開發進度計劃公共衛生

鄂州市基層醫療衛生信息系統

軟件開發進度計劃(公共衛生)建設方(甲方)代表簽字：日期：監理方代表簽字：日期：承建方(乙方)代表簽字：日期：目錄1. 引言 11.1. 標識 11.2. 系統概述 11.3. 文檔概述 31.4. 與其他計劃之間的關系 31.5. 基線 32. 引用文件 43. 交付產品 53.1. 程序 53.2. 文檔 53.3. 服務 53.4. 非移交產品 63.5. 驗收標準 63.6. 最后交付期限 64. 所需工作概述 85. 實施整個軟件開發活動的計劃 95.1. 軟件開發過程 95.2. 軟件開發總體計劃 95.2.1. 軟件開發方法 95.2.2. 軟件產品標準 105.2.3. 可重用的軟件產品 17. 吸納可重用的軟件產品 17. 開發可重用的軟件產品 175.2.4. 處理關鍵性需求 18. 安全性保證 18. 保密性保證 18. 私密性保證 18. 其他關鍵性需求保證 185.2.5. 計算機硬件資源利用 195.2.6. 記錄原理 195.2.7. 需方評審途徑 196. 實施詳細軟件開發活動的計劃 206.1. 項目計劃和監督 206.1.1. 軟件開發計劃 206.1.2. CSCI測試計劃 206.1.3. 系統測試計劃 206.1.4. 軟件安裝計劃 206.1.5. 軟件移交計劃 216.1.6. 跟蹤和更新計劃 216.2. 建立軟件開發環境 216.2.1. 軟件工程環境 216.2.2. 軟件測試環境 216.2.3. 軟件開發庫 226.2.4. 軟件開發文檔 226.2.5. 非交付軟件 226.3. 系統需求分析 226.3.1. 用戶輸入分析 226.3.2. 運行概念 226.3.3. 系統需求 226.4. 系統設計 236.4.1. 系統級設計決策 236.4.2. 系統體系結構設計 236.5. 軟件需求分析 236.6. 軟件設計 246.6.1. CSCI級設計決策 246.6.2. CSCI體系結構設計 246.6.3. CSCI詳細設計 246.7. 軟件實現和配置項測試 246.7.1. 軟件實現 246.7.2. 配置項測試準備 246.7.3. 配置項測試執行 246.7.4. 修改和再測試 246.7.5. 配置項測試結果和分析記錄 256.8. 系統單元測試 256.8.1. 系統單元測試準備 256.8.2. 系統單元測試執行 256.8.3. 修改和再測試 266.8.4. 系統單元測試結果分析記錄 266.9. 系統集成測試 266.9.1. 系統集成測試準備 266.9.2. 系統集成測試執行 276.9.3. 修改和再測試 276.9.4. 系統集成測試結果分析記錄 276.10. 系統合格性測試 276.10.1. 系統合格性測試準備 276.10.2. 系統合格性測試執行 286.10.3. 修改和再測試 286.10.4. 系統合格性測試結果分析記錄 286.11. 軟件使用準備 296.11.1. 可執行軟件的準備 296.11.2. 用戶現場的版本說明的準備 296.11.3. 用戶手冊的準備 296.11.4. 在用戶現場安裝 296.12. 軟件移交準備 296.12.1. 可執行軟件的準備 296.12.2. 源文件準備 296.12.3. 支持現場的版本說明的準備 296.12.4. “已完成”的CSCI設計和其他軟件支持信息的準備 296.12.5. 系統設計說明的更新 296.12.6. 支持手冊準備 306.12.7. 到指定支持現場的移交 306.13. 軟件配置管理 306.13.1. 配置標識 306.13.2. 配置控制 306.13.3. 配置狀態統計 306.13.4. 制定配置管理計劃 306.13.5. 創建配置管理環境 316.13.6. 配置管理計劃的執行 316.13.7. 配置審核 316.13.8. 發行管理和交付 316.14. 軟件產品評估 316.14.1. 中間階段的和最終的軟件產品評估 316.14.2. 軟件產品評估記錄（包括所記錄的具體條目） 326.14.3. 軟件產品評估的獨立性 336.15. 軟件質量保證 336.15.1. 軟件質量保證評估 336.15.2. 軟件質量保證記錄 336.15.3. 軟件質量保證的獨立性 346.16. 問題解決過程 356.16.1. 問題/變更報告 356.16.2. 更正活動系統 356.17. 聯合評審（聯合技術評審和聯合管理評審） 356.17.1. 聯合技術評審包括一組建議的評審 356.17.2. 聯合管理評審包括一組建議的評審 356.18. 文檔編制 356.19. 其他軟件開發活動 357. 進度表和網絡圖 367.1. 進度控制表 367.2. 進度表 398. 項目組織和資源 408.1. 項目組織 408.2. 項目資源 418.2.1. 人力資源 418.2.2. 開發環境資源 429. 培訓 439.1. 項目技術要求 439.2. 培訓計劃 439.2.1. 總體培訓安排 439.2.2. 現場培訓 432、應用軟件的管理維護培訓 443、應用軟件的系統開發用戶培訓 444、應用軟件的使用培訓 449.2.3. 集中培訓 4510. 項目估算 4710.1. 規模估算 4710.2. 工作量估算 4710.3. 成本估算 4710.4. 關鍵計算機資源估算 4711. 風險管理 4811.1. 外部風險控制 4811.2. 內部風險控制 4812. 支持條件 4912.1. 計算機系統支持 4912.2. 需要需方承擔的工作和提供的條件 4912.3. 需要分包商承擔的工作和提供的條件 49引言標識本條包括了本文檔適用的鄂州市基層醫療衛生信息系統的完整標識。標識號EZCHSS標題鄂州市基層醫療衛生信息系統縮略詞語EZCHSS版本號V4.0發行號V4.0修訂歷史記錄日期說明作者2012-03-04創建賴贊新2012-03-19修正格式盧剛系統概述大力發展社區衛生服務是黨中央、國務院的戰略決策，是衛生重點工作。近年來，市委市政府高度重視，制定了一系列政策和措施，健全網絡、培訓人才、加大投入、強化管理，我市社區衛生服務快速發展，社區衛生服務中產生的大量信息需要處理、分析、利用、管理。但是，社區衛生服務發展歷史較短，尤其是社區衛生服務信息管理系統建設剛剛起步，海量信息和落后的信息管理手段的矛盾越來越突出，加快社區衛生服務信息管理系統建設是當前十分重要而有很緊急的任務。近年來，鄂州市委市政府高度重視，制定了一系列社區衛生服務相關政策和措施，健全網絡、培訓人才、加大投入、強化管理，使得鄂州市社區衛生服務快速發展，社區衛生服務中產生的大量信息需要處理、分析、利用、管理。但是，目前社區衛生服務信息化建設剛剛起步，海量信息和落后的管理手段的矛盾越來越突出，加快社區衛生服務信息管理系統建設是當前十分重要而有很緊急的任務。社區衛生服務是社區建設的重要組成部分，是在政府領導、社區參與、上級衛生機構領導下，以基層衛生機構為主體，全科醫生為骨干，合理使用社區資源和適宜技術，以人的健康為中心、家庭為單位、社區為范圍、需求為導向，以婦女、兒童、老年人、慢性病人、殘疾人等為重點，以解決社區主要衛生問題、滿足基本衛生服務需求為目的，融預防、醫療、保健、康復、健康教、計劃生育技術服務等為一體的，有效、經濟、方便、綜合、連續的基層衛生服務。社區衛生服務信息管理系統（CommunityHealthcareServiceSystem）是指應用計算機及其網絡通訊技術為工具，以健康檔案為核心，在一個特定的區域內，將病人或健康人的衛生醫療信息、衛生行政管理信息和決策分析信息等，進行及時、正確和全面的收集、儲存、處理和通訊，使所有用戶信息達到共享而形成的一個分層次的計算機網絡應用系統。目標是統一居民健康信息管理，滿足社區衛生服務機構社區公共衛生信息數據集中保存、信息共享和數據交換的社區衛生信息平臺，構建居民健康信息庫，更好地為居民提供安全、有效的社區衛生服務。近年來，鄂州市委市政府高度重視，制定了一系列社區衛生服務相關政策和措施，健全網絡、培訓人才、加大投入、強化管理，使得鄂州市社區衛生服務快速發展，社區衛生服務中產生的大量信息需要處理、分析、利用、管理。但是，目前社區衛生服務信息化建設剛剛起步，海量信息和落后的管理手段的矛盾越來越突出，加快社區衛生服務信息管理系統建設是當前十分重要而有很緊急的任務。在這樣的背景下，鄂州市基層醫療衛生信息系統的建設是社區衛生服務的需要、社區衛生服務監管的需要、社區衛生服務發展的需要，也是社區衛生服務信息資源開發、整合的需要。該系統主要用于鄂州市社區衛生服務業務的開展，實施社區衛生服務各項業務的統計、分析、報表、共享居民健康數據等功能，使用信息化手段統一鄂州全市居民健康檔案管理，構建全市公共衛生信息數據交換共享平臺，實現全市社區衛生服務機構公共衛生信息數據集中保存、信息共享和數據交換。在鄂州市所有區（縣級市）調試軟件和培訓人員、使經雙方確認的應用軟件得以正常運行，并根據有關制度和政策的變化對鄂州市內所有用戶的軟件進行統一升級，滿足市、區（縣級市）衛生行政部門和全市所有社區衛生服務機構管理工作需要。本項目的投資方為鄂州市衛生局，需方及用戶為鄂州市衛生局、市轄區（縣）級市衛生局、社區衛生服務中心、社區衛生服務站等機構。開發方為上海金仕達衛寧軟件股份有限公司。文檔概述本文檔主要為軟件需求方提供了解和監督軟件開發過程、所使用的方法、每項活動的途徑、項目的安排、組織及資源的一種方法。鄂州市衛生局作為需求方對本文檔涉及的保密義務如下：保密內容：該文檔所有內容。涉密人員范圍：僅限于對本系統進行驗收和直接維護的人員。保密期限：大于20年。泄密責任：賠償本公司的損失。與其他計劃之間的關系本軟件開發計劃是鄂州市基層醫療衛生信息系統建設的綱要計劃，是其他分項計劃的指導。基線《鄂州市基層醫療衛生信息系統談判采購文件》《鄂州市基層醫療衛生信息系統開發及服務合同》《鄂州市基層醫療衛生信息系統培訓及調試方案》《鄂州市基層醫療衛生信息系統驗收指標》《鄂州市基層醫療衛生信息系統售后服務承諾》《可行性分析（研究）報告》《軟件需求規格說明》《接口需求規格說明》引用文件《社區衛生服務技術規范叢書》衛生部婦幼保健與社區衛生司2008-1-4《婦幼保健信息系統基本功能規范（試行）》衛生部信息化工作領導小組辦公室2008-2《慢病防治方案》中國疾病預防控制中心、慢性非傳染性疾病預防控制中心《常用計劃生育技術常規》衛基婦發[2003]32號《國家衛生統計調查制度》衛生部統計信息中心2007《鄂州市城市社區公共衛生服務項目（試行）》《中華人民共和國傳染病報告卡》《全國性病監測點監測方案（征求意見稿）》《全國碘缺乏病監測方案（試行）》衛生部辦公廳2007-11-14《全國血吸蟲病監測方案（試行）》衛疾控《預防接種工作規范》衛疾控發[2005]373號交付產品程序《鄂州市基層醫療衛生信息系統》文檔項目最終應向用戶移交的所有有關文檔。文檔包括：《可行性分析（研究）報告》《軟件開發計劃》《軟件需求規格說明》《數據需求規格說明》《接口需求規格說明》《系統∕子系統設計（結構設計）說明》《軟件（結構）設計說明》《接口設計說明》《數據庫（頂層）設計說明》《用戶手冊》《操作手冊》《測試計劃》《測試報告》《軟件產品版本說明》服務公司將鄂州市基層醫療衛生信息系統平臺應用軟件管理機構列為公司級的VIP用戶，所以在服務上更加重視，公司為鄂州市基層醫療衛生信息系統平臺應用軟件系統提供的服務方式：公司在各區（縣級市）軟件正式運行后對整個系統提供終身維護服務，軟件系統在整個工程完工后至少提供五年免費服務。服務內容至少包括：所有軟件的升級、維護和故障排除，根據社區的業務發展和要求的改變對管理信息系統進行修改，按照國家和鄂州市相關規范和要求免費升級。如政府相關部門提出信息管理系統相關的新標準和規范，公司有責任免費對系統軟件進行修改和升級。并保證修改后軟件使用的穩定性。如需和其它的信息系統連接，公司應負責免費提供符合國家標準的接口和技術支持。在受理用戶提出的服務要求和問題后，公司應在第一時間給出相應的解決方法：包括2小時內響應，4小時內恢復系統正常運行，必要時24小時內到達現場，問題解決率大于80%。以保證整個系統的正常運轉。電話熱線咨詢服務：公司提供7*24小時電話技術支持。遠程支持：公司提供遠程支持，技術支持工程師通過網絡進行技術支持。在線問答處理：公司負責問題郵件回復和在線問答，在一個工作日內必須做到有問必答，及時、明確地處理各種疑難問題。如需和其它的信息系統連接，公司負責免費提供相關接口。公司提供完整的突發故障應急方案。非移交產品不包含在合同范圍內的其他軟件，包括系統軟件、開發工具等。驗收標準參見《鄂州市基層醫療衛生信息系統驗收指標》最后交付期限交付產品鄂州市基層醫療衛生信息系統，包括：健康檔案、傳染病預防控制、慢性病管理、精神疾病防制、地方病防治、婦女保健、兒童保健、中老年人健康管理、社區康復服務、計劃生育技術服務、社區基本醫療、健康教育與促進、綜合管理及統計、行政管理、系統維護業務模塊。交付文檔公司向用戶交付下列資料的紙質文件和電子文檔：可行性分析（研究）報告、軟件開發計劃、軟件需求規格說明、數據需求規格說明、接口需求規格說明、系統∕子系統設計（結構設計）說明、軟件（結構）設計說明，接口設計說明、數據庫（頂層）設計說明、用戶手冊、操作手冊、測試計劃、測試報告、軟件產品版本說明。交付期限1、在買方認可賣方完成的需求分析和開發計劃后60日內，向買方交付下列資料的紙質文件和電子文檔：可行性分析（研究）報告、軟件開發計劃、軟件需求規格說明、數據需求規格說明、接口需求規格說明、系統∕子系統設計（結構設計）說明、軟件（結構）設計說明，接口設計說明、數據庫（頂層）設計說明、軟件產品版本說明。2、賣方時交付下列資料的電子文檔：軟件修改說明書、在運行的最新版本的軟件源代碼（包括安裝程序代碼）。在此后，凡對軟件進行修改、升級后，即交付軟件修改說明書和修改后的軟件源代碼（包括安裝程序代碼）。3、根據第三條4款軟件升級的約定，向買方交付下列資料的紙質文件和電子文檔：可行性分析（研究）報告、軟件開發計劃、軟件需求規格說明、數據需求規格說明、接口需求規格說明、系統∕子系統設計（結構設計）說明、軟件（結構）設計說明，接口設計說明、數據庫（頂層）設計說明、用戶手冊、操作手冊、測試計劃、測試報告、軟件產品版本說明。所需工作概述公司將按照《鄂州市基層醫療衛生信息系統談判采購文件》、《鄂州市基層醫療衛生信息系統開發及服務合同》、《鄂州市基層醫療衛生信息系統培訓及調試方案》、《鄂州市基層醫療衛生信息系統驗收指標》、《鄂州市基層醫療衛生信息系統售后服務承諾》文檔的要求，進行開發計劃的編制，充分調配公司的內部人財物資源保障項目的順利進行。實施整個軟件開發活動的計劃軟件開發過程鄂州市基層醫療衛生信息系統平臺應用軟件開發計劃包括以下過程，分別是：需求分析在需求分析階段應按照任務書的要求，對應用系統的功能進行合理劃分，并提出合理的性能指標和接口要求。概要設計在需求分析的基礎上，對應用系統的開發環境進行選配。在硬件環境的選配上先進性和實用性的統一。在軟件環境的選用上盡量使用現有的、成熟的技術成果。應使用科學、合理的設計方法，提高開發起點，減少低水平、重復勞動。充分考慮在開發過程中可能涉及到的信息及軟件開發標準和規范。盡量使用已有的標準規范，提高軟件的通用性。詳細設計在詳細設計過程中，應注意系統結構的合理性和易用性，使程序具有更好的維護性。注意程序實現的合理性和效率，考慮用戶的合理要求，使其具有良好的實用性和可靠性。軟件測試按以下順序進行測試和檢查。書面檢查：對軟件文檔進行完整性、準確性檢查。演示測試：對軟件進行模擬運行，檢查其可用性和正確性。人工測試：按軟件評測規范進行人工判定。軟件測試：如果可能，應利用評測軟件對應用系統進行自動測試。應用測試：在實際使用過程中利用真實數據進行檢驗。集成聯試軟件開發總體計劃軟件開發方法軟件開發方法是指軟件開發過程所遵循的辦法和步驟。軟件開發活動的目的是有效地得到一些工作產物，也就是一個運行的系統及其支持文檔，并且滿足有關的質量要求。采取目前主流的幾種開發方法：結構化方法、面向數據結構的軟件開發方法、面向問題的分析法、原型化方法、面向對象的軟件開發方法、可視化開發方法等。考慮到鄂州市基層醫療衛生信息系統的需求和驗收標準是比較明確的本系統將以面向對象的軟件開發方法為主結合其他開發方法。軟件產品標準需求根據合同要求以《軟件需求規格說明》和《接口需求規格說明》等文檔進行說明。設計、編碼系統的設計和編碼規則按照公司的要求完成。例如：基本命名規范規范命名的目的：命名的方法是隨著軟件系統開發使用的編程語言和編程工具的不同而變化的。編程語言的不同決定了可使用的字符，因此，詳細的規定必須根據項目Project的不同情況而定。“開始編程之前，必須設定編程詳細準則”是一個必須遵守的原則。在本系統中，我們采用匈牙利命名法。命名方法之所以要標準化，主要出于以下幾個目的。即使只從名字，也可以判斷出起什么作用？是何種類型？提高了可讀性及可維護性；閱讀源程序以及進行調試時，某個符號屬于哪一個模塊，能很快的明白；和用途直接有關的固有名詞的使用，能夠防止由于疏忽而錯誤地使用于別的用途。對于變量來說，一個用途一個變量是一個重要的原則；可維護性。命名的基本要求：命名指的是對系統原形設計、編程中涉及到的所有標識符的命名，標識符包括原形設計中的菜單、窗體、控件和對象，以及編程中的過程、函數、變量等名稱的符號。在源程序中使用的標識符應該滿足下列基本條件：必須以字母或下劃線開頭；其它可以是字母、數據及些特殊符號；最長為40個字符，中間不能有空格；保留字不能作為標識符；根據其名稱，可以容易地推斷它的用途；根據其名稱，可以容易地推斷變量的作用域和類型基本書寫風格縮排（Tabstops）：每一級為2。行寬（Margin）：代碼行寬一般設為80個字符，超過80應換行。begin/end：begin/end應單獨一行；但begin可與else同在一行；end離Begin太遠時要有層次開始說明{}。如以下示例：括號（Parenthesis）：在左括號與下一個字符，右括號與上一個字符間不要留有空格；不要使用無關系的括號。如：操作符（Operator）：由于操作符有優先級，所以在進行符號運算時一定要合理運用“（）”。在每一個操作符前后均加一個空格。賦值語句：賦值語句用于變量和對象屬性的賦值，這是程序中使用最頻繁的語句。一定要注意類型的匹配、兼容，以及數據的四舍五入造成的數據誤差；賦值符號前后加一個空格。case與if：對每一個case的處理應盡量簡單，如果超過5行代碼，應將處理放入單獨的過程或函數。盡量使用Case替代系統if語句。if嵌套不要超過5級。不要在if中包含無用括號。如果一個if語句中有多個條件，應按條件計算速度從左到右排列條件。如：保留字和關鍵字（ReservedWordsandKeyWords）：在ObjectPascal中，所有保留字和關鍵字總是全部小寫。常量（const）：禁止在程序中直接使用數值的編程方法。盡量使用定義或參數設定，其原因如下：在將來變更的時候，需要修改源文件，或者比較導致修改比較復雜，而容易產生漏改等錯誤。光從數值上來看的話，不容易明白其含義。對這種定數命名時，必須采用望其名通其意的名稱來全局或局部的常量定義，或使用枚舉型常量表示。在程序中使用該常量。錯誤處理：錯誤處理包括程序出錯時的統一處理和規范化的錯誤提示信息。出錯處理：應用統一的錯誤處理過程。在處理過程中，要求顯示中、英文錯誤信息，重要錯誤要記錄日志文件。提示信息：對系統中所有的提示信息，包括出錯提示、操作提示信息應該盡量準確、簡捷，用詞統一。切忌游戲文字和夸張語言。JAVA編碼標準一般概念盡量使用完整的英文描述符采用適用于相關領域的術語采用大小寫混合使名字可讀盡量少用縮寫，但如果用了，要明智地使用，且在整個工程中統一避免使用長的名字（小于15個字母是個好主意）避免使用類似的名字，或者僅僅是大小寫不同的名字避免使用下劃線（除靜態常量等）示范包（Package）采用完整的英文描述符，應該都是由小寫字母組成。對于全局包，將Internet域名反轉并接上包名。java.awt,om.ambysoft.www.persistence類（Class）采用完整的英文描述符，所有單詞的第一個字母大寫stomer,avingsAccount。接口（Interface）采用完整的英文描述符說明接口封裝，所有單詞的第一個字母大寫。習慣上，名字后面加上后綴able，ible或者er，但這不是必需的。Contactable,rompter組件/部件（Component）使用完整的英文描述來說明組件的用途，末端應接上組件類型。okButton,ustomerList,fileMenu異常（Exception）通常采用字母e表示異常。類變量字段采用完整的英文描述，第一個字母小寫，任何中間單詞的首字母大寫。firstName,lastName實參/參數同字段/屬性的命名規則publicvoidsetFirstName(StringfirstName){this.firstName=firstName;}局部變量同字段/屬性的命名規則<類變量>獲取成員函數被訪問字段名的前面加上前綴get。getFirstName(),getLastName()布爾型的獲取成員函數所有的布爾型獲取函數必須用單詞is做前綴。isPersistent(),isString()設置成員函數被訪問字段名的前面加上前綴set。setFirstName(),setLastName(),setWarpSpeed()普通成員函數采用完整的英文描述說明成員函數功能，第一個單詞盡可能采用一個生動的動詞，第一個字母小寫。openFile(),addAccount()靜態常量字段（staticfinal）全部采用大寫字母，單詞之間用下劃線分隔。MIN_BALANCE,DEFAULT_DATE循環計數器通常采用字母i，j，k或者counter都可以接受。i,j,k,counter數組數組應該總是用下面的方式來命名：objectType[]。byte[]buffer;C#編碼標準書寫程序時的大小寫規則:類：PascalCase表示法。如MyClass枚舉值：PascalCase表示法。如Colors.Red枚舉類型：PascalCase表示法。如Colors事件：PascalCase表示法。如MouseClick、ButtonDown異常類：PascalCase表示法。類名稱以Exception為后綴，如MyCustomException、WebServiceException接口：PascalCase表示法。接口名稱以I為前綴，如Icar方法：PascalCase表示法。如GetItemData、UpdateModifiedValue命名空間：PascalCase表示。如Company.Technology.Product、Company.NewApplication.DataTier屬性：PascalCase表示法。如ItemValue參數：camelCase表示法。如itemArray、valueData、purchasePrice私有成員變量：camelCase表示法。如myValue避免將多個類放在一個文件里面。一個文件應該只有一個命名空間，避免將多個命名空間放在同一個文件里面。一個文件最好不要超過500行的代碼（不包括機器產生的代碼）。一個方法的代碼長度最好不要超過25行。避免方法中有超過5個參數的情況。使用結構來傳遞多個參數。每行代碼不要超過80個字符。不要手工的修改機器產生的代碼。如果需要編輯機器產生的代碼，編輯格式和風格要符合該編碼標準。避免利用注釋解釋顯而易見的代碼。代碼應該可以自解釋。好的代碼由可讀的變量和方法命名因此不需要注釋。避免使用方法級的文檔。使用擴展的API文檔說明之。只有在該方法需要被其他的開發者使用的時候才使用方法級的注釋。（在C#中就是///）不要硬編碼數字的值，總是使用構造函數設定其值。只有是自然結構才能直接使用const，比如一個星期的天數。避免在只讀的變量上使用const。如果想實現只讀，可以直接使用readonly。代碼的每一行都應該通過白盒方式的測試。只拋出已經顯示處理的異常。在捕獲(catch)語句的拋出異常子句中(throw)，總是拋出原始異常維護原始錯誤的堆棧分配。避免方法的返回值是錯誤代碼。盡量避免定義自定義異常類。當需要定義自定義的異常時：自定義異常要繼承于ApplicationException。提供自定義的序列化功能。避免在單個程序集里使用多個Main方法。只對外公布必要的操作，其他的則為internal。……測試測試用例是有一定的分類的。要是沒有科學分類的用例，是不便于維護和閱讀。最好按標準寫：接口測試用例、路徑測試用例、功能測試用例、容錯能力、性能測試用例、用戶界面測試、信息安全測試、壓力測試用例、可靠性測試用例、安裝／反安裝測試用例。測試用例與軟件質量特性有對應關系。軟件質量特性：功能性：一組功能（能滿足明確的或隱含的需求）及其指定的特性。適合性：軟件能否提供一組功能及這組功能的適合程度。準確性：能否得到正確或相符的結果或效果。互操作性：和其它指定進行交互的能力。依從性：使軟件符合相關的法規、標準、約定、規定的軟件屬性。安全性：防止對程序及數據的非授權故意／意外訪問的能力。可靠性：在規定的一段時間和條件下軟件維持其性能水平的能力。成熟性：由軟件故障引起的失效的頻度。容錯性：在軟件故障或違反指定接口時，維持規定的性能水平的能力。易恢復性：在失效發生后，重建其性能水平并恢復直接受影響數據的能力，達到此目的所需要的時間和努力程度。易用性：用戶為使用軟件所需作的努力及其對使用所做的評價。易理解性：用戶為認識邏輯概念及其應用范圍所需的努力程度。易學性：用戶為學習軟件應用所需的努力程度。效率：在規定的條件軟件的性能水平和所使用資源量之間的關系。時間特性：軟件執行其功能時，響應和處理時間及吞吐量。資源特性：軟件執行其功能時，所使用的資源數量及使用時間。可維護性：進行指定的修改所需的努力。易分析性：為診斷缺陷或失效原因及為判定待修改的部分所需的努力。易改變性：進行修改、排除錯誤或適應環境變化所需的努力。穩定性：修訂所造成的未可預料結果的風險程度。易測試性：確認已修改軟件所需的努力。可移植性：軟件可以某一環境轉到另一環境的能力。適應性：軟件無需額外的特殊動作就可適應不同的規定環境的能力。易安裝性：在指定環境下安裝軟件所需的努力程度。遵循性：使軟件遵循與可移植性有關的標準或約定的軟件屬性。易替換性：軟件在該軟件環境中平替代指定的其他軟件的機會和所需的努力程度。測試過程單元測試功能測試集成測試測試結果測試用例測試記錄問題提交記錄測試報告可重用的軟件產品吸納可重用的軟件產品公司作為專業的醫療行業軟件公司，已經有多年的社區產品開發經驗，并且已有大量成功的應用案例，因此鄂州市基層醫療衛生信息系統將在公司原有社區產品（3.0）版本上根據標書和合同要求進行重新規劃和開發。開發可重用的軟件產品公司的數據交換平臺任務組件、業務層處理組件、界面組件等都是建立在可重用產品組件基礎上，能夠被其他系統使用。并在產品設計模式上采用軟件工廠等相關模式，實現產品的可重用性。處理關鍵性需求安全性保證產品設計要符合國家《信息安全等級保護管理辦法》及相關文件要求，系統采用的設備符合國家有關安全標準，系統具有嚴密的安全保護措施；充分應用身份識別與驗證、訪問權限控制等措施，保證數據的完整和安全，保護公眾隱私。保密性保證本項目涉及的文檔、代碼等都按照公安部規定的密級等級進行保管。1、數據傳輸過處理采用不可破解加密體系。2、系統運行中，數據對外部系統是無法被竊取、修改、刪除；3、系統在Internet上運行不易被黑客，病毒攻擊；4、在系統被攻擊時，系統能保護數據的安全性，并能保證系統不會崩潰；5、系統用戶要進行安全認證才能接入系統；6、支持復雜的用戶名和口令。口令長度不得低于6位。口令采用加密保護，并提供方便用戶密碼的修改與恢復功能；私密性保證個人或人群有限制自身與他人交換一定質與量的信息的需求，本項目結合操作系統本身的私密性設計，在操作人員離場加密保護、安全性設計等諸多方面保證操作人員、居民信息的對私密性的要求。其他關鍵性需求保證公司：保密內容（包括技術信息和經營信息）:賣方提供的技術資料及文檔（《操作手冊》、《用戶手冊》除外）。涉密人員范圍：僅限于對本系統進行驗收和直接維護的人員。保密期限：大于20年。泄密責任：賠償賣方的損失。用戶：保密內容（包括技術信息和經營信息）:買方提供的技術資料、軟件系統中各類數據信息。涉密人員范圍:軟件研發人員、維護人員和可以接觸到以上資料和數據的人員。保密期限：大于20年。泄密責任：賠償買方的損失計算機硬件資源利用開發活動中，所有開發人員全部使用本公司計算機完成開發工作用戶現場測試，需要使用甲方提供的硬件環境，包括數據庫服務器、應用服務器、客戶端機器、打印機等記錄原理略。需方評審途徑 根據項目合同，在項目每個階段，開發方將按開發合同中的約定提供相關資料、系統供評審，需方也可通過書面申請，對開發方未提供的資料（合同外）等進行索取，以供評審所需。實施詳細軟件開發活動的計劃項目計劃和監督軟件開發計劃軟件開發設計包括以下步驟：需求調研需求分析系統分析系統設計系統開發系統測試CSCI測試計劃功能項測試計劃包括：單元測試功能測試集成測試系統測試計劃軟件測試計劃包括：系統測試集成測試功能測試合格性測試軟件安裝計劃安裝計劃包括：數據庫安裝數據庫安裝由數據庫服務器開發商負責完成；應用軟件安裝應用軟件安裝包括數據服務器安裝和功能服務器安裝，由本公司負責完成；客戶端安裝本公司軟件采取應用服務器集中部署，安裝客戶端只需要登錄應用服務器就可以自動完成安裝工作；軟件移交計劃1、在買方認可需求分析和開發計劃后60日內，完成軟件的研發工作并申請軟件驗收。驗收合格后組織軟件移交與實施，同時部署市級應用平臺。2、軟件驗收合格后7個工作日內在買方確定的鄂州市鄂城區、華容區、梁子湖區三個區正式運行四個月后申請軟件的現場應用驗收。3、試用區現場應用驗收合格后一個年度內完成鄂州市所有區（縣級市）的現有機構的培訓調試等服務工作。隨我市社區衛生服務網絡的不斷健全，每年度內應及時做好新增社區衛生服務機構的培訓調試等服務工作。培訓調試具體內容見附件1《鄂州市基層醫療衛生信息系統培訓及調試方案》。4、軟件試用現場驗收合格后一年內，根據信息技術的發展及有關政策對軟件進行統一升級；升級的開發工作在買方提交“軟件升級需求”后三個月內完成，用戶的升級工作在升級版驗收后兩個月內完成。合同期五年內的升級周期為一周年至少一次,并免費提供升級服務。跟蹤和更新計劃在軟件完成移交和實施后，由客服部門負責維護和更新計劃，并詳細記錄維護和更新日志，如果軟件有更新，則在日志中記錄詳細修正信息。建立軟件開發環境軟件工程環境硬件環境：由本公司研發部門所有參與開發工作的計算機組成；軟件環境：由本公司所有開發過程中所要用到的軟件組成，包括：以J2EE/JAVAEE，microsoftvisualstudio及相關設計工具。軟件測試環境在本公司內部有專門的測試服務器，軟件開發過程中，所有的測試環境均在此服務器上完成。用戶現場測試需要甲方按照合同內容，提供測試環境。軟件開發庫本公司開發數據庫為：Oracal9。軟件開發文檔軟件開發文檔包括：可行性分析（研究）報告軟件開發計劃、軟件需求規格說明數據需求規格說明、接口需求規格說明系統/子系統設計（結構設計）說明軟件（結構）設計說明，接口設計說明數據庫（頂層）設計說明非交付軟件非交付軟件包括開發工具、公司開發的項目管理軟件及輔助開發工具，以及開發過程中產生的相關開發統計數據。系統需求分析用戶輸入分析在調研階段詳細了解客戶的業務流程，并對業務流程進行功能劃分，提出合理的對應流程的功能模塊。運行概念按照合同要求和甲方實際情況，所建立的系統將運行的數據庫為ORACLE9i、UNIX，而應用服務器使用WindowsServer2003、客戶端為WindowsXP。系統需求系統應滿足以下需求：系統運行穩定可靠，滿足7*24小時運行的要求各項功能符合衛生部頒發的規范和要求采用業界公認的國家標準或行業標準采用世界主流、成熟的技術具備開放性和可移植性，適應不同的軟硬件平臺提供容錯機制，在意外情況發生時能確保數據的正確性、完整性能夠實現高水平的信息共享具有易學易用、友善的人機界面系統設計系統級設計決策系統級設計決策包括以下原則：先進性與科學性標準化與開放性實用性與經濟性可靠性與安全性信息共享靈活性與擴充性易操作性及高可維護性系統體系結構設計在遵循系統設計原則的基礎上，結合需求方實際情況，設計系統體系結構。系統體系結構設計包括：數據服務器系統設計在整個系統體系中充當存儲介質的作用，存儲一切與鄂州基層衛生服務信息有關的數據內容。應用服務器系統設計負責完成整個系統體系中的業務功能。客戶端系統設計是實現業務功能的終端，直接與系統使用者關聯，由系統使用者操作。軟件需求分析在需求分析階段應按照任務書的要求，對應用系統的功能進行合理劃分，并提出合理的性能指標和接口要求。軟件設計CSCI級設計決策在綜合調研需求方需求后，以滿足需求方所需求的功能項為原則，制定軟件功能設計。CSCI體系結構設計在充分考慮需求方的業務流程，及各流程中的關聯的情況，設計符合需求方實際現狀的功能體系結構。CSCI詳細設計在需求方對軟件需求文檔分析評審結束并完成修正后，緊密結合需求方功能需求制定軟件功能詳細設計。軟件實現和配置項測試軟件實現軟件實現的主要內容為社區衛生服務信息管理系統，產出的主要為數據庫設計、業務邏輯層設計和用戶界面的設計，軟件測試和配置應遵循上述多層結構進行。配置項測試準備配置項測試首先進行測試環境、工具的準備，并進行測試用例的設計。配置項測試執行在軟件設計開發完成后，提交本公司測試部門，由測試部門完成測試執行工作。修改和再測試測試部門完成測試，并想研發部門提交測試結果，研發部門根據測試結果，對程序進行完善和修改，并再一次提交測試部門執行測試。配置項測試結果和分析記錄使用VSTS工具記錄并分析程序測試結果，并將測試結果和記錄進行統計分析。系統單元測試系統單元測試準備單元測試的主要內容：單元模塊內和模塊之間的功能測試、容錯測試、邊界測試、約束測試、界面測試、重要的執行路徑測試，單元內的業務流程和數據流程等。單元測試的輸入：《源代碼》、《詳細設計報告》單元測試的技術要求：測試要求：a)每個被測單元中每條可執行的腳本都被一個測試用例或異常操作所覆蓋，即腳本覆蓋率達80%。b)每個被測單元中分支語句取真和取假時，各分支至少執行一次，即分支覆蓋率達到80%。c)每個被測單元中的業務流程和數據流程，必須被一個測試用例、一個異常數據、一次異常操作所覆蓋，即異常處理能力達80%。單元測試通過準則a)單元功能同設計需求一致；b)單元接口同設計需求一致；c)能正確處理輸入和異常運行中的錯誤；單元發現問題進行修改后，進行回歸測試，且回歸測試通過后，才能進行下一階段。單元測試的輸出：《單元測試記錄》、《測試計劃》單元測試的測試質量責任人是項目經理。系統單元測試執行由各項目組的開發人員完成測試工作，并詳細記錄測試結果和修改過程，質量部進行抽檢。修改和再測試針對測試后的結果，提交修改計劃，由開發人員完成修改后，再按上述方法執行測試，并形成第二次單元測試記錄。系統單元測試結果分析記錄根據單元測試的技術測試要求，在測試過程中記錄并分析測試結果，生成《單元測試記錄》、《測試計劃》。系統集成測試系統集成測試準備集成測試的主要內容：系統集成后的功能測試、容錯測試、邊界測試、約束測試、界面測試、重要的執行路徑測試，業務流程（接口測試）等。集成測試的輸入：《集成測試計劃》、《概要設計》、《測試大綱》集成測試的技術要求：測試技術要求：a)驗證被測系統是否滿足設計的需求。即根據設計要求中全部功能和性能要求，測試整個軟件系統，驗證其是否達到設計的要求；b)通過數據處理的測試用例對被測系統的輸入、輸出、處理進行測試，使其達到設計要求；c)通過業務處理的測試用例對被測系統的業務處理過程進行測試，使其達到設計的要求；d)測試軟件正確處理能力和容錯能力；e)確認單元間無錯誤連接；f)測試軟件對正常數據的處理，對接口錯誤、數據錯誤、協議錯誤的識別及處理。通過準則a)各單元間無錯誤連接；b)滿足軟件需求的各項功能、性能要求；c)對錯誤輸入有正確的處理能力；d)對測試中的異常有合理的提示；e)人機界面友好。集成測試的輸出：《集成測試bug記錄》、《集成測試分析報告》。系統集成測試執行由測試人員組織進行并完成該階段的測試工作，對測試結果進行詳細的記錄。修改和再測試針對測試后的結果，提交修改計劃，由開發人員完成修改后，再按上述方法執行測試，并形成第二次集成測試記錄。系統集成測試結果分析記錄根據集成測試的技術測試要求，在測試過程中記錄并分析測試結果，生成《集成測試bug記錄》、《集成測試分析報告》。系統合格性測試系統合格性測試準備系統性的初始化測試、功能測試、用戶需求確認、業務處理或數據處理測試、性能測試、安全性測試、安裝性測試、恢復測試、壓力測試等系統測試的輸入：《系統測試計劃》、《用戶需求分析報告》、《用戶操作手冊》、《安裝手冊》系統測試的技術要求：測試技術要求：a)用戶需求的確認：進一步驗證被測系統是否滿足用戶的需求。即根據用戶的需求分析報告中全部功能和性能要求，測試整個軟件系統，驗證其是否達到用戶的要求。b)通過數據處理的測試用例對被測系統的輸入、輸出、處理進行測試，使其達到設計要求；c)通過業務處理的測試用例對被測系統的業務處理過程進行測試，使其達到用戶需求的要求；d)測試其進行數據處理時的響應時間是否滿足用戶要求；e)安裝性測試是驗證其按照《安裝手冊》是否能夠正常配置和安裝；f)安全性測試是測試其對非法用戶的抵御能力，非法用戶無法登錄本系統。g)恢復性測試：測試系統在掉電的情況下，系統的恢復能力。是否正確恢復數據，是否恢復正常操作。h)壓力測試：對b/s結構的系統來說，系統的大用戶量測試，系統的并發能力測試，系統的數據庫壓力測試是必須要做的測試，常用的測試手段是測試工具。如was、loadrunner、jmeter等通過準則a)滿足軟件需求的各項功能、性能要求；b)系統的安全性滿足用戶的需求；c)系統的負載能力滿足用戶的需求；d)系統與外界支持系統正常運行；e)系統的穩定性等滿足用戶的需求；f)用戶操作手冊易讀、易懂、易操作。系統測試的輸出：《系統測試bug記錄》、《系統測試分析報告》。系統合格性測試執行由測試人員組織進行并完成該階段的測試工作，對測試結果進行詳細的記錄。修改和再測試針對測試后的結果，提交修改計劃，由開發人員完成修改后，再按上述方法執行測試，并形成第二次合格性測試記錄。系統合格性測試結果分析記錄根據合格性測試的技術測試要求，在測試過程中記錄并分析測試結果，生成《集成測試bug記錄》、《集成測試分析報告》。軟件使用準備可執行軟件的準備本系統客戶端全部部署在應用服務器上，用戶只需要訪問應用服務器，就可以自動完成客戶端安裝。用戶現場的版本說明的準備在軟件開發階段即著手開始《操作手冊》的編制工作，此《操作手冊》同客戶端一起部署在應用服務器上，在系統使用者安裝客戶端時，即可同時下載此《操作手冊》。用戶手冊的準備本系統《用戶手冊》，隨軟件應用系統部署安裝時交付需求方。在用戶現場安裝本系統客戶端全部部署于應用服務器上，系統用戶在用戶現場通過瀏覽器訪問應用服務器完成安裝。軟件移交準備可執行軟件的準備在系統應用服務器上部署客戶端安裝程序。源文件準備在軟件交付時，隨相關開發文檔一并交付軟件設計源文件。支持現場的版本說明的準備在系統應用服務器上部署《操作手冊》。“已完成”的CSCI設計和其他軟件支持信息的準備在系統移交時，將“已完成”的CSCI設計和相關軟件支持的寫在具體的移交單據中。系統設計說明的更新在系統移交時，系統的相關說明文檔必須與實際提交產品一致，不一致的需要檢查更新為一致。支持手冊準備支持手冊的準備原則同上。到指定支持現場的移交支持現場為鄂州市衛生指定的安裝和驗收現場進行移交。軟件配置管理配置標識配置項目名稱、產生配置項，并配置管理相關人員權限。配置控制配置管理計劃的實施由項目相關參與人員進行，主要是進行配置標志、建立配置基線、編制狀態報告、招待配置審計和變更控制。制定配置管理計劃的過程包括以下主要工作流程：—CCB根據項目的開發計劃確定各階段里程碑和開發策略；—CMO根據CCB的規劃，制定詳細的配置管理計劃，交CCB審核；—CCB審核通過配置管理計劃后交項目經理批準，發布實施。配置狀態統計由項目相關參與人員進行，主要是進行配置標志、建立配置基線、編制狀態報告，并產生狀態統計報告。制定配置管理計劃在項目啟動階段，項目經理首先要制定整個項目的開發計劃，它是整個項目研發工作的基礎。總體研發計劃完成之后，配置管理的活動就可以展開了，如果不在項目開發之初制定配置管理計劃，那么配置管理的許多關鍵活動就無法及時有序地進行，而它的直接后果就是造成項目開發狀況的混亂，并注定使配置管理活動成為一種救火的行為。由此可見，在項目啟動階段制定配置管理計劃是項目成功的重要保證。配置管理計劃由CMO制定，主要內容是制定配置管理策略，制定變更控制策略，編寫配置管理計劃，評審配置管理計劃。創建配置管理環境建配置管理環境主要是由CMO設置硬件環境、設置網絡環境、設置軟件環境、建立一個配置管理庫，儲存項目中定義的配置項，安裝配置管理工具，例如：ClearCase，VSS等，并提供配置管理培訓。配置管理計劃的執行執行階段的配置管理活動主要分為三個層面：—由CMO完成日常管理和維護工作；—由DEV具體執行配置管理策略；—變更控制。這三個層面彼此之間既相互獨立、又互相聯系。在配置管理執行過程中，具體按照如下流程進行：—CCB設定研發活動的初始基線；—CMO根據軟件配置管理規劃設立配置庫和工作空間，為執行配置管理人員做好工作準備；—開發人員按照統一的軟件配置管理策略，根據獲得授權的資源進行項目的研發工作；配置審核CCB根據項目的進展情況，審核各種變更請求，并適時地劃定新的基線，保證開發和維護工作有序地進行。發行管理和交付CCB根據項目的進展情況，根據基線啟動自動測試、自動編譯程序，并產生發行程序，并產生發行配置記錄。軟件產品評估中間階段的和最終的軟件產品評估項目評估/驗證在事先確定的階段進行，并在總體開發計劃中對其日程進行安排。通常要進行二次評估：一次在項目的初始，評估和最終確定總體設計方案；另一次評審在需求分析和軟件構造后，評估和確定項目需求、設計文件。驗證進行一次，通常在編程完成時進行，驗證輸出是否滿足輸入要求。評估由產品開發部門申請，組織銷售部門、實施部門共同進行。驗證由產品開發部門經理、測試負責安排，并對結果負責。評估/驗證的記錄形成書面形式，由開發部門、測試部門編制和存放。軟件產品評估記錄（包括所記錄的具體條目）文件編號：WN-QR-評審記錄-1.4階段日期評審成員存在問題詳見評審標準評審資料優點：缺點：風險分析及評審結論：□通過□通過，有修改□修改后再評審□重新制作負責人簽名：日期：軟件產品評估的獨立性評估的目的是證實設計開發的項目滿足客戶和法律的要求。評估要保證評估的獨立性。開發部門完成試運行β測試，項目經理組織審核小組發表審核意見，得到總裁、客戶或政府授權的監察機構認可。評估的結果應加以記錄，包括缺陷及針對這些缺陷所采取的解決措施的文件。測試人員對軟件修改的內容進行測試，填寫測試意見，由項目經理或部門經理審批。開發部門依文件控制過程與人力資源部交接資料，項目結束。軟件質量保證軟件質量保證評估指評估軟件產品相對于應用、環境及作用的可接受性，滿足需求的能力，具有理想屬性的組合程度及滿足用戶期望的程度的保證。軟件質量保證記錄記錄軟件質量管理過程中的問題及修正。軟件質量保證的獨立性軟件質量管理：在軟件研究過程中對軟件質量要素進行控制的過程。軟件質量構成適用性維護性適用性維護性軟件質量要素完備性可靠性準確性一致性效率能用性可理解性可更改性可測試性可移植性需求分析性能需求分析性能功能接口環境方法標準程序實現結構設計文檔生成初步設計詳細設計軟件設計研究過程問題解決過程問題/變更報告記錄軟件在開發過程中出現的問題及對起所做的變更的文檔。更正活動系統負責在軟件開發活動中記錄和分析軟件所出現的問題及針對問題所做的更正內容，并針對更正活動制定更正計劃和任務的系統方法。聯合評審（聯合技術評審和聯合管理評審）聯合技術評審包括一組建議的評審在項目階段及結尾，組織進行技術的聯合評審，從技術的各個層面進行總體的綜合性評審，并產生評審記錄。聯合管理評審包括一組建議的評審在項目階段及結尾，組織進行管理的聯合評審，從技術的各個層面進行總體的綜合性評審，并產生評審記錄。文檔編制在開發文檔編制過程中，所有文檔應符合《GB-T+8567-2006+計算機軟件文檔編制規范》標準。其他軟件開發活動無進度表和網絡圖進度控制表本表為各工程任務的完成時間的先后順序和銜接關系，作為工程進度計劃安排和時間點控制的基本依據。鄂州市基層醫療衛生信息系統軟件建設進度控制表階段名稱明細工程進度1234561系統設計需求調研需求確認總體設計方案2業務系統設計研發數據中心運行軟件研發社區衛生服務業務系統其他外部系統的數據導入、數據整合等工作；3系統試運行、驗收試點機構培訓試點機構試運行系統維護試點機構驗收4系統推廣、免費維護期系統推廣項目應用驗收通過后，合同約定的免費維護期內培訓系統維護進度表任務名稱工期開始日期完成時間鄂州市基層醫療衛生信息系統118工作日2012/3/152012/5/15需求調研6工作日2012/3/152012/3/22需求分析6工作日2012/3/182012/3/25系統分析10工作日2012/3/222012/4/4系統設計10工作日2012/3/292012/4/11系統開發86工作日2012/4/102012/5/15健康檔案7工作日2012/4/102012/4/18傳染病管理7工作日2012/4/152012/4/23慢性病管理8工作日2012/4/172012/4/26重型精神病管理6工作日2012/4/222012/4/29地方病防治5工作日2012/4/242012/4/30婦女保健7工作日2012/4/102012/4/18兒童保健8工作日2012/4/152012/4/24老年人保健5工作日2012/4/222012/4/26康復管理6工作日2012/4/102012/4/17計劃生育管理5工作日2012/4/152012/4/19健康教育管理6工作日2012/4/192012/4/25綜合管理及統計8工作日2012/4/292012/5/8行政管理8工作日2012/5/102012/5/15備注：考慮到10.1國慶放假，10月份后工作日需要順延7天。起始日期根據具體日期另行調整，目前只是暫定日期。項目組織和資源項目組織項目組：管理機構設領導小組和工作小組，采用領導小組下的各級負責制，并明確規范所屬下級各組的職責及組間關系，監督工程的實施：序號名稱職能1項目領導小組主要負責審定建設計劃、項目投資、總體方案及有關重大問題；對組織協調組、專家顧問組、總體需求組、總體技術組和分系統項目組實施領導。2項目工作小組具體工作的執行小組，包括流程規劃、設計規劃、配合實施、人員組織、環境搭建等等。3組織協調組主要負責制定工作計劃，掌握工程進度，檢查工程質量；指導總體需求組、總體技術組和各工程組的工作；協調各部門之間的關系，做好保障服務工作。組織協調組在項目領導小組的領導下由雙方工程建設總負責人組成。4總體需求組主要負責擬定總體需求方案和有關技術系統需求方案，確定整體系統的使用功能，制定各項技術指標。總體需求組在項目領導小組的領導下由工程實施單位的有關管理、技術人員及用戶單位的負責人組成。5總體技術組總體技術組負責擬制總體技術方案，確定各項技術標準，搞好主要設備的選型，對系統進行技術劃分，檢查各系統研發情況，組織系統集成和聯調。總體技術組在項目領導小組的領導下由項目實施單位的有關技術人員組成并具體負責。6各分系統項目組各分系統項目組主要負責各分系統工作計劃、實施、進度控制及人員調配。各分系統項目組主要由項目實施單位技術人員組成并具體負責。7項目驗收組項目驗收組主要負責項目的各項驗收檢驗，包括各分系統的階段性驗收和系統最終驗收。項目驗收組由領導小組指定。8系統維護組系統維護組負責系統試運行期間和工程建設完畢后的維護工作。系統維護組主要由工程實施單位和用戶方面部分技術人員共同組成。9項目監理負責對項目實施過程中的監理，有條件的話可以外聘專業單位實施項目監理。項目資源人力資源序號姓名參與項目階段學歷職務/職稱/獲得資質證書具有公共衛生領域相關工作經驗年限備注1蔡玲系統調研本科公共衛生開發部經理/高級程序員/項目經理62周金玉系統調研本科項目經理33賴贊新系統調研、系統分析本科高級程序員/產品經理54馬維民系統分析、系統設計本科公共衛生開發部經理/高級程序員/項目經理65范鈞系統分析、系統設計本科社區衛生產品開發經理66周洪系統分析、系統設計本科社區衛生產品開發經理87韓偉系統設計、程序設計本科公共衛生事業部項目經理/計算機信息系統集成項目經理78李偉系統設計、程序設計本科高級程序員59盧剛系統設計、程序設計本科高級程序員510孫曉偉程序設計本科高級程序員311馬曉霞程序設計本科高級程序員412李斌程序設計本科程序員213許冬華測試本科實施工程師/程序員414李梁測試專科測試工程師515李晨實施專科實施工程師/中級程序員416王謀林實施本科高級程序員4開發環境資源公司滿足項目開發的硬件及軟件開發環境。主要包括：服務器、網絡、開發機、數據庫系統、中間系統、操作系統，以及郵件等通訊系統。培訓項目技術要求培訓技術要求：培訓內容先進性與實用性相結合；聘請專業的培訓教師為學員授課；培訓教材采用原廠商提供的中文教材，授課語言為中文；境外培訓做好接待工作，協調好相關的一切事宜；對學員從嚴要求，確保培訓質量；建立培訓反饋體系，由學員考評培訓教師，確保培訓質量。培訓計劃總體培訓安排我方將采取現場培訓和集中培訓兩種方式，組織下列培訓：系統軟件管理員培訓中標后盡快安排系統軟件管理員的培訓，主要為第三方廠商的認證培訓，包括數據庫管理、應用中間件管理等。