Do you have a good reference source with example lists of agile firmware deliverables or shows how to develop those?

Thanks a lot for the response! I do agree with your approach. Something that I forgot to mention. Altough the current project targets the development of AOCS actuactors products to fly in LEO, the development philosophy is "new space". That means we qualify EEE parts from automotive grade under representative space environment conditions. That also means we have assess to MCU discovery boards even before the HW simulation. That said, for particular target firmware features, like e.g. over the air sw patch capability, cooperative scheluler, device drivers, we can do it independently from the hw maturity evolution. Once the hw breadboard is assembled and comissioned we will strongly consider your approach. Thanks again!

Thank you for the comprehensive response, it was very valuable to me. Normally, in co-developed hardware and software for critical applications (my current field of work is aerospace) there are project reviews that typically follow a waterfall/V-model life cycle. We are a small embedded software team that is trying hard to develop software using SCRUM agile methodology. What would be your strategy to harmonize HW HDAUF development (e.g. V-model/waterfall), embedded SW development using SCRUM and project reviews (and also hw/sw release s) following a V-model/waterfall lyfe cycle? Thank you very much for your time.

In short, yes, absolutely, but not in exactly the same way as true software. There is a spectrum from hardwired electro-mechanical systems to non-embedded software, and the axis of this distinction is ease of modification. The more you add physical production elements, the more effort and time should be devoted to analysis and design before committing to physical manufacture. This means that the greater the percentage of physical hardware, the more effort must be taken in verification before manufacture using heavy-weight design and analysis.

For example, released software can be fixed with a software patch, often OTA. Physical hardware requires physical processes for updates; thus the rules for agile software, which ultimately assume infinite malleability, don't apply well to electronic & mechanical hardware. In practical terms, this means that more "traditional" processes of heavy-design-and-analysis-upfront (HDAUF) make more sense for HW than for SW because the cost of refactoring and correction are far higher.

However, this is a spectrum, so truth is somewhere in the middle, depending on the actual properties of the system under development. Most systems I deal with fall somewhere on the spectrum, but exactly where can vary quite a bit.

Ok, let's get practical now. Agile methods can easily be applied to HW but to be most effective, they may be applied differently than with software. Early simulation, breadboarding, hand-built electronics, for example, plays a more important role in agile HW development than in SW, because it is easier and less costly to regenerate the software from the design than for HW. OTP HW should be developed using HDAUF while run-time reprogrammable systems can be more incrementally developed.

The relevant things to consider, I believe, are:

• What is the cost of creating the released product, both design cost and manufacturing cost ? (also known as non-recurring and recurring cost)

• What is the lead time for producing the product? (many physical systems have long lead times)

• What is the cost of refactoring the design and implementation?

• What is the cost of defect repair in a released product or in the released facet*?

• What is the likelihood of defects in the different engineering disciplines? (best to use historical data here)

• How will updates to released products be managed? (OTA, service calls, recalls, etc)

to find the optimal mix of incremental and traditional approaches that minimizes overall product cost and maximizes product quality. You must look at the specific properties of the elements and engineering disciplines involved to answer the question. And they vary from business to business and from product to product.

It is also possible to mix traditional development for HW with agile development of the SW (which, I of course, is your actual question); in fact, this is very common and, for many, a preferred approach. I do this all the time.

Remember that Agile doesn't mean "rigorously following Guru X" but rather "adapting your approach to provide the most value with respect to the success of the product depending on the nature of the business environment and the product".

Anyway, that's what I think.

Anyone else want to weigh in?

- b

*facet is a term I use for the portion of a product specific to an engineering discipline; so we have software, electronic, mechanical, hydraulic, pneumatic, (and so on) facets, which are the contributions each of those disciplines make to the overall product.