二维码电子票业务系统建设方案.doc

江门移动二维码电子票业务竞赛文献
系统建设方案

2023年11月29日

文档说明
本文档所涉及到的文字和图表，仅限广州市**信息技术有限公司和广东移动内部使用，未经广州市**信息技术有限公司的书面许可，请勿扩散到任何第三方。

目 录
1 概述 1
1.1 项目背景 1
1.2 建设目的 1
1.3 系统规模 2
1.4 项目范围 2
1.5 用户特性 2
2 系统架构 3
2.1 系统网络架构 3
2.1.1 应用环境 3
2.1.2 网络架构 3
2.2 硬件配置建议 4
2.2.1 配置依据 4
2.2.2 配置建议 6
2.3 软件体系架构 6
3 系统功能说明 8
3.1 系统功能概述 8
3.2 应用功能 9
3.2.1 短信查询购票 9
3.2.2 Wap查询购票 9
3.2.3 Web查询购票 9
3.2.4 Web后台管理系统 9
3.3 基础平台 10
3.3.1 业务解决模块 10
3.3.2 数据存储模块 15
3.3.3 系统管理与监控 16
3.3.4 记录分析 16
3.4 数据接口 17
3.4.1 接口情况概述 17
3.4.2 手机支付业务平台接口 17
3.4.3 条码凭证业务平台接口 18
3.4.4 短信网关接口 18
3.4.5 江门汽运售票系统接口 18
4 系统设计原则 19
4.1 设计特点 19
4.2 安全性 19
4.3 可靠性 20
4.4 易用性 20
4.5 可扩展性 20
4.6 可维护性 21
4.7 开放性 21
5 项目实行方案 22
5.1 项目组织架构 22
5.1.1 成员计划 22
5.1.2 角色职责 24
5.2 项目实行计划 24
6 项目管理计划 26
6.1 沟通管理 26
6.1.1 沟通流程及形式 26
6.1.2 与客户的接口 27
6.1.3 项目文档的交付与归档 27
6.2 实行过程管理 27
6.2.1 实行控制的基础 27
6.2.2 实行控制的手段 28
6.2.3 实行控制的具体措施 28
6.3 变更控制流程 30
6.3.1 变更的提出 30
6.3.2 变更的评估 31
6.3.3 变更的批准 31
6.4 质量及安全保障体系 32
6.4.1 质量保证组织 32
6.4.2 质量体系文献 32
6.4.3 系统测试措施 32
6.4.4 质量改善 35
6.4.5 配置管理 35
6.4.6 数据安全措施 36

附图目录
附图1. 平台网络结构图 3
附图2. 系统软件结构图 7
附图3. 应用功能框架图 8
附图4. 购票解决流程图 11
附图5. 项目组织架构 22
附图6. 测试流程图 34

表格目录
表格1. 系统用户数规模 2
表格2. 系统软硬件配置 6
表格3. 项目组角色职责 24
表格4. 项目实行计划 24
表格5. 沟通计划列表 26
表格6. 变更申请表 30
表格7. 变更评估报告 31
表格8. 变更审批表 31
表格9. 测试文档列表 35

1 概述
1.1 项目背景
随着移动通信技术的发展和增值业务服务的丰富，移动手机已经跨越了传统的通信工具这一角色定位，逐渐成为人们平常生活必不可少的生活工具。为提高广大手机用户移动信息化生活的质量，将移动增值业务与人们的平常生活更加紧密的联系起来，广东移动已经先后推出了手机支付和条码凭证回执两类全新的移动应用技术。为此，江门移动计划使用相应的接口（即手机钱包及条码凭证回执接口）开发二维码电子票业务系统。会以实现与江门汽运集团合作开展客运手机购票业务为当前目的。将来可以使用同样的技术扩展到其他的商业合作伙伴。
1.2 建设目的
u 开展手机购票业务的应用，提高江门汽运购票业务的市场渗透率；
u 拓展手机小额支付、条码凭证电子回执应用。提高手机支付、条码凭证的业务应用收入；
u 丰富移动用户的信息化生活，培养用户的手机消费习惯，为下一代移动通信变革巩固基础。
u 实现手机支付进行购买指定线路的汽车票、下发二维码到验证乘车的闭环流程

江门移动“二维码电子票业务”本期项目的重要建设目的涉及以下方面：
u 与江门移动手机支付平台进行接口通信，实现话费账户、专用账户和银行账户的在线支付和对账等手机支付功能；
u 与条码凭证平台进行接口通信，实现条码凭证下载和条码凭证验证等功能；
u 与江门汽运售票系统的接口通信，实现最新班次的查询，购票以及数据同步。
u 短信网关的接口通信。
u 支持短信、WAP、WEB方式的最终用户访问，用户可使用任何一种方式，方便灵活的实现二维码电子车票的查询，购买。
u 支持对手机支付和条码凭证业务的灵活数据记录分析。
1.3 系统规模
表格1. 系统用户数规模
二维码点子票出票量
具体情况
二维码电子票出票数量暂时设定为10万/小时
系统初步的设计10万/小时的出票量。应当可以满足实际的应用需求。（经初步压力测试，本地数据库查询同步线程在100的情况下，系统正常稳定。考虑的与多个接口的数据同步稳定。系统目前按30个同步线程估算出暂定的出票数量。）
1.4 项目范围
本方案所描述的“二维码电子票业务”业务平台项目建设范围涉及以下几个方面：
1. 根据第2章所描述的系统网络架构和软硬件体系结构，搭建“二维码电子票业务”业务平台；
2. 按照第3章所描述的系统功能，设计和开发“二维码电子票业务”业务平台；
1.5 用户特性
根据**公司对“二维码电子票业务”业务平台的理解，系统用户重要分为以下两大类：
1. 系统管理员/移动管理员，通过内网访问系统，在“二维码电子票业务”业务平台上负责系统业务管理及平常维护。
2. 普通消费者，通过手机sms, wap或者web查询，购买指定线路的班次。实现手机支付和条码凭证下载等功能。
2 系统架构
2.1 系统网络架构
2.1.1 应用环境
“二维码电子票业务”将部署在江门移动内部网中。用户对“二维码电子票业务”平台的访问以外网接入为主，通过WEB网站、WAP网站、短信渠道访问系统。另平台接口服务器与江门汽运售票系统的通信，完全通过接口协议交互同步的数据报文。并且设有IP限制及防火墙过滤。系统的安全性和数据的保密性将得到有效的管理及控制。
2.1.2 网络架构
根据“二维码电子票业务”平台应用场合规定，建议网络架构如下：

