SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 4 Jan 2004 22:31:25 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Zdenek Jizba writes:
"This discussion is quite interesting, but IMHO problems arise
that do not fit any mold. A case in point: ..."

I will make the point I made early on with Peter. Every
programming language is a specification language. Thus
anything you code in any language is a specification. It has
nothing to do with any "mold" or type of application. If you
can code it, you can specify it, because that's what you have
just done.

You perform analysis on specifications to see if contained
within them you have enough information even though
incomplete. You check to see if you have a seamless path
from all your outputs to all your inputs. If you don't, then you
need to gather more specifications to fill in the gaps. At some
point you decide that the remaining gaps will not adversely
effect a design and you move into the design phase. Where
the emphasis in analysis was in data flows, that seamless path
between inputs and outputs, emphasis in design is on modular
flow. Modular flow seeks to create a hierarchy of functions
from the highest level to the lowest. When you have that
then you move on to construction.

What's important here is that all of analysis, all of design, all
of construction derives from the specifications. In short they
are implicit, inherent in the specifications. Getting them out
becomes a clerical task. If clerical, if performed to certain
rules, also specifiable, then you can automate them in
software. If you automate them in software, that means for
the same output that you have time left over for something
else.

It seems silly to me to hear people constantly complain that
they didn't have enough time to do the job right, that they did
not have time to correct detected errors, that they did not
have time to enter changes which occurred in the interval,
that they did not have time to document the system properly,
that they did not have enough time to test the system, that
they did not have enough time to ..., to then challenge
something whose principal reason for existence lies in saving
them time. It seems to me that you would more than welcome
something that better offered you the time to do all those
things. Maybe you just didn't want to do them, found yourself
with an excuse not to, and now feel threatened that the
excuse may disappear.

These are general remarks, not directed at anyone
specifically. I truly appreciate the comments of all
participants and their willingness, sometimes their
overeagerness, to challenge opinions expressed here. I don't
know why suddenly this much activity has occurred, but I
want to encourage its continuation. It provides some of the
background that we can address in our monthly meeting
where we can overcome some of the constraints of this
particular media.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 04 | January | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.