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资质审核,软件的可靠性、安全性、保密性等这些关键需求将不再是一句空话。
这正是:
关键需求不能略,忽视形成恶后果
标准明确有要求,无论如何必须做