软件研发管理制度

文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 文件标识： 当前版本： 作 者： 完成日期： 参与者 Lolaage-Software-PM 宋孝光 2012/3/27 修改日期 2012/3/26 2012/3/27 目录

备注 第一版草稿 整理目录 版本/状态

作者 宋孝光 宋孝光

1 软件研发制度综述 精简模型

“精简模型”是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。

精简模型把产品生命周期划分为6个阶段，分别为：

 产品概念阶段  产品定义阶段  产品开发阶段  产品测试阶段  用户验收阶段  产品维护阶段

在精简模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。上述三类过程可以细分为17个主要过程域，分布在产品生命周期的各个阶段。

项目管理过程包含6个过程域，分别为：  立项管理  结项管理  项目规划  项目监控  风险管理  需求管理

项目研发过程包含7个过程域，分别为：  需求开发  技术预研  系统设计  实现与测试  系统测试  客户验收  技术评审

机构支撑过程包含4个过程域，分别为：  配置管理  质量保证  培训管理  服务与维护 精简模型如图1-1所示。精简模型的主要特征和优点有： 一、直观的过程模型

精简模型将项目管理、项目研发、机构支撑所包含的工作划分为相对独立的三类过程，各个过程域之间的关系直观明了。这样，机构领导、项目经理、开发人员、测试人员、质量保证人员等人根据精简模型，很容易知道自己“应该在什么时候、按照什么规范做什么事情”。所以精简模型有助于使机构内的各个职能单位有条不紊地开展工作。

二、容易裁剪与扩充

精简模型的三类过程贯穿了产品的整个生命周期，17个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特

征，适当地裁剪或扩充精简的过程域，很容易制定出最适合于本产品的过程模型。

产品概念 项目 管理 过程 项目 研发 过程 需求开发 技术预研 并行、迭代 系统设计 实现与测试 系统测试 根据产品特征确定最合适的开发模型， 以线性顺序为主，以并行、迭代为辅。 客户验收 技术评审 立项管理 项目规划 项目监控 风险管理 需求管理 结项管理 产品定义 产品开发 产品测试 客户验收 产品维护 机构支撑过程 配置管理 质量保证 培训管理 服务与维护 其它： 人力资源管理 财务管理 行政管理 市场营销 … 图1-1 精简模型

精简过程域的目的

精简模型 所有17个过程域的目的如表1-1所示。

项目管理过程域 目的 采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目。杜立项管理 绝不符合机构最大利益的立项建议被采纳，避免浪费机构的资源、资金、时间等。 结项管理 在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。 为项目的研发和管理工作制定合理的行动纲领（即项目计划），以便所有相关人员按照该计划有条不紊地开展工作。 周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等，不断地了解项目的进展情况，以便当项目实际进展显着偏离计划时能够及时采取纠正措施。 在风险产生危害之前识别它们，从而有计划地消除或削弱风险。 在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 目的 通过调查与分析，获取用户需求并定义产品需求。 在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。 设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。 依据系统设计文档，编写并测试整个系统的代码。在精简模型中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。 对最终系统进行全面的测试，确保最终系统满足产品需求并且遵循系统设计。 客户依据合同对产品进行审查和测试，确保产品满足客户需求。 尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。 目的 通过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。 根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。 是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发项目规划 项目监控 风险管理 需求管理 项目研发过程域 需求开发 技术预研 系统设计 实现与测试 系统测试 客户验收 技术评审 机构支撑过程域 配置管理 质量保证 培训管理 服务与维护 方的满意度。 表1-1 精简过程域的目的

精简模型 文档结构与规范细分

精简模型的文档结构如图1-2所示，SPP包含17个过程域，规范细分如表1-2所示。 过程改进政策 过程域 规程 文档模板 图 1-2 精简模型 文档结构

项目管理过程域 立项建议 立项管理 立项评审 项目筹备 主要规程 文档模板 《立项建议书》 《立项调查报告书》 《立项可行性分析报告》 《立项评审报告》 《结项申请书》 《结项评审报告》 《项目计划》 《项目计划变更控制报告》 《项目监控数据表》 《项目偏差控制报告》 《项目进展报告》 《风险检查表》 《风险管理报告》 《需求跟踪报告》 《需求变更控制报告》 文档模板 《用户需求说明书》 《产品需求规格说明书》 结项管理 结项管理 制定项目计划 项目规划 审批项目计划 项目计划变更控制 项目计划跟踪 项目监控 偏差控制 项目进展总结 风险管理 风险管理 需求确认 需求管理 需求跟踪 需求变更控制 项目研发过程域 需求调查 需求开发 需求分析 需求定义 主要规程 技术预研 技术预研 体系结构设计 《技术预研计划》 《技术预研报告》 《体系结构设计报告》 《用户界面设计报告》 《数据库设计报告》 《模块设计报告》 《实现与测试计划》 《编程文档》 《系统测试计划》 系统设计 用户界面设计 数据库设计 模块设计 实现与测试 实现与测试 系统测试 系统测试 《测试用例》 《测试报告》 客户验收 客户验收 《客户验收计划》 《客户验收报告》 《技术评审计划》 《技术评审报告》 《技术评审检查表》 文档模板 《质量保证计划》 《质量保证检查表》 《质量保证报告》 《质量问题跟踪表》 《配置管理计划》 《配置库管理报告》 《配置项变更控制报告》 《培训计划》 《培训评估报告》 《客户服务计划》 《客户服务报告》 《产品维护计划》 《产品维护报告》 技术评审 正式技术评审 非正式技术评审 规程与关键活动 制定质量保证计划 机构支撑过程域 质量保证 过程与产品质量检查 问题跟踪与质量改进 制定配置管理计划 配置管理 配置库管理 版本控制 变更控制 培训管理 机构培训管理 项目培训管理 客户服务 服务与维护 产品维护 表1-2 精简模型 规范细分 精简模型 角色与职责表

