某保险公司手机APP开发建设解决方案 - 大连APP,大连app开发,大连APP建设

学习园地

某保险公司手机APP开发建设解决方案

发布时间-2013/12/14 10:12:03

第一章概述

1.1 项目背景

随着信息技术的高速发展，传统的PC用户必须通过电脑和网络才能进行应用和服务的获取，具有极大的不便捷性和信息滞后性。而现代网民的上网习惯的改遍和生活节奏加快，保险行业产品数量众多，对保户的服务性要求更高；网民使用习惯从PC转向了手机、平板电脑等移动终端，采用PC进行保险的推广尤为不便。

目前某保险公司网站已集成了陆游险、意外险、人寿险、家财险、车险、团体险等常用的系统。提供了快捷搜索、产品展示、在线投保、在线支付、账号申请、密码重置、等用户服务功能。但一方面网站缺少可行的推送机制，另一方面是公司也没有对应的移动Wap站。所以迫切需要建设一套功能完善的移动终端使用的Wap站,供保户使用。建成的Wap站应该包括以下内容。

1.某保险公司网站用户更方便的适用手机对网站进行访问；

2.在手机端展示保险信息，快速推荐适合客户的保险；

3.会员通过手机网站登录，在线购买适合自己的保险；

4.新的手机网站与现有网站数据的无缝对接，实时同步数据；

5.建立全面的安全管控机制，有效保证数据安全性；

6.建立会员信息库，保存重要会员信息。

1.2 项目目标

某保险公司WAP站 -的主要目标是利用移动互联网络，将面向公司、保户的各种常用服务进行汇聚，提供全生命周期的、可以不断完善的、有实用价值的、便捷的、随时随地的移动信息化服务；

同时，通过平台建设促使公司支撑服务的管理效率和管理水平得以提高，最终优化服务的质量。通过便捷的移动服务，改善现有的信息流通渠道，改善现有的营销和工作模式，使公司产品在时间、空间上得到延伸，克服传统营销模式障碍。

1．建立电子商务平台，通过手机访问某保险公司网站，使用户更方便的通过手机购买保险产品，提升交易额。

2．动态信息推送，实现保户主动在线投保。

3．客观、准确的反映保户投保情况。

4．为客户提供一个更加便捷、高效的沟通和服务渠道。

5．提供标准化的服务内容

6．降低公司成本，优化公司的业务流程和管理流程，提高用户满意度。

1.3 建设原则

根据此项目的需求与现状分析，在进行建设时，将遵循以下原则：

标准化和规范化原则

严格遵循国家和地方有关法律法规和技术规范的要求，从业务、技术、运行管理等方面对项目的整体建设和实施进行设计，充分体现标准化和规范化。

创新性与先进性原则

紧密结合相关需求文档，在该系统的建设中突出自主创新以及重点突破，保持系统在技术上的先进性。在充分分析系统技术发展的现状以及发展趋势的基础上，结合实际应用的业务需求，采用先进成熟的技术体系。同时，开发或配置先进、高效实用的系统软件和应用软件，使整个系统能协调一致地运行，以获得最大的系统性能和效益。同时，充分考虑系统后续发展的技术和应用需求，为后续的维护和升级提供全面的保障，在设计和开发上具有一定的前瞻性，使系统具有较强的可扩展能力。

安全性原则

在进行系统设计时需依托国家电子政务建设的各种信息技术标准（环境、技术、信息、安全、信息交换标准等），制订项目各项技术标准。强化信息安全建设，建立健全安全保密制度和信息安全管理措施，确保数据信息资源的安全。

易用性原则

系统在设计过程中要针对不同层面的使用者的应用水平，充分考虑系统的易用性，保障本系统建成后的应用与推广。具体做到：界面友好、易于使用、便于管理维护、数据更新快捷和系统升级容易。满足用户在不了解技术的条件下，能够很好的使用系统处理业务以及定制、调整和维护系统功能。

经济性原则

近年来各部门信息系统建设的成果是本系统建设的基础。本项目建设应当充分利用已有资源，避免重复工作，力求减少浪费。系统设计方案将在实用的基础上做到最经济，以最小的投入获得最大的产出。在硬件和软件配置、系统开发和数据库设计上充分考虑在实现系统全部功能基础上尽量节约经济成本。

系统性原则

统筹规划、统一设计，保证整个系统的统一和数据的一致，是非常重要的，因此必须坚持系统性原则，采取有力的组织措施和严格的制度保障。

扩展性与开放性原则

扩展性是系统设计好坏的重要衡量要素之一。由于机构、人员、业务处理过程以及业务表现方式都是处于不断变化的过程中，所以在系统设计过程中需要具有良好的扩展性。这种扩展性主要体现在，具有方便的二次开发的能力、可定制维护能力、可快速移植的能力等等，真正做到高内聚低耦合，以提高系统对业务调整的应变水平以及再开发的水平。

整体性与渐进性原则

在系统建设过程中要根据现有的条件，按照统筹规划、分步实施原则，有计划有步骤地进行。按照系统的主要工作内容，先作好总体规划和设计，搭建好整体框架，然后有计划进行分期建设，逐步进行扩展。

1.4 建设策略

1)统一标准规范

本系统建设需要从全局高度出发，统一流程规范，建立统一数据标准。统一数据标准的目的是为了更好的实现数据共享和数据交换。尤其是拟建系统中的数据交换部分。我们建议在项目中对各类数据进行统一标准规划。

2)基于应用支撑平台开发

基于统一的技术平台进行本系统的开发，统一的流程定制公共组件、系统管理、角色管理、节点管理、流程定制、数据报表等功能，从而快速实现业务功能开发，保证项目的顺利、按时启动及上线后对系统方便的维护。

3)领导组织权力支持

需要建立专门的项目领导小组，对项目建设进行领导和业务协调。项目领导小组应确定客户方及承建商双方协调人，负责协调与集成商、监理商、系统开发商之间的沟通机制，根据不同阶段的工作任务，明确各干系人的相关职责。同时加强项目阶段评审工作，防范风险发生。

第二章系统架构

2.1 系统业务架构

根据总体架构思路，规划的总体架构图如下：

1）网络硬件基础层

网络硬件基础层是整体建设的基础，包括网络环境、服务器主机、存储设备以及系统软件四类资源，是整个架构赖以存在的支撑。

网络环境：信息安全要采用严格的权限配置、防火墙、网闸与传输加密共同保障。

服务器主机：服务器需要使用高端的 PC 服务器，需要采用必要的技术手段确保服务的稳定性及可靠性。

存储设备：采用外部独立存储保证数据存储安全。

系统软件：选用成熟、稳定、经济性好的系统软件产品。

2）数据层

数据层用于存储各类数据，为业务应用提供数据支撑。具体的内容包括：基础数据、大连教育公司现有的基础应用系统、业务系统的数据库或其提供的数据接口等。

内容及问答信息库保存整个系统中用到的所有非结构化的数据，比如公司的基本资料数据以及问答模块产生的一问一答的数据等。

文件资源库保存系统中用到的结构化数据，比如上传到系统中的优秀教案、精品课件等。

另外为WAP站提供数据的接口也会直接访问内容及问答信息库。以实现WAP站与网站的数据同步。

3）应用支撑层

应用支撑层起到对数据的统一管理、统一应用、简化数据调用与展现的作用。在承担对数据层的调用与管理职责的同时要能够为业务层提供服务支撑。

4）网站系统业务层

基于对业务的归纳和分析，业务层的构建要依托于统一的应用支撑层，通过构建一个个具体的业务应用系统形成业务层，最终在现有网站上进行展示。业务层的业务系统通过应用支撑层提供的基础支撑服务来搭建，并完成明确的完成移动应用平台请求的各项工作。如果公司有内部的业务系统，也可以在这一层上同内部业务系统实现内部系统与网站的对接。

