Alexander Shevlakov, IS consultant, Moscow, Russia.
 
 

Preamble:

To develop a sizeable software application project involving a workgroup of trained staff, one approach is to set up a project management system as a local network resource that could be accessed by all project participants by way of using some kind of special software, either a client GUI front end, which connects to the server backend, or an input/output application with or without database connections, being run on a single computer.

Finding in the Net the GIS-related examples of project management systems is of particular interest, and one can look into the SWAT/GRASS project management system (1); the ITEMS Environmental Data Acquisition and Management system (2). In the former case, there is no external or internal database used for storing data other than in the GRASS format data directories and SWAT format files. In the latter one, there is a DBMS used.

Another example is the Hydrographic Information System for the Swedish and Finnish Maritime Administrations (HIS) (3):
"The client-server setup allows sharing of datasets, workflow control, supervisor distribution of tasks to technicians, centralized data archiving and optimized client data processing. SDE and Oracle on the server store the master database from which clients extract hydrographic data for updates (...), or to which the clients place newly input and validated datasets. Staffware, commercial software for workflow management, handles system workflow control. ArcView on the clients provides tools for hydrographic data editing, viewing, querying, importing and output. (...)"

There are numerous examples of other workflow management systems (WMS), including commercial ones, found in various fields of computer applications (6),(7).

There have probably been few cases of a network oriented system developed with purpose to speed up the multi-level GIS project development and to facilitate the GIS project administration (4). However, to get the best use of the GRASS data architecture (i.e., DB/Location/Mapset/Map), and of  local workgroup collaborative effort, the prototype for such a system has been implemented by the author as a new separate interface integrated within GRASS . The inherent system data is stored in external RDBMS with access to by a plug-in, such as the GRASS odbc driver, though it could also be placed into the internal GRASS SQL compliant database management system, if such was to appear in any future release of the GRASS.

Two distinct modules of the GRASS project workflow management system (G_PWMS) system are  accordingly intended for use by project key figures (project coordinators, class masters, etc.) who determine the project tasks, subtasks, deadlines, and by users (workgroup members, mappers, students) responsible for particular subtasks. These two modules are implemented as the administrative interface module (AI) (fig. 1) and the common interface module (CI) (fig. 2).

Fig. 1 Administrative interface module (AI)

Parameters: Project = A, user = administrator
 

Location 1 Location 2 Location 3 ...... Location N List_locations ------------------------------ Templates A, B,..K ....

Set of administrative functions

a. The administrative interface module (AI)

The purpose of this module is to provide the tool for project coordinators:

define the key values, criteria for the common interface module;

schedule tasks and assign individual subtasks for the users;

edit, view and backup/restore the inherent G_PWMS data;

address the users by email interactively or through automatic notifications (messages subsystem);

run arbitrary SQL commands on the selected database,

and some other.

b. The common interface module (CI)

This module creates a framework of scheduled tasks that have to be fulfilled by all participants of the project to achieve the project's goal.
Currently, it consists of three levels:

project overall assessment level;

project task management;

user's input form;

Fig. 2 Common interface module (CI) (example data)

Parameters: Project = A, user = U1

Start = Level 1 (L1)
Title of the project
Locations list and status
Overall project current rating
 

Location Name	Overall status	Number of tasks done of total	List of workgroup members
Loc 1	u	4 of 9	u1,u2,..,uN
...	...	...

-------------------------------------------
--> Level 2 (L2)
Task manager
 
 

Task 1
Task date of	Indicator of	Task name	Users	Subtask status	Date of the last update & User's  report
completion
primary task or secondary task
deadline date for the task 1	+/-	Description of subtasks	1st user	completed	Last updated: May 12, 2001 Report:......
			2nd user	not completed	.......
			3d user	partially completed	Last updated: May 1, 2001
...	...	...	...	...	...

Task 2, 3
etc.
-----------------------------------

--> Level 3 (L3)
User's subtask input form
-----------------------------------
--> back to L1
 

The L1 of the module has to be accessed first (i.e., by default) by all system users after the user authentication was done. Skipping from this current project status assessment level to the single-location level L2, the user finds the way to what has to be done in the task management table including particular subtasks description, task deadline dates, tasks and  subtasks implementation status. It is also possible to read there other users last reports, on other tasks and subtasks. Next, the user comes into L3 (input form) to write here a concise report and check out the mark corresponding to the subtask implementation. Finally, the user returns to L1 now reflecting the changes in the overall GRASS project rating as well as in the location implementation status changed by the last update. This circular way, of course, leads to simultaneous update of information displayed on each of the levels, the data being retrieved from the database with each invocation of the program.

