Wintersemester Systementwicklung: Grundlagen. Prof. Dr. Christoph Rosenkranz. Katholische Universität Eichstätt-Ingolstadt

Wintersemester 2016-2017 Systementwicklung: Grundlagen Prof. Dr. Christoph Rosenkranz Katholische Universität Eichstätt-Ingolstadt

1 Informationsmanagement 1.1 Strategisches IT-Management 1.2 Operatives IT-Management 2 Grundprinzipien der Modellierung von Informationssystemen Gliederung 2.1 Architekturorientierte Modellierung 2.2 Objektorientierte Modellierung 3 Vorgehensmodelle der Systementwicklung 3.1 Wasserfall-Modell 3.2 Prototyping 3.3 Spiral-Modell 3.4 V-Modell 3.5 Unified Process 3.6 Agile Softwareentwicklung

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungssichten 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML 5.1 Objektorientierte Systementwicklung mit UML 5.2 Kombination von UML mit ARIS

Literatur I 3 Hinweis: Die Folien basieren auf dem Skript von Prof. Dr. Klaus Wilde aus dem WiSe 2015-2016 Abts, D.; Mülders, W. (2011): Grundkurs Wirtschaftsinformatik, 7. Aufl., Wiesbaden. Alpar, P.; Grob, H. L.; Weimann, P.; Winter, R. (2011): Anwendungsorientierte Wirtschaftsinformatik, 6. Aufl., Wiesbaden. Biethahn, J.; Mucksch, H.; Ruf, W. (2004): Ganzheitliches Informationsmanagement, Band I: Grundlagen, 6. Aufl., München. Bleek, W. G.; Wolf, H. (2010): Agile Softwareentwicklung, 2. Aufl., Heidelberg. Ferstl, O. K.; Sinz, E. (2008): Grundlagen der Wirtschaftsinformatik, 6. Aufl., München. Gadatsch, A. (2010): Grundkurs Geschäftsprozess-Management, 6. Aufl., Wiesbaden. Grief, J. (2005): ARIS in IT-Projekten, Wiesbaden. Hansen, R.; Neumann, G. (2009): Wirtschaftsinformatik 1, Grundlagen und Anwendungen, 10. Aufl., Stuttgart.

Literatur II 4 Holey, T.; Welter, G.; Wiedemann, A. (2007): Wirtschaftsinformatik, 2. Aufl., Ludwigshafen. Hubwieser, P.; Mühling, A.; Aiglstorfer, G. (2012): Fundamente der Informatik, 2. Aufl., München Lassmann, W. (Hrsg.) (2006): Wirtschaftsinformatik, Wiesbaden. Laudon, K. C.; Laudon, J. P.; Schoder, D. (2009): Wirtschaftsinformatik, 2. Aufl., München. Ludewig, J.; Lichter, H. (2010): Software Engineering, 2. Aufl., Heidelberg. Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M.; Hess, T. (2010): Grundzüge der Wirtschaftsinformatik, 10. Aufl., Berlin. Pomberger, G.; Dobler, H. (2008): Algorithmen und Datenstrukturen, München. Seidlmeier, H. (2010): Prozessmodellierung mit ARIS, 3. Aufl., Wiesbaden. Stahlknecht, P.; Hasenkamp, U. (2005): Einführung in die Wirtschaftsinformatik, 11. Aufl., Berlin.

1 Informationsmanagement 1.1 Strategisches IT-Management Gliederung 1.2 Operatives IT-Management 2 Grundprinzipien der Modellierung von Informationssystemen 2.1 Architekturorientierte Modellierung 2.2 Objektorientierte Modellierung 3 Vorgehensmodelle der Systementwicklung 3.1 Wasserfall-Modell 3.2 Prototyping 3.3 Spiral-Modell 3.4 V-Modell 3.5 Unified Process 3.6 Agile Softwareentwicklung

Unternehmensstrategie und strategische Informationssysteme 6 Strategische Ansatzpunkte des IS-Einsatzes IT follows process/process follows IT? Quelle: Mertens et al. 2004, S. 182

Strategisches IT-Management: Konzeption der IT-Infrastruktur 8 IT-Strategie (Strategische Ziele des IT-Einsatzes) IS-Architektur (Identifikation kritischer Anwendungssysteme zur Realisierung der strategischen Ziele) IT-Architektur (Grundsatzentscheidungen zu Hardware, Systemsoftware, Vernetzung) Priorisierung von IT-Projekten (Realisierung von IS-Architektur und IT-Architektur durch Vielzahl von IT-Projekte, die um knappe Ressourcen konkurrieren)

Operatives IT-Management: Aufbau und Betrieb der IT-Infrastruktur 10 Aufgaben des operativen IT-Managements Quelle: Stahlknecht/Hasenkamp 2005, S. 438 f. Rechenzentrum Systementwicklung Benutzerservicezentrum Operatives IT-Controlling

Systementwicklung 11 Entwicklung, Wartung, Weiterentwicklung und Einführung neuer Anwendungssysteme in Form von IT-Projekten Systementwicklung erfolgt meist nach einem phasenorientierten Vorgehensmodell Abgrenzung von Systementwicklung und Projektmanagement: Quelle: Stahlknecht/Hasenkamp 2005, S. 459

Informationssystemmodellierung 13 Entwurf des Bauplans für ein IS Kernfrage: Was genau soll in einem IS passieren? Welche Funktionen sollen ausgeführt werden? Welche Daten werden dazu benötigt? Wie sollen Geschäftsprozesse ablaufen? Welche Abhängigkeiten existieren dabei? Die verständliche Beschreibung erfordert eine Komplexitätsreduktion durch Partitionierung: Aufteilung eines großen Problemkreises in mehrere kleinere und somit besser handhabbare Teilprobleme. Abstraktion: Konzentration auf wesentliche Fakten des Systems, während andere nicht aspektrelevante Details ausgeblendet werden. Projektion: Betrachtung des gleichen Sachverhalts aus unterschiedlichen Perspektiven. Diese ergeben sich sowohl aus der Sichtweise verschiedener Personengruppen (Anwender, Entwickler etc.) als auch aus technischen Gesichtspunkten und erschließen tendenziell unterschiedliche Aspekte einer möglichen Problemlösung. Abbildung eines komplexen IS durch eine Vielzahl von Modellen der betrachteten Realitätsausschnitte. Quelle: Hansen/Neumann 2005, S. 169 ff.

ARIS-Architekturmodell 15 Architektur integrierter Informationssysteme (ARIS) von A.-W. Scheer Integrationskonzept zur ganzheitlichen Betrachtung IT-basierter Geschäftsprozessen Komplexitätsreduktion durch Partitionierung in verschiedene Sichten Beschreibung der Prozesse in diesen Sichten auf unterschiedlichem Abstraktionsniveau in drei Schichten Quelle: Hansen/Neumann 2005, S. 178 f.

Objektorientierte Systementwicklung 17 Zwei Kernprobleme der architekturorientierten Systementwicklung Getrennte Betrachtung von Daten und Funktionen Abstimmungsprobleme zwischen den beiden Modellen Alle Phasenübergänge der Systementwicklung bereiten Probleme Methodenbrüche Als Alternative wurde die objektorientierte Systementwicklung entwickelt. Ein Objekt besteht aus Attributen, die die Eigenschaften des Objekts beschreiben. Methoden, die das Verhalten des Objekts beschreiben. Trennung zwischen Daten und Funktionen aufgehoben Das Konzept der Objektorientierung lässt sich über alle Phasen hinweg, d. h. ohne Methoden- bzw. Strukturbruch, anwenden. Objektorientierte Systementwicklung basiert auf drei Grundprinzipien: Objektbildung und Datenkapselung Klassenbildung und Vererbung Botschaftenkommunikation und Polymorphismus Quelle: Stahlknecht/Hasenkamp 2005, S. 270 ff.

Objektbildung und Datenkapselung 18 Objekte sind konkrete Personen, Gegenstände oder abstrakte Begriffe (z. B. Rechnung). Sie besitzen neben Eigenschaften, die durch Attributwerte beschrieben werden, zusätzlich ein Verhalten, das durch Methoden ausgedrückt wird. Beispiel: Objekt Student Hans Hartknecht Eigenschaften: 1234567 (Matrikel Nr.), 23.03.1986 (Geburtstag), Verwaltungswissenschaften (Studiengang) Methoden: Teilnehmen (an Klausuren), Anmelden (zu Seminaren), Exmatrikulieren (nach Examen) Datenkapselung bedeutet, dass die Attributwerte eines Objekts nur durch dessen Methoden und nicht von außen geändert werden können (Information Hiding). Quelle: Stahlknecht/Hasenkamp 2005, S. 272 f.

Klassenbildung und Vererbung 19 Eine Klasse wird durch die Zusammenfassung von Objekten mit den identischen Attributen und Methoden gebildet. Belegte (konkrete) Objekte aus der Klasse werden als Instanz bezeichnet, z. B. Klasse: Kunde Instanzen: Martha Meier, Manfred Müller Quelle: Stahlknecht/Hasenkamp 2005, S. 273

Klassenbildung und Vererbung 20 Objekte, die in der Realität in einer hierarchischen Beziehung stehen, können durch ein hierarchisches Klassenkonzept (dargestellt als Klassendiagramm) abgebildet werden. Gemeinsamkeiten von verschiedenen Klassen können durch Vererbungsmechanismus erfasst werden. Jede Klasse (Subklasse) erbt die Attribute und Methoden der darüberliegenden Klasse (Superklasse). Quelle: Stahlknecht/Hasenkamp 2005, S. 274

Botschaftenkommunikation und Polymorphismus 21 Zwischen den Objekten werden Botschaften (Anweisungen) ausgetauscht. Jede Botschaft enthält den Namen des Empfängerobjekts sowie den Namen der Methode, die das Empfängerobjekt ausführen soll. Das Empfängerobjekt führt die Methode aus. Ist die Methode in der Klasse nicht zu finden, wird automatisch in der Superklasse gesucht. Ein wesentliches Merkmal der Botschaftenkommunikation ist der Polymorphismus: eine Botschaft, die an Objekte verschiedener Klassen gesendet wird, kann dort unterschiedliche Reaktionen auslösen. Z. B. führt die Botschaft Berechne_Zinsen bei Girokonten zu anderen Operationen als bei Termingeldkonten. Quelle: Stahlknecht/Hasenkamp 2005, S. 277 ff.

Botschaftenkommunikation und Polymorphismus 22 Quelle: Stahlknecht/Hasenkamp 2005, S. 278

Vorgehensmodelle der Systementwicklung 24 Phasenschema der Systementwicklung Aufgliederung des kontinuierlichen Entscheidungsprozesses in mehrere Entwicklungsstufen zur Komplexitätsreduktion Unterteilung der Phasen entsprechend der Abfolge wichtiger Entscheidungen Quelle: Hansen/Neumann 2005, S. 264 f.; Stahlknecht/Hasenkamp 2005, S. 218

Softwarelebenszyklus-Modell 25 Ausgangspunkt aller gängigen Vorgehensmodelle Zyklus im Sinne einer wiederholten Ausführung der Phasen Streng sequentieller Entwicklungsprozess: Ein Rücksprung zu vorherigen Phasen oder deren Wiederholung wird nicht zugelassen. Eine neue Phase darf erst begonnen werden, wenn die vorhergehende abgeschlossen ist. Nachteile: Unrealistisch, da Phasen häufig überlappen, fehlende Informationen nachträglich ergänzt werden müssen etc. Änderungswünsche können nicht mehr berücksichtigt werden, da greifbare Ergebnisse erst zu einem relativ späten Zeitpunkt vorliegen. Problemstellung Quelle: Hansen/Neumann 2005, S. 265 f. Systemtest Betrieb und Wartung Implementierund Komponententest Problemanalyse System- und Komponentenentwurf Systemspezifikation

Wasserfall-Modell 27 Problemanalyse V Projektauftrag, Grobplan Systemspezifikation Grobentwurf V V Pflichtenheft Datenmodell, Systemarchitektur Quelle: Hansen/Neumann 2005, S. 267 Feinentwurf Implementierung Integration V Installation V V V Betrieb & Wartung Algorithmische Struktur der IS-Komponenten Programme und Dokumentation Endprodukt V

Wasserfall-Modell 28 Weiterentwicklung des Softwarelebenszyklus: Verfeinerung der Projektphasen: Aufspaltung der Entwurfsphase in Grob- und Feinplanung, zusätzliche Installationsphase. Bei jeder Phase sind Rückkopplungen zur vorhergehenden Phase möglich wenn sich deren Ergebnisse als fehlerhaft erweisen und korrigiert werden müssen. Iterationen über mehrere Phasen sind wegen hoher Nachbearbeitungskosten nicht erlaubt. Jede Projektphase endet mit einem Validierungsprozess. Die Validierung sollte möglichst experimentell mit einem Prototypen (ausführbare Vorversion des IS) erfolgen. Nachteile: Alle Anforderungen müssen vollständig zu Beginn bekannt sein, was in der Praxis nicht immer realisierbar ist. Jede Entwicklungsaktivität muss nach ihrer Bearbeitung abgeschlossen sein. Quelle: Hansen/Neumann 2005, S. 268

Prototyping 30 Ergänzendes Konzept zu traditionellen Phasenkonzepten, das deren Nachteile aufhebt bzw. abschwächt. Realisierung einer vereinfachten Version des IS (Prototyp) in einem Pilotprojekt, um für wichtige, aber noch offene Fragen (z. B. Benutzerschnittstellen, Datenstrukturen, Methoden) praktische Erkenntnisse zu sammeln. Qualitätssicherung und Risikominderung in der IS-Entwicklung, indem die Kluft zwischen Benutzer und Entwickler über eine frühzeitige Abstimmung von Anforderungen und Softwarerealisation aufgehoben wird. Verschiedene Lösungsalternativen können mit geringem Aufwand durchgespielt und ein besonders guter Entwurf ausgewählt werden. Quelle: Biethahn et al. 2004, S. 249 f.

1 Informationsmanagement Gliederung 1.1 Strategisches IT-Management 1.2 Operatives IT-Management 2 Grundprinzipien der Modellierung von Informationssystemen 2.1 Architekturorientierte Modellierung 2.2 Objektorientierte Modellierung 3 Vorgehensmodelle der Systementwicklung 3.1 Wasserfall-Modell 3.2 Prototyping 3.3 Spiral-Modell 3.4 V-Modell 3.5 Unified Process 3.6 Agile Softwareentwicklung

Spiral-Modell 32 Quelle: Hansen/Neumann 2005, S. 268

Spiral-Modell 33 Verfeinerung des Wasserfall-Modells: Die IS-Entwicklung wird dabei als evolutionärer Prozess angesehen. In den einzelnen Spiralzyklen wird sowohl der Gesamtaufwand als auch der Projektfortschritt dargestellt. Am Anfang der Spirale müssen folgende Punkte festgelegt werden: Ziele für und Anforderungen an das Produkt (z. B. Einsatzbereich, Funktionalität etc.), Alternativen zur Realisierung des Produkts (z. B. partielle Wiederverwendung vorhandener IS, Zukauf etc.), Nebenbedingungen und Einschränkungen (z. B. Kosten, Termine etc.). Danach erfolgt in jedem Zyklus eine Risikoanalyse, eine Weiterentwicklung des Prototyps und ein Validierungsschritt. Vorteile: Frühes Erkennen von Fehlern und Abwägen von Lösungsalternativen. Benutzer werden durch Prototyping bereits frühzeitig in den Entwicklungsprozess eingebunden. Keine strikte Trennung von Entwicklung und Wartung mehr. Nachteil: Hoher Managementaufwand, da oftmals neue Entscheidungen Quelle: Hansen/Neumann 2005, S. 269 f.

V-Modell 35 Anforderungsdefinition Anwendungsszenarien Abnahmetest Validierung Grobentwurf Testfälle Systemtest Feinentwurf Testfälle Integrationstest Verifikation Testfälle Modulimplementation Modultest Validierung: Eignung Produkt auf seinen Einsatzzweck Verifikation: Übereinstimmung Produkt mit seiner Spezifikation

Submodelle des V-Modells 36 Projektmanagement (PM) Initialisierung eines Projekts (Projektplan und -handbuch) Projektbegleitung Projektabschluss (Projektabschlussbericht usw.) Softwareerstellung (SWE) Requirements-Engineering Grob- und Feinentwurf der Software bzw. des IS Implementierung Integration Qualitätssicherung (QS) Planung der Qualitätssicherung (Prüfpläne usw.) Prozessprüfungen Produktprüfungen Berichtswesen zur Qualitätssicherung Konfigurationsmanagement (KM) Verwalten von Konfigurationen Änderungsmanagement (Verwaltung von Fehlermeldungen und Anforderungsdefinition) Maßnahmen zur Datensicherung Quelle: Hansen/Neumann 2005, S. 275 ff.

Unified Process (UP) 38 Der UP vereint die Vorteile von Phasenmodellen und nichtlinearen Prozessmodellen: UP ist iterativ Ermöglicht eine inkrementelle Produktentwicklung (in kleinen Schritten zur kontinuierlichen Verbesserung) Der UP definiert 5 Kernarbeitsabläufe, die sich über alle Phasen erstrecken: Requirements, Analysis, Design, Implementation und Test. Als Phasenmodell definiert der UP folgende vier Phasen: Inception Phase (Projektsetup, Konzeptualisierung): Bestimmung welche Funktionen vom Software-System erfüllt und welche Use-Cases abgedeckt werden sollen. Elaboration Phase (Ausarbeitung, Entwurf): Schrittweise Verfeinerung und Implementierung der Kernarchitektur. Komponenten mit hohem Risiko werden vorab realisiert. Zudem werden wesentliche funktionale und technische Anforderungen identifiziert und modelliert. Construction Phase (Implementierung): Iterative Implementierung und Test des Systems Transition Phase (Übertragung, Inbetriebnahme): Systemstabilisierung und Übergabe an den Anwender Quelle: Ludewig/Lichter 2007, S. 190 ff.

Phasen, Iterationen und Arbeitsabläufe beim UP 39 Quelle: Ludewig/Lichter 2007, S. 195

Agile Softwareentwicklung 41 Agile Prozesse sind Vorgehensmodelle mit wenig Formalismen, intensiver Interaktion. Minimierung abstrakter Entwicklungsschritte und rascher Einstieg in die konkrete Entwicklungsphase. Schnellstmöglich Generierung ausführbarer Software, deren Entwicklung laufend mit Kundenbedürfnissen abgeglichen wird. Beispiele für agile Prozesse: Extreme Programming (XP) Usability Driven Development (UDD) Feature Driven Development (FDD) Quelle: http://de.wikipedia.org/wiki/agile_softwareentwicklung

Agile Softwareentwicklung 42 Agile Prozesse sind Vorgehensmodelle mit wenig Formalismen, intensiver Interaktion. Minimierung abstrakter Entwicklungsschritte und rascher Einstieg in die konkrete Entwicklungsphase. Schnellstmöglich Generierung ausführbarer Software, deren Entwicklung laufend mit Kundenbedürfnissen abgeglichen wird. Beispiele für agile Prozesse: Extreme Programming (XP) Usability Driven Development (UDD) Feature Driven Development (FDD) Quelle: http://de.wikipedia.org/wiki/agile_softwareentwicklung

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML 5.1 Objektorientierte Systementwicklung mit UML 5.2 Kombination von UML mit ARIS

Geschäftsprozess und Workflow 44 Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von IuK- Technologien ausgeführt werden können. dient der Erstellung von Leistungen entsprechend den aus der Unternehmensstrategie abgeleiteten Prozesszielen. kann formal auf unterschiedlichen Detaillierungsebenen und aus mehreren Sichten beschrieben werden. Ein Workflow ist ein formal beschriebener, ganz oder teilweise automatisierter Geschäftsprozess (z. B. Urlaubsantrag, Beschaffung von IT-Zubehör etc.). beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatisierte Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte können durch Mitarbeiter oder durch Anwendungsprogramme durchgeführt werden. Quelle: Gadatsch 2003, S. 29 ff.

Geschäftsprozess 45 Quelle: ARIS Methode

Geschäftsprozesssicht des Unternehmens 46 Die Unternehmung kann beschrieben werden als System vernetzter Geschäftsprozesse. Abschluss eines Geschäftsprozesses startet einen oder mehrere nachfolgende Geschäftsprozesse. Start eines Geschäftsprozesses/Vorgangs erfordert u. U. mehrere Startereignisse, die von verschiedenen Geschäftsprozessen ausgelöst werden. Elemente eines Geschäftsprozess-Modells Vorgang: zeitverbrauchendes Geschehen der Informationstransformation Ereignis: zeitpunktbezogenes Geschehen, das am Anfang oder Ende eines Vorgangs steht Zustand: (zeitraumbezogene) Beschreibungen über die relevante Umwelt des Vorgangs (kann im Verlauf eines Vorgangs verändert werden) Bearbeiter: der für die Vorgangsbearbeitung zuständige Mitarbeiter Organisationseinheit: Organisationseinheit, welcher der Bearbeiter angehört IT-Ressourcen: die der Organisationseinheit zugeordneten informationstechnologischen Ressourcen

Abstraktionsebenen der Beschreibung 47 Metaebene Anwendungsebene "Klassen" Anwendungsebene "Instanzen" Vorgang Auftragsannahme Auftragsannahme Nr. 4712 Ereignis Auftragsbestätigung erstellt Auftragsbest. Nr. 4712 erstellt Zustand Kunde Kunde Nr. 0815 Bearbeiter Vertriebssachbearbeiter Vertriebssachbearbeiter Müller Organisationseinheit Verkaufsbüro Verkaufsbüro Ingolstadt IT-Ressource Notebook FJS Lifebook T PC Inv. Nr. 4231 Istanalyse arbeitet vorwiegend auf der Instanzen-Ebene Konzeption auf der Klassen-Ebene Modellierungs- und Analysewerkzeug arbeiten auf der Metaebene

ARIS: Architektur integrierter Informationssysteme 48 Standardisiertes Rahmenkonzept zur Darstellung und Konzeption des strukturellen Aufbaus des Entwicklungsprozesses betriebswirtschaftlicher Informationssysteme. Komplexitätsreduktion durch Bildung von Beschreibungssichten: Zerlegung des Geschäftsprozess-Modells in (weitgehend) unabhängige und weniger komplexe Beschreibungssichten Beseitigung von Redundanzen in der Geschäftsprozess-Modellierung durch gleiche Vorgänge, Ereignisse, Zustände, Bearbeiter, Organisationseinheiten, IT- Ressourcen in verschiedenen Geschäftsprozessen Quelle: ARIS Methode, Hansen/Neumann 2005, S. 178; Seidlmeier 2006, S. 13

Beschreibungssichten in ARIS 49 Vier Basissichten werden durch die Prozesssicht koordiniert: Datensicht: Zustände und Ereignisse und deren Struktur in redundanzfreier Form Funktionssicht: Informationstransformationsregeln und deren Struktur Organisationssicht: Bearbeiter und Organisationseinheiten (Ressourcensicht: IT-Ressourcen) Prozesssicht: Interdependenzen zwischen den Beschreibungssichten Jede Sicht kann ohne Detailkenntnis der anderen Sichten beschrieben werden. Quelle: ARIS Methode, Hansen/Neumann 2005, S. 178 f.; Seidlmeier 2006; S. 15

Komplexitätsreduktion durch Auflösung der Ressourcensicht 50 Ressourcensicht umfasst Vielzahl von Hard- und Softwarekomponenten. IT-Ressourcen unterliegen einem permanenten technologischen Wandel. Betriebswirtschaftliches Grundkonzept der Informationsverarbeitung Zeitlich wesentlich stabiler, vom kurzfristigen technologischen Wandel kaum beeinflusst IT-Ressourcen nur Rahmenbedingungen für technische Implementierung IT-Ressourcen verstellen oft den Blick für wichtige betriebswirtschaftliche Grundkonzepte Deshalb zuerst Konzentration auf die Konzeption des fachlichen Kerns, dann schrittweise informationstechnische Implementierung. Beschreibung der Ressourcensicht ersetzt durch Beschreibung des Weges zur Entwicklung einer Ressourcensicht.

Beschreibungsebenen in ARIS 51 Betriebswirtschaftliches Anwendungskonzept: Istanalyse und Sollkonzept der Geschäftsprozesse, Aufzeigen des Informationssystem-Nutzens Fachkonzept: Modellierung der einzelnen Sichten unabhängig von Implementierungsgesichtspunkten DV-Konzept: Anpassung des Fachkonzepts an Implementierungstools (Datenbanken, Programmiersprachen usw.) Technische Implementierung: Umsetzung in physische Datenstrukturen, Programme, Hardwarekomponenten usw. Quelle: Seidlmeier 2006, S. 23 f.

Das ARIS-Haus: Verknüpfen von Beschreibungssichten, -ebenen und Methoden 52 Betriebswirtschaftliche Problemstellung Organisationssicht Fachkonzept DV-Konzept Implementierung Fachkonzept Fachkonzept DV-Konzept DV-Konzept Implementierung Implementierung Datensicht Steuerungssicht Quelle: Seidlmeier 2006, S. 25 f. Fachkonzept DV-Konzept Implementierung Funktionssicht

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML 5.1 Objektorientierte Systementwicklung mit UML 5.2 Kombination von UML mit ARIS

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.1.1 Grundlagen 4.2.1.2 Modellierung mit ARIS 4.2.2 Fachkonzept 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

Beschreibungsebenen in ARIS 55 Quelle: Seidlmeier 2006, S. 24

Projektziele 57 Administrationssysteme (operative Geschäftsprozesse) Wirtschaftlichkeit Kosteneinsparungen Verringerung von Fehlerquoten Wettbewerbsvorteile Beschleunigung der Geschäftsprozesse Unternehmensübergreifende Integration von Geschäftsprozessen Neue/ bessere Dienstleistungen für Kunden Führungsinformationssysteme (Managementprozesse) Erhöhte Datenaktualität Bessere Datenverfügbarkeit Bessere Entscheidungsgrundlagen

Projektanstoß und Projektauftrag 58 Projektanstoß durch Unternehmensleitung, Fachabteilung oder DV-Abteilung (nur in Kooperation mit UL oder FA). Projektauftrag durch Unternehmensleitung, Leiter der Fachabteilung oder zentralen IT-Lenkungsausschuss, der über die Prioritäten und Finanzierung aller anstehenden IT-Projekte entscheidet. Quelle: Stahlknecht/Hasenkamp 2005, S. 223 ff.

Inhalt und Ablauf der Geschäftsprozessanalyse 59 Beschreibungssichten noch nicht voll ausdifferenziert: Funktionsanalyse: statische Beschreibung der betriebswirtschaftlich relevanten Tätigkeiten Prozessanalyse: Grobe logische und zeitliche Bearbeitungsreihenfolge der Funktionen (dynamisch) Zuordnung von groben Datenclustern und Organisationseinheiten zu Funktionen Ablauf Istanalyse: Erhebung des gegenwärtigen Istzustandes des Geschäftsprozesses Anforderungsdefinition: Entwicklung eines unternehmensspezifischen Soll-Konzepts Schwachstellenanalyse: Ableitung des Handlungsbedarfs durch Soll-Ist-Vergleich Prioritätendefinition: Bestimmung der Prioritäten der erkannten Schwachstellen

Informationsquellen der Geschäftsprozessanalyse 60 Interviews mit den Domänenexperten Workshops mit mehreren Domänenexperten Demonstration des bestehenden Geschäftsprozesses/Anwendungssystems Zielvorgaben Geschäftsvorfallbeschreibungen Maskenbeschreibungen Format- und Schnittstellenbeschreibungen Organisations- und System-Handbücher Quelle: Grief 2005, S. 58 ff.

Einsatz von Referenzmodellen 61 Referenzmodell Allgemein gültige Empfehlungen, auf die in Konstruktionsprozessen von Informationsmodellen Bezug genommen werden kann Quellen Vorangegangene Systementwicklungs-Projekte Fachliteratur Vorteile von Referenzmodellen Bessere Verständigung durch einheitliche Terminologie aus Referenzmodellen Vereinfachung/Beschleunigung der Abbildung unternehmensindividueller Prozesse durch generische Vorlage (Checkliste) Normative Wirkung einer übergeordneten Sichtweise auf unterschiedliche Interessengruppen ( state-of-the-art / best practice ) Effizientere/effektivere Geschäftsprozesse durch bewährte Lösungsansätze Risikominimierung durch Mehrfachvalidierung der Lösungsansätze Quelle: Brocke, Jan vom (2003): Referenzmodellierung Gestaltung und Verteilung von Konstruktionsprozessen, Berlin; Gadatsch 2003, S. 327 f.

Beispiel aus SAP CRM 62 SAP Business Scenario Maps: Bieten eine detaillierte Beschreibung branchenspezifischer und branchenübergreifender Szenarien (Geschäftsprozesse) und zeigen, wie SAP-Lösungen zur Unterstützung dieser Szenarien verwendet werden können. Quelle: SAP AG

Geschäftsprozessanalyse mit Referenzmodellen 63 Schwachstellenanalyse:

Lastenheft und Pflichtenheft 64 In einem Lastenheft wird von der Fachabteilung beschrieben, was ein IS fachlich leisten soll. Anschließend werden in einem Pflichtenheft von der IT-Abteilung sämtliche fachlichen und technischen Anforderungen zusammengestellt. Das Pflichtenheft ist die ausführliche Beschreibung der Leistungen, die erforderlich sind oder gefordert werden, damit die Ziele des Projekts erreicht werden (DIN 69901). Quelle: Stahlknecht/Hasenkamp 2005, S. 247 f.

Wertschöpfungskettendiagramm 66 Einstiegs- und Überblicksmodell auf einer sehr hoch verdichteten Ebene der Prozessdarstellung Bildet primär die Kernprozesse des Unternehmens mit hoher Wertschöpfung für den Kunden ab, weniger die Unterstützungsprozesse. Abfolge wertschöpfender Funktionen bildet eine Wertschöpfungskette. Zur weiteren Beschreibung werden organisatorische Zuständigkeiten hinterlegt. Hinterlegung von Detailmodellen Quelle: ARIS, Seidlmeier 2006, S. 71 f.

Wertschöpfungskettendiagramm 67 Quelle: ARIS Methode

Vorgangskettendiagramm (VKD) 68 Abbildung der betriebswirtschaftlichen Problemstellung in relativ hoher Verdichtung Spaltenorientierte Darstellung ausgewählter Tatbestände aus den Sichten und deren Beziehungen Quelle: ARIS Methode, Seidlmeier 2006, S. 66 f.

Beispiel: Vorgangskettendiagramm 69 Quelle: ARIS Methode

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.2 Fachkonzept 4.2.2.1 Fachkonzept der Funktionssicht 4.2.2.2 Fachkonzept der Datensicht 4.2.2.3 Fachkonzept der Organisationssicht 4.2.2.4 Fachkonzept der Prozesssicht 4.2.2.5 Wirtschaftlichkeitsanalyse 4.2.2.6 Kostenplanung 4.2.2.7 Terminplanung 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

Fachkonzept 71 Gegenstand der Entwicklung eines Fachkonzepts: Fachkonzepte für Funktions-, Daten-, Organisations- und Steuerungssicht auf der Basis der Geschäftsprozess-Analyse entwickeln. Wirtschaftlichkeitsuntersuchung (Kosten-Nutzen-Analyse) Detaillierung der Sollkonzepte für ausgewählte IS-Variante (u. U. parallele Grobkonzeption für mehrere Sollkonzepte bis zur Stufe der Wirtschaftlichkeitsuntersuchung) Kosten- und Terminplanung Mit einem Fachkonzept verbundene Zielsetzungen: Vertragsgrundlage Nachschlagewerk Handlungsanweisungen für Mitarbeiter Quelle: Grief 2005, S. 53 ff.

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.2 Fachkonzept 4.2.2.1 Fachkonzept der Funktionssicht 4.2.2.1.1 Grundlagen 4.2.2.1.2 Modellierung in ARIS 4.2.2.2 Fachkonzept der Datensicht 4.2.2.3 Fachkonzept der Organisationssicht 4.2.2.4 Fachkonzept der Prozesssicht 4.2.2.5 Wirtschaftlichkeitsanalyse 4.2.2.6 Kostenplanung 4.2.2.7 Terminplanung 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

73 Betriebswirtschaftliche Problemstellung Organisationssicht Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Datensicht Quelle: Seidlmeier 2006, S. 25 Fachkonzept DV-Konzept Implementierung Steuerungssicht Fachkonzept DV-Konzept Implementierung Funktionssicht

Zielsetzung der Funktionssicht 75 Die Funktionssicht beschreibt betriebswirtschaftliche Funktionen und deren Beziehungen zueinander. Die Funktionssicht beantwortet z. B. folgende Fragen: Wie sind die Geschäftsprozesse strukturiert? Welche Teilfunktionen unterstützen welche Aufgaben und Geschäftsprozesse? Wie sind die Anwendungen miteinander verknüpft bzw. aufgebaut? Quelle: Grief 2005, S. 53 ff.

Fachkonzept der Funktionssicht 76 Gruppierung von Funktionen objektorientiert prozessorientiert verrichtungsorientiert Prüfplan bearbeiten Kundenauftrag bearbeiten Daten erfassen Prüfplan erstellen Prüfplan ändern Prüfplan stornieren Prüfplan freigeben Kundenauftrag annehmen Kundenauftrag technisch prüfen Kundenauftrag kaufmännisch prüfen Kundenbonität prüfen Produktverfügbarkeit prüfen Kundendaten erfassen Auftragsdaten erfassen Personaldaten erfassen Bestelldaten erfassen Kundenauftrag bestätigen Orientierung an der Dimension, die die Komplexität der Informationsverarbeitung bestimmt: Komplexe Objekte: Objektorientierung Komplexe Prozesse: Prozessorientierung Komplexe Verrichtungen: Verrichtungsorientierung (früher oft IT-Funktionen)

Funktionsbaum 78 Strukturierung einer Menge von Funktionen nach ausgewählten Kriterien (Objekt, Verrichtung oder Prozess) in hierarchischer, graphischer Form. Auf der obersten Ebene definieren Funktionen Kernprozesse, auf der untersten Ebene spricht man von Elementarfunktionen, die Teil- und Unterstützungsprozesse bilden. Darstellung einer Funktion: Zweck eines Funktionsbaums: Einstiegs- und Überblicksmodell zur Komplexitätsreduktion Brainstorming-Instrument zur Prozessoptimerung Darstellung von statischen Funktionszusammenhängen (Basis für Prozessmodellierung) Quelle: ARIS, Seidlmeier 2006, S. 52 ff.; Grief 2005, S. 70

Funktionsbaum (Ausschnitt) 79 Quelle: ARIS Methode

Funktionsbaum (objektorientiert) 80 Quelle: ARIS Methode

Funktionsbaum (prozessorientiert) 81 Quelle: ARIS Methode

Funktionsbaum (verrichtungsorientiert) 82 Quelle: ARIS Methode

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.2 Fachkonzept 4.2.2.1 Fachkonzept der Funktionssicht 4.2.2.2 Fachkonzept der Datensicht 4.2.2.2.1 Grundlagen 4.2.2.2.2 Modellierung in ARIS 4.2.2.3 Fachkonzept der Organisationssicht 4.2.2.4 Fachkonzept der Prozesssicht 4.2.2.5 Wirtschaftlichkeitsanalyse 4.2.2.6 Kostenplanung 4.2.2.7 Terminplanung 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

Fachkonzept der Datensicht 84 Betriebswirtschaftliche Problemstellung Organisationssicht Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Datensicht Quelle: Seidlmeier 2006, S. 25 Fachkonzept DV-Konzept Implementierung Steuerungssicht Fachkonzept DV-Konzept Implementierung Funktionssicht

Fachkonzept der Datensicht 86 Die Datensicht hat die Definition der Datenstruktur in einem IS zum Gegenstand, beschreibt die Abbildung der zu beschreibenden Objekte des zu beschreibenden Realitätsausschnittes. Darstellung im Fachkonzept durch ein konzeptionelles Datenmodell Vereinfachte Beschreibung eines betrieblichen Realitätsausschnitts Definition der relevanten Objekttypen mit ihren sachlogischen und strukturellen Zusammenhängen Beschreibung meist durch eine grafisch orientierte, formale Modellierungssprache (bspw. das Entity Relationship Modell bzw. ERM) Quelle: Hansen/Neumann 2005, S. 185 ff.

Grundlagen des Entity Relationship Modell (ERM) 87 Entity-Relationship-Modell (ERM) Generelle, umfassende Beschreibungssprache für Datenstrukturen Leicht verständliche Graphische Darstellung in Form von ER-Diagrammen Losgelöst von konkreten Datenbank-Modellen Kann automatisch in Relationenmodell übertragen werden Grundelemente des Entity-Relationship-Modells Objekte, Ausprägungen (engl.: entity) Beziehungen (engl.: relationship) Objekttypen (engl.: entity types): Abstraktion gleichartiger Objekte mit gemeinsamen Attributen Beziehungstypen (engl.: relationship types): Abstraktion gleichartiger Beziehungen Konstruktionselemente von ER-Diagrammen: Objekttypen Beziehungstypen <Beziehungstyp> Quelle: Hansen/Neumann 2005, S. 187 f. <Objekttyp>

Weiterführende Elemente des ERM 88 Attribute (beschreibende Eigenschaften) Beschreiben die relevanten Merkmale von Objekten oder Beziehungen Identifizierende Attribute Auch Schlüsselattribute genannt Kennzeichnen eindeutig ein bestimmtes Objekt eines Objekttyps Schlüssel ist ein Objektattribut bzw. eine Kombination von Objektattributen, die geeignet sind, ein Objekt (eindeutig) zu identifizieren. Man unterscheidet Primär- und Sekundärschlüssel (können auch Kombinationen von Attributen sein) Quelle: ARIS Designer, Hansen/Neumann 2005, S. 190 ff.

Spezifizierung von ER-Beziehungstypen 89 Das Kardinalitätsverhältnis drückt aus, wie viele Objekte eines Objekttyps mit wie vielen Objekten eines weiteren Objekttyps in Beziehung treten dürfen Ausprägungen: 1:1, 1:n, n:m Mitarbeiter 1 1 verwendet PC Abteilung 1 n beschäftigt Mitarbeiter Die Partizipation bestimmt, ob alle Objekte eines Objekttyps an einer Beziehung teilnehmen müssen. Ausprägungen: partiell, vollständig 1 n Abteilung beschäftigt Mitarbeiter Jeder Mitarbeiter muss einer Abteilung zugeordnet sein. Quelle: Hansen/Neumann 2005, S. 188 f.

Erweitertes Entity Relationship Modell (eerm) 91 Klassischer Ansatz zur präzisen Datenmodellierung Attributgruppen zur genaueren Charakterisierung von Entitytypen und Beziehungen unterscheiden Schlüsselattribute Beschreibende Attribute Beispiele für Entitytypen: Beispiele für Attribute des Entitytyps Kunden: Quelle: ARIS Methode, Seidlmeier 2006, S. 63 ff.

