CoboCards App FAQ & Wünsche Feedback
Sprache: Deutsch Sprache
Kostenlos registrieren  Login

Hol' Dir diese Lernkarten, lerne & bestehe Prüfungen. Kostenlos! Auch auf iPhone/Android!

E-Mail eingeben: und Kartensatz kostenlos importieren.  
Und Los!
Alle Oberthemen / Informatik / IT-Konzepte und Modelle

IM (162 Karten)

Sag Danke
1
Kartenlink
0
was beinhaltet die Systemidee
  • Kernaufgabe* Nutzungsart und Nutzer* Schnittstellen* Datenhaltung* Kontrolle
2
Kartenlink
0
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
0
Was bedeutet CIS?
Customer Information System
Tags:
Quelle: IM1
4
Kartenlink
0
In welcher Phase wird das Grobkonzept erstellt?
initialisierungsphase
Tags:
Quelle: IM2
5
Kartenlink
0
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
0
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
0
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
0
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
  • - eine Leistung (erwünschtes Verhalten) ODER- eine Eigenschaft.
  • In einem Grobkonzept werden zur Detaillierung der Ziele die wichtigsten Anforderungen grob beschrieben.
Tags:
Quelle: IM2
9
Kartenlink
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
  • <span class="small">- eine Leistung (erwünschtes Verhalten) ODER- eine Eigenschaft.</span>
  • Das Requirements Engineering ist diejenige Disziplin, welche die Anforderungen an das Zielsystem aktiv durch ihren gesamten Lebenszyklus begleitet.
Tags:
Quelle: IM2
20
Kartenlink
0
Was sind die 3 Haupttätigkeiten des Requirements Engineering?
- Sammeln
- Ausarbeiten (Dokumentieren & Prüfen)
- Verwalten
Tags:
Quelle: Kp3
21
Kartenlink
0
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
0
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
0
Prozentual wie viele Fehler passieren in Analyse und Designphase?
Analysephase: 60%
Design & Implementierung: 40%
Tags:
Quelle: Kp3
24
Kartenlink
0
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
0
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
0
Ebenen der Anforderungen
Tags:
Quelle: Kp3
27
Kartenlink
0
Requirements Engineering: Hauptaktivitäten
• Sammeln
  - Gewinnung
  - Analyse
• Ausarbeiten
  - Spezifikation
  - Validierung
• Verwalten
  - Freigabe
  - Änderung (Change Management!)
  - Verfolgung
Tags:
Quelle: Kp3
28
Kartenlink
1
Anforderungspyramide

[Vampiere fressen Ratten]
29
Kartenlink
0
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
0
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
0
woraus bestehen sprints
  • dem Sprint Planning* dem Daily Meeting* der eigentlichen Entwicklungsarbeit* der Sprint Abnahme* der Sprint Retrospektive
32
Kartenlink
0
Requirement Engineering
Sammeln; Aus welchen Quellen schöpfen?
  • Stakeholder
  • Vorhandene Dokumentation
  • Gesetze und Verordnungen usw.
Tags:
Quelle: IM3b
33
Kartenlink
0
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
0
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
0
Requirement Engineering
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
Tags:
Quelle: IM3b
36
Kartenlink
0
Requirement Engineering
Ausarbeiten; Kategorien von Anforderungen
  • Funktional/Nichtfunktional
  • Vorschrift/Tatsache/Annahme
  • Hart (Sperrung nach Ablauf) / Weich (einfach nutzbar)
  • Repräsentation:
  • - Operational: Kontostand = Kontostand + Buchungsbetrag- Quantitativ: Antwortzeit < x- Qualitativ: Hohe Verfügbarkeit- Deklarativ: Soll unter LINUX laufen
Tags:
Quelle: IM3b
37
Kartenlink
0
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
0
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
0
Requirement Engineering
Verwalten; Anforderungs-Datenbasis
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 UCs
Tags:
Quelle: IM3b
40
Kartenlink
0
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
0
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!
  • - Also: Nicht das Durchführen eines Workshops ist interessant, sondern z.B. die daraus hervorgegangenen Anforderungen.
  • Projektresultate präzise und vollständig definieren und beschreiben!
Tags:
Quelle: IM4
42
Kartenlink
0
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
0
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
0
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
0
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
0
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
0
4 Rollen im SoDa Projekt
  • Projektleiter/-in
  • Schlüsselrolle in der Initialisierungs- und Einführungsphase: Rahmenplanung, Organisation, Meilensteine, Produkteinführung
  • Product Owner
  • (Schlüsselrolle in Konzeptions- und Realisierungsphase:  ProductBacklog-Pflege & -Priorisierung, Sprint-Planung & -Abnahme)
  • Scrum Master
  • («servant leader» für das Team und den Product Owner: unterstützt korrektes Vorgehen und stellt die Qualität sicher)
  • Scrum Team
  • (Entwickler/innen, die selbstorganisiert und eigenverantwortlich in den Sprints die Software entwerfen, erstellen und testen)
