软件能力成熟度模型 SW-CMM 马 梅 2002.4.29

1. 软件能力成熟度模型 SW-CMM 马 梅 2002.4.29

5. 内 容 • SW-CMM是什么？ • SW-CMM的由来和发展 • SW-CMM的管理思想与结构 • SW-CMM评估的国内外现状 • ISO 9001与SW-CMM异同 • 软件业对SW-CMM的认识 • SW-CMM市场存在的问题 • 我们怎么办？

6. 什么是SW-CMM？ • SW-CMM称为软件能力成熟度模型，是Capability Maturity Model for Software的缩写形式。 • 目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。用于评价软件承包能力并帮助其改善软件质量的方法。 • 美国卡内基-梅隆大学的软件工程研究所(SEI：Software Engineering Institute) 在1987年研制成功。 • 卡内基-梅隆大学的软件工程研究所是美国国防部的软件开发基地之一，CMM就是受美国国防部委托而研制的。

7. SW-CMM是什么？（续一） • SEI给CMM下的定义： 对于软件组织在定义、实现、度量、控制和改善其软件过程的各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。 • 如今的行情是：一家软件企业如果不能通过相应等级的CMM评估，他的产品就少了一张进入国际市场的通行证。

8. SW-CMM的由来与发展 The Capability Maturity Model for Software, Version 1.1(Mr. Marc C. Paulk): The major problems in software development are managerial – not technical.

9. SW-CMM的由来与发展（续一） • 20世纪60年代中期，大型软件系统生产中爆发的软件危机，使程序中大量的错误难以消除，软件生产的进度无法预测，开发应用费用失去控制，程序员人数增长需求很难满足要求。 • 人们将工程的概念、原理、技术和方法引入了软件系统开发，在一定程度上解决了软件生产过程中遇到的问题。软件工程成为软件产业的重要分支。 • 直至80年代还是没有提出一套管理软件开发的通用原则，软件管理不善的问题依旧在大范围内存在。

10. SW-CMM的由来与发展（续二） • 70年代中期美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够。 • 90年代中期，软件工程管理不善的问题仍然存在。据美国软件工程实施现状的调查，大约只有10%的项目能够在预定的费用和进度下交付。 • 1995年，美国共取消了810亿美元的软件项目，其中31%的项目未做完就取消了，53%的软件项目进度通常要延长50%的时间，通常只有9%的软件项目能够及时交付并且费用也不超支。 • 结论：管理是影响软件研发项目全局的因素，而技术只影响局部。

11. SW-CMM的由来与发展（续三） • 80年代中期，美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。在Mitre公司的帮助下，1987年9月，美国卡内基-梅隆大学软件工程研究所发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。 • 4年之后，SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM）。 • 1991年8月，SEI发布了最早的SW-CMM v1.0。 • 经过两年的试用，1993年SEI正式发布了SW-CMM v1.1，这是目前使用最为广泛的版本。

12. SW-CMM的由来与发展（续四） • 从1995年，CMM又进入了另一个修改的高峰期。 • 美国政府和软件业界大力支持和积极参与下，SEI先后发表了CMM 2.0版的A版，B版和C版草案；1997年，CMM 2.0C版草案停止推进。 • SEI宣布，CMM 1.1版和CMM 2.0C版草案都有效，并且SEI及其授权的机构为这两种版本提供相应的服务。 • 自CMM 1.1发布起，SEI相继研制并发布了“人员能力成熟度模型”（P-CMM），“软件访问能力成熟度模型”（SA-CMM）和“系统工程能力成熟度模型”（SE-CMM）及其支持文件。 • 经过试运行，产生了把SM-CMM, P-CMM, SA-CMM和SE-CMM合并在一起的想法，于是开始了名为“综合能力成熟度模型”（英文缩写为CMMI）的一个综合性模型投入研制。

13. SW-CMM的由来与发展（续五） • SEI的CMM为软件工程管理开辟了一条新的途经，其的本质还是软件工程的一个部分。 • 迄今为止，CMM虽然只是美国卡内基-梅隆大学软件工程研究所（SEI）发表的一份技术报告，既不是政府也不是行业协会批准的标准，但它在美国和国际上已成为事实上的软件行业标准。鉴于CMM的巨大应用前景，SEI已在美国注册了CMM, Capability Maturity Model 和Capability Maturity Modeling的专利和商标。 • 围绕以CMM为基础的软件过程评估和软件能力评价，建立了从审核员培训到提供评估和评价的一整套服务体系。

14. SW-CMM的管理思想与结构 • SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架。 • 它是基于过去所有软件工程成果的过程改善的框架，吸取了以往软件工程的经验教训。 • 指明了一个成熟的软件组织在软件开发方面需要管理的主要工作、这些工作之间的关系以及以怎样的先后次序，一步一步的做好这些工作使软件组织走向成熟。

15. SW-CMM分为 五个等级 • 初始级 • 可重复级 • 已定义级 • 已管理级 • 优化级

16. SW-CMM的管理思想与结构（续一） 1、初始级：混沌的过程 • 不具备稳定的环境用于软件开发和维护； • 缺乏健全的管理惯例，其软件过程能力无法预计； • 软件过程是一片混沌； • 软件过程总是随着软件开发工作的推进而处于变更和调整之中。 现实中有许多这样的软件组织，这种情况被CMM定义为初级（第1级）能力成熟度。

17. SW-CMM的管理思想与结构（续二） 2、可重复级：定义管理的基本过程 • 软件开发的首要问题不是技术问题而是管理问题。因此，可重复级的焦点集中在软件管理过程上。 • 一个可管理的过程则是一个可重复级的过程，一个可重级的过程则能逐渐进化和成熟。 • 该级管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。 • 项目管理分为计划过程和跟踪监控过程两个过程。 • 通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

18. SW-CMM的管理思想与结构（续三） 3、定义级：定义执行的步骤标准 • 制定企业范围的工程化标准； • 将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出该项目的过程，并执行这些过程。 • 对用于软件开发和维护的标准过程要以文件形式固定下来。针对各个基本过程建立起文件化的“标准软件过程” • 较普遍的看法是，只有当达到了第3级能力成熟度时，才表明这个软件组织的软件能力“成熟”了。 定义级是标准一致的软件过程。

19. SW-CMM的管理思想与结构（续四） 4、管理级：设定定量的质量目标 • 第四级的管理是量化的管理。 • 所有过程都需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量是详尽的，且可用于理解、控制软件过程和产品，这种量化控制将使软件开发真正变成为工业生产活动。 • 处于这一级的组织已经能够为软件产品和软件过程设定定量的质量目标，并且能对跨项目的重要软件过程活动的效率和质量予以度量。 管理级是可度量的、可预测的软件过程

20. SW-CMM的管理思想与结构（续五） 5、优化级：持续优化级 • 第五级的目标是达到一个持续改善的境界。 • 可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。 • 如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 优化级是能持续改善的软件过程

21. SW-CMM的管理思想与结构（续六） • 除第一级外，SW-CMM的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域(KPA)，每个KPA进一步包含若干关键实施活动(KP)，无论哪个KPA，它们的实施活动都统一按五个公共属性进行组织。 • 关键过程域KPA(Key Process Areas) 一组相关联的活动；通过执行这些活动可以实现既定的过程能力。 • 关键实施KP（Key Practices） 使关键过程域得以有效实现和制度化的最大的基础设施和活动。

22. SW-CMM的管理思想与结构（续七） • 各个关键实践按每个关键过程域的5个“公共特性”（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程 • 这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。这一点很重要，因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动。

23. SW-CMM的管理思想与结构（续八） 五个公共属性： 1、目标 每一个KPA都确定了一组目标，若这组目标在每一个项目都能实现，则 说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求，则表明达到了这个级别所要求的能力。 2、实施能力 实施能力一般包括资源保证、人员培训等内容。它是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的活动。 3、执行活动 　 执行过程描述了执行KPA所需求的必要角色和步骤，一般包括计划、执行的任务、任务执行的跟踪等。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。 4、度量分析 　 描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。 5、实施验证 验证执行活动是否与建立的过程一致。实施验证涉及到管理的评审和审计以及质量保证活动。

