Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
134 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
"Was bezeichnet der Stakeholder Value?"
|
"Nebenbedingung des Shareholder Value: Ausrichtung der Unternehmensführung an der Wertsteigerung des Unternehmens (insb. zugunsten Eigentümer) Zielerfüllung der relevanten Stakeholder (Kunden, Mitarbeiter, Lieferanten etc.) Ziel: Win-Win-Situation"
|
01 Value-based SE
|
|
|
"Welche Defizite gibt es im herkömmlichen SE?"
|
* Stakeholder Value wird ignoriert * Controlling schwierig (Zielerreichung benötigt Ziele) * Artefakten wird der gleiche Wert zugemessen, unabh. ihrer tatsächlichen Bedeutung
|
01 Value-based SE
|
|
|
"Welche Gründe gibt es für das Scheitern von S-Projekten?"
|
* Unvollständige Requirements * Fehlende Benutzereinbeziehung * Mangelnde Ressourcen * Unrealistische Erwartungen * Fehlender Rückhalt im Management * Wechselnde Anforderungen * Mangelnde Planung * Fehlender Bedarf
|
01 Value-based SE
|
|
|
"Welche Methoden existieren, die die Ursachen für das Scheitern beseitigen?"
|
* Benefits Realization Analysis (""Results Chain"") * Abstimmen und Analysieren * Real Options
|
01 Value-based SE
|
|
|
"Was passiert bei der Benefits Realisation Analysis?"
|
Erstellen einer Result Chain Initiative ---(Beitrag)--->Ergebnis ---(Beitrag)--->Ergebnis (Annahme) Beispiel Implementierung Auftragsannahmesystem * leistet: Beschleunigung der Auftragsbearbeitung * führt zu: früherem Lieferzeitpunkt, schnellerer Auftragsausführung Absatzsteigerung, Benutzereinbeziehung, unrealistische Erwartungen, mangelnde Planung und fehlender Bedarf werden gelöst.
|
01 Value-based SE
|
|
|
"Was ist ""Analysieren und Abstimmen""?"
|
Werte und Ziele sind vage und nicht ausformuliert - können durch Befragungen, Prototypen und Showcases erforscht werden. Stakeholder-Konflikte werden im Interaction Room gelöst durch: * Erwartungsmanagement (Bekanntmachung Konfliktfelder) * Visualisierung der Auswirkungen * Prioritätensetzung der SH * Business Case Analyse
|
01 Value-based SE
|
|
|
"Was ist die Real Options Theorie?"
|
Optionen als Finanzmittel: * Das Recht, Geschäfte zu festen Konditionen auszuführen * Frühzeitge Investition * Später vermutlich günstigere Konditionen für ein Geschäft Real Option *Vergleichbare Rechte an realen Gütern *Stochastische Methoden zur Berechnung des Zukünftigen Nutzens
|
01 Value-based SE
|
|
|
Real Options im Software Kontext
|
Vermutliche zukünftige Änderungswünsche werden gesammelt Kosten für Vorbereitung und Durchführung werden berechnet Der Nutzen der sofortigen Investitionen kann durch Methoden der Real Options Theorie geschätzt werden
|
|
|
|
Weitere Anwendungen von Real Options
|
Planungsgrundlage für - Kauf - Verkauf - Bilanzierung Berechnung eines nachvollziehbaren Wertes von Software für juristische Auseinandersetzungen um Nutzungs- Urheber und Patentrechte.
|
|
|
|
Probleme mit dem Wasserfall-Modell
|
Ausgerichtet an den Bedürfnissen des Managements - Klare Phasenenden mit eindeutig zugeordneten Ergebnissen - Klare Verantwortungen für Phasen Fatale Überabstraktion Erweiterung des Modells um Iterationen versucht den Mangel zu beheben. Zwischen initalen und iterierten Aktivitäten wird nicht unterschieden
|
|
|
|
Wasserfallmodell vs. Software Entwicklung
|
Die Trennung der Phasen spiegelt nicht die natur des SE wider. Erkenntnisgetriebene Entwicklung Entwicklung als Aktivität der Klärung von Anforderungen Phasen überlappen zwangsläufig - Reviews beanspruchen Zeit - Dekomposition schafft ab dem Entwurf eine vielzahl von Ergebnissen, die nicht bereitgestellt werden müssen
|
|
|
|
Spiralmodell
|
Kein Lebenszyklusmodell Eher Metamodell eines Lebenszyklus SE ist Iteration von vier Schritten: Ziele, Randbedingungen identifizieren Risiko-Management Entwicklung und Test von Teilergebnissen Planung
|
|
|
|
Vorteile des Spiralmodells
|
regelmäßige Überprüfung Prozessmodell nicht für gesamte Entwicklung festgelegt Integration andere LZM als Spezialfall frühzeitige Fehlereliminierung flexibles Modell Umdirigierung leichter
|
|
|
|
Nachteile des Spiralmodells
|
Hoher Managementaufwand weiniger für kleine Projekte geeignet. Wissen über das Identifizieren von Risiken nicht verbreitet
|
|
|
|
V-Modell
|
Lebenszyklusmodell, das ursprünglich für die SE bei der Bundeswehr Enge Integration von Softwareerstellung,QM,PM, Konfigurationsmanagement
|
|
|
|
Vorteile des V-Modells
|
Integration von SE,KM,QM,PM Identifikation von Rollen und Verantwortungen In der SE: durchgängige Tests Umfassende Abdeckung verschiedener Aspekte
|
|
|
|
Nachteile des V-Modells
|
zu detailliert für ein LZM zu unkonkret für ein Softwareprozessmodell Anwendung nicht immer klar Dokumentenzentriert und komplex
|
|
|
|
V-Modell XT
|
XT = Xtreme Tailoring (individuelle starke Anpassung) 21 Teilbausteine statt 4 Submodelle Bei Bedarf können weitere Bausteine dazukommen Abhängigkeiten zwischen Bausteinen
|
|
|
|
Bausteine des V-Modell XT (Dömanen)
|
Projekt-,Qualitätssicherung, Konfigurations-, Änderungs-, kfm Projekt-, Messung und Analyse,
|
|
|
|
Bausteine des V-Modell XT (Aktivitäten)
|
Anforderungserstellung Systemerstellung HW/SW-Entwicklung Logistikkonzeption Weiterentwicklung Evaluierung von Fertigprodukten Benutzbarkeit Systemsicherheit Multi-PM Lieferung und Abgabe (AG/AN) Vertragsschluss (AG/AN)
|
|
|
|
Vorteile V-Modell XT
|
Integration der Kernbausteine Weitere Definierte Vorgehensweise Identifikation von Rollen und Verantwortungen In der SE: durchgängige Tests Umfassende Abdeckung verschiedener Aspekte sehr flexibel
|
|
|
|
Nachteile V-Modell XT
|
Anwendung? dokumentenzentriert und komplex wird als starr wahrgenommen Tailoring erfordert großes Wissen und Verständnis
|
|
|
|
Vorgehen beim Rational Unified Process
|
Anwendungsfallgetrieben - Nutzer identifizzieren und AF als weitere Grundlage Iterativ und inkrementell - Schrittweise Teile entwerfen, entwickeln und Testen. - Erhöhung der Qualität in jedem Schritt Architekturzentriert - Architektur wird parallel beschrieben - Früherkennun von Technische Implikationenen
|
|
|
|
RUP-Phasen
|
1. Inception (Beginn) 2. Elaboration (Ausarbeitung) 3. Construction 4. Transition (Umsetzung)
|
|
|
|
RUP-Tätigkeiten
|
Jede Phase besteht aus mehreren Iterationen Es gibt Tätigkeiten mit unterschiedlicher Gewichtung Es gibt Tätigkeiten die alle Phasen begleiten (PM)
|
|
|
|
RUP Phase 1
|
Kick-Off Meeting Infrastruktur aufbauen Systemfokus festlegen Anforderungen aufnehmen Entwurf einer Architektur Bewertung des Projekts
|
|
|
|
RUP Phase 2
|
Analyse durchführen Analysemodell erstellen Entwicklung eines Analyseprototyps Implementierung des Architekturkerns Projektplan für Entwurf Erste Version des Handbuchs
|
|
|
|
RUP Phase 3
|
Entwicklung und Test der Klassen und Komponenten zunehmende Integration des Systems Vorbereitung der Zielumgebung Erstellung von Schulungsunterlagen
|
|
|
|
RUP Phase 4
|
Fertigstellung des Produkts Abschließende Tests uns Qualitätskontrollen Installation und Integration beim Kunden Anwenderschulung Formelle Abnahme
|
|
|
|
RUP vs. Wasserfall
|
Beide haben sequentiell beginnende Phasen Zum Phasenende liegen Dokumente vor Unfertige Dokumente werden explitzit benannt und eine Verfeinerung gefordert Tätigkeiten sind nicht einer Phase zugeordnet
|
|
|
|
RUP Tailoring
|
Für ein Projekt wird der allgemeine RUP angepasst Teamgröße kann sich auf Projektplanung auswirken
|
|
|
|
RUP Best practises Architektur Iterativ Prototypisch Visuell
|
1. Konzentration auf kritische Anwendungsfälle vor der Implementierung Gemeinsamer Entwurf von Architektur und Projektplan 2. Jede Iteration konzentriert sich auf ein Risiko 3. Frühzeitige Akzeptanzprüfung von Zwischenergebnissen Schnelle Identifikation von Performanceproblemen 4. Leichtere Modellierung und Doku
|
|
|
|
RUP Best Practises Komponenten Round-Trip Change-Management Qualitätskontrolle
|
1. Minimierung des Codes Automatische Generierung von Fragmenten Nutzung von Standardkomponenten,COTS 2. Modellierungstools erlauben, Kopplung von code und Modell 3. Automatisierung von Änderungsprozessen 4. Autmatische Fortschrittskontrolle durch automatische Metriken
|
|
|
|
Vorteile RUP
|
Risikoreduzierung durch Iteration Anpassung durch geänderte Anforderungen Definiert Vorgehen für UML-Diagramme Identifikation von Rollen und Verantwortungen Planung erlaubt Koordiantion von großen Teams
|
|
|
|
Nachteile RUP
|
Nicht alle Aspekte der UML sind definiert Wird als starr wahrgenommen Tailoring ist aufwändig
|
|
|
|
Phaseorientierung vs. Outtasking
|
Übergabepunkte müssen klar definiert und Quality gates haben Ausgelagerter Teil = Black Box Beim Tailoring ist festzulegen ob Rolle intern oder extern ist Verfügbarkeit ist sicherzustellen Kommunikationsmöglichkeiten müssen bestehen Kontinuierliche Übergänge als Fortschritt
|
|
|
|
Modellgetriebene Entwicklung
|
Anwendungswissen über Modelle ausdrücken Modelle als DER Fokus Unabhängig von konkreter Infrastruktur Sicherstellung einheitlicher Architektur und Struktur Verhinderung der Degeneration der Systemstruktur Vermeidung von Portierungen
|
|
|
|
Model Driven Architecture (MDA)
|
Anwendung im Mittelpunkt Trennung von Anwendungslogik und technischer Plattform Modellierung als Platform Independent Model (PIM) Transformation in Platform Specific Model (PSM)
|
|
|
|
MDA Vorgehen
|
PIM Erstellen Plattform auswählen Transformation PIM -> PSM Code Generierung
|
|
|
|
Anwendbarkeit von MDA
|
Langlebige Software Variantenreichtum Einfache Businesslogik Technik-unaffine Fachexperten Großes Gesamtteam
|
|
|
|
Gefahren von MDA
|
Unhandhabbarkeit durch Modelle Fachwissen wird Vergraben Werkzeugterror "Unwohlsein" bei Entwicklern Verschüttete Architektur
|
|
|
|
Anwendbarkeit von MDA
|
Langlebige Software Variantenreichtum Einfache Businesslogik Technik-unaffine Fachexperten Großes Gesamtteam
|
|
|
|
Gefahren von MDA
|
Unhandhabbarkeit durch Modelle Fachwissen wird Vergraben Werkzeugterror "Unwohlsein" bei Entwicklern Verschüttete Architektur
|
|
|
|
"Gründe für Einführung von inkrementeller Entwicklung"
|
"Prüfung: Requirements/Spezifikationen passend zu Unternehmenszielen? Problem: Betriebsblindheit der Projektteilnehmer durch Spezifikation * durch Experten - Verfügbarkeit, Kosten, ""Notwendigkeit"" Fehler zu finden * durch phasenorientierte Implementierung - Ergebnisse erst nach langer Zeit sichtbar, teure Fehlversuche, Requirements Drift während Entwicklung unberücksichtigt Lösung: Prüfung durch inkrementelle Entwicklung"
|
""
|
|
|
"Wie funktioniert Scrum im allgemeinen?"
|
"Aus dem **Product Backlog** werden User Stories für den **Sprint Backlog** ausgewählt. Diese werden in einem **Sprint** realisiert. Zusätzlich gibt es täglich ein 15-minütiges **Daily Scrum**. Nach jedem **Sprint** gibt es eine Retrospektive, in der der letzte Sprint betrachtet wird, um daraus Erkenntnisse für den nächsten Sprint zu gewinnen. Am Ende eines jeden Sprints steht ein Stück lauffähige Software."
|
""
|
|
|
"Wie funktioniert die Entwicklung bei Scrum?"
|
"Aus dem **Sprint Backlog** werden User Stories in konkrete Tasks ausgeführt, die dann umgesetzt werden. Am sogenannten **Planning Board** kann jederzeit jeder Entwickler einsehen, welche Aufgaben zugeteilt, in Bearbeitung oder abgeschlossen sind."
|
""
|
|
|
"Woraus besteht ein Daily Scrum?"
|
* Was habe ich seit dem letzten DS getan? * Was werde ich bis zum nächsten DS tun? * Was behindert mich? * 15 Minuten, stehend, freihändig, fester Zeitpunkt * keine Diskussion * vom Scrum Master geleitet "
|
""
|
|
|
"Woraus bestehen Review und Retrospektive am Ende eines Sprints?"
|
"**Review** * Vorführung Ergebnis des Sprints (lauffähige Software) * Prüfung durch Kunden * Änderungen im Product Backlog dokumentieren * Unerledigte Anforderungen zurück ins PB **Retrospektive** * Feedback zum Prozess (nicht zum Produkt) * wichtige Ereignisse während des Sprints notieren -> Gruppierung und Bewertung (gut/schlecht) * Lösung für bessere Organisation entwickeln
|
|
|
|
"Was ist eine User Story?"
|
"Karte (ursprünglich Papier), die ein Feature der Software darstellt. Inhalt: Titel, [Nummer], Beschreibung, Ansprechpartner, [Priorität][Schätzung] Umfang: Gerade so detailliert, dass Schätzung möglich ist Schema der Beschreibung: <Aktion>
|
|
|
|
"Was ist ein Use Case?"
|
"Diagrammtyp aus der UML. High-Level-Beschreibung eines einzelnen Systems aus Nutzersicht * Welche Funktionen bietet das System seinen Nutzern und Nachbarsystemen? * Wie unterstützt das System die Geschäftsprozesse? Keine Implementierungsdetails oder detaillierten Datenflüsse! "
|
""
|
|
|
"Welchen Nachteil hat ein Festpreisprojekt?"
|
* Kunde will Festpreis, weiß aber nicht genau, was das fertige Produkt genau können soll * Erstmal wird spezifiziert, eine vollständige Spezifikation ist weder sinnvoll noch wirtschaftlich * Entweder ist Festpreis-Dienstleister unglücklich oder kassiert mit Change Requests ab -> keine nachhaltige Kundenbeziehung
|
|
|
|
"Wie können Festpreisprojekte um agile Methoden erweitert werden?"
|
* Initiale Benennung von Anforderungen als User Stories (daraufhin double blind Budget-Schätzung) * Für jeden Sprint relevante Features werden detaillierter beschrieben * Ergebnis: Frühe lauffähige, aber nicht vollständige Version
|
""
|
|
|
"Welche Regeln gelten für einen Sprint?"
|
* Fixer Umfang * Umpriorisierung zwischen Sprints möglich, auch neue Anforderungen * Fortlaufende Kontrolle über die Projektziele auf Seiten des Kunden
|
""
|
|
|
"Inwiefern findet sich der Festpreis in agiler Vorgehensweise wider?"
|
* Aus Schätzung der User Stories einzeln, des Zielbudgets und des Zieltermins wird priorisiert und aufsummiert -> kein fester Preis, aber Orientierungspunkt * Orientierungspunkte (Aufwandssumme und Zieltermin) konstant transparent gemacht * Änderung von User Stories immer mit Blick auf OP ->
|
|
|
|
"Inwieweit ist die Wertorientierung berücksichtigt?"
|
* Nutzen einer SW ergibt sich aus Aufwänden für Entwicklung/Betrieb & qualitativen Veränderungen in Geschäftsprozessen * User Stories erzwingen zielgerichtete Auseinandersetzung (einzelne überschaubare Teilprozesse) * Ständige Priorisierung bewirkt konstante Ausrichtung am Nutzen * Durch Risikoverteilung wird auch Dienstleister am Nutzen ausgerichtet
|
""
|
|
|
"Welche Besonderheiten umfasst die ""kommerzielle agile Entwicklung""?"
|
* Niedrig priorisierte Req. werden spät spezifiziert und vllt. weggelassen (-> kein unnötige Spezifikationsaufwand) * Jederzeit neue Stories möglich * Kunde kann jederzeit aussteigen, wenn zufrieden * Schlanke Lösung für Dienstleister * Vertrauensvoller Umgang zwischen Kunde/Dienstleister notwendig * Einigkeit über gemeinsame Risiken * Wirtschaftliches Risiko wird verteilt
|
|
|
|
"Wie kann das agile Vorgehen abgerechnet werden?"
|
* Am Ende jeder Iteration * Abnahme pro User Story (qualitätsgerecht geliefert?) * Normaler Tagessatz innerhalb von Schätzung, niedrigerer Tagessatz für Fehlerbehebung, Overspend * Feste Deadline pro Sprint * Grundpauschale für ständige, administrative Tätigkeiten * Abbruch nach jeder Iteration möglich oder Definition von nächster Iteration
|
""
|
|
|
"Was muss man bei Schätzungen beachten?"
|
* Gefühlte Sicherheit deutlich höher als tatsächliche (kein ""bin mir zu 90% sicher"") * Keine Spontanschätzungen, da immer geraten - besser diskutieren * Bewusste Bandbreite wählen, die Unsicherheit widerspiegelt
|
""
|
|
|
"Was bedeuten Ziel, Schätzung, Zusage und Plan?"
|
* Ziel: Fixwert durch externe Faktoren (Budget, Deadline, ...) * Schätzung: Vorläufige Vorhersage eines künftigen Wertes/Wertebereichs * Zusage: Festlegung auf einen künftigen Fixwert * Plan: Vorgehensvereinbarung, um Zusage zu erreichen
|
""
|
|
|
"Unter- oder Überschätzung? Was ist besser und wie ist die Realität?"
|
"Überschätzung besser, da Mehraufwand ... * niedriger als bei Unterschätzung * durch erforderliche Arbeit begrenzt * durch Projektmanagement handhabbar Problem in Realität: Schätzungen meistens 20-30% zu optimistisch * Übersehene funktionale und nicht-funktionale Anforderungen * Übersehene Entwicklungsaktitvitäten (Einarbeitung, Konfigurationsmanagement, ...) * Übersehene andere Aktivitäten (Urlaub, Krankheit, ...)
|
""
|
|
|
"Inwiefern lässt sich ein Projektplan verkürzen?"
|
"Ohne Weglassen von Features nicht. Verkürzung (d.h. Erhöhung der Teamgröße) steigert den Aufwand, aufgrund von * höherem Einarbeitungs-/Koordinationsaufwand * größerem Potential von Missverständnissen * zu wenig parallelisierbare Aufgaben Verlängerung (d.h. Reduzierung Teamgröße) sehr wohl möglich: * geringerer Kommunikationsaufwand * stärkere Sequenzialisierung ->frühere Fehlererkennung ->
|
|
|
|
"Welche Vorteile bieten genaue Schätzungen?"
|
* Referenzwerte * höhere Qualität durch weniger Stress * bessere Kooperation mit Plänen anderer Geschäftsbereiche * finanzielle Sicherheit * kompetenteres Image der Entwickler * frühe Risikowarnung bei Divergenz Ziel<
|
->
|
|
|
"Welche Unsicherheiten gibt es?"
|
* Unscharfe Infos über Projekt * Unscharfe Infos über Fähigkeiten der ausführenden Personen * Ständige Veränderung (Ziele, Rahmenbedingungen, Stakeholder, ...) * in der Methodik begründete Unschärfen
|
""
|
|
|
"Was ist der Cone of Uncertainty?"
|
"Besagt die Schwankung der Schätzung während des Projektverlaufs. Diese ist anfangs sehr groß (zwischen 25-400%) und wird über die vollständigen Anforderungen (67%-150%) bis zum detaillierten Design (90%-110%) immer schmaler. Dies allerdings nicht von alleine, Quellen der Unsicherheit müssen aktiv beseitigt werden."
|
""
|
|
|
"Wie wird mit Unsicherheit in agilen Projekten umgegangen?"
|
* Regelmäßige Überprüfungen der Richtung * Anfangs großer Entscheidungsspielraum, der nach und nach eingeschränkt wird * Unschärfe wird im Projektverlauf verringert
|
""
|
|
|
"Welche Unterschiede bestehen zwischen phasenorientierer und agiler Herangehensweise bzgl. Schätzung/Zeitplanung?"
|
"Bei traditioneller Herangehensweise sind Features festgelegt, der Aufwand der Phase wird geschätzt und ein Zeitplan festgelegt. Bei agiler Heransgehensweise hingegen wird der Zeitplan festgelegt, dann der Aufwand der Features geschätzt und somit der Inhalt des nächsten Zeitabschnitts festgelegt."
|
""
|
|
|
"Wie ist die grundsätzliche Vorgehensweise beim Feature Driven Development (FDD)?"
|
"Über eine Zeit von max. 6 Monaten wird in den //ersten 2-3 Wochen// zunächst *ein Gesamt-Modell erstellt, *daraus eine Feature-Liste, * daraus ein Plan je Feature. Jedes Feature wird dann in //je zwei Wochen// entworfen und entwickelt. FDD ist geeignet für eine Teamgröße von 10-50 Personen."
|
""
|
|
|
"Welche Feedbackschleifen existieren in agilen Methoden und welche Fragen beantworten sie?"
|
"{ * **Sprint, Daily Scrum:** Entwickeln wir die richtigen Dinge? * **CI, Unit Testing, Pair Programming:** Entwickeln wir Dinge richtig? * **Planning Board:** Durchschnittlicher Durchsatz und Flaschenhälse }"
|
""
|
|
|
"Was sind die 5 zentralen Werte des XP?"
|
* Kommunikation: Ständiger Austausch, Akzeptanz unterschiedlicher Meinungen * Einfachheit: einfachste Lösung wird realisiert * Feedback: durch (1) gibt es Feedback zu Fortschritt und Akzeptanz der Ergebnisse * Mut: offene Kommunikation erfordert Mut, explizite Benennung eines ""Sprechers"" der alle ""Beschwerden"" weitergibt * Respekt: auch Nicht-Experten kommen zu Wort, unterschiedliche Meinungen werden akzeptiert
|
""
|
|
|
"Welche Prinzipien gibt es beim XP?"
|
* Menschlichkeit * Wirtschaftlichkeit * Beidseitiger Vorteil * Selbstgleichheit * Verbesserungen * Vielfältigkeit * Reflexion * Lauffähigkeit & kontinuierlicher Projektfortschritt * Gelegenheiten wahrnehmen * Redundanzen vermeiden * Fehlschläge hinnehmen * Qualität * Kleine Schritte * Akzeptierte Verantwortung
|
""
|
|
|
"Welchen Zweck erfüllen die XP-Praktiken?"
|
* Konkrete Maßnahmen aus Werten und Prinzipien abgeleitet * ""Best Practices"" * kein Allheilmittel, müssen angepasst werden * sind nicht notwendigerweise neu * scheinen trivial und werden unterschätzt * einige gehören mittlerweile zum ""guten Ton"", nicht nur in XP-Projekten Beispiel: TDD, einfaches Design, CI, kleine Iterationen"
|
""
|
|
|
"Wie ist das grundsätzliche Vorgehen bei Test-driven Development (TDD)?"
|
* Testfall erstellen * Testfall schlägt fehl * Feature programmieren * alle Testfälle erfolgreiche * Refactoring * Testfälle bleiben erfolgreich * s. (1)
|
""
|
|
|
"Was ist Test-driven Development im Allgemeinen?"
|
* 2003 von Kent Beck entwickelt * Grundkonzept aus XP * Testfälle als ausführbarer Code * Möglichst kleine Verbesserungen sind Teil jedes Tests * Testfall wird minimal gelöst * Keine Funktionalität ohne Testfall
|
""
|
|
|
"Wie sind Testfälle organisiert?"
|
"In Cases und Suites. * Pro Applikationsklasse eine Testklasse * Unterschiedliche Fixtures: Aufteilung nach gemeinsamer Fixture-Nutzung * Tests von mehreren A-Klassen werden ausgelagert in eigene T-Klassen Testklassen werden in Suites gruppiert (pro Package eine Testsuite), diese wiederum in eine übergeordnete Suite."
|
""
|
|
|
"Welche Granularität ist für Testfälle empfehlenswert?"
|
* Es werden nur public-Methoden getestet. Nichts was funktionieren ""muss"" wird getestet, bspw. Getter/Setter. * Es wird nur Funktionalität getestet, nicht explizit nach Methoden (nicht notwendigerweise disjunkt). * Es werden typische Situationen getestet, sowie orthogonal (d.h. andere Tests werden als korrekt vorausgesetzt)
|
""
|
|
|
"Was muss man bei Testfällen für verteilte Systeme beachten?"
|
* Laufzeitumgebung zur Entwicklungszeit unbekannt * Verhalten von Nachbarsystemen unsicher * Verhalten der Infrastruktur unsicher * Komplexe Abhängigkeiten schlecht für Unit Testing
|
""
|
|
|
"Was muss man bei Testfällen für mobile Systeme beachten?"
|
* Kontext um Größenordnungen komplexer * Sprunghafte Kontextveränderungen * Unzuverlässige Emulatoren * Automatisierung schwierig
|
""
|
|
|
"Was beschreibt das Organizational Pattern?"
|
"?????"
|
""
|
|
|
Steigende Software Komplexität
|
Technologischer Fortschritt - Nachfolger schnell vorhanden Steigende Flexibilitätsanforderungen - Dezentrale Anwendungen mit externen Diensten laufen in der Cloud Diversifikation der Fachlichkeit - Technologie nicht kriegsentscheidend Migrationsaufwand - Datenbestand muss übernommen werden Integrationsaufwand - Anwendungen müssen integriert werden
|
|
|
|
Komplexitätstreiber Migration und Integration
|
IT Systeme werden nicht auf der grünen Wiese entwickelt Altsysteme werden abgelöst Daten müssen übernommen werden, liegen aber ggf. in unbrauchbarer Struktur vor Neuentwicklung muss sich integrieren, auch wenn Schnittstellen veraltet sind.
|
|
|
|
Übliche Lösungsansätze zur Komplexität
|
Modellgetriebene Entwicklung - Möglichst detaillierte, vollständige, unmissverständliche Spezifikation aller Systemdetails vor Implementierung Agile Entwicklung - Iterativ-inkrementelle Implementierung von Systemkomponenten in kurzen Releasezyklen - Korrektur, Verfeinerung und Erweiterung in enger Abstimmung mit Kunden
|
|
|
|
Dilemma bestehender Ansätze zur Lösung der Softwarekomplexität
|
Traditionelle dokumentenzentrierte Techniken,fördern die Kommunikation nicht Agile Ansätze fördern Kommunikation und Interaktion liefern aber kein operationelles Vorgehen Individuelle Hintergründe, unterschiedliche Kulturen und Erfahrung werden außer Acht gelassen
|
|
|
|
Warum ist es ein Problem wenn kein gemeinsames Projektverständnis vorhanden ist.
|
Fach und IT Experten sprechen oft keine gemeinsame Sprache Technisce Details schnell im Vordergrund Komplizierte Modelle werden erstellt Missverständnisse, Fehler Mangelnde Akzeptanz für interdisziplinäre Probleme Gemeinsame Vision in Gefahr
|
|
|
|
Wie kann das Big-Picture und das gemeinsame Verständnis im Auge behalten werden
|
Viele Modelle, Dokumente, Fortschrittsberichte an vielen Orten Fachliche Zusammenhänge sind für das Problemverständnis besser als spezifizierte Details Überblick behalten durch Betrachtung aller relevanten Aspekte, Fortschritte und Probleme
|
|
|
|
Was sind versteckte Unsicherheiten in der Spezifikation
|
Ein gewisses Maß an Unsicherheit ist normal bspw durch mangelnde Detailkenntnis der Domäne und unvollständige Aussagen der Stakeholder Unsicherheit kann maskiert werden durch einfaches weglassen unsicherer Bereiche oder Annahmen des Spezifizierers als Informed Outsider (WTF?) Lücken in der Spezifikation tritt erst spät auf
|
|
|
|
Was bedeutet die Vernachlässigung von Wert und Aufwandstreibern
|
Gut verstandene Elemente werden bis ins kleine Detail spezifiziert, dabei weniger trivial als schlechter verstandene Leichtere Erzeugung von voluminösen Spezifikationen Aufmerksamkeit wird nicht auf die kritischen Wert und Aufwandstreiber gelenkt Falsche Wahrnehmung des Fortschritts Kritische Artefakte werden erst angegangen wenn Budget und Zeit knapp ist.
|
|
|
|
Wie sinkt die Awareness für den Aufwand
|
Inkrementelle Verfeinerung und Weiterentwicklung ist ein zentrales Konzept agiler Methoden Manche Artefakte unterliegen ständiger Veränderung und werden durch Veränderungen von Anforderungen und individuellen Stakeholderwünschen getrieben. Aufwand bleibt in komplexen Projekten oft unbemerkt
|
|
|
|
Philosophie des Interaction Room
|
Wertortientierung - Was ist wichtig? Modellierung des Gesamtüberblicks - Punktuelle Verfeinerung nur dort, wo zum Verständnis erforderlich - Kein ausmodellieren von Trivialitäten, was unnötigen Aufeand generiert Dynamische Modellanpassung an den Projektfortschritt - Fertige Komponenten ggü Baustellen auf einen Blick erkennbar
|
|
|
|
Beschreibung des Interaction Room
|
Ort des gemeinsamen Verständnisses von Projektziel und Fortschritt Ort zur Kommunikation Ort zu Identifikation notwendiger Interaktion Ort der inhaltlichen Auseinadersetzung in agilen Prozessen Nicht elektronisch, formal oder vollständig
|
|
|
|
Beschreibung des Product/Sprint Backlog
|
Informelle Notation der Anfroderungen des Kunden durch User Stories - Kunde kann Anforderungen in seiner Sprache formulieren Funktionale AF in Form von User Stores lassen sich auf die dynamische Sicht eines IT-Systems abbilden. Reine Auflistung einfacher als Prozessdenken
|
|
|
|
Beschreibung der annotierte nGeschäftsprozessmodelle
|
Darstellung der dynamischen Struktur des Systems Modellierung auf unterschiedlichen Abstraktionsebenen - triviale Teilprozesse werden nur abstrakt dargestellt - Gegenstand der Betrachtung ist detailliert modelliert - Bereits umgesetzte Teilprozesse sind zugeklappt und überklebt Aufwands- und Werttreiber werden durch Annotationen gekennzeichnet
|
|
|
|
Beschreibung der Fachlichen annotierte Objektmodelle (FAO)
|
FAO bilden Datenbasis des Systems Grundlage des Zielbildes der staitischen Systemaspekte Modellierung der Entitäten und grundsätzlichen Beziehungen - keine Beziehungen - keine Kardinalitäten - keine Attribute Sukzessive Weiterentwicklung und relationierung zum bestehenden Datenmodell
|
|
|
|
Beschreibung der Migrationslandkarte
|
Häfuiges Problem ist die Herkunft der Daten Die Struktur des Bestehenden Datenmodells muss nicht mit der des neuen Modells übereinstimmen Dem bestehenden Modell wird das neue gegenübergestellt. Was wird übernommen, was transformiert,was belassen, was ignoriert, was ergänzt.
|
|
|
|
Beschreibung der Integrationsszenarien
|
Integrationsanforderungen verständlich machen Integrationsaufwände explizit machen Darstellung der direkten Nachbarn in der IT-Landschaft Abbildung von Schnittstellen,ausgetauschten Daten,Kommunikationsbedingungen, Sicherheitsaspekten
|
|
|
|
Ziele des Interaction Rooms
|
Überblickswissen und gemeinsames Problemverständnis schaffen Erwartete Probleme und Komplexität hervorheben und managen Unsicherheit explizit machen & reduzieren Fortschrittskontrolle und Implementierungsprobleme verdeutlichen
|
|
|
|
Bestandteile von Scrum
|
Rollen Artefakte Meeting Prinzipien,Kultur,Wert
|
|
|
|
Rollen in Scrum
|
Scrum Team: Product Owner, Team, Scrum Master, Nebenrollen
|
|
|
|
Artefakte in Scrum
|
Vision, User Stories und deren Tasks Product Backlog, Sprint Backlog, Technical Backlog Burndown Charts Fertige Produktkremente
|
|
|
|
Meetings in Scrum
|
Sprint Planning, Daily Scrum, Sprint Review, Sprint Restrospektive Schätzklausuren
|
|
|
|
Prinzipien Kulturen und Werte in Scrum
|
Kontinuierliches Beobachten und Anpassen Timeboxing Feedback, Selbstorganisation, Dinge abschließen Respekt, Vertrauen, Offenheit, Ehrlichkeit, Verpflichtung, Courage
|
|
|
|
Wie passt der IR in Scrum
|
Scrum gibt einen Orgarahmen vor - Reihenfolge und Rollen in der Phasen durchlaufen werden - Welche Regeln wurden auf grund welcher Prinzipien entwickelt Scrum bietet keine methodische Unterstützung für die effektive Inhaltliche auseinandersetzung
|
|
|
|
Ideale Arbeitsumgebung nach Wirdemann
|
Seperater Teamraum mit Beamer und Whiteboards Treffpunkt für Daily Scrum, Retrospektive und zum öffentliche Sprint review
|
|
|
|
Was kann der IR besser als Wirdemanns Umgebung
|
Verbindung von Anforderung und Design Sprint Planning Meetings zum Erstellen des Designs und der umzusetzenden Artefakte im Gesamtkontext Interaktion der Rollen im IR Die wichtigsten Besandteile nach Wirdemann müssen sich aber wiederfinden
|
|
|
|
User Stories im IR
|
User Stories erweitern den IR um eine weitere Sicht (Wand) User Stories finden sich im Geschäftsprozess wider Aufwandsschätzung und Priorisierung durch Modelle, Annotationen, Unsicherheitsdarstellung und Expertenschätzung
|
|
|
|
Sprint Plannung im IR
|
Meeting 1: Erstellung des SBL durch Anordnung der US im PBL & Ablesen von Komplexitäts und Aufwandstreibern aus den annotierten Modellen Meeting 2: Jede US wird unter ständiger Berücksichtigung des Gesamtsystems in die Architektur eingebttet Funktionalität die im Sprint umgesetzt werden soll, wird an Wänden verfeinert Konkrete Aufgaben an Hand von verfeinerten artefakten
|
|
|
|
Sprint Durchführung im IR
|
Ruckzugsraum für Designmeetings Fachliche Diskussion zwischen PO und Team
|
|
|
|
Daily Scrum (IR)
|
Was habe ich gestern getan? Was werde ich heute tun? Was steht mir im Weg? Visualisierung an Hand der Modelle Update des Burndown-Charts auf Konferenzstisch
|
|
|
|
Spring Review und Retrospektive im IR
|
Sprint ergebnisse durch Ausdruck im IR manifestieren - Teil von Definition and done - Ergebnisse können Reports , UI Screenshots oder Detail modelle sein Live Demo Retrospektive zur identifikation von Problemen
|
|
|
|
User Stories (IR)
|
Vorderseite: Rolle,Ziel,Nutzen der Zielerreichung,Wichtigkeit für den Kunden, ID Rückseite: Akzeptanzkriterium
|
|
|
|
Beschreibung der User Stories (IR)
|
Beschrieben funktionale Anforderungen aus Rollensicht Haben Mehrwert für Endanwender Sind Platzhalter für detaillierte AF
|
|
|
|
Best Practises für User Stores (IR)
|
Qualitätsanforderungen als Teil der US Keine Randbedingungen Schema F: "Als <Rolle> will ich <das Ziel> erreichen [so dass <Grund für das Ziel>
|
|
|
|
Eigenschaften guter User Stories (IR)
|
US formulieren Anforderungen keine Lösungen US beschreiben keine Technik US beschreiben keine UIs US sind in der Sprache des Kunden zu formulieren US repräsentieren Ziele von verschiedenen Rollen
|
|
|
|
INVEST Modell für User Stories (IR)
|
I - Independent - unhabhängig N - Negotiable - verhandelbar V - valueable - wertvoll E - estmatable - schätzbar S - small -- klein T - testable - testbar
|
|
|
|
Evolution von User Stories (IR)
|
1. Epics = Abstrakte Platzhalter (z.b. Bezahlfunktion) 2. abgeleiterte US (z.B. Als User möchte ich Rechnungen bezahlen) 3. konkrete US (z.B. [...] per Lastschrift [...], [...]per PayPal [...] etc
|
|
|
|
Gruppierung von User Stories (IR)
|
konkrete Stories können zu einer Gruppe zusammengefasst werden. Z.B. alle US die mit Zahlungsmethoden zu tun haben in eine Gruppe.
|
|
|
|
Priorisierung von User Stories (IR)
|
Finanzieller Wert - Beitrag zum Verdienst - Für Themen einfacher als einzelne Stories Kosten - Kosten für Entwicklungsaufwand, Hardware, kostenplfichtige Dienste, Lizenzen, Support Kundenzufriedenheit - Basis,Leistung, Begeisterung Risiko - adressiert hohes/geringes risiko/Wert - Bringt hohes/geringes Risiko/Wert Abhängigkeiten - Spielen priorisierte Rolle, sollten aber nicht vorhanden sein
|
-
|
|
|
User Stories mit MuSCoW priorisieren
|
Must Have - US is zwingend erforderlich Should Have - US ist wichtig System funktioniert aber auch ohne Could Have - User Stories dieser Kategorie werden nur umgesetzt wenn noch Kapazitäten zur Verfügung stehen Won't have this time - vorgemerkt aber aktuell nicht umgesetzt. Schnelle Priorisierung des initialen Product Backlog Epics lassen sich schätzen Must-Have, Should Have Epics werden weiterverfolgt und zu User Stories weiterverwertet.
|
|
|
|
Das Product Backlog im Interaction Room
|
Epics bu. US werden auf Karten an einer Pinnwand oder Whiteboard notiert - dann gruppiert, dann priorisiert Zuordnung zu Prozesschritten und aktivitäten möglich - Epics meist mehr als eine aktivität - Themen besitzen ca. die Granualirität eines Ebene 0 Prozesses - User Stories lassen sich 1 bis n Aktivitäten zuordnen
|
|
|
|
Ziele des IR - Überblickswissen und gemeinsamen Problemverständnis schaffen
|
Anforderungen sammeln und als US notieren US gruppieren, priorisieren und schätzen Systembestandteile und - umgebung kennenlernen Zielmodell auf höchster Abstraktionsebene mit struktureller Aussagekraft Aspekt von Zielmodell verfeinern Verbindung von Ausgangmodell mit relevantem Aspekt des Zielmodells
|
|
|
|
Ziele des IR - Erwartete Probleme und Komplexität hervorheben
|
Aufwandstreiber identifizieren Aufwandstreiber in verfeinerten Modellen konkretisieren Weitere Aufwandstreiber identifizieren Priorisierung von Umsetzungsschritten Ansprechpartner identifizieren / Experten einbeziehen Spezielle Testziele und deren Güte
|
|
|
|
Ziele des IR - Unsicherheit explizit machen & reduzieren
|
Klärungsbedarf in Zielmodell darstellen Teile des Klärungsbedarfs auflösen Nachvollziehen von Entscheidungen Nachvollziehbarkeit herstellen
|
|
|
|
Ziele des IR - Fortschrittskontrolle und Implementierungsprobleme verdeutlichen
|
Fortschritt festhalten Fortschritt in Bezug setzen Entstehende Projektrisiken identifzieren Versionshistorie und Entscheidungen nachvollziehen
|
|
|
|
Erwartete Probleme und Komplexität hervorheben und managen - Wert und Aufwandstrieber identifizieren
|
Prozesse und Datenobjekte besitzen nicht die gleiche Relevanz für das Geschäft Klassische Modellierungssprachen sehen keine ntiven mechanismen vor um diese Infos in Modellen darzustellen Annotationen zur Darstellung von Wert und Aufwandsrtreiber.
|
|
|
|
Wert und Aufwandstrieber identifizieren - Wertorientierte Annotationen
|
Frequenz der Nutzung - Stellt in Geschäftsprozessen Anforderungen an die Usability Viele Nutzer - Stellt Anforderungen an die Usability optimierung Bewegtes Geld in unternehmenskritischer Höhe - Hohe Summe oder häufige Bewegung geringer Beiträge Image - Wichtig für Außendarstellung der Firma / Kundenzufriedenheit
|
|
|
|
Wert und Aufwandstrieber identifizieren - Qualitätsorientierte Annotationen
|
Gesetzliche Anforderungen - i.d.r. zwingend umzusetzen da sonst Strafen drohen Vorgehen nach Richtlinie Vorgaben (bspw BSI Sicherheitsanforderungen) Performanz - Zeitkritische Prozesse (Abruf von Kundendaten während Telefonat) - Ressourcenintensive Prozesse - Rechenintensiver Arbeitsschritt (Tarifsanierung) Sicherheit - zugriffskontrollen, Backups etc. Sensibilität von Daten (Krankheitsbilder von Patienten) Gefahr von Dubletten - Ungewollte Redundanz Fehlertoleranz (Berechnung von Verträgen) Zuverlässigkeit ( Daten während Antragsprozess lokal vorhalten)
|
|
|
|
Wert und Aufwandstreiber identifizieren - Problemorientierte Annotationen
|
Umsetzungskomplexität - Umsetzungverursacht überdurchschnittlich viel Aufwand Ungewissheit - Komplexität ruft Ungewissheit und weiteren Diskussionsbedarf hervor Änderungsdynamik - Artefakt unterliegt zukünftiger Veränderung sowie deren noch nicht bekannter Ausprägung Mobilität - Funktion oder Daten muss in mobilen Anwendungen zur Verfügung stehen
|
|
|
|
Ableitung von Testfall und Testfallguide
|
Management von Komplexität und Problemen Qualitätsorientierte Annotationen treffen Aussagen über die Testfälle -Güte der TF ist das Ergebnis der Konkretisierung der Annotationen
|
|
|
|
Wie reduziert man Unsicherheiten explizit und reduziert sie?
|
Im Gegensatz zur Annotation der Ungewissheit, die sich auf umsetzbare Artefakte bezieht, existieren auch Elemente dessen Umsetzung unsicher ist Unsicherheit bei unstrukturierten Prozessen, indeterministischen Aktivitätsfolgen, Annahmen der Umsetzbarkeit nicht feststeht. Unserbarkeit wird mit Wolken gekennzeichnet
|
|
|
|
Priorisierung der Umsetzungsreihenfolge
|
Aufwand und Priorität von US, Annotationen und Wolken sind Indikator für Komplexität und Unsicherheit Expertenmeinung und Verfeinerung der Modelle löst Teil des Klärungsbedarfs auf Erst die "schwierigen" Aufgaben Umsetzungspriorität wird durch Aufwands und Komplexitätstreiber begründet
|
|
|
|
Identifikation relevanter Experten
|
Erwartete Komplexität und Proleme managen Teile des Klärungsbedarfs lösen Annotationen sowie Wolken sind Indikator zur Experten sichen Rechtsexperten wegen revisionssicherer Speicherung zu Rate ziehen
|
|
|
|
Fortschrittskontrolle und Implementierungsprobleme verdeutlichen
|
Fertiggestellte Artefakte müssen as solche gekennzeichnet werden und ins Überblicksmodell integriert werden Darstellung erfolgt durch analogisierung digitaler Artefakte Einordnung in Überblicksmodell erfolgt durch Überkleben von Modellelementen an den Wänden des IR mit Ausdrucken der Artefakte
|
|
|
|
Fortschritt festhalten und in Bezug stellen
|
Fortschritt verdeutlichen Nachvollziehbarkeit der Entscheidungen herstellen Erstellen von Lösungsartefakten Artefakt über Modellelement kleben - Indikator der Veränderbarkeit
|
|
|
|
Projektrisiken identifizieren und Versionshistorie nachvollziehen
|
Design und Implementierungsprobleme verdeutlichen Häufig überklebte Artefakte weisen auf Probleme hin Versionshistorie kann abgelesen werden und Entscheidungen bleiben nachvollziehbar
|
|
|
|
Vorteile des IR Ansatzes
|
Schnell, intuitiv, pragmatisch Kein neues Modell Unterstützt Kommunikation Bildet Komplexität und Fortschritt realistisch ab Offenbart bestehende Unsicherheiten im Systemverständnis Visualisiert sonst leicht übersehene Abhängigkeiten Kompatibel zu IS9241-210 - Gechäftskontext und Anwendungsumgebung als Ausgangspunkt Einbeziehung von Fach und Technologieexperten Fortlaufende Experten Evaluierung und Verfeinerung
|
|
