Here’s a short blog review of Klocwork Solo by Jeanne Boyarsky. Klocwork Solo is a downloadable Eclipse plug-in for Java. Aside from a few installation hiccups, it’ s a good review with kudos for the range of checkers we provide in the default configuration.

Try it out yourself and let us know what you think.

Interesting paper and presentation (pdf) from Emmanuel Chenu at Thales Avionics that describes how they’re using several Agile concepts as part of their safety-critical avionics software projects. With the exception of pair programming, my read is that much of this is mapping activities that have been done in a safety-critical environment (e.g. test driven development) to several Agile principles, rather than the introduction of concepts that are foreign to safety-critical development. The other one that probably hasn’t been done in most safety-critical shops is continuous integration, but I’d argue that CI (or at least a “build early and often” philosophy), has transcended Agile and is just becoming “the way things are done”, regardless of whether you’re a “Big A Agile”, agile, or iterative development shop.

Either way, it’s interesting how even the most heavy, formal, process-driven development teams are looking at aspects of Agile they can embrace to make their development more flexible, responsive, while still producing highly reliable software. Of course, as he notes, there’s obviously a limit to how “Agile” an avionics development team can really become given the level of formal documentation required through all aspects of a DO-178B project. I’m pretty sure if you ever submitted this kind of documentation to a certification authority they’d probably not accept it:

Today, I had a chance to connect with Connie Beane, the Director of Certification and Safety Critical Software for ENEA Embedded Technology, Inc. Connie has a deep background in safety-critical avionics systems development as a Federal Aviation Administration Designated Engineering Representative (DER) with authority for design assurance level A systems, software and complex electronic hardware. Her additional experience includes 12 years with the FAA in the Transport Airplane Directorate as a Project Officer, Federal representative and Secretary of the RTCA committee SC-180, which produced DO-254, as well as 8 years at Boeing as a Lead Engineer in Boeing Commercial and Boeing Aerospace Divisions.

I wanted to talk to her more about avionics software development, specifically give Kloctalk readers some additional background on the DO-178B guidance that’s used in avionics software development.

[Brendan]:  Can you describe the short version of the history behind this guidance, its purpose, and use in the industry?
[Connie]: In the early 1990’s Boeing was developing the 777 aircraft, which included very software intensive systems.  As a result, industry began using software development and verification tools as a means of developing software more efficiently. The FAA saw this trend as a concern since many of these tools were being used with very little human oversight. When DO-178B was published in 1992, a section on Tool Qualification was included.

[Brendan]:  Is DO-178B guidance only used by teams developing software for commercial aircraft or is it used elsewhere?
[Connie]: DO-178 was developed for commercial aircraft, however, today DO-178B is being used for much more.  It is being used for commercial systems which aid aircraft such as ground based navigation and communication systems. Interestingly, it’s also now being used in military applications both airborne and ground based.

[Brendan]: What’s the most common misunderstanding people have about DO-178B?
[Connie]: That it involves much more than good engineering practices.  DO-178B was developed by government and industry.  They incorporated good engineering practices and some additional activities to ensure safe, reliable software.

[Brendan]: What are a few of the core software development best practices that are required by DO-178B?
[Connie]: Quality Assurance audits, requirements traceability, robustness testing, standards for design, coding and verification.

[Brendan]:  Sounds like a pretty rigorous approach to software development, which of course is a good thing given its safety-critical nature. What kind of cost burden does DO-178B add to a typical project?
[Connie]: That depends on whether the software being developed is performing highly critical functions or not.  For highly critical software, the cost of developing to DO-178B could double the average development cost.

[Brendan]:  Switching gears a bit to your role at ENEA. Out of the full range of DO-178B service offerings you provide, what’s the most common problem you’re brought in to solve?
[Connie]:  Probably the most common issue is a project that is behind schedule and needs to be certified to meet a customer deadline.

[Brendan]:  What’s the biggest change you’ve seen in aircraft systems development during your career?
[Connie]:  Growth in use of software and complex electronic hardware to develop highly integrated avionics systems.

[Brendan]: What do you think the future holds for this guidance? Do you see it evolving in a particular direction that’s different from where it is now?
[Connie]: There is an international committee currently working on the next version of DO-178. This committee is addressing issues such a object-oriented design, model based development, and further defining qualification of software tools.  This committee is also developing a companion guideline to DO-178 which will be applied to ground based software.

[Brendan]: Any final thoughts?
[Connie]:  Companies resist embracing DO-178.  However, once a company has the processes and procedures in place to ensure compliance to DO-178, their software development process is easily understood, repeatable, and maintainable.  This translates to software which is reliable, understandable, traceable and maintainable.

Here’s Gwyn chatting about general software development challenges, in particular the whole goal of “in-phase defect containment” – i.e. identifying and correcting defects in the same development phase they’re created. Near the end of the video, there’s a short discussion on how this objective fits in an Agile context. With Agile’s focus on the frequent delivery of working software, in-phase containment becomes even more important, even though it’s more often associated with more formal methodologies such as CMMI and Six Sigma.

Many of us have seen the # of lines of code (LOC) stats that get thrown around as a metric for illustrating how complex software development has become:

• The U.S. Army’s Future Combat System is estimated at 60 million lines of code (MLOC)
• The software that runs the Boeing 787 is almost 7 MLOC, triple that of the 777
• GM says future cars will have >100 MLOC (that sounds high, but hey, <insert GM joke here>)

So, yes there’s a lot of code out there, it’s growing, and it’s getting more complex. It’s tough to put these numbers into perspective… Jack Ganssle has a clever column that does just that:

• A million lines of code printed out would be 18,000 pages
• A million lines of code will typically have 100,000 bugs pre-test
• A million lines of code costs $20m to $40m

I won’t try to compete with Jack on the stats front since that column speaks for itself, and it’s not just the mission/safety critical systems that are trying to deal with the challenges of more code, more complexity, and less time (as in time-to-market). The consumer market is no different. Guess how much code is in the Xbox HD DVD Player? Not the whole system, just the player? 4.7 MLOC. Heck, you could fly an airplane with all that code (hopefully most of it can also be re-used on a non-obsolete disc format). Just as a point of comparison to today’s gaming systems, ask yourself how many software engineers worked on this “game system”:

Yes, I had to throw Digital Derby under the bus didn’t I? Not because I don’t have fond memories of playing this game that was about the size of carry-on luggage. In fact, I played it until the poor little conveyor belt just stopped working and I put up with the, ahem, limitations in the technology. I was actually quite patient (more patient than I am now with technology) and gave my little Digital Derby second and third chances to work properly.

More code, more complexity, impatient customers, and very little margin for error – these are the trends that are driving tool and process automation across the board in the SDLC.