信息系统应用工程监理细则

《 信息化工程监理细则（信息系统应用工程部分） 》

目 录

第 1 页

1.工程概述

信息系统应用工程即软件工程，是一类求解软件的工程，它应用计算机科学、数学（用于构造模型和算法）和管理科学（用户计划、资源、质量和成本等的管理）等原理，借鉴传统工程（用于制定规范、设计范型、评估成本、权衡结果)的原则和方法，创建软件已达到提高质量、降低成本的目的. 2。工程建设内容

软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动.

需求活动包括需求分析和问题分析.问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。

设计活动一般包括该药设计和详细设计。概要设计建立整个软件体系结构,包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。

实现活动把设计结果转换为可执行的程序代码。

确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求. 支持活动包括修改和完善。

伴随以上活动，还有管理过程、支持过程、培训过程等。归结起来，软件工程活动包括以下基本内容:

2.1需求：定义问题,即建立系统模型，包括以下主要任务： 2.1。1需求获取:需求定义.市系统功能的一个正确的陈述。

2.1.2需求规约：系统需求规格说明。主要成分是系统模型，是系统功能的一个精确、系统的描述.

2.1。3需求验证:对获取的需求进行验证。

2。2设计：在需求分析基础上，给出系统的软件解决方案。 2。2.1总体设计

2.2。1。1系统的软件体系结构 2。2。1。2 C/S结构、B/S结构 2.2。1.3 以数据库为中心的结构 2.2.1。4管道结构 2.2.1.5面向对象的结构

第 2 页

2。2.1.6其它

2.2.2详细设计：针对总体设计结果，给出每一构件的详细描述。 2.3实现：选择可用的构件，或以一种选定的语言,对每一构件进行编码。 2。4确认：贯穿软件开发的整个过程,主要任务是软件测试。 2。5支持：完善性维护和纠错性维护. 3.监理依据

依据“委托原则”，在业主方的委托授权范围内，依据相关的合同及标准,对项目的全过程开展监理工作。在工程监理过程中，依据的相关材料包括: 3。1招标人与施工方签订的工程建设承包合同:明确监理方的地位。

3.2招标人与监理方签订的工程建设监理合同：明确监理方的责任、权利和义务。 3。3国际标准、国家和行业标准。

根据合同执行的具体情况，如适用,则应选择使用下列现行的有关技术规范、规程和技术标准：

 ISO 9000—3:1997 质量管理和质量保证标准第三部分

 ISO 9001—1994 在计算机软件开发、供应、安装和维护中的应用指南  GB/T 16260—1996 信息技术 软件产品 质量特性及其使用指南  GB/T 9385-88 计算机软件需求说明编写指南  GB/T 9386—88 计算机软件测试文件编制规范  GB/T 12504—90 计算机软件质量标准保证计划规范  GB/T 12505—90 计算机软件配置管理计划规范  GB/T 12207—1995 信息技术 软件生存周期过程  GB/T 14079-93 计算机软件维护指南

 GB/T 14394—93 计算机软件可靠性和可维护性管理  GB/T 15532-95 计算机软件单元测试  GB/T 11457-1995 软件工程术语 4.监理内容

对于信息系统应用工程监理的内容,主要围绕信息产业部正式颁布的《信息系统工程监理暂行规定》第九条规定的对信息系统工程的质量、进度、投资进行监督，对项目合同和文档进行管理，协调有关单位间的工作关系。 4.1质量控制

第 3 页

质量控制要贯穿项目建设从可行性分析、设计、开发、实施、测试、验收和用户维护的

全过程。主要包括组织设计方案评比,进行设计方案磋商，控制设计变更，在实施前审查承建单位资质等，在实施中采用多种控制手段检查监督标准、规范的贯彻，以及通过阶段验收和竣工验收把好质量关等. 4.2进度控制

主要工作内容是要在开发前期通过周密分析研究确定合理的工期目标，并在实施前将工

期要求纳入承建合同；在软件开发、实施阶段通过运筹学、网络计划技术等科学手段,审查、修改实施组织设计和进度计划，做好协调与监督,排除干扰,使单项工程及其分阶段目标工期逐步实现，最终保证项目建设总工期的实现。 4.3投资控制

主要工作内容是在开发前期进行可行性研究，协助业主单位正确的进行投资决策，在设

计阶段对设计方案、设计标准、总预算进行审查；在开发准备阶段协助确定标底和合同造价；在开发阶段审核设计变更,核实已完成的工程量，进行工程进度款签证和索赔控制；在工程竣工阶段审核工程结算. 4。4变更控制

主要工作内容是对接受应用软件系统建设过程中的变更申请，收集变更信息资料，对发

生的所有变更情况按照一定的程序进行处理，并对变更的内容、方式、范围应用进行评估和控制。 4。5合同管理

合同管理是进行投资控制、工期控制和质量控制的手段。因为合同管理是监理单位站在

公正立场采取各种控制、协调与监督措施,履行纠纷调解职责的依据，也是实施三大目标控制的出发点和归宿。 4。6安全管理

信息系统安全管理的作用是保证业主在信息系统工程项目建设过程中，保证信息系统的

安全在可用型、保密性、完整性与信息系统工程的可维护性技术环节上没有冲突；在投资控制的前提下，确保信息系统安全设计上没有漏洞；督促业主的信息系统工程应用人员在安全管理制度和安全规范下严格执行安全操作和管理,建立安全意识;监督承建单位按照技术标准和建设方案实施；检查承建单位是否存在设计过程中的非安全隐患行为或现象等. 4.7信息管理

确保项目信息管理工作规范化，保证项目信息的准确性、完整性和可用性,确保项目信

第 4 页

息交流、信息沟通渠道畅通，规范信息组织及信息管理，为项目实施管理及决策提出信息依据。 4。8协调

协调贯穿在整个信息系统工程从设计到实施再到验收的全过程.主要采用现场和会议方

式进行协调.

针对信息工程应用系统的特点,在后续的条目中详细描述监理流程、各不同阶段的监理

要点及相关监理工作手册，以指导软件监理工程师工作的顺利实施。 5.监理流程

5.1工程前期阶段监理 5。1。1工作流程

第 5 页

5。1.2流程描述

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

5.1.2。2基本业务模型分析：协助业主制定所需应用系统的业务需求指标；进行基本需求的调研和分析整理工作,基本上明确应用系统的主体思路，为应用系统建设范围的确定提供依据;

5.1.2.3用系统总体规划:结合基本需求和应用系统的实施框架结构,协助业主对应用系统进行优先级划分，同时结合国内外的相关类型系统的实施情况,协助业主制定系统的总体实施规划;

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

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

第 6 页

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

5。1.2.6签订开发合同：协助业主进行应用系统的开发合同的签订工作；在承建合同中应明确要求承建单位接受监理方的监理；建议业主单位在承建合同中明确规定工程所包含的功能、技术要求、测试标准、验收要求和质量责任；建议业主单位在开发合同中明确工程阶段划分及其质量和进度要求，并依此作为工程阶段性付款的依据；核准投资预算与付款计划； 5.1。2.7评审系统实施方案：协助业主评审系统实施方案的科学性、可行性；协助业主审核系统建设的量化目标以及考核方法;结合业主的实际情况对实施过程中的风险进行评估,协助提出规避风险的措施和手段；

5.1。2。8评审总体进度计划：评审应用系统承建方的总体实施进度计划,根据软件工程的要求，评审承建方提出的应用系统总体实施计划是否合理；

5.1。2.9项目启动会:项目启动时，召开由委托方、业主方、承建方和监理方参加的首次会议，明确四方在项目实施过程中的责任和权利、四方的项目负责人及联系方式、项目实施过程中三方遇到问题的处理流程、监理例会的具体时间及周期等,并规定监理方和承建方按时提交报告。

5.2 工程需求阶段监理 5。2.1工作流程

第 7 页

第 8 页

5.2。2流程描述

5.2。2。1编制监理规程和监理细则；

5.2.2。2审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解计划，提出监理建议，对工程进度进行控制； 5.2.2.3督促承建方建立完善的质量保证体系；

5。2。2.4建立协调机制：督促建设小组的联系、沟通，有利于本阶段的工作效率和效果； 5.2.2.5审核调研方式：协助业主审核调研计划，进行需求调研准备工作，必要时参加需求的调研工作；

5.2。2。6审核调研记录：审核承建方提交的用户需求调研记录（即原始需求)，协助业主组织进行调研记录的确认工作;

5.2.2.7组织需求分析报告评审：提交评审预案报告，说明需求分析报告评审的标准规范、评审项及建议;协助业主组织需求分析报告评审，必要时以“专家评审会”的形式展开； 5.2.2.8协助组织需求分析报告的业主方、监理方、承建方签字确认； 5。2。2.9审核承建方提交的测试方案；

5.2.2。10定期向业主报告项目实施的进度和质量情况; 5.3 工程设计阶段监理 5.3.1工作流程

第 9 页

5。3。2流程描述

5。3。2。1审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解计划，提出监理建议，对工程进度进行控制； 5。3.2.2审核承建方的质量保证措施的完备性及有效性；

第 10 页

5.3.2。3监督实施小组的联系、沟通，有利于实现过程的工作效率和效果； 5。3.2.4协助业主组织系统设计报告评审；

5.3.2。5协助业主组织应用系统架构设计、数据库设计的合理性审查; 5。3.2.6定期向业主报告项目实施的进度和质量情况。 5。4 工程实施阶段监理 5.4。1工作流程

第 11 页

5。4。2流程描述

5.4.2。1审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解计划,提出监理建议，对工程进度进行控制；

第 12 页

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

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

5.4.2。4编码过程的控制：依据承建方的模块开发计划，对系统编码阶段进行过程控制，审核承建方提交的测试分析报告,必要时进行抽测，随时掌握系统开发的进展情况； 5。4。2。5自测管理：督促承建方及时提交单元测试报告、系统模块测试计划、系统模块测试用例、系统模块测试报告和问题跟踪情况报告;督促承建方对系统出现的问题及时进行改正和优化；

5。4.2.6UI确认：在系统编码结束前，协助业主方组织系统用户界面(UI）的确认； 5.4.2.7审核项目开发总结报告:依据合同、需求和设计文档，审查承建方的项目开发总结报告；

5.4。2.8审核系统测试分析报告：审核承建方的系统测试分析报告，并提交系统集成测试审核报告，如果系统集成测试存在问题，指出问题并督促承建方对进行修正;

5.4.2。9评审并评估项目的阶段性成果：组织评审并评估项目的阶段性成果,发现并总结分析系统试运行中存在的问题和缺陷;

5.4.2。10定期向业主报告项目实施的进度和质量情况。 5.5 工程验收阶段监理 5.5。1工作流程

第 13 页

第 14 页

5。5。2流程描述

5.5。2。1协调进行交工验收：承建方确认应用系统满足需求后，监理方和业主方依据合同执行情况评估报告中所作的结论与合同中的规定准则和方式判断产品是否已经可以验收，对于不符合验收条件的，督促承建方对问题进行整改；

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

5。5.2。3系统培训管理：审核承建方的培训计划和培训内容，检查和考核培训效果； 5。5。2。4评审系统试运行计划和方案：组织评审承建方的应用系统试运行计划和方案,并提交系统试运行计划和方案的审核报告，如果存在问题，指出问题并督促承建方对其进行修正;

5。5.2.5系统试运行管理:协助进行试运行前数据准备；审核并评估系统试运行的方法、步骤、条件以及实施的措施，检查为保证系统整体试运行所采取措施的有效性；依据应用系统试运行计划和方案对应用系统的试运行过程进行控制，及时发现存在的问题，随时掌握系统试运行的进展情况；并督促承建方对系统试运行中出现的问题及时进行改进和优化； 5。5.2.6评审并评估项目的阶段性成果：组织评审并评估项目的阶段性成果，发现并总结分析系统试运行中存在的问题和缺陷；协助业主进行试运行的总结、分析并评估系统试运行的效果；协助业主制定下一步的流程持续改进措施；

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

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

5.5。2.9组织合同执行情况评估:依据业主与承建方签订的应用系统实施合同和本应用系统的实施情况，组织进行评估合同的执行情况,并提交合同执行情况评估报告;

5。5.2.10协助组织系统验收测试：监理方和业主方批准承建方提交的验收申请后，协助业主方组织验收测试，必要时引入第三方测试;协调解决验收过程中发现的问题，对问题的处理方法以及结果纳入验收记录中。具体验收测试内容:

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

(b) 协助业主方组织验收测试,审核承建商提交的测试报告,提出监理意见；必要时引入

第三方测试或进行监理抽测;出具监理验收测试报告。 (c) 验收报告三方签字确认；

第 15 页

5。5。2。11审核系统维护计划：审核承建方提交的系统维护计划，提出意见和看法,对于出现的问题，督促承建方进行修正,协调进行系统试运行维护，审核承建方的维护记录,协调解决维护过程中出现的问题;协调相关承建方进行系统联调；

5。5.2。12协助组织系统竣工验收会：协调进行竣工验收工作，协助业主方组织进行系统竣工验收会，必要时可以聘请专家参加；

5。5.2。13验收文档移交：监督工程验收后各项文档的移交工作. 6。监理控制要点 6.1 工程前期阶段监理 6.1.1标准、规范体系

三方或四方就工程建设中应该采用的总的标准和规范的内容、参考依据达成一致，作为工程建设的依据.

6.1。2明确工程范围、总工期

三方或四方就工程建设的总体进度计划、量化目标以及考核方法达成一致。 6.1.3明确质量控制标准

三方或四方就工程建设质量保证计划达成一致。 6.1.4制定工程总体实施规划：

三方或四方就工程建设优先级、实施方案和各子系统间接口标准达成一致，作为工程建设的参考依据.

6.1.5明确组织结构保障

确定工程建设领导小组的职责及人员构成，建议采用“一把手负责制”,便于协调工程建设中的各方及相关业务部门的关系。 6。2

工程需求阶段监理

6。2。1明确需求调研涉及各方的职责

确定调研方式、调研范围、涉及各方的职责和权限划分并制订需求管理规定,督促需求调研的积极进展。

6.2.2需求调研的组织和协调

业主方、监理方、承建方共同制定调研计划，协调各方及相关业务部门关系落实计划的执行. 6。2.3明确系统建设范围

在遵循承建合相关说明情况下，进一步细化系统建设范围，并作为系统验收的依据之一。 6.2。4需求评审和需求确认

第 16 页

组织需求调研结果的评审，落实需求分析报告的正确性、完整性、可验证性等要求,并落实需求分析报告的签字确认，作为以后阶段的依据。 6。2。5测试计划审核

三方或四方就测试方案达成一致。 6。3

工程设计阶段监理

6.3.1审核阶段性成果

审核工程设计阶段的成果，包括概要设计报告、详细设计报告、数据库设计报告、界面设计原型等。 6.3。2变更控制

妥善处理系统建设过程中变更事项，进行变更管理,并落实文档的同步更新。 6。4

工程实施阶段监理

6.4.1审核阶段性成果

审核工程实施阶段的成果,包括程序编码规范、测试计划、测试用例、测试分析报告、培训计划、培训记录等. 6.4。2变更控制

妥善处理系统建设过程中变更事项，进行变更管理，并落实文档的同步更新. 6。5

工程验收阶段监理

6.5.1系统实施

协调系统实施部署计划的执行，建议采用“试点”模式,逐步实现系统试运行，同时，制定新老系统协调运行业务管理办法，处理好历史数据问题; 6.5。2验收标准

三方制定验收标准，进行合同执行情况的评估，并落实合同中验收事项的执行。 7。监理工作手册 7。1。1实施准备

7.1。1。1系统规划是否从组织上确定了整体计划的主要,是否得到了最高领导的认可； 7.1。1。2整体计划是否依照主要规则判定，是否得到了最高领导的认可； 7.1.1.3整体计划中是否明确了信息化的效果、推进、费用等各项内容； 7.1.1.4整体计划中是否明确说明了信息系统的整体概貌； 7.1。1.5整体计划中是否明确说明了系统开发的优先级；

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

第 17 页

7。1。1。7整体计划中是否明确说明了安全对策的方针； 7.1。1。8整体计划是否定期进行修正以及随条件的变化而修正； 7。1。1。9开发计划是否得到最高领导的认可； 7。1.1.10开发计划是否考虑到了与整体计划的整合；

7。1。1.11开发计划是不是在对内外信息技术调查基础上决定的；

7.1.1。12开发计划是否明确说明了目的、对象业务、性能价格比等各项内容； 7。1.1。13开发计划是否明确说明了改变信息系统生命周期的条件； 7.1.1.14是否具有明确的项目质量计划。 7.1。2系统分析

7。1。2。1开发计划，需求定义是否得到承建方及用户方认可; 7.1.2.2用户需求调查是否明确对象、范围及方法； 7。1.2。3是否由精通业务的用户参与现状分析；

7。1.2。4是否对随着信息系统引入而产生的风险进行分析; 7.1.2.5是否对有关信息系统的法律、法规及制度等进行调查；

7。1。2.6对引入信息系统后受影响的业务、管理和各种规程等是否进行研讨与修正; 7。1.2.7用户部门及信息部门的作用分配是否明确；

7.1。2.8开发计划及用户需求是否考虑了软件、硬件和网络等需求； 7.1.2。9是否有达到信息系统目的的替代方案;

7.1.2。10是否根据开发的规程、时间及系统的特性来决定承建方法； 7.1.2.11开发及运行费用的计算模型是否适当，结果是否合理、准确； 7。1.2。12是否对信息系统的效果进行了定量及定性的评价; 7.1。2。13是否确保开发所必须的人员、预算、设备及时间等； 7.1。2。14是否有明确的业务状况调研问卷； 7。1。2.15是否有明确的业务状况调研报告；

7。1.2.16需求分析规格说明书是否得到了承建方及业主方、委托方的认可。 7.1。3系统设计

7.1。3.1系统设计报告是否得到承建方与业主方（或委托方）负责人的认可； 7.1。3。2输入输出报表及界面设计是否便于用户使用； 7。1。3.3输入输出报表及界面设计是否得到用户的签字确认； 7。1.3。4数据库是否按业务内容进行设计；

第 18 页

7。1。3。5数据的整体性是否确保； 7。1。3。6网络是否按业务内容进行设计; 7.1。3。7信息系统的性能是否满足用户要求;

7.1。3.8系统的组成是否考虑系统应用的高峰进行设计； 7.1.3。9是否设计运行性能管理的技术实现方法； 7。1.3.10是否考虑信息系统的故障对策；

7.1。3。11是否设计对不正当行为防止及机密保护等功能; 7.1.3.12测试计划中是否明确目的、范围、方法及进度安排等； 7.1.3。13信息系统应用的培训方针、进度等是否明确。 7。1。4编码

7.1.4.1程序说明书，是否得到开发负责人认可； 7.1。4.2是否按照系统设计报告进行程序设计;

7。1.4.3编码时发现与系统设计有矛盾时，是否对系统设计进行了再讨论； 7。1.4。4检查编码是否按程序说明书进行; 7。1。4.5是否对程序测试结果进行登记与保管；

7。1.4。6重要的程序是否由程序作者以外的人员进行了测试. 7.1。5系统测试

7.1.5。1测试用例数据的选取及系统测试是否按测试计划进行； 7.1。5.2系统测试是否站在公正、客观立场上进行;

7。1.5.3系统测试是否由用户参加，是否按照用户手册进行；

7.1.5。4系统测试结果是否得到开发、运行、维护及用户的负责人认可; 7.1.5。5系统的测试是否考虑容量、并发数等边界条件; 7。1.5.6是否对系统测试的结果进行记录与保管的认可. 7.1。6系统初始化

7。1.6。1是否收集到了完整的初始化数据； 7.1.6。2是否对初始化数据加以有效整理; 7。1。6。3是否对初始化数据进行评审;

7.1。6。4整理过的初始化数据是否得到业主方的签字认可； 7.1.6.5是否能够有效的将各类数据初始化;

7。1。6。6初始化的数据是否正确并得到业主方的签字认可。

第 19 页

7。1.7系统培训

7。1。7.1是否有完整的培训计划； 7。1.7.2是否有系统培训记录; 7。1。7.3是否按照培训计划进行培训； 7.1。7.4是否有完善的培训教材。 7.1。8试运行

7。1。8.1试运行是否按计划进行；

7.1.8。2是否能根据试运行计划筹备到必要的人员、预算和设备等资源; 7。1。8。3系统的性能是否满足用户的需求; 7。1.8。4系统的组成是否考虑高峰进行设计； 7。1.8.5是否考虑信息系统的故障对策；

7。1.8.6是否设计对不正当行为的防止和机密保护等功能； 7.1。8.7并行运行业务数据录入规则是否正确； 7.1。8。8试运行结果的验收方法是否正确; 7。1。8。9是否制定试运行后的运行计划;

7。1.8.10试运行顺序的制定是否考虑到试运行的条件； 7。1.8。11是否对修改前的程序及数据做好了备份； 7.1。8.12试运行负责人是否验证其信息系统不受影响； 7.1.8。13试运行结果的验收方法是否明确；

7。1.8。14是否制订试运行后的运行计划，并根据试运行结果进行修正。 7。1.9运行管理 7.1.9。1总体操作管理

(a) 信息系统用户是否制定与遵守运行管理的规则； (b) 操作顺序是否标准化，事故及故障对策是否明确； (c) 作业进度的决定是否考虑业务处理的优先级; (d) 操作是否按作业进程表及指导书进行； (e) 例外处理的操作是否按运行管理规则进行; (f) 操作员的交替是否按运行管理规则进行；

(g) 是否对作业进程表与操作事实记录的差异进行分析;

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

第 20 页

(i) 操作实施记录是否按照运行管理规则保管一定期限; (j) 是否记录事故及故障内容，并向信息系统运行负责人报告； (k) 是否找到事故及故障的原因，并采取措施防止再发生；

(l) 识别代码及口令的管理是否考虑防止不正当行为及机密保护对策； (m) 是否对用户进行了有关信息系统的安全教育及培训。 7。1。9。2软件管理

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

(b) 对软件的存取及控制、监视是否有防止不正当行为及机密保护对策； (c) 信息系统用户是否记录软件利用状况，并定期进行分析； (d) 软件备份的范围及方法是否按业务内容及处理状态来决定； (e) 软件的保管及废除有否防止不正当行为对策及机密保护对策； (f) 软件的拷贝有否防止不正当行为及机密保护对策； (g) 对软件有否故障对策； (h) 对软件版本如何管理。 7.1。9.3硬件管理

(a) 信息系统用户是否制定并遵守硬件管理的规则； (b) 对硬件是否设置了能够回避风险的环境； (c) 对硬件是否设置了能够应对风险的环境； (d) 是否定期对硬件进行维护； (e) 是否有硬件的故障对策；

(f) 是否对硬件的利用状况进行记录,并定期进行分析。 7.1。9。4建筑物及相关设备管理

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

(b) 建筑物及房间的进出管理是否有防止不正当行为的对策及机密保护的对策； (c) 对相关设备是否定期进行维护； (d) 相关设备是否有故障对策。 7.1.9.5组成管理

(a) 所有要管理的软件、硬件、网络的对象范围是否明确; (b) 软件、硬件及网络的组成，供应商的支持维护条件是否明确； (c) 引入或变更软件、硬件和网络后受到影响的范围是否明确;

第 21 页

(d) 引入或变更软件、硬件和网络是否按计划实施。 7。1.10文档编制

7。1。10。1是否遵守文档编制规范； 7.1.10.2是否制订文档计划； 7.1。10。3文档计划的执行情况；

7。1.10.4文档的种类、目的、制作方法等是否明确；

7.1。10。5文档是否得到信息系统部门及用户部门负责人的认可。 7.1。11文档管理

7。1。11.1是否制定和遵守文档管理规则；

7。1.11.2文档更新是否得到信息系统部门及用户负责人的认可; 7.1.11。3在系统需求更新时,文档内容是否进行更新，并留下更新记录； 7.1.11.4文档的拷贝及废除是否有对不正当行为的防范及机密保护的对策。 7。1。12进度计划

7。1.12。1是否按标准格式编写计划书; 7。1。12。2是否有时间、任务和结果形式； 7.1.12.3进度安排是否合理。 7.1.13进度控制

7.1.13。1承建方是否制订进度管理的方法、，是否得到计划、开发、运行及维护等各业务负责人的认可；

7.1。13.2计划、开发、运行及维护各业务负责人是否把握进度状况,是否按计划执行； 是否有进度延迟的对策；

7.1.13.3各业务结束时，是否按计划等实施状况进度分析与评价； 7.1。13.4评价的结果是否反映到下阶段工程的进度计划中； 7.1.13.5评价的结果是否反映对进度管理的方法与等的改进。 7。1。14进度评价

7。1.14.1检查在各业务结束时，是否按计划对实施状况进行分析与评价,评价的结果是否客观、真实，是否分析了影响进度的主要原因,是否提出了相应的应对措施，应对措施是否合理，能否实现等；

7。1。14。2检查评价的结果是否反映到下阶段工程的计划中，在下阶段的工程实施过程中是否按照相应的进度调整计划进行实施;

第 22 页

7.1。14.3对进度的评价是否反映对进度管理的方法与等的改进。 7。2软件监理技术要点 7.2.1系统规划

任务:确保新开发的信息系统是满足企业战略发展需要的，从技术、经济和操作的角度来说是可行的、恰当的，但不是不顾企业的实际需要而一味地追求新技术或高性能的硬件配置。

7.2。2系统需求分析

任务：保证需求达到如下原则：  一致性:所有需求必须是一致的；

 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能；  现实性：制定的需求应该是用现有的硬件技术和软件技术可以实现的；  有效性：必须证明需求是正确有效的,确实能解决用户面临的问题。 7.2。3系统设计 7。2.3.1总体设计要求

(a) 详细需求的描述



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

(b) 数据/信息流的设计

  

数据流和信息流的流动方向以及传输点； 数据流和信息流的流动频率以及流动时间； 将被格式化的数据流和信息流.

7。2.3.2详细设计要求

(a) 数据库设计



结构

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

对这些实体、实体属性和实体关系的静态和动态；  数据建模:将概念模型转换成数据模型；

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

备上;

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

数据

第 23 页

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

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

别，根据安全策略的定义决定用户对资源的存取权限。  实体—关系模型中的完整性约束

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

最大基数：在数据库中存在的一个实体所能产生的实例最大数目； 最小基数：在数据库中存在的一个实体所能产生的实例最小数目; 实体关键字：唯一标识实体的实例的属性； 关键字类型：定义实体关键字的属性的类型； 关键字的值:定义组成关键字的属性所允许的一些值.  属性完整性约束

属性类型：一个属性所允许的数据类型； 属性的值：对于一个属性所允许的一些值；

转换法则：定义一个属性的前一个值到后一个值的转换关系。  关系完整性约束

键的完整性：定义一个关系的候选键应唯一标识关系的一个元组； 实体完整性:包拯主键不能为空；

参照完整性：保证元组之间协同。当一个元组引用另一个元组的一个属性时（利用外键)，应保证这个属性在另一个元组中是存在的。  对象完整性约束

