This book is aimed at the business and professional market (more than the academic market) as a guide to managing and administering software maintenance (more than doing it). Software maintenance is defined (page 5) as:
The book has the flavor of a managerial video course (it actually started life as a proposed video course), with bullets (as above), charts (mostly simple hierarchies or flow diagrams), repetition, and a little illustrative code (in a nonspecific FORTRAN/COBOL-type language). As one would expect from a video class, the flow is clear and the language simple. The plan of the book is well summarized by the chapter titles. In the following list, the italicized phrases are the reviewer’s assessment of the theme; other phrases are chapter titles (in the book’s order):
Orientation
Software evolution and maintenance
Administrative topics
Change management
Impact analysis
System release planning
Types of software maintenance
Corrective maintenance
Adaptive maintenance
Perfective maintenance
Reengineering source code
Technical topics
Software testing
System release and configuration management
Orientation
Implementing software evolution
Managing software maintenance
This reviewer believes that the computing profession is going through a paradigm shift in its attitude toward existing software. We do not yet understand what role existing software will play in future human society, nor what role humans will play in dealing with existing software. In this cloud of philosophical and historical uncertainty, it is understandable that a textbook is partial and unsatisfactory. This book is partial and unsatisfactory, but it is, at least, much closer to reality than Martin and McClure [1] and more systematic than Glass and Noiseux [2], though it lacks the latter’s affectionate insider view of the world of the maintenance programmer. Uncertainty may be understandable but ignorance and inattention are not. Arthur makes little attempt to report or interpret what is known or inferred by others on the topic of software maintenance. He tramples around the term “evolution,” apparently more to use it as a euphemism for “maintenance” than to explain the issues surrounding this term, and does not reference Lehman and Belady [3]. Similarly, he tramples around the “Perfective/Adaptive/Corrective” classification from Swanson [4] without referencing that paper, noticing that Swanson used the terms differently, or pausing to wonder if this 1976 pail is the right packaging for 1988 milk.
This reviewer would feel more confidence in Arthur’s competence to guide professionals in managing existing software if Arthur showed more competence in managing existing knowledge.