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.

Software und Umgebungsorganisation als integriertes System:


01.06.1984 - 

Tool-Konzept braucht mehrere Architekturen

Glaubt man den vielen Publikationen und Vorträgen über Anwendungssoftware-Entwicklung, so ist die Lösung aller Probleme im massiven Einsatz von Werkzeugen zu suchen. Das Angebot an Software-Tools ist bereits reichhaltig und vermehrt sich von Tag zu Tag. Bei Gesprächen mit Tool-Vertreibern gewinnt der Anwender zudem nicht selten den Eindruck, Software-Tools brauchten nur gekauft und installiert zu werden. um alle Nöte des Entwicklers verschwinden zu lassen. Genug negative Erfahrungen belegen jedoch die Aussage, daß eine solche Vorgehensweise nicht zum erhofften Erfolg führt. Derart eingeführte Werkzeuge fristen eine Weile ein eingeschränktes Dasein, werden von einigen Mitarbeitern im Unternehmen eingesetzt und leisten insgesamt nur einen verschwindend geringen Beitrag zur Milderung der Programmiersorgen.

Der Entwickler von Anwendungssoftware steht unter dem doppelten Zwang, einerseits die Programme termingerecht und wirtschaftlich zu entwickeln und zu warten, andererseits immer höhere Qualitätsansprüche bei komplexer werdenden Systemen zu erfüllen. Die heute geforderte Softwarequalität beinhaltet nicht nur eine weitgehende Fehlerfreiheit, sondern auch eine komfortable und den Bedürfnissen der Benutzer angepaßte Schnittstelle, Robustheit, Wartungsfreundlichkeit sowie Flexibilität gegenüber Leistungserweiterungen und Integrationsfähigkeit mit anderen Systemen im Unternehmen.

Wenn ein Unternehmen diesem immer stärker werdenden Zwang erfolgreich begegnen will, so muß es den Aufbau eines DV-unterstützten Systems für den Software-Entwickler genauso professionell angehen wie die Planung, Konzeption und Realisierung jedes Anwendungssystems. Anders gesagt, müssen sich die Software-Entwickler selbst als eine Fachabteilung betrachten, die derzeitige Arbeitsweisen erhebt, analysiert und daraus Anforderungen für den Soll-Zustand ableitet.

Diese Anforderungen sind in ein Konzept einzusetzen, das die Leistungen des Entwicklungssystems spezifiziert und die Methoden und Verfahren beschreibt, nach denen diese Leistungen zu erbringen sind. Nicht zuletzt muß dieses Konzept die erwünschte Wechselwirkung zwischen Entwickler und Werkzeug beschreiben.

Erst nachdem dieses Konzept abgesichert ist, sollten zielgerichtete Entscheidungen zum Kauf von Software-Tools fallen. Diese Entscheidungen berücksichtigen die objektiven Möglichkeiten der einzelnen Werkzeuge und weisen ihnen einen definierten Platz im Gesamtgefüge zu.

Die Einführung kann stufenweise erfolgen. Begleitende Maßnahmen sind die Schulung und Erprobung an Pilotprojekten und die Bereitstellung von Verfahren und Routinen zur Integration des

eile eines Systems zur Software-Entwicklung sollen durch eine Erläuterung der vom EDV-Studio Ploenzke entwickelten Konzeption für. "Integrierte Software-Technologie" (ISOTEC) veranschaulicht werden.

Systementwurf nach Drei-Sichten-Modell

Die Konzeption basiert auf Prinzipien des Systems-Engineering und berücksichtigt drei Forderungen. Die erste Forderung verlangt den Entwurf des Systems nach dem 3-Sichten-Modell. Jedes System kann unter verschiedenen Aspekten (Sichten) betrachtet werden. Der Systementwurf hat alle für das gesteckte Ziel relevanten Aspekte zu berücksichtigen: Die fachliche Sicht, die Sicht des Benutzers und die DV-technische Sicht müssen vollständig und korrekt beschrieben werden.

