Re: Quality (Re: status of PL/I as a viable language)

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

You can never escape the necessity of testing. Whatever you build will
ultimately be tested so long as it is actually used. Either you test it or
your customer tests it. But that said, testing can't build in quality. It
can only demonstrate quality - or the lack thereof. Ideally, you would build
a product, test it and find zero errors or defects. That would reflect
building the quality in. Going through a cycle of testing it, fixing it,
testing it again, fixing it again,,,,, is an attempt to test the quality
into a product. Using that approach, you might eventually get to zero
defects, but it takes longer and costs more than if the test immediately
revealed zero defects.

Ada is not the end-all, be-all of software development. It is absolutely not
going to guarantee that you get to zero defects. However, one of the things
I really like about Ada is that it tends to catch lots of simpler errors up
front and never lets them get into the finished product. (Things like type
checking, parameter/interface checking, bounds checking, etc.) On my project
I know from metrics that this saves me cost & schedule compared against the
use of some other languages. (Fortran, C and Assembler, mostly) To the
extent that a language eliminates errors up-front, I think that goes to
"Building Quality In" and the odd thing is that it costs less to build a
better product.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote in message
news:mCH6a.102$8M5.44@read3.inet.fi...
>
> When you talk about quality, I think a key issue is a discussion about
building quality versus testing quality. What means
> "building quality into something"?
>
> The paradoxality lies in that you never can avoid the situation of "First
Do It And Then Test What You Have Done".
> With "testing" I mean any way (test, review ...) to convince that some
entity is fulfilling the requirements put on it.
> If you write an essay, the only way to have linguistically correct text is
to write a sentence and check (test) your sentence. Then
> write the next sentence. And check it.
> The only way to guarantee that you spread butter all over your slice of
bread is to spread the butter and then check that you have
> it all over the slice.
>
> So, how do you then _build_ quality into your product or computer program?
By "testing" smartly! By taking your time to plan a
> "testing" schedule all over the lifetime of the project. By leaving all
testing to the end you just create a big bang and hope that
> the bang is a positive one. By splitting the development project into
smaller pieces the bangs are smaller and hence the damages of
> having negative bangs become significantly smaller.
>
> The thing you have to decide is then: How often do I test? How small
pieces do I test?
> In a software project you have requirements in the beginning and a running
software at the end. What you have in between is your own
> choice as a project manager. Your choice may be to build a protype and run
a test suite on it, create next proto and test it. Or
> your choice may be to divide your project into phases of specification,
design and coding and have a testing or review after each
> phase.
> The specification and the final piece of code (maybe together with
necessary hardware) both should demonstrate the end product
> entirely. Hence it should be possible to test the requirements of the end
product on both embodiments. If the tests show shortages
> or inaccuracies the embodiment is incomplete and should be corrected
before the project continues. If the specification has passed
> your tests (or review, whatever), then you KNOW (as John R. Strohm writes)
that you have a correct specification of the end product.
>
> My experience of development projects in electronics and steel industry
has strengthen my above described opinion about the value of
> dividing the whole project into phases. I have participated in projects
where we systematically worked through the project starting
> from a verbal specification of the product and ending at a hand held
measuring device with correct functions and accuracy and look.
> I have also seen development projects ending in a bitter situation where
the project manager defended his ideas about a successful
> product because that discussion was never held earlier in the project. In
the latter situation the project manager DID NOT KNOW
> whether or not he was on the right track until at the end of the track.
>
> Anders
>
>