Page 39 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 2: Software Processes and Models

Figure 2.5: Iterative Delivery Approach Notes

The iterative approach is becoming extremely popular, despite some difficulties in using it in this
context. There are a few key reasons for its increasing popularity. First and foremost, in today’s
world clients do not want to invest too much without seeing returns. In the current business
scenario, it is preferable to see returns continuously of the investment made. The iterative
model permits this after each of iteration some working software is delivered, and the risk to
the client is therefore limited. Second, as businesses are changing rapidly today, they never
really know the complete requirements for the software, and there is a need to constantly add
new capabilities to the software to adapt the business to changing situations. Iterative process
allows this. Third, each of iteration provides a working system for feedback, which helps in
developing stable requirements for the next iteration.
The four basic process areas of the iterative model are:
• The requirements phase, in which the requirements for the software are gathered and
analyzed. Iteration should eventually result in a requirements phase that produces a
complete and final specification of requirements.

• A design phase, in which software architecture and components to meet the requirements
are designed; this may be a new design, or an extension of an earlier design.

• An Implementation phase, when the software is coded, integrated and tested.
• A review phase, in which the software is evaluated, the current requirements are reviewed,
and changes and additions to requirements proposed.

The design phase develops the architecture that forms the foundation for the system and is
critical to the success of the subsequent iterations. For obvious reasons, the design must facilitate
change, and be robust enough to support unforeseen, future implementations. For each cycle
of the model, a decision has to be made as to whether the software produced by the cycle will
be discarded, or kept as a starting point for the next cycle. This approach has been referred to
as incremental prototyping. However, the temptation to create a quick prototype that cannot
scale-up must be resisted typically; this is not prototyping, although it could be. The cycle is
complete when the requirements have been satisfied, and the release to the customer is made.
On some iteration particularly early ones, a decision may have to be made to abandon the
approach and begin anew.
The iterative model is not without its share of potential pitfalls. If fact, according to Kruchten,
iterative development actually involves much more planning and is therefore likely to put more

LOVELY PROFESSIONAL UNIVERSITY 33