注意，图5-4的“发行”活动不像在图5-3中是分开列举的。它包含取得所有项目资助者同意发行的时间，建立项目的最后记录，建立项目的历程报告和其他项目结尾的活动。

图表中的具体数据都是依照经验法则得来的，所以不是很严格的数字。不过它们还是提供了一些实际的概念。需求开发跟构架的上游活动消耗了项目努力中相对较少的部分，而下游的构建跟系统测试活动则消耗了太多的时间和精力。上游活动对下游活动起着极大的杠杆作用，两者都需兼顾是很重要的。

图5-5补足了上图，说明项目活动间的典型时间分布图。


从这些图表中得到一个很重要的概念是，项目中进行某一活动的时间比例不会跟耗用的精力成正比。需求开发工作一般会耗去项目12%的时间，可是只占用6%的努力。由于上游活动比较抽象而需要更多的深思熟虑，所以必须以较慢的步调进行。

程序代码增长曲线

前面的图表应该已经说明在项目初期有许多不会产生任何程序代码的工作要做。其实项目的头三分之一是用来详细了解需求与发展高质量的构架方式，好让项目团队能够好好检测项目规格，然后一次把产品做好，程序代码可能会教慢写出来。项目中间的三分之一主要在建立项目软件上，在这一阶段程序码会快速产生出来。项目的后面三分之一，则将焦点摆在检查前面阶段写出来的程序代码是否上得了台面。这一阶段着重错误修正和根本程序代码的更动。如同开头三分之一，程序代码增加得很缓慢。图5-6描述了一个执行良好的项目中程序码增长的方式。

黑线表示正常的程序代码增长方式，阴影部分则表示正常变化量。在项目中期程序代码增长的变化量仿照过渡版本提升现有程序代码品质而产生的。图5-6中的项目在最后推出产品以前，推出两个过渡版本。


一旦你了解了程序代码增长的方式，你就能很精确的估计项目的现况。执行良好的项目每周都会记录项目的程序代码。如果你认为项目快到结尾，新程序码几乎也停止增加，这时项目就已经可以准备发行了。如果新的程序代码还不停的加入项目中，那项目就还处于执行中期的三分之一，还没接近推出的成熟阶段。

同样的道理，如果开发人员在他们完成构架设计前加入太多程序代码，你几乎可以保证会在系统测试阶段停留许久，那是为了要让开发人员修正他们在系统设计还不是很成熟时所造成的错误。

一些项目犯下的严重错误是将产品在只完成了85%左右时就发行出去。

如果项目主持人不了解图中所说明的软件开发方式，他们会假设新的程序代码开发量开始降低时就可以立刻把程序推出去发行了，特别是项目执行受到明显的时间压力时。这个将产品只有85%完成度就仓促发行的决定，表示软件终究未臻完善，这样的决定就像搬砖头砸自己的脚。

主要完成点与推行点
有时候，前几节中描述的一般软件开发方式可缩减成以图像表示详细的完成时间点和推出时间点。主要完成点以极高水平来追踪项目执行进度，图5-7概述了本文中使用的高层次阶段和完成点的划分方式。

这里的通用项目要点几乎可以应用到任何规模的项目上。实际上每个阶段的初步工作常可以比图中所说的更早开始进行，而后头的工作可以比图中所示的要晚结束。本图说明了每段时间中主要强调的重点都放在个别的活动上（图5-3已经更完整的提到过各项活动重叠的情形了）。


上层主管与客户有时对于软件项目中的完成点模糊不清、无法依据而感到泄气，不过如果你依循着本文建议的做法，以完成点的方式追踪项目进度，将可以对项目状态得到良好的了解。表5-1列出这些完成点与图5-7的高层次阶段划分方式相对应的详细活动。

表5-1 高层次完成点与推行点的划分方式
◆ 项目初期
□ 找出项目关键决策者
□ 建立、检视并按照前景叙述进行项目
□ 建立软件的业务状况评估
□ 建立、检视初步努力与时间目标
□ 团队中拥有2～3名资深开发人员
□ 建立、检视变更管制规划，定案
□ 建立、检视十大风险清单，并以此避开已知风险
□ 开始记录软件项目的过程
项目这时期所进行的工作没有的明显终结点。这时期的工作是用来了解项目规模而进行的。这时期耗用的时间和精力会随着项目的不同而有极大变化
◆ 项目开启/可行性研究完成

□ 质量保证主导者就位
□ 文件说明主导者就位
□ 找出重要使用者，进行访谈
□ 建立简单的使用者接口雏形，由使用者审查直到能被接受后定案
□ 使用者接口格式简介建立，经过检阅后作为日后说明文件的基础
□ 建立第一次项目评估（精确度在-50%～范围线+100%的范围内），检视评估记结果后定案
□ 建立初步软件开发规划，经过审查后，据以执行项目过程
□ 更新十大风险清单
□ 更新软件项目记录
项目在这部分的工作也是不受结尾限制的，而且依照项目性质而决定

◆ 初步需求开发完成
在这时期，项目中开放性结尾的工作都已经完成了，现在需要一些检查来决定要不要继续进行项目
□ 建立细节使用者接口雏形，经过检视后定案
□ 建立使用说明/使用规格，经过审查后定案
□ 建立软件质量保证计划，经过检查后定案
□ 建立细节软件开发规划，经过检查后定案
□ 更新项目评估（精确度在-45%～+75%的范围内）
□ 更新十大风险清单
□ 更新软件项目记录
到这一阶段中约花费12%的项目时间跟6%的人手精力。这些比例不包括在项目开启/可行性研究与初步需求开发上的工作时间跟努力成效的花费

◆ 细节需求开发完成
◆ 审查规划，决定要不要继续进行项目

□ 开发团队大致就位
□ 管理人员大致就位
□ 完成使用说明/使用规格后撤除撰写文件的人力（除非有别的文件产品要写）
□ 建立软件构架文件，检查后定案
□ 建立软件整合程序，检查后定案
□ 建立阶段性完成规划，检查后定案
□ 建立第一阶段的软件测试项目，检查后定案
□ 更新使用说明/使用规格
□ 更新项目评估（精确度在-30%～+40%）
□ 更新十大风险清单
□ 更新软件开发规划
□ 更新软件项目记录
到这阶段，约耗费20%的项目时间与14%的精力

◆ 构架完成

□ 开发团队完全就位
□ 品管人员完全就位
□ 初步阶段规划完成
□ 建立第一阶段的细节设计文件，检查后定案
□ 建立包括小型完成点的第一阶段的细节软件构建规划，检查后定案
□ 建立下一阶段的软件测试项目，检查后定案
□ 更新第一阶段软件测试项目
□ 建立第一阶段软件建立指示（产生档案）
□ 建立第一阶段软件源代码，检查后定案
□ 创造安装程序，检查后定案
□ 更新使用说明/使用规格
□ 第一阶段“功能完成”产品
□ 更新项目评估（精确度在-20%～+30%）
□ 更新十大风险清单
□ 更新软件项目记录
假设项目分三个阶段，到这阶段约耗用45%的项目时间与40%的努力成效

◆ 第一阶段程序代码完成
□ 各项活动同上
到这阶段约花费65%的项目时间与65%的努力成效

◆第二阶段源代码完成
□ 建立最后阶段细节设计文件，检查后定案
□ 更新所有阶段软件测试项目
□ 更新所有阶段软件源代码
□ 更新所有阶段软件建立指示（产生档案）
□ 更新安装程序
□ 如果软件是个业务系统，完成使用文件（清楚的使用说明），完成使用者训练，使用团队准备上路
□ 整合已完成的“功能完整”产品
□ 更新项目评估（精确度在-5%～+5%）
□ 更新十大风险清单
□ 更新软件项目记录
到这阶段，约花费85%的项目时间跟90%的努力成果

◆ 最后阶段源代码完成（如果分三个阶段，这就是第三阶段）

□ 建立发行检查项目，检查后定案
□ 所有成员同意发行产品，不再更议产品
□ 完成功能正确的产品
□ 完成功能正确的安装程序
□ 完成最后测试项目
□ 完成软件正本的复制
□ 项目成果媒介（源代码、建立环境等）归档存放
□ 更新最后软件项目记录
□ 建立项目历程文件，检查后定案
到了这阶段，用去100%的项目时间与努力成效

◆ 产品发行

有时人们会想，为何软件项目要花那么久的时间。表5-1中的推进项目清单有助于回答这个问题。每个推进项目都代表一些必须完成才能让项目有效推进的重要工作。

大部分执行成效糟糕的项目最后都得做同样的事情，由于它们缺乏管理
，执行起来也缺乏效率，最后花费代价更多却没得到什么好处。

人们抗拒“开发程序”的一个理由是开发程序导向的项目在一开始就让人们看到一张这样的工作清单，使他们觉得“把这些事情都做完的话，项目就永远做不完了！”事实是如果项目中不做这些事，就得花更久时间才完成得了。即使小型的项目也得处理表5-1中列出来的绝大多数工作项目，虽然有些工作在小型项目中做起来不会花什么时间。我们也不希望做那么多工作，不过对软件项目而言，忽视一定得做的事情恐怕会功亏一篑，而如果人们知道一个项目中从开头就有哪些事情必须做的话，每个人都会好过得多。

=================================================================
求生检查
项目采用阶段性完成方式。
上层主管、顾客或两者都依据程序代码增长曲线盯紧项目进度。
上层主管、顾客或两者都留心着主要完成点和推行点的达成。
=================================================================[@more@]