IT项目监理细则样本
信息化系统项目监理细则
XXXX信息化项目监理细则第一部分工程概况一、工程简介工程名称：XXXXXXXXXX项目工程地点：XXXXXXXXXXXXX二、项目建设内容第二部分监理工作的流程一、工程需求阶段监理1、监理方应完成的任务：√编写监理方案，并召开三方协调会议，确定工作流程及沟通制度；√根据监理方案及承建方的进度计划，编制监理实施细则；√确定需求变更以及进度计划变更的处理方法，并三方确认；√审核开发计划，以评审报告的形式给用户方进行确认；√参与需求调研方式的制定，并三方确认；√对重要的需求调研部分，应与开发方一起进行调研；√对开发方的调研成果进行核查，及时指出不足之处；√对系统的需求必须有充分的理解；√审核需求规格说明书、以评审报告的形式给用户方进行确认；2、承建单位应提交的文档√开发计划√软件需求说明书3.监理步骤3.1编制监理规划和监理细则；3.2审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解计划，提出监理建议，对工程进度进行控制；3.3督促承建方建立完善的质量保证体系；3.4建立协调机制：督促建设小组的联系、沟通，有利于本阶段的工作效率和效果；3.5审核调研方式：协助业主审核调研计划，进行需求调研准备工作，必要时参加需求的调研工作；3.6审核调研记录：审核承建方提交的用户需求调研记录（即原始需求），协助业主组织进行调研记录的确认工作；3.7组织需求分析报告评审：提交评审预案报告，说明需求分析报告评审的标准规范、评审项及建议；协助业主组织需求分析报告评审，必要时以“专家评审会”的形式展开；3.8协助组织需求分析报告的业主方、监理方、承建方签字确认；3.9审核承建方提交的测试方案；3.10定期向业主报告项目实施的进度和质量情况；二、工程设计阶段监理1、监理方应完成的任务：√对概要设计进度情况进行核查；√审核概要设计说明书，以评审报告的形式给用户方进行确认；√对详细设计进度情况进行核查；√审核详细设计说明书、数据库设计说明书、测试计划，以评审报告的形式给用户方进行确认；√审核开发方提交的周报；√根据实际情况调整进度计划（出现重大变更应立即进行调整），并三方确认；√编制周报，并提交给用户方；√主持召开三方工程例会，编制工程备忘录；√各监理规范表格的使用；2、承建单位应提交的文档√概要设计说明书√详细设计说明书√数据库设计说明书√测试计划√测试报告3、监理步骤3.1审核本阶段计划和明细任务分解计划：审核承建方提交本阶段计划和明细任务分解计划，提出监理建议，对工程进度进行控制；3.2审核承建方的质量保证措施的完备性及有效性；3.3监督实施小组的联系、沟通，有利于实现过程的工作效率和效果；3.4协助业主组织系统设计报告评审；3.5协助业主组织应用系统架构设计、数据库设计的合理性审查；3.6定期向业主报告项目实施的进度和质量情况。
工程信息化项目建设监理细则
《智能建造工程质量验收规范》( GB50339-2003 )《电气装置安装及验收规范》( SL60-94 )《电气建设安全工作规程》( SDJ63-82 )《建造电气安装工程质量检验评定标准》( GBJ303-88 )《电气装置安装工程电气装置施工及验收规范》( GB50196-92 )《低压电气基本标准》 ( GBJ497-79 )《电气装置安装工程盘、柜二次回路接线施工及验收规范》( GB50171-92 )《电气装置安装电缆路线施工及验收规范》( GB60168 )《水位观标准》 ( GBJ138-90 )《工业企业通讯设计技术规定》( GBJ42-81 )《微型数字电子计算机通用技术条件》( GB2887-2000 )《水文自动测报系统规范》( SL61-2003 )《水利水电工程水情测报系统设计规定》( DL/T5051-96)《计算机软件开辟规范》( GB8566-88 )《计算机软件质量保证计划规范》( GB/T 12504-90 )《计算机软件配置管理计划规范》( GB/T 12502-90 )《建造物防雷设计规范》( GB50057-2000 )《电子计算机房设计规范》( GB50174-2022 )《电子设备雷击保护导则》( GB7450-87 )《全国信息化规划》。
《关于开展大型灌区水利信息化建设试点工作的通知》(农水灌[2002]9 号)。
本细则合用于工程信息化建设施工监理控制工作。
⑴为了确保现场仪器及设备安装按合同规定和设计要求进行(如承包人自行采购仪器及辅助装置)，承包人应根据合同文件、设计文件、施工进度以及仪器设备供货所需的时间要求，编制仪器及辅助装置的“采购计划”，报监理部批准。
“采购计划”主要内容应包括：①项目简况。
②供货厂家情况(包括厂名、厂址及其资信情况)。
③采购仪器件申报表(包括埋设部位、仪器名称、规格型号、本批采购数量、计划进场日期、供货价格、承运方式与到货地点 )。
信息化工程监理规范以及实施细则
信息化工程监理规范以及实施细则总则1.为了提高信息化工程监理水平，规范信息化工程行为，编制本规范。
2.本规范适用信息化工程项目的立项、实施、评测等方面的监理工作。
3.实施信息化工程监理前，监理单位必须与信息化建设单位签订书面信息化工程委托监理合同，合同中应包括监理单位对信息化工程技术要求、费用、进度进行全面控制和管理的条款。
4.信息化工程监理应实行总监理工程师负责任。
5.监理单位应公正、独立、自主地开展监理工作，维信息化建设单位承建单位的合法权益。
6.信息化工程监理除应符合本规范外，还应符合国家现行的有关强制性标准、规范的规定。
1. 范围本规范——规定了信息化工程监理的要求和方法——确定了信息化工程监理的基本原则——给出了信息化工程监理工作实施指南——适用于从事信息化工程监理的单位、个人，从事信息化工程的建设单位、承建单位和相关的培训单位也可参照使用。
2. 规范引用文件下列标准所包含的条文，通过在本规范中引用而构成为本规范的条文。
在规范出版时，所示版本均为有效。
所有标准都会被修订，使用本规范的各方应探讨使用下列标准最新版本的可能性。
《信息技术软件生存期过程》GB/T8566-2001 《软件工程术语》GB/T11457-1995 《建设工程监理规范》GB50319-20003. 术语3.1 工程监理是指信息化工程监理单位，接受信息化建设单位的委托，依据国家的有关规定、信息化工程建标准和信息化工程承建、监理合同，对信息化工程的质量、进度和投资方面实施监督和控制。
即从技术和管理的角度，对信息化工程项目的实施过程进行控制和管理，确保信息化工程能够按照信息化建设单位需求，高效、经济的按时完成，实现预期的建设目标。
3.2 工程监理单位具有独立企业法人资格，取得相应等级资质证书，受业主单位委托负责信息化工程监理单位。
3.3 工程建设单位具有信息化工程发包主体资格和支付工程价款能力的单位。
3.4 工程承建设单位取得相应等级的资质证书，承担信息化工程建设的具有工程承包主体资格的单位。
软件开发项目监理细则
软件开发项目监理细则一、项目背景软件开发项目监理是指对软件开发项目的计划、进度、质量、成本等方面进行监督和管理，确保项目按照既定目标和要求顺利进行。
本文将详细介绍软件开发项目监理的细则，包括监理的职责、流程、工具和方法等。
二、监理职责1. 监督项目计划的制定和执行情况，确保计划与实际进展相符。
2. 监控项目进度，及时发现和解决项目延期或进度偏差的问题。
3. 检查项目质量，确保软件开发过程符合相关标准和规范。
4. 监督项目成本，控制开发费用，防止超支情况的发生。
5. 协调项目参与方之间的合作，解决项目中的冲突和问题。
6. 提供专业建议和技术支持，帮助项目团队解决技术难题。
7. 定期向项目管理层和相关方提供项目进展报告和风险评估。
三、监理流程1. 制定软件开发项目监理计划，明确监理目标和任务。
2. 定期召开项目进展会议，了解项目团队的工作情况。
3. 检查项目文档和工作成果，评估项目的质量和进度。
4. 进行现场巡查，检查项目进展和工作环境。
5. 针对项目中出现的问题，及时跟进并提出解决方案。
6. 定期与项目管理层和相关方沟通，汇报项目进展和风险。
7. 对项目进行总结和评估，提出改进意见和建议。
四、监理工具和方法1. 项目管理软件：使用专业的项目管理软件，如Microsoft Project或JIRA等，帮助监理人员进行项目进度和资源管理。
2. 文档审查：对项目文档进行审查，包括需求文档、设计文档、测试文档等，确保其完整性和准确性。
3. 代码审查：对软件开发过程中的代码进行审查，确保代码质量和规范。
4. 测试和验证：参与项目的测试过程，对软件进行功能测试、性能测试和安全测试，确保软件符合要求。
5. 风险评估：对项目中的风险进行评估和管理，制定相应的风险应对措施。
6. 问题解决：及时跟进项目中出现的问题，与项目团队合作解决，并记录问题和解决过程。
7. 专业咨询：提供专业建议和技术支持，帮助项目团队解决技术问题和难题。
监理实施细则模板(信息化、软件工程)
监理实施细则目录一、工程概况及专业工程特点 (4)二、监理工作流程 (4)2工程需求阶段监理 (7)1.工程前期阶段监理 (4)1.1监理方应完成的任务 (4)1.2承包方应提交的文档 (4)1.3建设方应提交的文档 (4)1.4监理方应提交的文档 (4)2.1监理方应完成的任务 (7)2. 2承建单位应提交的文档 (7)2. 3监理方应提交的文档 (7)3.工程设计阶段监理 (7)3.1监理方应完成的任务 (11)3. 2承建单位应提交的文档 (16)3.3监理方应提交的文档 (17)4.工程实施阶段监理 (19)4.1监理方应完成的任务 (19)4.2承建单位应提交的文档 (21)4.3监理方应提交的文档 (21)5.工程验收阶段监理 (24)5.1监理方应完成的任务 (24)5.2承建单位应提交的文档 (25)5.3监理方应提交的文档 (25)三、监理工作要点 (30)1.工程启动阶段的控制要点 (30)2.设计阶段的控制要点 (30)2.1需求调研监理控制点 (32)3.施工阶段的控制要点 (33)3.1软件编码监理控制点 (34)3.2软件测试监理控制点 (35)3.3数据迁移及转换监理控制点 (37)4.验收阶段的控制要点 (39)4.1验收流程 (40)4.2验收的前提条件 (41)4.3验收方案的审核与实施 (41)四、监理工作方法及措施 (42)1.网络工程的监理 (42)1.1 设备采购的监理 (42)1.2 机房工程的监理 (43)1.3 综合布线的监理 (43)1.4 隐蔽工程的监理 (44)1.5 布线系统测试 (44)1.6 网络系统安装调试的监理 (47)2.软件工程的监理 (48)2.1软件项目计划工序监理主要内容的方法 (48)2.2软件质量管理体系建立及执行监 (50)2.3软件质量保证监理主要内容及方法 (50)2.4软件配置管理监理主要内容及方法 (51)2.5需求说明书评审监理工作方法 (52)2.6软件分包合同监理工作方法 (53)2.7概要设计说明书评审监理工作方法 (54)2.8软件编码规范评审 (55)2.9软件编码监理的内容及方法措施 (58)2.10.软件测试监理的内容及方法措施 (61)2.11数据迁移转换监理方法及措施 (66)3.验收阶段监理工作方法及措施 (69)3.1．验收的前提条件 (69)3.2．验收方案的审核与实施 (70)3.3．监理的主要工作 (70)3.4．验收测试 (71)3.5．验收评审 (71)3.6．验收报告 (72)3.7.验收未通过的处理 (72)3.8.系统移交和系统保障监理 (72)一、工程概况及专业工程特点根据实际建设项目填写，主要参考《设计方案》、《实施方案》。
软件开发-项目-监理细则
软件开发-项目-监理细则摘要任何一个软件项目都需要相应的监理机制以确保项目的进程合理、效率高、质量优良。
而监理细则则是指与软件开发项目有关的监理方案、监督措施、标准要求和规范规定等等。
本文旨在探讨软件开发项目中的监理细则。
为何需要监理细则？一个合格的软件监理员需要具备技术过硬、责任心强、严格遵循标准等特征。
监理细则是确保软件开发项目按照标准、规范和流程进行的重要预防措施。
具体而言，其作用在于优化项目进程、促进项目质量、减少漏洞和错误、提高项目经济效益、防止项目的失败和纠纷等等。
可以说，监理细则对于软件开发项目的成功，至关重要。
监理细则的要素监理人员软件开发项目的监理人员需具备以下特质：•技术过硬。
熟知相关标准和规范，具备技术储备及应用，对项目各类软件和策略等都有足够的了解，能够针对项目的具体情况提出可行性建议。
•责任心强。
内心感到对项目负责，并在工作中表现出过硬的工作原则和责任心，对项目质量和进度具有高度的关注。
•严格遵循标准。
熟悉业内标准和国家规范，并能严格执行，确保项目的质量和进程符合标准和规范。
监理内容软件开发项目的监理内容大致包含以下几个方面：•开发流程监督。
追踪项目开发进度和进度较慢的点，以及确认流程符合相应的标准和规范。
•质量审查。
对关键文件和代码进行审查和测试，确保项目合格并达到预期目标。
•特殊活动的审查。
例如，对于某些不常见的建设活动，就需要进行特殊监控，包括需求分析、定义软件结构、测试计划编制、测试执行等等。
监理管理对于软件开发项目监理，管理非常重要。
成功的管理应该围绕以下几个要点展开：•项目计划监管。
制定准确的项目计划，监测和调整进展。
•纠正行动计划。
纠正计划外的行动，防止偏差或低效执行。
•绩效管理。
对项目经理和实践管理团队进行层层考核。
监理细则的执行阶段监理细则的执行阶段主要可分为以下两个阶段：前期准备项目开发阶段前期准备，是监理人员按照一定流程来管理软件开发项目的阶段。
主要包括以下内容：•确认开发任务。
软件工程监理实施细则1.0
软件工程监理实施细则1.0范本一：软件工程监理实施细则1.01. 引言1.1 目的该文档的目的是为软件工程监理项目提供详细的实施细则和指导。
1.2 范围该文档适用于所有软件工程监理项目。
1.3 定义、首字母缩写词和缩略语在本文档中，以下术语的定义适用于整个文档：- 软件工程监理：对软件工程实施过程的监督和管理。
- 项目：指软件工程监理项目。
2. 项目背景2.1 项目简介描述软件工程监理项目的背景和目标。
3. 项目组织结构3.1 项目组织机构描述软件工程监理项目的组织结构和角色职责。
4. 项目计划4.1 项目启动描述软件工程监理项目的启动过程和相关活动。
4.2 项目执行描述软件工程监理项目的执行过程和相关活动。
5. 项目监督与控制5.1 项目监督描述对软件工程监理项目的监督活动和方法。
5.2 问题管理描述对软件工程监理项目中出现的问题的管理方法。
6. 项目报告6.1 项目进展报告描述软件工程监理项目的进展报告内容和格式。
7. 文件管理7.1 项目文档描述软件工程监理项目的文件管理方法和规范。
8. 项目收尾8.1 项目验收描述软件工程监理项目的验收过程和标准。
8.2 项目总结描述软件工程监理项目的总结方法和要点。
9. 附录附件：- 附录A：软件工程监理项目组织结构图- 附录B：软件工程监理项目计划表法律名词及注释：- 法律名词1：注释1- 法律名词2：注释2-------------------------------------------------------------------范本二：软件工程监理实施细则1.01. 引言1.1 目的本文档的目的是为了规范和指导软件工程监理项目的实施。
1.2 范围本文档适用于所有软件工程监理项目。
1.3 定义、首字母缩写词和缩略语在本文档中，以下术语的定义适用于整个文档：- 软件工程监理：对软件工程实施过程的监督和管理。
- 项目：指软件工程监理项目。
2. 项目简介2.1 项目背景描述软件工程监理项目的背景和目标。
信息系统监理实施细则
信息系统监理实施细则1.1监理实施细则编制的程序与依据技术复杂、专业性较强的大中型信息系统工程项目，项目监理组应该编制监理实施细则。
信息系统工程监理实施细则是在监理规划的基础上，根据项目实际情况对各项监理工作的具体实施和操作要求的具体化、详细化，用以指导项目监理部全面开展监理业务。
监理实施细则应符合监理规划中的相关要求，并应结合信息系统工程项目的专业特点，做到详细具体，具有可操作性。
1.监理实施细则编制的规定(1)监理实施细则应在相应工程实施开始前编制完成，须经总监理工程师批准;(2)监理实施细则应由总监理工程师组织各专业监理工程师编制;(3)监理实施细则应符合项目的特点。
2.监理实施细则编写的要求1)要符合项目本身的专业特点监理实施细则虽然是具体指导项目中各专业开展监理工作的技术性文件，但一个项目的目标实现，必须靠各专业间相互的配合协调，才能实现项目的有序进行。
如果各自管各自的专业特点而不考虑别的专业，那么整个项目的有序实施就会出现混乱，甚至影响到目标的实现。
2)严格执行国家、地方的规范及标准并考虑项目自身的特点国家和地方的标准、规范、规程及行业技术规范文件等，是开展监理工作的主要依据。
但是对于一些非强制性的标准、规范可以结合项目的自身特点和监理目标，有选择地采纳部分适合项目自身特点的部分，而不要照抄、照搬。
3)尽可能地对专业方面的技术指标量化、细化，使其更具有可操作性编写监理实施细则的目的是指导项目实施过程中的各项活动，并对各专业的实施活动进行监督和对结果进行评价。
因此，监理工程师必须尽可能地依据技术指标来进行检验评定。
在监理实施细则的编写中，要明确国家标准、规范、规程中的技术指标及要求。
只有这样，才能使监理实施细则更具有针对性、可操作性。
在监理工作的具体实施过程中，监理实施细则应根据实际进行补充、修改和完善。
另外，为确保监理工作的顺利进行，监理实施细则应对所要监理项目中的关键点和实施难点设置“质量控制点”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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) 鉴定测试、操作和维护的可行性。