国内目前软件开发项目组中可以采用的软件工程手段
2003.1
1. 前言
为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；当然，公司情况良好则有更加可行的、更多的方法可以选择；这里只讨论了最差情况下可以采用的方法。
本文按照最简单的瀑布模式的各个阶段分别列举了一些方法，在其他模式中应该也可以采用。
必须指出的是：这是对目前情况的一个分析和总结；本文(V1.0)的完成时间是2003年1月，有效期大概是半年。限于个人的认知有限，希望能够得到大家的指正和补充。计划每半年提出一个新版本，希望中国的软件工程技术能够快速地发展，让此文每次都有许多新东西。另外，这里所说的国内，当然指的是中国国内民营、私营、国有企事业单位和一些虽然有外资性质，但无外资软件企业开发规范、纪律和管理制度的“假外企”。因为很多外企的经验、方法虽然很好，但是没有相应的制度、文化支持，照搬是不行的。比如：微软的开发、测试同步进行，日创建等方法，虽然很好，可是只能借鉴，在小范围内实施；如果哪个企业的项目经理想全部照搬，那就要先想一想有没有微软那么多的钱、人和文化氛围。所以，本文不把微软、IBM、HP、Motorola等外企的方法作介绍；本着从实际出发的原则说，我们现在不具备全盘引进那些先进开发方法和经验的条件。《软件工程》上介绍的方法，只能有一小部分能够在国内的项目中部分地、有条件地使用—本文就是要介绍目前这些方法或手段，和它们的使用特点以供大家选择。 数据挖掘实验室
2. 需求阶段
需求的管理应该是贯穿整个开发过程，往往最大的问题是变更失控。在需求获取、讨论、分析等阶段，可以采用的方法有：
CCB(变更控制委员会)
建立CCB（change control board）是需求管理的前提，否则需求管理将成为一句空话。 数据挖掘研究院
CCB必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员，测试负责人，SQA.等，以5-7人左右为宜。
需求确认，发生变更等活动必须由CCB以会议形式批准。
CCB对整个项目有最高权力（不仅负责需求变更，还负责听取项目经理汇报、关键中间工作产品评审等重要决策） 数据挖掘实验室
这里需要着重说一下评审。评审是正规化开发的一个重要标志，目前常见的方式有：同行评审，团队评审，走查等。根据需要可以采用会议、
需求评审，纳入基线
原始需求必须形成文档，被CCB评审，然后纳入基线管理，所有变更都需要CCB评审。
该评审一般步骤：
项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响（主要是带来的规模、工作量、成本），提出计划和计划执行人，举出可能风险；
CCB来决定是否同意或要求项目经理修改上述项；
之后，项目经理提交执行情况汇报。
最后，CCB指定代表或由SQA进行核实。
如果变更过小，过多，可以进行周汇总评审。
3. 项目计划阶段
项目计划是开发的指导或脚本，事实上，在每一个阶段开始时，都应该重新、小范围修订一下计划。 数据挖掘研究院
选择合适的软件开发生命周期
关于生命周期的选择上，一直有而且会有很多争议。目前，国内运用最多的是纯瀑布生命周期；个人的看法是：一定有更好的选择，但这是一个最安全、最少在实际中有争议的选择。
选择合适的生命周期的要点是：一定要有选择原因的陈述—本项目的特点，团队特点，开发特点和公司或部门的特点；该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。 数据挖掘研究院
除了主流模式外，一些“轻量级“的方法也值得考虑，目前成熟的、有部分被使用的有：
XP（Extreme Programming，也快变成“主流“了），要点是：communication,simplicity,feedback,courage 数据挖掘研究院
ADP（Adaptive Software Development） 数据挖掘研究院
Cystal 数据挖掘研究院
SCRUM 数据挖掘研究院
FDD 数据挖掘研究院
一般项目经理也许不会轻易采用这些不熟悉的模式，但了解一点，借鉴其中的一些好方法和思想则是应该的。 数据挖掘研究院
最糟糕的是没有选择任何模式，上来就Code&Fix；或者在进度压力下退化成Code&Fix。 数据挖掘研究院
Code&Fix的发生，一定要项目经理负主要责任：一种情况是没有管理或管理无能；还有就是在编码或测试阶段需求变更失控；需求分析、设计失败的话，当然就只能Code&Fix了。 数据挖掘研究院
划分阶段--小里程碑
根据选定的生命周期模型，考虑到可以投入的人员，各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月，那么应该在每经过一个月左右选择合适的点作为小里程碑。
每达到一个里程碑时，项目经理应该提交本阶段工作报告，一般应该包括：
本阶段活动统计和估计的数值和它们差异的原因
工作产品完成情况 数据挖掘研究院
需求变更情况统计 数据挖掘研究院
问题及其解决情况的统计 数据挖掘实验室
总结优点和缺点，指出对下一步工作的影响
CCB听取该报告并评价该阶段工作。
小里程碑可以防止项目失控，使项目经理、项目组和其上的管理层能够正确认识到项目进展情况，并能协助项目开展、出谋划策，项目可视化好；避免项目发生大问题。
里程碑应该定义明确，有容易检查的结果，它只有完成/不完成两个状态，丝毫不能含糊。
决定工作产品和含中间工作产品
在最混乱的项目中，工作产品和中间工作产品都没有被明确定义，或者可以朝令夕改，随意添加或去除产品。决定工作产品和中间工作产品，是为了确定各个产品的重要性，计算其上的工作量以合理地投入足够的、合适人员来开发它。
项目工作分解
一般是将系统分解成模块甚至更细，要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定；一个忠告：开始做得细、做得认真，以后的工作都会相应容易很多。
一般人只分解产品。实际上，管理工作也应该分解的，而且也比较容易作。
工作分解的原则是：每个工作包必须分解到5工作日或一个工作周内，至少是即将进行的阶段的所
