项目管理理论和实践：第2回 系统开发工程的计划

项目管理应该在最初执行的时候，适时建议项目计划。以TQC等客户满意度出发，对项目的范围、日程、体制、成员明确化。这些计划是否成熟、稳定，是左右项目的关键。

项目管理需要做的流程共有“项目计划”、“过程监督和控制”、“风险管理”、“约定管理”4类。今天我们说说“项目计划”。

明确约束

---

 

图1，项目计划的做成流程。主要由8个作业内容构成。所有的计划结果，都要总结到“项目计划”。

关于最初执行的“项目目标明确化”，约定内容和约定的事情作为约束事项要明确下来。在此基础之上，需要一边考虑限制事项（项目开发前提），一边明确开发的范围和开发的内容。这项工作，要经过项目管理者的确认、定义，并且正确的记录至文档。

讨论关键技术

---

“开发对象和环境的最优化”:

明确立了项目的目标后，接下来需考虑“决定作业开发的系统的运行环境和开发环境”。例如，如何选择C/S分布方式的系统形式、软硬件环境、软件插件、网络。在这个阶段，要尽可能的从多角度发掘，更深层次的讨论如何选择最合适的环境。在目前的软件开发中，这项工作尤为重要。除了项目的TQC外，还要考虑系统运行后的维护难度。

"开发方法论和工程的定义"：

根据开发方法论和开发方式，选择最适合的开发工具，选择最理想的开发过程定义。随着过程定义下来，所有阶段定义及其产品、工作内容、开始标准、完了标准都需要明确。

开发工程定义的同时，带着“我们需要做成一个什么样子质量产品”的疑问，制作质量管理计划。进行里程碑式阶段性检查，主要是保证我们的目标及计划不要存在大的偏差。质量管理计划主要定义各个工程阶段的质量管理方法（比如自我检查、评审、测试等），将各种手段用明确的定义、工作顺序尽早的明确下来。

WBS后制定日程计划

---

以开发范围、系统规模、处理数据数量、开发生产性等为前提，估算开发工数和开发周期。包括对于风险辨别、评估后，所以准备好负担的风险准备金。根据所有和钱挂钩的项目，成本就计划便完成了。一旦识别出了，若干风险，不要忘记准备好风险预案（接受、缓解、转嫁）。

 

至此，项目管理准备的工作重点转向WBS和具体的日程计划制作。首先，项目WBS，然后依据WBS做成全体日程计划。这个计划可以表示出发货日期等主要事情的日程、重要评审的日程、重大决策日的日程等。

在向用户企业供货的需求定义书、设计书、用户手册等文档的交货时间内，文档的质量管理方法等都要计划起来，这是不允许被忘记的重要事项。

将以上计划事项作为前提，制作“人员体制”。根据项目需求安排合适的人员。如果实在朝中无人，要制定出外部委托的合作单位计划。

最后根据“必要的技术种类”和“特定技能的需要投入时间”，项目组制定“培训计划”。与此同时，针对最终用户和使用部门也要制作培训的大计划。

以上8种工作的结果，全部要总结至一个统一的计划文档。这个计划将作为全体成员的作业规范。

另外，我们这里说的计划是标准化的计划。根据项目的不同理应进行适当的调整，因为也许有些工作是可有可无的。比如一个小项目的人员计划，3、5个人没几天就结束了。但如果希望系统开发的项目计划真正作为我们工作的BASE，那就需要无论在任何情况下都对文档化坚持再坚持了。

重要工程的定义

---

系统开发项目根据开发步骤不同，品质和生产性都有很大的不同。因此，尽早敲定以什么样的风格进行开发是关键，非常重要。如果项目组不足2~3人的话，是没有必要浪费时间定义什么开发过程成的。越是大的项目，开发过程定义就越重要。

 

 定义好开发工程后，首先以管理的角度，对开发阶段进行分割。明确各个阶段的输入、输出、开始、完了。

