Spiral Model

What is the Spiral Model?

The Spiral Model was first introduced in a paper titled “A Spiral Model of Software Development and Enhancement” in 1986 written by Barry Boehm who was an American software engineer. Later on in 1988 he published a similar paper to a wider audience.

The model was not the first model to discuss iterative development, however it was the first model to explain why iteration matters.

In later publications, Boehm describes the Spiral Model as a “process model generator”, where choices based on a project’s risks generate an appropriate process model for the project. Therefore making such methodologies like prototyping and Waterfall etc. are special cases of the Spiral Model that fit the risk patterns of certain projects. To differentiate this Spiral Model from other “hazardous spiral look alikes” Barry Boehm had created a list of six characteristics common to all authentic application of the Spiral Model.

The “hazardous spiral look alikes” refers to the misconceptions that had risen from the original Spiral Model, these misconceptions are:

• The spiral is a sequence of Waterfall increments
• All project activities will follow a single spiral sequence
• Every activity in the diagram must be performed in the order shown

The Spiral Model is a systems development lifecycle (SDLC) method, just like many other methods, such as Rapid Application Development, that is used for risk management that combines the iterative development model with elements of the Waterfall Model. The Spiral Model is generally favoured for large scale, expensive, and complicated projects.

The Spiral Model is considered to be a risk driven software development process. Diagrammatically, the model looks like a spiral with many loops, however the number of loops of the spiral is unknown and can vary from project to project.

Each loop within the spiral is referred to as a “phase” of the software development process. The number of phases also depends on the project and will ultimately depend on the project manager as the risks are evaluated, therefore making the project managers job to develop the product that is required using the spiral.

The radius of the circle at any point will represent the cost of the project so far, moreover, the angular dimension represents the progress made so far in the current phase.

Therefore in a nutshell the Spiral Model can be described to be similar to incremental development for a system, but with more emphasis on risk analysis.

Six Invariants of the Spiral Model

Any authentic application that uses the Spiral Model are driven by cycles that will ultimately display six characteristics. Barry Boehm describes these characterises with an example of a “dangerous spiral look alike” that will violate the invariant.

Define artefacts concurrently:

Defining the key artefacts sequentially for a project will often lower the possibility of developing a system that meets the clients “win conditions” (which are there objectives and constraints)

The invariant excludes “hazardous spiral look-alike” process that will use a sequence of incremental Waterfall passes in areas where the underlying assumptions of the Waterfall Model do not apply.

The following assumptions are:

1. Requirements are known in advance, i.e. before the implementation starts.
2. Requirements do not have an unresolved, high-risk implications, for instance risks that may be due to cost, performance, schedule, user interface, safety, and organisational impacts etc.
3. The nature of the requirements do not change drastically during development of the system.
4. The requirements produced are inline and accepted by the client(s) expectations, as-well as user, customer, developer maintainers, and investors point of view.
5. The correct architecture for implementing the requirements is well understood.
6. There is enough calendar time to proceed sequentially.

In some situations where these assumptions may apply, it will be considered to be a project risk if the requirements and objectives are not provided, and the system is proceeding sequentially. Therefore, the Waterfall Model will then become a risk driven special case of the Spiral Model. 

Perform four basic activities in every cycle:

The invariant portrays four actives that must occur in each cycle of the Spiral Model:

1. Consider the “win conditions” of all success critical clients.
2. Identify and evaluate other methods for accomplishing win conditions.
3. Identify and resolve risks that stem from the selected approach(es).
4. Obtain approval from the client that what had been created was a success, and the ensure to obtain commitment to pursue the next cycle.

The “hazardous spiral look-alike” processes violate this invariant by not including the client from certain phases in the cycle. For instance, system admin or maintainers may not be told to participate in the definition and development of the system. This will inevitably result in risking the system to failure to satisfy their “win conditions”.

Risk determines level of effort:

In any project activity for instance: requirements analysis, design, prototyping, or testing, the team must decide how much effort is required to fulfil the requirements in those phases. In the authentic spiral process, these decisions are made by minimising the overall risk.

Additional testing for a system might increase the risk of a competitor early market entry. Though from a Spiral Model point of view, testing should only be performed until the total risk is minimised.

“Hazardous spiral look-alike” will ignore risks due to scalability issues, resulting in a redesign of certain aspects or aspects being replaced in future increments of the product.

Risk determines degree of details:

