摘要本文是笔者软件工程与方法课的课程作业，从中国网约车行业的发展历程及市场现状出发，立足于当下市场需求，以期设计一款具有市场竞争力的打车软件。本文首先对打车软件进行需求分析，然后采用SA方法及DFD描述工具进行系统建模，最后给出相应的设计方案。文章中的打车软件系统架构图、系统部署图、功能架构图、数据流图、E-R图均发布在ProcessOn模板社区，欢迎有需要的同学克隆使用！

关键词：打车软件；系统分析；设计方案；SA；DFD

1 引言

随着移动互联网的发展，各行各业纷纷进行升级转型。在传统出租车行业，由于司机绕路、拒载等行为普遍存在，“打车难”、“打车贵”等问题层出不穷。因此，针对这些痛点，打车软件应运而生。打车软件，又称网约车平台，是指以互联网技术为依托构建的服务平台，通过接入符合条件的车辆和驾驶员，整合供需信息，提供非巡游的预约出租汽车服务[1]。

本文的主要工作是完成打车软件的分析与设计。为设计一款具有市场竞争力的打车软件，有必要了解当前的市场环境，因此本文首先回顾中国网约车行业的发展历程，并对网约车市场现状加以分析。

1.1 中国网约车行业发展历程

图 1 中国网约车行业发展历程[2]

根据易观的《2019中国网约车市场分析报告》[2]，中国网约车行业的发展大致分为四个阶段：探索期（2010-2015）、市场启动期（2015-2016）、高速发展期（2017-2024）以及应用成熟期（2025-），如图 1所示。

在探索期，网约车平台逐渐兴起：2010年，易到用车上线；2012年，滴滴打车和快的打车上线；2014年，Uber进入中国，同年，嘀嗒拼车成立；2015年，神州租车推出神州专车业务。

2015-2016两年间，网约车行业进入竞争激烈的市场启动期。在这一阶段，发生了两次重大的合并事件：一是滴滴打车和快的打车宣布合并，市场完成初步洗牌；二是滴滴在合并之后又将Uber中国收入囊中，市场进入寡头化。另一方面，传统车企和租赁公司也开始向网约车市场进军，首汽集团的首汽约车、吉利集团的曹操专车于2015年先后上线。

2016年7月，《网络预约出租汽车经营服务管理暂行办法》颁布，网约车的合法地位得以肯定。此后，网约车行业进入高速发展期。随着美团打车、高德地图以及汽车主机厂的纷纷入局，网约车市场的竞争持续加剧。

1.2 中国网约车市场现状分析

目前，中国移动出行市场规模快速增长，移动出行用户将近5亿人，汽车出行市场容量达3800亿元[3]。网约车服务品牌和业务模式大致分为三类：一类是C2C模式的互联网平台，如滴滴出行、嘀嗒出行；一类是B2C模式的车企和租赁公司，车企如上汽投资的享道出行、广汽投资的如祺出行、吉利的曹操出行及三大央企（长安、一汽、东风）投资的T3出行；租赁公司如首汽约车、神州专车等。此外，最近兴起的一类是B2B2C模式的互联网聚合平台，以高德和美团为代表，又被称为“平台之上的平台”，方便用户一键呼叫多个第三方平台的网约车服务。

整体而言，当前的中国网约车市场呈现“一超多强”的竞争格局。滴滴出行占据大部分市场份额，截至2018年12月31日，滴滴出行app安装渗透率达14.71%，是位列第二的神州专车的10倍以上[4]。滴滴的商业模式属于“纯平台”模式，这种模式轻量化运营、用户和数据变现前景可期，但具有较高的进入壁垒。而且由于政府对平台的监管趋严、合规压力大，运力短缺问题短期内将持续困扰“纯平台”企业[5]。在这种前有围堵（滴滴）后有追兵（合规政策）的局势下，若无颠覆性的技术和极端的政治因素出现，“纯平台”模式很难再出现有威胁的新企业。

相较“纯平台”模式，“平台+运力”模式尚有机会进入网约车市场分一杯羹。“平台+运力”的网约车公司背靠具有区域优势的租赁公司、整车厂等，受到当地政府的支持，合规化程度较高，投入相对较少，能够在盈利性和运力保障间寻求平衡。

