Introduction - The Spiral Model
Introduction - The Spiral Model
(1)
Quadrant 1 Quadrant 2
(2)
(2)
Quadrant 4 Quadrant 3
1.2 The main concept of spiral model :
1. a project undergoes a large number of cycles (loop), starting with a small prototype.
2. each loop of the spiral follows a mini-waterfall process.
3. before each cycle of the spiral ends, a review is held.
4. subsequent cycles become official releases.
5. the cycling only ends when the system is finally retired
The spiral model suggests that the first thing to do before embarking on each new loop of
the spiral is to decide what are the major difficulties to be handled are. A key feature of the
model is that each cycle of the spiral is completed by a review, which covers all the products
developed during that cycle, including plans for the next cycle. The Spiral model is a risk-driven
approach that is develop from the evolution of the Waterfall Model and can make use of a
combination of models as necessary until a high risk situation is resolved. The models include
Specification-oriented (Transform or Stagewise), Prototype-oriented (Waterfall), Automatic-
transformation oriented (Transform), Simulation-oriented (Evolutionary).
Besides that, the Spiral Model provides a rapid development and at the same time,
incremental versions of the software application. It is iterative, but each repetition is designed to
reduce the risk at that particular stage of the project. The spiral model works for developed as
well as enhancement projects. Therefore, the Spiral Model is the best of both top down and
bottom up approaches.
The spiral is oriented towards software development which the concept is similarly applicable to
systems, hardware and training. This development contains four quadrants:
Evaluate alternatives, that best satisfy technical, technology, cost, schedule, support,
identify, resolve risks. and risk constraints. The main focus here is risk mitigation. Each
options are investigated and prototyped to decrease risks
associated with the development decisions.
Develop, verify, next-level when a determination is made that the previous prototyping
Plan next phases. technical review that assesses the status, progress, maturity,
merits, and risk of development efforts to date which resolves
operational or technical issues and reviews plans and identifies
the issues to be resolved for the next iteration of the spiral. This
model has characteristic similar to all model which is the need for
advanced technical planning and multidisciplinary reviews at
critical staging or control points.
2.1 Advantage 1
The main advantage of the spiral model is that its variety of options accommodates the good
features of presented software procedure models, while its risk-driven come close to avoids
various of their difficulties. The spiral model can be treated as any of the on hand model such as
the waterfall model in certain condition. Besides that, it provides guidance on the superlative mix
of existing approaches to a given project. For example, a risk-driven mix of specifying,
prototyping and evolutionary development is provided. Once certain risk areas are removed at a
stage, other models can replace the Spiral model.
The main circumstances under which the spiral model becomes corresponding to other
main process models are summarized as:-
1. Getting the wrong user interface or not meeting rigid performance requirements will
occurred if the project is in low riskand if it has a high risk in budget and schedule
expectedness and control, then these risk considerations drive the spiral model into
correspondence to the waterfall model.
2. Implying a low risk of expensive design and code breakage due to requirements changes
during development or in the other hands if a software product’s requirements are very
steady and if the existence of errors in the software product constitutes a high risk to the
task it serves then these risk considerations drive the spiral model to bear a resemblance to
the two-legged model of accurate specification and formal faulty program development.
(The two-legged model actually is a model that allows an application to grant access to
another via either a shared secret key (examples: Amazon's Web Service model, you will use
the HMAC-SHA1 signing method) or via public/private key system by using a signing
method (examples: Amazon's Web Service model, you will use the RSA-SHA1.)
3. If a project has a low risk in such areas as losing budget and schedule expectedness and
control, encountering large-system assimilation problems or coping with information
sclerosis. If it has a high risk in such areas as getting the incorrect user decision support
requirements, then these risk considerations drove the spiral model into ancorrespondence
to the evolutionary development model.
( Evolutionary development model is a software development method that has become
quite popular and also known as Evolutionary Development or EVO. EVO uses small,
incremental product releases, frequent delivery to users and dynamic plans and processes.
Besides that, EVO is simply relatively simple in concept. Implementation of EVO has also
included both significant challenges and notable benefits.)
4. If automated software generation capabilities are accessible, then the spiral model
accommodates them either as options for swift prototyping or for the application of the
make over model, depending on the risk consideration concerned.
5. If the high risk elements of a project involve a mix of the risk items listed, then the spiral
approach will replicate a suitable mix of the process model. At the same time, its risk
prevention features will generally avoid the difficulties of the other models.
6. It focuses early awareness on options involving the reclaim of presented software. The
steps involving the recognition and assessment of alternatives support these options.
2.1 Advantage 2
The advantages of using the spiral model are varied. The primary advantage of spiral
model is it’s flexible design that allows changes to be implemented at several stages of the
project. For example, the process of building up large systems in small segments makes it easier
to do cost calculations and the client will be involved in the development of each segment,
retains control over the direction and implementation of the project. In addition, the client's
knowledge of the project grows as the project grows, so that they can interface effectively with
management. The realistic approach of spiral model to the development of the software evolves
as the process progresses. In addition, the developer and the client better understand and react to
risks at each evolutionary level.
The Spiral Modal can be applied in many situations, but in order to be called a mature and
universally applicable model, some issues must be overcome. There are 2 major setbacks of the
spiral modal, which are relying on risk-assessment expertise and the need for formal guidelines
on the steps spiral model.
3.1 Disadvantage 1
One of the disadvantages is that the spiral model is relying on risk-assessment expertise
heavily. The Spiral Modal places a great deal of reliance on the ability of software developers to
identify and manage sources of project risk (risk-driven specification). A simple example is the
spiral model’s risk-driven specification, which carries high-risk element that will be drawn down
to details and leaves low-risk element to be developed develop at a later stage. Unfortunately,
there is several risk of breakage. A group low-balling developers may produce a very good
description of detail on low risk factors (which is well-understood), but unable to describe the
high-risk factors (which is poorly-understood). This may create confusion and a wrong
impression to the progress the period of time in recognizing the risks and managing the risk. This
setback can be overcome by having an insightful review of such a benchmark set by experienced
development or acquisition personnel. Another concern is that a risk-driven specification can be
very people-dependent. An example can be drawn from a situation where by non-experts
implementing a design produced by the experts, who does not need a great deal of particulars
documentation. The experts must produce a complete documentation with sufficient information
to keep the non-experts on the correct path of implementing the design. It also creates a large
drain on the time of the scarce experts, who must dig for the critical issues within a large mass of
non-critical particulars. Furthermore, if the high-risk factors have been varnished over by
impressive-sounding references to poorly understood capabilities (such as a new synchronization
concept or a commercial Database Management System), there is an even greater risk that the
common approach will give the wrong impression to progress in situations that are actually
heading for disaster. With a common, document-driven approach, the requirement to carry all
aspects of the specification to a uniform level of detail to clear up some potential problems and
permit appropriate review of some aspects inexperienced reviewers.
3.2 Disadvantage 2
The second disadvantages are the need for formal guidelines on the steps in the spiral
model. In general, the spiral model process steps need formal guidelines to ensure that all
software development participants are operating under a consistent context. Some examples of
this are the need for more detailed definitions of the nature of spiral model specifications and
landmark, the nature and objectives of spiral model reviews, techniques for estimating and
synchronizing schedules, and the nature of spiral model status indicators and cost-versus-
progress tracking procedures. Another need is to identify project risk and the most effective
resolution techniques for each source of risk. In large-scale project where people bring widely
differing experience bases to the project should have documentation on the different levels of
development that have been accumulated over the years. This document-driven approach is
important in ensuring consistent explanation and use of the spiral model across the project.
Efforts to implement and improve the spiral model should focus on creating a discipline and
organized software risk management, including techniques for risk identification, risk analysis,
risk prioritization, risk management planning , and risk-factors tracking,