CMMI培训讲义2.pdf

《CMMI培训讲义2.pdf》由会员分享，可在线阅读，更多相关《CMMI培训讲义2.pdf（118页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 CMMI 培训讲义（2）编写：胡希明 2005 年年 7 月月 目 录 第四章第四章 需求管理需求管理.1 4.1 需求管理标准文本译文.1 4.2 需求管理要点.8 4.3 需求管理实施计划.14 4.4 软件需求评审规程（略）.20 4.5 软件需求评审检查单（略）.20 4.6 需求规格说明书模板（略）.20 第五章第五章 项目策划项目策划.21 5.1 项目策划标准文本摘要.21 5.2 项目策划要点.27 5.3 项目策划实施计划.35 5.4 项目策划规程（略）.41 5.5 规模估算规程（略）.41 5.5工作量估算规程（略）.41 5.8软件风险管理规程（略）.41 5.9

2、项目进度表编制规程（略）.41 5.10 项目计划模板（略）.41 5.11 项目进度表模板（略）.41 第六章第六章 项目监控项目监控.42 6.1项目监控标准文本摘要.42 6.2 项目监控要点.46 6.3 项目监控实施计划.48 6.4 项目监测规程（略）.53 6.5 里程碑评审规程（略）.53 6.6 项目状态报告模板（略）.53 第七章第七章 配置管理配置管理.54 7.1 配置管理标准文本摘要.54 7.2 配置管理要点.59 7.3 配置管理实施计划.63 7.4 配置管理规程（略）.68 7.5 配置项变更控制规程（略）.68 7.6 配置审计规程（略）.68 第八章第八章

3、 过程和产品质量保证过程和产品质量保证.69 8.1 过程和产品质量保证标准文本摘要.69 8.2 过程和产品质量保证要点.73 8.3 过程和产品质量保证实施计划.76 8.4 PPQA审计规程（略）.80 第九章第九章 测量与分析测量与分析.81 9.1测量与分析标准文本摘要.81 9.2 测量与分析要点.85 9.3 测量与分析实施计划.92 9.4 度量策划规程（略）.96 9.5 机构测量大纲模板（略）.96 第十章第十章 供方合同管理供方合同管理.97 10.1 供方合同管理标准文本摘要.97 10.2 供方合同管理要点.102 10.3 供方合同管理实施计划.109 第 1 页

4、共 115 页 第四章第四章 需求管理需求管理 从这一章开始，逐个介绍全部过程域，一个过程域一章。每章的第一节给出该过程域标准文本的摘要（目标和实践），然后再分节介绍实施过程中的问题。需求管理作为第一个过程域，章节安排稍有不同，第一节全文给出标准文本的参考译文（不是摘要），其他节则除了具体实施中的问题之外，还涉及 CMMI 模型具体实施中的一些共性问题（此类问题，在以后的章节中就不再重复了）。4.1 需求管理标准文本译文需求管理标准文本译文 需求管理需求管理 成熟度等级 2 目的目的 需求管理的目的是管理项目产品和产品构件的需求，并识别需求与项目计划和工作产品之间的不符合项。概述概述 本过程域

5、所包含的多个需求管理过程应管理由机构指派、项目组接受或产生的全部需求，包括技术性需求和非技术性需求。特别是，如果需求开发过程域已经实施，相关的诸过程将会生成产品和产品构件的需求，这些需求就应由需求管理过程域的相关过程进行管理。当需求管理、需求开发和技术解决方案三个过程域都得到实施时，其中各个相互联系的过程应该紧密配合、协调一致地得到执行。项目组应采取适当的步骤，确保协商一致的需求得到管理，以支持项目策划和项目计划的执行。当项目组从被认可的需求提供者接受需求时，在将需求纳入项目计划之前，应与需求提供者一起对需求进行评审，以解决争议问题或者防止误解。需求提供者与接受者之间一旦取得一致，项目组就应从

6、项目参加者那里取得对于需求的承诺。项目组应该管理需求变更（当出现变更时），并且识别在项目计划、工作产品和需求之间发生的不一致项。作为需求管理的一个部分，需求变更及其理由应填入记录文档，并且在最初需求与产品和产品构件的所有需求之间维持双向可追溯性。相关过程域相关过程域 有关如何将项目干系人的需求转换成产品需求，以及如何决定在各个产品构件之间安排或分配这些需求的更多信息，参考需求开发需求开发过程域。有关把需求转换成技术解决方案的更多信息，参考技术解决方案技术解决方案过程域。有关项目计划如何反映需求及其变更的更多信息，参考“项目策划”过程域。第 2 页 共 115 页 有关基线和配置变更控制的更多信