6）手机WAP站表现层

手机WAP站表现层的构建是移动数字公司平台的移动应用，对各类信息化建设的成果进行统一组织、统一入口、统一规范，为用户提供更好的交互体验。在原有网站上的用户可以在手机表现层用旧用户登录并发布以及回答各分类下的问题。

2.2 系统技术架构

考虑到产品的成熟与技术的成熟是个交替发展的过程，我们建议方案整体采用J2EE技术平台，但方案中不排除使用NET技术或只用Webservice接口模式等成熟解决方案。具体根据某保险公司现有网络架构将采取不同的技术架构方案。

2.2.1 采用标准的架构

采用基于行业标准或得到广泛使用的、事实上的、行业标准的技术架构，有利于降低技术风险和对特定供应商的依赖性；采用的开放系统架构，有利于保持系统的向后兼容性、可集成性和可扩展性。在项目中，将采用符合 J2EE规范的应用服务器作为整个应用的基础技术平台，采用JSON 作为数据交换的标准格式，以保证整个项目的技术架构满足标准和开放性的要求。

2.2.2 采用面向对象的技术

面向对象技术的发展已经成熟，基于面向对象技术的开发语言和应用框架，已经得到证明可以大大提高信息系统开发和建设的效率，提高架构的合理性和可扩展性。

我们将采用面向对象的开发方法完成软件的开发工作，包括面向对象的分析（OOA）、设计（OOD）和实现（OOP），具体表现为使用 UML语言进行分析和设计工作，使用 JAVA 语言进行编码实现。

2.2.3 采用三层（N层）的分布式架构

分层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于建设、维护和升级。在系统中将采用基于浏览器/服务器（B/S）模式的三层（N层）体系结构，将系统按照表现层、中间层和数据层来划分，其中中间层还可以划分为：业务逻辑层、公用服务层、数据访问层等。从开发的角度讲，通过这些层次的划分，使得系统开发人员的分工更加明确，负责每个层面的技术人员只需要掌握相关的技术和接口，而不必掌握全部的技术，降低了开发人员的技术难度；对业务人员来讲，只需要把注意力集中在业务逻辑的实现上，并可以通过管理和配置的方式来适应未来业务一定程度上的发展变化。

三层架构示意图:

2.2.4 采用基于组件的技术

基于组件的开发是普通应用程序开发的变体，它具有如下特点：

应用程序由各自独立的组件组成，这些组件的开发和部署保持相对的独立性，而且很可能是多个项目同时开发和部署的；通过仅对这种应用程序的某些组件进行升级，从而对其进行小幅度的升级；组件可以在不同应用程序之间共享，因此可对它们复用，但同时也产生了项目之间的依赖关系；尽管并非与基于组件完全密不可分，但基于组件的应用程序倾向于分布式结构；

2.2.5 SSH技术架构图

2.3 系统部署架构

2.4 系统接口设计

2.4.1 接口设计原则

规范接口原则

1)规范各个子系统的开发，提高业务和数据交互的合理、安全、稳定和高效；

2)提供规划合理的接口，便于根据产业发展变化的系统扩展和二次开发；

3)采用通用且安全性高的接口通信标准，如xml、webService；

4)系统提供对外接口发布及对内接口调用，清晰明了的发布及调用文档；

5)平台对外提供公共服务的关键环节，为建设产业类数据中心提供基础，进一步规范接口的使用；

接口类型分类

业务类接口：提供业务接入能力，整合不同子系统间的业务流。

数据类接口：提供数据交换以及数据整合能力。

安全类接口：提供安全访问和隔离的能力。

系统统一采用可信Web Service、XML技术实现应用交互。所有基于可信Web Service开发的服务型应用接口应采用WSDL标准写出描述文件。以WSDL标准定义的服务接口描述可以在可信服务注册中心注册或直接提供给服务调用方。应用服务调用方通过查询可信服务注册中心或从服务提供方取得所需Web服务的调用规范，通过可信SOAP客户端调用服务方提供的可信Web Service服务接口，完成应用的交互。通过以服务和API方式提供可信消息服务的调用接口，为应用开发中集成各种用户交流手段提供安全、方便的解决方案。

