Posted on 2006-06-30 22:52
Nomad 閱讀(499)
評論(1) 編輯 收藏 所屬分類:
Code Life
就像某人說的失敗并不可怕，可怕的是不知道從失敗中吸取教訓。
前言
本項目的目的是構建一個在線的考試系統，功能包括在線考試、用戶管理、題庫管理、試卷管理、教師批改、分數統計分析等。系統使用Java技術、Oracle數據庫。開發人員計劃為4人。時間周期為一個月。
項目概述
一、計劃的制定
一個月簡單分為4周，第一周完成界面設計、數據庫設計、對象設計、平臺搭建等工作。
第二周完成對象模塊的開發。
第三周完成頁面的開發。
第四周進行測試與完善工作。
二、軟件框架
采取四層結構，由底向上依次是:
Hibernate->Spring->Struts->JSP+JSTL+DWR
DAO->Model->Controller->View
三、人員配置???
一個leader(M)＋三個組員(A、B、C)
四、任務劃分
M的任務1是：對象設計、平臺搭建；
A的任務1是：界面設計；
B的任務1是：數據庫設計；
c的任務1沒有。
M的任務2是：用戶管理模塊、在線考試模塊；
A的任務2是：題庫管理模塊；
B的任務2是：試卷管理模塊；
c的任務2是：教師批改模塊、分數統計分析模塊。
失敗原因
一、計劃偏差
如果是設計優秀的軟件，在模塊開發上花的時間應該是頁面開發所花時間的N倍（視軟件的大小與復雜度），簡單的給這兩個部分一周時間不太合理。實際的情況也是這樣，到項目結束的時候，很多模塊都只完成了基本的部分，即沒有開發完成。
教訓：做需求時只能預估項目的計劃。計劃的具體制定應該在設計工作完成后考慮。
二、風險管理
在項目組中，每個人都有自己的繁重任務，可是在第二個星期時，組員C因為特殊情況退出了項目組，于是他所負責的模塊空置一旁。因為沒有預料到這個突發情況，項目組也沒法再添加組員進來。
教訓：M應該有處理組員突然離開風險的準備。
三、時間控制
項目總的時間只有一個月，但是四位成員全部都有其他重要的事務須處理，這些其他的工作至少用掉每個成員10天的時間。項目進度因此嚴重滯后。
教訓：M已經知道成員們會分心處理其他的事務，且項目時間無法延長的情況下，在需求和設計時應該壓縮功能。
四、技術問題
對項目組的四位成員來說本次軟件的框架都不太熟悉，在項目的開發過程中都經歷了一個了解熟悉的過程。這樣的一個過程也讓項目的進度跟著拖累。并且由于對技術的不熟悉，成員們的開發效率也是令人頭痛的問題。
教訓：作為程序員應當熟悉軟件開發中的各項技術，平時就需要磨練自己的技藝，不能抱著到實際項目中用用就會的思想。對于項目的計劃制定者也需要將項目成員的技術問題考慮到，留出一定的時間學習是必要的。
項目結果
從后臺到頁面全部完成的模塊有用戶管理、題庫管理。其它模塊都在半完成或沒啟動狀態。