Kurs:Wirtschaftsinformatik SS09/SE1/Lernskript/ImmateriellesGut

Software-Engineering im Vergleich mit zwei anderen Ingenieursdisziplinen

Software ist ein immaterielles Gut. Die Arbeit an der Software ist unsichtbar für Außenstehende. Schwere Konsequenzen sind die Folge: Software kann man nicht beliebig ändern. Konstruktionsfehler sind nicht einfach erkennbar wie zum Beispiel bei Mängelware. Ein Kratzer beim Lack eines Mercedes kann rasch erkannt werden. Fehler in einem Software-Artefakt zu finden ist dagegen eine Kunst. Eine Sicherheit jemals alle Fehler in einem Software-Artefakt zu finden gibt es nicht.

Die Personalkosten sind der Hauptposten bei den Kostentreibern von Software. Der Auftraggeber knabbert daran, wie er gute Software-Entwickler von schlechten Software-Entwicklern unterscheiden kann. Denn Software-Fehler sind nicht unmittelbar sichtbar. Nach Tom deMarco liegt das Verhältnis bei den Leistungsunterschieden zwischen durchschnittlichen und guten Software-Entwicklern bei 1:2. Die Spitzengruppe erreicht ein Leistungsgefälle von 10:1 im Vergleich zu der schlechtesten Programmierern.

Die Intransparenz ist ein Problem - insbesondere wenn man die Implementierung auslagern möchte nach Indien. Der Fachbegriff heißt outsourcing. Große Hoffnungen wurden auf das outsourcing von Entwicklungskosten gesetzt; inzwischen ist man ernüchtert. Gute Programmierer von schlechten Programmierer unterscheiden ist schwer. Erste Hilfe bieten Programmierwettbewerbe z.B. bei Top Coder. Es gibt auch die Sitte, seine Fertigkeiten mit Open Source Projekten unter Beweis zu stellen. Open Source Programme können von allen kostenlos verwendet werden. Die Coder handeln da mit einer ähnlichen ökonomischen Praxis, wie kostenlosen Artikel von aufstrebenden Journalisten. Es geht darum einen guten Ruf aufzubauen, das zu einer gut dotierten Anstellung bei einer Zeitung oder Zeitschrift führen soll; in der Berufsgruppe der Programmierer geht es eben um einen hochbezahlten Job in einer Software-Haus. Zu dem Problem trägt bei, dass an Universitäten eigentlich nicht gelehrt wird, wie man programmiert, sondern die Wissenschaft Informatik wird gelehrt. Ein Irrtum ist zu glauben, dass ein Informatik-Studium Programmierer ausbilden kann. Programmieren ist eine Kunst. Kunst erlernt man durch Übung und Feilen an den eigenden Fertigkeiten. Um passabel zu programmieren an einer Erstsprache zu lernen, braucht man etwa ein halbes Jahr. Als Autodidakt ein Spitzenprogrammierer zu werden, sollte man möglicherweise zehn Jahre programmieren. Durch die Vertiefung in die Wissenschaft Informatik - insbesondere mit Hilfe eines guten Algorithmen-Kurs - geht das Gerücht um, dass sich die Zeit auf zwei Jahre stauchen läßt. Programmieren ist wie Sprachenlernen. Je mehr Sprachen man kennt, desto einfacher ist es, eine neue zu lernen. Noch viel schwieriger ist die Programmierfähigkeit von Teams zu beurteilen. Aus diesem Grund werden nur die Entwicklung von Standartsoftware in weit entfernte Länder und Zeitzonen ausgelagert; denn da hat man Blaupausen, oder es wird eine Blaupause durch Re-Engineering hergestellt. Kritische Entwicklungsaufgaben gehen als Aufträge an nahe Zeitzonen mit ähnlicher Arbeitsmentalität: der Softwareprojektleiter will schnell eingreifen können bei Problemen und niedrige Kommunikationsbarrieren. Dafür will er nicht mehrere Flugstunden investieren wollen. Kurze Flugzeiten reduzieren spürbar das Outsourcing von Entwicklungsaufgaben.

