[comp.lang.smalltalk] OO Development Differences

schultz@grebyn.com (Ronald Schultz) (12/04/90)

Much has been mentioned on the net as to how the development of
OO software is significantly different than the development of
software using other approaches.  And so I ask, how much
different is OO development from conventional development when
comparing OO against other approaches from a development
management perspective?  Albeit from the developer's viewpoint
much is changed, but from a management perspective what has
changed?

1.   For instance, how have you found configuration management
     (CM) to be different ?

2.   How different is your development team organization ?

3.   How is quality assurance and control different ?

4.   How different are your schedules and estimating when done in
     an OO lifecycle vs. another approach ?

5.   How are your user specifications different ?

6.   If you are a contractor bidding for work, how do your OO
     proposals differ from your other development proposals ?

At the November meeting of an IBM Mainframe User's Group (GUIDE),
Dave Dykstal of IBM Rochester presented on the development issues
involved in developing a cooperative processing OO interface
between the AS/400 and IBM PS/2s under OS/2.  The presentation
highlighted the differences and conflicts between the development
team's spiral model of development and the rest of IBM
Rochester's waterfall lifecycle development.  Simple issues such
as defining 'when is the product ready to be documented?' became
a critical management issue when injecting OO into a development
staff.  

Any thoughts or comments would be appreciated.  I will post a
summary to the net if there is sufficient response.

Ron Schultz
schultz@grebyn.com
614-759-3127

johnson@m.cs.uiuc.edu (12/05/90)

One of the main reasons that people are attracted to OOP is reuse,
and managing for reuse is a lot different than managing traditional
software.

First, reuse doesn't happen by accident.  More particularly,
reusable software doesn't happen by accident.  Software that
was not designed to be reusable isn't.  Even if it was designed
to be reusable, it isn't reusable until it has been reused a
few times.

If you decide that you are not going to WRITE reusable software
but are only going to REUSE it then the impact of reuse will not
be that great.  You will need to schedule time for your people
to learn the software that you are going to reuse (don't think
that it will not take any time--it will!) and you might need to
assign someone to be the local expert on the package, but the
overall software process is not changed much.

However, if you are going to develop your own reusable software
then you will need a large change in your software process.
There needs to be a group of people (usually small) who are charged
with building the reusable framework that others will reuse.  It
is probably a good idea to have them start early, because it usually
takes several iterations to get a good framework.  Unless you have
experienced people who have built this kind of application before,
it might be a good idea to NOT depend on having a framework, since
it is very hard to predict how long it will take.

One way to divide up a project that I know about is to have framework
designers, application class designers, and application configurers (a 
lousy name, I know).  The application configurer is the person who talks
to customers and tries to build what they want.  This person wants
to do as little programming as possible.  If the framework does
not satisfy the needs of the customer, this person will either complain
to the framework designers or (more likely) get an application class
designer to build what is necessary.  The application class designer
is more of a traditional programmer, using the framework and producing
classes that fit into the framework.  Usually the application
configurer is in charge of testing.

Large projects will have lots of frameworks, some of which will be
reused by different projects.  Thus, a project will need to have
someone to coordinate the various frameworks.  Usually a project
will have a chief architect, who will do the coordination.

One of the real problems of writing reusable software is figuring
out who is going to pay for it.  It is quite likely that there are
several groups using the software, and issues of reembursement and
control can be hard to solve.