7、息，参见配置管理配置管理过程域。有关如何根据需求跟踪和控制各项活动和工作产品以及采取必要纠正措施的更多信息，参考项目监督和控制目监督和控制过程域。有关如何识别和处理与需求相关的风险的更多信息，参考风险管理风险管理过程域。特定目标和共性目标特定目标和共性目标 SG 1 管理需求管理需求 对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。GG 2 制度化为受管理过程制度化为受管理过程 将过程制度化成受管理的过程。将过程制度化成受管理的过程。GG3 制度化为已定义过程制度化为已定义过程 将过程制度化为已定义的过程。将过程制度化

8、为已定义的过程。目标实践对照表目标实践对照表 SG 1 管理需求 SP1.1-1 取得对需求的理解 SP1.2-2 取得对需求的承诺 SP1.3-1 管理需求变更 SP1.4-2 维护需求的双向可追溯性 SP1.5-1 识别项目工作与需求之间的不一致项 GG 2 制度化为受管理过程 GP 2.1 （CO 1）制定机构方针 GP 2.2 （AB 1）策划过程 GP 2.3 （AB 2）提供资源 GP 2.4 （AB 3）分配职责 GP 2.5 （AB 4）培训人员 GP 2.6 （OI 1）管理配置项 GP 2.7 （DI 2）识别相关的项目干系人并使之介入（项目过程活动）GP 2.8 （DI

9、3）监督和控制过程 GP 2.9 （VE 1）客观评价遵循情况 GP 2.10（VE 2）高层管理者参与（过程）状态评审（对于成熟度等级 2 级而言，以下的目标不是必需的，其实践也不是期望的，但是对 3 级而言，下列目标及实践以及上列目标及实践，均是必需的或期望的。）GG3 制度化为已定义过程 GP3.1 建立（项目）定义过程 GP3.2 收集改进信息 特定目标和特定实践特定目标和特定实践 SG 1 管理需求管理需求 对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。对需求进行管理，并识别需求与项目计划和工作产品之间的不一致项。在整个项目生存周期中，项目组应通过下列活动维护经过确认

10、的最新需求：?管理所有的需求变更；?维护需求与项目计划和工作产品之间的对应关系；?识别需求与项目计划和工作产品之间的不符合项；第 3 页 共 115 页?采取纠正措施。有关判定需求可实现性的更多信息，参考技术解决方案技术解决方案过程域。有关确保需求反映顾客需要和期望的更多信息，参考需求开发需求开发过程域。有关采取纠正措施的更多信息，参考过程监督和控制过程监督和控制过程域。对于软件工程学科而言，需求可能是整个产品需求的一部分，也可能是全部。对于系统工程学科而言，系统每个结构层次的需求均来自上一个结构层次。SP 1.1-1 取得对需求的理解取得对需求的理解 理解需求提供者提出的需求的含义。理解需求

11、提供者提出的需求的含义。随着项目的进展和需求的衍生，各项活动或科目会（不断地）收到新的需求。为了避免需求漂移（creep）(需求不断的增加或变化)，应建立准则，用以指明接受需求的正规渠道或需求的合法来源。接受需求的活动应该包括与需求提供者一起进行的需求分析活动，以确保对需求的含义取得一致的理解。分析和对话的结果是达成一致理解的需求集合。典型工作产品典型工作产品 1.合格需求提供者判别准则。2.需求验收和鉴定标准。3.根据准则进行分析后所得的各类结果。4.达成一致理解的需求集。子实践子实践 1.制定合格需求提供者判别准则。2.制定需求验收的客观标准。缺少验收标准通常将导致不充分的验证、高代价的返

12、工以至用户拒收。3.分析需求，确保满足所制定的准则。4.与需求提供者达成对需求的(共同)理解，以便项目参加者能够对需求做出承诺。SP 1.2-2 取得对需求的承诺取得对需求的承诺 从项目参加者处取得对需求的承诺。从项目参加者处取得对需求的承诺。验收标准的实例如下：?叙述清楚和准确。?完整。?彼此一致。?唯一。?可实现。?可验证（可测试）。?可跟踪。第 4 页 共 115 页 有关如何监督是否作出承诺的更多信息，参考项目监督和控制项目监督和控制过程域。对于 IPPD（集成化产品和过程开发）学科而言，应注意：组建集成化群组时，项目参加者应作为群组的成员。对每一个集成化小组来说，针对因小组之间互相配

13、合的需要而做出的承诺，与对产品或项目其他需求而作出的承诺具有同样的重要性。通过特定实践 Sp1.1-1，项目组与需求提供者对需求有了共同的理解，特定实践 Sp1.2-2 所要处理的问题则是在所有应执行需求实现所必需的活动的人员或群组之间协商一致并做出承诺。正如需求开发需求开发和技术解决方案技术解决方案过程域所描述的，需求变化贯穿项目全过程。当需求发生变化时，实践 SP1.2-2 就可确保项目参加者对已确认的最新需求（重新）作出承诺，并且对因需求变化而导致改动的项目计划、活动和工作产品做出承诺。典型工作产品：典型工作产品：1.需求影响评估结果。2.对需求及其变更的承诺的记录文档。子实践子实践 1