24. SW-CMM的管理思想与结构（续九）

25. SW-CMM的管理思想与结构（续十一） • 结论： • 初始级是混沌的过程； • 可重复级是经过训练的软件过程； • 定义级是标准一致的软件过程； • 管理级是可预测的软件过程； • 优化级是能持续改善的软件过程。 We can never reach perfection. The focus is on always doing better.

26. SW-CMM评估的国内外现状 • SEI评估报告 • 1996年~2000年，全球有1012个组织进行了CMM评估，其中64.8%为商业组织，26.7%为美国官方和军方合同商。 • 主要业务为软件开发和维护的组织有922个，有将近一半的组织规模是在100人以下。 • 这些数据表明，CMM认证已经引起软件企业的高度关注，并且这种认证同样适合中小企业。 • 通过CMM4-5级评估的状况 • 截止2001年10月底，全世界共有139个组织通过了CMM4和CMM5的评估。 • 73家组织：CMM4级评估 • 66家组织：CMM5级评估 • 这139家组织中，其中美国占59家，印度占72家，其他国家占8家。

27. SW-CMM评估的国内外现状（续一） • 日本情况 • 日本官方将采用CMM软件客观评价标准。官方已决定到2003年由日本政府机构购入的软件都要经受此模型的评价。 • 日本的经济产业省，将在美国卡内基－梅隆大学软件工程研究所的协助下，结合日本市场的特点，与美方共同开发日本版的软件评价模型。 • 今后日本官方各部门将以此为标准，从优秀的软件开发公司购入自己所需的各种软件，改变固定地从大型企业购买软件的局面。

28. SW-CMM评估的国内外现状（续二） • 国内CMM评估的状况 • 我国政府对CMM认证标准给予的足够的关注和支持，国务院发布的《鼓励软件产业和集成电路产业发展的若干政策》（也称18号文件）中第17条中表示，将对软件出口型企业CMM认证费用予以适当支持。鼓励企业实施CMM 。 • 珠海开发区规定了通过二级一次性奖励50万元的政策。 • 我国已有软件企业通过了CMM标准认证，如motorala（中国）过了CMM5、联想集团通过了CMM3、鼎新过了CMM2等等。 • 预计未来2、3年内，国内将出现软件业实施CMM的高潮。

29. 我国通过CMM的认证情况：

30. ISO 9001与CMM异同 • 与ISO标准系列相比，CMM更为软件产业所看好 原因是它专门针对软件工程控制而设置的，不仅进行软件企业工程能力的评估，更致力于软件开发过程的管理，强调“对软件开发过程进行持续改进”，引导软件开发过程走向成熟。 • 相同点 • CMM和ISO 9001标准系列都着眼于质量和过程管理，二者都为了解决同样的问题。 • 不同点 • CMM是动态的、开放的和持续改进的，强调没有最好只有更好，强调不断改进，强调人在软件开发方面的思想认识和主动性，适用于软件过程的改进。 • CMM模型只关注软件，它能解决“软件危机” 这个世界性的问题， • ISO 9001是静态的质量控制，只要达到几个关键指标就能完成质量控制，更适用于硬件制造生产线的质量控制。 • ISO 9001的适应范围更广，包括硬件、软件和服务。

31. 软件业对CMM的认识 • 并不是实施了CMM，软件项目的质量就能有所保障。CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。 • CMM已经是一套发展相当成熟的方法，但国内要想完全掌握并广泛付诸实践，对绝大多数软件企业来说，可能还需要3～5年的时间。 • 美国曾在1995年做过软件产业成熟程度的调查，发现在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，其特征是软件开发过程不能预测，风险度高；为可重复级的占15%，其特征是软件开发过程需小心谨慎方能避免失败；为定义级的所占比例小于10%，其特征是软件开发过程相当稳定，进展顺利且可以预测；为管理级的所占比例小于5%，其特征是软件过程预测准确、值得信赖；为优化级的所占比例小于1%，其特征是软件过程能持续改善。 • 实施CMM并非一朝一夕的事情。

