official recommendations of Ada

official recommendations of Ada

[Russ]

I work in an environment dominated by C/C++, and I would like to
recommend Ada for a safety-critical application that is about to be
initiated. I think official recommendations of respected standards
organizations will carry a lot of weight. I came across a reference to
IEC-1508, for example, which apparently recommends Ada. However, the
document must be ordered and costs over $100. Yes, I should go ahead
and get it, but I am wondering if the actual Ada recommendation is
available online somewhere. Also, does anyone know of other official
recommendations of Ada over other languages for critical software
(either online or available through snail-mail)? Thanks.

Re: official recommendations of Ada

[Pat Rogers]

The MISRA C guidelines recommend Ada (among others) at the end of the
document.

http://www.misra.org.uk/


"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0107162313.66a58a69@posting.google.com...
> I work in an environment dominated by C/C++, and I would like to
> recommend Ada for a safety-critical application that is about to be
> initiated. I think official recommendations of respected standards
> organizations will carry a lot of weight. I came across a reference to
> IEC-1508, for example, which apparently recommends Ada. However, the
> document must be ordered and costs over $100. Yes, I should go ahead
> and get it, but I am wondering if the actual Ada recommendation is
> available online somewhere. Also, does anyone know of other official
> recommendations of Ada over other languages for critical software
> (either online or available through snail-mail)? Thanks.
>

Re: official recommendations of Ada

[Larry Kilgallen]

In article <6QW47.1193$Pz6.12254@nnrp1.sbc.net>, "Pat Rogers" <progers@classwide.com> writes:
> The MISRA C guidelines recommend Ada (among others) at the end of the
> document.
> 
> http://www.misra.org.uk/

Good pointer.  Thanks (even though I did not ask the question).

In particular, the freely-distributable just so you do not excerpt
preview at http://www.misra.org.uk/graphics/miscprev.pdf give that
recommendation in the penultimate paragraph of page 3.  The only
better-than-C languages for safety-related systems they call out
by name are Ada and Modula 2.

Re: official recommendations of Ada

[Hambut]

Hi,

It's been a dull evening tonight, so I thought I'd have a wade through
the stuff I've got to hand to see what I can find with respect to Ada
recommendations.  This may help - it might at least be a starting
point.

I've managed to find three broad categories of things:

1.  Recommendations to use Ada in safety related applications
2.  Links to articles which perhaps provide ammunition against the use
of C++.
3.  Some general safety links that you might find useful if your
company's about to embark on a safety related project.

1.  Recommendations to use Ada in safety related applications.
    ==========================================================

I've managed to find 3.5 concrete recommendations for the use of Ada
in safety related systems:
1.1  European Railway Safety Standard prEN50128
1.2  MISRA C Coding Guidelines
1.3  US DoD Joint Software System Safety Handbook (the half a recommendation)
1.4  A paper published in the early nineties

Interestingly neither DO178B (aviation software safety standard) nor
Defence Standard 00-55 (UK defence standard for the development of
safety related/ critical software) make recommendations as to language
choice.  Instead they define characteristics that the chosen language
should obey.  The characteristics defined by Defence Standard 00-55
pretty much boil down to a choice of SPARK Ada or SPARK Ada for the
highest integrity levels.

I believe that IEC61508 (you referred to it as 1508 in your initial
posting) has a similar table to prEN50128 - although I'd need to chase
it up to be absolutely sure (so all you standards junkies don't shoot
me down in flames just yet).

Final point to note is that there is a very useful document being
produced by an ISO committee (The Annex H Rapporteur(sp?) Group)
called "Programming Languages - Guide for the Use of the Ada
Programming Language in High Integrity Systems".  I can't find a link
to a downloadable copy immediately.  Perhaps another reader can help?

1.1  European Railway Standard prEN50128

Table A.15 of CENELEC prEN50128 lists Ada as being "highly recommended" for Safety
Integrity Levels 1 and 2, and "recommended" for Safety Integrity
Levels 3 and 4.

The same table lists unrestricted C or C++ as "not recommended" for
safety integrity levels 3 and 4, and makes no recommendation for
safety integrity levels 1 and 2.

However it also lists "A subset of C or C++" as "recommended" for
safety integrity levels 1 to 4.

Interestingly it doesn't mention a safe subset of Ada in the table.  However it
does say, in a note, "At Software Safety Integrity Level 3 and 4 when a subset of
languages 1,2,3 and 4 are used the recommendation changes to HR" HR is
the code for highly recommended.  Ada is language 1.  So when a
suitable subset of Ada is used the recommendation is "highly recommended".

This is from "Railway applications - Software for railway control and protection
systems", prEN 50128.  Possibly available from www.cenelec.org.

1.2  MISRA C Coding Guidelines

"Examples of languages generally recognised to be more suitable than C
[for safety related software] are Ada and Modula-2.  If such languages
could be available for a proposed system then their use should be
seriously considered in preference to C."

Document at:
o  http://www.misra.org.uk/graphics/miscprev.pdf

1.3  US DoD Software Safety Handbook

"The Ada programming language provides considerable support for
preventing many causes of unpredictable behaviour allowed in other
languages.  For example,...., implicit constraint checks prevent the
classic "C" programming bug of writing a value into the 11th element
of a 10-element array." 

This is from "Software System Safety Handbook - A technical and Managerial Team
Approach", Joint Software System Safety Committee, December 1999.

Available from http://www.nswc.navy.mil/safety/joint_software_system_safety_han.htm

1.4  The choice of computer languages for use in safety-critical systems

A paper published in the early nineties, which looked at a number of
attributes that the authors thought were important for 'safe'
software, has this to say about the subject:

"The languages that design teams should consider as candidates for use
in high integrity systems are, according to the assessments in this
paper, and in descending order of merit

o  ISO Pascal subsets supported by validation tools (e.g. SPADE
Pascal);
o  an Ada sub-language, when available;
o  a Modula-2 sub-language when available;
o  a CORAL 66 subset."

"If analysis of the hazards suggests that the risks are comparatively
low, the second group of languages that may be considered includes, in
no particular order

o  structured assembly languages;
o  DoD Ada, with minimal restrictions;
o  ISO Pascal, with minimal restrictions;
o  Modula-2, with minimal restrictions."

"Based on the assessments in this paper, the use of the following
languages is to be deprecated when safety is an issue

o  unrestricted use of assembly languages;
o  C (despite its many adherants)
o  unrestricted use of CORAL 66"

This is from "The choice of computer languages for use in safety-critical systems",
W.J.Cullyer, S.J. Goodenough and B.A. Wichmann, Software Engineering
Journal, March 1991.

I believe this study is also quoted in Neil Storey's "Safety Critical
Computer Systems" book.


2.  Links to articles which provide ammunition against the use of C++.
    =================================================================

There are two main links;

For a critical view of C++, which may provide useful reasons why it
should not be used in a safety related/ critical project look at the
Joyner paper, "A Critique of C++ and Programming and Language Trends of
the 1990s" available at:

    http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html

And for a debate, which includes submissions by a number of respected
safety people about the use of C++ in developing safety related
software take a look at:

    http://www.cs.york.ac.uk/hise/sclist/cplussafety.html


3.  Some General Safety Links You Might Find Useful
    ===============================================

In fact there's one, which is a good starting point for links to lots
of other sites interested in software safety:

    http://www.afm.sbu.ac.uk/safety/


Hope this helps.

Cheers,

Hambut

Re: official recommendations of Ada

[Martin Dowie]

ARINC Report 613, Guidance for Using the Ada Programming
Language in Avionic Systems

"It is the desire of the airline community to reduce the
 cost and the economic risk associated with avionics
 software systems. As a means to achieve this, it is
 recommended that the Ada programming language be used
 as the standard High-Order Language (HOL) in avionics
 equipment design."


Russ <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0107162313.66a58a69@posting.google.com...
> I work in an environment dominated by C/C++, and I would like to
> recommend Ada for a safety-critical application that is about to be
> initiated. I think official recommendations of respected standards
> organizations will carry a lot of weight. I came across a reference to
> IEC-1508, for example, which apparently recommends Ada. However, the
> document must be ordered and costs over $100. Yes, I should go ahead
> and get it, but I am wondering if the actual Ada recommendation is
> available online somewhere. Also, does anyone know of other official
> recommendations of Ada over other languages for critical software
> (either online or available through snail-mail)? Thanks.

Re: official recommendations of Ada

[Hambut]

A final point worth noting is that if everything goes horribly wrong
and you have to go 'C' then I understand that it's well worth looking
at:

o  The MISRA 'C' Guidelines, and
o  "Safer C" by Les Hatton

According to people 'in the know' both of these are supposed to have
valuable tips for developing safer 'C' software.

Later,
Hambut

Re: official recommendations of Ada

[Mike Silva]

hfrumblefoot@yahoo.com (Hambut) wrote in message news:<fb75c450.0107181354.23688357@posting.google.com>...
> A final point worth noting is that if everything goes horribly wrong
> and you have to go 'C' then I understand that it's well worth looking
> at:
> 
> o  The MISRA 'C' Guidelines, and
> o  "Safer C" by Les Hatton
> 
> According to people 'in the know' both of these are supposed to have
> valuable tips for developing safer 'C' software.
> 
> Later,
> Hambut

FWIW, the MISRA 'C' Guidelines intend their C subset for SIL 2 & 3,
but make no recommendation for SIL 4.  I guess you could count that as
a negative recommendation for C (and by implication C++)

Mike


Mike

Re: official recommendations of Ada

[Phil Thornley]

"Hambut" <hfrumblefoot@yahoo.com> wrote in message
news:fb75c450.0107171332.18376cd6@posting.google.com...
.. lots of useful stuff, including:

> Final point to note is that there is a very useful document being
> produced by an ISO committee (The Annex H Rapporteur(sp?) Group)
> called "Programming Languages - Guide for the Use of the Ada
> Programming Language in High Integrity Systems".

The work on this finished some time ago and it was published early last
year. The official designation is ISO/IEC DTR 15942.

I can't find a link
> to a downloadable copy immediately.  Perhaps another reader can help?

The published version is under ISO/IEC copyright, so you have to buy it
from your local standards source. However a very late draft version is
at:

http://anubis.dkuug.dk/JTC1/SC22/WG9/n359.pdf

I believe that this is still under ISO/IEC copyright, so I guess you can
read it, but not copy it further. An earlier (but not substantially
different) version that isn't under ISO/IEC copyright was published in
Ada Letters - Volume XVIII Number 4, July/August 1998.

Cheers,

Phil

--
Phil Thornley
BAE SYSTEMS

Re: official recommendations of Ada

[Peter Amey]

Phil Thornley wrote:
> 
> "Hambut" <hfrumblefoot@yahoo.com> wrote in message
> news:fb75c450.0107171332.18376cd6@posting.google.com...
> .. lots of useful stuff, including:
> 
> > Final point to note is that there is a very useful document being
> > produced by an ISO committee (The Annex H Rapporteur(sp?) Group)
> > called "Programming Languages - Guide for the Use of the Ada
> > Programming Language in High Integrity Systems".
> 
> The work on this finished some time ago and it was published early last
> year. The official designation is ISO/IEC DTR 15942.
> 
> I can't find a link
> > to a downloadable copy immediately.  Perhaps another reader can help?
> 
> The published version is under ISO/IEC copyright, so you have to buy it
> from your local standards source. However a very late draft version is
> at:
> 
> http://anubis.dkuug.dk/JTC1/SC22/WG9/n359.pdf
> 
> I believe that this is still under ISO/IEC copyright, so I guess you can
> read it, but not copy it further. An earlier (but not substantially
> different) version that isn't under ISO/IEC copyright was published in
> Ada Letters - Volume XVIII Number 4, July/August 1998.
> 