14、.评估各项需求（包括或特别是变更需求）对已有承诺的影响。当需求发生变更或提出新需求时，应评价它们对项目参加者的影响。2.协商并记录承诺。在项目参加者对需求或需求变更作出承诺之前，应协商已有承诺的变更。SP 1.3-1 管理需求变更管理需求变更 在项目开发期间，需求发生变更时，应对需求变更进行管理。在项目开发期间，需求发生变更时，应对需求变更进行管理。有关维护和控制需求基线以及如何使需求及其变更信息能为整个项目组所用的更多信息，参考配置管理配置管理过程域。在项目开发期间，需求会由于各种原因而发生变化。当原来的需要发生变化并且工作还需要继续进行时，产生了附加的需求，因此必需对现有的需求做出相应的变

15、更。此时，最重要的事情就是有效地和高效的管理这些新增需求和变更。为了有效地分析变更的影响，应该知道每项需求的最初形态，并记录其变更原因。项目经理还可能要跟踪需求发散性的合理度量，以便判断是否需要采取新的控制措施或修改已有的控制措施。典型工作产品典型工作产品 1.需求状态表。2.需求数据库。3.需求决策数据库。子实践子实践 1.汇集交给项目组的或者项目组产生的全部需求及其变更。第 5 页 共 115 页 2.维护需求变更的历史及变更理由。维护变更的历史数据有助于跟踪需求的发散性。3.从相关的项目干系人的角度出发评价需求变更的影响。4.使需求和需求变更数据可供项目组使用。SP 1.4-2 维护需求

16、的双向可追溯性维护需求的双向可追溯性 维护需求与项目计划和工作产品之间的双向可追溯性。维护需求与项目计划和工作产品之间的双向可追溯性。这个特定实践的意图在于维护每个产品分解层次的需求的双向可追溯性。如果需求得到很好的管理，就可以建立起从原始需求到它的较低层次的需求的可跟踪性，以及从较低层次的需求回到较高层次的最初需求的可回溯性。这种双向可追溯性有助于确定是否所有原始需求都完全得到处理，是否所有的低层需求都可以回溯到有效的来源。需求的可追溯性还可以用于维持需求与其他事项的关系，例如，中间产品或最终工作产品、设计文档的变更、测试计划、以及工作任务等。可追溯性应该包括横向可追溯性和纵向可追溯性，例如

17、，横跨接口两边的需求。在评估需求变更对项目计划、活动以及工作产品的影响时，尤其需要可追溯性。典型工作产品典型工作产品 1.需求追溯性矩阵。2.需求跟踪系统。子实践子实践 1.维护需求的可追溯性，以确保将低层（派生）需求的源需求记入文档。2.维护每个需求与它的各个派生需求的可追溯性，维护每个需求与功能分配、目标、人员和过程的可追溯性。3.维护功能（模块）之间和跨接口二边的功能之间的横向可溯性。4.生成需求可追溯矩阵。SP 1.5-1 识别项目工作与需求之间的不符合项识别项目工作与需求之间的不符合项 识别项目计划和工作产品与需求之间的不符合项。识别项目计划和工作产品与需求之间的不符合项。关于监督和

18、控制项目计划和工作产品与需求的一致性，以及必要时采取纠正措施的更多信息，参考项目监督和控制项目监督和控制过程域。这个特定实践旨在发现需求与项目计划和工作产品之间的不一致项，并且启动纠正措施。典型工作产品典型工作产品 1.以文档形式记录不符合项，包括来源、条件和理由。2.纠正措施。子实践子实践 1.评审项目计划、活动和工作产品与需求及其变更的一致性。第 6 页 共 115 页 2.识别不符合项的来源和理由。3.识别因需求基线的变更而导致的项目计划、活动和工作产品的变更。4.启动纠正措施。GG 2 制度化为受管理过程制度化为受管理过程 作为受管理过程加以制度化。作为受管理过程加以制度化。执行承诺执

19、行承诺 GP 2.1（CO1）制定机构方针制定机构方针 为策划和执行需求管理过程，制定并维护机构方针。为策划和执行需求管理过程，制定并维护机构方针。详细说明详细说明 这个方针反映或表明了机构对需求管理、以及识别需求与项目计划和工作产品不符合项活动的期望或要求。执行能力执行能力 GP 2.2（AB1）策划过程策划过程 制定并维护需求管理过程的实施计划。制定并维护需求管理过程的实施计划。详细说明详细说明 典型的做法是将执行需求管理过程的计划作为项目计划的一个部分，详见项目策划项目策划过程域。GP 2.3(AB2)提供资源提供资源 为执行需求管理过程、开发工作产品和提供需求管理过程所需的服务，提供足

