后台|业务管理后台的设计方案( 二 )

文章插图
但如果我们从项目的角度出发，我们需要从平台中抽象出ota的特征通用需求出来作为参考，如下：

产品线管理：FOTA&SOTA；
设备接入管理：接入终端硬件信息和系统要求；
软件升级及任务包管理：android差分\整包；
数据管理：活跃\版本\地域分布；

在抽取了ota的特征需求后我们需要针对真实的项目情况去落地设计；
二、梳理业务需求和使用场景一般而言业务管理后台都是面向TO B产品，而TO B的产品最大的特点就是定制化程度高，私有化部署；
而这对产品设计带来的挑战就是业务诉求频繁变化和场景复杂，如果考虑不全面，后续平台返工的成本、概率就会随着功能的堆叠变得越来越高；
所以第一步我们需要对业务需求和使用场景进行梳理，并且需要基于项目背景及终端设备出发，制定核心可落地的功能；
我们假定手头有以下信息：

车载应用系统：android 10.1.X;
终端芯片：XXX;
是否具备辅助设备：T-box；
设备型号：XXX；

有了以上的信息，咱们就以车载OTA（云端更新系统软件包）的服务端简化流程举例，可以参考以下的思路尝试整理：

文章插图
经过上面的整理，我们就可以从中抽取出具体的平台功能，如下图标蓝部分：

文章插图
当然这个也还算是初略的版本，所以下一步，我们就需要进入详细的方案拟定；
三、设计方案描述在进行详细的需求设计时，遵循三个原则：
前面两点简单地说，就如下图展示的情况，模块高度集成且互相关联；

文章插图
然后在制定详细的需求书时需要先制定基础功能，类似于角色数量、权限管理及审批、账号登录\登出等，如下图：

文章插图
还是以OTA作为例子，在这个例子中，由于首先是面向的对象是车企研发和测试的人员，使用对象不会外授权给外部开发者和市场人员。
毕竟如果更新包或者策略出问题了，这个肯定是会造成车企经济损失和名誉损伤。
这时候其实角色数量和审批的流程就可以简化处理，角色定义管理员和普通角色、审批流采取二级审批或者验证码二次确认即可，如果为了保险，其实也可以增加一个密钥验证；
确定好角色和审批，就需要确认账号体系，但一般TO B大型项目都会有一套通用的账号体系，所以直接沿用即可；
当我们制定了完整闭环的业务流程后，我们就可以参考之前的需求分析抽取的功能点和业务流程制定几个大的功能模块；

文章插图
如：

首页：呈现业务数据和报表，涉及设备、系统版本、升级成功率等数据类型等；
软件包管理：管理软件包和上传通道，涉及软件包校验、软件包大小要求及信息、产品线管理等；
任务管理：制定OTA的规则和策略，涉及OTA任务信息、升级版本要求、重复推送机制、基于VIN码和系统版本推送、任务中止条件等；
操作历史记录：记录每个用户对应的操作记录，涉及软件包上传、产品线信息变更、任务发布等；
账号中心和通知中心：记录审批的通知和用户角色管理，涉及角色梯度、任务发布通知管理等；

由于OTA的领域要求，一般都是会对数据及升级情况有比较明确且具体的要求，下面就以数据上报和报表呈现展开；