軟體專案管理的實質就是軟體專案計劃的編制和軟體專案計劃的跟蹤控制，這裡計劃是專案成功實施的指南和跟蹤控制的依據，而跟蹤控制又保證專案計劃的成功執行。本文以例項具體分析在軟體開發過程中如何進行這兩項
工作。

在軟體專案中有兩條非常重要的線索，一條是軟體專案開發過程，另外一條是軟體專案管理過程。通常，人們容易注意軟體專案開發過程，而忽略軟體專案管理過程的線索。事實上，後者很重要，有時其重要性甚至超過專案開發過程。專案管理可以讓一個專案獲得高額的盈利也可以讓一個專案損失慘重，而編碼的影響力則相對小一些。現實中由於出色的專案管理，將已經虧損很嚴重的專案又重新扭虧為盈的例子並不少見。

專案管理在生活中的例子很多。例如進行一次商品採購，你會在一張紙上記錄所有需要購買的東西（即採購清單），這個採購清單幫助你不要遺漏採購項，你可以採用“完成一個採購項，在採購清單上打一個勾”的方法協助你完成採購。與此類似，軟體專案管理也是如何管理好軟體專案的內容、花費的時間（進度）以及花費的代價（規模成本）。為此需要制定一個好的專案計劃，然後控制好這個計劃。編制軟體專案計劃、跟蹤控制軟體專案計劃這就是軟體專案管理的實質。其中，計劃是專案成功實施的指南和跟蹤控制的依據，而跟蹤控制是專案計劃成功執行的保證。

確定軟體專案開發的策略

專案經理的首要任務是編制專案計劃。專案計劃有三大核心目標: 確定專案範圍、專案預算、專案進度，即明確專案做什麼、花多少錢、需要多長時間。為了制定一個合理有效的計劃，專案經理需要從專案需求開始確定專案範圍，然後將專案的需求進行分解，以便於估算、安排資源和合理的進度等。這樣就形成了三個核心計劃: 範圍計劃、成本計劃和進度計劃。此外，作為完整的專案計劃，質量計劃、風險計劃、溝通計劃等同樣也必不可少。沒有質量管理的專案是失敗的專案，沒有風險管理的專案會時時處於風險之中，沒有溝通的專案是很難完成的。專案規劃從合同階段就開始了，其實任何一個合同的主要內容也是確定專案的範圍、時間和成本。

軟體專案最終的結果是根據使用者的需求提交一個使用者滿意的產品，這是一個從無到有的過程。因此計劃首先應該確定專案開發的策略，即專案的生存期模型。瀑布、Ｖ、原型、螺旋、漸進式階段提交等模型是幾種常見的生存期模型，漸進式階段提交模型體現了軟體專案漸進性的特點，同時，分階段提交專案結果，也有利於軟體專案開發。RUP（Rational的統一過程）提及的軟體專案生存期模型就是一種漸進式階段提交模型。圖1的模型是筆者曾經參與的一個銀行業務系統的生存期模型，它是漸進階段提交的模型。

圖1 某銀行業務系統漸進式階段提交模型
如果專案週期不是很長，可以不分階段提交結果，而只是分階段開發，這樣漸進式階段提交模型就演化為增量模型。例如筆者曾完成的一個《校務通管理平臺資訊系統》專案，它是對學校教務和教學活動進行綜合管理的平臺系統。儘管分階段實施專案是比較理想的專案管理模型，但是由於這個專案不大，沒有必要分階段提交一個執行系統，所以採用增量的模型。

生存期模型中可以定義軟體開發中採用的過程、程式，如果過程定義得很明確，或者過程定義的操作性很強，那麼作為工廠化的軟體開發就會很順利，專案管理的過程也會很順利，所以在軟體專案中的這兩條線索也是相輔相成的。

制定專案核心計劃

專案的核心計劃是範圍、時間、成本的確定，這三方面並不是截然分開的，而在專案計劃的制定過程中相互交織。

確定專案範圍要從需求入手，將一個專案分解為更多的工作細目或者子專案，使專案變得更小、更易管理、更易操作。目的是為了提高估算（成本、時間和資源）的準確性，使工作變得更易操作，責任分工更加明確。任務分解的結果是WBS (Work Breakdown Structure)。只有在WBS中的工作才屬於該專案的工作範圍。

任務分解之後，可以根據分解的結果，估算任務的規模、成本，同時可以根據分解的結果進一步分解詳細的專案活動，以便安排任務之間的關聯關係，估算每個任務的工期，然後進一步估算專案總的工期。

專案的規模和進度估算有一定的關係。進度估算是從時間的角度對專案進行規劃，而成本估算則是從費用的角度對專案進行規劃。類比估演算法、引數模型估演算法、自下而上估演算法等都是規模成本估算的方法，而經驗匯出模型、工程評價技術（PERT，Program Evaluation and Review Technique）、關鍵路徑法（CPM，Critical Path Method）等都是進度估算的方法。在專案的進行過程中，可能要不斷重複進行估算，以減少估算的誤差。在專案的不同階段可以採用不同的估算方法，開始可能很粗糙，隨著專案的進展會逐步精確。

在安排專案進度的時候，可以根據WBS的分解情況，繼續分解相應的活動（任務），分析確定各個活動之間的順序關係，畫出任務的網路圖(例如PDM網路圖或者ADM網路圖)。圖中的每一項任務必須有一個前驅和後繼，除了專案中的第一項和最後一項任務。確定關鍵路徑在哪裡、哪些任務還有變化，然後結合資源、成本等情況，再不斷進行資源調整最佳化以及工期、活動關係的調整等。計劃調整的過程雖然很費時費力，但也是一個關鍵的過程，要經過多次調整、修改、評審討論等，最後才能確定一個計劃，將此計劃存為基準計劃。這個基準計劃可以存入專案管理系統中，例如MS Project。

透過這個基準計劃可以確定專案的範圍即專案所有的任務，還可以確定專案的時間進度表，這個計劃也確定了各個任務的資源（人力資源、物力資源等），當然專案的成本就可以確定下來。

仍以《校務通管理平臺資訊系統》為例，根據專案WBS的分解情況，繼續分解相應的活動（任務），然後確定各個活動之間的關係，系統的功能採用增量方式實現，實施階段分6個增量，對各個任務（活動）分配相應的資源，經過多次的活動調整以縮短工期，多次的資源調配以解決資源衝突和減少成本，最終形成了基準計劃。 [@more@]

軟體專案管理的實質(一)（轉）

相關文章