作/轉載者：mypm.net 發(fā)布時(shí)間：2004-6-9 瀏覽量：56
一. 軟件開(kāi)發(fā)的種類(lèi)
1.軟件產(chǎn)品 (software products)
1.1 大多為橫向型市場(chǎng) (horizontal market)而開(kāi)發(fā)。使用者多為個(gè)人, 且數目任意，能力不齊
1.2 提供的功能(features and functionalities)大多為解決某個(gè)具體應用問(wèn)題或需要
1.3 功能需求 (requirement)來(lái)自開(kāi)發(fā)商的市場(chǎng)開(kāi)發(fā)和銷(xiāo)售隊伍(marketing & sales), 或使用者對 前一代產(chǎn)品的回饋
1.4 例子: 辦公用軟件、單功能應用軟件、游戲、等等
2. 軟件系統 (software systems)
2.1 大多為縱向型市場(chǎng) (vertical market)而開(kāi)發(fā): 使用者為專(zhuān)門(mén)的客戶(hù)的內部員工及部門(mén)團隊, 數目有限, 事先可知, 且能力可專(zhuān)門(mén)培訓
2.2 提供的功能大多為解決客戶(hù)一連串具體的商業(yè)業(yè)務(wù)或運作問(wèn)題或滿(mǎn)足客戶(hù)對外服務(wù)需要
2.3 功能需求來(lái)自客戶(hù)提出的具體要求和客戶(hù)業(yè)務(wù)的運作特性: 它已有的系統, 流程的局限性
2.4 例子: 商業(yè)業(yè)務(wù)軟件系統, 自動(dòng)控制系統, 等
二. 編寫(xiě)程序之前必須進(jìn)行的工作
了解和確證客戶(hù)的使用方案(User Scenario)
總結詳細的功能需求并與用戶(hù)審核確證
功能設計通過(guò)完整的設計規范書(shū)(Design Specification)來(lái)表達
以設計規范書(shū)為基礎制定構架設計(Architecture)、開(kāi)發(fā)方案(Implementation Plan)
事先制定測試計劃和軟件合格的檢驗準則 (Exit Criteria)
三. 開(kāi)發(fā)項目的計劃和管理采取來(lái)自開(kāi)發(fā)團隊的、從下而上的時(shí)間表的估算，避免人為的不合理猜測
開(kāi)發(fā)時(shí)間表的制定以具體的功能開(kāi)發(fā)任務(wù)，并且以幾天為衡量單位
整個(gè)開(kāi)發(fā)過(guò)程以間斷性的里程碑來(lái)追蹤
進(jìn)行周期性的進(jìn)度審核，作必要的調整
對 “功能蔓延” (Feature Creep)嚴格控制和管理
四 . 開(kāi)發(fā)管理
4.1寫(xiě)任何程序前一定要先有設計構劃書(shū)
4.2任何復雜的系統程序要先有構架設計書(shū)
4.2.1 對系統組件有明確的功能定義.
4.2.2 對組件的接口的設計事先有完整的紀錄.
4.2.3 構架設計書(shū)由構架設計師或開(kāi)發(fā)工程師的領(lǐng)導人員來(lái)撰寫(xiě).
4.2.4 構架設計書(shū)要通過(guò)項目經(jīng)理和測試人員在內的審核及通過(guò), 才能開(kāi)始編寫(xiě)程序.
4.3 建立程序原代碼的提交庫，并建立完整的原代碼的提交的流程管理制度
4.3.1原代碼只允許一人改動(dòng). 改動(dòng)前先要從提交庫申請出原代碼. 改動(dòng)后再送進(jìn)提交庫.
4.3.2改動(dòng)完先要在開(kāi)發(fā)工程師的機器上編譯, 與其它組件一起運行過(guò), 確證沒(méi)有致命的缺陷后，才能送進(jìn)原代碼的提交庫.
4.3.4在產(chǎn)品發(fā)行前, 整個(gè)提交庫都被鎖上, 只有被批準的缺陷修補的原代碼才能提交進(jìn)庫.
4.4 建立原代碼互審的管理制度
每個(gè)軟件開(kāi)發(fā)工程師遍寫(xiě)的原代碼都有致少一個(gè)以上的同事對程序進(jìn)行審查.
4.5 建立原代碼編寫(xiě)的規范
每個(gè)軟件開(kāi)發(fā)工程師都應按照規范進(jìn)行程序設計, 包括編寫(xiě)的風(fēng)格, 格式, 組件接口的規范, 解說(shuō)詞的撰寫(xiě), 等等.
五 測試管理根據設計構劃書(shū)撰寫(xiě)測試計劃
5.1.1 測試計劃要請項目經(jīng)理和開(kāi)發(fā)工程師一起進(jìn)行審查.
5.1.2 測試計劃用列表式將所有的測試方案寫(xiě)下.
5.1.3 每個(gè)具體地的測試方案都有專(zhuān)人執行，并記錄每個(gè)測試方案的結果. 任何缺陷都記錄下來(lái).
5.2測試與開(kāi)發(fā)同步進(jìn)行
在部分組件編寫(xiě)完后就進(jìn)行開(kāi)發(fā)測試工具.
5.3 測試計劃執行中的注意事項
5.3.1 由測試員發(fā)現的缺陷分給開(kāi)發(fā)工程師修改糾錯.
5.3.2 修改完畢由測試員先進(jìn)行初步質(zhì)量驗證 (Smoke Test), 通過(guò)后才能由開(kāi)發(fā)工程師送進(jìn)原代碼的提交庫.
5.3.4 每次任何影響到其它組件的程序糾錯改動(dòng), 不僅是經(jīng)過(guò)改動(dòng)的程序要重新測試, 任何可能受到影響的其它組件或程序也必須重測 (Regression Test).
5.3.5發(fā)行前要進(jìn)行全程測試 (Full Test Pass).?
5.4 測試的內容：1.確定測試的優(yōu)先級別 2。函數模塊 3。功能模塊
5.5 測試的結果：1.bug的數量（平均每50行就有一個(gè)）2.代碼的覆蓋率（代碼的執行路徑）
5.6 測試不到的地方未知錯誤要進(jìn)行出錯處理
六 實(shí)施關(guān)鍵
設計在先，編碼在后
沒(méi)有設計規范書(shū)就不寫(xiě)一行編程碼
所有的編碼要有員工之間的互相審核
所有的編碼在加入整體匯編前必須在開(kāi)發(fā)工程師的機器上先匯編
“吃你自己的狗食”: 產(chǎn)品發(fā)行前全體團隊成員要自己使用尚未完善的產(chǎn)品,并報告缺陷.
專(zhuān)門(mén)的匯編團隊負責整個(gè)產(chǎn)品的建造并每天進(jìn)行匯編。任何造成匯編失敗的編程必須寫(xiě)此程序的工程師立即修改糾錯 (Fix Bug).
整個(gè)公司所有團隊使用統一的缺陷報告數據庫工具. 但每個(gè)團隊掌握控制自己的數據庫. 任何問(wèn)題都通過(guò)缺陷數據庫來(lái)跟蹤.
被修改后已解決的缺陷 (Fixed Bug)必須由找到缺陷的人 (通常是測試人員) 驗證.?被修改后已解決的缺陷還必須通過(guò)再測試，驗證修改的編碼沒(méi)有造成新的害蟲(chóng).
所有的害蟲(chóng)被分類(lèi)成三種嚴重性的級別及三種修改的優(yōu)先權的級別. 所有團隊員工被要求必須先除級別高的害蟲(chóng).
有的團隊執行 “害蟲(chóng)監獄” (Bug Jail)制度: 害蟲(chóng)數字超過(guò) 5 個(gè)以上的開(kāi)發(fā)工程師在除完害蟲(chóng)前不準編新的功能的編碼.
所有關(guān)鍵性的害蟲(chóng)在產(chǎn)品發(fā)行前都要由“三國會(huì )議” (Triage Meeting – PM, Dev, QA) 討論決定是否要除, 才能改動(dòng)。
產(chǎn)品發(fā)行前團隊召開(kāi)定時(shí)的“戰前會(huì )議” (War Meeting), 由團隊各領(lǐng)導成員審核所有的害蟲(chóng).
每次一項功能編程完成后, 團隊全體成員進(jìn)行 “抓蟲(chóng)大掃除” (Bug Bash)：每人在規定的時(shí)間內使用新的功能，將找到的害蟲(chóng)及時(shí)報告. 大掃除結束后抓蟲(chóng)的統計向全隊報告.
