當(dāng)前位置:工程項目OA系統(tǒng) > 泛普各地 > 黑龍江OA系統(tǒng) > 哈爾濱OA系統(tǒng) > 哈爾濱OA快博
軟件開發(fā)項目需求管理簡述
前言
在軟件項目的開發(fā)過程中,需求變更貫穿了軟件項目的整個生命周期,從軟件的項目立項,研發(fā),維護(hù),用戶的經(jīng)驗在增加,對使用軟件的感受有變化,以及整個行業(yè)的新動態(tài),都為軟件帶來不斷完善功能,優(yōu)化性能,提高用戶友好性的要求。在軟件項目管理過程中,項目經(jīng)理經(jīng)常面對用戶的需求變更。如果不能有效處理這些需求變更,項目計劃會一再調(diào)整,軟件交付日期一再拖延,項目研發(fā)人員的士氣將越來越低落,將直接導(dǎo)致項目成本增加、質(zhì)量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。
二、需求管理復(fù)雜性分析
軟件需求是整個軟件開發(fā)項目的最關(guān)鍵的一個輸入,和傳統(tǒng)的生產(chǎn)企業(yè)相比較,軟件的需求具有模糊性、不確定性、變化性和主觀性的特點,他不像生產(chǎn)汽車、電腦等硬件的需求,是有形的、客觀的、可描述的、可檢測的,軟件需求是軟件項目最難把握的問題,他的復(fù)雜性體現(xiàn)在以下方面:
1、需求的描述問題。缺少正式的完整的需求文檔浪費了大量的人力物力,但是有了需求文檔又出現(xiàn)了新的問題。在用戶方進(jìn)行的需求評審會完全是走形式,因為用戶根本不去聽他讀那上百頁的需求文檔。不同層次的客戶(用戶)關(guān)心的問題是不一樣的,想要每個客戶都成為需求專家是不現(xiàn)實的。
2、需求的完備程度問題。需求如何做到?jīng)]有遺漏?如何準(zhǔn)確劃定系統(tǒng)的范圍?這確實是一個兩難問題,稍微大一點的系統(tǒng)要想窮舉需求幾乎是不可能的,每次開需求評審會時,總會冒出新的需求,以至于系統(tǒng)沒有一個準(zhǔn)確的范圍界定。即使是這樣,系統(tǒng)還是要開發(fā),沒辦法,系統(tǒng)的范圍還要硬性的劃定一個,從而建立一個基線。
3、需求開發(fā)的工期問題。在需求上花費了大量的時間,客戶、軟件公司是否能夠忍受?為了確保需求的正確性,完備性,項目經(jīng)理往往堅持要在需求階段花費大量的時間,但是客戶與公司的高層領(lǐng)導(dǎo)卻會為項目遲遲看不到實際可運行的軟件擔(dān)心不已!他們往往會逼迫項目組盡快往前推進(jìn),而項目組的成員往往也會為系統(tǒng)復(fù)雜的善變的需求折騰的筋疲力盡,他們也希望盡快結(jié)束此階段。
4、需求的細(xì)致程度問題。需求到底描述到多細(xì),才算可以結(jié)束了?仁者見仁,智者見智,并沒有定論,如果時間允許,要想細(xì)總可以細(xì)下去的。但是,需求的周期越長,可能的變化越多,對設(shè)計的限制越嚴(yán)格,對需求的共性提取要求越高,所以只要大家(客戶、用戶、需求分析人員、設(shè)計人員、測試人員)認(rèn)為描述清楚了,就可以進(jìn)入設(shè)計階段了。
5、需求的變化問題。在軟件開發(fā)過程中如果只有一條真理的話,那一定是:需求的變化是永恒的,需求不可能是完備的。軟件開發(fā)的過程實際上是同變化做斗爭的過程,需求的變更不一定是壞事,也有可能是好事,是商業(yè)機(jī)會,對市場敏感的人可以從需求的變化中發(fā)現(xiàn)市場機(jī)會。
需求變化的原因很多,如:
一開始沒有識別全,需要增加需求;
業(yè)務(wù)發(fā)生了變化,需求必須變化;
需求錯誤;
需求不清楚。
需求的變化問題是每個開發(fā)人員、每個項目經(jīng)理都遇到的問題,也是最頭痛的問題,一旦發(fā)生了需求變化,你不得不來修改你的設(shè)計、重寫你的代碼、修改你的測試用例、調(diào)整你的項目計劃等等,需求的變化好比是萬惡之源,為項目的正常的進(jìn)展帶來不盡的麻煩,怎么辦?管理它!使需求在受控的狀態(tài)下發(fā)生變化,而不是隨意變化,需求管理就是要按照標(biāo)準(zhǔn)的流程來控制需求的變化。難題隨之而來,需求中的變化一般不是突發(fā)的革命性的變化,最常見的是項目需求的漸變(Project Scope Creep)問題,這種漸變很可能是客戶與開發(fā)方都沒有意識到的,當(dāng)達(dá)到一定層度時,雙方才驀然回首,發(fā)現(xiàn)已經(jīng)物是人非,換了一番天地。
三、需求管理策略
需求管理需要遵守以下策略:
1、需求一定要與投入有必然的聯(lián)系。
需求一定要與投入有必然的聯(lián)系,否則如果需求變更的成本由開發(fā)方來承擔(dān),則項目需求的變更就成為必然了。人們常說世上沒有免費的午餐,同樣也不應(yīng)該有免費的需求變更。但是,接受需求變更目前卻是軟件開發(fā)商不得不咽下的苦果。所以,在項目的開始無論是開發(fā)方還是出資方都要明確這一條:需求變,軟件開發(fā)的投入也要變。
2、需求的變更要經(jīng)過出資者的認(rèn)可。
需求的變更引起投入的變化,所以要通過出資者的認(rèn)可,這樣才會對需求的變更有成本的概念,能夠慎重地對待需求的變更。筆者曾經(jīng)經(jīng)歷過一個項目,為了避免項目的風(fēng)險,我們請了用戶代表全程參與了開發(fā)過程,結(jié)果此用戶代表在開發(fā)過程提出了大量“小的需求變更,當(dāng)開發(fā)人員按此需求變更修改了軟件時,在項目進(jìn)入現(xiàn)場實施階段時,卻有大量的這些變更需要改回去,問題就是出在我們的項目組成員視該用戶代表的需求為圣旨,卻忽略了需求是否經(jīng)過了客戶方真正有決策權(quán)的人員的認(rèn)可。
3、小的需求變更也要經(jīng)過正規(guī)的需求管理流程。
小的需求變更也要經(jīng)過正規(guī)的需求管理流程,否則會積少成多。在實踐中,人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程,認(rèn)為降低了開發(fā)效率,浪費了時間。正式由于這種觀念才使需求的漸變不可控,最終導(dǎo)致項目的失敗。
4、精確的需求與范圍定義并不會阻止需求的變更。
并非對需求定義的越細(xì),越能避免需求的漸變,這是2個層面的問題。太細(xì)的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的,并非由于需求寫細(xì)了,它就不會變化了。注意溝通的技巧。實際情況是用戶、開發(fā)者都認(rèn)識了到了上面的幾點問題,但是由于需求的變更可能來自客戶方、也可能來自開發(fā)方,作為客戶他們可能不愿意為需求的變更付出更多的投資,開發(fā)方有可能是主動的變更了需求,他們的目的可能是使軟件做的更精致,于是作為需求管理者、項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。
基于上述的問題,必須對需求進(jìn)行管理,使需求能夠真正成為軟件工程和管理的基線,使軟件計劃、活動和工作產(chǎn)品同軟件需求保持一致,使需求可以復(fù)用。
來源:中國經(jīng)理
- 1用供應(yīng)鏈技術(shù)實現(xiàn)企業(yè)內(nèi)部信息流動
- 2渠道別搬起石頭砸了自有產(chǎn)品的腳
- 3知識管理是一種持續(xù)的實踐
- 4管理會計動態(tài)成本體系構(gòu)建的訴求
- 5不識水性的民企如何趟過信息化的河
- 6如何提高員工企業(yè)信息安全意識
- 7企業(yè)績效管理走出理念到應(yīng)用
- 8APS算法之六禁忌搜索TS(上)
- 9比爾·蓋茨:視信息技術(shù)為一種戰(zhàn)略資源
- 10擺脫企業(yè)存儲的困擾:建立動態(tài)存儲新架構(gòu)
- 11日企的本地化的信息系統(tǒng)建設(shè)
- 12掀開幕布看PDM:產(chǎn)品數(shù)據(jù)管理系統(tǒng)的概念與應(yīng)用
- 13OA多應(yīng)用服務(wù)器方案---僅供XX參考
- 14神州數(shù)碼3年實踐:標(biāo)準(zhǔn)化使ERP實施普遍成功
- 15從業(yè)務(wù)流程角度理解面向服務(wù)的概念
- 16管理無定式
- 17解密DSL的QoS
- 18企業(yè)信息門戶商業(yè)功能和服務(wù)的雙軌
- 19無線局域網(wǎng)的未來
- 20IT項目需要周全的交流計劃
- 21企業(yè)CIO在OA方面只能有三種選擇
- 22“維客”世界中的隱性“把關(guān)人”
- 23并行工程集成框架
- 24構(gòu)建EKM框架三步走
- 25VoIP一部好車卻為什么賣不出好價?
- 26企業(yè)成功經(jīng)驗:“可的”信息化變革
- 27中小企業(yè)與大企業(yè)競爭行動的比較研究
- 28PLM如何實現(xiàn)對SCM、CRM、ERP的整合
- 29下一代流程管理的夢想
- 30存儲網(wǎng)絡(luò)Exchange數(shù)據(jù)庫移動
成都公司:成都市成華區(qū)建設(shè)南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