项目管理规范-RUP管理实施样本.doc

项目管理规范-RUP管理实施第一部分：项目阶段第二部分：关键工作步骤 第三部分：角色划分 第四部分：现在实施项目规范考虑 概述 软件开发产品质量水平，是一个由来已久话题。而提升软件企业产品质量水平，必需改善软件产品开发过程。不过这里没有什么百试百灵灵丹妙药，我们必需依据本企业实际情况，参考中国外优异企业经验，总结出一个适合本企业软件开发模式。 此规范是基于CMM模型规范，以RUP软件工程过程为蓝本，由我本人依据项目实际情况而选择修改，从而使之适应该前应用级系统设计开发需要。 本文关键以RUP软件工程框架为主，省略复杂概念部分。着眼点放在控制软件产品开发步骤上，因为人员配置和软件分工现行情况限制，对其中部分细节进行了合并可省略，从而适应现在中国软件开发所要求。 Rational Unified Process（简称RUP）是一套软件工程过程（在下面介绍）。 在RUP过程中，我们能够看到它很强调一点：循环。 现在我们做每一个项目全部存在不停改变问题。用户需求改变、系统设计改变（可能是需求改变也可能是存在了技术问题）、编码改变（由测试和复审等步骤引发）等问题困扰着项目进行。处理这些问题方法就是不停循环。 这个规范是我依据自己见解整理编写而成，有不足之处请指教。 RUP介绍 Rational Unified Process（简称RUP）是一套软件工程过程，关键由Ivar Jacobson The Objectory Approch 和 The Rational Approch 发展而来。同时，它又是文档化软件工程产品，全部RUP 实施细节及方法导引均以Web文档方法集成在一张光盘上，由Rational企业开发、维护并销售，目前版本是RUP。RUP又是一套软件工程方法框架，各个组织可依据本身实际情况，和项目规模对RUP进行裁剪和修改，以制订出合乎需要软件工程过程。 RUP 吸收了多个开发模型优点，含有很好可操作性和实用性、从它一推出市场，凭借Booch、Ivar Jacobson、和Rumbaugh 在业界领导地位、和和统一建模语言（Unified Model Language , 以下简称UML）良好集成、多个CASE工具支持、不停升级和维护，快速得到业界广泛认同，越来越多组织以它作为软件开发模型框架。在RUP中，软件开发生命周期依据时间和RUP关键工作流划分为二维空间。如上图所表示，时间维从组织管理角度描述整个软件开发生命周期，是RUP动态组成部分。它可深入描述为周期（Cycle）、阶段（phase）、迭代(Iteration)。关键工作流从技术角度描述RUP静态组成部分，它可深入描述为行为（activities）、工作流（workflow）、产品（artifact）、工人（worker）。图中阴影部分描述了不一样工作流，在不一样时间段内工作量不一样。值得注意是，几乎全部工作流，在全部时间段内全部有工作量，只是大小不一样而已。这和Waterfall process 有显著不一样。RUP采取Use Case概念，把要开发系统依据各功效使用情况划分多个Use Case，并采取迭代思想把系统风险分布在四个阶段，风险越大迭代越要放在靠前阶段做，使软件产品风险不停降低；而不是像传统软件工程那样越往开发后期问题越多。所以RUP思想一推出就受到软件企业欢迎。根据RUP开发模式通常能够达成CMM2、3级水平。当然，了解和掌握RUP需要一个相对较长过程。1. 项目阶段 从管理见解来说，软件生命周期伴随时间分为四个依次进行阶段，每个阶段结束全部有一个关键里程碑；实质上，每个阶段就是两个关键里程碑之间时间跨度。在每个阶段结束时进行评定，以确定是否实现了此阶段目标。良好评定可使项目顺利进入下一阶段。 1.1. 计划阶段 在进度和工作量方面，全部阶段全部各不相同。尽管不一样项目有很大不一样，但一个中等规模项目标经典初始开发周期应该预先考虑到工作量和进度间分配： 先启 精化 构建 产品化 工作量 5% 20% 65% 10% 进度 10% 30% 50% 10% 可表示为下图 对于演进周期，先启和精化阶段就小得多了。能够自动完成一些构建工作工具将会缓解此现象，并使得构建阶段比先启阶段和精化阶段总和还要小很多。 经过这四个阶段就是一个开发周期；每次经过这四个阶段就会产生一代软件。除非项目“死亡”，不然经过反复一样先启阶段、精化阶段、构建阶段和产品化阶段次序，产品将演进为下一代产品，但每一次侧关键全部将放在不一样阶段上。这些随即周期称为演进周期。 伴随产品经历了多个周期，新一代产品随之产生。 1.2. 先启阶段 1.2.1. 目标 先启阶段基础目标是实现项目标生命周期目标中全部相关原因（如用户等）之间并行。 先启阶段关键对新开发工作含有重大意义，新工作中关键业务风险和需求风险问题必需在项目继续进行之前得四处理。对于关键是扩展现有系统项目来说，先启阶段较短，但关键仍然是确保项目值得进行而且能够进行。 先启阶段关键目标包含： 建立项目标软件规模和边界条件，包含运作前景、验收标准和期望软件中包含和不包含内容。 识别系统关键用例（也就是将造成关键设计折衷操作关键部分）。 评定整个项目标总体成本和进度（和对立即进行精化阶段进行更具体评定） 评定潜在风险（不可估计性起源） 准备项目标支持环境。 1.2.2. 关键活动 明确地说明项目规模。这包含了解环境和最关键需求和约束，方便于能够得出最终产品验收标准。 计划和准备商业理由。评定风险管理、人员配置、项目计划和成本/进度/收益率折衷备选方案。 综合考虑备选构架，评定设计和自制/外购/复用方面折衷，从而估算出成本、进度和资源。此处目标在于经过对部分概念证实来证实可行性。该证实可采取可模拟需求模型形式或用于探索被认为高风险区域初始原型。先启阶段原型设计工作应该限制在确信处理方案可行就能够了。该处理方案在精化和构建阶段实现。 准备项目标环境，评定项目和组织，选择工具，决定步骤中要改善部分。1.2.3. 里程碑：生命周期目标 生命周期目标里程碑评定项目标基础可行性。先启阶段末是第一个关键项目里程碑，即生命周期目标里程碑。此时，检验项目标生命周期目标，并决定继续进行项目还是取消项目。 1.2.3.1 评定标准 规模定义和成本进度估算中，全部相关原因（如用户等）可并行 对是否已经取得正确需求集达成一致意见，而且对这些需求了解是共同。 对成本进度估算、优先级、风险和开发步骤是否适宜达成一致意见。 已经确定全部风险而且有针对每个风险减轻风险策略。假如项目无法达成该里程碑，则它可能中途失败或需要进行相当多重新考虑。 1.2.3.2 提供文档及模型 关键文档及模型（根据关键性排序） 里程碑状态 前景 已经对关键项目标需求、关键功效和关键约束进行了统计。 商业理由 已经确定并得到了同意。 风险列表 已经确定了最初项目风险。 软件开发计划 已经确定了最初阶段及其连续时间和目标。软件开发计划中资源估算（尤其是时间、人员和开发环境成本）必需和商业理由一致。资源估算能够涵盖整个项目直到交付所需资源，也能够只包含进行精化阶段所需资源。此时，整个项目所需资源估算应该看作是大致“粗略估量”。该估算在每个阶段和每次迭代中全部会更新，而且伴随每次迭代变得愈加正确。 依据项目标需要，可能在某种条件下完成了一个或多个附带“计划”工件。另外，附带“指南”工件通常也最少完成了“初稿”。 迭代计划 第一个精化迭代迭代计划已经完成并经过了复审。 软件验收计划 完成复审并确定了基线；伴随其它需求发觉，将对其在随即迭代中进行改善。 项目专用模板 已使用文档模板制作了文档工件。 用例建模指南 确定了基线。 工具 选择了支持项目标全部工具。安装了对先启阶段工作必需工具。 词汇表 已经定义了关键术语；完成了词汇表复审。 用例模型（主角，用例） 已经确定了关键主角和用例，只为最关键用例简明说明了事件流。 领域模型（也叫做业务对象模型） 已经对系统中使用关键概念进行了统计和复审。在关键概念之间存在特定关系情况下，已用作对词汇表补充。 原型 概念原型一个或多个证据，以支持前景和商业理由、处理很具体风险。 1.3. 精化阶段 1.3.1. 目标 精化阶段目标是建立系统构架基线，方便为构建阶段关键设计和实施工作提供一个稳定基础。构架是基于对大多数关键需求（对系统构架有很大影响需求）考虑和风险评定发展而来。构架稳定性是经过一个或多个构架原型进行评定。 精化阶段关键目标包含： 确保构架、需求和计划足够稳定，充足降低风险，从而能够有预见性地确定完成开发所需成本和进度。对大多数项目来说，经过此里程碑也就相当于从简单快速低风险运作转移到高成本、高风险运作，而且在组织结构方面面临很多不利原因。 处理在构架方面含相关键意义全部项目风险 建立一个已确定基线构架，它是经过处理构架方面关键场景得到，这些场景通常能够显示项目标最大技术风险。 制作产品质量构件演进式原型，也可能同时制作一个或多个可放弃探索性原型，以减小特定风险，比如： 设计/需求折衷 构件复用 产品可行性或向用户和最终用户进行演示。 证实已建立基线构架将在合适时间、以合理成本支持系统需求。 建立支持环境。 为了实现这个关键目标，建立项目标支持环境也相同关键。这包含创建开发案例、创建模板和指南、安装工具。 1.3.2. 关键活动 快速确定构架、确定构架并为构架建立基线。 依据此阶段取得新信息改善前景，对推进构架和计划决议最关键用例建立可靠了解。 为构建阶段创建具体迭代计划并为其建立基线。 改善开发案例，定位开发环境，包含步骤和支持构建团体所需工具和自动化支持。 改善构架并选择构件。 评定潜在构件，充足了解自制/外购/复用决议，方便有把握地确定构建阶段成本和进度。集成了所选构架构件，并按关键场景进行了评定。经过这些活动得到经验有可能造成重新设计构架、考虑替换设计或重新考虑需求。1.3.3. 里程碑：生命周期构架 生命周期构架里程碑为系统构架建立管理基线，并使项目团体能够在构建阶段调整规模。 精化阶段末是第二个关键项目里程碑，即生命周期构架里程碑。此时，您检验具体系统目标和规模、选择构架和关键风险处理方案。 1.3.3.1 评定标准 产品前景和需求是稳定。 构架是稳定。 可实施原型表明已经找到了关键风险元素，而且得到妥善处理。 构建阶段迭代计划足够具体和真实，能够确保工作继续进行。 构建阶段迭代计划由可靠估算支持。 全部用户方人员一致认为，假如在目前构架环境中实施目前计划来开发完整系统，则目前前景能够实现。 实际资源花费和计划花费相比是能够接收。 假如项目无法达成该里程碑，则它可能中途失败或需要进行相当多重新考虑。 1.3.3.2 提供文档及模型 关键文档及模型（根据关键性排序） 里程碑状态 原型 已经创建了一个或多个可实施构架原型，以探索关键功效和构架上关键场景。 风险列表 已经进行了更新和复审。 新风险可能是构架方面，关键和处理非功效性需求相关。 项目专用模板 已使用文档模板制作了文档工件。 工具 已经安装了用于支持精化阶段工作工具。 软件构架文档 编写完成并确定了基线，假如系统是分布式或必需处理并行问题，则包含构架上关键用例具体说明（用例视图）、关键机制和设计元素标识（逻辑视图），和（布署模型）进程视图和布署视图定义。 设计模型（和全部组成部分） 制作完成并确定了基线。已经定义了构架方面关键场景用例实现，并将所需行为分配给了合适设计元素。 已经确定了构件并充足了解了自制/外购/复用决议，方便有把握地确定构建阶段成本和进度。集成了所选构架构件，并按关键场景进行了评定。经过这些活动得到经验有可能造成重新设计构架、考虑替换设计或重新考虑需求。 数据模型 制作完成并确定了基线。已经确定并复审了关键数据模型元素（比如关键实体、关系和表）。 实施模型（和全部组成工件，包含构件） 已经创建了最初结构，确定了关键构件并设计了原型。 前景 已经依据此阶段取得新信息进行了改善，对推进构架和计划决议最关键用例建立了可靠了解。 软件开发计划 已经进行了更新和扩展，方便涵盖构建阶段和产品化阶段。 指南，如设计指南和编程指南。 使用指南对工作进行了支持。 迭代计划 已经完成并复审了构建阶段迭代计划。 用例模型 用例模型（大约完成 80%）- 已经在用例模型调查中确定了全部用例、确定了全部主角并编写了大部分用例说明（需求分析）。 补充规约 已经对包含非功效性需求在内补充需求进行了统计和复审。 可选 里程碑状态 商业理由 假如构架调查不涵盖变更基础项目假设问题，则已经对商业理由进行了更新。 分析模型 可能作为正式工件进行了开发；进行了常常但不正式维护，正演进为设计模型早期版本。 培训材料 用户手册和其它培训材料。依据用例进行了初步起草。 假如系统含有复杂用户界面，可能需要培训材料。 1.4. 构建阶段 1.4.1. 目标 构建阶段目标是说明剩下需求，并基于已建立基线构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，关键在于管理资源和控制操作，方便优化成本、进度和质量。从这种意义上说，从先启和精化阶段到构建和产品化阶段，管理上思维定势经历了从知识产权开发到可布署产品开发转变。 构建阶段关键目标包含： 经过优化资源和避免无须要报废和返工，使开发成本降到最低。 快速达成足够好质量 快速完成有用版本（Alpha 版、Beta 版和其它测试公布版） 完成全部所需功效分析、开发和测试。 迭代式、递增式地开发随时能够公布到用户群完整产品。这意味着描述剩下用例和其它需求，充实设计，完成实施，并测试软件。 确定软件、场地和用户是否已经为布署应用程序作好准备。 开发团体工作实现某种程度并行。 即使是较小项目，也通常包含能够相互独立开发构件，从而使各团体之间实现自然并行（资源许可）。这种并行性可较大幅度地加速开发活动；但同时也增加了资源管理和工作步骤同时复杂程度。假如要实现任何关键并行，强壮构架至关关键。 1.4.2. 关键活动 资源管理，控制和步骤优化 完成构件开发并依据已定义评定标准进行测试 依据前景验收标准对产品公布版进行评定。1.4.3. 里程碑：最初操作性能 最初操作性能里程碑确定产品是否已经能够布署到 Beta 测试环境。 在最初操作性能里程碑，产品随时能够移交给产品化团体。此时，已开发了全部功效，并完成了全部 Alpha 测试（假如有测试）。除了软件之外，用户手册也已经完成，而且有对目前公布版说明。 1.4.3.1 评定标准 构建阶段评定标准包含到对以下问题回复： 该产品公布版是否足够稳定和成熟，可布署在用户群中？ 是否已准备好将产品公布到用户群？ 实际资源花费和计划相比是否仍能够接收？ 假如项目无法达成该里程碑，产品化可能要推迟一个公布版。 1.4.3.2 提供文档及模型 关键文档及模型（根据关键性排序） 里程碑状态 “系统” 可实施系统本身随时能够进行“Beta”测试。 布署计划 已开发最初版本、进行了复审并建立了基线。 实施模型（和全部组成部分，包含构件） 对在精化阶段创建模型进行了扩展；构建阶段末期完成全部构件创建。 测试模型（和全部组成部分） 为验证构建阶段所创建可实施公布版而设计并开发测试。 培训材料 用户手册和其它培训材料。依据用例进行了初步起草。 假如系统含有复杂用户界面，可能需要培训材料。 迭代计划 已经完成并复审了产品化阶段迭代计划。 设计模型（和全部组成部分） 已经用新设计元素进行了更新，这些设计元素是在完成全部需求期间确定。 项目专用模板 已使用文档模板制作了文档模板。 工具 已经安装了用于支持构建阶段工作工具。 数据模型 已经用支持连续实施所需全部元素（比如，表、索引、对象关系型映射等）进行了更新 可选 里程碑状态 补充规约 已经用构建阶段发觉新需求（假如有）进行了更新。 用例模型（主角，用例） 已经用构建阶段发觉新用例（假如有）进行了更新。 1.5. 产品化阶段 1.5.1. 目标 产品化阶段关键是确保最终用户能够使用软件。产品化阶段可跨越多个迭代，包含测试处于公布准备中产品和基于用户反馈进行较小调整。在生命周期中该点处，用户反馈应关键侧重于调整产品、配置、安装和可用性问题，全部较大结构上问题应该在项目生命周期早期阶段就已得四处理。 在产品化阶段生命周期结束时，目标应该已经实现，项目应处于将结束状态。一些情况下，目前生命周期结束可能是同一产品另一生命周期开始，从而造成产生产品下一代或下一版本。对于其它项目，产品化阶段结束时可能就将文档和模型完全交付给第三方，第三方负责已交付系统操作、维护和扩展。 依据产品种类，产品化阶段可能很简单，也可能很复杂。比如，公布现有桌面产品新公布版可能十分简单，而替换一个国家航空交通管制系统可能就很复杂。 产品化阶段迭代期间所进行活动取决于目标。比如，在进行调试时，实施和测试通常就足够了。 不过，假如要添加新功效，迭代类似于构建阶段中迭代，需要进行分析设计。 当基线已经足够完善，能够布署到最终用户领域中时，则进入产品化阶段。通常，这要求系统某个可用部分已经达成了可接收质量等级并完成用户文档，从而向用户转移能够为全部方面全部带来主动结果。 产品化阶段关键目标是： 进行 Beta 测试，按用户期望确定新系统 Beta 测试和相对于正在替换遗留系统并行操作 转换操作数据库 培训用户和维护人员 市场营销、进行分发和向销售人员进行新产品介绍 和布署相关工程，比如接入、商业包装和生产、销售介绍、现场人员培训 调整活动，如进行调试、性能或可用性增强 依据产品完整前景和验收标准，对布署基线进行评定 实现用户自我支持能力 在用户之间达成共识，即布署基线已完成 在用户之间达成共识，即布署基线和前景评定标准一致 1.5.2. 关键活动 实施布署计划 对最终用户支持材料定稿 在开发觉场测试可交付产品 制作产品公布版 取得用户反馈 基于反馈调整产品 使最终用户能够使用产品1.5.3. 里程碑：产品公布 产品化阶段末是第四个关键项目里程碑，即产品公布里程碑。此时，您确定是否达成目标，和是否应该开始另一个开发周期。有时候，该里程碑可能和下一周期先启阶段末重合。产品公布里程碑是项目验收复审成功完成结果。 1.5.3.1 评定标准 产品化阶段关键评定标准包含到对以下问题回复： 用户是否满意？ 实际资源花费和计划花费相比是否能够接收？ 在产品公布里程碑处，公布后维护周期同时开始。这包含开始一个新周期，或某个其它维护公布版。 1.5.3.2 提供文档及模型 关键文档及模型（根据关键性排序） 里程碑状态 产品工作版本 已根据产品需求完成。用户应该能够使用最终产品。 公布说明 完成。 安装产品和模型 完成。 培训材料 完成，以确保用户自己能够使用和维护产品。 最终用户支持材料 完成，以确保用户自己能够使用和维护产品。 可选 里程碑状态 测试模型 在用户想要进行现场测试情况下，能够提供测试模型。 2. 关键工作步骤 软件工程中工作步骤分为两部分：关键工作步骤和关键支持工作步骤 关键工作步骤（在项目中步骤） 业务需求建模 分析设计 实施 测试 布署 关键支持工作步骤（在组织中步骤） 环境 项目管理 配置和变更管理2.1. 业务需求建模2.1.1. 目标业务建模目标在于： 了解目标组织（将要在其中布署系统组织）结构及机制。 了解目标组织中目前存在问题并确定改善可能性。 确保用户、最终用户和开发人员就目标组织达成共识。 导出支持目标组织所需系统需求。为实现这些目标，业务建模工作步骤说明了怎样确定新目标组织前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中步骤、角色和职责。作为对这些模型补充，还编写了以下文档： 补充业务规约 词汇表2.1.2. 业务建模工作步骤2.1.3. 提供文档和模型商业逻辑建模（USE CASE）（ROSE）业务需求说明书（MS WORD）专业词汇表（英汉对照）（MS WORD）风险说明（MS WORD）复审说明书2.1.4. 文档模板参见项目管理规范目录下业务需求文档模板子目录2.2. 分析设计2.2.1. 目标分析设计目标在于： 将业务需求转换为未来系统设计。 逐步开发强壮系统构架。 使设计适合于实施环境，为提升性能而进行设计。2.2.2. 分析设计工作步骤2.2.3. 提供文档和模型系统总体设计汇报（MS WORD）系统设计模型DOMAIN MODEL（ROSE）系统设计模型DESIGN MODEL （ROSE）数据库设计模型 （POWER DESIGNER）数据字典（MS WORD）系统具体设计汇报（MS WORD）工作量化书（MS WORD）2.2.4. 文档模板参见项目管理规范目录下分析设计文档模板子目录2.3. 实施2.3.1. 目标实施目标包含： 对照实施子系统分层结构定义代码结构、 以构件（源文件、二进制文件、可实施文件和其它文件等）方法实施类和对象、 对已开发构件按单元来测试，而且 将各实施员（或团体）完成结果集成到可实施系统中。实施工作步骤范围仅限于怎样对各个类进行单元测试。系统测试和集成测试将在测试工作步骤中进行说明。测试目标在于： 核实对象之间交互。 核实软件全部构件是否正确集成。 核实全部需求是否已经正确实施。 确定缺点并确保在布署软件之前将缺点处理。2.3.2. 实施工作步骤2.3.3. 提供文档和模型实施总结书（MS WORD）实施模型（ROSE）系统集成书（MS WORD）代码审核意见书（MS WORD）源代码（MS WORD）用户使用手册（MS WORD）错误处理统计手册（MS WORD）构件及其说明2.3.4. 文档模板参见项目管理规范目录下实施文档模板子目录 2.4. 项目管理2.4.1. 目标本部分目标是，经过提供部分项目管理环境，使这个任务愈加轻易完成。它即使不是成功秘诀，但它介绍了能够显著提升成功交付软件可能性项目管理方法。项目管理目标是： 为对软件密集型项目进行管理提供框架。 为项目标计划、人员配置、实施和监测提供实用准则。 为管理风险提供框架。该工作步骤关键侧重于迭代式开发步骤以下关键方面： 风险管理 计划迭代式项目，贯穿生命周期并针对特定迭代 监测迭代式项目标进度、指标2.4.2. 项目管理工作步骤2.4.3. 提供文档和模板风险管理计划（MS EXCEL）工作计划书（MS EXCEL）风险列表（MS EXCEL）迭代计划（MS EXCEL）问题处理计划（MS EXCEL）测试计划书（MS EXCEL）系统集成计划书（MS EXCEL）子系统集成计划书（MS EXCEL）工作单（MS EXCEL）产品验收计划（MS EXCEL）评测计划（MS EXCEL）项目计划复审意见书（MS WORD）开发总结（MS WORD）2.4.4. 文档模板参见项目管理规范目录下项目管理文档模板子目录2.5. 布署2.5.1. 目标布署工作步骤用来描述那些为确保最终用户能够正常使用软件产品而进行活动。布署工作步骤描述了两种产品布署模式： 自定义安装 经过 Internet 使用软件在每个实例中，全部强调要在开发场所对产品进行测试，并在产品最终公布之前进行 Beta 测试。尽管布署活动关键集中于产品化阶段，但在较早部分阶段中也会有部分为布署进行计划和准备活动。 2.5.2. 提供文档和模板布署计划 安装文档 公布说明3. 角色划分角色是抽象职责定义，它定义是所实施一组活动和所拥有一组文档和模型。角色通常由一个人或作为团体相互协作多个人来实现。项目团体组员通常要推行很多不一样角色职能；就象一个人能够担任很多职务，一个人也能够担任很多不一样角色。角色并不代表个人，而是说明个人在业务中应该怎样表现和她们应该负担责任。分析员角色集分析员角色集用于组织关键从事需求获取和研究多种角色。角色 业务步骤分析员 业务设计员 业务模型复审员 需求复审员 系统分析员 用户界面设计员3.1.1. 业务步骤分析员业务步骤分析员经过概括和界定作为建模对象组织来领导和协调业务用例建模。比如，确定存在哪些业务主角和业务用例，她们之间怎样进行交互。人员配置 担任业务步骤分析员人员应该善于简化工作，而且含有良好沟通技巧。担任此角色人员中必需要有含有业务领域知识人才，但这种知识并不是全部些人全部必备。业务步骤分析员应该准备好开展以下工作： 评定将在其中布署项目最终产品目标组织情况。 了解用户和用户需求、策略和目标。 协调目标组织建模工作。 在必需时对业务工程工作进行讨论和协调。 对目标组织中所提议任何变更进行成本效益分析。 3.1.2. 业务设计员业务设计员经过描述一个或多个业务用例工作步骤来具体说明组织中某一部分规约。她指定实现业务用例所需业务角色及业务实体，而且将业务用例行为分配给这些业务角色及业务实体。业务设计员定义一个或多个业务角色和业务实体责任、操作、属性和关系。人员配置 担任业务设计员人员应该善于协调，而且含有良好沟通技巧。她最好含有业务领域知识，但这并不是担任此角色全部些人全部必需。业务设计员需要熟悉用于获取业务模型工具。3.1.3. 业务模型复审员业务模型复审员参与对业务用例模型和业务对象模型正式复审。 人员配置 在大多数情况下，担任业务模型复审员人员全部需要含有业务领域基础知识，或对将用来实现业务自动化技术含有基础知识。业务模型复审员应该含有另一个技能是具体了解所应用业务工程技术。3.1.4. 系统分析员系统分析员经过概括系统功效和界定系统来领导和协调需求获取及用例建模。比如，确定存在哪些主角和用例，和她们之间怎样交互。人员配置 担任系统分析员人员应该善于协调，而且含有良好沟通技巧。担任此角色人员中必需要有含有业务和技术领域知识人才，但这些知识并不是全部些人全部必需含有。3.1.5. 用户界面设计员用户界面设计员经过以下方法领导和协调用户界面原型设计和正式设计： 分析对用户界面需求，包含可用性需求； 构建用户界面原型； 邀请用户界面最终用户参与可用性复审和使用测试会议； 对用户界面最终实施方案（由设计员和实施员等其它开发人员创建）进行复审并提供对应反馈。人员配置 用户界面设计员不应实施用户界面。用户界面设计员工作关键和时间全部应集中在用户界面设计和“可视化成形”，原因以下： 用户界面设计员所需技能通常需要为目前项目和应用程序类型（可能含有独特可用性需求）而加以改善和优化，这需要投入时间并集中工作关键。 应该限制因“一心二用”而带来风险，即用户界面设计员不应该因为实施方面考虑（相对于可用性方面考虑而言）而受到过多影响。3.2. 开发角色集开发人员角色集用于组织关键从事软件设计和开发多种角色。角色 构架设计师 构架复审员 代码复审员 数据库设计员 系统设计员 设计复审员 实施员 集组员3.2.1. 构架设计师构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图整体结构：视图具体组织结构、元素分组和这些关键分组之间接口。所以，和其它角色相比，构架设计师见解重在广度，而不是深度。 人员配置 构架设计师必需多才多艺、成熟练达、洞察力强、经验丰富。这么，她才能在无法取得完整信息情况下快速领会问题并依据经验作出审慎判定。更正确地说，构架设计师（或构架团体组员）必需兼具以下技能： 经验：既包含在问题领域经验（经过根本了解需求），也包含在软件工程领域经验。对于一个构架团体，这些素质要求可由各团体组员来分别负担，但其中最少要有一名构架设计师能够把握项目标全局。 领导才能：能够推进各个团体技术进展，并能在压力下作出关键性决议然后将其落实到底。要提升效率，构架设计师和项目经理必需紧密协作。构架设计师关键负责处理技术问题，项目经理关键负责处理行政管理问题。构架设计师必需有权在技术问题上作出决定。 沟通：能够赢得她人信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必需要赢得项目中其它人员赞同。为了提升效率，构架设计师必需赢得项目团体、项目经理、用户、用户群体和管理团体尊敬。 以目标为中心、主动主动，不懈地追求成效。构架设计师是推进项目发展技术动力，而不是空想家。在其职业生涯中，成功构架设计师一直全部要在捉摸不定和承受压力情况下作出折衷决定。构架设计师只有将注意力集中在该做事情上，才能在项目中取得成功。从专业角度看，构架设计师必需含有系统设计员全部能力。团体。假如项目较大，需要组建一个构架团体，则应尽可能广聚贤才，使该团体既拥有广泛经验，又对软件工程步骤含有一致认识。构架团体不应该是由各团体、领域或承包商代表组成委员会。软件构架设计是一项长久工作，一直全部需要配置专职人员。3.2.2. 构架复审员通常而言，构架复审员负责计划并实施对软件构架正式复审。 人员配置 构架复审员角色人员配置要求和构架设计师人员配置要求相同，但前者愈加重视于技术问题。即使对领导才能、成熟程度、实用主义及重视结果这些方面重视程度稍低，但这些方面仍然关键：复审员可能会发觉构架方面缺点，而且有可能会因为影响项目标进度而不受欢迎。尽管如此，最好还是在问题能够处理时候及早提出关键性问题，而不是盲目地追随进度，致使项目团体步入歧途。构架复审员需要依据成本对风险加以权衡，并对影响项目成功概括性问题保持一定敏感性。构架复审员还需是善于说服沟通者，她应该能够提出并讨论对她人来说比较敏感问题。3.2.3. 代码复审员 代码复审员负责确保源代码质量，而且计划和实施源代码复审。在复审活动中，代码复审员还负责相关返工任何反馈意见。3.2.4. 数据库设计人员数据库设计员定义表、索引、视图、约束条件、触发器、存放过程、表空间或存放参数，和其它在存放、检索和删除永久性对象时所需数据库专用结构。相关信息统计在数据模型中。 人员配置 数据库设计员必需在以下方面含有扎实应用知识： 数据库和面向对象分析设计技术 系统构架，包含数据库和系统性能调整，和硬件和网络负载平衡 数据库管理 了解实施语言和环境3.2.5. 系统设计员设计员定义一个或多个类职责、操作、属性及关系，并确定应怎样依据实施环境对它们加以调整。另外，设计员可能要负责一个或多个设计包或设计子系统，其中包含设计包或子系统所拥有全部类。 人员配置 设计员必需在以下方面含有扎实应用知识： 用例建模技术。 系统需求。 软件设计技术，包含：o 面向对象分析设计技术。o 统一建模语言。 实施系统时将利用技术。3.2.6. 设计复审员设计复审员计划并进行设计模型正式复审。 人员配置 设计复审员人员配置要求和构架设计师人员配置要求相同，但前者愈加侧重于技术问题。即使对领导才能、成熟程度、实用主义及重视结果这些方面重视程度稍低，但这些方面仍然关键：复审员可能会发觉设计方面缺点，而且有可能会因为影响项目标进度而不受欢迎。尽管如此，最好还是在问题能够处理时候及早提出关键性问题，而不是盲目地追随进度，致使项目团体步入歧途。设计复审员需要依据风险对成本加以权衡，并对影响项目成功概括性问题保持一定敏感性。设计复审员还需是一个善说服沟通者，她应该能够提出并讨论对她人来说比较敏感问题。从技术知识见解来看，设计复审员应该含有和设计员相同经验。3.2.7. 实施员（程序员）实施员负责根据项目所采取标准来进行构件开发和测试，方便将构件集成到更大子系统中。假如必需创建驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及对应子系统。人员配置 实施员应含有对应技能和知识包含： 了解系统或所测试应用程序 熟悉测试及测试自动化工具 编程技能提议负责实施子系统实施员同时应负责该子系统所包含构件。3.2.8. 集组员实施员将经测试构件交付到集成工作区，由集组员在集成工作区将构件组合起来，生成一个工作版本。集组员还负责制订集成计划。集成在子系统和系统等级进行，每次集成全部有独立集成工作区。正如经测试构件从实施员专用开发工作区交付到子系统集成工作区一样，已集成实施子系统也从子系统集成工作区交付到系统集成工作区。人员配置 有时，担任集组员个人还能够担任实施员或测试员。比如，假如项目较小，或是在子系统等级上进行集成，就能够让同一个人兼任集组员和测试员，以做到有效地利用人力资源。实际上，对于子系统等级集成（和测试），一个人就能够兼任实施员、集组员和测试员角色。不过，对于系统等级集成，提议应由独立团体来实施集成和测试。3.3. 测试员角色集测试员角色集用于组织关键从事软件测试多种角色。角色 测试设计员 测试员3.3.1. 测试设计员测试设计员是测试中关键角色。该角色负责对测试进行计划、设计、实施和评定，包含： 生成测试计划和测试模型 实施测试过程 评定测试范围和测试结果，和测试有效性 生成测试评定摘要人员配置 测试设计员应含有对应技能和知识包含： 了解系统或所测试应用程序 了解测试及测试自动化工具 含有诊疗和处理问题技能 编程技能（最好含有）3.3.2. 测试员测试员负责实施测试，其职责包含： 设置和实施测试 评定测试实施过程并修改错误人员配置 测试员应含有知识和技能可能会因为她们所实施测试类型和/或测试阶段不一样而有所差异。比如，在实施性能测试或集成阶段测试时，需要更高级技能。在实施功效测试或系统测试阶段测试时，则不需要太高级技能。以下是测试员所需知识和技能部分标准：高级测试员： 了解系统或所测试应用程序 了解联网和系统构架 了解测试及测试自动化工具 含有诊疗和处理问题技能 编程技能（必备）初级测试员： 了解系统或所测试应用程序 了解测试及测