專案一個迭代週期內的開發流程
阿新 • • 發佈：2019-01-08
軟體專案開發，一般都會採用增量、迭代、（或者叫進化、演化、演進）的軟體開發模型，眾多的軟體開發模型大多是以經典的瀑布模型為基礎進行改進、變形，改進原則是：增加客戶在整個專案週期中的參與度，降低軟體開發過程中的風險，增強軟體專案的後期可維護性。
不 同的軟體開發模型，迭代週期長短也不相同，有的是一個月，有的是兩週，我們一般都是根據實際情況確定，一個週期完成，將專案成果（可執行的軟體）提交給用 戶（或進行內部評審），通過後就進入下一個迭代開發週期，每一個活動，將在下面詳細說明。
一、明確客戶（使用者）。客戶和使用者一般指的是最終使用軟體系統的人或為系統付費的人，搞不清楚目標客戶（使用者）會造成需求上的偏差。比如一個網站專案，或是一個外包專案，你首先得搞明白軟體專案的目標客戶（使用者）。
二、市場調研，可行性分析。 針對目標客戶，對軟體專案或產品的目前市場狀況、目標客戶的情況以及公司的開發資源等各個方面因素進行綜合分析考慮，確定專案市場與技術上的可行性，如果 發現風險過大，或可行性太低，專案就必須得終止。本階段一般會產生市場調研報告或市場分析報告等文件。如果專案可行，就算是立項了。
準備自己創業的同學一定要注意市場調研哦，千萬不能想當然，還一腔熱血，不要迷戀網上的成功創業傳奇。
三、需求採集。對目標客戶進行需求的採集，方法很多，這列幾個：部門訪談、中上層領導訪談、問卷調配、同類型軟體分析、電話會議等等，收集回來的資料包括客戶工作中的報表、表格，訪談記錄，會記錄、問卷調查表等。
四、需求分析、整理。
五、形成需求（規約）分析說明書。需求分析說明書的完成標誌著軟體生命週期中的第一個重要里程碑完成，需求分析說明書可以用兩種形式來描述使用者的需求：
A、 按功能模組來劃分。具體思路是把整個大的系統按邏輯分成子模組功能，子功能再具體細分，直到確信某子功能可以實現為止。這種方式來描述需求有一些缺點，主 要表現在隔離了模組的角色與操作環境，不好把握需求與設計的界線，優點是非常容易對映到實現上（一般一個子功能就是一個選單項）。這種方法很多大公司至今 都還在用，也許是老程式設計師已經習慣了這種需求描述的方式吧。
B、按用例來劃分。用例是現在很多公司採用的需求描述方式。用例檔案是需求主要描述的地方，用例檔案描述的是一個會話環境，更加的形象、生動，推薦大家按這種方式來做，我也是習慣於用例來描述需求。
在前面五個環節中，還有兩個活動流程是貫穿在其中的，它們是介面原型和領域模型。我認為這兩個軟體活動，在軟體開發早期就開始了，並且在後續軟體開發流程中，都可以找到它們的身影，下在就來談談這兩個重要的活動。
原型法是 我認為在軟體開發過程中必不可少的過程，而且非常的重要。我在這裡指的原型法，主要是介面原型（架構原型或技術探索原型先不在這討論），介面原型分兩個階 段來做，分別是原型設計與原型實現，在web專案中，會有不同的工具，並且側重點也是不同的，具體請參閱我的別一篇文章。總的來說，沒有介面原型，後面的 開發流程都免談。打個比方：你要創作一幅油畫，應該先有一個構思，先要有素描稿、色彩稿，要做到心中有數，否則，後期的創作將無從談起。我現在的任何一個 專案，都是由原型設計開始，原型設計通過評審後，再進行原型實現。
領域模型的重要性大家應該非常清楚，在DDD一書中已有詳細的論 述。領域模型是我們軟體開發活動中的一種重要溝通工具，在需求採集、整理階段就已經可以採用，我們可以用它來和客戶溝通，可以固化我們對需求的理解，隨著 對需求的不斷深入，領域模型將不斷完善。領域模型是一個專案的精髓，就像一幅肖像畫中的神，它是更本質、更核、更深層的東西，不容易隨著需求的變化而變 化。
有一些人和我糾纏介面原型、領域在軟體活動中的順序，比如：先寫用例文字，再尋找領域；先寫介面原型，再寫需求文件等等，如果 你也存在這樣的困惑，那就說明你犯了教條主義的錯誤，讀書讀死了。軟體開發的各個響動，都是以降低軟體開發風險，保證功能開發為目的的，無論什麼活動，什 麼工具，只要你認為對當前所處的開發階段有用，就可以大膽採用，無要再在順序上過於糾結。
領域模型做完後，有的公司會用一些方法對域模型的可行性 進行驗證，常用工具是DB4O，一種面向物件的資料庫，具體做法是：結合介面原型實現，直接在Controller層中通過DB4O完成主要域物件與頁面 的互動，如果發現領域問題就可以及時修正，減少後期存在的一引起風險因素。
六、概要設計。這一過程架構師參與得多一些，主要是根據需求分析階段的成果（重點要考慮非功能性需求），進行架構的確定，包括業務架構（如果一個公司初入某一行業領域，可能無法確定業務架構），系統架構，技術實現架構等，這一階段可能還會對領域模型進一步的細化。
七、詳細設計。該階段應該完成編碼前的所有準備工作，主要完成以下的任務：
A、 ER模型。可參照領域模型，完成ER模型的設計，最終結果基本和域模型一致。有的UML工具可以由領域模型直接匯出ER模型，經常有人問題有了領域模型， 為什麼要建立ER模型呢？因為我們要由ER轉物理模型，在PD中由ER轉物理模型非常方便，並且可以選擇不同的底層資料庫，建了ER後資料庫移植將非常的 方便。
B、物理模型。由er直接轉面物理模型，再由物理模型匯出資料字典，建表sql，在PD中還可以自動生成測試資料，因此，物理模型這一步是 必須要做的。我見過有人是先寫好領域物件，再寫好hbm，然後動態生成表，這種做法不是太好，因為在實際的生產環境中，資料庫和領域物件是不匹配的，存在 阻抗，所以，資料字典對於開發、維護，都絕對是一份非常重要的文件，也就是說一定要有物理模型。
C、詳細設計包層次結構，包中的類，類中的方法及屬性，總之，編碼前的一切準備工作都要做好。
D、本次迭代的週期的人員分工，計劃等。人員分工可按用例（或功能）來分配，也可以按層來分配（比如：dao,service,action等），任務分配要考慮到任務是否存在時間上和邏輯上的先、後依賴關係。
E、如果持久層是hibnerate、ibatis等orm框架，要事先安排一到兩人來完成整個系統的關係對映檔案（如果用 hibernate，這點很重要，不要讓每個實現者去寫自己的hbm）。
F、專案的第一個版本，上傳版本控制伺服器，每位開發人員檢出專案。
八、編碼實現，單元測試。 程式設計師在這個階段按照分工及業務需求，進行程式碼實現。如果是按用例（或功能）來分工的，必須要求程式設計師從底層向上層寫，最好按測試驅動開發（TDD）方式 來做，寫一層，測一層，保證底層的實現正確性後再向上寫。編碼階段管理者還要注意時間上的控制，業務程式碼實現大約佔比20%，頁面互動、實現約佔80%的 編碼實現週期，做計劃時要做到心中有數。如果是程式新手，還得分階段對程式碼進行評審，對不規範的程式碼進行及時指正，以保證程式碼的質量。
九、測試。本階段專業的測試人員參與多一些，一般的公司可採用下面的流程。
A、首先是一個整合測試，必須保證每個程式設計師寫的東西可以做為一個專案整體正確執行；
B、功能性測試，可以用工具來簡化（比如：Selenium），但對前期設計要求很高，如果你的前期設計沒有達到這個程度，最好是用人進行手工測試了。比如一些web game，還只能用人來進行測試功能。
C、 壓力測試。壓力測試是針對於非功能性需求的，選擇一些重要的功能進行壓力測試，得到測試報告（得到系統的效能引數後有針對性的優化），可選擇工具有 ab，loadruner，jmeter等等，要注意的是壓力測試是要有針對性的，一般不會整個專案的全部功能都進行壓力測試。根據測試結果，還要進行性 能調優，至少得滿足非功能性需求吧。
十、使用者驗收。把階段性果（可執行軟體）交付使用者使用，收集使用者反饋，準備下一階段的迭代準備。如果本次的軟體迭代成品是不可執行的，或不需要向客戶交付，只需進行一個內部驗收或評審即可。
十一、專案部署，維護，二次開發等。 軟體開發流程是一環扣一環的，前一階段的沒有做好，一定會對後一階段造成影響。如果前面的工作做得不紮實，存在一些問題，那麼在專案的執行維護期，就等著 前期把掙到的錢一點一點還回去吧。什麼開閉原則，高耦合低內聚，程式碼質量，文件完整性等等這些，我相信在這個階段你一定會感受到它們的重要性，這些東西絕 對不是空洞的理論。
上面是對軟體開發流程中各個活動進行了一個簡單的介紹，下面來談談活動的時候及專案管理者如何來管理（主要針對一個已經有需求文的專案，如何帶領程式設計師來實現，假設程式設計師都是些新手，初級程式設計師）。
一個月的時候分為四周，共20個工作日，每週的具體安排如下：
第一週：
A、下發需求文件，必須要明確如何去閱讀需求文件。
B、 在閱讀的過程中，認真思考業務流程，並進行介面原型的設計（這是讓程式設計師儘快熟悉需求的最好辦法）。本過程的原則是：快速，每張介面原型中要合理佈局主要 的介面元素以及要標明頁面間的跳轉流程，所用工具：Balsamiq Mockups。做好後的原型全部整合到一起，進行總體評審，在評審的過程中，需求將會得到了進一步的明確和理解。（2天）
稽核不合格的，要求進行再次修改，修改完後再次評審。評審以小組為單位，結合業務流程，在PC上進行逐頁進行檢查，也可以使用投影儀，由頁面實現者根據原型設計自己講解業務。
（注：本過程之前一定要下發頁面原型規範，明確稽核標準）
C、原型實現。以前期的原型設計為基礎，進行可重用原型的實現，工具為DW。原則是：按最終的實現去做，儘量細化，詳細確定介面上的原素細節。css、js、目錄劃分、頁面命名、頁面元素命名這些事項都要進行明確。
（注：本過程前期要講清楚原型實現的要求、細節，下發頁面框架，在框架的基礎上實現，以達到效果的統一）
普通web專案原型實現要用到js框架，我們一般選擇jQuery ui。（3天）
時間安排上，原型設計約2天時間，原型實現3天時間。第一週完成後的專案成果有：原型設計存檔檔案，原型實現存檔檔案。
第二週：
A、 領域模型設計。以OOA理論為基礎，結合介面原型、需求檔案以及自身對業務的理解，小組討論通過形成第一個版本的領域模型，確保大的結構符合業務需求。第 一個版本的領域模型只包括物件的重要屬性及物件間的組合聚合、泛化關係，已經搞清楚的關聯數量關係一定要標出，領域物件一定要取合理的名字。這個過程完成 後，要求小組的每個程式設計師能夠根據領域物件圖描述自己的業務流程（1天）
（注：這個過程也可以在第一週討論業務的時候就開始進行，我一般都會向前提）
B、 在第一個版本的領域模型圖的基礎上，結合介面原型，進一步完善領域物件的屬性及關係，這個時候必須要做細緻，類名及屬性名全部用翻譯成英文（描述要用中文 寫好，匯出的程式碼中就會有中文註釋）；物件間的關聯關係線全部用具體屬性表示；根據業務確定是單向還是雙向關聯；新增資料庫主鍵；實現序列化介面；例項化 所有集合。
C、進行資料庫ER設計，匯出建表sql，生成資料庫測試資料，生成資料字典。（B、C兩步共用2天時間）
D、進行詳細設計，根據規範建立包名，從uml工具中匯出領域物件；根據介面原型及需求（用例）確定業務物件粒度，完成業務層業務方法的設計（業務層業務方法設計這一步也可以省略，按敏捷方法在實現時自行靈活新增）。
E、 建立一個動態web工程，在公司現有架構基礎上（這時要對架構進行講解），按規範建立初始版本，主要做三件事：生成orm對映檔案，確保基本正確無誤；所 有html頁面轉換為jsp頁面，注意轉換的一些注意事項，要確保新建立起來的專案能夠正確啟動執行，所有頁面均可訪問，外觀不變形；初始版本專案提交至 版本控制伺服器，每位組員根據賬號密碼檢出一份專案程式碼（1天）。
F、第二週要建立起編碼前的所有準備工作，小組後面兩週的計劃要制定出來，有橫向的人員模組分工，有縱向的哪一天寫到哪一個層次。專案管理人員要對編碼前所完成的工作進行稽核，確保無誤。
第二週的階段性成果有：領域模型，資料字典，設計模型，專案後期開發計劃，ORM對映文件等。
第三週：
進 行編碼期，這個時期要求程式設計師從業務層實現寫起，junit測試程式碼與實現程式碼交替進行（基本按照TDD來做），測試過程中會發現ORM對映檔案可能有問 題，表結構或許也有問題，這個時候要進行小的調整（所有的表結構、類、orm調整均由專案負責人進行）。專案管理人員在這個時間主要是對程式碼進行稽核，確 保符合編碼規範。
業務層程式碼的編寫與測試時間大約為2~3天，後面的時間進行頁面的互動實現。
頁面的互動花費的時候非常多，工作量也很大，這項工作會持續到第四周。
第四周：
頁面的互動實現，專案整合整合，整合測試，功能性測試，壓力測試等。
本 周花在頁面互動實現的時間約2~3天，整合測試1~2天，壓力測試及最後的整合1天，根據程式設計師的整體水平的不同，本週的時間可能會非常倉促。如果前面幾 周的工作沒有做紮實，這周受到的影響會非常大。如果專案最終結果沒有達到，時間可能會順延幾天，這樣也致使專案在一個迭代週期中無法完成，如果一定要以固 定週期迭代，只有在專案前期減少本次迭代的任務。
最後說一點，每個公司都會根據專案特點和自身習慣，找到一條符合公司實際情況的開發流程，但總的原則只有一個，那就是儘量降低軟體開發過程中的風險，確保專案成功開發。
不 同的軟體開發模型，迭代週期長短也不相同，有的是一個月，有的是兩週，我們一般都是根據實際情況確定，一個週期完成，將專案成果（可執行的軟體）提交給用 戶（或進行內部評審），通過後就進入下一個迭代開發週期，每一個活動，將在下面詳細說明。
一、明確客戶（使用者）。客戶和使用者一般指的是最終使用軟體系統的人或為系統付費的人，搞不清楚目標客戶（使用者）會造成需求上的偏差。比如一個網站專案，或是一個外包專案，你首先得搞明白軟體專案的目標客戶（使用者）。
二、市場調研，可行性分析。 針對目標客戶，對軟體專案或產品的目前市場狀況、目標客戶的情況以及公司的開發資源等各個方面因素進行綜合分析考慮，確定專案市場與技術上的可行性，如果 發現風險過大，或可行性太低，專案就必須得終止。本階段一般會產生市場調研報告或市場分析報告等文件。如果專案可行，就算是立項了。
準備自己創業的同學一定要注意市場調研哦，千萬不能想當然，還一腔熱血，不要迷戀網上的成功創業傳奇。
三、需求採集。對目標客戶進行需求的採集，方法很多，這列幾個：部門訪談、中上層領導訪談、問卷調配、同類型軟體分析、電話會議等等，收集回來的資料包括客戶工作中的報表、表格，訪談記錄，會記錄、問卷調查表等。
四、需求分析、整理。
五、形成需求（規約）分析說明書。需求分析說明書的完成標誌著軟體生命週期中的第一個重要里程碑完成，需求分析說明書可以用兩種形式來描述使用者的需求：
A、 按功能模組來劃分。具體思路是把整個大的系統按邏輯分成子模組功能，子功能再具體細分，直到確信某子功能可以實現為止。這種方式來描述需求有一些缺點，主 要表現在隔離了模組的角色與操作環境，不好把握需求與設計的界線，優點是非常容易對映到實現上（一般一個子功能就是一個選單項）。這種方法很多大公司至今 都還在用，也許是老程式設計師已經習慣了這種需求描述的方式吧。
B、按用例來劃分。用例是現在很多公司採用的需求描述方式。用例檔案是需求主要描述的地方，用例檔案描述的是一個會話環境，更加的形象、生動，推薦大家按這種方式來做，我也是習慣於用例來描述需求。
在前面五個環節中，還有兩個活動流程是貫穿在其中的，它們是介面原型和領域模型。我認為這兩個軟體活動，在軟體開發早期就開始了，並且在後續軟體開發流程中，都可以找到它們的身影，下在就來談談這兩個重要的活動。
原型法是 我認為在軟體開發過程中必不可少的過程，而且非常的重要。我在這裡指的原型法，主要是介面原型（架構原型或技術探索原型先不在這討論），介面原型分兩個階 段來做，分別是原型設計與原型實現，在web專案中，會有不同的工具，並且側重點也是不同的，具體請參閱我的別一篇文章。總的來說，沒有介面原型，後面的 開發流程都免談。打個比方：你要創作一幅油畫，應該先有一個構思，先要有素描稿、色彩稿，要做到心中有數，否則，後期的創作將無從談起。我現在的任何一個 專案，都是由原型設計開始，原型設計通過評審後，再進行原型實現。
領域模型的重要性大家應該非常清楚，在DDD一書中已有詳細的論 述。領域模型是我們軟體開發活動中的一種重要溝通工具，在需求採集、整理階段就已經可以採用，我們可以用它來和客戶溝通，可以固化我們對需求的理解，隨著 對需求的不斷深入，領域模型將不斷完善。領域模型是一個專案的精髓，就像一幅肖像畫中的神，它是更本質、更核、更深層的東西，不容易隨著需求的變化而變 化。
有一些人和我糾纏介面原型、領域在軟體活動中的順序，比如：先寫用例文字，再尋找領域；先寫介面原型，再寫需求文件等等，如果 你也存在這樣的困惑，那就說明你犯了教條主義的錯誤，讀書讀死了。軟體開發的各個響動，都是以降低軟體開發風險，保證功能開發為目的的，無論什麼活動，什 麼工具，只要你認為對當前所處的開發階段有用，就可以大膽採用，無要再在順序上過於糾結。
領域模型做完後，有的公司會用一些方法對域模型的可行性 進行驗證，常用工具是DB4O，一種面向物件的資料庫，具體做法是：結合介面原型實現，直接在Controller層中通過DB4O完成主要域物件與頁面 的互動，如果發現領域問題就可以及時修正，減少後期存在的一引起風險因素。
六、概要設計。這一過程架構師參與得多一些，主要是根據需求分析階段的成果（重點要考慮非功能性需求），進行架構的確定，包括業務架構（如果一個公司初入某一行業領域，可能無法確定業務架構），系統架構，技術實現架構等，這一階段可能還會對領域模型進一步的細化。
七、詳細設計。該階段應該完成編碼前的所有準備工作，主要完成以下的任務：
A、 ER模型。可參照領域模型，完成ER模型的設計，最終結果基本和域模型一致。有的UML工具可以由領域模型直接匯出ER模型，經常有人問題有了領域模型， 為什麼要建立ER模型呢？因為我們要由ER轉物理模型，在PD中由ER轉物理模型非常方便，並且可以選擇不同的底層資料庫，建了ER後資料庫移植將非常的 方便。
B、物理模型。由er直接轉面物理模型，再由物理模型匯出資料字典，建表sql，在PD中還可以自動生成測試資料，因此，物理模型這一步是 必須要做的。我見過有人是先寫好領域物件，再寫好hbm，然後動態生成表，這種做法不是太好，因為在實際的生產環境中，資料庫和領域物件是不匹配的，存在 阻抗，所以，資料字典對於開發、維護，都絕對是一份非常重要的文件，也就是說一定要有物理模型。
C、詳細設計包層次結構，包中的類，類中的方法及屬性，總之，編碼前的一切準備工作都要做好。
D、本次迭代的週期的人員分工，計劃等。人員分工可按用例（或功能）來分配，也可以按層來分配（比如：dao,service,action等），任務分配要考慮到任務是否存在時間上和邏輯上的先、後依賴關係。
E、如果持久層是hibnerate、ibatis等orm框架，要事先安排一到兩人來完成整個系統的關係對映檔案（如果用 hibernate，這點很重要，不要讓每個實現者去寫自己的hbm）。
F、專案的第一個版本，上傳版本控制伺服器，每位開發人員檢出專案。
八、編碼實現，單元測試。 程式設計師在這個階段按照分工及業務需求，進行程式碼實現。如果是按用例（或功能）來分工的，必須要求程式設計師從底層向上層寫，最好按測試驅動開發（TDD）方式 來做，寫一層，測一層，保證底層的實現正確性後再向上寫。編碼階段管理者還要注意時間上的控制，業務程式碼實現大約佔比20%，頁面互動、實現約佔80%的 編碼實現週期，做計劃時要做到心中有數。如果是程式新手，還得分階段對程式碼進行評審，對不規範的程式碼進行及時指正，以保證程式碼的質量。
九、測試。本階段專業的測試人員參與多一些，一般的公司可採用下面的流程。
A、首先是一個整合測試，必須保證每個程式設計師寫的東西可以做為一個專案整體正確執行；
B、功能性測試，可以用工具來簡化（比如：Selenium），但對前期設計要求很高，如果你的前期設計沒有達到這個程度，最好是用人進行手工測試了。比如一些web game，還只能用人來進行測試功能。
C、 壓力測試。壓力測試是針對於非功能性需求的，選擇一些重要的功能進行壓力測試，得到測試報告（得到系統的效能引數後有針對性的優化），可選擇工具有 ab，loadruner，jmeter等等，要注意的是壓力測試是要有針對性的，一般不會整個專案的全部功能都進行壓力測試。根據測試結果，還要進行性 能調優，至少得滿足非功能性需求吧。
十、使用者驗收。把階段性果（可執行軟體）交付使用者使用，收集使用者反饋，準備下一階段的迭代準備。如果本次的軟體迭代成品是不可執行的，或不需要向客戶交付，只需進行一個內部驗收或評審即可。
十一、專案部署，維護，二次開發等。 軟體開發流程是一環扣一環的，前一階段的沒有做好，一定會對後一階段造成影響。如果前面的工作做得不紮實，存在一些問題，那麼在專案的執行維護期，就等著 前期把掙到的錢一點一點還回去吧。什麼開閉原則，高耦合低內聚，程式碼質量，文件完整性等等這些，我相信在這個階段你一定會感受到它們的重要性，這些東西絕 對不是空洞的理論。
上面是對軟體開發流程中各個活動進行了一個簡單的介紹，下面來談談活動的時候及專案管理者如何來管理（主要針對一個已經有需求文的專案，如何帶領程式設計師來實現，假設程式設計師都是些新手，初級程式設計師）。
一個月的時候分為四周，共20個工作日，每週的具體安排如下：
第一週：
A、下發需求文件，必須要明確如何去閱讀需求文件。
B、 在閱讀的過程中，認真思考業務流程，並進行介面原型的設計（這是讓程式設計師儘快熟悉需求的最好辦法）。本過程的原則是：快速，每張介面原型中要合理佈局主要 的介面元素以及要標明頁面間的跳轉流程，所用工具：Balsamiq Mockups。做好後的原型全部整合到一起，進行總體評審，在評審的過程中，需求將會得到了進一步的明確和理解。（2天）
稽核不合格的，要求進行再次修改，修改完後再次評審。評審以小組為單位，結合業務流程，在PC上進行逐頁進行檢查，也可以使用投影儀，由頁面實現者根據原型設計自己講解業務。
（注：本過程之前一定要下發頁面原型規範，明確稽核標準）
C、原型實現。以前期的原型設計為基礎，進行可重用原型的實現，工具為DW。原則是：按最終的實現去做，儘量細化，詳細確定介面上的原素細節。css、js、目錄劃分、頁面命名、頁面元素命名這些事項都要進行明確。
（注：本過程前期要講清楚原型實現的要求、細節，下發頁面框架，在框架的基礎上實現，以達到效果的統一）
普通web專案原型實現要用到js框架，我們一般選擇jQuery ui。（3天）
時間安排上，原型設計約2天時間，原型實現3天時間。第一週完成後的專案成果有：原型設計存檔檔案，原型實現存檔檔案。
第二週：
A、 領域模型設計。以OOA理論為基礎，結合介面原型、需求檔案以及自身對業務的理解，小組討論通過形成第一個版本的領域模型，確保大的結構符合業務需求。第 一個版本的領域模型只包括物件的重要屬性及物件間的組合聚合、泛化關係，已經搞清楚的關聯數量關係一定要標出，領域物件一定要取合理的名字。這個過程完成 後，要求小組的每個程式設計師能夠根據領域物件圖描述自己的業務流程（1天）
（注：這個過程也可以在第一週討論業務的時候就開始進行，我一般都會向前提）
B、 在第一個版本的領域模型圖的基礎上，結合介面原型，進一步完善領域物件的屬性及關係，這個時候必須要做細緻，類名及屬性名全部用翻譯成英文（描述要用中文 寫好，匯出的程式碼中就會有中文註釋）；物件間的關聯關係線全部用具體屬性表示；根據業務確定是單向還是雙向關聯；新增資料庫主鍵；實現序列化介面；例項化 所有集合。
C、進行資料庫ER設計，匯出建表sql，生成資料庫測試資料，生成資料字典。（B、C兩步共用2天時間）
D、進行詳細設計，根據規範建立包名，從uml工具中匯出領域物件；根據介面原型及需求（用例）確定業務物件粒度，完成業務層業務方法的設計（業務層業務方法設計這一步也可以省略，按敏捷方法在實現時自行靈活新增）。
E、 建立一個動態web工程，在公司現有架構基礎上（這時要對架構進行講解），按規範建立初始版本，主要做三件事：生成orm對映檔案，確保基本正確無誤；所 有html頁面轉換為jsp頁面，注意轉換的一些注意事項，要確保新建立起來的專案能夠正確啟動執行，所有頁面均可訪問，外觀不變形；初始版本專案提交至 版本控制伺服器，每位組員根據賬號密碼檢出一份專案程式碼（1天）。
F、第二週要建立起編碼前的所有準備工作，小組後面兩週的計劃要制定出來，有橫向的人員模組分工，有縱向的哪一天寫到哪一個層次。專案管理人員要對編碼前所完成的工作進行稽核，確保無誤。
第二週的階段性成果有：領域模型，資料字典，設計模型，專案後期開發計劃，ORM對映文件等。
第三週：
進 行編碼期，這個時期要求程式設計師從業務層實現寫起，junit測試程式碼與實現程式碼交替進行（基本按照TDD來做），測試過程中會發現ORM對映檔案可能有問 題，表結構或許也有問題，這個時候要進行小的調整（所有的表結構、類、orm調整均由專案負責人進行）。專案管理人員在這個時間主要是對程式碼進行稽核，確 保符合編碼規範。
業務層程式碼的編寫與測試時間大約為2~3天，後面的時間進行頁面的互動實現。
頁面的互動花費的時候非常多，工作量也很大，這項工作會持續到第四周。
第四周：
頁面的互動實現，專案整合整合，整合測試，功能性測試，壓力測試等。
本 周花在頁面互動實現的時間約2~3天，整合測試1~2天，壓力測試及最後的整合1天，根據程式設計師的整體水平的不同，本週的時間可能會非常倉促。如果前面幾 周的工作沒有做紮實，這周受到的影響會非常大。如果專案最終結果沒有達到，時間可能會順延幾天，這樣也致使專案在一個迭代週期中無法完成，如果一定要以固 定週期迭代，只有在專案前期減少本次迭代的任務。
最後說一點，每個公司都會根據專案特點和自身習慣，找到一條符合公司實際情況的開發流程，但總的原則只有一個，那就是儘量降低軟體開發過程中的風險，確保專案成功開發。