1、軟考論文:項目范圍管理摘要:該文章是我參加信息系統項目管理師考試的一篇練習之作,大概用了兩個小時時間,倉促的完成該論文的寫作,當時還自我感覺良好.對我的文字功底孤芳自賞好一段時間.當參加完考試之后,回頭看這篇論文,才發現這篇論文寫的有多爛,內容粗制濫造不說,整體上給人感覺不實,有造假的嫌疑.本來不想把這篇論文展示給大家的,但想想,這總算是我的勞動成果,也凝聚著我兩個小時的汗水和智慧,因此,特發表出來,還望各位同行不嗇賜教,給點批評,督促我繼續上進.某企業是一個大型的中外合資企業,旗下8個子公司，主要經營手機業務，冰箱洗衣機等白電業務、配套配件生產業務、網絡產品業務。企業以冰箱、洗衣機、手機為主

2、營業務，其他的為輔業。總公司主要做業務規劃，市場調研，營銷，產品開發等工作，子公司則根據總公司下達的生產任務進行組織生產。2002年，公司耗時近兩年，花巨資打造了一套ERP系統，但該ERP系統未能滿足公司的戰略目標和業務目標的要求，現在，除了ERP中的物料管理模塊還在運行外，其他功能基本被廢棄，現在還在使用1998年建設的MRPII系統。但隨著公司規模的不斷擴張，業務范圍不斷拓展，原來的信息系統已經無法再滿足企業的目前業務需求，因此，企業急需升級現在的信息系統。2007年4月，我作為承建方合同中的項目經理，組織和實施了該企業的信息系統建設。由于該企業涉及的業務領域比較多，跨行業跨學科，各子公司

3、分布全國各地，銷售網絡遍布全國各地，信息分布散，功能要求各異，錯綜復雜，管理困難，所從事的又是科技含量高的行業，對信息的依賴性比較強，加上建設方由于有上次失敗的ERP，對這次的開發工作的工期，成本，質量要求相當苛刻，這些都給項目建設的成功蒙上了陰影，項目的前景面臨很大的風險，而項目的范圍管理也就成為我作為項目經理的重要工作。項目的范圍，是指為了完成具有所規定的特征和功能的產品必須完成的工作。項目的范圍管理，包括為完成項目所需要的一系列活動，以確保項目包含且僅僅包含項目所必須完成的工作。首先，我們根據歷史數據和初步的項目開發計劃，利用模板工具，制定一個范圍管理計劃。內容包括制定軟件開發功能設計規

4、范的過程和方法，創建WBS的過程，詳細說明已完成的開發結果如何得到正確的確認和認可，以及范圍控制管理的一些規程和制度。軟件功能范圍管理的第一步，就是對軟件功能的分析總結，即軟件開發的功能需求分析。功能需求是描述一個產品或項目應該做什么，應該提供什么功能，那些功能是必須的，那些功能不屬于項目的范圍。功能需求分析的不正確，將導致系統涉及的漏洞和錯誤，保證與用戶對需求理解的一致性，可以減少客戶對需求進行變更的頻度，模糊不清的功能需求只能造成時間，成本的浪費，最終影響項目的目標。在項目實施過程中，我們主要從8個方面來考量用戶的需求的：業務的需求、使用者的需求、功能需求、性能需求、質量需求、系統需求、非

5、功能需求，以及開發的局限。由于篇幅和時間的限制，本文只對我在項目管理的主要需求分析過程進行論述。我們軟件開發企業的市場人員，以及簽訂軟件開發合同的領導，他們對建設方的真正使用方案，在認識上有很大的不同，因此，作為軟件開發者，我們首要任務就是獲取軟件系統中，不同的使用者對信息的不同需求。對于先前失敗的ERP項目，我們詳細的分析了失敗的原因，主要是：需求分析不到位，沒有能夠滿足企業高層領導在宏觀決策上的信息需求，雖然滿足了中層領導的信息需求，但是界面設計粗糙，使得中層領導對開發的軟件抱有成見，設計缺乏人性化，缺乏對底層用戶的培訓，一般工作人員直接抵制使用軟件，加上軟件在使用過程中，也確實出現了質量

