Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.03.1992 - 

Zur Arbeitssituation von Software-Entwicklern (3 und Schluß)

Änderbarkeit von Software - die Architektur entscheidet

Nachdem sich Udo Bittner, Wolfgang Hesse und Johannes Schnath* in den ersten beiden Teilen ihres dreiteiligen Beitrags mit den Auslösern und der Verteilung von Software-Änderungen beziehungsweise den Einflußfaktoren auf die Produktqualität beschäftigt haben, gehen sie im dritten und letzten Teil der Frage nach, was der einzelne Entwickler zur Änderbarkeit der Softwaresysteme beitragen kann.

Ein erster Hinweis auf die Wichtigkeit bestimmter Produkteigenschaften oder die Eignung bestimmter Maßnahmen ergibt sich aus dem Verhältnis zwischen den geschilderten negativen und positiven Beispielen. Eine exaktere Aussage hierzu erhält man durch die gesonderte Betrachtung von Produkten mit guter Erweiterbarkeit und von solchen mit schlechter Erweiterbarkeit.

Unter mehreren Parametern für die Änderbarkeit erwies sich das Verhältnis des für die Anpassung der bereits bestehenden Teile notwendigen Aufwandes zum Gesamtaufwand für die Durchführung von Erweiterungen als aussagekräftigstes Kriterium.

Das Verhältnis variierte stark in den untersuchten Projekten: Im günstigsten Fall standen 80 Prozent des Aufwands für die reine Erweiterung 20 Prozent für die Anpassung der bestehenden Teile gegenüber, im ungünstigsten war das Verhältnis genau umgekehrt.

Die Projekte wurden danach gruppiert, ob der größere Teil des Gesamtaufwandes für die Erweiterung verwendet werden konnte oder aber auf die dafür notwendige Anpassung anderer Produktteile entfiel. Daraus ergaben sich zwei nahezu gleich große Gruppen.

Dabei zeigte sich bei Projekten mit günstigerem Aufwandsverhältnis deutlich mehr positive Nennungen in den Kategorien Architektur/Entwurf und Dokumentation (siehe Teil 2 dieses Beitrags in CW Nr. 10 vom 6. Februar 1992). Es ist wichtig festzuhalten, daß diese beiden Merkmale nicht voneinander abhängen. Eine gute Architektur wurde keineswegs immer gleichzeitig mit einer guten Dokumentation genannt.

Weiterhin wiesen die Projekte mit günstigerem Verhältnis einen deutlich höheren Werkzeugeinsatz auf und man war dort, auch in der Lage, die Auswirkungen von Anwenderanforderungen abzufangen, die eigentlich eine Verschlechterung der Änderbarkeit hätten bewirken müssen. Also gibt es keinen Hinweis darauf, daß sich diese beiden Einflußfaktoren gegenseitig bedingen. Bei den Projekten mit günstigerem Verhältnis wurden deutlich häufiger Werkzeuge eingesetzt. Außerdem gelang es dort, die Auswirkungen von Anwenderanforderungen abzufangen, die eigentlich eine Verschlechterung der Änderbarkeit hätten bewirken müssen. Zur Überprüfung der Schlußfolgerungen wurden die Projekte nach den Maßnahmen zur Erhöhung der Änderbarkeit gruppiert und die jeweiligen Durchschnittswerte der Aufwandsverteilungen berechnet. In die Gruppierungen aufgenommen wurden nur solche Projekte, in denen sich die Entwickler über den Grund für die gute oder schlechte Änderbarkeit ihres Produkts weitgehend einig waren.

Weiterhin trat zutage, daß ungenügende Planung und schlechtes Management des Entwicklungsprozesses sofort auf die Produktqualität durchschlagen. Das wurde auch in den Interviews immer wieder betont. Eine Detailanalyse ergab, daß einige Einflußfaktoren stets gegenüber anderen überwiegen.

Es ließen sich drei Stufen feststellen: Architektur und insbesondere Tabellensteuerung dominieren gegenüber Werkzeugeinsatz und gut organisiertem Entwicklungsprozeß, die ihrerseits wiederum gegenüber den Anwenderanforderungen dominieren. Dies bedeutet zum Beispiel, daß auch eine gute Werkzeugunterstützung die Auswirkungen einer schlechten Architektur nicht beseitigen kann, umgekehrt jedoch eine gute Architektur auch bei schlechter Werkzeugunterstützung zum Tragen kommt.

Ergänzend ist festzuhalten, daß sich unter den drei "besten" Projekten mit weniger als 25 Prozent Aufwand zur Anpassung der bestehenden Teile zwei objektorientierte Systeme und ein System mit konsequenter Datenkapselung befanden.

An dieser Stelle soll nicht versäumt werden, auf eine Tatsache hinzuweisen, die sich erst in einer Tiefenuntersuchung deutlich zeigte und die gerade bei der Realisierung von objektorientierten Systemen zu erwarten ist: Die Konzentrierung von Parametern und Funktionalität in einem zentralen Baustein bewirkt einerseits eine erhöhte Änderbarkeit, da nur an einer Stelle geändert werden muß. Andererseits bewirkt sie eine erhebliche Verkoppelung unterschiedlicher Systemteile, unter Umständen sogar mehrerer Projekte, und damit unbeabsichtigte Seiteneffekte bei Änderungen oder zumindest einen erheblichen Mehraufwand. Zentrale Bausteine weisen eine gewisse Analogie zu globalen Variablen auf und sind daher mit den gleichen Vor- und Nachteilen behaftet.

