Die Adaptierbarkeit eines Software-Systems ist nicht nur ein Kriterium des Softwareprodukts, sondern mindestens ebensosehr des Herstellungsprozesses. Im ersten Teil ihres Beitrags beschäftigten sich
Udo Bittner, Johanes Schnath und Wolfgang Hesse mit den Auslösern und der Verteilung von Software-Änderungen. Im zweiten Teil untersuchen sie die Einflußfaktoren auf die Produktqualität.
Im Rahmen des vom BMFT geförderten "Interdisziplinären Projektes zu r Arbeitssituation in der Software-Entwicklung" (IPAS) wurde Software-Entwicklern die Frage gestellt, was das von ihrem Projektteam bearbeitete Gesamtprodukt besonders gut respektive schlecht macht. Dabei war keine Antwort vorgegeben; vielmehr konnten die Befragten ihre Ansichten frei darlegen. Die Antworten wurden nach Kategorien aufgeteilt und ausgezählt.
Bei einigen Nennungen handelt es sich eher um Produkteigenschaften, bei anderen um Maßnahmen - wie beispielsweise den Methodeneinsatz. Es zeigte sich, daß von den Entwicklern ein und desselben Projekts das gemeinsam bearbeitete Produkt weitgehend einheitlich charakterisiert wurde. Selten wurden mehr als zwei zentrale Merkmale genannt.
Als Hauptgründe für, gute Änderbarkeit ihres Produkts nennen Software-Entwickler einen sauberen Entwurf beziehungsweise eine klare -und modulare Architektur des Gesamtsystems. Umgekehrt sind schlechte Entwürfe beziehungsweise eine schlechte Architektur Hauptgründe für eine geringe Adaptierbarkeit.
An zweiter Stelle der positiven Einflußfaktoren steht der Einsatz von Werkzeugen, hauptsächlich Generatoren. Unter dem dritten Punkt "Tabellensteuerung" wurden in erster Linie die Auslagerung der Ablaufsteuerung und der Maskenbeschreibungen aus dem Programmcode genannt. Dieser ei gentlich unter "Entwurf/Architektur" einzuordnende Punkt wurde gesondert betrachtet, da er einen wichtigen, deutlich von den übrigen Nennungen abgrenzbaren Teilaspekt darstellt.
Dabei fiel auf, daß sich der Einsatz einer Tabellensteuerung in keinem Fall negativ ausgewirkt hat.
Im Gegensatz dazu lag eine niedrige Änderbarkeit bisweilen durchaus am Einsatz eines falschen Werkzeugs oder eines falschen Sprache. Auf Qualitätssicherungs-Maßnahmen ließ sich eine erhöhte Änderbarkeit offenbar in keinem Fall zurückführen.
Als Ergänzung zu diesen Aussagen wurden die Entwickler gefragt, ob es einen Punkt, eine Entscheidung oder eine Maßnahme im Entwicklungsprozeß gegeben hat, von der man sagen konnte: "Ab hier wurde es deutlich besser oder schlechter mit der Änderbarkeit." Aus den Antworten lassen sich Hinweise ableiten, auf welche Weise die Projektleitung am ehesten wirksam eingreifen kann.
Im wesentlichen gibt es zwei zentrale und gleich häufig genannte Maßnahmen - ein explizites Re-Design und die Einführung von Werkzeugen. Bei letzteren handelt es sich in erster Linie um Projektbibliotheken oder Data-Dictionaries.
Von negativen Ereignissen wurde in diesem Zusammenhang nicht berichtet - abgesehen von einem Fall, in dem fast alle mit dem Projekt befaßter Entwickler total resignierten. Das betreffende Produkt wurde mehr als zehn Jahre lang "weiterentwickelt", wobei alle am ursprünglichen Design beteiligten Entwickler die Firma bereits verlassen hatten.
Eine Dokumentation existierte nur rudimentär und war obendrein in weiten Teilen veraltet. Um überhaupt Fortschritte zu erzielen, hatte das Management allen Entwicklern mittlerweile das Recht eingeräumt, jedes Modul zu ändern, falls sie dies für nötig hielten - was die letzten Reste von Übersichtlichkeit in der Architektur beseitigte.
Als besonders positiv wurden die Erfahrungen hingegen dann bezeichnet, wenn potentielle Änderungsanforderungen am Beginn des Projekts explizit berücksichtigt wurden. In einem Fall bekam ein Kernteam erfahrener Entwickler zu Projektbeginn drei Monate Zeit, um ausschließlich Werkzeuge zu programmieren, die die spätere Durchführung von Änderungen unterstützen.
Diese Tools wurden einhellig gelobt. Sogar die Anwender waren mittlerweile von der Nützlichkeit dieses Vorgehens überzeugt, obwohl sie zu Beginn eher skeptisch waren, daß hier Aktivitäten zu bezahlen seien, die dem Produkt nicht zugute kommen. (wird fortgesetzt)
Udo Bittner und Johannes Schnath sind wissenschaftliche Mitarbeiter; Wolfgang Hesse ist Professor der Informatik mit Schwerpunkt Software-Engineering an der Philips-Universität Marburg.