Page 61 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes In prototyping, for the purposes of requirement analysis to be feasible, its cost must be kept low.
Consequently, only those features are included in the prototype that will have a valuable return
from the user experience. Exception handling, recovery, and conformance to some standards
and formats are typically not included in prototypes. In prototyping, as the prototype is to be
discarded, there is no point in implementing those parts of the requirements that are already
well understood. Hence, the focus of the development is to include those features that are not
properly understood. Because the prototype is to be thrown away, only minimal documentation
needs to be produced during prototyping. For example, design documents, a test plan, and a test
case specification are not needed during the development of the prototype. Another important
cost-cutting measure is to reduce testing. Because testing consumes a major part of development
expenditure during regular software development, this has a considerable impact in reducing
costs. By using these types of cost-cutting methods, it is possible to keep the cost of the prototype
low.
Prototyping is often not used, as it is feared that development costs may become large. However,
in some situations, the cost of software development without prototyping may be more than the
prototyping. There are two major reasons for this. First, the experience of developing the prototype
might reduce the cost of the later phases when the actual software development is done. Secondly,
in many projects, the requirements are constantly changing, particularly when development
takes a long time. We saw earlier that changes in requirements at a later stage, during
development, substantially increase the cost of the project. By elongating the requirements
analysis phase (prototype development does take time), the requirements are “frozen” at a later
time, by that time they are likely to be more developed and, consequently, more stable. In
addition, because the client and use to get experience with the system, it is more likely that the
requirements specified after the prototype will be closer to the actual requirements. This again
will lead to fewer changes in the requirements at a later time. Hence, the costs incurred due to
changes in the requirements may be substantially reduced by prototyping. Hence, the cost of the
development after the prototype can be substantially less than the cost without prototyping; we
have already seen how the cost of developing the prototype itself can be reduced.

Task In a group of four analyze this statement: “The basic reason for little common use
of prototyping is the cost involved in this built-it-twice approach.”
Prototyping is catching on. It is well suited for projects where requirements are hard to determine
and the confidence in obtained requirements is low. In such projects, a waterfall model will have
to freeze the requirements in order for the development to continue, even when the requirements
are not stable. This leads to requirement changes and associated rework while the development
is going on. Requirements frozen after experience with the prototype are likely to be more
stable. Overall, in projects where requirements are not properly understood in the beginning,
using the prototyping process model can be the most effective method for developing the
software. It is an excellent technique for reducing some types of risks associated with a project.
We will further discuss prototyping when we discuss requirements specification and risk
management.

Advantages of Prototyping

Users are actively involved in the development
It provides a better system to users, as users have natural tendency to change their mind in
specifying requirements and this method of developing systems supports this user tendency.

54 LOVELY PROFESSIONAL UNIVERSITY