Table of Contents
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
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:
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:
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:
60.10
Phases are periods of time between milestones. The following attributes must exist for a phase:
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.
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.
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:
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:
260.20 Multiple project report types
Generate the following reports for selected projects in PT:
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.
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.