Further to the above, Jim Moore, convener of ISO WG9 has taken steps to
try and get the HRG report made freely available.  There is a mechanism
for doing this for "technical reports" as opposed to "standards".

Peter

Re: official recommendations of Ada

[Robert Dewar]

"Phil Thornley" <phil.thornley@baesystems.com> wrote in message news:<3b57d412$1@pull.gecm.com>...
> An earlier (but not substantially
> different) version that isn't under ISO/IEC copyright was published 
> in Ada Letters - Volume XVIII Number 4, July/August 1998.

Please be careful to remember that everything is copyrighted
automatically, unless it has been specifically placed in the public
domain. The mere lack of a copyright notice on any document (or 
source program) is not sufficient to conclude that the document
(or source program) is not in the public domain. Furthermore, the
mere fact that a source program or document contains some copyright
or license notice does not necessarily mean that the information
there is correct. If you copy a document, it is up to you to determine
that you are doing so without violating copyright law.

Re: official recommendations of Ada

[codesavvy]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> I work in an environment dominated by C/C++, and I would like to
> recommend Ada for a safety-critical application that is about to be
> initiated. 

Excellent, you're probably going to have an incredibly hard sell
because:

1.  There is probably so much legacy C/C++ code around.

2.  Management probably has quite a bit of experience in managing
C/C++ projects.

3.  The developers have a lot of C/C++ experience.

4.  Management probably has little or no experience in managing Ada
development projects.

5.  There are probably at least some developers that are not
experienced with Ada and have a major learning curve to overcome.


From management's view point, using Ada instead of C/C++ is taking a
major risk and when push comes to shove management probably will not
take such a risk unless they can see the "payback" in using Ada.  I'm
sorry but I doubt if management will find papers recommending Ada for
safety critical applications compelling.  Qualitative arguments
regarding the advantages of Ada will probably fall on deaf ears. 
Quantitative arguments regarding productivity advantages have a decent
chance of being received well.  As has been pointed out in another
thread, there has to be a consensus on a metric that measures
productivity effectively.  If there is and management collects the
appropriate data you may convince them to try Ada on some small
project and collect the appropriate data to measure Ada productivity. 
If productivity is not being measured currently I'd start there.  BTW
you do run the risk of being labled a malcontent.  I'd save the $100
unless I was really interested in having the hard copy as a standard.

I think official recommendations of respected standards
> organizations will carry a lot of weight. I came across a reference to
> IEC-1508, for example, which apparently recommends Ada. However, the
> document must be ordered and costs over $100. Yes, I should go ahead
> and get it, but I am wondering if the actual Ada recommendation is
> available online somewhere. Also, does anyone know of other official
> recommendations of Ada over other languages for critical software
> (either online or available through snail-mail)? Thanks.

Re: official recommendations of Ada

[Larry Kilgallen]

In article <5be89e2f.0107200443.678562ea@posting.google.com>, codesavvy@aol.com (codesavvy) writes:
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107162313.66a58a69@posting.google.com>...
>> I work in an environment dominated by C/C++, and I would like to
>> recommend Ada for a safety-critical application that is about to be
>> initiated. 

> From management's view point, using Ada instead of C/C++ is taking a
> major risk and when push comes to shove management probably will not
> take such a risk unless they can see the "payback" in using Ada.

In some cases, management may be willing to try "something different"
that does not disrupt the whole shop.

Re: official recommendations of Ada

[Ed Falis]

codesavvy wrote:

> From management's view point, using Ada instead of C/C++ is taking a
> major risk and when push comes to shove management probably will not
> take such a risk unless they can see the "payback" in using Ada.

Since I've been "management", I have to say that "management" is not homogenous.  Your generalizations are
just that. There's a lot more variety of approaches than your stereotypes (a la Dilbert) would lead one to
believe.  You think there's no conflict of ideology and business strategy at that level?  Often enough, taking
measured risk is _the_ way through, though it doesn't appear to be the modus from a developer's perspective.

The point being, don't use assumptions about management motive to bolster your arguments.  When you do, you're
attributing motivation and behavior unfairly.

- Ed

Re: official recommendations of Ada

[Mike Silva]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> I work in an environment dominated by C/C++, and I would like to
> recommend Ada for a safety-critical application that is about to be
> initiated. I think official recommendations of respected standards
> organizations will carry a lot of weight. I came across a reference to
> IEC-1508, for example, which apparently recommends Ada. However, the
> document must be ordered and costs over $100. Yes, I should go ahead
> and get it, but I am wondering if the actual Ada recommendation is
> available online somewhere. Also, does anyone know of other official
> recommendations of Ada over other languages for critical software
> (either online or available through snail-mail)? Thanks.

One thing isn't clear to me -- is your "environment" already
developing safety-critical apps?  If so, are they using C or C++?

Mike

Re: official recommendations of Ada

[James Rogers]

