Software Engineering - Methoden Flashcards
Inhalt: Methoden
V-Modell (4)
(1) Lineares Vorgehensmodell
(2) 10 Phasen: Anforderungsanalyse, Funktionaler Systementwurf, Technischer Systementwurf, Komponenten Spezifikation, Implementierung, Komponententests, Integrationstests, Systemtests, Abnahmetests
(3) Jeder Entwurfsphase ist eine Testphase gegenübergestellt um die Ziele zu validieren.
(4) V-Modell XT erweitert klassische Vorgehensweise durch Iterationen
Wasserfallmodell (3)
(1) Lineares Vorgehensmodell: Nächste Phase erst nach Abschluss von festgelegten Zielen.
(2) 6 Phasen:
- Anforderungsanalyse
- Entwurf/Design
- Implementierung
- Test/Monitoring
- Abnahme/Einführung,
- Wartung
(3) Nachteile: Unflexibel (strenge Reihenfolge), Realitätsfern (Phasen in der Realität nicht klar getrennt), , Anforderungen sind nicht stabil
Agiles Manifest (4)
(1) Leitsätze für Agile (Software-) Entwicklung von 2001
(2) 4 Leitsätze und 12 abgeleitete Prinzipien
(3) Verbessert klassische Vorgehensmodelle durch Flexibilität
(4) Leitsätze:
- 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.
Scrum - Überblick (5)
(1) Agile Methode der Softwareentwicklung
(2) Idee: In kurzen Zyklen releasefähige Software ausliefern (2-4 Wochen)
(3) Ansatz: empirisch, inkrementell, iterativ
(4) Ziel: Kostengünstige Entwicklung hochwertiger Produkte
(5) Bestandteile:
- Rollen: Project-Owner, Scrum-Master, Entwicklungsteam
- Ereignisse: Daily-Scrum, Sprint-Planning, Sprint-Review, Retrospektive
- Artefakte: Product-Backlog, Sprint-Backlog, Product-Inkrement
Scrum - Prozess (7)
(1) Product-Backlog: Enthält priorisierte Anforderungen (items) in Form von User-Stories und wird vom Product-Owner gepflegt.
(2) Sprint-Planning: Entwickler-Team schreibt Anforderungen aus dem Product-Backlog in Form von Tasks ins Sprint-Backlog.
(3) Sprint (2-4 Wochen): Entwickler-Team implementiert Tasks und Scrum-Master sorgt für Abschirmung von Veränderungen und hilft bei nicht fachlichen Problemen.
(4) Daily-Scrum (15 Min/Tag): Entwickler beantwortet drei Fragen –> Was habe ich gestern geschafft? Was schaffe ich heute? Was hilft mir dabei?
(5) Product-Inkrement: Potenziell auslieferbarer Teil der Software.
(6) Sprint-Review: Entwickler-Team und Product-Owner überprüfen ob die Anforderungen aus dem Sprint-Backlog umgesetzt wurden und aktualisieren das Product-Backlog.
(7) Retrospektive: Scrum-Prozess wird überprüft und falls möglich verbessert.
Scrum - Rollen (3)
(1) Product-Owner:
- Verantwortlich für wirtschaftlichen Erfolg des Produkts
- Vertritt Interessen von Stakeholdern
- Pflegt, priorisiert und aktualisiert Product-Backlog (items)
- Erstellt Akzeptanzkriterien “Definition of Done”
(2) Scrum-Master:
- Überwacht den Scrum-Prozess
- Schützt Entwickler-Team vor veränderten Anforderungen während des Sprints
- Mediator bei Meinungsverschiedenheiten
- Beschaffung benötigter Ressourcen
(3) Entwickler-Team:
- Cross-Funktionale Teams von 3-9 Personen
- Gleichberechtigt und selbstorganisiert
- Plant und erstellt Sprint-Backlog mit Tasks für 2-4 Wochen
Sprint - Artefakte (3)
(1) Product-Backlog:
- Enthält ausformulierte Anforderungen “Backlog-Items”
- Wird nur vom Product-Owner gepflegt und priorisiert
- Ist ein lebendes Artefakt und entwickelt sich weiter
(2) Sprint-Backlog:
- Enthält Anforderungen auf Task-Ebene für einen Sprint
- Wird vom Entwickler-Team erstellt und abgearbeitet
- Gibt aktuellen Bearbeitungsstand wieder
(3) Product-Inkrement:
- Muss potenziell auslieferbare Software sein
- Muss die Anforderungen aus dem Product-Backlog erfüllen “Definition of Done”
Kanban (3)
(1) Agile Methode der Softwareentwicklung
(2) Kanban-Board:
- Backlog
- To-Do
- In-Progress
- Testing
- Done
(3) Prinzipien:
- Tasks werden als “Ready” gekennzeichnet
- Pull-Prinzip zum ziehen in die nächste Phase
- Board-Phasen sind mengenmäßig limitiert
- Viele Parallelen zu Scrum (Retrospektive, Definition of Done, Daily-Meeting)
Requirements Engineering (3)
(1) System-Anforderungen:
- ermitteln
- dokumentieren
- prüfen und abstimmen
- verwalten
(2) Anforderungsarten:
- Funktionale
- Nicht-funktionale (Qualitäts-/Akzeptanzkriterien)
(3) Häufige Probleme:
- Steakholder haben unterschiedliche Vorstellungen vom IST- und SOLL-Zustand
- Steakholder können Anforderungen nicht formulieren
- Fachsprache
- Implizietes/unbewusstes Wissen
Kano-Model (4)
(1) Beschreibt Zusammenhang von realisierten Qualitätsanforderungen und Kundenzufriedenheit
(2) Ziel: Kategorisierung von Anforderungen
(3) Koordinatensystem mit zwei Achsen
(4) Kategorien für Anforderungen
- Basismerkmale
- Leistungsmerkmale
- Begeisterungsmerkmale
Aufwandsschätzung - Function Point Methode ()
abc
Aufwandsschätzung - Cocoma Methode (3)
(1) Cocomoa = Constructive Cost Modell
(2) Algorithmisches Schätzverfahren für Kosten und Aufwand
(3) Vorgehensweise:
- Menge an 1.000 Zeilen auszuliefernden Code (KDSI) ermitteln
- Projektkomplexität festlegen: klein (<350 KDSI), mittel (≈350 KDSI), groß >350 KDSI)
- Aufwand und Projektdauer in Personenmonaten berechnen (19 Tage a 8 Std)
Aufwandsschätzung - Delphi Methode (3)
(1) Systematisches, mehrstufiges Schätzverfahren durch Expertenbefragung.
(2) Vorgehensweise:
- Mehrere Experten erhalten Anforderungen und Rahmenbedingungen
- Jeder gibt eine Aufwandsschätzung ab
- Ergebnisse werden anonymisiert offen gelegt
- Einzelne Aufwandsschätzungen werden so lange geändert und offen gelegt, bis ein bestimmter Toleranz-Bereich erreicht wurd
