Software-Entwicklung wird von zwei Problemen beherrscht: Aufwand und Qualität. Software als System zu behandeln und industriell zu erstellen, wäre ein geeigneter Weg, diese Schwierigkeiten zu lösen. Doch bisher fehlte dafür eine wirkungsvolle, lehrbare Vorgehensweise. Professor Dr. Helmut Groh von der Fachhochschule des Saarlandes, Saarbrücken, und Kurt H. Lutz von der Siemens AG München beschreiben in diesem Beitrag Möglichkeiten der durchtechnisierten Softwareerstellung. Dabei fordern sie eine stärkere Berücksichtigung der Prozeßträger und seiner Komponenten in einem System sowie der gegenseitigen Wechselwirkungen.
Die ausufernden Kosten der Programm-Erstellung haben zum Schlagwort von der Softwarekrise geführt. Ein Lösungsansatz für dieses Problem wird heute durch den Übergang von der handwerklichen zur industriellen Softwareerstellung gesehen.
Um bei den SW-Produkten mit weniger Aufwand bessere Qualität zu erreichen, muß man die Arbeitsabläufe der Erstellung rationalisieren, insbesondere aber die Fehlerrate senken. Dies gilt nicht nur für die DV-technische Realisierung, sondern ebenso für Problemanalyse, Anforderungsdefinition, Leistungsbeschreibung und Entwurf. In der Systemkonstruktion, worunter hier die kreativen Arbeitsphasen bis zur DV-technischen Realisierung verstanden werden, steckt heute noch erhebliches Rationalisierungspotential, das man mittels neuer Arbeitsmethoden und Werkzeuge zu erschließen versucht. Ziel ist das arbeitsteilig organisierte und instrumentierte Software-Konstruktionsbüro sowie ein phasenübergreifendes Methodenkonzept für die gesamte Erstellung und Anwendung (Life cycle) eines Software-Produkts. Rationalisieren der Softwareerstellung muß aber vor allem bei den Fehlerquellen ansetzen. Kostenanalysen haben zweierlei erbracht:
- Fehler, die erst bei der Anwendung festgestellt werden, verursachen 30- bis 100mal höhere Kosten als früher entdeckte Fehler.
- Bei der Anwendung entdeckte Fehler sind überwiegend in den Phasen der Problemanalyse und der Konstruktion entstanden (Abb 1).
Die Fehlerrate senken heißt bei der Software-Konstruktion zu Ergebnissen kommen, die eindeutiger, vollständiger und widerspruchsfreier sind als bisher. Außerdem muß die Qualität des Systems bereits aufgrund dieser Ergebnisse prognostizierbar sein. Damit Funktionserfüllung und Zeitverhalten unter gegebenen Randbedingungen, wie Lastprofil, Mengengerüst, konkurrierende Nutzungen der Systembasis, gewährleistet sind, muß die Konsistenz von Anforderungen und Entwürfen prüfbar sein. Dies setzt voraus, daß man die Zielumgebung des Systems als Lasterzeuger und die Systembasis (Hardware, Betriebssystem, Datenbank) einbezieht. Ihr funktionales und ihr zeitliches Verhalten müssen statistisch spezifiziert werden.
Man betrachtet also ein "geschlossenes", soziotechnisches System, in dem das Zielsystem und die Umwelt eingeschlossen sind. In einem solchen geschlossenen System laufen interaktive, parallele Prozesse ab. Die Prozesse finden in Prozeßträgern verschiedener Art statt, in organisatorischen Einheiten oder technischen Einrichtungen, in Arbeitsplatzsystemen oder Hosts, oder in interaktiver Software. Geschlossene Systeme können simulationsfähig dargestellt werden; sie sind also prognostizierbar.
Bei der Konstruktion großer und umfangreicher Systeme arbeiten viele einzelne Individuen zusammen. Ein solcher Arbeitsprozeß erfordert ein arbeitsteilig organisierbares Verfahren. Teilaufgaben müssen durch klare Schnittstellen abgrenzbar sein. Individuelle Arbeitsprozesse müssen zielorientiert gesteuert werden und zu untereinander konsistenten Ergebnissen führen. Dies setzt eine einheitliche, also lehrbare Arbeitsmethode voraus, die eine Leitlinie für die Modellierung vorgibt. Zum Darstellen der Arbeitsergebnisse benötigt man eine Sprache, die auch für den Anwender leicht verständlich sein muß. Sie sollte für Beschreibungsmodelle ebenso wie für formalisierte Modelle geeignet sein. Dies ermöglicht den kontinuierlichen Übergang zwischen Analyseergebnissen, simulationsfähigen Modellen und eindeutigen Vorgaben für die Realisierung.
Die Sprache sollte universell sein, damit sie für die Arbeit in möglichst vielen Bereichen geeignet ist; dadurch können die Mitarbeiter, die sie benutzen, flexibel eingesetzt werden. In Bild 2 sind die Komponenten der industriellen Softwareerstellung mit ihren Merkmalen dargestellt.
Ziel der Systemkonstruktion ist ein Zielsystem, das den Qualitätsanforderungen genügt. Dies in einem industriellen Verfahren effizient zu realisieren, ist ein zur Zeit noch nicht gelöstes Problem. Eine spezielle Vorgehensweise des Outside-in eröffnet allerdings neue Möglichkeiten.
Ein gerichteter Baum stellt die Standardhierarchie für Softwaresysteme dar." Diese Aussage von H. Balzert in einem Werk über die Entwicklung von Softwaresystemen trifft für die meisten heute praktizierten Verfahren zu. Baumstrukturen sind ein unentbehrliches Hilfsmittel für das Ordnen großer Mengen. Sie erleichtern insbesondere das Suchen eines Objekts oder einer Zwischenposition. Um baumartige Ordnungsstrukturen aufzubauen, entwickelt man in der Regel logische Kriterien oder Attribute, nach denen man die Objekte unterscheiden kann.
Das Raster für die jeweils abgrenzbaren Teilmengen wird dabei schrittweise verfeinert. Die Kriterien müssen so gewählt werden, daß die abgegrenzten Teilmengen nicht überlappen, was häufig nicht auf Anhieb eindeutig gelingt.
Abbildung 3 zeigt die beiden für die Softwareentwicklung typischen Grobhierarchien, je eine Baumstruktur für Daten und Programme. Die Praxis lehrt, daß es nicht einfach ist zwei derartige Baumstrukturen untereinander konsistent zu entwerfen.