SCOUG-Programming Mailing List Archives
Return to [ 24 |
December |
2003 ]
Content Type: text/plain
Cris,
I felt the need to also respond to some other comments you
made in your last message. We should add another stage in
front of the software development process (SDP), that of
requirements or requirements gathering. Normally we gather
them into groups or batches before passing them into the
formal, five stages of SDP: specification, analysis, design,
construction, and testing.
Note that normally requirements do not occur in batches.
They also do not occur in logical order. In short they
frequently occur individually and in random order. Due to the
way we have implemented the SDP, the methodology use, and
the software tools supporting it, immediately transferring an
individual requirement, a change request, into the process in
random order would quickly bring the process to a halt.
We should note, however, that we want to effect a change
request as quickly as possible, immediately if possible,
regardless of the order or timing of their occurrence. That we
cannot currently do so does not represent a failure of the SDP
as sometimes falsely claimed, but a failure of implementation.
Imperative languages (first, second, and third generation)
created the need for the SDP which represents the optimal
logical order of processing. In fact it's more than optimal: it's
absolutelyl necessary. Any deviation from this order results in
non-optimal effort, i.e. a loss in efficiency or productivity.
That does not mean that deviations do not occur in practice.
They happen all too frequently. You get in analysis to
discover incomplete or missing specifications. You can have a
similar discovery in design of a failure in analysis or
specification. You can in construction discover a failure in
design related to one in analysis relating in turn to
specification.
These discoveries in later stages of errors in earlier should
mean going back to the earliest stage in which the error was
introduced, correcting it, and then proceeding forward. In
short it should follow Deming's theory of quality control,
which works for software as it does for any other process.
If you don't do this, if you don't reflect the correction in the
earlier stages, then the source for each stage gets out of
sync. That means new change requests coming into the
process will reflect the error condition in going from one stage
to the next.
You seem to indicate that these processes can occur in a
different order. In practice they do. In every instance it leads
to a rework of some kind, which may or may not get reflected
back to its source. When source, when documentation gets
out of sync beyond a loss of efficiency, i.e. productivity, you
also create a conflict situation, which frequently degenerates
to a personnel conflict, of one group distrustful of another or
believing them incompetent.
Now all this goes back to the use of imperative programming
languages. While requirements and specifications can occur in
any order the manual functions of analysis, design, and
construction demands that the input to code generation have
a logical organization of source code. In imperative languages
that logical organization, globally and locally, is the
programmer's responsibility, by definition a manual operation.
In logic programming, i.e. declarative languages, that logical
organization becomes the software's responsibility as part of
the completeness proof. It follows then that any logical
re-organization due to specification changes remains the
software's responsibility.
Thus declarative languages accept logical or rule-based
source segments in any, i.e. random, order which they in turn
impose an optimal logical organization. Thus as quickly as a
change request can be translated into its set of specifications
we can enter it into the SDP. It should be possible in practice
to effect changes in the solution set (the software) more
rapidly than they occur in the problem set (the user world).
In short no persistent or growing backlog should occur.
Therein lies the advantage of using a fourth generation,
declarative specification language which is also a
programming language. An advantage also occurs in using it
until it becomes a programming language, regardless of having
to translate it meanwhile into some third generation form like
C or C++.
=====================================================
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 [ 24 |
December |
2003 ]
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.
| 
