Abschlussbericht

Ulrik Schroeder Praktische Informatik, TU Darmstadt
dem Ziel, an ausgewählten Beispielen eine neue Softwareentwicklungsmethodik zu
demonstrieren, die Anwender von Softwaresystemen vom ersten Moment des Projektes
an der Entwicklung aktiv beteiligt. Durch die sehr kurzfristige Mittelzuteilung war es nicht
möglich, alle drei Teilprojekte zeitgleich zu initiieren. Stattdessen bot sich an, eine
gestaffelte Bearbeitung der Teilprojekte durchzuführen, indem das vorliegende Teilprojekt
die Vision der Prototypgestaltung seitens der Anwender anhand von Referenzbeispielen
konkretisiert und die dabei ermittelten Anforderungen an den Arbeitsprozess und die
informationstechnischen Voraussetzungen an die Anwender definiert. Die anschließenden
Teilprojekte untersuchen die Realisierbarkeit der dargestellten Vision vom Standpunkt der
Arbeitsgestaltung und der informationspädagogische Prozesse, um auf die neuen
Herausforderungen geeignet vorzubereiten
Das Teilprojekt wurde als Vorläufer vor Start der anderen Teilprojekte konzipiert, da es
über die vorgeschlagene partizipative Software-Technik neue Herausforderungen an
Nicht-Informatiker stellt. Das Teilprojekt A prüft, ob und wie diese Herausforderungen in
betrieblichen Prozessen aufgegriffen werden können. Es soll die Anforderungen an den
partizipativen Software-Entwicklungsprozess auf der Grundlage der kritischen
Bildungstheorie erforschen und für die Umsetzung in Vorgehensmodellen für die
Informatik, für die Gestaltung von Lernumgebungen und für die Erstellung von
Entwicklungswerkzeugen aufbereiten.
Das Teilprojekt C beschäftigt sich mit der Entwicklung von Konzepten
informationspädagogischer Weiterbildung und berührt damit Fragestellung der Aus- und
Weiterbildung für die Anwender der vorgeschlagenen Entwicklungswerkzeuge.
3 Ziele des Teilprojektes B
Aktuell sehen alle aktuellen Vorgehensmodelle für objektorientierte Softwareentwicklung
als Ergänzung eine funktionale Definition der Systemanforderungen in Form von
Anwendungsfällen (Use Cases [Jacobsen99] bzw. Stories im xP [Beck99]) vor. Erst daran
schließen die eigentlich objektorientierten Methoden an, um die funktionalen Aspekte zu
analysieren und die an der Funktionsrealisierung beteiligten Objekte zu identifizieren.
Daraus resultieren die statischen Klassenmodelle, die die Funktionalität des Systems auf
Klassen verteilen. Die Klassenstruktur ist die Ausgangsbasis für die Implementierung, die
sich leicht auf viele Entwickler verteilen und getrennt entwickeln lässt.
Ein Problem der Analysephase besteht darin, dass die in der Informatik üblichen
Notationen ungeeignet sind, um die resultierenden Modelle adäquat mit den zukünftigen
Anwendern des Systems zu diskutieren. Auf der anderen Seite sind Anwender die
kompetentesten Vertreter der Anwendungsdomäne und müssen exakt Auskunft über die
benötigte Funktionalität des Systems und den Einsatzkontext geben.
Als Ausweg schlagen wir vor, die Use Cases bzw. ihre Konkretisierungen, die Szenarien
oder Stories möglichst lebendig, in der dem Anwender bekannten Weise zu
dokumentieren. Die „natürlichste“ Repräsentation eines Ablaufes wird durch seine
Simulation als ausführbares Programm erreicht. Daher schlagen wir vor, Stories der
Systemverwendung in Form einfacher aber ausführbarer Szenarioprototypen
durchzuführen. Wir vertreten ferner die These, dass Anwender und Entwickler
gleichermaßen aktiv bei der Entwicklung der Szenariomodelle beteiligt sein müssen.
Bislang obliegt einzig dem Entwickler die Hoheit über alle Modelle, während Anwender als
passive Befragte oder Rezeptoren der präsentierten Modelle fungieren. Um ein
symmetrischeres Verhältnis zwischen Anwender und Entwickler zu ermöglichen, muss
2