Software Engineering in Deutschland ̶ eine kritische Bestandsaufnahme (Version 2)

Anlässlich eines Dagstuhl-Workshops im Oktober 2005 entstand ein Manifest [1], das außer von den vier Autoren Manfred Broy, Matthias Jarke, Manfred Nagl und Dieter Rombach noch von weiteren 30 Kollegen unterschrieben wurde. Das sind fast alle Inhaber von deutschen Universitätslehrstühlen in Softwaretechnik bzw. Software Engineering. Als ich für meinen letzten Blog-Beitrag das Manifest wieder einmal las, stimmten mich einige Aussagen doch etwas nachdenklich. Ich nahm mir vor, sie mit einigen Kollegen zu diskutieren. Ich will dies in der Form eines Gruppen-Interviews tun, und zwar in diesem Blog.

Alle mir etwas auffällig erscheinenden Aussagen in dem Manifest hatte ich zunächst in Kurzform übernommen. Ich habe sie in kursiver Schrift vorneweg gestellt. Ich habe eine stichwortartige Überschrift hinzugefügt. Anschließend habe ich in jedem Fall einige Fragen formuliert, die mich bewegen. Zur Beantwortung habe ich mir bekannte Kolleginnen und Kollegen eingeladen. Die Antworten sind hier alle aufgeführt, und zwar mit oder ohne Namen des Beitragenden, ganz nach Wunsch. 

Die ersten drei Antworten kamen vom Kollegen Christof Ebert in Stuttgart (am 30.8.). Der Beitrag von Peter Mertens aus Nürnberg folgte als nächster (am 3.9.). Eine sehr ausführliche Antwort kam von Manfred Broy (am 12.9.). Er schlug unter anderem vor den Originaltext des Manifests zu zitieren und nicht meine (nicht immer gelungene) Paraphrase. Das habe ich jetzt geändert. Platz ist ja kein Argument, eher die Übersichtlichkeit. Barbara Paech aus Heidelberg hat sich (am 22.9.) noch der beiden Zusatzfragen am Schluss angenommen.

Aktuelle Erfolgsmaßstäbe

Software Engineering (abgekürzt SE, deutsch Softwaretechnik) auf Weltniveau ist die Voraussetzung dafür, dass Deutschland seine führende Stellung im Ingenieurbereich (z.B. Export-Weltmeister im Maschinenbau) halten und ausbauen bzw. eine entsprechende Position in neuen Sparten (z.B. e-Health) aufbauen kann. 

Bertal Dresen (BD): Welche Qualitätsziele halten Sie heute für relevant und angemessen (wie z. B. Fehlerfreiheit, Zuverlässigkeit, Änderungsfreundlichkeit)? Welche Maße sollen zur Anwendung kommen und welche Schwellwerte sind derzeit erreichbar bzw. akzeptabel? Wie sieht es heute bezüglich Produktivitätszielen aus? Welche Maße bevorzugen Sie (z. B. LOC, Function Points)? Müssen Metriken stärker in der Ausbildung verankert werden? Teilen Sie meine Meinung, dass die Produktivität an Bedeutung verliert, sobald auch der Wert eines Produkts in Betracht gezogen wird?

Christof Ebert (CE): Das sind viele Fragen, und viele sind heute beantwortet. Qualitätsziele werden für das Projekt oder Produkt festgelegt und durch Standards unterstützt,  beispielsweise funktionale Sicherheit oder Benutzbarkeit. Auch das Software-Volumen hat inzwischen seine durch ISO abgedeckten Standards, auf Basis der Function Points. Produktivität wird heute grundsätzlich wertorientiert gemessen, denn Softwarezeilen pro Stunde und andere solcher Maße sind ziemlicher Quatsch. Die Standardisierung mit ISO hat die Informatik professioneller gemacht. Standards zählen heute zum Kanon des „State oft the Art“ und sind damit vor Gericht, beispielsweise bei der Produkthaftung, relevant. Kritisch bleibt, dass in der Ausbildung und Industrie zu wenig empirisch gearbeitet wird. Kennzahlen sind ad-hoc, und die wenigsten Unternehmen haben belastbare Erfahrungsdatenbanken.

Peter Mertens:  Im Hinblick auf die  weitere Integration  von IT-Systemen in Unternehmen, in Institutionen der öffentlichen Verwaltung und selbst in Haushalten, auf eingebettete Systeme, auf Verbindung von Informationstechnik und Mechanik sowie  mit Blick darauf, dass sich immer mehr zum Teil wenig geschulte  Menschen (z. B. Sparkassenkunden) zwangsläufig mit IT-Systemen befassen müssen, scheint mir vordringlich: Viel gründlicher und geduldiger  als bisher üblich müssen die Apps, Programme und Systeme, die "auf die Menschheit losgelassen" werden, ausgetestet sein. Das hätte zur Folge, dass die Zeitspannen zwischen "Updates" sehr viel länger werden als momentan üblich. Angestrebt werden sollte z. B., dass die Software im PKW mindestens so lange fehlerfrei arbeitet, wie das durchschnittliche Wartungsintervall des Fahrzeugs ist. Dann könnte die Werkstatt die nächste Version fachmännisch aufspielen und die Fahrzeugeigentümer müssten sich nicht alle paar Monate mit den Problemen und den Tücken der Softwareimplementation auseinandersetzen und hierfür viel Freizeit opfern.

Dass  sich umgekehrt  Hersteller von Gebrauchsgütern aller Art  ̶  ich denke z. B. an eine Aussage des Vorstandsvorsitzenden eines bedeutenden deutschen Fahrzeugproduzenten  ̶  dafür aussprechen, im Interesse der Geschwindigkeit ("Time to Market") den  Entwurf und  Bau ihrer Erzeugnisse  dem momentan unbefriedigenden Perfektionsgrad der Softwareproduktion anzunähern, halte ich für den falschen Weg und nachgerade für eine Reduktion der Wohlfahrt im Staat. Kurzum: Auch bei der verkauften Software jene Reife, die man physischen Produkten "Made in Germany" (oder Austria oder "Swiss made") weltweit oft attestiert.

BD: Peter Denning (Jahrgang 1942) rüttelte in einem Beitrag in den CACM (Heft 59,9, 9/2016) an den von ISO standardisierten (und von Christof Ebert zitierten) Qualitätskriterien. Anstatt ihrer schlägt er sechs Stufen vor, die stärker die Nutzersicht als die Entwicklersicht berücksichtigen. Sie sind in der folgenden Tabelle zusammengefasst.

Die unteren zwei Stufen sind negative Maße, die oberen vier sind aufsteigend positiv. Man sollte über sie diskutieren.

Manfred Broy (MB): In den letzten Jahren sind sehr differenzierte Qualitätsmodelle, auch nicht zuletzt durch meine eigenen Forschungsarbeiten, entwickelt worden. Ein besonderes Augenmerk haben wir auf das Thema der Wartbarkeit gelegt. Ein Start-Up aus meiner Forschungsgruppe, die CQSE, ist hier aus meiner Sicht am absoluten 'leading-edge' in Praxis und Theorie. Was Produktivitätsziele betrifft, so halte ich alle Metriken für Krücken. Allerdings meine ich, dass Metriken stärker in der Ausbildung verankert sind. Das lässt sich auch, soweit es meine Lehre betrifft, gerne nachweisen. Sie brauchen nur mein vor wenigen Jahren erschienenes Buch zum Thema Projektorganisation und Management [2] lesen. Dann sehen Sie, welche Bedeutung dort den Metriken eingeräumt wird. Der letzte Satz, dass Produktivität an Bedeutung verliert sobald der Wert eines Produktes in Betracht gezogen wird, ist eine Binsenweisheit.

Vergleich Maschinenbau

Damit erfolgversprechende Forschungsprojekte realisiert werden können, muss eine Zusammenarbeit mit Ingenieuren, insbesondere Maschinenbauern, erfolgen. Disziplinen wie der Maschinenbau unterscheiden sich allerdings in Bezug auf ihr Wissenschaftsverständnis merklich von der Informatik. Während in der Informatik allgemein das Bestreben nach verallgemeinerbaren Methoden vorherrscht, besteht im Maschinenbau ein vorrangiges Ziel darin, funktionierende (große) Systeme zu bauen. Disziplinübergreifende Forschungsprojekte müssen sowohl den methodischen Erkenntnisfortschritt als auch eine empirische Bestätigung beinhalten und werden daher in der Zukunft deutlich höhere Forschungsvolumina benötigen. 


