Home : Project Tracker Documentation : 3. For Developers : 3.6. Project Tracker Future Possibilities 

3.6. Project Tracker Future Possibilities

Table of Contents

3.6.1. Subtask Rules
3.6.2. Dependencies
3.6.3. Milestones
3.6.4. Phases
3.6.5. Scheduling
3.6.6. Gantt Chart
3.6.7. Aggregate Reports
3.6.8. Suggested features
3.6.9. Revision History

By Nobuko Asakai

3.6.1. Subtask Rules

  • Status A parent task is complete only when all subtasks are complete. Conversely, when all subtasks are complete, the parent task must be automatically marked complete.

  • Schedule The start and end times of the parent task must encompass the estimated/scheduled duration of it's subtasks parent start time = min(children start time) parent end time = max(children end time)

  • Estimate The estimate time of a parent task must be the greatest estimate of its child tasks.

  • Dependency If a parent task A is dependent on task B all of A's subtasks must inherit the dependency

3.6.2. Dependencies

40.10 Rules

The time constraint type is as soon as possible (When task A depends on B, A cannot be scheduled to start until B is done), and must follow these rules:

  • Circular dependencies are not allowed

  • A parent cannot depend on its descendents

  • A child cannot depend on its ancestors

40.20 Multiple dependencies

A task may depend on more then one task.

40.30 Dependency types

