From: "Robert I. Eachus" <rieachus@attbi.com>
Subject: Re: Enforcing good software process
Date: Sun, 11 May 2003 23:02:37 GMT
Date: 2003-05-11T23:02:37+00:00 [thread overview]
Message-ID: <3EBED68A.7010705@attbi.com> (raw)
In-Reply-To: cf2c6063.0304300901.53bb7caa@posting.google.com
Rod Chapman wrote:
> We have delivered software with warranties, and we will continue to
> do so. Examples are CDIS (part of the London air-traffic management
> systems), SHOLIS, and the MULTOS CA. In the case of the latter
> project, four defects were reported in the first year of operation - these
> were corrected under our warranty at no cost to our client.
That reminded me of one of my favorite Ada stories from way back.
Honeywell Small Systems Division--its name changed several times while I
was there and it is now part of Bull--did a study to see which systems
programming language should be chosen to replace assembler. Three
languages were chosen for further testing C, Pascal, and Ada. Two of
six implementation projects for the next OS version all about the same
size and complexity were chosen for the study. One of the Pascal
projects was shifted to Ada when it was determined during the detailed
design phase that concurrency support was needed in the programming
language.
The three Ada projects came in on time and on budget as did one of the C
projects. The other two projects were over schedule and budget, but
that is not the story.
Six months after the OS version containing all these projects shipped,
there was a meeting to review the support costs. The OS support manager
was a big C fan and dead set against Ada. He showed lots of charts that
indicated that when repairing STARS (bug reports) on the C projects
turnaround was twice as fast as with assembler, and the cost per report
was a third less. "What about the Ada projects?" he was asked by the
division manager.
"Oh, we don't know what it costs to fix bugs in the Ada systems. There
haven't been any reported." To this day, I don't think he understands
why everyone present started laughing uncontrollably.
Similarly I was involved with one DoD project where "safety critical"
was a total understatement. (One joke among the requirements analysis
team was that if there was an accidental nuclear war, this system would
insure that we won it.)
Several years after deployment, I was copied on an analysis of remaining
problems with the system. There was just one. The decision on whether
to have the original contractor maintain the software or to do it
organically (within the Air Force) had never been made. Under reasons?
"No software maintenance has been required." That I could live with.
prev parent reply other threads:[~2003-05-11 23:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 15:14 Enforcing good software process Stephen Leake
2003-04-25 20:15 ` John R. Strohm
2003-04-28 15:55 ` Stephen Leake
2003-04-29 20:12 ` Kevin Cline
2003-04-29 20:54 ` Stephen Leake
2003-04-30 17:01 ` Rod Chapman
2003-05-11 23:02 ` Robert I. Eachus [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox