第7章-IDP項(xiàng)目研發(fā)過程

1、IDP項(xiàng)目研發(fā)過程第7章7.1 需求開發(fā)與管理47.1.1 需求調(diào)研57.1.2 需求分析67.1.3 需求定義67.1.4 需求評審確認(rèn)77.1.5 需求細(xì)化跟蹤87.1.6 需求變更控制87.2 軟件系統(tǒng)設(shè)計(jì)97.2.1 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)10 用戶界面設(shè)計(jì)107.2.3 數(shù)據(jù)庫設(shè)計(jì)117.2.4 系統(tǒng)設(shè)計(jì)評審127.3 模塊開發(fā)和集成127.3.1 模塊需求細(xì)化127.3.2 模塊設(shè)計(jì)137.3.3 模塊實(shí)現(xiàn)和集成147.4 測試與改錯(cuò)147.4.1 測試準(zhǔn)備147.4.2 執(zhí)行測試167.4.3 消除缺陷167.5 軟硬件系統(tǒng)集成177.5.1 系統(tǒng)集成方案設(shè)計(jì)177.5.2 選擇設(shè)備供應(yīng)商

2、177.5.3 設(shè)備采購和驗(yàn)收187.5.4 設(shè)備安裝調(diào)試187.6 部署試用187.6.1 撰寫文檔197.6.2 軟件部署197.6.3 客戶培訓(xùn)207.6.4 客戶試用207.7 軟件維護(hù)217.7.1 接受維護(hù)請求217.7.2 分析維護(hù)請求227.7.3 執(zhí)行維護(hù)227.1 需求開發(fā)與管理需求開發(fā)與管理的目的是通過“調(diào)研、分析、定義、評審確認(rèn)、細(xì)化跟蹤、變更控制”等活動(dòng)，使開發(fā)方和客戶對需求有共同、清晰的理解，并依據(jù)雙方確認(rèn)的需求開展后續(xù)開發(fā)工作（如設(shè)計(jì)、編程、測試等）。需求開發(fā)與管理的流程如圖7-1所示，該流程的主要工作成果和責(zé)任人見表7-1。一般地，在立項(xiàng)之前，產(chǎn)品經(jīng)理應(yīng)當(dāng)撰寫產(chǎn)

3、品需求說明書，項(xiàng)目銷售人員應(yīng)當(dāng)撰寫合同項(xiàng)目需求說明書。但是此時(shí)的需求說明書通常是宏觀粗略的，不足以讓項(xiàng)目開發(fā)團(tuán)隊(duì)依據(jù)此需求說明書開展設(shè)計(jì)和編程工作。需求管理變更控制細(xì)化跟蹤評審確認(rèn)需求開發(fā)需求定義需求分析需求調(diào)研項(xiàng)目開發(fā)團(tuán)隊(duì)?wèi)?yīng)當(dāng)在產(chǎn)品經(jīng)理、銷售人員的工作成果基礎(chǔ)之上，進(jìn)一步開展需求調(diào)研、分析、定義、評審確認(rèn)、細(xì)化和跟蹤活動(dòng)。項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的人力資源來確定需求分析員（通常是項(xiàng)目經(jīng)理或資深開發(fā)工程師擔(dān)任需求分析員）。圖7-1 需求開發(fā)與管理的流程關(guān)鍵活動(dòng)主要工作成果主要責(zé)任人需求調(diào)研需求分析需求定義需求調(diào)研記錄產(chǎn)品需求說明書或合同項(xiàng)目需求說明書需求分析員需求評審確認(rèn)需求評審報(bào)告，簽字確認(rèn)開發(fā)方

4、和客戶方的責(zé)任人需求細(xì)化跟蹤需求跟蹤表需求分析員需求變更控制需求變更控制報(bào)告開發(fā)方和客戶方的責(zé)任人表7-1 主要工作成果和責(zé)任人7.1.1 需求調(diào)研需求分析員起草需求問題表，將調(diào)查重點(diǎn)鎖定在該問題表內(nèi)，否則調(diào)研工作將變得漫無邊際。需求分析員確定需求調(diào)研的方式，例如：² 與用戶交談，向用戶提問題。² 參觀用戶的工作流程，觀察用戶的操作。² 向用戶群體發(fā)調(diào)查問卷。² 與同行、專家交談，聽取他們的意見。² 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。² 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。² 從Internet上搜查相關(guān)資料。需求分析員與被訪談

5、者建立聯(lián)系，確定調(diào)查的時(shí)間、地點(diǎn)、人員等，要特別留意的是不要漏掉典型的用戶。需求分析員在調(diào)研過程中隨時(shí)填寫“客戶需求記錄”，參考格式如表7-2所示。提示：集成化研發(fā)管理平臺(tái)RDMS的“客戶需求記錄”功能滿足此要求。項(xiàng)目名稱需求分析員被調(diào)研者調(diào)研方式如面談，電話交談等時(shí)間、地點(diǎn)需求標(biāo)題描述表7-2 客戶需求記錄的參考格式需求分析員整理所有客戶需求記錄，歸納與總結(jié)共性的需求，為撰寫詳細(xì)的需求說明書作準(zhǔn)備。調(diào)研過程中獲取的需求信息可以作為需求說明書的附件。7.1.2 需求分析需求分析的目的是對各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。問答分析

6、最重要的問題是：“是什么”和“為什么”。每個(gè)需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補(bǔ)充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求?，F(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達(dá)模型的細(xì)節(jié)。要注意的是：在建模時(shí)使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而

7、且使圖形文檔更加雜亂。世上不存在一個(gè)包羅萬象的圖用以完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。7.1.3 需求定義需求分析員根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的需求，產(chǎn)生需求說明書。產(chǎn)品需求說明書的模板參見表5-2，合同項(xiàng)目需求說明書的模板參見表5-7。好的需求說明書有如下特征：Ø 正確：需求文檔應(yīng)當(dāng)正確地反映客戶的真實(shí)意圖。Ø 清楚：清楚的需求讓人易讀易懂。Ø 無二義性：每個(gè)需求只有唯一的含義。Ø 一致：需求文檔的上下文之間不

8、會(huì)發(fā)生矛盾。Ø 必要：需求文檔中的各項(xiàng)需求對用戶而言應(yīng)當(dāng)都是必要的。Ø 完備：需求文檔中沒有遺漏必要的需求。Ø 可實(shí)現(xiàn)：需求文檔中的各項(xiàng)需求對開發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的。Ø 可驗(yàn)證：需求文檔中的各項(xiàng)需求對客戶方而言應(yīng)當(dāng)都是可驗(yàn)證的。7.1.4 需求評審確認(rèn)一、需求評審需求分析員邀請項(xiàng)目成員（包括項(xiàng)目經(jīng)理）和客戶代表共同評審需求說明書，大家盡最大努力使需求說明書能夠正確無誤地反映用戶的真實(shí)意愿。需求評審的流程和技術(shù)評審流程相同，如圖7-2所示。一般地，需求分析員為申請人，項(xiàng)目經(jīng)理為評審負(fù)責(zé)人，項(xiàng)目成員和客戶代表可以擔(dān)任評審員。所有評審人員認(rèn)真檢查需求文檔，

9、力求使需求文檔達(dá)到正確、清楚、無二義性、一致、必要、完備、可實(shí)現(xiàn)、可驗(yàn)證。 執(zhí)行負(fù)責(zé)人執(zhí)行需求評審會(huì)議需求評審申請 申請人 評審人圖7-2 需求評審流程二、需求確認(rèn)需求確認(rèn)是指當(dāng)需求說明書通過評審之后，開發(fā)方負(fù)責(zé)人和客戶方負(fù)責(zé)人作書面承諾，使之具有商業(yè)合同效果。提示：書面承諾一般放在需求說明書的最后一頁。人們作出書面承諾之前務(wù)必要認(rèn)真閱讀文檔，一定要明白簽字意味著什么?！皶娉兄Z”的示例如下：本需求說明書建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求說明書開展。如果需求發(fā)生變化，我們將按照“需求變更控制流程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。開發(fā)方

10、負(fù)責(zé)人簽字客戶方負(fù)責(zé)人簽字7.1.5 需求細(xì)化跟蹤在后續(xù)開發(fā)過程中，人們會(huì)對原先的需求文檔進(jìn)行細(xì)化。為了提高工作效率，補(bǔ)充需求細(xì)節(jié)不必按照需求變更來處理。需求分析員將補(bǔ)充的需求內(nèi)容保存在新的文檔中，及時(shí)通知相關(guān)開發(fā)人員，只要大家正確理解了新的需求內(nèi)容即可。需求分析員要填寫需求跟蹤表，及時(shí)檢查后續(xù)開發(fā)成果是否和需求保持一致。CMMI建議的“需求跟蹤矩陣”要把“需求設(shè)計(jì)代碼測試”的所有關(guān)系全部羅列出來，過于復(fù)雜和麻煩。根據(jù)作者調(diào)查，幾乎沒有人能夠長期使用理想化的“需求跟蹤矩陣”。為了提高需求跟蹤的效率，應(yīng)當(dāng)簡化需求跟蹤表，如表7-3所示。提示：集成化研發(fā)管理平臺(tái)RDMS的“項(xiàng)目需求管理”功能滿足此

11、要求。項(xiàng)目名稱需求目錄需求變更對應(yīng)測試用例相關(guān)缺陷跟蹤記錄表7-3 簡化的需求跟蹤表7.1.6 需求變更控制對大多數(shù)項(xiàng)目而言，需求發(fā)生若干次變更似乎是不可避免的。需求發(fā)生變更的起因主要有：Ø 隨著項(xiàng)目的進(jìn)展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯(cuò)誤或不足，因此要變更需求。Ø 市場發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前市場需求，因此要變更需求。提出需求變更的動(dòng)機(jī)是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項(xiàng)目開發(fā)團(tuán)隊(duì)而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)團(tuán)隊(duì)要為此付出較重的代價(jià)。如果每次需求變更請

12、求都被采納的話，這個(gè)項(xiàng)目也許永遠(yuǎn)不能按時(shí)完成。需求變更控制的動(dòng)機(jī)是：（1）如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。（2）如果需求變更帶來的壞處大于好處，那么拒絕變更。需求的變更應(yīng)當(dāng)遵循“變更控制流程”，即“變更申請>審批>執(zhí)行”，詳見本書第6.3.2節(jié)“變更控制”。7.2 軟件系統(tǒng)設(shè)計(jì)軟件系統(tǒng)設(shè)計(jì)的主要內(nèi)容有體系結(jié)構(gòu)設(shè)計(jì)、用戶界面設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)和設(shè)計(jì)評審，在需求與代碼之間建立橋梁，指導(dǎo)工作人員開發(fā)能夠滿足用戶需求的軟件系統(tǒng)。如圖7-3所示。數(shù)據(jù)庫設(shè)計(jì)用戶界面設(shè)計(jì)產(chǎn)生軟件系統(tǒng)設(shè)計(jì)說明書和“可運(yùn)行系統(tǒng)框架”系統(tǒng)設(shè)計(jì)評審軟件系統(tǒng)設(shè)

13、計(jì)系統(tǒng)結(jié)構(gòu)設(shè)計(jì)圖7-3 軟件系統(tǒng)設(shè)計(jì)的示意圖項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的人力資源來確定系統(tǒng)設(shè)計(jì)師（可以多人）。系統(tǒng)設(shè)計(jì)師撰寫軟件系統(tǒng)設(shè)計(jì)說明書，并構(gòu)造可運(yùn)行的軟件系統(tǒng)框架，所有的模塊都是在該系統(tǒng)框架上開發(fā)和運(yùn)行。軟件系統(tǒng)設(shè)計(jì)說明書的模板參見表7-4。軟件系統(tǒng)設(shè)計(jì)說明書1. 系統(tǒng)概述2. 設(shè)計(jì)約束3. 開發(fā)、測試與運(yùn)行環(huán)境4. 軟件系統(tǒng)結(jié)構(gòu)圖5. 功能模塊設(shè)計(jì)概述5.1 模塊匯總5.2 模塊之間的關(guān)系6. 數(shù)據(jù)庫設(shè)計(jì)概述6.1 數(shù)據(jù)庫環(huán)境說明6.2 數(shù)據(jù)庫命名規(guī)則6.3安全性設(shè)計(jì)說明6.4 表匯總和表設(shè)計(jì)（使用表設(shè)計(jì)工具PowerDesign）7. 用戶界面設(shè)計(jì)概述8. 綜合考慮（可選）8.1 穩(wěn)定性和

