幾乎所有的研發人員或者專案管理者都認為文件很重要,但是那麼多文件,哪些文件重要? 可能我們都會有不同認識..
但我們都有乙個共識,就是嚴重的文件化,目前也行不通,研發人員幾乎每天都在寫文件,真正幹活的時間就不多了,常常抱怨專案完不成.那麼多少的文件量才是合適的呢?我想說,如果研發人員的文件水平很高,尤其是uml水平,那麼做uml過程其實就是專案構架和簡單編碼的過程,uml完成之後,整個專案**頁完成80%,但我們常常更加習慣於直接寫**,而不習慣畫uml,這是現實情況.因為它不能測試,無成就感吧.
嚴格的按照標準的軟體工程流程來說,需求文件,概要設計文件,詳細設計文件,測試文件等...在我所遇到和認識團隊中,沒有十分嚴格的完成過的,尤其是詳細設計文件,雖然我以前也寫過很多詳細設計文件,但都與最終的實現差距很大,又不願意耽誤時間改文件,導致基本都作廢了.下面是我對文件的觀點
現在我認為,需求文件是最主要的, 首先,他指明了專案開發人員應該完成的功能點,要達到的目標,他能是我們快速了解整個系統功能..另外,需求文件相當於是客戶與研發間的約定的,防止互相扯皮的可能...專案型別的公司,可以有專門的需求部門,負責寫需求文件,研發人員只要看文件開發就ok了.
其次,概要設計文件,我認為這個文件主要記錄專案的構架,各個功能實現遵守的規則就ok了...
最後,測試文件,功能複雜的軟體中,每個測試點都要記錄,防止出現某些功能不確定的情況,有些時候你會忘記某些功能是否實現了,與其查**或者執行再試下,不如找測試文件.
那麼詳細設計文件呢?我個人認為作用最小.我建議採用規範**的方法,尤其加強對注釋的應用,我相信合格的程式猿能夠看明白複雜的**,即使沒有注釋也應該能夠理解,加了注釋後,應該更加沒問題...如果加了注釋的**都看不懂,怎嘛改bug,怎嘛公升級軟體...
注釋不應該停留在函式或類功能的簡單描述,要盡量詳細,包括建立和修改時間的記錄,本功能對其他功能的影響等.
要下班了,就這樣了...
專案開發文件格式
在專案開發過程中，應該按要求編寫好十三種文件，文件編制要求具有針對性 精確性 清晰性 完整性 靈活性 可追溯性 可行性分析報告 說明該軟體開發專案的實現在技術上 經濟上和社會因素上的可行性，評述為了合理地達到開發目標可供選擇的各種可能實施方案，說明並論證所選定實施方案的理由。專案開發計畫 為軟體專案...
專案開發文件格式
在專案開發過程中，應該按要求編寫好十三種文件，文件編制要求具有針對性 精確性 清晰性 完整性 靈活性 可追溯性 可行性分析報告 說明該軟體開發專案的實現在技術上 經濟上和社會因素上的可行性，評述為了合理地達到開發目標可供選擇的各種可能實施方案，說明並論證所選定實施方案的理由。專案開發計畫 為軟體專案...
專案開發文件之 專案開發計畫
專案開發計畫 1 引言 1.1 編寫目的 闡明編寫可行性研究報告的目的，提出讀者物件 1.2 專案背景 應包括 專案的委託單位 開發單位和主管部門 該軟體系統與其他系統的關係。1.3 定義 列出文件中用到的專門術語的定義和縮寫詞的原文 1.4 參考資料 可包括 專案經核准的計畫任務書 合同或上級機關...