CN102169562A - 一种项目计划处理方法及系统 - Google Patents

Abstract

本发明公开了一种项目计划处理方法及系统，其中，所述方法包括：接收用户的登录请求，解析所述登录请求以获取用户的身份信息；根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；接收用户针对所述计划任务提交的管理请求，确定所述管理请求对应的项目计划分解信息状态；针对所述管理请求及所述项目计划分解信息状态产生相应的事件；将所述事件发送到事件驱动架构(Event Driven Architecture，简称EDA)引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。通过本发明，能够借助于计算机系统，实现更高效的工作分解，进而适应于大项目多层次、多单位的计划协同。

Description

一种项目计划处理方法及系统

技术领域

本发明涉及Web服务技术领域，特别是涉及一种项目计划处理方法及系统。

背景技术

工作分解结构(Work Breakdown Structure，以下简称WBS)是在项目管理中以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作更详细的定义。

目前，在项目管理等应用领域，通常是由各级计划人员对项目进行WBS分解，然后通过会议等方式传达到各个下级单位，以便由多个单位或单位内部的部门协同完成项目计划。例如，通常由各级计划人员根据WBS进行进度、资源等的规划与分配，将整个项目从第一级分解到最后一级。而在确定各级计划时，一般是基于会议的方式进行线下的沟通协调。但是，对于一个规模大、参与单位多、层次多的项目而言，这种协调方式会比较费时费力，无法适应这种大项目多层次、多单位的计划协同。

因此，迫切需要本领域技术人员解决的技术问题就是：如何利用强大的计算机系统，对项目管理中的工作分解进行支持，从而实现更高效的工作分解，以适应于大项目多层次、多单位的计划协同。

发明内容

本发明提供一种项目计划处理方法及系统，能够借助于计算机系统，实现更高效的工作分解，进而适应于大项目多层次、多单位的计划协同。

为实现上述目的，本发明提供了如下方案：

一种项目计划处理方法，在计划的不同阶段下发工作分解结构WBS分解的项目计划分解信息，对项目WBS计划分解信息进行逐级反馈，将协调后的项目计划分解信息下发，对各层的项目计划分解信息进行逐级确认；其中，所述项目计划分解信息包括任务量和相应的进度控制数；所述方法包括：

接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；

接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

其中：

所述管理请求包括新建项目计划分解信息的请求，所述项目计划分解信息状态包括新建状态；

所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理包括：

所述EDA引擎调用新建项目计划分解信息的方法，产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。

其中：

所述管理请求包括修改项目计划分解信息的请求，所述项目计划分解信息状态包括变更状态；

所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理包括：

所述EDA引擎调用变更项目计划分解信息的方法，产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。

优选地，所述项目计划分解信息带有版本号，所述方法还包括：

当用户读取项目计划分解信息时，获取该项目计划分解信息在该读取时刻的第一版本号；

当接收到用户提交的携带有所述第一版本号的修改项目计划分解信息请求时，从该请求中解析出所述第一版本号，并获取该项目计划分解信息在该请求提交时刻的第二版本号；

判断所述第一版本号与第二版本号是否一致，如果一致，则将所述项目计划分解信息的版本号增加，并接受该修改请求；否则，拒绝该修改请求。

优选地，所述方法还包括：

当用户需要对所述项目计划分解信息进行修改操作时，获取针对该项目计划分解信息建立的锁，如果获取到，则将所述项目计划分解信息设置为可修改状态，否则，则将所述项目计划分解信息设置为不可修改状态。

优选地，所述将各个分解后计划任务下发到对应的执行者之前还包括：

将各个分解后计划任务向对应的执行者进行预发布；

当接收到各个执行者确认的反馈信息后，执行将各个分解后计划任务下发到对应的执行者的步骤。

优选地，所述确定各个分解后计划任务对应的执行者之后还包括：

向各个分解后计划任务对应的执行者发送通知消息。

优选地：采用异步的处理方式向所述EDA发送产生的事件。

一种项目计划处理系统，在计划的不同阶段下发工作分解结构WBS分解的项目计划分解信息，对项目WBS计划分解信息进行逐级反馈，将协调后的项目计划分解信息下发，对各层的项目计划分解信息进行逐级确认；其中，所述项目计划分解信息包括任务量和相应的进度控制数；所述系统包括：

解析单元，用于接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

展现单元，用于根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；

请求接收单元，用于接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

事件产生单元，用于针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

发送单元，用于将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

其中：所述管理请求包括新建项目计划分解信息的请求，所述项目计划分解信息状态包括新建状态；

