軟件項目開發是一項系統而復雜的工作 它需要一個團隊互相配合、分工協作。軟件項目管理系統可以規范一個軟件開發團隊的日常工作，下面是關于軟件項目管理論文，歡迎借鑒！
隨著信息技術的飛速發展，軟件產品的規模也越來越龐大,各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。但國內軟件企業對于軟件項目的認知，在一定程度上盲目多于理性、理論多于實踐。鑒于上述問題，本文分析了基于項目管理的軟件開發過程需要注意的幾個問題。
1需求開發要注意的問題
需求開發作為軟件項目啟動的初始工作有兩個目標:發現真正的需求并以適合于用戶和開發人員的方式加以表述。
發現需求即需求獲取,“真正的需求”是指在實現時可以給用戶帶來預期價值的需求“;以適合于用戶和開發人員的方式”即需求定義,主要是指對需求的最后描述必須讓用戶和開發人員無歧義的理解。在需求開發過程,軟件開發人員要注意如下的兩個問題:
1.1 不要忽視非功能需求
通常，需求分析人員更多的關注功能需求，而忽視非功能需求，從而導致 NV[2]( 即“下一版本”) 陷阱。陷入 NV 陷阱后，產品的質量會大打折扣，甚至“拿不出手”。另外，不完整的需求也容易導致架構的錯誤設計，如:1.1.1 XX 查詢的響應時間必須小于 1 秒;1.1.2 并發用戶的數量每小時超過 10000個用戶對于此類性能方面的非功能需求，直接影響到架構中持久層設計所采用的技術，而且這種架構上的缺陷實際上很難在“下一版本”輕易的改變。為了防止陷入 NV 陷阱，非功能性需求從一開始就要被提出來，和功能性需求一樣受到應有的重視。如果這些非功能性需求是確實需要的，就應該被寫入需求規格書，并在產品開發過程中接受實現狀況的檢查。
1.2 正確面對需求變更
在大多數軟件項目中最不穩定的部分就是需求。在項目需求分析階段，必需全面的、應盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其它軟件的接口要求，以及對項目進行評估的各種評價標準。但由于各方面的原因用戶需求始終處在一個持續變化的狀態中，這是項目開發人員必須的接收的事實。那么對于這樣的現狀，軟件開發者該怎么辦呢? 其一是把需求變化控制在最小的范疇，在需求變化發生之前盡量減少需求變化; 其二是在設計軟件體系結構時，不僅應該想到如何滿足現在已經提出的用戶需求,同時也應適當地考慮到需求的變更，想辦法應對需求變化，例如:采用面向對象的思想。世界都是由對象組成的，而對象都是持久的。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因為企業的模式一旦變化，只需要將穩定的企業對象重新組織就行了。這種開發的方法就被稱為 OOAD(Ob-ject Orient Analysis & Design 面向對象的分析和設計)。
2項目管理人員需要克服的障礙
項目管理是一項控制性的工作,項目管理者的工作重點就是控制和協調。項目管理者首先要確保每個成員完全理解任務,要把任務的目標解釋清楚，并強調他對最終期限及評估成果的期望。
在軟件的整個開發過程中項目管理者需要有效的監控工作進展，并提供給每個成員必要的協助，以確保整個開發團隊朝著目標前進，并且在項目迭代開發過程中的設定可觀測的里程碑。作為團隊開發的項目管理者,要讓整個開發團隊有效地運轉，發揮團隊每位成員的最大能量,必須要克服下列障礙：
2.1障礙一:不信任員工
最簡單的例子是，在重量級(Heavyweight)方法[3](制定了大量的規則的 RUP 方法)中,基本假設是對人的不信任，但不信任就會產生很多的問題，比如士氣不高，計劃趕不上變化，創新能力低下，跳槽率升高等等。輕量級( Lightweight) (像XP 這樣只制定少量的規則來規范行為的方法)方法的出發點是相互信任，做到這一點是很難的，但是一旦做到了，那么這個團隊就能高效運作。
2.2 障礙二:對任務的控制走向極端
很多項目管理者害怕失去對任務的控制。如果能夠保持溝通與協調的順暢，采用類似“關鍵會議制度”等手段，強化信息流通的效率與效果，任務在完成的過程中，失控的可能性其實是很小的。同時，在安排任務的時候，項目管理者應該盡可能地把問題、目標、資源等，向各成員交代清楚，也有助于避免任務失控。
2.3 障礙三: 管理意識薄弱
在軟件企業中，項目經理大多是技術骨干。因此有些項目管理者憑著自己的技術實力寧可自己做得很辛苦，也不愿意把工作內容交給團隊成員。為什么呢? 他們認為，教會部下怎么做，得花上好幾個小時; 自己做的話，不到半小時就做好了，花那么多時間教他們，還不如自己做更快些。問題是: 難道項目管理者就這樣一直把所有的事情都自己做嗎? 由于團隊成員的經驗、技能等方面的差異，盡管項目管理者自己親自動手可能做得比其他成員好，但是如果項目管理者能夠教會團隊成員，就會發現: 其他成員也可以做得一樣好，甚至更好。也許今天項目管理者要耽誤幾個小時來教其他成員干活，但以后他們會為項目管理者節省幾十、幾百個小時，讓項目管理者有時間對關鍵業務作更多的更深入的思考，以保證軟件開發的成功。
3 軟件模塊的'再認識
每一個軟件模塊都具有三項職責: 第一個職責是它運行起來所完成的功能，這也是該模塊存在的原因; 第二個職責是它要應對變化，幾乎所有的模塊在它的生命周期內都要變化，開發者應保證這種改變盡可能的簡單。一個難以改變的模塊是拙劣的，即使能夠工作，也需要對它進行修正; 第三個職責是能和閱讀它的人很好的溝通，對該模塊不熟悉的開發人員也能比較容易的閱讀并理解它。一個無法進行溝通的模塊也是拙劣的，同樣也需要對它進行修正。
當開發人員最初編寫一個模塊時，代碼對于他們來說看起來也許是清晰的。這是由于他們專注于代碼的編寫，對代碼非常熟悉。
經過一段時間后，開發者回過頭來在去看那個模塊，就知道自己怎么會編寫如此糟糕的代碼。為了防止這種情況的發生，開發人員必須站在閱讀者的位置，對代碼進行必要的重構，這樣其他的閱讀者就能夠理解代碼，同時所有的代碼也需要團隊中其他成員的評審。
4 重視經驗的總結
在軟件開發的過程中，對每一問題的解決不可能一開始就有一個好的方法，在解決一系列類似的問題后，開發人員再回過頭來重新審視和評價自己解決問題的方法，在大多數情況下，開發人員都可以對這些解決方法加以提煉，對具有共性的解決方法進一步抽象，尋求更通用的解決方式，并將該設計經驗提交到團隊資源庫組織成項目事件庫。項目盡管有其獨特性，但借鑒從同類型的項目之間的經驗教訓提煉出來的知識是很十分有價值的。
在項目的收尾階段，不僅是給項目的利益相關者一個正式交代，還有一個任務就是項目整個過程的經驗教訓予以提煉形成企業的知識財富[4]。企業的知識往往是隱含、散落在員工群體中，因此需要將員工的隱性知識轉化成公司的顯性知識。
結束語
項目管理雖然沒有非常高深的理論，但要真正實施起來，也絕非易事。對于軟件開發企業而言，這不是一個小的改變，而是一種變革，企業需要為此付出艱苦的努力，從而在實踐中鍛煉提高，解決各種各樣的問題，使項目管理工作越做越好。
參考文獻：
[1]鄭人杰等.實用軟件工程[M].北京:清華大學出版社,1997.4.
[2]新產品開發項目中的需求問題[EB/OL].
[3]Roger S.Pressman;黃柏素,梅宏譯.軟件工程-實踐者的研究方法 [M]. 北京: 機械工業出版社,1999,10.
[4]丁榮貴等.軟件企業項目管的有效性研究[J].經濟與管理研究,2005,4.
【軟件項目管理的論文】相關文章：
2.項目管理的論文
本文來源：http://www.nvnqwx.com/shiyongwen/2160427.htm