Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.11.1976

Was wird aus Systemanalyse?

In EDV-Urzeiten gab es den Organisations-Programmierer. Dann kam die Spezialisierung. Zwischen Problemvorgabe seitens der Fachabteilung und Programmierung wurde die Abteilung Systemanalyse eingeschaltet, die aus verbalen, meist unpräzisen Vorgaben der Anwender Datenflußpläne für die Codierung erarbeitete. Gewiß, es gibt noch andere Organisationsmodelle - aber in der kommerziellen-Datenverarbeitung ist dies wohl das übliche Verfahren, um einen anwenderorientierten Entwurf in einen rechnerorientierten Entwurf zu überführen.

Mit der strukturierten Programmierung - gar keine Frage, daß sie sich letztlich mal durchsetzen wird - kommt nun das Chief Programmer Team Konzept als dieser Methode optimal entsprechende Projektorganisation. Der Chefprogrammierer soll im direkten Kontakt mit der Fachabteilung eine Problemstellung in verschiedene Module zerlegen und nach der Methode der schrittweisen Verfeinerung in zahlreiche Subsysteme und schließlich überschaubare Prozeduren gliedern. Diese Module - je ein Eingang und Ausgang - werden dann von den einzelnen Programmierern des Teams kodiert. Auch nicht erfahrene Junior-Programmierer können dabei sinnvoll selbständig arbeiten. Das Team wird unterstützt durch einen Programm-Sekretär, der vor allem die Aufgaben der Dokumentation übernimmt und gegebenenfalls auch durch einen Test-Manager. Der Chefprogrammierer - entsprechend qualifiziert - hat im Kontakt mit der Fachabteilung den vollen Überblick und schreibt in der Regel den Steuerfluß für die Kettung der Module.

Weniger Schnittstellen

Wo bleibt die Systemanalyse? Zunächst wird man sie weiterhin zwischen Anwender und Programmierung einschalten - vor allem auch deshalb, weil sie halt da ist. Aber langfristig wäre es wünschenswert, diese zusätzliche Schnittstelle mit Dolmetscher-Funktion im Informationsfluß zu eliminieren, denn auch die Systemtheorie schreibt ja vor, daß dem Ziel, Komplexität von Systemen zu verringern, immer dann gedient wird, wenn die Zahl der Interfaces minimiert wird.

Damit es künftig eine einzige Schnittstelle zwischen Anwendern und Programmierern geben kann, ist es aber wohl Voraussetzung, daß - wenngleich die Systemanalyse als Abteilung aufzulösen wäre - die Dolmetscher-Funktion der Systemanalyse erhalten wird. Einerseits müssen die Chefprogrammierer entsprechendes Systemanalyse-Know-how haben, um dem neuen Konzept gerecht zu werden. Codierer bisher üblicher Art werden dieser Aufgabe kaum gewachsen sein. Anderseits wird Systemanalyse-Know-how in den Fachabteilungen benötigt, damit klare Anwender-Vorgaben definiert werden können. Hierfür ist es wohl unumgänglich, daß in größeren Firmen die Fachabteilungen, die viel mit der Datenverarbeitung zu tun haben, EDV-Koordinatoren erhalten, die mit den jeweiligen Chefprogrammierern zusammenarbeiten können und die insbesondere über das Wissen verfügen, darauf zu achten, daß die Interessen der Fachabteilung bei der Implementierung und Codierung tatsächlich gewahrt werden.

EDV-Koordinatoren für die Fachabteilungen

Zahlreiche Anwender haben mit solchen, den großen Fachabteilungen zugeordneten EDV-Koordinatoren hervorragende Ergebnisse erzielt. (CW-Nummer 39 vom 24. September 1976, Interview der Woche mit Ralf Hieber, Zahnradfabrik Friedrichshafen.)

Es sieht so aus, als ob künftig in dem Ausmaß, wie die strukturierte Programmierung Eingang in die Praxis findet, die Systemanalyse-Dolmetsch-Funktion etwa je zur Hälfte EDV-Koordinatoren in drei Fachabteilungen und Chefprogrammierern der EDV-Abteilung übertragen wird, damit es künftig nicht mehr methodisch unterschiedliche, ja inkompatible anwenderorientierte System-Entwürfe und rechnerorientierte Programm-Entwürfe gibt, sondern als eine Schnittstelle des "Strukturierten Entwurfs", der in beide Richtungen entweder verfeinert oder vergröbert werden kann.