《CMMI简明培训教材-18过程域.docx》由会员分享，可在线阅读，更多相关《CMMI简明培训教材-18过程域.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、CMMI基础培训CMMI包括18个过程域：1 评估2 投标3 合同评审、立项4 总体计划（项目启动）5 原形开发6 需求分析7 总体设计（概要设计）8 详细设计9 功能开发10 代码走查11 产品集成12 集成测试13 试运行（用户测试上线运行）14 初验15 初验维护16 终验17 终验维护18 结项报告在CMMI评级过程中，上面的18个过程域都必须提供证据，即所谓的PIID。名词解释：PIID：Practice Instantiation Indicator Document实践的实施证据文档SR - Senior Management, PL - Project Lead, DEV -
2、Developer, SQA, SCM. RM, SEPG随着人们对CMM研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的CMM 模型。例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等：（1） SW-CMM （Software CMM） 软件CMM（2） SE-CMM （System Engineering CMM） 系统工程CMM（3） SA-CMM （Software Acquisition CMM） 软件采购CMM（4） IPT-CMM （Integrated Product Team CMM） 集成产品群组CMM（5） P-CMM （People CMM） 人力资源
3、能力成熟度模型CMMI三级18个过程域中属于项目管理类的过程域:A、B、C、D、REQM: Requirements Management（需求管理）PP: Project PlanningPMC: Project Monitoring and Control（项目监控）MA: Measurement and Analysis（度量分析）PPQA: Process and Product Quality Assurance（过程、产品质量保证）CM: Configuration ManagementRD: Requirements DevelopmentVER: Verification（文档
4、评审、系统测试）VAL: Validation（项目验收、发布许可）TS: Technical Solution方案选择表PI: Product Integration（产品集成）OPF:Organizational Process Focus（组织过程焦点）OPD:Organizational Process Definition（组织过程定义）OT: Organizational Training（组织培训）IPM: Integrated Project Management（集成项目管理）RSKM: Risk ManagementDAR:Decision Analysis and Res
5、olutionCMMI2级简述如果对项目的范围、规模、性质、任务、工作量、费用等都不了解的情况下，是不可能做出 计划的，所以做好计划的第一步就是要把这些东西搞清楚。PP这个PA的第一个Specific Goals， 中文大意是：建立和维护用于项目计划的各类参数的估算，英文原文是：Estimates of project planning parameters are established and maintained.下面我们再详细看看，到底做计划之前，需要搞清楚什么东西？SP1.1：Estimate the Scope of the Project. 估计项目的范围，如项目的目标、任务、工
6、作产品 等。这里通常就是指WBS(top-level work breakdown structure)，试想一下，我们做计划之前不 是常常要先对任务进行分解吗？SP1.2: Establish Estimates of Work Product and Task Attributes. 估计工作产品及任务的属性。 做计划的时，我们会先列出这个项目要产生的工作产品，以及这个项目要完成的任务等，然后我 们需要分析这些任务、工作产品的规模、工作量、复杂度、代码行数等所谓的属性。CMMI并没 有规定一定要分析什么属性，具体由企业自己来选择适合自己需要分析的属性。在CMM模型的 时候，项目计划这个PA
7、硬性规定了需要分析的几大属性，CMMI模型中已经改进，不再强制要 求。分析这些属性的目的是对任务、工作产品等更加了解，以便于做好计划。SP1.3 Define the project life-cycle phases upon which to scope the planning effort. 定义项目生 命周期。写计划的其中一个步骤是要考虑用什么生命周期模型，是瀑布型？螺旋？还是别的？选 择怎样的模型，CMMI并没有规定，企业可以选择常见的生命周期模型，也可以自己定义自己的 模型。CMMI3级简述2级其实有很多问题还没有解决的，细心的人会发现，2级对软件工程活动的指导很弱， 如：需求开
8、发、设计、编码、测试等。在3级，你会发现：1)有指导需求开发的需求开发(Requirements Development)这个PA；2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA；3)有指导如何保证工作产品满足要求的验证(Verification)；4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产 品集成(Product Integration)；2级的PP与PMC是直接与项目管理有关的两个PA，在3 级，对项目管理的要求进一步提高：6)集成项目管理(
9、Integrated Project Management)：3级的项目管理，要求利用组织级 的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理 项目。7)风险管理(Risk Management)：2级只有PP的SP2.2中提到要识别风险，而在3级专 门有一个PA对风险管理提出更高的要求。大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。3级的IPM和RSKM， 除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM 要求要有组织级的风险管理策略等。另外，3级有几个“O”开头的PA，这几个PA都 是直接对组织级的提出要求。8)
10、组织过程焦点(Organizational Process Focus)：这个PA要求组织成立SEPG来推动过 程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。9)组织过程定义(Organizational Training)：这个PA要求组织级建立财富库，财富库内 容要包括标准的过程、裁剪库、度量库、生命周期模型等。10)组织培训(Organizational Training)：要求组织根据商业目标要求准备并提供培训。3 级还有一个很特别的PA：11）决策分析及解决方案（Decision Analysis and Resolution）：这个PA提供了一个如何做 出最佳
11、决策的方法指导。软件行业很多重要的决策，如设计方案、采购方案等，都可以 应用这个PA提供的办法，另外也可以在组织过程改进中应用决策分析的办法。总结一下3级的几个重要特点：1）明确规定了需求开发、设计、编码、测试、集成等软件开发各过程的要求。2）对项目管理提出了更高的要求，要利用组织级的数据来管理项目。3）出现了专门针对组织级的PA，要求有专门的组织来负责过程改进的工作。4）提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以用于组织级 过程改进。由这些特点大家可以看到，3级已经对软件开发的各个方面有了详细的要求，2级很多 不明细的地方全部已经明确。一个达到3级的企业，肯定会定义了很
12、多软件开发各个方 面的过程，并且会有组织级的财富库。所以3级叫“已定义”级。补充说明：3级还有另外3个PA上文没有提到，分别是Integrated Teaming、Organizational Environment for Integration：对大型软件团队提 出了要求，一般情况下中小型软件企业可以NA。Integrated Supplier Management：如果软件企业需要管理大量的供应商，则需要考虑 这个PA。这3个PA大部分情况下不需要考虑，将暂时不展开详细的讨论。CMMI4级简述2、3级已经对软件开发的方方面有了详细的指引，4级还会有什么更高的要求呢？4级叫定量管理，那什么
13、叫定量管理？微软的MSF达到CMMI几级水平呢？是不是所有企业都适合做CMMI4级呢？大家都知道软件开发是智力劳动，量化谈何容易。作为企业老板来说，希望能对自 己的软件生产过程进行强有力的控制，量化管理自然就会提到议程。4级的定量管 理是有一定的基础要求的，进行定量管理的项目必须是性质近似的，生产过程类似 的，这样才可能在一段时间类积累了一堆有同类可比性的数据，对这些数据进行统 计分析后才可能得出用于项目控制的基线。简单的说，所谓的定量管理，就是利用 经验数据得出的指标，对将来的项目进行管理。如果一个企业已技术创新为主，项目间可比性低，这样是不太可能做4级的。就好 象微软，微软不断的研发新产品
14、、新技术，微软也是不太可能做到4级的。微软的 MSF，大概就达到CMMI3的水平。首先要向大家澄清一个误区，软件企业并不是越高级越好的，其实4级的管理不太 适用于创新型的企业，因为无法形成基线。当然创新性的企业，也可能会有相对稳 定的过程，这些过程是可以实施4级管理的。4级只有两个PA，就是：组织过程性能(Organizational Process Performance )定量项目管理(Quantitative Project Management)OPP是对组织级的要求，组织需要统计出组织级的基线；QPM是对项目的要求，项 目要用组织级的基线来控制项目过程。两个PA都很复杂，其中OPP的
15、SP1.4建立性能基线，SP1.5建立性能模型，两者工 作量就可以是2、3级几个PA的总和。CMMI5级简述5级的企业，是如何做到“持续改进”呢？其实一个软件企业，要提高生产力，有3方面途径：1)改进过程，使现有的过程更强更有效。2)引入新技术，提高生产力。3)对工作出出现的问题进行原因分析，避免以后再次出现。改进过程、引入新技术都是有风险的，不能盲目改进过程，也不能盲目引入新技术，新 过程、新技术也不能一下子推广到整个组织，可能需要先试行，然后逐步推广到整个组 织，在实施过程中，需要监控整个情况并评估改进的效果。组织革新与部署(Organizational Innovation and De
16、ployment )这个PA给出了明确的指引。 工作中发现的每个问题，其实都是改进的机会，但实际工作中发现的问题可能非常多， 需要选择最有价值的问题进行深入分析，并避免其再次发生。通过不断地修复问题，组 织的生产力就会不断提升。原因分析及解决方案(Causal Analysis and Resolution)这个PA给出了明确的指引。5级就只有OID和CAR两个PA，两个PA对3个可以提高企业生产力的途径进行了指引， 只要把OID、CAR做好，企业就可以“持续改进”了。CMMI-ACQ随着信息与网络科技之快速发展与应用普及，对政府机关及民间企业都造成 极大的冲击。政府机关对内要因应民意高涨与服
17、务水平要求不断提升，对外则需面 对国际间追求提升国家竞争力的压力；民间企业则由于产业环境的激烈竞争，迫使 企业必须重新思考与评估内部的营运活动，辨识企业的核心能力，集中资源专注于 核心活动以创造竞争优势。因此，藉由委外导入信息技术，提供高效率、低成本， 富有弹性而快速反应的服务，已势必成为政府机关及民间企业一股不可遏止的潮流。信息业务委外虽可对组织产生效益，但也会带来一些风险。根据Standish Group International 在报告中说明，有15的软件项目终究没有完成，并有超过 80的软件项目延宕，并且超过预算；2000年的统计报告中，只有26的软件项 目成功，另外的74都是失败。
18、多位学者从影响委外绩效之原因、委外的困难、委 外成功因素等不同观点作出研究，归纳出信息系统委外所遭遇最主要的困难为质量 不确定、项目时间的延长与成本超乎预算。所以，为了在合理的成本与预定时程内， 交付高质量的软件，软件工程领域的专家学者们，不断地研究改善各种软件开发技 术与方法。然在软件筹获组织为提高委外软件质量而要求软件开发组织的资格评鉴或管 理能力认证之余，却往往因本身的筹获流程相对不成熟，没有标准的作业程序，无 法做好软件筹获规划、监控等重要工作项目，进而影响软件委外项目的成功。基于 上述问题， CMU/SEI 相继发展了软件筹获能力成熟度模式(Software Acquisition
19、Capability Maturity Model，SA-CMM)、能力成熟度整合模式筹获模块(CMMI Acquisition Module，CMMI-AM)及能力成熟度整合模式筹获(CMMI for ACQuition，CMMI-ACQ)，用以评估及改善软件筹获流程。SA-CMM介绍能力成熟度模式(CMM)是由美国卡内基美隆大学软件工程学院所发展，以 作为软件生产全面质量管理与流程改善的架构。1987 年第一次发表研究成果，并 于1991 年正式发表CMM V1.0 版。一般称CMM通常是指软件能力成熟度模式SW-CMM，相较SW-CMM之于软 件组织为改善其软件开发效能，SA-CMM 则
20、为软件筹获组织为改善信息委外流程， 以达到筹获高质量交付软件的成熟度评估模式。简言之，在藉由订定契约而获得软件的流程中，SW-CMM 描述的是一个好的 软件开发者所必须要具有的能力，而SA-CMM 描述的则是一个好的软件筹获 者所必须要具有的能力。成熟度 等级重点关键流程领域5最佳 化级持续流程 改善筹获创新管理持续流程改善4定量 级定量管理定量筹获管理定量流程管理3已定流程标准训练计划管理筹获风险管理合约执行管理项目执义级化行管理使用者需求流程定义及维护2可重基础的项移转支持评估合约追踪与监督项目管理需求发展复级目管理及管理招标软件筹获规划1初始 级胜任的人们及英雄式主义StagedCont
21、流程管理专案管理支援筹获Level 5组织创新与发 展原因分析与解 决方案Level 4组织流程绩效量化专案管 理Level 3组织流程专注 组织流 程定义组织训 练整合专案管 理风险 管理决策分析与解 决方案筹获需求发 展 筹获技术解 决方案 筹获确认 筹获验证Level 2需求管理 专业规划 专业监控 建构管理流程与产品 品质保证度 量与分析筹获管理 招标与供应 商管理SCAMPI的变化CMMI Version 1.2 SCAMPI A Appraisal Method ChangesSCAMPI A类评估方法v1.2变更的主要方面1. 减少评估方法的复杂度和模糊性2. 在需要的地方提供附
22、加指导3. 强化评估规划和实施4. 强化了对评估的报告5. 定义评估的有效期限6. 强化对主任评估师的要求减少复杂度删除了对评估工具(例如：调查表)的要求目前仅需要两种类型的客观证据： 文档 访谈下列章节在方法定义文档(MDD)中被修订： 交换2.2节“验证和确认客观证据”和2.3节“文档化客观证据”的顺序，这样任务的顺 序能够放映评估过程的自然顺序 为了更好地描述每个过程，把“验证客观证据”和“确认初步的发现(findings)”分开 改变了术语“实例(Instantiation)”的使用： 实例(Instantiation)目前被定义成：模型相关实践在一个组织单元内的实施； 实例(Inst
23、antiation)针对项目和组织级实体的应用被“项目(Project)或”“支持团队 Support Group)”替代减少模糊性澄清评定“不予评级(NotRated)”的概念 模型范围之外的过程域(PAs)被定为：范围之外(Out of Scope)。例如，对于一个 成熟度级的评估，成熟度级和五级的过程域被定为“范围之外(Out of Scope)” 对于没有充足数据评定的过程域，评级为：不予评级(Not Rated) 在模型范围内但在组织范围外的过程域(PAs)被定为：不适用(Not Applicable)。仅有 一个过程域SAM能被定为不适用(Not Applicable)(这由评估团
24、队决定)。实践特征表被修订： 澄清了虚拟访谈和实况访谈的使用 把“面对面访谈(face-to-face interviews)”改变为“口头访谈(oral interviews)” 附加指导扩大了预评审(readiness reviews)指导涵盖的范围，包括团队和后勤准备 对使用虚拟方法提供附加指导(例如，对访谈和简报等)为可选实践提供附加指导(例如,附录C：可选实践识别和特征指导) 强化评估规划和评估实施组织单元取样(sampling)被修订为：(详细参见：方法定义文档MDD) 强化组织取样的要素和限制(例如，识别出最小数量的聚焦项目) 增加报告取样决策的标准目前实施评估阶段必须在90天内
25、完成目前评估团队成员必须签署最终评估发现(final findings)。基于基线化1的迭代2开发和风险管理3 策略 亚远景科技项目研发管理专题系列(1)作者：杨俊 庞丽IPMS(Integrated Project Management System)，是一个为上海贝尔阿尔卡特某 移动事业部门定制化开发的多系统集成项目管理系统，其目标是通过对该部门整个开发 管理工具环境的集成来达到对项目的实时跟踪和管理，以及数据的采集和度量。然而， 一个客观事实是，国内大量的中小型项目中的绝大多数都存在着需求不明确性的问题， 伴随而来的是大量需求变更所带来的开发风险。那么面对这样的客观事实，是否意味着 项目
26、经理根本无法应对这样的问题呢？真正优秀的项目经理又会如何挑战需求不明确 和需求变更所带来的开发风险呢？案例背景背景描述1: 随着阿尔卡特与朗讯科技的合并，该移动事业部门也将与原两家公司 的多个部门进行合并。合并后的新部门将采用全新的产品线定义，并实施新的项目管理 流程。在这样的情况下，以前的IPMS系统已经无法满足该事业部门对项目的流程管理， IPMS系统三期开发势在必行。背景描述2: IPMS系统作为一个集成化的管理系统与众多功能强大的软件系统集成， 其中包括ClearQuest，一个强大的事务状态管理软件。原先IPMS与ClearQuest通过一 组ClearQuest软件预先定义的API进行数据通讯。提出问题由于合并的时间过于仓促，以及部门之间的项目数据定义和管理流程的不同，导致 IPMS三期开发的需求极不明确，整合后的新部门内部还在为部门的项目管理的流程定 义和系统可能的功能修改争论不休，在这样的情况下，项目进展十分缓慢。IPMS三期的第一个迭代中有这样一个非功能性需求，即ClearQuest的版本升级， 随之而来的一个风险便是，伴随着ClearQuest的版本升级，没有人知道原版本中与IPMS 数据通讯的API接口是否可以向下兼容。