SCOUG-Programming Mailing List Archives
Return to [ 28 |
October |
2007 ]
Content Type: text/plain
"...Now we have other fourth generation additions like "rules"
to cover. We will put off our consideration of these until
after we cover testing, the fifth stage of software
development."
Note that of the first four stages--specification, analysis,
design, and construction--only the first remains people-based
while the other three we have turned over to software. Of
course people have to write that software so that it can do
those three stages. Fortunately that means exists in all
fourth generation languages. So we have nothing to invent,
only implement.
In the matter of testing, the fifth stage of SDP, we have to
write test cases, test scripts for each test case, and test data
for each test script. Three sources to create, maintain, and
synchronize. Nominally we estimate testing to require at least
twice the amount of time for construction. Even at that we
accept the "fact" that we cannot completely test the source
logic. Thus in addition to our internal testing against our own
test cases, scripts, and data we employ "beta testers" to
expand the number of test cases, scripts, and data, all of
which further increases our test time...and total testing effort,
i.e. people resources consumed.
So how can we minimize the people time, effort, and
resources? We did it in the first four stages by shifting
everything after the first stage to software. Can we not do
something similar with respect to testing? Yes.
We gained something else in shifting to a fourth generation
language. Every fourth generation language relies on a
two-stage proof engine, a completeness proof and an
exhaustive true/false proof. The completeness proof provides
the means for the software to do the analysis, design, and
construction stages. The exhaustive true/false proof offers us
two options for creating test data, continue to use
people-created data (clausal logic) or let the software create
the data (predicate logic). No actual difference in program
logic occurs, i.e. no change to an assertion statement. The
difference lies in the data definition.
If we assign a set of possible values to a data variable which
logically translates into "for all x where x = values1, values 2,
...", the software will create each of the possible instances of
the range of values specified for each variable. It will then
enumerate all of the possible combinations of the set of
variables.
Now understand that as the number of variables in the set
increases that an even greater increase in the number of
combinations will occur. Thus we may have decreased the
amount of people effort in creating the test data, but we will
have increased significantly the amount of people effort to
"verify" the test results.
Normally we have deadlines in developing and maintaining
software. Those deadlines include a fixed amount or upper
limit on test time which includes test case, script, and data
preparation, execution of the test, and verification of test
results. Though we have the means of automating the first
two, preparation and execution, through software that could
through the sheer number of results take the
people-verification beyond the allotted test time.
So we can have a far more complete testing process without
the need for beta testing or testers, but that could still
exceed the time allotted due to the people-verification
process. We will need to address this, but here simply note
that we do have a means with a fourth generation language
to largely automate the testing stage as well.
At this point we have completed our automating of the SDP
where people only write specifications (which software
cannot) and software writes the rest (where people need
not). We have done this through one change only, shifting
from a third to a fourth generation language.
Now granted I've chosen a third generation language, PL/I, for
which no fourth generation equivalent exists. Thus the need
to add the necessary upgrades while retaining backward
compatibility. However, the features and functions of those
upgrades do exist in other fourth generation languages. Thus
only the language specific upgrades, e.g. syntax, need occur.
This hardly qualifies as a "silver bullet" as it doesn't bring
anything to the table which did not already exist. So far we
have not introduced a process change as the "writing
problem" derives from the implementation, not the SDP
process. We have the universal acceptance of SQL, a fourth
generation language, that demonstrates this.
With the major process of the five stages of the SDP intact
we can now go on to looking at the sub-processes and
possible changes in the specification and testing stages, the
only two continuing to involve people input (writing), effort
(thinking and verifying), and resources (numbers). We need
to look at minimizing these.
=====================================================
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
"postmaster@scoug.com".
=====================================================
Return to [ 28 |
October |
2007 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
