Erst die Methode, dann das Tool

Bayerische Kriminaler stellen SW-Entwicklung auf neue Basis

16.04.1993

Mit dieser Erkenntnis wird derzeit im Bayerischen Landeskriminalamt (BLKA) die SW-Entwicklung auf eine ganz neue Basis gestellt. War noch vor wenigen Jahren ueberall eine Programmierung auf Zuruf durch die Organisatoren taegliche Praxis, so erfolgt sie heute methodengerecht im Rahmen von Softwareprojekten.

Bereits seit gut drei Jahren haben die Mitglieder der Gruppe "Methodik und Planung" die Einfuehrung einer BLKA-eigenen Methodik vorbereitet. Wegbegleiter waren externe Berater, die das methodische Wissen in die Gruppe brachten. Unser Team blieb nicht unbeeinflusst durch die allgemeine Tool-Euphorie, die von den Anbietern nicht nur mit Wohlwollen beobachtet, sondern auch gefoerdert wird.

Anforderungen nicht eindeutig formuliert

Die Planungsgruppe konzentrierte sich auf die Suche nach dem richtigen CASE-Tool, das alle Sorgen und Probleme beseitigen sollte. Nach einiger Zeit und mehreren Enttaeuschungen stellten wir fest, dass dieser Weg nicht zum gewuenschten Ziel fuehren wuerde. Die Verantwortlichen hatten die Anforderungen an die zu beschaffende SW-Entwicklungsumgebung nicht ausreichend formuliert. Eine objektive Auswahl von passenden Werkzeugen war daher zu diesem Zeitpunkt noch nicht moeglich.

