SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Fri, 2 Jan 2004 16:51:59 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"osfree" <osFree@yahoogroups.com > , "scoug-programming@scoug.com" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

"...Having spent a few years writing requirements, I found
that it's pretty hard to define the requirement adequately, up
front, and the waterfall of the development process results in
a refinement of the requirement manifested in the sequential
specs. The code becomes a sulf(sic)-fulfilling requirement
baseline, no matter what the original spec. Probably
accidental if it actually matches the designer's intentions. ..."

Ah, a second voice heard from. Must be an open moment
during the holidays. Thank you, Dave, for taking time to
comment.

The waterfall effect as you describe it changes radically in
logic programming in that only two stages have people input:
requirements and specification. The remaining stages occur in
software: analysis, design, construction (completeness proof)
and testing (exhaustive true/false proof). So only two errors
in translation can occur, one in translation from the user to
written requirements (informal logic) and their translation into
specifications (formal logic). The software translates the
specifications exactly as written, i.e. no transmission loss.

Note that having the software perform these functions you no
longer have programmer analysts, designers, or coders. The
designer's intentions then must reside in the written
specifications. If they don't result in the expected, i.e.
intended, then he wrote them wrong (errors of commission) or
incompletely (errors of omission). He corrects them by
correcting the writing. He does not do analysis, design, or
coding beyond the specifications.

It seems difficult to accept to accept that software can
adequately perform these tasks. Yet daily millions of users
have trusted SQL to do exactly that...for the last 30 years. If
you respond that an SQL query doesn't quite match up to the
more extensive logic and levels found in a program, that a
program using embedded SQL has to also include additional
logic outside the query, then I would have to refer you to an
AI product like IBM's TIRS (The Intelligent Reasoning System).
TIRS does the whole logic including the writing of the SQL
query.

Peter also comments:
"...Dave, you've identified the true path -- writing the spec.
Lynn has also been pushing the spec as the one true
document but he's constantly trying to incorporate it into code
generation using just-in-time manufacturing techniques and
hallowed echoes of H. Edwards Deming (plus Homer Sarasohn
and Charles Protzman, to be fair). It's much easier to
digest "writing the spec" when there's a wall between design
and manufacturing, and Lynn's dream might more quickly bear
fruit if he took that tack."

A wall between design and manufacturing. In imperative
languages that wall exists by necessity: it has to do with the
logical organization globally in the sourceby people prior to
submitting it to manufacturing, i.e. compiling. In declarative
languages, i.e. logic programming, it ceases when you submit a
specification to processing. The software in the completeness
proof does analysis, design, and construction in a seamless
stages with no loss in transmission or translation.

Get use to it. Get use to the idea of saying what you want in
an unordered, disconnected manner in terms of writing
specifications. Get use to the idea that the software has all
the capabilities that humans have in performing analysis,
design, and construction. You tell it "what" you want. It tells
you "how" to get it.

It's not some dream of mine. It's how logic programming
works. It's how SQL works. It's how AI works. It's how neural
nets work.

A difference that occurs lies in the thousands and millions
reduction in time for the software to do analysis, design,
construction, and testing over having people do it. To make a
few changes to specifications, submit it, and few seconds (or
even minutes) later to have the complete results of the
effects of those changes ought to suffice that analysis and
design reside inherently in specifications. They do for people.
They do for software.

This means that you do specifications at one point in one
source in the process regardless of the number of iterations of
that process. That means you do requirements at one point in
one source in the process. You don't get involved with the
writing of either, with detection and correction of errors of
omission or commission, at some later point.

You do what SQL query writers do. You write a query. You
view the results. If they are not what you want, you rewrite
the query. The query design is pre-structured in the
"SELECT...FROM...WHERE" clauses. Inside those clauses the
structure is user-specified in any order that the user chooses.
In fact within the "FROM" and "WHERE" clauses the order is
unimportant. Obviously the SQL processor demonstrates that
it can do analysis, design, construction, and testing without
any further "input" from you.

I'll reserve commenting on Peter's references to Deming, et al
except to say that once you get by the effort for problem
detection, i.e. validating the exhaustive results of execution,
you need to correct it at its source. When you only have two
sources which occur sequentially in time you don't have to go
back to requirements unless it exists there. If it doesn't, then
you only have to change the specifications.

In short you only have two sources to maintain in sync. These
two sources represent two different but equivalent
descriptive forms. It's only between these forms that either a
loss in transmission or translation can occur. Any that do
definitely lie outside the purview of the software:
people-based.

You end up from a people's perspective with a drastically
short portion up front of the total waterfall. You never have
to tread water beyond that portion while you always get to
see it in its entire glory. You can change that flow
extensively with very small changes in your portion. It reacts
immediately to any such change. You do not apply the term
"immediately" when you have people responsible for the
entire waterfall.

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

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