小軟體開發該不該實施GJB5000？
在軍用軟體中，很大一部分是小軟體——規模小，功能少。所以，在GJB5000剛開始推進的時候，很多組織對GJB5000是否適用此類小軟體提出質疑：
本來一個人用上1~2周的時間就可以完成一個小軟體的開發和除錯，依照GJB5000要求來開發，卻需要建立一個4 ~ 5人的團隊，用2~3個月的時間才能完成，值得嗎？
還有人說：
小軟體開發要用敏捷！
對於小軟體就要用敏捷這樣的提法，個人認為是對敏捷的理解僅停留在感性認識上。敏捷絕不限於一兩個人的小專案，有多個開發人員的團隊並不影響敏捷的應用；敏捷倡導擁抱變化，如果需求都很明確，即使是小軟體開發也不一定要使用敏捷。
再回到第一個問題。
在實施GJB5000之前，大多數小軟體的開發都是這樣由1個人來完成，而且這個人通常是元件的負責人，既負責硬體設計也負責軟體開發。開發週期不長，驗證主要靠在硬體板卡上除錯完成。
這樣的結果常常是把發現和修復軟體問題放在後期系統聯試，甚至之後的外場試驗中。
這樣做的代價會是巨大的。
小軟體的問題，可能會導致系統的崩潰。由此帶來整個系統聯試程序的推遲，影響試驗節點……
按照GJB5000的要求，建立一個團隊，有質量保證、配置管理，有評審和測試，軟體的質量會有很大提高！軟體在系統聯試期間再暴露問題的機率會大大降低！
這樣做是否值得？
理論上來說，實施GJB5000會有更多的質量控制措施，這樣開發的軟體質量會有保證。
最讓人信服的方法是度量出小軟體開發工作量加上發現和修復問題的工作量，比較兩種方式下的開發成本，會給出一個準確的答案。
而且，對於軍用軟體開發來說，更應關注軟體的質量而非軟體的成本。
這正是：
成本因素要考慮，但它不是唯一地
不管規模大或小，軍軟質量最重要
作者簡介：王小雙，長期從事GJB5000推廣、實施、評價、改進的工作，建立《軟體工程之思》微信公眾號，一直在《軟體工程之思》分享GJB5000、CMMI、軟體工程的知識和感悟。現致力於GJB5000諮詢以及軟體過程改進、軟體工程能力提升的研究工作。