項目范圍對項目的影響是決定性的，它確定了軟件項目工作內容的多少。有效的范圍管理可以保證項目只做必須做的事情，避免范圍蔓延和做無用功，同時也避免不清晰的需求所導致的嚴重的系統缺陷。?

本章內容提要

n3.1 需求獲取 n3.2 范圍定義 n3.3 創建工作分解結構 n3.4 范圍確認 n3.5 范圍控制 n3.6 案例分析

3.1 需求獲取

n需求獲取工作的任務就是收集項目干系人的需求信息，為定義項目的范圍奠定基礎。n需求獲取工作只能通過用戶與開發人員之間進行高度的合作和交流才能成功。n在軟件項目的需求獲取活動中，一般要收集以下類別的用戶需求：n（1）界面需求：描述軟件系統的外部特性，即系統如何從外部得到數據輸入，如何向外部輸出數據。n（2）功能需求：列出軟件系統必須完成的所有功能。n（3）性能需求：響應時間、吞吐量、處理時間、存儲空間等方面的限定。n（4）質量需求：對安全性、保密性、可靠性、可維護性、可移植性、易用性等方面的要求。n（5）資源使用需求：對硬件、支持軟件、數據通信接口等方面的要求。n（6）軟件成本消耗與開發進度需求：即對時間和經濟方面的要求。n（7）異常處理要求：在運行過程中出現異常情況(如臨時性或永久性的資源故障，不合法或超出范圍的輸入數據、非法操作等)時應采取的行動以及希望顯示的信息。

獲取需求的常用方法?

n（1）訪談。訪談是通過與干系人直接交談來獲取信息。訪談的典型做法是向被訪者提出問題，并記錄他們的回答。訪談經常是一個訪談者和一個被訪者之間的一對一談話，但也可包括多個訪談者或多個被訪者。訪談有經驗的項目參與者、發起人、以及主題專家，有助于識別和定義項目可交付成果的特征和功能。

n（2）討論會。討論會把主要項目干系人召集在一起，通過集中討論來定義項目需求。討論會是快速定義跨職能需求和協調干系人差異的重要方法。由于群體互動的特點，被有效引導的討論會有助于參與者之間建立信任、改善關系、改進溝通，從而有利于干系人達成一致意見。在每次討論會中，都必須記錄所討論的內容，并在會后加以整理。在會前應提前發給參加人員有關討論會的議題和內容等材料，以便有所準備。n（3）觀察用戶工作流程。直接觀察用戶在其實際環境中怎樣執行工作是一種行之有效的獲取需求方法。當產品使用者難以清晰說明他們的需求時，就特別需要通過觀察了解他們的工作細節。通常由觀察者從外部來觀看業務專家如何執行工作，也可由觀察者實際執行一個流程或程序，來體驗該流程或程序是如何實施的，以便挖掘隱藏的需求。n（4）問卷調查。問卷調查是指設計一系列書面問題，向眾多受訪者收集信息。當需要調查大量人員的意見時，向被調查人分發調查問卷是一個十分有效的做法。經過仔細考慮寫出的書面回答可能比被訪者對問題的口頭回答更準確。調查者應仔細閱讀收回的調查表，然后再有針對性地訪問一些用戶，以便向他們詢問在分析調查表時發現的新問題。n（5）快速原型法。快速原型法是指在軟件開發的早期快速建立目標軟件系統的原型，并據此征求用戶對需求的反饋。由于原型是可以操作的，它使得用戶可以體驗最終產品的模型，而不是僅限于討論抽象的需求描述，從而可以獲得更為準確和清晰的需求。快速原型法需要經歷從模型創建、用戶體驗、反饋收集到原型修改的反復循環過程。在經過足夠的反饋循環之后，就可以通過原型獲得足夠的需求信息。

分析和整理收集到的用戶需求

n對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由。n將那種以“如何實現”方式表達的需求轉換為“實現什么”的方式。因為需求獲取階段關注“做什么”，而不是“怎么做”。n分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求。

3.2 范圍定義

n范圍定義就是制定項目和產品的詳細描述，從而定義項目的范圍。由于在獲取需求過程中識別出的所有需求未必都包含在項目中，所以范圍定義過程就是從所獲取的需求中選取最終的項目需求，然后制定出項目及其產品的詳細描述。n3.2.1 軟件產品范圍和項目范圍n3.2.2 項目范圍說明書

