第二章 过程域 —— 原因分析与决策

CMMI2.0之我见-原因分析和解决CAR&决策分析和解决DAR 解析CMMI2.0中实践域-原因分析和解决CAR&决策分析和解决DAR 阅读详情

原因分析与决策

成熟度5级的一个支持过程域

目的

原因分析和决策(CAR)的目的是为了识别缺陷和其他问题的原因并且引起注意防止它们在将来发生。

介绍

原因分析和决策过程域包括:

l         识别和分析缺陷和其他问题的原因

l         努力消除原因并且防止这类缺陷和问题的发生

原因分析和决策通过防止缺陷进入产品来提高质量和生产能力。依赖在缺陷发生后再去检查是没有有效价值的。通过将原因分析和决策活动融入到项目的每一个阶段中才能更有效的防止缺陷。

       既然在其他项目或者在当前项目尽早的阶段或者任务中,缺陷和问题可能被遇到,那么原因分析和决策活动便成为一个项目间学习的沟通课程的机制。

       缺陷的类型和其他遇到的问题都被分析以识别任何趋势。基于对已定义过程和怎样改进这个过程的一种理解,缺陷的根源和将来这个缺陷的牵连是被确定的。

       原因分析也可能执行在与缺陷无关的问题上。例如,原因分析可能会被用于提高例如生命周期这样的质量属性。改进建议、模拟、动态系统模型、工程分析、新的业务方向,或者其他项目都可能开始这样的分析。

       有的时候可能会不切实际对所有的缺陷执行原因分析。在这些案例中,需要在评估投资和评估在质量、可生产性、生命周期以及选择的缺陷目标上的回报之间作权衡。

       一个度量过程应该已经足够适合了。已定义的度量标准是有用的,尽管在一些案例中新的度量标准可能需要分析过程改变带来的影响。

有关建立度量和分析的目标,完成特定的度量和分析,获得和分析度量标准,报告结果的更多信息请参见度量与分析过程域。

       原因分析和决策活动为项目在当前等级下评估他们的过程并且寻求能够执行的改进提供了一个机制。

       当改进被判断为有效时,这个消息被扩展到组织等级。

有关通过已建议的改进和活动建议改进组织的过程等级的信息请参见组织革新与部署过程域。

       这个过程域中的具有情报价值的素材是在假设特殊实践被应用在一个已量化管理的过程的基础上写的。如果假设不存在的话,那么这个过程域的特殊实践或许是可应用的,但是它的价值会降低。

       对“稳定过程”和“过程变化的一般原因”的定义请见术语表

相关过程域

有关过程性能的分析和被选择的项目过程的过程能力度量的更多信息请参见量化项目管理过程域。

       有关对组织过程和技术改进的选择和部署的更多信息请参见组织革新与部署过程域。

有关建立度量和分析的目标,完成特定的度量和分析,获得和分析度量标准,报告结果的更多信息请参见度量与分析过程域。

实践-目标关系表

连续式

分级式

SG1 判断缺陷原因

SG1 判断缺陷原因

     SP1.1-1 为分析选择缺陷数据

     SP1.1-1 为分析选择缺陷数据

     SP1.2-1 分析原因

     SP1.2-1 分析原因

SG1 定位缺陷原因

SG1 定位缺陷原因

     SP2.1-1 执行活动的目的

     SP2.1-1 执行活动的目的

     SP2.2-1 估计变化的影响

     SP2.2-1 估计变化的影响

     SP2.3-1 记录数据

     SP2.3-1 记录数据

GG1 达到特定目标

 

     GP1.1 完成基础实践

 

GG2 制度化一个已管理的过程

GG2 制度化一个已定义的过程

     GP2.1 发布一个组织政策

     GP2.1 发布一个组织政策

     GP2.2 计划过程

     GP2.2 计划过程

GP2.3 提供资源

GP2.3 提供资源

GP2.4 分配职责

GP2.4 分配职责

GP2.5 培训人员

GP2.5 培训人员

GP2.6 管理配置

GP2.6 管理配置

GP2.7 识别和包括相关的风险承担者

GP2.7 识别和包括相关的风险承担者

GP2.8 监督和控制这个过程

GP2.8 监督和控制这个过程

GP2.9 客观的评价坚持

GP2.9 客观的评价坚持

GP2.10 以更高等级的管理回顾情况

GP2.10 以更高等级的管理回顾情况

GG3 制度化已定义的过程

 

     GP3.1 建立一个已定义的过程

     GP3.1 建立一个已定义的过程

     GP3.2 收集改进信息

     GP3.2 收集改进信息

GG4 制度化一个已量化管理的过程

 

     GP4.1 建立过程的量化目标

 

     GP4.2 稳定子过程的执行

 

GG5 制度化一个优化中的过程

 

     GP5.1 保证连续的过程改进

 

     GP5.2 改正问题的根源

 

实现目标的关键实践
SG1 判断缺陷原因

缺陷的根源和其他问题都是需要系统性的确定。

所谓缺陷的根源就是一旦它被消除,那么缺陷也会减少或消除。

SP1.1-1 为分析选择缺陷数据

选择缺陷和其他问题用于分析。

典型工作产品

1.缺陷和问题数据被选择作进一步分析

子实践

1.收集相关缺陷数据。

相应的缺陷数据实例可能包含如下内容:

l         项目管理问题报告需要纠正活动

l         客户的缺陷报告

l         最终用户的缺陷报告

l         在同行评审中发现的缺陷

l         在测试中发现的缺陷

l         过程的能力性问题

有关工作产品确认的更多信息请参见确认过程域。

有关统计管理的更多信息请参见量化项目管理过程域。

2.确定哪些缺陷和其他问题将作进一步分析。

当确定哪些缺陷将被分析之前,要考虑到缺陷的影响、发生的频率、缺陷之间的相似性、分析的费用、所需的时间和资源、安全性考虑,等等。

选择缺陷和其他问题的方法如下:

l         排列图分析

l         柱状图

l         过程能力分析

SP1.2-1 分析原因

执行选择的缺陷和其他问题的原因分析并且建议标记它们的活动。

       这个分析的目的是开发解决方案已达到通过分析相关数据和用于改进的生产性活动建议去识别问题的目的。

典型工作产品

1.活动建议

子实践

1.与有可能执行这个任务的的人一起引导原因分析。

原因分析是由那些通过研究(典型的如会议)对选择的缺陷或问题有了解的人来完成的。对这些缺陷越了解的人越有责任执行这个任务。

什么时候执行原因分析的例子如下:

1.         当一个稳定的过程没有达到它的特定质量和过程性能目标

2.         在任务的过程中,假如或者当问题使额外的会议有了正当的理由

3.         当一个工作产品表现出与它的需求有意料外的背离

关于完成项目质量和过程性能目标的更多信息请参见度量项目管理过程域。

2.分析选择的缺陷和其他问题以确定它们的根源原因。

依据缺陷的类型和数量,在识别它们的根源原因之前最好先将它们分组。

确定根源原因的方法示例如下:

l         原因影响(鱼骨)图

l         检查单

3.将选择的缺陷和其他问题按照它们的根源原因分组。

原因的分组或分类示例如下:

l         培训不充分

l         信息交流不畅

l         问题细节考虑不周

l         手工操作出错(例如:打印错误)

l         过程缺乏

4.建议和制订活动用于防止类似的缺陷和其他问题再次发生。

建议的活动(包括改变)示例如下:

l         存在问题的过程

l         培训

l         工具

l         方法

l         沟通

l         工作产品

 

一些具体的活动包括:

l         为一些公共的问题以及防止它们的技术提供培训

l         改变一个过程使有错误倾向的步骤不再发生

l         自动化所有或者部分的流程

l         记录过程行为

