软件工程实践(11)CMM&CMMI.ppt

软件工程实践,第十一讲,软件能力成熟度模型（SW-CMM）集成能力成熟度模型（CMMI）介绍,目的,了解SW-CMM和CMMI的提出背景和思想 掌握SW-CMM 1.1提出的5个等级的基本含义掌握SW-CMM 1.1模型的基本结构了解5个等级相关的关键过程区域掌握CMMI1.1的基本结构,内容,SW-CMM的提出SW-CMM的结构SW-CMM的关键过程区域CMMI的提出CMMI的结构CMMI的过程区域,SW-CMM和CMMI的提出,质量的杠杆作用点,每个人都体会到主动积极的优质劳动力的重要性，但是,如果不理解过程，或者过程不是在“最佳实践”下运行，即使我们的精英也无法使工作达到最佳的状态,人员,过程,技术,过程是产品成本、进度和质量的主要决定因素,项目成功的支柱,过程管理,技术资产,人力资源,客户供应商关系,什么是过程,如何定义过程？,过程的一般定义,过程是指为了达到给定目的而执行的实践的集合；它可能包括工具、方法、资料和/或人过程是指为了达到给定目的而执行的一系列活动的有序集经常将过程描述成是三元组“过程人员技术”中的一个元素，也可以认为它是联合其它元素的“粘合剂”,人员,技术,过程,过程是三个杠杆作用点之一,过程改进的基本前提,“产品质量主要取决于用于开发和维护该产品的过程的质量”。基于Shewhart,Juran,Deming和Humphrey倡导的TQM原理,早期的过程改进,过程管理理论是Deming，Crosby，Juran以及其他一些人的概念的综合在过去的30年里，这些理论已经用于解决许多组织的共同问题虽然已经有了解决方案，但是现有的实践水平与技术发展水平之间仍有一定的差距其中的许多概念已经用于建立过程改进模型,软件过程外行的观点,该过程的潜在问题,开发队伍角色未定义，不协调团队工作和过程绩效由于执行的间隙和冲突而削弱对过程和产品质量的洞察有限对产品配置的控制有限 发行比原始进度推迟 成本比估计的大得多 软件不是客户所需要得,软件过程内行的初步观点,描述,编码,观察能否工作,因素特征管理相关没有觉察，太忙项目成员差的培训，缺乏经验，没有组织开发过程未定义，任意管理类型危机管理产品质量没有度量产品配置没有控制项目成功依赖于英雄,不成熟组织的共同特征,不成熟组织产生的共同结果,因素 结果需求 缺乏控制，需求“不断懦动”产品性能 不可预估，不能满足用户需要产品配置 没有管理 产品质量 不可知，充满缺陷成本 缺乏追踪，经常超越进度 经常延迟,早期的过程改进,过程管理理论是Deming，Crosby，Juran以及其他一些人的概念的综合在过去的30年里，这些理论已经用于解决许多组织的共同问题虽然已经有了解决方案，但是现有的实践水平与技术发展水平之间仍有一定的差距其中的许多概念已经用于建立过程改进模型,什么是过程模型？,模型是描述有效过程特征的元素的结构化集合这里所涵盖的过程是指那些通过经验证明为有效的过程,如何使用模型？,模型是用来：帮助建立过程改进的目标和优先次序，协助改进过程，并为确保建立一个稳定的、有能力的以及成熟的过程提供指南作为组织过程改进的指南,模型为什么重要？,模型提供了过程改进的出发点社团过去经验的结晶共同的语言和共享的构想活动优先次序的框架,模型,“所有的模型都是错误的，但有些是有用的。”“All models are wrong,but some are useful.”George Box提供对真实世界认识的简单近似,使用什么模型？,从历史的角度讲，是以学科建立模型，如：软件工程系统工程软件获取系统安全，等等,CMM的产生背景,美国国防部在向承包商发包军用软件项目时，希望了解承包商的开发能力，以保证项目的成功和产品质量美国国防部委托美国卡内基-梅隆大学的软件工程研究所（CMU-SEI）进行研究SEI基于项目成功很大程度依赖于其开发过程的经验，提出包含5级的软件能力成熟度模型（SW-CMM）美国国防部要求其承包商的能力成熟度至少为3级,CMM的产生历程,1987年美国软件工程研究所(SEI）以W.S.Humphrey为首的研究组发表的“承包商软件工程能力的评估方法”1991年发展为SEI CMM1.0（能力成熟度模型1.0版）1993年该模型发展为SEI CMM 1.1（现行有效）,CMM的基础,阶段化结构：基于过去60年来的产品质量原则。Walter Shewart在三十年代发表了统计质量控制原理。W.Edwards Deming 和Joseph Juran 又进一步发展和论证了该原理。成熟度框架：Philip Crosby在“Quality is Free”中描述了质量管理成熟度框架的五个进化阶段。IBM等的工程实践。,基于CMM过程改进的收益（不完全）,什么是CMM？,能力成熟度模型 一个在特定学科中的成熟实践的参考模型，用于评估一个组履行该学科任务的能力CMM有不同模型，从以下不同的方面来区分：学科（软件、系统、获取等）结构（阶段和连续式）成熟度的程度（过程改进的路线）能力的程度（制度化）软件工程研究所（SEI）的“能力成熟度模型”和CMM是一种成熟度模型。能力成熟度模型、CMM、CMM Integration和CMMI是卡内基梅隆大学的服务标志和注册商标,IDEALSM 模型,SW-CMM的结构,软件过程术语,人们用于开发和维护软件及其相关产品(例如，项目计划、设计文档、代码、测试用例、用户手册等等)的一系列活动、包括软件工程活动和软件管理活动。,软件过程能力术语,描述（开发组织或项目组）通过遵循其软件过程能够实现预期结果的程度。一个软件开发组织或项目组的软件过程能力提供一种预测该组织承担下一个软件项目时最可能的预期结果的方法。软件过程能力既可对整个软件开发组织而言，也可对一个软件项目组而言。软件过程性能：表示（开发组织或项目组）遵循其软件过程所得到的实际结果。,软件过程成熟度术语,一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。成熟度可指明一个软件开发组织软件过程能力的增长潜力。随着软件组织的软件过程成熟度的提高，开发组织通过其方针、标准和组织机构等将其软件过程规范化和具体化。从而使得开发组织明确定义的有关管理和工程的方法、实践和规程等在现有人员离去后仍能继续下去。,软件过程能力成熟度等级术语,软件开发组织在走向成熟的途中几个具有明确定义的表征软件过程能力成熟度的平台。每一个成熟度等级为过程继续改进达到下一个等级提供一个基础。每一等级包含一组过程目标，当其中一个目标被达到时，就表明软件过程的一个（或几个）重要成分得到了实现，导致组织的软件过程能力增长。,软件能力成熟度模型术语,对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步前进。这个模型使软件组织能够较容易地确定其当前过程的成熟度并识别出其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略；软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步地改善其全组织的软件过程。,CMM软件过程能力成熟度的5个等级,软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力。已建立基本的项目管理过程去跟踪成本、进度和功能性。必要的过程纪律已经到位，使类似得应用项目，能重复以前的成功。管理活动和工程活动两方面的软件过程均已文档化、标准化、并集成到组织的标准软件过程。全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的剪裁版本。已采集详细的有关软件过程和产品质量的度量数据。无论软件过程还是产品均得到了定量了解和控制。利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息，使持续的过程改进成为可能。,CMM软件过程能力成熟度的5个等级（图示）,2.可重复,1.初始,3.已定义,4.已管理,严格执行的过程,标准、一致的过程,可预估的过程,连续改进过程,不可预估和缺乏控制,可以重复以前熟练的任务,过程特征化，容易理解,过程被度量和控制,集中于过程改进,5.优化,项目管理,集成工程过程,产品和过程质量,管理更改,结果,关键过程区域,级别,特征,优化 Continuous process Process change management(5)capability improvement Technology change management Defect prevention已管理(4)已定义 Software process defined(3)and institutionalized to provide product quality control可重复(2)初始l(1),Product quality planning;Software quality managementtracking of measured Quantitative process managementsoftware process,Management oversightand tracking of project;stable planning andproduct baselines,关键过程区域,定制(成功依赖于英雄),“人员,风险,生产率&质量,Software configuration management Software quality assurance Software subcontract management Software project tracking&oversightSoftware project planningRequirements management,Peer reviews Intergroup coordinationSoftware product engineering Integrated software managementTraining programOrganization process definitionOrganization process focus,SEI 能力成熟度模型,管理 机构 工程5 优化级 技术更新管理 过程更新管理 缺陷预防4 已管理级 定量软件管理 软件质量管理3 已定义级 集成软件管理 组织过程焦点 软件产品工程 组间合作 组织过程定义 同行评审 培训大纲2 可重复级 需求管理 软件项目策划 软件项目 追踪与监督 软件子合同管理 软件质量保证 软件配置管理1 初始级 定制的过程,管理可视性 过程能力,Out,In,1,2,3,4,5,概率,Time/$/.,Target,N,N+a,N-x,N-y,N-z,级别,初始级图示,初始级行为特征（1）,在初始级上组织一般不提供开发和维护软件的稳定环境。当组织中缺乏健全的管理实践时，不适当的规划和反应驱动体系会降低由良好的软件工程实践所带来的效益。,初始级行为特征（2）,在危机时刻，项目一般抛弃预定的规程，回复到仅作编码和测试。成功完全依赖于有一个杰出的经理及一支有经验的、战斗力强的软件队伍。偶尔，有能力的、坚强的软件经理能经受住要他们在软件过程中走捷径的压力，但是当他们离开项目后，他们能使过程稳定的影响也随之消失。甚至一个强的工作过程也不能克服由于缺乏健全的管理实践所造成的不稳定。,初始级行为特征（3）,等级1的组织的过程能力是不可预测的，因为随着工作进展软件过程经常被改变或修定（即过程是无秩序的）。进度、预算、功能性和产品质量一般是不可预测的。等级1组织几乎没有明显的稳定的软件过程，只能通过个人的能力而不是组织的能力去预测性能。,可重复级图示,Activity,Results,to produce,Level 2:Think before you act,and think after you act,just to make sure you did it right.,Planning,Evaluation,input to,to improve,可重复级行为特征（1）,在可重复级上，已建立管理软件项目的方针和实施这些方针的规程。基于在类似项目上的经验对新项目进行规划和管理。达到2 级的目的是使软件项目的有效管理过程制度化，这使得组织能重复在以前项目上所开发的成功实践，尽管项目所实施的具体过程可能不同。一个有效过程可特征化为实用的、已文档化的、已实施的、已培训的、已测量的和已改进的。,可重复级行为特征（2）,等级2组织中的项目已经设置基本的软件管理控制。实际可行的项目约定是基于对以前项目的观察结果和当前项目的需求。项目的软件经理跟踪软件成本、进度和功能性；在满足约定方面的问题，一旦出现就被识别。对软件需求和为实现需求所开发的工作产品建立基线，并控制其完整性。软件项目标准均已确定，并且组织能保证准确地执行这些标准。如果有子承包商的话，软件项目与他们一起努力建立一种强有力的顾客供应商关系。,可重复级行为特征（3）,等级2组织的过程能力可概括为有纪律的，因为软件项目的规划和跟踪是稳定的，能重复以前的成功。由于遵循基于以前项目性能所制定的切实可行的计划，项目过程处在项目管理系统的有效控制之下。,已定义级图示,Standards,Activity,Results,to produce,Level 3,Planning,Evaluation,input to,to improve,input to,input to,Use your lessons learned.,已定义级行为特征（1）,在已定义级上，全组织的开发和维护软件的标准过程已文档化，包括软件工程过程和软件管理过程，而且这些过程被集成为一有机的整体（组织的标准软件过程）。等级3上所建立（适当时，经更改）的过程，被用来帮助软件经理和技术人员工作得更有效。组织在使其软件过程标准化时，利用有效的软件工程实践。存在一个负责组织的软件过程活动的组，例如软件工程过程组。实施全组织的培训计划以保证职员和经理具有履行其职责所必须的知识和技能。,已定义级行为特征（2）,项目通过剪裁组织的标准软件过程去建立他们自己定义的软件过程，它说明项目独有的特征（项目定义软件过程）。一个已定义软件过程包含一组协调的、集成的、妥善定义的软件工程过程和管理过程。妥善定义的过程可特征化为具有准备就绪判据、输入、标准、进行工作的规程、验证机制（例如同行评审）、输出、以及完成判据。因为软件过程已妥善定义，管理者就能洞察所有项目的技术进展。,已定义级行为特征（3）,等级3组织的软件过程能力可概括为标准的和一致的，因为无论软件工程活动还是管理活动，过程都是稳定的和可重复的。在所建立的产品基线内，成本、进度和功能性均受控制，对软件质量也进行跟踪。这种过程能力建立在整个组织范围内对已定义过程中的活动、角色和职责的共同理解之上。,已管理级图示,Standards,Activity,Results,to produce,Level 4,Planning,Evaluation,input to,to improve,input to,input to,to forecast,Predict the results you need and expect and then create opportunities to get those results,已管理级行为特征（1）,在已管理级上，组织对软件产品和过程都设置定量的质量目标。作为组织测量大纲的一部分，对所有的项目都测量其重要的软件过程活动的生产率和质量。利用一个全组织的软件过程数据库收集和分析从项目定义软件过程中得到的数据。等级4 上的软件过程均已配备有妥善定义的和一致的度量。这些度量为定量地评价项目的软件过程和产品打下基础。,已管理级行为特征（2）,项目通过将其过程性能的变化限制在定量的可接受的范围之内，实现对其产品和过程的控制。可以将过程性能方面有意义的变化与随机变化（噪声）区别开来，特别在所建立的产品线内。开发新应用领域的软件所带来的风险是已知的，并得到精心的管理。,已管理级行为特征（3）,等级4组织的软件过程能力可概括为可预测的，因为过程是已测量的并在可测的范围内运行。该等级的过程能力使得组织能在定量限制的范围内预测过程和产品质量方面的趋势。当超过限制范围时，采取措施予以纠正。软件产品具有可预测的高质量。,Standards,Activity,Results,to produce,Level 5,Planning,Evaluation,input to,to improve,input to,input to,to forecast,to improve,Create lessons learned,and use lessons learned to create more lessons learned,and use more lessons learned to create even more lessons learned,and use even more lessons learned to create.etc.,优化级图示,优化级行为特征（1）,在优化级，整个组织集中精力进行不断的过程改进。为了预防缺陷出现，组织有办法识别出弱点并预先针对性地加强过程。在对新技术和所建议的组织软件过程的更改进行费效分析时利用有关软件过程有效性的数据。识别出采用最好软件工程实践的技术创新并推广到整个组织。,优化级行为特征（2）,等级5组织的软件项目群组分析缺陷以确定其发生的原因。为了防止已知类型的缺陷再次出现，他们认真评价软件过程，同时将经验教训告知其它项目。,优化级行为特征（3）,等级5组织的软件过程能力可特征化为不断改进，因为这些组织为扩大其过程能力的范围进行着不懈的努力，因而不断改善其项目的过程性能。既通过在现有过程中增量式前进的办法，也通过采用新技术、新方法的革新办法，使改进不断出现。,CMM结构,关键过程区域术语,互相关联的若干软件实践活动和有关基础设施的一个集合。每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程区域，它们的实施对达到该成熟度等级的目标起保证作用，这些过程区域就称为该成熟度等级的关键过程区域。,共同特点术语,共同特点是表明一个关键过程区域的实施和规范化是否有效、可重复且持久的一些属性。关键过程区域按照共同特点进行组织。共有5个共同特点：执行约定、执行能力、执行的活动、测量和分析、验证实施。,关键实践术语,对关键过程区域的实施起关键作用的方针、规程、措施，活动以及相关基础设施的建立。关键实践一般只描述“做什么”，而不强制规定“如何做”。关键过程区域的目标是通过其包含的关键实践的实施来达到的。,成熟度级别,关键过程区域,目标,共同特点,关键实践,2,3,4,5,CMM结构,RM,PP,PT,SM,CM,QA,执行能力,执行的活动,执行约定,测量和分析,验证实施,关键过程区域的过程分类,CMM的关键过程区域,需求管理（L2）,需求管理的目的是在顾客和软件项目之间建立对顾客需求的共同理解，顾客需求将由软件项目处理。与顾客的协议是策划和管理软件项目的基础。对与顾客关系的控制依靠遵循有效的更改控制过程。,需求管理,软件项目策划（L2）,软件项目策划的目的是制定进行软件工程和管理软件项目的合理的计划。这些计划是管理软件项目的必要基础。没有切合实际的计划不可能实施有效的项目管理。,软件项目策划,软件项目追踪与监督（L2）,软件项目追踪与监督的目的是建立适当的对实际进展的可视性，使管理者在软件项目性能显著偏离软件计划时能采取有效的措施。,软件项目追踪与监督,在必要时采取及时的修正行动,软件子合同管理（L2）,软件子合同管理的目的是选择合格的软件子承包商，并有效地管理它们。它把用于基本管理控制的需求管理、软件项目策划、以及软件项目跟踪与监督等关键过程区域所关注的事情与软件质量保证和软件配置管理等过程区域中的必不可少的协调结合在一起，并且当合适时对子承包商实施这项管理。,软件子合同管理,软件质量保证（L2）,软件质量保证的目的是给管理者提供对于软件项目正采用的过程和正在构成的产品的恰当的可视性。软件质量保证是绝大多数软件工程过程和管理过程的不可缺少的部分。,软件质量保证,确定偏离的活动和工作产品,软件配置管理（L2）,软件配置管理的目的是在项目的整个软件生存周期中建立和维护软件产品的完整性。软件配置管理是绝大多数软件工程过程和管理过程的不可缺少的部分。,软件配置管理,软件配置管理,等级2(可重复的)的一个关键过程区域（根据蔡愉祖译稿整理）,概述,软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性。软件配置管理包括标识在给定时间点上软件的配置（即选定的软件工作产品及其描述）,系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。置于软件配置管理之下的工作产品包括交付给顾客的软件产品（例如软件需求文档和代码），以及与这些软件等同的产品项或生成这些软件产品所要求的产品项（例如编译程序）。建立一个软件基线库，当软件基线形成时就将它们纳入该库。通过软件配置管理的更改控制和配置审计功能，系统地控制基线的更改和那些利用软件基线库构造成的软件产品的发行。这个关键过程区域仅包括实施软件配置管理功能的实践。而标识具体的配置项或单元的实践则包含在描述每个配置项或单元的开发和维护的关键过程区域中。,目标,目标1 软件配置管理活动是有计划的。目标2 所选定的软件工作产品是已标识的、受控的和适用的。目标3 对已标识的软件工作产品的更改是受控的。目标4 受影响的组和个人得到软件基线的状态和内容的通知。,执行约定,（1项）,约定1 项目遵循书面的用以实施软件配置管理(SCM)的组织方针。,该方针一般规定：1.明确指派每个项目的SCM职责。2.在项目的整个生存周期内实行SCM。3.对于对外可交付的软件产品、指定的内部软件工作产品和指定在项目内部使用的支持工具（例如编译器）都实行SCM。4.项目建立或可以利用一个仓库，用来存储配置项/单元和相关联的SCM记录。在这些实践中这个仓库的内容称为“软件基线库”。,存取该仓库的工具和规程在这些实践中称为“配置管理库系统”。置于配置管理上并作为单个实体予以处理的工作产品称为配置项。配置项一般分解为配置部件，而配置部件一般分解为单元。在一个硬件/软件系统中，所有的软件可看成一个单个配置项，或者可将该软件分解为多个配置项。在这些实践中术语“配置项/单元”用于指示在配置管理下的元素。5.定期审计软件基线和SCM活动。,执行能力,（5项）,能力1 存在或者建立一个有权力管理项目软件基线的委员会（即软件配置控制委员会SCCB）。,该SCCB：1.审定软件基线的建立和配置项/单元的标识。2.代表项目经理和所有可能受到软件基线更改影响的组的利益。受影响的组的例子有：硬件质量保证组，硬件技术状态（配置）管理组，硬件工程组，制造工程组，软件工程组（包括所有的小组，例如软件设计小组），,系统工程组，系统测试组，软件质量保证组，软件配置管理组，合同管理组，和文档支持组。3.评审和审定对软件基线的更改。4.审定由软件基线库制造的产品的生成。,能力2 存在负责协调和实施项目的SCM的组(即SCM组)。,一个组是负责一组作业或活动的部门、经理、和个人的集合。组的规模可以变化：从一个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日制的个人。建立一个组时应考虑的问题有：指派的作业和活动、项目的规模、组织机构和组织文化。某些组，例如软件质量保证组，集中注意力于项目的活动，而其它组，例如软件工程过程组，集中关注全组织的活动。SCM组协调或实现:1.项目的软件基线库的生成和管理。,2.SCM计划、标准和规程的制定、维护和散发。3.将置于SCM之下的软件工作产品集合的标识。一个工作产品是由定义、维护、或使用一个软件过程所生成的任何人工制品。4.对存取软件基线库的管理。5.软件基线的更新。6.由软件基线库制造的产品的生成。7.SCM行动的记录。8.SCM报告的生成和散发。,能力3 为进行SCM活动提供足够的资源和投资。,1.安排一个经理专门负责SCM。2.使得支持SCM活动的工具合用。支持工具的例子有：工作站，数据库程序，和配置管理工具。,能力4 SCM组的成员在有关进行其SCM活动的对象、规程和方法方面受到培训。,培训的例子包括：SCM标准、规程和方法；和SCM工具。,能力5 软件工程组和其它软件一有关组的成员受到培训以便完成其SCM活动。,其它软件一有关组的例子有：软件质量保证组，和文档支持组。培训的例子有：在软件工程组和其它软件一有关组的内部进行SCM活动要遵循的标准、规程和方法，和SCM组的角色、职责和权力。,执行的活动,（10项）,活动1 按照已文档化的规程对每个软件项目准备一份SCM计划。,这个规程一般规定：1.SCM计划的制定是在整个项目策划的早期阶段，并平行于整个项目策划。2.受影响的组评审SCM计划。3.对SCM计划进行管理和控制。,“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的（即版本控制），而且以受控的方式引进更改（即更改控制）。如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管理的完备的纪律之下，正如在本关键过程区域中所描述的。,活动2 用已文档化的经批准的SCM计划作为进行SCM活动的基础。,该计划包括：1.将进行的SCM活动、活动的日程表、指派的职责和所要求的资源（包括职员、工具和计算机设施）。2.SCM需求和将由软件工程组及其它软件一有关组进行的SCM活动。,活动3 建立一个配置管理库系统作为软件基线的仓库。,该库系统：1.支持SCM的多个控制层次。导致多个控制层次的情况例如：在生存周期的不同时间所需要的控制层次不同（例如，随着产品成熟要更加严密地控制），纯软件系统和既包括硬件又包括软件的系统所需要的控制层次不同。2.提供对配置项/单元的存储和检索功能。3.在受影响的组之间和在库内部的控制层次之间提供配置项/单元的共享和传送。,4.帮助使用配置项/单元的产品标准。5.对配置项/单元的归档版本提供存储和恢复功能。6.帮助保证由软件基线库制造的产品的正确生成。7.对SCM记录提供存储、更新的检索功能。8.支持SCM报告的编制。9.提供对库结构和内容的维护。库维护功能的例子有：库文件的备份/重建，和从库的错误中恢复。,活动4 标识将置于配置管理之下的软件工作产品。,1.基于已文档化的准则选择配置项/单元。可标识为配置项/单元的软件工作产品的例子有：过程一有关文档（例如：计划、标准或规程），软件需求，软件设计，软件代码单元，软件测试规程，为软件测试活动所构造的软件系统，为交付给顾客或最终用户所构造的软件系统，,编译程序，和其它支持工具。2.安排给每个配置项/单元唯一的标志符。3.详细说明每个配置项/单元的特征。4.详细说明每个配置项/单元所属于的软件基线。5.详细说明在开发中将每个配置项/单元置于配置管理之下的时间点。6.标识每个配置项/单元的负责人(即从配置管理的角度来说的所有者)。,活动5 按照已文档化的规程，起动、记录、评审、批准和跟踪对所有配置项或单元的更改请求和问题报告。,活动6 按照已文档化的规程控制对基线的更改。,该规程一般规定：1.进行评审和(或)回归测试以保证更改不会造成对基线的未料到的影响。2.仅仅那些经SCCB批准的配置项/单元才能进入软件基线库。3.以能保持软件基线库的正确性和完整性的方式进行配置项或单元的登入和退出。,登入或退出步骤的例子有：验证修改是经审定的，建立更改日志，保持一份更改拷贝，更新软件基线库，和建立被取代的软件基线的档案。,活动7 按照已文档化的规程生成由软件基线库制造的产品并控制它们的发行。,该规程一般规定：1.SCCB审定由软件基线库制造的产品的生成。2.不论为内部使用或外部使用，由软件基线库制造的产品仅仅由软件基线库中的配置项或单元组成。,活动8 按照已文档化的规程记录配置项或单元的状态。,该规程一般规定：1.足够详细地记录配置管理行动，使每个配置项/单元的内容和状态，都是清楚的并且能恢复以前的版本。2.对每个配置项/单元维护其当前状态并保留其历史(即更改和其它行动)。,活动9 编制用文档记载SCM活动和软件基线内容的标准报告，并使受影响的组和个人可以使用它。,报告的例子包括：SCCB会议记录，更改申请的摘要和状态，问题报告的摘要和状态（包括解决情况），软件基线更改的摘要，配置项/单元的修改历史，软件基线状态，和软件基线审计结果。,活动10 按照已文档化的规程进行软件基线审计。,该规程一般规定：1.为审计作好充分准备。2.评估软件基线的完整性。3.评审配置管理库系统的结构和设施。4.验证软件基线库内容的完备性和正确性。5.验证与适用的SCM标准和规程的符合性。6.向项目软件经理报告审计结果。7.跟踪得自审计的措施条款直至结束。,测量和分析,（1项）,测量1 进行测量并将测量结果用于确定SCM活动的状态。,测量的例子有：每单位时间处理的更改申请数；SCM活动的里程碑的完成情况与计划相比较；和在SCM活动中所完成的工作、花费的工作量和消耗的资金。,验证实施,(4项）,验证1 高级管理者定期参与评审SCM活动。,高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合崐机制，间隔可以长。参考软件项目跟踪和监督关键过程区域的验证1以便找到包括高级管理者监督评审的典型内容的实践。,验证2 项目经理既定期地也事件驱动地参加评审SCM活动。,参考软件项目跟踪和监督关键过程区域的验证2以便找到包括项目管理者监督评审的典型内容的实践。,验证3 SCM组定期审计软件基线以验证它们符合定义它们的文档。,验证4 软件质量保证组评审和审计有关SCM的活动和工作产品，并报告其结果。,参考软件质量保证关键过程区域。至少，评审和审计要验证：1.以下各组对SCM标准和规程的依照情况：SCM组，SCCB，软件工程组，和 其它软件一有关组。2.定期进行软件基线审计的情况。,组织过程焦点（L3）,组织过程焦点的目的是规定组织在改进其整体软件过程能力的软件过程活动方面的职责。组织过程焦点活动的主要结果是一组软件过程财富，它们在组织过程定义中加以描述。正如集成软件管理中所描述的，这些财富供软件项目使用。,组织过程定义（L3）,组织过程定义的目的是开发和保持一组便于使用的软件过程财富，它们能改进横跨项目的过程性能，并且为组织能获得积累性的、长期的得益奠定基础。这些财富提供一组稳定的基本原则，通过诸如培训等机制就能使其成为制度。培训在培训大纲中加以描述。,培训大纲（L3）,培训大纲的目的是培育个人的技能和知识，使他们能有效地和效率高地执行其任务。尽管培训是组织的责任，但是软件项目应该识别出他们所需要的技能，当项目需求独特时，该项目应提供所需要的培训。,集成软件管理（L3）,集成软件管理的目的是将软件工程活动和管理活动集成为一个协调的、已定义的软件过程，该过程是剪裁组织的标准软件过程和组织过程定义中所描述的相关的过程财富而得到的。剪裁基于项目的经营环境和技术需要，正如在软件产品工程中所描述的那样。集成软件管理是从等级2 的软件项目策划与软件项目跟踪与监督进化而得到的。,软件产品工程（L3）,软件产品工程的目的是一致地执行一个妥善定义的工程过程。为了能有效地和效率高地生产正确的、一致的软件产品，该工程过程集成全部软件工程活动。软件产品工程描述项目的技术活动，例如，需求分析、设计、编码和测试。,组间协调（L3）,组间协调的目的是为软件工程组积极参与其它工程组工作制定一种方法，使得项目能更有效地和效率高地满足顾客的需求。组间协调是集成软件管理的一个涉及多科目的方面，它延伸到软件工程之外。不仅应该集成软件过程，而且软件工程组和其它组之间的相互作用也必须加以协调和控制。,同行评审（L3）,同行评审的目的是及早和高效地除去软件工作产品中的缺陷。一个重要的必然结果是增强对软件工作产品和可预防的缺陷的了解。同行评审是一种重要而又有效的工程方法，在软件产品工程中采用此方法，可通过法根（Fagan）式审查、结构化走查、或者其它评审方法加以实施。,定量过程管理（L4）,定量过程管理的目的是定量地控制软件过程的过程性能。软件过程性能表示遵循一个软件过程所得到的实际结果。焦点是在一个可测的稳定的过程范围内鉴别出变化的特殊原因，并且适当时改正那些促使瞬时变化出现的环境。定量过程管理给组织过程定义、集成软件管理、组间协调、和同行评审的实践附加了一个内容丰富的测量计划。,软件质量管理（L4）,软件质量管理的目的是建立对项目的软件产品质量的定量了解和实现特定的质量目标。软件质量管理对软件产品工程中所描述的软件工作产品，实施内容丰富的测量计划。,缺陷预防（L5）,缺陷预防的目的是鉴别缺陷的原因并防止它们再次出现。正如在集成软件管理中所描述的，软件项目分析缺陷、鉴别其原因并更改项目定义软件过程。正如在过程更改管理中所描述的，应将具有普遍价值的过程更改通知给其它软件项目。,技术改进管理（L5）,技术改进管理的目的是识别出能获利的新技术（即工具、方法和过程），并以有序的方式将它引进到组织中去，正如在过程改进管理中所描述的那样。技术改进管理的关注焦点是在不断变化的环境里高效率地创新。,过程改进管理（L5）,过程改进管理的目的是出于改进软件质量、提高生产率和缩短产品开发周期的目的，持续不断地改进组织中所采用的软件过程。过程改进管理既采用缺陷预防的增量式改进，又采用技术改进管理的创新式改进，并使得整个组织可以享用这些改进。,CMM评估,CMM评估方法,软件过程评估（CBA-IPI），目的是确定一个组织的当前软件过程的状态，找出组织所面临的急需解决的软件过程有关问题，进而有步骤地实施软件过程改进，使组织的软件过程能力不断提高。软件能力评价（SCE），目的是识别合格的能完成软件工作的承制方，或者监控承制方现有软件工作中软件过程的状态，进而提出承制方应改进之处。,SCE与CBA-IPI的差异,由于在动机、目的、输出和结果的所有权等方面均不同，导致二者在：会谈目的、询问的范围、所采集的信息和结果的表示方式上不同；所采用的详细规程有别；培训要求也不一样。,CBA-IPI,软件过程评估是在开放、合作的环境中进行的，评估目的在于暴露问题和帮助经理和工程师们改进他们的软件过程，一般都能得到较好的支持。评估过程中虽然提问单是个重要工具，但更重要的是通过各种会谈了解组织的软件过程。评估的结果除了识别组织所面临的软件过程问题外，最有价值的还是：明确软件过程的改进途径，促进制订进一步的行动计划，使全组织关注改进过程，增强执行改进行动计划的动力和热情。,SCE,软件能力评价是在更象审计的环境中进行。评价的目的与金钱密切相关，评价组的推荐性意见将影响挑选承制方或设置资金。评价过程的重点放在复审已文档化的审计记录上，这些记录能揭示组织实际执行的软件过程。,评估方法特点,采用成熟度提问单作为现场访问的出发点；采用CMM作为指导现场调查研究的导引图；利用CMM中的关键过程域生成明确地指出软件过程强项和弱项的调查发现清单；在对关键过程域目标满足情况进行分析的基础上，衍生出一个剖面；根据调查发现清单和关键过程域剖面，向合适的对象提出结论意见。,（SCE和CBA-IPI）评估步骤图示,建立评估或评价组,填写提问单,进行响应分析 分析,现场访问会谈和文档评审,提出调查发现清单,制作KPA（关键过程区域）剖面,CMMI的提出,广泛使用的各种CMM模型,问题,系统学科与软件学科在传统上没有很好地集成在一起软件在系统中的重要性引人注目地增长例如：分配给软件的需求百分比*B-2-65%F-22-80%美国国防部强调，要使系统/软件的接口更好地做到无缝联接,Systems,Software,*Source:Standish Group Chaos Report,模型太多，时