Journal of Software Maintenance: Research and PracticeVolume 12, Issue 4 p. 249-253 Book Review Practical Software Maintenance Carolyn B. Seaman, Corresponding Author Carolyn B. Seaman Department of Information Systems, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore MD 21250, U.S.A.Department of Information Systems, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore MD 21250, U.S.A.===Search for more papers by this author Carolyn B. Seaman, Corresponding Author Carolyn B. Seaman Department of Information Systems, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore MD 21250, U.S.A.Department of Information Systems, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore MD 21250, U.S.A.===Search for more papers by this author First published: 22 September 2000 https://doi.org/10.1002/1096-908X(200007/08)12:4<249::AID-SMR213>3.0.CO;2-NAboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Volume12, Issue4July/August 2000Pages 249-253 RelatedInformation

SUMMARY The test process for evolving software systems takes on a different measurement aspect than that of new systems. Existing systems are generally being modified on a continuing basis as a normal part of the software maintenance activity. This process of product modifications is fault prone because faults are introduced in the code as it is being modified. From a statistical perspective, regression testing should be focused on those areas that are most likely to contain the introduced faults. Based on that premise, we have developed an evolutionary fault index that works as a fault surrogate varying in the same manner as faults. However, the knowledge as to the location of probable faults is not enough to assess the capabilities of a regression test suite. It is necessary to understand what the software is doing under each test. For that purpose, test execution profiles are gathered. Test execution profiles and the evolutionary fault indexes are combined in one methodology to provide an assessment of the overall regression testing activity and the suitability of each individual test. The methodology is illustrated with data from a 300 KLOC embedded system and its corresponding regression test suite. Copyright © 2000 John Wiley & Sons, Ltd.

This paper advocates that extracting formal specification semantically consistent to the original legacy system will facilitate further redesign and forward engineering greatly. The three parts of reengineering could be integrated on the basis of a wide spectrum language. The key approach to comprehension and the production of formal specification is a notion of abstraction. Transformation can help to change the original source code into alternative forms, but with the same semantics. Abstraction is often interpreted as the act of hiding irrelevant details. What constitute as relevant details is often left open to different interpretations. A unified approach for reverse engineering is described within which the notion of abstraction is classified and precisely defined. Abstraction rules are given and applied to various case studies. Copyright © 2000 John Wiley & Sons, Ltd.

When programmers perform maintenance tasks, program understanding is often required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e., its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems by showing them architectural information. This paper describes an environment for the architectural recovery of software systems called the architectural recovery tool (ART). The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a different architectural view of a system or of some of its parts. Recognizers embody knowledge about architectural clichés and use flow analysis techniques to make their output more accurate. To test the accuracy and effectiveness of the ART, a suite of public domain applications containing interesting architectural organizations was selected as a benchmark. Results are presented by showing ART performance in terms of precision and recall of the architectural concept retrieval process. The results obtained show that cliché-based architectural recovery is feasible and the recovered information can be valuable support in reengineering and maintenance activities. Copyright © 1999 John Wiley & Sons, Ltd.

Software restructuring is the process of re-organizing the logical structure of existing software systems in order to improve particular quality attributes of software products. During design or maintenance, software developers often use intuition, rather than an objective set of criteria, to determine, recapture, or restructure the design of a software system. In this dissertation, we provide a quantitative framework for software restructuring. In the framework, restructuring decisions are guided by visualized design information and quantitative design-level measures. The restructuring process is automated by supporting tools. A set of design-level cohesion and coupling measures provides the objective criteria for comparing alternative design structures. They are derived, compared, and applied in our software restructuring framework. The process insures that restructuring results in measurable and visible improvements in design quality. Applying our framework can result in restructured software systems that are easier to maintain and reuse.

