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