Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Vorgehensmodelle > Flashcards

Vorgehensmodelle Flashcards

1
Q

Aufgaben von Vorgehensmodellen

A

Definieren von Standards für IT-Projekte

  • Projektphasen (z.B. Entwicklung und Test)
  • Projektorganisation (z.B. Rollen und Aktivitäten)
  • Dokumente (z.B. Requirement Spec, Change Request)
  • Kommunikation zwischen Beteiligten
  • Methoden (z.B. für Aufwandschätzung)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Zweck von Vorgehensmodellen

A
  • Erfahrungen aus vergangenen Projekten zusammenfassen
  • Grundstruktur für Projektplanung vorgeben
  • Assessment (Was lief gut/schlecht?)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Wasserfallmodell

A
  • Reihenfolge: Anforderungen, Design, Implementierung, Test, Inbetriebnahme
  • sequentielle Abarbeitung der Phasen
  • am Ende jeder Phase ein Meilenstein
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Vor- / Nachteile Wasserfallmodell

A

Vorteile: schnell für jedermann verständlich, Qualitätskontrolle nach jeder Phase
Nachteile: nicht iterativ, keine Prototypen, Test erst am Ende, Missverständnisse erst spät erkannt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Anwendungsfälle Wasserfallmodell

A
  • klare Anforderungen und keine Änderungen an diesen
  • kleine, kurze Projekte mit wenigen Mitarbeitern
  • IT-interne Anwendung (Anwender sind IT-Experten)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Inkrementell-iterative Methoden

A
  • initiale Erstellung der Kernfunktionalität unter Berücksichtigung der techn. Herausforderungen
  • Ergänzung in Iterationen
  • Zwischenprodukte als Prototyp zum Testen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Vor- / Nachteile inkrementell-iterativer Methoden

A

Vorteil: frühzeitige Fehlererkennung

Nachteil: technisches Design muss Endausbaustufe berücksichtigen, ansonsten Wegwerfaufwand (z.B. Web-Frontend)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Spiralmodell (inkrementell-iterativ)

A
  • 4 Quadranten: Zieldefinition, Risikoabschätzung, Implementierung und Test, Planung des nächsten Zyklus
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Rational Unified Process (RUP)

A
  • Vorgehensmodell für Projekte der objektorientierten Softwareentwicklung, das sich auf UML bezieht
  • Rational macht Vorgehensmodell frei verfügbar
  • RUP sieht aber an vielen Stellen den Einsatz bestimmter Werkzeuge vor
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Best Practices RUP

A
  • Iterative Entwicklung
  • Anforderungsmanagement
  • Komponentenbasierte Architektur
  • Visuelle Modellierung mittels UML
  • Permanente Qualitätskontrolle
  • Management von Änderungen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Vorteile RUP

A
  • frühe und kostengünstige Fehlererkennung
  • Einbindung aktueller softwaretechnischer Methoden
  • geeignet für Entwicklung objektorientierter Software mit Komponentenarchitektur
  • Parallelisierung von Aktivitäten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Nachteile RUP

A
  • komplex, hoher initialer Einarbeitungsaufwand
  • ungeeignet für Hardware und für nicht-objektorientierte Legacy-Erweiterungen und für Standardsoftware
  • angepasst auf Tools von Rational
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Agiles Manifest (4 Prinzipien)

A
  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Grundsätze agiler Vorgehensmodelle

A
  • Strukturierung, Formalisierung, Dokumentation: So wenig wie möglich, so viel wie nötig
  • Vertrauen vor vertraglicher Absicherung
  • kein: allgemeingültigen Regeln: Mensch im Mittelpunkt vor Werkzeugen und Prozessen
  • Flexibles Reagieren auf Änderungen, Kundenzufriedenheit > Einhaltung überholter Ziele
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Extreme Programming (XP)

A
  • bekannteste agile Methode
  • Entwickler und Anwender in einem Raum
  • 40-Stunden-Woche, mehr Arbeit mindert die Produktivität
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

XP: Planning Game

A

Anwender definieren Anforderungen in “Stories”, Entwickler schätzen den Aufwand, beide verhandeln die Reihenfolge der Entwicklung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

XP: Zyklus

A
  • Anforderung, Design, Entwicklung, Test
  • kurze Zeitabstände zwischen Zyklen
  • ständige Verbesserung mit sofortiger Rückmeldung der Anwender
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

XP: Refactoring

A

Codeverbesserungen ohne zusätzliche Funktionalität

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

XP: Entwicklungsstandards

A

keine persönlichen Vorlieben bei der Codegestaltung
-> jeder ist für Gesamtergebnis verantwortlich, man darf Ergänzungen in Programmteilen der anderen vornehmen, wenn sie zur eigenen Aufgabe gehören, aber woanders implementiert werden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

XP: Arbeitsvorgehen

A
  • zwei Programmierer teilen sich einen Arbeitsplatz (einer entwickelt, der andere achtet auf Fehler)
  • ständiges Deployment (Zusammenführen der Arbeitsergebnisse der 2er-Gruppen) um Unverträglichkeiten sofort zu entdecken
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Würdigung des XP

A
  • für kleinere Projekte
  • setzt großes Vertrauensverhältnis voraus
  • Dokumentation fehlt (Entwickler für spätere Pflege)
  • wenige Grundregeln, Projektdurchführung wenig detailliert
  • Elemente aus XP lassen sich in anderen Projekten einsetzen (z.B. Refactoring)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Scrum

A
  • Idee: Prozesse eines Softwareprojektes eh zu komplex, um sie detailliert zu beschreiben
  • gibt groben Rahmen für Projektmanagement vor
  • Projektteam gibt sich Richtlinien selbst und trägt Verantwortung gemeinsam
23
Q

Scrum: Pre-Game-Phase

A
  • Zusammenstellen des Projektteams
  • Einigen auf Standards und Werkzeuge
  • Diskutieren von Vorschlägen für Systemdesign und Bestimmen der Architektur
24
Q

Scrum: Product Owner und Product Backlog

A
  • Product Owner erstellt Product Backlog (enthält alle bisher bekannten Anforderungen und wird ständig weiterentwickelt)
25
Q

Scrum: Game-Phase

A

Produkt wird mehreren Abschnitten (Sprints) erstellt, die ein nachprüfbares Ergebnis haben (Dauer: ca. 1 Monat)

26
Q

Scrum: Sprint Planning Meeting

A

Ziel und dessen Erreichung für nächsten Sprint wird von Product Owner und Projektteam festgelegt

27
Q

Scrum: Sprint Backlog

A
  • wird in jedem Sprint angelegt und gepflegt
  • enthält Ziele für laufenden Sprint aus Product Backlog und ist bezüglich dieser detaillierter
  • Product Owner kann Sprint Backlog nicht ändern (Änderungen kommen erst im nächsten Sprint zu tragen)
  • Team entscheidet selbst, wer welche Punkte aus Sprint Backlog als nächstes bearbeitet
28
Q

Scrum: Daily Scrum

A

Jedes Teammitglied beantwortet in täglichem, kurzen Face-to-Face-Meeting folgende Fragen:

  • Was habe ich seit gestern erreicht?
  • Was will ich bis morgen erreichen?
  • Was blockiert meine Arbeit?
29
Q

Scrum: Burndown Chart

A

Wird täglich gezeichnet und bezieht Restaufwand auf verstrichene Zeit

30
Q

Scrum: Sprint Review Meeting

A
  • Zum Abschluss des Sprints stellt Projektteam dem Product Owner und den Stakeholders seine Ergebnisse vor
  • Entscheidung für Anpassung des Product Backlog und neuer Sprint oder Übergang in Post-Game-Phase
31
Q

Scrum: Post-Game-Phase

A
  • Erstellung der Dokumentation
  • Systemtest (bei Fehlern: Anpassen des Product Backlog und neuer Sprint)
  • User Acceptance Test
32
Q

Scrum: Scrum Master

A
  • überwacht Einhaltung der Scrum-Regeln
  • ist weder Teammitglied noch Teamleiter (Team organisiert sich selbst)
  • Ansprechpartner bei Schwierigkeiten
  • trägt Blockaden aus Daily Scrum in Impediment Backlog ein und beseitigt diese
  • kann Sprint abbrechen, wenn er Ziele für unerreichbar oder Hindernisse für unüberwindbar hält
33
Q

Scrum: Product Owner

A
  • Product Owner kann Product Backlog ändern und priorisiert Einträge
  • kommuniziert mit Kunden und vertritt diese gegenüber dem Team
  • definiert Projektziele anhand von User Stories
  • kommuniziert direkt mit Team
34
Q

Scrum: Projektteam

A
  • schätzt Aufwände für Einträge im Product Backlog

- wählt anhand der Prioritäten des Product Owner aus den Product Backlog-Einträgen die Ziele für nächsten Sprint aus

35
Q

Scrum: Kunden/Stakeholder

A
  • finanzieren das Projekt

- bekommen im Sprint Review Meeting die Ergebnisse des letzten Sprint präsentiert

