? ? 從4月3號到5月7號機房收費系統合作版終于告一段落。從寫文檔到畫UML圖，到加設計模式對文檔進行補充，然后是編碼，測試發布。時間持續了一個月，遇到的問題很多，當然收獲也很多。

由于之前已經做過幾遍機房收費系統了對系統的功能已經很熟悉了，所以這次合作開發就省去了可行性分析、對系統功能的具體分析等工作，那么接下來就是寫文檔了。雖然之前個人版機房收費系統已經試著寫過文檔了，但那些文檔基本上都是寫給自己看，多點什么內容無關緊要，少點什么內容自己也察覺不出來，畢竟個人版的系統涉及到的所有人員只有自己一個人。但合作開發就不一樣了，合作開發要求項目要文檔來驅動，所有的東西都要體現在文檔上，避免直接交流都要以文檔來代替。一開始寫文檔時真不知道如何下手，該從哪去寫，各個文檔里都要具體寫什么內容。怎么寫才能體現出系統的設計思路及實現思路以方便小組成員開發的時候參考。

? ? 這次合作開發主要寫了可行性分析、需求分析、概要設計、詳細設計、數據庫設計、測試計劃、項目開發計劃、用戶操作手冊幾個文檔。比較重要的是需求分析文檔、概要設計文檔、詳細設計文檔、數據庫設計文檔還有就是測試文檔。

需求分析

? ? 需求分析，需求分析是系統設計的前提，一個系統設計的是不是合理，功能是不是完善主要看需求分析階段的需求分析做的好不好。作為軟件的設計者來說，需求分析文檔是寫給客戶看的也是寫給自己看的。寫給客戶看主要是看有沒有把客戶的所有需求考慮在內，體現在功能、界面設計上。客戶看到需求文檔并滿意后開發人員才能開始開發系統。如果將來軟件開發出來客戶對軟件有了變動，認為沒有達到他的需求此時需求文檔完全可以作為一份憑證，證明責任并不在我們開發人員身上。當然需求分析文檔最主要的還是寫給軟件設計人員自己看的。對于一個系統來說在各個方面都有要求，比如數據的輸入輸出、界面設計及系統所涉及的各項功能等。對于一個軟件設計師來說這些記在腦子里是沒用的，因為軟件設計師并不參與軟件的實現過程，在軟件的實現過程中編碼人員需要這些數據，而作為軟件設計者能為編程人員提供這些數據的一個平臺只有通過文檔來體現。所以需求分析文檔的主要的內容可以概括為軟件原型圖（為用戶提供一個軟件開發參考）、用例圖（向軟件設計者、軟件開發者提供系統功能模型）、數據輸入、輸出介紹（為軟件設計者、編程人員提供數據參考）。

概要設計文檔

? ?概要設計文檔主要是對系統的一個概要分析，是從整體上看系統的構成，如果把整個軟件當做一本書來看，概要設計文檔就應該和書的目錄的作用差不多了，是對書內容的整體的描述。所以在概要設計文檔里應該體現的內容應該包括系統架構（包圖）、類圖、接口設計、數據庫表說明等。站在使用者的角度來看，當然概要設計文檔是寫給項目開發人員用的。概要設計體現出對軟件的宏觀把控，內容不多但卻十分重要為軟件詳細指明方向。

詳細設計文檔

? ? 概要設計是對整個系統的整體描述，詳細設計文檔就是在概要設計的基礎上對系統設計的具體實現和完善。詳細設計文檔對于分層實現和合作開發來說十分重要。軟件實現人員（編程人員）首先要對系統有一個快速認識、了解，所以詳細文檔中系統的整體架構必不可少。有了對系統的整體認識，在軟件具體實現上用到的最多的還是類，開發人員需要實現他們并去使用他們，所以詳細設計文檔中對類、類中每個方法的功能描述、屬性的使用、參數的類型和使用等描述都是必不可少的。當然一個系統的實現不僅僅體現在單個類的實現上，還體現在多個類的協同上即類與類之間的調用。所以詳細設計文檔中第三個必不可少的內容就是時序圖及其描述。時序圖體現出在整個系統中或某個功能模塊中類與類之間的聯系及類與類之間的數據傳遞。把系統中的類看做節點有了時序圖做向導才把這些離散的點連起來組成網，從而構成了整個系統。

