軟件項目文檔管理與版本控制的初步報告

1、word文檔 可自由復制編輯軟件項目文檔管理與版本控制的初步報告 一、現(xiàn)階段的問題： 版本與文檔管理中常見或可能存在的現(xiàn)象： Item 1. 項目的邏輯結構不嚴謹 Item 2.多人修改同一個文件 Item 3.用戶權限混亂或無權限控制 Item 4.上傳文檔的命名隨意 Item 5.從服務器上獲取最近版本時的疏忽 二、文檔與版本管理衡量標準：效率與質(zhì)量（軟件的一致性、冗余程度等） 三、解決方向： 1、項目文檔、文件夾結構化分類管理 2、文檔命名規(guī)范化 3、操作權限控制 4、注意服務器唯一有效版本，本地備份輔助 四、初步解決辦法 創(chuàng)建文檔儲存庫，基于工具的資料庫或是一個共享目錄里建立的簡單的“

2、文件夾/文件”結構。 1、管理范圍：開發(fā)庫、項目文檔、產(chǎn)品庫、構建庫 1） 開發(fā)庫包括：A、源代碼B、執(zhí)行程序 2）文檔管理： A、項目文檔包括可行性研究報告(愿景)，項目開發(fā)計劃(立項)，需求(說明書)，評審，軟件設計說明書，開發(fā)進度月報，測試，相關開發(fā)文檔，參考資料，文檔模板，用戶（操作）手冊，項目開發(fā)總結報告 B、相關設備 C、參考資料（開發(fā)人員與客戶會談的材料，參考文獻，項目結束歸檔時電子郵件 3）產(chǎn)品庫 2、建立規(guī)范的目錄體系 目錄體系結構圖如下：SVN開發(fā)庫管理(m2m)項目一源碼(FSU)SVN開發(fā)庫管理(m2m)項目一源碼(FSU)項目二源碼項目二源碼項目文檔管理(docs)項

3、目三源碼項目文檔管理(docs)項目三源碼可行性研究報告(愿景)可行性研究報告(愿景)項目開發(fā)計劃(立項)項目開發(fā)計劃(立項)需求(說明書)項目一需求(說明書)項目一評審評審軟件設計說明書軟件設計說明書開發(fā)進度月報開發(fā)進度月報測試測試測試計劃測試計劃缺陷變更與追蹤缺陷變更與追蹤測試用例設計測試用例設計測試分析總結測試分析總結相關開發(fā)文檔相關開發(fā)文檔參考資料參考資料參考文獻、技術資料客戶資料參考文獻、技術資料客戶資料其他文檔模板文檔模板用戶（操作）手冊項目二用戶（操作）手冊項目二項目開發(fā)總結報告項目開發(fā)總結報告 3、版本與文檔命名規(guī)則 1）版本V1.0至版本V2.0之間可少設過渡版本，變更量積累

4、之一定量或階段之后再進行版本變更。對于計劃性文檔、技術文檔和用戶文檔，其版本按修改的先后順序確定，新生成的文檔第一次發(fā)行是第一版，修改后第二次發(fā)行是第二版，以此類推。 2）建立規(guī)范的文檔與版本命名規(guī)則，文檔控制級別為中、低的文檔是不需要進行版本控制的，這些文檔大都是臨時性的、一次性的、中間性的文檔，比如：需求調(diào)研報告，會議紀要，項目報告等。文檔 控制級別為高的文檔要進行版本控制。如：用戶需求說明書，概要設計說明書，用戶手冊等，無論修改有多少次，都要求留版本記錄，尤其是項目產(chǎn)品。 控制級別高的文檔命名： 項目編號_文檔名與版本號_日期_作者， 如SPMS_需求說明書V1.0_YYMMDD_李明

