番禺民生卡APP 20项目采购需求说明书doc.docx

番禺民生卡APP 20项目采购需求说明书doc.docx

《番禺民生卡APP 20项目采购需求说明书doc.docx》由会员分享，可在线阅读，更多相关《番禺民生卡APP 20项目采购需求说明书doc.docx（12页珍藏版）》请在冰豆网上搜索。

番禺民生卡APP20项目采购需求说明书doc

番禺民生卡APP2.0项目采购需求说明书

项目目标

番禺民生卡APP作为民生卡服务系统平台重要组成部分，是用户使用的主要入口，在现有的民生卡APP已不能满足业务发展需要和技术更新要求，新功能更新严重依赖APP版本更新，应用对接接口不统一，APP没有运营后台管理，需要对系统进行全面升级，已满足民生卡APP在后续业务扩展和技术更新需要，逐步提升番禺民生卡APP作为“番禺智慧城市移动服务入口”的应用地位，深化发展智慧教育、公共交通及停车、政务应用及社区等民生相关内容,实现线上线下进一步融合。

以公安部的刷脸实人认证技术，发挥民生卡“金卡工程”及支付功能的作用，丰富民生卡各项应用覆盖面。

同时，以满足番禺超过三百万市民使用为目标，重大升级番禺民生卡APP的用户量承载和并发能力。

让市民通过民生卡APP、自助终端、消费POS等多渠道实现以民生卡作为身份识别并通过民生卡账户进行支付，实现民生卡综合服务平台和应用环境。

番禺民生卡APP2.0（须支持安卓、iOS版本的移动终端）系统，需实现现有运行APP基本功能和业务应用，保障业务正常平稳迁移，在满足业务需要和稳定的基础上新增：

1、系统架构设计需求：

使用分布式微服务的开发架构，并使用Docker容器技术进行分布式部署，极大增加APP的访问量和并发量承载能力。

同时，要求新增文件存储服务Ceph、统一接口网关、APP网关等系统设计，进一步增强系统的安全性、稳定性和向外拓展性，提供多种应用对接的能力支持。

2、系统功能需求：

优化APP注册、登录、忘记密码流程，注册完毕引导绑卡；15天内再次使用免密登录；短信验证码登录；指纹验证登录；首页界面自动延伸；卡证功能；用户地址管理；AOS运营管理后台；应用搜索；APP闪屏；停车场功能H5改造；计划免疫功能H5改造。

设计原则

（一）独立性

系统应独立于其他业务系统开发，不因其他业务需求变化而变化，也不影响其他业务系统的升级。

（二）扩展性

系统应设置灵活、维护简单、扩充方便、能适应业务快速发展的需要。

软件、硬件平台具有良好的可扩充、扩展能力，能够方便进行系统升级和更新，以适应各种不同业务的不断发展；新功能、新业务的增加能够在不影响系统运行的情况下实现。

支持业务量的不断扩容。

（三）可靠性

系统必须建立一套异常恢复机制，保障系统运行的可靠性及交易的一致性。

（四）高效性

系统必须具备足够的交易吞吐能力和高效的处理效率；实时性要求很高，响应速度要快，实时性是提供优质服务的前提。

系统在满足可靠性和安全性的前提下，应该尽量提高系统的响应速度，为客户提供满意的服务

（五）操作性

在系统设计时充分考虑对底层技术进行封装，提供面向一般管理员的管理工具，以减少员工学习成本，减轻维护人员的负担，提高管理和决策的效率；系统应具有友好的操作界面，操作员使用方便、简单、易学。

（六）规范性

系统的软、硬件建设应符合国家标准和行业相应的技术规范，各类文档完整、规范。

（七）开放性

系统应具有很好的开放性，能与原有的业务系统对接。

（八）安全性

安全性是实现企业应用系统的必要条件，包括系统安全、通讯安全、数据安全、业务安全；必须充分考虑系统的安全风险点，采用有针对性的安全策略，充分考虑整个系统运行的安全策略和机制，可以根据不同的业务要求和应用处理，设置不同的安全措施。

（九）开发接口

丰富的应用编程API，可以充分利用现有的设备与系统资源，并根据快速变化发展的市场需要做出相应调整，整个系统具备开放性的架构，提供开放的二次开发接口，能够保证业务的持续发展，使得业务维护和发展不依赖于厂商。

（十）稳定性

系统必须充分考虑网络中可能出现的传输瓶颈，有效防止和解决通信阻塞，保证交易质量。

