RUP Public.pptVIP

IBM 如何使用 IRUP 来迭代化地开发软件产品 标题 IRUP 概念简述 迭代的实际应用 迭代带来的转变 有关迭代的常见错误分析 总结 IRUP 简述 P?UP?RUP?IRUP??RUP P Process: 过程 UP Unified Process: 统一过程 RUP Rational Unified Process: 最佳实践集合 IRUP IBM Rational Unified Process ?RUP 定制, 实现和扩展最佳实践 IRUP 简述 软件开发的问题 用户或商业愿望没有满足 需求持续变动, 无法确定 模块无法集成 难于维护 缺陷发现太晚 质量差 性能和可扩性差 部门无法有效协同 生产和发布的管理不足 IRUP 的主要特征 IRUP的主要特征： 迭代式软件开发 以架构为核心的软件开发 用例驱动的软件开发 风险驱动的软件开发 IRUP 包含了以下方面来支持或提高其他软件开发方法: 过程 Processes 技术 Techniques 技巧 Tips 模板 Templates 工具指导 Tool mentors IRUP： 阶段（Phase）、规程（Disciplines）及迭代 迭代与瀑布开发模式的对比 瀑布式 迭代式 迭代开发的四个阶段 初启: 确立目标和范围 远景，框架需求及业务用例 无需提供详细需求 精化: 确立架构并解决主要风险 架构基线，实现部分关键功能 无需提供详细设计 构建: 系统完成，可移交用户初步使用 全功能的Beta版本 移交: 验证，最终实现产品 干系人（Stakeholder）验收通过，交接产品 迭代的实际应用 标题 迭代之前要做什么？ 迭代中应包含什么？ 如何确定迭代周期和数量？ 不同的迭代策略 迭代案例 实践体会 迭代之前要做什么？ 多方合作制定需求，确保需求具有一定的准确性。 制定需求的优先级列表及风险分析 市场风险 开发风险 依赖关系（开发、测试。。。） 其它。。。 将优先级列表分解成项目的交付件 将可交付物分布到各个迭代中 制定并交付IRUP总体计划及下一次详细迭代计划 迭代中应包含什么？ 在每次迭代中，以下事项需被定义并获得干系人（Stakeholder）同意： 开始及结束时间。 本次迭代中所包含的需求及在本次迭代中需要解决的缺陷列表 确定本次迭代所关注的重点以在此次迭代中正确指引、管理团队 迭代中所需的活动： 原则上包含所有科目，但在每一个迭代中的侧重点不同。 本次迭代的主要交付物： Use case描述 用例的补充规范说明 被验证通过的测试用例 （如：UT, UIT, FVT, SVT) 程序代码 相关文档 针对下一次迭代的风险分析 退出条件 迭代结束时必须产生一个满足本此迭代需求的可运行的发布版本 如何确定迭代的周期及数量？－ 周期 根据具体项目的规模和复杂度，典型的迭代为2-8个星期 Timebox模式 固定的周期以确保各团队同步及计划的易执行性 影响迭代周期主要有以下因素： 软件公司的规模、团队的稳定性和软件开发能力成熟度 对迭代化流程的熟悉程度 项目的大小 项目中所采用技术的复杂度 软件开发的自动化程度：管理代码、发布信息、功能/性能测试等 本次迭代中Use-Case的数量 上一次迭代中所包含开发内容的多少 迭代周期是否能足够获得反馈 如何确定迭代的周期及数量？－ 数量 迭代数量与迭代周期的相关性 经验值：6 ± 3 各阶段工作量和时间的可能分布（中型项目） 迭代案例分析（一）在迭代中如何筛选需求 在构建阶段还剩余 2 个迭代 C3 和 C4.仍剩余以下四组任务（每组已指定优先级和风险级别）。假设每组任务工作量相同，每个迭代可以包含两组任务，请问每个迭代中应包含哪些任务？ A1, A2 – 低优先级, 低风险 B1, B2 - 高优先级, 低风险 C1, C2 - 高优先级, 高风险 D1, D2, D3 - 低优先级, 高风险 迭代案例分析（一）在迭代中如何筛选需求 迭代必须按时结束（Time Boxed） 情景提示： A1, A2 – 低优先级, 低风险 B1, B2 - 高优先级, 低风险 C1, C2 - 高优先级, 高风险 D1, D2, D3 - 低优先级, 高风险 迭代 C3 C1, C2, B1, B2 提示：应该尽早包含高优先级和高风险的任务 迭代 C4 D1, A1, A2, + 预留的时间以解决来自于迭代C3的问题 如果时间、工作量允许的话可以考虑加入任务D2. 把任务D3排除在计划之外. 提示： 将低优先级的事情排在计划后面。 一次迭代应考虑上次迭代可能遗留的问题。 实践体会 如果6周为一个迭代周期，建议: 1 周用于计划，分析和设计；3－4周用