智慧城市环卫管理系统解决方案(系统项目测试开发软件)

随着环保事业的迅速发展和信息化在各行业的普及，城市环卫工作的高效运行面临极大的挑战，如何利用信息化的手段建立有效的考核体系以便于提升管理调度水平，提高作业效率和质量，是环卫部门必须解决的难题之一。

本系统将根据环卫管理部门的实际业务需求，建立一套数字化智能环卫管理系统，对环卫局归口管理的监测人员、保洁公司、环卫车辆（洒水车、垃圾车等）、公厕、果皮箱、垃圾桶、转运站进行统一的平台化管理和调度，以提高环卫部门的科学管理水平。

为提高工作效率、结合环卫部门现有的资源，增加对环卫作业过程的管理和监控，系统在研发和设计上将实现以下目标：

对数字化环卫系统所涉及的对象基本属性、行为、关联关系等基本数据进行统一数字字典建设。

管理员可以将对作业区域进行统一管理，指定具体人员/公司负责区域，并可及时查询各对象的任务区域和作业详细情况。

将现实传统的考核方法以信息化形式进行实现，提高作业考核的即时性，减少人为的数据统计，从而有效提升作业考核的效率。

通过考核人员和平台管理员的对讲通话，实现作业区域考核信息的及时上报，并调度相关单位进行处理。

系统实现主要以GIS地图结合系统数据的直观展现模式，将各对象的地理信息位置结合系统算法标记在矢量地图上。

系统管理员：设置系统基础信息，定义各个角色系统使用权限，维护系统日常使用；

环卫局领导：可查看系统的任何信息；

信息维护员：维护系统基础信息；

保洁公司：可接收考核结果通知及消息；

监测员：可录入监测对象的考核结果；

1.5 词汇、定义、参考文献

本文中用到的专门术语的定义和缩写词的原词组列表：

系统架构采用Browser/Server模式，分为表现层、业务逻辑层、数据层。
其中业务逻辑层又包含业务管理、用于处理与其它系统接口的Http Service服务组件；

系统采用Windows2003 server/CentOs作服务器OS，SQL Server2005/MYSQL作为DBMS。
采用JavaEE/Microsoft .Net进行开发。

环卫局数字化环卫管理系统以处理环卫作业中的考核对象为主线，把考核目标分为不同的维度来实施，在每个实施过程中又按作业对象来进行划分。
系统通过对作业任务的监控来达到对作业对象的跟踪和考核。

本项目采用MVC模式进行开发和设计，我们采用各层分离的方式使层次之间达到低耦合，从而增加程序的灵活性，并降低了维护的成本。
数据结构和服务采用模型驱动的方式进行开发。

2.3.2功能模块划分原则

系统功能模块的划分，遵循着松耦合易扩展的原则，将每一个功能模块高度封装，模块与模块间完全通过接口实现信息传递。

模块通过接口构建起紧凑牢固的系统结构，而某一个功能模块影响不到整个系统的正常运转，达到松耦合的目的。
通过现有模块接口可以轻松挂接新的功能模块，且可以达到“即插即用”的效果，即实现了系统的易扩展性。

逻辑业务通过调用基础数据来管理监控考核作业任务的执行情况，外部系统通过系统服务接口来访问数据。
系统功能严格按照用户的权限来实现功能。

网络拓扑结构及硬件规划：

系统主要通过考核人员对作业现场的实际考评，通过对讲设备将在指定时间内向平台报告考核区域/点的考核情况。

为保证数据的安全性，系统部署在环卫局的计算机中心机房，服务器与互联网分离，采用防火墙进行安全隔离,系统的访问采用严格的权限体系以保网络数据的安全。

2.4 软件功能设计2.4.1 系统管理

（1）用户管理

针对使用该系统的管理人员进行帐号基本信息的增加、修改、删除和查询统计，明确用户使用范围。

（2）角色管理

角色是系统使用的权限集合，针对系统用户的特点，可分别赋予不同的角色，从而使得用户方便继承角色的所有权限。

（3）权限管理

管理系统所涉及的所有业务模块的权限信息，包括权限编码、相关URL、权限层次、权限类型等。

（4）数据字典管理

对系统常用的数据进行定义，定义其含义，标准值，标准范围以及数据变量等基础信息。

（5）数据库管理

查看数据库的实时状态，包括数据库容量和数据数量，并可进行数据库的备份、还原等操作。

（6）作业区域管理

根据职责的划分，将作业任务计划纳入系统的管理，方便查询浏览。

(1) 监测人员

维护监测人员的基本信息，包括增加/删除监测人员和监测人员的基本信息维护，如姓名、性别、座机、手机号码等。

监测人员可通过系统对保洁公司的责任区进行及时的考核评分，考核评分细则及分值视具体规则而定。

同时，系统将对监测人员划分责任监测区域，系统会采用实时GPS定位和对讲机通讯的方式对监测人员进行定时考勤监督。

（2）保洁公司

维护保洁公司的基本信息，包括增加/删除保洁公司和保洁公司的基本信息维护，如公司名称、简称、地址、联系电话、负责人等。

可实时查看各保洁公司的考核得分，并分等级予以不同的提示（如颜色红黄绿），可对保洁公司的历史得分情况进行查询和统计。

保洁公司可随时查询统计自己的区域考核得分。

（3）环卫车辆

维护环卫车辆的基本信息，包括增加/删除环卫车辆和环卫车辆的基本信息维护，如车辆类型、车型、车牌号、驾驶员、租用公司等。

（4）果皮箱

维护果皮箱的基本信息，包括增加/删除果皮箱和果皮箱的基本信息维护，如果皮箱编号、道路名称、管理单位（各环卫分公司及各办事处）、管理人姓名、安装时间、种类（不锈钢式，环保式等）、安装状态（预安装，已安装），可提供模糊查询。

可在地图上定位果皮箱的位置，并提供果皮箱编号、种类、管理单位以及状态等基本信息展示。

可查询统计果皮箱的使用情况，并导出报表。

（5）垃圾桶

实现垃圾桶搜索功能：用户可以根据垃圾桶编号、道路名称、管理单位（各环卫分公司及各办事处）、管理人姓名、安装时间、种类（地埋式垃圾桶，立式垃圾桶等）、安装状态（预安装，已安装）进行搜索，可提供模糊查询。
搜索结果除能在地图上显示以外，还能以表格的形式显示垃圾桶的详细信息和统计数量。

实现垃圾桶地图定位功能：地图可根据用户的搜索结果显示单个或多个垃圾桶的图标及编号，当用户点击地图上垃圾桶图标时，应显示这个垃圾桶的编号、图片、种类、所在位置、管理单位、管理人员姓名、管理人员联系方式、安装时间。

实现垃圾桶信息增加、删除、修改的功能：用户可以批量增加、删除、修改垃圾桶信息，并在提交到数据库之前显示增加、删除、修改垃圾桶信息后的结果，提醒用户检查是否有错，并提示用户是否发消息通知其他用户，最后经用户确认后提交。

实现预安装垃圾桶功能：在地图上显示两种不同状态（预安装，已安装）的垃圾桶的时候，可以用不同的颜色或图标进行区分。
当预安装垃圾桶安装完成后，用户可修改垃圾桶状态为已安装。

实现垃圾桶撤除功能：考虑到今后垃圾桶有可能因损坏而撤除或更换新型垃圾桶的可能性，用户可将垃圾桶状态改为撤除或退路。

（6）公厕

实现公厕搜索功能：用户可以根据公厕名称、道路名称、管理单位（公司）、管理人姓名、管理人员联系方式、投入使用时间、建设状态（已建成、预建设、建设中）、种类（一类公厕、三类公厕）进行搜索，可提供模糊查询。
搜索结果除能在地图上显示以外，还能以表格的形式显示公厕的详细信息和统计数量。

实现公厕地图定位功能：地图可根据用户的搜索结果显示单个或多个公厕的图标及名称，当用户点击地图上公厕图标时，应显示这个公厕的名称、图片、种类、所在位置、管理人姓名、管理人员联系方式、投入使用时间（预建设公厕和建设中公厕显示预建设时间）、备注。

实现公厕信息增加、删除、修改的功能：用户可以批量增加、删除、修改公厕信息，并在提交到数据库之前显示增加、删除、修改公厕信息后的结果，提醒用户检查是否有错，并提示用户是否发消息通知其他用户，最后经用户确认后提交。

实现预建设公厕管理功能：在地图上显示三种不同状态（预建设，建设中、已建成）的公厕的时候，可以用不同的颜色或图标进行区分。
当预建设公厕投入建设后，用户可将预建设公厕状态修改为建设中，当建设中公厕投入使用后，用户可将建设中公厕状态修改为已建成。

（7）转运站

实现转运站搜索功能：用户可以根据转运站名称、道路名称、管理单位（人环卫公司）、管理人姓名、管理人员联系方式、投入使用时间、建设状态（已建成、预建设、建设中）、种类（原建、翻建）进行搜索，可提供模糊查询。
搜索结果除能在地图上显示以外，还能以表格的形式显示转运站的详细信息和统计数量。

实现转运站地图定位功能：地图可根据用户的搜索结果显示单个或多个转运站的图标及名称，当用户点击地图上转运站图标时，应显示这个转运站的名称、图片、种类、所在位置、管理人姓名、管理人员联系方式、投入使用时间（预建设转运站和建设中转运站显示预建设时间）、备注。

