BI-DIRECTIONAL TRANSFORMATION BETWEEN

PROJECT DOMAIN AND PROCESS DOMAIN

Cross- Reference and Claim of Priority

This application claims priority from United States provisional patent application US62,574,286 filed October 19, 2017 for a "System and Method for Bi-Directional Transformation Between Project Domain and Process Domain", which is expressly incorporated herein to the fullest extent permitted by law.

Background

The present invention is directed to a system and method for bi-directional transformation between a project domain, for example as embodied by a Gantt Business Project Plan having temporal constraints, task relationships, subtasks, task duration types, and task resources, and an equivalent project domain, for example as embodied in a Business Process Modeling Notation (BPMN) XML specification, ready for deployment and execution by any BPM engine with real-time transformation of BPM execution events back to the project domain.

Related Art and Problem Description

Time is a critical problem in Project Management and the essential aspect for any business process, because it directly affects operation costs, losses of productivity, lack of coordination, missed deadlines or business opportunities.

To solve time planning and scheduling problem in Project Management, Gantt timeline has been successfully used worldwide since 1910 as an effective tool to specify the coordination and plan execution of projects with complex time constraints in a simple and intuitive way. Since 1995, organizations had widely adopted MS Project to help with time planning using Gantt timeline to help with scheduling automation.

Organizations adopt Business Process Management (BPM) for Project Management due to the growing need to automate and streamline time of business projects in order to save money. Still today, out-of-the-box, they face the following challenges:

• BPMN Standard Lacks Time Dimension for Project Management

It is very difficult to specify and manage complex time constraints and relationships between the flow of tasks with different behaviors inside a large BPM process in a simple way due to the lack of BPMN time dimension. The lack of time dimension prevents adoption of any business process where automating temporal coordination of tasks in a complex business process with time constraints between tasks is essential

• Gantt Project Management Software Lacks Automatic BPM Execution

Gantt timelines do not specify automatic behavior what to do when, due to project execution contingencies, any time constraint or time relationship between tasks is violated. Any task coordination or escalation action is left at the human discretion and requires manual coordination, which directly affects operation costs, losses of productivity, lack of coordination, missed deadlines or business opportunities

Example Case

1. Project Design Effort: During process planning and modeling stage, Project Manager needs to work backwards from the target deadline date in order to determine earliest possible start date using Critical Path method (sequence of tasks that will take the longest to complete to execute the process) and schedule tasks and resources with real-life different temporal and relationship constraints, i.e. Project Manager uses Gantt Project Management Software with temporal dimension for project design and testing the feasibility of executing the Gantt Project Model.

2. Process Design Effort: Process Designer uses Gantt model to manually transform all the Gantt tasks and resources constraints into BPM N process model that meets all temporal constraints and relationships specified in the Gantt model. Software Engineer will use BPMN process model to prepare, test and stage for deployment.

3. Execution Run-time Effort: When BPM N process model is deployed to BPM engine by Software Engineer, BPM

software orchestrates tasks to assigned participants, the Project Manager needs to manually map BPM process audit reports to synchronize Gantt project timeline for reporting and risk monitoring. Any re

In this example case, design and run-time requires man-months of manual effort and human coordination between Project Manager, Process Designer, and Software Engineer.

The present invention is directed to these needs. Summary

According to one aspect of the present invention, there is provided a system having a computing and communication resource, the computing and communication resource having a processor, a storage medium, and an application program stored on the storage medium comprising machine-executable code for execution by the processor, wherein the machine-readable code directs the processor to transform a project domain model into a process domain model.

This transformation may include transforming at least one of: temporal constraints, task relationships, subtasks, task duration types, and task resources.

The machine-readable code may further direct the processor to synchronize the project domain model to the process domain model.

This synchronization may include synchronizing at least one of a: process started event, process completed event, subprocess starter event, subprocess completed event, task created event, task assigned event, task completed event, call activity started event, call activity completed event, and signal fired event.

Further aspects and advantages of the present invention will become apparent upon considering the following drawings, description and claims.

Description

The invention will become more fully illustrated by the following detailed description of non-limiting specific embodiments in conjunction with the accompanying drawing figures. Brief Description of the Drawings

Figure 1 is a UML sequence diagram of a transformation and synchronization between a Gantt model and a Business Process Model, embodying aspects of the present invention.

Figure 2 is a UML class diagram of a Gannt Business Project model, embodying to aspects of the present invention.

Figure 3 is a UML deployment diagram of a computing and communication resource for storing the Gantt Business Project model and performing transformation and synchronization between the Gantt model and the Business Process Model, embodying aspects of the present invention.

Additional smaller illustrations, for example charts, UML diagrams, and source code extracts, are provided in-line as part of the text of the description, for greater clarity, concision and precision of description.

Detailed Description

The structure and operation of various aspects of the invention will now be illustrated by explanation of specific, non- limiting, exemplary embodiments shown in drawing figures and described in greater detail herein. These include embodiments of computing and communication methods, systems, networks, nodes, resources, devices, classes, artifacts and objects specially characterized and configured to provide the technical solutions to support this kind of

communication in this kind of application and to satisfy the constraints imposed. Those skilled in the art will recognize that the nature of this kind of communication and this kind of application produces specific technical problems that require solution, as will be described further below.

For greater clarity, concision and precision, the description includes inline with text additional annotations, for example in the form of charts, UML diagrams, and source code extracts.

Overview

With reference to Figures 1 and 2, those skilled in the art will come to appreciate that the teachings herein play an important role in adopting BPM for Gantt Project Management automation to eliminate human discretion, reduce project and task manual coordination to increase efficiency, productivity, human collaboration with Gantt BPM automation technology all participants in the example case realize instant time to value:

• Process Designer uses Gantt Project Management timeline to specify the required process design of all time- constrained tasks with resources and the ability to test the feasibility of executing the Gantt plan scheduling and critical path assessment feature.

• With one-click, the Gantt BPM instantly transforms it to valid Gantt BPMN process model that meets the temporal constraints and task relationships specified in the Gantt plan.

• During run-time, Gantt BPMN Model is deployed and executed in BPM Engine. The BPM Engine orchestrate tasks for all participants. When any task is started or completed in Gantt BPM Process, it automatically synchronizes state with Gantt Model instance.

• Project Coordinator is now able to monitor progress and mitigate risks in real-time by observing Gantt Model state. Gantt Business Project Model

Gantt charts are widely used, for example in business and government, to describe and monitor all kinds of projects according to the rules of project management. Gantt chart represents a timeline view of a project plan with a series of interdependent tasks that need to be performed in a particular order. Project plans have a specific start date, corresponding to the start of the first task, and a specific end date, corresponding to the end of the last task.

Gantt project plan uses a work breakdown structure, a technique for splitting tasks into sub-tasks and creating a task hierarchy linked by relationship with different types and temporal attributes.

The Gantt project model provides rich process orchestration model as an input for explicit transformation into equivalent BPM N XML specification. The output BPMN process model represents XML specification required to run the process by any BPMN-compliant engine, for example via compilation or interpretation, including via intermediate or domain-specific languages. Those skilled in the art will recognize the advantages provided by an XML implementation as taught herein, but will appreciate that other approaches would also fall within the scope of the teachings of the invention.

Mapping Gantt Project into BPMN

The equivalent BPMN specification uses start timer definition event to execute process at specific time instance followed by BPM task with the outgoing Intermediate Throw Event with the attached Signal Event.

Mapping Gantt Tasks into BPMN

Task concept is fundamental to define equivalency between Gantt and BPMN task models. Gantt task model provides several attributes in order for project coordinator to delegate task to an assignee. We will use Start(task) to denote the time instant when coordinator delegates the task to responsible performer. Finish(task) is used to denote the time instant when the task finishes. Since the real finish date may not equal with the one specified in the model, we propose to provide real task finish time, when assignee communicates time of the task completion to project coordinator. This makes flexibility to compare and analyze planned and real completion time due to underestimation or overestimation of its duration.

Mapping Gantt Task Duration Constraints into BPMN

Gantt provides specification of the estimated duration of tasks. There are two types of duration constraints: estimated and fixed. To map Gantt task into equivalent BPMN task we will distinguish between u nbounded and bounded task durations using following equivalent BPMN graphical and XML notations for Gantt task duration types.

Mapping Gantt Task Estimated Duration into BPMN

It is used to specify uncertain duration and is assumed to finish as soon as possible when the assignee informs the coordinator that the task has been completed. This behavior is using default BPMN task specification.

Mapping Gantt Task with Fixed Duration

Fixed task duration is used to specify the intention with limited time task execution constraint, in which project coordinator will need to revoke execution capability to ensure duration will be exactly as specified. This constraint is specified in BPMN as the boundary timer event attached to the task with the timer using Duration(Task) expression.

Mapping Gantt Inflexible Time Constraints to BPMN

Gantt provides inflexible time constraints such as Must Start On (MSO) and Must Finish On (MFO), which take precedence over any other restriction or relationship between tasks. Mapping Gantt Must Start On (MSO) into BPMN

Project coordinator defines MSO task to start at the specified time instant to ensure its delegation and execution regardless of what happens to other related tasks. This rigid constraint means that the task, whether linked or not, must start on the given date. Even if the preceding task is completed earlier, the Gantt application cannot pull in the constrained task to take advantage of the time gained. This constraint is specified by placing task execution in the parallel gateway sequence flow in combination with the other tasks.

Mapping Gantt Must Finish On (MFO) into BPMN

Project coordinator defines MFO completion time constraint as the instant when the execution will be revoked from the assignee regardless of what happens to other related tasks. This rigid constraint means that the task, whether linked or not, must end on the given date. As above, even if the preceding task is completed earlier, the Gantt coordinator cannot pull in the constrained task to take advantage of the time gained. This constraint is specified as the boundary timer event attached to the task. On the specified MFO time instant, the task is terminated to continue the predefined flow.

Mapping Gantt Task Temporal Behaviors into BPMN

Gantt defines two possibilities for the temporal behavior of tasks execution: As Soon As Possible (ASAP) and As Late As Possible (ALAP).

Mapping Gantt As Soon As Possible Behavior into BPMN

Project coordinator defines ASAP tem poral behavior the task to execute as soon as the sequence flow arrives. This is generally the default constraint to schedule Gantt project from its start date, as is normally the case. Gantt tries to keep this default whenever possible as it gives the most scheduling flexibility. If this constraint is applied to an u nlinked task, the task will be scheduled to start at the project start date. If applied to a linked task, it will start as soon as the dependencies with its predecessor tasks will allow. The ASAP behavior is using default BPMN task specification.

Mapping Gantt As Late As Possible Behavior into BPMIM

Project coordinator defines ALAP temporal behavior of the task to delay execution as much as possible without delaying the entire project. This is generally the default constraint when scheduling Gantt project from its end date. If this constraint is applied to an unlinked task, the task will be scheduled so that its end date coincides with the end date of the overall project. If applied to a task linked to a successor task, the task will be scheduled to end when the successor needs to start. Any delay on the task is very likely to impact the overall end date. The ALAP behavior is specified using BPMN intermediate timer throw event to delay the execution of the followed task until ALAP instant date is triggered by timer expression.

Mapping Gantt Flexible Temporal Task Constraints Behavior into BPMN

Flexible temporal task constraints specify time limits within which the task execution must be performed by assignees. Mapping Gantt Finish No Later Than Constraint into BPMN

This constraint establishes a deadline for the execution of the task. The BPM N mapping is provided by combination of a boundary event attached to the task and outgoing flow to include the possibility to complete the task before FNLT deadline.

Mapping Gantt Start No Later Than Constraint into BPMN

This constraint establishes that execution of the task should start no later than the specified SNLT date regardless of the execution of other tasks. This means that the task, whether linked or not, may not start later than the given date.

However, the Gantt application still has the flexibility to start the task earlier than the given date. The BPMN mapping provides a signal event to coordinate the start of the execution of the task with the completion of its predecessor tasks to maintain default ASAP behavioral constraint using event based gateway.

Mapping Gantt Finish No Earlier Than (FNET) Constraint into BPMN

This constraint specifies that the task mush finish after the specified FNLT date. This means that the task, whether linked or not, may not end before the given date. However, the Gantt coordinator still has the flexibility to end the task later than the given date. It is not possible to control when the task is actually completed by the assignee since the project coordinator has no real influence on the end of the task. The BPMN mapping provides a timer event at the outgoing task flow in order to transfer the flow to the next task after FNET timer is triggered.

