軟件項目在執(zhí)行過程的變更，特別是需求的變更是難把握的，它也是影響到整個項目成敗的關(guān)鍵因素。

一、計算機系統(tǒng)集成軟件開發(fā)項目需求變更產(chǎn)生的原因

對于軟件項目的需求而言，產(chǎn)生變更的原因集中在下面幾個方面:

1.用戶對系統(tǒng)功能理解的分歧。在進行用戶需求調(diào)查分析時，分析人員的知識、背景、與用戶的交流情況等因素會造成系統(tǒng)分析人員和用戶在功能理解上的分歧，隨著項目的進行，這種分歧肯定會帶來變更。

2.用戶業(yè)務(wù)邏輯發(fā)生了變化。用戶自身的業(yè)務(wù)邏輯不太明確，特別是處于激烈競爭情況下的用戶肯定要隨著市場情況的變化，隨時調(diào)整自己的運作來適應(yīng)這種變化，這肯定會對相關(guān)的軟件產(chǎn)品提出更多的變更要求。

3.用戶在試用過程中提出的變更。當(dāng)用戶拿到測試版本可以進行實際操作時，用戶一般都會對功能、性能、界面、操作方式等提出新的意見，這時變更產(chǎn)生了。

4.技術(shù)的升級。技術(shù)的升級分為兩個方面，一方面是隨著信息化技術(shù)的迅速發(fā)展，原項目中使用的技術(shù)可能變成過時技術(shù)，需要對原技術(shù)進行升級;另一個方面是開發(fā)方自身對軟件版本升級、性能改進、設(shè)計修正時產(chǎn)生的變更。從上面可以看出，指望軟件項目需求能從始至終一成不變是不可能的。

二、計算機系統(tǒng)集成軟件開發(fā)項目需求變更的影響及管理原則

1.設(shè)定項目需求基線。需求基線是需求變更的參照標準，每次的變更均應(yīng)在需求基線的基礎(chǔ)上進行。每次變更評審?fù)ㄟ^后要重新確定需求基線，使其符合需求變更后的狀況。

2.嚴格執(zhí)行需求變更流程，并記錄在變更過程中產(chǎn)生的所有文檔。

3.成立項目變更控制委員會(CCB)，負責(zé)對項目變更進行評估，裁定哪些變更需要執(zhí)行，哪些變更應(yīng)該放棄。變更控制委員會的成員應(yīng)由項目所涉及到的多方面人同組成，應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。

4.需求變更后，受影響的相關(guān)軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。

三、計算機系統(tǒng)集成軟件開發(fā)項目需求變更的流程

在軟件項目需求變更時，一般采用下面的流程進行控制:

1.申請變更。當(dāng)項目開發(fā)組確認將要產(chǎn)生需求變更時，用標準的變更申請表格將用戶的每一次變更申請記錄存檔。

2.變更評估。項目開發(fā)組收到用戶提交的需求變更申請后，應(yīng)對該變更所帶來的影響進行評估。它包括項目的人力、物力、資金、管理、時間、質(zhì)量、工作負荷等內(nèi)部因素，以及外部因素如資本、用戶要求的完工時間、項目負債情況等各個方面的影響。對于一個變更的申請，可能會有以下幾個可能的評估結(jié)果:(1)在現(xiàn)有資源和時間范圍允許的情況下可以采納該變更。(2)可以采納，但要延長交付時間。(3)在現(xiàn)有的可交付時間內(nèi)可以采納，但需要額外的資源支持。(4)可以采納，但需要額外的資源和延長交付時間。(5)可以采納，但需要采取多次發(fā)布策略，并排定不同發(fā)布時期交付成果的優(yōu)先次序。這種情況的發(fā)生非常頻繁，項目經(jīng)理需要權(quán)衡將一些重要的工作提前完成，而有一些不重要的工作延遲完成。(6)不能采納。

