個人專案管理計劃及實施建議

1、專案啟動（專案開工會） 2、需求分析 3、概要設計 4、詳細設計 5、編碼 6、整合測試 7、客戶驗收 8、結項

[@more@]一、專案啟動（專案開工會）
瞭解專案干係人及其利害關係。
所有專案組成員是否到位，如到位則拿到專案開發人員的簡歷，詳細瞭解每個開發人員的情況（可能會組織到客戶方面試）。
根據專案需求規格列出專案功能列表，並根據開發人員技術等情況建立WBS。
根據專案時間、資源等情況規劃專案初步開發計劃（各里程碑時間點的粗略計劃，每個時間段投入多少人力等）。
確定各種軟硬體需求，如：版本控制伺服器、資料庫伺服器、開發伺服器、缺陷管理軟體伺服器、開發工具等。

參與人員：
專案經理、專案總監、全體專案組成員、使用者方領導、使用者方參與人員、其它主要專案干係人

專案啟動會議的目標：
讓整個專案組的成員相互認識
建立專案的工作關係和溝通關係
讓大家明確團隊的工作目標
讓大家瞭解專案的當前狀態
一起審閱專案計劃
找出專案的難點或可能出問題的環節
分配小組和個人的角色與責任
獲得小組和個人的承諾

實施建議：
對立項管理過程域產生的所有有價值的文件如《立項建議書》、《立項調查報告》、《立項可行性分析報告》、《立項評審報告》進行配置管理。
做好必要的保密工作。
由於每個專案都要佔用機構的資金和資源，立項評審一定要嚴格。建議對機構高層管理人員進行必要的立項管理培訓。

輸出文件包括：
專案風險管理計劃、工作任務分解結構（WBS）、專案進度計劃、配置管理計劃、質量保證計劃、TimeSheet、開發規範文件、測試計劃


二、需求分析
需求調研：與客戶就其所需要的功能、流程、操作等需要為基礎，而且需求決策者必須是專案經理或部門負責人。
列一個需求管理（包括詳細的溝通計劃及要求溝通）計劃，考慮需求溝通中的人員、資源、時間的要求。
雖然有些因素是客戶方造成的，但應該站在其角度上，為其考慮一些存在的客觀及主觀因素。
注意與專案成員之間的溝通方式及對團隊的建設。
把握需求分析的進度及質量是否符合要求。
根據互動設計原型與客戶交流需求分析是否達到要求及功能點是否有遺漏。
有哪些文件或資料是由客戶提供的，這些資料是否需要在新開發的系統中維護等。


實施建議：
先對專案成員進行培訓，讓他們掌握必要的需求開發技能。(比如需求開發要做什麼，做到什麼程度，需要注意哪些問題等)
對需求開發過程域產生的所有有價值的文件進行配置管理。
需求的建模分析有較高的技術難度，專案成員應當根據自身水平進行取捨。

互動設計中應以使用者的易用性為前提然後考慮在這樣設計的前提下技術上實現是否有難度或者工作量超過前期設計的百分之二十.
（多用TAB形式，儘量讓客戶的某個角色的任務可以在一個頁面中完成，一般用上下文選單，避免用系統的選單，一個功能塊一般只需要一個入口）


輸出文件包括：
產品需求分析說明書、資料流程圖、系統應用架構圖、互動設計原型、需求分析模型(RQM)


三、概要設計
確定影響系統設計的約束因素：本系統應當遵循的標準或規範、軟體、硬體環境（包括執行環境和開發環境）的約束、介面/協議的約束、軟體質量的約束、隱含約束等。
確定設計策略：擴充套件策略、複用策略、折衷策略。
系統分解與設計：將系統分解為若干子系統，確定每個子系統的功能以及子系統之間的關係；將子系統分解為若干模組，確定每個模組的功能以及模組之間的關係。
資料庫概要設計。


輸出文件：
產品概要設計說明書、資料概要設計模型(CDM)



四、詳細設計
確定功能模組的參與者、資料庫表、輸入引數說明、前置條件、基本流程、異常流程、日誌等資訊。
各層次結構的介面定義
資料庫設計：邏輯設計—>物理設計－>安全性設計－>最佳化


實施建議：
先對系統設計人員進行“專題”培訓，讓他們掌握必要的系統設計技能。
由於國內絕大多數的大學不開設“使用者介面設計課程”，這導致大部分軟體開發人員不善於設計使用者介面。專案開發小組應當設法邀請使用者介面設計專家參與（或指導）本軟體的

介面設計。
對系統設計過程中產生的所有有價值的文件進行配置管理。


輸出文件：
產品詳細設計說明書、資料物理設計模型(PDM)、自定義資料型別及BO資料型別檔案、資料字典、系統測試用例、物件模型(OOM)


五、Coding
軟體編碼，各介面的實現。
單元測試。

實施建議：
對開發人員進行“高質量程式設計”培訓，讓他們掌握編寫高質量程式的技能。
對開發人員進行“版本控制、程式碼審查、測試、改錯”等方面的培訓，提高他們的工作效率。
開發小組根據專案的資源、時間等限制因素，可以適當地減少測試的工作量。
對實現與測試過程中產生的所有程式碼和有價值的文件進行配置管理。



