往往在解决一个困难之后，就会出来一个新的困难。当我们渐渐意识到越早发现错误，就越容易解决问题的时候，我们开始了看上去比较正规的评价活动，对软件开 发计划、需求、设计等进行评价。在一段时间之后，我们失望的发现，这对我们遇到的困难帮助不大，我们的评价活动存在流于形式的问题。

    但我无意于对所有的评价活动发表意见，只想就比较熟悉的软件设计评价进行讨论。

    软件设计通过软件统设计模型来表示（参见《再议模型》），软件设计评价是对软件系统设计模型的评价。在这里，我们使用源系统表示软件要实现自动化的系统，它处于实体空间；目标系统表示要实现的软件本身，它处于形式空间。软件表示模型（即系统分析模型和系统设计模型，参见《再议模型》）是沟通源系统和目标系统的桥梁。表示模型的形成需要一个过程，我们称其为过程空间。下面我们使用图形方式来描述：


   这样，软件设计评价应该具有三类标准，分别是实体空间标准、过程空间标准和形式空间标准。

   实体空间标准以源系统做为标准来度量系统设计模型。这依赖于我们对于源系统的认识程度，我们知道应该具有这样一个标准，但实行起来非常困难。设计的合理性就是实体空间标准，它没有一个具体的内容和形式。

   过程空间标准在设计评价中经常被使用。它可以看作实体空间的间接标准，基于分析模型和设计模型是出于同一实体，其中具有自然的关联。我们说，设计是否附合需求，就是检验设计模型和分析模型的一致性。

    形式空间标准以目标系统的角度检验系统设计。从上述两种标准，可以保证目标系统的功能满足源系统，但不能保证目标系统在运行状态 下的质量属性。所以形式空间标准是从目标系统的质量出发来考察系统设计的。考虑到质量，我们使用McCall/GE质量模型，它围绕产品改进、产品运行、 产品移交三种使用情况来组织质量属性，可以看出是基于目标系统的。国际上有很多现行的基于质量评价系统设计的方法，我们后面会参考其中的部分。

    继续阅读《软件设计评价（续）》。