20、够的资源。为执行需求管理过程、开发工作产品和提供需求管理过程所需的服务，提供足够的资源。详细说明详细说明 GP 2.4(AB3)分配职责分配职责 为执行过程、开发工作产品和提供需求管理过程所需的服务，分配责任和权限。为执行过程、开发工作产品和提供需求管理过程所需的服务，分配责任和权限。GP 2.5(AB4)培训人员培训人员 对执行或支持需求管理过程的人员进行必要的培训。对执行或支持需求管理过程的人员进行必要的培训。详细说明详细说明 指导实践指导实践 GP 2.6(DI1)管理配置项管理配置项 把需求管理过程的工作产品置于配置管理的适当层次。把需求管理过程的工作产品置于配置管理的适当层次。详细说

21、明详细说明 例如，提供的资源包括下列工具：?需求跟踪工具。?可跟踪性工具。培训课题的例子如下：?应用领域。?需求定义、分析、评审和管理。?需求管理工具。?配置管理。?协商和冲突解决。第 7 页 共 115 页 GP 2.7(DI2)识别相关的项目干系人并使之介入（过程活动）识别相关的项目干系人并使之介入（过程活动）识别项目干系人，并使其按计划要求介入需求管理过程。识别项目干系人，并使其按计划要求介入需求管理过程。详细说明详细说明 在顾客、最终用户、开发人员、生产人员、测试人员、支持人员、营销人员、维护人员、辅助人员、以及其他可能受产品和过程影响或者可能影响产品和过程的人员中挑选项目干系人。GP

22、 2.8(DI3)监督和控制过程监督和控制过程 按计划监督和控制需求管理过程，并且采取适当的纠正措施。按计划监督和控制需求管理过程，并且采取适当的纠正措施。详细说明详细说明 验证实施验证实施 GP 2.9(VE1)客观评价遵循情况客观评价遵循情况 客观地评价需求管理过程以及该过程的工作产品和服务对适用的需求、目标和标准的遵循情况，并且处理不符合项。客观地评价需求管理过程以及该过程的工作产品和服务对适用的需求、目标和标准的遵循情况，并且处理不符合项。详细说明详细说明 GP 2.10(VE2)高层管理者审查状态高层管理者审查状态 高层管理者评审需求管理过程的活动、状态和结果，并解决争议问题。详细说

23、明:高层管理者应评审来自机构外部的修改已有承诺的提议，以确保全部承诺得到实现。对于成熟度等级 2 级而言，以下的目标不是必需的，其实践也不是期望的，但是对 3级而言，下列目标及实践以及上列目标及实践，均是必需的或期望的。GG3 制度化为已定义过程制度化为已定义过程 置于配置管理之下的工作产品的例子如下：?需求。?需求跟踪矩阵。项目干系人应介入的活动，包括：?解决需求理解的争议问题。?评估需求变更的影响。?通报双向可追溯性。?识别需求与项目计划和工作产品之间的不一致项。在监督和控制需求管理过程的活动中使用的度量，如下：?需求发散性（需求变更的百分比）。被审查的活动的例子如下：?进行需求管理。?识

24、别项目计划和工作产品与需求之间的不一致。被审查的工作产品的例子如下：?需求。?需求可追溯性矩阵。第 8 页 共 115 页 将过程制度化为已定义过程 GP3.1 建立已定义过程建立已定义过程 建立并维护已定义的需求管理过程的描述。GP3.2 收集改进信息收集改进信息 收集工作产品、度量定义、度量结果以及来自策划和执行需求管理过程的其他改进信息，比便将来使用并支持机构标准过程 OSSP 和机构过程资产 OPA 的改进。4.2 需求管理要点4.2 需求管理要点 如何实施需求管理过程域，例如，需求是什么，需求管理要求达到什么目的，如何达到这些目的，写些什么文档，文档怎么写，标准文本的规定怎样结合机构

25、的具体情况，等等。本节拟对此问题分成 6 个要点，逐点给出详细的说明。管理需求，需求到底指什么 从 CMMI 结构角度看，需求管理过程域与另外二个过程域需求开发（RD）和技术解决方案（TS）密切相关。严格讲，应该是需求开发过程域的执行结果第 9 页 共 115 页 就是需求管理过程域的管理对象，或者是需求开发和技术解决方案二个过程域的执行结果作为需求管理过程域的管理对象。但是，RD 和 TS 二个过程域被列入 3级，如果一个机构先实施 2 级的过程域，这个时候就会遇到一些困惑。从国内软件企业的实际情况看，交给项目组作为应完成任务的最初描述的需求（给定需求），其来源大体有三个：?直接来自机构外部

