A key problem in software engineering is changing the code. We present a sequence of visualizations and visual metaphors designed to help engineers understand and manage the software change process. The principal metaphors are matrix views, cityscapes, bar and pie charts, data sheets and networks. Linked by selection mechanisms, multiple views are combined to form perspectives that both enable discovery of high-level structure in software change data and allow effective access to details of those data. Use of the views and perspectives is illustrated in two important contexts: understanding software change by exploration of software change data and management of software development. Our approach complements existing visualizations of software structure and software execution.

A central feature of the evolution of large software systems is that change-which is necessary to add new functionality, accommodate new hardware, and repair faults-becomes increasingly difficult over time. We approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed, but on the whole persuasive, statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decay are also discussed.

We have developed a flexible software environment called ADVIZOR for visual information discovery. ADVIZOR complements existing assumptive-based analyses by providing a discovery-based approach. ADVIZOR consists of five parts: a rich set of flexible visual components, strategies for arranging the components for particular analyses, an in-memory data pool, data manipulation components, and container applications. Working together, ADVIZOR's architecture provides a powerful production platform for creating innovative visual query and analysis applications.

Computers generate trace files containing reports on system performance, status and faults. To analyze these trace files more efficiently, we have developed a graphical technique embodied in an interactive system for displaying large trace files. Our system uses abstraction, color, aggregation, filtering, interaction, and a drill-down capability to find patterns among the reports. We apply our system and technique to analyze command accounting trace files from a Unix compute server, showing what commands were executed, by which users, when, and how long the commands ran. We identify resource intensive commands, sequences of commands initiated by a compilations, and commands run with super-user permissions.

Recent research has offered programmers increased options for programming parallel computers by exposing system policies (e.g., memory coherence protocols) or by providing several programming paradigms (e.g. message passing and shared memory) on the same platform. Increased flexibility can lead to higher performance, but it is also a double-edged sword that demands a programmer understand his or her application and system at a more fundamental level. Our system, Tempest, allows a programmer to select or implement communication and memory coherence policies that fit an application's communication patterns. With it, we have achieved substantial performance gains without making major changes in programs. However, the process of selecting, designing, and implementing coherence protocols is difficult and time consuming, without tools to supply detailed information about an application's behavior and interaction with the memory system. StormWatch is a new visualization tool that aids a programmer through four mechanisms: tightly-coupled bidirectionally linked views, interactive filters, animation, and performance slicing. Multiple views present several aspects of program behavior simultaneously and show the same phenomenon from different perspectives. Real-time linking between views enables a programmer to explore levels of abstraction by changing a view and observing the effect on other views. Interactive filters, along with bidirectional linking, can isolate the effects of statements, loops, procedures, or files. StormWatch can also animate a program's dynamic behavior to show the evolution of program execution and communication. Finally, performance slicing captures causality among events. The examples in the paper illustrate how StormWatch helped us substantially improve the performance of two applications.

Networks are critical to modern society, and a thorough understanding of how they behave is crucial to their efficient operation. Fortunately, data on networks is plentiful; by visualizing this data, it is possible to greatly improve our understanding. Our focus is on visualizing the data associated with a network and not on simply visualizing the structure of the network itself. We begin with three static network displays; two of these use geographical relationships, while the third is a matrix arrangement that gives equal emphasis to all network links. Static displays can be swamped with large amounts of data; hence we introduce direct manipulation techniques that permit the graphs to continue to reveal relationships in the context of much more data. In effect, the static displays are parameterized so that interesting views may easily be discovered interactively. The software to carry out this network visualization is called SeeNet.>

Computer sliders are a generic user input mechanism for specifying a numeric value from a range. For data visualization, the effectiveness of sliders may be increased by using the space inside the slider as

This paper is aimed at the exploratory visualization of networks where there is a strength or weight associated with each link, and makes use of any hierarchy present on the nodes to aid the investigation of large networks. It describes a method of placing nodes on the plane that gives meaning to their relative positions. The paper discusses how linking and interaction principles aid the user in the exploration. Two examples are given; one of electronic mail communication over eight months within a department, another concerned with changes to a large section of a computer program.>

Article Estimating software fault content before coding Share on Authors: Stephen G. Eick View Profile , Clive R. Loader View Profile , M. David Long View Profile , Lawrence G. Votta View Profile , Scott Vander Wiel View Profile Authors Info & Claims ICSE '92: Proceedings of the 14th international conference on Software engineeringJune 1992 Pages 59–65https://doi.org/10.1145/143062.143090Online:01 June 1992Publication History 83citation658DownloadsMetricsTotal Citations83Total Downloads658Last 12 Months12Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

A visualization technique that makes it possible to display and analyze line count profile data is described. The technique is to make a reduced picture of code with the line execution counts identified with color. Hot spots are shown in red, warm spots in orange, and so on. It is possible to identify nonexecuted code and nonexecutable code such as declarations and static tables.>

The Seesoft software visualization system allows one to analyze up to 50000 lines of code simultaneously by mapping each line of code into a thin row. The color of each row indicates a statistic of interest, e.g., red rows are those most recently changed, and blue are those least recently changed. Seesoft displays data derived from a variety of sources, such as version control systems that track the age, programmer, and purpose of the code (e.g., control ISDN lamps, fix bug in call forwarding); static analyses, (e.g., locations where functions are called); and dynamic analyses (e.g., profiling). By means of direct manipulation and high interaction graphics, the user can manipulate this reduced representation of the code in order to find interesting patterns. Further insight is obtained by using additional windows to display the actual code. Potential applications for Seesoft include discovery, project management, code tuning, and analysis of development methodologies.>

The authors describe several dynamic graphics tools for visualizing network data involving statistics associated with the nodes or links in a network. The authors suggest a number of ideas for the static display of network data, while motivating the need for interaction through dynamic graphics. A brief discussion of dynamic graphics in general is presented. The authors specialize this to the case of network data. An example is presented.>

A large, circuit-switched, communications network engineered for historical traffic patterns using dynamic nonhierarchical routing (DNHR) is considered. During overloads, the offered traffic many not follow the historical patterns. In such situations, it is possible to increase network throughput by augmenting the routing tables in near-realtime to utilize instantaneous spare capacity. The surveillance strategy determines how often network data is collected and how frequently additional paths are added to the routing tables. Six surveillance strategies for adaptive routing are examined: (1) 2.5-min surveillance interval; (2) 5-min surveillance interval; (3) 10-min surveillance interval; (4) 15-min surveillance interval; (5) modify the routing every other 5 min; and (6) modify the routing every 5 min with a fixed 10-min lag before the routing tables are changed. Simulation is used to compare the network performance to the baseline performance without adaptive routing for each of the strategies. It is found that the more adaptive strategies, (1), (2), and (6), perform better during periods with variable traffic, and that the less adaptive strategies perform better during periods with stable traffic. During heavy overloads, almost as important as the surveillance strategy is the number of problems, overflowing node pairs, and the algorithm attempts to relieve.>