所述EDA引擎包括：

第一调用子单元，用于所述EDA引擎调用新建项目计划分解信息的方法，产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。

其中：所述管理请求包括修改项目计划分解信息的请求，所述项目计划分解信息状态包括变更状态；

所述EDA引擎包括：

第二调用子单元，用于所述EDA引擎调用变更项目计划分解信息的方法，产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。

优选地，所述项目计划分解信息带有版本号，所述系统还包括：

第一获取单元，用于当用户读取项目计划分解信息时，获取该项目计划分解信息在该读取时刻的第一版本号；

第二获取单元，用于当接收到用户提交的携带有所述第一版本号的修改项目计划分解信息请求时，从该请求中解析出所述第一版本号，并获取该项目计划分解信息在该请求提交时刻的第二版本号；

判断单元，用于判断所述第一版本号与第二版本号是否一致，如果一致，则将所述项目计划分解信息的版本号增加，并接受该修改请求；否则，拒绝该修改请求。

优选地，所述系统还包括：

锁定单元，用于当用户需要对所述项目计划分解信息进行修改操作时，获取针对该项目计划分解信息建立的锁，如果获取到，则将所述项目计划分解信息设置为可修改状态，否则，则将所述项目计划分解信息设置为不可修改状态。

优选地，所述系统还包括：

预发布单元，用于将各个分解后计划任务向对应的执行者进行预发布；

反馈接收单元，用于当接收到各个执行者确认的反馈信息后，执行将各个分解后计划任务下发到对应的执行者的步骤。

优选地，所述系统还包括：

通知单元，用于确定各个分解后计划任务对应的执行者之后，向各个分解后计划任务对应的执行者发送通知消息。

优选地：所述发送单元采用异步的处理方式向所述EDA发送产生的事件。

根据本发明提供的具体实施例，本发明公开了以下技术效果：

在本发明中，能够通过统一的计算机系统对项目计划进行管理，每一级计划任务的执行者都可以登录该系统，从而获得分配给该执行者的计划任务，该执行者可以在该系统中对该计划任务进行管理(包括对当前的计划任务进行再细分并下发、或者对项目计划进行的修改等)。系统在接收到执行者的管理请求后，可以产生一事件，将该事件发送到事件驱动架构(Event Driven Architecture，以下简称EDA)引擎去处理，进而，EDA就可以调用该事件对应的事件处理方法进行相应的处理即可。可见，在本发明中，每一级的业务执行者都可以仅针对分配给自己的计划任务进行管理，对应用系统而言，在处理用户请求时，采用了EDA架构，由于EDA引擎与Web服务器中的业务逻辑系统是不同的模块，可以部署于不同的服务器，因此，可以避免单服务器工作时带来的性能瓶颈，为处理海量数据提供了可能。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的多级计划组织形式示意图；

图2是本发明实施例提供的方法的流程图；

图3是本发明实施例提供的多级计划分解流程图；

图4是本发明实施例提供的零级计划分解流程图；

图5是本发明实施例提供的一级计划分解流程图；

图6是本发明实施例提供的系统的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中，为了实现高效地工作分解及管理，提供一种简单、易推广、满足多层次、多层级协同管理要求的计划编制方法，同时通过计算机技术和网络技术实现计划的逐级编制、审核、下发、反馈、发布过程，实现计划的多级协同编制，以便提高计划编制效率，提高计划有效性、合理性以及可执行性。

参见图1，本发明实施例中的计划过程采取多级计划的组织形式，以便进行交互式迭代，由上到下逐级完成项目计划，由上到下逐级下达计划，由下到上反馈上报各级计划，每一级制定本级承担的计划分解工作，每一级计划由相应的计划人员完成，经本级单位领导审核通过后，下发下一级任务承担单位。下一级任务承担单位根据上级WBS计划分解本单位执行的WBS计划，向上级上报本级、本单位负责的计划，并根据下级的反馈和上级的计划调整来修改调整本级、本单位负责的计划。

这样，相当于采用统一的计划制定软件平台，实现了一种“两上两下”的计划制定方式，从而实现多级、多组织、多层次协同的计划制定模式。其中，“两上两下”分别是指，一下：在计划不同的阶段向下逐级下发WBS任务量和相应的进度控制数；一上：对计划WBS分解的任务量和进度控制数的向上级逐级反馈；二下：将协调后计划WBS任务量和进度控制数再向下级逐级下发；二上：对各层级的计划WBS任务量和进度控制数向上级逐级确认，计划正式发布。也就是说，通过各层级计划的反复下发、反馈、确认的迭代，通过计算机软件在网络环境中实现在同一网络环境下计划数据的共享，参与项目计划的各级单位协同完成完整的项目计划。下级计划的变动不能直接引起上级计划数据的变化，上级计划的变动只能由上级计划的制定者修改调整。

