Splitting the task into de-coupled sections has many benefits. Recently,
Plug-in architectures have become popular. As well as allowing
others to extend the program, there are development advantages too
- development teams can work independently
- some decisions about what features to offer can be deferred
- Waterfall - Non-overlapping phases. OK if detailed analysis can be successfully completed
prior to coding. This might well be possible for a stable project definition and development environment. A variant is the Sashimi lifecycle with some overlap (local eddies)
- Spiral - revisits all phases of development. Useful with new technologies -
minimises the costs of rethinks - but can be hard to manage.
- Reuse-orientated - Relies on a large base of reusable software. Development may consist in adapting existing code, combining the components
using Corba, Javabeans, etc.
- Staged delivery or Iterative model - each milestone is a working release. Useful with new technologies in particular (Survival Guide p.56). It's considered by some books to be much preferable to Waterfall - "Contrary to popular belief, waterfall is alive and well ... and continuing to undermine projects today" (The Software Development Edge, p.58)
A style of software development called Agile is another reaction to the monolithic waterfall method. There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. The emphasis is on doing things in small increments with minimal planning in short time frames, thus being more adaptable. Extreme Programming (XP) is a specific agile method
- It avoids the all-or-nothing risk when the Waterfall model is used - some recent
UK central government failures have been blamed on their "big bang" implementation.
- Integration testing (and several other difficult phases) is spread across the life-cycle.
- The point when you have to decide whether the project is feasible will be reached sooner, and with fewer staff taken on (The Software Development Edge)
- You can "Measure progress by working code, not documents" (The Software Development Edge, p.58)
- You can "Progressively reduce risk by attacking hard problems first" (The Software Development Edge, p.58)
- The success at meeting iterative deadlines can help calibrate future estimates (The Software Development Edge)
- Controlled iteration - Go onto the next stage if (say) 80% is done. Appropriate for strongly Object-Orientated tasks where progress
- Test-First Development - In some communities developers write tests first, so that they can serve as a well-defined specification as well as a test-suite. Only once the tests are written do they start writing the code that will pass those tests
"Test-driven development" (TDD) involves a cycle of writing a test program that fails, writing the simplest code to fix it, then refactoring. This approach raises the status of testing, and provides clear targets, but the repeated refactoring/re-designing may lead to more work.
Note that in an Object-Orientated situation, things might not develop as outsiders (or older programmers) might
expect - if data-structures are hidden away inside objects, detailed
decisions about data-structures may be deferred. Top-down design is
complicated by the fact that there may be no "top".
Updated April 2011 with help from James Matheson