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