- 1、本文档共36页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第七章面向对象软件开发过程(1)统一过程模型UP介绍 提纲 §7a.1 UP的基本结构 §7a.2 UP的阶段 §7a.3 迭代增量式开发 §7a.4 核心工作流 §7a.5 最佳实践 §7a.6 UP工件 §7a.1 UP的基本结构 软件开发模型的出发点 如何更快(效率)更好(质量)地满足需求 使得开发过程在一种受控的方式下运行 过程←活动←任务 还需要涉及:项目、人员、工件 UP(Unified Process)是一个软件开发过程的框架 拥抱变化:用户反馈和适应调整逐步满足用户需求; 迭代增量式开发 用例驱动整个开发过程 提倡基于构件的软件体系结构为中心展开开发活动 §7a.1 UP的基本结构 UP科目(3e中) §7a.2 UP的阶段(初始阶段,inception) 初始阶段的目标是为系统建立商业案例和确定项目的边界。 项目边界的确定 识别外部角色,识别用例,描述主要用例;(系统应该为不同的用户提供什么?) 用户提出的非功能性要求描述。 系统的整体架构划分(子系统的划分),与外界环境的交互关系等。 商业案例(business case) 使用资源估计,包括项目的支撑环境; 估计潜在的风险; 对整个项目做最初的项目成本和日程估计 项目验收规范。 §7a.2 UP的阶段(初始阶段,inception) 初始阶段主要目标: 明确软件系统的范围和边界条件,包括从功能角度的构想(vision)分析、产品验收标准和哪些做与哪些不做的相关决定; 明确区分系统的关键用例和主要的功能场景; 展现或者演示至少一种符合主要场景要求的候选软件体系结构; 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出); 估计出潜在的业务风险(主要指各种不确定因素造成的潜在业务风险); 准备好项目的支持环境。 评审标准: 风险承担者就范围定义、成本/日程估计达成共识; 以客观的主要用例证实对需求的理解; 成本/日程、优先级、业务风险和开发过程的可信度; §7a.2 UP的阶段(初始阶段,inception) 初始阶段的产出: 构想文档:核心项目需求、关键特性、主要约束的总体构想; 原始用例模型(完成10%~20%); 原始项目术语表(可能部分表达为业务模型); 原始商业案例,包括商业背景、验收规范、成本预计等; 原始的业务风险评估; 一个或多个原型 §7a.2 UP的阶段(细化阶段,elaboration) 细化阶段的主要目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。 确保软件结构、需求、计划足够稳定,确保项目技术风险已经降低到能够预计完成整个项目的成本和日程的程度; 针对项目的软件结构上的主要技术风险已经解决或处理完成; 通过完成软件结构上的主要场景建立软件体系结构的基线; 建立一个包含高质量组件的可演化的产品原型; 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内; 建立好产品的支持环境。 §7a.2 UP的阶段(细化阶段,elaboration) 评审标准: 产品的构想是否稳定? 体系结构是否稳定? 可执行的原型版是否显示技术风险要素已被处理和可靠的解决; 构建阶段的计划是否足够详细和精确?是否被可靠的审核基础支持? 如果当前计划在现有的体系结构环境中被执行而开发出完整系统,是否所有的风险承担人同意该构想是可实现的? 实际的费用开支与计划开支是否可以接受? §7a.2 UP的阶段(细化阶段,elaboration) 细化阶段的产出: 用例模型(完成至少80%)……所有用例均被识别,大多数用例描述被开发; 补充捕获非功能性要求和未关联于特定用例要求的需求(补充规范) 软件体系结构描述 可执行的软件原型 经修订过的技术风险清单和商业案例 总体项目的开发计划,包括粗粒度的项目计划,显示迭代过程和对应的审核标准; 用户手册的初始版本(可选) §7a.2 UP的阶段(构造阶段,construction) 构造阶段:所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。 通过优化资源和避免不必要的返工达到开发成本的最小化; 根据实际需要达到适当的质量目标; 根据实际需要形成各个版本(α,β和release) 对所有必须的功能完成分析、设计、开发和测试工作; 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品; 确定软件、站点、用户都为产品的最终部署做好了相关准备; 达成一定程度上的并行开发机制。 §7a.2 UP的阶段(构造阶段,construction) 审核标准: 产品是否足够稳定和成熟地发布给用户? 是否所有的风险承担人准备好向用户移交? 实际费用与计划费用的比较是否仍可被接受? 构造阶段的产出: 特定平台上的集成产品; 用户手册; 当前版
文档评论(0)