Skip to main content

Posts

Showing posts from January, 2008

Traceability through a simple metamodel

When people start defining processes with total traceability between every aspect, the sight is often not very pretty! When traceability adds multiple layers of complexity it rarely pays for itself in terms of improved quality or maintainability.

This is one of the reason why we defined what we termed the "minimum metamodel" in the Better Software Faster book on agile development. The diagram shown here is this model in its simplest form. The questions traceability should answer are:
How is this requirement tested?How is this requirement implemented?How is this part of the design tested?Why is this part of the design needed?It's a useful starting point when defining the artifacts required in a software development process, and the references they should contain to enable these questions to be answered.

The Role of the Process Engineer

Since xProcess provides configurability of processes, it also introduces a new role to projects - that of the Process Engineer. Of course the role may be played by a project manager or process consultant, or simply by one of the members of the project, but it's an important role and one that can greatly enhance the success of projects using xProcess.

Several Process Engineers have already created the processes that come bundled with xProcess (Basic Scrum, Basic FDD, Simple Process) and there are others such WPM Prince 2, Web Development, Issue Management and Basic UP that are available in the community. So the likelihood is that most Process Engineers will start with one of these processes as the baseline. As experience with a process is gained, the details of the way it is being used by the projects can be understood and the sorts of useful modifications or additions to the patterns, actions and workflows can be specified.

Using parameters in task patterns

Processes are defined in xProcess through Patterns - patterns for sets of tasks, for projects, for priority groupings (e.g. Folders) and patterns for artifacts. By constructing sets of patterns, including patterns within patterns (Composite Tasks), a complete definition of the process behind a family of projects can be built up. A key part of pattern definition is the specification the pattern's parameters. This is what this article looks at.
The diagram above shows the editor for a typical pattern from the Simple Process, showing the 4 parameters that this pattern has: Name, Project Home Page, Start Date, Duration. These are the values that the user can supply when creating an instance of the pattern. Parameters always have default values which are used if the user does not change them, but you can add an action to a parameter - a DefaultValueGetter - which will set the default value at run time based on teh context or time at which the pattern is being instantiated. You can see …

Artifact templates

When you're defining the process for your project don't forget that a major part of this is defining the standards for the files, documents and records (artifacts) that are created, modified and qualified as a result of the process. xProcess provides excellent support for defining the types of artifacts that will be used in a process. Furthermore it stores both the document templates and the resulting documents within its version control system so you can not only reliably access the most up to date version, but also compare it with previous versions if necessary. Here's a task pattern showing artifact templates that have been added to each of the subtasks in the pattern.
You can do this simply by right-clicking on the task and adding a "reference" to a new artifact - an attached file, form or hyperlink. (To learn more about the different types of artifacts supported in xProcess see Creating Artifacts in the Help system). Once you've done this, every time you …

Adding gateways to task patterns

An important part of defining the process for your project is defining how to know when a task is complete. Is a development task complete before unit testing for example? Almost certainly not. But if acceptance testing for an enhancement is a separate task in your process, at what stage does the developer hand it over for acceptance testing?

One way to define this in xProcess is to define a gateway for the task so that the user is prompted by a checklist to ensure he has completed the required work.
In the task pattern shown above you can see that a gateway called "Feature complete" has been added to the "Develop" task. To do this in one of your patterns simply switch from the Project Manager perspective to the Process Engineer perspective, you can thenopen the pattern diagram for your pattern (right-click on the pattern). You can then select "Gateway Type" from the palette and drop it on the task in the pattern that you want to have a gateway.

The content …

EV for Agile

Earned Value analysis is really designed for showing how closely you are tracking a pre-defined plan. Schedule efficiency and cost efficiency give separate measures of the degree to which you are "on-time" and on-budget". The problem with agile plans is that the scope of the project is expected to change as it progresses, usually with the aim of keeping schedule and cost more or less constant. Is EV analysis simply not applicable in this case? Actually in the context of a forecasting environment like xProcess, EV can still provide some most valuable metrics to agile plans. I've been invited to present a paper on EV for agile projects in a few months time and so I'd be most interested to hear of others applying EV with plans that must vary over time. Drop me a line if that's you!

If you're interested in receiving a copy of the paper btw click here.