1、IT工程實施與管理方案-投標書 1.1 工程實施與管理 1.1.1 工程實施方法論 針對南京銀行企業(yè)效勞總線系統(tǒng)工程，高偉達公司基于對客戶需求、業(yè)務(wù)目標、業(yè)務(wù)能力和IT環(huán)境的理解，結(jié)合多年的軟件開發(fā)和系統(tǒng)實施經(jīng)驗，將工程的實施周期劃分為六個活動階段，保證在工程生命周期內(nèi)，應(yīng)用合理的工程管理和控制技術(shù)。通過專注于使客戶投資回報最大化，和使客戶的投資風(fēng)險最小化的關(guān)鍵戰(zhàn)略和戰(zhàn)術(shù)領(lǐng)域，加快工程實施速度，使得工程成功地完成。這些階段的特性是可循環(huán)往復(fù)性，使客戶可以盡快地獲得新的應(yīng)用系統(tǒng)所帶來的好處。 工程定義階段 在這個階段, 所有與分期實施相關(guān)的工程活動都被明確定義, 工程的"工程利益相關(guān)者

2、"被指定，工程經(jīng)理和客戶工程經(jīng)理的角色和職責被傳達給所有的"工程利益相關(guān)者"。管理工程所需的工程控制結(jié)構(gòu)被定義,所有需要的工程規(guī)劃文件被創(chuàng)立, 客戶的業(yè)務(wù)問題和被用來衡量工程成功的衡量標準被確認。 制定解決方案范圍，在一個高級別上定義哪些模塊將被實施，估算預(yù)期需要的客戶化程度, 以及勾畫出在產(chǎn)品之外需要開發(fā)的內(nèi)容和要提交的技術(shù)成果。解決方案范圍文檔包括解決方案范圍概述, 功能范圍, 流程范圍, 客戶化問題, 其他風(fēng)險, 外部依賴條件以及假設(shè)。這個工作為未來工程決策, 統(tǒng)一或達成"工程利益相關(guān)者"之間就有關(guān)工程參數(shù)的共識，提供書面的文檔。它闡述以

3、SOW為根底的業(yè)務(wù)需求，并且把它轉(zhuǎn)化成產(chǎn)品 模塊實施信息。 簡而言之, 這個階段組建工程團隊，保證客戶實施工程的成功。公司人員與客戶人員一道，組建工程團隊, 設(shè)定工程方法和范圍，并建立工程管理控制。主要交付的成果有，解決方案范圍和工程管理控制。制定了工程質(zhì)量檢查方案。 1.1.1.2 需求分析階段 在需求調(diào)研階段, 在工程管理小組的指導(dǎo)下, 由公司和客戶組成的統(tǒng)一的工程團隊將識別并且書面記錄在開始設(shè)計客戶解決方案之前所必須弄清楚的，需處理的問題。工程團隊書寫、提煉滿足客戶業(yè)務(wù)目標所需的功能和技術(shù)要求。主要交付的技術(shù)成果為業(yè)務(wù)需求和差距分析。 專家效勞參謀將進行一個配臵檢查，以保證系統(tǒng)有精確的規(guī)

4、格，便于購置硬件和架構(gòu)部署。在有技術(shù)客戶經(jīng)理參與的情況下, 通過完成初始的評估, 來建立部署的基準，及通過給戰(zhàn)略，管制，用戶采用, 流程和技術(shù)各方面打分的評估來建立業(yè)務(wù)目標。 1.1.1.3 工程設(shè)計階段 在設(shè)計階段, 主要的目標是設(shè)計一個能夠最正確地滿足客戶明確的業(yè)務(wù)需求的解決方案，并且為培訓(xùn)和系統(tǒng)測試做準備。 在設(shè)計(Design)階段,工程團隊利用應(yīng)用系統(tǒng)屏幕流程和設(shè)計布局來映射在發(fā)現(xiàn)階段確定的需求,設(shè)計解決方案的原型。 主要交付的技術(shù)成果是解決方案設(shè)計文檔和測試策略。這個策略定義測試方案和測試要求，以保證一個系統(tǒng)部署的成功。主要的目的是提供一個高級的測試策略，以便使用自動化的測試工具和

5、/或手工過程來實現(xiàn)功能測試,系統(tǒng)整合測試(SIT),用戶驗收測試 (UAT)和性能測試。 專家效勞參謀要執(zhí)行設(shè)計檢查，來評估由客戶或集成商提供的書面設(shè)計文檔，并且提供詳細的建議清單。設(shè)計標準包括,但不限于，應(yīng)用系統(tǒng)性能,對升級的影響,應(yīng)用系統(tǒng)維護, 與數(shù)據(jù)模型相關(guān)的問題和常規(guī)的最正確做法。 1.1.1.4 工程開發(fā)階段 在開發(fā)階段，工程團隊將開發(fā)應(yīng)用系統(tǒng), 提供任何需要的擴展功能和外部接口, 為客戶部門部署和持續(xù)支持解決方案做準備。工程團隊配臵應(yīng)用系統(tǒng)、所有需要的擴展功能和外部接口。主要交付的技術(shù)成果有功能測試和系統(tǒng)測試。這些流程整合和測試活動更好地保證介入的系統(tǒng)功能與客戶組織的業(yè)務(wù)需求協(xié)調(diào)一

6、 致。 專家效勞參謀應(yīng)該進行一個配臵檢查，來評估所有經(jīng)過客戶化改造的實施文檔。在這個檢查過程中,所有這樣的文件都將被評估，以使應(yīng)用系統(tǒng)性能, 應(yīng)用系統(tǒng)升級,系統(tǒng)維護工作量和常規(guī)最正確實踐最優(yōu)。 1.1.1.5 工程驗證階段 在驗證階段, 將完成新系統(tǒng)全部功能的測試。這個階段分兩個局部。第一局部,工程團隊進行一個對有生產(chǎn)數(shù)據(jù)的應(yīng)用系統(tǒng)的全部功能進行測試。在這個檢測完成后,關(guān)鍵用戶然后進行一個代表性的驗收測試，以保證系統(tǒng)正確地處理用戶的需求。一旦全面的功能測試結(jié)束, 將進行一個使用系統(tǒng)工具的，嚴格的性能測試。這一階段主要交付的技術(shù)成果為用戶驗收測試和性能測試結(jié)果, 包括性能,容量和壽命測試。 適時

7、的性能調(diào)整審計，可保證整個企業(yè)架構(gòu)環(huán)境的性能最正確。在這個檢查中, 專家效勞將主動性地識別任何性能問題, 這樣將減少在運行時出現(xiàn)問題的風(fēng)險，增加系統(tǒng)生產(chǎn)切換的信心。在有技術(shù)客戶經(jīng)理參與的情況下, 可執(zhí)行一個實施準備就緒檢查，以確認系統(tǒng)是否可以部署了。這個實施準備就緒檢查是用來評估實施風(fēng)險,技術(shù)上是否準備停當以及部署策略。 此時，應(yīng)該召開管理人員定向協(xié)調(diào)研討會，將責任轉(zhuǎn)移給一線的員工，這些員工將開始支持業(yè)務(wù)流程和技術(shù)的推出。在管理人員定向協(xié)調(diào)研討會上, 工程團隊與客戶的管理團隊一起工作，以獲得維持資助人的內(nèi)部負責，并把正確的信號傳達給組織的其他成員。 1.1.1.6 部署上線階段 部署上線階段內(nèi)

8、的第一個活動是實施一個投產(chǎn)導(dǎo)航。這個導(dǎo)航是被用來測試全面的生產(chǎn)部署, 并且在客戶業(yè)務(wù)環(huán)境中的一局部部門中進行的，例如一個地區(qū)或一個區(qū)域。生產(chǎn)導(dǎo)航在機構(gòu)的業(yè)務(wù)環(huán)境中局部部門里，為用戶提供所有系統(tǒng)的特點。來自于生產(chǎn)導(dǎo)航的反響信息指導(dǎo)整個的部署。 同樣在這個過程中, 專家效勞參謀應(yīng)該進行生產(chǎn)準備就緒檢查, 通過主動地識別任何可能造成部署中斷和使實施的系統(tǒng)解決方案的技術(shù)優(yōu)點打折扣的所 有問題，來協(xié)助系統(tǒng)的順利推出。 此時, 要召開流程實施研討會，部署流程最優(yōu)實踐，來優(yōu)化人, 流程和技術(shù)的配合。目的是在客戶所有的一線機構(gòu)中，使用變革和銷售流程的最正確實踐，使最初的贊助人和行政領(lǐng)導(dǎo)團隊完全滿意。 1.1.

9、2 工程管理方案 1.1.2.1 工程管理概述 工程管理包括在工程生命周期中協(xié)調(diào)所有工程管理知識領(lǐng)域所涉及的過程。它確保工程所有的組成要素在正確的時間結(jié)合在一起，以成功的完成工程。進行工程整體管理時，必定涉及工程的范圍、質(zhì)量、時間和本錢管理以及人力資源、溝通、風(fēng)險管理等各個環(huán)節(jié)，工程管理一個復(fù)雜的工程，在此主要針對南京銀行企業(yè)效勞總線工程的工程進度管理、變更管理、溝通管理、質(zhì)量管理、風(fēng)險管理等相關(guān)策略進行描述。 1.1.2.2 工程進度管理 通過工程進度的管理最終明確工程開發(fā)階段的進度控制活動和關(guān)鍵流程。 ? 工程經(jīng)理： ? 根據(jù)軟件開發(fā)方案編制詳細的階段開發(fā)方案以及每項任務(wù)的邊界時 間，并召

10、集過程控制人員、專題小組負責人審核該方案； ? 審核各專題小組擬訂的每項任務(wù)的日程安排； ? 檢查和控制工程進度； ? 制定進度變更方案； ? 過程控制人員： ? 協(xié)助審核詳細的階段開發(fā)方案和任務(wù)邊界時間； ? 監(jiān)督工程進展； ? 專題小組負責人： ? 協(xié)助審核詳細的階段開發(fā)方案和任務(wù)邊界時間； ? 在聽取小組成員意見的根底上，擬訂每一項任務(wù)的日程安排； ? 負責檢查和控制任務(wù)的進度，并填寫進度控制表； ? 負責制訂任務(wù)變更方案。 1.1.2.2.1. 進度安排流程 ? 工程經(jīng)理根據(jù)工程方案，明確該階段的邊界時間； ? 根據(jù)工程方案中的任務(wù)PERT網(wǎng)絡(luò)圖，找出該階段的關(guān)鍵任務(wù)并進一步分 解、細

11、化，在此根底上繪制更具體的階段任務(wù)PERT網(wǎng)絡(luò)圖； ? 擬訂詳細的階段方案； ? 確定每一關(guān)鍵任務(wù)的邊界時間； ? 召集各專題小組負責人審核擬訂的方案，并修改； ? 專題小組負責人確定任務(wù)的日程安排；對于大型的或時間要求嚴格的項 目，進度安排應(yīng)以天為單位； ? 征求小組成員的意見； ? 交由工程經(jīng)理和過程管理人員審核。 1.1.2.2.2. 進度控制流程 ? 工程經(jīng)理和過程管理人員按照階段PERT圖，標志階段中被跟蹤的關(guān)鍵任 務(wù)和里程碑，并將之告知專題小組負責人； ? 專題小組負責人按照任務(wù)的日程安排，確定任務(wù)完成期間的關(guān)鍵時間點， 并將之告知專題小組成員； ? 專題小組負責人經(jīng)常與成員溝通，

12、了解任務(wù)進展；并定期檢查，填寫任 務(wù)進度表和下期方案表，及時發(fā)現(xiàn)問題； ? 工程經(jīng)理定期組織專題小組負責人，召開工程狀態(tài)會議，了解任務(wù)進展， 及時發(fā)現(xiàn)問題；工程過程管理人員參加會議或了解會議的記錄； ? 專題小組負責人在執(zhí)行中發(fā)現(xiàn)延遲，分析原因： ? 人員緊張：組內(nèi)調(diào)配不了的，找工程經(jīng)理解決； ? 事先預(yù)估缺乏：調(diào)整任務(wù)日程安排；假設(shè)解決不了，告知工程經(jīng)理， 會同過程管理人員，調(diào)整詳細的階段方案；如果階段內(nèi)消化不了的 問題，那么工程經(jīng)理按照?配臵管理的程序?，變更軟件開發(fā)方案。 1.1.2.3 工程變更管理 針對工程變更管理組織變更控制小組，由工程組經(jīng)理、工程管理部人員、工程總監(jiān)、客戶、客戶部

13、成員組成，考慮并授權(quán)工程的重大修改修改工作量超過一周的。而工程經(jīng)理負責工程的一般修改決策修改工作量在一天以上，一周以內(nèi)。 變更管理活動包括修改請求、評估、通過、執(zhí)行和跟蹤。 變更管理要點如下： ? 變更批準權(quán)限： ? 變更控制組負責討論和決策工程的重大修改； ? 工程經(jīng)理討論和決策一般性修改；并報工程管理部備案； ? 修改審批程序： ? 根據(jù)不同地點的客戶有不同的審批程序。 1.1.2.3.1. 變更狀態(tài)登記 變更狀態(tài)登記活動記錄和報告各種配臵項的狀態(tài)，記錄在工程生命周期中的任何管理信息和歷史信息。包括：所有變更請求表、所有變更報告單、所有變更記錄。由工程管理人員存取狀態(tài)登記。 變更狀態(tài)登記的

