您的位置:軟件測試 > 軟件項目管理 > 風險管理 >
淺析軟件項目管理中的需求變更控制
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時間:[ 2013/8/14 15:41:32 ] 推薦標簽:

軟件項目在執(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.用戶在試用過程中提出的變更。當用戶拿到測試版本可以進行實際操作時,用戶一般都會對功能、性能、界面、操作方式等提出新的意見,這時變更產(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),負責對項目變更進行評估,裁定哪些變更需要執(zhí)行,哪些變更應(yīng)該放棄。變更控制委員會的成員應(yīng)由項目所涉及到的多方面人同組成,應(yīng)該包括用戶方和開發(fā)方的決策人員在內(nèi)。

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

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

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

1.申請變更。當項目開發(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í)行變更的控制流程,減小項目風險。

四、實際項目分析

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

五、結(jié)束語

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

軟件測試工具 | 聯(lián)系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd