去年的八月份左右也就是在軟考之前為了體驗工程的感覺（或者說更好的準備軟考）我們進行了教務平臺的開發。從準備軟考的角度來說這個教務系統是成功的，而且非常的成功！因為在做教務的過程中我們遇到了很多問題和疑惑，而這些問題在后面準備軟考的學習當中都有相應的解答，所以說對于軟考來說那一遍做的教務是非常成功的。但是就教務本身而言是及其失敗的，雖然說可以跑起來，甚至于個別的小模塊獨立使用的時候效果還不錯。但是如果整體的教務跑的話必定會出這樣和那樣的問題。

安照相對正規的開發流程做完了DRP，回頭再看看我們當時的教務，又有新的感觸，特記錄于此和組員們共勉，權且當為第二次開發教務做準備吧。

Web開發（無論是java還是.Net）的一般的流程如下

1、需求確定

通過各種手段確定系統的功能與性能

功能：用戶維護、物料維護….

性能：可同時支持 n個并發訪問，并且響應時間不高于 m毫秒…

手段：

頭腦風暴 (brain storm)

會議

詢問

原型–界面原型、業務原型…

本階段是項目開發的最重要階段

在web項目中，通常界面設計會在本階段進行

 

針對此步驟的總結：

在做教務的時候因為時間的原因想早點兒做完這個系統，于是在做的過程中完全是憑自己的主觀臆斷去猜測需求，更不用說利用原型與客戶溝通確定需求了。所以一些模塊用戶根本就無法使用。

 

2、分析與設計

a)        架構分析與設計

邏輯架構

3層架構、n層架構…

MVC…

Model 1 or Model 2

…

物理架構

Web服務器的分布

數據庫服務器的分布

…

技術解決方案的確定

Java / .NET

Open Source /商業

…

 

針對此步驟的總結：

經典的三層架構幫助我們明確了各自的分工。敲定了使用.NET也使得的開發過程大大的縮短了。總的來說架構方面當時做的還是很不錯。

 

b)        業務邏輯分析

根據需求分析業務邏輯

有哪些人會使用本系統？

他們會使用本系統做什么？

通常他們使用本系統的步驟是什么樣的？

會有哪些明顯的類來支撐本系統的運行？

會有哪些不同的提示會返饋給用戶？

…

本階段與需求的確定密切相關，通常在確定需求的時候就會進行相關的分析

 

針對此步驟的總結：

因為前期的需求分析做的就不是很好，所以分析業務邏輯這步驟就約等于形同虛設了。上面幾個問題都得不到明確的答復。再做開發的時候一定一定先把上面的問題搞清楚了再動手去做，沒有思想的做永遠是徒勞。

 

c)        業務邏輯設計

根據需求的分析來確定具體的類

確定類的屬性

確定類的接口（方法）

確定類之間的關系

確定用戶操作流程在設計上的反映

進行數據庫的設計

不同的項目步驟可能不盡相同

…

針對此步驟的總結：

個人認為最重要的就是數據庫設計，回想上次的教務系統，做到了最后還在改動表的結構，后果可想而知----牽一發而動全身。為了有效的解決這個問題我們唯一能做的就是在前期把需求分析做的詳細詳細再詳細，在業務邏輯分析階段和客戶溝通的細致細致再細致，把每條業務邏輯都走一遍盡可能的確保自己的理解和客戶的理解一致。

 

d)        界面設計

設計系統的界面風格

顏色、style

設計系統的具體“模擬”界面

能夠從頭走到尾

方便進行需求的確定

方便JSP程序員的開發

…

針對此步驟的總結：

個人認為界面的設計應該分為兩個步驟，建立原型的時候可以簡單一些，能保證開發者和客戶之間的交流溝通就可以；但是到了真正需要拿給用戶使用的時候界面就應該加一些美化。想想我們當時做教務的時候建立的的頁面簡直就是四不像，說它是原型吧設計的時間太長，說它是最終的頁面吧又太難看了。下次再做Web開發時候必須首先建立原型，并且這個原型可以完整的表達清楚開發者的意思，保證開發者和客戶的溝通；其次再去美化界面，美化的意思就是在顏色以及風格方面讓用戶感到舒服，這是關鍵。

 

3、開發環境搭建

開發工具的確定

配置管理工具的確定

測試工具的確定

文件服務器/配置服務器等的確定

…

 

針對此步驟的總結：

整個教務的開發環境是VS2010，配置管理工具統一用的是SVN（關于SVN等工具），有一個公共的服務器（所有的文檔以及源代碼全部上傳到服務器中）。悲催的是當時沒有用測試工具，這一點是下次開發的時候需要注意的地方。

 

4、開發-測試-開發-測試

按照設計進行開發

迅速開發原型

進行迭代開發

提早進行測試

單元測試（白盒測試）

黑盒測試(功能性測試、驗收測試)

性能測試

易用性測試

…

針對此步驟的總結：

目前個人認為最好的開發方法就是首先建立原型，然后迭代開發，而不是像上次開發教務那樣一下子搞一個大工程，最終一塊兒沒跑起來整個系統就崩了。首先保證核心的功能可以運行起來，然后在此基礎上一步一步的迭代，最終達到用戶滿意的程度。

5、編纂文檔

針對此步驟的總結：

還記得我們的大部分文檔都是開發完了之后補上去的，其實文檔什么時候寫沒有必要非得規定個時間，例如：必須邊開發邊寫，或者必須開發之前寫等等。這些都不是一定的，只要我們能夠讓文檔發揮出他應有的作用那么什么時候寫，怎么寫將都不是問題。

問題來了，文檔的作用是什么？

筆者認為文檔就是溝通的工具，無論是團隊之間的溝通，還是以前的開發人員和以后的開發人員之間的溝通都屬于溝通的一種，只要文檔能夠保證二者之間有良好的溝通那么就可以說這個文檔是成功的。