Erweitertes Entity Relationship Modell (eerm) 92 Beispiel für einen Beziehungstyp: Zuordnung von Attributen im ERM: Quelle: ARIS Methode

eerm-attributzuordnungsdiagramm 93 Komplexitätsreduktion in eerm-darstellungen Hinterlegung der ERM-Attributzuordnungen zu jedem Entityund Beziehungstyp in einem eigenen Modell Darstellung von Attributtypgruppen: Gruppierung von ERM-Attributen eines Entitytyps, die eine enge semantische Zusammengehörigkeit aufweisen (z. B. Zusammenfassung der ERM-Attribute eines Entitytyps, die in ihrer Gesamtheit einen Sekundärschlüssel bilden). Beispiele für Attribute des Entitytyps Kunden: Quelle: ARIS Methode

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.2 Fachkonzept 4.2.2.1 Fachkonzept der Funktionssicht 4.2.2.2 Fachkonzept der Datensicht 4.2.2.3 Fachkonzept der Organisationssicht 4.2.2.3.1 Grundlagen 4.2.2.3.2 Modellierung in ARIS 4.2.2.4 Fachkonzept der Prozesssicht 4.2.2.5 Wirtschaftlichkeitsanalyse 4.2.2.6 Kostenplanung 4.2.2.7 Terminplanung 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

Fachkonzept der Organisationssicht 95 Betriebswirtschaftliche Problemstellung Organisationssicht Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Datensicht Quelle: Seidlmeier 2006, S. 25 Fachkonzept DV-Konzept Implementierung Steuerungssicht Fachkonzept DV-Konzept Implementierung Funktionssicht

Fachkonzept der Organisationssicht 97 Zielsetzung Darstellung des organisatorischen Umfelds, in dem die Geschäftsprozesse ablaufen Benutzertypologie (als Basis für daraus resultierende IS-Anforderungen) Darstellung Aufbauorganisation: Organigramme Ablauforganisation: Prozessmodell, erweitert um Organisationseinheit/Aufgabenträger (z. B. VKD, EPK) Benutzertypologie Arbeitsplatz: Büro, Werkstatt, Reise, zu Hause Arbeitsstil: starrer Ablauf, Routine, episodenhaft Informationssystemnutzung: regelmäßiger/sporadischer Nutzer, Vorkenntnisse Quelle: Hansen/Neumann 2005, S. 182 ff.

Aufbauorganisatorisches Modell 98 Geschäftsführer Deutschland Unternehmensplanung Verkaufsbüro Nord Verkaufsbüro Süd Vertriebsleiter Key Account Manager Abteilungsleiter Rechnungswesen und Organisation Kundendienst Werk Ingolstadt Fertigungsleiter Werk Meppen Qualitätskontrolle Forschungslabor Meppen Abteilungsleiter Forschung und Entwicklung Anwendungs- Entwicklung

Ablauforganisatorisches Modell 99

Organigramme 101 Modellierung der statischen Strukturen der Aufbauorganisation Strukturierung von Aufgaben, Aufgabenträgern und deren Beziehungen Organisationseinheit (z. B. Abteilung) als zentrales Organisationsobjekt wird näher erläutert durch Stellen Personen als Stelleninhaber Gruppe (für temporäre Sonderaufgaben) Personentypen (Personen mit gleichen Eigenschaften, z. B. Abteilungsleiter ) Organisationseinheitentypen (Organisationseinheiten mit gleichen Eigenschaften, z. B. Hauptabteilung ) Quelle: Seidlmeier 2006, S. 54 ff, ARIS Methode

Organigramme 102 Beziehungen zwischen Organisationseinheiten werden durch verschiedene Kantentypen dargestellt Organisationseinheit Organisationseinheit ist übergeordnet wird gebildet durch ist fachlich vorgesetzt ist disziplinarisch vorgesetzt Personen Stellen besetzt gehört zu ist Vertretung von Quelle: ARIS, Seidlmeier 2006, S. 54 ff.

Beispiel: Organigramm mit Stellen- und Personenzuordnung 103 Quelle: ARIS Methode

Beispiel: Organigramm mit Personentypen 104 Quelle: ARIS Methode

Gliederung 4 Strukturierte Systementwicklung mit ARIS 4.1 Grundkonzept von ARIS 4.2 Phasen der Systementwicklung: ARIS-Beschreibungsebenen 4.2.1 Betriebswirtschaftliche Problemstellung 4.2.2 Fachkonzept 4.2.2.1 Fachkonzept der Funktionssicht 4.2.2.2 Fachkonzept der Datensicht 4.2.2.3 Fachkonzept der Organisationssicht 4.2.2.4 Fachkonzept der Prozesssicht 4.2.2.4.1 Grundlagen 4.2.2.4.2 Modellierung in ARIS 4.2.2.5 Wirtschaftlichkeitsanalyse 4.2.2.6 Kostenplanung 4.2.2.7 Terminplanung 4.2.3 DV-Konzept 4.2.4 Implementierung 4.3 Systemdokumentation 4.4 Systembetrieb und Systemwartung 5 Objektorientierte Systementwicklung mit ARIS und UML

Fachkonzept der Prozess- bzw. Steuerungssicht 106 Betriebswirtschaftliche Problemstellung Organisationssicht Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Datensicht Quelle: Seidlmeier 2006, S. 25 Fachkonzept DV-Konzept Implementierung Steuerungssicht Fachkonzept DV-Konzept Implementierung Funktionssicht

Fachkonzept der Prozesssicht 108 Zielsetzung: Verknüpfung der Beschreibungssichten des Fachkonzepts Darstellung Prozessmodell in der erweiterten Darstellung Verweise auf die Objekte des Datenmodells und des Organisationsmodells