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 lifecyclewhich can value from further study into the application of specialised software visualizationto them.
- 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 involvedventure. 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.
Largeamounts 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, anotherkey 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 complexitiesinvolved in thesoftware 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. AsParker (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 studyanalyses 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.
- Methodology
The initialstarting 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 listthen 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). Theresulting list acted as a visual guide to what steps and also which areas (groups of steps)in the SDLC could be visualized.
Previous resourcesfrom 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.
- 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 engineerthe 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 SVtoolsfocus on its benefits to the developer by increasing thedensity 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 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 Visio[3]), 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 Rose[4], 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.
- 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 Excel[5]) 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 crucialare 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 identifyeveryone 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 ArgoUML[6]by Tigris andAltova’s closed source UModel[7].
3.1.3.Propose Initial Business Case
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 usingthe 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’sRationalPlan[8].
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 Phase
3.2.1.Analysis and Elicitation
The early stages of requirements analysis and elicitation are primarily focused on system analysis and extracting information fromthe 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 visualizationsto 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 alsooffering thisfunctionality.
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 Flowchart4j[9], 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 primarilyfocusing onincreasing code development speed and efficiency during product development.IBM’s Telelogic Doors[10] (discussed later) can be used to trace design issues and history in Rational Rose, with both Doors and Requisite Pro[11]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 generic tools. Previously mentioned tools such as ArgoUML and the Eclipse IDE plug-ins offer this modellingcapability. Thirty-fiveUML plug-insare 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 matrixview 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 theintegration with Project offered by numerous packages from other developers, such as Doors and RequisitePro.