共享数据接口要求

1)采用XML格式实现跨应用的数据共享和交换；

2)接口调用采用WebService的方式实现，同时数据格式以xml的形式传输；

安全接口要求

1)基于SSL协议的安全认证连接和信息保密传输；

2)支持多种应用协议，包括HTTP、FTP、Telnet、数据库协议等；

2.4.2 接口设计模式

采用WebService方式

优点：

1)可操作分布式应用程序；

2)普遍性、使用HTTP和XML进行通信；

3)Web Service 可以穿越防火墙，真正的自由通信；

4)通过 SOAP 协议实现异地调用；

缺点

性能低，如果是局域网之间没必要采用WebService方式。

基于数据封装接口

优点

1)访问速度快；

2)调试方便，开发效率高；

缺点

直接对数据库操作，不安全。

第三章系统功能设计

3.1 移动应用基础平台建设

某保险公司WAP站的信息基本上来源于基础的应用系统或业务系统，需要对这些数据进行处理、优化、过滤以适合移动端使用。

主要功能设计分为两部分。如下图：

Wap站第一部分是进行产品展示及推广功能模块的实现，主要是针对某保险公司旗下的所有产品进行展示及推广。包括产品展示，产品详情，专题等功能模块。

Wap站第二部分是进行产品在线销售及支付功能模块的实现，主要是允许客户通过手机Wap站选购某保险公司旗下的产品，并可以自由筛选适合自己的险种，实现在线投保并完成支付等。包括登录注册，产品筛选，投保支付等模块。

另外，还有一些与公司网站统一身份系统进行有效对接、WebService接口的对接、后台管理对接等操作。

3.1.1 功能结构图

3.1.2 Wap站功能说明

3.1.2.1登录注册

保户的需要登录后才能进行支付等操作，在WAP站上注册的新用户，也可以登录到网站上进行支付等操作。网站上以经有的旧用户可以用之前的用户名及密码登录WAP站，登录后可以操作WAP站上所有功能。

3.1.2.2会员中心

保户成为公司公员，登录系统后，可以在会员中心模块中修改自已的基本信息，查看自已的积分等。可以查看自已在开心宝上的近期订单，未完成支付的订单可以继续完成支付。已经完成的订单可以取消。

3.1.2.3订单管理

保护可以管理自已的订单，订单有3种不同的状态，待支付、已支付、已取消，未完成支付的订单可以继续完成支付。已经完成的订单可以取消。

3.1.2.4积分管理

跟据后台的积分设置，保户在购买过某保险公司的相关产品后，系统会自动发给保户一定的积分做为奖励。保户可以在手机上方便的查看管理自已的积分。

3.1.2.5投保模块

保户在网站上选择适合自已的产品后，输入投保人的投保信息，比如投保年龄，投保期限等，系统自动计算出所需要的保费。确定投保后，填写投保人个人信息如姓名、证件、性别、手机号等信息，提交订单后进入到支付模块。

3.1.2.6支付模块

系统提供多种支付方式，用户提交成功的订单，可以使用支付宝及网上银行进行支付。支付不成功系统会给出不成功提示。

3.1.2.7公司展示

展示公司的简史、公司的领导、公司组织机构等信息。在后台维护对这些信息进行维护，通过接口调用展示到手机端。

3.1.2.8产品展示

针对公司的产品信息，系统管理员在现有网站的后台进行发布后，在手机端可以直接将最新的产品以列表的形式展示出来，点击某一个产品后，可查看该信息详情。

3.1.2.9产品详情

展示保险产品的详细信息，比如产品的缩略图，产品简介，累计销售数量，保费等。

3.1.2.10专题模块

对特定的产品可以跟据后台设置的数据，以专题的形式展现。