在此过程中，数据的特点如下：计划的发布、审核、反馈、接收、上报等事件，会引起项目计划分解信息的状态变化，给相应的处理人产生一个计划任务，还可以同时给相关的人员发送通知消息。针对这种类型的数据，现有技术中常用的处理方式，是直接对每个事件编写对应的处理程序，以便处理计划的更新、产生计划任务和发送通知消息等等。但是这种方式的缺点在于：业务逻辑完全嵌入在处理程序中，使得程序的扩展性不强，并且在计算机的处理性能上容易产生瓶颈，并不适合于计划数据量大、分布广泛的现实状况。

为此，在本发明实施例中，提供了相应的处理方案，参见图2，本发明实施例提供的项目计划处理方法包括以下步骤：

S201：接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

在本发明实施例中，可以采用Web服务的方式实现，这样，相当于各级用户可以通过Web页面访问Web服务器上保存的数据。具体实现时，由于每级用户的权限以及需要承担的任务都可能不同，因此，为了区分不同的用户，可以设置为，需要在用户登录服务器之后，才会访问到相应的内容。为此，可以为用户提供注册用户信息的入口，用户从该入口注册成功之后，服务器可以记录用户的注册信息，并且用户可以利用这些注册信息登录Web服务器。

也就是说，对于一个已经注册过的用户，可以在Web页面上向Web服务器发起登录请求(例如，通过输入用户名、密码的方式)，Web服务器在接收到该登录请求之后，就可以从中解析出用户的身份信息，以便在后续的步骤中使用该信息。

S202：根据所述身份信息，向所述用户展现上级分配给该用户的计划任务；

如前文所述，由于每一级在进行项目计划分解之后，由于在计划的不同阶段下发WBS分解的项目计划分解信息，因此，对于某一级别的用户X而言，当其登录到Web服务器之后，就可以看到上级下发给用户的计划任务。例如，某一级用户接收到的计划任务是任务A，该一级用户将该任务A分解为任务A1、A2、A3之后，将其分别下发给其下级用户X、Y、Z，对于Web服务器而言，在完成下发之后，会保存任务与用户之间的对应关系；这样，当用户X使用自己的注册信息登录到Web服务器之后，Web服务器在解析出该用户X的身份信息之后，就可以将上级用户下发给该用户X的计划任务A1展现给该用户X；类似的，当用户Y或Z使用自己的注册信息登录到Web服务器之后，Web服务器在解析出该用户Y或Z的身份信息之后，就可以将上级用户下发给该用户Y或Z的计划任务A2或A3展现给该用户Y或Z。为了便于描述，以下均以用户X为例进行介绍。

S203：接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

当用户X登录到Web服务器，并看到自己的计划任务A1之后，就可以对该计划任务进行管理。例如，包括对任务A1的进一步分解，并向下级用户进行下发，或者，向上级用户进行反馈，或者对已经分解的计划进行变更等等。因此，相应的项目计划分解信息状态就可以包括项目计划分解信息的新建、反馈、变更等等。也就是说，接收到的管理请求，可能是新建、反馈、变更等请求，对应的项目计划分解信息状态也有新建、反馈、变更等。在接收到用户提交的管理请求之后，可以将相关的信息保存到数据库中。

S204：针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

在本发明实施例中，采用基于事件驱动的处理框架，也即，每次接收到用户的一个管理请求，都可以产生相应的事件，例如，当接收到新建请求时，即可产生新建一个项目计划分解信息的事件，当接收到变更请求时，即可产生对当前的项目计划分解信息进行修改的事件，等等。

S205：将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

在本发明实施例中，在针对用户的管理请求产生了相应的事件之后，并不是直接调用事件处理程序进行处理，而是将事件发送到EDA引擎，有EDA引擎去调用相应的事件处理方法进行相应的处理。其中，EDA是一种用于进行设计和实现应用和系统的方法，在这些应用和系统里，事件所触发的消息可以在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。这些应用程序中的EDA极大地改进了响应不同的、表面上毫无关联事件的能力。通过提供瞬时过滤、聚合和关联事件等能力，EDA可以快速地检测出事件并判断它的类型，从而帮助组织机构快速、恰当地响应和处理这些事件。

