软件监理规范

软件监理规范

（征求意见稿）

山东正中

目录

总则........................................................................2

第一部分术语...................................................................4

第二部分组织结构和人员资质....................................................8

第三部分监理工作流程.........................................................11

第四部分监理控制要点.........................................................21

第五部分：监理工作手册.........................................................22

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

第七部分：监理依据.............................................................56

第八部分：问题与解答..........................................错误！未定义书签。

总则

为了提高建设工程监理水平，规范建设工程监理行为，编制本规范。

本规范适用于新建、扩建、改建信息化工程应用系统部分（软件）的各个工作阶

段的监理工作。

实施信息化工程监理前，监理单位必须与建设单位签订书面信息化工程委托监理

合同，合同中应包括监理单位对工程质量、资金、进度进行全面控制和管理的条款。

建设单位与承建单位之间与信息化工程合同有关的联系活动应通过监理单位进行。

工程监理应实行总监理工程师负责制。

监理单位应公正、独立、自主地开展监理工作，维护建设单位和承建单位的合法

权益。

软件工程监理除应符合本规范外，还应符合国家现行的有关强制性标准、规范的

规定。

第一部分术语

1.项目监理机构：监理单位派驻工程项目负责履行委托监理合同的组织机构。

2.监理工程师：取得国家监理工程师执业资格证书并经注册的监理人员。

3.总监理工程师：由监理单位法定代表人书面授权，全面负责委托监理合同的履行、

主持项目监理机构工作的监理工程师。

4.总监理工程师代表：经监理单位法定代表人同意，由总监理工程师书面授权，代

表总监理工程师行使其部分职责和权力的项目监理机构中的监理工程师。

5.专业监理工程师：根据项目监理岗位职责分工和总监理工程师的指令，负责实施

某一专业或某一方面的监理工作，具有相应监理文件签发权的监理工程师。

6.监理员：经过监理业务培训，具有同类工程相关专业知识，从事具体监理工作的

监理人员。

7.监理规划：在总监理工程师的主持下编制、经监理单位技术负责人批准，用来指

导项目监理机构全面开展监理工作的指导性文件。

8.监理实施细则：根据监理规划，由专业监理工程师编写，并经总监理工程师批准,

针对工程项目中某一专业或某一方面监理工作的操作性文件。

9.工程例会：由项目监理机构主持的，在工程实施过程中针对工程质量、造价、进

度、合同管理等事宜定期召开的、由有关单位参加的会议。

10.工程变更：在工程项目实施过程中，按照合同约定的程序对部分或全部工程在需

求、功能、技术指标、工程数量及施工方法等方面做出的改变。

11.工程计量：根据设计文件及承建合同中关于工程量计算的规定，项目监理机构对

承建单位申报的已完成工程的工程量进行的核验。

12.见证：由监理人员现场监督某工序全过程完成情况的活动。

13.旁站：在关键部位或关键工序施工过程中，由监理人员在现场进行的监督活动。

14.巡视：监理人员对正在施工的部位或工序在现场进行的定期或不定期的监督活

动。

15.平行检验：项目监理机构利用一定的检查或检测手段，在承建单位自检的基础上,

按照一定的比例独立进行检查或检测的活动。

16.费用索赔：根据承建合同的约定，合同一方因另一方原因造成本方经济损失，通

过监理工程师向对方索取费用的活动。

17.临时延期批准：当发生非承建单位原因造成的持续性影响工期的事件，总监理工

程师所作出暂时延长合同工期的批准。

18.延期批准：当发生非承建单位原因造成的持续性影响工期事件，总监理工程师所

作出的最终延长合同工期的批准。

19.验收准则：软件产品要符合某一测试阶段必须满足的准则，或软件产品满足交货

要求的准则。

20.验收测试：确定一系统是否符合其验收准则，使客户能确定是否接收此系统的正

式测试。

21.需方：从供方获得或得到一个系统、产品或服务的一个机构。注：需方可以是

买主、客户、拥有者、用户、采购人。

22.供方：按照所签的合同向需方提供系统、产品或服务的一个机构（是合同当事人、

生产者、卖方、批发商的同义词）。注：需方可以指定它的机构中的某一部门做

为供方。

23.应用软件：解决属于专用领域的，非计算机本身问题的软件。

24.变更管理：提议作一项更动并对其进行估计、同意或拒绝、调度和跟踪的过程。

25.代码审计：由某人、某小组、或借助某种工具对源代码进行的独立的审查，以验

证其是否符合软件设计文件和程序设计标准。还可能对正确性和有效性进行估

计。

26.配置：计算机系统或网络按照其功能部件的特点、数量和主要特性而确定的排列。

具体地讲，配置一词可以指硬件配置或软件配置；为确定系统或系统组成部分

的特定版本而提出的需求、设计和实现；在技术文档中制定的并在产品中体现的

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

27.配置管理：标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项

的投放和吏动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确

性。

对下列工作进行技术和行政指导与监督的一套规范：

•对一配置项的功能和物理特性进行标识和文件编制工作；

•控制这些特性的更动情况；

•记录并报告对这些更动进行的处理和实现的状态。

28.合同：通过法律约束当事双方的一个协议，或是在一个机构内部为了提供服务的

一个内部协议。

29.交付：软件研制周期中的一个阶段。在此阶段上将产品提交给计划中的用户供其

使用。软件研制周期中的一个阶段。在此阶段上产品由其预定的用户接受。

30.评审：对现有的或提出的产品所做的正式评估和审查，其目的是找出可能会影响

产品，过程或服务工作的适用性和环境方面的设计缺陷并采取补救措施，以及（或

者）找出在性能、安全性和经济方面的可能的改进。

31.文档：为了对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任

何书面或图示的信息。

32.质量：产品或服务的全部性质和特征，能表明产品满足给定的要求。

33.招标：需方使用的一份文件，用来向潜在的投标人表示它要获得某特定系统、产

品或服务的意图。

34.需求：用户为解决某一问题或达到某个目标所需要的条件或能力。系统或系统部

件为满足或具有的条件或能力以满足合同、标准、规格说明或其它正式的强制性

文件。所有需求的集合形成了以后开发系统或系统部件的基础。

35.规模估计：对一个系统或系统部件所需要的源程序的行数或计算机存储的总量的

估计。

36.软件开发周期：从决定开发一个软件产品开始到产品交付为止的时间间隔。这个

周期通常包括需求阶段、设计阶段、实现阶段、测试阶段，有时还包括安装和

验收阶段。从决定开发软件产品开始到开发者不再改进产品时为止的时间周期。

37.软件开发过程：把用户要求转化为软件需求，把软件需求转化为设计，用代码来

实现设计，对代码进行测试，完成文档编制，并确认软件可以投入运行性使用的

过程。

38.软件工程：软件开发、运行、维护和引退的系统方法。

39.系统：一个完整的整体。它由种类不同的、相互作用的、专门的结构和子功能部

件所组成。

40.测试：由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满

足规定的需求；或识别出期望的结果和实际结果之间有无差别。

41.测试用例：测试数据及与之相关的测试规程的一个特定的集合。它是为了特定目

的（如考察特定程序路径或验证是否符合特定的需求）而产生出来的。

42.测试范围：一个范围，在此范围内测试程序测试系统需求能否满足。

43.测试计划：一个文件，它叙述了对于预定的测试活动将要采取的途径。典型的计

划中包括：标识要测试的项目、要完成的测试、测试进度表、人事安排要求、报

告要求、评价准则，以及任何临界的要求的临时计划。

44.测试报告：描述对系统或系统部件进行的测试行为及结果的文件。

第二部分组织结构和人员资质

监理单位履行施工阶段的委托监理合同时，必须在施工现场建立项目监理机构。项

目监理机构在完成委托监理合同约定的监理工作后可撤离施工现场。

项目监理机构的组织形式和规模，应根据委托监理合同规定的服务内容、服务期限、

工程类别、规模、技术复杂程度、工程环境等因素确定。

监理人员应包括总监理工程师、专业监理工程师和监理员，必要时可配备总监理工

程师代表。

总监理工程师应由具有三年以上同类工程监理工作经验的人员担任；总监理工程

师代表应由具有二年以上同类工程监理工作经验的人员担任；专业监理工程师应由具

有一年以上同类工程监理工作经验的人员担任。

项目监理机构的监理人员应专业配套、数量满足工程项目监理工作的需要。

监理单位应于委托监理合同签订后十天内将项目监理机构的组织形式、人员构成及

对总监理工程师的任命书面通知建设单位。当总监理工程师需要调整时，监理单位应

征得建设单位同意并书面通知建设单位；当专业监理工程师需要调整时，总监理工程

师应书面通知建设单位和承建单位。

监理人员的职责

一名总监理工程师只宜担任一项委托监理合同的项目总监理工程师工作。当需要同

时担任多项委托监理合同的项目总监理工程师工作时，须经建设单位同意，且最多不

得超过三项。

总监理工程师应履行以下职责：

1确定项目监理机构人员的分工和岗位职责；

2主持编写项目监理规划、审批项目监理实施细则，并负责管理项目监理机构的

日常工作；

3审查分包单位的资质，并提出审查意见；

4检查和监督监理人员的工作，根据工程项目的进展情况可进行监理人员调配，

对不称职的监理人员应调换其工作；

5主持监理工作会议，签发项目监理机构的文件和指令；

6审定承建单位提交的开工报告、施工组织设计、技术方案、进度计划；

7审核签署承建单位的申请、支付证书和竣工结算；

8审查和处理工程变更；

9主持或参与工程质量事故的调查；

10调解建设单位与承建单位的合同争议、处理索赔、审批工程延期；

11组织编写并签发监理月报、监理工作阶段报告、专题报告和项目监理工作总

结；

12审核签认分部工程和单位工程的质量检验评定资料，审查承建单位的竣工申

请，组织监理人员对待验收的工程项目进行质量检查，参与工程项目的竣工验收;

13主持整理工程项目的监理资料。

总监理工程师代表应履行以下职责：

1负责总监理工程师指定或交办的监理工作；

2按总监理工程师的授权，行使总监理工程师的部份职责和权力；

3总监理工程师不得将下列工作委托总监理工程师代表：

1）根据工程项目的进展情况进行监理人员的调配，调换不称职的监理人员；

2）主持编写工程项目监理规划及审批监理实施方案；

3）签发工程开工/复工报审表、工程暂停令、工程款支付证书、工程项目的

竣工验收文件；

4）审核签认竣工结算；

5）调解建设单位和承建单位的合同争议，处理索赔，审批工程延期。

1负责编制本专业的监理实施计划，经总监批准后组织实施；

2负责本专业监理工作的具体实施；

3审查施工方提交的涉及本专业的计划、设计、方案、申请、变更、报告等，并

向总监理工程师提出报告；

4负责本专业的测试审核、单元工程验收，对本专业的子系统工程验收提出验收

意见；

5定期向总监理工程师提交本专业监理工作实施情况报告，对重大问题及时向总

监理工程师汇报和请示；

6根据本专业监理工作实施情况做好监理日志；

7负责本专业监理资料的收集、汇总及整理，参与编写监理月报；

8检查施工方投入工程项目的人力、材料、主要设备及其使用、运行状况，并做

好检查记录；

9按专业分工并配合其它专业对工程进行巡检、现场督导、监理测试或确认见证

数据；

10发现问题及时指出并向总监理工程师报告；

第三部分监理工作流程

工程前期阶段监理

流程

监理业务流程（表1:前期阶段）

愉入承建单待蚱现和构业主单位输出

（阶段开始）

监理合同

政策法规

F

标准规范

业务模型分析、规划设计

行业文件

审核报告

1F

专项报告

监理招标文件协助招投标

监理合同

招标文件

签订承建合同

专项报告

项目启动申请承建合同

承律合同

合同审核报告

系统实施方案

项目开工准备审核

白状出庭计划系统实施方案

审核报告

1F

廿侏出塞冲利

丁田口/hA

审核报告

V

阶段结束

流程描述

前期咨询：提供应用系统建设相关的技术支持服务;

基本业务模型分析：协助业主制定所需应用系统的业务需求指标；进行基本需求的

调研和分析整理工作，基本上明确应用系统的主体思路，为应用系统建设范围的确定

提供依据;

应用系统总体规划：结合基本需求和应用系统的实施框架结构，协助业主对应用系

统进行优先级划分，同时结合国内外的相关类型系统的实施情况，协助业主制定系统

的总体实施规划；

招投标：必要时协助业主进行应用系统的招投标工作；

承建方实力评价：协助业主了解承建方的技术实力和管理能力，客观公正地评价承

建方，为业主评估、选定承建方提供技术方面的参考意见；

签订承建合同：协助业主进行应用系统的实施合同的签订工作；在承建合同中应明

确要求承建单位接受监理方的监理；建议业主单位在承建合同中明确规定工程所包含

的功能、技术要求、测试标准、验收要求和质量责任；建议业主单位在承建合同中明

确工程阶段划分及其质量和进度要求，并依此作为工程阶段性付款的依据；核准投资

预算与付款计划；

评审系统实施方案：协助业主评审系统实施方案的科学性、可行性；协助业主审核

系统建设的量化目标以及考核方法；结合业主的实际情况对实施过程中的风险进行评

估，协助提出规避风险的措施和手段；

审核总体进度计划：审核应用系统承建方的总体实施进度计划，根据软件工程的要

求，审核承建方提出的应用系统总体实施计划是否合理；

项目启动会：项目启动时，召开由业主、承建方和监理方参加的首次会议，明确三

方在项目实施过程中的责任和权利、三方的项目负责人及联系方式、项目实施过程中

三方遇到问题的处理流程、监理例会的具体时间及周期等，并规定监理方和承建方按

时提交报告。

工程需求阶段监理

流程

监理业务流程（表2：需求阶段）

输入承理的待监理和构加主单待蛤1由

监理规程

1调研申请表1

调研计划1r

->调研申请

承建合同审核报告

流程描述

编制监理规程和监理细则；

:审核承建方提交本阶段计划和明细任务分解计划，提出监理建议，对工程进度进行

控制；

督促承建方建立完善的质量保证体系；

建立协调机制：督促建设小组的联系、沟通，有利于本阶段的工作效率和效果；

审核调研方式：协助业主审核调研计划，进行需求调研准备工作，必要时参加需求

的调研工作；

审核调研记录：审核承建方提交的用户需求调研记录（即原始需求），协助业主组织

进行调研记录的确认工作；

组织需求分析报告评审：提交评审预案报告，说明需求分析报告评审的标准规范、

评审项及建议；协助业主组织需求分析报告评审，必要时以“专家评审会”的形式展

开；

协助组织需求分析报告的业主方、监理方、承建方签字确认；

审核承建方提交的测试方案；

定期向业主报告项目实施的进度和质量情况；

工程设计阶段监理

流程

监理业务流程（耨：设计阶段）

।穴工田土n切1蛤山

标准规氾

承建合同1

―>设计报审

士区由主/二1父•\

系统实施方案H1乂衣（匕《文）

1V

1阶段性计划设计符合性评审评审预案

1

质量管理监理通知

整改<-

需求分析报告评审报告

流程描述

审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解

计划，提出监理建议，对工程进度进行控制；

审核承建方的质量保证措施的完备性及有效性；

监督实施小组的联系、沟通，有利于实现过程的工作效率和效果；

协助业主组织系统设计报告评审；

协助业主组织应用系统架构设计、数据库设计的合理性审查；

定期向业主报告项目实施的进度和质量情况。

工程实现阶段监理

流程

流程描述

审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解

计划，提出监理建议，对工程进度进行控制；

审核承建方的质量保证措施的完备性及有效性；

监督实施小组的联系、沟通，有利于实现过程的工作效率和效果；

编码过程的控制：依据承建方的模块开发计划，对系统编码阶段进行过程控制，审

核承建方提交的测试分析报告，必要时进行抽测，随时掌握系统开发的进展情况；

自测管理：督促承建方及时提交单元测试报告、系统模块测试计划、系统模块测试

用例、系统模块测试报告和问题跟踪情况报告；督促承建方对系统出现的问题及时进

行改正和优化；

UI确认：在系统编码结束前，协助业主方组织系统用户界面(UI)的确认；

审核项目开发总结报告：依据合同、需求和设计文档，审查承建方的项目开发总结

报告；

审核系统测试分析报告：审核承建方的系统测试分析报告，并提交系统集成测试审

核报告，如果系统集成测试存在问题，指出问题并督促承建方对进行修正；

评审并评估项目的阶段性成果：组织评审并评估项目的阶段性成果，发现并总结分

析系统试运行中存在的问题和缺陷；

定期向业主报告项目实施的进度和质量情况。

工程验收阶段监理

流程描述

协调进行交工验收：承建方确认应用系统满足需求后，监理方和业主方依据合同执

行情况评估报告中所作的结论与合同中的规定准则和方式判断产品是否已经可以验

收，对于不符合验收条件的，督促承建方对问题进行整改；

审核安装手册和操作使用手册：对承建方提交的安装手册和操作使用手册进行审核;

系统培训管理：审核承建方的培训计划和培训内容，检查和考核培训效果；

评审系统试运行计划和方案：组织评审承建方的应用系统试运行计划和方案，并提

交系统试运行计划和方案的审核报告，如果存在问题，指出问题并督促承建方对其进

行修正；

系统试运行管理：协助进行试运行前数据准备；审核并评估系统试运行的方法、步

骤、条件以及实施的措施，检查为保证系统整体试运行所采取措施的有效性；依据应

用系统试运行计划和方案对应用系统的试运行过程进行控制，及时发现存在的问题，

随时掌握系统试运行的进展情况；并督促承建方对系统试运行中出现的问题及时进行

改进和优化；

评审并评估项目的阶段性成果：组织评审并评估项目的阶段性成果，发现并总结分

析系统试运行中存在的问题和缺陷；协助业主进行试运行的总结、分析并评估系统试

运行的效果；协助业主制定下一步的流程持续改进措施；

协商制定验收程序和验收标准：根据国际、国家标准、规范要求，三方协商制定验

收程序和验收标准；

审核验收申请：依据承建方提交的系统实施文档报告，审核承建方提交的验收申请;

组织合同执行情况评估：依据业主与承建方签订的应用系统实施合同和本应用系统

的实施情况，组织进行评估合同的执行情况，并提交合同执行情况评估报告；

协助组织系统验收测试：监理方和业主方批准承建方提交的验收申请后，协助业主

方组织验收测试，必要时引入第三方测试；协调解决验收过程中发现的问题，对问题

的处理方法以及结果纳入验收记录中。具体验收测试内容：

相关文档审核：依据验收标准对工程文档进行审核；

,审核承建商提交的测试报告，提出监理意见；必要时引入第三方测试或进行监理抽

测；出具监理验收测试报告。

验收报告三方签字确认；

审核系统维护计划：审核承建方提交的系统维护计划，提出意见和看法，对于出现

的问题，督促承建方进行修正，协调进行系统试运行维护，审核承建方的维护记录，

协调解决维护过程中出现的问题；协调相关承建方进行系统联调；

协助组织系统竣工验收会：协调进行竣工验收工作，协助业主方组织进行系统竣工

验收会，必要时可以聘请专家参加；

:监督工程验收后各项文档的移交工作。

第四部分监理控制要点

工程前期阶段监理

标准、规范体系：三方就工程建设中应该采用的总的标准和规范的内容、参考依据

达成一致，作为工程建设的依据。

明确工程范围、总工期：三方就工程建设的总体进度计划、量化目标以及考核方法

达成一致。

明确质量控制标准：三方就工程建设质量保证计划达成一致。

制定工程总体实施规划：三方就工程建设优先级、实施方案和各子系统间接口标准

达成一致，作为工程建设的参考依据。

明确组织结构保障：确定工程建设领导小组的职责及人员构成，建议采用“一把手

负责制”，便于协调工程建设中的各方及相关业务部门的关系。

工程需求阶段监理

明确需求调研涉及各方的职责：确定调研方式、调研范围、涉及各方的职责和权限

划分并制订需求管理规定，督促需求调研的积极进展。

需求调研的组织和协调：业主方、监理方、承建方共同制定调研计划，协调各方及

相关业务部门关系落实计划的执行。

明确系统建设范围：在遵循承建合相关说明情况下，进一步细化系统建设范围，并

作为系统验收的依据之一。

需求评审和需求确认：组织需求调研结果的评审，落实需求分析报告的正确性、完

整性、可验证性等要求，并落实需求分析报告的签字确认，作为以后阶段的依据。

测试计划审核：三方就测试方案达成一致。

工程设计阶段监理

审核阶段性成果：包括概要设计报告。

变更控制：妥善处理系统建设过程中变更事项，进行变更管理，并落实文档的同步

更新。

工程实现阶段监理

审核阶段性成果：包括概要设计报告。

变更控制：妥善处理系统建设过程中变更事项，进行变更管理，并落实文档的同步

更新。

工程验收阶段监理

系统实施：协调系统实施部署计划的执行，建议采用“试点”模式，逐步实现系统

试运行，同时，制定新老系统协调运行业务管理办法，处理好历史数据问题；

验收标准：三方制定验收标准，进行合同执行情况的评估，并落实合同中验收事项

的执行。

第五部分：监理工作手册

软件监理管理要点

系统规划

1)系统规划是否从组织上确定了整体计划的主要体制，是否得到了最高领导的

认可；

2)整体计划是否依照主要规则判定，是否得到了最高领导的认可;

3)整体计划中是否明确了信息化的效果、推进体制、费用等各项内容；

4)整体计划中是否明确说明了信息系统的整体概貌；

5)整体计划中是否明确说明了系统开发的优先级；

6)整体计划中是否明确说明了系统开发的组织及业务改变的方针；

7)整体计划中是否明确说明了安全对策的方针；

8)整体计划是否定期进行修正以及随条件的变化而修正；

9)开发计划是否得到最高领导的认可；

10)开发计划是否考虑到了与整体计划的整合；

11)开发计划是不是在对内外信息技术调查基础上决定的；

12)开发计划是否明确说明了目的、对象业务、性能价格比等各项内容；

13)是否明确说明了改变信息系统生命周期的条件。

系统分析

1)开发计划，需求定义是否得到承建方及用户方认可；

2)用户需求调查是否明确对象、范围及方法；

3)是否由精通业务的用户参与现状分析；

4)是否对随着信息系统引入而产生的风险进行分析；

5)是否对有关信息系统的法律、法规及制度等进行调查；

6)对引入信息系统后受影响的业务、管理体制和各种规程等是否进行研讨与修

正；

7)用户部门及信息部门的作用分配是否明确；

8)开发计划及用户需求是否考虑了软件、硬件和网络等需求；

9)是否有达到信息系统目的的替代方案；

10)是否根据开发的规程、时间及系统的特性来决定承建方法；

11)开发及运行费用的计算模型是否适当，结果是否合理、准确；

12)是否对信息系统的效果进行了定量及定性的评价；

13)是否确保开发所必须的人员、预算、设备及时间等。

系统设计

1)系统设计报告是否得到承建方与用户方负责人的认可；

2)输入输出报表及界面设计是否便于用户使用；

3)数据库是否按业务内容进行设计；

4)数据的整体性是否确保；

5)网络是否按业务内容进行设计；

6)信息系统的性能是否满足用户要求；

7)系统的组成是否考虑系统应用的高峰进行设计；

8)是否设计运行性能管理的技术实现方法；

9)是否考虑信息系统的故障对策；

10)是否设计对不正当行为防止及机密保护等功能；

11)测试计划中是否明确目的、范围、方法及进度安排等；

12)信息系统应用的培训方针、进度等是否明确。

编码

1)程序说明书，是否得到开发负责人认可；

2)是否按照系统设计报告进行程序设计；

3)编码时发现与系统设计有矛盾时，是否对系统设计进行了再讨论;

4)检查编码是否按程序说明书进行；

5)是否对程序测试结果进行登记与保管；

6)重要的程序是否由程序作者以外的人员进行了测试。

系统测试

1)测试数据的选取及系统测试是否按测试计划进行；

2)系统测试是否站在公正、客观立场上进行；

3)系统测试是否由用户参加，是否按照用户手册进行；

4)系统测试结果是否得到开发、运行、维护及用户的负责人认可；

5)是否对系统测试的结果进行记录与保管的认可。

试运行

1)试运行是否按计划进行；

2)是否能根据试运行计划筹备到必要的人员、预算和设备等资源；

3)试运行结果的验收方法是否明确；

4)是否制订试运行后的运行计划，并根据试运行结果进行修正。

运行管理

1)总体操作管理

A.信息系统用户是否制定与遵守运行管理的规则;

B.操作顺序是否标准化，事故及故障对策是否明确；

C.作业进度的决定是否考虑业务处理的优先级；

D.操作是否按作业进程表及指导书进行；

E.例外处理的操作是否按运行管理规则进行；

F.操作员的交替是否按运行管理规则进行；

G.是否对作业进程表与操作事实记录的差异进行分析；

H.是否能把握住信息系统运行状况达到性能管理及资源的有效利用；

I.操作实施记录是否按照运行管理规则保管一定期限；

J.是否记录事故及故障内容，并向信息系统运行负责人报告；

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

L.识别代码及口令的管理是否考虑防止不正当行为及机密保护对策；

M.是否对用户进行了有关信息系统的安全教育及培训。

2)软件管理

A.信息系统用户是否制定及遵守软件管理的规则；

B.对软件的存取及控制、监视是否有防止不正当行为及机密保护对策;

C.信息系统用户是否记录软件利用状况，并定期进行分析；

D.软件备份的范围及方法是否按业务内容及处理状态来决定；

E.软件的保管及废除有否防止不正当行为对策及机密保护对策；

F.软件的拷贝有否防止不正当行为及机密保护对策；

G.对软件有否故障对策；

H.对软件版本如何管理。

3)硬件管理

A.信息系统用户是否制定并遵守硬件管理的规则；

B.对硬件是否设置了能够回避风险的环境；

C.对硬件是否设置了能够应对风险的环境；

D.是否定期对硬件进行维护；

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

F.是否对硬件的利用状况进行记录，并定期进行分析。

4)建筑物及相关设备管理

A.对建筑物及相关设备是否设置了能够回避风险的环境；

B.建筑物及房间的进出管理是否有防止不正当行为的对策及机密保护的对策；

C.对相关设备是否定期进行维护；

D.相关设备是否有故障对策。

5)组成管理

A.所有要管理的软件、硬件、网络的对象范围是否明确；

B.软件、硬件及网络的组成，供应商的支持维护条件是否明确；

C.引入或变更软件、硬件和网络后受到影响的范围是否明确；

D.引入或变更软件、硬件和网络是否按计划实施。

文档编制

1)是否遵守文档编制规范；

2)是否制订文档计划；

3)文档计划的执行情况；

4)文档的种类、目的、制作方法等是否明确；

5)文档是否得到信息系统部门及用户部门负责人的认可。

文档管理

1)是否制定和遵守文档管理规则；

2)文档更新是否得到信息系统部门及用户负责人的认可；

3)在系统需求更新时，文档内容是否进行更新，并留下更新记录；

4)文档的拷贝及废除是否有对不正当行为的防范及机密保护的对策。

进度计划

1)是否按标准格式编写计划书；

2)是否有时间、任务和结果形式；

3)进度安排是否合理。

进度控制

1)承建方是否制订进度管理的方法、体制，是否得到计划、开发、运行及维护

等各业务负责人的认可；

2)计划、开发、运行及维护各业务负责人是否把握进度状况，是否按计划执行;

3)是否有进度延迟的对策；

4)各业务结束时，是否按计划等实施状况进度分析与评价；

5)评价的结果是否反映到下阶段工程的进度计划中；

6)评价的结果是否反映对进度管理的方法与体制等的改进。

进度评价

1)检查在各业务结束时，是否按计划对实施状况进行分析与评价，评价的结果

是否客观、真实，是否分析了影响进度的主要原因，是否提出了相应的应对措施，

应对措施是否合理，能否实现等；

2)检查评价的结果是否反映到下阶段工程的计划中，在下阶段的工程实施过程

中是否按照相应的进度调整计划进行实施；

3)对进度的评价是否反映对进度管理的方法与体制等的改进。

软件监理技术要点

系统规划

任务：确保新开发的信息系统是满足企业战略发展需要的，从技术、经济和操作

的角度来说是可行的、恰当的，但不是不顾企业的实际需要而一味地追求新技术或高

性能的硬件配置。

系统分析(需求分析)

任务：保证需求

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

2)完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或

性能；

3)现实性：制定的需求应该是用现有的硬件技术和软件技术可以实现的；

