实用软件工程方法10.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 创建主项目进度（1） 估算技术 对人的任命；技术的成熟度；系统的复杂性；环境的稳定性；所用开发工具；调整和分析工具的可用性；协调技术和小组技术水平的关系；小组动态性；可重用性的机遇；客户的期望值；设计的灵活性和模块性；企业文化 任务层次上的估算指南 小组的领导人实施任务分解和定优先级；由小组成员作任务层次上的估算；每个任务都有一个起始和结束点；产生一个单独的产品或工作产品；任务要分配到个人；为了反馈和改正及时，任务的粒度可调整（约半天到一周） 创建主项目进度（2） 容许的不确定性 建立开发和测试环境 10.2 调度原则 微软总结了大量调度实践中的经验提出以下四条原则： 估算工作量由底向上 上市日期坚定不动的意识 风险驱动调度 为不确定的未来调度 估算工作量由底向上 谁做这个工作，就由谁去推断这个工作需要的时间，应该是一个基本的信条。当然，精确不是目标，任何人都有预断不到之处 ——Jim McCarthy《软件开发动力学》 上市日期坚定不动的意识 一旦商定项目产品的上市日期决不轻易更改 有利于培养员工的意志品质：“言而有信” 任何工作失误都会导致资源（成本）增加 风险驱动调度 把注意力集中在优先级最高的风险上，并按优先级安排任务 风险驱动的调度还鼓励尽早在概念上证实原型 较大的风险一般起因是在上层或最上层，而缓解和消除必须在下层做切实的工作 为不确定的未来调度 未来是不确定的 为了使不确定变为相对确定一些，人们把大任务化小是常用的办法 使用离散任务 设立中间里程碑（interim milestone） 增加缓冲时段。 使用离散任务 大任务化为相对独立的小任务 如果无法化小，那么就建立中间里程碑 使用离散任务的好处 持续时间短，出错的余地小；出了问题影响面小，易于控制；任务小，工作量估算容易精确 设立中间里程碑 可以把大的功能集分解为若干小的功能集，作为中间里程碑 这些小的功能集越独立越好 在中间里程碑评估项目进展，并调整项目计划 把每个中间里程碑当作一次实际的发布 增加缓冲时段 不仅可留出处理偶发因素的时间，对于保证按时完成也是必须的，它还有助于允许角色或小组的隐私 设立项目缓冲时段 10.3 计划阶段的成功标准 干系人和项目组针对项目就以下几点达成一致： 要交付的解决方案组件 主要项目里程碑的日期 如何构建解决方案 创建好开发和测试环境 开始对项目进行变更控制和配置管理 发起人和（或）主要干系人正式认可本阶段的交付成果和完成的工作 10.4 计划阶段文档 项目计划阶段的工作产品 工作产品 目的 责任者 功能规范文档 描述要做什么 程序管理 主项目计划 描述怎么做 程序管理 主项目进度表 描述何时做 程序管理 复审主风险评估文档 描述在制作中的任何问题 程序管理 功能规范文档 功能规范文档的内容 功能规范的作用 功能规范文档编制指南 功能规范文档常见的缺陷 功能规范审核 范文档（1） 功能规范文档的内容 内容 解释 远景概述 远景文档总结，以及解决方案的业务环境 设计目标 影响决策的关键设计目标，包括性能、可靠性、时限、可访问性、可用性 产品需求 客户/用户的需求，包括优先需求和冲突平衡 用户概述 按业务案例说明谁在什么时候用到本产品的什么 功能特性 按优先级排出的产品功能特性及其功能，说明包括用户界面、导航 产品依赖性 高层依赖是外部系统，底层依赖是共享组件 进度总结 主项目进度表的概述，关键的日期及其工作产品，上市日期 风险 风险列表 附录 设计过程的输出 功能规范文档（2） 功能规范的作用 功能规范是开发主项目计划，主进度表的基础 功能规范记录了项目组和客户/用户达成的共识 功能规范文档编制指南 要理解本规范文档使用者的需要 风格一致 不要想一次成，要多次反复，收集反馈 明确写出产品，功能特性是什么 找出核心的功能特性集，以及产品改进和新版本的生成 将已明确的项目变量转变成设计目标功能规范文档常见的缺陷 功能规范文档（3） 功能规范文档常见的缺陷 提供细节不足 提供细节过多 做了过多的不实际的设计 冻结过早 更新过频耗时太多 失于交流变更 整个小组成员没有充分参与 功能规范文档（4） 功能规范审核 角色 准则 客户 解决方案满足了业务需求 产品管理 解决方案满足了已知需求 程序管理 落实了小组的职责和进度 开发 解决方案是可以实现的 测试 解决方案是测试的并有可能稳定 用户体验 解决方案是可用的，所需要的用户