SCOUG-Programming Mailing List Archives
Return to [ 08 |
June |
2007 ]
Content Type: text/plain
I would like to propose a summer recess for the Programming
SIG. On relecting on the disucussion during my presentation at
the last SCOUG meeting on the Data
Directory/Repository/Dictionary (DDRD) I have a huge
communication failure which I need to address. It will likely
take me the summer to right the course.
IT has had a single situation which has plagued it from the
beginning: the backlog situation. It results from receiving
change requests faster than we can implement
them...properly. That means putting them through the
development or maintenance process in proscribed manner
from specification (the "formal" rewriting of requirements into
unambiguous specifications) through analysis, design,
construction, and testing.
That process ultimately comes down to writing text and in the
instance of analysis and design writing visual representations.
CASE tools never offered to do analysis and design, but only
to increase the productivity in writing...and specifically
rewriting...the visual output. That rewriting often results in
reorganization. The CASE tools eased that process, but
obviously could not compensate for the user's skill or lack
thereof of analysis or design.
In any software system we have boundary points, essentially
interfaces between the external world and the internal
processes. These boundary points mark the inputs into and
the outputs out of the software system. Internally within the
system the inter-process flows (data) has internal inputs and
outputs known as datastores. OO technology refers to this
storage aspect as "persistent storage".
Nevertheless for every data item which appears at an output
must have a continuous path back through processes and
datastores to one or more inputs. This remains true even for
"virtual" data which depends upon "real" data for its
existence.
For example, the "12-month average on-hand balance" of an
inventory item depends upon the last 12 recorded months on
an on-hand balance. Thus each month a new on-hand
balance enters a datastore from which a process extracts the
last 12 and calculates the average which then appears on an
output.
The purpose of analysis then lies in insuring that the data
continuity exists between where data comes into the system
and where it goes out. The only things lying inbetween are
processes and datastores. So we have only four visual
elements--input, output, process, and datastore--to depict
analysis along with the data names which flowed from
process to process, process to datastore, or process from
input or to output.
Note that the analysis has to conform to the specifications and
vice versa. Each has a different source to create (write) and
maintain (rewrite)...and more importantly to keep in sync.
This writing, rewriting, and synchronizing must occur among
each stage in the process. Each additional stage adds its own
delay in the overall process.
Once we have an analysis which conforms to the data
continuity which has to exist from the inputs to the outputs,
we then proceed to design. The same conformity which
analysis had to have with specification design must have with
analysis. Thus each has a different way of indicating the
same thing. Each different way has its own source.
The analysis process described before replaced flowcharting
which had long dominated the process. The simple process
representation by a circle replaces a more detailed flowchart.
That amounts to less writing, rewriting, and synchronization.
Two factors accounted for this. One, programmers objected
to the rigidity of the logic inherent in the flowchart, especially
one not written by the programmer. Two, flowcharting
became post-source productions instead of pre- with the
introduction of flowcharting software from source.
Instead we have IPO (Input-Process-Output), the
transformation of input data form into that of the output with
the logical details left up to the programmer. Technically the
dataflow charts exist as a coherent set of IPO units, some
entirely within the system and others connecting to its
boundary points.
That offers an overview of "structured analysis" authored by
Larry Constantine and taught initially in IBM advanced learning
center, Systems Research Institute. Constantine also authored
"structured design" by introducing a heuristic from
transforming dataflows into structure charts, the hierarchical
representation of the modules (processes) within a program.
The heuristic basically tracked the path of the inputs into a
set of processes seeking the process in which they lost their
input form to take on the look of their output form. He
referred to this process as the "central transform". Looking
backward from the "central transform" created a downward
hierarchy of input modules (processes) and looking forward
created a downward hierarchy of output modules. Some of
the lower level modules had "central transforms" of their own
in which replicated the looking backward (downward)
process.
The structure charts used only rectangles for the modules,
replacing the dataflow process circle. It allowed only a single
vertical line to its top line to connect its entry point to the
higher level module invoking it. In turn it had lower lines from
its bottom line connecting to the modules it invoked. As a
final note we repeat that this representation had a source
different from that for the dataflow charts.
Now Constantine's structured analysis/design revolutionized IT
software development and maintenance. It did so particularly
for software contractors bidding for multi-million dollar
government contracts. In this highly competitive market this
tool allowed contractors to more quickly, correctly, and
accurately size the effort conforming to the specifications of
the government's RFP. Thus they could reduce their fudge
factor associated with the risk of both under- and
over-estimating the effort.
To one skilled in the methodology, thanks in large part to the
publications and personnel of the Yourdan Group at that time,
it offered an opportunity to get by the smoke screen of
insufficient specifications. I used to offer accounts the
opportunity to present me with their specifications for a
software system which I offered to provide an analysis and
design in a single afternoon.
Have some appreciation of the time difference between the
methods, formal and informal, they used and this approach.
You ignored detail logic, i.e. programming, in favor of an
overall representation of the processes and the data
continuity which had to exist among the inputs, outputs, and
datastores. This "abstraction" which ignored logic for
dataflows focused on the "coherence" or "completeness" of
the specifications, in essence determining if you could get
"there" (output) from "here" (input).
However, it did not solve the backlog situation. It did speed
up a segment (analysis and design) through the use of CASE
tools...if the user had the proper skills and training. Moreover
it was independent of the choices representing the
specification "language" or the programming language. Both
analysis and design were "data" driven and determined.
But it didn't solve the backlog situation. It didn't allow the
writing, rewriting, and synchronization of sources at a rate to
sustain or match that of change requests. Note, however,
that it did have a positive effect as opposed to the negative
effect that OO technology introduced with UML for analysis
and design.
The answer does not lie in increasing the number of sources
and languages to learn, write, rewrite, and synchronize.
Instead it lies in reducing them to a minimum, getting as close
to one as possible.
Therein lies the challenge. How to get to one. One source.
Then having minimal manual effort involved in its writing,
rewriting, and synchronization. Minimizing manual effort
through greater automation by software.
That doesn't occur by chance. Software can only do what we
tell it to do and how we tell it to do it. We have to set up an
environment in which the software following our rules allows
"people to write (and rewrite) what software cannot and
software to write, rewrite, and synchronize what people need
not". Then hopefully when we get to the point of minimal
human effort and maximal software effort it takes us less
time to effect a change request than its inter-arrival rate. If
so, we no longer have a backlog situation.
Now it may seem strange or you may have difficulty relating
the viability of OS/2-eCS, the major point of discussion in 1998
and presentation subject at Warpstock98 in Chicago. You
eliminate the backlog situation. You do it for the entire IT
population. You radically eliminate a whole edifice of manual
source writing, rewriting, and synchronization.
You radically reduce reduce the necessary personnel
infrastructure. You reduce it to a level well within the
capability of the active OS/2 developers. Moreover you
increase the ability of an active OS/2 user to transform into an
active OS/2 developer. You lower the barriers to entry to a
minimum.
It does not occur through the choice of a specific programming
language like SL/I. It does occur in part through the use of a
fourth-generation programming language with its two-stage
proof engine of a completeness proof and exhaustive
true/false proof. The choice of language does make a
difference if you want only one. It must be capable of doing
all that needs doing. Otherwise you have to have two, three,
four or more and thus raise the barrier to entry.
A fourth-generation language requires only the manual
writing and rewriting of specifications: the specification stage.
The completeness proof, the first stage of the two-stage
proof engine, does the analysis, design, and construction
(global organization of source into an executable). The
second stage of the two-stage proof engine performs the
testing. Here we have a choice of manually writing test data
or requesting it done by the software according to data rules
we specify.
Once again the choice lies in using a fourth-generation
declarative language as opposed to any of the previous three
generations of imperative languages. Which fourth-generation
language does make a difference in terms of universal
applicability. We may differ on which language but not on
which language generation.
=====================================================
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 [ 08 |
June |
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.
| 
