roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (07/28/89)
Apologies if this has been discussed before. I'm posting this for a friend. A large institute here in Holland is looking at ways to document/channel expertise for maintenance of very large transaction processing programs. These program suites process in the order of 100 thousands/millions of transactions a day (or so I am told). Due to programmer turnover and program size and inadequate documentation the usual maintenance woes are being felt. 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?) What methods/strategies were employed? What were the lessons learned (and perhaps even more important the mistakes made :-)? 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? What other tools did you use/can you get on the market for this sort of work? 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? I believe the current idea is to come up with some sort of "expert system" to handle (some of) the maintenance problems. I personally have my doubts about such an approach and would be glad to hear any positive or negative experiences/opinions in this (or related) areas. All opinions/pointers/experiences/flames welcome. Thanks in advance. -- I don't know what the question means, but the answer is yes... (overheard on comp.lang.misc) Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof
johnm@uts.amdahl.com (John Murray) (08/01/89)
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.)
jfoster@zaphod.axion.bt.co.uk (john foster) (08/03/89)
From article <217@ssp1.idca.tds.philips.nl>, by roelof@idca.tds.PHILIPS.nl (R. Vuurboom): > > A large institute here in Holland is looking at ways to document/channel > expertise for maintenance of very large transaction processing programs. > [ ... ] > Due to programmer turnover and program size and inadequate documentation > the usual maintenance woes are being felt. > > 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?) My group here at British Telecom Research Labs has a strong interest in reverse engineering (as part of more general research into software maintenance). We also have past experience of using reverse engineering in the maintenance of switching system software. I hope the following, fairly general, comments might be of some use. > > What methods/strategies were employed? > There are (at least) three broad strategies to consider: 1. Reverse documentation, involving the use of static analysis etc to create information to help the maintainers 2. Reverse engineering, where you start with the code and attempt to recreate the design/spec information 3. Re-engineering, where you perform step (2) and then recreate the system from the new spec. (BTW, I don't claim that my use of these terms is definitive). Identifier cross-referencing is the lowest level of our reverse documentation work, and we then build on that to gain higher levels of documentation. Parts of that work are described in: Foster, J. R. and Munro, M. "A Documentation Method Based on Cross-Referencing" Proc Conf Software Maintenance 1987, Austin, Texas Fletton, N. T. and Munro, M. "Redocumenting Software Systems Using Hypertext Technology" Proc Conf Software Maintenance 1988, Phoenix, Arizona (John Foster is me; Nigel Fletton is another member of the group here; Malcolm Munro is at the University of Durham (UK) and runs the Centre for Software Maintenance there). We have found reverse documentation extremely useful, even though it can't tell you _all_ the things you want to know (like the reasons behind design decisions). This isn't a commercial plug, incidentally, because we are not in the market as tool suppliers in this area. Reverse engineering (as I define it here) is a more difficult task, but there's a lot of interest and activity. A good example paper is: Sneed, H. M. and Jandrasics, G. "Inverse Transformation of Software from Code to Specification" Proc Conf Software Maintenance 1988 The paper describes a system for reverse engineering from COBOL. Re-engineering is the most expensive of the lot, but of course it also offers the greatest potential gain. IBM have an interesting project involving re-engineering via formal methods: see eg Nix, C. J. and Collins, B. P. "The Use of Software Engineering, including the Z Notation, in the Development of CICS" Quality Assurance, vol 14 no 3, September 1988 > > What other tools did you use/can you get on the market for this sort > of work? > There's a regularly updated survey on software maintenance tools, published by Software Maintenance News, Staten Island, New York. Sorry I can't quote the full reference right now, but their phone number is (USA) 718-816-5522. > > I believe the current idea is to come up with some sort of "expert system" > to handle (some of) the maintenance problems. I personally have my doubts > about such an approach and would be glad to hear any positive or negative > experiences/opinions in this (or related) areas. > I'm convinced that expert systems have a lot to offer, although these are early days yet. But people are certainly talking about, and/or experimenting with: - systems to help users register their change requests (with some problem analysis capability) - systems to aid code analysis - systems to aid people writing documentation There are some papers in the proceedings of the software maintenance conferences mentioned above, that give an idea of what's going on. Hope this helps. +--------------------------------------------------------------------+ | Who: John Foster | | Where: RT3151, Room G44C, SSTF, British Telecom Research Labs, | | Martlesham Heath, Ipswich, IP5 7RE, UK. | | Phone: +44 473 646019 Fax: +44 473 643019 | | E mail: jfoster@axion.bt.co.uk Telex: 987137 (ISSEC G) | +--------------------------------------------------------------------+