BD: Halten Sie die hier ausgedrückte Meinung für richtig, dass in der Software lediglich die Methoden zählen, nicht jedoch Produkte und funktionierende Systeme? Sollte die hier zitierte Meinung an Hochschulen oder in der Praxis vorherrschen, was muss geschehen, um sie zu verändern? Ist es nicht gerade für ein Hochlohnland wie Deutschland wichtig, auf den Multiplikatoreffekt von Produkten zu setzen, anstatt sich auf Projekte zu spezialisieren?

MB: Es ist Unsinn zu behaupten, dass in der Software nur die Methoden zählen und nicht die Produkte. Das ist in dem Manifest auch nie so gesagt worden. Eine solche Meinung herrscht auch an Hochschulen nicht vor und in der Praxis schon gleich gar nicht.

Grundlagen versus Theorie

Angesichts der hohen gegenwärtigen Bedeutung und der sich noch verstärkenden Bedeutung in Zukunft ist von Seiten des BMBF eine wesentlich höhere Förderung für Software Engineering vorzusehen. Auch die Deutsche Forschungsgemeinschaft muss diese Thematik in besonderer Weise fördern, indem spezielle Programme aufgelegt werden und sich sowohl DFG als auch Gutachter klar werden, dass Grundlagenorientierung – wie in allen Ingenieurwissenschaften – nicht nur Theorie bedeutet.

BD: Als Grundlagen der Informatik gelten diejenigen Wissenschaften, auf denen sie beruht (z.B. Physik, Mathematik, Elektrotechnik, Psychologie)? Eine Theorie in den Naturwissenschaften erklärt, warum etwas geschieht. Ist der Eindruck richtig, dass der Begriff Theorie von Informatikern oft auch für die Formalisierung gewisser Methoden benutzt wird? Woran liegt das? Was kommt dadurch zu kurz?

MB: Als Grundlagen der Informatik sehe ich nicht die Physik, Mathematik, Elektrotechnik und Psychologie. Theorie in der Informatik wird zumindest nach meiner Definition mit den fundamentalen Zusammenhängen begründet wie Berechenbarkeit, formale Sprachen, algorithmische Komplexität. Grundlagen im Software-Engineering bedeutet für mich, zusätzlich zu den Kenntnissen wesentlicher Teile der Theorie der Informatik, dass der Student ein klares Verständnis von wichtigen Begriffen hat, mit denen der Software-Ingenieur hantiert. Beispiele sind Schnittstelle, Architektur, Modularität, Kompatibilität. ... . Ich könnte hier das Begriffsgerüst beliebig fortsetzen.

Ziele der Ausbildung

Die universitäre Lehre muss international wettbewerbsfähig sein. Sie sollte international zusammenarbeiten. Trotz Grundlagenorientierung muss auch auf die gegenwärtige Praxis vorbereitet werden. 
...  Neben der Vermittlung praxisrelevanter Inhalte muss die Lehre auch gezielter auf Forschungsinhalte vorbereiten.

BD: Der letzte Satz könnte dahingehend interpretiert werden, dass Hochschulen primär an dem eigenen Nachwuchs interessiert seien. Ist dieser Vorwurf begründet? Ist es nicht viel wichtiger auch das Entwickeln und Bewerten von Produkten und Dienstleistungen zu lehren? Wie kann die Praxis-Relevanz des Studiums generell gesteigert werden? Lassen sich ‚soft skills‘ (z.B. Rhetorik, Team-Fähigkeit) theoretisch lehren?

CE: Die Ausbildung muss immer an der späteren Umsetzung interessiert sein. In der Informatik-Ausbildung werden der untere Teil des V-Modells und die Werkzeuge überbetont, während Requirements Engineering, Projektmanagement, Soft Skills etc. zu kurz kommen. Natürlich geht das nicht nur theoretisch, und genau deshalb ist es wichtig, dass das Studium Grundlagen und Methodik auch im praktischen Kontext vermitteln. Das kommt dort zu kurz, wo Professoren nur an Zitationsindexen interessiert sind und nie in der Industrie gearbeitet haben.

MB: Das Manifest beschreibt explizit, dass Lehre auch auf Praxis vorbereiten muss und natürlich auch auf die Fähigkeit zu forschen. Das ist der Anspruch jeder wissenschaftlichen Disziplin. Zumindest, was mich betrifft und die Kollegen, deren Lehre ich kenne, muss ich sagen, dass es ein völlig unzutreffender Vorwurf ist, dass wir nur am eigenen Nachwuchs interessiert sind. Ich finde die Unterstellung fast bösartig.

