Home : Project Tracker Documentation : 3. For Developers : 3.5. Project Tracker Design Document 

3.5. Project Tracker Design Document

Table of Contents

3.5.1. Essentials
3.5.2. Introduction
3.5.3. Historical Considerations
3.5.4. Competitive Analysis
3.5.5. Design Tradeoffs
3.5.6. API
3.5.7. Data Model Discussion
3.5.8. User Interface
3.5.9. Configuration/Parameters
3.5.10. Future Improvements/Areas of Likely Change
3.5.11. Authors
3.5.12. Revision History

By Nobuko Asakai

3.5.1. Essentials

3.5.2. Introduction

Project Tracker is an ACS 4.0 application designed to assist in project planning and tracking. Powered by ACS-Workflow, Project Tracker tracks the status of tasks.

Project Tracker is suited for project teams that needs to communicate frequently about who has done what. The tracking features allows users to record, and thereby communicate the status of their tasks. Project Tracker's flexible definition of tasks and subtasks allows users to define the project at a level of granularity that makes sense to them.

3.5.3. Historical Considerations

The direct ancestor of Project Tracker is Dev-Tracker, which was developed on ACS 3.x platform and was used internally at ArsDigita to manage projects. The design and requirements of Project Tracker comes from the enhancement requests for Dev-Tracker, and Reviews of Existing Systems.

Project Tracker is also an attempt to generalize concepts in Dev-Tracker. The semantics of Dev-Tracker focused on software development with words such as "features", "releases", and "feature areas". Project Tracker replaces these grouping terms with a generalized notion of tasks and subtasks. The metaphor gives the user more room to create plans that suites their particular needs.

Ticket Tracker is another application that served a task tracking function in ACS 3x. In theory, broad general ideas were entered in Dev-Tracker and individual tasks were entered in Ticket Tracker. This was confusing and inconvenient for everyone. The high-level "features" entered in Dev-Tracker were too "high level" to be tracked accurately and the individual tasks in Ticket Tracker were unaware of the larger context in Dev-Tracker. Project Tracker's hierarchy of tasks is designed to address the need for different levels of granularity in a project. Also, with ACS-Workflow users can have "my task list" that shows all the tasks assigned to that person from disparate "trackers".

Project Tracker does not implement all the features in Dev-Tracker. Because each instance of the application corresponds to one "project", the ability to browse through projects is lost. However administrators now have the power to manage access privileges for each project. Generating aggregate reports across projects one of the features considered for future implementation.

3.5.4. Competitive Analysis

There are numerous project management tools in the market some of which were reviewed to gather requirements for Project Tracker (Reviews of Existing Systems).

Project Tracker's advantage lies in its integration with the ACS and its applications: ACS-Kernel handles permissions and access control, ACS-Workflow assigns and manages the life cycle of a task, and General Comments provides comments and file attachments. The help of these applications and services allows Project Tracker to be both lightweight and robust.

Another advantage of Project Tracker and the ACS is the variety of tools the user can choose from. A project management tool such as Web Project's Project Portal may provide the user with a bulletin board, planner, file storage and etc. These packaged solutions will not allow the user to choose what they need, but with the ACS a project team can mix and match whatever tools they want. A project team can start with Project Tracker, then add on a bulletin board or a file-storage, and later, use the SDM to track bugs.

Although Project Tracker's collaborative capacities will assist in bringing people, partners, and processes together it is not intended as a scheduling tool. MS Project would be better suited for complex time sensitive projects with multiple task dependencies.

3.5.5. Design Tradeoffs

3.5.5.1. Dependencies

The original plan for Project Tracker included task dependencies and Gantt charting capabilities. However these features were abandoned because the DML required to support dynamic modification of task schedules were deemed to be too complex given the current platform (ACS 4 Tcl). The details on these features can be found in Project Tracker Future Possibilities.

3.5.5.2. ACS Workflow

