目录

一 建设目标

二 技术架构

2.1 技术规划方案

2.1.1 基于SOA架构的系统技术框架

2.1.2 以J2EE为核心的技术路线

2.1.3 基于微内核和构件化技术的系统搭建模式

2.1.4 基于HTML5和AJAX为核心的展示框架

2.1.5 基于移动中间件技术的框架路线

2.1.6 基于XML的数据交换

2.1.7 基于WebService的应用系统整合

2.1.8 基于云技术的计算和存储

2.2 系统架构

2.2.1 设备层

2.2.2 网络层

2.2.3 物联云平台层

2.2.4 应用层

2.3 网络架构

2.4 数据库架构

2.5 安全架构设计

2.5.1 防火墙

2.5.2 负载均衡

2.6 技术先进性

2.7 兼容性

2.8 扩展性

2.9 可维护性

2.10 安全性

2.10.1 系统安全

2.11 系统实施方案

2.11.1 项目实施策略

2.11.2 项目实施建设内容

2.11.3 项目管理方案

2.11.3.1 项目范围管理

2.11.3.2 项目进度管理

2.11.3.3 项目配置管理

2.11.3.4 项目变更管理

2.11.3.5 项目文档管理

2.11.3.6 项目风险管理

2.11.3.7 项目沟通管理

2.11.3.8 项目成本管理

2.11.4 项目制度管理

2.11.5 项目需求调研方案

2.11.5.1 需求调研总体流程与相关角色

2.11.5.2 需求获取与确认

2.11.5.3 需求变更管理

2.11.6 项目开发方案

2.11.6.1 开发方法

2.11.6.2 任务描述

2.11.6.3 编码阶段

2.11.6.4 软件实现阶段

2.11.7 安装调试方案

2.11.7.1 任务描述

2.11.7.2 产出物

2.11.8 项目测试方案

2.11.8.1 测试目的

2.11.8.2 测试标准

2.11.8.3 测试人员

2.11.8.4 测试技术

9 推荐测试形式

2.11.8.5 测试步骤

2.11.8.6 测试工具

2.11.8.7 测试管理

2.11.8.8 测试文档

2.11.9 项目试运行方案

2.11.9.1 系统试运行的目的

2.11.9.2 系统试运行过程检验及记录

2.11.9.3 系统的改进和完善

2.11.9.4 文档整理及最终版本发布

2.11.9.5 准备进入正式运行

2.11.10 项目质量保障方案

2.11.10.1 质量管理规划

2.11.10.2 质量控制和保证

2.11.10.3 质量管理举措

2.11.10.4 源代码管理

2.11.11 项目交付物管理

2.11.11.1 保密措施

2.11.12 项目验收方案

2.11.12.1 项目建设验收

2.12 售后服务方案

2.12.1 概述

2.12.2 整体研究方法

2.12.3 运维服务范围

2.12.3.1 现场运维技术支持

2.12.3.2 定制软件维护

2.12.3.3 告警配置与处理服务

2.12.3.4 应用系统部署协助服务

2.12.3.5 快速响应

2.12.3.6 技术支持信息共享服务

2.12.3.7 其他服务内容

2.12.4 售后服务流程

2.12.4.1 服务台

2.12.4.2 事故管理流程

2.12.4.3 问题处理流程

2.12.4.4 变更管理流程

2.12.4.5 发布管理流程

2.12.4.6 配置管理(CM)

2.12.4.7 运行监控流程

2.12.4.8 系统优化流程

2.12.4.9 支持服务流程

2.12.4.10 服务管理流程

2.12.5 服务级别管理

2.12.5.1 服务级别达成准备

2.12.5.2 服务级别管理方法

2.12.5.3 服务级别保障计划

2.12.6 运维服务计划与沟通计划

2.12.6.1 运维服务计划

2.12.6.2 服务沟通计划

2.12.7 运维实施质量管理

2.12.7.1 质量保障方法

三 功能简介

3.1 云平台

3.1.1 :介绍

3.1.2 :功能

1. 数据实时分析和查看

2. 预警信息查看和展示

3. 设备运行态势监控

4. 硬件设备远程和联动

5. 设备巡检和管理

3.2 设备巡检

3.2.1 一:介绍

3.2.2 二:工单系统

3.2.3 三:硬件巡检系统

3.3 在线专家平台

3.3.1 :介绍

3.3.2 :在线专家平台

1. 专家库

2. 论坛交流

3. 专家诊室

3.4 智能硬件

3.4.1 ：虫情检测简介

3.4.2 :虫情检测系统

3.4.3 :病情检测简介

3.4.4 :病情检测系统

3.4.5 ：监控系统简介

3.4.6 :监控系统系统

1. 前端部分:

2. 传输网络部分

3.硬件对接功能

4.平台部分

3.4.7 :土壤墒情监测系统简介

3.4.8 :土壤墒情系统

3.4.9 :气象采集管理系统介绍

3.4.10 :气象采集管理系统

3.4.11 :水肥一体系统介绍

3.4.12 :水肥一体系统功能

四 可视化驾驶舱

4.1 首页

4.2 虫情检测

4.3 病情检测

4.4 监控系统

4.5 土壤墒情检测

4.6 气象检测

4.7 水肥一体化

4.8 设备管理

建设目标

利用科学的方法，精确的数据基础进行精细化管理，不仅为政府监管部门提供可靠准确的数据，方便制定应急措施与方案，同时也可以切实的为农民提供科学、合理的种植办法，增加最终受益，通过感知层的多种传感器将枳壳生产环节中的环境温湿度，土壤温度、土壤水分、土壤肥力、病虫害等数据以多种组网方式上传至云端服务器，并通过预制方案，将数据进行整合、分析、处理，并将最优解决办法反馈至控制机构，并进行喷灌、滴灌、补光、加温、换气、遮阳、补充CO2等具体操作。用最科学的数据去执行最优的解决办法。从而做到更方便、更智能、更高效、更节能。用数据说话，达到科学、安全、高效、优产的最终目标。

技术架构

技术规划方案

基于SOA架构的系统技术框架

面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA作为技术框架平台已经在大量基础平台、物联云对接平台及衍生的应用层系统得到了很好的应用。

利用SOA架构开发的优点：

1）更容易维护

业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。

2）更高的可用性

服务提供者和服务使用者之间的松散耦合关系使得使用者无须了解提供者的具体实现细节。

3）更好的伸缩性

依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。

以SOA为架构的系统平台，不仅可以帮助平台轻松和有效地整合已有应用系统，规范和理顺不同的工作流程，整合信息和人员，并且能够为未来服务平台发展提供一个坚实的基础，避免IT重复投资和高昂的IT维护成本，支撑系统实现随需应变。

以J2EE为核心的技术路线

J2EE是一个开放的开发语言，是目前最流行也是最具有持续发展潜力的开发语言，拥有庞大的用户群体和技术标准规范，特别是在web应用领域，产品群更加丰富，包括web容器、数据库操作、缓存等技术框架成熟稳定，现有大部分web容器都是基于J2EE体系的，包括云计算、分布式框架等等。

J2EE的优越性：

1）保留现存的IT资产：可以充分利用原有的投资，由于基于J2EE平台的产品几乎能在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。

2）高效的开发：J2EE允许公司把一些通用的，很繁琐的服务端任务交给中间件供应商完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应缩短开发时间。

3）支持异构环境：J2EE能够开发部署在异构环境中的可移植程序，基于J2EE的应用程序不依赖于任何特定操作系统、中间件和硬件设备，因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。也允许客户订购与J2EE兼容的第三方的组件，把他们部署到异构环境中，节省了由自己制定整个方案所需的费用。

4）可伸缩性：J2EE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署，这种部署可达数千处理器，实现可高度伸缩的系统，满足未来商业的需求。

5）稳定的可用性：J2EE部署到可靠的操作系统中，他们支持长期的可用性。

采用J2EE技术路线可以更快更好地为系统提供技术支撑，可选择的产品范围也更加广泛，后续的系统维护更加容易便捷，技术风险较小。

基于微内核和构件化技术的系统搭建模式

微内核架构模式可以适用于那些需要适应变化的软件系统。微内核保持系统的稳定性，而构件化则增强系统灵活性，微内核与业务构件化的分离实现了对系统稳定和变化的同时管理。

微内核是由Richard Rashid在卡内基·梅隆大学开发Mach操作系统时提出的概念，目标是建立一个基于消息传送机制的最小内核，以便在此基础上建造对其他操作系统的模拟层来模拟其他操作系统的特性。

由云系统的核心逻辑、流程及构架形成的内核就是云系统引擎。云系统引擎与微内核是一种共生态，都是基于构件化的体系结构，这种结构带来了高层次的抽象、重用与柔性。

对制造公式、模型和核心逻辑实行精炼和优化被称为微内核设计，它可以保持系统内核稳定，以不变应万变。微内核实现了策略和机制分离，它把基础服务功能封装在一个微内核部件内，该内核独立于其他部件工作。由此可见，采用微内核架构的企业构件总线，在一定意义上将商务和技术上的瞬息万变转化成了机遇。

云系统引擎和微内核设计理念的深化了构件化设计思想。内核就是引擎，就是构件总线，运行于这条总线的是业务构件，微内核设计使基础构件与业务构件分离开来，实现业务构件的热插拔。

构件化就是通过构件技术来构造系统。云系统构件化是平台架构的构件化，包括技术架构和业务架构都向构件的方向发展，逐渐摆脱传统体系结构的束缚。它要求在平台内核的基础上，通过业务构件来搭建和构造新的业务系统，因此，平台构件化的真正含义是平台体系结构的转型问题。构件化增强系统灵活性，微内核则保持系统稳定性，而微内核与业务构件化的分离实现了对系统稳定和变化的同时管理。

构件化的价值在于其可复用性、可重构性、可装配、可替换、可组合等特性，这些特性使构件系统具有很好的灵活性和柔性，能够适应变化。这些优良特性对系统适配、流程变革和维护提供了很好的柔性支持能力。

构件化是平台发展的重要方向，而业务构件化是平台构件化的重点。业务构件是业务过程的软件实现，是分布式信息系统自治的、可复用的元素，包括对特定业务概念描述、实现和部署时所必需的所有软件产品，也包括业务流程、用户界面和数据模型，是对一定领域内业务处理共性的抽象化、标准化。基于构件的开发方法能创建可重用的构件并将其组合，用多个业务构件动态地组成一个新的应用系统，提高了效率，降低了开发成本。

基于消息的构件技术是一种采用消息交换思想的构件技术。消息交换是指一系列实体按照一定的标准规范，通过某种通信机制，互相进行消息交换。消息交换网络是构件之间的中介。

消息系统的好处在于它的松耦合，这也是从系统体系结构的视角，克服和解决系统刚性。松耦合意味着模块或构件之间的关联度低，构件内部的聚合度较高，构件增减或功能变化不会影响到其他构件，这样便于系统的装配、局部重构和升级，也有利于构建一个灵活的具有柔性的系统。

基于HTML5和AJAX为核心的展示框架

HTML5是最新一代web展现语言技术，具有良好的扩展能力和本地资源调用能力，2012年Adobe主动放弃移动端Flash技术支持，转向HTML5，国内百度、腾讯等与W3C（万维网联盟）组织合作，宣布参与HTML5标准定制，来自各方面的力量（包括浏览器、开发者、用户等）共同推动HTML5向前发展。2014年10月29日，万维网联盟宣布，经过几乎8年的艰辛努力，该标准规范终于最终制定完成。

HTML5提高了用户体验，加强了视觉感受。HTML5技术在移动端，能够让应用程序回归到网页，并对网页的功能进行扩展，用户不需要下载客户端或插件就能够在线办公、观看视频、操作更加简单，用户体验更好。HTML5的视音频新技术解决了移动端对flash的支持问题。在视音频方面，性能表现比flash要更好。网页表现方面，HTML5中的CSS3特效样式、Canvas、webgl的介入，不仅加强了网页的视觉效果，甚至能够使用户在网页当中看到三维立体特效。

HTML5技术跨平台，适配移动端、PC端、TV端等多终端。传统终端上的Native App，开发者的研发工作必须针对不同的操作系统进行，成本相对较高。Native App还存在着管理成本、存储成本以及性能消耗成本。HTML/JavaScript/ CSS语言所开发的应用只要一次开发就能进入所有浏览器进行分发，从时间和资金成本上讲，远小于跨系统移植。

对于搜索引擎来说，HTML5新增的标签，使搜索引擎更加容易抓取和索引网页，从而驱动网站获得更多的点击流量。

Ajax是基于浏览器的异步调用方法，在地图、交互式web中应用非常广泛，与传统的web请求技术相比，具有如下优点：

1）最大的一点是页面无刷新，在页面内与服务器通信，给用户的体验非常好。

2）使用异步方式与服务器通信，不需要打断用户的操作，具有更加迅速的响应能力。

3）可以把以前一些服务器负担的工作转嫁到客户端，利用客户端闲置的能力来处理，减轻服务器和带宽的负担，节约空间和宽带租用成本。并且减轻服务器的负担，Ajax的原则是“按需取数据”，可以最大程度地减少冗余请求，和响应对服务器造成的负担。

4）Ajax是基于标准化的并被广泛支持的技术，不需要下载插件或者小程序。

基于移动中间件技术的框架路线

移动应用产品往往常常考虑多个平台的支持，单一平台很难保证应用的覆盖面。另外从开发的角度而言.多平台的支持往往需要建立不同的技术团队，而平台之间开发技术也是完全迥异的。开发一个具有相同业务的应用Natural- Application需要使用到不同平台的框架和开发语言。使用ObjectC的iOS和使用Java的Android应用开发技术，几乎是完全无法融合的。

移动中间件技术为移动前端提供访问移动终端设备及资源的接口。采用统一的标准的html、javascript、css等web技术开发。通过不同平台的浏览器访问来实现跨平台。通过javascript脚步代码调用系统资源，以降低开发难度。

移动中间件的优点如下：

1）可跨平台

移动中间件作为跨平台框架，帮我们解决了平台间的差异性。javascript与平台系统的连接由移动中间件框架完成，成为连接移动终端的适配器。移动中间件通过调用javascript调用API库实现和各个平台的SDK进行无差别的交互，以达到调用不同平台手机上摄像头、文件系统、重力感应、GPS定位等功能。

2）易用性

移动中间件开发人员无需直接操作平台资源。对平台资源的操作完成由移动中间件框架完成。开发人员只需要用javascript调用移动中间件，API就可以完成对平台资源操作。

3）提供硬件访问控制

比起传统的Web程序，移动中间件提供了一系列的JS的类，可以直接访问硬件。比如加速、相机、指南针、GPS、文件访问等，可以让你用JS方便的调用系统的硬件，以弥补传统Web程序。

4）方便的安装和使用

移动中间件的架构很复杂，但对于大多数开发者来说，并不需要了解移动中间件内部，只用很简单的配置就可以搭好环境。只用专注写好自己的Web页面就可以了。

基于XML的数据交换

XML正在快速成为标志Internet文档结构和内容的标准语言，数据交换是XML最好的应用。数据交换的核心问题是信息的标准化，主要解决信息的可理解性问题，包括人和机器对信息的理解。而且，更重要的是机器对信息的识别，并能根据数据进行自动处理。XML的出现为信息的标准化提供了有力的工具。

由于不同的应用领域对数据的要求千差万别，因此要想制订一个放之四海而皆准的数据交换标准是不现实的，同时也是不必要的。最典型的做法是在同一应用领域制订一个标准，参与者按照这个标准组织数据，就可以进行数据交换。比如，IBM、UNISYS和其他合作伙伴定义的XMI（XML Metadata Interchange）是一个存储和共享面向对象的程序设计信息的标准。Microsoft和Marimba合作提出的开放软件描述（Open Software Description，简写为OSD）是用于描述软件的一个XML标准。

XML的关键是将数据内容与显示处理分开以提高效率。将需要交换的数据转换为XML文档在各个应用程序之间传递。只要数据交换中各参与方采用统一的XML标签和格式生成XML文档，不同应用系统中不同语言编写的应用程序就可正确识别和解析文档中的数据，实现数据的动态交换。

云系统中的需要对接和交换的数据种类众多，需要使用基于XML的数据交换技术来解决异构数据的集成和交互问题。

基于WebService的应用系统整合

WebService的主要目标是跨平台的可互操作性。WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。WebService有如下好处：

1）跨防火墙的通信

如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，目前主流开发语言都支持WebService技术。

在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上20%的开发时间。另外，一个由WebService组成的中间层，完全可以在应用程序集成或其他场合下重用。最后，通过WebService把应用程序的逻辑和数据“暴露”出来，还可以让其他平台上的客户重用这些应用程序。

2）应用程序集成

企业级的应用程序经常要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在主机上的程序中获取数据，或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService，应用程序可以用标准的方法把功能和数据“暴露”出来，供其他应用程序使用。

3）软件和数据重用

软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，仅限于代码重用，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。

WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。

从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有效的，WebService技术能够满足整个平台中包含各种异构系统整合以及对系统重用性方面的要求。

基于云技术的计算和存储

云计算是一种标准化的IT能力，它是将软件、应用平台、基础设施整合建立起来一个体系，通过Internet技术以按需和自助的方式提供服务。云计算也是虚拟化、效用计算（utilityComputing）、IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）等XaaS（一切皆服务）概念和技术混合演进的结果。2015年1月6日，国务院发布《关于促进云计算创新发展，培育信息产业新业态的意见》，鼓励云计算领域投入和创新。

云计算主要有两大优势，一是节省硬件投资，通过虚拟化等技术使得IT资源的利用率得到提高，而借助SaaS、IaaS、PaaS等服务，无需每个用户都投入资金建立自己的数据中心，就可以灵活满足业务的变化。二是SaaS，云计算和SaaS成为一对“黄金搭档”，云计算托起SaaS，SaaS保持用户对云计算的黏性，SaaS服务是云计算当前最主要、最流行的应用。

目前在云架构中，云计算和云存储是比较成熟的，本项目可以充分利用云提供按需使用的运营模式，比如各部门需要计算和存储空间，可以直接通过IaaS云存储进行动态分配。

在采用云技术的同时，需要综合考虑业务的需要，并不是所有的服务都需要运行在云上，在云和传统模式之间找到一种平衡，比如对于一些交互请求频繁的资源采用传统的模式构件更加稳定可靠。

系统架构

设备层

系统设备层主要分为数据收集设备与逻辑控制设备，数据收集设备负责将虫情测报系统、智能病害监测系统、生物实时预警监控系统、害虫自动性诱监测仪、环境监测系统以及太阳能供电系统等相关设备运行过程中的重要数据进行系统化集中，设备主要分为7大类：

（1）智能虫情测报灯设备，主要包括收集害虫信息，并对信息进行存放与计数，将信息采集上传至物联云平台中心数据库进行分析与存档。

（2）智能孢子捕捉仪设备，主要包括收集空气流动、传染的病害病原菌孢子及花粉尘粒信息，同时将采集的信息及拍照的照片上传至物联云平台中心数据库进行分析与存档。

（3）病虫害物联网监测设备，通过安装固定式枪式摄像机和360°远红外摄像机，并对视频流数据汇聚到局域网及互联网，管理人员可通过移动端设备及管理中心实时查看病虫害情况及周边的环境情况，并对突发异常事件进行记录和记忆。

（4）土壤墒情检测设备，主要包括收集土壤墒情、苗情监测、遥感分析数据等数据，同时将采集的数据上传至物联云平台中心数据库进行分析与存档。

（5）农业气象监测设备，主要包括收集各种环境传感器上报的数据比如温湿度、PM2.5、风速、风向、雨量、土壤，蒸发量等并将数据上传至物联云平台中心数据库进行分析与存档。

（6）太阳能供电设备，通过太阳能供电，提供了物联设备的供电需求，为系统运行提供准确的环境数据支撑。

（7）水肥一体设备，通过将设备采集的数据进行分析后，控制水肥一体设备进行精准灌溉、施肥等操作，提高精准化管理效率。

网络层

各种物联设备与网关之间、网关与物联网平台之间的数据交换形成网络传输层。包括传感器有线组网、短距离无线组网、物联网专网、公共网络与网关进行协议适配。平台通过预设配置将多重网络以固有规则进行统一规划、集中管控，实现多重网络下的分散与统一。

物联云平台层

平台采用B/S经典架构，同时配合移动端专用App或者小程序，实现跨平台、跨地域的统一管理。网关底层设备通过TCP/IP、UDP、HTTP等协议接入管理平台，与平台建立加密通讯连接，同时平台层作为智慧农业的数据支撑层，向上提供应用层的数据支撑及设备控制的底层实现，同时考虑平台的扩展性，可开放相应接口给第三方平台通过API接口实现多平台数据互通。

应用层

应用层具备系统快速定制功能及设备控制功能，根据系统需求及物联云平台提供的数据支撑，实现统一平台，搭建不同子系统的需求，例如智慧农业大数据运营驾驶舱；用于自动灌溉、施肥等功能的智慧农业监控系统；

系统架构示意图

网络架构

数据库架构

采用业界主流的关系型数据库Mysql，非关系型数据库Redis，支撑海量PB级的数据仓库Hive、Hadoop大数据技术来支撑业务的稳定和发展，同时可根据业务需求动态采用主从分离、数据负载均衡等技术，为保证数据的安全性，可考虑做热备、冷备份数据库；同时根据不同的业务维度划分为不同的数据中心，比如虫情数据中心、土壤墒情数据中心等，数据库的整体架构如下：

安全架构设计

防火墙

使用防火墙作为不同网络或网络安全域之间信息的出入口，能根据安全策略控制出入网络的信息流，且本身具有较强的抗攻击能力。它是提供信息安全服务，实现网络和信息安全的基础设施。防火墙在网络间实现访问控制，比如一个是用户的安全网络，称之为“被信任应受保护的网络”，另外一个是其他的非安全网络称为“某个不被信任并且不需要保护的网络”。防火墙位于一个受信任的网络和一个不受信任的网络之间，通过一系列的安全手段来保护受信任网络上的信息。

负载均衡

部署负载均衡设备，通过对服务器、防火墙进行健康和性能检测，将各种应用访问进行动态均衡分发，极大地提高了访问速度，为物联网云平台网络提供了一个高性能的负载均衡解决方案。

负载均衡业务模块提供丰富的健康检测技术，可以进行实时、高效的设备性能探测。同时提供了全面的负载均衡算法，可以根据不同应用场景，采用不同的负载均衡算法，确保服务器访问效率最大化。

技术先进性

信息技术尤其是软件技术发展迅速，新理念、新体系、新技术迭相继推出，这造成了新的、先进的和成熟的技术之间的矛盾。而大规模、全局性的应用系统，其功能和性能要求具有综合性。因此，在设计理念、技术体系、产品选用等方面要求先进性和成熟性的统一，以满足系统在很长的生命周期内有持续的可维护性和可扩展性。

兼容性

系统适用于现有夏坝业务系统及管理制度，并能保持和内部结构一致性，全面提升夏坝整体的管理水平。

扩展性

系统软件可在通用产品版本升级时作同等完整升级，且升级不对使用造成影响。

• 定制部分及功能，定制部分可单独升级，且升级不影响其他部分和功能。

预留通用接口，具备后期开发、对接其他业务子系统的功能，实现业务数据的查询、统计、交换和整合。

系统上线使用后，可对部分页面特定位置的内容板块等进行个性化内容修改。

• 系统上线使用后，可通过扩展容量或者运算能力，实现系统整体性能的提升。

系统上线使用后，在实现基本功能的基础上，增加对外展示应用扩展模块。

可维护性

系统充分利用模块化、结构化程序设计，结构化设计技术、先进的软件开发技术及工具来提高软件质量，从而提升系统的易用性及可维护性，同时拥有良好的系统接口文档、操作手册来实现系统的维护工作。

安全性

系统严格遵守《中华人民共和国计算机信息系统安全保护条例》（国务院令第147号）；以《互联网安全保护技术措施规定》（公安部令第82号）和《信息安全等级保护管理办法》为指导，完善系统的安全技术能力和手段，重点防范WEB攻击，以及信息篡改和窃取；提供访问使用记录分析；具备应急恢复、主动防护、及时升级等安全技术措施；在网络架构上强化WEB应用防护手段。

系统安全

• 系统各项功能开放权限严格与用户所属的角色权限相匹配，拒绝所有非权限范围内的使用、查阅及其他操作。
• 系统后台对用户各项行为操作记录详细日志，支持对日志的查询和统计分析。
• 对上传至系统的文件格式进行后缀与编码解析等多重过滤，防范病毒、木马。
• 采用设备备份、服务备份、数据备份、虚拟化等技术实施相应的备份机制，避免单点故障，提供故障时高可用的切换和恢复机制。
• 提供对系统设备、服务、网络（登录用户使用流量、当前并发数）状态的监控与管理。
• 通过建立索引、自动清理等方式优化数据库和应用，保持数据库、应用服务的高效和稳定。

系统实施方案

本章节根据夏坝村智慧农业建设要求对本项目实施方案进行详实、全面、合理、具有针对性、可行性以及符合项目需求的实施方案，包括提供的项目进度和质量保障方案、项目实施的项目组织、管理方案、项目实施、工程进度及保障、试运行及验收方案等。

项目实施策略

根据项目建设重点难点的分析和项目实施内容的分析，我们建议项目采取以下实施策略：

• 成立由甲乙双方高层领导牵头的项目领导小组，保证项目实施资源

成立由甲乙双方领导牵头的项目领导小组，作为决策和协调机构，切实做好夏坝智慧农业项目建设战略、总体规划、关键实施方案、重大项目等的决策工作，保障项目建设资金、人员等实施资源按时到位。

• 充分利用公司积累，保证项目实施周期和质量

建设时间紧、任务重。夏坝智慧农业项目开展物联网关接入平台、物联云平台、智慧农业应用平台包括农业大数据驾驶舱等内容的建设，本公司也拥有丰富的智慧农业建设实施经验和大量的优秀业务和技术人员：在公司层面，基于公司的知识管理和共享体系，通过多年积累，业务需求积淀可以得到充分利用，同时，在人员技能上，本公司不乏高级的业务分析人员。项目建设过程中必须挖掘利用XXXX大坪村已有的积累，基于已有的成果开展建设，如各类定制应用、各类服务的方法性、制度性、操作性文档，保证项目实施周期和质量。

• “总分总”项目建设模式，支持需求渐进和专业分工，保障项目整体性和可持续性

所谓“总分总”是指项目总体设计、项目各分项任务并行推进、系统总体集成三个阶段，是将所有建设任务视为集成的整体，定义项目的总体架构和集成规范，明确项目的边界、依赖关系和关键路径，分项开发，运用集成规范指导信息系统建设可控而有序地开发；总体集成管理、总体服务，使得集成在一起的各项数据、信息系统形成合力，对项目建设和运行发挥重要作用。

• 统一组织、成熟团队、规范管理、工具支撑

夏坝智慧农业项目建设工程项目，存在建设内容涉及面广、业务复杂多样参与方众多等问题。每一项具体建设内容既相对独立，同时与其他建设内容紧密相关。随着项目的逐步开展，会出现从单一工作重点到多个项目齐头并进的局面，因此，需要建立统一的项目管理组织，运用统一项目管理管理理念和专业管理工具，进行统一规划、设计，做全局重大决策，协调各种资源，促进资源的合理分配；同时各建设小组之间通过专业化分工与协作，分别完成各自建设任务，通过统一组织、协调资源、专业分工，最终为采购人提供全局、持续、高质量的服务。

同时，为了保证开发过程，控制开发质量，需要一套切实可行的项目管理规范，通过对多年的软件工程项目经验的总结，归纳出一套新型智慧农业建设项目建设管理规范，概括为“四个统一”、“三条线”。

四统一管理是指：统一交付文件模板、统一配置管理、统一设计Review、统一发布管理。

三条线指：文档管理、源代码控制、提交物版本控制。

项目实施建设内容

本期项目的实施建设内容如下：

1. 物联网云平台

物联云平台主要使用者是系统管理员，业务人员及系统运维人员和项目建设开发公司等，物联网云平台通过集成不同协议的物联设备，统一汇集到一个平台上，同时平台提供设备管理、设备巡检、设备维护、设备突发事件处理的闭环等功能，同时针对物联设备上报的数据建设虫情监测、病情监测、监控系统、土壤墒情监测、气象监测等应用功能，同时专家可通过远程诊断的方式给出相应的建议及解决方案。

2）可视化驾驶舱

基于农业大数据，提供数据可视化功能，其中包含GIS标记的设备在离线状态、设备的数据详情、收发情况、苗情预警、实时监控系统，同时提供各种各样的数据指标展示，比如设备的接入数量情况，CO2、 PM2.5、土壤检测值等辅助领导给出关键决策。

项目管理方案

项目工作方法是确保项目成功的基石，国际经验表明，项目成功的70％因素在于项目管理和工作方法的恰当与否。

项目工作管理是面向目标和面向规范工作过程的管理。因此，目标的严肃性必须严格强调。

工作过程的规范化应得到首要的尊重。

本章节将着重论述我公司对项目管理工作方法的一贯原则和做法，主要包括项目整体管理、项目需求管理、项目范围管理、项目进度管理、项目配置管理、项目变更管理、项目文档管理、项目风险管理、项目沟通管理和项目基本管理等内容。

项目范围管理

定义项目范围是定义项目过程的关键一环，管理项目范围是项目管理重要组成部分。

项目的范围管理主要包括界定项目需求边界，定义及控制项目应该包括或不包括的内容，以及发生范围变更时的处理办法，保证项目完成所有应该完成的工作，并且不会蔓延。

编制范围计划

编制项目范围计划是项目管理的关键一环，其目的是确定项目的边界和最终产品提交物，使项目参与人对项目范围的达成共识，并以此作为未来项目决策的基准。对于软件项目，项目范围主要集中在需求以及最终项目完成的提交物。编制范围计划就是以文件的形式定义哪些工作是包括在该项目内，而哪些工作又是在该项目范围之外。

需求识别与需求范围确定应从多个角度来确定系统需求，具体可分为：

• 用户需求

掌握用户希望将来的系统完成哪些任务，要达成哪些目标。用户需求可能带有部分主观性，需要双方沟通，达成一致理解，最终形成业务需求。

• 业务需求

不考虑主观因素和客观条件限制，业务系统本身应具备的功能和性能要求，使用户利用系统能够完成他们的任务。

• 质量需求

如功能、效率、稳定性、易用性、可移植性等。

• 潜在需求与约束

客户未规定，但预期或规定用途所必需的产品要求。它包括产品必须遵从的标准、规范、法律法规等。

范围管理

软件项目的范围管理主要指对软件需求的管理，需求获取与管理控制活动不能仅限于需求分析，即便到系统维护期还可能有新的需求出现，因而需求管理贯穿于项目生存全部过程中。建立全程的需求范围管理对项目的成功非常重要。

需求范围管理的目的是保持项目进行过程中计划、工作产品以及相关活动与软件需求保持一致性，确保进度计划的实现，降低成本，减少浪费，提高客户满意度。主要内容包括需求变更控制。

需求变更控制首先是制定变更控制计划和变更流程。项目各方一起制定需求变更控制办法，并作为需求分析报告的一部分是实施需求范围管理的一种可行办法。

系统需求范围以项目各方确认的需求分析报告或需求规格说明书为准，不能随意变更，如有变更，必须在受控状态下进行。客户或项目开发小组提出需求变更或功能增加时，须按照双方约定的需求变更控制办法执行，填写“变更控制报告”，明确变更所涉及的相关部分，经项目组负责人确认。当变更发生频繁时，双方协商定期提交变更内容。

对可能引起系统结构变化或工作量较大的变更，须经领导小组评审，项目开发小组不能擅自承诺，分析风险以防止给当前系统带来太大冲击。

变更部分应由项目组在适当的时机将变更部分的内容补充到《需求分析报告》或《软件功能规格说明书》中。

项目进度管理

项目进度计划是项目实施和控制的基准和依据。项目进度管理的好坏，直接关系到项目的成败。

制定项目进度计划

项目计划是项目实施的基础，是为方便项目的组织、协调、交流及控制而设计的最有效的工具，它将使所有参与项目实施的成员明确自己的奋斗目标、实现目标的方法、途径及期限，并确保以时间、成本及其他资源需求的最小化实现项目的目标。

项目计划涉及到实施项目的各个环节，计划的合理性和准确性往往关系着项目的成败。计划要力求完备，要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划要力求准确，尽可能提高所依据数据的可靠程度。

由于此项目是与项目采购单位共同开发的项目，其计划需分为：

• 项目实施计划

此为综合性计划，应包括各阶段的目标、工作任务、时间进度、人力分配、环境要求、资源条件、组织结构与分工职责、经费预算等方面的内容。

• 质量保证计划

确定质量保证的人员，把软件开发的质量要求具体规定为在每一个实施阶段中可以检查的质量保证活动，确定各阶段进行技术质量评审的内容、时间进度、评价标准、修正方法等。

• 系统测试计划

规定测试活动的任务、测试方法、测试结果允许的偏差范围、时间进度、资源条件、人员职责等。

• 系统联调计划

规定联调方式、联调内容、联调过程记录、联调结果分析、各方准备、各方人员及职责等。

• 文档编制计划

规定所开发项目应编制的文档种类、内容、时间进度、人员职责等。

• 用户培训计划

规定对用户进行培训的目标、内容要求、时间进度、人员职责等。

• 综合支持计划

规定软件开发过程中所需要的支持，以及如何获取和利用这些支持。

• 系统提交计划

开发项目完成后，将项目提交用户的移交方案与时间进度。

项目进度控制

• 项目进度报告

项目经理必须按时提交项目进度报告，并对其内容负全部责任；

项目进度报告中的“累计已完成工作的百分比确认”、“剩余工作的工时估计”、“汇报期项目工时”对项目分析起着至关重要的作用，各项目经理必须细分项目的工作范围，严肃、谨慎地填写；

• 进度分析与控制

以进度计划为基准，综合分析项目报告、已完成项目成果、项目费用等信息，及时发现项目进度中隐含的问题，并采取相应的措施进行弥补和更正。

• 进度计划变更

随着项目的进展，核对项目实际信息的分析和汇总，若初始的计划与实际进度出现偏差，可根据实际情况提出修订计划。

进度计划变更必须报请项目管理组审批，在批准之后执行。

项目配置管理

为了使项目组的产出物能够得到有序完整的管理，整个项目应该有统一的项目配置管理策略。

配置管理策略

制定配置管理策略，建立变更控制流程，并在配置管理计划中记录此信息。

• 项目构件

通过配置软件构件从而使项目成为由构件构成的体系结构。构件可以是软件系统中相对独立的模块、子系统或包。

将多个工件组织为构件（在UCM中构件指一个VOB的根目录或VOB的某个第一层子目录）从而扩展了软件工件管理的版本控制能力，即用基线对构件而不是构件中众多的版本进行标识，然后用这一基线作为新的开发起点并更新开发人员的工作空间。

基于多个构件的组合基线，即多个构件之间可以建立依赖关系，一旦底层构件的基线发生变化，如生成一条新基线，其上层构件相应地也自动建立起一条基线，该基线自动包含底层构件基线。

开发人员在交付变更到公共集成流时可以周期性地更新他们私有开发流中的构件。然后开发团队可以根据开发过程的当前阶段和质量级别对构件进行评级。项目策略确定了在开发人员变基之前构件基线必须达到的质量级别以及其他开发团队成员（如测试人员）应该如何同构件基线交互。在稍后会对项目以及项目策略做更多描述。

• 对于不同特性的并行开发

项目的应用软件系统包含多个相对独立的子系统和组件，开发时会由不同的相对独立的开发小组来实现。这样就会出现在集成或“合版本”时正常的开发被迫停止，或者因个别特性无法按期完成而影响整个项目的进度。结合我们的经验建议使用的ClearCase工具的特性，建议项目配置采用针对不同特性的并行开发策略：

首先在主分支（main分支）上建立一个集成分支，然后在集成分支上再根据不同特性进行分支，每个特性拥有自己独立的分支，如分支“特性1”对应软件特性1，所有关于特性1的开发都在该分支上进行，不同特性的开发由于在各自的特性分支上进行，因此相互独立、互不影响。开发完成的特性通过智能的、自动化的合并功能集成到集成分支上，显然，该集成过程不影响其他特性的正常开发，全部业已完成的特性进一步合并到主分支进行测试和发布，从而实现“完成多少，发布多少”的管理目标。

• 基线和提升级别

基线在项目的里程碑或适当时间点被创建，对某个时间点构成软件系统所有物件的版本描述。这些物件在打基线后可以被更改，但更改是作为变更控制委员会过程的一部分来记录和控制的。

本项目中，将在集成流或特性流上创建基线。项目集成人员是在集成流上唯一合法能够打基线的人员。在特性流上，可以由小组的集成人员负责创建基线，并且负责向集成流上提交合并。

它们包括被拒绝（rejected），初始（initial），通过构建（built），已测试（tested）和已发布（released）。另外，UCM允许开发团队用他们自己的命名规范和提升策略对这些预定义基线级别进行定制。

基线提升级别标识了一个基线的质量，下表定义了本项目的提升级别：

提升级别	描述
已发布	系统已经通过了所有级别的测试，准备发布
已测试	系统已经通过功能，装载，性能和压力测试
通过构建	成功编译和连接
初始	初始状态
被拒绝	坏基线，不使用的基线

配置管理资源配备

项目配置管理相关的角色和职责分配如下（具体人员的映射可以在项目初始阶段的配置管理计划中细化明确）。

配置管理角色	配置活动	与工具相关的活动
配置经理	设置配置环境制定配置策略编写配置计划创建部署单元报告配置状态执行配置审核	定义开发组件创建配置管理库定义访问控制定义总体策略
项目经理	安排日程分配工作	定义集成里程碑分配活动
变更控制经理	建立变更控制流程复审变更请求确认重复或拒绝的变更请求	定义变更控制流程（由配置经理或其他熟悉CQ开发的人员辅助）确认变更请求被接受或拒绝或视为重复
项目集成人员/版本工程师	创建集成空间计划系统的集成创建基线集成系统提升基线	确定候选构造建立软件系统基线建立对外部的发布与外部项目集成为发布工件选择位置
开发人员	创建个人工作空间进行修改提交修改更新开发空间提交变更请求更新变更请求	创建开发视图在配置项上工作提交变化变基工作空间
CC/CQ 管理员		ClearCase/ClearQuest备份和恢复ClearCase/ClearQuest 维护ClearCase/ClearQuest 用户管理

配置管理活动

定义项目基线

需求基线：需求分析基线是指经过联合评审确认的《软件需求分析说明书》中说明的有关事项，具体包括：业务需求分析中的业务流程图（功能需求）、性能需求描述（可用性、安全性、可维护性、可移植性等）、系统运行平台（硬件平台、网络平台、操作系统平台、数据库平台等）。

功能基线：功能基线主要是指经过联合评审确认的“概要设计说明书”和“详细西设计说明书”中的各项规格说明。

产品基线：在软件测试阶段结束时，经过正式评审和批准的软件产品和全部配置项的规格说明。

其他基线：如项目计划

基线既是前一阶段工作的成果，又是下一阶段工作的依据，为此，必须有严格的手段控制基线的确认、标识和更改，其要点为：经过联合评审确认需求基线后，设计人员在进行系统的设计时，必须严格按照需求分析文档所规定的范围进行。项目阶段性计划和详细计划经部门经理和项目经理签字确认后，各小组按既定的进度要求制定周计划，在例会上经相关经理批准后确定实施。严格执行项目领导小组制定的阶段时间表，每周例会总结计划实施和完成情况；计划完成不好的，找出原因，制定具体措施，争取把失去的时间补回来。

在需求分析阶段，若存在不确定的用户需求，要将其划为“暂时未明确”（不列入基线），或标识“搁置”。严格执行变更规程，在变更申请、变更审批、变更实施、变更确认和变更传递过程中的各步骤都有跟踪监控处理，涉及基线变更的，要经项目协调领导小组审核确定并由项目经理签字后才能修改。

对计划的变更，分为两个层次，一是阶段性计划的变更，由项目协调领导小组召开相关人员参加的会议进行讨论后确定，确定变更后报项目协调领导小组审批确认。确认后由项目经理及时部署相关修改措施，保证项目能按新的计划正常完成。二是详细计划的变更，在不影响阶段性计划的前提下，由相关经理确认后修改，并及时布置相关的修改措施。

项目中的开发规范确定之后，项目全体开发人员在开发过程中要严格遵守，对其变更要严格执行变更规程。

定义受控配置项

配置项类型主要包括：

• 硬件设备资源配置项

受控的硬件设备资源配置项包括在项目开发过程中的所有硬件设备。

• 软件设备资源配置项

受控的软件设备资源配置项包括在项目开发过程中所使用的所有的软件设备，如：操作系统，数据库管理系统，开发工具软件和开发中所使用的各类应用软件和防病毒软件。

• 开发阶段所产生的各类技术文档和管理文档配置项

受控的文档配置项包括：开发各个阶段所产生的各类技术文档、管理类文档以及规范类文档的正式版本。

• 软件产品配置项

为本项目所产生的软件产品及其相关部件，包括：应用源代码、公用组件源代码，后台的数据库表结构和数据库SQL脚本、数据字典等，一旦提交，即要对其整个过程进行监控。定义配置项的标志与状态跟踪方法。

版本移交

项目结束后，开发商负责将配置库中所有内容移交给用户。同时，协助业主完成对现有系统的版本管理工作。

创建项目配置环境

在项目的早期阶段，需要创建项目的配置环境，在此环境中，项目组可以对整个软件系统进行开发、构建。

该过程主要包括以下步骤：

• 安装配置管理工具。
• 设置开发环境，创建构件的储存库、设置软件系统目录结构，导入所有的已有文件。
• 设置配置策略，如安全访问策略、开发策略等。
• 定义基线晋升级别

变更与交付工件

项目工件的控制版本通常在限制访问权限的中心储存库中维护。借助于检入和检出操作，项目组的所有成员都可以得到授权访问的工件的特定版本，对其做出变更，重新提交并生成工件的最新控制版本。

变更与交付工件包括以下步骤：

• 加入项目，创建个人工作空间

个人工作空间为角色提供了一个变更工件的环境，在此环境中所做的变更可以被其他角色立刻见到。

• 提交变更请求

使用标准的、已记录的变更控制流程，确保在建项目中进行统一的变更，并将软件系统的状态、对其所做的变更以及这些变更对成本和计划的影响通知给项目相关成员。任意角色在整个项目生命周期内都可以提交对任何配置项的变更请求。

• 进行变更

每个人对于指派给自己的任务，执行不同的活动，来更新或添加工件。

借助配置管理工具的检入和检出操作，项目组成员可以得到工件的特定版本，对其做出变更，重新提交并生成工件的最新控制版本。这一步骤的目的在于确保开发人员遵循“检入和检出”流程，对进行版本控制的工件做出变更。

在使用基于活动的配置管理工具时，每个人可以在自己的桌面上看到指派给自己的任务，对工件的变更将关联到相应的任务上，即通过活动来组织工件的版本。

• 更新工作空间

用推荐使用的基线中的文件来更新显示在角色的个人工作空间中的文件，确保使用最新版本的项目文件。当有文件版本发生冲突时，进行合并操作。

执行单元测试核实变更是正确的，没有缺陷。

• 交付变更内容

在确认变更和集成版本没有冲突时，将变更从个人工作空间交付到集成工作空间。

更新变更请求的状态将变更活动通知给项目组相关成员。

管理基线

管理基线的活动包括建立基线和晋升基线。

当子系统达到指定的成熟度后为其建立基线，可以在随后的项目迭代中重复使用，或者用作发布。

根据项目配置管理策略晋升基线。晋升基线反映基线达到的软件成熟度、稳定性和质量级别。

基线的命名要遵循命名规范，便于其他人员的使用。

信息系统交付

系统交付管理流程是确保向客户提交了正确的软件系统版本，包括源代码和相关的文档。

项目开发过程中的所有工件（源代码、可执行软件系统和相关文档）都进行了统一标识和版本管理，并且有变更请求管理流程控制变更，保证了源代码、可执行软件系统和相关文档的一致性。

每次的软件系统交付，至少包含可执行的软件系统、发布说明、用户支持材料。

软件系统交付流程为：

• 配置经理取得可以发布的软件系统（可以是最终软件系统的部分）版本的拷贝。该软件系统是集成了系统多个构件、可执行的并通过了所有测试，通常被标记在已发布基线中。
• 测试组执行测试/再测试。测试结果反馈给项目经理和项目配置经理。如果存在缺陷，则项目经理负责组织项目组进行修复，更新源代码和相关基线。重复直到测试通过或者经项目经理评估确定软件系统可以提交。
• 项目配置经理将可以发布的软件系统（包括源代码、可执行文件和相关文档）晋升基线为已发布，并生成软件系统发布说明，描述软件系统版本的相关信息。
• 项目经理按照约定方式交付软件系统，并接收客户方的反馈。

变更请求管理

提供组织级的标准的变更控制流程管理项目的变更，确保项目中所做的变更保持一致，并将软件系统的状态、对其所做的变更以及这些变更对成本和时间表的影响通知给有关的涉众。

变更控制委员会

组建变更控制委员会 (CCB)，由他们批准对已建立基线的配置项的所有变更。该团队的目的在于确保所有提出的变更都得到了妥善的技术分析与复审，并已记录备查。

CCB由所有受影响的组织或涉众的代表组成，主要包括客户方代表、项目软件经理、配置经理、架构师、设计师、测试设计师。

CCB 的基本任务是明确软件系统的基线、复审对基线的变更、最后批准、否决变更或延期执行。CCB 必须每周或定期按需召开会议，以此确保变更提议及时得到了复审和处理。开发团队必须将该小组视为解决问题的可靠团体，否则项目将停滞不前。

在考虑是否同意某个变更请求时，CCB将主要从以下方面综合考虑和平衡：

• 大小

必须要变更的现有工作量是多少？

需要添加的多少新工作量？

• 备选方案

是否有备选方案？

• 复杂程度

提议的变更是否容易实现？

变更可能导致哪些连锁反应？

• 严重性

不实施这个请求的会导致哪些影响？

是否涉及到工作或数据丢失？

是否为扩展请求？

是否为次要的错误？

• 进度

何时需要进行变更？

是否可行？

• 影响

进行变更的后果如何？

不进行变更的后果如何？

• 成本

进行变更的成本或节约的资金是多少？

• 与其他变更的关系

其他变更是否可以取代此变更或使其无效吗，或者此变更是否依赖于其他变更？

• 测试

是否存在任何特殊的测试需求？

变更请求流程

变更请求的来源是多方面的，包括了项目相关的所有人员可能就所开发系统提出的任何类型的请求。将这些请求经常两个大类：增强请求和缺陷。对这两种变更请求使用定义的流程：

• 缺陷流程

下表描述在缺陷请求上执行的流程：

活动	描述	角色
Submit	项目的任何有关人员都能提交变更请求（CR Change Request）CR被提交到ClearQuest后进入CCB评审队列，状态为Submitted	测试人员
Assign	将缺陷分配给相关人员，状态为assigned状态	项目经理
Open	缺陷负责人将分配给自己的缺陷打开，进行缺陷修改，状态为opened	开发人员
Postpone	项目人员根据项目目前的进度要求，资源，优先级等因素可以考虑把处于submitted、assigned、opened状态的请求推迟到以后的开发阶段中处理，状态为postponed。	项目经理、开发人员
Duplicate	项目人员判断提交的缺陷请求是重复的，执行Duplicate，状态为duplicated	项目经理、开发人员
Resolve	开发人员对缺陷修改并通过单元测试。状态为resolved	开发人员
Reject	测试人员对已修改的缺陷测试没有通过，执行reject操作，状态为opened	测试人员
Validate	在变更被Resolved后，变更进入测试队列，分配给测试员进行软件系统测试，测试通过执行validate操作，状态为closed	测试人员
Close	对那些延期执行的缺陷根据项目的情况决定关闭操作，状态为closed	项目经理

• 增强请求流程

在需求变更请求流程中不包括任务分配活动，只进行变更的搜集和确认。与需求变更相关的任务分配在任务管理中进行。这种方式适合变更大多覆盖面较大，不能由一个人完成的项目。跟踪需求变更与相关工件的关联通过任务（利用CQ的Record Type间的parent-child实现）间接实现来实现。

下表描述在增强请求上执行的流程：

活动	描述	角色
Submit	项目的任何有关人员都能提交需求变更请求，需求变更请求被提交到ClearQuest后进入CCB评审队列，状态为Submitted	项目经理
Duplicate	判断提交的增强请求是重复的，执行Duplicate，状态为duplicated	CCB
Open	将确定变更的增强请求打开，状态为opened	CCB
Close	对于开发完成的需求变更请求，根据项目的情况决定关闭该请求，状态为closed	CCB
Re_open	将已经解决的请求重新打开，状态为 opened	CCB

• 任务流程

计划的项目任务，在Project中定义后，将任务导入ClearQuest中，用于关联活动影响的工件版本。

下表描述在任务上执行的流程：

活动	描述	角色
Submit	项目经理的任务计划从Project导入ClearQuest	项目经理
Assign	将任务分配给相关人员，状态为assigned状态	项目经理
Activate	开发人员激活分配给自己的任务，生成或修改相应的工件，状态为Active	开发人员
Postpone	开发人员根据项目目前的进度或变更可以考虑把处于Active状态的请求推迟到以后的开发阶段中处理，状态为Submitted。	开发人员
Complete	开发人员完成任务并通过单元测试。状态为Complete	开发人员
Reopen	将已经完成的任务重新打开，状态为 Assign	项目经理

管理贯穿生命周期的工件

贯穿生命周期的变更不只是开发人员对源代码和相关工件的管理，也可以由非开发人员进行管理。这些非开发人员包括分析人员，设计人员以及测试人员。相应的工件包括他们在相关领域产生的工件，例如分析人员所创建的需求文档和用例（use cases），设计人员所建立的设计模型和用例，测试人员建立的测试脚本，测试数据和测试结果。

监测与报告配置状态

监测与报告配置状态，主要包括：

• 确定软件满足功能需求和物理需求。
• 确定工件存储在受控制的库中。
• 确保工件和基线可用。
• 支持项目配置状态统计活动。这些活动基于正式化的记录，并报告已提议变更的状态以及这些变更的实施状态。
• 通过缺陷追踪和报告活动来辅助软件系统复审。
• 确保为追踪进展和趋势而“积累”数据并报告数据。

项目变更管理

项目变更控制的需要

在项目实施过程中，项目的变更是必然存在的，并且合理地变更是应予以允许和尊重的。因此，实施变更的管理目的在于忠实地记录项目演变的过程，有利于项目的跟踪管理，是项目管理工作的重要组成部分。

我公司在项目实施过程中，如果发现需要对系统设计进行必要的变更，或者机房施工需要变更，我们将提前5个工作日提出变更说明，在征得用户方同意后，进行系统重新设计后提交用户审核。

针对系统实施过程中出现的各种变更，我公司将依据项目管理规范之项目变更管理规范执行，其基本过程如下：

实施相关各方有权对需求、工作任务、进度要求、人员调动、经费等提出系统实施变更请求，实施变更提出方或发现方需填写实施变更报告，说明变更前的状态、变更原因、变更的内容，并根据具体内容提交直属负责人、项目经理或工程领导组。

如果项目变更被拒绝，项目经理负责解释原因，并填入项目变更报告。

如果项目变更被接受，项目经理分析由于该项目变更对工作量、费用、进度、人员安排等方面的影响，并将此内容填入实施变更报告。如该变更涉及第两方或转包方，则项目经理必须将项目变更报告提交他们，并取得一致意见。如遇到重大的项目变更，项目经理还必须将实施变更报告提交工程领导组，提请领导组对该实施变更进行讨论和决策。

项目经理于接到变更提出方请求后2个工作日之内，应给予变更提出明确答复。对于提交工程领导组讨论决策的项目变更，领导组应在接到变更提出方请求后3个工作日内给予明确答复。

参与实施合作的相关各方在实施变更报告单上签字认可后，该实施变更生效，项目经理或下辖直属负责人执行变更实施。

项目经理或子系统负责人根据项目变更报告单中进度的变更情况，修改实施进度计划，调整实施组人员组织结构，以及实施组成员的工作安排，修改项目预算等。对于重大变更，项目经理应将实施变更报告提交工程领导组，提请领导组对于实施变更所引起的问题与各方进行协商。

将实施变更报告单以及该变更所引起的进度计划、计划预算、人员组织结构、工作说明书等方面修改版本的提交各相关实施组。

对于由于实施变更所产生的文档、代码等修改，遵照项目管理规范之项目变更管理实施规范执行。

实施组成员以及相关人员有义务及时发现各种实施变更，并通报项目经理。

项目经理有责任追踪实施变更的各项工作过程，直至变更管理工作完成，实施按新的计划执行。

对所有实施变更必须进行管理，并忠实记录变更过程。及时合理地调整因变更引起的进度、预算、人员、工作内容等。

变更控制流程

首先由需求调研人员根据用户提出的需求变更，编写《需求变更报告》提交给项目经理。项目经理接收到变更需求后，查看是否合理、信息是否全面；

项目经理委托有经验的系统设计人员和专家对变更需求进行分析，主要从变更对项目的质量、进度、费用、流程等各方面进行影响分析；

项目经理根据分析报告决定变更需求是否能实施，如果不能实施，提出解决建议并召开由项目小组、公司项目领导小组参加的变更会议；

通过变更会议，对变更进行裁决是否可行，如果通过，则编写《需求变更日志》；

项目经理应及时跟踪变更的执行，并分析对项目实施的实际影响。

项目的变更需求一旦执行，有可能会影响到项目计划的调整，这点在项目管理中要注意及时调整并发布给相关项目组成员。

更改提出

过程设计更改来源于项目设计改进、项目完善以及顾客的要求

自主设计的系统更改来源于

1）在设计阶段中出现的遗漏或错误；

2）顾客要求的改变；

3）设计完成后发现制造安装有困难；

4）安全性、法规或其他要求发生变化；

5）设计评审、验证或确认的要求更改。

非设计部门提出的更改建议，由建议人填写项目功能变更单，并反馈到相应部门。

非自主设计的项目更改来源于顾客的项目功能更改通知单，由销售部负责接收，按公司办公自动化系统（OA）中的工作流程下发。

更改评审

设计更改由项目的主管设计者对更改建议做评审，工程更改由项目的主管单位指定技术人员评审：

1）作出是否同意更改的决定，并将结果回复建议部门。

2）评审的内容主要有：评价对项目的组成部分和已交付项目的影响；对合同、进度和费用的影响；对设计、开发和测试的影响；对维护、用户手册影响等；并保存记录。

用户的项目功能更改通知单由技术部负责评审，主要评审项目功能更改对过程的影响；对在项目的处理等。

对于重大的更改，负责评审的责任单位要进行可行性评审和技术经济分析，必要时组织会议评审，并作出是否采纳或是否要验证和再评审的处理意见。

编制更改方案

一般的更改，由评审人员验证评审内容后直接制定更改通知单；

需要验证的更改，由责任单位人员编制更改方案，并根据更改方案，制定验证方法和要求；

更改验证

更改部门对需要项目功能更改部分，发布验证通知单，明确验证方法和要求。验证单位接收到验证通知单后，开展验证工作，最后由验证单位将验证结果和见证材料提交给主管设计部门。

更改确认

负责评审的责任单位，组织验证结果的评审，作出是否正式更改的决定。

更改批准

更改单由资深的技术人员或技术主管审核，由项目经理批准。

凡设计更改影响到用户要求，要通知用户并得到用户批准。用户批准由设计部门与用户联系并得到结果。

当用户要求时，还应满足附加的验证及确认要求。

更改发布

更改批准后，责任部门下发更改通知单。

更改通知单的编号方法按文件技术性文件编号办法执行。

更改通知单下发时，必须通过个人邮件通知到相关人员。

更改实施

各人员收到邮件通知后，必须在半个工作日查阅更改通知单，并打印出更改通知单通知相关技术人员进行更改处理。

各单位依据更改后的技术文件组织项目功能的开发和测试。

需要得到用户的批准时，由更改的责任单位准备项目功能变更文件，按照项目功能变更程序步骤实施。

项目文档管理

对于信息化建设项目来说，交付物主要是程序、文档和设备，其中程序和文档的管理非常重要，也容易忽视。程序和源代码是应用系统运行的基础，是体现项目价值的重要因素。本节重点介绍文档管理方案。

在本项目实施过程中，由于项目实施的复杂性，参与人员众多以及时间跨度长等因素，所以有关需求、建议、问题、技术方案和会议等都必须文档化、标准化，以便查阅和引用。这些文档伴随着项目实施的各个阶段逐渐充实、完善；与此同时，它们亦记载跟踪了整个实施的过程和成果。

文档编制工具

主要用到以下几种工具：MS Word、MS Excel、MS Visio、MS PowerPoint、MS Project、Rational Rose。

MS Word：主要用来编写描述性文档，例如项目章程、管理流程、需求报告、业务蓝图、项目状态报告、项目总结报告等；

MS Excel：主要用来编制检测表、各种项目计划、数据准备表、问题及变更日志等；

MS Visio：主要用来绘制业务流程图；

MS PowerPoint：主要用来编制各种报告、培训性文档；

MS Project：主要用来制订项目进度计划、资源计划、预算计划，并跟踪项目，生成各种汇报结果；

Rational Rose：主要用来绘制与UML相关的用例图、序列图、活动图、状态图等。

文档分类和命名

项目文档包含用户所要求的各项文档并且按以下情况分类：

文档的命名要求是：从文件名就大概能判断文档的主要内容是什么。文档不只是给自己看的，即使自己看，过了一段时间，也不一定能够很快找到自己想要的文档。文档命名规则为“二级类别_内容摘要_版本（或日期）”，例如：PI_需求规格说明书_V1.0.doc。

版本管理

软件有版本的区别，文档也一样：对于每一份文档的版本号管理，以下面的规则为准：

说明：版本号分总号与子号，例如Vl.0，其中的1为总号，0为子号。

创建文档时为V1.0版；

在未经客户方审阅前的内部审阅和修改。版本总号不变、子号递增，如：V1.1、Vl.2；

经项目经理或客户方的审阅或修改后，则版本号升级，如：V2.0；

当文档最终确定后，统一提交项目经理或文档管理员存档，若需要修改须通过变更流程。

在每一份文档的开头，就会有类似这样一个表格说明了版本控制的信息：

版本/修订版
修改确认日期
修改内容概述
修改人
批准人
备注

文档管理原则

所有的项目文档应严格按照文档控制标准进行：

从项目经理接手项目开始就指定专人建立负责项目文档管理，归集项目所有电子和书面文档，并建立文档目录。文档起草、修改人应标注编写日期和主要修改内容。文档编制时，要严格按照项目规定的标准操作，例如页眉、页脚、标题、内容编排、字体字号等，是否按标准进行，作为项目质量检测的一部分；

文档须通过双方相关责任人和项目经理的会签；最终版本的文档须经过双方项目总监的签署并作为交付文档保存；

文档的发放去向应准确记录收件人的姓名。对于电子文档，收件人应及时回复审阅意见。对于阶段性交付成果应同时保存具备签字的书面介质的文档原件，对于重要的邮件也要作为文档进行存档备份；

对于失效版本的文档，要单独放置在一个目录中，并设置屏蔽权限防止误用；

所有文档均适用于服务合同约定的保密条款；

项目结束后，整理归集所有项目文档，电子文档存放在专门的文件服务器上，或刻盘保存；将书面文档按项目进度分类整理，扉页档案目录整理，装订成册，交项目档案管理人员保存。

项目风险管理

大型系统实施项目，风险巨大。事实上在全世界统计有近36％的大型项目以失败或近似失败而告终。

项目组织体系不仅应作为管理机构，而且要在项目实施过程中，充分考虑风险因素，及早规避，减少项目的损失。

在项目实施过程中，项目的风险是必然存在的，并且合理的风险变化是应予以允许和尊重的。因此，项目风险的管理目的在于忠实地记录项目演变的过程，有利于项目的跟踪管理，是项目管理工作的重要组成部分。

项目风险管理原则

针对项目实施过程中出现的各种变化，我公司将依据自身长期实践总结的项目管理规范之项目变化管理规范执行，其基本原则如下：

项目相关各方有权对需求、工作任务、进度要求、人员调动、经费等提出项目变化请求，项目变化提出方或发现方需填写项目变化报告，说明变化前的状态、变化原因、变化的内容，并提交项目经理。

如果项目变化被拒绝，项目经理应该负责解释原因，并填入项目变化报告。

如果项目变化被接受，项目经理分析由于该项目变化对工作量、费用、进度、人员安排等方面的影响，并将此内容填入项目变化报告。如该变化涉及第三方或转包方，则项目经理必须将项目变化报告提交他们，并取得一致意见。如遇到重大的项目变化，项目经理还必须将项目变化报告提交项目领导小组，提请项目实施领导层对该项目变化进行讨论和决策。

项目经理于接到变化提出方请求后2个工作日之内，应给予变化提出方明确答复。对于提交项目领导小组讨论决策的项目变化，项目领导小组应在接到变化提出方请求后5个日天内给予明确答复。

参与项目合作的相关各方在项目变化报告单上签字认可后，该项目变化生效，项目经理执行变化实施。

项目经理根据项目变化报告单中进度的变化情况，修改项目进度计划，调整项目组人员组织结构，以及项目组成员的工作安排，修改项目预算等。

将项目变化报告单以及该变化所引起的进度计划、计划预算、人员组织结构、工作说明书等方面修改版本的提交项目相关各方。

对于由于项目变化所产生的项目文档、代码等修改，遵照我公司项目管理规范之项目变化管理实施规范执行。

项目组成员以及项目相关人员有义务及时发现各种项目变化，并通报项目经理。

项目经理有责任追踪项目变化的各项工作过程，直至变化管理工作完成，项目按新的项目计划执行。

对所有项目变化必须进行管理，并忠实记录项目变化过程。及时合理地调整因项目变化引起的进度、预算、人员、工作内容等。

变更申请流程

• 提出变更

提出变更需首先填写变更申请表（REQUEST FOR CHANGE，以下简称RFC）。RFC需提交项目领导小组。项目领导小组将就RFC的技术可靠性以及对整个项目的影响作出评估。审批结果将转给项目经理。

• 变更审核

项目领导小组将在接到RFC的10天内给出收讫说明以及分析RFC所需的时间，作出相应的项目变更建议在（ENGINEERINE CHANGE PROPOSAL，以下简称ECP）。

ECP将就RFC中所提出的变更对整个项目的影响作出以下几方面的说明：

基本变更－文件的增改和删除；

测试项目－测试计划、测试和重新测试的变更；

系统性能－确认变更项目对系统性能的影响以及增加或改装其他机器是否必要。

培训－培训计划、课程准备及教材；

其他材料－列出所有其他材料；

人员需求－确认增加其他人员的必要性；

进度－项目进展情况、交付项目的进展速度和协议的终止日期；

费用－变更涉及的费用。

• 变更的认可

任何或有关ECP费用或进展的变更，需由项目参与单位或各使用单位一方授权的代表以书面形式提出，由项目领导小组主任批准。

• 实施

可根据多次变更后的内容修改文件的基本内容并以注有变更日期的文件的形式重新分发。变更只包括项目领导小组通过的内容。

• 变更程序流程

变更提出方提出RFC；

将RFC提交项目经理组织技术专家作技术可行性评定，并给出ECP的准备时间和所需费用估算；

项目领导小组讨论变更所需的时间和费用以及是否批准RFC；

变更提出方做出ECP并确认所需费用和进度；

项目领导小组讨论ECP并提出实施建议；

双方对ECP提出认可并同意变更提出方对合同进行修改；

项目经理对控制程序进行修改。

变更申请

（系统名称）变更申请序号#

申请人：日期：

申请变更内容：申请变更原因：

变更类别（标明一个）A．功能方面 B.运行性能方面 C.文档方面

授权人签字： 日期：

项目沟通管理

我公司将按要求建立与招标人的周报告、周例会制度，将项目工作完成的内容、进度、问题等及时与招标人进行沟通，定期向招标人汇报项目进度，并提交项目报告及相关制度报表。

我公司将做好与项目组内部、与招标人、监理单位及咨询单位的沟通协调工作。

沟通决策制度

决策制度是对本章程中没有涉及、或者有冲突的职责和权利进行决策之制度。决策内容包括各个方面，但是有以下几个原则。

• 项目经理首先决策原则

对于不大的决定，一般由项目经理加以决策，然后提交给项目领导小组。一般在5天之内，如果没有任何一方提出异议，则该决定生效，此异议应以书面方式表达。

• 最高权力机构准则

项目领导小组可以推翻项目经理和任何项目机构的决策。

• 决策书面准则

一切决策应有书面文件，并且在项目经理和项目领导小组各方代表处备案。

• 自主发起决策原则

一切需决策的问题，如果无章程可循，首先遇到此问题的项目成员，需拿出自己的建议，并且提交项目经理，如果项目经理在获得建议后三个工作日内没有口头或书面异议，则该决定生效。

沟通交流制度

准则

• 问题及早提出准则

对自己承担责任的工作，必须及时发现不能恰当完成的因素，并及时向项目经理或有关责任人书面报告，否则不能恰当完成任务的责任在于任务的承担人。

• 及时澄清准则

对所承接的工作，如没有拒绝，则代表接受人已经完全了解工作环境、工作结果要求等多个要素。如果在呈交结果时，与任务要求有出入，则不可以以任何理由解释责任，失败责任在接受人。因此，接受人应及时与任务分派人澄清任务的全部因素。

• 提醒道义准则

所有项目组成员，如发现项目进展隐患，应及时向项目经理或其他人员提醒。不提醒是没有道义的。提醒可以以书面或口头方式。提醒时也要注意不要追究相关人员的后续工作（因为工作安排有各自的计划与方式）。

制度

• 例会制度

A.周例会

由项目经理组织在现场的各方项目组成员参加周例会。总结上周工作，形成项目周报。项目周报的内容包括：上周工作进展报告、本周工作计划、本周任务分派报告。

B.月例会

每月月初，由项目组织项目参加人员召开项目例会，总结这段时间的工作，会后形成会议纪要、项目月报（参见本章报告体系），呈交项目领导小组各成员。

C.季度例会

每个季度，由项目经理组织召开由项目领导小组成员、项目经理参加的季度例会。从宏观上总结这段时间的工作，会后形成会议纪要。

• 抱怨

此处的抱怨，指项目组成员对项目进行过程中历史问题不满。

抱怨需提出书面报告，报告中说明提交人、提交时间、抱怨的内容、现象与事实、抱怨受理者（可为项目经理或其他项目管理者）。并将其提交抱怨受理者。抱怨提交表格式见我公司项目管理文档。

如项目组成员未书面提交抱怨提交表，则不可随便抱怨。

• 问题的提交

参见下节相关内容。

• 审批与确认

审批或确认人在收到抱怨、问题后的三个工作日内向提出人给出书面回复。

• 报告体系

报告分为常规报表和事件触发报表。

问题与争议管理方法

• 问题及早报告原则

对于一个问题，问题发起人必须在问题发生的三日之内，向项目经理提交报告。问题没有及早报告，导致的项目影响，由延误报告人承担。

报告方式：如报告人认为口头报告即可，可以采用口头报告，但是如果口头报告没有使问题得以解决，则视同报告人没有做报告。

• 争议管理

在项目中，任何不能达成一致的观点均为争议，争议应立即向项目的上级单位呈报。

争议应由可以协调争议各方的机构加以裁决，并对裁决承担责任。争议裁决人由项目领导小组和项目经理选择。

争议的最高仲裁机构为项目领导小组。

如项目领导小组仍不能达成一致意见，则遵循，谁决策，谁承担决策失误给对方和项目带来的损失之原则。

失误管理制度

失误可能是多方面的，失误的及早发现是项目成功的基本保障。对失误的严肃性是项目管理的基本要素。因此，每个项目成员均要给予极大重视。

对以下各个事件，必须做出失误分析。

• 计划有重大改动；
• 经费有较大变化；
• 质量不符；
• 进度不符；
• 成果不符；
• 其他重大事情。

项目经理应每月给出失误分析报告，并有每一失误的详细分析报告，此报告应提交相关人员。

如果失误分析报告看不出项目有重大影响，而项目实际有重大问题，则为项目经理之职责。

SOW方法－任务落实的有效方法

本项目是应用软件开发与系统集成类项目，各项任务比较复杂，相互制约，为了保证项目的顺利高效地实施，必须按照项目管理的科学方法进行严格的项目管理和质量监控。

如果说，强有力的组织结构体系，明确的岗位职责分工是项目管理的首要条件，是项目成功的组织保障，那么，科学严谨的项目规范和完整的工作任务陈述文档则是大型系统项目实施的行之有效的方法。

根据本项目的特点，我公司认为，采用我公司在众多项目开发和项目实施中经常使用的工作任务说明书SOW（Statement of work）方式对整个项目实施涉及到的各项任务进行详细的描述和分解，是一个非常有效的工作方法。

• SOW方法的精髓是：国际上著名的WDR方法，即：

Write what you think 写你所想的

Do what you write 做你所写的

Record what you do 记你所做的

SOW方法首先要求把自己的实施想法设计清楚，落实在文字上，避免随意性和模糊性，并且通过充分交流和评审认定下来，避免边干边想带来的低效、重复，浪费、无序，甚至不必要的失败风险。体现整个公司的水平而非个人水平，要求严格按文档规定的时间、任务、责任、步骤和验收方法分派任务、执行任务、检查任务。最后要求对所有工作情况、工作状态，必要要素进行严格记录、备案，以便质量跟踪检查和日后维护。

SOW把每项任务都按任务描述，任务实施步骤和责任分工，任务前提条件，任务成功标志，任务资源需求等各要素进行了详细规定，是项目开发实施的纲领性文档。

• SOW方法的作用和意义是：

清楚阐述每项工作的任务、目标及责任分工，避免口头交接的歧义、误解和推辞借口，有利于责任落实，也方便工作的交流。

完整勾勒出整个项目的任务分解情况，便于制订宏观实施规划，计划制订更科学，更有依据，更有分寸。

任务目的和意义的阐述便于任务传达者、接受者、验收者准备把握该任务目标的核心实质，便于更好地理解任务，充分发挥能动性。

明确规定每项任务的实施步骤，便于逐项落实，记录当前状况，发现推进过程中的问题症结，以利及时采取措施。

任务前提条件表现出各项任务之间的有机关联，便于有关责任人把握轻重缓急，避免无谓浪费，掌握投入时机，有效利用资源。

明确规定验收标准便于参与者有清晰的方向、目标和完成标志，并保证质量，方便验收检查。

每一执行步骤均有明确的提交文档有利于质量控制，为将来的维护管理留下记录以利于追究责任，有据可查。也便于每一个执行人全面、完整、负责地思考问题，交接成果。防止因人员流动而产生的风险。

项目成本管理

成本管理是项目管理和控制的一部分，目的是控制项目费用，使项目在预算中完成。

制定项目预算

在项目计划时，除制定进度计划外，还要根据工作内容制定项目预算。项目预算是项目成本控制的依据。

项目成本控制

• 项目费用报告

项目经理必须定期提交项目费用报告。在费用报告中列出各项费用的预算金额、实际金额，并注明差异原因。

• 成本分析与控制

项目协调管理小组分析项目经理提供的项目费用报告，对于费用与预算之间存在的问题进行分类处理，对重大问题及时报项目实施领导层。

定期收集实际的财务数据，与预算及项目费用报告进行核对，并及时向项目实施领导层进行汇报。

严格费用审批和报销制度，杜绝费用漏洞。

• 项目预算调整

随着项目的进展，项目协调管理小组对项目实际信息的分析和汇总，若初始的费用预算与实际预算出现较大偏差，可根据实际情况提出预算调整计划。

预算调整计划需经项目实施领导层批准后才能生效。

项目制度管理

由于夏坝智慧农业项目建设过程中，任务多，压力大，为了确保按期、保质完成工程任务，必须进一步加强配套管理制度的建设和合同管理；明确实施架构各个组织单元的职责、权限和工作流程；同时创造完善的保障条件。

