二、《計劃管理說明文檔》：如果有完整的Porject計劃是最好的，但此文檔一定要注意的是其準確性，在用Project進行計劃管理時，往往是項目進展時間越長，變更越多，計劃維護就越困難，此時就有可能計劃已經(jīng)無法反應(yīng)實際的項目進展情況了。計劃管理文檔一定要仔細研究，整個項目計劃是否安排妥當，哪些任務(wù)制定了但沒有完成，哪些任務(wù)取消了，這些取消的任務(wù)是否是屬于預定的功能要求，哪些環(huán)節(jié)就沒有進行，哪些環(huán)節(jié)多次重復，有哪些人員工作過程中發(fā)生了任務(wù)的中斷變化，都可以從計劃管理說明文檔看出，這樣更有利于評估項目的實際情況，風險情況，并可以根據(jù)前階段未完善的內(nèi)容進行后續(xù)完善。同時，很關(guān)鍵的一點是，這些任務(wù)中是否存在非正常情況，譬如：你認為很難的技術(shù)研發(fā)工作在短時間內(nèi)卻已經(jīng)完成，這都需要注意，并了解實際情況。最終通過計劃管理說明確文檔定是否預定的目標已經(jīng)全部完成。而已經(jīng)完成的內(nèi)容應(yīng)該和以上提交的成果說明是一致的，此部分如果不存在文檔，就需要根據(jù)相應(yīng)的成果內(nèi)容及人員對整個過程進行文檔補充。此文檔完成后，也可成為后續(xù)管理的一個基礎(chǔ)，進行優(yōu)化處理。

　　如果沒有計劃管理文檔的話，補充的時候，則建議采用Project來完成，前一個成果提交文檔，并且最好可以采用WBS來組織任務(wù)的安排，將已經(jīng)提交的對應(yīng)到相應(yīng)的任務(wù)中。通過前一文檔狀態(tài)的說明，將未完成的內(nèi)容做標記，并且看是否存在同樣的任務(wù)不同的成果表現(xiàn)形式的情況，這時應(yīng)該是屬于重復性任務(wù)，也做標記說明。

　　三、《需求說明書》：需說明產(chǎn)品的最初需求內(nèi)容實際對于我當前接手的這個產(chǎn)品，需求說明書的重要性已經(jīng)大大降低了，因為產(chǎn)品已經(jīng)研發(fā)完成，且提供了完整的用戶手冊，但整理需求說明書的主要目的還是有兩個：

　　1、是要建立完整的項目過程追溯流程，為后續(xù)工作做準備。

　　2、通過需求驗證成果的有效及可用性。

　　需求說明書是一個可簡可繁的一個文檔，在這個項目中，需求說明書更多的是從用戶手冊中來提取需求了，實際的意義并不是很大。但如果是做一個新的項目，則需求說明書應(yīng)該是僅最大可能的對用戶業(yè)務(wù)進行一種還原描述，不要摻雜個人的理解。至于是否可以實現(xiàn)，怎么實現(xiàn)是后續(xù)工作的事情，不是這個環(huán)節(jié)的內(nèi)容。

四、《系統(tǒng)設(shè)計說明書》：系統(tǒng)設(shè)計說明書現(xiàn)在在這個時候已經(jīng)無法在考慮設(shè)計的問題，但此時應(yīng)該提供以下內(nèi)容：

　　1、系統(tǒng)的架構(gòu)設(shè)計及架構(gòu)在應(yīng)用過程的調(diào)整。并且最好可以提供架構(gòu)的弊病分析說明。

　　2、接口設(shè)計說明及接口的詳細規(guī)格及設(shè)計說明。現(xiàn)在的系統(tǒng)基本上都是松散的，通過接口標準從而最終實現(xiàn)系統(tǒng)的集成，所以，接口部分非常關(guān)鍵，這部分內(nèi)容一定要非常清晰和準確。

　　3、如果現(xiàn)在無法再提供設(shè)計文檔，則建議通過第三方工具，根據(jù)成果代碼反項生成設(shè)計，并在此基礎(chǔ)上進行文檔補充，看設(shè)計總比看代碼好很多，所以，這部分內(nèi)容應(yīng)該進行提供。如果在新項目中，此部分內(nèi)容頁建議考慮，主要是規(guī)劃接口調(diào)用、對象職能及對象關(guān)系。

　　五、《數(shù)據(jù)庫設(shè)計說明書》

　　我本人還是十分重視數(shù)據(jù)庫設(shè)計的，雖然現(xiàn)在有很多的DAO的工具，而且也倡導對象建模，但實際在應(yīng)用過程中，完全做到的卻是少之又少，尤其是針對數(shù)據(jù)分析部分內(nèi)容。所以此文檔我認為還是非常重要的。至于文檔的格式，因為此方面已經(jīng)非常“標準”化了，就不在進行說明了。

責任編輯：

更多