l         增加防止缺陷的过程步骤,例如任务启动会讨论普通的缺陷和行为,从而防止它们发生

一个活动建议通常的写法如下:

l         活动建议的创建者

l         问题的描述

l         缺陷原因的描述

l         缺陷原因分类

l         问题被提出的阶段

l         缺陷被确认的阶段

l         活动建议的描述

l         活动建议的分类

SG2 标记缺陷原因

缺陷的根源和其他问题都是需要系统性的标记以防止它们将来发生。

当项目的操作符合比较好的定义的过程,那么会系统地分析那些依然发生问题的操作并且实现过程改进从而去消除这些被选择的问题的根源原因。

SP2.1-1 贯彻活动建议

贯彻那些来自原因分析中的被选择的活动建议。

活动建议描述消除被分析过的缺陷或问题的根源原因并防止它们再次发生所必需的任务。

只有被证明有价值的改变才可能会被认为是显著的执行。

典型工作产品

1.         被选择执行的活动建议

2.         改进建议

子实践

1.分析活动建议并且确定它们的优先权。

把活动建议区分优先次序的标准示例如下:

l         与没有标记的缺陷的牵连

l         为防止缺陷所执行的过程改进的花费

l         预期的质量效果

2.选择那些将被执行的活动建议。

3.为将要执行的这些活动建议创建活动项目。

在一个活动项中提供的信息包括:

l         负责执行的责任人

l         影响到的领域的描述

l         哪些人要跟踪它的状态信息

l         下一个状态被讨论的日期

l         关键决定的基本原理

l         执行活动的描述

l         识别缺陷并改正它所需的时间和花费

l         不改正这些问题预计的花费

       要执行活动建议,下面的任务必须作:

l         任务分派

l         调整做工作的人员

l         讨论结果

l         跟踪活动项目直到其关闭

试验可能来源于独特的复杂的变化。

试验示例如下:

l         使用一个临时的、改进的过程

l         使用一个新的工具

活动项可能被分配给原因分析组的成员,项目组的成员,或者其他组织的成员。

4.识别并且消除可能存在于其他过程和工作产品中的相似的缺陷。

5.识别和记录为组织的系列标准化过程的改进建议。

有关组织的系列标准过程的改进建议的选择和部署的更多信息请参见组织革新与部署过程域。

SP2.2-1 评价改变的效果

评价改变在过程性能上的效果。

有关分析过程性能和为被选择的过程创建过程能力度量方法的更多信息请参见集成项目管理过程域。

一旦一个被改变的过程被配置在项目中,必须收集过程改变已经改正了问题并且改进了性能的证据,从而检查改变的效果。

典型工作产品

1.性能和性能改变的度量方法。

子实践

1.         适当的度量项目已经定义的过程的性能改变。

这个子实践确定了这个选择的改变是否已经肯定地改变了过程的性能以及改变了多少。

在项目已定义的设计过程的性能上的一个改变有可能成为在设计文档中的缺陷密度上的改变,如同统计上的度量通过前期的同行评审和后期的改进一样。在一个统计过程控制图表中,这个将被会作为一个平均的变化来表现。

 

2.         适当的度量项目已经定义的过程的能力。

这个子实践确定了这个选择的改变是否已经肯定地改变了过程的能力已达到它的质量和过程性能目标,如同被相应的风险承担者确定一样。

在项目已定义的设计过程的能力上的一个改变有可能成为在过程取代在他们的过程规范边界之内的能力的一个改变。通过计算设计文档中的缺陷密度的范围能够被统计上度量,如同在前期的同行评审和后期的改进中的收集一样。在一个统计过程控制图表中,这个将被会作为一个低控制限制来表现。

SP2.3-1 记录数据

记录原因分析和结果数据在项目和组织中共享使用。

数据被记录从而使其他的项目和组织能够进行适当的过程改变和达到类似的结果。

       记录如下内容:

l         被分析的缺陷和其他问题的数据

