03 Vorgehensmodelle Flashcards

1
Q

Vorgehensmodell - Definition

A

Ein Vorgehensmodell stellt Methoden und Elemente der Softwareentwicklung inklusive des Projektmanagements zu Prozessen und Projektphasen eines standardisierten Projektablaufs zusammen.

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

Vorgehensmodelle als Basis für

A

Projektplanung
Wie komme ich erfahrungsgemäß am besten von X nach Y

Assessment
Bin ich vom geplanten Weg abgekommen?

Performance Analyse
Wie gut laufe ich den geplanten Weg?

Prozessverbesserung
Wie könnt ich den Verlaufsfluss optimieren?

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

Stagewise Modell

A

o Die einzelnen Phasen sind streng sequentiell zu durchlaufen
o Rückkopplungen und Schleifen zwischen den Phasen sind nicht erlaubt

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

Wasserfallmodell

A

o Zwischen jeweils zwei aufeinanderfolgenden Phasen sind Rückkopplungen erlaubt

-> Höhere Flexibilität, ohne aber kostenintensive Überarbeitung über mehrere Projektphasen zuzulassen

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

Wasserfallmodell - Vorteile

A

Einfach verständlich
Kontrollierbarer Prozessablauf durch Meilensteine und Dokumentation am Ende jeder Phase
Organisatorisch gut beherrschbar
Wenig Managementaufwand

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

Wasserfallmodell - Nachteile

A

Streng Dokumentorientiertes Vorgehen -> Gefahr, dass Dokumente wichtiger als Projektziel/-inhalt werden

Risiken werden erst in späterer Phase erkannt (keine frühen Feedback-Möglichkeiten)

Spätere Veränderung und Detaillierung von Anforderungen bleiben unberücksichtigt

Anwender und Management sehen System erst nach Fertigstellung

Test beginnt erst, wenn Entwicklung abgeschlossen

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

V-Modell

A

Geplanter, systematischer Prozess, mit dem Ziel sicherzustellen, dass ein Arbeitsprodukt seinen Anforderungen entspricht. -> Testfälle werden nicht erst in der Hälfte erstellt

  • Verstärkt Wert auf das Thema Qualitätssicherung gelegt

Schritte (von links nach rechts):
- Anforderungen
- Systemdesign
- Moduldesign
- Modul-Kodierung
- Modultest
- Integrationstest
- Systemtest

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

V-Modell - Vorteile

A

o Detaillierte Darstellung von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement

o Vorgabe von definierten Aktivitäten, Rollen, Produkten und Methoden

o Unterstützung von parallelen Aktivitäten (nicht sequentiell)

o Möglichkeit des „Tailoring“ des Prozesses auf projektspezifische Erfordernisse

o Standardisierte Abwicklung von Projekt- zur Systemerstellung

o Fordert Qualitätsbewusstsein (Definition Zielqualität, Überprüfung durch QS)

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

V-Modell - Nachteile

A

o Hohe Komplexität, hohe Kosten bei der Einführung

o Bei kleineren und mittleren Projekten: unnötige Bürokratie, Dokumentation und Vorgehensweise

o Ohne Case-Unterstützung nur schwer handhabbar

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

Projektphasen eines Produktionslogistikkonzepts

A
  • Projektinitiierung und Planung
  • IST-Analyse
  • SOLL-Konzept
  • Umsetzung und Abschluss
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Projektinitiierung und -planung

A

 Konkretisierung Projektziele
 Festlegung Projektteam
 Entwicklung eines Projektstrukturplans
Zusammensetzung des Projektteams

-> Projektstrukturplan und Projektorganisation

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

IST-Analyse

A

 Durchlaufzeiten
 Flächenbilanz
 Ermittlung logistischer Aufwand
 Darstellung von Material- und Informationsfluss sowie Schnittstellen
 Anlagenverfügbarkeit
 Renner-/ Exoten-Teile
 Typologisierung von Aufträgen

-> Stärken-/Schwächen-Profil

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

SOLL-Konzept

A

 Ermittlung Anforderungen an zukünftige Produktionsstruktur
 Definition Leitlinien für Lean Manufacturing
 Definition Steuerungsprinzipien je Auftragstyp
 Beispielhaftes Line Design (Pilot)
Kennzahlen als Führungsinstrument

-> Ausgestaltetes Soll-Konzept

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

Umsetzung und Abschluss

A

 Definition Umsetzungsplan inkl. Zeitschiene
 Maßnahmen- und Umsetzungscontrolling
 Umsetzungsunterstützung/Coaching

-> Realisierung

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

Agile Programmierung - Dilts Pyramide (oben nach unten)

A
  • Purpose (Why?)
  • Identity (Who am I?)
  • Beliefs/Values (What do I believe in?)
  • Capabilities/Competences (How do I choose?)
  • Behavior (What do I do?)
  • Environment (Where? When? What do I have?)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Das Agile Manifest

A

o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan

17
Q

Scrum - 3 Key Artifacts

A
  • Product Backlog
  • Sprint Backlog
  • Increment
18
Q

Product Backlog

A
  • Ordered list of everything that is known to be needed in the product
  • Prioritized by the product owner
  • The product owner is responsible for the product backlog, including its content, availability, and ordering
19
Q

Sprint Backlog

A
  • Set of product backlog items selected or the sprint realizing a sprint goal
  • Team signs up for work of their own
  • Highly visible, real-time picture of the work that the development team plans to accomplish during the sprint
  • Belongs solely to the development team
20
Q

Increment

A
  • Sum of all the product backlog items completed during a sprint
  • Must be in useable condition regardless of whether the product owner decides to realise it
21
Q

Scrum - 4 events

A
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
22
Q

Sprint Planning

A
  • Create the sprint backlog and identify the sprint goal that the entire scrum team is commiting to over the course of the sprint
  • Attendees: Entire Scrum Team
23
Q

Daily Scrum

A
  • Provide the scrum team an opportunity to discuss progress, announce daily commitments, and identify impediments, which should be cleared by the scrum master
  • Attendees: Scrum Master and Development Team. Product Owner and outside Stakeholders are optional
24
Q

Sprint Review

A
  • Showcase the work completed over the course of the sprint. Gather feedback from the stakeholders to inspect and adapt the product
  • Attendees: Entire Scrum Team plus stakeholders and customers
25
Q

Sprint Retrospective

A
  • Allow the team to inspect itself and plan for improvements in the next sprint
  • Attendees: Scrum Master and the Development Team. Product Owner is optional but recommended
26
Q

Projektmanagement - Traditionelles vs. Agiles Vorgehen

A

Traditionelles Vorgehen:
 Stabile Anforderungen, vorab definiert
 Möglichst wenig Veränderung
 Lieferung eines Gesamtergebnisses am Ende des Projektes
 Stakeholder-Beteiligung zu den Meilensteinen

Agiles Vorgehen:
 Dynamische Anforderungen, häufig verfeinert
 Fortlaufende Anpassungen
 Lieferung häufiger Zwischenergebnisse für Feedback und Kundennutzen
 Fortlaufende Einbindung wesentlicher Stakeholder

Hybrid: Kombination sequenziell, parallel oder integriert

27
Q

Sequentielle Anwendung

A

o Anwendung verschiedener Modelle nacheinander in zeitlicher Abfolge der Projektphasen
o Klassisches Vorgehen innerhalb der angewandten Modelle
o In sich geschlossene Teilmodelle
o Keine Beeinflussung in der laufenden Durchführung
o Standards als Orientierungshilfe

-> Projektphasen mit verschiedenen Voraussetzungen
-> Konzentration auf Erlernen der verschiedenen Vorgehensweisen
-> Einführung neuer Arbeitsweisen als ganzheitliche Modelle

28
Q

