軟件監(jiān)理規(guī)范

軟件監(jiān)理規(guī)范

（征求意見稿）

山東正中

目錄

總則........................................................................2

第一部分術語...................................................................4

第二部分組織結構和人員資質....................................................8

第三部分監(jiān)理工作流程.........................................................11

第四部分監(jiān)理控制要點.........................................................21

第五部分：監(jiān)理工作手冊.........................................................22

第六部分：文檔模板、流程.......................................................37

第七部分：監(jiān)理依據(jù).............................................................56

第八部分：問題與解答..........................................錯誤！未定義書簽。

總則

為了提高建設工程監(jiān)理水平，規(guī)范建設工程監(jiān)理行為，編制本規(guī)范。

本規(guī)范適用于新建、擴建、改建信息化工程應用系統(tǒng)部分（軟件）的各個工作階

段的監(jiān)理工作。

實施信息化工程監(jiān)理前，監(jiān)理單位必須與建設單位簽訂書面信息化工程委托監(jiān)理

合同，合同中應包括監(jiān)理單位對工程質量、資金、進度進行全面控制和管理的條款。

建設單位與承建單位之間與信息化工程合同有關的聯(lián)系活動應通過監(jiān)理單位進行。

工程監(jiān)理應實行總監(jiān)理工程師負責制。

監(jiān)理單位應公正、獨立、自主地開展監(jiān)理工作，維護建設單位和承建單位的合法

權益。

軟件工程監(jiān)理除應符合本規(guī)范外，還應符合國家現(xiàn)行的有關強制性標準、規(guī)范的

規(guī)定。

第一部分術語

1.項目監(jiān)理機構：監(jiān)理單位派駐工程項目負責履行委托監(jiān)理合同的組織機構。

2.監(jiān)理工程師：取得國家監(jiān)理工程師執(zhí)業(yè)資格證書并經(jīng)注冊的監(jiān)理人員。

3.總監(jiān)理工程師：由監(jiān)理單位法定代表人書面授權，全面負責委托監(jiān)理合同的履行、

主持項目監(jiān)理機構工作的監(jiān)理工程師。

4.總監(jiān)理工程師代表：經(jīng)監(jiān)理單位法定代表人同意，由總監(jiān)理工程師書面授權，代

表總監(jiān)理工程師行使其部分職責和權力的項目監(jiān)理機構中的監(jiān)理工程師。

5.專業(yè)監(jiān)理工程師：根據(jù)項目監(jiān)理崗位職責分工和總監(jiān)理工程師的指令，負責實施

某一專業(yè)或某一方面的監(jiān)理工作，具有相應監(jiān)理文件簽發(fā)權的監(jiān)理工程師。

6.監(jiān)理員：經(jīng)過監(jiān)理業(yè)務培訓，具有同類工程相關專業(yè)知識，從事具體監(jiān)理工作的

監(jiān)理人員。

7.監(jiān)理規(guī)劃：在總監(jiān)理工程師的主持下編制、經(jīng)監(jiān)理單位技術負責人批準，用來指

導項目監(jiān)理機構全面開展監(jiān)理工作的指導性文件。

8.監(jiān)理實施細則：根據(jù)監(jiān)理規(guī)劃，由專業(yè)監(jiān)理工程師編寫，并經(jīng)總監(jiān)理工程師批準,

針對工程項目中某一專業(yè)或某一方面監(jiān)理工作的操作性文件。

9.工程例會：由項目監(jiān)理機構主持的，在工程實施過程中針對工程質量、造價、進

度、合同管理等事宜定期召開的、由有關單位參加的會議。

10.工程變更：在工程項目實施過程中，按照合同約定的程序對部分或全部工程在需

求、功能、技術指標、工程數(shù)量及施工方法等方面做出的改變。

11.工程計量：根據(jù)設計文件及承建合同中關于工程量計算的規(guī)定，項目監(jiān)理機構對

承建單位申報的已完成工程的工程量進行的核驗。

12.見證：由監(jiān)理人員現(xiàn)場監(jiān)督某工序全過程完成情況的活動。

13.旁站：在關鍵部位或關鍵工序施工過程中，由監(jiān)理人員在現(xiàn)場進行的監(jiān)督活動。

14.巡視：監(jiān)理人員對正在施工的部位或工序在現(xiàn)場進行的定期或不定期的監(jiān)督活

動。

15.平行檢驗：項目監(jiān)理機構利用一定的檢查或檢測手段，在承建單位自檢的基礎上,

按照一定的比例獨立進行檢查或檢測的活動。

16.費用索賠：根據(jù)承建合同的約定，合同一方因另一方原因造成本方經(jīng)濟損失，通

過監(jiān)理工程師向對方索取費用的活動。

17.臨時延期批準：當發(fā)生非承建單位原因造成的持續(xù)性影響工期的事件，總監(jiān)理工

程師所作出暫時延長合同工期的批準。

18.延期批準：當發(fā)生非承建單位原因造成的持續(xù)性影響工期事件，總監(jiān)理工程師所

作出的最終延長合同工期的批準。

19.驗收準則：軟件產品要符合某一測試階段必須滿足的準則，或軟件產品滿足交貨

要求的準則。

20.驗收測試：確定一系統(tǒng)是否符合其驗收準則，使客戶能確定是否接收此系統(tǒng)的正

式測試。

21.需方：從供方獲得或得到一個系統(tǒng)、產品或服務的一個機構。注：需方可以是

買主、客戶、擁有者、用戶、采購人。

22.供方：按照所簽的合同向需方提供系統(tǒng)、產品或服務的一個機構（是合同當事人、

生產者、賣方、批發(fā)商的同義詞）。注：需方可以指定它的機構中的某一部門做

為供方。

23.應用軟件：解決屬于專用領域的，非計算機本身問題的軟件。

24.變更管理：提議作一項更動并對其進行估計、同意或拒絕、調度和跟蹤的過程。

25.代碼審計：由某人、某小組、或借助某種工具對源代碼進行的獨立的審查，以驗

證其是否符合軟件設計文件和程序設計標準。還可能對正確性和有效性進行估

計。

26.配置：計算機系統(tǒng)或網(wǎng)絡按照其功能部件的特點、數(shù)量和主要特性而確定的排列。

具體地講，配置一詞可以指硬件配置或軟件配置；為確定系統(tǒng)或系統(tǒng)組成部分

的特定版本而提出的需求、設計和實現(xiàn)；在技術文檔中制定的并在產品中體現(xiàn)的

硬件、軟件的功能和（或）物理特性。

27.配置管理：標識和確定系統(tǒng)中配置項的過程，在系統(tǒng)整個生存周期內控制這些項

的投放和吏動，記錄并報告配置的狀態(tài)和更動要求，驗證配置項的完整性和正確

性。

對下列工作進行技術和行政指導與監(jiān)督的一套規(guī)范：

?對一配置項的功能和物理特性進行標識和文件編制工作；

?控制這些特性的更動情況；

?記錄并報告對這些更動進行的處理和實現(xiàn)的狀態(tài)。

28.合同：通過法律約束當事雙方的一個協(xié)議，或是在一個機構內部為了提供服務的

一個內部協(xié)議。

29.交付：軟件研制周期中的一個階段。在此階段上將產品提交給計劃中的用戶供其

使用。軟件研制周期中的一個階段。在此階段上產品由其預定的用戶接受。

30.評審：對現(xiàn)有的或提出的產品所做的正式評估和審查，其目的是找出可能會影響

產品，過程或服務工作的適用性和環(huán)境方面的設計缺陷并采取補救措施，以及（或

