工行個人消費信貸項目軟件開發(fā)質量計劃

1、.軟件質量計劃 PAGE ;PAGE 9軟件質量計劃（文檔編號：DW-ZFZQ-01-001）方正奧德計算機系統(tǒng)有限公司2002年9月文檔管理信息表主題：質量計劃版本：10.0內容：關于個貸總行移植質量的計劃關鍵字參考文檔：提交時間：2002年11月29日創(chuàng)建人：劉軍偉文檔修改記錄表修改人修改時間修改內容目 錄 TOC o 1-3 1、 產品的質量目標 PAGEREF _Toc503110527 h 12、 質量保證措施 PAGEREF _Toc503110528 h 12.1、設計過程質量保證措施 PAGEREF _Toc503110529 h 12.1.1、實際和開發(fā)的策劃 PAGEREF

2、 _Toc503110530 h 12.1.2、組織和技術接口設計 PAGEREF _Toc503110531 h 12.1.3、設計輸入和輸出及驗收準則 PAGEREF _Toc503110532 h 22.1.4、設計評審 PAGEREF _Toc503110533 h 32.1.5、設計驗證 PAGEREF _Toc503110534 h 42.1.6、設計確認 PAGEREF _Toc503110535 h 42.1.7、設計更改 PAGEREF _Toc503110536 h 42.1.8、病毒防治 PAGEREF _Toc503110537 h 42.2、測試過程質量保證措施 PA

3、GEREF _Toc503110538 h 52.2.1、測試階段 PAGEREF _Toc503110539 h 52.2.2、測試規(guī)范 PAGEREF _Toc503110540 h 52.2.3、測試要求 PAGEREF _Toc503110541 h 52.2.4、質量記錄 PAGEREF _Toc503110542 h 52.2.5、其它 PAGEREF _Toc503110543 h 52.3、維護過程質量保證措施 PAGEREF _Toc503110544 h 52.3.1、維護要求 PAGEREF _Toc503110545 h 52.3.2、質量記錄 PAGEREF _Toc

4、503110546 h 63、 風險控制 PAGEREF _Toc503110547 h 64、 質量保證活動的職責和權限 PAGEREF _Toc503110548 h 9產品的質量目標系統(tǒng)的接收標準為用戶接收的UAT測試報告， 系統(tǒng)測試報告和模塊測試報告。產品的質量目標為：1.UAT測試中， 系統(tǒng)的功能要求和效率要求滿足合同要求和需求規(guī)格說明書要求。2.在模塊測試和系統(tǒng)測試中，沒有影響系統(tǒng)運行的嚴重BUG, 屬于實現形式、操作形式上的BUG應該低于 1個/千行；3.已發(fā)現BUG的修改率為95%；4.系統(tǒng)的接收時間與合同時間的差異小于1個月。質量保證措施按照公司的質量管理體系以及部門的質量管

5、理規(guī)范，在需求分析、軟件設計、軟件實現、軟件測試和售后服務等各個階段，應有嚴格的質量保證措施。具體劃分為如下階段：設計過程質量保證措施實際和開發(fā)的策劃在開發(fā)計劃中對需求分析、軟件設計、軟件實現、軟件測試和測試狀態(tài)及軟件發(fā)布等幾個開發(fā)階段進行了策劃，并將各個階段的活動配備了相應的資源，保證落實到有資格的開發(fā)人員，而且開發(fā)人員基本上劃分了相應的職責。組織和技術接口設計開發(fā)實施過程遵循公司質量體系規(guī)范, 在開發(fā)實施每個階段由項目經理提交階段性成果記錄, 部門秘書向相關部門傳遞成果記錄, 由相關部門進行評審。組織接口有：項目推進部（提供項目建議書、合同、立項報告；接收并審核開發(fā)計劃）；商務管理部（接收

6、并審核開發(fā)計劃、質量計劃、需求分析、設計分析、測試計劃等程序文件要求商務管理部審核的階段性控制資料）；總裁辦公室（發(fā)版審核等）。設計輸入和輸出及驗收準則開發(fā)階段階段輸入階段輸出驗收準則進入下一階段要求需求分析項目合同書（要求評審）、軟件開發(fā)計劃（要求評審）、軟件質量計劃（要求評審）、經營性網站備案登記管理暫行辦法、合同評審記錄表需求分析說明書（要求評審）功能范圍描述全面無落漏；功能描述做到明確無歧義；滿足輸入條件。通過驗收準則通過評審軟件設計需求分析說明書（要求評審）軟件質量計劃（要求評審）、軟件開發(fā)計劃（要求評審）軟件設計說明書（要求評審代碼模塊劃分及輸入輸出關系明確；算法明確；符合需求說明

7、書的功能、性能要求；滿足輸入條件。通過驗收準則通過評審編碼實現軟件質量計劃、軟件設計說明書系統(tǒng)代碼（要求評審）、軟件測試計劃（要求評審）、代碼抽查驗證表（要求評審）編碼嚴格遵守詳細設計， 必要的調整必須寫入備忘錄；遵守編碼規(guī)范；滿足輸入條件。通過驗收準則通過評審軟件測試和測試狀態(tài)系統(tǒng)編碼、軟件測試計劃、軟件質量計劃、測試大綱、模塊測試通過標準、系統(tǒng)測試通過標準模塊測試報告（要求審批）、系統(tǒng)測試報告（要求審批）功能實現測試， 需求說明中的功能全部實現；性能測試滿足預期用戶的訪問效率要求；滿足輸入條件。通過驗收準則通過評審軟件發(fā)布確認需求分析說明書、軟件設計說明書、用戶手冊、測試大綱、測試報告、軟

8、件原碼、軟件母盤用戶接受報告UAT測試報告滿足用戶確認系統(tǒng)功能和性能滿足需求；滿足輸入條件。通過驗收準則通過評審設計評審開發(fā)階段時間會議內容人員軟件需求分析評審2002/9/1討論需求分析設計情況， 審查需求分析說明書；用戶簽字；總控組;項目經理;客戶代表;系統(tǒng)設計總結2002/9/20總結軟件設計情況，審查設計說明書總控組;項目經理;編碼實現總結2002/9/25總結編碼實現情況， 審查編碼計劃， 代碼抽查驗證表，代碼完成情況表總控組;項目經理;開發(fā)人員;軟件測試總結2002/11/5總結模塊測試,系統(tǒng)測試情況。審查模塊測試報告， 系統(tǒng)測試報告總控組;項目經理;開發(fā)人員;測試人員;系統(tǒng)發(fā)布準

9、備2002/12/6討論系統(tǒng)發(fā)布的準備工作；審查發(fā)布有關文檔， 包括：需求分析說明書、設計說明書， 開發(fā)計劃， 發(fā)布母盤，用戶手冊， 測試報告?？偪亟M;項目經理;開發(fā)人員;測試人員;系統(tǒng)發(fā)布總結2002/12/14反饋系統(tǒng)發(fā)布后情況。審查用戶反饋意見， 用戶問題提出表?？偪亟M;項目經理;開發(fā)人員;測試人員;（會議記錄記錄入評審會議記錄）設計驗證驗證包括：需求分析驗證、軟件設計驗證、軟件實現驗證和軟件測試驗證四個部分。（驗證記錄記錄入評審會議記錄表和相關審批表）設計確認通過驗證之后即可確認。（確認結果記錄入評審會議記錄）設計更改所有更改需要經過授權人員確認，并且記錄入設計更改文檔。注意：不能在原

10、有文檔基礎上直接更改。病毒防治在開發(fā)過程中, 要做好病毒防治措施,具體有：開發(fā)環(huán)境不允許進行網絡數據下載；開發(fā)中使用的磁盤媒體要求為未格式化的軟盤， 格式化后由項目經理統(tǒng)一管理使用；采用正版工具；定期進行系統(tǒng)查毒。測試過程質量保證措施測試階段測試包括單元測試、模塊測試、系統(tǒng)測試、壓力測試和UAT測試四個階段。測試規(guī)范測試規(guī)范可以參見軟件測試大綱。測試要求測試過程中應合理運用各種測試方法，通過黑盒測試，驗證模塊接口和功能的實現；通過白盒測試，驗證關鍵算法的實現科學性。測試遵循典型性和覆蓋性原則。質量記錄記錄入測試大綱、測試報告和相應審批表中。其它有關策劃、評審、驗證、確認等部分的內容可以參見 “