4)有效性：必须证明需求是正确有效的，确实能解决用户面临的问题。

系统设计

总体设计要求：

1)详细需求的描述

为了设计一个信息系统，设计者必须明白系统能够提供什么信息。

2)数据/信息流的设计

A.数据流和信息流的流动方向以及传输点；

B.数据流和信息流的流动频率以及流动时间；

C.将被格式化的数据流和信息流。

详细设计要求：

1)数据库设计

A.结构

令概念建模：模型反映了实体或对象的关系、实体的属性、实体之间的关

系以及对这些实体、实体属性和实体关系的静态和动态限制；

令数据建模：将概念模型转换成数据模型；

令存储结构设计：决定怎样将这些数据结构线性化和进行分割，以存储在

某些设备上；

令物理结构设计：决定怎样通过具体的存储介质和地点来分配存储结构。

B.数据

令自由存取控制：根据用户的类别分配适当的权限；

令强制性存取控制：数据资源被分为不同的级别，用户也被分配了不同的

存取级别，根据安全策略的定义决定用户对资源的存取权限。

令实体-关系模型中的完整性约束

唯一性：每个实体的实例必须是唯一的；

最大基数：在数据库中存在的一个实体所能产生的实例的最大数目；

最小基数：在数据库中存在的一个实体所能产生的实例的最小数目；

实体关键字：唯一标识实体的实例的属性；

关键字类型：定义实体关键字的属性的类型；

关键字的值：定义组成关键字的属性所允许的一些值。

令属性完整性约束

属性类型：一个属性所允许的数据类型；

属性的值：对于一个属性所允许的一些值；

转换法则：定义一个属性的前一个值到后一个值的转换关系。

令关系完整性约束

键的完整性：定义一个关系的候选键应唯一标识关系的一个元组；

实体完整性：包拯主键不能为空；

参照完整性：保证元组之间协同。当一个元组引用另一个元组的一个

属性时（利用外键），应保证这个属性在另一个元组中是存在的。

令对象完整性约束

唯一标识码：每个对象都必须是唯一的，数据库系统能产生一个对象

标识码，在对象的生命周期中唯一标识这个实体；

唯一键：唯一键与唯一标识码是不同的，唯一标识码是系统产生的，

唯一键是用户产生的；

属性类型：对象的属性允许的类型；

属性的值：对象的属性所允许的一些值；

类型和继承：保证一个对象的子对象继承了它的所有属性。

令对象关系完整性约束

参照完整性：一个对象要引用另一个对象，被应用的对象必须存在并

且是正确的类型；

合成完整性：规定的合成关系中，对应对象的插入和删除的行为；

基数完整性：在一个关系中，特殊类型对象的最大和最少数目。

2)用户界面设计

A.屏幕的组织

B.标题设计

C.数据输入框设计

D.颜色设计

E.响应时间

F.提示和帮助的设计

3)模块详细设计

A.模块要求独立性强；

B.模块规模应适中；

C.深度、宽度、输入和输出都应适当；

D.模块的作用域应该在控制域之内；

E.力争降低模块接口的复杂度；

F.设计单入口单出口的模块；

G.模块功能可以预测。

4)硬件或软件平台的设计和获得

要考虑硬件及软件平台的设计上相互之间的兼容程度，理想状况下，不同的硬件和

系统软件可以互相交流。

编码要求：

主要是从编程语言的选择、编程风格、编码方法，以及相关文档的编写这几个方

面进行考虑。

1)程序内部的文档

A.选取含义鲜明的名字，使它能正确地提示程序对象所代表的实体；

B.正确的注解非常有助于对程序的理解；

C.程序清单对程序的可读性有很大的影响。

2)数据说明

A.数据说明的次序应该标准化；

B.当多个变量名字在一个语句中说明时，应该按字母顺序排列这些变量；

C.如果设计时使用了一个复杂的数据结构，则应该用注解说明用这种程序设计

语言实现这个数据结构的方法和特点。

3)语句构造

A.不要为了节省空间而把多个语句写在同一行；

B.尽量避免复杂的条件测试；

C.尽量减少对“非”条件的测试；

D.避免大量使用循环嵌套和条件嵌套；

E.利用括号使逻辑表达式和算术表达式清晰直观。

4)输入输出

A.对所有输入数据进行校验；

B.检查输入项重要组合的合法性；

C.保持输入格式简单；

D.使用数据结束标记，不要要求用户指定数据的数目；

E.明确提交交互式输入的请求，详细说明可用的选择和边界数值；

F.设计良好的输出表格；

G.给所有输出数据加标志。

5)效率

效率主要指时间和容量两方面。首先，应该在需求分析阶段确定效率方面的要求;

其次，效率是靠好设计来提高的；第三，程序的效率和程序的简单程度是一致的，

包括程序运行的时间，存储器效率和输入输出效率。

6)编码

程序的每个模块都只能有一个入口和一个出口，模块的长度建议限制在50—100

个语句范围，应采用自顶向下的流控制。

7)文档

高质量的文档是减少编码错误和提高以后可维护性的有利途径。

A.提供程序主要组成部分和相互关系的图表；

B.在程序中利用各种注释可阐明程序的特点、作用以及不同的组成部分和逻辑

关系；

C.对于不同类型的变量、常量、程序段和模块等，使用有意义的名字可增强程

序的可阅读性；

D.有格式的书写程序可增强阅读性。

测试要求：

1)单元测试

2)集成测试

3)总体测试

运行要求：

1)系统输入

数据录入是整个信息系统运行的非常关键的一个环节，是以后报表生成和决策支

持的基础

数据有效性验证。

A.字段检验

数据缺省或空值检验

字母或数字检验

范围检验

校验码检验

主文件参照

大小检验

格式检验

B.记录检验

合理性

大小

顺序检验

C.批检验

控制总量

批类型

顺序检验

