[转帖]CMM-2软件能力成熟度实践

翔羽

<p><br/>第一章 CMM的简介<br/>1.1 CMM简述<br/>CMM（Capability Maturity Model for Software）是软件能力成就度模型，它是由软件工程研究所（SEI，Software Engineering Institute）提出的，目的是领导软件机构进行在成本和进度的要求下能提交高质量的软件，CMM为软件企业提供了一条从混乱、不成熟的软件过程向成熟的、有纪律的软件过程改进的方法。<br/>1986年11月，SEI在MITRE公司协助下，开始开发过程成熟度框架，以帮助软件机构进行软件过程改造；1987年SEI发布了软件过程成熟度问卷；1991年CMM最初版本通过评审，并开始在软件机构中应用。<br/>什么叫软件过程，软件过程是软件工程的基础，软件过程是指在相应的规范下组织和使用相应的资源（人财物等）生产出满足客户需要的软件产品。软件过程可以抽象成一系列的工作和工作产品的开发、维护的行为、方法、实践和控制过程，如项目计划、概要设计、详细设计、代码、测试计划等。<br/>软件过程成熟度指对于具体的软件过程进行明确定义、管理、测量和控制的程度，改进软件过程要求企业加强管理机制，并且长期有效地关注软件过程，建立软件过程的制度化，这样才能以越来越好的方式进行软件开发。<br/>CMM是全面质量管理（TQM, TQC total quality Management）中的过程管理部分在软件行业的应用，CMM比ISO9000更细致，更具有针对性，当然通过了ISO9000认证的软件企业基本上已经满足了CMM2至CMM3的要求。</p><p>CMMI</p><p>1.2 CMM的5个级别<br/>CMM一共有5个级别，分别是一级初始级、二级可重复级、三级已定义级、四级已管理级和五级优化级。<br/>级别1:初始级<br/>软件机构不能提供开发和维护软件的稳定环境,,经常做出不切合实际的承诺,危机发生时,项目一般都会脱离原有计划,回到仅有编码和调试的状态,项目经常超出预算和超期,软件项目的成功完全依赖于项目组中特别的人,当他们离开后他们对软件项目过程的影响随之消失,所以项目的开发能力的保证来自于个人能力而非组织能力.<br/>比较典型的特征是项目的需求不断变更,软件设计不断变更,经常会发生推倒重来的事情,项目后期加班严重,最终产品的客户满意度不高等等.<br/>在级别一中,软件过程是一个不定的过程(黑盒),由于没有很好地定义活动和实施,管理人员需要花大量时间确定项目的状态和活动的状态,需求在不被确定的情况下进入软件过程,软件产品的质量只有在发布后才能被评估出来.<br/>级别2:可重复级<br/>建立并实施了软件管理的规程,项目执行经过定义的、文档化的、有以往经验的、可测量的、强制的以及可改进的过程，管理级对软件项目制定了基本的软件管理和控制措施，项目负责人不断跟踪软件成本、进度，一旦出现问题能很快确定，对软件需求和开发过程中的工作产品进行基线（基线：）管理。软件项目的计划和跟踪是稳定的，并可以重复以前的成功，项目的过程处于一个项目管理系统的有效的控制之下，遵守并执行基于以前成功项目所制定的项目计划。<br/>在级别二,因为已经建立基本的项目管理,软件项目的开发过程可以看成是一系列黑盒的串连,在项目的里程碑处具有可视性(可以知道当然的状态和进度),客户可以在里程碑处对产品进行评审.<br/>级别3：已定义级<br/>将组织用于开发和维护的标准过程文档化，指定了一个负责机构过程活动小组（SEPG），在组织内部进行培训，保证全体人员和负责人具有所需的知识和技能。<br/>软件过程被严格定义，包括准备、输入、实施工作的标准和规程、验证机制、输出和完成准则的过程。<br/>无论是软件工程活动还是管理活动，其过程都是稳定的，可重复的，软件开发的成本、进度和功能均可受到良好的控制，软件质量被跟踪。<br/>在三级,软件过程中的任务具有可视性,管理人员和工程人员对自身的活动在一定程序进行相互交流,管理人员对可能发生的风险进行准备,客户可以随时得到关于项目准确的最新情况.<br/>级别4：已管理级<br/>组织对所有的项目的关键软件过程活动进行生产率和质量的测量，收集并分析这些数据，为评估项目的软件过程和产品建立定量的基础。<br/>该级别的软件机构可以对软件过程&nbsp; 因为软件过程是稳定的、可测量的，所限定的数量范围内预测软件的过程趋势和工作产品的质量，当意外发生时，可明确指出变化产生的原因，当超出预计边界时，能采取相应的措施进行纠正。<br/>在该级,管理人员可以测量项目的进度和存在的问题,而且在项目开始之前,客户就能对过程能力和风险有定量的认识.<br/>级别5：优化级<br/>组织强调渐进的过程改进,以预防缺陷为目的的过程中,能有效地确定软件的优势和弱势,并预先加强防范,使用描述软件过程有效性的数据完成新技术的成本和效益分析,并向该机构的软件过程提供相应的更改建议.<br/>软件小组通过分析缺陷产生的原因对软件过程进行评估以预防已知的缺陷再次发生,并在组织内部进行宣传以防止再次发生.<br/>级别5的特点是,过程可以不断得到改进,并且可以通过对已有软件过程进行不断改进来提高过程效率和能力,可以使用新技术和新方法进行革新,技术和过程改进可作为常规的业务活动来进行计划和管理.<br/>在该级对过程进行更改后造成的影响能够被准确的被评估,管理人员能估计和定量跟踪更改的效果和影响.</p><p>1.3 CMM级别的关系<br/>CMM的级别其实是将过程管理的改进活动由浅入深,每一个级别都是下一个级别的基础,如果企业要跳跃级别,往往会导致改进活动失败.一般来说较高等级的软件过程的潜力只有建立在相应的基础上才可以发挥出来.成熟度等级只描述一个等级上占主导地位的关键问题，即主要矛盾。<br/>在一级的企业中,在还没建立可重复级过程(二级)之前,试图去实施已定义级的过程,因为没有管理过程的规定,当项目陷入成本和进度的压力后,工程过程会在这些压力下被抛弃.<br/>在还没有对过程进行定义为基础的软件企业,试图进行定量管理过程(四级),因为没有对过程进行定义,就没有了采集和解释数据的共同基础,那么一个项目中采集到的数据,对其它项目来说是无用的,如果使用它,必然导致不良的结果，企业即使具有实施较高成熟度等级的软件过程的能力并不意味着它可以跳越成熟度等级。<br/>在CMM模型中，每个等级都有一个必要的基础，从此基础出发才能达到下一个等级，因此，跳越等级通常被认为是违反规律和不能允许的。<br/>当然,在CMM模型中,针对当前机构或项目的需要,也可以在较低级别实行较高级别的实践,例如:SEPG小组(软件工程过程组),SEPG小组是三级的属性,但是在企业从一级向二级改进的活动中,经常建立该组来指导企业从一级到二级的过程改进.另外就是部分活动,如分析、测试等，在二级中没有进行描述，但是一级的企业依然有这些活动，在三级，这些活动被定义为连贯和严谨的软件工程过程。当然本书所讲的一级企业进行二级改造的例子中没有SEPG小组。</p><p>1.4 国内企业实施CMM2过程改造<br/>中国注册的软件企业有八千余家，实际进行软件开发的约有五千多家，绝大多数的企业的研发人员规模小于50人，就软件开发来说，多是作坊式开发，项目的管理是基于黑箱的人的管理方式，项目的成功和精英的关系极大，如果项目组中有人离开，不要说精英，就是一个普通程序员的离开都有可能导致项目延期甚至失败,而就每个项目来说,经验(成功的和失败的)只能积累在个人的范围内,对于企业,对于其它的项目基本上没有帮助.<br/>中国软件企业的特点是规模小,年纪轻,没有积累的管理经验，很多企业对软件工程还知之甚少，就软件的开发管理很不成熟,而CMM模型为软件企业搭建了一个较好的管理框架,用于管理企业内部具体的软件过程，可以在短的时间内为企业建立一套完整的软件工程过程,从而极大程度地提高企业按计划的时间和成本提交有质量保证的软件产品的能力。<br/>中国和印度的软件产品起步是差不多的,但是如今印度已经成为名副其实的软件大国,这其中的差别不仅仅只是一个ISO9000或者是CMM认证的差异,仔细对比中国和印度的软件产业,中国自身拥有巨大的软件市场,在软件技术上具有优势,印度总体落后于中国,其软件产品依赖出口,但产业结构已经完成与国际接轨,如今，印度的计算机软件产品已远销世界75个国家，其中28个国家完全依靠印度的计算机软件和服务支撑。特别是中国加入WTO以后,软件产业与国际化接轨迫在眉睫,软件产品的质量\成本和进度将成为软件企业生存和发展的首要因素,说用CMM进行软件过程改进,利用别人已有的经验，取其对自己有用的部分，加以使用，并由此在实践中不断改进和创新。这应该是我们赶超世界水平的一种办法，另外用CMM进行软件过程评估，有助于提高我国软件产业的国际竞争力，获得规模效益是有很大帮助的。<br/>实施CMM2模型进行软件过程改进，必然会遇到很多阻力，下面就将简述一下主要阻力及其产生原因。<br/>首先是制度化的理念与原有管理模式的冲突，国外的软件企业有几十年的软件管理经验，其软件工程的推广程序远远超过我国，而过程改进将首先同企业文化冲突，原因很多，领导不重视，相关人员抵触，质量保证人员和软件工程组人员得不到应有的重视和权威。其实CMM2在推行过程中与在中国推行ISO9000所遇到的问题是一样的，推行制度化，制定规范、监督和执行三位一体，这就会与企业的特权行为相抵触，软件开发最常见的就是后期加班加点，不按计划，不管规范，而在这些时间，制度就往往成为压力的牺牲品。<br/>第二是管理层推动的问题，所有制度的推行，必须要有高层领导的推动，过程改造是一个长期的工作，而且并不是立竿见影的，而在真正受到压力的时候，高层领导是否还能够坚定的推动，中国企业在推行ISO9000的时候，很多企业是三把火，是问有多少企业领导是不断对制度和过程进行研究，并成为个中高手，如果自己对此还知之不多，又怎么能了解和体会制度给企业带来的好处呢？在CMM2过程改进中，我们要求高层领导不只是支持，而且还要亲者参与。进行CMM过程改造的目的不是为了”评级”,如果企业采用其它的手段通过了”评级”,但自身没有获得提高,这实际上是自欺欺人,在ISO9000的评审中出现过极少的例子,相信在CMM评审中也会出现.<br/>第三是软件企业人员的质量意识亟待提高，中国的软件企业，小规模非公有制企业占绝大多数，而在这些企业中，实施质量体系定向培训的是凤毛麟角，大多数的公司不愿意为此投入资金和人力，造成各级人员不了解质量体系的知识。另外，项目管理人员对质量体系的实施起着至关重要的作用，但实际上我国软件企业的项目管理人员基本上都是从技术出身，对软件工程的了解，对项目管理的了解都很欠缺，缺乏真正的项目管理意识，而在实际的推广过程中必须首先对他们强化管理意识，这样在真正的软件项目的过程中，项目管理人员就会主动维护质量保证的工作。<br/>第四是CMM咨询和认证的问题，详细的CMM资料都是只告诉你做什么，但是没告诉你怎么做，具体的实施和应用需要企业自己不断去领会并且由专人来进行培训和指导，由于中国的企业培训还没有建立起来,中国的主任评审员还属于稀缺资源,从CMM的评审认证具有垄断性，对中小型企业来说成本较高，在一定程度上也相应影响了CMM的发展，所以在我国，大力推行第三方评审就很有必要了。而且随着中国进入WTO,CMM评审的价格会相应下调,这对CMM在中国的推广也将是一件好事.<br/>提供高质量的产品和成功的产品是两个不同的概念,高质量的产品是成功产品的重要条件,但不是说高质量的产品就一定会成功,这也就是说CMM并不是企业的万灵丹, 它一种有步骤且一致地改进软件产品的管理过程和工程过程的方案，但是它并不能解决软件工程中的全部问题，它的目的是提高企业的当前软件过程的管理能力,而且也不涉及企业的战略能力,如企业的人才战略、新技术战略（在低级的企业中，采用新技术是有风险的）以及产品战略等，一个企业的成功必须是多个条件加在一起。关于人才的管理软件工程所专门开发了一套人员管理成熟度模型(PM-CMM),有兴趣的读者可以参考与之相关的文档.<br/>由于CMM产生的历史的特殊性，CMM1.1版本很适合与政府签约的大型软件开发组织部的大型项目，这也是很多中小型企业对表示CMM怀疑的地方，事实上对中小型组织或中小型项目来说，合理地对CMM进行剪裁是有效的，另外就CMM2级和3级来说，基本上与组织和项目的规模大小没有直接的关系。<br/>对于企业实施CMM笔有提出以下几个建议：<br/>软件企业应专注于软件工程过程改进，除非必要，不要搞软件能力评审，特别是不能将“认证”作为执行改进活动的目的。软件过程管理与改进的唯一目的是：开发制造高质量的软件产品。（质量的几个重要的要素是：产品要适应客户的需要，产品要保时，保成本。）<br/>领会CMM和其他的模型与标准，运用自己的专业判断力去使用它，决不能生搬硬套。按照企业自身的特点、要求与条件去制订软件过程和选择实行改进的部分。<br/>软件过程的建立与改进要有短、中、长期的目标，有轻重缓急之分。切忌一下子什么都想达到。摊子铺得越大，失败的概率也越大，一定要选择先做什么，什么是“最薄弱的环节”和“最易做到而又有显著收效”。就某一能力的成熟度来说，不必一下子去满足该级级的所有目标，可以试行某部分关键过程领域的中的部分关键实践活动，要逐步取得经验后再展开。在CMM过程改造中从等级1到等级2可能需用几年的时间，而在其它等级间的升迁通常花费约2年时间。<br/>企业上层领导要首先理解建立软件过程管理和改进的重要，并亲自领导这件工作。要保证过程管理的人员配备。企业上层领导的持之以恒的参与是成功的先决条件。除此之外，专业开发人员的全力支持与参与过程管理和改进也是成功的关键。<br/>企业在内部的“过程评估”中，坦诚地暴露软件过程中存在的各种问题。从而制定出真正对症下药的过程改进的对策。<br/>是否在企业中全面推行CMM过程改造是一个慎重的决定，它所涉及的范围相当广，而且要求投入人力、物力和财力资源，一个企业如果单凭一点点对CMM的认识就做出是否全面推行CMM的决定，那将是很遗憾的。企业应该在对CMM及有关的一切知识有彻底的理解之后，才去考虑是否全面引进的问题。<br/>////另外,在二级的企业,对项目时间及成本的估计会超过一级////</p>

翔羽

<p>第二章 详解CMM2<br/>CMM 由五个成熟度等级组成。除了等级1 外，每个成熟度等级由几个关键过程域组成。每个关键过程域又划分为五个称作共同特点的部分。共同特点规定一些关键实践，当这些关键实践群体得到认真执行，能实现关键过程域的目标。下显示了CMM 的这个结构。<br/>2.1 CMM的结构和组成<br/>CMM 的组成部分包括：<br/>成熟度等级（Maturitylevels）<br/>一个成熟度等级是在朝着实现成熟软件过程进化选中的一个妥善定义的平台。五个成熟度等级提供CMM 的顶层结构。<br/>过程能力（ProcessCapability）<br/>软件过程能力描述通过遵循软件过程能实现预期结果的程度。一个组织的软件过程能力提供一种预测组织承担下一个软件项目时预期的最可能结果的方法。<br/>关键过程域（KeyProcessareas）<br/>每个成熟度等级由若干关键过程域组成。每个关键过程域标识出一串相关的活动，当它们作为群体完成时，就达到一组目标，此组目标对建立该过程成熟度等级是至关重要的。关键过程域是分别定义在各个成熟度等级并与之相连在一起的。例如，等级2 的一个关键过程域是软件项目策划。<br/>目标（Goals）<br/>目标概括一个关键过程域中的关键实践，并可用于确定一个组织或项目是否已有效地实施该关键过程域。目标表示每个关键过程域的范围、边界和意图。例如，软件项目策划关键过程域的一个目标是“软件估计已文档化，供策划和跟踪软件项目使用。”参<br/>见“软件能力成熟度模型，1．1 版”[Paulk93a]和本文的4．5 节（即运用专业判断），能得到更多的有关解释目标的信息。<br/>共同特点（CommonFeatures）<br/>将关键实践分别归入下列五个共同特点中：执行约定、执行能力、执行的活动、测量和分析、及验证实施。共同特点是一种属性，它能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的。执行的活动这个共同特点描述实施活动。其余四个共同特点描述规范化因素，它们使得过程成为组织文化的一部分。<br/>关键实践（KeyPractices ）<br/>每个关键过程域用若干关键实践加以描述，当实施这些关键实践时，能帮助实现该关键过程域的目标。关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。例如，软件项目策划这个关键过程域的一个关键实践是“按照已文档化的规程制定项目的软件开发计划”。<br/>这个结构图用个例子来解释,如果一个企业达到了CMM二级的水平,这表明了该企业具有以下的过程能力：<br/>已建立管理软件项目的方针和实施这些方针的规程。基于在类似项目上的经验对新项目进行策划和管理。使软件项目的有效管理过程制度化，组织能重复在以前项目上所开发的成功实践，尽管项目所实施的具体过程可能不同。一个有效过程可特征化为实用的、已文档化的、已实施的、已培训的、已测量的和能改进的。<br/>项目已设置基本的软件管理控制。实际可行的项目约定是基于对以前项目的观察结果和当前项目的需求。项目的软件经理跟踪软件成本、进度和功能；识别在满足约定方面出现的问题。对软件需求和为实现需求所开发的工作产品建立基线，并控制其完整性。软件项目标准已确定，并且组织能保证准确地执行它们。如果有子承包商的话，软件项目与他们一起努力建立一种强有力的客户一供应商关系。<br/>过程能力可概括为有纪律的，因为软件项目的规划和跟踪是稳定的，能重复以前的成功。由于遵循实际可行的基于以前项目性能的计划，项目过程处在项目管理系统的有效控制之下。<br/>对于CMM二级，它包括了6个关键过程域，分别是需求管理、软件项目计划、软件项目跟踪和监控、软件配置管理、软件质量保证、软件子合同管理。每一个关键过程域是之了实现相应的目标，例如需求管理的目标是：控制指定给软件的系统需求，为软件工程和管理应用建立基线（目标1），保持软件计划、产品和活动与指定给软件的系统需求一致（目标2）。<br/>每一个关键过程域可以分成执行约定、执行能力、执行的活动、测量和分析、及验证实施五个部分(共同特点)，这五个部分从五个不同的方向反映了这个关键过程域的过程情况。<br/>对于整个CMM来说，每一系列关键过程域的完成，就代表着企业达到了某一个级别，CMM二级有6个关键过程域，三级有七个，四级两个，五级三个，整个CMM的级别结构如下图：</p><p></p><p></p><p></p><p></p><p></p><p><br/>&nbsp;</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 优化级（5）<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 过程变更管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 技术变更管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 缺陷预防</p><p><br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 定量管理级（4）<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件质量管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 定量过程管理</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 已定义级（3）<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 同行评审<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 组际协调 <br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件产品工程<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 集成软件管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 培训大纲<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 组织过程定义<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 组织过程焦点</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 可重复级（2）<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件配置管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件质量保证<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件子合同管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件项目跟踪和监控<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件项目策划<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求管理<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br/>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;初始级（1）&nbsp;</p><p></p><p>2.2等级2的RM关键过程域（需求管理）<br/>需求管理的目的是在客户和将处理客户需求的软件项目之间建立对客户需求的共同认识。<br/>需求管理包括和客户一起建立和维护有关软件项目需求的协议，该协议称作“分配给软件的系统需求”。“客户”可解释为系统工程组、销售部门、另一个内部组织、或者一个外部客户。协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、计划和跟踪整个软件生存周期内软件项目活动的基础。<br/>将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组（如系统工程组）完成，软件工程组可能不能直接控制需求的分配。在项目约束范围内，软件工程组采取适当的步骤以保证对分配给软件的需求形成文档、并加以控制。<br/>为了实施控制，软件工程组需对初始的和经修改的分配给软件的系统需求进行评审，以保证有关问题在被纳入软件项目之前得以解决。每当改变分配给软件的系统需求时，都要调整受到影响的软件计划，工作产品和相关活动，使其与更新后的需求保持一致。<br/>目标<br/>目标1：分配给软件的系统需求是受控的，为软件工程和管理建立基线。<br/>目标2：软件项目计划、工作产品和活动与分配给软件的系统需求保持一致。<br/>执行约定<br/>约定1 项目遵循一书面的、组织级的方针去管理分配给软件的系统需求。<br/>分配给软件的系统需求称为“分配需求”。分配需求是系统需求的一部分，它将用系统的软件部分来实现。分配需求是软件开发计划的主要输入。软件需求分析对分配需求进行详细的分析和细化，并生成文档化的软件需求。<br/>该方针一般规定；<br/>1．对分配需求建立文档。<br/>2．由下列人员评审分配需求：<br/>软件经理<br/>其它受到影响的组<br/>受到影响的组的实例有：<br/>&nbsp;系统测试组<br/>&nbsp;软件工程组（包括所有小组，例如软件设计小组）<br/>&nbsp;系统工程组<br/>&nbsp;软件质量保证组<br/>&nbsp;配置管理组<br/>&nbsp;文档支持组<br/>3．修订软件计划、更改工作产品和相关活动，以保持和分配需求的变更一致。<br/>执行能力<br/>能力1:对每个项目，应明确对系统需求的分析,和将其分配到硬件、软件和其它部分的职责。<br/>分析和分配系统需求不是软件工程组的职责，而是他们工作的前提。<br/>该职责包括：<br/>1．在项目整个生存期内，以文档方式管理系统需求和分配需求。<br/>2．实施对系统需求及分配需求的更改。<br/>能力2:对分配需求建立文档。<br/>分配需求包括：<br/>1．影响和确定软件项目活动的非技术性需求（即：协议、条件、合同条款等）。<br/>协议、条件和合同条款的实例包括：<br/>&nbsp;要交付的产品<br/>&nbsp;交付日期<br/>&nbsp;里程碑<br/>2．对软件的技术需求。<br/>技术需求的实例有；<br/>&nbsp;最终用户、操作员、支持、或集成功能(问题:integration functions,有译为综合功能,什么叫集成功能,举个例子)<br/>&nbsp;性能要求<br/>&nbsp;设计约束<br/>&nbsp;编程语言<br/>&nbsp;界面需求<br/>3．用于确认软件产品满足分配需求的验收准则。<br/>能力3:提供足够的资源和资金用以管理分配需求。<br/>1．应由在应用领域和软件工程方面有经验和能力的人管理分配需求。<br/>2．应有合适的支持管理需求活动的工具。<br/>支持工具的实例有：<br/>&nbsp;电子表格程序<br/>&nbsp;配置管理工具<br/>&nbsp;跟踪工具<br/>&nbsp;测试管理工具(测试管理工具在这里是干什么用的?是用来管理问题和缺陷和测试过程和结果的吗?)<br/>能力4:软件工程组和其它软件一有关组的成员接受过需求管理的培训。<br/>培训的实例包括：<br/>&nbsp;项目所使用的方法、标准、规程<br/>&nbsp;应用领域知识<br/>执行的活动<br/>活动1: 软件工程组在分配需求被纳入软件项目之前对分配需求进行评审。<br/>1．找出不完整的和遗漏的分配需求。<br/>2．评审分配需求，确定它们是否：<br/>&nbsp;可以并适合用软件来实现<br/>&nbsp;清晰和正确地被描述<br/>&nbsp;相互一致<br/>&nbsp;可测试的<br/>3．负责分析和分配系统需求的组评审被确认有可能存在问题的分配需求，并作出必要的更改。<br/>4．由分配需要所形成的约定应和受到影响的组协商达成。<br/>受到影响的组的实例包括：<br/>&nbsp;软件工程组（包括所有的小组，例如软件设计小组）<br/>&nbsp;软件估计组<br/>&nbsp;系统工程组<br/>&nbsp;系统测试组<br/>&nbsp;软件质量保证组<br/>&nbsp;软件配置管理组<br/>&nbsp;合同管理组<br/>&nbsp;文档支持组<br/>有关协商约定的做法，请参考软件项目计划关键过程域的活动6。<br/>活动2：分配需求是软件工程组进行软件计划、工作产品和活动的基础。<br/>1．管理和控制分配需求。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的（即版本控制），而且以受控制的方式进行更改（即更改控制）。<br/>如果希望有比“进行管理和控制”意义上更高程度的控制，则工作产品可置于完整的配置管理控制之下，正如在软件配置管理关键过程域中所描述的。<br/>2．软件开发计划的基础。<br/>3．制定软件需求的基础。<br/>活动3：对分配需求的更改需经过评审，并将其纳入软件项目中。<br/>1．评估它对现有约定的影响，协商对约定进行合适的更改。<br/>&nbsp;对组织外部的人或组所作约定的更改须由高级管理者参与评审。<br/>对于组织外部的约定，参考软件项目计划关键过程域活动4 和软件项目跟踪和监督关键过程域活动3。<br/>&nbsp;组织内部和受到影响的组协商约定的更改。<br/>参考软件项目跟踪和监督关键过程域的活动5、6、7 和8，以便找到包括对约定的更改进行协商的实践。<br/>2．由于分配需求的更改所造成的对软件计划、工作产品和活动的更改需要进行：<br/>&nbsp;识别<br/>&nbsp;评价<br/>&nbsp;风险评估<br/>&nbsp;归档<br/>&nbsp;计划<br/>&nbsp;通知受到影响的组和个人<br/>&nbsp;跟踪直到结束<br/>测量和分析<br/>测量1测量分配需求的管理活动状态。<br/>测量的实例包括；<br/>&nbsp;标明每个分配需求的状态<br/>&nbsp;给定分配需求的更改活动记录<br/>&nbsp;统计分配需求更改的累积数，包括已提出的、未解决的、已批准的和已完成并纳入系统基线的总数</p>

翔羽