14、可擴(kuò)展性8.2 性能分析8.3 復(fù)用和移植8.4 防錯(cuò)與出錯(cuò)處理8.5 其它表7-4 軟件系統(tǒng)設(shè)計(jì)說明書7.2.1 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)系統(tǒng)設(shè)計(jì)師進(jìn)行系統(tǒng)結(jié)構(gòu)設(shè)計(jì)：Ø 確定本系統(tǒng)的約束條件；Ø 確定本系統(tǒng)的開發(fā)、測試和運(yùn)行環(huán)境；Ø 將系統(tǒng)分解為模塊，確定每個(gè)模塊的功能，以及模塊之間的關(guān)系，繪制系統(tǒng)結(jié)構(gòu)圖。7.2.2 用戶界面設(shè)計(jì)系統(tǒng)設(shè)計(jì)師設(shè)計(jì)和構(gòu)建用戶界面原型，目的是：Ø 加深開發(fā)方和客戶方對軟件需求的理解（界面原型直觀地反映了軟件需求）；Ø 在編程之前讓相關(guān)人員看到用戶界面原型，不僅可以提高界面的易用性，還提高了程序員的開發(fā)效率（避免反復(fù)修改界面及其

15、代碼）。第1步 繪制界面示意圖系統(tǒng)設(shè)計(jì)師首先分析用戶對界面的需求，例如： Ø 用戶的工作習(xí)慣Ø 用戶對界面有什么喜好Ø 有什么強(qiáng)制要求Ø 是否有范例系統(tǒng)設(shè)計(jì)師構(gòu)思并繪制用戶界面示意圖，常用方式如下：Ø 在紙張上繪制用戶界面示意圖（效率高但是不便于保存）Ø 用Word或者Visio等工具繪制線框圖（效率低但可以作為文檔保存）第2步 制作界面原型系統(tǒng)設(shè)計(jì)師制作界面原型（通過編程或者繪圖等方式），將所有界面原型的圖片保存在指定的文件夾中，并用HTML建立簡要的索引，這樣做的好處有：Ø 便于其他人員審閱（使用IE瀏覽）；Ø

16、 需求分析員不必將界面原型圖片插入到需求文檔中；Ø 修改界面原型圖片將不會(huì)影響其它文件；第3步 體驗(yàn)和改進(jìn)界面設(shè)計(jì)師邀請項(xiàng)目成員或者用戶來體驗(yàn)界面原型，大家給出改進(jìn)建議，力求使用戶界面滿足以下10個(gè)設(shè)計(jì)要素： （1）用戶界面適合于展現(xiàn)軟件的功能（2）適合用戶群體（2）容易理解（3）及時(shí)反饋信息（4）防錯(cuò)處理（5）合理的布局（6）合理的色彩（7）風(fēng)格一致和必要的個(gè)性化（9）最少操作步驟（最高效率）（10）國際化、可復(fù)用等7.2.3 數(shù)據(jù)庫設(shè)計(jì)系統(tǒng)設(shè)計(jì)師進(jìn)行數(shù)據(jù)庫設(shè)計(jì)： Ø 確定數(shù)據(jù)庫的環(huán)境說明Ø 確定數(shù)據(jù)庫的命名規(guī)則Ø 確定安全性設(shè)計(jì)方法Ø 使用

17、表設(shè)計(jì)工具PowerDesign設(shè)計(jì)主要的表結(jié)構(gòu)7.2.4 系統(tǒng)設(shè)計(jì)評審當(dāng)系統(tǒng)設(shè)計(jì)師撰寫完成軟件系統(tǒng)設(shè)計(jì)說明書并構(gòu)建可運(yùn)行的系統(tǒng)框架之后，邀請項(xiàng)目成員（包括項(xiàng)目經(jīng)理）和本公司技術(shù)專家開展系統(tǒng)設(shè)計(jì)評審。詳見“技術(shù)評審”的流程。系統(tǒng)設(shè)計(jì)評審的目的是，在同行專家的幫助下，盡早地發(fā)現(xiàn)本系統(tǒng)中存在的設(shè)計(jì)缺陷，及時(shí)消除設(shè)計(jì)缺陷。7.3 模塊開發(fā)和集成增量模式的模塊開發(fā)和集成流程如圖7-4所示，主要內(nèi)容有：“模塊需求細(xì)化”、“模塊設(shè)計(jì)”和“模塊實(shí)現(xiàn)和集成”。模塊設(shè)計(jì)說明書模塊需求說明書模塊實(shí)現(xiàn)和集成模塊設(shè)計(jì)模塊需求細(xì)化增量開發(fā)可運(yùn)行模塊，交付測試項(xiàng)目經(jīng)理分配任務(wù)給開發(fā)工程師，開發(fā)工程師對模塊的質(zhì)量和進(jìn)度負(fù)最

