项目管理规范-RUP管理实施.pdf

《项目管理规范-RUP管理实施.pdf》由会员分享，可在线阅读，更多相关《项目管理规范-RUP管理实施.pdf（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、工程治理标准工程治理标准-RUP-RUP 治理实施治理实施第一局部：工程时期第二局部：核心工作流程第三局部：角色划分第四局部：目前实施工程标准的考虑概述软件开发的产品质量水平，是一个由来已久的话题。而提高软件企业的产品质量水平，必须革新软件产品的开发过程。然而那个地点没有什么百试百灵的灵丹妙药，我们必须依据本企业的实际情况，参考国内外先进企业的经验，总结出一种适合本企业的软件开发模式。此标准是基于 CMM 模型标准，以RUP 软件工程过程为蓝本，由我本人依据工程实际情况而选择修改，从而使之适应当前应用级系统设计开发的需要。本文要紧以 RUP 的软件工程框架为主，省略复杂概念局部。着眼点放在操纵

2、软件产品开发流程上，由于人员配置与软件分工现行状况的限制，对其中的局部细节进行了合并可省略，从而适应目前国内软件开发所要求。RationalUnifiedProcess简称 RUP是一套软件工程过程在下面介绍。在 RUP 过程中，我们能够瞧到它特不强调一点：循环。现在我们做的每一个工程都存在不断变化的咨询题。用户需求变化、系统设计变化可能是需求变化也可能是存在了技术咨询题、编码变化由测试与复审等环节引发的等咨询题困扰着工程进行。解决这些咨询题的方法确实是根基不断的循环。那个标准是我依据自己的瞧点整理编写而成的，有缺乏之处请指教。RUP 简介RationalUnifiedProcess简称 RU

3、P是一套软件工程过程，要紧由IvarJacobson 的 TheObjectoryApproch 和 TheRationalApproch 开展而来。同时，它又是文档化的软件工程产品，所有 RUP 的实施细节及方法导引均以 Web 文档的方式集成在一张光盘上，由 Rational公司开发、维护并销售，当前版本是RUP2000。RUP 又是一套软件工程方法的框架，各个组织可依据自身的实际情况，以及工程规模对RUP 进行裁剪和修改，以制定出符合需要的软件工程过程。RUP 汲取了多种开发模型的优点，具有特别好的可操作性和有用性、从它一推出市场，凭借 Booch、IvarJacobson、以及 Rum

4、baugh 在业界的领导地位、以及与统一建模语言 UnifiedModelLanguage,以下简称 UML的良好集成、多种 CASE 工具的支持、不断的升级与维护，迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架。在 RUP 中，软件开发生命周期依据时刻和 RUP 的核心工作流划分为二维空间。如上图所示，时刻维从组织治理的角度描述整个软件开发生命周期，是RUP 的动态组成局部。它可进一步描述为周期Cycle、时期phase、迭代(Iteration)。核心工作流从技术角度描述 RUP 的静态组成局部，它可进一步描述为行为activities、工作流workflow、产品arti

5、fact、工人worker。图中的阴影局部描述了不同的工作流，在不同的时刻段内工作量的不同。值得注重的是，几乎所有的工作流，在所有的时刻段内均有工作量，只是大小不同而已。这与 Waterfallprocess 有明显的不同。RUP 采纳 UseCase 的概念，把要开发的系统依据各功能使用的情况划分多个 UseCase，并采纳迭代的思想把系统的风险分布在四个时期，风险越大的迭代越要放在靠前的时期做，使软件产品的风险不断落低；而不是像传统软件工程那样越往开发的后期咨询题越多。因此 RUP 的思想一推出就受到软件企业的送不。按照 RUP 的开发模式一般能够到达 CMM2、3 级的水平。因此，理解和

6、掌握 RUP 需要一个相对较长的过程。1.工程时期从治理的瞧点来讲，软件生命周期随着时刻分为四个依次进行的时期，每个时期的结束都有一个要紧里程碑；实质上，每个时期确实是根基两个要紧里程碑之间的时刻跨度。在每个时期结束时进行评估，以确定是否实现了现在期的目标。良好的评估可使工程顺利进进下一时期。1.1.方案时期在进度和工作量方面，所有时期都各不相同。尽管不同的工程有特别大的不同，但一个中等规模工程的典型初始开发周期应该预先考虑到工作量和进度间的分配：先启精化构建产品化工作量5%20%65%10%进度 10%30%50%10%可表示为以如下面图关于演进周期，先启和精化时期就小得多了。能够自动完成某