Unabhängig von den Merkmalen des Gesamtprodukts und der Durchführung des Projekts, nutzen Entwickler noch den Freiraum, bei dem von ihnen erstellten Teilprodukt besonders auf Änderbarkeit zu achten. In einigen Fällen wurde dies damit begründet, daß die Vorgaben der Projektleitung häufiger wechseln. Die persönlichen Maßnahmen werden teilweise zusätzlich oder in Abwandlung offizieller Vorgaben angewandt, wobei die Grenzen zur sogenannten "creeping elegance" fließend sind.

Die Erfassung der persönlichen Maßnahmen sollte einerseits auf besonders wirksame und eventuell wenig bekannte Techniken und Vorgehensweisen hinweisen. Andererseit hatte sie das Ziel zu überprüfen, ob eine erhöhte Änderbarkeit des Gesamtprodukts auf die Summe der individuellen Maßnahmen zurückgeht.

Auch hier rangiert die auf Änderbarkeit ausgelegte Architektur des Teilprodukts an erster Stelle. Gleichauf liegt die Dokumentation, wobei nicht die offiziell vorgeschriebenen Dokumentationen gemeint sind, sondern gerade die persönlichen Notizen und Kommentare im Programm.

Erstaunlich an der Verteilung ist aber in erster Linie, daß hier Konventionen direkt hinter Architektur und Dokumentation auf dem dritten Platz rangieren, obwohl Standards und Richtlinien relativ selten als Voraussetzung höherer Änderbarkeit des Gesamtprodukts genannt werden. Dieser Widerspruch kann damit erklärt werden, daß die persönlichen Konventionen eines Entwicklers seinen Kollegen entweder überhaupt nicht bekannt oder aber keineswegs einleuchtend sind.

Auf diese Weise kann es durchaus vorkommen, daß in einem Projekt mehrere Konzepte nebeneinander existieren, was dem Gesamtsystem kaum zugute kommt. Die Aufstellung geeigneter Standards und Richtlinien stellt somit eine von Software-Entwicklern als sinnvoll akzeptierte Maßnahme dar. Dieses Potential wird jedoch in vielen Projekten noch kaum ausgeschöpft.

Als wichtiges Ergebnis ist zu vermerken, ein Effekt der individuellen Maßnahmen auf die Änderbarkeit des Gesamtprodukts nicht feststellbar war. Die Einflußfaktoren auf die Änderbarkeit eines Produkts sind somit auf dem Projektniveau zu suchen.

Von besonderem Interesse sind über diese allgemein genannten Maßnahmen hinaus die Strategien und Maßnahmen jener Software-Entwickler, die von ihren Kollegen als besonders gut eingestuft wurden. Strategien von Entwicklern wurden durch die Rekonstruktion der jeweiligen Vorgehenweise bei einer größeren Arbeitsaufgabe ermittelt.

Bei einem Vergleich dieser Rekonstruktionen konnten einige zentrale Strategien festgestellt werden:

- Einige Entwickler führen erst alle Erweiterungen durch, die sich über den Einbau eines Parameters in die bestehenden Programme lösen ließen; dann testen sie diese Erweiterungen mit einem Testprotokoll gründlich aus. Anschließend werden die die Spezialfälle in einem Zusatzprogramm behandelt. Kurz: Es wird erst nach einer möglichst allgemeinen Lösung gesucht und diese realisiert.

- Bisweilen verwenden die Entwickler über 50 Prozent der Zeit für die Abklärung der Aufgabe, bevor sie mit der Realisierung beginnen. Dabei werden auch häufiger mehrere Lösungsvorschläge erarbeitet und Konsequenzen durch die Realisierung der einen oder anderen Anforderung herausgestellt.

- Tätigkeiten, die aller Wahrscheinlichkeit nach häufiger durchgeführt werden müssen, werden von manchen Entwicklern routinisiert und durch kleine selbstgeschriebene Werkzeuge automatisiert. Diese Werkzeuge werden von den jeweiligen Entwicklern gleich dokumentiert und bekanntgemacht, damit sie auch von anderen verwendet werden können.

- Auch Besprechungen mit Kollegen gehören zu den genannten Strategien. So läßt sich überblicken, wer in welcher Weise von dieser Änderung betroffen sein würde.

- Ein neues Modul wird manchmal ähnlich wie bestehende Module konzipiert, auch wenn es eine bessere Lösung für diesen Fall gegeben hätte. Bedingung dafür ist, daß die bestehende Software bereits "Recycling-fähig" geschrieben war oder spätestens an dieser Stelle daraufhin überarbeitet wurde. In einem Fall suchte ein Entwickler so lange nach Gemeinsamkeiten, bis er einen Treiber "plündern" konnte, um den Kern eines zweiten zu erstellen. Die "Auslagerung von Gemeinsamkeit" wird auch mit besserer Lesbarkeit begründet.

Die "guten" Software-Entwickler konzentrieren sich insgesamt darauf, das Wissen, das im Zusammenhang mit Änderungen von Bedeutung ist, vorher möglichst genau abzuklären und anschließend auf geeignete Art und Weise festzuhalten sei es durch den einheitlichen Aufbau von Modulen, durch Auslagerung gemeinsamer Teile oder durch das Festhalten von Tätigkeiten in Form selbstgeschriebener Werkzeuge.

Insgesamt zeigt sich jedoch, daß ein Produkt mit hoher Änderbarkeit nicht allein aufgrund des individuellen Einsatzes einzelner Entwickler entsteht, sondern nur durch Koordination. Es ist also eine zentrale Aufgabe der Projektleitung, Maßnahmen in die Wege zu leiten, die zu einem flexiblen Produkt führen.

*Udo Bittner und Johannes Schnath sind wissenschaftliche Mitarbeiter, Wolfgang Hesse ist Professor der Informatik mit Schwerpunkt Software-Engineering an der Philips-Universität Marburg.