comp.lang.ada
 help / color / mirror / Atom feed
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.






      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