软件项目管与计划.ppt

* * 风险评价的步骤 多数情况中，参照点不是一条平滑的曲线，而是一个区域，这个区域可能是易变动的区域，在这些区域内想要作出基于参照值组合的管理判断往往是不准确的。因此，在做风险评价时，按以下步骤执行： （1）为项目定义风险参照水准。 （2）尝试找出在每个[ri，li，xi]和每个参照水准之间的关系。 （3）预测参照点，定义一个终止区域，用一条曲线或一些易变动区域来界定。 （4）努力预测复合的风险组合将如何形成一个参照水准。 * * 19.4.4 风险驾驭和监控 风险驾驭步骤： （1）与现在在职的人员协商，确定人员流动的原因（如工作条件差、收入低、人才市场竞争等）。 （2）在项目开始之前，把缓解这些原因（避开风险）的工作列入已拟定的驾驭计划中。 （3）当项目启动时，做好人员流动会出现的准备。采取一些办法以确保人员一旦离开时项目仍能继续（削弱风险）。 （4）建立项目组，以使大家都了解有关开发活动的信息。 * * （5）制定文档标准，并建立一种机制以保证文档能够及时产生。 （6）对所有工作组织细致的评审（以使更多的人能够按计划进度来完成自己的工作）。 （7）对每一个关键性的技术人员，要培养后备人员。 * * 图19-6表示风险驾驭步骤要写进风险驾驭与监控计划RMMP（Risk Management and Monitoring Plan）。RMMP记叙了风险分析的全部工作。 图19-6 风险驾驭与监控 * * RMMP的主要内容 图19-7 风险驾驭与监控计划概要 * * 风险监控的三个主要目标 （1）判断一个预测的风险事实上是否发生了。 （2）确保针对某个风险而制定的风险消除步骤正在合理地实施。 （3）收集可用于将来的风险分析的信息。 实际上，项目中发生的问题总能追踪到许多风险。风险监控的另一项工作就是要把“责任”（什么风险导致问题发生）分配到项目中去。虽然风险分析会增大成本，但是相对于因为严重的风险发生而没有采取有效的措施造成的项目损失来说，这些工作量花得值得。 * * 19.5 进度安排 软件开发项目的进度安排有两种考虑方式： （1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成。 （2）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。 * * 19.5.1 软件开发小组人数与软件生产率 在软件开发中，生产率和人数往往是成反比的。在通常情况下，一个人的开发小组效率是最高的。主要的原因是减少了人员之间的通信和理解工作量。但是，不可能让一个人工作10年，而是让10个人工作1年去进行软件开发。因此，需要多人组成开发小组共同参加一个项目的开发。多个人开发同一个项目会产生通信问题，对接口、设计的理解。通信需花费时间和代价，降低软件生产率。 但是小组这种软件开发形式便于开展质量保证活动，可以获得更完善的软件分析与设计，从而减少因为软件分析引起的错误数，从而降低测试工作量。 * * 19.5.2 任务的确定与并行性 当参加同一个软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。 图19-8 软件项目的并行性 * * 19.5.3 制定开发进度计划 表19-3 进度分配百分比表 表19-4 更精确的进度分配表 阶段 需求分析 设计 编码与单元测试 组装与测试 占开发时间的百分比 10~30 17~27 25~60 16~28 总体类型 阶段分配 规模（KDSI） ? 微型 ＜2 小型 8 中型 32 大型 128 特大型 512 组织型 计划与需求 设计 编码与单元测试 组装与测试 10 11 12 17 ? 19 19 19 19 ? 63 59 55 51 ? 18 22 26 30 ? 半独立型 计划与需求 设计 编码与单元测试 组装与测试 16 18 20 22 24 ? 24 25 26 27 28 ? 56 52 48 44 40 ? 20 23 26 29 32 ? 嵌入型 计划与需求 设计 编码与单元测试 组装与测试 24 28 32 36 40 ? 30 32 34 36 38 ? 48 44 40 36 32 ? 22 24 26 28 30 ? * * 19.5.4 进度安排的图形方法 甘特图（Gantt Chart）是常用的多任务安排工具。用水平线段表示任务的工作阶段，用垂直线表示当前的执行情况；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间。 在甘特图中，任务完成的标准是以应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图的优点是标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。缺点是难以反映多个任