Vorgehensmodelle Flashcards

1
Q

Was ist ein Vorgehensmodell?

A

stellt Methoden und Elemente (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

Wofür sind Vorgehensmodelle die Basis?

A

◼ Projektplanung - Wie komme ich erfahrungsgemäß am besten von Ort X nach Y
◼ Assessment - Bin ich vom geplanten Weg abgekommen?
◼ Performance Analyse - Wie gut laufe ich den geplanten Weg?
◼ Prozessverbesserung - Wie könnte ich durch Bauen neuer Straßen den Verlaufsfluss optimieren?

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

Typen von Vorgehensmodellen

A
  • Stagewise-Modell
    -Wassefallmodell
    -V-Modell
  • Phasenmodell Logistik
    -Hybride Modelle
    -DevOps
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Grundprinzip des “Stagewise-Modells”

A
  • Die einzelnen Phasen sind
    streng sequenziell zu durchlaufen
  • 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
5
Q

Grundprinzip des “Wasserfall-Modells”

A
  • Die einzelnen Phasen sind sequenziell zu durchlaufen
  • Zwischen jeweils zwei aufeinander folgende 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
6
Q

Vorteile des Wasserfallmodells

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
7
Q

Nachteile des Wasserfallmodells

A
  • durch streng Dokumentorientiertes
    Vorgehen Gefahr, dass Dokumente
    wichtiger als Projektziel /-inhalt werden
  • Risiken werden erst in späterer Phase erkannt (keine frühen FeedbackMö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
8
Q

Empfehlung zur Anwendung des Wasserfallmodells

A

Nur einsetzen, wenn am Anfang gleichzeitig alle Anforderungen bekannt sind und sich im Laufe des Projektes nicht ändern (selten der Fall!).
z.B. bei kleinen Projekten oder bei Weiterentwicklungen.

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

Grundprinzip des “V-Modells”

A

Anforderung Systemtests Systemdesign Integrations-
Moduldesign Modultest
Modulkodierung

(Verifikation steigt auf der rechten Seite)

-Im Gegensatz zum Wasserfallmodell, wird verstärkt Wert auf das Thema Qualitätssicherung gelegt. Verifikation meist in diesem Zusammenhang:

-„Geplanter, systematischer Prozess mit dem Ziel sicherzustellen, dass ein Arbeitsprodukt
seinen Anforderungen entspricht.“ D.h. praktisch: Testfälle werden nicht erst in der Hälfte
erstellt!

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

Vorteile des V-Modells

A

+ standardisierte Abwicklung von Projekt zur Systemerstellung
+ Unterstützung von parallelen Aktivitäten(nicht sequentiell)
+ fordert Qualitätsbewusstsein (Definition
Zielqualität, Überprüfung durch QS)
+ detaillierte Darstellung von Systemerstellung, Qualitätssicherung,
Konfigurationsmanagement und
Projektmanagement
+ Vorgabe von definierten Aktivitäten
Rollen, Produkten und Methoden
+ Möglichkeit des „Tailoring“ des Prozesses
auf projektspezifische Erfordernisse

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

Nachteile des V-Modells

A
  • Hohe Komplexität, hohe Kosten bei der
    Einführung
  • bei kleineren und mittleren Projekten;
    unnötige Bürokratie bspw. Dokumentation und
    Vorgehensweise
  • Ohne Case-Unterstützung nur schwer
    handhabbar
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Empfehlung zur Anwendung des V-Modells

A

insbesondere für große Projekte gut geeignet

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

Grundprinzip des “Phasen-Modells Logistik”

A

Projektinitiierung
-Projektplanung
-Ist-Analyse
-Soll-Konzept
-Projektumsetzung
–>Projektabschluss

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

Projektphasen eines Produktionslogistikprojekts + Kurzerklärung

A
  • Projektinitiierung und -planung -> Projektstrukturplan und Projektorganisation
  • Ist-Analyse -> Stärken-/SchwächenProfil
  • Soll-Konzept -> Ausgestaltetes Soll-Konzept
  • Umsetzung und Abschluss -> Realisierung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Family TreeAGILE

A

Agil Workforce (oben)
Agil Organization
Agil Software Development
Lean/Agil Manufacturing (unten)

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

What is complicated? What is complex?

A

Comlicated: dead, machine, permanent, targets, bosses

Complex: alive, humans, temporary, options, social density

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

Aufbau Dilts Pyramide

A

Vision (Warum?) (Oben)
Identität (Wer bin ich?)
Werte/Glaubensansätze (Woran glaube ich?)
Fähigkeiten (Wie wähle ich aus?)
Verhalten (Was mache ich?)
Umgebung (Wo? Wann?) (Unten)

18
Q

Aufgabentypen in Projekten

A

-Dynamisch
-Routine

19
Q

Project Management Process

A

Initiating -> Planning -> Executing -> Monitoring (überwachen)-> Closing

20
Q

Product Development Process

A

Analysis -> Design -> Realization -> Testing -> Roll-out

21
Q

Schlüsselartefakte der agile Programmierung (Scrum-Methode)

A
  • Product Backlog: Ist eine
    geordnete Liste von allem, was
    bekanntlich für das Produkt benötigt wird

-Sprint Backlog: -Ist die Menge der
Product-Backlog-Elementen
die für den Sprint ausgewählt wurden
ein Sprint-Ziel zu verwirklichen.
-Ist ein gut
sichtbares Echtzeit-Bild der
Arbeit, die das Entwicklungsteam
Team plant, die Arbeit
während des Sprints.

  • Das Increment: Ist die Summe aller
    der Product Backlog Elemente
    die während eines Sprints abgeschlossen werden.
22
Q

Schritte der agile Programmierung (Scrum-Methode)

A
  • Sprint Planning (Create Sprint Backlog, identify Sprint Goal)
  • Daily Scrum (Discuss Progress, announce daily commitments…)
  • Sprint Review (Feedback from Stakhoalders)
  • Sprint Retrospective (Team inspect itself and plan for improvements)
23
Q

Vorgehen bei traditionellem Projektmanagement

A

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

24
Q

Vorgehen bei agilem Projektmanagement

A

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

25
Q

Mögliche Kombinationen bei “hybridem” Projektmanagement

A

sequenziell
parallel
integriert

26
Q

Beschreibung der sequenziellen Anwendung

A

• Anwendung verschiedener Modelle nacheinander in zeitlicher Abfolge der Projektphasen
• Klassisches Vorgehen innerhalb der angewandten Modelle

Mögliches Aussehen: Srum-Methode (Konzept- und
Machbarkeitsstudie) kombiniert mit dem V-Modell (Umsetzung) –> Schnittstelle: Anforderungen

27
Q

Vor- und Nachteile der sequenziellen Anwendung

A

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

  • 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

-> In sich geschlossene Teilmodelle
-> Keine Beeinflussung in der laufenden Durchführung
-> Standards als Orientierungshilfe

28
Q

Beschreibung der parallelen Anwendung

A

• Anwendung verschiedener Modelle gleichzeitig, getrennt nach Teilprojekten
• Klassisches Vorgehen innerhalb der angewandten Modelle

Mögliches Aussehen: Wasserfallmodell in Kombination mit der Scrum-Methode –> Schnittstelle: Anforderungen

29
Q

Vor- und Nachteile der parallelen Anwendung

A

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

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

-> In sich geschlossene Teilmodelle
-> Keine direkte Beeinflussung in der Durchführung
-> Standards als Orientierungshilfe
-> Erhöhter Koordinationsbedarf

30
Q

Beschreibung der integrierten Anwendung

A

• Anwendung verschiedener Modelle entlang des Projektlebenszyklus situativ
angemessen
• Modernes Vorgehen innerhalb der angewandten Modelle

Mögliches Aussehen: V-Modell in Kombination mit Kanban

31
Q

Vor- und Nachteile der integrierten Anwendung

A

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

  • 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

-> Kein Vorgehen nach geschlossenen Standards
-> Individualisierung und Optimierung von Modellen
-> Hoher Koordinationsbedarf

32
Q

Probleme und Lösungen bezüglich des Projektmanagements bei Bauprojekten

A

->Probleme:
• Je schwieriger die Umsetzung von Änderungen werden, desto weniger eignet sich ein agiles Vorgehen
• Aber auch die Baubranche ist von der VUKA-Projektwelt betroffen und erfordert angepasste PM-Modelle

-> Lösung: Hybrides PM-Modell: Sequenziell in Form von der Scrum-Methode und dem Wasserfallmodell –> Schnittstelle: Pläne
• Stabilisierung der Anforderungen in der Planungsphase durch agile und iterative Objektmodelle
• Umsetzung von Bestandteilen mit noch volatilen Anforderungen so spät wie möglich

33
Q

Was sind DevOps

A

Ansatz, wie die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb verbessert werden kann.
Durch gemeinsame Anreize, Prozesse und Software-Werkzeuge eine effektivere und effizientere Zusammenarbeit der Bereiche Development, IT-Operations, Qualitätssicherung und Fachbereichen ermöglicht werden.
Die Qualität der Software, die Geschwindigkeit der Entwicklung und der Auslieferung sowie das Miteinander der beteiligten Teams soll so verbessert werden

34
Q

Vorteile von DevOps

A

+ Technisch:
Reduktion der Komplexität durch Kürzung des „Software Development Life Cycles“
+ Kulturell:
Grundsätzlich zufriedenere Mitarbeiter, produktivere Teams und mehr individuelles Engagement

+ Technisch:
Kombination aus „Continuous Delivery“ mit agilen Entwicklungsmethoden

+ Wirtschaftlich:
Schnellere Bereitstellung neuer Funktionalitäten, stabilere Anwendungen, effizientere Prozesse und mehr Innovation (→ schneller auf dem Markt (Wettbewerbsvorteil ))
+ Wirtschaftlich:
Gemeinsamer Nutzen von Entwicklungs-, Test- und Betriebsumgebung führt zu Kostenersparnissen (Cloud-Infrastruktur)

35
Q

Nachteile von DevOps

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

Projektinitiierung und -planung

A

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

37
Q

Ist-Analyse

A

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

38
Q

Soll-Konzept

A

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

39
Q

Umsetzung und Abschluss

A

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

40
Q

Sprint

A

Plan-Build-Review-Test-Deploy

41
Q

Extreme Programmierung

A

-Das Lösen einer Programmieraufgabe rückt in den Vordergrund
-Annahme, dass das mit der Realisierung betraute Entwicklerteam anfangs nicht
über alle Informationen verfügt
-Basiert auf Iterationen - Kunde hat jederzeit die Möglichkeit auf das Projekt
einzuwirken