CMMI3级精简并行过程综述.doc

1、0第 2 章 CMMI 3 级精简并行过程综述 .12.1 SPP 模型 .12.2 SPP 过程域的目的 .42.3 SPP 与 CMMI 的关系 .52.4 SPP 文档结构与规范细分 .62.5 SPP 角色与职责表 .82.6 机构软件过程改进的政策 92.6.1 目标 92.6.2 机构领导的支持 92.6.3 质量管理的政策 102.6.4 软件工程过程小组的政策 102.6.5 质量保证小组的政策 112.6.7 项目团队的政策 112.7 SPP 裁剪与扩充的指导方针 .121第 2 章 CMMI 3 级精简并行过程综述“精简并行过程” （Simplified Parallel

2、 Process，SPP）是基于 CMMI 以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范” ，它由众多的过程规范和文档模板组成。SPP 主要用于指导国内 IT 企业持续地改进其软件过程能力。此处“精简并行”的含义是：（1）对 CMMI 3 级以内各过程域的内容和要求作了“精简”处理。（2）在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。本章是 SPP 的综述文章，它对 SPP 的思想方法以及企业的软件过程改进政策作了全面介绍。阅读本章有助于读者更好地理解和应用 SPP 的所有过程规范和文档模板。建议用户（企业）根据自身情况（如发展战略、研发实力等）适

3、当地修改 SPP，然后推广使用。2.1 SPP 模型SPP 模型把产品生命周期划分为 6 个阶段，分别为： 产品概念阶段，记为 PH0。 产品定义阶段，记为 PH1。 产品开发阶段，记为 PH2。 产品测试阶段，记为 PH3。 用户验收阶段，记为 PH4。 产品维护阶段，记为 PH5。在 SPP 模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。上述三类过程可以细分为 19 个主要过程域，分布在 PH0 到 PH5 的各个阶段。项目管理过程包含 6 个过程域，分别为： 立项管理 结项管理 项目规划 项目监控 风险管理 需求管理项目研发过程包含 8 个过程域，分别为： 需

4、求开发 技术预研 系统设计 实现与测试2 系统测试 Beta 测试 客户验收 技术评审机构支撑过程包含 5 个过程域，分别为： 配置管理 质量保证 培训管理 外包与采购管理 服务与维护SPP 模型如图 2-1 所示。SPP 模型的主要特征和优点有：一、直观的过程模型SPP 模型将项目管理、项目研发、机构支撑所包含的工作划分为相对独立的三类过程，各个过程域之间的关系直观明了。这样，机构领导、项目经理、开发人员、测试人员、质量保证人员、外包与采购管理人员等人根据 SPP 模型，很容易知道自己 “应该在什么时候、按照什么规范做什么事情” 。所以 SPP 模型有助于使机构内的各个职能单位有条不紊地开展

5、工作。二、容易裁剪与扩充SPP 模型的三类过程贯穿了产品的整个生命周期，19 个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特征，适当地裁剪或扩充 SPP 的过程域，很容易制定出最适合于本产品的过程模型。0图 2-1 SPP 模型PH0 产品概念 PH1 产品定义 PH2 产品开发 PH3 产品测试 PH4 客户验收 PH5 产品维护立项管理 项目规划 项目监控 风险管理 需求管理 结项管理需求开发配置管理 质量保证 外包与采购管理 培训管理项目管理过程项目研发过程机构支撑过程服务与维护技术评审技术预研并行、迭代根据产品特征确定最合适的开发模型，以线性顺序为主，

6、以并行、迭代为辅。系统设计实现与测试系统测试Beta 测试客户验收其它： 人力资源管理 财务管理 行政管理 市场营销 42.2 SPP 过程域的目的SPP 所有 19 个过程域的目的如表 2-1 所示。项目管理过程域 目的立项管理采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建议被采纳，避免浪费机构的资源、资金、时间等。结项管理在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。项目规划为项目的研发和管理工作制定合理的行动纲领（即项目计划） ，以便所有相关人员按照该计划有条不紊地开展工作。项目监控周期