Tags:
Quelle: IM5a
48
Kartenlink
0
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
0
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
0
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
0
PMP
Projektmanagementplan mit folgenden Kapiteln:
  • Einleitung
  • Projektorganisation
  • Projektführung
  • Projektunterstützung
  • Anhänge

Tags:
Quelle: IM5a
52
Kartenlink
0
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
0
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
  • • Begriffe, Abkürzungen und Referenzen

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
0
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
0
Instrumente der Projekt-Übersicht
  • der Projektstrukturplan (PSP)
  • der Rahmenplan
Tags:
Quelle: IM5b
56
Kartenlink
0
Möglichkeiten des Aufbaus eines Projektstrukturplanes
  • objektorientierte Strukturierung (nach Komponenten) 
  • vorgehensorientierte Strukturierung (nach Projektphasen)
Tags:
Quelle: IM5b
57
Kartenlink
0
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
0
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
0
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
0
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
0
80/20 – Regel
Das Pareto-Prinzip

Eine Minderheit von Ursachen führt zu einem Grossteil der Ergebnisse
62
Kartenlink
0
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
0
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
0
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
0
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
0
Risiken identifizieren
  • Systematik zur Risikoidentifikation
  • "Jäger und Sammler-Ansatz" liefert aktuelle,  nicht aber wichtigen Risiken. Projekte in Umfeld haben ähnliche Risikoprofile. 
  • Bezug zu den Erfolgsfaktoren
  • Risikoidentifikation soll klaren strategischen Bezug haben und sich auf Erfolgsfaktoren konzentrieren (z.B.Kernkompetenzen)
  • Einsatz von Fachexperten
Tags:
Quelle: IM5b
67
Kartenlink
0
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
0
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
0
Risikomatrix
Tags:
Quelle: IM5b
70
Kartenlink
0
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
0
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
0
Merkmale eines Modelles
  • Abbildungsmerkmal
  • Jedes Modell ist Abbild oder Vorbild
  • Verkürzungsmerkmal
  • Jedes Modell abstrahiert
  • Pragmatisches Merkmal
  • Jedes Modell wird im Hinblick auf einen Verwendungszweck geschaffen
  • Manchmal werden Modelle als Abstraktion eines Ausschnitts der Realität definiert
Tags:
Quelle: IM7
73
Kartenlink
0
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
0
Was bedeutet ARIS?
Architektur integrierter Informations-Systeme
Tags:
Quelle: IM7
75
Kartenlink
0
Sichten von ARIS
  • Organisationssicht (Wo? Wer?)
  • Prozess-(Steuerungs)sicht (Wann?)
  • Funktionssicht (Wie? Warum?)
  • Datensicht (Was?)
Tags:
Quelle: IM7
76
Kartenlink
0
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
0
Was sind die Vorteile von UML?
  • Eindeutigkeit
  • Notationselemente besitzen eine präzise Semantik
  • Ausdrucksstärke
  • Ausschöpfung aller Möglichkeiten der verfügbaren Notationselemente erlaubt die nahezu vollständige Definition aller wichtigen Details eines Softwaresystems
  • Standardisierung und Akzeptanz
  • ist Weltweit in Softwarebranche im Einsatz. Der Object Management Group, die für die Spezifikation der UML verantwortlich ist, gehören mittlerweile mehr als 800 Unternehmen an
  • Plattform- und Sprachunabhängigkeit
  • Mit der UML können Sie Softwaresysteme für jede denkbare Plattform und Programmiersprache modellieren. Sie hat ihre Stärken in der objektorientierten Welt, kann aber ohne weiteres auch für prozedurale Sprachen eingesetzt werden
  • Unabhängigkeit von Vorgehensmodellen
  • UML definiert mit ihren Diagrammen und Notationselementen »Werkzeuge«, um die Visualisierung von Softwaresvstemen zu erleichtern. Sie überlässt den Soflwareentwicklern die Entscheidung, wie sie diese Werkzeuge am effizientesten nutzen.
