1、案例案例 1 1： A A 航空公司剩余客票销售系统的开发航空公司剩余客票销售系统的开发 一、 案例内容 1、系统背景 我国的航空业目前正在进行着其历史上最重大的变革,市场环境巨大的变化使得航空 业目前竞争的激烈程度前所未有。一方面，民营低成本航空公司进入市场，并占有相当一部 分市场份额。2004 年,春秋、奥凯和鹰联获批准成为国内首批 3 家民营航空公司,这些民营 航空公司已低成本的策略，很快的占有了相当部分的市场份额，它们的口号是“让更多普通 大众坐得起飞机,让乘飞机旅游进入千家万户” 。特别是春秋航空公司推出的 1 元、99 元、 199 元的超低票价,对原有国有航空公司垄断的航空市场产
2、生了巨大的冲击。另一方面，高 铁的迅猛的规划和建设也对航空市场造成了较大的冲击。2009 年 4 月，石太高速铁路开通 运营，A 航空公司公司的北京-太原航线 5、6 月份客座率出现显著下降。从 A 航空公司北京 -太原航线与其国内航线平均客座率水平来看，半年之内，石太高铁影响 A 航空公司北京- 太原航线客座率下降 5 个百分点左右，分流客源 8%左右。 尽管市场和需求产生了激烈的变化，全球航空公司依然按照两类旅客商务型旅客 和经济型旅客来制定营运策略。 为商务型旅客提供可以退改签的全价机票， 而为经济型旅客 提供低价机票。现在，选择经济型航空产品的旅客比率比以前上升了。价格敏感程度的增加
3、使得航空公司的年平均收入下降， 并使得市场的供应能力严重过剩。 这些因素加剧了航空市 场的竞争。 早在 20 世纪 90 年代后期国内的民航业就已经卷入了“价格大战”，而当时 A 航空公司 就已经暴露出了其经营上的一些问题。 在国际航线上， A 航空公司无法与国外经营对手相匹 敌，在国内又没有能力与那些灵活的中小航空公司及航空联合体抢占市场。在这种情况下， A 航空公司寄希望于增加飞机数量、扩大运输规模，以扩大自己的市场份额。然而，盲目的 增加运力并没有使得 A 航空公司的生存环境得到多少改变，反而使得供过于求的现象更加 剧烈，剩余机票居高不下，运力浪费严重。 一些国内航空公司采用了多种方法来
4、处理剩余机票。例如，在消费淡季，提前 60 天订 票可以买到一折票，提前 45 天可以买到三折票，提前 30 天可以买到五折票。由于低于 5 折的机票不允许机票的退改签， 所以这种折扣票对于时间充足价格敏感的休闲客人有相当的 吸引力， 他们在购买机票后一般不会出现行程变更的情况。 不过这种方法也没有完全排斥商 务客人，很多商务客人的某些行程可以提前确定，所以他们也可以购买这类折扣票。而航空 公司是不希望商务客人购买这类折扣票的。 2005 年-2006 间，A 航空公司面临的困境主要来自两方面：1）自身的运力过剩和 2） 民营航空公司的市场瓜分。面对如此困境，A 航空公司希望能够在减少剩余票的
5、同时开发新 的客源，于是 A 航空公司 B 分公司以航空客运的收益管理为理论基础，在对机票目标消费 者市场进行细分的基础上，推出了特殊的折扣机票产品“超值天下” 。 这是 A 航空公司 B 分公司实施航空收益管理的一次重要的探讨和实践。 “超值天下”就是通过低价销售航班的 剩余座位，提高航班客座率，而为 A 航空公司创造最大收益。 2、系统立项 “超值天下” 系统是 A 航空公司 B 分公司向 C 公司定制的航空商务信息系统， 是主要针 对时间充裕的探亲、 休闲旅游旅客群体的市场需求而推出的产品， 其目标顾客是对价格敏感， 但对出行时间不太敏感的旅客（有别于商务旅客、公务旅客和一般有计划的旅游
6、团体） 。它 是 A 航空公司 B 分公司全面实行收益管理的产物， 其目的是在正常销售渠道之外， 将航班的 剩余座位以较低的价格进行销售， 从而在现有市场客源基础之上， 充分利用价格对市场的调 控作用，开发航空旅客客源，提高航班销售收入。 “超值天下”系统是一个基于信息化的管理创新项目，提供超低价剩余机票的销售，其 目的是在自己可以掌控的情况下在合适的时间， 将合适的机票卖给合适的旅客， 尽可能减少 剩余机票的数量，在抢占市场的同时实现利润最大化。 “超值天下”系统中提供的机票，票 价一般低于五折，但是有较为严格的限制条件，旅客预定出行的时间必须为一个时间段（3 5 天） ，而不能为指定的某一
7、个航班或某一天的航班，由“超值天下”系统根据航班订票 的整体情况对旅客的雏形请求进行匹配， 匹配成功后通知旅客， 旅客有权选择是否接受匹配 结果，但旅客一旦接受匹配结果，此不定期客票“不得退票、不得转签” （不含非自愿退票 及签转） 。为了区分商务客人和休闲客人，A 航空公司 B 分公司市场部的想法是旅客订票时 只允许旅客指定欲购机票的一个时间段，不能指定具体日期和航班（比如，只能说明想购买 的机票是 5 月 4 号到 7 号武汉到北京的机票） 。旅客订票时看到的机票信息也是某一个时间 段某个航线的折扣票信息（例如，5 月 1 号到 3 号武汉到三亚的折扣机票为一折到五折的折 扣机票） 。航线
8、经理负责决定各航线的剩余客票的折扣和张数，计算机系统将旅客的订票申 请和航线的剩余客票做匹配， 如果匹配成功， 询问旅客是否愿意按照匹配的日期和航班出行。 旅客愿意就出票， 旅客不愿意就将机票放入剩余客票库里继续参加匹配。 这种剩余客票的销 售方法针对的就是时间充足价格敏感的休闲客人。 A 航空公司 B 分公司了解到 C 公司开发过成功的信息系统，邀请 C 公司的负责人和技 术骨干到 A 航空公司 B 分公司和公司负责人、市场部经理和市场部技术骨干一起开了一个 会，双方相互介绍了基本情况。双方讨论的结果，准备系统只提供剩余客票的匹配，如果匹 配成功，由呼叫中心负责和用户联系，确认是否愿意并记录
9、用户的答复；由于当时国内电子 商务的支付手段还不够完善， 大众对通过网络付款这种方式缺乏信任， 双方决定放弃网上支 付机票款；如果旅客同意购买匹配成功的折扣机票，可以到 A 航空公司的售票处付款。沟 通之后，开发单位觉得用户的目的可以通过开发系统实现。双方决定这个项目由 C 公司开 发，用户单位的计算机中心监督和辅助开发过程。 初步拟定的系统的大体框架如图 1。 图 1 系统功能图 A 航空公司航空公司武汉公司商务系统武汉公司商务系统 航 班 数 据 报表 销 售 分析 剩 余 座 位 销 售 管理 代 理 人 管 理 信 息 管理 数 据 录入 系 统 管理 基 础 数 据 处理 接口 IC
10、S CRS FOC 3、系统分析 C 公司很快拿出了大体方案，准备在 6 个月内完成系统开发。A 航空公司 B 分公司审 查通过后，双方签订了合同。开发单位派出了技术骨干到 A 航空公司 B 分公司进一步调研， 了解到一般民航旅客的订票信息存储在中国民航信息网络股份有限公司的 PNR（旅客订座 记录）系统里，如果剩余客票项目的匹配成功的订座信息直接与 PNR 对接，需要中航信正 式授权交费的配置。既然剩余客票项目准备付款在 A 航空公司的售票处进行，那么旅客订 座信息也可以在付款同时由售票处输入。 所以项目的基本任务就是开发一个平台， 允许航线 经理通过系统放出折扣票；旅游可以通过系统了解、申
11、请购买折扣票；呼叫中心从系统中了 解匹配成功的旅客信息，通知他们，将他们的反馈（是否购买匹配成功的航班机票）记录下 来；各售票处查询系统匹配信息，收取匹配成功的旅客机票款，将旅客订座信息输入 PNR 系统。 开发单位采用了开会、个别访问和调查提纲等方式进行调研。其调查提纲如表 1。 表 1 调查提纲 调查提纲 1. 本部门的主要职能是什么？ 2. 本部门的组织结构图是怎样的？各岗位的名称及职责是什么？ 3. 本部门的工作岗位及其各自的工作任务是什么？ 4. 本部门的考核指标和工作目标是什么？ 5. 本部门工作流程是怎么样的？ 6. 本部门通常需要制订哪些计划？ 7. 本部门的工作中经常要到哪些
12、单据、 台帐、 统计报表、 工作文件、 工作标准、 管理标准？ 8. 本部门用到的哪些单据、 台帐、 统计报表、 工作文件、 工作标准、 管理标准可能会修改？ 9. 本部门经常需要向领导提供哪些统计数据？ 10. 哪些统计指标更能反映本部门工作情况？ 11. 本部门中存在哪些问题？现在如何解决这些问题的？希望如何解决这些问题？ 12. 本部门哪些工作需要改进？有什么建议？ 13. 为做好本部门工作，应该搜集哪些外部信息？ 14. 本部门计算机应用情况是怎么样的？本部门员工的计算机应用水平如何？ 15. 本部门对新系统的可用性期望及要求是什么？ 开发单位理解的系统流程如图 2。 开发单位详细调查
13、了解了有关旅客订票的相关资料，A 航空公司 B 分公司提供了 PNR 使用手册、机场三字码、市场部相关岗位的职能说明等等。开发单位在消化资料后又与用户 单位进行了沟通和确认。为了让用户更快地了解和确认系统，开发单位迅速地用 frontpage 开发了一个系统原型， 这里页面显示都是开发单位按照自己对系统的理解虚拟的数据， 如图 3。 旅客预订旅客预订 查看航段信息 确定时段，航 段，填写人数 填写完整订单， 提交 旅客注册旅客注册 填写个人信息 航线经理发布供应信息航线经理发布供应信息 根据预测提供航 班供应信息 通知旅客通知旅客 CallCenter通知 旅客在网上自己 操作 订单匹配订单匹
14、配 自动匹配 设定时间，系统 自动匹配 手工匹配 核查员手工指定 匹配结果 旅客接受的匹配 结果可以出票 被旅客拒绝的匹 配结果作废 出票出票 旅客在直属售票 处出票 超过时限仍未出 票，该匹配结果 作废 旅客接受的订单 才可以出票 核查员控制整个业务流程核查员控制整个业务流程，包括对旅客的管理包括对旅客的管理，对订单的管理对订单的管理，对匹配结果的管理和维护基础信息对匹配结果的管理和维护基础信息 系统管理员负责对内部业务用户管理系统管理员负责对内部业务用户管理，权限分配权限分配 图 2 系统流程 图 3 系统首页 旅客登陆后可以预定查询机票如图 4。 图 4 旅客订座页面 航线经理登陆后可以
15、录入和修改折扣机票信息、 查询当前需求信息和匹配信息以及统计 分析如图 5。 图 5 航线经理放票的页面 呼叫中心的可以查询旅客的预定和匹配信息， 以及匹配成功后旅客的答复， 如图 6 所示。 图 6 呼叫中心查询匹配成功的旅客的信息 售票处可以查询旅客的预定记录和匹配是否成功的信息，如图 7 所示。 图 7 售票处查询页面 开发单位原来准备将系统原型的制作交给网页制作公司， 在了解市场行情之后， 开发单 位犹豫了。 考虑到让网页制作公司理解系统的困难和经费问题， 开发单位最终决定自己制作 系统原型。用户单位在组织技术骨干和具体操作人员反复使用原型之后，提出了不少意见。 其中既有增加系统核查员
16、这一角色这样的重大功能改变， 也有题头飞机是麦道而用户单位没 有麦道飞机这样的形式改变。 开发单位马上根据用户意见对系统原型进行了修改， 并要求用 户单位对系统原型同意签字后再进行下一步开发工作。 开发单位研究后决定， 采用.NET 技术， 开发基于 B/S 的系统， 数据库采用 SQL SERVER。 在和用户单位进一步协商后， 用户单位为了限制商务型旅客通过该系统订票， 细化了一 些限制因素： 1）退签、签转、更改航程航班的限制 通过本系统购买机票的旅客，无法无条件的退票、签转或者更改航程航班。此条件可 以某种程度上限制时间、服务敏感的商务旅客。 2）服务等级限制 通过本系统购买机票的旅客
17、，是无法享受与高票价旅客同等的各种服务的。在某些大 型商务公司，相对于高等级舱位所代表的身份象征时，所谓的价格影响可以说微乎其微。 3）提前订票限制 通过本系统订票的旅客，必须提前三天或者三天以上订票。该限制结合退改签的限制， 可以限制紧急出行的旅客通过该系统订票。 一方面， 紧急出行的旅客不能提前确定自己的出 行需求，另一方面，紧急出行的时候，时间是一个主要的决策依据，相对来说价格可能并没 有那么的重要。 4）出行日期限制 通过本系统订票的旅客，在订票时，只能指定出行的日期范围，而不能指定具体的某 一日期，提交订票请求后，具体的日期由系统根据旅客指定的日期范围来安排。对于商务旅 客来说，时间
18、就是效益，每次出行的日期都是确定的，他们不会希望由系统随机地为他们安 排出行日期，可能会导致损失很重要的商务会谈。而相对可能的损失来说，机票的价格实在 算不上什么。 5）出行航班限制 通过本系统订票的旅客，在订票时，只能指定出发城市和目的城市，不能指定具体的某 趟航班。 具体的航班由系统或者航线经理根据各趟航班的售票情况来决定， 该限制条件一方 面使得航空公司可以灵活调节各航班的剩余座位数， 另一方面也限制了那些对出行时间要求 非常高的商务出行需求和紧急出行需求。 用户提交的订单和航线经理放出的折扣机票如何匹配？由于这一流程过去没有先例， 用 户单位内部反复讨论后提出了“申请时间优先、会员优先
19、级优先、人数优先”原理： “申请时间优先”不论是网上预订还是电话预订，按照提出申请的时间，谁提出申请的 时间早，优先匹配。 “会员优先级优先”主要是针对会员的网上预订，按照会员积分的高低，积分高的为优 先级，优先匹配。 “人数优先”是按照一次预订机票的数量，数量越大的，优先匹配。 4、系统设计 （一）功能设计（一）功能设计 基于上述系统分析结果，开发单位提出了系统的几个功能： 1） 注册管理 提供免费注册功能，要求注册时提供用户名、密码、真实姓名、身份信息和联系方式。 注册时所用的用户名和密码是用户以后预定机票的入口信息。 2） 航线经理放票管理 航线经理需要先录入和维护航线基本信息，然后根据
20、情况决定某个时段的各航班的折 扣票数和折扣大小。 航线经理也可以查询当前的折扣票申请情况和匹配情况。 还提供统计分 析能力，分析总折扣票数、已匹配成功的折扣票数和剩余折扣票数。 3） 预订管理 顾客可以下订单预定某一时段某一航线的折扣票， 在顾客预定时需要确认顾客了解剩余 客票不可退改签的规定。也允许顾客查询和修改自己的订单。 4） 机票匹配 系统每天定时自动进行折扣票与预定申请的匹配。 5） 呼叫中心通知管理呼叫中心通知管理 呼叫中心每天根据匹配成功的结果通知顾客。 如果顾客同意按匹配的时间和航班出票， 记录当前时间，要求顾客在 24 小时内到营业部交款出票；如果顾客不同意按匹配时间和航 班
21、出票，则将这张票重新放入剩余客票票库，继续参加匹配。呼叫中心也可以查询待通知客 户的相关信息。 6） 出票管理出票管理 营业部可以根据订单号或身份证号查询匹配相关信息，如果匹配成功，在顾客交款后可 以出票。 7） 核查员管理核查员管理 核查员是具有最高权限的管理者，可以了解航线经理放票的情况、顾客相关信息以及匹 配的结果。 （二）（二） 数据库设计数据库设计 系统中有旅客、航线经理、售票处、呼叫中心和核查员多种用户，每类用户的操作权限 不同，所需的基本信息也不同。所以，系统中设计了一个用户基本信息表，用来记录所有用 户的基本信息，包括用户 ID、账户、密码、用户类型之类的用户最基本的信息；另外
22、设计 了一个旅客表存储旅客的基本信息，一个内部操作人员表存储 航线经理、售票处、呼叫中 心和核查员等内部人员的基本信息。 考虑到旅客持有的证件不同， 没有采用身份证号作为旅 客表的关键字。同时，考虑到后期可能的修改，在各个表中都预留了两个多余字段，如表 2-表 4。 表 2 用户基本信息表 T_U_User 序号序号 列名列名 数据类型数据类型 长度长度 小数小数 K K NULLNULL 默认默认 字段说明字段说明 1 ID VARCHAR2 100 N 用户 ID 2 ACCOUNT VARCHAR2 50 Y 帐号 3 PASSWORD VARCHAR2 10 Y 密码 4 QUESTI
23、ON VARCHAR2 100 Y 密码问题 5 ANSWER VARCHAR2 200 Y 密码问题答案 6 LASTLOGINTIME DATE 7 Y 最后登陆时间 7 LASTIP VARCHAR2 20 Y 最后登陆 IP 8 ACCLOGINTIMES NUMBER 10 0 Y 累计使用次数 9 UTID VARCHAR2 100 Y 用户类型 ID（表 T_U_UserType 用户类型） 10 EFFECTIVESTATU S VARCHAR2 2 Y Y/N 用户状态，是否有效 11 OPTERATOR VARCHAR2 100 Y 修改人（ID） 12 OPTERATET
24、IME DATE 7 Y 修改时间 13 R1 VARCHAR2 500 Y 备注 1 14 R2 VARCHAR2 500 Y 备注 2 表 3 用户类型表 T_U_UserType 序号序号 列名列名 数据类型数据类型 长度长度 小数小数 PKPK NULLNULL 默认默认 字段说明字段说明 1 UTID VARCHAR2 100 N 用户类型 ID 2 USERTYPENAME VARCHAR2 20 Y 用户类型名称（旅 客、大客户、航线经理、 销售中心、呼叫中心、 核查员、系统管理员） 3 TABLENAME VARCHAR2 100 Y 表名 4 OPTERATOR VARCHA
25、R2 100 Y 修改人（ID） 5 OPTERATETIME DATE 7 Y 修改时间 6 R1 VARCHAR2 100 Y 备注 1 7 R2 VARCHAR2 100 Y 备注 2 表 4 旅客基本信息表 T_U_Guest 序号序号 列名列名 数据类型数据类型 长度长度 小数小数 K K NULLNULL 默认默认 字段说明字段说明 1 ID VARCHAR2 100 N 用户 ID 2 CNNAME VARCHAR2 20 Y 中文姓名 3 FIRSTNAME VARCHAR2 20 Y First Name 4 MIDDLENAME VARCHAR2 20 Y Middle N
26、ame 5 LASTNAME VARCHAR2 20 Y Last Name 6 TITLE VARCHAR2 20 Y 旅客称谓 7 GUESTLEVEL VARCHAR2 20 Y 客户级别 8 BIRTHDAY DATE 7 Y 生日 9 CARDNUM VARCHAR2 20 Y 会员卡号 10 IDTYPE VARCHAR2 20 Y 证件类型 11 IDTYPENUM VARCHAR2 30 Y 证件号码 12 SEX VARCHAR2 1 Y 客户性别 13 COMPANYADDRESS VARCHAR2 200 Y 单位地址 14 FAMILYADDRESS VARCHAR2
27、200 Y 家庭地址 15 EMAIL VARCHAR2 50 Y 电子邮件 16 POSTADDRESS VARCHAR2 200 Y 邮件地址 17 POSTCODE VARCHAR2 20 Y 邮编 18 FOX VARCHAR2 50 Y 传真号码 19 LANGUAGE VARCHAR2 20 Y 联系语言 20 ACCMILE NUMBER 10 0 Y 累计里程 21 ACCTIMES NUMBER 10 0 Y 累计次数 22 ACCMONEY NUMBER 10 0 Y 累计金额 23 GUESTTYPE VARCHAR2 50 Y 旅客类别（注册旅客/未 注册但成行） 24
28、 RECORDPONITID VARCHAR2 100 Y 信息录入点 25 OPTERATOR VARCHAR2 100 Y 修改人（ID） 26 OPTERATETIME DATE 7 Y 修改时间 27 R1 VARCHAR2 500 Y 备注 1 28 R2 VARCHAR2 500 Y 备注 2 在系统概要设计完成之后，开发单位与用户单位协商，决定采用托管方式托管剩余座 位系统。由用户单位的信息中心负责与托管服务提供商接洽，确定具体托管方案。系统选型 的依据是根据用户单位认为一两年内剩余座位系统的日点击率在 1000 次左右，今后也不会 超过万次。 开发单位将有关剩余座位系统硬件结构
29、及软硬件需求发给用户单位， 由用户单位 根据实际情况选购相关所需软硬件。 5、系统实施及运行维护 开发单位在系统分析和设计完成之后， 利用系统的原型作为系统的用户界面设计， 迅速 开发了系统。在系统编程的同时，完成了测试计划的设计。计划进行单元测试、集成测试、 验收测试和系统测试。其中单元测试涉及系统的四个主要模块：航线剩余座供应信息管理、 客户订票信息管理、机票匹配管理、出票管理。部分采用白盒测试的方法。集成测试及以后 的阶段，主要采用黑盒测试的方法。集成测试包括接口测试、数据和数据库完整性测试、用 户界面测试等；验收测试包括功能测试、性能测试和容量测试；系统测试包括安全性和访问 控制测试、
30、负载测试、强度测试、故障转移和恢复测试。 测试完成后， 开发单位迅速写出了用户操作手册， 并对用户单位的相关人员进行了培训。 “超值天下”系统是全国首个剩余票销售系统，系统中旅客的需求特性及订票行为，在 一定程度上反映了航空旅客对折扣票的态度和行为。对系统中旅客需求及订票行为的研究， 不仅能够为 A 航空公司 B 分公司进一步采取措施提供决策依据，同时也为其它航空公司处 理剩余票，甚至是制定折扣票策略提供了良好的参考依据。 “超值天下”系统于 2006 年 12 月底完成开发及试运行，并通过内部通知，开始投入试 运行。截止 2007 年 6 月停止使用前，通过该系统订票的订单人数达到八千多，成
31、功售出的 机票数目也有四千多， “超值天下”系统为 A 航空公司 B 分公司创造了不小的收益。 “超 值天下” 系统最终被叫停， 是由于用户单位发现有购买剩余客票的旅客中有数量不少的商务 客人。在系统被叫停之后，开发单位对销售数据进行了分析，发现有相当数量的订单是重复 订单， 也就是说一些商务旅客为了购买理想日期和航班的机票， 采用了多次下一样的订单的 方法。由于该系统没有真正对外推出，所以订单数并不多，这样同一旅客的多个订单可能都 能匹配成功， 客人就可以放弃不理想的日期或航班的匹配， 而选择比较理想的匹配结果出票。 二、案例问题 1、剩余客票销售系统是如何立项的？ 2、采用原型法开发剩余客
32、票销售系统有什么好处？ 3、剩余客票销售系统的概要设计是如何进行的？ 4、剩余客票销售系统的开发过程存在哪些问题？ 三、案例点评 1、剩余客票销售系统是如何立项的？ 由于 A 航剩余机票居高不下，运力浪费严重，希望通过信息技术提供一种面向休闲客 人的客票销售方式，更好地需要解决剩余客票问题。为了区分商务客人和休闲客人，A 航空 公司 B 分公司市场部的想法是旅客订票时只允许旅客指定欲购机票的一个时间段，不能指 定具体日期和航班。旅客订票时看到的机票信息也是某一个时间段某个航线的折扣票信息。 航线经理负责决定各航线的剩余客票的折扣和张数， 计算机系统将旅客的订票申请和航线的 剩余客票做匹配，如果
33、匹配成功，询问旅客是否愿意按照匹配的日期和航班出行。旅客愿意 就出票，旅客不愿意就将机票放入剩余客票库里继续参加匹配。 在与开发单位沟通和开发单位对用户需求做了初步调查分析之后， 双方感觉该想法可以 用计算机系统实现，并且应该尽快开发。 2、采用原型法开发剩余客票销售系统有什么好处？ 1）增进用户与开发人员之间的沟通 传统的开发方法中， 客户主要靠阅读大量的文件了解系统， 然后向系统分析员表达他们 对系统需求的意见。原型法展示给用户的是可以实际运行的原型系统，用户“看得见，摸得 着“，可以很清楚地把他们的意见告诉给系统分析员。 2）用户在系统开发过程中起主导作用 结构化方法强调了面向用户的观点
34、，但用户参与较多的是系统分析阶段。而采用原型 法进行系统开发，用户在整个开发过程中起主导作用，随时提供现场的第一手资料，帮助开 发者认识用户的真正需求。 3）辨认动态的用户需求 我们知道，系统分析的困难之一是用户与开发者之间的沟通，尤其对一些动态需求，不 容易用语言文字来描述。 可以实际运行的系统原型有助于开发者发掘和验证这类不易用一般 语言来规范交谈的动态需求。 4）启迪衍生式的用户需求 在系统投人运行之前，有些功能用户也无法预先知道。复印机刚发明时，人们曾认为其 功能只是代替复写纸，在 使用实践中才认识到远非如此，复印机才得以有今天这么广泛的 应用。信息系统也有类似情况。衍生式的需求是指当
35、系统投入运行之后，用户有了使用经验 而提出的 需要。在整个开发过程中，原型系统可以启发用户的这些衍生的新需求，并把这 些需求告诉开发者。决策支持系统就常有这类需求，适合用原型法进行开发。 5）缩短开发周期，降低开发风险 原型法以用户为主导，更有效地辨认用户需求，不仅使系统分析的时间大为缩短，而且 减少了开发人员对用户需求的误解，从而降低了系统开发的风险。 3、剩余客票销售系统的概要设计是如何进行的？ 在充分进行了用户需求调查的基础上，通过与用户充分沟通，用 Frontpage 开发了 一个系统原型，给用户演示，项目组多次开会研究，确定了系统的功能、接口、数据库管理 系统、和用户界面等。 4、剩余客票销售系统的开发过程存在哪些问题？ 1）项目组对航空领域的专业知识不熟悉，花了很多时间去了解航空的基本知识，但还 是出了一点问题：如题头飞机是麦道而用户单位没有麦道飞机。 2）用户单位对于剩余客票销售的新流程还缺乏认识，所以系统边开发，边再造流程。 比如机票匹配准则就是后来在系统分析阶段才确定的。 3）系统最终被放弃，是由于项目组在系统设计过程中没有考虑的顾客重复购票的可能 性，导致系统出现了漏洞，造成顾客实际上可以选择他需要的航班出行，违背了面向休闲客 人的出发点。