Verhältnis Primär- zu Sekundärbereich

  

Software ist wettbewerbsentscheidender Faktor geworden, nicht nur in der Primärbranche, die durch die Entwicklung eigenständiger Softwareprodukte gekennzeichnet ist. Dies gilt weitaus stärker in allen so genannten Sekundärbranchen (eingebettete Software in Produkten und Dienstleistungen, z.B. Maschinen- und Fahrzeugbau, Elektrotechnik, Telekommunikation, aber auch Unterhaltungsbranche, Medizin u.a.), in denen 80 % der Softwareingenieure arbeiten [3]. Für die Wertschöpfung im Produktionsgüter- und Dienstleistungsbereich ist Software Engineering entscheidend als „Produktionstechnik des 21. Jahrhunderts“.

BD: Das klingt für mich, als ob man aus der Not eine Tugend macht. Führt diese Einstellung nicht dazu, dass Informatiker auf Dauer in eine Ecke gedrängt werden, während Ingenieure, Kaufleute, Ärzte und andere das Denken für sie übernehmen und auch den ganzen Ruhm einheimsen? Sollten Informatiker nicht  lieber andern Berufen und Personengruppen Informatik-Produkte anbieten, mit denen sie ihre Anwendungen leicht und sicher erstellen können? SAP ging  ̶  zumindest ansatzweise  ̶  in diese Richtung. Wäre das nicht nur ein Weg zu mehr Professionalität der Informatiker, würde es nicht auch das Problem des Fachkräftemangels an der Wurzel angreifen?

MB: Ich bin genug in Projekten unterwegs, insbesondere auch als Gutachter für gescheiterte Projekte, um eine Vielzahl von Beispielen aufzählen zu können, die zeigen, dass dieses Bild eben gerade heute noch mehr zutrifft denn je. Ich schreibe das unter dem Eindruck eines Projektes, das ich gerade begutachtet habe, das für das Anwendungsunternehmen von strategischer, fast existentieller Bedeutung ist und durch Missmanagement in ein Desaster geführt worden ist.

Nirgends steht im Manifest, dass es sich nicht lohnt, sich um den Primärbereich zu kümmern. Allerdings gilt mehr denn je, dass heute die Informatik in allen möglichen Disziplinen entscheidend in den Anwendungen unterwegs ist. Und man wird in diesen Anwendungen keinen Fortschritt machen, wenn hier nicht Software-Engineering und Anwendungs-Know-How eine enge Verbindung eingehen. Im Manifest wird in keinster Weise geschrieben, dass hochqualifizierte Arbeitsplätze nur mit Ausländern besetzt werden. Im Text wird zunächst über Wissenschaft gesprochen und über die Art und Weise, wie sich der Ruf von Wissenschaftlern begründet. Was das für die Praxis bedeutet, ist etwas ganz anderes. Abgesehen davon kenne ich eine Vielzahl von Firmen, die über die Landesgrenzen hinaus wirken, insbesondere Anwendungsfirmen. Beispiele sind Siemens, KUKA, die deutschen Automobil-Firmen und eine Vielzahl von anderen mittelständischen Firmen.

Weiterbildung von Praktikern

Die Hochschulen sollten für die Weiterqualifizierung von Industrie-Mitarbeitern sorgen. Hier bestimmen Quereinsteiger noch immer das Bild des Berufes.

BD: Natürlich würde die Industrie begrüßen, wenn sich Hochschulen hier stärker engagieren würden. Was kann getan werden, um die Situation zu verbessern? Bei fast einer Million Arbeitskräften im IT-Bereich werden Quereinsteiger noch lange benötigt. Was ist falsch daran?

MB: Quereinsteiger stoßen schnell an ihre Grenzen!

Schätzung des Bedarfs

Es gibt einen geschätzten Bedarf von 385.000 Softwareentwicklern in Deutschland. Auch bei vorsichtiger Bewertung dieser Zahl ergibt sich daraus, dass ein weiterer Ausbau der Softwaretechnik an deutschen Universitäten dringend erforderlich ist, denn nach dem aktuellen Stand der Forschung und Lehre wären das derzeit 7300 benötigte Softwareentwickler pro Forschungsgruppe. Vereinzelt begründen einschlägige Firmen bereits die Verlagerung ins Ausland mit dem Mangel an Softwareingenieuren.

