3.2 Ansätze

3.2.1 Wissensarten: Modell, Methode, Werkzeug

Es gibt drei Wissensarten, in denen wissenschaftliche Beiträge zur Softwaretechnik zu erbringen sind:

1.

Modelle. Ein Modell ist eine vereinfachte abstrakte Repräsentation eines Teils der wirklichen Welt. Der Zweck von Modellen besteht darin, das Verständnis des modellierten Sachverhalts zu verbessern und insbesondere Vorhersagen über sein Verhalten zu treffen. Ferner sind Modelle das Hauptmittel zur Organisation einzelner Wissensteile in ein verständliches Ganzes. Modelle sind deshalb in allen Wissenschaften Bindeglied oder sogar Grundlage aller weiteren Beiträge.

2.

Methoden. Eine Methode ist eine allgemeine Anleitung zum Lösen einer Klasse von Problemen. Im Gegensatz zu einem Algorithmus muß eine Methode das Vorgehen nicht unbedingt prozedural und auch nicht vollständig beschreiben. Methoden bilden gewissermaßen das Herz der Softwaretechnik, denn ihre zentrale Frage ,,Wie erstelle ich am besten Software¿` ist eine Methodenfrage.

3.

Werkzeuge. Die praktische Nützlichkeit von Methoden hängt ganz erheblich vom Aufwand ihrer Anwendung ab. Werkzeuge können diesen Aufwand erheblich reduzieren. Sie stellen dann eigene Beiträge zum Wissen dar, wenn entweder bekannt ist, wie oder warum ein bestimmtes Werkzeug nützlich ist (weil dann vom einzelnen Werkzeug abstrahiert werden kann, was zur Modellbildung beiträgt) oder wenn damit erstmalig die praktische Anwendbarkeit einer annerkannterweise im Prinzip nützlichen Methode hergestellt wird.

Das ist alles. Mehr gibt's nicht.

In der Softwaretechnik ist beispielsweise das Phasenmodell und seine Abarten die Kommunikations- und Verständnisgrundlage für zahlreiche Effekte bei der Entwicklung von Softwaresystemen. Es prägt eine einheitliche Grundterminologie (z.B für die Bezeichnungen und Aufgaben der Phasen), ordnet Wissenselemente an (anhand der Disjunktheit der Phasen) und ist die Grundlage für Vorhersagen, z.B. des Zeitbedarfs. Sprachen sind häufig ebenfalls Modelle, nämlich von bevorzugten Problembeschreibungsmethoden, z.B. imperativ oder deklarativ.

Aus einem anderen Blickwinkel ist das Phasenmodell eine Methode. Es ist eine Anleitung, die beschreibt, was wann zu tun ist. Sprachen (samt ihrer Übersetzer), die im Prinzip Modelle sind, kann man in ähnlicher Betrachtung als Werkzeuge ansehen; maschinelle Hilfen zur Bearbeitung und Lösung von Problemen. Eine solche Doppelsicht kommt oft vor, weil sich hinter jedem Werkzeug und jeder Methode irgendwo ein Modell versteckt.

3.2.2 Arten von Beiträgen

Ein wissenschaftlicher Beitrag in der Softwaretechnik hat immer einen der folgenden Typen (oder eine Mischung von mehreren):

1.

Existenzbeweis. Oftmals ist für ein bestimmtes Problem überhaupt noch keine Lösung bekannt. Dann ist eine praktikable Lösung, die gefunden wird, in jedem Fall ein wissenschaftlicher Beitrag, weil sie beweist, daß das Problem sinnvoll lösbar ist. Dies ist zunächst weitgehend unabhängig von der Nützlichkeit dieser Lösung.
Beispiel: Wenn das erste Mal eine komplette mathematisch-formale Spezifikation einer Programmiersprache vorgelegt wird, beweist das, daß Programmiersprachen nicht unbedingt Eigenschaften haben müssen, die eine vollständige formale Definition ausschließen. Dies ist ein wissenschaftlicher Beitrag auch dann, wenn diese Spezifikation weniger nützlich sein sollte als eine ,,normale`` oder die Nützlichkeit ungeklärt bleibt.

2.

Offensichtliche Verbesserung. Manchmal kann ein alternativer Ansatz zur Lösung desselben Problems so offensichtlich besser sein als ein bisheriger, daß sein reines Vorstellen, ähnlich wie beim Existenzbeweis, ein wissenschaftlicher Beitrag ist.
Beispiel: Die Erfindung des Volltexteditors als Verbesserung des Zeileneditors.

3.

Theorem. Eine nützliche theoretische Aussage ist ein wissenschaftlicher Beitrag, wenn diese Aussage mathematisch bewiesen werden kann.
Beispiel: Berechenbarkeitstheorie. ,,Versuche nicht, ein Werkzeug zu bauen, das automatisch alle Endlosschleifen identifizieren kann, denn so etwas ist unmöglich.``

4.

Validierter Entwurf. In der überwiegenden Zahl der Fälle haben Beiträge in der Informatik die Form eines Entwurfs: ein Algorithmus, eine Programmiersprache, ein Werkzeug, eine Entwurfsmethode, ein Modell etc. Solche Entwurfsbeiträge sind in beliebiger Zahl mit geringem Aufwand herzustellen. Sie können deshalb nur dann als wissenschaftliche Beiträge (also Beiträge zum Wissen) gewertet werden, wenn ihre Nützlichkeit nachgewiesen wird: eine Programmiersprache muß ausdrucksstark sein, Programmiersprachen, Werkzeuge und Methoden müssen Produktivität oder Qualität erhöhen, Modelle oder Theorien müssen realistische Aussagen machen. Häufig wird dieser Nachweis die Form haben, daß eine Eigenschaft für den Entwurf behauptet und ihr Vorhandensein dann nachgeprüft wird (Hypothesentest). Den höchsten wissenschaftlichen Wert haben dabei Modelle, weil sie am meisten Wissen liefern bzw. repräsentieren, gefolgt vom Methoden, gefolgt von Werkzeugen. Beachte, daß meist mehrere Komponenten gemischt einen Beitrag bilden. Hypothesentests können auch losgelöst von einem Neuentwurf stattfinden (also pure Validation).

5.

Eigenschaftsbeweis. Oft können nicht alle behaupteten Eigenschaften eines Entwurfs in der ersten Arbeit nachgewiesen werden oder es werden erst später zusätzliche Eigenschaften entdeckt. Eine Art von Forschungsbeiträgen besteht deshalb darin, eine Validation einer Eigenschaftsbehauptung zu einem schon vorher bekannten Entwurf zu liefern.
Beispiel: Bei Verwendung von Methode X entdecken gut geschulte Programmierer meist mehr als die Hälfte aller ihrer Fehler schon vor dem Test.

6.

Vergleich. Wenn alle Beiträge eine der obigen Formen hätten, stünden viele Ideen zur Lösung der gleichen Probleme nebeneinander, ohne daß man ihre relative Nützlichkeit beurteilen könnte. Vergleiche zwischen Modellen, Methoden oder Werkzeugen schließen diese Lücke. Solche Vergleiche können auf empirischer oder (seltener) auf theoretischer Basis erfolgen.
Beispiel: In welchem Programmierparadigma machen Programmierer die wenigsten Fehler (rein prozedural, prozedural objektorientiert, funktional) und was für Fehler sind das jeweils?
Vergleiche sind neben dem Hypothesentest bei validierten Entwürfen die wichtigste Grundlage zur Formulierung neuer Modelle und Theorien und nehmen insofern eine Schlüsselstellung im Wissenschaftsprozeß ein.

Beiträge, die zu keinem dieser Typen gehören, sind keine wissenschaftlichen Beiträge in dem Sinne, daß sie unmittelbar gesichertes Wissen liefern. Sie können eventuell dennoch nützliche Beiträge sein, indem sie den Wissenschaftsprozeß anregen. Häufiger jedoch findet man leider Forschungsarbeiten, die weder einen nennenswerten direkten noch einen indirekten Beitrag zum Wissen liefern.

3.2.3 Forschungsmethoden

Zur Erbringung eines wissenschaftlichen Beitrags in der Softwaretechnik gibt es nur wenige Klassen von Forschungsmethoden, aus denen geschöpft werden kann:

1.

Entwurf und Bau. Entwurf und Bau eines Softwaresystems oder der Entwurf eines Modells oder einer Methode stellen gelegentlich einen eigenen wissenschaftlichen Beitrag dar, im Sinne eines Existenzbeweises oder einer offensichtlichen Verbesserung. In der großen Mehrzahl der Fälle jedoch sind diese beiden Forschungsmethoden nur Teilmethoden, da der hergestellte oder implementierte Entwurf noch validiert werden muß.

2.

Mathematischer Beweis. Mathematische Beweise sind die Hauptmethode für die Beitragsart Theorem, sind aber auch oftmals als Hilfsmethode an anderen Stellen nützlich.

3.

Kontrolliertes Experiment. In einem kontrollierten Experiment wird eine klar formulierte und sehr enge Forschungsfrage untersucht und, sofern das Experiment richtig entworfen und durchgeführt wird, auch recht klar beantwortet. Die Bezeichnung ,,kontrolliert`` stammt daher, daß hier versucht wird, für alle relevanten Faktoren wohldefinierte Verhältnisse herzustellen, was die Voraussetzung dafür ist, eine zuverlässige Aussage zu bekommen. Dies wird entweder durch Festhalten des Faktors auf einem bestimmten Niveau erreicht oder durch Randomisierung (Zufallsauswahl) über eine Menge (Grundgesamtheit) von Individuen, die betrachtet werden sollen. Letztere Methode ist fast immer nötig, wenn Menschen im Spiel sind, weil deren Eigenschaften nicht genau genug gemessen, geschweige denn fixiert werden können. Über kontrollierte Experimente folgt weiter unten ausführliche Information.

4.

Fallstudie. Eine komplette Validation eines Entwurfs ist in sehr vielen Fällen außerordentlich schwierig zu bewerkstelligen. Denken sie beispielsweise an die Aussage ,,Das Spiralmodell halbiert die Gefahr von Fehlentwürfen oder über 30prozentigen Terminüberschreitungen gegenüber dem Phasenmodell (Wasserfallmodell) bei Projekten von mehr als 10 Personenjahren Umfang``. Um eine solche Aussage komplett zu validieren müßte man also eine größere Zahl von solchen großen Projekten (vielleicht etwa 10) zweimal durchführen, je einmal mit dem Spiralmodell und mit dem Phasenmodell und zwar jeweils mit Teams vergleichbarer Qualifikation für das Projekt. Dies ist offensichtlich unbezahlbar. In derartigen Situation nimmt man Zuflucht zu Fallstudien als Validationsersatz. In Fallstudien wird eine kleine Zahl von Versuchen mit dem Entwurf ausgewertet. Um die geringe Zahl auszugleichen, werden im Gegensatz zu anderen empirischen Methoden auch die nichtobjektiven Beobachtungen in die Ergebnisse einbezogen und vorsichtig in Bezug auf die zu untersuchenden Aussagen hin interpretiert.

5.

Feldbeobachtung. Eine Zwischenposition zwischen Experimenten und Fallstudien nehmen Beobachtungen im Feld ein, also Beobachtungen an realen Entwicklungsprojekten. Anders als bei Fallstudien liegt hier oft eine genügend große Zahl von Beobachtungen vor, so wie es bei Experimenten ebenfalls nötig ist, um die Effekte der Randomisierung auszugleichen. Im Unterschied zu Experimenten ist aber bei Feldbeobachtungen keine Kontrolle über die Umgebungsfaktoren gegeben, so daß die Beobachtungen von Effekten anderer Variablen als der zu beobachtenden ,,verschmutzt`` sind. Wenn man abschätzen kann, welche Variablen dies sind, stellen aber auch Feldbeobachtungen wertvolle Forschungsbeiträge dar.

  
3.2.4 Forschungsfelder

Die derzeit bearbeiteten Forschungsfragen lassen sich ungefähr wie folgt in Felder innerhalb der Softwaretechnik einordnen. Die Felder sind natürlich nicht disjunkt und anders gestaltete Einteilungen könnten ebenso sinnvoll sein. Die Auflistung soll nur eine ungefähre Übersicht über die Themen vermitteln, die derzeit in der Softwaretechnik-Forschung von Bedeutung sind. Für die meisten der Fragen existiert ein gewisses Teilwissen, aber bei kaum einer gibt es Antworten, die auch nur entfernt als endgültig angesehen werden sollten.

• Anforderungsanalyse. Wie kommuniziert man mit dem Anwender? Wie setzt man vage Anforderungen (Benutzerfreundlichkeit, Sicherheit) in konkrete um? Wie versteht man Prioritäten und Zufriedenheitskriterien des Anwenders? Wie stellt man Eindeutigkeit und Vollständigkeit sicher? Wie verteilt man Aufgaben zwischen System und Anwender?
  Querbezüge zu Spezifikation, Entwurf, Dokumentenverwaltung.
• Spezifikation. Wie integriert man verschiedene Sichten und Darstellungen? Welche Darstellungen sind effizient und fehlerarm handhabbar? Warum? Welche erlauben die Verfolgung von Anforderungen? Welche sind anwendertauglich? Warum? Wie prüft man Eindeutigkeit und Vollständigkeit?
  Querbezüge zu Anforderungsanalyse, Entwurf, Dokumentenverwaltung.
• Entwurf. Wie evaluiert man verschiedene Entwurfsansätze? Wie findet man einen guten Entwurf in Bezug auf Fehler, Implementationskosten, Implementationsgeschwindigkeit, Produkttestbarkeit, Produktwartbarkeit? Wie prüft man diese Qualität? Welche wiederkehrenden Muster in Entwürfen lassen sich entdecken? Warum? Welche Formalismen sind zur Darstellung von Entwürfen günstig? Warum? Wie dokumentiert man Anforderungen und Entwurfsentscheidungen?
  Querbezüge zu allen anderen Feldern.
• Implementation. Welche Sprachen haben die höchste Produktivität, die geringste Fehlerhäufigkeit? Warum? Welche Programmierstile optimieren Effizienz, Verständlichkeit, Erweiterbarkeit, Fehlerhäufigkeit? Warum? Wie unterstützt man Verfolgung von Entwurfsentscheidungen, Anforderungen?
  Querbezüge zu Entwurf, Test, Reengineering.
• Test. Welche Testmethoden sind am effektivsten? Am effizientesten? Warum? Wie kann man das Testen automatisieren? Wie kann man Testaufbauten wiederverwenden? Wie kann man die SW-Zuverlässigkeit schätzen? Wie kann man das Fehlerlokalisieren beschleunigen?
  Querbezüge zu Entwurf, Implementation, Wiederverwendung.
• Reengineering. Wie deckt man Anforderungen, Entwurfsentscheidungen, Entwurfsstrukturen in Programmen auf, deren Anforderungs- und Entwurfsdokumente verloren oder veraltet sind? Wie stellt man die möglichen Auswirkungen einer Änderung an einer Stelle fest? Wie findet man die Stelle(n), wo man ein großes Programm ändern muß, um einen gewissen Zweck zu erreichen?
  Querbezüge zu Dokumentenverwaltung, Entwurf, Implementation.
• Dokumentenverwaltung. Wie bewahrt man Bezüge zwischen Dokumenten gleicher oder verschiedener Phasen? Wie verwaltet man Konfigurationen (Revisionen, Varianten, Familien)? Wie geht man mit unvollständiger Kontrolle über Dokumente um? Wie unterstützt man örtlich verteilte Softwareentwicklung?
  Querbezüge zu allen anderen Feldern.
• Wiederverwendung. Wie entwirft, validiert, katalogisiert man wiederverwendbare Software? Wie findet man eine Komponente? Wie entwirft, produziert, testet man mit wiederverwendbaren Komponenten? Wie wirkt sich Wiederverwendung auf Qualität, Kosten, Produktivität aus? Warum? Wie verwendet man Artefakte früher Phasen wieder (Anforderungen, Entwürfe)?
  Querbezüge zu allen anderen Feldern.
• Softwareprozeß. Wie sollte eine SW-Organisation arbeiten? Wieviel Vorschriften braucht man? Welche? Warum? Wie kontrolliert man ihre Einhaltung? Wie optimiert man das Vorgehen allmählich aufgrund von Beobachtung? Wie wirkt sich das auf die Arbeit des einzelnen aus? Wie verhindert man unerwünschte Nebenwirkungen?
  Querbezüge zu allen anderen Feldern.