Spiral Model In Software Engineering Case Study
The need for new development processes becomes apparent as the complexity and cost of developing software systems increase. Many processes have evolved that attempt to improve upon the weaknesses of the traditional waterfall model. One such process is Barry Boehm's spiral model of software development. This risk-driven process uses prototyping and customer evaluation to address problems associated with defining system requirements and incorporating improved design alternatives. This paper describes an application of the spiral model used by a team of software engineering graduate students at Texas Christian University (TCU). The team used this process as part of a two semester software engineering course in which a communications simulator was built. As previous discussions of spiral model implementations have focused on large projects, this discussion will focus on applying the model in a small project setting and will offer refinements to the model at large. This paper discusses methods for handling product specifications and milestones in the spiral model and discusses why and how the model was used. Difficulties with applying the spiral model are presented along with conclusions drawn from the experience. © 1996 by John Wiley & Sons Ltd and Gauthier-Villars
Spiral Model is not so well-known as other SDLC (Software Development Life Cycle) models such as Scrum or Kanban, for example. And here’s the reason. Spiral Model can be pretty costly to use and doesn’t work well for small projects.
It’s a risk-driven model which means that the overall success of a project highly depends on the risks analysis phase. Risk analysis requires specific expertise on every iteration. Thus, to review and analyze the project from time to time, special skills are needed.
At a first sight, it may seem like this model is complicated and clumsy, and there are no reasons to consider this approach as one of your options. But, like any other SDLC models, this one, besides its disadvantages, has its unique strong sides.
For example, there’s a possibility to add some additional functionality at the last stages of product development. Since risk monitoring and regular expertise are core characteristics of this approach, the overall project becomes more transparent.
Also read more about software testing life cycle (STLC).
Brief Review of Main Characteristics
In a few words, Spiral Model can be characterized by repeatedly iterating a set of elemental development processes and eliminating risk, so it is actively being reduced.
To understand how you can get your goals using Spiral Model, let’s take a look at this diagram:
As you can see, Spiral Model consists of four main software development life cycle phases. The whole development process repeatedly passes trough these stages. Each iteration is called Spiral.
Four main phases are:
- Determine Objectives
- Planning Phase
This is where everything starts. Team members try to gather the product objectives, requirements (e.g. Business Requirement Specifications or BRS, System Requirement Specifications or SRS), alternatives in design, etc. In the subsequent spirals, all requirements are generated according to the customer’s feedback. Thus, permanent communication between the customer and project management is crucial.
Evaluate Alternatives, Identify, Resolve Risks, or Risk Analysis Phase is probably the most significant development stage.
What are the risks in this context? Risks are possible conditions and events that prevent development team from its goals. There’s a wide range of them, from trivial to fatal. The primary task for the development team is to enumerate all the possible risks and prioritize them according to importance. The next step is to determine the potential strategies that can help to overcome the risks. Evaluation of these parameters can cause changes at the next steps. At the end of this stage, a prototype is produced.
Develop, Verify Next Level Product, or Engineering Phase.
This is when the planned product is developed along with further testing. During the first spiral, when the overall requirements are not so clear, so-called Proof Of Concept (POF) is created to get the customer’s feedback. Later, in subsequent spirals, working version of a product called build can be developed and sent to the client to get a new, more detailed, feedback. Such approach allows to achieve higher clarity on requirements.
Plan Next Phases, or Evaluation Phase.
This phase allows evaluating the output of the project to date before the project continues to the next spiral.
Spiral Model is called meta-model because it uses both Waterfall and Prototype models. But it’s highly important to understand that Spiral Model is not just a sequence of waterfall increments. Not at all. (Read more about waterfall software development life cycle model).
In fact, this model is pretty flexible. You should remember that the diagram we’ve talked about earlier contains some oversimplifications. It may seem that everything on the project follows a single spiral sequence while it’s not. Real life project life cycle is more agile and flexible than this simple representation. There’s even a possibility to revisit the previous decision.
Let’s tale a look at the real project to see, how this model works.
Real Project Example. How GanttPRO Was Made
To provide a great example, we will consider our startup Gantt Chart Software – GanttPRO a tool for simple task handling.
XB Software team applied some principles of Spiral model, and also Scrum principles. For example, shoter iteration to make more frequent releases in order to receive feedbacks more quickly. Besides, a detailed plan describing what to develop for just one iteration was created. Other requirements were documented in the backlog or roadmap.
The main issues the GanttPRO team faced were:
- Unpredicted requirements which were not fully known at the beginning and needed to be clarified and added from iteration to iteration
- Necessity of risks analysis and risks management being the important stage of Spiral model
- Too many risks that can accrue during development and as a result
- Possible costs increase caused by long period of planning and further designing, developing, and implementation
Therefore, following agile principles of SDLC, we chose shorter delivery frequency: two weeks iterations. As a consequence, we managed to reduce risks because of quick adaptation to the needs of the users and the market.
As a result, the following development stages have been completed:
1. Defining concept
On this stage, there was only the initial vision of the product that can create value to the potential users. We wanted to have a possibility to get feedback from our first users as quick as possible. Such conception can help understand more clearly what features are the most valuable for the users. We had some analysis data about features and requirements that should be implemented at first. The main aim was to understand what potential increment we would like to have at the end of the iteration.
2. Inception stage
After we determined the main conception and initial architecture vision, we started to plan our first iteration. The most critical requirements were sent to the top of the list. Then we asked each developer of our team how many requirements they think can be turned into completed functionality. Afterwards, we decomposed each requirement (identified work tasks) and defined the best possible way to develop them. We’ve included modeling and prototyping solution to make a more accurate estimate.
3. Design stage
We elaborated a mockup that described software functionality and features in detail. The mockup was then processed by our designer. The design elements had to be described quite clearly to help a developer build software with minimal additional input.
4. Construction of iteration and testing
At this stage, the team delivered high-quality working software in priority order, which was created in accordance with the changing needs of our potential users. What’s more important, the team could deploy this solution into a pre-production testing/QA sandbox for system integration testing.
5. Installation stage
This stage provides the mechanisms to move the latest application and development changes into production.
6. Post production / Maintenance stage
At the end of each development iteration, we had a partial working solution to show our users. On this basis, users gave us their feedbacks on the current state of our system. After collecting and analysing these requirements, we’re able to change the priority of tasks in the next iteration and even included some requirements from scratch.
Spiral Model Pros and Cons
Each software development model has its own weak and strong sides. Spiral Model is not an exclusion from this rule. Let’s sum up possible pros and cons of this approach.
- Risk monitoring is one of the core parts which makes it pretty attractive, especially when you manage large and expensive projects. Moreover, such approach makes your project more transparent because, by design, each spiral must be reviewed and analyzed
- Customer can see the working product at the early stages of software development life cycle
- Different changes can be added at the late life cycle stages
- Project can be separated into several parts, and more risky of them can be developed earlier which decreases management difficulties
- Project estimates in terms of schedule, costs become more and more realistic as the project moves forward, and loops in spiral get completed
- Strong documentation control
- Since risk monitoring requires additional resources, this model can be pretty costly to use. Each spiral requires specific expertise, which makes the management process more complex. That’s why this SDLC model is not suitable for small projects
- A large number of intermediate stages. As a result, a vast amount of documentation
- Time management may be difficult. Usually, the end date of a project is not known at the first stages
Another important thing to remember is that Spiral Model should be used in that kind of projects it was initially designed for. It can be a good option if you face a medium, or high-risk project and costs are highly important, a customer is unsure completely about his needs and requirements are complex, and significant changes are expected.
All posts, outsourcing, Project Management, sdlc, software development life cycle, spiral model
XB Software business analyst, PM and dedicated Agile Evangelist. Passionate about assisting and growing efficient teams to deliver products for a better world.