軟體專案管理 三 軟體專案範圍管理

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

需求獲取工作的任務就是收集專案干係人的需求資訊，為定義專案的範圍奠定基礎。

需求獲取工作只能通過使用者與開發人員之間進行高度的合作和交流才能成功。

在軟體專案的需求獲取活動中，一般要收集以下類別的使用者需求：

（ 1

）介面需求：描述軟體系統的外部特性，即系統如何從外部得到資料輸入，如何向外部輸出資料。（ 2
）功能需求：列出軟體系統必須完成的所有功能。（ 3
）效能需求：響應時間、吞吐量、處理時間、儲存空間等方面的限定。（ 4
）質量需求：對安全性、保密性、可靠性、可維護性、可移植性、易用性等方面的要求。（ 5
）資源使用需求：對硬體、支援軟體、資料通訊介面等方面的要求。（ 6
）軟體成本消耗與開發進度需求：即對時間和經濟方面的要求。
（ 7 ）異常處理要求：在執行過程**現異常情況 ( 如臨時性或永久性的資源故障，不合法或超出範圍的輸入資料、非法操作等 ) 時應採取的行動以及希望顯示的資訊。

但也可包括多個訪談者或多個被訪者。訪談有經驗的專案參與者、發起人、以及主題專家，有助於識別和定義專案可交付成果的特徵和功能。

（ 2 ）討論會。討論會把主要專案干係人召集在一起，通過集中討論來定義專案需求。討論會是快速定義跨職能需求和協調干係人差異的重要方法。由於群體互動的特點，

被有效引導的討論會有助於參與者之間建立信任、改善關係、改進溝通，從而有利於干係人達成一致意見。在每次討論會中，都必須記錄所討論的內容，並在會後加以整理。

在會前應提前發給參加人員有關討論會的議題和內容等材料，以便有所準備。

（ 3 ）觀察使用者工作流程。直接觀察使用者在其實際環境中怎樣執行工作是一種行之有效的獲取需求方法。當產品使用者難以清晰說明他們的需求時，就特別需要通過觀察了解他們的工作細節。

通常由觀察者從外部來**業務專家如何執行工作，也可由觀察者實際執行乙個流程或程式，來體驗該流程或程式是如何實施的，以便挖掘隱藏的需求。

（ 4 ）問卷調查。問卷調查是指設計一系列書面問題，向眾多受訪者收集資訊。當需要調查大量人員的意見時，向被調查人分發調查問卷是乙個十分有效的做法。經過仔細考慮寫出的書面回答

可能比被訪者對問題的口頭回答更準確。調查者應仔細閱讀收回的調查表，然後再有針對性地訪問一些使用者，以便向他們詢問在分析調查表時發現的新問題。

（ 5 ）快速原型法。快速原型法是指在軟體開發的早期快速建立目標軟體系統的原型，並據此徵求使用者對需求的反饋。由於原型是可以操作的，它使得使用者可以體驗最終產品的模型，

而不是僅限於討論抽象的需求描述，從而可以獲得更為準確和清晰的需求。快速原型法需要經歷從模型建立、使用者體驗、反饋收集到原型修改的反覆迴圈過程。在經過足夠的反饋迴圈之後，

就可以通過原型獲得足夠的需求資訊。

5. 分析和整理收集到的使用者需求

（1）對於使用者提出的每個需求都要知道「為什麼」，並判斷使用者提出的需求是否有充足的理由。

（2）將那種以「如何實現」方式表達的需求轉換為「實現什麼」的方式。因為需求獲取階段關注「做什麼」，而不是「怎麼做」。
（3）分析由使用者需求衍生出的隱含需求，並識別使用者沒有明確提出來的隱含需求。

軟體產品是專案的最終交付物，因此軟體產品範圍是軟體專案範圍中最重要的一部分。

在軟體專案中，產品範圍通常表現為軟體需求規格說明書（ software requiremets specificatio, srs ）。

（ 2 ）系統介面描述。即描述軟體系統與其他軟硬體系統之間的介面。在描述系統範圍時，明確介面是非常必要的。

（ 3 ）質量特徵描述。主要的質量特徵包括效能、可靠性、可移植性、機密性、可維護性等。不同程度的質量要求對專案的工作範圍會有很大影響。

