IT项目监理细则(样本)

 

IT项目监理细则（样本）


第一章总则 3
第二章项目角色 3
一、业主方： 3
二、监理方： 3
三、开发方： 3
第三章项目内容 4
一、应用开发部分： 4
二、项目的总体测试： 4
三、系统硬件集成： 4
第四章前期监理 4
一、审核招标文件： 4
二、审核开发方提供的资料： 4
三、审核开发方提供的开发计划及时间表： 5
第五章过程文件 5
一、系统需求分析： 5
二、系统设计： 6
三、软件需求分析： 6
四、概要设计： 7
五、详细设计： 8
六、软件编码： 10
七、软件集成： 11
八、软件鉴定测试： 13
九、系统集成： 14
十、系统鉴定测试： 15
十一、总调试： 15
第六章后期监理 15
一、试运行： 15
二、问题和修改： 16
三、实施修改： 16
四、评审和通过： 16
五、培训计划的实施： 16
六、完工验收： 16


第一章总则
为更好地开展监理工作，保障XXX--XX-XX系统的有效实施，确立全面科学的监理标准，提高实际监理工作的可操作性和透明度，特制订本《监理细则》，供项目开发人员及现场人员参照执行。因本项目开发的特殊性及其监理非完全在现场的特点，在实际开发过程，建议采取较简化的方式进行，请各外包开发方参照本《监理细则》相关要求执行。

第二章项目角色
一、业主方：
1.
2. 代表：

开发业主方：浙江京安电子工程有限公司
二、监理方：
1. 监理方：广州ebridge.net
2. 代表：
3. 总监理工程师：楼新平
4. 现场监理组：
5. 技术专家组：

三、开发方：
1. 开发方：


2. 代表：
3. 项目经理：
4. 采购组组长：
5. 系统集成组组长：
6. 应用开发组组长：
7. 测试组组长：
8. 培训组组长：



第三章项目内容
一、应用开发部分：
1、应用软件
2、电子地图
3、项目建设需进行软件开发，并承担有关的安装、调试、技术支持、技术培训和维护、保修等工作。
。。。

二、项目的总体测试：

三、系统硬件集成：
服务器安装调试。


第四章前期监理
一、审核招标文件：
1. 系统需求；
2. 工作描述；
3. 投标者须知；
4. 产品或服务清单；
5. 合同条款；
6. 技术限制。

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


第五章过程文件
一、系统需求分析：
1. 开发方对系统的要求进行分析，以建立系统需求，系统需求应当说明：
(1) 系统的功能和性能；
(2) 安全、保密、人机工程、接口、操作和维护需求；
(3) 设计限制和鉴定的要求；
2. 对这些系统需求进行评价，使其包括下述准则：
(1) 可跟踪性；
(2) 与获取及系统要求的一致性；
(3) 可测试性；
(4) 设计、操作和维护的可行性；
3. 需求说明书基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(3) 定义
(4) 参考资料
(二) 任务概述
(1) 目标
(2) 用户的特点
(3) 假定与约束
(三) 需求规定
(1) 对功能的规定
(2) 对性能的规定
A. 精度
B. 时间特性要求
C. 灵活性
(3) 输入输出要求
(4) 数据管理能力要求
(5) 故障处理要求
(6) 其他专门要求
(四) 运行环境规定
(1) 设备
(2) 支持软件
(3) 接口
(4) 控制

二、系统设计：
1. 开发方应当建立一个高层的系统体系结构，在系统体系结构中体现系统的需求，该系统体系结构要表现出系统的内部结构以及硬件、软件和人工操作的配置；应当保证：
(1) 系统需求已完全分配给硬件配置项（HCI）、软件配置项（SCI）和人工操作；
(2) 分配给HCI、SCI和人工操作的系统体系结构和系统需求要写成文档；
2. 对HCI、SCI和人工操作的系统体系结构和系统需求进行评价，使其包括下述准则：
(1) 可跟踪性；
(2) 与系统需求的一致性；
(3) 设计和所用标准恰当；
(4) 操作和维护的可行性；

