PRESENTED BY:

Dr. Mahak Gambhir

Assistant Professor (DCSE)
Thapar University, Patiala
Prototyping Model
 Overview of the model
After gathering requirements from the customer,
instead of developing the complete actual model,
the developer creates a prototype/dummy model.
If the client approves the prototype, then the
developer starts developing the actual model by
following the actual phases of development (i.e.
iterative development with feedback, i.e. with
phases like design, implement, test and maintain).
But if the customer is not satisfied with the prototype,
then refinement of requirements is done, suggestions
are incorporated and the prototype is modified
accordingly.
 It can be considered as an extension of waterfall model
 This model suggests building a working prototype
of the system, before development of the actual
software.
 A prototype is a toy and crude implementation of a
system.
 It has limited functional capabilities, low
reliability, or inefficient performance as
compared to the actual software.
 A prototype can be built very quickly by using several
shortcuts. The shortcuts usually involve developing
inefficient, inaccurate, or dummy functions..
 About Prototype model

 When customer is not clear with the idea that what he

needs (after getting a prototype, he will get some
clarity)
 Throwaway (if the client does not approve the model,
discard the prototype and create the prototype again
by taking customer’s suggestions.)
 Good for technical and requirement risks (if we feel that
customer’s requirements are not sound, then the developer
can provide his suggestions and create a dummy of the
model/prototype)
 Increase in cost of development (prototype development
requires cost)
 Necessity of the prototyping model
The prototyping model is advantageous to use for specifically 3
types of projects. :
 For the development of the graphical user interface (GUI)
part of an application. Through the use of a prototype, it
becomes easier to illustrate the input data formats, messages,
reports, and the interactive dialogs to the customer. This is a
valuable mechanism for gaining better understanding of the
customers’ needs.
 The prototyping model is especially useful when the exact
technical solutions are unclear to the development team.
A prototype can help them to critically examine the technical
issues associated with product development.
For example, consider a situation where the development team
has to write a command language interpreter as part of a
graphical user interface development. Suppose none of the team
members has ever written a compiler before. Then, this lack of
familiarity with a required development technology is a technical
risk. This risk can be resolved by developing a prototype
compiler for a very small language to understand the issues
associated with writing a compiler for a command language.
Once they feel confident in writing compiler for the small
language, they can use this knowledge to develop the compiler
for the command language.
 An important reason for developing a prototype is that it
is impossible to “get it right” the first time. Thus, the
prototyping model can be deployed when development
of highly optimised and efficient software is
required.
 It can be concluded that The prototyping model is
considered to be useful for the development of not
only the GUI parts of a software, but also for a
software project for which certain technical issues are
not clear to the development team.
 Life cycle activities of prototyping model

 Prototype development:
• Prototype development starts with an initial requirements
gathering phase.
• A quick design is carried out and a prototype is built.
• The developed prototype is submitted to the customer for
evaluation.
• Based on the customer feedback, the requirements are
refined and the prototype is suitably modified.
• This cycle of obtaining customer feedback and modifying
the prototype continues till the customer approves the
prototype.
 Iterative development:
• Once the customer approves the prototype, the actual
software is developed using the iterative waterfall
approach.
• In spite of the availability of a working prototype, the SRS
document is usually needed to be to be developed since the
SRS document is invaluable for carrying out traceability
analysis, verification, and test case design during later phases.
• However, for GUI parts, the requirements analysis and
specification phase becomes redundant since the working
prototype that has been approved by the customer serves as
an animated requirements specification.
• The code for the prototype is usually thrown away.
However, the experience gathered from developing the
prototype helps a great deal in developing the actual
system.
Even though the construction of a throwaway
prototype might involve incurring additional cost,
but for systems with unclear customer requirements
and for systems with unresolved technical issues, the
overall development cost usually turns out to be
lower compared to an equivalent system developed
using the iterative waterfall model from the
customer and the associated redesign costs.
 By constructing the prototype and submitting it for user
evaluation, many customer requirements get properly
defined and technical issues get resolved by
experimenting with the prototype. This minimises later
change requests from the customer and the associated
redesign costs.
 Strengths
 Most appropriate for projects that suffer from
technical and requirements risks. A constructed
prototype helps overcome these risks.
 The prototyping model is considered to be useful for the
development of GUI parts of a software, but also
 Helps developers for a software project for which certain
technical issues are not clear to the development
team.
 Though the construction of a throwaway prototype might
involve incurring additional cost, but the overall
development cost usually turns out to be lower
compared to an equivalent system developed using
the iterative waterfall model from the customer and
the associated redesign costs.
Prototyping Model:
 Advantages:
 Increased user involvement in the product even before
its implementation.
 Since a working model of the system is displayed, the
users get a better understanding of the system
being developed.
 Reduces time and cost as the defects can be detected
much earlier.
 Quicker user feedback is available leading to better
solutions.
 Missing functionality can be identified easily.
 Confusing or difficult functions can be identified.
 Weaknesses
 The prototype model can increase the cost of
development for projects that are routine development
work and do not suffer from any significant risks.
 Even when a project is susceptible to risks, the
prototyping model is effective only for those projects for
which the risks can be identified upfront before the
development starts.
 Since the prototype is constructed only at the start
of the project, the prototyping model is ineffective
for risks identified later during the development
cycle.
Disadvantages:
 Risk of insufficient requirement analysis owing to too
much dependency on the prototype.
 Users may get confused in the prototypes and actual
systems.
 Practically, this methodology may increase the
complexity of the system as scope of the system may
expand beyond original plans.
 Developers may try to reuse the existing prototypes to
build the actual system, even when it is not technically
feasible.
 The effort invested in building prototypes may be too
much if it is not monitored properly
Evolutionary Process Model

Delivery of the next

version to the
customer
 It’s a Combination of Iterative waterfall and
Incremental model of SDLC.
 This model has many of the features of the incremental
model. As in case of the incremental model, the software
is developed over a number of increments.
 Incremental model first implements a few basic features
and delivers to the customers. Then it builds the next
part and delivers it again and this step is repeated until
the desired system is fully realized.
 And Iterative waterfall model’s main advantage is
its feedback process in every phase.
 So At each increment, a concept (feature) is
implemented and is deployed at the client site.
 The software is successively refined and feature-enriched
until the full software is realised.
 The principal idea behind the evolutionary life cycle model is
conveyed by its name. In the incremental development
model, complete requirements are first developed and
the SRS document prepared.
 In contrast, in the evolutionary model, the requirements,
plan, estimates, and solution evolve over the iterations, rather
than fully defined and frozen in a major up-front specification
effort before the development iterations begin.
 Such evolution is consistent with the pattern of unpredictable
feature discovery and feature changes that take place in new
product development.
 Though the evolutionary model can also be viewed as an
extension of the waterfall model, but it incorporates a
major paradigm shift that has been widely adopted in
many recent life cycle models.
 Due to obvious reasons, the evolutionary software
development process is sometimes referred to as design a
little, build a little, test a little, deploy a little model.
 This means that after the requirements have been specified,
the design, build, test, and deployment activities are
iterated.
 Advantages
 Effective elicitation of actual customer requirements:
• In this model, the user gets a chance to experiment with
a partially developed software much before the complete
requirements are developed.
• Therefore, the evolutionary model helps to accurately
elicit user requirements with the help of feedback
obtained on the delivery of different versions of the
software.
• As a result, the change requests after delivery of the
complete software gets substantially reduced.
 Easy handling change requests:
• In this model, handling change requests is easier as no
long term plans are made.
• Consequently, reworks required due to change
requests are normally much smaller compared to the
sequential models.
 Disadvantages
 Feature division into incremental parts can be non-
trivial:
• For many development projects, especially for small-
sized projects, it is difficult to divide the required
features into several parts that can be incrementally
implemented and delivered.
• Further, even for larger problems, often the features
are so interwined and dependent on each other that
even an expert would need considerable effort to plan
the incremental deliveries.
• Ad hoc design:
• Since at a time design for only the current increment
is done, the design can become ad hoc without
specific attention being paid to maintainability and
optimality.
• Obviously, for moderate sized problems and for those
for which the customer requirements are clear, the
iterative waterfall model can yield a better solution.
 Applications
 The evolutionary model is normally useful for very large
products, where it is easier to find modules for incremental
implementation. Often evolutionary model is used when
the customer prefers to receive the product in increments
so that he can start using the different features as and when
they are delivered rather than waiting all the time for the
full product to be developed and delivered.
 Another important category of projects for which the
evolutionary model is suitable, is projects using object-
oriented development since it is easy to partition the
software into stand alone units in terms of the classes.
Also, classes are more or less self contained units that can
be developed independently.
• Obviously, for moderate sized problems and for those for
which the customer requirements are clear, the iterative
waterfall model can yield a better solution.
THANK YOU