<p>验证实施<br/>验证1：高级管理者定期参与评审管理分配需求的活动。<br/>高级管理者定期评审的主要目的是为了保证能够合适的和及时的了解和洞察软件过程。评审的时间间隔应该满足组织的需要，只要存在合适的出现异常情况的报告机制，评审间隔可以稍长。<br/>参考软件项目跟踪和监督关键过程域的验证1，以便找到包括高级管理者监督评审的典型内容的实践。<br/>验证2：项目经理定期或根据实际工作需要随时评审管理分配需求的活动。<br/>参考软件项目跟踪和监督关键过程域的验证2 以便找到包括项目管理者监督评审的内容。<br/>验证3：软件质量保证组评审和（或）审计管理分配需求的活动和工作产品，并报告其结果。<br/>参考软件质量保证关键过程域。<br/>至少，这些评审和（或）审计要验证：<br/>&nbsp;分配需求是已评审的，且在软件工程组接受它们之前，其中存在的问题已经被解决。<br/>&nbsp;当分配需求更改时，软件计划、工作产品和活动已经进行了合适的修改。<br/>&nbsp;对于由分配需求的更改所导致的对约定的更改，是经过与受影响的组协商并达成一致的。</p><p>2.3等级2的SPP关键过程域（软件项目计划）<br/>软件项目计划的目的是为完成软件工程和管理软件项目制定合理的计划。软件项目计划包含估计待完成的工作，建立必要的约定和确定进行该工作的计划。<br/>软件计划首先作出有关待完成的工作和其它定义及界定软件项目的约束和目标（由宪来管理关键过程域的实践所建立的）的陈述。软件计划过程包括以下步骤：估计软件工作产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。为了制定软件计划（即软件开发计划），可能需要重复地通过这些步骤。<br/>该计划提供完成和管理软件项目活动的基础，并按照软件项目的资源、约束和能力，阐述对软件项目的客户作的约定。<br/>目标<br/>目标1：对供计划和跟踪软件项目用的软件估计已建立文档。<br/>目标2：软件项目的活动和约定是有计划的并已建立文档。<br/>目标3：受影响的组和个人同意他们的关于软件项目的约定。<br/>执行约定<br/>约定1：指定项目软件经理负责协商约定和制定项目软件开发计划。<br/>约定2：项目遵循书面的组织的用于策划软件项目的方针。<br/>该方针一般规定：<br/>1．配给软件的需求用作为策划软件项目的基础。<br/>参考需求管理关键过程域的活动2。<br/>2．下列人员之间协商软件项目的约定：<br/>项目经理<br/>项目软件经理<br/>其它的软件经理<br/>3．其它的工程组协商他们介入该软件活动的事宜，并记入文档。<br/>其它工程组的实例包括：<br/>&nbsp;系统工程组<br/>&nbsp;硬件工程组<br/>&nbsp;系统测试组<br/>4．影响的组评审软件项目的；<br/>软件规模估计<br/>工作量和成本估计<br/>进度<br/>其它约定<br/>受影响的组的实例有；<br/>&nbsp;软件工程组（包括所有的小组，例如软件设计小组）<br/>&nbsp;软件估计组<br/>&nbsp;系统工程组<br/>&nbsp;系统测试组<br/>&nbsp;软件质量保证组<br/>&nbsp;软件配置管理组<br/>&nbsp;合同管理组<br/>&nbsp;文档支持组<br/>5、级管理者评审所有的对组织外部的个人和组所作的软件项目约定。<br/>6、项目的软件开发计划进行管理和控制。<br/>在所有这些实践中术语“软件开发计划”习惯上指的是管理软件项目的全面的计划。采用“开发”术语并不是有意排除软件维护项目或软件支持项目，应在每个项目的上下文中恰当地解释该术语。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的（即版本控制），而且以受控的方式引进更改（即更改控制）。<br/>如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管理的完备的纪律之下，正如在软件配置管理关键过程域中所描述的。<br/>执行能力<br/>能力1：对软件项目存在文档化的经批准的工作陈述。<br/>1．作陈述包括；<br/>工作的范围，<br/>技术目标和对象，<br/>对客户和最终用户的识别，<br/>这些实践中所指的最终用户是客户指定的最终用户或最终用户的代表。<br/>要求实施的标准，<br/>安排的职责，<br/>成本和进度的约束及目标，<br/>软件项目和其它组织间的依赖关系。<br/>其它组织的实例有；<br/>&nbsp;客户<br/>&nbsp;子承包商<br/>&nbsp;合资伙伴<br/>资源限制和目标<br/>对开发和（或）维护的其它的约束和目标。<br/>2．作陈述由下列人员评审；<br/>项目经理<br/>项目软件经理<br/>其它软件经理<br/>其它受影响的组<br/>3．工作陈述进行管理和控制。<br/>能力2：安排制定软件开发计划的职责。<br/>1．目软件经理，直接工作或通过委托代表，协调项目的软件策划。<br/>2．可追踪，可说明的方式分解对软件产品和活动的职责，并将其安排给软件经理。<br/>软件工作产品的实例包括；<br/>&nbsp;适当时，交付给外部在客或最终用户的工作产品；<br/>&nbsp;供其它工程组使用的工作产品；和<br/>&nbsp;供软件工程组内部使用的主要工作产品。<br/>能力3：为策划软件项目提供足够的资源和投资。<br/>1．可能处，可以使用对正在策划的软件项目的应用领域有专门知识的有经验的个人来制定软件开发计划。<br/>2．得支持软件项目策划的工具合用。<br/>支持工具的实例有：<br/>&nbsp;电子表格程序，<br/>&nbsp;估计模型，和<br/>&nbsp;项目策划和调度程序。<br/>能力4：介入软件策划的软件经理、软件工程师和其它个人，在适用于其职责范围的软件<br/>估计和策划规程方面受到培训。<br/>执行的活动<br/>活动1：软件工程组参加项目建议群组。<br/>1．件工程组与下列各项工作有关：<br/>建议的准备和提交，<br/>D 说明的讨论和提交，和<br/>对影响软件项目的约定作更改而进行的协商。<br/>2、件工程组评审所建议的项目约定。<br/>项目约定的实例包括：<br/>&nbsp;项目的技术目标和对象；<br/>&nbsp;系统和软件的技术解；<br/>&nbsp;软件预算、进度和资源；和<br/>&nbsp;软件标准和规程。<br/>活动2：在整个项目策划的早期阶段起动软件项目策划，此两项策划平行进行。<br/>活动3：在项目的整个生存期内，软件工程组和其它受影响的组一起参加整个项目的策划。<br/>1．件工程组评审项目层的计划。<br/>活动4：高级管理者参加按照已文档化的规程评审对组织外部的个人和组所作的软件项目约定。<br/>活动5：识别或确定具有可管理规模的预先规定阶段的软件生存周期。<br/>软件生存周期的实例有：<br/>&nbsp;瀑布型，<br/>&nbsp;重叠瀑布型，<br/>&nbsp;螺旋型，<br/>&nbsp;单型构造，和<br/>&nbsp;单个原型／重叠瀑布型。<br/>活动6：按照已文档化的规程制定项目的软件开发计划。<br/>该规程一般规定：<br/>1．件开发计划基于且遵守；<br/>客户的标准，当合适时；<br/>项目的标准；<br/>经批准的工作陈述；和<br/>分配需求。<br/>2．软件一有关组和其它工程组协商他们介入软件工程组活动的计划，把该项支持工作编入预算，并对协议建立文档。<br/>软件一有关组的实例有：<br/>&nbsp;软件质量保证组<br/>&nbsp;软件配置管理组<br/>&nbsp;文档支持组<br/>其它工程组的实例有：<br/>&nbsp;系统工程组<br/>&nbsp;硬件工程组<br/>&nbsp;系统测试组<br/>3．其它软件一有关组和其它工程组协商软件工程组介入其活动的计划，把该支持工作<br/>编入预算，并对协议建立文档。<br/>4．下列人员评审软件开发计划：<br/>项目经理，<br/>项目软件经理，<br/>其它软件经理，和<br/>其它受影响的组。<br/>5．软件开发计划进行管理和控制。<br/>活动7:对有关软件项目的计划建立文档。<br/>在关键实践中，这个计划或计划的集合称为软件开发计划。<br/>参考软件项目跟踪和监督关键过程域的活动1 以便找到关于项目使用软件开发计划<br/>的实践。<br/>软件开发计划包括：<br/>1．件项目的目的、范围、目标、和对象。<br/>2．件生存周期的选择。<br/>3．选的供开发和（或）维护软件用的规程、方法和标准的确定。<br/>软件标准和规程的实例有；<br/>&nbsp;软件开发策划<br/>&nbsp;软件配置管理<br/>&nbsp;软件质量保证<br/>&nbsp;软件设计<br/>&nbsp;问题跟踪和解决<br/>&nbsp;软件测量<br/>4．开发软件工作产品的确定。<br/>5．软件工作产品的规模估计和对软件工作产品的更改。<br/>6．软件项目的工作量和成本的估计。<br/>7．键计算机资源的预计使用情况。<br/>8．件项目的进度，包括里程碑和评审的确定。<br/>9．目软件风险的识别和评估。<br/>10．于项目软件工程设施和支持工具的计划。<br/>活动8:识别为建立和保持对软件项目的控制所必须的工作产品。<br/>参考软件配置管理关键过程区的活动4。<br/>活动9:按照巴文档化的规程导出对软件工作产品规模（或对软件工作产品规模的更改）的估计。<br/>该规程一般规定：<br/>1．所有主要的软件工作产品和活动作出规模估计。<br/>对软件规模的量度的实例有：<br/>&nbsp;功能点（functionpoints），<br/>&nbsp;特征点（featurepoints），<br/>&nbsp;代码行，<br/>&nbsp;需求数，和<br/>&nbsp;页数。<br/>要作规模估计的工作产品和活动的类型的实例有；<br/>&nbsp;运行软件和支持软件，<br/>&nbsp;可交付的和不交付的工作产品，<br/>&nbsp;软件和非软件工作产品（例如文档），和<br/>&nbsp;开发、验证和确认工作产品的活动。<br/>2．软件工作产品分解到能满足估计对象所需要的粒度。<br/>3．可得到历史数据的地方使用历史数据。<br/>4．规模估计的假定记入文档。<br/>5．规模估计建立文档，进行评审、并使之得到承认。<br/>评审和认可规模估计的组和个人的实例包括：<br/>&nbsp;项目经理，<br/>&nbsp;项目软件经理，和<br/>&nbsp;其它软件经理。<br/>活动10:按照巴文档化的规程导出对软件项目的工作量及成本的估计。<br/>该规程一般规定：<br/>1．软件项目的工作量及成本的估计与对软件工作产品的规模（或更改的规模）的<br/>估计有关。<br/>2．生产率数据（历史的和（或）当前的）可利用时，将其用于估计；将这些数据<br/>的来源及合理的解释记入文档。<br/>当可能时，生产率和成本数据来自该组织的项目。<br/>生产率和成本数据应考虑用于制作软件工作产品的工作量及重要的成本。<br/>用于制作软件工作产品的重要成本的实例有：<br/>&nbsp;直接的劳务费，<br/>&nbsp;管理费，<br/>&nbsp;差旅费，和<br/>&nbsp;计算机使用成本。<br/>3．工作量、人员配置和成本的估计基于过去的经验。<br/>当可能时，应利用类似项目的经验。<br/>导出各种活动的时间分段（timephasing）。<br/>作出工作量，人员配置和成本估计在软件生存周期上的分布。<br/>4．计和导出估计值时所作的假定记入文档，进行评审、并使之得到认可。<br/>活动11 按照文档化的规程导出对项目的关键计算机资源的估计。<br/>关键计算机资源可以在宿主环境中，在集成与测试的环境中，在目标环境中，或在以上<br/>这些环境的任何组合中。<br/>该规程一般规定：<br/>1、别项目的关键计算机资源。<br/>关键计算机资源的实例包括：<br/>一计算机存储能力，<br/>一计算机处理器运用能力，和<br/>一通信通迢容量。<br/>2、关键计算机资源的估计与对下列项的估计有关：<br/>软件工作产品的规模，<br/>运行处理的负载（operationalprocessingload），和<br/>通信量。<br/>3、关键计算机资源的估计建立文档、进行评审、并使之得到认可。<br/>活动12 按照已文档化的规程导出项目的软件进度表。<br/>该规程一般规定：<br/>1、件进度与以下各项有关：<br/>对软件工作产品的规模（或规模更改）的估计，和<br/>软件工作量和成本。<br/>2、件进度表基于过去的经验。<br/>可能时，利用类似项目的经验。<br/>3、件进度表适应所规定的里程碑日期、关键的相关性日期及其它限制。<br/>4、件进度表中的活动有合适的间隔，且里程碑是以适当的时间长度分开的，以支<br/>持在进程测量上的精度。<br/>5、导出进度表时的假定记入文档。<br/>6、软件进度表建立文档、进行评审、并使之得到认可。<br/>活动13<br/>对与项目成本资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档。<br/>1、于风险对项目的潜在影响，对风险进行分析和优先级排序。<br/>2、别风险的偶发事件。<br/>偶发事件的实例包括：<br/>一进度受阻，<br/>—更换人员配置计划，和<br/>—关于附加计算装置的更换计划。<br/>活动14<br/>制定关于项目软件工程设施和支持工具的计划。<br/>1、这些设施和支持工具的能力需求的估计建立在对于软件工作产品的规模估计<br/>和其它特征的基础上。<br/>软件开发设施和支持工具的实例包括：<br/>—软件开发用的计算机和外设，<br/>一软件测试用的计算机和外设，<br/>—目标计算机环境软件，和<br/>一其它支持软件。<br/>2、购买或研制这些设施和支持工具问题，分配职责和商谈约定。<br/>3、有受到影响的组评审该计划。<br/>活动15<br/>记录软件策划数据。<br/>1、记录的信息包括估计及为了重构该估计和评估它们的合理性所需要的相关信<br/>息。<br/>2、软件策划数据进行管理和控制。</p><p><br/></p>

翔羽

测量和分析<br/>测量1<br/>进行测量，并将测量结果用于确定软件策划活动的状态。<br/>测量的实例有：<br/>一与计划相比较，软件项目策划活动的里程碑的完成情况，和<br/>一与计划相比较，在软件项目策划活动中所完成的工作，所用的工作量和所消耗的资金。<br/>验证实施<br/>验证1<br/>高级管理者定期参与评审软件项目策划的活动。<br/>高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软<br/>件过程活动。评审间隔应满足组织的需要，只要已存在报告例外情况的合适机制，间隔可以<br/>长。<br/>1、审技术、成本、人员配置和进度等性能。<br/>2、析在较低层次上未解决的矛盾和问题。<br/>3、析软件项目风险。<br/>4、排和评审措施条款并跟踪到结束。<br/>5、备每次会议的摘要报告，并将其散发给受影响的组和个人。<br/>验证2<br/>项目经理既定期地也事件驱动地参与评审软件项目策划的活动。<br/>1、影响的组有代表出席。<br/>2、照软件项目的工作陈述和分配需求，评审软件项目策划活动的状态和当前结果。<br/>3、析组间的依赖关系。<br/>4、析较低层次上未解决的矛盾和问题。<br/>5、审软件项目风险。<br/>6、配和评审措施条款，并跟踪到结束。<br/>7、备每次会议的摘要报告，并将其散发给受影响的组和个人。<br/>验证3<br/>软件质量保证组评审和（或）审计软件项目策划的活动和工作产品，并报告其结果。<br/>参考软件质量保证关键过程域。<br/>至少，评审和审计要查证：<br/>1、件估计和策划的活动。<br/>2、制定项目约定的活动。<br/>3、备软件开发计划的活动。<br/>4、于准备软件开发计划的标准。<br/>5、件开发计划的内容。<br/>软软软件件件项项项目目目跟跟跟踪踪踪和和和监监监督督督<br/>等级2（可重复的）的一个关键过程域<br/>软件项目跟踪和监督的目的是建立对实际进展的适当的可视性，使管理者能在软件项目<br/>性能明显偏离软件计划时采取有效措施。<br/>软件项目跟踪和监督包括对照已文档化的估计、约定、和计划评审和跟踪软件完成情况<br/>和结果。基于实际的完成情况和结果调整这些计划。<br/>软件项目的已文档化的计划（即软件开发计划，正如在软件项目策划关键过程域中所<br/>描述的）用作跟踪软件活动、传送状态和修订计划的基础。管理者监控软件活动。主要通过<br/>在所选出的软件工作产品完成时和在所选择的里程碑处，将实际的软件规模。工作量、成本<br/>和时间表与计划相比较，来确定进展情况。当确定未实现软件项目计划时，采取纠正措施。<br/>这些措施可以包括修订软件开发计划以反映实际的完成情况和重新策划遗留的工作或者采<br/>取改进性能的措施。<br/>目标<br/>目标1<br/>服软件计划，跟踪实际结果和性能。<br/>目标2<br/>当实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理直到结束。<br/>目标3<br/>对软件约定的更改得到受到影响的组和个人的认可。<br/>执行约定<br/>约定1<br/>指派～个项目软件经理，对项目的软件活动和结果负责。<br/>约定2<br/>项目遵循书面的组织用以管理软件项目的方针。<br/>该方针一般规定：<br/>1、用并维护一个已文档化的软件开发计划作为跟踪软件项目的基础。<br/>2、时向项目经理报告软件项目的状态和问题。<br/>3、软件计划未实现时，采取纠正措施，或者调整性能，或者调整计划。<br/>4、受影响的组参与和认可的情况下对软件约定进行更改。<br/>受影响的组的实例有；<br/>一软件工程组（包括所有小组，例如软件设计小组），<br/>一软件估计组，<br/>一软件工程组，<br/>一系统测试组，<br/>一软件质量保证组，<br/>一软件配置管理组，<br/>一合同管理组，和<br/>一文档支持组。<br/>5、级管理者评审所有的约定更改和软件项目对组织外部的个人和组所作的新的约定。<br/>执行能力<br/>能力1<br/>对软件项目的软件开发计划已建立文档和批准。<br/>参考软件项目策划关键过程域的活动6 和7 以便找到包括软件开发计划的实践。<br/>能力2<br/>项目软件经理明确地分配关于软件工作产品和活动的任务。<br/>分配的任务包括：<br/>1、开发的软件工作产品或将提供的服务。<br/>2、些软件活动的工作量和成本。<br/>3、些软件活动的进度。<br/>4、些软件活动的预算。<br/>能力3<br/>提供足够的用以跟踪软件项目的资源和投资。<br/>1、派给软件经理和软件作业领导跟踪软件项目的具体职责。<br/>2、得支持软件跟踪的工具是可用的。<br/>支持工具实例包括：<br/>—电子表格程序，和<br/>一项目策划／制定进度表程序。<br/>能力4<br/>在管理软件项目的技术和人员方面，软件经理受到培训。<br/>培训的实例包括；<br/>一管理技术项目，<br/>一跟踪和监督软件规模、工作量、成本及进度，和<br/>一管理职员。<br/>能力5<br/>一线软件经理在软件项目的技术方面受到定向培训。<br/>走向培训的实例包括：<br/>—项目的软件工程标准和规程，和<br/>一项目的应用领域。<br/>执行的活动<br/>活动1<br/>将已文档化的软件开发计划用于跟踪软件活动和传送状态。<br/>参考软件项目策划关键过程域的活动7 以便找到包括软件开发计划内容的实践。<br/>这个软件开发计划：<br/>1、着工作进展而更新，以使反映完成情况，特别当实现里程碑时。<br/>2、能容易被下列人员使用：<br/>软件工程组（包括所有的小组，例如软件设计小组），<br/>软件经理，<br/>项目经理，<br/>高级管理者，和<br/>其它受影响的组。<br/>活动2<br/>按照已文档化的规程修订项目的软件开发计划。<br/>参考软件项目策划关键过程域的活动6 以便找到包括制定软件开发计划的活动的实<br/>践。<br/>该规程一般规定：<br/>l、合适时，修订软件开发计划，以便包括对计划的精炼和更改，特别当计划有重大更<br/>改时。需将在分配给软件的系统需求、设计约束、资源、成本和进度之间的相关性反映<br/>在所有计划更改中。<br/>2、新软件开发计划以便包括所有新的软件项目约定和对约定的更改。<br/>3、每次修订时，评审软件开发计划。<br/>4、软件开发计划进行管理和控制。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的<br/>（即版本控制），而且以受控的方式引进更改（即更改控制）。<br/>如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管<br/>理的完备的纪律之下，正如在软件配置管理关键过程域中所描述的。<br/>活动3<br/>级管理者参与按照已文档化的规程评审那些对组织外部的个人和组所作的软件项目约<br/>定和约定的更改。<br/>活动4<br/>将经批准的、影响软件项目约定的更改传达给软件工程组和其它软件一有关组的成员。<br/>其它软件一有关组的实例包括：<br/>一软件质量保证组，<br/>一软件配置管理组，和<br/>一文档支持组。<br/>活动5<br/>跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施。<br/>参考软件项目策划关键过程域的活动9 以便找到包括导出规模估计的实践。<br/>1． 踪所有主要软件工作产品的规模（或更改的规模）。<br/>2． 实际代码规模（生成的、经完全测试的和交付的）和在软件开发计划中所<br/>记载的估计规模对比。<br/>3． 实际交付的文档单元数据与在软件开发计划中所记载的估计数相比较。<br/>4． 期精炼、监控和调整软件工作产品的整体预测规模（与实际值相结合的估<br/>计值）。<br/>5． 受影响的组协商那些能影响软件约定的对软件工作产品规模估计的更改，<br/>并对该更改建立文档。<br/>活动6<br/>跟踪项目的软件工作量和成本，必要时采取纠正措施。<br/>参考软件项目策划关键过程域的活动10 以便找到包括导出成本估计的实践。<br/>1． 根据一段时间内已完成的工作得出的实际工作量和成本的开销与在软件开<br/>发计划中的估计量相比较以识别潜在的超支和欠支。<br/>2． 踪软件成本并将其与软件开发计划中记载的估计相比较。<br/>3． 工作量及人员配置与软件开发计划中记载的估计相比较。<br/>4． 受影响的组协商那些影响软件约定的在人员配置和其它软件成本方面的更<br/>改，并对该更改建立文档。<br/>活动7<br/>跟踪目的关键计算机资源，必要时采取纠正措施。<br/>参考软件项目策划关键过程域的活动11 以便找到包括导出计算机资源估计的实践。<br/>1． 对于每一个主要的软件成分，正如在软件开发计划中记载的那样，跟踪项<br/>目关键计算机资源的实际使用情况和预计使用情况，并将其与估计相比较。<br/>2． 和受影响的组协商那些影响软件约定的对关键计算机资源估计的更改，并<br/>对其建立文档。<br/>活动8<br/>跟踪项目的软件进度，必要时采取纠正措施。<br/>参考软件项目策划关键过程域的活动12 以便找到包括导出进度的实践。<br/>1． 将软件活动、里程碑和其它约定的实际完成情况与软件开发计划作比较。<br/>2． 评价软件活动、里程碑和其它约定等迟后和提前完成的后果对将来的活动和里<br/>程碑的影响。<br/>3． 和受影响的组协商那些影响软件约定的对软件进度的修订，并对其建立文档。<br/>活动9<br/>跟踪软件工程技术活动，必要时采取纠正措施。<br/>1． 软件工程组的成员定期向他们的一线经理报告他们的技术状态。<br/>2． 将为后续工作所提供的软件发行内容与软件开发计划中记载的计划相比较。<br/>3． 在任何软件工作产品中所识别出的问题均予以报告和建立文档。<br/>4． 问题报告直至结束。<br/>活动10<br/>跟踪与项目的成本、资源、进度及技术方面有关的软件风险。<br/>参考软件项目策划关键过程域的活动13 以便找到包括风险识别的实践。<br/>1．当有补充信息时，调整风险及风险可能性的优先级。<br/>2．项目经理定期参与评审高风险的区域。<br/>活动11<br/>记录软件项目的实际测量数据和重新策划的数据。<br/>参考软件项目策划关键过程域的活动15 以便找到包括记录项目数据的实践。<br/>1．记录的信息包括估计、及为重构该估计和验证其合理性所必须的辅助信息。<br/>2．对软件重新策划的数据进行管理和控制。<br/>3．将软件策划数据、重新策划数据和实际测量数据归档供正在进行的和未来的项目使<br/>用。<br/>活动12<br/>件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进展、计划、性能和问题。<br/>这些评审由下列人员共同进行：<br/>1、一线软件经理和他们的软件作业领导。<br/>2、当合适时，项目软件经理、一线软件经理和其它软件经理。<br/>活动13<br/>按照已文档化的规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情<br/>况和结果。<br/>这些评审：<br/>1、被安排在软件项目进度的有意义的点上进行，例如在所选阶段的开头或结束处。<br/>2、合适时，由雇客、最终用户和组织内部受影响的组参与进行。<br/>这些实践中所指的最终用户是客户指定的最终用户或最终用户的代表。<br/>3、使用经过负责的软件经理评审和批准的材料。<br/>4、分析软件活动的约定、计划和状态：<br/>5、导致对重大问题、措施条款和决策的识别和建立文档。<br/>6、分析软件项目风险。<br/>7、导致在必要时对软件开发计划的改进。<br/>

翔羽

测量和分析<br/>测量1<br/>进行测量并将测量结果用于确定软件跟踪和监督活动的状态。<br/>测量的实例包括：<br/>—在完成跟踪和监督活动时所化资的工作量和其它资源；和<br/>—对软件开发计划的更改活动，‘包括对以下项的更改：软件工作产品的规模估计，软<br/>件成本估计、关键计算机资源估计和进度。<br/>验证实施<br/>验证1<br/>高级管理者定期参与评审软件项目跟踪和监督和活动。<br/>高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软<br/>件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可<br/>以长。<br/>1、评审技术、成本、人员配置和进度等性能。<br/>2、分析较低层次上无法解决的矛盾和问题。<br/>3、分析软件项目风险。<br/>4、安排和评审措施条款，并跟踪到结束。<br/>5、准备每次会议的摘要报告，并将其散发给受影响的组。<br/>验证2<br/>项目经理既定期地又事件码区动地参与评审软件项目跟踪和监督的活动。<br/>1、受影响的组有代表出席。<br/>2、对照软件开发计划评审技术、成本、人员配置和进度等性能。<br/>3、评审关键计算机资源的使用；对照原来的估计，报告有关这些计算机资源的当前<br/>估计和实际使用。<br/>4、分析组间的依赖关系。<br/>5、分析在较低层次上无法解决的矛盾和问题。<br/>6、分析软件项目风险。<br/>7、分配和评审措施条款，并跟踪到结束。<br/>8、准备每次会议的摘要报告，并将其散发给受影响的组。<br/>验证3<br/>软件质量保证组评审和（或）审计软件项目跟踪和监督的活动和工作产品，并报告其结<br/>果。<br/>参考软件质量保证关键过程域。<br/>至少，该评审和（或）审计要查证：<br/>1、评审和修正约定的活动。<br/>2、修正软件开发计划的活动。<br/>3、经修正的软件开发计划的内容。<br/>4、跟踪以下各项的活动：软件项目的成本、进度、风险、技术和设计限制、及功能性<br/>和性能。<br/>5、已计划好的技术评审和管理评审的活动。<br/>软件子合同管理<br/>等级2（可重复的）的一个关键过程域<br/>软件于合同管理的目的是选择合格的软件子承包商并有效地管理他们。<br/>软件于合同管理包括选择软件予承包商、建立和子承包商的约定，及跟踪和评审子承包<br/>商的性能和结果。这些实践包括对纯软件子合同的管理，也包括对子合同的软件成分的管理，<br/>后者含有软件、硬件和可能有的其它系统成分。<br/>基于子承包商完成工作的能力选择子承包商。许多因素对将主承包商工作的一部分签为<br/>子合同的决策产生影响。选择子承包商可以基于战略经营同盟及技术上的考虑。这个关键过<br/>程区域的实践阐述与将工作的一个确定部分签子合同给另一个组织相联系的传统的采购过<br/>程。<br/>当签子合同时，建立一个包括技术和非技术（例如交付日期）需求的已文档化的协议并<br/>将其用作管理于合同的基础。对将由于承包商完成的工作和关于该工作的计划建立文档。子<br/>承包商将遵循的标准和主承包商的标准一致。<br/>子承包商的软件的策划、跟踪和监督活动由于承包商完成。主承包商确保恰当地完成这<br/>些策划、跟踪和监督活动并且确保子承包商交付的软件产品满足其验收准则。主承包商和子<br/>承包商一起工作去管理他们的产品和过程界面。<br/>目标<br/>目标1<br/>主承包商选择合格的软件予承包商。<br/>目标2<br/>主承包商和软件子承包商认同他们相互的约定。<br/>目标3<br/>主承包商和软件子承包商保持不断的通信。<br/>目标4<br/>主承包商对照约定跟踪软件予承包商的实际结果和性能。<br/>执行约定<br/>约定1<br/>项目遵循书面的管理软件予合同的组织上的方针。<br/>该方针一般规定；<br/>1、在选择软件予承包商和管理软件子合同时采用已文档化的标准和规程。<br/>2、合同协议形成管理干合同的基础。<br/>3、对子合同的更改需由主承包商和子承包商共同介入和认同。<br/>约定2<br/>指派一个子合同经理负责建立和管理软件子合同。<br/>1、子合同经理本人在软件工程方面是博学的和有经验的，或者他已配备有具有这方面<br/>知识和经验的个人。<br/>2、子合同经理和受影响的当事人一起负责协调待签子合同工作的技术范围及子合同的<br/>条件和条款。<br/>项目的系统工程组和软件工程组确定待签子合同工作的技术范围。适当的经营功能组一<br/>例如采购、财务和法律组，建立和监控于合同的条款和条件。<br/>3、子合同经理负责：<br/>选择软件予承包商，<br/>管理软件予合同，和<br/>安排子合同产品的后一子合同支持。<br/>执行能力<br/>能力1<br/>为选择软件予承包商和管理于合同提供足够的资源和投资。<br/>1、确定软件经理和其它个人管理子合同的具体职责。<br/>2、使得支持管理子合同的工具可用。<br/>支持工具的实例包括：<br/>一估计模型，<br/>一电子表格程序，和<br/>一项目管理和编制进度程序。<br/>能力2<br/>参与建立及管理软件予合同的软件经理和其它个人受到完成这些活动的培训。<br/>培训的实例的有：<br/>一准备和策划软件予合同的签订，<br/>一评价子合同投标者的软件过程能力，<br/>一评价子合同投标者的软件估计和计划，<br/>一选择子承包商，和<br/>一管理子合同。<br/>能力3<br/>参与管理软件子合同的软件经理和其它个人在子合同的技术方面接受定向培训。<br/>走向培训的实例有：<br/>一应用领域，<br/>一正运用的软件技术，<br/>一正使用的软件工具，<br/>一正使用的方法论，<br/>一正使用的标准，和<br/>一正使用的规程。<br/>执行的活动<br/>活动1<br/>按照已文档化的规程定义和规划待签子合同的工作。<br/>该规程一般规定：<br/>1、基于对项目的技术特征和非技术特征所作的综合评估，选择待签子合同的软件产品<br/>和活动。<br/>选择待签子合同的功能或子系统，使其与潜在于承包商的技能和能力相匹配。<br/>基于对系统和软件需求所作的系统性分析和恰当的划分，确定对待签子合同的<br/>软件产品和活动的规格说明。<br/>2、从项目的以下各项导出对待签子合同工作的规格说明和将遵循的标准和规程：<br/>工作陈述，<br/>分配给软件的系统需求，<br/>软件需求，<br/>软件开发计划，和<br/>软件标准和现程。<br/>3、对子合同的工作陈述进行：<br/>准备，<br/>评审，<br/>认同，<br/>评审和认同子合同工作陈述的个人的实例包括：<br/>一项目经理，<br/>一项目软件经理，<br/>一应负责的软件经理，<br/>一软件配置管理经理，<br/>一软件质量保证经理，和<br/>一子合同经理<br/>当需要时修订，和<br/>管理和控制。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的<br/>（即版本控制），而且以受控的方式引进更改（即更改控制）。<br/>如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管<br/>理的完备的纪律之下，正如在软件配置管理关键过程域中所描述的。<br/>参考软件项目织划关键过程域的能力1 以便找到包括工作陈述的典型内容的实践。<br/>4、在准备子合同的工作陈述的同时准备一份选择子承包商的计划，合适时要进行评审。<br/>活动2<br/>按照已文档化的规程，在评价子合同投标者完成该工作的能力的基础上选择软件子承包<br/>商。<br/>这个规程包括对以下各项的评价：<br/>1、所提交的对计划中的子合同的建议。<br/>2、以前在类似工作方面的性能记录，如果有的话。<br/>3、子合同投标者的组织相对于主承包商的地理位置。<br/>对某些子合同的有效管理可能要求频繁的面对面的相互交流。<br/>4、软件工程和软件管理能力。<br/>评价子承包商能力的方法的一个实例是SEI 软件能力评价方法。<br/>5、为完成该工作可得到职员。<br/>6、以前在类似应用领域的经验，包括子承包商的软件管理队伍所具有的软件专门知识。<br/>7、可用资源。<br/>资源的实例包括<br/>一设施，<br/>一硬件，<br/>一软件，和<br/>一培训。<br/>活动3<br/>将主承包商和软件子承包商间的合同协议用作管理子合同的基础。<br/>该合同协议用文档记载以下各项：<br/>1、条款和条件。<br/>2、工作陈述。<br/>参考软件项目策划关键过程域的能力1 以便找到包括工作陈述的典型内容的实践。<br/>3、对待开发产品的需求。<br/>4、子承包商和主承包商之间的依赖关系表。<br/>5、将交付给主承包商的子合同产品。<br/>产品的实例有：<br/>一源代码，<br/>一软件开发计划，<br/>一仿真环境，<br/>一设计文档，和<br/>一验收测试计划。<br/>6、提交产品修订的条件。<br/>7、在主承包商接收子合同产品之前评价子合同产品时将用的验收规程和验收准则。<br/>8、主承包商用来监控和评价子承包商性能的规程和评价准则。<br/>活动4<br/>主承包商评审和批准已文档化的子承包商软件开发计划。<br/>1、这个软件开发计划包括（直接地或通过引证）主承包商软件开发计划中的适当条款。<br/>在某些情况下，主承包商的软件开发计划可能包括于承包商的软件开发计划，因此无需<br/>单独的子承包商软件开发计划。<br/>参考软件项目策划关键过程域的活动7 以便找到包括项目软件开发计划的内容的实<br/>践。<br/>活动5<br/>将已文档化的且经批准的子承包商软件开发计划用于跟踪软件活动和通信状态。<br/>活动6<br/>按照已文档化的规程判定对软件予承包商的工作陈述、子合同条款和条件、以及其它约<br/>定的更改。<br/>1、该规程一般规定，主承包商和子承包商的所有受影响的组都要参与。<br/>活动7<br/>主承包商的管理者和软件子承包商的管理者一起执行定期的状态或协调评审.<br/>1、当合适时，向子承包商提供对产品客户及最终用户的需要及希望的可视性。<br/>这些实践中所指的最终用户是客户指定的最终用户或最终用户的代表。<br/>2、对照子承包商软件开发计划评审子承包商的技术、成本、人员配置和进度等性能。<br/>3、评审那些指定为对项目是至关重要的计算机资源；跟踪子承商对当前估计所起的作<br/>用，并将它与在子承包商软件开发计划中所记载的每一个软件成分的估计相比较。<br/>4、分析在子承包商的软件工程组和其它子承包商组之间的关键的依赖关系和约定。<br/>5、分析主承包商和子承包商之间的关键的依赖关系和约定。<br/>既评审子承包商对主承包商的承诺，也评审主承包商对于承包商的承诺。<br/>6、分析不符合于合同的问题。<br/>7、分析与子承包商工作有关的项目风险。<br/>8、分析不能由于承包商内部解决的矛盾和问题。<br/>9、安排和评审措施条款，并跟踪到结束。<br/>活动8<br/>软件于承包商参与定期技术评审和交流。<br/>这些评审；<br/>1、当合适时，向子承包商提供对客户和最终用户的需要和希望的可视性。<br/>2、监控于承包商的技术活动。<br/>3、验证子承包商对技术要求的解释和实施是符合主承包商的要求的。<br/>4、验证约定正得到满足。<br/>5、验证技术问题是以及时的方式得到解决。<br/>活动9<br/>按照已文档化的规程在所选择的里程碑处进行正式评审，评价子承包商的软件工程完成<br/>情况和结果。<br/>这些规程一般规定：<br/>1、评审是预先计划好的，并在工作陈述中加以记载。<br/>2、评审分析子承包商关于软件活动的约定、计划和状态。<br/>3、识别重大的问题、措施条款及决策，并将它们记人文档。<br/>4、分析软件风险。<br/>5、当合适时，精炼子承包商的软件开发计划。<br/>活动价主承包商的软件质量保证组按照巳文档化的规程监控于承包商的软件质量保证<br/>活动。<br/>该规程一般规定：<br/>1、定期地评审子承包商用于软件质量保证的计划、资源、规程和标准，以保证它们适<br/>于监控于承包商的性能。<br/>2、执行对子承包商的常规评审以保证经批准的规程和标准正得到遵循。<br/>主承包商的软件质量保证组抽查子承包商的软件工程活动和产品。<br/>当合适时，主承包商的软件质量保证组审计于承包商的软件质量保证记录。<br/>3、定期审计于承包商有关其软件质量保证活动的记录，以评估软件质量保证计划、标<br/>准和规程正受到遵循的好坏。<br/>活动们主承包商的软件配置管理组按照已文档化的规程监控于承包商的软件配置管理<br/>活动。<br/>该规程一般规定：<br/>1、评审子承包商关于软件配置管理的计划、资源、规程和标准，以保证它们是满足要<br/>求的。<br/>2、主承包商和子承包商就有关软件配置管理的情况协调它们的活动，以保证子承包商<br/>的产品能容易地集成到或并入主承包商的项目环境。<br/>3、定期地审计于承包商的软件基线库，以便评估用于软件配置管理的标准和规程正<br/>受到遵循的程度和它们在管理软件基线方面如何有效。<br/>活动12<br/>主承包商按照已文档化的规程进行验收测试，这是子承包商软件产品交付的一部分。<br/>该规程一般规定：<br/>1、在测试前，主承包商和子承包商共同定义、评审和批准对每个产品的验收规程和验<br/>收准则。<br/>2、对验收测试的结果建立文档。<br/>3、对任何未通过其验收测试的产品制定措施计划。<br/>活动13<br/>定期评价软件予承包商的性能，并与子承包商一起评审该评价工作。<br/>对于承包商性能的评价提供一个机会使子承包商能获得关于它是否正在满足其雇客（即<br/>主承包商）需求的反馈信息。诸如性能有奖评审（Performanceawardfee reviews）那样的机<br/>制提供这种类型的反馈，它与贯穿于整个项目的定期的协调和技术评审不同。这些评价的文<br/>档也作为将来子承包商选择活动的输入。<br/>测量与分析<br/>测量1<br/>进行测量，将测量结果用于确定管理软件予合同的活动的状态。<br/>测量的实例有：<br/>一管理子合同活动的成本与计划相比较，<br/>一子合同产品的实际交付日期与计划相比较，和<br/>一主承包商的交付物交给子承包商的实际日期与计划相比较。<br/>验证实施<br/>验证1<br/>高级管理者定期参与评审管理软件予合同的活动。<br/>高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软<br/>件过程活动。评审间隔应满足组织的需要，只要已存在报告例外情况的合适机制，<br/>间隔可以长。<br/>参考软件项目跟踪和监督关键过程域的验证1 以便找到包括高级管理者监督评审的<br/>典型内容的实践。<br/>验证2<br/>项目经理既定期地也事件驱动地参与评审管理软件子合同的活动。<br/>参考软件项目跟踪和监督关键过程域的验证2 以便找到包括项目管理者监督评审的<br/>典型内容的实践。<br/>验证3<br/>软件质量保证组评审（或）审计管理软件于合同的活动和工作产品，并报告其结果。<br/>参考软件质量保证关键过程域。<br/>至少，该评审和（或）审计要查证；<br/>1、选择子承包商的活动。<br/>2、管理软件予合同的活动。<br/>3、协调主承包商和子承包商的配置管理活动的活动。<br/>4、已计划好的和子承包商一起进行的评审的执行情况。<br/>5、用以确立完成子合同的关键项目里程碑或阶段的那些评审的执行情况。<br/>6、子承包商软件产品的验收过程。<br/>

翔羽