In any project artefact for instance: requirements specification, design document, or a test plan, the project team must evaluate how much detail is satisfactory for the project.

For example, if we consider “requirements specification”, the project should precisely specify those features where the risk is reduced through precise specification, for example, interfaces between hardware and software.

However on the other hand, the project should not specify those features where precise specification will increase the risk, for instance graphical screen layouts. 

Use anchor point milestones:

During later refinements of the specification Bohem had introduced three anchor point milestones that will serve as progress indicators and points of commitment.

The anchor points that he produced can be characterised by key questions.

• Life Cycle Objectives. The questions was: Is there a sufficient definition of a technical and management approach to satisfying everyone’s win conditions?

If the client(s) agree that the answer to the questions is “Yes”, then the project has cleared this “life cycle objectives” (LCO) milestone. Otherwise, the project can be abandoned, or the client(s) can commit to another cycle to try to get to a positive result they desire.

• Life Cycle Architecture. The questions was:  Is there a sufficient definition of the preferred approach to satisfying everyone’s win conditions, and are all significant risks eliminated or mitigated?

If the client(s) agree that the answer is “Yes”, then the project has cleared this “life cycle assessment” (LCA) milestone. Otherwise, the project can be abandoned, or the client(s) can commit to another cycle to try to get to try to get to a positive result they desire.

• Initial Operational Capability. The questions was: Is there sufficient preparation of the software, site, users, operators, and maintainers to satisfy everyone’s win conditions by launching the system?

If the stakeholders agree that the answer is “Yes”, then the project has cleared the “initial operational capability” (IOC) milestone and is launched. Otherwise, the project can be abandoned, or the client(s) can commit to another cycle to try to get to try to get to a positive result they desire.

“Hazardous spiral look-alikes” that violate this invariant will include incremental processes that commit significant resources to achieving a solution with a weak architectural base.

Focus on the system and its life cycle:

This invariant showcases the need and importance of the overall system and the long-term concerns throughout its entire life cycle.

It excludes “hazardous spiral look-alikes” that focus too much on initial development of software code.

This can result in following approaches that are widely published etc. while neglecting other aspects of the projects process needs.

Phases involved in the Spiral Model

The Spiral Model can be broken down into four main phases. Usually a project will pass through these phases in every iteration, these are referred to as “Spirals”.

Identification:

The identification phase is initiated by collected all the business requirements in the baseline spiral.

In the following spirals, as the product becomes more mature (i.e. becomes more developed), identification of the system requirements, subsystem requirements, and unit requirements are all completed in this phase.

This phase also includes understanding the system requirements by a constant flow of communication between the customer and the system analyst. Then at the end of the spiral, the product is deployed in the market that it was designated to be marketed at.

Design:

The design phase will start at the baseline spiral with a conceptual design, this will involve architectural design, logical design of models, physical product design, and the final design in the following spirals.

Construct/Build:

The construct phase is where the production of the actual software product at every serial occurs. As mentioned above, the baseline spiral is where the “Proof of Concept” is developed, and customer feedback is obtained at this stage.

When a cleaner clarity on the requirements and design details is obtained in later spirals, a working model of the software is produced that is referred to as a “build”, this build is produced with a version number, and are sent to the client for feedback.

Evaluation and Risk Analysis:

This phase includes risk analysis, which subsequently also includes identifying, estimating, and monitoring the technical feasibility and management risks, such as schedule slippage, and cost overrun.

Like with other methodologies, the client provides feedback after builds are completed, therefore, once the build is tested at the end of the first iteration, the customer will evaluate the software and provide feedback necessary to the developers.

Based on the clients feedback and evaluation of the product, the software development process will then enter the next iteration and it will follow the linear approach to incorporate the feedback that the customer had provided. The process of iterations along the spiral will continue throughout the life of the software.

When to use the Spiral Model?

The Spiral Model is a widely used methodology in the software industry, this is due to the fact that it is in sync with the natural development process of any product, for instance, learning with maturity: which involves minimum risk for the client as well as the development team.

The following pointers explain some of the uses of a Spiral Model:

• When there is a budget constraint on the project and the risk evaluation is important.
• For projects that are medium-high risk.
• Projects that are long-term committed, due to potential changes in economic priorities as the requirements may change with time.
• The client is not usually 100% sure of the requirements at the very beginning.
• The requirements are complex and require thorough evaluation to get proper clarity.
• A new product line that should be released in phases to obtain enough customer feedback to implement any changes in the following release.
• Significant changes to the product are expected during the development life cycle.

