Survey of the Current State of Software Visualization Systems and their Application to the Software Development Lifecycle

James Walsh WALJA008 100063615

Abstract

The ideal applications for software visualization (SV) systems in the software development lifecycle (SDLC) have not yet been discovered. This paper presents the results from a study examining the current state of software visualization applications and research in relation to the actual software development process. The results reveal that the vast majority of effort (both past and present), by both industry and academia, in applying software visualization has been into the development and maintenance of software systems, primarily focusing on the later two stages of the SDLC. Based on these results, we identify areas in the lifecycle which can value from further study into the application of specialised software visualization to them.

1. Introduction

The most efficient and effective method for the development of large scale software systems has eluded researchers and industries experts since their inception. Despite years of research, software development of any size remains a risky, expensive and time involved venture. The development of these systems can become incredibly complex, with the lifespan of some systems spanning over many years, or in some cases, decades. Dealing with the complexity of these systems by the many different staff members that will be involved in the project across its lifespan has also become a crucial issue.

Large amounts of any kind of data are difficult for the human brain to interpret. With developers often having to examine many versions of the same data in parallel, another key issue has become "how can information about these systems be presented in a way that helps, rather than overwhelms the developer? The answer is in pictures." (Wilner, 1995). With over 50% of the brains neurons associated with vision (Owen, 1993), we can see that the human brain is designed to analyse things visually, acting as a visual code breaker, allowing us to intuitively understand even the most complex data sets. The application of visualization to software development allows the brain to easily apply parallel pattern matching techniques to help recognise common forms and easily make associations. From this, the promise of software visualization as a potential key tool in the development process quickly becomes apparent.

However, despite decades of research into software visualization, the ad-hoc approaches taken have been on an opportunistic basis. Both academic and industry tools exist to help project members deal with the complexities involved in the software development lifecycle (SDLC), however these tools have primarily focused on the later two stages of the lifecycle (development and maintenance), ignoring the earlier design phase, and even then, the applications and success have been limited. As Parker (1996) states, the “two areas of the software development life cycle that stand to benefit substantially from this process are software training and debugging”.

This study analyses the link between the current works in the SV field, and their related applications to the SDLC. Concentrating on a low level breakdown of the SDLC, we seek to identify areas of neglect with relation to the application of SV.

2. Methodology

The initial starting point for this survey was the analysis of current works (both from academia and industry) in the SV field. By searching relevant academic sources along with SV specific resources 1, a selection of relevant resources was gathered. These were then analysed to identify and characterize the current types of SV and their current applications in software development. It quickly became apparent that with the expected overlay between tools, and the possible re-purposing of tools to achieve different goals than originally intended, it would become difficult to identify any areas of the SDLC which required further study.

This resulted in a different approach; a survey that was divided into two stages. Initially, the software basic lifecycle was outlined with four stages – inception/business modelling, requirements/design, implementation and maintenance. This basic outline was then expanded to include all steps relevant to the SDLC (regardless of its size, impact or significance to SV). This list then helped to identify which steps in the SDLC lifecycle could actually be visualized (for example, steps such as performing interviews to extract requirements could not be visualized). The resulting list acted as a visual guide to what steps and also which areas (groups of steps) in the SDLC could be visualized.

Previous resources from researching earlier in the SV study were then allocated against this list, classifying them as whether they were a research paper (with applications relating to that step in the SDLC), academic tool or industry tool. Further research was then conducted, focusing on each step/area of the SDLC, hoping to further identify resources specific that that area. After being allocated to the relevant step in the list, the resources were also allocated against other areas which could also benefit from their application.

The final list consisted of each step in the SDLC, and any industry tools, academic tools or academic papers that could be applied to it. This list was then analysed to identify areas of neglect in the SDLC with regards to benefiting from SV.

3. Survey

A number of small observations became apparent during the initial stages of this work. SV tools and research essentially could be split into three methods; line-by-line source code/code control system analysis and program structure with little work being available on the run time behaviour of software. It was observed that the primary focus of SV has been on helping the developer understand/reverse engineer the program structure and on helping track overall developments within the project, benefiting program management. Despite increasing the understanding of how/what was being developed, little existed to actually streamline the process of writing code itself. With programmers relying on the SV tools to gain an understanding of what needs to be done, and then going off and performing the required updates as if SV hadn’t impacted on the process at all.

Despite SV still not being mainstream, the application of 3D environments to SV is still in its infancy. Current 3D SV tools focus on its benefits to the developer by increasing the density of information to be displayed per screen, but also mentioning that it introduced a number of key issues which impeded its usefulness. Human computer interaction (HCI) became a key issue, with problems

1 ACM Symposium on Software Visualization – http://www.st.uni-trier.de/~diehl/softvis/org/index.php

arising as to how to effectively navigate and optimally make use of the visualization in the third dimension.

The majority of work in the SV field has been done by academia, not industry. Despite industrial tools being available, many tools were generic (such as Microsoft Project 2 and Visio3), which despite offering some benefits as non-purpose specific tools, they didn’t offer the full potential that SV is capable of. Given their nature, these generic tools could often be used at various steps throughout the SDLC. Other widely known tools such as IBM’s Rational Rose4, despite being designed for software developers, still offered limited SV facilities. This reinforces the fact that despite the obvious benefits of SV, its best applications to software development are still to be identified.

3.1. Inception/Business Modelling

Inception and business modelling dealt with the initial stages of life for a software project before any requirements/design. The main steps here involved identifying problems within the current model of performing tasks. Although other elements are involved, numerous statistics/graphics packages exist (even as basic as Microsoft Excel5) to help identify where time is spent within a process, identifying inefficient areas. We then identify if any solutions to the proposed problems exist, which given highly cognitive and qualitative nature cannot be visualized.

3.1.1. Vision Document

Any project stems from an initial vision document outlining what needs to be achieved, the key features and any major constraints. At this point, the basic core requirements and requests become apparent, with the author needing to manage them, and any interdependencies between them. These interdependencies can affect which requirements become crucial, as those crucial are highly interlocked with others. Some academic work existed, with Carlshamre et al. (2001) identifying key parameters (split between functional and value/cost related) for optimal requirement selection, whilst also offering the visualization of interdependencies to assist in selection of ‘core’ dependencies (those of high impact).

3.1.2. Critical Use Case Model

Use case modelling is used to identify everyone who interacts with the existing system and the corresponding processes that are carried out. UML models have traditionally been the form used to express this; however standard diagram drawing software can be used. Many UML packages exist; Microsoft Visio offers support as standard, and open source integrated development environments (IDEs) such as Eclipse offer numerous plug-ins, along with purpose specific tools such as the open source ArgoUML6 by Tigris and Altova’s closed source UModel7.

3.1.3. Propose Initial Business Case

2 Project – Microsoft Corporation, http://office.microsoft.com/en-au/project/ 3 Visio – Microsoft Corporation, http://office.microsoft.com/en-au/visio/ 4 Rational Rose – IBM, http://www-01.ibm.com/software/rational/ 5 Excel – Microsoft Corporation, http://office.microsoft.com/en-au/excel/ 6 ArgoUML – Tigris, http://argouml.tigris.org/ 7 UModel – Altova, http://www.altova.com/products/umodel/uml_tool.html

The business proposal for a software system cannot be visualized beyond the individual quantitative components, such as financial return-on-investment (ROI). The initial risk assessment performed can however be visualized by using the precedence networks available in project management tools (e.g. Microsoft Project).

3.1.4. Candidate System Architecture

Significant decisions about what the software components are and how they are to be organised can be broken down, listing the critical subsystems and defining their relationships with each other. This interconnectivity again relates to the work done by Carlshamre et al. (2001).

3.1.5. Initial Project Plan

The initial outline for the development, scheduling of completion dates along with budgeting can be visualized for user in project management tools, such as Microsoft Project or Stand By Soft’s RationalPlan8.

3.1.6. Proof of Concept (Prototype)

If applicable, a prototype will need to be developed, which in itself serves as another software project, utilising the same tools/research that are applicable to the SDLC of a full scale project. As with any project, analysis, requirements selection and development and review must all be carried out. Traditional concrete models such as a waterfall or spiral do not enable the rapid development often required for prototyping. Rapid Application Development (RAD) techniques favouring agility and quick development can improve prototype develop by offering a more flexible approach to the developer. Despite RAD being commonly used in the prototyping phase, the change of methodology from a more concrete one to RAD doesn’t impact on the tools used.

3.2. Requirements and Design Phase3.2.1. Analysis and Elicitation

The early stages of requirements analysis and elicitation are primarily focused on system analysis and extracting information from the current system and its users, utilising various techniques. The written nature of contextual analysis and user profiling makes them difficult to visualize using SV (excluding the use of document formatting tools such as outline views). The required artefacts, including user profiles and domain/contextual analysis, are all primarily text based; preventing the application of traditional visualizations to the step. The results of the elicitation process (with the exception of storyboards), are again textual and cannot be visualised until they are sorted and interdependencies and information flow are identified. Techniques such as background reading, apprenticing, questionnaires, etc. all lead to the creation of large amounts of text. It is in the following stages that this information is sorted, interpreted and visualized accordingly. Early storyboards (and to an extent scenario models and use cases) of the system are visual by definition, and can be created using any drawing program, with UML tools also offering this functionality.

8 Rational Plan – Stand By Soft, http://www.rationalplan.com/

3.2.1.1. Model the System

The primary focus of modelling the system by using storyboards, use cases and a domain model is to identify the actors, events, classes and relationships that are present and interacting within the system. The standard drawing and UML tools as mentioned prior can be used again here. Should the project be incorporating or building on existing code, tools such as CodeSWAT’s Flowchart4j9, Flowchart4C#, etc., enable the designer to help identify actors in systems by automatically creating flowcharts from any existing code. However these tools do not offer integration with any other SDLC design software.

3.2.2. Requirement Specification

Despite it being said that the difficulty for large industry players in adopting formal requirement specifications lies in the ability easily read and understand them (Dulac et al., 2002), little of the work carried out by academia has focused on the need for visualization in the requirements stage. Dulac et al. (2002) focused on offering multiple differing visual representations of a common model to aid in understanding. This theory is in-line with other work, also suggesting that the key in applying visual technologies is in offering the user multiple views of the same system (Domingue et al., 1992, Wu and Storey, 2000, Heath and Etheridge, 1991). Solheim et al. (2005) looked at implementing a requirements visualization system in their ATHENA system, with limited success. Coming to the conclusion that “we believe that connecting requirements to multiple classification structures will provide ... the overview they need to solve interoperability issues”.

Limited commercial products offer relevant functionality to the requirement specification stage, with the products primarily focusing on increasing code development speed and efficiency during product development. IBM’s Telelogic Doors10 (discussed later) can be used to trace design issues and history in Rational Rose, with both Doors and Requisite Pro11 offering integration of individual tasks within the requirements specification with schedules in Microsoft Project.

3.2.2.1. Develop Requirement Models

Prior to the development of the requirement specification, design models exploring various aspects of the system are created. System sequence, operation contracts, state transition, data flow, design class, activity and interaction, class diagrams and class responsibility collaboration (CRC) may all need to be generated to aid the requirement development process. As stated previously, standard diagram tools such Microsoft Visio (which includes UML support as standard) along with industry-specific tools such as IBM’s Rational Rose support the development of these models. Rational Rose together with Requisite Pro offer integration of the diagrams with the later generated requirements, enabling tractability of design requirements, something not offered by

9 FlowChart4j – CodeSWAT, http://www.codeswat.com/cswat/index.php?option=com_content&task=view&id=38&Itemid=56 10 Telelogic Doors – IBM, http://www-01.ibm.com/software/awdtools/doors/ 11 RequisisePro – IBM, http://www-01.ibm.com/software/awdtools/reqpro/

generic tools. Previously mentioned tools such as ArgoUML and the Eclipse IDE plug-ins offer this modelling capability. Thirty-five UML plug-ins are available for Eclipse, with some larger companies also offering plug-ins, such as Altova’s UModel (Altova being better known for their XML and database tools). Despite these UML tools being offer specific functionality for these types of diagrams, their lack of integration into the other stages of the SDLC is a limitation for larger projects.

3.2.2.2. Develop Requirement Specification

The development of the specification document itself is perhaps the most crucial step in the SDLC, as the success of the project will be defined by the accuracy and definition of the requirements. A project of any size will have numerous requirements that become integral to one another, creating tight relationships which often dictate the flexibility and complexity of those areas. Carlshamre et al. (2001) looked at applying visualization specifically to this area to aid in defining and managing these requirements. Jermakovics et al. (2007) focused on visualizing the requirements and their impact and development efforts. Despite its use primarily as review tool, its ability to visualize the requirements, allowing the user to highlight a set of requirements and have it show which areas of the system are impacted by it, allows the designer to visually associate textual requirements with a visual representation of the system.

The specification development focuses on categorizing requirements into specific categories according to a chosen software requirement specification (SRS) template. Management of this document and the associated documents, diagrams, etc. which the requirements were based, can become difficult. The use of tools such as Doors and Rational Rose/Requisite Pro at the earlier stages, enable visualizations of the document. Basic visualizations such as the evolution matrix view offered by Requisite Pro or the representation of requirements as individual objects in Doors allow the designer to visually interpret and group sections of the document, instead of purely dealing with text.

3.3. Development Phase

The development of any project primarily revolves around the code, test, and debug cycle along with the required management, to deal with project scheduling and resource scheduling and allocation. Numerous project management tools exist, both closed and open source, with the chosen package required to deal with compartmentalisation, interdependency, time allocation, effort validation and define responsibilities, outcomes and milestones. The widely known and adopted Microsoft Project offers this required functionality. However many extras are not present, such as issue (or bug) tracking, a lack of a collaborative work environment and no document tracking. Despite this, Project’s dominant adoption can be observed by the integration with Project offered by numerous packages from other developers, such as Doors and RequisitePro.

The need for project management goes across all fields, with work by Russell and Udaipurwala (2002) in applying visualization to project management in the building industry. These same concepts can be directly applied to project management in the SDLC, with the outcomes covering the advantages to having numerous planning charts (the same data presented in multiple views).

This enabled the user to be able to visualize the ‘big picture’, whilst still having the capability to ‘drill down’ to the local details (a common requirement).

Zhang and Zhu (1998) focused on a different aspect, visualization of application scheduling in a dynamic environment. They propose a system, Scheduling With A Vision (SWAV), that enables managers to make decisions despite the uncertainty or ever evolving or unknown status of influential environment variables. However despite their efforts, the authors note that information visualization is still in the early stages, requiring further work.

Dependent upon the development model, prototyping may be a regular occurrence throughout development. As mentioned previously, these prototypes would be dealt with as mini-projects, with their own lifecycle, most likely using the RAD development model. This change of development model doesn’t require a new toolset, with tools that support the concrete model also support RAD.

3.3.1. Implementation

Before any code is written, a decision must be made whether to buy/reuse existing code or implement it from scratch. Use of existing modules can lead to other issues, especially if the documentation is poor or nonexistent. Rigi, one of the original SV tools, helps to enable the developer to reverse engineer an application. Rigi, and it’s later extension SHriMP, allow the user to view the relations between various subsystems represented as a graph (Storey et al., 1997b). With SHriMP utilising a temperamental fish-eye view, it allows the user to focus on multiple elements simultaneously for more detail, whilst still retaining how the element fits into the global context (a common complaint in SV navigation).

If source code and version control history are available, existing code can be examined to identify risky/bug ridden areas of code that perhaps needs further work or should be redesigned or rewritten from scratch. SeeSoft (Eick et al., 1992) provides line-orientated statistics for large systems, offering the ability to condense thousands of lines of code into one screen. Despite only being able to show one metric at a time, its ability to easily switch metrics and the high information density make it a useful tool. The code itself is often viewed in another window alongside the metrics, offering a second viewing portal (Asija, 1999).

3.3.2. Code, Test, Debug, Repeat

The vast majority of work in the SV field has focused on helping the developer understand the system they are working on. Various approaches have been implemented (as will be discussed), with some research using line orientated statistics, whilst others focused on program structure. Both approaches offered singular snapshots of the system, or the project’s evolution over time through the use of various snapshots taken throughout the project’s SDLC.

Storey et al. (1997a) and Wu and Storey (2000) both look at SHriMP, and its ability to facilitate code exploration and searching (something often mentioned as lacking in SV systems). As previously mentioned, SHriMP facilitates the use graphs with fish-eye focusing to allow the use to zoom in on multiple objects at once, whilst still retaining global context. Mentioning that the majority of a coder’s time is spent browsing and searching through code

(Wu and Storey, 2000), SHriMP streamlines this by providing three search facilities to the developer; general (normal text based), artefact (certain elements in the structure, such as object) and relation (search for relationships between objects).

