Prototyping and Spiral: Life Cycle Models

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

Prototyping and Spiral

Life Cycle Models


Specific Instructional Objectives
At the end of this lesson the student will be able to:

Explain what a prototype is.


Explain why and when a prototype needs to be developed during software
development.
Identify the situations in which one would prefer to build a prototype.
State the activities carried out during each phase of a spiral model.
Identify circumstances under which spiral model should be used for
software development.
Tailor a development process to a specific project.

Prototype
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
customers needs:

how the screens might look like


how the user interface would behave
how the system would produce outputs

This is something similar to what the architectural designers of a building do; they
show a prototype of the building to their customer. The customer can evaluate
whether he likes it or not and the changes that he would need in the actual
product. A similar thing happens in the case of a software product and its
prototyping model.

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.

Examples for prototype model


A prototype of the actual product is preferred in situations such as:

user requirements are not complete


technical issues are not clear

Lets see an example for each of the above category.

Example 1: User requirements are not complete


In any application software like billing in a retail shop, accounting in
a firm, etc the users of the software are not clear about the different
functionalities required. Once they are provided with the prototype
implementation, they can try to use it and find out the missing
functionalities.
Example 2: Technical issues are not clear
Suppose a project involves writing a compiler and the development
team has never written a compiler.
In such a case, the team can consider a simple language, try to
build a compiler in order to check the issues that arise in the process and
resolve them. After successfully building a small compiler (prototype), they
would extend it to one that supports a complete language.

Spiral model
The Spiral model of software development is shown in fig. 2.2. 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. 2.2. The following activities are carried out
during each phase of a spiral model.
-

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.

Fig. 2.2: Spiral Model

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.

Circumstances 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 can not 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 object-oriented 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
customers 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 customers 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.

What is Incremental model- advantages, disadvantages and when


to use it?
In incremental model the whole requirement is divided into various builds.
Multiple development cycles take place here, making the life cycle a multiwaterfall cycle. Cycles are divided up into smaller, more easily managed
modules.
Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced
during the first module, so you have working software early on during the
software life cycle. Each subsequent release of the module adds function to the
previous release. The process continues till the complete system is achieved.

In the diagram above when we work incrementally we are adding piece by piece
but expect that each piece is fully finished. Thus keep on adding the pieces until
its complete. As in the image above a person has thought of the application.
Then he started building it and in the first iteration the first module of the
application or product is totally ready and can be demoed to the customers.
Likewise in the second iteration the other module is ready and integrated with the
first module. Similarly, in the third iteration the whole product is ready and
integrated. Hence, the product got ready step by step.

Advantages of Incremental model:

Generates working software quickly and early during the software life cycle.
This model is more flexible less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during itd
iteration.
Disadvantages of Incremental model:

Needs good planning and design.


Needs a clear and complete definition of the whole system before it can be broken
down and built incrementally.

Total cost is higher than waterfall.


When to use the Incremental model:

This model can be used when the requirements of the complete system are clearly
defined and understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available
There are some high risk features and go

You might also like