另外，从长期来看，网约车市场整体需求将持续高涨。一是随着疫情的好转，企业相继复工，出行市场逐渐复苏，网约车市场用户规模将会恢复性增长[6]；二是随着城镇化水平提升，经济持续发展，基础设施持续完善，中国未来城镇居民出行需求将持续增长；三是由于私家车的限购及征收拥堵税，随着移动共享出行的日益成熟，共享出行将受到更多消费者的青睐。

因此，在需求旺盛且有待开垦的二线城市，“平台+运力”模式的网约车企业仍具有一定的发展空间。下文将以这样的企业为业务方，完成打车软件的系统分析与方案设计。

2 打车软件系统分析

本节将从需求分析、系统模型两方面对打车软件进行系统分析。

2.1 需求分析

需求分析主要可分为业务需求、用户需求、功能性需求、以及非功能性需求四方面。

2.1.1 业务需求

打车软件的业务需求是：为乘客提供便捷、舒适、安全的出行服务，为司机提供公平、透明、可靠的接单途径，从而提高乘客用户与司机用户的留存率，通过合作提点、推介佣金、广告植入、广告推送、积分换购[7]等方式，实现盈利创收的目的。

2.1.2 用户需求

打车软件的主要服务对象是乘客、司机两种角色，不同的角色对系统的需求是不同的。下面分别对这两种角色的用户需求加以分析。

2.1.2.1 乘客用户需求

打车难、安全焦虑[8]、体验差等问题仍是网约车及出租车服务面临的主要问题。虽然相比于传统的扬招打车，网约车在一定程度上解决了一些问题，但对于问题的最终解决仍有很长的路要走。不久前J.D. Power发布的中国网约车服务质量研究[3]显示，网约车行业整体PP100（每百用户抱怨数）偏高，行业平均PP100高达575，即每个用户平均抱怨5.75个问题。用户抱怨主要集中在平台效率方面，叫车过程中的PP100高达166。根据统计数据，“守时”和“高效”对于网约车平台用户留存至关重要：如果接单响应时间超过5分钟，41%的乘客用户会选择取消订单或更换平台叫车；若接单司机与乘客的距离超过10分钟路程，50%的乘客用户会选择取消该订单。此外，地图相关问题也用户抱怨较多。

上述研究通过对不同品牌和区域网约车用户进行访谈和调研，重点考察了乘客用户在打车过程的6大环节（叫车过程、上车过程、乘坐体验、下车过程、支付和管理以及安全体验）遇到的问题，能够较为全面地反映乘客用户需求。基于此，现将打车软件的乘客用户需求总结如表 1：

表 1 打车软件的乘客用户需求

序号	用户故事	需求描述	优先级
1	公司或住所位置偏僻，不好打车。	系统将用户的打车信息推送给一定数量的司机，增加用户成功打到车的机会；提供预约打车功能，使司机提前明确接送任务，保证乘客能打上车。	P0
2	雨雪天气或早晚高峰，担心出门拦不到车，耽误行程。	系统提供加价功能，激励司机接单，增大司机与乘客相互选择的空间；确实受天气或交通等客观因素限制时，系统提供其他出行方式的建议和参考。	P0
3	线下打车不划算。	系统提供顺风车、拼车功能，设立优惠券、鼓励金、积分减免等活动。	P1
4	出租车车型舒适度不够。	系统提供专车打车功能。	P2
5	携带宠物出行。	系统提供携宠打车功能。	P2
6	携带较多货物出行。	系统提供同城送货、城际送货功能。	P2
7	老弱病残孕人士出行有特殊需求。	系统提供爱心打车、无障碍打车功能。	P2
8	加班到深夜，去偏远地区，担心打车不安全。	系统提供证照信息公示、一键报警功能，保障乘车安全，增加乘客安全感。	P0
9	去外地出差或旅游，不熟悉路线，担心司机绕远，费用高。	系统提供高精度的地图导航，提供即时计费、评价反馈功能，建立诚信机制。	P0
10	平台派单时间过长，预计接单时间不准，实际等待时间比预计接单时间长很多，甚至没有司机接单。	系统提供更完善的时间预测算法和司机派单算法；在叫不到车等待时，向乘客显示等待时间、等待人次、排位顺序信息；若超出平台规定最长派单时间，提供合理的减免优惠。	P0
11	看到附近有空车打不到，接单司机距离太远，接单接驾时间长。	系统提供更完善的司机派单算法，降低“近单远接”的概率；做到车辆状态信息透明化，明确地向乘客展示车辆处于空驶或是已接单状态。	P0
12	联系接单司机浪费时间：司机接单后不主动联系，只有车辆到达地点后找不到人才联系，甚至找不到人也不联系，要不在地点等候，要不在周围绕圈（不方便停车的地方）。	系统提供通知功能，在司机接单后自动向用户发送消息告知接单司机及车辆相关信息。	P0
13	车辆到达上车点和实际位置有出入，到达上车点时间不准，导航路线不合理，预计到达目的地时间不准，到达目的地位置不准。	与高质量的地图服务第三方合作，提供更精准的地图服务。	P0
14	对司机服务或车辆不满意。	系统提供评价反馈功能。	P0
15	个人物品落在车内。	通过系统的对话功能联系行程司机。	P0

