帶你讀《SAS資料分析開發之道 軟體品質的次元》第二章品質2.1品質的定義（三）

一個新的品質詞彙

為了對軟體品質進行初步的評估，我們假設存在以下 SAS資料集 ：

datasample;

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

run;

我們現在需要評估以下 SAS代碼的品質，該代碼模仿的是提取 - 轉換 - 加載

（ETL）或其他軟體中一個更大的資料轉換子產品 ：

datauppersample;setsample;

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

那麼，上面代碼的品質是高、低還是介于兩者之間呢？換句話說，我們會繼續雇    傭編寫該代碼的 SAS從業人員，還是因他犯了低級錯誤而解雇他呢？這裡就存在品質陷阱。考慮到 ISO和IEEE的品質定義，如果不知道軟體背後的目标、需求和要求， 我們就無法判斷這是一個高品質軟體還是低品質的軟體。

接下來，我們需要找出要求建立上述代碼的經理所發來的郵件   ：請将樣本資料集轉換成大寫形式，15 分鐘後我要用它進行示範。

此時，我們就能了解最終的項目需求，确定這是一個高品質的代碼，因為它滿足了所有的要求，而且是迅速建立完成的。唯一的功能性需求是需要大寫，而且推測出唯一的性能需求是操作速度，因為經理要求迅速編寫并執行代碼。它并不是完美無缺的，但實作了客戶指定的商業價值。

但現在假設，該經理發送了下面這封電子郵件對軟體做出要求     ：

請建立一個能将樣本資料集中所有字元變量變成大寫形式的子產品。該子產品在DATA   步驟中應能夠被調用為宏，而且應該指定被大寫化為一個參數的資料集。字元變量應該能被不斷地識别和完成大寫化，而無須手動搜尋變量名稱。

上述要求和說明規定軟體要有完全一緻的功能性（至少用于樣本資料集時是如此），但實際更具動态性和複雜性。該經理要求的是一個子產品化解決方案，是以，可能需要建立一個 SAS宏。而且，考慮到宏要求資料集和變量名稱是動态的，子產品應該能重複利用，在其他情境和後續資料集中依然能執行相同的功能。如果該小組之後需要在更大的資料集中實作多個變量的大寫化——手動編碼可能需要較長的時間，那麼子產品的重複利用将是非常有益的。

假設是後者這種比較複雜的要求，那麼最初建立的轉換代碼可能就是低品質的。    它能滿足最終的功能目标（所有的變量都是大寫形式的），但無法滿足性能需求——子產品化、動态和可重用。第 18章會介紹能滿足這些附加性能需求的SAS解決方案。代碼複雜性增加，就要考慮品質特性、複雜性和開發時間三者之間的互相關系，這是    軟體開發中固有的權衡分析。

品質次元

假設品質具體運用到軟體開發領域，我們依然需要抛開軟體需求，對軟體進行描述，顯示品質特征（性能需求）的高低程度。例如，回到原來的問題   ：如果我不知道該經理發送給開發人員的這封對軟體要求做出規定的郵件，那麼我該如何憑空描述代碼的品質呢？

如果非要說，我可能會将這個代碼與有類似功能的理論上的代碼相比較，然後用      “品質相對較低”來描述這個代碼。更有可能的是，我會說這個代碼不是“生産軟體”，參照可能存在的理論性要求評估這個代碼，看它是否有關鍵的基礎架構支撐，是否有相關性，是否有多個使用者或者有較長的預期使用期限。然而，使用軟體品質模型最大的一個好處是不涉及品質便可讨論軟體的性能。例如，我可以說這個代碼缺少穩定性、   複用性及子產品化——子產品化是在不涉及需求和要求的情況下評估軟體的。

使用軟體品質模型建立的這個專用詞彙有益于開發環境，因為這個派生的詞彙對軟體性能評估是非常重要的。隻有按照明确的科技要求，使用統一的命名法，我們才能在軟體中加入并評估品質。有時，我們說軟體“缺乏子產品化和複用性”要比簡單地強調它“沒有品質”更具體有效。盡管利益相關者對某些具體産品的品質次元不做要求，但他們會有一個公認的模型和詞彙來讨論品質。

資料品質和資料産品品質

在SAS文獻中，我們所說的品質通常指的是“資料品質”，從更狹義的角度來講，指的是資料産品的品質，如分析報告等。實際上，在資料分析開發中，品質實際表示    的不是軟體或代碼品質。這與傳統的軟體開發文獻形成鮮明的對比，傳統的軟體開發    文獻描述的是軟體品質的特征以及設計和建立軟體品質所使用的方法。

在傳統軟體開發環境中，軟體本身就是終端産品，而資料分析開發環境通常将數    據産品看作是終端産品，是商業價值的來源，考慮到這一點，品質落腳點的轉變也是    有所期待的。但遺憾的是，讓資料品質和資料産品品質來代替代碼品質，這使資料分    析開發環境無法在 SDLC 中融入性能需求。是以，在确定要求、設計、開發、測試、接受和操作環節中，代碼品質都是位居資料品質之後的。

如果支撐資料産品的軟體品質不過關，那麼這些資料産品的品質又如何能讓人信服呢？為了解釋清楚這個稀松平常的悖論，我借用一個朋友的分析來進行說明，這個朋友在國防部工作時遇到了一個軍銜上有三星的将軍，他堅持認為SAS   生成的分析報表的一些線條（紫色不夠深），隻關注資料産品的品質，卻毫不關心支撐資料産品的軟體的品質。這個軟體可靠嗎，耐用嗎，容易受漏洞威脅嗎，能夠擴充嗎，如果将軍因戰術需要而要求輕微調整分析結果，那麼該軟體便于修改和改作他用嗎？不，與代碼品質相關的這些問題他一概不問，而隻問：“你能把這個紫色加深嗎？”

本書的目的不是淡化資料品質和資料産品品質的重要性，而是将代碼品質和資料品質放在了同等重要的位置上，因為基礎不良的好建築是沒有的。