精简模型的主要角色及其职责如表1-3所示（详见各个过程域对角色与职责的描述）。公司在应用精简模型时，可以将精简模型的各个角色映射到公

司原有的岗位上，也可以依据精简模型角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。

常设角色 软件工程过程组 机构过程改进角色 质量保证小组 （QAG） （SEPG） 职责简述 （1）制定适合于本机构的过程规范。 （2）在机构范围内推广该规范（如培训、考核），评估机构过程能力等。 （1）监督规范的实施，确保所有项目以及相关部门准照规范开展工作。 （2）分析并解决机构内存在的共性质量问题，协组SEPG完善规范。 （1）是机构内所有项目的主管，对立项管理和结项管理有最终决策项目 管理 过程角色 项目经理 机构领导 权。 （2）监督项目经理的工作，审批项目经理的各种申请。 （1）向机构领导汇报工作。 （2）是项目规划、项目监控、风险管理和需求管理过程域的负责人。 （3）监督项目成员的工作，审批项目成员的各种申请。 需求分析员 项目研发 过程 角色 程序员 调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。 根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等，并撰写相应的设计文档。 （1）根据系统设计文档，编写软件系统的代码。 （2）随时测试和检查自己的代码，及时消除代码中的缺陷。 从事单元测试、集成测试和系统测试，主要工作包括制定测试计划、设计测试用例、执行测试和撰写测试报告。 （1）为项目制定《配置管理计划》。 配置管理员 （2）创建并维护配置库，如分配权限、清除垃圾文件、备份配置库等。 质量保证员 机构 支撑 过程 角色 客户服务人员 培训管理员 （即QAG成员） （1）为项目制定《质量保证计划》。 （2）周期性的开展“过程与产品质量检查”。 （3）跟踪质量问题，给出质量改进措施。 制定机构（或项目）的《培训计划》，监督该计划的实施，撰写《培训评估报告》。 为客户提供与产品相关的服务（如技术咨询），快速响应客户的要求，给客户一个满意的解答。 （1）纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺产品维护人员 陷。 （2）完善性维护：在资源允许的情况下，不断改善产品功能与质量。 临时角色 立项建议小组 职责说明 （1）开展立项调查、产品构思和可行性分析，撰写相应文档。 （2）申请立项，并在立项评审会议上答辩。 系统设计师 测试员 立项评审委员会 由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。 对项目的有形资产和无形资产进行清算，对项目进行综合评估，总结经验教训等。结项委员会的人员组成与立项评审委员会的类似。 对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。该委员会由项目内外的技术专家组成。 对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。 表1-3 精简模型的角色与职责简表 结项评审委员会 技术评审委员会 配置控制委员会 公司软件过程的政策

目标

 持续改进机构的软件过程能力，不断地提高产品质量、提高生产率并且

降低开发成本。

机构领导的支持

 机构领导批准用于软件过程改进的必要经费，例如支付咨询费，购买相

关软件工具等。

 机构领导组建SEPG和QAG，专门从事软件过程改进工作。SEPG的主

要职责是建立适合于机构的过程规范，QAG的主要职责是监督该规范的实施。建议让SEPG和QAG的大部分人员重叠，这些人既是SEPG成员又是质量保证员，扮演两种角色。这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。一般地，SEPG成员和质量保证员共占机构总人数的5%左右。

 机构领导不仅要口头支持，还要亲自参与软件过程改进的实践。例如参

加培训和考试，准照过程规范执行立项管理和结项管理等。

质量管理的政策

质量管理口号：“在开发过程之中内建质量而非修补质量”。

质量管理有种基本措施：“质量保证”、“技术评审”和“测试”。 一、 质量保证

机构的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。

机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。

二、技术评审

在工作成果刚产生之际，对其进行技术评审（分正式或非正式两种），目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。

如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。技术评审活动由项目开发团队组织。

三、测试

测试是指通过运行测试用例（test case）来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。

一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。验收测试由客户组织。如果有条件的话，建议机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。

质量保证小组的政策

机构领导任命一位熟悉过程规范并且有丰富的质量管理经验的人担任QAG的负责人（或称为质量经理）。在机构领导的许可下，该负责人组建QAG（成员可以是全职的也可以是兼职的）。

QAG在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。QAG准照SEPG制定的“质量保证规范”开展工作。

机构领导赋予QAG一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与项目之间出现的难以调和的争议，由机构领导处理。

项目团队的政策

项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规范，每个人都必须明白自己“应当在什么时候依据什么规范做什么事情”。项目经理应当树立榜样，并且督促项目成员们按规范做事。

允许项目经理根据本项目的特征，在SEPG和QAG的指导下，适当地裁剪或扩充机构的过程规范，从而快速建立本项目的过程规范。这项工作应当在“项目规划过程域”中完成，并在《项目计划》中体现出来。

如果项目对机构过程规范的裁剪幅度比较大，遭到QAG的反对，如果双方不能达成共识，则由机构领导处理该争议。

SEPG对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占30％以上的比重。

2 立项管理

参见《项目管理制度试行版本》

3 项目规划

在立项管理过程域的项目筹备阶段，机构领导首先任命一位项目经理，之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组，着手制定《项目计划》，并按计划执行研发和管理工作。

项目的计划书可分两类：一是全局的计划书（Overall Plan），这里称为《项目计划》；二是一些下属计划书（Subordinate Plan），例如《配置管理计划》、《质量保证计划》、一些开发计划和测试计划等。

下属计划书是对《项目计划》的补充，其内容不可与《项目计划》冲突。通常《项目计划》由项目经理负责制定，由机构领导审批。而下属计划书一般由项目成员制定，由项目经理审批即可。

项目计划过程域有3个主要规程：“制定项目计划”、“审批项目计划”和“项目计划变更控制”，流程如图3-1所示。 项目计划变更控制 制定项目计划 审批项目计划 按计划执行 研发与管理工作 图3-1项目规划流程图

4 项目监控

项目监控（Project Monitoring and Control, PMC）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况，以便当项目实际进展状况显着偏离计划时能够及时采取纠正措施。

本规范阐述了项目监控过程域的三个主要规程：  项目计划跟踪  控制偏差

 项目进展汇报 周期性地开展 项目计划跟踪 偏差控制 项目进展总结 图4-1 项目监控流程

项目计划跟踪

周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时了解项目的实际进展情况。

为持续过程改进提供有价值的数据。

任务跟踪

项目经理（或其指定的项目成员）周期性地（如每周一次）跟踪每个重要的任务，将采集的数据保存在《项目监控数据表》之中。任务跟踪表的参考格式如表4-1所示。

任务名称 实际起止时间 跟踪日期、当前进度 实际工作量 实际工作成果 表4-1 任务跟踪表

项目经理（或其指定的项目成员）周期性地跟踪项目费用，将采集的数据保存在《项目监控数据表》之中。费用跟踪表的参考格式如表4-2所示。

费用类别 主要开支项、用途 金额 时间 表4-2 费用跟踪表

项目经理（或其指定的项目成员）周期性地跟踪软硬件资源，将采集的数据保存在《项目监控数据表》之中。资源跟踪表的参考格式如表4-3所示。

软硬件资源名称 级别 关键 关键 普通 普通 实际配置 获取方式与时间 使用说明 … 表4-3 资源跟踪表

项目经理（或其指定的项目成员）周期性地跟踪工作成果及其规模，将采集的数据保存在《项目监控数据表》之中。工作成果跟踪表的参考格式如表4-4所示。

工作成果名称 新开发的成果规模 （代码行、类、文档页数） 工作成果1 工作成果2 … 总和 复用或自动生成的成果规模 （代码行、类、文档页数） 表4-4 工作成果及其规模跟踪表 控制偏差

对比“项目实际进展”和“项目计划”，分析偏差，如果发现项目实际进展显着偏离计划，则及时采取纠正措施。

记录日期 显着偏差描述 原因分析 纠正措施 结果 表4-5项目偏差控制报告

项目进展汇报

周期性地汇报项目进展情况。

项目经理周期性地总结项目进展情况，撰写《项目进展报告》并通报给机构领导和所有项目成员。

基本信息 项目名称 项目编号 项目经理 项目进展状况 任务与进度 工作成果 费用 人力资源 计划 报告日期 报告批次 项目所处阶段 第N份 实际情况 软硬件资源 问题与对策 表4-6项目进展报告

5 风险管理

风险管理（Risk Management, RiskM）的目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。

所有可能危害项目的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生。人们对待风险有两种态度。一种是被动态度，可比作“救火模式”。另一种是主动态度，可比作“防火模式”。风险管理属于“防火模式”，目的就是“防止风险产生真正的危害”。

为了便于量化管理，我们给风险定义3个参数：  风险严重性：指风险对项目造成的危害程度。  风险可能性：指风险发生的几率。

 风险系数：是风险严重性和风险可能性的乘积。 参数 风险 严重性 等级 很高 比较高 中等 比较低 很低 值 5 4 3 2 1 描述 例如进度延误大于30%，或者费用超支大于30%。 例如进度延误20%~30%，或者费用超支20%~30%。 例如进度延误低于20%，或者费用超支低于20%。 例如进度延误低于10%，或者费用超支低于10%。 例如进度延误低于5%，或者费用超支低于5%。 表5-1 风险严重性等级