l         决议的基本原理

l         来自原因分析会议的活动建议

l         来自活动建议的活动项结果

l         分析和决策活动的花费

l         来源于决策而发生的已定义的过程的性能变化的度量方法

典型工作产品

1.       原因分析和决策记录

 

目标的一般实践

GG1 完成特定目标

通过将可识别的输入工作产品转变为可识别的输出工作产品,过程支持并且能够使过程域的特定目标实现。

 

GP1.1 履行基本实践

履行原因分析和决策过程的基本实践从而发展工作产品和提供达到过程域的特殊目标的服务。

 

GG2 制度化一个已管理的过程

    过程被作为一个已管理的过程制度化。

仅仅适用于连续式

 

GG3 制度化一个已定义的过程

过程被作为一个已定义的过程制度化。

编者按:这类目标的外观反映它在分级表示法中的位置。

 

 

仅仅适用于分级式

 

执行的保障

       GP2.1 建立组织性方针

       建立和维持一个用于计划和执行原因分析和决策过程的组织性方针。

       详尽的细节

       这个方针建立了对识别组织性的期望以及对缺陷和其他问题的根源原因的系统性标记。

 

执行的能力

       GP2.2 为过程制定计划

       建立和维持一个用于执行原因分析和决策过程的计划。

       详尽的细节

按照项目计划过程域中的描述,执行原因分析和决策过程的计划可能包含(或被参考)在项目计划中。这个计划不同于在这个过程域中的许多特殊实践中描述的活动建议和相关的活动项。计划这个通常的实践应该标记项目全部的原因分析和决策过程(或许从一个被组织维持的标准过程中剪裁)。与之相对照,过程活动建议和相关的活动项标记需要通过研究消除一个特殊根源原因的活动。

 

GP2.3 提供资源

提供足够的资源用于执行原因分析和决策过程,开发工作产品,以及提供过程的服务。

 

详尽的细节

提供的资源包括如下工具所示:

l         数据库系统

l         过程建模工具

l         统计分析包

l         工具、方法以及分析技术(例如,Ishakawa或鱼骨法图表,帕累托(Pareto)分析法,柱状图,过程能力研究,控制图表)

 

GP2.4 分配职责

分配执行过程,开发工作产品以及提供原因分析与决策过程服务的职责。

 

GP2.5 培训人员

培训人员执行或者支持原因分析与决策过程。

详尽的细节

培训主题示例如下:

l         质量管理方法(例如,根源原因分析)

直接的执行

       GP2.6 管理配置

       将设计过的原因分析和决策过程的工作产品放在适当的配置管理级别下。

      

       详尽的细节

在配置管理下存放的工作产品示例如下:

l         活动建议

l         为改进而选择的活动建议

l         原因分析与决策纪录

 

       GP2.7 识别和包含相关的风险承担者

       如同计划的,识别和包含原因分析与决策过程的相关风险承担者。

 

详尽的细节

风险承担者的活动示例如下:

l         管理原因分析

l         核定活动建议

 

GP2.8 监督与控制过程

       根据计划监督与控制原因分析与决策过程,从而执行过程并进行适当的纠正活动。

 

详尽的细节

用于监督与控制的度量方法示例如下:

l         根源原因消除的数量

l         质量的改变或者每次原因分析与决策过程的过程性能情况

验证执行

       GP2.9 客观的评价坚持

根据过程描述、标准以及产物和不可能顺利找寻,客观的评价原因分析与决策过程的坚持。

 

详尽的细节

回顾活动示例如下:

l         确定缺陷的原因

l         找到缺陷的原因所在

 

工作产物回顾示例如下:

l         为执行选择的活动建议

l         原因分析与决策纪录

 

       GP2.10 用更高等级的管理回顾状态

       用更高等级的管理和解决观点回顾活动、状态和原因分析与决策过程的结果。

 

GG3 制度化一个已定义的过程

过程被作为一个已定义的过程制度化。

