Re: Required Metrics

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

In article <kdKQ4.8331$wb7.618601@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> Except, of course, for those of us who read the word
> "requirement" as it's
> used in software engineering.

And there perhaps lies the crux of the problem, a formal
language definition has almost NOTHING to do with an informal
"software engineering" requirements document. It is that
confusion in the understanding of the word requirement that
lies at the heart of the confusion. Indeed, most software
projects are specified with a requirements document where
the requirements are often very much subjective, and not
anywhere *near* being a mathematical formal specification.

> 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.

You keep saying this, but that does not make the argument
here any more convincing. The documenatation requirements
are trivial to meet. Everyone meets them, no one ignores them.
That of course is from a formal language specification point
of view, but the standard is a formal language specification,
nothing more and nothing less.


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

Please don't bring your software engineering background to
the table, you will just confuse yourself, it is irrelevant.
Yes, a lot of people don't understand this, including some
people who participated in the language design effort. A
background in formal language semantics is much more relevant
here, and I definitely think you will have trouble writing
semantic equations for the documentation requirements, no
matter WHAT formalism you choose. Yes, we chose to use formal
english (which is not that great mathematically) to describe
the semantics of Ada 95, so that it would be more accessible,
but it has to be equivalent to a formal specification in
some sense, or it is useless.

It's a bit like the controversy over translating the bible into
english. When this was first done, priests worried that people
would look at the result and try to interpret in an informal
context which would lead to misunderstandings. I leave it to
others to judge whether there concern was misplaced, but for
sure there is a danger in making standards accessible if people
start reading them like software engineering specifications.

Now the "implementation advice" sections of the RM *can* be
read this way, and including these sections was a brilliant
innovation on the design team's point of view, because it
allowed us to state informal pragmatic implementation
"requirements" where requirements here is used in Ken's sense
of software engineering, without contaminating the formal
definition with junk.

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

Yes, I think it's fair, reread what you said.

> Like I said, "with a pen in the hand, and a song in the
> heart."

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.

> 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.

All requirements are requirements. I am not saying that the
documentation requirements are not requirements, just that
they are trivially met.

> You may believe that the ACVC review board, and all other
> vendors, agree with you.

You mean I agree that there can be no formal tests for whether
you meet the documentation rquirements. I cannot imagine anyone
with any reasonable knowledge thinking otherwise.

> 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.

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.


> > 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. Here is
an example (there are hundreds maybe thousands of others)

                         Implementation Requirements
15   An implementation shall support lines of at least 200
characters in length, not counting any characters used to
signify the end of a line.  An implementation shall support
lexical elements of at least 200 characters in length.  The
maximum supported line length and lexical element length are
implementation defined.

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???????

> 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.

>
> !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.

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.

This reminds me of people who use to operate under the curious
illusion that validation had something to say about guaranteeing
that a compiler was usable (of course failing validation does
say that a compiler may NOT be usable, but passing validation
does not for a MOMENT constitute a guarantee that a compiler
is usable).

Perhaps we should have used VDM for the Ada standard after
all -- it would certainly have helped eliminate uncertainties
and for sure would have avoided this kind of user confusion :-)





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