数字化农业建设详细方案+建设模型全

数字化农业建设详细方案+建设模型目录一建设目标二技术架构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.4项目制度管理2.11.5项目需求调研方案需求调研总体流程与相关角色需求获取与确认需求变更管理2.11.6项目开发方案开发方法任务描述编码阶段软件实现阶段2.11.7安装调试方案任务描述产出物2.11.8项目测试方案测试目的测试标准测试人员测试技术9推荐测试形式测试步骤测试工具测试管理测试文档2.11.9项目试运行方案系统试运行的目的系统试运行过程检验及记录系统的改进和完善文档整理及最终版本发布准备进入正式运行2.11.10项目质量保障方案质量管理规划质量控制和保证质量管理举措源代码管理2.11.11项目交付物管理保密措施2.11.12项目验收方案项目建设验收2.12售后服务方案2.12.1概述2.12.2整体研究方法2.12.3运维服务范围现场运维技术支持定制软件维护告警配置与处理服务应用系统部署协助服务快速响应技术支持信息共享服务其他服务内容2.12.4售后服务流程服务台事故管理流程问题处理流程变更管理流程发布管理流程配置管理(CM)运行监控流程系统优化流程支持服务流程0服务管理流程2.12.5服务级别管理服务级别达成准备服务级别管理方法服务级别保障计划2.12.6运维服务计划与沟通计划运维服务计划服务沟通计划2.12.7运维实施质量管理质量保障方法三功能简介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-orientedarchitecture，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技术路线可以更快更好地为系统提供技术支撑，可选择的产品范围也更加广泛，后续的系统维护更加容易便捷，技术风险较小。基于微内核和构件化技术的系统搭建模式微内核架构模式可以适用于那些需要适应变化的软件系统。微内核保持系统的稳定性，而构件化则增强系统灵活性，微内核与业务构件化的分离实现了对系统稳定和变化的同时管理。微内核是由RichardRashid在卡内基·梅隆大学开发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端等多终端。传统终端上的NativeApp，开发者的研发工作必须针对不同的操作系统进行，成本相对较高。NativeApp还存在着管理成本、存储成本以及性能消耗成本。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（XMLMetadataInterchange）是一个存储和共享面向对象的程序设计信息的标准。Microsoft和Marimba合作提出的开放软件描述（OpenSoftwareDescription，简写为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、统一发布管理。三条线指：文档管理、源代码控制、提交物版本控制。项目实施建设内容本期项目的实施建设内容如下：物联网云平台物联云平台主要使用者是系统管理员，业务人员及系统运维人员和项目建设开发公司等，物联网云平台通过集成不同协议的物联设备，统一汇集到一个平台上，同时平台提供设备管理、设备巡检、设备维护、设备突发事件处理的闭环等功能，同时针对物联设备上报的数据建设虫情监测、病情监测、监控系统、土壤墒情监测、气象监测等应用功能，同时专家可通过远程诊断的方式给出相应的建议及解决方案。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项目的任何有关人员都能提交变更请求（CRChangeRequest）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的RecordType间的parent-child实现）间接实现来实现。下表描述在增强请求上执行的流程：活动描述角色Submit项目的任何有关人员都能提交需求变更请求，需求变更请求被提交到ClearQuest后进入CCB评审队列，状态为Submitted项目经理Duplicate判断提交的增强请求是重复的，执行Duplicate，状态为duplicatedCCBOpen将确定变更的增强请求打开，状态为openedCCBClose对于开发完成的需求变更请求，根据项目的情况决定关闭该请求，状态为closedCCBRe_open将已经解决的请求重新打开，状态为openedCCB任务流程计划的项目任务，在Project中定义后，将任务导入ClearQuest中，用于关联活动影响的工件版本。下表描述在任务上执行的流程：活动描述角色Submit项目经理的任务计划从Project导入ClearQuest项目经理Assign将任务分配给相关人员，状态为assigned状态项目经理Activate开发人员激活分配给自己的任务，生成或修改相应的工件，状态为Active开发人员Postpone开发人员根据项目目前的进度或变更可以考虑把处于Active状态的请求推迟到以后的开发阶段中处理，状态为Submitted。开发人员Complete开发人员完成任务并通过单元测试。状态为Complete开发人员Reopen将已经完成的任务重新打开，状态为Assign项目经理管理贯穿生命周期的工件贯穿生命周期的变更不只是开发人员对源代码和相关工件的管理，也可以由非开发人员进行管理。这些非开发人员包括分析人员，设计人员以及测试人员。相应的工件包括他们在相关领域产生的工件，例如分析人员所创建的需求文档和用例（usecases），设计人员所建立的设计模型和用例，测试人员建立的测试脚本，测试数据和测试结果。监测与报告配置状态监测与报告配置状态，主要包括：确定软件满足功能需求和物理需求。确定工件存储在受控制的库中。确保工件和基线可用。支持项目配置状态统计活动。这些活动基于正式化的记录，并报告已提议变更的状态以及这些变更的实施状态。通过缺陷追踪和报告活动来辅助软件系统复审。确保为追踪进展和趋势而“积累”数据并报告数据。项目变更管理项目变更控制的需要在项目实施过程中，项目的变更是必然存在的，并且合理地变更是应予以允许和尊重的。因此，实施变更的管理目的在于忠实地记录项目演变的过程，有利于项目的跟踪管理，是项目管理工作的重要组成部分。我公司在项目实施过程中，如果发现需要对系统设计进行必要的变更，或者机房施工需要变更，我们将提前5个工作日提出变更说明，在征得用户方同意后，进行系统重新设计后提交用户审核。针对系统实施过程中出现的各种变更，我公司将依据项目管理规范之项目变更管理规范执行，其基本过程如下：实施相关各方有权对需求、工作任务、进度要求、人员调动、经费等提出系统实施变更请求，实施变更提出方或发现方需填写实施变更报告，说明变更前的状态、变更原因、变更的内容，并根据具体内容提交直属负责人、项目经理或工程领导组。如果项目变更被拒绝，项目经理负责解释原因，并填入项目变更报告。如果项目变更被接受，项目经理分析由于该项目变更对工作量、费用、进度、人员安排等方面的影响，并将此内容填入实施变更报告。如该变更涉及第两方或转包方，则项目经理必须将项目变更报告提交他们，并取得一致意见。如遇到重大的项目变更，项目经理还必须将实施变更报告提交工程领导组，提请领导组对该实施变更进行讨论和决策。项目经理于接到变更提出方请求后2个工作日之内，应给予变更提出明确答复。对于提交工程领导组讨论决策的项目变更，领导组应在接到变更提出方请求后3个工作日内给予明确答复。参与实施合作的相关各方在实施变更报告单上签字认可后，该实施变更生效，项目经理或下辖直属负责人执行变更实施。项目经理或子系统负责人根据项目变更报告单中进度的变更情况，修改实施进度计划，调整实施组人员组织结构，以及实施组成员的工作安排，修改项目预算等。对于重大变更，项目经理应将实施变更报告提交工程领导组，提请领导组对于实施变更所引起的问题与各方进行协商。将实施变更报告单以及该变更所引起的进度计划、计划预算、人员组织结构、工作说明书等方面修改版本的提交各相关实施组。对于由于实施变更所产生的文档、代码等修改，遵照项目管理规范之项目变更管理实施规范执行。实施组成员以及相关人员有义务及时发现各种实施变更，并通报项目经理。项目经理有责任追踪实施变更的各项工作过程，直至变更管理工作完成，实施按新的计划执行。对所有实施变更必须进行管理，并忠实记录变更过程。及时合理地调整因变更引起的进度、预算、人员、工作内容等。变更控制流程首先由需求调研人员根据用户提出的需求变更，编写《需求变更报告》提交给项目经理。项目经理接收到变更需求后，查看是否合理、信息是否全面；项目经理委托有经验的系统设计人员和专家对变更需求进行分析，主要从变更对项目的质量、进度、费用、流程等各方面进行影响分析；项目经理根据分析报告决定变更需求是否能实施，如果不能实施，提出解决建议并召开由项目小组、公司项目领导小组参加的变更会议；通过变更会议，对变更进行裁决是否可行，如果通过，则编写《需求变更日志》；项目经理应及时跟踪变更的执行，并分析对项目实施的实际影响。项目的变更需求一旦执行，有可能会影响到项目计划的调整，这点在项目管理中要注意及时调整并发布给相关项目组成员。更改提出过程设计更改来源于项目设计改进、项目完善以及顾客的要求自主设计的系统更改来源于1）在设计阶段中出现的遗漏或错误；2）顾客要求的改变；3）设计完成后发现制造安装有困难；4）安全性、法规或其他要求发生变化；5）设计评审、验证或确认的要求更改。非设计部门提出的更改建议，由建议人填写项目功能变更单，并反馈到相应部门。非自主设计的项目更改来源于顾客的项目功能更改通知单，由销售部负责接收，按公司办公自动化系统（OA）中的工作流程下发。更改评审设计更改由项目的主管设计者对更改建议做评审，工程更改由项目的主管单位指定技术人员评审：1）作出是否同意更改的决定，并将结果回复建议部门。2）评审的内容主要有：评价对项目的组成部分和已交付项目的影响；对合同、进度和费用的影响；对设计、开发和测试的影响；对维护、用户手册影响等；并保存记录。用户的项目功能更改通知单由技术部负责评审，主要评审项目功能更改对过程的影响；对在项目的处理等。对于重大的更改，负责评审的责任单位要进行可行性评审和技术经济分析，必要时组织会议评审，并作出是否采纳或是否要验证和再评审的处理意见。编制更改方案一般的更改，由评审人员验证评审内容后直接制定更改通知单；需要验证的更改，由责任单位人员编制更改方案，并根据更改方案，制定验证方法和要求；更改验证更改部门对需要项目功能更改部分，发布验证通知单，明确验证方法和要求。验证单位接收到验证通知单后，开展验证工作，最后由验证单位将验证结果和见证材料提交给主管设计部门。更改确认负责评审的责任单位，组织验证结果的评审，作出是否正式更改的决定。更改批准更改单由资深的技术人员或技术主管审核，由项目经理批准。凡设计更改影响到用户要求，要通知用户并得到用户批准。用户批准由设计部门与用户联系并得到结果。当用户要求时，还应满足附加的验证及确认要求。更改发布更改批准后，责任部门下发更改通知单。更改通知单的编号方法按文件技术性文件编号办法执行。更改通知单下发时，必须通过个人邮件通知到相关人员。更改实施各人员收到邮件通知后，必须在半个工作日查阅更改通知单，并打印出更改通知单通知相关技术人员进行更改处理。各单位依据更改后的技术文件组织项目功能的开发和测试。需要得到用户的批准时，由更改的责任单位准备项目功能变更文件，按照项目功能变更程序步骤实施。项目文档管理对于信息化建设项目来说，交付物主要是程序、文档和设备，其中程序和文档的管理非常重要，也容易忽视。程序和源代码是应用系统运行的基础，是体现项目价值的重要因素。本节重点介绍文档管理方案。在本项目实施过程中，由于项目实施的复杂性，参与人员众多以及时间跨度长等因素，所以有关需求、建议、问题、技术方案和会议等都必须文档化、标准化，以便查阅和引用。这些文档伴随着项目实施的各个阶段逐渐充实、完善；与此同时，它们亦记载跟踪了整个实施的过程和成果。文档编制工具主要用到以下几种工具：MSWord、MSExcel、MSVisio、MSPowerPoint、MSProject、RationalRose。MSWord：主要用来编写描述性文档，例如项目章程、管理流程、需求报告、业务蓝图、项目状态报告、项目总结报告等；MSExcel：主要用来编制检测表、各种项目计划、数据准备表、问题及变更日志等；MSVisio：主要用来绘制业务流程图；MSPowerPoint：主要用来编制各种报告、培训性文档；MSProject：主要用来制订项目进度计划、资源计划、预算计划，并跟踪项目，生成各种汇报结果；RationalRose：主要用来绘制与UML相关的用例图、序列图、活动图、状态图等。文档分类和命名项目文档包含用户所要求的各项文档并且按以下情况分类：文档的命名要求是：从文件名就大概能判断文档的主要内容是什么。文档不只是给自己看的，即使自己看，过了一段时间，也不一定能够很快找到自己想要的文档。文档命名规则为“二级类别_内容摘要_版本（或日期）”，例如：PI_需求规格说明书_V1.0.doc。版本管理软件有版本的区别，文档也一样：对于每一份文档的版本号管理，以下面的规则为准：说明：版本号分总号与子号，例如Vl.0，其中的1为总号，0为子号。创建文档时为V1.0版；在未经客户方审阅前的内部审阅和修改。版本总号不变、子号递增，如：V1.1、Vl.2；经项目经理或客户方的审阅或修改后，则版本号升级，如：V2.0；当文档最终确定后，统一提交项目经理或文档管理员存档，若需要修改须通过变更流程。在每一份文档的开头，就会有类似这样一个表格说明了版本控制的信息：版本/修订版修改确认日期修改内容概述修改人批准人备注文档管理原则所有的项目文档应严格按照文档控制标准进行：从项目经理接手项目开始就指定专人建立负责项目文档管理，归集项目所有电子和书面文档，并建立文档目录。文档起草、修改人应标注编写日期和主要修改内容。文档编制时，要严格按照项目规定的标准操作，例如页眉、页脚、标题、内容编排、字体字号等，是否按标准进行，作为项目质量检测的一部分；文档须通过双方相关责任人和项目经理的会签；最终版本的文档须经过双方项目总监的签署并作为交付文档保存；文档的发放去向应准确记录收件人的姓名。对于电子文档，收件人应及时回复审阅意见。对于阶段性交付成果应同时保存具备签字的书面介质的文档原件，对于重要的邮件也要作为文档进行存档备份；对于失效版本的文档，要单独放置在一个目录中，并设置屏蔽权限防止误用；所有文档均适用于服务合同约定的保密条款；项目结束后，整理归集所有项目文档，电子文档存放在专门的文件服务器上，或刻盘保存；将书面文档按项目进度分类整理，扉页档案目录整理，装订成册，交项目档案管理人员保存。项目风险管理大型系统实施项目，风险巨大。事实上在全世界统计有近36％的大型项目以失败或近似失败而告终。项目组织体系不仅应作为管理机构，而且要在项目实施过程中，充分考虑风险因素，及早规避，减少项目的损失。在项目实施过程中，项目的风险是必然存在的，并且合理的风险变化是应予以允许和尊重的。因此，项目风险的管理目的在于忠实地记录项目演变的过程，有利于项目的跟踪管理，是项目管理工作的重要组成部分。项目风险管理原则针对项目实施过程中出现的各种变化，我公司将依据自身长期实践总结的项目管理规范之项目变化管理规范执行，其基本原则如下：项目相关各方有权对需求、工作任务、进度要求、人员调动、经费等提出项目变化请求，项目变化提出方或发现方需填写项目变化报告，说明变化前的状态、变化原因、变化的内容，并提交项目经理。如果项目变化被拒绝，项目经理应该负责解释原因，并填入项目变化报告。如果项目变化被接受，项目经理分析由于该项目变化对工作量、费用、进度、人员安排等方面的影响，并将此内容填入项目变化报告。如该变化涉及第三方或转包方，则项目经理必须将项目变化报告提交他们，并取得一致意见。如遇到重大的项目变化，项目经理还必须将项目变化报告提交项目领导小组，提请项目实施领导层对该项目变化进行讨论和决策。项目经理于接到变化提出方请求后2个工作日之内，应给予变化提出方明确答复。对于提交项目领导小组讨论决策的项目变化，项目领导小组应在接到变化提出方请求后5个日天内给予明确答复。参与项目合作的相关各方在项目变化报告单上签字认可后，该项目变化生效，项目经理执行变化实施。项目经理根据项目变化报告单中进度的变化情况，修改项目进度计划，调整项目组人员组织结构，以及项目组成员的工作安排，修改项目预算等。将项目变化报告单以及该变化所引起的进度计划、计划预算、人员组织结构、工作说明书等方面修改版本的提交项目相关各方。对于由于项目变化所产生的项目文档、代码等修改，遵照我公司项目管理规范之项目变化管理实施规范执行。项目组成员以及项目相关人员有义务及时发现各种项目变化，并通报项目经理。项目经理有责任追踪项目变化的各项工作过程，直至变化管理工作完成，项目按新的项目计划执行。对所有项目变化必须进行管理，并忠实记录项目变化过程。及时合理地调整因项目变化引起的进度、预算、人员、工作内容等。变更申请流程提出变更提出变更需首先填写变更申请表（REQUESTFORCHANGE，以下简称RFC）。RFC需提交项目领导小组。项目领导小组将就RFC的技术可靠性以及对整个项目的影响作出评估。审批结果将转给项目经理。变更审核项目领导小组将在接到RFC的10天内给出收讫说明以及分析RFC所需的时间，作出相应的项目变更建议在（ENGINEERINECHANGEPROPOSAL，以下简称ECP）。ECP将就RFC中所提出的变更对整个项目的影响作出以下几方面的说明：基本变更－文件的增改和删除；测试项目－测试计划、测试和重新测试的变更；系统性能－确认变更项目对系统性能的影响以及增加或改装其他机器是否必要。培训－培训计划、课程准备及教材；其他材料－列出所有其他材料；人员需求－确认增加其他人员的必要性；进度－项目进展情况、交付项目的进展速度和协议的终止日期；费用－变更涉及的费用。变更的认可任何或有关ECP费用或进展的变更，需由项目参与单位或各使用单位一方授权的代表以书面形式提出，由项目领导小组主任批准。实施可根据多次变更后的内容修改文件的基本内容并以注有变更日期的文件的形式重新分发。变更只包括项目领导小组通过的内容。变更程序流程变更提出方提出RFC；将RFC提交项目经理组织技术专家作技术可行性评定，并给出ECP的准备时间和所需费用估算；项目领导小组讨论变更所需的时间和费用以及是否批准RFC；变更提出方做出ECP并确认所需费用和进度；项目领导小组讨论ECP并提出实施建议；双方对ECP提出认可并同意变更提出方对合同进行修改；项目经理对控制程序进行修改。变更申请（系统名称）变更申请序号#申请人：日期：申请变更内容：申请变更原因：变更类别（标明一个）A．功能方面B.运行性能方面C.文档方面授权人签字：日期：项目沟通管理我公司将按要求建立与招标人的周报告、周例会制度，将项目工作完成的内容、进度、问题等及时与招标人进行沟通，定期向招标人汇报项目进度，并提交项目报告及相关制度报表。我公司将做好与项目组内部、与招标人、监理单位及咨询