14、目的是為了控制軟件需求發(fā)生變更時的處理過程，使之按照制定的規(guī)程進行，以保證軟件需求的一致性。 1.1.2.3.2. 變更管理流程 ? 客戶方或高偉達提出變更請求，填寫變更申請表； ? 將變更申請表交本工程組的工程經(jīng)理； ? 雙方工程經(jīng)理或工程經(jīng)理授權(quán)人，必須以書面形式確認共同審閱， 評估該需求變更的技術(shù)有效性和對本工程的影響； ? 如果審閱批準該請求，那么雙方工程經(jīng)理或工程經(jīng)理授權(quán)人，必須以書 面形式確認簽字確認，變更申請表將被貴行文檔管理員登記后，轉(zhuǎn)發(fā)給高偉達。如果未獲批準，其原因?qū)⒎错懡o該需求變更發(fā)起人； ? 高偉達在收到經(jīng)審閱批準的需求變更申請后的三個工作日內(nèi)，發(fā)給貴行 一份書面確認書，

15、確認其收到，并給出分析與執(zhí)行變更所需時間和工作量的估算； ? 根據(jù)請求的變更程度和復(fù)雜度，高偉達進一步進行本錢評估，假設(shè)不需成 本，那么直接執(zhí)行變更工作；假設(shè)需要增加本錢，那么以書面形式通知貴行文檔管理員，貴行管理員登記后，按照工程管理方法中的工程變更管理流程處理。 1.1.2.4 工程溝通管理 南京銀行ESB工程是一個技術(shù)與業(yè)務(wù)互動的工程，工程的成功很大程度上依賴于業(yè)務(wù)人員的參與程度及技術(shù)人員對業(yè)務(wù)需求的透徹分析，這就要求技術(shù)與業(yè)務(wù)人員保證充分的交流，制定并遵守工程內(nèi)部的溝通管理方案。 1.1.2.4.1. 工程溝通形式 根據(jù)本工程的組織形式及特點，我們建議采取如下多種方式的溝通形式： 1.

16、1.2.4.2. 會議管理制度 工程開始進行以后，要有效地控制工程，需要在各個關(guān)鍵時刻召開關(guān)鍵會議。 關(guān)鍵會議的主要內(nèi)容是總結(jié)上一階段的工作，分析問題、提出建議，并介紹下一 階段的主要任務(wù)和目標，使各有關(guān)人員都能做到心中有數(shù)，明確努力的方向。關(guān) 鍵會議也是協(xié)調(diào)各不同小組之間的人員以及工作任務(wù)的重要手段。 除關(guān)鍵會議外，在工程進行的全過程中，應(yīng)定期召開例會，會上主要介紹項 目進展情況，檢查進度、是否存在問題等，會議時須做詳細的會議記錄并在會后 報送所有工程相關(guān)人員。主要的工程會議流程規(guī)定如下： ? 會前準備： ? 做好準備工作，如明確會議目的和會議議程等； ? 把會議中要求討論的材料事先下發(fā)給開

17、會成員； ? 提前兩天通知各位與會成員； ? 準備會議環(huán)境、會議用設(shè)備等； ? 會議之中： ? 會議成員準時到會； ? 按會議議程逐項進行； ? 嚴格控制會議時間； ? 會后跟蹤： ? 會議決議落實和檢查。 1.1.2.5 工程質(zhì)量管理 為保證工程順利實施及系統(tǒng)質(zhì)量，必須在工程管理過程和工程實施過程上加大質(zhì)量管理力度。通過高偉達公司實施的成功案例，我們深深體會到“質(zhì)量是方案出來的這一現(xiàn)代質(zhì)量學(xué)觀點所蘊含的深刻道理，所以，我們在工程啟動及工程進展的各個階段都會仔細制定各項工作方案，嚴格按照審核通過的方案進行工程控制。 針對本工程，我們建議從QA及QC兩方面保障工程的順利實施，具體的質(zhì)量保障措施如

18、下： 1.1.2.5.1. 質(zhì)量保證 本工程將設(shè)臵質(zhì)量保證小組，由南京銀行和高偉達公司各出一名人員擔任QA的角色，其工作任務(wù)是根據(jù)工程總體組制定的質(zhì)量核對單，在工程進展過程按照質(zhì)量核對單逐項審核工程是否按照方案約定執(zhí)行和控制，并直接向南京銀行的相關(guān)領(lǐng)導(dǎo)匯報工程實施的質(zhì)量狀況。 1.1.2.5.2. 正式評審 根據(jù)本工程的特點，本工程中將對工程方案、軟件需求規(guī)格說明書、系統(tǒng)設(shè)計說明書、測試規(guī)格說明書、測試報告等文檔，組織南京銀行相關(guān)領(lǐng)導(dǎo)、專家進行正式評審，以便審核系統(tǒng)開發(fā)中各階段所產(chǎn)生的過程文檔，以保證文檔內(nèi)容與上一階段所產(chǎn)生的軟件文檔內(nèi)容一致，并且符合使用者的需求。 1.1.2.5.3. 交叉

19、審查 除工程要求的正式評審內(nèi)容外，本工程還將對各模塊軟件代碼實行交叉評審制度。各模塊負責人應(yīng)根據(jù)總體組制定的代碼質(zhì)量審核清單，對所負責檢查的其他模塊軟件代碼進行仔細審查，對代碼質(zhì)量不能通過交叉評審的那么必須進行返工。整體的軟件代碼交叉評審總量不能少于60。 1.1.2.5.4. 變更控制 為保證軟件產(chǎn)品質(zhì)量，開發(fā)過程將嚴格采用配臵管理工具進行變更控制，其目的是保證最終軟件產(chǎn)品能夠符合業(yè)務(wù)需求的各項要求，并對開發(fā)過程進行監(jiān)控、報告和提供咨詢支持，它包括下面的質(zhì)量屬性要求： ? 軟件產(chǎn)品與需求、說明書和設(shè)計一致； ? 按照說明的標準建立文檔； ? 可測試和可維護； ? 被識別、管理、評審和測試；

20、? 當變更發(fā)生時可管理。 1.1.2.6 工程風(fēng)險管理 任何工程開發(fā)實施過程中都會遇到各種風(fēng)險，在各方面都會遇到不同規(guī)模的風(fēng)險，因此需要了解工程本身的風(fēng)險、技術(shù) 風(fēng)險、新產(chǎn)品的風(fēng)險、工程資源風(fēng)險、工程過程風(fēng)險等全方位的風(fēng)險因素。通過對風(fēng)險的量化提供一個方案來管理預(yù)防風(fēng)險，同時對于潛在的風(fēng)險也應(yīng)該建立意外事件的應(yīng)急方案，使其在必要時能夠以可控的及有效的方式作出反響。 ? 針對需求風(fēng)險，南京銀行應(yīng)把握系統(tǒng)建設(shè)起點要高、標準運作為系統(tǒng)建設(shè)的 根底工程、采用構(gòu)件化技術(shù)進行應(yīng)喲軟件開發(fā)、采用B/S技術(shù)降低信息點維護本錢的方式躲避需求風(fēng)險。 ? 針對合作風(fēng)險，選擇一個長久的、上規(guī)模、具備成熟行業(yè)經(jīng)驗、工程

