IT项目监理细则样本

1、第一章 总 则 为更好地开展监理工作，保障 XXX-XX-XX 系统的有效实施，确立全 面科学的监理标准， 提高实际监理工作的可操作性和透明度， 特制订 本监理细则，供项目开发人员及现场人员参照执行。因本项目开 发的特殊性及其监理非完全在现场的特点， 在实际开发过程， 建议采 取较简化的方式进行，请各外包开发方参照本监理细则相关要求 执行。第二章 项目角色一、业主方：1.2. 代 表：开发业主方：浙江京安电子工程有限公司二、监理方：1. 监理方：广州 2. 代 表：3. 总监理工程师：楼新平4. 现场监理组：5. 技术专家组：三、开发方：1. 开发方：2. 代 表：3. 项目经理：4. 采购组

2、组长：5. 系统集成组组长：6. 应用开发组组长：7. 测试组组长：8. 培训组组长：第三章 项目内容一、应用开发部分：1、应用软件2、电子地图3、项目建设需进行软件开发，并承担有关的安装、调试、技术支持、 技术培训和维护、保修等工作。项目的总体测试：三、 系统硬件集成：服务器安装调试。第四章 前期监理一、审核招标文件：1. 系统需求；2. 工作描述；3. 投标者须知；4. 产品或服务清单；5. 合同条款；6. 技术限制。二、审核开发方提供的资料：1. 为执行工程而建立的组织机构；2. 外包开发的关键工作人员的身份和职务；3. 包括外部机构在内的每个机构的权利与责任。三、审核开发方提供的开发计

3、划及时间表：1. 开发的顺序；2. 完成合同义务的合理日期；3. 开发环境，包括测试环境、库、设备、仪器以及工程标准、步骤 和工具；4. 工作细目的结构，包括可交付的产品，与任务有关的经费预算、 人员、物理资源、软件的规模以及时间进度；5. 系统的质量需求管理；6. 系统安全和保密的关键需求管理；7. 业主方和监理方的介入，即按合同要求进行的评审、非正式的会面、报告、修改和变更的实施、批准、验收、对设施的使用等；8. 如何验证和确认；9. 质量保证；10. 风险管理，包括对项目的潜在技术、成本和进度等领域的管理；11. 保密方针，及保密所要求的批准、证书、专有权等；12. 制定计划、跟踪和报告

4、的方法；第五章 过程文件一、 系统需求分析：1. 开发方对系统的要求进行分析，以建立系统需求，系统需求应当 说明：(1) 系统的功能和性能；(2) 安全、保密、人机工程、接口、操作和维护需求；(3) 设计限制和鉴定的要求；2. 对这些系统需求进行评价，使其包括下述准则：(1) 可跟踪性；(2) 与获取及系统要求的一致性；(3) 可测试性；(4) 设计、操作和维护的可行性；3. 需求说明书基本格式：( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料( 二 ) 任务概述(1) 目标(2) 用户的特点(3) 假定与约束( 三 ) 需求规定(1) 对功能的规定(2) 对性能的规定A

5、. 精度B. 时间特性要求C. 灵活性(3) 输入输出要求(4) 数据管理能力要求(5) 故障处理要求(6) 其他专门要求( 四 ) 运行环境规定(1) 设备(2) 支持软件(3) 接口(4) 控制二、系统设计：1. 开发方应当建立一个高层的系统体系结构，在系统体系结构中体 现系统的需求，该系统体系结构要表现出系统的内部结构以及硬件、 软件和人工操作的配置；应当保证：(1) 系统需求已完全分配给硬件配置项(HCI)、软件配置项(SCI)和人工操作；(2) 分配给 HCI、 SCI 和人工操作的系统体系结构和系统需求要写成文档；2. 对 HCI、 SCI 和人工操作的系统体系结构和系统需求进行评

6、价， 使 其包括下述准则：(1) 可跟踪性；(2) 与系统需求的一致性；(3) 设计和所用标准恰当；(4) 操作和维护的可行性；三、软件需求分析：1. 开发方应当确定各种需求并将其写成文档，其中包括合同要求的 质量特性规格说明(可操作性、可靠性、可用性、有效性、可维护性 和可移植性)；该文档描述：(1) 功能和能力规格说明，其中包括性能、物理特性、运行软件的环 境条件；(2) 用户文档；(3) 安全规格说明， 其中包括与操作和维护的方法、 环境影响和人员 伤害有关的说明；(4) 保密规格说明，其中包括对敏感性信息或资料的危害有关的说 明；(5) 人机工程和人机规格说明，其中包括与人工操作、人机

7、对话、 对人员的限制有关的规格说明， 以及那些对于人的错误和能力很敏感 的、需要人集中注意力的领域的说明；(6) 处理器、存储设备或数据通道所用的硬件处理和资源储备的规格 说明；(7) 数据定义和数据库的需求；(8) 已交付软件在操作和维护现场上的安装和验收的需要；(9) 用户操作和执行的需求；(10) 用户维护需求；2. 开发方应当确定 SCI 的外部接口的需求并将其写成文档；3. 开发方应当对 SCI 的鉴定要求写成文档；4. 开发方应当对需求作出评价，使其包括下面指出的准则：(1) 对系统需求和系统设计的可跟踪性；(2) 与系统需求的外部一致性；(3) 各个软件需求之间的内部一致性；(4

8、) 软件需求的可测性；(5) 软件需求的测试范围；(6) 软件设计、操作和维护的可行性；5. 开发方应当依据合同要求进行评审，以决定软件需求的完善和恰 当；当评审完成时，就应当建立 SCI 需求的基线。四、概要设计：1. 开发方应当把 SCI 的工程需求转变为一个体系结构，该体系结构 应描述它的顶层结构和定义它的主要部分；它应当保证此项工程和SCI的鉴定要求已完全分配给了各个部分，并对其进行了细化以便进 行详细设计；应当建立 SCI 体系结构的文档；2. 开发方应当为 SCI 外部接口的设计、 SCI 的各软件部分之间的设 计建立一个顶层的设计文档；3. 开发方应当为数据库建立一个顶层的设计文

9、档；4. 开发方应当评价 SCI 的体系结构、接口和数据库的设计，使其包 括下面指出各项：(1) 对 SCI 需求的可跟踪性；(2) 与 SCI 需求的外部一致性；(3) 各部分需求之间的内部一致性；(4) 所使用的设计方法和标准是否恰当；(5) 详细设计、操作和维护的可行性；5. 开发方应当依据合同要求进行评审，以决定分配给各部分的需求和 SCI 体系结构设计方法的完善和恰当。6. 概要设计说明书基本格式：( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料( 二) 总体设计(1) 需求规定(2) 运行环境(3) 基本设计概念和处理流程(4) 结构(5) 功能需求与程序的关

10、系(6) 人工处理过程(7) 尚未解决的问题( 三) 接口设计(1) 用户接口(2) 外部接口(3) 内部接口( 四) 运行设计(1) 运行模块组合(2) 运行控制(3) 运行时间( 五 ) 系统数据结构设计(1) 逻辑结构设计要点(2) 物理结构设计要点(3) 数据结构与程序的关系( 六 ) 系统出错处理设计(1) 出错信息(2) 补救措施(3) 系统维护设计五、详细设计：1. 开发方应当详细设计 SCI 的每个软部件；应当尽量地将各个软部 件详细划分为含有软件单元的较低的层次， 以便进行编码、 编译和测 试；应当保证该软件的需求已完全分配给从软部件到软件单元的整个 软件；应当把该详细设计写

11、成文档；2. 开发方应当写出与 SCI 的外部接口、各软部件之间和各软件单元 之间的详细设计文档；接口的详细设计应当足够详细以便于编码；3. 开发方应当写出数据库的详细设计文档；4. 开发方最好写出软件用户手册的最初版本；5. 开发方应当为测试软件单元规定测试要求和时间进度，并将其写 成文档；测试要求中最好包括在软件需求限定上的重点软件单元；6. 开发方应当为软件的集成规定测试要求和时间进度，并将其写成 文档；7. 开发方应当评价软件的详细设计和测试要求，使其包括下面的准则：(1) 对 SCI 需求的可跟踪性；(2) 与体系结构设计的外部一致性；(3) 各部件和单元的需求之间的内部一致性；(4

12、) 所使用的设计方法和标准是否恰当；(5) 详细设计、操作和维护的可行性；8. 开发方应当依据合同要求进行评审，以决定分配给各个部分和单元的需求以及 SCI 详细设计方法是否完善和恰当。9. 详细设计说明书基本格式：( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料：( 二 ) 程序系统的组织结构(三) 程序 1(标识符 )设计说明(1) 程序描述(2) 功能(3) 性能(4) 输入项(5) 输出项(6) 算法(7) 流程逻辑(8) 接口(9) 存储分配(10) 注释设计(11) 限制条件(12) 测试计划(13) 尚未解决定问题(四) 程序 2(标识符 )设计说明10.

13、用户手册基本格式： ( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料：( 二 ) 用途(1) 功能(2) 性能A. 精度B. 时间特性C. 灵活性(3) 安全保密( 三 ) 运行环境(1) 硬设备(2) 支持软件(3) 数据结构( 四) 使用过程(1) 安装与初始化(2) 输入A. 输入数据的现实背景B. 输入格式C. 输入举例(3) 输出A. 输出数据的现实背景B. 输出格式C. 输出举例(4) 文卷查询(5) 出错处理与恢复(6) 终端操作11. 操作手册基本格式：( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料：( 二 ) 软件概述(1) 软件

14、的结构(2) 程序表(3) 文卷表( 三) 安装与初始化( 四) 运行说明(1) 运行表(2) 运行步骤(3) 运行 1(标识符 )说明A. 运行控制B. 操作信息C. 输入输出文卷D. 输出文段E. 输出文段的复制F. 启动恢复过程(4) 运行 2(标识符 )说明 ( 五) 非常规过程( 六 ) 远程操作六、软件编码：1. 开发方应当进行下述开发并建立文档：(1) 开发每个软件单元和数据库；(2) 为测试每个软件单元和数据库而开发的测试过程和数据；(3) 为进行软件集成而开发的测试过程和数据；2. 开发方应当测试每个软件单元和数据库，以保证它们符合需求； 测试结果应当写成文档；3. 必要时，

15、开发方应当更新软件的用户手册；4. 开发方应当评价软件的代码和测试结果， 并使其包括下面的准则：(1) 对 SCI 需求和设计的可跟踪性；(2) 与 SCI 需求和设计的外部一致性；(3) 各单元需求之间的内部一致性；(4) 各单元的测试范围；(5) 使用的编码方法和标准是否恰当；(6) 集成、操作和维护的可行性；5. 数据库设计说明书基本格式：（ 一） 引言(1)编写目的(2)背景(3)定义(4)参考资料：(二)外部设计(1)标识符和状态(2)使用它的程序(3)约定(4)专门指导L . r.r-亠广.trt.(5)支持软件(三)结构设计(1)概念结构设计(2)逻辑结构设计(3)物理结构设计(

16、四)运用设计(1)数据字典设计(2)安全保密设计七、软件集成：1. 开发方应当制订计划把各个软件单元和软部件集成为SCI;该计划应当包括测试要求、步骤、数据、责任和时间表；该集成计划应当写成文档；2. 在依据集成计划开发集合体时，开发方应当集成软件的单元、部 件和进行测试； 应当保证每个集合体都能满足 SCI 的需求，并且在集 成活动结束时形成完全集成的SCI;集成和测试的结果应当写成文档；3. 必要时，开发方应当更新用户手册；4. 为了进行软件的鉴定测试，开发方应当为每个 SCI 开发写出一个 完整的测试集、测试用例(输入、输出、测试准则)和测试步骤；开发方应当保证集成后的SCI可以进行软件

17、鉴定测试；5. 开发方应当对集成计划、设计、代码、测试、测试结果和用户手 册进行评价，使其包括下面的准则：(1) 对 SCI 需求的可跟踪性；(2) 与 SCI 需求的外部一致性；(3) 内部一致性；(4) SCI 需求的测试范围；(5) 使用的测试方法和标准是否恰当；(6) 是否符合预期的结果；(7) 鉴定测试、操作和维护的可行性；6. 开发方应当依据合同要求进行评审，以确定测试过程的完善和恰当，并确定已经做好软件鉴定测试的准备；7. 在模块开发过程中，开发方应当编制模块开发卷宗 ，每完成一 个模块或一组密切相关的模块的复审时编写一份， ，并把所有的模块 开发卷宗汇集在一起；目的是记录和汇总

18、低层次开发的进度和结果， 以便于对整个模块开发工作的管理和复审， 并为将来的维护提供非常 有用的技术信息；基本格式如下：( 一 ) 标题( 二 ) 模块开发情况表(1) 模块标识符(2) 模块的描述性名称(3) 代码设计A. 计划开始日期B. 实际开始日期C. 计划完成日期D. 实际完成日期(4) 模块测试A. 计划开始日期B. 实际开始日期C. 计划完成日期D. 实际完成日期(5) 组装测试A. 计划开始日期B. 实际开始日期C. 计划完成日期D. 实际完成日期(6) 代码复查日期 / 签字(7) 源代码行数A. 预计B. 实际(8) 目标模块大小A. 预计B. 实际(9) 模块标识符(10

19、) 项目负责人批准日期 / 签字( 三) 功能说明( 四) 设计说明( 五) 源代码清单( 六 ) 测试说明( 七) 复审的结论八、软件鉴定测试：1. 开发方应当依据为 SCI 确定的鉴定要求进行鉴定测试；应当保证 对每项要求进行符合测试；应将鉴定测试结果写成文档；2. 必要时，开发方应当更新用户手册；3. 开发方应当对设计、代码、测试、测试结果和用户手册进行评价， 使其包括下面的准则：(8) 对 SCI 和系统需求的可跟踪性；(9) 与 SCI 和系统需求的外部一致性；(10) 内部一致性；(11) SCI 和系统需求的测试范围；(12) 是否符合预期的结果；(13) 操作和维护的可行性；4

20、. 开发方应当依据合同要求对SCI的功能性配置审计(FCA和物理配置审计(PCA);在FCA时，应当保证SCI的测试成功并符合需求， 而且用户手册中充分描述 SCI的操作和支持；在PCA时，应当保证 SCI的设计和源码完整并正确，反映了 SCI的新技术；FCA和PCA的 结果应当写成文档；如果同时开发硬件和软件，FCA和PCA可以推迟到系统鉴定测试时进行；5. 在FCA和PCA成功地完成之后，开发方应当：(1) 为系统集成、系统鉴定测试或适当时的安装和验收， 更新和准备可交付的软件；(2) 为 SCI 的设计和编码建立一个基线；6. 测试计划基本格式：( 一 ) 引言(1) 编写目的(2) 背

21、景(3) 定义(4) 参考资料：( 二 ) 计划(1) 软件说明(2) 测试内容(3) 测试 1(标识符 )A. 进度安排B. 条件C. 测试资料D. 测试培训(4) 测试 2(标识符 ) ( 三) 测试设计说明(1) 测试 1(标识符 ) A. 控制B. 输入C. 输出D. 过程(2) 测试 2(标识符 ) ( 四) 评价准则(1) 范围(2) 数据整理(3) 尺度7. 测试分析报告基本格式：( 一) 引言(1) 编写目的(2) 背景(3) 定义(4) 参考资料：( 二) 测试概要( 三) 测试结果及发现(1) 测试 1(标识符 )(2) 测试 2(标识符 ) ( 四 ) 对软件功能的结论(

22、1) 功能 1(标识符 )A. 能力B. 限制(2) 功能 2(标识符 ) ( 五 ) 分析摘要(1) 能力(2) 缺陷和限制(3) 建议(4) 评价( 六) 测试资源消耗九、系统集成：1. SCI应当与HCI、人工操作和其他必要的系统一起集成到系统中去；应当对照它们的需求进行测试；应当将集成和测试的结果写成文档；2. 应当为系统的每项已确定的需求进行系统鉴定测试开发一个完整 的测试集、测试用例(输入、输出、测试准则)和测试步骤，并将其 写成文档；开发方应当保证集成的系统已做好系统鉴定测试的准备；3. 应当对集成的系统进行评价以使其包括下述准则：(1) 系统需求的测试范围；(2) 所使用的测试

23、方法和标准是否恰当；(3) 是否符合预期结果；(4) 鉴定测试、操作和维护的可行性。十、 系统鉴定测试：1. 应当依据为系统建立的鉴定要求进行系统鉴定测试；应当保证每 项系统需求都进行符合性测试， 而且系统已做好交付准备； 应当把鉴 定测试的结果写成文档；2. 应当对系统进行评价以使其包括下述准则：(1) 系统需求的测试范围；(2) 所使用的测试方法和标准是否恰当；(3) 是否符合预期结果；(4) 鉴定测试、操作和维护的可行性。3. 本项需求不适用于已经进行过 FCAPCA的SCI; SCI的FCA和PCA十一、 总调试：1. 开发方应当制定一个按合同中指明的、在目标环境中安装软件的 计划；应

24、当指出与软件的安装有关的必要的资源和信息并保证提供； 开发方应当以适当的方式帮助业主方得到与系统建立活动有关的信 息；当所安装的软件替代了现有的系统时， 开发方应当支持合同所要 求的并行运行的活动；应当将安装情况写成文档；2. 开发方应当依据安装计划安装软件；应当保证该软件和数据库能 按照合同的规定初始化、 执行和终止； 应当将安装情况及其结果写成 文档；3. 开发方应当支持业主方和监理方对软件（或系统）的总调试评审和测试；总调试评审和测试应当考虑FCA PCA软件鉴定测试和系统鉴定测试的结果；应当把评审和测试的结果写成文档；4. 开发方应当按照合同的规定完成有关的文档和编码并交付给业主方；5

25、. 开发方应当按照合同的规定向业主方提供初始的和继续的培训与 支持；第六章 后期监理一、试运行：1. 开发方应当为试运行期间对系统的维护制订计划和步骤，并将其写成文档；2. 开发方应当确定接受、跟踪来自用户的问题报告和修改请求的步 骤和向用户反馈的步骤；问题应当记录下来并进入改正过程。二、问题和修改：1. 开发方应当对问题反复进行验证；2. 开发方应当对问题报告和修改请求，对机构、现有系统和接口系 统的影响进行下述分析：(1) 类型改正、改进、预防或对新环境的适应；(2) 范围修改的规模、所涉及的成本、修改的时间；(3) 关键性对性能、安全、保密或风险的影响；3. 开发方应当在分析的基础上，选

26、择修改的实施方案；4. 开发方应当将问题报告、修改请求、分析结果和实施方案写成文 档；5. 实施方案应当得到业主方的认可方可实施。三、实施修改：1. 开发方应当进行详细的分析并决定哪些文档、代码单元和版本需 要修改；应当把这种分析和决定写成文档；2. 开发方应当按照开发过程来实施修改；开发过程的需求应当作如 下补充：(1) 为测试和评价系统的已修改部分和未修改部分 (单元、部件和配 置项)，应当定义测试和评价准则，并将其写成文档；(2) 应当保证初始的、 未经修改的需求不受影响， 而新修改过的需求 得到完善、正确地实现；测试结果应当写成文档。四、评审和通过：1. 开发方应当会同业主方和监理方一

27、起，对经过修改的系统进行评 审，以决定经过修改的系统的整体性；2. 评审方式参照“系统鉴定测试” ；3. 业主方和监理方对修改确认满意时，经过修改的系统获得通过。五、培训计划的实施：1. 开发方应当制订完整的、有效的培训计划，为业主方用户提供必 要的培训；2. 开发方应当编写培训手册，包括提供在培训时所需要的资料；3. 开发方应当保证为用户培训所配备的导师都是专业且是具有经验 的，能使培训成果更为有效；4. 培训计划应当全部、 无保留地得到实施， 并做好和保存培训记录；六、完工验收：试运行结束， 开发方应当达到下述各项要求， 方可视为已满足合同技 术指标，可以通过完工验收：1. 需求验证：(1) 系统需求(包括接口和