| 429 | | * If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration. Done scheduling this task. |
| 430 | | * If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration. Done scheduling this task. |
| | 434 | * If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration. |
| | 435 | * If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration. |
| | 436 | |
| | 437 | NOTE: Once a task is begun, its assignedStart is set from the computedStart so recomputing a schedule doesn't change its start. We may have to deal with split tasks, however, if a task is begun then put down and resumed later. |
| 445 | | === Random algorithm notes === |
| 446 | | |
| 447 | | * As Late As Possible (ALAP) with only FS dependency is an easy scheduling algorithm. A task without successors is due on it's milestone date and things back up from there. However, it is sometimes helpful to use ASAP, even for single tasks. For example, if a software development task is poorly understood so its estimate might be wildly wrong, that task should be tackled early in the project so that deviation from estimate is known early and there is more time to adjust for it. Also, it's often desirable to handle bugs before new features so tasks might get ALAP and bugs ASAP within the same project. |
| 448 | | |
| 449 | | * There are three constraints that influence a task's scheduling: |
| 450 | | * The date of the task's milestone |
| 451 | | * Dependency on other tasks |
| 452 | | * Resource sharing (contention) |
| 453 | | |
| 454 | | * For ALAP with FS and 100% resource application (effort) |
| 455 | | * Task A's finish date is the milestone date if it has no successors |
| 456 | | * Task A's finish date is Task B's start date if B has an FS dependency on A (A -> B) |
| 457 | | * Resolve resource conflict: |
| 458 | | * Task A should be before B if A has successors and B does not |
| 459 | | * Task A should be before B if A is higher priority |
| 460 | | * Task A should be before B if A has more risk |
| 461 | | |
| 462 | | * With the above rules for putting A before B, does scheduling become a sorting operation that just needs a comparison function which implements those rules? Intuitively, an O(n^2^) sort like bubble sort would work but something like a merge sort might not because tasks in the partitions might depend on one another. Perhaps partitioning can be done to eliminate dependencies. |
| 463 | | |
| 464 | | * It might be helpful or interesting to consider saving schedules or scenarios. If we stored resource assignment, start and finish data in a table keyed by schedule and ticket, we could store multiple possible schedules and choose to display different ones. An initial release could have only a single schedule and no facility for creating alternatives. A later refinement could add scenario support. If a start or finish date was configured for a task, the schedule would copy that data and not allow editing or recomputation of those dates; other tasks would flow around that fixed time. If a task lacked a start or finish date, the scheduling of that task would be fluid and computed by the scheduler. |
| 465 | | |
| 466 | | '''...more here...''' |
| | 453 | == Schedule Scenarios == |
| | 454 | |
| | 455 | It might be helpful or interesting to consider saving schedules or scenarios. If we stored resource assignment, start and finish data in a table keyed by schedule and ticket, we could store multiple possible schedules and choose to display different ones. An initial release could have only a single schedule and no facility for creating alternatives. A later refinement could add scenario support. If a start or finish date was configured for a task, the schedule would copy that data and not allow editing or recomputation of those dates; other tasks would flow around that fixed time. If a task lacked a start or finish date, the scheduling of that task would be fluid and computed by the scheduler. |