附图1. 平台网络结构图
“二维码电子票业务”业务平台由数据库服务器、WEB/WAP应用服务器、接口机服务器构成。
WEB/WAP应用服务器用于部署平台的WEB应用服务和WAP应用服务，为手机移动用户、移动内部员工提供对系统的访问途径。通过防火墙，保证系统内部设备不受外部系统的侵扰。应用服务器上部署系统各类业务组件和业务生成引擎，负责所有核心业务的解决。应用服务器采用PC Server，可以根据业务的开展情况灵活扩展。
数据库服务器负责对平台数据的存取管理工作，采用PC服务器。
接口机服务器用于部署各类接口应用程序，可实现与汽运售票平台等外部系统数据通信，同时也可实现与手机支付业务平台，条码凭证业务平台等内部系统数据通信，也可实现与SMSC,WAP 网关等网关系统数据通信。
接口机服务器同时也用作系统数据的冷备份。
2.2 硬件配置建议
2.2.1 配置依据
2.2.1.1 预期用户数
综合考虑客运高峰期并发出票较高的需求以及与各个接口数据同步的安全稳定。系统暂定10万/小时的出票数量。
2.2.1.2 硬件配置规定
从硬件配置的角度，“二维码电子票业务”业务平台需要重点考虑的重要硬件设备涉及数据库服务器和WEB/WAP服务器。
1. CPU配置规定
u 数据服务
系统数据服务可以根据峰值用户解决业务的情况来估算。假设峰值时100人同时在向系统发出请求（假设每个请求的平均响应速度为1秒），系统每秒需解决的事务数则约为100。
考虑到数据服务器CPU 25%的冗余和10%用于操作系统运营，则数据解决占用65%的CPU资源。系统所需TPM-C值（TPM-C值为每分钟解决的事务数）为：
100×60 /0.65 =9,231。
可见，系统的数据服务器对TPMC值的规定为大于9,231。
主流PC服务器的TPMC值均大于20230，一台主流PC服务器作为数据库服务器应可满足上述计算的需求。
u WEB/WAP服务
在考虑到应用服务器性能时，我们参考服务器的Specweb99性能参数。Specweb99是SPEC（Standard Performance Evaluation Corporation，公开网址为.org) 组织（非赚钱第三方计算机研究评测组织）研发出的一套评测基准程序。该评测基准重要用来衡量计算机系统在Web Server环境下，所能支持的最大并发连接数，是在保证一定的连续时间、低于一定的错误率等情况下所记录下的最大连接数。该指标考察的是硬件系统平台、操作系统、Web Server软件等综合各部分的计算机整体系统对Internet并发连接的解决能力。而测试中的仿真终端具有一定的随机性，可模拟对图标、图片乃至大文献的访问，较为贴近实际应用情况。由于Specweb99的评测环境虽不等同于本系统的实际业务环境，但可作为相似的参考。
系统并发100个连接用户占用65%的计算能力（考虑到服务器CPU 25%的冗余和10%用于操作系统运营），则规定Web Server主机具有的Specweb99值应当大于：
100 / 0.65 = 154。
主流品牌1G以上CPU的PC服务器的Specweb99一般都大于1000，可以满足目前的性能需求。也就是说，系统的应用服务器采用一般主流的PC服务器即可满足需要。
2. 服务器内存
和CPU同样，内存的运用也和用户工作量的支持有关，可以参考厂家提供的相应CPU的标准内存配置采购。系统需要具有快速海量查询的能力，应考虑更大的冗余和更好的性能，采用4G内存容量可以满足数据库服务器的性能需求，而应用服务器则可以采用2G内存容量。
3. 服务器硬盘空间
按平台的需求情况，流程解决的数据量应较少，但资料、档案等所占磁盘空间则也许较大。
根据我们平台建设经验，系统业务数据占用的硬盘空间建议不小于72G，操作系统、应用软件和基础业务数据的大小约10G，再考虑25%的空间冗余，即数据库服务器的可用硬盘空间不小于110G。
2.2.2 配置建议
根据上节的配置依据，建议为“二维码电子票业务”业务平台配置以下软硬件系统：
表格2. 系统软硬件配置
序号
服务器名称
配置描述
数量
1
数据库服务器
配置：IBM X346，CPU 3.0GHZ*2 /RAM 4G/HD 4*73GB Raid 5
操作系统：Windows Server 2023标准版
DBMS：Oracle 9i
1
2
接口机服务器
配置：CPU 3.0GHZ / RAM 2GB / HD 2*73GB Raid 0
操作系统：Windows Server 2023标准版
DBMS：Oracle 9i
1
3
应用服务器
配置：CPU 3.0GHZ *2 / RAM 2GB / HD 2*73GB Raid 0
操作系统：Windows Server 2023标准版
WEB/WAP应用：TOMCAT5.0, JDK1.4
1
2.3 软件体系架构
软件体系构架为如下图所示的：

附图2. 系统软件结构图
“二维码电子票业务”业务平台从设计到开发将完全采用面向对象的技术，并大量采用多种涉及Servlet, JSP, JavaBean, JDBC, XML等在内的Java技术。
整体的架构完全遵循Sun公司建议的MVC模式，使得整个体系架构符合e时代公司应用的发展趋势。
采用MVC的方式有许多优点：
1. 将表达层（View）和逻辑层(Model)分开的一个优越性，在于容易在某种数据的基础上，增长多种表现或者改变某种形式；
2. 逻辑层(Model)以及表达层(View)分开以后，使得它们各自可以独立的变化。进而使得可维护性，可以扩展性，可测试性方面得到很大的改善；
3. 将控制层(Control)和表达层（View）分开，可以动态的决定表达的形式；
4. 将控制层(Control)和逻辑层（Model）分开，使得用户的输入和数据解决之间的关系可以灵活决定。

3 系统功能说明
3.1 系统功能概述
“二维码电子票业务”业务平台功能结构如下图：

