Iterative System Development
This is a draft. Please let us know if we've omitted anything important.
The bad old days
In the beginning there was phased development. Building functionality a little at a time and using the "Waterfall" approach at each stage:
- Requirements, Specification, Design, Code, Test, Deliver
Initially this worked well and methodologies were developed and widely adopted. It worked because each enterprise required but a small number of critical systems. These systems were rather simple and did not need to be well user engineered by today's standards. (Green screens, printed output etc were acceptable.)
As time progressed the environment changed and major projects started to fail. This was primarily because business changes produced requirements changes during the life of a project. Also because the full scope of requirements became very broad. (c.f. Taurus) In a sense this was a product of the increasing power-to-cost ratio of IT.
Oh how things have changed!
Business drivers for today's IT systems include:
- Much greater complexity and functional coverage (Moore's Law enabled)
- Highly competitive market makes time-to-market critical
- High standards of usability including GUIs are now mandatory
- Stringent requirements for enterprise-wide integration
Web applications are the most poignant example because they:
- Are in your "front line"
- Require continuous development over lifetime
- Need to react rapidly to market changes
- Delivered through browser technology (not as powerful as Win GUI)
The industry reaction to these drivers is Iterative Development. This is the concatenation of many tiny Waterfalls.
Some key differences
Let's compare approaches then and now.
||Whatever size it takes. Different skills (some of which very arcane)brought to the table by different team members.
||Small, to minimize the cost/ delay of communication within the team. Multi-skilled people who can simultaneously understand requirements and implementation issues.|
||Obtain a full understanding of the whole requirement before the project starts.
||Start with as much of the requirement as possible but accept that this is incomplete.|
||Produce a complete but potentially abstract documention that specifies everything you need to develop the software. Document exactly how things should be done.
||Document only what is needed. Use rough prototypes to illustrate requirements and verify them with representative users. Accept that this specs will be incomplete until close to the end of a project phase.|
||Highly skilled task to check that the specs are in-line with requirements.
||Pay much more attention to requirements and feedback than to specifications. Ban objections like "scope creep".|
|Time to first full user review
||80-90% of project duration.
||Less than 10% of project duration.|
|Number of complete reviews per major project phase.
||Five to ten.|
||Determined base up from the time required to build what is required.
||Set by the business requirement. Functionality may have to be sacrificed to shoehorn the project into the allotted time.|
||Build, test and integrate module by module.
||Start all modules and accept some gaps in detailed functionality in the first few iterations.|
||Produced in advance and should need little work post-implementation.
||Accept that it will be sketchy until the iteration nears completion.|
||Start CR process once spec is signed off.
||Defer formal CR process until prpoject phases are complete. During the phases maintain the requirements documents and any implementation notes as each change is requested.|
|Need to rewrite code
||Should not be needed to any significant extent.
||Throw away code that proves unsatisfactory (50% of work if necessary).|
||Formal and towards the end of the project phase.
||Informal and continuous.|
||Proven, standards-based. Take care to reuse rather than copy and hack repetituve functions.|
||Primitive tools such as procedural programming languages and databases.
||Powerful tools which may be complete subsystems like CRM apps or high-level toolsets like Content Management Systems.|
|Amount of procedural code
||Minimal (thanks to tools)|
Given that a first iteration can, by definition, never be complete, careful consideration must be applied to deciding what can be omitted. In general, this should be functionality that is transparent to the reviewer. This allows business-focussed, often non-technical, reviewers to carry out their task effectively.
Some Dos and Dont's of Web Development
- Timebox it;
- Minimise the size of the core team;
- Maximise the amount of empowered user involvement;
- Use a powerful platform;
- Iterate like crazy;
- Use realistic and concrete visual documentation to check requirements;
- Develop the first complete version very fast;
- Minimise formalities;
- Avoid abstract specifications that only developers can understand;
- Be prepared to throw away anything that doesn't satisfy needs.