唯一标识码:每个对象都必须是唯一的，数据库系统能产生一个对象标识码,在对象的生命周期中唯一标识这个实体；

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

属性类型:对象的属性允许的类型； 属性的值:对象的属性所允许的一些值;

类型和继承：保证一个对象的子对象继承了它的所有属性。  对象关系完整性约束

参照完整性:一个对象要引用另一个对象，被应用的对象必须存在并且是正确的类型；

第 24 页

合成完整性：规定的合成关系中，对应对象的插入和删除的行为； 基数完整性：在一个关系中，特殊类型对象的最大和最少数目.

(b) 用户界面设计

     

屏幕的组织 标题设计 数据输入框设计 颜色设计 响应时间 提示和帮助的设计

(c) 模块详细设计

      

模块要求性强; 模块规模应适中；

深度、宽度、输入和输出都应适当; 模块的作用域应该在控制域之内; 力争降低模块接口的复杂度； 设计单入口单出口的模块； 模块功能可以预测.

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

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

件和系统软件可以互相交流。

7.2.4编码要求

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

7.2.4。1程序内部的文档

(a) 选取含义鲜明的名字，使它能正确地提示程序对象所代表的实体； (b) 正确的注解非常有助于对程序的理解； (c) 程序清单对程序的可读性有很大的影响。 7.2.4。2数据说明

(a) 数据说明的次序应该标准化;

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

第 25 页

(c) 如果设计时使用了一个复杂的数据结构，则应该用注解说明用这种程序设计语言实

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

7。2。4.3语句构造

(a) 不要为了节省空间而把多个语句写在同一行; (b) 尽量避免复杂的条件测试； (c) 尽量减少对“非”条件的测试； (d) 避免大量使用循环嵌套和条件嵌套；

(e) 利用括号使逻辑表达式和算术表达式清晰直观。 7.2。4.4输入输出

(a) 对所有输入数据进行校验; (b) 检查输入项重要组合的合法性； (c) 保持输入格式简单；

(d) 使用数据结束标记，不要要求用户指定数据的数目;

(e) 明确提交交互式输入的请求,详细说明可用的选择和边界数值； (f) 设计良好的输出表格； (g) 给所有输出数据加标志. 7。2.4。5效率

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

其次,效率是靠好设计来提高的；第三，程序的效率和程序的简单程度是一致的，包括程序运行的时间，存储器效率和输入输出效率。

7。2.4.6编码

(a) 程序的每个模块都只能有一个入口和一个出口,模块的长度建议在50—100个

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

7。2。4.7文档

(a) 高质量的文档是减少编码错误和提高以后可维护性的有利途径. (b) 提供程序主要组成部分和相互关系的图表；

(c) 在程序中利用各种注释阐明程序的特点、作用及不同的组成部分和逻辑关系； (d) 对于不同类型的变量、常量、程序段和模块等，使用有意义的名字可增强程序的可

阅读性；

(e) 有格式的书写程序可增强阅读性。

第 26 页

7.2。5测试要求 7.2.5。1单元测试 7.2。5。2集成测试 7。2.5。3验收测试 7。2。6运行要求

7.2.6.1系统输入:数据录入是整个信息系统运行的非常关键的一个环节，是以后报表生成和决策支持的基础数据有效性验证.

(a) 字段检验

 数据缺省或空值检验  字母或数字检验  范围检验  校验码检验  主文件参照  大小检验 

格式检验

(b) 记录检验

 合理性  大小 

顺序检验

(c) 批检验

 控制总量  批类型 

顺序检验

(d) 文件检验

 内部标签  版本号 

有效期

7.2。6。2错误报告

(a) 清晰和简洁 (b) 语言严谨中立

第 27 页

(c) 信息系统生命周期支持业务 7.2。7文档管理 7。2。7.1意义

(a) 文档可以作为开发人员在一定阶段内的工作成果和结束的标志，各阶段的人员通过

文档进行交接工作； (b) 文档可以作为管理依据； (c) 文档可用做未来项目的一种资源；

(d) 文档可以作为运行、维护和培训的参考依据； (e) 文档对保证软件质量起到重要作用。 7。2.7.2主要内容

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

开发进度月报；

(b) 需求分析:项目开发计划、系统需求说蜜柑内、数据要求说明、测试计划、用户手

册、开发进度月报;

(c) 设计：概要设计说明、详细设计说明、测试计划、用户手册、操作手册、开发进度

月报；

(d) 代码编写:用户手册、操作手册、开发进度月报; (e) 测试：测试分析报告、开发进度月报、项目开发总结； (f) 运行与维护：维护修改日志。 7。2.7。3质量要求

(a) 针对性 (b) 精确性 (c) 清晰性 (d) 完整性 (e) 灵活性 (f) 可追溯性

文档的版本管理是文档管理的一个必要方面。需求文档的每一版本必须被统一确定，并保证开发成员得到需要的当前版本.此外，在需求进行变更时，需要清楚地将变更以文档形式记录下来,并通知相关人员。 7。2.8进度管理

第 28 页

7。2。8。1进度计划要求

(a) GATT图 (b) 网络图 7。2。8.2进度控制要求

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

务活动的开始和结束时间及完成程度;

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

结合时间、开发内容、效率、消耗等评价项目进度状况,分析其中的问题; (c) 对下期工作做出安排，对一些已开始，但尚未结束的项目单元的剩余时间做估算，

