Montag, 13. Mai 2013

Warum und wie sollte der Systemkontext erfasst werden?

These: Systemkontextanalyse öffnet die Augen für optimale Software

Eine Software wird, bewusst oder nicht bewusst, immer für eine Umgebung erstellt. Diese Umgebung ist der Systemkontext. Das Verstehen und Analysieren dieses Umfeldes spielt in vielen Projekten keine große Rolle und so sind viele Softwaresysteme nicht optimal in ihr späteres Wirkungsfeld eingepasst. Man verlässt sich auf Aussagen des Auftraggebers bzw. der Fachseite, ohne den Kontext zu prüfen, geschweige denn ihn zu optimieren. Dabei ist es vollkommen egal, ob man ein Altsystem modernisieren will, eine Software in ihrer Funktionalität erweitern möchte oder ein vollkommen neues System entwickelt.


Pohl definiert den Systemkontext wie folgt: „Der Systemkontext ist Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das System relevant ist“. [S.55,POHL08]  Bei der Erfassung des Systemkontextes können wir mehrere Zustände erfassen, die man nicht miteinander vermengen sollte. Zuerst gilt es den IST-Zustand zu erfassen. Dabei kommen eine Reihe von Erfassungstechniken zum Einsatz, wie z.B. Interviews, Beobachtungen oder Workshops. Bei der Durchführung dieser Erhebungstechniken ist streng darauf zu achten, was man ermittelt. Oft kommt es zu einer Vermischung von IST- und SOLL-Zuständen. Beide Zustände sind jedoch streng zu trennen. Ideen für den SOLL-Zustand sind getrennt zu vermerken und dienen als Grundlage zur Optimierung und zur Bildung des zu erstellenden Systems.

Die Dokumentation des Systemkontextes ist eine wichtige Voraussetzung, um Schwachstellen zu finden. Es lässt sich wesentlich besser ersehen, wo Verbesserungen durchgeführt werden können. Außerdem können alle Aktionen auf ihre Automatisierbarkeit geprüft werden, die sogenannte Systemanalyse. Beide Schritte, Schwachstellenanalyse und Systemanalyse, wollen wir streng voneinander trennen und die Ergebnisse in getrennten Zuständen dokumentieren. Beide Zustände sind SOLL-Zustände, die aufeinander aufbauen.

Das Ergebnis der Optimierung nennen wir Optimierungs-SOLL-Zustand. Dieser Zustand zeigt eine besser organisierte Umgebung. Das Ergebnis der darauf aufbauenden Automatisierung nennen wir System-SOLL-Zustand. In diesem Schritt ist eine große Anzahl an Funktionalität in das System eingeflossen, oder das System wurde vollkommen neu für die Umgebung konzipiert. Dabei wurde entschieden, welche Prozesse, welche Daten und Fremdsysteme sich in dem zu erstellenden System abbilden lassen. Damit kommt es erneut zu einem Umbau des Systemkontextes. Dinge, die bis dahin in der Umgebung des Systems waren, sind nun Bestandteil des Systems. Der System-SOLL-Zustand bildet die Grundlage für die genaue Erhebung von Anforderungen und deren späterer Umsetzung.

Jeder dokumentierte Zustandswechsel sollte mit einem Controlling abgeschlossen werden. Es macht einen Unterschied, ob sich etwas ausgedacht wurde, oder ob man es in der Realität wirken sieht. Verbesserungspotentiale bzw. neue Ideen sind hierbei ein erneuter Beginn für ein verbessertes System, das sonst veralten und verrotten würde.





Alle Kontextobjekte müssen gesondert erfasst werden. Es muss nachvollziehbar sein, zu welchem Kontextzustand etwas gehört, und es muss gesichert sein, dass die Zustände validiert werden. Diese Aufgaben betreffen das Management und die Validierung des Kontextes. In Bezug auf die Erfassung und Analyse des Systemkontextes sind das querschnittliche Funktionen, sogenannte Cross-Cutting-Concerns.

In ähnlicher Weise hat [S.39, POHL08] diese Aufgaben in seinem Requirement-Engineering-Rahmenwerk aufgezeigt.

  • [POHL08]  Klaus Pohl: „Requirements Engineering“, 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Aus Sicht eines Anwenders ist eine gründliche Systemanalyse sicherlich wünschenswert. Leider bekommen die künftigen Anwender für diese Aufgabe kaum Zeit und so kann das notwendige Wissen nicht in der Tiefe erschlossen werden. Auftraggeber, die oft auch Arbeitgeber der Anwender sind, sollten Anreize zu solch einer Mitarbeit setzen statt sie zu verhindern.

    AntwortenLöschen
  2. Zeit hin oder her ... die Praxis zeigt doch, dass die Kontextanalyse schlichtweg oftmals vergessen oder noch schlimmer ignoriert wird. Selbst eine grobe Kontextanalyse regt zum Nachdenken an, ob wirklich "alle" Aspekte in der Umgebung berücksichtigt sind. Die Kontextanalyse zeigt den Weg zu weiteren potentiellen Anforderungsquellen. Verpasste Anforderungsquellen sind verpasste Anforderungen. Verpasste Anforderungen wirken sich auf das Spannungdreieck Time-Quality-Budget aus.

    AntwortenLöschen