7、些构建工作的工具将会缓解此现象，并使得构建时期比先启时期和精化时期的总和还要小许多。通过这四个时期确实是根基一个开发周期；每次通过这四个时期就会产生一代软件。除非工程“死亡，否那么通过重复同样的先启时期、精化时期、构建时期和产品化时期的顺序，产品将演进为下一代产品，但每一次的侧重点都将放在不同的时期上。这些随后的周期称为演进周期。随着产品经历了几个周期，新一代产品随之产生。1.2.先启时期.目标先启时期的全然目标是实现工程的生命周期目标中所有相关因素如客户等之间的并行。先启时期要紧对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险咨询题必须在工程接着进行之前得到解决。关于重点是扩展现

8、有系统的工程来讲，先启时期较短，但重点仍然是确保工程值得进行而且能够进行。先启时期的要紧目标包括：建立工程的软件规模和边界条件，包括运作前景、验收标准以及盼瞧软件中包括和不包括的内容。识不系统的要害用例也确实是根基将造成重要设计折衷操作的要紧局部。评估整个工程的总体本钞票和进度以及对立即进行的精化时期进行更具体的评估评估潜在风险不可推测性的来源预备工程的支持环境。1.2.2.核心活动明确地讲明工程规模。这涉及了解环境以及最重要的需求和约束，以便于能够得出最终产品的验收标准。方案和预备商业理由。评估风险治理、人员配备、工程方案和本钞票/进度/收益率折衷的备选方案。综合考虑备选构架，评估设计和自制

9、/外购/复用方面的折衷，从而估算出本钞票、进度和资源。此处的目标在于通过对一些概念的证实来证实可行性。该证实可采纳可模拟需求的模型形式或用于探究被认为高风险区域的初始原型。先启时期的原型设计工作应该限制在确信解决方案可行就能够了。该解决方案在精化和构建时期实现。预备工程的环境，评估工程和组织，选择工具，决定流程中要革新的局部。1.2.3.里程碑：生命周期目标生命周期目标里程碑评估工程的全然可行性。先启时期末是第一个重要的工程里程碑，即生命周期目标里程碑。现在，检查工程的生命周期目标，并决定接着进行工程依旧取消工程。评估标准规模定义和本钞票进度估算中，所有相关因素如客户等可并行对是否差不多获得正

10、确的需求集达成一致意见，同时对这些需求的理解是共同的。对本钞票进度估算、优先级、风险和开发流程是否适宜达成一致意见。差不多确定所有风险同时有针对每个风险的减轻风险策略。要是工程无法到达该里程碑，那么它可能中途失败或需要进行相当多的重新考虑。提供的文档及模型核心文档及模型按照重要性排序里程碑状态前景差不多对核心工程的需求、要害功能和要紧约束进行了记录。商业理由差不多确定并得到了批准。风险列表差不多确定了最初的工程风险。软件开发方案差不多确定了最初时期及其持续时刻和目标。软件开发方案中的资源估算特别是时刻、人员和开发环境本钞票必须与商业理由一致。资源估算能够涵盖整个工程直到交付所需的资源，也能够只

11、包括进行精化时期所需的资源。现在，整个工程所需的资源估算应该瞧作是大致的“粗略估量。该估算在每个时期和每次迭代中都会更新，同时随着每次迭代变得更加正确。依据工程的需要，可能在某种条件下完成了一个或多个附带的“方案工件。此外，附带的“指南工件通常也至少完成了“草稿。迭代方案第一个精化迭代的迭代方案差不多完成并通过了复审。软件验收方案完成复审并确定了基线；随着其他需求的发现，将对其在随后的迭代中进行革新。工程专用模板已使用文档模板制作了文档工件。用例建模指南确定了基线。工具选择了支持工程的所有工具。安装了对先启时期的工作必要的工具。词汇表差不多定义了重要的术语；完成了词汇表的复审。用例模型主角，用

12、例差不多确定了重要的主角和用例，只为最要害的用例简要讲明了事件流。领域模型也喊做业务对象模型差不多对系统中使用的核心概念进行了记录和复审。在核心概念之间存在特定关系的情况下，已用作对词汇表的补充。原型概念原型的一个或多个证据，以支持前景和商业理由、解决特不具体的风险。1.3.精化时期1.3.1.目标精化时期的目标是建立系统构架的基线，以便为构建时期的要紧设计和实施工作提供一个稳定的根底。构架是基于对大多数重要需求对系统构架有特别大碍事的需求的考虑和风险评估开展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。精化时期的要紧目标包括：确保构架、需求和方案足够稳定，充分减少风险，从而能够有预

13、见性地确定完成开发所需的本钞票和进度。对大多数工程来讲，通过此里程碑也就相当于从简单快速的低风险运作转移到高本钞票、高风险的运作，同时在组织结构方面面临许多不利因素。处理在构架方面具有重要意义的所有工程风险建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常能够显示工程的最大技术风险。制作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探究性原型，以减小特定风险，例如：设计/需求折衷构件复用产品可行性或向客户和最终用户进行演示。证实已建立基线的构架将在适当时刻、以合理的本钞票支持系统需求。建立支持环境。为了实现那个要紧目标，建立工程的支持环境也同等重要。这包括

14、创立开发案例、创立模板和指南、安装工具。1.3.2.核心活动快速确定构架、确认构架并为构架建立基线。依据现在期获得的新信息革新前景，对推动构架和方案决策的最要害用例建立可靠的了解。为构建时期创立具体的迭代方案并为其建立基线。革新开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。革新构架并选择构件。评估潜在构件，充分了解自制/外购/复用决策，以便有掌握地确定构建时期的本钞票和进度。集成了所选构架构件，并按要紧场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。1.3.3.里程碑：生命周期构架生命周期构架里程碑为系统构架建立治理基线，并使工

15、程团队能够在构建时期调整规模。精化时期末是第二个重要的工程里程碑，即生命周期构架里程碑。现在，您检查具体的系统目标和规模、选择的构架以及要紧风险的解决方案。评估标准产品前景和需求是稳定的。构架是稳定的。可执行原型讲明差不多寻到了要紧的风险元素，同时得到妥善解决。构建时期的迭代方案足够具体和真实，能够保证工作接着进行。构建时期的迭代方案由可靠的估算支持。所有客户方人员一致认为，要是在当前构架环境中执行当前方案来开发完整的系统，那么当前的前景能够实现。实际的资源消耗与方案的消耗相比是能够同意的。要是工程无法到达该里程碑，那么它可能中途失败或需要进行相当多的重新考虑。提供的文档及模型核心文档及模型按

16、照重要性排序里程碑状态原型差不多创立了一个或多个可执行构架原型，以探究要害功能和构架上的重要场景。风险列表差不多进行了更新和复审。新的风险可能是构架方面的，要紧与处理非功能性需求有关。工程专用模板已使用文档模板制作了文档工件。工具差不多安装了用于支持精化时期工作的工具。软件构架文档编写完成并确定了基线，要是系统是分布式的或必须处理并行咨询题，那么包括构架上重要用例的具体讲明用例视图、要害机制和设计元素的标识逻辑视图，以及部署模型的进程视图和部署视图的定义。设计模型和所有组成局部制作完成并确定了基线。差不多定义了构架方面重要场景的用例实现，并将所需行为分配给了适当的设计元素。差不多确定了构件并充

17、分理解了自制/外购/复用决策，以便有掌握地确定构建时期的本钞票和进度。集成了所选构架构件，并按要紧场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。数据模型制作完成并确定了基线。差不多确定并复审了要紧的数据模型元素例如重要实体、关系和表。实施模型以及所有组成工件，包括构件差不多创立了最初结构，确定了要紧构件并设计了原型。前景差不多依据现在期获得的新信息进行了革新，对推动构架和方案决策的最要害用例建立了可靠的了解。软件开发方案差不多进行了更新和扩展，以便涵盖构建时期和产品化时期。指南，如设计指南和编程指南。使用指南对工作进行了支持。迭代方案差不多完成并复审

18、了构建时期的迭代方案。用例模型用例模型大约完成 80%-差不多在用例模型调查中确定了所有用例、确定了所有主角并编写了大局部用例讲明需求分析。补充规约差不多对包括非功能性需求在内的补充需求进行了记录和复审。可选里程碑状态商业理由要是构架调查不涵盖变更全然工程假设的咨询题，那么差不多对商业理由进行了更新。分析模型可能作为正式工件进行了开发；进行了经常但不正式的维护，正演进为设计模型的早期版本。培训材料用户手册与其他培训材料。依据用例进行了初步起草。要是系统具有复杂的用户界面，可能需要培训材料。1.4.构建时期1.4.1.目标构建时期的目标是讲明剩余的需求，并基于已建立基线的构架完成系统开发。构建时