數據庫設計說明書

? ? 數據庫設計說明書主要體現數據庫的設計跟使用，所以數據庫設計說明書中應詳盡的描述數據庫的概念結構設計、邏輯結構設計和物理結構設計，當然數據庫名稱、數據表結構、各表字段及詳細說明、及視圖的說明都必不可少。數據庫是整個軟件應用的根基，是軟件設計的起點，它起著決定性的質變作用。站在數據庫的建立者和使用者的角度來看，數據庫設計說明書不僅要能夠使數據庫創建者能夠完成一個完整的數據庫設計，還要使數據庫使用者能夠在此說明書的指導下實現對數據庫的使用。

測試計劃文檔

? ? 測試文檔可千萬不能小瞧，一個系統開發完成，成功與否要看測試效果如何，測試效果的體現還要根據測試計劃文檔來評價，它直接體現著開發人員所開發出的系統是否跟軟件設計人員設計的系統之間的差距。所以測試文檔中應該體現出對各模塊功能測試的測試內容、測試方法、測試結果預測等。測試文檔主要的使用對象是軟件測試人員，是衡量一個系統是否成功的關鍵性文檔，也為后期修改指明了方向。

合作開發文檔的不足

? ? 這次合作寫的文檔明顯有許多不足之處，問題主要體現在詳細設計文檔和測試計劃文檔內容不詳細，有些關鍵的細節東西沒有體現出來。這次開發我負責寫文檔、畫圖和U層，坤哥負責B層跟抽象工廠，靜媛負責D層、接口跟數據庫。U層的問題還少點，這可能跟由我負責有關。B層是出現問題最多的層，主要的問題是詳細設計中體現的供代碼實現的信息太少，比如說各個方法的功能及實現及所需要的參數的說明等。最突出的一個問題是從D層返回給B層的DataTable數據，如果這些數據直接返回給U層還好說直接返回就行，當這些數據在B層需要的時候由于DataTable不像實體那樣對象名打點就能得到所需要的數據，所以對于坤哥來說DataTable就像一個密封的容器，明知道里邊有數據但只能眼睜睜的看著卻拿不到。D層跟數據庫出的問題主要是在數據表的查詢和字段的使用上。比如查詢正在上機時，可以根據IsOnline字段來判斷當前正在上機信息，由于信息沒體現出來所以該字段沒有用上基本上都是根據下機 時間、日期是否為空來判斷的，雖然這么做能夠實現功能但與預期的實現方式有差別。還有一個突出問題就是有些字段的值是固定可選擇的，比如說IsOnline字段的可選擇值為”是“或”否“，IsCheckout字段的可選擇值為“是”或“否”，還有就是上機記錄的備注信息“Comment”的可選擇值是“正常下機”和“全部下機”，由于這樣的數據沒有在文檔中將可選擇的值全部體現出來，所以測試的時候導致了數據庫中的值各種各樣。

總結：

? ? 寫文檔最最重要的是要明確使用對象，幾個文檔的使用對象包括客戶、設計人員自己、編程人員、后期維護人員，所有文檔的建立要站在使用者的角度去考慮文檔應該怎么寫、寫什么，所以寫文檔要牢牢把握為誰而寫。其次文檔還要明確的體現出設計思路及實現思路，要讓編程人員按你的設計思路和實現思路去實現。所以衡量文檔是否成功的標志是軟件的實現是否跟設計人員的設計思路和實現思路完全吻合。

總結

以上是生活随笔為你收集整理的合作开发后谈如何写文档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。