Der ständig härter werdende Konkurrenzkampf macht betriebsweite Informationssysteme unabdingbar. Kann die Software für diese Systeme nicht in adäquater Qualität geliefert werden, so droht den Unternehmen ein operationelles Debakel. Qualität läßt sich aber weder einkaufen noch automatisch erzeugen; sie muß systematisch kultiviert werden.

Im letzten Jahrzehnt dieses Jahrtausends müssen wir mit noch nie dagewesenen wirtschaftlichen und technischen Voraussetzungen fertig werden: Wir leben heute unter der Drohung eines in seiner Heftigkeit beispiellosen internationalen Konkurrenzkampfes, der zusammenfällt mit spektakulären und nicht ungefährlichen politischen Turbulenzen.

Angesichts dieses fast unüberblickbaren Wirrwarrs haben unsere Unternehmen und Organisationen keinen Grund zur Selbstzufriedenheit. Der Ernst der Situation fordert uns heraus, nach neuen Organisationsformen zu suchen, die es erlauben, in den internationalen Märkten mit innovativen, qualitativ hochstehenden Produkten und Diensten zu bestehen.

Die neue Universalität der Märkte ruft einen erbarmungslosen Kampf aller gegen alle hervor. Dieser Kampf muß zwangsweise den ausgewoge-

nen, verschlafenen, bürokratischen Reigen in unseren großen Betrieben und Organisationen zerreißen .

Die Umwandlung, die sich unter unseren Augen vollzieht, erfordert sowohl die Integration von

bisher getrennten - oft gegeneinander arbeitenden - Unternehmensbereichen als auch die Dezentralisierung der Verantwortungen. Jeder einzelne wird in Zukunft viel stärker an der Gestaltung des Unternehmensgeschehens mitwirken müssen - im Sinne einer kommunizierenden Kreativität.

Die fundamentale Bedeutung der Informatik als Produktions- und Wirtschaftsfaktor wurde längst erkannt; ihr integrierter Einsatz in allen Betriebsbereichen ist aber noch nicht Realität. Europa kann zwar auf eine stolze Tradition in der Herstellung von technisch und qualitativ hochstehenden Produkten zurückblicken, aber wir sind weit davon entfernt, die Zukunft unserer Industrie- und Dienstleistungsbetriebe gesichert zu haben.

Es fehlt uns nämlich in zunehmendem Maße an der Software, die es uns erlauben würde, unsere Unternehmungen so zu führen, daß sie im internationalen Wettbewerb bestehen könnten. Wesentliche Prozesse unserer Betriebe müssen einer völligen Neukonzeption unterzogen werden. Deren Ziel sollte sein, diese Prozesse als funktionsfähige Einheiten in ein betriebsweites Steuerungs- und Produktionssystem zu integrieren.

Das sektorielle Denken sollte zugunsten eines integrativen Betriebsdenkens verschwinden. Vernetzungsmöglichkeiten müssen ausgeschöpft werden, um nicht nur den innerbetrieblichen Informationsaustausch zu steigern, sondern auch um Lieferanten und Kunden in ihren Funktionen zusammenzufügen. Die Zusammenschlüsse offener Systeme über standardisierte Schnittstellen bilden die unersetzliche Grundlage, um das Erfolgspotential unserer Betriebe voll auszuschöpfen.

Monumentale Blamage für die Computerindustrie

Der Informatikmarkt entwickelt sich exponential. Schätzungen künftiger Umsatzzahlen müssen immer wieder nach oben korrigiert werden. 1988 belief sich dieser Markt weltweit auf 250 Milliarden US-Dollar; für das Jahr 1995 werden Größenordnungen um 550 Milliarden US-Dollar geschätzt Dabei wachsen die Ausgaben für Hardware höchstens um zehn Prozent jährlich, jene für Software aber um zwanzig Prozent.

Der nicht zu deckende Bedarf an qualitativ hochstehender Software kann zu einer monumentalen Blamage der Computerindustrie werden. Für viele Unternehmungen, die auf Software zur Aufrechterhaltung des Betriebs angewiesen sind, dürfte dieses Manko zu einem operationellen Debakel führen.

Neben der gewaltigen Steigerung der Maschinen- und Kommunikationsleistungen wirkt das Softwaregeschehen unsicher, ständig schwankend zwischen der spektakulären Huldigung neuer Paradigmen oder Entwicklungsmethoden samt den darauf basierenden CASE-Tools einerseits und der Improvisation am Rande des Abgrundes andererseits. Die Funktionsfähigkeit vieler unserer Unternehmen steht derweil - wegen Mangel an adäquater Software - auf dem Spiel.

Die Informationstechnologie ist, gemessen an den eingesetzten Mitteln, selten mehr als eine teure Prothese, die in der Mitte der maßlosen Unordnung unserer Unternehmen noch wenig beiträgt zur betrieblichen Leistungssteigerung. Das titanenhafte Selbstbewußtsein der Informatiker schöpft seine Kräfte aus einer technischen Amoral, die nur allzuoft den Zweck mit den Mitteln vertauscht.

Mitten im Getöse des Technologierausches sind wir taub geworden für die Belange der Qualität. Daß die meiste Software, die heute entwickelt wird, gar nicht brauchbar ist und die meisten Informatikprojekte fehlschlagen, gehört zu den unbegreiflichen Extravaganzen der Branche. Auffälligerweise rufen diese Fehlleistungen nicht einmal das übliche Minimum von Konsterniertheit hervor.

Komplexe Strukturen ohne klare Grenzen

Die bedeutendste Rolle in der Software-Entwicklung spielt zweifelsfrei der Mensch. Als Auftraggeber, Designer, Entwickler, Datenbank- oder Systemspezialist muß er nach wie vor die meiste Arbeit bei der Entwicklung von Software durchführen. Die Anzahl der an einem Projekt Beteiligten erfordert zumindest drei wichtige Leistungen des Managements: die Vermittlung der Unternehmensphilosophie, die Zuteilung von Aufgaben und die Aufrechterhaltung der Kommunikation.

An die Stelle von geschlossenen Programmen, die auf eine feste Anzahl unveränderlicher Ergebnisse beschränkt sind, entwickeln wir heute Informationssysteme, die oft keine klaren Grenzen haben und fast unendlich komplex in ihrer Funktion und inneren Struktur sind. Die Welt der Informationssysteme ist eine offene, vielfältige Welt, die nicht leicht in einer einheitlichen Formel zusammengefaßt und begriffen werden kann. Diese Tatsache stellt ganz neue Herausforderungen an die Entwickler.

Die logische Beanspruchung der Informatiker war in der Vergangenheit eher einseitig und beschränkt. Zu den Sonderfähigkeiten, die ein Software-Entwickler früher haben mußte, gehörte eine gewisse maschinennahe Programmierakrobatik, die es ihm erlaubte, Algorithmen unter Aufwendung geringster Memory- und CPU-Ressourcen trickreich zu realisieren.

Die Entwicklung eines modernen Informationssystems verlangt aber die Betätigung einer vielseitigen,

natürlichen Intelligenz. Gefragt sind unter anderem ein deutliches und klares

Verständnis für Zusammenhänge, ein plastisches Vorstellungsvermögen für Betriebsabläufe und Anwendungsgestaltung, Gedankenschärfe in der Modellierung komplexer Verhältnisse, praktische Interpretation sowie Wertungsvermögen im Hinblick auf die Systemanforderungen. Ganz andere Intelligenzkategorien werden gefordert; sie sind aber nicht immer genügend ausgebildet.

Vom entwickelnden Informatiker wird heute aber nicht nur erwartet, daß er logisch richtig denkt, seine Werkzeuge beherrscht und gute Programme schreibt. Er muß gleichzeitig seine gefühlsmäßigen, sowohl intuitiv als auch durch Denkoperationen erarbeiteten Erkenntnisse mit dem Umfeld seines Systems in Einklang bringen und als vollwertiger Partner eng mit seinem Auftraggeber zusammenarbeiten .

Leider sind oft schon die Grundbestandteile der Systemanforderungen und somit die konzeptuellen Bausteine eines Systems verworren, unklar und ungenau. Es sind gerade diese Unklarheiten, die zu mangelnder Qualität und teuren Fehlentwicklungen führen. In dieser Situation ist es fatal, wenn der Systementwickler sich einem aktiven, empathiegeprägten Mitdenken entzieht.

Man scheint stillschweigend anzunehmen, daß wir uns die Fähigkeiten für die Beherrschung des enormen Vorrats an technischen Mitteln rasch aneignen können. Das amerikanische Modewort Training (gleich "Dressur"!) sagt alles aus über die seichte Art, in der man über die Fragen der Ausbildung, des Verständnisses und der Befähigung im Umgang mit neuer Technologie denkt. Auch in den Universitäten wird das Problem wie eine sich ständig und radikal ändernde Technologielandschaft praktisch beherrscht werden kann, umgangen.

Hunderte von inkompatiblen Tools

Die Design-Methodik steckt heute noch in den Kinderschuhen. Der Markt ist aber bereits überflutet durch Hunderte von hoffnungslos inkompatiblen auf den verschiedensten Methoden basierenden CASE-Tools. Die Ausreifung dieser Produkte in den nächsten Jahren wird zweifelsfrei eine Verbesserung bei der Qualität der Software produkte und des Entwicklungs prozesses nach sich ziehen. Dann werden

