SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Mon, 17 Mar 2003 06:54:54 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	SCOUG Programming SIG <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Message One

Content Type: text/plain

IBM's AD/Cycle died due to vendors passive resistance to
implementing the very idea in which they had agreed upon to
implement. AD/Cycle dealt with formalizing the software
development process (SDP). It assumed a seamless fit of the
five stages of specification, analysis, design, construction, and
testing. That seamless fit decomposes in turn to a set of
activities within each stage, for each of which we have an
operational definition of the process and its interfaces. We
can represent each activity as an IPO model. By definition of
a seamless fit we can create a sequence of the activities from
initial entry of requirements to final production of a version.

No one reading this, no publication, no enterprise, and no
academic institution has ever defined any such seamless
sequence of activities. Despite the tools available to
successfully define user processes we have never applied
them to the process which uses them: the SDP.

It isn't that we can't. We certainly can. We can't, however,
do it, i.e. the seamless fit, with any combination of vendor
tools that have ever existed during the lifetime of
programming.

AD/Cycle then didn't assume that only one path of seamless
activities existed, i.e that there was only one right way.
There could be an unlimited number just as we have
essentially had an unlimited number of tools produced. No
tool covers more than a seamless segment of a path of
activities. Of all the possible segments ever covered in their
entirety no means exists of a seamless fit from gathering of
requirements to the production of a version.

It means simply that even if we made the minor effort to
define a seamless sequence of activities covering the SDP, we
have no set of tools which map into it. In short if the SDP is
the problem set, then we have never produced a matching
solution set. We have offered the user pieces, segments,
leaving it up to the user to somehow act as his own set of
"filters" to connect the pieces to support his implementation
of the SDP.

IBM proposed AD/Cycle to eliminate user filtering by getting
the tool vendors to use a set of well-defined interfaces, the I
and the O of the activity IPOs. The well-defined interfaces
meant having at least one seamless sequence of activities
from beginning to end. As previously mentioned this has not
occured period either before, during, or after AD/Cycle.

The tool vendors quickly understood what "standard"
activities and interfaces meant: no protected turf or niche
from which you could encroach on that of a competitor.
There was no sense in deliberately committing suicide. They
chose instead to die a slow death as almost none of them
survive today.

The SDP model is frequently called the "waterfall" process in
that its "central transform" occurs within the specification
stage when requirements get translated into specifications.
We can represent that as follows:

SDP
specification [process]
[input] -> [output]
(requirements) -> (specifications)
analysis
(dataflows) [output]
design
(structure charts) [output]
construction
(source code, modules) [output]
testing
(software version) [output]
After you have translated the input requirements into output
specifications in the specification stage it's all downhill, i.e. a
sequence of outputs, from there. Thus the "waterfall"
reference.

Both users and vendors could extrapolate the same meaning
of a successful AD/Cycle. It would result in a user's heaven
and a vendor's hell: a win-lose situation. Therein lay the
problem. Users wanted it. Vendors not wanting to displease
the user marketplace gave it lip support publically, but
practice passive resistance privately through an active "you
first, no you first" process of delay.

So we need some way to bring a win-lose situation into a
win-win one. That occurs in this instance of SDP tools by
erasing the distinction between user and vendor, in effect by
the user assuming the role of vendor. This means that the
user now acquires the essential claim of vendors: ownership
of the resultant code, ownership of a seamless set of SDP
tools.

Where in today's marketplace does the user assume the role
of his own vendor of SDP tools? In open source. This
completes the ownership circle in enterprises today which rely
on proprietary vendor tools they license but do not own to
develop application source code which they do own.

Open source gives them and us unrestricted ownership of SDP
tools which we can modify or distribute in any manner we
choose. If we choose to make the modifications freely
available, a basic tenet of open source and the GPL license,
then we can distribute them equally freely among ourselves.

So open source allows us to transform a win-lose situation
with closed (proprietary) source into a win-win one.
However, it will only do so if we carry the intent of AD/Cycle
to its completion: define a seamless set of SDP activities and
transform them into a seamless set of tools.

***************************************************

The previous paragraph marks a stopping point for this
message and a starting point for the next in which we will
repeat it. As it takes some time to actually author these
messages, at least an order of magnitude greater than it
takes to read them, I would like to know who in fact manages
to get this far and what, if any, value they received for the
cost in time of reading.

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

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 [ 17 | March | 2003 ]

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.