编者按:这类目标的外观反映它在连续表示法中的位置。

 

 

仅仅适用于连续式

执行的能力

       GP3.1 建立一个已定义的过程

       建立和维持一个已定义的原因分析与决策过程的描述。

直接的执行

       GP3.2收集改进信息

收集工作产品、度量方法、度量结果以及源于计划和执行原因分析与决策过程的改进信息,从而支持将来的使用以及组织过程和过程域的改进。

 

GG4 制度化一个集成的已管理的过程

   过程是作为一个集成的已管理的过程被制度化的。

 

   GP4.1 为过程建立集成目标

   为原因分析与决策过程建立和维持集成目标从而明确质量和过程执行是基于客户需求和商业目标的。

 

   GP4.2 稳定子过程执行

   稳定一个或多个子过程的执行从而确定原因分析和决策过程的能力以达到建立的集成质量和过程执行目标。

 

GG5 制度化一个已优化的过程

   过程是作为一个已优化的过程被制度化的。

 

   GP5.1 确保连续的过程改进

   在完成组织的相关商业目标过程中确保连续的原因分析与决策过程改进。

 

   GP4.2 纠正问题的根源原因

   在原因分析与决策过程中识别和纠正缺陷和其他问题的根源原因。

 

仅仅适用于连续式

 

原因分析与解决过程域(CAR) CMMI体系中,原因分析与解决(CAR)过程域详解,包含特定目标,特定实践,子实践和工作样例 立即下载

相关推荐

Codex驱动AEDT完成无线充电仿真——从双线圈建模到三维电磁场动画

本文介绍了一个利用Codex、PyAEDT和Ansys Electronics Desktop 2025 R2实现双线圈无线充电系统自动建模与仿真的案例。通过简化模型(平面线圈+铁氧体磁芯),完成了从参数化建模、电磁场求解到后处理的全流程自动化,获得了耦合系数(k=0.17)、三维电磁场分布及多周期动态可视化效果。研究发现:线圈间距对传输效率影响最大(10-30mm间距时效率从40.2%降至5.57%),横向偏移15mm会使效率下降35%,而磁芯厚度增加带来的效率提升有限(3→7mm仅提高1.67%)。该框

sjjsjjsjjsjjsjj的博客 446

CMMI-原因分析与解决(CAR)

CMMI-原因分析与解决(CAR)

深圳市多克创新科技有限公司 2552

Ferry工单平台部署

ferry工单平台部署

运维求生之路 1897

CAR访谈问题

1、请简要介绍贵司的CAR管理的管理方式? 基于公司管理和CMMI要求,制订了《组织级方针》(包括本过程域的组织级方针),制定和部署了《原因分析报告》和相关的指南、模板。在流程部署中,对于过程特定目标(SG目标),主要进行数据分析、原因分析、制定措施行动计划、改进成效分析等活动。 2、如何选择改进点? 如何分析和确定根本原因? 项目中选择了SPC控制图发现的异常问题,作为改进点,进行因...

一切都是浮云 1124

KiCad 7.0 + 嘉立创打样:从原理图到实物,打造你的双LLCC68 LoRa串口透传板

本文详细介绍了使用KiCad 7.0设计双LLCC68 LoRa串口透传板的完整流程,从原理图设计到嘉立创打样。重点解析了AVR+LLCC68组合的优势、双模块布局的电磁兼容设计、SPI接口配置及射频走线技巧,并提供了实测数据和常见问题解决方案,帮助开发者高效实现物联网设备的低功耗远距离通信。

weixin_28693447的博客 260

2026保姆级:1小时搞定C# OPC UA客户端开发——PLC与上位机全量数据交互零基础教程

