軟件開發(fā) 控制

1、第12章 控制退出 一般說來，所謂控制就是掌握被控制的對象，不讓它任意活動或超出規(guī)定范圍活動，盡量使一切活動都按照預定的計劃進行，向預期的目標前進。112.1 風險管理12.2 質量保證12.3 配置管理12.4 小結212.1 風險管理 軟件開發(fā)幾乎總會存在某些風險。對付風險應該采取主動的策略，也就是說，早在技術工作開始之前就應該啟動風險管理活動：標識出潛在的風險，評估它們出現(xiàn)的概率和影響，并且按重要性把風險排序，然后，軟件項目組制定一個計劃來管理風險。 風險管理的主要目標是預防風險，但是，并非所有風險都能預防，因此，項目組還必須制定一個處理意外事件的計劃，以便一旦風險變成現(xiàn)實時能夠以可控的

2、和有效的方式作出反應。3 12.1.1 軟件風險分類 風險有兩個顯著特點。 不確定性：標志風險的事件可能發(fā)生也可能不發(fā)生，也就是說，沒有100%發(fā)生的風險(100%發(fā)生的風險是施加在軟件項目上的約束)。 損失：如果風險變成了現(xiàn)實，就會造成不好的后果或損失。 1.按照風險的影響范圍分類 (1) 項目風險 (2) 技術風險 (3) 商業(yè)風險42.按照風險的可預測性分類(1) 已知風險(2) 可預測的風險(3) 不可預測的風險5 12.1.2 風險識別 通過識別已知的和可預測的風險，項目管理者就朝著在可能時避免風險并且在必要時控制風險的目標邁出了第一步。 在12.1.1節(jié)中描述的每一類風險又可進一步

3、分成兩種類型：一般性風險和特定產(chǎn)品的風險。一般性風險對每個軟件項目都是潛在的威脅。特定產(chǎn)品的風險只有那些對當前項目的技術、人員、及環(huán)境非常了解的人才能識別出來。為了識別出特定產(chǎn)品的風險，必須檢查項目計劃和軟件范圍說明，并且回答下述問題：“本項目有什么特殊的性質可能會威脅我們的項目計劃”。6 事實上，“如果你不主動地攻擊風險，風險將主動地攻擊你”。因此，應該系統(tǒng)化地識別出一般性風險和特定產(chǎn)品的風險。 采用建立風險條目檢查表的方法，人們可以集中精力識別下列已知的和可預測的風險。 產(chǎn)品規(guī)模與要開發(fā)或要修改的軟件總體規(guī)模相關的風險。 商業(yè)影響與管理或市場所施加的約束相關的風險。 客戶特性與客戶素質以及

4、開發(fā)者和客戶定期通信的能力相關的風險。7 過程定義與軟件過程已被定義的程度以及軟件開發(fā)組織遵守軟件過程的程度相關的風險。 開發(fā)環(huán)境與用來開發(fā)產(chǎn)品的工具的可用性和質量相關的風險。 所用技術與待開發(fā)系統(tǒng)的復雜性及系統(tǒng)所包含的技術的“新奇性”相關的風險。 人員數(shù)目與經(jīng)驗與參加工作的軟件工程師的總體技術水平及項目經(jīng)驗相關的風險。8 12.1.3 風險預測 風險預測(也稱為風險估算)試圖從兩個方面來評估每個風險：風險變成現(xiàn)實的可能性或概率，以及當風險變成現(xiàn)實時所造成的后果。 1. 評估風險后果 美國空軍建議從性能、支持、成本和進度等四個方面評估風險的后果，他們把上述四個方面稱為四個風險因素。下面給出這四

5、個風險因素的定義。 性能風險產(chǎn)品能滿足需求且符合其使用目的的不確定程度。 成本風險能夠維持項目預算的不確定程度。9 支持風險軟件易于改錯、適應和增強的不確定程度。 進度風險能夠實現(xiàn)項目進度計劃且產(chǎn)品能按時交付的不確定程度。 根據(jù)風險發(fā)生時對上述四個風險因素影響的嚴重程度，可以把風險后果劃分成四個等級：可忽略的、輕微的、嚴重的和災難性的。表121給出了由于軟件中潛伏的錯誤所造成的各種后果的特點(由表中標為“1”的行描述)，或由于沒有達到預期的結果所造成的各種后果的特點(由表中標為“2”的行描述)。按照實際后果與表中描述的特點的吻合程度，可以把風險后果劃分成四個等級中的某一個。10 2. 建立風險

