IM | Karteikarten online lernen

Alle Oberthemen / Informatik / IT-Konzepte und Modelle

IM (162 Karten)

Sag Danke

1
Kartenlink

was beinhaltet die Systemidee

Kernaufgabe* Nutzungsart und Nutzer* Schnittstellen* Datenhaltung* Kontrolle

2
Kartenlink

Welches sind die wichtigsten Informationen, die notwendig sind, um ein IT-Projekt durch-zuführen? Wie sieht eine Inhaltsstruktur für das Grobkonzept eines IT-Projekts aus?

1. Ausgangslage
2. Ziel(e)
3. Scope
4. Anforderungen
5. Resultate
6. Business Case / Nutzenanalyse
7. Grobplanung (Aufwand und Zeit)
8. Approach / Lösungsskizze (optional)
9. Kontext Diagramm
10. Informationsmodell
11. Prozesslandkarte / Prozesse (optional)
12. Funktionale Zerlegung
13. Systemdesign
14. Projektstruktur
[Auf Zalando suchen alle Russen blaue Gurte als Kunst ihrer Partei]

3
Kartenlink

Was bedeutet CIS?

Customer Information System

Tags:
Quelle: IM1

4
Kartenlink

In welcher Phase wird das Grobkonzept erstellt?

initialisierungsphase

Tags:
Quelle: IM2

5
Kartenlink

Bestandteile Grobkonzept
Ausgangslage

Die Ausgangslage beschreibt die Problemstellung respektive Probleme, die zum Projekt führen* Sie beschreibt WARUM man das Projekt machen will.--> Motivation

6
Kartenlink

Bestandteile Grobkonzept
Ziel

Beschreibt, WAS man mit dem Projekt erreichen will* Was soll NACH dem Projekt „besser“ sein als vorher* Das Ziel beschreibt einen Zustand / Situation

7
Kartenlink

Bestandteilie Grobkonzept
Scope

Engl.: Abgrenzung, Anwendungs-, Gültigkeitsbereich
Der Scope beschreibt, was in ein Projekt „hineingehört“, was nicht zu dazugehört und die Einschränkungen (constraints).

Tags:
Quelle: IM2

8
Kartenlink

Bestandteile Grobkonzept
Anforderungen

Eine Anforderung ist eine Soll-Aussage über ein System oder einen Prozess, die etwas für einen Beobachter oder ein Umsystem Wahrnehmbares beschreibt, nämlich

ODER

In einem Grobkonzept werden zur Detaillierung der Ziele die wichtigsten Anforderungen grob beschrieben.

Tags:
Quelle: IM2

9
Kartenlink

Bestandteile Grobkonzept
Resultate

Mit den Resultaten meint man die Arbeitsergebnisse, welche das Projekt abzuliefern hat. Man beschreibt, was der Auftraggeber oder die Benutzer „in die Hand“ kriegen
Resultate sind präzis und klar zu umschreiben.

Tags:
Quelle: IM2

10
Kartenlink

Bestandteile Grobkonzept
Business Case

Der Business Case oder Nutzenanalyse beschreibt den Nutzen eines Projekts:* Qualitativ: Beschreibung des Nutzens in Prosa* Quantitativ: Berechnung des Nutzens in Fr. (optional)* Der Nutzen lässt sich von den Zielen ableiten und ist in drei Kategorien unterteilbar:<div style="padding-left:5px;">-Erzeugung von Mehrwert (Einnahmen)</div><div style="padding-left:5px;">- Reduktion von Kosten</div><div style="padding-left:5px;">- Externe Zwänge: z.B. Gesetze</div>

11
Kartenlink

Bestandteile Grobkonzept
Grobplanung

Mit der Grobplanung skizziert man

A) einen groben Zeit- und Meilensteinplan
B) einen grobe Aufwand- und Kostenschätzung Voraussetzung für diese Grobplanung sind die Projektresultate und eine grobe Lösungsskizze (Approach)

Tags:
Quelle: IM2

12
Kartenlink

Typische Risiken in Softwareprojekten

Unterschätzer Aufwand und Komplexität* Überschätzte Ressourcen* Verfügbarkeit (Personen und Sachen)* Ungeeignete Ressourcen (Personen und Sachen)* Unzuverlässige Basissysteme und Drittsysteme (Schnittstellen)* Unvollständige, widersprüchliche und instabile Anforderungen

13
Kartenlink

Bestandteile Grobkonzept
Lösungsskizze / Approach (optional)

Die Lösungsskizze oder englisch Approach beschreibt, wie man gedenkt mit dem Projekt die Probleme zu lösen.
Dies kann eine Optimierung eines Prozesses sein, die Entwicklung oder der Einkauf einer oder mehrere Applikationen und vielleicht der Umbau einer Organisation.

Tags:
Quelle: IM2

14
Kartenlink

Bestandteile Grobkonzept
Kontext Diagramm

veranschaulicht in Konzeptionsphase das Umfeld des zu realisierenden IT-Systems. Insbesondere wird klar abgegrenzt, was zum Aufgabenbereich des IT-Systems gehört und was nicht.* Weiterhin veranschaulicht es grob, welche Informationen in das System hinein fliessen und welche Informationen das System liefern kann. Das Kontextdiagram wird zu einer sehr frühen Phase der Systemkonzeption eingesetzt.

15
Kartenlink

Bestandteile Grobkonzept
Informations/Daten-Modell

Informationsmodell in Grobkonzept beschreibt wichtigsten Informationsobjekte und deren Zusammenhänge, welche für das Projekt, SW-System und Projektverständnis zentrale Rolle spielen.

16
Kartenlink

Bestandteile Grobkonzept
Prozessskizze / -landkarte

Prozessskizze oder Prozesslandkarte gibt Überblick über die zu automatisierenden Geschäftsprozesse. Es wird beschrieben, für welchen Geschäftsbereich eine Applikation erstellt werden soll.

17
Kartenlink

Bestandteile Grobkonzept
Was versteht man unter "Funktionale Zerlegung"

Mit der Funktionalen Zerlegung (Funktionen-Diagramm) beschreibt man die wichtigsten Funktionen oder Funktionsblöcke eines IT-Systems.
--> Klarheit über die Funktionalität des Systems

18
Kartenlink

Bestandteile Grobkonzept
Systemdesign

Mit dem Systemdesign im Grobkonzept wird der physische Aufbau eines IT-Systems beschreiben.
Mit physischem Aufbau meint man einzusetzende Software- und Hardwarekomponenten und deren Aufbau.

Tags:
Quelle: IM2

19
Kartenlink

Was ist Requirements Engineering?

Ein Requirement ist eine Anforderung, d.h. eine Soll-Aussage über ein System oder einen Prozess, die etwas für einen Beobachter oder ein Umsystem Wahrnehmbares beschreibt, nämlich

ODER

Das Requirements Engineering ist diejenige Disziplin, welche die Anforderungen an das Zielsystem aktiv durch ihren gesamten Lebenszyklus begleitet.

Tags:
Quelle: IM2

20
Kartenlink

Was sind die 3 Haupttätigkeiten des Requirements Engineering?

- Sammeln
- Ausarbeiten (Dokumentieren & Prüfen)
- Verwalten

Tags:
Quelle: Kp3

21
Kartenlink

Requirements Engineering
Welche 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

22
Kartenlink

Massnahmen und Ziele des Requirements Engineering

Ziele:

Anforderungen stabil halten und Veränderungen kontrolliert zulassen* Beherrschen der Evolution von Anforderungen und Traceability (Verfolgbarkeit)

Massnahmen:
Konfigurationsmanagement für Anforderungen

23
Kartenlink

Prozentual wie viele Fehler passieren in Analyse und Designphase?

Analysephase: 60%
Design & Implementierung: 40%

Tags:
Quelle: Kp3

24
Kartenlink

Die drei Risiken im Requirements Engineering (und für Ihr konkretes Projekt)

1. Fehlende Anforderungen
- Kunde nicht involviert; unkarer Bedarf und Nutzen
- Kritische Anforderungen übersehen
- Nur funktionale Anforderungen

2. Falsche Anforderungen
- Vermischen von was (Bedarf) und wie (Lösung)
- Keine Verifikation / Validierung

3. Sich ändernde Anforderungen
- Unbekannte / unzureichende Baselinem auf die aufgebaut wird
- unzureichende Änderungsmanagement

25
Kartenlink

Warum Requirements Engineering?

Requirements Engineering sorgt dafür, dass:

die Anforderungen mit dem Auftraggeber abgestimmt werden* die Anforderungen so weit ausgearbeitet werden, dass das System gebaut werden kann* die Anforderungen und mögliche Änderungen daran über das Projekt hinweg verfolgt werden

Requirements Engineering ermöglicht die Verfolgbarkeit von Anforderungen über die Spezifikation und die Module bis hin zu den Testfällen des Systems („Traceability“)!

26
Kartenlink

Ebenen der Anforderungen

Tags:
Quelle: Kp3

27
Kartenlink

Requirements Engineering: Hauptaktivitäten

• Sammeln
- Gewinnung
- Analyse
• Ausarbeiten
- Spezifikation
- Validierung
• Verwalten
- Freigabe
- Änderung (Change Management!)
- Verfolgung

Tags:
Quelle: Kp3

28
Kartenlink

Anforderungspyramide

[Vampiere fressen Ratten]

29
Kartenlink

3 resultierende Fragen zur Systemgrenze

Was gehört zum System das ich entwickeln muss, das ich beeinflussen kann
Was gehört zur Systemumgebung Umsysteme, die vorgegeben sind, schon bestehen oder in einem andern Projekt von Dritten entwickelt werden
Welche Schnittstellen hat mein System die mein System anbieten muss oder die es von den Umsystemen benötigt

30
Kartenlink

Requirement Engineering
Sammeln; Geschäftsereignisse und -prozesse

Betroffene Geschäftsereignisse und Geschäftsprozesse bestimmen (erst IST, dann SOLL) Diejenigen Teile der Geschäftsprozesse herausfinden, die von dem Zielsystem unterstützt werden sollen -> fliessen in die Use Cases (UCs) ein
Beispiel: Organisation einer Kundenveranstaltung im CIS. Dazu werden die Profile der Kunden benötigt, um die richtigen Leute einzuladen. Das ändert sich mit CIS.

31
Kartenlink

woraus bestehen sprints

dem Sprint Planning* dem Daily Meeting* der eigentlichen Entwicklungsarbeit* der Sprint Abnahme* der Sprint Retrospektive

32
Kartenlink

Requirement Engineering
Sammeln; Aus welchen Quellen schöpfen?

Stakeholder
Vorhandene Dokumentation
Gesetze und Verordnungen usw.

Tags:
Quelle: IM3b

33
Kartenlink

Requirement Engineering
Sammeln; Fallstrike

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

Tags:
Quelle: IM3b

34
Kartenlink

Requirement Engineering
Sammeln; Techniken

Interview viele nützliche Daten
Fragebögen Exakte Antworten, Klärung der "Lager"
Workshops Intensiv, aufwändig
Szenarien durchspielen liefert Details, offenbart Lücken im Verständnis, holt Nutzer ins Boot
Prototyp gibt gutes Gefühl über spätere System
Beobachten Reduziert Risiko "implied needs" zu übersehen

Tags:
Quelle: IM3b

35
Kartenlink

Requirement Engineering
Ausarbeiten; Sichtweisen

Auftraggeber will die Spezifikation verstehen und abnehmen
Entwickler müssen wissen, was sie bauen sollen

Tags:
Quelle: IM3b

36
Kartenlink

Requirement Engineering
Ausarbeiten; Kategorien von Anforderungen

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

Tags:
Quelle: IM3b

37
Kartenlink

Requirement Engineering
Ausarbeiten; 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!
Schreibe, wo möglich, quantifizierbar, testbar: Nicht „System muss schnell sein“, sondern „Antwortzeit in 95% der Fälle unter 2 sec“
Verwende die Sprache des Anwenders!
Verwende ein Glossar!

Tags:
Quelle: IM3b

38
Kartenlink

Requirement Engineering
Ausarbeiten; 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:<div style="padding-left:5px;">- Vollständigkeit</div><div style="padding-left:5px;">- Korrektheit</div><div style="padding-left:5px;">- Klassifizierbarkeit (rechtliche Relevanz; muss/soll/kann)</div><div style="padding-left:5px;">- Konsistenz</div><div style="padding-left:5px;">- Prüfbarkeit (Testfälle!!)</div><div style="padding-left:5px;">- Eindeutigkeit (können nicht anders verstanden werden)</div><div style="padding-left:5px;">- Klare Verständlichkeit</div><div style="padding-left:5px;">- Gültigkeit und Aktualität</div><div style="padding-left:5px;">- Realisierbarkeit, Kalkulierbarkeit der Kosten</div><div style="padding-left:5px;">- Notwendigkeit zur Erreichung des Ziels</div><div style="padding-left:5px;">- Gewichtbarkeit (Prioritäten)</div>

39
Kartenlink

Requirement Engineering
Verwalten; Anforderungs-Datenbasis

Alle Anforderungen kommen in eine
gemeinsame Datenbasis. Attribute:

Urheber
Status: erhoben, akzeptiert, zurückgestellt, gestrichen, ausgeliefert.
Komplexität
Verbindung zu den UCs

Tags:
Quelle: IM3b

40
Kartenlink

Bestandteile Grobkonzept
Scope

Engl.: Abgrenzung, Anwendungs-, Gültigkeitsbereich* Der Scope beschreibt, was dazu gehört, was nicht dazugehört und die Einschränkungen (constraints).

41
Kartenlink

Bestandteile Grobkonzept
Resultate

Mit den Resultaten meint man die Arbeitsergebnisse, welche das Projekt abzuliefern hat. Man beschreibt, was der Auftraggeber oder die Benutzer „in die Hand“ kriegen
Resultate sind nicht Aktivitäten!
Projektresultate präzise und vollständig definieren und beschreiben!