BD: Wie verlässlich sind solche Bedarfsschätzungen? Wie weit kann bzw. muss dieser Bedarf aus Nachwuchs im Inland abgedeckt werden? Besteht wirklich ein Mangel an deutschen Führungskräften? Wenn ja, was kann getan werden?

MB: Nur zu dem Punkt des Mangels an deutschen Führungskräften. Nennen Sie mir fünf Vorstandsmitglieder in deutschen DAX-Unternehmen, die in der Lage sind, ihr Unternehmen zu Fragen der Digitalisierung strategisch kompetent zu führen.

Internationale Ausstrahlung

Deutsche Wissenschaftlerinnen und Wissenschaftler im Bereich Software Engineering zeigen international eine hohe Präsenz. Insbesondere im Vergleich mit den europäischen Nachbarn lässt sich feststellen, dass in dem traditionell von den USA dominierten Feld neben den Briten gerade Deutsche in den Organisationskomitees und Herausgeberräten aller einschlägigen Konferenzen und Zeitschriften beteiligt sind. Dieses positive Bild zeigt sich auch in vielen Beiträgen zu Konferenzen und Zeitschriften, deren Anzahl allerdings noch steigerungsfähig ist.

BD: Ist diese Ansicht wirklich ernsthaft vertretbar? Die Informatik ist – und das weiß doch jeder – sowohl was die Wirtschaft als auch die Wissenschaft betrifft, international ausgerichtet. Ohne sichtbare technische und wissenschaftliche Leistungen, die auch im Ausland beachtet werden, insbesondere in den USA, verkommt Wirtschaft und Wissenschaft zur Provinzialität. Das großzügige finanzielle Engagement des Staates in Begegnungsstätten (wie Schloss Dagstuhl), im Ausland geförderte Forschungsgruppen (etwa der Fraunhofer-Gesellschaft) oder den Wissenschaftleraustausch (wie Fulbright und ICSI Berkeley) ist zweifellos hilfreich, allein reicht es sicherlich nicht aus. Was kann getan werden, um einzelne Wissenschaftler oder Unternehmer dazu zu motivieren, ihrem fachlichen Wirken über die Landesgrenzen hinaus mehr Nachdruck zu verschaffen? Welche neuen Initiativen könnten helfen?

MB: Nur ganz kurz: Wir versuchen gerade eine konkrete inhaltliche Zusammenarbeit mit den USA!

Technologietransfer

Die Industrie ist eingeladen, diese Zusammenarbeit verstärkt zu suchen bzw. anzunehmen. Innerhalb dieser Zusammenarbeit kann vorhandenes Wissen transferiert werden bzw. gemeinsam erarbeitetes für die Nutzung aufbereitet werden. Diese Zusammenarbeit besteht nicht aus kurzzeitiger und kurzfristiger Entwicklungsarbeit. Eine längerfristige Zusammenarbeit im beschriebenen engen Kooperationsmodus bezüglich des Horizonts der Aufgabenstellung und der Kooperationszeit ist eine ideale Basis für das Rekrutieren von Mitarbeitern, deren Qualifikation und Eignung der Industriepartner dann genau kennt.

BD: Wird nicht über dieses Problem schon seit Jahrzehnten gejammert? Was kann getan werden, um die Situation zu verändern?

CE: Technologietransfer findet überall dort statt, wo parallel zur Forschung auch der Markt und der Bedarf hinterfragt werden. Gute Forschung ist auf Tuchfühlung mit der Industrie. Algorithmen für Suchmaschinen oder für selbstfahrende Autos entstehen genau an dieser Schnittstelle, und nicht im stillen Kämmerlein eines Lehrstuhls. Dass es klappt, zeigen Fraunhofer Institute und die vielen Unternehmen, die ganz konkret mit Hochschulen arbeiten und damit den Transfer operationalisieren. Bei Vector [dem Unternehmen, bei dem Ebert Geschäftsführer ist] unterstützen wir verschiedene deutsche Hochschulen in der Forschung und im Transfer – ohne die Freiheit der Forschung einzuschränken.

MB: Von jammern kann keine Rede sein – wir machen das – gern bei Bedarf näheres!

Stand der Praxis

