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.
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.
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?
Grundlagen versus Theorie
MB: Volle Zustimmung!
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.
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?
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:
- Broy, M., Jarke, M:, Nagl, M., Rombach, D.: Manifest: Strategische Bedeutung des Software Engineering für Deutschland. Informatik Spektrum 29.3 (2006), 210-221
- Broy, M., Kuhrmann, M.: Projektorganisation und Management im Software Engineering. Heidelberg 2013
- Evasoft2000: Analyse und Evaluation der Softwareentwicklung in Deutschland. Studie für das Bundesministerium für Bildung und Forschung, 2000