一个新的质量词汇

为了对软件质量进行初步的评估，我们假设存在以下 SAS数据集 ：

datasample;

lengthchar1$20char2$20;char1="IloveSAS";char2="SASlovesme";

run;

 

我们现在需要评估以下 SAS代码的质量，该代码模仿的是提取 - 转换 - 加载

（ETL）或其他软件中一个更大的数据转换模块 ：

datauppersample;setsample;

char1=upcase(char1);char2=upcase(char2);

run;

 

那么，上面代码的质量是高、低还是介于两者之间呢？换句话说，我们会继续雇    佣编写该代码的 SAS从业人员，还是因他犯了低级错误而解雇他呢？这里就存在质量陷阱。考虑到 ISO和IEEE的质量定义，如果不知道软件背后的目标、需求和要求， 我们就无法判断这是一个高质量软件还是低质量的软件。

接下来，我们需要找出要求创建上述代码的经理所发来的邮件   ：请将样本数据集转换成大写形式，15 分钟后我要用它进行演示。

此时，我们就能了解最终的项目需求，确定这是一个高质量的代码，因为它满足了所有的要求，而且是迅速创建完成的。唯一的功能性需求是需要大写，而且推测出唯一的性能需求是操作速度，因为经理要求迅速编写并执行代码。它并不是完美无缺的，但实现了客户指定的商业价值。

但现在假设，该经理发送了下面这封电子邮件对软件做出要求     ：

请创建一个能将样本数据集中所有字符变量变成大写形式的模块。该模块在DATA   步骤中应能够被调用为宏，而且应该指定被大写化为一个参数的数据集。字符变量应该能被不断地识别和完成大写化，而无须手动搜索变量名称。

上述要求和说明规定软件要有完全一致的功能性（至少用于样本数据集时是如此），但实际更具动态性和复杂性。该经理要求的是一个模块化解决方案，因此，可能需要创建一个 SAS宏。而且，考虑到宏要求数据集和变量名称是动态的，模块应该能重复利用，在其他情境和后续数据集中依然能执行相同的功能。如果该小组之后需要在更大的数据集中实现多个变量的大写化——手动编码可能需要较长的时间，那么模块的重复利用将是非常有益的。

假设是后者这种比较复杂的要求，那么最初创建的转换代码可能就是低质量的。    它能满足最终的功能目标（所有的变量都是大写形式的），但无法满足性能需求——模块化、动态和可重用。第 18章会介绍能满足这些附加性能需求的SAS解决方案。代码复杂性增加，就要考虑质量特性、复杂性和开发时间三者之间的相互关系，这是    软件开发中固有的权衡分析。

 

质量维度

假设质量具体运用到软件开发领域，我们依然需要抛开软件需求，对软件进行描述，显示质量特征（性能需求）的高低程度。例如，回到原来的问题   ：如果我不知道该经理发送给开发人员的这封对软件要求做出规定的邮件，那么我该如何凭空描述代码的质量呢？

如果非要说，我可能会将这个代码与有类似功能的理论上的代码相比较，然后用      “质量相对较低”来描述这个代码。更有可能的是，我会说这个代码不是“生产软件”，参照可能存在的理论性要求评估这个代码，看它是否有关键的基础架构支撑，是否有相关性，是否有多个用户或者有较长的预期使用期限。然而，使用软件质量模型最大的一个好处是不涉及质量便可讨论软件的性能。例如，我可以说这个代码缺少稳定性、   复用性及模块化——模块化是在不涉及需求和要求的情况下评估软件的。

使用软件质量模型创建的这个专用词汇有益于开发环境，因为这个派生的词汇对软件性能评估是非常重要的。只有按照明确的科技要求，使用统一的命名法，我们才能在软件中加入并评估质量。有时，我们说软件“缺乏模块化和复用性”要比简单地强调它“没有质量”更具体有效。尽管利益相关者对某些具体产品的质量维度不做要求，但他们会有一个公认的模型和词汇来讨论质量。

 

数据质量和数据产品质量

在SAS文献中，我们所说的质量通常指的是“数据质量”，从更狭义的角度来讲，指的是数据产品的质量，如分析报告等。实际上，在数据分析开发中，质量实际表示    的不是软件或代码质量。这与传统的软件开发文献形成鲜明的对比，传统的软件开发    文献描述的是软件质量的特征以及设计和创建软件质量所使用的方法。

在传统软件开发环境中，软件本身就是终端产品，而数据分析开发环境通常将数    据产品看作是终端产品，是商业价值的来源，考虑到这一点，质量落脚点的转变也是    有所期待的。但遗憾的是，让数据质量和数据产品质量来代替代码质量，这使数据分    析开发环境无法在 SDLC 中融入性能需求。因此，在确定要求、设计、开发、测试、接受和操作环节中，代码质量都是位居数据质量之后的。

如果支撑数据产品的软件质量不过关，那么这些数据产品的质量又如何能让人信服呢？为了解释清楚这个稀松平常的悖论，我借用一个朋友的分析来进行说明，这个朋友在国防部工作时遇到了一个军衔上有三星的将军，他坚持认为SAS   生成的分析报表的一些线条（紫色不够深），只关注数据产品的质量，却毫不关心支撑数据产品的软件的质量。这个软件可靠吗，耐用吗，容易受漏洞威胁吗，能够扩展吗，如果将军因战术需要而要求轻微调整分析结果，那么该软件便于修改和改作他用吗？不，与代码质量相关的这些问题他一概不问，而只问：“你能把这个紫色加深吗？”

本书的目的不是淡化数据质量和数据产品质量的重要性，而是将代码质量和数据质量放在了同等重要的位置上，因为基础不良的好建筑是没有的。