- bessere Prototyping-Werkzeuge die Zeiten zwischen Spezifikation, Modellierung und Realisierung von Systemen verkürzen (zum Beispiel mittels direkt ausführbarer Spezifikationen),

- bessere formale und grafische Design-Werkzeuge die Systemmodellierung erleichtern,

- Projektplanungs- und -steuerungsmethoden die Einhaltung von Qualitätstandards ermöglichen .

Harte, formale Spezifikationsmethoden lehnen sich an die Mathematik an, die ja die unzweideutigste Sprache ist, über die wir verfügen. Mathematische Systembeschreibungen können zwar für Laien schwer verstehbar sein, haben aber den Vorteil, daß ihre Implementation weitgehend automatisiert wird, wir sie also direkt am Computer ausführen können.

Weichere, halbformale Spezifikations- und Modellierungsmethoden wie Datenflußdiagramme, Entity/Relationship- oder Niam-Diagramme haben den Vorteil, daß sie leicht zu verstehen sind und konzeptuelle Schemata in grafischer Form sichtbar machen; sie sind jedoch nur partielle Spezifikationen, beschreiben also lediglich das Informationsmodell oder die Datenflüsse beziehungsweise Prozesse.

Die Entwicklung von Informationssystemen erfordert die Modellierung von Daten und Prozessen. Dabei bilden die Daten den stabilen Kern des Systems im Gegensatz zu den Prozessen, die in der Zeit sehr stark variieren können. Dies ist der Grund für die starke Datenorientierung und die Hervorhebung von Informationsanalyse-Methoden in der modernen Systementwicklung.

Unabhängig vom DBMS und von der Hardware

Datenbank Modellierung ist eine anspruchsvolle Aufgabe, die sich auf drei Abstraktionsebenen abspielt: auf einer konzeptuellen, einer logischen und einer physischen Ebene. Zunächst wird der jeweilige Ausschnitt der Funktionen beschrieben, die mit der Datenbank operieren sollen. Auf dieser Grundlage läßt sich dann ein vollständiges, unzweideutiges Abbild des jeweiligen Realitätsausschnitts entwickeln. Dieses konzeptuelle Schema ist eine Beschreibung der Datenbankstruktur auf der höchsten Abstraktionsstufe.

Das Schema existiert sinnvollerweise isoliert von allen Implementationsfragen, also von Belangen wie der Art des später zu wählenden DBMS oder der Hardware, auf der die Datenbank betrieben werden soll. Gegenstand der Beschreibung ist der Informationsgehalt der Datenbank und nicht die Speicherstrukturen, die für das Betreiben der Datenbank notwendig sein werden.

Erst in weiteren Schritten werden die einem spezifischen DBMS entsprechenden logischen und physischen Strukturen entwickelt. Durch moderne CASE- Tools kann dieser Prozeß wesentlich rationalisiert werden - insofern, als ein solches Werkzeug über eine Design-Datenbank (Meta Datenbank) verfügt, in der das konzeptuelle Schema der Daten und der Funktionen sowie weitere wichtige Systemkomponenten wie Datensichten, Anwendungen und Zugriffsrecht gespeichert werden.

Software-Entwicklung ist heute eine vielschichtige Tätigkeit, die sich auf verschiedenen Abstraktionsebenen abspielt und zeitlich in Phasen gegliedert werden muß. Je länger das Zeitintervall zwischen der Anforderungsspezifikation und der Lieferung eines validierbaren Softwareprodukts, desto größer das Risiko, daß die gelieferte Software nicht der gestellten Aufgabe entspricht.

Hier greifen neue Methoden wie das strukturierte Prototyping an. Dessen Ziel besteht darin, die Konformität der Implementation mit der Spezifikation zu sichern, indem die Entwicklungszeit verkürzt und das Systemmodell so früh wie möglich validiert wird.

Die Erwartungen der Auftraggeber konzidieren mit den Leistungen der Entwickler dann, wenn der Spielraum für Mißverständnisse im Entwicklungsprozeß so weit wie möglich reduziert wird. Prototyping hat

gegenüber anderen Entwicklungsverfahren zwei wesentliche Vorteile. Zum einen werden die Anforderungen anhand des Systemmodells abgeklärt; zum anderen erhöht sich die Produktivität.

Es wird im Prototyping durchaus akzeptiert, daß der Auftraggeber zunächst seine Bedürfnisse nicht eindeutig definieren kann und er seine Meinung während der Entwicklung ändert. Am Ende des Entwicklungszyklusses sind sich der Entwickler und der Auftraggeber jedoch über die Systemanforderungen im klaren und verfügen über eine Aufforderungsspezifikation höchster Qualität.