2.1.2.2 司机用户需求

打车软件的司机用户需求与乘客用户需求之间存在关联，现将司机用户需求总结如表 2：

表 2 打车软件的司机用户需求

序号	用户故事	需求描述	优先级
1	不愿意去偏远地区接单：路程远，时间长，而且途中接不到其他单。	系统提供加价功能，激励司机接单；提供预约打车功能，使司机提前明确接送任务。	P0
2	深夜接单前往偏远地区，担心不安全。	系统提供一键报警功能，保障司机安全。	P0
3	看见附近有乘客想打车，但接不到单；系统分配的乘客距离太远，接单中途被取消订单。	系统提供更完善的派单算法，降低“近单远接”的概率。	P0
4	特殊原因暂时不方便接单（如手机即将没电）。	系统提供拒单功能，并向乘客发送拒单原因，便于司乘之间的双向选择。	P0
5	接单到地点找不到乘客。	系统提供对话功能，方便联系乘客。	P0
6	对乘客行为或平台不满意。	系统提供评价反馈功能。	P0

2.1.3 功能性需求

基于上述用户需求，本节将打车软件的功能性需求分配至乘客端与司机端。

2.1.3.1 乘客端功能性需求

乘客端主要包括如下功能性需求：

（1）注册登录：乘客使用打车软件进行打车时需要处于登录状态，新用户需要进行注册，可以选择使用手机号码与验证码进行注册，或者使用微信、QQ等第三方账号授权登录。

（2）多样化打车模式：乘客可以选择即时打车或预约打车，其中即时打车的打车模式有快车、专车、顺风车和拼车；预约打车的打车模式有快车、专车、拼车和个性化打车。多样化的打车模式满足更广大用户群体的需求。

（3）开销预算：乘客提交打车请求后，系统会根据乘客的出发地和目的地，估算出需要花费的时间及费用，方便司机与乘客。

（4）空车搜索：乘客可以查看附近车辆状态（空驶/已接单），方便乘客自选车辆打车。

（5）订单管理：乘客可以查看历史订单。在司机接单后，乘客可以查看当前订单详情，了解接单司机的相关信息，包括司机的电话号码，车牌号码、车辆型号、司机评价、司机实时位置等。在行程开始前，乘客可以取消订单。

（6）消息管理：乘客可以接收系统通知及司机消息，可以向司机发送消息进行联系，并且可以查看历史对话记录。

（7）即时计费：在乘客上车后计费开始，乘客可以实时查看当前行车路线导航、里程、时间及费用。

（8）一键报警：如若遇到危险，乘客可以通过一键报警向第三方安全中心求救。

（9）支付：到达目的地后，乘客可以选择支付宝、微信等第三方支付方式进行支付，同时可以选择使用优惠券、会员积分等获得减免。

（10）评价：支付完成后，乘客可以对司机的服务进行评价。

上述需求总结如图 2：

图 2 乘客端功能性需求

2.1.3.2 司机端功能性需求

