Re: Required Metrics

[Robert Dewar <robert_dewar@my-deja.com>]

In article <Gt7R4.8719$wb7.695096@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:

> > Nope! No "song in the heart", which I take to mean with an
> > intent other than a formal declaration. Perhaps you have
> > some other meaning, if so, it is obscure to me.

> I do have some other meaning, and apparently it is obscure to
> you (even though you quote its meaning in the following):

OK, you still don't say what that "other meaning" is.

> or vacuously met, to quote previous posts? as in: "all other
> requirements are 'met' no matter what"?
>
> Perhaps you have some meaning for vacuous or trivial that is
> obscure to me!

Right, as I said earlier, I think the problem you have in
understanding just comes from unfamiliarity with the notion
of formal language definition, and the history and function
of language standards documents. You are expecting them to
do something they can NOT by nature do, a common
misunderstanding indeed. As I say, closely related to the
peculiar notion, so very common in Ada 83 days, that validation
guaranteed quality and usability.

> No, I mean that you may believe that the ACVC review board
> agrees with you, based on your statement in a previous post:
>
> "By the way, the ACVC review board discussed this briefly.
They immediately
> agreed that these requirements were too ill-defined to even
consider
> including them in conformance assessment."

Right, this was a completely uncontroversial position. I cannot
imagine anyone who understood the notion of language
definitions, conformance and validation testing disagreeing.

What would you have in mind? That we have a section of the ACVC
testing that includes Ken Garlington sitting down, reading the
documentation and announcing that it meets his (nowhere defined)
criteria for acceptable documentation? Ken is free (more than
free, encouraged) to do this as part of his acceptance testing,
but only for his own purposes.

Actually Ken, you said something VERY revealing earlier on. You
talked about tightening up the standard to make compiler vendors
do stuff that they had not done in Ada 83 compilers in this
area so that the costs could be shared.

Let's examine this thought a bit further.

First. It's really an inappropriate distortion of the market
to attempt to include requirements that YOU want, but the
market place does not in general want, in an attempt to get
other people to pay for things that you need that they don't
want (if they wanted them generally, they would be there,
competition works that way).

Second, Even ignoring the dubious justification for such an
attempt, it is bound to fail. Why? Because language standards
are not about providing good documentation, useful information,
or even about producing usable compilers. They are nothing more
than a set of mathematical formulae, informally expressed in
this case, that dictate certain input-output properties that
a compiler must have. The language standard by its nature can
only ever be a small part of the requirements.

You might hope that "beefing up" the standard would help solve
YOUR problem and relieve you of YOUR responsibility for devising
the set of requirements for your tools and making sure you
acquire tools that meet these requirements, but this attempt is
bound to fail. Language standards are NOT software engineering
requirements documents, and no amount of yelling or complaining
can change this fundamental fact.




>
> Isn't it at least possible that I simply mean what I say?
>
> > There is no list of non-requirements, because there are no
> > non-requirements. THe DOC requires that you have not made
> > any intentional deviations from the FULL SET of
requirements,
> > including the documentation requirements.
> >
> > > 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.
> >
> > intentionally is of course critical. Otherwise the DOC would
> > be a declaration that your compiler was bug free. This is
not
> > intended, and would be impractical.
>
> That's right. You can sign the DOC "with a pen in the hand and
a song in the
> heart", and still make an unintentional mistake. Perhaps,
even, a certain
> kind of unintentional mistake relevant to the topic at hand.
And yet, the
> meaning of my statement above still eludes you. Unfortunate,
but there's no
> point in banging my head against that wall any further.
>
> > > > 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.
> >
> > Of course implementation requirements are requirements, what
> > gave you the lunatic idea that this is not the case. I say
> > lunatic here, because it simply makes no sense. There are
many
> > critical implentation requirements. Where ON EARTH did you
> > get this idea, certainly not from anything I wrote.
>
> Except for the bit you quoted from your earlier post:
>
> "Nope, the issues with pragma Reviewable are also all
documentation based,
> let's look:"
>
> So, which is it?
>
> (a) the ***implementation*** requirements for pragram
Reviewable should be
> treated like documentation requirements (vacuously met), or
> (b) they shouldn't (i.e. it is possible to fail to meet them).
>
> If (a), then how does someone determine which other
***implementation***
> requirements are vacuously met, and which are critical?
>
> > This is formally definable, and of course tested by the ACVC
> > tests. Again, I ask where did you get the idea that
> > implementation requirements are not requirements???????
>
> From you. You should really read the implementation
requirements for pragma
> Reviewable, they're quite extensive. None are tested by the
ACVC, of
> course...
>
> >
> > > 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.
> >
> > Actually many useful things came out of those meetings, but
if
> > you thought that the meetings were about requiring vendors
to
> > provide useful usable implementations, you were indeed
deluding
> > yourself, since language standards can never guarantee this.
>
> Actually, I thought we were working on a useful usable
standard. That is, an
> agreement from the vendors as to the text of the
implementation requirements
> included the concept that the vendors understood what they
meant!
> Apparently, I was mistaken.
>
> > > !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."
> >
> >
> > This is plain silly, I can't imagine the ARG giving it much
> > attention, since it amounts to nothing more than an
unfounded
> > polemic. There is no part of the Ada community that
considers
> > any requirements in the RM not to be requirements, and
> > certainly the vendor community does not ignore any
requirements.
>
> Note my definition of a requirement: "i.e., it is possible for
a vendor to
> 'fail' to meet it." So, which is it?
>
> (a) There are areas of the standard that have the word
"requirement"
> attached to them which are vacuously met by all vendors.
> (b) There aren't.
>
> You may consider it "plain silly" to take items in (a) and
label them
> implementation advice, and I'm sure the ARG will give it no
attention (I
> mean, how much weight should my opinion hold?). At least, when
a user comes
> to me and says, "if this is crap, why is in the standard?" I
can say, "beats
> me, I tried to get it fixed, but no one cared."
>
> > Again, I think the entire problem comes from the fact that
you
> > don't really understand the purpose of a formal language
> > definition, and that you read the word "requirement" in
> > (to use your terms) "software engineering" sense, which is
> > totally misleading in this context.
>
> Absolutely! An equally elegant solution to the problem to this
would be to
> put in the front of the standard:
>
> "WARNING: Terms used in this standard, such as 'requirement,'
do not have
> their usual English meaning."
>
> > (by the way, I suddenly realize that you Ken
> > converts my general use of semantic into the headings in the
> > manual, don't make that mistake, semantics includes a lot
more
> > :-)
>
> Excellent! Light begins to dawn. Now, the slippery part: How
much more?
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.