一些公司用cmmi做軟體開發過程管理，對詳細設計過程要求很高，需產出rose設計模型，畫出序列圖、活**等等。本意是為了讓rose設計模型對後續的編碼有指導意義。但實際實施過程中發現效果不佳，一是有人不願意認真寫詳細設計文件，二是有人不願意看詳細設計文件，問題如下：
1）當詳細設計和編碼人員實際為同一人時：既然是同一人，自己做事心裡有數，整體想清楚了就開始編碼，而不願意寫詳細設計文件。
2）當詳細設計和編碼人員不是同一人時：編碼人員根本不願意看rose設計模型，一，詳細設計要畫的很細才有效果，這樣一來要讀懂別人的序列圖、活**反而不容易；二，如果詳細設計做的不夠細，那還不如直接看需求文件。
文件有兩個功能，乙個是指導下游工序進行工作，二是作為檔案供將來回憶或新人學習之用；由於上面兩個原因，rose設計模型的第乙個功能「指導下游工序進行工作」的功能實際是失效了；而第二個功能呢？在與許多從事軟體維護工作的開發人員訪談之後，得到的結論是：大多數人更願意直接看**，而不是看詳細設計文件（因為設計文件要不就是太粗略，要不就是太細、重點不突出，看不懂）。因此rose設計文件的第二個功能也失效了。這也驗證了前人說的一句話：設計文件是一次性的，或者：**即文件。
再談談設計的目的。設計分為架構設計、概要設計、詳細設計。如果說架構設計是規劃房子的地基，概要設計則是規劃房子的鋼筋混凝土框架、詳細設計就是規劃管道、線路、門窗、外表等等（其中以管道、線路為首要）。對應到軟體上，概要設計就是要規劃出軟體的結構 —— 模組、模組之間的關係、模組內部的類（介面）、類（介面）之間的關係。而詳細設計就是規劃出軟體裡的管道、線路，可以認為是貫穿全域性的演算法。
那麼設計文件該怎麼寫呢？設計文件不是越細越好，寫得細了也沒人看，稍微發生變化又要去修改。乙個合理的設計文件是結構清晰的、重點突出的，也就是概要設計+關鍵詳細設計。概要設計是對軟體結構的描述，包括類的責任、介面的責任；關鍵詳細設計，也就是對貫穿全域性演算法思路的描述。結構的描述，用類圖就可以了。而貫穿全域性的演算法，用序列圖活**可以，用文字描述也行。說清即可，僅此足矣。那麼類裡面的屬性、方法需要在rose模型裡體現嗎？這是不必要的，有時間乙個個輸入到rose裡，不如在ide裡編碼來的直接。
設計文件如何使用？首先在設計評審時，供評委評價。其次，對詳細設計和編碼有限定作用。而詳細設計編碼最好就是同乙個人來做，可省去不必要的文件交流。在編碼完成後，設計文件的使命也就完成了。後續沒有必要維護設計編碼一致性，就算要維護一致性，因為我們的設計文件是只抓重點的，而重點的都是不容易改變的，因此維護一致性的工作量也不大。
如何寫詳細設計文件
在大多數軟體專案中，要末不作詳細設計，要麼開發完成後再補詳細設計文件，質量也不容樂觀，文件與系統往往不能同步，使詳細設計文件完全流於形式，對工作沒有起到實際的幫助。那到底應不應該寫詳細設計文件呢，怎麼使詳細設計文件起到他應有的作用呢，下面就讓我們來認識一下詳細設計及寫詳細設計文件的好處和問題。什麼是...
如何寫詳細設計文件
在大多數軟體專案中，要末不作詳細設計，要麼開發完成後再補詳細設計文件，質量也不容樂觀，文件與系統往往不能同步，使詳細設計文件完全流於形式，對工作沒有起到實際的幫助。那到底應不應該寫詳細設計文件呢，怎麼使詳細設計文件起到他應有的作用呢，下面就讓我們來認識一下詳細設計及寫詳細設計文件的好處和問題。什麼是...
應該如何寫詳細設計文件
下面討論如何寫出乙個符合要求 實用的詳細設計文件。一 首 先是文件的內容，根據專案和團隊的不同，詳細設計文件的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模組 整體設計的關係 操作的處理流程，對業務規則的設計考慮等，有乙個標準為，凡是...