标准化知识

标准的概述

标准化：为了在一定范围内获得最佳秩序，对现实问题或潜在问题，制定共同使用和重复使用的条款的活动。

标准：为了在一定范围内获得最佳秩序，经协商一致制定并由公认机构批准共同使用和重复使用的一种规范性文件，是标准化活动的核心产物。

标准体系：由标准组成的系统
标准体系结构：层次和并列
标准体系表现形式——标准体系表

国家标准以GB开头、地方标准DB开头、电子行业标准SJ开头；

标准的分类

1、按照适用范围划分

国际标准：ISO、IEC、ITU 等
国家标准：强制性标准代号为：GB；推荐性标准代号为：GB/T；指导性标准：GB/Z；实物标准代号GSB
行业标准：（GJB—中国军用标准MIT-S美国军用标准IEEE美国电气电子工程师协会）其代号由拼音大写字母组成
地方标准：（DB）国家的地方一级行政机构指定的标准
企业标准：（Q）

2、标准涉及的对象类型不同，反映到标准的文本上体现为其技术内容及表现形式的不同

（1）术语标准是指”与术语有关的标准，通常带有定义，有时还附有注、图、示例等。
（2）符号标准是指与符号相关的标准。
（3）试验标准是指“与试验方法有关的标准，有时附有与测试有关的其他。条款，例如抽样、统计方法的应用、试验步骤”。
（4）产品标准是指“规定产品应满足的要求以确保其适用性的标准”。
（5）过程标准是指“规定过程应满足的要求以确保其适用性的标准”。
（6）服务标准是指“规定服务应满足的要求以确保其适用性的标准”。
（7）接口标准是指“规定产品或系统在其互连部位与兼容性有关的要求的标准”。

3、按照标准的要求程度划分

规范、规程、指南

4、规程是指“为设备、构建或产品的设计、制造、安装、维护或使用而推荐惯例或程序的文件”

国家标准制定

阶段代码	阶段名称	阶段任务	阶段成果
00	预阶段	提出新工作项目建议	PWI
10	立项阶段	提出新工作项目	NP
20	起草阶段	提出标准草案征求意见稿	WD
30	征求意见阶段	提出标准草案征求意见稿	CD
40	审查阶段	提出标准草案送审稿	DS
50	批准阶段	提出标准出版稿	FDS
60	出版阶段	提出标准出版物	GB、GB/T、GB/Z
90	复审阶段	对实施周期达5年的标准进行复审	继续有效、修改、修订、废止
95	废止阶段		废止

信息技术（软件工程术语）

抽象：对某一问题的概括，它抽取与某一特定目标相关的本质内容而忽略其非本质内容

验收准则：系统或部件必须满足的准则，其目的是使用户、客户或其他授权实体能够予以接受

验收测试：确定一系统是否符合其验收准则，使客户能确定是否接收此系统的正式测试

可达性：组成软件的各部分便于选择使用或维护的程度

活动：一个过程的组成元素。对基线的变更要经有关机构的正式批准

活动图：用于对涉及一个或多个类目的进程建模的状态机的一种特例

适应性：使不同的系统约束条件和用户需求得到满足的容易程度

关联：规定其实例件连接的多个类目之间的语义联系

聚集：在聚集（整体）与某一构件部分之间，规定整体与一部分之间联系的关联的一种特别形式（组合）

体系结构：系统或部件的组织结构

审计：为评估工作产品或工作产品集是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立检查

需方：从供方获得或得到一个系统、产品或服务的一个机构。需方可以是买主、客户、拥有者、用户、采购人员等

可用性：软件（系统或部件）在投入使用时可操作和可访问的程度或能实现其指定的系统功能的概率

代码审计：由某人、某小组、或借助某种工具对源代码进行的审查，其目的是验证其是否符合软件设计文件和程序设计标准，还可能对正确性和有效性进行估计

代码评审：把软件代码呈现给项目人员、管理人员、用户、客户或其他感兴趣的人员用于评论或批准的会议

配置审计：证明所要求的全部配置项均已产生出来，当俞的配置与规定的需求相符。技术文件说明书完全而准确地描述了各个配置项目，并且曾经提出的所有更动请求均已得到解决的过程

配置控制委员会：是对提出的工程上的更动负责进行估价、审批，对核准进行的更动确保其实现的权力机构

配置状态报告：记录和报告为有效地管理某一配置所需的信息。包括列出经批准的配置标识表、列出对配置提出更动的状态表和经批准的更动的实现状态

功能性配置审计：验证一个配置项的实际工作性能是否符合它的需求规格说明的一项审查，以便为软件的设计和编码建立一个基线

基线：已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理步骤方能加以修改的规格说明或产品。在配置项目生存周期的某一特定时间内，正式制定或固定下来的配置标识文件和这一组这样的文件。基线加上根据这些基线批准批准同意的改动构成了当前配置标识。对于配置管理，有三种基线：功能基线（最初通过的功能配置）、分配基线（最初通过的分配的配置）、产品基线（最初通过的或有条件地通过的产品配置）

验证：确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程

确认：在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程

软件开发方法：是指软件开发过程所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求

自底向上：这种方法从底层结构的最低层软件组成部分开始，逐级向上直至最高层组成部分为止

设计评审：（1）在正式会议上，把系统的初步的或详细的设计提交给用户、客户或有关人士供其评审或批准；（2）对现有的或提出的设计所做的正式评估和审査，其目的是找出可能会影响产品、过程或服务工作的适用性和环境方面的设计缺陷并采取补救措施，以及（或者）找出在性能、安全性和经济方面的可能的改进

评价：决定某产品、项目、活动或服务是否符合它的规定的准则的过程

缺陷或故障：功能部件不能执行所要求的功能

断点：计算机程序中能暂停执行、允许人工或自动监控程序性能或结果。类型包括代码断点、数据断点、动态断点、跋断点、可编程断点、序断点和静态断点

接口：连接，硬件电路的接口是针对不同部件之间的连接电路，起到信息传递的匹配作用；而软件中的接口，是针对不同模块之间程序运行的连接，同样要起到之间信息的匹配作用

数据流图：DFD描述外部实体、数据流、加工、数据存储的一种图

数据字典：软件系统中使用的所有数据项的名字及与这些数据项有关的特性（例如数据项长度、表示等）的集合