软件质量保证<br/>等级2（可重复的）的一个关键过程域<br/>软件质量保证的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的<br/>可视性。<br/>软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项<br/>目和其它有关的经理提供这些评审和审计的结果。<br/>在软件项目的早期阶段，软件质量保证组与软件项目一起工作制定计划、标准和规程等，<br/>这些计划、标准、和规程将增加软件项目的价值并将满足项目和组织方针上的限制。通过参<br/>与制定计划、标准和规程，软件质量保证组帮助确保它们适合项目的需要，并且帮助验证它<br/>们对完成整个软件生存周期中的评审和审计将是适用的。软件质量保证组在整个生存周期评<br/>审项目活动，审计软件工作产品，并就软件项目是否正遵守已制定的计划、标准和规程等给<br/>管理者提供可视性。<br/>首先在软件项目内部处理符合性问题，如可能的话就地解决它。对于那些无法在软件项<br/>目内部解决的问题，软件质量保证组逐级上递该问题到管理者的恰当层次以求得解决。<br/>这个关键过程域只包括该组履行软件质量保证功能的实践。而识别软件质量保证组要<br/>评审和（或）审计的具体的活动和工作产品的实践一般包含在其它关键过程域的验证实施<br/>共同特点中。<br/>目标<br/>目标1<br/>软件质量保证活动是有计划的。<br/>目标2<br/>软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证。<br/>目标3<br/>受影响的组和个人接到软件质量保证活动和结果的通知。<br/>目标4<br/>高级管理者处理在软件项目内部不能解决的不符合问题。<br/>执行约定<br/>约定1<br/>项目遵循书面的实施软件质量保证（SQA）的组织方针。<br/>该方针一般规定；<br/>1、对全部软件项目，SQA 功能到位。<br/>2、SQA 有一个向高级管理者报告的渠道，它独立于：<br/>项目经理，<br/>项目的软件工程组，和<br/>其它的软件一有关组。<br/>其它软件一有关组的实例有：<br/>一软件配置管理组，和<br/>一文档支持组。<br/>组织必须确定一种组织机构，它在组织的战略经营目标和经营环境的上下文中支持那些<br/>要求独立性的活动，例如SQA。<br/>独立性应该：<br/>一给担当SQA 角色的个人提供组织上的自由度，使他们成为高级管理者在软件项目上<br/>的“耳目”。<br/>一使得担当SQA 角色的个人免受他们正在评审的软件项目的管理者所作的性能评价的<br/>影响。<br/>一使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。<br/>3、高级管理者定期地评审SQA 活动和结果。<br/>执行能力<br/>能力1<br/>存在负责协调和实施项目的SQA 的组（即SQA 组）。<br/>一个组是负责一组作业或活动的部门、经理、和个人的集合。组的规模可以变化，从一<br/>个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日<br/>制的个人。建立一个组时应考虑的因素包括指派的作业和活动、项目的规模、组织机构和组<br/>织的文化。某些组，例如软件质量保证组，集中注意力于项目活动，而其它组，例如软件工<br/>程过程组，则集中关注全组织的活动。<br/>能力2<br/>为进行SQA 活动提供足够的资源和投资。<br/>1、指派一个经理专门负责项目的SQA 活动。<br/>2、指派一个在SQA 任务方面是博学的，并有权力采取适当的监督行动的高级经理接收<br/>和处理软件不符合问题。<br/>在SQA向高级经理报告链上的全部经理均是在SQA的任务、责任和权力方面有见识的。<br/>3、使得支持SQA 活动的工具合用。<br/>支持工具的实例有：<br/>一工作站，<br/>—数据库程序，<br/>一电子表格程序，和<br/>一审计工具。<br/>能力3<br/>SQA 组的成员受到培训以完成他们的SQA 活动。<br/>培训的实例有：<br/>一软件工程技巧和实践；<br/>一软件工程组和其它软件一有关组的岗位任务及职责；<br/>一用于软件项目的标准、规程和方法；<br/>一软件项目的应用领域；<br/>－SQA 的对象。规程和方法；<br/>－SQA 组对软件活动的参与；<br/>一SQA 方法和工具的有效使用；和<br/>一人员间的交流。<br/>能力4<br/>软件项目的成员接受有关SQA 组的任务、职责、权力和价值等的定向培训。<br/>执行的活动<br/>活动1 按照已建档的规程为软件项目制订SQA 计划。<br/>该规程一般规定：<br/>1、SQA 计划的制定是在整个项目策划的早期阶段，并平行于整个项目策划。<br/>2、受影响的组和个人评审该SQA 计划。<br/>受影响的组及个人的实例有：<br/>一项目软件经理；<br/>一其它软件经理；<br/>一项目经理；<br/>一客户的SQA 代表；<br/>一SQA 组对其报告不符合问题的高级经理；和<br/>一软件工程组（包括全部小组，诸如软件设计小组及软件作业领导）。<br/>3、对SQA 计划进行管理和控制。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的<br/>（即版本控制），而且以受控的方式引进更改（即更改控制）。<br/>如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管<br/>理的完备的纪律之下，正如在软件配置管理关键过程域中所描述的。<br/>活动2<br/>按照SQA 计划进行SQA 组的活动。<br/>该计划包括：<br/>1、SQA 组的职责和权力。<br/>ZSQA 组的资源要求（包括职员、工具和设施）。<br/>3、项目的SQA 组活动的进度表和投资。<br/>4、SQA 组参加制定项目的软件开发计划、标准和规程的情况。<br/>5、将由SQA 完成的评价。<br/>待评价的产品和活动的实例有：<br/>一运行软件和支持软件，<br/>一可交付的和不交付的产品，<br/>一软件和非软件产品（例如文档），<br/>一产品开发和产品验证活动（例如运行测试用树），和<br/>一生成产品时所从事的活动。<br/>6、将由SQA 组进行的审计和评审。<br/>7、将用作SQA 组评审和审计的基础的项目的标准和规程。<br/>8、用于对不符合性问题建立文档和进行跟踪直至结束的规程。<br/>这些规程可能作为计划的一部分而纳入，也可以通过索引那些包含它们的其它文档的方<br/>式而纳入。<br/>9、要求SQA 组生成的文档。<br/>10、就SQA 活动给软件工程组和其它软件一有关组提供反馈信息的方法和频率。<br/>活动3<br/>SQA 组参与准备和评审项目的软件开发计划、标准和规程。<br/>L、SQA 就以下几个方面对计划、标准和规程提供咨询和评审：<br/>对组织方针的符合性，<br/>对外部强加的标准和要求的符合性（例如工作陈述所要求的标准），<br/>适合项目使用的标准，<br/>在软件开发计划中应阐述的专题，和<br/>项目指定的其它领域。<br/>2、SQA 组验证计划、标准和规程已到位并可用于评审与审计软件项目。<br/>活动4<br/>SQA 组评审软件工程活动以验证符合性。<br/>1、对照软件开发计划和指定的软件标准和规程去评价活动。<br/>参考其它关键过程域中的验证实施共同特点以便找到包括由SQA 组进行特定评审和<br/>审计的实践。<br/>2、对偏差进行鉴别和建立文档，并跟踪到结束。<br/>3、验证纠正措施。<br/>活动5<br/>SQA 组审计指定的软件工作产品以验证符合性。<br/>1、在交付给客户之前，评价可交付的软件产品。<br/>2、对照指定的软件标准、规程和合同要求评价软件工作产品。<br/>3、对偏差进行鉴别和建立文档，并跟踪到结束。<br/>4、验证纠正措施。<br/>活动6<br/>SQA 组定期向软件工程组报告其活动的结果。<br/>活动7<br/>按照巴文档化的规程对在软件活动和软件工作产品中所鉴别出的偏差建立文档并加以<br/>处理。<br/>该规程一般规定：<br/>1、将不符合软件开发计划和指定的项目标准及规程的问题写成文档，并在可能处，与<br/>适当的软件作业领导、软件经理或项目经理一起，加以解决。<br/>2、有些不符合软件开发计划和指定的标准及规程的问题不能与软件作业领导、软件经<br/>理或项目经理一起加以解决，将这些不符合问题写成文档并提交给指定的接收不符合问题的<br/>高级经理。<br/>3、定期评审提交给高级经理的不符合问题直至解决它们为止。<br/>4、对不符合问题的文档进行管理和控制。<br/>活动8<br/>当合适时，SQA 组与客户的SQA 人员一起对它的活动和发现进行定期评审。<br/>测量与分析<br/>测量1<br/>进行测量并将测量结果用于确定SQA 活动的成本和进度状态。<br/>测量的实例有：<br/>—SQA 活动的里程碑的完成情况与计划作比较；<br/>一在SQA 活动中所完成的工作、所化费的工作量和所消耗的资金与计划作比较；和<br/>一产品审计和活动评审的次数与计划相比较。<br/>验证实施<br/>验证1<br/>高级管理者定期参与评审SQA 活动。<br/>高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软<br/>件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可<br/>以长。<br/>参考软件项目跟踪和监督关键过程域的验证1 以便找到包括高级管理者监督评审的<br/>典型内容的实践。<br/>验证2<br/>项目经理既定期地也事件驱动地参与评审SQA 活动。<br/>参考软件项目跟踪和监督关键过程域的验证2 以便找到包括项目管理者监督评审的<br/>典型内容的实践。<br/>验证3<br/>独立于SQA 组的专家定期评审项目SQA 组的活动和软件工作产品。<br/>

翔羽

等级2（可重复的）的一个关键过程域<br/>软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整<br/>性。<br/>软件配置管理包括标识在给定时间点上软件的配置（即选定的软件工作产品及其描述），<br/>系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可银踝性。置于软<br/>件配置管理之下的工作产品包括交付给客户的软件产品（例如软件需求文档和代码），以及<br/>与这些软件产品等同的产品项或生成这些软件产品所要求的产品项（例如编译程序)建立一<br/>个软件基线库，当软件基线形成时就将它们纳入该库。通过软件配置管理的更改控制和配置<br/>审计功能，系统地控制基线的更改和那些利用软件基线库构造成的软件产品的发行。<br/>这个关键过程域仅包括实施软件配置管理功能的实践。而标识具体的配置项或单元的<br/>实践则包含在描述每个配置项或单元的开发和维护的关键过程域中。<br/>目标<br/>目标1<br/>软件配置管理活动是有计划的。<br/>目标2<br/>所选定的软件工作产品是巳标识的、受控的和适用的。<br/>目标3<br/>对巴标识的软件工作产品的更改是受控的。<br/>目标4<br/>受影响的组和个人得到软件基线的状态和内容的通知。<br/>执行约定<br/>约定1<br/>项目遵循书面的用以实施软件配置管理（SCM）的组织方针。<br/>该方针一般规定；<br/>1、明确指派每个项目的SCM 职责。<br/>2、在项目的整个生存周期内实行SCM。<br/>3、对于对外可交付的软件产品、指定的内部软件工作产品和指定在项目内部使用的支<br/>持工具（例如编译器）都实行SCM。<br/>4、项目建立或可以利用一个仓库，用来存储配置项／单元和相关联的SCM 记录。<br/>在这些实践中这个仓库的内容称为“软件基线库”。<br/>存取该仓库的工具和规程在这些实践中称为“配置管理库系统”。<br/>置于配置管理之下并作为单个实体予以处理的工作产品称为配置项。配置项一般分解为<br/>配置成分，而配置成分一般分解为单元。在一个硬件／软件系统中，所有的软件可看成一个<br/>单个配置项，或者可将该软件分解为多个配置项。在这些实践中术语“配置项牌元”用于指<br/>示在配置管理下的元素。<br/>5、定期审计软件基线和SCM 活动。<br/>执行能力<br/>能力1<br/>存在或者建立一个有权力管理项目软件基线的委员会（即软件配置控制委员会一<br/>SCCB）。<br/>该SCCB：<br/>1、审定软件基线的建立和配置项／单元的标识。<br/>2、代表项目经理和所有可能受到软件基线更改影响的组的利益。<br/>受影响的组的实例有；<br/>一硬件质量保证组，<br/>—硬件技术状态（配置）管理组，<br/>一硬件工程组，<br/>一制造工程组，<br/>一软件工程组（包括所有的小组，例如软件设计小组），<br/>—系统工程组，<br/>一系统测试组，<br/>一软件质量保证组，<br/>—软件配置管理组，<br/>一合同管理组，和<br/>一文档支持组。<br/>3、评审和审定对软件基线的更改。<br/>4、审定由软件基线库制造的产品的生成。<br/>能力2<br/>存在负责协调和实施项目的SCM 的组（即SCM 组）。<br/>一个组是负责一组作业或活动的部门、经理、和个人的集合。组的规模可以变化：从一<br/>个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日<br/>制的个人。建立一个组时应考虑的问题有：指派的作业和活动、项目的规模、组织机构和组<br/>织文化。某些组，例如软件质量保证组，集中注意力于项目的活动，而其它组，例如软件工<br/>程过程组，集中关注全组织的活动。<br/>SCM 组协调或实现：<br/>1、项目的软件基线库的生成和管理。<br/>2、SCM 计划、标准和规程的制定、维护和散发。<br/>3、将置于SCM 之下的软件工作产品集会的标识。<br/>一个工作产品是由定义、维护、或使用一个软件过程所生成的任何人工制品。<br/>4、对存取软件基线库的管理。<br/>5、软件基线的更新。<br/>6、由软件基线库制造的产品的生成。<br/>7、SCM 行动的记录。<br/>8、SCM 报告的生成和散发。<br/>能力3<br/>为进行SCM 活动提供足够的资源和投资。<br/>1、安排一个经理专门负责SCM。<br/>2、使得支持SCM 活动的工具合用。<br/>支持工具的实例有：<br/>一工作站，<br/>一数据库程序，和一<br/>一配置管理工具。<br/>能力4<br/>SCM 组的成员在有关进行其SCM 活动的对象、规程和方法方面受到培训。<br/>培训的实例包括：<br/>一SCM 标准、规程和方法；和<br/>一SCMXi 具。<br/>能力5<br/>软件工程组和其它软件一有关组的成员受到培训以便完成其SCM 活动。<br/>其它软件一有关组的实例有：<br/>～软件质量保证组，和<br/>一文档支持组。<br/>培训的实例有：<br/>一在软件工程组和其它软件一有关组的内部进行SCM 活动要遵循的标准、规程和方法，<br/>和<br/>一SCM 组的角色、职责和权力。<br/>执行的活动<br/>活动1<br/>按照已文档化的规程对每个软件项目准备一份SCM 计划。<br/>这个规程一般规定：<br/>1、SCM 计划的制定是在整个项目策划的早期阶段，并平行于整个项目策划。<br/>2、受影响的组评审SCM 计划。<br/>3、对SCM 计划进行管理和控制。<br/>“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的<br/>（即版本控制），而且以受控的方式引进更改（即更改控制）。<br/>如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管<br/>理的完备的纪律之下，正如在本关键过程域中所描述的。<br/>活动2<br/>用已文档化的经批准的SCM 计划作为进行SCM 活动的基础。<br/>该计划包括：<br/>1、将进行的SCM 活动、活动的日程表、指派的职责和所要求的资源（包括职员、工<br/>具和计算机设施）。<br/>2、SCM 需求和将由软件工程组及其它软件一有关组进行的SCM 活动。<br/>活动3<br/>建立一个配置管理库系统作为软件基线的仓库。<br/>该库系统：<br/>l、支持SCM 的多个控制层次。<br/>导致多个控制层次的情况例如：<br/>一在生存周期的不同时间所需要的控制层次不同（例如，随着产品成熟要更加严密的控<br/>制），<br/>一纯软件系统和既包括硬件又包括软件的系统所需要的控制层次不同。<br/>2、提供对配置项／单元的存储和检索功能。<br/>3、在受影响的组之间和在库内部的控制层次之间提供配置项／单元的共享和传送。<br/>4、帮助使用配置项／单元的产品标准。<br/>5、对配置项／单元的归档版本提供存储和恢复功能。<br/>6、帮助保证由软件基线库制造的产品的正确生成。<br/>7、对SCM 记录提供存储、更新和检察功能。<br/>8、支持SCM 报告的编制。<br/>9、提供对库结构和内容的维护。<br/>库维护功能的实例有：<br/>一库文件的备份／重建，和<br/>一从库的错误中恢复。<br/>活动4<br/>标识将置于配置管理之下的软件工作产品。<br/>1、基于已文档化的准则选择配置项／单元。<br/>可标识为配置项／单元的软件工作产品的实例有：<br/>一过程一有关文档（例如：计划、标准或规程），<br/>一软件需求，<br/>一软件设计，<br/>一软件代码单元，<br/>～软件测试规程，<br/>～为软件测试活动所构造的软件系统，<br/>一为交付给客户或最终用户所构造的软件系统，<br/>一编译程序，和<br/>一其它支持工具。<br/>2、安排给每个配置项／单元唯一的标志符。<br/>3、详细说明每个配置项／单元的特征。<br/>4、详细说明每个配置项／单元所属于的软件基线。<br/>5、详细说明在开发中将每个配置项／单元置于配置管理之下的时间点。<br/>6、标识每个配置项／单元的负责人（即从配置管理的角度来说的所有者）。<br/>活动5<br/>按照巴文档化的规程，起动、记最、评审、批准和跟踪对所有配置项或单元的更改请求<br/>和问题报告。<br/>活动6<br/>按照已文档化的规程控制对基线的更改。<br/>该规程一般规定：<br/>1、进行评审和（或）回归测试以保证更改不会造成对基线的未料到的影响。<br/>2、仅仅那些经SCCB 批准的配置项／单元才能进入软件基线库。<br/>3、以能保持软件基线库的正确性和完整性的方式进行配置项或单元的登入和退出。<br/>登入或退出步骤的实例有；<br/>一验证修改是经审定的，<br/>一建立更改日志，<br/>一保持一份更改拷贝，<br/>一更新软件基线库，和<br/>一建立被取代的软件基线的档案。<br/>活动7<br/>按照已文档化的规程生成由软件基线库制造的产品并控制它们的发行。<br/>该规程一般规定：<br/>1、SCCB 审定由软件基线库制造的产品的生成。<br/>2、不论为内部使用或外部使用，由软件基线库制造的产品仅仅由软件基线库中的配置<br/>项或单元组成。<br/>活动8<br/>按照已文档化的规程记录配置项或单元的状态。<br/>该规程一般规定：<br/>l、足够详细地记录配置管理行动，使每个配置项／单元的内容和状态，都是清楚的并<br/>且能恢复以前的版本。<br/>2、对每个配置项／单元维护其当前状态并保留其历史（即更改和其它行动）。<br/>活动9<br/>编制用文档记载SCM 活动和软件基线内容的标准报告，并使受影响的组和个人可以使<br/>用它。<br/>报告的实例包括：<br/>一SCCB 会议记录，<br/>一更改申请的摘要和状态，<br/>一问题报告的摘要和状态（包括解决情况），<br/>一软件基线更改的摘要，<br/>一配置项／单元的修改历史，<br/>一软件基线状态，和<br/>一软件基线审计结果。<br/>活动们按照已文档化的规程进行软件基线审计。<br/>该规程一般规定：<br/>1、为审计作好充分准备。<br/>2、评估软件基线的完整性。<br/>3、评审配置管理库系统的结构和设施。<br/>4、验证软件基线库内容的完备性和正确性。<br/>5、验证与适用的SCM 标准和规程的符合性。<br/>6、向项目软件经理报告审计结果。<br/>7、跟踪得自审计的措施条款直至结束。<br/>测量和分析<br/>测量1<br/>进行测量并将测量结果用干确定SCM 活动的状态。<br/>测量的实例有：<br/>一每单位时间处理的更改申请数；<br/>一SCM 活动的里程碑的完成情况与计划相比较；和<br/>一在SCM 活动中所完成的工作、花费的工作量和消耗的资金。<br/>验证实施<br/>验证1<br/>高级管理者定期参与评审SCM 活动。<br/>高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软<br/>件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可<br/>以长。<br/>参考软件项目跟踪和监督关键过程域的验证1 以便找到包括高级管理者监督评审的<br/>典型内容的实践。<br/>验证2<br/>项目经理既定期地也事件驱动地参加评审SCM 活动。<br/>参考软件项目跟踪和监督关键过程域的验证2 以便找到包括项目管理者监督评审的<br/>典型内容的实践。<br/>验证3<br/>SCM 组定期审计软件基线以验证它们符合定义它们的文档。<br/>验证4<br/>软件质量保证组评审和审计有关SCM 的活动和工作产品，并报告其结果。<br/>参考软件质量保证关键过程域。<br/>至少，评审和审计要验证；<br/>1、以下各组对SCM 标准和规程的依照情况：<br/>SCM 组，<br/>SCCB，<br/>软件工程组，和<br/>其它软件一有关组。<br/>2、定期进行软件基线审计的情况。<br/>

