软件项目计划_第1页
软件项目计划_第2页
软件项目计划_第3页
软件项目计划_第4页
软件项目计划_第5页
已阅读5页,还剩1页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

温馨提示

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

评论

0/150

提交评论