重视架构——基于CMMI2.0思考对设计实现实践域的优化

CMMI 2.0中的技术解决方案与前版相比的一个重大变化是增加了设计评审的实践，去掉了依据准则设计接口的实践。 除此之外，CMMI 2.0对原有的实践也提出了更高或更明确的要求。 以上这些变化，可以在以下几个方面帮助优化我们的软件过程管理体系：

1. 让设计和实现更加紧密

在CMMI 2.0中，将前版TS过程域的SP2.1“设计产品或产品部件”和SP3.1“实现设计”两个专用实践合并为一个实践。 这不是简单的实践合并，同时也是两个活动的合并。 在现实的软件开发过程中，设计和实现在一些场景下很难是瀑布式的、先后进行，而是相互融合、交替迭代的形式进行。

在我们的软件过程管理体系中，应当构建这样的生命周期模型。

2. 重视架构设计

在前版的TS过程域的设计产品和产品部件实践中，给出了概要设计和详细设计的要求，而在CMMI 2.0的实践中明确了对架构的要求： 架构应当遵循设计标准和最佳实践、反映操作概念和场景、可追溯到需求。 我们的设计规范当中，应当补充架构设计的上述要求。

3. 重视设计评审

前版TS过程域中，对于设计评审并没有直接的专用实践，它是隐含在诸如“确保设计遵循可用的设计标准和准则”这样的表述中。 而在CMMI 2.0中则明确要求应当对设计进行审查，以减少缺陷、降低成本。 而且还要求编制评审检查单。 设计评审的内容也悄局限于设计方案，也可能是设计实体。

我们通常的设计评审多数都是对设计说明文档进行评审，而实际上设计评审的目的只是了解设计方案，去除方案中的缺陷，所以评审的内容也不应局限于文档。 这一点可以在我们的软件过程管理体系中改进。

4. 设计方案选择准则的要求

CMMI 2.0中关于设计方案的选择准则也有了一些不一样的要求。 比如： 对于某些特定的解决方案来说，2.0允许无备选解决方案的情况出现； 设计方案的选择标准会因领域的不同而不同，其它项目的选择标准未必适用本项目。

我们的设计方案选择准则也应补充上述要求。

以上就是CMMI 2.0给出的对技术解决方案（设计实现）过程域的优化建议。

这正是：

设计实现不分家，架构值得时间花

评审未必看文档，方案选择也优化

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