提示：由于内容过长，所以实施规划详细方案说明书分成；两篇文章来写，此处紧接上一篇一份全面的“实施规划详细方案说明书1”是怎样的？的内容。

全部产品所在的店铺地址：https://www.axureshop.com/shop/3039
本人最新项目原型设计（大项目）完整版高保真实战原型(UE&UI)设计(PC端)地址：https://www.axureshop.com/a/674824.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(针对于全息中继器组件)地址：https://www.axureshop.com/a/249709.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(PC端+手机端)地址（这个性价比很高，推荐路过的朋友购买）：https://www.axureshop.com/a/234122.html#comment-287804
与此相关的完整版高保真实战项目(UE&UI)原型设计(手机端)地址：https://www.axureshop.com/a/246479.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(PC端)地址：https://www.axureshop.com/a/298707.html

6 平台性能规划方案

6.1 安全性设计

6.1.1 网络安全性

网络安全的建设目标要求针对网络在将来实际运行过程中可能遇到的各种安全威胁，采用防护、检测、反应、恢复四方面行之有效的安全措施，建立一个全方位并易于管理的安全体系，保障网络能够安全、稳定、可靠地运行，需要制定出安全体系的具体目标，以保证安全系统工程的实施。

主要的体现：

• 提高可靠性

通过冗余措施加以保证，具体包括线路冗余、设备备份措施。

• 防范与Internet互联的安全威胁

在外网与Internet互连区采用安全可靠的防火墙。

• 采用防病毒措施

在两个方面防范：

• 一方面建立完整的网络防毒机制；
• 另一方面建立严格完善的防毒管理规范；
• 防范网络服务的安全威胁

确保必须的网络服务的安全和可靠性。如DNS；对其它网络基本服务，限制使用范围，建立严格的使用管理规定，防止被黑客利用，绝对禁止匿名FTP服务，对需要使用又必须保证安全的场合，要经过身份认证、访问授权和审计记录机制的控制。

• 阻止黑客攻击

在两个方面防护：

• 一方面在Internet互联区域及与内网互连区域设置防火墙。
• 另一方面采用防黑客攻击软件：
  • 实现安全漏洞的扫描，结合系统管理及时修补安全漏洞；
  • 提供网络实时入侵检测，一定程度上实现对内网与外网的入侵阻隔；
  • 做好攻击的跟踪审计。
• 保障网站内容安全

防止网站数据被非法篡改，并且在被篡改后能及时恢复。

6.1.2 系统安全性

6.1.2.1 硬件安全

• 机房环境：保障温度范围为20-25℃，湿度范围为40-55%，防止电子设备失灵。
• 电力设施：采用双路强点引入，防止单一线路损坏导致断电；采用UPS系统，防止突然停电或电压不稳导致设备损坏。
• 报警监控设施：安装火灾报警系统，实现实时报警。同时安装了烟感报警系统，实时对烟雾进行探测。
• 设备情况：本系统应用时为1台数据库服务器，1台场景应用服务器，1台应用服务器。但是，同时配置另外3台备份服务器，防止服务器的损坏，并能够及时进行系统的切换和数据迁移
  • 安全管理制度：安全管理制度包括：
• 设立信息安全岗位，由专人负责；
• 建立服务器日常维护及管理制度
• 机房值班安全制度；
• 防火墙等软件更新制度；
• 应急处理流程；

6.1.2.2 软件安全

• 用户系统：平台拥有灵活的用户体系，根据项目的实际需求，可创建不同的用户多用户角色，同时该角色可分配相应的操作权限。用户需要通过身份认证才能登录平台。
• 权限管理：对应用系统的所有资源进行权限控制，根据用户所在角色，判断用户是否拥有访问、操作权限。
• 接口安全
• 系统日志：系统日志主要记录系统的系统错误信息、异常的根据信息等。系统管理员可以查看系统日志
• 审计日志：系统将会记录用户的重要的页面操作、数据访问等各类系统操作日志，系统管理员可查看日志来控制用户的安
• 数据校验设计
• 软件容错：目前系统异常处理机制有分为三种：
• 用户输入错误，这类错误在用户进行操作递交时会做出校验处理，并提示用户错误所在，由用户自行修改输入的错误；
• 系统对操作界面产生的错误信息给予明确的提示，或弹出对话框，提示用户该步骤操作出现错误，并且指明具体的错误之处，方便系统维护人员及时找出问题所在，解决此错误，保证系统运行正常。
• 客户端异常问题，主要体现在打开的控件提示。系统会提示用户按照正确的步骤去解决该类错误，或者请求运维人员根据提示的步骤进行操作解决客户端异常问题；

6.1.2.3 数据安全

• 硬件数据安全：服务器磁盘整理利用数组方式做磁盘组，利用RAID5技术，将数据切割成许多区段，分别存放在各个硬盘上。同时，磁盘阵列还能利用同位检查，在磁盘阵列中任意一颗硬盘故，障时，仍可读出数据，在数据重构时，将数据经计算后重新置入新硬盘
• 软件数据安全：对服务器中地系统数据库进行定时备份，从而防止服务器或者数据库损坏时、数据被攻击或者篡改时能够及时修复。

6.1.3 操作安全性

操作安全性由网络登录验证、数据库登录验证、应用系统使用验证三级组成。网络登录验证由操作系统完成，用于对具有网络资源访问权限用户的验证；数据库登录验证由数据库服务器完成，用于对具有数据库访问权限用户的验证；系统使用验证由应用系统完成，用于对具有应用系统使用权限用户的验证；应用系统将采用三种验证方式相结合的方式验证用户。

6.1.4 数据传输安全性

为保证数据传输的安全性，使得所传输数据不被盗窃、更改，应用系统所采集的重要原始数据可采用网络加密传输、数据库加密传输或应用系统数据加密相结合的技术。

6.1.5 数据存储安全性

重要数据因某种原因需用存储介质进行长期备份存储时，可采用加密算法对数据进行加密，使得非法用户不能理解其含义，当合法用户访问时再将其还原。

6.1.6 采用日志

采用日志的形式，对进入系统的用户的操作进行记录，包括合法用户的操作和非法用户的尝试性登录；可以根据日志进行事后分析，从而找到事故的发生原因、责任者或非法用户。

6.1.7 系统维修时的数据安全性

当系统需要检修或维修时，有可能对系统进行调试，在调试时我们将采用切换到临时运行环境的方法，使系统在调试时与正式存储设备（数据库）隔离，维修结束正式使用时，再将系统与正式存储设备（数据库）相连接。这样就可以保证系统在维修时已有数据的安全。

6.1.8 原始数据的安全性

为了保证原始数据的原始性，原始数据一旦保存，便不能被更改；对错误数据只能采取增加一条记录来修正的方式处理，对修正数据应加标志以保证正确性，同时对于修正操作应做数据修正日志，记录修正人相关信息及修正原因等。

6.2 风险管理方案

6.2.1 风险分析

建议按下面的公式评估风险：

风险规避的优先级 = 风险系数×风险的影响程度

其中，风险系数为风险发生的概率。影响程度为风险发生后所导致的后果的严重程度，分为四个级别：

• 一级风险（致命的）：致命的指导致项目不能在一定的时间、成本范围内，按照客户的需求完成；
• 二级风险（严重的）：对项目进度、成本或质量产生重大的影响，有使项目失败的可能，但可以通过某种方式得以弥补，而避免失败的结果。采用该方式需要付出较大代价；
• 三级风险（一般的）：项目进度、成本或质量有影响，但影响力度相对较轻，基本上不致使项目失败，可以通过适当措施弥补或纠正，但要付出一定的代价；
• 四级风险（可忽略）：项目进度、成本或质量的影响轻微，不会使项目失败，做轻微调整就可以弥补或纠正；

优先级分为高、中、低三级，分别对应着计算数值大于等于1.5（C≥1.5）、小于1.5且大于等于0.8（0.8≤C＜1.5）和小于0.8（C＜0.8）的情况。

对于中、高级的风险（风险优先级≥0.8），应该考虑该风险对当前项目计划执行的影响，并根据实际情况，调整项目计划的相关内容。

6.2.2 常见风险

本项目在系统需求没有详细全面确定的情况下，我们建议项目组能够借鉴如下常见风险，及早采取有效措施，确保项目成功。

image

6.2.3 应对措施

在风险分析之后，项目经理对概率和影响程度制定风险应对计划。

风险应对计划分为规避、减缓和应急计划。在规避、减缓、接受和应急计划中，项目经理写明计划中相关的人员、时间（对应急计划可以不需要）、具体行动等。计划制定后，相关人员必须严格依照执行。在制定风险应对措施时，如涉及到资源、成本、进度变更等问题，报请项目经理提供支持，并启动配置变更管理过程。

规避：通过分析找出发生风险事件的原因，消除这些原因来规避一些特定的风险事件发生。

6.2.4 风险跟踪

在制定和执行风险应对计划之后，跟踪所有被标识风险的状态和应对计划的执行情况，并将规避/减缓计划的执行情况以及风险发生时采取的应急计划的执行情况，记录在项目风险表中的计划执行情况栏目中，直至被标识风险的状态为Close。

6.2.5 状态通报

根据当前风险项目的状态以及正在形成的风险的信息随时更新修改风险列表，并把它作为项目月总结报告的一部分提交项目总经理。

对于风险处理优先级比较高的风险，要以最快的速度，用书面或口头形式通报项目总经理。

6.2.6 风险数据库

在子系统开发关闭时，子项目经理负责向质量部提交相关风险数据，在通过风险数据库维护人员的评审后，更新项目风险数据库。

6.3 可靠性设计

数据需在整个分布式数据库系统中保持一致，我们将采取以下几种措施来保证这些数据的一致性：

• 利用关系数据库管理系统（RDBMS）的一致性检查与控制机制；
• 关系数据库管理系统（RDBMS）具有一套严格的数据完整性和一致性的管理机制。
• 采用版本控制技术，即对每一类需同步的数据设置其版本号，在用户登录系统或系统进行处理时（若要用到这些数据），则系统先判断其是不是最新版本，若不是最新版本，则对这些数据进行更新（以原始数据库的数据为基础），保证系统所用的数据为最新数据，同时也保证了各级数据的一致。
• 在操作平台运营中，需要传输大量的数据，因此，保证数据传输的正确性就显得尤为重要，即使在网络通讯不可靠或出现异常时也能保证信息的传输。

6.4 存储解决方案

本平台是以建立大额在线管理操作系统为目的的，对于这么一个系统，数据的安全、高效存储是系统建设的重中之重。

6.4.1 系统的数据存储特点

• 数据集中存储，所有的数据都存储在一个中心。
• 数据安全性要求高，数据的安全是系统正常运营的前提，一定要认真考虑系统的数据安全性。
• 数据增长量大，系统数据在网络完善的情况下会以更加惊人的速度增加。
• 数据备份及管理的工作量比较大。

6.4.2 软硬结合的存储方式

鉴于系统的复杂程度，单纯依靠数据库自身的备份功能，不足以保证系统的灾难恢复能力；系统的数据量对普通的硬盘、以太网等，在容量和性能上也是一个考验；因此，我们建议采用软硬结合的方式：

• 软件支持各种数据备份策略和各种存储设备，可采购第三方产品。
• 硬件保证容量、缩短备份时间，可使用高速光纤网络（存储区域网，SAN），高速磁盘阵列（RAID），大容量磁带机（TAPE）等。

6.5 容灾备份设计

保证业务持续性的重要手段是提高信息系统的高可靠性，需要建设一个对各种情况都可以抵御或者化解的异地的容灾系统。

容灾系统的核心就在于将灾难化解：

• 一是保证业务数据的安全；
• 二是保证业务的连续性；

数据的安全需要保证用户数据的完整性、可靠性和一致性。数据安全是容灾系统的基础，也是容灾系统能够正常工作的保障；业务连续性是容灾系统的建设目标，它必须建立在可靠的数据备份的基础上，通过应用系统、网络系统等各种资源之间的良好协调来实现。

为了建立高可靠性的系统，如机房破坏等重大自然灾害，需要建立异地灾难备份中心，用户将本地备份的数据送到远离本地的地方保存抵御灾难。灾难发生后，按预定的数据恢复程序购置和安装备份硬件平台，恢复系统和数据即可。实现数据的异地复制，有软件方式和硬件方式两种途径。软件方式，是通过主机端软件来实现，如远程卷复制或者数据库厂家提供的远程数据备份工具来实现业务数据的远程复制。

建立一个异地的数据系统，该系统是生产中心关键应用数据的一个复制。复制可以通过硬件——磁盘阵列的同步技术；也可以通过软件——远程卷镜像和数据库远程复制工具。确保在生产中心发生灾难时，生产数据在备份中心仍然可用，可以采用硬件（磁盘阵列）或软件方式来实现。

建立一个集本地、异地数据和应用容灾于一体的方案，最大限度的保证数据的一致性，容灾级别依次提高，后者以前者为基础，可以分步实施，后期保护前期投资，能够支持人工/自动容灾的方案，用户可以根据需要自由选择,是灾难备份设计方案的目标和出发点。

6.6 软硬件建设方案

6.6.1 网络系统

image

6.6.1.1 服务器端采用阿里云

服务器端采用阿里云服务器，需要安装sql server2008 R2，IIS，asp，.net等软件及组件。现有单项目阿里云服务器配置如下：

image

通过对阿里云服务器增加配置的方式实现企业级应用。

image

则每增加一个北横同等体量的项目，按照新增24M带宽、扩容linux服务器、windows服务器的CPU、内存、数据盘，新增费用如下：

image

则每新一个项目，新增费用22071.1****元。

6.6.1.2 服务器端采用物理机

服务器端采用物理机，优点在于一台物理机可以同时开辟多台虚拟机用于多个项目，在服务器承载能力满足的情况下，不需要每年再付费。但是物理机需要独立IP，可能存在网络带宽不稳定、供电不稳的问题，由于地域原因，不能随时观察服务器状况。同时，伴随着项目的增多，服务器的负荷也会升高，运维成本增大。一旦承载能力超出负荷，则不能再自由扩展原有物理机的配置。

• 物理机配置：

image

• Linux虚拟机的配置：

image

• Windows虚拟机的配置：

image

理论上，一台物理机，可以搭载北横同等体量的6个项目。

6.6.1 客户端软硬件环境

image

6.7 实用性设计

6.7.1 可维护性

本方案中选用多层结构体系作为应用系统开发的核心技术，使得开发的应用系统具有非常好的维护性和功能扩展能力。

应用软件的维护和升级，只需要更新服务器中的应用程序就可以达到维护和升级的目的。

6.7.2 可操作性

系统管理和操作将全部采用图形化交互式人机界面，具有数据处理操作简单、方便、快捷。对业务流程的处理，完全按照常规的处理习惯，充分考虑到人员的操作习惯。

6.7.3 多功能性

系统可向各类用户提供各种指标报表；能根据不同的要求灵活处理报表指标，提供灵活自由的、功能强大的组合查询手段和统计功能。

提供多种分析方法，如饼图、曲线图、柱图、表格等。通过数据库与Web的集成，对工作人员、管理机构提供功能强大的综合查询和统计服务及Web服务访问功能。

6.7.4 高效性

采用高效的服务器、功能强大的数据库系统，为各种业务提供高效率的工作能力，适应大规模数据处理的要求。

6.8 可扩展性设计

本方案选用多层结构体系作为系统开发的核心技术，就充分考虑到本系统的业务变化和扩展的实际情况，使得开发的应用系统具有非常好的维护性和功能扩展能力。

采用标准和通用的网络设备及协议，采用开放式的数据库平台和组件技术，采用兼容性强的电子邮件系统，确保随着平台的成长，已有的资源的有效性。

6.9 灵活性设计

6.9.1 高度的模块化设计

采用高内聚、低耦合原则进行模块划分。模块间提供相应的接口，当应用系统的业务或功能要求发生变化时，可以通过简单的对相应模块的修改来实现功能扩展。

6.9.2 多层体系结构

多层体系结构分为客户端、应用服务器和数据库服务器。其中，客户端提供统一的用户界面，完成对用户请求的收集与结果显示；应用服务器主要是处理用户请求，实现应用系统功能；数据库服务器则是为应用服务器提供数据。基于这样的体系结构，更有利于功能扩展与修改。

6.10 容错性设计

系统的容错性设计是指设计软件时能够保证用户输入的正确性和对系统非法的和破坏性的输入有很强的容错能力。

当用户进行正常的数据输入时，系统对输入的数据要做有效性检查和完整性检验，保证将正确的数据存入数据库，对于用户错误的输入，不但拒绝接受，而且要给出明确的错误提示，供操作者改正；对于用户输入非法的和对系统具有破坏性的数据，系统能够加以识别，并做出相应的处理，避免造成系统的死机和瘫痪。

6.11 快速恢复设计

在系统使用过程中，由于硬件出现故障或其它原因造成系统暂时性的中断后系统重新启动时，能够保证系统将原有的数据快速恢复，使继续运行下去。

在数据库设计时，有软件自动（默认）或人工对重要的数据进行定期的备份，并做有备份日志，系统的功能中专门设计数据备份和恢复功能，使用户能够快速地自动地将数据从故障处恢复。

在系统正常运行时，定期地将数据库中的数据备份到磁带机，在系统硬盘里保存一段时间内的数据（如5年），如果超出这个时间区段，则将超出时间区段的数据全部导出到磁带机上保存，避免数据库里的数据过于庞大，也保证数据的安全。当用户查询以前的数据超出当前硬盘存储的数据范围，则随时从磁带机中调出相应时间段的数据库供使用。

6.12 方案设计特点

6.12.1 基于体系结构的服务标准

遵循体系结构规范的、适合于分布式异构环境的标准服务平台。通过管理信息系统信息化建设系统提供的标准服务，为用户提供办公支持。

6.12.2 基于XML标准的数据交换标准

通过应用XML技术，规范当前管理信息系统信息化建设系统资料库的数据标准，从而实现应用之间的互联互通。

6.12.3 中间件技术

系统采用的中间件技术使得中间业务逻辑层能够很方便的维护和二次开发,同时使系统能够让用户方便地进行WEB的报表打印。

6.12.4 基于WEB的多级审批

通过WEB方式，既可以部署在专网，也可以部署在互联网，通过中心机房集中数据、应用，其他各方用户无需重复建设，只需通过终端PC即可使用。

6.12.5 支持复合流程

从数据获取到数据展示的主体流程，也支持数据查询和数据删除、修改的办公子流程。

6.12.6 信息高度的电子化

本系统信息的高度电子化，所有项目信息都完全上网录入，文档化数据则以附件方式上传，从而保障了办公的真正高效和数据统计的及时与科学性。

6.12.7 工作流技术

本系统采用工作流技术方便各个用户了解自己当前的任务和每个事物处理进展情况,加强了用户的使用方便性。

6.12.8 界面的灵活定制和组件化

由于采用了组件式模块化开发，保证了技术核心不修改的情况下，操作界面的可快速定制，有效满足用户的个性需求。

6.12.9 报表的多种格式

本系统能以Excel文档等不同文件格式输出文件。

7 项目质量管理保障方案

项目质量管理包括执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预订的需求。项目质量管理在项目环境内使用政策和程序，实施组织的质量管理体系；并以执行组织的名义，适当支持持续的过程改进活动。项目质量管理确保项目需求，包括产品需求，得到满足和确认。

一个项目只有实现高质量的信息系统建设，才能为信息系统的有效运行提供基础，才能保证信息系统发挥应有的经济效益和社会效益。因此，信息系统集成的质量控制是十分重要的，只有实施严格的质量控制，才能真正实现信息系统的质量建设目标，保证信息化建设的投资回报。为实现平台系统的全面质量控制，在项目启动阶段，一方面要明确确定进行软件质量控制的人员；另一方面要制定全面的软件质量保证计划。在软件开发过程中，通过有效的质量评审机制，使软件质量得到有效的保证和跟踪。

image

7.1 质量管理的各过程

7.1.1 质量管理的各过程概述

项目质量管理各过程，包括：

• 规划质量管理：识别项目及其可交付成果的质量要求和/或标准，并书面描述项目将如何证明符合质量要求的过程。
• 实施质量保证：审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程。
• 控制质量：监督记录质量活动执行结果，以便评估绩效，并推荐必要的变更的过程。

image

上述过程不仅彼此作用，而且还与其他知识领域中的过程相互作用。

项目质量管理需要蛟骨项目管理与项目可交付成果两个方面。它适用于所有项目，无论项目的可交付成果具有何种特性。质量的测量方法和技术则需专门针对项目所产生的的可交付成果类型而定。

无论什么项目，未达到质量要求，都会给某个或全部项目干系人带来严重的负面后果：

• 为满足客户要求而让项目团队超负荷工作，就可能导致利润下降、项目风险增加，以及员工疲劳、出错或返工。
• 为满足项目进度目标而仓促完成预定的质量检查，就可能造成检验疏漏、利润下降，以及后续风险增加。

7.1.2 质量与等级的区别

质量与等级不是相同的概念：

• 质量：作为实现的性能或成果，是“一系列内在特性满足要求的程度（ISO 9000）”。
• 等级：作为设计意图，是对用途相同但技术特性不同的可交付成果的级别分类。

项目经理及项目管理团队负责权衡，一边同时达到所要求的的质量与等级水平。质量水平未达到质量要求肯定是个问题，而低等级不一定是个问题：

• 一个低等级（功能有限）、高质量（五明显缺陷，用户手册易读）的软件产品，也许不是问题。该产品是和一般使用。
• 一个高等级（功能繁多），低质量（有许多缺陷，用户手册杂乱无章）的软件产品，也许是个问题。改产破旧年的功能会因质量低劣而无效和/或低效。

7.1.3 精确度和准确度

项目管理团队应该在质量管理计划中合理地确定将要达到的准确水平和精确水平：

• 精确度：是对精密程度的度量。增量的数量越多，精确度就越高。
• 准确度：是对正确性的评估。

可用射箭进一步说明。箭头密集在靶子的一个区域（即便不在靶心），就具有很高的精确度。箭头分散但到靶心的距离相等，就具有相同的准确度。箭头密集在靶心内，就是既准确又精确。精确的测量未必准确，准确的测量未必精确。

7.1.4 质量管理方法的重要性

在与ISO保持兼容性的前提下，现代质量管理方法力求缩小差异，交付满足既定要求的成果。

现代质量管理方法承认一下几个方面的重要性：

• 客户满意：了解、评估、定义和管理要求，以便满足客户的期望。这就需要把“符合要求”（确保项目产出预定的成果）和“适合使用”（产品或服务满足实际需求）结合起来。
• 预防胜于检查：质量应该被规划和设计，并且在项目的管理过程或可交付成果生产过程中被建造出来（而不是被检查出来）。预防错误的成本通常远低于在价差或使用中发现并纠正错误的成本。
• 持续改进：由休哈特提出并经戴明完善的计划——实施——检查——行动（PDCA循环）是质量改进的基础。另外，诸如全面质量管理（TQM）、六西格玛和精益六西格玛等质量管理措施，也可以改进项目的管理质量及项目的产品质量。常用的过程改进模型包括马尔科姆·波多里奇模型、组织级项目管理成熟度模型（OPM3）和能力成熟度集成模型（CMMI）。
• 管理层的责任：项目的成功需要项目团队全体成员的参与。然而，管理层在其质量职责内，肩负着为项目提供具有足够能力的资源的相应责任。
• 质量成本(CQQ)：是指一致性工作和非一致性工作的总成本。
• 一致性工作：侍卫预防工作出错而坐的附加努力。
• 非一致性工作：是为纠正已经出现的错误而坐的附加努力。

质量工作的成本在可交付成果的真个生命周期中都可能发生。项目结束后，也可能因产品退货、保修索赔、产品召回而发生“后项目质量成本”。由于项目的临时性及降低后项目质量成本所带来的潜在利益，发起组织可能选择对产品质量改进进行投资。这些投资通常用一致性工作方面，以预防缺陷或检查出不合格单元来降低缺陷成本。此外，与后项目质量成本有关的问题，也应该成为项目集管理和项目组合管理的关注点，以便项目、项目集和项目组合管理办公室专门开战审查，提供模板和分配资金。

image

7.2 规划质量管理

7.2.1 计划编制

确定项目的范围、中间产品和最终产品，然后明确关于中间产品和最终产品的有关规定、标准，确定可能影响产品质量的技术要点，并找出能够确保高效满足相关规定、标准的过程方法。

7.2.2 输入、工具与技术、输出

质量规划应与其他规划过程并行开展。

image

图7.4 规划质量管理：输入、工具与技术和输出

image

7.2.2.1 输入

• 项目管理计划：被用于制定质量管理计划。用户自定质量管理计划的信息包括：
• 范围基准：
• 项目范围说明书：包括项目描述、主要项目可交付成果及验收标准。产品范围通常包含技术问题细节及会影响质量规划的其他事项，这些事项应该已经在项目的规划范围过程中得以定义。验收标准的界定可能导致质量成本并进而导致项目成本的显著增加或降低。满足所有的验收标准意味着发起人和客户的需求得以满足。
• 工作分解结构（WBS）：WBS识别可交付成果和工作包，用于考核项目绩效。
• WBS词典：提供WBS要素的详细信息。
• 进度标准：记录经认可的进度绩效指标，包括开始和完成日期。
• 成本基准：记录用于考核成本绩效的、经过认可的时间间隔。
• 其他管理计划：这些计划有利于整个项目质量，其中可能突出与项目质量有关的行动计划。
• 干系人登记册：有助于识别对质量有特别兴趣的那些干系人。
• 风险登记册：包含可能影响质量要求的各种威胁和机会的信息。
• 需求文件：记录项目应该满足的、与干系人期望有关的需求。包括（但不限于）项目（包括产品）需求和质量需求。这些需求有助于项目团队规划将如何开展项目质量控制。
• 事业环境因素：可能影响规划质量管理过程的事业环境因素包括（但不限于）：
• 政府法规；
• 特定应用领域的相关规则、标准和指南；
• 可能影响项目质量的项目或可交付成果的工作条件或运行条件；
• 可能影响质量期望的文化观念。
• 组织过程资产：
• 组织的质量政策、程序及指南。执行组织的质量政策是高级管理层所推崇的，规定了组织在质量管理方面的工作方向。
• 历史数据库；
• 以往阶段或项目的经验教训。

7.2.2.2 工具与技术

• 成本效益分析：答道质量要求的主要效益包括减少返工、提高生产率、降低成本、提升干系人满意度及提升盈利能力。对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。
• 质量成本：包括在产品生命周期中为预防不符合要求、为评价产品或服务师父符合要求，以及因未达到要求（返工），而发生的所有成本。失败成本常分内部（项目内部发现的）和外部（客户发现的）两类。失败成本也成为劣质成本。

image

• 其中基本质量工具：也称7QC工具，用于在PDCA循环的框架内解决与质量相关的问题。
• 因果图又称鱼骨图或石川图：问题陈述放在预估的头部，作为起点，用来追溯问题来源，回推到可行动的根本原因。在问题陈述中，通常把问题描述为一个要被弥补的差距或要达到的目标。通常看问题陈述和问“为什么”来发现原因，知道发现可行动的根本原因，或者尽每根鱼骨图上的合理可能性。要在被视为特殊偏差的不良结果与飞随机原因之间建立联系，鱼骨图往往是行之有效的。基于这种联系，项目团队应采取纠正措施，消除在控制图中呈现的特殊偏差。

image

• 对于复杂的项目，编制质量计划时可以采用因果分析图，描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。其次，质量计划中还必须确定有效的质量管理体系，明确质量监理人员对项目质量负责和各级质量管理人员的权限。
• 流程图也称过程图：用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要的步骤顺序和可能分支。它通过映射SIPOC模型的水平价值链的过程细节，来显示活动、决策点、分支循环、并行路径及整体处理顺序。流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率，来估算质量成本。这些逻辑分支，是为完成符合要求的成果而需要开展的一致性工作和非一致性工作的细分。

image

• 核查表，又称计数表：适用于手机数据的查对清单。它合理排列各种事项，以便有效地手机关于潜在质量问题的有用数据。在开展检查以识别缺陷时，用核查表收集属性数据就特别方便。用核查表收集的关于缺陷数量或后果的数据，又经常使用帕累托图来显示。
• 帕累托图：是一种特殊的垂直条形图，用于识别造成大多数问题的少数重要原因。在横轴上所显示的原因类别，作为有效的概率分布，涵盖100%的可能观查结果。横轴上每个特定原因的相对频率逐渐减少，直至以“其他”来涵盖未致命的全部其他原因。在帕累托图中，通常按类别排列条形，以测量频率或后果。
• 直方图：是一种特殊形式的条形图，用于描述几种趋势、分散程度和统计分布形状。与控制图不同，直方图不考虑时间对分布内的变化的影响。
• 控制图：用来确定一个过程是否稳定，或者是否具有可预测的绩效。根据协议要求而制定的规范上限和下限，反应了可允许的最大值和最小值。超出规范界限就可能受处罚。上下控制界限不同于规范界限。控制界限根据标准的统计原则，通过标准的统计计算确定，代表一个稳定的过程的而自然波动范围。项目经理和干系人可基于计算出的控制界限，发现采取纠正措施的检查点，以便预防非自然的绩效。纠正措施旨在维持一个有效过程的自然稳定性。
• 散点图，又称相关图：标有许多坐标点（x,y），解释因变量y相对于自变量x的变亮。相关性可能成正比例（正相关）、负比例（负相关）或不存在（零相关）。如果存在相关性，就可以画出一条回归线，来估算自变量的变化将如何影响因变量的值。
• 标杆对照：标杆对照是将实际或计划的项目实践与可比项目的时间进行对照，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。作为标杆的项目可以来自执行组织内部或外部，或者来自同一应用领域。标杆对照也允许用不同应用领域的项目作类比。
• 实验设计：DOE是一种统计方法，用来识别那些因素会对正在生产的产品或正在开发的流程的特定变亮产生影响。可以在规划质量管理过程中使用，以确定测试的数量和类别，以及这些测试对质量成本的影响。DOE也有助于产品或过程的优化。它用来降低产品性能对各种环境变化或制造过程变化的敏感度。该技术的一个重要特征是，它为系统地改变所有重要因素（而不是每次只改变一个因素）提供了一种统计框架。通过对实验数据的分析，可以了解产品或流程的最优状态，找到显著影响产品或流程状态的各种因素，并揭示这些因素之间存在的相互影响和协同作用。
• 统计抽样：是指从目标总体中选取部分样本用于检查，抽样的频率和规模影子啊规划质量管理过程中确定，以便在质量成本中考虑测试数量和预期废料等。其拥有丰富的知识体系。在某些应用领域，项目管理团队可能有必要熟悉各种抽样技术，以确定抽取的样本能代表目标总体。
• 其他工具：头脑风暴：用于产生创意的一种技术。
• 力场分析：显示变更的推力和阻力的图形。
• 含义小组技术：先由规模较小的群体进行头脑风暴，提出创意，再由规模较大的群体对创意进行评审。
• 质量管理和控制工具：对已识别的活动进行相互关联和排序的一组工具。
• 会议：项目团队可以召开规划会议来制定质量管理计划。参会人员可以包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、负责项目质量管理活动（规划质量管理、实施质量保证或控制质量）的人员，以及需要参加的其他成员。

7.2.2.3 输出

• 质量管理计划：是项目管理计划的组成部分，描述将如何实施组织的质量政策，以及项目管理团队准备如何达到项目的质量要求。可以是正式或非正式的，非常详细或高度概括的。其风格与详细程度取决于项目的具体需要。应该在项目早起就对质量管理计划进行评审，以确保决策是基于准确信息的。这样的好处是，更加关注项目的价值定位，降低因返工而造成的成本超支金额和进度延误次数。
• 进程改进计划：过程改进计划是项目管理计划的子计划或组成部分。过程改进计划详细说明对项目管理过程和产品开发过程进行分析的各个步骤，以识别增值活动。需要考虑的方面包括：
• 编程边界：描述过程的目的、过程的开始和结束、过程的输入输出、过程责任人和干系人。
• 过程配置：含有确定界面的过程图形，以便于分析。
• 过程测量指标：与控制界限一起，用于分析过程的效率。
• 绩效改进目标：用于指导过程改进活动。
• 质量测量指标：质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何对属性进行测量。通过测量，得到实际数值。测量指标的可允许变动范围成为公差。
• 质量核对单：核对单是一种结构化工具，通常具体列出各项内容，用来核实所要求的一系列步骤是否已得到执行。基于项目需求和实践，核对单可简可繁。许多组织都有标准化的核对单，用来规范地执行经常性任务。在某些应用领域，核对单也可以从专业协会或商业性服务机构获取。质量核对单位该涵盖在范围基准中定义的验收标准。

项目文件更新：

• 干系人登记册；
• 责任分配矩阵；
• WBS和WBS词典。

7.3 实施质量保证

7.3.1 输入、工具与技术、输出

7.3.1.1 输入

• 质量管理计划：描述了项目质量保证和持续过程改进的方法。
• 过程改进计划：应该支持并符合执行组织的过程改进。
• 质量测量指标：提供了应该被测量的属性和允许的偏差。
• 质量控制测量结果：是质量控制活动的结果，用于分析和评估项目过程的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
• 项目文件：可能影响质量保证工作，应该放在配置管理系统内监控。

7.3.1.2 工具与技术

• 质量管理和控制工具：过程使用规划质量管理和控制质量过程的工具和技术，除此之外，还包括：
• 亲和图：亲和图和心智图相似。针对某个问题，产生出可联成有组织的想法模式的各种创意。在项目管理中，使用亲和图确定范围分解的结构，有助于WBS的制定。
• 过程决策程序图（PDPC）：用于理解一个目标与大成此目标的步骤之间的关系。PDPC有助于制定应急计划，因为它能帮助团队预测那些可能破坏目标实现的中间环节。
• 关联图：关系图的变种，有助于在包含相互交叉逻辑关系（可有多达50个相关项）的中等复杂情形中创新地解决问题，可以使用其他工具（诸如亲和图、树形图或鱼骨图）产生的数据，来绘制关联图。
• 树形图，也称系统图：可用于表现诸如WBS、RBS（风险分解结构）和OBS（组织分解结构）的层次分解结构。在项目管理中，树形图依据定义嵌套关系的一套系统规则，用层次分解形式直观地展示父子关系。树形图可以是横向（如风险分解结构）或纵向（如团队层级图或OBS）的。因为树形图中的嵌套分支都终止于单一的决策点，就可以像决策树一样为已系统图解的、数量有限的依赖关系确立预期值。
• 优先矩阵：用来识别关键事项和何时的备选方案，并通过一系列决策，排列出备选方案的优先顺序。先对标准排序和加权，在应用于所有备选方案，计算出数学得分，对备选方案排序。
• 活动网络图过去成为箭头图：包括两种网络图：AOA（活动箭线图）和最常用的AON（活动节点图）。活动网络图连同项目进度计划编制方法一起使用。
• 矩阵图：一种质量管理和控制工具，使用矩阵结构对数据进行分析。在行列交叉的位置展示因素、原因和目标之间的关系强弱。

image

• 质量审计：是用来确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化的、独立的过程。质量审计的目标是：
• 识别全部正在实施的良好及最佳实践；
• 识别全部违规做法、差距及不足；
• 分享所在组织和/或行业中类似项目的良好实践；
• 积极、主动提供协助，已改进过程的执行，从而帮助团队提高生产效率；
• 强调每次审计都应对组织经验教训的积累做出贡献。

采取后续措施纠正问题，可以带来质量成本的降低，并提高发起人或客户对项目产品的接受度。质量审计可事先安排，也可以随即进行；可由内部或外部审计师进行。

质量审计还可以确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预防措施）的实施情况。

• 过程分析：是指按照过程改进计划中概括的步骤来识别所需的改进。它也要检查在过程运行期间遇到的问题、制约因素，以及发现的非增值活动。过程分析包括根本原因——用于识别问题、探究根本原因，并制定预防措施的一种具体技术。

7.3.1.3 输出

• 变更请求：可以提出变更请求，并提交给实施整体变更控制过程，以全面考虑改进建议。可以为采取纠正措施、预防措施或缺陷补救而提出变更请求。
• 项目管理计划更新：
• 质量管理计划；
• 范围管理计划；
• 进度管理计划；
• 成本管理计划。
• 项目文件更新：
• 质量审计报告；
• 培训计划；
• 过程文档。
• 组织过程资产更新：可能需要更新的组织过程资产包括（但不限于）组织的质量标准和质量管理系统。

7.4 控制质量和保障

控制质量过程使用一系列操作技术和活动，来核实已交付的输出是否满足需求，在项目规划和执行阶段开展质量保证，来建立满足干系人需求的信心；在项目执行和收尾阶段开展质量控制，用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。

7.4.1 控制质量

7.4.1.1 输入

• 项目管理计划：包含质量管理计划、用于控制质量。将如何在项目中开展质量控制。
• 质量测量指标：描述了项目或产品属性及其测量方式。包括功能点、平均故障见个时间（MTBF）和平均修复时间（MTTR）。
• 质量核对单：是结构化清单，有助于合适项目工作及其可交付成果是否满足一系列要求。
• 工作绩效数据：
• 实际技术性能（与计划比较）；
• 实际进度绩效（与计划比较）；
• 实际成本绩效（与计划比较）。
• 批准的变更请求：在实施整体变更控制过程中，通过更新变更日志，先是那些变更已经得到批准，那些变更没有得到批准。批准的变更请求可包括各种修正，如缺陷补救、修订的工作方法和修订的进度计划。需要核实批准的变更是否已得到及时实施。
• 可交付成果：是任何独特并可核实的产品、成果或能力，最终将成为项目所需的、确认的可交付成果。
• 项目文件：
• 协议；
• 质量审计报告和变更日志（附有纠正行动计划）；
• 培训计划和效果评估；
• 过程文档；
• 组织过程资产：
• 组织的质量标准和政策；
• 标准化的工作指南；
• 问题与缺陷报告程序及沟通政策；

7.4.1.2 工具与技术

• 统计抽样：按照质量管理计划中的规定，抽取和测量样本。
• 检查：是指检验工作产品，以确定是否符合书面标准。检查的结果通常包括：相关的测量数据。检查可在任何层次上进行。检查也可称为审查、同行审查或巡检。在某些应用领域，这些术语的含义比较狭窄和具体。检查也可用于确认缺陷不久。
• 审查已批准的变更请求：对所有已经批准的变更请求进行审查，以何时他们是否已按照批准的方式得到实施。

7.4.1.3 输出

• 质量控制测量结果：是对质量控制活动的结果的书面记录。应该以规划质量管理过程。
• 确认的变更：对变更或补救过的对象进行检查，做出接受或拒绝的决定，并把决定通知干系人。被拒绝的对象可能需要返工。
• 核实的可交付结果：控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果，是核实的可交付成果。核实的可交付成果是确认范围过程的一项输入，以便正式验收。
• 工作绩效信息：是从控制过程收集，并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。
• 变更请求：如果推荐的纠正措施、预防措施或缺陷补救导致需要对项目管理计划进行变更，则应按照既定的实施整体变更控制过程的要求，提出变更请求。
• 项目管理计划更新：
• 质量管理计划；
• 过程改进计划；
• 项目文件更新：
• 质量标准；
• 协议；
• 质量审计报告和变更日志；
• 培训计划和效果评估；
• 过程文档，如使用其中基本质量工具或资粮管理和控制工具所生成的文档。

组织过程资产更新：

• 完成核对单：如果使用了核对单，完成的核对单就会成为项目文件和组织过程资产的一部分。
• 经验教训文档：偏差的原因、采取纠正措施的理由，以及从控制质量中得到的其他经验教训，都应记录下来，成为项目和执行组织历史数据库的一部分。

7.4.2 控制原则

7.4.2.1 事前控制原则

整个平台建设是一个高技术、高投入的建设过程，任何由于质量问题引起的工程变更必然产生巨大的投资浪费和工期拖延。所以，在信息系统集成过程中应该始终坚持质量的事前控制原则。坚持事前控制原则的关键在于准确了解用户需求，科学地进行信息系统设计。

7.4.2.2 标准原则

目前信息领域已经形成一系列的标准，总的来说，信息领域的标准可以分为：

• 信息技术标准：阐述了信息产品或系统所应该遵循的技术规范；
• 信息管理标准：规定了信息产品或系统设计、实现和维护过程中所应该遵循的行为规范。

这些标准为我们建设高质量的信息系统提供了科学的依据。

因此，在信息系统集成过程中，应该根据信息系统的特点，遵循有关国内外的相关标准进行系统集成，保证集成过程的科学性。

7.4.2.3 阶段性控制原则

根据用户的具体需求，系统地设计和实现系统，因此，它是一个创新的过程。

由于信息系统集成的过程性，这就决定了信息系统的质量控制应该是阶段性的，不可能一蹴而就。换句话说，质量控制应该分阶段实施；应该根据系统的质量总目标形成各个工程阶段的质量目标和具体的质量控制措施，通过实现各阶段的质量目标来完成整个系统的质量目标。

7.4.2.4 定型测试和量化测试相结合原则

由于信息系统特殊性，绝大多数的验证过程是无损的，应该大力提倡使用信息系统的验证手段来保证信息系统的质量，测试是信息系统验证的重要手段之一。

笼统地说，信息系统测试可以分为定性测试和量化测试。

定性测试主要用于系统的功能测试，而量化测试主要用于系统的性能测试，这两种手段可以从不同角度反映信息系统的质量。

7.4.2.5 用户需求复合型原则

衡量信息系统质量的一个重要尺度是用户需求的符合程度。

建成的信息系统应该符合用户的业务功能需求、性能要求和使用习惯要求等。

检验用户需求符合度的主要方法是科学的测试，可以通过测试手段来判定用户需求的符合程度。

7.4.3 控制影响因素

7.4.3.1 全面地、系统地了解用户需求

定义清晰的用户需求是整个系统成败的关键。

要采用科学的方法从事用户需求的调查，这种需求调查不仅应该包括单位管理者和系统维护者意见，而且应该包括最终用户的意见，从而保证用户需求的完整性；同时为了保证用户需求的准确性，用户需求的制定过程应该使用迭代的方式，通过反复征询用户的意见，逐步完善用户需求。

7.4.3.2 充分讨论系统设计方案

系统设计方案描述了被建系统的抽象模型，因此设计方案的科学性和合理性对被建系统的质量具有极其重要的影响。因此，系统设计方案应该进行充分讨论，提高系统设计的质量。其中，系统设计过程中应该注意：用户需求的符合性、技术成熟性和先进性、系统的安全性、系统的可扩展性、所选产品的质量符合性、法律法规的符合性等。

7.4.3.3 设计完整的系统验证方案

在系统设计阶段，根据用户需求书和系统设计方案，制定完整的系统验证方案。

信息系统的验证方法主要包括：模拟仿真的方法和测试的方法。设计现场测试方案时应该充分考虑用户需求的符合性。

7.4.3.4 确定可行的质量控制方案

为了保证系统实施的质量，依据系统设计方案制定一套可行的系统质量控制方案，以便有效地指导系统实施过程。该质量控制方案应该确定系统实施各个阶段的质量控制目标、控制措施、工程质量问题的处理流程、系统实施人员的职责要求等。

7.4.3.5 形成表述规范的设计文档

为了保证系统实施的可操作性和系统的可维护性，设计文档应该采用规范的表述形式。

例如：我们采用标准建模语言UML（Unified Modeling Language）描述软件设计方案，利用甘特图（Gantt Chart）描述工程进度安排等。

7.4.3.6 遵循科学的实施流程和技术要求

系统实施过程应该遵循科学的流程和有关技术要求，坚持按照标准的实施流程完成系统的建设。

系统实施流程应只与系统的需求和类型相关，而不能因人而异。

7.4.3.7 合理进行阶段性测试

系统实施的各个阶段应该遵照质量控制方案的要求，分阶段地进行系统测试，逐步地实现质量控制目标。

对用户系统维护人员的培训及建立完整的工程实施文档也是保证信息系统集成质量的重要内容。

7.4.4 控制具体措施

7.4.4.1 技术保障措施

本项目是一个技术要求高、系统需求复杂的系统工程，需要由具有一定的计算机水平（包括计算机硬件、计算机网络和计算机软件），精通业务并能将其计算机规程化，对计算机软件应用技术和工程有着丰富经验，具有组织过大型项目或工程经验等的各类人员组成的项目组。为了保证项目的顺利完成，技术保障主要包括计算机软件技术和业务应用两个方面。

• 技术方面
• 专家组负责技术体系的建立和实施工作。
• 按照软件工程规范，对软件系统进行透彻分析，制定切实可行的总体方案和实施方案。严格按照需求分析、概要设计、详细设计、数据库设计、测试计划，编码、测试、组装测试等软件工程规范进行。
• 考虑目前现系统的现状，采用当今最先进的、主流的、成熟的数据库和软件工具，应用中间件技术使得本项目的编制和使用规范化、通用化、可升级化。
• 采用对象技术，实现软件产品的柔性制造。
• 应用方面
• 按照业务流程进行软件模块编制，尽量使现有征集模式与软件应用相一致。同时保持模块间的低耦合，保证其独立性、安全性、可靠性。
• 具体业务数据采集系统与统计分析，对决策支持系统进行分层次设计，保证数据的正确性、可靠性。
• 按照管理层次编写数据接口，保证数据传输和处理过程的正确性和实时性。
• 在程序设计时，保持用户界面友好、风格一致，提供完善的功能键和联机帮助信息。
• 建立完整的测试环境，主要是设计一套软件测试数据，减少现场调试和测试的工作量，保证软件产品的可靠性。
• 制定完善的培训计划。

7.4.4.2 管理保障措施

• 工程化开发：项目的开发是一项系统工程，必须按照系统工程的规律组织系统开发，必须建立严格的系统工程控制方法，要求开发组的每一个人都要严格遵守开发规范，以质量控制为核心，紧紧抓住软件开发的各个主要环节，规范开发过程中的全部活动。
• 变更控制与阶段性冻结：一个软件项目的每一个阶段都有明确的任务和成果，在每个阶段结束，都要通过软件配置管理以“冻结”部分成果，作为下一阶段开发的基础，冻结之后不是不能修改，而是修改一定要经过一定的审批程序，并且涉及到项目计划的调整。
• 加强阶段性确认、验证和评审： 通过验证、确认、评审，实现项目的技术把关，避免软件人员在工作中的随意性和不负责任现象，从不同侧面确认系统的正确性、协调性完整性等。
• 面向用户参与的原型演化：特别注意用户的参与。在需求阶段，必须使开发人员与用户进行全面深入的沟通，以明确用户的需要究竟是一个什么样的系统。在设计阶段和测试过程中，要有用户参与，及时获取用户的反馈信息；利用原型与用户交互，根据用户的反馈，不断改进设计。
• 全面测试：系统测试是把住软件质量的关键关口。在系统开发的各个阶段，要采用适当的手段，依据系统需求规格说明书，对系统设计，实现和相应得文档进行全面的测试。

7.4.4.3 质量保障措施

质量好坏是评判本项目是否成功的一个标志。

在本项目实施的前期，项目组将会根据PMP质量管理的有关规范，参照我公司的《质量手册》、《程序文件》、《软件产品及编写企业标准》和国家《软件开发文档规范》，制定项目开发过程中的一系列规范。并由用户方专家组组和我公司的软件测试中心予以控制，建立质量保障体系。

• 开发过程规范：
  • 项目开发过程和管理规范
  • 项目文档和符号使用规范
  • 总体方案设计开发规范
  • 软件设计开发规范
  • 软件编程规范
  • 数据库设计规范
  • 软件测试规范
  • 软件维护规范

制定软件测试的详细计划，对模块测试、集成测试、系统测试和交验测试的各个过程进行控制，保证软件质量处于受控状态。在测试的过程中，建立一套完整的测试数据，使之尽可能包含典型数据、边界条件、误操作等，使软件的可靠、强壮性达到设计要求和应用要求。

为了保证项目开发过程的可追溯性，按照软件编制规范要求，形成如下文档，从另一个方面保证软件的质量。

• 开发过程中相关文档：
  • 需求分析：包括业务流程和总体方案
  • 概要设计说明书
  • 详细设计说明书
  • 数据库设计说明书
  • 用户手册
  • 操作手册
  • 测试计划
  • 测试分析报告
  • 项目开发总结报告

8 项目建设与费用预算

8.1 项目建设内容

本项目将以GIS和BIM三维空间模型为载体，将工程全生命周期的过程信息整合在一起，通过信息传递和交换平台，打破工程中不同阶段、不同专业、不同角色之间的信息沟通壁垒，实现信息的准确传递。并以此为基础，建立工程协同管理平台，围绕规划期、设计期、施工期、运维期的核心管理目标，使管理人员能够通过快速、形象、便捷的信息入口，进行工程全生命周期协同和智慧管理，改变市政行业传统管理和运营模式，提升市政工程的质量和效益。

8.2 建设规模

项目投资总计划额为1100万元。

8.3 项目投资估算

项目计划投资总额为1100万元，其中企业自筹资金917万元，申请本次资助经费183万元。总投资包括：硬件设备购置费23.5万元，软件购置费35.5万元，软件开发费1038万元，审计费3万元。

8.4 项目建设周期

项目建设周期为两年，2015.8.1~2017.7.31。

9 集团建BIM协同管理平台实施策略规划

9.1 集团BIM协同管理平台实施流程

9.1.1 基于里程碑的迭代式开发过程模型

9.1.1.1 项目的实时控制

• 全面采用微软解决方案框架结构模型来进行规划实施；
• 全面采用面向对象的分析设计等软件开发管理系列产品；
• 全面贯彻质量体系标准和BIM软件生产过程标准，建立相应的质量和进度保证体系。

9.1.1.2 四个里程碑

• 前景／范围认可（Vision／Scope Approved）里程碑。
• 项目设计认可（Project Plan Approved）里程碑。
• 范围完成／第一次应用（Scope Complete／First Use）里程碑。
• 系统发布（Release）里程碑。

四个里程碑是用户与项目组之间重要的设计、评估和协调的同步点。

9.1.2 风险控制的时间进度

风险控制的时间进度安排是指在项目中风险程度高的部分优先开发的方法。无论是软件开发项目还是基础信息设施实现项目，风险控制的时间进度安排都很重要。

• 尽早的建立体现概念理解的原型；
• 确定何时完成何种功能特色；
• 根据技术和业务的风险，对工作任务进行优先级划分；
• 在每个里程碑上进行风险复查；
• 风险控制的时间进度安排的一个优势是，在高风险的部分需要比原计划更多的时间时，可以提供更灵活的响应时间。

9.1.3 全面质量管理控制

全面贯彻质量体系标准和CMM软件生产过程标准，严格执行国家有关软件工程的设计规范，建立相应的质量和进度保证体系。

9.1.3.1 测试

• 在开发各阶段进行测试评审，尽早地发现和预防错误，提高软件质量。经过以下四个阶段的测试，直至开发的软件合格，将软件交付用户验收。
• 单元测试
• 组装（集成）测试
• 确认测试
• 系统测试

9.1.3.2 质量保证

• 制定质量保证计划和质量保证标准；
• 明确各阶段的质量保证（文档和程序）工作；
• 各阶段的质量评审；
• 各开发阶段进度管理、质量管理、交接管理、维护体制；
• 贯彻质量体系标准；
• 符合BIM软件生产过程标准。

9.1.4 实施步骤

对于该系统，我们确定了如下的系统实施步骤：

• 成立项目组织机构
• 制定实施计划
• 准备各种数据
• 系统开发和用户化
• 功能模拟运行
• 培训操作人员
• 系统实际运行
• 系统升级和维护

9.1.5 进度计划

image

9.1.5.1 各阶段节点目标

image

9.1.6 各参与方职责

image

9.1.7 责任人

9.1.7.1 项目负责人简介

张三，教授级高工，现任本集团总工程师。曾获得中国铁道学会科学技术奖一等奖、山西省科学技术二等奖、山西省科技进步“金牛奖”先进个人一等奖、XX市优秀工程咨询成果奖一等奖、国家级企业管理现代化创新成果二等奖、XX市管理创新一等奖，撰写并通过认定的国家级工法1项、省部级工法2项，主持过多项隧道与地下工程科技项目研究。现主要从事城市道路隧道工程前期方案研究、设计管理、施工技术管理及建设管理工作。

9.1.8 组织保障

9.1.8.1 人员组织保障

为确保本项目按研究预期方向推进，拟成立项目推进协调组。由XX城投公路集团指定集团总工刘艳滨为项目负责人，XXXX工程所属的第三事业部总工、和项目指挥部的各相关职能部门都派专人参加本项目建设。将要求软件开发单位的项目经理、BIM咨询方、设计方、施工方、监理方等所有BIM参与方均指派代表加入项目建设，组建一个紧密的项目团队。

9.1.8.2 制度保障

在项目研究过程中，建立制度保障措施，确保研究团队与参与方沟通顺畅、各项节点目标按时、保质完成。

• 每周例会：每周召开一次日常工作例会，汇报工作进展，安排工作分工，时刻把握科研工作进展；
• 月度例会：每月召开一次月度分析例会，分析近阶段工作总体进展及存在的问题，及时制定解决方案，并重点安排下阶段的工作要点；
• 节点例会：按项目研究的进度计划及节点目标需要，召开节点例会，详细部署、紧抓进度、及时归纳，全面掌控各节点目标的进展和完成情况；
• 重点例会：根据项目研究开展过程中的重大问题、关键节点的实际需求，召开重点工作推进例会，动员和部署相关工作重点，确保项目研究按时、保质完成。
• 协调例会：根据业主方及项目推进实际需求，定期召开项目推进工作协调例会，与各参与方建立良好的沟通，及时协调各参与方的工作要点及计划安排，确保项目顺利开展。

9.2 项目管理工作

9.2.1 制定进度计划

制定进度计划用于展示平台实施过程中活动之间的关联，以及计划日期、持续时间、里程碑和所需的资源

• 横道图：概括性进度计划，相对易读，用于展示各活动持续时间，用于向集团、事业部管理层汇报平台实施进展情况
• 里程碑图：仅标示出主要可交付成果的计划开始或完成日期，有助于对平台关键节点的开发、测试在进度上进行把控
• 项目进度网络图：详细进度计划，包含时间刻度和活动之间的逻辑关系，用于咨询单位跟踪在整个平台实施过程中的每个活动的进展情况

9.2.2 质量保证

在平台实施过程中反复进行测试，收集测试数据，发现潜在的质量问题并查到到问题的根本原因

• 因果图：用于追溯问题来源，回推到根本原因
• 核查表：用于收集数据的查对清单，合理排列各种事项，以便有效地收集关于潜在质量问题的有用数据

9.2.3 文档管理

• 文档编写
• 开发文档，用于描述开发过程本身，包括：可行性研究报告和项目任务书；需求规格说明；功能规格说明；设计规格说明；开发计划；测试计划；质量保证计划等。
• 产品文档，用于描述开发过程的产物，包括：培训手册，参考手册和用户指南；软件支持手册；产品手册等。
• 管理文档，用于记录项目管理的信息，包括：开发过程中的变更的记录；开发团队的职责定义等。
• 制定文档规范
  • 文档书写规范，对文档中的文本、图形、表格等多种类型制定统一书写规范；
  • 图表编号规范，对文档中的图表进行有规则的编号，方便查找；

9.2.4 变更管理

建立项目基准、变更流程和变更控制委员会。

• 基准管理：基准是变更的依据，首先制定初始基准，此后在平台实施过程中，针对每次批准的变更重新确定基准。
• 建立变更控制流程：建立平台实施过程中需要的变更管理流程，所有变更都必须遵循这个流程进行控制。流程的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识和信息流转等元素有效地综合起来，按科学的顺序进行变更。
• 建立变更控制委员会：建立变更控制委员会并明确其职责，明确变更流程中相关工作的角色及其职责。变更委员会是一个正式的组织，负责审查、评价、批准、推迟或否决项目变更。变更控制委员会由项目所涉及的多方人员共同组成，应当包含集团和事业部的决策人员。

9.2.5 信息安全管理

• 保密性，确保所传输的数据只被其预定的接受者读取。确保数据的保密性的技术包括：
  • 网络安全协议；
  • 身份认证服务；
  • 数据加密
• 完整性，确保接收到的数据就是发送的数据。确保数据的完整性的技术包括：
• CA认证
  • 数字签名
  • 防火墙系统
  • 传输（通信）安全
• 可用性，确保数据在需要时可用。确保数据可用性的技术包括：
  • 磁盘和系统的容错
  • 可接受的登录及进程性能
  • 可靠的功能性的安全进程机制
  • 数据冗余和备份

9.3 集团BIM协同管理平台实施目标

将BIM技术应用贯穿设计、建设和运维全阶段，结合GIS、web等技术搭建一个大型市政工程全生命周期协同管理平台，实现信息集成、共享、更新和管理，保证信息的一致性，实现各参与方的协同交流、信息共享，实现对整个项目的动态控制，为管理和决策提供帮助，提升工程设计、施工的管理水平，减少返工浪费，缩短工期，提高工程质量和投资效益。

以构建“特大型城市道路工程基于BIM全生命周期协同管理平台”为核心，建立工程参建各方的信息网络和信息流动机制，结合计算机技术、BIM技术、数据分析技术，通过基于BIM的中心数据库建设及工程协同管理技术的研究，形成一套可在工程建设行业内复制推广的成套信息技术体系。

具体完成以下目标：

• 满足施工项目管理过程中对BIM信息化平台的业务需求；
• 满足业务需求在异构系统下的融合；
• 满足多种类型终端的功能部署；
• 形成BIM数据资产；

9.4 项目的团队与领导

为了项目的顺利进行，必须建立完善、严密、高效的项目组织机构，以在项目实施的各个阶段，项目各个小组协同工作，使系统保质保量的按期投入运行，圆满完成系统的开发设计任务。

9.4.1 团队结构

image

9.4.2 领导小组

image

9.4.3 协调小组

image

9.4.4 质量管理小组

质量管理贯穿整个项目生命周期的各个阶段。软件开发单位的软件质量计划和计划的执行情况由项目领导小组或委托项目协调小组负责监督审核。

image

9.4.5 需求分析小组

image

9.4.6 系统设计小组

image

9.4.7 软件开发小组

image

9.4.8 系统测试小组

image

9.4.9 文档整理小组

image

9.4.10 系统培训小组

image

9.4.11 系统维护小组

image

9.5 项目培训方案

9.5.1 培训策略及方式

9.5.1.1 培训的重要性

培训是系统实施的重要环节，是系统应用的第一步。通过对参与项目系统决策和实施人员的进行全方位培训，能够提前分析与控制项目的实施风险，统一思想，正确理解和应用平台系统的实施方法和实施过程。通过培训，平台管理人员将深入了解本系统的开发背景、技术资料、开发思路，使其能够得心应手地做好日常管理和维护工作，保证系统的安全、稳定运行。通过培训，操作人员可以正确理解相关的业务流程，熟练掌握各个子系统的详细操作。

9.5.1.2 培训的过程和重要方法

对平台应用系统开发项目的培训将贯穿项目实施的全过程，可分为实施中培训和实施后培训两个阶段：

• 前一阶段培训主要目的在于让参与培训人员熟悉系统的业务流程、掌握系统管理的使用方法，以正确理解本平台的管理思想、实施方法论，掌握管理与控制项目风险的具体方法。
• 后一阶段的培训主要目的则是让参与培训人员学习系统的详细操作方法，掌握正确组织系统所需的静态和动态数据的方法；并且结合实施过程中出现的各种问题，对相关人员进行强化培训，使用户真正应用好系统中的管理思想，实现技术和管理各个层面知识的转移，最终培养出属于自己的系统管理维护团队。

9.5.1.3 培训类型

培训主要分为系统应用和系统管理，这两种培训在培训内容和培训要求方面是有很大差异的，因此，在整个项目培训过程中，针对不同的应用系统、不同的机构人员情况，所关注的培训重点也是不一样的。

9.5.1.4 培训方式

• 集中授课模式（一对多培训）；
• 现场培训；
• 个别操作指导；
• 一对一培训；

9.5.2 培训计划

image

培训时间：培训是项目实施的重要环节之一，详细的培训时间安排请参见实施计划。

另外，项目实施过程中，本集团会重点培训项目的主要技术人员和业务骨干。在实施过程中，逐步把用户业务骨干和操作人员的二次培训交给技术人员和实施小组成员负责，形成企业自己的培训队伍体系。

9.5.3 培训质量考核

为了保证培训质量，每次培训都有必要的考核。考核有下列方式：

• 书面答卷：主要针对系统原理、操作规范方面的考核。
• 实际上机操作：主要针对实践操作技巧和系统配置方面的考核。
• 项目经理评估：主要针对管理制度和岗位规范的考核。对于不能顺利通过考核的人员，项目经理将建议更换人员以保证项目的顺利进行。

9.5.4 培训组织要求

项目过程中的各种系列培训是实施工作的重要内容之一。培训的效果与质量直接影响到本系统的正常使用与管理。为确保达到培训的目标本集团对这个平台应用系统开发项目制定了完善的项目培训组织与要求，通过培训可以为平台应用系统的顺利实施打好坚实的基础。

系统开发项目培训组织与要求：

• 项目双方各指定专人负责培训的全面组织工作，通常由项目经理担任。
• 培训负责人负责安排培训教师，教师提前准备好讲义和教材，建好培训环境，准备考试试题。
• 培训期间所有学员须严格按照《培训计划》的安排参加培训，如对培训工作有任何疑问，须向负责人反映，由双方负责人协调解决各种问题。
• 培训负责人有责任维护好课堂正常秩序，严格课堂纪律，做好培训出勤记录。
• 所有学员必须按时完成教师布置的各项作业。
• 培训结束双方共组织闭卷考试，所有参加培训人员必须参加，考试期间不得有任何形式的舞弊行为。
• 培训结束后企业与河南迪富将对本次培训进行集中总结，并将总结内容向对方通报。

9.5.5 培训提交文档

image

9.5.6 其它培训方式

• 信息服务平台建设
• 灾难恢复计划与业务持续经营
• 信息化咨询
• 网络安全知识与应用
• 软件项目的研发与管理规范
• 其它需要的培训

上述培训可以根据具体需要，自由选择，不是项目实施所必须。

9.6 系统移交

• 项目的建设应严格按照系统工程理论和方法实施。
• 整个系统实施过程应建立完整的资料档案：
• 一方面可保证系统实施具有系统性，编程的设计具有规范性，不会因为程序员的变化影响到系统的改造开发；
• 另一方面可保证系统移交的正常完成；再一点有利于系统移交后的版本升级二次开发等的顺利实现。
• 为保证系统移交后，系统的正常运行，我公司将为企业培训出几名合格的系统管理员。保证系统管理员能完成独立进行系统的日常维护，独立进行各种系统设置工作，能够独立解决系统运行中出现的各种问题（非程序问题），能够独立进行对应用人员的培训工作。以保证我公司技术服务人员阶段撤离后不影响整个系统的运行。
• 各种文档资料的移交，包括：
• 完整的系统需求定型报告；
• 完整的系统设计分析定型报告；
• 完整的数据库结构设计资料；
• 实施过程中的修改意见及修改说明；
• 各种双方协调工作的备忘录。

9.7 评审验收

评审和测试一样，是系统质量保证的又一措施。软件评审的通过，一方面用于净化软件工程的各项活动，同时也标志着我公司在此阶段工作的胜利完成及用户对其功能/质量的认可。

我们认为，在软件改造开发的各个阶段都可进行评审。如：对系统需求分析定型、系统重要功能模块的修改等。系统试运行结束后应组织使用单位人员对软件工程的系统建设进行全面的评审验收。

9.7.1 评审方面

• 功能、逻辑和实现上有无缺陷。
• 是否符合用户需求。
• 是否按照指定的工具和方法加以开发。
• 效率如何。
• 文档是否齐全。
• 在各个局部范围是否已经试用成功。
• 其它。

9.7.2 验收项目

9.7.2.1 功能项测试

对软件需求说明书中的所有功能项进行测试；

9.7.2.2 业务流程测试

对软件项目的典型业务流程进行测试；

9.7.2.3 容错测试

• 系统对用户常见的错误操作是否能进行提示；
• 系统对用户的的操作错误和软件错误，是否有准确、清晰的提示；
• 系统对重要数据的删除是否有警告和确认提示；
• 系统是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。

9.7.2.4 安全性测试

• 系统是否有留痕功能, 即是否保存有用户的操作日志；
• 系统中各种用户的权限分配是否合理；

9.7.2.5 性能测试

对需求说明书中明确的系统性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。

9.7.2.6 易用性测试

• 用户界面是否友好，是否出现中英文混杂的界面；
• 提示信息是否清楚、易理解，是否存在原始的英文提示；
• 各个模块的界面风格是否一致；
• 查询结果的输出方式是否比较直观、合理。

9.7.2.7 适应性测试

参照用户的软、硬件使用环境和需求说明书中的规定，列出开发的系统需要满足的软、硬件环境。对每个环境进行测试。

9.7.2.8 文档测试

用户文档包括: 安装手册、操作手册和维护手册。

对用户文档测试的内容包括:

• 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；
• 用户文档描述的信息是否正确, 是否没有歧义和错误的表达；
• 用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达；
• 用户文档对主要功能和关键操作是否提供应用实例；
• 用户文档是否有详细的目录表和索引表；

9.7.2.9 验收标准

• 软件错误的严重性等级
• 不能执行正常功能或重要功能；
• 严重地影响系统要求或基本功能的实现, 且没有办法解决；
• 严重地影响系统要求或基本功能的实现, 但存在合理的解决办法；
• 使操作者不方便或遇到麻烦, 但不影响执行正常功能或重要功能；
• 其它错误。
• 错误与严重性等级对应表
• 一级错误的描述：没有实现或错误地实现重要的功能；业务流程存在重大隐患；软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；软件在操作过程中由于软件自身的原因对系统或数据造成破坏；在现有的软、硬建设环境下不能实现应有的功能；特殊软件在操作过程中可能危及系统和人身安全等。
• 二级错误的描述：没有实现基本功能，并且不存在替代办法；没有实现重要功能中的部分功能，并且不存在替代办法；业务流程衔接错误；密钥以明文方式存储；没有留痕功能；用户的权限分配不合理；在现有的环境下，不能实现部分功能且没有替代方案；没有满足系统的性能要求。
• 三级错误的描述：这一级的错误是与第二级别的错误相对应的，而第3级错误则存在替代方法；对误操作或错误操作没有提示，导致非法数据进入数据库。
• 四级错误的描述：为易用性方面的错误。比如界面不友好、前后风格不一；中英文混杂；查询结果输出不直观等。
• 五级错误的描述：为文档方面的错误，如安装手册、操作手册、维护手册中的描述错误。

对发现的每一个错误都要确定相应的严重性等级，全部改正方可。

• 验收标准
• 测试用例不通过数的比例<1.7 %；
• 不存在错误等级为1的错误；
• 不存在错误等级为2的错误；
• 错误等级为3的错误数量≤6；
• 所有提交的错误都已得到更正；

10 效益分析

10.1 经济效益

本项目研究成果将为北横工程提供三维可视化信息模型、动态施工管理及投资控制平台，可有效地提高工程效率、减少失误、节省资源，使各参与方都能获益。更为重要的是，可合理降低和有效控制工程建设整体投资，同时为后期运营维护提供便利，在中长期运维期产生的经济效益巨大。

10.2 社会效益

本项目在北横工程建设中的应用，将促进设计、施工阶段的方案优化完善，提高施工组织协调性、有效减少返工误工、降低环境影响。本项目的研究将推动BIM技术在市政工程建设中的应用与发展，将为建设方和政府主管部门提供管理上的便利，对未来城市市政基础设施建设水平的提高产生积极的影响，其总体社会效益十分显著：

• 本项目可以建立相关市政路桥工程BIM信息数据标准，减少数据冗余和避免不兼容。
• 本项目为其他相关市政行业起到示范和标杆作用。
• 本项目的数据信息可以为后期智慧城市、智慧道路等信息化建设提供基础数据。