软件过程改进与管理分析报告.ppt

统一开发过程 RUP简单介绍 敏捷开发 ARUP RUP RUP的核心概念 RUP的二维模型 RUP的四个阶段 RUP的核心工作流 RUP的优缺点 RUP的核心概念 角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。 活动：是一个有明确目的的独立工作单元。 工件：是活动生成、创建或修改的一段信息。 RUP的二维模型 RUP的四个阶段 RUP包括以下几个阶段： 起始阶段 细化阶段 构建阶段 交付阶段 每个阶段结束于一个主要的里程碑(Major Milestones)，每个阶段本质上是两个里程碑之间的时间跨度。 每个阶段包含一个或多个迭代 。 初始阶段(1) 本阶段的主要目标有： 明确软件系统的范围和边界条件，包括从功能角度的前景分析、产品验收标准和哪些做和哪些不做的相关决定。 明确区分系统的关键Use．case和主要的功能场景。 展现或者演示至少一种符合主要场景要求的候选软件体系结构。 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出。 估计出潜在的风险(主要指各种不确定因素造成的潜在风险)。 准备好项目的支持环境。 初始阶段(2) 本阶段的产出有： 蓝图文档：核心项目需求、关键特色、主要约束的总体蓝图。 原始用例模型(完成10％-20％)。 原始项目术语表(可能部分表达为业务模型)。 原始业务案例，包括业务的上下文、验收规范(年度映射、市场认可等等)，成本预计。 原始的风险评估。 一个或多个原型。 初始阶段(3) 初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。初始阶段的评审标准是： 风险承担者就范围定义、成本，同程估计达成共识。 以客观的主要用例证实对需求的理解。 成本／日程、优先级、风险和开发过程的可信度。 被开发体系结构原型的深度和广度。 实际开支与计划开支的比较。 细化阶段(1) 本阶段的主要目标有： 确保软件结构、需求、计划足够稳定：确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。 针对项目的软件结构上的主要风险己经解决或处理完成。 通过完成软件结构上的主要场景建立软件体系结构的基线。 建立一个包含高质量组件的可演化的产品原型。 说明基线化的软件体系结构可以保障系统需求控制在合理的成本和时间范围内。 建立好产品的支持环境。 细化阶段(2) 本阶段的主要产出是： 用例模型(完成至少80％)一一所有用例均被标识，大多数用例描述被开发。 补充捕获非功能性要求和非关联于特定用例要求的需求。 软件体系结构描述。 可执行的软件原型。 经修订过的风险清单和业务案例。 总体项目的开发计划，包括纹理较粗糙的项目训‘划，显示迭代过程和对应的审核标准。 指明被使用过程更新过的开发用例。 用户手册的初始版本(可选) 细化阶段(3) 细化阶段结束是第二个重要的里程碑：生命周期的结构里程碑，此刻，检验详细的系统和范围、结构的选择以及主要风险的解决方案。 主要的审核标准包括回答以下的问题： 产品的蓝图是否稳定? 体系结构是否稳定? 可执行的演示版是否显示风险要素已被处理和可靠的解决。 构造阶段的计划是否足够详细和精确?是否被可靠的审核基础支持? 如果当前计划在现有的体系结构环境中被执行而开发出完成系统，是否所有的风险承担人同意该蓝图是可实现的? 实际的费用开支与计划开支是否可以接受? 构造阶段(1) 本阶段的主要目标有： 通过优化资源和避免不必要的返工达到开发成本的最小化。 根据实际需要达到适当的质量目标。 据实际需要形成各个版本(Alpha，Beta和其他测试版本)。 对所有必需的功能完成分析、设计、开发和测试工作。 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品。 确定软件、站点、用户都为产品的最终部署做好了相关准备。 达成一定程度上的并行开发机制。 构造阶段(2) 本阶段的产出是可以交付给最终用户的产品，它最小包括以下几点： 特定平台上的集成产品。 用户手册。 当前版本的描述。 构造阶段(3) 构造阶段结束是第三个重要的项目里程碑(初始功能里程碑)。此刻，决定软件、环境、用户是否可以运作而不会将项目暴露在商度风险下。该版本也常被称为“beta”版： 构造阶段主要的审核标准包括回答以下的问题： 产品是否足够稳定和成熟得可以发布给用户? 是否所有的风险承担人准备好向用户移交? 实际费用与计划费用的比较是否仍可被接受? 交付阶段(1) 本阶段的目标是确保软件产品可以提交给最终用户。本阶段根据实际需要可以分为几个循环，本阶段的主要目标如下： 进行Beta测试以期达到最终用户的需要。 进行Beta测试和旧系统的并轨。 转换功能数据库。 对最终用户和产品支持人员的培训。 提交给市场和产品销售部门。 和具体部署相关的工程活动。 协调Bug修订、改进性能和可用性等工作。 基于完整的