CMM的SQA过程域的主要内容

软件质量保证软件质量保证第第2讲讲 CMM的的SQA过程域的主要内容过程域的主要内容议程议程lCMM简介lCMM和CMMI的比较lCMM实施相关问题CMM是l一些成功项目的软件过程的总结；l过程管理；l一种不断改进软件过程和软件过程能力的方法和步骤；l以“按期如预算地生产高质量软件”为最终目标的；l通过描述“谁做什么”来指导过程改进的；l有明细判据确定是否已经达到其要求的；l与具体的软件生命周期、开发方法等无关的；The Five CMM Maturity LevelsInitial(1)Repeatable(2)Defined(3)Managed(4)Optimizing(5)Disciplined processStandard,consistent processPredictable processContinuously improving processThe FiveMaturity LevelsCMM 的五层体系结构的五层体系结构初始级(1)可重复级(2)已定义级(3)已管理级(4)优化级(1)训练过程标准化、一致化过程可预计过程持续改进过程CMM五级特征五级特征l初始级：企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测 试。l可重复级：建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。l定义级：有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。l定量管理级：企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案，要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。l优化级：整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。成熟度等级成熟度等级的内部结构的内部结构核心（关键过程域）核心（关键过程域）关键过程域关键过程域关键过程域关键过程域关键过程域关键过程域过程分类过程分类等级等级管理方面管理方面组织方面组织方面工程方面工程方面优化级优化级 技术改革管理过程变更管理缺陷防范可管理级可管理级定量过程管理 软件质量管理已定义级已定义级集成软件管理组间协调组织过程焦点组织过程定义培训程序软件产品过程同级评审可重复级可重复级需求管理软件项目计划软件项目跟踪与监控软件转包合同管理软件质量保证软件配置管理 初始级初始级无序过程共同特点共同特点一个关键实一个关键实践的例子践的例子关键实关键实践的例践的例子子2SW-CMM 的模型构成成分的模型构成成分 Maturity Level 1:The Initial Level黑箱黑箱lThe software process is a black box,where visibility into the projects process is limited.lThe software development is looked as a black art.lIt is difficult to establish the projects progress and activity status since the activities are poorly defined.lProblems result in crisis situations and fire-fighting.lRequirements flow into the project in an uncontrolled manner and a product somehow flows out.Maturity Level 1:The Initial LevellSummary PointslThe customer can assess whether the product meets the requirements only when the product is delivered.lCapability is a characteristic of the individuals in the project,not of the project or organization.Maturity Level 1:The Initial LevellAn organization at the Initial Level:lTypically does not provide a stable software development/maintenance environment.lTends to overcommit and the staff has difficulty meeting the commitments made resulting in a series of crisis.lSuccess depends on the competence and heroics of the people doing the work.lDuring crisis,projects abandon process and revert to coding and testing.lHas unpredictable outcomes.lIs characterized by the absence of sound managerial practice.初始级初始级l过程特征软件过程不稳定，项目的执行是无序的甚至是混乱的，没有为软件开发，维护工作提供一个稳定的环境一旦遇到危机时经常放弃或改变原有计划过程，直接进行编码和测试成果取决于个人的能力，经验，知识和他们的进取心以及积极程度。成功依赖于个别杰出的管理人员和有经验有能力的软件开发队伍。组织中的软件过程能力体现在个人身上，而不是整个组织中稳定的过程能力。组织依靠个人的能力，往往承受着巨大压力。一旦此类人离去，组织的稳定作用也随之而去。整个软件过程不可确定和不可预见。组织的软件过程在实际的工作中经常被改变（过程是随意的）。这类组织也在开发产品，但其成果是不稳定的，不可预见，不可重复的。也就是说，软件的计划，预算，功能和产品的质量都是不可确定和不可预见的。各种条例和规章制度不健全。即使有也是互不协调，甚至互相矛盾人们的工作方式处于一种“救火”状态，不断地应付开发过程中出现的危机在引进新技术方面有极大的风险初始级初始级l工作组可能会建立一些工作组，例如：软件开发组，项目工程组等l度量没有进行数据收集或分析工作l改进方向要建立项目过程管理，实施规范化管理，保障项目的承诺要进行需求管理方面的工作，建立用户与软件项目之间的沟通，使项目真正反映用户的要求要建立各种软件项目计划。例如，软件开发计划，软件质量保证计划，软件配置管理计划，软件测试计划，风险管理计划及过程改进计划等积极开展软件质量保证活动（SQA)Maturity Level 2:The Repeatable LevellThe process of building the software is a series of black boxes where visibility is provided at predefined checkpoints(ex.,milestones).lManagement reacts in a controlled manner to problems as they occur.lWhile management may still not know the details of what is happening in each black box,the work products and checkpoints confirm the process is working.Maturity Level 2:The Repeatable LevellHave installed basic software management processes.lRealistic commitments are made based on experience from previous projects.lAble to track software costs,schedule,and functionality.lRequirements and work products are baselined and controlled.Maturity Level 2:The Repeatable Level 阶段可视阶段可视lThe process of building the software is a series of black boxes where visibility is provided at predefined checkpoints(ex.,milestones).lManagement reacts in a controlled manner to problems as they occur.lWhile management may still not know the details of what is happening in each black box,the work products and checkpoints confirm the process is working.Maturity Level 2:The Repeatable LevelSummary PointslThe customer has greater visibility by being able to review the product at the predefined checkpoints during the software development.lThe capability of the process is now a characteristic of individual projects,but is not yet at the organizational level.可重复级可重复级l过程特征建立了软件项目管理的策略和实施这些策略的规程软件开发和维护的过程相对稳定，已有的成功经验可以被复用，基于已往的成功经验对同类的新项目进行规划和管理过程管理的策略主要针对项目建立的，而不是针对整个组织来建立的。软件项目经理负责跟踪成本，进度和软件功能，确定其中的问题。问题出现时，有能力识别及纠正。其承诺是可以实现的。为需求和相应的工作产品建立基线来标志进展、控制完整性定义了软件项目的标准，能保证项目准确地执行它通过与转包商合作建立有效的供求关系项目的成功不仅依赖于个人的能力还得到了管理层的支持重视管理和依靠管理重视人员的培训工作建立技术支持活动，并有了稳定的计划可重复级可重复级l工作组系统测试组，软件评估组软件质量保证组，软件配置管理组合同管理组，文档支持组，培训组l度量每个项目建立资源计划。主要是关心成本、产品和进度。有相应的管理数据l改进方向不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中。从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础。建立软件工程过程小组（SPEG)长期承担评估与调整软件过程的任务，以适应未来软件项目的要求。积累数据：建立组织的软件过程库及软家过程相关的文档库l加强培训Maturity Level 3:The Defined LevelAn organization at the Defined Level:lBuilds a standard process or set of processes for developing and/or maintaining software which is then used across the organization.Becomes the organizations standard software process.Defines both the management process and the software engineering process and integrates them into a coherent whole.lBuilds the software project management process upon the software project management processes from Level 2.Maturity Level 3:The Defined LevellCreates a group within the organization responsible for software process activities,sometimes called a Software Engineering Process Group(SEPG).lEstablishes an organization-wide training program to ensure that staff has the necessary skills and knowledge to be able to fulfill their roles.lHas the projects tailor the standard software process to meet their own specific needs.This is referred to as the projects defined software process.lHas management who have good insight into the progress of the project.Maturity Level 3:The Defined Level 活动可视活动可视lThe internal structure of each black box(i.e.,the tasks)are visible to all.lThe internal structure represents how the organizations defined software process is applied to the project.lManagement prepares proactively for risks that may arise.Maturity Level 3:The Defined LevelSummary PointslThe customer can now get accurate and rapid status updates because of the greater visibility into the well-defined process.lThe process capability is now a characteristic of the organization as a whole,which is then tailored to meet the needs of specific projects.已定义级已定义级l过程特征整个组织全面采用综合性的管理及工程过程来管理。软件工程和管理活动是稳定的和可重复的，具有连续性的整个组织的软件管理和软件工程的过程都已标准化，文档化，并综合成有机的整体，成为组织的标准软件过程软件过程标准被应用到所有工程中，用于编制和维护软件。有的项目也可根据实际情况，对软件开发组织的标准软件过程进行裁减。再从事一项工程时，产品的生产过程、花费、计划以及功能都是可以完全控制的，从而软件质量也可以控制。软件过程起到了预见及防范问题的作用，能使风险的影响最小化软件工程过程组(SPEG)负责软件过程活动在全组织范围内安排培训计划。有计划地按人员的角色进行培训在整个组织内部的所有人对于所定义的软件过程的活动、任务有深入理解。大大加强了过程能力在定性基础上建立新的评估技术。已定义级已定义级l工作组除具有前一级的工作组外还增加了以下工作组：软件工程过程组软件工程活动组软件估计组l度量在全过程中收集使用数据在全项目中系统性地共享数据l改进方向开始着手软件过程度量分析，以达到定量地控制软件项目过程地效果通过软件的质量管理达到软件的质量目标Maturity Level 4:The Managed LevelAn organization at the Maturity Level:lSets quantitative quality goals for both the software process and products.lEstablishes a organization-wide software process database to collect analyze and store data from the projects.lUses measurements to establish a quantitative foundation in order to evaluate software processes and products.lUses measurements to understand the process capabilities and performance and determine the quantitative boundaries.lCan begin to identify variations in process performance as to whether it is just random noise or some actual problem.Maturity Level 4:The Managed Level 过程可视过程可视lManagement now is able to manage the risks involved in moving up the learning curve of a new application domain.lThe software processes within the black boxes are now instrumented and controlled quantitatively.Maturity Level 4:The Managed LevelSummary PointslThe customer can now establish a quantitative understanding of the process capability and risk before the project begins.lThe process capability is not only well-defined,it is now quantifiable and predictable because the the process is being measured and operates within quantitative limits.lThe organization can now predict trends in process and product quality within the quantitative bounds of the known limits.lWhen these quantitative limits are exceeded,the organization can take quick action and correct the situation.已管理级已管理级l过程特征制定了软件过程和产品质量的详细而具体的度量标准。软件过程和产品质量都可以被理解和控制可以预见软件过程和产品质量的一些趋势。一旦质量经度量后超出这些标准或是有所违反，可以采用一些方法去纠正，以达到良好的目标开始定量地认识软件过程。软件组织的能力是可预见的。原因是软件过程是被明确的度量标准所度量和操作的。不言而喻，软件产品的质量就可以预见和得到控制。组织的度量工程保证所有项目对生产率和质量进行度量具有良好定义及一致的度量标准来指导软件过程，并作为评价软件过程及产品的度量标准在开发组织内已建立软件过程数据库，保存收集到的数据，可用于各项目的软件过程软件过程变化较小，一般在可接受的范围内每个项目中存在强烈的群体工作意识。因为每人都了解个人的作用与组织的关系，因此能够产生这种群体意识不断地在定量基础上评估新技术已管理级已管理级l工作组除具有前一级的工作组外还增加了以下工作组：软件相关组定量过程管理活动l度量在全组织内进行数据收集与确定度量标准化数据用于定量地理解软件过程及稳定软件过程l改进方向缺陷防范。不仅在发现了问题时能够及时改进，而且应采取特定行动来防止将来出现这类缺陷主动进行技术改革管理，标识，选择和评价新技术，使有效的新技术能在开发组织中施行进行过程变更管理。定义过程改进的目的，经常不断地进行过程改进Maturity Level 5:The Optimizing LevelSummary PointslThe customer works with the supplier in a collaborative manner to establish a strong client-supplier relationship.lThe organization is characterized by a culture of continuous improvement.lContinuous improvement is a way of life.Maturity Level 5:The Optimizing LevelAn organization at the Optimizing Maturity Level:lIs focused on continuous improvement.lCan identify weaknesses and deal with them proactively.lCan introduce new technologies in a controlled and managed manner using data.lCan make changes to the organizations software process in a controlled and managed manner using data.lCan identify innovations that exploit the best software engineering practices and transfer them throughout the organization.lHas software teams that practice defect prevention as a way of life.Maturity Level 5:The Optimizing Level 过程可控过程可控lThe black boxes can now be removed and new and improved black boxes can be introduced.lNew ways of doing things are continually tried in a controlled and managed manner to improve the way software is built.lDisciplined change is now a way of life for all.lManagers are able to effectively estimate and then track the impact and effectiveness of change.优化级优化级l过程特征整个组织特别关注软件过程改进的持续性、预见及增强自身。防止缺陷及问题的发生。不断地提高他们的过程能力加强定量分析，通过来自过程的质量反馈和吸收新观念、新科技，使软件过程能不断地得到改进根据软件过程的效果，进行成本/利润分析，从成功的软件过程实践中吸取经验，加以总结。把最好的创新业绩迅速向全组织转移。对失败的案例，有软件过程小组进行分析以找出原因找出过程的不足并预先改进。把失败的教训告知全体组织以防止重复以前的错误在全组织内推广对软件过程的评价和对标准软件过程的改进不断地改进软件过程要消除“公共”的无效率根源，防止浪费的发生。尽管所有级别都存在这些问题，但这是该级的特点整个组织都存在自觉的强烈的团队意识每个人都致力于过程改进。要力求减少错误率追求新技术，利用新技术。实现软件开发中的方法和新技术的革新防止出现错误，不断提高产品的质量和生产率优化级优化级l工作组除具有前一级的工作组外还增加了以下工作组：软件相关组缺陷防范活动协调组技术改革管理活动组软件过程改进组l度量利用数据来评估，选择过程改进l改进方向保持持续不断的软件过程改进按照按照CMM模型进行的过程改进模型进行的过程改进l软 件 过 程 改 进 的 方 法 论 软软 件件 过过 程程 改改 进进 的的 IDEAL 模模 型型 修 改 组 织 的 方 法 记 录 和 分 析 教 训 定 义 过 程 和 度 量 计 划 及 执 行 试 行 方 案 计 划，执 行 和 跟 踪 改 进 方 案 建 立 过 程 行 动 组 做 行 动 计 划 设 定 战 略 和 优 先 级 提 出 建 议 并 记 录 阶 段 成 果 评 估 当 前 实 践 情 况 改 进 动 机 确 定 改 进 范 围 以 及 获 取 支 持 建 立 改 进 机 制 诊 断 建 立 行 动 扩 充 初 始 化 CMMIlCMMI 是由美国卡内基梅隆大学软件工程研究所（SEI）于 1999 年发布的新一代能力成熟度模型。那么 CMMI 相对于人们熟悉的 SW-CMM 有些什么异同？其变化的原因是什么？SW-CMM 到 CMMI 的过渡是势在必行的吗？针对这些问题，本文将 SW-CMM 与 CMMI 从多个方面和不同的层次进行了对比，剖析了其演变的原因，探讨了其发展前景，并对于企业从 SW-CMM 到 CMMI 的过渡提出了切实可行的建议。模型的演变模型的演变 l第一个 CMM 版本于 1991 年发布，是面向软件的，称为 SW-CMM.。从此以后，SEI 在原有的基础上又衍生出了一系列能力成熟度模型。其中比较重要的包括：系统工程能力成熟度模型（System Engineering Capability Maturity Model,SE-CMM）,软件获取能力成熟度模型（Software Acquisition Capability Maturity Model,SA-CMM），人力资源成熟度模型（People Capability Maturity Model,P-CMM），集成产品开发能力成熟度模型（Integrated Product Development Capability Maturity Model,IPD-CMM）。l这些模型各自面向不同的领域，具有不同的用途。但因为是在同一个模型的基础上发展起来的，它们在过程域（Process Area）等方面有一定重叠，而表现形式却又有不同之处。系统工程能力成熟度模型是“连续式”（Continuous），而其它能力成熟度模型采用了“阶段式”（Staged）。尽管这些模型都非常有用，但当一个组织（Organization）使用了其中多个模型的时候，会随之带来一些问题。首先，组织往往希望将自身持续改进的努力集中在组织内部所有的领域上，而这些各自有特定领域的模型之间的区别（包括体系结构、内容和方法）将会使这种努力落空。其次，在一个组织内部实施多个模型，而不将它们集成到一起，将会导致培训、评估和改进等方面的开销增加。另外，在实际应用中对于 CMM 诸模型本身也存在很多争议。l其一，CMMs 的关键过程域（Key Process Area，KPA）主要的关注点是活动（Activities），而不是开发结果（软件产品）或记录真正目标产品的相关工程结果，也不强调体系结构、设计过程、评估过程和使用过程等。l其二，有人认为 CMMs 过度地强调了同级评审（Peer Review）、检查（Inspection）和传统的质量保证控制方法，这些方法虽然有用，但难以发现体系结构等方面的重大缺陷。l其三，实施了 CMMs 的组织产生了更多的文件、检查点、结果、可追溯性、以及更多的检查和计划、更厚的文档，这与当今降低复杂性和减少“人造”材料等提高软件经济效益的途径格格不入。虽然这些是 CMMs 作为一种重载（Heavy-load）软件过程的必然产物，但 CMMs 的使用者们仍然期望着在这方面能有所改进。在这样的环境下，融入了软件工程领域新的经验和理论的 CMMI 应运而生。CMMI 的体系框架的体系框架 源模型 lCMMI 的源模型有三个：（1）软件能力成熟度模型 V2.0 版，C 草案；（2）电子行业协会临时标准 731（Electronic Industries Alliance Interim Standard 731）；（3）集成产品开发能力成熟度模型 V0.98 版；l此外，SEI 在开发 CMMI 时还注意到了与国际标准化组织和国际电工委员会的 15504 技术报告（ISO/IEC 15504）相兼容和一致。知识领域知识领域 lCMMI 框架的内容涉及四个知识领域：l系统工程：系统工程：系统工程涵盖了一个系统所有的开发工作，其中可能包括、也可能不包括软件。它关注于将客户提出的需求、期望以及限制条件转化到产品的解决方案中，并且在产品的整个生命周期中对解决方案给予始终的支持。l软件工程：软件工程：软件工程的对象是软件系统的开发。它关注于将系统的、条理的、可量化的方法应用到软件的开发、运行和维护中。l集成的产品和过程开发（集成的产品和过程开发（IPPD IPPD）：）：IPPD 是一种系统的方法，指在产品的生命周期中通过所有相关人员和部门的合作，更好地满足客户的需要、期望和要求。支持 IPPD 的过程都是与组织中其它的过程紧密结合的，仅仅只有 IPPD 的过程域、特定目标（Specific Goals）、特定实践（Specific Practices）是无法实现 IPPD 的。l供应商来源（供应商来源（Supplier Sourcing Supplier Sourcing）：）：随着工作越来越复杂，项目有时候需要特定的供应商来实现功能或对产品进行修改。当这一点对于项目很关键的时候，如果项目能够增强对供应商的分析，并在产品交付以前对供应商的行为进行监督，那么项目将受益匪浅。供应商来源（SS）关注的就是如何在这种情况下从供应商处获得合格产品。l在以上知识领域中，企业可以任意选择，也可以都选择。IPPD 和 SS 主要是配合软件工程和系统工程的内容使用。例如，纯软件商可以选择软件工程的内容；设备制造商可以选择系统工程和软件工程的内容；系统集成商可以选择系统工程、软件工程和 IPPD 的内容。相对 SW-CMM 只涉及软件工程来说，CMMI 的覆盖面和适应面更广、更全面、更灵活。这种演变基于这样一种思想：在适当抽象的前提下，项目管理和过程管理的理论其实可以用于多个学科，软件工程的过程也可以用于多种其它工程形式。表达方式表达方式 lSW-CMM 的表达方式（Presentation）是阶段式的，而 CMMI 的表达方式包括了阶段式和连续式两种。lCMMI 的阶段式类似于 SW-CMM，将所有的过程域按 5 个成熟度等级来组织，从低到高分别为：初始级（Initial）（第 1 级）、已管理级（Managed）、已定义级（Defined）、量化管理级（Quantitatively Managed）和优化级（Optimizing）（第 5 级）。整体来看，这样的组织方式除了名称略为有些变化之外，各个成熟度模型等级代表的能力成熟度与 SW-CMM 对应等级相比都是大同小异的。lCMMI 的连续式则使用能力等级来衡量单个的过程域，从低到高分别有：未完成级（Incomplete）（第 0 级），已实施级（Performed），已管理级（Managed），已定义级（Defined），量化管理级（Quantitatively Managed）和优化级（Optimizing）（第 5 级）等 6 个等级。l连续式与阶段式所包含的过程域是完全一致的。两者的区别主要在于过程域的组织方式不同，阶段式是用来描述组织整体上的成熟度，而连续式关注的是组织单个过程域的能力。如果组织注意力主要集中在某几个过程域上时，则采用连续式比较合适。l在 CMMI 框架内，由不同的知识领域和不同的表达方式可以构成多个 CMMI 模型。当组织需要选择一种 CMMI 模型时，必须要根据自己的过程改进的实际情况确定使用那一种表达方式，并且要确定需要用到哪一个或者哪一些知识领域。模型构成成分构成成分模型构成成分构成成分 l阶段式 l阶段式的模型构成成分构成成分主要有：能力成熟度等级、过程域、一般目标（Generic Goal）、特定目标（Specific Goal）、一般实践（Generic Practice）、特定实践（Specific Practice）以及用于组织一般实践的公共特性（Common Feature）。阶段式表达方式各构成成分之间的关系阶段式表达方式各构成成分之间的关系 特点特点 与 SW-CMM 的结构相比，CMMI 的模型结构显得更加复杂与精细。CMMI 从过程域所有的实践提炼出了多个过程域所共有的实践，称为一般实践，将其目标称为一般目标，其余特定于某个过程域的实践与目标称为特定实践与特定目标。这样模型取得了相对 SW-CMM 更高的抽象度与适应范围。目标（一般目标与特定目标）首次作为模型构成成分出现，这表明 CMMI 对过程活动的结果投入了更多的关注。在 CMMI 中删除了 SW-CMM 中的公共特性度量与分析（Measurement and Analysis），并用一个单独过程域组织相关的内容。这样既避免了 SW-CMM 中对每个关键过程域都有度量要求所带来的不一致和精力的浪费，又 降低了对度量的要求和实施的难度，且更具有全局性和可实施性。关键过程域（连续式）关键过程域（连续式）SW-CMM 的模型构成成分的模型构成成分 过程域过程域 l连续式的模型构成成分与阶段式的主要构成成分差别不大，只是成熟度等级换成了能力等级，没有公共特性，并且由于连续式是针对单个过程域，因此构成成分不是围绕等级来组织的，而是围绕过程域来组织的。图 3 显示了它们之间的关系：lCMMI 总共有 25 个过程域，连续式与阶段式的过程域完全一致，与 SW-CMM 相比，数量上多了 7 个过程域。虽然大部分的过程域都有所变化，但主要的改动集中在等级 3 的过程域中。这一层新增加了 7 个过程域，与原来 SW-CMM 等级 3 中的过程域一起进行了重新划分，形成了一个更细致，更实际，更符合软件工程发展方向的成熟度等级。图 4 将 CMMI 和 SW-CMM 各等级的过程域进行了一个对比：2级比较级比较3级比较级比较4、5级比较级比较lCMMI 加强了对工程化过程的重视，将软件产品过程细分为 5 个单独的过程域。需求的重要性在 CMMI 中得到了进一步的强调。除了等级 2 中需求管理（Requirements Management）过程域外，在等级 3 中新增加了需求开发（Requirements Development）过程域。它是从 SW-CMM 软件产品工程（Software Product Engineering）过程域中的一个实践提升而成的。lCMMI 对比 SW-CMM 更加强调了对风险的管理，在 SW-CMM 中风险只是关键过程域软件项目计划（Software project planning）中的一个活动，而在 CMMI 中风险管理成为一个单独的过程域。lCMM 中的一个关键过程域组间协调（Intergroup coordination），在 CMMI 中地位下降，只是作为综合项目管理（Integrated Project Management）中的一个目标。lSW-CMM 中的关键过程域同级评审（Peer Review），在 CMMI 中得到了更高的抽象，对应 CMMI 的验证（Verification）。实施实施 CMMI CMMI 取代 SW-CMM 和其它一些模型是大势所趋。那么对于一个企业来说，什么时候比较合适实施 CMMI 呢？如果企业还没有实施 SW-CMM 或者其它的一些模型，那么可以立即开始着手 CMMI，这样避免了以后再从其它模型转换过来的麻烦。如果企业正在实施其它模型，并且即将达到预期的目标，那么等到目标实现以后再转换到 CMMI 比较合适，并且当前模型的许多东西可以在今后的 CMMI 中重用。另外，企业还必须根据自身的实际情况选择使用阶段式 CMMI，还是 CMMI 连续式。如果选择阶段式 CMMI，还要确定自己最终想要到达的成熟度等级是什么。总结总结lCMMI 是在取得巨大成功的 SW-CMM 基础上发展起来的，它是软件工程界智慧的结晶。它继承并发扬了 SW-CMM 的优良特性，借鉴了其它模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其它工程领域。代表了当今软件工程发展的趋势。referencesl万永刚，洪玫，刘月钟，四川大学 计算机学院，CMMI 与 SW-CMM 对比研究 CMM不是l目标管理；l软件过程；l可操作的具体事务；l通过描述“怎样做”来指导过程改进的；CMM的效果的效果l美国国防部的统计是：在CMM之前，平均28个月的进度推迟了20个月。（CMMSEI.2）部分资料：（部分资料：（CMMSEI.50）Haughes(软件工程部基础系统组)报道了从CMM2（1987年）到CMM3（1991年）的过程，花费了44.5万美元历时两年多时间（？）实现了每年减少200万美元的支出，实现了4.5：1的回报投资比。Tinker投资了46.2万美元并获得了290万的回报，6.35：1。Schlumberger由40万行程序的0.22/KSLOC提高到70万行程序的0.13/KSLOC；客户报告的缺陷从25%降低到10%（作者注：发现缺陷提前了）；生产率增加了两倍以上；满足进度要求的项目从51%增长到94%。Raytheon的重复工作费用从41%降低到11%。典型的回报投资比是7：1,平均年生产率递增37%，测试前发现缺陷比例年均增长18%，投放市场时间减少19%，现场错误报告年均降低45%。部分资料：（部分资料：（CMMPOST.230）Raythoon公司现有400名软件开发人员，公司用了进5年的时间，将其成熟度从CMM1提升到CMM3,已经收到了明显的效果。为了提升到较高的级别，公司所花费的投资与五年来因成本降低所收到的效益之比为1：8，直接生产效率提高了大约14倍。该公司所开发的产品在成熟度提升前每千行错误率为0.31，提高后仅为0.03。无形好处：（无形好处：（CMMSEI.51）提高了雇员的士气；改进了日常工作的质量；减少了超时工作时间；更稳定的工作环境；降低了人员调动频率；改进了通信状况；改进了客户报告的质量；CMM的评估l评估过程（适用于评估过程（适用于SPI和和SCE）（）（CMMSEI.48）选择评估小组；回答成熟度问卷；进行响应分析；现场访问、会谈和文档评审；提出基于CMM的调查结果清单；制作KPA剖面图（显示了该机构在哪些区域已满足，在哪些区域还没有满足KPA的目标）；lSPA即软件过程评估，在评估中，一组经过培训的软件专业人员确定出一个企业软件过程的状况，找出该企业所面对的与软件过程有关的、需继续解决的所有问题，以便取得企业领导层对软件过程改进的支持。（CMMPOST.15）lSPI是在开放、合作的环境中进行的，评估的目的在于暴露问题和帮助管理人员和工程师改进它们所在机构的软件过程。评估能否成功取决于管理部门和专业人员两方面对改进机构的支持。（CMMSEI.49）lSCE是在更为面向审计的环境中进行的。评价的结构将影响挑选承制方或投放资金。(CMMSEI.50)l一般来说，从等级1到等级2可能需要用几年的时间，而在其他等级间通常花费2年时间。（CMMPOST.41）l国内最少8个月CMM的角色（CMMSEI.37）l软件工程组软件工程组SEG，Software Engineering Group，负责一个项目的软件开发和维护活动（需求分析、设计、编程和测试）的人员，包括管理人员和技术人员。l软件相关组软件相关组SRG，Software Related Groups，当涉及到此术语时，要根据前后文确定是哪些组，可能是质量保证组、软件配置管理组等。l软件工程过程组软件工程过程组SEPG，Software Engineering Process Group，按软件工程方法制定软件过程的专家组。l系统工程组系统工程组SEG，System Engineering Group，负责说明系统需求，分配系统需求到硬件、软件和其他部件，规格说明硬件、软件和其他部件之间的接口，并监督这些部件的设计和开发，以确保符合规格。l系统测试组系统测试组STG，System Test Group，负责计划和实施对软件的单独系统测试，以确定其软件产品是否满足其需求；l软件质量保证组软件质量保证组SQAG，Software Quality Assurance Group，负责计划和实施项目的质量保证活动，以确保软件开发活动遵循软件过程规程和标准（作者注：注意并不是保证软件是高质量（作者注：注意并不是保证软件是高质量的）的）。l软件配置管理组软件配置管理组SCMG，Software Configuration Management Group，负责计划、协调和实施项目的正规配置管理活动。l培训组培训组TG，Training Group，协调和安排机构的培训活动。CMM的要求的要求l独立性和机构结构独立性和机构结构：SQA组可越过项目负责人、项目软件过程组和其他软件相关组向上级管理部门进行报告（CMM2软件质量保证KPA的约定1.2）。（CMMSEI.38）l为执行SQA任务的人员在机构范围内提供充分的自由，使其成为项目的上级管理部门的“眼睛和耳朵”；l当项目外有增加偏差的需要时，谨防执行SQA任务的人员执行相反的个人行为（？）；l能如实地向上级管理部门汇报有关项目产品和软件过程方面的客观信息。测试小组可不依赖软件开发人员，计划和准备系统和验收测试用例以及测试规程。（CMM3软件产品工程KPA的活动7.3）（CMMSEI.38）在CMM的实施中组织机构的设计必须完善，但不等于说每个机构必须是独立的。有些组织很小时，机构可以适当合并，成员可以身兼数职。但对于那些关键实践要求独立性时，组织必须十分小心。例如，软件质量保证组的独立性就是必须给予考虑的，否则在技术上或机构上出现的偏差，会直接影响到软件过程。（CMMPOST.50）CMM的要求（续）的要求（续）l文档和文档和CMM KP描述了一些和过程相关的文档，但并不要求这些文档和实际项目工作工程之间有一一对应的关系。KP只是要求这些文档的可用内容成为机构或项目书面工作结果的一部分。（CMMSEI.43）l共同特征共同特征：每个KPA都有5个共同特征：执行约定，执行能力，执行活动，测量和分析，验证实现。（CMMSEI.24）l管理和控制管理和控制：在一定时间内所使用工作产品的版本是明确的（版本控制），并以受控方式进行修改（更改控制）。（CMMSEI.33）l书面规程书面规程由执行任务或活动的人来决定形式和详细程度。（CMMSEI.32）CMM观点观点l一个步骤被使用的次数越多，其重要性和可用性就越强，结果的可接受程度就越大。（CMMSEI.32）l目前没有普遍适用的软件过程或质量的测量方法。（CMMSEI.33）l对于上级管理部门定期审查，在满足机构需求的前提下，只要有适当的机制来报告异常情况，评审的时间间隔就尽可能长些。（CMMSEI.34）l企业的软件过程能力被作为一项关键因素来考虑。CMM认为保证软件质量的根本途径就是提升企业的软件生产能力，而企业的软件生产能力又取决于企业的软件过程能力，特别是在软件开发和生产中的成熟度。企业的软件过程能力越成熟，它的软件生产能力就越有保证。（CMMPOST.11）l所谓软件过程能力，是指企业从事软件开发和生产的过程本身透明化、规范化和运行强制化。（CMMPOST.11）l一些专业人员，通过多年的对软件开发管理的经验进行分析与研究发现，过程成熟度的焦点问题不是技术问题，而是管理，对需求的变化如何适应都是工程成熟度的关键问题。（CMMPOST.44）l初始级的企业成功的关键就是能否雇佣到并且留住能干的员工及项目经理和开发人员。必须靠企业内个人的竞争意识和英雄主义，而且要想在下一个项目中再次取得成功，就要配备原班人马。（CMMPOST.51）CMM实施实施l从CMM1到CMM2的机构常常要建立SEPG，尽管SEPG是CMM3才必要的特征。（CMMSEI.12）l软件过程也可以开发和维护，包括：（CMMSEI.39）给出可以确定软件过程的需求说明；给出一种层次结构和设计方法，该方法能够对如何定义软件过程提供信息；在项目或机构中实现软件过程设计；对软件过程说明的有效性进行测量；将制定的软件过程在机构或项目范围内推广；抽象管理体系模型抽象管理体系模型SQA过程域过程域l软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。成熟度等级成熟度等级过程能力过程能力关键过程域关键过程域目标目标共同特点共同特点实施或规范化实施或规范化关键实践关键实践基础设施及活动基础设施及活动阶段式表达方式各构成成分之间的关系阶段式表达方式各构成成分之间的关系 目标：l1 软件质量保证活动有计划。l2 软件产品和活动与适当的标准、过程和需求的一致性被客观的证明。l3 把软件质量保证活动的结果告知受影响的组和个人。l4 如果在软件项目中不能解决不一致的问题，则要把提交给高层管理人员。承诺l工程遵循一个已写下的机构方针，这样才可已进行软件质量保证活动。前提条件l1 存在一个软件质量保证组。l2 有足够的资金和资源。l3 软件质量保证组的成员要经培训，才可进行软件质量保证活动。l4 软件工程组的成员接收软件质量保证组的指导。活动l1 根据文档化的规程，要为软件项目准备一个软件质量保证的计划。l2 软件质量保证组根据软件质量保证计划来进行相应的活动。l3 软件质量保证组参与准备和评审软件项目的开发计划、标准和过程。l4 软件质量保证组评审软件工程活