司机端主要包括如下功能性需求：

（1）注册登录：司机在使用打车软件时需要处于登录状态，新用户需要注册，向系统提交手机号、驾驶证号、本人与车辆合照等信息，审核通过后才能进行接单。

（2）订单管理：司机在收到系统推送的订单时，可以选择接单或拒单。司机选择接单后可以查看当前订单详情，确定乘客的上车地点。另外，司机可以查看历史订单信息，方便对工作量的评估。

（3）乘客搜索：司机可以查看附近请求打车的乘客状态（未上车/已上车），方便司机自找乘客。

（4）行车导航：司机可以根据行车导航出发去接乘客，并且可以通过导航确定从乘客出发地到目的地的合适路线。

（5）消息管理：司机可以接收系统通知，与乘客对话沟通，并可以查看历史对话记录。

（6）一键报警：如若遇到危险，司机可以通过一键报警向第三方安全中心求救。

（7）评价：订单结束后，司机可以对乘客进行评价。

（8）收入查询：司机可以查看载客所收到的报酬，通过绑定银行卡提现。

上述需求总结如图 3：

图 3 司机端功能性需求

2.1.4 非功能性需求

如表 3所示，打车软件不仅要实现用户的基本需求，而且在性能、安全性、软件质量属性等方面有一定的限制要求。

表 3 打车软件的非功能性需求

类型	需求描述
性能需求	业务量：系统满足多用户同时工作，保障同时在线用户数500W人，并发操作100W人的使用要求。
	响应时间：在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。
	精度：地图定位精度误差不超过80米。
	系统容量：满足未来5年业务数据扩展要求。
	资源使用率：CPU占用率<=50%，内存占用率<=50%。
安全性需求	严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。
	提供运行日志管理及安全审计功能，可追踪系统的历史使用情况。
	网络传递数据应经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。
	能经受来自互联网的一般性恶意攻击，如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等，至少90%的攻击需要在10秒内检测到。
软件质量属性	易用性：打车软件面向用户群体广泛，为方便老人使用，要求操作简单，界面美观，用户容易上手，体验良好。
	可靠性：连续运行一周不得出现闪退或程序未响应的情况。
	健壮性：对于运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统能正确地处理回避。
	效率性：尽可能优化通信协议，减少网速对系统的影响。
	兼容性：可运行于安卓系统2.3.0及以上的各个品牌的智能手机上。
	易集成性：要求代码精简、集成度高，易于嵌入美团、高德等互联网聚合平台，有利于后期的发展。
	可扩展性：软件采用模块化设计，接口要标准化，以适应未来功能扩展的需求。
	可测试性：软件开发过程中使用回归测试，交付必须通过100%覆盖的单元测试。
	可维护性：一个模块的最大圈复杂度不超过15。
其他需求	软件需按照公司整体风格进行UI调整、色调调整等。
其他需求	软件需遵守最新法律法规，根据所在地区规定提供相应的服务。

2.2 系统模型

根据上述需求分析，本节采用结构化分析方法（SA, Structure Analysis）中的数据流图（DFD, Data Flow Diagram）定义系统模型。

打车软件的顶层数据流图如图 4，系统以乘客、司机、第三方地图、第三方支付、以及第三方安全中心为边界。

图 4 打车软件顶层数据流图

图 5 打车软件一层数据流图

图 5为打车软件的一层数据流图，将系统拆分为注册登录、搜索、打车、定位导航、开销预算、派单、订单管理、即时计费、消息管理、评价、报警、电子支付及收入查询环节。由于该数据流图线条繁杂，在此不再给出其细化后的二层数据流图及数据文件，下文的功能设计（3.1节）与数据设计小节（3.2节）将对打车软件的功能与数据做进一步设计说明。

3 打车软件设计方案

本节将从功能设计、数据设计、系统架构、系统部署、关键技术五方面介绍打车软件的设计方案。

3.1 功能设计

对比乘客端与司机端的功能性需求发现：乘客端与司机端的很多功能是相似的、甚至相同的。因此，相似或相同的功能可并入一个模块处理。如图 6，最终整个打车软件系统可分为个人信息、打车、定位、订单管理、消息管理五个模块。