附图3. 应用功能框架图
系统分为三大重要构成部分：
u 应用功能
平台的应用功能构建于系统核心模块上，由相对独立组件构成。重要涉及手机短信查询购票业务，手机wap查询购票业务，web查询购票业务，以及相应的web后台管理支持系统。
u 基础平台
提供系统底层核心管理功能，涉及相应的业务解决模块、数据存储模块、系统管理与监控、报表记录等基础功能。
u 数据接口
实现与内、外部系统的接口通信，完毕与内、外部系统的数据交互。
3.2 应用功能
3.2.1 短信查询购票
用户通过发送指定查询订票信息到指定端口。或者在系统设计的导航菜单交互的情况下，完毕手机短信的查询，订票流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.2 Wap查询购票
用户通过手机wap的方式访问相应wap查询订票网站。在系统设计的导航功能下完毕车票的查询购买流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.3 Web查询购票
用户通过web的方式访问相应web查询订票网站。在系统设计的导航功能下完毕车票的查询购买流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.4 Web后台管理系统
Web后台管理系统重要实现对二维码电子票业务平台运营情况的实时查询，管理功能，涉及查看系统当前运营的实际情况，按条件查询用户的具体购票情况。对指定号码进行重发二维码，短信，察看系统日记，以及各类报表的记录等管理功能。

3.3 基础平台
3.3.1 业务解决模块
该功能重要完毕用户实际使用系统中的各种业务逻辑方面的解决。涉及短信查询购票流程，wap查询购票流程，web查询购票流程。
3.3.1.1 短信查询购票模块
该模块完毕用户短信查询购票的完整业务逻辑。用户通过发送指定查询订票信息到指定端口。或者在系统设计的导航菜单交互的情况下，完毕手机短信的查询，订票流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。该模块最终完毕处会调用手机支付业务接口及条码凭证接口。
3.3.1.2 短信购票业务流程图

附图4. 购票解决流程图

3.3.1.3 短信购票业务事件流
汽运手机购票业务解决事件流如下：
A、 用户通过手机编辑具体购票短信指令发送到具体的购票短信端口；
B、 移动手机售票前台接受到用户的购票短信指令后，判断购票指令的合法性；
n 假如购票指令不合法，通过菜单选择的方式引导用户订票；
n 假如购票指令合法，则通过数据接口向汽运售票系统发送购票请求数据；
C、 汽运售票系统根据接受的请求数据包解决购票业务，并响应业务解决结果；
D、 移动手机售票前台根据接受的业务解决结果，进行下一步业务操作；
n 假如购票解决不成功，通过短信方式回复用户购票失败信息，业务操作结束；
n 假如购票解决成功，进行手机支付合法性校验，假如合法性校验成功，则下发扣费短信确认，假如合法性校验失败，向用户下发扣费失败短信告知并向汽运售票系统请求取消购票操作，业务操作结束；
E、 当扣费合法性校验成功后，用户收到扣费短信确认告知后，回复扣费短信确认；
F、 移动手机售票前台接受到用户批准扣费的短信确认后，进行手机在线扣费并下发条码凭证到购票用户手机上；
G、 用户接受到购票条码凭证后，到车站兑票；
H、 汽运售票系统对用户提供的条码凭证做数据检查，校验通过给用户兑现车票；
I、 业务流程结束。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下解决机制：
u 接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接解决机制，保证支付过程的畅通。
u 多线程解决机制；
实现多线程解决，提高通信效率，保证数据交互的顺畅。
u 高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
u 安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
u 按优先级别排队解决机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
u 用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
u 同一用户天天支付金额的上限额度机制
提供同一用户天天付款金额上限额度控制。
u 短信提醒功能机制
提供支付过程中的短信提醒功能。
u 解决异常，事务的回滚机制
提供支付异常时，事务回滚机制，保证交易数据的对的性。
3.3.1.4 Wap查询购票模块
该模块完毕用户Wap上网方式的查询购票的完整业务逻辑。用户通过Wap登录指定网站，通过系统导航，完毕手机短信的查询，订票流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。该模块最终完毕处会调用手机支付业务接口及条码凭证接口。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下解决机制：
u 接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接解决机制，保证支付过程的畅通。
u 多线程解决机制；
实现多线程解决，提高通信效率，保证数据交互的顺畅。
u 高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
u 安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
u 按优先级别排队解决机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
u 用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
u 同一用户天天支付金额的上限额度机制
提供同一用户天天付款金额上限额度控制。
u 短信提醒功能机制
提供支付过程中的短信提醒功能。
u 解决异常，事务的回滚机制
提供支付异常时，事务回滚机制，保证交易数据的对的性。
3.3.1.5 Web查询购票模块
该模块完毕用户通过普通WEB上网方式的查询购票的完整业务逻辑。用户通过WEB登录指定网站，通过系统导航，在通过手机校验码的校验后。完毕手机短信的查询，订票流程。最终会通过手机支付接口扣减相应的费用。通过条码凭证接口下发相应的二维码电子车票至用户手机。该模块最终完毕处会调用手机支付业务接口及条码凭证接口。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下解决机制：
u 接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接解决机制，保证支付过程的畅通。
u 多线程解决机制；
实现多线程解决，提高通信效率，保证数据交互的顺畅。
u 高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
u 安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
u 按优先级别排队解决机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
u 用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
u 同一用户天天支付金额的上限额度机制
提供同一用户天天付款金额上限额度控制。
u 短信提醒功能机制
提供支付过程中的短信提醒功能。
u 解决异常，事务的回滚机制
提供支付异常时，事务回滚机制，保证交易数据的对的性。
3.3.2 数据存储模块
数据存储模块会记录用户的所有上下行记录，以及相关的手机支付，条码凭证等各个应用环节的完整数据，方便此后的查询，核对。具体涉及以下一些方面
l 业务运营具体信息
l 交易数据明细（手机支付信息/条码凭证信息）
l 系统运营信息
3.3.2.1 业务运营具体信息
涉及在业务运营过程中用户的具体操作记录，如短信操作的查询/订票过程中的所有上下行互动记录。以及wap/web查询购票过程中的具体的互动操作记录等。
3.3.2.2 交易数据明细
具体完整的记录用户在购票过程的互动记录。同时涉及手机支付信息，条码凭证信息的完整周详记录。用于后面记录模块的报表记录及后期的数据查询核对。
3.3.2.3 系统运营信息
具体完整系统运营日记模块。后期可以对系统流量，用户操作习惯等进行分析。用于之后的系统优化及各个具体环节的完善。
3.3.3 系统管理与监控
提供“二维码电子票业务”的运营监控管理。
3.3.3.1 系统实时票务查询
后台提供二维码电子票业务的实时运营状态。管理员也可立即实时查询指定用户的使用情况。一种用途是客服通过查询该系统知道客户查询订票的实际情况。根据具体情况进行补发二维码彩信或短信等具体操作。
3.3.3.2 业务异常监控
提供“二维码电子票业务”业务平台上所接入合作业务解决异常的日记查询，数据监控分析。
3.3.3.3 业务高峰期监控
通过度析“二维码电子票业务”业务平台所接入合作业务受理事务日记和系统运营日记，监控各类合作业务高峰期运营情况，并可设立预警。协助系统管理员及时解决故障。
3.3.3.4 运营日记管理
系统管理员可对业务运营日记进行分类管理、查询、导出。
3.3.4 记录分析
提供固定格式的记录报表，实现对系统数据查询、记录的后台解决功能，在此基础上实现对业务数据的查询和记录分析。
3.3.4.1 记录报表
用户的所有短信，wap购票数据的具体信息都已完整记录入数据库。前期会提供以下一些基本的关键记录报表（实际情况可根据客户需求增长其他方式的记录报表）：
u 平台业务明细记录（准时间段，始发站等具体条件）；
u 系统总运营情况记录（准时间段记录各接入业务信息传递流量。）；
3.3.4.2 查询引擎
查询功能的内部核心组件，解释查询条件与业务数据等系统数据源之间的关系，从而实现对系统数据的查询和记录功能。
3.4 数据接口
3.4.1 接口情况概述
本期项目“二维码电子票业务”业务平台所需接入的重要业务接口如下：
u 手机支付业务平台接口
u 条码凭证业务平台接口
u 短信网关接口
u 江门汽运售票系统接口
3.4.2 手机支付业务平台接口
“二维码电子票业务”业务平台与手机支付业务平台通过数据接口实现手机在线支付功能。
u 交易环节：
1. 在得到用户确认的情况下，通过HTTP POST提交交易请求数据，发送到MPS交易解决系统。
2. MPS解决交易请求，并回复解决结果。
3. SP接受MPS回复结果，并解析结果作相应的交易解决。
3.4.3 条码凭证业务平台接口
“二维码电子票业务”业务平台与条码凭证平台通过数据接口实现条码凭证下载功能。
u 交互环节：
1. “二维码电子票业务”业务平台向条码凭证业务平台发送条码凭证下载请求。
2. 条码凭证业务平台接受到“二维码电子票业务”业务平台的请求消息后，进行信息反馈，并通过彩信方式下载条码凭证彩信给目的用户。
3. “二维码电子票业务”业务平台对记录条码凭证业务平台反馈回来的业务信息，为条码凭证兑现过程中与特约商户进行条码凭证合法性校验做准备。
4. 短信网关接口
3.4.4 短信网关接口
通过移动CMPP协议，以移动互联网短信网关通信，实现用户在指定端口的短信的上下行短信的交互。
3.4.5 江门汽运售票系统接口
“通过之前与江门汽运确立的交互报文，实现查询，订票数据的交互与同步。该接口支持短信，wap，web三种查询方式。

