Dr. Christian Maurer, FU Berlin

Allgemeines zur Systemanalyse

Vor dem Einstieg in ein größeres Programmiervorhaben sind gründliche Untersuchungen darüber erforderlich, welche Teile eines gegebenen komplexen Bereichs sich mit vertretbarem Aufwand durch einen Rechner erledigen lassen. Dazu gehört im Laufe der Beschaffung der notwendigen sachlichen Hintergrundinformationen die Analyse der Datenflüsse und der funktionellen oder organisatorischen Abläufe des Systems, das automatisiert werden soll. Derartige Untersuchungen bilden die notwendigen Voraussetzungen für bei der Konstruktion des Softwaresystems. In der industriellen Produktion von Software bilden sie die Grundlage für die Kalkulation der Entwicklungskosten und damit für einen der Faktoren der Preisgestaltung.

Daneben steht der Dialog zwischen den Systemanalytikern und den Auftraggebern (oder späteren Benutzern) über konkrete Ausformungen von Details des geplanten Systems, eventuell die Erstellung von Prototypen zur Klärung von Fragen zur Gestaltung der Benutzeroberfläche oder zum Systemverhalten. Daß dieser Dialog manchmal mit Verständigungsproblemen behaftet ist, ergibt sich aus den unterschiedlichen Sichtweisen von Systemanalytikern und Benutzern, die sich meist als Laien gegenüberstehen: Softwaretechniker müssen sich oft erst in die Materie einarbeiten und Fachwissen erwerben, Benutzer haben häufig unscharfe Vorstellungen über die Möglichkeiten und Grenzen des Rechnereinsatzes.

Rücksichtnahme auf die Wünsche und Abstimmung auf die Gewohnheiten der vorgesehenen Benutzer bedingen zwar zunächst einen gewissen Mehraufwand bei der Entwicklung; die Folge ist aber eine höhere Akzeptanz des automatisierten Systems durch stärkere Anlehnung an die vorhandenen und bessere Einbettung in die durch den DV-Einsatz veränderten Strukturen. Auch bei der Herstellung und Weiterentwicklung von Software für den Massenmarkt ist die Rückkopplung mit den Vorstellungen der Benutzer ein Leitgedanke: angemessenene Reaktionen auf das Echo des Marktes und die Konkurrenzprodukte entscheiden über Erfolg und Lebensdauer eines Softwaresystems.

Im Zuge der Systemanalyse kristallisiert sich die Aufgabenstellung genauer heraus, als das bei der Festlegung des Projektthemas möglich und sinnvoll war. Mitunter stellt sich bei der vertieften Beschäftigung mit den Sachfragen auch heraus, daß das ursprüngliche Konzept modifiziert werden muß.

Kennzeichnend für die Anfangsphase der Projektarbeit ist eine deutliche Tendenz zur Unterschätzung der Komplexität der zu bewältigenden Probleme, folglich zu unrealistischen Erwartungen über die Größenordnung des Erreichbaren. Auch die Einsicht, daß sich nicht jeder Aspekt des Systems zur automatischen Bearbeitung eignet, wächst erst mit dessen fortschreitender Analyse: die Realisierung mancher Idee erweist sich bei näherem Hinsehen als zeitlich zu aufwendig, als mit der vorhandenen Hardware nicht durchführbar oder als prinzipiell fragwürdig, weil viele Tätigkeiten von Menschen effizienter als von Maschinen erledigt werden können oder weil deren Delegierung an Maschinen nicht verantwortbar ist.

In die Überlegungen müssen auch die Rückwirkungen des Rechnereinsatzes einbezogen werden: sie können die Struktur des betrachteten Systems durch die Umstellung auf automatische Datenverarbeitung eventuell verändern, und damit bereits die Aufgabenstellung gravierend beeinflussen.

Der Aufwand für die Systemanalyse sollte in der Regel in engen Grenzen gehalten werden: die Zeit für die tiefere Erarbeitung von Spezialwissen ist nicht vorhanden und der Schwerpunkt der Projektarbeit liegt bei informatischen Fragestellungen. Die Systemanalyse kann daher in einem Lehrprojekt nur als Sachanalyse einer weitgehend vereinfachten Themenstellung begriffen werden. Folglich ist es sinnvoll, das Thema für das Projekt vorzugeben, so daß sich der Gestaltungsspielraum der Teilnehmer auf die Analyse einiger weniger Objektklassen und die detaillierte Ausarbeitung der Aufgabenstellung konzentriert.

Dem Ziel der Vermeidung langwieriger und in der Regel wenig fruchtbarer Diskussionen über in Frage kommende Projektthemen dient die Rolle der Projektleitung vor und während dieser Phase des Softwarelebenszyklus: sie ist für die Abschätzung des Volumens der anfallenden Arbeit und damit für die Kalkulation der zeitlichen und personellen Ressourcen und deren Einhaltung verantwortlich. Daher muß sie - im Grunde ähnlich wie in der kommerziellen Softwareentwicklung - zwingend

Neben der grundsätzlichen Forderung auf angemessene Kleinheit und Überschaubarkeit des Themas (kleines Thema, noch kleineres Thema, noch kleiner, noch kleiner, ... ) ist eine gewisse Mindestkomplexität unverzichtbar, um für die Softwaretechnik typische Prinzipien und Methoden aufzuzeigen und Einsicht in ihre Notwendigkeit zu vermitteln:
  • angemessen tiefe Beschäftigung mit einer Anforderungsdefinition, insbesondere mit Fragen der Benutzerführung,
  • Einbeziehung einer über mindestens drei Ebenen verschachtelten Struktur der beteiligten Datenobjekte, die an mindestens einer Stelle verzweigt ist, damit eine nichttriviale Tiefe und Verzweigung in der Modulhierarchie,
  • Berücksichtigung der Möglichkeit alternativer Implementierungen zu gegebenen Systemteilen,
  • beispielhafte Erstellung von wiederverwendbaren Softwarebausteinen, die die Teilnehmer später im Unterricht einsetzen können.

Christian Maurer, 10.5.1999