Deshalb konzentrierten sich die Gruppenmitglieder im Weiteren auf die Definition einer durchgaengigen Methodik, die sich in den fruehen Phasen eines SW-Projekts im wesentlichen auf Structured Analysis (SAund auf die Entity-Relationship-Modellierung (ERM) stuetzte. Gleichzeitig erfolgte die Festlegung des zur Methodik passenden Metamodells, mit dem die Abbildung der Methode auf ein Dictionary geschehen sollte.

Als dann vor knapp einem Jahr mit dem Integrationsverfahren der Bayerischen Polizei (IGV-P) ein strategisch aeusserst wichtiges Projekt mit einem Aufwand von rund 45 Mannjahren anstand, war diese Methodik noch nicht an einem praktischen "Lernprojekt" erprobt worden. Erfahrungen innerhalb des BLKA fehlten ganz. Da jedoch der zustaendige Projektleiter ohne methodische Entwicklung das Millionenprojekt von Beginn an gefaehrdet sah, wagte die Gruppe "Methodik und Planung" den Sprung ins kalte Wasser: Allen Mahnungen der Literatur zum Trotz wurde in unserem Grossprojekt die Methodik detailliert definiert und zum Ersteinsatz gebracht.

Trotz mancherlei Anlaufschwierigkeiten und Rueckschlaegen kann heute - rund ein Jahr nach Projektbeginn - festgestellt werden, dass diese Entscheidung richtig war. Es kristallisierte sich sogar heraus, dass zwar grundsaetzlich ein CASE-Tool fuer zukuenftige Projekte wuenschenswert und notwendig sein wuerde, dass sich dieses aber in unserem Erstlingsprojekt nachteilig auf den Feinschliff der Methodik ausgewirkt haette.

Nur ohne die methodischen Grenzen, die ein CASE-Tool zwangslaeufig den Entwicklern und Methodikern aufzwingt, war es moeglich, auf Anforderungen im Tagesgeschaeft der Entwicklungsmannschaft zu reagieren.

Entwickelt wurde meist auf Papier

Als aenderungsfreundliche Basis bot sich dabei die bestehende Werkzeuglandschaft mit "Predict" als einfachem Data Dictionary an. Entwickelt wurde zumeist auf Papier, nur selten kam ein Grafik- Tool zum Einsatz.

Durch den engen Kontakt der vierkoepfigen Methodengruppe mit der Entwicklungsmannschaft und mit einem externen Berater wurde die Vorgehensweise stets aktualisiert, angepasst und geschult. Nur so war es ueberhaupt moeglich, den Entwickler zu unterstuetzen statt zu behindern. Dadurch entstand ein auf BLKA-Beduerfnisse optimal angepasster Methodenverbund, der - unter Beachtung von Standards - nunmehr Eingang in weitere Projekte finden soll.

Polizeiliche Sonderanforderungen und Sicherheitsaspekte gingen weit mehr als gedacht in die Methodik ein, so dass selbst der dafuer zustaendige externe Methodenberater neue Erkenntnisse aus der Projektarbeit gewann. So wurden in die zur SA gehoerenden Informationsfluss-Diagramme (IFD) Elemente der Dialogsteuerung aufgenommen, die heute den Organisator in die Lage versetzen, bereits im IFD alle wichtigen Elemente der zukuenftigen Funktionalitaet herauszulesen.

Die Funktionsstruktur wurde auf vier Ebenen (System, Dummy, logische Datei und logischer Satz) ausformuliert, die Datenmodellierung orientiert sich bereits in sehr fruehen Phasen an der Normalform-Theorie. Fuer die Formulierung der Steuerung werden Entscheidungstabellen eingesetzt, die den Vorteil der Vollstaendigkeit und relativ fruehen 100prozentigen Ueberpruefbarkeit bieten. Speziell hierfuer wurde das Programm "Pate" der in Muenchen ansaessigen Firma Superdata GmbH beschafft.

Gleiches Vorgehen bei der Software-Entwicklung

Um die reinen Verarbeitungsfunktionen und die Plausibilitaetspruefungen der verschiedenen Ebenen beschreiben zu koennen, wurde der Strukturtext - ein fuer BLKA-Beduerfnisse standardisierter Pseudocode - vorgegeben. Damit sollen die Organisatoren in der Lage sein, je nach Detaillierungsebene und unabhaengig von der Programmiersprache die Funktion zu beschreiben.

Inzwischen hat das Projekt einen Stand erreicht, der es der Methodengruppe erlaubt, bereits weiter zu planen. So soll die SW- Entwicklung in gleicher Weise betreut werden, wobei man auch hier wieder bereit ist zu lernen. Schliesslich gilt es, die Vorgaben der Organisation in bis zu vier verschiedenen Programmiersprachen (Assembler, Cobol, Natural, C) zu realisieren.

Das Hauptaugenmerk der Gruppe "Methodik und Planung" richtet sich deshalb nun verstaerkt auf eine Standardisierung von Testverfahren und Programmrahmen sowie auf die Erstellung von Programmier- Richtlinien.

Ausserdem arbeitet ein Mitglied der Gruppe derzeit an der Standardisierung von Dokumentationen, womit ein weiterer Schritt in eine vollstaendig transparente SW-Entwicklung getan werden soll.

Parallel zur Betreuung der SW-Entwicklung ist die Gruppe Methodik und Planung im Rahmen von IGV-P allerdings auch mit der Ersterprobung eines umfassenden Projekt-Management-Systems beschaeftigt. Damit soll erreicht werden, dass ein Projekt von Beginn an auf terminliche Zusagen und Planungen beruht. Die bislang ueblichen "firmenpolitischen" Terminaussagen, die im BLKA wie auch anderswo das Projektende bestimmten, gehoeren damit der Vergangenheit an.

Das Tool "PMW" von der Hoskyns Group hat sich bei der Projektarbeit bewaehrt. Selbst die anfangs auf Ablehnung gestossenen Controlling-Sitzungen sind nun nicht nur von den Projektmitarbeitern, sondern auch vom zustaendigen Personalrat als richtig erkannt worden. Damit scheint der Grundstein gelegt, um in allen zukuenftigen Projekten des BLKA eine methodische Vorgehensweise, gepaart mit einem ausgefeilten Projekt-Management, anzuwenden.

Trotz dieser positiven Erfahrungen - der Projektverlauf verzoegerte sich durch das stete angleichen der Methodik nur sehr wenig - muss festgestellt werden, dass noch sehr viel Aufwand in den Abgleich der Ergebnisse investiert werden muss, die mit voneinnder unabhaengigen Tools erzeugt wurden. Die Anschaffung eines umfassenden CASE-Tools scheint in Zukunft absolut notwendig zu sein.

Im Vergleich zur Anschaffungseuphorie vor noch gut drei Jahren haben sich heute allerdings die Voraussetzungen grundlegend geaendert. So kann jetzt die Notwendigkeit gegenueber dem Management exakt beschrieben werden, der Umfang und die Anforderungen an das zukuenftige CASE-Tool lassen sich genau definieren.

Erkenntnisse aus der Projektarbeit

Fuer das BLKA kommt nun nur noch ein CASE-Tool in Frage, das die praktizierte Methodik ohne allzu grosse Aenderungen unterstuetzt. Ein solches Tool wird dann wesentlich einfacher einzufuehren sein, weil ja bereits die angewandte Methodik in die SW-Entwicklung integriert ist.

Es hat sich gezeigt, dass zuerst die Methode den Beduerfnissen und erst danach das CASE-Tool der Methodik folgen darf - eine wichtige Erkenntnis, die aus der praktischen Projektarbeit gezogen wurde.

Allerdings sollte es nicht immer gleich ein Millionenprojekt sein, an dem man praktische Erfahrungen mit der Methodik sammelt.

*Dipl.-Informatiker Georg Ringmayr leitet die Gruppe Methodik und Planung beim Bayerischen Landeskriminalamt in Muenchen.