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资质审核,软件的可靠性、安全性、保密性等这些关键需求将不再是一句空话。

这正是:

关键需求不能略,忽视形成恶后果

标准明确有要求,无论如何必须做


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

相关推荐