軟件評測師筆記_軟件質量管理基礎20161022

軟件質量管理

軟件是邏輯產品，其質量屬性有不一樣的特色。軟件質量保證（SQA）活動是確保軟件產品在軟件生存期全部階段的質量的活動，即爲了肯定、達到和維護須要的軟件質量而進行的全部有計劃、有系統的管理活動。

 

歸納地說，軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。具體地說，軟件質量是軟件與明確敘述的功能和性能需求、文檔中明確描述的開發標準，以及任何專業開發的軟件產品都應該具備的隱含特徵相一致的程度。

軟件質量具備如下3個要點。

（1）用戶需求是衡量軟件質量的基礎，與需求不一致就無質量可言。

（2）指定的開發標準定義了一組指導軟件開發的準則。若是沒有遵照這些準則，確定會致使軟件質量不高。

（3）一般還有一些沒有明確寫進用戶需求說明書但開發人員都應當瞭解的隱含需求（例如易理解性、易修改性等）。若是軟件僅知足明確描述的需求，但不知足這些隱含的需求，那麼軟件的質量仍然是值得懷疑的。

計算機軟件是一種複雜、抽象的邏輯實體，它所固有的一些特色包括抽象性、複雜性、多樣性、易變性、軟件開發需求難於把握等。全部這些軟件獨具的特色都增長了軟件開發的困難。

影響軟件質量的因素主要包括：

（1）人的因素。

（2）軟件需求。

（3）質量問題可能出如今開發過程的各個環節上。

（4）測試的侷限性。

（5）質量管理的困難。

（6）質量管理未能給予足夠的重視。

（7）軟件人員的傳統習慣。

（8）開發規範。

（9）開發工具的支持不夠。

軟件質量可用多種軟件質量模型來描述。《GB/T 16260.1—2003信息技術 軟件工程 產品質量 第1部分：質量模型》分別給出了軟件內部質量（Software Internal Quality）、軟件外部質量（Software External Quality）和軟件使用質量（Software Quality in Use）的概念和模型，質量模型由3個層次組成：質量特性（Quality Characteristics）、質量子特性（Quality Subcharacteristics）和度量（Metrics）。

 

1．質量需求分析

質量需求分析就是肯定與軟件項目相關的質量目標和標準。根據項目需求肯定質量目標、標準、級別和評判標準，並將其做爲檢驗質量成果的基礎。在肯定質量需求時，特別在資源有限的環境中，要考慮到質量目標的優先級，以及品質、性能、費用和時間等影響客戶滿意度的要素間的平衡。

2．質量計劃

質量計劃就是爲肯定如何知足質量需求分析中制訂的質量目標和標準，以及要採起哪些必要行動。質量計劃包括質量控制、質量保證、持續改進措施等過程，以及在這些過程當中所要採起的溝通、受權、明確職責、編制質量管理文件、質量檢查、審計、報告和審查等管理活動。

軟件質量計劃的詳細內容和書寫格式請看「10.3.4 計算機軟件質量保證計劃規範」。

3．質量保證

質量保證是保證質量計劃得以系統地實施的所有活動，包括按期評價整體項目執行狀況，以提供項目知足質量標準的信心。質量保證經過質量管理系統實現。創建和維護質量管理系統以保證有效的溝通和輸出實施質量管理計劃的結果。

軟件質量保證是爲保證軟件系統充分知足用戶要求的質量而進行的有計劃、有組織的活動，其目的是生產高質量的軟件。

軟件質量保證的主要困難表如今如下方面：

（1）軟件開發的管理人員每每更關心項目開發的成本與進度。由於成本和進度是顯而易見的，而軟件質量則難以度量。

（2）若是軟件開發的管理人員對於交付的軟件含有多少隱患並沒必要負什麼責任，他們一定沒有過高的熱情去控制開發的質量，更沒必要說保證質量並不容易且代價昂貴。

（3）開發人員的習慣一旦造成便難以改變，他們的行爲也難於控制。而高質量的軟件產品，又主要取決於參與開發的人員。

（4）複雜的軟件項目須要許多技術人員和管理人員參與，對問題的不一樣認識和誤解如不能及時消除必然影響軟件質量。

（5）軟件開發人員的頻繁流動，特別是骨幹開發人員的流失，也會使軟件質量受到必定影響。

軟件質量保證的主要手段：

（1）開發初期制定質量保證計劃，並在開發中堅持實行。

（2）開發前選定或制定開發標準或開發規範，並遵守實施。

