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