实现转运站信息增加、删除、修改的功能：用户可以批量增加、删除、修改转运站信息，并在提交到数据库之前显示增加、删除、修改转运站信息后的结果，提醒用户检查是否有错，并提示用户是否发消息通知其他用户，最后经用户确认后提交。

实现预建设转运站管理功能：在地图上显示三种不同状态（预建设，建设中、已建成）的转运站的时候，可以用不同的颜色或图标进行区分。
当预建设转运站投入建设后，用户可将预建设转运站状态修改为建设中，当建设中转运站投入使用后，用户可将建设中转运站状态修改为已建成。

（1）区域管理

对辖区的区域进行维护，可在地图上直接标注地图区域，并进行责任对象的绑定。

（2）作业点管理

对辖区的作业点进行管理维护，可在地图上直接标注作业点，并进行责任对象的绑定。

2.5 系统选型2.5.1 选型原则

根据系统构架设计，结合招标技术规格要求，确定如下选型原则：

（1）软件开发环境选型原则：

符合用户提出的技术参数和产品要求

采用成熟的、稳定的技术和标准

支撑环境/产品的售后服务和后续升级质量高

采用接口标准、扩展性好的结构设计

满足具体产品的性能、技术要求

软件开发平台要提供对比选优

具有开发和应用这些软件的经验

（2）数据库选择原则：

结合系统的规模、部署等实际情况，以及应用开发的需要，在进行数据库选型时主要考虑以下因素：对平台的支持、管理海量数据、并发处理、并行处理、支持分区表和分区索引等等。

（3）操作系统选择原则：

操作系统选择重点从系统安全性好，系统运行稳定，系统运行效率高，系统支持及维护成本低廉几方面考虑。

（4）应用服务器选择：

平台支持：应用服务器支持的操作系统和机型的种类和数量直接影响其应用范围。

WebService支持：应用服务器应支持与各种Web服务器无逢的集成，稳定的协作，扩展其支持web应用的能力。

安全代理支持：应用服务器应用能够支持第三方的安全代理产品。

配置信息数据库的支持：如果支持当前主流的关系数据库，则可充分利用数据库的优化能力来安全有效的利用用户的配置信息。

集成开发工具： 应提供全面的智能化配套开发工具和各类组件。

管理工具：优秀的应用服务器应提供多种管理方式及友好的图形界面管理工具，并提供API编程接口供用户可以编写自己控制程序，方便的操作配置文件。

应用服务器专有特性：应用服务器产品有其自己产品独特的优化设计，在具体的应用环境中可保证应用的高效性，安全性等。

最后再综合考虑用户的使用习惯、普遍计算机操作能力，及因此影响的系统长期TCO成本，最后确定选型结论。

（5）操作系统选择

系统的业务服务器操作系统推荐使用Microsoft Windows Server 2003 Enterprise x32 Edition中文版。
Windows 2003 Server执行效率高、安全性高、系统稳定，和数据库结合紧密，为多用户环境和Web系统提供了强大的优化支持。
而且Windows系统的用户接受程度较好，操作简易，可以大大降低服务器维护的费用。

数据库服务器操作系统推荐使用Microsoft Windows Server 2003 Enterprise x64 Edition中文版。
能够保证发挥硬件作用，执行效率高、安全性高、系统稳定，和数据库结合紧密，为多用客户环境和Web系统提供了强大的优化支持。
并且Windows系统的用户接受程度较好，操作简易，TCO成本较低。

（6）数据库选择

根据选型原则，数据库需要考虑以下方面：

平台支持：对多种平台的支持能大大扩展数据库的应用范围。

管理海量数据：管理海量数据需要大量的工作，也是对数据库性能的挑战。

并发处理：OLTP系统的大量并发用户会加重任何计算机系统的负荷，甚至使系统瘫痪。
因此DBMS应安全管理大量并发用户对同一资源的操作，有效均衡计算机资源，使大量并发用户可以快速的进行工作。

并行处理：支持各种不同的多处理器计算机体系结构，如共享内存、共享磁盘以及不共享的多处理器配置。
对并行处理的支持能充分利用多处理器计算机系统的并行处理和高可用性能力。

安全性：保证合法用户合法的使用分配其资源；提供各种保护数据库信息措施，可恢复从简单的电源故障到灾难性的场地损毁引起的信息丢失。

开放性：在异构的数据库环境中,支持标准化查询多种数据源,甚至可统一访问调用各数据库存储过程和外部过程。

对多种操作系统、机型的支持决定了数据库的应用范围。
能满足不同企业环境的需要。

对XML支持：我们网络技术基于Web Service，要求数据库对XML标准有很好的支持。

