内部软件质量

内部软件质量的定义是软件产品在特定条件下使用时，它们的一组静态属性满足明确和隐含要求的能力。这些特征只能通过代码的静态审查观测，可读性有时会在附加的软件文档中体现。可测试性有时可通过一个正式的测试计划和测试案例进行评估，第 16章“可测试性”会讲到这一点。

内部软件质量有时被称作白盒质量方法（玻璃箱），因为质量的评估是通过代码监测而不是代码执行完成的。软件复用的白盒视图是根据复用原则评估软件可被复用的程度，但要求手动查看代码，或通过解析代码的第三方软件审查代码。由于在传统加密的软件应用程序中，用户无法获取基础的代码，因此，他们无法评估内部的软件质量    ；如果他们缺少技术方面的经验，那么他们可能甚至都不知道内部软件质量这个概念。

静态性能需求

静态性能需求指内部软件质量，如可维护性、模块化或稳定性。在某些组织和软件项目中，由于内部软件质量特征具有本质上的不显露性，所以与那些更容易观察的动态性能需求比起来，我们更难让利益相关者重视并进而将这些静态质量特征考虑进软件内。例如，我们很容易向客户阐释速度提升的好处，但若要解释清楚提升复用性的好处，则需要介绍复用性和软件的重复利用。

静态性能需求除了更难观测之外，它给利益相关人员带来的也不是即时的满足，    而代表的是对软件产品的未来投资。例如，当完善动态性能以提升软件运行速度时，    这效果不仅是可观测的，还是即时的。若要完善静态性能以提升软件的可读性或模 块化时，这些改变是无法观测的（通过软件性能），而且，我们只能在下次软件需要审查或修改时才能看到此次改进的益处。模块化能够助长被改进的动态性能的功 效，第 7  章“运行效率”会讲到这一点，但通常来讲，静态性能需求既无法观测，又不能获得即时的效果。但随着软件的预期使用期限不断延长，静态性能需求也变得  越来越重要，因为它们能提升软件的可维护性——这是增加软件寿命最关键的特征  之一。

混合质量

单个软件质量维度的组织是非常简单的，但由于术语定义的多样化，高级结构中

（如质量模型）质量维度的组织可能是非常复杂的。例如，外部软件质量包括功能性    和性能需求，软件的文献中通常会将这两种要求分开。这一点反映在 ISO软件产品质量模型中，该模型将功能的适用性（功能性）划归为软件产品质量。

其他质量模型包含了性能特征但删掉了功能性。例如，铁三角（项目范围、进度    和成本之间的联系）的许多定义将范围解释为具有独立质量和功能性的组件，这表明    它是一个不包含功能性的质量模型。国际商业分析研究所在“业务分析知识体系指南”

（BABOKGuide®）中的需求定义中将质量与功能性进行了区分 ：

■     功能性需求   ：系统在所管理的行为和信息方面应具有的功能   ；

■     非功能性需求或服务质量需求     ：与系统的功能性行为没有直接的联系，而是指系统必须保持有效的运转状况或者系统必须具有的质量。

较多的质量模型混合存在，因为软件性能需求既包括动态性能需求，又包括静态性能需求，前者代表的是外部软件质量特征（删除功能性），而后者指内部软件质量特征。由于本书主要讲述软件性能，而不提及功能性（假设功能性需求在所有情况下均已达到），因此，本书所涉及的质量结构体现的是动态和静态性能的二元现象。

图2-3展示的是混合质量结构，在对质量的多种诠释中，突出强调的是功能性、可靠性和可维护性。无论功能性是软件的一个成分，还是功能性和质量都是范围属性的成分，有一点是非常清楚的——软件功能性和软件性能之间确实会相互竞争资源，以期被优先考虑到软件产品需求中，质量的这一方面及其他权衡取舍会在后面部分进行讲解。