Benutzer:Chi-Vinh/Testgelände/UMO1 Schuermann

Unternehmensmodellierung [ZUSAMMENFASSUNG]

Kapitel 1: Motivation & Grun dbegr iffe

Begriffe sind ein Instrument für bestimmte Zwecke, z.B. zur Analyse. Sie selbst sind eine Abstrak-

tion (bezeichnen nie einen einzelnen Gegenstand, sondern immer eine Klasse von Gegenstän- den), die uns helfen, die Realität zu strukturieren und zu ordnen.

Ein betriebliches Informationssystem dient der Erfassung, Aufbewahrung, Verarbeitung und

Bereitstellung von Informationen sowie der Informationsübermittlung. Das IS wird als Instrument zur Erreichung von Unternehmenszielen angesehen.

Daten: Folge von Symbolen aus festgelegten Symbolmengen. Formale Semantik ergibt sich durch

Typzugehörigkeit.

[[Image:]]*Information: Daten, deren Semantik sich (auch) durch die Abbildung realer (oder gedachter)

Sachverhalte ergibt. Es liegt also eine realweltliche Interpretation vor.

Wissen: Informationen, die durch ein höheres Maß an Abstraktion und Begründung gekenn-

zeichnet sind.

Software-Entwicklung als ein riskantes Geschäft, Risiko ist wirtschaftlich immer mit Kosten ver-

bunden. Ansätze zur Verringerung des Risikos sind der Einsatz von Standardsoftware und die Be- auftragung von renomierten Software-Firmen.

Warum scheitern so viele IT-Projekte? Ein Grund hierfür ist, dass viele Entwickler ihr Handwerk-

szeug nicht richtig verstehen. Programmierer der ersten Stunde waren Mathematiker, Physiker, etc. (damals gab es noch keine dedizierte, fundierte Ausbildung).

Zum erfolgreichen Einsatz von IT-Systemen muss auch die Organisation des Unternehmens ange-

passt werden. Abläufe müssen optimiert werden, um freie Potenziale nutzen zu können. *Es gibt einen hohen Grad an schwer durchschaubarer Interdependenz zwischen Unternehmens-

strategie, Organisation und Informationssystemen. Daher empfiehlt sich eine gemeinsame, ver-

zahnte Planung und Realisierung durch Fach- und IT-Experten. Diese haben aber häufig unter- schiedliche Problemsichten und Zielvorstellungen  Kommunikationsbarrieren.

Ziele zur Verbesserung der Situation: Reduktion von Komplexität, Förderung der Kommunikation

zwischen Management/Anwendern und IT-Experten/Entwicklern sowie die Reduktion von Risi- ken.

Sinnvolle Maßnahmen: Schaffung von Transparenz  Abstraktion von unwesentlichen Aspekten,

Abstraktion von personenspezifischen Details, Abstraktion von speziellen Merkmalen einzelner

Einsatzbereiche, Abstraktion von zeitlich varianten Eigenschaften und speziellen Technologien

Modell: Abbild von Sichten auf einen tatsächlichen oder geplanten Realitätsausschnitt, welches

bewusst von bestimmten Aspekten der Wirklichkeit abstrahiert (die Art der Abstraktion hängt

vom jeweiligen Verwendungszweck ab)

Modellierungszwecke: Beschreibung, Erklärung, Entscheidung, Konstruktion

Modelle erfordern Modellierungssprachen, die aus Syntax (Regeln für zulässige Modelle, auch

abstrakte Syntax), Semantik und Notation (Aussehen von Symbolen, auch konkrete Syntax) be-

stehen

Fundamentaler Konflikt der Systementwicklung: einerseits Abstraktion von der Implementie-

rung/Laufzeitbeschränkungen, andererseits Unterstützung des Entwurfs und der Implementie-

rung (erfordert formale Beschreibungen und Einbeziehung der Spezifikation von Programmier-

sprachen)

Konzeptuelle Modellierung als Brücke zwischen Anwendungswelt und der Software: Sie dient

der allen Beteiligten an einem Software-Entwicklungsprozess verständlichen Darstellung der An-

Frank Schürmann | Wintersemester 2007/2008 1

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

wendungsdomäne, abstrahiert dabei von technischen Besonderheiten, trägt aber den Randbe-

dingungen Rechnung, die durch später verwendete Implementierungssprachen entstehen

Kernideen: Förderung der Kommunikation zwischen allen Beteiligten, Bereitstellung von Konzep-

ten zur zielgerichteten Analyse und dem Entwurf von Systemen, Modelle als wiederverwendba-

rer Wissensspeicher

Eigenschaften von Software / Informationssystemen: sind sprachlich konstruiert, dienen der

Beschreibung von Gegenständen / Sachverhalten aus Anwendungsdomänen, stellen sprachlich

spezifizierte Funktionen zur Verwaltung und Verarbeitung von Daten bereit und ändern den Zu-

stand der verwalteten Daten nach der Maßgabe von Regeln

Die Abbildung realer oder geplanter Anwendungsdomänen bedient sich der Begriffe / Konzepte,

die in den jeweiligen (Fach-)Sprachen verwendet wird  Diskurswelt. Wir bilden also nicht die Realität ab, sondern deren sprachliche Repräsentation.

Man erschließt sich z.B. den Begriff Kunde, indem man mit den Leuten redet, die mit Kunden zu

tun haben.

Konzeptuelle Modellierung als sprachliche Rekonstruktion. Modellierungssprachen sind besser

zur Vorbereitung des Systementwurfs geeignet als die natürliche Sprache, da sie formal (bzw. semi-formal) sind und Konzepte der Software-Entwicklung (z.B. Entitätstypen, Klassen) berück- sichtigen.

Hintergründe zur konzeptuellen Modellierung:

Philosophische Ontologie, Lehre vom Sein, Grundbestandteile der Welt, Problem: Kategorien

lassen sich zum Teil kaum präzise bzw. formal beschreiben

Softwaretechnik: Strukturierungselemente für Daten (Datentypen, -strukturen, Klassen, At-

tribute) und Programme (Funktionen, Prozeduren, Methoden, Klassen, Operationen)

Psychologische Hypothese: Graphische Repräsentationen sind tendenziell besser geeignet,

komplexe Systeme anschaulich abzubilden als rein schriftliche Darstellungen

Traditionelle Basisabstraktionen des Systementwurfs:

Datenabstraktion: Abstraktion auf Datenstrukturen (statische Abstraktion) * Funktionsabstraktion: Abstraktion auf Funktionen

Zustandsabstraktion: Abstraktion auf Systemübergänge (dynamische Abstraktion)

Objektabstraktion: Abstraktion auf Objekte (integriert Daten- und Funktionsabstraktion)

Prozessabstraktion: Abstraktion auf Geschäftsprozesse (spezielle dynamische Abstraktion)

Frank Schürmann | Wintersemester 2007/2008 2

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Ideal wäre, wenn aus dem konzeptuellen Modell automatisch das Implementierungsdokument

transformiert werden kann  geringe Fehlerwahrscheinlichkeit, kostengünstig; dafür nötig ist

eine präzise Abbildung der Modellierungssprache auf die Implementierungssprache

Fokus auf Typen, die den Begriffen der natürlichen Sprache entsprechen; Fokus auf einzelne In-

stanzen macht z.B. aufgrund der zeitlichen Varianz wenig Sinn

Die Modellierung von Geschäftsprozessen ist für die Wirtschaftsinformatik von entscheidender

Bedeutung, weil es sich um ein Blick auf das Unternehmen handelt, welcher die Welt der Daten-

verarbeitung mit der Welt der Betriebswirtschaft verbindet und integriert

Warum nicht gleich codieren? Häufig zu komplexe Anforderungen, geringe Struktur und wenig

Dokumentation verhindert die Wiederverwendbarkeit

Kapitel 2: Grundlege nde Abstraktionen

Ein Grund für die besondere Bedeutung der Datenmodellierung ist die Tatsache, dass Daten-

strukturen tendenziell im Zeitverlauf stabiler sind als z.B. Funktionen. Dies gilt aber nur, wenn die

Anforderungen an das System präzise und vollständig beschrieben sind, auch im Hinblick auf zu

erwartende Änderungen in der Zukunft. Des Weiteren sind Datenbanken ein zentraler Aspekt für die Architektur betrieblicher IS.

Hintergründe des ER-Modells

Philosophische Ontologie

Mathematische Fundierung: formal definierte Sprache mit verlässlichen, korrekten Verfah-

ren. Syntax und Semantik der verwendeten Datenstrukturen sollten ebenso formal beschrie-

ben werden wie die Zugriffsoperationen

Datenbanktechnologie: verschiedene Daten aus einzelnen Anwendungen können mit Hilfe

dieser Technologie integriert werden

Das Entity Relationship Model ist kein konzeptuelles Modell, sondern eine Modellierungsspra-

che zur Erstellung von Datenmodellen!

Ziele des ERM:

Abstraktion von Datenbankmodellen

Berücksichtigung einer formalen Fundierung

Förderung einer anschaulichen (graphischen) Darstellung

Sprachkonzepte des ERM:

Entitätstypen, welche eindeutig identifizierbar sind

Beziehungen zwischen Entitätstypen

Beispiel für ein ERM:

Abstraktionsprinzipien:

Zweckmäßigkeit: Beschränkung auf relevante (auch zukünftige) Merkmale

Frank Schürmann | Wintersemester 2007/2008 3

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Integrität: Verhindert unzulässige Zustände, vermeidet Redundanz

Anschaulichkeit: Orientierung an existierender Fachterminologie

Attribut oder assoziierter Entitätstyp? Wenn ein Ding eine eigenständige Identität besitzt, wird es

i.d.R. als Entitätstyp modelliert.

Adresse als Sonderfall: Kompromiss zwischen fein granularer Aufsplittung und noch handhabba-

rem Umgang, eine Möglichkeit: Adresse und Ort jeweils als Entitätstyp

Vermeidung von Typdifferenzierung durch Attributzustände, besser allgemeingültige Attribute in

eine Oberklasse auslagern und Spezialisierungen modellieren

Sachverhalten, deren Ausprägungen durch andere Größen (z.B. die Zeit) determiniert sind, soll-

ten nicht als Attribute modelliert werden

Unnötige Kreise in Modellen müssen unbedingt vermieden werden, streichen von redundanten

Beziehungen  kann ansonsten zu Dateninkosistenzen führen

Normalisierung bei sorgfältiger Modellierung nicht notwendig, Normalisierung nicht hinreichend

zum Auffinden von Anomalien (eindeutige Bezeichner notwendig)

Ausdrucksmächtigkeit (Semantik) von Domänen (Wertebereichen): Oftmals ist z.B. String nicht

präzise genug und lässt auch unsinnige Werte zu, hier wäre eine größere Einschränkung des Wer-

tebereichs wünschenswert

Kritische Würdigung des ERM:

Sieht keine Generalisierung/Spezialisierung vor

Keine Angabe der Leserichtung

Beziehungstypen redundant

Abgeleitete Attribute u.U. wichtig, aber Bedeutung nicht darstellbar

Wichtig für die Erstellung von Schemata zur Erzeugung von relationalen Datenbanken

Funktionsmodellierung

Fokus vor allem auf Funktionen, die der Verarbeitung von Daten dienen (können auch Ge-

schäftsprozesse sein)

Häufiges Vorgehen zum Auffinden von Funktionen ist das Dekomponieren von Funktionen

und die Benennung von eingehenden und produzierten Daten

Menschen tendieren eher dazu, ihre Arbeitsumgebung in Form von Aufgaben und Funktio-

nen wahrzunehmen als in Form von Objekten

Funktionenhierarchie:

Diagrammtyp zur Darstellung von Aggregationsbeziehungen zwischen Funktionen

Auf Grundlage von Funktionshierarchien kann z.B. analysiert werden, ob Funktionen automa-

tisiert oder ausgelagert werden können

Zur Darstellung eines Überblicks wichtiger Funktionen geeignet, da die Dekomposition gut

auf Befragungsstrategie abbildbar ist

Bewertung und Analyse durch fehlenden Kontrollfluss nur sehr eingeschränkt möglich

Nur eingeschränkt geeignet, um Reorganisations- bzw. Rationalisierungspotenziale zu ermit-

teln

Datenflussdiagramm

Unterstützen die Durchführung und Dokumentation einer funktionsorientierten Analyse

Dienen der Vorbereitung und Ergänzung der Datenmodellierung

Datenflüsse und Funktionen als wesentliche Konzepte

Beispiel für ein DFD:

Frank Schürmann | Wintersemester 2007/2008 4

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Konzepte des DDF:

Funktion: dient der Repräsentation von Funktionen/Aufgaben/Prozessen in der betrachteten

Domäne

Datenfluss: dient der Abbildung von Datenstrukturen (z.B. Entitätstypen oder Attributmen-

gen), deren Instanzen in Funktionen eingehen oder von ihnen erzeugt werden

Ablage: dient der Kennzeichnung von Datenstrukturen, deren Instanzen über die Dauer des

Prozesses zu speichern sind

Schnittstelle/Akteur: Kennzeichnet externe Schnittstellen zu Akteuren (Menschen, Organisa-

tionen, Maschinen, Programme)

Integration verschiedener Modelle durch gemeinsame Konzepte

Funktionenhierarchie und DFD: Funktionen

DFD und ERM: Entitätstyp und Attribute

DFD Bewertung:

Gängige Abstraktion für die Ermittlung/Darstellung der in Funktionen benötigten/erstellten

Daten

Mögliche Grundlage für den Entwurf der Funktionen/Module eines Programms

Damit: Grundlage für die Entwicklung eines gemeinsamen Referenzsystems für die funktiona-

le Integration

Unterstützt sukzessive Entwicklung korrespondierender Datenmodelle

Kapitel 3: Objektorie ntierte Modellierung

Hintergrund: Abstrakte Datentypen

Grundidee: Dem Programmierer wird ermöglicht, eigene Datentypen auf einem angemesse-

nen Abstraktionsniveau zu definieren

Bestehen aus einer Datenstruktur und Operationen, die auf die Struktur angewendet werden

können

Verkapselung der Daten

Erlauben eine Spezifikation unabhängig von vorgegebenen Datenstrukturen

Erhöhen die Integration, da zwischen verschiedenen Applikationen nicht mehr nur Bits & By-

tes oder Integerzahlen ausgetauscht werden, sondern z.B. Kunden

Eine Klasse basiert auf dem Konzept des Abstrakten Datentyps, hat jedoch die zusätzliche Eigen-

schaft der Spezialisierung/Generalisierung

Zwei verschiedene Konzepte zur Definition von Klassen

Extensional: Eine Klasse als eine Menge von Objekten mit gemeinsamen Eigenschaften

Frank Schürmann | Wintersemester 2007/2008 5

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Intensional: Eine Klasse als Vorlage (Template) / Konzept mit bestimmten Eigenschaften, die

zur Instanziierung von Objekten des gleichen Typs dient

Kernkonzepte der Objektorientierung:

Klassenbildung

Repräsentieren domänenspezifische Konzepte bzw. Mengen von Objekten

Dienen zur Klassifizierung einer Menge von Objekten, welche gemeinsame Eigenschaften

haben

Verkapselung

Auf Daten, welche in einem Objekt - d.h. in seinen Attributen - verwalten werden, kann

nicht direkt von außerhalb des Objektes zugegriffen werden  der Zustand eines Objekts

kann nur von dem Objekt selbst verändert werden

Zugriffe von außerhalb erfolgen nur über die vom Objekt angebotenen Dienste

Dienste werden von Operationen implementiert. Die nach außen hin sichtbarer Reprä-

sentation des Dienstes nennt man Signatur oder Schnittstelle

Abstraktion von interner Datenstruktur sowie von der konkreten Implementierung der

Operationen

Spezialisierung (Vererbung)

Generalisierung kann auf eine Menge von Klassen mit gemeinsamen Eigenschaften an-

gewendet werden. Diese gemeinsamen Eigenschaften werden in einer gemeinsamen Su- perklasse generalisiert.

Eine Klasse erbt die Eigenschaften ihrer Superklasse(n)

Durch Hinzufügen weiterer Eigenschaften in eine Subklasse wird diese zur Spezialisierung

ihrer Superklasse

Abstraktion von Besonderheiten der spezialisierten Klassen

Voraussetzung: Generalisierung muss auf wesentliche, im Zeitverlauf invarianten Ge-

meinsamkeiten beruhen!

Unterschied Spezialisierung und Vererbung: Verschiedenen Perspektiven, bei der Spezia-

lisierung wird ein generelles Konzept (Klasse) spezialisiert durch Hinzufügen von weiteren Eigenschaften, bei der Vererbung werden Eigenschaften einer Oberklasse in eine Unterk-

lasse vererbt

Polymorphismus

"Vielgestaltigkeit"

Ermöglicht die Verwendung des selben Namens (Signatur) für verschiedene Implemen-

tierungen eines Dienstes

Natürliche Bezeichnungen, bessere Lesbarkeit

Abstraktion vom Empfänger einer Nachricht

Wartungsvorteil: Bei Erweiterung eines Systems durch spezialisierte Klassen können auf-

rufende Klassen davon unberührt bleiben

Der wesentliche Vorteil der objektorientierten Softwareentwicklung: Abstraktion, durch Klassen,

"Information Hiding", Generalisierung/Spezialisierung, Polymorphie

Bei Klassen: Abstraktion von einzelnen Instanzen; den Besonderheiten der Implementierungs-

technologien; der Phasen des Lebenszyklus, weil in jeder Phase verwendbar (wenn auch in unter-

schiedlicher Detaillierung)

Vorteile von Klassen:

Frank Schürmann | Wintersemester 2007/2008 6

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

durch Korrespondenz mit natürlichsprachlichem Klassenbegriff Beitrag zur Anschaulichkeit

von Software-Entwürfen

durch Verwendung in allen Phasen Beitrag zur Integration der Phasen

Software-Wartung  Modularisierung: Änderungen können gezielt für Klassen durchgeführt

werden, Abstraktion von Änderungen einer Klasse

Wartungsvorteile durch Abstraktion von Modifikationen im Zeitverlauf

Objektorientierung fördert Wiederverwendbarkeit

Bessere Chancen, von variierenden Randbedingungen in unterschiedlichen Wiederverwen-

dungskontexten zu abstrahieren

Förderung einer komfortablen und sicheren Anpassung an spezielle Gegebenheiten durch

Verkapselung, Spezialisierung (Vererbung) und Polymorphie

Aber: Je spezieller eine Klasse für einen bestimmten Einsatzkontext erstellt wurde, desto ge-

ringer die Wiederverwendungschancen in einem anderen Kontext

Isolierte Wiederverwendung einer Klasse i.d.R. nicht möglich, da zumeist Abhängigkeiten von

anderen Klassen bestehen

Beispiel für ein Objektmodell / Klassendiagramm:

Warum ist es von Vorteil, zwischen Attributen und assoziierten Objekten zu unterscheiden? Weil

Objekte mit eigenständigen Identitäten als Objekt zu modellieren sind, außerdem wird die Les- barkeit gefördert und die Redundanz verringert.

Spezifische Vorteile von uni- und bidirektionalen Beziehungen: Bei bidirektionalen Beziehungen

wird die Performanz erhöht, da zugehörige Daten direkt ausgelesen werden können. Jedoch er- höht dies die Redundanz und bedroht die Integrität. Im Hinblick auf die Wartbarkeit ist also eine unidirektionale Beziehung vorzuziehen.

Generalisierungshierarchie: Problem ist, dass ein Objekt während seines Lebenszyklus seine zu-

gehörige Klasse nicht ändern kann

Kapitel 4: Phasenmo delle

Modellierungssprachen alleine reichen nicht aus, um Software zu entwickeln. Man braucht eine

Vorstellung davon, wie man vorgehen soll, welche Aufgaben sind in einem Software-

Entwicklungsprojekt zu erfüllen und in welcher Reihenfolge sind diese durchzuführen.

Phasenmodelle:

Dienen der Identifikation wesentlicher Aufgaben im Rahmen der Software-Entwicklung und

