Page 38 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes the project control list is empty, at which time the final implementation of the system will be
available. The iterative enhancement model is shown in Figure 2.4.

Figure 2.4: The Iterative Enhancement Model

Design 0 Design 1 Design n

Implement 0 Implement 1 Implement n

Analysis 0 Analysis 1 Analysis n

The project control list guides the iteration steps and keeps track of all tasks that must be done.
Based on the analysis, one of the tasks in the list can include redesign of defective components
or redesign of the entire system. However, redesign of the system will generally occur only in
the initial steps. In the later steps, the design would have stabilized and there is less chance of
redesign. Each entry in the list is a task that should be performed in one step of the iterative
enhancement process and should be simple enough to be completely understood. Selecting tasks
in this manner will minimize the chances of error and reduce the redesign work. The design
and implementation phases of each step can be performed in a top-down manner or by using
some other technique.

Though there are clear benefits of iterative development, particularly in allowing changing
requirements, not having the all-or-nothing risk, etc., there are some costs associated with iterative
development also. For example, as the requirements for future iterations are not known, the
design of a system may not be too robust. Also, changes may have to be made to the existing
system to accommodate requirements of the future iterations, leading to extra rework and/or
discarding of work done earlier. Overall, it may not offer the best technical solution, but the
benefits may outweigh the costs in many projects.

Another common approach for iterative development is to do the requirements and the
architecture design in a standard waterfall or prototyping approach, but deliver the software
iteratively. That is, the building of the system, which is the most time and effort-consuming
task, is done iteratively, though most of the requirements are specified upfront. We can view
this approach as having one iteration delivering the requirements and the architecture plan,
and then further iterations delivering the software in increments. At the start of each delivery
iteration, which requirements will be implemented in this release is decided, and then the design
is enhanced and code developed to implement the requirements. The iteration ends with delivery
of a working software system providing some value to the end user. Selecting of requirements
for iteration is done primarily based on the value the requirement provides to the end users and
how critical they are for supporting other requirements. This approach is shown in Figure 2.5

The advantage of this approach is that as the requirements are mostly known upfront, an overall
view of the system is available and a proper architecture can be designed which can remain
relatively stable. With this, hopefully rework in development iterations will diminish. At the
same time, the value to the end customer is delivered iteratively so it does not have the all-or-
nothing risk. Also, since the delivery is being done incrementally, planning and execution of each
of iteration is done separately, feedback from iteration can be incorporated in the next iteration.
Even new requirements that may get uncovered can also be incorporated. Hence, this model of
iterative development also provides some of the benefits of the model discussed.

32 LOVELY PROFESSIONAL UNIVERSITY