20xx/4 -- 20xx/12： 电力公司投资（资金）计划系统

项目描述： 该系统的实施目标是为了实现省电力公司对各市电力公司的投资计划进行有效管控，并实现与

国网系统的数据交换。

责任描述： 承担软件实施工作，甘肃电力公司投资计划项目、新疆电力公司投资计划项目，工作职责：辅

助项目经理进行调研工作，负责数据收集、整理、系统安装调试和培训工作。

20xx/5 -- 20xx/10 ：宁夏回族自治区SG186电力安全生产系统

项目描述：

责任描述：

20xx/7 -- 20xx/2 ：吉林省SG186电力营销业务应用系统

开发工具：

项目描述： PL/SQL+Oracle 吉林省SG186电力营销业务应用系统推广应用（业扩、抄表核算、收费账务、用电检查、计量、资产、

线损、稽查）

责任描述：

国家电网SG186信息一体化营销业务项目：负责项目前期系统的测试，系统推广，需求调研、 供电局相关人员培训 、参与编写用户手册、系统上线后的维护工作及BUG反馈跟踪。 宁夏回族自治区SG186电力安全生产系统的实施及推广 负责电力安全生产、系统应用的实施工作: 包括供电局的需求调研分析、业务流程及需求资料编写整理、 系统的部署调试、系统的测试（黑盒测试），供电局相关人员培训 、编写用户手册、系统维护

20xx/3 --至今：山西省电力营销费控系统

项目描述： 1、 国家电网公司在20xx年提出了全面建设智能电网的战略规划，随后在20xx年初又提出落实以全面推进

“三集五大”工作为核心的总体部署，提出加快统一坚强智能电网和“一强三优”现代公司建设，

要求加快电力用户用电信息采集系统建设。 2、为保证智能电网建设规范有序推进，

国网公司提出了实现用电信息采集系统“全覆盖、全采集、全费控”的总体建设目标。

3、发改委推行居民阶梯电价，鼓励居民节约用电、减少能源浪费，从而提高能源的利用效率。

4、以智能电表应用为起点，实现从单纯电量采集向用户侧综合数据采集、用户用电管理的转变，

实现高效、经济、智能化的电网应用 在此背景下，安装智能表、开展费控业务以及陆续开展其它

提升应用是必然趋势。山西电力公司率先开展费控业务研究，在和局方负责人员对于费控业务进行

充分讨论以及对于营销业务应用的改造影响详细分析梳理的基础上，提出本解决方案。

责任描述：

20xx/6 -- 20xx/11： 安徽电力公司生产管理系统

开发工具： C++,DEPHI

项目描述： 在上海电力生产管理系统(PMS)基础上本地化,分期实现对供电公司生产业务的管理,包括电网管

理\设备台帐管理及其它生产业务模块管理

责任描述： 担任实施工程师,按不同的模块,在市级分公司完成试点实施后组织推广到全省供电公司。先后

完成电网基础数据录入、缺陷管理、线损管理和供电方案答复等多个模块的实施和推广

20xx/10 -- 20xx/12： 内蒙古旗县农电局用电营销软件项目实施

项目描述： 该项目包括生产管理、用电营销管理、业扩报装、计量管理、人力资源、办公自动化(OA)。

实施过程中负责:

1、 软件运行环境搭建。与农电局信息中心人员交流了解当地业务情况及当前数据库的表结构。 国家电网SG186信息一体化营销费控系统项目：负责项目前期系统的测试，系统推广，需求调研、供电局 相关人员培训 、参与编写用户手册、系统上线后的维护工作及BUG反馈跟踪。

2、 将当前客户系统的相关数据导入到本公司数据库中。

请农电局生产部门人员在本系统中维护线路变压器信息。

设置抄表员、核算员、收费员 及营销部门其他人员权限。

2、统计用户的打印票据，测试打印票据。

如果用户有抄表机、集抄设备，与用户及抄表和集抄厂家2方协调沟通，公司人员制作接口，实施人员测试接口程序。

3、导入用户某个月的电能表表底，并计算电费，对新旧两个系统所有用户电费核对，电费有出入的情况和当地农电局人员协调沟通解决。

统计用户报表格式。

4、抄、核、收满足客户要求后，与客户协调，确定培训时间、项目上线时间。

在规定时间对农电局各部门人员分批培训，并签培训单、项目运行单。

项目双周计划及项目实施周报提交。

20xx/7 -- 20xx/6： 江西双源电力高新技术有限公司 | 研发部 | ERP技术/开发应用

IT服务（系统/数据/维护）/多领域经营 、股份制企业 、20xx-4000元/月

负责国家电网江西电力公司的SAP MM物料管理模块的实施，先后负责实施江西省吉

安市供电公司、江西省吉安市安福县供电公司、江西省赣州市供电公司、江西省赣州市

大余县供电公司的ERP SAP项目。

SAP功能强大，集成性高，MM是SAP的中间环节，月底与FICO财务进行月结，四

个供电公司的项目进展顺利，现处于阶段性项目验收阶段。

20xx/9 -- 至今： 黑龙江省电力公司ERP项目

项目描述： 国家电网公司依据国家“十一五”信息发展规划，决定在国家电网公司系统构筑由信息网络、数据交换、数据中心、应用集成、企业门户五个部分组成的一体化企业级信息集成平台；建设由财务（资金）管理、营销管理、安全生产管理、协同办公、人力资源管理、物资管理、项目管理和综合管理八大业务应用；建立健全信息化安全防护、标准规范、管理调控、评价考核、技术研究、人才队伍六个保障体系。重点建设“一个系统、二级中心、三层应用”。 黑龙江省电力公司ERP项目作为国网公司“SG186”工程的一部分，起着推动公司信息化建设、提高企业管理水平的重要作用。

责任描述： 作为SAP(FICO)财务实施顾问，为黑龙江省电力公司进行ERP实施工作，主要负责西部推广分区财务模块实施工作，主要包括：

1、最终用户培训工作

2、静态、动态数据清理与导入工作

3、模拟运行

4、上线支持工作

20xx/2 -- 20xx/9： 湖北省电力公司ERP项目

项目描述： “SG186”工程是国网公司确定的“十一五”信息化建设的宏伟目标，它的具体内容包括企业一体化平台、八大业务应用和六项信息化建设保障措施。湖北省电力公司ERP项目作为国网公司“SG186”工程的一部分，起着推动公司信息化建设、提高企业管理水平的重要作用。

责任描述： 作为SAP(FICO)财务实施顾问，为湖北省电力公司进行ERP实施工作，主要负责武汉推广分区财务模块的实施工作，主要包括：

1、项目前期业务调研与差异确认工作，业务蓝图设计

2、根据差异分析进行系统配置以及权限设计、配置与测试工作

3、系统配置手册、操作手册的编写与修改工作

4、关键用户、最终用户培训以及系统单元测试、集成测试

5、各静态数据与动态数据收集与清理工作

日期:20xx/03-20xx/04

项目名称/客户名称

开发环境与技术

项目简述

本人职责 物11111111111111 WindowsXp Web 本人

 

第二篇：OA项目总结

组织机构管理模块

请描述一下你做的组织机构管理模块

描述思路：

1、 组织机构模块的基本需求

a) 本模块主要管理公司、子公司、部门、岗位、员工的信息

b) 公司下面可以创建子公司、部门

c) 部门下面可以创建子部门、岗位或员工

d) 岗位下面可以创建员工（即员工可以属于某个岗位）

e) 公司、部门、岗位、员工形成一棵组织机构树，要求使用树型方式来展现和管理

2、 组织机构的总体设计思路

a) 公司、部门、岗位、员工可以看成同一种类型：Party

b) 在Party上实现树型结构（父子关系）

c) 其它类型：公司、部门、岗位、员工均继承Party（请画出类图）

3、 组织机构的实现技巧

a) 利用jQuery的jsTree实现组织机构树

b) 利用jQuery的treeTable实现列表（AJAX、查询、分页）

c) 在组织机构树中显示公司、部门、岗位的信息，点击公司、部门、岗位，则可以显示其详细信息，及其下面的所有员工（利用hibernate filter避免在树上显示员工信息）

d) 为了显示某个公司或部门（包括其下级机构）下面的所有员工，我们设计了一个sn，这个sn根据组织机构的树型结构来取值，通过它便可以方便实现查询需求。 e) 利用TreadLocal实现分页参数的传输

f) 利用VO设计模式适应客户端对数据格式的特殊要求

4、 我们这个设计的优点在哪里

a) 通过树的方式来管理，一目了然，层次清楚

b) TheadLocal设计模式的运用大大降低了分页查询逻辑的封装处理