6、問題，這又成了他們抵制新開發的軟件的口實，最終導致新開發的軟件被廢棄，造成公司的巨大損失。由于有前車之鑒，我們加強了對不同層次使用軟件的用戶分別作需求獲取。我們對不同層次的用戶采取直接進行訪談，調查表的形式，借助Rose軟件，以簡單，直觀的圖形化方式，對用戶的需求進行描述。對用戶的每一需求，我們都建立一個使用方案來描述，對系統解決用戶的某一個問題所必須具備的功能，性能，使用方法，具體步驟，使用界面都作了詳細的描述。針對用戶對軟件的質量需求，我們是從軟件的可靠性、效率性、安全性、健壯性、可維護性和可測試性幾個方面來來進行的。我們從分析建設方現有的系統出發，深入企業內部的各個層次，深入了解用戶對軟

7、件的各個方面的質量要求，并把這些要求，做到有具體的數值，可量化，可驗證。我們經過對建設方的各個方面的需求進行分析和獲取，形成了了軟件開發需求分析總結書的報告文件，詳細地描述了用戶在不用方面對軟件的要求，然后根據這份報告文件，對用戶的需求進行功能設計，最終完成了軟件開發功能設計規范。設計規范，詳細描述了所開發的軟件應該滿足用戶的應有的功能，定義了開發項目的目標，項目成功的標準，項目的邊界，可交付物，進度里程碑，項目的約束條件以及假設條件等。并組織開發方和建設方的客戶代表、建設方的主管領導，對軟件開發功能設計規范進行評審確認，評審通過的設計規范，將作為合同的附屬文件，將指導和規范軟件設計開發的所有

8、工作，他是軟件開發的綱領性文件。完成需求分析后，我們組織主要開發人員，利用模板，歷史開發資料，按照項目的每個階段的里程碑和階段開發成果，自頂向下的對開發項目進行分解，把每個階段的任務分解成便于管理和控制工作包，經過對WBS的評審和確認，保證WBS的分解是充分和必要的，每個工作包都是獨立的，可以單獨進行開發和驗證，完成后WBS后，我們還對每個工作包進行時間的估算和成本的估算，并對每個工作包指派責任人。因為信息系統項目的特點，整個開發過程我們都面臨著各種各樣的需求變化，這些變化，都直接或間接的影響著項目的目標，處理不當，將會給項目的成功帶了很大的風險。為了保證項目的成功，我們建立了一套嚴格的變更控

9、制制度，針對用戶的每一項變更要求，必須提出書面申請，對變更申請，根據不同的變更級別，組織開發團隊的主要成員，上級領導，以及建設方的主要代表，對變更進行各方面的評審，如變更的必要性，技術可行性，對項目成本、進度的影響以及已完成或未完成，將要進行的別的任務的影響，根據分析結果來決定是否接受用戶的變更要求。而對于特別重大的變更，我們邀請建設方的主管領導作為變更控制中的主要成員參與對變更的評審，由于建設方重要級的領導參與，使得是否批準變更的決定，具有權威性，因此，我們在開發過程中，對于用戶合理的，必要的變更，我們積極的與客戶進行溝通，滿足他們的期望，而對于不合理的，或者沒有必要的變更要求，我們堅決給予

10、拒絕。比如，我們的開發工作接近尾聲的時候，建設方因企業的戰略需要，在印度收購了一家企業，因印度的官方語言是英語，因此要求我們的軟件系統必須支持英文版本。針對用戶的合理要求，我們邀請了雙方的高層領導，以及第三方的專家，參與對變更的評審，把變更對項目的成本，技術，進度等各種影響作了詳細的分析和核算后，大家一致決定拒絕變更的要求，并要求我們在項目完成以后，以一個新的項目來實現用戶的新要求。由于范圍變更管理作的充分，我們不僅規避了項目范圍蔓延的風險，還為組織帶來了新的開發項目。經過一年半的開發工作，我們按時保質保量的完成了項目的開發工作，由于我們加強了對項目的范圍的管理，整個開發成果順利地通過了用戶的驗收確認，并在與用戶原有的系統并行運行一個月后，目前已經獨立運行了近四個月，尚未發現系統有明顯的缺陷。鑒于我們總結了用戶上次失敗的項目，把實現用戶不同層次的需求作為項目的重要工作，因而獲得了建設方各界的好評。但是，在工作中，我們也發現了很多不足，特別是沒有考慮到用戶對語言版本的需求，以及西北網絡速度局限，造成遠程子公司與總公司交換數據時，傳輸速度低的性能需求，導致子公司對信息系統不滿，但經過我們后期對系統的調整，目前