Why and how do organizations select the OO approach to S.E

[agate!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!geraldo.cc.utexas.ed u!emx.cc.utexas.edu!not-for-mail@ucbvax.Berkeley.EDU (Ravi Kalakota)]

(A shorter version of this was posted in comp.object and comp.software-eng)


	Why and how do organizations select the OO approach to Software Eng.


I have been going though the software engineering literature (primarily
OO literature) to understand and enumerate the reasons why organizations,
firms or groups have chosen or were seriously thinking about using 
an object oriented approach to software engineering. There is an amazing
lack of objective, evaluative literature on the selection of methodologies
in software engineering. We seem to be carried away by the bandwagon effect
and are not spending enough time understanding the pluses and minuses of
new methodologies, their effectiveness in various types of application
development areas and their effect on people. I may sound pessimistic but
it is definitely time that we understood what external factors impact the
selection of methodologies and what impact does the selection of a methodology
have on the effectiveness of the development group. While the technical side
has progressed and is progressing, the management side is limping along with
lame theorizing which almost always has no practical value.    

Most authors also seem to be consultants and each of them is pushing his or
her own methodology without any assessment of how or why it better than the
other available methodologies in the market. Most of these people seem to 
be interested in making a quick buck before the "fad" loses its charm. These
people come across as snake oil salesman rather than objective people.

Milt Fulghun points out that at OOPSLA'92 that there was a noticeable hunger
for application and experience papers, panel sessions and workshops. How are
we satisfying this need?  

The best people for the kind of research which bridges the managerial aspects
with the technical are the people on the "western front", managers. 
Unfortunately, most of them don't have the time to dissipate or write 
about their experiences and this is one of the reasons why we are suffering.
We are unable to reuse the knowledge of the software engineers and project
managers. Hence this plea, I urge this group of people to share with me and
others the knowledge which would answer the following questions:

1. What are the factors that were considered and evaluated before you decided
to select an object oriented approach to software engineering?

I have found four broad categories: monetary, technical, organizational 
and political.

I have included personnel training and selection in organizational category.
I would appreciate your filling each category and suggesting more categories 
if these are not sufficient.

Milt Fulghun (fulghum@esds.mdc.com) response to Question 1 was the following:

>  Our primary reason for going to object orientation is that object
>  partitioning maps well into our application space, visual simulation.
>  We believe that object oriented software will be easier to maintain in
>  our environment.

According to Steve Berczuk (berczuk@space.mit.edu)

>  In the 2 projects I have worked on so far, the primary factor in selecting a
>  methodology was (yes, this is serious), what methodology (novice, until the 
>  time of taking a course in OO)  THE DECISION MAKER SAW in the first course 
>  that he took on Object-orientation.  Both times there were others in the 
>  project who had been building OO systems for at least a few years and were 
>  at least familiar with some of the OO methodologies, and these experienced 
>  people would find the choice to be wrong for various reasons.


2. What impact does the selection of object oriented methodology have on
the project sucess, customer satisfaction and learning for future projects?

I assume there are other factors other than the ones in Q1. which moderate this
relationship.

According to Steve Berczuk (berczuk@space.mit.edu)

>The methodology should be used to facilitate the DESIGN process as WELL as the
 
>documentation process. Probably the biggest problems arise from taking the 
>phrase "We'll use the XXX methodology" to mean "We'll use the symbols in the 
>XXX methodology" rather than using the methodology to explore the system.

With regard to Q1, I have found some stock or canned answers, such as:

	- software reusability (both code as well as design)

	- easier maintenance (mainly perfective and adaptive) 

	- faster time to market, by compressing the product lifecycle

	- ability to perform concurrent and parallel development

	- enhanced interoperability (??)

	- reduction of code complexity through encapsulation and information
          hiding 

	- better suitability for real-time systems.

However, probably the most common answer would be: software reusability.
But to implement software reuse, you need a clear organization policy to
make it a sucess. How many organizations have such a policy and enforce it
in practice? Does one come up with a policy before selection of methodology
or patch quilt one as one goes along. 

Ed Berard puts it very succinctly in his book "Essays ...."    

" Like object-orientation, software reusability is very much
misunderstood. Many people think that the pinnacle of software reuse
is a "library of math functions." What most software professionals do
not realize is that software reusability, like object-orientation,
impacts everything, from management practices to software development
standards, and much more."


Please email your thoughts to me and I will summarize, if people are
interested. Send your comments to  kalakota@emx.cc.utexas.edu


Thanks in advance,

-- Ravi

_______________________________________________________________________
Ravi Kalakota
University of Texas at Austin
Austin, Texas 78712                kalakota@emx.cc.utexas.edu
_______________________________________________________________________