Mit einer qualitativ hochstehenden Anforderungsspezifikation wird die Validierung beschleunigt. Außerdem läßt sich die Realisierungsphase verkürzen, indem wesentliche Teile des Prototyps in das Produktionssystem übergehen.

Die Quantität der Qualität

Die Probleme, um die es bei der Meisterung der Softwarequalität geht, sind letzten Endes menschlich. bei der Herstellung von Software handelt es sich nach wie vor um eine handwerkliche, personalintensive Tätigkeit. Da der Mensch also eine große Rolle spielt, haben Entdeckung und Korrektur von menschlichen Fehlern hohe Priorität. Reviews, Inspektionen und Funktionsprüfungen der Produktionen sind nützlich, wenn sie während des gesamten Entwicklungszyklus vorgenommen werden; sie allein können jedoch die Qualität nicht sichern .

Eine Quantifizierung der Softwarequalität erfordert die Festlegung von Kriterien, nach denen die Qualität bemessen werden soll. Zunächst können wir die externen, also die vom Standpunkt des Benutzers aus wahrgenommenen, Eigenschaften der Software betrachten. Diese äußeren Faktoren - zum Beispiel Effizienz, Wartbarkeit und Portabilität - werden weiter unterteilt in Kriterien, die die inneren Eigenschaften der Software widerspiegeln.

Die Identifizierung dieser Kriterien zeigt den Entwicklern an, welche internen Charakteristiken der Software auf welche äußeren Faktoren einen Einfluß haben. Schließlich können wir jedes Kriterium mit einem meßbaren Attribut (Metrik) verbinden, das als Qualitätsmaßzahl dient.

Ein gutes Qualimetrie-Modell wird aber nicht nur die Qualität der Software an sich, sondern auch das Herstellungsverfahren in Betracht ziehen. Die Qualität des Herstellungsverfahrens bezieht sich auf die angewendeten Methoden und die Projektführung (zum Beispiel hinsichtlich Kosten- und Zeitgerechtigkeit). Beide Aspekte, das Softwareprodukt und sein Herstellungsverfahren, sind Teile einer notwendig ganzheitlichen Qualitätsbetrachtung.

Es liegt mir fern, ein allgemeingültiges Rezept abzugeben, wie Softwarequalität erreicht werden kann. Ich will aber vor allem darauf hinweisen, daß Qualität an sich weder durch Reviews noch durch Validierungen und Testläufe erreicht werden kann. Qualität ist eine der Software einverleibten Eigenschaft; sie hängt im wesentlichen von der Motivation, Kompetenz und inneren Einstellung jener Menschen ab, die Soft ware produzieren.

Die Qualität als normierender Wert einer Organisation und als Leitbild ihrer Mitarbeiter muß von den Unternehmensführungen besser gefördert werden. Qualität läßt sich nicht einkaufen. Sie fängt in den Köpfen der Strategen an und hat mit der Findung und Durchsetzung einer unternehmensweiten Ethik zu tun.

Wir müssen uns überzeugen, daß mehr als jemals vorher eine Kultivierung und weniger eine Überwachung der Qualität not tut. Es reicht nicht aus, um Validierungsmethoden und Qualimetriemodelle zu wissen. Vielmehr hängt der qualitative Erfolg auch an den in der täglichen Entwicklungspraxis nützlichen Prinzipien wie:

- Sicherung des Realitätsbezugs der geplanten Software,

- Arbeiten in kleinen, hochqualifizierten Teams,

- partizipative Entwicklung mit enger Zusammenarbeit von Auftraggeber und Entwickler,

- Ersatz voluminöser Spezifikationen durch formale Daten- und Prozeßmodelle sowie praktisch bewertbare Prototypen,

- Kultivierung der Entwicklungsqualität,

- Qualitätssicherung in allen Phasen des Software-Lebenszyklus

- Vorgehen in kleinen, überschaubaren Schritten,

- Pflege des Weitblickes und des Verständnisses für Zusammenhänge.

Ich möchte behaupten, daß viele Softwareprojekte in Katastrophen kulminieren, weil Auftraggeber und Entwickler mit einem einseitig auf bestechend reiner Logik basierenden Konzept - mangels praktischer Interpretation und Wertung des Projekts - in unlösbare Schwierigkeiten geraten.

Schlüssige, aber erfahrungswidrige Logik kann man beliebig konstruieren. Die Fehlschlüsse werden erst bei einem Vergleich mit der praktischen Erfahrung erkannt.

Wir können deshalb keinen Maßstab für die Güte einer Software gewinnen, wenn wir sie nicht in der Praxis prüfen. Darin liegt die besondere Bedeutung moderner partizipativer und Prototyp-basierter Entwicklungsmethoden für die Qualitätssicherung.