者）找出在性能、安全性和經(jīng)濟方面的可能的改進。

31.文檔：為了對活動、需求、過程或結果進行描述、定義、規(guī)定、報告或認證的任

何書面或圖示的信息。

32.質量：產品或服務的全部性質和特征，能表明產品滿足給定的要求。

33.招標：需方使用的一份文件，用來向潛在的投標人表示它要獲得某特定系統(tǒng)、產

品或服務的意圖。

34.需求：用戶為解決某一問題或達到某個目標所需要的條件或能力。系統(tǒng)或系統(tǒng)部

件為滿足或具有的條件或能力以滿足合同、標準、規(guī)格說明或其它正式的強制性

文件。所有需求的集合形成了以后開發(fā)系統(tǒng)或系統(tǒng)部件的基礎。

35.規(guī)模估計：對一個系統(tǒng)或系統(tǒng)部件所需要的源程序的行數(shù)或計算機存儲的總量的

估計。

36.軟件開發(fā)周期：從決定開發(fā)一個軟件產品開始到產品交付為止的時間間隔。這個

周期通常包括需求階段、設計階段、實現(xiàn)階段、測試階段，有時還包括安裝和

驗收階段。從決定開發(fā)軟件產品開始到開發(fā)者不再改進產品時為止的時間周期。

37.軟件開發(fā)過程：把用戶要求轉化為軟件需求，把軟件需求轉化為設計，用代碼來

實現(xiàn)設計，對代碼進行測試，完成文檔編制，并確認軟件可以投入運行性使用的

過程。

38.軟件工程：軟件開發(fā)、運行、維護和引退的系統(tǒng)方法。

39.系統(tǒng)：一個完整的整體。它由種類不同的、相互作用的、專門的結構和子功能部

件所組成。

40.測試：由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部件的過程，以驗證它是否滿

足規(guī)定的需求；或識別出期望的結果和實際結果之間有無差別。

41.測試用例：測試數(shù)據(jù)及與之相關的測試規(guī)程的一個特定的集合。它是為了特定目

的（如考察特定程序路徑或驗證是否符合特定的需求）而產生出來的。

42.測試范圍：一個范圍，在此范圍內測試程序測試系統(tǒng)需求能否滿足。

43.測試計劃：一個文件，它敘述了對于預定的測試活動將要采取的途徑。典型的計

劃中包括：標識要測試的項目、要完成的測試、測試進度表、人事安排要求、報

告要求、評價準則，以及任何臨界的要求的臨時計劃。

44.測試報告：描述對系統(tǒng)或系統(tǒng)部件進行的測試行為及結果的文件。

第二部分組織結構和人員資質

監(jiān)理單位履行施工階段的委托監(jiān)理合同時，必須在施工現(xiàn)場建立項目監(jiān)理機構。項

目監(jiān)理機構在完成委托監(jiān)理合同約定的監(jiān)理工作后可撤離施工現(xiàn)場。

項目監(jiān)理機構的組織形式和規(guī)模，應根據(jù)委托監(jiān)理合同規(guī)定的服務內容、服務期限、

工程類別、規(guī)模、技術復雜程度、工程環(huán)境等因素確定。

監(jiān)理人員應包括總監(jiān)理工程師、專業(yè)監(jiān)理工程師和監(jiān)理員，必要時可配備總監(jiān)理工

程師代表。

總監(jiān)理工程師應由具有三年以上同類工程監(jiān)理工作經(jīng)驗的人員擔任；總監(jiān)理工程

師代表應由具有二年以上同類工程監(jiān)理工作經(jīng)驗的人員擔任；專業(yè)監(jiān)理工程師應由具

有一年以上同類工程監(jiān)理工作經(jīng)驗的人員擔任。

項目監(jiān)理機構的監(jiān)理人員應專業(yè)配套、數(shù)量滿足工程項目監(jiān)理工作的需要。

監(jiān)理單位應于委托監(jiān)理合同簽訂后十天內將項目監(jiān)理機構的組織形式、人員構成及

對總監(jiān)理工程師的任命書面通知建設單位。當總監(jiān)理工程師需要調整時，監(jiān)理單位應

征得建設單位同意并書面通知建設單位；當專業(yè)監(jiān)理工程師需要調整時，總監(jiān)理工程

師應書面通知建設單位和承建單位。

監(jiān)理人員的職責

一名總監(jiān)理工程師只宜擔任一項委托監(jiān)理合同的項目總監(jiān)理工程師工作。當需要同

時擔任多項委托監(jiān)理合同的項目總監(jiān)理工程師工作時，須經(jīng)建設單位同意，且最多不

得超過三項。

總監(jiān)理工程師應履行以下職責：

1確定項目監(jiān)理機構人員的分工和崗位職責；

2主持編寫項目監(jiān)理規(guī)劃、審批項目監(jiān)理實施細則，并負責管理項目監(jiān)理機構的

日常工作；

3審查分包單位的資質，并提出審查意見；

4檢查和監(jiān)督監(jiān)理人員的工作，根據(jù)工程項目的進展情況可進行監(jiān)理人員調配，

對不稱職的監(jiān)理人員應調換其工作；

5主持監(jiān)理工作會議，簽發(fā)項目監(jiān)理機構的文件和指令；

6審定承建單位提交的開工報告、施工組織設計、技術方案、進度計劃；

7審核簽署承建單位的申請、支付證書和竣工結算；

8審查和處理工程變更；

9主持或參與工程質量事故的調查；

10調解建設單位與承建單位的合同爭議、處理索賠、審批工程延期；

11組織編寫并簽發(fā)監(jiān)理月報、監(jiān)理工作階段報告、專題報告和項目監(jiān)理工作總

結；

12審核簽認分部工程和單位工程的質量檢驗評定資料，審查承建單位的竣工申

請，組織監(jiān)理人員對待驗收的工程項目進行質量檢查，參與工程項目的竣工驗收;

13主持整理工程項目的監(jiān)理資料。

總監(jiān)理工程師代表應履行以下職責：

1負責總監(jiān)理工程師指定或交辦的監(jiān)理工作；

2按總監(jiān)理工程師的授權，行使總監(jiān)理工程師的部份職責和權力；

3總監(jiān)理工程師不得將下列工作委托總監(jiān)理工程師代表：

1）根據(jù)工程項目的進展情況進行監(jiān)理人員的調配，調換不稱職的監(jiān)理人員；

2）主持編寫工程項目監(jiān)理規(guī)劃及審批監(jiān)理實施方案；

3）簽發(fā)工程開工/復工報審表、工程暫停令、工程款支付證書、工程項目的

竣工驗收文件；

4）審核簽認竣工結算；

5）調解建設單位和承建單位的合同爭議，處理索賠，審批工程延期。

1負責編制本專業(yè)的監(jiān)理實施計劃，經(jīng)總監(jiān)批準后組織實施；

2負責本專業(yè)監(jiān)理工作的具體實施；

3審查施工方提交的涉及本專業(yè)的計劃、設計、方案、申請、變更、報告等，并

向總監(jiān)理工程師提出報告；

4負責本專業(yè)的測試審核、單元工程驗收，對本專業(yè)的子系統(tǒng)工程驗收提出驗收

意見；

5定期向總監(jiān)理工程師提交本專業(yè)監(jiān)理工作實施情況報告，對重大問題及時向總

監(jiān)理工程師匯報和請示；

6根據(jù)本專業(yè)監(jiān)理工作實施情況做好監(jiān)理日志；

7負責本專業(yè)監(jiān)理資料的收集、匯總及整理，參與編寫監(jiān)理月報；

8檢查施工方投入工程項目的人力、材料、主要設備及其使用、運行狀況，并做

好檢查記錄；

9按專業(yè)分工并配合其它專業(yè)對工程進行巡檢、現(xiàn)場督導、監(jiān)理測試或確認見證

數(shù)據(jù)；

10發(fā)現(xiàn)問題及時指出并向總監(jiān)理工程師報告；

第三部分監(jiān)理工作流程

工程前期階段監(jiān)理

流程

監(jiān)理業(yè)務流程（表1:前期階段）

愉入承建單待蚱現(xiàn)和構業(yè)主單位輸出

（階段開始）

監(jiān)理合同

政策法規(guī)

F

標準規(guī)范

業(yè)務模型分析、規(guī)劃設計

行業(yè)文件

審核報告

1F

專項報告

監(jiān)理招標文件協(xié)助招投標

監(jiān)理合同

招標文件

簽訂承建合同

專項報告

項目啟動申請承建合同

承律合同

合同審核報告

系統(tǒng)實施方案

項目開工準備審核

白狀出庭計劃系統(tǒng)實施方案

審核報告

1F

廿侏出塞沖利

丁田口/hA

審核報告

V

階段結束

流程描述

前期咨詢：提供應用系統(tǒng)建設相關的技術支持服務;

基本業(yè)務模型分析：協(xié)助業(yè)主制定所需應用系統(tǒng)的業(yè)務需求指標；進行基本需求的

調研和分析整理工作，基本上明確應用系統(tǒng)的主體思路，為應用系統(tǒng)建設范圍的確定

提供依據(jù);

應用系統(tǒng)總體規(guī)劃：結合基本需求和應用系統(tǒng)的實施框架結構，協(xié)助業(yè)主對應用系

統(tǒng)進行優(yōu)先級劃分，同時結合國內外的相關類型系統(tǒng)的實施情況，協(xié)助業(yè)主制定系統(tǒng)

的總體實施規(guī)劃；

招投標：必要時協(xié)助業(yè)主進行應用系統(tǒng)的招投標工作；

承建方實力評價：協(xié)助業(yè)主了解承建方的技術實力和管理能力，客觀公正地評價承

建方，為業(yè)主評估、選定承建方提供技術方面的參考意見；

簽訂承建合同：協(xié)助業(yè)主進行應用系統(tǒng)的實施合同的簽訂工作；在承建合同中應明

確要求承建單位接受監(jiān)理方的監(jiān)理；建議業(yè)主單位在承建合同中明確規(guī)定工程所包含

的功能、技術要求、測試標準、驗收要求和質量責任；建議業(yè)主單位在承建合同中明

確工程階段劃分及其質量和進度要求，并依此作為工程階段性付款的依據(jù)；核準投資

預算與付款計劃；

評審系統(tǒng)實施方案：協(xié)助業(yè)主評審系統(tǒng)實施方案的科學性、可行性；協(xié)助業(yè)主審核

系統(tǒng)建設的量化目標以及考核方法；結合業(yè)主的實際情況對實施過程中的風險進行評

估，協(xié)助提出規(guī)避風險的措施和手段；

審核總體進度計劃：審核應用系統(tǒng)承建方的總體實施進度計劃，根據(jù)軟件工程的要

求，審核承建方提出的應用系統(tǒng)總體實施計劃是否合理；

項目啟動會：項目啟動時，召開由業(yè)主、承建方和監(jiān)理方參加的首次會議，明確三

方在項目實施過程中的責任和權利、三方的項目負責人及聯(lián)系方式、項目實施過程中

三方遇到問題的處理流程、監(jiān)理例會的具體時間及周期等，并規(guī)定監(jiān)理方和承建方按

時提交報告。

工程需求階段監(jiān)理

流程

監(jiān)理業(yè)務流程（表2：需求階段）

輸入承理的待監(jiān)理和構加主單待蛤1由

監(jiān)理規(guī)程

1調研申請表1

調研計劃1r

->調研申請

承建合同審核報告

流程描述

編制監(jiān)理規(guī)程和監(jiān)理細則；

:審核承建方提交本階段計劃和明細任務分解計劃，提出監(jiān)理建議，對工程進度進行

控制；

督促承建方建立完善的質量保證體系；

建立協(xié)調機制：督促建設小組的聯(lián)系、溝通，有利于本階段的工作效率和效果；

審核調研方式：協(xié)助業(yè)主審核調研計劃，進行需求調研準備工作，必要時參加需求

的調研工作；

審核調研記錄：審核承建方提交的用戶需求調研記錄（即原始需求），協(xié)助業(yè)主組織

進行調研記錄的確認工作；

組織需求分析報告評審：提交評審預案報告，說明需求分析報告評審的標準規(guī)范、

評審項及建議；協(xié)助業(yè)主組織需求分析報告評審，必要時以“專家評審會”的形式展

開；

協(xié)助組織需求分析報告的業(yè)主方、監(jiān)理方、承建方簽字確認；

審核承建方提交的測試方案；

定期向業(yè)主報告項目實施的進度和質量情況；

工程設計階段監(jiān)理

流程

監(jiān)理業(yè)務流程（耨：設計階段）

?穴工田土n切1蛤山

標準規(guī)氾

承建合同1

―>設計報審

士區(qū)由主/二1父?\

系統(tǒng)實施方案H1乂衣（匕《文）

1V

1階段性計劃設計符合性評審評審預案

1

質量管理監(jiān)理通知

整改<-

需求分析報告評審報告

流程描述

審核本階段計劃和明細任務分解計劃：審核承建方提交本階段計劃和明細任務分解

計劃，提出監(jiān)理建議，對工程進度進行控制；

審核承建方的質量保證措施的完備性及有效性；

監(jiān)督實施小組的聯(lián)系、溝通，有利于實現(xiàn)過程的工作效率和效果；

協(xié)助業(yè)主組織系統(tǒng)設計報告評審；

協(xié)助業(yè)主組織應用系統(tǒng)架構設計、數(shù)據(jù)庫設計的合理性審查；

定期向業(yè)主報告項目實施的進度和質量情況。

工程實現(xiàn)階段監(jiān)理

流程

流程描述

審核本階段計劃和明細任務分解計劃：審核承建方提交本階段計劃和明細任務分解

計劃，提出監(jiān)理建議，對工程進度進行控制；

審核承建方的質量保證措施的完備性及有效性；

監(jiān)督實施小組的聯(lián)系、溝通，有利于實現(xiàn)過程的工作效率和效果；

編碼過程的控制：依據(jù)承建方的模塊開發(fā)計劃，對系統(tǒng)編碼階段進行過程控制，審

核承建方提交的測試分析報告，必要時進行抽測，隨時掌握系統(tǒng)開發(fā)的進展情況；

自測管理：督促承建方及時提交單元測試報告、系統(tǒng)模塊測試計劃、系統(tǒng)模塊測試

用例、系統(tǒng)模塊測試報告和問題跟蹤情況報告；督促承建方對系統(tǒng)出現(xiàn)的問題及時進

行改正和優(yōu)化；

UI確認：在系統(tǒng)編碼結束前，協(xié)助業(yè)主方組織系統(tǒng)用戶界面(UI)的確認；

審核項目開發(fā)總結報告：依據(jù)合同、需求和設計文檔，審查承建方的項目開發(fā)總結

報告；

審核系統(tǒng)測試分析報告：審核承建方的系統(tǒng)測試分析報告，并提交系統(tǒng)集成測試審

核報告，如果系統(tǒng)集成測試存在問題，指出問題并督促承建方對進行修正；