Tags:
Quelle: IM8b
78
Kartenlink
0
Komponentendiagramm
Das Komponentendiagramm modelliert die Organisation und Abhängigkeiten von Komponenten eines Systems. 
Tags:
Quelle: Im8b
79
Kartenlink
0
Sequenzdiagramm
Sequenzdiagramme definieren den Nachrichtenfluss und zeigen die zeitliche Abfolge der Nachrichten zwischen Objekten. 
Tags:
Quelle: IM8b
80
Kartenlink
0
was ist ein Aktivitätsdiagramm
Aktivitätsdiagramme modellieren das Verhalten von Systemen und bedienen sich dabei eines Kontroll- und Datenflussmodells.
81
Kartenlink
0
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
0
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
0
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
0
Generisches Prozessmodell einer Unternehmung
85
Kartenlink
0
Bestandteile Managementprozesse
  • Strategieplanungsprozess
  • Qualitätsmanagementprozess
  • Controllingprozess
Tags:
Quelle: IM9
86
Kartenlink
0
Bestandteile Kernprozesse
  • Innovationsprozess* Vertriebsprozess (Leistungsverwertung)* Auftragsabwicklungsprozess (Leistungserstellung)* Serviceprozess

[Italien vertreibt alle Serben[
87
Kartenlink
0
Bestandteile Unterstützungsprozesse
  • Personalmanagementprozess
  • Finanzmanagementprozess
  • Ressourcenmanagementprozess
  • IT-Manangementprozess
Tags:
Quelle: IM9
88
Kartenlink
0
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
0
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
0
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
0
Was gibt es neben EPK noch für Modellierungssprachen?
  • UML-Aktivitätsdiagramme
  • BPMN - Business Process Modeling Notation
Tags:
Quelle: IM9
92
Kartenlink
0
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
0
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
0
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
0
Was ist die Grundidee der Funktionsmodellierung?
Komplexitätsreduktion bei der Beschreibung von Informationssystemen durch die Zerlegung in einzelne, abgegrenzte Teileinheiten.
96
Kartenlink
0
Welche Teile betrifft die Funktionsmodellierung?
  • die fachliche Beschreibung in der Systemanalyse
  • die programmtechnische Realisierung eines Systems
Tags:
Quelle: IM10b
97
Kartenlink
0
Was ist das grundsätzliche Anliegen der Funktionsmodellierung?
ein Informationssystem in verschiedene sachlich abgeschlossene Teileinheiten zu zerlegen.
98
Kartenlink
0
Welche 2 Grundtypen der Funktionsmodellierung werden im wesentlichen unterschieden?
  • Trennung der Verantwortlichkeiten 
  • Separation of Concerns
  • Geheimnisprinzip 
  • Information Hiding
Tags:
Quelle: IM10b
99
Kartenlink
0
Seperation of concerns
"Trennung der Verantwortlichkeiten" führt im Idealfall zu einer doppelten Modularisierung:
  • fachliche Komponenten durch die Trennung der fachlichen
  • Verantwortlichkeiten (senkrechte Gliederung)
  • In Schichten oder durch die Trennung der technischen Verantwortlichkeiten (waagerechte Schichtung)

Tags:
Quelle: IM10b
100
Kartenlink
0
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
0
Was sind DV-Systeme?
Wie sieht die Leittechnikpyramide von DV-Systemen aus?
Datenverarbeitungssysteme

[Penner dürfen oben sitzen]
Tags:
Quelle: IM10b
102
Kartenlink
0
was versteht man unter Dekomposition?
sequentielle Zerlegung eines Systems in seine Teilfunktionen
Tags:
Quelle: IM10b
103
Kartenlink
0
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
0
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
0
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
0
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
0
Was sind Software-Kategorien im Zusammenhang Dekomposition betrieblicher DV-Systeme?
  • Software-Kategorie ist alle Software, die das Know-How eines bestimmten Gebietes enthält. 
  • Beispiel: „Was tut / kann / weiss das Ding??“ Software-Kategorien helfen erheblich bei der Komponentisierung eines Systems − sie sind sozusagen die Komponenten-Behälter.
  • 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
0
Was sind Techniken und Tools zur Dekomposition grösserer Systeme
  • UML Aktivitäts-Diagramme
  • Deployment-Diagramme
  • Komponentendiagramme
Tags:
Quelle: IM10b
109
Kartenlink
0
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
0
Komponentendiagramme
unterstützen die Strukturierung von Systemen in Subsysteme und Komponenten.
Tags:
Quelle: IM10b
111
Kartenlink
0
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
0
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
0
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
  • nicht.
  • veranschaulicht grob, welche Informationen in das System hinein fließen und welche Informationen das System liefern kann. Das
  • Kontextdiagram wird zu einer sehr frühen Phase der Systemkonzeption eingesetzt.
Tags:
Quelle: IM11
114
Kartenlink
0
Pyramide der Begriffshierarchie

[Wissen ist die Zukunft]
Tags:
Quelle: IM12
115
Kartenlink
0
Was sind Daten?
Angaben über Sachverhalte und Vorgänge aufgrund bekannter oder unterstellter Abmachungen in einer maschinell verarbeitbaren Form.
Tags:
Quelle: IM12
116
Kartenlink
0
Was ist eine Datenbank?
selbständige, auf Dauer und für den flexiblen und sicheren Gebrauch ausgelegte Datenorganisation
Tags:
Quelle: IM12
117
Kartenlink
0
Was ist ein Datenmodell?
Formale Beschreibung des Schemas, z. B. in Form eines Diagramms oder einer Datenstruktur.
Tags:
Quelle: IM12
118
Kartenlink
0
Was heisst Datenmodellierung?
Prozess, der sicherstellen soll, dass eine Datenbasis zu jedem Zeitpunkt ein korrektes Abbild der Diskurswelt wiedergibt.
Tags:
Quelle: IM12
119
Kartenlink
0
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
0
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
0
Schritt 3 des Informationsstrukturmodelles
Verknüpfungen zwischen Informationsobjektklassen
Verknüpfungstypen:
  • Nach der Kardinalität
  • 1:1, 1:N, M:N
  • Nach der Optionalität
  • feste Verknüpfungen oder optionale Verknüpfungen
Tags:
Quelle: IM12
122
Kartenlink
0
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
0
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
0
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
0
Welche Architektursichten werden im Systemdesign unterschieden?
  • Kontextsicht
  • Bausteinsicht
  • Laufzeitsicht
  • Verteilungssicht
Tags:
Quelle: IM13a
126
Kartenlink
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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
0
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 
  • unterschiedlichen Speichersystemen
Tags:
Quelle: IM13c
149
Kartenlink
0
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
0
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
0
Was heisst SoDa
Software development agile
152
Kartenlink
0
Ablauf Scope
  • Systemgrenze bilden
  • Einflussgrössen ermitteln
  • Unter- und Teilsysteme definieren
  • Schnittstellen definieren
  • Analyse der Unter- und Teilsysteme
  • Gemeinsamkeiten ermitteln

[SEUSAG]
153
Kartenlink
0
Ursachen für unzfriedenheit in Firma
  • Kundenwünsche, Marktdruck
  • neue Technologie
  • neue Gesetze
  • Ineffiziente Abläufe
  • Systemfehler
  • Überalterung von Systemen
154
Kartenlink
0
Erfolgsquote in SW- und IT-Projekten
35%

Hauptgründe für Projektprobleme: Prozessfähigkeit, Organisationsmanagement, Requirements Engineering (87%)
155
Kartenlink
0
Was sind die Phasen in SoDa Entwicklungsprojekten
  • Initialisierungsphase
  • Konzeptionsphase
  • Realisierungsphase
  • Einführungsphase

[Ingrid kauft rohe Eier]
156
Kartenlink
0
Präzise Beschreibung der Projektresultate
  • Ziele
  • Hauptresultat
  • Teilresultat
  • Arbeitspaket
157
Kartenlink
0
Was sind die Phasen in SoDa Entwicklungsprojekten
  • Initialisierungsphase* Konzeptionsphase* Realisierungsphase* Einführungsphase

[Inder kaufen rohe Eier]
158
Kartenlink
0
Was sind die Phasen in SoDa Entwicklungsprojekten
  • Initialisierungsphase* Konzeptionsphase* Realisierungsphase* Einführungsphase

[Inder kaufen rohe Eier]
159
Kartenlink
0
Für was wird IT gebraucht
Unterstützung Geschäftsprozesse
160
Kartenlink
0
2 Unterscheidungen in der IT
  • entwickeln
  • betreiben
161
Kartenlink
0
Welche Tätigkeiten gehören nach Jenny zur Projektführung
  • Projektstart
  • Projektplanung
  • Projektsteuerung
  • Projektkontrolle
  • Projektabschluss
162
Kartenlink
0
Ebenen der Modellierung
  • Konzept-Ebene
  • Architektur-Ebene
  • Implementierung-Ebene

KAI
Kartensatzinfo:
Autor: CoboCards-User
Oberthema: Informatik
Thema: IT-Konzepte und Modelle
Schule / Uni: hslu
Ort: Luzern
Veröffentlicht: 12.03.2013
Tags: IM
 
Schlagwörter Karten:
Alle Karten (162)
keine Schlagwörter
Missbrauch melden

Abbrechen
E-Mail

Passwort

Login    

Passwort vergessen?
Deutsch  English