（十一）经济性原则

经济性原则要求系统的设计与实施必须考虑资源的使用和闲置情况，同时保证系统的平滑扩容。

项目需求

功能清单

根据业务需求目标，结合系统现状，汇总了功能清单：

序号

功能

功能描述

1

注册登录功能优化

优化APP注册、登录、忘记密码流程，注册完毕引导绑卡，用户界面重新设计。

2

持续登录

用户注册登录之后，15天内再次使用即免密登录，并保持免密登录延续下一个15天周期。

3

短信登录

增加验证码短信登录功能。

4

安全登录

新增指纹登录功能，用户可设置手势密码或指纹验证登录。

两种方式可单独设置或重叠使用。

5

绑定民生卡提示

APP开启过程中检测用户是否绑定民生卡，未绑定民生卡用户在当天第一次开启民生卡APP，APP将反馈用户提示绑卡。

6

首页自动延伸

根据运营后台新建的应用和应用分类，自动延伸首页界面。

7

卡证功能

管理绑定/解绑民生卡功能，查看名下民生卡种类和卡号。

8

用户地址管理

用户可预设并保存居住地址、户口地址及公司地址。

用于各应用填写地址信息时调用。

10

民生小钱包

配合民生卡核心系统子钱包功能，管理各项专款专用补贴。

11

应用搜索

增加应用搜索栏，搜索APP内所有应用。

12

APP闪屏

新增应用开启启动页，可跳转至网站及内部应用。

13

横幅自由配置

支持APP内应用在不需要用户更新情况下，由运营人员新建、编辑横幅。

13

番禺天气

显示番禺天气功能。

14

应用可配置

支持APP内应用和应用类别在不需要用户更新情况下，由运营人员新建、编辑排版。

15

分布式微服务架构

为了增加APP的访问量和并发量承载能力，重构APP的系统架构为分布式微服务架构（SpringCloud）。

16

Docker容器技术

新增Docker容器技术进行部署。

17

Ceph对象存储服务

新增文件存储服务Ceph。

18

统一接口网关

集群内应用接入集群外部接口的统一调用服务，能够有效避免集群内部微服务重复对接集群外部接口，以及集中管理集群内部对外的流量。

19

APP网关

实现外部接入手机应用接口，对数据的通信加解密。

20

网页应用服务

将非核心业务停车缴费、计划免疫、积分转换成网页H5，降低APP的复杂度，提升业务迭代能力。

21

乘车码

请求并下载乘车码，现阶段支持国朗与羊城通乘车码，日后逐步扩展至可兼容展示不同乘车码或交通工具二维码

22

扫二维码

既可扫民生卡进行支付与转账，亦可扫描国朗停车、泊车科技停车等场景的二维码

23

关于扫条形码

对传统条形码进行支持，可通过扫码识别商户并获取产品信息等，并能请求并下载民生卡后端服务器生成条形码，并展示在应用上

24

对接微信小程序

针对日渐增多的商户使用微信小程序推广业务，对接方式也有H5转变为微信小程序，要求具有对接微信小程序功能

25

支付网关展示与交易通讯

为拓展用户群，并为非番禺本地（无民生档案号）的居民能使用上便民的民生通，绑卡后民生消费是App的一大功能，没有民生档案的用户通过选择支付网关进行民生消费

26

停车场应用

民生通将覆盖市民出行各方面，包括停车（路边停车与停车场停车），需要从整体业务流程对接停车场业务场景，具体

1、用户绑车牌

2、注销车牌

3、定位空车位

4、车辆定位

5、退场消费

6、离场扫码

等，并增加相应信息提示与推送

27

旅游板块应用

民生通将覆盖市民出行各方面，包括旅游（包括套票购买等），需要从整体业务流程对接旅游业务场景，具体

1、购票

2、景区地图展示

3、优惠推介

等，并增加相应信息提示与推送

28

医务板块应用

民生通将覆盖市民出行各方面，包括医疗（包括体检报告，挂号，缴费），需要从整体业务流程对接医疗场景，具体

1、体检报告展示（页面数据模式、pdf模式）

2、挂号

3、缴费

等，并增加相应信息提示与推送（包括检验信息完成通知、排队叫号通知等）

29

民生卡APP旧版功能支持

在新系统完全迁移民生卡APP旧版基本的功能，实现注册、绑卡、解绑、充值（微信、支付宝、银联）、提现、转账、付款码、乘车码、账单查询、交易通知、政务应用、医疗应用、商城应用、出行应用、生活服务应用等功能模块。