（3）從選擇分析設計方法和工具，造成高質量的分析模型和設計模型。

（4）嚴格執行階段評審，以便及時發現問題。

（5）各個開發階段的測試。

（6）對軟件的每次「變更」都要通過申請、評估、批准、實施、驗證等步驟。

（7）軟件質量特性的度量化。

（8）軟件生存期的各階段都要有完整的文檔。

4．質量控制

質量控制活動具體監控軟件項目的進程和結果，以肯定其是否符合相關的質量標準；分析產生質量問題的緣由，並制訂相應措施來消除致使不符合質量標準的因素，確保項目質量得以持續不斷地改進。質量控制活動包括經過由內部或外部機構進行的監測管理，發現與質量標準的差別，消除成果或過程當中不能知足質量要求的因素；還要審查質量標準，以肯定可能達到的質量目標及爲此須要支付的質量成本，並評價其費用效率，必要時能夠修訂質量標準或項目目標。

5．質量改進

質量改進活動一般經過持續不斷的糾正措施，並提出必要的變動申請，經過總體變動控制系統程序來實現。

 

軟件能力成熟度模型：

CMM把軟件開發過程的成熟度由低到高分爲5級，即初始級、可重複級、已定義級、已管理級和優化級。隨着CMM等級的提升，它逐步下降了軟件開發風險，縮短了開發時間，下降了軟件開發的人力物力成本，下降了災難性的錯誤發生率，提升了軟件質量。CMM評估等級的提高會大幅度提升軟件開發能力，有助於客戶特別是大公司對該軟件企業創建信心，並向該軟件企業下訂單採購軟件產品。

CMM的每一個等級由不一樣的關鍵過程域（Key Practivice Area，KPA）組成，每一個關鍵過程域包括一系列的關鍵實踐（Key Practivice，KP）。關鍵過程域是指互相關聯的若干軟件實踐活動和有關基礎設施的一個集合。關鍵實踐則是指對關鍵過程域的實踐起關鍵做用的方針、規程、措施、活動，以及相關基礎設施的創建。CMM1.1中的5個等級共有關鍵過程域18個，18個關鍵過程域中包含KP共316項。CMM1.1的5個等級和18個關鍵過程域如表6-8所示。

表6-8 CMM1.1的5個等級和18個關鍵過程域

 

CMM做爲評估軟件過程成熟度的依據，爲軟件過程評估和軟件能力成熟度評估創建了一個共同的參考框架。

 

軟件過程改進非一日之功，急於求成必將致使失敗。盲目進行過程改進，只會浪費時間和資金而不會取得好的效果。若是咱們把軟件過程改進看作一個項目，像其餘項目同樣，它也要有一個好的規劃，這個規劃不但要知足公司的商業目標，還要包含過程改進戰略和具體的實施步驟。

一般，軟件過程改進可按如下步驟進行。

1．比較「目標狀態」與「目前狀態」，找出全部差距

（1）目標狀態：若是一個機構決定採用CMM做爲參考藍本的話，就能夠基於它的各個關鍵過程域（KPA），制定出符合本身機構及產品特色的目標狀態。

（2）目前狀態：要找出什麼是目前的狀態，就要進行對目前軟件過程的評估。評估的方法不少，最簡單的就是一組熟悉本機構的平常開發運做的人員在一塊兒討論，把它列出來。在這裏，可藉助CMM的評估問卷辦法。實質上，評估問卷中的問題，就是由各關鍵過程域的各細則內容，加上「有沒有作到」、「有沒有創建」、「有沒有執行」等語句而構成的，並無什麼神祕之處。

2．肯定改進目標

找出全部差距以後，首先篩選出若干個改進點，並把每一個改進點都看作一個改進項目。對於每一個改進項目，可從該項目對公司商業目標的影響、風險程度、對公司達到更高CMM等級的貢獻、投入產出比等方面進行分析評價。而後根據公司具體狀況，肯定上述幾方面因素所佔的不一樣權重，計算每一個改進項目的總分，並按照分值對各個改進項目進行排序。排序完成後，根據各個改進項目的優先級順序和依賴關係肯定整體改進目標與階段改進目標。

3．制定改進計劃

軟件過程改進計劃一般要求以下。

（1）要有明確的、能夠檢驗的目標。

（2）要定出檢驗成功與否的標準。

（3）要有具體的實施行動辦法。

（4）要指定具體執行計劃的人，以及每人的具體責任與任務；。

