Zusammenfassung IM

Thomas Stuber, 06.06.2010

Inhalt0 Lernziele Modul................................................................................................................................3

1 Textarbeit..........................................................................................................................................4

1.1 Informationen aufnehmen........................................................................................................4

1.2 Informationen verarbeiten (strukturieren, ordnen, wiederholen)............................................5

1.3 Anwenden.................................................................................................................................5

1.4 Schreiben..................................................................................................................................6

2 IT Grobkonzepte und Modellierung (EPK).........................................................................................7

2.1 Grobkonzept.............................................................................................................................7

2.2 Modellierung.............................................................................................................................8

2.2.1 Definition...........................................................................................................................8

2.2.2 Zweck................................................................................................................................9

2.2.3 Modellbildung.................................................................................................................10

2.2.4 Systemmodellierung in der IT..........................................................................................10

2.3 Prozessmodellierung...............................................................................................................13

2.3.1 Allgemein........................................................................................................................13

2.3.2 Generisches Prozessmodell.............................................................................................13

2.3.3 EPK..................................................................................................................................14

2.3.4 Erweitertes EPK (EEPK)....................................................................................................17

2.3.5 Weitere Modellierungssprachen.....................................................................................18

2.4 Datenmodellierung.................................................................................................................19

3 Requirement Engineering und Modellierung..................................................................................24

3.1 Requirements Engineering und Management.........................................................................24

3.1.1 Was ist Requirements Engineering..................................................................................24

3.1.2 Warum?...........................................................................................................................24

3.1.3 Überblick.........................................................................................................................25

3.1.4 Sammeln.........................................................................................................................26

3.1.5 Ausarbeiten.....................................................................................................................27

3.1.6 Verwalten........................................................................................................................28

3.1.7 Werkzeuge......................................................................................................................29

3.2 UML.........................................................................................................................................29

3.3 Funktionsmodellierung...........................................................................................................29

3.3.1 CRC Karten......................................................................................................................29

3.3.2 Dekomposition grösserer Systeme..................................................................................30

3.4 Systemdesign..........................................................................................................................31

3.4.1 Themenfelder im Systemdesign......................................................................................31

3.4.2 Einflussfaktoren und Vorgehen.......................................................................................31

3.4.3 Systemdesign kommunizieren.........................................................................................32

0 Lernziele Modul Erstellung eines Grobkonzepts für ein IT System (Bau oder Kauf oder Miete):

o Was soll das System leisten? – Requirements Engineeringo Wie sieht das System grob aus? – Modelle:

Prozessmodell Informations- und Datenmodell Funktionenmodell Systemdesign

Fertigkeiten zur Erstellung eines Grobkonzepts:o UML-Kurs, (viele) Modellierungs-Übungeno Textarbeit:

Informationen finden (Recherche) Informationen analysieren (Verständnis) Informationen aufbereiten und darstellen (Präsentation)

Durchgängige Verwendung einer Fallstudie:o Firma „AlpineRe“ – realitätsnahes Beispielo Projekt CIS (Customer Information System) – an die Praxis angelehnt, aber (stark)

vereinfachto Die Studierenden erstellen die wesentlichen Teile des Grobkonzepts für die Fallstudie

(mit Coaching)

1 Textarbeit

1.1 Informationen aufnehmenDas THUN-Schema

T Thema (gr. Gesetzt) Titel, 2-3 SchlagworteH Hauptgedanken Kernaussagen, HauptargumenteU Unterstützende Einzelheiten Erklärungen, Beispiele, Daten, BeweiseN Nebensächliches Zierrat, Abschweifungen

Fragestellung zum Ermitteln von Bereichen

Thema:

Worum geht es überhaupt Wie lautet das Ziel? Was ist das Kernproblem?

Hauptgedanken

Was ist die Botschaft des Autors? Welches sind die Schlussfolgerungen?

Unterstützende Einzelheiten

Welche Beispiele kommen? Wo sind Beweise? Womit werden Hauptgedanken veranschaulicht?

Der Weg zum IT Konzept

1. Kunde anhören (Lastenheft)2. Aufschreiben; was haben wir verstanden (Pflichtenheft)3. Klären: Passt unser Verständnis? Missverständnisse & Sprachunterschiede klären.

Generell Wichtig

Verständnis erlangen Vollständiges eigenes Bild gewinnen (strukturieren etc.) Eigenes Bild klar darlegen

IT-Konzept schreiben

1. Phase 1: Recherche2. Phase 2: Disposition entwickeln (roter Faden, Inhalte, Quellen, Notizen)3. Phase 3: Schreiben

Drei Bestandteile zum Erkennen eines Informationsblocks:

1. Wahrnehmungskanäle (lesen, sprechen, schreiben, hören,..) richtig einsetzten, ggf. Kombinieren

2. Auf Form von Information achten (Strukturangaben, Gesetzte Ziele, Abstracts, Farbcodes, Layout, Bilder)

3. Aufbau von Informationen erkennen

Regeln für Thema-Formulierung

Hauptsachen in Hauptsätze (Präsident x ermordet!) Mehrere Hauptsachen: Beiordnung (76 Tote bei Zugunglück in England) Verb möglichst früh im Satz Kurze und einfache Sätze Keine exotischen Fachwörter, Abkürzungen

1.2 Informationen verarbeiten (strukturieren, ordnen, wiederholen)Techniken um Informationen zu vertiefen

Gedankenstützen, Merksätze Eigene Zusammenfassung, Zeichnungen Verwandtschaften suchen (z.B. Spannung = Wasserdruck) Anwendungsmöglichkeiten, Beispiele suchen

o Deskriptiv: Abschrift von etwas Vorhandenem (Zeitung, Ausweis)o Präskriptiv: Vorschrift für etwas Neues (SourceCode, Drehbuch)

Fragen an den Text stellen Mit anderen diskutieren

Fünf Ordnungsprinzipien mit Darstellungsform

Ordnungsprinzip Fragen Darstellung BeispielElemente, Merkmale Woraus besteht es? Liste, Diagramme Zusammensetzung

Shampoo, Nationalrat, Konzeptkarte Projektmanagement

Über- und Unterordnung Hauptgedanken/ Details

Baumdarstellung, Mapping-Darstellung

Concept Map für Bäume

Vergleich, Beurteilung Unterschiede? Gemeinsamkeiten?

Matrix (Raster) Entscheidungs-Matrix

Beziehungen Welche Abhängigkeiten bestehen?

Beziehungsnetz, Darstellung mit Pfeilen

Software Komponenten

Reihenfolge, Ablauf In welcher Reihenfolge macht man etwas?

Zeitstrahl, Flussdiagramm, Ablaufplan

Arbeitsprozess

1.3 AnwendenAnwenden der Textarbeit-Techniken heisst:

Bewusst lesen (Vorbereiten, Leseprozess, Nachbearbeiten) Richtig Notizen nehmen (Notizen nehmen, Nachbearbeiten)

Informationen recherchieren (3 Ebenen: Präsent [Zeitung], Fachwissen, Schwer zugängliche Literatur)

1.4 Schreiben Konzept Vorbereiten, Informationen zusammenstellen (gute Thema-Wahl) Material strukturieren, Disposition entwickeln (Struktur + Stil)

o Chronologisch (Zeitlich, Prozessschritte)o Hierarchisch (Von wichtig zu unwichtig)o Deduktiv (Behauptung, Beweis, Schlussfolgerung)o Strukturell (Nacht Art)o Argumentativ (Pro/Contra)o Didaktisch (von leicht nach schwer)

Text schreiben, Arbeit gestalten (Layout, sauber, ..)

2 IT Grobkonzepte und Modellierung (EPK)Lernziele Kurmann

Scope (was das) Projekt / Überblick geben, Ziel und Scope formulieren Resultate / Ziele, Abhängigkeit, Begründung dafür Resultate im Projekt formulieren Was ist ein Modell, Beispiele (KAP 7) Phasen der Modellierung / Sichten / Ebenen (KAP7) EEPK, kleiner Prozess modellieren (KAP8) Funktionsdiagramm (KAP10) Kontextdiagramm, anhand von Text skizzieren (KAP10) Datenmodellierung (Dokument FIBEL, Vorgehensweise, KAP11)

2.1 Grobkonzept1. Ausgangslage

Beschreibt die Ausgangslage Beschreibt, warum ein Projekt ausgeführt werden soll Schildert die Motivation

2. Ziel(e) Beschreibt, was man in einem Projekt erreichen will Was soll nach dem Projekt besser sein als vorher Ziel beschreibt Zustand / Situation

3. Scope Definiert den Gültigkeitsbereich Beschreibt, was zu einem Projekt gehört und was nicht sowie die Einschränkungen

(constraints)4. Resultate

Resultate sind Arbeitsergebnisse, welche das Projekt abzuliefern hat Kriegt der Auftraggeber „in die Hand“ Resultate sind klar und präzise beschrieben Resultate sind gebraucht für

o Aufwandschätzungo Projekt Controlling (Aufwand- & Erreichungskontrolle)

Projektreporting Zusammensetzung: Ziele (Haupt)-Resultate Teilresultate Arbeitspakete

5. Business Case / Nutzenanalyse Business Case (oder Nutzenanalyse) beschreibt Nutzen und ggf. Kosten Nutzen leitet sich von den Zielen ab Nutzen ist in drei Kategorien gegliedert:

o Erzeugung von Mehrwerto Reduktion von Kosteno Externe Zwänge z.B. Gesetzte

6. Grobplanung (Aufwand und Zeit) Groben Zeit- und Meilensteinplan Grobe Aufwand- und Kostenschätzung Voraussetzung sind Projektresultate und Lösungsskizze (Approach)

7. Approach / Lösungsskizze (optional) Beschreibt, wie man mit dem Projekt die Probleme lösen will Bsp: Prozessoptimierung, SW Einkauf / Entwicklung, Umbau Organisation, …

8. Kontext Diagramm System und derer Grenzen wird aufgezeigt (Abgrenzungen des Aufgabenbereiches) Informationsfluss in und aus dem System Beispiel:

9. Informationsmodell (Datenbank) Beschreibt die wichtigsten Informationsobjekte und deren Zusammenhänge

10. Prozesslandkarte (optional) Prozessübersicht für betroffene Geschäftsprozesse

11. Funktionale Zerlegung Beschreibt die wichtigsten Funktionen und Funktionsblöcke

12. Systemdesign Beschreibt den physikalischen Aufbau des Systems Umfasst Software und Hardware und derer Aufbau

2.2 Modellierung

2.2.1 DefinitionModell: abstrakte Darstellung eines Gegenstandes oder einer Situation

Modell: Abbild (Deskriptiv) oder Vorbild für etwas z.B. Plan (Präskriptiv). Das

Modell: Abstraktion auf das Wesentliche

Modelle: sind Abbildungen (Abstraktion) und Konstruktion der Realität

Modell: Konkretes oder gedankliches Abbild eines vorhandenen Gebildes oder Vorbild für ein zu schaffendes Gebilde in der Wahrnehmung der beteiligten Personen für einen bestimmten Verwendungszweck.

Grösstmögliche Ähnlichkeit zwischen Original und Modell ist kein Ziel!

Bewusste Abstraktion und Gestaltung von Modellen Ausnahme: Kopie

Validierung erforderlich

Alle relevanten Eigenschaften des Originals müssen adäquat und vollständig auf Eigenschaften des Modells abgebildet sein.

Merkmale eines Modells

Jedes Modell ist Abstraktion oder Vorbild eines vorhanden oder zu schaffenden Originals Jedes Modell abstrahiert Jedes Modell wird im Hinblick auf einen Verwendungszweck geschaffen Manchmal werden Modelle als Abstraktion eines Ausschnitts der Realität definiert Zu jedem Modell gehört eine Abbildung, welche die Details des Originals auf diejenigen des

Modells abbildet Das Original kann selbst wieder ein Modell sein Es kann verschiedene Modelle des selben Originals geben

2.2.2 Zweck Verstehen eines Systems Kommunizieren über Systeme Spezifikation von Anforderung an ein geplantes Gebilde Gedankliches Hilfsmittel zum Gestalten, Bewerten oder Kritisieren eines geplanten Systems Durchführen von Experimenten Aufstellen / Prüfen von Hypothesen über beobachtete oder postulierte Phänomene

2.2.3 Modellbildung Modellbildung: Iterativer Prozess; Reflektion über Original

Reflektieren: Überlegen und Verstehen, was modelliert wird Gewinnen: Informationen über das Original gewinnen Beschreiben: Gewonnene Informationen beschreiben und strukturieren Validieren: Modelle durch Wissensträger überprüfen lassen

2.2.4 Systemmodellierung in der ITModellsichten (für die Kommunikation zwischen Auftraggeber und IT)

Prozessmodell Datenmodell Organisationsmodell Interaktionsmodell (Funktionen)

Idee mit den drei Sichten: Beschreibungsebenen (Prozesse, Funktionen, Daten) in einer Unternehmung!

Beispiel ARIS

Sichten (Interessen/Stakeholder)

Sicht 1: (Geschäfts)-ProzesseInhalt: Beschreibt die Prozesse einer UnternehmungStakeholder: Manager der Führungsebene

Sicht 2: DatenInhalt: Unternehmensweites Datenmodell der wichtigsten GeschäftsdatenStakeholder: Systemnutzer, Systemkonstrukteure

Sicht 3: SystemTeilsicht: FunktionInhalt: Das „Was“ der LösungStakeholder: Systemnutzer, Fachbereiche

Teilsicht: KonstruktionInhalt: Das „Wie“ der LösungStakeholder: Systemkonstrukteure

Telisicht: Verteilung / BetriebInhalt: Das „Wo“ und „Womit“ der LösungStakeholder: IT-Betrieb

Sicht 4: Prozess-/Funktions-IntegrationInhalt: Zusammenspiel von Prozessen und FunktionenStakeholder: Manager der operativen Ebene, Systemnutzer

2.3 Prozessmodellierung

2.3.1 AllgemeinBetrieb (resp. Unternehmen) = Einheit von zusammenwirkenden Personen und Produktionsmitteln

zum Hervorbringen von Gütern und Dienstleistungen (Output) aus Eingangsmaterialen (Input) für Dritte mit dem Zweck der Erzielung eines Gewinnes

Prozess= Vorgang, Handlungsweise

Geschäftsprozess = Ein Geschäftsprozess ist ein Ablauf von Aktivitäten, die der Erzeugung eines Produktes/einer Dienstleistung dienen. Er wird durch ein oder mehrere Ereignisse gestartet und durch ein oder mehrere Ereignisse abgeschlossen. Es liegt eine Organisationsstruktur zu Grunde.

Prozess (Definition) = ein allgemeiner Ablauf mehrerer Abschnitte, mit denen es sich um Aufgaben, Arbeitsschritte etc. handeln kann. Zwischen den Prozessen bestehen gewisse Abhängigkeiten

2.3.2 Generisches ProzessmodellMangementprozesse

Qualitätsmanagementprozesse Strategieplanungsprozesse Controllingprozesse

Kernprozesse (starten und enden beim Kunden)

Innovationsprozesse Vertriebsprozesse Auftragsabwicklungsprozesse Serviceprozesse

Unterstützungsprozesse

Personalmanagementprozesse (Personal) Finanzmanagementprozesse (Finanz und Rechnungswesen) Ressourcenmanagementprozesse (Einkauf, Facility & Q-Management) IT-Management (Informatik)

Ein typischer Geschäftsprozess umfasst:

1. Startereignis (Auslöser2. Aktivität

a. Zerlegungb. Sequenzc. Auswahld. Parallelität

3. Abschlussereignis

2.3.3 EPKEPK = Sprache zur Modellierung von Geschäftsprozessen

Grundsätzliches zu EPK:

Auf ein Ereignis folgt immer eine Funktion und umgekehrt EEPK (Erweitertes EPK) Im Deutschsprachigen Raum weit verbreitet EPK beginnt immer mit einem Ereignis, danach folgt eine Funktion oder mehrere (UND-

Konnektor)

2.3.4 Erweitertes EPK (EEPK)

Beispiel Urlaubsgesuch

2.3.5 Weitere ModellierungssprachenAndere Modellierungssprachen für Prozesse (Wichtig: sollten über äussere Ereignisse gesteuerte Abläufe modellieren können)

UML-Aktivitätsdiagramme BPMN (Business Process Modeling Notation)

2.4 DatenmodellierungBegriffshierarchie

Daten: Angaben über Sachverhalte und Vorgänge aufgrund bekannter oder unterstellter Abmachungen in einer maschinell verarbeitbaren Form.

Datenbank: selbständige, auf Dauer und für den flexiblen und sicheren Gebrauch ausgelegte Datenorganisation

Datenmodell: Formale Beschreibung des Schemas, z. B. in Form eines Diagramms oder einer Datenstruktur.

Datenmodellierung: Prozess, der sicherstellen soll, dass eine Datenbasis zu jedem Zeitpunkt ein korrektes Abbild der Diskurswelt wiedergibt.

Auszug aus dem ARIS-Prozesshaus – Sicht und Beschreibungsebenen

Vorgehen bei der Informationsstukturierung

1. Attribute bestimmen2. Entitäten zusammenfassen3. Beziehungen

Notationen

3 Requirement Engineering und Modellierung GRUNDLEGEND: Lernziele Req. Engineering, UML, Funktionsmodellierung Wo sind Anforderungen im Projekt verankert (anfang / mitte Anforderungen sammeln und verwalten (Techniken und Einsatz) UML: Anwendungsfälle Funktionsmodellierung: Wie man modeliert, Werkzeuge für grössere Projekte CRC: Grundlagen der Dekomposition Systemdesign: Grundlagen, Typen, Probleme Was ist Relevenat? Wie wird das dargestellt?

3.1 Requirements Engineering und Management Sie können fundiert begründen, warum Requirements Engineering im Software-Engineering so

wichtig ist. Sie können die grundlegenden Prozesse des Requirements Engineering darlegen und seine

wichtigsten Methoden erläutern Sie können einige wichtige Requirements Engineering-Werkzeuge aufzählen und ihre

Charakteristika kurz beschreiben.

3.1.1 Was ist Requirements Engineering Req. Engineering Begründen warum, Prozesse / Methoden, Werkzeuge

o Entscheidend über Projekterfolg (erster Schritt der Systementwicklung)o Haupttätigkeiten:

Sammeln Gewinnen Analyse

Ausarbeiten Validierung Spezifikation

Verwalten Freigabe Änderung (Change Management) Verfolgung (Tracability)

o Anforderungen können im Projektverlauf ändern: Veränderte Bedürfnisse von Kunden Veränderung von Märkten / neue Märkte Änderung der Organisation (kundenseitig oder entwicklerseitig) Neue / geänderte politische oder rechtliche Randbedingungen

o Ziele: Anforderungen stabil halten, Traceability der AnforderungenMassnahmen: Konfigurationsmanagement für Anforderungen

3.1.2 Warum? 60% der Fehler passieren in der Analyse, in Design und Implementierung nur 40%.Die Kosten

der Fehlerbehebung steigen aber exponentiell mit dem Zeitpunkt der Entdeckung ->bei den Requirements investieren!!

Nur ca. 1/3 der Projekte ist erfolgreich, rest abgebrochen oder über Zeit/Budget Drei Risiken:

o fehlende Anforderungen (Kunde nicht involviert/unklarer Bedarf)o falsche Anforderungen (Keine Verfikation/Validierung),o Ändernde Anforderungen nicht berücksichtigt

Besser, Fehler am Anfang zu entdecken, da dies mit der Zeit immer teurer wird, mehr Personen beteiligt und schwieriger noch anzupassen, wenn schon begonnen

3.1.3 ÜberblickREQ sorgt für:

Anforderungen mit Auftraggeber abgestimmt Anforderungen soweit ausgearbeitet, dass System gebaut werden kann Anforderungen und Änderungen über das Projekt hinweg verfolgbar

REQ ermöglicht die Verfolgbarkeit (Traceability) von Anforderungen über Spezifikationen bis hin zu Testfällen

Ebenen der Anforderungen

REQ & Kunden

1. Kunde gibt Lastenheft 2. Auftragnehmer erstellt daraus Pflichtenheft und lässt es absegnen

Kommunikation wichtig, um Komplexität zu beherrschen

REQ Einordnung in den SW Entwicklungsprozess:

Was ist Requirements Engineering?

Ein Requirement ist eine Anforderung (Soll-Aussage über ein System / Prozess), die etwas für einen Beobachter oder ein Umsystem beschreibt

Leistung oder Eigenschaft

3.1.4 SammelnQuellen für Anforderungen

- offizielle Ansprechpartner beim Auftraggeber

- noch inoffizielle (aber betroffene!) Ansprechpartner beim Auftraggeber:– Hotline-MA– Umsystem-Betreuer– BO …

- Vorhandene Dokumentation- Gesetze und Verordnungen usw.

Fallstricke / Vorsicht

„People hate change“ Politische Interessen, Machtspielchen etc.Manche Leute sagen nicht, was sie denkenManche Leute wissen nicht, was sie wollen

Technik für Sammlung

Technik Wann einsetzen? NutzenInterview Mindestens am Anfang; oft! Liefert bei versierter

Interviewtechnik viele und nützliche Daten

Fragebögen Fragen sind bekannt, aber viele Leute

Exakte Antworten, Klärung der „Lager“

Workshops Komplexe Themen Intensiv (aber auch Aufwändig)Szenarien durchspielen Erster Entwurf steht Liefert die nötigen Details, offenbart

Lücken im Verständnis, holt Nutzer ins Boot

Prototyp Prosaspezifikation für Nutzer schwer verdaulich

Gibt ein gutes Gefühl über das spätere System

Beobachten (vor Ort) Prozesse und Umfeld fremd für Auftragnehmer

Reduziertes Risiko implied needs zu übersehen

3.1.5 Ausarbeiten Sichtweisen:

- Auftraggeber will die Spezifikation verstehen und abnehmen darf nicht zu detailliert, nicht zu technisch sein

- Entwickler müssen wissen, was sie bauen sollen muss detailliert und auch technisch sein – je nach Fähigkeiten des Teams unterschiedlich

unterschiedliche Dokumente erzeugen:- z.B. HTAgil Kundenanforderung als Spezifikation gegenüber Auftragnehmer- z.B. HTAgil Systemspezifikation zum Festhalten technischer Vorgaben:

Kap. 3.(Schnittstellen) / 4.(SW-Anforderungen) / 5.(Environment) Management-Folie, die knapp die wichtigsten Eigenschaften und den Kontext eines Systems

darstellt. Hilfsmittel

- Use Cases für die funktionalen Anforderungen- Formulare für die nichtfunktionalen Anforderungen- Formalere Mittel, wo nötig:

o Ablaufdiagrammeo Informationsmodell

o Zustandsdiagramme Kategorisierung von Anforderungen

- Funktional/Nichtfunktional- Vorschrift/Tatsache/Annahme- Hart (Sperrung nach Ablauf) / Weich (einfach nutzbar)- Repräsentation:

o Operational: Kontostand = Kontostand + Buchungsbetrago Quantitativ: Antwortzeit < xo Qualitativ: Hohe Verfügbarkeito Deklarativ: Soll unter LINUX laufen

Goldene Regeln- Formuliere Anforderungen, keine Lösungen!- Schreibe klar und verständlich!- Definiere die Subjekte, vermeide Passivsätze!- Definiere die Bedeutung von „muss“, „soll“, „kann“, wenn Du sie benutzen willst!

- Beispiele:o „Die Händlerstammdaten müssen um ein Feld für einen dritten Mehrwertsteuersatz

erweitert werden“ Lösung.o „Das System muss Anträge mit einem von drei Mehrwertsteuersätzen abrechnen

können“ Anforderung.o Nicht „System muss schnell sein“, sondern „Antwortzeit in 95% der Fälle unter 2 sec“

Validierung- Die Anforderungen werden vom Auftraggeber abgenommen und damit gültig! Am besten

richtet man ein Quality Gate ein, durch das alle Anforderungen hindurch müssen.- Qualitätskriterien für Anforderungen:

o Vollständigkeit, Korrektheit, Klassifizierbarkeit, Konsistenz, Verständlichkeit, Gültigkeit

3.1.6 Verwalten Alle Anforderungen kommen in eine gemeinsame Datenbasis. Attribute:

- Urheber- Status: erhoben, akzeptiert, zurückgestellt, gestrichen, ausgeliefert.

• bei iterativem Vorgehen immer mit Bezug zu einer bestimmten Iteration.- Komplexität- Verbindung zu den Use Cases

Evolution- Anforderungen unterliegen einer Evolution

• Fortschritte der Technologie• Änderung der unternehmensinternen Organisation• Veränderte Bedürfnisse von Kunden• Veränderung von Märkten / neue Märkte• Neue / geänderte politische oder rechtliche Randbedingungen

- Problem:• Anforderungen stabil halten und• Veränderung kontrolliert zulassen

- Es braucht

• Konfigurationsmanagement für Anforderungen• Verfolgbarkeit von Anforderungen

Änderungsprozess- Geregeltes Prozedere- Entscheidung durch Steuerkomitee (Mitglieder/Vertreter von Auftraggeber/-nehmer, PL)

Verfolgbarkeit- Rückwärts: Wo kommt welche Anforderung her?- Vorwärts: Wo ist welche Anforderung entworfen bzw. implementiert?- Wie hängen Anforderungen voneinander ab?

- Aufwand und Ertrag für Verfolgbarkeit gegeneinander abwägen- Rückverfolgungsbeziehungen pflegen, sonst sind sie nutzlos benötigt Werkzeugunterstützung

3.1.7 Werkzeuge- Rational/IBM Requisite Pro- Telelogic DOORs- Excel besser ein einfacheres Werkzeug als gar keines!!

3.2 UMLSiehe UML-Buch

3.3 Funktionsmodellierung Sie können in einer überschaubaren, abgeschlossenen Programmieraufgabe geeignete Klassen

finden und deren Zuständigkeiten und Beziehungen modellieren und das Modell anhand von Szenarien überprüfen.

Sie kennen Grundlagen und Werkzeuge zur funktionalen Gliederung grösserer Systeme (Subsystem- und Komponentenbildung) und können diese geeignet dokumentieren.

Sie können aus der Spezifikation eines grösseren Systems die wesentlichen Systemeigenschaften extrahieren und damit eine grobe funktionale Gliederung des Systems vornehmen.

3.3.1 CRC Karten CRC Karten nur für kleinere Projekte brauchbar!

- CRC = Class Responsibility Collaborationo Hilfsmittel für das objektorientierte Designo Kartenbereiche:

Name der Klasse (oben) Verantwortlichkeiten / Aufgaben (links) Beziehungen zu anderen Klassen (rechts)

Beispiel siehe Übung (Kino Reservierungssystem)

3.3.2 Dekomposition grösserer SystemeGrundidee: Reduktion der Komplexität in kleinere Teilsysteme / Teileinheiten durch Zerlegung

Die funktionale Zerlegung (Funktionsmodell) stellt ein System dar, welches aus Bausteinen zusammengesetzt ist. Dieses stellt eine klar eingrenzbare und beschriebene Funktionalität dar.

Zwei Architektur-Grundprinzipien:

Trennung der Verantwortlichkeiten (Separation of Concerns)o Trennung senkrecht in fachliche Komponenteno Trennung waagrecht in technische Schichten

Geheimnisprinzip (Information Hiding)o Zeigt nur die zur Erfüllung nötigen Informationen. Beispiele:

OOP mit dedizierten Methoden Fassade Schichten-Architektur (Zugriff n nur auf n-1)

Zusammengenommen beschreiben sie das Ideal der Delegierung einer Aufgabe.

Referenzarchitekturen (verwenden die oben beschriebenen Grundprinzipien)

Leittechnik-Pyramide SOA BI & BI / DWH

Kriterien für die Dekomposition technischer DV-Systeme

Sicherheit Verteilung der Intelligenz Art der Kommunikation (Polling vs. Push) Fehler- und Alarmierungs-Propagation

Kriterien für die Dekomposition betrieblicher DV-Systeme

Software-Kategorie ist eine bestimmte Software (Wissen um spezielles Know-How) Software-Kategorie können verfeinert werden Software-Kategorie hilft bei der Dekomposition von Systemen und hilft schon mal bei der

groben Übersicht / Analyse

Techniken und Tools

Es gibt nicht DIE richtige Lösung Wichtig ist das Denken in Varianten und Variationen Varianten Diskussion wichtig UML Diagramme bieten sich hier an

o Deployment-Diagrammo Kompenten-Diagrammo Aktivitätsdiagramm

3.4 Systemdesign Sie können den Begriff Systemdesign erklären Sie können die Aspekte des Systemdesign den Sichten und Ebenen der Modellierung von IT

Systemen zuordnen Sie kennen das Vorgehen beim Systemdesign und können die wesentlichen Schritte erklären. Sie kennen die wichtigsten Entwurfsprinzipien und Heuristiken, die beim Systementwurf

herangezogen werden und können deren Nutzen erklären. Sie können ein Systemdesign aus den typischen Sichten entwerfen und mit geeigneten UML

Diagrammen und Beschreibungen dokumentieren. Sie können stakeholdergerechte Abstraktionsebenen für die typischen Sichten auf ein

Systemdesign auswählen. Sie kennen die typischen Problemfelder beim Systementwurf und können entsprechende

Architekturaspekte nennen.

3.4.1 Themenfelder im Systemdesign Einflussfaktoren und Vorgehen beim Systementwurf Leitplanken, Muster und Kriterien für das Systemdesign Rund ein Dutzend Architekturaspekte wie z.B. Sicherheit, Persistenz, Usability etc. beeinflussen

je nach zu realisierendem System die Entwurfsentscheidungen Die Konstruktionsteilsicht kann aus verschiedenen Perspektiven betrachtet werden, man

spricht in diesem Zusammenhang von Architektursichten o Kontextsicht o Bausteinsicht o Laufzeitsicht o Verteilungssicht

3.4.2 Einflussfaktoren und Vorgehen Wesentliche Schritte, die zu einem guten Systemdesign führen

o Informationen sammeln Wie haben andere vor Ihnen ähnliche Probleme gelöst?

o Systemidee entwickeln Die Systemidee ist die Basis für künftige weitere Entwurfsentscheidungen Kernaufgabe – 1 Satz was das System macht + 5 Schlüsselbegriffe Nutzungsart und Nutzer Schnittstellen – Beziehungen zu anderen Systemen, Daten und Mengen… Datenhaltung – Persistenz: wo / Datenvolumina / Integrität / Sicherheit Kontrolle – regelbasiert / parallel / event-driven …

o Einflussfaktoren und Randbedingungen würdigen Organisatorische und politische Faktoren

Politik bestimmt was in einem Projekt erreicht werden soll Technische Faktoren

vorhandene Hard- und Software, Schnittstellen und Methoden System- bzw. Produktfaktoren

funktionale Anforderungen und Features, Abhängigkeit von anderen Systemen

o Risiken identifizieren

Typische Risiken in SW-Projekten Unterschätzer Aufwand und Komplexität Überschätzte Ressourcen-Verfügbarkeit Ungeeignete Ressourcen Unzuverlässige Basissysteme und Drittsysteme Unvollständige, widersprüchliche und instabile Anforderungen

o Qualität explizit beschreiben Starke empfiehlt Szenarien dafür einzusetzen und so praxisgerecht zu

konkretisieren Anwendungsszenarien

z.B. Benutzeranfrage muss in 0,5 Sekunden beantwortet sein Änderungsszenarien

beschreibt den Aufwand für absehbare Änderungen am System Stress- und Grenzszenarien

beschreibt wie das System auf Extremsituationen reagiert o Lösungsstrategie entwickeln

Mangel an Zeit, Budget und Erfahrung Enge Kooperation mit dem Projektmanagement, offenlegen der

Risiken, Etappierung der Auslieferung, Anpassung der Anforderungen, und: adding people to a late project makes it even later.

Performanceprobleme Leistungsfähigere Hardware ist billiger als optimieren oder ungünstige Verteilung und suboptimale Kommunikation sind

Ressourcenfresser Probleme mit Anpassbarkeit und Flexibilität

Konfigurationsdaten in Datei statt im Code Subsysteme und Komponenten über Adapter, Fassaden, Proxies

entkoppeln Explizite Interfaces vorsehen

3.4.3 Systemdesign kommunizierenSichten erlauben die Konzentration auf bestimmte Aspekte, indem sie von Details abstrahieren, die für die gewählte Perspektive nicht von Bedeutung sind.

Kontextsicht:

Zeigt das System als Blackbox in seinem Kontext aus einer Vogelperspektive o Schnittstellen zu Nachbarsystemen o Interaktionen mit wichtigen Stakeholdern o wesentliche Teile der umgebenden Infrastruktur

Bausteinsicht:

Zeigt die statischen Strukturen der o Architekturbausteine des Systems o Subsysteme o Komponenten und deren Schnittstellen

top-down ausgehend von der Kontextsicht Die letzte mögliche Verfeinerungsstufe der Zerlegung bildet der Quellcode Unterstützt Projektleiter und Auftraggeber bei der Projektüberwachung Dient der Zuteilung von Arbeitspaketen Fungiert als Referenz für Software-Entwickler

Laufzeitsicht:

Beschreibt, wie die Bausteine des Systems zur Laufzeit zusammenwirken Beschreibt die dynamische Struktur

Verteilungssicht (Deployment):

Beschreibt Hardwarekomponenten auf denen das System abläuft o Rechner o Prozessoren o Netztopologien und –protokolle o sonstige Bestandteile der physischen Systemumgebung

Die Infrastruktursicht zeigt das System aus Betreibersicht

Architekturaspekte

Unter Architekturaspekten verstehen wir Dinge, die Software-Architekten beim Systementwurf meistens beschäftigen. Für viele dieser Aspekte gibt es daher typische Lösungsansätze auf die man für die konkrete Lösung aufbauen kann.

Persistenz Typische Probleme beim Entwurf sind

Datenmodellierung (Performance vs. Normalisierung) Wahl eines DBMS Trigger (Seiteneffekte) Strukturbrüche (OR-Mapping, impedance mismatch)

im einfachsten Fall stellt man der Fachklasse dedizierte Datenklassen zur Seite (JDBC / ADO / …)

Wenn vernetzte Objektstrukturen persistiert werden müssen bzw. die Abbildung auf die Datenbank(en) komplex ist, lohnt sich der Entwurf einer Persistenzschicht

o Persistenzschichten vermitteln zwischen Anwendung und unterschiedlichen Speichersystemen

Geschäftsregeln Geschäftsregeln legen Abläufe in Abhängigkeit von bestimmten Bedingungen fest Anstatt mit if-then-else Konstrukt zu arbeiten kann man die Geschäftsregeln in einer

Regelsprache beschreiben. Eine RuleEngine führt dann die Fachlogik auf den Geschäftsobjekten aus.

Legacy

Insbesondere kommerzielle SW-Systeme werden in der Regel in einem Umfeld bestehender Anwendungen, d.h. in einem Legacy-Kontext entwickelt.

Einen minimal invasiven Ansatz stellt die Integration über einen Gateway dar. So lassen sich die Details der Kommunikation mit dem Legacy System kapseln und bei Bedarf auch weiteren Clients Zugang zum Altsystem schaffen.

Alternativ kann ein Wrapper, der typischerweise auf der Legacy-Plattform realisiert wird, eine Schnittstelle zu deren Dienste anbieten.

Verteilung o Aus verschiedensten Gründen kann es notwendig sein, dass ein Softwaresystem auf

unterschiedlichen Rechnern abläuft o Allerdings sind entfernte Methodenaufrufe ressourcenintensiver, benötigen verteile

Objekte, komplexere Infrastruktur und ist die Fehlerbehandlung über Systemgrenzen hinweg ist aufwändiger

o Daher Verteilung nur wenn nötig (Komplexität) Verarbeitung möglichst nahe bei den betroffenen Daten Stabile Schnittstellen anstreben Lieber höhere Serverbelastung als höherer Datentransfer Zusatzaufwand für Test und Deployment einplanen

Kommunikation o beim Entwurf verteilter Systeme kommt der Kommunikation wegen der vielfältigen

Möglichkeiten mit entsprechenden Vor- und Nachteilen grosse Bedeutung zu. o Fragen

Synchron oder asynchron Stateful oder stateless Direkt oder via Middleware Stil (RPC, publish/subscribe, broadcast, poll, …) Nur TCP/IP oder zusätzlich IIOP, SOAP, HTTP, … Datenkodierung, (little/big endian, Zeichensatz, …) Semantik (aktuelle Werte oder nur Deltas)

GUI-Ablaufsteuerung o Frage/Antwort-System

Kontrolle durch Zustandsautomat aufgrund fachlicher Ereignisse o Objektorientierte Oberfläche

Unterscheidung von Werkzeug, Verwendung und Material Umgebungsobjekt, z.B. Schreibtisch ist Materialverwalter und

Werkzeugkoordinator o MVC – trennen von Verarbeitungslogik und Steuerungselemten

GUI-Ergonomie o Arbeitsmetaphern (Struktur und Arbeitsabläufe)

Fabrik sequenzieller Ablauf (Web-Shop) Werzeug/Material kreative Aufgaben (Photoshop) Formular Datenerfassung und -Ansicht

o Interaktionsstile (Art der Darstellung) Objektorientiert, wenn die Daten grafisch gut repräsentierbar sind Frage/Antwort, wenn der Ablauf vom System vorgegeben ist Formularbasiert, wenn Daten erfasst bzw. abgefragt werden Menü + Fenster, als Applikationsrahmen für die einzelnen Anwendungsfälle

o Effektivität, Effizienz und Akzeptanz Internationalisierung

o Neben Sprache ev. auch rechtliche und kulturelle Aspekte beachten o Internationalisierung beeinflusst deshalb die gesamten Entwicklungsprozesse

Workflow-Management o Systemübergreifende Ablaufsteuerung und Koordination von SW-Systemen o 3 Lösungsansätze

Steuerung durch externes WMS bzw. BPMS manuelle Steuerung (mittels E-Mail oder Groupware) Embedded Workflow mittels Zustandsautomat

o WMS Sicherheit

o Beschränkter Entscheidungsfreiraum z.B. durch Verschlüsselungsverbot o Organisatorische Fragen (Firewalls / PKI / Hardware / …) o Ziele

Vertraulichkeit / Integrität / Autentizität / Autorisierung Verfügbarkeit (denial of service Angriffe)

o OSI-Schichten Netzwerk (3) z.B. VNP, für Anwendungen transparent Transport (4) z.B. SSL, Anwendung kennt Zertifikate Anwendung (7) z.B. S/MIME E-Mail Anwendungen

Protokollierung o Loglevels und Kriterien definieren o Zu Projektbeginn ein geeignetes Framework festlegen

Fehlerbehandlung o Fokus auf Schnittstellen, keine leeren Catch-Klauseln o Logging definieren