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