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."