評審并評估項目的階段性成果：組織評審并評估項目的階段性成果，發(fā)現(xiàn)并總結分

析系統(tǒng)試運行中存在的問題和缺陷；

定期向業(yè)主報告項目實施的進度和質量情況。

工程驗收階段監(jiān)理

流程描述

協(xié)調進行交工驗收：承建方確認應用系統(tǒng)滿足需求后，監(jiān)理方和業(yè)主方依據(jù)合同執(zhí)

行情況評估報告中所作的結論與合同中的規(guī)定準則和方式判斷產品是否已經(jīng)可以驗

收，對于不符合驗收條件的，督促承建方對問題進行整改；

審核安裝手冊和操作使用手冊：對承建方提交的安裝手冊和操作使用手冊進行審核;

系統(tǒng)培訓管理：審核承建方的培訓計劃和培訓內容，檢查和考核培訓效果；

評審系統(tǒng)試運行計劃和方案：組織評審承建方的應用系統(tǒng)試運行計劃和方案，并提

交系統(tǒng)試運行計劃和方案的審核報告，如果存在問題，指出問題并督促承建方對其進

行修正；

系統(tǒng)試運行管理：協(xié)助進行試運行前數(shù)據(jù)準備；審核并評估系統(tǒng)試運行的方法、步

驟、條件以及實施的措施，檢查為保證系統(tǒng)整體試運行所采取措施的有效性；依據(jù)應

用系統(tǒng)試運行計劃和方案對應用系統(tǒng)的試運行過程進行控制，及時發(fā)現(xiàn)存在的問題，

隨時掌握系統(tǒng)試運行的進展情況；并督促承建方對系統(tǒng)試運行中出現(xiàn)的問題及時進行

改進和優(yōu)化；

評審并評估項目的階段性成果：組織評審并評估項目的階段性成果，發(fā)現(xiàn)并總結分

析系統(tǒng)試運行中存在的問題和缺陷；協(xié)助業(yè)主進行試運行的總結、分析并評估系統(tǒng)試

運行的效果；協(xié)助業(yè)主制定下一步的流程持續(xù)改進措施；

協(xié)商制定驗收程序和驗收標準：根據(jù)國際、國家標準、規(guī)范要求，三方協(xié)商制定驗

收程序和驗收標準；

審核驗收申請：依據(jù)承建方提交的系統(tǒng)實施文檔報告，審核承建方提交的驗收申請;

組織合同執(zhí)行情況評估：依據(jù)業(yè)主與承建方簽訂的應用系統(tǒng)實施合同和本應用系統(tǒng)

的實施情況，組織進行評估合同的執(zhí)行情況，并提交合同執(zhí)行情況評估報告；

協(xié)助組織系統(tǒng)驗收測試：監(jiān)理方和業(yè)主方批準承建方提交的驗收申請后，協(xié)助業(yè)主

方組織驗收測試，必要時引入第三方測試；協(xié)調解決驗收過程中發(fā)現(xiàn)的問題，對問題

的處理方法以及結果納入驗收記錄中。具體驗收測試內容：

相關文檔審核：依據(jù)驗收標準對工程文檔進行審核；

,審核承建商提交的測試報告，提出監(jiān)理意見；必要時引入第三方測試或進行監(jiān)理抽

測；出具監(jiān)理驗收測試報告。

驗收報告三方簽字確認；

審核系統(tǒng)維護計劃：審核承建方提交的系統(tǒng)維護計劃，提出意見和看法，對于出現(xiàn)

的問題，督促承建方進行修正，協(xié)調進行系統(tǒng)試運行維護，審核承建方的維護記錄，

協(xié)調解決維護過程中出現(xiàn)的問題；協(xié)調相關承建方進行系統(tǒng)聯(lián)調；

協(xié)助組織系統(tǒng)竣工驗收會：協(xié)調進行竣工驗收工作，協(xié)助業(yè)主方組織進行系統(tǒng)竣工

驗收會，必要時可以聘請專家參加；

:監(jiān)督工程驗收后各項文檔的移交工作。

第四部分監(jiān)理控制要點

工程前期階段監(jiān)理

標準、規(guī)范體系：三方就工程建設中應該采用的總的標準和規(guī)范的內容、參考依據(jù)

達成一致，作為工程建設的依據(jù)。

明確工程范圍、總工期：三方就工程建設的總體進度計劃、量化目標以及考核方法

達成一致。

明確質量控制標準：三方就工程建設質量保證計劃達成一致。

制定工程總體實施規(guī)劃：三方就工程建設優(yōu)先級、實施方案和各子系統(tǒng)間接口標準

達成一致，作為工程建設的參考依據(jù)。

明確組織結構保障：確定工程建設領導小組的職責及人員構成，建議采用“一把手

負責制”，便于協(xié)調工程建設中的各方及相關業(yè)務部門的關系。

工程需求階段監(jiān)理

明確需求調研涉及各方的職責：確定調研方式、調研范圍、涉及各方的職責和權限

劃分并制訂需求管理規(guī)定，督促需求調研的積極進展。

需求調研的組織和協(xié)調：業(yè)主方、監(jiān)理方、承建方共同制定調研計劃，協(xié)調各方及

相關業(yè)務部門關系落實計劃的執(zhí)行。

明確系統(tǒng)建設范圍：在遵循承建合相關說明情況下，進一步細化系統(tǒng)建設范圍，并

作為系統(tǒng)驗收的依據(jù)之一。

需求評審和需求確認：組織需求調研結果的評審，落實需求分析報告的正確性、完

整性、可驗證性等要求，并落實需求分析報告的簽字確認，作為以后階段的依據(jù)。

測試計劃審核：三方就測試方案達成一致。

工程設計階段監(jiān)理

審核階段性成果：包括概要設計報告。

變更控制：妥善處理系統(tǒng)建設過程中變更事項，進行變更管理，并落實文檔的同步

更新。

工程實現(xiàn)階段監(jiān)理

審核階段性成果：包括概要設計報告。

變更控制：妥善處理系統(tǒng)建設過程中變更事項，進行變更管理，并落實文檔的同步

更新。

工程驗收階段監(jiān)理

系統(tǒng)實施：協(xié)調系統(tǒng)實施部署計劃的執(zhí)行，建議采用“試點”模式，逐步實現(xiàn)系統(tǒng)

試運行，同時，制定新老系統(tǒng)協(xié)調運行業(yè)務管理辦法，處理好歷史數(shù)據(jù)問題；

驗收標準：三方制定驗收標準，進行合同執(zhí)行情況的評估，并落實合同中驗收事項

的執(zhí)行。

第五部分：監(jiān)理工作手冊

軟件監(jiān)理管理要點

系統(tǒng)規(guī)劃

1)系統(tǒng)規(guī)劃是否從組織上確定了整體計劃的主要體制，是否得到了最高領導的

認可；

2)整體計劃是否依照主要規(guī)則判定，是否得到了最高領導的認可;

3)整體計劃中是否明確了信息化的效果、推進體制、費用等各項內容；

4)整體計劃中是否明確說明了信息系統(tǒng)的整體概貌；

5)整體計劃中是否明確說明了系統(tǒng)開發(fā)的優(yōu)先級；

6)整體計劃中是否明確說明了系統(tǒng)開發(fā)的組織及業(yè)務改變的方針；

7)整體計劃中是否明確說明了安全對策的方針；

8)整體計劃是否定期進行修正以及隨條件的變化而修正；

9)開發(fā)計劃是否得到最高領導的認可；

10)開發(fā)計劃是否考慮到了與整體計劃的整合；

11)開發(fā)計劃是不是在對內外信息技術調查基礎上決定的；

12)開發(fā)計劃是否明確說明了目的、對象業(yè)務、性能價格比等各項內容；

13)是否明確說明了改變信息系統(tǒng)生命周期的條件。

系統(tǒng)分析

1)開發(fā)計劃，需求定義是否得到承建方及用戶方認可；

2)用戶需求調查是否明確對象、范圍及方法；

3)是否由精通業(yè)務的用戶參與現(xiàn)狀分析；

4)是否對隨著信息系統(tǒng)引入而產生的風險進行分析；

5)是否對有關信息系統(tǒng)的法律、法規(guī)及制度等進行調查；

6)對引入信息系統(tǒng)后受影響的業(yè)務、管理體制和各種規(guī)程等是否進行研討與修

正；

7)用戶部門及信息部門的作用分配是否明確；

8)開發(fā)計劃及用戶需求是否考慮了軟件、硬件和網(wǎng)絡等需求；

9)是否有達到信息系統(tǒng)目的的替代方案；

10)是否根據(jù)開發(fā)的規(guī)程、時間及系統(tǒng)的特性來決定承建方法；

11)開發(fā)及運行費用的計算模型是否適當，結果是否合理、準確；

12)是否對信息系統(tǒng)的效果進行了定量及定性的評價；

13)是否確保開發(fā)所必須的人員、預算、設備及時間等。

系統(tǒng)設計

1)系統(tǒng)設計報告是否得到承建方與用戶方負責人的認可；

2)輸入輸出報表及界面設計是否便于用戶使用；

3)數(shù)據(jù)庫是否按業(yè)務內容進行設計；

4)數(shù)據(jù)的整體性是否確保；

5)網(wǎng)絡是否按業(yè)務內容進行設計；

6)信息系統(tǒng)的性能是否滿足用戶要求；

7)系統(tǒng)的組成是否考慮系統(tǒng)應用的高峰進行設計；

8)是否設計運行性能管理的技術實現(xiàn)方法；

9)是否考慮信息系統(tǒng)的故障對策；

10)是否設計對不正當行為防止及機密保護等功能；

11)測試計劃中是否明確目的、范圍、方法及進度安排等；

12)信息系統(tǒng)應用的培訓方針、進度等是否明確。

編碼

1)程序說明書，是否得到開發(fā)負責人認可；

2)是否按照系統(tǒng)設計報告進行程序設計；

3)編碼時發(fā)現(xiàn)與系統(tǒng)設計有矛盾時，是否對系統(tǒng)設計進行了再討論;

4)檢查編碼是否按程序說明書進行；

5)是否對程序測試結果進行登記與保管；

6)重要的程序是否由程序作者以外的人員進行了測試。

系統(tǒng)測試

1)測試數(shù)據(jù)的選取及系統(tǒng)測試是否按測試計劃進行；

2)系統(tǒng)測試是否站在公正、客觀立場上進行；

3)系統(tǒng)測試是否由用戶參加，是否按照用戶手冊進行；

4)系統(tǒng)測試結果是否得到開發(fā)、運行、維護及用戶的負責人認可；

5)是否對系統(tǒng)測試的結果進行記錄與保管的認可。

試運行

1)試運行是否按計劃進行；

2)是否能根據(jù)試運行計劃籌備到必要的人員、預算和設備等資源；

3)試運行結果的驗收方法是否明確；

4)是否制訂試運行后的運行計劃，并根據(jù)試運行結果進行修正。

運行管理

1)總體操作管理

A.信息系統(tǒng)用戶是否制定與遵守運行管理的規(guī)則;

B.操作順序是否標準化，事故及故障對策是否明確；

C.作業(yè)進度的決定是否考慮業(yè)務處理的優(yōu)先級；

D.操作是否按作業(yè)進程表及指導書進行；

E.例外處理的操作是否按運行管理規(guī)則進行；

F.操作員的交替是否按運行管理規(guī)則進行；

G.是否對作業(yè)進程表與操作事實記錄的差異進行分析；

H.是否能把握住信息系統(tǒng)運行狀況達到性能管理及資源的有效利用；

I.操作實施記錄是否按照運行管理規(guī)則保管一定期限；

J.是否記錄事故及故障內容，并向信息系統(tǒng)運行負責人報告；

K.是否找到事故及故障的原因，并采取措施防止再發(fā)生；

L.識別代碼及口令的管理是否考慮防止不正當行為及機密保護對策；

M.是否對用戶進行了有關信息系統(tǒng)的安全教育及培訓。

2)軟件管理

A.信息系統(tǒng)用戶是否制定及遵守軟件管理的規(guī)則；

B.對軟件的存取及控制、監(jiān)視是否有防止不正當行為及機密保護對策;

C.信息系統(tǒng)用戶是否記錄軟件利用狀況，并定期進行分析；

D.軟件備份的范圍及方法是否按業(yè)務內容及處理狀態(tài)來決定；

E.軟件的保管及廢除有否防止不正當行為對策及機密保護對策；

F.軟件的拷貝有否防止不正當行為及機密保護對策；

G.對軟件有否故障對策；

H.對軟件版本如何管理。

3)硬件管理

A.信息系統(tǒng)用戶是否制定并遵守硬件管理的規(guī)則；

B.對硬件是否設置了能夠回避風險的環(huán)境；

C.對硬件是否設置了能夠應對風險的環(huán)境；

D.是否定期對硬件進行維護；

E.是否有硬件的故障對策；

F.是否對硬件的利用狀況進行記錄，并定期進行分析。

4)建筑物及相關設備管理

A.對建筑物及相關設備是否設置了能夠回避風險的環(huán)境；

B.建筑物及房間的進出管理是否有防止不正當行為的對策及機密保護的對策；

C.對相關設備是否定期進行維護；

D.相關設備是否有故障對策。

5)組成管理

A.所有要管理的軟件、硬件、網(wǎng)絡的對象范圍是否明確；

B.軟件、硬件及網(wǎng)絡的組成，供應商的支持維護條件是否明確；

C.引入或變更軟件、硬件和網(wǎng)絡后受到影響的范圍是否明確；

D.引入或變更軟件、硬件和網(wǎng)絡是否按計劃實施。

文檔編制

1)是否遵守文檔編制規(guī)范；

2)是否制訂文檔計劃；

3)文檔計劃的執(zhí)行情況；

4)文檔的種類、目的、制作方法等是否明確；

5)文檔是否得到信息系統(tǒng)部門及用戶部門負責人的認可。

文檔管理

1)是否制定和遵守文檔管理規(guī)則；

2)文檔更新是否得到信息系統(tǒng)部門及用戶負責人的認可；

3)在系統(tǒng)需求更新時，文檔內容是否進行更新，并留下更新記錄；

4)文檔的拷貝及廢除是否有對不正當行為的防范及機密保護的對策。

進度計劃

1)是否按標準格式編寫計劃書；

2)是否有時間、任務和結果形式；

3)進度安排是否合理。

進度控制

1)承建方是否制訂進度管理的方法、體制，是否得到計劃、開發(fā)、運行及維護

等各業(yè)務負責人的認可；

2)計劃、開發(fā)、運行及維護各業(yè)務負責人是否把握進度狀況，是否按計劃執(zhí)行;

3)是否有進度延遲的對策；

4)各業(yè)務結束時，是否按計劃等實施狀況進度分析與評價；

5)評價的結果是否反映到下階段工程的進度計劃中；

6)評價的結果是否反映對進度管理的方法與體制等的改進。

進度評價

1)檢查在各業(yè)務結束時，是否按計劃對實施狀況進行分析與評價，評價的結果

