COTS package. Although potential commercial solutions did exist, they would have required such extensive customisation that it really made more sense to develop a system from scratch. The application, which is now nearing completion, has been internally named “DEV Folio” since it encompasses a portfolio of multiple projects. Codeworks DEV holds the I.P. of the application and we hope to open-source it at a future point.
We evolved an XML schema for defining workflows. Each step in a workflow may consist of sub-workflows, or (if a leaf node) will contain various data entry fields. Requirements capture, timeboxing, MoSCoWing, and document-generation features were architected as plug-ins to the basic workflow tool.
DEV Folio: a first look
Logging in to the application shows which projects in the program the user is currently participating in (see Figure 2). Note that we have applied MoSCoWing at even this high level. Candidate projects are inducted in batches over the course of the DEV Programme. We cannot handle all at once; we must have a means of prioritising them by importance and by their own inherent timescales. Each project on the DEV Programme is therefore given a MoSCoW rating. The “Musts” are those projects that we identify as making definitive contributions to the success of the programme and for which deferral to a later batch cannot be risked.
Clicking on the workflow of any particular project shows the high level process model defined for that project. Although the technical details are beyond the scope of this document, the Agile-PRINCE2 flows are customisable for each project if necessary.
Clicking on a project workflow shows the top level flow for that project (see Figure 4). This flow maps to the DSDM Phases of Feasibility, Foundations, Exploration, and Engineering as described earlier and summarised in Figure 3.
DSDM Phases are thereby represented by process boxes in a workflow. A key feature of DEV’s Agile approach is that these workflows can be nested. This allows configurability of each phase, since all workflows are defined as XML. The precise workflow that should be followed in each phase can therefore be adjusted to be project-specific.
Figure 5 shows a standard sub-workflow for the Feasibility (Discovery) Phase of a DEV Project. As each step is completed, it is annotated with a check. Decision points enable progress to appropriate branches. For decision points that have not yet been reached, the ensuing branches are greyed out.
Figures 5 and 6
Figure 6 shows the content of a leaf process. In this case “Invention Summary” does not contain any sub workflows. At this finest level of granularity, data must be entered.
A detailed description of each sub workflow, and the leaf nodes for data entry, is beyond the scope of this discussion. However it is worth examining the flow of the Engineering (Delivery) Phase in some detail. During Engineering, project velocity is maintained via a brisk and focused dialogue between stakeholders. The tools which are brought to bear are those of requirements elicitation, timeboxing, and the MoSCoWing of requirements. All of these are critical components of our approach.
In the default process configuration used for DEV projects, we include a precursory stage for preparation of the solution development team infrastructure. This is followed by a Delivery stage which is defined in terms of requirements capture, timeboxing, and MoSCoW dialogues. Then there is a project closing stage (see Figure 7).
Typically requirements entry, timeboxing, and MoSCoWing for a particular project are all done as part of a “Deliver” stage within Engineering. Clicking on the appropriate link will bring