Methoden-Vielfalt allein hilft nicht weiter:

Integrierte Methoden statt Werkzeugschrank

09.09.1983

GUMMERSBACH (hö) - Konzeptionslos einen Schrank von Software-Tools anzuschaffen, hilft aus der Softwaremisere nicht heraus. Wilhelm Th. Bröcker, Bereichsleiter der Una-Dat EDV-Beratung, Gummersbach/Wiehl, empfiehlt dem Anwender, mehrere Phasen bei der Werkzeugsuche zu durchlaufen: "Erst wenn dies gewährleistet ist, liegt ein durchgängiges, alle Phasen des Software-Entwicklungsprozesses integrierendes Methodenkonzept vor."

Immer mehr setzt sich die Erkenntnis durch, daß die Erstellung komplexer Softwaresysteme mit vertretbaren Kosten und in hoher Qualität nur noch realisierbar ist unter Zuhilfenahme von Werkzeugen, die die Softwareproduktion von der handwerklichen Einzelfertigung hin zur industriellen Serienfertigung unterstützen. Dies hat dazu geführt, daß sich ein interessierter potentieller Anwender mittlerweile einer schier unüberschaubaren Zahl solcher Werkzeuge gegenübersieht, die von Hardwareherstellern und Softwarehäusern angeboten werden. Ohne Mühe lassen sich etwa 200 solcher Werkzeuge, Werkzeugsammlungen und Werkzeugsysteme aufzählen deren Einsatzmöglichkeiten und Vorzüge in den Produktbeschreibungen charakterisiert werden durch Worte wie phasenübergreifend, methodenunabhängig, dokumentierend, generierend, interpretativ, integriert, dediziert und ähnliches. Der Einsatz einzelner Werkzeuge aus diesem Spektrum geschieht oft mit dem Ziel, den einzelnen Softwareentwickler oder bestimmte arbeitsplatzbezogene Tätigkeiten kurzfristig zu unterstützen mit dem Ergebnis, daß schließlich eine bunte Vielzahl solcher Instrumente im Gebrauch ist. Hierbei wird der Nutzen und die Anwendungshäufigkeit und -tiefe von Projektgruppe zu Projektgruppe unterschiedlich gehandhabt - abhängig von persönlichen Erfahrungen und Interessen. Dem einzelnen Entwickler mag eine solche Vorgehensweise vielleicht noch die gewünschten Qualitäten bringen, aus der übergeordneten Sicht der Org./DV-Abteilung muß dies jedoch bezweifelt werden. Der Einsatz von Werkzeugen bringt erst dann die Softwareentwicklung den Zielen

- Rationalisierung (Kostenreduzierung und Produktivitätssteigerung),

- Normierung und Standardisierung,

- Verbesserung der Qualität der Software

näher, wenn der Einsatz der Werkzeuge methodisch untermauert ist.

Allgemeingültige Konzepte gibt es nicht

Nun läßt sich leider kein allgemeingültiges Methodenkonzept für die Softwareentwicklung empfehlen, da ein solches immer betriebsspezifische Gegebenheiten berücksichtigen muß. Unabhängig von den Firmenspezifika ist jedoch die Notwendigkeit methodischen Vorgehens an sich. Durch die Festlegung auf die anzuwendenden Methoden bei der Softwareentwicklung wird im vorhinein ein planmäßiges Vorgehen festgelegt, das heißt, es werden die einzelnen Schritte ausgehend von der Problemstellung bis zur Problemlösung bestimmt.

Die gewählte Methode

- bietet ein Raster, in die die auszuführenden Tätigkeiten zeitlich und sachlich eingeordnet sind (Prioritäten),

- führt durch konsequente, projektübergreifende Anwendung zu einer Normierung und Standardisierung in der Projektabwicklung und -dokumentation

- stellt sicher, daß zu bestimmten Zeitpunkten beziehungsweise nach definierten Arbeitsabschnitten die bis dahin erzielten Teilergebnisse den Entscheidungsberechtigten präsentiert werden,

- fördert den Prozeß der Modellbildung und Strukturierung bei der Systementwicklung.

In vielen Unternehmen hat man zwischenzeitlich die Notwendigkeit methodischen Vorgehens erkannt und denkt intensiv über ein Methoden- und Werkzeugkonzept nach. Nun ist die Erarbeitung eines Methodenkonzeptes, die Auswahl geeigneter Werkzeuge und die Einführung ein Prozeß, der umfangreicher Überlegungen und sorgfältiger Planung bedarf - dies allein schon deshalb, weil die dann geschaffene Entwicklungs-Infrastruktur nicht beliebig geändert werden kann und sollte. Es empfiehlt sich daher, vor Beginn und während der Durchführung eines solchen Projektes, folgende Punkte zu berücksichtigen:

Die Bereitstellung personeller, finanzieller und materieller Ressourcen erfordert die Genehmigung der Org./DV-Leitung und gegebenenfalls übergeordneter Instanzen. Dies geschieht jedoch erst dann, wenn die Verantwortlichen sich von der Notwendigkeit eines solchen Vorhabens überzeugt zeigen. In den Diskussionen unter den Beteiligten (Management, Org./DV-Leitung, Leitung der Programmierung etc.) treten regelmäßig die Fragen auf:

Was kostet uns die Einführung eines werkzeuggestützten Methodenkonzeptes?

Was sparen wir dadurch in welcher Zeit ein?

Spätestens zu diesem Zeitpunkt scheint eine Kosten-/Nutzenanalyse sinnvoll, die jedoch häufig zu denselben Schwierigkeiten führt. Während die Kosten mit genügender Genauigkeit bestimmt werden können, entzieht sich der zu erwartende Nutzen einer ebenso detaillierten Einschätzung. Generell darf der Schluß gezogen werden, daß methodisches Vorgehen bei der Entwicklung von Informationssystemen, orientiert an den aus der Fertigung her bekannten Konstruktionsprinzipien, -verfahren und -hilfsmitteln, auch hier entsprechende Verbesserungen bezüglich der obengenannten Ziele bringt.

Bei den Schwierigkeiten, den gegenwärtigen Kosten den diskontierten zukünftigen Nutzen gegenüberzustellen, ist nur dann eine positive Entscheidung für ein solches Projekt zu erwarten, wenn bei den Entscheidungsträgern ein entsprechend stark ausgeprägtes Methodenbewußtsein vorhanden ist und dies auch gefördert wird.

Oft fehlt die Überzeugung

Um den Umstellungsaufwand so gering wie möglich zu halten, empfiehlt es sich, die schon bisher angewandten Methoden und Werkzeuge zu sichten und gegebenenfalls in das zu erstellende Gesamtkonzept zu integrieren. In vielen Fällen sind es ja nicht die Methoden und Werkzeuge, die sich nicht bewährt haben, sondern es fehlt an der Überzeugung, daß die Beschränkung der persönlichen Kreativität bedingt durch Methodenführung für den Systementwicklungsprozeß als Ganzes zu erhöhter Effektivität führen kann. Die Bestandsaufnahme erfordert eine eingehende Analyse einzelner Projekte und der dort angewandten Methoden. Die in diesem Zusammenhang geführten Gespräche geben den Verantwortlichen wertvolle Hinweise, welche Vorgehensweisen sich aus der Sicht der einzelnen Projekte bewährt haben, wo Verbesserungsmöglichkeiten liegen und welche Gründe zur Ablehnung einzelner Verfahren geführt haben. Besonders sorgfältig sollte das Für und Wider beachtet werden bei durchgreifenden Änderungen, zum Beispiel die Einführung formaler Sprachen in der Problemanalyse. Die Beherrschung solcher Methoden setzt umfassende Programmierkenntnisse beim Analytiker voraus. Auch die Kommunikation mit den Entscheidungsträgern in den Fachabteilungen auf der Grundlage solcher Darstellungen sollte dabei berücksichtigt werden. Durch die Ablösung herkömmlicher Methoden durch mehr rechnergestützte Verfahrensweisen, die sich auch in einer geänderten Dokumentation der Arbeitsergebnisse niederschlagen, ergeben sich Außenwirkungen über den Kreis der Org./DV-Abteilung hinaus.

Methode und Werkzeug müssen zusammenpassen

