软件过程框架与软件过程模型.ppt

* 3个核心支持工作流： - 配置和变更管理（Configuration Change Management） - 项目管理（Project Management） - 环境（Environment） * 初始阶段 - 目标是为系统建立商业企划（business case）并确定项目的边界。 - 商业企划包括项目的验收规范、风险评估、所需资源估计、阶段计划等。 - 要确定项目边界，需识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。 * - 阶段结束里程碑：生命周期目标（Lifecycle Objective）里程碑，包括一些重要的文档，如：项目构想（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始商业企划等。 需要对这些文档进行评审，以确定：正确理解用例需求、项目风险评估合理、阶段计划可行等。 * 细化阶段 - 目标是分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。 - 里程碑：包括：风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。 通过评审确定：软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。 * 构造阶段 - 将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。 - 里程碑：初始运行能力（Initial Operational Capability）里程碑。包括：可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。 通过评审确定：软件、环境、用户是否可以开始系统的运行。 * 移交阶段 - 移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。 - 里程碑：产品发布(Product Release)里程碑。 通过评审确定：最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。 * RUP通过迭代增量建模思想提高了风险控制能力，这体现在： ⑴ 迭代计划安排是风险驱动的，高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险； ⑵ 每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的； * ⑶ 每一个阶段结束时还有严格的质量评审，保证里程碑文档的质量； ⑷ 由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，所以，可以根据市场竞争的情况适时推出中间版本，降低市场风险。 * RUP的最佳实践： ⑴ 短时间分区式的迭代：2～6周，不鼓励时间推迟； ⑵ 适应性开发：小步骤、快速反馈和调整； ⑶ 在早期迭代中解决高技术风险和高业务价值的问题； ⑷ 不断地让用户参与迭代结果的评估，并及时获取反馈信息，以逐步阐明问题并引导项目进展； ⑸ 在早期迭代中建立内聚的核心架构。 * ⑹ 不断地验证质量；尽早、经常和实际地测试； ⑺ 使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。 ⑻ 可视化软件建模：使用UML（Unified Modeling Language，统一建模语言）进行软件建模。 ⑼ 仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。 ⑽ 实行变更请求和配置管理。 * RUP模型的优点 提高了团队生产力，在迭代的开发过程、需求管理、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。 RUP模型的缺点 RUP在理论上，是比较理想的，但在实际应用上，还需要更多的工具的支持和普及推广工作。 * 2. 敏捷模型 为了避免许多公司的软件团队陷入过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：Scrum，Crystal，特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发（Adaptive Software Develop