参数 风险 可能性 等级 很高 比较高 中等 比较低 很低 值 5 4 3 2 1 风险发生的几率为 ~ 风险发生的几率为 ~ 风险发生的几率为 ~ 风险发生的几率为 ~ 风险发生的几率为 ~ 描述 表5-2 风险可能性等级

风险 系数 风险 严重性 很高 5 比较高 4 中等 3 比较低 2 很低 1 很高 5 25 20 15 10 5 比较高 4 20 16 12 8 4 风险可能性 中等 3 15 12 9 6 3 比较低 2 10 8 6 4 2 很低 1 5 4 3 2 1 本表灰色部分的风险系数值为10~25，应当优先处理。 表5-3 风险系数等级 风险严重性的等级划分如表5-1所示，风险可能性的等级划分如表5-2所示，风险系数的等级划分如表3所示。

风险管理有4个主要活动：

 风险识别：根据风险检查表，识别出本项目的风险。  风险分析：估计风险严重性、风险可能性、风险系数。

 风险减缓：对于风险系数超过“容许值”的每一个风险，都应当采

取减缓措施。

 风险跟踪：跟踪风险减缓过程，记录风险的状态。 风险识别 风险跟踪 风险分析 风险减缓 图5-1 风险管理示意图

在项目的生命周期内，上述4个活动将被循环执行，如图5-1所示。直到项目的所有风险都被识别与解决为止。

常用的《风险检查表》，使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》 。

商业风险 风险类型 政治 法律 市场 检查项 政府或者其他机构对本项目的开发有限制吗 有不可预测的市场动荡吗 有不利于我方的官司要打吗 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗 竞争对手有不正当的竞争行为吗 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗 是否在开发很少有人真正需要却自以为很好的产品 是否在开发可能亏本的产品 客户 客户的需求是否含糊不清 客户是否反反复复地改动需求 客户指定的需求和交付期限在客观上可行吗 客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗 客户的合作态度友善吗 与客户签的合同公正吗双方互利吗 客户的信誉好吗例如按客户的需求开发了产品，但是客户可能不购买。 子承包商 供应商 与子承包商、供应商签订的合同公正吗双方互利吗 子承包商、供应商的信誉好吗 子承包商、供应商有可能倒闭吗 子承包商、供应商能及时交付质量合格的产品（或部件）吗 子承包商、供应商有能力做好售后服务吗 管理风险 风险类型 项目计划 检查项 对项目的规模、难度估计是否比较正确 人力资源（开发人员、管理人员）够用吗合格吗 项目所需的软件、硬件能按时到位吗 项目的经费够用吗 进度安排是否过于紧张有合理的缓冲时间吗 进度表中是否遗忘了一些重要的（必要的）任务 进度安排是否考虑了关键路径 是否可能出现某一项工作延误导致其他一连串的工作也被延误 任务分配是否合理（即把任务分配给合适的项目成员，充分发挥其才能） 是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起 … 项目团队 项目成员团结吗是否存在矛盾 是否绝大部分的项目成员对工作认真负责 绝大部分的项目成员有工作热情吗 团队之中有“害群之马”吗 技术开发队伍中有临时工吗 本项目开发过程中是否会有核心人员辞职、调动 是否能保证“人员流动基本不会影响工作的连续性” 项目经理是否忙于行政事务而无暇顾及项目的开发工作 上级领导 行政部门 合作部门 本项目是否得到上级领导的重视 上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目 上级领导是否过多地介入本项目的事务并且瞎指挥 行政部门的办事效率是否比较底，以至于拖项目的后腿 行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目 机构是否能全面、公正地考核员工的工作业绩 机构是否有较好的奖励和惩罚措施 本项目的合作部门的态度积极吗是否应付了事或者做事与承诺的不一致 技术风险 风险类型 检查项 需求开发 需求管理 需求开发人员懂得如何获取用户需求吗效率高吗 需求开发人员懂得项目所涉及的具体业务吗能否理解用户的需求 需求文档能够正确地、完备地表达用户需求吗 需求开发人员能否与客户对有争议的需求达成共识 需求开发人员能否获得客户对需求文档的承诺以保证客户不随便变更需求 综合技术 开发能力 包括设计 编程、测试等 开发人员是否有开发相似产品的经验 待开发的产品是否要与未曾证实的软硬件相连接 对开发人员而言，本项目的技术难度高吗 开发人员是否已经掌握了本项目的关键技术 如果某项技术尚未实践过，开发人员能否在预定时间内掌握 开发小组是否采用比较有效的分析、设计、编程、测试工具 分析与设计工作是否过于简单、草率，从而让程序员边做边改 开发小组采用统一的编程规范吗 开发人员对测试工作重视吗能保证测试的客观性吗 项目有独立的测试人员吗懂得如何进行高效率地测试吗 是否对所有重要的工作成果进行了同行评审（正式评审或快速检查） 开发人员懂得版本控制、变更控制吗能够按照配置管理规范执行吗 开发人员重视质量吗是否会在进度延误时降低质量要求 表5-4 风险检查表