What Project Tracker needs from Workflow

  • I. Parent to child, child to parent Tasks move from being a leaf task to a parent task as project plans are developed. For this reason, it must be possible for tasks to move from the parent path to the leaf path and vice versa at all times.

  • II. Planning and execution Project planning and execution could happen at different times, therefore the timing of the email notification must be controled by the user.

  • III. Dynamic Assignments The user must have full control over the task assignments. It also most possible to alter assignments throughout the life time of the task.

  • IV. Aggregating subtasks (not implemented) Parent tasks are also aggregates of its children. That is, parent tasks should only be closed when all of its children are complete, and when a parent task is closed all of its children should be completed.

Simple Workflow

The current implementation of Project Tracker uses an extremely simple workflow for its tasks where tasks only has incomplete and complete states.

Project Tracker task workflow

This workflow was chosen for it's simplicity in implementation and flexibility.

  • I. To allow fluidity between parent and leaf tasks, it deletes workflow cases for parent tasks and only allow leaf tasks to have cases. This approach is problematic because it involves irreversibly deleting data that the user may have entered. Canceling cases for parent tasks instead of deleting is not an option because user is able to reactivate the case via the workflow UI which would break the logic in Project Tracker.

  • II. The lag between planning and execution means that we cannot start the workflow case at the time of creation. We need a separate step that starts the workflow. This action is enabled only when the task has been assigned.

  • III. Dynamic assignments means that we must take measures to ensure that the assignment in PT and Workflow are consistent. We achieve this by storing task assignments only in the ACS-Workflow tables and using PL/SQL procedure pt_task.assign to manage the DML.

  • IV. Implementing aggretion in parent tasks would be relativly complex as we would have to create a separate states column in Project Tracker if we want parent tasks to be complete when all subtasks are complete. Similar features such as assigning all subtasks when a parent task is assigned also require additional columns or tables that duplicates information stored in workflow.

Pros

  • Task types Having a simple workflow means that we reserve room for having different workflows or different types of tasks.

  • Complexity The implementation is simple.

Cons

  • AssignmentsBecause assignments are stored in the workflow_case_assignments table, parent tasks cannot have assignments or states. This makes implementing IV difficult.

  • States and dropping tasks Because parent tasks do not have workflow cases, they do not have states. To support dropping and deleting of tasks that are not leaf tasks it has added an extra column dropped_p to the pt_tasks table. This is confusing as it forces the distinction between "dropping" a task and "cancelling" to the user.

  • Comments Users have the workflow journal and general comments to create comments on their tasks. It is confusing to have two, and also unpleasant that the workflow journal gets deleted when a leaf task changes to a parent task.

Complex workflow

The alternative is to express the difference between parent and leaf tasks with different paths in the petri-net for parent tasks and leaf tasks.

Using a complex workflow that supports both parent and child task would be conceptually cleaner. The state of the task including parent and leaf status would be represented in Workflow. The hierarchical structure of the tasks would be stored in Project Tracker and the semantic difference between parent tasks and leaf tasks would be handled by ACS-Workflow.

  • I. There must be bridges built in the petri-net to allow fluidity between parent and leaf tasks, which will increase the complexity of the model.

  • II and III. We would have to start the workflow case when the task is created because it is possible that parent tasks never get assigned. We would have to add an extra loop to allow the user to control the timing of notification.

  • IV. Aggregating calculations could be done as a callback in workflow

Pros

  • Data loss Data never gets deleted as a consequence of adding or moving tasks. We would still have General Comments and workflow journal because we would want to preserve the file attachment capacity.

  • States The Project Tracker tables would not have to store any state information. Droping, and reactivating can simply "cancel" the cases.

Cons

  • Task types It would be nontrivial to provide different types of workflow. For example, if we wanted to include extra steps such as client approval and clarification in our workflow, each new transition would require that we build a bridging arc and transition to allow tasks to move freely from parent to leaf and vice versa.

  • Complexity - PT/workflow communication The implementation would be complex since most of the transitions would be enabled by messages sent from Project Tracker to Workflow.

  • Complexity - parent/leaf We would have to build bridging transitions between each leaf transition and parent transition.