21、管理規(guī) 范、技術(shù)先進、員工有歸屬感、真正站在用戶的立場上考慮問題的公司作為后盾，高偉達集團是能為您最大限度地控制合作風(fēng)險。 ? 針對資源風(fēng)險，擁有健全的組織與管理，在防止人員流動的根底上，即使因 個人原因必須離職時，高偉達公司也因其標準的、體系化的管理與產(chǎn)品架構(gòu)而使工程根本不受影響或極少受到影響。 ? 針對技術(shù)風(fēng)險，高偉達的銀行業(yè)務(wù)系統(tǒng)擁有多個成功實踐經(jīng)驗，具備與國外 接軌的理念與技術(shù)，同時擁有不斷調(diào)整、更新的技術(shù)體系、以及參照標準體系指定標準質(zhì)量標準并在實施過程中加強階段評審，使因為技術(shù)原因而可能 導(dǎo)致的風(fēng)險降低到最小。 除此之外，為預(yù)防操作風(fēng)險，在南京銀行自身加強制度管理的根底上，高偉達還

22、提供培訓(xùn)考試合格上崗及定期培訓(xùn)定期總結(jié)分析的模式來躲避此類風(fēng)險。 1.1.2.6.1. 風(fēng)險管理內(nèi)容 風(fēng)險管理的內(nèi)容如下： ? 工程實施前和實施中對風(fēng)險的發(fā)現(xiàn)、識別、上報、分析及風(fēng)險責任人的 指定； ? 風(fēng)險應(yīng)對方案的制訂和執(zhí)行應(yīng)對方案包括兩局部，一是在如何降低風(fēng) 險發(fā)生機率的躲避方案；一是當風(fēng)險不幸變成現(xiàn)實時，如何應(yīng)對的應(yīng)急預(yù)案； ? 風(fēng)險狀態(tài)的監(jiān)控和更新； ? 定期對工程風(fēng)險進行統(tǒng)計、分類和總體結(jié)構(gòu)分析。 1.1.2.6.2. 風(fēng)險管理中的相關(guān)角色和責任 1.1.2.6.3. 風(fēng)險嚴重程度 ? 災(zāi)難的：會因為無法滿足需求而導(dǎo)致任務(wù)失敗，會產(chǎn)生錯誤導(dǎo)致進度延 遲和預(yù)算嚴重超支； ? 嚴重的：

23、會因為無法滿足需求而導(dǎo)致系統(tǒng)性能下降，使得工程能否成功 受到臵疑，嚴重影響工程里程碑的范圍、交付日期和交付質(zhì)量以及會影響其它工程進展的風(fēng)險； ? 輕微的：會因為無法滿足要求而導(dǎo)致次要任務(wù)的退化，影響工程里程碑 的范圍、交付日期和交付質(zhì)量以及會影響其它工程進展的但不嚴重的風(fēng)險； ? 可忽略的：不影響或輕微影響工程里程碑的范圍、交付日期和交付質(zhì)量 的風(fēng)險，只是無法滿足要求而導(dǎo)致使用不方便或不易操作。 1.1.2.6.4. 風(fēng)險狀態(tài) ? 已提交：風(fēng)險識別人已填寫風(fēng)險登記表，完成了風(fēng)險號分配、風(fēng)險描述 并有工程經(jīng)理提交； ? 拒絕：工程管理辦公室認為風(fēng)險導(dǎo)入人所提出的風(fēng)險不屬于工程風(fēng)險； ? 已完成方

24、案：風(fēng)險責任人得到風(fēng)險登記表后，對其進行分析并完成應(yīng)對 方案； ? 躲避方案：風(fēng)險責任人正在根據(jù)應(yīng)對方案躲避風(fēng)險； ? 風(fēng)險已躲避：風(fēng)險責任人已成功躲避風(fēng)險并得到工程管理辦公室認可； ? 發(fā)生進入應(yīng)急方案：風(fēng)險責任人未成功躲避風(fēng)險，風(fēng)險發(fā)生，執(zhí)行應(yīng)急 預(yù)案。 1.1.2.6.5. 風(fēng)險分類 本工程中，風(fēng)險主要分為以下幾類： ? 管理類風(fēng)險 工程管理沒有遵循工程管理的制度、時間、崗位的要求。出現(xiàn)工程的風(fēng)險。 ? 資源類風(fēng)險 由于人力資源、設(shè)備環(huán)境等原因產(chǎn)生。例如，ATM設(shè)備沒有驅(qū)動程序，無法進行程序調(diào)試。 ? 業(yè)務(wù)類風(fēng)險 業(yè)務(wù)風(fēng)險主要表現(xiàn)在業(yè)務(wù)需求不清晰，變動頻繁。 ? 技術(shù)類風(fēng)險 技術(shù)風(fēng)險主要

25、表達在技術(shù)架構(gòu)不合理，各個子系統(tǒng)、效勞渠道無法進行整合。 1.1.2.6.6. 風(fēng)險管理流程 風(fēng)險管理流程包括： ? 工程啟動前風(fēng)險識別與防范流程 在各工程啟動前，應(yīng)當由工程管理辦公室指導(dǎo)各個工程提交其工程風(fēng)險因素識別、評估和應(yīng)對措施方案； 工程管理辦公室根據(jù)各工程的風(fēng)險識別方案，以及其對工程風(fēng)險的理解，完成工程風(fēng)險因素識別、評估和躲避的工程風(fēng)險躲避方案以及制訂工程風(fēng)險應(yīng)急預(yù)案； 工程管理辦公室將有關(guān)風(fēng)險應(yīng)對方案上報工程總監(jiān)審批； 將工程總監(jiān)審批過的風(fēng)險應(yīng)對方案提交給領(lǐng)導(dǎo)領(lǐng)導(dǎo)組審批； 審批通過的風(fēng)險應(yīng)對方案由工程管理辦公室公布歸檔； 在工程實施過程中由工程經(jīng)理管理風(fēng)險應(yīng)對方案的執(zhí)行，工程管理辦

26、公室通過工程周、月報跟蹤監(jiān)督。 如以下圖示： ? 工程運行中風(fēng)險管理流程 在工程實施過程中，所有工程組成員均有責任報告進程中發(fā)現(xiàn)的風(fēng)險因素，并報告工程經(jīng)理； 工程經(jīng)理在確定其確為風(fēng)險后，定義風(fēng)險發(fā)生機率和嚴重度并指定風(fēng)險責任人，制訂風(fēng)險一旦發(fā)生的應(yīng)急預(yù)案，并將其填寫風(fēng)險登記表上報工程管理辦公室； 工程管理辦公室審核風(fēng)險發(fā)生機率、嚴重度和風(fēng)險責任人并負責風(fēng)險狀態(tài)的監(jiān)控； 風(fēng)險責任人負責編制風(fēng)險應(yīng)對方案，并定期報告風(fēng)險狀態(tài)； 工程管理辦公室負責發(fā)現(xiàn)跨工程的風(fēng)險因素，并主持評估躲避方案和應(yīng)急預(yù)案； 工程管理辦公室將有關(guān)風(fēng)險評估報告和躲避方案、應(yīng)急預(yù)案上報工程總監(jiān)審批； 所有發(fā)現(xiàn)的風(fēng)險因素和審批通過的