风险名称 风险编号 风险描述 风险严重性 风险可能性 风险减缓措施 跟踪记录 风险识别人 风险识别日期 风险系数 风险处理人 （1）记录何人在何时做了什么事情 （2）记录当前风险状态（正在处理，已经解决，不作处理） 表5-5 风险管理报告

6需求管理

需求管理（Requirement Management, RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。

需求管理过程域的三个主要规程：  需求确认  需求跟踪

 需求变更控制

需求工程 需求开发 需求管理 需求调查 需求分析 需求确认 需求跟踪 需求定义 需求变更控制 图6-1 需求工程结构图 需求确认

项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。

当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下：

本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发

工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。

甲方负责人签字 乙方负责人签字

评审结束 输出 《需求评审报告》，书面的需求承诺

需求评审报告摘要 需求文档 需求评审报告 评审结论 输入名称，标识符，版本，作者，完成日期，… 输入名称，标识符，评审日期，… [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 评审意见 评审小组成员 输入评审小组成员 表6-1 需求评审报告

需求承诺 需求文档 客户承诺 输入名称，标识符，版本，作者，完成日期 承诺… 签字，日期 项目经理承诺 承诺… 签字，日期 表6-2 需求承诺

需求跟踪

将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。 项目经理跟踪需求。

建立与维护需求跟踪矩阵：

 正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到

对应点。

 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求

文档中找到出处。

 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都

要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表6-3为简单的需求跟踪矩阵格式。

 当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。 ＃ 需求文档 （版本，日期） 1 2 标题或标识符，说明 … 设计文档 （版本，日期） 标题或标识符，说明 … 代码 （版本，日期） 代码名称，说明 … 测试用例 （版本，日期） 测试用例名称，说明 … 表6-3 简单的需求跟踪矩阵格式

需求变更控制

 修改“原需求文档”中不正确的内容，产生新的需求文档。  控制需求文档的变更，防止发生混乱。

补充说明：本规程中的“原需求文档”是指已经通过了评审并获得书面承诺的需求文档。

开发方负责人（项目经理）和客户共同控制需求变更。

需求变更申请 申请变更的 需求文档 变更的内容 及其理由 输入名称，版本，日期等信息 评估需求变更将对 项目造成的影响 申请人签字 变更申请的审批意见 项目经理签字 审批意见： 签字，日期 客户签字 （合同项目） 审批意见： 签字，日期 更改需求文档 变更后的 需求文档 更改人签字 输入名称，版本，完成日期等信息 重新评审需求文档 需求评审小组签字 评审意见： 签字，日期 变更结束 项目经理签字 签字 日期： 表6-4 需求变更控制报告 7 结项管理

结项管理（Project Closing Management, PCM）是指在项目开发工作结束后，对项目的有形资产和无形资产进行清算；对项目进行综合评估；总结经验教训等。

立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终”。

项目结束有两种状况：一是正常结束，二是异常结束。前者是指项目按预定计划结束。后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划（如进度延误、费用超支）而被取消。

不论项目属于正常结束还是异常结束，都要按照结项管理规范处理。国内很多项目普遍存在“虎头蛇尾”的现象，结项管理畸变成了“走过场，吃顿饭”，这是非常有害的。

有价值的结项管理至少包括三项内容：

 对项目的有形资产和无形资产进行清算，既要防止资产流失，又要

及时地利用这些资产。

 对项目进行综合评估。例如评估项目完成情况、项目质量、投入产

出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。  总结经验教训，使整个机构受益。 结项评审 资产检查 机构领导指示 结项申请 机构领导审批 综合评估 经验总结 图7-1 结项管理流程图

结项管理的流程如图7-1所示，产生的主要文档有：

8需求开发

需求开发（Requirement Development, RD）的目的是通过调查与分析，获取用户需求并定义产品需求。

本规范阐述了需求开发过程域的两个主要规程：  需求调查

 需求定义

需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程结构图如图6-1所示，需求开发和需求管理的流程如图8-1所示。 输出 需求 开发 过程域 产品需求定义 产品需求规格说明书 输出 用户需求调查 需求分析 用户需求说明书 需求 管理 过程域 需求确认 需求 变更 需求跟踪 控制 图8-1 需求开发与需求管理流程图 需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”。而“需求分析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员），避免与其它开发人员混淆。

一、需求调查

需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。

二、需求分析

需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常用的需求分析方法有“问答分析法”、“结构化分析法”和“面向对象分析法”。

三、需求定义

需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。

需求开发过程域产生的主要文档有：

9 技术预研

技术预研（Technical Pre-Research, TPR）是指在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。

在产品开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。

一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。

所以开展技术预研工作至少有两大好处：

 帮助开发人员更好地进行需求开发、系统设计和程序设计。  防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。

技术预研的流程如图9-1所示。 制定计划 开展技术预研 撰写预研报告 工作成果介绍 技术评审… 图9-1 技术预研流程 技术预研过程中产生的主要文档有：

10 系统设计

系统设计（System Design, SD）是指设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。

本规范阐述了系统设计过程域的四个主要规程：  体系结构设计  用户界面设计  数据库设计  模块设计

系统设计过程域分为两个阶段：高层设计阶段和详细设计阶段。

高层设计阶段的重点是软件系统的体系结构设计。详细设计阶段的重点是用户界面设计、数据库设计和模块设计，如图10-1所示。 高层设计阶段 详细设计阶段 用户界面设计 需求开发 体系结构设计 数据库设计 实现与测试 模块设计 图10-1 系统设计过程域示意图 系统设计过程域产生的主要文档有：  《体系结构设计报告》  《用户界面设计报告》  《数据库设计报告》  《模块设计报告》

体系结构设计

分析与设计软件的体系结构。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，产生《体系结构设计报告》。

项目经理指定若干名开发人员从事体系结构设计（以下称为体系结构设计人员）。

体系结构设计流程如图10-2所示。 Step1. 设计 准备 Step2. 确定 约束 因素 Step3. 确定 设计 策略 Step4. 系统 分解 设计 Step5. 撰写 文档 Step6. 设计 评审 图10-2 体系结构设计流程

用户界面设计

设计软件的用户界面，产生《用户界面设计报告》。 制作用户界面的资源如图像、图标或者界面专用组件等

项目经理指定若干名开发人员从事用户界面设计（以下称为界面设计人员）。

如果可能的话，邀请用户或美工人员协助设计用户界面。 用户界面设计流程如图10-3所示。 Step2. 界面设计 原型创作 Step1. 设计 准备 细化 原型评估 Step3. 撰写 文档 Step4. 设计 评审 迭代 图10-3 体系结构设计流程

数据库设计

设计软件的数据库，产生《数据库设计报告》。

项目经理指定若干名开发人员从事数据库设计（以下称为数据库设计人员）。

数据库设计流程如图10-4所示。 Step2. 数据库设计 逻辑设计 Step1. 设计 准备 物理设计 Step3. 撰写 Step4. 设计 评审 安全性设计 文档 优化 迭代 图10-4 数据库设计流程

模块设计

设计软件所有模块的主要接口与属性、数据结构和算法，产生《模块设计报告》。

项目经理指定若干名开发人员从事模块的设计（以下称为模块设计人员），模块设计人员将在实现阶段编写这些模块的代码。 模块设计流程如图10-5所示。 Step2. 模块设计 Step1. 设计 准备 数据结构 与算法设计 接口与属性设计 Step3. 撰写 文档 Step4. 设计 评审 迭代 图10-5 模块设计流程

11 实现与测试

实现与测试（Implementation and Test, IT）的目的是依据系统设计文档，编写并测试整个系统的代码。在本规范中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。

实现与测试的流程如图11-1所示。一般地，编程、代码审查、单元测试、集成测试大致存在先后顺序关系，也可以并行、迭代地开展。上述任何活动中发现的缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。 模块 准备 编程 代码审查 单元测试 集成测试 缺陷管理与改错 软件系统 图11-1 实现与测试流程图

由于实现与测试是工作量最大、时间最长、产生工作成果（代码与文档）最多的一个项目研发过程域，所以需要作充分的准备工作。

实现与测试工作基本上在开发小组内部开展。一个项目可能有一个或者多个开发小组。对于小型项目，项目经理可以兼任开发组长。

特别要注意的是，开发人员应当对自己的代码进行审查和测试（这是份内的工作），但是不能作为该代码已经通过审查和测试的依据。所以开发人员还要互相审查和测试同伴的代码。

实现与测试过程域产生的主要文档有：  《实现与测试计划》  《编程文档》

 《代码审查报告》  《测试用例》  《测试报告》

 《缺陷管理报告》（由缺陷管理工具自动生成）

一个项目可能有多个开发小组，视项目规模而定。开发组长由项目经理指定。

开发组长管理编程、代码审查、单元测试、集成测试、缺陷管理与改错等活动。

12 系统测试

系统测试（System Test, ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

系统测试流程如图12-1所示。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。这样可以提高系统测试的效率。

系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。

审批 审批 迭代 制定测试计划 设计测试用例 执行系统测试 缺陷管理与改错 图12-1 系统测试流程图

项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于：

 机构独立的测试小组（如果存在的话）。  邀请其它项目的开发人员参与系统测试。  本项目的部分开发人员。  机构的质量保证人员。 系统测试小组应当根据项目的特征确定测试内容。一般地，系统测试的主要内容包括：

 功能测试。即测试软件系统的功能是否正确，其依据是需求文档，

如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。

 健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。

健壮性有两层含义：一是容错能力，二是恢复能力。

 性能测试。即测试软件系统处理事务的速度，一是为了检验性能是

否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。

 用户界面测试。重点是测试软件系统的易用性和视觉效果等。

 安全性（security）测试。是指测试软件系统防止非法入侵的能力。

“安全”是相对而言的，一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等因素）高于得到的好处，那么这样的系统可以认为是安全的。  安装与反安装测试。 系统测试过程域产生的主要文档有：  《系统测试计划》  《系统测试用例》  《系统测试报告》  《缺陷管理报告》

对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

项目经理组建系统测试小组，并指定一名成员任测试组长。

系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档。测试组长管理上述事务。

开发人员及时消除测试人员发现的缺陷。

13 客户验收

客户验收（Customer Acceptance, CA）是指客户依据合同对产品进行审查和测试，确保产品满足客户需求。

客户对产品的验收主要有两种方式：

 成果审查。验收人员审查开发方应当交付的成果，如代码、文档等

等。确保这些成果是完整的并且是正确的。

 验收测试。验收人员对待交付的产品进行全面的测试，确保产品功

能、质量符合需求。

验收测试的内容、方法与系统测试几乎是相同的。两者主要区别在于执行人员不同。验收测试人员来自于客户方，而系统测试人员则来自于开发方。客户验收流程如图13-1所示。 验收准备 成果审查与验收测试 问题处理 交付与签字 图13-1 客户验收流程 客户验收过程域产生的主要文档有：  《客户验收计划》  《验收测试用例》  《客户验收报告》

补充说明：“客户验收”是针对合同项目而言的。

14 技术评审

技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。

本规范阐述了技术评审过程域的三个主要规程：  制定技术评审计划  正式技术评审  非正式技术评审

技术评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷。技术评审的主要好处有：

 通过消除工作成果的缺陷而提高产品的质量。  越早消除缺陷就越能降低开发成本。

 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工

作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。 可见技术评审有助于“提高质量、提高生产率、降低成本”，符合软件过程改进的根本目的。

技术评审有两种基本类型：

 正规技术评审（FTR）。FTR比较严格，需要举行评审会议，参加评

审会议的人员比较多。

 非正规技术评审（ITR）。ITR的形式比较灵活，通常在同伴之间开

展，不必举行评审会议，评审人员比较少。

理论上讲，为了确保产品的质量，产品的所有工作成果都应当接受技术评审。现实中，为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。

技术评审过程域有三个主要规程：“制定技术评审计划”、“正规技术评审”和“非正规技术评审”，如图14-1所示。

图14-1 技术评审过程域示意图 正规技术评审 制定技术评审计划 非正规技术评审 技术评审的注意事项：  评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消

除缺陷的办法，而不是替开发人员消除缺陷。

 技术评审应当“就是论事”，不要打击有失误的开发人员的工作积

极性，更不准搞人身攻击（如挖苦、讽刺等）。

 在会议评审期间要限制过多的争论，以免浪费他人的时间。 技术评审过程域产生的主要文档有：  《技术评审计划》  《技术评审通知》  《技术评审报告》  《技术评审检查表》

15 配置管理

配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

本规范阐述了配置管理过程域的四个主要规程：  制定配置管理计划  配置库管理

 配置项版本控制  配置项变更控制

项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑

地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等。为了提高配置管理的效率和安全性，机构应当有专门的配置管理员（角色）。配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。

鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration Control Board, CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。

如果机构的各个项目紧密相关（例如一个产品线下的多个项目），建议机构设立公共的CCB，这个公共的CCB对所有项目的配置管理拥有决策权。如果机构的各个项目相对独立，那么每个项目可以设立各自的CCB。CCB的决策采用“少数服从多数”原则。

配置管理的流程如图15-1所示。 制定配置管理计划 版本控制 变更控制配置库管理 配置审计 图15-1 配置管理流程图

一、制定配置管理计划 配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。

二、配置库管理

配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。

三、版本控制

在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。

四、变更控制

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。

修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。

当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。

五、配置审计

为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。

配置管理过程域产生的主要文档有：  《配置管理计划》  《配置库管理报告》

 《配置项变更控制报告》

16 质量保证

质量保证（Quality Assurance, QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而

实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。

本规范阐述了质量保证过程域的三个主要规程：  制定质量保证计划  过程与产品质量检查  问题跟踪与质量改进

过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心产品质量。

提高产品质量有三种基本方法：

 质量保证。质量保证人员通过有计划地检查“工作过程以及工作成

果”是否符合既定的规范，来监控和改进“过程质量”与“产品质量”。

 技术评审。请同行专家、技术人员对工作成果进行评审，尽早发现

工作成果中的缺陷。

 测试。通过运行测试用例来找出软件中的缺陷。例如单元测试、集

成测试、系统测试、验收测试等。

质量保证既关心过程质量又关心产品质量。如果“工作过程以及工作成果”不符合既定的规范，那么产品的质量肯定有问题。基于这样的推理，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质量。这是质量保证方法富有成效的一面。但是“工作过程以及工作成果”符合既定的规范却并不意味着产品的质量一定合格，因为仅靠规范无法识别出产品中可能存在的大量缺陷。这是质量保证方法的不足之处。所以单独的“质量保证”其实并不能“保证质量”。

技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。技术评审和测试能弥补质量保证的不足，三者是相辅相成的质量管理方法。我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。让质量保证人员参加并监督重要的技术评审和测试工作，这是很好的方法。把三者有机地结合起来，可提高工作效率，降低成本。

质量保证小组（Quality Assurance Group, QAG）有如下特点：

 质量保证小组在行政上独立于任何项目。这种独立性有助于质量保

证小组客观地检查和监控“过程以及产品的质量”。

 质量保证小组有一定的权利，可以对质量不合格的工作成果做出处

理。这种权利使得质量保证小组的工作不会被轻视，并有助于加强全员的质量意识。需要强调的是，提高产品质量是全员的职责，并非只是质量保证小组的职责。

质量保证过程域有3个主要规程：“制定质量保证计划”、“过程与产品质量检查”和“问题跟踪与质量改进”，如图16-1所示。

一、制定质量保证计划

质量保证小组为每个项目指定一名质量保证员（即接口人）。质量保证员撰写《质量保证计划》，项目经理和质量经理审批该计划。《质量保证计划》的主要内容是“过程与产品质量检查计划”、“参与技术评审计划”和“参与测试计划”。

二、过程与产品质量检查

质量保证员客观地检查项目成员的“工作过程”和“工作成果”是否符合既定的规范，并与项目成员协商改进措施。质量保证员记录本次检查的结果和经验教训，并及时通报给所有相关人员。

三、问题跟踪与质量改进

质量保证员设法先在项目内部解决质量问题，如果在项目内部难以解决，则提交给上级领导处理。质量保证小组分析机构内共性的质量问题，给出质量改进措施。

周期性地开展 制定质量保证计划 过程与产品质量检查 问题跟踪与质量改进 技术评审 --------- 表示质量保证与 技术评审、测试有机结合 测试 图16-1 质量保证过程域示意图 质量保证过程域产生的主要文档有：  《质量保证计划》  《质量保证检查表》  《质量保证报告》  《质量问题跟踪表》

17 培训管理

培训管理（Training Management, TM）是指根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。

本规范阐述了培训管理过程域的两个主要规程：  机构培训管理  项目培训管理

按范围划分，培训管理可分为“机构培训管理”和“项目培训管理”。流程如图17-1所示。 确定机构培训需求 制定机构培训计划 执行培训 培训效果评估 确定项目培训需求 制定项目培训计划 执行培训 培训效果评估 图17-1 培训管理流程 机构培训管理的对象是公共的培训课程，这些培训课程对大多数学员而言是必需的。例如企业规章制度、业绩考核、项目管理、软件工程、客户关系等培训。上述培训由机构培训管理员来管理。

项目培训管理的对象是项目专有的培训课程，这些培训课程是针对项目特定的培训需求而开设的，它们没有被包括在机构培训管理范围之内。例如项目特定的开发技术和产品使用等培训。上述培训由项目经理或者开发组长来管理。

受培训的学员主要有两类：机构内部人员和客户。注意切勿疏忽客户培训。

培训管理过程域产生的主要文档有：

 《机构培训计划》和《项目培训计划》  《机构培训通知》和《项目培训通知》

 《机构培训评估报告》和《项目培训评估报告》

18 服务与维护

服务与维护（Service and Maintenance, SM）是指产品销售之后的客户服务和产品维护。客户服务和产品维护的宗旨就是提高客户对产品以及对开发方的满意度。

本规范阐述了服务与维护过程域的两个主要规程：  客户服务  产品维护

当产品开发完成并开始销售时，原开发小组应当解散以便人力资源重新分配。其中大部分的开发人员将参加新的项目，只需要留小部分人员从事客户服务和产品维护工作。

对于合同项目，客户服务和产品维护的周期、费用等等在合同中决定。对于自主研发的产品而言，一般地，客户服务和产品维护工作将持续到产品退役。客户服务与产品维护的流程如图18-1所示。

客户服务准备 接收客户要求 响应客户要求 产品维护准备 接收并判断维护要求 图18-1 客户服务与产品维护流程 执行维护工作 客户服务的重点是为客户提供与产品相关的服务（如技术咨询），快速响应客户的要求，给客户一个满意的解答。

产品维护可分两大类：

 纠错性维护。由于软件产品开发过程中的测试不可能揭露所有的错误，用户在

使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。

 完善性维护。在软件产品的正常使用过程中，客户还会提出新的需

求。为了满足客户的需求而不断改善产品功能和质量的活动称为完善性维护。如果需求变更比较大，那么完善性维护将转变为软件新版本的开发（即新的项目）。

纠错性维护是必需的、强制性的，而完善性维护则要根据产品发展战略、开发方财力和资源等因素而定。

服务与维护过程域产生的主要文档有：  《客户服务计划》  《客户服务报告》  《产品维护计划》  《产品维护报告》