人教口语app系统软件技术委托开发项目投标方案(技术标)

目录

第一章、生产研发部分2

第一节、项目需求理解2

第二节、方案整体设计45

第三节、系统功能55

第四节、系统性能73

第二章、项目组织管理125

第一节、项目角色与职责125

第二节、项目进度计划131

第三节、项目管理方案135

第三章、售后服务168

第一节、售后服务方案168

第二节、运行保障体系173

第三节、培训方案177

第四节、知识转移183

1

第一章、生产研发部分

第一节、项目需求理解

1.系统功能性需求分析

（1）功能划分

本次开发任务对如下功能模块进行功能的新增和调整

：

注册登录业务流程重构、账号的数据操作权限调整、

页面的优化和兼容性调整、支付优化、会员策略调整、视

频音频课下架开关、单词增加关联词组、教辅绑定改版。

（2）功能描述

1、注册登录业务流程重构

应用场景

针对新用户，用户在进行账号注册时，强制绑定手机

号；

针对老用户，如果没有绑定过手机号的用户，进入APP

时，需要弹窗提示用户去进行手机号绑定，才可以使用APP

功能；

需求分析

2

需求实现

1、用户注册时选择第三方登录，进入绑定手机号页面；

2、绑定手机号页面，“跳过”按钮去掉，强制用户进行手

机号绑定；

3

2、历史登录账号

应用场景

用户可以通过历史登录账号，查看登录过人教口语APP

的全部账号；

4

需求分析

在“我的”页面新增历史登录账号功能；

需求实现

在“我的”页面新增“历史登录账号”功能栏，点击

进入历史登录账号页面，可查看历史登录账号列表，显示

历史登录账号和对应登录设备；

5

3、游客账号取消

应用场景

针对新用户进入APP的账号必须要先走注册登录流程

，APP不在支持游客账号；

针对存在注册账号和游客账号两种权限的老用户，进

6

行账号数据的合并；

需求分析

游客账号取消；

需求实现

不提供游客查看功能，关闭游客账号权限，进入APP

必须注册；

4、根据登录设备查找历史账号

应用场景

根据用户登录端口的不同，管理后台需实现可查看登

录账号所使用的设备，并且通过用户的登录设备可查询，

此设备历史登录过的账号；

需求分析

需求实现

7

实现账号、设备双向查找；

5、注销账号验证

应用场景

在用户注销账号时，增加手机验证功能，需要用户发

送并正确填写验证码，才可以注销账号；

需求分析

注销账号，增加手机验证功能；

需求实现

用户进入注销账号页，点击“确认注销”按钮后，增

加手机验证功能；

8

6、VIP相关调整

应用场景

我的页面，非会员不显示VIP标识；

VIP页面，调整非会员的VIP卡片；

需求分析

页面样式调整；

9

需求实现

我的页面，非会员不显示VIP标识；

10

VIP页面，调整非会员的VIP卡片；

11

12

7、关于我们

应用场景

删除客服相关文案；

需求分析

页面样式调整；

需求实现

删除客服相关文案；

13

14

8、兼容性问题

ipad13单词展示的兼容问题，android首页和我的

页面兼容问题，大字体兼容问题；

9、买错课本优化

在购买课本时，新增新手引导的引导页，降低用户买

错课本的操作，同时考虑到用户交互的友好性，允许用户

跳过；

针对买错课本的用户，通过后台配置支持策略，用户

可查看买错课本后，APP支持的对应策略，进行对应操作；

10、支付优化

单科、会员、包月会员鉴权流程与权限时间调整，优化

前后端校验机制；

帐号历史权限、历史订单记录；

定时任务新增报警机制，增加执行日志，代码优化；

客户端订单与权限合并，前后端权限一致。增强客户端

订单可读性，增加兑换码、激活码订单、管理员授权内

容；

订单权限校验优化，异常订单处理流程（自动续费、订

15

单期间无

权限情况）；

11、包月会员策略调整

到期短信提示功能，微信续费签约，1天内未完成支付

发送短息提醒，超X天未完成支付则解约；

微信续费权限延时2天（不叠加），苹果续费新增过渡

期；

增加解约策略：注销账号自动解约，包月会员购买会员

产品时询问是否解约。

新增解约入口；

客户端新增签约状态，后台优化签约状态和记录；

鉴权流程及权限时间调整；

12、视频音频课下架开关

新用户无法看到入口；

老用户可査看入口，不可购买；

13、单词增加关联词组

16

客户端增加关联词组模块、如近义词、反义词、相关短

语等。

后台对单词内容增加词组字段及相关编辑功能。例句支

持多个展示；

14、教辅绑定改版

教辅首次绑定、更换改版；

教辅分册次统计埋点，记录绑定数据；

针对上述需求，首先需要经双方协调，形成《需求调

研计划》及《需求调研大纲》，确定准备工作、需求调研

的内容、方法方式以及人员和日程安排等内容，经双方同

意后按此计划开始调研。调研正式开始前项目开发组应检

查所有必要的准备工作已经圆满完成。

项目开发组根据调研中系统实际技术需求和各个子系

统的业务需求，编写并向工程领导小组提交符合

CMMILEVEL3规范要求的《系统需求分析报告》，并由项目

组评审，不合格的部分进一步完善调研；评审通过后由双

方共同签署评审意见，并正式生效。

对于软件生产过程而言，需求阶段是整个过程中最重

要的阶段，需求分析成果的好坏将直接导致项目的成功与

17

否，因此合作双方在此阶段多投入是值得的。而且一旦评

审通过并生效，则需求报告将成为系统的设计、开发、测

试、实施试运行和项目验收的基本依据之一，因此原则上

用户需求将不再因为其它因素的改变而变更，如需进行此

种变更，需经双方项目负责人协商确定。

18

2.系统非功能性需求分析

（1）质量需求

代码质量需求

（1）对于重构或新功能开发，要求使用行业内通用

的编码规范进行约束。

（2）代码应具有良好可读性、可扩展性、可维护性

以及可重用性和可测试性。

（3）要求以自动化代码质量检查和团队成员共同代

码走查相结合的方式，保证所有上线的代码都经过机器与

人工多个环节的检查。

（4）基于git进行代码版本管理，代码分支划分科

学、合理，确保代码安全、稳定。

服务质量需求

（1）本期开发内容无功能问题，项目整体功能测试

用例通过率高于95%

（2）App崩溃率低于0.5%

（3）故障修复需在1小时内做出明确响应和安排，

在4小时内为甲方提供维修服务，故障修复时间不得超过

19

36小时。若需要现场服务才能解决问题，应在8小时内到

达用户现场。

（2）性能需求

（1）7期开发期间，需要对人教口语app分阶段优

化产品系统架构、技术架构、应用架构，以降低用户增长

对原系统带来的性能和安全风险以及资源成本。

（2）为保证口语系统在开学季高并发下的用户体

验，满足在现有2台8cl6g应用服务器3台8cl6g数据库

（读写分离一写两读）条件下接口达到lOOOqps并且响应

时间在1s。

（3）安全需求

漏洞修复

应按照甲方需求按时完成人教口语App的漏洞修复工

作，并配合完成漏洞修复验证工作。

等保测评

应按照甲方要求按时配合完成人教口语App以及后台

服务的年度等保测评工作，包括但不限于安全内容整改、

资料撰写、人员配合等。

App安全认证

20

应按照甲方要求按时配合完成App安全认证相关工

作，包括但不限于安全内容整改、资料撰写、人员配合

等。

（4）兼容性需求

乙方应在七期开发期间，确保应用软件在实际用户

toplO的机型、分辨率、操作系统、新出设备和操作系统

上，功能测试用例通过率高于95%,app崩溃率低于0.5%,

兼容测试用例通过率高于90%；

（5）其他需求

数据支撑需求，包括但不限于财务系统、账号中心、

大数据平台等。

维保服务需求，软件验收合格之日起向甲方提供12个

月的维保服务。在维保期间，乙方承诺向甲方提供免费的

应用软件的答疑、修复、技术支持及免费版本升级，以保

证甲方的正常使用及整个系统正常运行。

（6）技术服务需求

1、产品交付

人教口语存在多个版本交付情况，在每个版本交付前

需要交付人充分测试，包含单元测试、集成测试和系统测

21

试，要求制定测试计划、编写测试用例、出具相应的测试

报告，确保交付物质量。

2、产品验收

开发完成后，需要在验收时提供第三方测试公司出具

的测试报告，测试报告相关指标需要满足招标文件技术需

求的各项要求。

3、项目进度管理

项目在开发阶段，每个开发任务有明确的版本计划和

上线时间点，进度落实到个人。以周会或双周会对项目进

度进行校准。

4、运营维护

支持产品的运营需求，如财务对账、运营活动等相关

产品数据的提供。支持客服反馈的技术答疑。

5、系统维护

开发完成后，交付方需要在维保期内提供bug修改、

运营维护等相关服务。

（7）业务运营及维护工作

日常功能改进、bug修复；

22

运营活动支持；

对账报表、数据统计、埋点管理等日常维护工作；

配合数字公司要求，进行相关系统测试、代码及漏洞修

复工作；

（8）项目安全、合规相关工作

配合等保、安全认证相关合规工作的资料编撰，功能开

发、修复和升级。

（9）目标前景

1.能够如期完成约定的委托开发任务，确保人教口语

业务稳定运行的持续性和连贯性。

2.提供成熟可行的移动端产品运营咨询服务。

3.提供业务相关的数据支持、技术咨询支持。

3.项目重点难点分析

本次开发任务中，主要包含对现有系统的升级优化和

新功能的开发，重点难点如下：

23

（1）系统功能对接

要求开发团队在对现有系统进行需求理解的基础上进

行系统优化，并在此基础上开发新功能，开发团队必须具

备新老系统对接的开发能力；

系统接口标准：

RESTful架构，就是目前最流行的一种互联网软件架

构。它结构清晰、符合标准、易于理解、扩展方便，所以

正得到越来越多网站的采用。

REST（RepresentationalStateTransfer），REST的

名称"表现层状态转化"中，省略了主语。“表现层"其实指

的是"资源”（Resources）的"表现层"。

资源（Resources）

所谓"资源"，就是网络上的一个实体，或者说是网络上

的一个具体信息。它可以是一段文本、一张图片、一首

歌曲、一种服务，总之就是一个具体的实在。你可以用

一个URI（统一资源定位符）指向它，每种资源对应一

个特定的URI。要获取这个资源，访问它的URI就可

以，因此URI就成了每一个资源的地址或独一无二的识

别符。

24

所谓"上网"，就是与互联网上一系列的"资源"互动，调

用它的URI。

表现层（Representation）

"资源"是一种信息实体，它可以有多种外在表现形

式。我们把"资源"具体呈现出来的形式，叫做它的"表现层

"（Representation）。

比如，文本可以用txt格式表现，也可以用HTML格

式、XML格式、JSON格式表现，甚至可以采用二进制格

式；图片可以用JPG格式表现，也可以用PNG格式表现。

URL只代表资源的实体，不代表它的形式。严格地说，

有些网址最后的".html"后缀名是不必要的，因为这个后缀

名表示格式，属于"表现层"范畴，而URI应该只代表"资源

"的位置。它的具体表现形式，应该在HTTP请求的头信息

中用Accept和Content-Type字段指定，这两个字段才是

对"表现层"的描述。

状态转化（StateTransfer）

访问一个网站，就代表了客户端和服务器的一个互动

过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意

25

味着，所有的状态都保存在服务器端。因此，如果客户端

想要操作服务器，必须通过某种手段，让服务器端发生"状

态转化"（StateTransfer）。而这种转化是建立在表现层

之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就

是HTTP协议里面，四个表示操作方式的动词：GET、

POST、PUT、DELETE。四个表示操作方式对应对应四种基本

操作

GET获取资源

POST新建资源

PUT更新资源

DELETE删除资源

综合上面，RESTful架构的内容：

26

每一个URI代表一种资源；

客户端和服务器之间，传递这种资源的某种表现层；

客户端通过四个HTTP动词，对服务器端资源进行操

作，实现"表现层状态转化"。

RESTfulAPI设计

API与用户的通信协议

采用HTTPs协议

域名

用api关键字标识接口url

示例：

#应该尽量将API部署在专用域名之下。

#表示前后端数据交互

#应该尽量将API部署在专用域名之下。

/api/

27

路径

路径又称"终点"（endpoint），表示API的具体网

址。

在RESTful架构中，每个网址代表一种资源

（resource），所以网址中不能有动词，只能有名词，而

且所用的名词往往与数据库的表格名对应。

HTTP动词

对于资源的具体操作类型，由HTTP动词表示。

示例：

GET（SELECT）：从服务器取出资源（一项或多

项）。

POST（CREATE）：在服务器新建一个资源。

PUT（UPDATE）：在服务器更新资源（客户端提供

改变后的完整资源）。

PATCH（UPDATE）：在服务器更新资源（客户端提

供改变的属性）。

DELETE（DELETE）：从服务器删除资源。

28

不常用

HEAD：获取资源的元数据。

OPTIONS：获取信息，关于资源的哪些属性是客户

端可以改变的。

状态码

示例：

200OK-[GET]：服务器成功返回用户请求的数

据，该操作是幂等的（Idempotent）。

