專案管理開發概述

標籤：style   tar   color   get   工作   問題   

1     背景1.1      目的與作用

專案管理開發規範用於規範管理開發活動，提升工作效率，減少項目品質問題的出現，並能夠對項目基準、成本績效進行有效控制，當然，也包括了對實施人員的績效考核工作。

 

2     概述

一個項目，可以分為專案管理部分和項目開發兩部分。其兩者的關係可以說是相互依存，缺一不可。

開發過程是項目目標的具體生產過程，而專案管理過程則對此生產過程進行控制，使其約束在一定的範圍、進的、成本之內，並需要達到規定的品質目標。

歸納起來說，專案管理是按照預先規定好的步驟，在滿足一些約束的條件下，一步步進行項目目標生產的過程。

要進行正常化的建設，首要做的，就是建立起相應的管理開發流程，流程是秩序的一種具體的體現。

流程應以管理為主要流程過程，將開發過程變成管理過程式控制制的一部分，管理過程對開發過程進行控制。同時，本流程還結合了研發部現在執行的模組化開發模式和基於原型的開發流程，使得本流程更加適合現有的工作模式，並彌補現在存在的管理上的缺陷。

現先將專案管理過程和項目開發過程進行簡單的概述，然後對再說明如何對其進行融合，形成一個統一的管理流程。

2.1.1   專案管理流程概述

專案管理的生命週期分為四個階段，分別是概念階段、計劃階段、實施階段、收尾階段。

?  概念階段

主要是進行可行性分析及論證工作，確定項目是否可行。

一般還會對招投標進行管理。

可以將制定項目章程過程放到了概念階段。

?  計劃階段

對項目對的實施過程進行計劃，包括制定各種管理計劃：進度、成本、品質、範圍、變更控制、溝通等等。

根據項目實際情況，制定項目的各種基準，如範圍基準、進度基準、成本基準。

 

?  實施階段

主要包括按照進計划進行實施，對實施進行控制，對偏離進度的情況進行糾正；在實施的過程中，根據實際情況，也可能對進度計划進行變更，從而改變項目基準；

?  收尾階段

針對整個項目進行收尾，也可以針對某個階段進行收尾。

項目的收尾工作主要包括行政收尾和完成合約兩部分工作。在各個階段和整個項目結束時，需要進行行政收尾工作。收尾應包括相應的檢查工作。確保階段中的各個活動均已完成，並進行測試或檢查。保證能夠進行下一階段。

2.1.2   項目開發流程概述2.1.2.1     軟體開發模型

選擇V模型+原型法作為開發模型，並採用模組化的方式將項目系統分割成一系列獨立的、可部署、測試的模組，進行設計開發工作。

       此軟體開發模型，具有如下的特點：

?  基於模組化。

將要做的項目產品，按照功能模組進行拆分。具體的模組化實現思路及執行方法，參見相關模組化文檔。

?  採用V模型

基於V模型在瀑布開發模型的基礎上，在功能融合了測試，以確保錯誤能儘早的暴露出來並被改正。

結合V模型和模組化，將V模型的最小實施單位定義為進度計劃網狀圖中的活動單元

?  原型法

在需求分析結束後，需進行原型設計工作。以最小的代價，展現出項目的整體輪廓。使模糊的文字表達，轉換成清晰直觀的圖形展示。

2.1.2.2     軟體開發流程階段概述2.1.2.2.1       軟體開發流程圖

2.1.2.2.2       開發流程整體流程概述

開發流程活動將融合到管理流程中，具體如下：

2.1.2.2.2.1   整體需求分析和原型設計

在專案計劃階段，會對軟體開發進行整體需求和整體原型功能設計工作。這兩部分工作的細分程度，視項目具體情況而定。如果項目的需求明確，項目目標清晰，則可以目標的所有功能進行詳細的需求分析和原型設計工作。若項目需求不明確，項目目標模糊。則可以對上述工作進行概述型的描述即可。

2.1.2.2.2.2   整體設計工作整體需求和原型工作完成後，會對項目進行設計工作。同樣，設計工作也會分為多個層次。在整體設計過程中，可以根據項目的情況，選擇合適的設計方式：

?  項目簡單/具有可比性

需求明確、簡單的項目，可以進行簡單設計即可。可選項包括整體功能描述、整體設計思路、功能模組劃分、功能模組描述、架構層級偽碼。

?  項目目標明確

具有詳細目標的項目，可以在整體設計時，進行完功能模組的設計工作。設計文檔內容同上

?  項目目標不明

對於目標不明確的項目，可以採用漸進明細的方式，在計劃階段，可以先進行簡單設計，但需要在後期不斷修正完善相關文檔。

 

       對於大型項目，可以按照功能模組，將計劃文檔劃分為子文檔。以方便查閱和維護。

2.1.2.2.2.3   模組層級別需求及原型設計

對於整體需求分析和原型設計階段未進行詳細分析設計的模組，在相應的模組活動中，將進行詳細需求及原型設計工作，以保證在設計和編碼工作開始前，進一步明確需求，降低風險。此工作會項目的時間、進度、成本、範圍產生變更。

 

步驟同整體需求分析和原型設計

2.1.2.2.2.4   模組層級別設計工作

對於整體設計階段未進行詳細分析設計的模組，在相應的模組活動中，可以對相應的設計文檔進行細化和調整。此工作會項目的時間、進度、成本、範圍產生變更。

步驟同整設計工作。

2.1.2.2.2.5  編碼工作

根據設計文檔、開發規範、進行編碼工作。編碼應遵循進度計劃、範圍要求，並遵守相應的開發規範。

開發過程中，如發現與設計、需求不符，應與項目負責人、系統設計人員進行協商。如確實需要更改，需走整體變更流程。

 

2.1.2.2.2.6  模組層級別測試工作

當功能模組開發完畢後，開發人員應保證模組符合部門定製的各種規範，如編碼規範、測試規範等。是否符合規範，將以符合各種品質檢查單為標準。

還需根據研發部測試組提供的開發人員自測規範，對常見的但不應該出現的問題，還應形成自測檢查單。

 

2.1.2.2.2.7  系統/整合測試

在裡程碑或某一組相關活動結束、以及全部功能開發完成後。需要對其進行整合測試。系統/整合測試從整體的角度，對一組功能模組進行測試，測試應遵循測試規範和標準。測試的結果應是可以度量的。

3      輔助的工具

知道怎麼做不難，難的地方在於如何去做

第一是執行力，如何去嚴格按照規範執行，按規矩去辦事，這是最難做到的。秩序不光需要建立，還應需要去維持，去強化。

第二是成本問題，如果執行的成本過高，也就失去了價值。由人去管理人是困難的，但如果交由系統呢，對吧？