18、大責(zé)任。圖7-4 模塊開發(fā)和集成的流程7.3.1 模塊需求細(xì)化開發(fā)工程師閱讀產(chǎn)品需求說明書或合同項(xiàng)目需求說明書，分析并細(xì)化自己承擔(dān)的模塊需求，撰寫詳細(xì)的模塊需求說明書，模板參見表7-5。如果發(fā)生比較大的需求變更，則按“變更控制流程”執(zhí)行，向項(xiàng)目經(jīng)理申請需求變更。模塊需求說明書項(xiàng)目名稱撰寫人/ 修改人模塊名稱完成日期1. 模塊用途和功能介紹2. 模塊流程介紹（可選）3. 字段說明字段名稱必填項(xiàng)*說明4. 操作說明操作名稱功能說明用戶角色和權(quán)限表7-5 模塊需求說明書的參考模板7.3.2 模塊設(shè)計(jì)模塊設(shè)計(jì)的主要內(nèi)容：Ø 設(shè)計(jì)模塊的接口；Ø 設(shè)計(jì)模塊的數(shù)據(jù)結(jié)構(gòu)和算法；Ø

19、 設(shè)計(jì)和細(xì)化本模塊相關(guān)的用戶界面；Ø 設(shè)計(jì)和細(xì)化本模板相關(guān)的數(shù)據(jù)庫；對于比較復(fù)雜的模塊，開發(fā)工程師應(yīng)當(dāng)撰寫必要的模塊設(shè)計(jì)說明書，參考模板見表7-6。模塊設(shè)計(jì)說明書項(xiàng)目名稱撰寫人/ 修改人模塊名稱完成日期1. 主要編程接口2. 主要數(shù)據(jù)結(jié)構(gòu)3. 主要算法4. 相關(guān)的用戶界面設(shè)計(jì)說明5. 相關(guān)的數(shù)據(jù)庫設(shè)計(jì)說明表7-6 模塊設(shè)計(jì)說明書的參考模塊7.3.3 模塊實(shí)現(xiàn)和集成所有開發(fā)工程師按照既定的編程規(guī)范來實(shí)現(xiàn)自己承擔(dān)的模塊，并在系統(tǒng)框架中和其它模塊集成一起。開發(fā)工程師自己必須先進(jìn)行測試，必須走通模塊的功能，消除自己已經(jīng)發(fā)現(xiàn)的缺陷。開發(fā)工程師把待測試的軟件包發(fā)布到約定的測試機(jī)器上，把本模塊相關(guān)

20、的需求說明書、設(shè)計(jì)說明書交付給測試人員，并向測試人員解釋清楚待測試模塊的特征。7.4 測試與改錯(cuò)測試與改錯(cuò)的目的是在給定的項(xiàng)目條件下（人員、時(shí)間、工具等限制）盡可能地找出軟件中的缺陷，并及時(shí)消除這些缺陷。測試與改錯(cuò)的流程如圖7-5所示，關(guān)鍵活動(dòng)是“準(zhǔn)備測試”、“執(zhí)行測試”和“消除缺陷”。建議使用缺陷跟蹤工具和測試管理工具，用于記錄測試用例和修改Bug的整個(gè)過程。提示：集成化研發(fā)管理平臺(tái)RDMS的“測試管理”和“缺陷跟蹤”功能滿足此要求。測試準(zhǔn)備消除缺陷 開發(fā)人員 測試人員審核關(guān)閉缺陷跟蹤執(zhí)行測試圖7-5 軟件測試與改錯(cuò)的流程7.4.1 測試準(zhǔn)備測試準(zhǔn)備主要有3件事情：制定測試計(jì)劃，設(shè)計(jì)測試用例

