免费智能真题库 > 历年试卷 > 信息系统监理师 > 2017年下半年 信息系统监理师 下午试卷 案例
  第2题      
  知识点：   承建单位   监理单位   建设单位   交换机   项目验收   验收报告   验收测试   验收委员会   综合布线系统   测试过程   测试内容   调试   评审   损坏   维护   项目管理   政府   综合布线

 
【说明】
北京市X区政府拟建设一套综合性政务公开系统，向公众展示各部门政策发布及政务进展。该项目由系统集成公司A负责实施，信息系统监理公司B负责监理。该系统在整个建设过程中，发生如下事件：
【事件1】实施人员在综合布线系统完成后，立即进行网络系统相连通电及调试，致使核心交换机被损坏。公司A项目管理人员已承担责任并及时更换了该设备，并希望现场监理不要报告业主，以维护承建单位和监理单位的信誉。监理出于多方考虑，接受了公司A的建议。
【事件2】项目验收前，建设单位成立了验收委员会，任命区政府办公室主任张工担任验收委员会主任。验收过程中，将验收内容记录在了验收报告中，并由张工在验收报告上代表验收委员会进行了签字，证明验收内容属实，最后将验收报告交由X区区长决定是否通过验收。
【事件3】验收委员会委托验收测试组依据合同进行验收测试过程中，业主要求临时增加一些测试内容，验收测试组拒绝了业主要求。测试合格后，验收委员会决定召开评审会，进行综合评价。
 
问题：2.1   （5分）
对于事件1，针对网络系统安装调试时出现的问题，请分别指出承建方和监理方存在的问题。
 
问题：2.2   （3分）
对于事件2，请指出其中的不适当之处。
 
问题：2.3   （7分）
（1）对于事件3，针对业主提出的测试内容，验收测试组的做法是否正确？请说明原因。
（2）请说明验收过程的工作步骤。
 
 
 

   知识点讲解    
   · 承建单位    · 监理单位    · 建设单位    · 交换机    · 项目验收    · 验收报告    · 验收测试    · 验收委员会    · 综合布线系统    · 测试过程    · 测试内容    · 调试    · 评审    · 损坏    · 维护    · 项目管理    · 政府    · 综合布线
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。
 
       监理单位
        项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。
        根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。
        （1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。
        （2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。
        （3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
        监理单位的主要作用如下。
        （1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。
        （2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。
        （3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。
 
       建设单位
        建设方是建设项目的主要投资者，有时也是项目的最终使用者，是在工程建设阶段的全权代表，建设项目的经济效益，如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体，但由于建设方是投资方，掌握着项目的最终资源——决定了其他方为从属地位，所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人，建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急，组织协调参与各方为此目标而通力合作，在管理决策过程中做出决策。但在某些具体的项目管理事务中，建设方并不总是处于主要负责人的地位，还要作为裁判、支持者、服务员及督促员的角色。
 
       交换机
        交换机也称为交换器。一台具有基本功能的以太网交换机的工作原理相当于一个具有很多个端口的多端口网桥，即是一种在LAN中互联多个网段，并可进行数据链路层和物理层协议换的网络互联设备。当一个以太网的信息帧到达交换机的一个端口时，交换机根据在该帧内的目的地址，采用快速技术把该帧迅速地转发到另一个相应的端口（相应的主机或网段）。目前在以太网交换机中最常用的高速切换技术有直通式和存储转发式两类。
        交换机可以分为二层交换机、三层交换机和多层交换机。二层交换机工作在数据链路层，起到多端口网桥的作用，主要用于局域网互联。三层交换机工作在网络层，利用IP地址进行交换，相当于带路由功能的二层交换机。多层交换机工作在高层（传输层以上），这是带协议转换的交换机。
 
       项目验收
        信息应用系统验收需由建设单位组织，监理辅助和承建单位配合。建设单位的工作主要是审核承建单位的验收方案并确定验收方案，承建单位的工作主要是内部测试准备、验收准备工作、验收申请提交和验收方案准备。监理的工作重点是软件配置审核和验收测试，具体分为文档审核、源代码审核、配置脚本审核、测试程序或脚本审核和可执行程序测试。
        信息应用系统验收的过程与信息网络系统的验收过程是一致的，其基本步骤为提出验收申请、制订验收计划、成立验收委员会、进行验收测试和配置审计、进行验收评审、形成验收报告并移交产品。验收的地点及条件要符合合同或验收方案的规定。
               验收委员会
               在信息应用系统验收阶段，验收委员会人数为不少于5人的单数，验收委员会的任务及其权限如下。
               （1）判定所验收的软件是否符合合同要求。
               （2）审定验收环境。
               （3）审定验收测试计划。
               （4）组织验收测试和配置审核，进行验收评审，并形成验收报告。
               验收的原则
               信息应用系统的验收，要遵循以下基本原则。
               （1）验收测试和配置审核是验收评审前必须完成的两项主要检查工作，由验收委员会主持。
               （2）测试组在认真审查需求规格说明、确认测试和系统测试的计划与分析结论的基础上制订验收测试计划。
               （3）配置审核组在需求规格说明、确认测试和系统测试等过程中形成的产品的变更管理及审核工作的基础上开展审计。
               （4）原有测试和审核结果凡可用的就可用，不必重做该项测试或审核。同时，可根据建设单位的要求临时增加一些测试和审核内容。
               （5）测试组在完成测试验收的同时，完成功能配置审核，即验证软件功能和接口与“合同”的一致性。
               （6）配置审核组完成物理配置审核，检查程序和文档的一致性、文档和文档的一致性、交付的产品与“合同”要求的一致性及符合有关标准的情况。
               验收的准则
               信息应用系统验收的准则如下。
               （1）软件产品符合“合同”或“验收标准”规定的全部功能和质量要求。
               （2）不同安全性关键等级的软件均通过了《软件测试细则》文档要求的各项测试。
               （3）文档齐全，符合“合同”或“验收标准”的要求及有关标准的规定。
               （4）文档和文档一致，同时程序和文档相符。
               （5）对被验收软件的可执行代码，在验收测试中查出的错误总数，以及错误严重性不超过建设单位事先约定的限制值。
               （6）配置审核时查出的交付文档中的错误总数不超过建设单位事先约定的限制值。
               验收报告
               验收报告的主要内容包括验收的各项内容、评价与验收结论、验收委员会全体成员签字及验收委员会主任的意见。
               如果验收未通过，则需要重新验收或进入合同争议。如果验收通过，则监理需要审查承建单位的项目资料清单、协助建设单位和承建单位交接项目资料、确保软件文档和软件的一致性，同时将开发软件做好备份，保管在安全的地方，文件材料归档。
 
       验收报告
        验收报告的主要内容包括验收的各项内容、评价与验收结论、验收委员会全体成员签字及验收委员会主任的意见。
        如果验收未通过，则需要重新验收或进入合同争议。如果验收通过，则监理需要审查承建单位的项目资料清单、协助建设单位和承建单位交接项目资料、确保软件文档和软件的一致性，同时将开发软件做好备份，保管在安全的地方，文件材料归档。
 
       验收测试
        验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
        验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
               验收测试的常用策略
               验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
                      正式验收测试
                      正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
                      在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .测试的细节是已知的，并且可以对其进行评测。
                      .这种测试可以自动执行，支持回归测试。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      缺点包括：
                      .要求大量的资源和计划。
                      .这些测试可能是系统测试的再次实施。
                      .可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
                      非正式验收测试
                      在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
                      大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      .与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
                      缺点包括：
                      .要求资源、计划和管理资源。
                      .无法控制所使用的测试用例。
                      .最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
                      .最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
                      .用于验收测试的资源不受项目的控制，并且可能受到压缩。
               验收测试的条件
               在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
               （1）软件开发已经完成，并全部解决了已知的软件缺陷。
               （2）验收测试计划已经过评审和批准，并且置于文档控制之下。
               （3）对软件需求说明书的审查已经完成。
               （4）对概要设计及详细设计的审查已经完成。
               （5）对所有关键模块的代码审查已经完成。
               （6）对单元、集成、系统测试计划和报告的审查已经完成。
               （7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
               （8）使用配置管理工具且代码置于配置控制之下。
               （9）软件问题处理流程已经就绪。
               （10）已经制定、评审并批准验收测试完成标准。
               验收测试的过程
               （1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
               （2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
               （3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
               （4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
               （5）测试实施：测试并记录测试结果。
               （6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
               （7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
               软件配置审核
               软件配置审核包括审查和审核。
               审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
               通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
               对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
               可执行程序的测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
               不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
               验收测试的内容
               具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
               如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
 
       验收委员会
        在信息应用系统验收阶段，验收委员会人数为不少于5人的单数，验收委员会的任务及其权限如下。
        （1）判定所验收的软件是否符合合同要求。
        （2）审定验收环境。
        （3）审定验收测试计划。
        （4）组织验收测试和配置审核，进行验收评审，并形成验收报告。
 
       综合布线系统
        综合布线系统（Premises Distributed System，PDS）是一种集成化通用传输系统，是在楼宇和园区范围内，利用双绞线或光缆来传输信息，可以连接电话、计算机、会议电视和监视电视等设备的结构化信息传输系统。
        综合布线系统使用标准的双绞线和光纤，支持高速率的数据传输。这种系统使用物理分层星型拓扑结构，积木式、模块化设计，遵循统一标准，使系统的集中管理成为可能，也使每个信息点的故障、改动或增删不影响其他的信息点，使安装、维护、升级和扩展都非常方便，并节省了费用。
        综合布线系统可分为6个独立的系统（模块），如下图所示。
        
        综合布线系统
        （1）工作区子系统。工作区子系统由终端设备连接到信息插座之间的设备组成，包括信息插座、插座盒、连接跳线和适配器。
        （2）水平区子系统（水平干线子系统、水平子系统）。水平区子系统应由工作区用的信息插座，以及楼层分配线设备至信息插座的水平电缆、楼层配线设备和跳线等组成。一般情况下，水平电缆应采用4对双绞线电缆。在水平子系统有高速率应用的场合，应采用光缆，即光纤到桌面。水平子系统根据整个综合布线系统的要求，应在二级交接间、交接间或设备间的配线设备上进行连接，以构成电话、数据、电视系统和监视系统，并方便进行管理。
        （3）管理间子系统。管理间子系统设置在楼层分配线设备的房间内。管理间子系统应由交接间的配线设备，以及输入输出设备等组成，也可应用于设备间子系统中。管理间子系统应采用单点管理双交接。交接场的结构取决于工作区、综合布线系统规模和所选用的硬件。在管理规模大、复杂、有二级交接间时才设置双点管理双交接。在管理点，应根据应用环境用标记插入条来标出各个端接场。
        （4）垂直干线子系统（垂直子系统、干线子系统）。通常是由主设备间（如计算机房、程控交换机房）提供建筑中最重要的铜线或光纤线主干线路，是整个大楼的信息交通枢纽。一般它提供位于不同楼层的设备间和布线框间的多条连接路径，也可连接单层楼的大片地区。
        （5）设备间子系统。设备间是在每一幢大楼的适当地点设置进线设备，进行网络管理及管理人员值班的场所。设备间子系统应由综合布线系统的建筑物进线设备、电话、数据、计算机和不间断电源等各种主机设备及其保安配线设备等组成。
        （6）建筑群子系统（楼宇子系统）。建筑群子系统将一栋建筑的线缆延伸到建筑群内的其他建筑的通信设备和设施。它包括铜线、光纤，以及防止其他建筑电缆的浪涌电压进入本建筑的保护设备。在设计建筑群子系统时，应考虑地下管道铺设的问题。
        在综合布线系统的技术指标和质量参数方面，要遵循《综合布线系统工程设计规范》（GB50311—2007）和《综合布线系统工程验收规范》（GB50312—2007）的要求。考生要熟记这两个规范里的技术要求和参数。软考在线软考学院（www.csairk.com）的法律法规栏目有该规范的完整文本，在此不再转载。
 
       测试过程
        软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：
               （1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。
               （2）确定每个测试项的优先级。
               （3）确定每个测试项的测试充分性要求。
               （4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。
               （5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。
               （6）确定测试项与软件需求规格说明或设计文档的追踪关系。
               将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。
               应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：
               （1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。
               （2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。
               （3）测试类型和测试项是否充分。
               （4）测试项是否包括了终止要求。
               （5）文档是否符合规定的要求。
               测试策划
               根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：
               （1）确定测试策略，如部件或配置项测试策略。
               （2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。
               （3）确定要受控制的测试工作产品，列出清单。
               （4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。
               （5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。
               （6）确定测试任务的结束条件。
               （7）确定被测软件的评价准则和方法。
               （8）确定测试活动的进度。应根据测试资源和测试项，确定进度。
               应将测试策划结果，按所确定的文档要求形成测试计划。
               测试设计和实现
               应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：
               （1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。
               （2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。
               （3）设计测试用例。
               （4）确定测试用例的执行顺序。
               （5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。
               （6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。
               （7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。
               （8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。
               应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：
               （1）测试名称和项目标识。
               （2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。
               （3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。
               （4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。
               （5）测试用例的输入。每个测试用例输入的描述中应包括的内容：
               ①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。
               ②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。
               ③测试输入是真实的还是模拟的。
               ④测试输入的时间顺序或事件顺序。
               （6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。
               （7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：
               ①实际测试结果所需的精确度。
               ②允许的实际测试结果与期望结果之间差异的上、下限。
               ③时间的最大或最小间隔。
               ④事件数目的最大或最小值。
               ⑤实际测试结果不确定时，重新测试的条件。
               ⑥与产生测试结果有关的出错处理。
               ⑦其他有关准则。
               （8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：
               ①每一步所需的测试操作动作、测试程序输入或设备操作等。
               ②每一步期望的测试结果。
               ③每一步的评估准则。
               ④导致被测程序执行终止伴随的动作或指示信息。
               ⑤需要时，获取和分析中间结果的方法。
               （9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。
               （10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。
               （11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。
               （12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：
               ①测试说明是否完整、正确和规范。
               ②测试设计是否完整和合理。
               ③测试用例是否可行和充分。
               测试执行
               应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：
               如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。
               （1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。
               （2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。
               （3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：
               ①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。
               ②对被测软件的缺陷应记录到软件问题报告中。
               ③软件问题报告的格式应规范。
               （4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：
               ①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。
               ②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。
               测试总结
               应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：
               （1）对测试工作进行分析和评价，分析和评价内容应包括：
               ①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。
               ②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。
               ③确定无法解决的软件测试事件并说明不能解决的理由。
               （2）对被测软件进行分析和评价，分析和评价内容应包括：
               ①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。
               ②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。
               ③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。
               （3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。
               （4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。
               测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：
               （1）审查测试文档与记录内容的完整性、正确性和规范性。
               （2）审查测试活动的独立性和有效性。
               （3）审查测试环境是否符合测试要求。
               （4）审查软件测试报告与软件测试原始记录和问题报告的一致性。
               （5）审查实际测试过程与测试计划和测试说明的一致性。
               （6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。
               （7）审查测试结果的真实性和正确性。
 
       测试内容
        由于每种测试所花费的成本不同，如果测试步骤安排得不合理，将会造成为了寻找错误原因而浪费大量的时间以及重复测试的情况。因此，合理安排测试步骤对于提高测试效率和降低测试成本有很大的作用，信息系统测试分别按硬件系统、网络系统和软件系统进行测试，最后对整个系统进行总的综合测试。
        （1）硬件测试。
        在进行信息系统开发中，通常需要根据项目的情况选购硬件设备。在设备到货后，应在各个相关厂商配合下进行初验测试，初验通过后将硬件与软件、网络等一起进行系统测试。初验测试所做的工作主要如下。
        .配置检测，检测是否按合同提供了相应的配置，如系统软件、硬盘、内存、CPU等的配置情况。
        .硬件设备的外观检查，所有设备及配件开箱后，外观有无明显划痕和损伤。这些包括计算机主机、工作站、磁带库、磁盘机柜和存储设备等。
        .硬件测试，首先进行加电检测，观看运行状态是否正常，有无报警、屏幕有无乱码提示和死机现象，是否能进入正常提示状态。然后进行操作检测，用一些常用的命令来检测机器是否能执行命令，结果是否正常。例如，文件复制、显示文件内容、建立目录等。最后检查是否提供了相关的工具，如帮助系统、系统管理工具等。
        通过以上测试，要求形成相应的硬件测试报告，在测试报告中包含测试步骤、测试过程和测试的结论等。
        （2）网络测试。
        如果信息系统不是单机，需要在局域网或广域网运行，按合同会选购网络设备。在网络设备到货后，应在各个相关厂商配合下进行初验测试。初验通过后网络将与软件、硬件等一起进行系统测试。初验测试所做的工作主要如下。
        .网络设备的外观检查，所有设备及配件开箱后，外观有无明显划痕和损伤，这些包括交换机、路由器等。
        .硬件测试，进行加电检测，观看交换机、路由器等工作状态是否正常，有无错误和报警。
        .网络连通测试，检测网络是否连通，可以用ping、 telnet、 ftp等命令来检查。
        通过以上测试，要求形成相应的网络测试报告，在测试报告中包含测试步骤、测试过程和测试的结论等。
        （3）软件测试。
        软件测试实际上分成4步：单元测试、组装测试、确认测试和系统测试，它们将按顺序进行。首先是单元测试（Unit Testing），对源程序中的每一个程序单元进行测试，验证每个模块是否满足系统设计说明书的要求。组装测试（Integration Testing）是将已测试过的模块组合成子系统，重点测试各模块之间的接口和联系。确认测试（Validation Testing）是对整个软件进行验收，根据系统分析说明书来考察软件是否满足要求。系统测试（System Testing）是将软件、硬件、网络等系统的各个部分连接起来，对整个系统进行总的功能、性能等方面的测试。
        下面将分别对单元测试、组装测试、确认测试和系统测试的内容和要求加以说明。
 
       调试
        调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。
 
       评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
 
       损坏
        损坏包括：自然灾害（比如，地震、火灾、洪灾）、物理损坏（比如，硬盘损坏、设备使用寿命到期、外力破损等）、设备故障（比如，停电断电、电磁干扰等），等等。
        介质库必须符合防火、防水、防震、防潮、防腐蚀、防鼠害、防虫蛀、防静电何妨电磁辐射的安全要求。一、二、三类介质应有多份备份和进行异地存储。介质库应设立库管理员，负责库的管理工作，并将核查使用人员的身份与权限。介质库内的所有介质应当被统一编目、集中分类管理。
        解决由于自然的或人为的灾难（包括系统硬件、网络故障以及机房断电甚至火灾、地震等情况）导致的计算机系统数据灾难，避免单点故障的出现，这主要是利用冗余硬件设备保护用户I T环境内的某个服务器或是网络设备，备份中心应该考虑到应用、数据和操作系统各级的保护。
        常规采用的数据备份容易造成备份的数据与数据库中的数据不一致，使数据库很难恢复。而且，恢复通过磁带备份的数据，需要三天到一个星期的时间，在这阶段，业务将处在停滞状态。同时，由于备份介质与生产系统之间的在线交易在物理上不好分开，所以在机房发生危险（如火灾、水灾以及其他的灾难性事件）时，数据丢失可能会导致业务瘫痪。因而迫切需要解决的问题是：对关键应用来说，如何能保证数据的安全性，以产生抵御灾难性的能力。随着环境的变化，灾难事件的增多，不能将对数据的依赖建立在可能不会出现灾难这样的赌注上，关键业务需要容灾。
        因此异地容灾已成为数据可用性解决方案的重要组成部分。异地容灾系统提供了一个远程的应用备份现场，能防止因本地毁灭性灾难（地震、火灾、水灾等）引起的数据丢失。容灾方案的核心是两个关键技术：数据容灾（即数据复制）和应用的远程切换（即发生灾难时，应用可以很快地在异地切换）。其中，数据容灾与应用切换不能截然分开，应用切换应该以数据容灾为基础。我们建议在以后的日子中可以考虑异地容灾。
 
       维护
        维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
 
       项目管理
        构建嵌入式系统是一项复杂的任务，尤其是涉及到很多人员共同长期工作的时候。为了使嵌入式项目开发获得成功，必须对系统开发项目的工作范围、花费的工作量（成本）、可能遇到的风险、进度的安排、要实现的任务、经历的里程碑以及需要的资源（人、硬／软件）等做到心中有数，而项目管理可以提供这些信息。项目管理的过程一般包括初启、计划、执行、监控、结项，项目管理的范围覆盖整个系统生命周期过程。
               管理范围
               有效的项目管理集中于4P，即人员（People）、产品（Product）、过程（Process）和项目（Project）。必须将人员组织起来以有效地完成产品构建工作；必须和客户及其他利益相关者很好地沟通，以便了解产品的范围和需求；必须选择适合于人员和产品的过程；必须估算完成工作任务的工作量和工作时间，从而制订项目计划。
               “人的因素”非常重要，在所有项目中，最关键的因素是人员，涉及项目管理人员、高级管理人员、开发人员、客户和最终用户。人员能力成熟度模型（People Capability Maturity Model，PCMM）针对人员定义了以下关键实践域：人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展以及团队精神或企业文化培育等。PCMM成熟度达到较高水平的组织，更有可能实现有效的项目管理事件。
               在制订项目计划之前，首先确定产品的目标和范围，考虑可选的解决方案，识别技术和管理上的限制。如果没有这些信息，就无法进行合理（精确）的成本估算，也无法进行有效的风险评估和适当的项目任务划分，更无法制定可管理的项目进度计划来给出意义明确的项目进展标志。确定产品的目标只是识别出产品的总体目标，而不用考虑如何实现这些目标。确定产品的范围是识别出产品的主要数据、功能和行为特性，并且应该用量化的方式界定这些特性。然后开始考虑备选解决方案，不讨论细节，使管理者与参与开发的人员根据特定的约束条件选择相对最佳的方案，约束条件有产品的交付期限、预算限制、可用人员、技术接口以及其他各种因素。
               开发过程提供了一个框架，一小部分框架活动适用于所有的项目，多种不同的任务集合使得框架活动适合于不同项目的特性和项目团队的需求。普适性活动（如质量管理、配置管理、测量等）覆盖了过程模型，独立于任何一个框架活动，且贯穿于整个过程之中。
               为了成功地管理项目，需要有计划、可控制，这样才能管理复杂的系统开发；需要了解可能会出现的各类问题以便加以避免。可以采用的方法有：
               （1）在正确的基础上开始工作。
               （2）保持动力。
               （3）跟踪进度。
               （4）做出正确的决策。
               （5）进行事后分析。
               成本估算
               系统开发成本估算主要指系统开发过程中所花费的工作量及相应的代价。为了使开发项目能够在规定的时间内完成，而且不超过预算，成本预算和管理控制是关键。项目开发成本的估算主要靠分解和类推的手段进行。分解技术是将项目分解成一系列较小的、容易理解的问题进行估算。常用的分解技术有：基于问题的估算、基于代码行（LOC）估算、基于功能点（FP）的估算、基于过程的估算、基于用例的估算。选择或结合使用分解技术，进行成本估算。基本的成本估算方法有如下几种。
               （1）自顶向下估算方法。估算人员参照以前完成的项目所耗费的总成本（或总工作量）来推算将要开发的系统的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配。
               自顶向下估算方法的主要优点是对系统级工作的重视，所以估算中不会遗漏集成、配置管理等系统级事务的成本估算，且估算工作量小、速度快。其缺点是不清楚低级别上的技术性困难，而这些困难将会使成本上升。
               （2）自底向上估算方法。自底向上估算方法是将待开发的系统细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到系统的总开发量。这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做，所以估算较为准确。其缺点是缺少对各项子任务之间相互联系所需要工作量和与开发有关的系统级工作量的估算，因此预算往往偏低。
               （3）差别估算方法。差别估算方法是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。该方法的优点是可以提高估算的准确度，缺点是不容易明确“差别”的界限。
               除以上方法外，还有许多方法，大致可分为三类：专家估算法、类推估算法和算式估算法。
               （1）专家估算法。该方法依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
               （2）类推估算法。在自顶向下的方法中，它是将估算项目的总体参数与类似项目进行直接比较得到结果；在自底向上方法中，类推是在两个具有相似条件的工作单元之间进行。
               （3）算式估算法。专家估算法和类推估算法的缺点在于它们依靠带有一定盲目性和主观性的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响，用于估算的方法有两种基本类型：由理论导出和由经验导出。
               典型的成本估算模型主要有动态多变量普特南（Putnam）模型和层次结构的结构性成本模型（Constructive Cost Model，COCOMO）的升级模型COCOMOII等。普特南模型基于软件方程，它假设在软件开发的整个生命周期中有特定的工作量分布。COCOMOII模型层次结构中有三种不同的估算选择：对象点、功能点和源代码行。
               风险分析
               新的系统建立时，总是存在某些不确定性。例如，用户要求是否能确切地被理解？在项目最后结束之前要求实现的功能能否建立？是否存在目前仍未发现的技术难题？在项目出现严重延期时是否会发生一些变更？等等。风险是潜在的，需要识别、评估发生的概率、估算其影响、并制定实际发生时的应急计划。
               风险分析在项目管理中具有决定性作用。当在软件工程的环境中考虑风险时，主要关注以下三个方面。一是关心未来。风险是否会导致项目失败；二是关心变化。用户需求、开发技术、目标机器以及所有其他与项目有关的实体会发生什么变化；三是必须解决需要做出选择的问题，即应当采用什么方法和工具，应当配备多少人力，在质量上强调到什么程度才满足要求等。
               风险分析实际上是贯穿软件工程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。
               进度管理
               进度安排包括把一个项目所有的工作分解为若干个独立的活动，并描述这些活动之间的依赖关系，估算完成这些活动所需的工作量，分配人力和其他资源，制定进度时序。进度的合理安排是如期完成软件项目的重要保证，也是合理分配资源的重要依据，因此进度安排是管理工作的一个重要组成部分。有两种安排软件开发项目进度的方式：
               （1）系统最终交付日期已经确定，系统开发部门必须在规定期限内完成；
               （2）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。
               进度安排的常用图形描述方法有Gantt图（甘特图）和PERT（Program Evaluation&Review Technique，项目计划评审技术）图。
               （1）Gantt图。Gantt图中横坐标表示时间（如时、天、周、月、年等），纵坐标表示任务，图中的水平线段表示一个任务的进度安排，线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间，线段的长度表示完成该任务所持续的时间。当日历中同一时段中存在多个水平条时，表示任务之间的并发。下图所示的Gantt图描述了三个任务的进度安排。该图表示：任务1首先开始，完成它需要12周时间；任务2在2周后开始，完成它需要18周；任务3在12周后开始，完成它需要10周。
               
               Gantt图实例
               Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性；但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。
               （2）PERT图。PERT图是一个有向图，其基本符号如下图所示。
               
               PERT图的基本符号
               PERT图中的有向弧表示任务，可以标上完成该任务所需的时间，图中的结点表示流入结点的任务已结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。每个事件有一个事件号及出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始；最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有一个松弛时间（slack time），表示在不影响整个工期的前提下，完成该任务有多少机动时间。为了表示任务间的关系，图中还可以加入一些空任务（用虚线有向弧表示），完成空任务的时间为0。
               PERT图的一个实例如下图所示，该图所表示的工程可分为12个任务，事件号1表示工程开始，事件号11表示工程结束（完成所有任务需要23个时间单位）。松弛时间为0的任务构成了完成整个工程的关键任务，其事件流为1→2→3→4→6→8→10→11，也就是说，这些任务不能拖延，否则整个工程就不能在23个时间单位内完成。
               
               PERT图示例
               PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，还可以找出如期完成整个工程的关键任务。任务的松弛时间则反映了完成任务时可以推迟其开始时间或延长其所需完成的时间。PERT图不能反映任务之间的并行关系。
 
       政府
        政府信息系统以电子政务为主要形式，是指政府机构在其管理和服务职能中运用现代网络技术打破传统行政机关的时间、空间和部门分隔的制约，使各级政府的各项监管更加严密，服务更加便捷，涉及政府机关、各团体、企业和社会公众，主要包括机关办公政务网、办公政务资源网、公众信息网和办公政务信息资源数据库几个部分。
        （1）安全级别高。政务信息数据中，有些关乎国家、政府部门、地方政策和利益，比个人或商务信息更为敏感；有些属于大规模的基础设施，比如档案、城建数据；有些具有服务特性，比如医保、社保、公积金、房屋交易等信息；加之电子政务行使政府职能的特点易导致政府信息系统受到各种攻击，包括黑客组织、犯罪集团和信息战时期的信息对抗等国家行为的攻击，因此，其安全问题尤其是数据安全应被重点关注。
        （2）业务的不间断运维需求高。政府信息系统面向社会提供外部服务，如出入境审批系统、身份证申领系统等，都必须在故障出现后以最短的时间恢复业务运行，否则导致业务受理停止，大量人员等待，大量紧急任务无法处理，影响政府办事效率和形象。
        （3）例行运维亟须加强。我国政府部分信息系统存在管理松散，制度不严明，执行乏力现象，包括内部信息外泄，个人下载或运行游戏、炒股、聊天、视频软件，甚至非法修改IP地址，卸载杀毒软件，不仅严重违反纪律，更易影响到关键应用的性能质量，因此，日常运维管理亟须加强。
 
       综合布线
        1．概念及相关标准
        综合布线系统（Premises Distribution System，PDS）是楼宇和园区范围内，在统一的传输介质上建立的可以连接电话、计算机、会议电视和监视电视等设备的结构化信息传输系统。
        目前在综合布线领域被广泛遵循的标准是EIA/TIA-568A。在此标准中把综合布线系统分为6个子系统：建筑群子系统、设备间子系统、垂直干线子系统、管理子系统、水平子系统和工作区子系统，如下图所示。
        
        EIA/TIA-568A标准中描述的综合布线系统
        各子系统的功能如下：
        .工作区子系统：实现工作区终端设备与水平子系统之间的连接，由终端设备连接到信息插座的连接线缆组成。工作区常用设备是计算机、网络集散器（Hub或Mau）、电话、报警探头、摄像机、监视器和音响等。
        .水平子系统：实现信息插座和管理子系统（跳线架）间的连接，将用户工作区引至管理子系统：系统中常用的传输介质是4对UTP（非屏蔽双绞线），它能支持大多数现代通信设备。如果需要某些宽带应用时，可以采用光缆。信息出口采用插孔为ISDN8芯（RJ45）的标准插口，每个信息插座都可灵活地运用，并根据实际应用要求可随意更改用途。
        .管理子系统：由交连、互连配线架组成。管理点为连接其他子系统提供连接手段。交连和互连允许将通信线路定位或重定位到建筑物的不同部分，以便能更容易地管理通信线路，使在移动终端设备时能方便地进行插拔。互连配线架根据不同的连接硬件分为楼层配线架（箱）IDF和总配线架（箱）MDF，IDF可安装在各楼层的干线接线间，MDF一般安装在设备机房。
        .垂直干线子系统：实现计算机设备、程控交换机（PBX）、控制中心与各管理子系统间的连接，是建筑物干线电缆的路由。该子系统通常是两个单元之间，特别是在位于中央点的公共系统设备处提供多个线路设施。系统由建筑物内所有的垂直干线多对数电缆及相关支撑硬件组成，以提供设备间总配线架与干线间楼层配线架之间的干线路由。常用介质是大对数双绞线电缆和光缆。
        .设备子系统：由设备间中的电缆、连接器和有关的支撑硬件组成，作用是将计算机、PBX、摄像头、监视器等弱电设备互连起来并连接到主配线架上。设备包括计算机系统、网络集线器（Hub）、网络交换机（Switch）、程控交换机（PBX）、音响输出设备、闭路电视控制装置和报警控制中心等。
        .建筑群子系统：将一个建筑物的电缆延伸到建筑群的另外一些建筑物中的通信设备和装置上，是结构化布线系统的一部分，支持提供楼群之间通信所需的硬件。它由电缆、光缆和入楼处的过流过压电气保护设备等相关硬件组成，常用介质是光缆。
        2．综合布线系统的范围
        综合布线的范围应根据建筑工程项目范围来定，主要有单幢建筑和建筑群体两种范围。
        .单幢建筑：一般是指在整幢建筑内部敷设的通信线路，还应包括引出建筑物的通信线路。
        .建筑群体：综合布线系统工程范围除包括每幢建筑内的通信线路外，还需包括各幢建筑之间相互连接的通信线路。
        上述范围是从基本建设和工程管理的要求考虑的，与今后的业务管理和维护职责等的划分范围有可能不同。因此，综合布线系统的具体范围应根据网络结构、设备布置和维护办法等因素来划分。
        3．综合布线系统的适用场合和服务对象
        综合布线系统的适用场合和服务对象有以下几类：
        .商业贸易类型：如商务贸易中心、金融机构、高级宾馆饭店、股票证券市场和高级商城大厦等高层建筑。
        .综合办公类型：如政府机关、群众团体、公司总部等办公大厦以及办公、贸易和商业兼有的综合业务楼和租赁大楼。
        .交通运输类型：如航空港、火车站、长途汽车客运枢纽站、江海港区城市公共交通指挥中心等。
        .新闻机构类型：如广播电台、电视台和新闻通信及报社业务楼等。
        .其他重要建筑类型：如医院、急救中心、科学研究机构、高等院校和工业企业及气象中心的高科技业务楼等。
   题号导航      2017年下半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第2题    在手机中做本题