19、期从某种意义上来讲是一个制造过程，在此过程中，重点在于治理资源和操纵操作，以便优化本钞票、进度和质量。从这种意义上讲，从先启和精化时期到构建和产品化时期，治理上的思维定势经历了从知识产权开发到可部署产品开发的转变。构建时期的要紧目标包括：通过优化资源和防止不必要的报废和返工，使开发本钞票落到最低。快速到达足够好的质量快速完成有用的版本Alpha 版、Beta 版和其他测试公布版完成所有所需功能的分析、开发和测试。迭代式、递增式地开发随时能够公布到用户群的完整产品。这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。确定软件、场地和用户是否差不多为部署应用程序作好预备。开发团队的工

20、作实现某种程度的并行。即使是较小的工程，也通常包括能够相互独立开发的构件，从而使各团队之间实现自然的并行资源准许。这种并行性可较大幅度地加速开发活动；但同时也增加了资源治理和工作流程同步的复杂程度。要是要实现任何重要的并行，强壮的构架至关重要。1.4.2.核心活动资源治理，操纵和流程优化完成构件开发并依据已定义的评估标准进行测试依据前景的验收标准对产品公布版进行评估。1.4.3.里程碑：最初操作性能最初操作性能里程碑确定产品是否差不多能够部署到 Beta 测试环境。在最初操作性能里程碑，产品随时能够移交给产品化团队。现在，已开发了所有功能，并完成了所有 Alpha 测试要是有测试。除了软件之外

21、，用户手册也差不多完成，而且有对当前公布版的讲明。评估标准构建时期的评估标准涉及到对以下咨询题的答复：该产品公布版是否足够稳定和成熟，可部署在用户群中？是否已预备好将产品公布到用户群？实际的资源消耗与方案的相比是否仍能够同意？要是工程无法到达该里程碑，产品化可能要推迟一个公布版。提供的文档及模型核心文档及模型按照重要性排序里程碑状态“系统可执行系统本身随时能够进行“Beta测试。部署方案已开发最初版本、进行了复审并建立了基线。实施模型以及所有组成局部，包括构件对在精化时期创立的模型进行了扩展；构建时期末期完成所有构件的创立。测试模型和所有组成局部为验证构建时期所创立的可执行公布版而设计并开发的

22、测试。培训材料用户手册与其他培训材料。依据用例进行了初步起草。要是系统具有复杂的用户界面，可能需要培训材料。迭代方案差不多完成并复审了产品化时期的迭代方案。设计模型和所有组成局部差不多用新设计元素进行了更新，这些设计元素是在完成所有需求期间确定的。工程专用模板已使用文档模板制作了文档模板。工具差不多安装了用于支持构建时期工作的工具。数据模型差不多用支持持续实施所需的所有元素例如，表、索引、对象关系型映射等进行了更新可选里程碑状态补充规约差不多用构建时期发现的新需求要是有进行了更新。用例模型主角，用例差不多用构建时期发现的新用例要是有进行了更新。1.5.产品化时期1.5.1.目标产品化时期的重点

23、是确保最终用户能够使用软件。产品化时期可跨越几个迭代，包括测试处于公布预备中的产品和基于用户相应进行较小的调整。在生命周期中的该点处，用户相应应要紧侧重于调整产品、配置、安装和可用性咨询题，所有较大的结构上的咨询题应该在工程生命周期的早期时期就已得到解决。在产品化时期生命周期结束时，目标应该差不多实现，工程应处于将结束的状态。某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。关于其他工程，产品化时期结束时可能就将文档与模型完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。依据产品的种类，产品化时期可能特不简单，也可能特不复杂。例如，公布

24、现有桌面产品的新公布版可能十分简单，而替换一个国家的航空交通管制系统可能就特不复杂。产品化时期的迭代期间所进行的活动取决于目标。例如，在进行调试时，实施和测试通常就足够了。然而，要是要添加新功能，迭代类似于构建时期中的迭代，需要进行分析设计。当基线差不多足够完善，能够部署到最终用户领域中时，那么进进产品化时期。通常，这要求系统的某个可用局部差不多到达了可同意的质量级不并完成用户文档，从而向用户的转移能够为所有方面都带来积极的结果。产品化时期的要紧目标是：进行 Beta 测试，按用户的期瞧确认新系统Beta 测试和相关于正在替换的遗留系统的并行操作转换操作数据库培训用户和维护人员市场营销、进行分

