淺析計算機軟件項目管理中的需求分析

時間：2024-09-17 05:29:05 計算機軟件畢業論文

淺析計算機軟件項目管理中的需求分析

    論文關鍵詞:需求分析　用戶方干系人　項目經理　需求分析員
　　論文摘要:計算機軟件項目管理中的需求分析是提高軟件質量的基礎也是決定一個軟件項目成敗的關鍵。本文介紹了在需求分析研究中探索出的一些有效措施。
　　眾觀國內計算機軟件業的發展，除遠不如歐美等西方發達國家外，與人均GDP不及我國的印度相比也相距甚遠，軟件業的劣勢正嚴重制約著我國IT業的發展。我國軟件業的劣勢表現在自主開發的成熟軟件不多，而開發的大量軟件工程項目(如ERP等)存在缺陷或完全開發失敗。目前，國家正在加大對軟件工程的研究和對軟件工程人才的培養。根據資料顯示，屬于需求分析造成軟件設計的錯誤和缺陷約占軟件失敗的6400，而屬于程序代碼的錯誤僅占軟件失敗的360a，數據表明需求分析是提高軟件質量的基礎也是決定一個軟件項目成敗的關鍵。通過對軟件項目管理知識的系統學習并結合近年來自己參與部分軟件項目實施的經驗，介紹在需求分析研究中探索出的一些有效措施。
　　1盡快熟悉項目用戶方干系人全貌
    項目用戶方干系人，指所有可能受到項目結果重大影響的人，即項目的風險承擔者，他可能是項目的受益者，也可能是項目的受害者。因此，應當從項目的啟動開始，需求分析員及其項目成員就要分清項目用戶方干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。
    有些項目在做需求調查時，由于受進度要求等客觀因素影響，需求分析員與建設單位的技術部門交流較多，向業務管理部門和實際使用者調查不夠深入，造成軟件試用后不得不再對需求做較大調整，“從頭再來”的部分比例很高，大大超過進度要求時間。因此，熟悉項目用戶方干系人全貌是進行需求調查的第一步，也是需求調查的基礎。在定制開發項目的項目用戶方干系人中，最重要的是建設單位中的人事組織、業務關系。最好是能夠用組織結構圖畫出相關單位的組織結構;還應當在相關單位組織結構圖基礎上畫出全體項目用戶方干系人結構圖，以便更好更全面地進行需求調研分析;用責任矩陣確定各部分的調研對象;建立調研對象通訊錄以保證調研及分析期間及時的溝通。
　　2采取正確的需求獲取方法
    軟件開發項目的目的就是要實現項目用戶方的需求，項目用戶方的需求包含明確的和隱含的，也可以分為NEED, WANT, WISH等不同的層次。如果對項目所有用戶方干系人沒有進行足夠的溝通和影響，使其盡可能地參與項目，則會出現客戶方相關責任人不明確或對范圍和需求責任心不強，提出的需求具有隨意性，項目前期對需求的確認不夠積極，或者是多個用戶代表各說各話、昨是今非，項目后期需求變化隨意等現象，這就會造成項目范圍的蔓延，進度的拖延，成本的擴大，甚至項目的完全失敗。
    各種用戶對系統具有不同的要求，如一個沒有經驗的用戶關心系統是否簡單易用，對于高級用戶則關心產品的易用性和高效性。因而需要對用戶進行分類，每一個用戶類將有自己的一系列功能和非功能要求。在項目中，要盡早為產品確定并描述不同的用戶類，這樣就能從每一個重要的用戶類代表中獲取不同的需求。
    項目需求具有雙面性(用戶與開發商)和多面性(項目中各干系人)，因此，項目經理和系統集成者應了解用戶干系人需求，用戶干系人也應了解技術方面的需求，兩者缺一不可。正確的需求獲取需要了解需求的來源、用戶的分類、用戶的代表性、用戶需求誰說了算數等因素。開發人員和項目經理要有足夠的耐心聆聽用戶的講述，要足夠詳細地了解每一個細節。項目管理者要善于將需求分類、歸類，善于將需求文檔化，并有所查詢標記。
　　3可視化需求調研，引導各種客戶挖掘他們的需求
    有的客戶因為自己缺乏計算機知識，無法提出完整準確、隱含的或潛在的需求。若這些需求不能滿足將導致用戶的不滿。因此需求調研分析人員應善于想用戶所想，不但要確定明確的需求，還要善于用啟發的方式與用戶探討隱含的或潛在的需求，并結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要盡快完整地熟悉相關業務，從而能夠站在用戶的立場看待軟件需求，想用戶所想，做好業務與計算機之間的橋梁。利用可視化需求調研的方法可以很好地啟發用戶深人挖掘潛在的需求。可視化需求調研就是使用圖表等工具來啟發引導用戶清楚地敘述需求，并且使需求更加全面完善。
    對于高層領導，可以提供系統總體框架圖;對于業務管理人員，可以用業務流程圖來描述新舊系統的業務流程;對于客戶中的技術人員，可以用數據流圖、實體關系圖或UMI中的各種圖形對系統進行各種角度的描述;而對于業務管理人員、客戶中的技術人員、以及各層次各流程中的用戶，畫出用戶界面圖來進行需求挖掘，是個比較有效的溝通方式。
    這里特別說明一下用戶界面的重要性。用戶界面的設計按理來說是軟件設計的責任，當然客戶自己對界面有特別提出要求的除外。但是，如果把它提前到需求調研時與客戶進行討論，則可以大大改善需求調研的效果。因為這時客戶對于將來的系統還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化，以筆者的經驗，畫出用戶界面草圖與客戶進行討論，可以大大激發他們提供更為準確全面的需求。原來收集資料，描述業務，說明系統模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。
