Newsgroups: comp.software-eng,comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!newsreader.wustl.edu!news.starnet.net!wupost!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!enews.sgi.com!wdl1!lmis1!lmis127.lmis.loral.com!user
From: chandra@lmis.loral.com (B. Chandramouli)
Subject: Re: OO Project Management
Message-ID: <chandra-0802951158140001@lmis127.lmis.loral.com>
Sender: news@lmis.loral.com
Organization: Loral Medical Information Systems
References: <Pine.A32.3.91.950131170042.33350O-100000-100000-100000-100000-100000@swim5.eng.sematech.org> <3gqpfa$crl@redstone.interpath.net> <1995Feb3.160549.2349@rcmcon.com>
Date: Wed, 8 Feb 1995 17:59:04 GMT
Lines: 91
Xref: glinda.oz.cs.cmu.edu comp.software-eng:30267 comp.object:26388 comp.lang.smalltalk:20559

In article <1995Feb3.160549.2349@rcmcon.com>, rmartin@rcmcon.com (Robert
Martin) wrote:

> The question has been asked: "How do we use our standard project
> management tools to help manage OO projects?"  On the surface of
> 
> There is a common myth that iterative projects are projects without
> schedules.  They ramble about, hither and yon, until some techie
> decides that they have done enough work and declare the project
> complete.  This is not the case.  An iterative projects has a schedule
> just like any other project, and that schedule can be modeled with
> standard project managment tools

Absolutely true. Any manager of some competence would not let a
marketplace driven (in terms of timely delivery of a quality product)
software project
to be executed as above. Agreed. but....

> When an iterative project begins, the application is broken down into
> many sub-projects, each with a very small number of features.  These
> sub projects are sometimes called vertical slices, or just slices.
> Each slice represents a small amount of work that needs to be
> accomplished.  It must be possible to array the slices in time, such
> that the features implemented in earlier slices do not depend upon the
> features implemented in later slices.  Thus the slices can be
> implemented in a chronological order.

The more I think about this, it is becoming clear to me that what Booch
talks about and what the above discussion alludes to, they do not have
much to do with OO Project Management. I have worked on projects involving
100s of engineers, geographically separated, millions of lines of code
with a project duration of year and a half. There were vertical slices and
each slice had its own schedule
(of requirements, architecture, design, coding, etc) and a grand
integration plan. This project itself is a (fairly thick) slice of the
entire product 
release cycle which are executed in the Chronological order that you talk
about. But no body even pretended that the project used any OO
methodologies. 

So how does OO project management differ from the above style of management?
I think most people would agree with the following observations.

1) OO schedules tend to have lot of internal milestones. Demonstrable
features early in the product release cycle.

2) Prototyping in encouraged.

3) Good OO engineers and managers in general don't believe in "Full and Complete
Analysis" followed by "Full and Complete Design" etc. They do what they
can with analysis, then move on to design probably lot sooner than
traditionally done.

Here are my questions which I am trying to find an answer for myself:

1) So given the above, how can one create a project management philosophy
to accomodate points 1, 2 and 3 above?  

2) Why are the above points relevant only to OO? Can a project using a
methodology of Process Decomposition followed by Functional Decomposition
adopt this approach?
 
3) Along Macro terms, OO, to many seasoned engineers, has a history:
         a) Really, OO techniques started at the coding level:
           Data Abstraction led to modular code and better maintainable code.
           Inheritance and Polymorphism led to better extensible code.
           People then started looking for an Analysis and Design techniques
           which will lead to good use of Abstraction, Inheritance Hierarchies
           that makes good use of Polymorphism. The following general 
           themes emerged.
         b) Analysis reflects the real world problem domain
         c) Design is a continuation of analysis with adding computer domain
            concepts to analysis.

  Given the above history, it looks to me that Iterative Development,
  Prototyping etc. that are usually associated with OO are just incidental to
  the main OO objective. They probably apply to any type of methodology.

4) This lead to my final observation and question: I think the words Analysis
and Design have too much ingrained meaning from the days before OO. 

If Data Abstraction (leading to modular and maintainable design) and
Meaningful Inheritance Hierarchies that makes good use of Polymorphism (
leading to 
extensible systems) are our ultimate objective, should n't we been thinking 
about how to best to arrive at them starting from requirements and then "invent"
a management philosophy to manage those steps? 

Thanks for putting up with my ramblings.

Chandra