201CREATED-[POST/PUT/PATCH]：用户新建或修

改数据成功。

202Accepted-[*]：表示一个请求已经进入后台

排队（异步任务）

204NOCONTENT-[DELETE]：用户删除数据成

功。

301：永久重定向

302：暂时重定向

29

400INVALIDREQUEST-[POST/PUT/PATCH]：用户

发出的请求有错误，服务器没有进行新建或修改数据的操

作，该操作是幂等的。

401Unauthorized-[*]：表示用户没有权限（令

牌、用户名、密码错误）。

403Forbidden-[*]表示用户得到授权（与401

错误相对），但是访问是被禁止的。

404NOTFOUND-[*]：用户发出的请求针对的是

不存在的记录，服务器没有进行操作，该操作是幂等的。

406NotAcceptable-[GET]：用户请求的格式不

可得（比如用户请求JSON格式，但是只有XML格式）。

410Gone-[GET]：用户请求的资源被永久删除，

且不会再得到的。

422Unprocesableentity-[POST/PUT/PATCH]

当创建一个对象时，发生一个验证错误。

500INTERNALSERVERERROR-[*]：服务器发生

30

错误，用户将无法判断发出的请求是否成功。

错误处理

状态码是4xx时，应返回错误信息，error当做key。

示例：

{

error:"InvalidAPIkey"

}

返回结果格式

尽量采用json格式避免XML格式

示例：

GET/collection：返回资源对象的列表（数组）

GET/collection/resource：返回单个资源对象

POST/collection：返回新生成的资源对象

PUT/collection/resource：返回完整的资源对象

PATCH/collection/resource：返回完整的资源对

象

31

DELETE/collection/resource：返回一个空文档

（2）接口规范性设计

系统平台中的接口众多，依赖关系复杂，通过接口交

换的数据与接口调用必须遵循统一的接口模型进行设计。

接口模型除了遵循工程统一的数据标准和接口规范标准，

实现接口规范定义的功能外，需要从数据管理、完整性管

理、接口安全、接口的访问效率、性能以及可扩展性多个

方面设计接口规格。

（3）接口定义约定

客户端与系统平台以及系统平台间的接口消息协议采

用基于HTTP协议的REST风格接口实现，协议栈如图所

示。

业务消息

会话数据

HTTP/

HTTPS

32

TCP/IP

底层承载

系统在http协议中传输的应用数据采用具有自解

释、自包含特征的JSON数据格式，通过配置数据对象的

序列化和反序列化的实现组件来实现通信数据包的编码和

解码。

在接口协议中，包含接口的版本信息，通过协议版本

约束服务功能规范，支持服务平台间接口协作的升级和

扩展。一个服务提供者可通过版本区别同时支持多个版本

的客户端，从而使得组件服务的提供者和使用者根据实际

的需要，独立演进，降低系统升级的复杂度，保证系统具

备灵活的扩展和持续演进的能力。

（4）业务消息约定

请求消息URI中的参数采用UTF-8编码并经过

URLEncode编码。

请求接口URL格式：{http|https}://{host}:{port}/

{appname}/{businesscomponentname}/{action}；其

中：

33

协议：HTTPREST形式接口

host：应用支撑平台交互通信服务的IP地址或域

名

port：应用支撑平台交互通信服务的端口

appname：应用支撑平台交互通信服务部署的应用

名称

businesscomponentname：业务组件名称

action：业务操作请求的接口名称，接口名字可配

置应答的消息体采用JSON数据格式编码，字符编码采用

UTF-8。

应答消息根节点为“response”，每个响应包含固定

的两个属性节点：“status”和“message”。它们

分别表示操作的返回值和返回消息描述，其他的同级子节

点为业务返回对象属性，根据业务类型的不同，有不同的

属性名称。

当客户端支持数据压缩传输时，需要在请求的消息头

的“Accept-Encoding”字段中指定压缩方式

(gzip)，如消息可以被压缩传输则平台将应答的数据报

文进行压缩作为应答数据返回，Content-Length为压缩

34

后的数据长度。详细参见HTTP/1.1RFC2616。

（5）响应码规则约定

响应结果码在响应消息的“status”属性中，相应的

解释信息在响应消息的“message”属性中。解释消息为

终端用户可读的消息，终端应用不需要解析可直接呈现给

最终用户。响应结果码为6位数字串。根据响应类型，包

括以下几类响应码。如表中的定义。

响应码描述

0成功

1XXXXX系统错误

2XXXXX输入参数不合法错误

3XXXXX应用级返回码，定义应用级的异常返

回。

4XXXXX正常的应用级返回码，定义特定场景的

35

应用级返回说明。

（6）数据管理

业务数据检查

接口应提供业务数据检查功能，即对接收的数据进行

合法性检查，对非法数据和错误数据则拒绝接收，以防止

外来数据非法入侵，减轻应用支撑平台系统主机处理负

荷。

对于接口，其业务数据检查的主要内容有以下几个方

面：

数据格式的合法性：如接收到非预期格式的数据。包

括接收的数据长度，类型，开始结束标志等。

数据来源的合法性：如接收到非授权接口的数据。

业务类型的合法性：如接收到接口指定业务类型外的

接入请求。对于业务数据检查中解析出非法数据应提供以

下几种处理方式：

事件报警：在出现异常情况时自动报警，以便系统管

理员及时进行处理。

36

分析原因：在出现异常情况时，可自动分析其出错原

因。如是数据来源非法和业务类型非法，本地记录并做后

续管理，如是数据格式非法，分析网络传输原因或对端数

据处理原因，并做相应处理。

统计分析：定期对所有的非法记录做统计分析，分析

非法数据的各种来源是否具有恶意，并做相应处理。

（7）接口的可扩展性规划与设计

各个端间的通信接口版本信息限定了各个系统平台间

交互的数据协议类型、特定版本发布的系统接口功能特

征、特定功能的访问参数等接口规格。通过接口协议的版

本划分，为客户端升级、其他被集成系统的升级、以及系

统的部署提供了较高的自由度和灵活性。

系统可根据接口请求中包含的接口协议版本实现对接

口的向下兼容。系统平台可根据系统的集群策略，按协议

版本分别部署，也可多版本并存部署。由于系统平台可同

时支持多版本的外部系统及客户端应用访问系统，特别是

新版本客户端发布时，不要求用户强制升级，也可降低强

制升级安装包发布的几率。从而支持系统的客户端与系统

平台分离的持续演进。

37

（8）系统性能优化

由于系统用户数较大，覆盖面广，要求开发团队具备

丰富的Linux系统性能优化经验，以保证系统的流畅性和

稳定性：

一、影响Linux性能的各种因素

1、系统硬件资源

（1）CPU

判断多核CPU不超线程，消耗CPU的业务