认证：是指由认证机构证明产品、服务、管理体系符合相关技术规范、相关技术规范的强制性要求或者标准的合格评定活动

鉴定：是一个正式的过程，通过这个过程决定产品是否符合它的规格说明，是否可在目标环境中适用

黑盒测试：等价类划分、边界值分析、错误推断、因果图
白盒测试：基本路径测试、循环覆盖测试、逻辑覆盖测试

测试：通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一

走查：一种静态分析技术或评审过程，在此过程中，设计者或程序员引导开发组的成员通读已书写的设计或编码，其地成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准等方面进行评论

桌面检查：对程序执行情况进行人工模拟，用遂步检查源代码中有无逻辑或语法错误的办法来检测故障

边界值：相应于为系统或部件规定的最小或最大的输入、内部、输出的数据值

软件文档管理指南

一、软件文档的作用

1）管理依据：文字载体的计划、绩效报告等资料可以让项目管理者明确的了解项目的进展、存在的问题等，是对项目进行管理控制的依据。
2）任务之间联系的凭证：通常很多软件开发项目由不同的角色、小组去完成不同的任务，各角色、小组之间的相互联系须通过文档资料的复制、分发和引用实现。比如分析员向设计员提供软件需求规格说明书。
3）质量保证：负责质量保证和评估系统性能的人员需要程序规格说明、测试和评估计划、测试该系统的各种质量标准，以及关于期望系统完成什么功能和如何实现这些功能的具体说明；必须制订测试计划和测试规程，并报告测试结果。他们还必须说明和评估安全、控制、计算、检验例行程序及其他控制技术。这些文档的提供可满足质量保证人员和审查人员对上述工作的需要。
4）培训与参考：可以使系统管理员、操作员、管理者和其他相关人员了解系统如何工作，以及如何使用系统。
5）软件维护支持：系统维护人员需参考系统的详细说明，以帮助他们熟悉系统，找出并修正错误，改进系统以适应用户需求的变更或是系统运行环境的变化。
6）历史档案：软件文档可记载系统的开发历程，作为组织过程资产进行保留，便于未来项目的参考复用。

二、软件文档类型

序号	文档类型	作用功能
1	开发文档	可行性研究和项目任务书、需求规格说明、功能规格说明、设计规格说明、开发计划、软件集成和测试计划、质量保证计划和标准、项目进度计划、安全和测试信息
2	产品文档	是描述开发过程的产物，包括如下：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告
3	管理文档	是记录项目管理的信息，包括如下：开发过程的每个阶段的进度和进度变更的记录、软件变更情况的记录、相对于开发的判定记录、职责定义

三、软件文档等级

每个文档的质量必须在文档计划期间就有明确的规定。文档的质量可以按文档的形式和列出的要求划分为四级：

1）最低限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包括程序清单、开发记录、测试数据和程序简介
2）内部文档（2级文档）：可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释，以帮助用户安装和使用本程序
3）工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
4）正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如薪酬计算）的程序需要4级文档。4级文档遵守GB8567的有关规定

四、文档评审

为了提高软件产品质量，我们可以在对每个软件开发过程中每个阶段形成的文档进行严格的评审，通过评审，可以尽早发现问题，及时采取有效措施进行解决，确保文档内容的正确性，避免或尽可能的减少返工，同时为进入下一阶段的工作做好组织上和技术上的准备。
我们需要重点掌握需求评审和设计评审。无论项目大小或项目管理的正规化程度，需求评审和设计评审是必不可少的。

1）需求评审：进一步确认开发者和设计者已了解用户有什么要求，以及用户从开发者一方了解到的某些限制和评审。在这个阶段（可能需要一次或以上）产生一个被确认的需求规格说明。只有对系统要做些什么，实现什么功能进行了共同了解并确认认可，才能着手详细设计。其中用户代表必须积极参加开发和需求评审，参与对需求文档的认可。
2）设计评审：主要为概要设计评审和详细设计评审。在概要设计评审过程中，主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应根据概要设计评审的结果加以修改。详细设计评审主要评审计算机程序和程序单元测试计划。经过设计评审，最终产生的文档需规定系统和程序将如何设计、开发和测试，以满足一致同意的需求
另外，对于其他文档的正规评审也是必须的。评审一般是采用评审会的方式进行。

评审步骤如下

1、由软件开发单位负责人、用户代表、开发小组成员、科技管理人员和标准化人员等组成评审小线，必要时还可邀请外单位的专家参加。
2、开会前，由开发单位负责人确定评审的具体内容，并将评审材料发给评审小组成员，要求做好评审准备。
3、由开发单位负责人主持评审会，根据文档编制者对该文档的说明和评审条目，由评审小组成员进行评议、评审，评审结束应做出评审结论，评审小组成员应在评审结论上签字。

五、文档归档

1、归档的文件应该是软件生存期内所形成的所有文档，在进行归档时，我们必须遵循以下原则：

▲归档的文件应该是经过鉴定或是评审的；
▲文档应签署完整、成套、格式统一、字迹工整；
▲印制本、打印本及各种报告应该装订成册，而且须按规定进行编号，签署；
▲而且，文档应在开发过程的每个阶段结束后及时归档。
▲另外，我们还需要注意文档需要覆盖整个软件生存期，而且是可用和可维护的。

2、支持有效文档策略的基本条件：

（1）文档需要复盖整个软件生存期
（2）文档应是可管理的
（3）文档应适合于它的读者
（4）文档效应应贯穿到软件的整个开发过程中
（5）文档标准应被标识和使用
（6）应规定支持工具

3、按照GB/T16680《软件文档管理指南》规定：

◆软件产品的所有文档都应按规定进行签署
◆软件文档签署的顺序一般按编写--审核--会签--标准化--批准的顺序进行。
◆其中会签仅在必要时才进行。
◆签署不允许代签。
◆修改单的签署与被修改的文档签署相同。
◆附录提了供软件文档签署者

计算机软件产品开发文件编制指南

一、软件各生命周期产生的文档

软件生命周期各阶段与软件文档编制工作的关系以及各个人员负责的事项：表软件生命周期各阶段与软件文档编制工作的关系

文档	计划	需求分析	设计	编码	测试	进行维护
可行性研究报告	√
项目开发计划	√	√
软件需求规格说明		√
数据需求规格说明		√
测试计划		√	√
概要设计说明			√
详细设计说明			√
数据库设计说明			√
模块开发卷宗				√	√
用户手册		√	√	√
操作手册			√	√
测试分析报告					√
开发进度月报	√	√	√	√	√
项目开发总结					√

二、文档归属问题

该标准规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发文档两大类。其中，用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。

文档	管理人员	开发人员	维护人员	用户
可行性研究报告	√	√
项目开发计划	√	√
软件需求说明书		√
数据要求说明书		√
概要设计说明书		√
详细设计说明书		√	√
数据库设计说明书		√	√
用户手册				√
操作手册				√
模块开发卷宗	√		√
开发进度月报	√
测试计划		√
测试分析报告		√	√
项目开发总结	√
维护报告	√		√

三、软件生存周期的六个阶段

阶段	工作内容
可行性与计划研究阶段	确定该软件的开发目标和总的要求，要进行可行性分析、投资——收益分析、制订开发计划，并完成可行性分析报告、开发计划等文档
需求分析阶段	由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明（也称为：软件需求说明、软件规格说明）、数据要求说明和初步的用户手册应该编写出来
设计阶段	系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块的划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计划初稿。
实现阶段	要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写进度日报、周报和月报（是否要有日报或周报，取决于项目的重要性和规模），并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。
测试阶段	该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。
运行与维护阶段	软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。

计算机软件需求说明编制指南

1、SRS应该具有以下特性：

1）无歧义性
2）完整性
3）可验证性
4）一致性
5）可修改性
6）可追踪性（向后追琮、向前追踪：）
7）运行和维护阶段的可使用性

2、SRS的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。编写需求的人必须描述的基本问题是：

a．功能
b．性能
c．强加于实现的设计限制
d．属性
e．外部接口
编写需求的人应当避免把设计或项目需求写入SRS之中，应当对说明需求设计约束与规划设计两者有清晰的区别

3、SRS应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目：

a．把软件划分成若干模块:
b. 甲给每一个模块分配功能;
c. 描述模块间的信息流程或者控制流程:a．选择数据结构。
SRS应当是描述一个软件产品，而不是描述产生软件产品的过程。

4、项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解（因此不应当包括在SRS中），例如：

a．成本;
b．交货进度:
c．报表处理方法;
d．软件开发方法;
e．质量保证;
f．确认和验证的标准;
g．验收过程

5、《计算机软件需求说明编制指南》中定义了软件需求的具体内容，包括的：

功能需求、性能需求、设计约束、外部接口需求、属性、其它需求这6项：

序号	需求种类	详细定义
1	功能需求	指描述软件产品的输入怎样换输出，即软件必须完成的基本动作。对于每一类功能或有时对每一个功能需要具要具体描述其输入、加工和输出的需求。
2	性能需求	描述企业当前的运行效率，可以分析当前业务的处理速度。一般是数字化的描述。如0.5秒内响应、10秒内完成支付功能等。
3	设计约束	设计约束受其他标准、硬件限制等方面的影响。
4	属性	在软件的需求之中有若干个属性如可移植性、正确性、可维护性及安全性等。
5	外部接口需求	包括用户接口、硬件接口、软件接口、通信接口。
6	其他需求	根据软件和用户组织的特性等某些需求放在数据库、用户要求的常规和特殊的操作、场合适应性需求中描述。

软件维护指南

同级评审：一种质量保证方法，由两个或多个程序员相互检查、评估，以确保被检查内容正确，且与软件的其他部分一致

软件维护：在软件产品交付使用之后，为纠正故障，改善性能和其他属性，或使产品适应改变了的环境所进行的修改活动。一般分为完善性维护、适应性维护和改正性维护、预防性维护。

完善性维护：为扩充功能和改善性能而进行修改和扩充，以满足用户变化了的需求。主要包含：为扩充或增强功能而做的修改、为提高性能而作的修改、为便于维护而作的修改—锦上添花

适应性维护：为适应软件运行环境的变化而做的修改，比如系统的规定、法律和法规的变化；硬件配置的变化；数据格式变化；操作系统、编译系统等变化。—适应变化

改正性维护：为维持系统操作运行，对在开发过程产生而在测试和验收时没有发现的错误而进行的改正。所必须改正的错误包括：设计错误、逻辑错误、编码错误、文档错误、数据错误。—知错就改

预防性维护：为改进软件的可靠性和可维护性，为适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使软件适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。----未雨绸缪

信息技术の软件生存周期过程

该标准适用于系统和软件产品以及服务的获取，还适用于软件产品和固件的软件部分的供应、开发、操作和维护，可在一个组织的内部或外部实施。应包含为软件产品和服务提供环境所需要的系统定义。

主要分为软件的主要过程、支持过程和组织过程。

主要过程过程名	主要活动
获取过程	定义、分析需求或委托供方进行需求分析而后认可：招标准备：合同准备以及验收
供应过程	评审需求：准备投标：签定合同：制订并实施项目计划：开展评审及评价：交付产品
开发过程	过程实施；系统需求分析：系统结构设计；软件需求分析；软件结构设计：软件详细设计：软件编码和測试：软件集成：软件合格測试：系统集成：系统合格测试：软件安装及软件验收支持
运行过程	制订并实施运行计划：运行測试；系统运行：对用户提供帮助和咨询
维护过程	问题和变更分析：实施变更：维护评审及维护验收：软件移植及软件退役

支持过程过程名	主要活动
文档编制过程	设计文档编制标准：确认文档输入数据的来源和适宜性;文档的评审及编辑；文档发布前的批准：文档的生产与提交、储存和控制：文档的维护
配置管理过程	配置标识：配置控制：记录配置状态：评价配置；发行管理与交付
质量保证过程	软件产品的质量保证；软件过程的质量保证，以及按ISO9001标准实施的质量体系保证
验证过程	合同、过程、需求、设计、编码、集成和文档等的验证
确认过程	为分析測试结果实施特定的测试；确认软件产品的用途：測试软件产品的适用性
联合评审过程	实施项目管理评审（项目计划、进度、标准、指南等的评价）、技术评审（评审软件产品的完整性、标准符合性等）
审计过程	审核项目是否符合需求、计划、合同，以及规格说明和标准
问题解决过程	分析和解决开发、运行、维护或其他过程中出现的问题，提出响应对策，使问题得到解决