6、表 建立風險表是一種簡單的風險預測技術，表12.2是風險表的一個例子。11 表中第4列給出的是風險后果的整體等級值，其中，1代表災難性的，2代表嚴重的，3代表輕微的，4代表可忽略的。 一旦填好了風險表前4列的內(nèi)容，就應該根據(jù)概率和影響來排序。高概率、高影響的風險放在表的上方，而低概率的風險放在表的下方，這樣就完成了第一次風險排序。 項目管理者研究排好序的風險表，并確定一條中止線。該中止線是經(jīng)過表中某一點的水平直線，它的含義是，只有位于線的上方的那些風險才會得到進一步的關注。對于處于線下方的風險要再次評估，以完成第二次排序。12 從管理的角度看，風險影響和風險概率的作用是不同的。對一個具有高影響

7、但發(fā)生概率很低的風險因素，不應該花費太多管理時間。但是，高影響且發(fā)生概率為中到高的風險，以及低影響且高概率的風險，應該進入風險管理的下一個步驟。 應該在軟件項目進展的過程中，迭代使用上述的風險預測與分析技術。項目組應該定期復查風險表，再次評估每個風險，以確定新情況是否引起它的概率和影響發(fā)生變化。作為這項活動的結果，可能在表中添加了一些新風險，刪除了某些與項目不再有關系的風險，并且改變了表中風險的相對位置。13 12.1.4 處理風險的策略 對于絕大多數(shù)軟件項目來說，上述的4個風險因素(性能、成本、支持和進度)都有一個臨界值，超過臨界值就會導致項目被迫終止。也就是說，如果性能下降、成本超支、支持

8、困難或進度延遲(或這4種因素的組合)超過了預先定義的限度，則因風險過大項目將被迫終止。 如果風險還沒有嚴重到迫使項目終止的程度，則項目組應該制定一個處理風險的策略。一個有效的策略應該包括下述三方面的內(nèi)容：風險避免(或緩解)；風險監(jiān)控；風險管理和意外事件計劃。14 1. 風險緩解 如果軟件項目組采用主動的策略來處理風險，則避免風險總是最好的策略。這可以通過建立風險緩解計劃來達到。 2. 風險監(jiān)控 隨著項目的進展，風險監(jiān)控活動也就開始了。項目管理者監(jiān)控某些能指出風險概率正在變高還是變低的因素。 3. 風險管理和意外事件計劃 風險管理和意外事件計劃假設緩解風險的努力失敗了，風險變成了現(xiàn)實。1512.

9、2 質量保證 質量是產(chǎn)品的生命，不論生產(chǎn)什么產(chǎn)品，質量都是極端重要的。軟件產(chǎn)品開發(fā)周期長，耗費巨大的人力和物力，更必須特別注意保證質量。 12.2.1 軟件質量 概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件符合明確地敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度。上述定義強調(diào)了下述的三個要點。16 軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。 指定的標準定義了一組指導軟件開發(fā)的準則，如果沒有遵守這些準則，幾乎肯定會導致質量不高。 通常，有一組沒有顯式描述的隱含需求(例如，期望軟件是容

10、易維護的)。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質量仍然是值得懷疑的。17 下面介紹影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量?？梢园堰@些質量因素劃分成三組，它們分別反映用戶在使用軟件產(chǎn)品時的三種不同傾向或觀點。這三種傾向是：產(chǎn)品運行，產(chǎn)品修改和產(chǎn)品轉移。圖12.1描繪了軟件質量因素和上述三種傾向(或稱為產(chǎn)品活動)之間的關系，表12.3給出了軟件質量因素的簡明定義。18圖12.1 軟件質量因素與產(chǎn)品活動的關系19 12.2.2 軟件質量保證措施 軟件質量保證(Software Quality Assurance，通?？s寫為SQA)的措施主要有，基于非執(zhí)

11、行的測試(也稱為復審)、基于執(zhí)行的測試(即本書第5章和第9章講述的測試)和程序正確性證明。 1. 技術復審的必要性 正式技術復審的明顯優(yōu)點是，能夠較早地發(fā)現(xiàn)錯誤，防止錯誤被傳播到軟件過程的后續(xù)階段。 正式技術復審實際上是一類復審方法，包括走查(Walkthrough)和審查(Inspection)等具體方法。走查的步驟比審查少，而且沒有審查那樣正規(guī)。20 2. 走查 (1) 參與者驅動法 參與者按照事先準備好的列表，提出他們不理解的術語和認為不正確的術語。文檔編寫組的代表必須對每個質疑做出回答，要么承認確實有錯誤，要么對質疑做出解釋。 (2) 文檔驅動法 文檔編寫者向走查組成員仔細解釋文檔。走

12、查組成員在此過程中不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質疑。這種方法可能比第一種方法更徹底，往往能檢測出更多錯誤。經(jīng)驗表明，采用文檔驅動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。21 3. 審查 審查的范圍要比走查廣泛得多，它的步驟也比較多。一般來說，審查有5個基本步驟。 綜述：由負責編寫文檔的一名成員向審查組成員綜述該文檔。在綜述會議結束時把文檔分發(fā)給每位與會者。 準備：評審員仔細閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作的進行。這些列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。22 審查：評審組仔細走查整個文檔。和走查一樣，這一步

