Embedded systems designers have been slow to adopt the "agile" methods that have taken over many segments of the information technology (IT) software development process. Instead of ordinary design-develop-deploy techniques, agile methods use an iterative development cycle that has proven itself by producing higher-quality code in less time than traditional techniques. Designers, however, need to avoid common pitfalls to successfully adapt agile methods to their embedded-system projects. Learn how to adapt the agile software development methodology to embedded system design from the author of the only book on agile-for-embedded at the The DESIGN West 2013 session Top Ten Mistakes of Agile Embedded Projects (and how you can avoid them on Thursday, April 25 at 2:00-to-2:45 pm.
"The primary reason that designers move to agile methods, is to improve quality," said Bruce Douglass, chief evangelist for IBM Rational. "Their second primary reason is to improve project and developer efficiency. The problem is how to adapt those agile methods to embedded systems, which is not obvious and is not well published."
The only textbook devoted expressly to agile methods for embedded developers is Douglass' own: "Real-Time Agility: Agile Methods for Real Time and Embedded Systems" (Addison-Wesley). Douglass touches on agile methods in many of his other books and will sum up the 10 most common pitfalls for embedded designers just starting out using agile methods in his DESIGN West session.
"A key problem that agile methods avoid is building the wrong system--one that might meet the requirements, which were verified with the customer, but the problem was that the requirements did not in fact meet the needs of the customer--what we call failing the validation test," said Douglass.
Unfortunately, it is not obvious how to adapt agile methods to embedded system development, due to the multiple ways they can fail, including safety, security, reliability, scope, size and geographically distributed team members, none of which are typically addressed by original project plans.
"Designers often have a project plan, but they need to understand that a plan is just a theory about what is expected to happen," said Douglass. "And theories need to be proven with evidence gathered during the development process. If the evidence proves the theory wrong, then designers need to change the theory--the project plan. And how you do that--how embedded system designers measure success and update the plan--is what I will be talking about."
From my 15 years of experience in high reliability embedded software, I find the assertion "The primary reason that designers move to agile methods, is to improve quality" hard to believe and very confusing.
Agile methods promote 'working software' over documentation.
Secondly, agile methods have shorter release cycles.
While this allows teams to better adapt to changing requirements, it does not improve quality.
By focusing on working software and shorter release cycles, one usually sacrifices quality (eg: less investment in long term architecture and less thought spent fully defining system requirements). While this may work well for fast pace projects with uncertain requirements, it can be fatal for complex software projects.
I don't have anything against agile methods, but to say that the primary reason teams move to them is to increase quality just doesn't make sense to me.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.