三、软件需求分析：
1. 开发方应当确定各种需求并将其写成文档，其中包括合同要求的质量特性规格说明（可操作性、可靠性、可用性、有效性、可维护性和可移植性）；该文档描述：
(1) 功能和能力规格说明，其中包括性能、物理特性、运行软件的环境条件；
(2) 用户文档；
(3) 安全规格说明，其中包括与操作和维护的方法、环境影响和人员伤害有关的说明；
(4) 保密规格说明，其中包括对敏感性信息或资料的危害有关的说明；
(5) 人机工程和人－机规格说明，其中包括与人工操作、人机对话、对人员的限制有关的规格说明，以及那些对于人的错误和能力很敏感的、需要人集中注意力的领域的说明；
(6) 处理器、存储设备或数据通道所用的硬件处理和资源储备的规格说明；
(7) 数据定义和数据库的需求；
(8) 已交付软件在操作和维护现场上的安装和验收的需要；
(9) 用户操作和执行的需求；
(10) 用户维护需求；
2. 开发方应当确定SCI的外部接口的需求并将其写成文档；
3. 开发方应当对SCI的鉴定要求写成文档；
4. 开发方应当对需求作出评价，使其包括下面指出的准则：
(1) 对系统需求和系统设计的可跟踪性；
(2) 与系统需求的外部一致性；
(3) 各个软件需求之间的内部一致性；
(4) 软件需求的可测性；
(5) 软件需求的测试范围；
(6) 软件设计、操作和维护的可行性；
5. 开发方应当依据合同要求进行评审，以决定软件需求的完善和恰当；当评审完成时，就应当建立SCI需求的基线。

四、概要设计：
1. 开发方应当把SCI的工程需求转变为一个体系结构，该体系结构应描述它的顶层结构和定义它的主要部分；它应当保证此项工程和SCI的鉴定要求已完全分配给了各个部分，并对其进行了细化以便进行详细设计；应当建立SCI体系结构的文档；
2. 开发方应当为SCI外部接口的设计、SCI的各软件部分之间的设计建立一个顶层的设计文档；
3. 开发方应当为数据库建立一个顶层的设计文档；
4. 开发方应当评价SCI的体系结构、接口和数据库的设计，使其包括下面指出各项：
(1) 对SCI需求的可跟踪性；
(2) 与SCI需求的外部一致性；
(3) 各部分需求之间的内部一致性；
(4) 所使用的设计方法和标准是否恰当；
(5) 详细设计、操作和维护的可行性；
5. 开发方应当依据合同要求进行评审，以决定分配给各部分的需求和SCI体系结构设计方法的完善和恰当。
6. 概要设计说明书基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(3) 定义
(4) 参考资料
(二) 总体设计
(1) 需求规定
(2) 运行环境
(3) 基本设计概念和处理流程
(4) 结构
(5) 功能需求与程序的关系
(6) 人工处理过程
(7) 尚未解决的问题
(三) 接口设计
(1) 用户接口
(2) 外部接口
(3) 内部接口
(四) 运行设计
(1) 运行模块组合
(2) 运行控制
(3) 运行时间
(五) 系统数据结构设计
(1) 逻辑结构设计要点
(2) 物理结构设计要点
(3) 数据结构与程序的关系
(六) 系统出错处理设计
(1) 出错信息
(2) 补救措施
(3) 系统维护设计