c) 抽象出Party来，便于对所有的组织机构实体进行统一的管理（比如方便我们后面的权限管理模块把所有Party统一对待）

5、 我们这个设计的缺点在哪里

a) 没有实现员工的调动管理（从一个部门调到另外一个部门），此功能在项目二期实现！

b) 员工不允许跨部门（即一个员工只能属于一个部门，而不能同时属于多个部门） c) 在模型上没有规定哪些类型的Party只能放在哪些类型的Party下面，比如，在一般的需求中，岗位下面肯定是不能挂一个公司的。我们针对这种需求，是通过具体的代码逻辑来实现的，而没有办法在一个地方去统一定义这种规则。 i. 如果要实现这些逻辑的统一定义，可以参考“责任模式”！

权限管理模块

请描述一下你做的权限管理模块

描述思路：

1、 权限管理的基本需求

a) 系统后台有很多菜单项，同时各个页面上也有很多功能按钮，客户要求我们的系统

要能够控制这些菜单项的访问权限，也可以控制到具体每个功能按钮的访问权限 b) 客户要求建立角色的概念（参考RBAC），能够自由定制不同的角色，角色和用户

之间是多对多的。

c) 权限可以授予角色，然后把角色分配给用户，这样用户就拥有了角色的权限

d) 权限也可以授予某个部门、某个岗位，这样在这些部门或岗位下面的用户就拥有了

这些部门和岗位的权限

e) 客户还要求权限也能直接授予用户，这样即使拥有相同的角色、相同的部门、相同

的岗位，用户的权限也可以是不同的

f) 这样，用户自身被授予的权限、用户拥有的角色的权限、用户所属部门或岗位的权

限这些要素联合起来判断，才能最终决定用户的权限。

g) 因为用户的权限可能从多个角色或部门、岗位中继承下来，而这些角色、部门或岗

位的授权极有可能会有冲突，比如一个角色的授权是允许访问，而另外一个角色的授权是拒绝访问，客户要求，如果出现这种情况，就以拒绝为准，即不允许访问。

2、 权限管理的总体设计思路

a) 因为权限可以被授予用户、角色、部门、岗位等等，我们称之为权限控制的“主体”，

我们定义了一个接口Principal用来表示主体的概念，用户、角色、部门、岗位等均实现这个接口

b) 我们要控制菜单项以及各种功能按钮的访问，我们称这些菜单项和各种功能按钮为

权限控制的“资源”，定义了一个SysResource接口来表示资源的概念。

c) 菜单项是一种资源；而各种功能按钮最终其实是要访问后台的某个类的某个方法，

因此我们把Action类看成是一种资源（称为“操作资源”），各种功能按钮则对应了这个类里面的各种方法，我们把这些方法看成是这种资源的各种操作。

d) 我们定义了一个ACL用来表示哪些资源的哪些操作被授予了哪些主体，ACL中的

主要属性包括：主体类型（principalType）、主体ID(principalId)、资源类型(resourceType)、资源ID(resourceId)、操作状态(aclState)，其中操作状态是int类型，在Java中，一个int有32位（bit），我们定义资源的时候，把这个资源对应的操作映射到某一位上，规定在这一位上取1表示允许执行那个操作，而取0表示不允许执行那个操作。

e) 这样，在授权的时候，我们直接改变相应操作的状态位的取值即可；在认证的时候，

直接判断相应操作状态位的取值

3、 权限管理的实现技巧

a) 在实现上，对于授权，我们界面上用jQuery和jQuery的插件jsTree来呈现菜单树，

在菜单树的前面显示一个CheckBox框，打勾表示允许，打叉表示拒绝；同时也做了一些右键点击显示上下文菜单，方便客户执行各种功能

b) jsTree没有打叉这种显示方式，为了满足我们的要求，所以对jsTree插件做了一些

扩展（主要是修改它的js文件和css文件、图片等），以便能支持更强大的显示方式。

c) 因为我们把系统中的各种Action类及其方法，看成是各种资源及其操作，为了方

便管理，我们利用Spring提供的API搜索具备某些特征的Action类及其方法（特定的命名及特定的注解），将这些信息插入数据库，这样便可以将其用于授权和认证。

d) 在认证的时候，我们实现了两种方式的认证：

i. 第一是根据授权，能够把没有授权的菜单项屏蔽，也能够把没有授权的功能按

钮屏蔽；

ii. 第二，因为第一种认证方式会有一些安全性问题，比如客户可以绕过功能按钮，

直接在浏览器输入某个功能的地址，为了避免这种问题，我们在后台也做了认证，根据当前请求的是哪个类的哪个方法，编写拦截器，判断当前登录用户是否具备这个权限，如果没有这个权限，就不允许执行这个操作！

e) InitService和XML

f) 自定义注解，利用Springde的API扫描类（大概说出一两个类名）

4、 我们这个设计的优点在哪里

a) 因为抽象出了主体和资源这两个概念，核心的授权和认证代码依赖于这两个概念，

而不是具体的哪个主体或资源。所以，能够更灵活的支持主体和资源的扩展，比如假设以后客户还想要给用户分组，按照分组来给用户授权，那么只需要实现一个新的主体类型即可，核心的授权和认证的代码无需变化。

b) 权限控制的粒度更细，因为我们用一个int来表示操作的允许状态，这就意味着，

我们能支持在某个资源上的至多32种操作，在设计上无需做变化。一个资源上的操作一般不会超过32种操作，一般来说也就是添加、更新、删除、查询，以及在这个基础上更加细分的一些操作而已，很少会超过32种操作。即使是极端情况，超过了32种操作，那么我们的核心设计也无需变动，无非就是把int换成一个long类型即可（支持64种操作）。

c) 我们还能支持细粒度的操作权限继承关系：

i. 比如针对“公司管理”这种资源，假设它有六种操作：添加公司信息、删除公

司信息、更新公司信息、查询公司信息、添加子公司、删除子公司；我们可以把这些权限授予比如“张三”这个用户。在授权的时候，我们可以细化到这种程度：

1. 明确规定：允许张三查询公司信息、更新公司信息

2. 明确规定：不允许张三添加公司信息、删除公司信息

3. 至于张三是否能执行添加子公司和删除子公司这些操作，我们可以不做明

确规定，而是由其所拥有的角色，或其所属的部门、岗位的权限来决定，

这称为“权限的继承关系”，针对这种需求，在ACL中，我们设计了一个

额外的属性：aclTriState，用来表示某种操作的权限是否是继承下来的。

5、 我们这个设计的缺点在哪里

a) 角色之间没有考虑父子关系，如果考虑父子关系的话，会更加便于授权，比如假设

有一个角色为“普通员工”，另外一个角色是“档案管理员”，如果把普通员工看成

是档案管理员的父角色，则意味着档案管理员这个角色的权限将可以继承普通员工中的权限（为什么没有实现这个设计呢，客户认为没有必要，因为系统中的角色数量比较少，如果这样设计的话，反而会增加客户操作的难度，无需过度设计） b) 我们还没有实现更细粒度的数据级的权限控制，比如，我们目前通过权限控制系统

无法实现如下需求：规定张三可以查看所有部门的员工信息，但只能对本部门的员工信息执行添加、删除和修改操作。没有实现的原因是：客户目前这方面的需求还不是很多，因此，没有必要在权限控制系统中实现。实现上述需求，我们是将这些逻辑写到了具体的代码中，而没有通过权限控制系统进行统一的定义。这也是大部分权限控制系统的实现策略。

工作流模块

请描述一下你做的工作流模块

描述思路：

1、 工作流模块的基本需求

a) 请描述

2、 工作流模块的总体设计思路

a) 把JBPM嵌入OA系统（如何实施的？具体过程？大概有哪些配置？）

b) 表单管理、流程管理、WorkEntity、WorkApprove、EntityProperty（动态表单）

3、 工作流模块的实现技巧

a) 引入jbpmeditor之后，对它做了一些定制开发（支持中文，动态表单的关联） b) 其它？

4、 我们这个设计的优点在哪里

a) 对JBPM的扩展

i. 自定义JBPM变量解释器

ii. 可以给角色、部门、岗位分配任务，抛弃了JBPM中简单的User-Group这种

组织结构模型，使用了OA中的组织结构模型

iii. 实现了自由流（如何实现的？）

iv. 利用自定义节点实现了会签的决策（如何实现的？）

b) 动态表单设计方案

5、 我们这个设计的缺点在哪里

a) 在流程定义的界面上，没有实现会签节点的定义

b) 在动态表单设计界面上，无法直接添加一些动态的组件（比如无法通过拖拽的方式

添加一个人员列表等等）

c) 没有实现流程的监控