Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!srvr1!maize.engin.umich.edu!zarnuk
From: zarnuk@caen.engin.umich.edu
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Keywords: Software ENGINEERING, Software Development Management
Message-ID: <1990Jun13.070649.14929@caen.engin.umich.edu>
Date: 13 Jun 90 07:06:49 GMT
References: <37538@genrad.UUCP> <55137@microsoft.UUCP>
Sender: news@caen.engin.umich.edu (CAEN Netnews)
Organization: University of Michigan, Ann Arbor
Lines: 55


>>(Jim Adcock) rants :-) 
>>  ... The traditional approach tends to be management heavy --

But that's exactly the goal of Software Engineering -- to make the
software development process more MANAGABLE.  How can management
make intelligent decisions about allocating resources if nobody
can answer the most fundamental questions about what resources
will be necessary and what benefits can be expected for/from a
software development project?  

The traditional approach is management heavy, because that is where
the real problems are in software development.  The problems with
software development are not technical, they are managerial (or 
sadly enough, political).   

However, I'd say that the scope of most CASE tools and Software
Engineering methodologies in general place far too much emphasis
on the actual development of software to the shameful neglect of 
MANAGING the process.  Little or no attention is paid to deciding
which projects to pursue, or calculating the cost/benefits of 
pursuing/abandoning projects.  There is certainly not enough 
attention paid to TRAINING MANAGEMENT to make decisions that 
will promote the strategic goals of an organization.  

There are still problems with developing software, but if management
is willing to COMMIT themselves to pursuing the projects that will
promote their organization -- anything can be built.  Things may 
get rocky in the design and development arena occasionally, but they
get solved with patience and plodding.  When management is perpetually
pursuing the "instant buck" and flipping and flopping between which
projects they have a "hard on" for today -- nothing gets built.  


>>  ... Everything done is documented on paper.

Ever been stuck trying to maintain undocumented systems?  


>>I claim OOP is quite different than this.  It is not naturally a top-down
>>approach, but rather a topless approach ...

I agree that OOP is not amenable to the standard Top-Down Structured Design
approach.  I also believe that OOP is "the next step" to generating higher
quality code more quickly, but saying that OOP is topless is nothing more
than saying that you are an anarchist (no prejorative intended).  When I 
design OOP systems, I start out by identifying objects and their various
domains of responsibility.  The boundaries "float" somewhat once development
gets under way, but the project starts out with a design!  Yes, development
proceeds in a "bottom-up" manner, but there's nothing new in that -- many
developers design "top-down" then implement "bottom-up".  Ultimately, even
OO systems require some action-oriented control sections (notably at the
top!).  

---Paul...