Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!bellcore-2!bellcore!dduck!duncan
From: duncan@dduck.ctt.bellcore.com (Scott Duncan)
Newsgroups: comp.software-eng
Subject: Re: CASE, the Little Red Hen, and Stone Soup
Message-ID: <26230@bellcore.bellcore.com>
Date: 28 Aug 90 11:37:58 GMT
References: <26229@bellcore.bellcore.com>
Sender: news@bellcore.bellcore.com
Reply-To: duncan@ctt.bellcore.com (Scott Duncan)
Organization: Computer Technology Transfer Division
Lines: 55

Sorry for the mix ups in that last posting.  I had a screen display problem
which, apparently, obscured what was actually in the posting.  Here's a cor-
rected version.

In response to a query about the requirements for a CASE environment, it has
been said that

>        The requirements are that it helps me create more software
                                            ^^
>better and faster.
 ^^^^^^     ^^^^^^

and that

>                    Any technology or methodology is acceptable as
>long as it improves the quantity, quality and delivery schedule.

Unfortunately, the basic requirements are totally subjective, i.e., valid for
individual work habits and effort but not necessarily valid for people who
have to interact with others in developing a system.  By whose standards is the
development "better":  according to a customer's view of the end-product or
some internal measure related to the developers' ease?  How fast does it have
to do this:  just somewhat faster than someone, alone, can do it now or faster
for a couple hundred people?

I'm not defending CASE tools by any means, but requirements based on just one
person's needs and standards don't help an entire industry deal with the issue
of CASE.  Perhaps CASE's biggest problem (and that of most tech transfer) is
that just "[a]ny technology or methodology is [not] acceptable" to people,
especially the latter.  The implied methodologies behind many CASE tools and
environments are just what many complain about.  That is, the methodology or
practice offered by the CASE tool(s) (e.g., balancing data-flow diagrams) is
not what many currently use to create software, so asking them to do it is
adding work, at least to their individual piece of the effort.

>I am waiting for the "CASE" people to come up with a design.
>Meanwhile, don't tell me that "tool integration" [sic] is the answer.
>"Integrate" means to incorporate parts into a whole; show me the whole
>first, and then I might buy the integration method.

I think this is a valid comment; however, what many industry customers of CASE
seem to be asking for is the integration approach, i.e., flexibility in mixing
and matching pieces rather than a monolithic whole.  They seem to be saying
that they'd prefer an approach that offers them choices, rather than locking
them into, potentially, a single vendor for their CASE environment.  The
"whole" is likely to be from the perspective of a single vendor unless many
major vendors team up to agree on an architecture.  (I realize this is happen-
ing, to some extent, in the mainframe marketplace but, at the moment, just for
that market and only for more traditional business data processing applications
where many large CASE vendors focus their attention.)

Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
                (Bellcore, 444 Hoes Lane  RRC 1H-210, Piscataway, NJ  08854)
                (908-699-3910 (w)   609-737-2945 (h))