In der Diskussion um CASE ist eine gewisse Ernuechterung eingetreten. Auf einschlaegigen Tagungen und Kongressen wird immer wieder hinterfragt, warum die Werkzeuge nicht so funktionieren, wie sie sollen. Meist stehen die Technik und die spezifische Funktionalitaet von Produkten im Vordergrund der Debatte. Was aber sind die tatsaechlichen Ursachen des Problems? Sind die Werkzeuge schlecht, oder koennen wir nur nicht mit ihnen umgehen?
Zu den Tools selbst gibt es grundsaetzlich nicht viel zu sagen. Sie muessen einfach zu handhaben, klar strukturiert und ueber mehrere Phasen konsequent einsetzbar sein. Einen gewissen Einarbeitungsaufwand vorausgesetzt, sollte jeder damit umgehen koennen, auch ein DV-Laie. Solche Werkzeuge sind bereits auf dem Markt. Wir koennten aufhoeren zu diskutieren und anfangen, mit ihnen zu arbeiten, sofern die Methodik des Werkzeugs der des Arbeitsgebietes entspricht.
Zur menschlichen Seite des Problems gibt es viel mehr zu bemerken als zur technischnen. Denn das Wichtigste wird zumeist uebersehen: die "Peopleware", die Menschen, die mit den Werkzeugen - der Software - arbeiten. Generatoren koennen uns nicht alle Aufagben abnehmen. Jedes Werkzeug, gleich welches, muss erst einmal angenommen werden von dem, der es benutzt. Bevor etwas Neues eingefuehrt werden kann, ist daher erst einmal Ueberzeugungsarbeit notwendig, auch muss ein Freiraum fuer die Eingewoehnung geschaffen werden. Und eben daran mangelt es in Unternehmen oft ganz gewaltig. CASE funktioniert dann deshalb nicht, weil man die Rechnung ohne den Anwender gemacht hat.
Das Fazit: Es ist zwar ein Werkzeug angeschafft, aber keiner will damit arbeiten. Die Spezies Computer-Freak sieht kreative Freiraeume bedroht und haelt sich einfach nicht an die Vorgaben.
CASE beruehrt noch einen anderen wunden Punkt: Mit strukturiertem Arbeiten laesst sich erreichen, dass der einzelne entbehrlich wird. Wie sieht es aber in der Praxis aus? Die meisten Projekte haben zum Ergebnis, dass sich die Menschen, die daran teilgenommen haben, unersetzlich gemacht haben. Der Entstehungsprozess der Einzelleistung bleibt in mysterioeses Dunkel gehuellt. Das Wissen gehoert nicht den Unternehmen, sondern den einzelnen Mitarbeitern. Wissen ist Macht, Abgabe von Wissen bedeutet Machtverlust - dieses Dogma beherrscht vielerorts noch die Unternehmenskultur. Warum sollten Mitarbeiter bestrebt sein, ihr Wissen transparent zu machen, ihr eigenes Machtmonopol zu unterhoehlen, wo sie doch gerade im Wissensvorsprung ihren Schutz vor Verlust des Arbeitsplatzes und unliebsamer Konkurrenz sehen? Daher wird Wissen eifersuechtig gehuetet.
CASE verlangt viel von Menschen, die damit arbeiten: zum Beispiel die Bereitschaft, sich austauschbar zu machen. Dies geschieht etwa durch saubere Dokumentation der Arbeitsergebnisse. Im Vordergrund steht allein die Aufgabe, die optimal geloest werden soll. Alles, was dabei hilft, wird eingesetzt - unter anderem eben auch ein Werkzeug. Anschliessend wendet man sich der naechsten Aufgabe zu. Der Prozess der Software-Entwicklung wird zu einem Gesamtkunstwerk aus anonymen Einzelleistungen. Voraussetzung dafuer ist die Faehigkeit zur Kommunikation. Das Gelingen eines Projektes haengt in erster Linie davon ab, ob sich die Beteiligten miteinander verstaendigen koennen.
Methoden des Knowledge-Engineerings zeigen den richtigen Weg. Der Knowledge-Engineer sorgt dafuer, dass eine gemeinsame Sprache gefunden wird und ueberprueft staendig, ob das, was gesagt wurde, auch richtig angekommen ist. Kommunikation wird immer wichtiger. Gefragt sind Mitarbeiter, die ihr Wissen
auf Besprechungen praesentieren koennen, die Ergebnisse selbstverstaendlich in Form von Protokollen sichern und dann auch allen Beteiligten zugaenglich machen. Sich selbst entbehrlich machen heisst frei sein fuer neue interessante Aufgaben.
Die neue Arbeitsweise verlangt hohe kooperative Kompetenz. Aber es mangelt oft bereits an der Einsicht in die Notwendigkeit von Kommunikation. Die Universitaeten vernachlaessigen die Ausbildung kommunikativer Faehigkeiten und ziehen Spezialisten heran, die nicht ueber die Grenzen der Technik hinausblicken koennen, die einseitig auf technische Loesungen fixiert sind. Die Realitaet in Unternehmen ist oft, dass die Beschaefigten ohne entsprechende Schulung und Vorbereitung Werkzeuge einfach vorgesetzt bekommen. Qualifikation von Mitarbeitern wird kleingeschrieben. Schulungsanbieter haben den Bedarf zwar erkannt und sich in ihren Programmen darauf eingestellt, aber das Angebot wurde nicht im erforderlichen Mass angenommen.
Um es noch einmal zu betonen: Das Gelingen eines Vorhabens haengt weniger vom Werkzeug ab als von der Faehigkeit der Beteiligten, strukturiert zu arbeiten und miteinander zu kommunizieren. Wir sehen CASE in erster Linie als Methode des logischen Vorgehens - von der Analyse zum Konzept, vom Konzept zum Pflichtenheft, vom Pflichtenheft zur Realisierung von Software inklusive Dokumentation, Schulung, Betreuung und Wartung. Es geht darum, ein Projekt vom Anfang bis zum Ende mit einer einheitlichen Methodik zu bearbeiten, soweit moeglich auch durch ein Werkzeug unterstuetzt.
An CASE als Methode wird kein Weg mehr vorbeifuehren. Offenheit und Transparenz sind gefragt, auch im Prozess der Software- Erstellung. Die Industrie kann es sich nicht laenger leisten, komplexe Software zu entwickeln, die nicht zu pflegen ist.