管理制度是大型项目建设的重要保障，需要全面梳理并制定有效的各项管理制度，指导各组织单元规范有序地开展管理和实施工作。我公司将协助采购人制定项目建设实施期的项目管理办法及实施细则，包括但不限于：沟通管理机制、实施管理机制、档案和资产管理机制、运维管理机制、过程监督机制、安全保密机制、验收机制等，加强夏坝智慧农业项目信息化建设管理措施，实行统筹规划与规范管理，整合信息资源，提高建设管理水平和投资效益，确保夏坝智慧农业项目的建设工作有序开展。

管理办法和实施细则的主要内容如下表：

序号	制度	主要章节
1	《项目管理办法》	总则组织保障招标管理合同管理资金管理档案管理沟通协调实施安排项目验收运行管理法纪保障……
2	《沟通管理机制》	总则职责与分工沟通渠道和方式沟通管理考核……
3	《实施管理机制》	总则组织机构与职责分工项目管理流程附则……
4	《档案和资产管理机制》	总则管理职责档案收集与整理档案验收与移交附件1：文档归档范围和保管期限附件2：档案整理原则和质量要求附件3：分项编号……
5	《运维管理机制》	总则服务内容响应方式服务制度服务流程应急措施响应时间服务评价服务组织……
6	过程监督机制	总则监督组织监督对象监督流程……
7	安全保密机制	总则各方职责安全保密流程……
8	《验收机制》	总则初步验收流程整体验收流程验收工作进度计划……

项目需求调研方案

需求调研总体流程与相关角色

在获取并分析用户需求前，首先要明确需求管理中的各个组织（或角色）与其职责的关系。确保在软件需求、设计和测试中有效明确地了解客户需求，提高产品的质量。具体关系描述如下：

需求获取与确认

调研与需求分析的任务主要是获取用户需求，分析用户需求特点和要求，形成系统需求，作为项目开发工作的基准。

首先需要经双方协调，制定需求调研计划，确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容。用户也必须做好准备工作，经双方同意后按此计划开始调研。调研正式开始前项目开发组应确认所有必要的准备工作已经完成。

按调研计划的进度进行现场调研，主要任务是用业务语言描述客户需求。尽可能及早落实主要算法，确定关键参数，掌握客户政策文件，收集需要打印的报表等。每天应将当天调研的内容整理成文档，并及时与用户确认，提高工作效率。及时将访谈记录、用户政策材料整理成规范格式的需求分析报告，向客户项目组长汇报调研结果，共同对需求分析报告内容进行确认。同时明确今后需求变更控制的规程需求变更控制流程。对于调研期间未落实的问题，以待明确问题的形式体现在需求报告中，并确定落实期限。

项目开发组根据调研中本系统实际系统需求，编写并向工程领导小组提交系统需求分析报告，并和采购人项目建设办公室一起评审，对模糊部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。

对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接影响下一环节的顺利进行。评审通过后的需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其他因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。开发组与客户一起再次确认总体项目计划，共同确定本项目的各项工作进度安排，明确每一阶段的工作内容，以及需要用户配合完成的具体工作。

需求变更管理

需求分析结果经各方确认之后，即形成项目需求基线。确定需求的基线，就是对需求的文档（前景文档、软件需求和用例模型等）进行版本控制，并向开发团队发布基线。即使由于各种原因需求需要发生变更，需要按照需求变更管理流程执行需求变更，梳理和确定新的基线，因此团队能够根据已知的需求基线来区分已知需求、旧需求、新需求以及被增加、删除的或修改的需求。变更管理与各项目干系人关系如下：

项目开发方案

开发方法

在上个世纪60年代中期爆发了众所周知的软件危机，即落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成了一系列的软件开发方法。比较常见的包括瀑布式开发模式和敏捷软件开发模式。敏捷软件开发模式中，近期比较常见是的Scrum开发模式。

瀑布式开发模式

典型的“瀑布模式”的开发过程：从系统需求分析开始，然后着手设计，接着开始前后台开发，最后进行评估并且实施。瀑布开发模式可以令项目管理人员非常方便地把整个项目置于自己的掌握之下。瀑布开发模式限制了开发期间团队间的交互，评估起来相当方便，由于开发计划稳定而且几乎不会发生经常性的变化从而有效地简化了项目开发的管理工作。

1970年温斯顿•罗伊斯（Winston Royce）提出了著名的“瀑布模型”，它一直是被广泛采用的软件开发模型。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

瀑布式开发模式也被称作系统开发生命期模式，简称SDLC（Systems Development Lifecycle Model），这是一种软件开发途径，它把项目分解为有限的阶段。每一个阶段都有序执行，并且依赖于先前已完成的阶段。在采用瀑布开发方法的情况下，开发工作的各个部分必须分别评估，而且通常由不同的开发队伍来实施。具体开发阶段的划分存在一定的争议，但各个阶段基本上取决于任务相对繁重的预先规划。以下就是瀑布开发过程的常见阶段划分：

问题评估

也就是概念形成阶段。明确现有解决方案所存在的问题同时收集相关信息。

需求分析及计划解决方案

提出解决方案的详细说明，包括软件的优点和缺点以及试图解决的问题。确定开发时序，工作结构分解以及其他支持文档。最重要的是明确和分析软件需求。

设计系统架构

提案获得接收之后即可创建解决方案模式，包括工作流和数据流图、模块和功能层次已经其他由解决方案所需要的说明。在这一阶段通常总是伴随一个有力度的检查过程。

开发代码

用以上阶段创建的蓝图编写、调试和单元测试软件代码。接着，集成系统的代码和测试部分。最后测试整个系统。该阶段要到测试完全通过才能结束。

部署和使用系统

部署最终功能，同时向用户提供所需的培训和文档。

维护解决方案

在必要的时候指出和升级软件并且修补软件错误。

有时测试会成为单独的一个阶段，其中包括软件调试而不是在开发阶段进行代码调试。此外，获取软件需求也可能成为独立的阶段。无论采取怎么样的开发路线，以上过程都是一次实施的，同时还要整合到整个解决方案中来。

采用瀑布开发模式是需要一定条件和场合的，并不是所有的解决方案都能采用这种比较严格的开发方式获得成功。

采用瀑布开发方式的用户常见于新负责的项目经理。因为这种方式对项目的估计非常方便。项目开发中涉及到的几乎一切都预先计划，从而便于确定预期的开发成本和开发时间。另一项好处是所有的需求都必须得到确认，在代码编写之前项目结束标准就能确定项目是否成功。这样就保证了项目开发的目的明确性。

由于项目开发工作分阶段实施，一次只有一个团队管理项目。从而简化了项目经理的工作，使得项目经理可以更深入地同每一位团员协作。这样的成员间交流对项目开发的最终成功自然大有裨益。

瀑布开发方式的缺点也是明显的。如果其间的每一阶段没有得到坚决贯彻和实现，那么隐藏的问题最终会影响项目的成功。虽然瀑布管理方式对项目经理而言非常方便，但是对开发人员而言就可能显得太严酷了。因为测试过程在开发阶段之后实施，子系统测试所暴露的问题可能需要立即修改代码，这样就显著增加了计划架构的成本。

调试过程可能非常复杂，原因在于，开发人员在同一阶段通常还可以从事其他项目的开发工作，而所需要的软件修改可能会降低开发人员的生产率和工作质量。有时工作区还必须集中到一个地方来，从而威胁到解决方案的完整性。

另一可能的危险是你只有到解决方案启动的时候才能知道当初所预计的是否成功，所以余下用来改正问题的时间和空间都非常有限。而设计工作上的疏漏和缺陷可能会严重地影响解决方案的启动日期。

这种模式的另一问题在于，除了阶段终止之时，其他时候几乎没有获取反馈的时间，还有，一旦开发工作开始启动那么修改的空间也就没有了。最后，假如系统测试表面功能或者性能没有达到要求也许到这个时候已经没有纠正问题的可能了。

在部署瀑布开发模式之前你必须仔细评估自己所处的环境和条件。如果客户希望在开发工作开始之后加入进来或者你要处理很多未知的问题，那么你或许最好采用一种更具重复性的开发过程。

敏捷软件开发模式

敏捷软件开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。敏捷软件开发以人为核心，强调迭代和循序渐进。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

相对于“非敏捷软件开发”，敏捷软件开发更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。

从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面地沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。

敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

相比瀑布式开发，两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

Scrum开发模式

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums。

Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

在每一次冲刺（Sprint，一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（或产品目标，product backlog），产品订单（或产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。

在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：

会议准时开始。对于迟到者团队常常会制定惩罚措施。不论团队规模大小，会议被限制在一定时间内，如15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：今天你完成了哪些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）

每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

本次项目中推荐采用的开发模式

根据本次项目的相关特点，推荐采用瀑布式开发模式+敏捷式开发模式（Scrum模式）的混合开发模式作为本次项目的开发模式。

本次项目的需求相对明确，基本不会出现需求随时变更的情况。业务相关人员可以在某一时间段内配合项目开发人员进行需求调研、需求确认，但是不能像敏捷开发要求的那样，随时可以参与到项目开发中，并提出相关意见。同时，本次项目的相关里程碑节点基本固定，如需求调研阶段、设计阶段、开发阶段、测试阶段、试运行阶段、验收及系统正式运行。整体上各阶段间划分相对明确，符合瀑布式开发模式的特征。

但是为避免瀑布式开发模式的缺点、发挥人的主观能动性、提高开发效率，建议在设计阶段、开发阶段、测试阶段这三个阶段可以采用敏捷开发模式，如采用Scrum模式进行敏捷开发。将任务划分为很多小的部分，在设计完成后，立刻进行开发，查看设计效果，开发完成后，立刻进行测试，检查开发质量。发现问题，立刻反馈，实现快速迭代，增加开发效率。

任务描述

系统开发我们将采用面向对象的分析设计方法（OOAD）。按照项目实施计划所确定的目标完成需求分析和系统设计等工作。开发组织规划图如下：

（1）系统设计

按照与业务部门确认的需求规格说明书内容、目标完成开发工作，编制需求规格说明书、概要设计说明书、详细设计说明书、数据库设计说明书等文档。

（2）系统开发

按照项目实施计划所确定的目标完成系统开发工作，包括编制系统开发计划、用户手册等文档。

编码阶段

这个阶段是把设计阶段所产生的类以及类之间的交互，在遵守设计时所规定架构的前提下，在特定的编程环境下（如IntelliJ IDEA）、以具体的编程语言（如Java）进行编码实现，程序的注释必须为中文书写且完整（至少达到60%），以便维护并进行单元测试。如下图所示：

良好的、足够详尽的设计是编码生产效率的决定性因素。在编程阶段，所有的概念性问题应该都得到了比较好的解决，程序员只是把设计成果由图纸翻译成可由计算机执行的代码，这项工作应该相对比较直接和简单。即便如此，在代码实现阶段，仍然有可能对设计成果进行优化。好的程序员不管其生产效率，还是其代码实现的质量，都比差的程序员有成倍的优势。特别是在涉及到某些实现需要采用领先技术或复杂算法时，这种情况尤其明显。

软件实现阶段

软件实现过程是依据软件设计文档（含软件体系结构设计、软件详细设计的所有设计文档），编写程序，实现设计要求，对模块进行代码走查和单元测试。软件实现过程中编码实现、代码走查、单元测试大致存在先后关系，不同模块间既可以并行、也可迭代地进行。软件实现管理流程如下图所示：

安装调试方案

任务描述

投标人在安装、部署和调试过程中须严格按照相应的工作规范和流程，做好安装、部署和调试记录。

系统开发完成后，按照夏坝智慧农业建设工程项目需求书以及项目设计方案中明确的所有功能以及性能指标进行逐一测试，包括单元测试、系统测试、性能测试等，测试结果均应得到项目监理单位和招标人的确认，并作为验收文档之一。

产出物

安装、部署和调试记录、测试报告。

项目测试方案

质量是整个软件产品的生命线，而测试是对软件产品质量的保障。在软件生命周期中采用良好的测试，将明显降低完成软件开发与维护的开支。整个业界都认识到测试举足轻重的地位。

测试目的

软件测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

同时，测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户需求的程度，为用户选择与接受软件提供有力的依据。

此外，通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时，通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。

测试标准

我公司的质量体系里关于软件产品开发及测试相关部分的质量要求和《软件测试规范》参考如下标准制定：

ISO/IEC 25051:2014 GB/T 25000.51-2016 《系统与软件工程系统与软件质量要求和评价（SQuaRE） 第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》

ISO/IEC 14598-6:2001 GB/T 18905.6-2002 《软件工程产品评价 第6部分：评价模块的文档编制》

GB/T 25000.21-2019 《系统与软件工程　系统与软件质量要求和评价（SQuaRE）》

GB/T 9386-2008 《计算机软件测试文件编制规范》

GB/T 15532-2008 《计算机软件测试规范》

测试人员

测试小组由专业测试人员和用户代表组成。测试小组负责平台的测试执行，并负责撰写详细的测试报告。

测试技术

按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运行程序，通过人工对程序和文档进行分析和检查；静态测试技术又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：走查、需求确认等。动态测试技术是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

下面所述的白盒测试、黑盒测试、灰盒测试，在实现测试方法上既包括了动态测试也包括了静态测试。

白盒测试

通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

几种典型的白盒测试方法：代码检查法、静态结构分析法、逻辑覆盖法、基本路径测试法等。

黑盒测试

通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。

几种典型的黑盒测试方法：等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、功能图法等。

灰盒测试

介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。

• 开发文档和源程序可以应用走查的方法。
• 单元测试可应用白盒测试的方法。
• 集成测试应用近似灰盒测试的方法。
• 系统测试、确认测试和验收测试应用黑盒测试的方法。

推荐测试形式

内部测试

内部测试在开发人员提交的编码开发测试基础上进行，由各开发小组自行组织，实现组员的交叉测试，测试主要关注点在：功能实现、数据准确性。

单元测试

在系统开发工作完成后，为各个系统软件编码过程和单元测试过程的实施提交详细的计划，建立项目测试体系，成立各个系统独立的测试小组，选择合适的测试工具进行系统单元测试，提交测试报告，由招标人、投标人双方签字确认。

单元测试集中在检查软件的各个单元模块上，通过测试发现该模块的实际功能与功能说明定义不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，开发人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理地输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。

集成测试

集成测试应该在单元测试基础上进行，由开发经理配合协调，实现开发小组内部、开发小组之间的功能联调测试，测试关注点在：接口实现、数据流完备性。

系统测试

系统测试应该在集成测试基础上进行，它通过与应用系统的需求说明书做比较，发现软件与需求说明书不相符合或与之矛盾的地方；系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。系统测试在完成单元测试后，自测合格的基础上由招标人、投标人及监理单位共同开展的系统测试，并形成测试结论。

联调测试

联调测试又称组装测试、联合测试、子系统测试、部件测试。侧重点在于模块间接口的正确性、各模块间的数据流和控制流是否按照设计实现其功能、以及集成后整体功能的正确性。

在系统上线前，我公司提交联调联测方案，与第三方系统完成联调联测工作，形成联调联测测试报告，由招标人、投标人及监理单位三方确认。

用户验收测试

用户验收测试的目的是表明系统能完全按照设计那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误已经基本排除，接下来就应通过验收测试验证软件的整体有效性，即软件的功能和性能达到设计要求和用户的合理期待。

用户验收测试是把系统放到模拟的应用环境下进行的测试，以此检查是否符合需求描述的要求。由于需求描述不仅仅是功能需求，往往还包括性能和质量上的要求，测试时应从用户应用角度考虑问题，结合需求，捕获软件中可能存在的问题。

用户验收测试应该在联调测试基础上进行，由双方项目经理组织实施，测试软件产品的应用符合度：功能是否符合业务需求、数据是否准确。在用户测试阶段还有一项重要测试工作就是进行操作方便性检查，在项目需求阶段，项目组针对业务内容制作了外观包（业务界面原型），在设计开发阶段，针对外观包开发出来了界面，在用户测试阶段针对有实际业务功能和有模拟数据的基础上需要再次进行验证。

用户验收测试与回归测试是系统建设工程中的重要阶段，是检验数据移植、业务处理流程、外围系统接口改造的正确性，保证系统上线后所有业务的正常运行的重要手段。

测试步骤

• 测试计划

主要是给后面的测试工作一些指南。

• 测试记录

主要描述具体的测试步骤。

• 缺陷记录

用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据。

• 测试总结

用于对项目测试工作的执行进行报告和总结，列举和统计相关测试据，对比分析数据及工作中存在的问题为后续工作作出提示，并记录遗留的问题等。

测试工具

测试过程中可根据项目实际需要采用业界通用的测试工具，包括功能测试工具（例如Selenium、UFT），性能测试工具（例如LoadRunner、JMeter），测试管理工具（例如QC、git）。

测试管理

测试策略

开发环境：实行统一的系统管理和安全备份工作。系统部署环境及网络环境均由信息办统一安排。项目系统部署、测试时均要符合本项目对上线软件的性能及安全要求。

软件开发采用通用开发工具，采用Java语言进行开发，不使用任何封闭的专用开发工具，避免由此引起的系统不兼容等问题。

使用要求

系统应具备很好的易用性、易浏览性和可操作性，应采用多层架构的B/S结构，系统应该提供诸如确认、询问、警告、出错报告等易于觉察、易于读取的信息来服务于用户；具有严重后果的操作应当可逆；屏幕输入格式、报表和其他输入/输出宜整齐、清晰和易于浏览。

系统开发不仅要提供用户所需要的功能，界面设计遵循人性化、简单、方便实用的原则，要让用户易于操作、易于使用、界面友好，输入输出方便，检索查询简单快捷，符合用户的业务习惯，满足用户方便、高效、安全的使用要求，具体主要体现在用户操作界面以人为本的设计等方面。

在使用要求方面，至少应包括：

1）系统稳定、可靠和实用，具有快捷键和操作菜单提示功能；

2）人机界面友好、操作方便灵活，使用风格接近终端操作系统视窗；

3）查询结果输出：将查询结果输出到通用的办公文件格式，便于数据的导入导出。

4）具有简单明确易于理解的操作提示

5）功能菜单简明清晰，具有可设定的快捷键和右键菜单；

6）业务流程简单明了，流程设计可因需而变；

7）操作路径简洁，响应速度快；

8）系统门户要直观、清晰的展现系统的全部内容，尽量减少层次和不必要的点击过程。

测试文档

根据我公司长期以来对软件项目的质量控制体系方面的严格管理和执行。测试文档一般包含内容如下：

编写目的

编写本方案的目的，从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等方面进行计划和设计。

术语和缩写词

术语和缩写词如下表：

缩写、术语	解 释
性能测试（performance testing）	运行这些测试通常要确定程序运行有多快，以便确定是否需要优化
负载测试(load testing)	通过在面临很多资源要求的系统上运行，攻击被测程序或系统
可靠性测试（reliability testing）	持续进行的性能测试，目标是发现短序列程序测试遗漏的情况
……	……

测试完成准则

系统满足各项性能要求、能满足实际使用情况并提供测试报告。

测试结果

应对每一轮的整体测试情况编写整体测试小结，作为是否可以进入下一轮整体测试的判断依据之一。

在整体测试阶段完成后，应对测试情况编写整体测试报告；它作为是否可以进入下一实施活动以及切换上线的判断依据之一。

整体测试报告的内容包括测试目标完成情况、整体测试时间安排、测试组织和工作流程、测试结果分析和建议方案等。

项目试运行方案

系统完成开发工作后，为保证系统运行稳定，进入系统试运行阶段。我司将在试运行过程中指派专人负责记录系统运行、使用过程中的情况，解决试运行过程中出现的技术问题，结合招标人及业务部门的需求完善系统各项功能，并形成各系统的试运行记录、试运行报告等过程资料。

系统试运行的目的

1）通过试运行环境的运行使用，检验系统设计和实验功能是否真正满足用户的实际业务需求。在实际的业务环境下，发现软件的问题和错误。

2）通过业务相关人员的使用，对系统的可行性提前进行评估。

3）提前在实际运行环境下，检验系统处理业务峰值数据的稳定性和系统的健壮性。

4）为系统正式运行积累宝贵的经验。

系统试运行过程检验及记录

1）功能满足要求检验：检查系统与用户需求的满足性。

2）系统性能的检验：通过模拟业务处理峰值，进行系统业务处理的压力测试，有效检查系统的处理性能及系统的健壮性情况。

3）系统操作流程、接口数据正确性等方面的检查和分析。

4）与其他系统进行横向比较的意见，包括结构设计的先进性、实用性、可用性等方面的检查。

系统的改进和完善

对于试运行中发现的问题，应具体情况具体处理：

1）对于可能造成系统试运行停顿的问题和错误，必须立即进行修改；

2）对于可能影响系统性能的问题，可以通过收集汇总，进行集中问题处理。

3）对于用户提出的一些新的功能需求，采取合理方法，在项目的下一阶段进行规划和实现。

文档整理及最终版本发布

根据系统试运行过程中发现问题的情况，对项目的相关文档报告，进行整理与修改。

软件通过试运行后，项目组需要对最终形成额软件版本进行整理归档，进行系统包装及安装系统制作等提交用户前的处理工作。

将试运行期间的过程记录整合形成测试报告《系统试运行报告》。

准备进入正式运行

系统试运行工作结束后，系统将被安装到用户方的实际运行环境中，并投入正式运行。

项目质量保障方案

在项目实施过程中，制定整个项目的质量标准，并按照该标准对项目进行监督和检查，是保证整个项目质量的关键。

项目质量控制的目的是确保以下几点：

• 完成应用开发和项目实施的各项任务，并达到预定的目标；
• 最终的系统是稳定的和可用的；
• 确保项目能按预定计划完成。

因此，在项目进行中，需要设立若干控制点，以确保项目的质量是可控的。集成商的项目控制主要包括以下几类：

• 系统方案质量控制；
• 项目初始阶段质量控制；
• 项目进行中质量控制；
• 项目结束阶段质量控制。

质量管理规划

质量保证策略

基于ISO9001标准，制定的程序文件和指导书，以及记录这些流程操作的记录表格，应涵盖合同评审、采购、项目管理、软件开发、变更控制、设计评审、文档控制、测试控制、不合格品控制、现场安装、售后服务、技术支持、培训管理等软件开发的全过程，保证质量体系有效性的管理评审、内审、文件／记录控制、纠正／预防措施控制等程序文件，应为各项操作提供科学合理的指导，以此构成完整严密的质量保证体系。

成立质量控制小组

质量控制小组由用户方、开发方和第三方专业人士组成。质量控制小组需要审核项目各项实施计划，定期检查项目实施进度和项目有关文档，领导和管理项目测试小组的工作。质量控制小组如下表：

	立项书	项目计划书	系统分析书
产品管理	●	●	●
项目管理	●	●	〇
架构设计师	●	●	●
系统分析师	●	●	●
开发	〇	●	●
测试	〇	●	●
领域专家	●	●	●

注：●表示需要提交文档；〇表示不需要提交文档。

检查表

产品质量把关的依据，通过使用检查表来验证过程与工作产品，被检查者与检查者使用相同的检查表，目的是确保产品和过程的质量，通过此检查表将项目中所需要检查的检查点一一列出，并专人逐项过滤。

流程

质量管理是项目经理的一项重要工作。在项目实施过程中要达到要求的水平，需要项目经理按制定的标准去完成任务。

项目的质量管理应着重加强以下几方面的工作：

1）岗位责任制

2）复核与审查

3）文档管理与控制

4）分阶段实际成果检查

标准及控制手段包括：

• 档案（包括数据库）命名标准
• 开发所需的表格
• 有效的变更管理和版本控制
• 完整的测试计划（包括每一阶段的测试）
• 严谨的用户验收过程
• 足够的人员培训

定好的标准是为了让各个组员能按统一规范进行工作，可以避免因为有些组员的经验而导致水准有参差，也避免了因为人员离开而没人可以跟进。良好的变更和版本控制也可以避免版本修改后失控。

质量流程图如下：

质量控制和保证

• 严格项目化管理

在项目实施过程中严格按照事先制订的规范化、标准化执行，加强进度汇报、方案审核和问题反馈处理制度。

• 建立严密的质量控制体系

在本项目实施过程中，按照ISO9001的质量管理标准，建立严密的质量控制体系，严格进行各阶段的测试验收工作。全部的测试面通过技术专家审核并同用户方协商确认。

• 建立完善的项目文档体系

