Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung
Dr. Jan G. Wieners // jan.wieners@uni-koe...
Phasen der Software-Entwicklung
 Analyse
 Spezifikation
 Entwurf
 Algorithmus
 Pseudocode
 Implementation
 (Post-Im...
Ergänzungen
„Betriebssysteme“
Speicherverwaltung: Swapping
 Problem: Externe Fragmentierung
Speicherverwaltung: Paging / Kachelverwaltung
MMU (Memory Management Unit) kümmert sich um
die Übersetzung virtueller Speicheradressen auf
den physikalischen Speicherbe...
Grundproblematik: Inkonsistenzen im Dateisystem
Z.B. Systemabsturz  Inkonsistenz
Journaling-Dateisysteme (ext3 / ext4): Ä...
 SSDs und (De)fragmentierung?
Neulich in den
Sommerferien…
Analyse
„Regeln zur Leitung des
Geistes" (1628):
 Hohe Relevanz der
Analysephase
 Aufteilung in Teil- und
Unterprobleme
 Hierar...
Analyse  Spezifikation  Lasten- /
Pflichtenheft
Entwurf
Systemarchitektur? Tools / Werkzeuge?
www.thecodinglove.com
Entwurf: Mockups
Entwurf: Algorithmus Eindeutige Beschreibung eines endlichen Verfahrens zur Lösung einer bestimmten Klasse von Problemen
„Algorithmus“, formal:
Eine Berechnungsvorschrift zur Lösung eines Problems heißt
genau dann Algorithmus, wenn eine zu die...
TheSimpleMaths:
https://www.youtube.com/watch?v=QR8ffLPtomM
 Finitheit: Das Verfahren muss in einem endlichen
Text eindeutig beschreibbar sein.
 Ausführbarkeit: Jeder Schritt des V...
Finden Sie einen Weg aus dem Labyrinth
Entwerfen Sie ein Verfahren, das Sie aus jedem Labyrinth (mit Ausgang) führt
Pledge-Algorithmus:
 Prämisse: Wir gehen davon aus, dass alle Ecken rechtwinklig
sind
 Somit kommen nur Rechtsdrehungen ...
Pseudocode Pledge-Algorithmus:
Setze Umdrehungszähler auf 0;
Wiederhole
 Wiederhole
 Gehe geradeaus;
 Solange Wand erre...
Implementation
Programmerstellung und Programmiersprachen
Programmiersprachen
Strukturierte Computerorganisation
Problemorientierte Sprache
Assemblersprache
Betriebssystemmaschine
Befehlssatzarchitekt...
Vorgehensmodelle
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Wasserfallmodell
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Prototypische Entwicklung
Anforderungsanaly...
Iterative Entwicklung
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Iterativ Inkrementelle Entwicklung (State of the Art)
Manifest für Agile Software-Entwicklung
 2001 veröffentlicht von 17 renommierten Entwicklern
[http://agilemanifesto.org/i...
 Arbeit in Sprints
 Feedback maximieren durch zeitnahe Software-
Inkremente
 Testgetriebene Entwicklung
 Refaktorisier...
"Als <Rolle> möchte ich <Ziel/Wunsch>, um
<Nutzen>"
[https://www.holisticon.de/2013/06/user-story-cards-aufs-wesentliche-reduziert/]
Product Backlog
mit priorisierten
Aufgaben
Quelle: Jeff Patton, http://agileproductdesign.com/presentations/user_story_map...
Unter jeder Aktivität / jedem
Feature: Entsprechende User
Stories
Quelle: Jeff Patton, http://agileproductdesign.com/prese...
Ein Wanderer kommt an eine Weggabelung. Er weiß,
dass der eine Weg ins Dorf führt, der andere jedoch in
einen Sumpf - und ...
/
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung
Nächste SlideShare
Wird geladen in …5
×

Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung

562 Aufrufe

Veröffentlicht am

Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung

Veröffentlicht in: Bildung
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
562
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
201
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Swapping
    Jeder Prozess wird komplett in den Speicher geladen, darf eine gewisse Zeit laufen und wird anschließend wieder auf Festplatte ausgelagert (Stichwort „Virtueller Speicher“)
    Prozesse im Leerlauf werden zumeist auf der Platte gespeichert, so dass sie keinen Speicher verbrauchen, wenn sie inaktiv sind
    Benötigte Prozess-Segmente werden von der Speicherverwaltung geholt und in den Arbeitsspeicher geladen. Ist nicht ausreichend Platz vorhanden, werden andere Segmente auf die Festplatte ausgelagert
    Nachteil: Da das Swapping keine festgelegten Segmentgrößen bietet, entsteht schnell eine externe Fragmentierung (Lücken zwischen den Adressräumen der Prozesse)
  • Paging
    Der Adressraum eines Programms wird in Einheiten aufgebrochen, die sogenannten Seiten (Pages)
    Jede Seite ist ein aneinander angrenzender Bereich von Adressen
    Die Seiten werden dem physischen Speicherbereich zugeordnet (auch unterteilt; hier werden die einzelnen Stücke als „Seitenrahmen“ bezeichnet)  Eine Seite und der Seitenrahmen verfügen über die gleiche Größe
    Zuordnung von Seitenrahmen zu Seiten über Seitentabelle
    Läuft der Prozess, müssen nur die benötigten Speicherseiten im Hauptspeicher liegen
    Greift das Programm auf einen Teil des Adressraumes zu, der sich im physischen Speicher befindet, kann die Hardware die notwendige Zuordnung sehr schnell durchführen
    Will das Programm dagegen auf einen Teil des Adressraumes zugreifen, der nicht im physischen Speicher ist, wird das OS benachrichtigt, das fehlende Stück zu beschaffen und den fehlgeschlagenen Befehl noch einmal auszuführen
  • Beispielfrage: Erläutern sie den Unterschied zwischen Swapping und Paging und beschreiben sie die beim Swapping auftretenden Probleme.
    Beispiellösung: Da auszuführende Programme größer werden können als der Hauptspeicher und der Ablauf von Programmstücken des Programms nicht vorher vom Programmierer festgelegt werden sollte, wurde das Konzept des virtuellen Speichers entwickelt. Dabei werden Programme virtuell vom Betriebsystem in einem Bereich von der Festplatte in kleinere Segmente bzw. Seiten geteilt, die groß genug sind, um auch im Arbeitsspeicher verarbeitet werden zu können. Beim Programmablauf werden nun relevanten Seiten / Segmente in den Arbeitsspeicher geladen um sie aufzuführen. Dabei ergeben sie die Unterschiede bei Swapping und Paging. Beim Paging wird, wenn eine relevante Seite aus dem virtuellen Speicher benötigt wird, die derzeitige Seite ausgelagert und auf der Festplatte unter der virtuellen Adresse gespeichert. Die geladene Seite aus dem virtuellen Speicher erhält nun ihre physische Adresse im Arbeitspeicher und füllt diesen. Bei Swapping befinden sich mehrere Programmsegmente aus dem virtuellen Speicher, die jedoch allgemein keine festgelegte Größe haben, wie die Seiten. Wenn ein Teil des Programms benötigt wird, der nicht im Arbeitsspeicher vorhanden ist, dann wird zunächst untersucht, ob im Arbeitsspeicher für dieses Segment noch genug Platz vorhanden wäre. Wenn dies nicht der Fall ist, werden Segmente, die zurzeit nicht benötigt werden aus dem Arbeitspeicher auf die Festplatte wieder ausgelagert und an diese Stelle wird das benötigte Segment geladen. Das angesprochene Problem entsteht dabei durch die variablen Größen der Segmente. Da das ausgelagerte Segment meist immer größer ist als das benötigte, bleiben Speicherlücken zurück, die ungenutzt bleiben. Es geht dadurch Arbeitsspeicher verloren, wodurch die allgemeine Effizienz (Stichwort: externe Fragmentierung) gehemmt wird.
  • Grundproblematik: Veränderungen von Dateien erfordern Schreiboperationen an mehreren Stellen des Speichermediums. Wird der Rechner vor Abschluss aller Operationen z.B. neu gestartet, befindet sich das Dateisystem in einem inkonsistenten Zustand (es enthält Änderungen, aber noch nicht alle Änderungen)

    Das Journaling-Konzept wirkt dieser Problematik entgegen. Angenommen, der Benutzer will eine Datei D aus dem Verzeichnis V1 ins Verzeichnis V2 verschieben. Dann müssen zwei Schreiboperationen durchgeführt werden: Zum einen muss der alte Eintrag auf D aus dem Verzeichnis V1 entfernt werden, zum anderen muss der neue Eintrag D in das Verzeichnis V2 hinzugefügt werden. Letzteres kann es erforderlich machen, dass das Verzeichnis V2 vergrößert wird, was dann noch weitere Veränderungen nach sich ziehen würde. Alle diese Änderungen werden nun nicht an den Stellen durchgeführt, wo sie eigentlich hin gehören, sondern sie werden zuerst in einem speziellen Bereich in das Dateisystem geschrieben, dem sogenannten Journal. Dort steht dann z. B. qualitativ:
    Entferne Eintrag D aus Verzeichnis V1
    Füge Eintrag D dem Verzeichnis V2 hinzu
    Diese Vorgehensweise alleine ergibt allerdings noch nicht das gewünschte Ziel der Sicherheit gegen nicht vollständig durchgeführte Operationen, da hier wieder mitten in der Operation – vielleicht zufällig genau nach „Entferne Eintrag D aus Verzeichnis V1“ aber vor „Füge Eintrag D dem Verzeichnis V2 hinzu“ das System abstürzt. Daher muss das Journal von Zeit zu Zeit abgeschlossen werden. Dabei wird verzeichnet, wie viele Änderungen bis hier durchgeführt wurden, und es wird durch eine Prüfsumme sichergestellt, dass die Daten korrekt sind. Sinnvollerweise sollte also eine Verschiebeoperation mit dem Anlegen der Datei am neuen Ort beginnen, dann alle Daten kopieren und mit der Löschung des Verzeichniseintrags und somit auch der Freigabe des Festplattenplatzes auf dem Quelldatenträger beendet werden.
  • Fragmentierung
  • Bei SSDs spielt eine solche Fragmentierung keine Rolle, hier kann von der ersten und letzten Zelle gleichermaßen schnell gelesen werden, es tritt keine Verzögerung auf«, ergänzt OCZ-Techniker Stamp. „Ferner sind solche Fragmentierungen beabsichtigt, um die Last zwischen den Zellen gleichmäßig aufzuteilen. Würden beispielsweise regelmäßig nur die ersten zehn Prozent der Zellen beschrieben, nutzen sich diese schneller ab. Die Fragmentierung umgeht dieses Problem.“

    Defragmentierung gar schädlich, weil NAND-Flash-Speicher nur eine begrenzte Anzahl von Schreiboperationen verträgt.
  • Dimmu Borgir = Dunkle Burgen, Dunkle Städte
  • Analyse des gestellten Problems  ToDo: Eine Möglichkeit entwickeln, trotz Dunkelheit einen Weg aus dem Labyrinth zu finden

    Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt

    Beachten:
    Problemkomplex exakt und vollständig beschreiben
    Ein- und Ausgabewerte berücksichtigen (Parameter)
    Randbedingungen bzw. Spezialfälle berücksichtigen
  • Programmentwicklung: Analyse
    Descartes (1596-1650)
  • Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt
    Im Zusammenhang mit Ausschreibungen gilt das Lastenheft als Anforderungsspezifikation des Auftraggebers, worauf die möglichen Auftragnehmer mit Pflichtenheften als Umsetzungsspezifikation antworten.
  • Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt
  • Kent Beck (Extreme Programming):
    System wird unrentabel
    Terminverzögerungen
    Projektabbruch
    Hohe Fehlerrate
    Falsche Funktionsfülle
  • „Programmieren im Großen“
  • Der aus dem Englischen stammende Begriff Mock-up oder Mockup (auch Maquette) bezeichnet im Deutschen beispielsweise eine Attrappe. Er wird heute aber meist für ein maßstäblich gefertigtes Modell bzw. eine Nachbildung zu Präsentationzwecken benutzt

    Anders als ein „Mock-up“ ‒ ein visueller Prototyp ‒ wird der Begriff Wireframe (Drahtmodell) dazu benutzt, einen sehr frühen konzeptionellen Entwurf einer Website oder eines Software-Frontends darzustellen. Dabei spielt die Gestaltung und Funktion noch keine Rolle. Das Augenmerk liegt auf der Anordnung von Elementen und der Benutzerführung (UX, Benutzererfahrung).
    Es gibt zwei Arten eines Wireframes:
    Zum einen statische Wireframes: Dies ist eine schematische Darstellung einer einzelnen Seitenvorlage. Hier werden die grundlegenden Elemente der Seite festgehalten. Ein konzeptionelles Layout sollte erkennbar sein. Ein vollendetes Design ist nicht notwendig.
    Des Weiteren gibt es auch dynamische Wireframes. Diese bestehen aus mehreren Seiten, die als funktioneller Prototyp interaktiv miteinander verknüpft sind. So ist eine Navigation von einer zur anderen Seite möglich. Dynamische Wireframes werden häufig durch einen beiliegenden Navigationsbaum oder ein Flussdiagramm ergänzt, welche beide die Struktur abstrahieren und leichter verständlich machen.
  • Terminierung von Algorithmen
    Wir verlangen (zumeist) von Algorithmen, dass sie terminieren, d.h. dass sie in endlicher Zeit (und möglichst schnell  Performance) ihre Arbeit erledigt haben
    Performanz: Geschwindigkeit der Problemlösung
  • Grundfrage Algorithmus:
    Existiert ein Algorithmus, der für jedes denkbare Labyrinth, aus dem es einen Ausgang gibt, einen Weg ins Freie findet?
  • Programmiersprache: Eine zum Formulieren von Programmen geschaffene künstliche / formale Sprache
    Warum braucht man so etwas? Darum:
  • Merkmale:
    - potenzielle Probleme frühzeitig
    identifiziert,
    - Lösungsmöglichkeiten im Prototypen
    gefunden, daraus Vorgaben abgeleitet
    Vorteile:
    -
    frühzeitige Risikominimierung
    - schnelles erstes Projektergebnis
    Nachteile:
    - Anforderungen müssen fast 100%-tig
    sein
    - Prototyp (illegal) in die Entwicklung
    übernommen
    - Kunde erwartet schnell Endergebnis
    Optimierung:
    es ist möglich, in die vorherige Phase
    zu springen
  • Merkmale:
    - Erweiterung der Prototypidee; SW wird in
    Iterationen entwickelt
    - In jeder Iteration wird System weiter verfeinert
    - In ersten Iterationen Schwerpunkt auf Analyse
    und Machbarkeit; später auf Realisierung
    große Vorteile:
    - dynamische Reaktion auf Risiken
    - Teilergebnisse mit Kunden diskutierbar
    Nachteile im Detail:
    - schwierige Projektplanung
    - schwierige Vertragssituation
    - Kunde erwartet zu schnell Endergebnis
    - Kunde sieht Anforderungen als beliebig
    änderbar
  • Merkmale:
    - Erweiterung der Prototypidee; SW wird in
    Iterationen entwickelt
    - In jeder Iteration wird System weiter verfeinert
    - In ersten Iterationen Schwerpunkt auf Analyse
    und Machbarkeit; später auf Realisierung
    große Vorteile:
    - dynamische Reaktion auf Risiken
    - Teilergebnisse mit Kunden diskutierbar
    Nachteile im Detail:
    - schwierige Projektplanung
    - schwierige Vertragssituation
    - Kunde erwartet zu schnell Endergebnis
    - Kunde sieht Anforderungen als beliebig
    änderbar
  • Utah, Skiurlaub
  • In Alltagssprache formuliert
    Kurz und knapp
    Intention: Anforderungen an ein zu entwickelndes Software-System frühestmöglich annähern und schrittweise bestimmen

    Als Mitarbeiter des CoDArchLab möchte ich eine Kaffeemaschine anschaffen, um Dienstags nicht immer so müde zu sein.
  • In Alltagssprache formuliert
    Kurz und knapp
    Intention: Anforderungen an ein zu entwickelndes Software-System frühestmöglich annähern und schrittweise bestimmen
  • Eine Sammlung von User Stories für ein Softwareprodukt wird als product backlog bezeichnet
  • Man fragt den einen, was der andere sagen würde, und nimmt dann das genaue Gegenteil.
  • Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung

    1. 1. Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung Dr. Jan G. Wieners // jan.wieners@uni-koeln.de Basisinformationstechnologie I Wintersemester 2015/16 07. Dezember 2015 – Software-Entwicklung: klassisch vs. agil
    2. 2. Phasen der Software-Entwicklung  Analyse  Spezifikation  Entwurf  Algorithmus  Pseudocode  Implementation  (Post-Implementation) Vorgehensmodelle  Wasserfallmodell  Prototypische Entwicklung  Iterative Entwicklung  Iterativ inkrementelle Entwicklung Agile Software-Entwicklung  Intention  Werkzeuge und Methoden  User Stories  User Story Mapping Themenüberblick „Software-Entwicklung: klassisch vs. agil“
    3. 3. Ergänzungen „Betriebssysteme“
    4. 4. Speicherverwaltung: Swapping  Problem: Externe Fragmentierung
    5. 5. Speicherverwaltung: Paging / Kachelverwaltung
    6. 6. MMU (Memory Management Unit) kümmert sich um die Übersetzung virtueller Speicheradressen auf den physikalischen Speicherbereich Paging: MMU Quelle: Tanenbaum: Moderne Betriebssysteme
    7. 7. Grundproblematik: Inkonsistenzen im Dateisystem Z.B. Systemabsturz  Inkonsistenz Journaling-Dateisysteme (ext3 / ext4): Änderungen werden vor der Speicherung in einem reservierten Speicherbereich („Journal“) aufgezeichnet. Ergänzungen „Betriebssysteme“: ext3 / ext4
    8. 8.  SSDs und (De)fragmentierung?
    9. 9. Neulich in den Sommerferien…
    10. 10. Analyse
    11. 11. „Regeln zur Leitung des Geistes" (1628):  Hohe Relevanz der Analysephase  Aufteilung in Teil- und Unterprobleme  Hierarchischer Erkenntnisprozess  Analyse der Analyse i.e. Sicherung der Analyse
    12. 12. Analyse  Spezifikation  Lasten- / Pflichtenheft
    13. 13. Entwurf
    14. 14. Systemarchitektur? Tools / Werkzeuge? www.thecodinglove.com
    15. 15. Entwurf: Mockups
    16. 16. Entwurf: Algorithmus Eindeutige Beschreibung eines endlichen Verfahrens zur Lösung einer bestimmten Klasse von Problemen
    17. 17. „Algorithmus“, formal: Eine Berechnungsvorschrift zur Lösung eines Problems heißt genau dann Algorithmus, wenn eine zu dieser Berechnungsvorschrift äquivalente Turingmaschine existiert, die für jede Eingabe, die eine Lösung besitzt, stoppt.
    18. 18. TheSimpleMaths: https://www.youtube.com/watch?v=QR8ffLPtomM
    19. 19.  Finitheit: Das Verfahren muss in einem endlichen Text eindeutig beschreibbar sein.  Ausführbarkeit: Jeder Schritt des Verfahrens muss tatsächlich ausführbar sein.  Platzkomplexität: Das Verfahren darf zu jedem Zeitpunkt nur endlich viel Speicherplatz benötigen.  Zeitkomplexität und Terminierung: Das Verfahren darf nur endlich viele Schritte benötigen. Algorithmus + Turingmaschine
    20. 20. Finden Sie einen Weg aus dem Labyrinth
    21. 21. Entwerfen Sie ein Verfahren, das Sie aus jedem Labyrinth (mit Ausgang) führt
    22. 22. Pledge-Algorithmus:  Prämisse: Wir gehen davon aus, dass alle Ecken rechtwinklig sind  Somit kommen nur Rechtsdrehungen und Linksdrehungen um jeweils 90 Grad vor  Wir verwalten unterwegs einen Umdrehungszähler, der:  bei jeder Linksdrehung um eins erhöht und  bei jeder Rechtsdrehung um eins verringert wird (auch bei der ersten Rechtsdrehung, die nach dem Auftreffen auf eine Wand ausgeführt wird).  Zu Beginn wird dieser Umdrehungszähler auf null gesetzt  Anschließend werden die beiden Anweisungen  geradeaus, bis Wand erreicht  Folge der Wand, bis Umdrehungszähler = 0 solange wiederholt, bis wir ins Freie gelangen Programmentwicklung: Entwurfsphase
    23. 23. Pseudocode Pledge-Algorithmus: Setze Umdrehungszähler auf 0; Wiederhole  Wiederhole  Gehe geradeaus;  Solange Wand erreicht;  Drehe nach rechts;  Wiederhole  Folge dem Hindernis;  Solange Umdrehungszähler=0; Solange ins Helle gelangt;  Entwurf unabhängig von der Programmiersprache!
    24. 24. Implementation Programmerstellung und Programmiersprachen
    25. 25. Programmiersprachen
    26. 26. Strukturierte Computerorganisation Problemorientierte Sprache Assemblersprache Betriebssystemmaschine Befehlssatzarchitektur (ISA) Mikroarchitektur Digitale Logik Ebene 5 Ebene 4 Ebene 3 Ebene 2 Ebene 1 Ebene 0
    27. 27. Vorgehensmodelle
    28. 28. Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Wasserfallmodell
    29. 29. Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Prototypische Entwicklung Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration Prototyp
    30. 30. Iterative Entwicklung Anforderungsanalyse Grobdesign Feindesign Implementierung Test und Integration
    31. 31. Iterativ Inkrementelle Entwicklung (State of the Art)
    32. 32. Manifest für Agile Software-Entwicklung  2001 veröffentlicht von 17 renommierten Entwicklern [http://agilemanifesto.org/iso/de] Intention / Grundpfeiler:  Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen  Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation  Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen  Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
    33. 33.  Arbeit in Sprints  Feedback maximieren durch zeitnahe Software- Inkremente  Testgetriebene Entwicklung  Refaktorisierung  Codereviews  Pair Programming  User Stories / User Story Mapping  … Agile Entwicklung, so funktioniert‘s
    34. 34. "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"
    35. 35. [https://www.holisticon.de/2013/06/user-story-cards-aufs-wesentliche-reduziert/]
    36. 36. Product Backlog mit priorisierten Aufgaben Quelle: Jeff Patton, http://agileproductdesign.com/presentations/user_story_mapping/index.html
    37. 37. Unter jeder Aktivität / jedem Feature: Entsprechende User Stories Quelle: Jeff Patton, http://agileproductdesign.com/presentations/user_story_mapping/index.html
    38. 38. Ein Wanderer kommt an eine Weggabelung. Er weiß, dass der eine Weg ins Dorf führt, der andere jedoch in einen Sumpf - und da will er nicht hin. An der Gabelung steht ein Haus, und in dem Haus wohnen zwei Zwillinge, die man nicht unterscheiden kann - sie kennen den Weg. Einer der Zwillinge lügt immer, der andere nie. Wenn der Wanderer anklopft, wird einer der Zwillinge an die Tür kommen, aber welcher es ist, das weiß der Wanderer nicht. Der Wanderer kann genau eine Frage stellen, um den Weg herauszufinden. Welche Frage muss er stellen?
    39. 39. /

    ×