-Wartung

Enthalten implizite und explizite Annahmen über angemessen Vorgehensweisen

Haben deutlich präskriptiven Charakter (schreiben vor, wie man vorgehen sollte = Anleitung)

Anwendung empfiehlt sorgfältige Interpretation

Code & Fix

Frank Schürmann | Wintersemester 2007/2008 7

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Kein Phasenmodell, da der Gesamtprozess nicht in verschiedenen Aufgaben unterteilt ist

Keine Dokumentation, kein Risiko-Management

Wasserfallmodell

Generisches Modell für alle Arten von Software-Entwicklungsprojekten

Aufeinanderfolgende Phasen und Rücksprünge in vorhergehende Phasen

Kritik: wenig differenziert und zu oberflächlich, um gehaltvolle Orientierung zu liefern; kann

jedoch als idealisierende Orientierung verwendet werden

Betrachtet Software-Entwicklung als einen rationalen Prozess, Wiederverwendung wird nicht

explizit berücksichtigt

Erweitertes Wasserfallmodell sieht Rücksprünge vor

Spiralmodell

Motiviert durch Kritik am Wasserfallmodell

Unterteilt den Gesamtprozess in Zyklen, die jeweils in gleicher Weise strukturiert sind

Machbarkeitsstudie

Anforderungsspezifikation

Architekturentwurf

Detaillierter Software-Entwurf

Besondere Beachtung des Risikos in Projekten (regelmäßige Risikoanalysen, regelmäßige

Realisierung von Prototypen)

Beurteilung

Detailliertere Unterstützung als im Wasserfallmodell

Explizite Berücksichtigung des Prototypings, aber keine Kriterien, wann Prototyping sinn-

voll ist

Betonung und Behandlung von Risiken für Projektmanagement hilfreich

Frank Schürmann | Wintersemester 2007/2008 8

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Aufforderung zur Berücksichtigung von Alternativen geeignet, um Wiederverwendung zu

fördern (nicht alles muss selbst neu entwickelt werden)

Explizite Berücksichtigung von Kosten und sonstigen Randbedingungen

Graphische Darstellung wirkt unübersichtlich

V-Modell

Obligatorisch bei allen Software-Entwicklungsprojekten im öffentlichen Bereich zu verwen-

den (Beitrag zur Qualitätssicherung, Einhaltung von Planungsrichtlinien)

Ziele

Minimierung der Projektrisiken

Verbesserung und Gewährleistung der Qualität

Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus

Verbesserung der Kommunikation zwischen allen Beteiligten

Generisches Vorgehensmodell für alle Arten der Software-Entwicklung, Anpassung an spe-

zielle Einsatzbereich durch konfigurierbare Vorgehensbausteine und Referenzelemente

Die Anpassung an spezielle Projektanforderungen erfolgt durch die Auswahl von Vorgehens-

baustein sowie deren Konfiguration durch Auswahl/Änderung von Rollen, Produkten und Ak-

tivitäten

Beurteilung

In Deutschland hohe Bedeutung, relativ weit verbreitet

Sehr umfangreich und detailliert

Vielfältige Anpassungsmöglichkeiten, aber relativ hoher Anpassungsaufwand

Hohe Komplexität erfordert aufwändige Einarbeitung

Nur eingeschränkte Verknüpfung mit Modellierungssprachen

Kritische Würdigung der Phasenmodelle

Identifikation wesentlicher Aufgaben hilfreicher Ansatz zur Reduktion von Komplexität

Aufzeigen kausaler bzw. temporaler Zusammenhänge

Unterstützen Projektmanagement

Qualität hängt wesentlich von der Erläuterungen der Einsatzvoraussetzung ab

Zielkonflikt zwischen Allgemeingültigkeit und Detaillierung (Entgegenwirken durch Konfigura-

tion und Anpassung)

I.d.R. eher pragmatisch als akademisch ausgerichtet

Kapitel 5: Modellieru ngsmethoden

Ansätze zur Unterstützung der Erstellung von komplexen Modellen

Systemanalyse

Frank Schürmann | Wintersemester 2007/2008 9

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Ziele:

Zweck des zu entwickelnden Systems konkretisieren

Angemessenes Verständnis der betrachteten Domäne entwickeln und dokumentieren

Systemanforderungen möglichst vollständig erfassen und strukturieren

Wirksame Unterstützung des anschließenden Entwurfs

Aufgaben:

Systemanforderungen in unterschiedlichen Abstraktionen (Modellen) erfassen und do-

kumentieren

Erfassung und Bewertung von Anforderungsalternativen

Dazu: Kommunikation mit Auftraggebern und Anwendern

Herausforderungen:

Angemessene Entscheidung über Vollständigkeit der Anforderungen treffen, Bewertung

der Kosten weiterer Detailanalysen und deren Nutzen

Abgrenzung der betrachteten Domäne (Wiederverwendungspotenziale), Differenzierung

zwischen invarianten und variierenden Anforderungen

Angemessen Abstraktion von vorgefundenen Handlungsmustern (sind die vordergründig

formulierten Anforderungen überhaupt zukunftsfähig)