輸出：
單元測試報告、程式碼評審報告


六、整合測試
根據系統測試用例測試系統的功能性需求，保證系統的正常功能處理及異常處理是否正確。
使用者介面測試，重點是測試軟體系統的易用性和視覺效果等。
健壯性測試,測試軟體系統在異常情況下能否正常執行的能力。(容錯能力和恢復能力)
安全性測試(這種測試一般能透過建行的fortify 軟體評測即可)
如果產品需要安裝，那麼還得經過安裝與反安裝測試

實施建議：
對系統測試人員進行必要的培訓，提高他們的測試效率。
專案經理和測試小組根據專案的資源、時間等限制因素，設法合理地減少測試的工作量，例如減少“冗餘或無效”的測試。
系統測試小組根據產品的特徵，可以適當地修改本規範的各種文件模板。
對系統測試過程中產生的所有程式碼和有價值的文件進行配置管理。
為了調動測試者的積極性，建議企業或專案設立獎勵機制，例如：根據缺陷的危害程度把獎金分等級，每個新缺陷對應一份獎金，把獎金髮給第一個發現該缺陷的人。


輸出：
系統測試報告、缺陷管理報告、操作手冊


七、客戶驗收
成果審查。驗收人員審查開發方應當交付的成果，如程式碼、文件等等。確保這些成果是完整的並且是正確有效的。
驗收測試。驗收人員對交付的產品進行全面的測試，確保產品功能、質量符合需求。
及時解決客戶方發現的問題。

輸出：
客戶驗收計劃、驗收測試用例、客戶驗收報告、驗收操作手冊


實施建議：
在客戶驗收之前，開發方對驗收人員進行必要的產品培訓。
開發方可以將系統測試用例給驗收人員參考，以減少設計測試用例的時間。
開發方人員應當熱情地協助驗收人員。對驗收人員發現的軟體缺陷馬上予以糾正；對於複雜的問題應當立即請示有關領導，不可拖延。在驗收期間不可與客戶爭吵，給客戶留下很

好的印象。
對驗收過程中產生的所有有價值的文件進行配置管理。


八、結項
計劃與實際情況對比:產品功能、工作成果、產品質量、投入人員、工作量、成本等
申請結項理由和專案自我評價
對專案進行綜合評估，總結經驗教訓。


有價值的結項管理至少包括三項內容：
一、對專案的有形資產和無形資產進行清算，既要防止資產流失，又要及時地利用這些資產。
二、對專案進行綜合評估。例如評估專案完成情況、專案質量、投入產出分析、專案的市場價值、專案對企業的貢獻等等。該評估報告可以作為考核專案人員業績的重要依據。
三、總結經驗教訓，使整個機構受益。

實施建議:
對結項管理過程域產生的所有有價值的文件進行配置管理。
做好必要的保密工作。
結項評審工作不能簡化。
對結項評審委員會進行必要的培訓，使他們樹立正確的觀念，從而嚴格把關

輸出：
結項申請書、結項評審報告



下面是這些核心工具的運用經驗：
1.必須建立原始碼的版本控制系統，就是cvs，基本的程式碼提交原則：
1)程式設計師儘量每天只在下班前提交一次;
2)提交的程式碼必須是在自己的機器上是正常執行的；
3)每次提交都必須用簡短的話說明自己提交程式碼的功能描述。
2.建立錯誤追蹤系統，用Bugzilla就很好，配置好郵件系統，使Bugzilla成為測試人員與開發人員溝通的橋樑。
3.用BAT和Perl指令碼，以cvs中的原始碼為核心實現簡單的每日編譯工具，將這個自己寫的自動化工具放到一臺專門的編譯機器上，在每天的半夜開始自動下載程式碼，自動編譯程式碼

，自動打包安裝程式，自動記錄各種編譯日誌，自動將安裝程式放置到一個固定的以日期為目錄名的公共區。（用cvs2cl.pl得到程式設計師上傳的程式碼更新日誌，以便測試人員參考）
4.測試人員的第二天，應該到公共區取得頭天的最新版本，並根據ChangeLog進行新版本的測試。並將測試中發現的Bug，透過Bugzilla反饋給程式設計師。程式設計師可以根據自己的情況

，或公司的規定來決定修改這些Bug的時間。並將這些Bug的修改情況，在程式碼提交時，寫入程式碼日誌。
5.開發人員的第二天，應該到公共區檢視編譯日誌，看看自己的模組是否正常編譯，及時更正，看看自己的郵箱有沒有Bug報告，及時修改。
6.管理人員的第二天，在綜合專案需求與頭天版本進度的上，可以判斷產品的發展方向，如果有偏航或理解錯誤或有新需求時，可以根據當前情況及時調整。
這樣，透過 cvs => bugzilla => daily-build，就能將程式設計師與測試員，進行互動，各施其責。減少溝通與人為的麻煩。對於管理層，也能做到心中有數：因為每天都有新版本，

隨時掌握產品的走向。。。等等。