Page 40 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes burden on the project manager: an overall plan has to be developed, and detailed plans will in
turn be developed for each iteration”. More architectural planning will also take place earlier,
and as stated previously, takes on greater importance. Artifacts documents and code will have
to be modified, reviewed and approved repeatedly at each revision Personnel will have to be
continually reviewed as the iterative tasks cycle rapidly and overlap.

Prepare a flow chart for the working of iterative model.

2.5.1 Advantages of the Iterative Model

A comparison of the conventional lifecycle to the iterative one reveals that the iterative model is
more flexible, as it presents more opportunities to introduce change. In the iterative model, change
is an acknowledged, integral component. Rework is accepted, but should diminish rapidly; the
changes should be less widespread as the architecture stabilizes and ideally, the hard issues are
being resolved .The embrace of source code amendment has a profound and positive impact on
software quality. When errors are found, they can be corrected at best real-time, at worst in the
next iteration. Contrast this to the waterfall model, where software is often released with major
defects--because it is too late in the lifecycle to rewrite, or redesign components.
Another advantage of the iterative model is that the complexity of implementing the system is
never overwhelming. Because elements are designed, developed and integrated in iterations,
the analysis paralysis that is common on enterprise scope projects is alleviated. In addition, the
developers get a chance to grow with the project. Each of iteration can leverage the business
knowledge gained on the previous and the team gets used to delivering finished software.

Using the iterative model brings more focus on the software, and less on the specifications. This
is a valid trade-off, as the customer is not buying specifications. The specifications are only an
attempt to communicate the business mind to the technical mind. By moving forward into an
implementation sooner in the project, requirement issues are bubbled to the surface earlier. If
critical errors in design or integration are to be discovered, it is better for all concerned that they
be uncovered early in the project. This early feedback from the customer serves to drive the
next iteration in the correct direction. The requirements can be modified without junking weeks
of development, as each of iteration through the model has all of the aspects of a traditional
software project, which has been completed.

The iteration and increment model was first used by NASA’s 1960s Project
Mercury.

2.6 Time Boxing

Eventually boxing, as in other iterative development approaches, some software is developed
and a working system is delivered after each iteration. In time boxing, each iteration is of equal
duration, which is the length of the time box. In this section we discuss the various theoretical
issues relating to this process model.

2.6.1 A Time box and Stages
In the time boxing process model, the essential unit of expansion is a time box, which is of
permanent duration. Within this time box all activities that need to be performed to successfully
release the next version are executed. Since the duration is fixed a key factor in selecting the
requirements or features to be built in a time box is what can be fit into the time box.

34 LOVELY PROFESSIONAL UNIVERSITY