Introduction

The Dimmick Consultancy Method is based upon an open source methodology known as FLiP[1].  This method originated in an online community using an open source software architecture called Fusebox[2].  Fusebox is often referred to incorrectly as a method because maintaining compliance with the Fusebox standard does require the methodical adherence to a set of rules.  Dimmick Consultancy strictly adheres to both the FLiP methodology and the Fusebox architecture as practice fundamentals.  This document explains FLiP as implemented by Dimmick Consultancy.  Further information on both FLiP and Fusebox can be found at www.fusebox.org.  Dimmick Consultancy acknowledges all of the people responsible for the development and promotion of these standards as having made a critically important contribution to software development for the Web in reducing risks, improving estimation capabilities, reducing development costs and time cycles and ensuring software longevity.  We are deeply grateful in being able to extend these benefits to our clients.

The Software Development Cycle

Please refer to the diagram.  Engineers and anyone having read engineering texts on software development will recognise aspects of classical structure to our methodology.  It essentially combines an iterative prototyping development model with a linear sequential model, attributed by Pressman[3] to Boehm and known as a 'Spiral Model'.  While we haven't illustrated our method as a spiral, it closely conforms to that idea, with a special focus upon the peculiarities of software development for the Web.  The following text all refers to this diagram.

1. The Design Cycle

Step 1.1 Requirements

This means requirements gathering and needs analysis.  The process at this point involves a series of meetings with domain experts at the client organisation.  This is the step in which we capture as much as we possibly can about the intent, objectives and outcomes of the project as well as getting an understanding of the broader organisational aspirations.  Think of this step as the beginning of a conversation.  Because our conversation intensely focuses upon an organisation's aspirations and involves individuals who may never have had the opportunity to fully express and discuss their respective needs around their work, the outcomes from this process can be as illuminating to the client as they are to us.

A Brief Digression: Language

Before explaining the next section, I make a point about language.  The requirements gathering stage results in a large number of sketches on paper, written notes, audio recordings, possibly video recordings and photographs, screen captures, etc.  While we have our own process for ordering this material and making it useful for our purposes, how do we share these outcomes with our client?  We are faced here with several facts about workplace.  People have a wide range of abilities and inclinations around written and spoken human language and vary also in their appreciation and abilities in the visual field.  People also have limited time to acquire and understand descriptions of things that exceed their already full work life.  These considerations introduce the almost obvious, but often overlooked fact that domain experts representing our client cannot possibly be expected to acquire and hold a uniform understanding of something not yet created from descriptive material 'about' that something.  This would be the case even if the material is elegantly prepared and presented.  Addressing this issue introduces the next step, Visual Prototype.

Top of Page

Step 1.2 Visual Prototype

The visual prototype is essentially a 'working picture' of the finished application as it is envisaged at this stage of the process.  It is normally built in HTML but could equally be built in Flash.  Many developers use visual prototypes to varying degrees and in varying ways.  Our employment of this technique is specific to a very specific end.  The visual prototype must completely describe not only the look and feel, but also the actual functionality, of the finished application.  Any user destined to use the finished system should be able to navigate and understand the finished system from this point.  Clearly, because there is no application at this stage, there is some license in striving for this goal.  Actions that will occur upon the submission of a form, etc are simulated with javascript or simple server side script to illustrate the functionality.  Experience shows that this works.  The visual prototype is the place where all of the minds involved in this process can meet with an accountable and shared understanding of what is intended.  The client is at this point intimately involved in the design process.  Note that we show a loop on the diagram that cycles the phototyping and requirements processes.  This cycle is repeated for as long as required to expose needs and intentions and illustrate them fully in the prototype.  Changes and the testing of ideas in this step are comparatively cheap and actively encouraged.  Every iteration here adds value to the outcome, reduces risks in the Production Cycle, and generally raises the guarantees on an optimal outcome. 

In pursuing this method, we must have a total buy in from our client.  The temptation to 'just start coding to speed the project up' must be resisted at all costs.  At best this is a road to wasted effort, extended delivery times and higher costs.  At worst, it leads to disaster.

Top of Page

Step 1.3 Design Approval

Design approval at this stage in our method means that we agree that we have captured all we can of the system needs and requirements in the Visual Prototype and that there is substantial agreement that what we see in the Prototype is what we expect in the final system.  This stage is signed off by printing copies of each screen in the Visual Prototype and having them signed and dated by representatives of both parties.

Step 1.4 Technical Specification

The Technical Specification is the step that captures all of the intentions expressed in the Visual Prototype and translates them into a structure and language that ensures that the Production Cycle conforms to and delivers these intentions.  In addition to this, it is the place where all of the business rules required for the system are captured.  This all needs to be expressed in highly formal terms.  Dimmick Consultancy has adopted a CASE[4] tool called Adalon, developed and sold by Synthis[5].  This software is a visual diagramming tool that allows an entire application to be mapped schematically and for all attributes, data elements, display elements and actions to be captured fully and formally.  From an Adalon project we can generate all required reports and documentation as well as producing a complete code stubbed framework ready for our Production Cycle.  This is an enormous productivity boost as well as ensuring full specification conformity into the Production Cycle.