组织过程过程名	主要活动
管理过程	制定计划：监控计划的实施：评价计划实施：涉及到有关过程的产品管理、项目管理和任务管理
基础设施过程	为其他过程所需的硬件、软件、工具、技术、标准，以及开发、运行或维护所用的各种基础设施的建立和维护服务
改进过程	对整个软件生存期过程进行评估、度量、控制和改进
培训过程	制订培训计划：编写培训资料；培训计划的实施

质量管理体系基础和术语

质量管理是指确立质量方针并进行实施的全部职能和工作内容，并对其工作效果进行评价和改进的一系列工作，它应当遵循以下原则：

1）以顾客为关注焦点：因为组织依存于顾客，所以，组织应当理解顾客当前和未来的需求，要满足甚至是超出用户的期望。
2）领导参与：领导者应确保组织的目标和方向的一致。他们应该创造良好的内部环境，使员工能充分参与实现组织目标的活动。
3）全员参与：各级人员都是组织之本，只有全员参与，才可以使他们为组织的利益发挥其才华。
4）过程方法：需要将活动和相关自愿作为过程进行管理，从而更高效的得到期望的结果。
5）管理的系统方法：将相互关联的过程作为体系来看待、理解和管理，有助于组织提高实现目标的有效性和效率
6）持续改进：持续改进总体业绩是组织的永恒目标
7）基于事实的决策方法：有效的决策建立在数据和信息分析的基础上
8）与供方互利的关系：组织与供方相互依存，互利的关系可以增强双方创造价值的能力

计算机软件质量保证计划规范

软件生存周期：从提出应用需求开始，经过开发，产生一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段

验证：确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。（验证软件质量）

确认：在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。（确认的是软件需求）

测试：通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。

质量：反映产品或服务满足明确或隐含需求能力的特征和特性的总和。

质量保证：为使软件产品满足规定需求所进行的一系列有计划的必要工作。

软件设计说明书：应该包括软件概要设计说明和软件详细设计说明两部分。其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每一个子部件进行描述。其详细设计部分必须给出每一个基本部件的功能、算法和过程描述。

功能检查：在软件释放前，要对软件进行功能检查，以确认已经满足在软件需求规格说明书中规定的所有需求。

物理检查：在验收软件前，要对软件进行物理检查，以验证程序和文档已经一致并已做好了交付的准备。

综合检查：在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性、接口规格说明之间的—致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

管理评审：要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。

阶段评审：在软件开发过程中，要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。根据总体组研究决定，在cADcsc软件及其所属各子系统的开发过程中，应该进行以下三次评审：

第一次评审软件需求、概要设计、验证与确认方法；
第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；
第三次是功能检查、物理检查和综合检查。

质量保证计划中：确保软件需求实现，至少需要的文档：软件需求规格说明书、软件设计说明书、软件验证与确认计划、软件验证和确认报告、用户文档、其它文档（比如：项目实施计划、项目进展报告、各阶段评审报表、项目开发总结）。

软件质量保证小组：在系统开发期间，必须成立软件质量保证小组，负责质量保证工作。软件质量保证小组属总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及子系统软件质量保证人员组成。由软件工程小组代表任组长，各子系统的软件质量保证人员在业务上受软件质量保证小组领导，在行政上受各子系统负责人领导。

评审小组：在软件开发过程中，需定期地或阶段性的对某开发阶段的阶段产品进行评审，因此，需组建评审小组。评审小组原则上由项目总体小组成员或特邀专家担任评审组长，项目委托单位、用户代表、质量保证人员、软件开发单位和上级主管部门的代表以及其他人员作为小组成员。
“项目评审小组可以不设副组长;此外，项目开发组长或其代表可以作为评审组的成员，但不能担任评审组的组长或副组长.”

文档质量度量准则：我们知道，文档是软件的重要组成部分，在进行验证和确认时，必须对文档的质量进行度量，主要包含：完备性（在开发阶段结束时，保证文档是齐全的）、正确性（真实反映各阶段的工作而且与各阶段的需求相一致）、简明性（各文档的语言表达应该清晰、准确简练）、可追踪性（文档应该具有良好的纵向可追踪性和横向可追踪性。纵向是指不同文档的相关内容之间相互检索的难易程度，横向是指确定同一文档某一内容在本文档中的涉及范围的难易程度）、规范性（文档的封面、大纲、术语的含义以及图示符号符合相关规定）。

性能检查：性能方面的检查，比如可靠性！

配置检查：必须编制有关软件配置管理的条款，或引用按照GB/T12505单独编制修订的文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工程等四个方面的活动。还必须规定用以维护和存储软件受控版本的方法和措施，必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

用户文档：比如用户手册、指南等，必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的出错信息、含义及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位(或软件开发单位)或项目委托单位的方法。用户文档的详细格式按GB8567标准。

概要设计评审：在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。

信息技术の软件产品评价、质量特性及其使用指南

一、软件质量特性

6个特性、21个子特性

功能靠用小护翼
是准备用一安培，错译成，学姐坐石源，应该装一个T

质量特性及定义	质量子特性及定义
功能性：一组功能及其指定的性质有关的一组属性	1、适合性：与规定任务能否提供一组功能及这组功能的适合程度有关的软件属性； 2、准确性：与能否得到正确或相符的结果或效果有关的软件属性； 3、互用性/互操作性：与其他指定系统进行交互的能力有关的软件属性； 4、依从性：使软件遵循有关标准、法律、法规及类似规定的软件属性； 5、安全性：防止对程序及数据的非授权的故意或意外访问的能力；
可靠性：在规定的一段时间和条件下，软件维持其性能水平有关的一组软件属性	1、成熟性：与由于软件故障引起失效的频度有关的软件属性； 2、容错性：与在与软件故障或违反指定接口情况下，维持规定的性能水平的能力有关的软件属性； 3、易恢复性：与在失效发生后，重新建立其性能水平、恢复直接受影响数据的能力，以及为达到此目的的所需的时间和努力有关的软件属性；
可用性：与使用的难易程度及规定或隐含用户对使用方式所做的评价有关的软件属性	1、易理解性：与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性； 2、易学性：与用户为学习使用该软件系统所花的努力有关的软件属性； 3、易操作性：与用户为操作和运行控制所花努力有关的软件属性；
效率：与在规定条件下，软件的性能水平和所用资源之间的关系有关的一组软件属性	1、时间特性：与软件执行其功能时相应和处理时间以及吞吐量有关的软件属性； 2、资源特性：与在软件执行其功能时，所使用的资源量及使用资源、持续时间有关的软件属性；
可维护性：与进行指定的修改所需的努力有关的一组软件属性	1、易分析性：与为诊断缺陷或失效原因、判定待修改的部分所需努力有关的软件属性； 2、可修改性：与进行修改、排除错误或适应环境变化所需努力有关的软件属性； 3、稳定性：与修改所造成的未预料结果的风险有关的软件属性； 4、可测试性：与确认已修改软件所需的努力有关的软件属性
可移植性：与软件可从某一环境转移到另一环境的能力有关的一组软件属性	1、适应性：与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性； 2、易安装性：与在指定环境下安装软件所需努力有关的软件属性； 3、一致性（遵循性）：使软件遵循与可移植有关的标准或约定的软件属性； 4、可替换性：软件在特定环境中用来替代指定的其他软件的可能性和难易程度；

