Spiral Model: Software Development For Critical Projects

The Spiral Model – first described by Barry Boehm in 1986 – is a software development methodology that aids in choosing the optimal process model for a given project. It combines aspects of the incremental build model, waterfall model and prototyping model, but is distinguished by a set of six invariant characteristics.

Spiral Model

The original spiral model diagram. Credit – Barry Boehm, & Wilfred J. Hansen http://www.sei.cmu.edu/reports/00sr008.pdf

The Spiral Model is concerned primarily with risk awareness and management. The risk-driven approach of the spiral model ensures your team is highly flexible in its approach, but also highly aware of and prepared for the challenges they can expect to face down the road. The spiral model shines when stakes are highest and major setbacks are not an option.

1. Define Artifacts Concurrently (AKA “Plan everything, then re-plan those plans, then plan some more.”)

In programming, an ‘artifact’ is any thing produced by people involved in the software development process. The spiral model suggests that all artifacts in a given project lifecycle should be defined fully from the start.

By planning each and every artifact of a project, your team reduces the potential for technical debt and other mishaps. For example, what if your software is reliant on an unusual, expensive or nearly obsolete piece of hardware? Or worse, what if after months of work you realize what you’ve been striving to build cannot actually be achieved? These types of issues can be disastrous.

Defining the scope of your entire project ensures you make the most of your time, and avoid potentially catastrophic scenarios.

2. Four Essential Spiral Tasks

According to Boehm, every spiral model cycle consists of the following four tasks.

  1. Consider critical-stakeholder objectives and constraints.
  2. Elaborate and evaluate alternatives for achieving your objectives.
  3. Identify and resolve risks attendant on choices of alternative solutions.
  4. Stakeholders’ review and agree to proceed based on satisfaction of their critical objectives and constraints.

The second characteristic of the Spiral Model – just like the first – is primarily concerned with mitigating risk and reducing the potential for setbacks. In this case, focusing on the wishes of critical stakeholders rises to the forefront. By performing these four activities, your team ensures it won’t pursue options that don’t satisfy the core needs of the project or present a high potential for risk.

3. Risk determines level of effort

Invariant three suggests that the effort allocated to a component of your project should be determined by the severity of risk associated with that component. Take the following chart for example:

Spiral Model Management

We can see that after a certain point, the risk of losing market share far outweighs the gains made in testing. Yes, testing is important, and reduces the likelihood of releasing a buggy product, but speed in software development, speed is just as important (if not more important). Don’t let your aversion to one risk hinder your ability to account for another.

4. Risk determines degree of details

Invariant four says the potential for risk should determine how much attention you pay to the details of the project you’re working on.

Let’s say you’re introducing a new suite of features to your application. Seems like a no-brainer, right? More features = happier customers. Well…is that always the case? What if your existing customers become overwhelmed by a new interface, or miss the way your product behaved in the previous version? This situation could be pretty bad – you might have some people jumping ship. It would have been best to gather more data and implemented your changes more carefully.

On the other hand, let’s say it’s time to spruce up the language on your site to communicate your offering more clearly. Is this a critical component of your success? Yes. Is getting it wrong going to ruin you? Probably not. In this case, it’s probably safe to throw a few different things up on your site, test them and see what sticks! Don’t sweat the small stuff.

5. Use the anchor point milestones

The spiral model consists of three “Anchor Point Milestones.” They are:

  • Life Cycle Objectives (LCO)
  • Life Cycle Architecture (LCA)
  • Initial Operational Capability (IOC)

These milestones serve as intermediate checkpoints to keep the project moving full steam ahead in the right direction.

The LCO milestone checks to see if the technical approach to a project is well-defined enough to proceed, and that stakeholder conditions are met. If “Yes”, continue. If no, abandon ship or commit to another lifecycle and try again.

The LCA milestone checks that an optimal approach has been defined and that all major risks are accounted for and planned for. If “Yes”, continue. If no, abandon ship or commit to another lifecycle and try again.

The ICO milestone checks that adequate preparations have been made to satisfy stakeholders prior to launch. This includes the software, site, users, operators, and maintainers. If “Yes”, its time for launch! If no, abandon ship or commit to another lifecycle and try again.

6. Focus on the system and its life cycle (Or “Software Isn’t Everything”)

