Models for Managing Projects

• Waterfall model - this is the classic SDLC we knew and loved in IPM

• Agile

• RAD

• Prototyping

Note: "SDLC" can mean both "System Development Life Cycle" or "Software Development Life Cycle" - it depends on whether you are building systems or software at the time. It can also be called the PDLC - Product Development Life Cycle.

Waterfall SDLC model - a predictive approach

The VCE IT model of the System Development Life Cycle (SDLC) contains 5 stages that flow from one to the next in order (hence the 'waterfall' imagery.) As with a real waterfall, the progression from stage to stage is one-way only, and a stage, once completed, is not revisited.

An advantage of the water It is popular because each stage can be compartmentalised (so one stage is completely separate to other stages and there is no overlapping) and the project's deadlines can be set, monitored and managed tidily.

A disadvantage of the Waterfall model is that it is so linear and sequential. Once a phase begins, if a team discovers a previous stage they had not thought out properly or a vastly better method were possible, the team would have to persevere with the existing plan: they cannot revisit the analysis phase, for example, to do more observation and better understand the nature of the problem.

There are alternatives to the strictness of the Waterfall model: you will need to be familiar with Rapid Application Development (RAD), but other models include Joint Application Development (JAD), Synch and Stabilise, Build and Fix, and the Spiral Model of the SDLC.

The Waterfall SDLC steps are:

• Analyse - study the current system; determine if there is really a problem; determine if the problem can be fixed; determine if the problem is worth fixing; determine what the new or changed system should be able to achieve. Finish with a logical design. Details.
• Design - Consider alternative ways of solving the problem; plan what hardware, software, procedures and data need to be created, purchased or assembled. Design other key features such as documentation, training, testing, implementation and evaluation requirements. Finish with a physical design.
• Develop - write the software, build the hardware, buy equipment, assemble components, formalise procedures of how the product should be used, perform ongoing informal component testing and integration testing. Write the documentation and training procedures. Finish with format testing, including acceptance testing.
• Implement - roll out the solution to its users using strategies such as direct, phased, parallel and/or pilot.
• Evaluate - review the development process and the finished product to learn from mistakes and identify good practices. Ensure the finished product is performing as specified during the design phase.

Details of the SDLC are here. Note - the version there includes 2 optional steps: testing and documentation which are not part of the 'official' VCE SDLC.

Agile methods - an adaptive approach

Reacting against the perceived strict regimentation of the Waterfall Model, the Agile model appeared in the 1990s. Its developers believed the Waterfall model was too slow and bureaucratic and did not comfortably accommodate the ways systems/software engineers actually work best. Agile, put simply, is where software is developed progressively with each new release adding more capabilities

It appeared under different names and flavours such as: Scrum (in management), Crystal Clear, Extreme Programming (XP), Adaptive Software Development, Feature Driven Development, and DSDM.

Agile aims to reduce risk by breaking projects into small, time-limited modules or timeboxes ("iterations") with each interation being approached like a small, self-contained mini-project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis, design, production, testing and documentation. In theory, a new software release could be done at the end of each iteration, but in practice the progress made in one iteration may not be worth a release and it will be carried over and incorporated into the next iteration. The project's priorities, direction and progress are re-evaluated at the end of each iteration.

Agile teams tend to work as a team in a bullpen - an open floor-plan work area that makes face-to-face communications easy. Agile, however, has been criticised for its lack of formal documentation.

(One wonder how well Agile development techniques would work for Virtual Teams.)

Agile's aims and characteristics include:

• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress.
• Even late changes in requirements are welcomed.
• Close, daily, cooperation between developers and customers
• Face-to-face conversation is the best form of communication.
• Projects are built around motivated individuals, who should be trusted (rather than micro-managed)
• Continuous attention to technical excellence and good design.
• Simplicity
• Self-organising teams
• Regular adaptation to changing circumstances

Such flexibility is seen by some as a lack of discipline, but its ability to adapting quickly to change can make it a powerful method of tackling big projects - and ICT is a field where rapid and significant change is the rule rather than the exception! On the other hand, long-term (beyond a couple of months) planning is very hard to do with an Agile approach.

I guess an Agile project manager would be updating his Gantt chart daily :-)

Agile methods have features in common with RAD.

(Thanks to Wikipedia for information on Agile)

Rapid Application Development - RAD

The perceived slowness and inflexibility of the Waterfall SDLC menthod led to the development of a method that reacted quickly to change and adapted to changing conditions: a normal state of affairs in the fast-moving ICT industry. Where the Waterfall model would slowly chug forward, the market or technologies would change under its feet: sometimes by the time software was released, its was already out of date, irrelevant or incompatible with new industry standards.

RAD works differently. It develops products in a sequence of small upgrades: each release has slightly more functionality than the previous one, and over time the product matures into a finished product. In the time a team would take to fully develop a product using the SDLC, a RAD team might have released a dozen incremental versions.

The drawback of RAD is its short-sightedness: you could tell what would be happening in a week's time; you could guess what you'd be doing in a month; but trying to predict the state of a project in a year's time would be like reading tea leaves.

Unlike the SDLC, RAD makes it easy for customers to redefine their basic needs and expectations from a product.

A possible drawback of RAD, however, is that it would seem to encourage a "make it up as you go along" approach which will limit a product's scalability or future modification. The thorough planning and analysis of the SDLC would tend to create products that anticipated future needs and allowed expansion. A RAD product would more likely be hammered together to cater for immediate needs, but cope poorly if it had to be radically altered later.

I see SDLC like building a skyscraper, with the TV aerial on the penthouse fully designed before the foundations are even dug. I see RAD more like a shanty town that has new shacks thrown together as the need arises: quick, responsive, but not too elegant or enduring.

A classic example of rapid, successful development was the original IBM PC and its accompanying operating system - MS-DOS.

A classic example of development gone wrong is the game Duke Nukem Forever, which has been awaited for six years, with still no sign of release. It has won Wired News' "Vapourware Product of the Year" every year since 2001.

Details on other SDLC models