system, information about those persons, including their training, certification, and licensing records, as well
as attributes such as their nationality
or level of security clearance.
It might not be known, in advance,
what kinds of compliance documentation will be needed later in the product
life cycle. Thus it is important to have
a flexible query interface that supports
the creation of compliance reports
from all cross-linked data sources.
Prevailing software management tools
focus on the tracking of software artifacts, but comprehensive information
about people and associated compliance items is largely missing.
Traceability of a Defect
In quality-critical manufacturing—
for example, pharmaceuticals or food
products—it is possible to trace each
quality issue to determine which
people, machines, ingredients, and
processes were involved and who else
could be affected by the same issue.
This same capability would be desirable for critical software products (see
Figure 3), which means for every artifact involved in a defect, it must be
possible to determine all persons and
tools (such as compilers) that were
involved in the development. In addition, one should be able to identify all
other development artifacts that were
created by the same tools and/or persons to check whether similar defects
exist there as well.
Furthermore, it would be desirable
to have a link between the software configuration management system and the
license management database recording each deployment of the software,
so that all customers/users of a certain
problematic version or configurations
can be informed about the problem
and possible fixes, if necessary.
Managing Technical Debt
For any long-living and complex sys-
tem, it is important to keep track of
the health of the underlying subsys-
tems and components. This is true
for manufacturing plants as well as
for software systems. While software,
unlike physical assets, does not objec-
tively deteriorate over time, it “ages”
through increasing divergence of
expected and actual levels of qual-
ity. The phenomenon of software
maintainability degrading over time,
primarily due to short-term-focused
bug-fixing and feature-adding activi-
ties, has been described as a type of
“Shall we spend time refactoring
or just keep adding new features?”
is a recurring dilemma for software
managers. Dealing with this problem strategically requires optimal investment decisions for use of limited
software maintenance budgets. To
support such decisions, we first need
to identify and quantify the trouble
spots—areas of technical debt—by
calculating effort, process metrics,
and structural complexity metrics
from a project repository. For example, we could monitor per file the
average time needed to fix a bug or
make a change, how coupled it is to
other files, and whether it is historically implicated in many high-severity
7 Similar to the previous scenarios, we can extract such information
from the production process of a software MES, concretely, the source code
repository, version control, and issue
But just identifying potential trou-
ble spots is not enough. To make op-
timal decisions quickly, management
has to balance multiple factors, addi-
tionally taking into account the future
quality of the product, impending
requirements and associated dead-
lines, the available skills of develop-
ers, and the costs of development,
maintenance, and operations, which
involves multiple areas of a software
MES. In the end, virtually every deci-
sion in a software project is an eco-
nomic decision, and such decisions
should be made based on a compre-
hensive software MES.
While the recording of the information underlying the scenarios described in this Viewpoint may not
be standard practice in all software
companies today, most of it is actually available. The challenge is to
integrate information from heterogeneous data produced by incompatible tools, and realize traceability
throughout the development process.
Currently, correlating all the necessary information is expensive and
awkward, but not impossible. We have
already begun to realize one of these
scenarios in a research decision-support system that aids in identifying and
measuring modularity debt3 to support refactoring decisions. Microsoft
launched a similar information integration project called CODEMINE.
Clearly, much more work is required to make this entire vision a
reality. This is a call to action for the
1. Bajric, A., Mertins, A.K., Rabe, M., and Jaekel, F. A
success story: Manufacturing execution system
implementation. In Enterprise Interoperability IV
(Springer 2010), 357–366.
2. Brown, N., Cai, Y., Guo, Y., Kazman, R. et al. Managing
Technical Debt in Software-Reliant Systems. In
Proceedings of the FSE/SDP Workshop on the Future
of Software Engineering Research at ACM SIGSOF T
FSE- 18, (Santa Fe, NM, Nov. 2010).
3. Cai, Y., Kazman, R., Silva, C.A., Xiao, L., Chen, H-M.
A decision-support system approach to economics-driven modularity evaluation. In Economics-Driven
Software Architecture, Elsevier, 2013.
4. Czer wonka, J., Nagappan, N., Schulte, W., and Murphy,
B. CODEMINE: Building a software development data
analytics platform at Microsoft. IEEE Software 30, 4
(July–Aug. 2013), 64–71.
5. Manufacturing Execution System (MES) Market—
Global Forecast and Analysis (2011–2016) (Feb. 2012);
6. MESA White Paper 6. MES Explained: A High Level
Vision, 1997; MESA Organisation; http://www.mesa.
7. Schwanke, R., Xiao, L., and Cai, Y. Measuring
architecture quality by structure plus history analysis.
In Proceedings of the 34th International Conference
on Software Engineering, May 2013.
Martin Naedele ( email@example.com) is a
member of the Information Technology Department at
ABB Corporate Research in Baden, Switzerland.
Rick Kazman ( firstname.lastname@example.org) is a professor of
information technology management in the Department of
Information Technology Management at the University of
Hawaii in Honolulu.
Yuanfang Cai ( email@example.com) is an associate
professor of computer science in the Department of
Computer Science at Drexel University in Philadelphia, PA.
Copyright held by authors.