Der Software-Entwicklungsprozeß wird in eine Reihe von Einzelaktivitäten aufgeteilt, deren Ergebnisse einzelne Teilprodukte sind. Über die sachliche und personelle Zusammenfassung der anfallenden Einzelaktivitäten wird die Gesamtaufgabe in Phasen aufgeteilt, wie etwa Planungs-, Definitions-, Entwurfs-, Implementierungs-, Einführungs- und Wartungsphase. Jede dieser Phasen stellt spezifische Anforderungen an den Entwickler und an die jeweils einzusetzenden Methoden. In der Phase "Entwurf" - als die Entwicklung organisatorischer Lösungen auf der Basis der zuvor festgeschriebenen Anforderungen an das Softwareprodukt - treten naturgemäß andere Fragestellungen und Probleme auf als in der Implementierungsphase. Die in den einzelnen Phasen zum Einsatz kommenden Methoden müssen also auf die speziellen dort auftretenden Bedürfnisse möglichst gut angepaßt sein. Andererseits sollten die unterschiedlichsten Projekte im Bereich Informationssysteme grundsätzlich mit der gleichen Systematik bewältigt werden können. Die Überlegungen zeigen die Schwierigkeiten bei der Auswahl der richtigen Methode. Hilfreich ist hier die Aufstellung eines Kriterienkatalogs, um die Attribute "gute" beziehungsweise "richtige" Methode aus dem subjektiven Empfinden in eine objektiv bewertbare Skala zu transformieren, die den Bogen von phasenspezifisch bis projektunabhängig umspannt. Die Phaseneinteilung bedingt, daß die Ergebnisse der vorgelagerten Phase an die nachgelagerte weitergereicht und dort weiterverarbeitet werden. Die Ergebnisse der Vorphase müssen der nachgelagerten Phase ohne Transformationsprozesse und ohne zusätzliche Kommunikation als Input dienen können. Erst wenn dies gewährleistet ist, liegt ein "durchgängiges, alle Phasen des Software-Entwicklungsprozesses integrierendes Methodenkonzept vor. Über den Weg, die Werkzeugauswahl an dem erarbeiteten Methodengesamtkonzept zu orientieren, gelingt es auch hier, eine zumindest inhaltliche Integration der Werkzeuge zu erreichen. Werden die Methoden durch den Funktionsumfang der Werkzeuge hinreichend unterstützt, müssen noch weitere Kriterien in den Entscheidungsprozeß bei gleichartigen Werkzeugen verschiedener Hersteller miteinbezogen werden:

- die Beanspruchung der vorhandenen Hardware,

- Benutzerfreundlichkeit, einheitliche Benutzeroberfläche,

- Zuverlässigkeit,

- Wartung und Weiterentwicklung durch den Hersteller etc.

Die aus dem Methodenkonzept entwickelten Verfahren, Techniken und Standards werden in einem Organisationshandbuch zusammengetragen und für die Systementwicklung als verbindlich erklärt. Die Erstellung eines solchen Handbuchs bedarf umfangreicher Überlegungen, damit die dort niedergelegten Verfahrensweisen über einen längeren Zeitraum ihre Gültigkeit behalten. Ergeben sich durch neue Erkenntnisse häufige Änderungen des Handbuchs, wird der wirtschaftliche Einsatz einer werkzeuggestützten Softwareentwicklung in Frage gestellt.

Die Umsetzung des Konzeptes in praktische Projektarbeit sowie der Umfang mit den Werkzeugen erfolgt über ein Pilotprojekt. Vorteilhaft ist es, wenn über diese Aufgabe möglichst alle Methoden und Verfahrensweisen zum Einsatz kommen. Da der Kreis der Beteiligten noch klein ist, wird das Tagesgeschäft übermäßig belastet. Überwiegend werden sich bei dieser Vorgehensweise Mitarbeiter zur Verfügung stellen, die Neuerungen besonders aufgeschlossen gegenüberstehen. Wichtig ist nun, daß die über das Pilotprojekt gewonnenen praktischen Erfahrungen intensiv ausgewertet werden. Erst wenn die erzielten Ergebnisse insgesamt als positiv beurteilt worden sind und Aufnahme in das Handbuch gefunden haben, kann schrittweise die Umstellung auf die gesamte Org./DV-Abteilung erfolgen.