7、性地跟踪项目计划的各种参数如进度、工作量、费用、资源等，不断地了解项目的进展情况，以便当项目实际进展显著偏离计划时能够及时采取纠正措施。风险管理 在风险产生危害之前识别它们，从而有计划地消除或削弱风险。需求管理在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。项目研发过程域 目的需求开发 通过调查与分析，获取用户需求并定义产品需求。技术预研在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。系统设计设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导

8、开发人员去实现能满足用户需求的软件产品。实现与测试依据系统设计文档，编写并测试整个系统的代码。在 SPP 中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。系统测试 对最终系统进行全面的测试，确保最终系统满足产品需求并且遵循系统设计。Beta 测试在产品正式销售之前，开发方将产品交付给一些潜在的客户免费试用，请他们对产品进行测试，并获取他们对产品的建议。客户验收 客户依据合同对产品进行审查和测试，确保产品满足客户需求。技术评审尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。机构支撑过程域 目的配置管理通过执行版本控制、变更控制等

9、规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。质量保证提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量” ，从而实现持续地改进质量。外包与采购管理 选择合适的承包商（外包）和供应商（采购） ，并依据合同进行有效的管理。培训管理根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。5服务与维护是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发方的满意度。表 2-1 SPP 过程域的目的2.3 SPP 与 CMMI 的关系CMMI 是 SPP 的主要参考标准，但是

10、SPP 并不是对 CMMI 进行简化处理后的结果。两者都是用于指导软件过程改进的方法论，CMMI 主要论述“应当做什么才能使软件过程能力达到 CMMI 某种级别” ，而 SPP 则论述“应当怎样做才能使软件过程能力达到 CMMI 3 级水平” 。SPP 过程域和 CMMI 3 级过程域的对应关系如表 2-2 所示。SPP 的 19 个过程域 CMMI 3 级以内的 18 个过程域立项管理结项管理CMMI 3 级，Decision Analysis and Resolution项目规划 CMMI 2 级，Project Planning项目监控CMMI 2 级，Project Monitorin

11、g and ControlCMMI 2 级，Measurement and Analysis风险管理 CMMI 3 级，Risk Management项目管理过程需求管理 CMMI 2 级，Requirements Management需求开发 CMMI 3级， Requirements Development技术预研系统设计实现与测试CMMI 3级， Technical SolutionCMMI 3级， Product Integration项目研发过程 系统测试Beta 测试用户验收技术评审CMMI 3级， VerificationCMMI 3级， Validation配置管理 CMMI

12、2 级，Configuration Management质量保证 CMMI 2 级，Process and Product Quality Assurance外包与采购管理 CMMI 2 级，Supplier Agreement Management培训管理 CMMI 3 级，Organizational Training机构支撑过程服务与维护SPP 其它成果： SPP 综述文章 SPP 培训教材 基于 Web 的项目管理工具CMM 3 级，Organization Process FocusCMM 3 级，Organization Process DefinitionCMM 3 级，Inte

13、grated Project Management表 2-2 SPP 过程域和 CMMI 3 级过程域的对应关系62.4 SPP 文档结构与规范细分SPP 的文档结构如图 2-2 所示，SPP 包含 19 个过程域、40 余个规程、近 60 个文档模板。SPP 的规范细分如表 2-3 所示。图 2-2 SPP 文档结构项目管理过程域 主要规程 文档模板立项管理SPP-PROC-PIM立项建议立项评审项目筹备立项建议书立项调查报告书立项可行性分析报告立项评审报告结项管理SPP-PROC-PCM结项管理结项申请书结项评审报告项目规划SPP-PROC-PP项目估计制定项目计划审批项目计划项目计划变更

