CMMI 3.0的276条实践中英文对照
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
CMMI 3.0实践摘要
在2023年4月6日发布的CMMI 3.0包含了31个实践域,涉及276条具体实践。以下是部分实践域及其对应的中英文陈述的概要:
实践域摘要
- CAR (因果分析与解决): 识别和处理现象的原因,执行根因分析,并提出行动建议。
- CM (配置管理): 执行版本控制,管理变更,并执行配置审计以维护完整性。
- CONT (连续性): 制定应急方法,识别并优先处理连续性需求。
- DM (数据管理): 识别管理目标,使用元数据,建立数据管理架构。
- DQ (数据质量): 定义数据质量参数,执行数据清洗活动,评价数据质量。
- DAR (决策分析与解决): 定义和记录决策,开发评价候选方案的准则。
- ESAF (环境安全): 识别安全需求和危险,开发应对安全问题的方法。
- ESEC (环境安全): 识别安全需求,开发应对物理和网络安全需求的方法。
- EVW (虚拟工作环境): 执行远程工作,监控并评价远程工作方法。
- EST (估算): 开展粗略的工作估算,基于规模估算评价工作量和成本。
- GOV (治理): 确定工作重点,定义组织指令并分配权力。
- II (实施基础): 执行满足实践目的的过程,提供资源和培训。
- IRP (事故解决与预防): 记录并解决事故,开发事故管理系统。
- MPM (度量和分析): 采集度量数据,识别性能问题,分析组织性能。
- MST (维护安全与信任): 识别信息安全威胁与漏洞,处理信息安全问题。
- MC (监控): 跟踪实际结果,监督运维过程,管理关键依赖。
- OT (组织培训): 识别培训需求,开发组织战略和短期培训计划。
- PR (同行评审): 评审工作产品,解决评审中发现的问题。
- PLAN (计划): 制定任务列表和工作方法,策划项目环境。
- PAD (过程资产开发): 开发过程资产,制定过程架构。
- PCM (过程与产品质量保证): 确定工作产品和过程问题,开展质量保证活动。
- PI (产品集成): 组装解决方案,确认组件满足需求。
- RDM (需求开发与管理): 记录需求,转换干系人需求为客户需求。
- RSK (风险与机会管理): 识别和分析风险或机会,开发风险管理策略。
- SDM (服务交付与管理): 根据服务协议交付服务,管理服务系统。
- STSM (战略服务管理): 制定服务描述,收集关于服务交付的战略需求数据。
- SAM (供应商协议管理): 识别供应商,制定和管理供应商协议。
- TS (技术解决方案): 构建解决方案,评价设计,提供使用指南。
- VV (验证与确认): 验证需求实现,确认解决方案功能。
- WE (工作环境): 分配工作组职责,管理工作环境。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
440 篇文章
浏览 780.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
COSMIC方法是新一代的软件规模度量方法,其基本的原理很简单,就是度量软件需求中的输入、输出、读、写这4类数据移动的个数,我们通过2个简单的例子来说明其基本的原理。 案例一:针对MIS类软件的需求 对于应用软件而言,我们都有这样的需求:允许合法用户登录到系统中; 对于上述的功能需求,我们可以采用USE CASE的方式详细描述需求如下:
2014年4月26日,CMMI 研究所CEO Kirk Botula先生与COO Lisa Masciantonio女士到访麦哲思科技(北京)有限公司,和麦哲思科技CEO任甲林先生与CTO Bruce Hofman先生进行了充分的沟通交流,对于如何融合敏捷方法到CMMI模型中,如何改进优化CMMI模型、SCAMPI评估方法,如何进一步推广CMMI模型在中国的实施,双方进行了热烈而富有创意的讨论。K
PMO、EPG与QAG职责分工 有很多人对PMO、EPG与QAG的关系理解比较混乱,因此整理此文以澄清一些误解。 1 PMOPMO(Project Management Office)是项目管理办公室的简写,是在PMBOK中建议的一种组织机构,其主要职责是:Ø 定义项目管理流程;Ø 培养项目经理团队;Ø 建立项目管理信息系统;Ø 对项目提供顾问式指导;Ø 监督项目进展情况;Ø 开展多项
这是一个很有意思的话题。很多人对此困惑。困惑在什么地方呢? 从开发的角度看,是希望系统测试发现的缺陷越少越好,那意味着在开发阶段都把缺陷找干净了。 从测试的角度看,是希望系统测试时把缺陷找干净了,不要遗留给客户去发现。在潜在的缺陷数恒定的前提下,找到的缺陷越多越好。 在组织级确定质量目标时,这个系统测试缺陷检出密度到底是定义为越高越好,还是越小越好呢?系统测试缺陷检出密度的大小能代表产品质量吗? 产品质量只能通过上线后的缺陷多少来衡量,上线后的缺陷密度越小越好...
很多项目需求写的模糊,如何对这些模糊的需求进行澄清呢?通过哪些问题可以帮我们澄清需求呢?我设计了一个问题单供大家参考。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线