软件项目计划.docx
《软件项目计划.docx》由会员分享，可在线阅读，更多相关《软件项目计划.docx（8页珍藏版）》请在冰点文库上搜索。
软件项目计划
第3章软件项目计划
3.1风险分析
教学内容：
风险标识、风险估计、风险评价和风险管理与监控。
教学重点：
风险标识。
教学难点：
风险估计。
教学方法：
课堂讲授+讨论。
教学要求：
掌握风险标志方法，了解风险估计和评价，理解风险管理。
思考题：
为何要对软件项目进行风险分析？
3.1.1风险标识
风险发生的“不确定性”和风险发生后带来的“损失”是风险包含的两个重要特性。
在进行风险分析时重要的是量化“不确定性”的大小和与每个风险相关的“损失”的程度。
风险标识是进行风险分析的第一步。
从宏观上来看，可将风险分为3类，即项目风险、技术风险和商业风险。
另一种常用风险分类方式由Charette提出，将风险分为了3类：
已知风险、可预测风险和不可预测风险。
一种识别风险的好办法便是得用一组提问帮助项目计划人员了解在项目和计划方面存在哪些风险。
Boehm建议使用一个“风险项目检查表”，列出所有可能的与每个风险因素有关的提问，从以下几个方面识别已知的或可预测的风险。
①产品规模
②商业影响
③客户特性
④过程定义
⑤开发环境
⑥建造技术
⑦人员数量及经验
3.1.2风险估计
风险估计主要有两个方面的工作，一是估计风险发生的可能性，另外是估计与风险相关的问题出现后将会带来的损失。
为此，项目计划人员、其它管理人员和技术人员一起进行四种风险估计活动，即建立一个尺度或标准来表示一个风险的可能性；描述风险的结果；估计风险对项目和产品的影响；确定风险估计的正确性，给出风险估计的定量结果。
估计每个风险所产生的影响时，对4个风险因素：
性能（即产品能够满足需求且符合其使用目的的不确定程度）、成本（即项目预算能够被维持的不确定程度）、支持（即软件易于纠错、适应及增强的不确定程度）和进度（即项目进度能够被维持且产品能按时交付的不确定程度），分别确定影响类别（即灾难的、严重的、轻微的和可忽略的），并求平均或加权平均，得到一个整体的影响值。
不同的风险发生后对项目造成的影响各不相同，主要有3个方面需要考虑，即风险的性质（风险发生时可能产生的问题）、风险的范围（风险的严重性及总的分布，如项目的多少部分或有多少用户受到损害等）、风险的时间（何时能感受到风险及风险持结多长时间）。
据此确定风险估计的加权系数，以得到项目的风险估计。
3.1.3风险评价
在风险评价时，可根据风险估计的结果，建立一系列三元组：
[ri,pi,ei]，其中ri表示风险，pi表示风险出现的概率，ei表示风险产生的影响，i=1,2,…,M表示风险的序号，假定软件项目共有M种风险。
要对项目风险进行评价，必须定义一个风险参考水准。
对于大多数项目而言，性能、成本、支持和进度就是典型的风险参考水准。
对于性能下降、成本超支、支持困难或进度延迟，都有一个水准值的要求，超出它就会导致项目被迫终止。
在软件项目的风险分析中，一个风险参考水准存在一个单独的点，称之为参考点或临界点，在该点上决定继续或终止（如果问题较大）该项目都是可以接受的，但超过它时会引起项目终止。
通常，风险评价可分为如下4步：
①定义项目的各种风险参考水准，如成本、进度等；
②找出每个[ri,pi,ei]与各参考水准之间的关系；
③预测一组临界点以定义项目的终止区，该区由一条曲线或易变动区域来界定；
④预测怎样的风险组合，会影响参考水准。
3.1.4风险管理与监控
风险管理是指利用某些技术，如原型化、软件自动化、可靠性工程学，以及某些项目管理方法等设法避免或转移风险。
与每种风险相关的三元组[ri,pi,ei]是风险管理的基础。
[例3-1]设项目组高级职员流动给项目带来的风险为r1，基于过去的历史和管理经验，高级职员离开项目组的概率为p1=70%；该风险带来的影响e1的估计值使项目开发时间增加25%，项目的成本增加30%。
为了管理这一风险，项目管理者必须制订一些策略，一种可能的风险管理策略如下：
①与现有人员探讨人员流动的原因，在项目开发期间控制这些原因，尽量减少人员的流动；
②在项目开始前，采取行动缓解在管理控制之下的原因；
③项目启动时做好人员流动的准备；
④对项目进行良好的组织，使每一开发活动的信息能被广泛传播和交流；
⑤制定文档标准并建立相应机制，确保文档能被及时建立；
⑥对所有工作进行详细复审，使大多数人能了解工作细节，跟上工作进度；
⑦对每个关键的技术人员均指定后备人员。
实施风险管理策略会带来一些额外的开销。
项目管理人员或计划人员要对风险管理策略的实施进行成本/效益分析。
仅当实施风险管理策略所需的成本小于风险管理带来的效益（即风险带来的影响）时才可考虑实施风险管理策略。
例如[3-1]实施其对应的风险管理策略仅增加2%的成本和4%的开发时间，而风险带来的影响的估计值使项目开发时间增加25%，成本增加30%，从而管理或计划人员应考虑实施有关风险管理策略。
从风险管理的角度来看，风险发生的概率和风险影响起着不同的作用。
一个具有高影响但发生概率很低的风险不应该花太多的管理成本。
而高影响且发生概率为中到高的风险以及低影响且高发生概率的风险，应该首先列入管理的考虑之中。
同时，对于有些已标出、评估及预测过的风险可能也不纳入风险管理的考虑。
按照Pareto的80-20规则，80%的软件风险能够由仅仅20%的已标出风险来说明。
随着项目的进展，风险监控活动便开始了，风险监控是一种追踪活动，主要有3个目标：
①事件和主要风险因素的跟踪，判断一个预测的风险事实上是否发生了；
②风险估计，确保针对某个风险制定的风险管理措施正在实施；
③收集可用于将来风险分析的信息。
在例3-1中，应该监控：
项目组成员对于项目压力的一般态度，项目组的凝聚力；项目组成员之间的关系；与利益相关的潜在问题；在公司内外工作的可能性；等等。
3.2进度安排
教学内容：
进度安排的基本原则、工作量分配、PERT技术、Gantt图技术。
教学重点：
PERT技术、Gantt图技术。
教学难点：
PERT技术。
教学方法：
课堂讲授+习题。
教学要求：
掌握PERT技术和Gantt技术，了解进度安排的基本原则。
3.2.1进度安排的基本原则
同软件工程的其它方面一样，有一些基本原则可以用来指导软件项目计划的进度安排。
①任务分解：
将软件工程项目的任务分解成易管理的子任务,即作业;
②作业依存：
确保作业间的依存关系——顺序和并发；
③时间分配：
为每个作业指定开始和终止时间；
④资源约束：
在进行时间分配时应考虑资源约束，如人员数量、工具；
⑤定义责任：
应指定某特定小组负责某个作业；
⑥定义结果：
对每个作业定义相应的结构——产品或产品的一部分；
⑦定义里程碑：
每个作业或作业系列应与项目的里程碑相联系。
随着项目进度的发展，上述每条原则都可能用到。
3.2.2工作量分配
在可行性研究阶段，通过成本估算方法获得了完成某项软件开发任务所需工作量的估计值。
在制订软件项目计划时，需要将工作量的估计值在软件定义与开发阶段进行分配。
另一种称为“40-20-40规则”的工作量分配建议方案认为：
在整个软件开发过程中，编码的工作量约占20%，编码前的工作量占40%，编码后的工作量也占40%，显然，这一工作量分配方案不强调编码工作。
实验上，现在对于大型软件项目而言，编码的工作量所占分额还在进一步缩小。
对实际开发的软件项目进行统计表明；一般在计划阶段所需工作量很少超过项目总工作量的2%~3%，除非是具有高风险的巨资项目；需求分析可能占用项目工作量的10%~25%,用于分析或原型开发的工作量与项目规模和复杂度成正比增长；通常有20%~25%的工作量用于软件设计，包括设计评审和迭代修改的时间；由于设计时投入了相当的工作量，使编码工作变得相对简单些，用15%~20%的工作量就可以完成；测试和随后的调试工作约占30%~40%的工作量，且测试的工作量取决于软件的质量特性要求，如可靠性程度等。
3.2.3进度安排方法
软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同。
首先识别一组项目任务作业，建立任务作业之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，指定进度时序。
原则上可以把一般工程项目的进度安排方法和工具应用于软件工程项目。
下面主要介绍两种方法，PERT技术和Gantt图方法。
1．PERT技术
PERT技术（ProgramEvaluation&ReviewTechnique，PERT）又叫计划评审技术。
20世纪50年代后期，美国海军和洛克希德公司首次提出这一技术，并成功地应用于北极星导弹的研究和开发。
几十年来，它在许多工程领域获得了广泛的应用，有时也因此称之为工程网络技术。
2．Gantt图方法
Gantt图，又称横道图，用水平线段来描述各作业的进度安排。
一般在每一作业的起始时刻和约束时刻各画一个小三角形，当作业开始或结束时，把小三角形涂黑。
Gantt图的横轴列出的是日历时间，纵轴列出的是作业名称。
3.3项目组织
教学内容：
人员组织规律、人员组织形式。
教学重点：
人员时间权衡定律、Brooks定律。
教学难点：
矩阵模式组织结构。
教学方法：
课堂讲授。
教学要求：
了解人员组织规律，熟悉人员组织形式。
思考题：
为何向已经延期的项目增加开发人员反而会使项目更加延期？
为何软件开发人员应该少而精？
3.3.1人员组织规律
对于一个软件项目而言，单个软件专业人员不可能在有限时间内单独完成。
如何合理地组织这些人员参与软件的开发是项目成败的关键。
为此，软件项目管理者应该重视软件项目的人员组织规律，不能简单地对待。
1．Rayleigh-Norden曲线
以Rayleigh爵士的名字命名的曲线本来是用于解释某些科学现象的。
1958年，Norden发现该曲线可用来说明科研及项目开发在实施过程中人力的需求。
1976年,Putnam又发现在软件生存期各阶段所需的人力分配具有与Rayleigh曲线十分相似的形状。
2．两条定律
Putnam在对Raleigh曲线进行大量研究的基础了，提出了Putnam模型。
该模型指出，软件开发工作量与软件开发时间的4次方成反比，Putnam将这一结论称之为“软件开发的人员——时间权衡定律”。
3.3.2人员组织形式
人员组织是一切软件项目管理的关键。
无法想象一个松散、责任不明确的一伙人在一起可以高效地开发软件。
软件开发机构选择怎样的人员组织形式，要针对软件项目的特点和参与人员的素质来决定。
在建立软件开发组织时，应注意：
责任到人——尽早将责任落实，便于管理；合理分工——减少不必要的通信，提高工作效率；责权均衡——责任与权力的平衡，有助于任务的完成。
就软件项目的组织结构而言，通常有两种模式可供选择。
（1）层次模式
层次模式是一种传统的管理结构，每一层人员向上层报告工作并且管理下层的人员。
（2）矩阵模式
矩阵模式实际是层次模式的扩展，一方面每个项目有一个项目经理管理，另一方面，每一个项目又分为若干阶段，按受阶段经理的管理。
对于层次模式中的小组和矩阵模式中的子项的组织，主要有三种组织形式。
（1）主程序小组
主程序员小组组织形式最早由H.Mills提出，并由Baker描述出来，小组主要由以下人员组成：
1名主程序员；2-5名技术人员；1名后备程序员。
（2）民主小组
1971年Weinberg首次描述了民主小组的组织形式。
民主小组一般由5-7人组成，其中1人兼任组长。
民主小组的最基本概念是“无我程序设计”（egolessprogramming），人人把小组开发的程序看成是“我们的”程序，而不是“我的”程序。
遇到问题时，组员之间可以平等地交换意见，从而可以充分发挥每个成员工作的积极性。
（3）层次小组
在层次小组内，人员分成三个层次：
项目负责人（组长）1人，负责全组的工作，直接管理2-3名高级程序员；每位高级程序员下属若干名程序员，负责子课题的有关工作。
3.4小结
软件项目计划是继可行性研究之后软件工程管理的重要组成部分，主要内容包括风险分析、进度安排和项目组织。
风险分析是软件项目计划的一个主要成部分之一。
当对软件项目期望很高时，均会进行风险分析活动，不过大多数软件项目管理者会非正式地完成它。
标识、估计、评价和管理风险有可能会占用较多的项目计划工作量。
但由于经过风险分析，能够做到“知已知彼”（彼即风险），从而“百战不殆”，使得开发者能够战胜风险带来的损失，使项目成功。
进度安排是软件项目计划的关键组成部分。
实际工作中，进度安排的落空不仅会造成项目开发成本的提高，造成有形的经济损失，而且会使客户的不满意度、不信任度增，造成有形的经济损失。
借助PERT技术和Gantt图方法可以方便地进行软件项目的进度安排。
项目组织是软件项目计划中与人直接相关的部分。
在软件开发过程中，人是最活跃的部分。
如何最大限度地发挥每个开发人员的工作效率是软件项目管理者应该积极重视的问题。
Rayleigh-Norden曲线，各类人员参与程度曲线，人员时间权衡定律和Brooks定律等人员组织规律值得软件项目管理者借鉴。
一些成功的组织形式，如民主小组、主程序员小组和层次小组，软件项目管理者可以根据项目的实际情况灵活运用。
一般软件项目计划在需求分析后才能正式定稿，在软件开发过程中可能还要随实际情况不断改变。
升级会员 