軟件開發的項目管理
一. 軟件開發的種類
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 例子: 商業業務軟件系統, 自動控制系統, 等
二. 編寫程序之前必須進行的工作
l 瞭解和確證客戶的使用方案(User Scenario)
l 總結詳細的功能需求並與用戶審覈確證
l 功能設計通過完整的設計規範書(Design Specification)來表達
l 以設計規範書爲基礎制定構架設計(Architecture)、開發方案(Implementation Plan)
l 事先制定測試計劃和軟件合格的檢驗準則 (Exit Criteria)
三. 開發項目的計劃和管理採取來自開發團隊的、從下而上的時間表的估算，避免人爲的不合理猜測
l 開發時間表的制定以具體的功能開發任務，並且以幾天爲衡量單位
l 整個開發過程以間斷性的里程碑來追蹤
l 進行週期性的進度審覈，作必要的調整
l 對 “功能蔓延” (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)：每人在規定的時間內使用新的功能，將找到的害蟲及時報告. 大掃除結束後抓蟲的統計向全隊報告.
|