25、发和向销售人员进行新产品介绍与部署相关的工程，例如接进、商业包装和生产、销售介绍、现场人员培训调整活动，如进行调试、性能或可用性的增强依据产品的完整前景和验收标准，对部署基线进行的评估实现用户的自我支持能力在用户之间达成共识，即部署基线已完成在用户之间达成共识，即部署基线与前景的评估标准一致1.5.2.核心活动执行部署方案对最终用户支持材料定稿在开发现场测试可交付产品制作产品公布版获得用户相应基于相应调整产品使最终用户能够使用产品1.5.3.里程碑：产品公布产品化时期末是第四个重要的工程里程碑，即产品公布里程碑。现在，您确定是否到达目标，以及是否应该开始另一个开发周期。有时候，该里程碑可能与下

26、一周期的先启时期末重合。产品公布里程碑是工程验收复审成功完成的结果。评估标准产品化时期的要紧评估标准涉及到对以下咨询题的答复：用户是否满足？实际的资源消耗与方案的消耗相比是否能够同意？在产品公布里程碑处，公布后的维护周期同时开始。这涉及开始一个新的周期，或某个其他的维护公布版。提供的文档及模型核心文档及模型按照重要性排序里程碑状态产品工作版本已按照产品需求完成。客户应该能够使用最终产品。公布讲明完成。安装产品与模型完成。培训材料完成，以确保客户自己能够使用和维护产品。最终用户支持材料完成，以确保客户自己能够使用和维护产品。可选里程碑状态测试模型在客户想要进行现场测试的情况下，能够提供测试模型。

27、2.核心工作流程软件工程中的工作流程分为两局部：核心工作流程与核心支持工作流程核心工作流程 在工程中的流程业务需求建模分析设计实施测试部署核心支持工作流程在组织中的流程环境工程治理配置与变更治理2.1.业务需求建模.目的业务建模的目的在于：了解目标组织将要在其中部署系统的组织的结构及机制。了解目标组织中当前存在的咨询题并确定革新的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。为实现这些目标，业务建模工作流程讲明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。作为对这些模型的补充，还编写了以下文档：

28、补充业务规约词汇表2.1.2.业务建模工作流程2.1.3.提供的文档与模型商业逻辑建模USECASEROSE业务需求讲明书MSWORD专业词汇表英汉比立MSWORD风险讲明MSWORD复审讲明书2.1.4.文档模板参见工程治理标准名目下业务需求文档模板子名目2.2.分析设计2.2.1.目的分析设计的目的在于：将业务需求转换为今后系统的设计。逐步开发强壮的系统构架。使设计适合于实施环境，为提高性能而进行设计。2.2.2.分析设计工作流程2.2.3.提供的文档与模型系统总体设计报告MSWORD系统设计模型 DOMAINMODELROSE系统设计模型 DESIGNMODELROSE数据库设计模型PO

29、WERDESIGNER数据字典MSWORD系统具体设计报告MSWORD工作量化书MSWORD2.2.4.文档模板参见工程治理标准名目下分析设计文档模板子名目2.3.实施2.3.1.目的实施的目的包括：比立实施子系统的分层结构定义代码结构、以构件源文件、二进制文件、可执行文件以及其他文件等的方式实施类和对象、对已开发的构件按单元来测试，同时将各实施员或团队完成的结果集成到可执行系统中。实施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行讲明。测试的目的在于：核实对象之间的交互。核实软件的所有构件是否正确集成。核实所有需求是否差不多正确实施。确定缺陷并确保在部

30、署软件之前将缺陷解决。2.3.2.实施工作流程2.3.3.提供的文档与模型实施总结书MSWORD实施模型ROSE系统集成书MSWORD代码审核意见书MSWORD源代码MSWORD用户使用手册MSWORD错误解决记录手册MSWORD构件及其讲明2.3.4.文档模板参见工程治理标准名目下实施文档模板子名目2.4.工程治理2.4.1.目的本局部的目标是，通过提供一些工程治理的环境，使那个任务更加轻易完成。它尽管不是成功的秘诀，但它介绍了能够显著提高成功交付软件可能性的工程治理方法。工程治理的目的是：为对软件密集型工程进行治理提供框架。为工程的方案、人员配备、执行和监测提供有用的准那么。为治理风险提供