（5）要指明計劃的主要領導或協調者，以負責解決一切在執行中出現的問題。

（6）要列出所採用的新技術與新工具，以及怎樣得到它們。

（7）要定出對新技術和新工具進行對本機構適用性改造的目標。

（8）要有對新技術和新工具的使用進行培訓的計劃。

（9）要列出每一改進對過程的其餘部分的關係、影響和協調的辦法。

（10）要創建與項目相關聯的時間表。

（11）要指出相關的人力、資金與時間的來源。

（12）要定出在整個執行過程當中，必須在何時提供什麼數據。

（13）要有對執行狀況進行監察考覈的具體辦法及計劃。

（14）要準備極可能發生的、在執行過程當中對行動計劃按狀況進行調整的行動。

（15）要對行動計劃執行中可能出現的意外狀況有所準備，保證項目仍然可以順利進行。

（16）必需要有高層領導、管理人員做爲推進整個行動計劃的動力。

4．執行改進計劃

在執行過程當中，一旦發現須要對改進計劃進行調整，以期達到最佳的效果，而實際狀況也容許在中途進行調整的話，能夠進行通過計劃的、嚴加控制的調整。全部的改變必須預先取得全部有關人員的贊成。

5．總結本輪改進經驗，開始下一輪改進

軟件過程的不斷改進是軟件工程的基本原理之一，認真總結本輪改進的經驗和教訓能使咱們在下一輪改進中作得更加出色。

軟件過程改進中，最重要的一點是要注重執行、作實事，千萬不要制定出了改進計劃以後就丟進抽屜中，束之高閣。另一個要注意的問題是，要有對改進計劃執行中可能出現的意外狀況有所準備，保證項目仍然可以順利進行。

 

能力成熟度模型集成

與CMM相比，（能力成熟度模型集成，CMMI）涉及面更廣，專業領域覆蓋軟件工程、系統工程、集成產品開發和系統採購。據美國國防部資料顯示，運用CMMI模型管理的項目，不只下降了項目的成本，並且提升了項目的質量與定期完成率。

CMMI能夠看作把各類CMM集成到一個系列的模型中了，CMMI的基礎源模型包括軟件CMM、系統工程CMM，以及集成化產品和過程開發CMM等。CMMI也描述了5個不一樣的成熟度級別。

每一種CMMI模型都有兩種表示法，即階段式和連續式。這是由於在CMMI的三個源模型中，CMM是「階段式」模型，系統工程能力模型是「連續式」模型，而集成產品開發（IPD）CMM是一個混合模型，組合了階段式和連續式二者的特色。兩種表示法在之前的使用中各有優點，都有不少支持者，所以，CMMI產品開發羣組在集成這三種模型時，爲了不因爲淘汰其中任何一種表示法而失去用戶對CMMI的支持，並無選擇單一的結構表示法，而是爲每個CMMI都推出了兩種不一樣表示法的版本。

不一樣表示法的模型具備不一樣的結構。連續式表示法強調的是單個過程域的能力，從過程域的角度考查基線和度量結果的改善，其關鍵術語是「能力」；而階段式表示法強調的是組織的成熟度，從過程域集合的角度考查整個組織的過程成熟度階段，其關鍵術語是「成熟度」。

儘管兩種表示法的模型在結構上有所不一樣，但CMMI產品開發羣組仍然盡最大努力確保了二者在邏輯上的一致性，二者的須要構件和指望部件基本上都是同樣的。過程域、目標在兩種表示法中都同樣，特定實踐和共性實踐在兩種表示法中也不存在根本區別。所以，模型的兩種表示法並不存在本質上的不一樣。組織在進行集成化過程改進時，能夠從實用角度出發選擇某一種偏心的表示法，而沒必要從哲學角度考慮兩種表示法之間的差別。

階段式模型也把組織分爲如下5個不一樣的級別。

（1）初始級：表明了以不可預測結果爲特徵的過程成熟度，過程處於無序狀態，成功主要取決於團隊的技能。

（2）已管理級：表明了以可重複項目執行爲特徵的過程成熟度。組織使用基本紀律進行需求管理、項目計劃、項目監督和控制、供應商協議管理、產品和過程質量保證、配置管理，以及度量和分析。對於級別2而言，主要的過程焦點在於項目級的活動和實踐。

（3）嚴格定義級：表明了以組織內改進項目執行爲特徵的過程成熟度。強調級別3的關鍵過程域的先後一致的、項目級的紀律，以創建組織級的活動和實踐。

