• Visualizing software development data

    by  • August 6, 2013 • Quality measurement, Software development, Software quality, Visualization

    sqale-dashboardKienle and Müller (2007) have identified requirements for software visualization tools by conducting a comprehensive literature survey. Their focus was on tools that visualize the structure of source code and measurements derived from the source code. The identified non-functional requirements are: rendering scalability, information scalability, interoperability, customizability, interactivity, usability, and adoptability. The identified functional requirements are: views, abstraction, search, filters, code proximity automatic layout, undo/history, and miscellaneous.

    Most of these requirements can be generalized to the domain of visualizing any software development related data as will be done in U-QASAR. Below we interpret the identified requirements from the point of view of this more general visualization domain.

    Functional requirements:

    1. Views. Multiple views to the data are needed. The views should be dynamic, i.e. the view synchronize and recomputed their information when the underlying data changes. Sometimes both graphical and textual data are needed in the same view. Data in a view may have links to other views.
    2. Abstraction. Different levels of abstraction of the data are needed. Grouping of data on a certain level results in layered views. Grouping and collapsing functionalities are needed to navigate through the different abstraction levels.
    3. Search. Searches to the data are needed. For example, searching for data about a certain project, software module, defect, person etc.
    4. Filters. When amount of data is high, uninteresting items should be filtered out. For example, filtering out low priority defects when analysing defect densities.
    5. Code proximity. Code proximity means the ability of the visualizer to provide easy and fast access to the underlying source code. In a more general case, it could mean access to content of defect reports, project task descriptions etc.
    6. Automatic layouts. Visualising software structure typically means visualization of large graphs for which automatic layout capabilities are important. Other software development measurements are often simpler, but in case there are complex structures in the data to be visualized automatic layout may be needed.
    7. Undo/history. It should be possible to cancel changes made to the visualizations. Tracking navigation steps and possibility to return back to a certain step are also needed.
    8. Miscellaneous. Miscellaneous requirements include use of colors, ability to place annotations on graphical entities, manipulating graphs (zooming), deleting/editing view entities, and saving.

    Non-functional requirements:

    1. Rendering scalability. Rendering speed should scale up to large amount of data.
    2. Information scalability. The system should avoid the cognitive overload of the user caused by “overplotting”. Abstraction and filtering are needed.
    3. Interoperability. In practice there is a need to visualize data originating from a number of different systems. In a general case the data from different origins need to be combined in the same visualization. Importing and combining data from different systems are needed.
    4. Customizability. It is difficult to anticipate the visualizations initially, and therefore it should be possible to customize them.
    5. Interactivity. Source code visualization is interactive and explorative in nature. The same applies, at least some degree, for other software development data. Instead of following specific workflows, the users should be able to explore views of the data.
    6. Usability. The tool should provide useful data and have an intuitive and easily used interface. The tool should not interfere with existing tools or work practices.
    7. Adoptability. Both technical and non-technical factors influence the chances of a tool to be adopted. Tool needs to support the right tasks. Ease of use and adaptability to the tasks at hand cause tool to be adopted. Programmable tools can more easily be incorporated into other toolsets.

    In (Bassil and Keller, 2001), the various functional aspects of the software visualization systems were ranked according to their usefulness. The research was conducted as a survey responded by 107 users of software visualization systems from different organizations mainly from industry. Each respondent evaluated the usefulness of 34 different functional aspects. The focus was on source code visualization and many of the aspects were specific for that domain. However, some of them are generalizable, and among those the most useful were: search tools, hierarchical representations, use of colours and navigation across hierarchies.

    Untitled

    About

    We are a strategy consultancy. We work with companies & institutions worldwide on strategy crafting, internationalisation & business modelling.

    http://www.vaibmu.com