是否客觀、真實，是否分析了影響進度的主要原因，是否提出了相應的應對措施，

應對措施是否合理，能否實現(xiàn)等；

2)檢查評價的結果是否反映到下階段工程的計劃中，在下階段的工程實施過程

中是否按照相應的進度調整計劃進行實施；

3)對進度的評價是否反映對進度管理的方法與體制等的改進。

軟件監(jiān)理技術要點

系統(tǒng)規(guī)劃

任務：確保新開發(fā)的信息系統(tǒng)是滿足企業(yè)戰(zhàn)略發(fā)展需要的，從技術、經(jīng)濟和操作

的角度來說是可行的、恰當?shù)?，但不是不顧企業(yè)的實際需要而一味地追求新技術或高

性能的硬件配置。

系統(tǒng)分析(需求分析)

任務：保證需求

1)一致性：所有需求必須是一致的；

2)完整性：需求必須是完整的，規(guī)格說明書應該包括用戶需要的每一個功能或

性能；

3)現(xiàn)實性：制定的需求應該是用現(xiàn)有的硬件技術和軟件技術可以實現(xiàn)的；

4)有效性：必須證明需求是正確有效的，確實能解決用戶面臨的問題。

系統(tǒng)設計

總體設計要求：

1)詳細需求的描述

為了設計一個信息系統(tǒng)，設計者必須明白系統(tǒng)能夠提供什么信息。

2)數(shù)據(jù)/信息流的設計

A.數(shù)據(jù)流和信息流的流動方向以及傳輸點；

B.數(shù)據(jù)流和信息流的流動頻率以及流動時間；

C.將被格式化的數(shù)據(jù)流和信息流。

詳細設計要求：

1)數(shù)據(jù)庫設計

A.結構

令概念建模：模型反映了實體或對象的關系、實體的屬性、實體之間的關

系以及對這些實體、實體屬性和實體關系的靜態(tài)和動態(tài)限制；

令數(shù)據(jù)建模：將概念模型轉換成數(shù)據(jù)模型；

令存儲結構設計：決定怎樣將這些數(shù)據(jù)結構線性化和進行分割，以存儲在

某些設備上；

令物理結構設計：決定怎樣通過具體的存儲介質和地點來分配存儲結構。

B.數(shù)據(jù)

令自由存取控制：根據(jù)用戶的類別分配適當?shù)臋嘞蓿?/p>

令強制性存取控制：數(shù)據(jù)資源被分為不同的級別，用戶也被分配了不同的

存取級別，根據(jù)安全策略的定義決定用戶對資源的存取權限。

令實體-關系模型中的完整性約束

唯一性：每個實體的實例必須是唯一的；

最大基數(shù)：在數(shù)據(jù)庫中存在的一個實體所能產生的實例的最大數(shù)目；

最小基數(shù)：在數(shù)據(jù)庫中存在的一個實體所能產生的實例的最小數(shù)目；

實體關鍵字：唯一標識實體的實例的屬性；

關鍵字類型：定義實體關鍵字的屬性的類型；

關鍵字的值：定義組成關鍵字的屬性所允許的一些值。

令屬性完整性約束

屬性類型：一個屬性所允許的數(shù)據(jù)類型；

屬性的值：對于一個屬性所允許的一些值；

轉換法則：定義一個屬性的前一個值到后一個值的轉換關系。

令關系完整性約束

鍵的完整性：定義一個關系的候選鍵應唯一標識關系的一個元組；

實體完整性：包拯主鍵不能為空；

參照完整性：保證元組之間協(xié)同。當一個元組引用另一個元組的一個

屬性時（利用外鍵），應保證這個屬性在另一個元組中是存在的。

令對象完整性約束

唯一標識碼：每個對象都必須是唯一的，數(shù)據(jù)庫系統(tǒng)能產生一個對象

標識碼，在對象的生命周期中唯一標識這個實體；

唯一鍵：唯一鍵與唯一標識碼是不同的，唯一標識碼是系統(tǒng)產生的，

唯一鍵是用戶產生的；

屬性類型：對象的屬性允許的類型；

屬性的值：對象的屬性所允許的一些值；

類型和繼承：保證一個對象的子對象繼承了它的所有屬性。

令對象關系完整性約束

參照完整性：一個對象要引用另一個對象，被應用的對象必須存在并

且是正確的類型；

合成完整性：規(guī)定的合成關系中，對應對象的插入和刪除的行為；

基數(shù)完整性：在一個關系中，特殊類型對象的最大和最少數(shù)目。

2)用戶界面設計

A.屏幕的組織

B.標題設計

C.數(shù)據(jù)輸入框設計

D.顏色設計

E.響應時間

F.提示和幫助的設計

3)模塊詳細設計

A.模塊要求獨立性強；

B.模塊規(guī)模應適中；

C.深度、寬度、輸入和輸出都應適當；

D.模塊的作用域應該在控制域之內；

E.力爭降低模塊接口的復雜度；

F.設計單入口單出口的模塊；

G.模塊功能可以預測。

4)硬件或軟件平臺的設計和獲得

要考慮硬件及軟件平臺的設計上相互之間的兼容程度，理想狀況下，不同的硬件和

系統(tǒng)軟件可以互相交流。

編碼要求：

主要是從編程語言的選擇、編程風格、編碼方法，以及相關文檔的編寫這幾個方

面進行考慮。

1)程序內部的文檔

A.選取含義鮮明的名字，使它能正確地提示程序對象所代表的實體；

B.正確的注解非常有助于對程序的理解；

C.程序清單對程序的可讀性有很大的影響。

2)數(shù)據(jù)說明

A.數(shù)據(jù)說明的次序應該標準化；

B.當多個變量名字在一個語句中說明時，應該按字母順序排列這些變量；

C.如果設計時使用了一個復雜的數(shù)據(jù)結構，則應該用注解說明用這種程序設計

語言實現(xiàn)這個數(shù)據(jù)結構的方法和特點。

3)語句構造

A.不要為了節(jié)省空間而把多個語句寫在同一行；

B.盡量避免復雜的條件測試；

C.盡量減少對“非”條件的測試；

D.避免大量使用循環(huán)嵌套和條件嵌套；

E.利用括號使邏輯表達式和算術表達式清晰直觀。

4)輸入輸出

A.對所有輸入數(shù)據(jù)進行校驗；

B.檢查輸入項重要組合的合法性；

C.保持輸入格式簡單；

D.使用數(shù)據(jù)結束標記，不要要求用戶指定數(shù)據(jù)的數(shù)目；

E.明確提交交互式輸入的請求，詳細說明可用的選擇和邊界數(shù)值；

F.設計良好的輸出表格；

G.給所有輸出數(shù)據(jù)加標志。

5)效率

效率主要指時間和容量兩方面。首先，應該在需求分析階段確定效率方面的要求;

其次，效率是靠好設計來提高的；第三，程序的效率和程序的簡單程度是一致的，

包括程序運行的時間，存儲器效率和輸入輸出效率。

6)編碼

程序的每個模塊都只能有一個入口和一個出口，模塊的長度建議限制在50—100

個語句范圍，應采用自頂向下的流控制。

7)文檔

高質量的文檔是減少編碼錯誤和提高以后可維護性的有利途徑。

A.提供程序主要組成部分和相互關系的圖表；

B.在程序中利用各種注釋可闡明程序的特點、作用以及不同的組成部分和邏輯

關系；

C.對于不同類型的變量、常量、程序段和模塊等，使用有意義的名字可增強程

序的可閱讀性；

D.有格式的書寫程序可增強閱讀性。

測試要求：

1)單元測試

2)集成測試

