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)指標