logo资料库

CMMI1.2版本升级1.3后变化及相关敏捷模型.doc

发布时间：2022-06-06 发布人：admin 分类：说明书 资料大小：0.03M 资料格式：doc 举报 版权申诉
第1页 / 共6页
第2页 / 共6页
第3页 / 共6页
第4页 / 共6页
第5页 / 共6页
第6页 / 共6页
资料共6页，全文预览结束
    解读 CMMI-DEV1.2 到 1.3 的变化 2010 年 12 月，CMMI DEV1.3 正式发布。在 CMMIV1.3 发布前，SEI 作了大量的宣传，称 1.3 有很大的改进。的确如 SEI 遵循的原则，CMMI 模型要体现业内的最佳实践(Best Practice)。CMMI DEV1.3 在吸纳目前业内的一些好的实践的同时，还吸纳了 ISO 以及 PMI 的一些新的成果。其主 要变化包括： 1、 吸收了敏捷软件开发的实践。在配置管理（CM）、技术解决方案（TS）、产品集成（PI）、 验证（VER）、确认（VAL）、需求管理（REQM）、质量保证（PPQA）等过程域中，对敏 捷软件开发相关一些实践作了说明； 2、 对高成熟度的 4 个过程域作了较大优化，以“反应业界的最佳实践”。感觉现在这几 个过程域的实践不再像之前那样高不可攀，很多解释似乎不再像从前那样机械，而且把 过程改进目标与组织商务目标相联系，增加了一些具体的例子，对实践有一定指导作用。 同时，该版本中删掉了原来高成熟度等级中的共性目标。连续型模型中只包含了 3 个级 别，不再有高成熟度等级。 3、 更加重视需求管理：该版本将需求管理（REQM）过程域从工程组（Engineering）移至 项目管理组（Project Management）。 4、 更加关注结果。这表现在一些名词的提法，如：  “管理过程(Manage Process)”变成“管理项目(Manage Project)”；  共性实践 GP2.6 的标题从“管理配置项”更改为“控制工作产品”，虽然内容基 本没有变化；  共性实践 GP2.9 “客观评价依从性”中将原来“客观评价过程的依从性”，更改 为“客观评价过程和工作产品的依从性”； 5、 吸纳了 ISO、PMBOK 等的一些最新成果。例如：  原来的“需求”变成了“功能需求和质量属性（Quality Attributes）”;  增加了架构评审的一些实践  更加强调各过程与组织商务目标的关系 6、 其他：删除了所有 IPPD（Integrated Product and Process Development）的相关内 容。（事实上，IPPD 是在 1.2 版中强塞进去的，与模型的其它部分融合度很差。） 下面按照成熟度等级对各 PA 的变化进行简要说明。 二级过程域的主要变化 1 CM(Configuration Management) ——配置管理  变化点  在配置项的例子中增加硬件、环境配置、工具等内容  强调了基于核心产品的产品线开发中，多分支配置管理的复杂性  强调了在敏捷开发环境中进行频繁变更、持续集成，导致配置管理工作的复杂性和 重要性  敏捷开发 在 Agile 环境中，配置管理非常重要。由于要支持经常性变更、经常性构建(通常是每 日)、多重基准、以及多重工作场所(例如，对个人、团队、甚至是结对程序)，如果配置管 理做不到下列各项，则 Agile 团队可能陷入泥沼：1) 自动化 CM (例如，build scripts、
    状态记述、完整性检查)；2)将 CM 当成标准服务执行：在启动的时候，Agile 团队应明确配 置管理负责人；在每一个迭代周期开始，需要重新确认配置管理的支持是否到位。而配置 管理责任人的目标是将配置管理工作谨慎地整合到团队的工作节奏，最小化开发人员重点 工作外的其它工作量。 2 PPQA (Process and Product Quality Assurance) —— 过程和产品质量保证  变化点  在 SP2.2 中增加评估工作产品的时机的例子。  增加敏捷开发模式下的质量保证活动建议  敏捷开发 在 Agile 环境中，团队倾向于将焦点聚集在本迭代的立即需要上，忽略较长期的且更 广泛的组织利益需要。为了确保客观评估的效果，使之具有价值和效率，需尽早确定：(1) 客观评估如何完成；(2)要评估哪些过程与工作产品；(3)评估的结果要如何整合到团队的 节奏中(例如，融合到每日例行会议、检查表、同行评审、工具、持续集成等等活动中)。 3 PP (Project Planning) —— 项目规划  变化点：  增加对计划的解释，既可以集中在一个文档中，又可以分散  在 SG1 中删掉了影响估算因素的项目属性的具体说明  SP1.3 标题“定义项目生命周期”改为“定义项目生命周期阶段”，计划内容中增 加“里程碑”  在项目进展状态评审中强调对客户满意度度量结果的评审  估算方面作了较多修改  敏捷开发 对于产品线，多种工作活动集能获益于项目规划过程，这些工作活动包括核心资产的 创建与维护、建立在核心资产上的产品开发、以及整个产品线中相关联的小组之间活动的 协调。在 Agile 环境中，实现增量式开发，比传统方法需要更为频繁执行计划、监视、控 制、以及重计划活动。虽然会建立整体项目的高层计划，但是团队是以一个增量或迭代进 行估算、计划，并执行实际的工作。除了预期的风险、重大事件、以及大规模的影响与限 制条件外，团队通常不对项目未知的部分做预测。估算值反映出影响完成该迭代的时间、 成本、资源、以及风险等特定的因素。每一迭代周期内，计划、监视、以及调整计划成为 经常性的工作。在迭代计划过程中，一个周期完成的任务从待完成的功能中选取，用例细 化后用于估算，一旦工作任务分配到个人，对计划的承诺是必须的 二级过程域的主要变化 4 PMC (Project Monitoring and Control) —— 项目监控  变化点：  增加对里程碑评审的详细说明  （监控风险一节）强调项目进行过程中需要不断识别新的风险；
     监控干系人参与中强调敏捷开发中客户和最终用户参与的重要性；  在项目进展状态评审中强调对客户满意度度量结果的评审  敏捷开发 在 Agile 环境中，项目产品开发活动中，客户与潜在最终用户的持续参与对于项目成功极其 重要；因此，项目活动中，客户与最终用户的参与，应受到跟踪。 5 REQM(Requirements Management) —— 需求管理  变化点：  增加在 Agile 环境中如何进行需求一致性跟踪  敏捷开发 在 Agile 环境中，需求通过产品积存、故事卡、屏幕实体模型之类机制进行交流和跟踪。对 需求的承诺，或是以团队集体式做出，或是由团队领导授权做出。根据项目的进展，或随着 对需求理解的进一步加深，或解决方案的出现，工作指派频繁地进行调整(每日或每周)。需 求与工作产品之间的追踪性与一致性，是通过上面所说的机制完成的，通常在迭代开始或迭 代结束活动如“回顾”与“展示日”之类中进行的。 6 SAM(Supplier Agreement Management) —— 供应商合同管理  变化点：  对 sp2.2/2.3/2.4 进行合并，将对供应商的过程和产品监控合并到“验收采购产品”， 删除了原来 2.2 和 2.3 中若干子实践 7 MA(Measurement and Analysis) —— 度量分析  变化点  SP2.1 标题，由“收集（Collect）度量数据”修改为“获取（Obtain）度量数据”，但 内容无变化  对一些度量目标的例子解释得更为详尽  SP1.2 确定度量中，增加了一张表举例说明基本的度量定义——对实际操作更有指导作 用 三级过程域的主要变化
    1 OPD(Organizational Process Definition ) —— 组织过程定义  组织过程定义的目标从原来“建立和维护组织过程资产和工作环境标准”扩充到“建立 和维护组织过程资产、工作环境标准以及团队规则和指导方针”；  增加 SP1.7“建立团队建设的规则和指导方针”，目标是通过建立和维护组织级的规则 和指导方针用以进行项目团队的组织、建设和管理。其实践包括项目的组织架构、项 目经理和成员的权利和责任、团队行为准则、内部的计划任务分配检查机制、沟通方 式，对外部和客户的汇报方式等等。旨在建立组织级的准则用以指导各项目团队管理。  SP1.3 中增加一节强调对标准过程裁减的重要性。强调对于存在特殊需求的项目，对标 准过程进行裁减以满足项目特殊的商务目标是非常关键的。  SP1.4 增加对度量库的功能描述 —— 有利于项目之间进行有效的比较；在建立新项目 时，可以通过度量库快速获得类似项目的基线或历史数据作为参照；可以通过类似项 目历史数据提高估算精度；有助于统计管理。 2 OPF(Organizational Process Focus ) —— 组织过程焦点  SP1.3，组织在对需要改进的过程排优先级时，需要从成本收益进行考虑。 3 OT(Organizational Training ) —— 组织培训  在培训需求中增加了领导力培训、团队建设培训以及沟通技巧培训的例子。 4 IPM (Integrated Project Management) —— 集成项目管理  SP1.6 前插入新的特定实践“组建项目团队”：包含了原来 IPPD 中的大部分内容  SP1.5 增加子实践“对影响项目目标达成的问题进行根源分析”，目的是在项目或组织 范围内采取适当的纠正或预防措施。 5 RSKM (Risk Management) —— 风险管理  基本无变化 6 DAR (Decision Analysis and Resolution) —— 决策分析和解决方案  基本无变化 7 RD (Requirements Development) —— 需求开发  增加了质量属性需求及说明 —— 质量需求，即质量属性的开发，贯穿于整个需求开发 过程域中；例如，分解需求中也提到架构设计与质量属性的关系，强调产品质量特性 的满足是通过架构设计实现的。  增加在 Agile 环境下需求存在的形式及文档详细程度的说明；  敏捷开发 在 Agile 环境中，会在每一个迭代周期内反复引导、细化、分析和确认客户需求。需 求通过用例、场景甚至迭代结果(在软件情况下为程序代码)的形式记录。哪些需求项会在
    给定的迭代周期中予以处理，是以风险评估和后续功能列表中的优先级驱动的。需求(及其 他工作产品)文档的详细程度，是由团队成员间、团队间、以及前后迭代周期之间协作的需 要以及项目或组织遗失相关成果的风险之间平衡的结果决定的。即使客户加入团队，仍然 会有独立的客户和产品文件，用于多种解决方案的并行探索。当最终的解决方案确定后相 应的需求会分配给适当的团队。 8 TS (Technical Solution) —— 技术解决方案  在需求前增加形容词“功能和质量属性” —— 更加强调对产品的质量要求；  产品的性能用质量属性代替——质量属性具有更宽泛的概念；  在解决方案的选择准则中增加对关键质量属性的考虑，如产品时间特性、安全性、可靠 性和可维护性等；  删除了对“Data Package”的具体内容描述。  敏捷开发 在 Agile 环境中，TS 的焦点在于对解决方案进行探索。让解决方案的选择准则及选择过程 透明，有助于提高决策的质量。解决方案可从功能、特征集、发布版本、或任何其它能产 品开发组件的角度来定义。当团队外的某个人在未来为这个产品工作时，产品的发布信息、 维护日志、以及其他数据，通常会包含于该已安装的产品中。为支持产品更新，关于接口 设计、组件采购和开发的决策准则的记录将有助于后续支持人员对该产品的理解。不过， 如果所选解决方案存在的风险越小，则正式进行决策的需要也就越低。 9 PI (Product Integration) —— 产品集成  SP1.1“确定集成顺序（Determine Integration Sequence）”更改为“建立集成策略 （Establish an Integration Strategy ）”。集成策略的涵盖的内容更多，除集成顺 序外，还包含了对环境、工具、方法以及验证的策略。  敏捷开发 在 Agile 环境中，产品集成是一个经常性、通常是每日进行的活动。例如，对于软件开发， 程序代码持续地以称为“持续集成”的过程，加入到程序代码库中。除了进行持续集成之 外，产品集成策略还应说明，第三方所提供的组件如何集成到产品中，功能性将如何构建 （横向分层还是纵切片)，以及在何时重构(refactor)。集成策略应在项目早期制定，并逐 渐修订以以反映组件接口、外部依赖、数据交换、以及应用程序编程接口的演化。 10 VER (Verification) —— 验证  验证方法中增加架构评审；  同行评审方法中增加重构、结对编成  验证方法的举例中增加了“架构评审、架构实现与架构设计的一致性检查”  验证方法的举例中增加了“持续集成（用于早期识别集成问题的敏捷方法）”  同行评审数据分析举例时增加“与缺陷相关的用例、与缺陷相关的客户或最终用户”  敏捷开发
    在 Agile 环境中，由于客户的参与和频繁发布版本，验证和确认两个过程需要交替进行， 互相支持。例如一个缺陷可能导致一个原型或一个早期发布的版本失效。反之，尽早的持 续的确认有助于帮助验证过程应用于正确的产品。验证和确认过程能确保用系统化的方法 选择工作产品进行评审和测试，有助于尽早识别缺陷。产品越复杂，越需要用系统化的方 法验证需求、解决方案及其最终使用之间的一致性和兼容性 11 VAL (Validation) —— 确认  在 sp2.2“分析确认结果”中增加子实践：提供信息说明确认过程中的（遗留）缺陷如 何解决，并发起纠正措施。
    分享到：
    赞 收藏

    相关推荐

    资料库

    信息化

    共收录1827份资料，累计6个分类，关注成员有19位，主要包括：管理软件,企业管理,电子商务,其它,IT管理,项目管理

    热门标签

    管理软件 企业管理 电子商务 其它 IT管理 项目管理

    最新资料