Tags:
Quelle: IM4

42
Kartenlink

Frühe Vorgehensmodelle in der SW-Entwicklung

Wasserfallmethode

Sequentielles Vorgehen
Phase = Aktivitäten
Kontrolle der Aktivitätenereignisse und Tests

V-Modelle

Sequentielles Vorgehen
Bezug zwischen analytischen und synthetischen Schritten
QS-Sicht: Verifikation und Validierung

Tags:
Quelle: IM5a

43
Kartenlink

was sind neue Vorgehensmodelle der SW-Entwicklung

Iterativ

Die Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen* bereits in frühen Iterationen werden lauffähige Programmteile geschaffen (Prototypen)

Inkrementell

Die Releases erhalten mit jeder Iteration einen grösseren Funktionsumfang

44
Kartenlink

Top-Down-Prinzip
Bottom-Up-Prinzip

Top-Down-Prinzip

Vom Groben zum Detail
Konzept auf oberer Ebene gilt als Orientierungshilfe
Es liegen nicht sofort konkrete Lösungen vor

Bottom-Up-Prinzip

Verbesserung vorhandener Lösungen
Es liegen schnell Lösungen vor

Tags:
Quelle: IM5a

45
Kartenlink

Scrum

agil, iteraktiv & inkrementell* 3Säulen:<div style="padding-left:5px;">- Transparenz</div><div style="padding-left:5px;">- Überprüfung</div><div style="padding-left:5px;">- Anpassung</div>* Framework welches Entwicklung komplexer Produkte unterstütz* Scrum Teams liefern Produkte in regelmässigen Abständen (iteraktiv) und stufenweise erweiternd (inkrementell) aus. Dadurch werden Gelgenheiten für Feedback maximiert* inkrementelle Lieferung "fertiger" Produkte stellt sicher dass immer nutzbare Version zur Verfügung steht

46
Kartenlink

was sind Sprints

Sprint ist Herz von Scrum* Sprints haben gleichmässig feste Dauer während ein fertig getestetes auslieferbares Produktinkrement entwickelt wird* Sprints ermöglichen Vorhersagbarkeit durch regelmässige Überprüfung des Arbeitsfortschrittes sowie Anpassung der Planung und gegebenenfalls der Zielsetzung

47
Kartenlink

4 Rollen im SoDa Projekt

Projektleiter/-in
Product Owner
Scrum Master
Scrum Team

Tags:
Quelle: IM5a

48
Kartenlink

Aufgaben des ProductOwner

ProductBacklog-Verwaltung (laufend)

Erfassen und klar formulieren der Einträge im ProductBacklo
ordnen der Einträge in eine zielführende Fertigstellungsreihenfolge
Transparenz sicherstellen des ProductBacklog für alle Beteiligten
fortlaufenden Pflege (Grooming) des ProductBacklogs

Sprintplanung (zu Beginn jedes Sprints)

mit dem Entwicklungs-Team den Inhalt des SprintBacklogs verhandeln und Zielkonflikte auflösen
Bei Bedarf den Umfang des SprintBacklogs nachverhandeln

Sprintabschluss

ermitteln, was „done“ ist (Testplan) und das Inkrement freigeben
verbleibende Arbeit ermitteln und Fertigstellungsdatum hochrechnen

49
Kartenlink

SoDa Artefakte
SoDa sieht für Software-Entwicklungsprojekte folgende Dokumente vor:

Projektführung:

Projektplan

(Erstellung in der Initialisierungsphase, Aktualisierung bei jedem Meilenstein, Sprintpläne für jeden Sprint im Anhang, Meilensteinbericht pro MS im Anhang)

Projektdurchführung:

Grobkonzept (Erstellung in der Initialisierungsphase)
ProductBacklog (Erstellung in der Initialisierungsphase, laufende Pflege)
SprintBacklog (Erstellung zu Beginn jedes Sprints => Teil des Sprintplans)
Sprintplan (Erstellung zu Beginn jedes Sprints => Ablage im Anhang Projektplan)
SysSpec (Erstellung in der Initialisierungsphase, Ergänzung pro Inkrement)
Testplan (Erstellung in der Initialisierungsphase, Ergänzung pro Inkrement)
Testprotokoll (Erstellung pro Inkrement)

Tags:
Quelle: IM5a

50
Kartenlink

Im Grobkonzept werden in der Initialisierungsphase zwei Fragen geklärt:

Was soll das System leisten?
Wie sieht das System grob aus? (Prozess-, Daten-, Funktionen-Modell, Systemdesign)

Tags:
Quelle: IM5a

51
Kartenlink

PMP

Projektmanagementplan mit folgenden Kapiteln:

Einleitung
Projektorganisation
Projektführung
Projektunterstützung
Anhänge

Tags:
Quelle: IM5a

52
Kartenlink

was enthält ein Sprintplan

Sprintziel<div style="padding-left:5px;">- Aktualisierte Risikoliste</div><div style="padding-left:5px;">- Was soll in diesem Sprint prinzipiell erreicht werden (allenfalls Bezug zu übergeordneten Projekt-Lieferobjekten, Meilensteinen etc.)</div>* (Initial) Taskboard<div style="padding-left:5px;">- Für diesen Sprint ausgewähtle UserStories inkl. Definition of «done»</div><div style="padding-left:5px;">- Aufwand und Zuordnung (nötigenfalls UserStories in Tasks herunter brechen)</div><div style="padding-left:5px;">- Abfolge im Sprint</div>

Sprintpläne werden im PMP als Anhang abgelegt

53
Kartenlink

Systemspezifikation SysSpec

beschreibt Architektur der Software
Basis wird möglichst schon in der Initialisierungsphase gelegt
Inhalte werden aber bei jedem Sprint aktualisiert und ergänzt
Dokument beschreibt jederzeit den aktuellen Zustand des in Entwicklung befindlichen Systems

1. Einführung

Systemübersicht: Übersicht und Begründung des gewählten Lösungsansatzes

2. Architektur und Design-Entscheide

Modell(e) und Sichten
Daten (Mengengerüst / Strukturen)
Entwurfsentscheide

3. Schnittstellen

Externe Schnittstellen
wichtige interne Schnittstellen
Benutzerschnittstelle(n)

4. Environment-Anforderungen (HW, BS, VM)

Tags:
Quelle: IM5a

54
Kartenlink

Testplan

Der Testplan ist das Werkzeug des ProductOwners bei der Sprint-Abnahme: Alle nicht automatisierten Tests (in der Regel Integrations- und Systemtests) sind darin beschrieben.

Tags:
Quelle: IM5a

55
Kartenlink

Instrumente der Projekt-Übersicht

der Projektstrukturplan (PSP)
der Rahmenplan

Tags:
Quelle: IM5b

56
Kartenlink

Möglichkeiten des Aufbaus eines Projektstrukturplanes

objektorientierte Strukturierung (nach Komponenten)
vorgehensorientierte Strukturierung (nach Projektphasen)

Tags:
Quelle: IM5b

57
Kartenlink

2-stufiges Planungsvorgehen