c. G_PWMS database structure

The relational DBMS is required to handle the system internal queries, because the queries and commands use SQL, and the data is of various types, such as numeric, text, date, timestamp and boolean.

Each projects corresponds to a database (DB). Inside a relational DB, locations are tables. Each location table holds full information about tasks specified for this location. There are also templates for creating and recreating tables, and a single table to hold the summary information for all locations in the project. Deleting, updating or creating records in this "project home" table takes automatic changes (deletes, renames or creates) on location tables, respectively.

Both interface modules, i.e., the AI and the CI, update the project database, however the former one is universal, using a number of built-in functions, such as database backup/restore, email messaging, and others, as well as executing arbitrary SQL queries input by the administrator either from the keyboard or from the file. The update capability of the CI is limited to just processing user's reports input at L3 of the interface.

d. The program implementation

Currently, the system prototype is a number of Perl scripts executed on the Apache server; the system is plugged into PostgreSQL RDBMS by APIs from DBI and DBD-Postgres Perl libraries. However, to obtain the better level of integration, GRASS may be running its own httpd server on one of the specified upper ports, after being launched on GRASS session startup (locally), or on the server startup (once for the local net). In this case, use of the GRASS odbc driver must be preferred so that one was able to plug in to RDBMS other then PostgreSQL.

The tasks at L2 correspond to the same one node of location, while all locations together compose a project. Subtasks at L3 attach to one node of a task. In general, there can be several projects, for example, those of different workgroups. So the tree-like structure of the G_PWMS is formally in accord with GRASS data structure (database/location/mapset/map).

In a network environment, it is often possible to run GRASS on a server in the X-terminal, or to keep the GRASS data only on NFS server, while running the program on a workstation. In all these cases, the proposed system workflow management algorithm is logically bound to the GRASS data storage and access methods. Moreover, as creation of separate layers often depends on existing map layers, which are used as background or startup coverages, and which may be located in other users' mapsets, it becomes important that each project member be able to quickly find the needed map layers. Browsing through multiple task trees allows one to find these coverages, so the G_PWMS is a tool to help find other users data. Although G_PWMS does not scan the GRASS directories directly, later this feature can be incorporated into it without major system reconstruction.

It is worth mentioning here that the currently used algorithm complies with the definition of the workflow in Section Two of the Workflow Management Coalition glossary (1996) (8):
"The automation of the business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules".
The system furthermore complies with the definition of the WMS as "a system that completely defines, manages and executes "workflows" through the execution of the software whose order of execution is driven by a computer representation of the workflow logic" (5).  In this context, the administrative interface module (AI) can be considered as the process definition tool, whilst the data input from it into the database tables of the project is the process definition.

By using this tool, it is possible for the administrator to assign values of criteria for the automatic assessment of the project, such as the target rating to be reached before certain date, or percent of tasks to be completed as a criterion for the overall location status assessment. The project coordinator can thus impose a strategy for the participants, influence on the productivity of the project and evenly dispose of the resources.

Another important issue that concerns the workflow system in general is version control. The implementation of this feature in G_PWMS allows one to to rewind the project history back to certain time points set by the project administrator in the AI. Basically, the whole of the system database can be dumped any time, and then recreated as an archive tagged by a certain date. All users are then free to select the needed archive and work the same way they would do as described above, except for the read-only access to the archive.
 

Looking at the proposed system as a prototype for the GRASS specific workflow management system to be developed, such important issues as full integration, portability, invocation of GRASS modules from inside the system have been left out of the scope of the discussed questions. Nevertheless, the basic features of a task oriented workflow, including process definition tool and version control were shown to apply in the GRASS session environment and data architecture.

1. http://www.brc.tamus.edu/swatgrass/

2. http://www.eimsonline.com/software/items.htm

3. http://www.gis2b.com/2_3.html

4. Integrating GIS and Workflow in the APA (Adirondak Park Agency) Prototype. http://www.ctg.albany.edu/projects/er/intgisw1.html

5. David Hollingsworth. The Workflow Reference Model. 1995. (Document TC-1003). http://www.wfmc.org/standards/docs.htm

6. http://www.cyberteams.com

7. http://poweredby.readworld.com/webpage.html

8. Rob Allen. Workflow: An Introduction. (from The Workflow Handbook 2001, edited by Layna Fischer, 2000.)