3.2.1?軟件產品范圍和項目范圍

n軟件產品是項目的最終交付物，因此軟件產品范圍是軟件項目范圍中最重要的一部分。n在軟件項目中，產品范圍通常表現為軟件需求規格說明書（Software Requirements Specification, SRS）。

SRS的內容

n（1）功能特征描述。即軟件系統向使用者提供什么樣的功能。n（2）系統接口描述。即描述軟件系統與其他軟硬件系統之間的接口。在描述系統范圍時，明確接口是非常必要的。n（3）質量特征描述。主要的質量特征包括性能、可靠性、可移植性、機密性、可維護性等。不同程度的質量要求對項目的工作范圍會有很大影響。

項目范圍

n項目范圍包含產品范圍，同時還包含更廣泛的內容，項目中應展開的工作均屬于項目范圍，例如制定項目計劃、編寫文檔、用戶培訓等。

3.2.2 項目范圍說明書

n項目范圍說明書是范圍定義的工作成果，它詳細描述了項目的可交付成果，以及為創建這些可交付成果而必須開展的工作。在實際的軟件項目中，可能不會出現一份叫做《項目范圍說明書》的文檔，但其中的內容可能會被多個文檔包含，如《項目合同》、《項目計劃》、《需求規格說明書》等。

項目范圍說明書的內容

n（1）產品范圍描述。即項目所創造的產品的特性。n（2）驗收標準。可交付成果通過驗收前必須滿足的一切條件。n（3）可交付成果。在某一過程、階段或項目完成時，必須產出的可核實的產品和成果。n（4）項目的除外責任。通常需要識別出什么是被排除在項目之外的。明確說明哪些內容不屬于項目范圍，有助于管理項目干系人的期望。n（5）制約因素。需要列舉并描述與項目范圍有關且會影響項目執行的各種內外部制約或限制條件。例如，客戶或執行組織事先確定的預算，強制性日期或進度里程碑等。n（6）假設條件。在制定計劃時，一些未經驗證就被視為正確、真實或確定的因素。對假設條件還應描述如果條件不成立，可能造成的潛在影響。

3.3 創建工作分解結構

n創建工作分解結構就是把項目分解成具有內在聯系的、更小、更詳細、易于管理、易于控制的組成部分。通過創建工作分解結構，不僅使項目范圍更為明確，而且為制定進度計劃、成本計劃等提供了基礎。n工作分解結構（Work Breakdown Structure, WBS）是對項目團隊為實現項目目標、創建可交付成果而需實施的全部工作范圍的層級分解。

WBS的結構

nWBS組織并定義了整個項目范圍，不在WBS中包括的工作就不是該項目的工作。nWBS是一個分級的樹型結構，是對項目由粗到細的分解過程。工作結構每細分一個層次表示對項目元素更細致的描述。nWBS最低層次的組件被稱為工作包，它是項目中最小的可控單元，它應當由唯一主體負責完成。同時，每個工作包又是一個可控制點，可以進行進度的監督和檢查。

WBS的表示類型

創建WBS的方法

? ? ? ??根據需求分析的結果和項目的相關要求，分解出WBS。常見的分解方法有三種：

n類比法n自頂向下法n自底向上法

(1) 類比法

n參考類似的已經完成的項目的WBS和以前的項目經驗，根據當前項目特點做必要的調整，從而得到新項目的WBS。 n一般來說，如果軟件組織經常性地在某一行業或某一類產品中重復多個項目，則項目過程的重合度比較高，較適合采用類比法。 n也可參照人們從大量實踐中總結出的WBS模板。

WBS模板舉例

(2) 自頂向下法

n把項目從粗粒度的任務逐層細化，得到整個項目的分解結構。

(3) 自底向上法

n通過將細粒度的工作逐層歸納而得到整個項目WBS的方法。

自底向上法

n參加分解工作的人員根據自己的理解識別項目中的工作，盡可能詳細地列出完成項目所涉及的各項具體的工作任務，然后對各項工作任務進行分類整合，歸并到一個或者若干個更大的活動中，并構成WBS的上一級內容。 n優點：通過自底向上歸納團隊中不同成員的想法，更容易發揮團隊的力量。 n缺點：分解過程的投入太大，會花費較多的時間和成本。

幾種任務分解方法的適用性