Yes, the Spiral Model is a software development process, but that doesn’t mean you can ignore non-software aspects of your business, or that every problem can be solved with a bit of code.

If you’re experiencing troubles converting leads, that doesn’t mean you need to build a sophisticated sales robot. Maybe it’s just time to re-visit your sales tactics! More software is not always better, and you may find that throwing software at non-software problems only complicates them more. Focus on the underlying goals of the project and see to it that the solution you employ is the one best suited for meeting your win conditions.

So…what now?

While the Spiral Model can be a bit odd to define, one thing is for sure – it’s a great way to keep your eyes on the prize and minimize the risk you assume when building something new. The invariants are great to keep in mind, but we’ve only just scratched the surface of this interesting software development life cycle tool. Check out Boehm & Hansen’s official write-up below to learn even more about Spiral Model.

Spiral Development: Experience, Principles & Refinements – Boehm & Hansen

Airbrake dashboard: visual refresh

At Airbrake, we constantly strive to improve our product to offer the very best. Today, we’ve refreshed the dashboard, improving how you view and navigate errors.


It was obvious that our old dashboard felt dated and needed a retouch. We didn’t want to throw everything at once, so you could have more time to adjust to the changes. First preparatory step that we’ve made prior to launching the new look was using system fonts instead of our custom one. This change made the dashboard much faster to load, and improved mobile users experience. Next, we’ve made some visual changes to the look of our buttons, so they are now unified with the rest of Airbrake. Finally, we are ready to publish the biggest change, which touches almost every aspect of the dashboard. Let me briefly guide you through the changes.

Reduced number of tabs


After we added Aggregations, we felt the tab view had become a little cluttered. We’ve fixed this by moving Backtrace, Params & Context into the Occurrences tab. This greatly improves the mobile experience; users no longer need to scroll horizontally to be able to access the tab they want. Four tabs fit on all modern mobile screens.

Redesigned Occurrences tab

Previously, the occurrences tab was a simple table showing all occurrences in the same error group. Now, it has drastically changed. First of all, the table was moved to another view accessible via the “View Occurrence List” link. Next, global notices pager was moved under the Occurrences tab. The tab itself displays more granular data such as brief error details, backtrace, context & parameters. Similar functionality was available in the previous design, but it was hard to observe differences between each notice because you needed to go to a separate tab every time. Now, everything you need is in the same view.


The table was also improved. Every entry has additional columns such as “hostname” and “remote address”. Additionally, you can open an occurrence by clicking on the entry ID. Finding the table pager is easier now as well, since we moved it from the bottom to the top.


Linkable tabs


The tabs are now linkable. It means that you no longer have to explain to your colleagues which tab you need to click to read certain piece of information. Just link straight to the tab you want.

Sortable aggregation tables


Previously, aggregation tables were sortable only in one direction. Now, you can sort them in both directions (ascending & descending).

Scalable graphs

All Airbrake graphs are now scalable. Previously, if you resized your browser, you needed to fully refresh the dashboard to redraw the graphs. Now, the graphs will adjust automatically to the width of your browser window.

Responsive design improvements

Apart from graphs, we’ve made many other minor tweaks to improve responsiveness of our dashboard for both, desktop and mobile users. Our dashboard can be used on every modern device that you have.

We’re excited to ship this retouch and we would love to hear your feedback. Contact us via our email support@airbrake.io to let us know what you think about it.

Airbrake Docs Relaunch

This summer we relaunched and refreshed the Airbrake docs. The docs were moved in-house, open-sourced on GitHub, given a style overhaul, and are now available at airbrake.io/docs. We hope the new docs provide you with a cohesive and enjoyable experience, helping you become an expert Airbraker one doc at a time.

The docs are home to a wealth of Airbrake information including:

Document updates

We used the relaunch as an opportunity to vet each doc, keeping our eyes open for chances to improve readability, update screenshots/images, and make sure content is organized into logical sections.

Builds and deploys

We automatically build and deploy airbrake-docs as a static site to our CDN. This strategy is low cost and reduces the possible problems related to managing airbrake-docs. There are no server processes to keep running and the docs are distributed globally.


Providing feedback on docs has never been easier. You can provide public feedback via GitHub issues, submit a pull request, provide private feedback anonymously via Temper, or just email us.

