CMMI2.2的启示：软件的关键性需求不能只是一句空话！
2021年3月10日，CMMI研究院发布了CMMI V2.2，作为CMMI 2.0的一次重要升级，其主要变化包括SAM不再作为核心（core）实践域了，仅是供应商管理中一个特定实践域；增加了虚拟评估和虚拟培训；更重要的是增加了三个与软件安全性（safety和security）有关的实践域。
这表明 CMMI对安全性的高度重视。
而提到软件安全性，不管是safety还是security，军用软件肯定要比民用软件更加重视。所以在GJB438B的软件研制任务书模板把可靠性、安全性和保密性作为关键性需求，单独列出来。
但是在具体的实践当中，这些关键性需求没有受到足够的重视：在任务书中的描述都是一些定性的或者模糊的定义，后续的开发过程中没有对其进行需求分析、设计和实现，更谈不上验证和确认了。
尽管我们早就有了关于软件安全性的国家军用标准——GJB/Z 142 军用软件安全性分析指南，对不同软件等级的安全性提出不同的要求，但在实际上这个标准并没有被很好地执行。
好在随着CMMI 2.0的发布，GJB5000A的修订也提上日程。新版的GJB5000B不仅借鉴了CMMI 2.0的一些理念，对于软件的这些关键性需求也提出专用的实践要求。
CMMI 2.2中关于安全性有3个实践域，分别是Enabling Safety（ESAF）、Enabling Security（ESEC）、Managing Security Threats & Vulnerabilities（MST）, 它们都属于Managing Security and Safety能力域。
其中，Enabling Safety实践域有3个等级共8个实践，Enabling Security实践域有3个等级共9个初中域，Managing Security Threats & Vulnerabilities实践域有4个等级共10个实践。
具体可以参见丛斌博士的文章《揭开CMMI 2.0模型中 Safety和Security的面纱》。
在丛博士的文章中还对安全性的评估方式做了讨论：是将安全性作为独立的模型来评价其成熟度等级，还是将其和开发模型的其他实践域结合在一起来评价。
而在我们即将发布的GJB5000B标准中，采用的是更为简单的方式——将安全性等关键需求的要求作为一个实践融入到需求开发、设计、验证和确认这些实践域中。具体来说：
在需求开发与管理实践域中的3级实践中增加：依据准则分析可靠性安全性等质量特性需求
在技术解决方案实践域中的3级实践中增加：依据准则开展可靠性安全性等质量特性设计
在验证和确认实践域中的3级实践中增加：开展可靠性安全性等质量特性的验证与确认
与CMMI 2.2相比较，GJB5000B的做法更为简洁实用。当然对于GJB5000B的修订者来说，也应该对CMMI 2.2中关于安全性三个实践域27个实践进行深入研究，借鉴并完善GJB5000B标准关于安全性要求。
所以当GJB5000B发布并实施之后，随着每年至少一次的GJB5000资质审核，软件的可靠性、安全性、保密性等这些关键需求将不再是一句空话。
这正是：
关键需求不能略，忽视形成恶后果
标准明确有要求，无论如何必须做