1. Rahmenplan:
Projektleiter erarbeitet Rahmenplan, der auf Ebene des Projekt-Modells grobe Vorstellung des übergeordneten Projektablaufs mit wichtigsten Meilensteinen und Terminen gibt

2. Rollende Detail-Planung:
ProductOwner priorisiert laufend Anforderungen im Backlog nach Geschäftsnutzen. Gemeinsam mit Entwicklungsteam wird
Aufwand für die höchst priorisierten Anforderungen abgeschätzt und folgenden zwei Iterationen detailliert geplant

58
Kartenlink

Rahmenplan

Häufig sind andere Projekte vom Stand der Entwicklung abhängig oder die Softwareentwicklung ist nur ein Teilprojekt in einem grösseren Unterfangen.
Der Rahmenplan muss daher möglichst stabil sein.
der Rahmenplan zeigt:

Projektdauer<div style="padding-left:5px;">- geplantes Projektende</div><div style="padding-left:5px;">- geplanter Projektstart</div>* Meilensteine<div style="padding-left:5px;">- Name</div><div style="padding-left:5px;">- Termin</div><div style="padding-left:5px;">- Deliverables</div>

59
Kartenlink

Vorgehen Rahmenplanung

1. Endtermin oft von aussen Vorgegeben:

Inkrafttreten neuer gesetzl. Bestimmungen,
Produktionsumstellung,
Messetermin / Produkteinführung
Schulprojekte: Semesterende

2. Starttermin meist später als erhofft:

Ressourcenverfügbarkeit
Entscheide der Geschäftsleitung

3. Meilensteine (in SoDa gemäss Phasenmodell von Jenny)

Termine festlegen
Deliverables festlegen

4. Iterationen
(Sprintdauer <=> Anzahl Sprints in Konzeption & Realisierung)

Tags:
Quelle: IM5b

60
Kartenlink

Verteilung der Meilensteine

Die Projektphasen sind nicht alle gleich lang!

Typisch sind die Meilensteine bei kleinen und mittleren Projekten wie die Widerlager und Pfeiler einer Doppelbogenbrücke verteilt.

(ist der Fluss breiter, so braucht es möglicherweise zusätzliche Pfeiler)

Tags:
Quelle: IM5b

61
Kartenlink

80/20 – Regel

Das Pareto-Prinzip

Eine Minderheit von Ursachen führt zu einem Grossteil der Ergebnisse

62
Kartenlink

Konsequenzen der 80/20- Regel für die Projektplanung

100% vollständigen Requirements sind erst nach unendlich langer Zeit zu haben* Ziel ist: «gut genug» eine kurze Initialisierungsphase muss genug Klarheit schaffen, um mit Umsetzung rasch beginnen zu können* Wenn der «mittlere Pfeiler» nach 50% der Projektdauer angesetzt wird, müssen nach Abschluss der Konzeptionsphase weit über 90% der Projektresultate vorliegen. Ein funktionierender Prototyp «System-Durchstich» ist eine Mindestvorgabe für diesen Meilenstein!

63
Kartenlink

Rollende Planung

lediglich Grobplanung existiert
Detailplanung jeweils für bestimmten Zeithorizont
wird dort eingesetzt, wo grosse Planungsunsicherheiten bestehen
Planungsaufwand kann erheblich verringert werden
Projektstart kann beschleunigt werden

Tags:
Quelle: IM5b

64
Kartenlink

Sprintplanning

Zu Beginn jedes Sprints erarbeitet der ProductOwner das neue Sprint-Ziel gemeinsam mit dem Team auf Basis

der Rahmenplanung* der aktualisierten Risikobewertung und* des priorisierten Product Backlog

Es wird geprüft, wie viele der höchst priorisierten ProductBacklog-Items (Stories) in das SprintBacklog übernommen werden können, so dass

ein sinnvolles Sprintziel* mit den verfügbaren Ressourcen* in der vorgesehenen Timebox

erreicht werden kann

65
Kartenlink

Was sind die wichtigsten Risiken in der SoDa-Planung?

Fehlendes Commitment des oberen Managements
Fehlendes Commitment beim Auftraggeber / Nutzer
Missverständnisse bei den Anforderungen
Unzureichender Einbezug von Auftraggeber bzw. Nutzer
Fehlendes Management der Endbenutzererwartungen
Fehlendes Change- & Scope-Management

Tags:
Quelle: IM5b

66
Kartenlink

Risiken identifizieren

Systematik zur Risikoidentifikation
Bezug zu den Erfolgsfaktoren
Einsatz von Fachexperten

Tags:
Quelle: IM5b

67
Kartenlink

Risiken analysieren

Einheitliches Mass zur Bewertung eines Risikos
Objektive Daten verwenden
Sicher erwartete Entwicklungen stellen kein Risiko dar
Einmalige Schadenwirkung und anhaltende Wirkung unterscheiden
Schadenhöhe x Eintrittswahrscheinlichkeit nicht immer geeignet:

z.B. Absatzmengenrisiken mit unterschiedlicher Wahrscheinlichkeit können einen Umfang von 1, 2, 3% usw. haben und sind besser durch eine Normalverteilung zu beschreiben.

Risiken nicht überschneidend identifizieren
“Kleinvieh macht auch Mist“
Korrelationen und Wechselwirkungen im Gesamtkontext bewerten.

Tags:
Quelle: IM5b

68
Kartenlink

wie sieht der Prozess der Risikoanalyse aus?

1. Beschreibung der Risiken
2. Eintrittswahrscheinlichkeit und Auswirkung abschätzen
3. Risiken bewerten
4. Für alle grossen Risiken:
- Reduktion der Eintrittswahrscheinlichkeit
- Begrenzung der Auswirkung

69
Kartenlink

Risikomatrix

Tags:
Quelle: IM5b

70
Kartenlink

Der wissenschaftliche Modellbegriff

Abbild eines vorhandenen Gebildes* Vorbild für ein zu schaffendes Gebilde* Immer mit Abstraktion verbunden* Das Gebilde, welches Abbild oder Vorbild ist, wird Original genannt* Modelle sind Abbildung (Abstraktion) und Konstruktionder Realität

71
Kartenlink

Wozu braucht man Modelle?

Verstehen eines Systems
Kommunizieren über ein System
Gedankliches Hilfsmittel zum Gestalten, Bewerten oder Kritisieren
Spezifikation von Anforderungen an ein geplantes Gebilde

Tags:
Quelle: IM7

72
Kartenlink

Merkmale eines Modelles

Abbildungsmerkmal

Abbild

Vorbild

Verkürzungsmerkmal

abstrahiert

Pragmatisches Merkmal

Verwendungszweck

Manchmal werden Modelle als Abstraktion eines Ausschnitts der Realität definiert

Tags:
Quelle: IM7

73
Kartenlink

Vorgehensweise Modellbildung

Reflektieren Überlegen und verstehen, was modelliert werden soll* Gewinnen Informationen über das Original und die Intentionen der Wissensträger gewinnen* Beschreiben Gewonnene Informationen verstehen, ordnen, strukturieren, bewerten und beschreiben* Validieren Modelle durch Wissensträger überprüfen lassen: Ist es das, was sie wollen und brauchen?

