經常聽到領導教誨，開發的同事應該要往前走一步，去做產品？去做售前？這也是一種方式，只不過是一大步。個人覺得，在邁出這一大步之前，需要先走出一小步：從寫好**到做好設計。下圖是按照軟體工程的通用做法，梳理出的標準設計指南，已經非常清晰地定義了軟體設計的階段和活動，產物規約，文件要求以及需要配合的培訓。比較適合於人朋規模大、產品化程度高、外包服務模式。按照這個標準的設計指南，把每一階段的事情做好，這是標準的開發方**的實踐指導。
有人會說，現在是移動網際網路的時代，我們的產品開發要求短、頻、快地上線，這種標準的設計方法已經不適合了，我覺的不完全正確。我的做法是，根據產品的願景和市場情況，按照標準的設計指南做一些定製性的剪裁，哪怕文件全部裁完了，腦子裡分析時仍然要按照這幾個階段開展對應的活動，因為這不僅是指南，更是方**，針對這個幾階段開展過的活動，下面就梳理下我的設計經驗。
首先是需求捕獲和分析階段，總是感覺需求在不斷地變化，老是怪市場和產品經理，其實很多情況是我們對需求的理解不到位。既有業務理解不準確，也有支撐方式不合理。還有一點就是將原型與需求沒有進行區分，原型不代表需求。將需求分析劃分為業務需求與系統需求兩個階段，做好領域分析，才能根本性地適應需求的不斷地變化。接下來談談如何做好系統分析，在這個階段一般又叫建領域模型，又叫概念模型，分析物件模型，它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。領域模型設計是需求分析的關鍵步驟。它幫助使用者及需求分析人員建立業務概念，確定使用者業務的問題域，系統涉及的業務範圍等等。
領域模型設計的一般步驟為：
1、從業務描述中提取名詞
2、從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、例項，形成問題域中操作實體的集合；
3、從業務實體集合中抽象業務模型，建立問題域的概念
4、用uml提供的方法和圖例進行領域模型設計、確定模型之間的關係。注：實體之間的關係，主要有泛化、依賴和關聯，關聯又分了一般關聯、聚合、組合等
簡言之，先分析出模型實體，然後找出模型實體之間的關係。
領域模型與實資料模型的關係：領域模型是與使用者溝通的乙個重要工具，是需求分析人員與使用者共同理解的概念，是彼此之間交流的語言。它是乙個分析模型，描述的是業務中涉及到的實體及其相互之間的關係，它是需求分析的產物，與問題域相關。同時給我們需求分析人員和系統功能提供了一定的擴充套件視野，看到將來需求的可能變化或可能存在的問題。而資料模型是系統設計、實現的一部分，描述的是對使用者需求在資料結構上的實現，當然資料模型中的概念模型設計與領域模型類似，缺乏的是實體之間更廣泛的關係描述。
軟體專案經驗談
軟體專案經驗。自己總結自己記錄，見笑了。剛寫完手賤誤刪，因太重要，復記一遍。2017.5.12 1.介面 a.樣式及布局 無論客戶端還是網頁，介面配色彩色不超過3種，字型大小不超過3類，字型不超過3種。功能用色彩不限制。選單布局注意行距，介面文字注意行距。b.易用性 考慮到大齡使用者和視力較差的弱勢...
系統設計經驗談（三）
2010 12 1 1.抽象的模組劃分圖是示意圖，在系統設計中應該有配套具體的模組關係圖對其進行解釋。2.環形呼叫關係的出現有時是不可避免的。盡量不要出現。2010 12 2 1.在複雜呼叫系統中，應該明確同步阻塞關係。2.在interpreter模式中，若需要崩潰恢復，不能使用凍結指令碼虛擬機器並...
OO分析設計經驗談
1.oo分析設計不一定用於oo語言,同樣適用於vb,php 以前版本 c等 程式設計之前最好進行oo設計,然後再進行編碼,這樣的 可讀性和易重構性要強得多.2.oo設計之前,首先應具備一定的oo概念.如果從來沒有接觸過,應好好補一下.3.uml是現在做oo設計的統一語言,應好好學習,應擁有一本 4....