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