27、相應(yīng)風(fēng)險應(yīng)對方案由工程管理辦公室公布歸檔； 在工程實施過程中由工程經(jīng)理管理風(fēng)險應(yīng)對方案的執(zhí)行，工程管理辦公室通過工程周、月報跟蹤監(jiān)督。 如以下圖示： 1.1.3 工程實施方案 1.1.3.1.1. 工程組織架構(gòu) 有效的組織結(jié)構(gòu)，是工程成功的有力保證。對于一個銀行效勞總線工程，除了考慮工程的有效管理，也要考慮SOA類工程的實施特點；根據(jù)本次工程 的范圍和要求，工程的參考組織結(jié)構(gòu)如下 1.1.3.1.1.1 工程管理委員會 工程管理委員會負責監(jiān)督并指導(dǎo)工程的實施進程，定期審核工程經(jīng)理就工程進展執(zhí)行情況的書面報告，對工程中存在的重大問題做出決策，協(xié)調(diào)解決重大問題和突發(fā)事件，決定對工程經(jīng)理的任免。工程

28、管理委員會由南京銀行高層領(lǐng)導(dǎo)與本公司高層領(lǐng)導(dǎo)共同組成。 1.1.3.1.1.2 效勞總線管理組 向工程管理委員會負責，在工程實施過程中進行效勞標準和原那么的控制，在未來工程實施完畢后，由這個組織管理和批準新的效勞發(fā)布和渠道系統(tǒng)的接入。同時負責制定企業(yè)實施SOA工程的總體規(guī)劃，從企業(yè)級的高度而非工程級參與工程管理。效勞總線管理組由南京銀行架構(gòu)師和本公司企業(yè)架構(gòu)師共同組成。工程實施完成后職責交給客戶執(zhí)行。 1.1.3.1.1.3 工程管理組 負責向工程管理委員會定期報告工程進展情況，就工程中存在的問題提出解決建議，對工程進行有方案地組織管理，并檢查工程進展情況。工程管理組由南京銀行工程負責人和本公

29、司工程經(jīng)理和技術(shù)負責人共同組成。 1.1.3.1.1.4 根底架構(gòu)組 負責根底架構(gòu)的設(shè)計和流程建模設(shè)計。和企業(yè)架構(gòu)師共同設(shè)計整體根底架構(gòu)，完本錢工程范圍內(nèi)的規(guī)劃，考慮本工程與整個企業(yè)范圍的IT架構(gòu)的一致性規(guī)劃。 1.1.3.1.1.5 質(zhì)量管理組 直接隸屬工程管理委員會，按制定的標準及控制手段執(zhí)行進度管理，風(fēng)險管理，全面的執(zhí)行各項局方及業(yè)內(nèi)規(guī)定的質(zhì)量標準和工作流程。 1.1.3.1.1.6 效勞定義發(fā)布組 負責在總線上發(fā)布效勞和設(shè)定效勞標準。根據(jù)根底架構(gòu)規(guī)劃中的效勞架構(gòu)，對效勞進行歸類，根據(jù)效勞定義模板，完成效勞的識別、設(shè)定和在效勞總線上的發(fā)布和配臵。 1.1.3.1.1.7 根底組件開發(fā)組

30、負責根底的，公共的組件的統(tǒng)一開發(fā)；開發(fā)從日志，平安到各種便利工具的公共組件，完成在OSB之上的各種組件的擴展工作，如擴展函數(shù)，擴展報文轉(zhuǎn)換方法，擴展監(jiān)控處理模塊，進行監(jiān)控平臺的集成等。 1.1.3.1.1.8 測試組 負責系統(tǒng)的聯(lián)合測試工作，在工程質(zhì)量方針指導(dǎo)下，進行測試管理，制定設(shè)計系統(tǒng)測試方案、測試方案、測試案例、各項測試、形成測試報告并對測試結(jié)果進行跟蹤，包括不同階段的測試工作。 1.1.3.1.2. 實施人員名單 1.1.3.1.3. 實施人員簡歷 1.1.3.1.4. 工程實施階段劃分 根據(jù)我公司執(zhí)行的ISO9001:2000質(zhì)量管理體系的規(guī)定，將整個工程的實施過程劃分為：需求分析、

31、詳細設(shè)計、系統(tǒng)開發(fā)、系統(tǒng)測試、試運行、系統(tǒng)驗收六個過程；工程監(jiān)控、管理的過程分為：配臵管理、內(nèi)部監(jiān)理和工程變更管理三個過程。下面將針對以上六個實施過程和三個管理過程的實施方案即工程方案進行 介紹。 1.1.3.1.4.1 第一階段：需求分析階段 自合同簽定之日，與工程籌備小組并行完成業(yè)務(wù)需求分析，建立完善的工程組織機構(gòu)，雙方密切協(xié)作，各工程小組密切協(xié)作，各項工作同時有條不紊地展開。 ? 完成并提交工程方案書，產(chǎn)品管理方案，質(zhì)量控制方案； ? 詳細的需求分析。需求分析的方案和方法主要包括調(diào)研階段劃分、日程 安排、調(diào)研形式和內(nèi)容、調(diào)研過程和成果文檔模板、資源安排、用戶方 要求等內(nèi)容； ? 公司方與

32、用戶方進行應(yīng)用軟件需求的討論、研究和分析，并一起根據(jù)需 求調(diào)研分析報告和調(diào)研的各種成果編寫?軟件需求規(guī)格說明書?，對應(yīng)用 系統(tǒng)提出完整、準確、清晰、具體的要求，主要是需求框架和根本要素， 并進行正式評審； 時間跨度：6周 需要資源專職：行方科技部2名、高偉達公司工程組需求分析人員3人。 1.1.3.1.4.2 第二階段：系統(tǒng)設(shè)計階段 ? 根據(jù)?軟件需求規(guī)格說明書?，進行應(yīng)用軟件概要設(shè)計，設(shè)計系統(tǒng)整體結(jié) 構(gòu)、主要流程、相關(guān)模塊接口以及數(shù)據(jù)庫設(shè)計，定義詳細設(shè)計和編碼規(guī) 范，整理?概要設(shè)計說明書?； ? 根據(jù)?軟件需求規(guī)格說明書?和?概要設(shè)計說明書?，由開發(fā)小組組長負 責組織進行詳細設(shè)計的分析討論，

