家庭旅馆管理系统分析报告.docx
- 文档编号:5247801
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:15
- 大小:87.01KB
家庭旅馆管理系统分析报告.docx
《家庭旅馆管理系统分析报告.docx》由会员分享,可在线阅读,更多相关《家庭旅馆管理系统分析报告.docx(15页珍藏版)》请在冰豆网上搜索。
家庭旅馆管理系统分析报告
家庭旅馆管理系统分析报告
课程名称专业综合设计
学院管理学院
专业班级11级电商
学号
姓名
指导老师闵惜琳
2014年12月
目录
第一章前期工作1
1.1业务概况1
1.2存在问题1
1.3业务目标1
1.4可行性分析2
第二章业务建模4
2.1业务分析4
2.2业务用例4
2.3业务用例场景5
2.4业务用例规约7
第三章需求分析8
3.1分析问题8
3.2系统目标8
3.3系统范围和边界9
3.4参与者9
3.5系统用例9
3.6系统用例场景11
第四章系统分析12
4.1软件架构和框架12
4.2分析对象12
4.3分析模型14
参考文献15
第一章前期工作
本项目从问题领域出发,在前期的准备工作中,主要依靠互联网或书籍上的资料及接触到的个别实际旅馆,对问题领域进行分析,了解旅馆业务状况,明确业务范围,发现旅馆管理方面存在的问题,从而整理出业务目标,并分析其可行性。
1.1业务概况
家庭旅馆管理主要管理的是旅馆及房间的基础信息,包括旅客的预定房间、办理续租、换房、寄存物品及前台人员办理入住结算操作、旅馆营业数据等信息的集中管理等。
1.2存在问题
目前在现实中,大部分家庭旅馆都没有一个成熟的、合适的系统来管理其旅客的入住信息及自身营业信息,在日常营业中主要存在以下几个问题:
(1)旅馆业务采用纸张登记,为旅客进行业务处理的能力和效率低。
由于为游客办理房间预订、房间入住、房间结算、房间续租、换房间、寄存物品登记等业务工作效率低,导致家庭旅馆营业额上不去。
(2)业务信息不够集成,过于分散,业主登记本旅馆的旅馆信息和房间信息时过于混乱,无法有效对家庭旅馆的房间信息、房间预订订金等进行设置和管理。
(3)入住统计、房费收入统计、营业情况概览及游客来源等统计功能不够便捷,使业主无法及时了解本家庭旅馆的经营情况,难以进一步扩大营业范围和及时调整营业方式及服务等。
(4)纸质化的信息管理不易查找且容易丢失损毁,不便于业务操作和存储。
1.3业务目标
通过对实际问题的研究、分析,对家庭旅馆的了解,最终根据实际业务需要,针对当前存在问题,为实现家庭旅馆业务的人性化管理,确定开发一个家庭旅馆管理系统,以达到如下目标:
(1)实现家庭旅馆管理的自动化
本系统的产生使家庭旅馆业主步入无纸化办公时代。
进一步提高了为游客进行业务办理的能力和效率。
可以快速为游客办理房间预订、房间入住、房间结算、房间续租、换房间、寄存物品登记等业务,在提高工作效率的同时,更大程度上增加了家庭旅馆的营业额。
(2)实现家庭旅馆业务的集成化与个性化
本系统集众多模块于一身,能够为游客办理多项业务,如:
入住、结算、续租、换房、存物品等。
且该系统能够使各家庭旅馆业主实现更多个性化管理,业主可登记本旅馆的旅馆信息和房间信息,并进一步对家庭旅馆的房间信息、房间预订订金等进行设置和管理。
(3)详尽地统计游客入住信息
本系统实现了本家庭旅馆的入住统计、房费收入统计、营业情况概览及游客来源等统计功能,让各家庭旅馆业主可更充分的了解本家庭旅馆的经营情况,进一步扩大营业范围,及时调整营业方式及服务等。
(4)实现系统数据的安全存储
本系统提供了完善的数据备份和数据还原功能,避免由于家庭旅馆业主的计算机故障或其他原因导致游客入住数据的丢失,家庭旅馆业主可定期进行家庭旅馆数据的备份和还原,防止造成不必要的损失。
(5)美观的用户界面和简易的操作方式
本系统考虑到家庭旅馆业主通常年龄较大,IT水平有限,甚至有些业主视力记忆力下降,期望使用操作简易的系统进行快捷的操作,特开发的系统界面简洁直观,方便上手。
且可通过系统提醒家庭旅馆业主待处理的工作,可进一步增加系统的易用性。
1.4可行性分析
在最短的时间内把确定的问题能够得到圆满解决是可行性分析的目的。
也就是用最小的代价在尽可能短的时间内确定问题是否有必要解决,是否能够解决,是否值得解决。
因此,主要可以从以下四个方面进行分析:
(1)技术可行性
根据本项目的前期调查,可以看到在外部接口方面只有收银机、打印机等日常的基本硬件设施,难度不大。
另外在系统开发方面,根据用户要达到的业务目标,当前的技术水平完全可以到达用户的要求,足够满足本系统的功能及非功能性需求。
因此,本项目系统的开发在技术上是可行的。
(2)经济可行性
该家庭旅馆管理系统的功能需求不高,开发难度不大,同时系统目标并不复杂,开发周期较短,人员经济支出不多,软硬件环境成熟。
其经济成分比重相对较少,主要费用只是前期的系统设计阶段及后期的定期维护更新等。
总体来说,此系统的开发在经济方面是可行的。
(3)操作可行性
本项目系统经过了前期的调研,系统各方面的需求,均是通过与业主沟通、商讨得出,专门为旅馆的管理人员开发。
由于管理系统具备友好的用户界面,使用方便,易于维护,操作简单等特点,用户只需熟练操作使用过计算机,在做几次简单的培训,通过对系统功能模块的简单了解即可方便使用,从而保障了系统的操作可行性。
(4)社会可行性
在当今这个移动互联时代,一切的商业行为都不可避免地与互联网有所联系。
未来的旅馆业里肯定会有越来越多的电子化产品帮助业主管理旅馆的日常事务,提供业主和旅客最便捷的服务,造福更多的人群。
因此,在社会可行性方面,本系统的开发是可行的。
综上分析,本系统的开发,在技术、经济、操作、社会等方面都是可行的;因此,通过开发本系统来完善家庭旅馆管理业务是切实可行的。
第二章业务建模
针对家庭旅馆行业的业务现状和目标,本章节对相关方面进行了业务建模,以便进一步了解目前家庭旅馆业务的现状,本项目根据实际需求,主要采用业务用例模型,通过对业务的分析、获取业务用例、描述业务用例场景、给出业务用例规约构建出实际业务的模型。
2.1业务分析
当前业务的现状主要有客房管理、旅客信息管理和消费管理模块等方面。
而由于旅客信息是与客房相关联的,所以可以把二者合并起来。
具体描述如下:
(1)客房管理
主要用于用户对客房及其业务的情况进行管理,其中包括:
客房管理:
可以对所有客房进行管理,包括增删该房间及房间状态;预定管理:
可以接受预定房间;收银管理:
完成对客户住宿的结账;顾客信息管理:
管理客户的基本信息。
(2)消费管理
主要用于对客户在入住期间的消费进行入帐操作,包括消费入帐,话费入帐,餐费入帐等操作。
2.2业务用例
通过实际调研,以上分析,可得出实际参与业务过程的业务主角有:
市业主、前台人员、旅客。
同时,也可得出两个主要的业务用例:
客房管理用例、消费管理用例;其中,客房管理用例可扩展出预定管理用例、收银管理用例和顾客信息管理用例,因此便可建立业务用例视图,如图所示:
业务用例图
2.3业务用例场景
业务用例场景用来描述该业务用例在该业务的实际过程中是如何做的,即说明该业务用例的执行过程,说明业务主角是如何使用业务用例完成业务目标的。
绘制业务用例场景可以使用活动图、顺序图、协作图等交互图来描述。
根据本项目的实际情况,使用时序图来绘制业务用例场景,描述业务的实际具体流程,具体如下:
(1)旅客入住时序图
旅客进行住宿活动时,前台查询是否有空房,并进行查询客房信息,然后登记本次住宿的所有信息。
(2)旅客结账时序图
旅客需要退房,前台进行退宿结账,打开结账界面,输入旅客的房间号,显示住宿费用信息,旅客支付费用,完成结账。
2.4业务用例规约
通过以上对业务用例的描述已经可以得知某几个业务的实际执行过程,以及参与者的实际职责,下面再通过业务用例规约对业务用例进行描述说明与规范,具体如表所示:
(1)客房管理业务用例规约
用例名称
客房管理业务用例
用例标识符
KFGL
用例描述
业主及前台对客房及其业务的情况进行管理
参与者
业主、前台、旅客
前置条件
无
后置条件
无
基本流程
1.客房预订
2.旅客预订未到处理
3.旅客入住处理
4.旅客信息修改
5.房态设置
6.退房
7.房间状态
(2)消费管理业务用例规约
用例名称
消费管理业务用例
用例标识符
XFGL
用例描述
业主及前台对客户在入住期间的消费进行入帐操作
参与者
业主、前台、旅客
前置条件
无
后置条件
无
基本流程
1.记账
2.明细账查询
第三章需求分析
需求分析是任何一个项目成败的根本,需求分析的目的是规范化本项目的开发,旨在提高软件开发过程中的能见度,便于客户和程序员之间交流、协作并作为工作成果的原始依据,同时也表明了本项目的共性,以期能够得到更大范围的应用。
通过和客户的反复沟通及确认,确定客户的具体功能需求。
3.1分析问题
(1)数据交换及关联
通过对现状业务的分析,可以看到实际上旅管管理系统与其他系统之间的数据交换并不是很密切,这就大大降低了软件编写的难度。
不过为适应今后旅馆的扩张壮大,系统需要留有适当的接口等一边今后的修改,以便与其他系统数据关联。
(2)业务补充
实际调查发现,现状业务存在缺少一个审查管理模块,主要用于该旅馆管理者对宾馆的基本数据信息进行查看,以便制定策略。
包括客房状态报表查看,客户入住信息报表查看,历史客户报表查看等等。
3.2系统目标
根据对现状业务当前存在问题的分析,以满足用户业务目标为基础,进行细化、具体化,最终得出本系统的开发目标。
根据实际业务需要,确定开发C/S模式的旅馆管理管理系统,以旅馆的精细化管理。
(1)客房管理业务
系统接收旅客的客房预订,并对预订未到的客房进行相应的处理,旅客入住时登记相应的信息,前台及业主可对旅客及房态信息进行查询,旅客退房时进行房态修改等操作。
(2)消费管理业务
旅客在旅馆内产生的任何消费都会登记在系统中,业主和前台可对相应得明细账进行查询。
(3)审查管理业务
业主对宾馆的基本数据信息进行查看,以便制定策略。
3.3系统范围和边界
根据以上对用户需求的分析,旅馆管理系统的系统边界,为旅馆信息管理边界。
根据系统目标,系统管理的内容都是为旅客服务的,因此这个部分处于系统外部,即系统边界外。
而客房管理业务、消费管理业务、审查管理业务这些管理内容就属于该系统管理范围内。
其他与这些管理内容无关的均属系统范围外。
按照这个分析,可得出如图所示的系统边界图:
3.4参与者
通过对旅馆管理系统需求分析得到:
系统外真正需要参与到系统的参与者有2个,分别是业主、前台人员。
旅客只是在入住及消费等情况下提供个人信息给旅馆,对本系统没有实际需求,没有使用到该系统,故不是参与者。
前台人员:
接收客房预订,对预订未到的客房进行相应的处理,旅客入住登记,旅客及房态信息进行查询,房态修改,记账等。
业主:
接收客房预订,对预订未到的客房进行相应的处理,旅客入住登记,旅客及房态信息进行查询,房态修改,记账,明细账查询等。
3.5系统用例
在UML建模过程中,用例图对系统的语境进行建模,强调的是系统的外部参与者。
对系统语境建模可以参考以下方法:
1.将类似的参与者组织成特殊化的结构层次;
2.在需要加深理解的地方,为每个参与者提供一个构造性;
3.将参与者放入到用例图中,并说明参与者与用例之间的通信路径。
(1)旅客预定房间
旅客可以通过电话预定房间,前台服务员将旅客要求预定的房型、房间数以及预定日期等录入系统,并以短信的方式告知旅客。
如果旅客未能在规定时间内入住,则应及时取消订单。
旅客预定房间用例图如图所示。
(2)退房
旅客需要离开宾馆时必须先结账,根据入住时间和房间类型计算消费金额,结账后必须把房间状态更新为“打扫”。
前台结账用例图如图所示。
3.6系统用例场景
系统用例场景与业务用例场景一样,都是描述用例的执行过程;不同的是,业务用例场景单单描述现实业务,而系统用例场景则是描述现实业务在结合新系统后如何执行的过程,系统的参与者如何使用这些系统用例来完成业务目标。
绘制系统用例场景同样可以使用活动图、顺序图、协作图等交互图来描述。
本项目使用活动图来绘制系统用例场景,描述系统用例实现的执行过程。
通过以上对系统用例的分析、给出用例规约,已经可以基本了解到系统用例的执行过程,下面我们来看一下前台服务员活动图,可以通过以下步骤描述前台服务员活动图:
Ø旅客要求入住
Ø前台服务员登录系统查看住房信息
Ø将查到的客房信息告知旅客
Ø旅客确定住入房间
Ø前台服务员修改房间入住信息
Ø前台服务员退出系统
根据以上所述,前台服务员的活动图如图所示:
第四章系统分析
统一过程把分析与设计合并为一个核心工作流,即当成一个阶段来看。
其实,分析设计阶段,也就是我们通常所说的概要设计与详细设计。
分析阶段是通过分析类,建立分析模型,描述系统如何使用对象来实现系统需求。
同时,分析阶段未涉及实现语言与方式,抽象层次较高。
因此,用分析阶段作为需求到设计的过渡,来保持与系统需求一致。
系统分析,即在系统需求分析的基础上,确定软件架构和框架,并在软件架构和框架的约束下,通过分析对象类,建立分析模型,描述系统如何使用对象来实现系统需求。
4.1软件架构和框架
(1)软件架构
系统在架构上主要包括两部分:
服务端程序与客户端程序。
服务器端程序参考了同行业类似管理站点的设计架构,采Windowsserver2008+IIS6.0作为web服务器基础配置。
Windowsserver2008作为老牌服务器操作系统,在稳定性与安全性上有着其他windows系统所无法比拟的优势,而IIS6.0作为windows操作系统上新一代的web容器,在作为网络应用服务器管理方面、可靠性、安全性、可用性、性能与扩展性方面提供了许多新的功能。
因此,采用WindowsServer2008+IIS6.0提供了最高效、安全、可靠、完善的网络服务器解决方案。
客户端程序采用标准桌面程序开发方法,在软件设计方面采用了模块化技术,使得系统易于管理和维护,易于扩展和应用,确保用户投资的长期效益,避免资源重复浪费。
(2)软件框架
本系统采用MVC模式进行设计,将系统分为表现层业务逻辑层与数据层。
其中,Model层是对于数据库操作的Dao类,通过该类获取数据库实例,从而完成对数据库的操作。
在Controller层,主要是对应与各个功能的Action,主要完成的是对功能事件的响,从而调用业务逻辑处理,完成相应的业务流程。
View层主要是采用JSP页面进行界面展示。
4.2分析对象
按照面向对象的分析思路,需要将上述需求分析得出的系统用例或功能抽象成一个个的对象,通过对象之间的交互来描述具体需求的实现。
因此,我们从分析系统的对象开始,进入系统分析阶段。
在UML的分析模型中,MVC模式使用边界对象、控制对象、实体对象,这三者来建立用例场景的对象模型。
因此,回顾以上分析,仔细分析系统用例场景中的活动,以此发现和定义各个用例的对象,并得知对象间如何交互来实现用例。
本项目使用顺序图来描述用例的对象交互。
(1)旅客入住用例对象交互
(2)旅客预定修改用例对象交互
(3)旅客退房用例对象交互
4.3分析模型
通过以上对象间交互的分析,可以明白新系统将如何使用这些对象来实现用例。
那么,根据这些对象的特征,以及调查中的数据分析,可以初步得出相关的类。
参考文献
[1]谭云杰.大象——ThinkinginUML[M].北京:
中国水利水电出版社,2009.
[2]张立厚,莫赞,张延林,陶雷.管理信息系统开发与管理[M].北京:
清华
大学出版社,2008.
[3]宋丽.UML在酒店管理系统中的应用[J].商场现代化,2009(03).
[4]朱波.宾馆旅客管理系统的设计与实现[D].上海:
华东师范大学,2009.
[5]祝继武.酒店管理系统的分析和设计[D].吉林:
吉林大学,2004.
[6]杨玉平.基于WEB的酒店管理系统的设计[D].吉林:
吉林大学,2012.
[7]魏娜娣.家庭旅馆管理系统的设计与实现[D].山东:
山东大学,2012.
[8]曾艳.中小型酒店管理系统的设计与实现[D].厦门:
厦门大学,2013.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 家庭旅馆 管理 系统分析 报告