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;
56 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
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 |
|
