Conference PaperPDF Available

Visualization of Software and Systems as Support Mechanism for Integrated Software Project Control

Authors:

Abstract and Figures

Many software development organizations still lack support for obtaining intellectual control over their software development processes and for determining the performance of their processes and the quality of the produced products. Systematic support for detecting and reacting to critical process and product states in order to achieve planned goals is usually missing. One means to institutionalize measurement on the basis of explicit models is the development and establishment of a so-called Software Project Control Center (SPCC) for systematic quality assurance and management support. An SPCC is comparable to a control room, which is a well known term in the mechanical production domain. One crucial task of an SPCC is the systematic visualization of measurement data in order to provide context-, purpose-, and role-oriented information for all stakeholders (e.g., project managers, quality assurance managers, developers) during the execution of a software development project. The article will present an overview of SPCC concepts, a concrete instantiation that supports goal-oriented data visualization, as well as examples and experiences from practical applications.
Content may be subject to copyright.
!
!
!
!
!
!
!
!
!
!
!
This is an author-generated version.!
!
The final publication is available at link.springer.org!
!
DOI: 10.1007/978-3-642-02574-7_94!
Link: http://link.springer.com/chapter/10.1007%2F978-3-642-02574-7_94!
!
Bibliographic information:!
!
Peter Liggesmeyer, Jens Heidrich, Jürgen Münch, Robert Kalcklösch, Henning Barthel, Dirk
Zeckzer. Visualization of Software and Systems as Support Mechanism for Integrated Software
Project Control. In Human-Computer Interaction: New Trends, volume 5610 of Lecture Notes in
Computer Science, pages 846-855. Springer Berlin Heidelberg, 2009.
Visualization of Software and Systems as Support
Mechanism for Integrated Software Project Control
Peter Liggesmeyer1, 2, Jens Heidrich1, Jürgen Münch1, Robert Kalcklösch2,
Henning Barthel1, Dirk Zeckzer2
1Fraunhofer IESE, Fraunhofer Platz 1, 67663 Kaiserslautern, Germany
{peter.liggesmeyer, jens.heidrich, juergen.muench, henning.barthel}@iese.fraunhofer.de
2TU Kaiserslautern, Post Office Box 3049, 67653 Kaiserslautern, Germany
{kalckloesch, zeckzer}@informatik.uni-kl.de
Abstract. Many software development organizations still lack support for ob-
taining intellectual control over their software development processes and for
determining the performance of their processes and the quality of the produced
products. Systematic support for detecting and reacting to critical process and
product states in order to achieve planned goals is usually missing. One means
to institutionalize measurement on the basis of explicit models is the develop-
ment and establishment of a so-called Software Project Control Center (SPCC)
for systematic quality assurance and management support. An SPCC is compa-
rable to a control room, which is a well known term in the mechanical produc-
tion domain. One crucial task of an SPCC is the systematic visualization of
measurement data in order to provide context-, purpose-, and role-oriented in-
formation for all stakeholders (e.g., project managers, quality assurance manag-
ers, developers) during the execution of a software development project. The
article will present an overview of SPCC concepts, a concrete instantiation that
supports goal-oriented data visualization, as well as examples and experiences
from practical applications.
Keywords: Software Project Control Centers, Visualization Mechanisms, Data
Visualization, GQM.
1 Introduction
The complexity of software-intensive systems and development projects continues to
increase. One major reason is the ever-increasing complexity of functional as well as
non-functional software and systems requirements (e.g., reliability or time constraints
for safety critical systems). The more complex the requirements, the more people are
usually involved in meeting them, which further increases the complexity of control-
ling and coordinating a project. This, in turn, makes it even harder to develop the
system according to plan (i.e., matching time, quality, and budget constraints). Project
control issues are very hard to handle. Many software development organizations still
lack support for obtaining intellectual control over their software development pro-
2 Peter Liggesmeyer et. al.
jects and for determining the performance of their processes and the quality of the
produced products. Systematic support for detecting and reacting to critical process
and product states in order to achieve planned goals and quality is usually missing
[15]. One way to support effective control of software development projects is the use
of basic engineering principles [7], [19], with particular attention to the monitoring
and analysis of actual product and process states, the comparison of actual states with
planned states, and the initiation of any necessary corrective actions during project
execution. Effectively applying these principles requires the collection, interpretation,
and appropriate visualization of measurement data according to a previously meas-
urement goals and plans in order to provide stakeholders with up-to-date information
about the project state. One major challenge is to adequately (and partially integrated)
visualize process and product properties during project execution so that informed
decisions can be made by the relevant stakeholders (such as project managers, quality
assurance personnel). This addresses, for instance, early warning mechanisms that
recognize insufficient quality characteristics of development products or the ability to
generate accurate effort and cost predictions.
In the aeronautical domain, air traffic control systems are used to ensure the safe
operation of commercial and private aircraft. Air traffic controllers use these systems
to coordinate the safe and efficient movement of air traffic (e.g., to make certain that
planes stay a safe distance apart or to minimize delays). These systems collect and
visualize all critical data (e.g., the distance between two planes, the planned arrival
and departure times) in order to support decisions by air traffic controllers. Software
project control requires an analogous approach that is tailored to the specifics of the
process being used (e.g., its non-deterministic, concurrent, and distributed nature). A
Software Project Control Center (SPCC) [15] is a control system for software devel-
opment that collects all data relevant to project control, interprets and analyzes the
data according to the project’s control needs, visualizes the data for different project
roles, and suggests corrective actions in the case of plan deviations. An SPCC could
also support the packaging of data (e.g., as predictive models) for future use and con-
tribute to an improvement cycle spanning a series of projects. Controlling a project
means ensuring the satisfaction of project objectives by monitoring and measuring
progress regularly in order to identify variances from the plan during project execu-
tion, so that corrective action can be taken when necessary [17]. Planning is the basis
for project control and defines expectations, which can be checked during project
execution. Project control is driven by different role-oriented needs. We define con-
trol needs as a set of role-dependent requirements for obtaining project control. A
project manager needs different kinds of data, data of different granularity, or differ-
ent data visualizations than a quality assurance manager.
In this article, we want to illustrate selected existing project control approaches
(Section 2), and then focus on a concrete instantiation that supports goal-oriented data
visualization, the so called Specula approach (Section 3). Afterwards, we will present
advanced visualization mechanisms used for controlling risks and quality of devel-
opment projects and selected lessons learned from their application (Section 4). Fi-
nally, we will give a summary and illustrate future research fields (Section 5).
Visualization of Software and Systems 3
2 Related Work
An overview of the state of the art in Software Project Control Centers can be found
in [15]. Most of the existing, rather generic, approaches for control centers offer only
partial solutions. Especially purpose- and role-oriented usages based on a flexible set
of techniques and methods are not comprehensively supported. In practice, many
companies develop their own dashboards (mainly based on Spreadsheet applications)
or use dashboard solutions that provide a fixed set of predefined functions for project
control (e.g., deal with product quality only or solely focus on project costs) and are
very specific to the company for which they were developed.
The indicators used to control a development project depend on the project’s goals
and the organizational environment. There is no default set of indicators that is always
used in all development projects in the same manner. According to [14], a “good”
indicator has to (a) support analysis of the intended information need, (b) support the
type of analysis needed, (c) provide the appropriate level of detail, (d) indicate a pos-
sible management action, and (e) provide timely information for making decisions
and taking action. The concrete indicators that are chosen should be derived in a sys-
tematic way from the project goals [12], making use of, for instance, the Goal Ques-
tion Metric (GQM) approach [3]. Some examples from indicators used in practice can
be found in [1]. With respect to controlling project cost, the Earned Value approach
provides a set of commonly used indicators and interpretation rules. With respect to
product quality, there exists even an ISO standard [10]. However, the concrete usage
of the proposed measures depends upon the individual organization.
The test / diagnosis of complex systems was put on a formal basis in 1967 by [16].
One of the drawbacks was addressed by [13]. A good overview of system diagnosis
models can be found in [2]. With respect to the visualization and applicable tools, an
overview is presented in [20].
3 Goal-oriented Software Project Control
Specula [8] is a state-of-the-art SPCC. It interprets and visualizes collected measure-
ment data in a goal-oriented way in order to effectively detect plan deviations. The
control functionality provided by Specula depends on the underlying goals with re-
spect to project control. If these goals are explicitly defined, the corresponding func-
tionality is composed out of packaged, freely configurable control components. Spec-
ula provides four basic components: (1) a logical architecture for implementing soft-
ware cockpits, (2) a conceptual model formally describing the interfaces between data
collection, data interpretation, and data visualization [9], (3) an implementation of the
conceptual model, including a construction kit of control components, and (4) a
methodology of how to select control components according to explicitly stated goals
and customize the SPCC functionality [8]. The methodology is based on the Quality
Improvement Paradigm (QIP) and makes use of the GQM approach [3] for specifying
measurement goals. QIP is used to implement a project control feedback cycle and
make use of experiences and knowledge gathered in order to reuse and customize
4 Peter Liggesmeyer et. al.
control components. GQM is used to drive the selection process of finding the right
control components according to defined goals. The different phases that have to be
considered for setting up and applying project control mechanisms can be character-
ized as follows:
I. Characterize Control Environment: First, stakeholders characterize the environ-
ment in which project control shall be applied in order to set up a measurement pro-
gram that is able to provide a basis for satisfying all needs.
II. Set Control Goals: Then, measurement goals for project control are defined and
metrics are derived determining what kind of data to collect. In general, any goal
derivation process can be used for defining control objectives. For practical reasons,
we focus on the GQM paradigm for defining concrete measurement goals addressing
the measurement object, purpose, quality focus, viewpoint, and context information.
III. Goal-oriented Composition: Next, all control mechanisms for the project are
composed based on the defined goals in order to provide online feedback on the basis
of the data collected during project execution; that is, control techniques and visuali-
zation mechanisms are selected from a corresponding repository and instantiated in
the context of the project that has to be controlled. This process is driven by interpre-
tation and visualization models that clearly define which indicators contribute to spe-
cific control objectives, how to assess and aggregate indicator values, and how to
visualize control objectives and intermediate results.
IV. Execute Project Control Mechanisms: Once all control mechanisms are speci-
fied, a set of role-oriented views is generated for controlling the project. When meas-
urement data are collected, the control mechanisms interpret and visualize them ac-
cordingly, so that plan deviations and project risks are detected and a decision-maker
can react accordingly. If a deviation is detected, its root cause must be determined and
the control mechanisms have to be adapted accordingly. This, does, for example,
require data analyses on different levels of abstraction in order to be able to trace
causes of plan deviations.
V. Analyze Results: After project completion, the resulting visualization catena has
to be analyzed with respect to plan deviations and project risks detected in time, too
late, or not detected at all. The causes for plan deviations and risks that were detected
too late or that were not detected at all have to be determined.
VI. Package Results: The analysis results of the control mechanisms that were ap-
plied may be used as a basis for defining and improving control mechanisms for fu-
ture projects (e.g., selecting the right control techniques and data visualizations,
choosing the right parameters for controlling the project).
Fig. 1 illustrates the basic conceptual modules of the Specula approach. The cus-
tomization module is responsible for selecting and adapting the control components
according to project goals and characteristics and defined measurement (control)
goals. It is possible to include past experience (e.g., effort baselines, thresholds) in the
selection and adaptation process. This experience is stored in a experience base. A
Visualization Catena (VC) is created, which formally describes how to collect, inter-
pret, and visualize measurement data. The set of reusable control components from
which the VC is instantiated basically consists of integrated project control techniques
(for interpreting the data in the right way) and data visualization mechanisms (for
presenting the interpreted data in accordance with the role interested in the data). The
central processing module collects measurement data during project performance and
Visualization of Software and Systems 5
interprets and visualizes them according to the VC specification. Measurement data
can be retrieved automatically from project repositories or manually from data collec-
tion forms and formal documents. Finally, charts and tables are produced to allow for
online project control. A packaging module collects feedback from project stake-
holders about the application of the control mechanisms and stores them in an Experi-
ence Base (e.g., whether a baseline worked, whether all plan deviations were detected,
or whether retaliatory actions had a measurable effect). Using these modules, the
Specula framework is able to specify a whole family of project control centers (which
is comparable to a software product line for control centers).
Online Control
Online Control
GQM
Plan
GQM
Plan
Visualisation
Catena
Visualisation
Catena
Project
Planners
Goals and
Characteristics
Goals and
Characteristics
Customisation
Customisation
Experience
Base
Experience
Base
Data Collection, Interpretation,
and Visualisation
Data Collection, Interpretation,
and Visualisation
Control
Components
Control
Components
Project
Members
Project
Stakeholders
WFI
WFI
WFI
WFI
DE
DE DE
DE
DE
DE
DB
DB
FI
FI FI
FI
FI
FI
VI
VI VI
VI
VI
VI
FI
FI
IDE
IDE
DE
DE
VI
VI
G
G
Q
QQ
QQ
Q
M
MM
MM
MM
MM
M
Packaging
Packaging
Project
Repositories
Project
Repositories
Documents
GQM Goal Question Metric
VI View Instance
FI Function Instance
DE Data Entry
WFI Web Form Instance
Association
Data Flow
GQM Goal Question Metric
VI View Instance
FI Function Instance
DE Data Entry
WFI Web Form Instance
Association
Data Flow
Fig. 1. Overview of the Specula framework.
Fig. 2. Example visualization of a simple hierarchical Gantt chart.
The Specula approach was evaluated as part of industrial case studies in the Soft-
Pit project (a public German research project, no. 01ISE07A) in which a prototypical
implementation of the concepts was used. Results of the first two iterations can be
found in [5] and [6]. In general, people perceived the usefulness and ease of use of the
6 Peter Liggesmeyer et. al.
Specula control center as positive. However, usefulness and ease of use also varied
across the different case study providers depending on the state of the practice before
introducing the control center solution and it also largely varied across the different
visualization mechanisms used. In the Soft-Pit case, mostly “standard visualizations”
for project control were used, such as Gantt charts, line/bar charts, tables/matrixes and
simple trees (see, e.g., Fig. 2). One major success factor for the usefulness of visuali-
zations was how intuitive the visualization can be interpreted. Especially, when ag-
gregating data and complex, multi-dimensional relationships needs to be illustrated,
this requires more advanced visualization concepts.
4 Advanced Visualization Mechanisms
The following sub-sections present examples for advanced mechanisms used for visu-
alizing the risks and quality of development projects and summarize lessons learned
from their application. Further visualization mechanisms of quality properties, espe-
cially safety and security for embedded systems, is currently investigated in the Ger-
man research project ViERforES (see http://www.vierfores.de).
Fig. 3. 3D Treemap visualizing different metrics.
4.1 Visualizing Code Quality
To analyze the quality of a software system, metrics are used that measure certain
attributes of the software’s internal structure. Many metric tools exist that are able to
define such metrics and collect measurement data automatically. For analysis pur-
poses different visualization techniques such as node-link diagrams and graphs are
Visualization of Software and Systems 7
used in order to help the user in drawing conclusions about the quality of the software
system. These techniques use a limited set of graphical elements like text, simple
geometric shapes or uniform color fills to highlight relevant attributes of the software
system being visualized. For combining different metric values within one picture, a
3D-Treemap technique (see Fig. 3) was developed and integrated into a code analysis
system at Fraunhofer IESE. This visualization mechanism allows us to map data
measuring code quality to different graphical properties of each cube (such as posi-
tion, size, height, and color). To further analyze these values, the user is able to inter-
actively define new views, pan and zoom within the 3D scene and use a pull-down
menu to initialize other measurement or visualization actions.
4.2 Visualizing Risk Management
Risk management and especially risk avoidance plays an important role in all devel-
opment and construction activities. For managing risks, a structured process is manda-
tory. Visualization is used for analyzing risks and supporting managers in deciding
upon necessary actions. Siemens developed a methodology named sira that is used for
collecting data about possible risks [4]. This includes structured interviews for deter-
mining possible risks, their probability and importance as well as the possible damage
that may be caused. Based on this analysis, a risk portfolio is created. In order to
analyze these risks, the so-called sira bubble charts were created that summarize all
necessary information that has to be discussed with the customer (see Fig. 4 and [4]).
Fig. 4. sira.iris, a visualization of a risk portfolio.
4.3 Fault Detection in Distributed Systems
The functionality of a software system is distributed over many components and the
interaction between these components plays a crucial role. In order to analyze the
8 Peter Liggesmeyer et. al.
reliability of a system, data about communicating components and their error-
proneness is collected. The output is analyzed using an interactive visualization (see
Fig. 5 and [20]). In this visualization color coding is used to characterize the “faulti-
ness” of components with respect to communication relations. The ratio between
faulty communication and the overall amount of communication is used for coloring
all nodes and edges of the graph, indicating starting points for bug fixing activities.
The overall approach is described in [11]. Interaction plays an important role in this
application. For instance, changing colors helps understanding the impact of faults.
Changing transparency of clusters helps understanding structural information about
the system.
Fig. 5. Faults collected during the execution of a system.
5 Conclusions
This article presented the basic concept of an SPCC for establishing project control by
means of systematic visualization mechanisms. We illustrated existing approaches
and presented a goal-oriented way to establish project control by formalizing the way
measurement data are interpreted and visualized according to a previously defined
measurement goal. Existing approaches offer mostly partial solutions. Especially
goal-oriented usages based on a flexible set of techniques and methods are not com-
prehensively supported [15]. The expected benefits of the goal-oriented visualization
approaches include: (1) improvement of quality assurance and project control by
providing a set of custom-made views of measurement data, (2) support of project
Visualization of Software and Systems 9
nformation overload
thr
on mechanisms can be seen as a valuable contribution towards reaching this
goal.
. SEL
Problem in Fault-
The Experience Factory. Encyclopaedia of Soft-
sira: Mit einem Blick IT-Projekte durchleuchten. SE
ical Software Engineering and Measurement, IEEE Computer
ware Engineering and
ftware
tware
ware Engineering Product Quality. Technical Report. ISO/IEC TR 9126.
Geneva, 2003.
management through early detection of plan deviations and proactive intervention, (3)
support of distributed software development by establishing a single point of control,
(4) enhanced understanding of software processes, and improvement of these proc-
esses, via measurement-based feedback, and (5) preventing i
ough custom-made views with different levels of abstraction.
An important research issue in this context is the development of a schema for
adaptable control techniques and methods, which effectively allows for purpose-
driven usage of an SPCC in varying application contexts. Another research issue is
the elicitation of information needs for the roles involved and the development of
mechanisms for generating adequate role-oriented visualizations of the project data.
Another important research issue is support of change management. When the goals
or characteristics of a project change, the real processes react accordingly. Conse-
quently, the control mechanisms, which should always reflect the real world situation,
must be updated. This requires flexible mechanisms that allow for reacting to process
variations. One long-term goal of engineering-style software development is to con-
trol and forecast the impact of process changes and adjustments on the quality of the
software artifacts produced and on other important project goals. Goal-oriented visu-
alizati
References
1. Agresti, W., Card, D., Church, V.: Manager’s Handbook for Software Development
84-101, NASA Goddard Space Flight Center. Greenbelt, Maryland, November 1990.
2. Barborak, M., Malek, M., and Dahbura, A. T. 1993. The Consensus
Tolerant Computing. ACM Computing Surveys 25, 2 (June), 171–220.
3. Basili, V.R., Caldiera, G., Rombach, D:
ware Engineering 1, 1994, pp. 469-476.
4. Bülte, H., Mäckel, O.: Mehr sehen mit
2009, Kaiserslautern, Germany, 2009.
5. Ciolkowski, M., Heidrich, J., Münch, J., Simon, F., Radicke, M.: Evaluating Software
Project Control Centers in Industrial Environments. In: Proceedings of the First Interna-
tional Symposium on Empir
Society, 2007, pp. 314-323.
6. Ciolkowski, M., Heidrich, J., Simon, F., Radicke, M.: Empirical results from using custom-
made software project control centers in industrial environments. In: Proceedings of the
Second ACM-IEEE International Symposium on Empirical Soft
Measurement, Kaiserslautern, Germany: ACM, 2008, pp. 243-252.
7. Gibbs, W.W.: Software’s Chronic Crisis. Scientific American, 1994, pp. 86-95.
8. Heidrich, J., Münch, J.: Goal-Oriented Setup and Usage of Custom-Tailored Software
Cockpits. In: Proceedings of the 9th international conference on Product-Focused So
Process Improvement, Monte Porzio Catone, Italy: Springer-Verlag, 2008, pp. 4-18.
9. Heidrich, J., Münch, J.: Cost-Efficient Customisation of Software Cockpits by Reusing
Configurable Control Components. In: Ton Dekkers (ed.): Proceedings of the 4th Sof
Measurement European Forum, May 9-11, 2007, Rome, Italy. Smef 2007, pp. 19-32.
10. ISO 9126: Soft
10 Peter Liggesmeyer et. al.
11. Kalcklösch, R.: Gossip-Based Diagnosis of Arbitrary Component-Oriented Systems. Tech-
nische Universität Kaiserslautern, PhD Thesis, 2008.
12. Kitchenham, B.A.: Software Metrics. Blackwell, Oxford, 1995.
13. Kuhl, J. G., and Reddy, S. M. 1980, Distributed fault-tolerance for large multiprocessor
systems. In ISCA ’80: Proceedings of the 7th Annual Symposium on Computer Architec-
ture, ACM Press, New York, NY, USA, La Baule, United States, 23–30.
14. McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J., Hall, F.: Practical Soft-
ware Measurement – Objective Information for Decision Makers, Addison-Wesley Profes-
sional. 1st edition, ISBN 4-320-09741-6, October 15, 2001.
15. Münch, J., Heidrich, J.: Software Project Control Centers: Concepts and Approaches. Jour-
nal of Systems and Software, 70 (1), 2003, pp. 3-19.
16. Preparata, F. P., Metze, G., and Chien, R. T. 1967. On the Connection Assignment Problem
of Diagnosable Systems. IEEE Transactions on Electronic Computers EC-16, 6 (Decem-
ber), 848–854.
17. Project Management Institute: A Guide to the Project Management Body of Knowledge
(PMBOK® Guide) 2000 Edition. Project Management Institute, Four Campus Boulevard,
Newtown Square, PA 19073-3299 USA, 2000.
18. Rombach, H.D.; Verlage, M.: Directions in Software Process Research. Advances in Com-
puters 41, 1995, pp. 1-63.
19. Shaw, M.: Prospects for an Engineering Discipline of Software. IEEE Software 7(6), 1990,
pp. 15-24.
20. Dirk Zeckzer, Leon Schröder, Robert Kalcklösch, Hans Hagen, and Timo Klein: Analyzing
the Reliability of Communication between Software Entities Using 3D Force-Directed
Layout of Clustered Graphs. ACM Conference on Software Visualization (SoftVis'08),
September 16-17, 2008, Herrsching am Ammersee, Germany. 2008.
... The development of enterprise systems requires a great collaboration effort, and the complexity of the collaboration increases the difficulty of adhering to project schedules, fulfilling system requirements, and controlling the overall project (Doumi et al., 2013;Liggesmeyer et al., 2014). A critical factor in the success of software projects is the effectiveness of requirements engineering activities (Fernández, 2017). ...
... There are many ways to visualize software and the systems that it supports, and many tools have been proven to improve the software development process. High levels of software complexity require more people and greater collaboration, which makes it more difficult to adhere to planning schedules and to complete the system development according to the requirements; project control also becomes an issue (Liggesmeyer et al., 2014). Duru, Cakir, and Veysi (2013) observed that software development performance was improved with the use of a statistical software visualization tool called NDEPEND, a performance improvement that was confirmed through both qualitative and quantitative findings. ...
... The development of enterprise systems requires a large collaboration effort, and the complexity increases the difficulty of adhering to project schedules, fulfilling system requirements, and controlling the overall project (Doumi et al., 2013;Liggesmeyer et al., 2014). ...
... Una de las propuestas para apoyar el control efectivo de los proyectos de desarrollo software es el uso de principios básicos de ingeniería, con especial atención al seguimiento y análisis del producto real y los estados de los procesos, la comparación de los estados reales con los planeados, y el inicio de cualquier acción correctiva necesaria durante la ejecución del proyecto [11]. Cuando los gestores comparan los logros con los planes, con frecuencia se centran en el calendario y el coste de las tareas, pero existen otras cuestiones importantes que también deben ser consideradas en el control de proyectos. ...
Article
Full-text available
Resumen Este artículo establece un marco de selección de métricas para controlar la gestión del proyecto de desarrollo software y propone un conjunto inicial de indicadores. La validez de la selección propuesta se evalúa mediante un estudio realizado en varias empresas del País Vasco y se presentan las conclusiones alcanzadas. Palabras clave: Gestión del proyecto software, Control del proyecto software, Métricas proyecto software, Estudio.
... Using SPCC, a project manager can understand the state of a project and check the quality more easily. From this, the Specula approach has been proposed [8], [9]. This approach collects measurement data based on the GQM model. ...
... This leads to a treemap-based layout with graphical representations of software system artifacts as high and low " buildings " grouped in areas of the " software city " . Several other publications addresses the use of 3D-Treemaps in Software Visualization in depth (Liggesmeyer et al., 2009; Bohnet and Döllner, 2011 ). Bohnet and Döllner also mentioned that the use of realistic rendering effects, e.g., shadowing, in 3D-Treemaps support the users' perception of the elements as distinguished ones (Bohnet and Döllner, 2011 ). ...
Conference Paper
Full-text available
3D-Treemaps are an important visualization technique for hierarchical views. In contrast to 2D-Treemaps, height can be used to map one additional attribute of the data items. Using the Treemap technique in combination with large datasets (more than 500k) a fast rendering and interaction techniques that are beyond collapsing/uncollapsing nodes is still one of the main challenges. This paper presents a novel rendering technique that enables the image synthesis of geometrical complex 3D-Treemaps in real-time. The fully hardware accelerated approach is based on shape generation using geometry shaders. This approach offers increased rendering performance and low update latency compared to existing techniques and through it enables new real-time interaction techniques to large datasets.
... Yet recently, notable attempts have been made to make 3-dimensional implicit tree visualizations (usually Treemaps) available to a wider audience. Examples come from the field of Software Visualization, e.g., the immersive software visualization "CodeCity", which uses a Steptree visualization for program code comprehension and analysis of code evolution and quality, or the Fraunhofer IESE Visual Software Analysis Tool, which likewise uses a 3D Treemap approach for visualizing code quality [34], [35]. ...
Article
Full-text available
Apart from explicit node-link representations, implicit visualizations and especially the Treemap as their frontrunner have acquired a solid position among the available techniques to visualize hierarchies. Their advantage is a highly space-efficient graphical representation that does not require explicit drawing of edges. In this paper, we survey the design space for this class of visualization techniques. We establish the design space along the four axes of dimensionality, edge representation, node representation, and layout by examining existing implicit hierarchy visualization techniques. The survey is completed by casting some light into regions of the design space that have not yet been explored. Our design space is not a mere theoretical construct, but a practically usable tool for rapid visualization development. To that end, we discuss a software implementation of the introduced design space.
Conference Paper
Full-text available
Software maps are a commonly used tool for code quality monitoring in software-development projects and decision making processes. While providing an important visualization technique for the hierarchical system structure of a single software revision, they lack capabilities with respect to the visualization of changes over multiple revisions. This paper presents a novel technique for visualizing the evolution of the software system structure based on software metric trends. These trend maps extend software maps by using real-time rendering techniques for natural phenomena yielding additional visual variables that can be effectively used for the communication of changes. Therefore, trend data is automatically computed by hierarchically aggregating software metrics. We demonstrate and discuss the presented technique using two real world data sets of complex software systems.
Conference Paper
Full-text available
Detecting and reacting to critical project states in order to achieve planned goals is one key issue in performing a software development project successfully and staying competitive as a software development company. Software Cockpits, also known as Software Project Control Centres, support the management and controlling of software and system develop-ment projects and provide a single point of project control. One key element of such cockpits is the analysis, interpretation, and visualisation of measurement data in order to support various stakeholders for different purposes. Currently, many companies develop their own cockpits (typically simple dashboards) that are mainly based on Spreadsheet applications. Alternatively, they use dashboard solutions that provide a fixed set of predefined functions for project control that cannot be sufficiently customised to their own development environ-ment. Most of the more generic approaches for control centres offer only partial solutions and lack purpose-oriented and role-oriented data interpretation and visualisation based on a flexible set of control techniques that can be customised according to planned goals in a cost-efficient way. A systematic approach for defining reusable, customisable control compo-nents and instantiate them according to different organisational goals and characteristics is basically missing. This article gives an overview of the Specula project control framework and illustrates how to employ it for implementing project control mechanisms. The focus is on how to describe and combine control components in a generic way and how to select the right components based on explicitly defined project goals. Furthermore, related approaches are discussed and the use of Specula as part of industrial case studies is described.
Article
Full-text available
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag. At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its $193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of $1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open. To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all. Photo of Dallas International Baggage Handling System: SOFTWARE GLITCHES in an automated baggage-handling system force Denver International Airport to sit empty nine months after airplanes were to fill these gates and runways (top). The system that is supposed to shunt luggage in 4,000 independent "telecars" along 21 miles of track still opened, damaged and misrouted cargo as testing continued in July (bottom). The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as "the
Conference Paper
Full-text available
Software Cockpits, also known as Software Project Control Centers, support the management and controlling of software and system development projects and provide means for quantitative measurement-based project control. Currently, many companies are developing simple control dashboards that are mainly based on Spreadsheet applications. Alternatively, they use solutions providing a fixed set of project control functionality that cannot be sufficiently customized to their specific needs and goals. Specula is a systematic approach for defining reusable, customizable control components and instantiate them according to different organizational goals and characteristics based on the Quality Improvement Paradigm (QIP) and GQM. This article gives an overview of the Specula approach, including the basic conceptual model, goal-oriented measurement, and the composition of control components based on explicitly stated measurement goals. Related approaches are discussed and the use of Specula as part of industrial case studies is described.
Chapter
Reuse of products, processes, and experience originating from the system life cycle is seen today as a feasible solution to the problem of developing higher quality systems at a lower cost. In fact, quality improvement is very often achieved by repeatedly reusing and modifying the same elements, learning about them by direct experience.
Article
Developing and maintaining software systems involves a variety of highly interrelated activities. The discipline of software engineering studies processes of both product engineering and process engineering. Product engineering aims at developing software products of high quality at reasonable cost. Process engineering in contrast aims at choosing those product engineering processes appropriate for a given set of project goals and characteristics as well as improving the existing knowledge about those processes. Explicit models of both types of processes help a software development organization to gain competitive advantage. This paper motivates the need for explicit process models, surveys existing languages to model processes, discusses tools to support model usage, and proposes a research agenda for future software process research.
Conference Paper
One means for institutionalizing project control, systematic quality assurance, and management support on the basis of measurement and explicit models is the establishment of so-called Software Project Control Centers. Nowadays many companies develop their own dashboards for project control or use off-the-shelf tools that provide a predefined functionality. It is not clear how to tailor an existing tool to the specific needs and goals. An engineering-like approach providing the methodological foundation is needed for systematically defining and applying project control mechanisms. "Soft-Pit" is a research project focusing on an improvement-oriented approach for setting up and applying project control mechanisms in a goal-oriented way and evaluating the practical benefits of such a control center. This article describes the results of industrial case studies conducted in the context of the project. Moreover, lessons learned are discussed, related work is described, and future work is presented.