（2）内存

消耗内存的业务：内存数据库

（redis/hbase/mongodb）

（3）磁盘IO

消耗磁盘的业务：数据库服务器

（4）网络带宽

消耗带宽的业务：hadoop平台、视频业务平台

2、操作系统相关资源

（1）系统安装优化

38

磁盘分区、RAID设置、swap设置

（2）内核参数优化

ulimit-n（最大打开文件数）

ulimit-u（最大用户数）

（3）文件系统优化

读操作频繁，同时小文件众多的应用：首选ext4文

件系统，接下来依次是xfs、ext3。写操作频繁的应用，

首选是xfs，接下来依次是ext4和ext3对性能要求不

高、数据安全要求不高的业务，ext3是比较好的选择。

3、程序问题

此类问题需要开发人员查看代码，介入处理。但作为

运维人员需要给出程序问题的有力证据。

二、Linux性能优化工具

1、cpu性能评估工具

利用vmstat命令可以对操作系统的内存信息、进程

状态、CPU活劢等进行监视。

对上面每项的输出解释如下：

39

●procs

r列表示运行和等待cpu时间片的进程数，这个值如

果长期大于系统CPU的个数，说明CPU不足，需要增加

CPU。

b列表示在等待资源的进程数，比如正在等待I/O、

或者内存交换等。

●memory

swpd列表示切换到内存交换区的内存数量（以k为

单位）。如果swpd的值不为0，或者比较大，只要si、

so的值长期为0，这种情况下一般不用担心，不会影响

系统性能。

free列表示当前空闲的物理内存数量（以k为单

位）

buff列表示bufferscache的内存数量，一般对块

设备的读写才需要缓冲。

cache列表示pagecached的内存数量，一般作为文

件系统cached，频繁访问的文件都会被cached，如果

cache值较大，说明cached的文件数较多，如果此时

IO中bi比较小，说明文件系统效率比较好。

40

●swap

si列表示由磁盘调入内存，也就是内存进入内存交换

区的数量。

so列表示由内存调入磁盘，也就是内存交换区进入内

存的数量。一般情况下，si、so的值都为0，如果si、so

的值长期不为0，则表示系统内存不足。

需要增加系统内存。

●IO项显示磁盘读写状况

￿Bi列表示从块设备读入数据的总量（即读磁盘）

（每秒kb）。

￿Bo列表示写入到块设备的数据总量（即写磁盘）

（每秒kb）

这里我们设置的bi+bo参考值为1000，如果超过

1000，而且wa值较大，则表示系统磁盘IO有问题，应该

考虑提高磁盘的读写性能。

●system显示采集间隔内发生的中断数

￿in列表示在某一时间间隔中观测到的每秒设备中断

数。

41

￿cs列表示每秒产生的上下文切换次数。

上面这2个值越大，会看到由内核消耗的CPU时间会

越多。

●CPU项显示了CPU的使用状态

￿us列显示了用户进程消耗的CPU时间百分比。us的

值比较高时，说明用户进程消耗的cpu时间多，但是如果

长期大于50%，就需要考虑优化程序或算法。

（3）uptime命令

uptime是监控系统性能最常用的一个命令，主要用来

统计系统当前的运行状况，输出的信息依次为：系统现在

的时间、系统从上次开机到现在运行了多长时间、系统目

前有多少登陆用户、系统在一分钟内、五分钟内、十五分

钟内的平均负载。

2、内存性能评估

（1）free命令

free命令是监控linux内存使用状况最常用的指令

一般有这样一个经验公式：应用程序可用内存/系统物

理内存>70%时，表示系统内存资源非常充足，不影响系统

42

性能，应用程序可用内存/系统物理内存<20%时，表示系统

内存资源紧缺，需要增加系统内存，20%<应用程序可用内

存/系统物理内存<70%时，表示系统内存资源基本能满足应

用需求，暂时不影响系统性能。

（2）sar/pidstat

此两个命令主要用于监控全部或指定进程占用系统资

源的情况，如CPU，内存、设备。

3、磁盘性能评估

通过“iostat–d”命令组合也可以查看系统磁盘的使

用状况，并分析输出。

4、网络性能评估

（1）ping命令

（2）netstat命令

（3）mtr/traceroute命令

跟踪网络路由状态，推荐使用mtr，劢态跟踪网络路

由，用于排除网络问题非常方便。

三、系统性能分析标准

43

44

第二节、方案整体设计

1.项目概述

为了更好地践行教育信息化、教育资源数字化建设，

人教数字出版有限公司（以下简称数字公司）依托人民教

育出版社深耕数字教材市场，按照“服务至上、示范引

领、安全运行”的工作要求和思路推出“人教口语”这款

面向中小学英语垂直学科的数字化资源应用。应不断增长

的用户人数和使用需求，数字公司需要对人教口语app及

相关业务系统进行升级维护和部分产品功能开发，因此开

展人教口语app七期技术委托开发的招标工作。

人教口语app的开发范围涉及iOS、android、鸿蒙系

统的移动设备（包含手机和平板电脑），以及PC端的人教

口语运营管理系统。

2.项目总体实施原则

1．承建方成立领导亲自挂帅的项目小组，在调研、设

计、编码、安装调试、测试、培训、运行、验收、售后服

务等项目的各个阶段，配合系统开发方的工作，一方面可

以培训自己的技术维护队伍，为系统的使用保驾护航；另

一方面，在开发过程中，协调用户方和承建方的关系，保

证项目的顺利进行，及时发现问题，并对项目进度和质量

45

进行监督。

2．采用“两手抓”的方针，一手抓开发、一手抓使用

对于软件项目，之所以称为一个工程，很大程度上是

因为软件项目的建设，除了技术因素外，还有很多的非技

术因素需要考虑，并且必须被得到重视。衡量一个软件项

目是否成功，很大程度上不是看这个软件项目采用了多么

先进的技术，而是软件对用户来说是否实用，是否能够帮

助用户解决许多预期的问题。国内很多软件项目的失败，

很大程度上是使用抓得不够。建议在项目的试运行过程

中，在抓系统维护的同时，也要狠抓系统的使用，开发方

和用户方齐心协力帮助业务人员从原来的手工处理转到计

算机辅助处理上来，在业务人员适应计算机辅助业务处理

的过程中，尽可能早发现系统中存在的问题，从而最大可

能地使系统保质保量的按时完成。

3．数据同程序同等重要

该系统的建设，数据位于首要的地位，程序的编写完

成，仅仅意味着系统完成了一半，数据的收集、整理、录

入，对系统的建设来说同等重要。在项目实施过程中，一

定要重视系统中数据的录入工作，充分估计数据处理的难

度，在系统建设之初，就将数据工作提到议事日程上来，

