| 中国加入WTO以后，作为信息产业核心之一的软件产地如何与国际接轨将成为整个IT界关心的重点。软件产业要想国际化，首先必须采纳国际通行的软件工业化生产标准，即CMM认证。由美国软件工程研究所SEI(Software Engineering Instituto)开发完成的软件能力度成熟模型CMM(Capabitity Maturity Model )是一种协助企业改进软件制作质量与管理流程并进行评估的标准。它是SEI集多年软件研究的经验所研制的过程标准，如今已成为国际上最流行最适用的软件质量改进体系。本文将就CMM的整个框架及各级阶段中的重点领域作详细描述，使读者对CMM的基本概念和内部结构有一个全面的了解。本文还附有CMM过程改进自测表，以协助企业检查并洞测自身软件生产能力的实际水准。 一． 基本概念二． CMM发展概况 三． CMM框架 四． CMM应用 五． 可重复级 六． 定义级 七． 管理级 八． 优化级 第二级（可重复级）自测表 第三级（定义级）自测表 第四级（管理级）自测表 第五级（优化级）自测表 软件过程（Software Process）： 过程即人们为实现某一既定目标所执行的一系列步骤（IEEE--STD--610）。软件过程则可定义为企业设计，研制和维护软件产品及相关资料文档的全部生产活动和工程管理活动。理解包括SEI在内的美国过程学派的一个核心概念就是--只要过程正确及构成过程的解决方法正确，产品就会正确。 软件过程能力（Software Process Capability）： 企业实施软件过程所能实现预期目标的程度。它可用于预测企业的软件过程水平。 软件过程行为（Software Process Performance）： 企业在项目开发中遵循其软件过程所能得到的实际结果。 软件过程成熟度（Software Process Maturity）： 软件过程行为可被定义，预测和控制并被持续性提高的程度。它主要用来表明不同项目所遵循的软件过程的一致性。 软件能力成熟度等级（Software Capability Maturity Ievels）： 企业的软件开发在由低到高成熟化演进过程中所普遍面临的具有一定成熟度标志特征的平台。 成熟与不成熟（Mature and Immature）： 不成熟的标志有--没有明确的软件过程体系可以依据；无法对生产进行预测；不严格执行生产过程；质量无法保证；无健全的过程控制及质量控制体系；项目开发没有准则可遵循；开发结果主要依据项目小组及个人的带有主观因素的能力发挥。 成熟的标志有--项目开发是依据企业早已明确的过程准则来实施；开发结果较少依赖个人能力和自然因素；项目由过程控制并可对整个生产作出预测；产品质量得到有效监控（借助客观定量化的数据）；过去的开发项目中所获经验得以积累并可系统地用于现行和未来的项目之中。 配置管理（Configuration Management）： 包括以下管理行为：对某个配置项的功能和物理特性进行识别和编档；对这些特征的变动进行控制；对变动和事实进行记录、汇报；验证需求计划的实现。 偏差（Deviation）： 针对开发中的计划、标准、规划等的明显偏离和变动。 同业复审（Peer Review）： 软件项目开发成员的同行遵循某一规则对项目产品所作的检查，用于发现缺陷所在。 风险管理（Risk Management）： 运用风险概率方法分析评估项目开发中设计的各类风险，包括风险识别，风险分析，风险等级排序和风险控制。 软件工程过程组（Software Engineering Process Group）： 协助开发机构对所采纳的软件过程进行制定、分析、监控和改进的专家组。它应直接想机构的最高领导层负责。 软件生命周期（Software Life Cycle）： 指软件开发所涉及的全过程，包括从产品设计到产品终结的整个周期，一般分为概念阶段，需求阶段，设计阶段，实施阶段，测试阶段，安装调试阶段，运行维护阶段，终止阶段。 软件需求（Software Requirement）： 用户为实现某种目标或解决某种问题要求软件给予满足的条件。 CMM模型是基于多年产品质量研究成果所建立。美国的Walter Shewart于上世纪30年代发表了统计质量控制成果。在Watts Hunaphrey和Ron Radice等人的研究成果之上，卡莱基.梅隆大学软件工程研究所将这套质量控制方法改造为能力成熟度框架并标明不同城市度等级，Humphrey并于1987年发表了初步的成熟度提向单。1990年SEI公布CMM的0.0版。1991年SEI公布了包含第二级KPA方案的CMM0.4版及包含第三级方案的CMM0.5版，同年，又发布了包含第四级和第五级KPA方案的0.7版。CMM1.0版于1991年底发布，1993年SEI公布CMM1.1版。目前通行的版本是1.1版，改进版2.0版原定于1997年完成，但由于CMMI（能力成熟度集成）的开发，2.0版被推迟。CMMI（Capability Maturity Model Integration）将把各种能力成熟度模型整合到同一架构中去，由此建立起包括软件工程软件采购和系统工程在内的诸模型集成，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。CMMI框架包括软件能力成熟度模型，系统工程能力成熟度模型，软件采购能力成熟度模型，继承产品 和过程开发等。1995年，个体软件过程（Personal Software Process，PSP）又被提出，用于控制和改进个人软件开发方式，PSP是一个过程描述、检测和方法的集合，能够帮助软件工程师改善其个人软件开发性能。它包括一整套适用于个人软件工作者在实践中应用的表格，脚本和标准，以帮助软件工程师预估和计划其工作减少软件工作缺陷并提高计划和生产效率。CMM是适用于软件开发组织中的流程管理，而PSP则面向个体开发人员。本文的探讨仅限于CMM软件能力成熟度模型。 CMM的出现是为了克服软件生产的危机。所谓软件生产的危机是指尽管新的软件开发方法和技术不断生产，但软件生产率和质量并未得到有效提高，软件产品不能按时完成，软件生产预算超支，而且交付客户使用的软件产品（特别是大型软件工程）中由于各种原因产生的错误无法克服。在80年代末期前后，美国国防部门和工业界开始认识到在软件开发中最重要的问题在于软件生产商对软件的生产过程管理不力，也就是说，软件生产过程的成败比新技术和开发方法更能决定一个项目或企业的成败。没有完善的软件生产过程体系，软件开发的成败只能依靠人为主观或偶然因素--比如某一杰出软件天才或小组的成就--而非可持续的客观标准及体系，因此，对成功的软件过程的重复使用，对以往经验或教训的分析总结，对全部开发案例的系统编档存档就成了一套完整而成熟的软件过程，需要一个从无序到有序，从人为到客观标准，从定性到定量的不断积累与完善的过程，这一过程的演变中软件企业会面临一系列有代表意义的成熟阶段。美国SEI提出的软件能力的评价与改进指导体系。软件开发企业可以依据CMM的框架对项目管理和项目工程进行定量控制和能力评估，而软件应用单位也可依据CMM来衡量和预测项目承接方的实际软件生产能力。这样，软件开发方与产品用户方都基于一个同样的标准来对软件生产和管理作评测与控制。大体来说，软件开发企业在以CMM为标准改进其生产过程中应采取如下步骤： 随着企业CMM成熟度等级的提高，项目开发中的风险可以得到逐步减低，开发时间也大大缩短，开发成本得以减少并大大降低软件产品中的错误发生率。CMM不仅可以提高企业在国际市场上的软件出口竞争力，也可提高企业自身的软件管理与开发水平，有助于客户对企业生产能力树立信心。目前，欧美等国的大型软件用户与软件供应商共同采纳CMM作为供需双方软件产品质量及工程预算的标准。印度软件企业更是对CMM全力投入，每年定期进行CMM培训，目前全球通过CMM四级与五级的软件企业中，印度占半数以上，印度企业的软件产品出口总值也从10年前的五千万美圆增长到五十亿美元，并预计于2008年达到五百亿美元。印度约有1000家软件企业，34万从业人员，《财富》杂志全球500强企业中近半数为印度软件企业的客户。到1999年止，全球范围内共进行了1330次CMM评测，总计评测项目有5452项，参加评测的机构逐年攀升，其中有7.2%是海外项目，参加国别有34个，参加机构类型，商业机构占56.1%，美国国防部供应商占29.8%，军方和政府机构占10.5%。其中，初始级机构占总评估数的43.2%，可重复级占34.2%，定义级占17.3%，管理级占4%，优化级占1.4%。第二级（可重复级）比例最高的为25人到100人的机构，第三级（定义级）所占比例最高的为1000到2000人的企业，第五级（优化级）所占比例最高的为2000人以上的企业。由此可见，通过CMM第二级的最佳规模为25人到100人。 软件生产过程理论告诉我们，软件质量往往取决于软件过程的能力水平，企业在软件过程中所采用的各种技术应适合该过程的成熟度水平。软件过程是一个可度量的，可控制的，不断改进的流程。CMM强调企业应对软件过程进行连续的改进，在这一改进过程中，分级结构将提供不同等级中的目标和核心领域来规范这一过程并为企业评论和改进自身生产能力提供客观标准。 CMM成熟程度理论不可以被看作纯粹的关于软件生产技术的标准，也不可以被看作普通的管理理论，它实际上是对软件开发实践所设计的整个工程流程的规定和分析，它的体系既包括软件工程过程本身，也包括对这一过程的管理。 CMM为企业软件能力提供了一个阶段式的五级进程。任何开始采纳CMM体系的机构都一并归与第一级的起点，即初始级（Initial level）除第一节外，每一级都设定了各自的目标组。如果达到了这一目标，则可向下一级推进，由于每一个级别都必须建立在实现了低于它的全部级别的基础之上，CMM等级的提高只能是一个渐进有序的过程。 CMM的评估包括五个等级，共计18个核心过程域，52个目标，300多个核心实践，每一级别的评估由美国卡莱基*梅隆大学软件工程研究所授权的主评估师领导的评估小组进行。其成员来自企业内部，评估过程包括企业员工培训，问卷填写，文档与数据分析，相关项目组成员面试，拟定评估报告。评估结束由主评估师签订生效。 CMM五级标准按由低到高的成熟度分别为：
1. 初始级 此级是个人英雄主义的天下，绝无可重复性，也无甚积累，项目的执行是随意甚至混乱的，软件开发过程未经定义，即使有某些规范也并未严格执行，企业不具备稳定的软件开发与维护环境，面对开发中所遇的各类具体实施问题往往选择放弃原定计划仍由编程人员凭个人经验与主观感觉应对，对客户的承诺多数无法兑现，许诺客户的产品与服务质量并无客观的预测与监控体系保证实现。在此，能力只是个人行为不是组织行为，一旦人员流动或变动，整个企业的开发能力也随之而去。整个企业没有稳定的过程规则可依据。现有的种种规章制度也互不协调或矛盾。开发人员的工作方式是救火式，那里有漏洞就往哪里填补，很少收集关于开发过程的数据，新技术的引进也要冒极大风险。总之，整个企业的软件生产是不可重复，不可预见，不成体系，不可积累及不稳定的。 本阶段改进重点包括：建立软件项目开发过程并进行有效管理；建立需求管理，明确客户要求；建立各类项目计划；建立完善的文档体系，严格执行质量监控；按CMM二级所规定的各项核心实践进行开发。 2． 可重复级 确定了基本的软件生产管理和控制，能针对特定软件项目制定开发过程及管理措施，能将以往项目开发经验用于类似的新项目，有一套不同的软件生产过程提供不同项目选择。软件生产成本和工期能得以客观预测并被有效追踪，过程标准在项目实施中能保证被遵循。项目的开发是有计划的，有控制的，并可重复的行为，总原则是：一个可管理的过程是一个可重复的过程并能逐渐改进和成熟。 第二级的管理过程包括需求管理，项目计划，项目追踪和监控，子合同管理，质量保证与配置管理等六个方面。在该级的企业可以给客户较有保证的承诺，因为企业可在以往同类项目的成功经验上总结和建立起一整套过程准则来保证成功地重复。项目管理采用基准（Baseline）来标识进展并对成本和进度进行追踪，企业通过子合同管理同客户建立了有效的供求关系，面对开发缺陷有规则可以依据来纠正错误，个人英雄行为被稀释并分解到企业整体的规则和管理框架之中，文档的准备和项目数据的收集也相应完备。 本阶段改进重点包括：将各项目的过程经验总结为整个企业的标准过程，是整个企业的过程能力得以提高，注意，跨项目间的过程管理协调和支持，树立齐全组织的过程标准概念，建立软件工程过程小组（SEPG），对各项目的过程和质量进行评估和监控，使软件过程得以正确地调整。建立软件工程数据库和文档库，加强培训。 3． 定义级 过程在整个企业范围内得以确立。企业制定了一套软件过程规则对所有软件工程和管理行为给与指导。企业有了标准化的过程并可在所开发的项目中，依据具体项目的需要，将标准过程调整为合适的项目过程。企业内部设置了软件工程小组（SEPG）负责过程的制定，修改，调整和监督。这一小组直接向企业最高领导层汇报。企业还有培训机构专门对全企业员工进行过程培训。各项目组的开发经验可相互借鉴并支持，对项目成本，工期及质量均可最终控制。有关软件工程及管理工程的过程文件被编制并成为企业标准，所有项目都必须按照这些标准过程或经调整后的项目过程来实施，从而保障了每一次工程开发的投入和时间，项目计划，产品功能及软件质量得以控制。软件过程在此得到的稳定的，重复的和持续性的应用，使开发风险大为下降。各项目组人员参与软件过程的制定和修改，并引进符合项目过程的新的软件开发技术，在各项目开发过程中收集的数据被系统共享。总而言之，第三级的主要特点在于软件过程已被编制为各个标准化过程，并在企业范围内执行，从而使软件生产和管理更具可重复性，可控制性，稳定性和持续性。 本阶段改进重点：应准备对整个软件过程，包括生产和管理两方面的定量评测分析，以便尽可能将软件工程所涉及的定性因素转变为定量标准，从而对软件进行定量控制和预测。应使整个企业的软件能力在定量基础上可预测和控制。 4．管理级 第四级的过程是量化的过程，所有项目和产品的质量都有明确的定量化衡量标准，软件也被置于这样一个度量体系中进行分析、比较和监控，所有定量指标都被尽可能地详细采集并描述，使之可具体用于软件产品的控制之中，软件开发真正成为一种工业化生产行为，由专门的软件过程数据库收集和分析软件过程中的各类数据并以此为对软件活动的质量评估的基准。企业所有项目的生产过程在定量化的基础上大大提高了可控制性和可预测性，生产过程中可能面对的偏差被控制在一定的量化范围内并被分析和解决，新技术的采纳也在量化基础上有控制的地进行，从而控制了风险。在此级中，所有的软件过程和产品都树立了定量的目标并被定量的管理，使软件组织的能力可以很好地预测。此阶段中所有定量标准都是明确定义并持续一致的，可以用于对软件过程和管理的评估与调节。所有修正和调节方法（包括对偏差及缺陷的校正分析）都是基于变化指标上，新的软件开发技术也在定量的基础上被评估。项目组成员对整个过程及其管理体系有高度一致的理解并已学会运用数据库等方法定量地看待和理解软件工程。本级主要特点是定量化，可预测化和高质量。 本阶段改进重点：注意采取必要措施与方案减少项目缺陷，尽量建立起缺陷防范的有效机制，引进技术变动管理以发挥新技术的功用，引进自动化工具以减少软件工程中人为误差，实行过程管理，不断改进已有的过程体系。 5．优化级 第五级的软件过程应是持续改进的过程，并且有一整套有效机制确保软件工程误差接近最小或零。每一个过程在具体项目的运用中，可根据周边和反馈信息来判断下一步实施所需的最佳过程，以持续改善过程使之最优化。因此，企业能不断调整软件生产过程，按优化方案改进并执行所需过程。 这样，企业的精力集中于持续的过程改进之中。新技术的采用也被作为日常活动加以规划，各项目组已具备尽早和尽快识别工程缺陷并改正错误的手段。这需要完善的数据库和长期积累的量化指标来协助实现，新技术和自动化工具也使软件工程人员能够预防软件缺陷并找到其根源以防止错误再现，企业资源在第五级阶段被有效利用并节约。一般来讲，企业在优化级所遵循的持续改进措施既包括对已有过程的渐进改善，也包括应用新技术和工具所产生的革新式改进，整个企业的过程定义、分析、校正和处理能力也大大加强，这些都需建立在第四级的定量化标准之上。项目组都能主动找到产生软件问题的根源，也能对导致人力和时间浪费等低效率因素进行改进，防止浪费再发生。整个机构都有强烈的团队意识，每个人都致力于过程改进、缺陷防范和高品质的追求。本阶段总的特点是新技术的采用和过程的不断改进被作为企业的常规工作，以实现缺陷防范的目标。 CMM描述的五个等级的软件过程反映了从混乱无序的软件生产到有纪律的开发过程，再到标准化、可管理和不断完善的开发过程的阶梯式结构。任何一个软件机构的项目生产都可以纳入其中，除第一级初始级外，每一级成熟度都由若干核心过程域构成，这些核心过程域分别针对软件开发过程的某一方面阐述了这一等级的软件过程在此方面应达到的目标组的核心实践。所有核心实践又可划分为五种共性：完成目标组所需的承诺、执行能力、执行活动、测量分析、实验验证。当然，任何一个级别的核心过程域都不仅包括本级所有的核心实践。例如，第四级管理级的实现必须完成第四级本身具备的两个核心过程以及第三级中的七个核心过程域和第二级中的六个核心过程域，共十五个核心过程域。 核心过程域又称关键过程域（Key Process Area，KPA），每一个KPA都与一些目标相关，代表某种对过程的要求，我们可根据KPA对软件过程进行评估并找到改进的重点所在。可见，除第一级KPA外，CMM的每一级都按相同结构组成，KPA不仅标明了某级成熟度所要求的目标和评估标准，也说明了要达到此级成熟标准所需解决的具体要点。实施每个核心过程域所包含的核心实践（Key Practices），就是实现此核心过程域所制定的目标并提高软件过程能力。如前所述，各个核心过程域中的核心实践都可按公共属性进行分类，每个KPA都包括五类核心实践。应该指出，核心实践只是规定了软件过程必须达到什么样的标准而未规定这些标准应如何实现，因此，对同样的过程水平，不同企业，不同项目可采纳不同的过程和实施方式去完成。下面，我们将就五类不同的核心实践给予具体说明： 1．执行保证（Commitment to perform）：为完成核心过程域中的目标组成所需的承诺又称执行保证，它是企业执行特定的核心过程域（KPA）所拟定的指导开发过程的规则和项目管理责任。 2．执行能力（Ability to perform）：指企业执行核心过程域的前提条件，包括企业资源、过程制定、人员培训等多种措施。对PKA的执行必须建立在此基础之上，才可保证所规划的目标得以实现。 3．执行能力（Activities performed）：它说明了执行核心过程域所需采纳的必要行动和步骤，与项目执行息息相关，包括计划、跟踪、检测等，这是核心实践的五种归类中与项目执行唯一相关的属性，其余四个属性都关注于软件组织的基础能力建设。 4．测量分析（Measurement and Analysis）：是关于过程的定量度测和度测分析，以确定所执行活动的效果并根据此作出分析判断。 5．实施验证（Verify Implementation）：在过程执行的中途及末尾对过程实施进行验证以确保执行活动与制定的过程相一致。它包括检测、复审等一系列质量保证活动，这些质量保证活动需要通过项目组以外的独立的质检人员和管理人员来保证验证的有效执行，从而确保产品符合计划要求。如果我们把执行活动看作是与项目执行相关的属性，则其他所有属性可一起视为企业成熟度能力基础建设。 在实施CMM过程中，可根据各个企业面临的不同问题决定实现核心过程域的先后秩序并按此秩序逐步进行。而在实施每一个具体的核心过程域时，对其目标组及核心实践也可确定执行的先后顺序，逐步实现总体目标。最后，我们将第二、三、四、五等等级始终的核心过程域简介如下：
第二级（可重复级）
第三级（定义级）
第四级（管理级）
第五级（优化级）
基于CMM成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施CMM的标准成为人们关注的重点。CMM的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，（如编码，操作系统等等），也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。 由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问题，将其作为过程实施开端的要领加以掌握： 1．不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以CMM工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。 2．必须懂得CMM作为一套标准，它指明的是该作什么（What）而非怎样去做（How），同时CMM也代表了一种对软件生产过程进行理解和分析的独到观点（Philosophy）。CMM着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发100%成功，CMM所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。 3．CMM1.1版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于20人以下的小型企业，1.1版中的一些环节可能并不适用。 4．企业在采纳CMM过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。 5．"知己知彼，百战不殆"。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域（KPA）。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。 6．如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括：
CMM模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施CMM的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。 作为一种模型，CMM实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。 目前，世界范围内已采纳CMM标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳CMM体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。 卡莱基·梅隆大学软件研究所提出了一套实施CMM标准的方法，按照他们的建议，IDEAL是企业开始引入CMM体系的良好参照模式，它包括：
如有可能，企业在咨询机构或咨询师的协助下可以加快CMM体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成CMM研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施CMM的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。CMM体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。 根据SEI的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则： 达到可重复级软件能力成熟度能力的企业有能力重复在以前项目上所作开发的成功经验，虽然项目的具体实施各不相同，但通过企业的制度化的有效管理过程，各项目组能够在当前和未来的项目中保证已建立的软件项目管理和实施规则能够得到正确和有效地执行，从而可在新项目上用积累的制度化有序化和文档化的经验进行有成功保障的开发实践，这种成功保障也可在开发前期的项目成本，工程进度和质量预算上得到体现。在此阶段的软件开发组织已拥有了一套有效过程，它们是实用的、文档化的、实施验证过的、可测量的和能改进的。 单个项目组通常会面对各类项目约定问题，项目组对项目的正确约定来源于以往开发项目的经验及当前项目的各级需求。项目经理应成为一个有序体系中的重要环节，他们负责追踪软件成本、进度和功能，能迅速发现项目级约定中出现的问题并设法解决。 各项目组对软件需求和实现需求的软件产品已建立了基于验证的基准或基限，项目标准也得到确立，软件组织能保证正确地执行标准。第二级软件组织的过程能力是有纪律的，项目的规划和追踪是稳定的，项目过程也在项目管理体系的有效控制之下重复着被验证的成功经验。在此，组织体系和管理的问题比技术问题更加重要。 一个成熟度等级是一个正确定义的向软件更高成熟度进步中的平台。除第一组外，每个成熟度等级被分为若干核心或关键过程域，帮助软件企业明了改进其软件过程所应关注的环节。这些环节都是为了达到此一等级所必须解决的问题。SEI制定的各个核心过程域都标志出了一系列相关的工程活动。理论上，完成全部活动软件组织应能实现一个或数个对增进过程能力绝对重要的目标。
为使软件开发组织实现特定的核心过程域，它必须实现与该核心过程域相关的所有目标。虽然由于各个项目的应用环境不同，导致实现核心过程域各目标的途径不同，所有核心过程目标都应由软件组织实现。如果软件组织的所有项目都已持续实现特定核心过程域的所有目标，则该软件组织已具备该核心过程域所代表的所有过程能力并使其规范化。由于CMM并不描述所有与软件开发和维护有关的过程领域，它所选的是在改进软件组织过程能力上最有效的，最具影响力的环节和达到一定成熟度等级的必要条件。
CMM全部五级能力成熟度等级的实现是一个有序的渐进过程，软件开发组织和项目组为了实现某个成熟度等级必须首先实现该等级中的全部核心过程域，而为实现一个核心过程域，首先应该达到该过程域的每一个目标的要求。这是因为SEI定义的目标概括了一个核心过程域的核心或关键实践，用以判断软件组织或项目是否已经有效地、正确地实现了该核心过程域。每一个目标都表明了一定核心过程的范围、界限和意义。随着软件组织向更高能力成熟度的前进，它在每个核心过程域中所应实施的具体活动内容也有所发展。 ·需求管理 在软件项目和客户之间尽可能明确客户自身对该软件项目或产品的真实需求，需求双方有一致的、细致的和可靠的对需求的共同认识。软件项目组将负责按既定程序处理客户的所有事项，此核心过程域保证了与客户的协议成为软件项目计划和追踪监控的基础，应注意在此项目组或组织与客户的关系上应遵循正确有效的，如配置管理中所述的变动控制过程。 ·软件项目计划 制定进行软件工程和软件项目管理的适当计划，并使之成为项目管理的基础所在。项目组可据此对软件项目追踪和监控。一个细致的、切合实际的计划是有效实施项目管理的保证。 ·软件项目追踪与监控
·软件子合同管理 帮助软件开发组织在软件开发的整体商业环境中正确选择合适的软件工程与合同承包商并对其实施有效管理，它应有效协调软件质量保证、软件配置管理等核心过程域中诸相关因素与基本管理控制的核心过程域中的重要因素，包括需求管理、软件项目计划以及软件项目追踪与监控等。 ·软件质量保证 为软件开发提供关于软件项目的过程和软件产品的状况的可视性与控制性，它是软件工程过程和软件管理过程必不可少的组成部分。 ·软件配置管理 在软件项目开发的整个生命周期中，确立和维护有关产品的完整性。它与软件工程涉及的一系列硬件、软件与系统的正确、高效的配置和应用息息相关。 过程改进应基于许多细小的、不断更新前进的步骤而决非革命化的突然创举。CMM的框架正是为软件开发组织提供了一个循序渐进的行动方案和基础。各成熟度等级之间的区别是在有序的和有测度的基础上划分的，对第三级（定义级）来讲，软件组织同样需要对其过程改进工作依据CMM框架的需求排出优先次序。 在此阶段，软件工程管理活动和工程活动两方面的过程都已得到标准化定义、文档化积累并集成到该组织的标准软件过程中去。软件组织的全部项目都应遵循开发和维护软件的标准过程的经批准的裁减或调整版本。 须再次强调的是，在整个组织范围内，软件工程过程和管理过程都在标准化基础上成为一个有机整体，并帮助项目经理和技术人员更有效地从事开发工作。过程标准化的同时，有效的软件实践得到了充分利用，例如，软件工程过程组成立并负责该组织的全部过程活动，包括培训计划的实施和各项目组的协作。 各个项目通过调整开发组织的标准软件过程来确定自己的项目定义过程，并以次说明项目的独特性能。一个已定义的过程包含一系列正确制定的、协调的和整合的工程及管理过程。已经正确制定的过程应具有过程准备就绪标准、输入状况、标准状况、实施规则、验证机制、输出状况以及过程完成标志。据此正确制定的过程，管理层能调查所有项目的开发进度和技术进度。 第三级软件组织的过程能力毫无疑问是标准一致的，这反映在软件项目的工程活动和管理活动中过程都可保证稳定和可重复。所有产品生产线上成本进度质量和效率均受到控制并可实施追踪，这种能力说明了整个软件组织范围内员工能对已定义过程中的相关行为、角色和职责有一致理解。 第三级无疑需建立在第二级的实现之上，因为第三级中所关注的技术和组织体系问题必须建立在过程改进和有序化基础之上。第三级的核心过程域既说明了项目问题也说明了组织问题，在此，软件开发组织树立了与所有项目相关的有效的工程过程和管理过程的规范化的基础： ·组织过程焦点 规定软件开发组织在改进其总体软件过程能力的过程活动中的职责。组织过程焦点活动所得到的是一组软件过程财富，它们在组织的过程定义中被描述。这些财富如集成软件管理中所述，是供各个软件项目使用。 ·组织过程定义 开发和保持一组便于各项目使用的软件过程财富，可改进跨越各个项目之间的过程特性并为软件组织积累长期有用的过程基础。它们也表明了一套稳固的基本规则，在培训等手段的促成下能使这些规则成为开发组织的制度。 ·培训项目 培养软件组织成员的个人技能和知识，使其正确高效地执行软件开发任务。基本培训应由软件组织提供，而软件项目组应另行识别该项目所需的独特技能并提供相关培训。 ·集成软件管理 将软件工程活动和软件管理活动集成为一个协调的，已定义的软件过程，该定义过程需经过对软件组织的标准过程的裁减和调整而得到，也是从过程定义中所述的过程财富而来，调整要基于单个项目的业务环境和技术需求，这在软件产品工程中有所描述。集成软件管理建立在第二级中的软件项目规划和软件项目追踪与监控之上。 ·软件产品工程 一致地实施一个正确制定了的软件过程，目的是为了能正确地和有效地生产合格一致的软件产品，在此，软件过程集成了全部的软件工程活动。项目的技术事项也通过软件产品工程得到明确，包括需求分析、设计、编程和测试。 ·组际协调 这是软件项目组与其他项目组相互支持的手段，它使项目更能正确高效地满足客户需求，它设计多种部门与学科的协调，不仅对软件过程进行集成，而且各项目组之间的关系也必须控制，以促进其沟通和协作。 ·同业复查 这是促进软件项目尽早和高效地发现并排除产品缺陷的有效手段，增强对软件产品和可预防的缺陷的了解。同业复查是经过长期软件开发验证的有效工程方法，对它的具体运用要根据不同的项目作调整。 在此阶段，一个重要工作是对有关软件过程和软件产品质量进行量化数据采集并根据所得数据建立对过程和产品进行监控的有效手段。 软件开发组织的软件产品和过程都应有定量化的，有关质量的目标作为软件组织测量计划的一部分，全部项目都应经度量化检测以掌握和控制其过程活动的生产效率和质量。这里，软件组织需要有一个全组织范围内的软件组织数据库来进行对项目定义过程中有关数据的收集和分析。在第四等级的软件过程中，应该有正确制定的、一致的测度指标，这些测度为定量化地了解和评价项目的过程及产品打下了基础。 项目通过对过程化的范围控制在定量的、可接受的程度内，从而实现对产品和过程的控制。应注意区分过程的无意义的随机变化与有意义的次序变化的区别，另外，具备管理级能力的企业对从事新的领域的软件和采纳新技术所带来的风险能进行预测和控制。因此，第四级软件组织的过程能力是可预测的，它的相关过程是已测量的，并在可测量的范围内实施。开发组织基于这些测量数据和定量指标在可控制的范围内对过程和产品质量的发展趋势进行预测。而一旦超过这个范围，软件组织及项目组能力及时采取适当的纠正措施已保证软件产品可预测的质量得到实现。 管理级中的核心过程域要求软件开发组织建立起对软件过程和产品的定量了解，该级中的两个核心过程域是相互依赖的： ·定量过程管理 在定量测度的基础上能够控制软件项目的过程。这种控制也是对遵循软件过程所得到的实际结果的控制，要求在可以测度的稳定的测度范围发现变动来源并即使纠正产生变动的原因。第四级中的过程管理给软件组织的许多过程和管理活动提供了依据与内容。 ·软件质量管理 应确立对软件项目的质量的定量化了解并实现质量目标。 CMM的等级描述了以模型化的方式所呈现的那些预期能反映软件组织特定等级的本质属性，CMM不是处方，它并不告诉软件组织如何进行改进，也不规定达到成熟度等级的具体方法，从第一等级到第二等级可能需要一到几年的时间，而其他等级之间的递进通常要花一年左右时间，第四级到第五级的过程也不例外。在达到优化级的企业中，绝大多数是拥有数千名开发人员的大型软件企业。在优化级，软件过程改进给企业带来的优势被淋漓尽致地呈现，过程改进已深入组织内部，包括软件组织的战略规划和经营目标、组织机构、新技术与工具以及企业文化和管理体系在内的所有环节中。 软件组织已有能力利用过程、新技术、新观念和新工具的先行实验得来的定量反馈数据来使过程的持续改进成为可能。 在此阶段，整个软件组织都进行不断的过程改进活动，为了预防缺陷的出现，已有有效办法来发现缺陷来源并预先对其采取有针对性的预防措施。通过软件过程有效性的数据对新技术和过程的更新进行成本与工效分析，能判断并采纳最佳软件工程时间和技术创新并推广到全组织。 各软件项目组能协调合作，分析开发中可能遇到的缺陷并找到原因，据此，他们会对软件进香详细评估，将经验传晓其他各项目以防止类似的缺陷在全组织内再次发生。优化级的软件组织具有不断改进过程的能力，并能将过程能力的范围扩大，也不断改善了过程所带来的实际结果，这包括过程改进中的递进演变方式，也包括其他的采用新技术和新工具的革新方法。
优化级的核心过程域主要包括为实施持续不断的、可测量的过程改进所必备的要求： ·缺陷预防 发现缺陷来源并即使采取适当的方法阻止其再次发生，注意在此的焦点不在于纠正当前发现的缺陷，而在于永久性地 防止此类缺陷在未来的再次出现。为此，常常要对具体的项目定义过程进行更新以适应缺陷的预防的需要。 ·技术变动管理 能及时判断可给软件组织带来实际利益的新技术和工具将其引入组织中去，目的是为了不断变化和竞争的环境下正确高效地进行创新。 ·过程变动管理 将软件质量的改进、生产效率的提高和开发进度的缩短作为目标，对软件组织中所采用的软件过程进行持续不断的改善。这一改善必定包括两层相互作用的方面：过程变动管理既含有缺陷预防的渐进式改进，又包括技术变动管理管理的创新式改进。这两个层面应处于有效融合与控制的体系内并使整个组织得以享用这些改进所带来的益处。 填表说明： 一。本试卷针对每一个问题提供四种可能的答案："是，否，不适用，不知道" 如果某种实践被明确建立并有效实施时，请选择"是"，注意，实施必须和标准操作规则一致； 如果某种实践未被确立或有效一致地实施，请选择"否"，注意，该答案包括实践被经常执行但偶尔因种种原因被忽略或任意更改的情况； 如果某种实践或项目的提问是你所能理解，同时根据你对此问题的只是认为该提问不适用于你的状况，请选择"不适用"例如，你从为和子承包商协作，那么，子合同管理的整个内容就可能不适用于你的项目； 如果你对所提的问题不能理解或不具备该方面的知识，请选择"不知道"。 二。每个提问只能选择一个答案。 三。请仔细阅读并回答所有问题。 第二级（可重复级）自测表 一。需求管理： 在客户和软件项目组之间建立对客户实际需求的共同理解，包括和客户一起建立和维护有关软件需求的协议，既包括技术需求也包括非技术需求（例如交付日期）。该协议构成软件生命周期中所有活动的基础（如预测、计划、实施、追踪、评测等）。如果客户需求有所变动，软件计划和实施也应做出相应调整，以求与需求保持一致。 1.是否用软件项目的需求来建立软件工程和管理的基准？
2.当软件项目的需求改进变动时，是否对软件计划、产品和活动做出必要的调整？
3.项目是否遵循软件组织所拟定的对项目需求的书面的管理规则？
4. 项目中负责管理需求的人员是否受到需求管理培训？
5.是否用测量方式来确定需求管理活动的状态（例如，所提议的，未解决的，已批准的和已纳入基准的需求变动总数）？
6.该项目需要管理活动是否受到软件质量保证的评审？ 二。软件项目计划 为进行软件工程活动和软件项目管理所制定的合理的计划，包括预测、项目投入和工期，确定必要的承诺和执行等。 1.供计划和追踪软件项目的预测（例如，规模、成本和工期的预计）是否已文档化？
2.软件项目计划是否将准备实施的活动和对项目的承诺文档化？
3.所有相关的项目组及其成员对项目约定是否同意？
4.项目是否遵循软件组织用于项目计划的书面规则？
5.是否为项目计划准备了足够的资源（例如，资金、有经验的开发人员）？
6.是否用测量方式来确定项目计划活动的状态（例如，项目计划活动里程碑的完成情况与计划本身的比较）？
7.项目经理是否对软件项目计划活动进行定期的和事件驱动的审查？
三.软件项目追踪和监控 提供适当的对项目实际进展的信息，使管理者能在实施明显偏离计划时采取纠正措施。纠正措施包括修改软件开发计划以反映实际的完成情况，重新计划剩余工作或采取改进性能的措施。软件项目追踪和监控包括对文档化的预计，承诺和计划的评审，跟踪软件完成情况及结果，以及在实际完成情况基础上的调整。 1.是否比较了软件项目的实际结果（例如，规模、成本、进度）与计划中的预算？
2.当实际结果明显偏离计划时，是否采用纠正措施？
3.所有相关的项目组及其成员是否同意对项目承诺的更改？
4.项目是否遵循软件组织用于追踪和控制软件开发活动的书面规则？
5.项目组中是否有专人追踪软件产品和活动？（例如，预算、进度和工作量）
6.是否用测量方式来确定软件追踪和监控活动的状态（例如，在追踪和监控活动中所投入的总工作量）？
7.高层管理是否定期参与评审软件项目追踪和监控的活动（例如，项目性能、未解决的问题、风险和行动指导）？
四。子合同管理 选择合格的软件方承包商并有效地对它们进行管理，包括如何选择软件分包商，如何建立与分包商的约定，如何追踪和评审分包商的功效。这些实践包括对软件子合同的管理，也包括对子合同的构成成分的管理，如子合同中含有的软件硬件及其他系统成分的管理。 1.是否按照文档化的规则来针对分包商完成项目的能力挑选软件项目子承包商？
2.子合同的变动是否得到主承包商和子承包商双方的同意？
3.是否与子承包商进行定期的技术交流？
4.是否根据约定追踪子承包商的工作效能和结果？
5.项目是否遵循软件组织管理制定的管理软件子合同的书面规则？
6.负责管理软件子合同的人员是否经过软件子合同管理的培训？
7.是否用测量方式来确定软件子合同管理活动的状态（例如，参照交付日期计划的进度状态以及在子合同管理上投入的工作量）？
8.项目经理是否参与对软件子合同活动的定期的和事件驱动的评审工作？
五。软件质量保证 向管理者提供对软件项目所采纳的过程和所开发的产品的质量信息，包括复查和审核软件产品及活动以验证它们符合试用的标准及规则，也包括向项目经理和其他相关人员提供审核数据和结果。 1.是否对软件质量保证活动作好计划？
2.软件质量保证是否针对软件产品和活动符合试用标准、规则的情况提供了客观的验证？
3.软件质量保证的复查和审核结果是否提供给相关的项目组及其成员（例如，负责该项目工作的管理人员和技术人员）？
4.如有项目组不能解决的与拟定过程不符合的问题，是否交由高级管理层解决（例如，偏离适当的标准）？
5.项目是否遵循软件组织实施软件质量保证的书面规则？
6.是否为软件质量保证活动准备了足够的资源（例如，资金和专门负责处理过程不符合情况的经理）？
7.是否用测量方式来确定软件质量保证活动的成本和进度状况（例如，已完成工作，投入的工作量，资金与计划的比较）？
8.高层管理是否定期参与对软件质量保证活动的评审？
六。软件配置管理 建立和维护在项目的整个生命周期内软件产品的完整性，包括指明在特定时段上软件的配置（即选定的软件产品及其描述）系统的控制对配置的变动，并在整个软件生命周期内保持配置的完整性和可追踪性。软件配置管理所含的产品包括最终交付给客户的产品，以及与这些产品一起标明的事项或开发这些产品所必须的事项（如硬件、系统等） 1.是否拟定对项目软件配置管理活动的计划？
2.通过配置管理，项目是否已经对软件产品进行标明、控制并使其可用？
3.项目是否遵循一套文档化的规则，对配置事项或配置单元的变动进行控制？
4.是否把关于软件基准（即经过正式评审及认定的软件配置事项，它们此后可作为进一步开发的基础并只有通过正式的更改程序才能被变动）的标准报告分发给相关的项目组及成员（此类报告包括软件配置控制组会议记录，变动申请汇报，状态报告）？
5.项目是否遵循软件组织如何实施软件配置管理活动的书面规则？
6.项目组成员是否经过专门培训使其能完成所负责的软件配置管理活动？
7.是否用测量方式来确定软件配置管理活动的状况（例如，为软件配置管理活动所投入的工作量和金钱）？
8.是否进行定期审核以验证软件基准同定义基准的文档相符合（例如，由软件质量保证小组定义的文档）？
CMM自测表解答 请阅读并回答所有提问，每个问题只能选择一项答案。针对每级自测结果，你可以以下方式确定是否通过该级能力成熟度水平。 1． 所有提问你都根据企业的真实情况给予了回答。 2． 在判断你的选择时，你所采纳的标准是完全按照问题中所要求的标准来严格检查你的企业是否执行了某项措施。 3． 要达到某级标准，你对该级标准的所有提问都应该一致性地选择"是"。 4． 如果某项措施在你的企业中有类似的替代性措施，对该提问你可选择"是"。 5． 此自测表只是一份简单的企业CMM水平自测的帮助提问单，它并不负责回答你的企业目前所具备的真实能力登记。不可用该自测表替代企业CMM水平预评估试卷与正式评估试卷。 6． 针对任何提问你都可在本自测表末尾的评语处记录下你的评估过程及发现的问题。 填表说明： 一。本试卷针对每一个问题提供四种可能的答案："是，否，不适用，不知道" 如果某种实践被明确建立并有效实施时，请选择"是"，注意，实施必须和标准操作规则一致； 如果某种实践未被确立或有效一致地实施，请选择"否"，注意，该答案包括实践被经常执行但偶尔因种种原因被忽略或任意更改的情况； 如果某种实践或项目的提问是你所能理解，同时根据你对此问题的只是认为该提问不适用于你的状况，请选择"不适用"例如，你从为和子承包商协作，那么，子合同管理的整个内容就可能不适用于你的项目； 如果你对所提的问题不能理解或不具备该方面的知识，请选择"不知道"。 二。每个提问只能选择一个答案。 三。请仔细阅读并回答所有问题。 第三级（定义级）自测表 一。组织过程焦点 建立起软件组织对软件过程活动的责任，包括促进和保持对软件过程的了解、协调、制定、维护、评估和改进这些过程的活动，软件组织将对改进组织的整体软件过程能力提供持续的支持。例如，通过成立软件工程过程组来协调软件过程的制定和维护。 1.在整个组织中。制定和改进软件组织的以及软件项目的过程的活动是否协调（例如，由软件工程过程组来执行）？
2.软件组织的过程是否接受定期的评估？
3.软件组织是否遵循文档化了的定义和改进组织过程计划？
4.高层管理是否推动整个组织的过程的制定和改进活动（例如，建立长期计划、承诺资源和资金的投入）？
5.是否有一个或多个成员投入全部或部分时间来负责软件过程活动的开展（例如，一个软件工程过程组）？
6.是否用测量方式来确定软件组织制定和改进过程的活动（例如，软件过程评估和改进所投入的工作量）？
7.高层管理是否定期参与为制定和改进软件过程所作工作的评审？
二。组织过程定义 开发和维护一组便于运用的软件过程资源并使其能促进各项目组之间过程的性能，为软件组织所积累的长期能力打好基础。包括定义和维护软件组织的标准过程及相关的过程资源，例如，软件生命周期的描述，过程调整准则，软件组织过程数据库和文档库。 1.软件组织是否已制定并维护一套标准的软件过程？
2.软件组织是否收集并举审查该组织标准软件过程运用的信息，使其得到应用（例如，有关软件规模、成本和工作量的预计值以及实际值、生产效率数据、有关质量的度量）？
3.软件组织是否遵循关于制定和维护其标准软件过程和相关过程资源的书面规则（例如，对经过批准的软件生命周期的描述）？
4.制定和维护软件组织的标准过程的成员是否接受过必须的培训？
5.是否用测量方式来确定定义和维护软件组织标准过程的活动状况（例如，项目进度里程碑的状况和过程制定的成本）？
6.制定和维护软件组织的标准过程的活动及产品经过软件质量保证的复查和审核？
三。培训活动 培训并提高软件组织成员的技能和知识，使他们能正确地，高效地履行职责，包括明确软件组织，软件项目和个人的培训要求并开展培训以满足需求。培训方式包括非正式的技能传授（例如，接受咨询和在职培训）和正式的技能传授（例如，课堂学习和有指导的自学）。选择什么样的培训方式应根据与实现的技能的特性而定。 1． 是否有对培训活动的计划？
2． 是否为执行软件组织的管理和技术所需要的技能和知识提供培训？
3． 软件项目和其他与项目组有关的成员是否接受了与其职责所需的培训？
4． 软件组织为满足培训需要，是否遵循书面的培训规则？
5． 软件组织是否为执行培训计划准备有足够的资源（例如，资金、软件工具、培训设施）？
6． 是否用测量的方式来确定培训活动的质量？
7． 高层管理是否定期参与对培训活动的审评？
四。集成软件管理 将软件工程活动和管理活动集成为一个协调的、定义好的软件过程，该过程对软件组织的标准过程和相关过程资源进行调整而得来的。包括制定项目的软件过程并依此定义好的过程去管理软件项目。软件项目的定义过程是软件组织的标准过程经调整后的版本，这种调整或截减是为了使普遍的标准过程适合于每个项目的具体特性，软件开发计划基于项目的定义过程来说明如何实施和管理项目的定义过程的相关活动。 1． 是否通过调整软件组织的标准过程来制定项目的定义过程？
2． 是否按项目的定义过程对项目进行规划和管理？
3.软件项目是否遵循了软件组织要求使用标准过程来规划和管理项目的书面规划？
4.负责调整软件组织的标准过程来制定项目的定义过程的成员是否接受过相应的培训？
5.是否用测量的方法来确定集成软件管理活动的成效（例如，重新规划的频率、原因和数量）？
6.管理软件项目的活动和产品是否受到软件质量保证的复查和审核？
五。软件产品工程 一致地执行一个定义好的过程，该过程集成了全部软件工程活动，以利于正确而高效地生产合格一致的软件产品。软件产品工程包括采用项目定义过程和合适的技术及工具去实施维护工程活动，这些工程活动包括：分析软件的系统需要、开发软件的体系结构、设计并编程、测试软件是否满足规定的需求。 1.是否按照项目的定义过程生产软件产品？
2.各软件产品之间的一致性是否得到保持（例如，从软件需求、设计、编程一直到测试用的文档始终保持追踪）？
3.项目是否遵循软件组织的有关软件工程活动的书面规则（例如，运用适当的技术和工具来生产和维护产品）？
4.是否为进行软件工程活动准备足够的资源（资金，有技能的个人，适当的工具）？
5.是否用测量的方式来确定软件产品的功能和质量（例如，缺陷的数量，类型和严重性）？
6.软件工程的活动和产品是否受到软件质量保证的复查和审核（例如，是否进行所需的测试，是否对软件需求，设计，编程和测试保持追踪？
六。组际协调 为软件项目组建立与其他项目组沟通并相互支持的方式以使项目能正确有效地满足客户需要。包括各项目组一齐参与规划对软件系统的需求目标和执行计划事项。项目组成员还会与客户和终端用户一齐制订软件系统的需求目录和执行计划，项目组的全部开发工作都应以这些制定好的需求，目标和计划为基础，其中，各方之间的约定或承诺即各方需遵守的，拟订好的协议。 1.针对某一项目，项目组和其他相关工程组是否与顾客合作拟定系统需求？
2.项目组是否同意在总计划中提出的项目承诺或约定？
3.项目组是否明确、追踪和解决各组间的问题（例如，不协调的进度、技术风险、系统层的问题）？
4.软件组织是否有书面的规划指导各工程项目组建立跨组协调组织？
5.不同的工程项目组所用的系统工具是否使有效的沟通和协调成为可能（例如，兼容的文字处理系统、数据库系统、追踪系统）？
6.是否用测量方式来确定组际协调活动的状况（例如，项目组在支持其他组上所投入的工作量）？
7.项目经理是否参加审评组？协调的定期的和事件驱动的活动？
七。同业复查 为了及早地高效地发现产品缺陷所进行的工作，它应使成员对软件产品及其缺陷有更深入地理解。它是软件同行为发现缺陷和更改缺陷来源对产品进行的系统检查，接受检查的产品在项目定义过程中被标明，其进度成为软件项目规划的一部分。 1. 对同行复查是否有所规划？
2. 同行复查中发现的缺陷来源是否受到追踪直至解决？
3. 项目是否遵循软件组织关于同行复查的书面规则？
4. 参加同行复查的人员是否接受过所需的培训？
5. 是否用测量的方式来确定同行复查活动的状况（例如，同行复查次数、所投入的工作量、经过复查的产品数量以及这些数据与计划的比较）？
6. 同行复查的活动和产品是否受到软件质量保证的复查和审评（例如，是否进行了计划中的检查、是否追踪了后续行为）？
CMM自测表解答 请阅读并回答所有提问，每个问题只能选择一项答案。针对每级自测结果，你可以以下方式确定是否通过该级能力成熟度水平。 1． 所有提问你都根据企业的真实情况给予了回答。 2． 在判断你的选择时，你所采纳的标准是完全按照问题中所要求的标准来严格检查你的企业是否执行了某项措施。 3． 要达到某级标准，你对该级标准的所有提问都应该一致性地选择"是"。 4． 如果某项措施在你的企业中有类似的替代性措施，对该提问你可选择"是"。 5． 此自测表只是一份简单的企业CMM水平自测的帮助提问单，它并不负责回答你的企业目前所具备的真实能力登记。不可用该自测表替代企业CMM水平预评估试卷与正式评估试卷。 6． 针对任何提问你都可在本自测表末尾的评语处记录下你的评估过程及发现的问题。 填表说明： 一。本试卷针对每一个问题提供四种可能的答案："是，否，不适用，不知道" 如果某种实践被明确建立并有效实施时，请选择"是"，注意，实施必须和标准操作规则一致； 如果某种实践未被确立或有效一致地实施，请选择"否"，注意，该答案包括实践被经常执行但偶尔因种种原因被忽略或任意更改的情况； 如果某种实践或项目的提问是你所能理解，同时根据你对此问题的只是认为该提问不适用于你的状况，请选择"不适用"例如，你从为和子承包商协作，那么，子合同管理的整个内容就可能不适用于你的项目； 如果你对所提的问题不能理解或不具备该方面的知识，请选择"不知道"。 二。每个提问只能选择一个答案。 三。请仔细阅读并回答所有问题。 第四级（管理级）自测表 一． 定量过程管理 定量地控制软件工程项目的流程，包括以某种定量方式测量流程特性，并对测量结果进行分析、调整，以保证过程的可控制性。如果过程能持续稳定在一定范围内，则可将其工程流程及相关测量数据和范围作为基准，用以定量地控制软件过程。 1． 项目是否遵循软件组织的文档的定量过程管理计划？
2． 是否用定量方法控制项目的定义过程的性能（例如，使用定量分析法）？
3． 软件组织的标准过程的能力是否已定量地明确和掌握？
4． 项目是否遵循软件组织的测量和控制项目定义过程的书面规则（例如，识别、分析和控制变动原因的项目计划）？
5． 是否为定量过程管理准备足够的资源（例如，资金、软件支持工具和测量指导）？
6． 是否用测量结果来确定定量过程管理活动的状况（例如，定量过程管理活动的成本和里程碑的完成状况）？
7． 项目经理是否参与评审定量过程管理定期的时间驱动的活动？
二． 软件质量管理 确定软件产品的质量目标，指定实现这些目标的计划，控制和调整软件计划、软件产品、项目过程和质量目标以满足客户和终端用户的需求。根据软件组织、顾客和终端用户对质量的需求来建立定量的产品质量目标。为实现软件质量目标，软件组织需制订规划并针对具体项目调整已定义过程。 1． 就每一个项目而言，是否计划好管理软件质量的活动？
2． 项目是否采用可测量的并优化排序的目标管理产品的质量（例如功能性，可靠性，可维护性和易用性）？
3． 是否比较质量的测量数据与产品的质量目标以确定产品是否达到质量目标？
4． 项目是否遵循软件组件管理质量的书面规则？
5． 软件项目组及相关组的成员是否接受了有关软件质量管理的培训（例如有关采集测量数据及定量管理产品质量的培训）？
6． 是否用测量数据确定软件质量管理活动的状况（例如只低劣的成本损耗）？
7． 高层管理是否参加评审软件质量管理的定期的活动？
CMM自测表解答 请阅读并回答所有提问，每个问题只能选择一项答案。针对每级自测结果，你可以以下方式确定是否通过该级能力成熟度水平。 1． 所有提问你都根据企业的真实情况给予了回答。 2． 在判断你的选择时，你所采纳的标准是完全按照问题中所要求的标准来严格检查你的企业是否执行了某项措施。 3． 要达到某级标准，你对该级标准的所有提问都应该一致性地选择"是"。 4． 如果某项措施在你的企业中有类似的替代性措施，对该提问你可选择"是"。 5． 此自测表只是一份简单的企业CMM水平自测的帮助提问单，它并不负责回答你的企业目前所具备的真实能力登记。不可用该自测表替代企业CMM水平预评估试卷与正式评估试卷。 6． 针对任何提问你都可在本自测表末尾的评语处记录下你的评估过程及发现的问题。 填表说明： 一。本试卷针对每一个问题提供四种可能的答案："是，否，不适用，不知道" 如果某种实践被明确建立并有效实施时，请选择"是"，注意，实施必须和标准操作规则一致； 如果某种实践未被确立或有效一致地实施，请选择"否"，注意，该答案包括实践被经常执行但偶尔因种种原因被忽略或任意更改的情况； 如果某种实践或项目的提问是你所能理解，同时根据你对此问题的只是认为该提问不适用于你的状况，请选择"不适用"例如，你从为和子承包商协作，那么，子合同管理的整个内容就可能不适用于你的项目； 如果你对所提的问题不能理解或不具备该方面的知识，请选择"不知道"。 二。每个提问只能选择一个答案。 三。请仔细阅读并回答所有问题。 第五级（优化级）自测表 一． 缺陷预防 分析项目开发中遇到的缺陷的来源并设法防止其发生。这些缺陷包括其它项目中的缺陷和目前项目中的被发现的缺陷。需要进行趋势分析以追踪已有缺陷类型并识别可能再遇的缺陷。 1． 是否对缺陷预防活动作好计划？
2． 项目是否举行识别分析缺陷原因的原因分析会议？
3． 一旦发现缺陷，是否将它们排序并系统消除它们？
4． 项目是否遵循有关缺陷预防的书面规则？
5． 项目组和相关组的成员是否接受有关缺陷预防的培训？
6． 是否用测量方式确定缺陷预防活动的状况（例如识别和更正缺陷所用的时间及成本，和建议中的，进行的及完成的行动数）？
7． 缺陷预防活动和产品是否受到软件质量保证的复查和审核？
二． 技术变动管理 1． 软件组织是否遵循技术变动管理和计划？
2． 是否对新技术进行评价以确定它们对质量和生产效率的作用？
3． 软件组织是否遵循将新技术引入标准软件过程的文档化的规则？
4． 高层管理是否参与软件组织对技术变动管理的活动（例如，通过制定和作出资金、人力等资源的承诺）？
5． 是否有过程方面的数据来帮助选择新技术？
6． 是否用测量的方法来确定软件组织在技术变动管理方面的活动（例如，进行技术变动的效果）？
7． 高层管理是否定期参与评审技术变动管理的活动？
三． 过程变动管理 确定过程变动目标，并在高层管理的参与下持续改进软件组织的标准过程和项目定义过程，同时对这种改进进行前瞻的、系统的评价，制定培训计划使软件组织每个成员都能够参与软件过程改进活动并得到鼓励，对改进的实施及时识别并评价其功效。在将过程改进纳入标准实践之前，对其进行实验评估，当软件过程变动经批准被用于实践之时，应恰当地修正软件组织的标准过程和项目定义过程。 1． 软件组织是否遵循制定和维护软件过程改进计划的书面规则？
2． 是否软件组织的成员都参加过程改进活动（例如，成为软件过程改进的项目组成员）？
3． 是否对软件组织的标准过程和项目定义过程进行持续不断的改进？
4． 软件组织是否遵循实施软件过程改进的书面规则？
5． 软件管理人员和技术人员是否都接受了软件过程的培训？
6． 是否用测量方法来确定软件过程改进活动的状况（例如，将实施每项过程改进的效果与其目标相比较）？
7． 高层管理是否定期参与软件过程改进的工作？
CMM自测表解答 请阅读并回答所有提问，每个问题只能选择一项答案。针对每级自测结果，你可以以下方式确定是否通过该级能力成熟度水平。 1． 所有提问你都根据企业的真实情况给予了回答。 2． 在判断你的选择时，你所采纳的标准是完全按照问题中所要求的标准来严格检查你的企业是否执行了某项措施。 3． 要达到某级标准，你对该级标准的所有提问都应该一致性地选择"是"。 4． 如果某项措施在你的企业中有类似的替代性措施，对该提问你可选择"是"。 5． 此自测表只是一份简单的企业CMM水平自测的帮助提问单，它并不负责回答你的企业目前所具备的真实能力登记。不可用该自测表替代企业CMM水平预评估试卷与正式评估试卷。 6． 针对任何提问你都可在本自测表末尾的评语处记录下你的评估过程及发现的问题。 |
版权所有：UML软件工程组织