2 现状分析和改进机会
2.1 过程决定产品质量
一个好的软件开发过程可以提高软件开发团队的工作效率，控制开发过程中的风险，保证软件开发进度并且提高软件产品质量。软件质量的好坏是由开发过程中的每一个环节（并不仅限于测试环节）所保证的，过程中的每一个角色都应该对软件质量负责。
软件过程是软件开发组织的“灵魂”。软件开发过程的优劣对于软件产品的成本的影响是指数级的，是软件成本的最主要影响因素。这一点可以从图表2-1COCOMO II的软件经济学模型得到科学的印证。
图表 2 1 软件经济学模型
从这个公式中可以看出，软件产品的质量将受到人员能力、开发工具自动化水平、软件产品的规模和复杂度、以及软件过程成熟度等多个因素的影响。过程对于软件产品的影响是指数级的。
所以说，军工单位的软件开发过程中，过程必须先行，只有规范过程，其他的一切开发活动才有了切实保障。
2.2 军工单位的软件开发的现有过程架构
根据IBM公司对客户的深入调研和分析, 在软件产品或软件项目开发和管理中，由图表3-2 所示的项目管理过程、基本支持过程和项目开发过程这“两横一纵”组成了军工单位的完整的软件开发生命周期。
图表 2 2 军工单位软件开发生命周期
在上述的生命周期过程中,按照管理类过程、开发类过程和支持类过程,军工单位对应的各个阶段的子过程如图表3-3:
图表 2 3 军工单位管理类过程、开发类过程和支持类过程
2.3 军工单位的软件开发的现有过程特征分析
军工单位质量保证体系中的软件开发过程基本遵循了GJB2786-96的核心思想,同时在软件开发管理和基本支持过程又引入了GJB5000中的ML2和ML3的相关KPA,由于GJB2786-96将开发过程划分为五个部分：系统的需求分析/设计；软件开发；硬件研制；系统集成和测试；试验与评价及生产和部署。且因为武器系统，是计算机系统与机械、电子、光学等复杂对象有机关联的系统，这样的系统有它特殊的设计、制造、测试等方面特殊问题。所以,GJB2786-96的先进点之一，正如我们前面所说, GJB2786-96不仅着眼于软件开发这一事件，而是把软件系统作为特定硬件系统的神经系统来对待，并予以整体综合考虑。把软件研制过程分作五部分，按时间顺序进行开发，反映了软件研制的生命周期演进的观点，即软件工程学的瀑布模型法。
GJB2786-96中安排了许多审查、审核、测试、评价，并且用符号“+”来特别注明：“可能多次审查，也可能与硬件审查结合进行”。因此，GJB2786-96把系统开发过程视为一个可以多次反复试验的过程，即：按研制生命期演进，在某个阶段，要经过反复审核或审查，直至达到目的为止。这是GJB2786-96的又一先进之处：既符合了软件工程学的快速原型试验法的思想，也符合瀑布模型法的思想。
这两点结合，说明图表3-4所规范的软件开发过程，总体上规范了从顶向下逐步求精的开发过程，同时也规范了局部(不排除总体上)由底向上的逐步归约的开发过程。开发过程的终止是以满足功能与性能指标为标志。
图表 2 4 GJB2786-96结构
引入GJB5000 ML2和ML3的相关KPA,则可以弥补GJB2796-96在管理领域的弱项,可以使军工单位的软件开发和管理在过程层面达到如图表3-5所示的GJB5000成熟度等级的2级和3级的以下特征.
图表 2 5 GJB5000 ML2&ML3特征
2.4 军工单位的软件开发现有过程的改进机会
有了过程,那么接下来的问题是:
1. 过程的执行力是否能够得到保障?
企业制定了过程,并不代表企业同时具有了与过程对等的过程能力,即达到了相应的软件成熟度级别,企业必须在实际的开发和管理过程中遵照所制定的过程,依据过程所制定的适合企业的最佳实践进行操作,才不会出现过程改进中出现”两层皮”的怪圈,一方面企业意识到过程改进的重要,另一方面却为了软件过程改进而改进,在制定完过程后即束之高阁,企业的现状没有任何实质的转变.
另外一种情况是企业制定的过程没有结合自己的实际情况制定过程,过程改进中会导致所制定的过程水土不服,原因是这些过程是基于别人的过程.
基于以上两种情况制定的过程很难在企业中有生命力,即我们所说的”落地生根”,过程基本上没有执行力.
还有一种情况与以上情况的区别是,企业制定了合适的过程,执行起来却”虎头蛇尾”,过程改进本身也是一个项目,也需要按照下图的戴明环的原理进行管理,以保证整个过程改进是受控的和连续有效地.
图表 2 6 戴明环
2. 员工没有真正理解所定义的过程?
由于过程是回答在整个开发和管理过程中，什么时候、应该由谁、进行什么样的活动、产生什么样的结果的问题,所以企业中的每一个与过程执行有关的角色和员工,都应该如图3-7所示,清楚自己的职责,工作内容,上下游的工作衔接,即输入和输出以及针对每一项工作的指南,否则过程的执行力很难得到保障,而各种角色如果没有充分的了解与其相关的子过程任务输入和输出的工作产品,更甚至针对自身的工作没有成熟的可供操作和指导意义的指南信息,那么过程的执行将不会有效和充分,甚至在过程的执行过程中,人员会有意规避过程,原因是他们认为过程不具备可操作性,没有指导作用,反而增加了许多”无谓”的工作,逐渐产生抵触情绪,从而在根本上违背了过程改进的本意,使得过程的执行力大打折扣.同时也使整个开发团队的能力不升反降，我们称之为“软件开发的恶性生态环境”。
图表 2 7 统一方法架构（UMA)
3. 是否有合适的开发环境和工具平台？
软件产品质量主要取决于产品的研发或生产过程。为了规范军用软件的研发过程，提高军用软件产品的质量，中国人民解放军总装备部颁布了GJB5000-2003《军用软件能力成熟度模型》，对军用软件承制单位的软件研制能力进行评价。
GJB5000-2003是国家在参考了CMU SEI的SW-CMM V1.1的基础上制定的。SW-CMM是对软件企业的软件过程(过程)中各个发展阶段的定义、实施、度量、质量控制和改善的一个模型化描述。这个模型用于确定软件企业的软件过程能力和找出软件质量及过程改进方面的最关键问题，为软件企业的过程改进提供指南。在GJB5000－2003中，除了给出了相关于过程成熟度的描述内容外，还给出了改进模式的指导和评估/评价模式的指导。
从软件过程改进模型的角度，GJB5000-2003能够指导软件企业进行软件过程的改进。(SPI，Software Process Improvement) ；同时帮助软件企业对其软件过程的改变进行计划、发展以及实施；并且可以用于软件过程评估(SPA，Software Process Assessment) 。
但是GJB5000-2003侧重于对企业的软件过程和软件能力的评估评价，它提供的是一个软件过程改进的框架，这个框架与软件开发的生命周期无关，更与项目管理的过程无关，因此它并不是企业可以直接采纳的软件开发方法和项目管理方法。GJB5000-2003为软件开发的流程改进提供了一个系统的框架，但是它所提供的只是一个流程框架，在实践过程中还需要具体工程技术的支持。如对于GJB5000-2003中的每一个目标，GJB5000-2003建议了一些实践来达到该目标，但这些实践只是提出了在具体实践过程应该注意的事项，并没有列出具体可采用的工程技术。因为作为一个模型，它不可能局陷在某一特定的工程技术之上，不同的软件组织可以采用不同的技术手段来达到相同的目标。GJB5000-2003的实施需要软件企业采用合适的方法和工具平台进行支撑。
GJB5000-2003做为一个指南能够帮助软件企业选择、采纳和合理使用一些先进的软件项目管理方法和软件开发方法，并在实践活动中不断提高和完善，从而极大程度地提高企业按计划的时间和成本提交有质量保证的软件产品的能力，可以说GJB5000-2003是“方法论”而不是“实践论”。
以上这些问题,我们怎样去解决呢?