（ 1 ）專案範圍包含產品範圍，同時還包含更廣泛的內容，專案中應展開的工作均屬於專案範圍，例如制定專案計畫、編寫文件、使用者培訓等。

（ 1 ）產品範圍描述。即專案所創造的產品的特性。

（ 2 ）驗收標準。可交付成果通過驗收前必須滿足的一切條件。

（ 3 ）可交付成果。在某一過程、階段或專案完成時，必須產出的可核實的產品和成果。

（ 4 ）專案的除外責任。通常需要識別出什麼是被排除在專案之外的。明確說明哪些內容不屬於專案範圍，有助於管理專案干係人的期望。

（ 5 ）制約因素。需要列舉並描述與專案範圍有關且會影響專案執行的各種內外部制約或限制條件。例如，客戶或執行組織事先確定的預算，強制性日期或進度里程碑等。

（ 6 ）假設條件。在制定計畫時，一些未經驗證就被視為正確、真實或確定的因素。對假設條件還應描述如果條件不成立，可能造成的潛在影響。

建立工作分解結構就是把專案分解成具有內在聯絡的、更小、更詳細、易於管理、易於控制的組成部分。通過建立工作分解結構，不僅使專案範圍更為明確，而且為制定進度計畫、成本計畫等提供了基礎。

工作分解結構 （ work breakdow structure, wbs ）是對專案團隊為實現專案目標、建立可交付成果而需實施的全部工作範圍的層級分解。

根據需求分析的結果和專案的相關要求，分解出wbs。常見的分解方法有三種：

模擬法自頂向下法
自底向上法

wbs模板舉例

(2) 自頂向下法

(3) 自底向上法（1）根據交付物進行分解

（2）根據專案階段分解

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

（ 1 ）分解出的工作對於完成上層相應交付物來說是必要且充分的。

（ 2 ）工作的獨立性。即工作一旦開始，就可以在不中斷的條件下完成。

（ 3 ）工作完成度的可判斷性。即可以清楚地判斷工作是否已經開始，工作完成了多少，以及工作是否完成。

（ 4 ）工作的交付成果。即明確工作完成後將得到什麼樣的成果。

（ 1 ）專案最底層的工作包要非常具體，任務分解的結果必須有利於責任分配，從而保證各工作包的負責人能夠明確自己的具體任務，也便於專案的管理人員對專案的執**況進行監督和業績考核。

（ 2 ）工作分解得越細緻，對工作的規劃、管理和控制就越有力，但是，過細的分解會造成管理工作的無效耗費，資源使用效率低下，工作實施效率降低。因此 wbs 的層數不宜太多，一般不超過 7 層。

（ 3 ）對於最底層的工作包，一般要有詳細和明確的文字說明，定義任務完成的標準。常常把所有工作包的文字說明匯集到一起，編成乙個 wbs 字典（ wbs dictioary ）。

軟體專案管理

軟體專案管理 課程背景 21世紀研發已成為企業競爭的主戰場，研發專案管理是極具挑戰性的一項工作 研發面臨市場 客戶的壓力，需要與內外部的各大部門協調，如 內部的測試 工藝工裝 生產 採購等相關職能部門，外部的 商 認證機構等 在保證產品質量的同時又要降低產品研發費用和成本 在產品開發的過程中需要不斷...

軟體專案管理

3.1 軟體專案管理概述 1.概念 專案 project 為建立某種特定的產品或服務而組織或設計的臨時的 一次性的行動 通過執行一組活動，使用受約束的資源 資金 人 原 料 能源 空間等 來滿足預定義的目標。專案管理 project management,pm 有效的組織與管理各類資源 例如人 以使...

軟體專案管理

以前看了一些軟體工程的書，非常的膚淺，一直深入不下去。這兩天帶領兩個才畢業的學生做專案，我把需求文件 設計文件 資料庫文件都寫好，然後把工作分成很多的小塊讓他們去做，當然這些小塊的功能怎麼做都告訴他們倆了，也就是我把詳細的工作都安排好，他們兩個去執行就行了。對於軟體專案的開發管理來說，現在我感覺最重...