14、控制项目估计表项目计划项目计划变更控制报告项目监控SPP-PROC-PMC项目计划跟踪偏差控制项目进展总结项目监控数据表项目偏差控制报告项目进展报告风险管理SPP-PROC-PM风险管理风险检查表风险管理报告需求管理SPP-PROC-RM需求确认需求跟踪需求变更控制需求跟踪报告需求变更控制报告项目研发过程域 主要规程 文档模板需求开发SPP-PROC-RD需求调查需求分析需求定义用户需求说明书产品需求规格说明书技术预研SPP-PROC-TPR技术预研技术预研计划技术预研报告过程改进政策过程域规程文档模板SPI PoliciesProcesses AreasProceduresTemplates

15、7系统设计SPP-PROC-SD体系结构设计用户界面设计数据库设计模块设计体系结构设计报告用户界面设计报告数据库设计报告模块设计报告实现与测试SPP-PROC-IT实现与测试 实现与测试计划编程文档系统测试SPP-PROC-ST系统测试系统测试计划测试用例测试报告Beta 测试SPP-PROC-BETABeta 测试 Beta 测试协议Beta 测试报告客户验收SPP-PROC-CA客户验收客户验收计划客户验收报告技术评审SPP-PROC-TR正式技术评审非正式技术评审技术评审计划技术评审报告技术评审检查表机构支撑过程域 规程与关键活动 文档模板质量保证SPP-PROC-QA制定质量保证计划过

16、程与产品质量检查问题跟踪与质量改进质量保证计划质量保证检查表质量保证报告质量问题跟踪表配置管理SPP-PROC-CM制定配置管理计划配置库管理版本控制变更控制配置管理计划配置库管理报告配置项变更控制报告外包管理外包开发竞标邀请书承包商评估报告外包开发合同外包开发过程监控报告外包开发成果验收报告外包与采购管理SPP-PROC-OPM采购管理采购竞标邀请书供应商评估报告采购合同采购物品验收报告培训管理SPP-PROC-TM机构培训管理项目培训管理培训计划培训评估报告服务与维护SPP-PROC-SM客户服务客户服务计划客户服务报告8产品维护产品维护计划产品维护报告表 2-3 SPP 规范细分2.5

17、SPP 角色与职责表SPP 的主要角色及其职责如表 2-4 所示（详见各个过程域对角色与职责的描述） 。企业在应用 SPP 时，可以将 SPP 的各个角色映射到企业原有的岗位上，也可以依据 SPP 角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。常设角色 职责简述软件工程过程组（SEPG）（1）制定适合于本机构的过程规范。（2）在机构范围内推广该规范（如培训、考核） ，评估机构过程能力等。机构过程改进角色质量保证小组（QAG）（1）监督规范的实施，确保所有项目以及相关部门准照规范开展工作。（2）分析并解决机构内存在的共性质量问题，协组 SEPG 完善规范。机构领导（1）是机构内所有

18、项目的主管，对立项管理和结项管理有最终决策权。（2）监督项目经理的工作，审批项目经理的各种申请。项目管理过程角色项目经理（1）向机构领导汇报工作。（2）是项目规划、项目监控、风险管理和需求管理过程域的负责人。（3）监督项目成员的工作，审批项目成员的各种申请。需求分析员调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。系统设计师根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等，并撰写相应的设计文档。程序员（1）根据系统设计文档，编写软件系统的代码。（2）随时测试和检查自己的代码，及时消除代码中的缺陷。项目研发过程角色测试员从事单元测试、集

19、成测试和系统测试，主要工作包括制定测试计划、设计测试用例、执行测试和撰写测试报告。配置管理员（1）为项目制定配置管理计划 。（2）创建并维护配置库，如分配权限、清除垃圾文件、备份配置库等。质量保证员（即 QAG 成员）（1）为项目制定质量保证计划 。（2）周期性的开展“过程与产品质量检查” 。（3）跟踪质量问题，给出质量改进措施。外包管理员（1）挑选最合适的承包商，签订外包开发合同。（2）监控外包开发过程，验收外包开发成果。采购管理员（1）挑选最合适的供应商，签订采购合同。（2）验收采购物品。机构支撑过程角色培训管理员制定机构（或项目）的培训计划 ，监督该计划的实施，撰写培训评估报告 。9客户

