1、精選優質文檔-傾情為你奉上軟件項目開發過程中的需求分析和范圍管理0 引言對于一個軟件系統的開發來說,最困難的部分就是準確說明開發什么,最困難的概念性工作就是編寫出詳細的需求,包括所有面向用戶、面向機器和其它軟件系統的接口。此工作一旦出現紕漏,將會給系統帶來極大的損害,并且以后對它修改也極為困難。所以,需求是整個軟件產品鏈的源頭,需求工作的優劣將直接影響到產品的設計、生產、銷售和維護的全過程。而對于項目中哪些該做,哪些不該做,做到什么程度,則都是由范圍管理來決定的。軟件項目開發過程中,花費大量時間用于需求調研和分析,也都是為了準確控制好項目范圍,以便于對整個項目的進行實施有效的管理。所以說,明確

2、的需求、準確的項目范圍控制和管理,是項目成功的基礎所在。1 需求分析項目管理培訓需求分析是一個項目的開端,也是項目建設的基石。由于需求不明確而造成項目產生風險甚至失敗的比例是相當高的。因此一個項目成功的關鍵因素之一,就是對需求的把握程度,即所謂的需求開發與管理。1.1 需求開發與管理的概念需求分析的過程包括了需求開發和需求管理兩個部分。需求開發指的是從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動,這幾個階段的活動可以是相互獨立和反復的,不一定非要遵循線性的順序。需求管理則是與需求直接相關的活動,即軟件項目開發過程中控制和維持需求約定的活動,主要包括:變更控制、版本控制、需求跟蹤、

3、需求狀態跟蹤等工作。和傳統的產業相比,由于軟件項目的需求具有模糊性、不確定性、變化性和主觀性的特點,它不像生產汽車、電腦硬件的需求,是有形的、客觀的、可描述的、可檢測的,同時由于需求分析的參與人員、業務模式、投資、時間等客觀因素的影響,造成了軟件需求分析是軟件項目開發中最難把握的問題。需求分析工作的復雜性及面臨的潛在風險主要體現在以下方面: (1)需求描述的準確性問題; (2)需求的完備程度問題; (3)需求開發的時間問題; (4)需求的細化程度問題; (5)需求的變更問題。1.2 需求變更在軟件開發過程中需求的變化是永恒的,需求不可能是完備的,軟件開發的過程實際上是同變化做斗爭的過程,而造成

4、需求變化的原因也有很多。比如:隨著項目的進展,開發方和客戶方對需求的了解越來越深入,原先的需求文檔可能存在這樣或那樣的錯誤和不足,因此要變更需求;由于市場和業務發生了變化,原先的需求文檔可能跟不上當前市場的要求,因此要變更需求等等。需求的變化問題是每個開發人員、項目經理都會遇到的問題,需求的變更不一定是壞事,常常提出需求變更的動機是好的,目的是希望產品更加符合用戶的需求。但是一旦需求發生了變化,隨之而來的將是不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等問題,對項目開發小組而言,變更需求意味著要調整資源、重新分配任務、修改前期工作成果等,這將為項目的正常進展帶來諸多的麻煩,開發小組也要

5、為此付出較重的代價。如果每次需求變更請求都被采納的話,這個項目也許永遠不能按時完成。而在需求變更過程中最難辦的事情是莫過于拒絕客戶提出的需求變更請求,通常情況下開發方是不敢得罪客戶的,但是無原則地退讓將使開發小組陷入困境。解決這個問題最好的辦法是事先將需求分析工作盡量做完備,即在需求分析上遵循一定的方法步驟,在需求管理上遵循一定的策略。1.3 需求分析的步驟在需求分析工作上應定位三個階段。第一階段:訪談式。這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通,主要目的是從宏觀上把握用戶的具體需求方向和趨勢,了解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等具體情況、客觀的信息

6、,建立起良好的溝通渠道和方式。第二階段:誘導式。這一階段是在開發方已經了解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等具體實際、客觀的信息基礎上,結合現有的硬件、軟件實現方案,做出簡單的用戶流程頁面,同時結合以往的項目經驗對用戶采用誘導式、啟發式的調研方法和手段,和用戶一起探討業務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO,來感受一下整個業務流程的設計合理性、準確性等問題,及時地提出改進意見和方法。第三階段:確認式。這一階段是在上述兩個階段成果的基礎上,進行具體的流程細化、數據確認。這個階段開發方必須提供原型系統和明確的業務流程報告、數據