31、框架。该工作流程要紧侧重于迭代式开发流程的以下重要方面：风险治理方案迭代式工程，贯穿生命周期并针对特定的迭代监测迭代式工程的进度、指标2.4.2.工程治理工作流程2.4.3.提供的文档和模板风险治理方案MSEXCEL工作方案书MSEXCEL风险列表MSEXCEL迭代方案MSEXCEL咨询题解决方案MSEXCEL测试方案书MSEXCEL系统集成方案书MSEXCEL子系统集成方案书MSEXCEL工作单MSEXCEL产品验收方案MSEXCEL评测方案MSEXCEL工程方案复审意见书MSWORD开发总结MSWORD2.4.4.文档模板参见工程治理标准名目下工程治理文档模板子名目2.5.部署2.5.1.

32、目的部署工作流程用来描述那些为确保最终用户能够正常使用软件产品而进行的活动。部署工作流程描述了两种产品部署的模式：自定义安装通过 Internet 使用软件在每个实例中，都强调要在开发场所对产品进行测试，并在产品最终公布之前进行 Beta测试。尽管部署活动要紧集中于产品化时期，但在较早的一些时期中也会有一些为部署进行方案和预备的活动。2.5.2.提供的文档和模板部署方案安装文档公布讲明3.角色划分角色是抽象的职责定义，它定义的是所执行的一组活动和所拥有的一组文档与模型。角色通常由一个人或作为团队相互协作的多个人来实现。工程团队成员通常要履行许多不同的角色职能；就象一个人能够担任许多职务，一个人

33、也能够担任许多不同的角色。角色并不代表个人，而是讲明个人在业务中应该如何表现以及他们应该担当的责任。分析员角色集分析员角色集用于组织要紧从事需求猎取和研究的各种角色。角色业务流程分析员业务设计员业务模型复审员需求复审员系统分析员用户界面设计员.业务流程分析员业务流程分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何进行交互。人员配备担任业务流程分析员的人员应该善于简化工作，同时具有良好的沟通技巧。担任此角色的人员中必须要有具备业务领域知识的人才，但这种知识并不是所有人都必备的。业务流程分析员应该预备好开展以下工作：评估将在其中部署

34、工程最终产品的目标组织的情况。了解客户与用户的需求、策略和目标。协调目标组织的建模工作。在必要时对业务工程工作进行讨论和协调。对目标组织中所建议的任何变更进行本钞票效益分析。3.1.2.业务设计员业务设计员通过描述一个或几个业务用例的工作流程来具体讲明组织中某一局部的规约。他指定实现业务用例所需的业务角色及业务实体，同时将业务用例的行为分配给这些业务角色及业务实体。业务设计员定义一个或几个业务角色和业务实体的责任、操作、属性和关系。人员配备担任业务设计员的人员应该善于协调，同时具有良好的沟通技巧。他最好具有业务领域的知识，但这并不是担任此角色的所有人都必需的。业务设计员需要熟悉用于猎取业务模型

35、的工具。3.1.3.业务模型复审员业务模型复审员参与对业务用例模型和业务对象模型的正式复审。人员配备在大多数情况下，担任业务模型复审员的人员都需要具备业务领域的全然知识，或者对将用来实现业务自动化的技术具备全然的知识。业务模型复审员应该具备的另一种技能是具体了解所应用的业务工程技术。3.1.4.系统分析员系统分析员通过概括系统的功能和界定系统来领导和协调需求猎取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。人员配备担任系统分析员的人员应该善于协调，同时具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才，但这些知识并不是所有人都必须具备的。3.1.5.用

36、户界面设计员用户界面设计员通过以下方法领导和协调用户界面的原型设计和正式设计：分析对用户界面的需求，包括可用性需求；构建用户界面原型；邀请用户界面的最终用户参与可用性复审和使用测试会议；对用户界面的最终实施方案由设计员和实施员等其他开发人员创立进行复审并提供相应的相应。人员配备用户界面设计员不应实施用户界面。用户界面设计员的工作重点和时刻都应集中在用户界面的设计和“可视化成形，缘故如下：用户界面设计员所需的技能通常需要为当前的工程和应用程序类型可能具有独特的可用性需求而加以革新和优化，这需要投进时刻并集中工作重点。应该限制因“一心二用而带来的风险，即用户界面设计员不应该因为实施方面的考虑相关于