[此贴子已经被作者于2006-3-31 14:20:00编辑过]

翔羽

<p>第三章 管理层该做什么<br/>管理层(组织级)的作用是定义组织的结构,职能角色和职责,制定工作方针,对组织内的结构进行&nbsp; 建立组织级的数据库和文档库,组织员工的培训等<br/>3.1先讲一些质量基本概念<br/>3.11什么是软件质量,如何保证软件质量<br/>很多人都把软件的质量活动与软件测试活动混为一谈,理解成保证软件的质量就是加强软件测试力量,软件测试能保证软件的质量吗?<br/>质量指产品或服务，满足规定或潜有需要的特征和特性的总和。它既包括有形产品也包括无形产品；既包括产品内在的特性、也包括产品外在的特性。即包括了产品的适用性和符合性的全部内涵。<br/>软件质量<br/>质量是商品的一种属性,它贯穿商品的整个生命周期,软件质量是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和(ISO 9126)。<br/>软件质量的定义是足够让人难懂，还是拿经典来解释吧，Philip Crosby[CRP97]（Philip Crosby是举世公认的质量运动的主要发起人，曾任ITT集团的副总裁，现任Philip Crosby Associates（克罗斯比顾问公司）及其属下著名的Quality University（质量大学）的董事长）在他的有关于质量的著作里有一个很引人深思的解释：<br/>质量管理的问题不在于人们不知道什么是质量，问题在于人们认为他们自己知道…<br/>在这一点，质量和性（sex）的共同点颇多，每个人都需要它，每个人都觉得自己理解它，每个人都认为实施它只需要遵从自然的趋势（毕竟不管怎么我们都做得不错），当然，大多数人认为如果实施出现问题是由他人引起的（假设他们花了时间就能做好）……<br/>软件质量保证（SQA）是一种应用于整个软件生命周期中对软件过程的保护性活动，它包括1）一种质量管理方法，2）有效的软件工程技术（方法和工具），3）对软件过程采用正式的复审，4）采用一种多层次的测试策略，5）对软件文档及其变更进行控制，6）保证软件遵从软件开发标准的规程，7）度量和报告机制。<br/>软件的质量包括产品质量和过程质量，产品质量是文件、设计、代码和试验的属性，过程质量是指技术、工具、人员和组织机构方面的属性。提出过程质量是因为它有决定软件质量方面的作用，是为实际产品的生产建立一个必要的支持条件。不可能希望以不具备这个条件的工程过程开发出成功的高质量的软件产品。<br/>质量管理包括质量保证(QA)和质量控制(QC),质量保证活动是针对环境来讲的，如方针、规范、方法和流程,它的活动是涉及到全员的,目的是提供创造有质量的产品的流程的保障；而质控是针对工作产品的，如产品评审、同级评审等，当然也包括对软件最终工作产品的验收评审，它的目的是注重于对过程进行监视、检查和测量等，防止偏离要求.<br/>软件测试:<br/>软件测试是软件质量（可靠性）保证的关键活动之一,代表了对约定、设计和编码的最终审查。软件测试是为了寻找错误（缺陷）而运行程序的过程，好的测试用例是指可能找到迄今为止尚未发现的错误（缺陷）的用例，成功的测试是指迄今为止尚未发现错误（缺陷）的测试。（Glen Myers[MYE79]《软件工程。。实践。。。。》P311） 软件测试是软件生命周期中一项非常重要且非常复杂的工作，对软件可靠性保证具有极其重要的意义。当形式化方法和程序正确性证明技术成为实用性方法之后，软件测试活动在软件可靠性保证方法的地位也将随之降低。<br/>就目前来说，软件测试还是软件工程中的一个必须的过程,正如同制造业的质量检测,都是抽检,如果在某一个工序是全检（百分之百检测）的话（例如一些总成装配完成后的功能检查）,那么这个工序就会由检验工序转化为一个正式的生产工序,由负责生产人员而不是质保人员完成，而针对这道工序，还是要由质保人员对其进行抽检（这个抽检活动属于质量控制活动QC）.<br/>当软件开发不需要软件测试就可以保证质量的时候,这时候软件测试就会成为质控活动之一,我想起来印度一个软件公司(过了CMM5),它的一个项目被评为零缺陷,而实际上在该项目的开发过程中就没有正式的软件测试环节.<br/>目前软件开发中的软件测试活动其实是集软件工程开发活动和软件质量控制活动一起的活动。</p><p>3.12什么是项目管理,为什么要采用项目管理来开发软件<br/>项目管理是第二次世界大战后期发展起来的重大新管理技术之一。它作为管理技术复杂的活动，或需要多学科协作的活动的一种特殊工具的价值，才完全被认识，其结果使项目管理成为一种相对来说较新的管理方法，得到迅速发展和不断完善。<br/>开始时项目管理应用于开发大规模的、高费用的、进度要求严的复杂系统而发展起来的。60年代美国只有航空、航天、国防和建筑业愿意采用项目管理。70年代项目管理在新产品开发领域中扩展到了复杂性略低、变化迅速、环境比较稳定的中型企业中。到70年代后期和80年代，愈来愈多的中小规模企业也开始关注项目管理，并将其灵活地运用于企业活动的管理中，到80年代，项目管理已经被公认为是一种有生命力并能实现复杂的企业目标的良好管理方法。<br/>九十年代以后，随着信息时代的来临和高新技术产业的飞速发展并成为支柱产业，项目的特点也发生了巨大变化，许多在制造业经济下建立的管理方法，到了信息经济时代已经不再适用。制造业经济环境下，强调的是预测能力和重复性活动，管理的重点很大程度上在于制造过程的合理性和标准化。而在信息经济环境里，事务的独特性超过了重复性过程，信息本身也是动态的、不断变化的。灵活性成了新秩序的代名词。他们很快发现实行项目管理恰恰是实现灵活性的关键手段。他们还发现项目管理在运作方式上最大限度地利用了内外资源，从根本上改善了中层管理人员的工作效率。于是纷纷采用这一管理模式，并成为企业重要的管理手段。经过长期探索总结，在发达国家中现代项目管理逐步发展成为独立的学科体系和行业，成为后现代管理阶段的管理学的重要分支。<br/>那么什么叫项目？项目是一种一次性的工作，是在规定的时间内，由为此专门组织起来的人员来完成；它有一个明确的预期目标；并且有明确的可利用的资源，它需要运用多种学科的知识来解决问题；没有或很少有以往的经验可以借鉴。<br/>项目可以是开发一枚原子弹，建造三峡工程，盖一栋大楼，一座工厂，或者解决某个研究课题，例如研制一种新材料，设计、制造一种新型设备或产品，如开发一种新型手执通讯设备。这些都是一次性的，都要求在一定的期限内完成，不得超过一定的费用，并有一定的性能要求等。所以，有人说项目是新企业、新产品、新工程、新系统和新技术的总称。<br/>一般来说项目具有以下的几个特点：<br/>1）项目由多个部分组成，跨越多个组织，因此需要多方合作才能完成； <br/>2）通常是为了追求一种新工程或产品才组织项目； <br/>3）可利用资源预先要有明确的预算； <br/>4）可利用资源一经约定，不再接受其他支援； <br/>5）有严格的时间界限，并公之于众； <br/>6）项目的构成人员来自不同专业的不同职能组织，项目结束后原则上仍回原职能组织中； <br/>7）项目的产物其保全或扩展通常由项目参加者以外的人员来进行。<br/>什么叫做项目管理？美国项目管理学会在《项目管理知识指南》中的一段话来了解项目管理的轮廓："项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内完成项目的各项工作，有效的项目管理是指在规定用来实现具体目标和指标的时间内，对组织机构资源进行计划、引导和控制工作。"具体来说就是在一个确定的时间范围内，为了完成一个既定的目标，并通过特殊形式的临时性组织运行机制，通过有效的计划、组织、领导与控制，充分利用既定有限资源的一种系统管理方法。<br/>软件产品的商业化生产，特别是软件工程已经为广大公司认可并实施了之后，使软件开发的过程可控成为现实，通过项目管理的方法可以在最短的时间内将资源紧密的结合在一起,并且使之发挥最大效益,能够较其它的管理方法更快地完成任务,能够成功地解决简单的问题.当然对于软件开发,也有不按照项目管理的方式进行管理的,例如有民主分权制(Democratic Decentralized,DD)的软件开发方式(DD的软件工程小组没有固定的负责人,”任务的协调者”是短期拟定的,之后由其他协调不同任务的人取代.问题和解决方法的确定是由小组讨论决策的),DD结构则适于解决难度较大的问题,能够产生较高的士气,适合生命周期较长的小组,它适合解决难度较高,对效率要求不严格的问题.<br/>现代企业管理非常注重团队和团队的凝聚力,团队可以是一个组，一个部门，也可以是一个公司或者组织，当团队具有真正的凝聚力的时候,他们的整体力量就会大于个体力量的总和,他们具有更高的生产率、项目的成功率和更高的动力。</p><p>2.2看看我们的日程表<br/>CMM2过程改进活动是以项目管理为主进行推行,对于已经实施软件工程的公司,包括已经实施了ISO9000系列标准化质量管理的公司来说,CMM2过程改进的工作量并不大,而且相对公司来说改进的风险也不大,但是对于一个还没有启动软件工程的公司来说, CMM2的改进就必须和软件工程的改进一起进行,相对于公司来说所涉及的范围和影响就很大了,这可能涉及到公司内部的组织重组,而且相应流程将重新设计.而且相对于公司的正常运营来说影响也比较大,特别是这些改进将建立在员工知识的培训,技能的提高之上,要求员工适应新的工作及环境,要求人们有新的行为方式,这些都将会把员工和经理们压得喘不过气来.不过不论对员工还是公司,这都是一个脱胎换骨的好机会.<br/>在确认公司要进行CMM2过程改进之前,建议公司组织一下管理层对CMM2的正式调研,当大家都统一对CMM的认可之后才决定改进,不只是CMM,所有的改进活动都是有风险的,CMM不是万能的,如果CMM不能给公司带来效益,那么就不应该执行CMM,这也是CMM的初衷.CMM的目的是为了提高软件企业的质量能力,开发出高质量的软件产品,其核心还是为了保证企业的商业行为,所以大家不要以为当市场需要一个风险极高的项目时,CMM会建议说不,而相反,它会建议企业根据商业需要去做.<br/>本书提供一个CMM2过程改进的过程安排来供大家参考,当然这里的改进计划是从公司里建立基本的软件工程开始的.如果已经实施过软件工程的企业,则可以将有关基本软件工程的活动去掉.</p>