Larry Kilgallen wrote:
> 
> In article <5be89e2f.0107200443.678562ea@posting.google.com>, codesavvy@aol.com (codesavvy) writes:
> > 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> >> I work in an environment dominated by C/C++, and I would like to
> >> recommend Ada for a safety-critical application that is about to be
> >> initiated.
> 
> > From management's view point, using Ada instead of C/C++ is taking a
> > major risk and when push comes to shove management probably will not
> > take such a risk unless they can see the "payback" in using Ada.
> 
> In some cases, management may be willing to try "something different"
> that does not disrupt the whole shop.

Occasionally management is willing to try something new in an attempt
to find a way to reduce costs or improve time to market. During those
times it may be reasonable to suggest a change of languages, if only
for a small, experimental project.

If management believes that everything is going as well as it can
then there is no future in suggesting change. You must wait for
the management confidence bubble to burst. It usually does when
the economic outlook for the company worsens.

You need to act when management is beginning to worry, but before
they think the only option is to cut all funding and avoid all risk.

Jim Rogers
Colorado Springs, Colorado USA

Re: official recommendations of Ada

[Pascal Obry]

codesavvy@aol.com (codesavvy) writes:

> From management's view point, using Ada instead of C/C++ is taking a
> major risk 

What is the major risk ?

You probably know the statistics: more than 80% of projects (at least in my
domain which is Information System) are doubling the budget or the time to
deliver or both.

So the risk the manager is going to take is:

  "Well, let me risk to have this project be delivered on time"

Quite a hard to take risk, right ?

I think the manager and developers don't want to switch just because they are
not willing to do something different... just keep doing what we have always
done.

You'll say, but the cost of learning a new language ?

I'll answer, no problem for a real and experienced developer team. Just a week
of practice. The problem is not the language but the underlying principles:
OO, encapsulation, abstration, information hiding...

Just my 2 cents,
Pascal.

PS: I'm a guy who have taken the risk for a IS project :)

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: official recommendations of Ada

[Pascal Obry]

Just let me add that I do understand that the language is only a part of the
problem. But at least switching from C++ to Ada is quite easy to do.

Other problems (far more complex to fix):

- software not well specified (over specification)
- team not trained sufficently in general
- inssuficient project management
- software not well designed
- configuration management
- too many peoples on the team
- the team does not quite understand the domain they are working on
  (I've seen a banking project using float for the money (under C++) because
   the team have been working on scientific projects before !)
- ...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: official recommendations of Ada

[codesavvy]

Ed Falis <efalis@mediaone.net> wrote in message news:<3B590D83.A15CC947@mediaone.net>...
> codesavvy wrote:
> 
> > From management's view point, using Ada instead of C/C++ is taking a
> > major risk and when push comes to shove management probably will not
> > take such a risk unless they can see the "payback" in using Ada.
> 
> Since I've been "management", I have to say that "management" is not homogenous.  Your generalizations are
> just that. There's a lot more variety of approaches than your stereotypes (a la Dilbert) would lead one to
> believe.  You think there's no conflict of ideology and business strategy at that level?  

Do you take risks without seeing the "payback"?  What other
generalizations are you talking about? What stereotypes  are you
talking about?  Where do I state that there's no conflict of ideology
and business strategy at the management level?


>Often enough, taking
> measured risk is _the_ way through, though it doesn't appear to be the modus from a developer's perspective.
> 

Oh so in order to take a risk you have to see the appropriate
"payback."  Thank you for supporting my statement.

> The point being, don't use assumptions about management motive to bolster your arguments. 

Apparently my assumption about taking a risk applies to you.

> When you do, you're
> attributing motivation and behavior unfairly.
> 

How did I do this specifically?


> - Ed

Re: official recommendations of Ada

[codesavvy]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uvgkmspa6.fsf@wanadoo.fr>...
> codesavvy@aol.com (codesavvy) writes:
> 
> > From management's view point, using Ada instead of C/C++ is taking a
> > major risk 
> 
> What is the major risk ?
> 

Good points.  There's also a risk in not finishing the project.  

> You probably know the statistics: more than 80% of projects (at least in my
> domain which is Information System) are doubling the budget or the time to
> deliver or both.
> 

In a subsequent portion of the thread I made a reference to a
productivity metric.  I stated that if they are not taking data and
applying a metric then I'd start by getting them to do that.  That is
the only way that I know of to start making accurate estimates. So if
the organization has accumulated data from previous development
projects the schedules should be accurate.  If the organization does
not believe in taking such data then I don't know that they will ever
realize that Ada helped them if they use it.


> So the risk the manager is going to take is:
> 
>   "Well, let me risk to have this project be delivered on time"
> 
> Quite a hard to take risk, right ?
> 

I like the way you put that actually.

> I think the manager and developers don't want to switch just because they are
> not willing to do something different... just keep doing what we have always
> done.
> 
> You'll say, but the cost of learning a new language ?
> 
> I'll answer, no problem for a real and experienced developer team. Just a week
> of practice. The problem is not the language but the underlying principles:
> OO, encapsulation, abstration, information hiding...
> 
> Just my 2 cents,
> Pascal.
> 

Ok I'll go along with that approach.  I refer you to Jim Rogers
comments though.

> PS: I'm a guy who have taken the risk for a IS project :)
> 
> -- 
> 
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|         http://perso.wanadoo.fr/pascal.obry
> --|
> --| "The best way to travel is by means of imagination"

Re: official recommendations of Ada

[Hambut]

hfrumblefoot@yahoo.com (Hambut) wrote in message news:<fb75c450.0107171332.18376cd6@posting.google.com>...
> Hi,
> 
> It's been a dull evening tonight, so I thought I'd have a wade through
> the stuff I've got to hand to see what I can find with respect to Ada
> recommendations.  This may help - it might at least be a starting
> point.
> 

Another reference:

Extracted from "NASA Guidebook for Safety Critical Software - Analysis
and Development", NASA-GB-1740.13-96

