11 配置管理计划
配置管理计划详见配置管理计划专题.
12 项目风险计划
风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间、资源和预算完成产生重大影响。风险分析的目标是识别这些事件，设法避免这些事件的发生并制定一旦这些事件发生后的处理措施。表2是本项目风险计划清单表。
表2：风险分析表
排序 1 输入 客户的SOW 风险事件 需求不明确，增加需求，导致需求蔓延 可能性 70% 影响 50% 风险值 35% 风险应对措施 1．采取加班的方法 2．修改计划去掉一些任务 3．与客户商量延长一些时间 2 合同 进度要求紧，合同金额有限 30% 50% 15% 可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度. 4 WBS 供货商、外包商的质量问题 20% 50% 10% 多选择几个可以作为备份的外包商和供应商 5 历史项目信息 开发人员的流动 15% 60% 9% 1．注意项目团队的沟通，及时了解开发人员的动态 2．控制好项目过程中的文档 3.从其他的项目组借调人员 4．从外部招聘有过此类开发经验人员
13.度量计划
详见度量计划专题 14 项目沟通与评审
项目评审的主要目的是根据项目计划对项目的执行活动进行检查，及时发现问题，研究解决对策，纠正偏差，保证项目的顺利实施。项目交流计划分为如下几类：
- 每天17:00的沟通交流 - 定期评审 - 阶段评审 - 事件评审
各类交流评审安排见表3。
表3:项目管理交流计划
评审类别 日例会 评审周期 每天17:00-17:30 评审要点 1. 不限定主题和内容,随意相关人员 项目组所有人 交流 2. 共享经验,避免错误 定期评审 (周例会) 每周五 3. 本周工作进度 4. 问题及对策 5. 资源协调 6. 下周工作安排 项目经理 开发经理 质量经理 配置管理员 项目主管 项目经理 开发经理 阶段评审 阶段结束 1. 本阶段计划执行情况 2. 质量评审结果 3. 产品审计结果 4. 下阶段计划修正 质量经理 配置管理员 市场人员 事件评审 当事件可能影响计划的执行 1. 事件性质和影响范围 2. 事件处理方案的讨论 3. 修改计划的评审时间 项目经理 开发经理 质量经理
案例说明-《校务通管理系统》的生存期模型
针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下：
1． 校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此
可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2． 在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可
以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”；资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3． “系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂
其它功能模块”。也说明用户可能会增加新的需求。 4． 对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用
校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5． 本项目具备增量式模型的其他特点
a) 项目复杂程度为中等。 b) 预计开发软件的成本为中等。
c) 产品和文档的再使用率会很高, d) 项目风险较低
生存期中的各阶段定义如下：
项目规划阶段
阶段目标： 根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。
输入：
合同文本 SOW
项目规划，计划确认 项目计划
过程： 输出：
需求分析阶段 阶段目标：确定客户的需求 输入： 过程： 输出：
设计阶段 阶段目标：
输入： 过程： 输出：
增量1实现
阶段目标： 输入：
过程： 输出：
增量2实现
阶段目标： 输入：
项目计划，SOW
需求获取，需求分析，需求控制 原型系统，需求规格
总体系统结构设计 原型系统，需求规格 总体设计
系统设计说明书，数据库结构定义
实现系统的通用功能 系统设计说明书 数据库结构定义
详细设计,编码，代码走查，代码评审，单元测试详细设计说明书，源代码，可运行版本－1
实现系统的招生管理功能 系统设计说明书 数据库结构定义