32. CMM市场存在的问题 1、CMM工具市场薄弱 ，缺乏过程管理工具 北大青鸟：JBCM Rational ：Clearcase 2、我国CMM评估师太少 全世界获得CMM主任评估师（Leader Assessor）资格的有355人， 而我国仅有两人。 原因CMM的门槛很高，要成为CMM主任评估师的条件： 1）具有硕士学历 2）十年以上的软件开发经验 3）两年以上管理经验 4）去美国卡内基·梅隆大学学习，并经过多种考核 我们缺乏自己的CMM主任评估师大大制约我国软件事业的发展。请外国评估师做一次CMM评估，花费大约是七八十万元，而且语言问题还会在一定程度上影响到评估。这势必大大阻碍我国软件企业在这方面的发展。

33. CMM市场存在的问题（一） 3、存在“牌子”误区 • CMM是梯子、是镜子，不是牌子！CMM不应该成为软件企业的应试教育。CMM应该是通过改善内部管理为企业带来利益的东西，不能带来利益的CMM，也就不能长久存在。 • CMM只是一个衡量体系，检验企业的软件工程做得怎么样，并不指导企业怎么做。企业只有有效地实施了软件工程，才能去实施CMM。

34. CMM市场存在的问题（二） 4、评定牵涉大量人力，财力和时间 实施CMM评定将牵涉大量人力，财力和时间。例如，美国的CMM评审机构为进行一次评估（或评价）开出的价码是7~10万美金。从接受评估申请到完成评估跨时2到3个月；如果涉及过程改进，将可能需时18~24个月。为了适应中，小组织的需要，要对CMM进行裁剪和压缩。

35. 我们怎么办？ • 由于实施CMM的基础是有效地实施了软件工程，所以BEPCII 实时数据信息管理系统以实施软件工程为本，执行过程中借鉴CMM的管理方式。 • 软件按其生命周期分为三个阶段：软件定义期、软件开发期和软件运行维护期。 • 软件定义期包括软件项目的系统定义、可行性研究和详尽的需求定义三个工作阶段。这一时期要为被开发的软件项目解决“做什么”。 • 软件开发期包括软件设计、编码、调试、测试和验收。 这一时期着重解决开发软件“怎么做”的问题。 • 软件运行维护期着重于因多种原因造成的对软件要作的修改。

36. 我们怎么办？（续一） • 系统定义 明确所开发软件的总体要求和适用范围，描述所开发软件与外界的接口关系，确定所需的硬、软件支持。 对开发的进度和成本作初步估计，确定所开发软件的性能与其内部复杂性之间的折中关系和所开发软件与原有软件系统的兼容性关系。 在确定以上任务时，设想多种可能方案，并从中进行比较选择。

37. 我们怎么办？（续二） • 可行性研究 任务是对系统的可行性进行研究。它包括技术可行性、经济可行性和法律可行性等方面。 技术可行性应弄清现有的技术条件能否完成开发工作，参加人员是否胜任开发技术的要求，硬件环境配置能否满足开发的需要，用户提出的开发周期和技术要求是否合理等。 经济可行性研究的目的是希望以最小的开发成本获得最佳经济效益的软件产品，因此需要作投资估算，如对人工费用、硬软件支持或其他费用进行估算，对软件投入使用后可能带来的经济效益进行估算。 法律可行性研究所开发的软件项目是否涉及到专利权、版权等法律问题。

38. 我们怎么办？（续三） • 需求分析 软件定义期的关键步骤，主要是理解和表达软件系统的用户需求。它包括所开发软件的功能、性能、可靠性、安全性、成本消耗、开发进度、资源利用、用户接口和所需的数据库等许多方面。 在研究用户需求的基础上，将经过分析的软件需求编写成软件需求说明书或软件规格说明书，作为需求分析阶段的主要工作成果。