33、完成交易的流程設(shè)計和報表設(shè)計等， 整理?詳細設(shè)計說明書?； ? 編寫系統(tǒng)結(jié)構(gòu)設(shè)計、功能設(shè)計、數(shù)據(jù)庫結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計、系統(tǒng)內(nèi)外接 口及界面設(shè)計、系統(tǒng)出錯處理及平安保障設(shè)計、代碼數(shù)據(jù)設(shè)計、聯(lián)機交 易流程以及批處理交易流程等設(shè)計文檔； ? 啟動數(shù)據(jù)轉(zhuǎn)換工作，定義統(tǒng)一的中間格式。 時間跨度：6周 需要資源專職：行方科技部2名、高偉達公司現(xiàn)場8名技術(shù)、業(yè)務(wù)骨干，產(chǎn)品咨詢1名。 1.1.3.1.4.3 第三階段：系統(tǒng)開發(fā)階段 與系統(tǒng)設(shè)計階段對應(yīng)，是系統(tǒng)開發(fā)階段，企業(yè)效勞總線建設(shè)是基于ORACLE成熟總線產(chǎn)品OSB，因此在進行了周密嚴格的需求分析及詳細設(shè)計的前提下，真正需要的開發(fā)工作并不多，周期相應(yīng)較短。

34、? 在系統(tǒng)設(shè)計完成后，由公司工程實施團隊開發(fā)人員根據(jù)各種設(shè)計文檔進 行應(yīng)用軟件的編碼工作； ? 系統(tǒng)開發(fā)工作完成及培訓(xùn)準備工作完成后，即開始進入全面培訓(xùn)階段； ? 系統(tǒng)開發(fā)工作完成后，進行應(yīng)用軟件單元測試和系統(tǒng)集成測試； 時間跨度：2周 需要資源：行方科技部1名、高偉達公司現(xiàn)場設(shè)計開發(fā)人員、測試人員10名。 1.1.3.1.4.4 第四階段：系統(tǒng)測試階段 系統(tǒng)開發(fā)完成后進行系統(tǒng)的測試工作。本階段主要指在南京銀行建立的測試環(huán)境中，進行全面的模擬測試，完成系統(tǒng)功能測試，由于測試的重要性，預(yù)計將花費兩個月左右的時間來完成對系統(tǒng)的模擬測試。 ? 測試對象是編程結(jié)束時提交內(nèi)容； ? 制定測試方案和選定測

35、試方法、準備測試數(shù)據(jù)、確認測試環(huán)境應(yīng)該是 硬件系統(tǒng)通過初步驗收后所構(gòu)成的標準模式運行環(huán)境； ? 進行測試記錄； ? 解決測試發(fā)現(xiàn)的問題，分析測試結(jié)果，形成測試報告； ? 為測試后確實認和初步驗收做好準備。 ? 驗收測試：在系統(tǒng)試運行一段時間后，由驗收小組組織進行全面系統(tǒng)驗 收測試，以證明系統(tǒng)的合格性。系統(tǒng)的驗收工作，系統(tǒng)驗收詳見?驗收和測試?相關(guān)章節(jié)。 時間跨度：8周 需要資源：行方科技部3名、接入系統(tǒng)相關(guān)人員1名、高偉達公司現(xiàn)場8名技術(shù)、業(yè)務(wù)骨干。 1.1.3.1.4.5 第五階段：試運行階段 模擬測試完成，進入系統(tǒng)試運行階段。考慮到試運行期間的目的，是將經(jīng)過集成測試及性能測試后較為穩(wěn)定的版

36、本投入到實際工作環(huán)境中運行，用于檢驗系統(tǒng)是否完全滿足實際業(yè)務(wù)的需要，為新系統(tǒng)的上線運行做準備。 ? 系統(tǒng)上機聯(lián)調(diào)； ? 試運行期間，核查新系統(tǒng)是否滿足實際業(yè)務(wù)需求； ? 試運行期間發(fā)現(xiàn)的問題，進行記錄、調(diào)整、解決； ? 試運行期間還是測試的良好時機，在該階段，應(yīng)對各網(wǎng)點的設(shè)備、網(wǎng)絡(luò) 狀況、業(yè)務(wù)響應(yīng)時間等內(nèi)容進行測試。 時間跨度：4周 需要資源：行方科技部1名、接入系統(tǒng)相關(guān)人員1名、高偉達公司現(xiàn)場4名技術(shù)、業(yè)務(wù)骨干。 1.1.3.1.4.6 第六階段：上線驗收及維護階段 上線驗收階段的主要工作是制定詳細的上線方案，確認上線步驟。選擇適宜日期開始上線實施工作，做好外連系統(tǒng)和外圍系統(tǒng)的預(yù)前通知和公告

37、工作。 時間跨度：24周 需要資源：行方相關(guān)人員2名、高偉達公司現(xiàn)場2名技術(shù)、業(yè)務(wù)骨干。 1.1.3.1.4.7 并行管理階段一：配臵管理工作 配臵管理工作的內(nèi)容主要是對配臵項的控制。配臵項主要包括：技術(shù)文檔技術(shù)文檔分文字類和表格類兩種、工程實施階段狀態(tài)表。配臵工作包括：文檔一致性控制、文檔標識控制、工程實施階段控制、工程實施更改控制。 時間跨度：26周 需要資源：科技部1名、高偉達公司現(xiàn)場1名配臵管理人員。 1.1.3.1.4.8 并行管理階段二：內(nèi)部監(jiān)理工作 對工程實施的進程、本錢、工期、進行監(jiān)控的過程。 時間跨度：26周 需要資源：行方科技部1名、高偉達公司現(xiàn)場1名QA人員。 1.1.3

38、.1.4.9 并行管理階段三：工程變更工作 涵蓋軟件實施工程實施過程中顧客需求變更及階段性成果變更的處理。包括需求分析、詳細設(shè)計、系統(tǒng)開發(fā)、系統(tǒng)測試、系統(tǒng)維護、系統(tǒng)交付、系統(tǒng)驗收各階段的變更以及涉及工程管理的變更。 1.1.3.1.5. 工程實施周期方案 整個工程實施周期方案如下： 1.1.4 工程測試方案 1.1.4.1 測試目的 對系統(tǒng)進行集成測試。對測試范圍內(nèi)需要測試的特性進行“完整性、“準確性、“有效性、“可靠性、“穩(wěn)定性驗證并對性能指標進行測評。 通過本次測試，到達以下具體目的： 1) 保證軟件根本功能使用正常，嚴重缺陷率小于5%； 2) 保證系統(tǒng)可靠穩(wěn)定運行； 3) 保證工程相關(guān)文

39、檔符合CMMI 3級文檔標準。 1.1.4.2 測試對象 1. 系統(tǒng)具有總線根本功能如：協(xié)議轉(zhuǎn)換、交易路由、數(shù)據(jù)轉(zhuǎn)換； 2. 效勞封裝標準滿足行內(nèi)存量、增量業(yè)務(wù)系統(tǒng)； 3. 對各類系統(tǒng)提供的適配器功能滿足性； 4. 系統(tǒng)并發(fā)處理能力及響應(yīng)時間滿足要求； 5. 系統(tǒng)可靠性、穩(wěn)定性。 1.1.4.3 測試范圍 測試范圍最終以實際形成的?系統(tǒng)業(yè)務(wù)需求說明書?的內(nèi)容為準。 1.1.4.4 測試方法 1.1.4.4.1. 功能測試 配合開發(fā)組的開發(fā)過程分階段提供測試小結(jié),測試方法以標準黑盒技術(shù)為主。 本次測試過程中，功能測試的執(zhí)行環(huán)節(jié)分為兩個階段，具體描述如下： 1.1.4.4.2. 性能測試 分為負載

