軟體開發的專案管理(轉)

軟體開發的專案管理
一. 軟體開發的種類

1.軟體產品 (software products)

1.1 大多為橫向型市場 (horizontal market)而開發。使用者多為個人, 且數目任意，能力不齊
1.2 提供的功能(features and functionalities)大多為解決某個具體應用問題或需要
1.3 功能需求 (requirement)來自開發商的市場開發和銷售隊伍(marketing & sales), 或使用者對 前一代產品的回饋
1.4 例子: 辦公用軟體、單功能應用軟體、遊戲、等等

2. 軟體系統 (software systems)
2.1 大多為縱向型市場 (vertical market)而開發: 使用者為專門的客戶的內部員工及部門團隊, 數目有限, 事先可知, 且能力可專門培訓
2.2 提供的功能大多為解決客戶一連串具體的商業業務或運作問題或滿足客戶對外服務需要
2.3 功能需求來自客戶提出的具體要求和客戶業務的運作特性: 它已有的系統, 流程的侷限性
2.4 例子: 商業業務軟體系統, 自動控制系統, 等

二. 編寫程式之前必須進行的工作

瞭解和確證客戶的使用方案(User Scenario)
總結詳細的功能需求並與使用者稽核確證
功能設計通過完整的設計規範書(Design Specification)來表達
以設計規範書為基礎制定構架設計(Architecture)、開發方案(Implementation Plan)
事先制定測試計劃和軟體合格的檢驗準則 (Exit Criteria)

三. 開發專案的計劃和管理採取來自開發團隊的、從下而上的時間表的估算，避免人為的不合理猜測

開發時間表的制定以具體的功能開發任務，並且以幾天為衡量單位
整個開發過程以間斷性的里程碑來追蹤
進行週期性的進度稽核，作必要的調整
對 “功能蔓延” (Feature Creep)嚴格控制和管理

四 . 開發管理

4.1寫任何程式前一定要先有設計構劃書

4.2任何複雜的系統程式要先有構架設計書
4.2.1 對系統元件有明確的功能定義.
4.2.2 對元件的介面的設計事先有完整的紀錄.
4.2.3 構架設計書由構架設計師或開發工程師的領導人員來撰寫.
4.2.4 構架設計書要通過專案經理和測試人員在內的稽核及通過, 才能開始編寫程式.

4.3 建立程式原始碼的提交庫，並建立完整的原始碼的提交的流程管理制度
4.3.1原始碼只允許一人改動. 改動前先要從提交庫申請出原始碼. 改動後再送進提交庫.
4.3.2改動完先要在開發工程師的機器上編譯, 與其它元件一起執行過, 確證沒有致命的缺陷後，才能送進原始碼的提交庫.
4.3.4在產品發行前, 整個提交庫都被鎖上, 只有被批准的缺陷修補的原始碼才能提交進庫.

4.4 建立原始碼互審的管理制度
每個軟體開發工程師遍寫的原始碼都有致少一個以上的同事對程式進行審查.

4.5 建立原始碼編寫的規範
每個軟體開發工程師都應按照規範進行程式設計, 包括編寫的風格, 格式, 元件介面的規範, 解說詞的撰寫, 等等.

五 測試管理根據設計構劃書撰寫測試計劃

5.1.1 測試計劃要請專案經理和開發工程師一起進行審查.
5.1.2 測試計劃用列表式將所有的測試方案寫下.
5.1.3 每個具體地的測試方案都有專人執行，並記錄每個測試方案的結果. 任何缺陷都記錄下來.

5.2測試與開發同步進行
在部分元件編寫完後就進行開發測試工具.

5.3 測試計劃執行中的注意事項
5.3.1 由測試員發現的缺陷分給開發工程師修改糾錯.
5.3.2 修改完畢由測試員先進行初步質量驗證 (Smoke Test), 通過後才能由開發工程師送進原始碼的提交庫.
5.3.4 每次任何影響到其它元件的程式糾錯改動, 不僅是經過改動的程式要重新測試, 任何可能受到影響的其它元件或程式也必須重測 (Regression Test).
5.3.5發行前要進行全程測試 (Full Test Pass).

5.4 測試的內容：1.確定測試的優先順序別 2。函式模組 3。功能模組

5.5 測試的結果：1.bug的數量（平均每50行就有一個）2.程式碼的覆蓋率（程式碼的執行路徑）

5.6 測試不到的地方未知錯誤要進行出錯處理

六 實施關鍵

設計在先，編碼在後
沒有設計規範書就不寫一行程式設計碼
所有的編碼要有員工之間的互相稽核
所有的編碼在加入整體彙編前必須在開發工程師的機器上先彙編
“吃你自己的狗食”: 產品發行前全體團隊成員要自己使用尚未完善的產品,並報告缺陷.
專門的彙編團隊負責整個產品的建造並每天進行彙編。任何造成彙編失敗的程式設計必須寫此程式的工程師立即修改糾錯 (Fix Bug).
整個公司所有團隊使用統一的缺陷報告資料庫工具. 但每個團隊掌握控制自己的資料庫. 任何問題都通過缺陷資料庫來跟蹤.
被修改後已解決的缺陷 (Fixed Bug)必須由找到缺陷的人 (通常是測試人員) 驗證.被修改後已解決的缺陷還必須通過再測試，驗證修改的編碼沒有造成新的害蟲.
所有的害蟲被分類成三種嚴重性的級別及三種修改的優先權的級別. 所有團隊員工被要求必須先除級別高的害蟲.
有的團隊執行 “害蟲監獄” (Bug Jail)制度: 害蟲數字超過 5 個以上的開發工程師在除完害蟲前不準編新的功能的編碼.
所有關鍵性的害蟲在產品發行前都要由“三國會議” (Triage Meeting – PM, Dev, QA) 討論決定是否要除, 才能改動。
產品發行前團隊召開定時的“戰前會議” (War Meeting), 由團隊各領導成員稽核所有的害蟲.
每次一項功能程式設計完成後, 團隊全體成員進行 “抓蟲大掃除” (Bug Bash)：每人在規定的時間內使用新的功能，將找到的害蟲及時報告. 大掃除結束後抓蟲的統計向全隊報告.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21417/，如需轉載，請註明出處，否則將追究法律責任。