搜索
1第11章變更管理2本章大綱•11.1變更管理的必要•11.2軟體構型管理•11.3需求管理•11.4構型與變更管理工具•11.5結語3學習目標•瞭解軟體專案的變更問題•瞭解軟體構型管理•瞭解需求變更管理•瞭解構型管理的相關工具4變更管理的必要(1/4)•多數時候，軟體開發處於一種摸索前進的狀態，需要不斷地依據當時的情況做修正。更何況，每一個新系統本身，對於現況就是一種改變。任何過程中的建議或調整，也是一項改變。所以「變」可以說是軟體專案中唯一的常態；任何開發過程中的產出，都可能被改變。•缺乏變更管理是造成開發混亂的根源，也是時程延誤與品質問題的根本原因之一。變更會帶進連鎖反應；需求的變更會導致設計與實作等一連串的改變。不當的變更造成專案缺乏控制、監督、追蹤與管理。5變更管理的必要(2/4)•專案管理是一個持續溝通與談判的過程。只要有良好的管理，適當的變更代表可獲得更高的用戶滿意度與商業價值的機會；變更不全是有害的，專案團隊必須積極地面對並制定計畫。•既要執行改變，又要維持專案的正常進度，其解決方法為「雙軌進行」：利用構型管理，先建立一個基準線（baseline），加以嚴格控管；而另一方面，允許需要變更的部分，進行必要的改變。然後在一個適當時機，將經過認可後的修改，整合到基準線中，變成新的基準。6變更管理的必要(3/4)•為了確保專案的目標與計畫的進行，在經過一個時間點之後，任何專案的變更建議，都需要經過一個審核過程，以評估對專案的衝擊程度。同樣地，修正後的結果，也需要有一個認證的過程，以確保專案團隊共同參考的基準線，不受變動可能產生的負面影響。•避免變更導致的混亂或失控。實務上，必須重視以下工作：–需求管理：需求是多數變動的源頭；需求變更的原因有許多，但未於專案開發初期，仔細分析顧客的需求，就直接進入系統開發，是常見的需求變更原因。7變更管理的必要(4/4)–變更管理：既然變更不可避免，就應確實做好變更評估與追蹤管理，否則許多變更帶來的副作用，如成本上升、時程延誤、軟體品質退化等，將會導致專案的失控。–資源配置：獲得許可的變更請求，若未配置適當的資源去執行任務，也是枉然。8軟體構型管理(1/12)•何謂軟體構型管理（SoftwareConfigurationManagement,SCM）–IEEE的定義是：「辨識與定義系統中的項目、控制它們在生命週期中的改變、記錄並報告它們的狀態、提出變更要求，以及驗證這些項目的正確與完整性。」–Pressman的定義是：「一組用來控制變更的活動，其方法包括：辨識容易改變的工作產出、建立它們之間的關係、定義管理不同版本的機制、控制加入的改變、稽核並報告所做的變更。」9軟體構型管理(2/12)•就其內容而言：「SCM是一個辨識、組織、控制與追蹤，關於軟體結構、功能、演化、與團隊合作之分解和組合的程序。簡單地說，SCM是產出、性能、變更，以及與團隊成員之間的『黏膠』；將它們結合在一起，從概念直到產品交付。」•就SCM的目的而言：「SCM是一管理工具，應用工程紀律來管理軟體從概念到產品退休之間的演化。主要重點在於確保被開發與被建造之系統的可重複性、可追溯性與整體性。」10軟體構型管理(3/12)•SCM的四項基本功能–SCM中一個非常重要的概念是「版本」，構型管理從建立並發布構件項的基準線開始。–版本管理提供了一個框架來容納並管理變動。透過基準線的安排，它可以凍結大家所共同參考的開發成果，隔絕那些尚未準備好與他人分享的工作，以及那些不應與他人分享的工作。–SCM的四大功能：辨識、變更管理、狀態報告與稽核，分述於後（如圖11.2）。11圖11.2軟體構型管理的四個支柱12軟體構型管理(4/12)–構件辨識•包含分析軟體系統的結構、辨識個別單獨的元件，以及建立一套構件的存取方式。•辨識不僅意味著將物件區別出來，還包含辨識物件之間的結構與相互關連。•構件辨識包含以下活動：–選擇需要加入SCM控制的項目；–建立SCM的軟體階層結構（如圖11.3）；–建立能夠反映此一階層結構的辨識規範；–決定哪一版本的元件可以或不可以加入基準線；–辨識各種系統產品的修正版及其之間的關係；–發布構型文件；–建立基準線。13圖11.3軟體構件項之階層結構14軟體構型管理(5/12)•有效的構件項辨識，是SCM其它各項功能發揮的先決條件。如果某些構件項未能確實辨識，管控軟體開發過程中的變動就失去意義。•構件項的核心元件，是需求與原始碼程式。其相關文件與資料都應納入SCM管理，並加以追蹤，以確保在整個軟體生命週期的任何階段都可以被重製出來。–構型變更管理•控制軟體產品的發布與變更，此為SCM最容易被觀察到的功能。其流程包括：準備、判斷、評估、協調、發布與實施提交的工程變更，並加入到對應的構件項或基準線中。15軟體構型管理(6/12)•構型變更管理的目標是建立一套機制，以確保產品的各個版本都包含必要的元件，且元件是對的版本，能夠共用在一起。它要能夠回答：誰被控制？變更如何加入？誰負責這些變更？以及何時收到、接受，並許可這些變更。•構型變更管理的一般性活動包括：–定義變更控制流程。–建立變更控制政策與程序。–維護基準線。–處理變更申請。–控制變更發布。16軟體構型管理(7/12)–狀態報告•內含變更流程的紀錄與報告，目標是維護所有基準線項目的最新狀態、歷史紀錄與提交過的變更，包含對所有基準線變更的可追蹤性報告。狀態報告可以回答：系統做了什麼改變？哪些檔案受到這份問題報告的影響？其日常活動包括：–決定日誌的型態與相關報告；–追蹤SCM項目的狀態；–追蹤系統改變後的狀態；–記錄並報告SCM的活動。17軟體構型管理(8/12)•狀態紀錄使得與構型有關的關鍵資訊，可被傳送與溝通：工程師可看到基準線中哪些被修正；專案管理者可追蹤問題報告以及其它維護活動。•狀態紀錄至少應包括異動日誌、修改日誌、項目的差異（delta）報告；此外，還應記錄構型的衍生歷史，內容包括：做了什麼改變、誰做的、何時，以及為何這樣做。–構型稽核•利用測試報告與文件來驗證軟體產品之建造，是否符合需求、標準或其它合約協訂，以確保所有產品都遵守原先的安排。18軟體構型管理(9/12)•稽核可以是正式或非正式的。正式稽核又分成兩種：功能構型稽核（FunctionalConfigurationAudit,FCA）與實體構型稽核（PhysicalConfigurationAudit,PCA）。•FCA驗證軟體是否符合功能需求與介面需求規範，亦即確認系統符合需求。•PCA則確認設計及參考文件是否代表所建造的軟體。•構型稽核包含以下活動：–定義稽核時程與程序，–找出誰來稽核，–產生稽核報告。19軟體構型管理(10/12)•軟體構型管理的意義–構型管理的工程方法讓我們能以秩序化、結構化與效率化的方式，來管理軟體開發的各種活動。其範圍涵蓋整個軟體開發週期，影響層面包括資料與流程。–工程化的紀律能夠從三方面為軟體開發帶來好處：•支援：提供各種功能，協助工程師、開發者等進行自己的任務。•控制：保持各種文件，如專案、計畫、需求、設計、程式的最新狀態。•服務：可協助各種專案變更的進行，提供分析與事後的追蹤。20軟體構型管理(11/12)•在構型管理中，不同角色所必須擔負的責任：–構型管理者：辨識並組合構件項、定義構型管理流程；–構型控制委員會：負責核可或駁回變更申請、相依項目表列、衝擊分析；–用戶或顧客：提出變更申請、追蹤變更結果；–開發者：執行變更申請、建立新的版本；–稽核者：評估變更結果、確保新版本的完整性與一致性。21軟體構型管理(12/12)•今日的軟體構型管理–傳統的軟體構型管理主要應用在專案後期，當開發接近完成時的產品發布，以及後續的維護上；主要目的在於支援新產品的發布。–今日的軟體開發，強調漸進式、多循環流程，以及要擁抱改變。所以它的問題是，如何在控制之下，處理相對微小的新增片段。–SCM的價值變成支援軟體開發本身，以應付過程中的各種變動（尤其是需求的變動）。因此，SCM如今又被稱為SCCM：軟體變更與構型管理（SoftwareChangeandConfigurationManagement），並導入自動化工具來執行。22需求管理(1/7)•需求管理是指「辨識、衍生、分配，以及控制所有與系統有關的功能、屬性、介面及驗證，以一種一致的、可追蹤的、相互關連的與可驗證的方法，來滿足顧客或工程上的需求。」•廣義的需求管理，包含所有與需求有關的活動，亦即需求工程。狹義需求管理，則著重在管理及控制需求的演化。•需求的變化通常是專案變動的源頭，而不良的需求管理是導致許多專案失敗常見的原因。所以一旦有了確認過的需求，就必須非常慎重地處理日後從各方而來、不可避免的變更請求。•需求管理的精神，在於避免不值得或不必要的需求變更。（但不是說要拒絕所有的需求變更。有些需求變更是有益的，有些想拒絕也拒絕不了。）23需求管理(2/7)•積極的需求管理是降低需求變動的衝擊。其方法有：–將需求分類、–建立一個可追溯的需求結構、–管理需求變更•從穩定性來看，需求有兩種：–耐久性需求：通常來自於顧客的核心活動。–變動性需求：會隨著開發或使用而改變。例如，管理上的需求，常會隨著環境而改變。–若軟體的基礎設計能建構在穩定性的需求之上，而對變動性的需求保持謹慎，則透過良好的設計，可以保持系統最大的彈性，並減少變動的成本。24需求管理(3/7)•變動性需求通常屬於以下幾類：–「規範性需求」會隨著外在的環境要求而改變；–「浮現性需求」會隨著軟體的開發，因為對系統更瞭解而浮現；–「衍生性需求」是因為採用了電腦化系統之後，所產生出的新需求；–「匹配性需求」係建立在組織流程或其他系統之上的需求。–預期未來之變更，是軟體工程的基本原則之一。所以面對這一類需求時，應特別注意其需求的穩定性。25需求管理(4/7)•建立一個可追溯的需求結構–需求的可追溯性，是指有能力從任何一個方向，去描述並追溯一個需求，從發生到結束。–達成需求可追溯性的方法主要有下列幾種：•交互參照（crossreferencing）：利用需求的標示、編號、索引，或者需求追溯矩陣，來追蹤這些交互參照。文件中則註明，請參考「某某節」的字樣。•特殊的樣版與整合文件：用以儲存不同開發階段所產生之文件的連結。•重新結構（restructuring）：將文件重新組合，用網路或圖形結構描述，以追蹤需求之變更。26需求管理(5/7)–需求追溯的涵蓋範圍，包括對需求、需求來源與系統設計間的關連性描述。–「源頭追溯」描述從需求到需求關係人之間的連結；「需求追溯」描述相依需求之間的連結；「設計追溯」描述從需求到設計之間的連結。–缺少了適當的需求追溯，任何改變只能用隨興或特例的方式，評估對其它項目的衝擊，無法有效地應付各種改變。27需求管理(6/7)•需求變更管理（ChangeRequestManagement,CRM）–需求管理應交由跨部門組成的代表，如變更審查小組或變更控制委員會來處理，其任務包括：評估需求變更的必要性，以及估算一項變更對某個專案成本、時程衝擊等影響。•需求的演化可從兩方面來管理–技術面的辦法：衝擊分析與需求追蹤。–管理面的辦法：利用指標來監督需求的穩定性，以控制或避免需求蔓延，並藉由這些代表需求穩定度的指標，來組織、控制並追蹤需求的改變。28需求管理(7/7)–需求演化的量化指標•最簡單的監控指標是累積需求變更數（CumulativeNumberofRequirementsChanges,CRC）與平均需求變更數（AverageNumberofRequirementsChanges,ARC），指標能反映現象背後的趨勢。•IEEE982標準建議用「軟體成熟度」（SoftwareMaturityIndex,SMI）來量化軟體產品接近完成的程度；同樣的邏輯，若將它用在軟體需求上，則可得到需求成熟度（RequirementsMaturityIndex,RMI）指標，以衡量需求接近成熟的程度。•需求穩定度（RequirementsStabilityIndex,RSI）指標