1、集成化軟件研發(fā)流程IDP 5.0Integrated Development Processes第5章IDP項目研發(fā)過程上海漫索計算機科技有限公司5.1需求開發(fā)與管理 45.1.1 需求調(diào)研 55.1.2 需求分析 65.1.3 需求定義 65.1.4 需求評審確認 75.1.5 需求細化跟蹤 85.1.6 需求變更控制 85.2軟件系統(tǒng)設(shè)計 95.2.1 系統(tǒng)結(jié)構(gòu)設(shè)計 105.2.2 用戶界面設(shè)計 105.2.3 數(shù)據(jù)庫設(shè)計 125.2.4 系統(tǒng)設(shè)計評審 125.3模塊開發(fā)和集成 125.3.1 模塊需求細化 125.3.2 模塊設(shè)計 135.3.3 模塊實現(xiàn)和集成 145.4測試與改錯 1

2、45.4.1 測試準(zhǔn)備 155.4.2 執(zhí)行測試 165.4.3 消除缺陷 165.5軟硬件系統(tǒng)集成 175.5.1 系統(tǒng)集成方案設(shè)計 175.5.2 選擇設(shè)備供應(yīng)商 175.5.3 設(shè)備采購和驗收 18設(shè)備安裝調(diào)試 185.6部署試用185.6.1 撰寫文檔 195.6.2 軟件部署 195.6.3 客戶培訓(xùn) 205.6.4 客戶試用 205.7軟件維護215.7.1 接受維護請求 225.7.2 分析維護請求 225.7.3 執(zhí)行維護 225.1需求開發(fā)與管理需求開發(fā)與管理的目的是通過“調(diào)研、分析、定義、評審確認、細化跟蹤、變更控 制”等活動，使開發(fā)方和客戶對需求有共同、清晰的理解，并依據(jù)

3、雙方確認的需求開展 后續(xù)開發(fā)工作（如設(shè)計、編程、測試等）。需求開發(fā)與管理的流程如圖5-1所示，該流程的主要工作成果和責(zé)任人見表5-1 o一般地，在立項之前，產(chǎn)品經(jīng)理應(yīng)當(dāng)撰寫產(chǎn)品需求說明書，項目銷售人員應(yīng)當(dāng)撰寫合同項目需求說明書 。但是此時的需求說明書通常是宏觀粗略的，不足以讓項目開發(fā)團隊依據(jù)此需求說明書開展設(shè)計和編程工作。項目開發(fā)團隊?wèi)?yīng)當(dāng)在產(chǎn)品經(jīng)理、銷售人員的工作成果基礎(chǔ)之上，進一步開展需求調(diào) 研、分析、定義、評審確認、細化和跟蹤活動。項目經(jīng)理根據(jù)本項目的人力資源來確定 需求分析員（通常是項目經(jīng)理或資深開發(fā)工程師擔(dān)任需求分析員）°需求管理需求開發(fā)調(diào)研需求調(diào)研需求分析需求 關(guān)鍵活動需求

4、分析廠圖5-1、fr需求主定義需求開發(fā)與管理的流程 評審要工作成果確認需求調(diào)研記錄細化跟蹤 變更 主要責(zé)任人需求評審確認需求評審報告，簽字確認開發(fā)方和客戶方的責(zé)任人需求細化跟蹤需求跟蹤表需求分析員需求變更控制需求變更控制報告開發(fā)方和客戶方的責(zé)任人產(chǎn)品需求說明書或需求分析員需求定義合同項目需求說明書表5-1主要工作成果和責(zé)任人5.1.1 需求調(diào)研需求分析員起草需求問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)研工作將變得 漫無邊際。需求分析員確定需求調(diào)研的方式，例如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調(diào)查問卷。 與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的

5、同類軟件產(chǎn)品，提取需求。從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。從In ternet上搜查相關(guān)資料。需求分析員與被訪談?wù)呓⒙?lián)系，確定調(diào)查的時間、地點、人員等，要特別留意的 是不要漏掉典型的用戶。需求分析員在調(diào)研過程中隨時填寫“客戶需求記錄”，參考格式如表 5-2所示。提示:集成化研發(fā)管理平臺RDMS的“客戶需求記錄”功能滿足此要求。項目名稱需求分析員被調(diào)研者調(diào)研方式如面談，電話交談等時間、地點需求標(biāo)題描述表5-2客戶需求記錄的參考格式需求分析員整理所有客戶需求記錄，歸納與總結(jié)共性的需求，為撰寫詳細的需求 說明書作準(zhǔn)備。調(diào)研過程中獲取的需求信息可以作為需求說明書的附件。需求分析需求分析的目的是對各種需求信

6、息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)

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

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

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

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

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

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

13、”圖5-3軟件系統(tǒng)設(shè)計的示意圖（可以多人）。系統(tǒng)設(shè)計師撰寫軟 所有的模塊都是在該系統(tǒng)框架上開5-4。項目經(jīng)理根據(jù)本項目的人力資源來確定系統(tǒng)設(shè)計師 件系統(tǒng)設(shè)計說明書，并構(gòu)造可運行的軟件系統(tǒng)框架, 發(fā)和運行。軟件系統(tǒng)設(shè)計說明書的模板參見表軟件系統(tǒng)設(shè)計說明書1. 系統(tǒng)概述2. 設(shè)計約束3. 開發(fā)、測試與運行環(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)定性和可擴展性8.2性能分

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

15、有什么喜好? 有什么強制要求? 是否有范例系統(tǒng)設(shè)計師構(gòu)思并繪制用戶界面示意圖，常用方式如下：? 在紙張上繪制用戶界面示意圖（效率高但是不便于保存）? 用Word或者Visio等工具繪制線框圖（效率低但可以作為文檔保存）第2步制作界面原型系統(tǒng)設(shè)計師制作界面原型（通過編程或者繪圖等方式），將所有界面原型的圖片保存在指定的文件夾中，并用HTML建立簡要的索引，這樣做的好處有：? 便于其他人員審閱（使用 IE瀏覽）；? 需求分析員不必將界面原型圖片插入到需求文檔中；? 修改界面原型圖片將不會影響其它文件；第3步體驗和改進界面設(shè)計師邀請項目成員或者用戶來體驗界面原型，大家給出改進建議，力求使用戶界面滿足

16、以下 10個設(shè)計要素：（1）用戶界面適合于展現(xiàn)軟件的功能（2）適合用戶群體（2）容易理解（3）及時反饋信息（4 ）防錯處理（5）合理的布局（6）合理的色彩（7）風(fēng)格一致和必要的個性化（9）最少操作步驟（最高效率）（10）國際化、可復(fù)用等523數(shù)據(jù)庫設(shè)計系統(tǒng)設(shè)計師進行數(shù)據(jù)庫設(shè)計:確定數(shù)據(jù)庫的環(huán)境說明確定數(shù)據(jù)庫的命名規(guī)則?確定安全性設(shè)計方法?使用表設(shè)計工具PowerDesign設(shè)計主要的表結(jié)構(gòu)524系統(tǒng)設(shè)計評審當(dāng)系統(tǒng)設(shè)計師撰寫完成軟件系統(tǒng)設(shè)計說明書并構(gòu)建可運行的系統(tǒng)框架之后，邀 請項目成員（包括項目經(jīng)理）和本公司技術(shù)專家開展系統(tǒng)設(shè)計評審。詳見“技術(shù)評審” 的流程。系統(tǒng)設(shè)計評審的目的是，在同行專家的

17、幫助下，盡早地發(fā)現(xiàn)本系統(tǒng)中存在的設(shè)計缺 陷，及時消除設(shè)計缺陷。5.3模塊開發(fā)和集成增量模式的模塊開發(fā)和集成流程如圖 塊設(shè)計”和“模塊實現(xiàn)和集成”。項目經(jīng)理分配任務(wù)給開發(fā)工程師，5-4所示，主要內(nèi)容有：“模塊需求細化”開發(fā)工程師對自己承擔(dān)模塊的質(zhì)量和進度負責(zé)、“模。模塊需求細化L_i、模塊需求說明書模塊設(shè)計1模塊設(shè)計說明書增量開發(fā)模塊實現(xiàn)和集成 模塊開發(fā)和集成的流程可運行模塊，交付測試 f圖5-45.3.1 模塊需求細化，分析并細化自己承開發(fā)工程師閱讀產(chǎn)品需求說明書或合同項目需求說明書擔(dān)的模塊需求，撰寫詳細的模塊需求說明書，模板參見表 5-5。如果發(fā)生比較大的需求變更，則按“變更控制流程”執(zhí)行，

