軟件項目管理研究論文

導語：軟件項目管理研究論文一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要：本文通過對軟件開發過程的各個階段中存在的問題以及解決方法進行研究，希望能夠從軟件開發過程的角度解決一些問題。

關鍵字：軟件項目管理需求分析系統設計

1.項目前期以及項目準備

在進行任何一項較大的項目時,首先要進行項目的可行性分析和研究,因為這些項目中的問題并不都有明顯的解決辦法,這樣就很難在預定的時間、費用之內解決這些問題，如果這些問題沒有可以行得通的解決辦法，貿然開始這些項目，就可能導致項目的失敗，造成巨大的損失。

1.1可行性分析

軟件項目可行性研究的目的是用最小的代價和時間，確定該項目是否能夠開發值得開發，其實質是要進行一次簡化的、抽象的需求分析和設計過程，主要應從以下幾個方面進行分析。

1.1.1技術可行性

對要開發項目的功能，性能和限制條件進行分析，確定在現有的資源條件下技術風險有多大，項目是否能夠實現，現有的資源包括硬件、軟件資源，現有的技術人員和技術水平，已經有的工作基礎等，判斷技術上是否可行，主要需要考慮以下幾個問題:

(1)開發的風險即在給定條件下能否實現目標的功能和性能；

(2)資源的有效性；

(3)技術的發展性；

由于需求未經過詳細的調研，存在模糊性和可能的變化，開發人員進行技術可行性評估時，存在比較大的風險，一旦出現估計的錯誤，將可能導致災難性的后果。

1.1.2經濟可行性

進行軟件開發項目的成本估算以及了解取得的效益估算，確定該項目是否值得開發，對于大多數項目，衡量經濟可行性，應考慮一個“底線”，同時應考慮公司的長期經營策略，潛在市場前景等因素。

1.1.3社會可行性

應考慮項目是否存在任何侵權、責任等問題，考慮在現有的制度、法規下是否行得通，包括合同、責任、法律等多種因素。

1.2需求調研

在項目前期工作中，需求調研是其中最重要的一個環節，今后的許多工作都依賴于需求調研的結果，需求調研的過程是漸進的，在可行性分析階段，主要關注的是項目規模、范圍和重點的功能，在項目進入正是開發流程以后，我們需要更加全面、準確地了解系統的需求不重視需求過程的項目隊伍將自食其果，需求工程中的缺陷將給項目成功帶來極大風險。如:無足夠用戶參與導致產品無法被接受；用戶需求的增加帶來過度的耗費和降低產品的質量；模棱兩可的需求說明可能導致時間的浪費和返工；用戶增加一些不必要的特性和開發人員畫蛇添足；過分簡略的需求說明以致遺漏某些關鍵需求；忽略某類用戶的需求將導致眾多客戶的不滿；不完善的需求說明使得項目計劃和跟蹤無法準確進行。

1.3項目團隊的組織

建立項目團隊是項目開發過程的開始，一切工作都是由項目團隊的成員完成的在整個項目的運行過程中，需要很多不同的角色參與到項目中，完成不同階段的任務。所以在建立項目團隊的過程中要把握好人員角色的劃分、特別人員管理與激勵、監督等。整個人員的管理是項目管理的關鍵，因為人是活的，而項目是死的，只要人員管理妥當，項目開發一般是不會出什么問題的。

1.4項目開發計劃

軟件項目的特征之一就是需求的不確定性和開發過程中存在的技術風險，按照通常的方法，制定一個項目的計劃應該是先根據項目的需求，進行詳細的任務分解找出實現的方法，估計出項目的工作量，再根據項目資源的狀況，制定出項目的計劃。

但是，再現實的工作中，項目的時間表往往是事先確定的，給開發留出的時間也是事先定好的。而我們能夠利用的資源，主要是開發的人力資源，也被事先基本確定了，在被確定的這2個前提條件下，我們如何根據項目的需求，合理地安排人力和時間，完成項目的開發，這是現實中項目經理經常遇到的問題如果事先確定的時間表是相對比較合理的，至少應該是我們夠的到的。我們制定的開發計劃才是有意義的，否則，按照這個時間表制定出來的計劃只能失敗的在這種情況下，項目經理唯一可以做的是對用戶的需求進行剪裁，去掉某些耗時長而且不太重要的功能，或是在開發中適當降低質量要求，或許可以完成項目的進度。當然這必須最終要得到用戶的認可。

2.項目開發過程管理

2.1詳細設計

在詳細設計階段，由于任務已經詳細地分解，總體地解決方案和技術框架已經確立，詳細設計地目的就主要是針對某個特定地模塊或對象，根據需求，技術框架地要求和模塊間接口，描述出我們實現功能的方法，主要內容包括：

（1）內部算法描述；

（2）內部數據組織；

（3）相關接口詳細設計；

2.2設計評審

在設計完成后，必須安排設計評審以保證設計的質量，通常設計評審以小組內部的評審會的方式進行，參與人有項目小組內部的人員及其負責人，由開發者介紹其設計思路，其他人了解并對其設計質量進行評審。評審的內容主

要包括：

（1）關鍵算法的可行性；

（2）接口是否符合概要設計的要求；

（3）技術清晰度是否符合設計標準；

（4）文檔的完備性；

評審通過的設計，才能夠開始編碼工作，評審的結果應記錄到開發文檔當中。

2.3編碼

在編碼階段，主要需要在編碼工作結束后，進行代碼審核，這項工作非常重要主要應該由項目小組的技術負責人完成，審核的目的并不是為了檢驗代碼的正確性而是需要對編碼是否按照規范進行審核。主要內容包括：

（1）變量、包、方法等的命名是否符合規則；

（2）注釋是否填寫完整，是否符合規范；

（3）代碼的可讀性，編寫風格是否符合規范；

（4）是否有明顯的造成系統運行低效率的處理方法；

（5）公共變量的定義和使用；

2.4調試

編碼工作完成以后，通常需要開發人員自己進行單元測試，有些部分需要編寫相應的測試程序。應該避免發生這類的情況，有些開發人員任務自己不應該進行測試工作，在編寫完代碼以后，只要編譯成功，就直接提交成果，將測試工作完全交給測試人員去做，這樣做不僅僅給測試人員增加了許多的工作量，同時增加了許多因為交流產生的時間，造成進度的延遲，管理人員應該杜絕程序員的這樣的思想，同時在管理中予以考慮，可以將提交成果產生的bug數量作為考核程序員業績的標準之一。

3.項目后期管理

3.1項目的驗收

項目驗收，是整個項目生命周期中最后一個環節。一般來說，軟件項目的驗收一般來說有2個階段，第一個階段是驗收測試，當驗收測試成功結束后，一般會有一個階段的試運行階段，只有當2個階段全部結束后，整個項目才算真正結束，可以收回全部的工程款，該軟件也進入其運行維護期。驗收測試應按照軟件的需求，質量要求進行測試驗收，需要甲乙雙方共同建立驗收小組，或請第三方測試機構進行驗收測試，在驗收測試之前，開發方應提供一系列的開發設計文檔供驗收測試使用。

3.2軟件維護

編程大師曾說“哪怕程序只有三行長，總有一天你也不得不對它維護?！?，很

多軟件產品不是一次性的買賣，比如在電信、金融等領域，有些軟件系統要用十幾年，對軟件進行維護是必不可少的，軟件公司的經理們沒有哪一個喜歡被維護的費用嚇一跳，但軟件維護的代價通常是高昂的。對軟件而言“維護”是個不太直觀的術語，因為軟件產品在重復使用時不會被磨損，并不需要進行像對車輛或電器那樣的維護，軟件維護是人們對既豐富多彩又會令人心酸的活動的統稱，其中豐富多彩的活動是指那些反映客觀世界變化，能使軟件系統更加完善的修改和擴充工作，令人心酸的活動是指那些永無休止，并且改了舊錯卻引起新錯讓人欲哭無淚的工作。

參考文獻：

1.邱菀華沈建明楊愛華等編著現代項目管理導論機械工業出版社

2002年10月

2.美理查德懷特黑德著領導軟件開發團隊電子工業出版社2002年5月

3.尼爾懷特著管理軟件開發項目-通向成功的最佳實踐電子工業出版社2002年4月

4.劉積仁康曉東饒友玲主編軟件開發項目管理人民郵電出版社

2002年2月

5.美JosephRaynus著CMM軟件過程改進指南電子工業出版社

2002年3月

6.美EvelynStillerCathieLeBlanc著基于項目的軟件工程面向對象研究方法機械工業出版社2002年6月