丰富好用的工具：提供性能调试工具，网络管理工具，开发工具，备份与恢复工具，发布工具，名字服务工具，DBMS管理工具等可高效方便运用数据库。

依据以上考虑，我们决定系统选择Microsoft公司的SQL SERVER数据库系统。
SQL SERVER数据库系统是Microsoft公司的拳头数据库产品，是世界上知名的大型数据库之一，也是一种最主流的关系型数据库。
SQL Server 数据平台是一个全面的、集成的、端到端的数据解决方案，它为组织中的用户提供了一个更安全可靠和更高效的平台

用于企业数据和 BI 应用。
SQL Server数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能，使得可以构建和管理用于业务的高可用和高性能的数据应用程序。
SQL SERVER获得Microsoft公司的全面技术支持，足以解决目前绝大多数的大型企业应用。
同时由于 SQL Server 是 Windows Server System 的一部分，通过 Windows Server System 产品中实现的通用工程策略可增强管理性和集成性，从而降低总拥有成本，加快开发速度，为客户提供更多额外收益，能

够有效降低TCO（总体拥有成本）。

数据库选择Microsoft SQL Server 2005 x64（SP2）中文标准版。
SQL Server DBMS技术成熟，性能稳定，和Windows系统结构紧密，能够有效降低TCO。
其应用程度和数据承载量足以满足资金系统目前和将来的应用。

（7）开发平台选择

基于操作系统选择Microsoft Windows，数据库系统选择Microsoft SQL Server，在此平台上最适合的企业级开发平台是Microsoft .Net Framework。
.NET开发平台是Microsoft公司首推的开发平台，技术先进稳定，与Windows平台、SQL Server数据库结合紧密，效率高。
在企业级应用（性能、安全、多层）方面具有完整成熟的解决方案，非常适合开发网络应用。

采用Microsoft Visual Studio 2008 IDE 进行基于.NET3.5的开发，符合本系统开发技术规格要求。

系统接口设计

系统通过接口与多个子系统相互通讯。
接口是基于通用的WebService方式来设计的，并使用通用的XML作为与系统之间交换数据的标准。
允许异构系统通过WebService访问共享信息。

计划步骤列表及说明：

3.2 质量保证措施3.2.1 软件开发各阶段需要提交的文档

系统在开发各阶段编写以下文档：

项目开发计划，在项目确定阶段产生初步项目计划，在需求分析阶段最终完成。

需求说明书，在需求分析阶段产生。

设计说明书，在概要设计阶段产生。

详细设计相关文档，在详细设计阶段完成。

用户手册，在需求分析阶段形成初稿，在以后各阶段逐步修改完善，在确认测试后最终完成。

测试计划：单元测试计划，在编程实现阶段产生；集成测试计划，在概要设计阶段产生；确认测试计划，在需求分析阶段形成初步确认测试计划，在概要设计阶段完成。

测试报告，在相应的测试阶段完成。

项目开发结束报告，在软件验收阶段完成。

数据需求说明书，在需求分析阶段产生。

数据库、数据结构说明书，在概要设计阶段产生。

以上软件开发文档，每个文档自成体系。

本项目严格按照ISO9001的质量管理体系实施，并参照CMMI3的要求进行过程活动管理。
项目开发过程中，项目组主要开展以下方面的活动：

目的：项目组与客户就应由软件项目实现的客户需求达成共识。

活动：评审软件需求。

软件工程组以评审通过的软件需求作为软件计划、工作产品和开发活动的基础。

目的：为开展软件开发与管理活动制订合理的计划。

活动：

◆ 软件工程组参与项目计划工作。

◆ 在早期进行软件项目计划的制订工作。

◆ 在项目开发过程中，软件工程组会和其它受影响的组一起参与项目计划工作。

◆ 高级管理人员对软件项目的对外承诺进行评审。

◆ 项目计划文档化。

◆ 明确作为项目控制、管理对象的软件工作产品。

◆ 对软件工作产品的规模进行估算。

◆ 对项目的工作量及成本规模进行估算

◆ 对项目所需的关键计算机资源进行估算。

◆ 对项目的进度进行估算。

◆ 对项目在成本、资源、进度、技术方面的风险进行识别、评估，并整理成文档。

◆ 对项目所需的开发设备及工具进行计划。

◆ 记录用于软件计划的数据。

目的：使管理层充分了解项目的实际进展，以便在项目实际工作结果严重偏离软件开发计划时，使管理层能采取有效的行动，在计划所定义的里程碑点处，积极向客户通报项目进度。

活动：

◆ 用文档化的项目开发计划进行项目跟踪和项目状态交流。

◆ 修订项目开发计划。

◆ 高级管理人员对软件项目的对外承诺及其变化进行评审。

