Who's Who at NASA

We assembled a really great team and won the proposal, which initially was awarded at about $15 million over 5 years, which was really exceptional. And we made a heroic effort to deliver on the ambition. We started by taking a close look at the requirements process, and basically our premise was that the design process is human, it requires human beings to make assessments and decisions, and human beings, as we know, are not perfect. They do, occasionally, make mistakes. So, the goal was catching those mistakes, making it less likely that they could enter into the development lifecycle, and making it more likely that they could be intercepted early on. We decided that a tool-based process – increasing the tool component in every step of the software development process – could dramatically help to reduce the number of defects.

So, we started with requirements and built a requirements capture tool (RCAT) that was linked with an analysis capability based on the SPIN model checker. If you can capture design requirements in such a way that they don’t just live in a PowerPoint view graph or in an Excel spreadsheet, but they actually have semantics where you can analyze them for consistency and completeness, then you can plug those requirements into a design verification tool like SPIN and use them to generate test cases, etc.

The next step was design verification based on model checking techniques, improvements in coding by using static source code analyzers, and improvements in testing by developing randomized test methods and simulation methods, prototyping methods, etc. in the final deliverable using fault containment methods to mitigate the effects of any remaining residual defects. So it was fairly ambitious, and about one-and-a-half years into the project we were really starting to produce very good results. Then, as usual, the Code-T funding stream was redefined and we lost our funding under that project because of the nature of the reorganization. Our project was one of the best evaluated from the set, so we still have the same ambition and we’re continuing to work on it, but at a much slower pace right now. We’re still dedicated to getting those results in sooner or later.

NTB: Several years ago, you created quite a stir in the computer world with a groundbreaking article called “The Power of 10: Rules for Developing Safety-Critical Code.” Please explain the Power of 10 concept and how you came up with it.

Holzmann: Well, again, that’s an excellent question. What I noticed when I came here was that every mission and project within JPL – and within NASA in general – would begin by defining a new project-specific coding standard for their software development effort. That coding standard would typically be based on the one that was used on the previous project by other people, but it would then be adjusted to the personal preferences of the new lead on the project. All of these standards differed in mostly insignificant ways, but one thing they all had in common was that they contained hundreds and hundreds of rules that no developer ever seemed to read or take seriously. To make things worse, most of these hundreds of rules would be completely unverifiable. You couldn’t even check mechanically if a developer was complying with the rules.

So, I did a quick scan of the types of software-related anomalies that we have seen in our missions in the last few decades and came up with a short list of problems that seem to be plaguing just about every mission that we fly. This led to the idea of just defining a very small set of rules that could easily be remembered, that clearly related to risk, and for which compliance could mechanically be verified. I published “The Power of 10: Rules for Developing Safety-Critical Code” in IEEE Computer in 2006, and you’re right, the reaction was rather impressive. The most interesting thing for me was that almost everybody who responded said, “Oh, excellent idea. That’s a great set of rules. There’s just one of the ten rules that I disagree with, and here’s why?” Then they’d give an exception, and every single person who responded would pick a different rule. That made me feel that the choices were probably right.

There is an exception to every rule, no matter what rule you can come up with, even if it’s a traffic rule like stop for a red light. You can think of exceptions, like you’re on your way to the hospital, or you’re a fire engine on your way to a fire. There are always exceptions, but as a general principal it is good to have these rules and in most cases you try to live by those rules. If there’s an exception, you have to think about it really hard and justify the exception.

« Start Prev 1 2 3 4 5 Next End»

The U.S. Government does not endorse any commercial product, process, or activity identified on this web site.