建立一个标准化的项目技术文档体系是项目管理规范化、程序化的重要手段。项目管理过程实行文档化管理，主要管理步骤和过程均有相应的文档记录。其目的是保证每一阶段的运作过程均是有组织的，并且责任明确、交接顺畅和留有依据，同时将对文档规范化的审核纳入阶段审核的工作之中。这些文档对于检查项目的进展、及时形成施工决策、帮助项目在不同阶段的交接等都将发挥重要的作用。

• 良好的协调机制

为了及时掌握项目进展状况，需要建立项目状态定期报告制度和项目随访制度，项目协调管理小组要及时了解、汇总并发布各实施单位的进度情况，与用户进行交流，经常性地如开专题研讨会和协调会，合理调用各类资源，提高质量，降低成本。通过项目实施管理中的集中管理、协调，可快速反馈存在的问题，及时发现问题并解决，使有关各方及时掌握项目动态，做到紧密的合作。

• 强化培训和技术转移

大型计算机应用系统的维护除要求用户制定一系列与之相适应的管理制度外，还要求用户自身必须配备一定数量称职的网络系统管理员、信息系统管理员和应用系统操作员，才能长期有效地保证系统的高质量运行。因此，必须通过组织一系列培训，为各级机构培养一批有技术基础、责任心强、有主动性的管理及操作人员，真正将项目实施中技术转移到用户方，以期最终保证项目结束后整个项目长久、高质、高效地运行。如果条件许可，各级机构应在项目的初期即选派一些人员参与项目开发与实施的全过程，有意识地在实践中培养一批既有计算机技术基础，又懂得业务和管理的人才，为日后系统的改造、升级及换代打下良好的基础。

质量管理举措

质量标准和规范

工程主要遵循以下的通用质量标准和管理、操作规范：

1）ISO9000质量管理规范。

2）CMM项目过程管理规范。

3）我公司内部管理、审核制度。

4）我公司内部工程实施管理方法。

质量管理模型

我公司质量管理模型基于全面质量管理的理念，实现了PDCA循环的自动化，提高了质量管理的效率。质量管理模型全面支持ISO9000/CMM/TSP/PSP等各种过程管理模型，通过软件管理和软件度量，收集项目活动的数据，从而为控制项目进展和过程改进提供量化的依据。

项目质量管理措施

实施先进的过程方法

质量是在过程中生产出来的。我们要保证软件的质量，就必须采用先进的过程方法来提高个人和团队的工作质量。我们深刻体会到采用PSP/TSP过程管理给个人和项目小组工作质量提高所做出的贡献。研究表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误造成的。因此，PSP方法的具体办法是强化设计，提高设计质量。TSP方法的价值在于提倡大家共同分担问题，以及定期找一个局外人来协助审查，通过集体管理和全员责任方法，解决了项目规模扩大时PSP方法中个人工作量过大的问题，从而大大提高产品一次交付的质量，降低初期故障率。

质量管理组织

我公司在项目质量管理上按照 ISO9000的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角色进行说明：

配置管理小组是保证项目开发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述，配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括： 完善各个部门发送需要存档和进行版本控制的代码、文档（包括外来文件）和阶段性成果；对代码、文档等进行单向出入的控制； 对所有存档的文档进行版本控制；提供文档规范，并传达到开发组中。

测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的设计，通常情况下测试可以分为如下几种类型，如：集成测试、压力测试、用户接受测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正确。测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的实现设计要求，在此也只证明了软件正确地反映了设计思想，但是否真正反映了用户的需求仍需要进一步的功能性测试。测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可靠。

质量保证小组作为质量保证的实施小组，主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括：系统分析人员是否正确地反映了用户的需求；软件执行体是否正确地实现了分析人员的设计思想；测试人员是否进行了较为彻底的和全面的测试； 配置管理员是否对文档的规范化进行得比较彻底，版本控制是否有效。

在组织上，他们直接对项目经理负责。

全程测试

测试是贯穿软件建设全程的，只是各个阶段的重点不同而已。在项目建设过程中，我公司采用V测试模型，基于系统运行要求和应用系统需求，在应用系统架构设计及具体应用实现的过程中，逐步展开单元测试、集成测试、压力测试及用户接受测试。

质量保证

质量保证的目标是为管理层提供为获知产品质量信息所需的信息，从而获得产品质量是否符合预定目标的认识和信心。目的是通过形式化的方法来保证规章制度的落实和质量目的的达成，由开发活动的审查和报告构成。

软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。软件质量保证小组需参加所有的评审与检查活动。评审和检查的目的是为了确保软件开发的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在本期建设项目开发过程中，我们将要进行如下评审与检查工作：

阶段评审：在软件开发过程中，定期地或阶段性地对某一开发阶段或某几个开发阶段进行内部评审。根据《开发项目计划》，在本软件的开发过程中将进行以下八次内部评审：第一次评审《项目实施方案》；第二次评审《用户需求说明书》；第三次评审《软件需求规格说明书》；第四次评审《软件概要设计说明书》；第五次评审《软件详细设计说明书》；第六次评审《软件测试计划》；第七次评审《系统联调测试计划》；第八次评审《系统试运行方案》。

在进行了内部评审后，《软件需求规格说明书》、《软件概要设计说明书》、《系统联调测试报告》进行外部评审。

阶段的内部评审工作可由我公司及项目组自行组织评审人员。对于阶段的外部评审需组织专门的评审小组，由用户方指派人员担任评审组长，评审小组成员应该包括用户方代表、软件质量保证小组、我公司人员、专家组，其他参加人员视评审内容而定。

内部评审和外部评审再进行评审前都应填写评审申请表，评审后应填写评审报告。

日常检查：在本项目开发过程中，各子开发小组组长应每周填写项目工作进展周报，项目经理及软件质量保证小组对各开发小组的文档及程序代码进行定期抽查和随机抽查，抽查结果填写模块开发进度检查记录单。抽查内容包括：文档是否符合规范、是否符合项目管理规范、代码开发情况（是否按计划代码完成）、代码运行情况（是否能达到预期运行结果）、Java文件样式是否符合规范（文件头是否有版权信息、class类是否有注释、package的命名、class的命名、Static Final 变量的命名、参数的命名、数组的命名等）、代码编写格式（代码样式、文档化、缩进、页宽、｝对等）、对程序的异常是否能截获并生成错误日志等。软件质量保证小组可通过项目进度周报和抽查结果发现相关软件质量问题。

文档管理：如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这是一个应用服务提供商比较难解决的问题。我公司认为解决此问题，其核心仍然是个”度”的问题。在项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下”填空”的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。

软件验收：在验收的时候应按照合同及其附件所约定的内容进行交付，所交付的内容应当是电子版式和打印稿各一份。每项内容的交付都需双方签字确认。在项目验收的终验阶段用户方应及时按合同对该软件进行系统验收。

项目维护：维护小组的任务是保证对项目客户的跟踪服务，项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。

应用系统质量保障计划

在项目过程中，通常硬件都是成熟产品，质量相对有所保证。而应用软件部分是定制开发，前期不可见，开发团队的素质直接关系到产品质量，所以软件质量保证是整个系统质量保障的关键。

应用开发项目问题分析

随着各行业信息化建设的发展越来越快，暴露出的问题也越来越多。

软件项目的规模越来越大，以前的项目完成后编写的源程序有1万行已被认为是十分庞大的项目，如今几十万、上百万行的比比皆是。

软件项目的开发变得越来越复杂，项目开发的复杂程度与项目的规模不无关系。项目规模小，参与开发的人员少，问题处理起来也简单很多；项目大了，参与的人员多了，需要解决的问题自然也就复杂起来。

产品质量问题更加突出，用户调查表明，对软件产品质量完全满意的只是少数；近年来，软件产品质量造成的系统事故已造成了业界巨大损失。

软件开发和维护的成本有增无减，许多软件项目在开发结束前支出已超出了预算。一些项目开发中的设计缺陷在产品确认阶段，甚至在投入运行以后才发现，再行消除的成本要比设计后及时消除高出1～2个数量级。

产品延期交付，项目制定的计划进度经常不能如期完成，必定会影响到用户的使用或是投放市场的时机。

针对本项目采取的质量保证措施

• 团队建设是质量保证最根本措施

我公司有一支具有丰富行业经验的项目建设团队，加上能深刻了解、理解采购人的业务人员加入项目组，从而在根本上给目标系统项目提供了质量保证。

拥有一个具有深刻行业背景的建设队伍，将使在业务提炼、业务需求理解、业务沟通上、保证了高效率，提高了软件开发业务符合度，从而保证了项目质量。

• 采用CMM 的标准改进软件开发过程

CMM标准的实施在制度上提供了过程质量保证，在我公司每一个项目开发中，都注重过程改进。

通过公司CMM专家组和持续的软件过程改进，使社保团队拥有了持续地、可控制地、稳定提升的实施能力，降低大规模、长时间项目实施的风险，也有效地保证了项目质量。

针对本项目，我公司采用CMM过程管理规范来实施项目管理，确保项目的成功。

对于配置管理：项目组实施配置管理；配置管理内容为版本管理、变更控制、基线审计；制定配置管理制度；开展配置管理培训；指定专人负责配置管理；制定配置管理计划；要求开发人员必须进行check out/check in；保证文档按期check in；定期审查文档提交情况；版本发布/上线前组织评审；生成配置管理报告；使用专业工具进行版本管理；

对于需求过程：确立正式的需求小组，小组成员包括项目经理、业务专家、技术负责人、开发及测试人员；需求内容包括功能要求、性能及接口要求；需求调研采取业务人员访谈、调查表、原型等方式；需求分析采用ROSE工具；需求分析采用UML及文字描述等方法；需求必须经过评审；评审采用会议及文档方式；评审人员有项目经理、需求组、设计人员；对评审问题进行记录并修正需求文档；需求确认后纳入基线管理；

对于设计过程：制定设计规范；过程分为总体设计、概要设计、详细设计、数据库设计；采用基于复用的、面向对象交易的设计方法；采用rose、powerdesigner工具；采用会议及文档审查的审查方法；参加评审的人员有项目经理、技术负责人、需求组、开发人员；对评审问题进行记录并修正；确认后纳入基线管理；

对于开发过程：制定编码规范；约定开发方法；依据需求及设计文档开发；制定开发计划；每周制定详细计划、每月制定概要计划、每季度、每年制定总体；对业务实现采用基于交易的结构化编程方法，对底层架构采用面向对象编程方法；代码使用工具集中版本管理；开发环境有专人负责维护；使用软件工具及代码走查方式检查代码质量；使用软件工具进行缺陷管理。

对于测试过程：制定单元、集成、系统测试计划；编写测试案例；采用流方式进行测试；使用工具进行性能测试；一般模拟用户数为50-200；使用工具进行缺陷记录及跟踪。

• 制定应用开发规范并监督执行

我公司经过多个项目实践，积累、改进、完善了一系列应用开发规范，如需求类规范、设计类规范、开发类规范、测试类规范、上线类规范、交付类规范、维护测规范和管理类规范等。并通过组织、检查、会议等一系列手段监督执行，我公司准备把这些规范应用到本项目上。

• 工作质量的定期检查与抽查

采用人工与工具相结合的手段进行检查。

项目组定期召开不同规模的质量管理会议，对代码质量进行抽查，集体评审，讨论，共同提高。

在多个项目实践中，我公司也开发了众多的质量管理工具。例如：检查JAVA代码中数据库对象是否关闭的程序可以有效杜绝代码中的数据库致命错误；知识管理配置工具可以有效检查交易配置文件的逻辑错误。

• 制定项目成员工作质量考核方案

如项目内部定期进行检查、统计用户的反馈与投诉数量，进行评比，根据评比结果进行奖惩。

利用缺陷管理工具TestDirector，对工作质量进行跟踪、考核，可以有效督促开发人员提高代码质量。

• 制定项目验收标准

项目验收标准的制定以项目的建设目标为依据，制定出各开发阶段的成果验收标准，保证了项目质量。严格的验收标准将会贯穿在项目实施的整个过程，从需求到设计，再到开发实现，以及上线维护，项目组都会对照验收标准保证软件的质量。

• 阶段性同行评审

在CMM标准中，每一阶段性成果，都要进行评审，评审的意见会体现到现阶段产品的改进工作中，评审通过方纳入基线管理，有效地保证软件质量。

• 开发阶段的代码审查及测试

我公司在软件开发阶段有着严格的代码审查制度，开发人员必须经过单元测试，填写单元测试报告单，提交开发小组，开发小组审查后，组织交叉测试，小组长填写报告，提交开发经理，组织集成测试，开发经理填写测试报告，提交技术经理，进行压力测试，技术经理填写压力测试报告，提交项目经理，项目经理审查后，负责提交用户测试。项目组得到用户测试报告，进行缺陷修改，最后进行发布测试，提请用户进行软件发布。代码审查制度也从制度上有效地保证了代码质量。

在日常过程中，项目小组、开发经理、技术经理定期组织规模不一会议进行代码评审走查，统一代码规范理解，协调开发风格，保证系统未来的可读性、可维护性，有效地保证软件质量。

采有CMM过程改进后的效果

通过专家计算，有过以下结论：

• 在产品交付后修改软件缺陷的成本是交付前的10倍；
• 在编码后修改软件缺陷的成本是编码前的10倍；

只有在项目开发过程中注重质量，才能保证整个软件系统质量，只有规范化的过程才能培育出高质量产品。

经过CMM过程改进的项目，将具备成熟的过程，我们可以参看成熟过程与不成熟过程的对比，过程对比表如下：

对比方面	不成熟过程	成熟过程
角色与职责	没有明确规定角色和职责。每个人在做他认为要做的事。常会发生重叠和不清楚的所属关系和责任。	角色与职责已有明确规定。相互关系无重叠。有明确的目标和测量方法。能够体现持续改进过程的机制。
处理变更的方式	每个人都按自己的想法做事。	人员遵循一个规划好的文件化过程。可分享取得的经验。
对发生问题的反应	无秩序的混乱现象随处可见。“救火”方式解决问题的情况经常发生。每个人都想当英雄。	根据已有的知识和专业规则对发生的问题进行分析和处理。
可靠性	有时延迟交付产品和（或）超出预算。如有估算也不可靠。	估算准确。项目得到有效地控制和管理目标一般能够达到。
对工作人员的奖励	奖励的对象是“救火队员”；“如果你第一次就把事情做好了，那是你的本分，没有人理睬，但你若先把事情搞乱，然后再去解决，你就成了英雄”。	奖励那些生产高质量产品的团队，他们的产品既能满足需求又没有或少有失败。奖励那些防火者而不是救火者。
预见性	质量不可把握，它依赖于个人。进度和预算不能根据以往的经验确定。	项目的进度和产品的质量均可预见。进度和预算可根据以往项目的经验确定，并且是符合实际的。

经过过程改进的项目文化具备以下特征：

• 可见性：对每个人来说，过程定义和过程职责都是清楚的。
• 规范性：遵循过程是常规的要求，过程之外的行为是个别的例外。
• 制度化：遵循过程已列入组织方针和规程，并得到管理者的支持。
• 管理者承诺：过程得到最高管理者以及其他管理者和员工的支持。
• 推行：过程的推行是坚定的，也是有成效的。
• 所有者：过程为组织基础设施（如SEPG）所拥有，并得到维护、持续改进和支持。
• 反馈：组织中每个人都可对过程的有效性提出反馈意见，并且已经建立了适当的反馈机制。
• 绩效评估：对员工和团队工作的评价与过程效果密切联系，即要看过程目标达到的情况。
• 培训：对全体员工的过程培训是强制性的，对新员工的过程入门培训也是强制性的。
• 改进：全体相关人员要自始至终参与过程改进的策划和实施。

源代码管理

项目版本控制

对软件进行版本控制，衡量其效果的标准，归根结底有两点：效率和质量。如果版本控制最终使软件开发效率得到提高、使软件质量得到提升，那就是成功的，反之则是失败的。效率的提高比较容易理解，质量的提升则体现在：软件的一致性、冗余程度等。需要指出的是，单就版本控制工具本身并不能保证这两点。对工具不熟悉或错误地使用，以及开发人员的不良习惯等都将导致失败。有时可能反而降低效率。针对最为普通的一个软件开发环境和组织结构，运用管理软件是进行版本控制管理的非常有效而且代价较小的解决方案。

在项目开发过程中采用成熟的版本管理软件进行项目管理，如：VSS、CVS等。

版本控制流程目标

保证各个环境（开发、测试、主干）的独立，避免相互影响；

减少最终发布时合并主干出现冲突的概率；

降低冲突处理的难度。

原则

多个版本（开发版本、测试版本、发布版本）；多次合并。

流程

项目开发编码前从当前主干建立一条开发分支，供项目开发人员使用；

• 开发结束，提交测试的时候，从当前主干建立一条分支，将开发分支合并到测试分支上，供测试人员进行测试。这样开发人员对开发分支的修改不会影响测试环境。
• BUG FIX的时候我们定时将开发分支的修改合并到测试环境中。
• 回归测试的时候，从当前主干建立一条发布分支，将测试分支合并到发布分支上，在发布分支上进行回归测试。
• 发布前，将发布分支合并到当前主干。

优点

多个版本相互独立，互不影响；

通过多次与主干的合并，这样发布时候和主干做最后一次合并的冲突会大大减少，并且在与主干多次合并过程中的冲突解决都在测试阶段中得到了测试。

BUG管理规范化

对于BUG的管理，公司采用BUG管理软件进行管理。BUG管理工具能让所有研发人员方便地看到每个BUG的处理过程、能与代码管理结合起来使用和能追踪BUG的处理过程的优点。

软件测试的主要目的在于发现软件存在的错误（Bug），对于如何处理测试中发现的错误， 将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证 要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确 认、修复、验证等的管理过程，这是软件测试的重要环节。

BUG管理的一般流程

• 测试人员提交新的Bug入库，错误状态为New；
• 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
• 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复 并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
• 对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
• 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

项目交付物管理

我公司将根据项目进展和合同要求，按时提供相关文档及技术成果。文档满足国家标准、行业标准、建设方的各项要求。

交付产物内容包括：

项目管理类

• 项目计划文档
• 软件配置管理计划
• 软件安装部署方案
• 文档编制规范
• 软件质量保证计划
• 项目变更控制文档
• 项目验收计划
• 项目总结报告

软件开发类文档

• 总体方案规划报告
• 需求调研计划
• 需求调研问卷
• 需求规格说明书
• 概要设计说明书
• 详细设计说明书
• 数据库设计说明书
• 采购软件及设备报告
• 项目测试方案
• 项目测试报告
• 系统部署报告

系统维护文档

• 设备和系统安装配置手册
• 系统管理员手册
• 用户操作手册
• 用户培训手册

保密措施

项目划定研究开发区域、商业秘密保护区域，未经许可，非科研人员和因工作需要必须接触到相应资料、物品的人员，不得擅自进入划定的与本职工作无关的场所，不得带领无关人员进入该场所或为无关人员进入该涉密场所提供便利；

在劳动合同中，加入保密条款和禁止条款，任何人不得利用职务、工作之便或采用其他不正当手段，将单位的知识产权擅自发表、泄漏、使用、许可或转让；也不得利用在本单位工作所掌握的信息资料为同行业的其他竞争者服务或提供便利； 

项目人员须增强保密意识，不该问的不问，不该说得不说，不该看得不看。 

项目经理是保密工作的第一责任人，各小组负责人为本小组的保密工作负责人。 

严禁私自携带外来人员随便出入项目建设区域。 

秘密文件、资料和其他物品的制作、收发、传递、使用、复制、摘抄保存和销毁，由项目经理委托专人执行；采用电脑技术储存、处理、传递的公司秘密由有关操作人员进行保密处理。 

对于密级的文件、资料或其他物品，必须采取以下保密措施： 

（1）非经项目经理的签批，不得复制和摘抄。 

（2）收发、传递和外出携带，由指定人员担任，并采取必要的安全措施。 

（3）在设备完善的保险装置中保存。

属于密级的设备或者重要的商业信息，由项目管理组指定的专门小组或专人负责，并采取相应的保密措施。 

在对外交往合作中，需要提供保密事项的应当事先报请项目经理签批。 

项目部具有属于保密内容的会议和其他活动，应采取以下保密措施。 

（1）选择具备保密措施的场所。 

（2）根据工作需要，限定参加会议的人员范围，对参加涉及秘密事项会议的人员予以指定。 

（3）依照保密规定使用会议设备和管理会议文件。 

（4）确定会议内容是否传达及传达范围。 

不准在私人交往和通讯中、不准在公共场所谈论、不准通过其他方式传递项目中的秘密。 

项目工作人员发现招标人或公司秘密已经泄露或者可能泄露时，应立即采取补救措施并及时报项目管理，项目部办公室接到报告，应立即作出处理。

项目验收方案

夏坝智慧农业项目验收方式为项目建设验收。项目建设验收分为项目建设初步验收和项目建设整体验收。

项目建设验收

项目建设验收要求

项目建设验收遵循以下验收要求：

• 本项目应以通过验收评估并获得招标人对项目整体建设与使用效果的认可为项目验收基础条件。
• 本项目应按照项目施工建设、软件定制开发及产品采购分别验收。
• 本项目内相关软件按照招标文件要求达到提供服务的能力。
• 在项目验收前，投标人应提交本项目的所有成果，以及项目产品有关的全部资料，包括全部有关技术文件、资料、安装调试、操作和维护技术手册、验收报告等文档，汇集成册交付给招标人，应以存储介质提交项目全套软件产品以及配套的文档，提交应属于招标人知识产权的所有系统源代码。
• 项目验收中，国家有强制性规定的，按国家规定执行，验收费用由投标人承担，验收报告作为申请付款的凭证之一。验收过程中产生纠纷或存在异议的，由质量技术监督部门认定的检测机构检测，出具检测报告，检测费用由投标人承担。
• 项目验收不合格，由投标人返工直至合格，有关返工、再行验收，以及给招标人造成的损失等费用由投标人承担。验收不合格的，双方协商延长验收期限，在此期间投标人自行承担相关费用进行修改或调整，并重新提交验收。

项目建设初步验收

在完成建设实施的全部内容后，由项目建设单位提交验收申请报告、验收方案，完成项目初步验收所需的技术、财务和档案材料，经招标人、项目监理单位审批通过后开展项目初步验收。

初步验收前提条件

项目建设单位提请初步验收应具备以下前提条件：

• 完成系统建设内容，达到项目招投标文件、项目合同及需求等相关文档的技术要求。
• 各种技术文档和验收资料完备，符合合同的内容。

在达到以上前提条件的情况下，项目建设单位向监理方提交《初步验收申请》，经监理方和甲方同意后，启动项目初步验收流程。

初步验收依据

初步验收依据包括：

• 项目招投标文件、合同及相关附件
• 《业务需求说明书》、《需求规格说明书》、《概要设计说明书》等软件技术说明书。

初步验收内容及标准

初步验收内容包括：系统方面和文档方面。

系统方面要求覆盖《业务需求说明书》、《需求规格说明书》等说明书中要求的功能和非功能性需求。

文档方面要求提供招标文件要求的所有文档交付物。

初步验收形式

初步验收采取专家组会议形式。

项目建设整体验收方案

夏坝智慧农业项目的建设实施整体验收由招标人组织投标人、监理单位、专家团队及相关部门共同进行。项目通过建设实施阶段的初步验收，并通过试运行后，投标人提交项目验收申请和项目建设实施整体验收方案，经招标人及监理单位审批通过后开展项目验收工作。

项目通过建设实施整体验收后，投标人向招标人移交全部项目竣工文档、交付物，并启动运行维护工作提供技术支持。

整体验收前提条件

项目建设单位提请总体验收应具备两个前提条件：

• 完成本项目初步验收后，完成试运行，系统运行稳定。
• 系统应用达到项目可研报告、初步设计、《需求说明书》所要求的应用效果。

在达到以上两个前提条件的情况下，项目建设单位向监理方提交《整体验收申请》和《试运行总结报告》，经监理方和甲方同意后，启动总体验收流程。

整体验收依据

整体验收依据包括：

• 项目招投标文件、合同及相关附件
• 《需求规格说明书》、《概要设计说明书》等软件技术说明书。
• 《初步验收报告》
• 第三方《测试报告》
• 《缺陷修正记录》或《项目备忘录》
• 《试运行总结报告》
• 监理方《项目评估报告》

