Information Technology Reference
In-Depth Information
and then - as up to now - will be operated largely without any defined main-
tenance strategy, might be inadequate for such a gigantic European project.
A project eventually replacing all legacy, but well service proven signaling
and train protection systems with one single unified, but less service proven
technology, especially when independent verification and system validation
is only provided at rare occasions by a very limited number of experts . . . or
. . . then again after a “critical incident” has taken place only?
Instead, a broad and continues peer review scheme with full transparency
in all stages of the life cycle of ETCS on-board software products would be
highly recommended. In particular during the critical specification, verifica-
tion and validation phases, following the so called “Linus's Law”, according
to Eric S. Raymond, which states that:
“given enough eyeballs, all bugs are shallow.”
More formally:
“Given a large enough beta-tester and co-developer base, almost every problem
will be characterized quickly and the fix will be obvious to someone.”
The rule was formulated and named by Eric S. Raymond in his essay
“The Cathedral and the Bazaar” [17]. Presenting the code to multiple devel-
opers with the purpose of reaching consensus about its acceptance is a simple
form of the software reviewing process. Researchers and practitioners have
repeatedly shown the effectiveness of the reviewing process in finding bugs
and security issues [18].
2.6
Changing Business Model for Software: From Sales to
Service
Such problems can be solved by changing the business model. Looking at
software as a “service” rather than a “commodity” or “product” (in its tradi-
tional definition) is justified by the fact that software is growing continuously
in size (but not necessarily increasing the value to the user) as shown in figure
4. Over a life-cycle of 17 releases, the total size of that software grew by more
than 300%. Furthermore, about 40% of the modules of the first release had
to be fixed or rewritten, due to one or more bugs per module. That means
only 60% of the original modules were reusable for second or later releases. It
is fair to assume that half of the original 60% virtually bug free code had to
be adapted or otherwise modified to use it for functional enhancements. This
results in not more than 30% of remaining code, which is about 50 TLOC of
the original code having a chance to survive unchanged up to release No. 17.
Biggerstaff [19] and Rix [20] suggest that these assumptions might even
be too optimistic, as long as no specific measures have been taken in order to
support reusability of code. It can be assumed that a potential sales price of
all versions would be at the same level, since all versions serve in principle the
same functions. That means during its life cycle only 10% ( 50 TLOC out of
about 500 TLOC) of the final code was left unchanged from the first version
in this particular example. In other words: 90% of the work (code lines) has
been added by software maintenance and continuous further development