46

安排相应的资金、时间等，将数据工作落到实处，只有这

样才能争取系统早日达到实用化。

3.项目总体推进计划

为了有效地保证系统开发的质量，整个系统建设的全

过程划分为准备、设计、开发、实施和运行阶段，每个阶

段完成相应的任务，确保信息系统的建设。

软件安装完成并确认可在系统正常运行后，开始相关

业务人员的培训；在培训开始之前需要由双方协商形成

《培训计划》，明确培训环境、条件及方式，参加人员，

课程课时等详细内容，由双方现场实施负责人签字后生

效，并分别开始着手准备，在既定时间内完成。

4.项目总体设计原则

（1）建立规范

保证设计的一致性

对内部：多个设计师合作，依然能保证设计风格的统

一。

对用户：提高用户体验，提高操作效率，加深对产品

的记忆。

47

提高开发效率

与前端有效沟通的工具，提高设计还原度，降低对接

成本。

开发可以建立公共组件库，极大的提高了开发效率。

方便产品迭代

随着产品的业务变化，发现一些问题或者需要优化用

户体验的时候，针对单个控件进行调整，就可以影响全

局，十分便捷。

（2）字体规范

文字是App中最核心的元素之一，产品传达给用户的

内容。字体有无衬线字体和衬线字体。无论iOS还是

Android系统，它们都有内置的默认字体可供设计师使

用。用心处理好字号大小、字体颜色与字体间距的处理

上。

用户界面设计中，字体是界面设计中的基本元素。设

计师要设计好界面中的字体颜色、字体间距、字号的大

小、

字重等思考。

48

苹果系统中默认的字体是：苹方字体。英文字体和数

字字体是：旧金山字体，SanFrancisco字体。

其中数字字体比较好的字体可以用：Dinner字体。

安卓系统默认的中文字体是：思源黑体。英文字体

是：Roboto字体。

界面设计中的字体设计规范，如下图所示。

（3）设计原则

为了最大限度地提高影响力和影响范围，请在想象应

用程序的身份时牢记以下原则。

审美完整性

审美完整性表示应用程序的外观和行为与其功能的集

49

成程度。例如，一个可以帮助人们执行重要任务的应用程

序可以通过使用微妙，醒目的图形，标准控件和可预测的

行为来使他们专注。另一方面，沉浸式应用程序（例如游

戏）可以提供引人入胜的外观，带来乐趣和刺激，同时鼓

励发现。

一致性

一致的应用程序通过使用系统提供的界面元素，知名

的图标，标准的文本样式和统一的术语来实现熟悉的标准

和范例。该应用程序以人们期望的方式结合了功能和行

为。

直接操纵

屏幕内容的直接操作可以吸引人们并促进理解。用户

在旋转设备或使用手势来影响屏幕内容时会经历直接的操

纵。通过直接操作，他们可以看到其操作的直接可见结

果。

反馈

反馈确认行动并显示结果，以使人们了解情况。内置

的iOS应用程序可响应每个用户操作提供可感知的反馈。

轻触时，交互元素将突出显示，进度指示器传达长时间运

50

行的操作的状态，动画和声音有助于阐明操作的结果。

隐喻

当应用程序的虚拟对象和动作是扎根于现实世界或数

字世界的隐喻时，人们会更快地学习。隐喻在iOS中可以

很好地工作，因为人们可以与屏幕进行物理交互。他们将

视图移开以隐藏下面的内容。他们拖动和滑动内容。他们

切换开关，移动滑块并滚动选择器值。他们甚至浏览书籍

和杂志的页面。

（4）组建规范

ios系统和安卓系统都提供了一些固定的官方组件规

范。遵循其官方组件规范，可以极大提高设计和开发效

率，同时降低用户的学习成本。其中最常见的规范化组件

包括顶部的状态栏、导航栏、底部标签栏和工具栏。

状态栏

ios是20pt,安卓是24dp.

导航栏

ios是44pt,安卓是56dp.

标签栏

51

ios的高度是49pt,安卓标签栏的高度是48dp.

工具栏

工具栏的高度是44pt,安卓是48dp.

字体是苹方字体；英文是SF英文字体。思源黑体，

roboto英文字体。

ios设计是11pt到29pt左右，一级主题是24pt以

上,二级标题是20pt左右。

内容，导航栏标题是18pt。三级标题是16pt。文字

内容一般是14pt

品类区图标内容：12pt。底部TAB图标文字：10pt

到11pt

5.项目建设思路

在保证基础的业务流程合规，数据安全的前提下，根

据业务需求及客户群体特征，尽量简化操作流程。根据项

目要求该平台系统须以源码方式部署到项目服务器上，通

过已部署成功的后台系统，配置iOS、Android、鸿蒙系统

移动设备（包含手机和平板电脑）相关参数实现与前端联

通调用。

52

6.项目实施策略

通过业务咨询、产品培训、系统操作的形式分析本次

招标范围内的需求，分析差异性需求，根据差异化需求的

情况，我们采取产品功能升级与个性化需求开发的模式进

行处理，既确保了产品的成熟度和稳定性，有兼顾了个性

化需求，通过敏捷开发模式，快速迭代保障项目按时、高

质量的上线运行。

在项目中，需要多方共同努力,发起方和实施方作为一

个整体，确定共同的项目目标，同时需要良好的沟通和配

合，相互协调，才可能及时发现问题，及时纠偏，逐步实

现确立的项目目标。为此，必须制定确实可行的、清晰的

实施策略，以及各阶段的实施方法，用于指导项目计划的

制定、资源的搭配。

项目成功实施的关键因素：

明确的项目关系界定，包括：项目实施中的授权和职

责。项目管理机构项目管理办公室Project

ManagementOffice（PMO）作为本项目的管理机构,管理

项目的日常活动，保证本项目的有效实施和最终成功上

线，由项目发起方和实施方共同组成，负责整个项目的目

标确定、计划、控制和实施，制定文档、问题管理、风险

53

控制、质量控制、评审和报告的标准和过程，同时还需要

一个项目指导委员会ProjectSteeringCommittee

（PSC），负责需求管理、系统架构、技术设计、接口设计

规范、技术开发规范、系统性能和可靠性设计、问题解

决、系统支持等。

完善有效的项目管理架构，成立项目指导委员会

ProjectSteeringCommittee（PSC），主要由项目总监、

项目经理、咨询顾问、项目管理办公室成员（PMO）组成，

PSC将拥有最终决定项目范围、实施优先级、资源分配、重

要决策，以及处理项目间关系的权力；任何问题和冲突必

须通过项目执行委员会ProjectWorkingCommittee

（PWC）提交PSC统一决策，PWC主要包括项目总监、项目

顾问和所有项目经理；PWC在PMO的领导下、在PSC的指导