26、（即合同甲方），此时，给定需求就是以委托方式或合作方式提交的任务书；或者是通过项目投标最终以合同形式确定的用户需求，其载体就是投标书、合同及其技术附件以及合同签订后编写的软件需求文档，当然还应包括项目开始后几乎难以避免的变更需求；也可以间接的来自外部机构，此时，公司内部不同部门或公司外部的委托方或合作方承接的整个集成项目分配给项目组的软件开发任务就是给定需求。?来自部门内部的新产品开发，此时给定需求及其载体就是新产品可行性研究报告、软件需求文档（初稿）以及相应的软件立项审批表。?来自已发布产品或已提交项目的最终用户，此时，不同的最终用户或同一个最终用户在不同时间、不可预料地提出的产品的每一个缺

27、陷报告或个性化修改要求都是给定需求，其载体可能是用户的传真或电子邮件，也可能是维护部门的电话记录，还可能是市场人员、工程人员的间接反映。【说明：第三种需求的管理纳入维护阶段作为产品问题报告另做专门叙述。需求管理主要针对前面二种需求。】另外，给定需求（特别是合同项目的需求）往往不能从技术上给出全面、完整、详细的软件产品描述，还需要由项目组长或其上一级主管进一步与用户（即合同甲方或产品最终用户）沟通，或者征求相关人员的意见，形成比合同甲方最初提出或产品立项阶段初步确定的给定需求更完整、更明确的软件需求。严格讲，这是立项阶段的工作产品，而实际上这里往往有一个交叉，项目组还得利用软件需求评审的机会，进

28、一步完善软件需求。因此，需求管理的范围应该包括：软件需求文档的完善、软件需求评审以及软件需求规格说明书编制、同行评审和审批，还有就是在生命周期全过程中需求变更的控制和管理，以及需求跟踪。管理需求，要达到什么目的，包含几项特定实践 标准文本只规定了一个特定目标，“对需求进行管理，并识别需求与项目计划和工作产品的不一致性”，并规定了为达到这个目标而期望执行的 5 项实践：?在项目开始阶段，?对文档化的需求进行评审，“以取得项目干系人（特别是甲方或集成化团队中其他相关组）对需求的共同理解”，形成需求规格说明书。?同时作出必要承诺。?在项目执行期间，?“管理需求变更”，控制并减小变更对项目的影响。?利

29、用需求跟踪矩阵，“维护需求的双向可追溯性”。向前跟踪用以确保需求第 10 页 共 115 页 在生命周期后期阶段（如设计、编码）的工作产品中得到体现；向后跟踪用以判定后期阶段的工作产品满足哪一项需求，以及用于变更管理和回归测试等活动。?通过需求跟踪活动，识别项目计划、工作产品与需求及其变更之间的不一致性、不一致的原因、必要的纠正措施，跟踪纠正措施。需求管理，以何种方式达到目标 除了以上所列的特定目标和特定实践之外，还涉及到以何种方式执行这些实践（即制度化到何种程度）。为了回答这个问题，CMMI 标准中又规定了二个共性目标，用以判定成熟度等级或能力等级。共性目标 GG2,使需求管理作为受管理的过

30、程加以制度化，包括以下活动：1制定并维护针对需求管理的机构方针，2策划需求管理过程，制定并维护需求管理实施计划，3确定并提供需求管理所必需的资源，4分配职责，5培训人员，6管理配置项，7识别项目干系人及其应介入的需求管理活动，8监控需求管理过程，9客观评价遵循情况，10高层管理者审查需求管理活动状况和结果，并解决争议问题。以上 10 项活动中，最重要的活动有三个：?制定并维护机构方针，?制定并维护需求管理实施计划，?管理需求管理所涉及的配置项。机构方针，包括哪些内容，例如，以机构名义正式规定每个项目对需求进行管理时应遵循以下方针：?需求应形成文档。?需求文档应取得项目相关各方的共同理解并做必要

31、的承诺。?需求或需求规格说明书应经过评审并审批。?需求及需求规格说明书的任何变更应得到管理和控制。过程策划的目的是制定并维护需求管理实施计划，按 CMMI 的规定，每个项目组对每个涉及的过程域均应进行策划，然后编写该过程域的实施计划。过程实施计划是规范地实施该过程的纲领性文件，应确保既符合 CMMI 标准文本的规定，又适合机构的实际情况。需求管理实施计划的实例下一节给出。如果机构的成熟度等级已经达到 3 级，或者正在 2 级的基础上实施 3 级所含的过程域，则项目组在实施需求管理时，还应满足 GG3 的要求，“将过程制度化为已定义过程”。此话什么意思？看相关的二个共性实践：?GP3.1，从机构

