詳解軟件項(xiàng)目管理流程的每一步
一、項(xiàng)目啟動(dòng)（項(xiàng)目開工會(huì)）
了解項(xiàng)目干系人及其利害關(guān)系。
所有項(xiàng)目組成員是否到位，如到位則拿到項(xiàng)目開發(fā)人員的簡(jiǎn)歷，詳細(xì)了解每個(gè)開發(fā)人員的情況（可能會(huì)組織到客戶方面試）。
根據(jù)項(xiàng)目需求規(guī)格列出項(xiàng)目功能列表，并根據(jù)開發(fā)人員技術(shù)等情況創(chuàng)建WBS。
根據(jù)項(xiàng)目時(shí)間、資源等情況規(guī)劃項(xiàng)目初步開發(fā)計(jì)劃（各里程碑時(shí)間點(diǎn)的粗略計(jì)劃，每個(gè)時(shí)間段投入多少人力等）。
確定各種軟硬件需求，如：版本控制服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器、開發(fā)服務(wù)器、缺陷管理軟件服務(wù)器、開發(fā)工具等。
參與人員：
項(xiàng)目經(jīng)理、項(xiàng)目總監(jiān)、全體項(xiàng)目組成員、用戶方領(lǐng)導(dǎo)、用戶方參與人員、其它主要項(xiàng)目干系人
項(xiàng)目啟動(dòng)會(huì)議的目標(biāo)：
讓整個(gè)項(xiàng)目組的成員相互認(rèn)識(shí)
建立項(xiàng)目的工作關(guān)系和溝通關(guān)系
讓大家明確團(tuán)隊(duì)的工作目標(biāo)
讓大家了解項(xiàng)目的當(dāng)前狀態(tài)
一起審閱項(xiàng)目計(jì)劃
找出項(xiàng)目的難點(diǎn)或可能出問題的環(huán)節(jié)
分配小組和個(gè)人的角色與責(zé)任
獲得小組和個(gè)人的承諾
實(shí)施建議：
對(duì)立項(xiàng)管理過程域產(chǎn)生的所有有價(jià)值的文檔如《立項(xiàng)建議書》、《立項(xiàng)調(diào)查報(bào)告》、《立項(xiàng)可行性分析報(bào)告》、《立項(xiàng)評(píng)審報(bào)告》進(jìn)行配置管理。
做好必要的保密工作。
由于每個(gè)項(xiàng)目都要占用機(jī)構(gòu)的資金和資源，立項(xiàng)評(píng)審一定要嚴(yán)格。建議對(duì)機(jī)構(gòu)高層管理人員進(jìn)行必要的立項(xiàng)管理培訓(xùn)。
輸出文檔包括：
項(xiàng)目風(fēng)險(xiǎn)管理計(jì)劃、工作任務(wù)分解結(jié)構(gòu)（WBS）、項(xiàng)目進(jìn)度計(jì)劃、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、TimeSheet、開發(fā)規(guī)范文檔、測(cè)試計(jì)劃
二、需求分析
需求調(diào)研：與客戶就其所需要的功能、流程、操作等需要為基礎(chǔ)，而且需求決策者必須是項(xiàng)目經(jīng)理或部門負(fù)責(zé)人。
列一個(gè)需求管理（包括詳細(xì)的溝通計(jì)劃及要求溝通）計(jì)劃，考慮需求溝通中的人員、資源、時(shí)間的要求。
雖然有些因素是客戶方造成的，但應(yīng)該站在其角度上，為其考慮一些存在的客觀及主觀因素。
注意與項(xiàng)目成員之間的溝通方式及對(duì)團(tuán)隊(duì)的建設(shè)。
把握需求分析的進(jìn)度及質(zhì)量是否符合要求。
根據(jù)交互設(shè)計(jì)原型與客戶交流需求分析是否達(dá)到要求及功能點(diǎn)是否有遺漏。
有哪些文檔或數(shù)據(jù)是由客戶提供的，這些數(shù)據(jù)是否需要在新開發(fā)的系統(tǒng)中維護(hù)等。
實(shí)施建議：
先對(duì)項(xiàng)目成員進(jìn)行培訓(xùn)，讓他們掌握必要的需求開發(fā)技能。(比如需求開發(fā)要做什么，做到什么程度，需要注意哪些問題等)
對(duì)需求開發(fā)過程域產(chǎn)生的所有有價(jià)值的文檔進(jìn)行配置管理。
需求的建模分析有較高的技術(shù)難度，項(xiàng)目成員應(yīng)當(dāng)根據(jù)自身水平進(jìn)行取舍。
交互設(shè)計(jì)中應(yīng)以用戶的易用性為前提然后考慮在這樣設(shè)計(jì)的前提下技術(shù)上實(shí)現(xiàn)是否有難度或者工作量超過前期設(shè)計(jì)的百分之二十. （多用TAB形式，盡量讓客戶的某個(gè)角色的任務(wù)可以在一個(gè)頁(yè)面中完成，一般用上下文菜單，避免用系統(tǒng)的菜單，一個(gè)功能塊一般只需要一個(gè)入口）
輸出文檔包括：
產(chǎn)品需求分析說明書、數(shù)據(jù)流程圖、系統(tǒng)應(yīng)用架構(gòu)圖、交互設(shè)計(jì)原型、需求分析模型(RQM)
三、概要設(shè)計(jì)
確定影響系統(tǒng)設(shè)計(jì)的約束因素：本系統(tǒng)應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范、軟件、硬件環(huán)境（包括運(yùn)行環(huán)境和開發(fā)環(huán)境）的約束、接口/協(xié)議的約束、軟件質(zhì)量的約束、隱含約束等。
確定設(shè)計(jì)策略：擴(kuò)展策略、復(fù)用策略、折衷策略。
系統(tǒng)分解與設(shè)計(jì)：將系統(tǒng)分解為若干子系統(tǒng)，確定每個(gè)子系統(tǒng)的功能以及子系統(tǒng)之間的關(guān)系；將子系統(tǒng)分解為若干模塊，確定每個(gè)模塊的功能以及模塊之間的關(guān)系。
數(shù)據(jù)庫(kù)概要設(shè)計(jì)。
輸出文檔：
產(chǎn)品概要設(shè)計(jì)說明書、數(shù)據(jù)概要設(shè)計(jì)模型(CDM)
四、詳細(xì)設(shè)計(jì)
確定功能模塊的參與者、數(shù)據(jù)庫(kù)表、輸入?yún)?shù)說明、前置條件、基本流程、異常流程、日志等信息。
各層次結(jié)構(gòu)的接口定義
數(shù)據(jù)庫(kù)設(shè)計(jì)：邏輯設(shè)計(jì)—>物理設(shè)計(jì)－>安全性設(shè)計(jì)－>優(yōu)化
實(shí)施建議：
先對(duì)系統(tǒng)設(shè)計(jì)人員進(jìn)行“專題”培訓(xùn)，讓他們掌握必要的系統(tǒng)設(shè)計(jì)技能。 由于國(guó)內(nèi)絕大多數(shù)的大學(xué)不開設(shè)“用戶界面設(shè)計(jì)課程”，這導(dǎo)致大部分軟件開發(fā)人員不善于設(shè)計(jì)用戶界面。項(xiàng)目開發(fā)小組應(yīng)當(dāng)設(shè)法邀請(qǐng)用戶界面設(shè)計(jì)專家參與（或指導(dǎo)）本軟件的
界面設(shè)計(jì)。
對(duì)系統(tǒng)設(shè)計(jì)過程中產(chǎn)生的所有有價(jià)值的文檔進(jìn)行配置管理。
輸出文檔：
產(chǎn)品詳細(xì)設(shè)計(jì)說明書、數(shù)據(jù)物理設(shè)計(jì)模型(PDM)、自定義數(shù)據(jù)類型及BO數(shù)據(jù)類型文件、數(shù)據(jù)字典、系統(tǒng)測(cè)試用例、對(duì)象模型(OOM)
五、Coding
軟件編碼，各接口的實(shí)現(xiàn)。
單元測(cè)試。
實(shí)施建議：
對(duì)開發(fā)人員進(jìn)行“高質(zhì)量程序設(shè)計(jì)”培訓(xùn)，讓他們掌握編寫高質(zhì)量程序的技能。
對(duì)開發(fā)人員進(jìn)行“版本控制、代碼審查、測(cè)試、改錯(cuò)”等方面的培訓(xùn)，提高他們的工作效率。
開發(fā)小組根據(jù)項(xiàng)目的資源、時(shí)間等限制因素，可以適當(dāng)?shù)販p少測(cè)試的工作量。
對(duì)實(shí)現(xiàn)與測(cè)試過程中產(chǎn)生的所有代碼和有價(jià)值的文檔進(jìn)行配置管理。
輸出：
單元測(cè)試報(bào)告、代碼評(píng)審報(bào)告
六、集成測(cè)試
根據(jù)系統(tǒng)測(cè)試用例測(cè)試系統(tǒng)的功能性需求，保證系統(tǒng)的正常功能處理及異常處理是否正確。
用戶界面測(cè)試，重點(diǎn)是測(cè)試軟件系統(tǒng)的易用性和視覺效果等。
健壯性測(cè)試,測(cè)試軟件系統(tǒng)在異常情況下能否正常運(yùn)行的能力。(容錯(cuò)能力和恢復(fù)能力)
安全性測(cè)試(這種測(cè)試一般能通過建行的fortify 軟件評(píng)測(cè)即可)
如果產(chǎn)品需要安裝，那么還得經(jīng)過安裝與反安裝測(cè)試
實(shí)施建議：
對(duì)系統(tǒng)測(cè)試人員進(jìn)行必要的培訓(xùn)，提高他們的測(cè)試效率。
項(xiàng)目經(jīng)理和測(cè)試小組根據(jù)項(xiàng)目的資源、時(shí)間等限制因素，設(shè)法合理地減少測(cè)試的工作量，例如減少“冗余或無效”的測(cè)試。
系統(tǒng)測(cè)試小組根據(jù)產(chǎn)品的特征，可以適當(dāng)?shù)匦薷谋疽?guī)范的各種文檔模板。
對(duì)系統(tǒng)測(cè)試過程中產(chǎn)生的所有代碼和有價(jià)值的文檔進(jìn)行配置管理。
為了調(diào)動(dòng)測(cè)試者的積極性，建議企業(yè)或項(xiàng)目設(shè)立獎(jiǎng)勵(lì)機(jī)制，例如：根據(jù)缺陷的危害程度把獎(jiǎng)金分等級(jí)，每個(gè)新缺陷對(duì)應(yīng)一份獎(jiǎng)金，把獎(jiǎng)金發(fā)給第一個(gè)發(fā)現(xiàn)該缺陷的人。
輸出：
系統(tǒng)測(cè)試報(bào)告、缺陷管理報(bào)告、操作手冊(cè)
七、客戶驗(yàn)收
成果審查。驗(yàn)收人員審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確有效的。
驗(yàn)收測(cè)試。驗(yàn)收人員對(duì)交付的產(chǎn)品進(jìn)行全面的測(cè)試，確保產(chǎn)品功能、質(zhì)量符合需求。
及時(shí)解決客戶方發(fā)現(xiàn)的問題。
輸出：
客戶驗(yàn)收計(jì)劃、驗(yàn)收測(cè)試用例、客戶驗(yàn)收?qǐng)?bào)告、驗(yàn)收操作手冊(cè)
實(shí)施建議：
在客戶驗(yàn)收之前，開發(fā)方對(duì)驗(yàn)收人員進(jìn)行必要的產(chǎn)品培訓(xùn)。
開發(fā)方可以將系統(tǒng)測(cè)試用例給驗(yàn)收人員參考，以減少設(shè)計(jì)測(cè)試用例的時(shí)間。
開發(fā)方人員應(yīng)當(dāng)熱情地協(xié)助驗(yàn)收人員。對(duì)驗(yàn)收人員發(fā)現(xiàn)的軟件缺陷馬上予以糾正；對(duì)于復(fù)雜的問題應(yīng)當(dāng)立即請(qǐng)示有關(guān)領(lǐng)導(dǎo)，不可拖延。在驗(yàn)收期間不可與客戶爭(zhēng)吵，給客戶留下很
好的印象。
對(duì)驗(yàn)收過程中產(chǎn)生的所有有價(jià)值的文檔進(jìn)行配置管理。
八、結(jié)項(xiàng)
計(jì)劃與實(shí)際情況對(duì)比:產(chǎn)品功能、工作成果、產(chǎn)品質(zhì)量、投入人員、工作量、成本等
申請(qǐng)結(jié)項(xiàng)理由和項(xiàng)目自我評(píng)價(jià)
對(duì)項(xiàng)目進(jìn)行綜合評(píng)估，總結(jié)經(jīng)驗(yàn)教訓(xùn)。
有價(jià)值的結(jié)項(xiàng)管理至少包括三項(xiàng)內(nèi)容：
一、對(duì)項(xiàng)目的有形資產(chǎn)和無形資產(chǎn)進(jìn)行清算，既要防止資產(chǎn)流失，又要及時(shí)地利用這些資產(chǎn)。
二、對(duì)項(xiàng)目進(jìn)行綜合評(píng)估。例如評(píng)估項(xiàng)目完成情況、項(xiàng)目質(zhì)量、投入產(chǎn)出分析、項(xiàng)目的市場(chǎng)價(jià)值、項(xiàng)目對(duì)企業(yè)的貢獻(xiàn)等等。該評(píng)估報(bào)告可以作為考核項(xiàng)目人員業(yè)績(jī)的重要依據(jù)。
三、總結(jié)經(jīng)驗(yàn)教訓(xùn)，使整個(gè)機(jī)構(gòu)受益。
實(shí)施建議:
對(duì)結(jié)項(xiàng)管理過程域產(chǎn)生的所有有價(jià)值的文檔進(jìn)行配置管理。
做好必要的保密工作。
結(jié)項(xiàng)評(píng)審工作不能簡(jiǎn)化。
對(duì)結(jié)項(xiàng)評(píng)審委員會(huì)進(jìn)行必要的培訓(xùn)，使他們樹立正確的觀念，從而嚴(yán)格把關(guān)
輸出：
結(jié)項(xiàng)申請(qǐng)書、結(jié)項(xiàng)評(píng)審報(bào)告
下面是這些核心工具的運(yùn)用經(jīng)驗(yàn)：
1.必須建立源代碼的版本控制系統(tǒng)，就是cvs，基本的代碼提交原則：
1)程序員盡量每天只在下班前提交一次;
2)提交的代碼必須是在自己的機(jī)器上是正常運(yùn)行的；
3)每次提交都必須用簡(jiǎn)短的話說明自己提交代碼的功能描述。
2.建立錯(cuò)誤追蹤系統(tǒng)，用Bugzilla就很好，配置好郵件系統(tǒng)，使Bugzilla成為測(cè)試人員與開發(fā)人員溝通的橋梁。
3.用BAT和Perl腳本，以cvs中的源代碼為核心實(shí)現(xiàn)簡(jiǎn)單的每日編譯工具，將這個(gè)自己寫的自動(dòng)化工具放到一臺(tái)專門的編譯機(jī)器上，在每天的半夜開始自動(dòng)下載代碼，自動(dòng)編譯代碼，自動(dòng)打包安裝程序，自動(dòng)記錄各種編譯日志，自動(dòng)將安裝程序放置到一個(gè)固定的以日期為目錄名的公共區(qū)。（用cvs2cl.pl得到程序員上傳的代碼更新日志，以便測(cè)試人員參考） 4.測(cè)試人員的第二天，應(yīng)該到公共區(qū)取得頭天的最新版本，并根據(jù)ChangeLog進(jìn)行新版本的測(cè)試。并將測(cè)試中發(fā)現(xiàn)的Bug，通過Bugzilla反饋給程序員。程序員可以根據(jù)自己的情況或公司的規(guī)定來決定修改這些Bug的時(shí)間。并將這些Bug的修改情況，在代碼提交時(shí)，寫入代碼日志。
5.開發(fā)人員的第二天，應(yīng)該到公共區(qū)查看編譯日志，看看自己的模塊是否正常編譯，及時(shí)更正，看看自己的郵箱有沒有Bug報(bào)告，及時(shí)修改。
6.管理人員的第二天，在綜合項(xiàng)目需求與頭天版本進(jìn)度的上，可以判斷產(chǎn)品的發(fā)展方向，如果有偏航或理解錯(cuò)誤或有新需求時(shí)，可以根據(jù)當(dāng)前情況及時(shí)調(diào)整。
這樣，通過 cvs => bugzilla => daily-build，就能將程序員與測(cè)試員，進(jìn)行互動(dòng)，各施其責(zé)。減少溝通與人為的麻煩。對(duì)于管理層，也能做到心中有數(shù)：因?yàn)槊刻於加行掳姹荆?/p>
隨時(shí)掌握產(chǎn)品的走向。。。等等
原文鏈接： http://www.cnblogs.com/dizchan/archive/2011/06/09/2076430.html
【編輯推薦】