◆ 项目对外承诺的变更经批准后，通知项目开发组成员及相关小组。

◆ 对项目的规模进行跟踪，并在必要时采取纠正措施。

◆ 对项目的工作量及成本进行跟踪，并在必要时采取纠正措施。

◆ 对项目的关键计算机资源进行跟踪，并在必要时采取纠正措施。

◆ 对项目的进度进行跟踪，并在必要时采取纠正措施。

◆ 对项目的开发技术工作进行跟踪，并在必要时采取纠正措施。

◆ 对项目在成本、资源、进度、技术方面的风险进行跟踪。

◆ 对实际度量数据和重新制订计划所用的数据都进行记录。

◆ 项目组内部通过定期进行评审来跟踪项目的工作进展、结果和存在的问题。

◆ 根据项目开发计划，在选定的项目里程碑处对项目工作成绩及结果进行正式评审。

目的：向管理人员提供适当的对软件项目正在使用的过程和正在构造产品的可视性。

活动：

◆ 制订SQA（软件质量保证） 计划。

◆ 按照SQA 计划进行SQA活动。

◆ SQA 组参与准备和评审项目的软件开发计划、标准和规程。

◆ SQA 组评审软件工程活动以验证符合性。

◆ SQA 组审计指定的软件工作产品以验证符合性。

◆ SQA 组定期向软件工程组报告其活动的结果。

◆ 按照SQA计划对在软件活动和软件工作产品中识别出的不符合性问题建立文档并加以处理。

◆ 当合适时，SQA 组与顾客的SQA 人员一起对它的活动和发现进行定期评审。

目的：在确定软件项目的开发过程时，将软件工程活动与管理活动有效地集成在一起。

活动：

◆ 剪裁组织的标准软件过程，得到项目定义的软件过程。

◆ 对项目定义的软件过程进行修订。

◆ 制订和修订项目开发计划（该计划描述了项目定义的软件过程的使用方法）。

◆ 根据项目定义的软件过程对软件项目进行管理。

◆ 使用组织的软件过程数据库进行项目计划和估算工作。

◆ 对软件工作产品的规模（或软件工作产品的变更规模）进行管理。

◆ 对项目的软件工作量和成本进行管理。

◆ 对项目的关键计算机资源进行管理。

◆ 对项目的进度（关键依赖关系和路径）进行管理。

◆ 对项目的风险进行识别、评估、文档化和管理。

◆ 为了确保项目的工作结果与商业目标、客户和最终用户的要求保持一致，对项目进行定期的评审。

目的：严格执行一个集成了所有软件工程活动的、经过明确定义的工程过程，高效地生产出合格的产品。

活动：

◆ 在项目定义的软件过程中集成适用的软件工程方法与工具。

◆ 根据项目定义的软件过程，开展软件需求活动，对其结果进行维护和文档化。
通过对分配需求的系统分析，对软件需求进行验证。

◆ 根据项目定义的软件过程，开展软件设计工作，对其结果进行维护、文档化，验证其与软件需求的符合性，形成代码框架。

◆ 根据项目定义的软件过程开展软件编码工作，对其结果进行维护、文档化和验证，实现软件需求和软件设计。

◆ 根据项目定义的软件过程开展软件（单元）测试工作。

◆ 根据项目定义的软件过程计划和实施集成测试。

◆ 通过计划和开展系统和验收测试来证实软件满足其需求。

◆ 根据项目定义的软件过程编制用于软件操作和维护的文档。

◆ 根据项目定义的软件过程对同行评审和测试中发现的缺陷进行收集和分析。

◆ 维护项目开发计划、开发过程描述、分配的需求、软件需求、软件设计、代码、测试计划、测试程序等文档间的一致性。

目的：在组织内建立起合理的项目管理工作机制，保证项目开发目标的实现，使项目的工作结果更加符合用户的要求。

活动：

◆ 在适当的时候软件工程组和受影响的组与最终用户一起建立系统需求。

◆ 软件工程组的代表和其他工程组的代表一起监督和协调技术活动，解决技术问题。

◆ 根据项目开发计划对组间约定进行交流，并对工作开展情况进行协调和跟踪。

◆ 根据项目开发计划识别、协调和跟踪各工程组间的关键依赖关系。

◆ 作为其他工程活动的输入项的工作产品要由接收方的代表进行评审，以确保其满足接收方的工作需求

◆ 根据问题解决计划，对在项目工程组代表间无法解决的组间问题进行处理。

◆ 项目各个工程组的代表进行定期的技术评审和交流。

目的：尽早地消除软件产品中的缺陷。

活动：

◆ 计划同行评审工作，并将计划写成文档。

◆ 根据评审计划进行同行评审。

◆ 记录有关同行评审的执行情况和结果。

目的：发展个人的技能与知识，使他们更好地履行自己的工作职责。

活动：

◆ 制订和维护项目培训计划。

◆ 依据项目培训计划开展相应的培训活动。

◆ 维护培训记录。

项目开发过程中，要求采用RUP作为项目软件开发过程，选用迭代化的开发方式进行项目开发。

本项目的开发将采用基于里程碑的生命周期模型，整个开发过程将设定四个阶段（如图）：初始阶段、细化阶段、构造阶段和交付阶段。
每个阶段结束于一个主要的里程碑。
在每个阶段的结尾将执行一次评估以确定这个阶段的目标是否已经满足。
如果评估结果令人满意的话，可以允许项目进入下一个阶段。

初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。
为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。
本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。
对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。
初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。
生命周期目标里程碑评价项目基本的生存能力。

细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。
同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。
细化阶段结束时第二个重要的里程碑：生命周期结构里程碑。
生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。
此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

构造阶段

在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。
构建阶段结束时是第三个重要的里程碑：初始功能里程碑。
初始功能里程碑决定了产品是否可以在测试环境中进行部署。
此刻，要确定软件、环境、用户是否可以开始系统的运作。
此时的产品版本也常被称为“beta”版。

交付阶段

交付阶段的重点是确保软件对最终用户是可用的。
交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。
在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
在交付阶段的终点是第四个里程碑：产品发布里程碑。
此时，要确定目标是否实现，是否应该开始另一个开发周期。
在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

在每个阶段我们将根据阶段目标进一步分解为迭代。
在每个迭代完成一个完整的开发循环，产生一个可执行的产品版本，作为最终产品的一个子集，通过增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。

传统上的瀑布生命周期会出现到了实现末期产品完成才开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期等问题。
因此项目组将采用迭代化的开发方式来避免这些情况的出现。

迭代是一种更灵活，风险更小的方法，是多次通过不同的开发活动（需求分析、设计、编码、测试等），通过更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。
软件生命周期是迭代的连续，通过它，软件进行增量的开发。
一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。
因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。
其本身就像一个小型的瀑布项目（如图）。

3.3.3 迭代过程与传统的瀑布模型相比较

加快了整个开发工作的进度。
因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的。
因此，迭代过程这种模式使适应需求的变化会更容易些。

迭代式开发方法是一个不断降低风险的过程，每一次迭代过程都选择风险最大的任务执行。
因此风险在迭代过程中不断地被发现、被消灭。

迭代式开发方法能够更容易地管理需求的变化，整个开发过程由一次次的独立迭代组成，项目经理能够比较容易地调整迭代过程，使最终产品满足变化的需求。
开发人员以及项目相关人员能够及时地从迭代过程中得到反馈信息，并能够及时修改以前工作中的失误，有效地监控开发过程，并对迭代工作流进行校正，这对一个时间跨度很长的项目具有重要的意义。

公司遵循ISO9001质量管理体系，按照CMMI3对质量管理环节的过程活动要求，对本项目，我们将从以下三个方面进行质量控制:

在本系统的开发过程中，要求对软件系统做以下二个层面的测试：

单元测试

单元测试将对最小的可测试软件元素（单元）实施的测试。
它所测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。
确保及时发现并改正编码缺陷。

集成测试

集成测试是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。
它所测试的内容包括单元间的接口以及集成后的功能、性能。
（因本期开发的软件只针对个别部门，因此不用执行系统测试）

评审是一种保证项目质量的重要手段，在本项目中，项目组将对所有开发出来的文档、模型、代码等进行评审，及早发现并修复缺陷，以起到保证系统的质量的作用。
在该项工作中，主要开展以下几项活动：

◆ 编制评审计划；

◆ 准备检查表；

◆ 召开评审会议，评审人员根据检查表对开发出来的文档、模型、代码等进行评审，发现并记录缺陷；

◆ 项目成员根据计划修复缺陷。

在本项目中，我公司将派出专业SQA人员对项目的开发活动和开发结果进行审计，以确保项目是按照规定的开发过程进行的，确保项目的开发结果满足质量要求。
在该项活动中主要开展以下几项工作：

◆ 编制项目的SQA计划；

◆ 准备检查表；

◆ 根据SQA计划对项目进行审计；

编制审计报告；

对审计中的不符合性问题进行解决和追踪。

东方电机机组服务系统是东方电机有限公司管理内部资料以及客户的相关信息的管理，涉及到部分商业保密信息，对数据及系统安全的要求很高。
我们的系统设计将从以下方面考虑和保障系统安全性：

系统提供多层安全保护措施，确保在以下情况下系统能够正常运行：

系统通过互联网提供公众服务和部分业务数据的收集、发布工作，要求系统提供多种防火墙措施，能够抵御来自互联网的网络攻击和入侵；

系统通过局域网提供内部业务，要求系统提供多种防火墙措施，能够防止来自内部的网络入侵；

系统提供独立的内网（业务）和外网服务器，防止通过外网入侵和窃取内网数据的可能；

系统提供独立的数据服务器，保障数据的安全，防止通过网络入侵业务服务器后窃取数据的可能。

系统的权限管理提供以下措施或特性：

独立的权限服务。
采用集中式的、独立的权限服务体系，权限业务不能简单的直接嵌入到普通业务中，避免业务服务器被窃取、权限被盗窃的情况；

多种用户权限验证措施。
不对外提供注册功能，用户是由系统提供的帐号，可采用加密锁等方式进行验证；对管理机构内部用户，采用权限账号方式进行验证。

权限管理要求可配置，可扩展。
不能固定死、缺乏扩展性。

对在线用户进行管理，为单点登录奠定基础。

因为涉及到关键的资金数据，系统对数据安全的要求很高。
设计并保证系统在如下情况时能保障数据的安全：

假设存在通过互联网的外部入侵业务服务器时，能够保证数据不透明（而无法被窃取）；

假设存在通过内部网络入侵业务服务器时，能够保证数据不透明（而无法被窃取）；

假设存在某个内部账号被窃取时，能够保证该账号权限外的所有数据都无法访问，并且该账号的所有操作会被记录；

（1）系统运行

系统硬件设计保持724小时能够稳定可靠的运行不间断。

（2）出错处理

系统自身的运算错误、操作失败，产生正确的提示信息，并且提供重试、实时解决，不会影响其它操作。
即部分的、偶尔错误不会影响整体的运行。

当出现以下故障时：1、网络故障；2、操作系统崩溃；3、硬件系统故障等不可预估的情况，系统不会发生无法逆转的灾难性破坏。
要求软硬件故障在24小时之内恢复，数据库服务器故障能即时切换备份服务器。

（3）数据备份措施

1、提供数据库备份工具。
支持后台运行，定期备份；

2、提供数据库还原工具，在确认数据丢失后，可以通过该工具及备份数据还原到备份前的状态。

测试各阶段主要测试内容如下：

模块测试：各功能是否满足程序模块说明书要求，以及输入、输出的正确性。

系统集成测试：检测模块间的接口以及集成后的功能的正确性。

系统测试：对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

性能测试：对系统进行负载、压力、并发、可靠性测试，确保系统资源使用情况、系统并发用户数、系统在线用户满足产品需求。

安装或部署测试：安装或部署系统，确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。

上线前试运行：在正式上线前发布一个版本，让用户在真实环境中试用，通过此测试来了解用户的操作习惯、行为模式，分析产品与用户之间的和谐程度。

根据系统的特点把系统的测试类型分为功能测试、兼容性测试、性能测试，各自的测试目标和标准如下：

目标：根据功能测试用例，对产品的各功能进行逐项测试，以确保产品达到用户要求。

标准：

A．功能测试：测试各个模块以及界面所完成的功能是否正确，数据是否正确，操作是否简洁方便。

B．业务流程测试：按照需求规格说明书的业务流程，检查系统所有业务流程是否正确。

C. 数据测试：（1）输入正确数据是否能按照预期的结果输出；（2）能否识别错误的输入，并给予正确的信息提示信息。

D．数据流测试：本系统所涉及的相关数据，是否按照正确的业务流程流动，每个阶段所输出的数据结果是否正确。

E．界面测试：界面信息描述准确，操作方便,以需求分析或设计文档UI部分为标准。

目标：检测待测试项目在不同操作系统平台、同一操作系统平台不同浏览器上，能否正常运行，本次测试主要针对常用的操作系统和常用的浏览器进行测试。

标准：

A. 验证本软件在IE8+等浏览器下的运行情况。

B. 验证本软件在windows XP 、WIN7等操作平台下的运行情况。

目标：检查系统的平均响应时间或者吞吐量是否符合指定的标准，在线用户数是否达客户到要求。

标准：

A负载测试：在给定的测试环境下，通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已达到饱和状态，目的是了解系统性能容量和处理能力极限。

B压力测试：测试系统在一定饱和状态下系统能够处理的会话能力，以及是否出现错误。

C.并发测试：模拟并发访问，测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。

各阶段的测试策略如下：

模块测试：手工方式进行功能测试、边界测试。

集成测试：采用自顶向下和基于功能方式集成；用手工和工具相结合的方式进行功能测试、边界测试、异常测试、业务测试等。

系统测试：用手工和工具相结合的方式进行功能测试、GUI测试、文档测试、在线帮助测试、兼容性测试等。

性能测试：用工具和手工相结合的方式进行性能测试（负载测试、压力测试、并发测试、可靠测试）。

安装或部署测试：用手工方式按照软件产品安装手册或相应的文档，在一个和用户使用该产品一样的环境中或用户环境中，进行安装测试。

上线前试运行：测试人员或开发人员坐在用户旁边观察用户的使用过程，并通过与用户交谈深入的了解用户的想法、行为、操作习惯等。

对照合同或系统需求，在系统上查看和维护相关信息、按照业务流程做模拟，检查相关功能是否实现，业务流程是否正确。

4.3.3 验收实施步骤

（1）验收前的准备

在产品验收之前，管理部门、开发部门根据合同中的验收准则、验收内容、交付要求完成所有交互件，并检查所有软件项是否完整。

（2）验收环境搭建

据合同的要求或双方协商的结果，确定验收测试的环境（用户环境或用户认可的环境），然后按建立相应的硬件环境、软件环境等。

（3）验收测试

根据合同或客户要求，验收测试可以是现场测试或在客户认可的环境下进行，验收测试尽量由客户实施，开发部门给予协助。
验收过程以合同规定为依据，所有与规定不一致的地方，均认为存在问题，由双方确认问题的类型，并记录在“验收测试报告”中。

（4）验收测试结果分析

对验收测试过程中记录的问题，进行逐个分析，根据分析结果决定验收是否通过和对本次验收测试进行评价。

（5）验收测试报告

根据测试结果编制验收测试报告，并提交给客户。

（6）交付

甲乙双方就合同中规定的交付件进行交付，并在验收单上签字，完成验收。

（1）二十四小时技术支持

如果在服务期间对本估算系统有任何疑问，可以在36524小时内拨打我们的全天服务热线，我们将及时地为您解答，并且将获得终身免费的技术支持及系统升级服务。

（2）电话跟踪式服务

在系统建设完成之后，我们将在一个月内回访两次，调查客户对现有网站的需求，是否有相关疑问，如有疑问我们根据情况上门解答及传授。

（3）登门式跟踪服务

在系统建设完成之后，我们公司将两个月登门拜访一次，传授如何管理系统能提高效果，没有效果当场找原因，对客户的疑问及时解答等。

（4）专业性操作辅助服务

在系统建设完成之后，如客户在操作系统中有较为专业的技术难题，我们辅助客户进行操作并完成。

（5）远程维护

系统部署完成后，由于服务器将部署在甲方的内部，对外使用防火墙以保障系统的安全性，对于紧急问题，我公司售后服务人员可与系统维护人员协调采用远程操作方式进行系统维护。

（6）系统速度提升服务

在系统建设完成之后，客户在维护期内对系统速度有任何质疑，我们将为客户解答，进行系统速度的提升。

（7）服务投诉

如对我们工作人员服务有疑问或不满意，方可拨打我们的投诉电话进行投诉，帮助我们提高我们的服务质量。

系统建设完毕后,在用户不改变模板及程序的情况下,我们将对所开发的系统进行一年免费更新、维护、修改服务。

在软件的生命周期中，公司严格近照ISO9001的标准来执行，在项目经理的领导下，由项目负责人向公司负责，展开项目的开发。
在项目实施之前制订整体研发计划，确立硬件、软件及人力资源，制定风险计划以规避项目在开发过程中可能出现的问题,项目开发完成后严格按照测试计划进行测试，并经试运行后才能正式结项。

根据制订的需求开发计划严格、周密执行调研计划，产生的需求文档必须经用户签字确认，以保证开发与需求的一致性；

在设计阶段，根据我公司现有的设计要求严格、翔实地设计系统、数据、接口，对于多种解决方案必须经过公司高层的决策分析，产生的设计文档必须经过公司专家的评审通过；

在编码阶段，程序员在项目负责人的指导下完成项目编码过程，严格执行公司规定的编码规范、遵守项目组制定的开发准则及事项、定期进行代码评审以保证编码质量；项目分阶段向用户演示，以收集用户问题；

测试人员按照制定的测试计划对项目开展功能测试、集成测试、系统测试和发版测试，并向项目经理提交测试总结报告；

测试完成后，系统上线试运行，项目组跟踪系统运行情况，及时解决出现的问题，试运行完成后交付客户，公司内部结项。

公司在系统完成并上线试运行后，培训东方电机有限公司选出的系统相关的操作人员。

在系统试运行之前集中培训系统相关的操作人员，达到熟练使用系统；

甲方确定

数字化环卫管理系统的操作及功能设置

我公司除了试运行之前的系统全面培训外，如果发现在实际运行中出现了比较典型的问题时，可在甲方内部进行现场培训。