软件工程基础：第3章 软件项目计划

第3章软件项目计划一年之计在于春，一日之计在于寅-----------增广贤文软件项目计划概述事实表明:软件工程项目的失败，大多是由于计划不周而引起的。软件项目计划的目标就是提供一个框架，使管理者有能够对资源、成本、风险及进度进行合理的估算分析和调度，为软件工程过程提供管理依据。

软件项目计划一般由软件项目的管理员、系统分析员与用户共同制订。

在需求分析阶段弄清软件系统的详细情况后才能正式定稿

3.1风险分析

T.Gilb:如果你不主动攻击风险，风险就会主动攻击你。

主动的、明智的风险管理策略应该在技术工作开始之前，先标识出潜在的风险，评估它们出现的概率及产生的影响，并按重要性加以排序，然后项目组织再制订一个计划来管理风险。风险分析活动：风险标识、风险估计、风险评价和风险管理与监控。

3.1.1风险标识

----类型宏观：项目风险、技术风险和商业风险。例如：资金不足（项目风险—预算问题）

规格说明存在二义性（技术风险）开发的产品过时（商业风险）

Charette：已知风险、可预测风险和不可预测风险。例如：自然灾害(不可预测风险)

用户计算机知识欠缺（已知风险）用户改变需求（可预测风险）风险标识----方法：风险项目检查表(Bohem）产品规模：与待开发或修改的软件的总体规模相关的风险。

商业影响：与管理或市场所加约束相关的风险。

客户特性：与客户的素质以及开发者和客户定期通信的能力相关的风险。

过程定义：与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。

开发环境：与用以建造产品的工具的可用性及质量相关的风险。

建造技术：与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。人员数量及经验：与参与工作的软件技术人员的总体水平及项目经验相关的风险。

3.1.2风险估计

估计风险发生的可能性。风险可能性尺度可以用布尔值、定量或定性的方式表示。（概率）估计与风险相关的问题出现后将会带来的损失：灾难的、严重的、轻微的和可忽略的。（影响值）。3.1.3风险评价

根据风险估计的结果，建立一系列三元组：[ri,pi,ei]，其中ri表示风险，pi表示风险出现的概率，ei表示风险产生的影响；定义项目的各种风险参考水准，如成本、进度等；

找出每个[ri,pi,ei]与各参考水准之间的关系；

预测一组临界点以定义项目的终止区，该区由一条曲线或易变动区域来界定；

预测怎样的风险组合，会影响参考水准。

风险表样本

风险参考水准曲线

估计进度延迟估计成本超支临界点（成本值，时间值）终止项目区3.1.4风险管理与监控

风险管理是指利用某些技术，如原型化、软件自动化、可靠性工程学，以及某些项目管理方法等设法避免或转移风险。

实施风险管理策略会带来一些额外的开销。仅当实施风险管理策略所需的成本小于风险管理带来的效益（即风险带来的影响）时才可考虑实施风险管理策略。高影响且发生概率为中到高的风险以及低影响且高发生概率的风险，应该首先列入管理的考虑之中。

按照Pareto的80-20规则，80%的软件风险能够由仅仅20%的已标出风险来说明。

风险监控

事件和主要风险因素的跟踪，判断一个预测的风险事实上是否发生了；

风险估计，确保针对某个风险制定的风险管理措施正在实施；

收集可用于将来风险分析的信息。

3.2进度安排

方式1:系统最终交付日期已经确定，软件开发组织在这一约束下将工作量进行分配；方式2：系统最终交付日期只确定了大致的期限，最终发布日期由软件开发组织确定，工作量以一种能够最好地利用资源的方式进行分配。

在实际工作中，第一种方式发生的频率远高于第二种方式。

3.2.1进度安排的基本原则

任务分解：将软件工程项目的任务分解成易管理的子任务,即作业;作业依存：确保作业间的依存关系——顺序和并发；时间分配：为每个作业指定开始和终止时间；

资源约束：在进行时间分配时应考虑资源约束，如人员数量、工具；

定义责任：应指定某特定小组负责某个作业；

定义结果：对每个作业定义相应的结果——产品或产品的一部分；

定义里程碑：每个作业或作业系列应与项目的里程碑相联系。

3.2.2工作量分配

40-20-40规则：在整个软件开发过程中，编码的工作量约占20%，编码前的工作量占40%，编码后的工作量也占40%。实际统计:CAD应用开发软件包工作量分配方案示例

3.2.3进度安排方法

原则上可以把一般工程项目的进度安排方法和工具应用于软件工程项目。

首先识别一组项目任务作业，建立任务作业之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，指定进度时序。

方法：PERT技术和Gantt图方法。

PERT技术

PERT技术（ProgramEvaluation&ReviewTechnique，PERT）

又叫计划评审技术、工程网络技术。

20世纪50年代后期，美国海军和洛克希德公司首次提出这一技术，并成功地应用于北极星导弹的研究和开发。

PERT图

1234567分析3概要设计

3详细设计

4文档整理2测试计划2测试方案设计

3产品测试

4编码30事件作业依赖关系计算事件的EET通常规定，起始事件的最早发生时刻为0；考虑进入该事件的所有作业；对于每个作业均计算其起始事件的最早发生时刻EET与持续时间之和；选取上述和数中的最大值作为该事件的最早发生时刻EET。

计算事件的LET通常规定，工程最后一个事件的最迟发生时刻等于最早发生时刻；考虑离开该事件的所有作业；对于每个作业都计算其结束事件的最迟发生时刻LET与作业持续时间之差；选取上述差数中的最小值作为该事件的最迟发生时该LET。确定关键路径

粗线箭头所示为关键路径

关键事件的EET等于LET利用机动时间安排进度

机动时间=LET-EET-作业持续时间先安排关键作业，再利用机动时间安排非关键作业。Gantt图方法

3.3项目组织

如何合理地组织参与项目的各类人员，以最大限度地发挥每个人的作用，对于成功地完成工程项目是非常必要的。软件项目中对于人员的管理问题不能象其它事件那样简单地划分，机械地对待。(Demarco)

3.3.1人员组织规律

Rayleigh-Norden曲线

如果在软件生存周期平均使用人力，则会造成：起始阶段人力过剩（图中①）、开发后期和维护前期人力不足（图中②）和维护时期人力补偿为时已晚（图中③）

各类人员参与程度曲线

初级技术人员在编码时参与最多，而在其它阶段参与则较少；高级技术人员在软件开始的开始阶段和结束阶段参与较多，在中间阶段参与较少；管理人员在项目开始阶段参与较多，其它则参与较少。

人员——时间权衡定律

软件开发工作量与软件开发时间的4次方成反比。如果适当延长软件开发时间，则可减少软件开发的工作量；反之，如果缩短软件开发时间，则工作量会大幅度增加。

Brooks定律

向一个已经延期的软件项目追加开发人员，可能会使它完成得更晚。当开发人员以算术级数增长时，人员之间的通信将以几何级数增长。

由这两条定律，可以得出：对于软件项目，开发时间宁可长一些，开发人员可少而精一些。3.3.2人员组织形式

软件开发机构选择怎样的人员组织形式，要针对软件项目的特点和参与人员的素质来决定。在建立软件开发组织时，应注意：

责任到人——尽早将责任落实，便于管理；

合理分工——减少不必要的通信，提高工作效率；

责权均衡——责任与权力的平衡，有助于任务的完成。

层次模式

软件经理负责整个开发部门的管理工作，在各项目之间分配和协调各种资源。项目经理负责一个具体项目开发的各个方面。每个小组负责项目的一部分工作。审查小组与项目经理同属一个层次，主要从事质量保证活动，在项目开发的里程碑进行技术审查和管理复审。

软件经理项目1经理项目n经理审查小组小组11小组12小组1m小组n1小组n2小组nm………矩阵模式

项目经理注重于问题域知识，阶段经理则熟悉阶段的开发知识。

总经理项目1经理项目2经理项目n经理阶段1经理阶段m经理子项1,1子项2,1子项n,1子项1,m子项2,m子项n,m阶段2经理子项1,2子项2,2子项n,2……………………主程序员小组

最早由H.Mills提出，并由Baker描述出来。主程序员负责制订计划、协调与审查工作，并完成结构设计及代码中关键和复杂部分的实现。技术人员负责项目的具体分析与开发以及文档资料的编写工作。

后备程序员主要协助主程序员的工作，必要时可替代主程序的工作。

1971年，IBM公司首次使用主程序员小组开发《纽约时报》的剪辑文件项目。

主程序员后备程序员其他人员技术人员民主小组

1971年Weinberg首次描述了民主小组的组织形式。

民主小组的最基本概念是“无我程序设计”（egolessprogramming）

日本许多公司使用权用民主小组的组织形式进行软件开发

层次小组

层次间按隶属关系进行通信，组内平等通信。这种组织方式适合于大型软件开发项目，尤其是项目本身就是层次结构状的课题。

项目负者人高级程序员高级程序员程序员程序员程序员程序员程序员程序员3.4软件项目开发计划文档

目的：用文件的形式，把对于在开发过程中各项目工作的负责人员、开发进度、所需经费预算、所需软/硬件条件等问题作出的安排记载