軟體專案管理的論文

軟體專案開發是一項系統而複雜的工作 它需要一個團隊互相配合、分工協作。軟體專案管理系統可以規範一個軟體開發團隊的日常工作，下面是關於軟體專案管理論文，歡迎借鑑！

隨著資訊科技的飛速發展，軟體產品的規模也越來越龐大,各軟體企業都在積極將軟體專案管理引入開發活動中，對開發實行有效的管理。但國內軟體企業對於軟體專案的認知，在一定程度上盲目多於理性、理論多於實踐。鑑於上述問題，本文分析了基於專案管理的軟體開發過程需要注意的幾個問題。

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 sman;黃柏素,梅巨集譯.軟體工程-實踐者的研究方法 [M]. 北京: 機械工業出版社,1999,10.

[4]丁榮貴等.軟體企業專案管的有效性研究[J].經濟與管理研究,2005,4.