5、控制級別為中、低的文檔命名： 項目編號_文檔名_日期_作者，如SPMS_第六周問題報告_YYMMDD_李明 3）最終完成的軟件版本用二位符號表示：“ s.xy”，含義如下： “ y ” 為第二次版本號，表示糾正錯誤時的版本升級，用一位數(shù)字表示：“ 1-9 ” 對上一次產(chǎn)品或項目的缺陷做修正，第二次版本號增加； “ x ” 為第一次版本號，表示增加功能時的版本升級，用一位數(shù)字表示：“ 1-9 ” ，與上一產(chǎn)品或項目相比，功能進行了小量的增加或修正時，第一次版本號增加，第二次版本號為零，第二版本號為零時可以省略不寫； “ s ” 為主版本號，用一位數(shù)字表示：“ 1-9 ” ，對產(chǎn)品作重大調(diào)整，或與

6、已發(fā)行的上一產(chǎn)品相比，在功能與性能上有較大改善時主版本號增加，次版本號為零，產(chǎn)品或項目概念全新，第一次完成，版本號為1.0。 4、人員職責與維護、更新 文檔管理的人員可以由一個或多個團隊成員兼職擔任，有經(jīng)驗最好，職責包括： 建立、管理和執(zhí)行文檔標準并監(jiān)控它們的狀態(tài)； 確認并解決文檔庫中存在的問題； 確定對哪些文件進行存檔或對哪些舊文件（如每周的狀態(tài)情況報告在三個月以后可能就會作廢）進行定期、階段性的清理； 創(chuàng)建資料庫的訪問規(guī)則、權限； 定期對資料庫進行檢查，并對文檔管理流程進行評估，應當確保文檔管理流程工作正常而且符合公司、項目組和利益相關方的需求； 5、關于項目開發(fā)與測試等其他人員，同樣需要

7、注意文檔提交、更新、維護等的規(guī)范，建議如下： 1）開發(fā)和測試人員在提交相關文檔后，自己應有備份。 2）軟件開發(fā)和測試人員可根據(jù)工作需要在自己手中保存一些個人文檔。這些一般應是主文本的副本，并注意和提交的主文本保持一致，在作必要的修改時，也應及時通知文檔管理人員。 3）在新文檔取代舊文檔時，管理人員應及時清理舊文檔。在文檔內(nèi)容有改動時，管理人員應隨時修訂主文本，使其及時反映更新了的內(nèi)容。 4）項目開發(fā)結束時，文檔管理人員應及時收集開發(fā)和測試人員的個人文檔。發(fā)現(xiàn)個人文檔與主文本有差別時，應立即著手解決。這常常是未及時修訂主文本造成的。 5）在軟件開發(fā)過程中，可能發(fā)現(xiàn)需要修改已完成的文檔，特別是規(guī)模

8、較大的項目，主文本的修改必須特別謹慎。修改以前要充分估計可能帶來的影響，并且要按照：提議、評議、審核、批準和實施等的步驟加以嚴格控制。 其他建議： 1）版本控制管理可包括工具軟件的使用和人為規(guī)范的遵循有控制意識、對工具的熟練使用，認為的良好習慣，和規(guī)范的制度的保證。 2）版本控制管理員設置一人或數(shù)人兼顧此角色，沒必要是全職，保證安全性問題，控制認為任意操作。 3）向版本控制過渡時一個循序漸進的、持久的過程需要逐步轉變，制訂一系列的循序漸進的措施，使版本控制的意識逐步得到認可，使人員逐漸養(yǎng)成良好習慣。 4）分為開發(fā)庫、文檔庫、產(chǎn)品庫、構建庫，這四個庫分別是獨立的單庫，版本不相互影響。 開發(fā)庫下項目一的相對路徑為：/dev/pro1，在pro1下為該項目的具體源碼結構樹； 文檔庫下項目一的相對路徑為： /doc/pro1，在pro1下為該項目的文檔樹結構（包括且不限于項目立項、項目結項、項目計劃、項目監(jiān)控、風險管理、配置管理.），相應的文檔 放入到相應的文件夾中； 構建庫下項目一的相對路徑為:/db/pro1，在pro1下為該項目不同時期的