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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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