More focused on code management, Collberg et al. (2003) look at GeVol, a system that utilises coloured spike graphs to illustrate the codes evolution based on multiple snapshots (or from a code versioning system). Similar to SeeSoft, in that it can only show one metric at a time, it brings up the concept of cross-snapshot layout, with a focus on keeping artefacts in a 'constant' position in each snapshot. Despite code having changed between snapshots, subsystems are still represented at the same location on the graph, allowing the user to become familiar with the same/similar layout and track the development of subsystems across multiple snapshots.

Software Landscapes (Balzer et al., 2004) looks at visualizing program structure through the use of 2.5D artefacts representations in a 3D representation. Utilising a series of spheres to represent systems (and spheres within spheres to represent subsystems), program structure and relations can be viewed on a 3D field. By using a form of abstraction (distant spheres are opaque, hiding contents, going closer they become transparent, showing their contents) and the use of ‘combined edges’ (the multiple edges between spheres are combined together into one link, with individual links represented a set colour within that ‘trunk’) in the graph the visual interface is always clean, with a minimum of clutter, allowing even complex relationships to be easily traced by the human eye.

Lewerentz and Simon (2002) offer a mixed approach, offering both software metrics along with structural information and with a focus on logical layout in a 3D world, presentation and scalability. By utilising set measures, objects are placed a logical distance from one another depending on their relation to each other, with loosely coupled objects placed further away. This facilitates the display of large numbers of objects (assuming a natural spread of relations), with scalability tests showing its layout was still effective on a 5000 class project.

The Narcissus system (Hendley et al., 1995) also focused primarily on methods for the logical arrangement of elements in a 3D space. Using basic attraction/repulsion physics, graph nodes can automatically arrange themselves based on program structure. A unique property of the Narcissus system was the ability to place icons/2D graphics on the individual elements in the graph, creating a blatant visual clue as to what that element represented.

3D Visualization for Software Development (Bonyuet et al., 2004) proposed another 3D system, Code Mapping, which offered two key differences from other 3D packages. Code Mapping introduces semi-multiuser collaborative environment along with the application of virtual reality to SV. By offering an immersive virtual reality (VR), a user can utilise a different level of interactivity. As sections are highlighted by the user in VR (or the 2D representation of it), they become available for other colleagues to review and edit, offering a collaborative, team orientated approach to SV, something not offered elsewhere.

Walker et al. (1998) highlight the importance of creating a tool to bridge the gap between the hierarchical structure of object orientated system and the run time execution structure.

By looking at the number of, and interaction between run time objects through an execution-speed independent visualization, a developer can actually view what internal relationships their code has developed. However, the system cannot identify if the object are interacting with one another as the developer instructed or intended. This approach is different from those previously mentioned, as it examines a previously ignored area regarding SV, the run time relations between multiple object instances.

Other work exists that have analysed the current options available for SV; however they have taken a different approach to categorising them. Asija (1999) examines at the current state of SV research (by categorically analysing individual research tools regarding their SV technique) and the current problems facing it. This approach critiques more the technique of the tool, rather than focusing on where the tool fits into the actual SDLC and what benefit it offers the developer.

(Feijs and Jong, 1998) looked at using Virtual Reality Modelling Language (VRML) (a de-facto standard) to model the SV system. The use of VRML provides “a way of describing multi-participant interactive simulations” (Feijs and Jong, 1998), allowing for the virtual worlds to have limited interactive behaviour. A few interesting approaches can be observed. The use of 3D space has been categorized to allow each axis to imply a certain meaning. For example, the third dimension was used to demonstrate the grouping of different types of nodes. This is a different approach from other 3D systems, which used the extra space to increase information density. Another interesting design choice was the use of coloured Lego blocks to represent different entity types. Although the use of categorical colour isn’t new, the use of Lego to literally imply a ‘building block’ is a logical model for nodes in this type of visualization, as the shape alone helps to imply meaning, regardless of the objects size or orientation on screen. This acts as a metaphor, helping the user to develop their internal mental model of the system, even if they are new to the system.

Static analysis tools (SeeSoft and GeVol) give project managers the ability to analyse numerous metrics about the project. Information such as repeatedly edited areas of code (and thus possibly bug prone) and the programmers responsible for any areas of the system can be highlighted, allowing the allocation of resources as appropriate. Again these metrics, when linked with the previously mentioned project management tools, give the manager the capability to review development and critical path progress.

The commercial software tool Structure10112 (which can function as plug-in for supported IDEs) allow developers to set a minimum threshold of acceptable complexity. When this threshold is passed, the overly complex areas are highlighted for further revision. This type of semi-automatic visualization acts as a quick and useful tool for the developer.

Sotoarc13 is another commercial tool, performing structural analysis in C, C++ and Java. It allows the system architect to construct the desired software structure within the SV system. As code is written, Sotoarc analyses the code’s conformance to the desired structure, alerting the user when differences occur by highlighting the violations. As a

12 Structure101 – Headway Software, http://www.headwaysoftware.com/products/structure101/index.php13 Sotoarc – hello2morrow, http://www.hello2morrow.com/products/sotoarc

management tool, this approach helps to ensure that the software being written is what was actually designed.

Lattix LDM14, also commercial, provides the manager with a dependency matrix, listing the dependencies for each individual subsystem, along with which other sub systems have the same dependencies. This enables the creation of what-if scenarios, where problems with one dependency can cascade to other subcomponents. Applications such as the implications of an unstable class’s impact on the rest of the project can easily be shown.

University of Augsberg’s statistical analysis tool, Mondrian15, although not specific to software engineering, allows the visualization of general statistical data in various forms. Meyer et al. (2006) looked at Mondrain, proposing a new approach to SV where instead of duplicating the data required to construct the visualization’s meta-model for the (bringing the data to the visualization), the visualization should be brought to the data (no creating of a second meta-model). Traditional SV systems analyse the system to be modelled, extracting the required information to create the relevant visualization. The generated meta-model is actually a separate, duplication of data from the system itself (moving data to the visualization). It is proposed that the SV system should be able to directly interact with the system being modelled, without requiring the intermediary meta-model (bringing the visualization to the system). It also introduces the idea that engineers shouldn’t be forced to use set visualization tools, but rather be able to script the required visualization in their preferred tool/environment.

NDepend16 is a commercial tool that allows the visualization of code dependencies (by either a matrix or graph). It offers a feature unseen by other packages in the use of a Code Query Language (CQL). CQL, with similar language and syntax to SQL, allows the developer to quickly search large projects not only text results, but also search for results relevant to implementation, such as use of interfaces and inheritance, revision history and cyclomatic complexity.

3.3.3. Optimization, Verification, Validation

Various forms and methods for software testing exist. Aside from the previously discussed work towards helping visualize software structure and execution, the visualization of information specifically relevant to testing is crucial to ensure software quality.

Parker (1996) is a thesis exploring the possibility of visualizing a programs execution within the program’s structure. The concept of a ‘snake’ was proposed to track execution, where a snake consists of a head (of various shapes) and a tail. The various heads can be associated with different states, with the tail representing what areas have just been executed. This snake moves throughout the various visual objects (which represent the programs structure) to show which part of which element is currently (and with the tail, has just finished) executing. This approach easily extends to support multithreading, with multiple snakes used, the execution of each thread can be viewed in tandem with the others.

14 Lattix LDM – Lattix Inc., http://www.lattix.com/products/LDM.php15 Mondrian – University of Augsberg, http://rosuda.org/mondrian/16 NDepend – Patrick Smacchia, http://www.ndepend.com/

Mukherjea and Stasko (1994) look at the integration of algorithm animation with an imbedded, high level debugger. Stating that engineers are less likely to use a visual tool when the combined time taken to use the visual tool and then fix the bug in their debugger is greater than just using the debugger on its own. The project, Lens, focused on the developer not having a visualization paradigm and without the programmer having to write mode code than if the system wasn’t used.

The debugging cycle of bug identification, identify what needs to be changed in the code (and the impact of that change), code modification and then retesting is a time consuming cycle. The previous tools Rigi, SHriMP, NestedVision, SeeSoft can all offer the developer benefits during testing and debugging, specifically by helping visualize the software structure and in the case of SHriMP, allow the developer to quickly find code through a search facility.

Code optimization has become increasing complex with the introduction of parallel architectures. Heath and Etheridge (1991) propose SV as a logical solution to this problem, developing ParaGraph, a tool that provides twenty-five different views of the same data extracted from the execution of a program. The data extracted relates to performance of the system, allowing for a post-execution review of statistics such as processor utilization and message ques. Despite offering benefits, the authors acknowledge the lack of support for real time performance analysis is an issue.

3.3.4. Documentation

