在20世纪60年代末，美国国防部的大人物们遇到了一些烦心事：支付了大笔预算的软件采购项目，却迟迟不能交付，即使交付了，也会出现这样或那样的问题。为此，“国防部为未能解决软件问题受到了巨大惩罚，惩罚不仅是软件交付的时间推迟，而且使作战能力大打折扣。”
有人说，“能够用钱解决的，那都不是事儿”。可是，这个软件问题，却不是用钱就能解决的：即使增加再多的经费，软件的问题依然存在。被逼无奈，国防部放了大招：广发招贤榜，征求解决软件难题的办法。
最终卡内基梅隆大学软件工程研究所(SEI)揭了榜。
SEI聚集了学术界、研究界和工业界的代表，在各自实践的基础上进行总结和提升，形成了被证明能够成功避免国防部软件采购困扰问题的方法，这就是CMM（Capability Maturity Model）。
CMM的横空出世，确实发挥出了极大的作用，软件危机得到一定程度的缓解。可是，很多软件项目并不是纯软件，还涉及到硬件，CMM的那些优秀实践就不那么适应，别别扭扭。所以，SEI又制定了系统工程CMM，集成产品开发CMM，最终合并成CMMI（Capability Maturity Model Integration）。
这就是CMM的演化历史1（见下图）。
图1-1 CMM演化历史
CMM的迅猛发展及其所起到的成效，逐渐引起国内有识之士的重视，先后有源自CMM的GJB5000和源自CMMI开发模型的GJB5000A标准的诞生。
这就是GJB5000A标准的源起。
从标准的源起来看，为什么要推进GJB5000A？因为这个标准是软件业界优秀的实践集大成者，应用这些优秀实践能够解决软件迟迟不能交付的问题，能够解决各种软件质量问题。
小故事：
一位老教授做过一个测试。
老教授问：“如果你去山上砍树，正好面前有两棵树，一棵粗，另一棵细，你会砍哪一棵?”
问题一出，大家都说：“当然砍那棵粗的了” 。
老教授一笑，说：“那棵粗的不过是一棵普通的杨树，而那棵细的却是红松，现在你们会砍哪一棵?”
学生们一想，红松比较珍贵，就说：“当然砍红松了，杨树又不值钱！”
老教授带着不变的微笑看着学生们，问：“那如果杨树是笔直的，而红松却七歪八扭，你们会砍哪一棵?”
学生们觉得有些疑惑，就说:“如果这样的话，还是砍杨树。红松弯弯曲曲的，什么都做不了！”
老教授目光闪烁着，学生们猜想他又要加条件了，果然，他说:“杨树虽然笔直，可由于年头太久，中间大多空了，这时，你们会砍哪一棵?”
虽然搞不懂老教授的葫芦里卖的什么药，学生们还是从他所给的条件出发，说：“那还是砍红松，杨树中间空了，更没有用！”
老教授紧接着问：“可是红松虽然不是中空的，但它扭曲得太厉害，砍起来非常困难，你们会砍哪一棵?”
学生们索性也不去考虑他到底想得出什么结论，就说：“那就砍杨树。同样没啥大用，当然挑容易砍的砍了！”
老教授不容喘息地又问：“可是杨树之上有个鸟巢，几只幼鸟正躲在巢中，你会砍哪一棵?”
终于，有人问：“教授，您到底想告诉我们什么？测试些什么呢?”
老教授收起笑容，说:“你们怎么就没人问问自己，到底为什么砍树呢?虽然我的条件不断变化，可是最终结果取决于你们最初的动机。如果想要取柴，你就砍杨树；想做工艺品，就砍红松。你们当然不会无缘无故提着斧头上山砍树了！”
这个故事告诉我们：很多人出发太久了，竟然忘了为什么上路?
不忘初衷。
我们推进GJB5000A标准，永远不能忘记初衷。否则，就会只记得过级，从二级，奔三级，从三级，奔四级，及至五级；或者迷失在实践集的汪洋大海之中，但却忘了用它来解决软件的问题。
那样的话，我们推进5000标准还有意义吗？