"5.3.11.8 Programming Languages: Conclusions
A technique for evaluating safety-critical languages has been
described along with other
considerations for implementers and for choosing a vendor. The Ada
subset we have described
is suitable for safety-critical systems. Although a Pascal subset is
suitable it was not described
because Ada is rapidly becoming the most common language on new
projects. The choice of "C"
is to be avoided for our domain of interest because the language lacks
the features that permit
robust, reliable programming. The Ada subset minimizes the
insecurities that were discussed in
this entry by restricting the misuse of certain features. The
objective of the subset is to define an
unambiguous syntax so that the semantics can be used for proofs if
necessary. All Ada
implementations have defects and implementers of safety-critical
systems should review the
historical defect list to verify that the problems have been addressed
and fixed in a timely fashion"

Re: official recommendations of Ada

[Rod Chapman]

hfrumblefoot@yahoo.com (Hambut) wrote in message news:<fb75c450.0107212304.c63df1a@posting.google.com>...

> Extracted from "NASA Guidebook for Safety Critical Software - Analysis
> and Development", NASA-GB-1740.13-96
> ...The Ada subset we have described
> is suitable for safety-critical systems.

I too read this document with some interest.  It is both encouraging,
and also slightly baffling.  The subset mentioned above is actually
identified earlier in the document as "SPADE Ada", by which I suspect
the authors mean SPARK.  Despite this advice, my database shows
precisely zero NASA sites using the SPARK Examiner... ho hum... :-)
 - Rod

An Assumption I Did Make (Was Re: official recommendations of Ada)

[codesavvy]

One thing I didn't mention that seemed clear from my post but perhaps
it wasn't is that I assumed that management colectively is competant. 
I was assuming that management could accurately predict the level of
effort needed to complete projects and had meaningful productivity
metrics in place.  I also assumed that management was "risk averse"
which I consider to be a good thing.  So I am assuming that management
will identify project risks and management them accordingly.  When I
say tha qualitative arguments will fall on deaf ears I wasn't putting
down management.  In fact I believe managers that would accept
qualitative arguments that would lead to schedule uncertainty when it
was not necessary would be acting irresponsibly.

Ed Falis <efalis@mediaone.net> wrote in message news:<3B590D83.A15CC947@mediaone.net>...
> codesavvy wrote:
> 
> > From management's view point, using Ada instead of C/C++ is taking a
> > major risk and when push comes to shove management probably will not
> > take such a risk unless they can see the "payback" in using Ada.
> 
> Since I've been "management", I have to say that "management" is not homogenous.  Your generalizations are
> just that. There's a lot more variety of approaches than your stereotypes (a la Dilbert) would lead one to
> believe.  You think there's no conflict of ideology and business strategy at that level?  Often enough, taking
> measured risk is _the_ way through, though it doesn't appear to be the modus from a developer's perspective.
> 
> The point being, don't use assumptions about management motive to bolster your arguments.  When you do, you're
> attributing motivation and behavior unfairly.
> 
> - Ed

Re: official recommendations of Ada

[Colin Paul Gloster]

In article <5be89e2f.0107210501.4d268a00@posting.google.com>, codesavvy wrote:
"Pascal Obry <p.obry@wanadoo.fr> wrote in message
news:<uvgkmspa6.fsf@wanadoo.fr>...
 > codesavvy@aol.com (codesavvy) writes:
 > 
[..]
 > 
 > What is the major risk ?
 > 
  
[..]  There's also a risk in not finishing the project.  
  
 > You probably know the statistics: more than 80% of projects (at least in my
 > domain which is Information System) are doubling the budget or the time to
 > deliver or both.
 > 
  
  In a subsequent portion of the thread I made a reference to a
  productivity metric.  I stated that if they are not taking data and
  applying a metric then I'd start by getting them to do that.  That is
  the only way that I know of to start making accurate estimates."

Hold on. You did not refer to a productivity metric. You imagined that
there is a productivity metric. In
news:5be89e2f.0107221953.8a52@posting.google.com you actually said
"[..] I was assuming that management could accurately predict the level of
effort needed to complete projects and had meaningful productivity
metrics in place. [..]". I have not read all of your posts in your "Ada
The Best Language?" thread but I have not seen you actually describe
properly nor name any of these metrics which you claim would be
useful. Perhaps eventually in "Ada The Best Language?" someone pointed you
towards a metric other than Source Lines Of Code but it seems that you are
still as ignorant of empirical productivity metrics now as you were when
you started that thread.

Also, instead of saying that subsequently somewhere in this thread you
said something, please have the decency to make a better reference as to
how exactly your post can be found. Right now for me it was not a problem,
but imagine you make another five posts with fairly similar claims and
someone else only then starts reading the thread. Without scruntizing
timestamps (and not all archives show the timestamps nor show a diagram of
which post is in which subthread) it may be difficult for them to see if
you are backtracking etc..

"So if the organization has accumulated data from previous development
projects the schedules should be accurate."