18、向項目經(jīng)理申請需求變更。模塊需求說明書項目名稱撰寫人/修改人模塊名稱完成日期1.模塊用途和功能介紹2.模塊流程介紹（可選）3.字段說明字段名稱必填項*說明4.操作說明操作名稱功能說明用戶角色和權(quán)限表5-5模塊需求說明書的參考模板模塊設(shè)計模塊設(shè)計的主要內(nèi)容:? 設(shè)計模塊的接口；? 設(shè)計模塊的數(shù)據(jù)結(jié)構(gòu)和算法；? 設(shè)計和細化本模塊相關(guān)的用戶界面;? 設(shè)計和細化本模板相關(guān)的數(shù)據(jù)庫；，參考模板見對于比較復(fù)雜的模塊，開發(fā)工程師應(yīng)當(dāng)撰寫必要的模塊設(shè)計說明書表 5-6。模塊設(shè)計說明書項目名稱撰寫人/修改人模塊名稱完成日期1. 主要編程接口2. 主要數(shù)據(jù)結(jié)構(gòu)3. 主要算法4. 相關(guān)的用戶界面設(shè)計說明5. 相關(guān)的

19、數(shù)據(jù)庫設(shè)計說明表5-6模塊設(shè)計說明書的參考模塊533模塊實現(xiàn)和集成所有開發(fā)工程師按照既定的編程規(guī)范來實現(xiàn)自己承擔(dān)的模塊，并在系統(tǒng)框架中和其 它模塊集成一起。開發(fā)工程師自己必須先進行測試，必須走通模塊的功能，消除自己已經(jīng)發(fā)現(xiàn)的缺陷。開發(fā)工程師把待測試的軟件包發(fā)布到約定的測試機器上，把本模塊相關(guān)的需求說明 書、設(shè)計說明書交付給測試人員，并向測試人員解釋清楚待測試模塊的特征。5.4測試與改錯測試與改錯的目的是在給定的項目條件下（人員、時間、工具等限制）盡可能地找 出軟件中的缺陷，并及時消除這些缺陷。測試與改錯的流程如圖5-5所示，關(guān)鍵活動是“準(zhǔn)備測試”、“執(zhí)行測試”和“消除缺陷”。建議使用缺陷跟蹤工

20、具和測試管理工具，用于記錄測試用例和修改Bug的整個過程。提示：集成化研發(fā)管理平臺RDMS的“測試管理”和“缺陷跟蹤”功能滿足此要求。H測試人員譽開發(fā)人員圖5-5軟件測試與改錯的流程541測試準(zhǔn)備測試準(zhǔn)備主要有 3件事情：制定測試計劃，設(shè)計測試用例，構(gòu)建測試環(huán)境。一、制定測試計劃測試工程師和項目經(jīng)理商議測試計劃，撰寫測試計劃，最好用軟件工具來管理測試工程師的任務(wù)。二、設(shè)計測試用例測試用例是用于檢驗?zāi)繕?biāo)軟件是否符合要求的一種“示例”，基本要素有：前提條件、輸入數(shù)據(jù)或動作、期望的響應(yīng)。測試用例就是描述各種測試用例的文檔，相當(dāng)于一本“測試操作手冊”。關(guān)于測試用例的一些常識如下：（1）設(shè)計測試用例的目

21、的是找出需求、設(shè)計、代碼中的毛病，因此最好盡可能早地 設(shè)計。（2）測試用例的設(shè)計需要動腦筋，不見得比“正向設(shè)計”簡單。（3）不同的測試用例其用途應(yīng)當(dāng)不一樣，不要累贅。（4） 顯而易見的測試用例不必完整地用文字描述，因為此時文字描述的價值不大、 反而消耗時間。，格式見表 5-8。測試工程師根據(jù)模塊需求說明書和設(shè)計說明書，撰寫測試用例 開發(fā)工程師審閱測試用例，提出改進建議，雙方達成共識。測試用例項目名稱用例名稱撰寫人測試工程師功能描述前提條件輸入/動作期望的輸岀示例：典型值示例：邊界值示例：異常值審閱人開發(fā)工程師審閱意見表5-8測試用例的參考模板三、構(gòu)建測試環(huán)境測試工程師（和開發(fā)工程師）構(gòu)建測試環(huán)