[Reingewinn bleibt variabel]

74
Kartenlink

Was bedeutet ARIS?

Architektur integrierter Informations-Systeme

Tags:
Quelle: IM7

75
Kartenlink

Sichten von ARIS

Organisationssicht (Wo? Wer?)
Prozess-(Steuerungs)sicht (Wann?)
Funktionssicht (Wie? Warum?)
Datensicht (Was?)

Tags:
Quelle: IM7

76
Kartenlink

2 Religionen des Modellierens

Model Driven Design

Code und Modell eng verbunden, vollständig* Code Generierung + Reverse Engineering* Tools sehr wichtig

Agile Modelling

Modelle nur soweit notwendig* Bruch zwischen den verschiedenen Ebenen ok* Tools nicht so wichtig* Kaum Modelle auf Implementations-Ebene

77
Kartenlink

Was sind die Vorteile von UML?

Eindeutigkeit
Ausdrucksstärke
Standardisierung und Akzeptanz
Plattform- und Sprachunabhängigkeit
Unabhängigkeit von Vorgehensmodellen

Tags:
Quelle: IM8b

78
Kartenlink

Komponentendiagramm

Das Komponentendiagramm modelliert die Organisation und Abhängigkeiten von Komponenten eines Systems.

Tags:
Quelle: Im8b

79
Kartenlink

Sequenzdiagramm

Sequenzdiagramme definieren den Nachrichtenfluss und zeigen die zeitliche Abfolge der Nachrichten zwischen Objekten.

Tags:
Quelle: IM8b

80
Kartenlink

was ist ein Aktivitätsdiagramm

Aktivitätsdiagramme modellieren das Verhalten von Systemen und bedienen sich dabei eines Kontroll- und Datenflussmodells.

81
Kartenlink

Zustandsdiagramm

In einem Zustandsdiagramm werden die möglichen Zustände, Zustandsübergänge, Ereignisse und Aktionen im »Leben« eines Systems modelliert.

Tags:
Quelle: IM8b

82
Kartenlink

Was ist ein Betrieb (oder Unternehmen)?

Einheit von zusammenwirkenden Personen und Produktionsmitteln zum Hervorbringen von Gütern und Leistungen

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

Tags:
Quelle: IM9

83
Kartenlink

Definition 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.

Tags:
Quelle: IM9

84
Kartenlink

Generisches Prozessmodell einer Unternehmung

85
Kartenlink

Bestandteile Managementprozesse

Strategieplanungsprozess
Qualitätsmanagementprozess
Controllingprozess

Tags:
Quelle: IM9

86
Kartenlink

Bestandteile Kernprozesse

Innovationsprozess* Vertriebsprozess (Leistungsverwertung)* Auftragsabwicklungsprozess (Leistungserstellung)* Serviceprozess