32、标准过程集（OSSP）出发，结合项目实际情况，按照裁第 11 页 共 115 页 剪指南的规定，定义适合该项目的需求管理过程。机构过程定义（OPD）过程域负责制定和维护机构标准过程集 OSSP。项目组要做的工作首先是从 OSSP 中找出相关的过程描述，例如，需求实施计划、需求评审规程、需求评审检查单、变更控制规程、同行评审规程、基线定义、软件需求规格说明书模板、需求跟踪矩阵模板，等等。然后，对上述文档进行必要和允许的修改（有时就是照抄），文档所涉及的相关内容具体化，形成项目定义的需求管理过程。当机构刚开始实施 2 级的过程改进时，上列文档只好从头写起了。但注意，即便是实施 2 级时，也不是每个

33、项目都各写一套，也还是几个项目共用相同的文档，只是没有 3 级时那样的全面、完备。从这一点看，2 级与 3 级并不能绝对分开，只是成熟程度不同而已。?GP3.2，将上述项目定义的过程描述和过程执行的结果及其相关的度量信息、经验加以整理汇集，纳入机构过程资产，以便其他项目参考，或者用于改进机构标准过程集和机构过程资产。通过评审，取得对需求的共同理解，评审时应侧重哪些问题。一般来说，需求或需求规格说明书通过评审，最后应满足如下标准：?叙述清楚和准确。?完整。?彼此一致。?唯一。?可实现。?可验证（可测试）。?可跟踪。为了从技术上（不单是文字上）达到上列标准，在评审过程中应特别侧重以下几个方面的问题

34、：?功能需求，功能需求，产品或项目最终应提供哪些功能，例如：?包含哪几个功能模块（或者子模块）？?每个模块的输入和输出是什么？?在每个模块中将输入转换为输出的逻辑流程或算法是否明确、确定？?有哪些应由系统维护的永久性数据？?有没有应遵循的行业标准？哪些标准？?模块间的接口清楚吗？确定吗？?产品应该提供的外部接口明确吗？?新产品或项目与其他遗留系统的关联或兼容性有什么要求？（各项功能需求最好还有一个重要性优先级排序。）?性能需求，性能需求，功能需求对系统应该做什么提供了定性的描述。性能需求则 规定了产品或项目应要满足的性能，例如：第 12 页 共 115 页?数据存储需求，?系统预期的最大用户数

35、目，?从事务的角度看，系统预期的峰值负载，?系统必须满足的吞吐量，?事务预计平均响应时间，?上述各项数值未来的增长率估计。?可用性需求，可用性需求，可用性需求是对项目或产品正常运行时间的期望，例如：?在系统内部要建立的冗余数目（包括硬件和软件），?数据库底层软件的成熟度估计，?定期备份等操作性问题，以及这些操作在速度上的相应要求。?安全性需求，安全性需求，可能是产品或项目的隐含需求，必须在需求阶段早期确定，例如：?谁是系统的授权用户？?他们如何被验证？?每个用户对各种组件（像模块，输入，输出等）有什么存取权力？?谁被授权管理这些安全权力？?还有哪些特殊的安全性要求？?环境定义，环境定义，说明系

36、统将要运行于其上的软件和硬件平台方面的限制。因为软/硬件平台的选择对设计和后续开发有很大的影响，也影响系统最终的性能，还（从某种程度上）决定了需要的技能，所以事先明确定义是必要的。?约束条件，约束条件，包括技术性的约束条件和非技术性约束条件，有一些非技术性约束条件可以谈判和妥协，而有一些则因为商业需要而必须绝对地满足。在需求阶段应该明确什么事是可以妥协的，什么是不能妥协的。例如：?在发布或交付日期上有没有死的期限？?可以花在项目上的钱数有没有最高限度？?在项目中可以安排的人员数量有没有限制？?有哪些其他技术性约束条件。?验收准则：验收准则：合同项目的验收准则一般由甲方提出，但应经项目组认可；新

37、产品的验收准则由机构内部规定，项目组执行。验收准则，包括：?在现场测试还是在仿真环境下测试？?测试时硬件、软件配置有什么规定？?测试覆盖范围、测试用例有什么特别规定？?用户试用有什么特别需求？?其他需求，包括：其他需求，包括：?文档，文档，应提交哪些文档，例如：用户手册、设计和内部文档、安装指南、在线帮助等。?培训，培训，一旦产品开发完成，可能需要培训用户，需要什么程度的培训，决定了第 13 页 共 115 页 要付出的工作量。包括：操作员培训、系统管理员培训，另外，如果产品的后续维护移交给客户，可能必须培训客户的开发人员了解程序以及如何维护该程序。?其他提交物（如代码、技术文档）有什么特别规