n如果軟件組織在同一應用領域做過多個類似的項目，則可以使用類比法。 n自頂向下分解的質量直接決定于分解者對項目的理解，所以要求分解者經驗豐富，對項目有深入理解和宏觀上的把握。 n自底向上法適用于那些具有創新性或不太熟悉的項目，更容易發揮團隊的力量。 n對于有些項目來說，可能需要綜合應用這三種方法才能得到結構良好的WBS。

任務分解的策略

n創建WBS時，對相同的項目存在著不同的分解策略，例如： n根據交付物進行分解 n根據項目階段進行分解 n根據系統功能組成進行分解

（1）根據交付物進行分解

n該策略是根據項目中必須產生的交付物來劃分項目中的工作。 n把項目的主要交付物（如需求規格說明書、概要設計說明書、軟件包、測試報告、用戶手冊等）作為分解的第二層，確定整個WBS的架構，然后通過類比、自頂向下或自底向上的方法繼續分解。 n根據交付物逐層分解可以很自然地得到結構良好的WBS，不會遺漏項目必需的工作包。

（2）根據項目階段分解

n根據項目階段分解就是首先確定整個項目必須經歷的階段，然后再逐步細化每一階段工作的細目。 n這種分解策略是從工程的角度進行項目分解，使WBS結構與項目工程過程較為一致。 n但該策略對使用者的項目工程經驗要求較高，項目工程經驗不足則較容易遺漏項目中必須的工作包。

按照項目階段進行分解

（3）按照產品的功能組成分解

對任務分解的要求

在創建WBS時，要注意分解的活動至少要滿足四點要求：

n（1）分解出的工作對于完成上層相應交付物來說是必要且充分的。 n（2）工作的獨立性。即工作一旦開始，就可以在不中斷的條件下完成。 n（3）工作完成度的可判斷性。即可以清楚地判斷工作是否已經開始，工作完成了多少，以及工作是否完成。 n（4）工作的交付成果。即明確工作完成后將得到什么樣的成果。?

任務分解的注意事項

n（1）項目最底層的工作包要非常具體，任務分解的結果必須有利于責任分配，從而保證各工作包的負責人能夠明確自己的具體任務，也便于項目的管理人員對項目的執行情況進行監督和業績考核。 n（2）工作分解得越細致，對工作的規劃、管理和控制就越有力，但是，過細的分解會造成管理工作的無效耗費，資源使用效率低下，工作實施效率降低。因此WBS的層數不宜太多，一般不超過7層。 n（3）對于最底層的工作包，一般要有詳細和明確的文字說明，定義任務完成的標準。常常把所有工作包的文字說明匯集到一起，編成一個WBS字典（WBS Dictionary）。

3.4 范圍確認

n范圍確認是指正式驗收已完成的項目可交付成果，從而確認項目可交付成果是否可以讓項目干系人滿意。 n范圍確認工作一般由客戶、發起人等關鍵項目干系人負責。 n通常在進行范圍確認前，項目組需要先進行質量控制工作，如系統測試等工作，以確保范圍確認工作的順利完成。

3.5 范圍控制

n項目范圍的變更必然會造成項目進度計劃、人員安排、成本等各方面的變化，處理不當則會增加項目風險，甚至造成項目陷入混亂的狀態。 n范圍控制就是指監控項目的范圍狀態，管理范圍變更。范圍控制的目的是在出現范圍變更需求后，管理相關的計劃、資源安排以及項目成果，使得項目各部分可以很好地配合在一起，避免變更帶來的負面影響。? n未經控制的產品或項目范圍的擴大被稱為范圍蔓延。變更是不可避免的，為防止范圍蔓延，在每個項目上，都必須強制實施某種形式的變更控制。 n范圍控制通過變更控制系統和配置管理系統來完成。當出現范圍變更需求時，通常要執行一個嚴格的變更控制流程。 n變更實現涉及到配置項的修改，要遵守配置管理規范。 n在項目初期就建立起完整的變更控制和配置管理的流程可以使項目在有序的變化中不斷前進。

3.6 案例分析

n“軟件缺陷管理和度量系統”的SRS和WBS

本章內容小結

n了解軟件項目的需求分類，理解獲取需求的常用方法。 n了解軟件項目產品范圍和項目范圍的一般內容。 n理解WBS的概念，了解創建WBS的常用方法和創建WBS時的分解策略。 n理解軟件項目范圍確認的任務。 n理解范圍控制的任務以及它與變更控制的關系。

總結

以上是生活随笔為你收集整理的第三章 软件项目范围管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。