（4）定量管理級：表明了以改進組織性能爲特徵的過程成熟度。4級項目的歷史結果可用來交替使用，在業務表現的競爭尺度（成本、質量、時間）方面的結果是可預測的。

（5）優化級：表明了以可快速進行從新配置的組織性能和定量的、持續的過程改進爲特徵的過程成熟度。

CMMI的具體目標是：

（1）改進組織的過程，提升對產品開發和維護的管理能力。

（2）給出能支持未來集成其餘科目CMM的公共框架。

（3）確保所開發的所有有關產品符合將要發佈的關於軟件過程改進的國際標準ISO/IEC15504對軟件過程評估的要求。

使用在CMMI框架內開發的模型具備下列優勢：

（1）過程改進能擴展到整個企業級。

（2）先前各模型之間的不一致和矛盾將獲得解決。

（3）既有分級的模型表示，也有連續的模型表示，可任意選用。

（4）原先單科目過程改進的工做可與其餘科目的過程改進工做結合起來。

（5）基於CMMI的評估將與組織原先評估得分相協調，從而保護當前的投資，並與ISO/IEC15504評估結果相一致。

（6）節省費用，特別是當要運用多科目改進時，以及進行相關的培訓和評估時。

（7）鼓勵組織內各科目之間進行溝通和交流。

 

1．軟件配置與軟件配置項

軟件配置（Software Configuration）是指一個軟件產品在軟件生存週期各個階段所產生的各類形式（機器可讀或人工可讀）和各類版本的文檔、程序及其數據的集合。該集合中的每個元素稱爲該軟件產品軟件配置中的一個配置項（Configuration Item）。

隨着軟件開發過程的深刻，軟件配置項的數量迅速增長，軟件配置項的內容也隨時可能發生變化。爲了開發出高質量的軟件產品，軟件開發人員不只要確保每個軟件配置項都正確，並且必須保證一個軟件的全部配置項是徹底一致的。

2．基線

基線（Baseline）是指已經過正式複審的軟件中間產品或軟件文檔，它能夠做爲進一步開發的基礎，而且只有經過正式的變化控制過程才能改變它。簡而言之，基線就是指已經過正式複審的軟件配置項。

基線有助於咱們在不嚴重妨礙合理變化的前提下控制變化。在軟件配置項變成基線以前，能夠迅速而非正式地修改它。一旦創建了基線以後，雖然仍然能夠實現變化，但必須應用特定的、正式的過程（稱爲規程）來評估、實現和驗證每一個變化。

爲防止不一樣版本的軟件工具所產生的結果不一樣，許多軟件工程組織將軟件工具，如特定版本的編輯器、編譯器和其餘CASE工具，也做爲軟件配置的一部分「固定」下來，也就是「軟件工具基線化」。

最經常使用的基線包括如下3種。

1）功能基線

功能基線是指在系統分析與軟件定義階段結束時，通過正式評審和批准的系統設計規格說明書中對待開發系統的規格說明；或是指通過項目委託單位和項目承辦單位雙方簽字贊成的協議書或合同中所規定的對待開發軟件系統的規格說明；或是由下級申請經上級贊成或直接由上級下達的項目任務書中所規定的對待開發軟件系統的規格說明。功能基線是最初批准的功能配置標識。

2）指派基線

指派基線是指在軟件需求分析階段結束時，通過正式評審和批准的軟件需求的規格說明。指派基線是最初批准的指派配置標識。

3）產品基線

產品基線是指在軟件組裝與系統測試階段結束時，通過正式評審的批准的有關所開發的軟件產品的所有配置項的規格說明。產品基線是最初批准的產品配置標識。

 

軟件配置管理活動主要包括5項任務：對象標識、版本控制、變化控制、配置審計和配置報告。

1．對象標識

爲了控制和管理軟件配置項，必須單獨爲每一個配置項命名，而後用面向對象方法組織它們。能夠標識出兩類對象：基本對象和彙集對象。基本對象是軟件開發人員在分析、設計、編碼或測試過程當中建立出來的「文本單元」，例如，需求規格說明的一個段落、一個模塊的源程序清單或一組測試用例。彙集對象是基本對象和其餘彙集對象的集合。能夠把彙集對象做爲表明軟件配置完整版本的一種機制。

每一個對象都有一個能惟一地標識該對象的「對象名」，以及有關的「描述」、「資源表」和「實現」。其中，對象名是無二義性地標識該對象的一個字符串。

