As continuous delivery and continuous integration practices become more prevalent in industry, the need for education in these areas grows. Introducing these topics introduces complexities due to the learning curve of the involved tools and the amount of time available for teaching these topics. Furthermore, there has been limited research into effective teaching practices for incorporating continuous integration and delivery concepts into traditional software engineering courses. In this paper, we discuss the results of an initial study of introducing a continuous delivery educational pipeline into an undergraduate software engineering course. The pipeline used was designed to help instructors introduce continuous integration and delivery into preexisting courses and allow students to visually understand the processes of continuous delivery and continuous integration.

Design recovery is often necessary for Software Engineers trying to manage and maintain complex software systems. The emergence of Service-oriented Architecture (SOA) creates new difficulties for design recovery. This article describes an approach to the use of a particular type of conceptual modeling that has been called knowledge modeling to support design recovery from SOA composite applications. The approach uses a prototype tool called CARET to automate the recovery of basic architectural structure from low level SOA descriptions such as BPELs, WSDLs and XML Schemas. CARET is used with the freely available CmapTools to produce graphical representations called concept maps which may either be used directly or further enhanced through a knowledge elicitation effort with system experts. Two case studies are presented. The first illustrates basic system structure recovery of a composite application. The second illustrates automated recovery augmented with knowledge elicitation for a large-scale SOA system.

Many future Services Oriented Architecture (SOA) systems may be pervasive SmartLife applications that provide real-time support for users in everyday tasks and situations. Development of such applications will be challenging, but in this position paper we argue that their ongoing maintenance may be even more so. Ontological modelling of the application may help to ease this burden, but maintainers need to understand a system at many levels, from a broad architectural perspective down to the internals of deployed components. Thus we will need consistent models that span the range of views, from business processes through system architecture to maintainable code. We provide an initial example of such a modelling approach and illustrate its application in a semantic browser to aid in software maintenance tasks.

SUMMARY Several authors have suggested that service‐oriented architecture (SOA) applications will present new program comprehension challenges for future software maintainers. We review the literature on program comprehension for SOA and describe exploratory work on static and dynamic program analysis, using two prototype tools to aid in addressing these challenges. SOAMiner is a static search tool to extract information from XML‐structured SOA files such as Web Services Description Language, XML Schema Definition Language, and Business Process Execution Language. Feature sequence viewer is a dynamic message trace analysis tool that extracts a sequence diagram highlighting the path of messages involved in processing a particular Web service request. Several case studies were conducted involving both static and dynamic analysis. Use of these tools has helped to clarify what SOA maintainers will need to know and how software tools might help them. Results revealed various types of static and dynamic information that can be useful to maintainers of SOA composite applications. Copyright © 2011 John Wiley & Sons, Ltd.

This retrospective briefly recapitulates highlights of the original paper that was published at IWPC 2002. Then it overviews research directions of the last 10 years: research in tools and techniques of concept location a that aim to support software developer, research of integrated model of software change, creation of software engineering course that emphasizes the role of software developer in iterative and agile software processes, and further basic research into the role and properties of concepts.

Feature location is a commonly occurring program comprehension problem. In understanding large software systems, software engineers need to locate the different software components that work together to provide a specific end user feature. Several dynamic analysis methods for feature location have been proposed in the literature. These generally require instrumenting the software to trace execution. However our industrial experience indicates that instrumenting can be problematic for large time-sensitive systems. This paper describes our experience and experiments with "mininst", a low-impact instrumentation approach oriented to feature location. We hope that this approach will enable the application of dynamic analysis feature location methods to this class of time-sensitive software.

Software Engineers frequently need to locate and understand the code that implements a specific user feature of a large system. This paper reports on a study by Motorola Inc. and the Software Engineering Research Center to see if industrial tools currently in use at the company could be adapted for feature understanding

