（计算机应用技术专业论文）基于敏捷化rational统一过程需求建模的研究及应用.pdf

摘要 摘要 当前，软件开发现状不容乐观，不少系统延迟、超支交付，甚至无法交付。 为了解决软件开发面临的困难，学者们提出了众多的软件开发过程，其中 r a t i o n a l 统一开发过程( r u p ) 是其中最具代表性的过程之一，也是被广泛采用的 一种软件开发过程。同时敏捷建模( a m ) 是当今最具突破性的建模思想，彻底摆脱 了传统建模思想的束缚，但敏捷建模本身并不是种完整的方法论，需要结合到 具体的开发过程中，r a t i o n a l 统一开发过程良好的可裁剪性使得二者的结合成为 可能。将敏捷建模应用n u r a t i o n a l 统一开发过程之中进行软件开发是很值得探讨 的问题。 本文首先论述t r a t i o n a l 统一过程及统一建模语言u m l ，并深入剖析了当前 运用r u p 进行软件开发实践时出现的典型问题。针对这些问题，引入了敏捷建模 思想。并对敏捷建模的核心实践进行了分析研究，同时与当前r u p 实践进行比较。 在对r u p 和a m 进行充分研究的基础上，依据a m 的实践和原则对r u p 进行相应的改 造，并总结出敏捷化统一过程( a m r u p ) 的特点。根据a m r u p 的特点，本文提出 了一个a m r u p 需求建模过程“总体概要需求获取，按需求优先级进行计划， 小增量迭代式简单需求建模”，同时分析研究了a m r u p 的部分需求建模制品，并 引入了结合场景和目标的需求分析技术。最后本文结合社会保险系统的部分模块 的需求建模实例具体说明如何选择、使用合适的需求建模制品进行a m r u p 的需求 建模过程。 关键词：软件工程；r u p ；敏捷建模；敏捷方法；需求建模 英文摘要 a b s t r a c t t o d a y ，t h es o f t w a r ed e v e l o p m e n ti sad i f f i c u l tw 0 r kf o rd e v e l o p e r s 1 0 t so f s o l t w a r es p e n d sm u c hm o n e yo rm u c ht t m e ，e y e ns o m es o f t w a r ec a n tu s ea tl a s t i n o r d e rt os e t t l et h e s ed i f f i c n l t i e s ，r e s e a r c h e r sh a v e d e v e l o p e ds o m es o f t w a r e d e v e l o p m e n tp r o c e s s e s t h er a t i o n a lu n i f i e dp r o c e s s ( r u p 、i st h eo n eo ft h em o s t r e p r e s e n t a t i v ea n dw i d e l yu s e ds o f t w a r ed e v e l o p m e n tp r o c e s s e s ，a g i l em o d e l i n g ( a m ) m e t h o di st h em o s tr e v o l u t i o n a r ym o d e l i n gi d e at h a ti sv e r yd i f f e r e n tf r o n lt h e t r a d i t i o n a l m o d e l i n gi d e a s ，b u t t h ea g i l e m o d e l i n g i d e ai sn o ta c o m p l e t e m e t h o d o l o g ys oi tn e e dt oc o m b i n ew i t hac o n c r e t ep r o c e s s i t sp o s s i b l eo ft h e c o m b i n a t i o no ft h ea g i l em o d e l i n gi d e aa n dt h eu i l i f l e dp r o c e s sf o rt h er a t i o n a l u n i f i e dp r o c e s sc a nb ec u tw e l l i ti sw o r t hp r o b i n gi n t ot h ec o m b i n a t i o no f t h ea g i l e m o d e l i n gi d e aa n dt h eu n i f i e dp r o c e s sf o rt h es o f t w a r ed e v e l o p m e n t t h i sd i s s e r t a t i o nf i r s td i s c u s s e st h er a t i o n a lu r f i f l e dp r o c e s sa n dt h eu 血f l e d m o d e l i n gl a n g u a g e f u m e ) t h e ne x p l o d e sa ni n d e p t hs t u d yt o 也er e p r e s e n t a t i v e p r o b l e m st h a te x i s t i nt h ep r a c t i c eo fd e v e l o p i n gs o f t w a r e u s i n gr u p t h i s d i s s e r t a t i o ni n t r o d u c e st h ea g i l em o d e l i n gi d e aa g a i n s tt h e s ep r o b l e m s ，t h e ns t u d i e s a n da i 】a i y s e st h ec o r ep r a c t i c e so f t l l ea m ，s i m u l t a n e o u s l yc o m p a r e st h ea m p r a c t i c e w i t ht h ep u r er u p p r a c t i c e b a s e do nt h e s es t u d y ，t l l i sd i s s e r t a t i o nd e s c r i b e sh o wt o m o d i f yt h er u pa c c o r d i n gt ot h ea mp r a c t i c e sa n dp r i n c i p l e s ，t h e nc o n c l u d e st h e f e a t u r e so fa g i l er a t i o n a iu n i f i e dp r o c e s s ( a m r u p ) b a s e do nt h e s ef e a t u r e s t h i s d i s s e r t a t i o nb r i n g sf o r w a r dt 1 1 ea m r u pr e q u i r e m e n tm o d e t i n gp r o c e s s - - g e t t i n g g e n e r a lr e q u i r e m e n t s ，p l a r m i n gb yr e q u i r e m e n tp r i o r i t i e s ，s m a p l er e q u i r e m e n t m o d e l i n ga tt h es m a l l i n c r e m e n ta n di t e r a t i v en 3 o d e ”，a n ds t u d i e sa n da n a l y s e ss o m e a m r u pr e q u i r e m e n tm o d e l i n gw a r e sa n di n t r o d u c e s t h es c e n a r i oa n dg o a l r e q u i r e m e n ta n a l y s i st e c h n o l o g y a tl a s t t h i s d i s s e r t a t i o nt a k e se x a m p l ef o rt h e r e q u i r e m e n tm o d e l i n g i ns o m em o d u l e so ft h es o c i a li n s u r a n c es y s t e m ，a n d i l l u m i n a t e sh o wt os e l e c ta p p r o p r i a t er e q u i r e m e n tm o d e l i n gw a r e st or e a l i z ea m r u p r e q u i r e m e n tm o d e l i n gp r o c e s s ， k e y w o r d s ：s o f t w a r ee n g i n e e r i n g ；r u p ：a g i l em o d e l i n g ；a g i l em e t h o d o l o g y r e q u i r e m e n tm o d e l i n g 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其 他人已经发表或撰写过的研究成果，也不包含为获得 寿蜃史萨或其他教育机 构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献 均己在论文中作了明确的说明并表示谢意。 学位论文作者签名：zj 式。武 签字日期：矽疗年怕 p 目 学位论文版权使用授权书 本学位论文作者完全了解 查墨苤壁 有关保留、使用学位论文的规定， 有权保留荠向国家有关都门或机构送交论文的复印件和磁盘，允许论文被查阅和 借阅。本人授权 壹墨苤壁 可以将学位论文的全部或部分内容编入有关数据 库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名：忒式聊虢砺锣灰 签字日期：如d 年妨船 签字日期 学位论文作者毕业后去向 工作单位 通讯地址 电话； 邮编； i 年j 月辑 第一苹绪论 第一章绪论 1 1 研究背景及意义 随着社会信息化水平的不断提高，世界上数以万计的软件开发团队正在为各 种行业开发各种软件应用程序，开发团队的共同目标是：在预算内按时开发符合 用户真正需要的高品质软件。然而现实并非如此，当前需求分析的主要难点在于： 1 实际问题的复杂性，由于用户需求所涉及的因素多，而导致问题的复杂化。2 交流困难，需求分析涉及人员多，这些人员往往具有不同的背景知识，且处在不 同的角度，扮演不同的角色，从而不可避免地要帝来交流上的问题。3 不完备性 和不一致性，由于种种原因，用户对问题的陈述往往是不完备的，其各方面的需 求不可避免地会存在矛盾，如何消除其矛盾，最终形成完备且一致的需求定义， 这也是一个难点。4 易变性，用户需求的变动是一个极为普遍的问题，特别是在 有关国家机关和企业信息系统的开发工作中，由于相关的政策和市场的不断变 化，造成需求也在不断的变化，如果不能很好的应对，会导致整个项目的进度和 质量都难以控制，最终使整个系统失败。 在我国，用户对于如何应用计算机软件并没有一个成熟的经验，在项目进行 中用户会频繁的改变和增加各种要求。当最终完成系统的建设时，却发现企业的 业务需求已经发生了很大的改变，一方面是系统的设计已经无法很好地满足新的 需求，另一方面是项目周期大大超过预期，项目发生亏损。 据美国软件工程实施现状的调查，软件研发的情况也是很难预测，大约只有 1 0 的项目能够在预定的费用和进度下交付。 由于这些问题的出现，软件工程领域的专家就提出了应用敏捷方法的思想来 应对软件开发过程中需求变化的问题。“敏捷”( a g i l i t y ) 是为了适应日趋激烈 的竞争和生存环境而提出的一种新概念，它要求企业通过提高敏捷性从变化的调 整中掌握主动并赢得市场。这一概念在制造业中已被广泛讨论和实践，以敏捷制 造( a g i l em a n u f a c t u r i n g ) 为核心的先进制造为全世界广为接受。近年来，软件 开发全球化、个性化、快速化、高质量新格局向软件工程提出了极大的挑战。“敏 捷”概念因此被引入软件领域。2 0 0 1 年2 月，十七个方法学家成立了敏捷软件开 发联盟( a g i l es o f t w a r ed e v e l o p m e n ta i l i a n c e ) 。在敏捷方法的探索与实践方 面，联盟的成员们取得了不少成果，x p 、c o a d 的特征驱动开发方法( f d d ) 、 1 第一章绪论 c o c k b u r n 的水晶系列方法、h i g h s m i t h 的适配性软件开发方法、开放式源码、 s c r u m 、动态系统开发方法( d s d m ) 均是当前知名的敏捷方法。随着敏捷方法的日 益成熟，逐渐形成一种新的软件建模方式敏捷建模( a g i l em o d e l i n g ) 。 敏捷建模是对已有方法的补充，而不是一个完整的方法论；而统一过程是已 为广泛使用的成熟的软件过程。将敏捷建模薪思想融入统一软件过程中，将顺应 当前软件开发的要求大大提高软件开发效率。 目前，国外在将敏捷建模融入统一过程方面的研究成果主要是s c o t t w a m b l e r 针对两者结合提出的些实践性的建议。在国内，对该问题的研究刚刚 起步，处于探索阶段。国内外对于敏捷化统一软件过程的研究并没有形成威熟的 理论，敏捷化统一软件过程中需求建模方法和技术的研究也处于初级阶段。当前 统一软件过程的需求建模主要还是运用u m l 。因此，本课题的研究无论在软件过 程的理论探讨方面，还是在需求建模应用实践指导方面都有极其重大的意义。 1 2 研究的内容、目标及创新点 1 、主要研究内容 基础研究： r a t i o n a l 统一软件过程。 u m l 技术理论。 敏捷建模思想及建模相关工具。 重点研究： 敏捷建模与r a t i o n a l 统一过程的结合。 敏捷化的统一需求建模过程及技术。 社会保险系统的需求建模。 2 、研究目标 将敏捷建模和r a t i o n a l 统一过程相结合，构建一个以提高软件开发效率为目 标的a m - r u p 需求建模过程。并依据该需求建模过程，合适的使用u m l 、敏捷建模 技术及相关的工具实现社会保险系统的需求建模。 3 、创新点 依照敏捷建模实践及原则对r u ? 实践进行改造，并总结a n r u p 的特点。创新 性的提出了一个a m r u p 需求建模过程。将u m l n 品和非u m l 制品( 女o c r c 卡、包含 2 第一章绪论 内部角色的d f d 图、健壮图) 、结台场景和目标的需求分析新技术融合在a mr l p 需求建模过程中，实现社会保险系统的敏捷需求建模。 1 3 论文的总体结构 第一章为绪论。主要介绍了本文研究的背景及意义、研究的内容、目标、创 新点及全文的总体结构。 第二章为r a t i o n a l 统一过程和u m l 。主要讨论r u p 的特点、生命周期及主要的 建模技术，最后总结了当前r u p 实践存在的不足之处。 第三章为r s , t i o n a l 统一过程敏捷化。通过讨论敏捷方法、敏捷建模过程的价 值观、核心实践及原则，同时与当前r u p 实践进行比较，说明了本文研究的 “敏捷化r a t i o n a l 统一过程”这一问题的必要性，并提供了敏捷化方面的方 法及实践支持。最后，将敏捷建模实践及原则融入r u p 中，建立敏捷化统一 过程。 第四章为a m r u p 软件需求建模。本章作为全文的主要部分，详细分析研究了 强化统一过程的敏捷建模技术方法，提高软件开发的效率，并依据敏捷化统 一过程理论实践特点提出一个a m r u p 软件需求建模过程。 第五章为社会保险系统需求建模。本章主要结合社会保险管理系统的需求建 模实例来具体说明如何利用各种建模技术方法在敏捷化统一过程中进行需 求建模。 论文的末尾是对课题的总结和展望。总结了课题研究的主要贡献及将来有待 进一步研究的问题。 参考文献列出了本文所引用的全部文献。 附录列出了本文所插入的图表清单。 第二章r a t i o n a l 统一过程和u 矾l 建模语言 第二章r a t io r ai 统一过程年n u a l 建模语言 2 1r a ti o n a l 统一过程 本节将引入本论文的理论基石之- - r u p 。它是本文所要研究的敏捷化统一过 程需求建模的基础。所谓基于敏捷化统一过程需求建模，就是以r u p 为组织的标 准过程，结合敏捷建模思想* 口r u p 的特点构造一个需求建模过程。 r u p 是r a t i o n a l 公司提出的一个通用的软件开发过程框架。“它是一种软件 工程过程( s o f t w a r ee n g i n e e r i n gp r o c e s s ，软件工程过程并不是从工程数学的 角度来探讨软件过程，而是应用工程式的纪律来管理和组织软件开发或维护的过 程) ，为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可 预计的时间安排和预算内，开发出满足用户需求的高品质的软件”“3 。其实，r u p 是涵盖以下两个方面的综合过程： 从软件工程过程的方面来看，统一过程是一个软件开发过程，即是指为了达 到目标而实施的一组有序的步骤。在软件生命周期中，统一过程就是为了实 现满足用户需求的软件系统所需的一系列步骤的汇总( 如图2 1 - 1 所示) ， 它对软件开发的周期、阶段、工作流步骤提供了详细的指导。 输入 赣件开发过程 麓出 用户需求 软件系抗 图2 卜1r 【i p 是一个软件开发过程 从项目组织管理方面来看，统一过程不仅是一个简单的开发过程，它还是一 个通用的、可裁剪的项目管理框架。统一过程从广泛的软件项目中吸取了不 少最佳的软件开发实践。这些实践经验对软件项目组织中的四要素( 人员、 项目、产品和过程) 之间关系的协调管理提供了有效的指导( 如图2 卜2 所 示) ，从而达到项目风险缓解、质量控制、优化项目管理和配置管理的目标。 统一过程框架可依据软件项目的实际情况进行合适的裁剪，使之在各种不同 的项目规模、各种不同的应用领域、各种不同类型的软件系统、各种不同类 型的组织及各种不同的性能水平上成功的发挥作用。 第二章r a t i o n a l 统一过程和l l m l 建模语言 2 。1 。1r u p 的生命周期 图2 卜2r o p 是一个项目管理构架 与传统的软件开发模型相比，传统的软件开发模型( 如瀑布模型) 通常是一个 一维的模型，而统一过程的生命周期可用二维结构来描述，如图2 卜3 ，该图的 一次循环代表了统一过程的一次生命周期。统一过程是一个将用户需求转化软件 系统所需的活动集合，该活动集合是在过程的生命周期中完成的a 棱心t f i e 蠢 业务建柱 需求 分析设计 善：习l i 嘲茸 帮蓦 棱心支持工作瓷 配置与麦更控嗣 璜目首理 环境 初抬绷化构造空甘 l o ! - ： ： i l l i il 一 ；： 一! 一 ： 迭代选代 菇代 图2 卜3r u p 生命周期的二维结构 统一过程是在重复一系列的生命周期，这些生命期构成了一个软件系统的寿 命。每个生命期都以向用户推出一个产品版本作为终结。每含周期包括初始、细 化、构造、交付四个阶段。正如上图所示，每个阶段可以进一步划分为多次迭代。 软件开发组织正是在该过程的指导下，不断重复过程的生命周期，从而不断向用 户提供越来越符合用户需求的软件产品版本，推进着系统不断升级。 始啬馨霎 多自 第二章r a t i o n a l 统一过程和u 魁建模语言 2 1 2r u p 的动态结构 在统一过程生命周期的二维结构图的横轴上包含阶段和迭代两项内容，这两 项即是开发过程沿时间的动态组织结构。在此时间维上，为了能够方便地管理软 件开发过程，监控软件开发状态，r u p 把软件生命周期划分为若干次迭代，每次 迭代生成一个产品的新版本并依次由四个连续的阶段组成，每次迭代都应完成确 定的任务，正是这些迭代过程不断产生系统新的增量，使产品不断成熟，从低版 本软件不断过渡到高版本软件。 2 1 2 1 四大阶段 软件生命周期被分解为周期，每一个周期工作在产品新的一代上，r u p 将周 期又划分为初始、细化、构造、交付四个连续的阶段。每个阶段都终结于个良 好定义的里程碑。其实，每个阶段就是两个主要里程碑之间的时间跨度。在每个 阶段结束时要依据里程碑目标进行工作评估，以确定是否实现了该阶段的目标以 及是否可以进入下一个阶段。 初始阶段 初始阶段的目标是为系统建立业务案例、确定项目的范围及边界条件。 为了达到该目标，必须识别所有与系统交互的外部实体，在较高层次上定义 交互的特性。该工作包括识别所有用例和描述一些重要的用例。业务案例包 括验收规范、风险评估、所需资源的估计及体现主要里程碑日期的阶段计划。 在初始阶段，通常要建立一个或多个用于验证的概念原型。 本阶段具有非常重要的意义，在这个阶段中关注的是整个项目进行工程 中的业务和需求方面的主要风险。 细化阶段 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目 计划和淘汰项目中最高风险的元素。在本阶段，需在理解整个系统的基础上， 确定它的范围、主要功能和性能等非功能性需求，建立一个合理的体系结构 基础。在细化阶段，需建造一个包含高质量组件的可演化的产品原型。 细化阶段是四个阶段中最关键的阶段。细化阶段活动确保了结构、需求 和计划的稳定性并充分减轻了风险性，最后决定项目是否提交给构造和交付 阶段。 一一蔓三兰! 坠i ! ! 生篓二塾堡! ! ! 坠垄堡堕童 构造阶段 在构造阶段，迭代地、增量地开发软件系统。通过不断测试、不断改进 软件、体系结构和方案，直至开发出完整的产品。 交付阶段 交付阶段的目标是将软件产品交付给用户使用。在交付阶段的终点是第 四个重要的项目里程碑产品发布里程碑。此时决定是否目标已达到或开 始另一个周期。 2 1 2 2 迭代过程 r u p 的每个阶段都由一个或多个连续的迭代组成。迭代过程是导致可执行产 品版本的完整开发循环( 即从捕获需求到代码实现) ，是最终产品的一个子集，从 一个迭代过程到另一个迭代过程递增式增长，形成最终的系统产品。在各阶段中， 每个过程工作流各有不同的重点。通常，在初始阶段，迭代工作重点在于需求捕 获；在细化阶段，重点转移到分析和设计：在构造阶段，实现是中心活动；而交 付阶段的，中心任务在于实施。 2 1 3r u p 的静态结构 在统一过程生命周期的二维结构图的纵轴上表现了过程的静态结构。 2 1 3 。lr u p 的模型元素 r u p 的静态结构包括角色、工作流程、活动、工件四个基本模型元素。它们 分别描述了软件开发过程“谁”“什么时候”“如何”“做”某事以及怎样实现 某一特定的目标。模型元素之间的关系如图2 卜4 所示。 角色，定义了个人或由若干人所组成小组的行为和责任。角色通过执行某些 活动完成特定工件。 活动，是具有明确的目的的工作单元，通常表现为些产物如模型、类、计 划等。 工件，是项目期间由活动生成并使用的中间或最终产物。工件有多种存在形 式，包括模型、模型元素、文档、源代码、可执行文件等。 工作流程，是产生具有可观察结果的活动序列。每个工作流产生一些有价值 的工件。r u p 主要提供两种组织工作流的方式：核心工作流和核心支持工作 流。工作流的具体内容将在下一小节详细介绍。 7 第二章r a t i o n a l 统一过程和删l 建模语言 除以上四个基本模型元素，r u p 还包括一些辅助活动及工件的其他一些模型 元素( 如图2 卜4 ) 。其中工作指南和工具向导，提供了角色执行活动的方法和 应用工具的步骤；概念则是包含了工作流中的重要概念；报告则存放着模型与模 型元素之间相关联的信息；工件相关的指南和检查点，提供有关开发工件、评估 工件和使用工件等信息。 广 除对潜在需求的记录，该文档还可记录系统的业务规则、可靠性、可扩 展性等方面的信息。这些信息可用“业务规则”、“技术需求”和“约 束定义”制品承载。 实际上，a m r u p 业务建模重要点就是在分析组织业务流程的同时分析出业务 对象( b u s i n e s so b j e c t ) 。业务对象是进行业务建模的基础，在此基础上，通 过评估业务状态，说明当前业务，确定业务流程，改进业务流程的定义，改进角 色和职责，研究流程自动化，并通过对主要几种业务模型文档的特点及在a m r u p 中应用的合适场合的分析，有选择韵开发在r u p 中建议的业务模型实现业务建模 的目标。 4 2 2 业务需求优先级的确定 业务需求优先级的确定是进行a m r u p 迭代计划的关键依据。一旦建立业务需 求的优先级，开发方就能够将业务实现任务按优先级的高低分配到各开发周期 中，同时在一个开发周期中计划风险承担者和项目的参与者就能把精力集中在一 系列共同的目标上。 为了确定业务需求优先级，必须考虑软件项目及其所要实现业务的四个方 面：业务重要性、业务稳定性、性能和成本。 业务重要性评定，需要从两个角度来衡量。首先从用户方的角度，由用户划 分哪些业务功能是急需要用到的，哪些是可以后续解决的。然而，用户并未 考虑到技术实现上的先后制约性，比如基础数据的维护是所有其它业务实现 的根本。因此，还要从开发方的角度，结合业务流程及技术实现的先后次序， 对业务模块的重要性进行综合评定。 业务稳定性评定，需要依据开发方在业务建模中从用户方中获得的关于业务 管理流程或相关政策等方面的可变信息。业务功能的可变度及变化的可能时 间，将从业务建模中的变例制品中体现。 3 5 第四章叫一r u p 软件需求建模 除了考虑以上两个主要方面以外系统性能、质量及项目成本也是实际需要 考虑的方面，毕竟，任何软件开发组织的可用资源都是有限的。为了业务需求确 定优先级，要将以上四个方面综合起来考虑。如表4 2 一l 需求优先级设定方法。 需求优先级的确定必须由开发方和各层用户代表针对他们所使用的规模中每一 层的含义上达成一致意见。 参考方法 优先级含义 l 关键性的业务，必须先实现。 2 次重要性、稳定性较好的业务，即必要的系统业务， 但如果需要，可以延迟实现。 本文总结 次重要性、稳定性较差的业务，即最终需要而模糊 3 的系统业务，有必要延迟实现。 性能或质量上的增强；如果资源允许，实现这些需 4 求将使软件系统更完美。 基本的只有在这些需求上达成一致意见，软件才会被接受 i e e e 条件的实现这些需求有利于增强软件系统的性能。 可选的一个功能类，实现或不实现均可 高必须完美地实现。 k o v i t z中 需要付出努力，但不必做得太完美。 低可以包含缺陷。 表4 2 - 1 需求优先级设定方法 由于a m r u p 需求过程侧重合适、够用的原则，因此，在需求优先级确定方面 并没有选择复杂而精确的方法，比如质量工程开发( q f d ，能够为软件系统提供 用户价值与性能相联系的一种综合方法) 、完全质量管理( t q m ，以多个重大项 目成功的标准来评价每个需求，并且计算出一个分值用于编排需求的优先级) 。 适合敏捷化统一过程的精确需求优先级确定方法还有待进一步的研究。 在利用以上方法确定了业务需求优先级后，结合开发团队的人员结构和规模 信息，进行团队的分组与概要业务实现任务的分配，从而初步确定各迭代周期各 小组的业务实现目标。 兰坚主些：! 竺鏊壁萱鲞垄堡 4 3 需求建模阶段 需求建模阶段主要目标是将依据业务需求制定软件系统的需求。其中包括与 用户方共同确定出软件系统必须实现的功能、明确系统范围、定义系统用户界面 及相应的一些非功能需求。以下将针对该阶段的目标，分析研究a m r u p 需求建模 制品与技术。 4 3 1 确定系统行为及环境 理解系统的环境及行为是晃定开发工作的重要依据，而且是需求建模将业务 模型演进为软件系统需求的首步。为了达到既能描述系统行为又能表现系统所处 的外部环境，一般选择上下文模型( c o n t e x zm o d e l ) ，而该模型相应的制品有 u m l 用例图和“0 级”数据流图( d f d ) 。在a m r u p 需求建模中提倡选用合适的制品。 因此，先将两制品进行比较分析，比较结果如表4 3 - i 所示。 u s ec a s e ( u m l ) “0 级”d f d 优 描述了与软件系统交互的 描述了系统与外部之间 占 所有角色( 包括系统的外部 交互的主要信息 j 和内部角色) 缺 无法描述系统与角色交互 点 的情况 无法描述内部角色 表4 3 - 1u s ec a s e 同“0 级”d f d 的比较 上表能够清楚说明以上两种制品在描述上下文模型时都各有优缺点，单独使 用无法实现同时描述系统行为和环境的目的。此时，虽然肌r u p 主张应用建模标 准，而同时也强调“别让它们成为僵化的教条。“。因此，考虑将两制品的优点 结合在一张包含内部角色的d f d 图。如图4 3 - 1 ，使用包含内部角色的d f d 图确定 社会保险系统的上下文模型。 系统的行为和环境确定后，则开始详细分析功能、界面及相关的非功能需求， 分析需求的制品除了前面介绍的u m l 的各类模型，还有描述用例故事的用户界面 流程图及健壮图，用于界面分析的用户界面原型，非功能需求文档。这些制品根 据项目的需要可选择性的用于a m r u p 需求建模过程当中。 第四章a m r u p 软件需求建模 图4 3 1 社会保险系统上下文模型 4 3 2 结合场景与目标的需求分析 在当前的软件需求建模领域中，用例建模是需求功能建模方面的主要方法， 然而对于系统的功能探索及细化方面显得不够灵活，而且在需求完整性验证方 面，显的不够充分。因此，只采取用例建模违背了a m r u p 使用合适制品的原则。 为了弥补这些不足，在功能建模中，将场景及目标两概念引入a m r u p 需求建模过 程中。 场景 场景( s c e n a r i o ) 用来理解一个系统的需要是什么和系统是怎样工作的。 从需求建模的角度来看，场景是为了完成特定任务而按照时间顺序排列的一 系列对象间交互；是对象交互的特定时序；是完成信息系统的某个需要“。 因此，场景的常见的形式化技术有静态的用例图、体现动态和交互性的u m l 活动图、协作图、交互图。如图4 3 2 所示社会保险系统中的个人参保业务 子系统的最初场景。 根据上面场景的定义，可发现单独的场景模型只能描述某一部分的需 求。在高层场景向下细化时，缺乏方向性；并且在仅通过场景获取的需求缺 乏可确认性。这两点将影响需求分析的速度和准确度。由于a m - r u p 2 e 张合适 使用的非u m l 制品，因此，为了高效的进行需求建模，引出目标模型。 第四章a d t - r u p 软件需求建模 图4 3 - 2 个人参保业务最初场景( 活动图) 目标 软件项目的用户方希望通过软件系统帮助他们达到某一目标，目标较对 象来说，更为稳定，因此，最近几年兴起了面向目标的需求分析方法。目标 概念是由k y g e 首先提出，他不仅在“存在什么需求”和“怎么处理需求” 两方面进行了分析研究，而且在理解“为什么这么做”问题的前提下，将目 标作为判断需求完整性的依据。随后，出现了不少的面向目标的需求分析方 法，如d i s t r i b u t ei t e n t i o n 框架、k a o s ( k n o w l e d g ea c q u i s i t i o ni n a u t o m a t e ds p e c i f i c a t i o n ) 等方法。面向目标的需求分析方法是从最初始 的需求信息着手分析，对初始目标进行分解和提取，逐步获取细化的目标并 构造出目标模型。它是一种有效的确认需求的方式。 然而，这种方法也不是完美的，它侧重的是系统目标，而并没有描述具 体实现每一层目标任务的场景。 场景和目标协同需求建模( 在本文中简称s c g 技术) 通过对场景和目标的优缺点分析，发现它们是互补式的两种模型。因此， 考虑将两者结合起来进行需求建模。通过相互交错的目标建模和场景设置来 分析建模。 结合场景和目标需求建模方式 结合场景和目标需求建模主要分两阶段：从场景发现下一层的目标，根 第四章a m - r u p 软件需求建模 据目标进行本层的场景设置。通过这两阶段的循环，直至目标被全部发现。 结合场景和目标的需求建模技术的关键结构是需求块( r e q u i r e m e n t c h u n k ) ，定义为( 目标g ，场景s c ) 。需求块之间的连接方式存在三种：提 取关系；组成关系 ；可选关系 ；。以下将结合实例对如何应用这 三种连接方式进行需求分析。 结合实例分析需求块的三种连接方式 组成和可选关系分别产生的是同一水平级的a n d 矛t 3 0 r 的结构，建立了水 平的连接，而提取关系将产生不同水平级的细化层次，体现了垂直的结构， 以个人参保业务为侧分析其作用及特点。该例是以如图4 3 2 所示的个人参 保业务最初场景作为起点进行的个人参保业务的需求分析实例( 如图 4 3 3 ) 。 图4 3 - 3 个人参保部分需求块 提取关系：场景的不断设置，目标的不断发现细化，产生了不同的细化 层。提取正是用来描述各细化层的需求块。如图4 3 3 中需 求块r c l 就被细化为r c l 。l 、r c l 。2 、r c l 。3 、r c i 4 四类子需 求块，这四类子需求块的目标均是从s c l 中提取出来的。 a n d 关系：各需求块均有完整的功能。目标g 1 1 、g 1 2 、g 1 3 、r c l 4 是由场景s c l 中分析发现的，而且相应的需求块r c l 1 、 r c l 2 、r c l 3 并1 3 r c l 4 z 间是由a n d 相连。a n d 在此的实际含 义：进行个人参保的人员为了g 1 4 “个人帐户结息”( 即 4 0 第四章a m r u p 软件需求建模 帐户有钱) 必须先进行“人员信息入个人库”及“创建个人 帐户”( g 1 2 ) ，再经过“缴费记帐”( g 1 3 ) ，这同时就 实现了“个人参保业务”。 o r 关系；描述完成一个目标有可能出现的几种情况或可选的几种方 式。例如：图4 3 3 中“人员信息入个人库”可能出现两 种方式：“人员信息新增”( g 1 1 ) 和“社保封存人员转入 库”( g 1 1 1 ) 。这是由于要进行个人参保人员身份不同： 新参保人员、社保封存人员、外地参保调入人员。 综上分析，利用组成关系、可选关系和提取关系发现目标表现在两个方 面：从初始场景及更具体的场景中发现提取新子目标，每一个非叶结点目标 存在各自的a n d o r 层。因此，结合场景和目标的需求分析进程可以描述为： 提取关系确保逐步清晰化模糊的目标，通过传统的a n d - o r 目标结构能够使叶 结点需求块( 即部分最终需求) 出现变得可能。总之，目标变得越来越具体， 实现目标的具体方案也变得越来越清晰。 结合场景和目标需求建模的特点 ( 1 ) 方便功能需求获取。通过场景发现目标的过程中，常常会发现一些 用户需求。这将增强需求分析的准确性、完整性。 ( 2 ) 便于同用户共同探索需求，因为该模型是采用用户易接受的目标概 念及易理解的a n d o r 目标结构。这一点积极的支持了a m r u p 的“公 开展示模型”及“用户积极参与”的建模原则。 ( 3 ) 有利于处理需求变更与需求验证、跟踪需求，并支持需求复