《第7章面向对象软件开发过程-UP介绍》由会员分享，可在线阅读，更多相关《第7章面向对象软件开发过程-UP介绍（36页珍藏版）》请在金锄头文库上搜索。
1、1,第七章面向对象软件开发过程（1)统一过程模型UP介绍,2,提纲,7a.1 UP的基本结构7a.2 UP的阶段7a.3 迭代增量式开发7a.4 核心工作流7a.5 最佳实践7a.6 UP工件,3,7a.1 UP的基本结构,软件开发模型的出发点如何更快（效率）更好（质量）地满足需求使得开发过程在一种受控的方式下运行过程活动任务还需要涉及：项目、人员、工件UP（Unified Process）是一个软件开发过程的框架拥抱变化：用户反馈和适应调整逐步满足用户需求；迭代增量式开发用例驱动整个开发过程提倡基于构件的软件体系结构为中心展开开发活动,4,7a.1 UP的基本结构,5,UP科目（3e中）,6
2、,7a.2 UP的阶段（初始阶段，inception）,初始阶段的目标是为系统建立商业案例和确定项目的边界。项目边界的确定识别外部角色，识别用例，描述主要用例；（系统应该为不同的用户提供什么？）用户提出的非功能性要求描述。系统的整体架构划分（子系统的划分），与外界环境的交互关系等。商业案例（business case）使用资源估计，包括项目的支撑环境；估计潜在的风险；对整个项目做最初的项目成本和日程估计项目验收规范。,7,7a.2 UP的阶段（初始阶段，inception）,初始阶段主要目标：明确软件系统的范围和边界条件，包括从功能角度的构想(vision)分析、产品验收标准和哪些做与哪些不做
3、的相关决定；明确区分系统的关键用例和主要的功能场景；展现或者演示至少一种符合主要场景要求的候选软件体系结构；对整个项目做最初的项目成本和日程估计（更详细的估计将在随后的细化阶段中做出）；估计出潜在的业务风险（主要指各种不确定因素造成的潜在业务风险）；准备好项目的支持环境。评审标准：风险承担者就范围定义、成本/日程估计达成共识；以客观的主要用例证实对需求的理解；成本/日程、优先级、业务风险和开发过程的可信度；,8,7a.2 UP的阶段（初始阶段，inception）,初始阶段的产出：构想文档：核心项目需求、关键特性、主要约束的总体构想；原始用例模型（完成10%20%）； 原始项目术语表（可能部分
4、表达为业务模型）；原始商业案例，包括商业背景、验收规范、成本预计等；原始的业务风险评估；一个或多个原型,9,7a.2 UP的阶段（细化阶段，elaboration）,细化阶段的主要目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。确保软件结构、需求、计划足够稳定，确保项目技术风险已经降低到能够预计完成整个项目的成本和日程的程度；针对项目的软件结构上的主要技术风险已经解决或处理完成；通过完成软件结构上的主要场景建立软件体系结构的基线；建立一个包含高质量组件的可演化的产品原型；说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内；建立好产品的支
5、持环境。,10,7a.2 UP的阶段（细化阶段，elaboration）,评审标准：产品的构想是否稳定？体系结构是否稳定？可执行的原型版是否显示技术风险要素已被处理和可靠的解决；构建阶段的计划是否足够详细和精确？是否被可靠的审核基础支持？如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该构想是可实现的？实际的费用开支与计划开支是否可以接受？,11,7a.2 UP的阶段（细化阶段，elaboration）,细化阶段的产出：用例模型（完成至少80）所有用例均被识别，大多数用例描述被开发；补充捕获非功能性要求和未关联于特定用例要求的需求（补充规范）软件体系结构描述可
6、执行的软件原型经修订过的技术风险清单和商业案例总体项目的开发计划，包括粗粒度的项目计划，显示迭代过程和对应的审核标准；用户手册的初始版本（可选）,12,7a.2 UP的阶段（构造阶段，construction）,构造阶段：所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详尽的测试。通过优化资源和避免不必要的返工达到开发成本的最小化；根据实际需要达到适当的质量目标；根据实际需要形成各个版本（，和release） 对所有必须的功能完成分析、设计、开发和测试工作；采用循环渐进的方式开发出一个可以提交给最终用户的完整产品；确定软件、站点、用户都为产品的最终部署做好了相关准备；达成一定程度上
7、的并行开发机制。,13,7a.2 UP的阶段（构造阶段，construction）,审核标准：产品是否足够稳定和成熟地发布给用户？是否所有的风险承担人准备好向用户移交？实际费用与计划费用的比较是否仍可被接受？构造阶段的产出：特定平台上的集成产品；用户手册；当前版本的描述。,14,7a.2 UP的阶段（移交阶段，transition）,移交阶段的主要目标：确保软件产品可以提交给最终用户。进行测试以期达到最终用户的需要；测试版本和旧系统的并轨；转换功能数据库；对最终用户和产品支持人员的培训；提交给市场和产品销售部门；和具体部署相关的工程活动；协调bug修订、改进性能和可用性(usability）等
8、工作；基于完整的构想和产品验收标准对最终部署做出评估；达到用户要求的满意度；达成各风险承担人对产品部署基线已经完成的共识；达成各风险承担人对产品部署符合构想中标准的共识,15,7a.2 UP的阶段（移交阶段，transition）,评审标准：用户是否满意？实际费用与计划费用的比较是否仍可被接受？,总结：,16,7a.3 迭代增量式开发,UP的每个阶段可以进一步分为迭代过程。迭代过程是生成可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。,17,7a.3 迭代增量式开发,迭代化的方法：将整个项目的开发目标划分成为一些更易于完
9、成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动。在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划；整个迭代过程包含了需求、设计、实施（编码）、部署、测试等各种类型的开发活动；迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。,18,7a.3 迭代增量式开发,UP中的迭代增量式开发（风险驱动）,19,7a.3 迭代增量式开发,项目的主要风险集中在前两个阶段：在细化阶段中经过几次迭代后，为系统建立一个稳定的架构，之后在实现更多的系统需求时，不再对该架构进行修改。同时，在
10、细化阶段中，通过迭代来不断地收集用户的需求反馈，便得系统的需求逐步地明确和完整。,20,7a.3 迭代增量式开发,21,7a.3 迭代增量式开发,开发计划的组织项目计划确定整个项目的开发目标和进度安排，包括每一个阶段的起止时间段。 阶段计划当前阶段中包含有几个迭代，每一次迭代要达到的目标以及进度安排。 迭代计划针对当前迭代的详细开发计划，包括开发活动以及相关资源的分配。,22,7a.3 迭代增量式开发,项目开发计划也是完全体现迭代化的思想：每次迭代中项目经理都会根据项目情况来不断地调整和细化项目开发计划。迭代计划是在对上一次迭代结果进行评估的基础上制定的，如果上一次迭代达到了预定的目标，那么当
11、前迭代只需要解决剩下的问题；如果上一次迭代中留有一些问题还没有解决，则当前迭代还需要继续去解决这些问题。所以必须注意，迭代是不能重叠的，即当还没有完成当前迭代时，决不能进入下一迭代，因为下一次迭代的计划是根据当前迭代的结果而制定的。,23,7a.4 核心工作流,软件开发流程定义了“谁”、“何时”、“如何”做“某事”。四种主要的建模元素被用来表达：角色（worker）“谁”活动（activity）“如何”工件（artifact）“某事”工作流（workflow，discipline） “何时”,24,7a.4 核心工作流,工作流是产生具有可观察结果的活动序列,25,7a.4 核心工作流,26,7
12、a.4 核心工作流（商业建模）,商业建模大多数商业工程化的主要问题是软件工程人员和商业工程人员之间不能正确地交流，这导致了商业工程的产出没有作为软件开发输入而正确地被使用，反之亦然。在商业建模中使用商业用例来文档化商业过程，从而确保了组织中所有商业过程人员达到共识。商业用例被分析以理解商业过程如何被业务支持，而这些在商业对象模型中被核实。许多项目可能不进行商业建模。,27,7a.4 核心工作流（需求）,需求是描述系统应“做什么”，并允许开发人员和用户就该描述达成共识。创建构想建立用例模型识别actor识别use case描述use case其他功能和非功能性需求在补充规范中说明。,Use ca
13、se起到贯穿整个系统的开发周期线索的作用，相同的用例模型在需求捕获阶段、分析/设计阶段和测试阶段中使用。,28,7a.4 核心工作流（分析和设计）,分析和设计显示系统“如何”在实现阶段被实现的，达到下列目标：在特定的实现环境中完成用例描述中指定的任务和功能满足了所有的需求健壮地被建造（如果功能需求发生变化，应该易于更改）分析设计结果是一个设计模型和可选的分析模型：设计模型由设计类和一些描述组成：设计类被组织成具有良好接口的设计包和设计子系统描述则体现了类的对象如何协同工作实现用例的功能设计模型是源代码的抽象设计活动以体系结构设计为中心,29,7a.4 核心工作流（实现）,实现目的：定义代码的组
14、织结构以层次化方式组织实施子系统；实现类和对象以构件的形式（源文件、二进制文件、可执行文件等）；将开发出的构件作为单元进行测试；将由单个实现者或小组产生的结果集成为可执行的系统。,30,7a.4 核心工作流（测试）,测试目的验证对象间的交互作用；验证软件构件的正确集成；验证所有需求被正确的实现；识别并确保在软件发布之前缺陷被处理。,UP提出了迭代的方法，意味着在整个项目中进行测试，从而允许尽可能早地发现缺陷，从根本上降低了修改缺陷的成本；测试生命周期的几个阶段：计划、设计、实现、执行和审核。,31,7a.4 核心工作流（发布）,发布目标是成功地生成版本，将软件分发给最终用户。包含的活动：生成软
15、件本身外的产品；软件打包安装软件给用户提供帮助许多情况下还包括如下的活动：计划和进行测试版移植现有的软件或数据正式验收,32,7a.4 核心工作流（配置和变更管理）,配置和变更管理完成建立并管理基线的任务。 基线：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。 配置项：置于配置和变更管理控制之下的工件。提供了管理系统演化中的多个变体、跟踪软件版本的准则；描述了如何管理并行开发、分布式开发，如何自动化创建工程；涵盖了需求变更管理，即：如何报告缺陷？如何管理缺陷？及如何使用缺陷来跟踪进展和发展的倾向？,33,7a.4 核心工作流（项目
16、管理、环境）,项目管理集中在迭代开发过程的组织管理方面目标是提供以下的事物来使该任务更简单：管理项目的框架；计划、配备、执行、监控项目的实践准则；管理风险的框架。环境目的是给软件开发组织提供软件开发环境（过程和工具），软件开发队伍需要它们的支持；集中在项目环境中配置过程的活动，同样着重支持项目的开发规范的活动，提供了逐步指导手册，介绍了如何在组织中实现过程；还包含了定制流程所必须的准则、模板、工具的开发工具箱。,34,7a.5 最佳实践,短时间分区式的迭代：26周，不鼓励时间推迟适应性开发：小步骤、快速反馈和调整在早期迭代中解决高风险和高价值的问题不断地让用户参与评估、反馈和需求；在早期迭代中建立内聚的核心架构不断地验证质量；提早、经常和实际地测试；使用用例：获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。可视化软件建模（使用UML）仔细地管理需求（需求提出、记录、等级划分、追踪和生命周期跟踪。）实行变更请求和配置管理。,