Software engineers who maintain and enhance large systems often encounter the feature location problem: where in the many thousands of lines of code is a particular user feature implemented? Several methods of addressing the problem have been proposed, most of which involve tracing the execution of the system and analyzing the traces. Some supporting academic tools are available. However, companies that depend on the successful evolution of large systems are more likely to use new methods if they are supported by industrial-strength tools of known reliability. This article describes a study performed with Motorola, Inc. to see whether there were any pitfalls in using Metrowerks CodeTEST and Klocwork inSight for feature location on message-passing software similar to systems that Motorola maintains. These two tools were combined with TraceGraph, an academic trace comparison tool. The study identified two main problems. First, some ‘glue’ code and workarounds were needed to get CodeTEST to generate a trace for an interval of time in which the feature was operating. Second, getting information out of TraceGraph and into inSight was needlessly complicated for a user. However, with a moderate amount of work, the tool combination was effective in locating, understanding and documenting features. Study participants completed these steps in typically 3–4 hours per feature, studying only a few hundred lines out of a 200 000 line system. An ongoing project with Motorola is focused on improving tool integration with the hope of making feature location common practice at Motorola. Copyright © 2006 John Wiley & Sons, Ltd.

For the last seven years students in the Masters track in Software Engineering at the University of West Florida have focused their capstone course and project work on software process and software evolution. Students initially defined a software maintenance process called GUMP which has been used in all subsequent years. Students use this process in a rolling project in which they maintain and enhance a medium-sized software tool. Simultaneously they improve the process based on their experiences, thus leaving their successors both enhanced software and an enhanced process to use in its evolution. Approximately 50 cycles of software change have been completed following this method, and two years ago a major revision to GUMP was undertaken based on an analysis of this experience. This article, by three of the instructors and two of the participating students, describes the methods used and the experience gained.

Software engineers often need to locate where particular features of a program are implemented in order to fix a bug or introduce an enhancement. This paper describes a tool called TraceGraph to support this task, particularly for large, long-running or interactive software. TraceGraph provides a simple visual display of the program's trace which allows changes in execution to be easily distinguished. A software engineer can run the feature he or she is interested in, and immediately view how program execution varies. Case studies on two large systems show how TraceGraph may be applied to different kinds of traces. Displays similar to TraceGraph would be good candidates for inclusion in software monitoring or debugging systems.

Programmers working on the year 2000 problem need to locate and understand date sensitive code, that is, code whose execution depends on date inputs. This paper presents several dynamic analysis methods for addressing this problem. Date sensitive code can be located by running many test cases that are identical except for a change in one date value. An advanced test coverage tool can recover each test's execution count vector giving the number of times that each basic block was executed. Comparison of the vectors reveals the blocks whose execution is affected by the input date values. We present several methods of analysing the execution count data to locate date algorithms. One method identifies subdomains, that is, ranges of dates that are processed similarly. Another method involves graphical or Fourier analysis to identify common programming patterns such as leap-year computations. The last method exploits the 28-year regularity in dates to look for anomalies in processing. The methods are illustrated using Bellcore's ATAC testing tool on five C programs that use some of the date encodings that year 2000 maintainers may need to locate and understand. Copyright © 1999 John Wiley & Sons, Ltd.

Software Reconnaissance is a dynamic analysis technique to help programmers locate code that they need to understand, fix, or enhance in an unfamiliar system. The technique was originally motivated by comments by industrial maintainers about the need for better ways of locating software features in large systems. It was then prototyped in a university setting and an initial tool called RECON was developed. The paper describes four case studies applying Reconnaissance to three different industrial programs of moderate size. Reconnaissance seems to be effective in finding "places to start looking" for maintainers of unfamiliar code. It can also be used to recover a traceability relation between program features and program code that may help identify design patterns. The case studies are the initial phase of an ongoing technology transfer project of the Software Engineering Research Center, to make Software Reconnaissance into a usable industrial technique.

