Agile software development methods are growing increasingly popular in product development. You can see why—an emphasis on speed, collaboration, and innovation sounds like a great concept.
However, in safety-critical applications, there are concerns that agile methodology is insufficient in ensuring that the end product will not malfunction out in the field.
So do those concerns have merit? Let’s take a deeper dive into the basic tenets of agile development, and the pros and cons of it’s implementation for safety-critical systems.
What is Agile?
Agile is a methodology that emphasizes collaboration and constant iteration with the end goal of developing the most innovative system possible. It was born by a group of developers that found traditional software development processes (eg. Software Development Lifecycle, Waterfall) to be too restrictive, limiting the ability to make changes on the fly if desired. The Agile Manifesto of 2000 cites four core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Essentially, agile development works by breaking a project down into several stages—with each stage providing an opportunity for feedback and collaboration from different stakeholders. There are several different types of agile methodologies, such as Extreme Programming (XP), Scrum, Lean and Kanban, Crystal, Dynamic Systems Development Method (DSDM), and Feature-Driven Development (FDD), with XP and Scrum being the most popular. However, all methods follow the same general principles:
- Customer satisfaction
- Early and continuous delivery
- Embrace change
- Frequent delivery
- Collaboration of businesses and developers
- Motivated individuals
- Face-to-face conversation
- Functional products
- Technical excellence
- Simplicity
- Self-organized teams
- Regulation, reflection, and adjustment
As you can see, with agile development, the development lifecycle never really ends. There is an emphasis on continuous iteration and improvement with the end goal of building the best possible product—and keeping it that way.
However, in safety-critical certified environments, is this the best approach?
Agile vs Traditional Approach
Compared to agile methodology, traditional software development approaches, such as System Development Lifecycle (SDLC), Waterfall, or V-Model are more rigid in structure.
Considering international standards such as IEC 62304, this rigidity can be interpreted as a strength. For example, in the Waterfall model pictured above, a linear plan is followed where each stage of the process must be thoroughly vetted and approved before proceeding to the next stage. A new requirement presented during the implementation phase will not be considered, as the requirements phase has already been completed—changing a requirement at this stage would force the design stage to be repeated/altered, creating inefficiency.
Regulators like the FDA and FAA tend to like traditional approaches, as they provide clear requirement traceability and make clear to auditors that all possible considerations have been taken to ensure a product is safe. Contrasting this with the agile approach, new requirements that are slipped into a product development lifecycle (and more importantly, their impact on the existing system) may not be thoroughly verified and validated, potentially causing quality issues in production—if not found by regulators first.
However, when taking the ability to innovate into consideration, the rigidity of traditional software development approaches can also be considered a weakness. By emphasizing collaboration and innovation, new ideas can be added to a product being developed to allow it to fully realize its market value. It can also save on costs, as the implementation of new features or improvements does not require a full restart of the development cycle.
So what’s the best approach?
As with anything, the real answer to what the best software development approach is that it depends on your application. In highly-regulated industries where quality control is paramount, a traditional approach can help prove to regulators that you take safety seriously. However, in highly-competitive industries where innovation is simply a cost of doing business, you may want to consider implementing more agile methodologies to keep up.
Regardless of how you develop your software, as long as you can prove to regulators that you can verify and validate that you built your system correctly, you should be able to get to market successfully. If you have a safety-critical device that needs regulatory approval, contact our Independent Verification and Validation team to help you get there.