翔羽

尚未结束，有待继续！谢谢各位！

翔羽

<p>成立过程改进活动领导小组,活动落实到具体的责任人.安排一个过程改进计划,并且定时对计划进行监督.<br/>XX公司CMM2过程改进日程表<br/>序号&nbsp;工作内容&nbsp;项目&nbsp;时间&nbsp;参加人员&nbsp;备注<br/>1&nbsp;CMM调研&nbsp;CMM的内容<br/>CMM实施方法<br/>CMM实施成本和效益<br/>CMM实施风险&nbsp;22天&nbsp;公司总经理、负责软件产品开发的总监、负责软件开发的部门经理&nbsp;建议请已经通过评审的同行或咨询公司讲解<br/>2&nbsp;企业领导决策&nbsp;确认公司按CMM2进行软件工程过程改进<br/>确认公司实施的目的<br/>确认公司所需解决的问题<br/>明确成本、范围和时间等要求&nbsp;1天&nbsp;同上&nbsp;<br/>3&nbsp;成立工作组&nbsp;成立CMM2推动小组<br/>确定咨询顾问人员<br/>(成立SEPG小组)&nbsp;2天&nbsp;&nbsp;<br/>4&nbsp;制定实施计划&nbsp;确定实施时间表<br/>确定阶段目标<br/>确定阶段责任部门和责任人<br/>确定改进例会时间&nbsp;5天&nbsp;&nbsp;<br/>5&nbsp;基本软件工程理论培训&nbsp;软件产品与开发过程<br/>软件项目管理<br/>传统软件工程方法&nbsp;1天&nbsp;开发全体人员&nbsp;<br/>6&nbsp;CMM2基础知识培训&nbsp;软件工程概论<br/>软件能力成熟度模型SW-CMM简介<br/>软件能力成熟度模型SW-CMM的价值<br/>软件能力成熟度模型SW-CMM的结构<br/>CMM的评估流程及内容(CBA-IPA简介)<br/>CMM2级评估时各KPA审核内容及通过标准&nbsp;1天&nbsp;&nbsp;<br/>7&nbsp;成立相关正是组&nbsp;软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组&nbsp;3天&nbsp;&nbsp;除了质量保证组以外其它组可根据企业自身情况调整,机构可以适当合并，成员可以身兼数职<br/>8&nbsp;需求管理（RM）培训&nbsp;需求变更<br/>需求风险<br/>需求管理<br/>需求跟踪&nbsp;&nbsp;&nbsp;解决如何有效获取需求分析的过程、方法和工具.<br/>10&nbsp;项目管理（SPP软件项目计划）培训&nbsp;项目策划（WBS方法，PERT等工具，资源，成本，计划样本）<br/>项目估计（功能点估计，COCOMO模型， Delphi方法）<br/>风险管理（风险识别，估计，策划，解决）&nbsp;&nbsp;&nbsp;解决如何规划软件项目的计划和进度安排<br/>如何进行软件项目工期控制与项目预算<br/>如何把软件项目的风险减到最小<br/>11&nbsp;项目管理（SPTO软件项目跟踪与监控）培训&nbsp;项目控制（数据采集样本）<br/>项目管理工具（资料）&nbsp;&nbsp;&nbsp;解决如何控制项目,对项目进行审核<br/>12&nbsp;软件质量保证（SQA）培训&nbsp;质量概念和模型介绍<br/>SQA策划(计划样本)<br/>过程审核<br/>审核过程<br/>工作产品评审&nbsp;&nbsp;&nbsp;如何保证软件过程质量<br/>13&nbsp;软件配置管理（SCM）培训&nbsp;SCM计划<br/>配置标识<br/>变更管理<br/>版本控制<br/>配置审核<br/>配置状态报告<br/>配置工具（资料）&nbsp;&nbsp;&nbsp;<br/>14&nbsp;软件分包管理培训&nbsp;软件子合同管理，可重复级的一个关键过程域 <br/>软件转包合同管理的概念 软件转包合同管理的基础 <br/>软件转包合同管理的活动 软件转包合同管理的评价&nbsp;&nbsp;&nbsp;<br/>15&nbsp;业务流程分析,制定缺陷改进计划&nbsp;明确企业现行软件开发组织机构<br/>明确企业现行软件开发质量状况<br/>明确企业现行软件开发质量管理状况<br/>明确企业现行资源状况<br/>明确企业现行质量活动状况<br/>明确企业现在软件开发业务流程<br/>制定缺陷改进计划<br/>由培训组制定培训计划&nbsp;10天&nbsp;&nbsp;对当前的工作流程进行分析、整理及文档化，从而制定出一个具有本企业风格的软件过程，并用该文档化的过程指导软件项目的开发<br/>16&nbsp;建立过程数据库&nbsp;过程小组的成员还应该维护过程中的数据库，定期统计各个过程中的产品和规模、开发周期、修改次数及评估周期。这些数据库可用来分析项目的效率以及存在的问题，以便今后进一步的改进，同时还可以为项目开发实事求是过程提供咨询&nbsp;&nbsp;&nbsp;<br/>17&nbsp;编写相关文件&nbsp;制定工作方针,<br/>确定活动方法<br/>确定活动流程&nbsp;&nbsp;&nbsp;<br/>18&nbsp;按计划实施&nbsp;完善工作方针<br/>等&nbsp;&nbsp;&nbsp;重复三次<br/>19&nbsp;培训内审员&nbsp;内审的目的<br/>内审的方法&nbsp;&nbsp;&nbsp;重复三次<br/>20&nbsp;内部审核&nbsp;对工作过程的审核<br/>对工作方法的审核<br/>对工作结果的审核&nbsp;&nbsp;&nbsp;重复三次<br/>建立请第三方审核员(内审员)参加<br/>21&nbsp;制定整改计划&nbsp;&nbsp;&nbsp;&nbsp;重复三次<br/>22&nbsp;总结&nbsp;&nbsp;&nbsp;&nbsp;</p><p>以上的日程表中的培训是必须组织的,而且应该由专业的人员进行培训,建议由企业找专业CMM咨询师或专家进行培训,这是很有必要的,可以为企业节省大量的人力和物力.<br/>有关技术和工程细节的培训,应由培训组负责计划并组织.<br/>培训可能涉及到的内容有:<br/>软件需求分析原理<br/>规模估计的方法<br/>软件生命周期<br/>软件项目管理<br/>部分工具的使用(MS project)<br/>部分方法(EV)等等<br/>该计划在过程中将依次导出以下几个子计划:<br/>培训计划<br/>过程改进计划<br/>预评审计划<br/>再次改进计划<br/>那么我们就按照日程一步一步来(Step by Step)</p><p>3.3 准备活动<br/>准备活动包括对CMM调研,制定过程改进的决策,成立推动小组等.<br/>3.31 CMM调研<br/>CMM调研对企业来说极为重要,它的结果将决定企业是否推行CMM,推行CMM会给企业带来哪些好处,企业在推行过程中将有多大规模的变动,涉及到多少人,多少项目,多少钱,多少设备等等.<br/>对CMM的调研,首先应该了解CMM的具体内容,大家可以参考中文的CMM1.1标准,多听一听有关CMM和软件过程的培训,熟悉并了解CMM的结构,各级别之间的关系,如何实施等等.<br/>当然对CMM的调研属于决策性或者说是战略性的活动,负责CMM调研的人必须对公司的管理足够熟悉，在高级管理层中有足够的信誉和影响，或者本身就是高级管理者。<br/>对CMM的调研应着重于以下五点的调查研究。<br/>1.企业能获得的好处<br/>所有企业的目的都是为了利润,企业的所有活动的目的也都是利润(法律法规不在此范围之内),这是改进在企业内部推行的内在力量.<br/>2.时间<br/>一般来说,企业达到CMM2需要3年左右的改进,当然时间不是死的,工业革命英国花了80年,而法国则用了40年,以我国的情况来看,一般计划一年到一年半的时间比较合适,时间过短对企业有害无利,千万不要制定一个打算三四个月就通过CMM2的规划.<br/>3.资源<br/>资源是指改进活动涉及到组织、人员、项目、资金、设备等，例如说有的企业没有质量保证组，如果没有就一定要建立起来，有没有配置管理人员，如果没有也必须要增加，其它的组和职位都应根据企业的实际情况进行合理调配；确认公司按CMM2进行软件工程过程改进确认公司实施的目的确认公司所需解决的问题，另外，如果公司打算参加相关培训或请外部培训人员，也应算入成本中去。<br/>4.风险<br/>CMM2的过程改进对于某些公司来说是波涛汹涌的事情，管理者和经理们必须抛弃陈旧的策略计划，这并不是一件简单的事情，它有太多的未知数，太多的可预知的阻力。<br/>第一大风险来自于管理层的分歧，主要的变革必须是自上而下具备战略眼光，需要在设计和实施过程中有广泛的参与性。至少在开始阶段，主要的变革方案必须由高层管理人员积极引导。高层管理人员往往对变革的必要性及方向达成共识，通常在变革方案实施的头几个月中，一旦高层管理层成员领悟到变革的真正含义，他们以前所做的努力就会付诸东流，有时这种分歧导致对峙，并由此展开辩论和商讨，在达成共识后继续推进，但有时分歧是悄然而至，一旦这种情况发生，分歧便以延缓变革活动的方式出现，最后变革计划失败。一旦出现分歧，千万不能存一线希望“但愿能通过”，更不能自欺欺人地认为已经达成共识。这时候管理层必须至少在三个方面取得共识情况下以重新开始努力，①我们为什么要这样（要变革的经营情况）？②我们做什么，怎么做（变革的过程是怎样，对哪些地方进行变革）？③谁负责变革（谁对变革的设计及结果负责）？无论是变革开始还是遇到分歧时，对这三个问题的辩论的深度将会使我们知道是否已准备好开始或者重新开始。<br/>第二大风险是规模风险，也就是说改进活动所涉及到的人员、项目、组织的规模。有人建议先从小项目试点，但我不赞同，詹姆斯•••A•钱普（James A.Charmpy）在他的文章里有一段叙述：<br/>“……我仍认为一项变革变形的规模越大，其成功的可能性也越大。我承认我的观点常会遭到反驳。……一项渐进的变革方案会遭遇太多的冲突性看法。这些冲突有时是悄然发生的，你甚至不知道是如何发生的，而事实上有时却是什么也没发生！人们只是陷入无穷无尽的讨论和研究中，就是没有采取任何行动。企业组织内部的抗体正悄悄地吞噬着变革事业。但是如果变革计划庞大，并得到高层管理者们的投入，企业组织必须面对所有变化所需的场面，没有必要躲躲闪闪，也就不会再维持原状。其结果——或许没有结果——都是昭然若揭的。但是最后要记住，工业变革程度和管理雄心将决定公司经营和组织变革的规模。这种变革可能会使我们气喘吁吁，但我们只能如此，不可能选择放慢速度……”<br/>第三大风险是转变风险——管理观念转变的风险。因为在实施的过程中涉及到了人们传统思想观念的转变、机制的转换、管理方法的改变、管理基础的改善、业务流程的重组、组织结构的调整、责权利的再分配等一系列实际问题。<br/>强化培训，进一步提高企业员工，特别是对高层管理者和经理们的培训，加强对CMM的理解。<br/>然后是技术风险，相对来说技术风险并不是很高，特别是在CMM2级。<br/>加强技术培训，如项目管理培训，风险管理培训等<br/>其余的就是资源风险，人、财物的风险，时间和进度控制风险，成本控制风险等，就不一一描述了。<br/>5同行和竞争对手以及产业政策的情况<br/>这是调研报告中必不可少的一部分，这里就不具体说了。<br/>调研活动完成后，应该出具一份方式的调研报告。</p><p>3．32 决策<br/>在公司高级管理层决策是否进行CMM的过程改进之前，必须真正明确几个问题，①我们为什么要这样（要变革的经营情况）？②我们做什么，怎么做（变革的过程是怎样，对哪些地方进行变革）？③谁负责变革（谁对变革的设计及结果负责）？对这三个问题的理解和认同，是企业实施CMM过程改进活动的动力基础。<br/>公司高级管理层依据调研的结果决策是否启动CMM2过程改进，何时启动，谁负责，涉及哪些部门和人员，允许时间，允许的成本，改进目标和验收标准。<br/>成立推动小组，由公司高级管理层负责CMM2过程改进的管理者负责，小组成员应是公司内具有丰富经验并且是工作核心的人员。<br/>根据公司情况决定是否成立软件过程组（SEPG），如果公司已经实施了软件工程，那么在2级可不必建立软件过程组，如果还没有实施软件工程，则可成立软件过程组以加快软件工程的实施。<br/></p>