管理變更請求.pdf10

一旦執行了軟件過程評估，我詢問項目組成員是如何接受產品的變更需求的，其中一位回答說“無論何時市場代表對B r u c e或S a n d y提出變更要求，他們總是說同意，我們就隻好努力去做出來”。他並未正麵回答我的問題。不被控製的變更是項目陷入混亂、不能按進度執行或軟件質量低劣的共同原因。為了使開發組織能夠嚴格控製軟件項目應確保以下事項：

? 應仔細評估已建議的變更。

? 挑選合適的人選對變更做出決定。

? 變更應及時通知所有涉及的人員。

? 項目要按一定的程序來采納需求變更。

隻有項目風險承擔者在開發過程中能控製變更，他們才知道將交付什麼，哪一項將會導致與目標的差距。對項目越深入了解後，你就越能發現采納變更需求條件的苛刻。在需求文檔中一定要反映項目的變更，需求文檔應精確描述要交付的產品，這就是你的原則。要是軟件需求文檔同產品不一致，那它就毫無用處，甚至就象沒有一個軟件需求文檔來指導開發組開發一樣。當你不得不做出變更時，應該按從高級到低級的順序對被影響的需求文檔進行處理。舉個例子，一個已建議的變更可能影響一個使用實例和功能需求但不影響任何業務需求。改動高層係統需求能夠影響多個軟件需求。如果在最低層需求上做出變更，（典型的情況是一個功能性需求），可能會導致需求同上層文檔不一致。17.1 控製項目範圍的擴展Capers Jones（1 9 9 4）在報告中聲稱擴展需求對百分之八十的管理信息係統項目和百分之七十的軍事軟件項目造成風險。擴展需求是指在軟件需求基線已經確定後又要增添新的功能或進行較大改動。問題不僅僅是需求變更本身，而是遲到的需求變更會對已進行的工作有較大的影響。要是每個建議的需求都被采納，對於項目出資者（ s p o n s o r）、參與者與客戶來說項目將永遠也不會完成—事實上，這是不可能的。對許多項目來說，一些需求的改進是合理的且不可避免。業務過程、市場機會、競爭性的產品和軟件技術在開發係統期間是可以變更的，管理部門也會決定對項目做出一些調整。在你的項目進度表中應該對必要的需求改動留有餘地。若不控製範圍的擴展將使我們持續不斷地采納新的功能，而且要不斷地調整資源、進度、或質量目標，這樣做極其有害。這兒一點小的改動，那兒一點添加，很快項目就不可能按客戶預期的進度和預期質量交付使用了。管理範圍擴展的第一步就是把新係統的視圖、範圍、限製文檔化並作為業務需求的一部分，正如第6章所描述的。評估每一項建議的需求和特性，將它與項目的視圖和範圍相比較決定是否應該采納它。強調客戶參與的有效的需求獲取方法能夠減少遺漏需求的數量，隻在做出提交承諾和分配資源後才采納該需求(Jones 1996a)。控製需求擴展的另一個有效的技術是原型法，這個方法能夠給用戶提供預覽所有可能的實現，以幫助用戶與開發者溝通從而準確把握用戶的真實需求（ Jones 1994）。

..............................