论CMM和CMMI论软件过程架构

  从CMM到CMMI 1.3经历过数次升级，但过程架构一词仅局限于术语定义层次，从来没有在实践描述中出现过。CMM是这样定义软件过程架构的：
软件过程架构是一个组织标准软件过程的概要（总结性）描述。它描述标准软件过程元素的次序、接口、相互依赖关系和其他关系。它同时也描述了软件过程元素和其他外部过程（如系统工程、硬件工程、和合同管理）之间的关系。

 CMMI 1.1到1.3基本继承了上面的定义，1.3开发模型将过程架构定义为：

（1）标准过程元素的次序、接口、内部依赖、其他关联关系；
（2）过程元素和外部过程的接口、相互依赖关系和其他关系。

到了CMMI 2.0时代，过程架构第一次出现在模型实践中。PAD 3.2明确提出“建立、记录、更新描述过程和过程资产结构的过程架构”。同时给了一个虚头八尾的实践价值，“一个富有活力的过程架构能确保过程的价值”。当你仔细阅读这条实践的阐述内容后，估计还是不能完全理解过程架构的具体定位，价值和核心内容。

 2.0在术语中是这样定义过程架构的：“标准过程或标准过程集中过程元素之间的顺序、接口、互相依赖关系和其他关系”，这和之前的定义没有什么变化。
 
我看软件过程架构，没有人质疑软件系统架构的重要性，软件过程架构在很多方面继承了其理念和方法。这也是Humphrey一开始给出的方向，可惜大师及后来者没有进一步深入研究并总结业界优秀实践。
大概在20年前，在雷神看到的CSWP（Common Software Process）软件过程架构，印象深刻，至今还记得雷神软件过程架构师在黑板上给我们展示各种过程的视图，让我见识了过程之美。
这20年来，断断续续一直在思考软件过程架构的问题，可惜共识者甚少。在咨询、培训过程中，也很少在这个领域深入展开。我接触到的许多国内导入CMMI的软件组织的软件过程架构鲜有活力，基本以摆设为主。
 
说到软件过程架构就离不开两个重要概念，一是过程结构（structure），二是过程视图（view）。

结构是软件过程包含内容的存在形式，视图则是站在具体干系人角度结构的展示，结构代表局部，而视图代表全景。结构应该清晰体现其内容存在的独特意义，并映射到软件开发中有价值的活动。软件过程架构可以支持重要干系人的视图，同时支持过程结构的设计。一般来讲，软件过程架构应该包含两个视图，站在端到端开发角度的视图；站在改进角度的过程视图。和软件系统架构相比，过程架构的考虑点有许多不同之处。系统架构展示元素之间如何相互配合实现具体的功能，而软件过程元素之间的关系则是环环相连，逐步实现整个过程目标。所以最终目标，关键中间目标应该在软件过程架构中明确体现，关键关系中应该包含这些目标之间的关系。 软件开发过程包含了核心过程和支持过程，架构也应体现它们之间的关系。

过程裁剪让许多软件组织头疼，标准建在哪里？灵活度如何把控？在不合理的进度、资源欠缺前提下，如何执行过程，如何保证质量底线，好的过程结构是能够给出一个好的答案。

Humphrey当年提出的ETXM（entry，task，exit，measure，也叫ETVX见下图）过程结构有许多合理之处，许多组织的过程都是按这个结构形成的。但大都有个通病，就是结果模糊，活动大而全。
但软件开发具有不确定性的特点，这种结构其实并不适用。结果明确，过程灵活应该是我们追求的目标。核心过程活动模块化、标准化支持多种开发模式，保证质量底线也是软件过程结构的重要考虑。

 CMMI 2.0没有给出具体的软件过程架构带来的好处，这里我罗列几条好的过程架构明显的价值点：
- 为软件过程改进和软件开发提供了一个很好的基础；
-  有助于过程在项目中的落地，减低过程培训成本；
-  有效支持过程的可扩展性；
-  帮助理解过程活动的价值点，引导过程执行者的正确行为规范；
-  有助于跨团队、跨领域协同作战，拉通活动和目标的关系；

-  便于过程管理，特别是动态化的过程管理。

 下面是我的软件过程架构的定义：
一个软件组织的过程架构是由一组相关联的过程结构组成，通过关键干系人的视图，清晰展示在视图中过程结构中内容的价值，结构之间的关键属性关系（依赖、反馈、支持、目标等）和接口关系（接力棒接口等）。