Im Widerspruch dazu wird in vielen Unternehmen der Sekundärbranche die Entwicklung und Pflege von Software noch als reiner Kostenfaktor betrachtet. Nur wenige Unternehmen haben bereits die strategische Bedeutung von Software als Umsatzgenerator und „Business-Enabler“ erkannt und betrachten Softwareprojekte unter dem Aspekt ihrer Unternehmensstrategie.

BD: Kommt hier nicht eine Meinung zum Ausdruck über eine Situation, die mindestens seit 20 Jahren nicht mehr zutrifft. Was kann getan werden, um das nachhängende Bild zu korrigieren?

MB: Betrachtet man wie der Einkauf in der Automobilindustrie Aufträge vergibt – im Fall von Softwareentwicklern rein nach Tagessätzen – so sieht man, dass die Aussage aus dem Manifest nach wie vor gilt!

  

Stuttgarter Modell

Die Erfahrungen mit einem speziellen Studiengang mit dem Schwerpunkt Softwaretechnik sind sehr gut. Versuche, wie etwa in Stuttgart, wurden nach erfolgreicher Evaluation inzwischen fest etabliert.

BD: Warum blieb Stuttgart bisher ein Einzelfall? Gäbe es nicht Alternativen zum Stuttgarter Modell, die insgesamt besser wären, nämlich generell die konstruktiven Aspekte der Informatik stärker zu betonen, und zwar für Systemprodukte, in denen Hardware und Software zusammen geplant werden?

MB: Volle Zustimmung!

Zusatzfrage 1

BD: Welche Möglichkeiten gibt es, um sowohl den intellektuellen wie den wirtschaftlichen Wert eines Software-Produkts kenntlich zu machen und ins allgemeine Bewusstsein zu rufen? Gibt es Möglichkeiten, dieses Anliegen während des Studiums stärker zur Geltung zu bringen?

Barbara Paech (BP): Ja, natürlich. Bei uns gibt es durch einen Lehrbeauftragten von SAP eine Vorlesung Software-Ökonomie. In Projekten mit industriellen Auftraggebern (im großen Stil bei Herrn Brügge an der TUM), im kleinen Stil an vielen anderen Unis erhalten die Studis ganz konkrete Anforderungen bzw. Feedback, das den  wirtschaftlichen Wert betont. Allerdings eher für kleine Anwendungen wie Apps.

Zusatzfrage 2

BD: Was sehen Sie als die größten Erfolge des Software Engineering an? Wo besteht noch Nachholbedarf? Wie sehen Sie Deutschland im Vergleich zu anderen Ländern? Tut die Gesellschaft für Informatik (GI) auf diesem Gebiet genug und – vor allem – tut sie das Richtige?

BP: Ich persönlich finde es nicht so hilfreich, größte Erfolge zu sammeln. Wichtig ist mir eine kontinuierliche positive  Weiterentwicklung. Im Bereich Requirements Engineering, den ich am besten beurteilen kann, gibt es z.B. eine Entwicklung von ausschließlich systemnahen Anforderugen zum Einbezug von NutzerInnen durch 'Use cases' und 'user stories'  zu 'continuous software engineering' mit kontinuierlichem NutzerInnen-Feedback zu kleinen Inkrementen. Da ist vieles noch nicht ganz ausgereift, aber das geht ein ganz essentielles Problem des SE an, nämlich dass die Produkte oft Funktionalität haben, die die NutzerInnen so nicht brauchen können oder wollen.

Diese Entwicklungen werden typischerweise nicht durch Unis angestoßen, sondern kommen aus der Praxis, aber die empirische Forschung hilft, Mechanismen deutlich zu machen und von Werbesprüchen wegzukommen. Die methodische Forschung hilft, diese oft als Hype entstehenden Entwicklungen (ein)zuordnen und eben auch für die Lehre aufzubereiten.

BD: Vielen Dank allen Beitragenden!

Referenzen:

1. Broy, M., Jarke, M:, Nagl, M., Rombach, D.: Manifest: Strategische Bedeutung des Software Engineering für Deutschland. Informatik Spektrum 29.3 (2006), 210-221
2. Broy, M., Kuhrmann, M.: Projektorganisation und Management im Software Engineering. Heidelberg 2013
3. Evasoft2000: Analyse und Evaluation der Softwareentwicklung in Deutschland. Studie für das Bundesministerium für Bildung und Forschung, 2000