图 6 打车软件功能架构

其中，个人信息、定位、订单管理、消息管理模块是乘客端与司机端都拥有的，打车模块是属于乘客端的。各功能点已在2.1.3节进行过描述，在此不再赘述。

3.2 数据设计

本节将从数据库概念设计、数据库逻辑设计、数据库物理设计三方面对系统数据进行设计。

3.2.1 数据库概念设计

打车软件系统的E-R图如图 7所示，可以看到：一个乘客可以预定和支付多个订单，一个司机也可以接收多个订单；但一个司机只能驾驶一辆网约车。另外，司机与乘客之间还存在搭乘、对话及评价关系。

图 7 打车软件系统E-R图

3.2.2 数据库逻辑设计

根据系统模型，本文为打车软件系统设计了8个数据表，包括乘客信息表、司机信息表、乘客位置表、司机位置表、订单记录表、消息记录表、乘客评价记录表、司机评价记录表。各数据表的设计结构如下：

乘客信息表（passenger）：记录乘客端用户的基本信息，乘客用户注册时添加的用户名、密码、姓名、性别、手机号等基本信息都会存入该表中。该表的主键为乘客编号。
司机信息表（driver）：记录司机端用户的基本信息，司机端用户注册时添加的用户名、密码、姓名、性别、手机号、身份证号、驾驶证号等基本信息都会存入该表中。该表的主键为司机编号。
乘客位置表（passenger_location）：记录当前乘客的位置信息，包括位置编号、经度、纬度、当前时刻、乘客编号、乘客状态。该表主键为位置编号。
司机位置表（driver_location）：记录当前司机的位置信息，包括位置编号、经度、纬度、当前时刻、司机编号、司机状态。该表主键为位置编号。
订单记录表（order）：记录每次打车订单的基本信息，包括订单编号、乘客编号、司机编号、起点、终点、打车时间、上车时间等基本信息。该表主键为订单编号。
消息记录表（message）：记录乘客与司机的对话信息，包括消息编号、订单编号、消息发送者编号、消息接收者编号、消息发送时间。该表主键为消息编号。
乘客评价表（passenger_review）：记录司机给乘客的评价信息，包括评价编号、乘客编号、订单编号、评价等级、评价内容、评价人编号、评价时间。该表主键为评价编号。
司机评价表（driver_review）：记录乘客给司机的评价信息，包括评价编号、司机编号、订单编号、评价等级、评价内容、评价人编号、评价时间。该表主键为评价编号。

3.2.3 数据库物理设计

数据库物理设计的工作是具体化设计数据字段名、数据类型及相关约束。上述数据表的物理设计如下：

表 4 乘客信息表（passenger）-与个人信息模块相关

编号	字段	数据类型	备注
1	passengerId	INT(20)	乘客编号PK
2	usr	VARCHAR(50)	用户名
3	psw	VARCHAR(50)	密码
4	name	VARCHAR(50)	姓名
5	sex	VARCHAR(3)	性别
6	idno	VARCHAR(20)	身份证号
7	tel	VARCHAR(11)	手机号

表 5 司机信息表（driver）-与个人信息模块相关

编号	字段	数据类型	备注
1	driverId	INT(20)	司机编号PK
2	usr	VARCHAR(50)	用户名
3	psw	VARCHAR(50)	密码
4	name	VARCHAR(50)	姓名
5	sex	VARCHAR(3)	性别
6	idno	VARCHAR(20)	身份证号
7	tel	VARCHAR(11)	手机号
8	license	VARCHAR(20)	驾驶证号
9	carno	VARCHAR(20)	车牌号
10	cartype	VARCHAR(20)	车型

表 6 乘客位置表（passenger_location）-与定位模块相关

编号	字段	数据类型	备注
1	locId	INT(20)	位置编号PK
2	longitude	DOUBLE	经度
3	latitude	DOUBLE	纬度
4	time	TIME	当前时刻
5	passengerId	INT(20)	乘客编号
6	status	INT(2)	乘客状态

表 7 司机位置表（driver_location）-与定位模块相关

