学习CMMI时，为了让大家更好地认识CMMI，老师专门讲解了CMMI是什么，不是什么。
CMMI不是标准，是价值，是改进；CMMI不是认证模型，是改进模型。
CMMI不是：
标准
处方
合规清单
一套可实施的流程或程序
“如何做”的手册或食谱
银弹
同样的，很多刚接触GJB5000的人对GJB5000的认识也存在误区，笔者这里抛砖引玉，也想阐述下GJB5000不是什么，有兴趣的同学可以思考下我说的对不对。
GJB5000不是：
不只是军软项目开发的入场券
虽然在ZZ或ZF推进GJB5000时，通过GJB8000、73号文等向所有从事军软开发或准备从事军软开发的组织透漏一个明显的信号，想要从事军软开发必须具备GJB5000的相应资质，但是，并不意味着这是组织实施GJB5000的终极目标，实际上，ZZ或ZF引入、推进GJB5000的根本目的是提高从事军软开发组织的软件工程能力，从而提高军软产品的交付质量，所谓的“入场券”，只是开始，不是结束。
不是神圣的、不可违背的教条
虽然GJB5000采用了类似CMMI那样的模型架构，为每个过程域/实践域提供了优秀实践，但是，这些实践并不是神圣、不可违背的。正相反，GJB5000/CMMI对此都有明确的说明：实践域的目的、等级目标是必需的部件，实践只是期望的部件（对于CMMI来说，实践域的目的和价值是必需的部件，实践是期望的部件）。这就意味着，我们可以采用这些实践，也可以不采用这些实践，采用自己认为合适的做法（替代实践）。
对于GJB5000评价来说，也应注意鼓励被评单位采用适合自己的替代实践！
不是可操作的流程
虽然GJB5000模型中有实践、有活动实例、有工作产品实例，但它仍然不是一套可操作的流程，它只是对软件开发的相关过程提出了更精细的要求。我们在建立软件过程管理体系的时，不能将标准中的实践、活动、工作产品直接照搬过来，正如不能把需求直接作为测试步骤。软件过程管理体系必须是容易理解的，能够指导项目组活动的。而从标准要求转化为指导项目组工作的体系就是EPG应该完成的工作。
不是解决软件开发问题的“银弹”
虽然GJB5000可以规范组织的软件开发过程，可以提高组织的软件工程能力，可以提高软件产品的质量，但它不是立竿见影的，不是一蹴而就的，不是一用就灵的。有些问题即便可以通过“原因分析”找到问题原因，但受限于解决的期限、资源、成本，却未必有可实施的解决措施。GJB5000可以给我们带来更适合的更优秀的过程，但它不可能解决所有软件开发的问题。
对于已经实施GJB5000A/B三级甚至四级的组织，如果他们的软件仍然会出现问题，我们也可以理解，因为GJB5000也不是“银弹”。
这正是：
五千标准非银弹，它的价值正确看
好的经验要吸取，不要教条要实效
联系客服
