当EPG成员开始制定流程和规范的时候，最大的困惑恐怕就是GJB
5000A-2008依据的软件工程哲学到底是什么？尽管这个题目比较大，但是我们还是可以GJB 5000A-2008对问题的表述中看出端倪。研究军标的软件工程哲学，就不得不研究我军长期以来指导这支军队发展壮大的根本哲学。软件开发也是一场战争，作为军标必然会渗透进军队对于战争的理解。下面我把我对此进行的研究心得供大家分享。
1，GJB 5000A-2008对工程过程域的表述
我们都知道，长期以来指导软件工程过程的一个模型，就是经典的递归（瀑布）软件开发过程。但是，在GJB
5000A-2008中工程过程域的描述与瀑布模型相比差别很大，如下图所示。
到底为什么会有这样的变化呢？我们能不能依据这张图通过反向推演，看看GJB 5000A-2008制定者们，在制定标准的时候的所依据的哲学与科学观念到底是什么？
2，用发展与动态的哲学观点看问题
仔细研究上面的图，我们就可以发现，GJB 5000A-2008所建议的软件工程哲学，关键点就是用变化的观点看问题。之所以强调这一点，是因为我军多年来能够由小到大由弱变强，依赖的就是我军有一个重要的指导思想，那就是辩证唯物主义世界观。具体化就是：到底我们是用孤立的、静止的、片面的观点来看待这个世界，还是用交互的、发展的、动态的、全面的观点来看待这个世界？这种被无数事实证明是正确的哲学观，是不是能够指导我们奉行正确的软件工程方法呢？
当我们面对软件过程的时候，很多人把过程看成一个静止的东西。在制定流程的时候，总是认为初期需求一定是、而且一定要完美无缺的，只要以顺序过程按照已有的规则去做，把所有的文档都书写好，那就一定会走向成功的。但是事情为什么总是事与愿违呢？
当我们认识和理解了我们必须用发展的动态的观点来看世界，那么这个困惑就可以迎刃而解了。事实上软件开发本身就是一个对事物的认识过程，是在一个认识不断深化、需求不断变化发展的过程中，通过创新精神，支持新事物的成长，最终才可能创造一个伟大产品。如果这样来看问题，后期发生需求变更是不是天经地义的事情呢？
正是在这种哲学思想的指导下，我们才会发现在整个工程过程域中有一个从头到尾都存在的过程域，那就是“需求管理过程域”。从本质上说，需求如果没有变化，那也就不需要需求管理了，需求管理正是管理着需求变化。
进一步说，如果我们认可以动态的观点看问题，既然需求是一个在过程中不断清晰的过程，那么计划也就必然是一个滚动式循序渐进模式，项目的计划需要经过一个由粗而精、不断完善的过程。也就是说项目的计划也会在频繁反馈中不断变更、滚动完善。
如果我们认可这个观点，那么，EPG小组在制定过程规范的时候，如何把这种计划的滚动完善变成可行的规则？如何力争把把计划失控的被动变更，变成了可控的主动变更？这种需求与计划的变更如何受控，如何确保在变动中不乱？如何从过程集成的层面，通过各个过程域的互相配合，在更高的层面保证产品质量？产品的质量控制到底怎么做才是合理的？这都需要我们在制定规则的时候仔细思考与实践。
3，利用反馈控制理论来设计软件过程
如果我们的软件工程哲学是用变化的观点看问题，那就需要用正确的科学手段来处理变化，这就不得不研究控制论的问题。
从控制论的角度看，有两种基本的控制方法：一种称之为前馈控制，另一种称之为反馈控制。所谓前馈控制，指的是需要事先通过观察情况、收集整理信息、掌握规律、预测趋势，正确预计未来可能出现的问题，提前采取措施，将可能发生的偏差消除在萌芽状态中，前馈控制发生在实际工作开始之前，是未来导向的。
问题在于如果我们认可软件开发本身就是一个认识事物不断螺旋上升的过程，那前期完完全全掌握情况几乎是不可能的，这就是为什么往往在项目快要交付的时候，才会发生需求变更的原因。联系到软件开发，我们会发现瀑布过程是属于前馈控制过程，一旦在项目后期发现了需求变更问题，已经很难保证不发生混乱了。
为了处理变化，可以采用反馈控制方法。也就是指把系统的输出信息返送到输入端，与输入信息进行比较，并利用二者的偏差进行控制的过程。
反馈控制其实是用过去的情况来指导现在和将来。反馈控制需要在很小的环路中不断地把输入和输出作比较，并且在过程中以误差为参数修正行为，以此保证比较高的精确度。由于在过程中不断的修正，就造成了距离目标越近，有关目标的信息越清晰，修正的目标就越精确这样一种情况。因此，为了正确实施反馈控制，就需要缩小反馈回路的规模，减少反馈的响应时间。这是处理变化的环境得很重要的科学手段。
让我们仔细看一下GJB 5000A-2008中对于工程过程域的描述，就可以发现，在其中存在大量的反馈通道，包括需求开发与技术解决方案之间，需求开发与产品集成之间、需求开发与顾客需要之间，都存在着反馈通道。这样，我们就需要考虑，在我们制定的过程规范中，如何形成这种灵活机变的反馈通道呢？
在我们定义的过程规范的时候，不能假定需求是无变化的，而是要主动建立反馈通道处理变化，不是被动的管理需求变更，而是主动发现变更并及时解决它。
我们在制定过程规范的时候就需要要考虑：符合这个科学思想的过程规范应该是什么样的？怎么样建立轻量级的反馈通道？怎么样早期发现需求变更并且有序、有效、规范的解决它？这些考虑，都是定义一个高质量过程所必须的。如果反馈通道重量太重太笨，是不能认为过程是采用了反馈控制论的。
4，过程中人的主观能动性的位置
任何过程哲学都不能忽视的一个问题，那就是过程模型中人的主观能动性所处的位置。也就是人们在活动中所具有的精神状态，即通常所说的决心、意志、干劲等。“在战争的一切要素中，人是第一重要的。”“战争的伟力极其最深厚的资源，存在于民众之中。”这些精辟的军事哲学，一直是我军得以成功的法宝。也是一种正确的思想方法与价值观，这都不可避免的渗透到GJB
5000A-2008里面去。
我军在长期的革命战争中，总结出了非常正确的三句话：“坚定正确的政治方向，艰苦朴素的工作作风，灵活机动的战略战术。”这三句话表达了三个观点，也就是目标管理、求实不搞花架子、灵活不死板僵化。这实际上也是中国文化的灵魂所在。因此我们在制定过程规范的时候，就绝不能把精力放在怎么制定一个庞大的叫人肃然起敬的、中规中矩的规范文本上，而是要实用，要根据具体情况制定相应的规程，要使规范真正在软件开发中发挥作用。而不是花拳绣腿，放在那里好看，变成一个玻璃柜（Glass
Case）似的供人观赏的规范。
在我们定义软件过程的时候，就需要考虑：在这个过程中人的位置在什么地方？过程是不是有利于激发所有参与者的积极性？过程是不是有利于发挥团队精神、进取精神、坚强意志、务实态度这些精神状态？无数事实告诉我们，这种精神状态，对项目最终成功有着不可忽视的作用。
进一步还需要考虑：这个工程规范能不能成为一个良好的交流平台？它是不是便于人们就一个问题集思广益？能不能使第一线工作人员的经验、观点及担忧得到充分的重视？能不能激发各个成员的参与、提高他们的积极性？如何使项目成员的经验、意见和想法就可以得到充分的应用，而不是遭受压制？如何使团队成员形成共同的目标，并尽最大的努力设法实现它？如何使整个团队达成互信，拥有充足的资源，确保项目一定会成功？
我们所制定的过程规范绝不能只见文档不见人，应该有人的位置。很多过去看似伟大科学但又无法使用的过程规范，最大的缺点，就是过程中没有人的位置。既然人在过程规范中应该处于一个重要的位置。那么，符合这个哲学思想的过程规范又应该是什么样的呢？
5，反馈过程中的回顾
回想国共战争中的方方面面，我们会发现一个非常奇怪的现象。国民党的将领大多数来自于黄埔军校、日本士官学校、德国陆军学校、西点军校。而我军的高级将领绝大多数都不是来自于这些学校，而是一个更大的学校：“战争大学”。但是正是这些没有受过正规训练的“泥腿子”，照样指挥大兵团作战，把那些学校出身的将领打得落花流水，他们是怎么做到的呢？这就发人深省了。
仔细观察和思考，就可以发现我军有一个非常值得称道的东西，那就是“回顾”。这是一个规则：每场仗打下来，必定要开总结会，必定要总结经验发现问题，必定要克服缺点修正错误。正是这种“回顾”，使战争成为一个大学校，所有的人在战争中都得到了快速的发展。
现在我们回到GJB 5000A-2008的过程定义，通过思索就可以发现，既然这个世界是不断变化的，那么科学的方法论就是反馈，就是充分发挥人的主观能动性。在这样的背景下，在反馈点上我们应该做一些什么事情呢？一句话：回顾！
回顾是一种正确的认识论和哲学观。阶段性的回顾能够尽早发现问题，能够早期发现需求的变更需要，能够充份调动每个参与者的积极性，更可以使每个团队成员在开发过程中迅速成长起来，而这样快速成长起来的团队成员，对企业来说将是无价之宝。
因此，当我们开始制定GJB 5000A-2008过程规范的时候，应该把如何在开发过程中进行“回顾”作为一个规则制定下来，至少应该有“回顾”的位置。需要仔细考虑：在什么点上回顾？什么人参加？回顾什么？如何克服缺点修正错误？如何早期发现变更的需求？回顾既然成为一个规则，那还需要考虑：回顾需要有什么样的报告和文档？
基于上述这些正确的哲学观、价值观和方法论，再综合人的因素、反馈过程、螺旋上升以及阶段性回顾，融合了这些思想的过程定义，是一种思考、研究、讨论与实践的结果，绝不可能照搬照套把别人的东西不经消化拿过来就用的。这样一种充满思想和智慧的的过程定义，必然是一个具有活力的，有创造力的，有价值的规范。
上面这些考虑，对于我们制定符合GJB 5000A-2008哲学思想的、目的明确的、科学而有效的、可执行的、并且符合实际情况的规程极其重要，是我们每一个EPG成员必须认真想清楚的、并且在实践中逐步完善的问题。
| 