开发阶段化的例子

---

为了工作顺利开展，准备一本“作业指导”。描述各个阶段采用的开发方式、工具，使用什么数据。与此同时，应该准备好各种业务用语。如果采用原型开发，要明确目的和范围。

典型的开发模型为瀑布型。

瀑布型是最基本的开发工程模型。前工程的产品作为下一个工程阶段生产的输入。如同瀑布一般，因此得名。如图所示，开发实施的阶段在在模型的最底部，被一分为二。“需求定义阶段”和“系统测试阶段”，“外部设计”阶段和“集成测试阶段”，制作的设计和验证/确认一一对应。这个图，也被称作“V字模型”。在编码负荷大的大规模系统开发过程中，必须使用这种规范的模式。

使用代码生成器等开发工具的场合，内部设计到结合测试都被包含在开发实施过程中。

在使用RAD快速应用开发的阶段模型中，只定义了“需求定义阶段”，“外部设计”以下的工程阶段并没有被定义。如果开发成员的数量较少，实际代码数量较少，采用这种模式是比较合适的。

开发工程选择的注意点

 

---

应尽量避免，没有参考数据的“假设”和容易让人迷惑的“错觉”。实际工程中，很多工程师希望项目成功，但盲目接受所有的开发条件，不去分辨对待。在过去较多的大型项目开发过程中，这种冒失的例子有很多。

 

举例说明，比如大规模的系统开发如果没有取得所有数据的一直性（风格、模式等），随着RAD和增量开发，尽管最初的看齐来算孙立，但最后系统全体的界面很有可能不匹配。

开发工程务必经过慎重考虑、评审分析平台种类、使用的开发工具、项目规模等。

一般来说瀑布开发适合所有大型项目的开发，如果错将应该作为瀑布模式开发的项目当作非瀑布模型进行开发的话，最终的规模有可能产生不可思议的膨胀。

最近使用必不可少的可视化开发工具、类库等软件中间件,有很多瀑布型和非瀑布型相结合的例子。在这种情况下，如何取得系统整体的一致性的疑问一定要在项目开发初期得到答案，并且依照外部设计奖系统分割成若干低耦合的功能。从此，就不用定义其他阶段了，开始着手各个子系统的增量开发、原型开发。

另一方面，如果即时是在项目开发投入都处于峰值的时间段，开发成员也不足几个人的情况下，采用非瀑布型的开发更能提高项目成功的概率。

大规模子系统化

 

---

大规模的系统华开发的情况下，需要在项目工程定义的同时进行子系统的划分。子系统的分割的目的和项目管理工程分割的目的是一致的。那就是追求可度量、可跟踪、可控制。但两者也有不同，其中过程定义主要是以时间线的概念进行纵向跟踪，子系统的划分是站在规模的角度对项目组进行细化分割，这属于横向分割。

 

在划分子系统的时候，作为有经验的管理者一定会保持规模的一致。比如一个1000功能点的功能（相当于10WCOBOL程序），当划分成若干子系统的时候，其规模不会有太大变化。

子系统以需求需求为基础，一边根据业务和系统的模式，一边考虑主要处理的数据对象，综合考虑后作系统划分。划分子系统任务尽早提前，至少在外部设计中能够得到体现。较大规模的工程中，通常在需求分析阶段，依据业务种类分组调查。这种分组的方式完全可以在子系统划分的时候继续沿用。

具体子系统的划分标准，主要参照各个模块之间数据流的复杂程度。一定在耦合度最低的地方，进行划分。子系统划分的工作中，不存在快刀斩乱麻。

在下一节，将向大家介绍，质量管理计划相关的内容。

 “项目计划”流程主要有8个作业项目。“项目目标的明确化”、“开发对象和环境的最优化”、“开发方法和工程的定义”、“估算和风险评估”、“WBS和日程”、“文档化计划”、“开发体制计划和关键成员计划”、“教育计划”。