22、境，注意測試環(huán)境要盡可能接近用戶的運 行環(huán)境。執(zhí)行測試測試人員按照測試用例執(zhí)行測試。如果發(fā)現(xiàn)Bug，則記錄在 Bug跟蹤工具中，并通知項目經(jīng)理或開發(fā)人員。開發(fā)人員及時消除 Bug后，更改Bug跟蹤工具中的相關(guān)信息。測試人員驗證后，關(guān) 閉該Bug。543消除缺陷消除缺陷的第一步是找出缺陷的根源，如同醫(yī)生治病，必須先找出病因才能“對癥 下藥”。開發(fā)人員必須從結(jié)果出發(fā)，逆向思考。一旦找到了根源，開發(fā)人員通常知道如何 消除缺陷。查找缺陷的基本方法是“粗分細找”。對于隱藏得很深的Bug，應(yīng)該運用歸納、 推理、“二分”等方法先“快速、粗略”地確定錯誤根源的范圍，然后再用調(diào)試工具仔細地跟蹤此范圍的源代碼。開

23、發(fā)人員在改錯時，要注意以下事項：（1）找到錯誤的代碼時， 不要急于修改， 先思考一下：修改此代碼會不會引發(fā)其它問題？ 如果沒有問題，可以放心修改。如果有問題，那么可能要改動程序結(jié)構(gòu)，而不止一行代碼。（2） 有些時候，軟件中可能潛伏同一類型的許多錯誤（例如由不良的編程習(xí)慣引起的） 好不容易逮住一個，應(yīng)當(dāng)乘勝追擊，全部殲滅。（3） 在改錯之后一定要馬上重新測試，以免引入新的錯誤。改了一個程序錯誤固然是喜 事，但要防止樂極生悲。更加嚴格的要求是：不論原先程序是否絕對正確，只要對此程序作過改動（哪怕是微不足道的），都要重新測試。（4） 上述事情做完后，應(yīng)當(dāng)好好反思：我為什么會犯這樣的錯誤？怎么能夠防止

24、下次不 犯相似的錯誤？最好能寫下心得體會，與他人共享經(jīng)驗教訓(xùn)。5.5軟硬件系統(tǒng)集成軟硬件系統(tǒng)集成既可能是客戶的需求(合同項目)，也可能是本公司的應(yīng)用需求。軟硬件系統(tǒng)集成的一般流程如圖5-6所示，關(guān)鍵活動是“系統(tǒng)集成方案設(shè)計”、“選擇設(shè)備供應(yīng)商”、“設(shè)備采購和驗收”和“設(shè)備安裝調(diào)試”。方 案 編 寫5.51方 案 評 審設(shè)備詢價選擇供圖5-6應(yīng)合軟硬'件系統(tǒng)集成同的一般流程合同付款商系統(tǒng)集成方案項目開發(fā)團隊設(shè)計系統(tǒng)集成方案，主要工作:(1 )根據(jù)需求，構(gòu)思設(shè)計系統(tǒng)集成方案。(2)編寫系統(tǒng)集成方案，通過后進入下一步。(3 )項目開發(fā)團隊和客戶共同評審系統(tǒng)集成方案5.5.2 選擇設(shè)備供應(yīng)商項

25、目經(jīng)理和采購人員共同“選擇設(shè)備供應(yīng)商”，主要工作:(1)對比分析多家候選供應(yīng)商的設(shè)備。(2)從多家候選供應(yīng)商中選擇合適的供應(yīng)商。(3) 和選定的供應(yīng)商進行合同談判。(4 )和選定的供應(yīng)商簽訂設(shè)備采購合同。5.5.3設(shè)備米購和驗收項目經(jīng)理和采購人員“采購設(shè)備并驗收設(shè)備”，主要工作:(1) 跟蹤設(shè)備采購，確保供應(yīng)商在計劃時間內(nèi)送貨。(2 )設(shè)備驗收，確保設(shè)備符合質(zhì)量要求。(3)根據(jù)合同支付相應(yīng)的款項。5.5.4設(shè)備安裝調(diào)試項目經(jīng)理安排“設(shè)備安裝調(diào)試、軟件部署”的工作計劃，主要工作：? 項目經(jīng)理協(xié)助供應(yīng)商將設(shè)備安裝在客戶指定的場地。? 供應(yīng)商負責(zé)調(diào)試設(shè)備，項目經(jīng)理檢查，確保設(shè)備正常運行。7.6 節(jié)。