二、软件外部、内部、使用、过程质量特性

用户质量要求可通过使用质量的度量、外部度量，有时是内部度量来确定为质量需求

• 内部度量可用于开发阶段的非执行软件产品(例如标书、需求定义、设计规格说明或源代码等)。内部度量为用户提供了测量中间可交付项的质量的能力，从而可以预测最终产品的质量。这样就可以使用户尽可能在开发生存周期的早期察觉质量问题，并采取纠正措施。
• 外部度量可以通过测量该软件产品作为其一部分的系统行为来测量软件产品的质量。外部度量只能在生存周期过程中的测试阶段和任何运行阶段使用。在所属系统环境下运行该软件产品即可获得这样的测量。
• 使用质量的度量是测量产品在特定的使用环境下，满足特定用户达到特定目标所要求的有效性、生产率、安全性和满意度的程度。这只能在真实的系统环境下获得。
• 用户的质量要求可用使用质量的度量、外部度量甚至是内部度量的质量需求来规定。这些由度量规定的需求宜作为产品评
  
• “软件质量”包括内部质量（开发过程内）、外部质量（开发过程外）和使用质量（用户的质量观）3个部分。因此，质量途径的一般顺序是过程质量属性测量——内部质量属性测量——外部质量属性测量——使用质量属性测量。
• 根据GB/T-17544，软件包质量要求包括三部分，即产品描述要求、用户文档要求、程序和数据要求。
• 软件度量贯穿整个软件开发生命周期，是软件开发过程中进行理解、预测、评估、控制和改善的重要载体。软件质量度量建立在度量数学理论基础之上。软件度量包括3个维度，即项目度量、产品度量和过程度量。
• 过程质量有助于提高产品质量，而产品质量又有助于提高使用质量。因此，评估和改进一个过程是提髙产品质量的一种手段，而评价和改进产品质量则是提高使用质量的方法之一。同样，评价使用质量可以为改进产品提供反馈，而评价产品则可以为改进过程提供反馈。

信息处理——数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定

• 数据流程图：表示求解某一问题的数据通路。
• 程序流程图：表示程序中的操作顺序
• 系统流程图：表示系统的操作控制和数据流
• 程序网络图：表示程序激活路径和程序与相关数据的相互作用
• 系统资源图：表示适合于一个问题或一组问题求解的数据单元和处理单元的配置

软件支持环境

软件支持环境又可分为如下两种类型：

• 软件开发支持环境：由软件承办单位确定、并经任务委托单位认可的资源，用于支持合同项目中的软件需求。
• 软件生存期支持环境：由软件生存期真持部门使用的（属于任务委托单位的）资源，用于为指定的目标机系统提供整个生存期内的软件支持。

计算机软件配置管理计划规范

术语	定义
软件配置	指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项
功能基线	指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待幵发系统的规格说明：或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志
指派基线	指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志
产品基线	指在软件组装与系统測试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志
释放	指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。其中，将系统集成与系统测试阶段结束时所获得的最终产品向用户提交的过程,也被称为交付

计算机软件可靠性和可维护性管理

一、可靠性和可维护性概念

《GB/T14394—1993计算机软件可靠性和可维护性管理》由原国家技术监督局于1993年5月14日发布，1994年1月1日起实施

• 根据该标准，软件可靠性是指：（1）在规定环境下，在规定时间内软件不引起系统失效的概率：（2）在规定的时间周期内所述条件下程序执行所要求的功能的能力。
• 软件可维护性是指与进行规定的修改难易程度有关的一组属性。软件可靠性和可维护性大纲是指为保证软件满足规定的可靠性和可维护性要求而制订的一套管理文件。
• GB/T14394-2008《计算机软件可靠性和可维护性管理》强调各个阶段软件可靠性和可维护性要求

二、可靠性和可维护性要求

序号	活动	定义、相关说明
1	概念活动	进行软件可行性要析，制定初步软件开发计划，提出软件可靠性和可维护性目标、要求及经费
2	需求活动	分析和确定软件可靠性和可维护性的具体设计目标，确保与研制任务书和合同中相应要求的可追踪性，制定实施计划，制定各实施阶段的基本准则，确定各实施阶段的验证方法
3	设计活动	进行软件可靠性和可维护性分析和设计，编写相应的设计说明，明确对编码、测试阶段的具体要求，组织设计评审，并验证可靠性和可维护性目标的实施和与需求活动中所提相应要求的可追踪性
4	实现活动	按照规定的规则，在软件编码过程中依据需求和设计活动中相应的规定实现可靠性和可维护性要求，进行单元测试，做好后续测试工作的准备，评价或审查代码以验证相应要求的实现
5	测试	在单元和集成测试阶段，验证相应可靠性和可维护性要求的实现，进行重用软件的可靠性和可维护性管理；在软件配置项测试和系统集成测试阶段，建立适当的软件可靠性测试环境，组织分析测试和测量的数据，验证软件可靠性和可维护性的实现，进行风险分析，决定交付时机
6	安装和验收活动	采取联合评审、审核、软件合性测试和系统合格性测试等手段对可靠性和可维护性进行最终验证和评定

三、可靠性和可维护性评审要点

在软件开发各阶段都要求进行评审，评审管理要求按GB8566进行，其中与软件可靠性和可维护性有关的具体评审要求如下：

评审	评审要点
需求分析评审	1）可靠性和可维护性目标; 2）大纲及其实施计划; 3）操作顺序和不可逆操作顺序的保障要求; 4）功能降级使用方式下，软件产品最低功能保证的规格说明。 5）选用或制定的规范和准则。
概要设计评审	1）可靠性和可维护性目标分配; 2）可靠性和可维护性设计方案; 3）设计分析，关键成分的时序，估计的运行时间，错误恢复及相关性能要求; 4）测试原理、要求、文件和工具。
详细设计评审	1）各单元可靠性和可维护性目标; 2）可靠性和可维护性设计（如:容错）; 3）测试文件; 4）软件开发工具
软件验证与确认计划评审	1）软件可靠性和可维护性验证和确认方法; 2）软件可靠性和可维护性测试（计划、规程、用例和设施）; 3）验证与确认时所用的其他准则
测试评审	（a）针对可靠性和可维护性的测试目标 （b）测试方法 （c）测试用例 （d）测试工具 （e）测试通过标准 （f）测试报告

信息安全等级保护

信息系统的安全保护等级共分为五级：信息安全等级保护是我国在信息化推进进程中实施的对信息系统安全保护的基本制度、方法和策略。

口诀：自审标结验

等级	内容
用户自主保护级	适应于普通内联网用户，信息系统受到破坏后，会对公民、法人和其他组织的合法权益造成损害，但不损害国家安全、社会秩序和公共利益。
系统审计保护级	适用于内联网或国际网进行商务活动，需要保密的非重要单位。信息系统受到破坏后，会对公民、法人和其他组织的合法权益造成严重损害，或者对社会秩序和公共利益造成损害，但不损害国家安全。
安全标记保护级	适用于地方各级国家机关、金融机构、邮电通信、能源与水源供给部门、交通运输、大型工商与信息技术企业、重点工程建设等单位。信息系统受到破坏后，会对社会秩序和公共利益造成严重损害，或者对国家安全造成损害。
结构化保护级	适应于中央级国家机关、广播电视部门、重要物资储备单位、社会应急服务部门、尖端科技企业集团、国家重点科研机构和国防建设等部门，信息系统受到破坏后，会对社会秩序和公共利益造成特别严重损害，或者对国家安全造成严重损害。
访问验证保护级	适应于国防关键部门和依法需要对计算机信息系统实施特殊隔离的单位。信息系统受到破坏后，会对国家安全造成特别严重损害。

IT服务的相关标准

1、ISO/IEC20000系列标准

ISO/IEC20000着重于通过“信息技术服务标准化”来管理信息技术问题。

目前，我国已经正式发行了两项ISO/IEC20000系列标准，分别是：
GB/T24405.1信息技术服务管理第1部分：规范。
GB/T24405.1信息技术服务管理第2部分：实践导则

2、ISO/IEC27000系列标准

ISO/IEC27001是标准族的主标准，各类组织可以按照ISO/IEC27001的要求建立自己的信息安全管理体系（ISMS）。
该标准的要求是通用的，适用于所有的组织、不考虑类型、规模和特征。

3、ISO9000系列标准是质量管理体系标准，该系列标准包括三个核心标准：

（1）IS09000/GB/Tl9000《质量管理体系基础和术语》为正确理解和实施质量管理体系标准提供必要的基础。
（2）IS09001/GB/Tl9001《质量管理体系要求》规定的要求旨在为组织的产品和服务提供信任，从而增强顾客满意。
（3）IS09004/GB/Tl9004《追求组织的持续成功质量管理方法》为组织选择超出本标准要求的质量管理方法提供指南。

4、ISO/IEC38500标准

这一标准提供了一个IT治理的框架，以协助组织高层管理者理解并履行他们对于其组织IT使用的既定职责，实现IT治理的有效性、可用性及效率。

5、ISO22301业务连续性管理体系

ISO22301规定了监理和管理一个有效的业务连续性管理体系（BCMS）。
本标准采用了“规划（Plan）-实施（Do）-检查（Check）-处置（Act）”这种（PDCA）模型来规划、建立、实施、运行、监视、评审、保持和持续改进组织的BCMS的有效性。

6、ITIL即IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)是目前业界普遍采用的一类IT服务管理的实际标准及最佳实践指南。
ITIL包含着如何管理IT基础设施的流程描述，以流程为向导、以客户为中心，通过整合IT服务与企业服务，提高企业的IT服务提供和服务支持的能力和水平

1、Version1 主要是基于职能型的实践
2、Version2 主要是基于流程型的实践
3、Version3 主要强调最佳实践执行
4、Version4 主要为了加强服务管理办法中的逻辑组织和业务一致性使用了5个主要书面指导文件：涉及论述IT服务的服务战略、服务设计、服务转换、服务运营和服务的持续改进

涉及4个职能：服务台、运营管理、应用管理、技术管理

7、COBIT（Controlled Objectives for Information and Related Technology）即信息及相关技术的控制目标。COBIT包含34个信息技术过程控制，并归集为4个控制域：

1、IT规划和组织（PlanningandOrganization）
2、系统获得和实施（AcquisitionandImplementation）
3、交付与支持（DeliveryandSupport）
4、信息系统运行性能监控（Monitoring）

该框架的意义在于：COBIT实现了企业目标与IT治理目标之间的桥梁作用

从内容上看，COBIT覆盖了从分析、设计到开发、实施到运营、维护的整个过程，COBIT覆盖整个信息系统的全部生命周期，其视野是最为开阔的。

IT服务国内标准

1、ITSS（Information Technology Service Standards）是信息技术服务标准，是在工业和信息化部、国家标准化委的领导和支持下，由ITSS工作组研制的一套IT服务领域的标准库和一套提供IT服务的方法论。

2、组成要素-----IT服务由人员（People）、过程（Process）、技术（Technology）和资源（Resource）组成，简称PPTR。

3、生命周期------IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称PIOIS。

信息技术服务相关标准

1、《信息技术服务分类与代码》

依据GB/T29264-2012《信息技术服务分类与代码》规定，信息技术服务包括：信息技术咨询服务、设计与开发服务、信息系统集成实施服务、运行维护服务、数据处理和存储服务、运营服务、数字内容服务、呼叫服务及其它信息技术服务。

2、《信息技术服务运行维护第一部分：通用要求》

3、《信息技术服务运行维护第二部分交付规范》

4、《信息技术服务运行维护第三部分应急响应规范》

运行维护服务应急响应过程规划分为四个主要阶段：应急准备、监测与预警、应急处置、和总结改进

5、《信息技术服务运行维护第四部分：数据中心规范》