整体验收内容及标准

整体验收内容包括系统部分和文档部分。系统方面要求覆盖《需求规格说明书》说明书中要求的功能和非功能性需求，系统无遗留问题或经甲乙双方及监理方协商达成一致备忘。文档方面要求提供招标文件要求的所有项目交付物。

整体验收的标准是文档完备，系统运行稳定，系统应用达到项目可研报告、初步设计所要求的应用场景的效果。

整体验收形式

整体验收采取验收专家组评审方式，评审形式一般采取评审会议结合现场检查方式进行。

售后服务方案

概述

XXXX大坪村智慧农业项目运维服务涉及到包括物联网硬件设备、网关协议汇聚平台、物联云平台、智慧农业大数据驾驶舱等。针对此次系统运维服务项目，我们在运维管理过程中，从日常运维，到服务响应、故障的处理，最后到服务管理制度建设、服务文档提交、优化建议的提出和落地实施，我们将秉承“以客户为中心、以流程为主线”的IT服务管理思想，建立相应以专业驻场工程师为基础的服务体系。从而保证XXXX大坪村智慧农业系统的可靠、高效、持续、安全运行。

本项目作为我公司五星级项目，我公司将在售后服务期内提供全程现场贴身服务，为用户配备专门的服务组织和高级技术人员，在技术力量、资金、服务和其他资源配置方面给予特别关注与考虑。建立与用户的较高层面的热线管道，及时有效的沟通。确保系统稳定，可靠，长期运行，伴随用户共同成长。

整体研究方法

对于XXXX大坪村智慧农业系统运维服务项目，我方基于ITIL方法进行研究。

众所周知，ITIL是最佳实践的产物，ITIL是一个依据IT运营发展不断变化、反复调整的理论体系，ITIL是需要结合客户实际运营环境，并进行反复验证的。因此脱离实践的ITIL空想，往往很难在现实客户中获得成功。ITIL理论引导和咨询规划帮助客户进行宏观层面的规划和指引，但是终究需要依赖“人”去理解和贯彻执行，并经过反复验证，方能在此过程中总结“何为企业IT运营的最佳实践”。我方洞察客户在实施ITIL遇到的风险和困难，通过整合长期积累的行业客户实践ITIL的经验，总结出了我方的实施方法。

建议客户的运维服务管理实施以“PDCA”为指导思想，建立运维服务管理体系的持续改进方法论和可执行方法。

P：服务管理的策划，目的：策划服务管理的实施与交付。

D：服务管理的实施，目的：实施服务管理目标和计划。

C：服务管理的检查，目的：监视、测量并评审服务管理目标和计划完成情况。

A：服务管理的持续改进，目的：改进服务交付和管理的效率和有效性。

根据PDCA指导思想结合客户现状，我方将运维服务体系建设及服务实施划分为五个阶段：IT战略阶段、管理体系设计、整理数据模型、服务实施、运行与改进阶段。

第一步是IT战略阶段

IT战略阶段的任务是帮助管理层设定实施ITIL的整体战略，明确管理层对于运维服务管理的承诺。在IT战略阶段，通过现状评估、差距分析、目标确立等活动，明确管理目标建设的优先等级。

IT战略阶段的目标：

通过现状评估全面了解IT运维服务管理流程和活动的成熟度，并以ITIL作为近期服务改进的目标，分析、评估运维服务管理现状以及与最佳实践的差距，同时提出改进建议。

帮助XXXX大坪村运维部门全面认识现有运维服务管理水平，并作为项目下阶段规划与设计双方交流的基础。

第二步管理体系设计：

明确IT战略之后，需要对组织的管理体系进行梳理和改进。管理体系阶段主要包括以下内容：

• 组织架构分析
• 明确岗位职责
• 规范管理制度
• 运维流程设计
• 考核体系

第三步整理数据模型：

数据模型阶段分为以下三个步骤：

（1）模型建立

我方为XXXX大坪村提供基于长期实践经验得出的数据模型工具帮助XXXX大坪村梳理流程及数据，并将流程及数据固化到系统中。

（2）数据采集

基于前期阶段设计的成果，按照数据模型的标准格式，转换成可被统计、量化并被系统识别的数据。

（3）数据整理

整理优化数据，通过手工或自动流程检验数据的合理性和可操作性。

第四步服务实施：

服务实施阶段分为以下五个步骤：

（1）系统配置及部署

完成运维管理工具的部署，管理资源、组织、人员、权限录入，监控告警策略设置，接口集成等。

（2）流程导入

将已构建的运维管理流程导入到运维管理系统中，实现各个流程在系统平台中的落地。

（3）系统测试和团队磨合

在测试环境中检验系统及数据的可操作性，并进行适当的调整，整体运维团队磨合。

（4）服务培训

运维服务培训，确保使用人员熟练掌握运维技术和运维流程，并实现团队自我学习和自我提升，不断升级运维能力。

（5）运维稳定持续交付

运维团队和运维相关团队进行有效的工作输出，支持业务运行。

第五步运行与改进：

服务运营阶段将全新的运维管理解决方案集成到智慧农业系统中，并提供日常的运行、监视、维护和管理服务。该阶段包括以下内容：

评估与改进：监视、评估我方运维服务管理的运行情况。将信息反馈回评估小组，以进行持续改进。它包括：

• 评估已交付的服务是否实现了预期价值；
• 识别哪方面的要求发生了变化。

运维服务管理体系的建立并不能只实施一次就实现所有运维服务管理建设的目标，它只是XXXX大坪村智慧农业在建设符合ITIL规范的IT服务管理系统的诸多循环中的一次过程。配合以不断的项目回顾和持续改进，才能使得江津智慧农业系统管理不断地向设定的目标愿景靠近。

运维服务范围

XXXX大坪村智慧农业系统使用的物联云平台、应用系统等技术产品，重要程度和类型的不同，具体运维流程有不同的运维关注点，我方基于日常运维、升级、优化进行分阶段管理。

质保期内出现任何质量问题（不可抗力除外），我公司及时提供免费的维修、更换或升级等服务。当出现重要或紧急情形时，按招标人的要求提供现场支援和备品备件服务。其中，免费是指免全部工时费、材料费、管理费、财务费等费用。

现场运维技术支持

驻场服务

我公司根据项目实际需要可提供售后维护团队的现场驻地化服务，解决用户系统使用疑问、故障反馈等。具体内容如下：

我公司本项目的服务人员能够做到实时响应用户的请求，及时进行问题的解决，保证目标系统的持续、稳定及高效的运行，且做到0.5小时内响应并解决基本故障的维护服务。

对于重大的技术问题，我公司会在1小时内作出响应。

对于工程师无法解决的问题，工程师会把问题及时告知服务专员并请示相关领导，我公司会派公司的高级工程师4小时内进行解决。

问题解决后，我公司的工程师会对问题的情况及处理时间、处理过程进行记录，并反馈给用户。

对服务质量管理方面，我公司已制定出相应的考核政策，对于服务不到位的人员进行惩罚，对于用户满意的服务人员进行奖励。

执行运行操作活动

负责相关用户的技术咨询及技术支持服务，对应机房、IaaS资源池、网络、安全、应用系统的每个运维同事各司其职；

负责系统运行状况监控，响应处理各类运行事件，管理并跟踪系统运行事件的处理情况；

负责轮守值班，服务告警及用户故障响应处理，保障系统稳定及用户问题的及时响应处理；

负责执行客户制定的工作计划和操作规范；

负责在节假日按照客户要求进行值班值守。

定制软件维护

定期巡检

质量保证期内，我公司定期对系统进行例行巡检，对用户的系统运行情况进行检查、优化，通过采取预防措施，对潜在的故障点进行分析诊断，达到预防目的。

系统调优

根据需要对系统的稳定性等进行性能调优和系统调优工作。

故障响应服务

我公司向招标人提供7*24小时的电话服务及远程服务来实现基本故障维护服务，响应并解决时间不超过0.5小时。当电话和远程服务不能排除系统故障时，我公司将新派专业技术人员奔赴现场提供技术支持服务，响应并解决时间不超过4个小时；如果发生特别严重故障，我公司提供备件直到问题解决，一般不超过24小时。

电话支持

我公司将针对本项目提供两方面的电话支持服务，我公司提供专门的服务热线手机，以保证不漏接客户电话。收到保障电话后，客户服务专员将根据故障等级通知相关工程师响应客户。

故障登记表如下：

受理人员		受理时间
报人姓名		保障人联系方式
保障人所属机构
保障内容
备注信息

培训服务

为使业务操作人员全面掌握业务操作流程，熟练灵活地使用统一软件完成业务操作，使系统管理人员达到能够独立进行日常管理、程序部署和更新、常规故障的处理、日常维护等工作目的，我们将协助采购人为相关管理人员和技术人员提供系统的使用、操作和管理等要求的技术培训服务。具体培训的实施方案参见培训方案章节。

文档维护服务管理

本项目运行维护过程中，我公司将严格按照CMMI3要求，建立配置管理环境，及时维护全过程的文档，并按照采购人要求定期或在重大功能变更后更新相关文档。服务期结束时将项目的全部有关技术文件、资料及软件维护、修改记录、程序发布记录和验收报告等文档汇集成册交付采购人。

告警配置与处理服务

根据系统架构与业务逻辑，设计配置合理告警方案；

跟踪处理告警，分析告警产生原因及解决方案，并跟踪解决方案有效性。

设计合理告警方案

优化告警规则，提高告警解决效率，便于运维人员跟踪，提高运维管理效率。针对不同业务、不同服务等级制定不同告警方案。

针对不同业务特性，设置合理告警点，关键业务不同处理节点均需设置告警点，以便问题及时响应；针对非关键业务，在关键节点设置告警点；

统计系统资源运行指标的高峰值，设置合理的告警阈值和运行基线，根据问题一般、严重、紧急程度，设置合理阈值。

告警处理

运维支撑人员收到告警信息后分析告警原因并第一时间通知项目经理，根据告警分析情况确认解决方案：

硬件问题，输出评估硬件替换解决方案及设备未到位前的临时解决方案。

应用系统问题，提交问题解决跟踪工单，要求开放厂商在指定时间内解决。

应用系统部署协助服务

业务系统的扩容和上线都是对现有运维工作的挑战，会引起一系列的变更，涉及面特别广，因此需要专门分析和处理，具体应对措施包括：

• 业务系统的扩容和上线对现有运维工作的影响分析；
• 运维团队人员和工作内容的调整应对；
• 相关运维文档的更新；
• 扩容和上线的具体操作支持；
• 新增业务系统的测试和验证；
• 日常保障和故障处理的更新；
• 系统巡检和报告的更新。

为了确保新增业务系统与现有运维工作的稳定整合，我方将协助客户做好应用系统扩容工程实施的相关工作并制定业务运维规范，确保新增业务系统能够快速稳定的交接给运维部门，规避交接维的风险。交接维管理具体内容见下图所示：

说明：具体流程和操作规范将在项目启动后由我方项目经理与客户相关人员共同讨论制定。

快速响应

服务特点

• 先进的服务理念：技术支持、人员流程、服务伙伴；
• 24*7*365的支持响应中心；
• 严格的人员培训认证；
• 严密的服务支持流程；
• 完善、高效的疑难问题升级流程与管理；
• 高效的备件管理系统；
• 完善的技术支持库；
• 丰富的技术工具；
• 专业服务专家。

服务方式

我方对您的支持服务基本上可以分成两类：响应式服务和主动式服务。

响应式服务：远程支持和现场服务。远程支持是指在系统出现问题时，XXXX智慧农业项目的技术人员通过我方提供的值班电话、手机、呼机等技术手段寻求技术支持。响应中心的工程师会通过诊断调制解调器远程初步诊断故障，当判断系统有硬件故障时，会立即通知本地的工程师到现场做硬件维修。当系统出现疑难问题不能立即解决时，响应中心的工程师会将问题升级到总部；

主动式服务：是通过主动式服务尽可能地预防和避免问题的发生，将问题消灭在萌芽状态。通过指定专门的客户服务代表，来保证我方服务的质量，协调解决XXXX智慧农业项目遇到的紧急问题，定期回顾和总结我方服务支持工作的情况，灵活处理智慧农业的一些特殊服务支持。

人员及其职责

角色	职责
客户经理	介绍我方相应产品满足客户需求安排我方订购产品和到货运输等
服务区域经理	领导客户支持服务队伍制定客户支持服务策略与客户管理层沟通
客户服务代表	实施客户支持计划紧急情况快速响应协调我方内部资源为客户提供问题解决方案满足客户需求
大客户管理经理	负责管理重要客户各项工作
服务合同经理	负责服务合同管理及相关事宜
备件管理经理	负责全国支持服务备件管理

快速响应流程

故障升级标准

故障是否应该升级处理的标准为：

在业务繁忙时发生故障并严重影响业务，无法及时找到解决方案；

重要问题在4小时内仍不能解决；

需要更多资源解决此类复杂问题。

故障升级前，客户服务代表会将整个问题情况汇报给部门经理，共同讨论如何及时充分调动我方的资源为客户服务，或是否需要其他途径将问题升级处理，客户服务代表或我方地区经理可以成为故障升级的客户满意度经理。

角色	职责
客户满意度经理（CSM）	代表我方管理层与客户管理层保持联系，通报进展，协商行动方案负责故障升级的项目管理协调资源，保证升级小组了解客户现场最新情况
故障升级工程师	负责故障升级的资深技术工程师组织协调技术行动制定、实施故障解决方案
故障升级经理	负责故障升级流程保障升级流程按程序进行配合客户满意度经理管理故障升级
技术升级专家	负责此次升级的相关领域全球技术专家提供技术解决方案及应急方案与我方实验室配合提供解决方案
技术升级专家经理	指派、管理相应的全球技术专家协调技术专家及实验室相应资源

客户满意度经理（CSM）是面向客户的故障升级负责人，出现故障升级时，其主要工作内容为：

确认客户已经知道问题已经升级处理；

确保问题被妥善解决，同时要让甲方满意；

保证客户和我方的管理层都明确了解升级处理的每一状态。

服务记录和报告

工程师或客户服务代表做完现场维修后，将被要求在一份“现场服务记录”上签字，这是甲方对现场服务的确认，此文件将被保存作参考用。同样，响应中心工程师在做完远程支持后，也会将服务记录下来，这样，所有智慧农业系统中出现的问题都可查询、分类，同时可帮助我方的工程师发现潜在问题。客户服务代表在系统运行情况定期回顾时将总结这些服务记录，以便确定今后要采取的一些措施。

支持服务回顾

系统运行和服务情况定期总结回顾活动是一次非常好的客户和我方交流的机会，客户服务代表从中可得知系统环境和业务需求的最新消息，阐明一些特殊问题，并同客户定制、修改年度维护计划。着重在于提供系统管理和技术指导以帮助智慧农业系统提高整体计算机环境的运作效率。

支持服务回顾的益处包括：

增加系统稳定运行性能和时间；

提高智慧农业系统的生产效率；

主题由双方协商确定的；

总结过去的服务记录；

提供技术指导；

分析操作流程：包括系统控制、备份策略、文件系统管理、工作计划和讨论年度维护计划等。

节假日期间，如遇到异常事件，我方现场维护人员具有足够的技术能力，在约定的时间范围内，可以及时达到客户现场，快速解决异常和处理故障，并将处理结果汇报给客户。确保智慧农业系统在节假日期间稳定运行。

同时，我方现场维护人员要协助客户制定完善的容灾恢复相应机制。在紧急响应情况发生时，能够及时协助客户进行业务恢复，我方现场维护人员需定期进行容灾恢复测试演练，通过日常磨合润滑，实现在应急情况下，多厂商之间达到默契配合，实现高效的工作效率。

技术支持信息共享服务

服务定义

为客户提供服务、技术及开发文档。每半年至少进行一次服务总结汇报。

服务方案

在系统上线的同时向客户提供服务、设计方案、实施方案、运维文档、产品手册、开发文档等技术支持信息文档。并且每半年至少进行一次服务总结汇报。

文档主要包括：

《夏坝智慧农业系统设计方案》

《夏坝智慧农业系统实施方案》

《夏坝智慧农业系统运维文档》

《夏坝智慧农业系统产品手册》

《夏坝智慧农业系统开发文档》

其他服务内容

我方将为客户设立所购买技术服务的专职服务经理，负责建立维护智慧农业系统档案、了解客户需求、制定服务计划、监督服务执行、跟踪并改进服务质量、提交各类服务报告、处理投诉等。

系统档案管理

我方客户服务经理将建立智慧农业系统档案，包括但不限于以下内容：

• 系统机房地址
• 客户联系人姓名、电话
• 系统设备应用情况
• 系统软件版本号
• 硬件配置
• 操作系统环境

定期回顾

我方将至少每季度进行该阶段技术服务情况回顾，并将回顾报告提交给客户。我方与客户将至少半年召开一次服务例会，在客户的要求下，我方有义务配合召开其他时间的例会。例会结束之后应由我方客户服务经理提供会议纪要交客户确认，并于7个工作日内反馈并跟踪落实会议纪要中的客户意见与建议。

例会内容将涉及以下事项：

（1）我方客户服务经理对该阶段所执行服务进行介绍，提交阶段性服务情况汇总报告。报告内容应包括该阶段所发生全部服务内容的执行及客户满意度情况。

（2）客户对我方客户服务经理所提供阶段性服务情况汇总报告进行确认。确认完成后由客户对该阶段服务执行情况及服务质量进行考核，并依据考核标准评测打分。

（3）我方客户服务经理听取并记录客户针对该阶段服务执行情况及服务质量的意见及建议，全部内容应通过会议纪要形式确认。

（4）我方客户服务经理应根据客户需求制定下一阶段的客户服务计划。

（5）讨论本阶段服务过程中的重大事件对就智慧农业系统运行的影响及应对措施，如系统升级、运维、系统管理人员变动、管理流程及制度变更等。

（6）针对本阶段服务过程中的重大技术问题，探讨预防措施及系统优化措施，寻求问题解决更为合理、有效的途径，改进针对此类问题的服务流程。

售后服务流程

运维服务流程是指为达到既定的IT运维管理目的而组织起来的逻辑上相关的有规律性并可重复的活动。按照IS09001规范和国际最佳实践ITIL框架，结合项目采购单位IT建设具体情况，设计了如下总体服务流程：

主要包括：

1) 服务台

2) 系统监控

3) 事故管理

4) 问题管理

5) 变更管理

6) 系统优化

7) 配置管理

8) 发布管理

9) 以及对运维工作的服务监督和考核等九个流程。

服务台

用户服务流程是通过“服务台”来统一处理的，其目的是为用户提供统一一致的服务渠道，规范用户服务活动。服务台可以集中处理来自客户的询问和请求，节约资源，还可以及时向客户和用户传递有关服务的各种情况。

对用户而言，服务台是“问题汇集中心”和“技术咨询中心”，是一个统一的问题收集接口和咨询服务接口。

事故管理流程

故障处理流程是针对信息系统出现故障时提供的处理流程。尽管现在的信息系统的使用者界面越来越友好，但对于非IT专业的一般用户而言，依然需要明确定义一种可操作性强的方式对发生的故障进行管理。

故障管理最主要关注的是按预设的服务级别快速稳定地恢复。按照国际标准化组织ITIL的定义，“故障”是指任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件。

建立故障管理流程的目标是期望在尽可能小地影响组织及用户业务的情况下使信息系统尽快恢复到服务级别协议所定义的服务级别，以确保最好的服务质量和可用性级别。

故障管理的主要包括：及时识别并跟踪发生的故障；对故障进行分类并提供初步支持；对故障进行调查与分析识别引发故障的潜在原因；解决故障并恢复服务；跟踪和监督所有事故的解决过程，并随时进行沟通。

问题处理流程

问题管理流程是指用于解决信息系统服务运营过程中遇到的所有问题的流程。结构化、系统化的问题管理方法能够迅速查明事故发生的潜在原因并找到解决此事故的方法或防止其再次发生的措施。因此，健全的问题管理关注预防性措施和引发事故的潜在因素的识别。本项目问题管理工具使用QC。

建立问题管理流程的目标是寻找发生问题的根本原因，根据优先级定义首先解决关键性问题，并防止与这些事故相关的事故再次发生，增加支持人员解决问题的能力。

问题管理的主要任务包括：识别和记录问题；对问题归类，主要关注影响业务的问题；调查问题的根本原因；解决问题；终止问题。

变更管理流程

变更管理的目标是确保在变更实施的过程中使用标准的方法和步骤，从而以最快的速度实施变更，将由变更所导致的业务中断的影响减少到最低。

变更管理主要任务包括：记录和筛选变更请求；对变更请求进行分类并划分优先级；评价变更请求对基础架构和其他服务的影响，及非信息技术流程与不实施变更请求的影响；实施变更请求所需要的资源；获得实施变更请求的正式批准；变更进度安排；实施变更请求；评审变更请求的实施。

发布管理流程

系统上线发布的软件（含补丁）需要经过发布请求、发布计划、发布实施、发布审验、发布关闭等几个阶段，软件的发布请求由业务主管部门发起，也可由信息化部门发起，但都必须经信息化相关职能部门统一发布。本项目发布管理使用开源Ant工具。发布管理是与变更管理、配置管理紧密结合的，当新发布引起IT基础架构的变化时，配置管理数据库也需要进行实时的更新，同时发布的内容：如最终软件版本，硬件规格说明、装配指南、升级安装手册和网络配置等都要关联到配置管理数据库中。发布流程如下图所示：

配置管理（CM）

配置管理指对生产环境中的软硬件资产、配置信息及各配置项的相互关系进行记录，形成集中的配置管理数据库（CMDB），并对生产环境中的配置信息进行定期审计，以保证配置管理系统中的数据与实际生产环境一致。因此，配置管理已不仅仅是一个或几个管理流程即可达到目的，它必须形成一套系统以支持其他管理流程及保障服务的需要。根据ITIL理论的解释，配置管理是其他服务支持流程的基础，配置管理涉及的活动有规划、识别、控制、状态管理、校验和审计等内容。

运行监控流程

最好的服务是在用户（使用系统的人员）未发现问题前通过内部流程先发现并解决问题，因此，这就需要一个内部的运行监控流程。项目运行监控是运维部门内部的一个流程，通过运行监控流程实现对系统全面的监控，包括数据中心机房、基础设施层、数据层、应用支撑层、应用层到展示层的全面监控，在性能模型和性能目标的基础上，通过监控、预警等机制，先于用户发现系统的性能问题和隐患，为提前（及时）处理系统问题提供支持。

运行监控内容

运行监控主要涉及到三方面的内容：

（1）日常监控

日常监控规定了相关人员凭借监控手段对系统进行监控，如运行高峰期的实时监控、定期的日志分析等；

（2）问题处理

问题处理规定了在监控出现异常现象，所执行的后续处理及服务流程。

（3）定期报告

运维人员需要对监控结果形成监控报告，提交给技术组分析。

运行监控技术机制

面向不同人员和角色的监控视图

一般来说，监控软件实现了对信息系统性能状态、事件等信息的采集和简单的显示功能，实际情况是，不同人员对监控信息的要求是不一样的，比如机房值班人员要求直观呈现系统是否正常，如果产生不正常，是哪个系统不正常，而技术人员则需要对系统运行指标信息的监控，如CPU、进程等信息。因此，作为一个通用的监控软件是不能做到这一点的，这通常是通过集成商的二次开发来完成的。

典型的监控视图包括：

面向管理人员：系统运行状态统计、系统整体运行实时状态结构图等；

面向值班人员：系统拓扑结构视图、业务系统（每个业务系统1套）逻辑结构视图、系统状态列表视图等；

面向技术人员：设备状态视图、系统性能分析视图等。

预警原则

1）完善网络与信息安全突发公共事件监测、预测和预警制度

加强对各类网络与信息安全突发事件和可能引起突发网络与信息安全突发公共事件的有关信息的收集、分析、判断和持续监测。当检查到有网络与信息安全突发事件发生或可能发生时，应及时对发生事件或可能发生事件进行调查核实、保存相关证据，并立即向应急领导小组报告。报告内容主要包括信息来源、影响范围、事件性质、事件发展趋势和采取的措施建议等。

若发现下列情况应及时向领导小组报告：

• 利用网络从事违法犯罪活动；网络或信息系统通信和资源使用异常；
• 网络或信息系统瘫痪，应用服务中断或数据篡改、丢失；
• 网络恐怖活动的嫌疑和预警信息；
• 其他影响网络与信息安全的信息。

2）设定信息安全等级保护，实行信息安全风险评估

通过相关设备实时监控网络工作与信息安全状况。各个基础信息网络和重要信息系统建设要充分考虑抗毁性和灾难恢复，制定并不断完善信息安全应急处理预案。针对信息网络的突发性、大规模安全事件，建立制度优化、程序化的处理流程。

3）做好服务器及数据中心的数据备份及登记工作

建立灾难性数据恢复机制一旦发生网络与信息安全事件，立即启动应急预案，采取应急处置措施，判定事件危害程度，并立即将情况向有关领导报告。在处置过程中，应及时报告处置工作进展情况，直至处置工作结束。

预警管理

监控系统可以设置一定的预警规则，当系统符合预警规则时，向外发出告警提示，以便运维人员对系统进行及时处理，避免故障的发生，如CPU>90%触发告警。

对于系统中持续出现以及超过规定处理时间仍未解决的告警，需要升级该告警的告警级别，以保证得到优先及时的处理。

告警管理功能能够与拓扑展现模块配合，当发生告警/告警清除时，自动更改拓扑中对应的对象状态。

监控系统能够提供多种告警通知方式，如声光电、短信、邮件等，同时提供灵活的告警通知规则定义功能，如按照告警源、所属应用系统、地理位置、告警级别、告警内容、告警类别、告警对象的关键级别等条件定义告警通知规则，即发生在某对象上的某类告警在何种条件下通过什么方式通知给何人。

系统优化流程

性能优化原则

由于信息系统优化的复杂性，因此信息系统的优化工作必须坚持以下原则：

1）可追溯性原则

系统优化涉及到对不同层次、不同位置众多软硬的配置和结构调整，因此系统必须确保追溯性原则。为了实现系统可追溯性，需要对系统配置和性能信息建立档案；

2）确定优化目标

优化目标是系统优化的指导和方针，它可以避免一些不必要的工作，比如，网络带宽是10M，你在该线路上的请求的速度和并发量。而不用不切实际情况优化工作；

3）制定优化计划

优化计划要体现问题优化的以下关键活动，搭建环境、跟踪模拟、优化验证；

4）可测量性原则

信息系统的优化的所有数据都是可测量的，而不是假想数据。

性能优化步骤

性能优化基本步骤：

1）建立应用系统性能模型

性能模型是用来分析和定位系统性能瓶颈的分析模型，需要考虑时间、资源和行为多个角度。

2）定位存在的瓶颈和隐患

系统的性能问题是一系列的瓶颈引起的，往往一个主要的瓶颈是引起性能的主要原因。并且，往往解决一个主要瓶颈后，其他次要的瓶颈逐步成为主要瓶颈，因此，优化不是一次完成的，需要经过长期监控优化。

3）提供升级改造优化建议

针对发现的系统瓶颈和隐患，提出系统优化的建议，如：系统扩容，SQL优化、增加缓存机制等。

4）量化现有应用性能需求

量化现有应用性能需求是把系统性能需要用数字形式来表述出来，从而提供科学的性能优化和系统趋势分析依据。量化内容包括：业务量与时间，系统资源与时间关系图等。

5）分析性能需求增长趋势

根据系统性能量化指标，结合实际的业务情况，分析系统增长趋势，如业务年增长率、资源需求增长曲线。

6）制定性能改善目标

系统优化目标是与业务要求相关的，同时也是影响优化的重要因素，性能目标是业务种类、业务量、响应时间的关系描述。建立合适的性能目标，可以避免一些不切必要优化工作。

7）优化方案性能指标要求

在制定的优化、升级方案基础上，采用数字化的形式，定义升级后的性能指标，以便升级后的评估，以及衡量升级是否达到目标。

8）检测改造方案实际负载

系统优化升级后，通过一定的监控机制，检测系统优化实际运行指标。

9）评估优化效果

根据升级方案的性能指标及检测的实际性能指标，评估系统优化的效果。

10）长期量化分析优化结果

因为系统性能问题往往是由一系列的性能瓶颈引起的，解决主要问题后，其他次要问题很可能成为新的主要问题。另外，系统性能与数据量及业务量是相关的，因此，需要建立长期量化分析和优化机制。

应用系统性能模型

系统性能问题是一个行为（用户操作或系统自动作业）、资源、以及时间的多维关系，资源不足会引起性能问题，相同的资源下，操作不合理也会引起性能问题。同时，行为与时间成一定的周期关系，如每天业务高峰。

系统优化的工具

压力模拟工具：压力模拟软件是诊断和定位问题的关键工具，成熟的压力测试工具如LoadRunner；

系统监控工具：系统监控工具是基于操作系统提供工具结合脚本编写的监控工具，用来观察系统、进程、线程的CPU、内存、IO以及其他资源的使用情况，常用的操作系统工具如sar、ps、vmstat、iostat、netstat等；

数据库监控工具：目前数据库软件都提供了内置的性能监控设施，它可以记录了数据库当前以及历史运行状态的信息。一般，数据库也提供了一些工具可以用来进行监控，但为了更准确的跟踪和定位问题，通过是通过自定义脚本来进行跟踪和监视的。

中间件监控工具：中间件主要提供了对事务和并发管理控制功能，因此，关于中间件监控关键是对事务、迸发管理控制以及数据库连接的监视，另外，对于J2EE，需要对进程内存使用以及JAVA 堆进行监控，这些都有一些专业的软件进行监控，如：jmeter、jtune、gcviewer等；

调试工具：为了更好的定位问题，可以通过对软件进行跟踪调试来更准确的定位问题，可以借助的调试工具如：wdb、adb、jdb等。

本项目性能优化建议

根据我们对项目整体情况的了解，建议：

定期使用LoadRunner，模拟复杂业务的处理，监控、分析这些业务的处理性能是否随业务量的增长而出现瓶颈。

数据整理定时化。通过Oracle JOB或J2EE Schedule机制，对需要定期整理的数据实施定时处理。

支持服务流程

项目管理流程

我方有一套先进、专业和完整方法论，为我方服务业务的实施提供全面和有力的支持和保障。它集成了多家大型IT服务和项目管理和实施经验和业界项目管理最佳的实践基础，由一系列的指南、模板、参考和工具组成，内容涵盖了项目管理的五大过程和九大知识领域，与项目管理协会（PMI）的项目管理知识框架和指南相符合，在全球范围内得到了广泛而成功的应用。可以使项目的管理更加效率，减低项目风险，提高和优化项目质量，为项目成功提供有效保证。

我方公司拥有通用项目管理方法。每个项目都应在此基础上，针对各自项目的不同类型和特点，进行适当的剪裁和调整，提供更适合项目的、更有针对性地管理方法。

问题升级流程

我方公司具有完善的、全球性的技术支持网络，并设置了正式的疑难问题升级流程，以便解决复杂的系统问题。任何疑难技术问题，都可以利用升级服务的支持手段，通过我方公司全球技术中心和第三方合作伙伴予以解决。

大客户支持流程

我方大客户支持流程主要包括：

• 支持计划建立流程
• 定期技术服务流程
• 定期运行回顾流程

定期服务回顾（OR）是一个交流机制。通过它，我方公司的客户支持服务团队与客户的团队一起，回顾所经历的活动，并确定未来的工作计划。这些会议原则上每季度举行一次。会议主题一般集中于客户服务计划（ASP）的执行、更改，以及进展中的支持服务任务状态等方面。该会议旨在确保我方公司提供的支持服务与客户的工作计划最佳同步。 《支持服务回顾报告》的目的是回顾最近一段时间的支持维护情况，对当前系统支持维护的状况进行总结分析，帮助客户 IT部门了解当前系统状况以及系统在一定时间范围内的可用性及故障情况，记录客户服务计划（ASP）的实施进度，了解系统运作中存在的隐患及改进方法，提高系统管理水平，同时，汇报将来的服务安排。通过此文档，客户能够更加全面地了解系统运行的状态以及我方公司已经提供的各项服务内容。

《支持服务回顾报告》至少包括下列信息：

• 一般性信息：

概述

当前服务级别

联系方法

• 服务回顾：

客户服务计划（ASP）执行情况

增值服务

常规服务

重大事件回顾分析

远程支持服务记录

现场维修服务记录

系统变更情况

• 问题和建议
• 下一步行动计划
• 客户满意度及期望调查

现场维修流程

我方现场维修流程主要包括：

• 现场维修流程
• 预防性维护流程
• 系统安装流程

服务管理流程

故障升级体系

故障是否应该升级处理的标准为：

• 在业务繁忙时发生故障并严重影响业务，无法及时找到解决方案；
• 重要问题在2小时内仍不能解决；
• 需要更多资源解决此类复杂问题。

故障升级前，客户服务代表会将整个问题情况汇报给部门经理，共同讨论如何及时充分调动我方公司的资源为客户服务，或是否需要其他途径将问题升级处理，客户服务代表或我方公司地区经理可以成为故障升级的客户满意度经理。

客户服务经理（ASM）是面向客户的故障升级负责人，出现故障升级时，其主要工作内容为：

• 确认客户已经知道问题已经升级处理；
• 确保问题被妥善解决，同时要让客户满意；
• 保证客户和我方公司的管理层都明确了解升级处理的每一状态。

紧急响应流程

服务级别管理

我方将按照与客户讨论确定的服务级别来规范和要求运维工作。为了保证符合服务级别要求，我方的项目经理会进行服务级别管理，具体内容如下：

服务级别达成准备

服务级别管理方法

服务级别保障计划

运维服务计划与沟通计划

运维服务计划

集中运维的规范和持续优化

我方服务的核心理念是与客户建立统一联盟，基于我方公司提供的运营IT服务管理（Operational ITSM）的经验，依据业界的规范和标准，订立务实的阶段性目标，持续完善、优化运营工作。以达到削减风险、增强服务管理成熟度的目的。其最终目标是提升IT部门的工作能力，并系统化、模型化地向公司高层及业务部门展现IT服务工作成效。

（1）识别运营中的风险和薄弱环节

在运营管理过程中收集工作信息和实际工作内容，衡量服务效果和质量，目的是识别风险和薄弱环节。

（2）建立服务改进计划（SIP）

服务改进计划（SIP）标示了将要实行的关键性的改进活动、完成这些活动的时间表、以及每项活动的责任单位（如客户、我方或第三方厂商）。

（3）服务管理计划（SIP）管理辅助

帮助客户管理在该计划中定义的改进活动，并定期评估和更新。

（4）服务改进活动辅助

根据计划的内容，辅助客户提高，如参与月度会议，给出针对性建议等。

（5）配备关键业务咨询顾问（BCC）

客户的关键业务咨询顾问是系统管理方面的专家，是客户在系统管理及其改进领域的主要联络人，负责系统管理相关的建议、跟踪，也向客户提供日常例行工作的建议和辅助。

从日常运营角度，评估和衡量服务管理的落实效果，结合服务管理执行中的短板给出建议，可能的情况下为改进和提升量身定做相应的解决方案。协助客户完善目标管理范围内虚拟资源池的事件管、配置、变更管理及日常运维管理流程。

故障及服务请求响应、升级、跟踪

对于需要产品厂家处理的问题，我方现场维护人员将及时进行服务升级处理，提交详细准确的故障描述以及所需日志等信息。

对于持续未能解决的事件，我方现场维护人员督促相应厂家与服务渠道， 进行问题升级处理。对于需要多厂商协同解决的问题，我方现场维护人员将协调相关厂家，共同进行问题解决，并及时通报客户问题处理进展。我方现场维护人员将维护、更新厂商联系方式，保持支持渠道的畅通。

我方的服务团队，对于故障处理全过程进行记录，并定期分析，总结经验。

日常工作割接配合

按照客户的要求，我方现场维护人员协助客户完善的工程割接配合机制。对于需要我方现场维护人员负责的工程割接，协助客户制定完善的割接方案、应急措施和验收测试方案。对于需要我方现场维护人员配合的工程割接，能够及时配合客户处理割接过程中出现的各类问题，确保割接工作的完成。

系统技术优化

通过我方的基础设施整合设计的经验，结合客户的需求和实际情况，对基础架构服务器和存储、网络等方面软硬件平台资源优化整合设计。

为最大限度保护客户投资和硬件资产，对已购的服务器和存储的继承和集成方面提出解决方案。针对可能的需要增加的软硬件设备，提出相应的软/硬件设备配置标准和推荐建议。

服务器优化整合资源池虚拟化设计，侧重以下方面的设计：

• 资源共享
• 开放标准
• 云平台虚拟化
• 自动化管理
• 容量按需增长

IT基础架构优化设计，侧重以下前沿趋势探索和设计：

• 业务系统分布式
• 业务应用云化
• 业务应用云平台虚拟化
• 大数据业务应用

服务器虚拟化是服务器整合实现资源池化的重要技术之一，是近年来企业IT整合的趋势与发展方向。

服务器云平台虚拟化的实现方式主要有两种。一种是通过硬件模拟实现的，该方式为每个虚拟服务器模拟了物理的服务器硬件，包括了全配置的BIOS。这种方法让每个虚拟服务器好像运行在主机平台的单个处理器上。硬盘方面，每个虚拟服务器是完全独立的，在其硬盘上有操作系统和必要的应用。

还有一种是通过主机来虚拟分类的，这种方式要求主机的操作系统能支持相当数量的虚拟操作系统，并通过同样的操作系统内核处理I/O需求和安排虚拟服务器对处理器的请求。

所有虚拟平台都需要一个管理程序，该程序要高于最基础的操作系统，低于云平台虚拟化系统。管理程序通过底层的操作系统掌管每个虚拟资源的请求和所有的I/O交互。每个虚拟平台的管理程序的组成是不同的，但它们的作用通常是一样的。

通过服务器云平台虚拟化的实施，可以达到以下目标：

• 提高客户公司服务器资源的使用效率，通过低负载服务器的整合，获得更合理的系统负载与IT投资回报。
• 通过系统整合有效减少目前机房空间，服务器供电、空调环境等要求，可在现有机房环境下，为更多新业务系统的上线提供了宝贵的资源，同时实现节能减排。
• 增强部署灵活性，快速响应高峰需求，可在需求降低的情况下重新分配资源。
• 建立以服务为导向的服务器体系架构，快速满足业务和应用的突发要求。
• 降低对于服务器的管理和维护成本。

事件记录与统计

按照客户要求，我方现场维护人员将详细记录代维范围内发生的各类事件，并进行分级、分类统计。

定时进行事件统计报告， 每周、每月进行事件统计分析， 并提交事件处理报告。

重大事件值守保障

我方现场维护人员提供重大事件值守保障工作。重大事件值守保障期间，我方公司本地维护负责人，确保负责维护范围环境的稳定运行。并将负责人员的联系方式提前汇报给客户。运维人员将监控和评估网络运行状态，并实时提供技术咨询和支持，在发生故障时根据实施应急方案向客户提供最快的响应和支持。在重大操作实施或重大节假日保障结束后提供《重大事件回顾报告》，并提出合理建议。

重大事件期间，如遇到异常事件，我方现场维护人员具有足够的技术能力，在约定的时间范围内，可以及时达到客户现场，快速解决异常和处理故障，并将处理结果汇报给客户。确保客户的各项IT系统在稳定运行。

服务沟通计划

在整个项目的实施过程中，项目组内、项目组与用户之间的有效沟通极为重要。必须要制定一套有效的沟通计划与策略。

本项目的主要沟通计划如下：

• 服务报告：实施期间，由我司服务专员发布，包括周、月、半年、年报等；
• 例会：由客户与我司项目组共同召开。会议将对上次例会以来项目的进展情况，本阶段以来的工作进展进行回顾，总结问题点，分析原因，并确定解决方案。对下一阶段的工作任务进行部署。会议结果由我司发布会议纪要；
• 项目协调会：由我司服务专员发起，不定期召开，协调各相关工作界面，确定资源分配，就项目实施过程中的重大问题进行讨论，并做出下一阶段工作安排，以保证项目的正常实施。会议结果由我司发布会议纪要；
• 交流：保持通信联络，以传真、电话、电子邮件等方式进行沟通。

沟通管理是项目管理的基础，沟通管理的目的是保证项目参与各方能够及时、有效、充分的沟通，使得各级项目组织和项目成员对项目进度和质量达成共识，需要制定项目沟通计划，定义沟通管理的内容、对象、程序和办法。

项目实施过程中，项目小组内部、项目小组与用户及其他合作厂商之间的有效沟通极为重要。项目管理组要制定一套有效的沟通计划与沟通策略，包括定期举行项目工程协调会，提交项目实施进展报告，经常地电话沟通、邮件沟通等。项目经理是项目团队唯一正式的对外联络人，其掌握和控制信息发布，使项目组对外的信息沟通变为单一接口，简化信息交流的复杂性，增强信息交流的有效性。项目管理组每周召开项目进展回顾会议，回顾一周来项目整体执行情况，发现问题，解决问题。

项目沟通可以分为垂直沟通和水平沟通两类。

• 垂直沟通是指：用户与我方之间的沟通、我方与其他供货商服务商之间的沟通。

我方每周五以邮件方式向用户提交项目周报，每月末以会议形式向用户项目主管领导汇报运维项目进展情况，不定题提交问题风险变更情况报告。

各供货商服务商每周四以邮件方式向我方提交项目周报，向用户和我方汇报项目进展情况，不定题提交问题风险情况报告。

必要时各方分别向上提交项目日报，加强沟通管理的时效性。

• 水平沟通是指：我方与用户项目小组、其他合作伙伴之间的沟通，供货商与服务商之间的沟通。

运维服务商与设备供货商之间根据项目需要进行不定期沟通，沟通内容和结果须记录，并及时提交我方。

建议我方项目组与用户项目组核心成员集中办公，根据需要随时进行沟通。

主要沟通方式

• 项目进度报告：项目实施期间，由我方项目经理每周发布；
• 项目周例会：由用户项目经理、我方项目经理每周共同主持召开，运维实施关联方项目组核心成员参加例会，其他项目成员根据需要列席会议。会议将对本周以来项目工作进展进行回顾，肯定成绩、总结问题、分析原因，并确定问题解决方案，对下一阶段的工作任务进行部署确认。会议结果由项目组发布会议纪要；
• 项目协调会：由用户或我方运维项目经理发起，不定期召开，协调各相关工作界面，确定资源分配，就项目实施过程中的重大问题进行讨论，提出下一阶段工作计划安排，以保证项目的正常实施。会议结果由项目组发布会议纪要；
• 项目阶段总结：在项目各阶段工作收尾时，由用户和我方运维项目经理进行阶段工作总结，评估上一阶段工作得失，为下阶段的工作进行必要的预沟通，解决问题隐患；
• 非正式交流：保持通信畅通，以面谈、电话、邮件等方式随时进行沟通。

主要沟通手段

我方运维项目经理负责汇总、发布《项目成员通信录》，随时更新保证反映项目人员变动情况。我方建议采用公告、传真、会议、座谈、电话、邮件、培训、文档查询等多种渠道进行全方位沟通。其中公告、传真、会议、邮件、培训为正式沟通方式。

项目组内部讨论和语言为中文，项目文档主要使用简体中文。为确保文件的兼容性，项目组成员须使用以下软件创建和修改项目文档：

• Microsoft Office Word
• Microsoft Office Excel
• Microsoft Office PowerPoint
• Microsoft Office Project
• Microsoft Office Visio
• Microsoft Office Outlook
• WPS软件

文档服务器是知识共享的基础，作为项目文档的载体，文档服务器承担着文档交换、存储、更新的诸多功能，为项目知识储备和转移奠定了基础。项目实施各方提交的各类技术和管理文档需要妥善保管，文档服务器由用户项目经理负责提供，并安排专人进行管理。

项目会议制度

会议名称	会议目的	会议主持
工程专题会议	为解决单项工程实施过程中的技术或管理问题而召开	关联方项目经理或架构师
项目协调会议	解决工程实施中出现的突发性问题和故障、范围分歧、责任纠纷等无法直接达成一致的问题	用户项目经理我方项目经理
项目每周例会	检查项目实施进程和状态，确定下周工作计划，了解项目组反馈意见	我方项目经理
项目启动会议	为实现高效的项目实施管理，使工程实施各方在共同指导思想下协同作业，同时建立各方各层次之间的有效沟通渠道。	用户项目经理我方项目经理
项目阶段汇报	汇报本阶段项目实施进展和完成情况，以求获得批准进入下一阶段	我方项目经理用户项目经理
项目评审会议	针对各单项工程完成并提交的项目交付成果，组织相关人员进行检查和确认	评审负责人
项目验收会议	按照合同约定的验收要求，召开项目验收会议，确认项目完工并达到建设目标	用户项目经理

项目报告制度

报告名称	报告内容
关联方项目周报	上期遗留问题解决情况；本期计划工作进展及完成状态；目前待解决问题；频率及时间：每周四下班前以电子邮件方式上报至集成商责任人：关联服务方
运维项目周报	上期遗留问题解决情况；本周计划工作执行及完成状态；目前待解决问题；风险识别及规避；时间：每周一上班前以电子邮件方式提交项目领导组及项目核心成员（PMO）；责任人： 我方
阶段性总结报告	项目阶段工作计划、执行和完成情况；总结回顾本阶段项目管理工作；总结本阶段工程实施经验教训；目前待解决问题，以及下一阶段工作要求。时间：根据项目阶段计划确定。责任人： 关联方提交阶段性工作报告，我方商汇总后提交项目领导组及项目核心成员（PMO）

会议纪要模板

项目名称
会议主题
会议时间		会议地点
会议主持		会议记录
参与人	单位	姓名	角色
参考文档
会议内容
小结/重点
后续工作
序号	描述/要求	负责人
1
2
3

运维实施质量管理

质量保障方法

我们提出系统运维服务项目质量保障方法，为了满足客户质量需求。项目质量管理保障方法包括过程质量管理和交付物质量管理。

质量管理的首要任务是确定质量方针、目标，核心是建立有效的质量管理体系，通过具体的质量计划、质量控制、质量保证，确保质量管理目标得以实现。

在项目执行过程中，我方将严格按ISO9001质量标准体系对每个交付物的质量进行把关，以保障项目集成服务的质量。具体包括：

• 评审和验证：项目实施过程中，我方将对环境勘察、需求分析和方案设计的内容进行评审验证，形成规范化文件，保证设计结果符合系统运维服务项目需求。
• 实施与测试：严格按设计方案和规范指导运维实施，并进行测试验收，遇到特殊情况需要变更原定设计方案时，必须经双方项目经理同意，并办理方案修订手续，不得擅自变更设计方案，不得违背设计方案实施。
• 文档管理：我方将对所有项目文件进行有效地控制和管理，以保持质量管理体系运行的系统性和规范化。这些文件包括项目管理规范、项目质量计划、技术文档、咨询实施中的记录等，还有一些国际及国家标准文件等。

功能简介

云平台

介绍

实现农情统一数据监管平台本要求在于借助将多元化的业务放在一个网络当中实现集成化的管理和控制，促使每一种管理系统获取相应的数据，并对这些数据进行分析和计算，从而更好地开展相应的农业服务工作。

功能

数据实时分析和查看

硬件可视化数据：展示平台接入所有硬件设备的基本数据展示和设备当前运行状态展示.用户可通过点击对应的设备查看 设备运行日志数据，设备当前实时测量数据，设备传感器状态，设备历史数据（用户可按照定义时间，数据字段等方式选择查询数据）来查看对应板块数据和汇总。

预警信息查看和展示

可视化中心：汇总触发系统虫情系统报警内容和气象系统，水肥系统等系统中的告警和预警信息按照图表可视化处理方式使用柱状图，饼状图，折线图等方式按照日月年等用户可自定义维度来展示整体数据发展趋势和关键数据的占比。

设备运行态势监控

设备管理中心：将硬件设备按照示意图和设备运行状态进行展示，设置对应硬件的告警阈值和报警和监控机制，自动将报警设备有限展示 并显示对应设备可能出现的问题清单。

水肥一体化监控中心：查看对应设备传感器状态实时监控和预警，用户可实时查看对应的当前压力状态，灌溉流速，水肥比例，过滤设施工作状态来查看水肥一体系统是否运转正常，系统将按照不同颜色区分来展示，如出现红色预警状态 系统自动创建工单推送指定维护人员。

硬件设备远程和联动

设备联动管理中心：可将对应的相邻设备进行系统关联，例如水肥和监控设备，虫情和监控设备等等进行系统内部关联，帮助系统设备相应阶段来调用关联设备数据和查询。

设备运作模式设置中心：选择对应的联动设备，填入对应模式名称和选择对应运转时间段和轮换周期来创建工作模式，设置完成后系统关联设备将按照关联模式执行计时的作业任务.用户可在设备中查看当前设备的运作模式，系统中同一时间为避免冲突内运作模式只能设置一个。

设备巡检和管理

1. 系统整体展示按照虫情，病情，监控，土壤墒情，气象，水肥一体化等 物联系统单独区分，按照3d建模方式在模型中展示对应类型的设备信息。
2. 用户可点击对应的设备展示相应设备数据和信息，用户也可切换成为列表展示模式，采用表格展示对应的设备信息，显示当前物联设备数据信息实时监测数值和对应设备的运行状态。
3. 用户在Pc/App上实时查看测量数据和搜索对应的历史数据，后台系统支持导出对应的测量历史数据。
4. 设备离线自动触发告警，推送相应的告警信息至系统关联人员。
5. 系统遇到设备严重告警自动创建对应的报事工单到系统中，对应设备维修上线后自动消除工单系统自动完成业务闭环，完成维护或者更换其他设备后用户可手动消除对应的工单。

设备巡检

一：介绍

通过设置系统当前设备列表，设置维护人员对设备进行日常保养和维护，包括但不限于 设备充电线路检查，设备运行状态的检查，设备零件的更换等。

二：工单系统

1.用户可在后台创建和维护对应的工单类型和工单审批流程和审批节点设置.

2.用户可手动创建对应的工单，选择对应的系统成员来指派对应的工单和分配完成时间可具体到日期，用户根据权限查看对应的工单信息内容来处理对应的工单信息。

3.被指派的人员的工单 可在Pc/App收到一条对应的系统推送消息，被指定可在系统中完成和处理对应的工单信息和操作后，指定专人可收到一条完成消息的推送信息，点击推送消息可查看完成详情，如完成结果不符合要求 可重新开启工单要求指定人继续整改或者更换具体的整改人。

4.所有已处理和未处理的工单信息都汇总展示在可视化信息中。

三：硬件巡检系统

1.用户根据对应的设备来创建对应的巡更点位信息，巡更点位配合工单系统来创建对应的巡更点位信息。

2.用户可在后台管理系统中配置对应的设备维护人员，按照设备类型配置对应的维管人员，可按照作业制度设置当日具体的巡检时间，用户可选择对应的循环模式例如每天，每周，每月等维度来自定义循环对应的巡检计划.

3.用户可通过PC/App来查看对应巡检计划关联的工单信息，通过审批信息来管控对应的巡检的结果。

4.系统设置对应的点位巡查签到机制，自动触发遗漏点位巡更确实预警，预警后将推送短信/app到用户手机中，系统自动汇总和统计对应的每日任务 按照巡更状态和巡更点位来汇总和分析对应的巡更计划的执行状态进行实时的监督和查看。

在线专家平台

介绍

农业专家远程诊断服务系统，采用无线传输技术、网络视频压缩技术术将视频信息、控制信息等监控数据进行压缩编码，通过无线数据网络，传给专家，实现专家足不出户，即可远程实时指导、浏览和在线答疑、咨询等服务。并可记录视频信息的一整套远程专家诊断系统产品。

在线专家平台

专家库

专家展示：展示平台中所有专家信息，用户可通过名称，职称，专业学科进行分类筛选所需要咨询的专家，用户可选择留言和实时沟通。

专家排班：系统可按照专业设置专家排班轮次和排班时间帮助农技人员实时在线解决问题。

热门专家排行：展示系统中回复积极性高，用户好评度高，月活跃度高专家名称

论坛交流

论坛发布：选择对应的农林专业加问题和图文描述发布相关问题帖子到论坛交流中心，论坛交流中心将按照问题分类自动推送给相关专家查看和回复。

专家诊室

提供一对一专家在线实时聊天预约服务，专家接受预约后将自动接入即时通信系统，支持语音电话，视频在线，图文聊天等多种沟通方式

智能硬件

虫情监测简介

孢子捕捉仪也叫智能远程拍照式孢子捕捉仪，可实现全天候无人值守自动监测孢子情况，该智能孢子捕捉仪可定时清晰拍摄孢子图片，远程上传至系统平台，便于实时查看田间孢子情况。

虫情检测系统

1. 前端功能介绍
2. 检测硬件设备内置GPS定位功能，根据建模在地图中查看设备站点等数据。在PC云端地图中查看设备站点等数据，设备被盗可追踪，保障设备的安全，所有硬件设备可通过后台管理系统按照物联控制协议远程手动控制换位、诱虫灯开启、加热管通断、杀虫仓和烘干仓清空、震动电机开关、传送带开关等功能。
3. 运用无线传感技术，摄像头实时识别记录对应的害虫数量统计汇总在对应的PC和App上展示，后台管理系统可根据不同的作物设置对应的标靶虫害预计阈值，仪器自动计数和灯下人工计数的动态趋势拟合度≥0.90，当设备计数达到预设阈值后自动触发对应的预警信息和短信信息至App/PC和关联人。
4. 实现农林业野外实时虫情自动成像、内置高清工业摄像机。可远程设置工作模式，通过PC云端及手机APP端能远程自动拍照和手动拍照，支持远程实时传输支持自动拍照，可调时段拍照，拍照可调频率区间≥〔10min,3h〕/张，可通过后台管理系统管理来设置对应的频率和图片浏览和查看。
5. 虫情测报信息结合物联网小气候信息采集系统采集的环境因子数据，通过后台系统预设昆虫模型智能运算模型，控制频振诱控技术、微生物喷雾设备、天敌自动释放设备、温湿度控制是否进入自动工作状态，针对对应的应急情况设备可支持手动激活，便于用户处理对应的紧急事件。
6. 利用虫情测报自动采集系统，掌握昆虫活动时间、活动种类和天敌数量，靶标害虫生活习性规律，设定对应硬件设备的工作时间段，同时上传系统进行对应的虫害的大数据可视化分析和统计，所有统计数据支持自定义灵活导出。
7. 利用虫情测报自动采集系统，结合物联网远程监控系统，实时掌控、监测靶标植物危害状态，为管理者及时进行防控提供决策依据。
8. 支持虫情系统与其他硬件设备联动，用户可在后台设置对应的关联设备，关联后可实时查看对应设备的数据，例如当虫情发生预警时，用户通过监控视频回放查看对应作物的生长状况，也可通过联动墒情检测系统查看当前土壤的酸碱程度，湿度，温度等来研判土壤是否适合对应的病虫害繁殖的条件等.

病情检测简介

设备启动后黑光灯发出的光照吸引昆虫聚集，诱导昆虫飞扑撞击透明玻璃瓶并坠落，通过落虫、烘干、虫水分离、传送、拍照、收集、清理等功能实现对虫害的发生与发展进行分析和预测，为现代农业提供服务，满足虫情预测预报及标本采集的需要.

病情检测系统

1. 检测硬件设备内置GPS定位功能，根据建模在地图中查看设备站点等数据。在PC云端地图中查看设备站点等数据，设备被盗可追踪，保障设备的安全.
2. 硬件设备可通过后台管理系统按照物联控制协议远程通过后台管理系统可灵活配置设备开关机远程设置开关机模式，是否自动拍照和拍照数量或通过PC和App控制手动拍照采样的时间和拍照数量，设置对应的工作时间段.
3. 通过物联网设备状态协议 可实时查看病情检测硬件设备物联工作状态和离线状态，查看对应样本采集时间和照片详情，查看箱体内温湿度等设备状态和信息，通过后台管理系统预设对应的载玻片对应的预警阈值，触发后自动触发对应的预警信息和短信信息至App/PC和关联人。
4. 通过物联协议用户可通过Pc/App实时查看，会看对应工作时段的照片数据，可自定义筛选时间段，采用云服务器技术，实现对病菌孢子图片的人工统计与分析，可实时人工远程查看确认，缩短了预测预报周期。
5. 虫情检测系统可与自动气象站监测系统、智慧农业物联网监测系统相结合完成自动监控虫情、风速、风向、雨量、光照、灌溉、施肥、喷药、降温和补光等日常操作。
6. 虫情可存储多年的检测数据，可随时按害虫种类，时间，等多个维度来筛选对应的数据，用户可在App/PC上实时查看和导出对应的数据用于分析和对比，系统实现数据环比查看历年虫害变化趋势分析出对应的系统阈值的合理性和新的病虫害预防方向和实施方案。
7. 系统可设置突发病虫害预防应急预案，用户可自定义硬件设备的功率和工作时长等预案信息，也可手动触发预案演示便于用户展示对应的病虫害的系统预防的联动。

监控系统简介

远程监控系统具有视频监控、环境监测、无线覆盖等功能，主要用于远程查看基地作物生长情况，育种家可在任意地点通过浏览器查看视频，所有监测数据都可按实时上传，管理者及时进行防控提供决策依据。

监控系统

图1.0视频监控系统

前端部分：

前端支持多种类型的摄像机接入，前端网络摄像机按照标准的音视频编码格式及标准的通信协议，可直接接入网络并进行视频图像的传输。

传输网络部分

前端与接入交换机之间可通过3种方式连接：光纤收发器的点对点光纤接入方式，直接接入交换机方式（距离100米以内），点对多点光纤PON接入方式，将前端信号汇聚至中心的核心交换机。

平台、统一的切换控制系统和统一的显示系统，实现对整个系统的统一配置和管理。

3.硬件对接功能

系统提供对视频设备和服务进行监控，采集设备和服务信息，并对采集的结果做一定的统计分析、生成告警，为视频监控平台提供可靠的信息来源，实现智能化运维管理。

对园区支持ONVIF协议的监控设备，系统可实现视频接入，完成设备名称、设备型号、OSD信息的接入，支持标准ONVIF协议接入，能够远程管理设备，支持硬件参数设置、通道名称设置、修改IP地址等参数设置。系统不支持标准（ONVIF/GB28181）协议的监控设备，可实现视频接入，完成设备名称、设备型号、OSD信息的接入，支持标准ONVIF协议接入，能够远程管理设备，支持硬件参数设置、通道名称设置、修改IP地址等参数设置。

系统支持RTSP协议去留的监控设备，可实现视频接入，完成OSD信息的接入，支持标准RTSP。

除了这些功能，本系统还可依据平台与其他智能终端硬件、各子系统的联合工作，实现智能一脸通功能、智能入侵报警管理功能、生产可视化管理功能及环境监测功能等。

4.平台部分

应用管理平台部署在通用服务器上，可以对视频监控设备和用户进行统一管控，并实现浏览、回放、下载等视频应用。

3.1用户通过App/Pc系统连接对应的物联协议可实时操作对应的摄像头 转向，旋转，上下，放大和缩小等操作，监控设备携带GPS定位功能，用户在地图上查看对应的设备的在线状态，当设备离线时会发送对应的预警信息和短信信息至App/PC和关联人。

3.2报警管理分为设备吊线报警、服务器异常报警、监控点报警、报警器报警。监控点报警为监控点的视频类报警，包括移动侦测，视频丢失，遮挡报警等。

3.3系统除提供日志管理、规则管理、预案管理等基础功能以外，可与其他系统进行联动，对紧急事件做到快速反应，提供报警管理、联动管理、处警管理等日常运维管理、事件处理调度功能，为企业的综合安全管理提供高效管理手段。

3.4用户可自定义监控报警机制，包括入侵报警，火情报警，人员离岗等等，当监控设备在设定时段监测到人员非法入侵后 监控自动拍照留存和联动其他监控设备 对其入侵路线进行记录，同时推送对应的报警短信到对应的责任手机上。

3.5设备报警系统被触发后，报警主机给一个信号到联动对应设备功能，监控设备与监控主机的通道连接，监控主机一旦收到监控设备的报警信号（模拟量报警的机制即是电压超出事先设定的阈值范围产生报警，开关量报警的机制即是通道的开关与事先设定的正常状态的对比，产生变动即为报警）将通过软件预设或硬件（产品可以做到硬件的直接联动）将输出一个开关量信号到对应的DO（开关量输出）通道，联动与DO通道连接的设备开关。例如：虫情检测设备高温报警，土壤湿度过低联动加湿机开启，酸碱度失衡联动水肥一体化设备，报警设备提供一个干结点，通过干结点连接到监控主机，联动其他设备维护整个系统的预警.

3.6功能包含消警、处警记录、误报管理、忽略报警，监控点报警关联相关录像记录可通过系统进行调用，处警流程闭环管理。

3.7系统对前端设备的视频资源进行统一存储管理，包括对前端设备的录像计划配置，集中存储的录像计划配置。

3.8系统对内部的网络运行状况，设备运行状况、服务器运行状况可进行监视和管理，并能以各种图表的形式进行实时显示，并提供资源清单管理、远程维护管理、性能管理、故障管理、日志管理等功能。对各种维护数据可以进行查询、统计，并生成相关报表。

图1.1墒情检测系统

土壤墒情监测系统简介

土壤墒情监测系统能够实现对土壤墒情（土壤湿度）的长时间连续监测。用户可以根据监测需要，灵活布置土壤水分传感器；也可将传感器布置在不同的深度，测量剖面土壤水分情况。系统还提供了额外的扩展能力，可根据监测需求增加对应传感器，监测土壤温度、土壤电导率、土壤PH值、地下水水位、地下水水质以及空气温度、空气湿度、光照强度、风速风向、雨量等信息，全面、科学、真实地反映被监测区的土壤变化，可及时、准确地提供各监测点的土壤墒情状况，为减灾抗旱提供了重要的基础信息。

土壤墒情系统

1. 设备硬件管理系统
2. 设备携带GPS定位功能，用户在后台绑定设备后，系统将采用3D建模方式在后台地图上展示当前设备的运行状态和对应设备的实时测量数据，点击设备可远程控制对应传感器工作状态.
3. 当设备离线时会发送对应的预警信息和短信信息至App/PC和关联人，用户可依据接入的物联硬件设备协议远程控制传感器开关，灵活设置传感器的作业时间和期间，设置对应的循环模式，实现一次配置后，系统自动循环作业模式。
4. 用户可通过物联协议远程可设置对应的设备的作业模式和查看历史采集的土壤温度、电导率、PH值以及地下水参数、等数据，用户按照作业模式维度，时间维度，数据区间维度 来自定义查询，分析和导出对应的墒情数据.
5. 用户可在后台管理系统中设置对应的监测设备的报警阈值，当系统接收的数据值达到系统阈值后自动触发报警功能，同时联动“水肥一体化”系统来平衡对应的土壤的酸碱度和土壤的温度和湿度 。
6. 土壤墒情系统硬件采集设备数据进行大数据分析和可视化信息处理，用户可在系统中数据自定义建模来展示对应数据驾驶舱中展示实时测量数据，同时系统将已处理，未处理预警数据发布到平台系统中进行滚动展示。
7. 用户通过后台管理系统 可联动对应点位的视频和气象设备进行综合数据分析和拉取，设定对应的分析维度进行综合大数据的分析，对应的分析维度的数据可导出和打印。
8. 系统对前端设备的采集数据资源进行统一存储管理，包括对前端设备的检测计划配置，历史检测数据等。

图1.2气象监测流程

气象采集管理系统介绍

气象环境数据平台是基于在线监测监控系统的基础上，在设计上融合了物联网技术、云技术、多网融合等多种技术方案，通过实时采集空气温湿度、风速、风向、雨量等环境数据信息，构建全方位、多层次、全覆盖的生态环境监测网络，推动环境资源高效、精准的传递及海量数据资源中心和统一服务的支撑平台建设。

气象采集管理系统

（1）通过智能传感设备实时监测空气温湿度，风速，风向，雨量，突然温度等多种气象参数，可存储整个生育期内容的气象信息，整合所以数据进行数据可视化大数据分析。

（2）用户可通过后台/Pc查看对应设备的运行状态和作业模式设置，远程通过物联协议输出开关量控制信号，实现设备的远程控制，设备采集的数据存储和访问进行加密和远程备份保障数据的持续性和安全。

（3）后台用户可通过GPS定位查看对应的设备位置，可实时查看实时数据采集针对历史护具支持按时段统计、曲线分析、支持下载，打印等操作，用户可后台配置对应的设备测点信息和对应的设备维保状态展示。

图1.3水肥一体化系统架构

水肥一体系统介绍

水肥一体化系统，通过对水、肥、土壤多因子的综合调控，帮助用户提高水肥管理效率，节约用水、高效施肥，并达到增加作物产量和改善品质的目的。

水肥一体化技术是将灌溉与施肥融为一体的农业新技术。其运作流程为：将可溶性固体或液体肥料，按土壤养分含量和作物种类的需肥规律和特点，配兑成肥液；通过可控管道系统供水、供肥，使水肥相融后，通过管道、喷枪或喷头形成喷灌，均匀、定时、定量，喷洒在作物发育生长区域，使主要发育生长区域土壤始终保持疏松和适宜的含水量。

水肥一体系统功能

1.借助现场物联网监控网络、高清摄像头等技术，工作人员可精确获取作物生长环境、作物生长情况、备远程控制执行情况、气候变化等，及时调整灌溉、植保等农事活动。

2.系统联动土壤墒情系统，气象检测系统精准采集土壤温度、土壤湿度、土壤EC值等土壤墒情，以及空气温湿度、光照度、CO2浓度等环境数据，通过历史数据和作物生长习性分析农作物全生长周期的生长需求、未来72小时气象数据等，

3.系统可为农作物制定科学的灌溉方案，通过系统设置对应的灌溉方案将所需营养和水分定时、定量自动输送给作物，指导农作物全生长周期科学生产。

4.利用先进的压力灌溉系统，系统后台可配置传感器将作物的肥液与灌溉水按需配比按照不同植物不同的季节和生长环境设置成固定灌溉模式，系统自动触发对应的灌溉指令将水肥一体化精准、均匀地输送到作物根部，实现无人值守自动灌溉，大幅节约劳动力，提升生产效率，降低成本。

5.设备传感器状态实时监控和预警，用户可在后台实时查看对应的当前压力状态，灌溉流速，水肥比例，过滤设施工作状态来查看水肥一体系统是否运转正常，系统将按照不同颜色区分来展示

可视化驾驶舱

首页

可视化首页展示虫情、病情、监控、土壤、气象、水肥、设备等每个模块综合数据信息；展示作物种类，数量，天气情况，当前设备预警情况。通过首页可查看系统各个模块数据统计，知晓作物基本情况。

首页示例图

虫情检测

汇总展示检测设备的数据，对实时虫情、虫情分析、害虫种类、实时的区域统计数据和对区域数据趋势进行分析展示，为虫情应对提供强有力的数据参考。

• 实时虫情

展示设备监控画面，通过画面可清晰查看监控范围内的虫情情况，驾驶舱可进行切换设备查看不同区域的监控画面。展示所有设备检测到的害虫数量汇总。

• 虫情分析

虫情分析主要对设备采集数据进行分析，可以查看单位时间段内增加的害虫数量，害虫种类，再根据系统设置的临界值做相应的预警警告显示。当害虫种类达到临界值时虫情分析驾驶舱界面出现预警图标。

• 害虫种类

害虫种类分析，展示害虫的种类数量，展示每一种害虫的数量，展示单位时间内某一种害虫的增加量，通过该数据可对增加数量快的害虫进行针对性的灭虫方案规划。

• 实时状态

实时展示设备的情况，如杀虫温度、烘干温度、电池电量、诱虫灯状态、虫雨挡板状态、杀虫挡板状态、烘干挡板状态、移虫装置状态、震动状态；实时监控设备的运行情况。

• 区域统计

根据区域划分对不同区域的虫情综合数据进行统计，区域内虫情增加情况，区域内虫情种类情况，区域内设备灭虫情况，区域内设备运行情况。

• 趋势分析

根据区域数统计数据进行趋势分析，通过区域内虫情的增减速度，设备的运行数据统计分析可预判对应区域的作物生长气势，对产量的影响气势大小做出对应的分析。

病情检测示例图

病情检测

展示作物病情监测数据，和通过APP或者PC端管理后台上传的病情进行分析展示。

• 病情类别展示

作物病情统计，种类统计，展示不同区域病情数量。

• 染病数量

作物病情种类展示，每种病状对应的作物数量，单位时间内增加的病株数量。

病情检测示例图

监控系统

监控系统主要实现驾驶舱内对作物生长区域的视频监控系统、气象检测系统、土壤墒情系统、水肥一体系统等系统的数据进行综合分析展示，对基地的气象信息，作物生长情况等进行监控。

• 视频监控系统

驾驶舱展示各个监控区域监控画面，可对摄像头进行切换。

• 气象检测系统

气象数据实时展示，展示温度、湿度、风向、风速、关照情况、PM数据等情况进行实时展示，展示历史气候信息。

• 土壤墒情系统

将墒情设备检测的数据进行汇总分析展示，主要展示温度，湿度

• 水肥一体系统

在可视化驾驶舱界面展示水肥系统中检测的水肥情况和处理情况，记录不同时段的土壤情况，如水含量、肥料含量，展示系统配兑的养料情况。

监控系统示例图

土壤墒情检测

对土壤墒情（土壤湿度）的长时间连续监测数据进行可视化展示，将获取不同的深度的土壤水分情况，土壤温度、土壤电导率、土壤PH值、地下水水位、地下水水质以及空气温度；以及空气湿度、光照强度、风速风向、雨量等数据，全面、科学、真实地反映被监测区的土壤变化，并将数据进行分析展示。

• 土壤情况

将土壤水分情况，土壤温度、土壤电导率、土壤PH值、地下水水位、地下水水质情况实时展示到数据大屏，按周期展示不同时段的数据情况，汇总到一个变化统计图中进行趋势分析。

墒情检测示例图

气象监测

可视化驾驶舱实时监测空气温湿度，风速，风向，雨量，温度等多种气象参数，展示不同时间段呢气象信息。

• 气候情况

将气候数据气温、光照强度、风速、雨量等天气情况数据进行单项多时段数据展示。

气象监测示例图

水肥一体化

水肥一体化技术将灌溉与施肥融为一体，可视化大屏将可溶性固体或液体肥料，按土壤养分含量和作物种类的需肥规律和特点，配兑成肥液；通过可控管道系统供水、供肥，使水肥相融后，通过管道、喷枪或喷头形成喷灌，均匀、定时、定量，喷洒在作物发育生长区域，使主要发育生长区域土壤始终保持疏松和适宜的含水量。

• 水肥一体系统

在可视化驾驶舱界面展示水肥系统中检测的水肥情况和处理情况，记录不同时段的土壤情况，如水含量、肥料含量，展示系统配兑的养料情况。

• 肥料数据展示

展示施肥记录，展示每个月，每个季度施肥次数。

• 配兑数据

肥料配兑数据展示，单次配兑量的展示，每种肥料配兑量的多少展示。

• 喷洒数据

展示施肥喷洒记录，喷洒时间，喷洒量每次喷洒多少升。

水肥一体化示例图

设备管理

通过获取物联云平台的设备管理模块集成的物联网设备信息，在GIS引擎上标注出设备的详细位置，同时展示该设备的类型、在线状态、设备的折旧信息等，做到一张图上清晰明了查看设备信息；同时支持在GIS引擎上点击查看设备详情，展示设备的详情数据，近7日，近一月的数据统计图，监控设备可支持点击查看实时视频内容并可关联附近的虫情检测仪，害虫诱捕系统等，做到监控设备与物联设备的联动效应，提高可视化管理的便捷性。

• 基地建模

将种植基地地图进行建模生成，在模型中对应位置展示检测设备。

• 点位展示

当点击某一个点位时，展示每个点位设备对应的7天数据，监控设备可查看视频。

• 设备分类

将系统内的所有硬件设备进行分类，如监控设备、虫情检测设备、墒情监控设备、水肥一体设备等所有联网设备进行分类，可筛选展示其中一类设备。

设备管理示例图