下，负责整个项目的实施过程。

54

第三节、系统功能

1.平台整体架构图

55

2.平台总体功能图

56

57

3.功能设计原则

（1）单一职责原则（LSP）

单一职责原则的含义是：只能让一个类有且只有一个

职责，因为如果有两个职责，当职责1发生改变，需要修

改这个类的代码时，这个修改有可能会导致职责2的运行

发生问题。

单一职责的优点是分类清晰，适用于接口、类、方

法，一个类一个方法只完成一件事情，避免了代码耦合出

现的问题。但是分得太细又会人为地增加系统的复杂性，

为开发制造了麻烦。

（2）里氏替换原则（LSP）

里氏替换原则针对的是有继承关系的子类和父类，为

了减少继承的弊端而生，含义是只要有父亲出现的地方子

类就可以出现，并且替换为子类也不会有任何错误（相反

父亲未必就能完美替换子类）。

为了达成这个目的，子类就必须要实现父类的所有方

法，即父类的方法必须是子类全部需要的、在调用时，必

须使用父亲/接口、子类可以有自己的个性、实现父类的方

法时输入参数可以被放大、实现父类的输出结果时结果可

58

以缩小。

里氏替换的优点是让继承得到最大作用发挥，并减少

继承的弊端，缺点是不太灵活。

（3）依赖倒置原则（DIP）

依赖倒置原则的定义是，实现类之间不发生直接的依

赖关系，其依赖关系是通过接口或抽象类产生的，也就是

面向接口编程。

依赖倒置原则的优点是，通过接口使各个类或模块彼

此间独立，不相互影响，实现模块之间的松耦合。缺点是

增加了额外维护接口和类的工作量。

（4）接口隔离原则（ISP）

接口隔离的原则是，建立单一的接口，不要建立庞大

臃肿的接口，尽量细化接口，接口中的方法尽量少。

每个模块都应该是单一的接口，提供给几个模块就应

该有几个接口，也就是接口模块化、独立化。

与单一职责原则不一样，单一职责原则中，一个接口

可以有多个方法，这多个方法提供给多个模块访问，而接

口隔离原则则是倡导一个模块使用一个一个接口，而不是

59

所有的方法都放在同一个接口中。

这样的设计原则虽然可以让系统内聚提高，但是也增

加了结构的复杂化，导致开发难度增加。

（5）迪米特法则（LOD）

迪米特法则又称最少知道法则，也就是一个对象应该

对其他对象有最少的理解，即一个类应该对自己需要耦合

或需要调用的类知道的最少。可以降低系统之间的耦合，

提高系统的健壮性。

在下面这个例子中，明星类和粉丝类要发生通信，就

需要一个经纪人的中间类，从而达到了最少知道法则。这

样虽然能降低耦合度，但是也大大提高了系统复杂性。

（6）开闭原则（OCP）

开闭原则也就是，软件实体（类、模块、方法）应该

对扩展开发，对修改关闭，也就是软件需要变化时，尽量

通过拓展软件实体的行为来实现，而不是修改已有的代

码。

开闭原则是面向对象设计的终极目标，其他原则可以

看做是开闭原则的实现方法。

60

61

4.功能安全性设计

（1）“严禁”原则

严禁使用明文或在程序/脚本文件中写死密码

应用系统中涉及的任何密码，均严禁使用明文，并严

禁将密码写在代码/脚本文件中。

严禁在网页源码中暴露应用处理逻辑

严禁在网页源代码中出现类似SQL、脚本、条件判断等

应用处理逻辑。

严禁在超链接中出现参数信息

严禁基于Web的应用将数据库连接用户、密码等重要

参数信息放在超链接中，超链接中参数信息、服务调用信

息应进行变形（乱码）或者隐藏，以防止SQL注入攻击，

避免黑客猜测数据库表结构、数据库连接用户和密码。

严禁应用系统设计留有“后门”

严禁以维护、技术支持或者特殊操作为由，设计违反

或者绕过安全规则的任何类型的入口和设计文档中未说明

的任何模式的隐藏入口。

（2）必须原则

必须提供应用系统用户的身份识别功能

62

身份识别是信息安全服务的基础，基本原则是要做到

用户区分的唯一性，认证是基于身份识别的，身份识别最

常见的形式就是用户ID，与密码组合标识一个用户身份。

必须对密码加密

密码分为交易密码和用户登录密码等。

应用系统应对交易密码的全部使用环节进行硬加密，

包括密码的产生、密码录入、密码修改、密码的传输、密

码的保存。应用系统应支持联机密钥修改，避免加密设备

密钥变更对应用系统正常运行的影响。

应用系统应对系统的使用用户密码进行加密（可以是

软加密），包括密码的产生、密码录入、密码修改、密码

的传输、密码的保存。软加密时应确保软加密算法具有足

够的强度，并且确保密钥存储安全，对密钥的访问应严格

控制。同时，还应采取必要的措施，确保软加密算法的安

全。

必须保证密码安全传递

应用系统应建立完善的密码传递机制，如采用硬件转

加密、密码信封等方式，确保密码在系统和使用用户

（人）之间的安全传递。

必须保证密码强度

63

应用系统必须设计密码强度检查机制，密码错误次数

限制等措施，避免用户使用简单密码，防止黑客对密码进

行暴力破解。

必须提供用户账户锁定功能

当用户帐户几次登录尝试失败后，必须禁用该帐户并

将事件写入日志。同时必须提供用户帐户解锁功能。必须

在设计阶段将这些策略明确下来。

必须支持密码有效期

密码不应固定不变。作为常规密码维护的一部分，通

过设置密码有效期强制应用系统用户对密码进行定期更

改。在应用程序设计阶段，必须考虑提供这种类型的功

能。

必须对前端输入信息进行验证

将输入验证策略作为应用程序设计的核心要素。应假

定所有的输入都是恶意的，不要依赖于客户端的验证，虽

然使用客户端验证可以减少客户端和服务器之间的信息传

递次数。

要做到限制、拒绝或者净化输入，输入验证的首选方

法是从开始就限制允许输入的内容。按照已知的有效类

型、模式和范围验证数据要比通过查找已知有害字符的数

64

据验证方法容易。设计应用程序时，应了解应用程序需要

输入什么内容。与潜在的恶意输入相比，有效数据的范围

通常是更为有限的集合。为了使防御更为彻底，可能还需

要拒绝已知的有害输入，达到净化输入的效果。

（3）尽可能原则

尽可能实现用户的权限最小化

应用用户的权限最小化，控制应用用户对文件、数据

的访问，记录并统计登录历史；对重要信息资源设置敏感

标记并控制对设置敏感标记资源的操作。

尽可能具有防木马程序设计

