Any attempt at optimizing software development processes will inevitably run up against the age-old tradeoff between quality, resources, and time. This triple constraint is well-known to project managers with the adage that it is possible to succeed at only two out of the three.
Figure 1: Triple constraint showing quality, resource, and time (Source: QA Systems Ltd)
Of course, no company really wants to compromise on quality, but the stakes are higher for safety-critical or business-critical software in which compromising on quality can result in severe financial or life-endangering consequences, so the primary focus must be on quality for projects of this kind. So how can you optimize your embedded software development when the nature of the project dictates that quality of the software must be of utmost importance?
Foster a quality culture
A quality culture will reduce the overheads for achieving a quality product and mean that less conscious thought and effort need to go into producing high-quality software.
Fortunately, it is relatively easy to develop a quality culture by following some simple principles. Quality cultures tend to promote transparency and ownership. They also treat testing and quality control as essential parts of the development process rather than the last development step.
The keystone to a functioning quality culture is good communication. Techniques include everything from stand-up daily meetings to promoting clarity when reporting bugs so that mistakes are less likely to be made when fixing them. Cross-functional teams and strong communication between teams also help to promote a quality culture and ensure that all stakeholders have a good understanding of quality and safety goals.
Optimize your software development methodology
Modern software development methodologies, such as Agile and DevOps, are widely recognized as producing faster results than traditional Waterfall methodologies. All major software safety standards (e.g., IEC 61508, ISO 26262, and DO-178C) define the software development as a linear process, with a v-model showing requirements definition on the left and testing on the right, as illustrated below:
Figure 2: V-model as defined by ISO 26262 Road vehicles — Functional safety (Source: QA Systems Ltd)
This makes it hard to shift away from a linear Waterfall approach in development of safety-critical software. Modern agile development practices focus on frequent releases, which can be problematic for the development of safety-critical software, as each release needs to go through formal verification and/or certification processes. Similarly, DevOps principles, such as continuous deployment, become more complex when hardware is involved.
However, it is still possible to take advantage of many DevOps and Agile principles to create a streamlined, more iterative approach to developing both safety-critical and business-critical embedded projects.
Shifting effort earlier (left) in the project development life cycle usually results in an overall reduction in effort. Spending more time ensuring that software requirements and design are correct reduces production issues and avoids time spent on wasteful development activities. A shift-left approach to testing works on the principal that finding bugs earlier means that they can be fixed faster, easier, and more cheaply. This is largely because, if testing is delayed, dependencies become hard to unpick.
Shift-left can be applied incrementally for large and complex systems. Agile takes this further by using a mini v-model for each sprint or iteration within an agile methodology.
- Write high-quality requirements
- Start with the hardware
- Involve domain experts in requirements definition
- Optimize the project scope
- Simple design
- Static analysis
- Automate test generation
- Use continuous integration
- Keep hardware in the loop
- Streamline requirements traceability
- Write tests that are easy to maintain