软件项目计划范文.doc_第1页
软件项目计划范文.doc_第2页
软件项目计划范文.doc_第3页
软件项目计划范文.doc_第4页
软件项目计划范文.doc_第5页
已阅读5页,还剩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图方法。 1PERT技术PERT技术(Program Evaluation&Review Technique,PERT)又叫计划评审技术。 20世纪50年代后期,美国海军和洛克希德公司首次提出这一技术,并成功地应用于北极星导弹的研究和开发。 几十年来,它在许多工程领域获得了广泛的应用,有时也因此称之为工程网络技术。 2Gantt图方法Gantt图,又称横道图,用水平线段来描述各作业的进度安排。 一般在每一作业的起始时刻和约束时刻各画一个小三角形,当作业开始或结束时,把小三角形涂黑。 Gantt图的横轴列出的是日历时间,纵轴列出的是作业名称。 3.3项目组织教学内容人员组织规律、人员组织形式。 教学重点人员时间权衡定律、Brooks定律。 教学难点矩阵模式组织结构。 教学方法课堂讲授。 教学要求了解人员组织规律,熟悉人员组织形式。 思考题为何向已经延期的项目增加开发人员反而会使项目更加延期?为何软件开发人员应该少而精?3.3.1人员组织规律对于一个软件项目而言,单个软件专业人员不可能在有限时间内单独完成。 如何合理地组织这些人员参与软件的开发是项目成败的关键。 为此,软件项目管理者应该重视软件项目的人员组织规律,不能简单地对待。 1Rayleigh-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人兼任组长。 民主小组的最基本概念是“无我程序设计”(egoless programming),人人把小组开发的程序看成是“我们的”程序,而不是“我的”程序。 遇到问题时,组员之间可以平等地交换意见,从而可以充分发挥每个成员工作的积极性。 (3)层次小组在层次小组内,人员分成三个层次项目负责人(组长)1人,负责全组的工作,直接管理2-3名高级程序员;每位高级程序员下属若干名程序员,负责子课题的有关工作。 3.4小结软件项目计划是继可行性研究之后软件工程管理的重要组成部分,主要内容包括风险分析、进度安排和项目组织。 风险分析是软件项目计划的一个主要成部分之一。 当对软件项目期望很高时,均会进行风险分析活动,不过大多数软件项目管理者会非正式地完成它。 标识、估计、评价和管理风险有可能会占用较多的项目计划工作量。 但由于经过风险分析,能够做到“知已知彼”(彼即风险),从而“百战不殆”,使得开发者能够战胜风险带来的损失,使项目成功。 进度安排是软件项目计划的关键组成部分。 实际工作中,进度安排的落空不仅会造成项目开发成本的提高,造成有形的经济损失,而且会使客户的不满意度、不信任度增,造成有形的经济损失。 借助PERT技术和Gantt图方法

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论