導讀:在這裡我就接著多年的工作經驗，並拿出曾經給負責的一個項目撰寫的實施規劃詳細方案說明書，來作為案例給大家展示一下，寫得不好，其中也有很多欠缺之處，願朋友們看過之後能夠給出很好的批評，咱們在這裡相互學習、共同進步！
一、市政行業信息化技術發展狀況1.1 引言1.1.1 文檔目的
具體有以下幾點主要目的：
實現基本建設計劃和設計需求，衡量設計方案的可能性和合理性。
規劃正常的實施流程，有計劃地開展各項實施過程。
及時做好各項準備工作提供依據，為整個項目的各個方面做好保障措施。
協調項目開發團隊與時間之間的合理關係，以保證工作順利的進行。
為項目後續的各項工作提供切實可行的保證措施。
1.1.2 文檔內容
本文檔包括以下主要內容：
引言
市政行業信息化技術發展狀況
承擔單位概況
總體技術規劃方案
系統設計
系統功能需求
平臺性能規劃方案
質量保障方案
項目建設與費用預算方案
集團建BIM協同管理平臺實施策略規劃
效益分析
結語
1.1.3 文檔約定
通過以下幾點核心概念進行約定闡述：
1.2 建築信息化技術的概念1.2.1 建築信息化背景
建築業信息化概念是1975年在美國首次被提出，但當時受制於技術未能實現。我國在2003年由建設部頒布了《2003—2008年全國建築業信息化發展規劃綱要》，指出我國要運用信息技術實現建築業跨越式發展。
1.2.2 建築信息化概念
建築業信息化是指運用計算機、通信、控制、網絡、系統集成和信息安全等技術，改造和提升建築業技術、生產、管理和服務水平。
1.2.3 建築信息化發展階段
建築信息化發展階段依次是「手工、自動化、信息化、網絡化」。
2000年的「甩圖板」運動使得CAD技術實現了從手工到自動化的革命。
2008年參與「水立方」建設的BIM技術，開啟了我國從自動化到信息化的轉變。我國目前處於BIM技術的推廣應用階段，即從自動化朝信息化轉變的階段，同時以網絡平臺和電子商務為基礎的網絡化發展階段也已開啟，與信息化階段同步發展。
1.2.4 建築信息化的內容
建築業信息化是指從建築企業規劃、設計、建築施工、竣工驗收等整個過程中充分利用現代信息技術和信息資源，逐步提高建築業集約化經營管理程度，使信息對建築業的貢獻達到較高水平的過程。
建築業信息化是國家信息化的基礎，是國家信息化的重要組成部分。
1.3 建築信息化技術的市場趨勢1.3.1 建築信息化的發展目標
《2016-2020年建築業信息化發展綱要》
發展目標：「十三五」時期，全面提高建築業信息化水平，著力增強BIM、大數據、智能化、移動通訊、雲計算、物聯網等信息技術集成應用能力，建築業數位化、網絡化、智能化取得突破性進展，初步建成一體化行業監管和服務平臺，數據資源利用水平和信息服務能力明顯提升，形成一批具有較強信息技術創新能力和信息化應用達到國際先進水平的建築企業、及具有關鍵自主智慧財產權的建築業信息技術企業。
1.3.2 建築信息化的建設規劃
《XX市城鄉建設和管理「十三五」規劃》:
（一）大力推進智能管理平臺建設
構建城鄉建設和管理綜合信息共享交換平臺。整合工程建設、城市運行、城市綜合管理和生態環境建設等領域信息平臺建設。完善房屋管理、城管執法、燃氣監管、道路照明管理等信息系統和服務平臺。
在現有城市綜合管理網格化平臺、綜合交通管理信息平臺、建設市場管理信息平臺、地下空間信息基礎平臺的基礎上，基於物聯網、大數據技術和電子政務、政務外網基礎設施資源，推動本市城市管理綜合信息共享交換平臺建設，匯聚城鄉建設和管理行業以及公安、工商等其他相關部門的基礎數據，構建城鄉建設和管理數據資源中心，實現各行業信息共享交換。
（二）推進建設管理智能化
發揮信息化在城市綜合管理中的支撐和引領作用，促進大數據、雲計算、物聯網等新一代信息技術與城市管理服務的融合。
探索構建城市信息模型（CIM）框架。按照城市管理精細化、可視化和社會治理協同化、透明化發展需求，加強互聯感知、數據分析和智能決策技術的應用。
以人口、法人、空間地理三大數據平臺為基礎，以城鄉建設和管理領域共享平臺為切入點，推進城市綜合管理相關數據資源的內部共享和對外開放，建立基於數據共享的協同化決策和管理機制，提升市場化的數據開發利用水平。探索多樣化互動技術應用，創新公眾參與載體。
（三）推廣BIM等技術應用
推進網際網路+、BIM技術、大數據和雲計算在建設行業的廣泛應用。打造網際網路+、BIM+工程建設和城市管理的發展新模式，建立健全BIM技術應用相配套的政策標準體系和推進考核機制，創建國內領先的BIM技術綜合應用示範城市，加快推進BIM技術廣泛應用。
（四）加強城市綜合管理信息化基礎設施建設
推進信息化技術與城市綜合管理融合應用，聚焦監測預警、城市防澇、水環境和燃氣安全、工程抗震等，以地下管線和市政設施等的監測預警和應急處置管理為切入點，探索信息技術與地上地下城市基礎設施安全預警及運行保障的融合運用，不斷完善基礎設施監測預警信息化水平。
積極推進智慧照明，探索道路照明燈杆綜合利用，為新能源汽車充電、移動通信、公共安全等提供空間載體，建設以智慧照明為核心功能，融合綠色能源、智慧安防、應急指揮、無線城市、智能感知和信息交互等功能的智慧照明網絡。
《XX市推進智慧城市建設「十三五」規劃》：
提升傳統企業信息化水平。大力推廣「兩化」融合管理體系貫標試點，建立和完善本市貫標服務認證體系。推廣數位化技術、系統集成技術、關鍵技術裝備、智能製造成套裝備，建設智能工廠、數位化車間。鼓勵骨幹企業推動產品全生命周期管理、供應鏈管理、集團智能管控等系統的深入應用。引導產業鏈協同生產平臺建設，深化研發、製造和服務等環節的協同應用。面向中小企業推廣行業信息化公共服務平臺應用，降低信息化建設成本。
促進綠色安全生產信息化。鼓勵企業充分利用物聯網實現能源消耗數據的自動採集，開展能效綜合評估、節能潛力分析、能源綜合管理、能源集成優化等應用，探索建設覆蓋各領域的能耗在線監測系統。鼓勵重點行業企業建立事故監測、應急處置、流程追溯、質量控制等系統，完善工控系統安全管理的信息化支撐體系。
1.4 建築信息化技術的價值分析1.4.1 建築信息化的價值體現
建築企業信息化發展，已經從單一的系統應用軟體向大型綜合管理系統過渡，集成了企業經營活動的核心系統，涵蓋了企業管理與經營活動多個業務系統，形成了統一的企業信息管理門戶、基礎應用平臺、數據報表平臺、管理決策平臺。解決了建築施工企業傳統的多層級多專業跨系統的綜合性大項目管理難題，能夠實現高效的集團式管控模式，引領企業管理創新、轉型升級，由過去的速度規模型發展向面向客戶的質量效益型發展轉變，為企業精細化管理提供助力。
1.4.2 建築信息化的核心價值
（1）實現管理規範化、精細化
建築企業以經營項目建設為核心，完成的產品是交付工程項目，最終目的是體現企業市場價值，實現企業盈利。工程項目建設成果，是過程中的一系列數據反映出來的，這些數據過去如果看不到，某一個地方管控不到位，可能就會造成資金流失。
就項目成本管理而言，數據分析要及時，才能實時跟蹤項目成本狀況，否則對後期項目建設起不到調控和指導作用。信息化的利用，能夠統一經營分析的方法和口徑，為實現項目成本分析的標準化和程序化提供了可能，實現標準化的意義在於消除短板，提高競爭能力。
實施信息化後，各業務系統都形成一套工具方法作指導，讓項目層按照標準的方式去實施，對提升企業整體項目管理水平，促進精細化管理，進而提高企業核心競爭力有著推進作用。
（2）增加自營項目管理能力，落地法人管項目
藉助信息化平臺的數據收集，逐步建立企業關鍵指標庫以便指導後續項目投資控制及過程控制，從而提升企業的經營能力和競爭力。在原有技術優勢上縮小管理短板，使整體市場競爭力得到顯著提升，做信息化的幾何級收益。
同時，已經積累的數據及指標，為管理者進行項目選擇和決策時，提供有力的數據支持及參照，在提升管理效率的同時，增強了決策的科學性，為企業戰略執行提供強大武器。
（3）數據透明，陽光工程
通過信息化，解決了經營實效的問題，所有項目部或基層單位採購材料、租賃的設備、基建安裝，勞務分包的範圍、價格、方式都會在平臺上進行對比；經營分析的數據結果可以追蹤，甚至哪個項目部召開了質量檢查會後，甲方代表或者監理對工程項目有什麼意見，都會毫無保留地呈現出來。平臺的建立使企業經營公開透明，從而對相關人員產生了道德上的約束。
1.4.3 建築信息化的必要性
1.4.3.1 有利於提高服務水平
本項目將為XXXX工程提供三維可視化信息模型、動態建設管理及全生命期的信息管理平臺，提高工程效率、減少失誤、節省資源，使BIM環節的各個利益參與方都能從中獲益。合理降低和有效控制工程建設整體投資的同時，從而為後期運營維護提供了便利，提高相關工作的整體服務水平。
1.4.3.2 有利於完善服務體系
本項目將推動BIM技術在市政工程建設中的應用與發展，對未來城市市政基礎設施建設水平的提高產生積極的影響。同時，基於BIM技術的工程建設全生命周期管理，將為政府主管部門提供管理上的便利，為智慧城市提供基礎數據，以此來完善服務體系。
1.4.3.3 有利於發揮服務優勢
構造針對性的相關服務體系，建立起一個面向提供綜合性服務的網絡工作平臺，使企業各項工作有一個協調資源的共享管理平臺，有效降低企業運營成本的同時，提高為企業服務的效率，最大程度地發揮信息網絡和信息技術優勢，增強服務優勢。
1.4.3.4 有利於加強總和管理能力
經過多年的實踐，建築信息化已經有了長足的發展，在不斷完善的同時，並深刻地影響著相關企業運營的方式。
通過本項目的建設，將充分發揮信息技術和網際網路的快速方便和海量存貯的優勢，將企業服務工作與信息化緊密結合，解析管理操作細節化，加強數據之間的交互能力，讓管理數據化、流程化、節奏化，總和數據和管理之間的使用契合度，從而增強兩者之間的應用能力。
1.4.4 建築信息化的實施總則
系統全面採用瀏覽器技術實現，遵循BIM理念進行系統架構設計。
採用整體規劃，逐步實施的的原則。
充分考慮企業現有系統和平臺系統間的資料庫結構優化、接口的工作。
重點突破，根據企業實際需求，將首先選擇最主要的功能進行開發，起到以點帶面的效果。
涉及全局，把控項目全局架構，用多方面、多層次、多元化的思想來對項目進行整體合理的操控。
注重細節，在主要功能的基礎之上，建立起細節和主題相結合的概念，兩者相互協調，以達到契合的目的。
以簡代繁，用簡單易用的設計思想來完成複雜繁多的操作功能。
1.5 建築信息化技術的現狀1.5.1 建築信息化技術的發展現狀
針對BIM技術的核心，及建築信息的共享與轉換，國外的一些學者對基於BIM技術的建築信息平臺進行了研究，其中英國索爾福德大學的Faraj等人完成開發了基於BIM技術的WISPER（Web based IFC Share Project Environment）平臺，該平臺具備IFC文件在資料庫中存儲，工程的造價預算，顯示等功能；加拿大基礎設施研究中心（Centre for Sustainable Infrastructure Research）的Halfawy等人完成了基於BIM技術的建築集成開發平臺的開發、平臺具備圖形編輯、構建數量統計、預算、工程管理等功能。
在我國，一些學者也提出了關於基於BIM技術的建築信息平臺的構建。其中，清華大學的張建平等人，對基於IFC的BIM及其數據集成平臺進行了研究，實現了設計和施工階段不同應用軟體間的數據集成、共享和轉換；清華大學的趙毅立等人提出了下一代建築節能設計系統建模及BIM數據管理平臺研究，對下一代建築節能設計軟體系統研究的初期工作進行了研究。一些軟體公司也開始探索BIM管理平臺，如：廣聯達、魯班等算量公司在研究基於BIM的4D和5D模擬的BIM平臺。
以上平臺基本上都是基於單體項目或單個功能開發的，且沒有考慮城市道路工程對地理信息系統GIS的需求，隨著BIM技術快速發展以及與GIS技術融合的提升，結合市政項目長線型、周邊環境影響大等特點，需要研發BIM與GIS融合的協同管理平臺。
1.5.2 集團信息化的現狀分析
BIM近年來得到快速發展。在北美，BIM已被整個建築行業規範採納。
根據《McGraw-Hill Construction 2012》，北美建築業應用BIM技術的百分比，由2007年28%，2012年已達到71%。美國總務管理局GSA於2003年推出了國家3D-4D-BIM計劃 。
美國聯邦機構美國陸軍工程兵團USACE在2006年制定並發布了一份15年（2006~2020 年）的BIM路線圖 。
2009年起，包括威斯康辛、德克薩斯、俄亥俄等多個州政府宣布對州政府投資的設計和施工項目提出應用BIM技術的要求。
2011年英國開展的全國BIM調研中揭示的「主要進展」表明：31%的建築業專業人士正在使用BIM（2010年該比例僅為13%），78%的受訪者表示BIM是「項目創新的未來」。
2011年，英國標準學會（BSI）發布BIM實施戰略（BIM Strategy），要求所有政府項目5年內全部採用BIM。
在亞洲，2010年，日本的國土交通省宣布推行BIM技術。目前日本BIM應用已擴展到全國範圍，並上升到政府推進的層面。澳大利亞、香港、新加坡、韓國等地區國家也已經積極推進BIM技術應用多年。
多國都已相繼發布相關的標準、指南來指導BIM在具體的工程領域的實踐。美國國家建築科學研究院2007年起發布的NBIMS-US目前是全世界影響力最大的BIM標準；美國總務管理局及各州、英國、挪威、澳大利亞、新加坡、韓國、中國香港等均已建立自己的BIM標準和指南。
我國從2003年開始引進BIM技術，起初主要是在學術領域和民用建築，如XX世博場館、XX中心、XX迪斯尼樂園等大型項目。
而市政項目的BIM應用起步較晚，還是處於初步應用階段。
2012年XX軌道交通引入BIM技術，在11號線管線安裝施工過程中首次運用BIM技術進行三維管綜碰撞模擬，之後的12號線、13號，9號線三期中都局部和分階段採用BIM技術。
2013年底，市建管委將XX周家嘴路越江隧道工程作為BIM示範工程，研究在全壽命周期應用BIM的關鍵技術，建立隧道工程BIM應用的交付標準和實施標準，研究採用BIM技術對工程質量、進度、安全和投資等方面的輔助管理的具體應用。
二、承擔單位概況2.1 本集團承擔該項目的基礎條件XXX有限公司（以下簡稱本集團）擁有一支具有軌道交通設計專業背景、豐富研究應用經驗的BIM技術研發和諮詢管理團隊，目前已在XXX隧道、XXXX工程建設中承擔BIM諮詢管理的工作。
2.2 本集團承擔該項目的優勢2.2.1 強大的整合能力
依託隧道股份的整體優勢， BIM中心在應用推廣中，具有整合協同設計、施工信息管理、運營養護管理、遠程智能管理等多個平臺的隧道工程全壽命周期信息管理的能力和優勢，可結合集團的專家資源與創新平臺開展優質的BIM技術應用研究服務。
2.2.2 豐富的實踐經驗
本集團BIM中心從2009年開始BIM技術的前沿研究，擁有建築、結構、暖通、機電及信息技術等全專業人員60餘名，覆蓋建設工程各領域的BIM研究，如軌道交通、公路隧道、房建工程、路橋工程等各類工程項目。近三年中心獲得8個國家級BIM應用一等獎（見表4-3），主編和參編3項國家級和1項XX市級BIM標準。
2.2.3 豐碩的研究成果
本集團BIM中心先後承擔了XX市XXX隧道、XXXX工程的BIM諮詢管理工作，並完成了XXX隧道「XXXXX協同管理平臺」、XXXX工程「BIM+GIS信息管理平臺」的研發，其中XXXX工程「BIM+GIS信息管理平臺」的研發和應用成果受到了媒體的熱點關注和廣泛報導。
2.3 本集團所承擔的已有成果2.3.1 XXX隧道管理平臺
2.3.1.1 XXX隧道管理平臺概述
XXX隧道「XXXXX協同管理平臺」形成了虛實交互的建設期安全預控平臺、基於大數據的網絡傳感監控平臺、以「資產價值」為中心的建設運維一體化管理體系、基於BIM的工程驗收與竣工交付系統、隧道管片質量可追溯體系、基於BIM和GIS的全壽命管理平臺等成果，提升BIM技術在工程管理中的價值。
2.3.1.2 XXX管理平臺上線部署
2.3.1.3 XXX隧道項目完成形式
交付XXX隧道全壽命BIM竣工模型
建立基於BIM技術的隧道工程全壽命信息管理平臺
全壽命信息管理平臺硬體設備1套
全壽命信息管理平臺軟體1套
全壽命信息管理平臺操作手冊1份
制定BIM技術應用實施標準3項
XXX隧道項目BIM模型交付標準
XXX隧道項目BIM實施技術標準
XXX隧道項目BIM數據接口標準
隧道工程全壽命信息管理制度1套
研究報告1套
課題研究綜述報告1份
全壽命信息管理平臺研發技術報告1份
全壽命信息管理平臺測試報告1份
全壽命信息管理平臺工程應用報告1份
人員培訓手冊1套
2.3.1.4 XXX隧道項目考核指標
2.3.1.5 XXX隧道項目完成情況與成果
2.3.1.6 XXX隧道項目考核指標完成情況
三、總體技術規劃方案3.1 技術體系建設項目信息管理涉及業主方、設計單位、施工單位、運營管理單位、政府部門等眾多參與方，信息量巨大，信息交換複雜。而傳統的信息管理方式凌亂無序，信息利用率低。
因此基於BIM的信息管理框架的構建思路的核心就是要改變傳統的信息傳遞和共享方式，通過BIM將不同階段、不同參與方之間的信息有效地集成起來，真正實現建設項目全生命周期的信息管理。
因此，基於BIM的建設項目全生命周期信息管理框架的構建主要從以下三點展開：
（1）數據問題
建設項目信息管理過程中，產生的信息形式多樣，各參與方所用的信息管理軟體不盡相同。如何實現BIM數據和其他形式數據的共享和利用，保證不同階段產生的信息能夠持續應用，而避免重複輸入，就需要建立可以保證不同BIM應用之間的信息提取、關聯及擴展的資料庫，該資料庫也是基於BIM的信息管理框架的基礎。
（2）信息模型
資料庫是存儲信息的地方，而信息模型是承載信息的載體。隨著建設項目的進展，信息數據不斷增加，如何保證這些信息分門別類有效地存儲，需要在全生命周期不同階段，針對不同的BIM應用形成子信息模型，由各子信息模型來承載不同專業和類別的信息，以保證信息的有序。子信息模型通過提取上一階段信息模型中的數據，然後再經過擴展和集成，如此繼續反覆，最終形成全生命周期信息模型。
（3）功能實現
對信息進行存儲和管理的最終目的就是有效地應用信息，進行建設項目管理，因此，在管理框架的最上層為功能模塊層。不同的功能模塊對應著不同的BIM應用，也即為一個功能子信息模型。使用多種研發技術、中間件、設備搭建基於網際網路環境的輕量化BIM信息管理平臺；採用B/S架構構建平臺；具體通過以下技術實現：
基於OpenGL的三維模型引擎，集成BIM+GIS數據；
基於ActiveX的瀏覽器、移動端APP模型引擎部署；
基於關係型資料庫SQL Server的結構化構件數據存儲、檢索；
基於React的H5前端研發技術；
基於PHP的表單、流程處理功能開發；
基於MySQL的業務表單、流程數據存儲；
基於螢石雲的視頻監控中間件集成；
3.2 適應體系本系統將預留單點登陸接口，可適應系統的整體規劃採用用戶單一登陸控制方式，用戶在通過統一登錄驗證後，就可訪問相關管理信息系統，不需多次驗證導致不必要的麻煩。
單點登錄指用戶只需登錄一次，就可使用多個應用子系統，每一個子系統都可以進行數據共聯。這種單一的登錄點在整個系統的設計中是唯一認證用戶的地方，由登錄點將token（針對不同的應用可能還需要傳遞用戶名，口令）傳遞給應用子系統，應用子系統利用token來進行用戶已認證的驗證。
簡單地來說，就是要修改已有的應用子系統，屏蔽已有的應用子系統的用戶認證模塊，使用系統提供的API來驗證用戶，以及對用戶的操作進行授權。
通常，認證與授權管理模塊以一種應用專有的方式實現，系統的授權模型、認證，授權信息存貯結構與訪問控制邏輯與應用的業務邏輯之間耦合緊密。
這種設計與實現方式的缺點是顯而易見的：由於認證、授權模塊與應用邏輯之間的緊耦合使得認證、授權模塊很難進行擴展與維護；認證、授權模塊的設計與編碼需要很大的工作量，而且很難在不同的應用系統之間共享與重用。這也是越來越多企業應用需要的原因之一。
另外，除了設定的系統窗口進行登錄，本系統也設定了支持第三方窗口登錄的能力，其流程和特定的登錄窗口功能一致。
3.3 數據中心規劃思路結合資料庫技術思路，有效收集整理系統數據，為逐步實現知識管理和數據分析應用提供數據基礎依據。
作為一種理想的數據加工及存儲模式，數據中心的建立將為管理中心的數據整合及有效利用提供了基礎，為知識管理和決策分析應用提供數據支持。
3.4 兼容未來數據拓展管理平臺是一種使用極為頻繁的操作模式，可通過業務管理集成性的對後臺各數據進行訪問，包括各類統計報表的展現和傳遞，基於綜合辦公管理平臺的權限控制體系對各後端數據進行受控安全訪問和傳遞，與其他信息系統實現數據集成，互為補充，滿足集成的需求。
3.5 無縫銜接Web Service技術Web Services是一種能夠被描述並通過網絡發布、發現和調用的自包含、自描述、鬆散耦合的軟構件。
在Web Services體系中，所有的應用實體都被抽象成服務形式。
3.5.1 三個實體
（1）服務提供者（Service Provider）
從商務角度看它是指服務的所有者，從體系結構上看它是指提供服務的平臺。
（2）服務請求者（Service Requester）
從商務角度看它是指需要請求特定功能的企業，從體系結構上看它是指查找和調用服務的客戶端應用程式。
（3）服務代理（Service Broker）
它是指用來存儲服務描述信息的信息庫（Repository）。服務提供方在這裡發布他們的服務;服務請求方在這裡查找服務，獲取服務的綁定（Service Binding）信息。
3.5.2 三種操作
（1）查找
服務請求方根據註冊伺服器提供的規範接口發出查詢請求，以獲取綁定服務所需的相關信息。在查找操作中，一般包含兩種查找模式：
A. 瀏覽模式(Browse Pattern)：
服務請求方可以根據通用的分類標準來瀏覽或者通過一些關鍵字來搜索，並逐步縮小查找的範圍，直到找到滿足需要的服務，查找結果是一系列服務的集合;
B. 直接獲取模式(Drill down Pattern)：
通過唯一的關鍵字直接得到特定服務的描述信息，其查找結果是唯一的。
（2）發布
服務提供者需要首先將服務進行一定描述並發布到註冊伺服器上。在發布操作中，服務提供者需要通過註冊伺服器的身份驗證，才能對服務描述信息進行發布和修改。
（3）綁定（Binding）
服務請求方通過分析從註冊伺服器中得到的服務綁定信息，包括服務的訪問路徑、服務調用的參數、返回結果、傳輸協議、安全要求等，對自己的系統進行相應配置，進而遠程調用服務提供者所提供的服務。
3.6 技術路線3.7 平臺建設原則（1）擴展性
系統應便於新業務或者新功能的生成和實現第三方系統與平臺的連接。另外系統提供動態頁面定製組件，能夠有效的幫助運營方生成產品和服務表單，方便管理人員擴充分類目錄等信息，並在權限管理、用戶管理上有高度的靈活性、合理性。
（2）診斷性
通過詳細註冊資料的方式確保用戶身份的可靠性，線上實施管理操作時，需確認用戶的身份。為了防止操作失誤，應該將用戶的操作過程信息以日誌形式保存，以作為失誤診斷的原始依據。
（3）先進實用性
系統規劃和設計理念可對照現有技術先進、成熟的產品，提高用戶體驗，以減少系統開發的周期和成本；功能定位充分考慮平臺服務對象的需求。
（4）擴充性
保證企業內已有平臺和系統的兼容性及對未來發展的適應性，使系統可在原有的基礎升級改造和更新，並應當充分考慮技術進步因素的影響。
（5）開放性
平臺不是一個封閉的系統，今後必須通過接口和其他平臺或系統相連，在平臺建設中應充分考慮與外界信息系統交換的需求，保證既能滿足基本功能的需要，有具有與外界系統進行信息交換與處理的能力。
（6）安全性
在系統規劃和設計時應充分考慮系統安全性問題，防止非法操作和惡意入侵造成系統災難，給使用平臺的企業帶來損失。
（7）可靠性
平臺提供全年候不間斷服務，在系統規劃和設計時充分考慮系統可靠性問題，採用備份方案或其它管理和技術手段提高系統可靠性，避免由於系統崩潰而造成災難性後果。
（8）業務驅動性
項目實施以提供業務支持為首要因素。應從業務實際需要出發，選擇重點與關鍵的環節進行信息化管理與控制，在信息化價值和靈活性、管理工作量之間取得良好的平衡，保證在系統實施後能提高工作效率、降低成本。
（9）集成性
系統具有良好的集成性，對流程審批、數據獲取、信息集成等功能提供標準接口，以實現與其他相關系統的功能和數據集成。
（10）經濟性
系統應具備高性價比，能對系統資源的使用進行優化，在實現系統功能的前提下，儘量節省硬體資源的開銷。
（11）可伸縮性
要求在不用修改系統架構的情況下，通過增加或增強相應的設備即可實現系統功能的擴展支持，包括垂直擴展和水平擴展。
（12）縱向伸縮
能夠通過增加硬體資源提高目標平均性能和峰值性能（即響應時間、延遲等）及目標平均負荷和峰值負荷（即並發用戶、信息量等）。
（13）橫向伸縮
能夠通過增加應用伺服器及實現應用伺服器負載均衡、多節點等措施提高目標平均性能和峰值性能（即響應時間、延遲等）及目標平均負荷和峰值負荷（即並發用戶、信息量等）。
（14）可層次性
系統可以統一各個層次管理規範，統一數據結構、數據表達方式、數據訪問方式。
（15）可模塊化性
系統須提供通用的組件支持，能夠減少重複開發工作，保證產品和項目的質量，縮短應用系統的開發周期，有利於系統的擴展。在統一的數據環境下集成化開發各個模塊，模塊的劃分應獨立於當前的組織機構，各個模塊之間的數據交換是結構化的、公用的，從而也是高效的和完整的，最大限度消除冗餘和不一致。
（16）可交換性
系統應符合開放的原則，充分考慮各種業務需求有機結合，建立完善的系統整體構架，可與外部系統進行通訊並可提供標準的接口。既能實現業主業務，還可以完成數據交換、信息共享功能。
（17）可維護性
方案和產品的架構須緊密跟蹤國家信息安全、業主標準和國際主流技術標準，開放性好，便於系統的升級維護、以及與各種信息系統進行集成。
四、系統設計4.1 網絡拓撲結構系統結構基於Intranet/Internet 技術，以瀏覽器/伺服器結構的技術架構方式進行設計，系統必須支持主流計算機硬體及軟體平臺，併兼容現有的設備，支持多種開放技術標準，系統應提供標準的接口程序或和預留技術接口標準，便於擴展應用系統功能和與其他應用系統的互聯、互訪。
系統資料庫採用通用大型資料庫技術；充分考慮利用現有網絡和硬體設備；瀏覽器支持多種通用瀏覽器。
系統具有開放性、易操作性、界面的友好性、可靠性和安全性等特點，為用戶提供統一的、友好的操作界面。
4.2 總體結構設計採用現階段成熟的基於MVC的前後端分離的設計結構。
WEB SERVER接受用戶的訪問／數據請求，並建立起安全通道之後，根據不同的業務請求，由專門的對應系統進行處理；並且會根據不同的請求調用相應功能對資料庫進行訪問，並調用組件的方式處理相應的業務方面的操作流程；最後根據配置文件定義的結果顯示頁面，將系統處理結果傳輸到用戶端，從而實現了對用戶業務請求的處理。從而保證了邏輯的完整性和一致性。
表現層把結果以頁面的方式呈現給用戶，在本層中採用php技術進行實現。同時為更方便界面的修改，採用模板技術，模板是一些嵌有標識符的php頁面。以後頁面的修改只需懂php即可，無須修改其它。
在系統實現上，採用目前國際流行的面向對象技術、MVC的設計模式和純後臺語言技術，將整個系統從邏輯上分為展現層平臺、中間應用服務平臺和業務系統平臺等幾大部分，以提高整體網站系統的可擴展性、靈活性、易維護性。
4.3 架構規劃4.4 應用體系結構規劃4.5 門戶結構4.6 用戶訪問流程圖4.7 系統關鍵用例4.8 設計範圍4.9 資料庫設計建立完善的資料庫結構管理設備的基本參數、運行狀態和各種工作計劃。
資料庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平臺業務的基本情況和運行狀況，滿足運營管理信息化的要求。
4.10 對資料庫平臺的性能要求根據本系統數據的特點,採用標準SQL語句，以便將來的擴展和移植。
系統將採用資料庫建模工具，根據系統功能模塊的設計，構建出整個資料庫。在構建資料庫時，也會定義好資料庫表的約束、關聯以及索引。
針對系統的具體特點和系統要求，我們在進行資料庫方案設計時對資料庫平臺提出下列性能方面的要求：
標準化程度高，符合標準ANSI SQL 92語言的規範；
支持對稱處理和多線程技術，支持XML/CORBA，支持數據分區；
可在多種作業系統，HP、IBM等伺服器下運行，獨立性強，對系統結構影響比較小；
高級語言、漢化功能先進，易於方便使用，支持漢字，GB18030標準；
支持主流的網絡協議，如TCP/IP、IPX/SPX、NETBIOS、DECNET、SNA等。
能支持同構、異構網絡分布操作，支持鬆散耦合及海量並行處理；
有足夠的並發控制；授權控制和事務處理能力及恢復能力；
與異種數據源有良好的可互操作性；
具有可靠的數據安全保密措施以及故障恢復能力；
具有SMP和MPP功能，具有快速的並發用戶查詢速度，並發控制穩定可靠；
具有很強的容錯能力，錯誤恢復能力，錯誤記錄及預警能力，具備異地容災能力；
允許行級鎖，具有死鎖自動解出功能而無需額外的數據一致性校驗；
具有強大的複製能力，支持主從式、級連式、對等式以及N-向複製，並支持複製日誌技術，具有分布式模式管理能力；
具有完整的安全性（帳號安全，系統級權限，對象安全性，審計），細粒度化的訪問控制，適合於多層環境的安全模式的能力；
擁有支持MIS的功能強大的開發工具，提供數據倉庫和數據挖掘的工具。
4.11 資料庫系統結構設計根據本系統的結構和應用服務，同時考慮到整個系統的一體化方案、功能擴展和靈活性，資料庫將按以下原則採用集中方式與三層結構相結合的體系結構。
本系統是信息管理平臺系統，能夠提供多種應用服務，這些服務採用集中方式運行可充分利用伺服器的資源，發揮伺服器的性能，方便管理，提高可靠性。
採用三層結構很容易實現客戶機的擴充，使用多伺服器能減小系統的處理瓶頸，提高系統的性能，同時能共享網絡中的所有資源資料庫系統，為集中方式和B/S結構的應用提供了可靠的技術保證。
4.12 資料庫系統邏輯結構考慮到系統的總體要求和今後各業務的發展，本方案中設計資料庫系統邏輯結構體現了以下特點：
（1）資料庫系統結構具有良好的兼容性。
（2）資料庫數據的全面性：對平臺進行調查，分析及要求，最大限度的保證其共享數據，同時為系統的擴展性保留數據接口，達到數據全面性的目的。
（3）資料庫系統結構完全完整：既可最大限度開放的公用數據，也嚴格保密共享數據和企業私有數據，對不同的類型應採用不同的安全管理機制。系統將採用大型資料庫系統，完善的數據備份和安全控制策略，保證數據的安全性和完整性，保證系統安全運行。資料庫可以採用數據冗餘備份，或者數據錄像備份，雙機備份，以確保數據的安全及完整性。
4.13 資料庫設計遵循技術規範標準保證與其它應用系統的無縫連接，便於與運營方其它系統的數據共享和實施各方社會資源的數據共享。
4.13.1 完善的編碼體系
完善的編碼體系是資料庫系統的重要核心之一。要求對業務中涵蓋的信息進行全面分類和編碼管理。
要求編碼設計科學合理，使系統能夠具備目錄樹結構顯示、分類路徑明確、多級同步維護、分類分級的多層次查詢、數據傳送量少等優點。
4.13.2 字典驅動的資料庫結構
系統的發展變化對應於設備的屬性和設備的增減，能夠通過數據字典驅動的方式，在資料庫中實現設備屬性的擴展修改和新增設備的定義。
系統採用這種字典驅動資料庫結構，通過它用戶可以根據需要，對系統中某對象的屬性進行擴展。
例如應用在設備管理上，可以採用圖形化界面簡單直觀地實現設備類型的自定義、設備種類的增加、設備屬性的自定義，從而適應不斷出現的新設備的需要，不需要修改程序代碼。
4.13.3 面向對象的資料庫設計
資料庫設計的面向對象特徵最終奠定了整個系統的面向對象性，具體要求包括：
資料庫結構清晰，便於實現
資料庫對象具有獨立性，便於維護
需求變更時程序與資料庫重用率高，修改少
4.13.4 柔性擴展技術
資料庫系統賦予查詢系統高度的柔性和充分的可擴充性。
查詢系統可以根據用戶的需求不斷地完善自身，以提供新的查詢功能和增強查詢能力。它有兩方面的意義：
一是當系統運行一段時間後，用戶極有可能會產生新的查詢需求，在良好的數據結構的基礎上，能夠通過對原有系統的適當調整和配置，滿足用戶新的需求。
二是應用系統具備為不同類型的用戶提供自己定製各種查詢的功能，降低了系統後期的維護工作量和費用，保護系統的前期投資。
4.13.5 可攜式資料庫
系統提供可攜式數據管理功能，以便在無法或不願連通網絡的情況下使用相關的數據。
4.13.6 非結構化數據的管理
系統對非結構化形式存在的數據如文檔、手冊、 報告、意見等數據採用合理的資料庫管理模式。
系統將非結構化納入資料庫系統進行管理，從而將企業數據源和應用集成為一個有機整體，實現對數據的集中管理、組織、分類、索引和檢索，以達到對數值、字符等結構化數據和電子文檔、圖像、聲音等非結構化數據高效操作。
4.13.7 過程數據存儲管理
對一項業務流程從開始、中間各個環節到最後結束和反饋的整個過程中產生的數據進行完整的關聯存儲，這樣不僅在業務流程上完成閉環管理，在具體某項工作所產生的數據上面同樣完成了閉環管理，最終實現了業務真正意義上的閉環管理和監控的功能。
4.13.8 最簡單的就是最好的
客觀世界是錯綜複雜的,計算機科學理論的發展也越來越高深、複雜。然而,人類探索理論和技術的最終目的是:讓客觀世界的複雜變簡單,最簡單的就是最好的。為此對資料庫設計提出以下幾個要求：
4.13.9 備份管理
實現對系統所有數據的備份，包括圖形數據、屬性數據和規則庫數據，這些數據均存放在資料庫中，定期備份以保證數據的安全性。
五、系統功能需求5.1 系統總體結構5.2 功能設計5.2.1 工程可視化信息展示子系統
工程可視化信息展示子系統包括大體量BIM模型數據的在線高速展現、工程漫遊和綜合BIM信息查詢功能。
5.2.1.1 工程模型、周圍環境展示
將工程模型、全線周圍環境整合在平臺上，進行web瀏覽和漫遊，可以通過旋轉平移等簡單操作查看整個模型，並可通過模型樹快速點選構件，並可進行隱藏，亦可以通過剖面框、開洞等控制項對模型進行多角度多方位的查看。
5.2.1.2 BIM信息、市政管線信息查詢
將不同來源的各方數據匯總在統一平臺上，用戶根據權限查詢整個工程的相關設計、施工關鍵信息以及市政管線模型的查看。支持三維場景與屬性數據的雙向查詢，既可以通過輸入關鍵字查找設備並在三維場景中定位，也可以在三維場景中指定設備查詢相關屬性信息。
5.2.2 工程設計協同管理子系統
工程協同設計管理子系統的功能主要是建立設計各方之間和設計方與施工方之間的聯繫。主要包括BIM模型審核、成果管理、模型和圖紙關聯功能。
5.2.2.1 BIM模型審核
在設計變更管理中，如果出現圖紙需要更改的情況，則需要進行模型變更的申請，進入模型審核流程。BIM審核主要提供模型審核過程信息的上傳、流轉和審核流程。
5.2.2.2 成果管理
對設計方上傳的BIM成果進行管理，設計方BIM成果包括市政管線綜合、交通碰撞報告等應用成果，按照版本和類別進行管理和調用，方便資料的查找和整理。
5.2.2.3 模型和圖紙關聯
協同設計功能提供各家設計院的模型進行整合，檢查接口模型的正確性，同時可將設計文檔提供各版本模型和關聯圖紙的查詢和瀏覽。用戶可以查詢到各個版本的模型以及他們的相關圖紙並瀏覽。
5.2.3 工程建設協同管理子系統
工程建設協同管理主要是對施工進行進度、質量、投資和安全的全過程管理，使得各參與方不僅能夠全面了解施工狀態、而且能夠系統提升施工管理能力。
5.2.3.1 質量管理
質量分析主要以驗收數據為依據，圍繞部件、區域和時間展開分析，並給出結論和建議。系統將質量或檢驗報告與BIM信息模型相關聯，可以實時查詢任意WBS節點或施工段及構件的施工質量情況，並可自動生成工程質量統計分析報表，使相關人員能夠對工程質量問題進行查看及處理回復。
5.2.3.2 進度管理
進度分析利用WBS編輯器，完成施工段劃分、WBS和進度計劃創建，建立WBS與Microsoft Project的雙向連結;通過BIM模型，對施工進度進行查詢、調整和控制，使計劃進度和實際進度既可以用甘特圖表示，也可以以動態的3D圖形展現出來，實現施工進度的4D動態管理；可提供任意WBS節點或3D施工段及構件工程信息的實時查詢、計劃與實際進度的追蹤和分析等功能。
進度查看：列出施工計劃中各任務的計劃時間、實際時間、工程量以及完成進度，並用甘特圖的形式表示出來，用於查看詳細的施工進度情況。
計劃維護：導入施工進度計劃表，並能夠對實際施工時間進行維護。
進度報告：由施工單位每周進行實際施工進度的填報，內容包括每個構件的實際完成時間與實際工程量。
5.2.3.3 安全管理
安全分析主要以驗收數據為依據，圍繞部件、區域和時間展開分析，並給出結論和建議。系統將安全報告與BIM信息模型相關聯，可以實時查詢任意WBS節點或施工段及構件的施工安全情況，並可自動生成工程安全統計分析報表，使相關人員能夠對工程安全問題進行查看及處理回復。
5.2.3.4 投資管理
主要基於BIM模型自動生成工程量表，並可自動根據進度情況生成周、月、季度的工程量統計和指定時間段的工程量。並可以根據施工進度預測下一計算區間的工程量。
5.2.3.5 風險管理
平臺通過設置風險判定規則或相關人員手動錄入相關數據，針對不同風險源位置以及風險等級，標註相應的風險或安全標識；亦可實時展現工程風險狀態分布；相關人員也可以通過移動端拍照和定位功能，實現風險監察。
5.2.3.6 監測可視化
以BIM模型為基礎，將施工方、監理方以及第三方監測數據與4D信息模型相關聯，可以反映了當前工程安全狀況（危險區域和預警區域）、實時查詢任意施工段及周邊環境的安全情況，並可進行預警信息自動推送。
數據報表：能夠對各個監測點的監測數據按時間維度進行查詢，並生成分析圖表。
類型維護：對主題結構和周邊環境進行測點類型、閥值範圍、速率方面的維護。
監測組：將同一個監測項目的多個監測點綁定成為一個監測組，能夠同時對多個點的數據進行查看、分析與比較。
5.2.3.7 視頻監控
平臺通過與施工現場監控攝像頭的數據對接，能夠獲取即時的監控圖像，相關人員也能夠控制攝像頭的方向，實現通過平臺即能觀察施工現場的具體情況。
5.2.3.8 信訪管理
將12345、投訴信箱等投訴渠道獲得的針對工程各施工工地產生的投訴工單，根據來源、時間、工段、地區、類型進行分類統計並關聯模型，形成分析圖表，並且推送相關施工單位進行情況的核實與反饋，幫助指揮部對確實存在的問題進行監管與督促整改。
5.2.3.9 騰地管理
平臺通過相關人員錄入的騰地相關信息，對工程的騰地情況進行整理匯總，包括騰地的地點、所屬區屬、長度、面積等。並與模型相關聯，直觀反映騰地的完成情況以及未完成的原因。
統計報表：以圖表形式表現騰地完成百分比與各區域完成情況，並列出近期需要完成的騰地項目。
騰地列表：將騰地信息以列表形式表現，其中包含了騰地的所有信息。
地點維護：相關人員能夠對騰地信息進行錄入、修改、刪除等操作。
5.2.3.10 方案管理
平臺通過相關人員提供的方案，基於模型對方案進行模擬，可用於方案的展示、研究與比選。
5.2.3.11 管線搬遷
平臺通過相關人員提供的管線搬遷數據，基於模型對管線搬遷環境及方案進行模擬，可用於管線搬遷方案的展示、研究與比選。
5.2.4 工程運維管理子系統
工程運維管理系統的目標是為後期的運維提供一套完整的設施和設備信息，便於後期運營過程中使用。該系統包括設備管理、設施管理兩個部分。
5.2.4.1 設施管理
設施管理是將設施與BIM竣工模型關聯，授權用戶可以通過設施名稱、編碼、模型實體查詢與此設施關聯的所有設計信息、材料信息、施工過程關鍵信息和竣工驗收信息。
5.2.4.2 設備管理
設備管理是將設備與BIM竣工模型關聯，授權用戶可以通過設備名稱、編碼、模型實體查詢與此設備關聯的所有設計信息、材料信息、施工過程關鍵信息和竣工驗收信息。
5.2.5 系統管理
系統管理是實現所有功能的一個基礎模塊，包括模型管理、權限管理、知識庫管理和數據安全管理4個部分。實現模型和數據的傳遞、用戶角色的設置、數據的存儲和安全的保障。該系統對平臺所存儲的數據和平臺使用者進行管理，主要分為權限管理、模型管理、知識庫管理和數據安全管理四個部分，為用戶的平臺體驗及數據整合提供便捷。
5.2.5.1 權限管理
權限管理主要是對用戶設置個人帳號，保證平臺的安全性和用戶登陸的唯一性，並根據工程不同角色對用戶進行設置，可以使得相關參與方方便查找模型的責任方和參與人員，亦可對每個用戶設置權限，保證數據的快速、準確的調用以及數據的安全性。
5.2.5.2 用戶管理
該平臺擁有靈活的用戶體系，根據項目的實際需求，可創建不同的用戶多用戶角色，同時該角色可分配相應的操作權限。
5.2.5.3 權限配置
5.2.5.4 模型管理
5.2.5.5 知識庫管理
知識庫管理主要是根據模型的屬性信息，建立數據字典，方便用戶的查詢。整理歸檔資料，方便驗收時資料的調用，節省資料整理時間。
5.2.5.6 數據安全管理
數據安全管理主要是對數據進行備份，以防數據的損壞與丟失，並對數據進行加密，保證數據的安全性。
5.2.6 微信息溝通平臺可以通過移動端輕量化訪問平臺，並通過行動裝置隨時隨地記錄與推送各類信息，實現實時溝通和信息共享。
5.2.6.1 輕量化訪問
將平臺整體進行輕量化處理，用戶可以使用手機、平板燈行動裝置高效、快速、隨時隨地查詢瀏覽模型。
5.2.6.2 信息推送
用戶可以通過手機、平板等各種行動裝置隨時隨地記錄與推送包括文字、聲音、圖片、視頻等各類信息，實現在線實時溝通和信息共享。
5.3 網頁設計規範5.3.1 形象設計規範
5.3.1.1 logo圖標
5.3.1.2 標準色系
5.3.1.3 標準字體
網站定義一種標準字體（指logo上，圖片上使用的字體）；
標準字體原則上定義兩種，一種中文字體，一種英文字體 （不包括文本內容字體）；
提供標準字體的名稱和字庫；
儘可能使用標準字體；
字體應使用網站通用標準字體；
字體可以根據不同的等級（標題、副標題、正文）進行不同或者相同的設定；
杜絕錯字、別字和自造字；
數字符號（不含標點）均為半角。
5.3.2 內容編輯規範
5.3.2.1 標題
力求簡短、醒目、新穎、突出、合理、容易理解。
5.3.2.2 邊框、按鈕、列表、圖標
5.3.3 頁面尺寸
5.4 UI需求5.5 技術性能設計5.5.1 性能指標
5.5.2 相應時間
5.5.3 CPU與LAN的負荷率
5.5.3.1 CPU平均負荷率
系統穩定狀態：工作站<28%。
系統繁忙狀態：工作站<47%。
5.5.3.2 內存
系統穩定狀態：工作站<62M。
系統繁忙狀態：工作站<72M。
每5分鐘測試期間，系統LAN負荷不大於28%。
5.5.4 並發處理
並發處理用戶≥700人。
系統峰值響應速度，並發處理用戶≥500人。
5.6 接口設計通過調研分析企業既有信息系統的技術框架與數據格式，利用BIM模型作為各系統信息集成的載體，通過各類數據接口的開發，實現企業關鍵信息數據的整合、分析與展示，最終形成基於BIM技術的企業數據資產庫。
5.6.1 與工程可視化信息展示子系統的接口
採用WebService技術為工程可視化定義使用模式，實現BIM模型數據、工程漫遊、BIM信息三維信息查詢的相關操作。
5.6.2 與工程設計協同管理子系統的接口
採用WebService技術為工程可視化定義使用模式，通過此接口進行BIM模型審核、文件、模型和圖紙關聯方面的管理操作。
5.6.3 與工程建設協同管理子系統的接口
採用WebService技術為工程可視化定義使用模式，通過此接口進行進度、質量、安全、投資、風險、監測可視化、視頻監控、信訪、騰地、方案、管線搬遷方面的管理操作。
5.6.4 與工程運維管理子系統的接口
採用WebService技術為工程可視化定義使用模式，通過此接口進行設施和設備方面的管理操作。
5.6.5 與系統管理的接口
採用WebService技術為工程可視化定義使用模式，通過此接口進行權限、用戶、模型、知識庫、數據安全方面的管理操作。
5.6.6 與微信息溝通平臺的接口
採用WebService技術為工程可視化定義使用模式，通過此接口進行輕量化訪問、信息推送方面的管理操作。
5.6.7 與中心總和資料庫的接口
通過視圖等形式，為中心綜合資料庫提供相關的信息數據。
5.6.8 模塊級、系統級的數據交換
系統接口採用XML進行系統功能模塊和系統之間的模塊級別、系統級別的數據信息交換。
5.6.9 接口規範
在信息化建設過程中，由於行業特點和分步實施的原因，內部容易出現多個系統共存的現象，同時與應用相連的外部應用系統也在不斷增多。
各個信息系統之間需要進行數據和信息的集成，這對於在整個內部充分進行信息交互與共享、避免信息孤島的產生起著決定性的作用，在數據的一致性、規範性、業務效率的提高、的合理運營決策等方面也具有重要的意義。因此，建立和提供標準的接口規範，可以在不同系統之間搭建起溝通的橋梁。
不同系統間的數據和信息都以不同方式存儲和利用，基礎平臺和數據結構差別非常大，而且這些系統可能使用了完全不同的程式語言、作業系統、資料庫系統，對數據共享和利用造成很大的問題。因此，為了實現異構系統之間的互聯互通，必須遵循一定的規範，按照某種公共約定設計和實現特定接口。
為了有效地進行各系統間的數據交換，我們採用在各個系統中間，架設一個數據交換的中心節點，我們稱為數據交換平臺（Data Exchange Platform， 簡稱DXP）的解決方案。這個數據交換平臺將為提供一個支持信息流轉的數據總線， 通過DXP平臺的信息數據能夠在各個應用之間進行交換，從而使的應用完成業務上的協作。
通過採取這樣一個星型的統一接口模式，而不是讓多應用系統間進行點對點的反覆銜接，可以為系統間的數據交換帶來很多好處：
5.6.9. 1 有效地降低系統間的耦合度
每個應用系統邏輯上只和數據交換平臺有關係，而不必考慮數據交換另一端的具體部署，使系統間形成簡單的數據耦合，有效降低了系統間的耦合度。
5.6.9.2 提高數據交換接口的規範性
由於系統接口統一面向數據交換平臺，在接口的邏輯和技術形態上都具備一致性，這樣，就為系統接口的穩定和規範提供了基礎，有利於設計和實現一致和規範的接口。
5.6.9.3 提高數據交換的開放性
數據交換平臺就如同系統間的一個邏輯數據總線，可以對外提供靈活的多種形式的接口，讓系統很容易地集成進來，從而提高了數據交換的開放性。
5.6.9.4 保證數據交換的高效性和穩定性
5.6.9.5 保證數據交換的安全性
採用數據交換平臺後，系統間的數據交換可以完全受到平臺的控制，可以充分利用到交換平臺認證、授權、加密等安全性服務，從而有效地保證了數據交換的安全性。
5.6.9.6 提高數據交換的可擴展性
隨著系統需求的發展，一個數據交換過程往往不是固定不變的，當需求變化產生時，通過數據交換平臺定義（而非直接編程實現）的數據交換，可以很容易地進行修改和擴充，從而極大地提高了系統的擴展性。
六、平臺性能規劃方案6.1 安全性設計6.1.1 網絡安全性
網絡安全的建設目標要求針對網絡在將來實際運行過程中可能遇到的各種安全威脅，採用防護、檢測、反應、恢復四方面行之有效的安全措施，建立一個全方位並易於管理的安全體系，保障網絡能夠安全、穩定、可靠地運行，需要制定出安全體系的具體目標，以保證安全系統工程的實施。
主要的體現：
（1）提高可靠性
通過冗餘措施加以保證，具體包括線路冗餘、設備備份措施。
（2）防範與Internet互聯的安全威脅
在外網與Internet互連區採用安全可靠的防火牆。
（3）採用防病毒措施
在兩個方面防範：一方面建立完整的網絡防毒機制；另一方面建立嚴格完善的防毒管理規範。防範網絡服務的安全威脅確保必須的網絡服務的安全和可靠性。
如DNS；對其它網絡基本服務，限制使用範圍，建立嚴格的使用管理規定，防止被黑客利用，絕對禁止匿名FTP服務，對需要使用又必須保證安全的場合，要經過身份認證、訪問授權和審計記錄機制的控制。
（4）阻止黑客攻擊
在兩個方面防護：一方面在Internet互聯區域及與內網互連區域設置防火牆。另一方面採用防黑客攻擊軟體：
（5）保障網站內容安全
防止網站數據被非法篡改，並且在被篡改後能及時恢復。
6.1.2 系統安全性
6.1.2.1 硬體安全
機房環境：保障溫度範圍為20-25℃，溼度範圍為40-55%，防止電子設備失靈。
電力設施：採用雙路強點引入，防止單一線路損壞導致斷電；採用UPS系統，防止突然停電或電壓不穩導致設備損壞。
報警監控設施：安裝火災報警系統，實現實時報警。同時安裝了煙感報警系統，實時對煙霧進行探測。
設備情況：本系統應用時為1臺資料庫伺服器，1臺場景應用伺服器，1臺應用伺服器。但是，同時配置另外3臺備份伺服器，防止伺服器的損壞，並能夠及時進行系統的切換和數據遷移。
安全管理制度：安全管理制度包括：
設立信息安全崗位，由專人負責；
建立伺服器日常維護及管理制度
機房值班安全制度；
防火牆等軟體更新制度；
應急處理流程；
6.1.2.2 軟體安全
用戶系統：平臺擁有靈活的用戶體系，根據項目的實際需求，可創建不同的用戶多用戶角色，同時該角色可分配相應的操作權限。用戶需要通過身份認證才能登錄平臺。
權限管理：對應用系統的所有資源進行權限控制，根據用戶所在角色，判斷用戶是否擁有訪問、操作權限。
接口安全
數據校驗設計
軟體容錯：目前系統異常處理機制有分為三種：
用戶輸入錯誤，這類錯誤在用戶進行操作遞交時會做出校驗處理，並提示用戶錯誤所在，由用戶自行修改輸入的錯誤。
系統對操作界面產生的錯誤信息給予明確的提示，或彈出對話框，提示用戶該步驟操作出現錯誤，並且指明具體的錯誤之處，方便系統維護人員及時找出問題所在，解決此錯誤，保證系統運行正常。
客戶端異常問題，主要體現在打開的控制項提示。系統會提示用戶按照正確的步驟去解決該類錯誤，或者請求運維人員根據提示的步驟進行操作解決客戶端異常問題；
6.1.2.3 數據安全
6.1.3 操作安全性
操作安全性由網絡登錄驗證、資料庫登錄驗證、應用系統使用驗證三級組成。網絡登錄驗證由作業系統完成，用於對具有網絡資源訪問權限用戶的驗證；資料庫登錄驗證由資料庫伺服器完成，用於對具有資料庫訪問權限用戶的驗證；系統使用驗證由應用系統完成，用於對具有應用系統使用權限用戶的驗證；應用系統將採用三種驗證方式相結合的方式驗證用戶。
6.1.4 數據傳輸安全性
為保證數據傳輸的安全性，使得所傳輸數據不被盜竊、更改，應用系統所採集的重要原始數據可採用網絡加密傳輸、資料庫加密傳輸或應用系統數據加密相結合的技術。
6.1.5 數據存儲安全性
重要數據因某種原因需用存儲介質進行長期備份存儲時，可採用加密算法對數據進行加密，使得非法用戶不能理解其含義，當合法用戶訪問時再將其還原。
6.1.6 採用日誌
採用日誌的形式，對進入系統的用戶的操作進行記錄，包括合法用戶的操作和非法用戶的嘗試性登錄；可以根據日誌進行事後分析，從而找到事故的發生原因、責任者或非法用戶。
6.1.7 系統維修時的數據安全性
當系統需要檢修或維修時，有可能對系統進行調試，在調試時我們將採用切換到臨時運行環境的方法，使系統在調試時與正式存儲設備（資料庫）隔離，維修結束正式使用時，再將系統與正式存儲設備（資料庫）相連接。這樣就可以保證系統在維修時已有數據的安全。
6.1.8 原始數據的安全性
為了保證原始數據的原始性，原始數據一旦保存，便不能被更改；對錯誤數據只能採取增加一條記錄來修正的方式處理，對修正數據應加標誌以保證正確性，同時對於修正操作應做數據修正日誌，記錄修正人相關信息及修正原因等。
6.2 風險管理方案6.2.1 風險分析
建議按下面的公式評估風險：
風險規避的優先級 = 風險係數×風險的影響程度
其中，風險係數為風險發生的概率。影響程度為風險發生後所導致的後果的嚴重程度，分為四個級別：
一級風險（致命的）：致命的指導致項目不能在一定的時間、成本範圍內，按照客戶的需求完成；
二級風險（嚴重的）：對項目進度、成本或質量產生重大的影響，有使項目失敗的可能，但可以通過某種方式得以彌補，而避免失敗的結果。採用該方式需要付出較大代價；
三級風險（一般的）：項目進度、成本或質量有影響，但影響力度相對較輕，基本上不致使項目失敗，可以通過適當措施彌補或糾正，但要付出一定的代價；
四級風險（可忽略）：項目進度、成本或質量的影響輕微，不會使項目失敗，做輕微調整就可以彌補或糾正。
優先級分為高、中、低三級，分別對應著計算數值大於等於1.5（C≥1.5）、小於1.5且大於等於0.8（0.8≤C＜1.5）和小於0.8（C＜0.8）的情況。
對於中、高級的風險（風險優先級≥0.8），應該考慮該風險對當前項目計劃執行的影響，並根據實際情況，調整項目計劃的相關內容。
6.2.2 常見風險
本項目在系統需求沒有詳細全面確定的情況下，我們建議項目組能夠借鑑如下常見風險，及早採取有效措施，確保項目成功。
6.2.3 應對措施
在風險分析之後，項目經理對概率和影響程度制定風險應對計劃。
風險應對計劃分為規避、減緩和應急計劃。在規避、減緩、接受和應急計劃中，項目經理寫明計劃中相關的人員、時間（對應急計劃可以不需要）、具體行動等。計劃制定後，相關人員必須嚴格依照執行。在制定風險應對措施時，如涉及到資源、成本、進度變更等問題，報請項目經理提供支持，並啟動配置變更管理過程。
規避：通過分析找出發生風險事件的原因，消除這些原因來規避一些特定的風險事件發生。
6.2.4 風險跟蹤
在制定和執行風險應對計劃之後，跟蹤所有被標識風險的狀態和應對計劃的執行情況，並將規避/減緩計劃的執行情況以及風險發生時採取的應急計劃的執行情況，記錄在項目風險表中的計劃執行情況欄目中，直至被標識風險的狀態為Close。
6.2.5 狀態通報
根據當前風險項目的狀態以及正在形成的風險的信息隨時更新修改風險列表，並把它作為項目月總結報告的一部分提交項目總經理。
對於風險處理優先級比較高的風險，要以最快的速度，用書面或口頭形式通報項目總經理。
6.2.6 風險資料庫
在子系統開發關閉時，子項目經理負責向質量部提交相關風險數據，在通過風險資料庫維護人員的評審後，更新項目風險資料庫。
6.3 可靠性設計數據需在整個分布式資料庫系統中保持一致，我們將採取以下幾種措施來保證這些數據的一致性：
利用關係資料庫管理系統（RDBMS）的一致性檢查與控制機制；
關係資料庫管理系統（RDBMS）具有一套嚴格的數據完整性和一致性的管理機制。
採用版本控制技術，即對每一類需同步的數據設置其版本號，在用戶登錄系統或系統進行處理時（若要用到這些數據），則系統先判斷其是不是最新版本，若不是最新版本，則對這些數據進行更新（以原始資料庫的數據為基礎），保證系統所用的數據為最新數據，同時也保證了各級數據的一致。
在操作平臺運營中，需要傳輸大量的數據，因此，保證數據傳輸的正確性就顯得尤為重要，即使在網絡通訊不可靠或出現異常時也能保證信息的傳輸。
6.4 存儲解決方案本平臺是以建立大額在線管理作業系統為目的的，對於這麼一個系統，數據的安全、高效存儲是系統建設的重中之重。
6.4.1 系統的數據存儲特點
6.4.2 軟硬結合的存儲方式
鑑於系統的複雜程度，單純依靠資料庫自身的備份功能，不足以保證系統的災難恢復能力；系統的數據量對普通的硬碟、乙太網等，在容量和性能上也是一個考驗；因此，我們建議採用軟硬結合的方式：
6.5 容災備份設計保證業務持續性的重要手段是提高信息系統的高可靠性，需要建設一個對各種情況都可以抵禦或者化解的異地的容災系統。
容災系統的核心就在於將災難化解：
數據的安全需要保證用戶數據的完整性、可靠性和一致性。數據安全是容災系統的基礎，也是容災系統能夠正常工作的保障；業務連續性是容災系統的建設目標，它必須建立在可靠的數據備份的基礎上，通過應用系統、網絡系統等各種資源之間的良好協調來實現。
為了建立高可靠性的系統，如機房破壞等重大自然災害，需要建立異地災難備份中心，用戶將本地備份的數據送到遠離本地的地方保存抵禦災難。災難發生後，按預定的數據恢復程序購置和安裝備份硬體平臺，恢復系統和數據即可。實現數據的異地複製，有軟體方式和硬體方式兩種途徑。軟體方式，是通過主機端軟體來實現，如遠程卷複製或者資料庫廠家提供的遠程數據備份工具來實現業務數據的遠程複製。
建立一個異地的數據系統，該系統是生產中心關鍵應用數據的一個複製。複製可以通過硬體——磁碟陣列的同步技術；也可以通過軟體——遠程卷鏡像和資料庫遠程複製工具。確保在生產中心發生災難時，生產數據在備份中心仍然可用，可以採用硬體（磁碟陣列）或軟體方式來實現。
建立一個集本地、異地數據和應用容災於一體的方案，最大限度的保證數據的一致性，容災級別依次提高，後者以前者為基礎，可以分步實施，後期保護前期投資，能夠支持人工/自動容災的方案，用戶可以根據需要自由選擇,是災難備份設計方案的目標和出發點。
6.6 軟硬體建設方案6.6.1 網絡系統
6.6.1.1 伺服器端採用阿里雲
伺服器端採用阿里雲伺服器，需要安裝sql server2008 R2，IIS，asp，.net等軟體及組件。現有單項目阿里雲伺服器配置如下：
通過對阿里雲伺服器增加配置的方式實現企業級應用。
則每增加一個北橫同等體量的項目，按照新增24M帶寬、擴容linux伺服器、windows伺服器的CPU、內存、數據盤，新增費用如下：
則每新一個項目，新增費用22071.1元。
6.6.1.2 伺服器端採用物理機
伺服器端採用物理機，優點在於一臺物理機可以同時開闢多臺虛擬機用於多個項目，在伺服器承載能力滿足的情況下，不需要每年再付費。但是物理機需要獨立IP，可能存在網絡帶寬不穩定、供電不穩的問題，由於地域原因，不能隨時觀察伺服器狀況。同時，伴隨著項目的增多，伺服器的負荷也會升高，運維成本增大。一旦承載能力超出負荷，則不能再自由擴展原有物理機的配置。
物理機配置：
Linux虛擬機的配置：
Windows虛擬機的配置：
理論上，一臺物理機，可以搭載北橫同等體量的6個項目。
6.6.1 客戶端軟硬體環境
6.7 實用性設計6.7.1 可維護性
本方案中選用多層結構體系作為應用系統開發的核心技術，使得開發的應用系統具有非常好的維護性和功能擴展能力。
應用軟體的維護和升級，只需要更新伺服器中的應用程式就可以達到維護和升級的目的。
6.7.2 可操作性
系統管理和操作將全部採用圖形化交互式人機界面，具有數據處理操作簡單、方便、快捷。對業務流程的處理，完全按照常規的處理習慣，充分考慮到人員的操作習慣。
6.7.3 多功能性
系統可向各類用戶提供各種指標報表；能根據不同的要求靈活處理報表指標，提供靈活自由的、功能強大的組合查詢手段和統計功能。
提供多種分析方法，如餅圖、曲線圖、柱圖、表格等。通過資料庫與Web的集成，對工作人員、管理機構提供功能強大的綜合查詢和統計服務及Web服務訪問功能。
6.7.4 高效性
採用高效的伺服器、功能強大的資料庫系統，為各種業務提供高效率的工作能力，適應大規模數據處理的要求。
6.8 可擴展性設計本方案選用多層結構體系作為系統開發的核心技術，就充分考慮到本系統的業務變化和擴展的實際情況，使得開發的應用系統具有非常好的維護性和功能擴展能力。
採用標準和通用的網絡設備及協議，採用開放式的資料庫平臺和組件技術，採用兼容性強的電子郵件系統，確保隨著平臺的成長，已有的資源的有效性。
6.9 靈活性設計6.9.1 高度的模塊化設計
採用高內聚、低耦合原則進行模塊劃分。模塊間提供相應的接口，當應用系統的業務或功能要求發生變化時，可以通過簡單的對相應模塊的修改來實現功能擴展。
6.9.2 多層體系結構
多層體系結構分為客戶端、應用伺服器和資料庫伺服器。其中，客戶端提供統一的用戶界面，完成對用戶請求的收集與結果顯示；應用伺服器主要是處理用戶請求，實現應用系統功能；資料庫伺服器則是為應用伺服器提供數據。基於這樣的體系結構，更有利於功能擴展與修改。
6.10 容錯性設計系統的容錯性設計是指設計軟體時能夠保證用戶輸入的正確性和對系統非法的和破壞性的輸入有很強的容錯能力。
當用戶進行正常的數據輸入時，系統對輸入的數據要做有效性檢查和完整性檢驗，保證將正確的數據存入資料庫，對於用戶錯誤的輸入，不但拒絕接受，而且要給出明確的錯誤提示，供操作者改正；對於用戶輸入非法的和對系統具有破壞性的數據，系統能夠加以識別，並做出相應的處理，避免造成系統的死機和癱瘓。
6.11 快速恢復設計在系統使用過程中，由於硬體出現故障或其它原因造成系統暫時性的中斷後系統重新啟動時，能夠保證系統將原有的數據快速恢復，使繼續運行下去。
在資料庫設計時，有軟體自動（默認）或人工對重要的數據進行定期的備份，並做有備份日誌，系統的功能中專門設計數據備份和恢復功能，使用戶能夠快速地自動地將數據從故障處恢復。
在系統正常運行時，定期地將資料庫中的數據備份到磁帶機，在系統硬碟裡保存一段時間內的數據（如5年），如果超出這個時間區段，則將超出時間區段的數據全部導出到磁帶機上保存，避免資料庫裡的數據過於龐大，也保證數據的安全。當用戶查詢以前的數據超出當前硬碟存儲的數據範圍，則隨時從磁帶機中調出相應時間段的資料庫供使用。
6.12 方案設計特點6.12.1 基於體系結構的服務標準
遵循體系結構規範的、適合於分布式異構環境的標準服務平臺。通過管理信息系統信息化建設系統提供的標準服務，為用戶提供辦公支持。
6.12.2 基於XML標準的數據交換標準
通過應用XML技術，規範當前管理信息系統信息化建設系統資料庫的數據標準，從而實現應用之間的互聯互通。
6.12.3 中間件技術
系統採用的中間件技術使得中間業務邏輯層能夠很方便的維護和二次開發,同時使系統能夠讓用戶方便地進行WEB的報表列印。
6.12.4 基於WEB的多級審批
通過WEB方式，既可以部署在專網，也可以部署在網際網路，通過中心機房集中數據、應用，其他各方用戶無需重複建設，只需通過終端PC即可使用。
6.12.5 支持複合流程
從數據獲取到數據展示的主體流程，也支持數據查詢和數據刪除、修改的辦公子流程。
6.12.6 信息高度的電子化
本系統信息的高度電子化，所有項目信息都完全上網錄入，文檔化數據則以附件方式上傳，從而保障了辦公的真正高效和數據統計的及時與科學性。
6.12.7 工作流技術
本系統採用工作流技術方便各個用戶了解自己當前的任務和每個事物處理進展情況,加強了用戶的使用方便性。
6.12.8 界面的靈活定製和組件化
由於採用了組件式模塊化開發，保證了技術核心不修改的情況下，操作界面的可快速定製，有效滿足用戶的個性需求。
6.12.9 報表的多種格式
本系統能以Excel文檔等不同文件格式輸出文件。
七、項目質量管理保障方案項目質量管理包括執行組織確定質量政策、目標與職責的各過程和活動，從而使項目滿足其預訂的需求。項目質量管理在項目環境內使用政策和程序，實施組織的質量管理體系；並以執行組織的名義，適當支持持續的過程改進活動。項目質量管理確保項目需求，包括產品需求，得到滿足和確認。
一個項目只有實現高質量的信息系統建設，才能為信息系統的有效運行提供基礎，才能保證信息系統發揮應有的經濟效益和社會效益。因此，信息系統集成的質量控制是十分重要的，只有實施嚴格的質量控制，才能真正實現信息系統的質量建設目標，保證信息化建設的投資回報。
為實現平臺系統的全面質量控制，在項目啟動階段，一方面要明確確定進行軟體質量控制的人員；另一方面要制定全面的軟體質量保證計劃。在軟體開發過程中，通過有效的質量評審機制，使軟體質量得到有效的保證和跟蹤。
7.1 質量管理的各過程7.1.1 質量管理的各過程概述
項目質量管理各過程，包括：
規劃質量管理：識別項目及其可交付成果的質量要求和/或標準，並書面描述項目將如何證明符合質量要求的過程。
實施質量保證：審計質量要求和質量控制測量結果，確保採用合理的質量標準和操作性定義的過程。
控制質量：監督記錄質量活動執行結果，以便評估績效，並推薦必要的變更的過程。
上述過程不僅彼此作用，而且還與其他知識領域中的過程相互作用。
項目質量管理需要蛟骨項目管理與項目可交付成果兩個方面。它適用於所有項目，無論項目的可交付成果具有何種特性。質量的測量方法和技術則需專門針對項目所產生的的可交付成果類型而定。
無論什麼項目，未達到質量要求，都會給某個或全部項目干係人帶來嚴重的負面後果：
7.1.2 質量與等級的區別
質量與等級不是相同的概念：
項目經理及項目管理團隊負責權衡，一邊同時達到所要求的的質量與等級水平。質量水平未達到質量要求肯定是個問題，而低等級不一定是個問題：
7.1.3 精確度和準確度
項目管理團隊應該在質量管理計劃中合理地確定將要達到的準確水平和精確水平：
可用射箭進一步說明。箭頭密集在靶子的一個區域（即便不在靶心），就具有很高的精確度。箭頭分散但到靶心的距離相等，就具有相同的準確度。箭頭密集在靶心內，就是既準確又精確。精確的測量未必準確，準確的測量未必精確。
7.1.4 質量管理方法的重要性
在與ISO保持兼容性的前提下，現代質量管理方法力求縮小差異，交付滿足既定要求的成果。
現代質量管理方法承認一下幾個方面的重要性：
客戶滿意：了解、評估、定義和管理要求，以便滿足客戶的期望。這就需要把「符合要求」（確保項目產出預定的成果）和「適合使用」（產品或服務滿足實際需求）結合起來。
預防勝於檢查：質量應該被規劃和設計，並且在項目的管理過程或可交付成果生產過程中被建造出來（而不是被檢查出來）。預防錯誤的成本通常遠低於在價差或使用中發現並糾正錯誤的成本。
持續改進：由休哈特提出並經戴明完善的計劃——實施——檢查——行動（PDCA循環）是質量改進的基礎。另外，諸如全面質量管理（TQM）、六西格瑪和精益六西格瑪等質量管理措施，也可以改進項目的管理質量及項目的產品質量。常用的過程改進模型包括馬爾科姆·波多裡奇模型、組織級項目管理成熟度模型（OPM3）和能力成熟度集成模型（CMMI）。
管理層的責任：項目的成功需要項目團隊全體成員的參與。然而，管理層在其質量職責內，肩負著為項目提供具有足夠能力的資源的相應責任。
質量成本(CQQ)：是指一致性工作和非一致性工作的總成本。
一致性工作：侍衛預防工作出錯而坐的附加努力。
非一致性工作：是為糾正已經出現的錯誤而坐的附加努力。
質量工作的成本在可交付成果的真箇生命周期中都可能發生。項目結束後，也可能因產品退貨、保修索賠、產品召回而發生「後項目質量成本」。由於項目的臨時性及降低後項目質量成本所帶來的潛在利益，發起組織可能選擇對產品質量改進進行投資。這些投資通常用一致性工作方面，以預防缺陷或檢查出不合格單元來降低缺陷成本。此外，與後項目質量成本有關的問題，也應該成為項目集管理和項目組合管理的關注點，以便項目、項目集和項目組合管理辦公室專門開戰審查，提供模板和分配資金。
7.2 規劃質量管理7.2.1 計劃編制
確定項目的範圍、中間產品和最終產品，然後明確關於中間產品和最終產品的有關規定、標準，確定可能影響產品質量的技術要點，並找出能夠確保高效滿足相關規定、標準的過程方法。
7.2.2 輸入、工具與技術、輸出
質量規劃應與其他規划過程並行開展。
圖7.4 規劃質量管理：輸入、工具與技術和輸出
7.2.2.1 輸入
項目管理計劃：被用於制定質量管理計劃。用戶自定質量管理計劃的信息包括：
範圍基準：
項目範圍說明書：包括項目描述、主要項目可交付成果及驗收標準。產品範圍通常包含技術問題細節及會影響質量規劃的其他事項，這些事項應該已經在項目的規劃範圍過程中得以定義。驗收標準的界定可能導致質量成本並進而導致項目成本的顯著增加或降低。滿足所有的驗收標準意味著發起人和客戶的需求得以滿足。
工作分解結構（WBS）：WBS識別可交付成果和工作包，用於考核項目績效。
WBS詞典：提供WBS要素的詳細信息。
進度標準：記錄經認可的進度績效指標，包括開始和完成日期。
成本基準：記錄用於考核成本績效的、經過認可的時間間隔。
其他管理計劃：這些計劃有利於整個項目質量，其中可能突出與項目質量有關的行動計劃。
干係人登記冊：有助於識別對質量有特別興趣的那些干係人。
風險登記冊：包含可能影響質量要求的各種威脅和機會的信息。
需求文件：記錄項目應該滿足的、與干係人期望有關的需求。包括（但不限於）項目（包括產品）需求和質量需求。這些需求有助於項目團隊規劃將如何開展項目質量控制。
事業環境因素：可能影響規劃質量管理過程的事業環境因素包括（但不限於）：
政府法規；
特定應用領域的相關規則、標準和指南；
可能影響項目質量的項目或可交付成果的工作條件或運行條件；
可能影響質量期望的文化觀念。
組織過程資產：
7.2.2.2 工具與技術
（1）成本效益分析
答道質量要求的主要效益包括減少返工、提高生產率、降低成本、提升干係人滿意度及提升盈利能力。對每個質量活動進行成本效益分析，就是要比較其可能成本與預期效益。
（2）質量成本
包括在產品生命周期中為預防不符合要求、為評價產品或服務師父符合要求，以及因未達到要求（返工），而發生的所有成本。失敗成本常分內部（項目內部發現的）和外部（客戶發現的）兩類。失敗成本也成為劣質成本。
其中基本質量工具：也稱7QC工具，用於在PDCA循環的框架內解決與質量相關的問題。
（3）因果圖又稱魚骨圖或石川圖
問題陳述放在預估的頭部，作為起點，用來追溯問題來源，回推到可行動的根本原因。在問題陳述中，通常把問題描述為一個要被彌補的差距或要達到的目標。通常看問題陳述和問「為什麼」來發現原因，知道發現可行動的根本原因，或者盡每根魚骨圖上的合理可能性。要在被視為特殊偏差的不良結果與飛隨機原因之間建立聯繫，魚骨圖往往是行之有效的。基於這種聯繫，項目團隊應採取糾正措施，消除在控制圖中呈現的特殊偏差。
對於複雜的項目，編制質量計劃時可以採用因果分析圖，描述相關的各種原因和子原因如何產生潛在問題或影響，將影響質量問題的「人員、設備、參考資料、方法、環境」等各方面的原因進行細緻的分解，方便地在質量計劃中制定相應的預防措施。其次，質量計劃中還必須確定有效的質量管理體系，明確質量監理人員對項目質量負責和各級質量管理人員的權限。
（4）流程圖也稱過程圖
用來顯示在一個或多個輸入轉化成一個或多個輸出的過程中，所需要的步驟順序和可能分支。它通過映射SIPOC模型的水平價值鏈的過程細節，來顯示活動、決策點、分支循環、並行路徑及整體處理順序。流程圖可能有助於了解和估算一個過程的質量成本。通過工作流的邏輯分支及其相對頻率，來估算質量成本。這些邏輯分支，是為完成符合要求的成果而需要開展的一致性工作和非一致性工作的細分。
（5）核查表，又稱計數表
適用於手機數據的查對清單。它合理排列各種事項，以便有效地手機關於潛在質量問題的有用數據。在開展檢查以識別缺陷時，用核查表收集屬性數據就特別方便。用核查表收集的關於缺陷數量或後果的數據，又經常使用帕累託圖來顯示。
（6）帕累託圖
是一種特殊的垂直條形圖，用於識別造成大多數問題的少數重要原因。在橫軸上所顯示的原因類別，作為有效的概率分布，涵蓋100%的可能觀查結果。橫軸上每個特定原因的相對頻率逐漸減少，直至以「其他」來涵蓋未致命的全部其他原因。在帕累託圖中，通常按類別排列條形，以測量頻率或後果。
（7）直方圖
是一種特殊形式的條形圖，用於描述幾種趨勢、分散程度和統計分布形狀。與控制圖不同，直方圖不考慮時間對分布內的變化的影響。
（8）控制圖
用來確定一個過程是否穩定，或者是否具有可預測的績效。根據協議要求而制定的規範上限和下限，反應了可允許的最大值和最小值。超出規範界限就可能受處罰。上下控制界限不同於規範界限。控制界限根據標準的統計原則，通過標準的統計計算確定，代表一個穩定的過程的而自然波動範圍。項目經理和干係人可基於計算出的控制界限，發現採取糾正措施的檢查點，以便預防非自然的績效。糾正措施旨在維持一個有效過程的自然穩定性。
（9）散點圖，又稱相關圖
標有許多坐標點（x,y），解釋因變量y相對於自變量x的變亮。相關性可能成正比例（正相關）、負比例（負相關）或不存在（零相關）。如果存在相關性，就可以畫出一條回歸線，來估算自變量的變化將如何影響因變量的值。
（10）標杆對照
標杆對照是將實際或計劃的項目實踐與可比項目的時間進行對照，以便識別最佳實踐，形成改進意見，並為績效考核提供依據。作為標杆的項目可以來自執行組織內部或外部，或者來自同一應用領域。標杆對照也允許用不同應用領域的項目作類比。
（11）實驗設計
DOE是一種統計方法，用來識別那些因素會對正在生產的產品或正在開發的流程的特定變亮產生影響。可以在規劃質量管理過程中使用，以確定測試的數量和類別，以及這些測試對質量成本的影響。DOE也有助於產品或過程的優化。它用來降低產品性能對各種環境變化或製造過程變化的敏感度。該技術的一個重要特徵是，它為系統地改變所有重要因素（而不是每次只改變一個因素）提供了一種統計框架。通過對實驗數據的分析，可以了解產品或流程的最優狀態，找到顯著影響產品或流程狀態的各種因素，並揭示這些因素之間存在的相互影響和協同作用。
（12）統計抽樣
是指從目標總體中選取部分樣本用於檢查，抽樣的頻率和規模影子啊規劃質量管理過程中確定，以便在質量成本中考慮測試數量和預期廢料等。其擁有豐富的知識體系。在某些應用領域，項目管理團隊可能有必要熟悉各種抽樣技術，以確定抽取的樣本能代表目標總體。
（13）其他工具
頭腦風暴：用於產生創意的一種技術。
力場分析：顯示變更的推力和阻力的圖形。
含義小組技術：先由規模較小的群體進行頭腦風暴，提出創意，再由規模較大的群體對創意進行評審。
質量管理和控制工具：對已識別的活動進行相互關聯和排序的一組工具。
會議：
項目團隊可以召開規劃會議來制定質量管理計劃。參會人員可以包括項目經理、項目發起人、選定的項目團隊成員、選定的干係人、負責項目質量管理活動（規劃質量管理、實施質量保證或控制質量）的人員，以及需要參加的其他成員。
7.2.2.3 輸出
（1）質量管理計劃
是項目管理計劃的組成部分，描述將如何實施組織的質量政策，以及項目管理團隊準備如何達到項目的質量要求。可以是正式或非正式的，非常詳細或高度概括的。其風格與詳細程度取決於項目的具體需要。應該在項目早起就對質量管理計劃進行評審，以確保決策是基於準確信息的。這樣的好處是，更加關注項目的價值定位，降低因返工而造成的成本超支金額和進度延誤次數。
（2）進程改進計劃：過程改進計劃是項目管理計劃的子計劃或組成部分。過程改進計劃詳細說明對項目管理過程和產品開發過程進行分析的各個步驟，以識別增值活動。需要考慮的方面包括：
（3）質量測量指標
質量測量指標專用於描述項目或產品屬性，以及控制質量過程將如何對屬性進行測量。通過測量，得到實際數值。測量指標的可允許變動範圍成為公差。
（4）質量核對單
核對單是一種結構化工具，通常具體列出各項內容，用來核實所要求的一系列步驟是否已得到執行。基於項目需求和實踐，核對單可簡可繁。許多組織都有標準化的核對單，用來規範地執行經常性任務。在某些應用領域，核對單也可以從專業協會或商業性服務機構獲取。質量核對單位該涵蓋在範圍基準中定義的驗收標準。
項目文件更新：
7.3 實施質量保證7.3.1 輸入、工具與技術、輸出
7.3.1. 1 輸入
質量管理計劃：描述了項目質量保證和持續過程改進的方法。
過程改進計劃：應該支持並符合執行組織的過程改進。
質量測量指標：提供了應該被測量的屬性和允許的偏差。
質量控制測量結果：是質量控制活動的結果，用於分析和評估項目過程的質量是否符合執行組織的標準或特定要求。質量控制測量結果也有助於分析分析這些測量結果的產生過程，以確定實際測量結果的正確程度。
項目文件：可能影響質量保證工作，應該放在配置管理系統內監控。
7.3.1.2 工具與技術
質量管理和控制工具：過程使用規劃質量管理和控制質量過程的工具和技術，除此之外，還包括：
親和圖：親和圖和心智圖相似。針對某個問題，產生出可聯成有組織的想法模式的各種創意。在項目管理中，使用親和圖確定範圍分解的結構，有助於WBS的制定。
過程決策程序圖（PDPC）：用於理解一個目標與大成此目標的步驟之間的關係。PDPC有助於制定應急計劃，因為它能幫助團隊預測那些可能破壞目標實現的中間環節。
關聯圖：關係圖的變種，有助於在包含相互交叉邏輯關係（可有多達50個相關項）的中等複雜情形中創新地解決問題，可以使用其他工具（諸如親和圖、樹形圖或魚骨圖）產生的數據，來繪製關聯圖。
樹形圖，也稱系統圖：可用於表現諸如WBS、RBS（風險分解結構）和OBS（組織分解結構）的層次分解結構。在項目管理中，樹形圖依據定義嵌套關係的一套系統規則，用層次分解形式直觀地展示父子關係。樹形圖可以是橫向（如風險分解結構）或縱向（如團隊層級圖或OBS）的。因為樹形圖中的嵌套分支都終止於單一的決策點，就可以像決策樹一樣為已系統圖解的、數量有限的依賴關係確立預期值。
優先矩陣：用來識別關鍵事項和何時的備選方案，並通過一系列決策，排列出備選方案的優先順序。先對標準排序和加權，在應用於所有備選方案，計算出數學得分，對備選方案排序。
活動網絡圖過去成為箭頭圖：包括兩種網絡圖：AOA（活動箭線圖）和最常用的AON（活動節點圖）。活動網絡圖連同項目進度計劃編制方法一起使用。
矩陣圖：一種質量管理和控制工具，使用矩陣結構對數據進行分析。在行列交叉的位置展示因素、原因和目標之間的關係強弱。
質量審計：是用來確定項目活動是否遵循了組織和項目的政策、過程與程序的一種結構化的、獨立的過程。質量審計的目標是：
採取後續措施糾正問題，可以帶來質量成本的降低，並提高發起人或客戶對項目產品的接受度。質量審計可事先安排，也可以隨即進行；可由內部或外部審計師進行。
質量審計還可以確認已批准的變更請求（包括更新、糾正措施、缺陷補救和預防措施）的實施情況。
過程分析：是指按照過程改進計劃中概括的步驟來識別所需的改進。它也要檢查在過程運行期間遇到的問題、制約因素，以及發現的非增值活動。過程分析包括根本原因——用於識別問題、探究根本原因，並制定預防措施的一種具體技術。
7.3.1.3 輸出
變更請求：可以提出變更請求，並提交給實施整體變更控制過程，以全面考慮改進建議。可以為採取糾正措施、預防措施或缺陷補救而提出變更請求。
項目管理計劃更新：
質量管理計劃；
範圍管理計劃；
進度管理計劃；
成本管理計劃。
項目文件更新：
組織過程資產更新：
可能需要更新的組織過程資產包括（但不限於）組織的質量標準和質量管理系統。
7.4 控制質量和保障控制質量過程使用一系列操作技術和活動，來核實已交付的輸出是否滿足需求，在項目規劃和執行階段開展質量保證，來建立滿足干係人需求的信心；在項目執行和收尾階段開展質量控制，用可靠的數據來證明項目已經達到發起人和/或客戶的驗收標準。
7.4.1 控制質量
7.4.1.1 輸入
項目管理計劃：包含質量管理計劃、用於控制質量。將如何在項目中開展質量控制。
質量測量指標：描述了項目或產品屬性及其測量方式。包括功能點、平均故障見個時間（MTBF）和平均修復時間（MTTR）。
質量核對單：是結構化清單，有助於合適項目工作及其可交付成果是否滿足一系列要求。
工作績效數據：
實際技術性能（與計劃比較）；
實際進度績效（與計劃比較）；
實際成本績效（與計劃比較）。
批准的變更請求：在實施整體變更控制過程中，通過更新變更日誌，先是那些變更已經得到批准，那些變更沒有得到批准。批准的變更請求可包括各種修正，如缺陷補救、修訂的工作方法和修訂的進度計劃。需要核實批准的變更是否已得到及時實施。
可交付成果：是任何獨特並可核實的產品、成果或能力，最終將成為項目所需的、確認的可交付成果。
項目文件：
協議；
質量審計報告和變更日誌（附有糾正行動計劃）；
培訓計劃和效果評估；
過程文檔；
組織過程資產：
組織的質量標準和政策；
標準化的工作指南；
問題與缺陷報告程序及溝通政策；
7.4.1.2 工具與技術
統計抽樣：按照質量管理計劃中的規定，抽取和測量樣本。
檢查：是指檢驗工作產品，以確定是否符合書面標準。檢查的結果通常包括：相關的測量數據。檢查可在任何層次上進行。檢查也可稱為審查、同行審查或巡檢。在某些應用領域，這些術語的含義比較狹窄和具體。檢查也可用於確認缺陷不久。
審查已批准的變更請求：對所有已經批准的變更請求進行審查，以何時他們是否已按照批准的方式得到實施。
7.4.1.3 輸出
質量控制測量結果：是對質量控制活動的結果的書面記錄。應該以規劃質量管理過程。
確認的變更：對變更或補救過的對象進行檢查，做出接受或拒絕的決定，並把決定通知干係人。被拒絕的對象可能需要返工。
核實的可交付結果：控制質量過程的一個目的就是確定可交付成果的正確性。開展控制質量過程的結果，是核實的可交付成果。核實的可交付成果是確認範圍過程的一項輸入，以便正式驗收。
工作績效信息：是從控制過程收集，並結合相關背景和跨領域關係進行整合分析而得到的績效數據。
變更請求：如果推薦的糾正措施、預防措施或缺陷補救導致需要對項目管理計劃進行變更，則應按照既定的實施整體變更控制過程的要求，提出變更請求。
項目管理計劃更新：
項目文件更新：
組織過程資產更新：
7.4.2 控制原則
7.4.2.1 事前控制原則
整個平臺建設是一個高技術、高投入的建設過程，任何由於質量問題引起的工程變更必然產生巨大的投資浪費和工期拖延。所以，在信息系統集成過程中應該始終堅持質量的事前控制原則。堅持事前控制原則的關鍵在於準確了解用戶需求，科學地進行信息系統設計。
7.4.2.2 標準原則
目前信息領域已經形成一系列的標準，總的來說，信息領域的標準可以分為：
這些標準為我們建設高質量的信息系統提供了科學的依據。
因此，在信息系統集成過程中，應該根據信息系統的特點，遵循有關國內外的相關標準進行系統集成，保證集成過程的科學性。
7.4.2.3 階段性控制原則
根據用戶的具體需求，系統地設計和實現系統，因此，它是一個創新的過程。
由於信息系統集成的過程性，這就決定了信息系統的質量控制應該是階段性的，不可能一蹴而就。換句話說，質量控制應該分階段實施；應該根據系統的質量總目標形成各個工程階段的質量目標和具體的質量控制措施，通過實現各階段的質量目標來完成整個系統的質量目標。
7.4.2.4 定型測試和量化測試相結合原則
由於信息系統特殊性，絕大多數的驗證過程是無損的，應該大力提倡使用信息系統的驗證手段來保證信息系統的質量，測試是信息系統驗證的重要手段之一。
籠統地說，信息系統測試可以分為定性測試和量化測試。
定性測試主要用於系統的功能測試，而量化測試主要用於系統的性能測試，這兩種手段可以從不同角度反映信息系統的質量。
7.4.2.5 用戶需求複合型原則
衡量信息系統質量的一個重要尺度是用戶需求的符合程度。
建成的信息系統應該符合用戶的業務功能需求、性能要求和使用習慣要求等。
檢驗用戶需求符合度的主要方法是科學的測試，可以通過測試手段來判定用戶需求的符合程度。
7.4.3 控制影響因素
7.4.3.1 全面地、系統地了解用戶需求
定義清晰的用戶需求是整個系統成敗的關鍵。
要採用科學的方法從事用戶需求的調查，這種需求調查不僅應該包括單位管理者和系統維護者意見，而且應該包括最終用戶的意見，從而保證用戶需求的完整性；同時為了保證用戶需求的準確性，用戶需求的制定過程應該使用迭代的方式，通過反覆徵詢用戶的意見，逐步完善用戶需求。
7.4.3.2 充分討論系統設計方案
系統設計方案描述了被建系統的抽象模型，因此設計方案的科學性和合理性對被建系統的質量具有極其重要的影響。因此，系統設計方案應該進行充分討論，提高系統設計的質量。其中，系統設計過程中應該注意：用戶需求的符合性、技術成熟性和先進性、系統的安全性、系統的可擴展性、所選產品的質量符合性、法律法規的符合性等。
7.4.3.3 設計完整的系統驗證方案
在系統設計階段，根據用戶需求書和系統設計方案，制定完整的系統驗證方案。
信息系統的驗證方法主要包括：模擬仿真的方法和測試的方法。設計現場測試方案時應該充分考慮用戶需求的符合性。
7.4.3.4 確定可行的質量控制方案
為了保證系統實施的質量，依據系統設計方案制定一套可行的系統質量控制方案，以便有效地指導系統實施過程。該質量控制方案應該確定系統實施各個階段的質量控制目標、控制措施、工程質量問題的處理流程、系統實施人員的職責要求等。
7.4.3.5 形成表述規範的設計文檔
為了保證系統實施的可操作性和系統的可維護性，設計文檔應該採用規範的表述形式。
例如：我們採用標準建模語言UML（Unified Modeling Language）描述軟體設計方案，利用甘特圖（Gantt Chart）描述工程進度安排等。
7.4.3.6 遵循科學的實施流程和技術要求
系統實施過程應該遵循科學的流程和有關技術要求，堅持按照標準的實施流程完成系統的建設。
系統實施流程應只與系統的需求和類型相關，而不能因人而異。
7.4.3.7 合理進行階段性測試
系統實施的各個階段應該遵照質量控制方案的要求，分階段地進行系統測試，逐步地實現質量控制目標。
對用戶系統維護人員的培訓及建立完整的工程實施文檔也是保證信息系統集成質量的重要內容。
7.4.4 控制具體措施
7.4.4.1 技術保障措施
本項目是一個技術要求高、系統需求複雜的系統工程，需要由具有一定的計算機水平（包括計算機硬體、計算機網絡和計算機軟體），精通業務並能將其計算機規程化，對計算機軟體應用技術和工程有著豐富經驗，具有組織過大型項目或工程經驗等的各類人員組成的項目組。為了保證項目的順利完成，技術保障主要包括計算機軟體技術和業務應用兩個方面。
技術方面：
應用方面：
按照業務流程進行軟體模塊編制，儘量使現有徵集模式與軟體應用相一致。同時保持模塊間的低耦合，保證其獨立性、安全性、可靠性。
具體業務數據採集系統與統計分析，對決策支持系統進行分層次設計，保證數據的正確性、可靠性。
按照管理層次編寫數據接口，保證數據傳輸和處理過程的正確性和實時性。
在程序設計時，保持用戶界面友好、風格一致，提供完善的功能鍵和聯機幫助信息。
建立完整的測試環境，主要是設計一套軟體測試數據，減少現場調試和測試的工作量，保證軟體產品的可靠性。
制定完善的培訓計劃。
7.4.4.2 管理保障措施
（1）工程化開發
項目的開發是一項系統工程，必須按照系統工程的規律組織系統開發，必須建立嚴格的系統工程控制方法，要求開發組的每一個人都要嚴格遵守開發規範，以質量控制為核心，緊緊抓住軟體開發的各個主要環節，規範開發過程中的全部活動。
（2）變更控制與階段性凍結
一個軟體項目的每一個階段都有明確的任務和成果，在每個階段結束，都要通過軟體配置管理以「凍結」部分成果，作為下一階段開發的基礎，凍結之後不是不能修改，而是修改一定要經過一定的審批程序，並且涉及到項目計劃的調整。
（3）加強階段性確認、驗證和評審
通過驗證、確認、評審，實現項目的技術把關，避免軟體人員在工作中的隨意性和不負責任現象，從不同側面確認系統的正確性、協調性完整性等。
（4）面向用戶參與的原型演化
特別注意用戶的參與。在需求階段，必須使開發人員與用戶進行全面深入的溝通，以明確用戶的需要究竟是一個什麼樣的系統。在設計階段和測試過程中，要有用戶參與，及時獲取用戶的反饋信息；利用原型與用戶交互，根據用戶的反饋，不斷改進設計。
（5）全面測試
系統測試是把住軟體質量的關鍵關口。在系統開發的各個階段，要採用適當的手段，依據系統需求規格說明書，對系統設計，實現和相應得文檔進行全面的測試。
7.4.4.3 質量保障措施
質量好壞是評判本項目是否成功的一個標誌。
在本項目實施的前期，項目組將會根據PMP質量管理的有關規範，參照我公司的《質量手冊》、《程序文件》、《軟體產品及編寫企業標準》和國家《軟體開發文檔規範》，制定項目開發過程中的一系列規範。並由用戶方專家組組和我公司的軟體測試中心予以控制，建立質量保障體系。
開發過程規範：
項目開發過程和管理規範
項目文檔和符號使用規範
總體方案設計開發規範
軟體設計開發規範
軟體編程規範
資料庫設計規範
軟體測試規範
軟體維護規範
制定軟體測試的詳細計劃，對模塊測試、集成測試、系統測試和交驗測試的各個過程進行控制，保證軟體質量處於受控狀態。在測試的過程中，建立一套完整的測試數據，使之儘可能包含典型數據、邊界條件、誤操作等，使軟體的可靠、強壯性達到設計要求和應用要求。
為了保證項目開發過程的可追溯性，按照軟體編制規範要求，形成如下文檔，從另一個方面保證軟體的質量。
開發過程中相關文檔：
需求分析：包括業務流程和總體方案
概要設計說明書
詳細設計說明書
資料庫設計說明書
用戶手冊
操作手冊
測試計劃
測試分析報告
項目開發總結報告
八、項目建設與費用預算8.1 項目建設內容本項目將以GIS和BIM三維空間模型為載體，將工程全生命周期的過程信息整合在一起，通過信息傳遞和交換平臺，打破工程中不同階段、不同專業、不同角色之間的信息溝通壁壘，實現信息的準確傳遞。並以此為基礎，建立工程協同管理平臺，圍繞規劃期、設計期、施工期、運維期的核心管理目標，使管理人員能夠通過快速、形象、便捷的信息入口，進行工程全生命周期協同和智慧管理，改變市政行業傳統管理和運營模式，提升市政工程的質量和效益。
8.2 建設規模項目投資總計劃額為1100萬元。
8.3 項目投資估算項目計劃投資總額為1100萬元，其中企業自籌資金917萬元，申請本次資助經費183萬元。總投資包括：硬體設備購置費23.5萬元，軟體購置費35.5萬元，軟體開發費1038萬元，審計費3萬元。
8.4 項目建設周期項目建設周期為兩年，2015.8.1~2017.7.31。
九、集團建BIM協同管理平臺實施策略規劃9.1 集團BIM協同管理平臺實施流程9.1.1 基於裡程碑的迭代式開發過程模型
9.1.1.1 項目的實時控制
9.1.1.2 四個裡程碑
前景／範圍認可（Vision／Scope Approved）裡程碑。
項目設計認可（Project Plan Approved）裡程碑。
範圍完成／第一次應用（Scope Complete／First Use）裡程碑。
系統發布（Release）裡程碑。
四個裡程碑是用戶與項目組之間重要的設計、評估和協調的同步點。
9.1.2 風險控制的時間進度
風險控制的時間進度安排是指在項目中風險程度高的部分優先開發的方法。無論是軟體開發項目還是基礎信息設施實現項目，風險控制的時間進度安排都很重要。
9.1.3 全面質量管理控制
全面貫徹質量體系標準和CMM軟體生產過程標準，嚴格執行國家有關軟體工程的設計規範，建立相應的質量和進度保證體系。
9.1.3.1 測試
9.1.3.2 質量保證
9.1.4 實施步驟
對於該系統，我們確定了如下的系統實施步驟：
成立項目組織機構
制定實施計劃
準備各種數據
系統開發和用戶化
功能模擬運行
培訓操作人員
系統實際運行
系統升級和維護
9.1.5 進度計劃
9.1.5.1 各階段節點目標
9.1.6 各參與方職責
9.1.7 責任人
9.1.7.1 項目負責人簡介
張三，教授級高工，現任本集團總工程師。曾獲得中國鐵道學會科學技術獎一等獎、山西省科學技術二等獎、山西省科技進步「金牛獎」先進個人一等獎、XX市優秀工程諮詢成果獎一等獎、國家級企業管理現代化創新成果二等獎、XX市管理創新一等獎，撰寫並通過認定的國家級工法1項、省部級工法2項，主持過多項隧道與地下工程科技項目研究。現主要從事城市道路隧道工程前期方案研究、設計管理、施工技術管理及建設管理工作。
9.1.8 組織保障
9.1.8.1 人員組織保障
為確保本項目按研究預期方向推進，擬成立項目推進協調組。由XX城投公路集團指定集團總工劉豔濱為項目負責人，XXXX工程所屬的第三事業部總工、和項目指揮部的各相關職能部門都派專人參加本項目建設。將要求軟體開發單位的項目經理、BIM諮詢方、設計方、施工方、監理方等所有BIM參與方均指派代表加入項目建設，組建一個緊密的項目團隊。
9.1.8.2 制度保障
在項目研究過程中，建立制度保障措施，確保研究團隊與參與方溝通順暢、各項節點目標按時、保質完成。
每周例會：每周召開一次日常工作例會，匯報工作進展，安排工作分工，時刻把握科研工作進展；
月度例會：每月召開一次月度分析例會，分析近階段工作總體進展及存在的問題，及時制定解決方案，並重點安排下階段的工作要點；
節點例會：按項目研究的進度計劃及節點目標需要，召開節點例會，詳細部署、緊抓進度、及時歸納，全面掌控各節點目標的進展和完成情況；
重點例會：根據項目研究開展過程中的重大問題、關鍵節點的實際需求，召開重點工作推進例會，動員和部署相關工作重點，確保項目研究按時、保質完成。
協調例會：根據業主方及項目推進實際需求，定期召開項目推進工作協調例會，與各參與方建立良好的溝通，及時協調各參與方的工作要點及計劃安排，確保項目順利開展。
9.2 項目管理工作9.2.1 制定進度計劃
制定進度計劃用於展示平臺實施過程中活動之間的關聯，以及計劃日期、持續時間、裡程碑和所需的資源。
橫道圖：概括性進度計劃，相對易讀，用於展示各活動持續時間，用於向集團、事業部管理層匯報平臺實施進展情況。
裡程碑圖：僅標示出主要可交付成果的計劃開始或完成日期，有助於對平臺關鍵節點的開發、測試在進度上進行把控。
項目進度網絡圖：詳細進度計劃，包含時間刻度和活動之間的邏輯關係，用於諮詢單位跟蹤在整個平臺實施過程中的每個活動的進展情況。
9.2.2 質量保證
在平臺實施過程中反覆進行測試，收集測試數據，發現潛在的質量問題並查到到問題的根本原因。
9.2.3 文檔管理
文檔編寫：
開發文檔，用於描述開發過程本身，包括：可行性研究報告和項目任務書；需求規格說明；功能規格說明；設計規格說明；開發計劃；測試計劃；質量保證計劃等。
產品文檔，用於描述開發過程的產物，包括：培訓手冊，參考手冊和用戶指南；軟體支持手冊；產品手冊等。
管理文檔，用於記錄項目管理的信息，包括：開發過程中的變更的記錄；開發團隊的職責定義等。
制定文檔規範：
9.2.4 變更管理
建立項目基準、變更流程和變更控制委員會。
（1）基準管理
基準是變更的依據，首先制定初始基準，此後在平臺實施過程中，針對每次批准的變更重新確定基準。
（2）建立變更控制流程
建立平臺實施過程中需要的變更管理流程，所有變更都必須遵循這個流程進行控制。流程的作用在於將變更的原因、專業能力、資源運用方案、決策權、干係人的共識和信息流轉等元素有效地綜合起來，按科學的順序進行變更。
（3）建立變更控制委員會
建立變更控制委員會並明確其職責，明確變更流程中相關工作的角色及其職責。變更委員會是一個正式的組織，負責審查、評價、批准、推遲或否決項目變更。變更控制委員會由項目所涉及的多方人員共同組成，應當包含集團和事業部的決策人員。
9.2.5 信息安全管理
保密性，確保所傳輸的數據只被其預定的接受者讀取。確保數據的保密性的技術包括：
完整性，確保接收到的數據就是發送的數據。確保數據的完整性的技術包括：
可用性，確保數據在需要時可用。確保數據可用性的技術包括：
磁碟和系統的容錯
可接受的登錄及進程性能
可靠的功能性的安全進程機制
數據冗餘和備份
9.3 集團BIM協同管理平臺實施目標將BIM技術應用貫穿設計、建設和運維全階段，結合GIS、web等技術搭建一個大型市政工程全生命周期協同管理平臺，實現信息集成、共享、更新和管理，保證信息的一致性，實現各參與方的協同交流、信息共享，實現對整個項目的動態控制，為管理和決策提供幫助，提升工程設計、施工的管理水平，減少返工浪費，縮短工期，提高工程質量和投資效益。
以構建「特大型城市道路工程基於BIM全生命周期協同管理平臺」為核心，建立工程參建各方的信息網絡和信息流動機制，結合計算機技術、BIM技術、數據分析技術，通過基於BIM的中心資料庫建設及工程協同管理技術的研究，形成一套可在工程建設行業內複製推廣的成套信息技術體系。
具體完成以下目標：
9.4 項目的團隊與領導為了項目的順利進行，必須建立完善、嚴密、高效的項目組織機構，以在項目實施的各個階段，項目各個小組協同工作，使系統保質保量的按期投入運行，圓滿完成系統的開發設計任務。
9.4.1 團隊結構
9.4.2 領導小組
9.4.3 協調小組
9.4.4 質量管理小組
質量管理貫穿整個項目生命周期的各個階段。軟體開發單位的軟體質量計劃和計劃的執行情況由項目領導小組或委託項目協調小組負責監督審核。
9.4.5 需求分析小組
9.4.6 系統設計小組
9.4.7 軟體開發小組
9.4.8 系統測試小組
9.4.9 文檔整理小組
9.4.10 系統培訓小組
9.4.11 系統維護小組9.5 項目培訓方案9.5.1 培訓策略及方式
9.5.1.1 培訓的重要性
培訓是系統實施的重要環節，是系統應用的第一步。通過對參與項目系統決策和實施人員的進行全方位培訓，能夠提前分析與控制項目的實施風險，統一思想，正確理解和應用平臺系統的實施方法和實施過程。
通過培訓，平臺管理人員將深入了解本系統的開發背景、技術資料、開發思路，使其能夠得心應手地做好日常管理和維護工作，保證系統的安全、穩定運行。通過培訓，操作人員可以正確理解相關的業務流程，熟練掌握各個子系統的詳細操作。
9.5.1.2 培訓的過程和重要方法
對平臺應用系統開發項目的培訓將貫穿項目實施的全過程，可分為實施中培訓和實施後培訓兩個階段：
前一階段培訓主要目的在於讓參與培訓人員熟悉系統的業務流程、掌握系統管理的使用方法，以正確理解本平臺的管理思想、實施方法論，掌握管理與控制項目風險的具體方法。
後一階段的培訓主要目的則是讓參與培訓人員學習系統的詳細操作方法，掌握正確組織系統所需的靜態和動態數據的方法；並且結合實施過程中出現的各種問題，對相關人員進行強化培訓，使用戶真正應用好系統中的管理思想，實現技術和管理各個層面知識的轉移，最終培養出屬於自己的系統管理維護團隊。
9.5.1.3 培訓類型
培訓主要分為系統應用和系統管理，這兩種培訓在培訓內容和培訓要求方面是有很大差異的，因此，在整個項目培訓過程中，針對不同的應用系統、不同的機構人員情況，所關注的培訓重點也是不一樣的。
9.5.1.4 培訓方式
集中授課模式（一對多培訓）
現場培訓
個別操作指導
一對一培訓
9.5.2 培訓計劃
培訓時間：培訓是項目實施的重要環節之一，詳細的培訓時間安排請參見實施計劃。
另外，項目實施過程中，本集團會重點培訓項目的主要技術人員和業務骨幹。在實施過程中，逐步把用戶業務骨幹和操作人員的二次培訓交給技術人員和實施小組成員負責，形成企業自己的培訓隊伍體系。
9.5.3 培訓質量考核
為了保證培訓質量，每次培訓都有必要的考核。考核有下列方式：
9.5.4 培訓組織要求
項目過程中的各種系列培訓是實施工作的重要內容之一。培訓的效果與質量直接影響到本系統的正常使用與管理。為確保達到培訓的目標本集團對這個平臺應用系統開發項目制定了完善的項目培訓組織與要求，通過培訓可以為平臺應用系統的順利實施打好堅實的基礎。
系統開發項目培訓組織與要求：
項目雙方各指定專人負責培訓的全面組織工作，通常由項目經理擔任。
培訓負責人負責安排培訓教師，教師提前準備好講義和教材，建好培訓環境，準備考試試題。
培訓期間所有學員須嚴格按照《培訓計劃》的安排參加培訓，如對培訓工作有任何疑問，須向負責人反映，由雙方負責人協調解決各種問題。
培訓負責人有責任維護好課堂正常秩序，嚴格課堂紀律，做好培訓出勤記錄。
所有學員必須按時完成教師布置的各項作業。
培訓結束雙方共組織閉卷考試，所有參加培訓人員必須參加，考試期間不得有任何形式的舞弊行為。
培訓結束後企業與河南迪富將對本次培訓進行集中總結，並將總結內容向對方通報。
9.5.5 培訓提交文檔
9.5.6 其它培訓方式
信息服務平臺建設
災難恢復計劃與業務持續經營
信息化諮詢
網絡安全知識與應用
軟體項目的研發與管理規範
其它需要的培訓
上述培訓可以根據具體需要，自由選擇，不是項目實施所必須。
9.6 系統移交項目的建設應嚴格按照系統工程理論和方法實施。
整個系統實施過程應建立完整的資料檔案：
一方面可保證系統實施具有系統性，編程的設計具有規範性，不會因為程式設計師的變化影響到系統的改造開發；另一方面可保證系統移交的正常完成；再一點有利於系統移交後的版本升級二次開發等的順利實現。
為保證系統移交後，系統的正常運行，我公司將為企業培訓出幾名合格的系統管理員。保證系統管理員能完成獨立進行系統的日常維護，獨立進行各種系統設置工作，能夠獨立解決系統運行中出現的各種問題（非程序問題），能夠獨立進行對應用人員的培訓工作。以保證我公司技術服務人員階段撤離後不影響整個系統的運行。
各種文檔資料的移交，包括：
完整的系統需求定型報告；
完整的系統設計分析定型報告；
完整的資料庫結構設計資料；
實施過程中的修改意見及修改說明；
各種雙方協調工作的備忘錄。
9.7 評審驗收評審和測試一樣，是系統質量保證的又一措施。軟體評審的通過，一方面用於淨化軟體工程的各項活動，同時也標誌著我公司在此階段工作的勝利完成及用戶對其功能/質量的認可。
我們認為，在軟體改造開發的各個階段都可進行評審。如：對系統需求分析定型、系統重要功能模塊的修改等。系統試運行結束後應組織使用單位人員對軟體工程的系統建設進行全面的評審驗收。
9.7.1 評審方面
功能、邏輯和實現上有無缺陷。
是否符合用戶需求。
是否按照指定的工具和方法加以開發。
效率如何。
文檔是否齊全。
在各個局部範圍是否已經試用成功。
其它
9.7.2 驗收項目
9.7.2.1 功能項測試
對軟體需求說明書中的所有功能項進行測試；
9.7.2.2 業務流程測試
對軟體項目的典型業務流程進行測試；
9.7.2.3 容錯測試
9.7.2.4 安全性測試
9.7.2.5 性能測試
對需求說明書中明確的系統性能進行測試。測試的準則是要滿足規格說明書中的各項性能指標。
9.7.2.6 易用性測試
9.7.2.7 適應性測試
參照用戶的軟、硬體使用環境和需求說明書中的規定，列出開發的系統需要滿足的軟、硬體環境。對每個環境進行測試。
9.7.2.8 文檔測試
用戶文檔包括: 安裝手冊、操作手冊和維護手冊。
對用戶文檔測試的內容包括:
操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊；
用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達；
用戶文檔是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達；
用戶文檔對主要功能和關鍵操作是否提供應用實例；
用戶文檔是否有詳細的目錄表和索引表；
9.7.2.9 驗收標準
軟體錯誤的嚴重性等級：
不能執行正常功能或重要功能；
嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決；
嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法；
使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能；
其它錯誤。
錯誤與嚴重性等級對應表：
一級錯誤的描述：
沒有實現或錯誤地實現重要的功能；業務流程存在重大隱患；軟體在操作過程中由於軟體自身的原因自動退出系統或出現死機的情況；軟體在操作過程中由於軟體自身的原因對系統或數據造成破壞；在現有的軟、硬建設環境下不能實現應有的功能；特殊軟體在操作過程中可能危及系統和人身安全等。
二級錯誤的描述：
沒有實現基本功能，並且不存在替代辦法；沒有實現重要功能中的部分功能，並且不存在替代辦法；業務流程銜接錯誤；密鑰以明文方式存儲；沒有留痕功能；用戶的權限分配不合理；在現有的環境下，不能實現部分功能且沒有替代方案；沒有滿足系統的性能要求。
三級錯誤的描述：
這一級的錯誤是與第二級別的錯誤相對應的，而第3級錯誤則存在替代方法；對誤操作或錯誤操作沒有提示，導致非法數據進入資料庫。
四級錯誤的描述：
為易用性方面的錯誤。比如界面不友好、前後風格不一；中英文混雜；查詢結果輸出不直觀等。
五級錯誤的描述：
為文檔方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。
對發現的每一個錯誤都要確定相應的嚴重性等級，全部改正方可。
驗收標準
測試用例不通過數的比例<1.7 %；
不存在錯誤等級為1的錯誤；
不存在錯誤等級為2的錯誤；
錯誤等級為3的錯誤數量≤6；
所有提交的錯誤都已得到更正；
十、效益分析10.1 經濟效益本項目研究成果將為北橫工程提供三維可視化信息模型、動態施工管理及投資控制平臺，可有效地提高工程效率、減少失誤、節省資源，使各參與方都能獲益。更為重要的是，可合理降低和有效控制工程建設整體投資，同時為後期運營維護提供便利，在中長期運維期產生的經濟效益巨大。
10.2 社會效益本項目在北橫工程建設中的應用，將促進設計、施工階段的方案優化完善，提高施工組織協調性、有效減少返工誤工、降低環境影響。本項目的研究將推動BIM技術在市政工程建設中的應用與發展，將為建設方和政府主管部門提供管理上的便利，對未來城市市政基礎設施建設水平的提高產生積極的影響，其總體社會效益十分顯著：
十一、結語以這篇文檔為基礎，全面性的進行論述BIM協同管理平臺推廣實施規劃方案，讓實施流程層次化、系統化，為以後項目的實際實施提供可靠的依據或者參考。
作者:臥枕江山
Ps：學習更多產品運營課程，歡迎加入已有10000+會員選擇的《91運營網VIP會員》。點擊閱讀原文了解詳情，開啟365天蛻變之旅！
據說，打賞的都是真粉絲哦，8塊8請小編喝咖啡吧！長按二維碼勾搭小編微信（ludan202088）加入91運營社群，全年多場運營課，定期問題答疑等著你， 會運營的人都在這裡了！