　　4詳細描述各項業務，以便讓所有客戶確認
    盡可能全面詳細地調查并且描述原有系統和用戶希望將來系統具有的各項業務的流程，并將這些業務流程文檔化后與客戶進行討論，對描述錯誤或不準確不精確的進行修改，最終讓客戶進行確認。從近年來開發的軟件看，對業務處理過程了解的完整性和準確性非常重要。雖然對數據來說都是SIDUT(查增刪改傳)，但具體業務都是分為若干步驟，每個步驟都有其業務名稱，同一步驟可能對多個數據集進行不同操作，需要調查了解清楚才能設計出適合用戶業務特點和習慣的軟件，使開發出來的軟件更受歡迎。當然在進行軟件概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務節點工作作為獨立的對象，充分考慮他們與其他各種業務對象的接口，在流程之間通過業務對象的相互調用實現其業務流程，這樣，在業務流程發生有限的變化時，就能夠比較方便地修改系統程序而實現新的需求。
    對于各項業務的調查可以通過對以下資料的收集整理分析來完成，這些資料來自各種各樣的項目用戶方干系人:遵循的標準、組織發放的工作手冊、作業流程、有關業務的上級通知、有關業務的辦事指南、辦理業務時需要填寫的登記表、各種相關的統計報表及通過其他途徑收集的類似系統的介紹、技術資料等等。

　　5對項目用戶方干系人的愿望進行平衡
    不同的項目用戶方干系人其愿望和追求的目標往往相差甚遠，因此對項目用戶方干系人的愿望進行平衡可能是非常重要而又相當困難的事情。例如:我曾在參與的某醫院計算機管理系統項目中，遇到醫院管理層希望能夠采集盡可能多的信息項以便對數據進行多種多樣的統計分析，同時為了對信息進行有效控制而增加一些審批流程;而門診、藥房等對外辦公的基層窗口則因為客流速度的壓力希望減少信息項的輸人量;甚至有些不良的基層部門由于害怕建立透明度高的信息系統會影響他們的利益而消極地應付，即所謂反需求;而客戶的客戶(就診的病人)則希望相關機構能夠簡化工作流程，加快辦事速度，增加診斷情況和就診費用的透明度;甚至項目組本身因為技術、資源、進度等原因，需要對一些功能進行優先級排序和取舍。雖然不是所有人的需求都是可以滿足的，特別是消極的反需求是不能接受的，但他們的需求都是應當考慮全面并進行平衡的。
    如果不同的用戶方干系人有不一致的需求，那么必須決策出滿足哪一類用戶方干系人的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于決定哪一個用戶類所占份額更大。如果系統分析人員提出的需求與開發者所想要開發的系統發生沖突時，通常由于系統分析人員作為客戶的代理人，市場需求具有更重的分量，但是，系統分析人員不能一味地遷就客戶需求。
    不同的用戶方干系人可能都要求產品按照他們各自的喜好來設計。運用項目的業務目標來決定哪些是你最關心的客戶，非核心客戶的需求可以安排在下一個版本中開發。當開發者想像的產品與客戶需求沖突時，通常應該由客戶作出決策，然而，不要陷人“客戶總是對的”的陷阱中去，現實中，客戶并不總是對的。
　　6強調實現項目需求的層次遞進性
    了解該系統或者該項目用戶所能夠提供的最小的工程費用。當預計經費不能支持時，應當考慮將項目分期實施。在系統上、技術上對用戶進行引導性建議，使用戶了解集成商所要進行的工作，了解集成商是為了幫助用戶實現他的需要、達到用戶的目的，而不僅僅是為了賺錢，用戶更了解集成商，也更了解自己的系統，有利于以后的項目合作、工程實施和系統維護。
    分析用戶曾用系統模式、數據結構和庫模式，看是否保持、共用、轉換，這涉及保護用戶投資的問題。根據現在工作業務流情況確定現有的工作模式，還應兼顧將來可能會發生的變化、擴展、新規定，及與同國際接軌可能的帶來的變化。考查工程實施環境是否有保證，尤其是網絡工程，必須在需求調查時充分了解用戶領域的實施環境，當不具有實施環境時，要求進行配套設計和環境改造。
　　7編寫需求文擋和進行需求評審與其他項目小組成員協作完善系統需求
    文檔資料是集成商重要的財富，貫穿于系統集成和項目開發的整個過程，其中包括法律文檔、技術文檔、資料文擋。文擋要求完整性、一致性、可修改性、可跟蹤性。
    以原來的需求為基礎的工作完成后，要修補需求錯誤需要大量的工作，研究表明:比起在需求開發階段由客戶發現的一個錯誤，然后更正這一錯誤需要多花到倍的時間。因此，需要進行需求評審。需求審查結束的標準為:已經明確闡述了審查員提出的所有問題、已經正確修改了文檔、修訂過的文檔已經進行了語法檢查、所有TBD問題都已經解決、文檔歸檔。
    需求文檔完成之后，并不是把它扔給后面的設計人員就了事了。作為項目組其他成員，對需求的有效性也起到某種程度的驗證作用。雖然軟件項目的生命周期按照各種開發模型有不同階段的劃分，但每個階段的結束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟件開發項目，上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢驗，通過檢驗有時也有必要對上一階段的工作結果進行相應的調整，需求分析也是如此。因此，無論是同一階段不同人員之間，或是不同階段人員之間都應根據需要相互協作，相互配合，共同完成軟件開發任務。

【淺析計算機軟件項目管理中的需求分析】相關文章：

計算機軟件項目管理中的需求分析03-20

關于軟件項目管理中的風險分析與管理03-01

淺析如何在工作分析中滲透人本管理思想03-20