Maßnahmen zur Unterstützung:

Bereitstellung möglicher Analyseziele und -kriterien

Checklisten zur Überprüfung typischer Risiken/Probleme

Methoden zur Unterstützung der Anforderungserhebung (Interviews, Workshops, Proto-

typen)

Konzepte zur angemessenen Strukturierung/Dokumentation von Analyseergebnissen

(Referenz-)Domänenmodelle

Systementwurf

Ziele:

Festlegung einer anforderungsgerechten Systemarchitektur * Detaillierte Spezifikation wesentlicher Systemeigenschaften

Wirksame Unterstützung der anschließenden Implementierung

Aufgaben:

Erstellung von Entwurfsdokumenten, schrittweise Verfeinerung der Analysemodelle

Erfassung und Bewertung von Entwurfsalternativen

Auswahl der Entwurfs- und Implementierungswerkzeugen * Dazu: Kommunikation mit Auftraggebern und Anwendern

Herausforderungen:

Angemessener Kompromiss zwischen Eigenerstellung und Wiederverwendung

Festlegung des Abstraktions-/Wiederverwendungsgrades (erhöht den Aufwand)

Einbettung des zu entwickelnden Systems in existierende Systemlandschaft

Angemessene Balance zwischen Anpassung an Implementierungstechnologien und Ab-

straktion von diesen

Angemessene Balance zwischen wirtschaftlichen Randbedingungen und technisch Mach-

barem

Maßnahmen zur Unterstützung:

Referenzentwürfe als Anleitung, Kriterienkataloge, Entwurfsfehlerverzeichnisse

Qualitätskriterien zur Bewertung von Entwürfen

Frank Schürmann | Wintersemester 2007/2008 10

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Bereitstellung geeigneter Modellierungssprachen & unterstützenden Werkzeugen

Unterstützung der Einbindung vorhandener Daten durch Modellierung der beteiligten

Systeme

Implementierung

Ziele:

Realisierung des Systems, Umsetzung der Architektur

Erstellung eines lauffähigen Systems nach Vorgaben des Entwurfs

Aufgaben:

Erfassung, Bewertung und Auswahl von Implementierungswerkzeugen und -sprachen

Erstellung von Implementierungsdokumenten (meistens Code)  vorteilhaft ist es, wenn

die Modelle aus dem Entwurf automatisch in Code umgewandelt werden

Komponieren von existierender Software

Festlegung von Schnittstellen

Integration des Systemkomponenten, möglicherweise Anpassung der vorhandenen

Software

Herausforderungen:

Erstellung von qualitativ hochwertigem Code erfordert angemessene Kriterien zur Beur-

teilung von Qualität

Auswahl von Sprachen und Werkzeugen erfordert Einarbeitung, dadurch aber subtile Be-

einflussung der Entscheider

Maßnahmen zur Unterstützung:

Regeln für die Umsetzung des Entwurfs in Code

Durch Einsatz von geprüften Code-Generatoren wird Code erzeugt, der hohen Qualitäts-

anforderungen genügen sollte, außerdem ist der Code dann immer gleich strukturiert

durch eingebaute Muster, jedoch keine simultane Änderung von Modell und Code mög-

lich

Repositories zur Unterstützung des Code-Managements

Test

Ziele:

Sicherstellung, dass das Systemverhalten akzeptabel ist und mit den Anforderungen kor-

respondiert

Ermittlung der Teile des Systems, die nicht korrekt funktionieren, besonders wichtig ist

die Ermittlung der Ursachen

Fehlerfreiheit kann i.a.R. nicht getestet werden, da zu beweisen ist, dass man alle denk-

baren Konstellationen der Programmbenutzung durch Testszenarien abgedeckt hat

Optimal wäre eine Verifizierung der Software, was aber mit einer mathematischen Auf-

wand verbunden ist, der i.d.R. nicht zu leisten ist

Sollte so früh wie möglich beginnen - am besten mit der Anforderungsanalyse

Aufgaben:

Ermittlung von Testfällen

Bereitstellung von Testdaten, Implementierung von Testszenarien

Herausforderungen:

Festlegung des angemessenen Testaufwands

Entscheidung über Zustand ausreichender Qualität

Maßnahmen zur Unterstützung:

Frank Schürmann | Wintersemester 2007/2008 11

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Anleitung zum systematischen Test

Automatisierte Testverfahren * Verzeichnisse typischer Fehler

Funktionale Analyse

Zentrale Annahme: Zum Verständnis dessen, was in einem Unternehmen abläuft, ist es hilf-

reich, zunächst auf die Funktionen zu schauen, und nicht auf Objekte oder Datenstrukturen

Für Anwender meist verständlicher als die Datenmodellierung, jedoch Spezifikation von

Funktionen nicht vorgesehen, außerdem schwache Integration mit Datenmodellen

Beispiel: Datenflussdiagramme

Strukturierte Analyse

Ein Ansatz um die Komplexität heutiger Systeme zu bewältigen ist die Verwendung unter-

schiedlicher Abstraktionsebenen

Beginn bei einer hohen Ebene (z.B. mit einem Kontextdiagramm) und dann wird Schritt für

Schritt dekomponiert  Top-Down-Methode

Im Gegensatz zum Datenflussdiagramm erlaubt die strukturierte Analyse die Prozessspezifi-

kation durch Minispecs (natürlichsprachlicher Text, Pseudocode, Flussdiagramm oder Nassi-

Schneidermann-Diagramm)

Relativ weit verbreitet, Werkzeugunterstützung, schrittweise Dekomposition fördert Über-

sichtlichkeit und trägt zur Komplexitätsreduktion bei

Structured Analysis and Design Technique

Betont ähnlich wie S.A. die schrittweise Verfeinerung von Funktionen ("Activities")

Verwendung von Aktigrammen, ähnlich wie DFDs, aber etwas reichhaltiger (z.B. Darstellung

von Steuerdaten und Kontrollflüssen sowie Berücksichtigung von Ressourcen)

Zusätzliche Semantik durch Unterscheidung von Steuerdaten, Ein- und Ausgangsdaten, aber

Unterscheidung nicht immer eindeutig

Berücksichtigung von Ressourcen unterstützt die Analyse von Geschäftsprozessen, jedoch

sind die Ressourcen nicht weiter beschreibbar, kein organisatorischer Kontext

Soft Systems Methodology

Basiert auf der Annahme, dass soziale Handlungssysteme mit rein formalen Ansätzen nur un-

vollständig und verzerrt beschrieben werden können, da sie zum Teil "soft" sind

Betont die Bedeutung der Sichtweisen der in den jeweiligen Systemen handelnden Personen

Modellierung als interaktiver Prozess unter Beteiligung der betroffenen Anwender

Kommunikation und Veränderung steht im Vordergrund

Verschiedene Betrachtungsebenen:

Political system analysis

Welche Interessen gibt es in dem betroffenen System, mit welcher Macht sind die

Interessen jeweils ausgestattet?

Wie ist das Konfliktpotential? Sind Konflikte eher produktiv oder destruktiv?

Social system analysis

Welche Rollen gibt es in dem betrachteten System, welche Erwartungen und Normen

sind mit ihnen verbunden?

Welche Werte und kulturellen Besonderheiten sind zu berücksichtigen?

Role analysis

Welche Themen beschäftigen die beteiligten Akteure/Rollen?

Wo sehen die Akteure besondere Probleme?

Frank Schürmann | Wintersemester 2007/2008 12

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Wie ist die Problemwahrnehmung und -bewertung jeweils begründet?

Struktur für die Beschreibung von Handlungssysteme: Customers - Actors - Transformation

Process - Weltanschauung - Ownership - Environmental Constraints (CATWOE)

Rich pictures: Veranschaulichung einer Problemdomäne durch selbstsprechender Bilder aus

individuellen Sichten

Würdigung:

Ausgangshypothese durchaus plausibel

Eher Methode (bestehend aus einem Ansatz zur Strukturierung und einer Vorgehenswei-

se) als Methodologie (Lehre von Methoden)

Berücksichtigung politischer und sozialer Einflussfaktoren häufig wichtig

Syntax und Semantik von Rich Pictures weitgehend beliebig

Kapitel 6: Prozessbasierte Modellierung

Geschäftsprozesse haben eine zentrale Bedeutung für die Unternehmensorganisation

Ableitung der Ziele von Geschäftsprozessen aus der Unternehmensstrategie

Ableitung der Organisationsstruktur aus den Anforderungen der Prozesse

Definition: Ein Geschäftsprozess ist eine wiederkehrende Abfolge von Aktivitäten, die mehr

oder weniger rigiden Regelungsmustern genügt. Er ist zielgerichtet und steht in einem direk- ten Zusammenhang mit der marktgerichteten Leistungserstellung eines Unternehmens. Sol- che Prozesse, die unmittelbar und in bedeutsamem Umfang zur Erzeugung von Erträgen füh-

ren und gleichzeitig wettbewerbsrelevante Kompetenzen eines Unternehmens fordern, be-

zeichnet man als Kernprozesse. Die Ausführung von Geschäftsprozessen erforder den Einsatz

knapper Ressourcen. Ein Geschäftsprozesstyp beschreibt eine Klasse gleichartiger Ge- schäftsprozesse.

Ein Geschäftsprozessmodell ist eine Abstraktion eines Geschäftsprozesstyps. Sie bilden eine gute

Grundlage (anschaulich, Prozessorientierung kommt der Wahrnehmung und Konzeptualisierung

vieler Betrachter entgegen) für die Kommunikation zwischen Führungskräften, Anwendern und IT-Experten.

Business Process Reengineering: Radikaler Reorganisationsansatz zur Steigerung der Wettbe-

werbsfähigkeit von Unternehmen, Prozesse wichtiger als Organisation, Informationstechnologie

spielt dabei eine zentrale Rolle. Aber: Forderung nach Bruch mit Tradition problematisch, da Tra- ditionen häufig wettbewerbsrelevante Kompetenzen transportieren und die Motivation der Mi- tarbeiter gefährdet werden kann. Angemessene, reflektierte Anwendung kann jedoch eine sinn- volle Idee für eine innovative, wettbewerbsorientierte Unternehmensführung sein.