40、測試、壓力測試、穩(wěn)定性測試等三個階段。使用LoadRunner進行測試。根據(jù)性能測試調(diào)研得到的數(shù)據(jù)構(gòu)建業(yè)務(wù)模型，進而構(gòu)建測試模型。測試模型包含多種子類型，不同類型的測試模型應(yīng)用于不同類型的性能測試。 性能測試模型包含要素如下： 本次測試包含的性能測試類型如下： 1) 壓力測試 基于本次的測試的目的和需要測試的特性，將本次測試分為兩個階段：階段一，單業(yè)務(wù)壓力測試；階段二，多業(yè)務(wù)混合壓力測試。 a) 單業(yè)務(wù)壓力測試 測試目的： 排查各個典型業(yè)務(wù)的壓力瓶頸。 選用測試模型 單業(yè)務(wù)壓力測試模型。 b) 混合業(yè)務(wù)壓力測試 測試目的： 在排查各個典型業(yè)務(wù)的性能瓶頸后，測試該系統(tǒng)的最大并發(fā)用戶數(shù)， 并找到系

41、統(tǒng)存在的性能瓶頸。 選用測試模型： 混合業(yè)務(wù)壓力測試模型。 2) 穩(wěn)定性測試 測試目的： 檢查系統(tǒng)在連續(xù)運行240小時過程中的性能表現(xiàn) 選用測試模型： 穩(wěn)定性測試模型。 1.1.4.4.3. 文檔測試 對需求說明書、設(shè)計文檔進行標準性檢查。 1.1.4.5 測試用例 本次測試中將主要的測試用例歸類為不同的測試場景，同時設(shè)計易用性測試用例和接收測試用例。 1.1.4.5.1. 根本測試場景 描述系統(tǒng)正常操作流程，以通過操作完整實現(xiàn)一個業(yè)務(wù)功能為原那么。其中每一個步驟對應(yīng)一個測試用例。測試用例中采取的數(shù)據(jù)都為正常數(shù)據(jù)。 1.1.4.5.2. 異常測試場景 基于系統(tǒng)正常操作流程，在整實現(xiàn)一個業(yè)務(wù)功能

42、的操作過程中驗證系統(tǒng)的數(shù)據(jù)校驗、特殊操作處理等功能。其中每一個步驟對應(yīng)一個測試用例。測試用例中采取的數(shù)據(jù)有正常數(shù)據(jù)和異常數(shù)據(jù)。 1.1.4.5.3. 接收測試用例 由“根本測試場景中選取出代表性用例，用于驗證開發(fā)團隊提交測試版本的可測性。 1.1.4.6 人員及職責 1.1.4.7 測試工作輸出 1.1.4.8 啟動、暫停/重啟、結(jié)束準那么 1.1.4.8.1. 啟動準那么 待測試系統(tǒng)部署完畢，功能使用正常。 1.1.4.8.2. 暫停/再啟動準那么 ? 測試版本未通過“接收測試，需要由開發(fā)人員修正后再次接收測試； ? 測試過程中發(fā)現(xiàn)性能瓶頸時測試執(zhí)行暫停，由開發(fā)人員進行調(diào)優(yōu)； ? 開發(fā)人員經(jīng)

43、過調(diào)優(yōu)后解決系統(tǒng)測試瓶頸后，可以再次啟動 1.1.4.8.3. 退出準那么 通過壓力測試發(fā)現(xiàn)的性能瓶頸經(jīng)過待測試系統(tǒng)開發(fā)人員對系統(tǒng)調(diào)優(yōu)后無解決時。 1.1.4.9 測試風(fēng)險分析 1.1.5 工程上線管理 在系統(tǒng)上線過程中，首先成立上線領(lǐng)導(dǎo)小組，在領(lǐng)導(dǎo)小組的組織下，編寫上線方案和應(yīng)急預(yù)案，將上線方案和應(yīng)急預(yù)案提交工程管理辦公室進行評審，待評審?fù)ㄟ^后進行實施。 1.1.6 驗收管理 為加強南京銀行企業(yè)效勞總線系統(tǒng)驗收管理工作，確保工程建設(shè)到達合同要求，高偉達公司建立該驗收管理方法，與南京銀行一道保障工程的順利成功實施。 1.1.6.1 工程驗收的過程 工程驗收包括階段驗收和最終驗收以下簡稱“終驗兩

44、局部。工程只有階段驗收合格后才能投入試運行，終驗合格后才能移交并投入正式運行。 1.1.6.2 工程驗收的參與者 階段驗收工作由南京銀行和高偉達公司共同組織實施，終驗工作在高偉達公司申請后由南京銀行負責組織實施。 1.1.6.3 驗收測試的范圍 驗收測試的范圍包括招標文件中的所有南京銀行企業(yè)效勞總線工程內(nèi)容。 1.1.6.4 驗收測試的責任 高偉達公司負責建立驗收測試環(huán)境，詳細設(shè)計所有的驗收測試方案。測試由高偉達公司進行準備，由南京銀行組織驗收，測試驗收方式和機構(gòu)由南京銀行確定，全部費用由高偉達公司承當。 南京銀行負責組織對驗收測試結(jié)果進行評估。在出現(xiàn)嚴重缺陷時，南京銀行可以決定將所有的測試暫

45、停，直至缺陷得到糾正。 1.1.6.5 驗收測試地點 南京銀行 1.1.6.6 驗收測試的標準 高偉達公司為每一項的測試編寫驗收測試手冊。驗收測試手冊的內(nèi)容包括： ? 驗收測試目的 ? 驗收測試環(huán)境設(shè)備 ? 驗收測試過程的描述 ? 驗收測試結(jié)果及分析 1.1.6.7 驗收方法及標準 對工程進行階段驗收或終驗時，需按如下步驟驗收： 一登記造冊。對工程中所涉及的所有硬件、軟件及工程文檔逐一登記造冊。 二對照檢查。對照檢查工程各項建設(shè)內(nèi)容是否與合同條款及系統(tǒng)需求規(guī)格相一致。 三操作檢查。 1、操作硬件設(shè)備，驗證是否與硬件提供的技術(shù)性能相一致； 2、運行軟件系統(tǒng)，操作處理業(yè)務(wù)，檢查是否與合同規(guī)定的功能

46、一致； 3、對工程文檔進行包括內(nèi)容針對性、內(nèi)容充分性、內(nèi)容一致性、文字明確性、圖表詳實性等方面檢查。 4、工程的驗收以國家標準、行業(yè)標準或國際慣例等為標準。 1.1.6.8 階段驗收內(nèi)容及程序 1.1.6.8.1. 階段驗收目的 檢查整個工程的設(shè)備、系統(tǒng)功能、工程文檔等，使其到達合同建設(shè)要求。 1.1.6.8.2. 檢驗條件 承建單位申請工程階段驗收，應(yīng)當符合以下條件： 一 所有建設(shè)內(nèi)容按照合同要求全部建成，并滿足使用要求； 二 各個分項工程全部階段驗收合格； 三 驗收審核材料齊全，材料主要包含以下幾個局部： 1、 根底資料：招標書、投標書、合同書、批復(fù)文件、系統(tǒng)設(shè)計說明書、系統(tǒng)功能說明書、系

