I would hope that you do not find an assertion like matching
the solution set to the problem set so abstract as to associate
it with finding code bugs only and not with insuring that the
output vision matches the input one.
Your versions 1.01 and up should not reflect the correction of
code bugs, which should not exist if detected logic errors
corrected, but changes in the visions as a proper evolution of
the problem set. When versions do not go from 1.0 to 2.0 to
integer amounts on up you have a situation which would not
occur using the automated testing process using logic
programming that I described: different versions for different
visions, including those that change over time.
Like you I have seen the cartoon that starts with a vision,
processed by multiple minds, and ends up a distortion: a
mismatch between the problem set and the solution set. Like
others I too have played the message passing game only to
laugh at how badly we can distort something in multiple steps
of translation.
For that reason I prefer to limit the translation to one, that
from requirements to specification, leaving it up to the
software to perform the remaining translations correctly. We
have a 30+ years experience in logic programming to know
that it can. That's more than the 1,000,000 years of human
experience has shown us as a hit or miss situation.
For the record there are no code bugs, only buggy people
who write code. You can only have a code bug if the
executable code does not follow the logic of the source. In
that instance you have a compiler or interpreter error, which
once fixed never again makes that mistake. Something else
seldom achieved consistently in people.
If you use logic programming, you cannot have either an
analysis bug, a design bug, a construction bug, or a testing
bug. You can only have two sources of error: (1) the
requirements or (2) their translation into specifications. You
have only two sources of correction, requirements and
specifications.
If you have complete and correct requirements along with a
correct translation, then you have complete and correct
specifications. You can validate either of these through
testing. That says that correct input produces correct output
and incorrect input produces incorrect output. You, not the
software, has to have the smarts enough to know which is
which.
If something is left out, that is an error of omission. You may
call it an oversight. It means something is left out of the
requirements or their translation into specifications. You still
only have two sources to correct.
I only make the point that you have no need for either
"outside" alpha or beta testing and thus "outside" alpha or
beta testers. You may want to have "outside" validators to
distribute the validation workload volume produced by the
software, but you don't need them for actual testing.
Someone is bound to bring up hardware dependecies or
inconsistencies. They cannot bring them up in a way not
specifiable as they would have no means of compensating in
source code.
The issue does not lie in how often requirements change as
we expect that to occur. The issue does lie in having the
change dynamics of the solution set at least equal to that of
the problem set so that we can implement changes as fast as
they occur. That level of rapidity possible with logic
programming reduces the "change intervals", so-called version
levels, to a fraction from weeks and months currently to
minutes and hours.
After writing the changes to the specifications and submitting
them to the software, the only remaining time lies in
validating the automated test results. Unfortunately that
remains a people thing that also unfortunately Goedel or
someone has proven will remain so and not possible with
software.
So, Peter, thank you for your input.
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 02 |
January |
2004 ]
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.