21、，構(gòu)建測試環(huán)境。一、制定測試計(jì)劃測試工程師和項(xiàng)目經(jīng)理商議測試計(jì)劃，撰寫測試計(jì)劃，最好用軟件工具來管理測試工程師的任務(wù)。二、設(shè)計(jì)測試用例測試用例是用于檢驗(yàn)?zāi)繕?biāo)軟件是否符合要求的一種“示例”，基本要素有：前提條件、輸入數(shù)據(jù)或動(dòng)作、期望的響應(yīng)。測試用例就是描述各種測試用例的文檔，相當(dāng)于一本“測試操作手冊”。關(guān)于測試用例的一些常識如下：（1）設(shè)計(jì)測試用例的目的是找出需求、設(shè)計(jì)、代碼中的毛病，因此最好盡可能早地設(shè)計(jì)。（2）測試用例的設(shè)計(jì)需要?jiǎng)幽X筋，不見得比“正向設(shè)計(jì)”簡單。（3）不同的測試用例其用途應(yīng)當(dāng)不一樣，不要累贅。（4）顯而易見的測試用例不必完整地用文字描述，因?yàn)榇藭r(shí)文字描述的價(jià)值不大、反而消耗時(shí)

22、間。測試工程師根據(jù)模塊需求說明書和設(shè)計(jì)說明書，撰寫測試用例，格式見表7-8。開發(fā)工程師審閱測試用例，提出改進(jìn)建議，雙方達(dá)成共識。測試用例項(xiàng)目名稱用例名稱撰寫人測試工程師功能描述前提條件輸入 / 動(dòng)作期望的輸出示例：典型值示例：邊界值示例：異常值審閱人開發(fā)工程師審閱意見表7-8 測試用例的參考模板三、構(gòu)建測試環(huán)境測試工程師（和開發(fā)工程師）構(gòu)建測試環(huán)境，注意測試環(huán)境要盡可能接近用戶的運(yùn)行環(huán)境。7.4.2 執(zhí)行測試測試人員按照測試用例執(zhí)行測試。如果發(fā)現(xiàn)Bug，則記錄在Bug跟蹤工具中，并通知項(xiàng)目經(jīng)理或開發(fā)人員。開發(fā)人員及時(shí)消除Bug后，更改Bug跟蹤工具中的相關(guān)信息。測試人員驗(yàn)證后，關(guān)閉該Bug。7

23、.4.3 消除缺陷消除缺陷的第一步是找出缺陷的根源，如同醫(yī)生治病，必須先找出病因才能“對癥下藥”。開發(fā)人員必須從結(jié)果出發(fā)，逆向思考。一旦找到了根源，開發(fā)人員通常知道如何消除缺陷。查找缺陷的基本方法是“粗分細(xì)找”。對于隱藏得很深的Bug，應(yīng)該運(yùn)用歸納、推理、“二分”等方法先“快速、粗略”地確定錯(cuò)誤根源的范圍，然后再用調(diào)試工具仔細(xì)地跟蹤此范圍的源代碼。開發(fā)人員在改錯(cuò)時(shí)，要注意以下事項(xiàng)：（1）找到錯(cuò)誤的代碼時(shí)，不要急于修改，先思考一下：修改此代碼會(huì)不會(huì)引發(fā)其它問題？如果沒有問題，可以放心修改。如果有問題，那么可能要改動(dòng)程序結(jié)構(gòu)，而不止一行代碼。（2）有些時(shí)候，軟件中可能潛伏同一類型的許多錯(cuò)誤（例如由

