OA项目总结

2024-06-08

OA项目总结（共5篇）

篇1：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)没有实现流程的监控

篇2：OA项目总结

面试过程中描述项目一般分为三大点（第一点是参考说辞。后两点是可补充的说明，个人可根据具体情况介绍）

1、项目的开发背景介绍以及个人在项目中完成的功能点

2、项目的开发过程（开发周期）

3、项目的系统架构

1、项目开发背景以及个人完成的功能点介绍

我们这个项目是为XXX公司开发的一套办公自动化系统，简称OA。该公司属于XX行业，业务类型主要是XXX，该公司为了提高办公效率与办公质量，实现无纸化办公与科学的管理而委托我们公司研发该系统。通过需求调研与设计，我们将该项目划分为了XX个大的模块。主要包括 XXX。。而本人在该项目中主要负责组织机构与权限管理两个大模块的设计，开发，调式以及维护等工作。

组织机构模块主要是对该公司的部门以及人员的管理。所以在此模块中我们又分为机构管理与人员管理两个子模块。由于该公司的机构属于职能型机构，父机构下面又存在子机构，就像一个树状结构，所以我们在设计该模块表的时候使用了自关联的方式，这样可以减少数据库设计的允余，也便于扩展。而人员模块设计比较简单，就是直接在表中加入了一个机构的外键，因为人员肯定是属于某个部门的。

至于权限模块的设计就稍微复杂点。任何一个项目都会根据需求来设计相应的权限操作，权限也是我们保证项目健壮性的一种手段。在此模块中我们分为用户管理，权限管理，角色管理三个子模块。因为首先我们考虑到应该为每个人员建立一个唯一的登陆账号，我们称为用户，我们将权限不直接授予具体人员，而是授予相应的用户，这样就可以降低耦合度。但是如果具有相同权限的人都需要重复授予一样的权限，客户操作起来会很麻烦，而人员在公司一定有其相应的职位，所以我们决定将权限打包授予某个角色，让角色与具体职位关联，再将角色授予用户，这样就能很好的解决问题了。不过一般来说，公司有些人员可能身兼数职，也就是说一个用户可能会被分配都多个角色，默认情况下我们是取所有权限的合集，但也会出现角色之间权限的冲突问题，因此我们在表中设计了一个优先级的字段，让一个用户拥有的多个角色有不同的优先级，如果权限产生了冲突，则以优先级高的角色为准。有点类似我们web程序中加载servlet时候配置的load-on-startup的属性。当我们将项目交与客户试运行后，客户反映，无论什么情况都需要通过建立角色来授权感觉很麻烦，而公司的职位变动也会引起角色的增多，造成角色的泛滥。所以通过与客户的沟通，我们修改了当初的设计，也就是除了可以通过角色来授权，也可以给用户直接授权。这种方式与oracle数据库的授权方式是一样的，客户也感觉很满意。当然，既然可以直接授权给用户，也可以授权给用户所属的角色，同样会发生类似于开始说的两者之间权限的冲突问题，我们解决的办法同样是多设计了一个字段，该字段表示是否使用用户自身的权限还是使用其角色的权限。

我们这个项目的权限分为三级，首先在用户登录的时候就开始验证是否有资格进入，（这是第一级）在通过该验证后，我们会查询出该用户拥有的所有具有可读功能的模块并展示，对于该用户不可读的模块是不会展示出来的，这样能避免用户的误操作（这是第二级）。但有些模块该用户虽然具有可读权限，但是没有更新与删除等权限，我们此系统也可以及时屏蔽该误操作（这是第三级）。

2、项目开发周期本项目总开发周期为1年，具体分为以下几个阶段

1、需求分析阶段，由系统分析员对客户进行需求调研，产生需求分析说明书，经客户签字确认。

2、概要设计，由系统分析员根据需求分析书编写概要设计文档，经客户签字确认。

3、详细设计，由系统分析员和架构师根据概要设计文档编写详细设计文档，经客户签字确认。

4、用户手册，根据以上三个文档编写用户使用手册

5、数据库设计，由系统分析员做数据库架构设计，生成数据字典

6、系统架构设计，由系统架构师做整个系统的架构设计，产生架构说明文档

7、分模块编码，主要由程序员进行分模块编码，并由测试人员对模块进行交叉测试

8、系统集成（也叫产品集成）

9、集成测试（对整个系统的产品结构功能进行整体测试）