[Italien vertreibt alle Serben[

87
Kartenlink

Bestandteile Unterstützungsprozesse

Personalmanagementprozess
Finanzmanagementprozess
Ressourcenmanagementprozess
IT-Manangementprozess

Tags:
Quelle: IM9

88
Kartenlink

Definition eines Prozesses

Ein Prozess ist ein allgemeiner Ablauf mehrerer Schritte, bei denen es sich um Aufgaben, Ausführungen, Arbeitsschritte oder Ähnliches handeln kann. Zwischen diesen Prozessabschnitten bestehen bestimmte Abhängigkeiten.

Tags:
Quelle: IM9

89
Kartenlink

Was beinhaltet ein typischer Prozess?

Startereignis (Auslöser) > auch mehrere
Aktivität(en)
Sequenz
Parallelität
Abschlussereignis(se) > auch mehrere

Tags:
Quelle: IM9

90
Kartenlink

Was bedeutet EPK? was beinhaltet sie?

Ereignisgesteuerte Prozessketten

Grundprinzip: auf ein Ereignis folgt immer eine Funktion und umgekehrt* im deutschsprachigen Raum weit verbreitet* Wird insbesondere beim Einsatz von SAP zur Modellierung der Geschäftsprozesse eines Unternehmens eingesetzt* Erweiterung mit Informationsobjekten und Organisationseinheiten möglich (EEPK)

91
Kartenlink

Was gibt es neben EPK noch für Modellierungssprachen?

UML-Aktivitätsdiagramme
BPMN - Business Process Modeling Notation

Tags:
Quelle: IM9

92
Kartenlink

UML-Aktivitätsdiagramme

Funktionen werden als Aktivitäten modelliert* Ereignisse werden nur bei Fallunterscheidungen explizit modelliert* Organisationseinheiten und Informationsobjekte sind modellierbar* Parallelverarbeitung entspricht den UND-Konnektoren in EPK's

93
Kartenlink

was versteht man unter BPMN?

Business Process Modeling Notation
BPMN ist heute eine gängige Modellierungssprache für den Entwurf von Workflows in Unternehmungen, welche in der Praxis durch sogenannte Workflow-Engines ausgeführt werden können.

94
Kartenlink

Bei welchen Programmieraufgaben muss vorgängig keine Subsystem- und Komponentenbildung gemacht werden

übersichtlich und klein* hat eine geschlossene Problemstellung* und die Anwendung ist nicht verteilt

95
Kartenlink

Was ist die Grundidee der Funktionsmodellierung?

Komplexitätsreduktion bei der Beschreibung von Informationssystemen durch die Zerlegung in einzelne, abgegrenzte Teileinheiten.

96
Kartenlink

Welche Teile betrifft die Funktionsmodellierung?

die fachliche Beschreibung in der Systemanalyse
die programmtechnische Realisierung eines Systems

Tags:
Quelle: IM10b

97
Kartenlink

Was ist das grundsätzliche Anliegen der Funktionsmodellierung?

ein Informationssystem in verschiedene sachlich abgeschlossene Teileinheiten zu zerlegen.

98
Kartenlink

Welche 2 Grundtypen der Funktionsmodellierung werden im wesentlichen unterschieden?

Trennung der Verantwortlichkeiten
Geheimnisprinzip

Tags:
Quelle: IM10b

99
Kartenlink

Seperation of concerns

"Trennung der Verantwortlichkeiten" führt im Idealfall zu einer doppelten Modularisierung:

fachliche Komponenten durch die Trennung der fachlichen
In Schichten oder durch die Trennung der technischen Verantwortlichkeiten (waagerechte Schichtung)

Tags:
Quelle: IM10b

100
Kartenlink

Information Hiding

"Geheimnisprinzip"
Man zeigt einem Nutzer nur diejenigen Informationen, die er zur Erfüllung seiner Aufgabe braucht

OOP: Alle Daten sind „private“, Zugriff auf Daten von aussen nur über dedizierte Methoden
Fassade, die den Zugriff auf ein ganzes Subsystem regelt und das Subsystem vor direktem Zugriff schützt (z.B. ein Interpreter)
Schichten-Architektur: Schicht n sieht nur Schicht n-1, die anderen bleiben verborgen.

Tags:
Quelle: IM10b

101
Kartenlink

Was sind DV-Systeme?
Wie sieht die Leittechnikpyramide von DV-Systemen aus?

Datenverarbeitungssysteme

[Penner dürfen oben sitzen]

Tags:
Quelle: IM10b

102
Kartenlink

was versteht man unter Dekomposition?

sequentielle Zerlegung eines Systems in seine Teilfunktionen

Tags:
Quelle: IM10b

103
Kartenlink

Wie wird Dekomposition in technischen DV-Systemen realisiert?

Technische DV-Systeme (Datenverarbeitungs-Systeme) werden meist entlang der Grenzen der elektrischen / mechanischen Systemkomponenten welche sie steuern zerlegt

Tags:
Quelle: IM10b

104
Kartenlink

Was sind Kriterien von Dekomposition technischer DV-Systeme?

Sicherheit z.B. autonomes Abschalten* Verteilung der Intelligenz zentrale Intelligenz vs. lokale Intelligenz<div style="padding-left:5px;">- Reaktionsgeschwindigkeit der Regelung</div><div style="padding-left:5px;">- Kontrollierbarkeit im Inselbetrieb</div>* Art der Kommunikation Polling vs. eventbasiertes Messaging, Übertragung des Zustandes oder nur der Veränderung (abhängig vom Bus-System)* Fehler- und Alarmierungs-Propagation über die Ebenen der Leittechnik

105
Kartenlink

Was ist die gängiste Struktur der Realisation von Entwürfen ereignisgesteuerter Systeme?

Zerlegung des gesamten Systems in Subactivities bis hinunter
zu basic Activities.
Jede Activity inkl. top level Activity enthält eine Control Activity.

Tags:
Quelle: IM10b

106
Kartenlink

Wie funktioniert die Entwurfsstruktur bei der die Top Level Activity keine Control Activity enthält?

Beim Starten der Simulation sind alle Activities gemeinsam aktiv. Die Steuerung der Activities wird durch Events ermöglicht:

Eine Activity konsumiert Eingangsinformationen, manipuliert diese Informationen und produziert daraus Ausgangsinformationen.
Leitet man aus der Erzeugung der Ausgangsinformationen einen Event ab, so kann dieser die Control Activities der "nächsten" Activity anstossen.

Tags:
Quelle: IM10b

107
Kartenlink

Was sind Software-Kategorien im Zusammenhang Dekomposition betrieblicher DV-Systeme?

Software-Kategorie ist alle Software, die das Know-How eines bestimmten Gebietes enthält.
Software-Kategorien können verfeinert werden.
erste Schritt bei funktionalen Zerlegung eines Systems ist Aufstellung der Software-Kategorien und Analyse der Abhängigkeiten dazwischen.
Die Kategorien liefern bereits eine erste grobe Aufteilung des Systems in funktionale Bausteine.

Tags:
Quelle: IM10b

108
Kartenlink

Was sind Techniken und Tools zur Dekomposition grösserer Systeme

UML Aktivitäts-Diagramme
Deployment-Diagramme
Komponentendiagramme

Tags:
Quelle: IM10b

109
Kartenlink

Deployment-Diagramme

unterstützen Modellierung verteilter Systeme. Subsysteme und Komponenten können Knoten zugeordnet werden. Die Kommunikationsverbindungen zwischen den Knoten kann dargestellt werden und bei Bedarf lassen sich Abhängigkeiten zwischen den Elementen aufzeigen.

Tags:
Quelle: IM10b

110
Kartenlink

Komponentendiagramme

unterstützen die Strukturierung von Systemen in Subsysteme und Komponenten.

Tags:
Quelle: IM10b

111
Kartenlink

Was skizziert man mit der Grobplanung?

einen groben Zeit- und Meilensteinplan
einen grobe Aufwand- und Kostenschätzung

Voraussetzung für diese Grobplanung sind die Projektresultate und eine grobe Lösungsskizze (Approach)

Tags:
Quelle: IM11

112
Kartenlink

Was ist der Approach

Die Lösungsskizze oder englisch Approach beschreibt, wie man gedenkt mit dem Projekt die Probleme zu lösen.
Dies kann eine Optimierung eines Prozesses sein, die Entwicklung oder der Einkauf einer oder mehrere Applikationen und vielleicht der Umbau einer Organisation.

Tags:
Quelle: IM11

113
Kartenlink

Was ist ein Kontext Diagramm?

veranschaulicht in Konzeptionsphase das Umfeld des zu realisierenden IT-Systems. Insbesondere wird klar abgegrenzt, was zum Aufgabenbereich des IT-Systems gehört und was
veranschaulicht grob, welche Informationen in das System hinein fließen und welche Informationen das System liefern kann. Das

Tags:
Quelle: IM11

114
Kartenlink

Pyramide der Begriffshierarchie

[Wissen ist die Zukunft]

Tags:
Quelle: IM12

115
Kartenlink

Was sind Daten?

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

Tags:
Quelle: IM12

116
Kartenlink

Was ist eine Datenbank?

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

Tags:
Quelle: IM12

117
Kartenlink

Was ist ein Datenmodell?

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

Tags:
Quelle: IM12

118
Kartenlink

Was heisst Datenmodellierung?

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

Tags:
Quelle: IM12

119
Kartenlink

Schritt 1 des Informationsstrukturmodelles

Merkmale charakterisieren die zugehörigen Informationsobjekte
Gleichartige Merkmale werden als Ausprägungen einer gemeinsamen Merkmalsklasse verstanden
Alle Merkmale, die einem Informationsobjekt zuzuordnen sind, werden als charakterisierende Merkmalskombination bezeichnet.

Tags:
Quelle: IM12

120
Kartenlink

Schritt 2 des Informationsstrukturmodelles

Gleichartige Informationsobjekte bilden Informationsobjektklassen (IOK) (Generalisiserung)
Informationsobjekte sind gelicharti, wenn sie durch Merkmalskombinationen derselben Merkmalsklassenkombination charakterisiert werden.

Tags:
Quelle: IM12

121
Kartenlink

Schritt 3 des Informationsstrukturmodelles

Verknüpfungen zwischen Informationsobjektklassen
Verknüpfungstypen:

Nach der Kardinalität
Nach der Optionalität

feste

optionale

Tags:
Quelle: IM12

122
Kartenlink

Was ist der Unterschied zwischen einem Entity-Typ und Entity?

Entity ist unterscheidbares Objekt der Realwelt, das ein reales Objekt oder gedankliche Abstraktion darstellen kann z.B. Sudent klein, Buch "Datenbanksysteme"* Entity-Typ ist Zusammenfassung von gleichartigen Entities, welche gleiche Eigenschaften besitzen.z.B. Studenten, Bücher

123
Kartenlink

Regeln für vereinfachtes ER-Modell

Kardinalität wird mit „1-m-c“ dargestellt
Relationship-Typ werden weggelassen, an ihre Stelle tritt die Bezeichnung der Beziehungen der beiden Entitäten
Definition der Attribute wird in separaten Dokument erstellt
Pro Entitätsmenge und pro Attribut gibt es eine kurze Beschreibung
Schlüsselattribut wird ausgezeichnet. Ein Schlüsselattribut identifiziert eine Entität eindeutig.

Tags:
Quelle: IM12

124
Kartenlink

Was sind Attribute im ER-Modell?

Eigenschaften eines Entity-oder Relationship-Typs werden Attribute genannt.
Jedes Attribut hat einen bestimmten Wertebereich
Ein Attribut das jedes Entity eines Entity-Typs eindeutig identifiziert heisst Schlüssel bzw. Schlüsselkandidat
z.B. Matrikelnr. von STUDENT, Erscheinungsjahr von BÜCHER

Tags:
Quelle: IM12

125
Kartenlink

Welche Architektursichten werden im Systemdesign unterschieden?

Kontextsicht
Bausteinsicht
Laufzeitsicht
Verteilungssicht

Tags:
Quelle: IM13a

126
Kartenlink

Was sind wesentliche Schritte, die zu einem guten Systemdesign führen?

1. Informationen sammeln
2. Systemidee entwickeln
3. Einflussfaktoren und Randbedingungen würdigen
4. Risiken identifizieren
5. Qualität explizit beschreiben
6. Lösungsstrategien entwickeln
[Inder sind Extrem rauchende Qaualitäts-Lümmel]

127
Kartenlink

Vorgehen Systementwurf:
Informationen Sammeln

Gute Lösungen lassen sich i.d.R. auf bekannte Dinge zurückführen* Völlig eigenständige Ansätze sind oft unnötig aufwändige Folge mangelhafter Recherche und nicht wirklich genial* Wie haben andere vor Ihnen ähnliche Probleme gelöst:<div style="padding-left:5px;">- Lassen sich Ergebnisse anderer Projekte in der Organisation wieder verwenden?</div><div style="padding-left:5px;">- Sind im Internet ähnliche Systeme beschrieben, kann man möglicherweise sogar geeignete Komponenten kaufen?</div><div style="padding-left:5px;">- Passen Referenzarchitekturen, Architektur- oder Entwurfsmuster auf Problemstellung?</div>

128
Kartenlink

Vorgehen Systementwurf:
Systemidee entwickeln

Systemidee ist Grundlage für Abstimmung mit<div style="padding-left:5px;">- Kunden</div><div style="padding-left:5px;">- Auftraggeber</div><div style="padding-left:5px;">- Projektteam</div>* Systemidee ist Basis für künftige weitere Entwurfsentscheidungen

129
Kartenlink

Vorgehen Systementwurf:
Randbedingungen

Ingenieure tendieren zur Unterschätzung organisatorischer und politischer Faktoren* kann im Extremfall dazu führen, dass lauffähige Systeme realisiert werden, aber nie zum Einsatz kommen* Faktoren, die möglicherweise für das Systemdesign relevant sind:<div style="padding-left:5px;">- Organisatorische und politische Faktoren</div><div style="padding-left:5px;">- Technische Faktoren</div><div style="padding-left:5px;">- System- bzw. Produktfaktoren</div>

130
Kartenlink

Vorgehen Systementwurf:
Risiken

Entwurfsentscheidungen und Projektrisiken beeinflussen sich gegenseitig* gutes Risikomanagement hilft, bestehenden Risiken minimier und keine neuen Risiken in Kauf genommen werden

131
Kartenlink

Vorgehen Systementwurf:
Qualität

Qualität muss konstruiert werden. Qualitätsmerkmale sind Entwurfsziele* Qualitätsmerkmale wie Performance, Wartbarkeit und Verständlichkeit sind nur auf Grundlage eines entspr. Systemdesigns erreichbar* Szenarien einsetzen und so Qualitätsmerkmale zu operationalisieren und praxisgerecht zu konkretisieren<div style="padding-left:5px;">- Anwendungsszenarien</div><div style="padding-left:5px;">- Änderungsszenarien</div><div style="padding-left:5px;">- Stress</div><div style="padding-left:5px;">- Grenzszenarien</div>

132
Kartenlink

Vorgehen Systementwurf:
Lösungsstrategien

Für typischen Herausforderungen bei Softwareprojekten gibt es zwar keine “silver bullets“ aber immerhin erprobte Strategien

Mangel an Zeit, Budget und Erfahrung: Enge Kooperation mit Projektmanagement, offenlegen der Risiken, Ettappierung der Auslieferung, Anpassung der Anforderungen, und: addig people to a late project makes it even later* Performanceprobleme Optimieren nur, wenn z.B. mit Profiler Bottelnecks identifiziert sind, zusätzliche oder leistungsfähigere Hardware ist billiger als optimieren, ungünstige Verteilung und suboptimale Kommunikation sind Ressourcenfresser* Probleme mit Anpassbarkeit und Flexibilität Subsysteme und Komponenten über Adapter, Fassaden, Proxies, entkoppeln; explizite Interfaces vorsehen, Konfigurationsdaten in Dateien statt im Code.

133
Kartenlink

wieso braucht es iterationen im Systementwurf

Sowohl Ihre Kunden wie auch andere Projektbeteiligte ändern Anforderungen und Einflussfaktoren* Aufgrund dieser Änderungen müssen Sie Ihr Systemdesign immer wieder den veränderten Gegebenheiten anpassen* Architekturen, die an den wirklichen Bedürfnissen und Anforderungen orientiert sind, entstehen iterativ

134
Kartenlink

welche 2 Komplexitäten werden unterschieden?

natürliche Komplexität ist die Komplexität des zu Grunde liegenden Problems. Eine Software kann nicht einfacher sein als das Problem, welches sie löst. ->beherrschen
künstliche Komplexität kommt bei der Entwicklung dazu, trägt aber nichts zur Lösung des Problems bei. ->vermeiden

Tags:
Quelle: IM13a

135
Kartenlink

Was sind Heuristiken?

Regeln zum Umgang mit komplexen Aufgaben, entstanden aus verallgemeinerten und abstrahierten Erfahrungen.

Darum können Heuristiken lediglich Hinweise geben auf dem Weg zum guten Systementwurf, aber ohne Erfolgsgarantie, denn Entwurf bleibt (zum Glück) eine kreative Tätigkeit.

Tags:
Quelle: IM13a

136
Kartenlink

Welchen Stakeholder müssen Entwurfsentscheidungen kommuniziert werden? Wieso?

Auftraggeber / Nutzer
Entwicklungsteam
Betrieb und Wartung

Beim Systementwurf werden wichtige Entscheidungen gefällt die Einfluss auf Entwicklung, Betrieb und Wartung haben.

Weil Lebensdauer von IT-Systemen oft Jahrzehnte beträgt, muss Architektur so dokumentiert werden, dass Generationen von Entwicklern das System verstehen und an neue Bedürfnisse anpassen und können.

Tags:
Quelle: IM13b

137
Kartenlink

Was ist Abstraktion im Zusammenhang von Systemdesign

Code, bzw. aus dem Code generierte Klassendiagramme haben ein zu tiefes Abstraktionsniveau für eine hilfreiche Kommunikation des Systemdesigns.

Das ist, wie wenn Sie einem Chinesen sagen, Sie studieren im Trakt II

Tags:
Quelle: IM13b

138
Kartenlink

Was sind Sichten im Systemdesign?

In einer einzelnen Darstellung lässt sich die Vielschichtigkeit und Komplexität eines Systemdesigns nicht ausdrücken.
Sichten erlauben die Konzentration auf bestimmte Aspekte, indem sie von Details abstrahieren, die für die gewählte Perspektive nicht von Bedeutung sind.

Tags:
Quelle: IM13b

139
Kartenlink

Was sind Kontextsichten im Systemdesign?

Wie ist das System in seine Umgebung eingebettet?

Kontextsichten zeigen das System als Blackbox in seinem Kontext aus einer Vogelperspektive* Hier zeigen Sie<div style="padding-left:5px;">- Schnittstellen zu Nachbarsystemen</div><div style="padding-left:5px;">- Interaktionen mit wichtigen Stakeholdern</div><div style="padding-left:5px;">- wesentlichen Teile der umgebenden Infrastruktur</div>* Diese Sicht können Sie als „Vision" etwas abstrakter betrachten als die übrigen Sichten.

140
Kartenlink

Was sind Bausteinsichten im Systemdesign?

Wie ist das System intern aufgebaut?

Bausteinsichten zeigen die statischen Strukturen der<div style="padding-left:5px;">- Architekturbausteine des Systems</div><div style="padding-left:5px;">- Subsysteme</div><div style="padding-left:5px;">- Komponenten und deren Schnittstellen</div>* Sie können die Bausteinsichten top-down entwickeln, ausgehend von einer Kontextsicht* Die letzte mögliche Verfeinerungsstufe der Zerlegung bildet der Quellcode* Bausteinsichten<div style="padding-left:5px;">- unterstützen PL und Auftraggeber bei Projektüberwachung</div><div style="padding-left:5px;">- dienen der Zuteilung von Arbeitspaketen</div><div style="padding-left:5px;">- fungieren als Referenz für Software-Entwickler</div>

141
Kartenlink

Was sind Laufzeitsichten im Systemdesign?

Wie läuft das System ab?

Laufzeitsichten beschreiben, wie Bausteine des Systems zur Laufzeit zusammenwirken.
beschreiben Sie dynamische Strukturen

Tags:
Quelle: IM13b

142
Kartenlink

Was sind Verteilungssichten im Systemdesign?

In welcher Umgebung läuft das System ab?

beschreiben die Hardwarekomponenten, auf denen das System abläuft. Sie dokumentieren<div style="padding-left:5px;">- Rechner</div><div style="padding-left:5px;">- Prozessoren</div><div style="padding-left:5px;">- Netztopologien und -protokolle</div><div style="padding-left:5px;">- sonstige Bestandteile der physischen Systemumgebung</div>* Die Infrastruktursicht zeigt das System aus Betreibersicht.

143
Kartenlink

Welche Elemente zeigt die Kontextsicht?

System als BlackBox
Schnittstellen zu Anwendern und Fremdsystemen, inkl. Daten & Steuerfluss
Toplevel UseCases
Technische Umgebung (Kommunikationskanäle, Rechnersysteme)

Tags:
Quelle: IM13b

144
Kartenlink

Welche Elemente zeigt die Bausteinsicht?

zeigen die Aufteilung der Funktionalität des Systems* Aus Sicht der Entwickler<div style="padding-left:5px;">- In Pakete</div><div style="padding-left:5px;">- evtl. Klassen</div>* Im lauffähigen System<div style="padding-left:5px;">- In Subsysteme</div><div style="padding-left:5px;">- Komponenten</div>* Hierarchisch verfeinern: Subsysteme -> Komponenten -> Objekte* Vollständig bezüglich Schnittstellen & Abhängigkeiten der dargestellten Elemente

145
Kartenlink

Welche Elemente zeigt die Laufzeitsicht?

wie die Systembestandteile bei der Ausführung zusammenwirken
Wie verhält sich System beim Hochfahren
Wie werden wichtige UseCases bearbeitet
Wie arbeiten wichtige Systemkomponenten zusammen

Tags:
Quelle: IM13b

146
Kartenlink

Welche Elemente zeigt die Verteilungssicht?

beschreiben technische Infrastruktur auf der das System abläuft.* Wesentliche Elemente sind<div style="padding-left:5px;">- Knoten (Rechner vom Mainframe bis zum µC)</div><div style="padding-left:5px;">- Kanäle (Kommunikationsverbindungen)</div><div style="padding-left:5px;">- Komponenten (Software)</div>

147
Kartenlink

Was heisst Persistenz?

Fähigkeit, Daten über lange Zeit bereitzuhalten. Das gilt bsp. für nichtflüchtige Speichermedien oder für Dateisysteme oder Datenbanken.

Tags:
Quelle: IM13c

148
Kartenlink

Wieso soll manchmal eine Persistenzsicht eingeführt werden?

Kümmert sich jede fachliche Komponente selbst um die Persistenz ihrer Objekte führt jede Änderung an der DB zu Quellcodeänderungen
Bei grossen Anzahl Fachklassen, wenn vernetzte Objektstrukturen persistiert werden müssen bzw. die Abbildung auf die Datenbank(en) komplex ist, lohnt sich der Entwurf einer Persistenzschicht
Persistenzschichten vermitteln zwischen Anwendung und

Tags:
Quelle: IM13c

149
Kartenlink

Was heisst Legacy?

Eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist das englische Wort für Vermächtnis, Hinterlassenschaft, Altlast
Innerhalb der Anwendungslandschaft eines Unternehmens sind zumeist großrechnerbasierte Individualentwicklungen, die sich oft durch unzureichende Dokumentation, veraltete Betriebs- und Entwicklungsumgebungen, zahlreiche Schnittstellen und hohe Komplexität auszeichnen. Die dort anzutreffende zentrale Daten- und Funktionshaltung galt seit der Client/Server-Euphorie als überholt.

Tags:
Quelle: IM13c

150
Kartenlink

Was ist zu beachten bei SW-Entwicklung in Legacy-Kontext?

Eingriff in die Legacy soll mininmal invasiv gestaltet werden:<div style="padding-left:5px;">- Bestehende Schnittstellen unterstützen</div><div style="padding-left:5px;">- bestehende Daten beim Entwurf berücksichtigen</div><div style="padding-left:5px;">- Verantwortlichkeit alt/neu klar abgrenzen</div>* Lösungsansätze<div style="padding-left:5px;">- Dateitransfer</div><div style="padding-left:5px;">- Gemeinsame Datenbank</div><div style="padding-left:5px;">- Synchrone Applikationsintegration (RPC)</div><div style="padding-left:5px;">- Asynchrone App.Integration (Messaging, z.B. CORBA)</div>

151
Kartenlink

Was heisst SoDa

Software development agile

152
Kartenlink

Ablauf Scope