Advantages of the Spiral Model

Flexibility:

Any feedback from the client that results in changes to be made to the system can be easily adopted and implemented.

Risk handling:

The Spiral Model revolves around risk analysis, hence it involves risk analysis in every phase. By doing so, it improves security and the chances of avoiding attacks/breakages allowing the system to become vulnerable. Moreover, the iterative development process also facilitates risk management.

Customer satisfaction:

The Spiral Model allows for customer feedback, therefore allowing the client to provide feedback after each phase after their evaluation.

This feature allows customers to voice out any issues they have with the product or any new features/changes they would like to have done into their product before being released into the market.

Disadvantages of the Spiral Model

High cost:

The Spiral model is regarded to be expensive and therefore is not suitable for small projects.

Dependence on risk analysis:

It is essential for personnel to have expertise in risk assessment, since successful completion of the project depends on effect risk handling.

Complexity:

In terms of complexity, the Spiral Model is one of the most complex methodologies compared with other SDLC options. Therefore meaning that for it to operate productively and efficiently, protocols must be followed closely and strictly.

Hard to manage time:

When starting out a project, establishing the number of required phases is often difficult, therefore making time management almost impossible. All of this means that there is always a risk for falling behind schedule or even possibly going over budget.

More documentation:

There is more documentation required when applying the Spiral model as the model involves intermediate phases.

Difference between Waterfall and Spiral

Waterfall Model	Spiral model
Waterfall Model works in a sequential way	Spiral works in an evolutionary way
Errors/risks are identified and rectified after the completions of stages	Errors/risks are identified and rectified earlier (after each iteration)
Adopted by customers	Adopted by developers
Applicable for small projects	Applicable for large projects
Requirements and early stage planning is necessary	Requirements and early stage planning is necessary is not required to the same extent as Waterfall. Meaning, there isn’t as much emphasis on it
Flexibility to change/amend aspects is difficult	Flexibility to change/amend aspects is allowed in the Spiral Model and isn’t as hard compared to Waterfall
High amount of risk	Lower amount of risk
Comparatively inexpensive (although if an error is identified at the very end, it may be very expensive or even allow the project to get abandoned)	Comparatively the Spiral model is expensive

Summary and Facts

What is the Spiral Model?

The Spiral Model is a systems development lifecycle (SDLC) method, just like many other methods, such as Rapid Application Development, that is used for risk management that combines the iterative development model with elements of the Waterfall Model. The Spiral Model is generally favoured for large scale, expensive, and complicated projects.

Phases involved in the Spiral Model:

• Identification
• Design
• Construct/Build
• Evaluation and Risk Analysis

Advantages and Disadvantages of the Spiral Model:

Advantages	Disadvantages
Additional functionality or changes can be done at a later stage	Risk of not meeting the schedule or not complying to the budget that was set out at the beginning
Prototype building is done in small fragments, therefore allowing cost estimation of the project to be more straightforward	It works best for large projects, the groups must also have risk assessment expertise
Continuous or repeated development aid risk management	For its smooth operation, this model has to be followed very strictly
Development occurs in a faster manner, and the fractures are added in a systematic way	Due to having more intermediate phases, this requires more documentation
Always room for customer feedback	It is not recommended for smaller projects, as it might cost them extra

References:

1. https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm
2. https://searchsoftwarequality.techtarget.com/definition/spiral-model
3. https://economictimes.indiatimes.com/definition/spiral-model
4. https://en.wikipedia.org/wiki/Spiral_model#The_six_invariants_of_spiral_model
5. https://www.geeksforgeeks.org/software-engineering-spiral-model/
6. https://www.guru99.com/what-is-spiral-model-when-to-use-advantages-disadvantages.html
7. https://www.softwaretestinghelp.com/spiral-model-what-is-sdlc-spiral-model/
8. https://binaryterms.com/spiral-model.html#PhasesofSpiralModel
9. https://www.geeksforgeeks.org/advantages-and-disadvantages-of-using-spiral-model/#:~:text=Software%20is%20produced%20early%20in,risk%20handling%20at%20every%20phase.&text=It%20is%20suitable%20for%20high,business%20needs%20may%20be%20unstable.
10. https://www.geeksforgeeks.org/difference-between-waterfall-model-and-spiral-model/#:~:text=Both%20the%20models%2C%20Waterfall%20model,it%20follows%20the%20evolutionary%20way.