《网上订餐系统可行性分析报告》由会员分享，可在线阅读，更多相关《网上订餐系统可行性分析报告（17页珍藏版）》请在金锄头文库上搜索。
1、网上订餐系统可行性分析报告院系：信息与控制学院专业：计算机科学与技术班级学号：1班学生姓名：小组成员：杨文鑫（组长）祁玉爱、窦超男指导教师：成 绩：2019 年 4 月 9 日目录1 引言 1编写目的 1 背景 1软件定义 2参考资料 22 可行性研究的前提 3 要求 3目标 3用户特点 33 对现有系统的分析 4 技术可行性 4 操作可行性 4 处理流程和数据流程 4 费用开支 7 设备 7局限性 814144 所建议技术可行性分析 9 对系统的简要描述 9 处理流程和数据流程 9 与现有系统比较的唯一优越性 采用建议系统可能带来的影响5 投资及效益分析 16支出 16收益 166 社会因素
2、方面的可行性 17 法律因素 17 用户使用可行性 177 其他可供选择的方案 188 结论 191 引言编写目的现在电子商务随着经济的快速发展受到越来越多的关注，以前的购物型网站，现 在的订餐类网站等等，都在各大城市相继出现。尤其是对于现在在社会上占主要 群体的一些大学生和白领，由于生活和学习越来越忙碌，加上对饮食的要求不断 提高，不出门就可以在家订餐的软件，同时方便客户和商家，两全其美。在中国的大学生高校中学生到食堂用餐，在路途和排队上会浪费很多时间，去晚 了还会不到自己想吃的食物，这样会导致学生对食堂的高度不满，网上订餐系统 会帮助商户充分了解学生需求，并且减少学生外出的几率和排队上浪费
3、时间。 网上订餐管理系统无论是在应用的深度还是广度都是逐步发展的过程。在开发一 个局部系统时要充分考虑到局部系统和整个目标系统的相容性和完整性，以利于 今后整个系统的建设。基于上述需求，我们小组策划了网上订餐系统的网站。背景越来越多的大学生、白领希望能够在网络平台上更多的了解到美食方面的信息， 并可以方便的购买。迅猛发展并日益成熟的互联网已经影响到我们生活的方方面 面，人们真切的体会到了网络给大家带来的便捷，互联网也以其独有的优势快速 的渗透到越来越多的领域。网络订餐随着互联网的成长会逐渐被人们所喜爱，正 如几年前手机移动的短信一样，在互联网世界里谁早一步在应用上创新，谁就掌 握了未来的方向，
4、谁便把握机遇，成为时代的先驱，成功的缔造者。我觉得网上 订餐服务的直观、有效、便捷等优点是传统的电话订餐业务无法比拟的。社会是 进步的，我坚信网络订餐终将取代以上的电话订餐，它将会带给广大繁忙的工作 人群诸多的方便，节约大量的时间。目前国内美食网站的现状大致为:以大众点评为代表的社区美食网站和以饭店为代 表的餐厅网站。前者的主要形式是网友上传餐厅相关消息，网友们互动点评餐厅 形成网络口碑等，正形成了点评网信息多而复杂，流量比较大，受众友们喜爱。 后者主要以餐厅信息预定业务为主，这样的餐厅网相对比较专业，流量相对较少 受众比较固定，有很高的用户粘性。软件定义网上订餐系统是基于SSH框架的系统开发
5、，以MySQL数据库为数据核心的应用。以服务为目的的信息平台。开发环境：MyEclipse、MySQL。参考资料基于 Internet 的管理信息系统 曾凡奇等 中国财政经济出版社 2001 年 信息系统开发方法 姜旭平 清华大学出版社 1997 年第一版 软件工程方法与实践 许家珆 电子工业出版社 2011 年第一版 软件工程实用教程 周丽娟 王华 清华大学出版社 2012 年第二版2 可行性研究的前提要求本系统应遵循合理的管理方法，利用计算机技术、网络技术、数据库技术等。全 面收集和处理数据，提供各类信息，并利用现代化管理方法，建立具有多种辅助 决策功能的模块，为网上订餐项目管理提供决策支
6、持，从而提高管理水平。 该系统的实现需要具备以下要求：1. 提高信息处理速度；2. 及时发布，及时可见，确保稳定高效；3. 集中处理，提高管理水平；4. 提高辅助决策能力。目标网上订餐系统目标:1. 系统能够友好的提供用户界面，使操作人员的工作量最大限度的减少2. 系统具有良好的运行效率，能够达到提高生产率的目的。3. 系统应具有良好的可扩展性，能够容易的在其他系统运行4. 平台的设计应具有一定的超前性，灵活性、能够适应企业的生产配置5. 系统需要操作方便，易于使用，方便管理员对菜品可以进行及时的修改。用户特点本系统的用户都是网上用户，包括两类:一类是访客和用户，访客可以查看菜品以 及基本信息
7、和价格，用户可以进行购买与访问。另外一类是用户管理员，管理员 需要给店铺添加商品，也可以对本店的商品进行管理即进行修改和删除的操作， 当用户购买商品结束后，管理员可浏览订单并处理订单，最后对订单信息进行配 送。3 对现有系统的分析技术可行性网上订餐系统的开发基于 SSH 框架模型，主要包括前台应用程序的开发以及后台 数据库的建立和维护两个方面。对于前台要求应具备功能完备、易于使用等特点， 而对于后者则要求能建立数据一致性和完整性、数据安全性好的数据库。基于以 上的要求，本系统采用 MyEclipse 和 MySQL 分别作为前台和后台的开发工具。 MyEclipse 是企业级工作平台是对 Ec
8、lipseIDE 的扩展，利用它我们可以在数据库和 JavaEE 的开发、发布以及应用程序服务器的整合方面极大的提高工作效率。它是 功能丰富的 JavaEE 集成开发环境，包括了完备的编码、调试、测试和发布功能， 完整支持 HTML, Struts, JSP, CSS, Javascript, Spring, SQL, Hibernate。MySQL 则是目前比较流行的数据库管理系统。另外外，所有的 MySQL 版本都可以在 Windows 操作系统上运行。操作可行性本网上订餐系统具备友好的用户界面,使用方便,易于维护,操作简单,易于被 用户接受。用户只需要可以熟练的操作计算机,并可以熟练的购
9、买商品,即可方 便使用,而且使用此系统可以大大减少管理人员的负担,因此,从操作方面看, 此系统的开发是可行的。处理流程和数据流程网上订餐系统顶层数据流图如图所示图网上订餐系统顶层数据流图网上订餐系统餐品管理细化数据流图如图所示网上订餐系统用户细化数据流图如图所示图用户管理的细化数据流图网上订餐系统餐品管理细化数据流图如图所示灵圧户辽星 番品工作负荷内部管理 主要包括用户登录、新用户注册。 用户登录：主要是进行用户验证。 新用户注册：主要是进行新用户的加入。餐品管理 主要包括浏览、发布、描述 浏览：主要是进行查看。 发布：主要是进行餐品的增加。 描述：主要是进行对餐品的做法进行说明。费用开支技术
10、人员 6 名 开支 50000管理人员 3 名 开支 20000设备 8 台 开支 50000其他 开支 20000设备本系统的硬件环境如下：1. 客户机:普通 pcCpu： 以上内存：256MB以上 能够运行及以上 服务器：Cpu： p41GHZ内存： 1GB硬盘： 80GB 以上网卡： 80GB 以上局限性由于系统老旧，操作复杂易于出错，所以需大量的人员来管理，费用花费很大以 及运行的不稳定，需要经常更新硬件。需要大量的人员来管理，维护其数据，出 错率较高。出现很多冗余信息。设备较为老旧，不能满足本系统的基本需求，所 以经常超负荷工作，比较容易损坏。4所建议技术可行性分析对系统的简要描述大
11、致模型如下所示：图系统功能模块图无论是客户端的还是用户还是管理端的用户都可以通过网络登录到本系统中。用 户通过网络注册会员填写并查询相关信息。管理端的管理员再对会员信息进行添 加、删除和修改等。处理流程和数据流程处理流程如图所示图数据处理流程图数据字典1. 数据流名称：餐品情况位置:餐品-+,餐品+定义:餐品情况=餐品名+类别+图片+点击率+收藏量+点赞量+发布时间+发布人D+ 描述+餐品ID数据流量:平均流量为每月传输1000次，高峰期流量每天传输100次。说明:餐品发布时，根据餐品情况建立餐品记录;用户收藏处理时需检查是否有该餐 品的记录，做法及点赞量是否高。2. 数据流名称：用户情况位置
12、:用户一,用户T定义:用户情况=用户名+密码+性别+年龄+邮箱+头像+积分+用户级别+手机号+联系 地址+用户ID数据流量:平均流量为每年传输80000次，高峰期流量每天传输1000次。 说明:根据用户情况建立用户记录。3. 数据流名称： 用户身份位置：, 定义:用户身份=合法用户数据流量: -切用户只要注册成功的都可以进入4. 数据流名称：注册新用户情况位置:新用户T定义:注册新用户情况=新用户ID+新用户用户名+姓名+性别+级别+密码+电话 数据流量:平均流量为每年传输 80000 次，高峰期流量每天传输 1000 次。 说明:新用户一.旦注册成功，无需再有升级等步骤。5. 数据流名称：发
13、布请求 位置:用户一定义:发布请求=类别+餐品ID+餐品名+书写时间数据流量:平均流量为每天传输 1000 次，高峰期流量每小时传输 300 次。6. 数据流名称：餐品信息位置T 定义:餐品信息=输入餐品编号+餐品名称+类别 数据流量:平均流量为每天传输 1000 次，高峰期流量为每小时传输 250 次。 说明:查看餐品信息时，需要输入餐品编号，餐品名称和类别，以确定餐品。主要的数据存储定义1. 数据存储编号: D1 数据存储名称:餐品记录 输入: 输出: P2. 1, ，P2. 3 数据结构:餐品记录=餐品编号+类别+发布者+材料+做法+描述+书写时间+餐品名数据量和存储频度:数据量为 25
14、0000 条，存取频度为每天 1000 次。 存取方式:联机处理;检索和更新;主要是随机检索。说明:餐品编号具有唯一- 性和非空性。2. 数据存储编号: D2 数据存储名称:用户记录 输入: , P3. 1, P3. 2输出: , 数据结构:用户记录=姓名+性别+级别+昵称+密码+电话+用户编号 数据量和存取频度:数据量为 15000 条，存取频度为每天 500 次。存取方式:联机处理，主要是检索处理，以随机检索为主 说明:编号具有唯-性和非空性，性别只能是“男”或“女”。3. 数据存储编号: D3 数据存储名称:评价记录 输入: ，输出: ，数据结构:评价记录=餐品编号+餐品名+评论+用户编
15、号+用户名+收藏量+点赞 量数据量和存取频度:数据量为 50000 条，存取频度为每天 1000 次。 存取方式:联机处理，以更新操作为主，随机检索 说明:用户编号是外码，参照表为“用户编号”主要处理过程1. 处理过程编号: 处理过程名:餐品管理 输入:餐品情况，用户身份 输出: D1 处理说明:对吧内所有餐品类别统-编码，将餐品信息数据化，存储到餐品记录 表中2. 处理过程编号: 处理过程名:用户管理 输入:用户情况，用户身份 输出: D2 处理说明:建立用户信息表，对用户统编号，实现用户记录表的增刪改维护功能3. 处理过程编号: 处理过程名:发布、查看做法 输入:发布请求，D1,用户身份 输出:
