软件是怎么做成的（CMM 需求篇）

一、 前言
人们常说“软件谁都会做，但是谁都做不好”。
软件公司的潮起潮落也说明了这一点。
成功的软件公司通常都不太像软件公司，例如，盛大，新浪等，而真正的软件公司通常都是举步艰难的公司，或者在历史上留下悲壮的一页。
为什么？
这些公司同样都有过良好的市场机会，但是也都同样地缺少关键的条件：知道如何可以把软件做好。
学术界还不能说已经找到了可以可*地“把软件做好”的方法，因为在今天学术界还在讨论着原始的问题：软件是工程结果，还是艺术结果。
为此中山大学软件所同中元公司（以下简称“我们”）对这一问题进行一些试探性的研究，并且取得初步结果。
要想解决“如何把软件做好”的问题至少要解决如下两个技术性问题：
·把问题搞清楚
·把事情做出来
我们在解决这两个问题上得到了一些可操作的结果。
二、 背景
无论如何，软件工程学是计算机学术界和工业界广泛注意的课题，并且学术成果丰富。但是操作的成果不多，因为否则，则人们早就知道了“如何把软件做好”了，其中影响最广的如下：
·E-R图
·UML
·CMM
1. E-R图
E-R图是由P.P.Chen于1976年提出的，其论文发表于ACM Transaction on Database System上。当时关系模型刚提出不久（1970年，Codd），并且关系数据库系统刚刚被工业界认可。由于时代的原因，当时的应用软件应当是相对简单和以数据库查询为主的。这些应用可以对应于今天的管理信息系统（MIS）。
当时P.P.Chen认识到MIS的质量，取决于数据库的组织，而良好的数据库组织取决于数据之间的依赖关系。E-R图可以清楚地说明这种依赖关系。
P.P.Chen最大的贡献是使得数据库的设计“可视化”，可视化带来的效果是不言而喻的，因此至今E-R图仍被广泛地使用。
但是，如何得到E-R图，P.P.Chen没有论述，事实上得到正确的E-R图是十分困难的。
有的书中，把E-R图叙述为概要设计的工具，我们认为这是不对的。明显在概要设计中主要是要回答“如何得到E-R图”的问题。
2. UML
UML被称为统一建模语言（Unified Modeling Language）。“统一”是指Grady Booch. Jim Rum baugh和Ivar Jacobson的研究工作的结合。经过三个人的共同努力，于1996年发布了UML0.9版本。从此，UML正式被工业界采用。
由于UML是一个图形化的问题描述语言，具有可视，简单和不同视角分别考察（搞清楚）问题的特点，因而UML被工业界广泛地采用。UML的广泛采用也说明了工业界对于一种能够把问题有效分解，可视化和简单的软件设计方法的需求是多么迫切的。
UML定义了两个模型无素，对象（不是OOP中的对象）和对象之间的联系，例如：类，构件，对象和关联，泛化，依赖和聚集等。同时他们分别可用图形化表示，例如：

UML比E-R进步的一点是对象同对象之间的联系是分别显式讨论的，而不像E-R首先讨论的是对象之间的关联关系，例如：1：n关系等。对于一个复杂问题的讨论，问题的有效分解是极为重要的。
但是UML中的对象概念，例如：类，对象和它们之间的联系，我们认为这些应当是设计阶段的概念。我们也认为在把问题“搞清楚”的阶段不易过多地引入计算机技术的概念，因为常常就是这些计算机的概念造成同用户沟通的困难，例如什么是类，对象，1对n的关系，或者键等这些常常连计算机科学家都难以搞清楚的概念。过早地引入计算机设计的概念常常引起用户和设计者在不同的问题空间都用着相同的语言（但不是表达相同的含义）讨论问题。在这种情况下想要把问题搞清楚几乎是不可能的。
总之，我们认为UML对于应用软件设计与开发是一个有意义的和可操作的方法。但是这也仅仅是解决“把软件做好”的问题进程中的一步，万里长征中的一步。
3. CMM
CMM是英文Capability Maturity Model 的缩写，也就是能力成熟度模型，和是由美国长内梅隆大学软件工程研究所（SEI）提出的。
CMM的研究在美国政府的要求下开始于1986年，并于1991年推出CMM1.0版。
自CMM1.0提出之后引起软件专家的注意，并且引起了激烈的争论。SEI在研究了这些争论后于1999年完成了CMM2.0版。今天我们讨论的主要是CMM2.0版。
CMM是从工程学的角度来讨论软件工程的，并且认为软件是工程而不仅仅是技术问题。我们认为这是一大进步。
由于软件是工程问题，因而把“软件做好”的问题转化为把“软件工程管好”的问题，我们认为这也是对的。
为了解决把“软件工程管好”的问题，CMM提出了软件管理的进化模型，并且认为级别越高，则“软件工程管理”得越好，我们认为这也是可以理解的。
CMM还提出，软件工程是可管理的，则软件开发过程一定是透明的，我们认为这是非常正确的。
但是，CMM没有认识到，软件工程既有“工程性”的一面，同时也有“艺术性”的一面，如工程中的算法设计一定是艺术性的（注：这里的艺术性是指非演绎性）。
但是，CMM虽然提出了管理的进化模型，但是却没有给出进化方法，最遗憾的是没有进化的客观标准。如果是由“人”去判断进化级别，则是十分不科学的。
但是，CMM虽然提出了软件工程透明理论，但是它过于平凡，并且E-R图早就是这么做的。
最不理想的是，没有实例说明满足CMM高等级的公司一定可以做好软件（例如：很多），和不满足CMM等级的公司做不好软件（例如：微软）。
我们认为CMM无法根本解决“把软件做好”的问题，因而不宜过度夸张。如果过度地夸张，则CMM的故事就变成了“基因皇后”的故事。
总之，据我们掌握的信息，目前还不能说找到了“把软件做好“的可*方法。
三、把事情搞清楚
“把事情搞清楚”对应于软件工程学中的“需求分析”和“规格说明”。
CMM认为：“结果表明：在软件开发和维护过程中，所有被检测出来的错误，54%是在编码和单元测试阶段以后才被发现的，其中45%是在需求和设计阶段发生的，而编码阶段的错误只占9%。另外，对GTE、TRW和IBM 三家公司的研究结果表明：在需求阶段查和修改一个错误的代价比值可高达1：200。”
这就说明，如果“事情搞不清楚”，则软件工程一定失败。同时，我们认为“敏捷开发”是以不记成本作为代价的，并且缺乏全局性。
3.1 需求分析。如果我们把软件的使用方叫做甲方，而软件开发方称为乙方，则需求分析过程可以理解为乙方听甲方讲故事并且整理出来的过程。
对于任何一个失败的软件工程项目来说，甲方和乙方都有很多话可说，例如：甲方说乙方开发的东西根本就不是我们想要什么东西；而乙方却说，你们根本就搞不清楚你们自己要什么东西。事实上两者都是有一定道理，因为目前，软件工程学本身就没有提出科学的方法（例如：CMM），可以使甲方讲的“故事”是完整的和不矛盾的，同时使乙方对“故事”的理解同甲方是一致的。
除了说不清楚之外，造成不确定的另一个原因就是需求本身就是变化的。道理是简单的，因为企业（或者政府）管理原则和方式本来就是不断进化的，因而造成对软件的需求也是在不断进化的。
任何一个软件公司面对需求的不确性都是痛苦的，因为需求的变化带来的是软件的变化，而任何软件变化的代价都会给软件开发带来巨大代价的。也就是在这种高昂的代价中，许多软件公司同项目一起消亡，甚至是前亡后继，例如，广州市社保项目。
解决需求不确定性是不可能的，但可以通过如下方法来减少它们带来的影响，尽可能地减少变化的所带来的代价：
·经验，乙方对甲方的业务非常了解，甚至讲起甲方的故事比乙方还要精彩，这时如果甲方讲的故事是不完全的或者不一致的，则乙方可以立即进行修正。这时变化的代价最小。遗憾的是通常情况下乙方不完全具备这种能力。目前已经有许多乙方把自己的公司技术积累转向为对某领域知识的理解。目前这是一种趋势。
·方法，如果能有一种方法能够把甲方的故事进行适当地抽象，则可以通过形式（或者半形式）化的方法进行推理，从而发现甲方讲的故事中的不完全或者不一致。这种方法虽然不能完全发现问题，但能最大限度地发现和解决问题。
·结构，假定需求是完全清楚的，但是也仍然解决不了需求变化的问题。需求变化时，软件也只能随之而变。在这种情况下，只能想办法减少变化所产生的代价，例如：软件的结构本身就是可进化的。可进化的软件结构技术要求是很高的，它要求以自动机理论作为根据。
软件所对于（2）和（3）的研究软件所有所进展，例如，基于主谓宾的需求获取方法，并且提出了带泳道的业务流程图，并且以此作为需求分析的标志性成果（见附录[1]）。
3.2 规格说明。如果说需求分析阶段是一个同用户交互的阶段，则规格说明阶段可以认为是同程度员交互的阶段。用户所讲的故事到程序员所编写的程序之间有着巨大的鸿沟。规格说明阶段主要的目的之一就是过渡这一鸿沟。
同用户交互的性质决定，需求分析结果一定是用一种双方都懂的语言进行描述的，因此不可能是完全形式化的。我们认为E-R图不是一种非常合适的需求分析表达方式，因为E-R图中的多对一，多对多，键的概念是用户方难以理解的概念，并且对于理解和说明故事的情节无关。但是很多软件工程的书都却把它引入到了需求分析一节。
同程序员打交道的性质决定，规格说明一定是形式化的，否则程序员就会“无所适从”或者根据自己的理解“自行其是”。
对需求分析而言，规格说明（Specification）应当是完全的，也就是说要全面地反映需求分析的结果。由于形式化，它还应当能够进一步地发现需求分析的不足，或说不完全的故事情节，并且完善它。同理，规格说明也应当是一致的，也就是说要正确地反映需求分析的结果。由于形式化，它应当能够进一步地发现需求分析的错误，或说矛盾的故事情节，并且纠正它。
除此之外，规格说明还应当是清楚，简单，可演绎和完全形式化的，其中：
·清楚的，是指一目了然，并且没有二意性的。
·简单的，是指多一分则过多，而少一分则不足，或没有多余的叙述，因为多余的叙述也是产生失败的因素之一。
·可演绎的，是指具有一定的可推导性。通过推导，形式地发现不一致性或者不完全性。
·形式化的，是指对于需求分析的解释应当是唯一的。
为了使得规格说明具有上述性质，我们研究了基本对象（不是OOP中的对象），它们之间的关系，表示方法，获取方法和演绎方法。
3.2.1 基本对象
根据主谓宾分析方法，我们这里的对象是指主语，谓语和宾语。
·主语。主语是指功能的使用者，也称为角色，通常代表人，硬件设备，甚至一个系统，例如：客户，供应商，财务部，或者是外部应用系统。但是主语不表示软件的具体使用人，因为某一个具体的使用人可能扮有多种角色，例如：财务总管可以是项目经理等。
主语可以从都有哪些使用者获得。
·谓语。谓语是指主语所做的操作，也称功能，通常代表一个操作，或者一个事件，甚至一个信号（外部），例如：入仓，收到一个通知，或者一个设备信号等。
谓语可以从主语都要做哪些操作获得。
·宾语。宾语是指主语做完操作之后所产生的副作用（Side-effects），也称为数据，通常表示为数据库中的表，或者程序中的数据结构等。
宾语可以从表单获得。
3.2.2 对象间的关系
当系统中的对象讨论清楚之后，我们就可以进一步讨论它们之间的关系，并且用形式化的方法表示出来。
● 宾语之间的关系
宾语之间的关系是讨论数据之间的关系，因此在数据库与数据工程书中多有讨论，例如：键，依赖和E-R关系等。我们认为它们讨论的都是设计层次问题，而规格说明则讨论的是元（mata）层次的问题。
为了清楚地表示宾语之间的元层次关系，我们提出了数据源向图的概念及表示方法。
数据源向图仅讨论数据之间的来源和去向问题。
首先从需求分析中总结出，系统中的全部基础数据，（或者称为原始数据EDB和结果数据CONS），并且表示为表格形式。

容易理解，用户方是清楚（或者客观清楚）它们的EDB和CONS通常情况下，用户方是不清楚如何由EDB得到CONS的。而这个“如何”是我们要在规格说明期间讨论清楚的。用逻辑的方法这个问题可以表示为：

如果我们讨论清楚了上面的RULS，则公式全部讨论清楚，在这里我们仅讨论公式的表格表示方法，例如：
其中的 RULS 表示数据的传递和变换规则。
明显数据源向图很容易转化为数据库的设计（ 见附录）。
注意，这里的表格不同于数据库中的表，但可以理解为逻辑层次上的表。
● 谓语同宾语之间的关系
谓语同宾语之间的关系，可以用一个OP表来表示。

以此类推，可以得到许多用户叙述的故事里没有涉及到的情节。
最后，op表可以转换为自动机表示方法状态图并作为状态推导引擎或者工作流引擎的输入基础。
● 主语同谓语之间的关系
主语同谓语的关系我们可以用一个SOP表来表示
    容易理解，SOP表可以清楚地表示角色同操作之间的权限关系。
容易理解，如果几个主语具有相同的权限和条件，则这几个主语可以定义为更高级概念的角色。
容易理解，如果某一个操作所有的角色都没有权限，则这个操作是没有意义的，反之，则不必设置权限。
以此类推，可以得到细致的操作权限细节，因为权限条件可以是逻辑表达式。
● 主语同宾语之间的关系
主语同宾语之间的关系，可以用一个Sob表来表示。

容易理解，Sob表表示角色与表单之间的权限关系。
容易理解，如果某一个主语对于所有表单都没有访问权限，则，这个主语根本就不用考虑，同理，对于表单亦然。
容易理解，如果某几个主语对于表单都具有相同的权限，则，可以定义更高级概念的角色。
以此类推，我们可以得到和清楚角色与表单之间的权限逻辑关系。
3．3 小结
所谓把事情搞清楚，也就是说搞清楚：谁，做了什么和产生了什么后果。
当主语同主语的关系搞清楚时，我们可以说搞清楚了组织架构。
当主语同谓语和主语同宾语关系搞清楚的时候，我们可以说对象之间的操作和访问权限关系基本清楚。
当谓语同谓语的顺序搞清楚时，我们可以说搞清楚了业务的操作流程。
当谓语同宾语的操作顺序搞清楚时，我们可以说搞清楚了业务的表单流程。
当宾语同宾语的关系搞清楚时，我们可以说搞清楚了数据之间的推导关系。
显然上述表示方法可以发现原来“故事”中不清楚的情节，和不一致的情节。
由于，表格是一种形式化的表示，并且 可以对内容进行分析，因而具有一定的归纳和演绎功能。
由于主语，谓语和宾语以及权限都是可分层的，因而可以采用递归表示方法（见附录），从而得到分层的主语，表单，操作等。事实上大多数应用都是分层的。分层的方法可以进一步地清楚问题。
不失一般性，分层后可以采用前述相同的方法。