37、可用性方面的考虑而言而受到过多的碍事。3.2.开发角色集开发人员角色集用于组织要紧从事软件设计与开发的各种角色。角色构架设计师构架复审员代码复审员数据库设计员系统设计员设计复审员实施员集成员3.2.1.构架设计师构架设计师负责在整个工程中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的具体组织结构、元素的分组以及这些要紧分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。人员配备构架设计师必须多才多艺、成熟练达、洞察力强、经验丰富。如此，他才能在无法获得完整信息的情况下迅速领会咨询题并依据经验作出审慎的判定。更正确地讲，构架设计师或者构架团

38、队的成员必须兼具以下技能：经验：既包括在咨询题领域的经验通过完全了解需求，也包括在软件工程领域的经验。关于一个构架团队，这些素养要求可由各团队成员来分不担当，但其中至少要有一名构架设计师能够掌握工程的全局。领导才能：能够推动各个团队的技术进展，并能在压力下作出要害性的决策然后将其贯彻到底。要提高效率，构架设计师和工程经理必须紧密协作。构架设计师要紧负责解决技术咨询题，工程经理要紧负责解决行政治理咨询题。构架设计师必须有权在技术咨询题上作出决定。沟通：能够赢得他人的信任，以对其进行讲服、鼓舞和指导。构架设计师不能靠命令进行领导，而必须要赢得工程中其他人员的赞同。为了提高效率，构架设计师必须赢得工

39、程团队、工程经理、客户、用户群体以及治理团队的尊敬。以目标为中心、积极主动，不懈地追求成效。构架设计师是推工作程开展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师只有将注重力集中在该做的情况上，才能在工程中取得成功。从专业角度瞧，构架设计师必须具备系统设计员的所有能力。团队。要是工程较大，需要组建一个构架团队，那么应尽量广聚贤才，使该团队既拥有广泛的经验，又对软件工程流程具有一致的熟悉。构架团队不应该是由各团队、领域或承包商的代表组成的委员会。软件构架设计是一项长期的工作，始终都需要配备专职人员。3.2.2.构架复审员一般

40、而言，构架复审员负责方案并执行对软件构架的正式复审。人员配备构架复审员角色的人员配备要求与构架设计师的人员配备要求相同，但前者更加注重于技术咨询题。尽管对领导才能、成熟程度、有用主义及注重结果这些方面的重视程度稍低，但这些方面仍然重要：复审员可能会发现构架方面的缺陷，同时有可能会因为碍事工程的进度而不受送不。尽管如此，最好依旧在咨询题能够解决的时候及早提出要害性的咨询题，而不是盲目地追随进度，致使工程团队步进歧途。构架复审员需要依据本钞票对风险加以权衡，并对碍事工程成功的概括性咨询题维持一定的敏感性。构架复审员还需是善于讲服的沟通者，他应该能够提出并讨论对他人来讲比立敏感的咨询题。3.2.3.

41、代码复审员代码复审员负责确保源代码的质量，同时方案和执行源代码复审。在复审活动中，代码复审员还负责有关返工的任何相应意见。3.2.4.数据库设计人员数据库设计员定义表、索引、视图、约束条件、触发器、存储过程、表空间或存储参数，以及其他在存储、检索和删除永久性对象时所需的数据库专用结构。相关信息记录在数据模型中。人员配备数据库设计员必须在以下方面具有扎实的应用知识：数据库和面向对象的分析设计技术系统构架，包括数据库和系统性能调整，以及硬件和网络负载平衡数据库治理了解实施语言和环境3.2.5.系统设计员设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何依据实施环境对它们加以调整。此外，设

42、计员可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。人员配备设计员必须在以下方面具有扎实的应用知识：用例建模技术。系统需求。软件设计技术，包括：o 面向对象的分析设计技术。o 统一建模语言。实施系统时将利用的技术。3.2.6.设计复审员设计复审员方案并进行设计模型的正式复审。人员配备设计复审员的人员配备要求与构架设计师的人员配备要求相同，但前者更加侧重于技术咨询题。尽管对领导才能、成熟程度、有用主义及注重结果这些方面的重视程度稍低，但这些方面仍然重要：复审员可能会发现设计方面的缺陷，同时有可能会因为碍事工程的进度而不受送不。尽管如此，最好依旧在咨询题能够解决的时候

43、及早提出要害性的咨询题，而不是盲目地追随进度，致使工程团队步进歧途。设计复审员需要依据风险对本钞票加以权衡，并对碍事工程成功的概括性咨询题维持一定的敏感性。设计复审员还需是一个善讲服的沟通者，他应该能够提出并讨论对他人来讲比立敏感的咨询题。从技术知识的瞧点来瞧，设计复审员应该具有与设计员相同经验。3.2.7.实施员程序员实施员负责按照工程所采纳的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。要是必须创立驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及相应的子系统。人员配备实施员应具备的相应技能和知识包括：了解系统或所测试的应用程序熟悉测试及测试自动化

