在军用软件中，很大一部分是小软件——规模小，功能少。所以，在GJB5000刚开始推进的时候，很多组织对GJB5000是否适用此类小软件提出质疑：

本来一个人用上1~2周的时间就可以完成一个小软件的开发和调试，依照GJB5000要求来开发，却需要建立一个4 ~ 5人的团队，用2~3个月的时间才能完成，值得吗？

还有人说：

小软件开发要用敏捷！

对于小软件就要用敏捷这样的提法，个人认为是对敏捷的理解仅停留在感性认识上。敏捷绝不限于一两个人的小项目，有多个开发人员的团队并不影响敏捷的应用；敏捷倡导拥抱变化，如果需求都很明确，即使是小软件开发也不一定要使用敏捷。

再回到第一个问题。

在实施GJB5000之前，大多数小软件的开发都是这样由1个人来完成，而且这个人通常是组件的负责人，既负责硬件设计也负责软件开发。开发周期不长，验证主要靠在硬件板卡上调试完成。

这样的结果常常是把发现和修复软件问题放在后期系统联试，甚至之后的外场试验中。

这样做的代价会是巨大的。

小软件的问题，可能会导致系统的崩溃。由此带来整个系统联试进程的推迟，影响试验节点……

按照GJB5000的要求，建立一个团队，有质量保证、配置管理，有评审和测试，软件的质量会有很大提高！软件在系统联试期间再暴露问题的几率会大大降低！

这样做是否值得？

理论上来说，实施GJB5000会有更多的质量控制措施，这样开发的软件质量会有保证。

最让人信服的方法是度量出小软件开发工作量加上发现和修复问题的工作量，比较两种方式下的开发成本，会给出一个准确的答案。

而且，对于军用软件开发来说，更应关注软件的质量而非软件的成本。

这正是：

成本因素要考虑，但它不是唯一地

不管规模大或小，军软质量最重要

作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。