第6章 软件管理文档.doc

实用软件文档写作 实用软件文档写作 实用软件文档写作第6章 实用软件文档写作 软件管理文档 6.1 管理文档概述 图6.1 管理文档的作用 图6.2 管理文档的组成 6.2 项目开发计划 6.2.1 项目开发计划书 6.2.2 工作分解结构 ref SHAPE 图6.3 工作分解结构 6.2.3 项目里程碑与阶段性文档 图6.4 需求过程中的里程碑 6.2.4 项目进度 图6.5 项目进度过程 6.2.5 运用图和表描述项目进度 表6.1 任务的持续时间及其依赖关系 任 务 持续时间（天数） 依 赖 关 系 T1 8 T2 15 T3 15 T1（M1） T4 10 T5 10 T2,T4（M2） T6 5 T1,T2（M3） T7 20 T1（M1） T8 25 T4（M5） T9 15 T3,T6（M4） T10 15 T5,T7（M7） T11 7 T9（M6） T12 10 T11（M8） ref SHAPE 图6.6 活动网络 图6.7 活动条形图 表6.2 任务—开发人员分配表 任 务 开 发 人 员 任 务 开 发 人 员 T1 人员1 T7 人员5 T2 人员2 T8 人员3 T3 人员1 T9 人员1 T4 人员3 T10 人员2 T5 人员4 T11 人员3 T6 人员2 T12 人员3 图6.8 人员分配及时间表 6.2.6 风险管理 表6.3 一些可能出现的典型的风险 风 险 风 险 类 型 描 述 职员跳槽 项目 有经验的职员未完成项目就跳槽 管理层变更 项目 不同的管理层考虑、关注的事情会不同 硬件缺乏 项目 项目所需的基础硬件没有按期交付 需求变更 项目和产品 软件需求与预期的相比，将会有许多变化 描述延迟 项目和产品 有关主要的接口的描述未按期完成 低估了系统规模 项目和产品 过低估计了系统的规模 CASE工具性能较差 产品 支持项目的CASE工具达不到要求 技术变更 业务 系统的基础技术被新技术取代 产品竞争 业务 系统还未完成，其他有竞争力的产品就已经上市了 SHAPE 图6.9 风险管理过程 表6.4 风险及风险类型 风 险 类 型 可能的风险 技术 系统使用的数据库的处理速度不够快 要复用的软件组件有缺陷，限制了项目的功能 人员 招聘不到符合项目技术要求的职员 在项目的非常时期，关键性职员生病，不能发挥作用 职员所需的培训跟不上 机构 重新进行机构调整，由不同的管理层负责这个项目 开发机构的财务出现问题，必须削减项目预算 工具 CASE工具产生的编码 CASE工具不能被集成 需求 需求发生变化，主体设计要返工 客户不了解需求变更对项目造成的影响 估算 低估了软件开发所需要的时间 低估了缺陷的修补率 低估了软件的规模 表6.5 风 险 分 析 风 险 出现的可能性 后 果 开发机构的财务出现问题，必须削减项目预算 小 灾难性 招聘不到符合项目技术要求的职员 大 灾难性 在项目的非常时期，关键性职员生病 中等 严重 要复用的软件组件有缺陷，限制了项目的功能 中等 严重 需求发生变化，主体设计要返工 中等 严重 开发机构重新调整，由新的管理层负责该项目 大 严重 系统使用的数据库的处理速度不够快 中等 严重 低估了软件开发所需要的时间 大 严重 CASE工具不能被集成 大 可容忍 客户不了解需求变更对项目造成的影响 中等 可容忍 职员所需的培训跟不上 中等 可容忍 低估了缺陷的修补率 中等 可容忍 低估了软件的规模 大 可容忍 CASE工具产生的编码效率低 中等 可以忽略 表6.6 风险管理策略 风 险 策 略 机构的财务问题 拟一份简短的报告，提交高级管理层，说明这个项目将对业务目标有重大贡献 职员招聘问题 告诉客户项目潜在的困难和延迟的可能性，检查要买进的组件 职员生病问题 重新对团队进行组织，使更多工作有重叠，员工可以了解他人的工作 有缺陷的组件 用买进的可靠性稳定的组件更换有潜在缺陷的组件 需求变更 导出可追溯信息来评估需求变更带来的影响，把隐藏在设计中的信息扩大化 机构调整 拟一份简短的报告，提交高级管理层，说明这个项目将对业务目标有重大贡献 数据库的性能 研究一下购买高性能数据库的可能性 低估开发时间 对要买进的组件、程序生成器的效用进行检查 表6.7 风 险 因 素 风 险 类 型 潜在的特征 技术 硬件或支持软件延迟交付，暴露出来许多技术问题 人员 员工士气低靡，团队成员的关系不协调，工作分配不当 机构 机构内说三道四，缺乏资深管理人员 工具 团队成员不愿使用工具，抱怨