3)總體測試

運行要求：

1)系統(tǒng)輸入

數(shù)據(jù)錄入是整個信息系統(tǒng)運行的非常關鍵的一個環(huán)節(jié)，是以后報表生成和決策支

持的基礎

數(shù)據(jù)有效性驗證。

A.字段檢驗

數(shù)據(jù)缺省或空值檢驗

字母或數(shù)字檢驗

范圍檢驗

校驗碼檢驗

主文件參照

大小檢驗

格式檢驗

B.記錄檢驗

合理性

大小

順序檢驗

C.批檢驗

控制總量

批類型

順序檢驗

D.文件檢驗

內部標簽

版本號

有效期

2)錯誤報告

A.清晰和簡潔

B.語言嚴謹中立

信息系統(tǒng)生命周期支持業(yè)務

文檔

1)意義

A.文檔可以作為開發(fā)人員在一定階段內的工作成果和結束的標志，各階段的人

員通過文檔進行交接工作；

B.文檔可以作為管理依據(jù)；

C.文檔可用做未來項目的一種資源；

D.文檔可以作為運行、維護和培訓的參考依據(jù)；

E.文檔對保證軟件質量起到重要作用。

2)主要內容

A.可行性研究：可行性研究報告、項目開發(fā)計劃、系統(tǒng)需求說明書、數(shù)據(jù)要求

說明、開發(fā)進度月報；

B.需求分析：項目開發(fā)計劃、系統(tǒng)需求說蜜柑內、數(shù)據(jù)要求說明、測試計劃、

用戶手冊、開發(fā)進度月報；

C.設計：概要設計說明、詳細設計說明、測試計劃、用戶手冊、操作手冊、開

發(fā)進度月報；

D.代碼編寫：用戶手冊、操作手冊、開發(fā)進度月報；

E.測試：測試分析報告、開發(fā)進度月報、項目開發(fā)總結；

F.運行與維護：維護修改日志。

3)質量要求

A.針對性；

B.精確性；

C.清晰性；

D.完整性；

E.靈活性；

F.可追溯性。

文檔的版本管理是文檔管理的一個必要方面。需求文檔的每一版本必須被統(tǒng)一確

定，并保證開發(fā)成員得到需要的當前版本。此外，在需求進行變更時，需要清楚地

將變更以文檔形式記錄下來，并通知相關人員。

進度

進度計劃要求

1)GATT圖；

2)網(wǎng)絡圖。

進度控制要求

1)用各種控制手段保證項目及各個任務活動按計劃及時開始，在項目過程中記

錄各任務活動的開始和結束時間及完成程度；

2)在各個階段結束時，按各任務的完成情況對比計劃，確定整個項目的完成程

度，并結合時間、開發(fā)內容、效率、消耗等評價項目進度狀況，分析其中的問題；

3)對下期工作做出安排，對一些已開始，但尚未結束的項目單元的剩余時間做

估算，分析調整進度的措施；

4)根據(jù)已完成的狀況做新的安排和計劃，并預測新的進度狀況；

5)分析新的進度計劃是否符合合理性需求，如不符合，如何采取調整措施等。

進度調整要求

1)調整過程

A.為了調整進度，應深入現(xiàn)場，進行調查，分析產生偏差的原因；

B.在查明產生原因之后，要分析偏差對后續(xù)工作和總進度的影響，確定是否應

當調整；

C.在分析了對后續(xù)工作和總進度的影響以后，需要采取一定的調整措施時，應

當首先確定進度可調整的范圍，主要關鍵節(jié)點、后續(xù)工作的限制條件以及總進度

允許變化的范圍；

D.采取進度調整措施，以后續(xù)工作和總進度的限制條件為依據(jù)，對原進度計劃

調整，以保證進度目標的實現(xiàn)；

E.在項目繼續(xù)實施中，執(zhí)行調整后的進度計劃。

2)調整方法

A.調整任務之間的順延關系；

B.縮短某些任務的持續(xù)時間。

人員管理

職責權限要求：要遵循“職責分離”的原則。目的在于保證不同職責有不同的人

承擔，保證人員之間的工作可互相檢查和監(jiān)督。

業(yè)務分配要求：

1)考察業(yè)務與能力，考慮人員的能力與崗位的要求是否匹配，業(yè)務分配及業(yè)務

量是否考慮到人員的知識與能力；

2)考察人員的接替過程對不可預測風險的防范情況。

災難對策

1)災難應急計劃；

2)備份計劃；

3)替代處理。

評價計劃

安全性

1)資產安全性

2)數(shù)據(jù)安全性

包括容錯能力；已經(jīng)存在或潛在的數(shù)據(jù)錯誤，以及這些錯誤的規(guī)模及數(shù)量。

3)總體安全性

測試單個控制的強弱，并不斷地對信息系統(tǒng)安全性作出全局性的判斷。

可靠性

概念：

1)指產品在規(guī)定的條件、規(guī)定的時間內完成規(guī)定功能的能力或無故障運行的概

率，也就是產品維持其功能和性能水平的能力；

2)信息系統(tǒng)可靠性是指系統(tǒng)在規(guī)定時間內無故障運行的概率。

軟件可靠性

1)軟件可靠度表示在規(guī)定的運行環(huán)境和規(guī)定的時間內軟件無故障運行的概率；

2)軟件故障強度，軟件故障率的物理解釋是單位時間內軟件發(fā)生故障的概率；

3)平均故障間隔時間是相鄰兩次故障間工作時間的數(shù)學期望；

4)平均故障修復時間表示軟件從發(fā)現(xiàn)故障到軟件恢復規(guī)定功能所需的時間，即

故障診斷、修復準備及修復實施時間之和。

有效性

評價過程

1)明確評價目標；

2)評價費用的預算；

3)明確性能指標；

4)構建負荷模型；

5)構建系統(tǒng)模型；

6)進行實驗；

7)結果分析；

8)給出建議。

性能指標

系統(tǒng)有效性的量度標準，反映了系統(tǒng)實現(xiàn)某些性能標準的數(shù)量特征

1)時間性指標：表述作為輸入系統(tǒng)到系統(tǒng)輸出用戶所需結果的時間周期；

2)吞吐率指標：系統(tǒng)生產力的度量標準，描述了在給定時間內系統(tǒng)處理的工作

量；

3)利用率指標：以系統(tǒng)資源處于忙狀態(tài)的時間為度量標準；

4)可靠性指標：系統(tǒng)處理用戶工作的可用性或處理過程失敗或錯誤的概率。

負荷模型

系統(tǒng)負荷是在給定時間段內作業(yè)提出所需系統(tǒng)資源和服務請求的總量。

系統(tǒng)模型

為了確定一個系統(tǒng)是否可以提高性能，需要對系統(tǒng)進行建模。建模過程包括識別

系統(tǒng)單元、單元界面、系統(tǒng)運行方式、輸入輸出之間的功能關系等。

綜合評價

評價過程

1)確定信息系統(tǒng)的主要目標；

2)選擇評價標準；

3)確定評價數(shù)據(jù)來源；

4)事先系統(tǒng)的價值；

5)事后系統(tǒng)的價值；

6)估計系統(tǒng)的影響。

評價內容

1)系統(tǒng)質量

A.響應時間；

B.周轉時間；

C.系統(tǒng)可靠性；

D.系統(tǒng)界面的友好程度；

E.功能性；

F.易用性；

G.文檔、幫助資料的質量；

H.與其他系統(tǒng)的集成度。

2)信息質量

A.真實性；

B.精確性；

C.完整性；

D.非冗余性；

E.時間性；

F.關聯(lián)性；