20、服务人员为客户提供与产品相关的服务（如技术咨询） ，快速响应客户的要求，给客户一个满意的解答。产品维护人员（1）纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺陷。（2）完善性维护：在资源允许的情况下，不断改善产品功能与质量。临时角色 职责说明立项建议小组（1）开展立项调查、产品构思和可行性分析，撰写相应文档。（2）申请立项，并在立项评审会议上答辩。立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。结项评审委员会对项目的有形资产和无形资产进行清算，对项目进行综合评估，总结经验教训等。结项委员会的人员组成与立项评审委员会的

21、类似。技术评审委员会对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。该委员会由项目内外的技术专家组成。配置控制委员会 对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等） 。表 2-4 SPP 的角色与职责简表2.6 机构软件过程改进的政策2.6.1 目标 持续改进机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开发成本。 在一年之内，初步建立适合于本机构的软件过程规范，并使机构内的所有项目和相关部门执行该规范。本年度机构内部对过程能力的评估成绩达到：合格率为 100，良好率为 50以上，优秀率为 25以上。 在两年之内，完善适合于本机构的

22、软件过程规范，并使机构内的所有项目和相关部门执行改进后的规范。第二年度机构内部对过程能力的评估成绩达到：合格率为 100，良好率为 75以上，优秀率为 50以上。或者通过 CMMI 3 级评估。补充说明：评估成绩在 100 85 之间为 “优秀 ”， 85 70 之间为 “良好 ”， 70 60 之间为 “合格 ”，分数低于 60 为 “不合格 ”。2.6.2 机构领导的支持 机构领导批准用于软件过程改进的必要经费，例如支付咨询费，购买相关软件工具等。 机构领导组建 SEPG 和 QAG，专门从事软件过程改进工作。SEPG 的主要职责是建立适合于机构的过程规范，QAG 的主要职责是监督该规范的

23、实施。建议让 SEPG 和 QAG 的大部分人员重叠，这些人既是 SEPG 成员又是质量保证员，扮演两种角色。这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过） 。一般地，SEPG 成员和质量保证员共占机构总人数的 5%左右。10 机构领导不仅要口头支持，还要亲自参与软件过程改进的实践。例如参加培训和考试，准照过程规范执行立项管理和结项管理等。2.6.3 质量管理的政策质量管理口号：“在开发过程之中内建质量而非修补质量” 。质量管理有种基本措施：“质量保证” 、 “技术评审”和“测试” 。一、 质量保证机构的质量保证员周期性地检查项目成员的“工作过程以及工作成

24、果”是否符合既定的规范，来监控和改进“过程质量以及产品质量” 。机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。二、技术评审在工作成果刚产生之际，对其进行技术评审（分正式或非正式两种） ，目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。技术评审活动由项目开发团队组织。三、测试测试是指通过运行测试用例（test case）来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统

25、测试和验收测试（或 Beta 测试） 。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。验收测试（或 Beta 测试）由客户组织。如果有条件的话，建议机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。2.6.4 软件工程过程小组的政策机构领导任命一位熟悉软件工程、项目管理、CMM/CMMI 并且有丰富工作经验的人担任 SEPG 的负责人。在机构领导的许可下，该负责人组建 SEPG（成员可以是全职的也可以是兼职的） 。 第一年度的任务与目标 SEPG 约用 23 个月的时间，了解机构过程能力的现状，通过裁剪或扩充 SPP，初步建

26、立适合于本机构的过程规范。 SEPG 约用 12 个月的时间，对机构全员进行培训和考试，确保全员了解本规范，并懂得如何应用。 之后 SEPG 协助 QAG 监督本规范在所有项目和相关部门的实施，并不断收集员工们反映的过程改进问题和建议，逐步改进过程规范（允许有小幅度的升级） 。 本年度最后一个月，SEPG 对机构的过程能力进行评估，并向领导和员工们通报“本年度过程改进工作报告” 。11 在 SEPG、 QAG 和全体项目人员的共同努力下，争取使本年度过程能力的评估成绩达到：合格率为 100，良好率为 50以上，优秀率为 25以上。 第二年度的任务与目标 根据上年度的过程能力评估状况，以及员工们

