I T项目监理细则样本集团标准化办公室：[VV986T-J682P28-JP266L8-68PNN]第一章总则为更好地开展监理工作，保障XXX--XX-XX系统的有效实施，确立全面科学的监理标准，提高实际监理工作的可操作性和透明度，特制订本《监理细则》，供项目开发人员及现场人员参照执行。

因本项目开发的特殊性及其监理非完全在现场的特点，在实际开发过程，建议采取较简化的方式进行，请各外包开发方参照本《监理细则》相关要求执行。

第二章项目角色一、业主方：1.2. 代表：开发业主方：浙江京安电子工程有限公司二、监理方：1. 监理方：广州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) 鉴定测试、操作和维护的可行性。