审批流程系统设计.pptVIP

GCC权限系统分析和设计 潘大勇 2008-12-06 提纲 设计目标 限制条件 需求范围 业务需求 原型演示 案例研究 理论基础 需求验证 方案比较 需求决策 里程碑划分 结束语 设计目标 满足施工企业公司级权限管理需求 可以完全满足90%的权限需求 基本满足权限设计和开发的需要 提供完整的需求规格 提供完整的原型系统 符合开发的能力要求 限制条件 原有方案改造 符合现有框架要求 符合现有技术要求 需求范围 分级的管理权限要求 按组织机构的层级的数据权限要求 业务需求 案例演示 理论基础—RBAC模型及变体 Users Roles Sessions OBS OPS Departs User Assignment Permission Assignment User_ Sessions Session_ Roles Role Hierarchy Role Assignment 案例分析 主要要求 1.可以按照组织机构进行分级授权管理 2.上级角色（岗位）具有下级角色（岗位）的全部权限 3.无隶属关系的角色之间也可以相互查看所属数据 4.支持按机构的分级数据查看 案例分析—基本用例 执行者：系统管理员 主成功场景： 1.SA构建本级系统的组织机构（含岗位与部门挂接）； 2.SA建立本级系统的人员（用户）名册（含与角色挂接）； 3.SA鉴于组织复杂，启用子部门系统管理员；并分配子部门系统管理员可管理的资源； 4.SA建立角色的行政或业务的直接上级关系； 5.SA为指定角色分配资源权限，若上级没有特殊权限，则不需要分配； 6.用例结束 扩展用例： 3a)SA鉴于组织简单，不启用任何子部门系统管理员，直接进入主成功场景第4步； 4a)SA不指定上下级关系 4a1 SA为所有角色分配资源权限 4a2 用例结束 案例分析—组织机构 广联达建筑公司 总经理 财务部 经营部 北京施工项目部 天津施工项目部 总工程师 财务主管 经营主管 预算员 项目经理 项目经理 预算科 预算科 预算员 预算员 技术部 物资部 总会计师 技术科 技术科 角色 机构 部门 案例分析—部门级系统管理员 广联达建筑公司 系统管理员 财务部 经营部 北京施工项目部 天津施工项目部 部门级系统管理员 部门级系统管理员 预算科 预算科 技术部 物资部 技术科 技术科 案例分析—分级授权 系统管理员 北项系统管理员 北项子部门系统管理员 天项系统管理员 天项子部门系统管理员 业务下属 案例分析—角色下属和角色信任 总经理 总经济师 财务主管 经营主管 预算员 天项\项目经理 北项\项目经理 北项\预算员 天项\预算员 总会计师 行政下属 信任 案例分析—权限范围（自己与他人） 每个预算员只能修改自己登记的中标合同，但是可以查看其他预算员登记的中标合同。 预算员 中标合同 浏览自己 修改自己 浏览全部 修改全部 经营主管 张三 李四 浏览全部 修改 张三/李四 修改全部 案例分析——内置的权限 一些单据或报表在编制时就已经确认了其所属的组织机构，系统将为这些数据赋予内置的权限。即仅有所属机构或其上级管理机构缺省有权利管理这些数据。其平行机构只有通过信任授权方式才可以取得这些数据的管理权。 案例分析—数据的内置权限管理 项目2分包合同 项目1分包合同 项目1 项目2 北京项目部 天津项目部 北项\预算员 天项\预算员 预算员 角色隶属 角色信任 数据隶属 中介 数据管理 案例分析—公共资源管理 1.每种资源类别都有具体的分类 2.各种模块与具体资源直接相关 3.管理员授予不同角色管理不同的具体资源 4.数据权限就这样被切分 资源独有 资源共享 资源无关 需求验证 支持权限的继承 支持按机构/项目/中标合同的内置权限管理 支持分级授权管理 方案比较 对比项目 原方案 新方案 权限控制角度 岗位 可以授权，不具备隶属关系 不可授权 人员 不可授权。人员归属多岗位和多部门，但无法区分同一个人在不同部门下的岗位和职能。 不可授权。人员归属单一角色（即部门下的岗位），从而明确区分同一个人在不同部门下的职能。 部门 不可授权 不可授权 角色 无此项 可以授权 权限控制方式 外部控制 按岗位的权限控制 按角色的权限控制； 通过角色之间级隶属关系，实现权限继承关系； 通过角色之间信任关系，实现权限转移。 内置权限 按项目/部门的权限控制，通过部门上下级实现权限继承关系。 按部门的权限控制，通过部门下管理的角色和角色之间的隶属关系实现权限的管理和继承关系。 授权管理模式 仅提供一个内置的系统管理员管理全部权限，系统管理员工作十分复杂 每个部门都可以建立自己的一个系统管理员角色，并且可以由多个人员承担，上级系统管理员可以授权和管理下级系统管理员，下级系统管理员在上级