第4章-初始不是需求阶段.pptVIP

第4章 初始不是需求阶段Inception is not the Requirements Phase 第二部分 初始阶段 初始不是需求 初始阶段的目的是决定是否继续进行项目的开发，而不是定义需求。 只要关键的需求被调查 初始阶段关注的问题 项目的愿景(vision)是什么？ 有哪些业务案例(business case)? 项目是否可行？ 购买还是开发？ 粗略估计成本？ 在初始阶段结束时：要决定项目是否继续进行下去？ 一句话概括初始阶段 预见项目的范围、愿景和业务案例。 一句话概括初始阶段要解决的问题 涉众(stakeholders)是否就项目愿景基本达成一致，项目是否值得继续认真研究。 初始阶段持续的时间 可能只包含 第一次需求讨论会（2天） 制定第一次迭代计划（1天） 初始阶段会创建的制品 不是每个项目都需要完整的文档 愿景和业务案例 描述高阶目标与约束、业务案例，并提供执行摘要. 通常会对项目的预算有个大概的估算，并且会列出期望的收益。 用例模型(Use Case Model) 描述功能性需求 列出大部分所期望的用例的名称和参与者的姓名，在只有10% 的用例会被详细分析 不要混淆用例图和用例。用例是用文本描述的。 补充性规格说明Supplementary Specification 描述其它需求，主要是非功能性的需求 多考虑关键的非功能性需求. 词汇表(Glossary) 描述业务领域的关键术语和数据字典 风险列表和风险管理计划 包括可能遇到的风险的清单 包括业务、技术、资源和进度方面的风险，标出可能性和严重性. 所有主要的风险应该有应对和缓解的方法。 原型 / 概念验证 用来澄清愿景，验证技术思路 初始阶段的原型是抛弃型的原型，而不是进化型的。通常使用一些原型工具来建立。 迭代计划 描述第一个细化迭代的任务. 第一个迭代通常实现产品的核心功能。 在第一时间消除最大的风险。最糟糕的风险往往是：最终产品无法满足最重要的需求。 阶段计划 /软件开发计划 对细化阶段的持续时间和工作量进行粗略的估计，包括工具、人力、培训等。 又称为“资源计划” 开发案例Development Case 就特定项目，对UP步骤和制品进行定制的描述。 何时知道自己并不了解初始阶段 (遇到麻烦的信号) 进度 认为初始阶段应该持续几个星期 需求定义 在初始阶段试图定义大部分的需求. 精确估计 期望初始阶段的预算和计划是可行的 定义架构 应该在细化阶段以迭代的方式来定义架构 瀑布法思想 认为正确的工作顺序应该是 定义需求 设计架构 实现产品 没有业务案例或愿景制品 用例 认为应该详细编写所有的用例. 认为不用编写详细用例 应该详细编写10 or 20% 用例 *