也就是说，在本发明实施例中，将EDA架构应用到项目计划分解的过程中来，使得业务逻辑层与具体的事件处理层相分离，也就是说，主要的业务逻辑，包括请求的接收、信息的保存等可以由业务逻辑层来完成，而事件处理等附加的业务逻辑则可以由EDA引擎来完成。这样，如果附加的业务逻辑需要发生变化，就可以改变对应的事件处理器的配置，而不需要改动主业务逻辑层的程序，从而增强了程序的可扩展性。其次，EDA引擎和业务逻辑层是不同的模块，可以部署于不同的服务器，这就为处理海量数据提供了可能，避免单服务器带来的性能瓶颈。另外，引入EDA引擎后，还可以对处理过程发生的事件进行很好的跟踪，统一进行日志记录等等。

需要说明的是，在具体实现时，业务逻辑层产生的事件可以具有自己的ID，对于EDA引擎而言，预先保存了各个事件的ID与事件处理方法之间的对应关系，因此，在接收到一个事件之后，直接调用该事件的ID对应的事件处理方法进行相应的处理即可。

例如，当管理请求为新建请求时，产生的事件是新建事件，则EDA引擎就会调用新建事件对应的事件处理方法进行相应的处理。具体实现时，如果用户需要针对上一级下发给其的某计划任务进行进一步地分解，则该用户可以在Web页面上录入分解信息(例如前述例子中的将任务A分解为A1、A2、A3等等)，然后点击“提交”等按钮，这样，Web服务器就可以接收到该新建请求。将项目计划分解信息状态确定为新建状态，之后就可以产生一个新建事件，并将其发送给EDA引擎。EDA引擎在接收到该事件之后，就可以调用新建事件对应的事件处理方法进行处理。具体的处理过程可以包括：产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。当然，为了使得下级执行者能够及时获知有新任务到来，还可以同时向执行者发送通知消息，例如，可以通过发送短消息等方式，使得用户即使没有在线，也可以获知新任务的到来。

当管理请求为变更时，对应的项目计划分解信息状态为变更状态，因此，主业务逻辑会产生变更事件，并将其发送给EDA引擎，则EDA引擎就会调用变更事件对应的事件处理方法进行相应的处理。例如，当用户登录到Web服务器看到上级下发给其的计划任务，以及之前对该计划任务的分解信息之后，如果需要对已经分解的信息进行修改，则可以在Web页面上提交修改后的分解信息，例如，以前是将任务A分解为A1、A2、A3，修改之后是将该任务A分解为A1、A2、A4，然后点击“提交”等按钮，这样，Web服务器就可以接收到该变更请求，并将项目计划分解信息状态确定为变更状态，之后就可以产生一个变更事件，并将其发送给EDA引擎。EDA引擎在接收到该事件之后，就可以调用变更事件对应的事件处理方法进行处理。具体的处理过程可以包括：产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。类似的，为了使得下级执行者能够及时获知有新任务到来，还可以同时向执行者发送通知消息，例如，可以通过发送短消息等方式，使得用户即使没有在线，也可以获知新任务的到来。

当然，无论是在新建还是在变更的过程中，在具体的将各个分解后计划任务下发到对应的执行者之前，还可以将各个分解后计划任务向对应的执行者进行预发布，当接收到各个执行者确认的反馈信息后，再执行将各个分解后计划任务下发到对应的执行者的步骤。

其中，关于主业务逻辑与EDA之间的事件发布方式，可以采用同步或者异步方式。而在本发明的优选实施例中，可以采用异步的处理方式，也就是说，当主业务逻辑产生一个事件，并向EDA引擎发送之后，不需要等待EDA引擎的反馈，就可以向EDA引擎发送下一个新产生的事件。这样，对于主业务逻辑层而言，只需要完成主业务逻辑就可以返回响应结果，因此，可以使主业务逻辑层对用户的响应速度得到提升。

总之，通过以上所述可见，本发明实施例能够通过统一的计算机系统对项目计划进行管理，每一级计划任务的执行者都可以登录该系统，从而获得分配给该执行者的计划任务，该执行者可以在该系统中对该计划任务进行管理(包括对当前的计划任务进行细分的计划分解并进行下发、或者对项目计划分解进行的修改等等)。系统在接收到执行者的管理请求后，可以产生一事件，将该事件发送到事件驱动架构EDA引擎去处理，进而，EDA就可以调用该事件对应的事件处理方法进行相应的处理即可。可见，在本发明中，每一级的业务执行者都可以仅针对分配给自己的计划任务进行管理，对应系统而言，在处理用户请求时，采用了EDA架构，由于EDA引擎与Web服务器中的业务逻辑系统是不同的模块，可以部署于不同的服务器，因此，可以避免单服务器工作时带来的性能瓶颈，为处理海量数据提供了可能。

