Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!ames!oliveb!amdahl!johnm
From: johnm@uts.amdahl.com (John Murray)
Newsgroups: comp.software-eng
Subject: Re: maintenance strategies/tools
Message-ID: <0d6u02..45YL01@amdahl.uts.amdahl.com>
Date: 31 Jul 89 18:38:31 GMT
References: <217@ssp1.idca.tds.philips.nl>
Distribution: comp.software-eng
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 57

In article <217@ssp1.idca.tds.philips.nl>, roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
> A large institute here in Holland is looking at ways to document/channel 
> expertise for maintenance of very large transaction processing programs.  
> . . .
> The institute wants to "reverse engineer" to an adequate maintenance
> environment.
> Does anyone have any experience with trying to "reverse engineer" to 
> a proper maintenance environment? (or know anybody who does?)

Much of this depends on the current maintenance environment, however
limited it may be. For example, is there accurate source code available?
(There are cases of major systems where all the source has been lost,
which can make life in maintenance a little complicated!) Also, what
language is the system written in?

> For example, did you decide to try and reverse engineer the specs and/or
> designs or was this considered unnecessary or on the contrary absolutely
> vital?
> Did you develop/use identifier cross-referencing or other related techniques?

If it is anticipated that the product will continue to be used and require
maintenance, it's probably worthwhile investing time and energy in some
useful tools. However, writing the specs from the code may not be too
fruitful, unless you're also going to commit to keeping them updated from
now on. (And that's a job which the group is obviously not too good at!)

Build a cross-reference system if possible. Our maint people really
appreciated the one we put in place, especially the "who-calls-me" lists.
But remember that the cross-reference will need to be continually re-built
for each change to the product.

> How can you phase this reverse engineering process viz. which activities
> are most important and which should be done first?. . .
> Which activities/phases/goals should you forget about attempting?

With a high staff turnover, part of the problem is that new people need
to be brought up to speed all the time. (It's an idiotic feature of most
managers that they think junior people learn best by fixing bugs!) Rather
than take on an expert system project, you might be better off capturing
an expert's knowledge by giving him/her a Macintosh and MacDraw, and
building a set of overall system diagrams showing the general data flow
and how things hang together. The costs involved are pretty low, whereas
the maintenance of knowledge bases can be very high (and the organization
would just be taking on even more work in its area of weakness).

Look at what way maintenance is done now and try to identify the loop-
holes and bottlenecks. For example, would some form of automated dump
analysis tools save time? How much maintenance is real bug-fixing (as
distinct from adding new bells and whistles)? If lots of bugs are getting
out, then the testing process may need revision. Many incoming problem
reports not only require a fix to the product itself, but also a fix in
the test which allowed the fault to slip through in the first place.

This is an interesting area; I'd certainly like to discuss the various
options and strategies a bit more.

- John Murray, Amdahl Corp. (My own opinions only, etc.)