分析调整进度的措施；

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

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

(a) 调整过程

 

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

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

在分析了对后续工作和总进度的影响以后，需要采取一定的调整措施时，应当首先确定进度可调整的范围，主要关键节点、后续工作的条件以及总进度允许变化的范围； 

采取进度调整措施，以后续工作和总进度的条件为依据，对原进度计划调整，以保证进度目标的实现； 

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

(b) 调整方法

 

调整任务之间的顺延关系 缩短某些任务的持续时间

7。2。9人员管理

职责权限要求：要遵循“职责分离”的原则。目的在于保证不同职责有不同的人承担，保证人员之间的工作可互相检查和监督。

业务分配要求：

第 29 页

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

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

 考察人员的接替过程对不可预测风险的防范情况. 7.2。10灾难对策 7.2。10.1灾难应急计划 7。2.10。2备份计划 7。2.10。3替代处理 7.2。10。4评价计划 7.2.11安全性

7。2。11。1资产安全性 7。2。11.2数据安全性

包括容错能力；已经存在或潜在的数据错误,以及这些错误的规模及数量。 7。2.11.3总体安全性

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

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

7。2。12。1软件可靠度表示在规定的运行环境和规定的时间内软件无故障运行的概率； 7。2。12.2软件故障强度,软件故障率的物理解释是单位时间内软件发生故障的概率; 7。2。12。3平均故障间隔时间是相邻两次故障间工作时间的数学期望；

7。2.12。4平均故障修复时间表示软件从发现故障到软件恢复规定功能所需的时间，即故障诊断、修复准备及修复实施时间之和. 7.2.13有效性 7。2。13.1评价过程

(a) 明确评价目标； (b) 评价费用的预算； (c) 明确性能指标； (d) 构建负荷模型； (e) 构建系统模型； (f) 进行实验； (g) 结果分析；

第 30 页

(h) 给出建议。 7。2.13。2性能指标

系统有效性的量度标准，反映了系统实现某些性能标准的数量特征 (a) 时间性指标：表述作为输入系统到系统输出用户所需结果的时间周期； (b) 吞吐率指标：系统生产力的度量标准，描述了在给定时间内系统处理的工作量; (c) 利用率指标：以系统资源处于忙状态的时间为度量标准;

(d) 可靠性指标：系统处理用户工作的可用性或处理过程失败或错误的概率. 7.2。13.3负荷模型

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

为了确定一个系统是否可以提高性能，需要对系统进行建模。建模过程包括识别系统单元、单元界面、系统运行方式、输入输出之间的功能关系等。 7.2.14综合评价 7。2。14.1评价过程

(a) 确定信息系统的主要目标 (b) 选择评价标准 (c) 确定评价数据来源 (d) 事先系统的价值 (e) 事后系统的价值 (f) 估计系统的影响 7.2。14.2评价内容

(a) 系统质量

       

响应时间 周转时间 系统可靠性 系统界面的友好程度 功能性 易用性

文档、帮助资料的质量 与其他系统的集成度

第 31 页

(b) 信息质量

         

真实性 精确性 完整性 非冗余性 时间性 关联性 综合性 精密度 简明 信息性

(c) 可用性感受

     

是否提高了用户的工作效率 是否改善了用户的工作表现 是否提高了用户的生产力 是否提高了工作效果

是否提高了用户对工作任务的理解 是否对他们的工作有帮助

(d) 易用性感受

    

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

用户是否能方便地利用信息系统完成他们的工作 用户与信息系统之间的交互是否清晰、易懂、顺畅、灵活 用户是否能利用信息系统快速地适应工作要求 用户是否认为信息系统的操作很容易

(e) 用户对计算机使用能力的判断 (f) 信息系统的使用情况 (g) 个人影响 (h) 信息系统满意度

 

与信息系统开发/维护人员的人际关系 对系统变更要求的处理方式

第 32 页

  信息的时间性

针对用户的信息系统技能培训  输出的相关性  输出的量  文档质量 

信息系统依赖性

组织影响 第 33 页(i)