git.sourceforge.jp Git - tjqt4port/tj2qt4.git/log

Grégoire Barbier [Sat, 1 Aug 2009 11:52:17 +0000 (13:52 +0200)]

Automatically align underspecified tasks boundaries on project boundaries when possible.

Somme common underspecification cases can be automatically completed,
before scheduling, by aligning the task boundaries on project
boundaries. This is now done.
This enables syntax simplication, and therefore ease of use for new
users, for the following two cases (the third one was actually
already supported).

(i) Project-wide tasks

Some tasks, such as management, last from project start to project
end. They no longer have to specify "start" and "end" with values
that change each time the project boundaries change.
For instance, this syntax is now accepted for a project-wide task:
task mnm "Management & Meetings" {
  # no start date since it can be guessed as aligned on project start
  # no end date since it can be guessed as aligned on project end
  priority 1000 # no other task should steal time on this one
  allocate john {
    limits { weeklymax 0.5d dailymax 1h } # 4h/w but for short weeks
    alternative joe select maxloaded # Joe when John is on vacation
  }
}
This only works for tasks that have no incompatible soft constraints.
That is, no previous tasks if the start date is to be aligned on
project start date, and no followers if the end date is to be aligned
on project end date.

(ii) Half-project-wide tasks

Some tasks, such as support, last from a start point to the project
end (in ASAP scheduling) or from the project start to an end point
(in ALAP scheduling). They no longer have to specify the boundary
that is to be aligned to a project boundary.
For instance, this syntax is now accepted for a task which lasts
until the project end:
task support "Support" {
  # no end date since it can be guessed as aligned on project end
  depends !deployment
  priority 1000 # no other task should steal time on this one
  allocate team { limits { weeklymax 0.5d dailymax 1h } }
}
The same restrition about soft constraints applies as in case (i).

(iii) Tasks that we do not yet know the details

Previously, several cases of unknown content tasks were silently
converted to milestones to avoid errors during early stages of
project specification. This is still the case for tasks that does
not match the two previous cases.
For instance, such a task will be automatically converted to
milestone:
task integration "Integration Phase" {
  depends !development
  # not yet decided, let it be a milestone until further details
}

Nota:
In some cases this patch changes the behaviour of TJ since some tasks
where previously converted to milestone and are now extended to the
project boundaries, this is the case of tasks that only contained
a start specification (therefore in ASAP scheduling) and had no
followers. The new behaviour seems more desirable than the former one
since such tasks should be explicitly marked as milestones if they
are so: implicit conversion to milestone is only there as a
convenience for early project specification, not as a regular syntax.