26、? 在“部署試用”過程域中，項目成員將軟件部署到指定的環(huán)境中，詳見5.6部署試用部署試用過程域的關(guān)鍵活動是“撰寫文檔”、“軟件部署”、“客戶培訓(xùn)”和“客戶試用”，流程見圖5-7，主要工作成果見表 5-9。撰寫文檔軟件部署客戶培訓(xùn)客戶試用合同項目驗收、產(chǎn)品宣傳銷售圖5-7部署試用的流程關(guān)鍵活動主要工作成果責(zé)任人撰寫文檔軟件部署客戶培訓(xùn)軟件部署說明書安裝和使用手冊項目指定人員客戶試用客戶試用反饋項目經(jīng)理表5-9主要工作成果撰寫文檔當(dāng)項目開發(fā)完成并經(jīng)過測試之后，項目經(jīng)理指定項目成員及時撰寫安裝手冊、使用手冊、軟件部署說明書等必需文檔。562軟件部署項目經(jīng)理審閱軟件部署說明書，模板參見表 5-10，如

27、果發(fā)現(xiàn)問題，則及時指正。項目經(jīng)理確認無誤后，再安排開發(fā)工程師為客戶（或者本公司）部署軟件系統(tǒng)：為客戶安裝（或更新）軟件系統(tǒng)，遷移數(shù)據(jù)；為客戶初始化業(yè)務(wù)數(shù)據(jù)，確保軟件能夠正常運行；注意：部署的軟件系統(tǒng)必須是從配置庫中提取已經(jīng)測試通過的軟件包。最好通過In ternet進行遠程部署，節(jié)省交通費用和時間。軟件部署說明書項目（系統(tǒng)）名稱撰寫人1. 部署環(huán)境說明（硬件和軟件系統(tǒng)）2. 需要初始化的數(shù)據(jù)3. 需要遷移（升級）的數(shù)據(jù)4. 注意事項項目經(jīng)理審閱意見部署過程中的主要事項記錄表5-10軟件部署說明書563客戶培訓(xùn)項目經(jīng)理指定項目成員（即講師）負責(zé)給客戶培訓(xùn)。講師和客戶商定培訓(xùn)計劃（確 定時間、地點

28、、人員批次等）。講師按照計劃給客戶培訓(xùn)，并填寫客戶培訓(xùn)記錄，格式參見表 5-11，作為培訓(xùn)服務(wù)的依據(jù)。客戶培訓(xùn)記錄講師課程名稱培訓(xùn)時間地點客戶名稱學(xué)員培訓(xùn)內(nèi)容介紹相關(guān)資料客戶簽字確認表5-11客戶培訓(xùn)記錄564 客戶試用對于自主產(chǎn)品，項目成員把軟件部署到本公司指定的機器上，產(chǎn)品經(jīng)理邀請潛在客 戶試用本軟件。對于合同項目，項目成員把軟件部署到客戶指定的機器上，客戶方人員試用軟件。客戶方和開發(fā)方在簽訂合同的時候，應(yīng)當(dāng)確定“試用協(xié)議”。如果事先沒有商定，雙方可以根據(jù)軟件復(fù)雜程度協(xié)商后補充“試用協(xié)議”。常見的“試用協(xié)議”如下：當(dāng)乙方（開發(fā)方）為甲方（客戶方）部署軟件并進行培訓(xùn)后，甲方組織人員進行為期X周的軟件試用。在試用期間內(nèi)，如果甲方發(fā)現(xiàn)軟件中存在嚴重的Bug （如死機、數(shù)據(jù)丟失、無法運行等），則乙方應(yīng)當(dāng)在24小時之內(nèi)給出解決問題的措施。如果超過試用期，乙方仍然沒有完全消除甲方報告的Bug，那么試用期順延， 直到乙方完全消除甲方報告的Bug為止。如果甲方在試用期間內(nèi)沒有報告嚴重Bug，那么試用期結(jié)束時，視為順利通過試用。如果試用期間，甲方提出改進需求、以及報告了一些不嚴重的缺陷，乙方作為正常維護工作來處理，不延誤甲方驗收產(chǎn)品。客戶在試用軟件的過程中，將發(fā)現(xiàn)的Bug以及對軟件的建議及時告知開發(fā)方。項目經(jīng)理和開發(fā)工程師及時處理客戶反饋來的Bug和建議。對于客戶發(fā)現(xiàn)的 Bug，開發(fā)