NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4889

Internet Message Format | 1992-12-11 | 3.6 KB

Path: sparky!uunet!olivea!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!sousa.tay.dec.com!talent.ljo.dec.com!gibian
From: [e-mail] (Marc S. Gibian)
Newsgroups: comp.software-eng
Subject: Re: Request for reuse tool info
Message-ID: <[e-mail]>
Date: 11 Dec 92 17:43:38 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Digital Equipment Corporation
Lines: 62


Having spent a lot of time working in this area, I think that most
software re-use efforts miss the point.  Let me expand on this a
bit...

I see four basic goals for software re-use:

   1.  Decrease the cost of developing software.

   2.  Get software products to market faster.

   3.  Increase the productivity of software engineers.

   4.  Improve quality through re-use of well tested components.

The required re-use support varies widely based on the software development
process being used.  By process, I mean how the various individuals that
are involved with the development effort do their jobs.  For example, a
major government contracting company I once worked for wrote into their
contracts clauses that forced use of the classic waterfall methodology
along with an emphasis on "requirements traceability".  This company's
need was for re-use of everything from the functional definition
specifications all the way through the their software process to test
case re-use.

On the other hand, another company I worked for, a more mainstream platform
vendor, used slightly more engineering discipline than total anarchy (The
going joke was "yeah, we do design... that's the time between entering the
building and getting logged onto your machine") where they were pretty
effective at doing informal reuse of code.  The only problem in this latter
case was that much of the reused code was very un-portable (bad news if you
want to succeed in software these days) and its maintanence was on a "whoever
last touched it, owns it" basis, making it hard to get a problem fixed once
there was a second "owner".

What I find missing in most CASE tools, and all the time with re-use tools
and methodologies, is that they are passive.  They require the engineer to
explicitly search a database, know the ground rules for building designs,
etc.  I believe that for re-use to realize its very real potential, as
well as most CASE tools, is for them to become integrated active assistants.
An example:

I start by using a design tool to start designing some software.  I would
like the design tool to not just allow me to build my design, but also to
constantly try to match portions of MY design against the pool of designs
(and existing code and tests for those designs).  When it finds a "close"
match, the design tool points out the match as a candidate for reuse, allowing
me to evaluate whether it REALLY is a design that does what I need, and then
incorporates the re-used design into the design I am creating.

I could give countless other examples, for instance problem reporting/tracking
facilities, test creation, the actual code...

The key, though, is that the tools actively participate in the process, leaving
me to focus only on my engineering of my product.  I don't need to learn tool
after tool, I don't have to explicitly lookup reusable parts, but I still find
and reuse those parts that fit my needs.

--
Marc S. Gibian            email: [e-mail]
Principal Software Engineer    phone: [phone]
Digital Equipment Corporation    fax:   [phone]  or [phone]