24、不良的編程習(xí)慣引起的）。好不容易逮住一個(gè)，應(yīng)當(dāng)乘勝追擊，全部殲滅。（3）在改錯(cuò)之后一定要馬上重新測試，以免引入新的錯(cuò)誤。改了一個(gè)程序錯(cuò)誤固然是喜事，但要防止樂極生悲。更加嚴(yán)格的要求是：不論原先程序是否絕對正確，只要對此程序作過改動(dòng)（哪怕是微不足道的），都要重新測試。（4）上述事情做完后，應(yīng)當(dāng)好好反思：我為什么會(huì)犯這樣的錯(cuò)誤？怎么能夠防止下次不犯相似的錯(cuò)誤？最好能寫下心得體會(huì)，與他人共享經(jīng)驗(yàn)教訓(xùn)。7.5 軟硬件系統(tǒng)集成合同付款設(shè)備采購和驗(yàn)收設(shè)備驗(yàn)收簽訂合同選擇供應(yīng)商設(shè)備詢價(jià)選擇設(shè)備供應(yīng)商方案評審方案編寫系統(tǒng)集成方案設(shè)計(jì)設(shè)備安裝軟件部署設(shè)備調(diào)試設(shè)備安裝調(diào)試采購跟蹤軟硬件系統(tǒng)集成既可能是客戶的需求（

25、合同項(xiàng)目），也可能是本公司的應(yīng)用需求。軟硬件系統(tǒng)集成的一般流程如圖7-6所示，關(guān)鍵活動(dòng)是“系統(tǒng)集成方案設(shè)計(jì)”、“選擇設(shè)備供應(yīng)商”、“設(shè)備采購和驗(yàn)收”和“設(shè)備安裝調(diào)試”。圖7-6 軟硬件系統(tǒng)集成的一般流程 系統(tǒng)集成方案設(shè)計(jì)項(xiàng)目開發(fā)團(tuán)隊(duì)設(shè)計(jì)系統(tǒng)集成方案，主要工作：（1）根據(jù)需求，構(gòu)思設(shè)計(jì)系統(tǒng)集成方案。（2）編寫系統(tǒng)集成方案。（3）項(xiàng)目開發(fā)團(tuán)隊(duì)和客戶共同評審系統(tǒng)集成方案，通過后進(jìn)入下一步。 選擇設(shè)備供應(yīng)商項(xiàng)目經(jīng)理和采購人員共同“選擇設(shè)備供應(yīng)商”，主要工作：（1）對比分析多家候選供應(yīng)商的設(shè)備。（2）從多家候選供應(yīng)商中選擇合適的供應(yīng)商。（3）和選定的供應(yīng)商進(jìn)行合同談判。（4）和選定的供應(yīng)商簽訂設(shè)備采購合

26、同。7.5.3 設(shè)備采購和驗(yàn)收項(xiàng)目經(jīng)理和采購人員“采購設(shè)備并驗(yàn)收設(shè)備”，主要工作：（1）跟蹤設(shè)備采購，確保供應(yīng)商在計(jì)劃時(shí)間內(nèi)送貨。（2）設(shè)備驗(yàn)收，確保設(shè)備符合質(zhì)量要求。（3）根據(jù)合同支付相應(yīng)的款項(xiàng)。 設(shè)備安裝調(diào)試項(xiàng)目經(jīng)理安排“設(shè)備安裝調(diào)試、軟件部署”的工作計(jì)劃，主要工作：Ø 項(xiàng)目經(jīng)理協(xié)助供應(yīng)商將設(shè)備安裝在客戶指定的場地。Ø 供應(yīng)商負(fù)責(zé)調(diào)試設(shè)備，項(xiàng)目經(jīng)理檢查，確保設(shè)備正常運(yùn)行。Ø 在“部署試用”過程域中，項(xiàng)目成員將軟件部署到指定的環(huán)境中，詳見7.6節(jié)。7.6 部署試用部署試用過程域的關(guān)鍵活動(dòng)是“撰寫文檔”、“軟件部署”、“客戶培訓(xùn)”和“客戶試用”，流程見圖7-7，主

27、要工作成果見表7-9。產(chǎn)品宣傳銷售軟件部署客戶培訓(xùn)撰寫文檔客戶試用合同項(xiàng)目驗(yàn)收圖7-7 部署試用的流程關(guān)鍵活動(dòng)主要工作成果責(zé)任人撰寫文檔軟件部署客戶培訓(xùn)軟件部署說明書安裝和使用手冊項(xiàng)目指定人員客戶試用客戶試用反饋項(xiàng)目經(jīng)理表7-9 主要工作成果 撰寫文檔當(dāng)項(xiàng)目開發(fā)完成并經(jīng)過測試之后，項(xiàng)目經(jīng)理指定項(xiàng)目成員及時(shí)撰寫安裝手冊、使用手冊、軟件部署說明書等必需文檔。 軟件部署項(xiàng)目經(jīng)理審閱軟件部署說明書，模板參見表7-10，如果發(fā)現(xiàn)問題，則及時(shí)指正。項(xiàng)目經(jīng)理確認(rèn)無誤后，再安排開發(fā)工程師為客戶（或者本公司）部署軟件系統(tǒng)：² 為客戶安裝（或更新）軟件系統(tǒng)，遷移數(shù)據(jù)；² 為客戶初始化業(yè)務(wù)數(shù)據(jù)，

