3.5 質量特征計劃
  為幫助設計者們進行設計，我們準備編寫一本設計指南的書，內容包括設計中的一些有代表性的類型、模式和技術。
  類型是最簡單的基本結構，通常被用來定義體系結構。常見的類型的例子包括客戶-服務器結構，管道與過濾結構，分層結構等等。在早期的結構選擇上，按照組織體系進行選擇是一種有代表性的類型。
  模式是一種能夠重復使用的微觀結構。它通常根據其產生、結構、行為的特征進行分類。例如適配器就是一個協(xié)調型的模式。
  設計技術是其它有益于設計的相關信息，它能避免一個低水平的設計。例如，數(shù)據編碼的使用，用于安全性的密碼保護，為使操作簡便而使用應用程序接口方法(API)，等等。
  在體系結構/設計中選擇合適的類型、模式和技術，對能否實現(xiàn)設計目標具有很大的關系。例如，一個分層體系結構將有助于實現(xiàn)易更改性，但是降低了操作性能。設計指南一書將作為這種設計知識的倉庫而為設計者提供服務。
  在結構和設計階段可以參考設計指南。我們設想設計指南具有一個簡單的使用界面并發(fā)布在互聯(lián)網絡上，使設計者們能通過特殊的搜索工具根據其期望特征選擇相關的類型、模式和技術，從而建立一個關注質量特征的體系結構。設計指南將為設計者們提供詳細的入口信息，使他們能根據這些入口的適用性作出正確的選擇。
  3.6 過程改進
  在項目開發(fā)的生命周期行為中，應該盡量使用上面提及的那些新技術。通過這些新技術，可以增強現(xiàn)有過程能力和過程資產(模版、指導方針、檢驗方法)，實現(xiàn)產品質量焦點一體化。
  項目開發(fā)的生命周期主要包括幾個階段(或如下圖所示)：

  —在需求階段明確地列出所有需要關注的特征，
  —在產品設計期間關注各項特征，
  —從產品質量角度出發(fā)對可交付產品進行檢驗，
  —確定測試案例并進行測試，檢查并核實特征是否滿足。
  對指定的特征進行測量、跟蹤和分析。
  例如，需要改進的過程資產用步驟序列的形式表示如下：
  —暫時不考慮計劃
  —需求手冊模板
  —設計(HLD,LLD)模板
  —預演指導方針
  —檢驗指導方針
  —帳目檢查表
  —測試計劃文檔/測試案例文檔
  —發(fā)布檢查表
  —用戶滿意度調查程序及其提問單
  來自發(fā)展組織內部的軟件質量工程師、過程工程師以及軟件質量改進的支持者們都致力于改進過程的創(chuàng)新工作，他們在總結以往經驗的基礎上為改進過程設立了基線。當OPG(組織過程組)提出一個POR(過程時機報告)時，意味著開始進行過程改進。一旦對所有過程都實施了改進，我們將計劃召開Educom(教育/交流)會議來對組織內部進行溝通。
  3.7 評價標準
  產品質量的評價標準可以被分為兩大類，即：內在的評價標準和外在的評價標準。內在的評價標準與產品自身相關，而外在的評價標準與開發(fā)者為滿足產品目標所付出的努力相關。下表列出了部分與產品自身相關的內在評價標準：

  如果內在的評價標準之間存在各種關聯(lián)，那么采用該標準并不能明確地區(qū)分各個特征目標。因此，在通常情況下，我們建議采用外在的評價標準對產品質量特征進行評價。
  3.7.1 改進性
  任何一個改進性規(guī)范的目的都將為適應變化所需付出的努力程度分為低/中/高三類。在下表中，對低/中/高三種努力程度的含義給出了一種可能的解釋。該表相對于某個特定項目是十分準確的。

 3.7.3 可用性
  接下來講述的評價標準是與產品的可用性相關的，在SUMI方法中，對初始階段的任何原型的改進或在完成之后對產品的評價都需要使用可用性評價標準。該標準使用一些0—70范圍內的數(shù)值進行評價。
  1）綜合
  該評價標準反應用戶對于可用性的理解的綜合觀點
  2）效率
  該評價標準反應用戶對于該軟件能否通過一種有效的方式來完成工作任務的看法。
  3）影響
  該評價標準反應軟件對用戶產生的心理影響。即用戶使用該軟件而產生的精神壓力和身體壓力。
  4）作用
  該評價標準反應用戶對軟件能產生的作用大小的認可程度。
  5）控制
  該評價標準反應用戶在使用軟件的過程中的舒適程度。如果用戶可以比較容易的使用軟件實現(xiàn)他所希望實現(xiàn)的目標，那么該軟件具有良好的控制性。
  6）容易掌握
  該評價標準反應用戶是否能夠輕松地掌握軟件的使用方法并開始使用。
  3.7.4 有效性
  該評價標準與the five 9的系統(tǒng)有效性小組所提出的標準相同。
  1）nines的個數(shù)
  2）無效性原因的排列圖
  4. 基本的指導
  SMAP2000小組在需求分析階段就指定產品的質量特征作為設計的目標。他們把產品的操作性、可用性、可改進性作為產品的重要特征。項目小組在這些活動上大約花費了17個工作日(估計值)，但可以使項目從以下幾個方面受益。
  1）改善了圖形用戶界面設計，并增加了有用的設計觀點。
  2）有助于從用戶那里獲取他們對軟件的操作性能期望并在可解決的范圍內識別約束條件(例如帶寬)。
  3）通過改進的觀點幫助項目小組對當前產品的試用版本進行思考，幫助他們獲得改進的最新理解。它使產品的結構觀發(fā)生了轉變，從“能適應當前SMAP-2G的執(zhí)行”轉變?yōu)?ldquo;一個應用程序的網絡管理平臺”。
  4）特征規(guī)范可以應用于綜合集成和現(xiàn)場實驗，還可以用來解釋工具的操作行為。
  5）它能滿足過程改進體系結構的需要。
  6）對這些特征的研究使設計人員能更好地理解部分的功能需求。
  特征規(guī)范文檔可以在http://libra.miel.mot.com/~3gtoolscm/ 3G_smap.html獲得。
  當前，正在對項目設計進行操作性分析，計劃采用SAAM方法針對改進性進行設計分析。