编号	字段	数据类型	备注
1	locId	INT(20)	位置编号PK
2	longitude	DOUBLE	经度
3	latitude	DOUBLE	纬度
4	time	TIME	当前时刻
5	driverId	INT(20)	司机编号
6	status	INT(2)	司机状态

表 8 订单记录表（order）-与订单管理模块相关

编号	字段	数据类型	备注
1	orderId	INT(20)	订单编号PK
2	passengerId	INT(20)	乘客编号
3	driverId	INT(20)	司机编号
4	startloc	VARCHAR(50)	起点
5	endloc	VARCHAR(50)	终点
6	ordertime	DATETIME	下单时间
7	starttime	DATETIME	上车时间
8	endtime	DATETIME	到达时间
9	mileage	DOUBLE	里程
10	cost	DOUBLE	费用
11	status	INT(2)	订单状态

表 9 消息记录表（message）-与消息管理模块相关

编号	字段	数据类型	备注
1	messageId	INT(20)	消息编号PK
2	orderId	INT(20)	订单编号
3	senderId	INT(20)	消息发送者编号
4	receiverId	INT(20)	消息接收者编号
5	time	DATETIME	消息发送时间

表 10 乘客评价表（passenger_review）-与订单管理模块的评价功能相关

编号	字段	数据类型	备注
1	reviewId	INT(20)	评价编号PK
2	passengerId	INT(20)	乘客编号
3	orderId	INT(20)	订单编号
4	rating	INT(2)	评价等级
5	content	TEXT	评价内容
6	reviewerId	INT(20)	评价人编号
7	time	DATETIME	评价时间

表 11 司机评价表（driver_review）-与订单管理模块的评价功能相关

编号	字段	数据类型	备注
1	reviewId	INT(20)	评价编号PK
2	driverId	INT(20)	司机编号
3	orderId	INT(20)	订单编号
4	rating	INT(2)	评价等级
5	content	TEXT	评价内容
6	reviewerId	INT(20)	评价人编号
7	time	DATETIME	评价时间

3.3 系统架构

系统设计采用MVC（Model View Controller）框架模式，这种框架模式以数据、界面显示、业务逻辑分离的方法组织代码，在改良和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑，使代码具有较好的可扩展性、可复用性、可维护性及灵活性。系统架构如图 8所示，分为三层：前端表现层、业务逻辑层、物理数据层。

图 8 打车软件系统架构

其中，前端表现层主要接收用户请求，并为用户呈现信息；业务逻辑层调用模型完成相应的业务，与数据库联动处理增删改查操作；物理数据层用于存储业务相关数据。

3.4 系统部署

打车软件基于C/S模型，其乘客端和司机端属于移动客户端，客户端之间通过网络进行通信，服务器端使用负载均衡和集群化的方式来应对高并发的业务需求。系统部署如图 9。

图 9 打车软件系统部署

3.5 关键技术

实现打车软件的关键技术如下表 12，包括操作系统、数据库、移动通信技术等：

表 12 打车软件的关键技术

技术类型	技术点	使用原因
操作系统	客户端为Andriod/iOS，服务器端为Linux	打车软件客户端主要运行在智能手机终端，主流操作系统为Andriod与iOS；服务器端选用Linux，是因其具有稳定、安全、易用、费用低的优点。
数据库	MySQL、Redis	MySQL用于持久化存储，Redis用于缓存。
移动通信技术	流量控制、负载均衡、实时通信	应对高并发、低延迟的业务需求。
数据交换技术	json、压缩	json常用于数据传输，为提升传输效率，使用压缩技术。
业务流程	派单算法、开销预测算法、计费算法	打车软件需要专用算法完成业务流程，派单、开销预测、计费等环节对用户体验至关重要。
地图和定位	空间索引、空间计算	空车搜索、乘客搜索等功能需要对空间数据进行高效地查询。
隐私保护技术	基于位置的K匿名、差分隐私	用户的位置、运行轨迹等信息属于个人敏感信息，需要脱敏处理。
安全技术	加密算法	用户密码等数据不得以明文形式进行传输。

4 总结

本文主要对打车软件进行系统分析和设计，首先使用SA方法及DFD工具进行系统分析，然后使用MVC框架模式进行系统设计，最后指明了打车软件的系统部署及关键技术。

