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

1、IDP項目研發(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è)計97.2.1 系統(tǒng)結(jié)構(gòu)設(shè)計10 用戶界面設(shè)計107.2.3 數(shù)據(jù)庫設(shè)計117.2.4 系統(tǒng)設(shè)計評審127.3 模塊開發(fā)和集成127.3.1 模塊需求細(xì)化127.3.2 模塊設(shè)計137.3.3 模塊實(shí)現(xiàn)和集成147.4 測試與改錯147.4.1 測試準(zhǔn)備147.4.2 執(zhí)行測試167.4.3 消除缺陷167.5 軟硬件系統(tǒng)集成177.5.1 系統(tǒng)集成方案設(shè)計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ì)化跟蹤、變更控制”等活動，使開發(fā)方和客戶對需求有共同、清晰的理解，并依據(jù)雙方確認(rèn)的需求開展后續(xù)開發(fā)工作（如設(shè)計、編程、測試等）。需求開發(fā)與管理的流程如圖7-1所示，該流程的主要工作成果和責(zé)任人見表7-1。一般地，在立項之前，產(chǎn)品經(jīng)理應(yīng)當(dāng)撰寫產(chǎn)

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

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

6、最重要的問題是：“是什么”和“為什么”。每個需求都應(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é)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而

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

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

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

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

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

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

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

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

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

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

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

19、 設(shè)計和細(xì)化本模塊相關(guān)的用戶界面；Ø 設(shè)計和細(xì)化本模板相關(guān)的數(shù)據(jù)庫；對于比較復(fù)雜的模塊，開發(fā)工程師應(yīng)當(dāng)撰寫必要的模塊設(shè)計說明書，參考模板見表7-6。模塊設(shè)計說明書項目名稱撰寫人/ 修改人模塊名稱完成日期1. 主要編程接口2. 主要數(shù)據(jù)結(jié)構(gòu)3. 主要算法4. 相關(guān)的用戶界面設(shè)計說明5. 相關(guān)的數(shù)據(jù)庫設(shè)計說明表7-6 模塊設(shè)計說明書的參考模塊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è)計說明書交付給測試人員，并向測試人員解釋清楚待測試模塊的特征。7.4 測試與改錯測試與改錯的目的是在給定的項目條件下（人員、時間、工具等限制）盡可能地找出軟件中的缺陷，并及時消除這些缺陷。測試與改錯的流程如圖7-5所示，關(guān)鍵活動是“準(zhǔn)備測試”、“執(zhí)行測試”和“消除缺陷”。建議使用缺陷跟蹤工具和測試管理工具，用于記錄測試用例和修改Bug的整個過程。提示：集成化研發(fā)管理平臺RDMS的“測試管理”和“缺陷跟蹤”功能滿足此要求。測試準(zhǔn)備消除缺陷 開發(fā)人員 測試人員審核關(guān)閉缺陷跟蹤執(zhí)行測試圖7-5 軟件測試與改錯的流程7.4.1 測試準(zhǔn)備測試準(zhǔn)備主要有3件事情：制定測試計劃，設(shè)計測試用例

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

22、間。測試工程師根據(jù)模塊需求說明書和設(shè)計說明書，撰寫測試用例，格式見表7-8。開發(fā)工程師審閱測試用例，提出改進(jìn)建議，雙方達(dá)成共識。測試用例項目名稱用例名稱撰寫人測試工程師功能描述前提條件輸入 / 動作期望的輸出示例：典型值示例：邊界值示例：異常值審閱人開發(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跟蹤工具中，并通知項目經(jīng)理或開發(fā)人員。開發(fā)人員及時消除Bug后，更改Bug跟蹤工具中的相關(guān)信息。測試人員驗(yàn)證后，關(guān)閉該Bug。7

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

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

25、合同項目），也可能是本公司的應(yīng)用需求。軟硬件系統(tǒng)集成的一般流程如圖7-6所示，關(guān)鍵活動是“系統(tǒng)集成方案設(shè)計”、“選擇設(shè)備供應(yīng)商”、“設(shè)備采購和驗(yàn)收”和“設(shè)備安裝調(diào)試”。圖7-6 軟硬件系統(tǒng)集成的一般流程 系統(tǒng)集成方案設(shè)計項目開發(fā)團(tuán)隊設(shè)計系統(tǒng)集成方案，主要工作：（1）根據(jù)需求，構(gòu)思設(shè)計系統(tǒng)集成方案。（2）編寫系統(tǒng)集成方案。（3）項目開發(fā)團(tuán)隊和客戶共同評審系統(tǒng)集成方案，通過后進(jìn)入下一步。 選擇設(shè)備供應(yī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)收項目經(jīng)理和采購人員“采購設(shè)備并驗(yàn)收設(shè)備”，主要工作：（1）跟蹤設(shè)備采購，確保供應(yīng)商在計劃時間內(nèi)送貨。（2）設(shè)備驗(yàn)收，確保設(shè)備符合質(zhì)量要求。（3）根據(jù)合同支付相應(yīng)的款項。 設(shè)備安裝調(diào)試項目經(jīng)理安排“設(shè)備安裝調(diào)試、軟件部署”的工作計劃，主要工作：Ø 項目經(jīng)理協(xié)助供應(yīng)商將設(shè)備安裝在客戶指定的場地。Ø 供應(yīng)商負(fù)責(zé)調(diào)試設(shè)備，項目經(jīng)理檢查，確保設(shè)備正常運(yùn)行。Ø 在“部署試用”過程域中，項目成員將軟件部署到指定的環(huán)境中，詳見7.6節(jié)。7.6 部署試用部署試用過程域的關(guān)鍵活動是“撰寫文檔”、“軟件部署”、“客戶培訓(xùn)”和“客戶試用”，流程見圖7-7，主

27、要工作成果見表7-9。產(chǎn)品宣傳銷售軟件部署客戶培訓(xùn)撰寫文檔客戶試用合同項目驗(yàn)收圖7-7 部署試用的流程關(guān)鍵活動主要工作成果責(zé)任人撰寫文檔軟件部署客戶培訓(xùn)軟件部署說明書安裝和使用手冊項目指定人員客戶試用客戶試用反饋項目經(jīng)理表7-9 主要工作成果 撰寫文檔當(dāng)項目開發(fā)完成并經(jīng)過測試之后，項目經(jīng)理指定項目成員及時撰寫安裝手冊、使用手冊、軟件部署說明書等必需文檔。 軟件部署項目經(jīng)理審閱軟件部署說明書，模板參見表7-10，如果發(fā)現(xiàn)問題，則及時指正。項目經(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)用和時間。軟件部署說明書項目（系統(tǒng)）名稱撰寫人1. 部署環(huán)境說明（硬件和軟件系統(tǒng)）2. 需要初始化的數(shù)據(jù)3. 需要遷移（升級）的數(shù)據(jù)4. 注意事項項目經(jīng)理審閱意見部署過程中的主要事項記錄表7-10 軟件部署說明書 客戶培訓(xùn)項目經(jīng)理指定項目成員（即講師）負(fù)責(zé)給客戶培訓(xùn)。講師和客戶商定培訓(xùn)計劃（確定時間、地點(diǎn)、人員批次等）。講師按照計劃給客戶培訓(xùn)，并填寫客戶培訓(xùn)記錄，格式參見表7-11，作為培訓(xùn)服務(wù)的依據(jù)?？蛻襞嘤?xùn)記錄講師課程名稱培訓(xùn)時間地點(diǎn)客戶名稱學(xué)員培訓(xùn)內(nèi)容介紹相

29、關(guān)資料客戶簽字確認(rèn)表7-11 客戶培訓(xùn)記錄 客戶試用對于自主產(chǎn)品，項目成員把軟件部署到本公司指定的機(jī)器上，產(chǎn)品經(jīng)理邀請潛在客戶試用本軟件。對于合同項目，項目成員把軟件部署到客戶指定的機(jī)器上，客戶方人員試用軟件?？蛻舴胶烷_發(fā)方在簽訂合同的時候，應(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小時之內(nèi)給出解決問題的措施。如果超過試用期，乙方仍然沒有完全消除甲方報告的Bug，那么試用期順延，直到乙方完全消除甲方報告的Bug為止。如果甲方在試用期間內(nèi)沒有報告嚴(yán)重Bug，那么試用期結(jié)束時，視為順利通過試用。如果試用期間，甲方提出改進(jìn)需求、以及報告了一些不嚴(yán)重的缺陷，乙方作為正常維護(hù)工作來處理，不延誤甲方驗(yàn)收產(chǎn)品?？蛻粼谠囉密浖倪^程中，將發(fā)現(xiàn)的Bug以及對軟件的建議及時告知開發(fā)方。項目經(jīng)理和開發(fā)工程師及時處理客戶反饋來的Bug和建議。² 對于客戶發(fā)現(xiàn)的Bug，開發(fā)方應(yīng)當(dāng)立即糾正。