本文介绍了使用C#开发OPC UA客户端的核心流程和关键代码实现。文章首先指出工业上位机开发中OPC UA的重要性,并针对新手常见问题提出了1小时掌握核心功能的解决方案。重点内容包括:选择官方.NET Standard库的优势、5分钟搭建开发环境的步骤、OPC UA客户端架构与通信流程的图解说明,以及完整的客户端基础类代码实现,涵盖了连接管理、证书配置、安全认证等关键功能。通过本文提供的代码模板,开发者可快速实现与PLC等工业设备的稳定数据交互。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 799

【项目管理】CMMI-原因分析与解决过程(CAR)

概述: “原因分析与解决”通过预防缺陷或者问题的引入以及识别并适当纳入优秀过程性能的原因,改进质量与生产率。

求-是 1551

Debezium 性能调优实战:吞吐量、延迟与资源平衡

摘要: 本文分享了团队如何通过系统性调优将Debezium从初始3,200 TPS/2.8秒延迟提升至15,200 TPS/210ms延迟的实战经验。优化涵盖四个层面:1)Debezium连接器配置(批处理、快照并行、消息精简);2)Kafka分区策略与Avro序列化缓存;3)JVM改用ZGC及OS参数调优;4)MySQL的binlog与I/O优化。关键发现包括分区数黄金公式、sync_binlog调整带来56%的I/O负载下降,以及避免盲目增大队列内存等陷阱。最终实现吞吐量提升4.75倍,并强调性能调优需

爱丹丹的博客 358

第二章 过程域 —— 配置管理

配置管理成熟度2级的一个支持过程域目的配置管理(CM)的目的是建立并且保持工作产品使用配置识别、配置控制、配置状态清算、配置审核的完整性。介绍       配置管理过程域包括:l         识别被选择的工作产品的配置从而及时地在特定的点组成基线l         收集配置项的变化l         从配置管理系统中建立或者提供规范去创建工作产品l     

鹿寒的专栏 3178

QT-Creator安装教程(windows)

本文介绍了Qt的下载安装步骤:1)通过镜像源下载安装包;2)运行exe文件时使用命令行参数指定镜像地址;3)在安装过程中选择路径和自定义安装组件,包含QT5和QT6版本的详细安装说明;4)安装后可继续添加扩展包或卸载组件。重点提示了QT6必须勾选的关键组件,并提供了组件管理的操作方法。

qq_53545309的博客 3107

RandLA-Net Tensorrt 推理 c++

RandLA-Net 实现 Tensorrt 部署.

J。 1109

我说CMMI 2.0 之:原因分析与解决方案

原因分析与解决方案(CAR)是对选中的现象识别原因,并采取纠正措施或预防措施。   基本的思想: 组织内的好事和坏事都可以做CAR,并非仅仅是对坏事做CAR。可以在计划阶段做CAR,也可以在事情发生后再做CAR, 前者是根据估计的结果做CAR,后者是根据实际执行的结果做CAR。 在做原因分析时,是从现象,到数据,然后再到原因。数据准确刻画了现象,并有助于识别真正的原因。 原因有浅层次的直...

麦哲思科技 5975

【TC3xx芯片】TC3xx芯片STM介绍

TC3xx芯片STM介绍

qq_36056498的博客 2280

基于CMMI模型实现自己的总体研发框架(5)——CMMI模型-支持类过程域介绍

CMMI支持过程域,CMMI1.3

wanglx1984的博客 781

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版

Part-E1-SDIO-Specification-Ver4.00-Final-120220.pdf:最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版,包括SDIO 接口的外设,SDIO 接口官方协议等。

软件项目量化管理(QPM)及根因分析实践总结(CMMI高成熟度访谈)

软件项目CMMI5试点及访谈实践总结:项目经理在项目级QA协助下,制定项目的质量目标,根据组织过程性能基线和模型裁剪项目过程,并对项目进行实时量化的监控,确定项目定义过程,选择度量和统计技术,对监控过程中发现的问题分析,确定并采取纠正措施。

肖永威的专栏 1万+

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

根因分析car