在实际应用中，可能存在这样的情况：同一项目计划A同时下发给了用户X和用户Y，用户X和用户Y都可以对项目计划A进行管理操作，包括进行分解，或者进行分解信息的变更等等。如果在某一时刻，用户X和用户Y都需要对项目计划A进行管理操作，则可能会发生冲突。例如，某用户X在登录到服务器之后，展现给该用户的关于某项目计划A当前的分解信息是，分解为A1、A2、A3，用户X需要将A3修改为A4；但是，由于修改的过程需要用户手动地录入新的分解信息，还需要经过网络传输才能到达服务器，这期间需要经历一定的时间周期。如果恰好是在这个时间段内，用户Y也对该项目计划A的分解信息进行了修改，例如，假设将A3修改为A5，并且已经在用户X提交之前完成了修改的操作，则服务器在处理用户X提交的修改请求时就会出错，因为数据库中已经不存在A3这一项目计划了。为了解决上述问题，需要在项目计划分解的过程中，进行并发控制，下面对此进行详细地介绍。

在本发明实施例中，可以为项目计划的分解信息生成版本号，也即对于某项目计划而言，某用户为其新建了项目计划分解信息时，系统可以自动为其生成版本号，例如，新建时的版本号可以为1；当用户成功进行第一次更新之后，可以将其版本号增加为2，以此类推。在用户需要对某项目计划的项目计划分解信息进行更新等操作时，系统在读取项目计划分解信息的同时，可以同时获取该读取时刻该分解信息的版本号。然后用户可以在Web界面上录入新的项目计划分解信息，当用户点击“提交”等按钮之后，服务器可以接收到用户的修改请求，该提交请求中可以携带有读取时刻的版本号；此时，服务器再去读取该项目计划分解信息当前的版本号，并比较两个时刻读取到的版本号是否一致，如果一致，则可以继续针对该用户的修改请求进行相应的处理(包括保存修改后的分解信息，以及将分解信息的版本号增加等等)，如果不一致，则拒绝接受此次修改请求。

为了更好地理解上述方案，下面结合例子进行介绍。假设用户X在T1时刻登录Web服务器，读取项目计划A的分解信息时，记录下其读取时刻的版本号是1；用户Y在T2时刻登录Web服务器，读取项目计划A的分解信息时，记录下其读取时刻的版本号也为1。用户X在看到版本号为1的分解信息之后，需要对其进行修改，录入了新的分解信息之后，在T3时刻将修改请求发送到Web服务器，该修改请求中携带有版本号1；Web服务器从修改请求中解析出版本号1，并重新去数据库中获取该项目计划的当前版本号，假设当前版本号也为1，则两个版本号一致，因此，可以接受该用户X的修改请求，同时，将该项目计划的版本号修改为2。而用户Y在看到版本号为1的分解信息之后，也需要进行修改，并假设在时刻T4提交了修改请求，其中，该修改请求中也携带有版本号1；Web服务器在接收到用户Y的修改请求之后，从中解析出版本号1，同时去数据库中读取该项目计划当前的版本号，假设为2，则两个版本号不一致，因此可以拒绝用户Y的修改请求。此时，对于用户Y而言，可以采用刷新Web页面等方式，重新向Web服务器发起读取项目计划分解信息的请求，Web服务器可以重新将版本号为2的分解信息展现给用户Y，用户Y可以在该版本号为2的分解信息基础上，重新考虑是否需要进行修改。

当然，在实际应用中，还可能存在更为严重的冲突。例如，两个用户针对同一项目计划提交管理请求的时间间隔非常短，即，在前述例子中，T3时刻与T4时刻很接近，则在接收到用户X对某项目计划A的修改请求时，发现两个时刻的版本号都为1，在接收到用户Y对该项目计划A的修改请求时，发现两个时刻的版本号也是都为1，因此，用户X和用户Y的修改请求就都会被接受，但是，在具体将修改后的信息保存到数据库中时，就会发生冲突，造成保存失败等现象。

为此，本发明实施例还增加了锁机制，当用户需要对所述项目计划分解信息进行修改操作时，需要首先去获取针对该项目计划分解信息建立的锁，如果获取到，则将项目计划分解信息设置为可修改状态，如果获取不到，则将项目计划分解信息设置为不可修改状态。也就是说，如果某用户获取到对某项目计划的修改权之后，就会将其锁定，在锁定解除之前，其他用户无法对该项目计划进行修改操作，这样就可以有效地避免前述冲突的发生。

关于上述锁机制，具体实现时，对于Web服务器采用单服务器方式实现的情况，可以采用内存锁的方式来实现。例如，可以利用Java语言里的synchronized关键字，并为每个项目计划分解信息创建一个对象，从而为每个分解信息建立了内存锁。内存锁保证了在同一个JVM里，某个时刻只能有一个线程对某个项目计划分解信息进行修改，从而保证了修改信息的一致性。如果在分布式环境下，也即在具有多台Web服务器的情况下，只需要将内存锁改成文件锁即可，即共享文件服务器上的某个文件对应的锁。

总之，在本发明实施例中，解决了计划分解过程中出现海量数据时存在的问题，在解决了这些问题之后，即便在遇到海量数据时，也可以采用本发明实施例中“两上两下”的计划制定模式。

下面介绍上述“两上两下”的计划制定模式在实际中的应用。首先，参见图3，其为计划制定过程中涉及的流程图，其中，计划本身逐级分为零级计划、一级计划、二级计划、...、N级计划，具体的制定计划的步骤可以包括：

步骤一、零级计划制定后预发布，下发下级承担单位；

步骤二、预发布的零级计划下发，由相关一级承担单位确认是否按此进行，一级计划单位若接受零级计划或待定，则进行本单位负责部分的一级计划分解，然后预发布至二级计划承担单位，若不接受，则向上反馈。二级、三级依此类推；

步骤三、每层级的计划制定后，须经本层级的计划审核人员审核同意后预发布，再下发下级承担单位进行计划确认、分解，计划审核人员包括总工程师、主任设计师、主管设计师等等；

步骤四、各级计划经过上述下发、确认、上报过程后，系统对所有计划节点的状态进行检查，如果均已处于确认状态，则由上至下发布计划，项目基准计划完成。

其中，零级计划主要制定项目总的计划分解目标，其流程参见图4，包括如下步骤：

步骤一、计划编制人员根据合同或项目要求进行WBS分解，形成零级计划；

步骤二、零级计划需要通过主管领导如所长、总工程师等相关人员的审核，如审核通过，则将零级计划下发下级承担单位；如审核未通过，则修改调整零级计划；

步骤三、下发后的零级计划，经下级承担单位接收确认后反馈信息，零级计划的编制单位综合各承担单位反馈的信息后，决定是否需要调整零级计划。如需要调整修改，则重复上述过程；

步骤四、零级计划及各级计划经反复下发、确认、审核后，由零级计划编制单位正式发布零级计划，下属各级计划逐级发布。

多级计划中的中间承担单位负责一级、二级等计划等，如图5所示，其为一级计划的流程，包括：

步骤一、一级计划承担单位根据零级计划中本单位承担的计划节点制定一级计划；

步骤二、一级计划经本单位领导审核，如审核通过，则预发布本单位承担的一级计划；如审核未通过，则再修改调整一级计划；

步骤三、预发布的一级计划下发各下级承担单位，下级承担单位确认后反馈信息。一级计划的承担单位综合下级反馈的信息，决定是否调整一级计划。如不需调整，则上报零级计划承担单位；如需要修改，由计划人员再行修改调整；

步骤四、一级计划及下属各级计划经反复下发、确认、审核后，在零级计划发布后，由上至下发布一级计划。

其他各级计划也与上述类似，这里不再一一赘述。

总之，上述总流程和子流程在计算机系统中，通过网络环境实现计划多级协同方式的分解制定。通过网络环境和计算机系统实现计划的分解、下发、上传等，需要严格控制计划分解和浏览的权限。根据安全保密的要求，一般可以约定：上级可以浏览所属下级的所有的计划分解，下级只能浏览所负责计划节点及其下属分解计划；每一层级的计划节点均只能由该计划节点的负责单位进行分解，其它单位无权浏览和分解；每一层级承担单位内部分解计划由指定的角色或人员进行审核。

上述总流程和子流程实现方法也可脱离网络应用环境。可以基于计算机系统，也适用于以介质形式下发、上报各级任务的计划方式，在计算机系统中可以将上报计划的电子介质逐级汇总，也可以将计划以电子介质的形式分级下发。

与本发明实施例提供的项目计划处理方法相对应，本发明实施例还提供了一种项目计划处理系统，该系统用于，在计划的不同阶段下发工作分解结构WBS分解的项目计划分解信息，对项目WBS计划分解信息进行逐级反馈，将协调后的项目计划分解信息下发，对各层的项目计划分解信息进行逐级确认；其中，所述项目计划分解信息包括任务量和相应的进度控制数；参见图6，该系统包括：

解析单元601，用于接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

展现单元602，用于根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；

请求接收单元603，用于接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

事件产生单元604，用于针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

发送单元605，用于将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

其中，管理请求可以包括新建项目计划分解信息的请求，所述项目计划分解信息状态包括新建状态；

所述EDA引擎包括：

第一调用子单元，用于所述EDA引擎调用新建项目计划分解信息的方法，产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。

管理请求也可以包括修改项目计划分解信息的请求，所述项目计划分解信息状态包括变更状态；

所述EDA引擎包括：

第二调用子单元，用于所述EDA引擎调用变更项目计划分解信息的方法，产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。

为了处理并发控制问题，所述项目计划分解信息可以带有版本号，此时，该系统还可以包括：

第一获取单元，用于当用户读取项目计划分解信息时，获取该项目计划分解信息在该读取时刻的第一版本号；

第二获取单元，用于当接收到用户提交的携带有所述第一版本号的修改项目计划分解信息请求时，从该请求中解析出所述第一版本号，并获取该项目计划分解信息在该请求提交时刻的第二版本号；

判断单元，用于判断所述第一版本号与第二版本号是否一致，如果一致，则将所述项目计划分解信息的版本号增加，并接受该修改请求；否则，拒绝该修改请求。

为了更好地处理并发冲突，该系统进一步还可以包括：

锁定单元，用于当用户需要对所述项目计划分解信息进行修改操作时，获取针对该项目计划分解信息建立的锁，如果获取到，则将所述项目计划分解信息设置为可修改状态，否则，则将所述项目计划分解信息设置为不可修改状态。

在一种优选的实施方式下，该系统还可以包括：

预发布单元，用于将各个分解后计划任务向对应的执行者进行预发布；

反馈接收单元，用于当接收到各个执行者确认的反馈信息后，执行将各个分解后计划任务下发到对应的执行者的步骤。

为了使得下级执行者及时获知新分配的项目计划，该系统还可以包括：

通知单元，用于确定各个分解后计划任务对应的执行者之后，向各个分解后计划任务对应的执行者发送通知消息。

为了提高响应速度：发送单元605可以采用异步的处理方式向所述EDA发送产生的事件。

总之，本发明实施例提供的系统能够通过统一的计算机系统对项目计划进行管理，每一级计划任务的执行者都可以登录该系统，从而获得分配给该执行者的计划任务，该执行者可以在该系统中对该计划任务进行管理(包括对当前的计划任务进行细分的计划分解并进行下发、或者对项目计划分解进行的修改等等)。系统在接收到执行者的管理请求后，可以产生一事件，将该事件发送到事件驱动架构EDA引擎去处理，进而，EDA就可以调用该事件对应的事件处理方法进行相应的处理即可。可见，在本发明中，每一级的业务执行者都可以仅针对分配给自己的计划任务进行管理，对应系统而言，在处理用户请求时，采用了EDA架构，由于EDA引擎与Web服务器中的业务逻辑系统是不同的模块，可以部署于不同的服务器，因此，可以避免单服务器工作时带来的性能瓶颈，为处理海量数据提供了可能。

以上对本发明所提供的一种项目计划处理方法及系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (16)

1.一种项目计划处理方法，其特征在于，在计划的不同阶段下发工作分解结构WBS分解的项目计划分解信息，对项目WBS计划分解信息进行逐级反馈，将协调后的项目计划分解信息下发，对各层的项目计划分解信息进行逐级确认；其中，所述项目计划分解信息包括任务量和相应的进度控制数；所述方法包括：

接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；

接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

2.根据权利要求1所述的方法，其特征在于：

所述管理请求包括新建项目计划分解信息的请求，所述项目计划分解信息状态包括新建状态；

所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理包括：

所述EDA引擎调用新建项目计划分解信息的方法，产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。

3.根据权利要求1所述的方法，其特征在于：

所述管理请求包括修改项目计划分解信息的请求，所述项目计划分解信息状态包括变更状态；

所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理包括：

所述EDA引擎调用变更项目计划分解信息的方法，产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。

4.根据权利要求3所述的方法，其特征在于，所述项目计划分解信息带有版本号，所述方法还包括：

当用户读取项目计划分解信息时，获取该项目计划分解信息在该读取时刻的第一版本号；

当接收到用户提交的携带有所述第一版本号的修改项目计划分解信息请求时，从该请求中解析出所述第一版本号，并获取该项目计划分解信息在该请求提交时刻的第二版本号；