38、定？?后续支持需求，后续支持需求，项目一旦提交或发布，将会需要后续的支持，例如：?需求变更如何提交以及如何处理？?代码改正完成时间有什么约定？?产品维护多久？?哪些事项一经验收就不能变更？管理需求，应写多少文档，哪些文档 如果是从 ML2 级开始，什么积累也没有，则应编写如下文档：?需求管理机构方针，?需求管理实施计划（可包含机构方针），?需求评审规程或同行评审规程（ML3，验证过程域），?变更控制规程（ML2，配置管理过程域），?项目监督规程（ML2，项目监督和控制过程域），?需求评审检查单，?软件需求或/和软件需求规格说明书模板，?评审表模板，?配置项变更控制表模板（ML2，配置管理过程域

39、），?需求跟踪矩阵模板。管理需求，应生成多少工作产品，哪些工作产品 在项目开始（需求分析）阶段，应生成如下工作产品：?通过评审和确认的软件需求或/和?通过同行评审和审批的软件需求规格说明书，?评审表及相关评审记录，?必要时，项目干系人（特别是用户，其次是同一个集成项目的不同组之间）对关键事项的承诺。在项目执行期间，形成的记录文档，包括：?配置项变更控制表，?各类跟踪、监控报告或检查、审核记录（包括各类度量结果）。第 14 页 共 115 页 4.3 需求管理实施计划需求管理实施计划 前面已经提到过多次，每个项目组都应对涉及的每一个过程域进行策划，策划的结果是文档化的过程实施计划。策划的具体活动

40、正好就是共性目标 GG2 的10 项共性实践以及（如果是 ML3 级）共性目标 GG3 的 2 项共性实践，这些实践的结果就构成了实施计划的内容要点。从 CMMI 的实际实施情况看，这里有一个比较普遍的问题，许多机构都不重视实施计划的文档化，结果是评估通过之后，随着第一批过程改进活动参与者的离开或新员工的加入或执行力度的减弱，第 15 页 共 115 页 过程改进活动也就留于形式，半年一载的改进活动等于走了一个过场，与日常社会生活中常见的各式各样的达标活动（运动）一样，层层发动、劳命伤财，运动一过、老方一贴。究其原因，可能有这么几种情况：?机构高层管理者支持或主张采用 CMMI 模型改进过程管

41、理，本来就只想要一张评估证明，用于商业活动的某种需要。?机构高层管理者真正认识到改进过程管理的重要性、不断提高机构能力成熟度的重要性，但是由于培训咨询人员本身对 CMMI 模型的有效实施缺少亲身实践（只是看了一些书），或者由于机构内部第一批参与过程改进的人员认识上有误区或者怕工作量太大而忽略了一些应该做的工作。对于第二种情况，再多说几句。过程实施计划，就其文字内容而言，基本上就是将 CMMI 模型描述的标准文本的相关条款重新叙述了一遍，表面上看，是抄了一遍标准文本的相关内容，但实际上并非如此。理由如下：?编制者应对标准文本有一个尽可能准确的理解；?结合机构、项目组的实际特点，应对标准文本的相关

42、条款细化、具体化，并且可能还要删去一些不符合实际的内容，增加一些机构所必需的内容；?通过以上二点写成了文档，用于实施，此时，每个项目组不必从头开始、从学习标准文本开始，而是从机构已有的文档开始，再作一次细化、具体化以至修改，特别是文档编制者或第一批参与者离开了，文档还在，制度还在，新员工、新加入者来了就从已有文档开始培训就行了，而不是再请培训机构再培训标准。?还有一个重要的问题，人们往往疏忽了。请注意，CMMI 是模型，不是标准。标准，是达到还是未达到的问题，例如，ISO9001 是标准，采用者编制文档旨在规定做些什么、如何做以达到标准的要求，此时在文档中重述标准（名词）的标准（定语）文本是无

43、济于事的。但模型就不一样了，它是为了达到某些目标而应执行的一套做法的描述，前面多次提到的模型标准，严格讲应该是“模型描述的标准文字”，即用一套标准文字描述了这个模型。模型不只给出了一些通用规则，还给出了在不同成熟度等级下应达到的目标以及为达到这些目标希望执行的实践及其工作产品，使得不同的模型采用机构不会因为对标准描述的不同理解而造成执行过程和结果的差异过大而失去可比性。同时，不同机构应根据自身的不同特点，针对标准的描述逐项进行细化、具体化以及必要的增删。特别是过程实施计划，作为该过程实施的纲领性规范，更应该突出二个要点：相对于模型标准文本的符合性；对机构和项目特点的适合性。下面给出需求管理实施

44、计划的参考文本，读者可以在此基础上参照标准文本加以修改，形成你所在机构或项目关于需求管理过程域的实施计划。需求管理实施计划需求管理实施计划 第 16 页 共 115 页 【过程概述】【过程概述】需求管理的范围，包括：?在生命周期全过程中，控制和管理需求变更；?跟踪需求，识别项目计划及工作产品与需求的不一致项，并跟踪针对不一致项而采取的纠正措施。?在项目开始阶段（立项阶段和需求分析阶段），通过正式评审，项目相关各方应对软件需求和/或软件需求规格说明书取得共同的理解并对重要事项作为必要的承诺。【过程目标】【过程目标】1.需求文档经过评审和确认，项目相关各方取得对需求的共同理解并对重要事项作出承诺。