Sequentielle Anwendung - Vorteile

A

 Hohe Prozessstabilität
Vereinfachte Abgrenzung von Methoden und Rollen
Keine Überschneidungen verschiedener Modelle

29
Q

Sequentielle Anwendung - Nachteile

A

 Keine Lösung für Phasen mit gleichermaßen traditionellen und agilen Voraussetzungen
 Ggf. Verlängerung der Projektdauer
 Ggf. Konflikte durch unterschiedliche Denk- und Handlungsweisen

30
Q

Parallele Anwendung

A

o Anwendung verschiedener Modelle gleichzeitig, getrennt nach Teilprojekten
o Klassisches Vorgehen innerhalb der angewandten Modelle
o In sich geschlossene Teilmodelle
o Keine direkte Beeinflussung in der Durchführung
o Standards als Orientierungshilfe
o Erhöhter Koordinationsbedarf

-> Teilprojekte mit verschiedenen Voraussetzungen
-> Geübt in Koordination und ggf. Ressourcenmanagement
-> Einführung neuer Arbeitsweisen, aber auch Zusammenarbeit mit anderen Teams

31
Q

Parallele Anwendung - Vorteile

A

 Hohe Prozessstabilität
 Vereinfachte Abgrenzung von Methoden und Rollen
Zusammenarbeit mit anders arbeitenden Organisationsbereichen möglich

32
Q

Parallele Anwendung - Nachteile

A

 Keine Lösung für Teilprojekte mit gleichermaßen traditionellen und agilen Voraussetzungen
 Gefahr von Spannungen im Projektablauf und einem unstimmigen Gesamtergebnis bei mangelhafter Synchronisation
 Ggf. Rollenkonflikte

33
Q

Integrierte Anwendung

A

o Anwendung verschiedener Modelle entlang des Projektlebenszyklus situativ angemessen
o Modernes Vorgehen innerhalb der angewandten Modelle
o Kein Vorgehen nach geschlossenen Standards
o Individualisierung und Optimierung von Modellen
o Hoher Koordinationsbedarf

-> Phasen und Teilprojekte mit durchmischten Anforderungen
-> Grübt in Koordination
-> Erfahren in verschiedenen Arbeitsweisen, aber auch Einführung von nach und nach neuen Elementen

34
Q

Integrierte Anwendung - Vorteile

A

 Umgang gleichermaßen mit traditionellen und agilen Voraussetzungen möglich
 Flexibilität in der Vorgehensweise
 Individuell anpassbar, d.h. maßgeschneiderte Vorgehensweise

35
Q

Integrierte Anwendung - Nachteile

A

 Gefahr von Lücken, Widersprüchen und Inkonsistenzen
 Bei übertriebener Kombination Entstehung von überhöhter Komplexität und Fehleranfälligkeit
 Gefahr von Verlust der Prozessstabilität
 Ggf. Rollenkonflikte

36
Q

DevOps - Vorteile

A

Technisch
 Kombination aus „Continuous Delivery“ mit agilen Entwicklungsmethoden
Reduktion der Komplexität durch Kürzung des „Software Development Life Cycles“

Kulturell:
 Grundsätzlich zufriedenere Mitarbeiter, produktivere Teams und mehr individuelles Engagement

Wirtschaftlich:
Schnellere Bereitstellung neuer Funktionalitäten, stabilere Anwendungen, effizientere Prozesse und mehr Innovation
 Gemeinsamer Nutzen von Entwicklungs-, Test- und Betriebsumgebung führt zu Kostenersparnissen

37
Q

DevOps - Nachteile

A

o Erfordert eine übergreifende Sicht von Programmierern, Testern, Architekten und Service Administratoren (Ops)
o Umstellung auf flache Hierarchien
o Umstellung auf pragmatisches Vorgehen (Bürokratismus bremst agile Methoden)
o Z.T. werden nicht ganz ausgereifte Produkte geliefert, die noch „Continuous Improved“ werden