Where Russ is does not seem to have ever worked on a safety critical
mission before so why -- how even -- would it have its own records on
previous schedule programmes? As for histories ensuring future timeliness,
bear in mind that one of the founders of financial applied maths -- a
French man named Bouchalleit (unsure of spelling) -- maintained that the
past and present have pretty much no bearing on future prices. And since
you love to default to C++ (e.g. evidence from
news:bebbba07.0107162313.66a58a69@posting.google.com with added stress:
"18k11tm001@sneakemail.com (Russ) wrote in message
news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> I work in an environment dominated by C/C++, and I would like to
> recommend Ada for a safety-critical application that is about to be
> initiated. 

EXCELLENT, you're probably going to have an incredibly hard sell [..]" )
when productivity studies extolling Ada are not winning you over, perhaps
you would like to look at the "accu-general: Making estimates about
work" thread from this month on the accu-general emailing list of the
Association of C & C++ Users ( HTTP://WWW.ACCU.org/ ; archive available to
members only; I highly recommend membership of the ACCU).

From the first of these accu-general posts:
"[..]

How do you all approach the task of making estimates of how long it will
take you to do your work?

[..]".

A not necessarily representative but not the only response of this sort:
"When I'm spending time & effort on having realistic estimates, I try to keep
track of how long previous tasks took. Then I base estimates on past
performance. i'm still not very good with estimates, though."

Back to "codesavvy":
"If the organization does not believe in taking such data then I don't know
that they will ever realize that Ada helped them if they use it.

[..]"

But if they just start collecting these data (which you have yet to
satisfactorily (or even try to) exhibit that they work and that you
understand anything about collecting them and exactly which sorts of data
these are anyway) from right now as opposed to having already had a
tradition of doing so, they will not have enough of a sample space for
many years. This is not to denigrate harvesting, but you did not get Russ
to back you up on such a practice already being installed therein so you
have a problem there.

Software Metrics (was Re: official recommendations of Ada)

[Marin David Condic]

I would like to ask a favor of those in this thread who have an interest in
productivity metrics: Please define and explain the metric(s) you would be
interested in collecting. (This is not an attempt to insult or deride
anyone - I'm professionally curious about what metrics have been used to
measure productivity and/or what metrics might be considered valuable for
measuring productivity. If you feel slammed, then submit a post to asuage
your guilt! :-)

In a past life, I measured productivity in a study of control system code.
(This was comparing Ada to other languages used in control system
development). The numbers may not be significant for other types of systems
as a result. It should be useful for other embedded/realtime apps with
all/most code being developed from the ground-up. (No we didn't have an
RTOS, or libraries of utilities, etc. We had (with Ada at least) the RTK
that was provided with the embedded compiler and that was about it.) Without
covering the development process in detail, this is basically what we did:

All software was under a CM system, so we could identify modules changed
between two times. We presumed that to add a new module, delete a module or
change a module (even a single line of code in it) you basically had to read
and understand that module, so you got credit for the whole thing.
Statistically, module size didn't vary hugely, so we didn't think we'd see
much skewing of results due to modifying a single 10,000 sloc module
regularly. Over time, we thought it would all average out enough to be
useful.

We could easily get man-hours/month for a given project. We could relatively
easily get modified modules (reduced to a semicolon count of all modules)
within a month. Hence we could calculate some version of SLOCs/Fortnight.
Introducing Ada and other factors moved our productivity from about 35
SLOCs/Hour to roughly 70 SLOCs/hour. (Not all credit could be given to Ada
alone - there were other high level tools introduced to go with it.)

Defects were another matter. We had a change request system tied to the CM
system, so it was easy to identify all change requests made in a month. The
submitter of a CR and the approver of a CR both made some kind of
determination of if the CR was asking for an enhancement/new feature or if
it was correcting some kind of deficiency in the code. Deficiencies were
chalked up as defects and counted. Introduction of Ada (and the tools)
resulted in reduction of defects by a factor of four. We largely credited
Ada for this (rather than the tools) because of the types of errors that
were being eliminated. Most of the errors that were not being made were the
kinds of things that the syntax/semantics of Ada were not allowing to occur.
(scaling errors, indexing errors, addressing errors, etc. Exactly the sort
of errors that C/C++ would *not* catch and eliminate.)

Anyway, that outlines my experience with collecting productivity numbers and
I would appreciate other ideas about how y'all would personally go about
doing it. This is because I'm interested in what people would consider to be
a *meaningful* measure of productivity. If we expect to state that Ada is
superior for productivity, we could maybe be clear about what we mean.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message
news:slrn9lqaf7.k5j.Colin_Paul_Gloster@camac.dcu.ie...
>
> But if they just start collecting these data (which you have yet to
> satisfactorily (or even try to) exhibit that they work and that you
> understand anything about collecting them and exactly which sorts of data
> these are anyway) from right now as opposed to having already had a
> tradition of doing so, they will not have enough of a sample space for
> many years. This is not to denigrate harvesting, but you did not get Russ
> to back you up on such a practice already being installed therein so you
> have a problem there.

Re: official recommendations of Ada

[codesavvy]

>>In a subsequent portion of the thread I made a reference to a
  productivity metric.  I stated that if they are not taking data and
  applying a metric then I'd start by getting them to do that.  That
is
  the only way that I know of to start making accurate estimates."

Hold on. You did not refer to a productivity metric. You imagined that
there is a productivity metric. In
news:5be89e2f.0107221953.8a52@posting.google.com you actually said
"[..] I was assuming that management could accurately predict the
level of
effort needed to complete projects and had meaningful productivity
metrics in place. [..]". I have not read all of your posts in your
"Ada
The Best Language?" thread but I have not seen you actually describe
properly nor name any of these metrics which you claim would be
useful.<<

First of all I did look for the productivity metric that I posted as a
strawman and I couldn't find it in that thread.  Apparently you're
trying to pin me down to a metric that is useful for all organizations
which I can't do.  The point is that the current thinking in software
engineering is that processes that can make reliable schedules are
accomplished by collecting data and determining metrics for estimating
future productivity.  Do you dispute this?


> 
> Also, instead of saying that subsequently somewhere in this thread you
> said something, please have the decency to make a better reference as to
> how exactly your post can be found. Right now for me it was not a problem,
> but imagine you make another five posts with fairly similar claims and
> someone else only then starts reading the thread. Without scruntizing
> timestamps (and not all archives show the timestamps nor show a diagram of
> which post is in which subthread) it may be difficult for them to see if
> you are backtracking etc..
> 

Ok but I don't want to get hung up on a specific metric which you seem
to want to discuss.  My post regarding my assumption of management is
self explanatory I'm sorry if you didn't get it.


> "So if the organization has accumulated data from previous development
> projects the schedules should be accurate."
> 
> Where Russ is does not seem to have ever worked on a safety critical
> mission before so why -- how even -- would it have its own records on
> previous schedule programmes? As for histories ensuring future timeliness,
> bear in mind that one of the founders of financial applied maths -- a
> French man named Bouchalleit (unsure of spelling) -- maintained that the
> past and present have pretty much no bearing on future prices.<<

Apparently you don't agree with the current thinking regarding
software engineering processes.  Apparently you don't put much stock
in the CMM either.  Your analogy doesn't apply to software
development.

>> And since
> you love to default to C++ (e.g. evidence from
> news:bebbba07.0107162313.66a58a69@posting.google.com with added stress:
> "18k11tm001@sneakemail.com<<

Huh?  What does this mean?  I've already acknowledge that I think Ada
95 is a better programming language than C++.

I'll try to make this clear.  My original response in this thread was
based on an assumption of what I consider to be rational management. 
I don't think that I'm the only one who shares those opinions.  If
management is acting irrationally I would start by trying to get them
to act rationally.  This is the same approach that is taken in other
disciplines when analyzing and discussing the decision making process.
 If you have another definition of rational management then please
bring it to the forefront.

>> (Russ) wrote in message
> news:<bebbba07.0107162313.66a58a69@posting.google.com>...
> > I work in an environment dominated by C/C++, and I would like to
> > recommend Ada for a safety-critical application that is about to be
> > initiated. 
> 
> EXCELLENT, you're probably going to have an incredibly hard sell [..]" )
> when productivity studies extolling Ada are not winning you over, perhaps
> you would like to look at the "accu-general: Making estimates about
> work" thread from this month on the accu-general emailing list of the
> Association of C & C++ Users ( HTTP://WWW.ACCU.org/ ; archive available to
> members only; I highly recommend membership of the ACCU).
> 
> From the first of these accu-general posts:
> "[..]
> 
> How do you all approach the task of making estimates of how long it will
> take you to do your work?
> 
> [..]".
> 
> A not necessarily representative but not the only response of this sort:
> "When I'm spending time & effort on having realistic estimates, I try to keep
> track of how long previous tasks took. Then I base estimates on past
> performance. i'm still not very good with estimates, though."
> 
> Back to "codesavvy":
> "If the organization does not believe in taking such data then I don't know
> that they will ever realize that Ada helped them if they use it.
> 
> [..]"
> 
> But if they just start collecting these data (which you have yet to
> satisfactorily (or even try to) exhibit that they work and that you
> understand anything about collecting them and exactly which sorts of data
> these are anyway) from right now as opposed to having already had a
> tradition of doing so, they will not have enough of a sample space for
> many years. This is not to denigrate harvesting, but you did not get Russ
> to back you up on such a practice already being installed therein so you
> have a problem there.

Re: official recommendations of Ada

[Colin Paul Gloster]

Colin Paul Gloster posted moments ago:

"[..] as I compose this there are 198 posts in the ["Re: Ada The Best
Language?"] thread already[..]"

Thank goodness I have such a fast news feed! Of course the thread I
am writing in and was just writing in a moment ago is much smaller.

Re: official recommendations of Ada

[Colin Paul Gloster]

In article <5be89e2f.0107241106.5a696d65@posting.google.com>, codesavvy wrote:
">>In a subsequent portion of the thread I made a reference to a
    productivity metric.  I stated that if they are not taking data and
    applying a metric then I'd start by getting them to do that.  That
  is
    the only way that I know of to start making accurate estimates."
  
  Hold on. You did not refer to a productivity metric. You imagined that
  there is a productivity metric. In
  news:5be89e2f.0107221953.8a52@posting.google.com you actually said
  "[..] I was assuming that management could accurately predict the
  level of
  effort needed to complete projects and had meaningful productivity
  metrics in place. [..]". I have not read all of your posts in your
  "Ada
  The Best Language?" thread but I have not seen you actually describe
  properly nor name any of these metrics which you claim would be
  useful.<<
  
  First of all I did look for the productivity metric that I posted as a
  strawman and I couldn't find it in that thread."

For one thing, when you followed up to Marin David Condic saying that
he must have missed that strawman post, you did not give better details as
to what post that was in (and please note this can be important if you
want to be really accountable, as I compose this there are 198 posts in
the thread already, 21 by you, I have so far read and understood 18 of
yours; but at least unlike Bob Leif you do a better job of threading).

I did read it originally. For some reason searching on
HTTP://groups.Google.com was not very useful this time
(author: codesavvy ; with word in body: strawman ; with word in
subject: Best ; from: comp.lang.ada )
but I found it again anyway. From
news:5be89e2f.0107181029.1e09f6c0@posting.google.com :
"[..] As a strawman let's define productivity as number of hours per
function point that yields less than or equal to a given defect rate per
hour of acceptance testing.  For example:

Say a developer is equally competant in Ada 95 and C++. Say this
developer uses C++ and takes 40 hours of a developers time per
function point that yield a defect rate of 1 defect per 40 hours of
testing.  Could you reasonably expect the same developer to take only
20 hours per function point that yields a defect rate of 1 defect per
40 hours of testing?  I sincerely doubt it but I could convinced
otherwise.

[..]".

As a strawman it may only have been meant as a gentle example. You may
still be ignorant of any rigorous or usefull or cheat-immune measurement
process.

"Apparently you're trying to pin me down to a metric that is useful for all
organizations which I can't do."

What I was trying was not that as such. But you have yet to name a single
one applicable anywhere which does not really indicate any familiarity
with the concept on your part. As for Russ's case: if they have some
process for current and past projects then it may be worthwhile to
continue exercising it on their new project. So far we do not know that
such a culture is already installed there.

Furthermore if you believe that there is no one way suitable for every
organization then how can you expect there to be one for a single
organisation suitable to every problem domain, apparently in the case of
Russ's organization: a problem domain they have never entered before.

"The point is that the current thinking in software engineering is that
processes that can make reliable schedules are accomplished by collecting data
and determining metrics for estimating future productivity.  Do you dispute
this?"

No dispute. Win me over if you want: show me that every single process
ever "that can make reliable schedules" is "accomplished by collecting
data and determining metrics for estimating future productivity."
  
"> 
 > Also, instead of saying that subsequently somewhere in this thread you
 > said something, please have the decency to make a better reference as to
 > how exactly your post can be found. Right now for me it was not a problem,
 > but imagine you make another five posts with fairly similar claims and
 > someone else only then starts reading the thread. Without scruntizing
 > timestamps (and not all archives show the timestamps nor show a diagram of
 > which post is in which subthread) it may be difficult for them to see if
 > you are backtracking etc..
 > 
  
  Ok but I don't want to get hung up on a specific metric which you seem
  to want to discuss."

If you would like to go on about a few that may be fine: better in a
discussion on them than mentioning exactly nought.

"My post regarding my assumption of management is self explanatory I'm sorry if
you didn't get it."

I did get it.
  
  
"> "So if the organization has accumulated data from previous development
 > projects the schedules should be accurate."
 > 
 > Where Russ is does not seem to have ever worked on a safety critical
 > mission before so why -- how even -- would it have its own records on
 > previous schedule programmes? As for histories ensuring future timeliness,
 > bear in mind that one of the founders of financial applied maths -- a
 > French man named Bouchalleit (unsure of spelling) -- maintained that the
 > past and present have pretty much no bearing on future prices.<<
  
  Apparently you don't agree with the current thinking regarding
  software engineering processes."

How exactly do you explain my drawing of attention -- at 23 Jul 2001
10:43:38 -0400 in news:slrn9lo12g.q0p.Colin_Paul_Gloster@camac.dcu.ie in 
"Re: C++ vs. Ada for safety-critical applications" on
news:comp.lang.c++.moderated -- to real contradictory systems and software
engineering practices in response to Richard's (Lao Xiao Hai's
<laoxhai@ix.netcom.com> 's) demeaning of neglecting good ideas (such as
type safety and sensible driving on roads), since Richard's comments were
detached from the conditions of these environments?

"Apparently you don't put much stock in the CMM either."

Which of course would explain why I think that something on level five of
the Capability Maturity Model would be more orderly and accountable than a
start-up at CMM1. Please have an argument, yes?

"Your analogy [was not an analogy -- the future is not determinable] 
doesn't apply to software development."

So the laws of physics are different if you adopt an on-going empirical
study of your software development process? I think not. Another
Association of C & C++ Users ( HTTP://WWW.ACCU.org/ ) member disagrees with you
on this (from the accu-general thread I already mentioned):

"[..]

Watching The Simpsons last night, Professor Frink said, when asked if the
project he was working on would be ready on time, "I have visited the
future, and yes it will."

[..]

Wonderfully appropriate to most scheduling situations in software
development. 
You can never be sure that it will be ready on time, because you can't
visit the future.

[..]"

">> And since
 > you love to default to C++ (e.g. evidence from
 > news:bebbba07.0107162313.66a58a69@posting.google.com with added stress:
 > "18k11tm001@sneakemail.com<<
  
  Huh?  What does this mean?  I've already acknowledge that I think Ada
  95 is a better programming language than C++."

Please do not treat me as a dolt who has not read that you think that Ada
is better than C++ umpteen times. You have tried to point out to others
what exactly you have said. I will tell you exactly what "since you love
to default to C++" means. It means since you love to default to C++. Is
that clear? Many times you have shown us that you would choose C++ over
Ada on a non-technical justification if you were not shown that Ada would
be much more productive than C++ (not a symmetric condition though, you
would use C++ without being shown that it is much more productive than
Ada). 

Saying
"Excellent, you're probably going to have an incredibly hard sell"
is a point of evidence for this.
  
"I'll try to make this clear.  My original response in this thread was
  based on an assumption of what I consider to be rational management. 
  I don't think that I'm the only one who shares those opinions."

You are not adding anything new to the discussion here. Indeed you quoted
my quoting of you saying that.

"If management is acting irrationally I would start by trying to get them
  to act rationally.  This is the same approach that is taken in other
  disciplines when analyzing and discussing the decision making process.
   If you have another definition of rational management then please
  bring it to the forefront."

There is not even one definition there already. So what if I decide I am
going to coin "rational management" to be an adjective meaning hairier
than yellow? What benefit would there be in striving to ensure that
whatever you are aiming for fits every possible meaning denoted by a label
(a lazy shorthand which can be confused with identical labels denoting
subtly and unsubtly different concepts) of "rational management"?
  
">> (Russ) wrote in message
 > news:<bebbba07.0107162313.66a58a69@posting.google.com>...
 > > I work in an environment dominated by C/C++, and I would like to
 > > recommend Ada for a safety-critical application that is about to be
 > > initiated. 
 > 
 > EXCELLENT, you're probably going to have an incredibly hard sell [..]" )
 > when productivity studies extolling Ada are not winning you over, perhaps
[..]"