需求管理.ppt

構型與變更管理工具(2/2) 版本管理工具通常具備以下功能： 版本與發行編號：系統自動給予新發行的版本編號。 儲存管理：系統會自動保存版本間的差異部分（delta），而非儲存整個版本。 變更歷史紀錄：記錄版本產生的原因。 開發獨立：新式的工具允許同時多人將同一版本文件或程式check out出來修改。 支援專案：可管理一組與專案有關的檔案，而非僅僅單一檔案。 結語(1/2) 軟體專案是一個持續溝通與協商的過程，因此變更不可避免。但是變更管理（尤其是需求）若不處理好，則會使得軟體開發變成射擊移動的目標（shoot moving target），最終導致專案的失敗。 面對變更的問題，軟體專案經常處於兩難的情況：不接受變更會導致顧客的需求不被滿足；而接受變動又會影響專案的開發，造成混亂。現今普遍的解決之道，是採用構型管理，提供雙軌的開發空間。透過基準線的設立，一面做好變更與版本控制，一面給予開發者足夠的創作空間，發展各自的系統。 結語(2/2) 不穩定的需求是軟體專案致命的風險，尤其是需求的演化，經常在不知不覺中進行。所以應落實需求變更的追蹤，並降低需求變動的衝擊。良好的構型管理、事前定義的變更控制流程，以及變更控制委員會（CCB）的角色，是落實需求管理不可或缺的幾項要素。 傳統的軟體構型管理，主要應用在專案後期，當產品接近完成時；今日的軟體開發則強調漸進式、多循環流程，以及要擁抱改變，所以需要經常面對相對微小但頻繁變動的新增片段。 構型管理是很瑣碎的工作，良好的構型管理應導入自動化工具來協助，否則將難以落實。 * * * * * * * * * * * * * * * * * * * * * * * * * 第11章 變更管理　 本章大綱 11.1　變更管理的必要 11.2　軟體構型管理　 11.3　需求管理 　 11.4　構型與變更管理工具 　 11.5　結語　 學習目標 瞭解軟體專案的變更問題 瞭解軟體構型管理 瞭解需求變更管理 瞭解構型管理的相關工具 變更管理的必要(1/4) 多數時候，軟體開發處於一種摸索前進的狀態，需要不斷地依據當時的情況做修正。更何況，每一個新系統本身，對於現況就是一種改變。任何過程中的建議或調整，也是一項改變。所以「變」可以說是軟體專案中唯一的常態；任何開發過程中的產出，都可能被改變。 缺乏變更管理是造成開發混亂的根源，也是時程延誤與品質問題的根本原因之一。變更會帶進連鎖反應；需求的變更會導致設計與實作等一連串的改變。不當的變更造成專案缺乏控制、監督、追蹤與管理。 變更管理的必要(2/4) 專案管理是一個持續溝通與談判的過程。只要有良好的管理，適當的變更代表可獲得更高的用戶滿意度與商業價值的機會；變更不全是有害的，專案團隊必須積極地面對並制定計畫。 既要執行改變，又要維持專案的正常進度，其解決方法為「雙軌進行」：利用構型管理，先建立一個基準線（baseline），加以嚴格控管；而另一方面，允許需要變更的部分，進行必要的改變。然後在一個適當時機，將經過認可後的修改，整合到基準線中，變成新的基準。 變更管理的必要(3/4) 為了確保專案的目標與計畫的進行，在經過一個時間點之後，任何專案的變更建議，都需要經過一個審核過程，以評估對專案的衝擊程度。同樣地，修正後的結果，也需要有一個認證的過程，以確保專案團隊共同參考的基準線，不受變動可能產生的負面影響。 避免變更導致的混亂或失控。實務上，必須重視以下工作： 需求管理：需求是多數變動的源頭；需求變更的原因有許多，但未於專案開發初期，仔細分析顧客的需求，就直接進入系統開發，是常見的需求變更原因。 變更管理的必要(4/4) 變更管理：既然變更不可避免，就應確實做好變更評估與追蹤管理，否則許多變更帶來的副作用，如成本上升、時程延誤、軟體品質退化等，將會導致專案的失控。 資源配置：獲得許可的變更請求，若未配置適當的資源去執行任務，也是枉然。 軟體構型管理(1/12) 何謂軟體構型管理（Software Configuration Management, SCM） IEEE的定義是：「辨識與定義系統中的項目、控制它們在生命週期中的改變、記錄並報告它們的狀態、提出變更要求，以及驗證這些項目的正確與完整性。」 Pressman的定義是：「一組用來控制變更的活動，其方法包括：辨識容易改變的工作產出、建立它們之間的關係、定義管理不同版本的機制、控制加入的改變、稽核並報告所做的變更。」 軟體構型管理(2/12) 就其內容而言：「SCM是一個辨識、組織、控制與追蹤，關於軟體結構、功能、演化、與團隊合作之分解和組合的程序。簡單地說，SCM是產出、性能、變更，以及與團隊成員之間的『黏膠』；將它們結合在一起，從概念直到產品交付。」 就SCM的目的而言：「SCM是一管理工具，