概述 Causal Analysis and Resolution 简单说,CAR的目标是识别缺陷原因并采取措施防止将来发生。即证明原因分析改善了公共原因,让性能基线有所提高。也就是说要对公共原因进行原因分析,并有实际的改善效果,让企业更有能力,而且最好有过程及技术方面的原因分析证据。这些都是在4级的基础上的进一步要求。 SG:Specific Goal SP:Specific Practices...

b0207191的博客 2940

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

【软件工程】CMMI 能力成熟度模型集成 ( CMMI 工程过程域 | CMMI 支持过程域 ) ★

一、 CMMI 工程过程域、 3 级、 二、 CMMI 支持过程域、 2 级、 3 级、 5 级、

让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 ) 1283

用CMMI CAR 实践域指导AI进行缺陷修复

本文提出Bug-Fixer缺陷修复AI技能,将CMMI CAR实践域引入AI编程场景,实现标准化缺陷治理。该技能通过四级缺陷分级、双线归零分析等机制,构建全流程强制化修复闭环,解决传统AI修复随意化问题。创新性地验证了CMMI体系不仅适用于人类研发流程规范,更能指导AI技能标准化定义。实践表明,该方法实现了AI修复行为可审计、经验可沉淀,为智能化研发的合规化治理提供了新思路。

麦哲思科技 524

通过CMMI5评估之后

 我们部门的一个项目,作为公司参与CMMI5评估的主要项目之一,从去年6月份开始,到今年3月份结束,所有的过程都参考了组织的标准过程。不过,CMMI的过程并不为项目组的研发成员所接受,因为大家都觉得,大部分的时间都花在了应付流程上,特别是大量的文档,让人头疼。就拿我们的这个参与CMMI5评估的项目来说,如果是按照我们传统的开发流程,在同样的人力资源的情况下,完全可以在半年内提交同样质量的软件产

Smilings -- Enjoying testing 4904

5.3 CMMI5级——原因分析及解决方案(Causal Analysis and Resolution)

聪明的人在出现问题的时候,除了解决问题外,都会想到如何避免问题以后再次发生,避免的办法可能是从过程或者技术两个方面入手,从根本杜绝问题的发生。问题分析是很常见的,为什么在5级的时候才有这样的要求呢?难道2、3级的企业,甚至是没有级别的企业,就不会做问题分析并防止问题再次发生吗?其实5级的这个CAR没有这么简单……

张传波(网名:Fireball,大大大火球) 5218

CMMI V2.0改善软件开发质量案例

CMMI V2.0模型比以前1.3版本简化,更适合用于敏捷迭代项目。这经验分享分3部分: 项目概述 - 背景与目标,主要事件时序 工具/方法+培训+评估 --- 针对问题的原因分析与改进措施 总结 1、项目概述 背景 我们的客户公司是IT软件企业,员工超过8,000,其中八成以上都与研发相关。 为了可以实际帮助企业提升,我们结合了量化敏捷开发与CMMI V2.0模型,对开发团队进行为期9个月的培训、辅导与评估服务:我们客户的客户群对软件产品的质量要求特别高,市场压力也很大,需要尽快依据新的市场需求

u011250455的专栏 2419

CMMI(软件能力成熟度集成模型)

前言:CMMI全称是Capability Maturity Model Integration,即能力成熟度模型集成(也有称为:软件能力成熟度集成模型),本质是软件管理工程的一个部分。CMMI认证的目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。 等级划分:

厚积而薄发,谋定而后动 2万+

4.4 CMMI4级——几个直接与项目管理相关的PA(PP、PMC、IPM、RSKM、QPM、CAR)

2级到5级,直接跟项目管理有关的PA有好几个,它们是怎样的关系呢?

张传波(网名:Fireball,大大大火球) 4994

CMMI v1.3模型变化点 - CAR

CMMI v1.3 变化点 CAR

DellXu的专栏 1081
上一篇: 目录
下一篇: 第二章 过程域 —— 需求管理
blueluhan
博客等级 码龄24年 108粉丝 143原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值