（1）运行维护对象：机房环境、网络通信及设备、服务器及存储、软件、数据和应用等。
（2）基本活动交付内容包括：例行操作、响应支持、优化改善和咨询评估。

①例行操作包括：监控、预防性检查、常规作业。
②响应支持：事件驱动响应、服务请求响应。
③优化改善：适应性改进、增强型改进、预防性改进。
④咨询评估：包含空调、供配电设备等建议。

（3）运维服务基本目标：及时、规范、安全、可用
（4）运维服务报告：运维服务实施中，供方应按要求进行服务报告编制、提交。服务报告统筹分为常规报告、事件报告和专题报告。

6、《信息技术服务服务管理第3部分：技术要求》SJ/T11435-2016

7、《信息技术服务从业人员能力规范》SJ/Tl1623-2016

（1）该标准依据信息技术服务行业发展的要求，将信息技术服务从业人员能力划分为知识、技能和经验三个维度。

（2）根据我国信息技术服务行业的特点、市场需求、职业种类的不同，以及知识、技能、经验的不同，将职业资格划分为6个等级。

8、ITSS运维能力成熟度模型

综合布线标准

一、基本概念

目前在综合布线领域被广泛遵循的标准是TIA/EIA568A

• 建筑群子系统、设备间子系统、垂直干线子系统、管理子系统、水平子系统和工作区子系统。水平子系统采用的网络拓扑结构是星型。

（1）工作区子系统：由终端设备连接到信息插座的连线组成，包括连接器、适配器、插座盒、信息插座等。

（2）配线（水平）干线子系统：在一个楼层上，连接信息插座和管理间子系统，一般为4对UTP；其中配线子系统信道的最大长度不应大于100m，工作区设备缆线、电信间配线设备的跳线和设备缆线之和不应大于10m，当大于10m时，水平缆线长度最大长度（90m）应适当减少。楼层配线设备（FD）跳线、设备缆线及工作区设备缆线各自的长度不应大于5m。

（3）管理间子系统：由交连、互连配线架组成；

（4）垂直干线子系统：一般在楼层之间，连接管理间子系统和设备间子系统，由所有的布线电缆组成；

（5）设备间子系统：由设备间中的电缆、连接器、和相关支撑硬件组成，该系统把公共系统设备中的不同硬件互连起来。

（6）建筑群子系统：实现建筑物间的互相连接，常用的通信介质是光缆。线缆布设方式有4种：架空布线、直埋布线、地线管道布线和隧道内电缆布线。

二、参数要求

• 大楼综合布线系统的适用范围：跨越距离不超过3000m，建筑总面积不超过100万平方米，人数为50-5万人。
• 计算RJ-45接头的用量公式：m=4n+4n*15%，其中m代表接头的总需求量、N代表信息点总量。
• 线缆平均长度计算公式：= [（最大长度+最小长度）/21.1信息点数量+6 ]，其中6为端接余量，单位为米。加余量系数是因为在实际走线的过程中不可能可钉可铆的，要有浪费的。
• 综合布线系统设计等级，可划分为三个等级：分别为：基本型，增强型，综合型。

电子信息系统机房设计规范

一、机房等级

电子信息系统机房应划分为A、B、C三级，A级最高；设计时应根据机房的使用性质、管理要求及其在经济和社会中的重要性确定所属级别：

等级	使用性质	管理要求
A级	电子信息系统运行中断将造成重大的经济损失；2电子信息系统运行中断将造成公共场所秩序严重混乱。	A级电子信息系统机房内的场地设施应按容错系统配置，在电子信息系统运行期间，场地设施不应因操作失误、设备故障、外电源中断、维护和检修而导致电子信息系统运行中断。
B级	电子信息系统运行中断将造成较大的经济损失；2电子信息系统运行中断将造成公共场所秩序混乱。	B级电子信息系统机房内的场地设施应按冗余要求配置，在系统运行期间，场地设施在冗余能力范围内，不应因设备故障而导致电子信息系统运行中断。
C级	不属于A级或B级的电子信息系统机房应为C级	C级电子信息系统机房内的场地设施应按基本需求配置，在场地设施正常运行情况下，应保证电子信息系统运行不中断。

二、机房位置选择

电子计算机机房在多层建筑或高层建筑物内宜设于第二、三层。

电子信息系统机房位置选择应符合下列要求。
1、电力供给应稳定可靠，交通、通信应便捷，自然环境应清洁；
2、应远离产生粉尘、油烟、有害气体以及生产或贮存具有腐蚀性、易燃、易爆物品的场所；
3、应远离水灾和火灾隐患区域；
4、应远离强振源和强噪声源；
5、应避开强电磁场干扰。

三、机房组成

• 电子信息系统机房的组成应根据系统运行特点及设备具体要求确定，宜由主机房、辅助区、支持区、行政管理区等功能区组成。

主机房的使用面积应根据电子信息设备的数量、外形尺寸和布置方式确定，并应预留今后业务发展需要的使用面积。在对电子信息设备外形尺寸不完全掌握的情况下，主机房的使用面积可按下式确定：

1、当电子信息设备已确定规格时，可按下式计算：
		A=K∑S（4．2．2-1）
		式中A——主机房使用面积（m2）；
		K——系数，可取5～7；
		S——电子信息设备的投影面积（m2）。
2、当电子信息设备尚未确定规格时，可按下式计算：
		A=F’N（4．2．2—2）
		式中F——单台设备占用面积，可取3．5～5．5（m2／台）；
		N——主机房内所有设备（机柜）的总台数。
		辅助区的面积宜为主机房面积的0．2～1倍。
		用户工作室的面积可按3.5～4m2／人计算；硬件及软件人员办公室等有人长期工作的房间面积，可按5～7m2／人计算。

四、机房设备布置相关标准

主机房内通道与设备间的距离应符合下列规定：
	1、用于搬运设备的通道净宽不应小于1．5m；
	2、面对面布置的机柜或机架正面之间的距离不宜小于1．2m；
	3、背对背布置的机柜或机架背面之间的距离不宜小于lm；
	4、当需要在机柜侧面维修测试时，机柜与机柜、机柜与墙之间的距离不宜小于1．2m；
	5、成行排列的机柜，其长度超过6m时，两端应设有出口通道；当两个出口通道之间的距离超过15m时，在两个出口通道之间还应增加出口通道。出口通道的宽度不宜小于lm，局部可为0．8m。

