原型法破解小型軟件項(xiàng)目需求分析之痛
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
軟件項(xiàng)目需求分析是一個(gè)項(xiàng)目的開端,也是一個(gè)項(xiàng)目建設(shè)的基石。在失敗的開發(fā)項(xiàng)目中,80%是由于需求分析的不明確而造成的。因此,一個(gè)軟件開發(fā)項(xiàng)目想要成功的關(guān)鍵就是要做好需求分析。這是我經(jīng)過在上個(gè)月不堪回首的痛苦折騰后,才深深領(lǐng)悟到的真意。在這里我想把在這個(gè)項(xiàng)目得到的教訓(xùn)和經(jīng)驗(yàn)與大家分享。
在上個(gè)月,公司委派我負(fù)責(zé)一個(gè)小型的軟件開發(fā)項(xiàng)目。在接手這個(gè)項(xiàng)目時(shí),我看到該項(xiàng)目的需求比較簡單,于是想當(dāng)然的就直接開始工作了。結(jié)果是由于在開發(fā)初期忽視了與用戶的信息溝通和深度需求分析,不但導(dǎo)致系統(tǒng)開發(fā)出來后不能很好地滿足用戶的需求,而且頻繁的需求變更返工不僅在技術(shù)上給開發(fā)人員帶來了巨大的麻煩,也使到軟件性能深受影響且造成人力、物力的浪費(fèi)。 輕視小型軟件項(xiàng)目需求分析之痛 一個(gè)軟件項(xiàng)目的開發(fā)主要分為五個(gè)階段:需求分析階段、設(shè)計(jì)階段、編碼階段、測(cè)試階段和維護(hù)階段。需求分析階段所得到的結(jié)果是軟件開發(fā)其它四個(gè)階段的必備條件。從這次項(xiàng)目的經(jīng)驗(yàn)來看,只要需求分析中有一個(gè)小小的偏差,就可能會(huì)導(dǎo)致整個(gè)項(xiàng)目無法達(dá)到預(yù)期的效果,或者說最終開發(fā)出的產(chǎn)品不是用戶所需要的。 因此,需求分析在許多大型軟件開發(fā)中都得到了很好的重視,但讓人遺憾的是在小型軟件項(xiàng)目中往往會(huì)認(rèn)為需求很簡單從而很容易就忽視了需求分析這個(gè)重要的步驟。教條主義式的經(jīng)驗(yàn)使我在這個(gè)項(xiàng)目上犯了這個(gè)錯(cuò)誤,結(jié)果是讓我付出了更多的心力和更大的代價(jià)。反思這次的項(xiàng)目需求分析階段,我主要犯有以下幾個(gè)失誤: (1)輕視用戶和開發(fā)人員之間的溝通 在軟件開發(fā)過程中主要有兩種角色:用戶和開發(fā)人員。需求獲取和需求調(diào)研是雙方溝通的第一步。在小型軟件項(xiàng)目中,由于雙方都認(rèn)為項(xiàng)目需求比較簡單,就會(huì)對(duì)需求的描述產(chǎn)生一定的輕視,從而只用幾句簡單的話來描述。但實(shí)際上即使需求調(diào)研時(shí)用了詳細(xì)的文字很完善的說明后,用戶與開發(fā)人員之間還是會(huì)存在著或多或少的理解差異。因?yàn)槲淖中缘拿枋隹偸侨狈_性,更何況只是幾句簡單的描述。 實(shí)際上,就算是小型開發(fā)項(xiàng)目,其需求獲取也可能是最困難、最關(guān)鍵、最易出錯(cuò)的方面。原因是用戶可能會(huì)對(duì)軟件開發(fā)過程不熟悉,或?qū)ψ约旱男枨蟊磉_(dá)不清楚,而開發(fā)人員則對(duì)用戶的業(yè)務(wù)流程不熟悉。在這種場(chǎng)合下,開發(fā)人員如果單單通過問/答的方式,或者更惡劣一點(diǎn)--只聽不問的方式,是無法獲取到真正需求的。因?yàn)橛袝r(shí)候連客戶自己也不清楚自己想要的是什么。還有用戶表達(dá)的同一需求,不同的需求調(diào)研人員也可能會(huì)有不同的理解。而如果需求調(diào)研人員理解錯(cuò)了,就可能會(huì)導(dǎo)致以后的開發(fā)工作勞而無功。所以,如果因?yàn)樾枨蠛唵尉洼p視的話,必然會(huì)導(dǎo)致后期大量的返工和修改。 (2)需求在開發(fā)前沒有被準(zhǔn)確地描述 在反思這次項(xiàng)目的失敗原因時(shí),我發(fā)現(xiàn)有時(shí)連客戶對(duì)自己的需求也只有朦朧的感覺,或常常也說不清楚具體的需求。例如,用戶可能很善于敘述其目標(biāo)、對(duì)象以及他們想要前進(jìn)的大致方面,但對(duì)于他們想要實(shí)現(xiàn)的細(xì)節(jié)卻不甚清楚和難以確定。于是用戶就會(huì)要求需求分析人員替他們?cè)O(shè)想需求,但需求分析人員要想詳細(xì)而精確的定義用戶心中的需求無疑是很困難的。結(jié)果是我們開發(fā)完成后,客戶卻認(rèn)為這不是他們需要的。這種事情一而再,再而三的發(fā)生。不但讓我們的開發(fā)人員哭笑不得,而且還無言以對(duì)。 (3)用戶需求變更頻繁,造成開發(fā)模式日漸紊亂 隨著時(shí)間的推移,用戶會(huì)對(duì)系統(tǒng)的界面、功能和性能等方面提出更高更多的要求。例如,在開發(fā)項(xiàng)目過程中,用戶隨時(shí)會(huì)提出一些新的需求,有時(shí)是在開發(fā)階段中,有時(shí)在開發(fā)階段后。而且,這些需求往往是后一次的需求與前一次不一致,也就是所謂的需求變更。后果是在開發(fā)中不斷補(bǔ)充的需求使到項(xiàng)目越變?cè)烬嫶?,以致超過其計(jì)劃及預(yù)算范圍。 正常的需求變更本來也沒有什么大事情,但由于我們?cè)陂_發(fā)模式上沒有對(duì)需求修改有足夠的準(zhǔn)備,結(jié)果是頻繁的變更把整體結(jié)構(gòu)變得日漸紊亂,補(bǔ)丁代碼使得整個(gè)程序難以理解和維護(hù)。不但插入的補(bǔ)丁代碼使模塊違背強(qiáng)內(nèi)聚、松耦合的設(shè)計(jì)原則,而且不斷的收回變更和刪除特性導(dǎo)致了更多的問題,例如出現(xiàn)軟件質(zhì)量明顯下降等現(xiàn)象。 原型法工具使項(xiàng)目浴火重生 看著日漸走向失敗的項(xiàng)目,一籌莫展的我心里是哪個(gè)的焦急。這時(shí),一位資深的軟件需求分析前輩提示我,為何不嘗試一下原型法工具。后來,我在應(yīng)用原型法進(jìn)行需求分析后,項(xiàng)目才得以起死回生。真所謂是:山窮水復(fù)疑無路 柳暗花明又一村;不經(jīng)一事,不長一智。 (1)什么是開發(fā)項(xiàng)目的需求分析? 軟件開發(fā)中最為困難的是要準(zhǔn)確知道應(yīng)該要開發(fā)些什么。因?yàn)橐坏┬枨蠓治鲎鲥e(cuò)了,不但會(huì)給系統(tǒng)功能帶來極大的損害,并且不斷的修改也會(huì)浪費(fèi)資源。有資料表明,現(xiàn)在的軟件項(xiàng)目中返工開銷幾乎占了總開發(fā)的一半,而導(dǎo)致返工的主要原因就是需求分析不明確。 軟件需求分析(software requirement analysis)是一個(gè)項(xiàng)目的開端,也是項(xiàng)目最重要的關(guān)鍵點(diǎn)。它的定義是指研究用戶想要得到的東西,完全理解用戶對(duì)軟件需求的完整功能,確認(rèn)用戶軟件功能需求,并建立可確認(rèn)的、可驗(yàn)證的一個(gè)基本依據(jù)。曾有調(diào)查報(bào)告顯示,軟件產(chǎn)品存在不完整性、不正確性等問題,80%以上是由于需求分析錯(cuò)誤所導(dǎo)致的,而且由于需求分析錯(cuò)誤造成功能性問題尤為突出。所以,一個(gè)成功的需求分析是軟件項(xiàng)目能否成功的關(guān)鍵一步。因此,在軟件開發(fā)中產(chǎn)生了一個(gè)核心問題:如何在用戶需求不明確的情況下進(jìn)行系統(tǒng)開發(fā)? (2)什么是原型法? 軟件需求分析方法有很多,如傳統(tǒng)方法、原型方法、模型驅(qū)動(dòng)方法、結(jié)構(gòu)化方法等。一般來說,選擇那種方法要根據(jù)項(xiàng)目的具體情況和資源來選擇,不能盲目套用。這里著重闡述原型法。 原型法(prototyping)的理念是指在獲取一組基本需求之后,快速地構(gòu)造出一個(gè)能夠反映用戶需求的初始系統(tǒng)原型。讓用戶看到未來系統(tǒng)的概貌,以便判斷哪些功能是符合要求的,哪些方面還需要改進(jìn),然后不斷地對(duì)這些需求進(jìn)一步補(bǔ)充、細(xì)化和修改。依次類推,反復(fù)進(jìn)行,直到用戶滿意為止并由此開發(fā)出完整的系統(tǒng)。簡單的說,原型法就是不斷地運(yùn)行系統(tǒng)的"原型"來進(jìn)行揭示、判斷、修改和完善需求的分析方法。 (3)原型需求分析法的特點(diǎn) 原型法是一種循環(huán)往復(fù)、螺旋式上升的工作方法,它更多地遵循了人們認(rèn)識(shí)事物的規(guī)律,因而更容易被人們掌握和接受。原型法強(qiáng)調(diào)用戶的參與,特別是對(duì)模型的描述和系統(tǒng)需求的檢驗(yàn)。它強(qiáng)調(diào)了用戶的主導(dǎo)作用,通過開發(fā)人員與用戶之間的相互作用,使用戶的要求得到較好的滿足。不但能及時(shí)溝通雙方的想法,縮短用戶和開發(fā)人員的距離。而且能更及時(shí)、準(zhǔn)確的反饋信息,使?jié)撛趩栴}能盡早發(fā)現(xiàn)并及時(shí)解決,增加了系統(tǒng)的可靠性和適用性。 簡單的說,原型法是將系統(tǒng)調(diào)查、系統(tǒng)分析和系統(tǒng)設(shè)計(jì)合而為一,使用戶一開始就能看到系統(tǒng)開發(fā)后是一個(gè)什么樣子。而且用戶參與了系統(tǒng)全過程的開發(fā),知道哪些是有問題的,哪些是錯(cuò)誤的,哪些需要改進(jìn)等,就能消除用戶的擔(dān)心,并提高了用戶參與開發(fā)的積極性。同時(shí),用戶由于參與了開發(fā)的過程將有利于系統(tǒng)的移交、運(yùn)行和維護(hù)。 但需要注意的是,原型法的適用范圍是比較有限的。它只對(duì)于小型、簡單、處理過程比較明確、沒有大量運(yùn)算和邏輯處理過程的系統(tǒng)比較合適。它的局限性是對(duì)于大型的系統(tǒng)不太適合,因?yàn)閷?duì)于需要大量的運(yùn)算、邏輯性較強(qiáng)的程序模塊,原型法是很難通過簡單的了解就構(gòu)造出一個(gè)合適的模型,供用戶評(píng)價(jià)和提出修改建議。 使用原型法進(jìn)行需求分析的流程 (1)快速分析,弄清用戶的基本信息需求 需求分析原型法的第一步是在需求分析人員和用戶的緊密配合下,快速確定軟件系統(tǒng)的基本要求。也就是把原型所要體現(xiàn)的特性(界面形式、處理功能、總體結(jié)構(gòu)、模擬性能等)描述出一個(gè)基本的規(guī)格說明??焖俜治龅年P(guān)鍵是要選取核心需求來描述,先放棄一些次要的功能和性能。盡量圍繞原型目標(biāo),集中力量確定核心需求說明,從而能盡快開始構(gòu)造原型。 這個(gè)步驟的目標(biāo)是要寫出一份簡明的骨架式說明性報(bào)告,能反映出用戶需求的基本看法和要求。這個(gè)時(shí)候,用戶的責(zé)任是先根據(jù)系統(tǒng)的輸出來清晰地描述自己的基本需要,然后分析人員和用戶共同定義基本的需求信息,討論和確定初始需求的可用性。 (2)構(gòu)造原型,開發(fā)初始原型系統(tǒng) 在快速分析的基礎(chǔ)上,根據(jù)基本規(guī)格說明應(yīng)要盡快實(shí)現(xiàn)一個(gè)可運(yùn)行的系統(tǒng)。我在這個(gè)項(xiàng)目得到的經(jīng)驗(yàn)是原型系統(tǒng)可先考慮原型系統(tǒng)應(yīng)必備的待評(píng)價(jià)特性,暫時(shí)忽略一切次要的內(nèi)容。例如安全性、健壯性、異常處理等。如果這時(shí)為了追求完整而把原型做得太大的話,一是需要的時(shí)間太多,二是會(huì)增加后期的修改工作量。因此,提交一個(gè)好的初始原型需要根據(jù)系統(tǒng)的規(guī)模、復(fù)雜性和完整程度的不同而不同。本步驟的目標(biāo)是:建立一個(gè)滿足用戶的基本需求并能運(yùn)行的交互式應(yīng)用系統(tǒng)。在這一步驟中用戶沒有責(zé)任,主要由開發(fā)人員去負(fù)責(zé)建立一個(gè)初始原型。 (3)用戶和開發(fā)人員共同評(píng)價(jià)原型 這個(gè)階段是雙方溝通最為頻繁的階段,是發(fā)現(xiàn)問題和消除誤解的重要階段。其目的是驗(yàn)證原型的正確程度,進(jìn)而開發(fā)新的原型并修改原有的需求。由于原型忽略了許多內(nèi)容和細(xì)節(jié),雖然它集中反映了許多必備的特性,但外觀看起來還是可能會(huì)有些殘缺不全。因此,用戶可在開發(fā)人員的指導(dǎo)下試用原型,在試用的過程中考核和評(píng)價(jià)原型的特性,也可分析其運(yùn)行結(jié)果是否滿足規(guī)格說明的要求,和是否滿足用戶的愿望。并可糾正過去溝通交流時(shí)的誤解和需求分析中的錯(cuò)誤,增補(bǔ)新的要求,或提出全面的修改意見。 總的來說,原型法是通過強(qiáng)化用戶參與系統(tǒng)開發(fā)的過程,讓用戶獲得系統(tǒng)的親身體驗(yàn),找出隱含的需求分析錯(cuò)誤。原型需求分析法是鼓勵(lì)改進(jìn)和創(chuàng)造,通過不斷交流來提高需求實(shí)現(xiàn)的質(zhì)量和軟件產(chǎn)品的質(zhì)量,目的是為了更好的提高客戶滿意度。 該文章在 2010/7/25 1:58:22 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |