全套CMMi软件质量管理体系

[Step4]审批新的项目计划机构领导审批新的《项目计划》，参见规程[SPP-PROC-PP-APPROVE]。5.6输出《项目计划变更控制报告》新的《项目计划书》5.7结束准则变更申请以及新的《项目计划》都得到了机构领导的批准。5.8度量项目经理统计工作量。6补充对项目规划过程域产生的所有有价值的文档进行配置管理。《项目计划》被机构领导批准之后，有关人员即可撰写下属计划如《配置管理计划》、《质量保证计划》、一些开发计划和测试计划等。选用合适的软件工具，尽量减少项目规划过程域的工作量。对于客户委托开发的项目，客户在项目规划过程域的介入程度视具体情况而定 四、项目监控项目监控（ProjectMonitoringandControl,PMC）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。项目监控过程域是SPP模型的重要组成部分。本规范阐述了项目监控过程域的三个主要规程：项目计划跟踪[PASS-PROC-PMC-TRACKING]控制偏差[PASS-PROC-PMC-CONTROL]项目进展汇报[PASS-PROC-PP-REPORT]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。1介绍项目监控至少有以下几个好处：避免原本合理的计划在实施时落空；避免“执迷不悟”地按照不合理的计划行事；将监控过程产生的数据保存起来，为机构持续的过程改进提供有价值的数据。项目监控过程域有3个主要规程：“项目计划跟踪”、“偏差控制”、“项目进展汇报”，流程如图4-1所示。项目计划跟踪项目经理周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，从而及时了解项目的实际进展情况。从数据分析角度讲，计划是基于估计的，而跟踪则是基于度量的。偏差控制项目经理将跟踪得到的数据和《项目计划》中的数据进行对比，分析偏差，如果发现项目进展显著偏离计划，应当及时采取纠正措施。项目进展汇报项目经理周期性地召开会议，讨论项目进展情况，撰写“项目进展报告”并通报给机构领导和所有项目成员。项目监控过程域产生的主要文档有：《项目监控数据表》，模板见[SPP-TEMP-PMC-DATA]。《项目偏差控制报告》，模板见[SPP-TEMP-PMC-CONTROL]。《项目进展报告》，模板见[SPP-TEMP-PP-REPORT]。项目计划跟踪偏差控制项目进展总结周期性地开展图4-1项目监控流程2项目计划跟踪2.1目的周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时了解项目的实际进展情况。为持续过程改进提供有价值的数据。2.2角色与职责项目经理跟踪项目的实施。项目成员协助项目经理采集有关数据。2.3启动准则《项目计划》已经制定2.4输入《项目计划》2.5主要步骤[Step1]任务跟踪项目经理（或其指定的项目成员）周期性地（如每周一次）跟踪每个重要的任务，将采集的数据保存在《项目监控数据表》之中。任务跟踪表的参考格式如表4-1所示。任务名称任务名称实际起止时间跟踪日期、当前进度实际工作量实际工作成果表4-1任务跟踪表[Step2]费用跟踪项目经理（或其指定的项目成员）周期性地跟踪项目费用，将采集的数据保存在《项目监控数据表》之中。费用跟踪表的参考格式如表4-2所示。费用类别费用类别主要开支项、用途金额时间表4-2费用跟踪表[Step3]资源跟踪项目经理（或其指定的项目成员）周期性地跟踪软硬件资源，将采集的数据保存在《项目监控数据表》之中。资源跟踪表的参考格式如表6-3所示。软硬件资源名称软硬件资源名称级别实际配置获取方式与时间使用说明关键关键普通…普通表6-3资源跟踪表[Step4]工作成果及其规模跟踪项目经理（或其指定的项目成员）周期性地跟踪工作成果及其规模，将采集的数据保存在《项目监控数据表》之中。工作成果跟踪表的参考格式如表6-4所示。工作成果名称工作成果名称新开发的成果规模（代码行、类、文档页数）复用或自动生成的成果规模（代码行、类、文档页数）工作成果1工作成果2…总和表6-4工作成果及其规模跟踪表2.6输出《项目监控数据表》2.7结束准则任务跟踪、费用跟踪、资源跟踪、工作成果跟踪所产生的数据已经保存在《项目监控数据表》之中。2.8度量项目经理记录本规程产生的所有度量数据。3控制偏差3.1目的对比“项目实际进展”和“项目计划”，分析偏差，如果发现项目实际进展显著偏离计划，则及时采取纠正措施。3.2角色与职责项目经理分析偏差，采取纠正措施。3.3启动准则周期性地跟踪进度、工作量、费用、资源、工作成果等，及时了解项目的实际进展情况。3.4输入《项目计划》《项目监控数据表》3.5主要步骤[Step1]找出显著偏差项目经理根据任务跟踪、费用跟踪、工作成果跟踪所产生的数据，对比“项目实际进展”与“项目计划”，找出显著偏差项（例如进度或费用偏差大于20％）。[Step2]分析原因项目经理分析产生显著偏差的原因，以便采取正确的纠正措施。[Step3]给出纠正偏差的措施项目经理给出纠正显著偏差的措施：如果偏差主要是由于《项目计划》不合理导致的，则要变更项目计划，见规程[SPP-PROC-PP-CHANGE]。如果《项目计划》本身是合理的，偏差主要是由于项目成员在执行时产生的，那么要求项目成员弥补偏差，避免原本合理的计划在实施时落空。[Step4]跟踪纠正偏差的过程项目经理跟踪纠正偏差的过程，直到该偏差被消除为止。3.6输出《项目偏差控制报告》3.7结束准则已发现的显著偏差被消除。3.8度量项目经理统计工作量。4项目进展汇报4.1目的周期性地汇报项目进展情况。4.2角色与职责项目经理周期性地总结项目进展情况，撰写《项目进展报告》并通报给机构领导和所有项目成员。4.3启动准则已经开展“项目计划跟踪”和“偏差控制”。4.4输入《项目计划》《项目监控数据表》《项目偏差控制报告》4.5主要步骤[Step1]举行项目进展会议项目经理周期性地（或者在里程碑处）召开项目进展会议，探讨问题，总结工作，让所有项目成员清楚地了解项目的实际进展情况。[Step2]撰写项目进展报告项目经理撰写《项目进展报告》，并及时通报给所有项目成员和机构领导。4.6输出《项目进展报告》4.7结束准则已经举行项目进展会议，《项目进展报告》已经通报给所有项目成员和机构领导。4.8度量项目经理统计工作量。5补充对项目规划过程域产生的所有有价值的文档进行配置管理。项目经理根据本项目的特征，确定项目监控的重点，适当修改《项目监控数据表》和《项目进展报告》的格式。项目经理根据本项目的特征，确定“项目计划跟踪”、“项目进展总结”的频度，例如每周一次或每月一次。选用合适的软件工具，尽量减少项目监控过程域的工作量。项目监控过程域和风险管理过程域均由项目经理负责，两者同步执行。 五、风险管理风险管理（RiskManagement,RiskM）的目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。风险管理过程域是SPP模型的重要组成部分。本规范阐述了风险管理的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍所有可能危害项目的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生。人们对待风险有两种态度。一种是被动态度，可比作“救火模式”。另一种是主动态度，可比作“防火模式”。风险管理属于“防火模式”，目的就是“防止风险产生真正的危害”。为了便于量化管理，我们给风险定义3个参数：风险严重性：指风险对项目造成的危害程度。风险可能性：指风险发生的几率。风险系数：是风险严重性和风险可能性的乘积。参数参数等级值描述风险严重性很高5例如进度延误大于30%，或者费用超支大于30%。比较高4例如进度延误20%~30%，或者费用超支20%~30%。中等3例如进度延误低于20%，或者费用超支低于20%。比较低2例如进度延误低于10%，或者费用超支低于%10。很低1例如进度延误低于5%，或者费用超支低于5%。表5-1风险严重性等级参数参数等级值描述风险可能性很高5风险发生的几率为1.0~0.8比较高4风险发生的几率为0.8~0.6中等3风险发生的几率为0.6~0.4比较低2风险发生的几率为0.4~0.2很低1风险发生的几率为~0.00.2表5-2风险可能性等级风险风险系数风险可能性很高5比较高4中等3比较低2很低1风险严重性很高5252015105比较高420161284中等31512963比较低2108642很低154321本表灰色部分的风险系数值为10~25，应当优先处理。表5-3风险系数等级风险严重性的等级划分如表7-1所示，风险可能性的等级划分如表7-2所示，风险系数的等级划分如表3所示。风险管理有4个主要活动：风险识别：根据风险检查表，识别出本项目的风险。风险分析：估计风险严重性、风险可能性、风险系数。风险减缓：对于风险系数超过“容许值”的每一个风险，都应当采取减缓措施。风险跟踪：跟踪风险减缓过程，记录风险的状态。风险识别风险分析风险减缓风险跟踪图7-1风险管理示意图在项目的生命周期内，上述4个活动将被循环执行，如图7-1所示。直到项目的所有风险都被识别与解决为止。常用的风险检查表见[SPP-TEMP-RISKM-CHECKLIST]，使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》，模板见[SPP-TEMP-RISKM-REPORT]。2风险管理规程2.1目的在项目的生命周期内，循环执行风险识别、风险分析、风险减缓和风险跟踪，直到项目的所有风险都被识别与解决为止。2.2角色与职责项目经理负责风险管理。项目成员协助项目经理处理风险。2.3启动准则《项目计划》已经制定，项目研发已经开始。2.4输入《项目计划》项目监控过程产生的文档如《项目监控数据表》、《项目偏差控制报告》和《项目进展报告》等2.5主要步骤[Step1]风险识别项目经理根据“风险检查表”[SPP-TEMP-RISKM-CHECKLIST，]定期（例如每周一次）识别本项目的风险。[Step2]风险分析项目经理评估每个风险的严重性、可能性和风险系数，并按照风险系数从高到低的顺序排列风险。[Step3]风险减缓对于风险系数超过“容许值”（建议为10）的每一个风险，项目经理应当给出风险减缓措施，并指定责任人。风险系数越高，越先处理。[Step4]风险跟踪项目经理跟踪风险减缓过程，直到风险已经解决为止。如果风险的性质发生变化，应当及时更新风险减缓措施2.6输出《风险管理报告》2.7结束准则所有风险都已经解决，相关信息已经记录到《风险管理报告》之中。2.8度量项目经理统计工作量。3补充对风险管理过程域产生的所有有价值的文档进行配置管理。项目经理根据本项目的特征，确定风险识别的频度（通常为每周一次），适当修改“风险检查表”[SPP-TEMP-RISKM-CHECKLIST]。选用合适的软件工具，尽量减少风险管理过程域的工作量。

六、需求管理需求管理（RequirementManagement,RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。SCRUM开发过程中常常会出现需求的变更，SCRUMMaster和SCRUMOwner需要在每次Sprint结束的时候重新评估需求的变更对项目/产品的计划的影响，内容包括：交付期限的影响资源配备的影响其他商务目标的影响在影响已经超过可控范围的时候需要启动需求变更[RM-CHANGE]过程。本规范阐述了需求管理过程域的三个主要规程：需求确认[PASS-PROC-RM-VALIDATE]需求跟踪[PASS-PROC-RM-TRACKING]需求变更控制[PASS-PROC-RM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。图6-1为需求工程的结构图。需求工程需求开发需求变更控制需求管理需求确认需求跟踪需求调查需求分析需求定义图6-1需求工程结构图需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制。需求确认需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。需求管理过程域产生的主要文档有：《需求评审报告》，同技术评审报告的模板[SPP-TEMP-TR-REPORT]。《需求跟踪报告》，模板见[SPP-TEMP-RM-TRACKING]。《需求变更控制报告》，模板见[SPP-TEMP-RM-CHANGE]。2需求确认2.1目的开发方和客户对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审，并作书面承诺。补充说明：《用户需求说明书》和《产品需求规格说明书》可以分开也可以放在一起进行需求确认，视项目的具体情况而定。2.2角色与职责开发方和客户共同组织人员对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审。开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。2.3启动准则需求文档如《用户需求说明书》和《产品需求规格说明书》已经完成。2.4输入需求文档如《用户需求说明书》和《产品需求规格说明书》。2.5主要步骤[Step1]非正式需求评审项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非正式的需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-ITR。][Step2]正式需求评审项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。正式需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-FTR。][Step3]获取需求承诺当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下：本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。甲方负责人签字乙方负责人签字2.6输出《需求评审报告》书面的需求承诺2.7结束准则需求文档通过了正式评审，并且获得开发方和客户的书面承诺。2.8度量项目经理统计工作量和上述文档的规模3需求跟踪3.1目的将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。3.2角色与职责项目经理跟踪需求。3.3启动准则需求文档已经通过正式评审并获得了承诺。系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。3.4输入需求文档设计文档、代码、测试用例等3.5主要步骤[Step1]建立与维护需求跟踪矩阵正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表8-1为简单的需求跟踪矩阵格式。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。＃＃需求文档（版本，日期）设计文档（版本，日期）代码（版本，日期）测试用例（版本，日期）1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2…………表8-1简单的需求跟踪矩阵格式[Step2]查找不一致使用需求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如：后续工作成果没有实现需求文档中的某些需求；后续工作成果实现了需求文档中的不存在的需求；后续工作成果没有正确实现需求文档中的的需求；项目经理将发现的“不一致性”记录在《需求跟踪报告》之中，并通报给相关责任人（工作成果的开发者）。[Step3]消除不一致相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划记录到《需求跟踪报告》之中。相关责任人消除“不一致性”之后，项目经理更新“需求跟踪矩阵”。3.6输出《需求跟踪报告》3.7结束准则每个开发阶段的“需求跟踪矩阵”都已经建立。已经消除了需求文档与后续工作成果之间的不一致性。3.8度量项目经理统计工作量和上述文档的规模。4需求变更控制4.1目的修改“原需求文档”中不正确的内容，产生新的需求文档。控制需求文档的变更，防止发生混乱。补充说明：本规程中的“原需求文档”是指已经通过了评审并获得书面承诺的需求文档。4.2角色与职责开发方负责人（项目经理）和客户共同控制需求变更。4.3启动准则某人（来自开发方或客户方）提出变更“原需求文档”的申请。4.4输入“原需求文档”4.5主要步骤[Step1]需求变更申请需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负责人。“需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响。[Step2]审批需求变更申请开发方负责人（项目经理）和客户共同审批“需求变更申请书”：如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。如果双方都同意变更，转向[Step3]。[Step3]更改需求文档需求分析员根据[Step1]和[Step2]更改“原需求文档”，产生新的需求文档。[Step4]重新进行需求确认重新进行需求评审，参见需求确认规程中的[Step2]。重新获取书面的需求承诺，参见需求确认规程中的[Step3]。4.6输出《需求变更控制报告》4.7结束准则新的需求文档已经被确认。4.8度量项目经理统计工作量。5补充先对项目经理和客户进行培训，让他们掌握必要的需求管理知识。对需求管理过程域产生的所有有价值的文档进行配置管理。对于非合同项目，本规范中有关客户的活动可以被裁减掉。第三篇技术实现过程一、技术预研技术预研（TechnicalPre-Research,TPR）是指在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。技术预研过程域是SPP模型的重要组成部分。本规范阐述了技术预研的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。1介绍在产品开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。所以开展技术预研工作至少有两大好处：帮助开发人员更好地进行需求开发、系统设计和程序设计。防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。技术预研的流程如图所示。制定计划撰写预研报告工作成果介绍技术评审…开展技术预研图7-1技术预研流程技术预研过程中产生的主要文档有：《技术预研计划》，模板见[SPP-TEMP-TPR-PLAN]。《技术预研报告》，模板见[SPP-TEMP-TPR-REPORT]。2技术预研规程2.1目的提前发现并解决开发过程中将会遇到的技术障碍。2.2角色与职责项目经理或技术负责人识别项目中的技术难题，指定技术预研人员攻克该问题。2.3启动准则项目中的技术难题已经识别。技术预研人员已经指定。2.4输入一些用户需求文档和技术方案文档2.5主要步骤[Step1]制定计划技术预研人员制定《技术预研计划》，主要内容包括：确定技术预研的内容和目标。确定应递交的工作成果。分配任务，制定进度表。项目经理或技术负责人审批该计划，如果该计划被批准，则转向[Step2]。[Step2]开展技术预研技术预研人员按照计划开展技术预研工作。[Step3]撰写技术预研报告在预研任务结束时，技术预研人员撰写《技术预研报告》。[后续活动]技术预研人员向相关人员介绍工作成果。项目经理或技术负责人视具体情况决定是否对该预研成果进行技术评审。2.6输出《技术预研报告》2.7结束准则指定的预研任务已经完成，《技术预研报告》已经产生。2.8度量技术预研人员统计工作量和工作成果的规模，汇报给项目经理。3补充技术预研不同于真正地开发产品，投入人员与时间相对比较少。一个项目可以有多次技术预研，由项目经理或技术负责人视具体情况而定。对技术预研过程中产生的所有有价值的文档进行配置管理。