Prozessbasierte Modellierungsmethode

Auf die Lösung einer Klasse von Problemen gerichtet

Basis: geeignetes Modell eines Geschäftsprozess

Dazu erforderlich: Sprache zur Modellierung von Geschäftsprozessen * Spezifische Ergänzungen im Hinblick auf die jeweilige Problemklasse

Ausnahme: Tritt selten auf (ist nicht der Normalfall), wird daher nicht als normales Ereignis mo-

delliert, muss aber trotzdem berücksichtigt werden. Ausnahmen sollten systemweit modelliert

werden, so dass es einheitliche, konsistente Ausnahmebehandlungen für den Anwender gibt. Ab-

straktion über die möglichen Ausnahmen in allen Anwendungskontexten, bei Gemeinsamkeiten Zusammenfassung zu systemweiten Ausnahmen mit einheitlichen Behandlungsroutinen.

Frank Schürmann | Wintersemester 2007/2008 13

[[Image:]]Unternehmensmodellierung [ZUSAMMENFASSUNG]

Der Detaillierungsgrad eines Modells hängt vom Ziel und von der Zielgruppe ab. Es wird soweit

detailliert, bis alle Unklarheiten beseitigt sind und eine fundierte Diskussionsgrundlage geschaf- fen worden ist.

Wann ist eine Parallelisierung sinnvoll? Hängt von der Wahrscheinlichkeit ab, wie oft die ent-

sprechenden Zweige durchlaufen werden. Außerdem muss auf den Wettbewerbsfaktor geachtet werden, möglicherweise ist der Faktor Zeit wichtiger als der Faktor Kosten.

Eine Methode besteht aus einer Vorgehensweise und einer (Fach-)Sprache. Bestandteile einer

Modellierungsmethode sind zum einen die Modellierungssprache zur problemadäquaten Struk- turierung des Untersuchungsgegenstands (Fachbegriffe/Konzepte), des Weiteren Heuristiken

und Evaluationskriterien zur Beurteilung von Alternativen sowie Vorgehensmodelle zur Problem-

lösung. Beispiele: Methode zur Organisationsanalyse und -gestaltung, Methode zur Software-

Entwicklung, Methode zur Gestaltung unternehmensübergreifender IT-gestützter Geschäftspro-

zesse

Generische Heuristiken zur Geschäftsprozessanalyse:

Systematische Komplexitätsreduktion: Zerlegung eines komplexen Prozesses in überschauba-

re Teilprozesse, Nutzung von Kompositions-/Dekompositionsbeziehungen

Zielorientierung: Sind die Ziele des Gesamt-/Teilprozesses klar definiert? Gibt es geeignete

Indikatoren zur Überprüfung der Zielerreichung?

Mitarbeiter: Wie ist die Eignung der beteiligten Mitarbeiter zu beurteilen (Qualifikation, Mo-

tivation, Zielorientierung)?

Vereinfachungspotentiale: Kann der Ablauf vereinfacht werden? Gibt es redundante bzw.

sehr ähnliche Tätigkeiten? Können Teilprozesse vereinfacht werden?

Auslagerung: Können Teilaktivitäten an anderen Orten durchgeführt oder an andere Unter-

nehmen ausgelagert werden?

Automatisierungspotentiale: Gibt es Medienbrüche? Gibt es Möglichkeiten für den Einsatz

von Standardsoftware? Gibt es Formalisierungsmöglichkeiten?

Method Engineering: Konfiguration spezifischer Modellierungsmethoden. Prozesse von Ge-

schäftsprozessmodellen als Ausgangslage, dann Hinzufügen von dedizierten Konzepten zur Un-

terstützung spezieller Analyse- und Entwurfsaufgaben und anschließend Abstimmung mit dedi-

ziertem Vorgehensmodell

Detaillierung einzelner Phasen durch z.B. folgende Punkte: Ziele/Gegenstand, Verwendbare

Dokumente, Beteiligte, Methoden/Heuristiken, Erstellte Dokumente

Zu einzelnen Prozessen betriebswirtschaftliche Eckdaten wie Anzahl der Instanzen, Umsatz-

varianz und Kundenzufriedenheit erfassen

Festlegung von Analyse- und Entwurfszielen: Detaillierte Bewertung des status quo (Kosten,

Durchlaufzeit, Kundennutzen, Vergleich mit Wettbewerb), dann Entwurf eines verbesserten

Prozesstyps (höherer Kundennutzen, geringere Kosten)

Grob-Modellierung des Ist-Zustandes, Interviews mit Beteiligten und Dokumentation durch

erstes Modell

Erste Bewertung, anschließend Detaillierung unklarer Bereiche (Relevanz, Funktionen, Dauer,

Ausnahmen, Häufigkeit, Automatisierbarkeit, Medium)

Neugestaltung des Prozesses, anschließend Evaluation (Überprüfung des Entwurfs mittels

der zuvor formulierten Ziele, Vergleich mit Performanz der Konkurrenz, evtl. Simulation, dazu

muss das Modell aber eine gute Repräsentation der Realität sein)

Frank Schürmann | Wintersemester 2007/2008 14