27、反映的问题和建议，SEPG 查找机构过程能力的薄弱环节，研究出解决措施。SEPG 用 12 个月的时间，建立比较完备的过程规范新版本（允许有大幅度的升级） 。 如果机构资金充足的话，可以邀请CMMI 评估师作正式评估前的指导。 SEPG 约用 12 个月的时间，就规范的更新内容对机构全员进行培训和考试，确保全员了解新版本规范，并懂得如何应用。 之后 SEPG 协助 QAG 监督本规范在所有项目和相关部门的实施，并不断地完善过程规范。 本年度最后一个月，SEPG 对机构的过程能力进行评估，并向领导和员工们通报“本年度过程改进工作报告” 。 如果机构资金充足的话，可以邀请 CMMI 评估师对机构过

28、程能力进行正式评估。 在 SEPG、 QAG 和全体项目人员的共同努力下，争取使本年度过程能力的评估成绩达到：合格率为 100，良好率为 75以上，优秀率为 50以上。 或者通过 CMMI 3 级评估。2.6.5 质量保证小组的政策机构领导任命一位熟悉过程规范并且有丰富的质量管理经验的人担任 QAG 的负责人（或称为质量经理） 。在机构领导的许可下，该负责人组建 QAG（成员可以是全职的也可以是兼职的） 。QAG 在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量” 。QAG 准照 SEPG 制定的“质量保证规范 ”开展工作。机构领导赋予 QAG 一定的权利

29、，可以对质量不合格的工作成果做出处理。这种权利使得 QAG 的工作不会被轻视，并有助于加强全员的质量意识。对于 QAG 与项目之间出现的难以调和的争议，由机构领导处理。2.6.7 项目团队的政策项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规范，每个人都必须明白自己“应当在什么时候依据什么规范做什么事情” 。项目经理应当树立榜样，并且督促项目成员们按规范做事。允许项目经理根据本项目的特征，在 SEPG 和 QAG 的指导下，适当地裁剪或扩充机构的过程规范，从而快速建立本项目的过程规范。这项工作应当在“项目规划过程域”中完成，并在项目计划中体现出来。如果项目对机构过程规

30、范的裁剪幅度比较大，遭到 QAG 的反对，如果双方不能达成共识，则由机构领导处理该争议。12SEPG 对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占 30以上的比重。2.7 SPP 裁剪与扩充的指导方针 不要迷信或者死搬硬套他人推崇的过程标准和规范（例如 CMM/CMMI, ISO, RUP,SPP 等等） 。SEPG 一定要根据机构的实际情况（如发展战略、研发实力等）来制定机构过程规范，要充分考虑过程改进的成本和效益。能够以比较低的代价有效地改进机构过程能力的规范才是好规范。 SEPG 要有计划地、逐步地完善机构的过程规范，切忌盲目追求“大而全”

31、 ，否则“欲速则不达” 。软件过程改进不是一次性买卖，不能靠“革命”，只能靠持续地改良，不进则退。 SEPG 应当具备一定的软件工程和项目管理知识，再通读 CMMI 和 SPP（或接受培训） ，才能结合机构实际情况裁剪或扩充 SPP，形成机构自己的过程规范。 SPP 对其 19 个过程域的论述已经比较充分，一般而言， SEPG 裁剪或扩充这 19 个过程域不会遇到太大的困难。如果机构的业务包括硬件开发，那么 SEPG 应当制定硬件开发过程规范（参考 SPP 的格式） ，并努力使软件、硬件开发过程保持一致性。 显然，SPP 并没有覆盖机构的全部职能，它仅仅局限于软件项目的研发与管理领域。SEPG 应当协助有关人员制定人力资源管理、财务管理、行政管理、市场管理、生产制造等领域的过程规范。上述每个领域的过程改进工作都是非常重要的。 SEPG 要认真撰写规范，力求使规范中的文字和图表没有歧义，并且简单易懂。