二、SCRUM过程1介绍Scrum是一个敏捷开发框架，是一个增量迭代的开发过程.。在这个框架整个开发周期由若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的长度2到4周。在每个Sprint中，Scrum的开发团队拿到一个排列好优先级的需求列表，我们称它为用户故事或者叫Sprintbacklog，所以我们先开发的是对客户具有较高价值的需求。在每个迭代结束后，都会开发完成可交付的产品。框架如图所示：SCRUM实现包括以下三个规程体系结构设计Sprint迭代项目按照计划可划分为几个ScrumTeam。每个Sprint周期控制在3到5天之内。巩固和提交2体系结构设计2.1目的将Backlogs按照优先级制成列表，根据该表制定软件交付基线。建立软件体系结构，将Backlog项按高内聚，低耦合的原则划分为一系列的问题包，成立数个ScrumTeam，为ScrumTeam分配问题包。建立开发环境。2.2角色与职责项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组：确定系统开发、测试、运行所需的软硬件环境。[Step5]撰写体系结构设计文档体系结构设计人员根据指定的模板撰写《体系结构设计报告》，主要内容包括：软件系统概述影响设计的约束因素设计策略系统总体结构子系统的结构与模块功能开发、测试、运行所需的软硬件环境[Step6]体系结构设计评审体系结构评审的重点不是“对还是错”，而是“好还是差”。主要评审要素包括：合适性。考察该体系结构是否适合于产品需求，是否可在预定计划内实现。系统的综合能力（Capability）。例如“时－空”效率（性能，容量等），可扩展性，可管理性（可维护性），可复用性，安全性等等，视产品特征而定。2.6输出《体系结构设计报告》Backlog列表2.7结束准则软件体系结构建立，2.8度量项目经理根据人员统计工作量和工作成果的规模3Sprint过程规程3.1目的该过程由若干个迭代的冲刺(Sprint)活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1~6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出）。每个Sprint包含以下活动：开发。对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。评审（Review）。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue及难点（) problem）,增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。调整（Adjust）。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。3.2角色与职责项目管理组。由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。若干个SCRUM小组。各小组由组长（SCRUMMaster）领衔。每个小组都是跨专业的（通常包括开发人员，文档人员，质量控制人员或用户代表等），通常为3~7人，以使小组内有充分的交流。小组的划分最好是功能导向的（按所分配的问题包或Backlog），也可是系统层次导向（按体系结构中的分层）。3.3启动准则《体系结构设计报告》建立3.4输入需求文档如《产品需求规格说明书》等作为原始PBL3.5主要步骤[Step1]开发。对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。[Step2]打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。[Step3]评审（Review）。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue及难点（)problem）,增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。[Step4]调整（Adjust）。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。3.6输出软件产品（Artifact）3.7结束准则产品可交付为止3.8度量Scrum主管根据人员统计工作量和工作成果的规模，汇报给项目经理4交付和巩固4.1目的一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。4.2角色与职责4.3启动准则根据风险评估结果认为可交付产品时，即进入该阶段。4.4输入需求文档如《产品需求规格说明书》等作为原始PBL4.5主要步骤[Step1]制定系统测试计划系统测试小组各成员共同协商测试计划。测试组长按照指定的模板起草《系统测试计划》。该计划主要包括：测试范围（内容）测试方法测试环境与辅助工具测试完成准则人员与任务表项目经理审批《系统测试计划》。该计划被批准后，转向[Step2]。[Step2]设计系统测试用例系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》。测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。该测试用例通过技术评审后，转向[Step3]。[Step3]执行系统测试系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。[Step4]缺陷管理与改错从[Step1]至[Step3]，任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。开发人员及时消除已经发现的缺陷。开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。[Step7]测试报告编制[Step6]操作文档编制4.6输出软件产品（Artifact）《用户操作文档》《测试报告》4.7结束准则完成最终文档 三、用户验收客户验收（CustomerAcceptance,CA）是指客户依据合同对产品进行审查和测试，确保产品满足客户需求。本规范阐述了客户验收的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍客户对产品的验收主要有两种方式：成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确的。验收测试。验收人员对待交付的产品进行全面的测试，确保产品功能、质量符合需求。验收测试的内容、方法与系统测试几乎是相同的。两者主要区别在于执行人员不同。验收测试人员来自于客户方，而系统测试人员则来自于开发方。客户验收流程如图15-1所示。验收准备问题处理成果审查与验收测试交付与签字图15-1客户验收流程客户验收过程域产生的主要文档有：《客户验收计划》，模板见[SPP-TEMP-CA-PLAN]。《验收测试用例》，模板见[SPP-TEMP-TEST-CASE]。《客户验收报告》，模板见[SPP-TEMP-CA-REPORT]。补充说明：“客户验收”是针对合同项目而言的，对于非合同项目，请参见Beta测试[SPP-PROC-BETA]。2客户验收规程2.1目的客户依据合同对产品进行审查和测试，确保产品满足客户需求。2.2角色与职责客户方组建一个验收小组，并指定验收负责人。开发方的项目经理和其他成员为客户验收工作提供协助。开发方应当及时解决客户方发现的问题。2.3启动准则系统测试已经完成。开发方对客户进行了必要的培训，参见培训管理规范[SPP-PROC-TM]。2.4输入产品需求文档需求变更记录产品使用指南有关合同2.5主要步骤[Step1]验收准备开发方和客户方共同制定《客户验收计划》，主要包括“成果审查计划”和“验收测试计划”。双方的负责人审批该计划。开发方和客户方共同设计“验收测试用例”。开发方将待验收的工作成果准备好，并将必要的材料提前交给验收小组。[Step2]成果审查与验收测试成果审查。验收人员根据计划审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确的。验收人员将审查结果记录在《客户验收报告》之中。验收测试。验收人员依据计划和测试用例，对待交付的产品进行全面的测试，确保产品符合需求。验收人员将测试结果记录在《客户验收报告》之中。[Step3]问题处理如果验收人员在审查与测试时发现工作成果存在问题，则开发方应当视问题的严重性与客户协商，给出合适的处理措施。如果工作成果存在严重的缺陷，则退回给开发方。开发方应当给出纠正缺陷的措施，双方协商第二次验收的时间。如果给客户方带来损失，应当依据合同对开发方作出相应的处罚。如果工作成果存在一些轻微的缺陷，则开发方应当给出纠正缺陷的措施，双方协商是否需要第二次验收。[Step4]交付与签字当待验收的所有工作成果都通过了审查和测试后，开发方将其交付给客户方。双方的责任人签字认可。2.6输出《客户验收报告》2.7结束准则所有应交付的工作成果都已经通过了客户方的审查与验收。《客户验收报告》已经产生，双方的责任人已经签字认可。2.8度量项目经理统计客户验收期间双方投入的工作量。3实施建议在客户验收之前，开发方对验收人员进行必要的产品培训。开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很好的印象。对验收过程中产生的所有有价值的文档进行配置管理 四、技术评审技术评审（TechnicalReview,TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。本规范阐述了技术评审过程域的两个主要规程：制定技术评审计划[TR-PLANNING]技术评审[TR-FTR]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。技术评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷。技术评审的主要好处有：通过消除工作成果的缺陷而提高产品的质量。越早消除缺陷就越能降低开发成本。开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。可见技术评审有助于“提高质量、提高生产率、降低成本”，符合软件过程改进的根本目的。理论上讲，为了确保产品的质量，产品的所有工作成果都应当接受技术评审。现实中，为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。技术评审过程域有两个主要规程：“制定技术评审计划”、“技术评审”，如图1所示。制定技术评审计划正规技术评审图1技术评审过程域示意图技术评审的注意事项：评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷。技术评审应当“就事论事”，不要打击有失误的开发人员的工作积极性，更不准搞人身攻击（如挖苦、讽刺等）。在会议评审期间要限制过多的争论，以免浪费他人的时间。技术评审过程域产生的主要文档有：整个项目的《技术评审计划》，模板见[SPP-TEMP-TR-PLAN]。《技术评审报告》，模板见[SPP-TEMP-TR-REPORT]。常用的《技术评审检查表》见[SPP-TEMP-TR-CHECKLIST。]2制定技术评审计划2.1目的确定需要评审的工作成果、评审方式，预定评审时间、地点以及相关人员。2.2角色与职责项目的技术负责人（或技术骨干）制定《技术评审计划》。项目经理审批《技术评审计划》。2.3启动准则《项目计划》已经制定。2.4输入《项目计划》2.5主要步骤[Step1]确定需要评审的工作成果如果项目的时间充足，为了确保产品的质量，应当对产品的所有工作成果都进行技术评审。如果项目的时间不充足，为了节约时间，可以选择一些重要的工作成果对其进行技术评审。[Step2]确定技术评审方式根据工作成果的重要性和复杂性确定技术评审方式。将重要性、复杂性各分“高、中、低”3个等级。重要性－复杂性组合与技术评审方式的对应关系见下表。重要性－复杂性组重要性－复杂性组合技术评审方式（FTR,ITR）高高FTR高中FTR高低FTR或者ITR均可中中FTR或者ITR均可中低中低ITR低低ITR表2重要性－复杂性组合与技术评审方式的对应关系[Step3]预定评审时间、地点以及相关人员根据《项目计划》中的进度表，预定评审时间和地点。根据工作成果的特征预定评审主持人和其他评审员。[Step4]审批计划项目经理根据《项目计划》以及现实情况（如可以支配的人力资源），审批《技术评审计划》。项目的技术负责人（或技术骨干）应根据项目经理的批示修正《技术评审计划》。2.6输出《技术评审计划》2.7结束准则《技术评审计划》已经制定并被项目经理批准。2.8度量技术负责人（或技术骨干）统计工作量和上述文档的规模，汇报给项目经理。3技术评审3.1目的对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。3.2角色与职责作者：是指待评审的工作成果的开发者，可能是一个人也可能是个小组。在评审会议期间，作者答复评审小组的问题，并与评审小组共同查找缺陷、商讨缺陷解决方案。评审会议结束后，作者应当及时消除工作成果中的缺陷。评审小组评审主持人是应当具备比较高的技术水平和比较丰富的评审经验，能够控制评审会议的进程。评审主持人可以是项目内的技术骨干也可以是项目外的技术专家。评审主持人本身是一名评审员，评审结论必须有评审主持人的签字才能生效。评审员主要来源于项目内和项目外的技术人员，必要时还应当邀请客户和质量保证人员担任评审员。工作成果的作者不能担任评审员。评审员的人选以及分工都由评审主持人来确定。评审员应当根据“检查表”认真地查找工作成果中的缺陷，并和作者共同商讨缺陷解决方案。评审小组的总人数一般在3～7人之间。记录员：由评审主持人指定一位评审员来担任记录员。记录员如实地将评审过程记录在指定的文档中。3.3启动准则作者已经按照指定的格式（如模板）完成了工作成果，对工作成果进行了内部检查，消除了拼写、排版等初级错误。根据《技术评审计划》，该工作成果进行正式技术评审的时间已到。3.4输入待评审的工作成果。与该工作成果评审相关的一些材料，如检查表。3.5主要步骤技术评审的流程如图16-2所示。Step3.修正跟踪审核Step2.举行评审会议Step1.准备评审2.1主持人宣讲2.2作者介绍工作成果2.3识别缺陷和答辩2.4讨论缺陷解决方案2.5会议结束决议3.1修正与跟踪3.2递交审核3.3审核工作成果图16-2技术评审的流程图[Step1]准备评审评审主持人首先确定评审会议的时间、地点、设备和参加会议的人员名单（包括评审员、记录员、作者、旁听者等），然后起草《技术评审通知》，并告知所有相关人员。评审主持人把工作成果及相关材料、技术评审规程、检查表等发给评审员。评审员阅读（了解）工作成果及相关材料。[Step2]举行评审会议[Step2.1]主持人宣讲主持人宣讲本次评审会议的议程、重点、原则、时间限制等。[Step2.2]作者介绍工作成果作者扼要地介绍工作成果。[Step2.3]识别缺陷和答辩评审员根据“检查表”认真查找工作成果的缺陷。作者回答评审员的问题，双方要对每个缺陷达成共识（避免误解）。[Step2.4]讨论缺陷解决方案作者和评审员共同讨论缺陷的解决方案。对于当场难以解决的问题，由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。[Step2.5]会议结束决议评审小组给出评审结论和意见，主持人签字后本次会议结束。评审结论有三种：工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。工作成果基本合格，需要作少量的修改，之后通过审核即可。工作成果不合格，需要作比较大的修改，之后必须重新对其评审。[Step3]修正、跟踪与审核[Step3.1]修正与跟踪作者修正工作成果，消除已发现的缺陷。评审主持人（或者指定审查员）跟踪每个缺陷的状态。[Step3.2]提交审核作者消除所有已发现的缺陷后，再将修正后的工作成果递交给评审主持人（或者指定审查员）审核。[Step3.2]审核工作成果评审主持人（或者指定审查员）审核修正后的工作成果。审核结论有两种：修正后的工作成果合格。修正后的工作成果仍然不合格，需重新修改，重复[Step3]。3.6输出该工作成果的《技术评审报告》。根据评审报告修正后的工作成果。3.7结束准则工作成果中所有已识别的缺陷都已经被消除。3.8度量评审主持人统计工作量和上述文档的规模，汇报给项目经理。4实施建议对于重要性和复杂性都很高的工作成果，建议先在项目内部进行“非正式技术评审”，然后再进行“正式技术评审”。技术评审应当与质量保证有机地结合起来，请质量保证人员参加并监督正规技术评审是很好的方式。技术评审应当与配置管理有机地结合起来，规定没有通过技术评审的工作成果不允许成为基准文件（Baselined）。建议机构采用统一的缺陷跟踪工具，使得技术评审所发现的缺陷能被及时地消除，不被遗漏。第四篇支撑过程一、配置管理配置管理（ConfigurationManagement,CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。配置管理过程域是SPP模型的重要组成部分。本规范阐述了配置管理过程域的四个主要规程：制定配置管理计划[PASS-PROC-CM-PLANNING]配置库管理[PASS-PROC-CM-LIB]配置项版本控制[PASS-PROC-CM-VERSION]配置项变更控制[PASS-PROC-CM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项（ConfigurationItem,CI），配置项主要有两大类：（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。（2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。所有的项目成员都要使用配置管理软件来保护自己的工作成果。XX软件采用Subversion作为配置管理工具。配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。配置管理的流程如图17-1所示。版本控制制定配置管理计划配置库管理变更控制配置审计图17-1配置管理流程图制定配置管理计划配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。版本控制在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。变更控制在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。配置审计为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。请参考质量保证规范SPP-PROC-QA，此处不再论述。配置管理过程域产生的主要文档有：《配置管理计划》，模板见[SPP-TEMP-CM-PLAN]。《配置库管理报告》，模板见[SPP-TEMP-CM-LIB]。《配置项变更控制报告》，模板见[SPP-TEMP-CM-CHANGE]。2制定配置管理计划2.1目的制定配置管理计划，以便有计划地开展配置管理工作。2.2角色与职责配置管理员制定《配置管理计划》。CCB审批《配置管理计划》。CCB的人数视项目的规模而定。通常CCB由项目经理、资深项目成员等人组成，项目经理为CCB负责人。CCB的决策采用“少数服从多数”原则。2.3启动准则《项目计划》已经制定配置管理员和CCB已经确定。2.4输入《项目计划》2.5主要步骤[Step1]确定配置管理的软硬件资源[Step2]制定配置项计划配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式为Project-Type…Type-Number。配置项计划的参考格式如下：类型类型主要配置项标识符预计正式发布时间[Step3]制定基线计划配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。基线计划的参考格式如下：基线名称基线名称/标识符基线所包含的主要配置项预计建立时间[Step4]制定配置库备份计划配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。2.6输出《配置管理计划》2.7结束准则《配置管理计划》已经制定并被CCB的批准。2.8度量配置管理统计工作量以及文档的规模，汇报给项目经理。3配置库管理3.1目的所有人员依照配置管理规范和《配置管理计划》操作配置库。3.2角色与职责配置管理创建并维护配置库。项目成员在权限之内操作配置库。3.3启动准则《配置管理计划》已经制定。配置管理的软件硬件已经存在。3.4输入《配置管理计划》3.5主要步骤[Step1]创建配置库配置管理员创建配置库，并且至少创建配置库的所有第一级目录。[Step2]分配权限配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add,Checkin/Checkout,Download等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。[Step3]配置库操作与管理项目成员根据自己的权限操作配置库，例如Add,Checkin/Checkout,Download等。配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。配置管理员定期清除配置库里的垃圾文件。配置管理员定期备份配置库。3.6输出《配置库管理报告》（由配置管理员撰写）3.7结束准则对配置库的操作与管理将持续到项目结束。3.8度量配置管理员统计工作量以及文档规模。4版本控制4.1目的按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。4.2角色与职责所有项目成员都必须遵照版本控制规程操作配置库。5配置项状态变迁规则配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁如图17-2所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。变更控制正式发布正在修改自由修改草稿评审或审批否决通过图17-2配置项状态变迁图6配置项版本号规则配置项的版本号与配置项的状态紧密相关：处于“草稿”状态的配置项的版本号格式为：0.YZYZ数字范围为01-99。随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。处于“正式发布”状态的配置项的版本号格式为：X.YX为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。配置项第一次“正式发布”时，版本号为1.0。如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。处于“正在修改”状态的配置项的版本号格式为：X.YZ配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则（2）。7补充要求所有人员对其工作成果进行配置管理。对全员进行配置管理培训。由于配置库里保存的是项目的所有工作成果，应当选择“责任心强、可靠”的人员担任配置管理员。 二、质量保证质量保证（QualityAssurance,QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。本规范阐述了质量保证过程域的三个主要规程：制定质量保证计划[PASS-PROC-QA-PLANNING]过程与产品质量检查[PASS-PROC-QA-PPQC]问题跟踪与质量改进[PASS-PROC-QA-TRACKING]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。1介绍过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心产品质量。提高产品质量有三种基本方法：质量保证。质量保证人员通过有计划地检查“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量”与“产品质量”。技术评审。请同行专家、技术人员对工作成果进行评审，尽早发现工作成果中的缺陷。测试。通过运行测试用例来找出软件中的缺陷。例如单元测试、集成测试、系统测试、验收测试等。质量保证既关心过程质量又关心产品质量。如果“工作过程以及工作成果”不符合既定的规范，那么产品的质量肯定有问题。基于这样的推理，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质量。这是质量保证方法富有成效的一面。但是“工作过程以及工作成果”符合既定的规范却并不意味着产品的质量一定合格，因为仅靠规范无法识别出产品中可能存在的大量缺陷。这是质量保证方法的不足之处。所以单独的“质量保证”其实并不能“保证质量”。技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。技术评审和测试能弥补质量保证的不足，三者是相辅相成的质量管理方法。我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。让质量保证人员参加并监督重要的技术评审和测试工作，这是很好的方法。把三者有机地结合起来，可提高工作效率，降低成本。质量保证小组（QualityAssuranceGroup,QAG）有如下特点：质量保证小组在行政上独立于任何项目。这种独立性有助于质量保证小组客观地检查和监控“过程以及产品的质量”。质量保证小组有一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得质量保证小组的工作不会被轻视，并有助于加强全员的质量意识。需要强调的是，提高产品质量是全员的职责，并非只是质量保证小组的职责。质量保证过程域有3个主要规程：“制定质量保证计划”、“过程与产品质量检查”和“问题跟踪与质量改进”，如图18-1所示。制定质量保证计划质量保证小组为每个项目指定一名质量保证员（即接口人）。质量保证员撰写《质量保证计划》，项目经理和质量经理审批该计划。《质量保证计划》的主要内容是“过程与产品质量检查计划”、“参与技术评审计划”和“参与测试计划”。过程与产品质量检查质量保证员客观地检查项目成员的“工作过程”和“工作成果”是否符合既定的规范，并与项目成员协商改进措施。质量保证员记录本次检查的结果和经验教训，并及时通报给所有相关人员。问题跟踪与质量改进质量保证员设法先在项目内部解决质量问题，如果在项目内部难以解决，则提交给上级领导处理。质量保证小组分析机构内共性的质量问题，给出质量改进措施。制定质量保证计划过程与产品质量检查问题跟踪与质量改进周期性地开展技术评审测试表示质量保证与技术评审、测试有机结合图18-1质量保证过程域示意图质量保证过程域产生的主要文档有：《质量保证计划》，模板见[SPP-TEMP-QA-PLAN]。《质量保证检查表》，模板见[SPP-TEMP-QA-CHECKLIST]。《质量保证报告》，模板见[SPP-TEMP-QA-REPORT]。《质量问题跟踪表》，模板见[SPP-TEMP-QA-TRACKING]。2制定质量保证计划2.1目的制定关于检查和改进过程质量、产品质量的计划。2.2角色与职责质量保证小组为每个项目指定一名质量保证员（即接口人）。项目的质量保证员制定《质量保证计划》。项目经理和质量经理（如果存在的话）审批《质量保证计划》。2.3启动准则《项目计划》已经制定。该项目的质量保证员已经确定。2.4输入《项目计划》2.5主要步骤[Step1]制定过程与产品质量检查计划质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果，并估计检查时间和人员。注意，对某些过程域的检查应当是周期性的而不是一次性的，例如配置管理、需求管理等。质量保证员确定相应的检查表（模板见SPP-TEMP-QA-CHECKLIST）。[Step2]制定“参与技术评审”的计划《技术评审计划》一般由项目经理或者项目的技术骨干制定。质量保证员应当参与并监督重要工作成果如需求、设计、代码的技术评审。质量保证员根据《技术评审计划》，制定“参与技术评审”的计划。[Step3]制定“参与测试”的计划一般地，项目开发小组自己负责单元测试和集成测试，机构独立测试小组负责最终产品的测试（如系统测试和验收测试）。由于测试的种类比较多，《测试计划》也可能有多个。质量保证员应当参与并监督重要工作成果的测试。质量保证员参考各种《测试计划》，制定“参与测试”的计划。[Step4]审批质量保证计划虽然质量保证小组在行政上独立于任何项目，但是质量保证员的工作与项目紧密相关，所以《质量保证计划》应当经过项目经理的审批才能生效，以确保《质量保证计划》与《项目计划》一致。如果机构存在质量经理，那么质量经理也要审批《质量保证计划》，以确保《质量保证计划》符合机构的要求（避免过于宽松而流于形式）。2.6输出《质量保证计划》2.7结束准则《质量保证计划》已经制定，项目经理和质量经理（如果存在的话）批准该计划。2.8度量质量保证员统计工作量和上述文档的规模，汇报给项目经理和质量经理。3过程与产品质量检查3.1目的客观地检查项目开发小组的“工作过程”和“工作成果”是否符合既定的规范。3.2角色与职责质量保证员负责过程与产品质量检查。3.3启动准则根据《质量保证计划》执行质量检查。3.4输入《质量保证计划》质量保证检查表3.5主要步骤[Step1]准备质量保证员和项目经理确定本次质量检查的时间、地点、参加人员等。[Step2]客观地检查过程质量质量保证员根据检查表，和相关的项目成员交谈，检查项目的实际执行过程（包括项目管理过程、项目研发过程、机构支撑过程等）是否符合既定的规范。如果发现不一致，质量保证员应当与相关人员分析原因并协商改进措施。[Step3]客观地检查工作成果的质量质量保证员根据检查表，和相关的项目成员交谈，检查项目的工作成果是否符合既定的规范（一个产品包含很多工作成果）。如果发现不一致，质量保证员应当与相关人员分析原因并协商改进措施。[Step4]记录检查结果质量保证员如实记录本次质量检查结果，并总结经验教训。该信息保存在《质量保证工作报告》中。[Step5]通报结果质量保证员及时将本次质量检查的结果、经验教训通报给所有项目成员、上级领导和其他相关的人员。3.6输出《质量保证报告》3.7结束准则质量保证员已经客观地检查了过程质量和工作成果的质量。质量保证员把本次PPQC结果、经验教训通报给所有相关人员。3.8度量质量保证员统计工作量和上述文档的规模，汇报给项目经理。4问题跟踪与质量改进4.1目的识别质量问题并跟踪问题的解决过程；分析共性质量问题，给出质量改进措施。4.2角色与职责项目的质量保证员识别质量问题并跟踪问题的解决过程。质量保证小组分析机构内共性的质量问题，给出质量改进措施。4.3启动准则有关人员已经执行质量检查、技术评审或者产品测试。4.4输入质量检查、技术评审或者产品测试的报告4.5主要步骤[Step1]记录质量问题质量保证员记录在质量检查、技术评审和产品测试过程中发现的质量问题。[Step2]确定解决措施质量保证员首先设法在项目内解决已经发现的质量问题，与项目成员们协商解决措施。质量保证员识别出那些在项目内难以解决的质量问题，将这些问题递交给上级领导，由上级领导给出解决措施。[Step3]跟踪问题的解决过程质量保证员跟踪问题的解决过程，记录问题的状态，直到问题被解决为止。[Step4]分析共性问题，给出改进措施质量保证小组分析机构内共性的质量问题，给出质量改进措施。4.6输出《质量问题跟踪表》4.7结束准则所有已经识别出来的质量问题都得到妥善的解决。4.8度量质量保证员统计工作量和上述文档的规模，汇报给项目经理。5补充企业根据自身的实力、人力资源组建质量保证小组，人员可以是全职的也可以是兼职的。一般地，质量保证小组和SEPG之和占企业总人数的5％左右。质量保证小组应当拥有直接向上级领导反映情况、提出建议的权利，如果质量保证小组的地位无足轻重，他的工作很容易被项目成员轻视或抵制。先对质量保证小组进行培训，让他们掌握必要的工作技能。 三、培训管理培训管理（TrainingManagement,TM）是指根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。培训管理过程域是SPP模型的重要组成部分。本规范阐述了培训管理过程域的两个主要规程：机构培训管理[PASS-PROC-TM-ORG]项目培训管理[PASS-PROC-QA-PROJECT]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。1介绍按范围划分，培训管理可分为“机构培训管理”和“项目培训管理”。流程如图20-1所示。确定机构培训需求执行培训制定机构培训计划培训效果评估确定项目培训需求执行培训制定