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

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

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


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

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

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

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

虽然从理论上我们可以知道软件设计评价具有三类标准，但却没有办法真正按照这些标准去检验一个软件的设计。

   实体空间标准应该是一个软件设计最终应该附合的标准。但是，这个标准很难直接应用于软件设计模型上，因为软件设计是思维的产物，在实体上检验这个产物是否正确，恐怕只能说“实践是检验真理的唯一标准”了。只有在错误非常明显的情况下，这个标准才会起作用。

    过程空间标准相对好一些。通过和软件生产过程前期阶段产物进行对比，可以找到其中不一致的地方，这可能就是设计上的问题了。同时，现代软件开发一般采用迭代的方式进行，设计活动可能分多次进行。这种迭代也要求我们检查设计对需求的覆盖情况。

    通过形式空间标准对软件设计进行检验时，往往并不存在一个唯一的检验标准。这是因为实际软件的质量要求不是唯一的，不同的软件有不同的质量属性要求。而特定软件的质量要求，是在需求分析、设计的过程中逐步形成的。这些质量要求，最终成为我们检验软件设计的标准之一。 

    

原文转自：http://www.ltesting.net