45、2.需求和/或需求规格说明书，经同行评审并审批后，纳入配置管理，作为项目计划以及后续的项目工程和管理活动的基础。3.软件需求和/或软件需求规格说明书的任何变更，得到控制和管理。4跟踪、识别项目计划及工作产品与需求的不一致项及其纠正措施。【机构方针】【机构方针】1.项目需求应形成文档。2.需求文档应取得项目相关各方的共同理解并作必要的承诺。3.需求规格说明书，应通过同行评审并审批。4.需求或需求规格说明书的任何变更，应得到控制和管理；项目开发计划、软件工作产品和软件过程活动必须与需求的变更保持一致。GP2.1(CO1)【执行能力】【执行能力】1.项目组应对需求管理过程进行策划，（参照本计划，进一

46、步细化和具体化，）制定和维护需求管理实施计划。GP2.2(AB1)2.项目组应确定需求管理所需的设备、工具、人力资源和费用，并由项目组所属部门经理负责确保及时到位。此处，有二点要特别注意：软件需求评审（以及需求规格说明书同行评审）应尽可能有行业专家参加，或者用合适方式征求行业专家或用户的意见；同时，项目组成员能共享公司范围内行业知识和产品技术的积累。软件工具（需求管理的软件工具以及整个项目工程和管理活动所用的各类软件工具）的采用和变更，应纳入项目配置管理范围定期审核，未经审批准用的任何工具软件及其版本一律不得出现在项目组共用和个人专用的开发设备中。GP2.3(AB2)3.合同项目如果是系统集成

47、项目，则其中软件开发任务的划分和分配，应由技术总监和部门经理负责，并与委托方或合作方负责人协商确定。如果新产品第 17 页 共 115 页 开发项目是大型项目，需要多个项目组分工协调完成，则任务划分和分配也应由技术总监和部门经理负责，必要时还要由技术总监负责部门间或组间的协调。项目组内部的需求管理分工则由项目组长负责，落实到人，并确保被分配者接受分工、理解分工任务。GP2.4(AB3)4.项目组应采取适当方式对执行和支持需求管理的人员进行必要的培训，或确认已受过比要的培训，使相关人员具备需求管理所必需的知识和技能。培训内容包括行业应用知识、需求管理机构方针、需求管理实施计划、需求评审规程、变更

48、控制规程、配置管理规程以及沟通技巧等。详见机构培训过程域的相关规定。GP2.5(AB4)【指导实施】【指导实施】1需求和需求规格说明书应纳入项目需求基线，得到管理和控制；需求管理实施计划以及各类评审、跟踪、监督和度量记录等其他工作产品作为一般配置项应放在项目组根目录的指定子目录下，纳入配置管理。详见配置管理过程域的相关规定。GP2.6(DI1)2.识别项目相关各方的负责人和一般干系人（特别是合同甲方代表和相关组负责人），明确他们应介入的活动、介入方式和问题响应的时间约定。介入活动包括：策划、决策、沟通、协调、评审、评价、需求定义以及争议问题的解决等。GP2.7(DI2)3.项目组长负责，或指定

49、专人负责，跟踪、监督和控制需求管理过程，收集及分析与需求管理相关的度量信息（如需求变更的比率、频率等），保持项目组对需求管理过程的可视性；必要时建议可能采取的纠正措施，包括修复缺陷、返工、修改实施计划、整调资源、修改过程目标、改变承诺、以至终止项目等。详见项目监督与控制、测量与分析二个过程域的相关规定。GP2.8(DI3)【特定实践】【特定实践】1.项目组长负责，按“软件需求评审规程”的规定，主持软件需求和/或需求规格说明书评审。通过评审取得项目相关各方对需求和/或需求规格说明的共同理解SP1.1-1，同时，相关各方经过协商对重要事项作出承诺SP1.2-2。经评审、修改、完稿的软件需求文档应由

50、项目组长签字确认，报部门经理审核批准，必要时还应由用户代表再次签字确认。项目组长负责或指定专人负责，依据经过评审确认和批准的软件需求，编写软件需求规格说明书（SRSSoftware Requirement Specification）。SRS 应准确描述软件产品必须提供的所有功能、性能以及其他应满足的约束条件，它不仅是集成测试、系统测试和验收测试以及编写用户文档第 18 页 共 115 页 的基础，也是项目策划、设计和编码的基础；除了设计和实现时的约束之外，SRS 不包括设计、编码、测试和工程管理的细节。（详见“需求规格说明书模版”）软件需求规格说明书完成后，应按“软件需求评审规程”或同行评审