判断所述第一版本号与第二版本号是否一致，如果一致，则将所述项目计划分解信息的版本号增加，并接受该修改请求；否则，拒绝该修改请求。

5.根据权利要求3或4所述的方法，其特征在于，所述方法还包括：

当用户需要对所述项目计划分解信息进行修改操作时，获取针对该项目计划分解信息建立的锁，如果获取到，则将所述项目计划分解信息设置为可修改状态，否则，则将所述项目计划分解信息设置为不可修改状态。

6.根据权利要求2至4任一项所述的方法，其特征在于，所述将各个分解后计划任务下发到对应的执行者之前还包括：

将各个分解后计划任务向对应的执行者进行预发布；

当接收到各个执行者确认的反馈信息后，执行将各个分解后计划任务下发到对应的执行者的步骤。

7.根据权利要求2至4任一项所述的方法，其特征在于，所述确定各个分解后计划任务对应的执行者之后还包括：

向各个分解后计划任务对应的执行者发送通知消息。

8.根据权利要求1至4任一项所述的方法，其特征在于：采用异步的处理方式向所述EDA发送产生的事件。

9.一种项目计划处理系统，其特征在于，在计划的不同阶段下发工作分解结构WBS分解的项目计划分解信息，对项目WBS计划分解信息进行逐级反馈，将协调后的项目计划分解信息下发，对各层的项目计划分解信息进行逐级确认；其中，所述项目计划分解信息包括任务量和相应的进度控制数；所述系统包括：

解析单元，用于接收用户的登录请求，解析所述登录请求以获取用户的身份信息；

展现单元，用于根据所述身份信息，向所述用户展现上级下发给该用户的计划任务；

请求接收单元，用于接收用户针对所述计划任务提交的管理请求，并确定所述管理请求对应的项目计划分解信息状态；

事件产生单元，用于针对所述管理请求及所述项目计划分解信息状态产生相应的事件；

发送单元，用于将所述事件发送到事件驱动架构EDA引擎，以便所述EDA引擎调用所述事件对应的事件处理方法进行相应的处理。

10.根据权利要求9所述的系统，其特征在于：所述管理请求包括新建项目计划分解信息的请求，所述项目计划分解信息状态包括新建状态；

所述EDA引擎包括：

第一调用子单元，用于所述EDA引擎调用新建项目计划分解信息的方法，产生分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到对应的执行者，以便完成下一级计划的下发。

11.根据权利要求9所述的系统，其特征在于：所述管理请求包括修改项目计划分解信息的请求，所述项目计划分解信息状态包括变更状态；

所述EDA引擎包括：

第二调用子单元，用于所述EDA引擎调用变更项目计划分解信息的方法，产生变更后的分解后计划任务，并根据预先配置的任务与执行者之间的对应关系，确定各个分解后计划任务对应的执行者，并将各个分解后计划任务下发到相应的执行者。

12.根据权利要求11所述的系统，其特征在于，所述项目计划分解信息带有版本号，所述系统还包括：

第一获取单元，用于当用户读取项目计划分解信息时，获取该项目计划分解信息在该读取时刻的第一版本号；

第二获取单元，用于当接收到用户提交的携带有所述第一版本号的修改项目计划分解信息请求时，从该请求中解析出所述第一版本号，并获取该项目计划分解信息在该请求提交时刻的第二版本号；

判断单元，用于判断所述第一版本号与第二版本号是否一致，如果一致，则将所述项目计划分解信息的版本号增加，并接受该修改请求；否则，拒绝该修改请求。

13.根据权利要求11或12所述的系统，其特征在于，所述系统还包括：

锁定单元，用于当用户需要对所述项目计划分解信息进行修改操作时，获取针对该项目计划分解信息建立的锁，如果获取到，则将所述项目计划分解信息设置为可修改状态，否则，则将所述项目计划分解信息设置为不可修改状态。

14.根据权利要求10至12任一项所述的系统，其特征在于，所述系统还包括：

预发布单元，用于将各个分解后计划任务向对应的执行者进行预发布；

反馈接收单元，用于当接收到各个执行者确认的反馈信息后，执行将各个分解后计划任务下发到对应的执行者的步骤。

15.根据权利要求10至12任一项所述的系统，其特征在于，所述系统还包括：

通知单元，用于确定各个分解后计划任务对应的执行者之后，向各个分解后计划任务对应的执行者发送通知消息。

16.根据权利要求9至12任一项所述的系统，其特征在于：所述发送单元采用异步的处理方式向所述EDA发送产生的事件。

Images