What Is an Application Value Assessment?
An application value assessment is a form of application assessment that measures, tests and evaluates the size, quality and complexity of application systems. The results give IT strategy decisions a solid footing. With legacy systems in particular, where the code base has grown large over the years and spans many languages, this produces hard data and makes the parts of the system comparable. That comparison can then be used to weigh different paths forward (maintenance, migration, refurbishment, etc.). To get there, though, you have to pick the right indicators and metrics from a very large pool of candidates.
Goals of a Measurement Project
A project to measure application systems typically pursues these goals:
- Determining the size, complexity and quality of a system’s code
- Building a metrics database for ongoing quality assurance
- Identifying and estimating alternative strategies for developing the system further
To meet the first goal, measuring the system, the application’s source code has to be structured and partitioned for measurement so that the results can be compared in a meaningful way. You can split it by language (COBOL, PL/I, C++, etc.), for example, or by specific business areas. The individual areas can then be compared in terms of size, quality and complexity, and anything that stands out can be examined more closely. Measurement isn’t limited to program code, either: databases and user interfaces can be measured too.
A metrics database makes it possible to keep measuring the system over time. That way, when the system is changed or extended, you can see whether overall quality has improved or declined, for example. Ideally, ongoing measurement is built into the quality assurance process.
The measurement results provide a common basis for evaluating different development scenarios and estimating their effort. This can serve as the foundation for the future IT strategy. Possible scenarios include:
- Annual maintenance of the system
- Rebuilding the system from scratch
- Migration
- Refurbishment
- Encapsulation
Choosing the Right Software Metrics
Every measurement project starts with choosing suitable metrics. This selection is also the first step in the measurement process of ISO 9126 (since replaced by the ISO/IEC 25000 series, with the quality model in ISO/IEC 25010). The literature, however, offers little guidance on which metrics to choose. Software systems are complex constructs with many different properties that can be measured. In his book “Software Complexity Metrics,” Horst Zuse identified more than 300 metrics on his own. Each indicator, or metric, measures a different property: the McCabe metric measures internal control flow complexity, the Halstead metric measures language complexity, and the function point metric measures the interactions between a system and its environment. In the end, which metrics fit best depends on the goal of the measurement project and the type of system.
Around 20 years of measurement projects with a wide variety of systems (as of 2009) have produced a set of size, complexity and quality metrics that have proven themselves many times over in analyzing and evaluating application systems. They include complexity metrics such as data complexity, control flow complexity and language complexity, as well as quality metrics for portability, maintainability, conformity and testability.
The Measurement Process
Measuring, testing and evaluating the system usually follows these steps:
- Select the metrics
- Structure the system to be measured
- Configure the tools and adapt them to local conditions (e.g., in-house language constructs)
- Run the measurement
- Load the measured values into a metrics database
- Evaluate the measurement results
- Carry out the estimates
Results
Besides the metrics reports on the size, quality and complexity of the system and its subsystems or components, and the effort estimates for the various development strategies, the information can be prepared for different audiences. That might take the form of scorecards that put quality and complexity in relation to each other, or management dashboards that give an up-to-date overview of the system.
Frequently Asked Questions
Why is measurement particularly valuable for legacy systems that have evolved over time?
Because with a large codebase and a wide variety of programming languages, any assessment would otherwise remain merely an opinion. Measurement, testing, and evaluating quantity, quality, and complexity provide data and enable comparability between different parts of the system. On this basis, further development scenarios such as maintenance, migration, or refurbishment can be evaluated against one another, rather than selected based on gut feeling.
How can measurement results from different parts of an application system even be compared?
Before measurement, the source code must be structured and prepared in such a way that meaningful comparability is achieved. It is categorized, for example, by languages such as COBOL, PL/I, or C++, or by functional areas. The areas are then compared based on size, quality, and complexity, and any anomalies are examined more closely. Not only program code but also databases and user interfaces can be measured.
What are the advantages of a metrics database over a one-time measurement?
It allows for ongoing measurement of the system over time. When changes or enhancements are made, it becomes clear whether overall quality has improved or deteriorated. The benefit is particularly evident when recurring measurements are firmly embedded in the quality assurance process rather than remaining a one-time snapshot.
Which development scenarios can be weighed against one another using measurement results?
Typically, the following are considered: annual system maintenance, a new development, a migration, a refurbishment, and encapsulation. The measurement results provide a uniform basis for evaluation and estimation for all these options. This makes it possible to compare the effort involved, and the decision can serve as the foundation for future IT strategy.
Is there a standard set of metrics for evaluating software?
No. Which metrics are appropriate depends on the objectives of the measurement project and the type of system. The literature offers little guidance on this: In his book “Software Complexity Metrics,” Horst Zuse identified more than 300 metrics alone. In 2009, this selection also formed the first step in the ISO 9126 measurement process.
What do McCabe, Halstead, and Function Points measure, respectively?
Each of these metrics focuses on a different characteristic. The McCabe metric captures internal control flow complexity, the Halstead metric captures language complexity, and the Function Point metric captures the interactions between a system and its environment. Anyone who measures only one of these metrics describes, accordingly, only a subset of the system.
What types of metrics should be included in an evaluation of application systems?
A combination of size, complexity, and quality metrics has proven effective. On the complexity side, these include data complexity, control flow complexity, and language complexity. On the quality side, metrics such as portability, maintainability, conformity, and testability are measured. This selection is based on measurement projects conducted over the approximately twenty years leading up to 2009.
How do you prepare measurement results for different target audiences?
In addition to metric reports on the size, quality, and complexity of the overall system and its components, as well as effort estimates, analyses tailored to specific target audiences are produced. Scorecards put quality and complexity into relative perspective. Management dashboards provide an up-to-date overview of the system’s status without requiring recipients to know the individual metrics in detail.
