Re: Required Metrics

["Ken Garlington" <Ken.Garlington@computer.org>]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8eukm0$ssm$1@nnrp1.deja.com...

>   It has always been true that documentation requirements like
>   this do not belong in the standard. As to why they got in, I
>   think your posts have vividly illustrated the thinking behind
>   those who argued for putting them in. To me a classical
>   case of confusing desirable implementation features with
>   formal semantic requirements.

In a word: Bullshit. This gets repeated (somewhat condescendingly)
throughout your response, but it's a total strawman.

Could you cite ONE case in this thread where I argued in favor of including
ANY requirement, documentation or otherwise, in the standard?

It's getting depressing, but I'll make one last run at my position:

ONCE A REQUIREMENT ENTERS THE STANDARD,  IT'S A REQUIREMENT UNTIL IT'S
REMOVED.

If a requirement shouldn't be in the standard, don't add it.
If a requirement is in there that shouldn't be, then remove it (or indicate
that it's only advice).

How hard could this be? At best, it's weakly coupled to the issue of which
requirements _should_ be in the standard.

If you want to discuss whether a requirement should or should not be in the
standard, fine. Start another thread. If you'd go back and read what I said
earlier, you'd see that I'd probably agree that documentation requirements
shouldn't be in there. So what?

>   You keep saying this, which means you still do not understand
>   the issue here, which is that we are talking about formal
>   semantic requirements.
>
>   On the contrary, everyone has met it, since from a formal
>   point of view, documentation is not defined, and therefore
>   can be defined anyway you want.

OK, so everyone always meets the requirements of the standard that aren't
formal semantic requirements? Good software engineering practice would say
that they aren't requirements then **and should be identified as such**. If
I understand ARM 1.1.2 (24-39), then the only "real" requirements are:

25 Syntax: Syntax rules (indented).
28 Static Semantics: A definition of the compile-time effect of each
construct.
30 Dynamic Semantics: A definition of the run-time effect of each construct.

Is this correct? I'd be happy to send in a comment to this effect to note
this in the standard, if we agree on this list. Actually, since there
appears to be complete agreement among the vendor community (and the ACVC
review board) as to what's in and what's not in, I guess it doesn't matter.
See the comment at the end.

>   And that probably accounts for the overwhelming lack of
>   interest in getting more accessible forms of this
>   documentation, since it was (like much of the RT annex)
>   framed with bare board single processor implementations
>   in mind, whereas modern reality is more likely implementation
>   over an OS or 3rd party RTOS.

Which is really depressing for those of us who still build bare-board
systems, but the use of DSPs and other "non-mainstream" processors has
pretty much taken Ada out of the running for us, anyway, so that's probably
why you're not seeing any demand. However, that's a different issue.

> > Why go through the motions to
> > formally establish the requirement and get a consensus
> documented and
> > approved, if there's not an equal intent to do something
> formal (an AI, at
> > least) to remove such a "bogus" requirement?
>
>   Lots of us knew these requirements were bogus, including
>   key people on the design team (e.g. Bob Duff). You fight
>   many battles in a consensus process. This one was not
>   worth fighting at the time, since the effect of these
>   requirements is negligible in practice. We knew they
>   would end up being useless of course, but we also
>   knew they would not be harmful.

Except, of course, for those of us who read the word "requirement" as it's
used in software engineering. However, once we get the list of
non-requirement requirements accepted, this is easy to fix.

You know, I lose those requirements battles from time to time myself. It
never occured to me to just ignore the ones that I considered infeasible to
meet.

> > It appears like the classic
> > case of people writing down a requirements document just
> > because the
> > customer says you have to do one,
>
>   Well, you paint with too broad a brush. This particular
>   phenomenon (documentation requirements) was indeed a
>   matter of responding to customers who did not really
>   understand the issue. But the great majority of the
>   Ada RM is not vaguely related to this process.

Whenever someone makes a post about how Ada is used by software engineers,
and other languages are used by hackers, I'm going to think about this
paragraph.

> > Again, the issue of whether it's an appropriate requirement is
> > interesting, but it's not the real issue. I'm still not
> > convinced that you meet the
> > requirement in the current release, for that matter.
>
>   Well try to prove this formally. First you will need a
>   formal definition of "documentation" *derived from the
>   RM*.

Why can't I use the definition of "documentation" *provided by the vendor*?

> That will be hard. For example, are you sure that
>   this documentation must be in English? What if I provide
>   it in Navaho or Klingon, is that sufficient, or, more to
>   the point here, what if I provide it in Ada 95.

What if you do, so long as you say "This is what I'm providing to meet the
requirement"?

Again, you're confusing "what a customer wants" with "what the standard
requires". In software engineering, validation addresses the former,
verification the latter.

>> > For a validated compiler -- difficult! In particular, how
>> > can the DOC be signed if you have ignored a requirement.
>>
>> I suspect with a pen in the hand, and a song in the heart!

> Ken, do you think it is fair to accuse vendors of dishonesty
> and duplicity with no evidence at all to back up your
> statements.

Do you think it's fair to accuse me of such an accusation, when the quoted
statement doesn't actually say that?

> I will say right away that I personally sign
> all DOC's for Ada Core Technologies, and in all cases I
> do so with integrity knowing that what I am signing is
> absolutely correct. I would assume that all other vendors
> would make the same statement.

Like I said, "with a pen in the hand, and a song in the heart." Of course,
your signature is based on your determination as to which requirements are
"real" requirements, believing that all other requirements are "met" no
matter what. You may believe that the ACVC review board, and all other
vendors, agree with you. You may be right, for that matter. If you're wrong,
there's no way to find out, since apparently the list of non-requirements
has never been formally established, and nobody (not even the vendor) checks
that any requirement is met beyond passing the conformance test.

You might want to re-read your original statement: "How can the DOC be
signed if you have ignored a requirement?" Note that the word
"intentionally" does not appear.

>> I suspect, after you read the discussion of pragma Reviewable,
>> we're going to be expanding this to "documentation and
>> some implementation requirements"

> Nope, the issues with pragma Reviewable are also all
 > documentation based, let's look:

Yes, let's. Specifically, let's look at the words which appear just before
paragraph 5:

***** Implementation Requirements *****

"5 The implementation shall provide the following information ..."

Now, I suspect you're using the term "documentation" informally, not in the
sense of ARM 1.1.2. However, since all Implementation Requirements, like all
Documentation Requirements, are not really requirements, perhaps we _should_
use the same name for both.

When we were discussing these safety and security requirements during that
industry-implementors meeting lo these many years ago, I was frankly
surprised that the vendor representatives (including yourself) didn't put up
more of a fuss. Now I see why. What a total waste of our time.

-----

From: Ken Garlington [mailto:Ken.Garlington@computer.org]
Sent: Friday, May 05, 2000 7:55 PM
To: ada-comment@sw-eng.falls-church.va.us
Subject: Non-Requirement Requirements

!topic Non-Requirement Requirements
!reference RM95-1.1.2(24-39)
!from Ken Garlington 00-05-05
!keywords requirements, advise
!discussion

The referenced paragraphs define several different categories of the
standard. Some of these categories use the term "requirements," although
they are not considered requirements by the Ada vendor community. There
should be an explicit list of which categories can be considered
requirements (i.e., it is possible for a vendor to "fail" to meet it). All
other categories should be described in the terms currently used for
"Implementation Advice."