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

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

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

1、需求確定

通過各種手段確定系統(tǒng)的功能與性能

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

性能：可同時支持 n個并發(fā)訪問，并且響應(yīng)時間不高于 m毫秒…

手段：

頭腦風(fēng)暴 (brain storm)

會議

詢問

原型–界面原型、業(yè)務(wù)原型…

本階段是項目開發(fā)的最重要階段

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

 

針對此步驟的總結(jié)：

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

 

2、分析與設(shè)計

a)        架構(gòu)分析與設(shè)計

邏輯架構(gòu)

3層架構(gòu)、n層架構(gòu)…

MVC…

Model 1 or Model 2

…

物理架構(gòu)

Web服務(wù)器的分布

數(shù)據(jù)庫服務(wù)器的分布

…

技術(shù)解決方案的確定

Java / .NET

Open Source /商業(yè)

…

 

針對此步驟的總結(jié)：

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

 

b)        業(yè)務(wù)邏輯分析

根據(jù)需求分析業(yè)務(wù)邏輯

有哪些人會使用本系統(tǒng)？

他們會使用本系統(tǒng)做什么？

通常他們使用本系統(tǒng)的步驟是什么樣的？

會有哪些明顯的類來支撐本系統(tǒng)的運行？

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

…

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

 

針對此步驟的總結(jié)：

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

 

c)        業(yè)務(wù)邏輯設(shè)計

根據(jù)需求的分析來確定具體的類

確定類的屬性

確定類的接口（方法）

確定類之間的關(guān)系

確定用戶操作流程在設(shè)計上的反映

進行數(shù)據(jù)庫的設(shè)計

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

…

針對此步驟的總結(jié)：

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

 

d)        界面設(shè)計

設(shè)計系統(tǒng)的界面風(fēng)格

顏色、style

設(shè)計系統(tǒng)的具體“模擬”界面

能夠從頭走到尾

方便進行需求的確定

方便JSP程序員的開發(fā)

…

針對此步驟的總結(jié)：

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

 

3、開發(fā)環(huán)境搭建

開發(fā)工具的確定

配置管理工具的確定

測試工具的確定

文件服務(wù)器/配置服務(wù)器等的確定

…

 

針對此步驟的總結(jié)：

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

 

4、開發(fā)-測試-開發(fā)-測試

按照設(shè)計進行開發(fā)

迅速開發(fā)原型

進行迭代開發(fā)

提早進行測試

單元測試（白盒測試）

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

性能測試

易用性測試

…

針對此步驟的總結(jié)：

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

5、編纂文檔

針對此步驟的總結(jié)：

還記得我們的大部分文檔都是開發(fā)完了之后補上去的，其實文檔什么時候?qū)憶]有必要非得規(guī)定個時間，例如：必須邊開發(fā)邊寫，或者必須開發(fā)之前寫等等。這些都不是一定的，只要我們能夠讓文檔發(fā)揮出他應(yīng)有的作用那么什么時候?qū)懀趺磳憣⒍疾皇菃栴}。

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

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