Mapping Gantt Start No Earlier Than Constraint into BPMN

This constraint specifies that task should start no earlier than the specified SNET date. This means that the task, whether linked or not, may not start before the given date. However, the Gantt application still has the flexibility to start the task later than the given date. The BPMN mapping uses preceding timer event to transfer execution flow to the task as soon SNET timer is triggered.

Mapping Gantt Temporal Relationships between Tasks into BPMN

Project coordinator uses Gantt timeline to specify temporal relationships between two or more tasks (i.e. Task A and Task B) in order to coordinate their starting and finishing times separately or in combination. There are five basic temporal relationships that can be specified between two tasks: No Relationship, Finish To Start, Start To Start, Finish To Finish, Start To Finish. By mapping these relationships on the Gantt timeline allows for project coordinator to calculate the start date of the dependent Task B based on the estimated start or the completion of the independent Task A. Also, we will use Temporal Lag (Lag) between related tasks for each relationship type to provide explicit BPMN mapping and execution semantics.

Mapping Gantt Finish To Start Task Relationship (FS) into BPMN

The Task B cannot start before its predecessor Task A ends, although it may start later. This is the most common type of relationship and is the default behavior. Lag is calculated as Finish(A)-Start(B)

Mapping Gantt Finish To Start (Lag == 0) into BPMN

Lag between tasks equals 0, BPMN mapping is using simple flow between tasks.

Mapping Gantt Finish To Start (Lag > 0) into BPMN

Mapping Gantt Finish To Start (Lag < 0) into BPMN

Mapping Gantt Start To Start Task Relationship (SS) into BPMN

The task B cannot start until the predecessor Task A starts, although it may start later. This can be useful if you have a task whose start date depends on the start date of another task. Lag is calculated as Start(A)-Start(B)

Mapping Gantt Start To Start (Lag == 0) into BPMN

Mapping Gantt Start To Start (Lag > 0) into BPMN

 Mapping Gantt Start To Start (Lag < 0) into BPMN

Mapping Gantt Finish To Finish Task Relationship (FF) into BPMN

The Task B cannot end before the predecessor Task A ends, although it may end later. Lag is calculated as the difference between Finish(A)-Finish(B)

Mapping Gantt Finish To Finish (Lag == 0) into BPMN



Mapping Gantt Finish To Finish (Lag > 0) into BPMN



Mapping Gantt Finish To Finish (Lag < 0) into BPMN

 Mapping Gantt Start To Finish Task Relationship (SF) into BPMN

The Task B cannot end before the predecessor Task A starts, although it may end later. Lag is calculated as the duration between Start(A)-Finish(B)

Mapping Gantt Start To Finish (Lag == 0) into BPMN

Mapping Gantt Start To Finish (Lag > 0) into BPMN

 

Mapping Gantt Start To Finish (Lag < 0) into BPMN

No Temporal Relationship

In the absence of a relationship between tasks, BPMN mapping provides parallel flow with any temporal execution order between them.

Mapping Gantt Milestones into BPMN

Mapping Gantt Subtasks Into BPMN

Mapping Gantt Tasks Relationship between Subtasks Into BPMN

Mapping Gantt Task Resources into BPMN

Mapping Gantt Task into BPMN CallActivity

Project coordinator defines a task to execute as BPMN CallActivity subprocess. The subprocess behavior is using defa BPM N Call Activity specification to create and run subprocess instance at runtime using associated BPMN Process definition key.

Tracking and Montoring Gantt Project Execution from BPMN Events

BPMN execution automation method enables to track and monitor tasks, subtask and milestone completion using Gantt Project Management.

The BPMN events published by the process engine are captured and correlated to update Gantt Project Model to synchronize the status of project tasks from corresponding BPMN tasks, sub processes and signal events:

• PROCESS STARTED EVENT

• PROCESS COMPLETED EVENT

• SUBPROCESS STARTER EVENT

• SUBPROCESS COMPLETED EVENT

• TASK CREATED EVENT

• TASK ASSIGNED EVENT

• TASK COMPLETED EVENT

• CALL ACTIVITY STARTED EVENT

• CALL ACTIVITY COMPLETED EVENT

• SIGNAL FIRED EVENT

The events from the process engine are captured to update the state of the Gantt project model instance in order to automatically synchronize its timeline with activities inside BPMN process instance. Deployment

With reference to Figure 3, according to one embodiment of aspects of the present invention, the system may be deployed on a discrete device, for example a workstation, a desktop computer, a laptop computer, a tablet or a smartphone.

According to another embodiment of aspects of the present invention, the system may be deployed as an internetwork (hereinafter "network") of computing and communication resources. This network is the foundation of a computing and communication system, for example an enterprise data system. The network connects together a number of nodes, some of which nodes may be categorized for convenience as servers and some of which nodes may be categorized for convenience as clients. Participants in the system, whether human, robotic or cybernetic, for example, participate through appropriate nodes in the network

Those skilled in the art will recognize that the network could be scaled to include multiple servers for each node.

Furthermore, a particular server might be spread across multiple physical locations (or jurisdictions), which might increase, decrease or change over time, including on-the-fly, depending on resource demands and network management decisions. The network could be provided as a managed network service.

Those skilled in the art will understand that in an internetworked system an action is often the result of coordinated activities occu rring at multiple nodes in the system. In the case of a system built on the Internet, these nodes are often distributed ad hoc and unpredictably across multiple jurisdictions. The actions as described and claimed herein are intended to encompass at least: (a) actions performed directly and completely within the jurisdiction of the patent, (b) actions coordinated within the jurisdiction but with at least some activities performed outside the jurisdiction, (c) actions coordinated outside the jurisdiction but with at least some activities performed within the jurisdiction, and (d) actions performed for the benefit of a node within the jurisdiction or a person within the jurisdiction using that node. An example of such coordination would be serving a layout for a web page from one node and serving content for insertion into the layout from one or more other nodes, including through the use of server-side scripting, client-side scripting, and Asynchronous JavaScript and XML (AJAX) techniques.

In general, each of the clients might be a duly configured general purpose programmable computing and communication resource, sometimes called a processing unit or a computing or communication device, for example a workstation, a desktop computer, a laptop computer, a tablet or a smartphone. Alternatively, a client might be a more specific or purpose-built device, for example a wearable device, a media viewer, a home entertainment system, a gaming system, a smart appliance, a point-of-sale device, a payment authorization terminal such as a PIN pad, or a kiosk.

Each server might similarly be a duly configured general purpose programmable computing and communication resource, including a farm of computing devices or one or more virtualized computers embodied as processes operating on a physical general purpose programmable computing and communication device. Such farmed or virtualized computers might themselves be distributed over their own local or wide area network.

In essence, the servers and the clients are roles or functions performed in the system by properly configured computing and communication resources. Multiple roles or functions could be performed by one device and one role or function could be distributed over multiple devices. The specific character and configuration of a device (and more generally the hardware) and the network topology is important to the extent that it supports the performance of the assigned roles or functions. The figure above shows an exemplary architecture for a typical computing and communication device, eitner as a discrete device or as embodying a node. These devices have a bottom hardware layer, a middle operating system layer and a top application program layer. Those skilled in the art will recognize the aspects in which like virtualized hardware and devices depart from like physical ones.

The hardware layer provides the device with computing and communication hardware, including: (a) a processor to execute processes of instructions and to compute data, (b) user-input hardware to receive input from a user, such as a keyboard (real or virtual), a selection device (for example a mouse, touchpad, touchscreen or other haptic sensor), or a microphone, (c) environmental sensors to receive input from the environment, such as a camera, a location sensor (e.g. G PS global positioning satellite receiver or cellular radio), an orientation sensor (e.g. compass, gyroscope), a movement sensor (e.g. GPS, accelerometer), or a scanner (e.g. an optical scanner, a magnetic scanner, a chip-and-PIN scanner, a field scanner (e.g. radio frequency identification - RFID, near field communication - NFC), a chemical scanner, or a biometric scanner), (d) user-output hardware to provide information to a user, such as a video display, a printer or a speaker, (e) mass storage such as electromagnetic, optical or nonvolatile solid-state media to store data and processing instructions, (f) memory such as read only memory and random access memory to store data and processing instructions, and (g) a network interface to support communication with other devices in accordance with known protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long term evolution (LTE), IEEE standard 802.11 (Wi-Fi), IEEE standard 802.3 (Ethernet), and transmission control protocol / internet protocol (TCP/IP), all interconnected by buses such as address and data buses and control lines such as interrupt and clock lines and such other connections and components as is conventionally required and known in the art.