47、統(tǒng)結(jié)構(gòu)圖、工程詳細實施方案； 2、 工程竣工資料：工程開工報告、工程實施報告、工程質(zhì)量測試報告、工程檢查報告、應(yīng)用測試報告、材料清單、工程實施質(zhì)量與平安檢查記錄、操作使用說明書、售后效勞保證文件、培訓(xùn)文檔； 3、 軟件開發(fā)文檔：需求調(diào)研報告、需求說明書、概要設(shè)計說明書、詳細設(shè) 計說明書、數(shù)據(jù)要求說明書、數(shù)據(jù)庫設(shè)計說明書、測試方案、測試分析報告、程序維護手冊、程序員開發(fā)手冊、用戶操作手冊； 4、 軟件開發(fā)管理文檔：工程方案書、質(zhì)量控制方案、配臵管理方案、用戶培訓(xùn)方案、質(zhì)量總結(jié)報告、會議記錄和開發(fā)進度月報、工程開發(fā)總結(jié)報告。 四 軟件已臵于配臵管理之下； 五 系統(tǒng)建設(shè)和數(shù)據(jù)處理符合信息平安的要求，

48、凡涉密信息系統(tǒng)需提供保密主管部門出具的驗收合格證書； 六外購的操作系統(tǒng)、數(shù)據(jù)庫、中間件、應(yīng)用軟件和開發(fā)工具應(yīng)符合知識產(chǎn)權(quán)及相關(guān)政策法規(guī)的要求，并有相關(guān)的授權(quán)使用證書； 七各種設(shè)備經(jīng)加電試運行，工作正常； 八經(jīng)過監(jiān)理方、高偉達公司及相關(guān)主管部門的同意； 九符合合同或合同附件規(guī)定的其他驗收條件； 十由高偉達公司向南京銀行提出階段驗收申請，同時將與工程驗收有關(guān)的材料提交到高偉達公司處； 十一南京銀行審核材料同意工程階段驗收。 1.1.6.8.3. 階段驗收內(nèi)容 按照工程合同以及工程的階段劃分，核實硬件設(shè)備是否齊全、硬件設(shè)備是否符合平安要求、系統(tǒng)功能是否符合合同要求、工程文檔是否符合文檔撰寫要求。 結(jié)

49、合本工程特點，我們建議的階段驗收分為： 1. 平臺建設(shè)完成階段驗收； 2. 數(shù)據(jù)、技術(shù)相關(guān)標準制定完成后階段驗收； 3. 各業(yè)務(wù)系統(tǒng)接入總線完成后階段驗收等。 同時根據(jù)工程的不同開發(fā)階段，穿插對開發(fā)過程形成的文檔進行驗收，例如： 1. 工程需求評審驗收； 2. 工程概要設(shè)計驗收； 3. 工程詳細設(shè)計驗收； 4. 工程測試方案驗收； 5. 工程上線方案驗收等。 1.1.6.8.4. 階段驗收形式 階段驗收只進行功能性測試。 1.1.6.8.5. 階段驗收步驟 一準備階段。工程監(jiān)理單位組織人員根據(jù)階段驗收內(nèi)容對工程進行驗收需求分析，編寫驗收方案書并提交給南京銀行、高偉達公司單位審定。 二成立階段驗

50、收小組。高偉達公司負責組織成立工程驗收小組。 三工程驗收實施。階段驗收小組按本方法第二章驗收方法和標準進行驗收。 四提交階段驗收報告。工程檢查完畢，驗收小組對工程系統(tǒng)設(shè)計、建設(shè)質(zhì)量、設(shè)備質(zhì)量、軟件運行情況等做出全面的評價，并撰寫階段驗收告提交給高偉達公司。 五高偉達公司根據(jù)階段驗收報告，對合格的工程準許投入試運行；對不合格的工程提出存在問題及整改時限，以書面形式通知承建單位，承建單位在通知的時限內(nèi)完成整改后，可再次提出階段驗收申請。 1.1.6.9 終驗內(nèi)容及程序 1.1.6.9.1. 終驗?zāi)康?對經(jīng)過一段時間試運行后的工程進行全面審核。 1.1.6.9.2. 終驗條件 高偉達公司申請工程終驗

51、，應(yīng)當符合以下條件： 1、階段驗收合格后，高偉達公司按照南京銀行要求完成中標的系統(tǒng)開發(fā)并經(jīng)南京銀行上線運行3個月之后，南京銀行確認能夠完全滿足南京銀行的業(yè)務(wù)需求并且能夠?qū)崿F(xiàn)本次招標工程的建設(shè)目標，完全符合南京銀行的技術(shù)要求并且能夠?qū)崿F(xiàn)本招標工程的系統(tǒng)要求，系統(tǒng)運行穩(wěn)定。 2、高偉達公司按照南京銀行要求完本錢次招標工程的業(yè)務(wù)與技術(shù)向南京銀 行的完全轉(zhuǎn)移，包括向南京銀行提供中標標的的培訓(xùn)。 3、高偉達公司按照南京銀行要求向南京銀行完成中標標的所有相關(guān)的源代碼、工程文檔及其介質(zhì)的移交工作。 4、系統(tǒng)在試運行期間沒有出現(xiàn)問題，或出現(xiàn)的問題已經(jīng)解決； 5、驗收審核材料齊全：除階段驗收時涉及的審核材料外，

52、還有工程建設(shè)總結(jié)評價報告組織與實施協(xié)調(diào)、試用總結(jié)報告、用戶使用反響意見、工程培訓(xùn)方案、工程培訓(xùn)總結(jié)，以及由測試資質(zhì)的第三方單位出具的測試報告； 6、高偉達公司向南京銀行提交終驗申請、驗收方案書及終驗審核材料； 7、南京銀行審核材料后同意工程終驗。 1.1.6.9.3. 終驗內(nèi)容 按照工程合同，對工程建設(shè)的各種設(shè)備進行核實；對工程建設(shè)系統(tǒng)進行終驗驗收測試，并進行用戶使用滿意度調(diào)查；對工程建設(shè)的相關(guān)材料進行審核。 1.1.6.9.4. 終驗形式 終驗驗收測試內(nèi)容有功能測試和性能測試，其中性能測試包括執(zhí)行效率、資源占用、穩(wěn)定性、平安性、兼容性、可擴展性、可靠性、并發(fā)性、疲勞強度等，涉及到網(wǎng)絡(luò)的工程性能測試應(yīng)分為客戶端性能測試、網(wǎng)絡(luò)性能測試和效勞器端性能測試三個方面。 1.1.6.9.5. 終驗步驟 準備階段。根據(jù)終驗內(nèi)容由工程監(jiān)理協(xié)助高偉達公司單位制訂終驗方案并