软件开发管理规范机构图标软件开发管理规范文件状态： 草稿 正式发布 正在修改文件标识：当前版本：1.0作 者：许昌禄完成日期：2006-2-15机构公开信息版 本 历 史版本/状态作者参与者起止日期备注V1.0许昌禄2006-2-15 目 录 0.文档介绍60.1文档目的60.2文档范围60.3读者对象60.4参考文献60.5术语与缩写解释71.项目阶段71.1计划阶段71.1.1先启阶段71.1.1.1目标71.1.1.2提供的文档及模型81.1.2精化阶段81.1.2.1目标81.1.2.2提供的文档及模型91.1.3构建阶段101.1.3.1目标101.1.3.2提供的文档及模型101.1.4产品化阶段111.1.4.1目标111.1.4.2提供的文档及模型122.核心工作流程122.1业务需求建模122.1.1目的122.1.2提供的文档与模型132.2分析设计132.2.1目的132.2.2提供的文档与模型132.3实施132.3.1目的132.3.2提供的文档与模型142.4项目管理142.4.1目的142.4.2提供的文档和模板142.5部署152.5.1目的152.5.2提供的文档和模板153.角色划分153.1分析员角色集163.1.1业务流程分析员163.1.1.1人员配备163.1.2业务设计员163.1.2.1人员配备163.1.3业务模型复审员173.1.3.1人员配备173.1.4系统分析员173.1.4.1人员配备173.1.5用户界面设计员173.1.5.1人员配备173.2开发角色集183.2.1构架设计师183.2.1.1人员配备183.2.2构架复审员183.2.2.1人员配备183.2.3代码复审员193.2.4数据库设计人员193.2.4.1人员配备193.2.5系统设计员193.2.5.1人员配备193.2.6设计复审员203.2.6.1人员配备203.2.7实施员（程序员）203.2.7.1人员配备203.2.8集成员203.2.8.1人员配备213.3测试员角色集213.3.1测试设计员213.3.1.1人员配备213.3.2测试员223.3.2.1人员配备223.4经理角色集223.4.1变更控制经理223.4.2配置经理223.4.3部署经理233.4.4流程工程师233.4.5项目经理233.4.6项目复审员230. 文档介绍软件开发管理规范（以下简称开发规范）是根据ISO9001和CMM3级的要求，以RUP软件工程过程为蓝本，并结合威士科技有限公司的实际开发情况而编写的软件开发指导性规范。开发规范可以作为威士科技内部一般软件项目开发和项目管理时的指导性规范。0.1 文档目的软件项目管理的根本目的是按时、保质、保量完成预期交付的成果。项目管理要让整个部门能清楚理解项目实施的目的、影响、进度，应做到项目组所有员工都应理解项目实施的原因、意义及客户的要求。在项目管理中还能看到公司高层领导通过实际行动表现出来的对于项目实施的支持与帮助，通过以制度化管理来组织合理安排员工的工作职责和角色转换。0.2 文档范围开发规范为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。的目的在于协助管理者在他们的机构中产生有效的文档。 开发规范涉及策略、标准、规程、资源和计划，管理者必须关注这些内容，以便有效地管理软件文档。 开发规范准期望应用于各种类型的软件，从简单的程序到复杂的软件系统。并期望覆盖各种类型的软件文档，作用于软件生存期的各个阶段。 不论项目的大小，软件文档管理的原则是一致的。对于小项目，可以不采用开发规范中规定的有关细节。管理者可剪裁这些内容以满足他们的特殊需要。 0.3 读者对象读者可能是管理者、分析员、开发人员、维护人员等0.4 参考文献GB 8566-88 计算机软件开发规范 GB 8567-88 计算机软件产品开发文件编制指南 GB/T 11457-1995 软件工程术语0.5 术语与缩写解释缩写、术语解 释SPP精简并行过程，Simplified Parallel ProcessRUP统一建模过程Rational Unified ProcessBD基本设计FD功能设计SD结构设计MK编码CT结合测试ST系统测试1. 项目阶段从管理的观点来说，软件生命周期随着时间分为四个依次进行的阶段，每个阶段的结束都有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。1.1 计划阶段在进度和工作量方面，所有阶段都各不相同。尽管不同的项目有很大的不同，但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度间的分配： 先启 精化 构建 产品化 工作量 5 % 20 % 65 % 10% 进度 10 % 30 % 50 % 10% 1.1.1 先启阶段1.1.1.1 目标先启阶段的基本目标是实现项目的生命周期目标中所有相关因素（如客户等）之间的并行。先启阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说，先启阶段较短，但重点仍然是确保项目值得进行而且可以进行。 先启阶段的主要目标包括： l 建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望软件中包括和不包括的内容。 l 识别系统的关键用例（也就是将造成重要设计折衷操作的主要部分）。 l 评估整个项目的总体成本和进度（以及对即将进行的精化阶段进行更详细的评估） l 评估潜在风险（不可预测性的来源） l 准备项目的支持环境。 1.1.1.2 提供的文档及模型文档及模型里程碑状态软件开发计划 已经确定了最初阶段及其持续时间和目标。软件开发计划中的资源估算（特别是时间、人员和开发环境成本）。资源估算可以涵盖整个项目直到交付所需的资源，也可以只包括进行精化阶段所需的资源。此时，整个项目所需的资源估算应该看作是大致的“粗略估计”。该估算在每个阶段和每次迭代中都会更新，并且随着每次迭代变得更加准确。 迭代计划 第一个精化迭代的迭代计划已经完成并经过了复审。 项目专用模板 已使用文档模板编写了文档。 用例建模指南 确定了基线。 工具 选择了支持项目的所有工具。安装了对先启阶段的工作必要的工具。 词汇表 已经定义了重要的术语；完成了词汇表的复审。 用例模型（主角，用例） 已经确定了重要的主角和用例，只为最关键的用例简要说明了事件流。 领域模型（也叫做业务对象模型） 已经对系统中使用的核心概念进行了记录和复审。在核心概念之间存在特定关系的情况下，已用作对词汇表的补充。 1.1.2 精化阶段1.1.2.1 目标化阶段的目标是建立系统构架的基线，以便为构建阶段的主要设计和实施工作提供一个稳定的基础。构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。 精化阶段的主要目标包括： 保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。对大多数项目来说，通过此里程碑也就相当于从简单快速的低风险运作转移到高成本、高风险的运作，并且在组织结构方面面临许多不利因素。 理在构架方面具有重要意义的所有项目风险 立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的最大技术风险。 作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探索性原型，以减小特定风险，例如： l 设计/需求折衷 l 构件复用 l 产品可行性或向客户和最终用户进行演示。 l 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。 建立支持环境。 了实现这个主要目标，建立项目的支持环境也同等重要。这包括创建开发案例、创建模板和指南、安装工具。 1.1.2.2 提供的文档及模型文档及模型里程碑状态原型 已经创建了一个或多个可执行构架原型，以探索关键功能和构架上的重要场景。 风险列表 已经进行了更新和复审。新的风险可能是构架方面的，主要与处理非功能性需求有关。 项目专用模板 已使用文档模板编写了文档。 工具 已经安装了用于支持精化阶段工作的工具。 软件构架文档 编写完成并确定了基线，如果系统是分布式的或必须处理并行问题，则包括构架上重要用例的详细说明（用例视图）、关键机制和设计元素的标识（逻辑视图），以及（部署模型的）进程视图和部署视图的定义。 设计模型（和所有组成部分） 制作完成并确定了基线。已经定义了构架方面重要场景的用例实现，并将所需行为分配给了适当的设计元素。已经确定了构件并充分理解了自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。 数据模型 制作完成并确定了基线。已经确定并复审了主要的数据模型元素（例如重要实体、关系和表）。 实施模型 已经创建了最初结构，确定了主要构件并设计了原型。 前景 已经根据此阶段获得的新信息进行了改进，对推动构架和计划决策的最关键用例建立了可靠的了解。 软件开发计划 已经进行了更新和扩展，以便涵盖构建阶段和产品化阶段。 指南，如设计指南和编程指南。 使用指南对工作进行了支持。 迭代计划 已经完成并复审了构建阶段的迭代计划。 用例模型 用例模型（大约完成 80%）- 已经在用例模型调查中确定了所有用例、确定了所有主角并编写了大部分用例说明（需求分析）。 补充规约 已经对包括非功能性需求在内的补充需求进行了记录和复审。 可选里程碑状态培训材料 用户手册与其他培训材料。根据用例进行了初步起草。如果系统具有复杂的用户界面，可能需要培训材料。 1.1.3 构建阶段1.1.3.1 目标建阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。从这种意义上说，从先启和精化阶段到构建和产品化阶段，管理上的思维定势经历了从知识产权开发到可部署产品开发的转变。 构建阶段的主要目标包括： l 通过优化资源和避免不必要的报废和返工，使开发成本降到最低。 l 快速达到足够好的质量 l 快速完成有用的版本（Alpha 版、Beta 版和其他测试发布版） l 完成所有所需功能的分析、开发和测试。 l 迭代式、递增式地开发随时可以发布到用户群的完整产品。这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。 l 确定软件、场地和用户是否已经为部署应用程序作好准备。 l 开发团队的工作实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现自然的并行（资源允许）。这种并行性可较大幅度地加速开发活动；但同时也增加了资源管理和工作流程同步的复杂程度。如果要实现任何重要的并行，强壮的构架至关重要。1.1.3.2 提供的文档及模型文档及模型里程碑状态“系统” 可执行系统本身随时可以进行“Beta”测试。 部署计划 已开发最初版本、进行了复审并建立了基线。 实施模型（以及所有组成部分，包括构件） 对在精化阶段创建的模型进行了扩展；构建阶段末期完成所有构件的创建。 测试模型（和所有组成部分） 为验证构建阶段所创建的可执行发布版而设计并开发的测试。 培训材料 用户手册与其他培训材料。根据用例进行了初步起草。如果系统具有复杂的用户界面，可能需要培训材料。 迭代计划 已经完成并复审了产品化阶段的迭代计划。 设计模型（和所有组成部分） 已经用新设计元素进行了更新，这些设计元素是在完成所有需求期间确定的。 项目专用模板 已使用文档模板编写了文档。 工具 已经安装了用于支持构建阶段工作的工具。 数据模型 已经用支持持续实施所需的所有元素（例如，表、索引、对象关系型映射等）进行了更新 可选里程碑状态补充规约 已经用构建阶段发现的新需求（如果有）进行了更新。 用例模型（主角，用例） 已经用构建阶段发现的新用例（如果有）进行了更新。 1.1.4 产品化阶段1.1.4.1 目标品化阶段的重点是确保最终用户可以使用软件。产品化阶段可跨越几个迭代，包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。在生命周期中的该点处，用户反馈应主要侧重于调整产品、配置、安装和可用性问题，所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。 产品化阶段生命周期结束时，目标应该已经实现，项目应处于将结束的状态。某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。对于其他项目，产品化阶段结束时可能就将文档与模型完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。 当基线已经足够完善，可以部署到最终用户领域中时，则进入产品化阶段。通常，这要求系统的某个可用部分已经达到了可接受的质量级别并完成用户文档，从而向用户的转移可以为所有方面都带来积极的结果。 产品化阶段的主要目标是： l 进行 Beta 测试，按用户的期望确认新系统 l Beta 测试和相对于正在替换的遗留系统的并行操作 l 转换操作数据库 l 培训用户和维护人员 l 市场营销、进行分发和向销售人员进行新产品介绍 l 与部署相关的工程，例如接入、商业包装和生产、销售介绍、现场人员培训 l 调整活动，如进行调试、性能或可用性的增强 l 根据产品的完整前景和验收标准，对部署基线进行的评估 l 实现用户的自我支持能力 l 在用户之间达成共识，即部署基线已完成 l 在用户之间达成共识，即部署基线与前景的评估标准一致 1.1.4.2 提供的文档及模型文档及模型里程碑状态产品工作版本 已按照产品需求完成。客户应该可以使用最终产品。 发布说明 完成。 安装产品与模型 完成。 培训材料 完成，以确保客户自己可以使用和维护产品。 最终用户支持材料 完成，以确保客户自己可以使用和维护产品。 可选里程碑状态测试模型 在客户想要进行现场测试的情况下，可以提供测试模型。 2. 核心工作流程2.1 业务需求建模2.1.1 目的业务建模的目的在于：l 了解目标组织（将要在其中部署系统的组织）的结构及机制。l 了解目标组织中当前存在的问题并确定改进的可能性。l 确保客户、最终用户和开发人员就目标组织达成共识。l 导出支持目标组织所需的系统需求。实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。作为对这些模型的补充，还需要编写以下文档： 补充业务规约 词汇表2.1.2 提供的文档与模型l 商业逻辑建模（USE CASE）l 业务需求说明书（MS WORD）l 专业词汇表（英汉对照）（MS WORD）l 风险说明（MS WORD）l 复审说明书2.2 分析设计2.2.1 目的分析设计的目的在于：l 将业务需求转换为未来系统的设计。l 逐步开发强壮的系统构架。l 使设计适合于实施环境，为提高性能而进行设计。2.2.2 提供的文档与模型l 系统总体设计报告（MS WORD）l 系统设计模型DOMAIN MODELl 系统设计模型DESIGN MODELl 数据库设计模型 （POWER DESIGNER）l 数据字典（MS WORD）l 系统详细设计报告（MS WORD）l 工作量化书（MS WORD）2.3 实施2.3.1 目的实施的目的包括： 对照实施子系统的分层结构定义代码结构、 以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式实施类和对象、 对已开发的构件按单元来测试，并且 将各实施员（或团队）完成的结果集成到可执行系统中。施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行说明。测试的目的在于：l 核实对象之间的交互。l 核实软件的所有构件是否正确集成。l 核实所有需求是否已经正确实施。l 确定缺陷并确保在部署软件之前将缺陷解决。2.3.2 提供的文档与模型l 实施总结书（MS WORD）l 实施模型（Visio）l 系统集成书（MS WORD）l 代码审核意见书（MS WORD）l 源代码（MS WORD）l 用户使用手册（MS WORD）l 错误解决记录手册（MS WORD）l 构件及其说明2.4 项目管理2.4.1 目的部分的目标是，通过提供一些项目管理的环境，使这个任务更加容易完成。它虽然不是成功的秘诀，但它介绍了可以显著提高成功交付软件可能性的项目管理方法。项目管理的目的是：l 为对软件密集型项目进行管理提供框架。l 为项目的计划、人员配备、执行和监测提供实用的准则。l 为管理风险提供框架。该工作流程主要侧重于迭代式开发流程的以下重要方面：l 风险管理l 计划迭代式项目，贯穿生命周期并针对特定的迭代l 监测迭代式项目的进度、指标2.4.2 提供的文档和模板l 风险管理计划（MS EXCEL）l 工作计划书（MS EXCEL）l 风险列表（MS EXCEL）l 迭代计划（MS EXCEL）l 问题解决计划（MS EXCEL）l 测试计划书（MS EXCEL）l 系统集成计划书（MS EXCEL）l 子系统集成计划书（MS EXCEL）l 工作单（MS EXCEL）l 产品验收计划（MS EXCEL）l 评测计划（MS EXCEL）l 项目计划复审意见书（MS WORD）l 开发总结（MS WORD）2.5 部署2.5.1 目的署工作流程用来描述那些为确保最终用户可以正常使用软件产品而进行的活动。署工作流程描述了两种产品部署的模式：l 自定义安装l 通过 Internet 使用软件每个实例中，都强调要在开发场所对产品进行测试，并在产品最终发布之前进行 Beta 测试。管部署活动主要集中于产品化阶段，但在较早的一些阶段中也会有一些为部署进行计划和准备的活动。2.5.2 提供的文档和模板l 部署计划 l 安装文档 l 发布说明 3. 角色划分色是抽象的职责定义，它定义的是所执行的一组活动和所拥有的一组文档与模型。角色通常由一个人或作为团队相互协作的多个人来实现。目团队成员通常要履行许多不同的角色职能；就象一个人可以担任许多职务，一个人也可以担任许多不同的角色。色并不代表个人，而是说明个人在业务中应该如何表现以及他们应该承担的责任。3.1 分析员角色集 分析员角色集用于组织主要从事需求获取和研究的各种角色。3.1.1 业务流程分析员务流程分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何进行交互。3.1.1.1 人员配备 任业务流程分析员的人员应该善于简化工作，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务领域知识的人才。业务流程分析员应该准备好开展以下工作：l 评估将在其中部署项目最终产品的目标组织的情况。l 了解客户与用户的需求、策略和目标。l 协调目标组织的建模工作。l 在必要时对业务工程工作进行讨论和协调。l 对目标组织中所建议的任何变更进行成本效益分析。 3.1.2 业务设计员务设计员通过描述一个或几个业务用例的工作流程来详细说明组织中某一部分的规约。他指定实现业务用例所需的业务角色及业务实体，并且将业务用例的行为分配给这些业务角色及业务实体。业务设计员定义一个或几个业务角色和业务实体的责任、操作、属性和关系。 3.1.2.1 人员配备 任业务设计员的人员应该善于协调，并且具有良好的沟通技巧。他最好具有业务领域的知识，但这并不是担任此角色的所有人都必需的。业务设计员需要熟悉用于获取业务模型的工具。 3.1.3 业务模型复审员务模型复审员参与对业务用例模型和业务对象模型的正式复审。 3.1.3.1 人员配备 大多数情况下，担任业务模型复审员的人员都需要具备业务领域的基本知识，或者对将用来实现业务自动化的技术具备基本的知识。业务模型复审员应该具备的另一种技能是详细了解所应用的业务工程技术。3.1.4 系统分析员统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。3.1.4.1 人员配备 任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才。3.1.5 用户界面设计员户界面设计员通过以下方法领导和协调用户界面的原型设计和正式设计：l 分析对用户界面的需求，包括可用性需求；l 构建用户界面原型；l 邀请用户界面的最终用户参与可用性复审和使用测试会议；l 对用户界面的最终实施方案（由设计员和实施员等其他开发人员创建）进行复审并提供相应的反馈。3.1.5.1 人员配备 用户界面设计员不应实施用户界面。用户界面设计员的工作重点和时间都应集中在用户界面的设计和“可视化成形”，原因如下：l 用户界面设计员所需的技能通常需要为当前的项目和应用程序类型（可能具有独特的可用性需求）而加以改进和优化，这需要投入时间并集中工作重点。l 应该限制因“一心二用”而带来的风险，即用户界面设计员不应该因为实施方面的考虑（相对于可用性方面的考虑而言）而受到过多的影响。 3.2 开发角色集开发人员角色集用于组织主要从事软件设计与开发的各种角色。 角色 l 构架设计师l 构架复审员l 代码复审员l 数据库设计员l 系统设计员l 设计复审员l 实施员l 集成员 3.2.1 构架设计师架设计师负责在整个项目中对技术活动和部件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。 3.2.1.1 人员配备 架设计师必须多才多艺、成熟练达、洞察力强、经验丰富。这样，他才能在无法获得完整信息的情况下迅速领会问题并根据经验作出审慎的判断。 3.2.2 构架复审员架复审员负责计划并执行对软件构架的正式复审。 3.2.2.1 人员配备 架复审员角色的人员配备要求与构架设计师的人员配备要求相同，但前者更加注重于技术问题。虽然对领导才能、成熟程度、实用主义及注重结果这些方面的重视程度稍低，但这些方面仍然重要：复审员可能会发现构架方面的缺陷，并且有可能会因为影响项目的进度而不受欢迎。尽管如此，最好还是在问题可以解决的时候及早提出关键性的问题，而不是盲目地追随进度，致使项目团队步入歧途。构架复审员需要根据成本对风险加以权衡，并对影响项目成功的概括性问题保持一定的敏感性。构架复审员还需是善于说服的沟通者，他应该能够提出并讨论对他人来说比较敏感的问题。 3.2.3 代码复审员 码复审员负责确保源代码的质量，并且计划和执行源代码复审。在复审活动中，代码复审员还负责有关返工的任何反馈意见。3.2.4 数据库设计人员 据库设计员定义表、索引、视图、约束条件、触发器、存储过程、表空间或存储参数，以及其他在存储、检索和删除永久性对象时所需的数据库专用结构。相关信息记录在数据模型中。 3.2.4.1 人员配备 据库设计员必须在以下方面具有扎实的应用知识：l 数据库和面向对象的分析设计技术l 系统构架，包括数据库和系统性能调整，以及硬件和网络负载平衡l 数据库管理l 了解实施语言和环境 3.2.5 系统设计员设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计员可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。 3.2.5.1 人员配备 设计员必须在以下方面具有扎实的应用知识：l 用例建模技术。l 系统需求。l 软件设计技术，包括：n 面向对象的分析设计技术。n 统一建模语言。n 实施系统时将利用的技术。 3.2.6 设计复审员 设计复审员计划并进行设计模型的正式复审。 3.2.6.1 人员配备 计复审员的人员配备要求与构架设计师的人员配备要求相同，但前者更加侧重于技术问题。虽然对领导才能、成熟程度、实用主义及注重结果这些方面的重视程度稍低，但这些方面仍然重要：复审员可能会发现设计方面的缺陷，并且有可能会因为影响项目的进度而不受欢迎。尽管如此，最好还是在问题可以解决的时候及早提出关键性的问题，而不是盲目地追随进度，致使项目团队步入歧途。设计复审员需要根据风险对成本加以权衡，并对影响项目成功的概括性问题保持一定的敏感性。设计复审员还需是一个善说服的沟通者，他应该能够提出并讨论对他人来说比较敏感的问题。技术知识的观点来看，设计复审员应该具有与设计员相同经验。3.2.7 实施员（程序员）施员负责按照项目所采用的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。如果必须创建驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及相应的子系统。 3.2.7.1 人员配备 实施员应具备的相应技能和知识包括：l 了解系统或所测试的应用程序l 熟悉测试及测试自动化工具l 编程技能建议负责实施子系统的实施员同时应负责该子系统所包含的构件。 3.2.8 集成员实施员将经测试的构件交付到集成工作区，由集成员在集成工作区将构件组合起来，生成一个工作版本。集成员还负责制定集成计划。集成在子系统和系统级别进行，每次集成均有独立的集成工作区。正如经测试的构件从实施员的专用开发工作区交付到子系统集成工作区一样，已集成的实施子系统也从子系统集成工作区交付到系统集成工作区。 3.2.8.1 人员配备 有时，担任集成员的个人还可以担任实施员或测试员。例如，如果项目较小，或者是在子系统级别上进行集成，就可以让同一个人兼任集成员和测试员，以做到有效地利用人力资源。实际上，对于子系统级别的集成（和测试），一个人就可以兼任实施员、集成员和测试员的角色。但是，对于系统级别的集成，建议应由独立的团队来执行集成和测试。 3.3 测试员角色集测试员角色集用于组织主要从事软件测试的各种角色。角色 l 测试设计员 l 测试员 3.3.1 测试设计员测试设计员是测试中的主要角色。该角色负责对测试进行计划、设计、实施和评估，包括：l 生成测试计划和测试模型l 执行测试过程l 评估测试范围和测试结果，以及测试的有效性l 生成测试评估摘要 3.3.1.1 人员配备 测试设计员应具备的相应技能和知识包括：l 了解系统或所测试的应用程序l 了解测试及测试自动化工具l 具备诊断和解决问题的技能l 编程技能（最好具备） 3.3.2 测试员测试员负责执行测试，其职责包括：l 设置和执行测试l 评估测试执行过程并修改错误3.3.2.1 人员配备 测试员应具备的知识和技能可能会因为他们所执行的测试类型和/或测试阶段的不同而有所差异。例如，在执行性能测试或集成阶段的测试时，需要更高级的技能。在执行功能测试或系统测试阶段的测试时，则不需要太高级的技能。3.4 经理角色集经理角色集用于组织主要从事软件工程流程的管理与配置的各种角色。角色l 变更控制经理 l 配置经理 l 部署经理 l 流程工程师 l 项目经理 l 项目复审员 3.4.1 变更控制经理变更控制经理这一角色负责对变更控制过程进行监督。此角色通常由配置（或变更）控制委员会 (CCB) 来担任，该委员会应该由有关各方（包括客户、开发人员和用户）的代表组成。在小型项目中，项目经理或软件构架设计师一人即可承担此角色。 3.4.2 配置经理配置经理负责为产品开发团队提供全面的配置管理 (CM) 基础设施和环境。CM 的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。配置经理还必须确保 CM 环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写 CM 计划并汇报基于“变更请求”的进度统计信息。 3.4.3 部署经理部署经理负责制定向用户群体发布产品的计划，并将其纳入布署计划中。 3.4.4 流程工程师流程工程师对软件开发流程本身负责。其职责包括在项目开始前配置流程，并在开发工作过程中不断改进流程。 3.4.5 项目经理项目经理负责分配资源，确定优先级，协调与客户和用户之间的沟通。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。 3.4.6 项目复审员项目复审员负责在项目生命周期中的主要复审点处评估项目计划工件和项目评估工件。在这些复审点发生的是非常重要的复审事件，因为在它们所标志的时间点处，如果计划不够充分或者进展无法令人满意，项目很可能会就此取消。 威士科技有限公司，2005第2 共 23