Stored in a portion of the read only memory and the mass storage are the components of the operating system layer, for example LINUX ^® or Microsoft ^® Windows ^® server ^® or Mac ^® OS X server ^® for a device such as general purpose programmable computer configured as a server or LINUX ^® or Microsoft ^® Windows ^® or Mac ^® OS X ^® for a general purpose programmable computer configured as a client or even Microsoft ^® Windows Phone ^® , Apple ^® iOS ^® , Google ^® Android ^® , BlackBerry ^® QNX° or Symbian ^® , for a portable such client device. The operating system layer provides the basic instructions to direct the processor how to interact with the other hardware described above and more generally how to perform the functions of a communication and computing device, including storing, accessing and computing data, and communicating with other devices. The operating system may be configured or extended to provide a web services framework, such as for distributed computing, such as the Windows Communication Foundation application programming interface in the .NET Framework. Those skilled in the art will recognize that some of the functionality described herein can be well-implemented using advanced HTML standards with related caching and client-side logic. Much like HTM L 5 now has standards to adhere to various screen resolutions and other controls, those skilled in the art will appreciate that future versions of HTML may have standardization around device accessibility for cameras, accelerometers, biometric receivers, compasses and other input, output and sensing components, and that future evolutions of HTML may have the ability for browser plug-ins or browser extended session support that provide similar services to current app notifications, even after a browser window might have been closed.

The operating system layer presents an application program interface to the application program layer, so the processor can execute more sophisticated combinations of processes under the direction of higher level application programs stored in mass storage and loaded into random access memory for execution, for example the processes that will be elaborated below. This layer may also include more purpose-specific application programming interfaces.

The structu re of software aspects of the system were described above using an object-oriented paradigm. Those skilled in the art will recognize that there are many programming paradigms and analogous systems can be programmed in accordance with such paradigms without departing from the spirit of the present invention. For example, other programming paradigms include: agent-oriented, automata-based, component-based (including flow-based and pipelined), concatenative, concurrent computing (including relativistic programming), data-driven, declarative including constraint, functional, dataflow (including cell-oriented and reactive) and logic (including abductive logic, answer set, constraint logic, functional logic, inductive logic, and uncertain inference (including markov logic and probabilistic logic))), event-driven (including service-oriented and time-driven), expression-oriented, feature-oriented, function-level, generic, imperative (including procedural), language-oriented (including discipline-specific, domain-specific, grammar-oriented (including dialecting) and intentional), metaprogramming (including automatic, reflective (including attribute-oriented) and template (including policy-based)), non-structured (including array and iterative), nondeterministic, parallel computing (including process-oriented), programming in the large/small, semantic, non-object oriented structured programming paradigms (including modular and recursive) and value-level.

Description Summary

Thus, it will be seen from the foregoing embodiments and examples that there has been described a way to provide computing and communication infrastructure to support a system and method for bi-directional transformation between a project domain, for example as embodied by a Gantt Business Project Plan having temporal constraints, task relationships, subtasks, task duration types, and task resources, and an equivalent project domain, for example as embodied in a Business Process Modeling Notation (BPMN) XM L specification, ready for deployment and execution by any BPM engine with real-time transformation of BPM execution events back to the project domain.

While specific embodiments of the invention have been described and illustrated, such embodiments should be considered illustrative of the invention only and not as limiting the invention. In particular, all quantities described have been determined empirically and those skilled in the art might well expect a wide range of values surrounding those described to provide similarly beneficial results.

It will be understood by those skilled in the art that various changes, modifications and substitutions can be made to the foregoing embodiments without departing from the principle and scope of the invention. For example, systems having more or less types of participants, nodes, artifacts, and classes may still fall within the scope of the invention.

While the invention has been described as having particular application for the embodiments described, those skilled in the art will recognize it has wider application.