在設計標識軟件對象的方式時，必須認識到對象在整個生命週期中一直都在演化，所以，所設計的標識方式必須能無歧義地標識每一個對象的不一樣版本。

2．版本控制

版本控制是指聯合使用規程和工具，以管理在軟件工程過程當中所建立的配置對象的不一樣版本。藉助於版本控制技術，用戶可以經過選擇適當的版原本指定軟件系統的配置。實現這個目標的方法是，把屬性和軟件的每一個版本關聯起來，而後經過描述一組所指望的屬性來指定和構造所須要的配置。

3．變化控制

對於大型軟件開發項目來講，無控制的變化將迅速致使混亂。變化控制把人的規程和自動工具結合起來，以提供一個控制變化的機制。典型的變化控制過程以下。

（1）變化評估——接到變化請求以後，應首先評估該變化在技術方面的得失、可能產生的反作用、對其餘配置對象和系統功能的總體影響，估算其修改爲本，並根據評估結果造成「變化評估報告」，提交變化控制審批者審閱。

（2）變化審批——變化控制審批者對變化的狀態和優先級作最終決策，爲每一個被批准的變化下達一個「工程變化命令」，描述將要實現的變化、必須遵照的約束，以及複審和審計的標準。

（3）變化執行——把要修改的對象從項目數據庫中「提取」（check out）出來，進行修改並通過適當的評審或測試活動，而後將修改後的對象「提交」（chech in）進數據庫，最後用適當的版本控制機制建立該軟件的下一個版本。

「提取」和「提交」過程實現了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定誰有權訪問和修改一個特定的配置對象，同步控制有助於保證由多人完成的並行修改不會相互覆蓋。

4．配置審計

配置審計做爲對正式技術複審的補充，主要審計配置對象的那些一般不在技術複審中考慮的特徵，好比：修改時是否遵循了軟件工程標準？是否在該配置中顯著地標明瞭所作的修改？是否註明了修改日期和修改者？是否適當地更新了全部相關的軟件配置項？是否遵循了標註變化、記錄變化和報告變化的規程？

5．配置報告

配置狀態變化對大型軟件開發項目的成功有重大影響。當大量人員在一塊兒工做時，可能一我的並不知道另外一我的在作什麼。軟件配置變化報告用於增強相關人員的通訊與協調，它主要包括如下內容：發生了什麼事（What）；誰作的這件事（Who）；什麼時間作的（When）；它將影響哪些其餘事物（What Other）。

 

風險管理已成爲軟件工程項目管理的一項重要內容，其主要活動包括風險識別、風險分析（風險估算與評價）、風險應對（風險防範）和風險控制等。

 

1．風險識別

首先要識別風險來源，由此可預測風險事件的發生並識別風險症狀。在立項、人員、計劃、質量、成本、進度、合同、安全、技術、外包外購、溝通協調等各管理要素中都對應着可能的風險條件，能夠用不一樣的方法對風險進行分類。從宏觀上來看，風險能夠分爲項目風險、技術風險和商業風險。項目風險包括潛在的預算、進度、我的、資源、用戶和需求方面的問題，技術風險包括潛在的設計、實現、接口、檢驗和維護方面的問題，而商業風險則主要來源於市場。

風險識別的重要工做就是將潛在的風險找到，並在文檔中體現出來。

 

2．風險估計（風險估算與評價）

風險分析就是估算與評價風險的過程，其目標是幫助項目管理人員決定在具體的風險面前採起什麼態度：應對，接受，仍是忽略。

應從兩方面來分析每一種風險：一是分析其發生的可能性；二是分析其可能帶來的破壞性。要儘可能採用量化辦法進行風險分析。經過量化分析，按照可能性和破壞力進行風險排序。對於那種可能性大、破壞力也大的風險就應該更加劇視。

 

3．風險應對（風險防範）

風險應對包括肯定風險策略和制定風險應對計劃。

風險策略是指應對某一種具體風險的策略，如規避（轉移）風險、減輕風險或接受風險等。可利用某種技術，如原型化、軟件自動化、軟件心理學、可靠性工程學，以及某些項目管理方法等設法規避或減輕風險。

風險應對計劃主要包括風險管理計劃和應急計劃等。

 

4．風險控制

風險控制活動主要包括如下任務：隨時追蹤風險已經、正在和將要發生的變化；預測和判斷風險的應對是否會引發更新的風險發生；對用於風險管理的資源配置進行調整；調整風險應對計劃；採起臨時緊急應變措施等。