弱项一：非功能需求的二意描述及不可追溯性

       我个人不太喜爱非功用这个说法，只说不是功用，那是什么呢？当然这是题外话。非功用其实比功用愈加重要，因为在很大程度上，它决议了用户对产品的满意度，非功用决议了功用的易用、安全、响应速度、可保护性等要素。而且产品架构是由非功用需求决议的，非功用的缺点修正本钱大大高于功用缺点的修正。惋惜非功用是常见的遗漏需求，即使识别出的非功用需求的描述也往往不精准，很难指导后续开发和测验作业。对于识别出的这些非功用需求，我常常看不到规划实现的考虑，看不到测验的掩盖，倒经常感觉到咱们项目组的赌性。期望咱们成熟的软件安排，可以重视这个问题。

       大多数测验陈述根本便是流水账：跑了多少用例，发现了多少缺点，修正了多少缺点，遗留了多少缺点……可是被测程序质量如何？测验盲点、潜在危险在哪里？后续测验应关注什么？这些根本质量评估都看不到。那么测验陈述的价值何在？这些流水账除了像个打酱油的，还能干嘛？

      早些年，我常看到EPG被置于公司质量部的领导之下。其结果是质量部包办了安排的一切改善作业，不管改善的流程执行实体和它有无关系。莫非质量部个个都是十项全能高手？架构的改善莫非不应该由架构师主导吗？看到一些不疼不痒的专题改善成果，我除了叹气还是叹气。

       项目方案常常会变，可奇怪的是项目的界说进程根本不变。随着项目的进展，方案的进程活动及其力度都不需求调整吗？这儿就不讨论高成熟度的问题了，但忍不住问一嘴：为什么项目量化方针永远不变？哪怕方针明显现已太低或太高了？您家软件项目真的那么稳定吗？

弱项七：为评估而做的决议方案

      现代的项目办理便是危险办理，惋惜这是个和同行评定做得平起平坐的进程域。相信你看到过这样的危险缓解方案：加强和客户交流。那谁和谁交流？交流什么？何时交流？一个不行操作的危险缓解方案如何能真的化解危险呢？

      CMMI 2.0在MPM（Managing Performance and Measurement）实践域中多次强调衡量项的可操作界说。精准的衡量项不如一致的衡量项，衡量项都会些噪音，但要高都高，要低都低。没有可比性的衡量是没有意义的，恰当的可操作界说保证了这一点。惋惜太多的安排，做不到这一点。