3.1.2.11限时优惠

在后台设定一定数量的商品在一定时间内以低于市场价进行促销活动.设定的这些产品会在这个模块中展示。

3.1.2.12热门推荐

在销售过程中有一些经常被保户购买的产品，或是在后台手动设置为推荐的商品，将在热门推荐中展示。

第四章系统实施

4.1系统实施步骤

系统实施步骤图

系统实施的步骤如图所示，该图是参照软件工程的一般步骤，综合系统的特点，细化而成，将系统每步的成果及应形成的文档标出。属性数据的采集以及硬件系统的安装调试等工作，主要数据在系统集成前应完成。

首先得明确一点，系统实现的成功与否，有许多因素，最重要的是用户与系统设计者通力合作。一个系统的实现，有系统设计者的工作，也有用户的工作，而且得配合得当。

4.2系统调研

调研考察与用户需求分析是系统设计成功的关键，这个过程就是客户将系统要完成的工作描述给系统设计者，系统要建成什么样子；另外，客户的业务流程要描述给系统设计者。系统设计者要把客户的思想领悟过来，领悟的多少基本决定系统的成功与否，因为理解了客户的思想才能分析客户的思想；哪些在现实条件或技术上是合理的；哪些功能计算机不可能实现；哪些功能应变通实现。并从客户角度为客户建议应增加哪些功能；从技术角度为客户提高系统的档次。总之，客户与系统设计者要充分交流思想，最后要达成一致。这里指的客户是客户的业务骨干。从文字上体现，用户提交用户需求书，系统设计提交调研报告（含调研问题表及业务流程分析书）。从工作上讲，用户要介绍情况，提供有关资料，讨论系统设计者的调研报告；系统设计者要尽量多了解各方面情况，领悟客户的要求，调研市场产品的性能及报价。“多交流，要一致”。一个目标，将客户的想法转换到系统设计者脑中。

4.3概要设计

系统设计者了解客户方情况及要求后，进入概要设计阶段，形成实施方案，客户方对实施方案进行认可论证。实施方案应反映系统的概貌，系统是什么样子，主要内容有：系统的层次结构、总体结构、系统的外部接口示意、系统的配置、系统的业务流程、系统的信息流、系统的功能结构、系统的开发环境及系统的实施步骤。

实施方案还包括系统框架（粗）选型及其根据。系统设计者提交实施方案后，客户方要认真讨论，确定实施方案是否可行。这个方案是设计者与客户方共同的结晶，反映了系统设计对客户方思想的领悟程度。该方案决定了系统的框架，即以后所有工作的蓝本，十分重要，要充分讨论。系统的详细设计、程序编码、系统集成、系统调试等工作主要由系统设计人员完成，客户方作一些必要配合（非技术性工作），同设计者一样，已无法影响到系统的总体框架了；最后的验收是以实施方案为基准的。因此，实施方案非常重要。

4.4详细设计

详细设计与相关工作概要设计确定了系统的框架，详细设计要确定系统的细节项目。概要设计如同打好地基，盖好房子；详细设计如同决定用什么漆、买什么家俱、如何摆放．．．这由系统设计者决定，但得完成客户方的功能要求。详细设计书具有可操作性，程序员或系统实施人员（非系统设计人员）根据详细设计书就可以编码或硬件安装调试。

4.5程序编码及设备的购置、安装、调试

系统的详细设计书是一种可操作性描述，第四步就是根据该设计书的数据结构及软件流程进行程序编码；根据信息库详细设计进行信息库的建立及数据的采集转换等工作；最后进行硬件设备的购置、安装、调试。

4.6系统集成

完成程序的编码及设备的购置、安装、调试后，要将几部分按系统的详细设计书进行集成，使系统成为一个整体。此时，各种数据均应按计划采集完毕。

4.7系统调试

系统集成后进行综合调试。

4.8系统验收

双方依据有关标准，对系统进行全面的验收。

栏目列表