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

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

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

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

    根据这些标准，我们现在设计一个软件设计评价表模版：

软件设计评价表
软件名称							迭代周期
设计人员
评审人员
设计合理性
需求附合度
功能点覆盖率（FPC）			?%			重点功能点覆盖率（IFPC）		?%
优先功能覆盖率（PFPC）			?%			需求一致度(Should be 100%)		?%
质量属性
模块性	权重	在过程中确定权重			分数，100分制，下同
可修改性	权重	权重之和应为100%
可扩展性	权重	下同
性能	权重
可靠性	权重
可用性	权重
可移植性	权重
可维护性	权重
灵活性	权重
可重用性	权重
可理解性	权重
弹性	权重
安全性	权重
容错性	权重
评审结论

    在设计合理性方面，主要考虑以下内容：

• 类的职责单一、明确
• 模块结构清晰、完整
• 活动、行为描述清晰
• 实体关联清楚，状态合理
  

    对需求附合度的要求要在评价之间确定。

    质量属性的评价权重一般在设计开始之前确定，这个工作多数在架构设计时刻完成。最后，根据质量属性的权重，可以计算设计的总体质量分数。这些都是最终评审结论的素材。

    一般来说，对于设计的评价通过建立场景的方法来实现。比如评价可修改性，一般先建立一个修改的场景，对设计进行模拟修改，观察其是否易于修改。有些质量属性无法通过这种方法检验，只能通过对设计模型进行观察得出结论。