Thanks CircleCI

The Airbrake docs are based on the open-source circleci-docs project on GitHub.
CircleCI provides with free testing, building, and deployments for public repositories. Since airbrake-docs is a public repository, we use CircleCI to build and deploy the docs.

Just launched: Airbrake’s new & improved activity feed

We see it in our data, change happens really fast in software projects. Our projects are alive with code changes, deploys, and let’s not pretend…errors!

Some of our eagle-eyed users will have noticed we already had an activity feed, but we knew we could do better.

Today we have launched an overhaul of our project activity feed feature. With a fresh look, a promotion to the error dashboard, and new functionality to help you keep delivering quality, production software!

The new Airbrake activity feed

Deploy Tracking

If you are not tracking deploys with Airbrake, I encourage you to set this up. This is a really powerful feature which gives great insight into the relationship between your deploys and your errors.

The new activity feed takes this a step further, showing teams what changes were deployed, and when. Including errors each deploy was responsible for resolving. Projects that use a code management integration such as GitHub, Bitbucket or GitLab get links to code diffs, showing exactly what changes were deployed. We’ve found this feature particularly useful while trialling it internally, at Airbrake.

We hope you find this to be another useful tool in your quests to deliver quality software! We welcome any feedback and suggestions you may have. Without giving too much away, we have more exciting improvements for Airbrake in the pipeline.

New to Airbrake? Start your 30-day free trial today and you’ll be organising and tracking all your application’s errors in just a few minutes.

New: GitLab integration

By popular demand, you can now integrate your Airbrake directly with GitLab.

You can manually create GitLab issues from the error dashboard, or enable auto-creation to automatically create a GitLab issue whenever new errors occur.

Every GitLab issue created from Airbrake will contain critical error details such as error type & message, URL, file, short backtrace, number of occurrences and more. We will also include link back to the specific error in Airbrake for further investigation.


When you set up GitLab integration, we will automatically create links in the Airbrake backtraces that will point to GitLab repository files.


Are you using GitLab Customer Edition or Enterprise Edition? No worries, we’ve got you covered! Just choose “GitLab CE/EE” integration type on the GitLab integration page.

Full details on how to set up GitLab integration can be found here: https://help.airbrake.io/kb/integrations/gitlab.

Do you have idea for new integration? Email us at support@airbrake.io and we’ll do our best to bring it live.

Get Unlimited Projects for your Airbrake Account

Your software stack likely includes multiple apps/projects/repos, maybe written in multiple languages. A failure in any one can affect the others. So it just makes sense to monitor errors across your entire stack. Right?

Well right now for a limited time, you can get unlimited projects – for life – when you sign-up for a Growth, Business, or Enterprise plan. Already on one of these plans? Don’t worry, you now have unlimited projects for life!

Don’t think you need more projects? There might be more reasons than you think:

  1. Interdependency. When one app fails, other parts of code can be affected. And that means your customers are affected. That’s bad. By monitoring all your apps, you can get alerted to ANY errors that happen ANYWHERE in your stack. So you can fix problems fast.
  2. Proof of Concepts. When you’re constantly innovating, you try lots of new things. Some of those POCs find their way into Staging or, gulp, Production. Monitoring these POCs for errors gives you piece of mind, and allows you to be fast without being reckless.
  3. Flexibility.  Want to monitor different regions or configurations separately? Want different notification settings for Production vs. Development? With unlimited projects, there’s no limit to how granular you can get (if you’re into that sort of thing)

Bonus: we’re currently working on a cross-project dashboard. Soon you’ll be able to see error trends across your entire stack, and how deployments affect each project. The more projects you’re monitoring, the more complete and valuable this dashboard will be.  Look for this to go live later this year.

This offer is good through June 30, just upgrade from your account settings. Or if you’re new to Airbrake, you can sign-up here

New: Trello integration

Today we are happy to announce the new Trello integration for Airbrake.

Just like our JIRA, Assembla and Pivotal Tracker integrations, you can quickly create new Trello cards directly for any error summary.


Or, save yourself time by enabling auto-creation. This will create a card automatically whenever new errors are found.

Trello cards will contain critical details like error name & type, environment, number of occurrences, backtrace, URL, and more. And of course we’ll include a link back to specific Airbrake error group, so you can quickly get all the info you need to fix the issue.