The default for how a task depends on another task is start to finish (A can't start until B is finished) and it is the only dependency type for this version. The following other dependency types may be added in the future:

  • FS (finish to start) A can't start until B is done

  • SS (start to start) A can's start until B starts

  • FF (finish to finish) A can't finish until B finishes

  • SF (start to finish) B cannot finish until A starts

3.6.3. Milestones

50.10

A milestone is a an event that is used to monitor the progress of a project. The following attributes must exist for each milestone:

  • Name

  • Description

  • Expected date

3.6.4. Phases

60.10

Phases are periods of time between milestones. The following attributes must exist for a phase:

  • Name

  • Scheduled end and start times (depends on milestones)

  • Actual end and start times (depends on milestones)

3.6.5. Scheduling

Based on start time, time estimate and dependency of tasks, PT must calculate the end time for a task.

70.10 Baseline schedule

The baseline schedule must be based strictly on estimates.

70.20 Current schedule

The current schedule must incorporate actual time information as tasks are completed.

70.25 Auditing

The ability to take "snap shots" of project plans at a given time may be included in the future. To make this possible all schedule related attributes must be audited.

70.30 User defined start time (MSO)

User must be able to define a start time for any task. End time will be calculated based on the start time and estimate. This is effectively a MSO (must start on) constraint.

70.40 Start time rules

Start times must have constraints so that it makes sense logically, and PT must enforce them.

70.410 Default start time (ASAP)

The default for the start time is the start time of the project, unless the task has dependencies. This is effectively an ASAP constraint.

70.420 Default start time for tasks with dependencies (ASAP)

If A depends on B, then A's default start time is immediately after B's scheduled end time. A.start time = (B.start time + B.estimate) This is effectively an ASAP constraint.

70.430 Constraint for tasks with deadlines (SNLT)

If a task has a deadline, user cannot define the start time to be after the latest possible start time given the time estimate. start time <= (deadline - estimate) This is effectively a SNLT (start no later) then constraint.

70.440 Constraint for tasks with dependencies (SNLT)

If A depends on B, user must be able to define a start time for dependent tasks as long as they are before B's scheduled end time. A.start time <= (B.start time + B.estimate) This is effectively a SNLT (start no later then) constraint.

70.450 Constraint for dependent tasks with deadline (SNLT)

If A depends on B, and B has a deadline, A's start time must follow the SNLT constraint. A.start time <= ( B.deadline - B.estimate - A.estimate )

70.460 Assignment and start time (Over booking)

There are no constraints against over booking a task. This may be added in the future.

70.470 Start time: automation

The scheduling process will not be automated.

70.480 Constraint types: summary

  • Setting a start time for a task with no dependency or constraint is MSO.

  • Setting a deadline means placing a FNLT (finish no later then constraint), which logically places a SNLT constraint on the start time.

  • Setting a deadline to a task with start time is subject to the FNET (finish no earlier then) constraint.

  • Setting a start time for a task that depends on another task is subject to the SNET (start no earlier then) constraint.

  • Setting a deadline to tasks with dependencies is subject to the FNET (finish no earlier then) constraint.

  • Setting a start time to tasks with dependencies and deadline is subject to the SNLT (start no earlier then) constraint.

70.50 Other possible constraint types

There are other possible constraint types which will not be implemented for this version, though it may be implemented in the future.

  • ALAP (as late as possible) Given a deadline the start time is exactly end time - estimate

  • MFO (must finish on) Task must finish on a given time. This can be a type of a deadline, however, in the current scheme, a deadline only requires that a task is complete

70.60 Current schedule rules

If the actual time does not match the baseline schedule, then the current schedule must be modified to reflect the difference. For now, only tasks with dependencies are subject to this adjustment. If A depends on B, then the adjustment must follow these rules. The rules apply only if the constraint is ASAP or if the delay violates the above constraints on start time.

  • If B is behind schedule, then A's start time must be delayed (only applies if B's end time = A's start time)

  • If B is ahead of schedule then A's start time gets pushed forward (Only on ASAP)

3.6.6. Gantt Chart

The schedule of tasks must be represented graphically in a Gantt chart, the display must follow these rules:

  • The chart must be gridded to represent time (horizontal axis is time)

  • Each task is a row in the chart, represented by a solid bar that spans across the time grid (vertical axis is task)

  • A milestone is a diamond

  • A phase is a solid bar with diamond endings

  • A parent task must be graphically distinct from subtasks

  • Dependencies must be represented by lines or arrows that join tasks

230.15 Gantt Chart (Optional)

These features may be implemented for the Gantt chart in the future:

  • Graphically indicate who the task is assigned to

  • Indicate what the task is

  • Manipulate task attributes via the chart

3.6.7. Aggregate Reports

250.10 Single project reports

User must be able to view reports on the project.

250.20 Daily activity report

Daily activity report that shows what people are doing on a given day, compared to which tasks are supposed to be in progress.

250.30 Status reports

Status report must indicate what tasks were supposed to be done by a given day, and which ones were done, and which ones weren't

250.40 Time estimate report

This report must give a score the accuracy of time for the tasks in the project. This should be the mean and median for the number of days the task is off by.

260.10 Multiple project reports

User must be able to designate which set of projects to report on based on the following criteria:

  • By owners of the project

  • By group the owners of the project belong to

  • Custom selection of a set of projects

260.20 Multiple project report types

Generate the following reports for selected projects in PT:

  • How many projects actually finished on schedule. A tracking of the time estimate scores for each project to represent the firm's performance as a whole.

  • How projects are progressing

3.6.8. Suggested features

3.6.8.1. Phases and helping resources

Allow phases to be associated with groups of tasks or with the schedule. Each phase could have "Helping Resources" associated with it, and something like "Required Deliverables," such as documentation. These facilities help us maintain a nominal methodology for all projects.

3.6.8.2. Software usage report/tracking

Keeping track of who's using what software (package, version, ACS version) a la module tracker so that the core team can inform projects when major bugs arise.

3.6.8.3. Estimation helper

Help with estimation by looking at similar tasks from other projects.

3.6.8.4. Skill Set

Suggest a set of skills to build into the team based on other projects.

3.6.8.5. Palm Pilot

Down loading the plan into palm pilot to-do list.

3.6.8.6. Optimistic and pessimistic schedules

Allow users to enter optimistic and pessimistic schedules.

3.6.9. Revision History

Document Revision #Action Taken, NotesWhen?By Whom?
0.2Edited and converted to DocBook DTD3/13/2001Nobuko Asakai
0.1Creation2/12/2001Nobuko Asakai

($ID$)