在MIEL中的其它產品計劃(如SinglecellWiLL，VOIP)也已經開始采用這種方法進行分析。
  5. 實施步驟
  我們可以對產品質量特征或設計目標進行明確地識別，并制訂一個規(guī)范，以此作為出發(fā)點。在實施過程中要注重建立過程資產，比如反應不同風險承擔者對軟件產品質量所持觀點的提問單，描述與質量特征相關的一般性概念的骨架圖，已開發(fā)的用于獲取產品操作性和可用性規(guī)范的模板。在每次實施過程中我們也至少參與一個項目，對產品質量特征和設計目標規(guī)范進行實踐，以便為其他類似項目進行同一個實施過程時所借鑒。
  最近，在組織范圍內成立了產品質量支持小組，小組成員來自工作臺(商業(yè)部門)。他們在產品質量改進計劃中的任務如下：
  —在產品質量改進計劃(PQIP)中充當消費者咨詢委員會(CAB)的角色，為用戶提供咨詢
  —參與計劃/策略/過程的改進，并提出明確意見
  —對產品質量改進計劃(PQIP)的可交付產品進行檢查并提出反饋意見
  —在各自的Ops中扮演支持者的角色：
  —確定急需改進產品質量的侯選項目
  —在規(guī)范、設計、分析、測試、驗證期間，通過相應專家的參與，確保在項目中對產品質量的關注
  —促進產品質量技術的廣泛應用并在Ops中進行實踐
  與當前角色相對應的職責如下表所示：

  6. 結論
  產品質量改進計劃通過關注操作性、可用性、有效性、改進性等質量特征，促使組織開發(fā)出更好的產品。改進過程通過一系列額外的活動來滿足產品質量特征，使不同的風險承擔者(包括用戶、系統(tǒng)工程人員、系統(tǒng)專家和銷售人員、軟件工程人員、產品改進人員等等)在整個產品開發(fā)周期內關注產品質量。而且，本文所討論的產品質量改進活動和技術也有助于鞏固CMM模型的軟件質量管理關鍵過程域。
  組織應為實施產品質量改進計劃提供支持，它有助于提高用戶對產品和解決方案的滿意度，從而使得用戶繼續(xù)使用該產品成為可能。該計劃也涉及到少數(shù)的關鍵技術實踐(如設計分析)，從而增強MIEL的整體過程成熟度。
  7. 參考書目
  [1]"Attribute-based architecture development", Krishnan Rangarajan, Kashinath Kakarla, Deepti Arora, Proceedings APSES-98, pp 381-387.
  [2]"Architecture"Attributes"for"SMAP2000",http://libra.miel.mot.com/~3gtoolscm/ 3G_smap.html
  [3]"Software Metrics for Product Assessment", Richard Bache, Gualtiero Bazzana, Mcgraw-Hill Book Company, 1994.
  [4]"Scenario-Based Analysis of software Architecture", Kazman, R., Abowd, G., Bass, L., and Clements, P., IEEE Software, 13(6):47-56, 1996.
  [5] http://www.usability.serco.com
  [6]"Experiences with Architecture attribute analysis", Lakshmi and Suresh Kumar Chintada, submitted for APSES99.
  [7]"Looking beyond customer satisfaction", Jyoti, submitted for APSES99.
  [8]"Information Needs in analysis of Telecommunication software - a case study", Vesa Hirvisalo, Esko Nuutila.
  [9]"Problems in practice of performance engineering", Mark H. Klein, CMU/SEI-95-TR-020, ESC-TR-95-020, Feb 1996.
  [10]"Testing for Non-functional attributes", Santhosh C.K and Krishnan Rangarajan, submitted for APSES99.
  [11] http://5nines.mot.com/
  [12]"Usability analysis with SUMI method", Krishnan Rangarajan, Jacob Jacob, S.C Nirmala, P.Rajshekar Swamy, submitted for APSES99.