应用系统尽可能设计必要的措施防止木马程序对密码

的截取。

尽可能使用成熟稳定版本的软件或者工具

软件产品或者工具升级换代非常的迅速，虽然新的版

本会带来很多功能上的提升，但是也可能隐藏着新的缺

陷。所以尽可能在功能满足的情况下使用经过验证的成熟

稳定的版本。

尽可能保证关键信息安全传递

应用系统尽可能完善各种关键信息（例如：磁道信

息、卡片校验码、制卡文件等）传递机制，如采用硬件转

65

加密、密码信封等方式，确保关键信息在系统和使用用户

（人）之间的安全传递。

尽可能提供安全审计功能

在应用系统中发生的各种与安全相关的事件，应尽可

能记录下来。审计记录应包括安全事件的主体、客体、时

间、事件类型、事件内容、事件结果等内容。应提供审计

记录查询、分类、分析和存储保护；能对特定安全事件进

行报警；确保审计记录不被破坏或非授权访问。应为安全

管理中心提供接口；对不能由系统独立处理的安全事件，

提供由授权主体调用的接口。并提供审计功能的启动和关

闭功能。

66

5.总体设计阶段

项目开发组通过对系统的功能、运行和性能要求加以

分析，产生一个高层次的系统结构、软件结构、接口和数

据格式的设计，并向工程领导小组提交《系统设计报告》

（其中包括数据库设计），组织评审并签署评审意见。对

其中评审不合格的部分进一步完善和重新策划，评审通过

后由双方共同签署评审意见，并正式生效，作为后续软件

开发和测试的基础。

该报告内容的变更由双方的现场实施负责人、技术负

责人进行交流即可确定，并需向工程领导小组汇报。

6.详细设计阶段

项目开发组在系统设计报告的基础上，对功能和性能

要求进一步加以分析和细化并且把软件的详细设计文档

化，向工程领导小组提交系统详细设计报告，并由项目组

组织评审并签署评审意见。对其中评审不合格的部分进一

步完善和重新策划，评审通过后由双方共同签署评审意

见，并正式生效，作为后续软件开发和测试的基础。

该报告内容的变更由双方的现场实施负责人、技术负

责人进行交流即可确定，并需向工程领导小组汇报。

67

7.系统开发阶段

为了使用户能够及时获知项目的进展情况，开发小组

需要每周向用户相关领导提交《项目客户周报》，用户项

目组可以随时对项目的工作情况进行检查。

8.系统实施和试运行阶段

首先需要经双方交流协调，形成《项目实施计划》，

确定现场实施的准备工作、人员和日程安排、培训计划、

阶段目标等内容，经双方负责人签字后生效，按此计划开

始现场实施。正式开始现场实施前项目开发组应检查所有

必要的准备工作是否已经完成。

9.项目验收阶段

在试运行期内系统存在一定的细节性问题是工程项目

不可避免的问题，特别是随着用户应用的逐渐深入，此类

需求会逐级提出，此类问题不属于系统的致命性错误；因

此当试运行期内所发现的真正的“问题和错误”收敛到一

定数目以下时，各业务子系统经过一段时间的并行工作新

系统已基本可靠，就可以切换到正式运行阶段，开始正式

运行。

正式运行后，由用户提出验收要求，双方共同制定

68

《项目验收计划》，组成项目验收小组，共同进行项目验

收。维护期的具体工作方式请见售后服务承诺部分，所有

维护工作，包括软件出现问题修改、细节性功能的增强，

用户都要以《问题及修改记录》的书面形式提交给公司，

修改完成后用户应组织相关的业务负责人进行确认，并在

《功能清单》中说明；如遇紧急情况可事后补齐。

项目验收分为功能验收和非功能验收，具体如下：

（1）功能验收标准

系统各项功能运行稳定，数据处理正确。确保应用软

件和开发工具符合知识产权相关政策法规的要求，数据处

理符合信息安全的要求。

（2）非功能验收标准

参照需求规格说明书中的要求，系统各项功能运行稳

定，数据处理正确。

69

（3）分类标准

错误级

描述

别

1.系统的主要功能模块无法正常工作

2.系统与外围系统的数据传输接口无法正常工

作，或数据不正确

3.系统的重要数据处理结果不正确

A

4.系统整体运行不稳定

5.系统主要功能模块或渠道缺失，但双方达成一

致协议的除外

6.系统不符监管、内控、保安需求

7.系统主要功能模块或渠道功能不完善

B8.系统部分非主要交易无法正常工作

9.系统与外围系统的数据传输接口工作不稳定

10.系统个别交易无法正常工作或处理结果错

C误，但可通过其他替代办法进行处理，不影响

业务的正常进行

70

11.因系统设计原因造成系统个别交易运行效

率低

系统在某种情况下才出现的错误，且不影响正常

D

的业务操作

功能错误级别分类

功能验收标准

功能验收错误情况描述

验收结果（允许错误个数）

ABCD

合格0000

性能测

试验收

（错误

基本合格可进行0<=3<=20<=30

后续解

决和完

善）

71

最终验

00<=10<=20

收

不合格除以上两种情况外的其他情况

（一）验收标准

1.功能测试：对招标文件中的服务内容进行测试，所

有功能均可正常使用；

2.业务流程测试：针对该平台典型的业务（优惠劵的

领取、查询、核销）进行测试；

3.易用性测试：软件中各个模块的界面风格保持一

致。

（二）验收资料

1.项目验收申请报告；

2.操作手册及使用手册；

3.源代码及安装说明。

在服务过程中供应商须对行方的一切有关信息进行保

密。

72

第四节、系统性能

1.核心设计原则

核心设计原则：系统各功能模块化程度高，独立性强

，能够方便快捷地进行功能扩展；系统界面全部符合招标

文件技术文件的要求；系统能够稳定、快速的运行；体现

系统健壮性强，数据安全性高，符合教育部安全等保要求

；系统具备完善的数字版权保护能力；开发技术能够兼容

各种操作系统和多种硬件设备，具备新老系统和设备的兼

容能力等。

建设后的系统应具备合理性、规范性、先进性、前瞻

性、安全性、高效性、实用性、可靠性、灵活性、扩展性

、稳定性、可维护性等性能。

（1）功能性

与一组功能及其指定的性质有关的一组属性，具体包

括:

适合性:与规定任务能否提供一组功能以及这组功能的

适合程度有关的软件属性。

准确性：与能否得到正确或相符的结果或效果有关的

软件属性。

73

互用性：与同其他指定系统进行交互的能力有关的软

件属性。

依从性：使软件遵循有关的标准,约定，法规及类似规

定的软件属性。

安全性：与防止对程序及数据的非授权的故意或意外

访问的能力有关的软件属性.