36
Q

Scrum: Manager

A
  • sind die Vorgesetzten des Teams

- stellen Arbeitsumgebung zur Verfügung

37
Q

Würdigung von Scrum

A
  • strukturiert, aber nicht komplex
  • es gelten Vor- und Nachteile agiler Methoden
  • mildert einige Nachteile agiler Methoden (z.B. Product Owner darf Ziele während des Sprints nicht ändern)
  • mittlerweile sehr verbreitet
38
Q

Continuous Integration

A
  • Extremfall von häufigem Release von Versionen
  • mehrfach täglich neue Versionen
  • Automatisierter Build und Test mittels geeigneter Werkzeuge
  • tägliche neuer Code (commits) zur Integration
  • alle neuen Commits werden in einem Build integriert
39
Q

Vor- / Nachteile Continuous Integration

A

Vorteil: Fehler werden sofort erkannt
Nachteil: durch ständig neue Commits werden stabile letzte Versionen erschwert

40
Q

DevOps: Zielkonflikt

A

agile Projekte wollen häufiges Deployment, Systembetrieb sieht Änderung als Störungsursache (wenige Deployments und müssen getestet werden

41
Q

DevOps: Idee

A

gemeinsame Ziele, Abläufe und Werkzeuge (Goals, Processes, Tools) für Entwicklungsprojekte und Systembetrieb

42
Q

DevOps

A
  • Entwicklungsprojekt und Systembetrieb oft voneinander getrennt
  • DevOps stellt Team für Applikation aus Entwicklern/Testern und Operatoren/Administratoren zusammen
  • unabhängig vom Vorgehensmodell
  • Team ist laufend zuständig für neuen Code und Systembetrieb
43
Q

DevOps: Toolchain

A
  • dauerhafte, permanente Verbindung von Dev und Ops
  • Create, Verify, Package (Graphiken, JAR), Release (Doc und RfC)
  • Configure (Infrastruktur), Monitor, Plan
44
Q

Crystal Family

A
  • farbige Bezeichnung von agilen Softwareentwicklungsmethoden
  • Farbe hängt von Teamgröße und Risikoklasse ab
  • Risiken: Gefährdung Kundenzufriedenheit, Imageschaden, Geldverlust
45
Q

Crystal Family: Prinzipien

A
  • fokussiertes Arbeiten, häufige Releases und Integration, laufende Kritik und Verbesserung, passiver Wissentransfer
46
Q

Crystal Clear

A
  • einfachste Form aus Crystal Family
  • Teamgröße: 2 bis 6 Personen
  • Meilensteine und inkrementelle Auslieferung von Software
  • kein Pair-Programming
47
Q

Software Kanban

A

Methode in der Softwareentwicklung, bei der die Anzahl paralleler Arbeiten, der Work in Progress, begrenzt und somit kürzere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden sollen

48
Q

Feature-driven development (FDD)

A
  • Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung
  • 5 Prozesse: Gesamtmodell entwickeln, Feature-Liste erstellen, Planung je Feature, Entwurf und Programmierung je Feature
49
Q

Test-driven development (TDD)

A

bei der agilen Entwicklung von Software werden Softwaretests konsequent vor den zu testenden Komponenten erstellt
-> qualitative Entwicklung in kurzer Zeit auf Kosten von komplizierten Codeänderungen

50
Q

Rapid Application Development (RAD)

A
  • Softwareentwicklung mit prototypischem Vorgehensmodell (Requirements planning -> User Design/Construction -> Cutover)
  • user-centered und Risikokontrolle, aber schwer skalierbar, komplex, Benutzeranforderungen und modularisierbares System erforderlich
51
Q

Lean Software Development (LSD)

A
  • ähnlich zu agilem Manifest
  • Müll vermeiden, spät entscheiden, früh liefern, das Ganze sehen, Integrität, Verantwortung ans Team, Lernen unterstützen
  • Stärken: Test, Implementierung, Systemdesign
  • Schwächen: Wartung, Requirement- und Projektmanagement
52
Q

Skalierungsmöglichkeiten Scrum

A
  • Large Scale Scrum
  • Nexus
  • Scrum at Scale
  • Safe
53
Q

Disciplined Agile Delivery (DAD)

A
  • Process Decision Framework, das leane und agile Methoden kombiniert
  • Inception Phase, Construction Phase, Transition Phase
  • Ansätze aus Softwareentwicklung (XP, Kanban), Datenmodellierung (Agile Business Intelligence) und Produktentwicklung (SCRUM) werden verbunden

Software Engineering (11 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions