A航空公司剩余客票销售系统的开发 - 案例及案例分析 - 图文(2)

呼叫中心的可以查询旅客的预定和匹配信息，以及匹配成功后旅客的答复，如图6所示。

图6 呼叫中心查询匹配成功的旅客的信息

售票处可以查询旅客的预定记录和匹配是否成功的信息，如图7所示。

图7 售票处查询页面

开发单位原来准备将系统原型的制作交给网页制作公司，在了解市场行情之后，开发单位犹豫了。考虑到让网页制作公司理解系统的困难和经费问题，开发单位最终决定自己制作系统原型。用户单位在组织技术骨干和具体操作人员反复使用原型之后，提出了不少意见。其中既有增加系统核查员这一角色这样的重大功能改变，也有题头飞机是麦道而用户单位没有麦道飞机这样的形式改变。开发单位马上根据用户意见对系统原型进行了修改，并要求用户单位对系统原型同意签字后再进行下一步开发工作。 开发单位研究后决定，采用.NET技术，开发基于B/S的系统，数据库采用SQL SERVER。 在和用户单位进一步协商后，用户单位为了限制商务型旅客通过该系统订票，细化了一些限制因素：

1）退签、签转、更改航程航班的限制

通过本系统购买机票的旅客，无法无条件的退票、签转或者更改航程航班。此条件可以某种程度上限制时间、服务敏感的商务旅客。

2）服务等级限制

通过本系统购买机票的旅客，是无法享受与高票价旅客同等的各种服务的。在某些大型商务公司，相对于高等级舱位所代表的身份象征时，所谓的价格影响可以说微乎其微。

3）提前订票限制

通过本系统订票的旅客，必须提前三天或者三天以上订票。该限制结合退改签的限制，可以限制紧急出行的旅客通过该系统订票。一方面，紧急出行的旅客不能提前确定自己的出行需求，另一方面，紧急出行的时候，时间是一个主要的决策依据，相对来说价格可能并没有那么的重要。

4）出行日期限制

通过本系统订票的旅客，在订票时，只能指定出行的日期范围，而不能指定具体的某一日期，提交订票请求后，具体的日期由系统根据旅客指定的日期范围来安排。对于商务旅客来说，时间就是效益，每次出行的日期都是确定的，他们不会希望由系统随机地为他们安排出行日期，可能会导致损失很重要的商务会谈。而相对可能的损失来说，机票的价格实在算不上什么。

5）出行航班限制

通过本系统订票的旅客，在订票时，只能指定出发城市和目的城市，不能指定具体的某趟航班。具体的航班由系统或者航线经理根据各趟航班的售票情况来决定，该限制条件一方面使得航空公司可以灵活调节各航班的剩余座位数，另一方面也限制了那些对出行时间要求非常高的商务出行需求和紧急出行需求。

用户提交的订单和航线经理放出的折扣机票如何匹配？由于这一流程过去没有先例，用户单位内部反复讨论后提出了“申请时间优先、会员优先级优先、人数优先”原理：

“申请时间优先”不论是网上预订还是电话预订，按照提出申请的时间，谁提出申请的时间早，优先匹配。

“会员优先级优先”主要是针对会员的网上预订，按照会员积分的高低，积分高的为优先级，优先匹配。

“人数优先”是按照一次预订机票的数量，数量越大的，优先匹配。

4、系统设计 （一）功能设计

基于上述系统分析结果，开发单位提出了系统的几个功能：

1） 注册管理

提供免费注册功能，要求注册时提供用户名、密码、真实姓名、身份信息和联系方式。注册时所用的用户名和密码是用户以后预定机票的入口信息。

2） 航线经理放票管理

航线经理需要先录入和维护航线基本信息，然后根据情况决定某个时段的各航班的折扣票数和折扣大小。航线经理也可以查询当前的折扣票申请情况和匹配情况。还提供统计分析能力，分析总折扣票数、已匹配成功的折扣票数和剩余折扣票数。

3） 预订管理

顾客可以下订单预定某一时段某一航线的折扣票，在顾客预定时需要确认顾客了解剩余客票不可退改签的规定。也允许顾客查询和修改自己的订单。

4） 机票匹配

系统每天定时自动进行折扣票与预定申请的匹配。

5） 呼叫中心通知管理

呼叫中心每天根据匹配成功的结果通知顾客。如果顾客同意按匹配的时间和航班出票，记录当前时间，要求顾客在24小时内到营业部交款出票；如果顾客不同意按匹配时间和航班出票，则将这张票重新放入剩余客票票库，继续参加匹配。呼叫中心也可以查询待通知客户的相关信息。

6） 出票管理

营业部可以根据订单号或身份证号查询匹配相关信息，如果匹配成功，在顾客交款后可以出票。

7） 核查员管理

核查员是具有最高权限的管理者，可以了解航线经理放票的情况、顾客相关信息以及匹配的结果。

（二） 数据库设计

系统中有旅客、航线经理、售票处、呼叫中心和核查员多种用户，每类用户的操作权限

不同，所需的基本信息也不同。所以，系统中设计了一个用户基本信息表，用来记录所有用户的基本信息，包括用户ID、账户、密码、用户类型之类的用户最基本的信息；另外设计了一个旅客表存储旅客的基本信息，一个内部操作人员表存储 航线经理、售票处、呼叫中心和核查员等内部人员的基本信息。考虑到旅客持有的证件不同，没有采用身份证号作为旅客表的关键字。同时，考虑到后期可能的修改，在各个表中都预留了两个多余字段，如表2-表4。

表2 用户基本信息表T_U_User 序号 列名 数据类型 长度 小数 K 1 2 3 4 5 6 7 8 9 ID ACCOUNT PASSWORD QUESTION ANSWER LASTLOGINTIME LASTIP ACCLOGINTIMES UTID VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE VARCHAR2 NUMBER VARCHAR2 100 50 10 100 200 7 20 10 100 0 Y N Y Y Y Y Y Y Y Y PNULL 默认 字段说明 用户ID 帐号 密码 密码问题 密码问题答案 最后登陆时间 最后登陆IP 累计使用次数 用户类型ID（表T_U_UserType 用户类型） 10 EFFECTIVESTATUS 11 12 13 14 OPTERATOR OPTERATETIME R1 R2 VARCHAR2 DATE VARCHAR2 VARCHAR2 100 7 500 500 Y Y Y Y VARCHAR2 2 Y Y/N 用户状态，是否有效 修改人（ID） 修改时间 备注1 备注2 表3 用户类型表 T_U_UserType 序号 1 2 列名 UTID USERTYPENAME 数据类型 长度 VARCHAR2 VARCHAR2 100 20 小数 PK NULL Y N Y 默认 字段说明 用户类型ID 用户类型名称（旅客、大客户、航线经理、销售中心、呼叫中心、核查员、系统管理员） 表名 修改人（ID） 修改时间 备注1 备注2 3 4 5 6 7 TABLENAME OPTERATOR OPTERATETIME R1 R2 VARCHAR2 VARCHAR2 DATE VARCHAR2 VARCHAR2 100 100 7 100 100 Y Y Y Y Y

表4 旅客基本信息表T_U_Guest

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 列名 ID CNNAME FIRSTNAME MIDDLENAME LASTNAME TITLE GUESTLEVEL BIRTHDAY CARDNUM IDTYPE IDTYPENUM SEX 数据类型 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 长度 100 20 20 20 20 20 20 7 20 20 30 1 200 200 50 200 20 50 20 10 10 10 50 小数 0 0 0 K NULL 默认 Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y 字段说明 用户ID 中文姓名 First Name Middle Name Last Name 旅客称谓 客户级别 生日 会员卡号 证件类型 证件号码 客户性别 单位地址 家庭地址 电子邮件 邮件地址 邮编 传真号码 联系语言 累计里程 累计次数 累计金额 注册但成行） COMPANYADDRESS VARCHAR2 FAMILYADDRESS EMAIL POSTADDRESS POSTCODE FOX LANGUAGE ACCMILE ACCTIMES ACCMONEY GUESTTYPE VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER NUMBER VARCHAR2 旅客类别（注册旅客/未 信息录入点 24 25 26 27 28 RECORDPONITID OPTERATOR OPTERATETIME R1 R2 VARCHAR2 VARCHAR2 DATE VARCHAR2 VARCHAR2 100 100 7 500 500 Y Y Y Y Y 修改人（ID） 修改时间 备注1 备注2 在系统概要设计完成之后，开发单位与用户单位协商，决定采用托管方式托管剩余座位系统。由用户单位的信息中心负责与托管服务提供商接洽，确定具体托管方案。系统选型的依据是根据用户单位认为一两年内剩余座位系统的日点击率在1000次左右，今后也不会超过万次。开发单位将有关剩余座位系统硬件结构及软硬件需求发给用户单位，由用户单位根据实际情况选购相关所需软硬件。

5、系统实施及运行维护

开发单位在系统分析和设计完成之后，利用系统的原型作为系统的用户界面设计，迅速开发了系统。在系统编程的同时，完成了测试计划的设计。计划进行单元测试、集成测试、验收测试和系统测试。其中单元测试涉及系统的四个主要模块：航线剩余座供应信息管理、

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库A航空公司剩余客票销售系统的开发 - 案例及案例分析 - 图文(2)在线全文阅读。