LECTURE II

SEN 2
PROTOYPING MODEL

 A prototype is a toy implementation of the system. A prototype usually

exhibits limited functional capabilities, low reliability, and inefficient
performance compared to the actual software.
 A prototype is usually built using several shortcuts. The shortcuts might
involve using inefficient, inaccurate, or dummy functions. The shortcut
implementation of a function, for example, may produce the desired
results by using a table look-up instead of performing the actual
computations.
 A prototype usually turns out to be a very crude version of the actual
system.
 Need for a prototype in software development

 There are several uses of a prototype. An important purpose is to illustrate the
input data formats, messages, reports, and the interactive dialogues to the
customer. This is a valuable mechanism for gaining better understanding of
the customer’s needs:
 how the screens might look like
 how the user interface would behave
 how the system would produce outputs


 Another reason for developing a prototype is that it is impossible to get
the perfect product in the first attempt. Many researchers and engineers
advocate that if you want to develop a good product you must plan to
throw away the first version. The experience gained in developing the
prototype can be used to develop the final product.
 A prototyping model can be used when technical solutions are unclear to
the development team. A developed prototype can help engineers to
critically examine the technical issues associated with the product
development. Often, major design decisions depend on issues like the
response time of a hardware controller, or the efficiency of a sorting
algorithm, etc. In such circumstances, a prototype may be the best or
the only way to resolve the technical issues.
 A prototype of the actual product is preferred in situations such as:
 User requirements are not complete
 Technical issues are not clear

Fig : Prototype Model
3.2
EVOLUTIONARY MODEL

 It is also called successive versions model or incremental model. At first,

a simple working model is built. Subsequently it undergoes functional
improvements & we keep on adding new functions till the desired
system is built.

 Applications:
 Large projects where you can easily find modules for incremental
implementation. Often used when the customer wants to start using the core
features rather than waiting for the full software.
 Also used in object oriented software development because the system can
be easily portioned into units in terms of objects.
 Advantages:
 User gets a chance to experiment partially developed system
 Reduce the error because the core modules get tested thoroughly.
 Disadvantages:
 It is difficult to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented &
delivered.
Fig 3.3 : Evolutionary Model
SPIRAL MODEL

 The Spiral model of software development is shown in fig. 4.1. The

diagrammatic representation of this model appears like a spiral with
many loops. The exact number of loops in the spiral is not fixed. Each
loop of the spiral represents a phase of the software process. For
example, the innermost loop might be concerned with feasibility study,
the next loop with requirements specification, the next one with design,
and so on. Each phase in this model is split into four sectors (or
quadrants) as shown in fig. 4.1. The following activities are carried out
during each phase of a spiral model.
Fig 4 : Spiral Model
.
1
 First quadrant (Objective Setting)
 During the first quadrant, it is needed to identify the objectives of the phase.
 Examine the risks associated with these objectives.

 Second Quadrant (Risk Assessment and Reduction)

 A detailed analysis is carried out for each identified project risk.
 Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
 Third Quadrant (Development and Validation)
 Develop and validate the next level of the product after resolving the
identified risks.
 Fourth Quadrant (Review and Planning)
 Review the results achieved so far with the customer and plan the next iteration
around the spiral.
 Progressively more complete version of the software gets built with each iteration
around the spiral.
 When to use spiral model

 The spiral model is called a meta model since it encompasses all other
life cycle models. Risk handling is inherently built into this model. The
spiral model is suitable for development of technically challenging
software products that are prone to several kinds of risks. However, this
model is much more complex than the other models – this is probably a
factor deterring its use in ordinary projects.
 Comparison of different life-cycle models

 The classical waterfall model can be considered as the basic model and
all other life cycle models as embellishments of this model. However,
the classical waterfall model cannot be used in practical development
projects, since this model supports no mechanism to handle the errors
committed during any of the phases.

 This problem is overcome in the iterative waterfall model. The iterative
waterfall model is probably the most widely used software development
model evolved so far. This model is simple to understand and use.
However this model is suitable only for well-understood problems; it is
not suitable for very large projects and for projects that are subject to
many risks.

 The prototyping model is suitable for projects for which either the user
requirements or the underlying technical aspects are not well understood.
This model is especially popular for development of the user-interface part
of the projects.

 The evolutionary approach is suitable for large problems which can be
decomposed into a set of modules for incremental development and
delivery. This model is also widely used for objectoriented development
projects. Of course, this model can only be used if the incremental delivery
of the system is acceptable to the customer.

 The spiral model is called a meta model since it encompasses all other life
cycle models. Risk handling is inherently built into this model. The spiral
model is suitable for development of technically challenging software
products that are prone to several kinds of risks. However, this model is
much more complex than the other models – this is probably a factor
deterring its use in ordinary projects.
 The different software life cycle models can be compared from the
viewpoint of the customer. Initially, customer confidence in the
development team is usually high irrespective of the development model
followed.
 During the lengthy development process, customer confidence normally
drops off, as no working product is immediately visible. Developers answer
customer queries using technical slang, and delays are announced. This
gives rise to customer resentment.
 On the other hand, an evolutionary approach lets the customer experiment
with a working product much earlier than the monolithic approaches.
 Another important advantage of the incremental model is that it reduces
the customer’s trauma of getting used to an entirely new system. The
gradual introduction of the product via incremental phases provides time to
the customer to adjust to the new product.
 Also, from the customer’s financial viewpoint, incremental development
does not require a large upfront capital outlay. The customer can order the
incremental versions as and when he can afford them.