專案(代號：XNB-001)軟體開發分析

由於該專案使用新的技術框架開發，為更為準確的收集資訊，分別取樣了兩個模組，一個是初次開發需熟悉開發框架的模組，另外一個是已基本熟悉使用技術框架二次開發的模組。

統計資訊如下表所示：

（見http://space.itpub.net/6906/spacelist-image）

表-1 資訊統計表

從上表的資料可以看出，一個由高階程式、中級程式設計師、初中級程式設計師和初級程式設計師組成的4人開發團隊，每人開發2個模組，在首次開發的開發效率約為40小時/模組，二次開發的開發效率約為32小時/模組，也就是說每個模組需耗費4-5天左右，效率較低。

下面從環境搭建和熟悉技術框架、熟悉業務需求和設計、編碼、返工和等待等階段分別說明開發過程中出現的問題。

1.         工程比較快搭建好了，但輔助類的配置（如選單、按鈕等）初始化花了較長時間；

2.         熟悉整個開發流程比較快，但是實際開發過程中因為框架的一些弊端影響效率：

a)         程式報錯，被框架catch掉，無法知道錯誤在哪，無法Debug到程式中；

b)        框架沒有完善的api，比如使用一些已經整合的功能只能靠猜。比如後臺填充到前臺的資料，使用list資料集填充不了，就猜測是不是要用map；

3.         沒有在該框架上開發過，只能仿造其他人的做法和一邊做一邊問或者自己一點一點的去猜；

1.         文件太簡單，沒有介面、沒有說明，只有介面原型，相關的資料庫表亦不清楚；沒有文件，只能根據原型和設計人員的口頭描述來理解設計；

1.         呼叫儲存過程不停的出錯，由於儲存過程不是由本人自己編寫，溝通存在問題，在很多地方浪費時間，比如結果不正確，但是過程沒報錯，執行成功等等。諸如此類的問題影響判斷和思路。

1.         業務問題：原型設計有問題，比如複核頁面本應跟經辦差不多，風格卻完全不同，導致返工；

2.         技術問題：

a)         業務邏輯透過儲存過程還是Java實現、是否採用工作流等技術問題在開發時才確定；

b)        除錯的時候快取的存在給除錯帶來麻煩，並且開始沒有認識到；

3.         版本釋出問題：由於時間比較倉促，單元測試較少，很多bug來不及修復，多半在系統釋出測試時才來得及修復；單元測試是開發人員手工構造的資料，很多中文程式碼欄位沒有準確寫入，導致部分頁面的bug；

4.         需求管理問題：

a)         業務需求開始不太明確，變更較大，返工較多；

b)        初期需求未定好，設計文件也不完善，從最開始理解的兩個介面改變到後來的四個介面；

5.         專案管理問題：

a)         任務目標不清：如任務分派時是A模組，以為列印也是A模組，後來才發現列印要做的是B模組的列印；

b)        溝通交流不充分：由於是分模組做，以為是各人完成自己的模組，所以取數邏輯是按A來做，報表樣式也是按A來做，後來改為列印B模組，導致返工較多；

1.         等待系統分析員解釋業務；

2.         基礎開發平臺啟動不了，開發一直在等待；

3.         在遇到問題問其他人的時候，其他人由於也有要做的模組，不能即時回覆，影響進度；

1.         最佳化和完善安裝指令碼。後臺sql指令碼應該進一步完善，和智慧化，不應該讓使用者自個去建立使用者然後再執行相應的指令碼，可以考慮直接進入一個dba使用者直接執行一個指令碼，簡單方便；

2.         充分調動成員積極性。大家互相幫助，團結奮進，做事負責任，嚴格控制自己的進度，如負責的模組是別人工作的基礎，能儘量加快進度，不要影響到其他同事的進度；

3.         分工明確。比如做維護的就做維護，規範化一點，不要東做一點西做一點，等修改完那邊程式回來後發現理清的思路忘記了，又得從頭來，浪費時間；

1.         編寫設計文件。設計文件還是需要有，特別是要說明資料表有哪些，業務較難複雜或難理解的地方，要說明設計思路；

2.         完善和確認介面原型。原型設計要儘量做到準確，否則，會導致一定的返工量；

3.         加強溝通和交流。希望能加強開發人員和設計人員的聯絡，就算時間緊，開發人員也應該再交流清楚，使自己的思路也得到設計人員肯定後再做，也希望設計人員將思路考慮充分，雙方共同來避免快做才完發現不對需要大規模返工的情況出現。

1.         重構架構。將後臺管理和系統框架分離，至少要分離在不同的模組中；

2.         框架開發人員合理分工。對於框架、公共部分的開發人員，在專案開發中能不能將其任務分配的稍微少一點，或者更靈活的對待這類開發人員的任務，以方便其對專案中的特殊需求優先進行框架的最佳化修改，從而提高其他同時的開發效率。