CMMI评估报告中的十个弱项，您的企业有吗？

在CMMI评估报告中经常出现的10个弱项，你的企业存在吗？其实这些弱项都有相同原因，它们代表了我们在软件工程、质量控制、项目管理、过程改进等方面的不足。不过这些弱项也是我们改进的机会，在一些企业中，擎标也看到了很多有效实践，在组织内部有效解决了这些问题。下面擎标先给大家介绍一下10个弱项。
弱项一：非功能需求的二意描述及不可追溯性
非功能其实比功能更加重要，因为在很大程度上，它决定了用户对产品的满意度，非功能决定了功能的易用、安全、响应速度、可维护性等因素。而且产品架构是由非功能需求决定的，非功能的缺陷修复成本大大高于功能缺陷的修复。可惜非功能是常见的遗漏需求，即使识别出的非功能需求的描述也往往不精准，很难指导后续开发和测试工作。对于识别出的这些非功能需求，我常常看不到设计实现的考虑，看不到测试的覆盖，倒时常感觉到咱们项目组的赌性。希望我们成熟的软件组织，能够重视这个问题。
弱项二：质量部包揽了EPG的工作
早些年，看到EPG被置于公司质量部的领导之下。其后果是质量部包揽了组织的所有改进工作，不论改进的流程执行实体和它有无关系。难道质量部个个都是十项全能高手?架构的改进难道不应该由架构师主导吗?看到一些不疼不痒的专题改进成果，除了叹气还是叹气。
弱项三：为评估而做的决策
一眼就能从备选方案中选出胜出者时，这个决策大概是为评估准备的。如果真的是四个专家花了两个小时，咱们能否将决策自然体现在需要决策的活动中?何必要单独出个决策报告，再把相关信息抄出来。这好歹也是一个专家一天的工作量(8个小时)，可惜了!
弱项四：Brutal Force的架构设计
好多人问中国软件最缺什么人才?最缺的就是软件架构师。在擎标评估的项目里，很少能看到可以支持产品扩展、维护的优美的软件架构。许多架构只是解决眼前的问题，英文叫brutal force的方法，也就是没有套路的方法。
弱项五：没有质量评估的测试报告
大多数测试报告基本就是流水账：跑了多少用例，发现了多少缺陷，修复了多少缺陷，遗留了多少缺陷……但是被测程序质量如何?测试盲点、潜在隐患在哪里?后续测试应关注什么?这些基本质量评估都看不到。那么测试报告的价值何在?
弱项六：不可操作的风险缓解计划
现代的项目管理就是风险管理，可惜这是个和同行评审做得不相上下的过程域。相信你看到过这样的风险缓解计划：加强和客户沟通。那谁和谁沟通?沟通什么?何时沟通?一个不可操作的风险缓解计划如何能真的化解风险呢?
弱项七：同行评审水土不服
同行评审在中国水土不服是个老问题了，我们的评审发现不了缺陷。这里我就不做原因分析了，每当我在心里算下评审速率，发现每小时要评审500页需求或5000行代码时，只能默默的对这个速率表达崇高的敬意!
弱项八：缺乏可操作定义(operational definition)的度量项
CMMI 2.0在MPM(Managing Performance and Measurement)实践域中多次强调度量项的可操作定义。精准的度量项不如一致的度量项，度量项都会些噪音，但要高都高，要低都低。没有可比性的度量是没有意义的，恰当的可操作定义保证了这一点。可惜太多的组织，做不到这一点。
弱项九：不变的项目定义过程和不变的项目量化目标
项目计划常常会变，可奇怪的是项目的定义过程基本不变。随着项目的进展，计划的过程活动及其力度都不需要调整吗?为什么项目量化目标永远不变?哪怕目标明显已经太低或太高了?您家软件项目真的那么稳定吗?
弱项十：支零破碎的过程架构
如果看到一家组织的过程是按过程域来编写的，过程元素和过程域的实践有很好的对应时，就为过程执行者捏把汗。项目经理在做计划时，怎么能够自然的梳理清楚不同过程的关系：谁是谁的输入?谁是谁的输出?很高兴CMMI2.0明确指出不要再说“我们在实施CMMI认证”,而是我们在改进过程，在组织内部实现模型的目的和价值。
上诉问题，CMMI2.0将逐一解决，上海擎标专业从事cmmi认证,cmmi3级认证,cmmi5级认证,是目前行业内提供IT咨询，培训相当有影响力的咨询服务商之一，现有多位具有国际化视野且经验丰富的精英团队,需要了解CMMI项目的企业，请联系在线客服，我们将为您提供最专业的服务。