Software Engineering

CS-251
Lecture 4

Course Instructor: Sajid Khattak

1
 The Prototyping Model

• Often, a customer defines a set of general objectives for software but does
not identify detailed input, processing, or output requirements.
• In other cases, the developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or the form that
human/machine interaction should take.
• In these, and many other situations, a prototyping paradigm may offer the
best approach.

2
 The Prototyping Model
• The prototyping paradigm begins with requirements gathering.
• The developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
• A "quick design" then occurs. The quick design focuses on a representation of those aspects of
the software that will be visible to the customer/user (e.g., input approaches and output
formats).
• The quick design leads to the construction of a prototype. The prototype is evaluated by the
customer/user and used to refine requirements for the software to be developed.
• Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same
time enabling the developer to better understand what needs to be done.
3
The Prototyping Model

4
The Prototyping Model

5
 The Prototyping Model
• Ideally, the prototype serves as a mechanism for identifying software requirements.
• If a working prototype is built, the developer attempts to use existing program fragments
or applies tools (e.g., report generators, window managers) that enable working
programs to be generated quickly.
• The prototype can serve as "the first system." The one that we throw away. But this may
be an idealized view.
• It is true that both customers and developers like the prototyping paradigm.
• Users get a feel for the actual system and developers get to build something
immediately. Yet, prototyping can also be problematic for the following reasons:
6
 The Prototyping Model
1. The customer sees what appears to be a working version of the software, unaware that
the prototype is held together “with chewing gum and baling wire,” unaware that in the rush
to get it working no one has considered overall software quality or long-term
maintainability.
• When informed that the product must be rebuilt so that high levels of quality can be
maintained, the customer cries foul and demands that "a few fixes" be applied to make
the prototype a working product.
• Too often, software development management relents.

7
 The Prototyping Model

2. The developer often makes implementation compromises in order to get a

prototype working quickly. An inappropriate operating system or
programming language may be used simply because it is available and
known; an inefficient algorithm may be implemented simply to demonstrate
capability.
• After a time, the developer may become familiar with these choices and
forget all the reasons why they were inappropriate. The less-than-ideal
choice has now become an integral part of the system.
8
 The Prototyping Model

• Although problems can occur, prototyping can be an effective paradigm

for software engineering.
• The key is to define the rules of the game at the beginning; that is, the
customer and developer must both agree that the prototype is built to serve
as a mechanism for defining requirements.
• It is then discarded (at least in part) and the actual software is engineered
with an eye toward quality and maintainability.

9
 Types of Prototyping
• 1. Rapid Throwaway Prototyping –
• This technique offers a useful method of exploring ideas and getting
customer feedback for each of them.
• In this method, a developed prototype need not necessarily be a part of the
ultimately accepted prototype
• Customer feedback helps prevent unnecessary design faults and hence, the
final prototype developed is of a better quality.

10
 Types of Prototyping
2. Evolutionary Prototyping
• In this method, the prototype developed initially is incrementally refined
based on customer feedback till it finally gets accepted.
• In comparison to Rapid Throwaway Prototyping, it offers a better
approach which saves time as well as effort.
• This is because developing a prototype from scratch for every iteration of
the process can sometimes be very frustrating for the developers.

11
 Advantages of Prototype Process Model
• The customers get to see the partial product early in the life cycle. This
ensures a greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for
refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost.
• The developed prototype can be reused by the developer for more
complicated projects in the future.
12
 Disadvantages of Prototype Process Model
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is
evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes demanded
by the customer.
• There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
13
 Disadvantages of Prototype Process Model
• After seeing an early prototype, the customers sometimes demand the
actual product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal
solutions.
• The customer might lose interest in the product if he/she is not satisfied
with the initial prototype.

14
 When to Use Prototype Process Model
• It should be used when the requirements of the product are :
• not clearly understood or
• Unstable (Keeps Changing).
• This model can be successfully used for developing user interfaces, high
technology software-intensive systems, and systems with complex
algorithms and interfaces
• It is also a very good choice to demonstrate the technical feasibility of the
product.
15