五、详细设计：
1. 开发方应当详细设计SCI的每个软部件；应当尽量地将各个软部件详细划分为含有软件单元的较低的层次，以便进行编码、编译和测试；应当保证该软件的需求已完全分配给从软部件到软件单元的整个软件；应当把该详细设计写成文档；
2. 开发方应当写出与SCI的外部接口、各软部件之间和各软件单元之间的详细设计文档；接口的详细设计应当足够详细以便于编码；
3. 开发方应当写出数据库的详细设计文档；
4. 开发方最好写出软件用户手册的最初版本；
5. 开发方应当为测试软件单元规定测试要求和时间进度，并将其写成文档；测试要求中最好包括在软件需求限定上的重点软件单元；
6. 开发方应当为软件的集成规定测试要求和时间进度，并将其写成文档；
7. 开发方应当评价软件的详细设计和测试要求，使其包括下面的准则：
(1) 对SCI需求的可跟踪性；
(2) 与体系结构设计的外部一致性；
(3) 各部件和单元的需求之间的内部一致性；
(4) 所使用的设计方法和标准是否恰当；
(5) 详细设计、操作和维护的可行性；
8. 开发方应当依据合同要求进行评审，以决定分配给各个部分和单元的需求以及SCI详细设计方法是否完善和恰当。
9. 详细设计说明书基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(3) 定义
(4) 参考资料：
(二) 程序系统的组织结构
(三) 程序1(标识符)设计说明
(1) 程序描述
(2) 功能
(3) 性能
(4) 输入项
(5) 输出项
(6) 算法
(7) 流程逻辑
(8) 接口
(9) 存储分配
(10) 注释设计
(11) 限制条件
(12) 测试计划
(13) 尚未解决定问题
(四) 程序2(标识符)设计说明
……
10. 用户手册基本格式：
(一) 引言
(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) 软件的结构
(2) 程序表
(3) 文卷表
(三) 安装与初始化
(四) 运行说明
(1) 运行表
(2) 运行步骤
(3) 运行1(标识符)说明
A. 运行控制
B. 操作信息
C. 输入－输出文卷
D. 输出文段
E. 输出文段的复制
F. 启动恢复过程
(4) 运行2(标识符)说明
……
(五) 非常规过程
(六) 远程操作

六、软件编码：
1. 开发方应当进行下述开发并建立文档：
(1) 开发每个软件单元和数据库；
(2) 为测试每个软件单元和数据库而开发的测试过程和数据；
(3) 为进行软件集成而开发的测试过程和数据；
2. 开发方应当测试每个软件单元和数据库，以保证它们符合需求；测试结果应当写成文档；
3. 必要时，开发方应当更新软件的用户手册；
4. 开发方应当评价软件的代码和测试结果，并使其包括下面的准则：
(1) 对SCI需求和设计的可跟踪性；
(2) 与SCI需求和设计的外部一致性；
(3) 各单元需求之间的内部一致性；
(4) 各单元的测试范围；
(5) 使用的编码方法和标准是否恰当；
(6) 集成、操作和维护的可行性；
5. 数据库设计说明书基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(3) 定义
(4) 参考资料：
(二) 外部设计
(1) 标识符和状态
(2) 使用它的程序
(3) 约定
(4) 专门指导
(5) 支持软件
(三) 结构设计
(1) 概念结构设计
(2) 逻辑结构设计
(3) 物理结构设计
(四) 运用设计
(1) 数据字典设计
(2) 安全保密设计

七、软件集成：
1. 开发方应当制订计划把各个软件单元和软部件集成为SCI；该计划应当包括测试要求、步骤、数据、责任和时间表；该集成计划应当写成文档；
2. 在依据集成计划开发集合体时，开发方应当集成软件的单元、部件和进行测试；应当保证每个集合体都能满足SCI的需求，并且在集成活动结束时形成完全集成的SCI；集成和测试的结果应当写成文档；
3. 必要时，开发方应当更新用户手册；
4. 为了进行软件的鉴定测试，开发方应当为每个SCI开发写出一个完整的测试集、测试用例（输入、输出、测试准则）和测试步骤；开发方应当保证集成后的SCI可以进行软件鉴定测试；
5. 开发方应当对集成计划、设计、代码、测试、测试结果和用户手册进行评价，使其包括下面的准则：
(1) 对SCI需求的可跟踪性；
(2) 与SCI需求的外部一致性；
(3) 内部一致性；
(4) SCI需求的测试范围；
(5) 使用的测试方法和标准是否恰当；
(6) 是否符合预期的结果；
(7) 鉴定测试、操作和维护的可行性；
6. 开发方应当依据合同要求进行评审，以确定测试过程的完善和恰当，并确定已经做好软件鉴定测试的准备；
7. 在模块开发过程中，开发方应当编制《模块开发卷宗》，每完成一个模块或一组密切相关的模块的复审时编写一份，，并把所有的模块开发卷宗汇集在一起；目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息；基本格式如下：
(一) 标题
(二) 模块开发情况表
(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) 项目负责人批准日期/签字
(三) 功能说明
(四) 设计说明
(五) 源代码清单
(六) 测试说明
(七) 复审的结论