28、確保軟件能夠正常運(yùn)行；注意：部署的軟件系統(tǒng)必須是從配置庫中提取已經(jīng)測試通過的軟件包。最好通過Internet進(jìn)行遠(yuǎn)程部署，節(jié)省交通費(fèi)用和時(shí)間。軟件部署說明書項(xiàng)目（系統(tǒng)）名稱撰寫人1. 部署環(huán)境說明（硬件和軟件系統(tǒng)）2. 需要初始化的數(shù)據(jù)3. 需要遷移（升級）的數(shù)據(jù)4. 注意事項(xiàng)項(xiàng)目經(jīng)理審閱意見部署過程中的主要事項(xiàng)記錄表7-10 軟件部署說明書 客戶培訓(xùn)項(xiàng)目經(jīng)理指定項(xiàng)目成員（即講師）負(fù)責(zé)給客戶培訓(xùn)。講師和客戶商定培訓(xùn)計(jì)劃（確定時(shí)間、地點(diǎn)、人員批次等）。講師按照計(jì)劃給客戶培訓(xùn)，并填寫客戶培訓(xùn)記錄，格式參見表7-11，作為培訓(xùn)服務(wù)的依據(jù)?？蛻襞嘤?xùn)記錄講師課程名稱培訓(xùn)時(shí)間地點(diǎn)客戶名稱學(xué)員培訓(xùn)內(nèi)容介紹相

29、關(guān)資料客戶簽字確認(rèn)表7-11 客戶培訓(xùn)記錄 客戶試用對于自主產(chǎn)品，項(xiàng)目成員把軟件部署到本公司指定的機(jī)器上，產(chǎn)品經(jīng)理邀請潛在客戶試用本軟件。對于合同項(xiàng)目，項(xiàng)目成員把軟件部署到客戶指定的機(jī)器上，客戶方人員試用軟件?？蛻舴胶烷_發(fā)方在簽訂合同的時(shí)候，應(yīng)當(dāng)確定“試用協(xié)議”。如果事先沒有商定，雙方可以根據(jù)軟件復(fù)雜程度協(xié)商后補(bǔ)充“試用協(xié)議”。常見的“試用協(xié)議”如下：當(dāng)乙方（開發(fā)方）為甲方（客戶方）部署軟件并進(jìn)行培訓(xùn)后，甲方組織人員進(jìn)行為期X周的軟件試用。在試用期間內(nèi)，如果甲方發(fā)現(xiàn)軟件中存在嚴(yán)重的Bug（如死機(jī)、數(shù)據(jù)丟失、無法運(yùn)行等），則乙方應(yīng)當(dāng)在24小時(shí)之內(nèi)給出解決問題的措施。如果超過試用期，乙方仍然沒有完全消除甲方報(bào)告的Bug，那么試用期順延，直到乙方完全消除甲方報(bào)告的Bug為止。如果甲方在試用期間內(nèi)沒有報(bào)告嚴(yán)重Bug，那么試用期結(jié)束時(shí)，視為順利通過試用。如果試用期間，甲方提出改進(jìn)需求、以及報(bào)告了一些不嚴(yán)重的缺陷，乙方作為正常維護(hù)工作來處理，不延誤甲方驗(yàn)收產(chǎn)品。客戶在試用軟件的過程中，將發(fā)現(xiàn)的Bug以及對軟件的建議及時(shí)告知開發(fā)方。項(xiàng)目經(jīng)理和開發(fā)工程師及時(shí)處理客戶反饋來的Bug和建議。² 對于客戶發(fā)現(xiàn)的Bug，開發(fā)方應(yīng)當(dāng)立即糾正。