Iterative and Incremental Development

A beginners Guide

Introduction
Pros and Cons of waterfall and spiral model
Enter IID – Iterative, Incremental Development
Conclusion
Bibliography

Introduction

Most of us in our software development experience would have seen various types of software development practices, such as ad-hoc model (!), where you get directly into coding from the first day; the cascade model, where you analyze, build, test, implement and deploy; the traditional waterfall model, where in each stage must be complete before the next stage can commence; the spiral model where you attack the project in shorter life cycle, each ending with an executable. But when you look into each of these there are both direct or indirect problems and negative problems with these models, in this document we will be discussing those problems and also look into some basics of the Iterative, Incremental framework which is now being considered as a part of Extreme Programming (XP). Pros and Cons of waterfall and spiral model

Waterfall Model

For those of us who are hearing the term Waterfall model for the first time, here is a brief description about the model and then we will look into its pros and cons.

What we call the ‘Waterfall model’ today was actually opinions of Mr. Winston Royce in his infamous article ‘Managing the development of Large Software Systems’ in late seventies. The waterfall model stresses that we should strictly complete each phase of the development before going to the next. This is where we exactly differ from what Mr. Royce had suggested, he had said it should be done twice, but we do it only once!

If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations area are concerned”

Reference:

http://www.programmersheaven.com/articles/images/guruprasad/waterfall.jpg

Let us now look at some of the important drawbacks of the waterfall model

1. The simplicity of managing the process becomes complex as the size of the project increases.
2. This model will suite for small projects whereas in case of larger projects (the term large is subjective here) the systems should be fully be analyzed and understood before progress is made towards design phase. This might lead into confusions and time consuming.
3. Risk is pushed forward, Major part of the risk happens or rises only towards the end of the project, especially during the implementation phase, where in the cost to rectify these risks also raises accordingly.
4. On larger projects each phase could be heavy-duty time consuming.
5. Even if we follow rigid standards such as getting a requirement signoff from the customer, the final product will not necessarily be what the customer wants then.
6. Waterfall model will suite best only for smaller projects with a short lifespan only.

Spiral Model

Spiral model is an alternate to the waterfall model; it was originated by Mr. Barry Boehm once a chief scientist of TRW (An army site defense software project for ballistic missile defense) in which we attack the project with shorter life span, and ending each phase with an executable deliverable. In spiral model the team would be able to concentrate on all phases of development rather than concentrating on a single phase. The customer feedback will be regular and so will be update done to the software. Risks can be managed then and there; especially risks like testing a particular new technology can be done, deployed and analyzed. The status of the project can be assessed more accurately. Spiral model actually formalized and made prominent the risk-driven-iterations concepts and need to use a discrete step of risk assessment at the end of each phase. Reference:

http://www.programmersheaven.com/articles/images/guruprasad/spiral.jpg

Though there are advantages of spiral model over waterfall model, it has its own drawbacks, let us look at some of the drawbacks of this model:-

1. This process needs or usually associated with Rapid Application Development, which is very difficult practically.
2. The process is more difficult to manage and needs a very different approach as opposed to the waterfall model (Waterfall model has management techniques like GANTT charts to assess)

Enter IID – Iterative, Incremental Development

To counter the drawbacks of the spiral model, a similar but more formal approach evolved called Iterative, Incremental Framework or Development (in short IID). An early reference (at east the reference which the world knows as earliest), to IID was made by Mr. Harlen Mills of IBM in late seventies. He had promoted IID in his well-known book “Top down programming in Large Systems”. Clearly Mr. Mills suggested for iterative development or refinement of the development phase Early adoption of modern IID came through the leaders in IBM, namely Mr. Mike Dyer, Bob McHenry and Don O’neil. This was the time when IID proved at its best when this was implemented successfully for US Department of Defense on a life critical space project of that time.

The following is the definition of IID, which was defined by Mr. Vic Basili “The basic idea behind iterative enhancement is to develop software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. At each iteration, design modifications are made along with adding new functional capabilities”

The IID is a logical extension of the spiral model. The model is divided into four major phases

• Inception
• Elaboration
• Construction and
• Transition

PS: These phases should not be confused with the stages in the waterfall model.

Inception

This is the phase in which the scope of the work or project is prepared. The normal possible deliverables from this phase are

1. A scope or vision document
2. An exploration of clients requirements
3. Business case
4. Initial risk assessment
5. A project plan

We should be very careful that we should not get deep inside the project now. Developing a prototype can be done in this phase.

Elaboration

In this phase we should actually dig more in to the project, assess it more and develop the project plan more. By the end of the elaboration phase we should aim at having a general knowledge about the project. Two of the UML models play a major role in this phase, The Use Case diagram to understand the user requirement and the Class diagram to explore the customer’s major concepts. Development of prototype is a nice idea in this phase.

Construction

At this phase, we actually start manufacturing the project. The product is built in same fashion as in the spiral model, but by following a series of iterations. Each iteration can be related to the waterfall model. UML models such as sequence diagrams and collaboration diagrams can be used describe the flow and interactions. At the end of as much iteration as possible we will have a concrete software executable (Note: This is still in early stages only!)

Transition

This phase can be understood as moving from beta release to final release. No new features are added, just optimization of the product, testing, bug fixing and documentation works are done. Following are the list of activities performed during this phase

1. Beta releases to the testing team
2. Parallel run of the product (if applicable) with the legacy system on the client side.
3. User manual preparation and appropriate user training
4. Marketing and Sales.

Some projects may require beta releases, but the product should be in well completed state before this phase happens.

Having described about the phases of an IID model, we are bound to think on how much long each phase should last? Though this is more subjective question, a loose guide line is 10% inception, 30% elaboration, 50% construction and 10% in transition.

Conclusion

Hope this document has roughly described the general definitions of various software development models, their history and how things evolved.

Bibliography

• IID – A brief history by Craig larman and Victor R. Basili
• From Waterfall to Iterative Lifecycle, Philippe Krutchen, 2000 – Rational whitepaper
• Dan Bunea’s IID and UML
• Crash: Learning from the world’s worst computer disasters - Tony Collins (A collection of case studies of why so many software development projects fail)
• OOAD – A companion handbook to RUP

About the Author

The author Guruprasad L, has around 7 years of experience in the IT industry and currenty working as a Systems Analyst in chennai India.

---