FROM
THE EDITOR
This week, we turn our truth-seeking goggles toward the often arcane management methods foisted upon hapless embedded software development teams by well-meaning but ill-informed project managers from non-software disciplines. It may seem on the surface that traditional, proven project management tools and techniques would be well suited for software planning and tracking. However, software development, by its very nature, requires a completely different set of disciplines in order to achieve accurate estimates and scheduling success. Part one of our series examines the difficulties encountered when applying mainstream planning techniques to software projects.
If you haven’t checked out our new Journal Jobs employment site
( www.journaljobs.com) it’s worth a visit. New jobs are being posted regularly, and traffic is skyrocketing since we upgraded the site. Registration is free, and it’s a great place to start looking for that next promotion.
Thanks
for reading! If
there's anything we can do to make our publications
more useful to you, please let us know at: comments@embeddedtechjournal.com
Kevin
Morris – Editor
Embedded Technology Journal
|
ANNOUNCEMENTS
Get More System Integration Benefits With Altera PLDs
Get more design benefits by integrating standard digital ICs and digital functions into programmable logic devices. Tell us how you've used Altera products to achieve higher integration, and you could win a 50" DLP HD TV, built with Altera devices.
 Click here!
|
Nios II - The World's Most Versatile Processor
Altera's Nios II processors feature a general-purpose RISC architecture designed to address a wide range of embedded applications. Nios II processors are soft processors, letting you easily adjust the features, performance, and cost of your embedded system. You can deploy your product to market quickly, extend its effective life cycle, and avoid costly processor obsolescence. Learn more about the world's most versatile processor now!
 Learn more about the world's most versatile processor now!
|
FIND A BETTER JOB. Browse new JOURNAL JOBS section from Embedded Technology Journal to find challenging and rewarding opportunities with the embedded technology industry’s top companies. Journal Jobs is specifically for embedded technology professionals – more of what you’re looking for, less of what you’re not.
 Browse now!
|
FPGA AND STRUCTURED ASIC JOURNAL
A weekly e-mail newsletter from techfocus media (publishers of Embedded Technology Journal) dedicated to the design and application of FPGA and structured ASIC technology.
 SUBSCRIBE NOW - FREE!
|
 |
|
Tyranny of the Metaphor
The Slippery Slope of Scheduling Software
Software is not a house.
It seems almost everything in the software world is a metaphor. I sit here typing in a “page” of a “document” that will become a “file” in a “folder”. In software, we create and use metaphors every day, almost without thinking about it. Metaphor creation is a natural consequence of working in a virtual world. Humans often need to map complex concepts to something tangible in order to gain understanding. Unfortunately, this metaphor mania extends to management expectations on the software development process. Management often wants, expects, or worse yet – tries to create project schedules for software development using the same techniques we might expect a contractor to use on a home construction project.
It seems reasonable enough on the surface. There is a pile of work to be done, and one of the project manager’s duties is to analyze that pile into something more manageable – usually a schedule with a resource plan and budget. The well-meaning project manager looks to the wisdom of conventional project planning for guidance in calming the chaos. After all, project management is not a new science. For decades, (if not millennia), techniques for taming the complexity of large collaborative projects such as construction have been well understood. If we just pretend our embedded software project is a house, we can organize, estimate, and schedule the tasks involved in the same way our contractor would, and we’ll be off and on our way to on-time, on-budget project completion and that big promotion and bonus.
Did I mention that software is not a house?
If we were a contractor building a house, we’d have a specification (a set of blueprints) before we began. This specification would be the definitive description of our completed project. Of course, we could expect changes and variations along the way, but the specification would give us a clear enough idea of what we were building that we could create a reasonably accurate development plan.
However, software IS a specification. Our software is a human readable (OK, that’s debatable) representation of the exact functionality we want. Our compiler will translate it into a working executable – our “house”. In the pathological case, if the specification is complete to that level, development time is highly predictable. It corresponds to the runtime of our compiler. That would make our project 99.9% planning and 0.1% execution.
Yes, I hear that collective sigh. Of course it is possible to create high-level specifications for a software project. You simply have to choose your level of abstraction and dive in. At the top level, our metaphoric equivalent specification might be: “Build us a single-family house.” The embedded software version would sound like: “Build us the applications software for a primary flight display for general-aviation aircraft.”
Clearly, both top-level descriptions are too unspecific for any meaningful project planning. We need more detail. In the case of the house, the details go down just a few levels. There is general agreement on the approximate level of specification required before implementation can proceed. You typically won’t find a blueprint with individual nails, screws, and other hardware described, but one level of abstraction above that is common. The specification stops (and implementation can start) at a level of abstraction where there are conventions established. In the case of construction, those conventions are provided by things like building codes that specify the defaults for implementation details. It is not necessary to specify beyond that level of detail. [more]
|
