In this lesson we are going to learn about spiral model

that takes a very different approach to software development.

It's a risk-driven approach, as you will see.

So let's see how it looks like.

So when you first look at it you can have, like,

whatever you have seen so far,

it's either linear or a two dimensional,

but this one is cyclic.

So you go in cycles and then you keep improving or iterating.

So it's a cyclic process but each of those cycle actually has four basic steps.

So you determine the objectives as your first step,

like what do you want to achieve in that particular cycle.

Then you identify and resolve risks,

and then you double up based on what you need for your objectives.

And then you plan for next iteration.

So that's kind of the basic idea behind each of these cycles.

And then the last one is that if you look at this diagram it

may overwhelm you with so many steps and so many things to do,

but not every single step or activity needs to be performed.

It depends on, so just basically it's just an idea as you

will see later that it's just a concept.

But then, based on the project or the product that you're working on,

you select what to do and not to do and maybe do something different.

But, basically, you do these steps of one, two, three,

four and then you go in a cyclic manner and you try to reduce

your risks as you do more and more cycles.

So let's go through the steps one by one.

So the first one is, determine objectives.

So, of course, in this step you

define what exactly would be the objective for this cycle.

And then you have to talk to all of your stakeholders so that it

meets the need of all the stakeholders.

And, at the same time, you define what are

the constraints to achieve those objectives in that cycle.

So it could be your industry-specific constraint,

like you must meet this regulation,

or it could be a cost,

it could be a time.

Whatever constraints you want to put to meet those objectives,

are defined in the step number one.

And then you also talk about what are the alternatives possible in that step.

What are the alternative ways to achieve your objectives?

So those are the things that you talk about in the step number one,

or this is what you do in step number one.

Then it comes to step number two which is,

the identifying and resolving risk.

And so the whole step is primarily focused on risk, what can go wrong.

And then not only just identify,

but then find ways to mitigate or do something about those risks.

So sometimes you might be building a prototype or an operational prototype in the end,

or you might be doing some surveys or whatever you need to do, or some research,

but you try to identify what other things

can go wrong and then you try to resolve what you can.

Then comes the step number three where you actually,

once you have resolved most of the risk,

I'm assuming some of the risks may not be resolved,

but then you can do this step number three

where you do the actual work to meet your objectives.

In this case, if you're doing a feasibility study then you do your feasibility study,

or if you're doing requirements,

then you write those and so on.

And if you're doing actual development then you go through

the design code integration and the result.

So whatever is the objective of that cycle,

the work needed to be done to achieve that objective is done here.

And then the last is to plan the next iteration.

So this is the step where you review the work done in this cycle and then,

you say, should we continue or should we not continue.

And if you want to continue,

then you decide, okay,

what will be the goal for the next iteration.

So a commitment for moving forward is done in the step number four.

And then you just start with the next cycle.

Right. So we just keep on cycling into this spiral.

So you may ask the question like,

how do you track progress,

do you just keep on going around, around, around?

Actually, it defines three kind of milestones.

And, of course, you can exit at any time but to track

the progress on a spiral project you can use these three milestones.

The first one is called lifecycle objective where we have

the sufficient definition of technical and management approach.

So, we know what is it that we're trying to do.

So, as long as the commitment or the consensus is there on

the objective then that goal is achieved or milestone is achieved.

The next one is the lifecycle architecture where we

have sufficient definition of the approach that we are going to take.

And then all the risks are eliminated or mitigated.

So, once you achieve that,

then you have that milestone down on.

So you can say, oh my spiral project has achieved,

is in that stage.

Or the last one is the initial operational capability when there is

a sufficient operation of the software site and user, and operators,

and maintainers to release the software to the team,

or to the market,

or to your users.So that's when you achieve the third milestone.

So let's talk about some of the characteristics of this model.

As you can see, that this model gives a lot and lot of emphasis on the risks.

So you identify and resolve risk as primary step of this process.

The next one is that the effort and the detail are driven by the risk.

So, let's say, if you're in this step,

the main goal is to validate something,

validate a concept, or validate the feasibility of it and you're

doing some kind of prototype or some kind of software development activity.

So you don't need to go through

a rigorous requirements documents or a very detailed document.

You just do enough so that the goal or objective is achieved.

So, again, how much is the risk based on that you put

effort in terms of resolving the risk as well as in the development and the test stage.

Whatever you're trying to do based on the risk,

you determine how much effort you're going to put.

Another attribute of this model is that it's not really a

very defined or a step by step process but it is a process model generator.

So you actually use other models wherever appropriate to execute.

So, for example, in the development and test approach you could be using

a waterfall or you could be using any of those software development model to execute.

And, similarly, in other phases you might be using some other techniques.

So it's a process model generator,

not a process itself.

So in summary, it

was first described in 1980 and 1986 by Barry Boehm as a process model generator.

It's a risk driven.

It has four basic activities in every cycle.

The risk determines the level of effort and the degree of details.

And then not every activity in the diagram needs to be performed.

So in terms of the cycle or,

like, the predictive versus adaptive scale,

I would say it's very much on the adaptive cycle because in every cycle

you look at what you have done and then you can

adapt to what is the next goal or what do you want to achieve next.

So it's very much on the adaptive side.

In terms of pros and cons,

as you can see, it's very adaptive,

you can change in every cycle the direction where you're going.

The focus on the risk increases the chance of success of your product.

And then you have this flexibility of using any software development model.

It also minimizes waste because it talks about how you don't need to go

through all this every single step in the same rigor but,

based on the risk,

you define how much effort you want to put.

And then there is this option of go,

no-go in every cycle and move forward.

So it kind of allows you that check in on a regular basis to make sure

that you're still going to get the ROI that you're hoping to get.

In terms of cons, again,

this is a very complicated model,

it definitely cost more to manage.

And then it needs

the stakeholder engagement because after every cycle or during every cycle,

you need a lot of or bit of engagement from your key stakeholders.

So where do you use this model?

Well, if it is a very large high risk project, I think,

a spiral model would be a good fit for those kind of projects.

Spiral Model

Software Development Processes and Methodologies

Meet the Instructors