充分考虑系统的安全防护，具备较强的数据管理机制

和控制能力。

系统充分考虑与外部系统之间的接口，实现系统的集

成应用。同时，系统采用开放型的应用接口，具有灵活的

扩充性，满足业务系统的整合需要。

（2）可靠性

与在规定的一段时间和条件下，软件维持其性能水平

的能力有关的一组属性,具体包括：

成熟性：与由软件故障引起失效的频度有关的软件属

性。

容错性：与在软件故障或违反指定接口的情况下，维

持规定的性能水平的能力有关的软件属性。

74

易恢复性：与在失效发生后，重建其性能水平并恢复

直接受影响数据的能力以及为达此目的所需的时间和能力

有关的软件属性充分考虑性价比。

系统采用具有平台无关性、安全性、网络移动性好的

基于JAVA语言，有严格的安全控制机制，可以确保系统的

健壮、安全可靠；在网络上，保证内部系统的数据不被非

法用户所获取。在应用软件的设计上，强化权限管理功

能，具有多级安全机制。通过对各级部门、人员的权限分

配，做到所有人员只能查看与自己相关的数据，并建立完

善的日志管理，做到所有操作都有据可查。

（3）可操作性

与一组规定或潜在的用户为使用软件所需作的努力和

对这样的使用所作用的评价有关的一组属性，具体包括:

易理解性：与用户为认识逻辑概念及其应用范围所花

的努力有关的软件属性。

易学性：与用户为学习软件应用所花的努力有关的软

件属性。

易操作性:与用户为操作和运行控制所花努力有关的软

件属性。

75

软件设计功能合理、应用合理、操作性合理。在操作

上，结合使用人员业务操作习惯，界面友好、方便使用。

保证各级操作人员能够迅速掌握、简单易用。

（4）高效性

与在规定的条件下，软件的性能水平与所使用的资源

量之间关系有关的一组属性，具体包括:

时间特性：与软件执行其功能时响应和处理时间以及

吞吐量有关的软件属性.

资源特性：与在软件执行其功能时所使用的资源数量

及其使用时间有关的软件属性。

（5）可维护性

与进行指定的修改所需的努力有关的一组属性，具体

包括：

易分析性：与为诊断缺陷或失效原因急为判定待修改

的部分所需努力有关的软件属性.

易改变性：与进行修改,排除错误或适应环境变化所需

努力有关的软件属性。

稳定性:与修改所造成的未预料结果的风险有关的软件

76

属性。

易测试性:与确认已修改软件所需的努力有关的软件属

性。

系统应用软件统一安装在组织机构管理服务器上，当

发生系统的重安装、升级等情况时，只需维护根服务器的

软件系统，客户端实现零维护，大大降低维护成本。同

时，如果下属部门、人员出现不懂的业务处理、软件操作

等情况时，无须到现场处理，只需在系统中授权，就可以

在服务器完成相应的操作。

（6）可扩展性

与软件可从某一环境转移到另一个环境的能力有关的

一组属性，具体包括：

适应性：与软件无需采用有别于为该软件准备的活动

或手段就可能适应不同的规定环境有关的软件属性。

易安装性：与在指定环境下安装软件所需努力有关的

软件属性。

遵循性：使软件遵循与可移植性有关的标准或约定的

软件属性。

77

易替换性:与软件在该软件环境中用来替代指定的其他

软件的机会和努力有关的软件属性.

应考虑未来业务的发展和管理的变化，根据业务量和

业务扩展情况能够灵活部署主机设备，以支持冗余和负载

均衡，满足未来风险预警管理系统变化的需要。

（7）标准化

本项目涉及到的各个系统模块设计、系统性能、代码

编写等应符合中国有关软件项目的标准化的要求：

1.软件开发过程中作业标准化；

2.确定每个作业的表示形式；

3.确定每个文档资料的格式；

4.规定组符号；

5.根据软件开发经验，制定出大家能够接受的开发原

则和进度。

整个系统的应用设计需符合业界标准，业务、功能、

界面、内容需保持高度统一性和标准性，从而达到服务的

规范化和管理的高效性。

78

（8）规范性

代码命名风格、常量定义、代码格式、控制语言、注

释规范符合业界标准。

采用成熟的软硬件平台和技术，并符合IT设计原则。

采用行业标准技术，采用可扩展的系统架构，开放式

语言。

按照客户信息化规划统一设计系统结构，特别是应用

系统建设结构、数据模型结构、数据存储结构以及系统扩

展规划等内容，从规划的全局出发、从长远的角度考虑。

（9）先进性

技术水平要保证先进性，符合当代信息技术发展形

势，代表当前计算机科学的发展方向。所选择的各平台供

应商应有能力对该项进行持续开发，可以保证该项技术不

断地更新并可顺利升级而维持系统的先进性。提供良好的

技术支持和技术服务，以满足当前的业务需求，使业务或

生产系统具有较强的运作能力。

技术上采用网络计算技术和分布处理模式，保证技术

上的先进性和前瞻性。

79

采用国际最新的科技成果，从而保证整个系统在整体

技术架构上处于领先地位，系统在建成后几年内不应由于

技术原因而进行较大的调整，可通过升级保持系统的先进

性，延长其生命周期，同时又要保证先进的技术是稳定

的、成熟的。考虑在大量用户并行的情况下，系统整体运

行稳定、快速、高效。

（10）前瞻性

整体设计应具有创新性，考虑未来业务发展的要求，

对于法规政策的变动对业务的影响有充分的认知和考虑。

便于支持行内科技系统建设和发展；

便于通过更换设备、参数修改、外加模块等实现小成

本UI组件升级。

项目建设既充分考虑未来新业务和新需求扩展和支

持，又要充分考虑软件体系结构与IT规划中其他平台和系

统有效衔接，满足未来客户业务发展及管理的需要。

（11）安全性

保证系统的安全，从多个层面提供安全保障措施；主

要采用安全文件传输协议，保证数据的安全，包括数据传

送的安全、数据存储的安全、数据操作的安全；

80

提供健全的安全控管机制，系统运行中不安全、异常

因素能提出预警，可有效防范外部及内部的操作风险。具

有完善的监控功能，对异常能提出预警，并记录下错误日

志，提供错误原因的分析，便于异地维护。

既要采用完善的身份认证机制、分级权限管理机制、

数据加密机制保证统计数据真实性和完整性以及防止统计

数据的不实和泄露，又要从网络、系统、软件、数据库等

方面充分考虑系统的安全，并具备容灾措施和监控手段，

保证信息统计系统安全运行。

（12）高效性

可以及时响应用户请求。能保证高效、稳定的运行设

计合理的业务处理流程，采取必要的技术手段增强系统的

处理能力，最大限度地发挥系统潜能，确保系