Aufrufe
vor 4 Monaten

03 | 2017 NEWS

  • Text
  • Marisk
  • Novelle
  • Niedrigzinsumfrage
  • Kids
  • Institute
  • Anforderungen
  • Zinsaenderungsrisiko
  • Deutschen
  • Banken
  • Aufsicht
  • Bafin
  • Unternehmenssteuerung
  • Risikotragfaehigkeit
  • Perspektive
Ausrichtung

Modellgetriebene

Modellgetriebene Dokumentation im Härtetest Durchgehender Einsatz von Magic Draw in einem paneuropäischen Projekt-Set-up von Stephan Bueren, Dr. Udo Nink und Oliver Lukas Modellgetriebene Vorgehensweisen sind in der Softwareentwicklung längst noch nicht Standard. Immer noch setzen viele Projekt- Set-ups insbesondere im Requirements Engineering auf Office-basierte Dokumentationsformen. Modellierungswerkzeuge werden restriktiv und punktuell eingesetzt, um Grafiken beizusteuern, die anschließend in Office-Dokumente kopiert und um Prosa ergänzt werden. Welchen Herausforderungen sich Projekte stellen müssen, die Modellierungswerkzeuge bereits im Requirements Engineering einsetzen, und welche Vor- und Nachteile daraus entstehen, zeigt dieser Artikel. Wie Qualität bewertbar wird Als Ausgangspunkt einer sinnvollen Qualitätsbewertung von Anforderungsdokumenten ist der Standard IEEE Std 830-1998 sinnvoll. Er definiert folgende Kriterien: > > korrekt, > > eindeutig, > > vollständig, > > widerspruchsfrei/konsistent, > > bewertbar nach Wichtigkeit und/oder Stabilität, > > verifizierbar, > > modifizierbar, > > verfolgbar. Kriterien wie widerspruchsfrei und verfolgbar sind, insbesondere in großen Projekt-Set-ups, bereits in der Ersterstellung von Konzepten eine Herausforderung. Der vermeintliche Vorteil einfacher Tools wie Excel und PowerPoint (gegebenenfalls noch Visio) birgt insbesondere die Gefahr, dass neben der Erzeugung offizieller Dokumente gemäß Projektvorgehensmodell eine Reihe von Nebendokumenten an unterschiedlichsten Ablageorten entstehen. Eine solche Verteilung von Informationen auf eine Vielzahl von Dokumenten wirkt sich anfangs kaum aus. Die Frage, welche Informationen wo zu finden sind, ist noch im Gedächtnis und die Ansprechpartner zumeist greifbar. Mit zunehmender Lebensdauer des Projekts und veränderten Projekt-Set-ups kann sich die Lage jedoch schnell verschlechtern. Die Ansprechpartner sind nicht mehr im Projekt oder können 34 I NEWS 03/2017

Informationstechnologie t sich nicht ausreichend erinnern. Die Auffindbarkeit von Informationen, die über eine große Anzahl von Dokumenten verteilt sind, ist kaum mehr möglich (Qualitätsaspekte Verfolgbarkeit und Modifizierbarkeit). Infolgedessen werden Änderungen punktuell durchgeführt, sinnvolle Möglichkeiten einer Auswirkungsanalyse fehlen, und die Konsistenz der Dokumentation leidet zunehmend. Fachliche und organisatorische Maßnahmen (idealerweise zu Beginn des Projekts vereinbart) lösen hier schon viele Probleme. Eine klare Regelung von Dokumententypen, Strukturen und Inhalten, der gezielte Einsatz von Autorenteams, die Vermeidung eines Teamwechsels zwischen Ersterstellung und Wartung sowie die zielgerechte Aufstellung von Fachdomänen sind nur einige sinnvolle Maßnahmen. Doch auch gut organisierte und strukturierte Projekte stoßen ab einer bestimmten Größe (und Menge an Dokumenten) an ihre Grenzen. So lässt sich etwa die Kommunikation mit steigender Anzahl an Stakeholdern immer schwerer gewährleisten. Fluktuation in den Teams (und damit verbunden auch Wissensverlust) wird ebenfalls zu einer erheblichen Hürde. Letztlich bleibt die Frage, wie strukturiert und auffindbar Informationen abgelegt werden können. Abhilfe gesucht Die Hersteller von Modellierungstools versprechen Abhilfe, zumindest was die meisten der oben gelisteten Qualitätskriterien angeht (inhaltliche Korrektheit und Vollständigkeit wird auch das Beste derzeit am Markt befindliche Werkzeug nicht gewährleisten). Ob solche Versprechungen eingehalten werden können, hängt jedoch nicht alleine am Werkzeug. Vielmehr sind auch die Methodik und deren richtige Interpretation und Umsetzung maßgeblich. Die Einführung einer geeigneten Kombination aus Werkzeug und Methodik bedarf mitunter weitreichender Maßnahmen. Diese umfassen zum Beispiel: die Auswahl einer geeigneten Methodik, die Softwareauswahl und -anschaffung, die Schulung von Mitarbeitern (sowohl in der Methodik als auch im Umgang mit spezifischer Software) und das Aufsetzen von Meta-Modellen (hier werden sich insbesondere die Unternehmensstandards in der Softwareentwicklung wiederfinden müssen). Nicht zuletzt dürfen auch „weiche“ Faktoren nicht außer Acht gelassen werden. So muss möglicherweise erst eine grundlegende Motivation geschaffen und vermittelt werden, altbekannte Pfade zu verlassen. Wie aber sieht in der Realität der Weg von einer rein textlichen Dokumentation hin zu einer modellbasierten Dokumentation aus? Welche Hürden sind zu meistern? Was sind die Erfolgsfaktoren? Was die Stärken und Schwächen? Im Folgenden wird dies anhand eines Praxisbeispiels (Projekt mit aktuell ca. 7.000 Seiten fachlicher Dokumentation) dargestellt. Im Fokus steht hierbei die Erstellung der Fachkonzeption. Erkannte Erfolgsfaktoren werden im Text gesondert durch das Tag [Erfolgsfaktor!] hervorgehoben. Praxisbeispiel – Am Anfang war das Wort Zu Beginn der Projektlaufzeit wurde die Fachdokumentation klassisch basierend auf Microsoft-Office-Tools (Excel, Word, Visio) erstellt. Hauptdokumentationselement waren dabei Use Cases, die die Mehrzahl der fachlichen Requirements dokumentierten. Use Cases wurden im Projekt rein textlich aufgebaut (keine Diagrammtypen, wie zum Beispiel Activity-Diagramme). Mit steigender Anzahl und Größe der Dokumente zeigten sich Mängel, die zu diesem Zeitpunkt primär die Konsistenz und Nachvollziehbarkeit betrafen. Aus diesem Grund beauftragte das Projekt eine Studie zur Darstellung möglicher Überführungsszenarien von der textlichen in die modellbasierte Form. Entscheidend in dieser, wie auch den Folgephasen, war die Tatsache, dass eine Reihe von Befürwortern mit der notwendigen Durchsetzungsfähigkeit und Entscheidungsgewalt im Projekt grundsätzlich für einen modellbasierten Ansatz eintraten [Erfolgsfaktor!]. Basierend auf den Ergebnissen der Vorstudie wurde schließlich beschlossen, zunächst ein Teilprojekt umzustellen. Diese schrittweise Umstellung erwies sich in vielerlei Hinsicht als vorteilhaft. So konnte eine ausreichende Belastbarkeit ohne Risiko für das Gesamtprojekt sichergestellt werden [Erfolgsfaktor!]. Zudem wurden die Ergebnisse genutzt, um für die Vorgehensweise zu werben. Die Auswahl des richtigen Tools Die Auswahl des „richtigen“ Werkzeugs war im vorliegenden Beispiel nicht notwendig. Das Großunternehmen im Automotive-Bereich setzte Magic Draw bereits in einer Vielzahl von NEWS 03/2017 I 35

msgGillardon

03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2016 | Seminarkatalog | Finanzen

Über msgGillardon



Wir bieten unseren Kunden Management-, Business-, Prozess- und IT-Beratung. Darüberhinaus entwickeln wir kundenspezifische Lösungen, sowohl auf Basis unserer eigenen Software als auch auf Basis marktüblicher Standardsoftware. Sofern gewünscht entwickeln wir auch Individuallösungen - ganz auf Ihre Bedürfnisse zugeschnitten. Mit unserer Beratungskompetenz, bankfachlicher Expertise und IT-Know-how unterstützen und begleiten wir Sie umfassend und helfen Ihnen, in dynamischen Märkten schnell, flexibel und erfolgreich zu handeln.

Ihr Erfolg ist unser Antrieb: Unsere mehr als 400 Mitarbeiterinnen und Mitarbeiter arbeiten mit Kompetenz und Leidenschaft an der Realisierung gemeinsamer Ideen - zuverlässig, engagiert und verantwortungsbewusst.

msgGillardon - Ihr Partner für zukunftsweisende Lösungen für die Finanzbranche.


© 2015 by msgGillardon AG - powered by yumpu Datenschutz | Impressum