Spiral Model
In spiral model the project will be in parts.
The process
begins at the center position. From there it moves clockwise in traversals.
Each traversal of the spiral usually results in a deliverable. It is not
clearly defined what this deliverable is. This changes from traversal to
traversal. For example, the first traversals may result in a requirement
specification. The second will result in a prototype, and the next one will
result in another prototype or sample of a product, until the last traversal
leads to a product which is suitable to be sold. Consequently the related
activities and their documentation will also mature towards the outer
traversals. E.g. a formal design and testing session would be placed into the
last traversal.
These regions are:
§ The planning task - to define resources,
responsibilities, milestones and schedules.
§ The goal determination task - to define
the requirements and constraints for the product and define possible alternatives.
§ The risk analysis task - to assess both
technical and management risks.
§ The engineering task - to design and
implement one or more prototypes or samples of the application
The most outstanding distinction
between the spiral model and other software models is the explicit risk
evaluation task. Although risk management is part of the other processes as
well, it does not have an own representation in the process model. For other
models the risk assessment is a sub-task e.g. of the overall planning and
management. Further there are no fixed phases for requirements specification,
design or testing in the spiral model. Prototyping may be used to find and
define requirements. This may then be followed by "normal" phases as
they can be found in other process models to handle design and testing.
The advantages of
the spiral model are that it reflects the development approach in many
industries much better than the other process models do. It uses a step-wise
approach which e.g. goes hand in hand with the habit of maintaining a number of
hardware sample phases in cases where the product to be produced is not only
software for a given environment, but also contains the development of hardware.
This way the developers and the customer can understand and react much better
to risks in the evolutionary process. By having an iterative process which
reduces formalism and omit-table activities in the earlier phases the use of
resources is optimized. Further, any risks should be detected much earlier than
in other process models and measures can be taken to handle them.
The disadvantages of the spiral model are that the risk assessment is rigidly anchored in the process. First of all it demands risk-assessment expertise to perform this task and secondly in some cases the risk assessment may not be necessary in this detail. For completely new products the risk assessment makes sense. But I dare to say that the risks for programming yet another book keeping package are well known and do not need a big assessment phase. Also if you think of the multitude of carry over projects in many industries i.e. applying an already developed product to the needs of a new customer by small changes, the risks are not a subject generating big headaches. Generally speaking the spiral model is not much esteemed
The disadvantages of the spiral model are that the risk assessment is rigidly anchored in the process. First of all it demands risk-assessment expertise to perform this task and secondly in some cases the risk assessment may not be necessary in this detail. For completely new products the risk assessment makes sense. But I dare to say that the risks for programming yet another book keeping package are well known and do not need a big assessment phase. Also if you think of the multitude of carry over projects in many industries i.e. applying an already developed product to the needs of a new customer by small changes, the risks are not a subject generating big headaches. Generally speaking the spiral model is not much esteemed
E.g. if 1st application is developed it will tested and sent
to client. This is suitable for very large project.
Advantages:-
1. Requirements are updated.
2. If changes made in one module it not affects the other
module.
3. There will be better understanding between client and
company.
4. There will be better quality.
Disadvantages:-
1. Requirements are not tested.
2. Design is not tested.
3. Root course analysis.
4. Cost of fixing the defect s high.
You May also like:
Testing basic interview questions