The complete Trello integration set-up only takes about 30 seconds. For full details, check out our knowledge base: https://help.airbrake.io/kb/integrations/trello.

What other integrations are you craving?  Email us at support@airbrake.io.

Getting even more context for errors & exceptions

Knowing that something has gone wrong is pretty valuable. Companies and software teams spend lots of time, energy, and other resources trying to find what has gone wrong and where the problem is.

But as developers and QA engineers know, sometimes all you get is “the app crashed when I tried to click on a button.”

It’s basically like getting this photo, with a complaint that the boat isn’t working. From this limited context, we can see the ship is old and rusty, with a lot of problem areas that could be fixed up — but which one is the real problem? 


Getting the report of an app crash caused by a button might be enough information to start your own investigation, but it’d be far more helpful to have some more context.

  • Which button?
  • What was the user doing before clicking on the button?
  • What other applications were running?
  • Cellular, wifi, or no data connection?
  • What other actions cause similar crashes or exceptions? 

There are many other pieces of information that help diagnose the root of the problem, each one adds a little more context and gets you closer to figuring out the real cause.

There are two important types of context for software errors: information about the application environment and information about what the human being in the real world who was using the application.


Information about the application environment is the kind of logging and filtering of data that a bug capturing tool like Airbrake provides. 

Back to our broken ship; let’s get a little more context:

wreck-687568_1920 3

We now know that the ship isn’t working because it’s stuck on dry ground on a beach. It might even be possible to trace what course it took to get there, which navigation systems were running, and what impact that rusty areas may have had. 

Once Airbrake is part of your app, it captures errors and exceptions, so you know what was going on in the background when a problem crops up. With aggregation, you can also see when errors are coming up in certain browsers, certain users, or servers.

You can see which parts of your app were running, backtrace to see everything that happened up to the point of the error, and in general get the nuts and bolts context of what’s going on.


Using a crowd of human testers provides the other kind of context for really effective bug capture, tracking, and fixing. test IO’s platform makes it possible to get real people checking over your app or website under real-world conditions.

To compare it with our shipwreck, it means you zoom out again and see how people similar to your users interact with it.  

wreck-687568_1920 2

Did they expect the ship to be in the water? Do the rust spots make a difference at all?

When you utilize the power of the crowd to do exploratory testing, human testers can provide you with much-needed context about the types of errors that surface in normal usage and even point out issues that don’t show up in capture tools like Airbrake because some issues are tied to user expectations, specific kinds of usage, and other assumptions people have when interacting with software products.

Better Together

By combining these two types of bug capturing, you get very different but equally helpful kinds of context for software development and fixing bugs. With the granularity provided by Airbrake, you can even pinpoint the exceptions discovered by testers and check the backtrace when you get their detailed bug reports. That means developers have the advantage of both a human-written document with screenshots or screencasts about the bug, as well as being able to see all the details of the application environment and backtrace in Airbrake for that particular bug report.

In the end, it’s all about getting enough information to your development team to empower them to make the right decisions and work effectively. Both test IO and Airbrake are striving to make software development better, they both do it by showing as much of the big picture to developers as they can.

New: GitHub Enterprise integration

GitHub has long been one of our most popular integrations for Airbrake. Today, we’re happy to announce that GitHub Enterprise users can now take advantage of this invaluable integration as well.

GitHub Enterprise integration effectively works the same as our regular GitHub integration. The biggest benefit is the ability to create new issues directly from your dashboard. Or even better, enable auto-creation so that issues are created automatically when new errors are found.

These GitHub issues will contain critical details like error type, error name, Airbrake project name, environment, backtrace and more. Plus, we’ll include a link directly back to the specific Airbrake error so you can dig deeper and quickly identify the root cause of the error.


And when you setup the GitHub Enterprise integration, Airbrake will automatically create error backtrace links which will point to your GitHub Enterprise repository.


Set-up takes about 60 seconds. Details on how to do that can be found on the right side of the screen when you visit GitHub integration page on your Airbrake account. Or you can get the full scoop here: https://help.airbrake.io/kb/integrations/github.

What other Airbrake integrations are you dying to have? Email us at support@airbrake.io and we’ll do whatever we can to make all your wildest dreams come true.