D.文件检验

内部标签

版本号

有效期

2)错误报告

A.清晰和简洁

B.语言严谨中立

信息系统生命周期支持业务

文档

1)意义

A.文档可以作为开发人员在一定阶段内的工作成果和结束的标志，各阶段的人

员通过文档进行交接工作；

B.文档可以作为管理依据；

C.文档可用做未来项目的一种资源；

D.文档可以作为运行、维护和培训的参考依据；

E.文档对保证软件质量起到重要作用。

2)主要内容

A.可行性研究：可行性研究报告、项目开发计划、系统需求说明书、数据要求

说明、开发进度月报；

B.需求分析：项目开发计划、系统需求说蜜柑内、数据要求说明、测试计划、

用户手册、开发进度月报；

C.设计：概要设计说明、详细设计说明、测试计划、用户手册、操作手册、开

发进度月报；

D.代码编写：用户手册、操作手册、开发进度月报；

E.测试：测试分析报告、开发进度月报、项目开发总结；

F.运行与维护：维护修改日志。

3)质量要求

A.针对性；

B.精确性；

C.清晰性；

D.完整性；

E.灵活性；

F.可追溯性。

文档的版本管理是文档管理的一个必要方面。需求文档的每一版本必须被统一确

定，并保证开发成员得到需要的当前版本。此外，在需求进行变更时，需要清楚地

将变更以文档形式记录下来，并通知相关人员。

进度

进度计划要求

1)GATT图；

2)网络图。

进度控制要求

1)用各种控制手段保证项目及各个任务活动按计划及时开始，在项目过程中记

录各任务活动的开始和结束时间及完成程度；

2)在各个阶段结束时，按各任务的完成情况对比计划，确定整个项目的完成程

度，并结合时间、开发内容、效率、消耗等评价项目进度状况，分析其中的问题；

3)对下期工作做出安排，对一些已开始，但尚未结束的项目单元的剩余时间做

估算，分析调整进度的措施；

4)根据已完成的状况做新的安排和计划，并预测新的进度状况；

5)分析新的进度计划是否符合合理性需求，如不符合，如何采取调整措施等。

进度调整要求

1)调整过程

A.为了调整进度，应深入现场，进行调查，分析产生偏差的原因；

B.在查明产生原因之后，要分析偏差对后续工作和总进度的影响，确定是否应

当调整；

C.在分析了对后续工作和总进度的影响以后，需要采取一定的调整措施时，应

当首先确定进度可调整的范围，主要关键节点、后续工作的限制条件以及总进度

允许变化的范围；

D.采取进度调整措施，以后续工作和总进度的限制条件为依据，对原进度计划

调整，以保证进度目标的实现；

E.在项目继续实施中，执行调整后的进度计划。

2)调整方法

A.调整任务之间的顺延关系；

B.缩短某些任务的持续时间。

人员管理

职责权限要求：要遵循“职责分离”的原则。目的在于保证不同职责有不同的人

承担，保证人员之间的工作可互相检查和监督。

业务分配要求：

1)考察业务与能力，考虑人员的能力与岗位的要求是否匹配，业务分配及业务

量是否考虑到人员的知识与能力；

2)考察人员的接替过程对不可预测风险的防范情况。

灾难对策

1)灾难应急计划；

2)备份计划；

3)替代处理。

评价计划

安全性

1)资产安全性

2)数据安全性

包括容错能力；已经存在或潜在的数据错误，以及这些错误的规模及数量。

3)总体安全性

测试单个控制的强弱，并不断地对信息系统安全性作出全局性的判断。

可靠性

概念：

1)指产品在规定的条件、规定的时间内完成规定功能的能力或无故障运行的概

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

2)信息系统可靠性是指系统在规定时间内无故障运行的概率。

软件可靠性

1)软件可靠度表示在规定的运行环境和规定的时间内软件无故障运行的概率；

2)软件故障强度，软件故障率的物理解释是单位时间内软件发生故障的概率；

3)平均故障间隔时间是相邻两次故障间工作时间的数学期望；

4)平均故障修复时间表示软件从发现故障到软件恢复规定功能所需的时间，即

故障诊断、修复准备及修复实施时间之和。

有效性

评价过程

1)明确评价目标；

2)评价费用的预算；

3)明确性能指标；

4)构建负荷模型；

5)构建系统模型；

6)进行实验；

7)结果分析；

8)给出建议。

性能指标

系统有效性的量度标准，反映了系统实现某些性能标准的数量特征

1)时间性指标：表述作为输入系统到系统输出用户所需结果的时间周期；

2)吞吐率指标：系统生产力的度量标准，描述了在给定时间内系统处理的工作

量；

3)利用率指标：以系统资源处于忙状态的时间为度量标准；

4)可靠性指标：系统处理用户工作的可用性或处理过程失败或错误的概率。

负荷模型

系统负荷是在给定时间段内作业提出所需系统资源和服务请求的总量。

系统模型

为了确定一个系统是否可以提高性能，需要对系统进行建模。建模过程包括识别

系统单元、单元界面、系统运行方式、输入输出之间的功能关系等。

综合评价

评价过程

1)确定信息系统的主要目标；

2)选择评价标准；

3)确定评价数据来源；

4)事先系统的价值；

5)事后系统的价值；

6)估计系统的影响。

评价内容

1)系统质量

A.响应时间；

B.周转时间；

C.系统可靠性；

D.系统界面的友好程度；

E.功能性；

F.易用性；

G.文档、帮助资料的质量；

H.与其他系统的集成度。

2)信息质量

A.真实性；

B.精确性；

C.完整性；

D.非冗余性；

E.时间性；

F.关联性；

G.综合性；

H.精密度；

I.简明；

J.信息性。

3)有用性感受

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

B.是否改善了用户的工作表现;

C.是否提高了用户的生产力；

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

E.是否提高了用户对工作任务的理解；