7、項表,并能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及承建方提供的DEMO系統,來提出反饋意見,并對已經可接受的報告、文檔簽字確認。三個階段或者說三步法的實施和采用,對用戶和承建方都同樣提供了項目成功的保證。1.4 需求管理的策略在需求管理上應遵循以下策略: (1)需求一定要與投入有必然的聯系,否則如果需求變更的成本由開發方來承擔,則項目需求的變更就成為了必然。在項目的開始無論是開發方還是出資方都要明確這點:需求發生變化,軟件開發的投入也要變。(2)需求的變更要經過出資者的認可。需求的變更將引起投入的變化,所以要通過出資者的認可,這樣才會對需求的變更有成本

8、的概念,能夠慎重地對待需求的變更。(3)小的需求變更也要經過正規的需求管理流程。小的需求變更也要經過正規的需求管理流程,否則會積少成多。在實踐中,人們往往不愿意為小的需求變更去執行正規的需求管理過程,認為降低了開發效率,浪費了時間。正是由于這種觀念才使需求的漸變不可控,最終導致項目的失敗。(4)精確的需求與范圍定義并不會阻止需求的變更。并非對需求定義的越細,越能避免需求的漸變,這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果,因為需求的變化是永恒的,并不會因為需求寫細了,它就不變化了。(5)注意溝通的技巧。實際情況是用戶、開發者都認識了到了上面的幾點問題,但是由于需求的變更可能來自客戶

9、方、也可能來自開發方,作為客戶他們可能不愿意為需求的變更付出更多的投資,開發方有可能是主動的變更了需求,他們的目的可能是使軟件做的更精致,于是作為需求管理者、項目經理需要采用各種溝通技巧來使項目的各方各得其所。基于上述的問題,必須對需求進行管理,使需求能夠真正成為軟件工程和管理的基線,使軟件計劃、活動和工作產品同軟件需求保持一致,使需求可以復用。1.5 監理方責任為了保證項目的成功,作為第三方的監理公司也必須加強項目管理和項目分析工作,要提醒開發方、客戶方重視需求分析的重要性,采用必要的手段和方法來進行需求調研。在原則上,需求階段監理應尊重承建方的項目管理和項目分析能力;在具體的任務開展上,以

10、不深入、不干擾承建方的自主權為主,除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足;在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。只有這樣才能切切實實地把握用戶的需求和方向,才能在將來的功能界定、開發范圍上有發言權。2 范圍管理對于項目中哪些該做,哪些不該做,做到什么程度等問題,都是由范圍管理來決定的。與需求相關的一系列問題,都屬于項目范圍管理的問題。2.1 產品范圍與項目范圍項目管理論壇項目中花費大量時間和精力用于需求調研分析,也是為了確定項目范圍。范圍的概念應包含兩個方面,一個是產品范圍,即產品或服務所包含的特征或功能;另一個是項目范圍,即為交付具有規定特

11、征和功能的產品或服務所必須完成的工作。在確定范圍時首先要確定最終產生的是什么,它具有哪些可清晰界定的特性。要注意的是特性必須要清晰,以認可的形式表達出來,比如文字、圖表或某種標準,能被項目參與人理解,絕不能含含糊糊、模棱兩可,在此基礎之上才能進一步明確需要做什么工作才能產生所需要的產品。也就是說有了明確的產品范圍,才可以確定為達到這個目的需要做哪些工作,即項目范圍,換句話說產品范圍決定項目范圍。2.2 范圍管理實施方法如何做好范圍管理,應注意做好以下幾方面的工作: (1)編制范圍說明和范圍管理計劃; (2)范圍分解; (3)范圍變更控制。項目經理圈子2.2.1 編制范圍計劃具體的說,范圍說明是

12、在項目參與人之間確認或建立了一個項目范圍的共識,作為未來項目決策的文檔基準。范圍說明中至少要說明項目論證、項目產品、項目可交付成果和項目目標。范圍管理計劃是描述對項目范圍如何進行管理、項目范圍怎樣變化才能與項目要求相一致等問題的。它也應該包括一個對項目范圍預期的穩定而進行的評估。范圍管理計劃還應該包括對變化范圍怎樣確定以及對變化應歸為哪一類等問題的清楚描述。2.2.2 范圍分解完成項目是一個復雜的過程,計劃明確了,還應采取分解的手段把主要的可交付成果分成更容易管理的單元才能一目了然,最終得出項目的工作分解結構(WBS)。比較常用的方式是以項目進度為依據劃分WBS,第一層是大的項目成果框架,每層下面再把工作分解,這種方式的優點是結合進度劃分,直觀、時間感強,評審中容易發現遺漏或多出的部分,也更容易被大多數人理解。2.2.3 范圍變更管理項目經理博客一個項目的范圍計劃可能制訂的非常好,但是想不出現任何改變幾乎是不可能的,因此對變更的管理是項目經理必備的素質之一。變更并不可怕,糟糕的是缺乏規范的變更管理過程。范圍變更的