Process

UML Model

The diagrams on this page were made with Poseidon for generating the code with ArchGenXML.  We do not do that anymore.  So the diagrams can be slightly outdated; for example, the Projectmanager role did not exist yet when we made these.  The diagrams should still give you a good idea of what is happening.

Project workflow

Projects start out in the private state. A Projectmanager (or Owner, but that's usually the same person) can activate a project. Once the project is active, the customer can be involved. When all is said and done the Projectmanager/Owner can also close the project.  Those two transitions are shown in blue, the color we use in all diagrams to indicate that this is the normal route. If you made a transition and later realize you made a mistake, you can go back to the previous state. This is true for most of the transitions in the other workflows as well.

Iteration workflow

After adding an iteration, you can start adding stories to the iteration and tasks to the stories. At a certain moment you ought to have an iteration start meeting with the customer, finalising the set of stories. Afterwards, you can set the workflow to in progress, which activates the stories and the tasks. The bright yellow note that grabs your attention indicates a transition that is triggered by another transition.  In this case: if all stories belonging to this iteration have been completed, the iteration itself is set to completed. After this, the Manager can invoice the iteration, which indicates that a bill has been sent to the customer.

A completed Iteration can also be put in new state own-account (not shown) when the customer is not going to pay for it (for example when it is an internal project not belonging to any customer).

Offer workflow

Offers.

Story workflow

The customer adds a story, describes it and finally submits it for estimation (it now has the pending state). The projectmanager or employee then provides a rough estimate (in days). Then the story can be set to the estimated state. The employees can now add tasks.

Or: an employee adds a story himself, gives it a rough estimate and immediately puts it in the estimated state.

The estimated story is activated automatically when the iteration is activated. This activation also triggers the activation of the tasks. The iteration should only be activated when all stories have tasks and all tasks are estimated (an estimate greater than 0) and have at least one assignee. The workflow protects employees (not project managers) from activating when there are unestimated tasks.

If all tasks have been completed, the story is automatically also completed. If all stories have been completed, the iteration is automatically also completed.

Task workflow

Tasks are added by employees. Like mentioned before, when all tasks are estimated, their parent story becomes startable. When all stories are startable, the iteration can be started. So when you view an iteration and you are allowed to start it, this means that all its stories and all their tasks are also startable. When you then actually click on 'start' then indeed this iteration and all its stories and tasks are activated.

If all tasks in a story are completed, the story is automatically marked as completed.

The special PoiTasks have the same workflow.

Booking workflow

Bookings have a one-state workflow. We are not trying to hide anything, so customers are allowed to view individual bookings.