昨天和今天上午，為了大家更好地合作，解決一部分出現的衝突和問題，我們小組和師兄一起研究了敏捷開發的
svn使用，發現了我們在開發時，需要注意的問題，也是我們思想上的缺失
!在自考的過程中我們解除了很多和專案開發相關的書籍，其中有《軟體開發工具》，《資訊系統開發與管理》，《網路經濟與企業管理》，《資訊資源管理》等等書籍，其中有不止一本書提到了軟體開發的過程：
1需求分析
2概要設計
3詳細設計
4編碼5測試
6軟體交付
7驗收其中需求分析分析我再上篇部落格詳細講了，這次主要是從概要設計和詳細設計兩個對比的方便來談談我的收穫！
首先，系統的需求基本明朗之後，需要對軟體系統進行概要設計，即系統分析與設計。包括系統的基本處理流程、系統的組織結構、模組劃分、功能分配、介面設計、執行設計、資料結構設計和出錯處理設計等，為下一步工作提供基礎。
而在這一步，我們其他的做的還說的過去，但是，其中，模組劃分和全域性性的規定做的尤為不足，導致了後期的很多問題！
svn的衝突問題，也是由此產生，我們做的時候沒有及時規定統一的字首與字尾，沒有統一的資料夾管理，也沒有抽象好公用類，導致開發的重複，修正工作佔據了過大的時間部分！
而我們另外乙個錯誤就是會議的缺失，我們確定嘗試敏捷開發的基本方法後，忽略了敏捷開發的特點，就是及時溝通，敏捷變化，導致問題的積累較為嚴重，直接導致一段時間的進度停滯！
在稍後的詳細設計中，我們也犯了全域性性的錯誤，其中
svn的設計出了較大的紕漏，我們為此也付出了相應的代價，就是整體停滯了
2天，當然原因不僅僅是
svn，但是這是個引子，後來我細細想想之後發現，這是乙個團隊進行到乙個階段的必然現象！
現在的問題就是怎麼解決以及如何在以後的工作中規避！我仔細想想這裡的問題是激勵機制的問題，系統的複雜性要在合適的時機合適地增加難度，系統的完成度，鬆緊程度要實時更新，在大前提不變的前提下，適時調整!
1，沒有乙個真理可以讓我們的團隊成為優秀的團隊，我們堅信我們是最優秀的團隊，我們就一定可以是最優秀的團隊，我們的效率也會是最高的。不要為了一時的鬆緊而緊張，是我們在掌握進度，而不是進度掌握我們！
2，沒有什麼是我們不了解的，只是我們還沒有了解，再新鮮的技術，與自己的知識體系一定可以掛鉤！
3，沒有什麼是不可能的，不要急著下結論，做了在討論！有時候的表象不是我們想要的，但是深深挖掘，我們發現，他恰恰就是我們最需要的！
軟體開發設計文件
專案名稱 概要設計說明書 v1.0 版本號 擬 制 人 審 核 人 批 準 人 一九九九年八月二十日 概要設計說明書 1 引言 1.1編寫目的 說明編寫這份概要設計說明書的目的，指出預期的讀者。1.2背景 a.待開發軟體系統的名稱 b.列出本專案的任務提出者 開發者 使用者。1.3定義 列出本檔案中...
軟體開發平台設計 cxd
軟體開發平台設計 一 實體設計 對資料庫的表的設計，以及表的相關資訊，表字段的相關資訊 此處最大的難點是能否做得比 sql server 方便，否則意義大減 二 表單設計 表單設計目前有 3種方案 1.將表單資訊全存入資料庫中，庫戶端只用乙個 dll呼叫資料庫的表單資訊，執行時組成介面。優點 做表單...
軟體開發設計文件模版
開發團隊 部門 組長 組員 備註 可以把上面的內容放在乙個好看的封面頁上。文件更新記錄 版本說明 完成日期 修改人建立文件 對專案的背景進行介紹 比如為什麼要開發這個系統 對整個系統的情況進行介紹。列舉參考的文件 該系統需要完成的基本功能，對系統的大體描述 該系統涉及的開源專案等 本設計文件作為xx...