第4章项目范围计划..pptVIP

软件开发项目WBS范例 1. 产品需求阶段 1.1 产品需求文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 签署 1.2 结束产品需求阶段 2. 软件需求阶段 2.1 软件需求文档 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 2.2 软件验收测试计划 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 2.3 结束软件需求阶段 3.体系结构设计阶段 3.1 体系结构设计文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 签署 3.2 软件集成测试计划 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 3.3 结束体系结构设计阶段 4.详细设计阶段 4.1 详细设计文档 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 4.2 软件单元测试计划 研究, 编写, 分发, 个人评估, 评审会议, 更新/修改文档, 重新分发, 第二次评审, 签署 4.3 结束详细设计阶段 5. 编码阶段 5.1 生成代码单元 编写代码单元 编译代码单元 链接代码单元 走查代码单元 为走查做准备 进行走查 更新修改代码 签署走查结果 代码单元文档 5.2 结束编码阶段 6. 单元测试阶段 6.l 单元测试代码 准备测试计划和测试案例集 测试代码 修正代码 重新测试代码 准备单元测试文档 6.2 结束单元测试阶段 7.集成测试阶段 7.1 代码集成测试 系统集成测试计划没有覆盖到的任何测试计划和测试案例集都属于代码集成测试 测试代码 修正代码 重新测试代码 准备集成测试文档 7.2 结束集成测试阶段 8.系统测试阶段 8.1 执行内部软件验收测试计划 8.2 结束系统测试阶段 9.发布阶段 9.1 安装 计划；活动；测试；记录结果 9.2 数据转换 计划；活动；测试；记录结果 9.3 评审 9.4 软件发布 9.5 结束发布阶段 10. 操作和维护阶段 10.1 评价 10.2 设计评审 10.3 支持和维护 10.4 审计 11. 项目生命周期中的其他可能用到的WBS元素 11.1 培训 项目人员的互相熟悉；项目人员的培训；用户培训 11.2 招聘 11.3 测试环境开发 为软件开发人员提供的开销 11.4 开发支持 数据库管理；开发环境；系统构造 11.5 项目管理 11.6 配置管理 评估；正在进行中的配置管理 11.7 文档记录 11.8 质量管理和质量计划 评审 用户（不同类型） 管理者 发行简介 技术手册，也就是描述软件如何工作的手册 帮助文本 为软件开发人员提供的开销 * 例子 一个建筑物的钢架结构及地基或州际高速公路的物理结构包含了前四个特性， 但它们不是系统；它们什么事情也不做，只是“坐”在那里，它们本身没有动 力，也没有自运作特性。但当把构建它们的对象加进去时，这些结构就成为了 一个总体系统的一部分。将人、车辆、加油站、交通规则（及其实施）一起加 进来以后，高速公路就变成了一个可以运输人和货物的高速公路系统。 * 基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。 * 即动态系统（dynamic system）整体运作的微妙特性。 　　一、今日的问题来自昨日的解：有些解决问题的方式，只是把问题从系统的一个部分推移到另一部分，当事者不能察觉，可能是因为系统中解决第一个问题者和承接新问题者经常不是同一人。 　　二、愈用力推，系统反弹力量愈大：补偿性回馈（compensating feedback）：善意的干预引起了系统的反应，但这反应反过来抵消干预所创造的利益。 　　三、渐糟之前先渐好：不良后果延时产生前的短暂改善假象常使我们错估决策的有效性。 　　四、显而易见的解往往无效：不寻求真正的原因，而固执地推动熟悉的解决方案，不可能产生根本改善。 　　五、对策可能比问题更糟：舍本逐末，干预产生的短期改善可能导致长期依赖，任何长期解决方案必须增强系统肩负自己担子的能力。 　　六、欲速则不达：违反规律的求快不可取。 　　七、因与果在时空上并不紧密相连：易误判诱因。 　　八、寻找小而有效的高杠杆解：以小而专注的行动，产生重大、持久的改善。观察变化的全程，而非以静态方式、或固定点的思考。 　　九、鱼与熊掌可以兼得：许多看似进退两难的矛盾（如低成本与高品质）往往是由