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".
Some monitoring is needed, both for your own benefit and to keep others happy.
The choice of model affects how easily progress can be monitored. If no "book-keeping" is done, the unproductive time and 'admin' overhead
increase rather than decrease as the project progresses.
For small groups, the cost of computing metrics is 3-8% initially dropping
to 1% (Pressman, p.100).
Records are also a
way to cover yourself if things go wrong.
Note than some statistics (e.g. lines of code produced per day) might be more
useful as propaganda than as progress indicators. Of course, that doesn't stop
them being useful to you. Especially if you're using O-O techniques you can
the boss with impressive complexity metrics (members per class,
depth of inheritance tree, number of children, number of operations
overridden, percent of public and protected, etc).
- Use Binary Milestones - tasks are either Done or Not Done.
The problem with tasks that are 90% done, is that the other 10% can end up taking a long time.
- A WWW page helps with communications - eg a project diary. If you keep it up to date people
might not pester you for progress reports
- Keep a "Top 10 Risks List" and make it generally visible - it will help convince people that you have their
concerns at heart. Update it fortnightly on a Friday afternoon. Column headings might include "Position", "Last position", "Weeks in chart", "Description" and "Progress". The major risks may be more to do with "management" than programming. Pressman (p.149) reports the 5 top project risk
factors as: lack of formal top-management support; lack of end-user interest;
lack of understanding of requirements; lack of end-user involvement in
requirements definition; unrealistic end-user expectations.
Updated April 2011 with help from James Matheson