Die zweite Forderung definiert Software als Einheit aus Programmen und Dokumentation. Damit soll hervorgehoben werden, daß Dokumentation und Programme als gleichwertige Produkte anzusehen sind, da eine effiziente Anwendung der Programme durch den Benutzer im Fachbereich und eine Wartung der Programme nur mit aussagefähiger Dokumentation möglich sind. Zur Dokumentation gehören die drei Entwurfsdokumente Fachkonzept Benutzerschnittstelle und DV-Konzept sowie die daraus abgeleiteten Arbeitsbücher RZ- und Benutzer-Handbuch.

Als dritte Forderung sollen Software und Umgebungsorganisation ein integriertes informationsverarbeitendes System bilden. Einerseits muß Software die Anforderungen der organisatorischen Umgebung erfüllen. Andererseits schafft die moderne Informationstechnologie (Dialogsysteme, Textsysteme, Kommunikationstechnologien) neue organisatorische Möglichkeiten, so daß bei der Entwicklung von Software die alte Organisation nicht einfach beibehalten,- sondern neu überdacht werden sollte.

Das Projektmanagementkonzept beschreibt die erforderlichen Aktivitäten zur Initiierung, Abwicklung und Steuerung von Projekten. Es untergliedert sich in Projektorganisation und Projektsteuerung.

Unter Projektorganisation werden Aufbau- und Ablauforganisation der Projekte verstanden. In der Projektaufbauorganisation werden Gremien, Kompetenzen, Berichtswege und andere zur Umfeldorganisation gehörende Bereiche behandelt. Die Projektablauforganisation beschäftigt sich unter anderem mit mittelfristiger Projektplanung, rollierender Rahmenplanung, Freigabe von Projekten und Projektüberwachung. Die Projektsteuerung übernimmt die notwendigen Steuerungsaufgaben zur Durchführung eines einzelnen Projekts.

Systemziel als Katalog

Eine Verfeinerung der allgemein akzeptierten Vorgehensweise - Problemanalyse, Entwurf, Realisierung, Implementierung - führt unter Berücksichtigung der drei Entwurfssichten zu dem Phasenmodell (Abbildung 1). Dazu tritt noch außerhalb der eigentlichen Systementwicklung die Phase technische und organisatorische Maßnahmen.

Die Voruntersuchung legt das Systemziel fest. Insbesondere wird dabei die Erreichbarkeit dieses Ziels unter wirtschaftlichen Gesichtspunkten untersucht. Die Verfahrensanalyse wertet die fachlichen Gegebenheiten und die Soll-Vorstellungen des Fachbereichs aus, um einen Anforderungskatalog zu erstellen der das Systemziel im Detail spezifiziert.

In den folgenden drei Phasen Erstellung des Fachkonzepts, Festlegung der Benutzerschnittstelle und Erstellung des DV-Konzepts wird jeweils eine der drei oben beschriebenen Sichten entworfen. Anschließend erfolgt die Softwaretechnische Realisierung, die im wesentlichen aus Programmierung und Test besteht.

Die technischen und organisatorischen Maßnahmen, die das Verfahren erfordert, können zum Teil schon nach der Voruntersuchung eingeleitet werden und parallel zu den folgenden Phasen ablaufen. Diese Maßnahmen beinhalten zum Beispiel die Vorbereitung notwendiger innerbetrieblicher Reorganisationen, Datenerhebungen und Erweiterungen der Kapazität des Rechenzentrums.

Das Methodenkonzept bietet eine durchgängige Methodik für die Teilaufgaben der Systementwicklung (Abbildung 1). Einige Methoden werden in mehreren Phasen angewendet, wobei phasenspezifische Voraussetzungen und Ziele zu beachten sind.

