软件开发过程定义八步法

作者：浪潮齐鲁软件项目管理部 段聿军
现在无论是软件行业正在积极引进和推广的CMM，还是国内已经推广、实施多年的ISO9000，从其本质来看，都离不开以过程为中心的原则。在实际工作中，大家往往把过程称为流程，两者含义也差不多。

过程就是指通过利用资源和实施管理，将输入转化为输出的一组有序的活动。过程可大可小，可以将企业产品实现的一系列活动作为一个过程，也可以将这一系列活动中的一个作为一个的过程，如采购过程、检验过程等。建立一个有效的过程可以有效的使用资源、降低成本和缩短开发周期，并且使开发活动具有可预测性。通过对GTE、TRW和IBM三家公司研究表明，如果在需求阶段检查和修改一个错误，所需的费用只占编码阶段的1/5到1/10，而在维护阶段做同样的工作所付出的代价却是编码阶段的20倍，这就意味着在需求阶段与维护阶段修改一个错误的代价比值可高达1：200，由此可见做好过程控制的重要性。

如何才能定义一个好的项目开发过程呢？一般要遵循8个步骤才能完成：

1.确定项目的软件开发模型
开发模型一般有快速原形、瀑布、增量、并行开发和螺旋模型等。选择模型不同，开发过程中活动安排将会有很大的差别，如瀑布模型的特点之一是最终才产生可使用产品，而增量模型则要求在开发过程中每次增量都产生一个可使用的产品，后者就要求项目经理在安排计划时先考虑要实现哪些功能以及这些功能与以后开发的功能之间的关系等内容。

2.确定开发过程中活动,并对每个活动写出相应的描述
活动如需求、质量计划、测试计划、概要设计、详细设计、编码等等。

3.确定活动之间的关系
可以通过定义每个活动的入口和出口条件以及所需的资源来完成。

4.对每个活动有用的信息进行适当的描述
定义了开发过程之后，过程结构将需要一种方法来定义每个活动的提示信息和其它有用的信息，这部分成为注释，一般有四部分组成：活动简要描述、入口条件、出口条件和注释。这样做两个目的：

l     示范一个软件开发过程如何被定义的框架

l     介绍在后来章节中引用的基本概念和术语集

例如：

需求规格说明书

描述：详细的描述了产品外貌，即对用户来说，产品看起来象什么？每一个功能、命令、屏幕、提示符、外包接口和其它用户界面必须被文档化，以便于参加产品开发的人都能了解所要创建、文档化、测试和支持的产品。产品的目标提供了开发产品的规格说明所需要的方向和基础。

入口条件：目标被分散评审或批准

出口条件：目标被批准，需求规格说明书被批准，而且来源于规格说明书评审的所有问题要得到解决

注释： 在目标草案可使用后，可以启动规格说明；然而，在目标被批准前，规格说明书不被批准。这将确保所有主要问题连同产品的功能目标都在完成或批准产品的详细定义之前，通过规格说明书而被解决。规格说明书在批准后，只能通过指定的变更控制过程而被修改。

5.定义如何裁减过程的文档
裁剪开发过程的规则必须文档化并且易于理解。由于几乎没有两个软件开发的项目完全相同，这就要求每个项目的项目经理在使用前必须进行裁减来满足新项目的需要，形成本项目的开发过程。

6.确定为确保这些过程的有效运作和控制所需要的准则和方法        
如CMM中则成立独立的且具有向上汇报的SQA人员来完成，并且要求高级管理层要定期验证和了解项目的实施情况。裁减过程中要遵循一定的准则来进行，如哪些活动可以被裁减，哪些不能；哪些活动可以被合并，哪些不能；哪些活动不能满足项目要求，对其进行修改或补充；谁必须同意被建议的裁减等。

7.过程获得认可并培训员工
每个领域的代表成员要为他所代表的领域来批准该过程，以此来达成一种承诺。如果代表成员犹豫不决或不批准，则该成员应提出代表该领域的观点，再进行协商，直到达成一致意见为止。意见达成一致后，培训工作至关重要，它是向人们展示过程已被批准、并作为公司一种纪律必须得到遵守的最好方法。由于公司的情况不同可以采用不同的形式，如可以强制公司的每一个人参加一天的培训，也可花半天时间向组织的大多数成员介绍新过程，再预定较多的时间对那些最需要理解过程实现的人员进行培训，公司的新成员加入到组织时，不要忘记对他们的培训。

8.不断有效使用和改善过程，为新的项目使用
   有效使用和改善过程也是大多数公司的最薄弱之处，责任在于每个新项目的领导。这需要公司的领导层坚持让每个新项目遵照所批准的软件开发过程执行。曾经有人这样比喻，如果制定了满足CMM3甚至是CMM4的文档，而不很好的实施，可能现在还是初始级的水平。从ISO9000：2000版和ISO9001：94版比较来看，二者的很大差别也在实施的有效性上，ISO9001：94版注重按照定义的过程来做，而ISO9000：2000版则要求提高组织的有效性和效率，不断改进和完善。如果依靠考核来推动，则会造成虚假的成分较多，对今后的过程改进和项目借鉴也会失去意义。美国的主任评估师曾举过这样一个例子，有两个编码人员，对他们的代码进行测试时，结果发现问题多的人用的开发时间较少而做了一些其它的工作，而问题少的人则花的开发时间较多没有时间做其他工作，所以不好评比谁的工作更出色。从CMM的评估原则来看，也反对将绩效考核的方式应用到过程改进中去，目的是体现过程改进的真实性。