可行性研究报告云泊车管理系统.docx

1、可行性研究报告云泊车管理系统1引言 11.1编写目的 11.2背景 11.3参考资料 22可行性研究的前提 22.1要求 22.2目标 52.3条件、假定和限制 62.4评价尺度 73对现有系统的分析 73.1处理流程 73.2工作负荷 83.3费用开支 83.4人员 83.5设备 83.6局限性 84所建议的系统 84.1对所建议系统的说明 84.2业务流程 94.3局限性 114.4技术条件方面的可行性 115投资及效益分析 115.1支出 115.1.1基本建设投资 115.1.2其他一次性支出 125.1.3非一次性支出 125.2收益 125.2.1一次性收益 135.2.2非一次性

2、收益 135.2.3不可定量的收益 135.3收益投资比 135.4投资回收周期 135.5敏感性分析 136社会因素方面的可行性 136.1法律方面的可行性 136.2使用方面的可行性 147结论 14GB856788可行性研究报告1引言1.1编写目的可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内确定问题是否可解。 经过对此项目进行详细调查研究，初步拟定系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。明确开发风险及其所带来的经济效益。本报告经审核后，交付项目经理孟宇龙审查。1.2背景说明：A. 软件系统的名称：云泊车管理系统B. 任务提出者：项目

3、经理孟宇龙开发者：第十四小组用户：停车场管理员、停车场相关工作人员及车主C. 实现该软件的计算中心或计算机网络：服务器端： 操作系统：Centos 6.5数据库：MYSQL 5.5 JDK：JDK 1.7及以上 J2EE框架：SpringMVC + Spring + MyBatis客户Web端： 操作系统：Windows、Linux或Mac OS 浏览器：Chrome 43及以上、FireFox 5.0及以上网络：稳定的网络接入，稳定2M及以上网络传输速率客户移动端： 操作系统：Android 5.0及以上或ios 7及以上 网络：3G、4G或Wi-Fi移动网络D. 该软件系统同其他系统或其他

4、机构的基本的相互来往关系： 开发环境：操作系统：OSX 10.11 集成开发工具：Eclipse 编译环境：JDK 1.8 Web服务器：Tomcat 8.0 同合作的停车场或具有停车位的机构之间呈合作关系1.3参考资料1 张海藩主编，软件工程导论，清华大学出版社2 陆丽娜主编，软件工程，经济科学出版社3 瞿中主编，软件工程，机械工业出版社2可行性研究的前提说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。2.1要求说明对所建议开发的软件的基本要求，如：A. 功能：城市停车场库ETC：只要设置好电子钥匙，进出道闸时该系统会自动识别车牌并放行，过程快捷，无需停车。关联车主：

5、基于车牌关联车主信息，自动记录车辆的出入时间，形成实时精确、可视化的停车信息，提供停车收费、车证管理、电子支付、VIP 服务等专业化停车管理服务。车位分享：用户在系统内分享闲置车位，有需求的车主则可预定车位泊车，大大增加闲置车位使用率，节约资源的同时还助力缓解了停车难。车位预定：帮助用户提前预定目的地车位，避免到了目的地无车位可停的尴尬现象。泊车诱导：为用户导航至目的地，助用户顺利找到自己预定的车位，避免迷路。会客分享：用户亲友前来拜访时，用户使用会客分享，为亲友车牌授权，小区道闸自动为该车牌号的车主放行。B. 性能：本产品应用于停车场，在使用中可能会遇到高峰期排队车辆过多的情况，所以要求图像

6、处理模块及通信模块的速度要快。我们规定的从车辆进入提取照片到数据库完成保存共20秒时间。C. 输出：获取该输入的记录中保存的系统时间，同时获得此时的系统时间，将这两时间作差交给计费模块。计费模块执行完毕后将最终的停车费用返回给客户。D. 输入：通过浏览器客户端（可通过在界面上添加按钮），获得摄像头拍摄的车牌图片，再通过浏览器客户端与服务器间的交互将图片传输给服务器端的图像处理模块进行处理，并在处理之后将车牌字符串发送回客户端显示、同时将车牌字符串存储到服务器的数据库中。在存入车牌信息的同时采集系统时间，与车牌字符串一并存入服务器数据库中。E. 处理流程：本系统主要的流程可以分成六部分：用户管理

7、、停车场管理、车位管理、停车管理、统计管理、可视化管理。一、用户管理 1、用户注册：提供用户注册，主要分为停车场管理者的注册和普通百姓的注册。2、用户登录：通过账户密码及验证码来组合判断用户身份。3、角色管理：通过用户信息的权限标记位在运行期判断角色类别信息。4、用户信息查询：用户可进行自己身份信息状态的查询。二、停车场管理1、停车场注册：停车场管理者进行停车场的注册。2、停车场查询：系统管理员进行停车场状态的查询。3、停车场信息修改：系统管理员根据实际需求进行停车场信息的修改。三、车位管理： 1、车位添加：停车场管理员进行本车场车位信息的添加。2、车位修改：停车场管理员进行本车场车位信息的修

8、改。3、车位删除：停车场管理员进行本车场车位信息的删除。四、停车管理：1、车辆入库：停车场管理员对车辆入库进行登记。2、车辆状态查询：用户对自己的车辆实时停车状态进行查询。3、车辆出库：停车场管理员对车辆进行出库操作。4、费用结算：停车场管理员对车辆停车进行费用计算。五、统计管理：1、车辆泊车分布统计：进行城市泊车热点停车场分布统计。2、具体车辆泊车统计：进行特定车辆泊车分布统计。六、可视化管理：1、城市实时泊车可视化：城市实时热点区域可视化。2、指定车辆状况可视化：具体车辆状况可视化功能划分图：F. 在安全与保密方面的要求：1. 统一管理：为了简化数据管理的复杂性，将分散的数据统一集中存放。

9、2. 在数据进行存储时，应采用加密后存储，以保证数据的机密性、完整性、可靠性。防止系统信息泄露。3. 系统应在一段时间内就提供数据库全备份管理，以保证在数据出错或被破坏时能够恢复。4. 对于系统执行的重要操作自动记录日志。G. 同本系统相连接的其他系统：支付系统，移车系统，车位交易系统，社交系统H. 完成期限：7个月左右2.2目标总体目标：本项目采用目前热门的云体系。旨在将目前国内分立的泊车管理进行集群化。目前国内的很多停车场依旧采用传统的咪表、蓝牙停车管理系统，同时一个城市内部的停车场都是分立管理的。这种分立的停车管理不但麻烦，而且需要泊车场管理者付出很多的管理及维护经历。提出这一云平台体系

10、主要是为了使目前的停车场集群化，对停车场进行统一管理调度，从而能够更加充分的进行停车场资源的调度；为用户设置客户端软件，使其可以通过客户端软件实时获取服务器中停车场的信息，从而判断将要前往的停车场，提前预约锁定车位，有效的解决局部停车场资源短缺的问题。系统目标：（1） 提供给停车场管理者一套完整的解决方案，使得其能够通过友好的用户交互进行停车场的日常管理。（2） 通过云体系架构提供一个区域内停车场的集群化管理，在泊车高峰期能够提供有效的车辆调度。（3） 提供android客户端给客户，使其能够随时了解自己的停车信息与其他情况，使得客户有一个直观的理解，更好的掌握实时情况。2.3条件、假定和限制

11、说明对这项开发中给出的条件、假定和所受到的限制，如：a 建议系统的运行寿命的最小值：5年b 经费、投资方面的来源和限制：投资方与合作方c 硬件：服务器端： CPU：双核及以上内存：4GB及以上硬盘：512GB及以上客户端： CPU：单核及以上内存：2GB及以上硬盘：128GB及以上 运行环境：操作系统：Windows 7浏览器：Internet Explorer 8浏览器及更新、Chrome浏览器开发环境：操作系统：OSX 10.11集成开发工具：Eclipse编译环境：JDK 1.8Web服务器：Tomcat 8.0d 系统投入使用的最晚时间：2018/052.4评价尺度开发费用较小；各项功

12、能的优先次序分明；开发时间的长短适中；使用难度较低，易于上手操作。3对现有系统的分析这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚 至是一个人工系统。分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。3.1处理流程3.2工作负荷 维护，值班，收费，计时3.3费用开支人力 3万设备 6万空间 20万支持性服务 2万材料等项开支 8万开支总额 39万3.4人员维护人员 3名；值班收费人员 3名；3.5设备 闸机，闸杆，值班室，摄像头，取卡机等3.6局限性分立化，工作低效，管理难度大4所建议的系统本章将用来说明所建议系统的目标和要求将

13、如何被满足。4.1对所建议系统的说明本项目采用目前热门的云计算体系。目前国内的很多停车场依旧采用传统的咪表、蓝牙停车管理系统，而且目前一个城市内部的停车场都是分立化的。我提出这一云平台体系主要是为了使目前的停车场集群化。统一管理调度，从而能够更加充分的进行停车场资源的调度。防止出现某部分停车场不够用而另部分过于冗余的情况的发生。 在设计方面，本系统的服务器端采用Apache Tomcat服务器windows操作系统。数据库软件采用MySQL数据库。服务器端采用MVC模式进行设计。前端界面采用jsp开发技术，通过中间层使后端与前端界面进行连接。通过编写具有JavaBean标准的类来存储数据模型，

14、并通过JSP与Servlet技术进行前后端的交互。 本项目周期较短，开发人员较少，所以未制定统一编码标准，故编码标准按照个人习惯进行。本项目开发分为四个阶段：第一阶段为服务器端开发，第二阶段为图像识别算法开发，第三阶段为web应用开发。第四阶段为android客户端开发。4.2业务流程4.3局限性 人员技术不足，合作方合作事宜未确定，资金未到位4.4技术条件方面的可行性说明技术条件方面的可行性：a 在当前的限制条件下，若资金足够，且合作方已经签订合同，该系统的功能目标能达到；b 利用现有的技术，该系统的功能能实现；c 开发人员的数量要求3名，要求对项目所需技术做到熟练掌握的程度，该要求暂不能满

15、足；d 在规定的期限内，技术人员到位，本系统的开发能完成。5投资及效益分析 5.1支出对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继续运行期间所需的费用。5.1.1基本建设投资包括采购、开发和安装下列各项所需的费用，如：a. 房屋和设施 30万b. ADP设备 5万c. 数据通讯设备 1万d. 环境保护设备 1万e. 安全与保密设备 1万f. ADP操作系统的和应用的软件 30万g. 数据库管理软件 20万共计 88万5.1.2其他一次性支出包括下列各项所需的费用，如：a 研究（需求的研究和设计的研究） 20万b 开发计划与测量基准的研究 5万c 数据库的建立 50万

16、d ADP软件的转换 5万e 检查费用和技术管理性费用 5万f 培训费、旅差费以及开发安装人员所需要的一次性支出 20万g 人员的退休及调动费用等 3万共计 108万5.1.3非一次性支出列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用，包括：a 设备的租金和维护费用 5（年）*2万=10万b 软件的租金和维护费用 5（年）*1万=5万c 数据通讯方面的租金和维护费用 5（年）*1万=5万d 人员的工资、奖金 5（年）*12万=60万e 房屋、空间的使用开支 5（年）*5万=25万f 其他经常性的支出 20万共计 125万5.2收益对于所选择的方案，说明能够带来的收益，这里所说的

17、收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括；5.2.1一次性收益 5万5.2.2非一次性收益 5（年）*330万=1650万5.2.3不可定量的收益服务的改进 增长2%组织机构给外界形象的改善 增长3%共计 1650万*1.05=1732.5万5.3收益投资比 （5+1732.5）/（88+108+125）=541.28%5.4投资回收周期 0.186年5.5敏感性分析设计系统周期为五年, 估计最长可达10年工作负荷的类型：传导，查询，计算，存储处理速度:小于4秒6社会因素方面的可行性本章用来说明对社会因素方面的可行性分析的结果，包括

18、：6.1法律方面的可行性所有软件都选用正版.所有技术资料都由提出方保管。合同制定确定违约责任明确合同责任、明确专利权和版权6.2使用方面的可行性员工方面：要求有一定计算机基础，但整体操作简便，经过培训均能正常熟练使用本系统。 用户方面：系统界面设计优美、简洁、清晰，系统交互性良好。用户初次使用经过系统提示指导后将能较好掌握本系统。7结论需要同合作方确定合同，投资方资金部分投入，技术人员技术条件成熟；待上述条件基本落实后可开始进行项目。目 录1 需求分析 - 3 -1.1 基本功能要求 - 3 -1.2 创新拓展功能 - 3 -1.3 设计原理 - 3 -1.4 实验原理图 - 4 -2 系统设计 - 5 -2.1 系统逻辑结构设计 - 5 -2.2 系统物理结构设计 - 12 -3 系统实现 - 18 -3.1 系统实现过程 - 18 -3.2 系统测试 - 20 -3.3 系统最终电路图 - 23 -3.4系统团队分工 - 23 -4 总结 - 25 -5 引脚图附录 - 26 -