Page 80 -
P. 80
3.2 Plan-driven and agile development 63
Plan-Based Development
Requirements Requirements Design and
Engineering Specification Implementation
Requirements Change
Requests
Agile Development
Requirements Design and
Engineering Implementation
Figure 3.2 Plan-driven
and agile specification
A plan-driven software process can support incremental development and deliv-
ery. It is perfectly feasible to allocate requirements and plan the design and develop-
ment phase as a series of increments. An agile process is not inevitably code-focused
and it may produce some design documentation. As I discuss in the following sec-
tion, the agile development team may decide to include a documentation ‘spike’,
where, instead of producing a new version of a system, the team produce system
documentation.
In fact, most software projects include practices from plan-driven and agile
approaches. To decide on the balance between a plan-based and an agile approach,
you have to answer a range of technical, human, and organizational questions:
1. Is it important to have a very detailed specification and design before moving to
implementation? If so, you probably need to use a plan-driven approach.
2. Is an incremental delivery strategy, where you deliver the software to customers
and get rapid feedback from them, realistic? If so, consider using agile methods.
3. How large is the system that is being developed? Agile methods are most effec-
tive when the system can be developed with a small co-located team who can
communicate informally. This may not be possible for large systems that require
larger development teams so a plan-driven approach may have to be used.
4. What type of system is being developed? Systems that require a lot of analysis
before implementation (e.g., real-time system with complex timing require-
ments) usually need a fairly detailed design to carry out this analysis. A plan-
driven approach may be best in those circumstances.
5. What is the expected system lifetime? Long-lifetime systems may require more
design documentation to communicate the original intentions of the system