Workflow was not designed to support cases where the lifecycle of a task was defined incrementally as it is in Project Tracker. This makes the division of labor between Project Tracker and ACS-Workflow tenuous and it is difficult to determine which approach is superior. Conceptually, the complex workflow is clearer and does the "right thing". However this correctness comes at the high price of complexity and limited extensibility. The simple workflow was chosen for the initial version because it allows us to develop rapidly and obtain valuable user feedback.

3.5.5.3. Hierarchy

Task hierarchy is modeled by using the Oracle connect by feature.

3.5.5.4. Application instance

Each instance of Project Tracker corresponds to one project. Thus the Project Tracker achieves modularity at the project level allowing users to mount and set permissions and parameters for each project. One drawback is that multi project reporting is not implemented, however it would not be difficult to create a companion package that summarizes Project Tracker information.

3.5.5.5. Minimal number of tables

By unifying the concept of projects, releases, and areas into tasks, Project Tracker only has one main table, pt_tasks. However tables still need to be joined with ACS-Workflow and General Comments tables to retrieve full project information.

3.5.5.6. Testability

As with most ACS 4.x applications Project Tracker DML interactions are encapsulated in PL/SQL APIs. These APIs are easily tested using utPL/SQL. Furthermore, by minimizing duplicate TCL code, the testability of the web interface is enhanced.

3.5.6. API

There are no public APIs.

3.5.7. Data Model Discussion

3.5.7.1. Database schema

The data model is simple: Project Tracker only has two tables

  • pt_tasks

    • Contains information about tasks, including parent id, name, description, deadline, estimate, and actual time

    • Deadline, estimate, and actual time are null for parent tasks

  • pt_projects

    • Uses acs_rels to map package instance and the root task

    • Extensible to contain specific information about a project, though none are defined at the moment

3.5.7.2. External Subsytems

  • Subsites Project Tracker is subsite aware and depends on subsites to set permissions

  • ACS-Workflow Drives Project Tracker tasks from one state to another

  • General Comments Allows users to create persistent comments on a task

3.5.7.3. PL/SQL Packages

  • pt_task package handles the communication between Project Tracker and ACS-Workflow, and performs the appropriate DML to transition between parent and leaf tasks. Inserts into the pt_tasks table should only happen via the API.

  • pt_project package handles the mapping between package instance and the root task. It also provides additional API to extract information about the task list as a whole.

  • pt_util package provides utility procedures for finding the url that ACS-Workflow and Project Tracker are mounted on, and for retrieving Project Tracker parameters.

  • pt_callback package implements callbacks to be executed as workflow transitions are enabled.

3.5.8. User Interface

The interface of Project Tracker is designed to let the user conduct the maximum amount of actions with a minimum number of pages. Thus all the data manipulation options are available in the index page: where users can add, edit, move, and assign tasks. The templating system is used to generate the task list instead of ad_table. The templating system allows more fine grained control over the display, especially when multiple rows need to be grouped together. In addition the form widgets are an effective way to dynamically generate html form pieces.

3.5.9. Configuration/Parameters

Project Tracker only has one parameter, which is the notification sender.

3.5.10. Future Improvements/Areas of Likely Change

What happens to Project Tracker next depends greatly on the demand from the users. Some possibilities are listed below:

  • The workflow definition will probably change to achieve a cleaner division of labor between Project Tracker and Workflow.

  • Admin UI for granting permissions to team members and clients.

  • Additional UI in Project Tracker that encompasses all actions possible in the ACS-Workflow UI. This would include the ability to modify task states in Project Tracker.

3.5.11. Authors

3.5.12. Revision History

Document Revision #Action Taken, NotesWhen?By Whom?
0.2Added discussion of workflow alternatives3/13/2001Nobuko Asakai
0.1Creation3/08/2001Nobuko Asakai

($DateTime$)