餐饮管理系统开发投标书.docx
- 文档编号:27898204
- 上传时间:2023-07-06
- 格式:DOCX
- 页数:28
- 大小:1.28MB
餐饮管理系统开发投标书.docx
《餐饮管理系统开发投标书.docx》由会员分享,可在线阅读,更多相关《餐饮管理系统开发投标书.docx(28页珍藏版)》请在冰豆网上搜索。
餐饮管理系统开发投标书
Documentnumber:
PBGCG-0857-BTDO-0089-PTT1998
餐饮管理系统开发投标书
餐饮管理系统开发投标书
实现部分
1项目目标
随着生活水平的提高,公司规模迅速发展。
公司在这种大潮流下也取得了不凡的业绩。
为了能够更加迅速的服务顾客,简化工作人员的一些操作,提高服务质量,服务速度和正确率。
具体目标如下:
(1)技术目标
∙建立数据库基础架构
∙建立数据自动计算机制
∙建立数据展示和数据查询框架
∙建立数据在一体机上的操作
(2)业务目标
前台业务目标
1、人性化点餐
(1)菜单查阅
(2)特色查询
(3)点菜时添加菜名,桌号,会员号。
可附加口味的特殊要求。
2、自动传菜
3、菜品录入
(1)大厅散桌菜品录入
(2)包厢菜品录入
(3)查询所点菜品的状态
(4)用餐中途加菜
4、结账管理
(1)非会员结账管理
(2)会员结账管理
5、对服务员评价
6、奖金评定
7、收银台
后台管理目标
1、会员中心
2、工作人员中心(包括服务员,厨师,管理人员以及采购人员等)。
3、货物中心。
4、收入结算中心
5、管理员中心
基于上述需求,零度软件公司提出如下技术解决方案来实现本项目的技术目标和业务目标。
2.技术解决方案
运行流程
注:
此处只写出主要流程,其它细小功能在此处不予显示。
显示的图片全为简图,旨为形象化表示
前台流程
客人到达,来到一体机,此为一体机
1号桌
2号桌
3号桌
开始界面,根据自己选择想要的桌号
(在使用的桌子为灰色,不可点)。
看右图(对于包间的一体机不用如此
选择)
点击后进入另一界面,要求设置密码
(为了防止出现不必要的错误),然后进
入。
系统将该密码打印,给客人,以免
客人忘记密码。
进入下一个界面,判断是否为会员
如果是会员,则要求输入会员号和
会员密码
进行完上述操作后,进入主界面。
以菜单查阅为例,以列表方式呈菜,点击后可看详细信息(文件夹功能只有会员可用,会员可以将自己喜欢吃的菜放入文件夹,所以详细信息中,只有会员才有加入文件夹功能)。
当然,查看状态和添加菜只能在提交完菜单之后才可使用。
如下图所示。
详细信息中包含许多重要信息
最后顾客选完菜之后,可以查看自己所点的菜,并进行一些操作
如下图所示。
百合牛肉
红枣煨肘
……
菜单信息提交到厨房,传到厨房的
菜单按照时间和会员级别排序后
显示。
厨师点击后可以进入详细
菜单(点击后该桌变为灰色,不可
再点,以防冲突)
百合牛肉
红枣煨肘
……
以7号桌的菜单为例,展示内部详细
菜单内部构造。
点击处理之后进入下
一个界面
7号桌牛肉
2号桌牛肉
……
这里是为了厨师可以一次做多道相同
的菜,提高效率。
做完之后,该桌的
这道菜和其它相应桌的菜变为灰色。
厨师A
厨师B
厨师C
雪魔芋鸡翅
鳝鱼鸡蛋卷
……
如果此时客人想查看菜的状态,
可以再次登陆自己的那桌,点
击查看状态选项
如果客户想要加菜,登陆自己的
雪魔芋鸡翅
鳝鱼鸡蛋卷
……
那桌,点菜方式和刚开始完全一
样,点完之后查看菜单,上面有
以前的菜和现在刚点的菜(以前
点的菜没有删除选项),刚点的
菜以不同颜色显示,提交的时候,
系统只把新点的菜传入厨房。
1号桌
2号桌
3号桌
结账时,会员和非会员有不同的
计算方法,都到收银台结账(收
银台处的一体机功能唯一,只
显示菜单和价格),可以使用现金
或是刷卡方式。
客人输入密码后
进入自己的桌子,界面显示如下:
雪魔芋鸡翅
鳝鱼鸡蛋卷
……
点击结账之后,该桌从灰色变为黑色,
表明该桌无人使用,可再次点击。
并
且同时打印收据。
然后,出现评价窗
口,可以评价饭菜质量或是服务态度,
如有图所示:
后台流程
物理架构
功能构成图与ER图
功能构成图
ER图
数据流
认证管理
管理员和经理进入系统时,必须输入账号与密码。
客人在操作时,也要自己设置相应的密码。
系统可靠性及可扩展性
系统的可靠性及可扩展性对企业级应用来说是非常重要的。
我们的设计充分考虑了这两个因素。
针对可靠性,我们的设计是在系统包含一个双机组成的数据仓库,。
数据仓库带有自己的外存磁盘阵列。
非功能性设计
性能需求
容量设计
建议每年的数据量分配在200G左右。
响应设计
高的响应能给用户带来效率上的提升,加快了工作效率,减少了等待时间,同时加快了系统的处理效率,我们将通过以下几方面手段来保证用户得到高质量的响应:
1.优化模型设计,好的模型设计能够减少冗余数据量的加载和检索,以及表间关联检索,能大大提高系统数据的响应时间。
2.有效利用数据库的缓存功能,对于经常访问的数据,可将数据缓存于数据库中,减少IO,
3.利用集群功能,合理分配负载,充分利用各主机的CPU,内存等硬件资源。
灾备设计
灾备级别
∙高:
内部系统核心数据,包括所有连机和脱机数据,需要高级别的备份。
∙中:
系统需要的资料数据。
∙低:
与系统关系不大,偶尔系统需要使用到的数据。
由此可见,对于高,中级别的数据,需要进行对应的备份。
备份策略
为了保障核心数据和重要数据的完整性和一致性,我们将提供对应的磁盘备份、联机备份和远程备份功能:
磁盘备份:
通过镜像(mirrored)磁盘矩阵,对每一个写到磁盘的字节,作实时的镜像备份,减少磁盘机出错的几率。
磁盘备份一旦设定,由设备实现,无需人工干预。
联机备份:
提供24*365天的备份机制,用户可以基于调度来运行备份,可以基于系统运行的热备份。
我们设计方案中使用的Oracle11g。
远程备份:
提供对付灾害性的系统失败的有效方式。
远程备份把数据存放到地理上的远方,以应对主机可能遇到当地灾害性的损毁。
我们建议把每天的热备份数据,拷贝到远端备份存储服务器。
以上的备份策略,保证在不影响系统服务的条件下,在本地和远程,都保留一份前一天的备份数据。
当地备份建议保留30天;远程备份建议保留7天。
备份可以保存在磁带库、或光盘库。
本地备份耗时目标是2小时;远程备份耗时目标是12小时。
恢复策略
常规的数据恢复流程设计如下:
1)重启系统的所有服务器和存储设备
2)如必要,恢复系统
3)从本地备份选取前一天的备份,或最近的备份;如果本地备份丢失,取远程备份
4)恢复数据仓库数据
5)恢复系统服务
常规数据恢复一般是在文件系统失败(包括磁盘设备失败)导致数据无法使用的情形下必须激活的程序。
常规数据恢复保证系统回复到前一天的状态,但也意味着当天数据的丢失。
一般系统出错的恢复,其实不一定需要用到备份,我们建议应该避免使用常规数据恢复,尽量考虑用其他办法把系统回复到最近的可用状态。
以下我们以Oracle数据库为例,说明一下可以考虑的恢复措施。
数据库的恢复过程分两步进行,首先将把存放在重做日志文件中的所有重做运用到数据文件,之后对重做中所有未提交的事务进行回滚。
数据库的恢复只能在发生故障之前的数据文件上运用重做,将其恢复到故障时刻,而不能将数据文件反向回滚到之前的某一个时刻。
数据库的异常、错误可以分为以下几类:
∙SQL语句失败
∙线程失败
∙实例失败
∙用户操作失败
∙存储设备失败
如果发生前三种失败,不需要人为干涉,系统会自动进行恢复。
对于用户操作型的失败(如误删除数据),系统采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。
数据库引入了基于表空间的时间点恢复(TSPITR),可以单独将包含错误操作的表空间恢复到指定时间,而不必对整个数据库进行不完全恢复。
当错误操作发现比较及时而且数据量不大的情况下也可以考虑使用logminer生成反向SQL。
针对存储设备的失败的情况比较复杂,存储设备的失败必然会使放置在其上的文件变为不可用,我们先将数据库所涉及到的文件进行一个划分,主要可分为:
∙数据库的系统文件,指数据库的运行文件,各种应用程序
∙数据库控制文件
∙数据库联机重做日志文件
∙数据文件
∙归档日志文件
避免第一种文件失败主要依赖系统管理员进行操作系统级的备份,当发生事故后只能依靠操作系统备份将其恢复。
控制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息,在创建数据库时会让用户指定三个位置来存放控制文件,他们之间互为镜像,当其中任何一个发生故障,只需将其从ini文件中注释掉故障数据文件就可重新将数据启动。
当所有控制全部失效时,可以在Nomount模式下执行createcontrolfile来重新生成控制文件,但必须提供redolog,datafile,文件名和地址以及MAXLOGFILES,MAXDATAFILES,MAXINSTANCES等信息。
如果失败之前运行过alterdatabasebackupcontrolfiletotrace或alterdatabasebackupcontrolfileto‘xxx’对控制文件作备份,恢复时可使用生成的脚本来重建或用备份文件覆盖,如果使用了旧的控制文件在恢复时要使用recoverxxxusingbackupcontrolfile选项来进行恢复,并使用resetlogs选项来打开数据库。
可获性设计
高可获性来自于我们建议的软件系统,无论是Oracle,IBMDB2,或Actuate9,都支持失败转移等高级集群功能,满足提供7x24不间断服务的要求,能够保证满足任何时候系统的可获性需求。
易用性设计
在软件的易用性方面,我们将充分考虑用户的体验性,简单性,高效率性为客户定制一套更适合客户需要的的系统,根据需要,我们将基于以下方面进行设计:
∙制作一体机。
∙用户界面友好、同时易操作。
∙界面操作符合浏览习惯。
∙界面风格,术语统一。
∙合理的组织操作菜单
∙查询等出现错误时提供友好的提示。
安全性设计
身份认证
系统提供身份认证功能。
使用系统的用户必须先要经过申请审批管理流程,通过有关部门管理人员的合法性审批,系统管理员在系统管理模块中设置用户名、操作权限和初始密码,并告知用户后,用户才可以用指定的用户名和密码登录进入系统,进行权限范围内的操作。
在系统登录界面中,只有输入正确的用户名和密码,才能进入系统,进入系统后用户可随时修改自己的密码。
对用户密码可提供更严格的控制功能,如首次登录系统必须修改密码、经过多长时间必须修改密码、多次登录失败锁定用户等,进一步提供系统的身份认证安全性。
用户权限控制
系统提供权限管理功能模块,系统管理员可增加、删除、修改用户、用户组,设置用户的、操作权限、数据权限。
通过用户、用户组及权限管理功能,可根据机构、部门、用户类别等建立用户组,用户可以属于某个组或几个组,也可以是独立用户。
通过对用户组进行授权,组中的每个用户都拥有组的所有权限,极大方便了授权管理;独立的用户可以独立授权。
用户组、用户的权限可以针对机构、业务数据的范围、功能范围等进行授权,实现系统应用的数据安全。
关键数据加密存储
对于存储到系统中的一些关键敏感数据,程序对这些数据进行加密存储,使得在其它任何软件环境中都无法获取明码。
系统操作处理日志
系统对用户登录情况,如登录用户、进入时间、退出时间、操作功能项等进行自动记录;对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行情况等也自动记录日志,以便出问题时跟踪追查审计。
系统日志还可用于系统操作的防抵赖。
安全管理机构和制度建设
明确系统的安全管理机构/部门、人员及职责,负责管理系统安全保密工作。
制定系统安全保密管理制度,并严格加以执行及监督,实现资源的合理配置和统一管理,实现统一的访问控制策略,确保系统的安全运行、安全审查。
在外部安全上,企业级的防火墙可以为本系统提供一个安全的运行环境。
在系统内部,本系统用户众多,机构、角色、权限各不相同,因此必须具有较高的安全性,防止用户越权访问以及窃取数据。
用户的每个动作都要经过身份验证,在身份与权限匹配的情况下才能继续执行其他操作,就可以有效实现安全性目标。
操作授权:
对不同使用部门使用产品的授权和其中不同级别的用户使用产品功能的授权由系统管理员分级授权,授权信息放在数据库中,操作员的每一个操作均需系统授权。
3项目管理
沟通管理
项目会议制度
项目会议是服务于项目工作的,是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。
每次会议都要有专人做会议记录,会议纪要的格式参见双方约定文档规范中的会议纪要模板,会后由记录人员将会议纪要分发给相关人员,并上传版本库中。
项目组根据项目实际情况拟设立定期会议和不定期会议,分别阐述如下:
定期会议
✧项目周例会
∙会议目标:
沟通项目状态,提出项目问题、风险和依赖条件;协调项目资源;对项目提出建议,问题的解决方法,行动计划。
∙日期与时间:
每周四14:
00开始。
∙参加人员:
乙方项目经理;甲方项目经理;项目经理指定的其他成员。
∙主要议程及责任:
更新项目状态,包括:
跟踪检查项目遗留问题的解决情况;项目状态信息,时间进度表等;问题,风险,依赖条件(技术和管理);对提出的问题,讨论和决定行动计划;乙方负责做会议记录,会后分发会议记录,将会议记录上传到版本库中,并负责下一步行动计划。
不定期会议
✧项目状态会议
∙会议目标:
使项目全体人员明确目前项目的状态、问题、解决方法。
∙日期与时间:
根据实际需要确定。
∙参加人员:
所有项目人员。
∙主要议程及责任:
项目状态,存在的问题及解决方法;下阶段项目计划。
✧项目领导组会议
∙会议目标:
审核下阶段项目计划;复查项目状态和里程碑;对项目中的重大问题做出决策;协调项目各方资源;解决项目各方可能发生的重大争议。
∙日期与时间:
根据项目进展实际情况安排。
∙参加人员:
项目领导组成员;乙方项目经理;甲方项目经理;其他有需要参加的人员。
∙主要议程及责任:
项目经理汇报项目状态和下阶段项目计划;项目领导讨论项目中需要决策的重大问题;乙方负责做会议记录,会后分发会议记录,将会议记录上传到版本库中,并负责下一步行动计划。
✧重大问题汇报会议
∙会议目标:
汇报项目重大问题,并讨论决定采取何行动。
∙日期与时间:
重大问题出现时。
∙参加人员:
问题发起人;项目经理;高层领导等。
∙主要议程及责任:
汇报项目重大问题,找出解决方案,决定行动计划。
✧项目组内部讨论/沟通会议
∙会议目标:
对项目组内部遇到的问题进行讨论,找出解决方案,并讨论决定采取何行动。
∙日期与时间:
根据开发的状态。
∙参加人员:
问题发起人;沟通相关人员等。
∙主要议程及责任:
讨论出现的各种相关问题,找出解决方案,决定行动计划。
项目状态周报制度
项目组各组员每周一上午提交周报,提交到乙方项目经理,由安讯软件(上海)有限公司项目经理汇总后提交给甲方项目经理;甲方项目经理根据项目状态,总结项目周报,形成项目组的状态周报,并于每周一下午4点之前上传到版本库中的周报目录上。
沟通手段
✧开会或直接交谈
按需要组织会议进行沟通,或直接找相关的人进行讨论,注意记录沟通和讨论结果,重要问题讨论必须有书面会议记录。
✧电话或电话会议
通过电话的方式进行信息沟通。
对比较重要的事情,需要包括开发地点以外的人员,则需要利用电话会议的方式进行讨论,沟通。
✧电子邮件
建立项目组电子邮件系统及与外界联系的电子邮件系统。
配置管理
配置管理原则
所有的项目过程文档、代码或项目最终文档、代码的编制工作,都必须在甲方提供的配置环境中进行,所有人员都必须按甲方的配置管理制度进行工作。
配置库管理
配置库分为文档库和代码库。
文档库管理项目的所有文档,而代码库管理项目的所有代码,文档及代码库进行基线化管理,按照项目阶段,对文档库和代码库打基线。
经测试以及审核后提交产品库,文档与产品由甲方统一管理,未经甲方同意,不得对任何项进行任何更改。
变更管理
为了保证项目开发工作的相对稳定性,提高工作效率,确保开发质量。
对影响项目计划的变更,制定出处理变更的规范的、统一的方法和过程,估算出因变更引起的相应的资源、费用、和时间的变化以及变更确立后,变更的发布,执行,和过程质量的控制。
本项目成立变更控制委员会,一般为单数组成(甲方人数=乙方+1),由甲方指定人员任变更控制委员会主任;
变更的审批由变更控制委员会表决决定,2/3人数通过为表决通过,变更控制委员会主任有最终否决权。
如变更控制委员会无法对变更做出最后决定,由变更控制委员会主任将变更申请提交项目管理高层进行裁决。
发起变更
提出变更要求必须填写《变更申请表》(参见附件C“变更申请表”所附表样)。
《变更申请表》由变更申请人填写。
变更控制委员会审议变更申请的有效性和变更的必要性,决定拒绝变更申请或者要求乙方对申请的变更进行评估。
评估变更
乙方指定的评估人员要充分评估变更对项目整体计划、进度、费用及质量的影响,进行全面的评估,在五工作日内,填写变更评估表(参见附件C“变更申请表”所附表样),以书面形式提交甲方。
审批变更
变更控制委员会对变更请求进行审批,由变更控制委员会主任签署书面变更审批单,有效变更审批间必须在审批结论中明确是否通过变更申请。
涉及合同变更的不在变更控制委员会审批范围内,根据购买合同规定的条款进行审批。
执行变更
乙方负责根据变更审批结果,调整相关项目计划,根据新的项目计划和项目进度,重新分配资源,对变更展开工作,并指定变更执行评估人员。
变更有关执行人进行变更执行。
执行完成后向变更控制委员会报告变更执行情况。
变更执行评估
变更控制委员会中乙方委员负责填报变更执行结果评估表,对执行结果进行评估跟踪,并将结果向变更控制委员会主任报告。
质量管理
质量规划
✧质量目标:
针对数据仓库一期系统,确立以下质量目标,甲乙双方应针对以下质量目标开展质量管理活动:
∙保证100%满足业务需求要求的正确性与精确性
∙用户满意度达90%以上
✧质量管理原则
∙客户满意度优先
∙预防优于检查
∙管理层的责任
∙持续改进
✧质量保证计划:
合同生效后,甲乙双方应在质量方针、质量目标、质量原则及项目范围等的前提下建立质量保证计划,明确相关干系人质量管理职责、项目质量管理任务的定义与责任人、需遵守的制度、规程、规范与标准、质量控制的方法、工具、记录与跟踪等,便以此为基础,有效地开展质量管理活动。
✧测试要求
测试作为项目最主要的验证方式,应该得到双方的高度重视。
应达到以下要求:
∙所有测试必须有适用的测试管理流程,得到质量控制小组的确认
∙在需求分析阶段,出具用户测试计划,以保证需求的可测试性
∙在概要设计阶段,出具集成测试计划、集成测试案例
∙在详细设计阶段,出具单元测试计划、单元测试案例
∙编码阶段所有模块必须经过单元测试通过,并出具单元测试报告,经双方项目经理确认
∙集成测试计划需经评审通过
∙集成测试必须有两轮以上的测试,每轮测试必须有集成测试报告
∙用户测试必须由甲方组织测试通过,出具经相关单位盖章的测试报告后,视为完成
∙在集成测试完成后的程序修改应有足够的回归测试工作,并得到项目质量控制小组的确认
质量保证
甲乙双方在项目实施期间应进行以下质量保证活动:
1.规则的培训与指导
双方项目经理负责组织在项目启动阶段向项目组成员做有关制度、规程、标准、工具与模板的使用培训。
2.文档管理
✧文档规范
•文档需遵循一定的规范,由双方参照相关国际与国家标准协商制定,需经甲方项目质量控制人员审核通过。
•文档标识方法必须有统一的文档编号;
•文档应具有相关的定位信息与参考信息等,如:
文档作者、完成日期、批准人员、批准日期、新发布与修订情况、流通清单、机密性限制等
✧文档批准:
所有文档必须经项目经理或质量保证人员的审核通过,正式提交件必须经过相关评审认可,参见提交件管理部分。
✧文档的存储与检索:
•存储:
双方明确文档存储管理人员,正式提交文件存储应在甲方统一配置管理平台上进行。
•文档的流通与检索:
经审核的新文档必须按时流通到指定收件人;保证副本的有效、准确、保密性。
•文档保密、包括文档的废止:
严格按照文档类型的限制访问;防止非授权人员改变存储的文档;提供电子或纸质的备份;确定存储期限。
3.需求跟踪管理:
甲乙双方项目人员应在项目开发过程建立需求跟踪矩阵,以对需求进行有效跟踪。
4.评审、同行评审与走查:
在项目需求分析阶段,需求分析说明书在正式提交前均应进行内部评审工作。
在项目设计阶段,相关技术文档均应进行至少一次的同行评审工作,双方质量保证人员负责跟踪缺陷的解决。
在项目编码阶段,开发组长应每半月组织至少进行一次代码的走查的工作,开发组长负责缺陷的跟踪。
5.变更控制:
双方均需遵守定义的变更控制流程,具体流程详见变更控制部分
6.版本管理:
对每一阶段的产品,进入集成阶段后,所有的版本控制工作,由甲方指定配置管理员统一按有关流程进行发布,甲乙双方其他人员不得以任何形式在测试环境或生产环境进行发布工作。
7.问题跟踪:
乙方负责指定专人对项目实施过程中出现的问题与缺陷进行跟踪解决,每周出具相关统计信息。
8.过程审计:
质量控制小组定期对项目质量工作进行审计,双方应就审计结论进行相关整改。
9.质量汇报:
双方项目经理应本着实事求是的原则,向双方管理层及时准确地汇报项目情况,保证项目的可视性。
质量检查
甲乙双方应就项目进展情况定期进行质量检查工作,保证项目按既定计划,保证质量地实施。
乙方应配合甲方有关项目管理部门进行质量检查,并及时根据检查结果,进行跟踪解决。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 餐饮 管理 系统 开发 投标