F.是否对他们的工作有帮助；

4)易用性感受

A.是否比较容易学习如何操作；

B.用户是否能方便地利用信息系统完成他们的工作；

C.用户与信息系统之间的交互是否清晰、易懂、顺畅、灵活;

D.用户是否能利用信息系统快速地适应工作要求；

E.用户是否认为信息系统的操作很容易；

5)用户对计算机使用能力的判断；

6)信息系统的使用情况。

7)个人影响

8)信息系统满意度

A.与信息系统开发/维护人员的人际关系；

B.对系统变更要求的处理方式；

C.信息的时间性；

D.针对用户的信息系统技能培训；

E.输出的相关性；

F.输出的量；

G.文档质量；

H.信息系统依赖性。

9)组织影响

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

(部分)

为了更加规范工程管理，对工程中的文档处理流程进行进一步的明确和细化，承

建方、监理方和业主方在工程实施过程中严格按照本规范进行文档的处理和存档。

监理方业务联系单

监理方业务联系单是监理方与业主方进行业务交流的方式，主要包括监理人员确定、

监理文档格式、工程进度质量状况及建议、抽测报告、检验记录和测试报告等。业务

联系单根据实施情况需要，由总监或总监代表审核后提交。

编号规则：［年度］LXD（监）xxx号。

监理方周报/月报/阶段总结报告

监理方周报在审核承建方周报的基础上，完成监理方周报，主要描述监理的参加人员

和工作情况。

监理方月报/阶段总结报告是监理方对工程的阶段总结报告，在每月5日前提交上月

月报，阶段总结报告不定期提交。

编号规则：［年度］文件标识（监）xxx号。如［年度］GCZB（监）xxx号、［年度］GCYB（监）xxx

号、［年度］JDBG（监）xxx号。

监理方监理通知

监理通知是监理方针对工程实施过程中存在问题与承建方交流的方式，根据实施情况

需要，由总监或总监代表审核后提交。

编号规则：［年度］JLTZ（监）xxx号。

会议纪要

由监理方对工程实施协调会的精神进行归纳整理形成会议纪要，会议纪要需要承建方

项目负责人、总监或总监代表和业主方项目负责人签字。

文档格式

软件咨询部所涉及的工程文档包括下述类别，主要文档的模版参见附录。

软件咨询部工程文档类别（6艮存期限10年）

1监理日志SDZZ-12-QR001项目管理人员编写，必须当日完成。

2监理规程SDZZ-12-QR002项目组编写，不要求固定格式。

3监理实施细则SDZZ-12-QR003项目组编写，不要求固定格式。

1监理人员名单SDZZ-12-QR004项目负责人与部门协商提供。

5工程开工/停工/复工通知SDZZ-12-QR005项目负责人编写。

6监理周度/月度报告SDZZ-12-QR006项目管理人员编写。

7监理会议纪要SDZZ-12-QR007项目管理人员编写，需及时编写。

8工程监理通知SDZZ-12-QR010项目管理人员编写，需及时编写。

9付款申请SDZZ-12-QR014部门领导审批。

10XXXX审核报告SDZZ-12-QR015项目负责人和管理人员编写。

11工程延期报告SDZZ-12-QR016项目负责人编写。

12费用索赔及报告SDZZ-12-QR017项目负责人编写，部门协助。

13合同争议及违约处理意见SDZZ-12-QR018项目负责人编写，部门协助。

14合同变更SDZZ-12-QR019项目负责人编写，部门协助。

15监理签收单SDZZ-12-QR021项目管理人员负责。

16工程文档卷内目录SDZZ-12-QR026项目管理人员负责。

17监理业务联系单SDZZ-12-项目负责人编写。

18监理（阶段）总结报告SDZZ-12-项目负责人编写，不要求固定格式。

19监理（阶段）测试计划SDZZ-12-项目负责人编写，不要求固定格式。

20监理（阶段）测试用例SDZZ-12-项目负责人编写，不要求固定格式。

21监理测试日志SDZZ-12-项目管理人员负责，不要求固定格

式。

22监理（阶段）测试问题报告SDZZ-12-项目负责人编写，不要求固定格式。

23监理（阶段）测试分析报告SDZZ-12-项目负责人编写，不要求固定格式。

24监理专项报告SDZZ-12-QR020项目负责人编写，不要求固定格式。

监理日志

SDZZ-12-QR001

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

业主方

监理方

承建方

简

述

监理工程师：

监理人员名单

SDZZ-12-QR004

项目名称：

总监理工程师：联系电话

监理工程师：联系电话

监理工程师：联系电话

监理工程师：联系电话

监理工程师：联系电话

监理工程师：联系电话

监理工程师：联系电话

业主方签收（盖章）山东省计算中心

年月日年月日

工程开工（停工、复工）通知

SDZZ-12-QR005

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

业主方

监理方

承建方

通知内容：

监理方代表：业主方代表：

监理周（月）度报告

SDZZ-12-QR006

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

业主方

监理方

承建方

1

工

程

进

度

、

质

量

状

况

及

建

议

监理工程师：业主方代表：

监理会议纪要

SDZZ-12-QR007

加的颐中公司青岛卷烟厂“十五”CIMS工程日期2004年01月11日

业主方颐中公司青岛卷烟厂

监理方山东省计算中心

承建方

地点：时间：**:**（时：分）

参加人员：

主持：

会议议题：

监理方代表：业主方代表：承建方代表：

监理通知

SDZZ-12-QR010

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

业主方

监理方

承建方

致承建方：

事由：

通知内容：

监理工程师：承建方：

抄送业主方：

付款申请

SDZZ-12-QR014

项目的日期****年**月**日

业主方

监理方

承建方

XXXXXXXXX领导：

依据XXXXX与XXXXXX签署的合同要求和XXX设备的运

行、检验情况，经我方监理人员与贵方项目负责人研