五、机房建筑与结构相关标准

1、主机房净高应根据机柜高度及通风要求确定，且不宜小于2．6m。

2、人流、物流及出入口

①主机房宜设置单独出入口，当与其他功能用房共用出入口时，应避免人流和物流的交叉。
②有人操作区域和无人操作区域宜分开布置。
③电子信息系统机房内通道的宽度及门的尺寸应满足设备和材料的运输要求，建筑入口至主机房的通道净宽不应小于1．5m。
④电子信息系统机房可设置门厅、休息室、值班室和更衣间。

3、电子信息系统机房的耐火等级不应低于二级。

在主机房与其他部位之间应设置耐火极限不低于2h的隔墙，隔墙上的门应采用甲级防火门。面积大于100m的主机房，安全出口不应少于两个，且应分散布置。面积不大于100m的主机房，可设置一个安全出口，并可通过其他相邻房间的门进行疏散。门应向疏散方向开启，且应自动关闭，并应保证在任何情况下均能从机房内开启。走廊、楼梯间应畅通，并应有明显的疏散指示标志。

4、A级B级电子信息系统机房的主机房不宜设置外窗。当主机房设有外窗时，应采用双层固定窗，并应有良好的气密性，不间断电源系统的电池室设有外窗时，应避免阳光直射。

5、电子信息系统机房内的照明线路宜穿钢管暗敷或在吊顶内穿钢管明敷。

6、电子信息系统机房内所有设备可导电金属外壳、各类金属管道、金属线槽、建筑物金属结构等必须进行等电位连接并接地；

六、机房建筑与结构相关标准

一、主机房地面设计应满足使用功能要求，当铺设防静电活动地板时，活动地板的高度应根据电缆布线和空调送风要求确定，并应符合下列规定：

1、活动地板下的空间只作为电缆布线使用时，地板高度不宜小于250mm；活动地板下的地面和四壁装饰，可采用水泥砂浆抹灰；地面材料应平整、耐磨；
2、活动地板下的空间既作为电缆布线，又作为空调静压箱时，地板高度不宜小于400ram；活动地板下的地面和四壁装饰应采用不起尘、不易积灰、易于清洁的材料；楼板或地面应采取保温、防潮措施，地面垫层宜配筋，维护结构宜采取防结露措施。

二、技术夹层的墙壁和顶棚表面应平整、光滑。当采用轻质构造顶棚做技术夹层时，宜设置检修通道或检修口。
三、A级和B级电子信息系统机房的主机房不宜设置外窗。

七、机房空调系统的新风量相关标准

一、空调系统的新风量应取下列两项中的最大值：

1、按工作人员计算，每人40m3／h；
2、维持室内正压所需风量。

二、空调系统无备份设备时，单台空调制冷设备的制冷能力应留有15％~20％的余量。

八、机房防雷与接地相关标准

1、电子信息系统机房内的电子信息设备应进行等电位联结，等电位联结方式应根据电子信息设备易受干扰的频率及电子信息系统机房的等级和规模确定，可采用S型、M型或SM混合型。采用M型或SM混合型等电位联结方式时，主机房应设置等电位联结网格，网格四周应设置等电位联结带，并应通过等电位联结导体将等电位联结带就近与接地汇流排、各类金属管道、金属线槽、建筑物金属结构等进行连接。每台电子信息设备（机柜）应采用两根不同长度的等电位联结导体就近与等电位联结网格连接。

2、等电位联结网格应采用截面积不小于25mm2的铜带或裸铜线，并应在防静电活动地板下构成边长为0.6～3m的矩形网格。

3、四种接地方式：

交流工作接地,接地电阻不大于4欧；
安全保护接地,接地电阻不大于4欧；
直流工作接地,接地电阻不大于1欧；
防雷接地,接地电阻不大于10欧；

口诀：一直交四个女友十分雷人！！！

九、机房电磁屏蔽相关标准

1、对涉及国家秘密或企业对商业信息有保密要求的电子信息系统机房，应设置电磁屏蔽室或采取其他电磁泄漏防护措施，电磁屏蔽室的性能指标应按国家现行有关标准执行。

2、在设计屏蔽机房时候我们需要注意：

（1）屏蔽门、滤波器、波导管、截止波导通风窗等屏蔽件，其性能指标不应低于电磁屏蔽室的性能要求，安装位置应便于检修。
（2）屏蔽门可分为旋转式和移动式。一般情况下，宜采用旋转式屏蔽门。当场地条件受到限制时，可采用移动式屏蔽门。

3、所有进入电磁屏蔽室的电源线缆应通过电源滤波器进行处理。电源滤波器的规格、供电方式和数量应根据电磁屏蔽室内设备的用电情况确定。

4、所有进入电磁屏蔽室的信号电缆应通过信号滤波器或进行其他屏蔽处理。

5、进出电磁屏蔽室的网络线宜采用光缆或屏蔽缆线，光缆不应带有金属加强芯。

6、截止波导通风窗内的波导管宜采用等边六角形，通风窗的截面积应根据室内换气次数进行计算。

7、非金属材料穿过屏蔽层时应采用波导管，波导管的截面尺寸和长度应满足电磁屏蔽的性能要求。

8、用于保密的的电磁屏蔽室，其结构形式分为可拆卸式和焊接式。焊接式又可分为自撑式和直贴式。建筑面积小于50平米，日后需搬迁的电磁屏蔽室，结构形式宜采用可拆卸式。电场屏蔽衰减指标要求大于120dB、建筑面积大于50平米的屏蔽室，结构形式宜采用自撑式。电场屏蔽衰减指标要求大于60dB的屏蔽室，结构宜采用直贴式，屏蔽材料可选择镀锌钢板，钢板的厚度根据屏蔽性能指标确定。电场屏蔽衰减指标要求大于25dB的屏蔽室，结构宜采用直贴式，屏蔽材料可选择金属丝网，金属丝网的目数应根据被屏蔽信号的波长确定。

十、双绞线的制作

1）直连线（直通线）：用于连接非同种设备（如网卡和集线器、电脑和交换机等），直连线两端均按EIA/TIA568A线序，或者均按EIA/TIA568B线序。

2）反跳线（交叉线）：用于连接同种设备（如网卡之间），交叉线的一端按EIA/TIA568A线序，另一端按EIA/TIA568B线序。

十一、机房的温、湿度