11、設計過程質量保證措施”。維護過程質量保證措施維護要求維護過程要在與客戶方達成一致的基礎上，保持對服務的實施、驗證和報告的形成文件的程序。質量記錄在項目過程中形成質量記錄文件包括：DW-ZFZQ-28-03-001質量記錄清單.docDW-ZFZQ-31-01-001工具軟件選用申請表.docDW-ZFZQ-31-02-001工具軟件使用紀錄.doc等。風險控制系統(tǒng)面臨的主要風險和控制策略有：技術風險在技術方案中存在如下的技術問題:系統(tǒng)中對加密和數字簽名技術的使用目前為初次使用, 需要對加密和數字簽名技術在系統(tǒng)實現中的位置和使用方法作更加慎重考慮和方案分析。控制策略：鄭武林負責分析整個網站應用系

12、統(tǒng)中加密、數字簽名的應用分析， 決定實現策略， 并結合公司在安全方面人才對安全策略和實現方法進行重點分析評價。保證安全和加密方案可行、可實現性好。風險指數：*， 該項風險影響系統(tǒng)的可用性。對WLCS中各種元素的配置優(yōu)化。盡管公司有人員參與了Weblogic的培訓， 但是在WLCS上沒有應用經驗， 對WLCS提供的調用接口沒有很好的應用實踐，對可用資源沒有很好的了解,將影響系統(tǒng)開發(fā)的復雜性、高效性和可維護性?？刂撇呗裕河蓜④妭?、劉波、梁倫發(fā)、馬建軍、戰(zhàn)乃國對WLCS的調用接口和元素， 參照技術手冊和技術支持， 進一步分析， 提出商業(yè)邏輯開發(fā)可供依賴的平臺支持接口。風險指數：*， 該項風險影響系統(tǒng)

13、的開發(fā)周期和系統(tǒng)可維護性和高效性。 3）數據庫ORACLE的使用 在開發(fā)梯隊中， 對ORACLE應用缺少具有成熟經驗的數據庫系統(tǒng)設計分析人員， 如何設計高效合理的數據庫對系統(tǒng)效率和系統(tǒng)的可維護性有重要意義。 控制策略：由電子商務部中ORACLE熟悉的人員對系統(tǒng)數據庫的設計進行質疑和咨詢， 特別是從數據效率、數據一致性、數據冗余、數據挖掘和分析等方面。 風險指數：* * ， 該項風險涉及到系統(tǒng)的效率、可維護性、可實現性。JAVA編程技術在開發(fā)梯隊大多數開發(fā)人員的JAVA開發(fā)經驗并不是很長。在開發(fā)隊伍中， 不可避免地存在一些編碼設計繁雜等問題。 控制策略：開發(fā)人員對于復雜和效率相關的代碼，必須進行

14、適當注釋， 便于檢查；在開發(fā)初期， 增加代碼抽查的次數， 便于及時發(fā)現問題。風險指數：* ， 該項風險影響到系統(tǒng)的可靠性、高效性。需求風險需求風險是該項目的最大風險之一。其主要原因是：用戶需求不是很成熟。用戶需求中存在若干不成熟的業(yè)務思想?？刂撇呗裕河脩粜枨筇岢龃硪獓栏褚?。用戶界面復雜， 需求難于一致。所有功能的實現方法和實現形式， 不同的需求主題有不同的要求。例如論壇、聊天室、采編對權限管理的需求?？刂撇呗裕河脩粜枨筇岢鋈藛T經過授權應該確定， 不應變化。業(yè)務關系較復雜， 業(yè)務關系需要跨模塊進行考慮。需求關系在各個系統(tǒng)之間由交叉。業(yè)務需求需要跨系統(tǒng)進行考慮。控制策略：需要在各個系統(tǒng)之外， 安排需求分析人員對系統(tǒng)之間的交叉需求進行分析。 并且， 為了保證需求的準確、全面和系統(tǒng)化， 應該組織多次的會議交流和討論， 及時發(fā)現需求分析中的偏差。 該項風險指數：* 該項風險影響到系統(tǒng)實現工期、項目成本。設計風險設計中存在的風險主要有：由于系統(tǒng)總體方案中結構不合理， 如數據庫分布形式， 各個系統(tǒng)之間的關系。該種風險將影響到系統(tǒng)的可實現性、系統(tǒng)的安全性和可維護性?？刂撇呗裕?對整體方案的總體結構進行深入分析和討論。代碼單元的接口設計和代碼共享控制策略：代碼單元的接口設計明確， 代碼單元功能復雜性適度，在各個系統(tǒng)之間、系統(tǒng)內