3.變更的實施。一旦確定變更后，下一步是分析和選擇可行的實施方案。項目的目標、預(yù)算、團隊以及項目的進度是決定項目成功實施的主要因素。在需求變更時，力求在盡可能小的變動幅度內(nèi)對這些主要的因素進行微調(diào)。為了將項目變更的影響降低到小，一定要認真執(zhí)行變更的控制流程，減小項目風(fēng)險。

四、實際項目分析

以某學(xué)院的信息管理系統(tǒng)軟件開發(fā)項目為例。該系統(tǒng)包括了學(xué)籍管理、排課管理、學(xué)生選課、教材管理、學(xué)生考勤管理、教學(xué)質(zhì)量管理、考試管理、成績管理、宿舍管理、財務(wù)管理、證明管理、招生管理等子系統(tǒng)。在開發(fā)過程中，我們對需求變更進行了較嚴格的管理，產(chǎn)品得以按時保質(zhì)地上線。在該管理信息系統(tǒng)的開發(fā)過程中，變更的因素有以下幾個:1.由于項目啟動時間距離第一個版本的上線時間很近，不可能在短時間內(nèi)將所有的需求都獲取到。2.開發(fā)人員有時會對用戶的描述理解不正確，或遺漏某些要求，所以要對已有的需求進行修改。3.用戶在項目開始的時候，大都不是很了解自己到底需要什么，等他們使用一段時間管理系統(tǒng)后，會在實際使用中不斷發(fā)現(xiàn)這樣那樣的需求。4.主要的因素，是該學(xué)院成立時間不長，且不是采用國內(nèi)常規(guī)的管理方法，而要使這些管理方法適合國內(nèi)的高校管理體制，需要有一段磨合期，所以學(xué)院內(nèi)部的管理經(jīng)常變，導(dǎo)致系統(tǒng)的相應(yīng)需求也必須變。變更控制委員會由主管這套系統(tǒng)開發(fā)的副院長、項目經(jīng)理以及配置管理員三個人組成。根據(jù)開發(fā)的實際情況，我們制定了一套變更管理程序，是所有變更都必須以變更申請書的形式提交給變更控制委員會，變更控制委員會評估后，出具變更報告，然后才交給相關(guān)人員做相應(yīng)處理，之后，由測試人員對變更后的相關(guān)用例進行測試跟蹤。一個需求變更申請?zhí)峤缓螅�變更控制委員會對其進行評估，如確認進行變更，則由我方項目經(jīng)理出具一份變更報告，寫明變更事由、提出方、提出時間、變更評估結(jié)果。配置管理員將這份變更報告加到配置管理庫中存檔，并分發(fā)給變更申請人以及相關(guān)系統(tǒng)分析員。系統(tǒng)分析員對之進行分析，提交出一份變更列表，將該變更所影響到的文檔、程序都詳細的列出來，上交給配置管理員進行存檔。然后，系統(tǒng)分析員對列表的中所列出來的文檔逐個進行修改，再交由編程人員進行相應(yīng)的代碼修改，然后提交測試員測試，出具測試報告。這些修改的文檔、代碼以及測試報告都要提交給配置管理員進行存檔管理，配置管理員還要根據(jù)提交情況對變更列表進行相應(yīng)維護，如某項修改完成了，要在它后面打上完結(jié)標記。當(dāng)該變更列表中的所有變更項都完結(jié)了，配置管理員在變更報告后要加上實際完成時間。這樣，變更所導(dǎo)致的文檔、程序變化可以在一個可以追溯、可以控制的狀態(tài)下進行了。減少了遺漏的可能性，并便于變更的追蹤。由于采取了上述變更控制方法，即使該項目的變更比較多，但還是能保持開發(fā)工作正常有序地進行。

五、結(jié)束語

對于軟件開發(fā)的過程中不可避免的會出現(xiàn)需求變更，并且這些變更會發(fā)生在項目的整個生命周期里，因此變更控制顯得尤其重要，變更控制的管理好壞對項目成敗有重要影響。