G.綜合性；

H.精密度；

I.簡明；

J.信息性。

3)有用性感受

A.是否提高了用戶的工作效率;

B.是否改善了用戶的工作表現(xiàn);

C.是否提高了用戶的生產力；

D.是否提高了工作效果；

E.是否提高了用戶對工作任務的理解；

F.是否對他們的工作有幫助；

4)易用性感受

A.是否比較容易學習如何操作；

B.用戶是否能方便地利用信息系統(tǒng)完成他們的工作；

C.用戶與信息系統(tǒng)之間的交互是否清晰、易懂、順暢、靈活;

D.用戶是否能利用信息系統(tǒng)快速地適應工作要求；

E.用戶是否認為信息系統(tǒng)的操作很容易；

5)用戶對計算機使用能力的判斷；

6)信息系統(tǒng)的使用情況。

7)個人影響

8)信息系統(tǒng)滿意度

A.與信息系統(tǒng)開發(fā)/維護人員的人際關系；

B.對系統(tǒng)變更要求的處理方式；

C.信息的時間性；

D.針對用戶的信息系統(tǒng)技能培訓；

E.輸出的相關性；

F.輸出的量；

G.文檔質量；

H.信息系統(tǒng)依賴性。

9)組織影響

第六部分：文檔模板、流程

(部分)

為了更加規(guī)范工程管理，對工程中的文檔處理流程進行進一步的明確和細化，承

建方、監(jiān)理方和業(yè)主方在工程實施過程中嚴格按照本規(guī)范進行文檔的處理和存檔。

監(jiān)理方業(yè)務聯(lián)系單

監(jiān)理方業(yè)務聯(lián)系單是監(jiān)理方與業(yè)主方進行業(yè)務交流的方式，主要包括監(jiān)理人員確定、

監(jiān)理文檔格式、工程進度質量狀況及建議、抽測報告、檢驗記錄和測試報告等。業(yè)務

聯(lián)系單根據(jù)實施情況需要，由總監(jiān)或總監(jiān)代表審核后提交。

編號規(guī)則：［年度］LXD（監(jiān)）xxx號。

監(jiān)理方周報/月報/階段總結報告

監(jiān)理方周報在審核承建方周報的基礎上，完成監(jiān)理方周報，主要描述監(jiān)理的參加人員

和工作情況。

監(jiān)理方月報/階段總結報告是監(jiān)理方對工程的階段總結報告，在每月5日前提交上月

月報，階段總結報告不定期提交。

編號規(guī)則：［年度］文件標識（監(jiān)）xxx號。如［年度］GCZB（監(jiān)）xxx號、［年度］GCYB（監(jiān)）xxx

號、［年度］JDBG（監(jiān)）xxx號。

監(jiān)理方監(jiān)理通知

監(jiān)理通知是監(jiān)理方針對工程實施過程中存在問題與承建方交流的方式，根據(jù)實施情況

需要，由總監(jiān)或總監(jiān)代表審核后提交。

編號規(guī)則：［年度］JLTZ（監(jiān)）xxx號。

會議紀要

由監(jiān)理方對工程實施協(xié)調會的精神進行歸納整理形成會議紀要，會議紀要需要承建方

項目負責人、總監(jiān)或總監(jiān)代表和業(yè)主方項目負責人簽字。

文檔格式

軟件咨詢部所涉及的工程文檔包括下述類別，主要文檔的模版參見附錄。

軟件咨詢部工程文檔類別（6艮存期限10年）

1監(jiān)理日志SDZZ-12-QR001項目管理人員編寫，必須當日完成。

2監(jiān)理規(guī)程SDZZ-12-QR002項目組編寫，不要求固定格式。

3監(jiān)理實施細則SDZZ-12-QR003項目組編寫，不要求固定格式。

1監(jiān)理人員名單SDZZ-12-QR004項目負責人與部門協(xié)商提供。

5工程開工/停工/復工通知SDZZ-12-QR005項目負責人編寫。

6監(jiān)理周度/月度報告SDZZ-12-QR006項目管理人員編寫。

7監(jiān)理會議紀要SDZZ-12-QR007項目管理人員編寫，需及時編寫。

8工程監(jiān)理通知SDZZ-12-QR010項目管理人員編寫，需及時編寫。

9付款申請SDZZ-12-QR014部門領導審批。

10XXXX審核報告SDZZ-12-QR015項目負責人和管理人員編寫。

11工程延期報告SDZZ-12-QR016項目負責人編寫。

12費用索賠及報告SDZZ-12-QR017項目負責人編寫，部門協(xié)助。

13合同爭議及違約處理意見SDZZ-12-QR018項目負責人編寫，部門協(xié)助。

14合同變更SDZZ-12-QR019項目負責人編寫，部門協(xié)助。

15監(jiān)理簽收單SDZZ-12-QR021項目管理人員負責。

16工程文檔卷內目錄SDZZ-12-QR026項目管理人員負責。

17監(jiān)理業(yè)務聯(lián)系單SDZZ-12-項目負責人編寫。

18監(jiān)理（階段）總結報告SDZZ-12-項目負責人編寫，不要求固定格式。

19監(jiān)理（階段）測試計劃SDZZ-12-項目負責人編寫，不要求固定格式。

20監(jiān)理（階段）測試用例SDZZ-12-項目負責人編寫，不要求固定格式。

21監(jiān)理測試日志SDZZ-12-項目管理人員負責，不要求固定格

式。

22監(jiān)理（階段）測試問題報告SDZZ-12-項目負責人編寫，不要求固定格式。

23監(jiān)理（階段）測試分析報告SDZZ-12-項目負責人編寫，不要求固定格式。

24監(jiān)理專項報告SDZZ-12-QR020項目負責人編寫，不要求固定格式。

監(jiān)理日志

SDZZ-12-QR001

項目的日期****年**月**曰

業(yè)主方

監(jiān)理方

承建方

簡

述

監(jiān)理工程師：

監(jiān)理人員名單

SDZZ-12-QR004

項目名稱：

總監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

監(jiān)理工程師：聯(lián)系電話

業(yè)主方簽收（蓋章）山東省計算中心

年月日年月日

工程開工（停工、復工）通知

SDZZ-12-QR005

加的日期****年**月**曰

業(yè)主方

監(jiān)理方

承建方

通知內容：

監(jiān)理方代表：業(yè)主方代表：

監(jiān)理周（月）度報告

SDZZ-12-QR006

項目的日期****年**月**曰

業(yè)主方

監(jiān)理方

承建方

1

工

程

進

度

、

質

量

狀

況

及

建

議

監(jiān)理工程師：業(yè)主方代表：

監(jiān)理會議紀要

SDZZ-12-QR007

加的頤中公司青島卷煙廠“十五”CIMS工程日期2004年01月11日

業(yè)主方頤中公司青島卷煙廠

監(jiān)理方山東省計算中心

承建方

地點：時間：**:**（時：分）

參加人員：

主持：

會議議題：

監(jiān)理方代表：業(yè)主方代表：承建方代表：

監(jiān)理通知

SDZZ-12-QR010

項目僦日期****年**月**曰

業(yè)主方

監(jiān)理方

承建方

致承建方：

事由：

通知內容：

監(jiān)理工程師：承建方：

抄送業(yè)主方：

付款申請

SDZZ-12-QR014

項目的日期****年**月**日

業(yè)主方

監(jiān)理方

承建方

XXXXXXXXX領導：

依據(jù)XXXXX與XXXXXX簽署的合同要求和XXX設備的運

行、檢驗情況，經(jīng)我方監(jiān)理人員與貴方項目負責人研