系统集成-app系统软件技术委托开发项目投标方案.docx

系统集成-app系统软件技术委托开发项目 投标方案 目 录 第 一 章 生产研发部分 5 第一 节 项目需求理解 5 一、 系统功能性需求分析 5 二、 历史登录账号 6 三、 关于我们 10 四、 系统非功能性需求分析 13 五、 项目重点难点分析 17 第二 节 方案整体设计 34 一、 项目 概述 34 二、 项目总体 实施原则 34 三、 项目总体推进计划 35 四、 项目总体设计 原则 36 五、 项目 建设思路 40 六、 项目实施策略 40 第三节 系统功能 42 一、 平台整体架构图 42 第 四节 系统性能 55 一、 核心设计原则 55 二、 系统开发工具 62 三、 技术实施安全性 72 第 二 章 项目组织管理 89 第一 节 项目角色与职责 89 一、 项目经理 89 二、 产品经理 91 三、 设计师 91 四、 开发工程师 92 第二 节 项目 进度计划 93 第三 节 项目管理方案 96 一、 项目管理流程 96 二、 项目范围管理 96 三、 项目进度管理 97 四、 项目风险管理 101 五、 项目质量管理 108 六、 项目协调与合作计划 114 七、 项目 配置管理 116 八、 项目 变更管理 118 九、 项目 文档管理 119 十、 项目 人员管理 119 十一、 项目 保密管理 119 十二、 项目 测试计划 119 第 三 章 售后服务 123 第一 节 售后服务方案 123 一、 质保期服务 123 二、 非质保期服务 123 三、 24小时应答服务 123 四、 售后服务原则 124 五、 技术支持与服务内容 124 六、 质保承诺 125 七、 服务方式 125 第二 节 运行保障体系 127 一、 运行保障体系 127 二、 故障级别定义 129 三、 服务流程和服务质量保证 130 四、 服务档案建立 130 五、 服务监督 130 六、 服务质量管理 130 第三 节 培训方案 131 一、 培训方案 131 二、 培训目标及总则 132 三、 培训目标 132 四、 培训方式 133 五、 教材目录 134 六、 培训日程及费用 135 第四 节 知识转移 136 一、 对知识转移的理解 136 二、 转移工作流程设计 141 第 一 章 生产研发部分 第一 节 项目需求理解 一、 系统功能性需求分析 功能划分 本次开发任务对如下功能模块进行功能的新增和调整： 注册登录业务流程重构、账号的数据操作权限调整、页面的优化和兼容性调整、支付优化、会员策略调整、视频音频课下架开关、单词增加关联词组、教辅绑定改版。 （2） 功能描述 1、注册登录业务流程重构 应用场景 针对新用户，用户在进行账号注册时，强制绑定手机号； 针对老用户，如果没有绑定过手机号的用户，进入APP时，需要弹窗提示用户去进行手机号绑定，才可以使用APP功能； 需求分析 需求实现 用户注册时选择第三方登录，进入绑定手机号页面； 2、绑定手机号页面，“跳过”按钮去掉，强制用户进行手机号绑定； 二、 历史登录账号 应用场景 用户可以通过历史登录账号，查看登录过人教口语APP的全部账号； 需求分析 在“我的”页面新增历史登录账号功能； 需求实现 在“我的”页面新增“历史登录账号”功能栏，点击进入历史登录账号页面，可查看历史登录账号列表，显示历史登录账号和对应登录设备； 游客账号取消 应用场景 针对新用户进入APP的账号必须要先走注册登录流程，APP不在支持游客账号； 针对存在注册账号和游客账号两种权限的老用户，进行账号数据的合并； 需求分析 游客账号取消； 需求实现 不提供游客查看功能，关闭游客账号权限，进入APP必须注册； 根据登录设备查找历史账号 应用场景 根据用户登录端口的不同，管理后台需实现可查看登录账号所使用的设备，并且通过用户的登录设备可查询，此设备历史登录过的账号； 需求分析 需求实现 实现账号、设备双向查找； 注销账号验证 应用场景 在用户注销账号时，增加手机验证功能，需要用户发送并正确填写验证码，才可以注销账号； 需求分析 注销账号，增加手机验证功能； 需求实现 用户进入注销账号页，点击“确认注销”按钮后，增加手机验证功能； VIP相关调整 应用场景 我的页面，非会员不显示VIP标识； VIP页面，调整非会员的VIP卡片； 需求分析 页面样式调整； 需求实现 我的页面，非会员不显示VIP标识； VIP页面，调整非会员的 VIP卡片； 三、 关于我们 应用场景 删除客服相关文案； 需求分析 页面样式调整； 需求实现 删除客服相关文案； 兼容性问题 i pad13单词展示的兼容问题， android 首页和我的页面兼容问题，大字体兼容问题； 买错课本优化 在购买课本时，新增新手引导的引导页，降低用户买错课本的操作，同时考虑到用户交互的友好性，允许用户跳过； 针对买错课本的用户，通过后台配置支持策略，用户可查看买错课本后，APP支持的对应策略，进行对应操作； 支付优化 单科、会员、包月会员鉴权流程与权限时间调整，优化前后端校验机制； 帐号历史权限、历史订单记录； 定时任务新增报警机制，增加执行日志，代码优化； 客户端订单与权限合并，前后端权限一致。增强客户端订单可读性，增加兑换码、激活码订单、管理员授权内容； 订单权限校验优化，异常订单处理流程（自动续费、订单期间无 权限情况）； 11、包月会员策略调整 到期短信提示功能，微信续费签约，1天内未完成支付发送短息提醒，超X天未完成 支付则解约； 微信续费权限延时2天（不叠加），苹果续费新增过渡期； 增加解约策略：注销账号自动解约，包月会员购买会员产品时询问是否解约。 新增解约入口； 客户端新增签约状态，后台优化签约状态和记录； 鉴权流程及权限时间调整； 12、视频音频课下架开关 新用户无法看到入口； 老用户可査看入口，不可购买； 13、单词增加关联词组 客户端增加关联词组模块、如近义词、反义词、相关短语等。 后台对单词内容增加词组字段及相关编辑功能。例句支持多个展示； 14、教辅绑定改版 教辅首次绑定、更换改版； 教辅分册次统计埋点，记录绑定数据； 针对上述需求， 首先需要经双方协调，形成《需求调研计划》及《需求调研大纲》，确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，经双方同意后按此计划开始调研。调研正式开始前项目开发组应检查所有必要的准备工作已经圆满完成。 项目开发组根据调研中系统实际技术需求和各个子系统的业务需求，编写并向工程领导小组提交符合CMMILEVEL3规范要求的《系统需求分析报告》，并由项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并正式生效。 对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否，因此合作双方在此阶段多投入是值得的。而且一旦评审通过并生效，则需求报告将成为系统的设计、开发、测试、实施试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。 四、 系统非功能性需求分析 （1）质量需求 代码质量需求 （1 ） 对于重构或新功能开发，要求使用行业内通用的编码规范进行约束。 （2 ） 代码应具有良好可读性、可扩展性、可维护性以及可重用性和可测试性 。 （3 ） 要求以自动化代码质量检查和团队成员共同代码走查相结合的方式，保证所有上线 的代码都经过机器与人工多个环节的检查。 （4 ） 基于git进行代码版本管理，代码分支划分科学、合理，确保代码安全、稳定。 服务质量需求 （1 ） 本期开发内容无功能问题，项目整体功能测试用例通过率高于95% （2 ） App崩溃率低于0.5% （3 ） 故障修复需在1小时内做出明确响应和安排，在4小时内为甲方提供维修服务，故障修复时间不得超过36小时。若需要现场服务才能解决问题，应在8小时内到达用户现场。 （2）性能需求 （1 ） 7期开发期间，需要对人教口语app分阶段优化产品系统架构、技术架构、应用架构，以降低用户增长对原系统带来的性能和安全风险以及资源成本。 （2 ） 为保证口语系统在开学季高并发下的用户体验，满足在现有2台8cl6g应用服务 器3台8cl6g数据库（读写分离一写两读）条件下接口达到lOOOqps并且响应时间在1s。 （3） 安全需求 漏洞修复 应按照甲方需求按时完成人教口语App的漏洞修复工作，并配合完成漏洞修复验证工作。 等保测评 应按照甲方要求按时配合完成人教口语App以及后台服务的年度等保测评工作，包括但不限于安全内容整改、资料撰写、人员配合等。 App 安全认证 应按照甲方要求按时配合完成App安全认证相关工作，包括但不限于安全内容整改、资料撰写、人员配合等。 （4）兼容性需求 乙方应在七期开发期间，确保应用软件在实际用户toplO的机型、分辨率、操作系统、新出设备和操作系统上，功能测试用例通过率高于95%, app崩溃率低于0.5%,兼容测试用例通过率高于90% ； （5） 其他需求 数据支撑需求，包括但不限于财务系统、账号中心、大数据平台等 。 维保服务需求，软件验收合格之日起向甲方提供12个月的维保服务。在维保期间，乙方承诺向甲方提供免费的应用软件的答疑、修复、技术支持及免费版本升级，以保证甲方的正常使用及整个系统正常运行。 （6）技术服务需求 1、产品交付 人教口语存在多个版本交付情况，在每个版本交付前需要交付人充分测试，包含单 元 测试、集成测试和系统测试，要求制定测试计划、编写测试用例、出具相应的测试报告，确保交付物质量。 2、产品验收 开发完成后，需要在验收时提供第三方测试公司出具的测试报告，测试报告相关指标需要满足 招标文件 技术需求的各项要求。 3、项目进度管理 项目在开发阶段，每个开发任务有明确的版本计划和上线时间点，进度落实到个人。以周会或双周会对项目进度进行校准。 4、运营维护 支持产品的运营需求，如财务对账、运营活动等相关产品数据的提供。支持客服反馈的技术答疑。 5、系统维护 开发完成后，交付方需要在维保期内提供bug修改、运营维护等相关服务。 （7）业务运营及维护工作 日常功能改进、bug修复 ； 运营活动 支持； 对账报表、数据统计、埋点管理等日常维护工作 ； 配合数字公司要求，进行相关系统测试、代码及漏洞修复工作 ； （8） 项目安全、合规相关工作 配合等保、安全认证相关合规工作的资料编撰，功能开发、修复和升级。 （9） 目标前景 1.能够如期完成约定的委托开发任务，确保人教口语业务稳定运行的持续性和连贯性。 2.提供成熟可行的移动端产品运营咨询服务。 3.提供业务相关的数据支持、技术咨询支持。 五、 项目重点难点分析 本次开发任务中，主要包含对现有系统的升级优化和新功能的开发，重点难点如下： （1） 系统功能对接 要求开发团队在对现有系统进行需求理解的基础上进行系统优化，并在此基础上开发新功能，开发团队必须具备新老系统对接的开发能力； 系统接口标准： RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。 REST（Representational State Transfer） ， REST的名称"表现层状态转化"中，省略了主语。“表现层"其实指的是"资源”（Resources）的"表现层"。 资源（Resources） 所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。 所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。 表现层（Representation） "资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。 比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。 URL只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。 状态转化（State Transfer） 访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。 互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。四个表示操作方式对应对应四种基本操作 GET 获取资源 POST 新建资源 PUT 更新资源 DELETE 删除资源 综合上面，RESTful架构的内容： 每一个URI代表一种资源； 客户端和服务器之间，传递这种资源的某种表现层； 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。 RESTful API 设计 API与用户的通信协议 采用HTTPs协议 域名 用api关键字标识接口url 示例： # 应该尽量将API部署在专用域名之下。 # 表示前后端数据交互 https://api.example.com # 应该尽量将API部署在专用域名之下。 https://example.org/api/ 路径 路径又称"终点"（endpoint），表示API的具体网址。 在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。 HTTP动词 对于资源的具体操作类型，由HTTP动词表示。 示例： GET（SELECT）：从服务器取出资源（一项或多项）。 POST（CREATE）：在服务器新建一个资源。 PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。 PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。 DELETE（DELETE）：从服务器删除资源。 不常用 HEAD：获取资源的元数据。 OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。 状态码 示例： 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。 201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。 202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务） 204 NO CONTENT - [DELETE]：用户删除数据成功。 301：永久重定向 302：暂时重定向 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。 401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。 403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。 404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。 406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个 验证错误。 500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法 判断发出 的请求是否成功。 错误处理 状态码是4xx时，应返回错误信息，error当做key。 示例： { error: "Invalid API key" } 返回结果格式 尽量采用json格式避免XML格式 示例： GET /collection：返回资源对象的列表（数组） GET /collection/resource：返回单个资源对象 POST /collection：返回新生成的资源对象 PUT /collection/resource：返回完整的资源对象 PATCH /collection/resource：返回完整的资源对象 DELETE /collection/resource：返回一个空文档 （2）接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用 必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和 接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、 接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。 （3）接口定义约定 客户端与系统平台以及系统平台间的接口消息协议采用基于 HTTP 协议的 REST 风格接 口实现，协议栈如图所示。 业务消息 会话数据 HTTP/ HTTPS TCP/IP 底层承载 系统在 http 协议中传输的应用数据采用具有自解释、自包含特征的 JSON 数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据 包的编码和解码。 在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范， 支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时 支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要， 独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能 力。 （4）业务消息约定 请求消息 URI 中的参数采用 UTF-8 编码并经过 URLEncode 编码。 请求接口 URL 格式： {http|https}://{host}:{port}/ {app name}/{business component name}/{action}；其中： 协议： HTTP REST 形式接口 host：应用支撑平台交互通信服务的 IP 地址或域名 port：应用支撑平台交互通信服务的端口 app name：应用支撑平台交互通信服务部署的应用名称 business component name：业务组件名称 action：业务操作请求的接口名称，接口名字可配置 应答的消息体采用 JSON 数据格式编码，字符编码采用 UTF-8。 应答消息根节点为 “response”，每个响应包含固定的两个属性节点： “status”和 “message”。它们分别表示操作的返回值和返回消息描述，其他 的同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。 当客户端支持数据压缩传输时，需要在请求的消息头的 “Accept- Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答 的数据报文进行压缩作为应答数据返回， Content-Length 为压缩后的数据长度。 详细参见 HTTP/1.1 RFC2616。 （5）响应码规则约定 响应结果码在响应消息的 “status”属性中，相应的解释信息在响应消息 的 “message”属性中。解释消息为终端用户可读的消息，终端应用不需要解析 可直接呈现给最终用户。响应结果码为 6 位数字串。根据响应类型，包括以下 几类响应码。如表中的定义。 响应码 描述 0 成功 1XXXXX 系统错误 2XXXXX 输入参数不合法错误 3XXXXX 应用级返回码，定义应用级的异常返回。 4XXXXX 正常的应用级返回码，定义特定场景的应用级返回说明。 （6）数据管理 业务数据检查 接口应提供业务数据检查功能，即对接收的数据进行合法性检查，对非法 数据和错误数据则拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系 统主机处理负荷。 对于接口，其业务数据检查的主要内容有以下几个方面： 数据格式的合法性：如接收到非预期格式的数据。包括接收的数据长度， 类型，开始结束标志等。 数据来源的合法性：如接收到非授权接口的数据。 业务类型的合法性：如接收到接口指定业务类型外的接入请求。 对于业务数据检查中解析出非法数据应提供以下几种处理方式： 事件报警：在出现异常情况时自动报警，以便系统管理员及时进行处理。 分析原因：在出现异常情况时，可自动分析其出错原因。如是数据来源 非法和业务类型非法，本地记录并做后续管理，如是数据格式非法，分析网络 传输原因或对端数据处理原因，并做相应处理。 统计分析：定期对所有的非法记录做统计分析，分析非法数据的各种来 源是否具有恶意，并做相应处理。 （7）接口的可扩展性规划与设计 各个 端 间的通信接口版本信息限定了各个系统平台间交互的数据协议类 型、特定版本发布的系统接口功能特征、特定功能的访问参数等接口规格。通过接口协议的版本划分，为客户端升级、其他被集成系统的升级、以及系统的 部署提供了较高的自由度和灵活性。 系统可根据接口请求中包含的接口协议版本实现对接口的向下兼容。系统 平台可根据系统的集群策略，按协议版本分别部署，也可多版本并存部署。由于系统平台可同时支持多版本的外部系统及客户端应用访问系统，特别是新版 本客户端发布时，不要求用户强制升级，也可降低强制升级安装包发布的几率。 从而支持系统的客户端与系统平台分离的持续演进。 （8） 系统性能优化 由于系统用户数较大，覆盖面广，要求开发团队具备丰富的 Linux系统性能优化经验 ，以保证系统的流畅性和稳定性： 一、影响 Linux 性能的各种因素 1、系统硬件资源 （1）CPU 判断多核 CPU 不超线程，消耗 CPU 的业务 （2）内存 消耗内存的业务：内存数据库（redis/hbase/mongodb） （3）磁盘 IO 消耗磁盘的业务：数据库服务器 （4）网络带宽 消耗带宽的业务：hadoop 平台、视频业务平台 2、操作系统相关资源 （1）系统安装优化 磁盘分区、RAID 设置、swap 设置 （2）内核参数优化 ulimit -n（最大打开文件数） ulimit -u（最大用户数） （3）文件系统优化 读操作频繁，同时小文件众多的应用：首选 ext4 文件系统，接下来依次是 xfs、ext3。写操作频繁的应用，首选是 xfs，接下来依次是 ext4 和 ext3对性能要求不高、数据安全要求不高的业务，ext3 是比较好的选择。 3、程序问题 此类问题需要开发人员查看代码，介入处理。但作为运维人员需要给出程序问题的有力证据。 二、Linux 性能优化工具 1、cpu 性能评估工具 利用 vmstat 命令可以对操作系统的内存信息、进程状态、CPU 活劢等进行监视。 对上面每项的输出解释如下： ● procs r 列表示运行和等待 cpu 时间片的进程数，这个值如果长期大于系统 CPU 的个数， 说明 CPU 不足，需要增加 CPU。 b 列表示在等待资源的进程数，比如正在等待 I/O、或者内存交换等。 ● memory swpd 列表示切换到内存...