Due to the nature of documentation and manuals, the visualization of software to specifically assist in the development of software documentation is a difficult task (assuming we exclude the incorporation of structural diagrams, etc. created by tools used earlier in the SDLC and focus on the visualization of the document development, not its contents). Despite tools existing for document visualization (and excluding formatting tools such outline views), these tools primarily focus on the relationships between documents and the links between the text and their citations, neither of which are applicable to the development of the system documentation itself, but more document management. It is important to note the difference between document visualization and formatting.

3.4. Transition and Maintenance Phase3.4.1. Deployment

Prior to the full scale roll out of software, an initial beta test is often conducted. The beta audience will be dependent on the nature of the project, which will impact the required level of user training. Aside from the use of project management software for the planning of user training events and a staged rollout, etc., this phase is primarily ‘hands on’, and does not relate to SV. The deployment schedule and associated events can be visualized and managed to an extent using the same tools previously used to track and manage the development of the software system. The issues identified during the beta testing (assuming they are bugs and not design issues), are handled as internal bugs were during the development phase.

Following the successful completion of the beta rollout, the completed product is deployed, repeating the same steps as the beta regarding user training and bug resolution.

3.4.2. Maintenance, Retirement and Future Development

Product maintenance follows the final steps of the SDLC, with possible continued roll outs and software upgrades/bug fixes, utilising the same, previously available software tools. Despite a project have coming to the end of its SDLC, its incorporation or reuse of code in other projects has just begun, linking in the earlier steps in the SDLC which analyse whether to buy, build or reuse code. It is also important to note that any software company that tracks internal development metrics will make use of the previously discussed project management and code reviewing software to conduct a post-development review.

4. Conclusions and Future Work

In this paper, we have examined the current state of software visualization in relation to the software development lifecycle. By examining the current state, we have identified areas within the lifecycle which could significantly benefit from a specified application of software visualization.

Currently, both academic and industry work in the field has been primarily focusing on helping the developer manage and understand (and in some cases reverse engineer) the code as quickly as possible. By analysing the software development lifecycle, we can see that the effort devoted to visualizing the later stages of the SLDC is not reflected equally in the actual effort/steps required during the earlier stages of the SDLC. Despite the design and requirements stages of large software project often being the most crucial (with 21.8% of projects failing due to problems with the requirements (Standish-Group-International, 1995)), researchers have ignored the possible benefits of applying visualization to the software design and requirements stages. Despite already having limited tools available, these early stages of the SDLC tended to have more generalised, non-purpose specific tools. This presents an opportunity for developers (both academic and industry) to explore the benefits SV in these areas.

Aside from version tracking of the requirements development, few tools exist to visualize the numerous documents and links between them (excluding formatting tools such as outlining), from which the system is developed. There also exists no method to map individual or groups of documented requirements to their resulting code/impact in the system (which would surely prove valuable in the post development review of requirement impact and scope creep). Efforts need to be made to further integrate SV seamlessly into the development process, as the vast majority of current tools do not offer any functionality within an IDE, and require the running of a separate system which extracts information from the code to only another system alongside the user’s development system. From a usability point of view, this is crucial, as there is no point in offering functionality such as searching, only to have the user be required to find the same code again in a different system to actually make a change. The lack of a multi-user, client-server approach in SV means that no universal representation visualization for a certain system exists within an organization, as each developer will have the representation that was current for them when their visualization system created its meta-structure database. It is in these areas which further SV research and development must focus.

5. References

ASIJA, S. (1999) Visualization of Object-Oriented Design Models. Telecommunications and Information Systems. Chicago IL, Depaul University.

BALZER, M., NOACK, A., DEUSSEN, O. & LEWERENTZ, C. (2004) Software Landscapes: Visualizing the Structure of Large Software Systems. Symposium on Visualization. Konstanz, Germany, Joint Eurographics.

BONYUET, D., MA, M. & JAFFREY, K. (2004) 3D Visualization for Software Development. Proceedings of the IEEE International Conference on Web Services. IEEE Computer Society.

CARLSHAMRE, P., SANDAHL, K., LINDVALL, M., REGNELL, B. & DAG, J. N. (2001) An Industrial Survey of Requirements Interdependencies in Software Product Release Plannin. Proceedings of the Fifth IEEE International Symposium on Requirements Engineering. IEEE Computer Society.

COLLBERG, C., KOBOUROV, S., NAGRA, J., PITTS, J. & WAMPLER, K. (2003) A system for graph-based visualization of the evolution of software. Proceedings of the 2003 ACM symposium on Software visualization. San Diego, California, ACM.

DOMINGUE, J., PRICE, B. & EISENSTADT, M. (1992) A framework for describing and implementing software visualization systems. Proceedings of the conference on Graphics interface '92. Vancouver, British Columbia, Canada, Morgan Kaufmann Publishers Inc.

DULAC, N., VIGUIER, T., LEVESON, N. & STOREY, M. A. (2002) On the use of visualization in formal requirements specification. Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on.

EICK, S. G., STEFFEN, J. L. & ERIC E. SUMNER, J. (1992) Seesoft-A Tool for Visualizing Line Oriented Software Statistics. IEEE Trans. Softw. Eng., 18, 957-968.

FEIJS, L. & JONG, R. D. (1998) 3D visualization of software architectures. Commun. ACM, 41, 73-78.HEATH, M. T. & ETHERIDGE, J. A. (1991) Visualizing the performance of parallel programs. Software,

IEEE, 8, 29-39.HENDLEY, R. J., DREW, N. S., WOOD, A. M. & BEALE, R. (1995) Case study: Narcissus: visualising

information. Proceedings of the 1995 IEEE Symposium on Information Visualization. Atlanta, Georgia, IEEE Computer Society.

JERMAKOVICS, A., SCOTTO, M., SILLITTI, A. & SUCCI, G. (2007) Lagrein: Visualizing User Requirements and Development Effort. Program Comprehension, 2007. ICPC '07. 15th IEEE International Conference on.

LEWERENTZ, C. & SIMON, F. (2002) Metrics-based 3D visualization of large object-oriented programs. Visualizing Software for Understanding and Analysis, 2002. Proceedings. First International Workshop on.

MEYER, M., GÎRBA, T. & LUNGU, M. (2006) Mondrian: an agile information visualization framework. Proceedings of the 2006 ACM symposium on Software visualization. Brighton, United Kingdom, ACM.

MUKHERJEA, S. & STASKO, J. T. (1994) Toward visual debugging: integrating algorithm animation capabilities within a source-level debugger. ACM Trans. Comput.-Hum. Interact., 1, 215-244.

OWEN, G. S. (1993) Visualization Education in the USA. Journal of Computers and Education, 8, 6.PARKER, G. (1996) NestedVision3D-trace, program execution visualization with NestedVision3D.

Graduate Academic Unit. New Brunswick, University of New Brunswick.RUSSELL, A. D. & UDAIPURWALA, A. (2002) Construction Schedule Visualization. IN ANTHONY, D. S. &

JOHN, C. M. (Eds.). ASCE.SOLHEIM, H., LILLEHAGEN, F., PETERSEN, S. A., JORGENSEN, H. & ANASTASIOU, M. (2005) Model-

driven visual requirements engineering. Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference on.

STANDISH-GROUP-INTERNATIONAL (1995) The Standish Group Report - Chaos. Standish Group International.

STOREY, M.-A. D., WONG, K., FRACCHIA, F. D. & MUELLER, H. A. (1997a) On Integrating Visualization Techniques for Effective Software Exploration. Proceedings of the 1997 IEEE Symposium on Information Visualization (InfoVis '97). IEEE Computer Society.

STOREY, M.-A. D., WONG, K. & MÜLLER, H. A. (1997b) Rigi: a visualization environment for reverse engineering. Proceedings of the 19th international conference on Software engineering. Boston, Massachusetts, United States, ACM.

WALKER, R. J., MURPHY, G. C., FREEMAN-BENSON, B., WRIGHT, D., SWANSON, D. & ISAAK, J. (1998) Visualizing dynamic software system information through high-level models. SIGPLAN Not., 33, 271-283.

WILNER, D. (1995) WindView: a tool for understanding real-time embedded software through system vizualization. Proceedings of the ACM SIGPLAN 1995 workshop on Languages, compilers, & tools for real-time systems. La Jolla, California, United States, ACM.

WU, J. & STOREY, M.-A. D. (2000) A multi-perspective software visualization environment. Proceedings of the 2000 conference of the Centre for Advanced Studies on Collaborative research. Mississauga, Ontario, Canada, IBM Press.

ZHANG, P. & ZHU, D. (1998) Information Visualization in Project Management And Scheduling. Proceedings of The 4th Conference of the International Society for Decision Support Systems. Helsinki, Finland.