The capture of business rules will most likely have occurred to a degree during the earlier steps.  Building the technical spec highlights any deficiencies in the rules collected and indicates where rules are required that haven't been considered.  All business rules are embedded into the Adalon project.

The outcome of the Technical Specification step is a completed Adalon project that can be shared with all involved through the Adalon reporting mechanisms.  Many people in our client organisation will be able to appreciate and access the technical spec and will be valuable in helping to ensure correctness and completeness.  This is done through an 'Advanced Wireframe' report that automatically generates a complete HTML click through of the application via a series of screens that represent the application's display screens, actions and exits.  All formal documentation is linked to these views and can be read by all parties involved.

Note in the diagram that we show the ability to cycle back up from the Technical Specification to the Visual Prototype (and, by implication, to the Requirements step).  This is necessary because it will not have been possible to foresee all of the impacts upon the Visual Prototype of the business rules in advance of their formal definition and that formal definition cannot be completed prior to the Technical Specification.

Produced concurrently with the Technical Specification, and delivered as part of the overall spec, is a Testing Plan.  The Testing Plan defines every function of the system as it will appear to a user, with provision to record any problems or deviation from specification.  This will be used later during the testing steps.

Top of Page

Step 1.5 Specification Review

The purpose of the Specification Review is to ensure completeness and correctness of the Technical Specification.  While it is shown in the diagram as a discreet step, it is quite likely to be a repeated cycle as the system areas are explored and defined.

Step 1.6 Specification Locking

This means exactly what it says.  A point is reached where the system is fully defined in the terms explained above and all parties have agreed.  This is not optional in our method; it is a requirement of our engagement in any project.  Developers and clients alike may find the idea of 'flexibility' during the Production Cycle to be indicative of good service.  It is, in reality, the opposite.  If a system is allowed to be endlessly redefined as it is being built there is the certainty of spiralling and uncontrollable costs and the distinct risk of a project that never completes.  This happens in practice to an alarming extent.  Some sources quote percentages of projects failing to deliver to expectations in the order of 50% to 70%[6].  The specification will be locked definitively at this stage so that the most effective and lowest risk Production Cycle can commence.

Top of Page

2.  The Production Cycle

Step 2.1 Coding

Coding is the primary activity of the Production Cycle.  It is often thought of as the major activity in software production.  In this method, it is the lessor activity.  Today there are many highly effective and experienced programmers in the market place.  This ensures a good supply of reasonably priced, competent workers for this part of the process.  A very important aspect of our methodology is that our coders do not need to understand the system as a whole in order to perform to requirements in delivery of the code components.  This is because the method produces a specification where each component is fully and independently described in terms of its inputs, processes and outputs.   Adalon embeds these descriptions into the code stubs ready for coding.  This also has a great impact on productivity.  The big picture is managed by less people through the architecting process and individual coders do not need to spend time learning and keeping up to date with the global aspects of the project or endlessly communication among themselves in order to negotiate shared parameter names and data types for input and output.  What effort is spent at this level can focus on best practice issues in coding, a much more productive use of time.

Step 2.2 Unit Testing

Unit testing is carried out in a series of steps.  It is first performed by the coder before they submit a finished component to the project manager.  The project manager then verifies the submitted work and returns it to the coder if necessary. 

Step 2.3 Workflow Testing

When the components required for a particular piece of system functionality have been created and tested, that piece of functionality can be tested at the system level.  This work will be carried out by the project manager or a dedicated tester.  This will pick up most problems that didn't surface in Unit Testing.  Workflow Testing is based upon the Test Plan produced at the specification stage.

Step 2.4 Primary Coding Completed

This point is reached when all of the coding required by the specification has been built, unit tested and workflow tested. 

Step 2.5 UAT

User Acceptance Testing is carried out by the client.  The same Testing Plan as used by the production team will be used by the client testers.  All problems discovered will be fed back up into the Production Cycle and then retested by the production team before being resubmitted to the UAT team.

Top of Page

3. Version Completion

Step 3.1 Deployment

When UAT has been signed off, the final product is installed into the deployment environment and re-tested to ensure that the change of environment hasn't caused any problems.  Typical problems that can arise at this point include those arising from environmental settings and version differences in the server technologies.  These are generally easily resolved.

Step 3.2 Delivery

Delivery is the stage of 'switching on' the system to the users.  Any training required can be delivered at this point, either by the developers or by suitably prepared client staff.

A Final Note

While we indicate 'Completion' as though it were a final and definitive step, the reality is that software systems go through a life cycle of progressive maintenance, updating and extension.  This why the final section is labelled 'Version Completion'.  It means that this major version of the system is complete, as part of the overall lifecycle of the product.  If the diagram is seen as a repeatable cycle, then any new requirements will be specified and developed in exactly the same way as the primary development cycles.  In the introduction, we mentioned software longevity as one of the benefits of our practice.  Because of the highly refined structures and clear methodology of our approach, software is produced in a very modular, extensible and maintainable way.  Any temptation to take short cuts in enhancements, extensions and updates to the delivered system will systematically reduce stability, maintainability and longevity.  Software systems die when they can not be understood and maintained.  Software that doesn't suffer from this realises vastly higher value from the initial investment and makes for very cost effective upgrades.

Top of Page