4 系统设计原则
4.1 设计特点
1. 面向对象设计
在系统设计方面，采用先进的面向对象设计方法(OOD)，借助强大的面向对象的可视化分析、设计建模工具，对系统需求、业务解决过程、公司运作所必备的商业对象、软件组件、系统结构和对象进行可视化建模，使应用更贴近实际业务需求。
2. 参数化驱动
移动业务系统规定具有较高的灵活性，以适应业务多变的特点。设计时采用参数化驱动的实现方法，将也许变化的因素统一参数化管理和维护，当参数变化时只维护这些参数表而无需更改应用软件，并且系统将在不断机情况下动态地调整这些参数。保证较短的时间内，响应业务需求经常变化的规定。
4.2 安全性
系统具有良好的安全性和可靠性，通过权限管理机制保证数据不被非法盗用和修改，保证数据的一致性；对非法登录或系统故障能采用多种检查和解决手段；采用故障检查、告警和解决机制，保证数据不因意外情况丢失和损坏。
系统具有良好的安全管理功能，数据存储、检索、提取、发布和管理等各个层面和角度都须具有相应的安全机制，并保证达成以下规定：
u 可分级进行权限管理；
u 能设立角色权限，可以定义角色以及角色相应的权限；
u 提供完整的操作日记，提供数据库存储日记接口/功能；
u 系统自身稳定；
u 用户活动的可审计性，提供良好的事后追查能力；
u 符合移动IT安全策略和标准；
u 系统具有访问权限的辨认和控制功能，提供多级密码口令或使用硬件钥匙等选择和保护措施；
u 系统提供操作日记记录功能，以便即时掌握运营状况；
4.3 可靠性
系统运营具有极高的可靠性和良好的容错性能，因软件系统自身因素（排除硬件、网络、数据库、中间件故障）导致系统局部功能短暂不可用的次数每月平均不超过1次；应用系统MTBF（平均失效间隔时间）部低于2023小时（不涉及因网络、主机硬件、数据库、中间件故障导致系统不可用导致的系统失效）。
4.4 易用性
u 提供丰富的联机帮助提醒和上下文有关的在线帮助；
u 系统应易于使用，具有良好的客户操作界面、具体的帮助信息，适合具有计算机基本知识或操作能力的用户的需要；
u 系统安装部署简朴方便；
u 系统保证良好的兼容性，不需要或较少补丁包；
u 界面布局及内容符合使用人员的思维习惯，容易理解，容易学习；
u 更新操作有反馈，系统将提供各类操作提醒；
u 危险操作有警告提醒，除告警之外，系统将通过完善的权限管理保证数据的安全性；
u 系统易于管理，系统参数的维护与管理通过操作界面实现。
4.5 可扩展性
系统采用模板的方式解决数据，可以灵活的适应业务的变化，此外，系统还将满意以下的扩展性规定：
u 易于版本升级，新的功能和模块可以加入；
u 易于增长功能；系统扩展新的功能时，不会影响到其他功能模块。
4.6 可维护性
u 有标准日记文献，数据可备份、恢复；
u 能记录后台进程状况和犯错信息；
u 标准和良好的数据备份/恢复机制；
u 操作系统、数据库和应用层满足信息安全规定；
u 技术资料完整。
4.7 开放性
系统保证具有良好的开放性，所有软件都应遵循业界相关标准，支持开放的标准接口，支持跨平台。使整个系统成为一个统一的整体，不会产生运营上的“孤岛”。
5 项目实行方案
5.1 项目组织架构
5.1.1 成员计划
根据“二维码电子票业务”业务平台项目的需求情况，**公司将以熟悉移动业务的技术人员为主组成项目组，通过公司重用程序库的代码重用来达成快速开发、实行的目的。
目前计划的项目团队组织结构如下图所示：

附图5. 项目组织架构
1 黄晓宇：中山大学本科学历，J2EE和.NET方面的技术专家，在移动数据业务平台方面有数年开发经验。曾先后担任程序员、高级程序员、系统分析员、项目经理，相关项目管理和开发经验：广州移动彩信营销平台、东莞移动彩信营销平台、顺德移动彩信管家系统、广州移动短信群发平台、茂名移动短信互动平台等。
1 李斌：新疆师范大学计算机专业毕业，2023的软件开发经验，精通Java，数据库delphi等各类软件开发工具。参与过多个大中型系统的设计，开发，建设。2023年以来一直从事移动增值业务平台的开发，建设。对底层通信，相关的各类通信协议以及各类增值应用方面都有丰富的实践经验及深刻的结识。
1 杨帆：2023年毕业于天津职业技术师范学院计算机科学与技术专业，获工学学士学位。毕业后一直从事J2EE架构的软件设计和开发工作。熟悉WAP技术，最近曾作为重要技术骨干成功完毕了广州移动节展会WAP平台、广东移动12580彩信营销平台的设计和开发工作。
1 李英山：2023年毕业于华中科技大学计算机科学与技术学院，获工学学士学位。熟悉移动数据业务、增值业务，具有2年.net项目开发经验，1年Java项目开发经验。参与开发十多个增值业务、数据业务、管理信息系统项目。
1 黄育盛：2023毕业于茂名学院计算机科学与应用系，曾负责广东省医疗事故鉴定系统、广东省办公厅OA系统、肇庆移动渠道积分系统、顺德移动彩信管家系统和广州移动会展E路通系统等项目的开发，对Java等技术有丰富的开发经验，对Oracle等数据库管理系统有丰富的实践经验，对数据业务项目有丰富的开发经验。
1 李毓：2023年毕业于华南热带农业大学计算机科学与技术专业，本科，获工学学士学位。毕业后即从事软件测试工作至今，曾负责的测试项目有：广东省特种设备管理系统、上海市特种设备管理系统、广州移动短信群发管理系统、东莞移动彩信群发管理系统、中山一键通客户管理系统、顺德移动彩信管家系统、广东移动12580彩信营销平台、肇庆渠道积分管理系统、广州移动后勤、深圳移动培训管理系统。
1 刘渊宇：2023年毕业于河海大学水文水资源管理专业，一直从事平面及网面设计工作。并于2023年获美国Adobe公司的Photoshop平面设计师认证。2023年开始专注于UI设计。最近完毕广州移动12580彩信业务系统、广州移动节展会WAP平台的前后台界面设计工作。
5.1.2 角色职责
根据项目的建设需求和**公司针对项目角色的安排，推荐以下人员担任项目组中相应角色，项目组重要成员名单和角色职责如下表所列：
表格3. 项目组角色职责
序号
角色
人员
职责
1
项目总监
黄晓宇
代表**公司，负责协调广东移动就项目的重大问题进行协商和决策
2
项目经理
李斌
作为**公司平常项目管理的单点联系人，负责项目实行的计划与控制、项目交付物的质量控制、项目资源的管理和任务分派，以及项目的平常沟通工作
4
开发组
杨帆、李英山、黄育盛
负责系统的概要设计、具体设计、开发和单元测试工作
5
测试组
李毓
负责完毕系统的集成测试工作，保证项目实行过程和交付物的质量
6
系统/美工组
刘渊宇
负责系统的部署、调测、管理、维护工作，负责系统人机界面的美工设计
5.2 项目实行计划
项目前期的筹备阶段时间较长，目前在需求调研与分析，系统设计，平台上线方面都有了较多的工作及实际的工作成果。考虑到项目正式启动后会有正式的开发需求文档。相应的工作会在之前的工作基础上进一步完善，建议的项目实行计划如下表所示：
表格4. 项目实行计划
序号
工作任务
完毕时间
交付物品
1
项目启动
2023-12-2
u 项目实行计划（MS Project文档）
2
需求调研和分析
2023-12-8
u 软件需求规格说明书（Word文档）
3
系统概要设计
2023-12-12
u 系统概要设计说明书（Word文档）
4
二维码电子票业务平台上线试运营
2023-1-6
u 用户操作手册（Word文档）
u 用户培训教材（Powerpoint文档）
u 系统安装维护手册（Word文档）
5
二维码电子票业务平台初验
2023-1-10
u 系统初验报告（Word文档）
6
二维码电子票业务平台终验
2023-1-15
u 系统终验报告（Word文档）
6 项目管理计划
6.1 沟通管理
针对项目的实行制定明确的沟通管理计划，目的在于保证项目相关信息可以及时产生并得到有效的传递，从而建立统一的项目沟通流程和语言，明确项目组每位成员的沟通职责。
6.1.1 沟通流程及形式
项目组成员应将每日工作情况以日报形式提交给项目小组长（周期较短的项目也许不再根据分工的不同设定不同的工作小组，这种情况项目组成员的工作日报应直接提交至项目经理），由小组长负责监督和控制项目组成员每日的工作进度，及时帮助项目组成员解决平常工作问题，或将问题提请项目经理解决。
项目组全体成员每周举行一次内部例会，将本周的各项工作进展以及碰到的困难进行总结和交流，并对下周的工作计划进行明确。会议结束后由各小组长负责归纳和整理，通过小组工作周报形式向项目经理反馈工作进展，项目经理整合和协调后以工作周报的形式发送给客户，并抄送双方项目总监。
项目经理应与客户项目经理约定每周工作周会的时间安排，并在工作周会前4个工作小时将上周工作报告及下周工作计划以工作周报形式发送给客户项目经理。项目经理应在工作周会结束后8个工作小时内，根据工作周会的讨论结果对工作周报进行更新。
表格5. 沟通计划列表
报告种类
负责人
提交时间规定
发送对象
工作日报
项目成员
每日下班前
小组长
小组工作周报
小组长
每周五下班前
项目经理
项目工作周报
项目经理
每周一中午前
客户项目经理
项目工作月报
项目经理
每月最后一个工作日下班前
客户项目经理
会议纪要
项目助理
会议结束后8个工作小时内
与会人员、项目组成员
6.1.2 与客户的接口
由于技术需要，在项目实行过程中有时候需要项目组成员直接与客户工作人员进行充足的沟通。但除了平常一般交流外，对于项目实行中比较正式和重要的协调工作统一由固定的接口人负责，并由其将沟通结果告知项目组成员，以避免多人答复导致沟通上的失误。如非特别说明，与客户的固定接口人为项目经理。
6.1.3 项目文档的交付与归档
项目成员完毕相关项目文档的编写后，通过**公司规范的交付物评审流程后，由项目经理正式地交付给客户。
在项目实行过程中，所有文档（涉及电子件）都应及时归档，统一平台管理。**公司统一采用Visual SourceSafe作为文档版本管理工具。
6.2 实行过程管理
6.2.1 实行控制的基础
**公司对项目实行的跟踪和监控分为七大类：
u 综合控制；
u 范围控制；
u 进度控制；
u 成本控制；
u 质量控制；
u 风险监控；
u 协议管理。
这些实行控制的执行以项目的相关计划为基础，一般涉及：
u 项目实行计划；
u 各类变更申请；
u 范围说明；
u 变更管理办法；
u 进度计划及管理办法；
u 成本基准计划和管理办法；
u 质量管理办法；
u 测试计划；
u 风险管理和应对计划；
u 采购协议管理细则。
6.2.2 实行控制的手段
项目组将通过以下方法对项目实行进行跟踪和监控：
u 每周项目例会。每周定期举行项目组例会；双方项目经理每周举行碰头会，交流项目进展情况和双方需协调的工作。
u 会议纪要。每次会议的内容记录，涉及与会人员、会议主题、中间过程、结论等，对于讨论形成的问题跟踪表则形成会议纪要的附件。不管是项目例会还是双方项目经理的碰头会都需要形成相应的会议纪要。
u 绩效报告。涉及状态周报、进度报告和预测。每周根据项目计划、当前工作结果和其