模板
教程
環境
性能
功能
管理
軟件產品質量改進框架（三）
發表于：2008-01-24來源：作者：點擊數：
標簽：質量改進框架
3.5 質量特征計劃 為幫助設計者們進行設計，我們準備編寫一本設計指南的書，內容包括設計中的一些有代表性的類型、模式和技術。 類型是最簡單的基本結構，通常被用來定義體系結構。常見的類型的例子包括客戶- 服務器 結構，管道與過濾結構，分層結構等等。在
3.5 質量特征計劃
為幫助設計者們進行設計，我們準備編寫一本設計指南的書，內容包括設計中的一些有代表性的類型、模式和技術。
類型是最簡單的基本結構，通常被用來定義體系結構。常見的類型的例子包括客戶-服務器結構，管道與過濾結構，分層結構等等。在早期的結構選擇上，按照組織體系進行選擇是一種有代表性的類型。
模式是一種能夠重復使用的微觀結構。它通常根據其產生、結構、行為的特征進行分類。例如適配器就是一個協調型的模式。
設計技術是其它有益于設計的相關信息，它能避免一個低水平的設計。例如，數據編碼的使用，用于安全性的密碼保護，為使操作簡便而使用應用程序接口方法(API)，等等。
在體系結構/設計中選擇合適的類型、模式和技術，對能否實現設計目標具有很大的關系。例如，一個分層體系結構將有助于實現易更改性，但是降低了操作性能。設計指南一書將作為這種設計知識的倉庫而為設計者提供服務。
在結構和設計階段可以參考設計指南。我們設想設計指南具有一個簡單的使用界面并發布在互聯網絡上，使設計者們能通過特殊的搜索工具根據其期望特征選擇相關的類型、模式和技術，從而建立一個關注質量特征的體系結構。設計指南將為設計者們提供詳細的入口信息，使他們能根據這些入口的適用性作出正確的選擇。
3.6 過程改進
在項目開發的生命周期行為中，應該盡量使用上面提及的那些新技術。通過這些新技術，可以增強現有過程能力和過程資產(模版、指導方針、檢驗方法)，實現產品質量焦點一體化。
項目開發的生命周期主要包括幾個階段(或如下圖所示)：
—在需求階段明確地列出所有需要關注的特征，
—在產品設計期間關注各項特征，
—從產品質量角度出發對可交付產品進行檢驗，
—確定測試案例并進行測試，檢查并核實特征是否滿足。
對指定的特征進行測量、跟蹤和分析。
例如，需要改進的過程資產用步驟序列的形式表示如下：
—暫時不考慮計劃
—需求手冊模板
—設計(HLD,LLD)模板
—預演指導方針
—檢驗指導方針
—帳目檢查表
—測試計劃文檔/測試案例文檔
—發布檢查表
—用戶滿意度調查程序及其提問單
來自發展組織內部的軟件質量工程師、過程工程師以及軟件質量改進的支持者們都致力于改進過程的創新工作，他們在總結以往經驗的基礎上為改進過程設立了基線。當OPG(組織過程組)提出一個POR(過程時機報告)時，意味著開始進行過程改進。一旦對所有過程都實施了改進，我們將計劃召開Educom(教育/交流)會議來對組織內部進行溝通。
3.7 評價標準
產品質量的評價標準可以被分為兩大類，即：內在的評價標準和外在的評價標準。內在的評價標準與產品自身相關，而外在的評價標準與開發者為滿足產品目標所付出的努力相關。下表列出了部分與產品自身相關的內在評價標準：
為幫助設計者們進行設計，我們準備編寫一本設計指南的書，內容包括設計中的一些有代表性的類型、模式和技術。
類型是最簡單的基本結構，通常被用來定義體系結構。常見的類型的例子包括客戶-服務器結構，管道與過濾結構，分層結構等等。在早期的結構選擇上，按照組織體系進行選擇是一種有代表性的類型。
模式是一種能夠重復使用的微觀結構。它通常根據其產生、結構、行為的特征進行分類。例如適配器就是一個協調型的模式。
設計技術是其它有益于設計的相關信息，它能避免一個低水平的設計。例如，數據編碼的使用，用于安全性的密碼保護，為使操作簡便而使用應用程序接口方法(API)，等等。
在體系結構/設計中選擇合適的類型、模式和技術，對能否實現設計目標具有很大的關系。例如，一個分層體系結構將有助于實現易更改性，但是降低了操作性能。設計指南一書將作為這種設計知識的倉庫而為設計者提供服務。
在結構和設計階段可以參考設計指南。我們設想設計指南具有一個簡單的使用界面并發布在互聯網絡上，使設計者們能通過特殊的搜索工具根據其期望特征選擇相關的類型、模式和技術，從而建立一個關注質量特征的體系結構。設計指南將為設計者們提供詳細的入口信息，使他們能根據這些入口的適用性作出正確的選擇。
3.6 過程改進
在項目開發的生命周期行為中，應該盡量使用上面提及的那些新技術。通過這些新技術，可以增強現有過程能力和過程資產(模版、指導方針、檢驗方法)，實現產品質量焦點一體化。
項目開發的生命周期主要包括幾個階段(或如下圖所示)：
—在需求階段明確地列出所有需要關注的特征，
—在產品設計期間關注各項特征，
—從產品質量角度出發對可交付產品進行檢驗，
—確定測試案例并進行測試，檢查并核實特征是否滿足。
對指定的特征進行測量、跟蹤和分析。
例如，需要改進的過程資產用步驟序列的形式表示如下：
—暫時不考慮計劃
—需求手冊模板
—設計(HLD,LLD)模板
—預演指導方針
—檢驗指導方針
—帳目檢查表
—測試計劃文檔/測試案例文檔
—發布檢查表
—用戶滿意度調查程序及其提問單
來自發展組織內部的軟件質量工程師、過程工程師以及軟件質量改進的支持者們都致力于改進過程的創新工作，他們在總結以往經驗的基礎上為改進過程設立了基線。當OPG(組織過程組)提出一個POR(過程時機報告)時，意味著開始進行過程改進。一旦對所有過程都實施了改進，我們將計劃召開Educom(教育/交流)會議來對組織內部進行溝通。
3.7 評價標準
產品質量的評價標準可以被分為兩大類，即：內在的評價標準和外在的評價標準。內在的評價標準與產品自身相關，而外在的評價標準與開發者為滿足產品目標所付出的努力相關。下表列出了部分與產品自身相關的內在評價標準：
| 產品形式 | 內在的評價標準 |
| 設計 | 耦合，內聚，輸入，輸出，…… |
| 代碼 | 循環的復雜程度，嵌套深度，易測量的標準，…… |
| 文檔 | 索引的可讀性，…… |
如果內在的評價標準之間存在各種關聯，那么采用該標準并不能明確地區分各個特征目標。因此，在通常情況下，我們建議采用外在的評價標準對產品質量特征進行評價。
3.7.1 改進性
任何一個改進性規范的目的都將為適應變化所需付出的努力程度分為低/中/高三類。在下表中，對低/中/高三種努力程度的含義給出了一種可能的解釋。該表相對于某個特定項目是十分準確的。
| 低 | – 不需作任何改變 – 對數據文件進行輕微地修改 – 重新鏈接，重新啟動 – 重新編譯，重新鏈接，重新啟動 |
| 中 | 原程序需要修改. 但不需要對設計進行改動 |
| 高 | 設計或體系結構需要修改 |
在體系結構或設計階段的最后，可以分析得出產品質量的外在的評價標準，如下所示：
1）已滿足改進目標的百分比
2）不能滿足的改進目標個數(低努力程度)
3）不能滿足的改進目標個數(中努力程度)
4）不能滿足的改進目標個數(高努力程度)
可以采用SAAM方法[4]對體系結構或設計進行分析，以獲得上面這些評價標準。
3.7.2 操作性
下面的評價標準可以用來跟蹤操作性目標。
1）實現的操作性目標的百分比：在設計階段，依照操作性規范對項目的每一個入口的設計都進行分析。在測試階段，通過測試案例來驗證產品是否達到操作性規范的要求。
實現的操作性目標的百分比 = （已實現的操作性目標的個數/操作性規范中要實現的目標的總個數）*100%
2）在設計/測試階段結束后，可以通過圖表來反應操作性規范中每個目標計劃值與實際值之間的差異。
例如：屏幕刷新率 1—5秒
1sec 5sec
1sec 5sec
3.7.3 可用性
接下來講述的評價標準是與產品的可用性相關的，在SUMI方法中，對初始階段的任何原型的改進或在完成之后對產品的評價都需要使用可用性評價標準。該標準使用一些0—70范圍內的數值進行評價。
1）綜合
該評價標準反應用戶對于可用性的理解的綜合觀點
2）效率
該評價標準反應用戶對于該軟件能否通過一種有效的方式來完成工作任務的看法。
3）影響
該評價標準反應軟件對用戶產生的心理影響。即用戶使用該軟件而產生的精神壓力和身體壓力。
4）作用
該評價標準反應用戶對軟件能產生的作用大小的認可程度。
5）控制
該評價標準反應用戶在使用軟件的過程中的舒適程度。如果用戶可以比較容易的使用軟件實現他所希望實現的目標，那么該軟件具有良好的控制性。
6）容易掌握
該評價標準反應用戶是否能夠輕松地掌握軟件的使用方法并開始使用。
3.7.4 有效性
該評價標準與the five 9的系統有效性小組所提出的標準相同。
1）nines的個數
2）無效性原因的排列圖
4. 基本的指導
SMAP2000小組在需求分析階段就指定產品的質量特征作為設計的目標。他們把產品的操作性、可用性、可改進性作為產品的重要特征。項目小組在這些活動上大約花費了17個工作日(估計值)，但可以使項目從以下幾個方面受益。
1）改善了圖形用戶界面設計，并增加了有用的設計觀點。
2）有助于從用戶那里獲取他們對軟件的操作性能期望并在可解決的范圍內識別約束條件(例如帶寬)。
3）通過改進的觀點幫助項目小組對當前產品的試用版本進行思考，幫助他們獲得改進的最新理解。它使產品的結構觀發生了轉變，從“能適應當前SMAP-2G的執行”轉變為“一個應用程序的網絡管理平臺”。
4）特征規范可以應用于綜合集成和現場實驗，還可以用來解釋工具的操作行為。
5）它能滿足過程改進體系結構的需要。
6）對這些特征的研究使設計人員能更好地理解部分的功能需求。
特征規范文檔可以在http://libra.miel.mot.com/~3gtoolscm/ 3G_smap.html獲得。
當前，正在對項目設計進行操作性分析，計劃采用SAAM方法針對改進性進行設計分析。
在MIEL中的其它產品計劃(如SinglecellWiLL，VOIP)也已經開始采用這種方法進行分析。
5. 實施步驟
我們可以對產品質量特征或設計目標進行明確地識別，并制訂一個規范，以此作為出發點。在實施過程中要注重建立過程資產，比如反應不同風險承擔者對軟件產品質量所持觀點的提問單，描述與質量特征相關的一般性概念的骨架圖，已開發的用于獲取產品操作性和可用性規范的模板。在每次實施過程中我們也至少參與一個項目，對產品質量特征和設計目標規范進行實踐，以便為其他類似項目進行同一個實施過程時所借鑒。
最近，在組織范圍內成立了產品質量支持小組，小組成員來自工作臺(商業部門)。他們在產品質量改進計劃中的任務如下：
—在產品質量改進計劃(PQIP)中充當消費者咨詢委員會(CAB)的角色，為用戶提供咨詢
—參與計劃/策略/過程的改進，并提出明確意見
—對產品質量改進計劃(PQIP)的可交付產品進行檢查并提出反饋意見
—在各自的Ops中扮演支持者的角色：
—確定急需改進產品質量的侯選項目
—在規范、設計、分析、測試、驗證期間，通過相應專家的參與，確保在項目中對產品質量的關注
—促進產品質量技術的廣泛應用并在Ops中進行實踐
與當前角色相對應的職責如下表所示：
| 角色 |
職責 |
| SSTE(系統軟件測試工程師) | —在測試過程中關注產品質量。根據產品質量選擇測試案例。 —證明或確保發布的產品滿足產品質量要求(測試小組在組織范圍內能獨立開展工作) |
| 質量員 | —選擇評價標準 —在改進期間，對相關活動進行審計以保證過程符合產品質量的要求 |
| 系統技術員 | —對可用性、操作性、改進性、有效性等質量特征的分析技術和規范進行歸納—制定實現質量特征的方法和指導方針 |
| Ops 經理 | —制定生產線流程圖 |
| 過程主管 |
—積極地參與實現指定的產品質量特征和目標—設置可重用目標—確?？芍赜媚繕艘呀泴崿F—制定生產線計劃 |
| 項目經理 | —為產品質量制定計劃—按照特定的規范和分析行為制定有助于提高產品質量的項目計劃—在產品開發過程中定期向上級提交產品質量報告 |
| 技術總監 | —在需求分析階段制定產品質量的特征規范—詳細設計產品質量特征 |
| 改進工程師 | —在改進過程中保證產品質量特征的實現 |
| 系統專家和銷售人員 | —在需求階段，制訂產品的改進方案和商業計劃 |
6. 結論
產品質量改進計劃通過關注操作性、可用性、有效性、改進性等質量特征，促使組織開發出更好的產品。改進過程通過一系列額外的活動來滿足產品質量特征，使不同的風險承擔者(包括用戶、系統工程人員、系統專家和銷售人員、軟件工程人員、產品改進人員等等)在整個產品開發周期內關注產品質量。而且，本文所討論的產品質量改進活動和技術也有助于鞏固CMM模型的軟件質量管理關鍵過程域。
組織應為實施產品質量改進計劃提供支持，它有助于提高用戶對產品和解決方案的滿意度，從而使得用戶繼續使用該產品成為可能。該計劃也涉及到少數的關鍵技術實踐(如設計分析)，從而增強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.
