RUP开发阶段及里程碑分析.ppt

预备概念(1) 风险(risk) 项目遭遇危险和失败的可能因素，如进度拖延、费用超支、现有技术难以实现等等。分为技术性风险和非技术性风险。 构造(build) 系统的一个可执行版本，开发通过一系列的构造过程来完成。 配置管理(configuration management) 定义和维护制品的配置和版本，配置管理包括制品的基线定义、版本控制、发布控制，状态控制和存储控制。 预备概念(2) 发布(release) 一组相对完整、一致的、交付给内部或外部用户的制品。 增量(increment) 通常指两个相邻的构造之间的差异。每次迭代至少产生一个(新的)构造块，从而向系统增加一个增量。 次要里程碑(minor milestone) 两个主要里程碑之间的中间里程碑，例如某次迭代结束时的里程碑。 RUP生命周期阶段 主要里程碑(major milestone) 到达 项目的每个阶段都由一个主要里程碑标志结束。标志着项目相关人员都一致认可项目达到里程碑准则。 前进 同时，管理层把主要里程碑作为一个同步点，对项目是否进入下一阶段作出决策。 各阶段的工作人员和工作流 各阶段所需要的资源(成本+时间) 生命周期中的迭代 迭代：按照迭代计划和评估标准产生一个(内部或外部)发布版本所进行的一组明确的活动，所得到的发布是最终产品的一个子集。 一般迭代工作流 是从四个阶段的不同迭代中提炼出的一般迭代模式，并以此为基础创建具体的迭代 一般迭代工作流包括 迭代计划 迭代时间 制定每次迭代所需要的时间和完成日期 迭代内容 识别，转化并降低风险 实现哪些用例 期望的输出(制品) 职责分配 资源的分配 制定评估准则 用例优先级排序 每次迭代都是由一些用例来驱动的 对已识别的用例按风险大小进行排序，形成用例排序清单 保证用例间的开发逻辑次序 最后确定本次迭代中需要实现的用例 风险管理 拟定风险清单 风险描述、优先级、监控者、职责、应急措施… 风险排序 必须对风险排序，不要将所有的风险都视为重点 技术风险管理 转化为用例，并放入用例清单中的适当位置 迭代的评估 负责人 项目经理负责评估工作 目标 检验已完成内容是否满足预定的评估准则 审查项目进展情况 目的 利用本次迭代结果和经验，指导下一次迭代 修正下一次迭代计划 评估未达标时的处理 下一次迭代中完成评估准则 修改或扩充用例模型 修改或扩充构架 为开发组添加某些必要技能和知识 … 延长本次迭代时间，并制定固定的完成日期 初始阶段概述 任务 确定目标系统范围 了解项目所包括的业务内容 定义风险的寻找范围 规定业务案例中费用、开发进度和投资回报等因素的评估范围 目标 生成业务案例的第一个草案 证明项目是可启动的 制定初始阶段计划 制定一个试验性的(tentative)计划，满足与初始目标有关的需求 制定一个创建候选框架的计划，使得创建的构架能确定项目是切实可行的 设立评估准则 是否清楚哪些部分在系统之内 已识别出的用例是否已经被详细描述 构架是否能满足用户的需要 是否已识别出所有的关键风险 已识别的风险是否已经缓解，或制定缓解的计划 业务案例草案是否能证明项目可继续进行 初始阶段的迭代工作流 初始阶段的主要活动 捕获需求 列出作为系统特征清单的候选需求 理解系统语境，建立业务模型(或领域模型) 以用例形式捕获功能性需求 捕获有关非功能性需求 以用例捕获需求 确定参与者和用例 确定制定构架所需要的用例 区分用例的优先级 对已经识别的用例按照风险大小和实现顺序排列 详细描述识别的用例 通过详细描述用例来发现关键的需求 构造用户界面原型构造用例模型 最小化执行 分析 构架分析 为实现初始阶段的目标挑选出适当的用例集合，为系统构造出最初的构架模型 分析用例 逐个分析，以及考虑多个用例共享系统资源(数据库、计算资源等)的情况 分析一个类和分析一个包 最小化执行 设计 构架设计 勾画出候选构架的设计模型轮廓 用子系统/类间的协作(接口)来实现需求分析工作流中识别的用例 包括用例的功能性需求和非功能性需求(意味着风险) 设计一个用例设计一个类和一个子系统 最小化执行 实现和测试 是否进入实现工作流取决于项目经理的决定 有人认为只有用户看到原型的运行，才能确信候选构架的功能 有人认为只要有(被经验丰富的开发人员)一看上去可以工作的构架，就可以停止本次迭代工组流 实现演示原型或概念性证明原型 由于探索性原型主要用作说明，不必做大量测试 初始阶段迭代的评估 评估小组 由用户代表和开发人员代表组成，最少2人 评估准则 系统范围：是否达到用例模型应该完成的程度 候选构架：探索性概念证明原型的演示效果是否被接受 关键风险：已识别的风险是否被充分缓解 评估结果 最重要结果就是决定继续开发还是取消开发 初始阶段的关键可交付内容 系