comp.lang.ada
 help / color / mirror / Atom feed
* Cooked cost-effectiveness
@ 1992-12-13 20:35 Michael Feldman
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Feldman @ 1992-12-13 20:35 UTC (permalink / raw)


In article <921212103914.20203764@OTTAWA.DSEG.TI.COM> PETCHER@OTTAWA.dseg.ti.co
m (What? Me Ada?) writes:
>
>On the life cycle cost controversy:  While, as somebody recently pointed out,
>statistics can be cooked up any way you want them, even a good cook can't
>cook without ingredients.  The typical life cycle of a military system is
>about 20 years, probably to grow a bit as time goes on.  I'm not sure what
>the oldest fielded Ada based system is right now, but it couldn't be over
>four or five years old.  Anybody who attempts to compare life cycle cost can
>only do so based on speculation.
>
Which is exactly why the DoD Ada nay-sayers should quit wasting their time
saying nay, relax, admit they are stuck with the mandate -- which carries
with it a _presumption_ that a safe and standard language will be cost-
effective in the long term -- and get on with the business at hand.
High time for a little good faith and giving it your best shot, IMHO.

For the non-DoD world, those of us who choose Ada have done so with no 
mandate -- we were open-minded enough not to need one.

Mike Feldman

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Cooked cost-effectiveness
@ 1992-12-14  3:41 Gregory Aharonian
  0 siblings, 0 replies; 3+ messages in thread
From: Gregory Aharonian @ 1992-12-14  3:41 UTC (permalink / raw)


Actually the long term cost effectiveness of Ada and the Mandate will always
be unknown for the following reasons:

	1) As the GAO reported a few years ago, there is no systematic
	   collection of comprehensive cost data for Ada projects inside
	   the DoD, a conclusion the DoD concurred with, and to date has
	   done little to address. Nor is there collection of background
	   socioeconomic data (such as processor throughput and desktop
   	   CPU power) that has to be factored out of the Ada cost data.
 
	2) There are no decent microeconomic models of defense software
	   development to use as a basis for analyzing the data collected.
	   In fact, data should not be collected until there is such a
	   model, otherwise you don't know what variables to measure.
	   As there is, and has been, no DoD interest in such models
	   (and I do not consider any modified form of COCOMO a suitable
	   basis for a microeconomic model, which some have argued),
	   the DoD is in the dark, except for ancedotal evidence.

	3) There are no groups independent of the DoD who know enough
	   about economics and defense software development to perform
	   a valid assessment of this question.  The Mosemann studies
	   are evidence of the crap you get when the DoD asks one of
	   its own to say how well the DoD is doing.

This is not to say that I don't believe that for some projects, Ada is
very cost effective.  I have seen a few private sector projects use Ada
very cost effectively.  Rather, I do not think anyone will be able to
specifically prove that the Ada mandate is cost effective.  Not that
anyone cares, especially when you have outrageous claims like the original
STARS claim to increase productivity ten-fold.   Any goal far enough in
the future, backed by a few uniforms, will be funded by Congress in under
a few tens of millions.  None of the originals will be around on judgment
day.

Greg Aharonian
Source Translation & Optimization

-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Cooked cost-effectiveness
@ 1992-12-14  5:07 Michael Feldman
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Feldman @ 1992-12-14  5:07 UTC (permalink / raw)


In article <SRCTRAN.92Dec13224133@world.std.com> srctran@world.std.com (Gregory
 Aharonian) writes:

[lots of good stuff deleted about the paucity of good models for assessing
cost-effectiveness deleted]
>
>This is not to say that I don't believe that for some projects, Ada is
>very cost effective.  I have seen a few private sector projects use Ada
>very cost effectively.  Rather, I do not think anyone will be able to
>specifically prove that the Ada mandate is cost effective.  Not that
>anyone cares, especially when you have outrageous claims like the original
>STARS claim to increase productivity ten-fold.   Any goal far enough in
>the future, backed by a few uniforms, will be funded by Congress in under
>a few tens of millions.  None of the originals will be around on judgment
>day.
>
Right. Which is why the service policies (e.g. Currie Colket's summary
the other day of the Navy one) simply state a _presumption_ of Ada cost-
effectiveness. The burden is on the nay-sayer to persuade the relevant
waiver-writer that a waiver is needed. Quite appropriate IMHO. This
could also have been done by simple DoD fiat, without Congress' help.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1992-12-14  5:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-12-14  5:07 Cooked cost-effectiveness Michael Feldman
  -- strict thread matches above, loose matches on Subject: below --
1992-12-14  3:41 Gregory Aharonian
1992-12-13 20:35 Michael Feldman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox