氣象局共享系統實施方案大綱-資料下載頁

【導讀】中科軟科技股份有限公司。新一代天氣雷達信息共享平臺-數據共享服務系統投標文件

　　

【正文】 其它標段單位的關系 國家氣象局本次項目比較大， 涉及 業(yè)務比較多，也考慮了項目具有很高的專業(yè)性，建設起來有一定的難度的特點，考慮到項目實施的成功率，所以本項目是采取總集成商新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 26 頁 總 84 頁 牽頭，分標段進行建設。這樣就會有幾家單位一起對該項目進行建 設，因此就會產生各系統相關接口的對接問題，以及數據共享和交換的問題的發(fā)生，所以各承建單位保持很好的溝通和協商是非常必要的。 在 這樣一個大的環(huán)境下，同樣我們單位有著多年豐富的團隊合作經驗，我們會在該項目的實施和建設期間，以及前期的調研、后期的維護期間都會于其他標段單位有好合作，共同把該項目做好，確保該項目建設成功。 項目溝通機制 目的 為保證工程建設質量，加強業(yè)主方各承建方工作溝通和協調，協調新一代天氣雷達信息共享平臺項目所涉及的各承建方之間的工作關系，并協調解決項目建設過程中的各類問題。 溝通機制 業(yè)主方與 監(jiān)理方、總集成方、各承建方之間要建立順暢的溝通協調渠道 ，所有問題能夠第一時間傳達到各方主要負責人，及時對為題作出判斷和解決的方法，提高項目管理的效率，降低項目建設的風險 。主要方式有信息交流、文件交流、召集會議等。 ? 主要溝通對象 業(yè)主方 （ 中國國家氣象局 ）、 總集成商 、監(jiān)理單位、第三方測試單位 、其他標段單位等； 授權人：各方應指定在書面交換文件上代表本方簽字的授權人（可有一位或一位以上授權人） ； 聯系人：各方應指定本方的聯系人（可有一位或一位以上聯系人）。通過聯系人收發(fā)文件以及交換信息 ； ? 溝通協調的方式 溝通協調 方式主要有：會議制度、匯報制度和其他輔助方式（如電話、傳真、電子郵件、郵遞、面談等）。 工作方式如下： 會議制度 會議制度將由總集成單位、 監(jiān)理 單位 同 業(yè)主方共同 建立會議制度，主要包括 日常會議、項目 例會、 監(jiān)理會議、 專題會議 等 ； 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 27 頁 總 84 頁 ? 項目領導小組月度會議。項目領導小組每月一次聽取項目協調管理小組的綜合匯報，研究、分析、解決項目進展過程中重大事項。 ? 項目例會制度。國家氣象局、總集成單位、監(jiān)理單位、其他承建商定期于每周召開項目例會；項目監(jiān)理單位應建立適用于本項目的項目例會制度。 ? 專題會議制度。專題會議根據項目進展情況隨 時召開。 ? 建立項目聯席會議制度，加快涉及多業(yè)務部門相關事務的解決。 ? 建立 專家咨詢評審會議制度 。所有會議應形成會議紀要。其中，例會和專題會議由項目監(jiān)理單位負責撰寫會議紀要；項目聯席會議和專家咨詢評審會議由國家氣象局項目辦或項目辦授權監(jiān)理單位負責撰寫。所有紀要應至少由國家氣象局、項目承擔單位和項目監(jiān)理單位的約定文件簽收人簽收。 報告制度 各承建單位根據總體要求 定期向業(yè)主方提交 月、 例會報告、專題報告、階段或里程碑總結報告，由業(yè)主方授權人簽署，發(fā)送給各方相關人員 ； ? 周報 （ 1）項目周報內容包括項目進展情況、存在 問題、下一階段工作安排。其中，對于存在問題，應同時提出解決建議。 （ 2）各承建單位 每周五形成項目工作周報，主送 國家氣象局 、 總集成單位、 監(jiān)理 單位 ， 分送其他相關單位。 ? 月報 （ 1） 項目月報內容包括項目進展情況、存在問題、下一階段工作安排。其中，對于存在問題，應同時提出解決建議。 （ 2） 項目各分建單位 于每月倒數第二個工作日形成項目月報，主送 總集成單位、監(jiān)理單位；單位之間 分別相互主送； （ 3） 總集成單位 于每月最后一個工作日向監(jiān)理單位提交匯總的月報； （ 4） 監(jiān)理 單位于次月第 一個工作日向 國家氣象局項目辦 提交監(jiān)理月報 ，并 協助國家氣象局項目辦 撰寫 項目簡報。 ? 專題報告 （ 1）專題報告應就項目進展過程中的專題性事項進行分析，并提出建議。 （ 2） 根據 項目進展 情況 ，報告發(fā)起單位應向項目相關各方 提交專題報告。 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 28 頁 總 84 頁 項目進度計劃安排 項目進度總體要求 項目進度安排 項目管理計劃 項目立項啟動 需求分析 系統設計 系統開發(fā) 用戶測試 用戶培訓 系統試運行 系統正式運行 系統部署 系統驗收 系統測試 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 29 頁 總 84 頁 測試類型 單元測試：內部開發(fā)功能模塊代碼測試、模塊內部接口測試 內部集成測試：內部開發(fā)模塊集成測試、模塊間接口測試 外部集成測試：內部開發(fā)模塊與協 作方開發(fā)模塊集成測試、模塊間接口測試 系統測試：整個系統測試、系統整體功能測試、子系統間接口測試 驗收測試：用戶驗收現場測試。 測試方針、要點 測試是軟件項目進行質量把關很重要的環(huán)節(jié)，質量管理組一方面要對測試過程和測試文檔進行把關，另一方面質量工程師應對系統的重要模塊進行抽樣測試，通過測試手段檢查軟件系統是否符合用戶功能和性能的要求，是否符合設計要求，是否能正常運行，是否能進行異常處理等方面進行質量檢查，一旦發(fā)向質量問題將要求項目組進行全面的回歸測試。 應用軟件測試主要包括以下具體任務： ? 分析各應用軟件系統 需求說明書和概要設計說明書，整理測試范圍。在各應用軟件系統的需求文檔和設計文檔形成之后，根據這些文檔對系統測試范圍進行確認，生成測試計劃。 ? 根據計劃編寫各要點的測試用例，包括合法輸入和不合法輸入，力求使測試用例能全面覆蓋軟件的功能。 ? 利用測試工具記錄測試要點，進行測試任務分配，包括每個要點的用例編寫人、測試人、測試問題修改人。 ? 搭建測試環(huán)境，準備測試數據，維護測試數據庫。 ? 根據用例執(zhí)行測試，記錄 bug，進行回歸測試。 ? 對測試結果進行分析，并編寫測試分析報告并進行評審。 測試環(huán)境、工具、技術與方法 測試環(huán) 境 內部測試利用開發(fā)環(huán)境 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 30 頁 總 84 頁 測試管理工具 軟件測試管理系統 裝載在中科軟內部服務器，內部測試使用。 測試技術與方法 進行代碼測試，語句覆蓋 100%； 進行功能測試，功能覆蓋 100%； 編寫測試用例、按不同角色、實際業(yè)務流程測試； 重要路徑測試； 邊界值測試； 錯誤處理測試； 測試方法 軟件的測試過程主要包括單元測試、集成測試、系統測試、驗收測試，在單元測試和集成測試階段重點進行 模塊測試、功能測試 。測試方法分別根據各階段的側重點分別采用不同的測試方法。 常用的測試方法包括黑盒測試和 白盒測試。單元測試采用白盒測試方法 ,測試覆蓋方法采用分支覆蓋；集成測試、系統測試和驗收測試采用黑盒測試方法。 黑盒測試（功能測試 /數據驅動測試）：在已知軟件功能設計內容的前提下，由測試人員依據有關技術文檔，著重測試和檢驗軟件實現的功能是否符合要求，這種測試對軟件或程序模塊的內部結構與技術實現細節(jié)并不關心，而僅關心測試的軟件或程序模塊是否能正常運行，輸入的數據、范圍值等是否能被準確地接受，輸出的結果是否正確，操作界面、操作效果、以及運行效果等是否達到了預定的目標。黑盒測試適用于各個階段的測試活動。 白盒測試（ 結構測試 /邏輯驅動測試）：在己知軟件或程序模塊的內部結構與技術實現細節(jié)的情況下，由測試人員利用程序的內部邏輯結構與有關文檔的信息，設計并準備測試用例與模擬數據，注重檢測程序模塊的邏輯路徑、不同點的執(zhí)行狀態(tài)、模塊接口、執(zhí)行效果等。這種測試雖然難度較大、過程復雜，但測試效果顯著。白盒測試適用于軟件編碼階段的單元測試活動中。 除此之外，還可采用以下測試方法： 累積綜合測試：當一個新功能增加后，對應用系統所做的連續(xù)測試。它要求應用系統的不同形態(tài)的功能能夠足夠獨立以可以在全部系統完成前能分別工作，或當需要時那新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 31 頁 總 84 頁 些測試驅 動器已被開發(fā)出來 ； 這種測試可由程序員或測試員來做。 負載測試：測試一個應用在重負荷下的表現，例如測試一個 Web站點在大量的負荷下，何時系統的響應會退化或失敗。 可用性測試：對“用戶友好性”的測試。顯然這是主觀的，且將取決于目標最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其他一些技術都可使用。程序員和測試員通常都不宜作可用性測試員。 配置測試：又叫兼容性測試。配置測試核實測試對象在不同的軟件和硬件配置中的運行情況。在大多數生產環(huán)境中，客戶機工作站、網絡連接和數據庫服務器的具體硬件規(guī)格會有所不同。客戶機工 作站可能會安裝不同的軟件例如，應用程序、驅動程序等而且在任何時候，都可能運行許多不同的軟件組合，從而占用不同的資源。（如瀏覽器版本，操作系統版本等） 文檔審核測試：文檔審核測試目前越來越引起人們的重視，軟件質量不是檢查出來的，而是融進軟件開發(fā)中來。前置軟件測試發(fā)越來越受到重視。請看一個資料：文檔審核測試主要包括需求文檔測試，設計文檔測試，為前置軟件測試測試中的一部分。 測試用例要求 測試用例依據需求規(guī)格說明書、詳細設計書說明書、數據庫設計說明書、界面設計說明書、在 ITEST 上編寫，要求： 測試大綱覆蓋軟 件所有的功能要點和主要流程； 每一條用例應給出測試數據（需要輸入數據時）、執(zhí)行步驟或方法、和預期結果。 測試用例應易于理解和重用、便于實施，避免重復和冗余。 測試用例應設計足夠的非法輸入檢查、邊界值檢查。 測試開始前進行用例正式評審，測試負責人和項目經理參加評審，評審通過后開始測試。測試過程中根據需要補充測試用例，補充的測試用例經過審查后方可執(zhí)行。 缺陷處理流程 開發(fā)組進行單元測試、報告、修改、驗證、關閉缺陷；向測試組提交測試結果； 開發(fā)組與測試組協作進行集成測試、系統測試，測試組報告 BUG、開發(fā)組修改 BUG、測試組驗證 BUG、驗證結果正確則關閉 BUG、否則重新提交 BUG；有爭議的 BUG，雙方通過協商解決，確定不是 BUG、可以 CANCEL，不能解決的問題提交 CCB討論決定。 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 32 頁 總 84 頁 測試數據采集與分析 分別采集各次測試結果。包括： 測試大綱、測試用例、 BUG狀態(tài)、嚴重級別、優(yōu)先級別、類型分布、階段分布、錯誤原因分布、缺陷按功能要點分布等；這些數據可以從 ITEST上導出。 測試組分析測試結果： 統計缺陷高發(fā)點、計算測試效率、缺陷密度、各級缺陷清除率等。 測試完成規(guī)則 每輪測試： a) 計劃測試的功能全部測試一遍 b) 進行代碼 測試時，語句覆蓋達到 100% c) 進行功能測試事，功能覆蓋達到 100% d) 對比缺陷指標、發(fā)現缺陷數低于下限或高于上限時分析原因再測 e) 根據測試結果、對缺陷集中的功能進行回歸測試 單元測試要求： a) 每輪測試 BUG 清除率 80%以上；其中 2 級 BUG 清除率 100%； b) 每輪單元測試后提交單元測試報告；達到要求后方可提交測試組、開發(fā)組與測試組共同進行集成 /系統測試。 c) 集成 /系統測試要求： d) 系統集成測試 BUG 清除率 100%； 測試內容 測試內容主要包括功能測試和性能測試，系統功能應滿足用戶需求。系統性能應從可靠性、安全性、可擴 充性、可維護性、平臺移植性、與其它系統的接口等方面全面測試。 代碼測試：覆蓋所有程序語句； 功能測試：覆蓋需求規(guī)格說明書描述的所有功能和業(yè)務流程； 性能測試：提交報告、進行統計、查詢等操作的響應時間不超過 2 分鐘； 內部接口測試：內部開發(fā)模塊間的接口測試、數據傳輸測試； 新一代天氣雷達信息共享平臺 數據共享服務系統投標文件 (實施服務方案 ) 第 33 頁 總 84 頁 外部接口測試：內部開發(fā)模塊與協作方開發(fā)模塊間的接口測試、數據傳輸測試。 測試文檔提交 在軟件開發(fā)過程中，編程和測試是緊密相關、相輔相成的技術活動，缺一不可。在一個完整的測試過程完成后，需要形成一系列文檔材料，并根據要求，對文檔進行提交，主要包 括以下幾種： ? 測試計劃文檔 ? 測試用例文檔 ? 單元測試報告 ? 集成測試報告 ? 功能測試報告 ? 系統測試報告 ? 驗收測試報告 ? 安全性測試報告 ? 兼容性測試報告 項目質量管理體系 質量體系的構成 質量管理在軟件項目對軟件質量的保證、項目建設的成功起著重要的作用，我公司嚴格按照質量管理體系 ISO9001 和 CMMI5 的要求對軟件項目進行管理和指導。 我們會在項目中的每一個環(huán)節(jié)都嚴格遵照 ISO9001和 CMMI5的質量管理規(guī)范來實施，從規(guī)劃、設計、開發(fā)、實施、維護、培訓到技術支持的整個項目過程都會投入一支技術精湛、業(yè)務精通的專業(yè)