Since software engineers spend a large proportion of their time trying to understand computer programs, many tools have been proposed to help them with this task. The construction of such tools raises a series of specification and design issues and requires a careful choice among alternative user interfaces, tool architectures, and knowledge representations. This paper discusses the information needs of software engineers and describes and compares two such tools, the Extensible Dependency Analysis Tool Set (EDATS) and the Inter-Module Code Analysis system (IMCA). A case study is presented showing how each tool would be used to support typical program comprehension tasks. Though the two tools have quite similar objectives, their designs are radically different, leading to interesting contrasts in flexibility and ease of use.

Software producing organizations attempt to improve their cost, schedule and quality performance by defining an organizational software process model. Educators try to teach their students the virtues of following such a process in software development and maintenance. But most software process models are proprietary so there are few readily available examples to help guide these efforts. This paper outlines the ‘Generic University of West Florida Maintenance Process (GUMP)’ which has been developed, used and refined over a period of almost two years in an educational setting. It describes the key maintenance process issues identified in this experience and the rationale for the solutions adopted in GUMP. As an academic tool, GUMP has greatly improved the learning experience in our project courses; two of our graduates have taken it as a starting point for developing a process for their employers. Full documentation for GUMP is publicly available on-line and may be copied and adapted as needed. GUMP is presented not as a ‘perfect’ process, but simply as a starting point that may be useful to either maintainers or educators as a point of reference for software process concepts.

Abstract Maintainers of old code often need to discover where particular program features are implemented. This paper presents a method, called ‘software reconnaissance’ for answering this question through an analysis of the execution of different test cases. The method is quite easy to implement, requiring only a test coverage monitor, some simple tools, and a surprisingly small number of test cases. A statistical case study is presented that shows the kind of results that can be obtained on a typical medium‐sized program. The method seems to be effective in identifying a small number of code components that are unique to a particular program feature, though it may not find all components that make up the feature's delocalized plan. A small protocol case study shows that professional programmers can learn to use the method quickly and can use the information that it produces. Software reconnaissance may be a simple but useful addition to the maintainer's tool kit in that it provides starting points for understanding a large program and a way of recovering some requirements traceability information from old code. For the researcher, it also provides a novel functionality ‘view’ of software that maps features to program components at different levels of precision.

If better tools are to be developed to support the impact analysis task, greater clarity is needed about the exact nature of that task. This paper presents a definition of impact analysis and distinguishes between impact analysis and program understanding. Impact analysis is a necessarily approximate technique which must focus on the cost-effective minimization of unwanted side-effects. A key to effectiveness would be a way of precisely describing the semantics of each software change. A general model of software impacts is presented that uses flexible declarative propagation rules to describe the way software objects affect each other. Preliminary versions of the model have been implemented in an impact analysis system. A small case study was performed to gain experience in applying the model as part of a software change process. Recommendations are made for impact analysis tool support and for further research directions.>

Industrial software systems are generally both large and complex. They tend to contain multiple languages and diverse kinds of structure that maintainers need to understand to do their jobs effectively. The Extensible Dependency Analysis Tool Set (EDATS) has been designed to provide support for understanding these kinds of systems. The EDATS concept emerged from discussions with industrial affiliates of the Software Engineering Research Center. It is built around a very flexible underlying structure in which software is represented as a generalized dependency graph; queries “by example” request chains of links from that graph. Information from diverse sources can be incorporated and the tool set can be easily extended to handle special relationships found in a particular system. A small case study is presented to illustrate the kinds of questions that maintainers tend to ask in understanding an unfamiliar system and to show how EDATS can help in answering such questions.

Abstract The maintenance or re‐engineering of a program usually begins with considerable effort in understanding the program structure. In this paper, an interactive tool for understanding the structure of non‐object‐oriented programs, known as the Object Finder, is presented. The structure of a program is defined in terms of the groupings of routines and data into modules within the program and the hierarchical relationships among the modules. The Object Finder incorporates two complementary approaches, one being top‐down and the other bottom‐up, to assist the software engineer in understanding the structure of a program based on the object‐like features found in the program. In the top‐down approach, the user obtains an overall understanding of the entire program as a collection of hierarchically organized objects. In the bottom‐up approach, the user obtains a view of the information which is closely related to the components under examination. In both approaches, two methods are used to identify the objects in a program written in a non‐object‐oriented programming language. These methods identify sets of objects based on the data bindings and on the type bindings found in a program. An object is considered as a collection of routines, types, and/or data items of the program. The Object Finder combines the top‐down and bottom‐up approaches while using human input to guide the object identification process. Two examples of using this Object Finder are also presented to demonstrate the capabilities of the approaches to assist the software engineer in attaining a high‐level understanding of the program structure.

It is pointed out that software maintainers often have to recover requirements traceability in old code. In other words, they need to determine in which parts of the program the functionality X is implemented. The authors propose a methodology for answering this question based on the use of carefully designed test cases as probes into the code. While the methodology is not applicable to all kinds of requirements and may not find all relevant code components, it should often provide a maintainer with good starting points for studying a large and poorly documented system. Two formulations of the methodology are suggested, and some encouraging experimental results are presented from a case study of a typical old program.>

Abstract This paper provides a framework for considering the problems of re‐engineering transaction processing systems. Such systems are key components of most modern business operations, and their continued enhancement is crucial for competitiveness. The paper grew out of a study of software re‐engineering problems and practices carried out by Andersen Consulting at several major companies in the telecommunications industry. It describes some of the practical difficulties found in re‐engineering transaction systems, especially the problems caused by the need for an incremental approach and the difficulties of re‐engineering in parallel with the continuing evolution of the operational system. This paper presents a model of the maintenance and re‐engineering processes showing the main activities that are needed and the data flows among them. Existing tools for re‐engineering are then analysed against this model to identify gaps and potential for further tool development. Finally, there is a brief discussion of the very stringent personnel needs of software re‐engineering projects.

This paper describes some of the difficulties that may be expected in the maintenance of software developed using the new object oriented languages. The concepts of inheritance and of polymorphism provide the great strengths of these languages, but they also introduce difficulties in program analysis and understanding. The paper analyzes problems of dynamic binding, object dependencies, dispersed program structure, control of polymorphism, high-level understanding, and detailed code understanding. Examples are presented based on code from a PC Smalltalk environment and from studies of two systems under development at Bell Communications Research

Some of the difficulties that may be expected in the maintenance of software developed using the new object oriented languages are described. The concepts of inheritance and of polymorphism provide the great strengths of these languages but they also introduce difficulties in program analysis and understanding. The authors analyze problems of dynamic binding, object dependencies, dispersed program structure, control of polymorphism, high level understanding and detailed code understanding. Examples are presented based on code from the Smalltalk V environment. Recommendations are made for possible tool support, particularly using the concepts of dependency analysis, external dependency graphs, and clustering methodologies. Some suggestions are made concerning maintenance in firefighting situations, when a failed system must be brought back into service with a minimum of lost time.>

The authors propose methodologies to aid in the design recovery of object-like features of a program written in a non-object-oriented language. Two complementary methods, based on an analysis of global data or of data types, are proposed, along with an interactive tool that would combine the two methods while using human input to guide the object identification process. The authors are constructing a prototype interactive software tool to implement these methods for the C language. The intention is to collect data on the user's decisions and reasons for making them so that improved heuristics or knowledge-based-methods could be developed to improve the process.>

A general-purpose toolset that is being developed to capture and analyze software dependencies is described. The tools are designed to serve as reusable components. They can be used not only to aid programmers directly in understanding programs but also as a basis from which other specialized tools can be constructed. The tools use the concept of a dependency graph as a basic abstraction to simplify the understanding of software relationships. Definitional, calling, functional and data-flow dependencies are analyzed. An external dependency graph for each function is developed to encapsulate the effects of function cells.>