Alle Methoden bieten eine sinnvolle Kombination von Text und grafischen Darstellungsmitteln zur Förderung der Kommunikation zwischen den Entwicklern untereinander und mit den Mitarbeitern der Fachbereiche. So zeigt Abbildung 2 die Darstellung der Aktivitäten beim Entwurf des Fachkonzepts mit Mitteln der Funktionsstrukturanalyse, und Abbildung 3 bringt einen Auszug der Informationsstruktur für das Fachkonzept.

Die Methoden greifen auf Ansätze der Systementwicklung zurück die sich in der Praxis, zumindest in Teilbereichen, bewährt haben. Zum Beispiel wurden Gedanken von Chen (Entity-Relationship-Ansatz), Hubbard und Raver (kanonische Synthese), Codd (Normalisierung), Jackson (Jackson System Development), de Marco (Structured Analysis), Parnas und Dijkstra, aufgegriffen, weiterentwickelt, präzisiert und in eine durchgängige integrierte Methodik eingebettet.

Bei der Vielfalt der Systemumgebungen, in denen Software entwickelt wird, muß ein Tool-Konzept mehrere mögliche Architekturen vorsehen. Eine erste Architekturvariante ist für den Einsatz in einer zentralisierten Umgebung bestimmt, bestehend aus einem Zentralrechner und unintelligenten Terminals. In abgestimmter Form werden dedizierte Werkzeuge eingesetzt für Aufgaben wie Textverarbeitung, Datenentwurf, Syntax- und Konsistenzprüfung sowie Code-Erzeugung und Listen- beziehungsweise Masken-Entwurf. Der zentrale Baustein ist jedoch eine Entwicklungsdatenbank auf der Basis eines Data Dictionary, das die Verwaltung benutzereigener Strukturen unterstützt (siehe Abbildung 3).

Standard-Tools reichen aus

Die Entwicklungsdatenbank speichert: in Form der "strukturierten Dokumentation" alle Systemelemente des Fachkonzepts (Funktion, Informationsobjekt, Elementarfunktion, Datenelement, Benutzersicht), der Benutzerschnittstelle (Dialog, Maske, Maskenübergang, Liste) und des DV-Konzepts (Step, Job, Programm, Modul) sowie die zahlreichen Beziehungen zwischen diesen Systemelementen. Zur Unterstützung des Projektmanagements können ebenso die Systemelemente wie Arbeitsauftrag, Mitarbeiter oder Aktivität gespeichert und in Berichten für Projektstatus, Soll/Ist-Abweichung, Aufwand, Termin und Kosten verwendet werden. Die für diese Archiktekturvariante verwendeten Tools stammen aus dem Standardangebot am Markt.

Die Weiterentwicklung des Systems zielt einerseits auf die Bereitstellung einer anderen Architekturvariante, die zum Beispiel den Einsatz dedizierter Entwicklungsrechner auf PC-Basis und eine verstärkte Verwendung von grafischen Hardund Softwarekomponenten zur Erhöhung des Handhabungskomforts vorsieht. Hierbei stehen neben Kostenfragen insbesondere die Probleme der Integration, der Schnittstellen zu einem zentralen Data Dictionary und des Übergangs auf den Produktionsrechner im Vordergrund.

Andererseits gehen die Überlegungen zum Prototyping, das den Entwicklungsprozeß beschleunigen und die Kommunikation mit dem Fachbereich verbessern soll. Hierbei ist neben der heute schon realisierten Simulation von Dialogabläufen vor der softwaretechnischen Realisierung im wesentlichen an einen durch Prototyping besser abstimmbaren und dadurch verkürzten fachlichen Entwurf gedacht. Dabei gilt es eine sinnvolle Abgrenzung zwischen einem "geordneten, produktiven Prototyping" und einem "konzeptionslosen Trial-and-error-Verfahren" zu finden.

Dr. Albert Mas leitet die Entwicklungsabteilung des Zentralen Beratungsbereichs für Information und Kommunikationstechnologie beim EDV Studio Ploenzke, Wiesbaden. Dr. Wolfgang Wiechert ist Mitglied der Geschäftsleitung.