News from the Information Technology (IT) community is mixed. Project backlogs, high employment and personnel shortages are claimed on one side; project cancellations, unproductive use of personnel time and continued poor quality software are claimed on the other. Which side is component-based software on? The drive to use components such as COTS components comes from claims of instant productivity gains, shorter time to market, lower cost, management mandates and a ‘parts’ philosophy. On the other side are difficulties in composing systems from unreliable components, the ‘ility’ factors, the traditional white-box software processes, short-changed testing, software component support limits and software malleability. If components such as COTS are used a lot, then finger-pointing grows more common as we move toward black-box component integration. Some of the defensive options include component certification, strengthened testing, and adding wrappers and middleware. All add to maintenance cost. If we use components such as COTS, our ability to maintain the resulting composite systems is reduced to the level of ‘unmaintainable’. This leads us to think in terms of disposable information systems. Overall, I observe as we move toward component-based software, quality will be even more important for maintainability. Copyright © 1999 John Wiley & Sons, Ltd.

After a brief introduction to the year 2000 (Y2K) software situation, this paper summarizes 10 options for handling the situation, two problems and 16 realities that distinguish Y2K work from other forms of software maintenance. Because it is basic to the case study, this paper then introduces a configuration management system, and briefly explains the 13 objectives for the one used by the organization reported. The Y2K case study coverage begins with a review of the project mission and background about the organization and its information systems environment. The key feature of what this organization did as part of its Y2K project was to build a supporting infrastructure. Of the eight tasks done by the project, only the eighth one was actually devoted to making the organization's software become Y2K compliant. The seven prior infrastructure tasks were: (1) install a single production module, (2) produce system documentation, (3) document all interface data, (4) populate a data dictionary, (5) analyse each production system, (6) produce and use viable JCL, and (7) produce run books. Besides making all the software Y2K compliant within schedule and budget at a cost below the USA national average, the project achieved nine other major benefits. This paper closes with a summary of a generic, successful, Y2K compliance process, and after some discussion, lists five lessons learned. © 1998 John Wiley & Sons, Ltd.

Reverse engineering tools support software engineers in the process of analysing and understanding complex software systems during maintenance, re-engineering or re-architecturing. The functionality of such tools varies from editing and browsing capabilities to the generation of textual and graphical reports. There are several commercial reverse engineering tools on the market providing different capabilities and supporting specific source code languages. We evaluated four reverse engineering tools that analyse C source code: Refine/C, Imagix 4D, SNiFF+ and Rigi. We investigated the capabilities of these tools by applying them to a real-world embedded software system as a case study. We identified benefits and shortcomings of these tools and assessed their applicability for embedded software systems, their usability and their extensibility. © 1998 John Wiley & Sons, Ltd.

SUMMARY Tools built in an ad hoc way and without proper models often display problems for both tool users and designers. Firstly, without systematic analysis and good understanding of the underlying software process model, we have little chance to design a tool that will adequately address user’s needs. Next, because one tool is often used in many different situations and by people who have different working habits, tools should be flexible and allow a user to customise tools functionalities. Ad hoc built tools usually are not flexible enough, as possible variations in tool functions had not been incorporated into the tool architecture to make future customisations possible. Finally, ad hoc design practice does not lead to accumulating the tool design know-how, makes it difficult to repeat successful solutions and slows down the process of understanding and improving tool design methods. We applied conceptual modelling in design of tools for software maintenance to alleviate some of the above problems. In this paper, we describe a model-based method to designing reverse engineering tools. The design starts by modelling low level source program design models, higher level design models to be recovered and heuristic rules a reverse engineering tool uses to recover higher level designs from lower level designs. On one hand, conceptual models lead to better understanding of tool requirements. On the other hand, model-based approach leads to the design of a generic design abstractor, a component of a reverse engineering tool that evaluates reverse engineering heuristics. A generic design abstractor adds flexibility to reverse engineering tools in two ways: (1) we can customise the generic design abstractor to meet requirements of a reverse engineering project in hand and (2) a programmer (an end-user of a reverse engineering tool) can define new reverse engineering heuristics and tune in recovered designs.