mod/techproject/view/screens/tasks

Index

Tasks

Tasks are descriptions of how to realize a set of specifications or obtain part of the deliverables.

Task management phase is an active period for the developement of the project, although previous phases could event be described in terms of tasks (write a specification may be also an operational activity).

Tasks, as requirements and specification, can be organized as a hierarchic tree. Root level tasks can be quite general, and may describe overall operative "strategies". i.e. : for producing such a software component, you may settle a root level of tasks as :

• Write utilities libraries
• Write the tests for utility libraries
• Test and qualify utility libraries
• Write storage persistance level (database acces)
• Write tests for storage level
• Test database access and qualify persistance libraries
• Write code for functional objects
• Write test units
• Unit testing
• Cleanup and review the code for harmonization
• Review in code comments
• Pack the component
• Produce deployement documentation
• Extract generated documentation

Each of (or some of) them could be refined in more elemental actions, as resulting of a questionning : "What should I do for making that ?" a developper would proceed to.

With tasks, refinement has two main goals :

• Describe action fine enough for a development crew to proceed.
• Have a detailed enough action plan to perfom time/charge estimation (cost foreseeing).

Viewing tasks

Tasks are viewed as a content-collapsed heading tree. Any sublevel can be collapsed if needed.

Each heading provides synthesis information, obtained by propagating indicators from the sub-tree hierarchy, or from associated specifications or deliverables:

• Numbering (autonumbering)
• Caption
• The number of binded specification (direct binding/through sub-tasks)
• The number of associated deliverables (direct binding/through sub-tasks)
• The completion level for that task, as a graphical bar-graph

Completion level is either entered (user edited) or calculated. Leaf tasks (we call them also effective tasks) will require completion to be entered by user. Tree nodes will accumulate completion from sub-nodes. Thus nodes should be only used as a "task grouping" principle.

Each heading can be expanded so a complete qualifier report and a content abstract can be viewed.

Editing tasks

Editing the task tree may not be available for students. The teacher may choose to lock this entity.

A task is a set of information describing an action the project team should perform. In its simplest form, a single task is made of a caption and a free description of what to do. As other entities, description will be an editable HTML document that could be understructured as needed.

A task may be qualified using :

• A work type : Each task designates some kind of job, that may need some special skills and will ask for some techniques to be used.
• Cost rate : All work types and associate skills may not have the same economical value. In a teaching context, this field would not be absolutely necessary. We added it in the eventuality this module would be used for real project (what it was intended for initially), but also to help student understand the cost calculation process for a complex project. This cost may be entered in arbitrary units and scales.
• Planned cost : The planned cost will be entered as a "evaluated time to perform the task". A planned cost would be easily obtained multiplying cost rate with planned cost.
• Completion rate : Completion rate should be entered from 0 to 100, and will qualify the part of the job wich has been realized (subjectively, most often).
• Cost (realized) : The realized cost will be entered as "an effective time we spent on the job". All the project control methodologies (IEEE, CMM, etc.) agree on utility of retrocalculation of costs on passed projects, to increase reliability of estimating models.

The task screens allows editing and managing tasks as resulting of a continuous refinement process. Each task could be detailed by subtasks that will describe more elemental actions to be performed.

Pedagogical strategy

Tasks are used to describe what the project team should exactly accomplish, how should the worktime spent to. These descriptions could be :

• first roughly setup by the teacher, but alterable by students so that they may reach a sufficient autonomy in "time scheduling and control".
• setup and locked by the teacher. They will represent an imperative process to be followed, when the action plan must cope a well-known or standard procedure.
• fully editable by students, from a blank editor : students may then have to construct their own action strategy.