44、工具编程技能建议负责实施子系统的实施员同时应负责该子系统所包含的构件。3.2.8.集成员实施员将经测试的构件交付到集成工作区，由集成员在集成工作区将构件组合起来，生成一个工作版本。集成员还负责制定集成方案。集成在子系统和系统级不进行，每次集成均有独立的集成工作区。正如经测试的构件从实施员的专用开发工作区交付到子系统集成工作区一样，已集成的实施子系统也从子系统集成工作区交付到系统集成工作区。人员配备有时，担任集成员的个人还能够担任实施员或测试员。例如，要是工程较小，或者是在子系统级不上进行集成，就能够让同一个人兼任集成员和测试员，以做到有效地利用人力资源。实际上，关于子系统级不的集成和测试，一个

45、人就能够兼任实施员、集成员和测试员的角色。然而，关于系统级不的集成，建议应由独立的团队来执行集成和测试。3.3.测试员角色集测试员角色集用于组织要紧从事软件测试的各种角色。角色测试设计员测试员3.3.1.测试设计员测试设计员是测试中的要紧角色。该角色负责对测试进行方案、设计、实施和评估，包括：生成测试方案和测试模型执行测试过程评估测试范围和测试结果，以及测试的有效性生成测试评估摘要人员配备测试设计员应具备的相应技能和知识包括：了解系统或所测试的应用程序了解测试及测试自动化工具具备诊断和解决咨询题的技能编程技能最好具备3.3.2.测试员测试员负责执行测试，其职责包括：设置和执行测试评估测试执行过

46、程并修改错误人员配备测试员应具备的知识和技能可能会因为他们所执行的测试类型和/或测试时期的不同而有所差异。例如，在执行性能测试或集成时期的测试时，需要更高级的技能。在执行功能测试或系统测试时期的测试时，那么不需要太高级的技能。以下是测试员所需知识和技能的一些标准：高级测试员：了解系统或所测试的应用程序了解联网和系统构架了解测试及测试自动化工具具备诊断和解决咨询题的技能编程技能必备初级测试员：了解系统或所测试的应用程序了解测试及测试自动化工具具备诊断和解决咨询题的技能编程技能最好具备3.4.经理角色集经理角色集用于组织要紧从事软件工程流程的治理与配置的各种角色。角色变更操纵经理配置经理部署经理流

47、程工程师工程经理工程复审员3.4.1.变更操纵经理变更操纵经理这一角色负责对变更操纵过程进行监督。此角色通常由配置或变更操纵委员会(CCB)来担任，该委员会应该由有关各方包括客户、开发人员和用户的代表组成。在小型工程中，工程经理或软件构架设计师一人即可担当此角色。3.4.2.配置经理配置经理负责为产品开发团队提供全面的配置治理(CM)根底设施和环境。CM 的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，同时使所有工件均可依据需要包含在部署单元中。配置经理还必须确保 CM 环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写 CM 方案并汇报基于“变更请求

48、的进度统计信息。3.4.3.部署经理部署经理负责制定向用户群体公布产品的方案，并将其纳进布署方案中。3.4.4.流程工程师流程工程师对软件开发流程本身负责。其职责包括在工程开始前配置流程，并在开发工作过程中不断革新流程。人员配备担任流程工程师的人员需要具有广博的软件开发知识。良好的沟通技巧是对担任此角色的人员的全然要求。3.4.5.工程经理工程经理负责分配资源，确定优先级，协调与客户和用户之间的沟通。总而言之，确实是根基尽量使工程团队一直集中于正确的目标。工程经理还要建立一套工作方法，以确保工程工件的完整性和质量。3.4.6.工程复审员工程复审员负责在工程生命周期中的要紧复审点处评估工程方案工件和工程评估工件。在这些复审点发生的是特不重要的复审事件，因为在它们所标志的时刻点处，要是方案不够充分或者进展无法令人满足，工程特别可能会就此取消。人员配备工程复审员应具有多年的业务包括合同制订及谈判、技术和软件工程治理的经验，并具有业务治理级不的决策能力。工程复审员还应对风险治理原理具有出色的理解力，同时善于在信息不全或不明确的环境下进行评估。