搜索
北京邮电大学计算机学院通信软件工程中心@bupt.edu.cn2提纲§4.1UP的基本结构§4.2UP的阶段§4.3迭代增量式开发§4.4核心工作流§4.5最佳实践§4.6UP工件3§4.1UP的基本结构软件开发模型的出发点–如何更快（效率）更好（质量）地满足需求–使得开发过程在一种受控的方式下运行–过程←活动←任务–还需要涉及：项目、人员、工件UP（UnifiedProcess）是一个软件开发过程的框架–拥抱变化：用户反馈和适应调整逐步满足用户需求；–迭代增量式开发–用例驱动整个开发过程–提倡基于构件的软件体系结构为中心展开开发活动4§4.1UP的基本结构5§4.2UP的阶段（初始阶段，inception）初始阶段的目标是为系统建立商业案例和确定项目的边界。–项目边界的确定识别外部角色，识别用例，描述主要用例；（系统应该为不用的用户提供什么？）用户提出的非功能性要求描述。系统的整体架构划分（子系统的划分），与外界环境的交互关系等。–商业案例（businesscase）使用资源估计，包括项目的支撑环境；估计潜在的风险；对整个项目做最初的项目成本和日程估计项目验收规范。6§4.2UP的阶段（初始阶段，inception）初始阶段主要目标：–明确软件系统的范围和边界条件，包括从功能角度的构想(vision)分析、产品验收标准和哪些做与哪些不做的相关决定；–明确区分系统的关键用例和主要的功能场景；–展现或者演示至少一种符合主要场景要求的候选软件体系结构；–对整个项目做最初的项目成本和日程估计（更详细的估计将在随后的细化阶段中做出）；–估计出潜在的业务风险（主要指各种不确定因素造成的潜在业务风险）；–准备好项目的支持环境。评审标准：–风险承担者就范围定义、成本/日程估计达成共识；–以客观的主要用例证实对需求的理解；–成本/日程、优先级、业务风险和开发过程的可信度；7§4.2UP的阶段（初始阶段，inception）初始阶段的产出：–构想文档：核心项目需求、关键特色、主要约束的总体构想；–原始用例模型（完成10%～20%）；–原始项目术语表（可能部分表达为业务模型）；–原始商业案例，包括商业背景、验收规范、成本预计等；–原始的业务风险评估；–一个或多个原型8§4.2UP的阶段（细化阶段，elaboration）细化阶段的主要目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。–确保软件结构、需求、计划足够稳定，确保项目技术风险已经降低到能够预计完成整个项目的成本和日程的程度；–针对项目的软件结构上的主要技术风险已经解决或处理完成；–通过完成软件结构上的主要场景建立软件体系结构的基线；–建立一个包含高质量组件的可演化的产品原型；–说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内；–建立好产品的支持环境。9§4.2UP的阶段（细化阶段，elaboration）评审标准：–产品的构想是否稳定？–体系结构是否稳定？–可执行的演示版是否显示技术风险要素已被处理和可靠的解决；–构建阶段的计划是否足够详细和精确？是否被可靠的审核基础支持？–如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该构想是可实现的？–实际的费用开支与计划开支是否可以接受？10§4.2UP的阶段（细化阶段，elaboration）细化阶段的产出：–用例模型（完成至少80％）……所有用例均被识别，大多数用例描述被开发；–补充捕获非功能性要求和非关联于特定用例要求的需求（补充规范）–软件体系结构描述–可执行的软件原型–经修订过的技术风险清单和商业案例–总体项目的开发计划，包括粗粒度的项目计划，显示迭代过程和对应的审核标准；–用户手册的初始版本（可选）11§4.2UP的阶段（构造阶段，construction）构造阶段：所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详尽的测试。–通过优化资源和避免不必要的返工达到开发成本的最小化；–根据实际需要达到适当的质量目标；–根据实际需要形成各个版本（α，β和release）–对所有必须的功能完成分析、设计、开发和测试工作；–采用循环渐进的方式开发出一个可以提交给最终用户的完整产品；–确定软件、站点、用户都为产品的最终部署做好了相关准备；–达成一定程度上的并行开发机制。12§4.2UP的阶段（构造阶段，construction）审核标准：–产品是否足够稳定和成熟地发布给用户？–是否所有的风险承担人准备好向用户移交？–实际费用与计划费用的比较是否仍可被接受？构造阶段的产出：–特定平台上的集成产品；–用户手册；–当前版本的描述。13§4.2UP的阶段（移交阶段，transition）移交阶段的主要目标：确保软件产品可以提交给最终用户。–进行β测试以期达到最终用户的需要；–β测试版本和旧系统的并轨；–转换功能数据库；–对最终用户和产品支持人员的培训；–提交给市场和产品销售部门；–和具体部署相关的工程活动；–协调bug修订、改进性能和可用性(usability）等工作；–基于完整的构想和产品验收标准对最终部署做出评估；–达到用户要求的满意度；–达成各风险承担人对产品部署基线已经完成的共识；–达成各风险承担人对产品部署符合构想中标准的共识14§4.2UP的阶段（移交阶段，transition）评审标准：–用户是否满意？–实际费用与计划费用的比较是否仍可被接受？总结：15§4.3迭代增量式开发UP的每个阶段可以进一步分为迭代过程。–迭代过程是导致可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。16§4.3迭代增量式开发传统瀑布模型的不足（文档驱动）：–需求或设计中的错误往往只有到了项目后期（测试阶段）才能够被发现。–对于项目风险的控制能力较弱，往往是经过系统测试之后，才能确定该设计是否能够真正满足系统需求。–软件项目常常延期完成或开发费用超出预算，项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。–项目管理人员专注于文档的完成和审核来估计项目的进展情况，所以项目经理对于项目状态的估计往往是不准确的，当他回答系统已完成了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。17§4.3迭代增量式开发18§4.3迭代增量式开发迭代化的方法：–将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。–迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动。在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划；整个迭代过程包含了需求、设计、实施（编码）、部署、测试等各种类型的开发活动；迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。19§4.3迭代增量式开发相比瀑布模型，迭代增量开发的优点：–允许变更需求需求总是会变化，这是事实。给项目带来麻烦的常常主要是需求变化和需求“蠕变”，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。通过向用户演示迭代所产生的部分系统功能，我们可以尽早地收集用户对于系统的反馈，及时改正对于用户需求的理解偏差，从而保证开发出来的系统真正地解决客户的问题。–逐步集成元素在传统的项目开发中，由于要求一下子集成系统中所有的模块，集成阶段往往要占到整个项目很大比例的工作量（最高可达40%），这一阶段的工作经常是不确定并且非常棘手。在迭代式方法中，集成可以说是连续不断的，每一次迭代都会增量式集成一些新的系统功能，要集成的元素都比过去少得多，所以工作量和难度都是比较低的。20§4.3迭代增量式开发–尽早降低风险迭代化开发的主要指导原则就是以架构为中心，在早期的迭代中所要解决的主要问题就是尽快确定系统架构，通过几次迭代来尽快地设计出能够满足核心需求的系统架构，这样可以迅速降低整个项目的风险。等到系统架构稳定之后，项目的风险就比较低了，这个时候再去实现系统中尚未完成的功能，进而完成整个项目。–有助于提高团队的士气开发人员通过每次迭代都可以在短期内看到自己的工作成果，从而有助于他们增强信心，更好地完成开发任务。而在非迭代式开发中，开发人员只有在项目接近尾声时才能看到开发的结果，在此之前的相当长时间，大家还是在不确定性中摸索前近。21§4.3迭代增量式开发–生成更高质量的产品每次迭代都会产生一个可运行的系统，通过对这个可运行系统进行测试，在早期的迭代中就可以及时发现缺陷并改正，性能上的瓶颈也可以及早发现并处理。因为在每次迭代中总是不断地纠正错误，所以可以得到更高质量的产品。–保证项目开发进度每次迭代结束时都会进行评估，来判断该次迭代有没有达到预定的目标。项目经理可以很清楚地知道有哪些需求已经实现了，并且比较准确地估计项目的状态，对项目的开发进度进行必要的调整，保证项目按时完成。22§4.3迭代增量式开发–容许产品进行战术改变迭代化的开发具有更大的灵活性，在迭代过程中可以随时根据业务情况或市场环境来对产品的开发进行调整。例如为了同现有的同类产品竞争，可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品。–迭代流程自身可在进行过程中得到改进和精炼一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。23§4.3迭代增量式开发开发进度的比较24§4.3迭代增量式开发风险控制的比较25§4.3迭代增量式开发UP中的迭代增量式开发（风险驱动）26§4.3迭代增量式开发项目的主要风险集中在前两个阶段：在精化阶段中经过几次迭代后，为系统建立一个稳定的架构，之后在实现更多的系统需求时，不再对该架构进行修改。同时，在精化阶段中，通过迭代来不断地收集用户的需求反馈，便得系统的需求逐步地明确和完整。27§4.3迭代增量式开发28§4.3迭代增量式开发开发计划的组织–项目计划确定整个项目的开发目标和进度安排，包括每一个阶段的起止时间段。–阶段计划当前阶段中包含有几个迭代，每一次迭代要达到的目标以及进度安排。–迭代计划针对当前迭代的详细开发计划，包括开发活动以及相关资源的分配。29§4.3迭代增量式开发–项目开发计划也是完全体现迭代化的思想：每次迭代中项目经理都会根据项目情况来不断地调整和细化项目开发计划。迭代计划是在对上一次迭代结果进行评估的基础上制定的，如果上一次迭代达到了预定的目标，那么当前迭代只需要解决剩下的问题；如果上一次迭代中留有一些问题还没有解决，则当前迭代还需要继续去解决这些问题。–所以必须注意，迭代是不能重叠的，即当还没有完成当前迭代时，决不能进入下一迭代，因为下一次迭代的计划是根据当前迭代的结果而制定的。30§4.4核心工作流软件开发流程定义了“谁”、“何时”、“如何”做“某事”。四种主要的建模元素被用来表达：–角色（worker）“谁”–活动（activity）“如何”–工件（artifact）“某事”–工作流（workflow，discipline）“何时”31§4.4核心工作流–工作流是产生具有可观察结果的活动序列32§4.4核心工作流33§4.4核心工作流（商业建模）商业建模–大多数商业工程化的主要问题是软件工程人员和商业工程人员之间不能正确地交流，这导致了商业工程的产出没有作为软件开发输入而正确地被使用，反之亦然。–在商业建模中使用商业用例来文档化商业过程，从而确保了组织中所有商业过程人员达到共识。–商业用例被分析以理解商业过程如何被业务支持，而这些在商业对象模型中被核实。–许多项目可能不进行商业建模。34§4.4核心工作流（需求）需求–是描述系统应“做什么”，并允许开发人员和用户就该描述达成共识。创建构想建立用例模型