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
Mögliche Kombinationen bei "hybridem" Projektmanagement
sequenziell parallel integriert
26
Beschreibung der sequenziellen Anwendung
• 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
Vor- und Nachteile der sequenziellen Anwendung
+ 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
Beschreibung der parallelen Anwendung
• 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
Vor- und Nachteile der parallelen Anwendung
+ 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
Beschreibung der integrierten Anwendung
• Anwendung verschiedener Modelle entlang des Projektlebenszyklus situativ angemessen • Modernes Vorgehen innerhalb der angewandten Modelle Mögliches Aussehen: V-Modell in Kombination mit Kanban
31
Vor- und Nachteile der integrierten Anwendung
+ 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
Probleme und Lösungen bezüglich des Projektmanagements bei Bauprojekten
->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
Was sind DevOps
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
Vorteile von DevOps
+ 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
Nachteile von DevOps
- 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
Projektinitiierung und -planung
•Konkretisierung Projektziele •Festlegung Projektteam •Entwicklung eines Projektstrukturplans •Zusammensetzung des Projektteams
37
Ist-Analyse
•Durchlaufzeiten •Flächenbilanz •Ermittlung logistischer Aufwand •Darstellung von Material-und Informationsfluss sowie Schnittstellen •Anlagenverfügbarkeit •Renner-/ Exoten-Teile •Typolog. von Aufträgen
38
Soll-Konzept
•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
Umsetzung und Abschluss
•Definition Umsetzungsplan inkl. Zeitschiene •Maßnahmen-und Umsetzungscontrolling •Umsetzungsunterstützung/ Coaching
40
Sprint
Plan-Build-Review-Test-Deploy
41
Extreme Programmierung
-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