13、的目的也是找出文檔中的錯誤，而不是改正它們。審查組組長必須在一天之內(nèi)寫出一份關于審查的報告。通常每次審查會不超過90分鐘。 返工：文檔的作者負責解決在書面報告中列出的所有錯誤及問題。 跟蹤：組長必須確保所提出的每個問題都得到了圓滿的解決(要么修正了文檔，要么澄清了被誤認為是錯誤的條目)。必須檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該召集審查組再對文檔全面地審查一遍。23 4. 程序正確性證明 正確性證明的基本思想是證明程序能完成預定的功能。因此，應該提供對程序功能的嚴格數(shù)學說明，然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。 如果在程序的若干個點

14、上，設計者可以提出關于程序變量及它們的關系的斷言，那么在每一點上的斷言都應該永遠是真的。假設在程序的P1，P2，Pn等點上的斷言分別是a(1)，a(2)，a(n)，其中a(1)必須是關于程序輸入的斷言，a(n)必須是關于程序輸出的斷言。24 為了證明在點Pi和Pi+1之間的程序語句是正確的，必須證明執(zhí)行這些語句之后將使斷言a(i)變成a(i+1)。如果對程序內(nèi)所有相鄰點都能完成上述證明過程，則證明了輸入斷言加上程序可以導出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。2512.3 配置管理 在開發(fā)計算機軟件的過程中，變化(或

15、稱為變動)是不可避免的。如果不能適當?shù)乜刂坪凸芾碜兓瑒荼卦斐苫靵y并產(chǎn)生許多嚴重的錯誤。 軟件配置管理是在計算機軟件整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來：標識變化；控制變化；確保適當?shù)貙崿F(xiàn)了變化；向需要知道這方面信息的人報告變化。26 軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。 軟件配置管理的目標是，使變化更容易被適應，并且在必須變化時減少所需花費的工作量。 27 12.3.1 軟件配置 1. 軟件配置項 軟件過程的輸出信息可以分為三類：計算機程序(源代碼和可執(zhí)

16、行程序)；描述計算機程序的文檔(供技術人員或用戶使用)；數(shù)據(jù)(程序內(nèi)包含的或在程序外的)。上述這些項組成了在軟件過程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。 可以把軟件配置管理看作是應用于整個軟件過程的軟件質量保證活動，是專門用于管理變化的軟件質量保證活動。28 2. 基線 基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為： 已經(jīng)通過了正式復審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎，并且只有通過正式的變化控制過程才能改變它。 簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速

17、而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應用特定的、正式的過程(稱為規(guī)程)來評估、實現(xiàn)和驗證每個變化。29 12.3.2 軟件配置管理過程 軟件配置管理是軟件質量保證的重要一環(huán)，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。 具體來說，軟件配置管理主要有五項任務：標識、版本控制、變化控制、配置審計和報告。30 1. 標識軟件配置中的對象 為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向對象方法組織它們?？梢詷俗R出兩類對象：基本對象和聚集對象(可以把聚集對象作為代表軟件配置完整版本的

18、一種機制)。 每個對象都有一組能惟一地標識它的特征：名字、描述、資源表和“實現(xiàn)”。其中，對象名是無二義性地標識該對象的一個字符串。31圖12.2 演化圖32 2. 版本控制 版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)這個目標的方法是，把屬性和軟件的每個版本關聯(lián)起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。 上面提到的“屬性”，既可以簡單到僅是賦給每個對象的特定版本號，也可以復雜到是一個布爾變量串(開關)，該布爾變量串指明了施加到系統(tǒng)上的功能變化的特定類型。33圖12.3 版

19、本和變體34 3. 變化控制 對于大型軟件開發(fā)項目來說，無控制的變化將迅速導致混亂。變化控制把人的規(guī)程和自動工具結合起來，以提供一個控制變化的機制。變化控制過程如圖12.4所示。35圖12.4 變化控制過程36圖12.5 訪問和同步控制37 4. 配置審計 為確保適當?shù)貙崿F(xiàn)了所需要的變化，我們從兩方面采用措施：正式的技術復審；軟件配置審計。 正式的技術復審(見12.2.2節(jié))關注被修改后的配置對象的技術正確性。復審者評估該配置對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。 軟件配置審計通過評估配置對象的那些通常不在復審過程中考慮的特征，而成為對正式技術復審的補充 5. 狀態(tài)報告 配置狀態(tài)報告是軟件配置管理的一項任務，它回答下述問題：發(fā)生了什么事?誰做的這件事?這件事是什么時候發(fā)生的?它將影響哪些其他事物?3812.4 小結 對于軟件開發(fā)項目來說，控制是十分重要的管理活動。本章主要講述了風險管理、質量保證和配置管理等三類軟件工程控制活動。 當對軟件項目寄予較高期望時，通常都會進行風險分析。在識別、預測、評估、監(jiān)控和管理風險等方