數(shù)據(jù)更新維護方案

目錄TOC\o"1-4"\h\z\u1 工程綜述 圖59所示〕著手，力爭做到萬無一失。圖SEQ圖\*ARABIC59空間數(shù)據(jù)庫生產(chǎn)體系功能模型通信網(wǎng)絡平安通信網(wǎng)絡的平安與保密一般指：認同用戶和對等實體鑒別：收發(fā)方均要已確認識別對方；存取控制：對網(wǎng)絡用戶的存取權限進行控制；數(shù)據(jù)完整性：防止數(shù)據(jù)被簽收、替換、刪除；加密：防止信息被截取后造成損失；防否認：收發(fā)雙方要成認收到或發(fā)過數(shù)據(jù)；審計：集中登錄用戶的網(wǎng)上活動。容錯：采用多路由選擇、斷點重發(fā)、節(jié)點雙工等。在計算機網(wǎng)絡中，最主要的平安機制就是數(shù)據(jù)保密、數(shù)據(jù)完整性、存取控制和數(shù)字簽名。局域網(wǎng)的平安局域網(wǎng)屬于內(nèi)部網(wǎng)，其平安性主要表達在存取控制和用戶身份識別上。一個局域網(wǎng)上的用戶群是相對穩(wěn)定和的，對每類用戶可以授予不同的訪問權限。用戶可以本機登錄也可以網(wǎng)絡登錄，本機登錄的平安管理主要是操作系統(tǒng)的平安管理，下一節(jié)介紹，網(wǎng)絡登錄方式在此說明。網(wǎng)絡的用戶可以分為不同的級別：網(wǎng)絡管理員分系統(tǒng)管理員、數(shù)據(jù)庫管理員、超級用戶、一般用戶等。一般用戶中又根據(jù)其工作性質(zhì)分為研究開發(fā)組、數(shù)據(jù)采集組、產(chǎn)品分發(fā)組、財務管理組、行政辦公組等。對于每類用戶，系統(tǒng)資源中均有說明，哪些資源對于哪類用戶有某種訪問權限，這些資源包括存貯空間、軟件、數(shù)據(jù)集、輸出設備等。用戶與這些資源之間的關系就是通過一個訪問權限矩陣來實現(xiàn)的，具體的權限又分為完全控制、只讀、只寫、刪除、讀寫等。在局域網(wǎng)中，數(shù)據(jù)的加密不是主要的問題。數(shù)字簽名也不是至關重要的。城域網(wǎng)和廣域網(wǎng)的平安城域網(wǎng)和廣域網(wǎng)的平安有類似的要求。由于這類網(wǎng)絡的用戶群機動性大，而且在網(wǎng)絡的結構和協(xié)議上也差異很大，所以在信息平安上有特殊的要求。信息在這類網(wǎng)絡的傳輸往往要經(jīng)過許多環(huán)節(jié)和路由，所以在網(wǎng)絡協(xié)議上就要有平安保證。信息要加密后才能在網(wǎng)上傳送，對用戶要確定身份，還要求具有防否認的能力。這就要求采用必要的信息平安措施，即防火墻技術、包過濾技術、公開密鑰傳輸和數(shù)字簽名技術。用戶的訪問權限也要同局域網(wǎng)的情況一樣進行嚴格控制。防火墻技術城域網(wǎng)和廣域網(wǎng)或Extranet和Internet的常用平安措施就是防火墻〔Firewall〕。防火墻由濾波器和網(wǎng)關〔gateway〕組成。濾波器的作用是阻止某些類型的通信傳輸，而網(wǎng)關的作用是提供中繼效勞，以補償濾波器的效應。典型防火墻的配置是用兩個網(wǎng)關，外部濾波器保護網(wǎng)關免受來自外部的攻擊。內(nèi)部濾波器對一系列中間網(wǎng)關進行防衛(wèi)，這些濾波器都是為了防止外界的攻擊。濾波可分為三類：分組濾波、應用級濾波和線路濾波。一般情況下，濾波器設置在本組織與外界之間，對于一些大的組織需要設置內(nèi)部濾波器，將一些平安域和一般用戶域隔離，也可對不同級別的平安域設置多個防火墻。分組濾波分組濾波器〔信息包過濾器〕能提供花費少而有用的網(wǎng)關平安，因為可以在已有的路由器中配置具有濾波功能的軟件。分組濾波的工作原理是根據(jù)源地址和目的地址端口來決定分組是否要去掉。濾波功能發(fā)生在分組接收時或發(fā)送時，或者兼有，取決于不同的路由器類型。管理員設置可接收的機器和效勞的表，以及不可接收的機器和效勞的表。這種方法可方便地在主機或網(wǎng)絡級來接收或拒絕分組，以實現(xiàn)分組濾波。很多先進的網(wǎng)關具有分組濾波功能。分組濾波的缺點是參加濾波后，使網(wǎng)關的效率降低。有些效勞在分組濾波環(huán)境中難以實現(xiàn)。應用級濾波應用級網(wǎng)關是防火墻設計的另一種極端，它不像通用的機制允許不同類型的通信流通，而是對每個應用采用專用的碼。雖然這種方法看起來很浪費，但比別的方案平安得多，這種方法需要用戶輸入ID和口令，有時要用到IC卡〔智能卡〕。應用級網(wǎng)關的另一個優(yōu)點是對某些環(huán)境十分關鍵。這些環(huán)境易于登記和控制所有輸入和輸出的通信，主要用于FTP文件傳輸和E－mail的收發(fā)方面。這種方法可以確保E－mail的唯一地址，也可以隱蔽內(nèi)部機器的細節(jié)。應用級濾波只是為了防止外部攻擊，往往無法防止內(nèi)部人員對文件的檢索。這種方法的缺點是對大局部的效勞提供者需要專門的用戶程序或各種用戶接口，一般只用于支持最重要的一些效勞。線路級濾波線路級濾波或回路級濾波可在兩臺電腦的傳送層之間提供中斷效勞。傳送層的責任是保證“端對端”之間數(shù)據(jù)信息包的可靠傳輸。有時線路連接是自動進行的，有時需要指定目的地以供連接效勞，后一種方式需要在調(diào)用者和網(wǎng)關之間有一定協(xié)議，該協(xié)議描述所需目的地和效勞，以及網(wǎng)關返回的出錯信號等，起一個代理〔proxy〕的作用。代理效勞〔proxy〕允許用戶從單位防火墻的后面建立與外面網(wǎng)絡的直接連接，從而對數(shù)據(jù)越界傳輸進行保護。防火墻的特性防火墻作為一種產(chǎn)品和技術，有多種方案可供選擇，具體選什么樣的方案要視要求而定。防火墻產(chǎn)品一般要具有下述功能：訪問控制：用戶在身份簽定后，才能進入網(wǎng)絡，訪問控制表可以設定；身份簽定：用戶向系統(tǒng)說明自己的身份供系統(tǒng)簽定，可用多種方法，比方一次性口令及智能卡密鑰簽定等。加密：應提供多種加密方案，如DES和RSA等。記錄：應提供不間斷的跟蹤監(jiān)聽。管理和用戶界面：供系統(tǒng)管理員操作和設置的圖形化界面。協(xié)議和應用程序支持：支持多協(xié)議、多種程序。地址轉換：可對IP地址進行擴展。透明性：對末端用戶來講，防火墻是透明的。病毒偵測：隨時監(jiān)測病毒的入侵。軟件平安軟件平安涉及信息存貯和處理狀態(tài)的保護。無論是系統(tǒng)軟件還是應用軟件，都要求可靠和強壯。從信息之平安和保密角度考慮，軟件平安主要有存取控制、信息流向控制、用戶隔離及病毒預防等。一個計算機系統(tǒng)可以看成進程〔主體〕和資源〔客體〕的結合。在這種情況下，最根本的平安措施為存取控制。它是對程序執(zhí)行期間使用資源合法性檢查。利用對數(shù)據(jù)和程序讀出、修改和刪除的管理，存取控制能制止因技術事故和蓄謀作案構成對信息的威脅，以保護信息機密性、完整性和可用性。在操作系統(tǒng)控制下的存取控制機構，可以授予和撤消用戶對各種客體的占有權，尤其是文件系統(tǒng)中廣泛應用存取控制功能。在軟件平安中采取隔離控制是常規(guī)手段。多道編程、多用戶存取操作系統(tǒng)內(nèi)廣泛使用隔離手段。多用戶系統(tǒng)各用戶程序互相隔離、多虛擬機是指一臺中央處理機內(nèi)同時運行假設干不同操作系統(tǒng)，每個操作系統(tǒng)下又有假設干用戶同時工作。它們是互相隔離的，以到達保護的目的。存取控制為保證計算機系統(tǒng)有序和有效操作，各進程要受資源管理策略的制約。存取控制為實施資源管理策略提供機構，策略可以經(jīng)常改變，但是它并不要求實施策略的機構有所改變，而只要求對系統(tǒng)參數(shù)和表格進行修改。在設置存取控制機構時，要引入保護域的概念。一個保護域?qū)粋€具體進程，其定義一個客體集和可在每個客體上實現(xiàn)存取權的類型。存取權可由三元組〔域、客體、權集〕有序級組成的存取矩陣表示。存取矩陣的一種表示形式為存取表，表內(nèi)每一列對應一個客體，每個客體的存取表由二元組〔域、權集〕組成。這樣每個客體均有其全部域，且無空權集出現(xiàn)。存取矩陣的另一種方式為權能表。假設存取矩陣的列和客體結合，行和域結合，那么構成一個域的權能表，它是允許在其上作存取操作的客體表。一個客體用其物理名或地址代表，稱為一種權能。文件系統(tǒng)中，對文件存取不僅可置于文件，還可置于與文件樹關聯(lián)的各級目錄。利用口令字可對文件起保護作用。隔離控制隔離的目的在于堵住平安上的漏洞。隔離法使操作系統(tǒng)內(nèi)遭到破壞的局部不響其他局部。因多用戶登錄、編譯、存取諸方面有多種要求，現(xiàn)代操作系統(tǒng)任務十分復雜。這種多種性和復雜度是造成系統(tǒng)崩潰和數(shù)據(jù)溢漏的根源，并構成對信息的破壞。防止這一現(xiàn)象的有效措施是將計算機硬件和軟件分割成假設干互斥局部，每一局部自行執(zhí)行任務，并與其他局部毫不相干，這就是隔離效果。隔離的一種實現(xiàn)方法是多虛擬機技術。每個用戶組可有自己的操作系統(tǒng)，各虛擬機操作系統(tǒng)及其應用當作單獨一個計算機系統(tǒng)分別運行。計算機病毒的危害起源于共享路徑、信息流的傳遞和信息解釋的通用性。把信息當作程序或數(shù)據(jù)并無本質(zhì)上的區(qū)別。解釋器被編輯的信息可作數(shù)據(jù)或程序解釋。事實上只有在解釋器解釋下的信息才有意義。如果有信息共享路徑，那么病毒會通過共享信息解釋而擴散。如果信息流的傳遞并無限制，那么該信息可起源于任何點的信息流傳遞包。也就是說，信息共享、信息流傳遞和解釋通用性都會使病毒到達起源于任何指定點的信息流傳遞包。信息完全隔離而無共享，那么談不上通過域內(nèi)信息傳遞。域外信息末予解釋，也就不會有病毒傳播到域外的條件發(fā)生。在病毒傳染過程中，需要對被解釋信息作修改，假設某系統(tǒng)內(nèi)的程序不能改動，那么該系統(tǒng)不會染上病毒。隔離法是制止病毒傳染的根本措施。對信息流傳遞渠道可有兩種限制：一是在傳遞過程中把用戶置于相應封閉子集內(nèi)，到達隔離效果。二是把信息流動限制在多個分割域內(nèi)，這樣即使有病毒傳染，每次也只限于一個分割域。這樣可防止病毒在整個系統(tǒng)傳染。平安操作系統(tǒng)軟件平安的根本是對平安操作系統(tǒng)的要求和實現(xiàn)。這種系統(tǒng)靠建立平安核實現(xiàn)，其思想是將全部與平安有關的決策的操作系統(tǒng)權能均集中在一個小而全的保護域〔平安核〕內(nèi)。其具有以下特征：完全：主體對客體的全部存取權均受平安檢驗；隔離：平安核代碼受隔離保護，系統(tǒng)內(nèi)任何其他軟件不會對它干擾或修改；可信：實施平安權能為預料中的，不會伴生其它權能而構成威脅。數(shù)據(jù)庫平安生產(chǎn)數(shù)據(jù)的平安數(shù)據(jù)在生產(chǎn)過程中要考慮平安措施。每個生產(chǎn)單位要設立一個系統(tǒng)管理員和數(shù)據(jù)管理員?；騼身椔氊熡梢蝗思嫒巍?shù)據(jù)的生產(chǎn)過程分為掃描數(shù)據(jù)〔源數(shù)據(jù)〕、處理過的數(shù)據(jù)〔如糾正、矢量化等〕、檢查過的數(shù)據(jù)、入庫前的數(shù)據(jù)等等。數(shù)據(jù)在各個生產(chǎn)過程中都要進行統(tǒng)一的管理與分發(fā)。每一份生產(chǎn)數(shù)據(jù)都要有備份。一般情況下，作業(yè)員一份，數(shù)據(jù)管理員一份。為了防止數(shù)據(jù)泄密，數(shù)據(jù)都通過網(wǎng)絡傳輸，一般作業(yè)員的機器不帶光驅(qū)和軟驅(qū)。當要輸出數(shù)據(jù)時，通過數(shù)據(jù)管理員。數(shù)據(jù)管理員對接收和分發(fā)的數(shù)據(jù)要進行登記。數(shù)據(jù)庫平安根底地理信息和其他信息一樣，在計算機中都是以文件或數(shù)據(jù)庫關系表的方式來表示和存貯。文件系統(tǒng)可看作數(shù)據(jù)庫系統(tǒng)的原始形式，其平安性能在前面討論，這里僅對以數(shù)據(jù)庫為環(huán)境的數(shù)據(jù)平安和保密作進一步討論。數(shù)據(jù)庫的平安建立在操作系統(tǒng)的平安之上，在網(wǎng)絡化的地理信息生產(chǎn)體系中，數(shù)據(jù)可以分布在不同機器上，也可以集中到文件效勞器或數(shù)據(jù)效勞器中，前者要求分布式數(shù)據(jù)庫，后者要求假設干客戶／效勞器的數(shù)據(jù)庫管理系統(tǒng)。數(shù)據(jù)庫的特點是使得數(shù)據(jù)具有獨立性，并且提供對完整性支持的并發(fā)控制、訪問權限控制、數(shù)據(jù)的平安恢復等。針對數(shù)據(jù)平安，下面分別討論：并發(fā)控制、存取控制和備份恢復技術。并發(fā)控制數(shù)據(jù)庫的完整性可以歸納為語義的完整性、運行的完整性的恢復問題。運行的完整性即并發(fā)性事務處理的控制〔并發(fā)控制〕。數(shù)據(jù)完整受損主要是出錯所致，如用戶程序、事務處理或系統(tǒng)有誤。數(shù)據(jù)的集中導致并行事務處理的出現(xiàn)，并行的事務處理可能會并發(fā)存取相同的數(shù)據(jù)。為防止并發(fā)存取和并發(fā)個性對數(shù)據(jù)完整性的危害，應采取措施保證無誤無沖突地工作?；诟綦x控制原理，這些措施目的在于使每項事務處理都覺得整個數(shù)據(jù)庫為其獨占，即邏輯模擬用戶操作環(huán)境。并發(fā)修改同一數(shù)據(jù)項時，可能會得出錯誤結果。所以在數(shù)據(jù)庫中當某項事務正在修改一個數(shù)據(jù)項時，其他事務只能讀取，而不能修改。在空間數(shù)據(jù)庫的情況下，采用鎖的機制可保護數(shù)據(jù)完整性。鎖的粒度取決于數(shù)據(jù)庫的實現(xiàn)方法。基于圖幅的組織方式時，整個圖幅可為一個鎖單元，無縫組織時，某個要素作為鎖單元。文件系統(tǒng)時，整個文件只能有一項事務進行修改，其他事務可讀取。最理想的鎖粒度應是數(shù)據(jù)庫中的單個要素，但這要求空間數(shù)據(jù)庫有非常強的功能才行。根底地理信息數(shù)據(jù)庫中，當圖形數(shù)據(jù)和屬性數(shù)據(jù)不在同一個庫中時，在修改時還要保證兩邊的一致性，所以要同時鎖住圖形數(shù)據(jù)和屬性數(shù)據(jù)。存取控制存取控制實為授權機制，是數(shù)據(jù)庫平安的關鍵。對于何范圍內(nèi)的數(shù)據(jù)，在何條件下，規(guī)定準許可進行何種操作。數(shù)據(jù)庫中的數(shù)據(jù)有對事件敏感、狀態(tài)敏感和模式敏感的三種，事件敏感的數(shù)據(jù)只對一組專門用戶在指定的時間內(nèi)開放。狀態(tài)第二的數(shù)據(jù)，存取取決于其值，即在數(shù)據(jù)庫管理系統(tǒng)動態(tài)狀況下起作用。對模式第三的數(shù)據(jù)其存取取決于數(shù)據(jù)庫模式設計時對其用法的規(guī)定。用戶在調(diào)用具體的模塊時，要輸入戶名和密碼或口令，每個模塊均有其授權的用戶。每種數(shù)據(jù)也定義了用戶權限表，只有指定的用戶才能進行相應的操作。用戶權限是由數(shù)據(jù)庫管理員來設定的。對于數(shù)據(jù)庫的操作可分為：擁有、只讀、只寫、讀寫、刪除等。一般這種權限是在表一級上定義的，通過對視圖〔View〕的授權也可以對表的列定義訪問權限。數(shù)據(jù)庫的用戶也是分組、分級的，數(shù)據(jù)庫管理員擁有全部特權，數(shù)據(jù)擁有者次之。根底空間數(shù)據(jù)在存取控制上又有其專門特征。數(shù)據(jù)控制的可以是基于空間范圍的，也可以是要素類的。有些區(qū)域?qū)δ承┯脩羰情_放的，對其他用戶關閉；而有些要素只對某些用戶是開放的。因此其存取控制可用一個三元組的表來表示，即〔范圍，要素，權限〕。該表只有DBA才能訪問修改。數(shù)據(jù)恢復數(shù)據(jù)庫中的數(shù)據(jù)是獨立于程序而存在的，無論是自然錯誤還是人為錯誤，都可能有千百萬數(shù)據(jù)的錯誤，為了能夠恢復修改前的狀態(tài)和值，數(shù)據(jù)庫的操作要具有：自動恢復：在出錯時可回到修改前狀態(tài)；自動備份：數(shù)據(jù)庫修改后，原數(shù)據(jù)應有備份，這種備份又有完全備份和增量式備份；歷史數(shù)據(jù)：當數(shù)據(jù)庫中數(shù)據(jù)大量修改后，原來的數(shù)據(jù)要保存入歷史庫中，供以后用。數(shù)據(jù)保密在遠程訪問時，數(shù)據(jù)查詢結果要在網(wǎng)上傳送，這樣就要求傳送的數(shù)據(jù)平安。同樣要采用加密的方法來到達目的。信息存貯媒體的平安以上討論了信息平安的幾個方面，而對于根底地理信息平安和保密來說，存貯媒體平安非常重要，是信息平安的根本保證，所以在此深入討論。關鍵記錄數(shù)據(jù)的保護記錄的分類為了對那些必須保護的記錄提供足夠的保護，而對那些不重要的記錄不提供多余的保護，應該對所有記錄給予評價，并作出分類。1類〔關鍵性的〕記錄：對設備的功能來說是最重要的，不可替代的，火災或災害后立即需要但又不能再制的那些記錄。如關鍵程序、主記錄、設備分配圖表、加密、并法、密鑰等秘級很高的記錄。2類〔重要的〕記錄：這類記錄是很重要的，可以在不影響系統(tǒng)最主要功能的情況下進行復制，但比擬困難和昂貴。如某些程序、存貯及輸入輸出數(shù)據(jù)等屬于該類。3類〔很有用的〕記錄：其喪失可能引起極大的不便，但可以很快復制。已留有拷貝的程序、掃描的航空象片數(shù)據(jù)等屬此類。4類〔不重要的〕記錄：在調(diào)動時很少需要的記錄。記錄的復制全部1類記錄都應復制。復制品應分散存放平安的地方。2類記錄應有類似的復制品和存放方法。防護要求機房內(nèi)所留記錄的數(shù)量應該是系統(tǒng)有效運行的最小數(shù)量。定期存放在機房中的1類和2類記錄應放在能防火、防高溫、防水、防震、防電磁場的保護設備中，3類記錄應放在密閉金屬文件箱〔柜〕中。存放在機房外的記錄，沒有復制過的1類和2類記錄應放在防火房間中，或放在能防火、防水、防潮、防震、防電磁場和防盜的保險柜中。磁帶、磁盤和光盤庫只有庫管理員或系統(tǒng)管理員才允許訪問磁帶、磁盤和光盤庫。所有磁帶、磁盤和光盤的目錄清單必須具有以下信息：文件所有者、卷系號、文件名及其描述、作業(yè)或工程編號、建立日期和保存期限。從外借來的材料應有文件所有者、卷系列號、文件名和描述、接收日期和歸還日期進行編目。新磁帶要定期檢查和清洗，并登記。舊磁帶和磁盤在銷毀前要進行消磁和消除數(shù)據(jù)，平安負責人應保證所有已經(jīng)損壞的磁帶、磁盤和光盤的銷毀。庫管理員或系統(tǒng)管理員要負責把備份文件傳送到離開現(xiàn)場的平安地方。所有磁帶、磁盤和光盤不用時必須放入庫中。庫管理員或系統(tǒng)管理員負責所有磁帶、磁盤和光盤從庫里撤出和接收。在發(fā)件前，必須認真核對批準的申請單。庫的溫度應當在15℃－25工程進度方案及實施方案工程工期安排及控制工期安排的原那么工程實施階段進度控制總目標是在按照合同規(guī)定的工程竣工時間完成全部工作，提交質(zhì)量合格的成果。中標單位必須根據(jù)工程量、工程特點，結合環(huán)境因素，統(tǒng)籌安排人員、資金、儀器設備的配置。如有提前或滯后工期的情況，須經(jīng)業(yè)主同意。為有效地控制實施進度，確保工程工程如期交付使用，需對實施進度總目標進行分解，形成各部門、分階段可具體操作的目標體系，作為實施進度控制的依據(jù)。工期安排一般從以下幾個方面進行分解：按實施階段分解，明確每一階段的起止時間；按實施單位分解，明確各個單位所承當工程的完成時間；按工程組成分解，明確各分項工程的開竣工時間；按時間分解，按工期及進度目標將實施總進度方案分解為月度或周方案。工期安排的內(nèi)容編制可行的方案需考慮諸多因素，一個較完善的進度方案根本內(nèi)容應包括：符合合同工期要求的實施程序，即實施性組織設計；工程總體進度安排圖〔網(wǎng)絡圖、橫道圖及管理曲線〕；工程總體方案及詳細的工藝方法；工程所需人力、財力、物力〔材料、儀器、設備等〕進場方案圖；重難點工程、控制性工程或有特殊要求的工程詳細的工期安排；保證進度方案的各項措施。工期安排管理的方法和措施抓好工期安排管理的方法主要是規(guī)劃、控制和協(xié)調(diào)。規(guī)劃就是確定工程總進度控制和分進度控制目標，并編制相應進度方案；控制就是在工程實施的全過程中，跟蹤檢查實際進度并與方案進度進行比擬，確定偏差并及時采取措施加以調(diào)整和糾正；協(xié)調(diào)就是協(xié)調(diào)與有關的各單位、各部門和各隊之間的進度關系。工程進度的主要措施有：組織措施、技術措施、合同措施、經(jīng)濟措施、信息管理措施等。工期安排的實施與檢查〔1〕工期安排的措施工程進度方案的實施就是開展施工活動，落實和完成方案，工程進度方案逐步實施的過程就是工程逐步完成的過程。為保證工程各項活動按工期安排所確定的順序和時間進行，保證各階段進度目標和總進度目標的實現(xiàn)，應做好以下工作：檢查各層次的方案，并進一步編制月〔旬、周〕工作方案；綜合平衡，做好勞、財、機等主要生產(chǎn)要素的優(yōu)化配置；層層簽訂承包合同，并簽發(fā)任務書；全面實行層層方案交底，保證全體人員共同參與方案實施；做好實施記錄，掌握現(xiàn)場實際情況；切實做好實施中的調(diào)度工作，發(fā)現(xiàn)問題及時處理；預測各種可能的干擾因素，采取預控措施?！?〕工期安排的檢查在工程實施過程，工程進度方案的檢查貫穿于工程進度方案執(zhí)行的始終，二者密不可分，方案是進度的指導性文件，而進度檢查的反響信息為后續(xù)方案的編制和調(diào)整提供依據(jù)。工期安排檢查的主要工作：跟蹤檢查實際進度；整理統(tǒng)計檢查有關數(shù)據(jù)；比照實際進度與方案進度；實施進度檢查結果的處理?！?〕對工期調(diào)整的安排首先分析進度偏差產(chǎn)生的影響，判斷此進度偏差是否關系到關鍵工作：假設此項工作處于關鍵線路上，無論偏差大小，都必將對后續(xù)工作及總工期產(chǎn)生影響，必須采取相應的調(diào)整措施；假設此項工作在非關鍵線路上，那么根據(jù)其對后續(xù)工作和總工期的影響程度來定。其次判斷此進度偏差是否大于總時差：假設大于總時差，說明該偏差會影響后續(xù)工作和工程的總工期，必須予以調(diào)整；假設不大于總時差，那么該偏差不會影響總工期，其對后續(xù)工作的影響待進一步判定。最后判斷進度偏差是否大于自由時差：假設大于自由時差那么說明此偏差對后續(xù)工作有影響，應根據(jù)其對后續(xù)工作的影響成都做出調(diào)整；假設不大于自由時差，說明其對后續(xù)工作無影響，無須調(diào)整。工期安排的調(diào)整方法主要有兩種：改變某些工作間的邏輯關系假設檢查的實際施工進度產(chǎn)生的偏差影響了總工期，在工作之間的邏輯關系允許改變的條件下，改變關鍵線路和超過方案工期的非關鍵線路上的有關工作之間的邏輯關系，到達縮短工期的目的?？s短某些工作的持續(xù)時間這種方法不改變工作之間的邏輯關系，而是縮短某些工作的持續(xù)時間，使施工進度加快，并保證實現(xiàn)方案工期的方法。工期安排調(diào)整的內(nèi)容主要包括：施工內(nèi)容、工程量、起止時間、持續(xù)時間、邏輯關系和資源供給。數(shù)據(jù)更新工期安排根據(jù)招標文件所規(guī)定的工期，編制在第一階段數(shù)據(jù)更新〔更新2008全年數(shù)據(jù)〕的工期安排：表SEQ表\*ARABIC6數(shù)據(jù)更新工期安排序號工作內(nèi)容開始時間完成時間所需工作日備注1需求分析2002008工作日1.1數(shù)據(jù)現(xiàn)狀調(diào)研2002004工作日1.2數(shù)據(jù)庫標準調(diào)研2002004工作日2數(shù)據(jù)方案制定2008-2008-9工作日2.1制定數(shù)據(jù)更新方案2008-2008-3工作日2.2用戶確認數(shù)據(jù)更新方案2008-2008-2工作日2.3制定數(shù)據(jù)生產(chǎn)流程2008-2008-2工作日2.4用戶確認數(shù)據(jù)生產(chǎn)流程2008-2008-2工作日3公開版電子地圖更新20020033工作日4公共設施點更新200200保證32工作日除去節(jié)假日5數(shù)據(jù)檢查和驗收20020021工作日5.1數(shù)據(jù)檢查20020020工作日5.2數(shù)據(jù)驗收2002001工作日工程包括三個階段的更新，2008全年度、2009上半年、2009全年度，每個階段的更新時間都是接近6個月，各個作業(yè)流程的時間分配大致相同。在后兩個階段，由于已經(jīng)熟悉數(shù)據(jù)的構成，因此減少數(shù)據(jù)調(diào)研的時間，但是在數(shù)據(jù)更新方案制定方面可以適當增加時間，根據(jù)經(jīng)驗提高數(shù)據(jù)更新的效率，提供更多的數(shù)據(jù)更新手段。系統(tǒng)開發(fā)工期安排據(jù)招標文件所規(guī)定的工期，整個系統(tǒng)的開發(fā)工期安排如下：表SEQ表\*ARABIC7系統(tǒng)開發(fā)工期安排序號工作內(nèi)容開始時間完成時間所需工作日備注1需求調(diào)研及分析2002007工作日2需求分析及確認20020010工作日2.1數(shù)據(jù)更新維護系統(tǒng)需求分析析20020010工作日2.4數(shù)據(jù)更新維護系統(tǒng)需求確認200200810工作日3系統(tǒng)設計2008-2008-7工作日4系統(tǒng)開發(fā)200200保證50工作日作日除去節(jié)假日5系統(tǒng)測試20020010工作日6系統(tǒng)試運行20020022工作日7系統(tǒng)驗收文檔準備20020010工作日8系統(tǒng)驗收2002003工作日進度圖如以下圖所示：圖SEQ圖\*ARABIC60開發(fā)進度圖提交成果數(shù)據(jù)提交成果如下：〔1〕2009年3月30日之前提交2008全年電子地圖和公共設施數(shù)據(jù)庫〔內(nèi)、外網(wǎng)版本〕；〔2〕2009年9月30日之前提交2009上半年電子地圖和公共設施數(shù)據(jù)庫〔內(nèi)、外網(wǎng)版本〕；〔3〕2010年3月30日之前提交2009全年電子地圖和公共設施數(shù)據(jù)庫〔內(nèi)、外網(wǎng)版本〕；〔4〕數(shù)據(jù)成果內(nèi)容包括：電子地圖數(shù)據(jù)庫、公共設施專題圖集、電子地圖和公共設施更新機制報告、電子地圖和公共設施更新操作標準、其他技術文檔和總結報告；〔5〕售后效勞：免費提供數(shù)據(jù)維護效勞一年。系統(tǒng)提交成果如下：〔1〕運行正確的安裝系統(tǒng)〔2〕運行系統(tǒng)〔3〕系統(tǒng)源代碼〔4〕用戶使用手冊〔安裝手冊、使用手冊、維護手冊等文檔〕〔5〕開發(fā)文檔〔需求、設計、測試、部署等文檔〕〔6〕總結報告數(shù)據(jù)更新質(zhì)量保證體系數(shù)據(jù)產(chǎn)品的高質(zhì)量是工程數(shù)據(jù)整理工作主要的追求目標，因此，在此次的數(shù)據(jù)整理工作中將對數(shù)據(jù)整理的質(zhì)量管理工作進行嚴格的管理。本數(shù)據(jù)整理過程的質(zhì)量管理工作將嚴格按照ISO9001：2000版的要求和我們的技術管理標準，建立工程質(zhì)量管理的流程，以保證數(shù)據(jù)整理的產(chǎn)品質(zhì)量。目的對從事與質(zhì)量有關的管理、執(zhí)行和驗證工作的人員，特別是對需要獨立行使權力開展以下工作的人員，應規(guī)定其職責、權限和相互關系，并形成文件；采取措施，防止出現(xiàn)與產(chǎn)品、過程和質(zhì)量體系有關的不合格；確認和記錄與產(chǎn)品、過程和質(zhì)量體系有關的問題；通過規(guī)定的渠道，采取、推薦或提出解決方法；驗證解決方法的實施效果；控制不合格產(chǎn)品的進一步加工、交付或安裝，直至缺陷或不滿足要求的情況得到糾正。范圍整個數(shù)據(jù)整理過程數(shù)據(jù)采集與說明文檔數(shù)據(jù)檢查到達的目標以獨立審查的方式監(jiān)控整個制作過程的執(zhí)行，給數(shù)據(jù)整理人員和管理層提供反映產(chǎn)品質(zhì)量的信息和數(shù)據(jù)，輔助數(shù)據(jù)整理組得到高質(zhì)量的數(shù)據(jù)產(chǎn)品；使數(shù)據(jù)質(zhì)量保證活動有方案性；使數(shù)據(jù)整理與其相關的標準、規(guī)程以及需求之間的符合性能夠得到客觀驗證；使數(shù)據(jù)質(zhì)量保證組所進行的活動和結果及時地通知到所涉及的數(shù)據(jù)整理組和個人；使高層管理者能夠及時處理在數(shù)據(jù)整理工程內(nèi)不能解決的與所制定的方案、標準和規(guī)程不相符合的問題。數(shù)據(jù)質(zhì)量保證〔SQA〕組我們在工程的實施前會成立一個由制作方和用戶共同成立的，對工程有一定管理能力的數(shù)據(jù)質(zhì)量保證〔SQA〕組，負責協(xié)調(diào)和實施工程的數(shù)據(jù)質(zhì)量保證〔SQA〕。為了使數(shù)據(jù)質(zhì)量保證得到順利實施，我們在工程管理中還制定了以下政策：為保障有足夠的資源和經(jīng)費，在工程經(jīng)費中至少有5%的費用用于SQA活動；對SQA組的成員進行培訓，使他們能完成SQA的活動；對參加數(shù)據(jù)生產(chǎn)工程的其他成員也進行有關SQA組的作用、職責及價值等方面的培訓；高層管理者定期地〔在工程實施的過程中不少于3次〕評審SQA活動和結果。本次系統(tǒng)開發(fā)過程的質(zhì)量管理工作除了嚴格按照公司的質(zhì)量管理的要求外，還要加強對數(shù)據(jù)生產(chǎn)活動的階段性評審工作，以保證數(shù)據(jù)生產(chǎn)的產(chǎn)品質(zhì)量。工程的質(zhì)量管理活動本工程將要進行的質(zhì)量管理活動如下：數(shù)據(jù)生產(chǎn)工具評價對所有正在使用的或方案的，用于數(shù)據(jù)生產(chǎn)或?qū)?shù)據(jù)生產(chǎn)進行必要支持的軟件工具進行評價。對于正在使用的軟件要評價其提供的功能是否滿足數(shù)據(jù)生產(chǎn)的需求，對于方案使用的軟件，要評價其能行性和可行性。表SEQ表\*ARABIC8軟件工具評價表軟件工具評價表格編號：D-B10-01質(zhì)量管理員：日期：評價：軟件工具評價：評價的方法與標準：評價結果：推薦的改正措施：改正措施的實行：工程設備的評價質(zhì)量管理員對正在使用的和方案使用的設備資源進行評價，估量所提供的必需的設備、器材和場地是否能滿足數(shù)據(jù)生產(chǎn)的需求，并形成書面報告。表SEQ表\*ARABIC9工程設備評價表工程設備評價表格編號：D-B10-02質(zhì)量管理員：日期：評價：工程設備評價〔器材、用戶/測試/場地〕：評價的方法與標準：評價結果：推薦的改正措施：改正措施的實行：工程過程評審任務數(shù)據(jù)產(chǎn)品審查過程SQA管理人員評價數(shù)據(jù)產(chǎn)品審查過程。檢查數(shù)據(jù)產(chǎn)品是否被審查，審查結果是否形成書面報告，結果和問題報告是否與工程的數(shù)據(jù)生產(chǎn)過程相一致。SQA管理人員使用過程審計報告單來報告審查的結果和本任務的完成情況。表SEQ表\*ARABIC10審計評審報告表表格編號：D-B04-01評審目的評審日期評審內(nèi)容參加評審人員評審綜述及結論〔可附頁〕：見附件存在的問題及原因〔可附頁〕：見附件整改措施建議〔可附頁〕：見附件審核意見：審核人：年月日批準意見：批準人：年月日編制單位：編制人：年月日工程方案過程工程管理小組需要開展并且文檔化以下方案：數(shù)據(jù)生產(chǎn)方案——通過數(shù)據(jù)生產(chǎn)規(guī)格來引導數(shù)據(jù)生產(chǎn)方案。方案被文檔化，規(guī)定了在數(shù)據(jù)生產(chǎn)生命周期和適當?shù)狞c所完成確實定的事件、檢查和評審活動。數(shù)據(jù)檢查方案——管理數(shù)據(jù)檢查的方式方案，包含數(shù)據(jù)檢查方案。工程需求分析過程工程需求分析在工程用戶和數(shù)據(jù)生產(chǎn)團隊之間建立起對數(shù)據(jù)處理的統(tǒng)一理解，確定工程用戶對數(shù)據(jù)處理工程需求的協(xié)議，并在后期的數(shù)據(jù)生產(chǎn)過程中不斷地對其進行維護工作。SQA人員應該完成以下的任務：保證在需求定義過程中選擇適當?shù)娜藛T，并且所有人員的需求都被正確、完全的識別。保證所定義的需求是否通過驗證的，是可實行的。保證對需求分配、工作產(chǎn)品、行為識別、檢查和終止途徑的變化管理。保證參加工程需求定義和分配過程的工程人員具有相關領域的工作經(jīng)驗或受過專門的訓練，以此來確保工作的正確執(zhí)行。保證對數(shù)據(jù)處理的承諾是與工程的實際關系人通過談判和協(xié)商而得來的。檢驗承諾是否文檔化的，便于交流的、便于檢查的和可被接受的。保證能夠識別出在工程需求分配確定過程中潛在的問題并進行必要的改變。檢驗規(guī)定的過程定義、文檔的需求分配是否伴隨進行并且是被文檔化的。檢驗需求是否經(jīng)過處理的、文檔化的受控的和可回溯的。檢驗需求是否被寫進制作方案中。工程概要設計過程〔1〕檢查一般需求與設計檢查設計評審時是否已確定了與需求有關問題〔如遺漏、模糊不清、不可測試的以及隱含的需求〕。檢查設計是否與需求一致〔如是否有遺漏、不準確的、模糊不清的或不正確的功能〕檢查設計是否充分說明了以下問題：實時需求可理解性數(shù)據(jù)的數(shù)學根底數(shù)據(jù)庫需求數(shù)據(jù)的質(zhì)量控制數(shù)據(jù)提交〔2〕數(shù)據(jù)生產(chǎn)規(guī)格說明檢查每一過程的過程規(guī)格說明是否準確、齊全。檢查是否用精確、不模糊的術語擬訂了過程規(guī)格說明，該過程規(guī)格說明是否清楚地描述了所需的變更。檢查是否規(guī)定了數(shù)據(jù)的分層、數(shù)據(jù)結構、數(shù)據(jù)編碼和精度要求。檢查是否規(guī)定了哪些地方需求進行錯誤檢查、錯誤處理和糾正。檢查設計是否遵循已確立的符號約定。系統(tǒng)詳細設計過程詳細設計需要被文檔化《詳細設計說明書》，SQA人員需要完成以下任務：〔1〕檢查需求可跟蹤性檢查數(shù)據(jù)生產(chǎn)的詳細設計是否實現(xiàn)了其需求。檢查對該數(shù)據(jù)生產(chǎn)的審查是否識別出工程需求規(guī)格說明書中存在的問題，例如，是否有遺漏、模糊不清、相互矛盾、不可測試或隱含的需求。檢查該數(shù)據(jù)生產(chǎn)的詳細設計是否符合其總體設計方案需求。檢查詳細設計審查是否識別出工程總體設計方案中存在的問題。檢查對數(shù)據(jù)成果完全、準確地進行描述是否到達足夠詳細的程度。檢查是否完全、準確地描述了所有的數(shù)據(jù)生產(chǎn)構成，包括數(shù)據(jù)的分階段制作，數(shù)據(jù)各階段的具體操作，技術要求細那么和限制。檢查詳細設計文檔內(nèi)容，即邏輯數(shù)據(jù)，所有內(nèi)部定義的數(shù)據(jù)是否完全、前后一致，沒有額外的數(shù)據(jù)?！?〕檢查邏輯性檢查是否有任何邏輯錯誤。檢查是否檢查了所有數(shù)據(jù)編碼的唯一值。檢查數(shù)據(jù)的處理順序是否正確。檢查是否存在數(shù)據(jù)處理錯誤，是否存在字段不正確、數(shù)據(jù)屬性不一致或無效現(xiàn)象?！?〕檢查錯誤處理和恢復檢查是否有適當?shù)腻e誤條件數(shù)據(jù)檢查。檢查是否認義了那些出錯概率高或錯誤結果對數(shù)據(jù)是致命的錯誤條件。檢查數(shù)據(jù)生產(chǎn)流程是否可以保證數(shù)據(jù)的質(zhì)量，同時及時進行數(shù)據(jù)錯誤的糾正?！?〕檢查可檢驗性和可擴展性檢查設計是否可理解〔即便于閱讀、符合邏輯性〕、可維護〔即無模糊不清的邏輯〕、可檢驗〔即可用合理的檢查模式對其檢驗〕。數(shù)據(jù)生產(chǎn)和檢查過程〔1〕檢查的規(guī)劃按照工程的實際情況確定各檢查階段的目標和策略。這個過程將輸出《檢查方案》，明確要完成的數(shù)據(jù)檢查活動，評估完成活動所需要的時間和資源，設計數(shù)據(jù)檢查組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制檢查過程的活動。數(shù)據(jù)檢查規(guī)劃與數(shù)據(jù)生產(chǎn)工作同步進行。SQA組人員在需求分析階段，要完成《檢查方案》；在設計階段，要完成《質(zhì)量控制設計方案》；在數(shù)據(jù)生產(chǎn)階段，要完成數(shù)據(jù)記錄；在提交顧客前，要完成《數(shù)據(jù)采集與處理的技術報告》和《質(zhì)量控制報告》。對于檢查方案的修訂局部，需要進行重新評審。圖SEQ圖\*ARABIC61檢查體系流程圖〔2〕檢查設計根據(jù)各階段的檢查方案設計質(zhì)量控制的方案。檢查設計過程輸出的是各檢查階段數(shù)據(jù)和檢查報告?！?〕檢查實施通過實施檢查流程，各項檢查工作同時進行檢查記錄記錄檢查的結果，對數(shù)據(jù)進行及時的糾錯，并在檢查結束后最終總結得到《質(zhì)量控制報告》。〔4〕配置管理檢查配置管理是配置管理的子集，作用于檢查的各個階段。其管理對象包括檢查方案、檢查方案、檢查版本、檢查工具及環(huán)境、質(zhì)量控制報告等?！?〕資源管理包括對人力資源和工作場所，以及相關設施和技術支持的管理。質(zhì)量控制的內(nèi)容數(shù)據(jù)檢查與質(zhì)量控制在工程實施過程中，主要是依據(jù)數(shù)據(jù)庫建庫標準以及相應的國家標準和行業(yè)標準，從原圖精度檢查、屬性數(shù)據(jù)的準確性、數(shù)據(jù)的完整性、位置精度、元數(shù)據(jù)記錄、數(shù)據(jù)邏輯一致性等方面進行的質(zhì)量控制。表SEQ表\*ARABIC11質(zhì)量特性一級質(zhì)量特性二級質(zhì)量特性位置精度數(shù)學根底平面精度高程精度接邊精度屬性精度要素分類與代碼的正確性要素屬性值的正確性要素注記的正確性邏輯一致性多邊形閉合精度結點匹配精度拓撲關系的正確性完備性數(shù)據(jù)分層的完整性實體類型的完整性屬性數(shù)據(jù)的完整性注記的完整性數(shù)據(jù)檢查根本包括圖形數(shù)據(jù)、屬性數(shù)據(jù)、數(shù)據(jù)的接邊情況、坐標配準等檢查工作，具體歸納如下：根本數(shù)據(jù)檢查〔1〕圖形數(shù)據(jù)檢查地圖數(shù)據(jù)屬于面狀地物的要素有沒有嚴格閉合，是否存在面狀地物的錯誤圖形。面狀地物的輪廓位置和形狀及編碼是否正確，標識點的編碼是否正確；面屬性項是否齊備，屬性取值是否正確，幾何精度是否符合國家標準；〔2〕不同層的地物要素共線時，數(shù)據(jù)有沒有提取公共邊；〔3〕點狀地物不是用點狀符號來表示，而是用線實繪時，是否丟漏標識符號；〔4〕不同類型的注記有沒有分類存放，如：面狀地物類注記是否丟漏注記、錯誤注記。注記位置、注記大小和注記字體是否得當；〔5〕數(shù)據(jù)局部地物分類是否不細致；〔6〕是否丟漏地物或地物的局部，是否存在多余地物的問題；〔7〕是否有重復數(shù)字化的要素；〔8〕有無錯誤的標識；〔9〕有向點的點位、方向是否正確；〔10〕地物點的編碼和定位位置是否正確；〔11〕線狀地物編碼是否正確、是否位移、是否變形、采集點是否疏密得當。當?shù)缆?、河流、等高線等線狀地物被點狀符號、注記、橋梁、涵洞等要素符號割斷時，線狀地物是否保持連通；當?shù)缆?、河流被橋梁、涵洞割斷時，是否加輔助線連通；〔13〕要素作為屬性的注記是否標注。數(shù)據(jù)屬性檢查〔1〕圖層名是否完整和正確，圖層是否有冗余；〔2〕每個層拓撲關系是否正確；〔3〕每個層的屬性字段是否完整、每個層屬性字段的定義是否正確、字段類型、字段長度，字段精度是否正確；〔4〕實體要素編碼是否屬于本層的范圍內(nèi)。拓撲關系檢查〔1〕圖層拓撲關系是否正確；〔2〕圖層是否存在懸掛節(jié)點、線線掛接現(xiàn)象；〔3〕是否嚴格按照拓撲關系分層；〔4〕是否存在自相交、環(huán)套環(huán)等屬于拓撲關系錯誤的情況。質(zhì)量控制的方法質(zhì)量檢查包括三種方法：軟件自動檢查、人際交互檢查、繪圖輸出檢查。軟件自動檢查對于入庫的所有數(shù)據(jù)應用軟件實行自動檢查，由于空間數(shù)據(jù)的圖形與屬性、圖形與圖形、屬性與屬性之間存在有一定的邏輯關系和規(guī)律，通過設計模型和算法，將數(shù)據(jù)中不符合規(guī)律、邏輯關系矛盾的要素自動挑選出來，主要包括：數(shù)據(jù)文件的完整性檢查、屬性一致性檢查、拓撲關系建立檢查、異常屬性值檢查、不符合邏輯關系的屬性值檢查等。程序檢查例如如下：圖SEQ圖\*ARABIC62批量監(jiān)理例如具體程序流程如以下圖：圖SEQ圖\*ARABIC63程序檢查流程人機交互檢查在軟件環(huán)境下，將要檢查的數(shù)據(jù)可視化，以圖形、圖像、表格等形式顯示在計算機的屏幕上，通過人工判斷其正確性;也可以使用查詢、統(tǒng)計、顯示等功能的組合，實現(xiàn)對數(shù)據(jù)的檢查。例如，在計算機上將采集的要素與影像進行疊加顯示，從而檢查要素的采集精度。還可以通過三維顯示DEM來檢查DEM高程的正確性。繪圖輸出檢查繪圖輸出主要是將各種要檢查的數(shù)據(jù)，根據(jù)其性質(zhì)表現(xiàn)為圖紙、報表、文檔等模擬形式的介質(zhì)，然后根據(jù)這些計算機回放的資料與數(shù)據(jù)采集的原始資料進行人工比擬核對，從而判斷和確定數(shù)據(jù)的正確性。例如，對于采集完后的道路、河流要素，進行輸出成圖，使之與現(xiàn)有地圖或航片進行對照或套合，從而檢查所采集要素的精度;屬性表可以打印出來，與原表逐條核對。在實際操作中，對于矢量數(shù)據(jù)的檢查可以用三種方法相互配合、綜合應用。在質(zhì)量檢查時，根據(jù)當時具體的內(nèi)容，選用相應的方法，主要是以軟件自動檢查為主，結合人機交互檢查和繪圖輸出模式，實現(xiàn)對二維空間數(shù)據(jù)進行全面的檢查。驗收內(nèi)容主要是對數(shù)據(jù)成果的分層、編碼、圖幅接邊、拓撲關系、幾何定位、現(xiàn)勢性等整理質(zhì)量因素進行檢查和驗收，并檢查提交技術文檔的完備性。文件格式檢查數(shù)據(jù)整理質(zhì)量的檢查；數(shù)據(jù)的屬性檢查；數(shù)據(jù)的命名檢查；數(shù)據(jù)的完整性檢查；數(shù)據(jù)幾何精度檢查；邏輯一致性檢查。檢查方法：人工檢查與程序檢查相結合。要求：地物要素分層正確、編碼屬性齊全、圖幅接邊情況良好、拓樸結構正確、文件命名方式正確無誤，邏輯一致性，幾何精度到達設計方案要求。工程文檔管理作為數(shù)據(jù)生產(chǎn)產(chǎn)品的一局部，數(shù)據(jù)生產(chǎn)的文檔的質(zhì)量直接影響產(chǎn)品的質(zhì)量。進行工程文檔的管理即是深圳市規(guī)劃局對本次數(shù)據(jù)更新的要求，也是我公司數(shù)據(jù)生產(chǎn)的標準性要求之一。有關的工程文檔管理工作內(nèi)容如下：文檔編制方案文檔方案是整個工程方案的一個獨立文檔，編寫文檔方案并把它分發(fā)給全體開發(fā)組成員，作為文檔重要性的具體依據(jù)和管理部門文檔工作責任的備忘錄。文檔方案一般包括以下幾方面內(nèi)容：列出應編制文檔的目錄提示編制文檔應參考的標準指定文檔管理員提供編制文檔所需要的條件，落實文檔編寫人員及編制工具明確保證文檔質(zhì)量的方法，為了確保文檔內(nèi)容的正確性、合理性，應采取一定的措施，如評審、鑒定等繪制進度表，以圖表形式列出在各階段應產(chǎn)生的文檔、編制人員、編制日期、完成日期、評審日期等規(guī)定每個文檔要到達的質(zhì)量等級為了到達期望的結果必須考慮哪些外部因素文檔方案還確定該方案和文檔的分發(fā)，并且明確表達與文檔工作的所有人員的職責。文檔種類根據(jù)招標文件的具體要求及我公司《文檔管理制度》的要求，本工程提交的所有文檔均符合相應的標準。本次開發(fā)活動將形成以下文檔〔1〕數(shù)據(jù)生產(chǎn)文檔根本的數(shù)據(jù)生產(chǎn)文檔：投標文件和工程任務書需求規(guī)格說明書驗收標準電子地圖和公共設施更新機制報告電子地圖和公共設施更新操作標準數(shù)據(jù)質(zhì)量控制設計方案數(shù)據(jù)檢查記錄質(zhì)量控制報告驗收報告〔2〕管理文檔工程管理過程所產(chǎn)生的文檔：數(shù)據(jù)生產(chǎn)過程的每個階段的進度和進度變更的記錄數(shù)據(jù)生產(chǎn)變更情況記錄過程評審表文檔管理職責為了作好工程的文檔管理工作，工程的文檔管理人員具有以下職責：建立編制、登記、出版工程文檔的各種策略；把文檔方案作為整個開發(fā)工作的一個組成局部；建立確定文檔質(zhì)量、測試質(zhì)量和評審質(zhì)量的各種方法規(guī)程；為文檔的各個方面，確定和準備各種標準和指南；積極支持文檔工作以形成在開發(fā)工作中自覺編制文檔的團隊風氣；不斷檢查已建立起來的過程，以保證符合策略和各種規(guī)程并遵守有關標準和指南。文檔的質(zhì)量要求工程開發(fā)過程中所產(chǎn)生的文檔要滿足以下要求：文檔需要覆蓋整個數(shù)據(jù)生產(chǎn)生存期，文檔在貫穿數(shù)據(jù)生產(chǎn)過程中必須是可用的和可維護的。在數(shù)據(jù)生產(chǎn)完成后，文檔應滿足數(shù)據(jù)成果的使用、維護、轉換或傳輸。文檔應可管理的，工程經(jīng)理應準備文檔產(chǎn)品、進度、可靠性、資源，質(zhì)量保證和評審規(guī)程的詳細方案大綱。文檔應適合于它的讀者，讀者可以是工程經(jīng)理、數(shù)據(jù)生產(chǎn)員、數(shù)據(jù)檢查員、維護人員、文書人員等，根據(jù)任務的執(zhí)行，文檔具有不同的詳細程度，針對不同的讀者，應設計不同類型的文檔。文檔應貫穿到整個數(shù)據(jù)生產(chǎn)過程中，應充分表達文檔的作用和限制，即文檔應指導全部開發(fā)過程。文檔標準應被標識和使用，應盡可能采納公司的文檔編制標準和指南。數(shù)據(jù)更新維護系統(tǒng)質(zhì)量保證體系軟件產(chǎn)品的高質(zhì)量是工程開發(fā)工作主要的追求目標，同時也是深圳市規(guī)劃局在此次系統(tǒng)建設中非常關心的內(nèi)容之一。因此，在此次的開發(fā)活動中將對開發(fā)活動的質(zhì)量管理工作進行嚴格的管理。本系統(tǒng)開發(fā)過程的質(zhì)量管理工作將嚴格按照ISO9001：2000版的要求和我們的技術管理標準，建立工程質(zhì)量管理的流程，以保證開發(fā)的產(chǎn)品質(zhì)量。目的對從事與質(zhì)量有關的管理、執(zhí)行和驗證工作的人員，特別是對需要獨立行使權力開展以下工作的人員，應規(guī)定其職責、權限和相互關系，并形成文件；采取措施，防止出現(xiàn)與產(chǎn)品、過程和質(zhì)量體系有關的不合格；確認和記錄與產(chǎn)品、過程和質(zhì)量體系有關的問題；通過規(guī)定的渠道，采取、推薦或提出解決方法；驗證解決方法的實施效果；控制不合格產(chǎn)品的進一步加工、交付或安裝，直至缺陷或不滿足要求的情況得到糾正。范圍系統(tǒng)開發(fā)過程系統(tǒng)文檔系統(tǒng)測試系統(tǒng)原代碼管理到達的目標以獨立審查的方式監(jiān)控整個開發(fā)過程的執(zhí)行，給開發(fā)人員和管理層提供反映產(chǎn)品質(zhì)量的信息和數(shù)據(jù)，輔助軟件工程組得到高質(zhì)量的軟件產(chǎn)品。使系統(tǒng)軟件質(zhì)量保證活動有方案性；使軟件開發(fā)與其相關的標準、規(guī)程以及需求之間的符合性能夠得到客觀驗證；使軟件質(zhì)量保證組所進行的活動和結果及時地通知到所涉及的軟件開發(fā)組和個人；使高層管理者能夠及時處理在軟件工程內(nèi)不能解決的與所制定的方案、標準和規(guī)程不相符合的問題。軟件質(zhì)量保證〔SQA〕組我們在工程的實施前會成立一個由開發(fā)方和用戶共同成立的，對工程有一定管理能力的軟件質(zhì)量保證〔SQA〕組，負責協(xié)調(diào)和實施工程的軟件質(zhì)量保證〔SQA〕。為了使軟件質(zhì)量保證得到順利實施，我們在工程管理中還制定了以下政策：為保障有足夠的資源和經(jīng)費，在工程經(jīng)費中至少有5%的費用用于SQA活動；對SQA組的成員進行培訓，使他們能完成SQA的活動；對參加軟件工程的其他成員也進行有關SQA組的作用、職責及價值等方面的培訓；高層管理者定期地〔在工程實施的過程中不少于3次〕評審SQA活動和結果。本次系統(tǒng)開發(fā)過程的質(zhì)量管理工作除了嚴格按照公司的質(zhì)量管理的要求外，還要加強對開發(fā)活動的階段性評審工作，以保證開發(fā)的產(chǎn)品質(zhì)量。工程評審工作任務〔1〕技術評審任務建立軟件配置管理的基線；提出并解決技術問題，審查技術工作；評價工程的狀態(tài)，判明有關技術問題的近期、長期風險，并加以討論；在技術代表的權限內(nèi)，達成已判明風險的轉移策略；標識呈交管理人員討論的風險要素和有關問題；確保用戶和軟件開發(fā)技術人員之間的交流通暢。〔2〕管理評審任務報告上級管理部門該工程的狀態(tài)、所采取的方針、所達成的技術協(xié)議以及按產(chǎn)品進展的總體情況解決技術評審不能解決的問題就技術評審不能解決的近期、長期風險可達成的轉移戰(zhàn)略；鑒別并解決管理方面的問題，以及技術評審沒有提出的風險；征得用戶的同意和各方認可，以便及時完成?！?〕系統(tǒng)評審任務系統(tǒng)和軟件需求分析評審系統(tǒng)結構評審軟件總體設計階段，應對軟件項、接口和數(shù)據(jù)設計結構評審軟件詳細設計和測試方案評審軟件編碼和測試結果的評審系統(tǒng)集成的評審系統(tǒng)確認評審軟件評審完成后，提出應采取的各種措施，工程組實施修改，在預計的時間內(nèi)，SQA組檢查糾正的結果。工程的質(zhì)量管理活動本工程將要進行的質(zhì)量管理活動如下：開發(fā)工具評價對所有正在使用的或方案的，用于軟件開發(fā)或?qū)浖_發(fā)進行必要支持的軟件工具進行評價。對于正在使用的軟件要評價其提供的功能是否滿足開發(fā)的需求，對于方案使用的軟件，要評價其能行性和可行性。表SEQ表\*ARABIC12軟件工具評價表軟件工具評價表格編號：D-B11-01質(zhì)量管理員：日期：評價：軟件工具評價：評價的方法與標準：評價結果：推薦的改正措施：改正措施的實行：工程設備的評價質(zhì)量管理員對正在使用的和方案使用的設備資源進行評價，估量所提供的必需的設備、器材和場地是否能滿足軟件開發(fā)的需求，并形成書面報告。表SEQ表\*ARABIC13工程設備評價工程設備評價表格編號：D-B11-02質(zhì)量管理員：日期：評價：工程設備評價〔器材、用戶/測試/場地〕：評價的方法與標準：評價結果：推薦的改正措施：改正措施的實行：工程過程評審任務軟件產(chǎn)品審查過程SQA管理人員評價軟件產(chǎn)品審查過程。檢查軟件產(chǎn)品是否被審查，審查結果是否形成書面報告，結果和問題報告是否與工程的軟件開發(fā)過程相一致。SQA管理人員使用過程審計報告單來報告審查的結果和本任務的完成情況。表SEQ表\*ARABIC14審計評審報告表格編號：D-B05-01評審目的評審日期評審內(nèi)容參加評審人員評審綜述及結論〔可附頁〕：見附件存在的問題及原因〔可附頁〕：見附件整改措施建議〔可附頁〕：見附件審核意見：審核人：年月日批準意見：批準人：年月日編制單位：編制人：年月日工程方案過程工程管理小組需要開展并且文檔化以下方案：軟件開發(fā)方案――通過軟件開發(fā)規(guī)格來引導軟件開發(fā)方案。方案被文檔化，規(guī)定了在軟件開發(fā)生命周期和適當?shù)狞c所工完成確實定的事件、檢查和評審活動。系統(tǒng)測試方案――管理系統(tǒng)測試條件的方案，其包含軟件測試方案。軟件安裝與培訓方案――包含系統(tǒng)安裝和系統(tǒng)用戶練習套件的方案。系統(tǒng)過渡方案――完成新舊系統(tǒng)轉換和手工與系統(tǒng)轉換的方案。系統(tǒng)需求分析過程系統(tǒng)需求分析在系統(tǒng)使用用戶和軟件工程開發(fā)團隊之間建立起對系統(tǒng)和統(tǒng)一理解，確定系統(tǒng)使用用戶對軟件工程需求的協(xié)議，并在后期的開發(fā)過程中不斷地對其進行維護工作。SQA人員應該完成以下的任務：保證在需求定義過程中選擇適當?shù)娜藛T，并且所有人員的需求都被正確、完全的識別。保證所定義的需求是否通過驗證的，是可實行的。保證對需求分配、工作產(chǎn)品、行為識別、檢查和終止途徑的變化管理。保證參加系統(tǒng)需求定義和分配過程的工程人員具有相關領域的工作經(jīng)驗或受過專門的訓練，以此來確保工作的正確執(zhí)行。保證對開發(fā)工作的承諾是與工程的實際關系人通過談判和協(xié)商而得來的。檢驗承諾是否文檔化的，便于交流的、便于檢查的和可被接受的。保證能夠識別出在系統(tǒng)需求分配確定過程中潛在的問題并進行必要的改變。檢驗規(guī)定的過程定義、文檔的需求分配是否伴隨進行并且是被文檔化的。檢驗需求是否經(jīng)過處理的、文檔化的受控的和可回溯的。檢驗需求是否被寫進開發(fā)方案中。系統(tǒng)概要設計過程系統(tǒng)設計需要被文檔化《概要設計說明書》，SQA人員需要完成以下任務：〔1〕檢查一般需求與設計檢查設計評審時是否已確定了與需求有關問題〔如遺漏、模糊不清、不可測試的以及隱含的需求〕。檢查設計是否與需求一致〔如是否有遺漏、不準確的、模糊不清的或不正確的功能〕檢查設計是否充分說明了以下問題：實時需求性能問題可維護性可理解性數(shù)據(jù)庫需求裝入與初始化錯誤處理與恢復用戶界面問題軟件升級〔2〕功能與接口規(guī)格說明檢查每一過程的過程規(guī)格說明是否準確、齊全。檢查是否用精確、不模糊的術語擬訂了過程規(guī)格說明，該過程規(guī)格說明是否清楚地描述了所需的變更。檢查提供給用戶界面的功能中是否適當?shù)乜紤]了人的因素。檢查是否規(guī)定了哪些地方需求進行錯誤檢查、錯誤處理和恢復。檢查接口是否與模塊使用一致，是否遺漏了接口，是否有多余的接口。檢查是否將接口規(guī)定到可確保對其進行驗證的足夠詳細程度。檢查設計是否遵循已確立的符號約定。系統(tǒng)詳細設計過程詳細設計需要被文檔化《詳細設計說明書》，SQA人員需要完成以下任務：〔1〕檢查需求可跟蹤性檢查模塊或接口的詳細設計是否實現(xiàn)了其需求。檢查對該模塊或接口的審查是否識別出軟件需求規(guī)格說明書中存在的問題，例如，是否有遺漏、模糊不清、相互矛盾、不可測試或隱含的需求。檢查該模塊或接口的詳細設計是否符合其概要設計需求。檢查詳細設計審查是否識別出概要設計中存在的問題。檢查對所有功能完全、準確地進行描述是否到達足夠詳細的程度。檢查是否完全、準確地描述了所有的接口，包括關鍵字或位置參數(shù)、字段描述符、屬性、范圍和限制。檢查詳細設計文檔內(nèi)容，即邏輯數(shù)據(jù)，所有內(nèi)部定義的數(shù)據(jù)是否完全、前后一致，沒有額外的數(shù)據(jù)?！?〕檢查結構與接口檢查在系統(tǒng)與子系統(tǒng)級，所有的組件和模塊是否都在系統(tǒng)體系結構模型上都被確定。檢查分解等級是否足以確定所有的模塊。檢查進一步分解是否能夠識別更多的模塊。檢查是否已經(jīng)清楚、準確地確定了系統(tǒng)/子系統(tǒng)中的單元與模塊之間的所有接口。檢查后續(xù)的分解是否能得到更詳細的結果。檢查模塊是否正在執(zhí)行多于一個的特定功能?！?〕檢查邏輯性檢查是否有任何邏輯錯誤。檢查是否測試了所有的唯一值，是否測試了所有的位置值，增量和循環(huán)計數(shù)器是否都被適當?shù)爻跏蓟?，變量和?shù)據(jù)區(qū)在使用之前是否都被初始化。檢查被審查模塊的表處理起始與結束是否正確，中斷隊列處理是否正確，決策表邏輯是否正確，計算精度和準確是否高。檢查是否為確保代碼的正確執(zhí)行適當?shù)胤峙淞诵畔?yōu)先級。檢查信息的處理順序是否正確。檢查是否存在數(shù)據(jù)處理、數(shù)據(jù)緩沖區(qū)或表格錯誤，是否存在字段更新不正確、數(shù)據(jù)區(qū)使用沖突、初始化或更新不完全、數(shù)據(jù)屬性不一致或無效現(xiàn)象。檢查是否正確定義了過程調(diào)用和返回接口，是否正確定義了調(diào)用和返回參數(shù)，語法是否正確。〔4〕檢查性能檢查內(nèi)存和時間分配是否合理并能得到。〔5〕檢查錯誤處理和恢復檢查是否有適當?shù)腻e誤條件測試。檢查是否認義了那些出錯概率高或錯誤結果對系統(tǒng)是致命的錯誤條件。檢查返回代碼是否經(jīng)過確證。檢查返回信息是否可理解。檢查程序是否能夠從模塊或過程失效、操作系統(tǒng)失效、中斷、硬件失效狀態(tài)成功地進行錯誤恢復。〔6〕檢查可測試性和可擴展性檢查設計是否可理解〔即便于閱讀、符合邏輯性〕、可維護〔即無模糊不清的邏輯〕、可測試〔即可用合理的測試數(shù)目對其測試〕?！?〕檢查耦合和內(nèi)聚檢查用標準耦合和內(nèi)聚評價設計。編碼和測試過程〔1〕測試的規(guī)劃按照工程的實際情況確定各測試階段的目標和策略。這個過程將輸出《測試方案》，明確要完成的測試活動，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。測試規(guī)劃與軟件開發(fā)活動同步進行。SQA組人員在需求分析階段，要完成《測試方案》；在設計階段，要完成《集成測試方案》；在編碼實現(xiàn)階段，要完成《單元測試方案》；在提交顧客前，要完成《系統(tǒng)測試方案》和《內(nèi)部驗收測試方案和方案》；在試運行時，要完成《驗收測試方案》。對于測試方案的修訂局部，需要進行重新評審。圖SEQ圖\*ARABIC64測試體系流程圖〔2〕測試設計根據(jù)各階段的測試方案設計測試方案。測試設計過程輸出的是各測試階段使用的測試用例。測試設計的另一項內(nèi)容是回歸測試設計，即確定回歸測試的用例集。對于測試用例的修訂局部，也要求進行重新評審。〔3〕測試實施使用測試用例運行程序，將獲得的運行結果與預期結果進行比擬和分析，記錄、跟蹤和管理軟件缺陷，最終得到《測試分析報告》?！?〕配置管理測試配置管理是軟件配置管理的子集，作用于測試的各個階段。其管理對象包括測試方案、測試方案〔用例〕〔一般測試方案與測試用例結合〕、測試版本、測試工具及環(huán)境、測試分析報告等?！?〕資源管理包括對人力資源和工作場所，以及相關設施和技術支持的管理?！?〕安裝與測試環(huán)境配置測試環(huán)境是測試實施的一個重要階段，測試環(huán)境適合與否會嚴重影響測試結果的真實性和正確性。測試環(huán)境包括硬件環(huán)境和軟件環(huán)境，硬件環(huán)境指測試必需的效勞器、客戶端、網(wǎng)絡連接設備，以及打印機/掃描儀等輔助硬件設備所構成的環(huán)境；軟件環(huán)境指被測軟件運行時的操作系統(tǒng)、數(shù)據(jù)庫及其他應用軟件構成的環(huán)境。在實際測試中，軟件環(huán)境又可分為主測試環(huán)境和輔測試環(huán)境。主測試環(huán)境是測試軟件功能、平安可靠性、性能、易用性等大多數(shù)指標的主要環(huán)境。一般來說，配置主測試環(huán)境可遵循以下內(nèi)容：符合軟件運行的最低要求。測試環(huán)境首先要保證能支撐軟件正常運行。選用比擬普及的操作系統(tǒng)和軟件平臺。一般我們會采用如“Windowsxp+MSOffice2003營造相對簡單、獨立的測試環(huán)境。除了操作系統(tǒng)，測試機上只安裝軟件運行和測試必需的軟件，以免不相關的軟件影響測試實施。無毒的環(huán)境。利用有效的正版殺毒軟件檢測軟件環(huán)境，保證測試環(huán)境中沒有病毒。將程序單位的所有程序以及用到的公共子程序安裝到指定的多用戶測試環(huán)境，該環(huán)境應與程序?qū)嶋H運行環(huán)境一致；提交SQA組進行測試時，工程經(jīng)理必須提交《需求規(guī)格說明書》、《概要設計說明書》、效勞器設置參數(shù)和將系統(tǒng)編譯成可執(zhí)行文件，及各種類相應的資料?！?〕各階段測試流程需求階段測試

質(zhì)量保證經(jīng)理制定《測試方案》，確定要完成測試的類型，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。設計&編碼階段測試

測試組長應組織測試組成員在設計&編碼階段，編寫《集成測試方案》〔方案中包括測試用例〕和《單元測試方案》〔方案中包括測試用例〕。在進行單元測試時，測試員將每一問題填寫《測試記錄：<模塊單元測試記錄表>》，所有的單元測試完成后，再聚集成《單元測試總結報告》。圖SEQ圖\*ARABIC65設計&編碼階段測試工作〔8〕集成、系統(tǒng)、驗收階段測試測試組長應組織測試組成員進行集成測試，測試員將每一問題填寫《測試記錄：<軟件集成測試表>》，所有的集成測試完成后，再聚集成《集成測試總結報告》。在提交顧客前，測試組要完成《系統(tǒng)測試方案》，按方案進行系統(tǒng)測試，并將測試結果反映在《系統(tǒng)測試綜合報告》。測試組完成系統(tǒng)測試后，提交《需求規(guī)格說明書》、《概要設計說明書》效勞器設置參數(shù)和將系統(tǒng)編譯成可執(zhí)行文件交SQA組進行內(nèi)部驗收測試，SQA組人員每日填寫《工程測試bug報告》，在下班前提交工程經(jīng)理或開發(fā)人員，請工程經(jīng)理確定BUG的處理時間，SQA組人員再按BUG的處理時間，更新系統(tǒng)后再進行回歸測試，直到不出現(xiàn)BUG為止。最后，根據(jù)本次測試情況編寫《測試分析報告》。圖SEQ圖\*ARABIC66集成、系統(tǒng)階段測試工作流程工程文檔管理作為軟件產(chǎn)品的一局部，軟件開發(fā)的文檔的質(zhì)量直接影響產(chǎn)品的質(zhì)量。進行工程文檔的管理即深圳市規(guī)劃局對本次開發(fā)活動的要求，也是我公司軟件開發(fā)的標準性要求之一。有關的工程文檔管理工作內(nèi)容如下：文檔編制方案文檔方案是整個工程方案的一個獨立文檔，編寫文檔方案并把它分發(fā)給全體開發(fā)組成員，作為文檔重要性的具體依據(jù)和管理部門文檔工作責任的備忘錄。文檔方案一般包括以下幾方面內(nèi)容：列出應編制文檔的目錄提示編制文檔應參考的標準指定文檔管理員提供編制文檔所需要的條件，落實文檔編寫人員及編制工具明確保證文檔質(zhì)量的方法，為了確保文檔內(nèi)容的正確性、合理性，應采取一定的措施，如評審、鑒定等繪制進度表，以圖表形式列出在各階段應產(chǎn)生的文檔、編制人員、編制日期、完成日期、評審日期等規(guī)定每個文檔要到達的質(zhì)量等級為了到達期望的結果必須考慮哪些外部因素文檔方案還確定該方案和文檔的分發(fā)，并且明確表達與文檔工作的所有人員的職責。文檔種類根據(jù)深圳市規(guī)劃局的具體要求及我公司《文檔管理制度》的要求，本工程提交的所有文檔均符合GB8567《計算機軟件產(chǎn)品開發(fā)文件編制指南》和GB/TI1457-89《軟件工程術語》。本次開發(fā)活動將形成以下文檔〔1〕開發(fā)文檔根本的開發(fā)文檔：投標文件和工程任務書需求分析報告需求規(guī)格說明書工作方案驗收標準總體設計說明書詳細設計說明書測試分析報告操作手冊試運行維護、測試報告驗收報告質(zhì)量保證方案、標準、進度總結報告〔2〕管理文檔工程管理過程所產(chǎn)生的文檔：開發(fā)過程的每個階段的進度和進度變更的記錄軟件變更情況記錄過程評審表文檔管理職責為了作好工程的文檔管理工作，工程的文檔管理人員具有以下職責：建立編制、登記、出版工程文檔的各種策略；把文檔方案作為整個開發(fā)工作的一個組成局部；建立確定文檔質(zhì)量、測試質(zhì)量和評審質(zhì)量的各種方法規(guī)程；為文檔的各個方面，確定和準備各種標準和指南；積極支持文檔工作以形成在開發(fā)工作中自覺編制文檔的團隊風氣；不斷檢查已建立起來的過程，以保證符合策略和各種規(guī)程并遵守有關標準和指南。文檔的質(zhì)量要求工程開發(fā)過程中所產(chǎn)生的文檔要滿足以下要求：文檔需要覆蓋整個軟件生存期，文檔在貫穿軟件開發(fā)過程中必須是可用的和可維護的。在開發(fā)完成后，文檔應滿足軟件的使用、維護、增強、轉換或傳輸。文檔應可管理的，工程經(jīng)理應準備文檔產(chǎn)品、進度、可靠性、資源，質(zhì)量保證和評審規(guī)程的詳細方案大綱。文檔應適合于它的讀者，讀者可以是工程經(jīng)理、分析員、無計算機經(jīng)驗的專業(yè)人員、維護人員、文書人員等，根據(jù)任務的執(zhí)行，文檔具有不同的詳細程度，針對不同的讀者，應設計不同類型的文檔。文檔應貫穿到整個開發(fā)過程中，應充分表達文檔的作用和限制，即文檔應指導全部開發(fā)過程。文檔標準應被標識和使用，應盡可能采納公司的文檔編制標準和指南。軟件配置管理公司成立配置管理小組〔SCM〕進行配置管理，同時使用配置管理軟件MicrosoftVisualSourcesafe工具進行工程標識項、文檔和代碼等的配置管理。配置管理的主要內(nèi)容為：批準的控制項列表、需求、產(chǎn)品設計、程序源代碼、測試用例和測試結果、產(chǎn)品設計標準〔如模塊和系統(tǒng)命名標準、接口標準、標準信息和屏幕以及可重用的程序庫〕、文檔代碼的版本、系統(tǒng)基準等。目標使系統(tǒng)的軟件配置管理活動有方案性；保障軟件開發(fā)過程的更動在控制下進行。相關政策建立一個負責協(xié)調(diào)和實施工程軟件配置管理的組〔即SCM組〕；提供工程經(jīng)費中至少2%的費用用于軟件配置管理；在工程的整個生存周期內(nèi)實行SCM；工程要建立專門的產(chǎn)品控制庫用來存儲軟件生存周期內(nèi)所產(chǎn)生的各種管理文檔和技術文檔，源代碼及其可執(zhí)行代碼，運行時所需的各種數(shù)據(jù)以及相應的存儲介質(zhì)；SCM組的成員要通過專門的培訓，使其能完成有關SCM的活動；軟件工程的其他成員〔例如軟件工程組、軟件質(zhì)量保證組的成員〕要經(jīng)過的SCM的培訓。實施與檢查在整個工程實施的早期階段成立軟件配置管理組〔SCM〕，制定SCM方案；定期對SCM方案進行評審，參加人員包括受影響的組和個人；按照SCM方案，對所有軟件配置管理項的更動請求和問題報告，進行申請、記錄、評審、批準和跟蹤等控制管理活動；高層管理者定期〔在工程的實施過程中不少于3次〕參與SCM評審活動；工程負責人應參加SCM評審活動，并對SCM組提出的問題做出響應；軟件質(zhì)量保證〔SQA〕組也應當評審和審計有關SCM的活動和工作產(chǎn)品，并報告其結果。工程進度管理在系統(tǒng)開發(fā)過程的每一步，開發(fā)方將嚴格按照相應的標準和標準執(zhí)行，特別重視工程質(zhì)量的保證，以便最終生成高質(zhì)量的軟件產(chǎn)品。工程組周例會工程管理人員每周召開一次例會，通報上周工作情況，存在問題，協(xié)調(diào)各小組開發(fā)人員的工作，針對問題采取相應的對策，調(diào)整以后的方案。工程管理協(xié)調(diào)小組會議工程管理人員每兩周召開一次工程管理協(xié)調(diào)小組會議，用戶方也派代表參加，評審工程進展情況并協(xié)調(diào)各方工作。方案的維護工程組每月一次將工程進度報揭發(fā)送到工程控制、公司管理部門和用戶方，其中詳述工程的進展情況，并列出所有未按方案完成的工作，同時注明未完成的原因，對方案進行及時修正與維護。工作考核與獎懲開發(fā)方將根據(jù)合同規(guī)定制訂嚴密的工作方案，并根據(jù)工程組每個人的工作質(zhì)量、工作效率、工作態(tài)度、團隊精神設立相應的獎懲制度，鼓勵按時完成任務，從而保證“深圳市城市規(guī)劃空間信息數(shù)據(jù)庫建設”工程的建設進度。風險識別與控制風險貫穿于工程的整個生命周期中，因而風險管理是個持續(xù)的過程，我公司建立良好的風險管理機制保證工程的成功實施。風險管理是工程管理流程與標準中的重要組成局部，包括以下幾方面：〔1〕風險管理規(guī)那么〔2〕明確風險管理崗位與職責〔3〕不斷豐富風險數(shù)據(jù)庫、更新風險識別檢查列表、注重工程風險管理經(jīng)驗的積累和總結。由于風險是在工程開始之后才開始對工程的開發(fā)起負面的影響，所以風險分析的缺乏，或是風險回避措施不得力，都很有可能造成軟件開發(fā)的失敗。風險分析是在事前的一種估計，憑借一定的技術手段和豐富的經(jīng)驗，根本能夠?qū)こ痰娘L險做出比擬準確的估計，經(jīng)過慎重的考慮提出可行的風險回避措施，是防止損失的重要環(huán)節(jié)。風險的識別就是確定何種風險事件可能影響工程。在工程開始、每個工程階段中間、主要范圍變更批準之前都要進行風險識別，實際上它在整個工程生命周期內(nèi)都是一個連續(xù)的過程，通過識別的和可預測的風險，工程管理者在可能時預先采取措施防止這些風險，必要時控制這些風險。風險識別經(jīng)過我公司長期從事信息系統(tǒng)的開發(fā)，積累了一些風險管理的經(jīng)驗，我們總結出在軟件開發(fā)的各個階段可能發(fā)生以下這些風險：〔1〕需求分析階段在這個階段進行大局部需求分析、少局部設計〔大局部業(yè)務建模和需求、少局部分析設計〕。工程目標不清工程范圍不明確〔范圍太大太小都不可以〕用戶參與少或和用戶溝通少對業(yè)務了解不夠?qū)π枨罅私獠粔驔]有進行可行性研究〔2〕設計階段在這個階段進行大局部設計、少局部編碼〔大局部分析設計，局部實施及測試，開始考慮部署〕工程隊伍缺乏經(jīng)驗，如缺乏有經(jīng)驗的系統(tǒng)分析員沒有變更控制方案，以至于變更沒有依據(jù)，該變更的不變，不該變的也變，這樣得來的設計勢必會失敗或者偏離用戶需求倉促方案，可能帶來進度方面的風險漏項，由于設計人員的疏忽某個功能沒有考慮進去〔3〕實施階段在這個階段進行大局部編碼和測試，也涉及少局部設計〔大局部實施及測試，局部部署〕，如：設計變更或補充設計。開發(fā)環(huán)境沒有具備好設計錯誤帶來的實施困難程序員開發(fā)能力差，或程序員對開發(fā)工具不熟工程范圍改變〔突然要增加或修改一些功能，需要重新考慮設計〕工程進度改變〔要求提前完成任務等〕人員離開，在一個工程內(nèi)軟件開發(fā)工作有一定的連續(xù)性，需要移交和交接，有時人員離開對工程的影響會很大開發(fā)團隊內(nèi)部溝通不夠，導致程序員對系統(tǒng)設計的理解上有偏差沒有有效的備份方案沒有切實可行的測試方案測試人員經(jīng)驗缺乏〔4〕收尾階段在這個階段進行安裝及維護〔大局部部署〕。質(zhì)量差客戶不滿意設備沒有按時到貨資金不能回收風險的控制制定風險管理規(guī)那么，標準風險管理〔1〕風險管理的原那么全面周到原那么符合本公司開展總目標原那么量力而行原那么本錢效益比擬原那么注重運用商業(yè)保險〔2〕風險管理根本程序風險識別風險衡量風險處理風險管理效果評價風險應對方法工程中的風險永遠不能全部消除，我公司針對上述的風險采取應對方法，使損失降底到最少?！?〕防止方法通過分析找出來發(fā)生風險事件的原因，消除這些原因來防止一些特定的風險事件發(fā)生。比方：如何防止客戶不滿意。客戶不滿意有兩種情況，一種情況是沒有判斷客戶滿意度的依據(jù)，即沒有雙方互相認可的客戶驗收標準，還有一種是開發(fā)方?jīng)]有到達驗收標準，即沒有滿足用戶需求。不管是哪一種，開發(fā)方都有不可推卸的責任，只要做好以下環(huán)節(jié)完全可以防止：業(yè)務建模階段要讓客戶參與需求階段要多和客戶溝通，了解客戶真正的需求目標系統(tǒng)的模型或DEMO系統(tǒng)要向客戶演示，并得到反響意見，如果反響的意見和DEMO系統(tǒng)出入比擬大時，一定要將修改后的DEMO系統(tǒng)再次向客戶演示，直到雙方都達成共識為止要有雙方認可的驗收方案和驗收標準做好變更控制和配置管理〔2〕減輕通過降低風險事件發(fā)生的概率或得失量來減輕對工程的影響。也可以采用風險轉移的方法來減輕風險對工程帶來的影響。工程預算中考慮應急儲藏金是另一種降低風險影響的方法。比方：經(jīng)過風險識別發(fā)現(xiàn)，工程組的程序員對所需開發(fā)技術不熟。可以采用熟悉的技術來減輕工程在本錢或進度方面的影響。也可以事先進行培訓來減輕對工程的影響?！?〕接受接受風險造成的后果。比方：為了防止自然災害造成的后果，在一個大的軟件工程中考慮了異地備份中心。開發(fā)應對措施〔1〕軟件技術風險“深圳市數(shù)據(jù)更新維護管理系統(tǒng)”采用C/S結構，采用全組件COM開發(fā)技術，從技術成熟度上說不存在風險，但為了實現(xiàn)良好的軟件構架和穩(wěn)定的組件，與傳統(tǒng)開發(fā)方法比擬，有相當?shù)亩嗟念~外工作需要做，這會給工程工期帶來較大的風險?；乇芎涂刂七@局部風險的方法是在工程進行的過程中不斷的對該階段進行風險估計和指定有效的里程碑。同時采用"范例"方式提高開發(fā)人員的構件組件的分析識別能力，適時調(diào)整構件組件的數(shù)量和粒度?！?〕軟件過程風險的識別和控制軟件需求階段的風險軟件的開發(fā)是以用戶的需求開始，我公司派出在系統(tǒng)開發(fā)和業(yè)務有經(jīng)驗的人員對深圳市規(guī)劃局進行需求調(diào)研，并在調(diào)研的過程中，與局進行廣泛的交流和確認，以書面的形式形成《用戶需求》這一重要的文檔，該文檔對每一需求都要進行需求標識，系統(tǒng)開發(fā)人員根據(jù)客戶的需求建立系統(tǒng)原型，說明和糾正用戶對需求的不確定性，最后得出經(jīng)雙方確認簽字的用戶需求。設計階段的風險設計的主要目的在于軟件的功能正確的反映了需求。設計階段的主要任務是完成系統(tǒng)體系結構的定義，使之能夠完成需求階段的即定目標和檢驗需求的一致性和需求分析的完整性和正確性?！吧钲谑谐鞘幸?guī)劃空間信息數(shù)據(jù)庫建設”工程的兩個重大的軟件技術是面向?qū)ο蟮臉嫾突谖④浀腃OM組件技術。組件和構件技術都是為了提高軟件的可靠性和軟件的可擴展性而采用的技術手段。從技術上實現(xiàn)良好的軟件構架和穩(wěn)定的組件。開發(fā)階段的風險源代碼本身也是文檔的一局部，同時它又是將來運行于計算機系統(tǒng)之上的實體。我公司制定了源代碼書寫的標準性和可讀性標準，并運行監(jiān)督體制監(jiān)督開發(fā)人員，使系統(tǒng)代碼標準化，把屬于程序員自身個性風格的成分引入代碼的比例降到最低限度，從而減小了系統(tǒng)整合的風險。并且組織專門的測試小組，對系統(tǒng)進行單元測試、集成測試、確認測試、系統(tǒng)測試和性能測試，力求盡早、盡多地發(fā)現(xiàn)系統(tǒng)的缺陷和錯誤。維護階段的風險通過多年來廣泛的社會實踐，我公司已形成了一套完善的立體效勞架構，擁有一批經(jīng)驗豐富的技術支持、開發(fā)和培訓人員以及專門對用戶需求而設計的各項效勞，以保障用戶在不同應用階段、不同層次、不同規(guī)模的效勞需求得到滿足。制定工程監(jiān)督制度，明確風險管理崗位與職責我們在以往的工程建設中積累了許多工程管理的經(jīng)驗，得出回避和控制軟件管理風險的唯一方法就是設立監(jiān)督制度，工程開發(fā)中任何較大的決定都必須有主要技術環(huán)節(jié)由用戶參與進行的。在“深圳市城市規(guī)劃空間信息數(shù)據(jù)庫建設”工程中工程監(jiān)督由工程開發(fā)中的質(zhì)量監(jiān)督組來實施。

具體的主要技術人員和管理人員名單請參閱投標商務資料。一般參與軟件開發(fā)的人員〔包括管理者和技術人員〕和其責任進行分析如下：工程經(jīng)理1人主要職責：進行全局把握，側重