Im Vergleich zu anderen Ingenieursdisziplinen gibt es im Software Engineering keine allgemein bewährten Abstraktionen und Visualisierungen. Der Ansatz des Unified Modeling Language ist nur ein gute Annäherung gemessen an den Standart eines Fahrzeugbauers. Die Autoteile können an Ansätzen aus vorigen Produkten modelliert werden; der Fahrzeughersteller erinnert sich an alt bewährte Methoden. Die Qualität des Personals ist ein entscheidender Erfolgsfaktor. Die großen Unterschiede in Produktivität und Qualität zwischen verschiedenen Entwicklern treiben Kosten hoch, wenn man seine Auftragnehmer unglücklich wählt. In der Automobilindustrie zählen die Maschinen bei der Produktivität. Der größte Teil der Produktion ist maschinell, und das Personal ist nur beim Design, Entwurf und Steuerung gefragt. Gerade weil der Erfolg beim Software Engineering von der Qualität des Personals abhängt, ist Software Engineering eine multipersonale Ingenieursdisziplin. Reden ist Silber und Schweigen Gold ist eine deplazierte Maxime beim Software-Engineering. Die Kommunikation zwischen den Beteiligten vermeidet viele Fehler. Die eingesparte Zeit machen die kommunikativen Entwickler produktiver, und die Qualität der Software wird besser. Bei Fahrzeugbauern zählt die hardware der Produktionsmittel und in der Software-Entwicklung ist die peopleware beinahe alles. Der Ausdruck peopleware ist auch der Titel eines sehr guten Primers zu Software-Engineering, das ich als Lesetip empfehle. Der Autor Tom deMarco schreibt unterhaltsame und aufrüttelnde Sachbücher zu Software-Engineering.

Ein ganz wichtiger Unterschied zwischen dem Software Engineering und beispielsweise dem Maschinenbau oder spezieller gesagt der Automobilherstellung ist die Tatsache, dass in vielen Anwendungsbereichen bei der Software Fehler hingenommen, während man bei der Automobilherstellung ein fehlerfreies Produkt erwartet. So veröffentlichen viele Hersteller Buglisten, die erst in den Folgeversionen behoben werden, was kaum einen Nutzer vor der Nutzung der Software abschreckt. Im Gegensatz dazu würde ein Auto wahrscheinlich gar nicht erst für den Straßenverkehr zugelassen , wenn man beispielsweise weiß, dass der Beifahrer-Airbag nicht funktioniert. Die mathematische Gewißheit ein richtiges Stück Programmcode in den Händen zu halten, ist nur erzielbar, wenn man sich bei der Programmierung auf drei Sprachkonzepte beschränkt:

(1) Zuweisungen

(2) IF-Kaskaden

(3) Schleifen

Sobald mehr Sprachkonstrukte auf tausenden von Codezeilen verteilt auftauchen, ist die automatisierte Programmverifikation nicht mehr möglich. Um Vertrauen in die Software herzustellen, gibt es Testtechniken. Grob eingeteilt sind das Black-Box und White-Box Test. Das wird an späterer Stelle behandelt.

Weiterhin gibt es signifikante Differenzen zwischen dem Software Engineering und dem Bauingenieurwesen, was die bedeutendsten Kostenfaktoren angeht: Beim Bauingenieurwesen ist die Umsetzung (= Herstellung) der Pläne also z.B. der konkrete Bau eines Hauses ein wichtiger Kostenfaktor, während beim Software Engineering die Herstellung (z.B. das Brennen auf eine CD) vernachlässigbare Kosten verursacht. Stattdessen verursacht die Entwicklung der Software die meisten Kosten. Es setzt sich fast nur aus Personalkosten zusammen.