Toolchain in der IT-Analyse
Analyse ist Transformation
Einführung
Für Software-Entwicklung braucht man Werkzeuge – klar. Zunächst muss man sein Programm irgendwo schreiben, man benötigt also so etwas wie einen Editor. Dann muss das Programm kompiliert werden, damit es ausgeführt werden kann. Und damit ist es noch lange nicht getan. Man braucht Bibliotheken, um z. b. auf die Funktionen des Betriebssystems zugreifen zu können. Mithilfe eines Debuggers kommt man Fehlern auf die Spur. Weitere Werkzeuge werden für das Deployment und für die Testautomation benötigt.
Das alles betrifft aber in erster Linie die Entwicklung. In diesem Artikel wollen wir uns die Frage stellen, wie das in der Analyse ist. Benötigen wir auch hier Werkzeuge? Und welche?
Wir wollen uns dieser Frage in folgenden Schritten nähern:
- Um zu wissen, welche Werkzeuge wir benötigen, müssen wir zunächst klären, was eigentlich die Aufgabe der Analyse ist.
- Im zweiten Schritt beschreiben wir das wichtigste Werkzeug des Analytikers.
- Schließlich werden wir mehrere Werkzeuge kennenlernen, die das Hauptwerkzeug unterstützen.
Die Aufgabe der IT-Analyse
Um beurteilen zu können, welche Werkzeuge in der IT-Analyse benötigt werden, ist zunächst zu klären, was überhaupt deren Aufgabe ist.
Die Aufgaben in einem IT-Projekt lassen sich in drei Gruppen teilen:
- Ingenieure: sie erfüllen all jene Aufgaben, für die man (software-)technisches Wissen benötigt. Jemand muss die Programmiersprache beherrschen, wissen, wie man eine Datenbank aufsetzt, alle die eingangs erwähnten Werkzeuge beherrschen.
- Manager: diese kümmern sich darum, dass das IT-Projekt mit den vorhandenen Ressourcen, Zeit und Budget, abgewickelt wird.
- Gestalter: deren Aufgabe ist es, dafür zu sorgen, dass das geplante System die ihm zugedachte Aufgabe erfüllt.
Es ist offensichtlich, dass die IT-Analyse die Rolle der Gestaltung übernimmt. Es ist also die Aufgabe der IT-Analyse, das neue System zu gestalten. Basis dafür ist Wissen über das Fachgebiet, für das das IT-System geplant ist. Dieses Wissen erhält der Analytiker aus verschiedenen Quellen, z. B. aus Büchern, diversen Unterlagen, und vor allem aus Gesprächen mit den sogenannten Stakeholdern.
Die Aufgabe des Analytikers ist es also, Wissen (bzw. Anforderungen) in das Design des geplanten Systems zu transformieren.
Das Haupt-Werkzeug am Web von den Anforderungen zum IT-System
Für diese Transformationsaufgabe braucht der IT-Analytiker zunächst kein Werkzeug. Oder aber – wenn man so will – er braucht genau ein Werkzeug: sein/ihr Gehirn.
Das Gehirn, das ist der Ort, an dem sich dieser Transformationsprozess vollzieht. Kreativität, Erfahrung, Gestaltungskraft machen aus Anforderungen ein Lösungsdesign. Diese Kernaufgabe der IT-Analyse funktioniert ganz ohne (weitere) Werkzeugunterstützung.
Heißt das also, in der IT-Analyse benötigen wir gar keine Werkzeuge – reicht uns unser Gehirn, das wir sowieso immer dabei haben? In der Theorie könnte man es so sehen. In der Realität stimmt das aber nicht – und das aus folgenden Gründen:
- Komplexität: ein typisches IT-Design ist sehr umfangreich, sodass es ein IT-Analytiker nicht schafft, sich jedes Detail, das er sich bereits überlegt hat, im Gedächtnis zu halten. Der Zwischenstand des Transformationsprozesses muss festgehalten werden, damit später wieder darauf aufgesetzt werden und dieser weitergeführt werden kann.
- Kommunikation: der Analytiker kommuniziert sein Design in zwei Richtungen:
- Fachbereich: die Auftraggeber bzw. die künftigen Anwender müssen das vom Analytiker entwickelte Design akzeptieren. Dazu muss der Analytiker in der Lage sein, das Design zu präsentieren. Dafür ist es wiederum erforderlich, dass es in irgendeiner Form aufgeschrieben wird.
- IT-Technik: das Design allein bringt noch gar keinen Nutzen; den bringt es erst, wenn es in Software umgesetzt wird. Damit die Entwicklung dazu in der Lage ist, muss dieses Design in geeigneter Form niedergeschrieben sein.
- Dokumentation: und schließlich soll der Entwurf des Analytikers auch für die Zukunft bewahrt werden. Das Software-System – sobald es realisiert ist – muss gewartet werden, es müssen Fehler korrigiert werden und auch eine Weiterentwicklung ist in praktisch allen Fällen erforderlich. Dokumentation ist dafür zwingend erforderlich.
Das heißt also, es reicht nicht aus, dass der Entwurf des IT-Analytikers in dessen Gehirn existiert. Er muss in geeigneter Form festgehalten werden – und dafür sind Werkzeuge erforderlich. Welche das sind, das soll im Folgenden ausgeführt werden.
Elemente des IT-Designs
Was also benötigt man, um ein IT-Design zu beschreiben? Diese Frage lässt sich nur beantworten, wenn man sich darüber im Klaren ist, woraus ein derartiger Entwurf besteht. Es gibt ja die unterschiedlichsten Arten von IT-Systemen. Gibt es ein durchgängiges Muster, das die Lösungen all dieser Systeme beschreiben kann?
Jedes IT-System, egal welcher Art, hat drei Aspekte:
- Statischer Aspekt: Das ist die Basis jedes IT-Systems. Es beschreibt die Daten, die verwaltet und gespeichert werden müssen, um die Realität des Fachbereiches abzubilden.
- Dynamischer Aspekt: Beschreibt die Prozesse und Algorithmen, die die Daten, die im statischen Aspekt definiert werden, erzeugen, transformieren und dem Benutzer zur Verfügung stellen.
- Schnittstellen: Es wird beschrieben, auf welchem Weg Daten ins System kommen und weitergegeben werden.
Werkzeuge zur Beschreibung des IT-Designs
Auch wenn die Entstehung des IT-Designs ein geistiger, kreativer Prozess ist, für den eine Werkzeugunterstützung nur beschränkt möglich ist, benötigt es für Kommunikation und Dokumentation Werkzeuge.
Das Design kann auf zwei Arten beschrieben werden:
- Text: Beschreibung des Designs durch natürliche Sprache
- Modelle: Verwendung von Modellierung zur Beschreibung des Designs.
Textuelle Beschreibung
Natürlich kann ein Design durch einfache Textverwaltungsprogramme beschrieben werden. Sie haben die Vorteile, dass sie universell verfügbar sind und die Integration von Text, Tabellen und Diagrammen sehr gut unterstützen. Diese Tools stoßen aber vor allem bei größeren Teams schnell an ihre Grenzen, insbesondere was die Mehrbenutzerfähigkeit betrifft. Auch die Verwaltung von sehr großen Dokumenten ist in einfachen Textwerkzeugen schwierig.
Eine gute Alternative zu diesen Textwerkzeugen ist die Verwendung von Kollaborationstools oder Wikis. Sie zeichnen sich durch gute Mehrbenutzerfähigkeit und Such- und Navigiermöglichkeiten aus. Häufig sind derartige Werkzeuge auch mit einem Issue-Tracker integriert. Nachteile von Kollaborationstools gegenüber einfachen Textwerkzeugen sind deren mangelnde Offline-Fähigkeit. Auch die Integration von Diagrammen ist manchmal aufwendig.
Modellierung
Ohne Modellierung ist die Entwicklung und Darstellung eines IT-Designs schwer vorstellbar. Etwa ein Datenmodell ausschließlich in Worten zu beschreiben, ist kaum denkbar. Als wichtigste Methode für die Software-Modellierung hat sich die UML (Unified Modeling Language) durchgesetzt. Sie stellt insgesamt 14 Diagrammarten zur Verfügung. Von diesen werden jedoch in der Regel nicht mehr als fünf benötigt. Daneben gibt es andere Methoden, wie z.B. BPMN (Business Model and Notation) für die Prozessmodellierung.
Welche Methoden sind nun wichtig für die IT-Analyse. Wir wollen dafür auf die Elemente der oben beschriebenen Elemente des IT-Designs zurückkommen.
Statische Analyse
In der statischen Analyse wird gewissermaßen das Skelett des IT-Systems definiert. Dabei wird ein fachliches Datenmodell erstellt. Wichtigste Methode dafür sind die UML-Klassendiagramme. Gelegentlich kommen auch noch Entity-Relationship-Diagramme zum Einsatz.
Dynamische Analyse
Durch die dynamische Analyse kommt Leben in das statische Design. Der Analytiker beschreibt zu diesem Zweck Algorithmen und Prozesse. Die geeigneten Methoden dafür sind:
- UML-Aktivitätsdiagramme
- Andere Prozessdiagramme: z. B. BPMN
- UML-Sequenzdiagramme
- UML-Statusübergangsdiagramme
Schnittstellen
Durch die Definition von Schnittstellen wird beschrieben, wie sich das System nach außen darstellt. Es ist zu unterscheiden zwischen der Schnittstelle zum Menschen hin und jener zu anderen Systemen. Die Schnittstelle zum Menschen wird meist durch die Beschreibung von GUI‘s (Graphical User Interface) festgelegt. Schnittstellen zu anderen Systemen werden durch API-Schnittstellen definiert.
...und die Werkzeuge
UML- und andere Diagramme können entweder mit einfachen Zeichenwerkzeugen erstellt werden oder man verwendet dafür spezielle Modellierungstools.
Zeichenwerkzeuge liefern optisch attraktive Resultate und bieten hohe Flexibilität. Allerdings muss man sich dabei bewusst sein, dass man zeichnet und nicht modelliert. Eine formal exakte Modellierung ist mit derartigen Werkzeugen nicht möglich.
Modellierungswerkzeuge hingegen erlauben eine effiziente Erstellung und Pflege von Diagrammen und Modellen. Sie sind jedoch eher schlecht geeignet für Text und Tabellen.
Der Entwurf von Schnittstellen unterscheidet sich je nachdem, ob es sich um Schnittstellen zu einem menschlichen Anwender oder zu einem anderen System handelt. Der Entwurf von Screens, die als Schnittstelle zum Menschen hin dienen, kann durch ein Mockup- oder Wireframe-Werkzeug unterstützt werden. Das Design von API-Schnittstellen zu anderen Systemen wird durch textuelle Beschreibung oder durch Modelle festgehalten.
Fazit
Das Design, das ein Analytiker gestaltet, entsteht in erster Linie in seinem Kopf. Dieser Entstehungsprozess benötigt kaum Werkzeuge.
Damit dieses Design aber dokumentiert und kommuniziert werden kann, muss es mit Hilfe von Werkzeugen niedergeschrieben werden. Am besten sind dafür geeignet:
- Ein Wiki oder Kollaborationstool für die beschreibenden Texte
- Ein Modellierungswerkzeug zum Erstellen von Modellen, das die verschiedene UML-Diagramme und eventuell weitere Diagramme, wie BPMN oder Datenflussdiagramme unterstützt
- Ein Mockup-Tool, mit dessen Hilfe Screens für die GUI-Schnittstelle entworfen werden können.
Mit diesen Tools kann der Analytiker das Produkt des Transformationsprozesses, der aus Anforderungen ein IT-Design macht, festhalten und so die Basis für eine erfolgreiche Umsetzung legen.
Quellen:
Starke, Gernot: Effektive Softwarearchitekturen, 7. Auflage, 2015 Carl Hanser Verlag München