From: j_ohearn@dsg4.dse.beckman.com
Newsgroups: comp.object
Subject: Re: Help: OOA and OOD Methodologies
Date: 29 Jul 92 15:42:30 GMT


Just thought I would add my two-cents worth to this thread.  My company has
decided to cautiously test the OO waters.  Its inspiration has been a small
group of software engineers who initiated a grass-roots investigation into OO.
This object-technology group quickly realized that some formal training was
required.  So we asked for training.  We were told that in order for management
to justify the training costs, we needed to write a proposal.  So we did.  The
proposal was crafted and distributed along with a wonderful book--  "Object-
Oriented Technology:  A Manager's Guide" by Dr. David Taylor (anyone and everyone
interested in OO should read this book!).  The distribution list was composed
of all the senior software department personnel (our "steering committee").  We
then made a presentation to this group where we gave them a chance to voice their
concerns.  Oddly enough, the majority of concerns either had to do with our soft-
ware development process or any new technology in general.  Approximately one-
third of the concerns raised had to do with OO in particular.  We then were asked
to draft a written response to these concerns.  We did-- the responses were well
received.  Let me give you a quick idea of the contents of the proposal:  intro-
duction, candidate projects, integration issues, risk evaluation (very important!)
and technical appendices.  The technical appendices provided a historical back-
ground of OO, an overview of methodologies & languages, a list of consultants (for
training), a reference list (i.e. those companies using OO) and a glossary.  If
I get enough requests, I will post the proposal to the comp.object newsgroup.

Anyways, during the proposal phase, we had to take a close look at the various OO
methodologies.  We studied Booch, Coad-Yourdan, Rumbaugh and Shlaer-Mellor.  I
spent a great deal of time monitoring the comp.object newsgroup looking for opin-
ions on the subject.  I also made contact with a software development manager at
TI when I saw his project mentioned in "American Programmer" (he recommended using
a synthesis of Rumbaugh and Booch).  We also utilized the monthly newsletter
"Object-Oriented Strategies", Vol. II, Number 4 and 5 (Cutter Information Corp.);
object-oriented methodologies were profiled and evaluated in these two issues.
OOS came to the conclusion that the Rumbaugh method was "the most powerful and
internally consistent OOM" reviewed.  Furthermore, another division of my company
had already chosen Rumbaugh and were pleased with their choice.

It is probably apparent that we selected the Rumbaugh methodology.  However, we plan
to supplement Rumbaugh with Booch-- we just find the Rumbaugh method easier to read
and interpret; we also appreciate the sense of scope.  We recognize that Grady Booch
possesses a great deal of meaningful experience and I have found his text to be
filled with many "pearls" of OO engineering wisdom that we cannot afford to ignore.
Furthermore, Grady has a great deal to offer software developers who work with real-
time embedded systems.  Our primary emphasis will be Rumbaugh but eventually the
methodology we will be using will be a synthesis of Booch and Rumbaugh.  I strongly
recommend this approach for everyone since all the OO methodologies are somewhat
immature.

Feel free to send me email if you have questions about issues pertaining to the
adoption of OO technology.  I will be glad to share my experiences with you.

Thanks for listening.

Jim O'Hearn, Software Engineer
Beckman Instruments, Inc., Diagnostics Systems Group
j_ohearn@dsg4.dse.beckman.com

Character, not color, is what matters...