参考文献

【1】网约车_百度百科[EB/OL]. https://baike.baidu.com/item/%E7%BD%91%E7%BA%A6%E8%BD%A6. 2020年7月20日访问.

【2】易观. 2019中国网约车市场分析报告. 2019年7月.

【3】J.D. Power. 2020中国网约车服务质量研究报告. 2020年3月.

【4】极光大数据. 2019年1月网约车行业研究报告. 2019年1月.

【5】德勤咨询. 十字路口的网约车. 2019年1月.

【6】CNNIC. 第45次中国互联网络发展状况统计报告. 2020年4月.

【7】牛伟娜, 马倩瑶. 我国打车软件盈利模式探讨[J]. 合作经济与科技, 2016(19):110-111.

【8】极光. 2019年网约车出行安全用户信心研究报告. 2019年12月.

打车软件系统分析与设计方案相关推荐

马来西亚拟对打车软件巨头Grab罚款2000万美元
2019-10-03 17:44:47 马来西亚反垄断监管机构周四提议,对东南亚打车软件巨头Grab罚款逾8600万林吉特(约合2050万美元),因该公司违反竞争法对司机施加限制性条款.马来西亚竞争委 ...
moia调度mysql到hive_创立打车软件Moia后，“不安分”的大众又收购一家移动支付公司PayByPhone...
,大众集团旗下的金融子公司 Volkswagen Financial Services AG 即将对移动支付公司收 PayByPhone 发起收购.目前,两家公司都已经向<华尔街日报>确认 ...
印度打车软件Ola将登陆伦敦，或将取代被吊销伦敦执照的Uber
12月1日,据外媒报道称,继打车软件Uber刚刚被吊销伦敦执照后,印度打车软件Ola已经开始在伦敦登记司机,并将于下个月在伦敦进行试运行,2020年1月全面上线.有趣的是,Ola同样获得了Uber投资 ...
索尼入局日本打车市场，联合6家出租车公司推AI打车软件
Root 编译整理自 The Verge 量子位报道 | 公众号 QbitAI 据外媒The Verge估计,日本打车市场规模达到160亿美元. 而打车软件巨头Uber的市场份额还不到1%. Ube ...
【Redis】数据结构的应用——GEO 【搜索“附近的餐馆”、在打车软件上叫车】
搜索"附近的餐馆".在打车软件上叫车,这些都离不开基于位置信息服务(Location-Based Service,LBS)的应用.LBS 应用访问的数据是和人或物关联的一组经纬度信 ...
css3 打车软件等车动画，简单一个渐变放大消失水波加载动画
业务需求,需要做一个打车软件,等车效果,于是用css3自己简单写了一个!分享出来大家参考! <style>.ea55_jiazaiquan{text-align: center; posi ...
做一款仿打车软件需要多少钱？
论一款打车软件的重要性,我们外出旅行.游玩.逛街上班等都离不开最主要额交通工具汽车,现在很多的打车软件上架让我们出行更加便利了,打车软件是一种智能手机应用,乘客可以便捷地通过手机发布打车信息,系统自动 ...
【软件工程习题(含参考答案)】软件系统分析-五道题
软件系统分析章节精选课后习题(含参考答案),如有错误,望不吝指出(#^.^#) [第一题]住院患者监护系统目前住院病人主要由护士护理,这样做不仅需要大量护士,而且由于不能随时观察危重病人的病情变化, ...
打车软件烧钱背后的商业逻辑
这两个月快滴又掀起了打车应用的烧钱狂潮,消费者切实得到了实惠,而不少有意识的司机,也都纷纷当起了出租车司机,甚至传言有不少的人都月入过2万,这让多年的程序员情何以堪啊!在跟一个产品经理的朋友进行深入交 ...
打车软件的未来发展方向
市面上的打车软件其实远不止嘀嘀和快的,嘀嘀和快的之所以影响力这么大,就是因为他们的平台优势和背后强大的资金支持.由于当时补贴的力度较大,乘客们和司机们都能够获得很多的实惠,所以去年的这个时候,打 ...

打车软件系统分析与设计方案