Software Risk Analysis

[Pyrotex]

Thank you muchly, Buffster_1.

So basically this is what's up. The target software (TSW) was originally designed and built 30 years ago, and has gone through about 50 versions since. Detailed statistics were kept on errors found at various stages of development: source inspection, system and subsystem testing, full integrated tested with full-up hardware systems and real-time simulation with people in the loops (let's call them "pilots"). These errors were classified as to their severity, 1,2,3 -- with "1" meaning total catastrophe.
Error statistics were also kept for actual "usages" (let's call them "flights") of the TSW--that is, errors that occurred during real "flights".
As it turns out, the probability that an error will make it through all the testing and finally execute during "flight" can be correlated to the probabilities that errors will execute during simulations and during integrated testing.
We know: the probability that a source line of code will contain an error;
the probability that it will be caught at various stages of development/testing;
the number of new or modified lines of code at each version;
the probability that a "flight" will be nominal, thereby NOT executing those portions of TSW intended for handling bad events.
Shuffle this all together, and for a particular version, you can calculate the probability of having a Real Bad Day (RBD) in an actual "flight".
Now we're looking at the degrees of uncertainty in our calculations.

Pyro the Probable

[Pyrotex]

Brief update --
Game Over, I Win.

I did in fact come up with a SW Probabalistic Risk Assessment model using 30 years of quality management data and statistics. It is a sequence of seven failure events:

1. Probability that a single line of code (SLOC) contains a bug
2. Probability that visual code inspection fails to find the bug
3. Probability that module integration and testing fails to find the bug
4. Probability that full-up system simulations fail to find the bug
5. Probability that the the bug executes while in flight
6. Probability that the bug is a critical-1 failure (the worst kind)
7. Probability that backup procedures fail to correct

We managed to find enough historical data to calculate most of these event probabilities directly. For events 5 and 7, we found "proxie" data in the training simulation QM data sufficient to generate close approximations.

I gave our pitch to the tip-top muckity-mucks and sahibs last Monday. And it went extremely well. Our results interested a lot of folks and there were several calls asking for the detailed report we published. Plans are being made to take our pitch to the companies who are building the next generation software. Mucho visibility. Mucho praise from unexpected quarters.

Now... where do I go from here???

[freeztar]

Congrats Pyro!

[Buffy]

Originally Posted by Pyrotex

Game Over, I Win.

That was a foregone conclusion!

Originally Posted by Pyrotex

Now... where do I go from here???

Find Critical Event Number 8 that reduces the standard deviation by 50% and patent it...

There is always one more feature,
Buffy

[CraigD]

Have you published it in a publicly available place (other than this hypography thread, of course)? If not, if you have the personal bandwidth, and no IP/trade secret entanglements, I’d recommend that as your next goal. In short, satisfy the wikipedia notability criteria – then, of course, craft a nice wikipedia article for it.

It’s a nice model, reminding me of the Drake equation, and having, I think, the potential to be as useful and as well-known.

I’ll do my personal part to promote it Monday, when I have a couple of meeting with project test teams, who are always hungry for tools to quantify risk.

PS: In the past 2 weeks, I’ve discovered a couple of appalling datapoints contributing to my personal event 1 probability, including one that’s been being touched over a hundred million times a day for the past 3 years with the potential to affect the survival of over half a million people! Fortunately, its failure mode didn’t occur until the recent test of some new software, where our apparently high event 4 probability made me aware of it, so the live world was never at risk.

[Pyrotex]

Originally Posted by Buffy

That was a foregone conclusion! ...
There is always one more feature...

Thank you muchly, dear Buffster. Your confidence in me is touching.

The one thing folks ARE requesting is a sensitivity/uncertainty analysis. We start Monday on discussing the ways and means of doing that.

The big deal of our analysis and pitch was in finding the degree to which "risk" is determined by the "maturity" of the ground test and verification processes: the odds of flight SW causing a Real Bad Day can vary from 1 in 100 for the first coupla flights -- to 1 in 2000 after 20 years of getting one's act thoroughly together. That really raised some eyebrows.

Some pressure is now being applied to the next-gen SW developers who had intended to "roll their own" ground test and verification process AFTER the SW was developed. You can't do that and keep risks down. The ground stuff must be totally in place and being used diligently from the first phase of SW development, or you face doing your first flight with a low-maturity system.

{shiver}

[Pyrotex]

Originally Posted by CraigD

Have you published it in a publicly available place (other than this hypography thread, of course)?
...with the potential to affect the survival of over half a million people! ....

No, I haven't. Currently, it is still an internal document. I won't think of publishing until the muckity-mucks and sahibs grant permission.

Half a million? Craig! What do you DO?? Write SW for fast breeder reactors in the middle of Amarillo, Texas???

[CraigD]

Originally Posted by CraigD

…with the potential to affect the survival of over half a million people! …

Originally Posted by Pyrotex

Half a million? Craig! What do you DO?? Write SW for fast breeder reactors in the middle of Amarillo, Texas???

Mostly, I make grandiosely exaggerated claims on the internet.

My defective line of code of note was in a piece of basic string manipulating code for an interface engine used by a 3-state region of a clinic and hospital system serving about half a million people. The event 6 - the bug is a critical-1 failure proability, even had its failure mode occurred, was pretty small. Most of them would have resulted in XML messages being incorrectly rejected as misformed, causing some support person to curse the system, and, ultimately, me. Less likely would have been something like sending you to the wrong examining room at the wrong time. Worst case would be a swapping patient identities to give you someone else’s lab test results, a medication to which you’re allergic, etc. Doctors, nurses and such being pretty well trained not to trust technology in life-or-death situations, their human contribution to event 7 - backup procedures fail to correct - keeps its probability pretty low.

In short, I exaggerated badly in claiming my code is critical to the survival of half a million people. Still, reliability is a big concern in medical software and hardware – causing injury or death of even one out of half a million people is not an experience any programmer or other medical IT person wants. Unlike in the technically sexier world of spaceflight software, I’m unaware of any initiatives like yours to systematically quantify the software risk component in healthcare (though there is a lot of study of injury and death causing error of healthcare systems as a whole), but his rocket-explosion-predicting model seems well suited for adapted to healthcare.