八、软件鉴定测试：
1. 开发方应当依据为SCI确定的鉴定要求进行鉴定测试；应当保证对每项要求进行符合测试；应将鉴定测试结果写成文档；
2. 必要时，开发方应当更新用户手册；
3. 开发方应当对设计、代码、测试、测试结果和用户手册进行评价，使其包括下面的准则：
(8) 对SCI和系统需求的可跟踪性；
(9) 与SCI和系统需求的外部一致性；
(10) 内部一致性；
(11) SCI和系统需求的测试范围；
(12) 是否符合预期的结果；
(13) 操作和维护的可行性；
4. 开发方应当依据合同要求对SCI的功能性配置审计（FCA）和物理配置审计(PCA)；在FCA时，应当保证SCI的测试成功并符合需求，而且用户手册中充分描述SCI的操作和支持；在PCA时，应当保证SCI的设计和源码完整并正确，反映了SCI的新技术；FCA和PCA的结果应当写成文档；如果同时开发硬件和软件，FCA和PCA可以推迟到系统鉴定测试时进行；
5. 在FCA和PCA成功地完成之后，开发方应当：
(1) 为系统集成、系统鉴定测试或适当时的安装和验收，更新和准备可交付的软件；
(2) 为SCI的设计和编码建立一个基线；
6. 测试计划基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(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(标识符)
……
(四) 对软件功能的结论
(1) 功能1(标识符)
A. 能力
B. 限制

(2) 功能2(标识符)
……
(五) 分析摘要
(1) 能力
(2) 缺陷和限制
(3) 建议
(4) 评价
(六) 测试资源消耗

九、系统集成：
1. SCI应当与HCI、人工操作和其他必要的系统一起集成到系统中去；应当对照它们的需求进行测试；应当将集成和测试的结果写成文档；
2. 应当为系统的每项已确定的需求进行系统鉴定测试开发一个完整的测试集、测试用例（输入、输出、测试准则）和测试步骤，并将其写成文档；开发方应当保证集成的系统已做好系统鉴定测试的准备；
3. 应当对集成的系统进行评价以使其包括下述准则：
(1) 系统需求的测试范围；
(2) 所使用的测试方法和标准是否恰当；
(3) 是否符合预期结果；
(4) 鉴定测试、操作和维护的可行性。
十、系统鉴定测试：
1. 应当依据为系统建立的鉴定要求进行系统鉴定测试；应当保证每项系统需求都进行符合性测试，而且系统已做好交付准备；应当把鉴定测试的结果写成文档；
2. 应当对系统进行评价以使其包括下述准则：
(1) 系统需求的测试范围；
(2) 所使用的测试方法和标准是否恰当；
(3) 是否符合预期结果；
(4) 鉴定测试、操作和维护的可行性。
3. 本项需求不适用于已经进行过FCA、PCA的SCI；SCI的FCA和PCA参照“八、软件鉴定测试”。

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

第六章后期监理
一、试运行：
1. 开发方应当为试运行期间对系统的维护制订计划和步骤，并将其写成文档；
2. 开发方应当确定接受、跟踪来自用户的问题报告和修改请求的步骤和向用户反馈的步骤；问题应当记录下来并进入改正过程。

二、问题和修改：
1. 开发方应当对问题反复进行验证；
2. 开发方应当对问题报告和修改请求，对机构、现有系统和接口系统的影响进行下述分析：
(1) 类型——改正、改进、预防或对新环境的适应；
(2) 范围——修改的规模、所涉及的成本、修改的时间；
(3) 关键性——对性能、安全、保密或风险的影响；
3. 开发方应当在分析的基础上，选择修改的实施方案；
4. 开发方应当将问题报告、修改请求、分析结果和实施方案写成文档；
5. 实施方案应当得到业主方的认可方可实施。

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

四、评审和通过：
1. 开发方应当会同业主方和监理方一起，对经过修改的系统进行评审，以决定经过修改的系统的整体性；
2. 评审方式参照“系统鉴定测试”；
3. 业主方和监理方对修改确认满意时，经过修改的系统获得通过。

五、培训计划的实施：
1. 开发方应当制订完整的、有效的培训计划，为业主方用户提供必要的培训；
2. 开发方应当编写培训手册，包括提供在培训时所需要的资料；
3. 开发方应当保证为用户培训所配备的导师都是专业且是具有经验的，能使培训成果更为有效；
4. 培训计划应当全部、无保留地得到实施，并做好和保存培训记录；

六、完工验收：
试运行结束，开发方应当达到下述各项要求，方可视为已满足合同技术指标，可以通过完工验收：
1. 需求验证：
(1) 系统需求（包括接口和鉴定）的完善性、正确性、可行性和可测性；
(2) 为达到最佳设计，系统需求已适当地分配给HCI、SCI和人工操作；
(3) 软件需求（包括接口和鉴定）的完善性、正确性、可行性和可测性，它们已准确地反映了系统需求；
(4) 与关键性、安全性、保密性有关的软件已达到用户需求
2. 设计验证：
(1) 设计方法是否与需求一致，是否根据需求所选择；
(2) 设计中的事件次序、输入、输出、接口、逻辑流程、计时分配和规模预算、出错定义、错误的隔离和恢复等措施是否完备有效；
(3) 关键性、安全性和保密性的需求是否实现；
3. 代码验证：
(1) 程序员的文件是否已全部提交；
(2) 关键的代码是否符合为跟踪设计和需求、可测性和与需求的一致性及编码的标准；
(3) 为适当的事件序列、一致的接口、正确的数据和控制流、完整性、适当分配的计时和规模预算、出错定义、错误的隔离和恢复而分析代码；
(4) 对照设计和需求验证所选择的代码；
(5) 验证关键性、安全性和保密性需求的代码是否实现；
4. 集成验证：
(1) 验证SCI的每个部件和单元已经完全和正确地集成进一个SCI中去；
(2) 验证该系统的各个部件（HCI、SCI、人工操作部分）已经完全正确地集成进该系统中去；
(3) 集成任务已经按照集成计划执行；
5. 文档验证：
(1) 合同要求的文档是否已经全部提交；
(2) 提交的文档是否已同时提交电子版；
(3) 文档是否恰当、完善和具有一致性；
6. 售后服务：
(1) 是否已制订计划，保证在完工后仍对系统提供合适的服务和支持（包括问题和修改、定期回访用户、软件升级承诺等）；
(2) 是否按照计划对用户进行了有效的培训，为用户提供了满足项目需求所需要的技术和知识；
7. 开发方提交《项目开发总结报告》，报告的基本格式：
(一) 引言
(1) 编写目的
(2) 背景
(3) 定义
(4) 参考资料：
(二) 实际开发成果
(1) 产品
(2) 主要功能和性能
(3) 基本流程
(4) 进度
(5) 费用
(三) 开发工作评价
(1) 对生产效率的评价
(2) 对产品质量的评价
(3) 对技术方法的评价
(4) 出错原因的分析
(四) 经验与教训

<等续>