10、上线试运行，将集成后的产品交付给客户进行试运行，对试运行期出现的错误进行修改

11、产品交付，试运行完后，如果产品没有什么问题之后，对客户交付产品

12、后期升级与维护(根据合同规定)

3、系统架构

篇3：OA项目总结

在信息经济环境下, OA系统软件的应用十分广泛, 对于企业内部OA系统软件的开发管理, 一直是很多企业信息化建设的一个重点内容, 鉴于不同企业所面临的环境和企业经营项目的差别, 每个企业的OA系统应该是符合内部应用特征的, 同时又能与外部协同统一的。因此, 对于OA系统软件的开发也是企业信息化管理的一个重中之重。在信息化技术高速发展的时代, 组织标准软件过程 (Organization's Standard Software Process, 简称OSSP) 的基本目标和思想是十分符合和适用于以经济、快捷的方式开发出企业特殊要求的OA系统软件项目开发管理的。

OSSP是一个已经被验证了的方法, 它的目标是帮助项目的顺利实施和完成。OSSP方法为项目定义了一个标准的项目结构, 是从软件工程学院 (SEI) 和项目管理学院 (PMI) 中被广泛接受的方法和在最佳实践指导中总结出来的, OSSP方法将此结构量身定做以满足综合资源库平台建设的项目需求。OSSP为项目经理提供了项目管理任务的模板, 这些模板集中了已有的项目经验。它们通过预定文档结构和预备使用的语句和示例文字, 节约了时间。此外, 模板的使用有助于项目经理重复使用其他项目中的信息。

OSSP的优点在于:跨组织、跨地域和技术界限的有效合作, 以规范的方法实施项目, 同时通过知识的获取、经验的积累、最佳实践以及现有经验的重用, 达到提高效率的目的。在整个项目中, 鼓励客户参与, 并遵循标准流程, 以提高客户实施的质量。下面我们基于OSSP的软件项目管理过程, 结合本人在使用协同OA软件教学及应用过程中的具体实列, 详细探讨企业OA系统项目开发管理的过程。

二、基于OSSP模式的OA系统项目管理开发分析

OSSP的建立一般是CMM3组织必不可少的一项工作, CMM (能力成熟度模型) 是一种广泛用于评估和改进机构的软件开发过程的模型。它分为五个等级:一级为初始级, 二级为可重复级, 三级为已定义级, 四级为已管理级, 五级为优化级。企业通过CMM3级评估标志着企业的软件开发和维护的标准过程已文档化, 称之为组织标准软件过程;CMM是一个体系, 它只规定了软件开发过程能力各种级别的特点以及改进的目标, 但对如何实现这些能力和目标没有详细的指导, 而且, 由于软件的应用领域很多, 各个机构特点不尽相同, 没有一个统一的详细指南可以解决所有机构面临的问题, 因此, 各个机构必须结合自身的特点来量体裁衣, 构建自己的软件开发过程。

由于各个项目环境不尽相同, 因此只组织标准软件过程是不够的, 还必须根据综合资源库平台建设特定的项目环境, 对组织标准软件过程进行打量定做, 根据实际需要, 建立起相应的项目定义软件过程。在OA系统项目的管理开发过程中, 只能结合OA系统本身的特点, 实施软件开发管理。OA系统是面向组织的日常运作和管理时员工及管理者使用频率最高的应用系统, 随着信息经济环境的不断完善, OA系统在应用内容的深度与广度、IT技术运用等方面都有了新的变化和发展, 并成为组织不可或缺的核心应用系统。在信息经济环境中, 办公自动化更多的是将最新的管理思想、管理理念植入其应用系统中, 使企业在面对外部环境的易变性与复杂性时, 突破以往传统的严格的部门分工, 打破企业在高速发展过程中受时间、地域、部门之间的限制而形成的信息孤岛, 从而提升企业的整体竞争力和前进速度。

不同的企业对信息的应用要求是不一样的, 要开发出与企业生产应用要求相匹配的应用系统, 最有效的方法就是基于OSSP模式的OA系统项目开发与建设。在OA系统项目管理开发过程中, OA系统应联系企业的实际需要, 根据协同OA平台建设项目的要求, 以OSSP实施方法论为基础, 分阶段地实施整个项目。

三、基于OSSP的OA系统项目管理的实施

1、OSSP项目实施方法

OA系统项目实施, 可以通过OSSP应用成熟的软件技术和平台来实现本项目的各项需求。在项目交付阶段制造执行系统被实施, 而一般当客户签订了合同时, 这个阶段就开始了。本阶段的目标是完成合同的各项指标, 并为推广应用做准备, OSSP项目实施的方法, 如图1所示。

在OSSP实施OA系统软件项目开发中的四个阶段中, 每个阶段都定义了一套交付、里程碑和报告, 并在第三阶段——执行阶段中应用基于CMM的项目管理理论。

2、OA系统软件项目开发中的软件质量管理

OA系统软件项目开发中软件质量保证的目标是为管理提供保证, 使得OSSP已定义的过程、规程、模板在项目过程中得到遵循和保持。

在OA系统软件项目开发项目启动后, 项目经理与质量总监协商指派项目SQA (软件质量保证) 和行业SQA小组来负责SQA活动。行业SQA和项目SQA参与项目早期的策划活动, 包括选择LC模型、标准过程规范;制定PDSP, 进行软件项目策划估计。

SQA小组负责制定项目的SQA计划, SQA计划以项目生命周期为基础保证实际与项目计划 (软件项目计划、测试计划、SCMP、SQMP、QPMP) 一致。计划SQA活动应该在项目软件质量保证计划模板中记录。每当项目的日程或范围有了重大改变, SQA活动都可能需要重新计划。项目经理必须评审SQA计划。SQA计划应与项目计划、项目PDSP一起撰写, 并与这些文档保持同步。计划中应该包括SOA协同、OA平台审核、SCM审核的计划日期和工作量。

SQA小组应该定期跟踪已计划的SQA活动。项目SQA活动从其他项目处吸取最佳实践, 帮助项目经理在识别过程即合作为PDSP (项目定义软件过程) 的一部分过程中获得SEPG (软件工程过程组) 的支持, 为项目计划提供帮助。SQA小组必须评审PP (项目策划) 、QP (质量计划) 、PDSP (项目定义的软件过程) 和SCMP (软件配置管理计划) , 以获得有价值的阶段入口, 从而保证在OSSP中定义的活动得到有效执行。

如果在OSSP过程或者PDSP过程中有变更发生时, 要及时将变更与项目组进行沟通。对小组中的新成员要及时进行项目定义的各种活动的培训。SQA小组应该为此做一些协调和配合工作。如果可能, 要将项目文档迁移到新的OS-SP版本, 并对此进行跟踪, 参与项目每月评审 (按需) 和项目检查点评审。

3、OA系统软件项目开发中项目实施质量控制管理

(1) OA系统软件项目开发中的设计规范。OA系统软件项目开发中设计规范是工程实施的初期步骤之一, 为整个工程的实施奠定基础, 是保证最终工程质量的关键要素。在集成工程的各个子任务实施前必须提交合格的设计文档, 设计文档应充分考虑工程实施的实际情况, 并确保技术的正确与可行。设计流程如图2所示。

(2) OA系统软件项目开发中的设计评审。第一, 设计评审是针对设计方案的质量进行控制。第二, 设计人员 (设计组) 根据实际需求、合同规定以及设备厂家的资料提出切实可行的设计方案后, 先由组内讨论通过, 然后由组长向项目管理部提出召开评审会的申请, 由项目管理部召集设计评审会。

OA系统软件项目开发中评审组的成员由项目管理部确定。对于OA系统软件项目开发中的总的设计原则和设计目标的确定以及影响整个工程质量的设计, 应当邀请用户和同设计无关的 (第三方) 专家参与构成评审组, 从技术角度作出判断;其他关系各项目小组设计的评审可以总体管理组为基础扩充若干专家构成评审组。

OA系统软件项目开发中评审应以确认设计是否满足用户需求、是否能达到用户满意的程度、同有关规范、标准的符合程度, 验证设计的适用性、可行性和可靠性, 必要时可要求提供设计验证的证明数据。评审结果形成评审报告存档, 若需要改进, 反馈给设计人员, 若评审通过, 则进入批准生效过程。

OA系统软件项目开发设计方案评审通过后, 领导决策组应当会同项目管理部向最终用户讲解设计方案, 对方案中采用的技术进行说明, 使最终用户理解设计的内容, 对工程进展和实施过程增强信心。重要的设计由领导决策组签字批准, 其他由项目管理部签字批准, 从而正式生效, 设计文件要发送到所有参与过程实施的技术人员。针对已经批准和发布的设计, 在实施过程中或实施前, 如果发现明显的错误或其他因无法抗拒的原因 (如设备和线路性能、政策改变等) , 需要修改设计方案时, 应由设计和实施人员共同提出申请, 由项目管理部批准后, 进行更改, 更改后的文件重新进行评审、批准程序。设计更改申请报告应对需要更改的原因作出说明和分析, 对于设计中的错误应当着重分析出现错误的根源。设计是工程最终能否满足用户需求的重要因素, 明确职责是为了确保设计的质量。项目管理部应当负责总的设计原则和设计目标的确定;督促影响整个工程质量的设计的进行, 各地区项目实施组的子项目经理负责督促属于本组的设计工作, 保证设计能够按时完成。设计评审会负责对设计质量的最后把关。

在设计开展过程中, OA系统软件项目开发中工程质量管理组应对设计进度和设计过程中存在的问题进行检查, 发现问题及时解决 (包括检查设计的目的是否清晰、设计分工是否明确合理、设计流程是否遵守、设计过程产生的文档是否完整符合要求) 。

4、OA系统软件项目开发中的工程实施控制

为保证OA系统软件项目开发中各子任务的工程实施顺利进行并保证质量, 任务负责人必须在实施前作好充分的准备和组织工作。OA系统软件项目开发中实施的准备和组织的流程如图3所示。

OA系统软件项目开发实施准备和组织流程产生的输出包括:实施方案与进度计划, 提取设备清单, 现场环境检查报告。

对OA系统软件项目开发中实施准备和组织流程作以下说明:当项目管理部确定某子任务的实施期限后, 由该任务的负责人在任务下达一周内提交自己的实施方案设计。OA系统软件项目开发中实施方案与进度计划的内容包括:参与人员及其任务分配、工程项目进度计划、所需设备清单、根据任务设计方案和有关作业指导书 (操作手册) 提出的关键控制点。OA系统软件项目开发中的实施方案与进度计划应当交组长审核后由项目管理部批准, 才能正式开始实施准备阶段。准备阶段首先要使参与人员各自明确自己的职责, 并收集有关设计方案、作业指导书、准备质量记录和登记表格。现场环境检查是指检查工程实施地点是否有合格配套的场地、线路。进入现场施工前, 要从库中提取所需要的设备。

OA系统软件项目开发中实施过程的控制:实施过程是对工程质量产生影响的最关键步骤, 必须按照设计方案和实施计划的要求, 规范化严格控制。

OA系统软件项目开发中工程实施的输出包括:配置记录表、配置修改记录表、工作日志、设计修改申请与批准书 (可能) 和联调技术报告。

OA系统软件项目开发中工程实施由相应的任务负责人控制工程实施的进度和质量以及关键控制点的状况。项目管理部和工程质量管理组也要各自履行质量监督职责。

OA系统软件项目开发中的实施验证:实施验证是为了及时得到工程进行状况与实施方案和设计方案的符合程度, 由工程质量管理组负责。

OA系统软件项目开发中的实施验证分为抽验和终验。抽验的时间地点由工程质量管理组组长决定。抽验结果要向领导决策组提供, 以便最高领导及时掌握工程质量状况, 向项目管理部反馈质量改进和控制的建议。终验指在每一项任务 (子任务) 工程实施完毕后进行的评审活动, 应检查各种文档是否齐全, 并对任务 (子任务) 的工程质量作总体评价, 提交评审计划 (评审参加人员、评审内容与方法) 和评审报告。

OA系统软件项目开发中审核与评审是保证工程质量的重要保障手段, 应当有计划地安排进行。工程中所产生的每一份文件 (实施过程产生的质量记录除外) 都要履行审核手续。审核的目的是使文件符合文件规范和有关作业程序的规定, 验证是否存在质量漏洞和职责不明确现象。对于工程中的重要关键问题必须召开评审会。评审会分为两种:一种是项目管理部召集的论证评审会, 另一种是工程质量管理组负责人召开的检验性评审会, 这种评审会由工程质量管理组负责人定期向领导决策组者提交评审计划安排。OA系统评审会要遵从特定的工作流程。

OA系统是一项结构复杂、功能强、涉及面广的信息系统集成和开发的工程, 为确保项目达到预期的目的, 使系统真正发挥作用, 必须做到在项目真正实施前就能预测到该项目可能遇到的各种风险, 并准备好项目风险的控制方法, 才有可能做到万无一失并最终确保本项目的实施成功。

5、OA项目的整体实施系统验收管理

根据需方行业的特点和惯例, 系统验收在最终用户的实际系统运行环境中进行。供方在开发环境下, 完成应用系统开发工作并进行系统测试。项目的系统验收包括系统工程验收、系统初验、系统最终验收 (终验) 三个阶段, 这三个阶段也可根据合同简化为工程验收、系统终验两个阶段。系统验收应履行正式手续, 成立专门的测试验收小组, 负责组织、监督和裁决整个系统的验收过程, 最后对系统验收管理完全实各阶层完成的软件进行实测和调整。

四、基于OSSP的协同OA系统软典型示例及分析

基于OSSP过程开发的协同OA软件挺多, 以笔者所使用的一个泛微协同OA系统软件为例, 它较好地针对“信息孤岛”、“应用孤岛”和“资源孤岛”这三个问题, 通过有效的人力资源和过程控制、技术处理, 实现信息、业务和资源的协同。

在OA系统软件开发过程中, 首先要本着“信息网状思想”:建立一个立体的、多维的信息获取、共享和使用的环境, 同时协同平台为这些信息节点之间提供立体化的“网状”关联通道, 从任何一个信息节点都可以到达任意的相关信息节点, 极大地方便企业获取完整的、真实的信息。其次要结合“业务关联思想”:即提供对各个业务环节进行整合的方案, 使得协同平台可以面向整个业务过程来进行管理。表面上看在协同平台中还是采用某个模块或某个功能完成某个业务环节的要求, 但随之这个应用可以自动启动其他的关联应用, 并完成相关数据的更新, 使得企业无需在不同应用平台之间切换便可以完成对业务链的管理。最后要有“随需而应思想”:即将企业的“人”、“财”、“物”、“信息”和“流程”进行充分的整合。在OA平台中, 这些资源可以实现各种关联, 当企业由于某个目的触发一个应用的时候, 相关的资源可以随之被调动并被自动加入统一管理和协同工作的环境中, 从而进行紧密的协调和运作。

总而言之, 企业在自行开发OA协同管理平台的过程中, 只有很好地利用结合OSSP的思想, 才能更有效地对各种分散存在或被分隔的资源进行整合, 并让它们在统一管理和调配下进行优化, 从而发挥这些资源的最大价值。

五、结束语

在信息经济环境下, 企业对于应用软件的要求越来越高, 应用软件在企业中发挥的作用也越来越重要, OA系统不仅仅是企业办公的一种工具, 更应该是一种有思想、有模式的能管理的软件。目前市场上主流的协同OA系统就为现代企业发展注入了强劲的动力, 它以动态组织为行为主体, 以工作流为传导模型, 以任务为处理模型, 将组织行为的复杂性通过三者的结合充分表现出来, 从而帮助实际组织解决管理过程中的复杂课题。系统管理模型的组织价值在于“使用有限资源创造最大化价值”, 组织标准软件过程在企业具体软件项目开发中的应用还是较初级阶段, 企业与企业间的实际情况千差万别, 完全把不同应用的软件用统一的软件开发格式化管理是无法很好地实施企业的信息化系统建设要求的。只有根据企业的具体要求, 确保客户充分参与;及时组织评审, 倾听客户意见;保持客户沟通渠道畅通, 及时反馈, 然后结合OSSP的软件过程标准灵活运用, 才会使企业的软件项目开发事半功倍, 开发效率大大提高。

摘要：本文基于OSSP的基本目标和思想, 结合实际情况, 依据企业软件项目开发管理过程的主要特点, 研究分析了基于OSSP的OA系统的开发和实施过程, 以期通过此种方式, 为软件项目开发管理过程的研发和实施提供更好的解决方案。

关键词：信息经济,OSSP,软件项目开发,管理过程,OA系统

参考文献

[1]王素芬:软件工程与项目管理[M].西安:西安电子科技大学出版社, 2010.

[2]康一梅:软件项目管理[M].北京:清华大学出版社, 2010.

[3]沈春龙、孔建寿、张友良:支持产品协同设计项目管理系统的研究与实现[J].计算机应用研究, 2000 (3) .

[4]伦蕊、黎正忠:信息经济时代企业管理的规模经济性[J].东北财经大学学报, 2004 (4) .

[5]McBride, T.M.:The mechanisms of project management of software development[J].Journal of Systems and Software, 2008 (81) .

[6]Charlie C.Chen.Chuck C.h.Law.Samuel C.Yang.Managing ERP implementation failure:a project management perspective[J].IEEE Transactions on Engineering Management, 2009 (56) .

[7]涂思佳、肖攸安:基于B/S结构的校园OA系统的设计与开发[J].武汉理工大学学报 (信息与管理工程版) , 2007, 29 (12) .

篇4：OA项目总结

11月25日，正和石化在公司营业楼三楼多媒体会议室召开OA项目认知培训暨项目启动准备会议，进一步统一思想、提高认识，为OA项目的上线实施做好准备。公司高中层管理人员及各部门信息专员参加了会议。会上，正和石化党委书记、副总裁韩其利对OA项目的实施提出了要求和意见。一是要充分认识实施OA项目的重要意义。OA项目实施后，将把日常业务、事务、协作等信息在各部门、个人之间进行即时高效、有序可控、全程共享的沟通处理。它通过网络技术，构建移动办公、资源共享、高效协同的事务处理机制，建立及时有效的信息交流管道和高质量、高效率的信息网络，实现办公现代化、信息资源化、传输网络化、管理人性化和监督透明化，从而达到管理高效的目的；二是要高度重视OA项目的实施，确保顺利推进。OA项目的实施是一项需要全员参与的项目，日后公司的日常事务处理都将通过、依靠这一办公平台，因此公司各部门相关人员一定要高度重视OA项目的启动实施工作，确保按照计划顺利推进；三是要全力支持OA项目的实施，确保按期完成。OA项目启动实施前，需求调研、部门流程对接、上线测试等大量工作需要处理，所以各部门在做好日常工作的同时一定要全力支持项目办公室的各项工作安排，按照要求指定部门信息专员，配合公司项目及技术顾问的工作，做到“两手抓，两不误”，确保按照油气总公司的统一部署按期完成；四是要积极参与OA项目实施，确保有效运行。协同办公平台作为一种工具和手段，建设是基础，使用是关键。系统上线后，各部门都要以良好的心态去认识、理解、接受、应用OA办公平台，要合理安排工作，积极参与到OA项目的实施中去，并从中学习新的知识和技能，为下一步能够熟练应用、提高管理水平打好基础，确保OA项目在公司高效运行。（正和石化闫晓强）

油气总公司ERP项目培训有序进行

随着昌邑ERP项目上线在即，ERP项目组开始对昌邑石化最终用户进行为期两周的培训。培训分为A、B和C三个班。A班主要是对生产综合统计培训，B班主要是对车间级培训，C班主要是对领导的培训。此次培训的授课老师来自ERP项目各个模块的关键用户，他们从ERP项目启动开始就从事各个模块相关的工作，通过五个月的学习和工作,进一步熟悉了公司的业务和系统操作，在此次培训中发挥着重要的作用。为了达到ERP上线要求，项目组充分利用晚上和周末时间，安排各个模块的关键用户再次对最终用户进行现场的指导和培训，直至熟练掌握系统操作为止。（昌邑石化马邦达刘新刚）

油气总公司三级企业协同办公平台项目进入测试阶段

11月28日，油气总公司协同办公项目组、神州数码、三级企业信息专员齐聚油气济南公司，开始协同办公平台项目测试工作。油气总公司三级企业协同办公平台项目于2011年10月18日启动后，神州数码公司在对油气总公司所属企业进行了调研并开发了统一的流程项目模板。在协同办公平台项目测试阶段，各企业信息专员结合本单位的情况，对每个流程项目梳理、取舍、熟悉和完善，以求项目完整、操作简便、实用性强。这次测试共四天时间，测试完成后，将进入试运行阶段。（济南公司段连山）

协同办公平台项目在华星与正和启动

12月6日，协同办公平台项目启动大会先后在华星石化和正和石化召开。油气总公司领导滕远方、刘长城等及两家企业的高中层管理人员、各部门信息专员和神州数码项目团队参加了会议。会上，项目有关人员就协同办公项目背景、项目组织架构及项目人员职责、项目实施内容及范围、项目计划以及项目成功的关键因素等五大方面的内容进行了介绍。协同办公平台由神州数码负责设计、制作与维护，项目启动上线后，会加快企业内部信息的流转、处理和共享，实现办公流程现代化、信息资源化、传输网络化、管理人性化和监督透明化，并建立与中国化工集团共享的信息平台，打造无所不在的电子化工作场所，从而达到管理高效的目的。会议同时对两家企业各部门信息专员进行了培训。（正和石化李学锋）

中国化工检查组在昌邑石化指导ERP上线工作

12月5日下午，中国化工集团公司副CIO周冠宇一行十人到昌邑石化检查指导 ERP项目上线准备工作，并主持召开上线调研汇报会。油气公司首席信息官滕远方、管信部主任朱宝生、昌邑石化副总经理姜建

篇5：OA项目总结

http://oa.hotongroup.com:8089

集团信息中心

【OA协同办公系统使用教程】

项目管理详细教程

内训资料

项目管理...................................................................................................................................................................................2 功能介绍...........................................................................................................................................................................2 基础数据的设置...............................................................................................................................................................2 立项申请...........................................................................................................................................................................4 项目审批...........................................................................................................................................................................6 我的项目...........................................................................................................................................................................6 我的任务...........................................................................................................................................................................8 项目文档.........................................................................................................................................................................10 项目问题.........................................................................................................................................................................11

OA协同办公系统使用教程

项目管理

功能介绍

协同项目管理组件以事件为中心，以项目文档、项目流程为驱动，以任务安排、项目监管、问题总汇等功能做辅助，集中体现了企业事务管理中的“事事皆项目”的核心思想。

首先项目应该是有计划的，因此协同项目管理指派专门的项目审核人员对项目计划进行审核，层层审批，实现项目立项、项目更改的监察和管理。

项目应立足文档，实现报表功能，在协同项目管理中，项目的具体事务以流程进行记录，以项目文档进行保存，将工作流与项目管理结合起来，实现项目明细的汇总统计和知识共享。不仅如此，项目管理中遇到的问题、疑难，皆可实现实时问答，并提供项目问题的汇总，实现项目知识的沉淀。

协同项目管理组件在OA办公系统中，不仅实现了项目计划管理，还实现了项目知识管理、项目文档共享和项目流程管理，它是企业信息化管理中不可或缺的一件利器，是OA管理的重要组成部分。

基础数据的设置

协同项目管理中，首先应该进行基础数据的设置，设置包括对项目权限的设置和对项目代码的设置，前者代表了用户在系统中的管理权限，后者体现了OA 以客户需求为主导的个性化解决方法。

1、项目权限设置：

项目权限包含项目的立项申请权限和项目审批权限两种。选择方法如图所示，以“部门”、“角色”和“人员”三种方式进行选择。

/ 11

内训资料

另外，项目权限设置增加免审人员设置，可按部门、角色、用户进行设置。进入基础数据设置->项目权限设置,切换至审批权限后，点击【设置免审批范围】按钮，方可按部门、角色、用户，设置免审人员。具体设置页面如下图所示：

/ 11

内训资料

2、项目代码设置

系统代码设置类似“系统管理”-“自定义字段设置”功能，这里主要设置“项目类型”、“项目角色类型”、“项目文档类型”、和“项目费用类型”。

“项目类型”是立项申请时设定项目类别时的供选择项，此代码主要是设定项目类型的“代码编号”、“排序号”和“代码名称”。

“项目角色类型”是在立项申请时一般认定的项目成员的所属类型，立项时，需按照不同的项目角色添加项目成员，项目成员即未来的项目任务的参与人。在建立项目任务时，需按照不同的任务设定项目的执行人，执行人就是从项目成员中选取。

“项目文档类型”是立项申请时项目文档中的类型定义。

“项目费用类型”是在项目预算时需要输入的各种费用的类型，不同公司可以自定增减。

3、项目模板管理

对立项过程中生成的模板进行管理。

立项申请

在页面中部显示【+新建项目】字样，点击出现立项申请页面。在项目申请过程中，标注有红色“*”符号的为必填项。

1、基本信息：

/ 11

内训资料

基本信息中，需要设定项目的编号、名称和项目计划周期，其中会显示该项目的当前创建人。项目基本信息中还需要设定其类别，便于查看和管理。项目创建人可以看到项目的详细信息，并追踪和点评任务进度。

“项目负责人”默认值为 OA 登录用户，项目负责人也可以通过点击该字段后面的“添加”按钮，修改项目负责人。

“参与部门”是项目参与范围的设定。

“项目查看者”可以看到项目的详细信息，并追踪和点评任务进度。

“项目审批人”是设定该项目的审核管理者，审批人从项目权限设置中设定的审批人员中选择，审批人可以追踪项目信息以及点评任务进度。

在项目的其余信息未设定前，请点击【保存】，不要点击“提交审批”。完成“基本信息”后才能够进入下一项“项目成员”的设定。

2、项目成员：

项目成员就是项目参与人，在建立项目成员时，需按照项目角色进行设定，项目角色类型在“项目代码设定”中修改。在这里设定的项目成员，就是在项目任务、项目文档中设定具体权限的可供选择的人员范围。

3、项目任务：

项目任务是项目中具体事务的名称，每一个项目是由许多具体事件组成的，每一个事件都可以称之为“任务”，任务需要设定的是任务的名称、执行人（执行人从项目成员范围中选择）和任务计划周期，其余信息为选填项。

“前置任务”：即相同项目内，在当前任务之前的任务列表，可设定某个任务与当前任务的前后关系。一旦设定前置任务，本任务的开始时间自动由前置任务决定，即：前置任务结束时，本任务自动开始计时。

“任务工时”：由“任务计划周期”自动生成，“任务描述”是对任务内容的描述，便于任务执行人理解任务的意义，“任务级别”设定了当前任务的紧急程度。

“里程碑”：任务进程中作为标志性的记录。“项目流程”：当该项目运行时，任务执行人可以发起流程，并监控流程的运行状况。

/ 11

内训资料

4、项目文档：

“项目文档”是项目中需要保存的文档存储所在，该功能中可以设定具体文件夹，以及文件夹的“新建”、“删除”、“修改”和“查看”权限，候选人员皆为“项目成员”。

5、项目预算：

“项目预算”是系统中进行预算金额输入和统计的模块，具体项目预算的类型由“项目代码设置”中设定。在各项信息都设定后，回到“基本信息”，点击【提交审批】，项目就进入审批。在提交审批后，项目基本信息就无法继续修改。

项目审批

具备“项目审批人”权限的用户，在“项目审批”模块中，可以看到待审批项目与项目审批记录，在通过或拒绝项目审批时，审批人都需要输入项目审批意见，以供立项创建人查阅，并将以通过的审批记录留存在项目审批记录中。

审批后，立项创建人会短信提醒，告知项目审批的情况。

项目审批记录中还可看到审批人曾经审批的项目的详细信息和实际结束时间。我的项目与任务

我的项目

进入“我的项目”，项目中心页面如下图所示。左侧项目树形图展示了项目名称列表与项目状态，可以按照项目类型和时间进行查询。右侧项目列表展示了项目更加详细的信息，包括：项目编号、项目名称、开始时间、结束时间、结束的实际时间、状态等。还可以根据状态、项目计划周期、项目编号、项目创建人进行查询。

页面中显示出当前用户有权查看的所有项目列表（项目查看者、项目成员和项目审批人都可以看到相关项目信息），点【+立项申请】可进入立项信息填写，在列表中，点击“项目名称”可查看该项目的各项详细信息。

/ 11

内训资料

在列表中，项目审批人可以看到项目的“删除”操作，以及当前项目的状态、“项目变更”和“编辑”操作。

当前项目状态分为“进行中”—表示该项目已经通过审批并运行，这种状态下项目可进行“项目变更”操作，即修改项目信息；

“已超时”—说明该项目当前已经超出创建项目时的计划结束时间，此时项目可以变更； “审批中”—说明项目已经保存并提交审批但暂未获批准，审批中的项目不能进行任何操作； “立项中”—表示项目当前处于创建信息阶段，尚未提交审批，此时可自由编辑或删除项目。在项目信息页面中，包含“基本信息”、“项目文档”、“任务列表”、“问题追踪”、“讨论区”和“项目批注”三个类型的信息。

1、基本信息：项目信息包含了项目基本信息与审批记录，页面主要篇幅显示的就是项目信息中的基本信息。点击【审批记录】可查看当前项目的历史审批结果。

2、项目文档：显示项目中上传的文档。

3、任务列表：显示任务列表以及完成的状态。

任务列表—本项目所有的任务信息列表；甘特图—项目进度图形化显示；

4、问题跟踪：项目问题的汇总；

5、讨论区：项目交流中显示出项目在运行中讨论区信息；

6、项目批注：项目中领导批注的具体内容。

1、项目描述中插入图片功能进入项目管理，新建项目页面，输入信息后，点击【插入图片】按钮，可以向描述内容中插入图片如下图所示：

/ 11

内训资料

2、项目管理查看和编辑页面从新页签打开

项目管理，我的项目，点击【编辑】或【查看】按钮时，页面从新页签打开，如下图所示：