39. 我们怎么办？（续四） • 软件设计 分为概要设计(也称为总体设计或结构设计)和详细设计(模块设计)两个阶段。 概要设计是从宏观角度解决开发软件“怎么做”的问题，把系统要完成的任务按功能分块，明确各模块的功能以及它们之间的接口，即模块之间的相互关系以及模块之间传递的信息。 详细设计则要明确每个模块内部的处理过程，即要给出每个模块的详细说明、流程图、一些典型或重要方法的结构化说明或伪代码等。

40. 我们怎么办？（续五） • 总体设计 根据需求分析阶段的用户需求说明书，产生具体的实际方案，主要解决：①怎样将系统分解成一个个功能独立，大小规模适当的模块；②判定各模块之间传递的数据，规定各个模块的功能和模块之间的相互联系；③决定各模块间调用的层次关系；④审查评价模块结构的质量；⑤产生模块说明书。 该阶段常用的方法有：自顶向下逐步求精、原型法；结构化设计方法，即SD方法、Jackson方法、Parnas和LCP方法。

41. 我们怎么办？（续六） • 详细设计 软件设计的第二阶段，与总体设计相比，它主要考虑每个模块内部的数据加工处理，完成模块内部详细的过程描述。 进行详细设计主要使用的工具可分为三种类型①图示工具，常用的有结构化流程图、N-S图和PAD图；②伪代码语言；③表格工具，如判定表、判定树等。

42. 我们怎么办？（续七） • 软件测试 为了发现错误而执行程序的过程，是软件生存期中的重要阶段之一。它的主要任务是发现并排除需求分析、系统设计和编码等阶段产生的各种类型的错误，得到可靠的可运行的软件系统。 软件测试可分为四级①单元测试；②集成测试；③确认测试；④系统测试。常用的测试方法有白盒测试法和黑盒测试法。

43. 我们怎么办？（续八） • 软件维护 作为产品的软件已交付用户使用以后，对软件产品所进行的后续软件工程的活动。它是软件工程的重要环节，据统计资料表明，该阶段的花费占整个软件生存期花费的60％以上。 它的工作包括三方面：改正性维护、适应性维护和完善性维护。 改正性维护是在软件运行中发生异常或故障时进行的，这种故障常常是由于遇到了从未用过的输入数据组合，或与其他硬、软件接口发生了问题。 适应性维护是使运行的软件能适应外部环境的变动，如计算机的更新换代，操作系统的升级，数据格式的变动等等。 完善性维护则是要扩充软件的功能，提高原有软件性能而开展的软件工程活动。

44. 我们怎么办？（续九） • 执行过程中具体计划和原则： 1、明确各阶段可以检验的目标和标准； 2、指定具体执行计划的人，每人的具体责任与任 务； 3、给出系统所采用的新技术与新工具，以及获得它们的渠道； 4、制定对新技术和新工具的使用进行培训的计划； 5、建立与项目相关联的时间表； 6、明确相关的人力、资金与时间的来源； 7、定出在整个执行过程中，各个阶段所要提供的文档； 8、制定对执行情况进行监察考核的具体办法及计划。

45. 我们怎么办？（续十） • 时间总要求 项目的总进度要与BEPCⅡ工程进度同步。 • 系统的初步设计 完成时间2001年11月—2002年3月 • 了解掌握EPICS环境下的实时数据库与关系数据库之间API接口 完成时间2002年4月—2002年5月？ 弄清控制系统所使用的基础软件：实时操作系统VxWorks和工控组态软件EPICS的功能，实时数据库与关系数据库之间API接口，估计开发的难度，给出分布存储的实时数据加载到关系数据库的具体实现方法。 • 熟练掌握UML语言的使用，在此基础上开展实际意义上的需求分析与系统设计 完成时间2002年5月—2002年7月 • 需求分析与系统设计 完成时间2002年8月—2002年12月 • 程序编码、调试现场测试 完成时间2003年1月—2003年12月 • 系统运行、维护、改进 完成时间2004年1月—2004年12月

46. 谢谢!