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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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