Content uploaded by Marco Kuhrmann
Author content
All content in this area was uploaded by Marco Kuhrmann on Mar 08, 2014
Content may be subject to copyright.
Software durchdringt heute viele Lebens-
bereiche und ist an immer mehr geschäft-
lichen und privaten Wertschöpfungsketten
wesentlich beteiligt. Insbesondere für das
Hochtechnologie-Land Deutschland ist
Software eine kritische Komponente der
Wirtschaft. Die Frage, wie professionell
und qualitativ hochwertig Software ent-
wickelt wird und wie sich Deutschland im
Wettbewerb positioniert, ist dagegen noch
nicht hinreichend beantwortet.
Hierzu hat Deutschlands größter ITK-Ver-
band, der BITKOM e. V., zusammen mit
der Technischen Universität München, der
SQS Software Quality Systems AG und der
Gesellschaft für Informatik (GI) e.V. eine
Befragung unter Projekt- und Prozessver-
antwortlichen der deutschen Softwarein-
dustrie durchgeführt, die durch Vorgabe
von Entwicklungs-, Test- und Projektma-
nagement-Prozessen den Rahmen der Soft-
wareentwicklung festlegen. Die Umfrage
verfolgte das Ziel, Einblicke in den Grad
der Professionalität der Softwareentwick-
lung in Deutschland zu erhalten und ins-
besondere der Frage nachzugehen, ob
Unternehmen die plan- und steuerbare
Entwicklung qualitativ hochwertiger Soft-
waresysteme entlang gegebener Kosten-
und Terminvorgaben systematisch durch-
führen, oder ob die Projektdurchführung
doch eher auf die subjektive Erfahrung der
Entwicklungsteams angewiesen ist, die das
„schon irgendwie” hinkriegen.
Softwareentwicklung wird global
Vor dem Hintergrund von Kosten- und
Zeitdruck wird gerade im Bereich der
Softwareentwicklung zunehmend auf das
Konzept des Global Delivery (auch Global
Software Development, GSD) gesetzt, d.h.
der globalen Nutzung geeigneter Ressour-
cen, insbesondere für die Codierung und
das Testen. Arbeitsintensive Tätigkeiten in
Softwareprojekten sollen hierbei in Län-
der mit geringeren Lohnkosten transferiert
werden (Outsourcing, Off-Shoring etc.).
Damit steht automatisch jeder in Deutsch-
land bezahlte Softwareentwickler in di-
rekter Konkurrenz zu seinen zahlenmäßig
überlegenen und meist auch (vermeintlich)
sehr viel günstigeren Kollegen in Indien
oder Bangladesch.
Software „Made in Germany“
In diesem Artikel wollen wir der Frage
nachgehen, inwieweit der durch Prozess-
und Projektverantwortliche aufgespannte
Rahmen erfolgreiche Softwareprojekte in
Deutschland unterstützt. Uns treibt hier-
bei die Frage, ob einem deutschen Soft-
wareprojekt die positive Attitüde „Made in
Germany“ mit Recht zugesprochen werden
kann.
Ist dies der Fall, ist Software „Made in
Germany“ ein Qualitätsattribut und ein
deutliches Votum für den Softwareentwick-
lungsstandort Deutschland. Auch wenn
dieser Artikel nur Einblicke in die hiesige
Softwareindustrie erlaubt, könnte eine auf-
gezeigte hohe Professionalität geeignet sein,
andere Nachteile – wie etwa Kostenstruk-
turen oder die Anzahl der Urlaubstage – zu
kompensieren. Sollte der umgekehrte Fall
zutreffen, müssten andere Aspekte als die
qualitative Bewertung für die Entscheidung
des Standortes Deutschland positiv evalu-
iert werden.
Industrialisierung
Der Begriff „Made in Germany“ ist heute
für Software eng verwoben mit dem Begriff
der Industrialisierung der Softwareent-
wicklung (vgl. [Bit10]). Der BITKOM hat
dazu einen eigenen Leitfaden mit dem Na-
men „Agiles Software Engineering Made
in Germany“ erstellt, in dem – aufbauend
auf einer Analyse der deutschen Stärken im
industriellen Umfeld – die Übertragung die-
ser Konzepte auf die Softwareentwicklung
diskutiert wird (vgl. [Bit13]). Dem Axiom,
dass Professionalisierung der Softwareent-
wicklung entlang des Pfades der Industri-
alisierung geschieht, folgt auch dieser Arti-
kel: Demnach gilt zu überprüfen, inwieweit
heute die Softwarebranche mindestens die
folgenden Schritte der industriellen Ferti-
gung bereits anwendet:
Modularisierung
Die Größe heutiger Softwareprojekte ver-
langt einen hohen Grad an Dekompositi-
on. Henry Ford hat mit dem Taylorismus
dieses Konzept für die Automobilbranche
als erster konsequent umgesetzt. Für die
IT bedeutet dieser Schritt unter anderem
die Verfeinerung in Teilprojekte, die Festle-
gung bestimmter Arbeitspakete, das Erken-
nen benötigter Mitarbeiterprofile und die
Festlegung bestimmter Rollen und Verant-
wortlichkeiten. Modularisierte Softwareent-
wicklung bedeutet also die Fähigkeit, Soft-
wareprojekte in definierte Teile zu zerlegen,
jedes einzeln voranzutreiben und sicherzu-
stellen, dass am Ende immer noch ein gro-
ßes und funktionierendes Ganzes entsteht.
Standardisierung
Je stärker der prozessuale Rahmen normativ
in die einzelnen Projekte wirkt, desto ähnli-
cher und damit vergleichbarer sind die Pro-
jekte. Dies sollte dann einen effizienten Mit-
arbeiteraustausch zwischen Teams erlauben,
das einfachere Einbinden neuer Mitarbeiter
oder auch nur die einfachere Durchsetzung
und Bewertung von unternehmensweiten
Praktiken. Dies bedeutet, Standards zu nut-
zen, um Gemeinsamkeiten in der arbeits-
teiligen Softwareentwicklung zu identifizie-
ren und die Integrierbarkeit der Ergebnisse
sicherzustellen. Oder mit den Worten von
Volker Smit, Geschäftsführer von HP in
Wunsch oder Wirklichkeit?
Professionelle Softwareentwicklung
„Made in Germany“
Natürlich ist eine in Deutschland entwickelte Software in ihrer Erstellung teurer als eine aus Indien. Aber was
rechtfertigt eigentlich diesen Preisunterschied? Haben wir es tatsächlich bereits geschafft, von anderen Erfolgs-
branchen wie der Automobilbranche zu lernen und unsere Softwareentwicklung marktführend zu professionali-
sieren? Dieser Artikel versucht, auf Basis der Analyse einer Branchenbefragung Einblicke in den aktuellen Status
quo zu geben. Gleichermaßen warnt er damit aber auch vor einer überzogenen Selbsteinschätzung.
Wunsch oder Wirklichkeit? Professionelle Softwareentwicklung „Made in Germany“
16
Deutschland (vgl. [Smi13]): „Was aber sind
die Voraussetzungen für einen zukunfts- und
innovationsorientierten Einsatz von ITK?
Auf diese Frage kann es nur eine Antwort
geben: Wir müssen dringend von Insellösun-
gen abrücken und Standards vorantreiben.“
Wiederverwendung und Automatisierung
Gemeinsamkeiten zwischen Projekten, Mo-
dulen oder Aktivitäten müssen erkannt und
für die Wiederverwendung vorbereitet wer-
den. Damit wird die Grundlage geschaffen,
anschließend Teile der Softwareentwick-
lung zu automatisieren. Wiederverwen-
dung bedarf als Vorbedingung der Mo-
dularisierung und Standardisierung, da es
ansonsten weder mögliche Module für eine
Wiederverwendung, noch entsprechende
Standardisierungen gibt, auf der eine Wie-
derverwendung aufbauen kann.
Die Umfrage
Um der Kernfrage „Wie professionell ist ak-
tuell die Softwareentwicklung in Deutsch-
land?“ entlang des formulierten Axioms
nachzugehen, haben vier aus dem Software-
und Testumfeld kommende Organisationen
eine Umfrage durchgeführt. Der BITKOM
(besonders der Arbeitskreis Software-En-
gineering), die Gesellschaft für Informatik
(GI) e.V. (besonders die Fachgruppe Vor-
gehensmodelle), die SQS Software Quality
Systems AG und die Technische Universität
München haben im Zeitraum Oktober bis
Dezember 2012 den so genannten „3Proc-
Survey“ durchgeführt, in dem die folgen-
den drei thematischen Schwerpunkte abge-
fragt wurden:
n
Projektmanagementprozesse, innerhalb
derer Projekte ablaufen.
n
Entwicklungsprozesse, innerhalb derer
neue oder geänderte IT-Systeme erstellt
werden.
n
Testprozesse, innerhalb derer die Qua-
lität der Projektergebnisse fortwährend
sichergestellt wird.
Die Untersuchung wurde als Online-Um-
frage gestaltet, die neben einigen Metada-
ten knapp 30 Fragen zu den oben genann-
ten Themenschwerpunkten enthielt. Jeder
Themenschwerpunkt wurde bezüglich der
Erwartungen und des Status quo abgefragt.
Die Auswertung der einzelnen Fragen be-
ruht dabei immer auf der tatsächlichen An-
zahl der Antworten, wobei im Folgenden
die Verteilung jeweils auf volle Prozentzah-
len gerundet angegeben wird. Aufgrund der
nicht gleichbleibenden und vergleichsweise
geringen Teilnehmerzahl (n lag pro Frage
zwischen 97 und 38 Teilnehmern) wurde
die Auswertung der Ergebnisse nur auf ei-
ner qualitativen Ebene durchgeführt.
Modularität in der
Softwareentwicklung
Eine professionelle Softwareentwicklung
kennzeichnet sich insbesondere dadurch
aus, dass die Softwareentwicklung nicht
mehr monolithisch als „One-Man-Show“
verstanden wird, sondern modularisiert
durch Teams erfolgt, die gegebenenfalls
über mehrere Standorte verteilt zusammen-
arbeiten. In einer verteilten Softwareent-
01/2014 17
www.objektspektrum.de
Abb. 1: Gründe für den Einsatz von Entwicklungsprozessen.
Abb. 2: Gründe für den Einsatz von Testprozessen.
wicklung kommt somit der Organisation
und Allokation von Arbeitspaketen eine
besondere Bedeutung zu.
In diesem Zusammenhang wurden die
Probanden befragt, ob und nach welchem
Muster Mitarbeiter bzw. Teams ihres Un-
ternehmens über mehrere Standorte ver-
teilt arbeiten. Lediglich 14 % der Befragten
gaben an, Projekte nicht verteilt durchzu-
führen. 41 % der Befragten gaben an, die
Softwareentwicklung zwar verteilt durchzu-
führen, jedoch größtenteils nur mit Teams in
Deutschland. Damit dominiert in Deutsch-
land heute immer noch eher eine Modula-
risierung auf Personalebene (in Form von
modularen Personalgruppen) als auf Aufga-
benebene. Ein „wir setzen uns schnell mal
zusammen“-Modus scheint noch wichtig
zu sein und ist kein Indikator für eine echte
Modularisierung. Nur 35% der Befragten
binden in Deutschland und vereinzelt in an-
deren Ländern verteilte Mitarbeiter/Teams
ein und nur 10 % gaben an, den überwie-
genden Teil der Arbeiten ins Ausland zu
transferieren. Wird angenommen, dass eine
reife Modularisierung mit dem Ergebnis ein-
fach handhabbarer Teilpakete dazu führt,
dass der Standort der Leistungserbringung
irrelevant ist, zeugen nur diese 10% eindeu-
tig von einer entsprechend großen Reife, da
es in den anderen Fällen eher um verteilte
Arbeitsgruppen geht. Dem folgend läge die
minimale Wertschöpfungstiefe in der deut-
schen IT-Industrie bei 90%; die deutlich
modularisierte deutsche Automobilbranche
liegt hier bei ca. 15% (vgl. [Ott08]).
Organisatorisch erfolgt Modularisierung
vor allem durch die Prozesse. Allerdings
scheint auch diese Sicht noch nicht eta-
bliert: Weniger als 50% der Befragten se-
hen im Entwicklungsprozess ein passendes
Instrument zur Unterstützung der verteilten
Arbeit (siehe Abbildung 1), etwa 10% wi-
dersprechen dem sogar strikt. Im Bereich
der Testprozesse ist das Ergebnis noch er-
nüchternder: Nur 42% der Befragten be-
scheinigen dem Testprozess eine Eignung,
verteiltes Arbeiten zu unterstützen (siehe
Abbildung 2). Circa 15% widersprechen
dem sogar strikt. Modularisierung scheitert
also heute an vielen Stellen immer noch an
so rudimentären Grundlagen wie Prozessen.
Auf der technischen Ebene können Werk-
zeuge bei der Modularisierung in Form der
Verteilung, aber auch bei der Erstellung ei-
ner integrierten Sicht helfen. Die Befragten
favorisieren hier eine Plattform, die die In-
tegration unterschiedlicher Einzelwerkzeu-
ge ermöglicht (für den Entwicklungspro-
zess 44% (siehe Abbildung 3) und 43% für
den Testprozess (siehe Abbildung 4). Nur
26% bzw. 27% erwarten eine Integration
aller Ergebnisse in ein Standardwerkzeug.
Das kann als ein Indikator für Modulari-
sierung interpretiert werden, da Teams je-
weils ihre eigenen Werkzeuge einsetzen und
diese dann projektspezifisch integrieren
und Ergebnisse austauschen wollen. Somit
entstehen dann wiederum Anforderungen
an die Standardisierung (siehe nächster Ab-
schnitt), etwa um verlustfrei Daten auszu-
tauschen.
Von dieser Perspektive aus kann der Soft-
wareentwicklung in Deutschland eine
gewisse Industrialisierungsreife attestiert
werden, jedoch nur in einem engen lokalen
Rahmen. Die (global) verteilte Softwareent-
wicklung ist nur teilweise Realität – für die
Befragten scheint heute immer noch die
räumliche Nähe das bevorzugte Szena-
rio für Projekte zu sein. Im Vergleich zum
fertigenden Gewerbe, in dem die Kompo-
nentenfertigung beispielsweise weitgehend
ausgelagert ist (Stichwort: Fertigungstiefe),
18
Wunsch oder Wirklichkeit? Professionelle Softwareentwicklung „Made in Germany“
Abb. 3: Erwartungshaltung an die Werkzeugunterstützung für den Entwicklungs-
prozess.
Abb. 4: Erwartungshaltung an die Werkzeugunterstützung für den Testprozess.
bleibt die deutsche Softwareentwicklung in
diesem Aspekt zurück.
Standardisierung in der
Softwareentwicklung
Neben der Modularisierung ist die Standar-
disierung der zweite wesentliche Schritt in
Richtung Industrialisierung (vgl. [Bit10]).
Im Projekt erarbeitete Ergebnisse sollten
demnach so erstellt werden, dass sie zwi-
schen unterschiedlichen Rollen (oder gar
unterschiedlichen Vertragsparteien) ein-
fach ausgetauscht und bewertet werden
können, um damit auch die Grundlage für
den Vergleich der Projekte und somit für
einen systematischen Verbesserungsansatz
zu legen. Die Standardisierung bietet so-
mit die Chance, die Softwareentwicklung
derart zu gestalten, dass die Einarbeitung
neuer Mitarbeiter vereinfacht wird, „Kopf-
monopole“ entfernt werden, die Plan- und
Steuerbarkeit einheitlich möglich und ein
Benchmarking projektübergreifend um-
setzbar ist.
Die Ergebnisse der Umfrage zeigen aller-
dings, dass Standardisierung noch keine
weite Verbreitung im Bereich des Software-
Engineerings gefunden hat. Wie bereits zu-
vor für die Analyse der Modularisierung
aufgeführt, haben für Werkzeuge 44% der
Befragten die Erwartungshaltung, nur eine
Integrationsplattform haben zu wollen, um
die Vielzahl an existierenden, heterogenen
und damit nicht-standardisierten Werkzeu-
gen im Entwicklungs- und Testbereich zu
integrieren. Dies kann als Bestandsschutz
einer nicht-standardisierten Werkzeugum-
gebung gedeutet werden. Nur knapp ein
Viertel der Befragten wünscht sich hinge-
gen ein standardisiertes Werkzeug zur voll-
ständigen und nahtlosen Integration der
Arbeitsergebnisse und Prozesse. Bei Werk-
zeugen ist die Standardisierung daher nicht
nur noch nicht realisiert, sondern offen-
sichtlich sogar gar nicht gewünscht (siehe
Abbildung 3 und Abbildung 4).
01/2014 19
www.objektspektrum.de
Abb. 5: Haben Sie einen unternehmens-
weiten Standard für den Entwicklungs-
prozess?
Abb. 6: Wie erfolgt das Tailoring?
Ein wenig positiver zeigt sich die Erwar-
tungshaltung der Befragten an den Einsatz
von standardisierten Prozessen: Die Mehr-
heit der Befragten erwartet hierdurch eine
Verbesserung der Effizienz (72%) und Ef-
fektivität (65%), eine bessere Planbarkeit
(72%), eine systematische Fortschrittskon-
trolle (75%) sowie die effiziente Integration
unterschiedlicher Teildisziplinen in verteil-
ten Projekten (77 %) (siehe Abbildung 1).
Während hier Standardisierung als Erwar-
tung deutlich zu erkennen ist, zeigt der Sta-
tus quo eine andere Realität. So arbeiten nur
44% der Befragten überhaupt nach einem
standardisierten Entwicklungsprozess, 56%
tun dies nicht (siehe Abbildung 5). Und
selbst diese Standardisierung ist eher lokal
als global: Die Anpassung eines gegebenen-
falls vorhandenen Standards an die indivi-
duellen Projektcharakteristika verläuft näm-
lich meist nicht systematisch: Knapp 55 %
der Befragten gaben an, dass das Tailoring
zu Projektbeginn durch den Projektleiter in-
dividuell und ohne „Leitplanken“ durchge-
führt wird, während nur knapp 32% ange-
ben, dass dies nach klar definierten Regeln
verläuft (siehe Abbildung 6). Gleiches gilt
für die Standardisierung von Testprozessen,
die bei knapp 57 % der Befragten jeweils
proprietär und projektspezifisch und damit
nicht standardisiert definiert sind (siehe Ab-
bildung 7).
Eine Standardisierung dieser Methoden ist
damit de-facto nicht existent – vielmehr
werden sie jeweils separat für individuelle
Geltungsbereiche aufgesetzt: So können
Fürstentümer ohne eine gemeinsame Stra-
tegie entstehen, die ungesteuert und unkon-
trolliert ihr Reich regieren.
Aber selbst innerhalb dieser Fürstentümer
wird der initial aufgesetzte Kleinstandard
nicht konsequent gelebt: Die Einhaltung
von Entwicklungsprozessen wird noch
nicht flächendeckend geprüft: Die am häu-
figsten eingesetzten Verfahren sind Check-
listen und Templates (53%) sowie Produk-
tevaluierungen an Meilensteinen (50%)
(siehe Abbildung 8). Es passt ins Bild, dass
die Möglichkeit, an diesen Produktevaluie-
rungen unternehmensweite Standards als
Kriterien einzusetzen, nur bedingt genutzt
wird: Nur 53% verwenden standardisierte
Vorgaben des Unternehmens; die meisten
Kriterien sind projektspezifisch und nicht-
standardisiert durch den Auftraggeber vor-
gegeben (74%, siehe Abbildung 9).
Projektmanagement mit seiner normativen
Kraft für Standardisierung wird mit einer
Zustimmung von 76%, die Entwicklungs-
und Testprozesse werden mit einer Zustim-
mung von je 44% als für den Projekterfolg
äußerst relevante Disziplinen betrachtet.
Diese hohen Erwartungswerte scheinen al-
lerdings eher Wunsch zu sein als Realität:
Denn genau dieselben Disziplinen liefern
mit einer Zustimmung von 40 % immer
noch das größte ungenutzte Verbesserungs-
potenzial. Standardisierung scheint also ge-
wünscht, aber noch nicht umgesetzt.
Ein weiterer Vorteil von Standardisierung
ist die dadurch gegebene Möglichkeit,
lungsprozessen noch keine weite Verbrei-
tung gefunden hat.
Ein Grund hierfür könnte die Angst vor der
Möglichkeit von Benchmarks sein. So zeigt
auch die „Vergleichbarkeit von Projekten“
bei den Befragten die größte Ablehnung
(41%, siehe Abbildung 1). Auch Reife-
gradmodelle wie CMMI oder ISO 15504,
die Vergleichbarkeit erzeugen, werden nur
sehr zurückhaltend angenommen (knapp
30 % geben an, dass ihr Unternehmen au-
genscheinlich „anders“ ist und daher die
Modelle nicht passen). Hier sind andere
Disziplinen, wie z.B. die deutsche Auto-
mobilbranche, deutlich weiter (vgl. z. B.
[Bre07]).
Wiederverwendung in der
Softwareentwicklung
Für eine professionelle Softwareentwick-
lung bedarf es nicht nur der Modularisie-
rung und der Standardisierung, selbst wenn
diese für sich genommen bereits positive
Auswirkungen haben. Die darauf aufbau-
ende Hoffnung, Wiederverwendung vor-
antreiben zu können, scheint damit schon
erschwert, da es offensichtlich ist, dass nur
etwas wiederverwendet werden kann, das
als „etwas“ identifiziert wurde (vgl. Modu-
larisierung) und das dann auch standardi-
siert wurde (vgl. Standardisierung).
Die Ergebnisse der Umfrage zeigen daher
hier auch klare Defizite auf. So hat bereits
die Analyse im Bereich der Standardisie-
rung offengelegt, dass ein großer Teil der
Projekte heute immer noch seine eigenen
Prozesse entwickelt, seine eigenen Werk-
zeuge einsetzt und seine eigenen Erfolgs-
dimensionen definiert. Demzufolge findet
auch auf einer über den Projekten liegen-
den Programm- oder Portfolio-Ebene keine
Wiederverwendung statt. So gibt es z.B.
nur in 32 % der Unternehmen „feste Regeln
für die verschiedenen Projekttypen, nach
denen das Tailoring der Entwicklungspro-
zesse durchgeführt wird“ (siehe Abbildung
6). Ohne solche Vorgaben genießt jedes
Projekt folglich maximale Freiheit. Eine
Wiederverwendung in Form von Regeln
und Best Practices kann so allerdings kaum
erfolgen. Die fehlende Wiederverwendung
auf der Ebene von projektübergreifenden
Vorgaben führt dann zu unterschiedlichen,
projektspezifischen Entwicklungsprozes-
sen (siehe oben). An vielen Stellen scheint
Wiederverwendung auch überhaupt nicht
gewünscht: 40 % der Befragten führen als
Gegenargument zur Wiederverwendung die
reduzierte Möglichkeit der individuellen
Anpassung als Grund an (siehe Abbildung
20
Wunsch oder Wirklichkeit? Professionelle Softwareentwicklung „Made in Germany“
Schnittstellen zu definieren und eben stan-
dardisiert und systematisch zu bedienen. So
hat der Entwicklungsprozess heute in den
meisten Fällen bereits Schnittstellen zum
Test- und Qualitätsmanagement (66 %, sie-
he Abbildung 10), zu anderen Disziplinen
existieren allerdings nur punktuelle Integ-
rationen. 16% geben sogar explizit an, den
Entwicklungsprozess mit keiner anderen
Disziplin zu verbinden! Das kann als Re-
sultat fehlender und teilweise auch unge-
wünschter Standardisierung gedeutet wer-
den. Unterstützt wird diese Deutung durch
die Befragung nach dem größten Nachteil
einer Standardisierung: 41 % der Befragten
geben hier einen erhöhten Verwaltungs-
aufwand an (siehe (Abbildung 11). Daher
stellen Methoden wie Scrum (27 %) oder
Kanban (10 %) mit weniger ausgeprägten
Schnittstellen als umfassende Vorgehens-
modelle (etwa das V-Modell XT, 6 %) die
bevorzugte Auswahl dar. Es wird scheinbar
die Methode gewählt, die dem bisherigen
Modus Operandi am nächsten kommt. Al-
lerdings ist es ein Irrschluss zu glauben, agi-
le Methoden würden keinen Verwaltungs-
aufwand nach sich ziehen (vgl. [Gre12]).
Insgesamt fällt entlang des Punktes Stan-
dardisierung hier ebenfalls auf, dass es
unter den 13 zur Auswahl stehenden Vor-
gehensmodellen keinen klaren Sieger gibt.
13% der Befragten geben sogar an, weite-
re andere Vorgehensmodelle im Einsatz zu
haben. Dies untermauert die anfängliche
Vermutung, dass Standardisierung in so
grundlegenden Bereichen wie den Entwick-
Abb. 7: Haben Sie einen unternehmens-
weiten Standard für den Testprozess?
Abb. 8: Wie wird die Einhaltung des Entwicklungsprozesses kontrolliert?
11). Dass diese eingeschränkte Freiheit ein
großer Vorteil sein kann, wird demnach
häufig nicht gesehen.
Die mit der Wiederverwendung mögliche
Vergleichbarkeit wird ebenfalls häufig arg-
wöhnisch bis negativ betrachtet. So domi-
nieren beispielsweise Befürchtungen, durch
den Einsatz von Entwicklungsprozessen
vergleichbar zu sein: 65 % der Befragten se-
hen hier deutliche Nachteile. Genauso we-
nig überzeugend wirkt die Idee, Programme
als „Quelle wiederverwendbarer Assets“
aufzusetzen. Nur 35% unterstützen diese
Idee durch den Einsatz von Entwicklungs-
prozessen (siehe Abbildung 1): Es lebe das
einzelne, isolierte Projekt.
Auch für Werkzeuge wird Wiederverwen-
dung kritisch betrachtet. Standardwerkzeu-
ge für die Entwicklung werden mit 26%
(siehe Abbildung 3) ebenso wenig begrüßt,
wie mit 27 % für Testwerkzeuge (siehe Ab-
bildung 4). Auch die Erfolgskontrolle ein-
zelner Projekte, um daraus gegebenenfalls
wiederverwendbare Verbesserungsmaß-
01/2014 21
www.objektspektrum.de
nahmen abzuleiten, scheint noch nicht weit
vorangeschritten zu sein: So gibt es nur in
17% der Unternehmen eine außerhalb des
Projekts liegende Stelle, die Wiederver-
wendung von Best Practices (und eventuell
sogar Automatisierung) erkennen und pro-
jektübergreifend ausrollen könnte.
In Summe scheint das Potenzial der Wie-
derverwendung auf prozessualer Ebene
weder vollständig genutzt noch vollständig
gewünscht. Das wichtigste Artefakt ist hier
nach wie vor das einzelne Projekt, das sich
relativ autark bewegen und arbeiten darf.
„Kleber“ zwischen einzelnen Projekten und
über einzelnen Projekten liegende Assets,
die einfach wiederverwendet werden kön-
nen, sind noch Mangelware.
Diese Trennung kann mit den Begriffen
Controlling und Governance dargestellt
werden: Das Controlling einzelner Projek-
te wird heute in vielen Projekten intensiv
gemacht (z. B. erheben 40% der Befragten
Testkennzahlen pro Projekt manuell). Eine
projektübergreifende Governance steckt al-
lerdings meist noch in den Kinderschuhen.
Professionalität der
Softwareentwicklung
Die Professionalität der Softwareentwick-
lung „Made in Germany“ wirft die Frage
auf, ob die Form der heutigen Arbeit tat-
sächlich Alleinstellungsmerkmale aufzeigt,
die den Hochlohn-Standort Deutschland
nachhaltig sichern. In jedem Fall unterfüt-
tern die vorliegenden Ergebnisse, dass die
Industrialisierung in der deutschen Soft-
wareentwicklung der Industrialisierung im
Automobilbereich tatsächlich über zehn
Jahre hinterher hinkt (vgl. auch [Bre07]).
Dort werden mit Wertschöpfungstiefen
im eigenen Unternehmen von nur knapp
15% qualitativ hochwertige Produkte un-
ter Zuhilfenahme eines engmaschigen und
redundanten Zulieferernetzes erstellt (vgl.
z.B. [Ott08]). Dort existiert ein klares Ver-
ständnis, mit welchen Prozessen überhaupt
Automobile professionell entwickelt wer-
den können und welche Prozesse davon
die eigentlich wertstiftenden sind und da-
her im eigenen Haus bleiben sollten (Mo-
dularisierung). Und es existieren nicht nur
projektübergreifende, sondern sogar fir-
menübergreifende, wiederverwendete Stan-
dardisierungen (z. B. der MISRA-Standard,
vgl. [Hol13], oder AutomotiveSPICE, vgl.
[Höh09]). Auch Wiederverwendung findet
mittlerweile konzernübergreifend erfolg-
reich statt, beispielsweise die Plattform-
Wiederverwendung.
Abb. 9: Nach welchen Kriterien bestimmen Sie die Qualität?
Abb. 10: Welche Schnittstelle hat der Entwicklungsprozess zu anderen Prozessen/
Disziplinen?
Viele Bestrebungen im Softwarebereich,
über das eigene Projekt hinaus Standardi-
sierung und Wiederverwendung voranzu-
treiben, werden unter dem Vorwand der
Nicht-Angemessenheit, des unflexiblen
Vorgehens und des Risikos des dann „ver-
gleichbar Seins“ scheinbar abgelehnt. Zu-
sammen mit dem vielleicht IT-spezifischen
„not-invented-here“-Syndrom zeigen die
Ergebnisse dieser Umfrage daher ein Bild,
in dem viele deutsche Entwicklungsprojek-
te ihr eigenes Fürstentum darstellen, und
jeder Versuch der von außen motivierten
Einflussnahme als kriegerischer Akt aufge-
fasst wird. Ob dies eine begründete Ableh-
nung darstellt, derzufolge Standardisierung
im IT-Bereich auf zu viele effektive Proble-
me stößt, oder eben doch eher emotional
Industrierevolution 4.0 Organisationen
und Prozesse verändert“ (vgl. [Sch12]). Die
Idee, dass die IT und das Internet – und
damit die in diesem Bericht dargestellte
Reife – in den Fabriken auf die dortigen
Maschinen treffen, kann aus diesem Blick-
winkel als risikobehaftet bewertet werden.
In jedem Fall dürfte der Erfolg der Idee, das
Attribut „Made in Germany“ auf die IT zu
übertragen, maßgeblich den Industriebran-
chen zu verdanken sein.
Der Zug scheint allerdings noch nicht ab-
gefahren zu sein, da bis heute noch keine
andere Nation den heiligen Gral der indus-
trialisierten Softwareentwicklung gefunden
hat. Wenn wir das Paradigma des Enginee-
rings und damit die Industrialisierung auf
die IT übertragen wollen, Softwareentwick-
22
Wunsch oder Wirklichkeit? Professionelle Softwareentwicklung „Made in Germany“
ist, kann jeder selbst für sich beurteilen. In
jedem Fall führt diese Projektlastigkeit mit
fehlendem „Kleber“ zwischen den Projek-
ten die Aussage „Software Made in Germa-
ny“ ins Leere. Vielmehr kommt die Frage
auf, inwieweit es überhaupt ein „Software
Made by XY“ gibt, da viele Projekte in
der Firma XY offensichtlich individuelle
Phänomene sind, mit unklaren ad-hoc Ei-
genschaften. Besonders heikel ist dabei das
außergewöhnlich schlechte Abschneiden
des Bereichs „Verbesserungsprozesse“, da
dies offensichtlich den direktesten Optimie-
rungsweg darstellt.
Interessant ist vor dem Hintergrund dieser
hier aufgezeigten Industrialisierungsschere
der Trend „Industrie 4.0“, bei dem es um
nicht weniger geht als darum, dass „die
Abb. 11: Erwartete Nachteile durch den Einsatz von Entwicklungsprozessen.
|| Dr. Frank Simon
(frank.simon@BLUECARAT.de)
ist bei BLUECARAT für das
Business-Development verantwort-
lich. Beim BITKOM leitet er den
Arbeitskreis Software-Engineering
und er ist im Vorstand des German
Testing Boards.
|| Dipl.-Betriebswirtin
Annette Koßmann
(annette.kossmann@sqs.com)
ist bei der SQS AG für den fachli-
chen Austausch mit Hochschulen
und Forschungsprojekten sowie für
die Schulung der prozessualen und
ergebnisorientierten Standardisie-
rung der Services verantwortlich.
|| Dr. Marco Kuhrmann
(kuhrmann@in.tum.de)
arbeitet an der TU München im
Bereich Projekt- und Prozessma-
nagement. Er ist Fachexperte im
erweiterten Leitungsgremium der
Fachgruppe Vorgehensmodelle der
Gesellschaft für Informatik.
|| Dr. Daniel Méndez Fernández
(mendezfe@in.tum.de)
arbeitet an der TU München im
Bereich Requirements Enginee-
ring und empirisches Software
Engineering.
Die Autoren
lung also als Ingenieursdisziplin verstehen,
die Entwicklungen plant, diszipliniert
durchführt und kontinuierlich misst, dann
sollten wenigstens unternehmensweite Ent-
wicklungs- und Testprozesse definiert und
eingesetzt werden.
Die Ergebnisse dieser Studie zeigen: Der
Weg dahin ist noch sehr lang, er sollte
aber helfen, den „Vertrauensvorsprung für
Anbieter aus Europa […] mit Werten wie
Vertrauen, Zuverlässigkeit, Sicherheit und
Datenschutz“ (vgl. [Ros11]) als entschei-
denden Wettbewerbsvorteil zukünftig zu
etablieren. Allerdings muss die Geschwin-
digkeit erhöht werden, denn bereits heute
gilt: „Die Industrialisierung der IT wird
Auswirkungen auf das Personal haben und
zu Veränderungen am IT-Arbeitsmarkt füh-
ren“ (vgl. [Wal12]). Die Kunst wird es sein,
diese Änderung als Chance und nicht als
Risiko zu sehen: „Es ist nicht die stärkste
oder intelligenteste Spezies, die überlebt. Es
ist die Spezies, die sich Veränderungen am
besten anpasst“ (Darwin nach [Ros11]). ||
01/2014 23
www.objektspektrum.de
Literatur & Links
[Bit10] BITKOM, Industrielle Softwareentwicklung: Leitfaden und Orientierungshilfe, 2010,
siehe:
http://www.bitkom.org/les/documents/Industrielle_Softwareentwicklung_web.pdf
[Bit13] BITKOM, Agiles Software Engineering Made in Germany: Leitfaden, 2013, siehe:
http://www.bitkom.org/les/documents/LF_Agiles_Software_Engineeringpdf(1).pdf
[Bre07] W. Brenner, A. Hochstein, N. Ebert, F. Übernickel, IT-Industrialisierung: Was ist das?,
in: Computerwoche vom 3.4.2007, siehe:
http://www.computerwoche.de/a/it-industrialisierung-was-ist-das,592035
[Gre12] S. Greter, W. Keller, Agilität skaliert: Ein agiles Projekt in einem internationalen Groß-
konzern, in OBJEKTspektrum 2/2012
[Höh09] H. Höhn, B. Sechser, K. Dussa-Zieger, R. Messnarz, B. Hindel, Software Engineering
nach Automotive SPICE: Entwicklungsprozesse in der Praxis: ein Continental-Projekt auf dem
Weg zu Level 3, dpunkt.verlag 2009
[Hol13] A. Holmberg, Mit C auf der sicheren Seite, in: All-electronics.de, siehe:
http://www.all-electronics.de/texte/anzeigen/50654/Mit-C-auf-der-sicheren-Seite
[Ott08] B. Otterbach, Porsche-Lieferant des Jahres, in: Automobil-Industrie 2008-08, siehe:
http://www.automobil-industrie.vogel.de/interieurkomfort/articles/117058/
[Ros11] C. Rossbach, B. Welz, Survival of the fittest: Wie Europa in der Cloud eine führende
Rolle übernehmen kann, Roland Berger Strategy und SAP, 2011, siehe:
http://www.rolandberger.com/media/pdf/Roland_Berger_Cloud_Ecosystem_D_20111130.pdf
[Sch12] A.-W. Scheer, Die Industrierevolution 4.0 verändert Organisationen und Prozesse,
2012, siehe: http://www.august-wilhelm-scheer.com/2012/08/23/die-industrierevo-
lution-4-0-verandert-organisationen-und-prozesse/
[Smi13] V. Smit (Hewlett-Packard), Zukünftiges Wirtschaftswachstum, in: E-3 Magazin Mai
2013, siehe: http://www.e-3.de/heft/mai-2013/
[Wal12] S.M. Walter, T. Böhrmann, H. Krczmar, Industrialisierung der IT- Grundlagen, Merk-
male und Ausprägungen eines Trends, in: IT-Industrialisierung, HDM 256, August 2007