商务要求

工期要求及交货地点

1、系统供应方需根据项目需求，针对各个功能提供具体工作量（单位人天）及报价（含报价依据）。

2、工期要求：

意向供应方必须在合同签订日期起90个工作日内完成主体系统设计开发及上线，并在其他关联方具备对接条件的情况下完成系统对接工作并正式交付使用。

3、交货地点：

广州星海数字电视金卡有限公司指定地点。

付款方式

（1）合同签订5个工作日内，采购方向意向供应方支付合同总额的30％；

（2）合同工作进度完成70%，经过双方确认，采购方向意向供应方支付合同总额的40％；

（3）系统开发完毕交付使用后，试运行期为三个月，如试运行期系统运行正常，达到用户要求，则双方在试运行期后五个工作日内组织验收，验收通过，采购方向意向供应方支付合同总额的25％；

（4）质保期后，如无问题，5个工作日内，采购方向意向供应方支付合同总额的5％。

项目实施要求

系统实施要求

意向供应方应结合自身的项目管理制度和经验，根据本项目的实际情况，在软件工程各个控制阶段提出针对性的管理方法。

以下内容主要是对项目实施过程的一些通用要求。

1、本项目已完成初步设计，意向供应方须在项目实施前，根据本采购文件内容，修改初步设计，并按软件工程规范要求进行数据库设计、详细设计。

2、意向供应方应在合同规定的工期内完成所规定的系统建设任务。

3、采购方及采购方所委托的监理单位，有权对整个项目实施的全过程进行监督检查。

意向供应方必须给予积极支持和配合，不得以任何理由回避采购方或监理单位的检查监督。

4、系统开发工作应严格遵照国家软件工程规范和普遍使用的相关行业标准，如：

ISO9000、CMM等，并根据开发进度及时提供有关开发文档。

5、意向供应方必须将整个系统建设划分为多个阶段进行，以保证系统建设的质量和进度得到有效的控制，其中至少包括：

项目启动阶段、需求阶段、详细设计阶段、编码阶段、测试阶段、现场实施阶段、确认测试、试运行阶段、系统验收阶段、系统正式运行阶段（维护阶段）等。

6、意向供应方必须建立完善的项目管理机制，以保证项目建设能按期进行。

至少包括：

事前计划，计划跟踪、进度控制和监督，需求管理，配置管理机制，产品质量评审，沟通协调。

⏹事前计划：

要求意向供应方在项目各个阶段开始前必须先向监理单位提供下一阶段的具体工作计划，在取得监理单位同意之后，方能进入下一阶段的工作。

⏹计划跟踪、进度控制和监督：

要求意向供应方对项目的总体计划和各阶段的具体工作计划进行跟踪报告，建立进度报告机制。

意向供应方须向采购方和监理单位每周提供《项目周状态报告》，报告上一周按计划已经完成的工作、未能完成的工作及原因、下周计划的工作；每月提供《项目月状态报告》，报告上月所处的阶段状态、按计划已经完成的工作、未能完成的工作及原因、与《软件项目计划》偏离度及是否需要调整项目计划、下月计划的工作；每个阶段结束后5个工作日提供《项目阶段总结报告》，报告阶段按计划已经完成的工作、未能完成的工作及原因、与《项目总体计划》偏离度及是否需要调整项目计划、下一阶段计划的工作、下一阶段存在的风险。

⏹需求管理：

要求意向供应方在需求阶段开始时，建立有效的需求管理制度，对需求的调研、需求的确认、需求的变更、需求的跟踪等相关工作进行有效的管理，保证能完全真实地反映采购方的所有需求，而且所有需求能得到正确地实现。

⏹配置管理：

要求意向供应方在软件系统的整个生命周期中，对各阶段的产出物（包括纸质文档）建立配置管理机制，保证各产出物属于当前最新版本，确保上一版本出现的问题在下一版本得到改正。

⏹产品质量评审：

要求意向供应方在软件系统的整个生命周期中，对重要产出物建立评审机制，规定各类产出物参与评审的人员类型和评审通过准则，评审必须以会议的形式进行，形成评审会议纪要和《评审报告》。

各产出物的评审报告必须提供给意向供应方和监理单位，在意向供应方同意评审通过之后，该产出物才能作为下一步工作的依据和指导。

⏹沟通协调：

要求意向供应方在和采购方的工作交往中，建立良好的有效的机制，保证采购方随时掌握项目的进展情况，也使意向供应方在工作中的重大问题和困难能得到快速的有效的解决，比如：

建立定期例会制度，由意向供应方报告当前项目进度并提出遇到的无法处理的困难，重大问题由采购方协调解决，并提出对下一步工作的总体要求，每次例会必须形成《会议纪要》并抄送相关各方；建立文档管理制度，保证合作双方的各种文件信息良好流通，并得到充分的共享。

系统测试和验收要求

1、安装检验

软件系统应通过光盘安装，系统的配置应简单、方便。

2、运行检验

（1）项目按采购方要求完成并通过由采购方组织的初步验收后，才能进入试运行阶段，试运行期三个月,此期间施工单位要按要求完成工程结算的报送。

初步试运行期间，意向供应方有责任配合采购方内部各个业务处室的建设要求，必要时对本项目建设的范围和内容进行相应调整、修改和完善。

在试运行期内系统若被发现存在会影响正常运行或正常使用的重大缺陷，则意向供应方应作深入分析并提交分析报告，提出解决方案并在规定的时间内解决问题。

试运行期的计算将在意向供应方解决了系统重在缺陷、恢复正常运行之日归零重新起算。

三个月试运行后组织测评。

（3）采购方组织综合验收，验收通过后投入正式运行。

期间，意向供应方有责任配合采购方内部各个业务处室的建设要求，在采购文件的范围内对本项目建设的范围和内容进行相应调整、修改和完善。

（4）综合验收通过的时间为系统售后服务的起始时间，免费售后服务期为：

1年。

功能和性能测试

严格遵照国家软件工程规范和普遍使用的相关行业标准相关要求执行。

系统交付要求

1、安装介质

意向供应方必须在正式运行前提供以CD-ROM为介质的完整的安装系统，包括应用软件、运行所必须的附加软件、与应用软件有关的电子文档等。

2、文档交付

意向供应方必须在正式运行前提供完整的与应用系统相关的文档，包括系统需求分析、概要设计、详细设计、新旧系统过渡方案、测试报告、安装说明书、使用说明书/用户手册、系统维护说明书、原厂家随机文档等。

各种文档应当以CD-ROM和书面两种形式交付。

各种验收文档数量要求、质量在合同另行规定。

3、源代码交付

意向供应方必须提供完整的应用软件的源代码，并加注良好的注释。

源代码应当以CD-ROM形式交付。

系统更新或升级后应相应提供完整的最新版本的源代码。

源代码的保密协议在合同另行约定。

售后服务和培训要求

售后服务

对意向供应方的售后服务要求：

意向供应方应为采购方提供自系统终验之日起一年的免费质保期，提供与系统有关的免费技术支持服务。

在质保期内，若采购方有系统维护需求，意向供应方需保证至少有两个项目实施人员现场支持。

具体售后服务要求如下：

1、故障报修的响应时间：

收到采购方书面或电话通知后，如不能远程解决，意向供应方应在5小时内到达现场。

2、终验后，意向供应方在采购方同意或指定的地点，为采购方提供一年的免费技术支持服务。

3、质保期内，意向供应方负责对其提供的系统免费进行升级和维护，并且保证每周上门巡检一次，并提供周报告和月报告，不再向采购方收取费用。

4、所有免费质保方式为意向供应方上门服务，即由意向供应方派员到采购方使用现场维护、升级、故障排查等。

由此产生的一切费用均由意向供应方承担。

培训

1、意向供应方必须提供相应的应用软件技术和系统操作等方面的培训。

应用软件的操作培训课程应该在系统正式上线前完成。

意向供应方须在响应文件中提出全面、详细的培训课程以及培训时间表。

2、意向供应方在实施过程中提供免费、全面的培训，包括数据库操作管理、面向系统管理员和业务人员的培训、基于系统开发完整的源代码培训，基于系统平台接口规范标准的二次开发培训、开发平台和开发工具培训、配置管理和系统维护培训、数据定义和管理培训、客户端操作培训。

3、对于所有培训，意向供应方必须派出具有相应专业资格和实际工作、教育经验的教师和相应的辅导人员进行培训，主要培训教员应至少具有三年的教学经验，培训所使用的语言必须是中文，否则意向供应方必须提供相应的翻译。

4、培训项目结束之后，当学员普遍反映对培训课程不满意时，采购方可要求意向供应方重新安排培训，并由意向供应方承担全部费用。

5、意向供应方须提供详细的培训计划。

6、培训费用计入总价。