数据更新维护方案

目录TOC\o"1-4"\h\z\u1 工程综述 图59所示〕着手，力争做到万无一失。图SEQ图\*ARABIC59空间数据库生产体系功能模型通信网络平安通信网络的平安与保密一般指：认同用户和对等实体鉴别：收发方均要已确认识别对方；存取控制：对网络用户的存取权限进行控制；数据完整性：防止数据被签收、替换、删除；加密：防止信息被截取后造成损失；防否认：收发双方要成认收到或发过数据；审计：集中登录用户的网上活动。容错：采用多路由选择、断点重发、节点双工等。在计算机网络中，最主要的平安机制就是数据保密、数据完整性、存取控制和数字签名。局域网的平安局域网属于内部网，其平安性主要表达在存取控制和用户身份识别上。一个局域网上的用户群是相对稳定和的，对每类用户可以授予不同的访问权限。用户可以本机登录也可以网络登录，本机登录的平安管理主要是操作系统的平安管理，下一节介绍，网络登录方式在此说明。网络的用户可以分为不同的级别：网络管理员分系统管理员、数据库管理员、超级用户、一般用户等。一般用户中又根据其工作性质分为研究开发组、数据采集组、产品分发组、财务管理组、行政办公组等。对于每类用户，系统资源中均有说明，哪些资源对于哪类用户有某种访问权限，这些资源包括存贮空间、软件、数据集、输出设备等。用户与这些资源之间的关系就是通过一个访问权限矩阵来实现的，具体的权限又分为完全控制、只读、只写、删除、读写等。在局域网中，数据的加密不是主要的问题。数字签名也不是至关重要的。城域网和广域网的平安城域网和广域网的平安有类似的要求。由于这类网络的用户群机动性大，而且在网络的结构和协议上也差异很大，所以在信息平安上有特殊的要求。信息在这类网络的传输往往要经过许多环节和路由，所以在网络协议上就要有平安保证。信息要加密后才能在网上传送，对用户要确定身份，还要求具有防否认的能力。这就要求采用必要的信息平安措施，即防火墙技术、包过滤技术、公开密钥传输和数字签名技术。用户的访问权限也要同局域网的情况一样进行严格控制。防火墙技术城域网和广域网或Extranet和Internet的常用平安措施就是防火墙〔Firewall〕。防火墙由滤波器和网关〔gateway〕组成。滤波器的作用是阻止某些类型的通信传输，而网关的作用是提供中继效劳，以补偿滤波器的效应。典型防火墙的配置是用两个网关，外部滤波器保护网关免受来自外部的攻击。内部滤波器对一系列中间网关进行防卫，这些滤波器都是为了防止外界的攻击。滤波可分为三类：分组滤波、应用级滤波和线路滤波。一般情况下，滤波器设置在本组织与外界之间，对于一些大的组织需要设置内部滤波器，将一些平安域和一般用户域隔离，也可对不同级别的平安域设置多个防火墙。分组滤波分组滤波器〔信息包过滤器〕能提供花费少而有用的网关平安，因为可以在已有的路由器中配置具有滤波功能的软件。分组滤波的工作原理是根据源地址和目的地址端口来决定分组是否要去掉。滤波功能发生在分组接收时或发送时，或者兼有，取决于不同的路由器类型。管理员设置可接收的机器和效劳的表，以及不可接收的机器和效劳的表。这种方法可方便地在主机或网络级来接收或拒绝分组，以实现分组滤波。很多先进的网关具有分组滤波功能。分组滤波的缺点是参加滤波后，使网关的效率降低。有些效劳在分组滤波环境中难以实现。应用级滤波应用级网关是防火墙设计的另一种极端，它不像通用的机制允许不同类型的通信流通，而是对每个应用采用专用的码。虽然这种方法看起来很浪费，但比别的方案平安得多，这种方法需要用户输入ID和口令，有时要用到IC卡〔智能卡〕。应用级网关的另一个优点是对某些环境十分关键。这些环境易于登记和控制所有输入和输出的通信，主要用于FTP文件传输和E－mail的收发方面。这种方法可以确保E－mail的唯一地址，也可以隐蔽内部机器的细节。应用级滤波只是为了防止外部攻击，往往无法防止内部人员对文件的检索。这种方法的缺点是对大局部的效劳提供者需要专门的用户程序或各种用户接口，一般只用于支持最重要的一些效劳。线路级滤波线路级滤波或回路级滤波可在两台电脑的传送层之间提供中断效劳。传送层的责任是保证“端对端”之间数据信息包的可靠传输。有时线路连接是自动进行的，有时需要指定目的地以供连接效劳，后一种方式需要在调用者和网关之间有一定协议，该协议描述所需目的地和效劳，以及网关返回的出错信号等，起一个代理〔proxy〕的作用。代理效劳〔proxy〕允许用户从单位防火墙的后面建立与外面网络的直接连接，从而对数据越界传输进行保护。防火墙的特性防火墙作为一种产品和技术，有多种方案可供选择，具体选什么样的方案要视要求而定。防火墙产品一般要具有下述功能：访问控制：用户在身份签定后，才能进入网络，访问控制表可以设定；身份签定：用户向系统说明自己的身份供系统签定，可用多种方法，比方一次性口令及智能卡密钥签定等。加密：应提供多种加密方案，如DES和RSA等。记录：应提供不间断的跟踪监听。管理和用户界面：供系统管理员操作和设置的图形化界面。协议和应用程序支持：支持多协议、多种程序。地址转换：可对IP地址进行扩展。透明性：对末端用户来讲，防火墙是透明的。病毒侦测：随时监测病毒的入侵。软件平安软件平安涉及信息存贮和处理状态的保护。无论是系统软件还是应用软件，都要求可靠和强壮。从信息之平安和保密角度考虑，软件平安主要有存取控制、信息流向控制、用户隔离及病毒预防等。一个计算机系统可以看成进程〔主体〕和资源〔客体〕的结合。在这种情况下，最根本的平安措施为存取控制。它是对程序执行期间使用资源合法性检查。利用对数据和程序读出、修改和删除的管理，存取控制能制止因技术事故和蓄谋作案构成对信息的威胁，以保护信息机密性、完整性和可用性。在操作系统控制下的存取控制机构，可以授予和撤消用户对各种客体的占有权，尤其是文件系统中广泛应用存取控制功能。在软件平安中采取隔离控制是常规手段。多道编程、多用户存取操作系统内广泛使用隔离手段。多用户系统各用户程序互相隔离、多虚拟机是指一台中央处理机内同时运行假设干不同操作系统，每个操作系统下又有假设干用户同时工作。它们是互相隔离的，以到达保护的目的。存取控制为保证计算机系统有序和有效操作，各进程要受资源管理策略的制约。存取控制为实施资源管理策略提供机构，策略可以经常改变，但是它并不要求实施策略的机构有所改变，而只要求对系统参数和表格进行修改。在设置存取控制机构时，要引入保护域的概念。一个保护域对应一个具体进程，其定义一个客体集和可在每个客体上实现存取权的类型。存取权可由三元组〔域、客体、权集〕有序级组成的存取矩阵表示。存取矩阵的一种表示形式为存取表，表内每一列对应一个客体，每个客体的存取表由二元组〔域、权集〕组成。这样每个客体均有其全部域，且无空权集出现。存取矩阵的另一种方式为权能表。假设存取矩阵的列和客体结合，行和域结合，那么构成一个域的权能表，它是允许在其上作存取操作的客体表。一个客体用其物理名或地址代表，称为一种权能。文件系统中，对文件存取不仅可置于文件，还可置于与文件树关联的各级目录。利用口令字可对文件起保护作用。隔离控制隔离的目的在于堵住平安上的漏洞。隔离法使操作系统内遭到破坏的局部不响其他局部。因多用户登录、编译、存取诸方面有多种要求，现代操作系统任务十分复杂。这种多种性和复杂度是造成系统崩溃和数据溢漏的根源，并构成对信息的破坏。防止这一现象的有效措施是将计算机硬件和软件分割成假设干互斥局部，每一局部自行执行任务，并与其他局部毫不相干，这就是隔离效果。隔离的一种实现方法是多虚拟机技术。每个用户组可有自己的操作系统，各虚拟机操作系统及其应用当作单独一个计算机系统分别运行。计算机病毒的危害起源于共享路径、信息流的传递和信息解释的通用性。把信息当作程序或数据并无本质上的区别。解释器被编辑的信息可作数据或程序解释。事实上只有在解释器解释下的信息才有意义。如果有信息共享路径，那么病毒会通过共享信息解释而扩散。如果信息流的传递并无限制，那么该信息可起源于任何点的信息流传递包。也就是说，信息共享、信息流传递和解释通用性都会使病毒到达起源于任何指定点的信息流传递包。信息完全隔离而无共享，那么谈不上通过域内信息传递。域外信息末予解释，也就不会有病毒传播到域外的条件发生。在病毒传染过程中，需要对被解释信息作修改，假设某系统内的程序不能改动，那么该系统不会染上病毒。隔离法是制止病毒传染的根本措施。对信息流传递渠道可有两种限制：一是在传递过程中把用户置于相应封闭子集内，到达隔离效果。二是把信息流动限制在多个分割域内，这样即使有病毒传染，每次也只限于一个分割域。这样可防止病毒在整个系统传染。平安操作系统软件平安的根本是对平安操作系统的要求和实现。这种系统靠建立平安核实现，其思想是将全部与平安有关的决策的操作系统权能均集中在一个小而全的保护域〔平安核〕内。其具有以下特征：完全：主体对客体的全部存取权均受平安检验；隔离：平安核代码受隔离保护，系统内任何其他软件不会对它干扰或修改；可信：实施平安权能为预料中的，不会伴生其它权能而构成威胁。数据库平安生产数据的平安数据在生产过程中要考虑平安措施。每个生产单位要设立一个系统管理员和数据管理员。或两项职责由一人兼任。数据的生产过程分为扫描数据〔源数据〕、处理过的数据〔如纠正、矢量化等〕、检查过的数据、入库前的数据等等。数据在各个生产过程中都要进行统一的管理与分发。每一份生产数据都要有备份。一般情况下，作业员一份，数据管理员一份。为了防止数据泄密，数据都通过网络传输，一般作业员的机器不带光驱和软驱。当要输出数据时，通过数据管理员。数据管理员对接收和分发的数据要进行登记。数据库平安根底地理信息和其他信息一样，在计算机中都是以文件或数据库关系表的方式来表示和存贮。文件系统可看作数据库系统的原始形式，其平安性能在前面讨论，这里仅对以数据库为环境的数据平安和保密作进一步讨论。数据库的平安建立在操作系统的平安之上，在网络化的地理信息生产体系中，数据可以分布在不同机器上，也可以集中到文件效劳器或数据效劳器中，前者要求分布式数据库，后者要求假设干客户／效劳器的数据库管理系统。数据库的特点是使得数据具有独立性，并且提供对完整性支持的并发控制、访问权限控制、数据的平安恢复等。针对数据平安，下面分别讨论：并发控制、存取控制和备份恢复技术。并发控制数据库的完整性可以归纳为语义的完整性、运行的完整性的恢复问题。运行的完整性即并发性事务处理的控制〔并发控制〕。数据完整受损主要是出错所致，如用户程序、事务处理或系统有误。数据的集中导致并行事务处理的出现，并行的事务处理可能会并发存取相同的数据。为防止并发存取和并发个性对数据完整性的危害，应采取措施保证无误无冲突地工作。基于隔离控制原理，这些措施目的在于使每项事务处理都觉得整个数据库为其独占，即逻辑模拟用户操作环境。并发修改同一数据项时，可能会得出错误结果。所以在数据库中当某项事务正在修改一个数据项时，其他事务只能读取，而不能修改。在空间数据库的情况下，采用锁的机制可保护数据完整性。锁的粒度取决于数据库的实现方法。基于图幅的组织方式时，整个图幅可为一个锁单元，无缝组织时，某个要素作为锁单元。文件系统时，整个文件只能有一项事务进行修改，其他事务可读取。最理想的锁粒度应是数据库中的单个要素，但这要求空间数据库有非常强的功能才行。根底地理信息数据库中，当图形数据和属性数据不在同一个库中时，在修改时还要保证两边的一致性，所以要同时锁住图形数据和属性数据。存取控制存取控制实为授权机制，是数据库平安的关键。对于何范围内的数据，在何条件下，规定准许可进行何种操作。数据库中的数据有对事件敏感、状态敏感和模式敏感的三种，事件敏感的数据只对一组专门用户在指定的时间内开放。状态第二的数据，存取取决于其值，即在数据库管理系统动态状况下起作用。对模式第三的数据其存取取决于数据库模式设计时对其用法的规定。用户在调用具体的模块时，要输入户名和密码或口令，每个模块均有其授权的用户。每种数据也定义了用户权限表，只有指定的用户才能进行相应的操作。用户权限是由数据库管理员来设定的。对于数据库的操作可分为：拥有、只读、只写、读写、删除等。一般这种权限是在表一级上定义的，通过对视图〔View〕的授权也可以对表的列定义访问权限。数据库的用户也是分组、分级的，数据库管理员拥有全部特权，数据拥有者次之。根底空间数据在存取控制上又有其专门特征。数据控制的可以是基于空间范围的，也可以是要素类的。有些区域对某些用户是开放的，对其他用户关闭；而有些要素只对某些用户是开放的。因此其存取控制可用一个三元组的表来表示，即〔范围，要素，权限〕。该表只有DBA才能访问修改。数据恢复数据库中的数据是独立于程序而存在的，无论是自然错误还是人为错误，都可能有千百万数据的错误，为了能够恢复修改前的状态和值，数据库的操作要具有：自动恢复：在出错时可回到修改前状态；自动备份：数据库修改后，原数据应有备份，这种备份又有完全备份和增量式备份；历史数据：当数据库中数据大量修改后，原来的数据要保存入历史库中，供以后用。数据保密在远程访问时，数据查询结果要在网上传送，这样就要求传送的数据平安。同样要采用加密的方法来到达目的。信息存贮媒体的平安以上讨论了信息平安的几个方面，而对于根底地理信息平安和保密来说，存贮媒体平安非常重要，是信息平安的根本保证，所以在此深入讨论。关键记录数据的保护记录的分类为了对那些必须保护的记录提供足够的保护，而对那些不重要的记录不提供多余的保护，应该对所有记录给予评价，并作出分类。1类〔关键性的〕记录：对设备的功能来说是最重要的，不可替代的，火灾或灾害后立即需要但又不能再制的那些记录。如关键程序、主记录、设备分配图表、加密、并法、密钥等秘级很高的记录。2类〔重要的〕记录：这类记录是很重要的，可以在不影响系统最主要功能的情况下进行复制，但比拟困难和昂贵。如某些程序、存贮及输入输出数据等属于该类。3类〔很有用的〕记录：其丧失可能引起极大的不便，但可以很快复制。已留有拷贝的程序、扫描的航空象片数据等属此类。4类〔不重要的〕记录：在调动时很少需要的记录。记录的复制全部1类记录都应复制。复制品应分散存放平安的地方。2类记录应有类似的复制品和存放方法。防护要求机房内所留记录的数量应该是系统有效运行的最小数量。定期存放在机房中的1类和2类记录应放在能防火、防高温、防水、防震、防电磁场的保护设备中，3类记录应放在密闭金属文件箱〔柜〕中。存放在机房外的记录，没有复制过的1类和2类记录应放在防火房间中，或放在能防火、防水、防潮、防震、防电磁场和防盗的保险柜中。磁带、磁盘和光盘库只有库管理员或系统管理员才允许访问磁带、磁盘和光盘库。所有磁带、磁盘和光盘的目录清单必须具有以下信息：文件所有者、卷系号、文件名及其描述、作业或工程编号、建立日期和保存期限。从外借来的材料应有文件所有者、卷系列号、文件名和描述、接收日期和归还日期进行编目。新磁带要定期检查和清洗，并登记。旧磁带和磁盘在销毁前要进行消磁和消除数据，平安负责人应保证所有已经损坏的磁带、磁盘和光盘的销毁。库管理员或系统管理员要负责把备份文件传送到离开现场的平安地方。所有磁带、磁盘和光盘不用时必须放入库中。库管理员或系统管理员负责所有磁带、磁盘和光盘从库里撤出和接收。在发件前，必须认真核对批准的申请单。库的温度应当在15℃－25工程进度方案及实施方案工程工期安排及控制工期安排的原那么工程实施阶段进度控制总目标是在按照合同规定的工程竣工时间完成全部工作，提交质量合格的成果。中标单位必须根据工程量、工程特点，结合环境因素，统筹安排人员、资金、仪器设备的配置。如有提前或滞后工期的情况，须经业主同意。为有效地控制实施进度，确保工程工程如期交付使用，需对实施进度总目标进行分解，形成各部门、分阶段可具体操作的目标体系，作为实施进度控制的依据。工期安排一般从以下几个方面进行分解：按实施阶段分解，明确每一阶段的起止时间；按实施单位分解，明确各个单位所承当工程的完成时间；按工程组成分解，明确各分项工程的开竣工时间；按时间分解，按工期及进度目标将实施总进度方案分解为月度或周方案。工期安排的内容编制可行的方案需考虑诸多因素，一个较完善的进度方案根本内容应包括：符合合同工期要求的实施程序，即实施性组织设计；工程总体进度安排图〔网络图、横道图及管理曲线〕；工程总体方案及详细的工艺方法；工程所需人力、财力、物力〔材料、仪器、设备等〕进场方案图；重难点工程、控制性工程或有特殊要求的工程详细的工期安排；保证进度方案的各项措施。工期安排管理的方法和措施抓好工期安排管理的方法主要是规划、控制和协调。规划就是确定工程总进度控制和分进度控制目标，并编制相应进度方案；控制就是在工程实施的全过程中，跟踪检查实际进度并与方案进度进行比拟，确定偏差并及时采取措施加以调整和纠正；协调就是协调与有关的各单位、各部门和各队之间的进度关系。工程进度的主要措施有：组织措施、技术措施、合同措施、经济措施、信息管理措施等。工期安排的实施与检查〔1〕工期安排的措施工程进度方案的实施就是开展施工活动，落实和完成方案，工程进度方案逐步实施的过程就是工程逐步完成的过程。为保证工程各项活动按工期安排所确定的顺序和时间进行，保证各阶段进度目标和总进度目标的实现，应做好以下工作：检查各层次的方案，并进一步编制月〔旬、周〕工作方案；综合平衡，做好劳、财、机等主要生产要素的优化配置；层层签订承包合同，并签发任务书；全面实行层层方案交底，保证全体人员共同参与方案实施；做好实施记录，掌握现场实际情况；切实做好实施中的调度工作，发现问题及时处理；预测各种可能的干扰因素，采取预控措施。〔2〕工期安排的检查在工程实施过程，工程进度方案的检查贯穿于工程进度方案执行的始终，二者密不可分，方案是进度的指导性文件，而进度检查的反响信息为后续方案的编制和调整提供依据。工期安排检查的主要工作：跟踪检查实际进度；整理统计检查有关数据；比照实际进度与方案进度；实施进度检查结果的处理。〔3〕对工期调整的安排首先分析进度偏差产生的影响，判断此进度偏差是否关系到关键工作：假设此项工作处于关键线路上，无论偏差大小，都必将对后续工作及总工期产生影响，必须采取相应的调整措施；假设此项工作在非关键线路上，那么根据其对后续工作和总工期的影响程度来定。其次判断此进度偏差是否大于总时差：假设大于总时差，说明该偏差会影响后续工作和工程的总工期，必须予以调整；假设不大于总时差，那么该偏差不会影响总工期，其对后续工作的影响待进一步判定。最后判断进度偏差是否大于自由时差：假设大于自由时差那么说明此偏差对后续工作有影响，应根据其对后续工作的影响成都做出调整；假设不大于自由时差，说明其对后续工作无影响，无须调整。工期安排的调整方法主要有两种：改变某些工作间的逻辑关系假设检查的实际施工进度产生的偏差影响了总工期，在工作之间的逻辑关系允许改变的条件下，改变关键线路和超过方案工期的非关键线路上的有关工作之间的逻辑关系，到达缩短工期的目的。缩短某些工作的持续时间这种方法不改变工作之间的逻辑关系，而是缩短某些工作的持续时间，使施工进度加快，并保证实现方案工期的方法。工期安排调整的内容主要包括：施工内容、工程量、起止时间、持续时间、逻辑关系和资源供给。数据更新工期安排根据招标文件所规定的工期，编制在第一阶段数据更新〔更新2008全年数据〕的工期安排：表SEQ表\*ARABIC6数据更新工期安排序号工作内容开始时间完成时间所需工作日备注1需求分析2002008工作日1.1数据现状调研2002004工作日1.2数据库标准调研2002004工作日2数据方案制定2008-2008-9工作日2.1制定数据更新方案2008-2008-3工作日2.2用户确认数据更新方案2008-2008-2工作日2.3制定数据生产流程2008-2008-2工作日2.4用户确认数据生产流程2008-2008-2工作日3公开版电子地图更新20020033工作日4公共设施点更新200200保证32工作日除去节假日5数据检查和验收20020021工作日5.1数据检查20020020工作日5.2数据验收2002001工作日工程包括三个阶段的更新，2008全年度、2009上半年、2009全年度，每个阶段的更新时间都是接近6个月，各个作业流程的时间分配大致相同。在后两个阶段，由于已经熟悉数据的构成，因此减少数据调研的时间，但是在数据更新方案制定方面可以适当增加时间，根据经验提高数据更新的效率，提供更多的数据更新手段。系统开发工期安排据招标文件所规定的工期，整个系统的开发工期安排如下：表SEQ表\*ARABIC7系统开发工期安排序号工作内容开始时间完成时间所需工作日备注1需求调研及分析2002007工作日2需求分析及确认20020010工作日2.1数据更新维护系统需求分析析20020010工作日2.4数据更新维护系统需求确认200200810工作日3系统设计2008-2008-7工作日4系统开发200200保证50工作日作日除去节假日5系统测试20020010工作日6系统试运行20020022工作日7系统验收文档准备20020010工作日8系统验收2002003工作日进度图如以下图所示：图SEQ图\*ARABIC60开发进度图提交成果数据提交成果如下：〔1〕2009年3月30日之前提交2008全年电子地图和公共设施数据库〔内、外网版本〕；〔2〕2009年9月30日之前提交2009上半年电子地图和公共设施数据库〔内、外网版本〕；〔3〕2010年3月30日之前提交2009全年电子地图和公共设施数据库〔内、外网版本〕；〔4〕数据成果内容包括：电子地图数据库、公共设施专题图集、电子地图和公共设施更新机制报告、电子地图和公共设施更新操作标准、其他技术文档和总结报告；〔5〕售后效劳：免费提供数据维护效劳一年。系统提交成果如下：〔1〕运行正确的安装系统〔2〕运行系统〔3〕系统源代码〔4〕用户使用手册〔安装手册、使用手册、维护手册等文档〕〔5〕开发文档〔需求、设计、测试、部署等文档〕〔6〕总结报告数据更新质量保证体系数据产品的高质量是工程数据整理工作主要的追求目标，因此，在此次的数据整理工作中将对数据整理的质量管理工作进行严格的管理。本数据整理过程的质量管理工作将严格按照ISO9001：2000版的要求和我们的技术管理标准，建立工程质量管理的流程，以保证数据整理的产品质量。目的对从事与质量有关的管理、执行和验证工作的人员，特别是对需要独立行使权力开展以下工作的人员，应规定其职责、权限和相互关系，并形成文件；采取措施，防止出现与产品、过程和质量体系有关的不合格；确认和记录与产品、过程和质量体系有关的问题；通过规定的渠道，采取、推荐或提出解决方法；验证解决方法的实施效果；控制不合格产品的进一步加工、交付或安装，直至缺陷或不满足要求的情况得到纠正。范围整个数据整理过程数据采集与说明文档数据检查到达的目标以独立审查的方式监控整个制作过程的执行，给数据整理人员和管理层提供反映产品质量的信息和数据，辅助数据整理组得到高质量的数据产品；使数据质量保证活动有方案性；使数据整理与其相关的标准、规程以及需求之间的符合性能够得到客观验证；使数据质量保证组所进行的活动和结果及时地通知到所涉及的数据整理组和个人；使高层管理者能够及时处理在数据整理工程内不能解决的与所制定的方案、标准和规程不相符合的问题。数据质量保证〔SQA〕组我们在工程的实施前会成立一个由制作方和用户共同成立的，对工程有一定管理能力的数据质量保证〔SQA〕组，负责协调和实施工程的数据质量保证〔SQA〕。为了使数据质量保证得到顺利实施，我们在工程管理中还制定了以下政策：为保障有足够的资源和经费，在工程经费中至少有5%的费用用于SQA活动；对SQA组的成员进行培训，使他们能完成SQA的活动；对参加数据生产工程的其他成员也进行有关SQA组的作用、职责及价值等方面的培训；高层管理者定期地〔在工程实施的过程中不少于3次〕评审SQA活动和结果。本次系统开发过程的质量管理工作除了严格按照公司的质量管理的要求外，还要加强对数据生产活动的阶段性评审工作，以保证数据生产的产品质量。工程的质量管理活动本工程将要进行的质量管理活动如下：数据生产工具评价对所有正在使用的或方案的，用于数据生产或对数据生产进行必要支持的软件工具进行评价。对于正在使用的软件要评价其提供的功能是否满足数据生产的需求，对于方案使用的软件，要评价其能行性和可行性。表SEQ表\*ARABIC8软件工具评价表软件工具评价表格编号：D-B10-01质量管理员：日期：评价：软件工具评价：评价的方法与标准：评价结果：推荐的改正措施：改正措施的实行：工程设备的评价质量管理员对正在使用的和方案使用的设备资源进行评价，估量所提供的必需的设备、器材和场地是否能满足数据生产的需求，并形成书面报告。表SEQ表\*ARABIC9工程设备评价表工程设备评价表格编号：D-B10-02质量管理员：日期：评价：工程设备评价〔器材、用户/测试/场地〕：评价的方法与标准：评价结果：推荐的改正措施：改正措施的实行：工程过程评审任务数据产品审查过程SQA管理人员评价数据产品审查过程。检查数据产品是否被审查，审查结果是否形成书面报告，结果和问题报告是否与工程的数据生产过程相一致。SQA管理人员使用过程审计报告单来报告审查的结果和本任务的完成情况。表SEQ表\*ARABIC10审计评审报告表表格编号：D-B04-01评审目的评审日期评审内容参加评审人员评审综述及结论〔可附页〕：见附件存在的问题及原因〔可附页〕：见附件整改措施建议〔可附页〕：见附件审核意见：审核人：年月日批准意见：批准人：年月日编制单位：编制人：年月日工程方案过程工程管理小组需要开展并且文档化以下方案：数据生产方案——通过数据生产规格来引导数据生产方案。方案被文档化，规定了在数据生产生命周期和适当的点所完成确实定的事件、检查和评审活动。数据检查方案——管理数据检查的方式方案，包含数据检查方案。工程需求分析过程工程需求分析在工程用户和数据生产团队之间建立起对数据处理的统一理解，确定工程用户对数据处理工程需求的协议，并在后期的数据生产过程中不断地对其进行维护工作。SQA人员应该完成以下的任务：保证在需求定义过程中选择适当的人员，并且所有人员的需求都被正确、完全的识别。保证所定义的需求是否通过验证的，是可实行的。保证对需求分配、工作产品、行为识别、检查和终止途径的变化管理。保证参加工程需求定义和分配过程的工程人员具有相关领域的工作经验或受过专门的训练，以此来确保工作的正确执行。保证对数据处理的承诺是与工程的实际关系人通过谈判和协商而得来的。检验承诺是否文档化的，便于交流的、便于检查的和可被接受的。保证能够识别出在工程需求分配确定过程中潜在的问题并进行必要的改变。检验规定的过程定义、文档的需求分配是否伴随进行并且是被文档化的。检验需求是否经过处理的、文档化的受控的和可回溯的。检验需求是否被写进制作方案中。工程概要设计过程〔1〕检查一般需求与设计检查设计评审时是否已确定了与需求有关问题〔如遗漏、模糊不清、不可测试的以及隐含的需求〕。检查设计是否与需求一致〔如是否有遗漏、不准确的、模糊不清的或不正确的功能〕检查设计是否充分说明了以下问题：实时需求可理解性数据的数学根底数据库需求数据的质量控制数据提交〔2〕数据生产规格说明检查每一过程的过程规格说明是否准确、齐全。检查是否用精确、不模糊的术语拟订了过程规格说明，该过程规格说明是否清楚地描述了所需的变更。检查是否规定了数据的分层、数据结构、数据编码和精度要求。检查是否规定了哪些地方需求进行错误检查、错误处理和纠正。检查设计是否遵循已确立的符号约定。系统详细设计过程详细设计需要被文档化《详细设计说明书》，SQA人员需要完成以下任务：〔1〕检查需求可跟踪性检查数据生产的详细设计是否实现了其需求。检查对该数据生产的审查是否识别出工程需求规格说明书中存在的问题，例如，是否有遗漏、模糊不清、相互矛盾、不可测试或隐含的需求。检查该数据生产的详细设计是否符合其总体设计方案需求。检查详细设计审查是否识别出工程总体设计方案中存在的问题。检查对数据成果完全、准确地进行描述是否到达足够详细的程度。检查是否完全、准确地描述了所有的数据生产构成，包括数据的分阶段制作，数据各阶段的具体操作，技术要求细那么和限制。检查详细设计文档内容，即逻辑数据，所有内部定义的数据是否完全、前后一致，没有额外的数据。〔2〕检查逻辑性检查是否有任何逻辑错误。检查是否检查了所有数据编码的唯一值。检查数据的处理顺序是否正确。检查是否存在数据处理错误，是否存在字段不正确、数据属性不一致或无效现象。〔3〕检查错误处理和恢复检查是否有适当的错误条件数据检查。检查是否认义了那些出错概率高或错误结果对数据是致命的错误条件。检查数据生产流程是否可以保证数据的质量，同时及时进行数据错误的纠正。〔4〕检查可检验性和可扩展性检查设计是否可理解〔即便于阅读、符合逻辑性〕、可维护〔即无模糊不清的逻辑〕、可检验〔即可用合理的检查模式对其检验〕。数据生产和检查过程〔1〕检查的规划按照工程的实际情况确定各检查阶段的目标和策略。这个过程将输出《检查方案》，明确要完成的数据检查活动，评估完成活动所需要的时间和资源，设计数据检查组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制检查过程的活动。数据检查规划与数据生产工作同步进行。SQA组人员在需求分析阶段，要完成《检查方案》；在设计阶段，要完成《质量控制设计方案》；在数据生产阶段，要完成数据记录；在提交顾客前，要完成《数据采集与处理的技术报告》和《质量控制报告》。对于检查方案的修订局部，需要进行重新评审。图SEQ图\*ARABIC61检查体系流程图〔2〕检查设计根据各阶段的检查方案设计质量控制的方案。检查设计过程输出的是各检查阶段数据和检查报告。〔3〕检查实施通过实施检查流程，各项检查工作同时进行检查记录记录检查的结果，对数据进行及时的纠错，并在检查结束后最终总结得到《质量控制报告》。〔4〕配置管理检查配置管理是配置管理的子集，作用于检查的各个阶段。其管理对象包括检查方案、检查方案、检查版本、检查工具及环境、质量控制报告等。〔5〕资源管理包括对人力资源和工作场所，以及相关设施和技术支持的管理。质量控制的内容数据检查与质量控制在工程实施过程中，主要是依据数据库建库标准以及相应的国家标准和行业标准，从原图精度检查、属性数据的准确性、数据的完整性、位置精度、元数据记录、数据逻辑一致性等方面进行的质量控制。表SEQ表\*ARABIC11质量特性一级质量特性二级质量特性位置精度数学根底平面精度高程精度接边精度属性精度要素分类与代码的正确性要素属性值的正确性要素注记的正确性逻辑一致性多边形闭合精度结点匹配精度拓扑关系的正确性完备性数据分层的完整性实体类型的完整性属性数据的完整性注记的完整性数据检查根本包括图形数据、属性数据、数据的接边情况、坐标配准等检查工作，具体归纳如下：根本数据检查〔1〕图形数据检查地图数据属于面状地物的要素有没有严格闭合，是否存在面状地物的错误图形。面状地物的轮廓位置和形状及编码是否正确，标识点的编码是否正确；面属性项是否齐备，属性取值是否正确，几何精度是否符合国家标准；〔2〕不同层的地物要素共线时，数据有没有提取公共边；〔3〕点状地物不是用点状符号来表示，而是用线实绘时，是否丢漏标识符号；〔4〕不同类型的注记有没有分类存放，如：面状地物类注记是否丢漏注记、错误注记。注记位置、注记大小和注记字体是否得当；〔5〕数据局部地物分类是否不细致；〔6〕是否丢漏地物或地物的局部，是否存在多余地物的问题；〔7〕是否有重复数字化的要素；〔8〕有无错误的标识；〔9〕有向点的点位、方向是否正确；〔10〕地物点的编码和定位位置是否正确；〔11〕线状地物编码是否正确、是否位移、是否变形、采集点是否疏密得当。当道路、河流、等高线等线状地物被点状符号、注记、桥梁、涵洞等要素符号割断时，线状地物是否保持连通；当道路、河流被桥梁、涵洞割断时，是否加辅助线连通；〔13〕要素作为属性的注记是否标注。数据属性检查〔1〕图层名是否完整和正确，图层是否有冗余；〔2〕每个层拓扑关系是否正确；〔3〕每个层的属性字段是否完整、每个层属性字段的定义是否正确、字段类型、字段长度，字段精度是否正确；〔4〕实体要素编码是否属于本层的范围内。拓扑关系检查〔1〕图层拓扑关系是否正确；〔2〕图层是否存在悬挂节点、线线挂接现象；〔3〕是否严格按照拓扑关系分层；〔4〕是否存在自相交、环套环等属于拓扑关系错误的情况。质量控制的方法质量检查包括三种方法：软件自动检查、人际交互检查、绘图输出检查。软件自动检查对于入库的所有数据应用软件实行自动检查，由于空间数据的图形与属性、图形与图形、属性与属性之间存在有一定的逻辑关系和规律，通过设计模型和算法，将数据中不符合规律、逻辑关系矛盾的要素自动挑选出来，主要包括：数据文件的完整性检查、属性一致性检查、拓扑关系建立检查、异常属性值检查、不符合逻辑关系的属性值检查等。程序检查例如如下：图SEQ图\*ARABIC62批量监理例如具体程序流程如以下图：图SEQ图\*ARABIC63程序检查流程人机交互检查在软件环境下，将要检查的数据可视化，以图形、图像、表格等形式显示在计算机的屏幕上，通过人工判断其正确性;也可以使用查询、统计、显示等功能的组合，实现对数据的检查。例如，在计算机上将采集的要素与影像进行叠加显示，从而检查要素的采集精度。还可以通过三维显示DEM来检查DEM高程的正确性。绘图输出检查绘图输出主要是将各种要检查的数据，根据其性质表现为图纸、报表、文档等模拟形式的介质，然后根据这些计算机回放的资料与数据采集的原始资料进行人工比拟核对，从而判断和确定数据的正确性。例如，对于采集完后的道路、河流要素，进行输出成图，使之与现有地图或航片进行对照或套合，从而检查所采集要素的精度;属性表可以打印出来，与原表逐条核对。在实际操作中，对于矢量数据的检查可以用三种方法相互配合、综合应用。在质量检查时，根据当时具体的内容，选用相应的方法，主要是以软件自动检查为主，结合人机交互检查和绘图输出模式，实现对二维空间数据进行全面的检查。验收内容主要是对数据成果的分层、编码、图幅接边、拓扑关系、几何定位、现势性等整理质量因素进行检查和验收，并检查提交技术文档的完备性。文件格式检查数据整理质量的检查；数据的属性检查；数据的命名检查；数据的完整性检查；数据几何精度检查；逻辑一致性检查。检查方法：人工检查与程序检查相结合。要求：地物要素分层正确、编码属性齐全、图幅接边情况良好、拓朴结构正确、文件命名方式正确无误，逻辑一致性，几何精度到达设计方案要求。工程文档管理作为数据生产产品的一局部，数据生产的文档的质量直接影响产品的质量。进行工程文档的管理即是深圳市规划局对本次数据更新的要求，也是我公司数据生产的标准性要求之一。有关的工程文档管理工作内容如下：文档编制方案文档方案是整个工程方案的一个独立文档，编写文档方案并把它分发给全体开发组成员，作为文档重要性的具体依据和管理部门文档工作责任的备忘录。文档方案一般包括以下几方面内容：列出应编制文档的目录提示编制文档应参考的标准指定文档管理员提供编制文档所需要的条件，落实文档编写人员及编制工具明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等绘制进度表，以图表形式列出在各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等规定每个文档要到达的质量等级为了到达期望的结果必须考虑哪些外部因素文档方案还确定该方案和文档的分发，并且明确表达与文档工作的所有人员的职责。文档种类根据招标文件的具体要求及我公司《文档管理制度》的要求，本工程提交的所有文档均符合相应的标准。本次开发活动将形成以下文档〔1〕数据生产文档根本的数据生产文档：投标文件和工程任务书需求规格说明书验收标准电子地图和公共设施更新机制报告电子地图和公共设施更新操作标准数据质量控制设计方案数据检查记录质量控制报告验收报告〔2〕管理文档工程管理过程所产生的文档：数据生产过程的每个阶段的进度和进度变更的记录数据生产变更情况记录过程评审表文档管理职责为了作好工程的文档管理工作，工程的文档管理人员具有以下职责：建立编制、登记、出版工程文档的各种策略；把文档方案作为整个开发工作的一个组成局部；建立确定文档质量、测试质量和评审质量的各种方法规程；为文档的各个方面，确定和准备各种标准和指南；积极支持文档工作以形成在开发工作中自觉编制文档的团队风气；不断检查已建立起来的过程，以保证符合策略和各种规程并遵守有关标准和指南。文档的质量要求工程开发过程中所产生的文档要满足以下要求：文档需要覆盖整个数据生产生存期，文档在贯穿数据生产过程中必须是可用的和可维护的。在数据生产完成后，文档应满足数据成果的使用、维护、转换或传输。文档应可管理的，工程经理应准备文档产品、进度、可靠性、资源，质量保证和评审规程的详细方案大纲。文档应适合于它的读者，读者可以是工程经理、数据生产员、数据检查员、维护人员、文书人员等，根据任务的执行，文档具有不同的详细程度，针对不同的读者，应设计不同类型的文档。文档应贯穿到整个数据生产过程中，应充分表达文档的作用和限制，即文档应指导全部开发过程。文档标准应被标识和使用，应尽可能采纳公司的文档编制标准和指南。数据更新维护系统质量保证体系软件产品的高质量是工程开发工作主要的追求目标，同时也是深圳市规划局在此次系统建设中非常关心的内容之一。因此，在此次的开发活动中将对开发活动的质量管理工作进行严格的管理。本系统开发过程的质量管理工作将严格按照ISO9001：2000版的要求和我们的技术管理标准，建立工程质量管理的流程，以保证开发的产品质量。目的对从事与质量有关的管理、执行和验证工作的人员，特别是对需要独立行使权力开展以下工作的人员，应规定其职责、权限和相互关系，并形成文件；采取措施，防止出现与产品、过程和质量体系有关的不合格；确认和记录与产品、过程和质量体系有关的问题；通过规定的渠道，采取、推荐或提出解决方法；验证解决方法的实施效果；控制不合格产品的进一步加工、交付或安装，直至缺陷或不满足要求的情况得到纠正。范围系统开发过程系统文档系统测试系统原代码管理到达的目标以独立审查的方式监控整个开发过程的执行，给开发人员和管理层提供反映产品质量的信息和数据，辅助软件工程组得到高质量的软件产品。使系统软件质量保证活动有方案性；使软件开发与其相关的标准、规程以及需求之间的符合性能够得到客观验证；使软件质量保证组所进行的活动和结果及时地通知到所涉及的软件开发组和个人；使高层管理者能够及时处理在软件工程内不能解决的与所制定的方案、标准和规程不相符合的问题。软件质量保证〔SQA〕组我们在工程的实施前会成立一个由开发方和用户共同成立的，对工程有一定管理能力的软件质量保证〔SQA〕组，负责协调和实施工程的软件质量保证〔SQA〕。为了使软件质量保证得到顺利实施，我们在工程管理中还制定了以下政策：为保障有足够的资源和经费，在工程经费中至少有5%的费用用于SQA活动；对SQA组的成员进行培训，使他们能完成SQA的活动；对参加软件工程的其他成员也进行有关SQA组的作用、职责及价值等方面的培训；高层管理者定期地〔在工程实施的过程中不少于3次〕评审SQA活动和结果。本次系统开发过程的质量管理工作除了严格按照公司的质量管理的要求外，还要加强对开发活动的阶段性评审工作，以保证开发的产品质量。工程评审工作任务〔1〕技术评审任务建立软件配置管理的基线；提出并解决技术问题，审查技术工作；评价工程的状态，判明有关技术问题的近期、长期风险，并加以讨论；在技术代表的权限内，达成已判明风险的转移策略；标识呈交管理人员讨论的风险要素和有关问题；确保用户和软件开发技术人员之间的交流通畅。〔2〕管理评审任务报告上级管理部门该工程的状态、所采取的方针、所达成的技术协议以及按产品进展的总体情况解决技术评审不能解决的问题就技术评审不能解决的近期、长期风险可达成的转移战略；鉴别并解决管理方面的问题，以及技术评审没有提出的风险；征得用户的同意和各方认可，以便及时完成。〔3〕系统评审任务系统和软件需求分析评审系统结构评审软件总体设计阶段，应对软件项、接口和数据设计结构评审软件详细设计和测试方案评审软件编码和测试结果的评审系统集成的评审系统确认评审软件评审完成后，提出应采取的各种措施，工程组实施修改，在预计的时间内，SQA组检查纠正的结果。工程的质量管理活动本工程将要进行的质量管理活动如下：开发工具评价对所有正在使用的或方案的，用于软件开发或对软件开发进行必要支持的软件工具进行评价。对于正在使用的软件要评价其提供的功能是否满足开发的需求，对于方案使用的软件，要评价其能行性和可行性。表SEQ表\*ARABIC12软件工具评价表软件工具评价表格编号：D-B11-01质量管理员：日期：评价：软件工具评价：评价的方法与标准：评价结果：推荐的改正措施：改正措施的实行：工程设备的评价质量管理员对正在使用的和方案使用的设备资源进行评价，估量所提供的必需的设备、器材和场地是否能满足软件开发的需求，并形成书面报告。表SEQ表\*ARABIC13工程设备评价工程设备评价表格编号：D-B11-02质量管理员：日期：评价：工程设备评价〔器材、用户/测试/场地〕：评价的方法与标准：评价结果：推荐的改正措施：改正措施的实行：工程过程评审任务软件产品审查过程SQA管理人员评价软件产品审查过程。检查软件产品是否被审查，审查结果是否形成书面报告，结果和问题报告是否与工程的软件开发过程相一致。SQA管理人员使用过程审计报告单来报告审查的结果和本任务的完成情况。表SEQ表\*ARABIC14审计评审报告表格编号：D-B05-01评审目的评审日期评审内容参加评审人员评审综述及结论〔可附页〕：见附件存在的问题及原因〔可附页〕：见附件整改措施建议〔可附页〕：见附件审核意见：审核人：年月日批准意见：批准人：年月日编制单位：编制人：年月日工程方案过程工程管理小组需要开展并且文档化以下方案：软件开发方案――通过软件开发规格来引导软件开发方案。方案被文档化，规定了在软件开发生命周期和适当的点所工完成确实定的事件、检查和评审活动。系统测试方案――管理系统测试条件的方案，其包含软件测试方案。软件安装与培训方案――包含系统安装和系统用户练习套件的方案。系统过渡方案――完成新旧系统转换和手工与系统转换的方案。系统需求分析过程系统需求分析在系统使用用户和软件工程开发团队之间建立起对系统和统一理解，确定系统使用用户对软件工程需求的协议，并在后期的开发过程中不断地对其进行维护工作。SQA人员应该完成以下的任务：保证在需求定义过程中选择适当的人员，并且所有人员的需求都被正确、完全的识别。保证所定义的需求是否通过验证的，是可实行的。保证对需求分配、工作产品、行为识别、检查和终止途径的变化管理。保证参加系统需求定义和分配过程的工程人员具有相关领域的工作经验或受过专门的训练，以此来确保工作的正确执行。保证对开发工作的承诺是与工程的实际关系人通过谈判和协商而得来的。检验承诺是否文档化的，便于交流的、便于检查的和可被接受的。保证能够识别出在系统需求分配确定过程中潜在的问题并进行必要的改变。检验规定的过程定义、文档的需求分配是否伴随进行并且是被文档化的。检验需求是否经过处理的、文档化的受控的和可回溯的。检验需求是否被写进开发方案中。系统概要设计过程系统设计需要被文档化《概要设计说明书》，SQA人员需要完成以下任务：〔1〕检查一般需求与设计检查设计评审时是否已确定了与需求有关问题〔如遗漏、模糊不清、不可测试的以及隐含的需求〕。检查设计是否与需求一致〔如是否有遗漏、不准确的、模糊不清的或不正确的功能〕检查设计是否充分说明了以下问题：实时需求性能问题可维护性可理解性数据库需求装入与初始化错误处理与恢复用户界面问题软件升级〔2〕功能与接口规格说明检查每一过程的过程规格说明是否准确、齐全。检查是否用精确、不模糊的术语拟订了过程规格说明，该过程规格说明是否清楚地描述了所需的变更。检查提供给用户界面的功能中是否适当地考虑了人的因素。检查是否规定了哪些地方需求进行错误检查、错误处理和恢复。检查接口是否与模块使用一致，是否遗漏了接口，是否有多余的接口。检查是否将接口规定到可确保对其进行验证的足够详细程度。检查设计是否遵循已确立的符号约定。系统详细设计过程详细设计需要被文档化《详细设计说明书》，SQA人员需要完成以下任务：〔1〕检查需求可跟踪性检查模块或接口的详细设计是否实现了其需求。检查对该模块或接口的审查是否识别出软件需求规格说明书中存在的问题，例如，是否有遗漏、模糊不清、相互矛盾、不可测试或隐含的需求。检查该模块或接口的详细设计是否符合其概要设计需求。检查详细设计审查是否识别出概要设计中存在的问题。检查对所有功能完全、准确地进行描述是否到达足够详细的程度。检查是否完全、准确地描述了所有的接口，包括关键字或位置参数、字段描述符、属性、范围和限制。检查详细设计文档内容，即逻辑数据，所有内部定义的数据是否完全、前后一致，没有额外的数据。〔2〕检查结构与接口检查在系统与子系统级，所有的组件和模块是否都在系统体系结构模型上都被确定。检查分解等级是否足以确定所有的模块。检查进一步分解是否能够识别更多的模块。检查是否已经清楚、准确地确定了系统/子系统中的单元与模块之间的所有接口。检查后续的分解是否能得到更详细的结果。检查模块是否正在执行多于一个的特定功能。〔3〕检查逻辑性检查是否有任何逻辑错误。检查是否测试了所有的唯一值，是否测试了所有的位置值，增量和循环计数器是否都被适当地初始化，变量和数据区在使用之前是否都被初始化。检查被审查模块的表处理起始与结束是否正确，中断队列处理是否正确，决策表逻辑是否正确，计算精度和准确是否高。检查是否为确保代码的正确执行适当地分配了信息优先级。检查信息的处理顺序是否正确。检查是否存在数据处理、数据缓冲区或表格错误，是否存在字段更新不正确、数据区使用冲突、初始化或更新不完全、数据属性不一致或无效现象。检查是否正确定义了过程调用和返回接口，是否正确定义了调用和返回参数，语法是否正确。〔4〕检查性能检查内存和时间分配是否合理并能得到。〔5〕检查错误处理和恢复检查是否有适当的错误条件测试。检查是否认义了那些出错概率高或错误结果对系统是致命的错误条件。检查返回代码是否经过确证。检查返回信息是否可理解。检查程序是否能够从模块或过程失效、操作系统失效、中断、硬件失效状态成功地进行错误恢复。〔6〕检查可测试性和可扩展性检查设计是否可理解〔即便于阅读、符合逻辑性〕、可维护〔即无模糊不清的逻辑〕、可测试〔即可用合理的测试数目对其测试〕。〔7〕检查耦合和内聚检查用标准耦合和内聚评价设计。编码和测试过程〔1〕测试的规划按照工程的实际情况确定各测试阶段的目标和策略。这个过程将输出《测试方案》，明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。测试规划与软件开发活动同步进行。SQA组人员在需求分析阶段，要完成《测试方案》；在设计阶段，要完成《集成测试方案》；在编码实现阶段，要完成《单元测试方案》；在提交顾客前，要完成《系统测试方案》和《内部验收测试方案和方案》；在试运行时，要完成《验收测试方案》。对于测试方案的修订局部，需要进行重新评审。图SEQ图\*ARABIC64测试体系流程图〔2〕测试设计根据各阶段的测试方案设计测试方案。测试设计过程输出的是各测试阶段使用的测试用例。测试设计的另一项内容是回归测试设计，即确定回归测试的用例集。对于测试用例的修订局部，也要求进行重新评审。〔3〕测试实施使用测试用例运行程序，将获得的运行结果与预期结果进行比拟和分析，记录、跟踪和管理软件缺陷，最终得到《测试分析报告》。〔4〕配置管理测试配置管理是软件配置管理的子集，作用于测试的各个阶段。其管理对象包括测试方案、测试方案〔用例〕〔一般测试方案与测试用例结合〕、测试版本、测试工具及环境、测试分析报告等。〔5〕资源管理包括对人力资源和工作场所，以及相关设施和技术支持的管理。〔6〕安装与测试环境配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的效劳器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、平安可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循以下内容：符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。选用比拟普及的操作系统和软件平台。一般我们会采用如“Windowsxp+MSOffice2003营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。将程序单位的所有程序以及用到的公共子程序安装到指定的多用户测试环境，该环境应与程序实际运行环境一致；提交SQA组进行测试时，工程经理必须提交《需求规格说明书》、《概要设计说明书》、效劳器设置参数和将系统编译成可执行文件，及各种类相应的资料。〔7〕各阶段测试流程需求阶段测试

质量保证经理制定《测试方案》，确定要完成测试的类型，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程的活动。设计&编码阶段测试

测试组长应组织测试组成员在设计&编码阶段，编写《集成测试方案》〔方案中包括测试用例〕和《单元测试方案》〔方案中包括测试用例〕。在进行单元测试时，测试员将每一问题填写《测试记录：<模块单元测试记录表>》，所有的单元测试完成后，再聚集成《单元测试总结报告》。图SEQ图\*ARABIC65设计&编码阶段测试工作〔8〕集成、系统、验收阶段测试测试组长应组织测试组成员进行集成测试，测试员将每一问题填写《测试记录：<软件集成测试表>》，所有的集成测试完成后，再聚集成《集成测试总结报告》。在提交顾客前，测试组要完成《系统测试方案》，按方案进行系统测试，并将测试结果反映在《系统测试综合报告》。测试组完成系统测试后，提交《需求规格说明书》、《概要设计说明书》效劳器设置参数和将系统编译成可执行文件交SQA组进行内部验收测试，SQA组人员每日填写《工程测试bug报告》，在下班前提交工程经理或开发人员，请工程经理确定BUG的处理时间，SQA组人员再按BUG的处理时间，更新系统后再进行回归测试，直到不出现BUG为止。最后，根据本次测试情况编写《测试分析报告》。图SEQ图\*ARABIC66集成、系统阶段测试工作流程工程文档管理作为软件产品的一局部，软件开发的文档的质量直接影响产品的质量。进行工程文档的管理即深圳市规划局对本次开发活动的要求，也是我公司软件开发的标准性要求之一。有关的工程文档管理工作内容如下：文档编制方案文档方案是整个工程方案的一个独立文档，编写文档方案并把它分发给全体开发组成员，作为文档重要性的具体依据和管理部门文档工作责任的备忘录。文档方案一般包括以下几方面内容：列出应编制文档的目录提示编制文档应参考的标准指定文档管理员提供编制文档所需要的条件，落实文档编写人员及编制工具明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等绘制进度表，以图表形式列出在各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等规定每个文档要到达的质量等级为了到达期望的结果必须考虑哪些外部因素文档方案还确定该方案和文档的分发，并且明确表达与文档工作的所有人员的职责。文档种类根据深圳市规划局的具体要求及我公司《文档管理制度》的要求，本工程提交的所有文档均符合GB8567《计算机软件产品开发文件编制指南》和GB/TI1457-89《软件工程术语》。本次开发活动将形成以下文档〔1〕开发文档根本的开发文档：投标文件和工程任务书需求分析报告需求规格说明书工作方案验收标准总体设计说明书详细设计说明书测试分析报告操作手册试运行维护、测试报告验收报告质量保证方案、标准、进度总结报告〔2〕管理文档工程管理过程所产生的文档：开发过程的每个阶段的进度和进度变更的记录软件变更情况记录过程评审表文档管理职责为了作好工程的文档管理工作，工程的文档管理人员具有以下职责：建立编制、登记、出版工程文档的各种策略；把文档方案作为整个开发工作的一个组成局部；建立确定文档质量、测试质量和评审质量的各种方法规程；为文档的各个方面，确定和准备各种标准和指南；积极支持文档工作以形成在开发工作中自觉编制文档的团队风气；不断检查已建立起来的过程，以保证符合策略和各种规程并遵守有关标准和指南。文档的质量要求工程开发过程中所产生的文档要满足以下要求：文档需要覆盖整个软件生存期，文档在贯穿软件开发过程中必须是可用的和可维护的。在开发完成后，文档应满足软件的使用、维护、增强、转换或传输。文档应可管理的，工程经理应准备文档产品、进度、可靠性、资源，质量保证和评审规程的详细方案大纲。文档应适合于它的读者，读者可以是工程经理、分析员、无计算机经验的专业人员、维护人员、文书人员等，根据任务的执行，文档具有不同的详细程度，针对不同的读者，应设计不同类型的文档。文档应贯穿到整个开发过程中，应充分表达文档的作用和限制，即文档应指导全部开发过程。文档标准应被标识和使用，应尽可能采纳公司的文档编制标准和指南。软件配置管理公司成立配置管理小组〔SCM〕进行配置管理，同时使用配置管理软件MicrosoftVisualSourcesafe工具进行工程标识项、文档和代码等的配置管理。配置管理的主要内容为：批准的控制项列表、需求、产品设计、程序源代码、测试用例和测试结果、产品设计标准〔如模块和系统命名标准、接口标准、标准信息和屏幕以及可重用的程序库〕、文档代码的版本、系统基准等。目标使系统的软件配置管理活动有方案性；保障软件开发过程的更动在控制下进行。相关政策建立一个负责协调和实施工程软件配置管理的组〔即SCM组〕；提供工程经费中至少2%的费用用于软件配置管理；在工程的整个生存周期内实行SCM；工程要建立专门的产品控制库用来存储软件生存周期内所产生的各种管理文档和技术文档，源代码及其可执行代码，运行时所需的各种数据以及相应的存储介质；SCM组的成员要通过专门的培训，使其能完成有关SCM的活动；软件工程的其他成员〔例如软件工程组、软件质量保证组的成员〕要经过的SCM的培训。实施与检查在整个工程实施的早期阶段成立软件配置管理组〔SCM〕，制定SCM方案；定期对SCM方案进行评审，参加人员包括受影响的组和个人；按照SCM方案，对所有软件配置管理项的更动请求和问题报告，进行申请、记录、评审、批准和跟踪等控制管理活动；高层管理者定期〔在工程的实施过程中不少于3次〕参与SCM评审活动；工程负责人应参加SCM评审活动，并对SCM组提出的问题做出响应；软件质量保证〔SQA〕组也应当评审和审计有关SCM的活动和工作产品，并报告其结果。工程进度管理在系统开发过程的每一步，开发方将严格按照相应的标准和标准执行，特别重视工程质量的保证，以便最终生成高质量的软件产品。工程组周例会工程管理人员每周召开一次例会，通报上周工作情况，存在问题，协调各小组开发人员的工作，针对问题采取相应的对策，调整以后的方案。工程管理协调小组会议工程管理人员每两周召开一次工程管理协调小组会议，用户方也派代表参加，评审工程进展情况并协调各方工作。方案的维护工程组每月一次将工程进度报揭发送到工程控制、公司管理部门和用户方，其中详述工程的进展情况，并列出所有未按方案完成的工作，同时注明未完成的原因，对方案进行及时修正与维护。工作考核与奖惩开发方将根据合同规定制订严密的工作方案，并根据工程组每个人的工作质量、工作效率、工作态度、团队精神设立相应的奖惩制度，鼓励按时完成任务，从而保证“深圳市城市规划空间信息数据库建设”工程的建设进度。风险识别与控制风险贯穿于工程的整个生命周期中，因而风险管理是个持续的过程，我公司建立良好的风险管理机制保证工程的成功实施。风险管理是工程管理流程与标准中的重要组成局部，包括以下几方面：〔1〕风险管理规那么〔2〕明确风险管理岗位与职责〔3〕不断丰富风险数据库、更新风险识别检查列表、注重工程风险管理经验的积累和总结。由于风险是在工程开始之后才开始对工程的开发起负面的影响，所以风险分析的缺乏，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，根本能够对工程的风险做出比拟准确的估计，经过慎重的考虑提出可行的风险回避措施，是防止损失的重要环节。风险的识别就是确定何种风险事件可能影响工程。在工程开始、每个工程阶段中间、主要范围变更批准之前都要进行风险识别，实际上它在整个工程生命周期内都是一个连续的过程，通过识别的和可预测的风险，工程管理者在可能时预先采取措施防止这些风险，必要时控制这些风险。风险识别经过我公司长期从事信息系统的开发，积累了一些风险管理的经验，我们总结出在软件开发的各个阶段可能发生以下这些风险：〔1〕需求分析阶段在这个阶段进行大局部需求分析、少局部设计〔大局部业务建模和需求、少局部分析设计〕。工程目标不清工程范围不明确〔范围太大太小都不可以〕用户参与少或和用户沟通少对业务了解不够对需求了解不够没有进行可行性研究〔2〕设计阶段在这个阶段进行大局部设计、少局部编码〔大局部分析设计，局部实施及测试，开始考虑部署〕工程队伍缺乏经验，如缺乏有经验的系统分析员没有变更控制方案，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求仓促方案，可能带来进度方面的风险漏项，由于设计人员的疏忽某个功能没有考虑进去〔3〕实施阶段在这个阶段进行大局部编码和测试，也涉及少局部设计〔大局部实施及测试，局部部署〕，如：设计变更或补充设计。开发环境没有具备好设计错误带来的实施困难程序员开发能力差，或程序员对开发工具不熟工程范围改变〔突然要增加或修改一些功能，需要重新考虑设计〕工程进度改变〔要求提前完成任务等〕人员离开，在一个工程内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对工程的影响会很大开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差没有有效的备份方案没有切实可行的测试方案测试人员经验缺乏〔4〕收尾阶段在这个阶段进行安装及维护〔大局部部署〕。质量差客户不满意设备没有按时到货资金不能回收风险的控制制定风险管理规那么，标准风险管理〔1〕风险管理的原那么全面周到原那么符合本公司开展总目标原那么量力而行原那么本钱效益比拟原那么注重运用商业保险〔2〕风险管理根本程序风险识别风险衡量风险处理风险管理效果评价风险应对方法工程中的风险永远不能全部消除，我公司针对上述的风险采取应对方法，使损失降底到最少。〔1〕防止方法通过分析找出来发生风险事件的原因，消除这些原因来防止一些特定的风险事件发生。比方：如何防止客户不满意。客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有到达验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以防止：业务建模阶段要让客户参与需求阶段要多和客户沟通，了解客户真正的需求目标系统的模型或DEMO系统要向客户演示，并得到反响意见，如果反响的意见和DEMO系统出入比拟大时，一定要将修改后的DEMO系统再次向客户演示，直到双方都达成共识为止要有双方认可的验收方案和验收标准做好变更控制和配置管理〔2〕减轻通过降低风险事件发生的概率或得失量来减轻对工程的影响。也可以采用风险转移的方法来减轻风险对工程带来的影响。工程预算中考虑应急储藏金是另一种降低风险影响的方法。比方：经过风险识别发现，工程组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻工程在本钱或进度方面的影响。也可以事先进行培训来减轻对工程的影响。〔3〕接受接受风险造成的后果。比方：为了防止自然灾害造成的后果，在一个大的软件工程中考虑了异地备份中心。开发应对措施〔1〕软件技术风险“深圳市数据更新维护管理系统”采用C/S结构，采用全组件COM开发技术，从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比拟，有相当的多的额外工作需要做，这会给工程工期带来较大的风险。回避和控制这局部风险的方法是在工程进行的过程中不断的对该阶段进行风险估计和指定有效的里程碑。同时采用"范例"方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。〔2〕软件过程风险的识别和控制软件需求阶段的风险软件的开发是以用户的需求开始，我公司派出在系统开发和业务有经验的人员对深圳市规划局进行需求调研，并在调研的过程中，与局进行广泛的交流和确认，以书面的形式形成《用户需求》这一重要的文档，该文档对每一需求都要进行需求标识，系统开发人员根据客户的需求建立系统原型，说明和纠正用户对需求的不确定性，最后得出经双方确认签字的用户需求。设计阶段的风险设计的主要目的在于软件的功能正确的反映了需求。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标和检验需求的一致性和需求分析的完整性和正确性。“深圳市城市规划空间信息数据库建设”工程的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术上实现良好的软件构架和稳定的组件。开发阶段的风险源代码本身也是文档的一局部，同时它又是将来运行于计算机系统之上的实体。我公司制定了源代码书写的标准性和可读性标准，并运行监督体制监督开发人员，使系统代码标准化，把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。并且组织专门的测试小组，对系统进行单元测试、集成测试、确认测试、系统测试和性能测试，力求尽早、尽多地发现系统的缺陷和错误。维护阶段的风险通过多年来广泛的社会实践，我公司已形成了一套完善的立体效劳架构，拥有一批经验丰富的技术支持、开发和培训人员以及专门对用户需求而设计的各项效劳，以保障用户在不同应用阶段、不同层次、不同规模的效劳需求得到满足。制定工程监督制度，明确风险管理岗位与职责我们在以往的工程建设中积累了许多工程管理的经验，得出回避和控制软件管理风险的唯一方法就是设立监督制度，工程开发中任何较大的决定都必须有主要技术环节由用户参与进行的。在“深圳市城市规划空间信息数据库建设”工程中工程监督由工程开发中的质量监督组来实施。

具体的主要技术人员和管理人员名单请参阅投标商务资料。一般参与软件开发的人员〔包括管理者和技术人员〕和其责任进行分析如下：工程经理1人主要职责：进行全局把握，侧重