Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Embedded software devt: The disciplined way (Part 1)

Posted: 15 Oct 2012 ?? ?Print Version ?Bookmark and Share

Keywords:debugging tools? firmware? software?

The idea behind the CMMI is to find a defined way to predictably make good software. The words "predictable" and "consistently" are the keynotes of the CMMI. Even the most dysfunctional teams have occasional successesgenerally surprising everyone. The key is to change the way we build embedded systems so we are consistently successful, and so we can reliably predict the code's characteristics (deadlines, bug rates, cost, etc.).

The figure shows the result of using the tenants of the CMMI in achieving schedule and cost goals. In fact, Level 5 organizations don't always deliver on time. The probability of being on time, though, is high and the typical error bands low.

Compare this to the performance of a Level 1 (Initial) team. The odds of success are about the same as at the craps tables in Las Vegas. A 1997 survey in EE Times confirms this data in its report that 80% of embedded systems are delivered late.

Figure: Improving the process improves the odds of meeting goals and narrows the error bands.

One study of companies progressing along the rungs of the CMMI found per year results of:

37% gain in productivity

18% more defects found pre-test

19% reduction in time to market

45% reduction in customer-found defects

It's pretty hard to argue with results like these. Yet the vast majority of organizations are at Level 1. In my discussions with embedded folks I've found most are only vaguely aware of the CMMI. An obvious moral is to study constantly. Keep up with the state of the art of software development.

At the risk of being proclaimed a heretic and being burned at the stake of political incorrectness, I advise most companies to be wary of the CMMI. Despite its obvious benefits, the pursuit of CMMI is a difficult road all too many companies just cannot navigate. Problems include:

1. Without deep management commitment CMMI is doomed to failure. Since management rarely understandsor even cares aboutthe issues in creating high quality software, their tepid buy-in all too often collapses when under fire from looming deadlines.

2. The path from level to level is long and torturous. Without a passionate technical visionary guiding the way and rallying the troops, individual engineers may lose hope and fall back on their old, dysfunctional software habits.

CMMI is a tool. Nothing more. Study it. Pull good ideas from it. Proselytize its virtues to your management. But have a backup plan you can realistically implement now to start building better code immediately. Postponing improvement while you "analyze options" or "study the field " always leads back to the status quo. Act now!

This series of three articles was printed with permission from Newnes, a division of Elsevier, Copyright 2008, from "The Art of Designing Embedded Systems, Second Edition" by Jack Ganssle.

About the author
With 30 years in this field Jack was one of the first embedded developers. He writes a monthly column in Embedded Systems Design about integration issues, and is the author of several embedded books, including: The Art of Designing Embedded Systems and The Art of Programming Embedded Systems. Jack conducts one-day training seminars that show developers how to develop better firmware, faster. His most recent column on this topic is The Non-Quality Revolution..

To download the PDF version of this article, click here.

?First Page?Previous Page 1???2???3

Article Comments - Embedded software devt: The discipli...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top