Softwaretechnik

• -Programme + Dokumentation der Rechnersysteme
• -Ausschnitt aus realer + gedanklicher Welt
• -Anwendungssoftware braucht Systemsoftware
• -Informationssystem: Erfassen Speichern Übertragung Auswertung

• -immateriell, leichter + schneller änderbar
• -kein Verschleiss, nicht physikalisch begrenzt
• -keine Ersatzteile
• -nicht messbar
• -Qualitätsmerkmale

• -Produkt wird ohne Spezifikation + Design geplant
• -gemäß Adhoc- Einfall
• -Modifizierung ist die einzige Aufgabe
• -Build first version, modify until satisfied
• -Vorteile: gut für kleine Programme an der eine Person arbeitet
• -Nachteile: -Unverständnis + Wartung werden größer bei Programmgröße
•                   - unzufriedenstellend
•                  -Game of Plan missing,

• Linearer Aufbau
• Nach Pressmann: Analyse Design Code Test
• Nach Dorfmann: Requirement Analyse, Design Code Test Integrate
• Nach Sommerville: Definition d. Systemanforderungen, Systementwurf, Subsystem, Integration, Installation, Inbetriebnahme, Weiterentwicklung, Retirement

• -Zerlegung in Einzelprozesse (Lebensabschnitte)
• -Teilprozesse dienen als Vorbote der nachfolgenden Prozesse
• -Teile sind individuell
• -Stationen bieten bessere, professionelle Einsicht
• -Basis Qualitätsmanagement/Projektmanagement

• 1.Anforderungsanalyse:
• -Sicht Kunden/Benutzer, was System leisten soll
• -Anwendungsfallanalyse
• -Konzeptanalyse
• -User Interface Mockup
• -Durchführbarkeitsanalyse

• 2.Spezifikation:
• -Beschreibung Funktionalität, Beschränkung
• -welche Eingabe Ausgabe hat das System?
• -Pflichtenheft
• -Guide for Development
• -Entwicklung Szenarien
• -Entwicklung Klassendiagramm
• -Hierrachie

• 3.Design:
• -Wie soll das Produkt Aufgaben erfüllen?
• -Softwarearchitektur, Komponenten
• -Benutzerschnittstellen
• -Physische Datenbanken
• -Spezifikation d. Attribute
• -Methoden, Operationen, Funktionen
• -Erweiterung Klassendiagramm + Codegenerierung

• 3a) Beteiligte Personen
• -Geldgeber
• -Customer, Spezifikation + Inbetriebnahme
• -User + Entwickler

• 3b) Unterschiedliche Sichtweisen
• -Überschätzung von Geschäftsziele
• (Was soll das System tun?)
• -Geschäftsziele einbezogen?
• -Funktion übersetzte in Hard/Software
• -Test DB UserSchnittstellen
• -Analyst: Wie arbeitet das System?

• 4. Implementierung
• -hier Programmierung
• -Zusammenführung aller Codes
• -TopDown: Designfehler können früh erkannt werden

• 5.Evolution/Wartung
• -alle Aktivitäten, die nach Auslieferung durchgeführt werden
• -kompletter Zyklus durchlaufen
• -reverse Engeenierung, Tests

• 6.Retirement
• -kompletter Stillstand d. Systems
• -Neues günstiger oft
• -Relaität nicht linear

• -Ergebnisse einer Phase müssen erst abgeschlossen werden bevor nächste Phase beginnt- Vorergebnisse relevant
• -Integration + Verifizierung in jeder Phase-->Rückkopplung möglich

• -für jede Phase wird Prototyp erstellt und Anforderungen abgeleitet
• -stetige Weiterentwicklung
• -blödes und umständliches System

• -muss nicht erst nach kompletter Fertigstellung ausgeliefert werden
• -Mögliche funktionierenden Teilstücken ausliefern
• -Vorteil->kein Big Bang am Ende, frühe Rückmeldung
• -Teile des gesamten Builds, welche zusammen bestimmte Funktionalitäten haben
• -Spezi,Design,Implement,Deliver

• -Basis von Wasserfallmodell
• -Integration von Prototypen + Risk Management
• -Projektplanung
• -Riskanalyse in jeder Phase

• -definiert Bedingungen, was das System tun soll
• -Anforderungen können Probleme machen, wenn sich nicht Benutzerforderung entsprechen

• Probleme bei:
• -inkonsistens und Unvollständigkeit
• -teuer einmal festgelegtes zu ändern
• -Missverständnisse

Anforderung = Dienstleistung

• -Zuverlässigkeit
• -Wartbarkeit
• -Performance
• -Usability
• -Sicherheit

• -System Requirements Engineering
• -->Anfoderungen werden für Stakeholder verständlich formuliert
• -Architectural Design-->System im Subsystem (Hard/software,parallel implementiert)
• -Zusammenfügung Gesamtsystem
• -Systemvalidität

• -Funktion + Dienste die das System bereitstellen soll
• -Rahmenbedingungen
• -Eigenschaften + Qualitätsmerkmale
• -Angaben zu möglich integrierten Systemen
• -Infos zu Anwendungsdomäne
• -Rahmenbedingungen + Entwicklungsprozess
• -Beschreibung Hardware auf das implementiert werden soll
• -Glossar zur Terminologie

• benutzt von:
• -Kunden des Systems
• -Projektmanagement
• -Systementwickler
• -Systemtester
• -Systemwarter

• -Interviews
• -Szenario
• -Soft System Method
• -soziale Strukturen beachten
• -Wiederverwendung von Anforderungen

-Leistung+Beschränkungs Informationen zu seiner Implementierung

• Funktionale Anforderungen:
• -Anfoderungen sind Aufstellung der Dienste, die ds System bereitstellensoll, für Berechnungen und Beschreibungen

• Nicht Funktional:
• -Einschränkungen für das zu entwickelnden System
• -Produktanforderungen + Unternehmensanforderungen
• (gelten für das ganze System)
• -Anforderungen Erhebung Spezi Validierung Management
• -Gesamtspezifikation ist Dokumentation, die für Entwickler + User gelten
• -Änderungen müssen sofort bearbeitet werden

• -Dokumentation der Gesamtheit der Forderung an die LuL des Auftragnehmers des Auftrags
• -Lastenheft: was und wofür etwas gemacht werden soll
• -Pflichtenheft wie konkreter & womit

• -Systemüberblick
• -Glossar
• -Angaben zu funktionalen Anforderungen
• -Operationale Randbedingungen

• Znotka:
• -Vorwort/Einführung
• -Glossar
• -allg. Benutzeranforderungen
• -Systemarchitektur
• -Hard/Software Spezifikation
• -Qualitätsanforderungen + optionale Ergänzung
• -Index

• -geschrieben im ausformuliertem Text (strukturiert)
• -Ergänzung durch Diagramme + Bedingungen
• -häufiger gelesen als geschrieben

• Probleme mit Anforderungen:
• -Verwendung von komplexen Bedingungen
• -zu inkonsistens
• -Voraussetzungen von zu viel Vorwissen
• -unklare Anforderungen
• -Auslassen von Problemfeldern
• ---> können zu verspäteter Auslieferungen/Änderungsanforderungen
• führen

• -Prozesse zur Bestimmung, Analyse + Validierung der Systemanforderungen
• -Unterscheidung in Anwendungsdomäne, beteiligte Personen + Organisationen
• -Anforderungsbestimmung mit allen Stakeholdern
• -Anforderungsanalyse + Verhandlung
• -Anforderungsdokumentation
• -Anforderungsvalidierung

• -Domain Expert: Providing Information, application domain and the specific domain
• -System end user: Responsible for using the system
• - RE: Responsible for eliciting & specifying the system RE
• -Software Engi: Responsible for developing the prototype software system
• -project manager: Responsible for planning & estimating the prototyping project

• -Softwareanalytiker sind verantwortlich für das Systementwicklung
• -Endanwender werden das System noch Auslieferung benutzen (müssen)
• -Manager der Anwenderseite sind verantwortlich für den Einsatz des System der Vergabe an die Entwickler
• -TÜV System
• -Domäneexperten die die Informationen über das System von Anwenderseite zur Verfügung stellen

• -Modellierung & Validierungstools unterstützen die Entwicklung von Systemmodellen, die das System spezifizieren & die Modelle auf Vollständigkeit & Konsistent prüfen
• -Management Tools verwalten eine Datenbank, in der die Anforderungen enthalten sind und untersützten die Änderungsverwaltung

• -befasst sich mit Veränderungen der Entwicklungsprozesse zur Verbesserung von definierten Zielen
• -->Qualitätsverbesserung
• -->Quantitäsverbesserung 
• -->Einhalten "on time"
• -->Einhalten "on budget"

• Fragen:
  -Welche Probleme existieren aufgrund aktueller Prozesse?
• -Welche Verbesserungsziele können gesetzt/erreicht werden?
• -Wie gestaltet sich die Organisation?
• -Wer überwacht/managet die Sache?

• -zu wenig Beteiligung der Stakeholder
• -schlechte Kommunikation
• -Fehlen von Anforderungsmanagement
• -Fehlen definierter Verantwortlichkeit
• -Geschäftsanforderungen werden missachtet
• -zu lange Projektlaufzeit
• -zu schlechte RE Dokumente

• 1.Initial Level:
• -kein definierte Prozesse, einzel Entwickler überlassen wie sie ihren Prozess steuern& welche Entwicklungsmethoden

• 2.Repeatable Level:
• -Kosten + Projektmanagement sind vorhanden
• -Budget + Ablauf für Projekte in ähnlichen Anwendungsdomänen

• 3.Defined Level:
• -Der Softwareprozess ist dokumentiert, standardisiert & integriert in einen Standard Softwareprozesse der Organisation

• 4.Management Level:
• -Detail Messung zu Prozess & Produktqualität werden durchgeführt und die Ergebnisse werden verwendet zur Steuerung anstehender Prozesse

• 5.Optimizing Level
• -Die Organisation hat einen kontinuierlich Verbesserungsprozess installiert, der auf objektiven Messungen beruht.

• -Definiere einen Standard Dokumentenstruktur
• -Identifiziere jede Anforderungen
• -Anforderungsmanagement
• -Checkliste zur Anforderungsanalyse
• -Szenarien Verwendung
• -Spezifiziere Anforderungen quantitativ
• -Prototypen zur Animierung der Anforderungen
• -Wiederverwendbare Anforderungen

• -Softwareentwurf wird durch explizite grafische Modelle dokumentiert
• -wenn möglich so darstellen, das sofort Code generiert werden kann

• -Verstehen der Anwendungsdomäne (allg. Einsatzgebiet)
• -Problemverständnis (Detailproblemverständnis)
• -Verstehen des Kundengeschäfts (Harmonie+Geschäftsziele)
• -Verstehen der Bedürfnisse & Beschränkungen der Stakeholder-->Bedürfnisse der Menschen, Unterstützung durch System

• -Setzte Ziele, allg. Geschäftsziele, Beschreibung des Problems Angaben zur Notwendigkeit d. Systems, Beschränkungen
• -Verstehe den Hintergrund, Info zur Organisation, Wo soll das System installiert werden, Anwendungsdomäne, Info über aktuelle Systeme
• -Strukturierte das Wissen, Wissen/Aktivitäten gesammelt
• -Sammle die Anforderungen der Stackholder(Bestimmung der Anforderungen)

• -Prüfung der Notwendigkeit/Gültigkeit - Ist das Problem das tatsächliche Problem der User?
• -Prüfung der Vollständigkeit & der Konsistenz, System muss erwartet Funktionen & Einschränkungen definiere (Konsistenzprüfung)
• -Prüfung der Durchführbarkeit (Realisierbarkeit on budget on time)
• -Prüfung der Diskussion
• -Priorisierung der Anforderungen
• -Festlegung der Anforderungen

• - Beobachtung von Menschen bei der Arbeit
• -nicht Schema F
• -Ethnografie muss akzeptiert werden
• -Hinreichend wissen
• -Work setting viewpoint
• -Social & organisational perspective
• -Workflow Viewpoint

• -Wegwerf Prototypen
• -Evolutionäre Prototypen (schnelles arbeitsfähiges System) nur wichtigsten Anforderungen der Software

• Vorteile:
• -experementierfreundig
• -Durchführbarkeit+Gebrauchsgültigkeit
• -Benutzerschnittstelle (look and feel)
• -Basis für Systemtest
• -Basis für Entwicklung der Dokumentation
• -Implementierung der Prototypen

• Nachteile:
• -hohe HRM
• -Entwicklungskosten
• -Verlängerte Entwicklungszeit
• -Prototyp oft zu unvollständig

• -Prototyp existiert auf Papier zur Diskussion
• -"Wizard of Oz", Person simuliert Antworten des Systems bzgl. auf Anwendereingaben
• -Ausführbarer Prototyp, Sprache der 4. Generation
• -Visuelle Programmierung Visula Basic, Object Works, PHP, Java

• -Ziel: entdecken von Problemen, Unvollständigkeit & Inkonsistenzen auf der Menge der Anforderungen
• -Stakelholder im Rahmen des Verhandlungsprozesses
• -Checkliste erstellen

• 1.Beispiel:
• -Informationen zur späteren Phase (Anforderungen zu Implementierung & Design)
• - Kombinierte/zusammengesetzte Anforderungen
• -Unnötige Anforderungen?

• 2.Beispiel:
• -Verwendung von Nichtstandard Hardware?-->welche Plattform?
• Übereinstimmung mit den Geschäftszielen?

• 3.Beispiel:
• -Ist die Anforderung mehrdeutig? Welche Interpretation?
• -Realistische Anforderungen?
• -ist Anforderung testbar?

• - Gibt es Überlappungen oder mögliche Konflikte?
• -Anforderungsinformationsmatrix
• -oft unpraktikabel
• -Konflikt:1
• -Überlappung:1000
• -Unabhängig: 0

• -Unterschiedliche Meinungen über Anforderungen sind unvermeidlich
• -Keine "Failure" sondern zeigen Prioriäten + Bedürfnisse auf -->KompromissjQuery112406239919638535503_1547457003514 Zeitaufwendig?

-informale Modelle der socio-technical systems, Behandlung von Mensch + Organisation

• -Softwaresysteme / Programme enthalten Fehler
• -gute Softwareentwicklung, wenig Fehler möglichst klein
• -Auswirken von Fehler begrenzen

• -Progress einer Programmausführung mit Absicht aus Fehlerfindung
• -destruktiver Prozess, da er nur Fehler aufzeigt aber nicht deren Abwesenheit
• -Testen, Evaluieren, Debuggen, Korrektur
• -Jede Phase wird getestet (RE Analyse,Spezi,Design, ModulDesign, Programm)

• -Testfälle ausschließlich aus der Spezifikation des Objekt abgeleitet
• -nicht Berücksichtigung der Struktur, des Codes
• -nur außen sichtbare Verhalten des Testsobjekts
• -Man muss nicht wissen wie das System arbeitet

• -Ansehen des Programm Codes, strukturell
• -Äquivivalenzklassen bilden (effektiv)
• -Anwendung/Eingabe Fehler, ausgiebig aufwendig
• -aus dem Design heraus erfolgen

• 1.Unit Testing: Testen einzelner Operationen
• 2.Modul Testing: Klassen abstrakter Datentypen, Komponenten
• 3.Subsystem Testing: Menge von Modulen
• 4.System Testing: Testen der gesamten System
• 5.Acceptance Testing: Abschliessendes Testen mit Daten

• -Betrachte die Funktionen des Systems & zeige deren korrektes wie auch fehlerhaftes Arbeiten-->Black Box
• -Betrachte die interne Struktur und den internen Ablauf & stelle sicher, dass jede interne Funktion arbeitet wie spezifiziert bzw. zeige deren Fehlerhaftigkeit-->White Box strukturelles Testen

• -Fehlende + fehlerhafte Funktionen, zeigt Abweichungen des Verhaltens einer Funktion
• -Schnittstellenfehler, Zwei Module scheinen beim testen fehlerfrei, drittes Modul hinzufügen
• -Fehler in Datenstrukturen & beim Datenzugriff - Output zeigt Fehler (zB unvollständig)
• -Performanzfehler-Laufzeiten, die für Echtbetrieb unzulässig
• -Initialisierung & Terminierungsfehler, kein korrektes terminieren der Daten
• -Äquvivalenzklassenanalyse

• -Pfadfehler (inkorrekt)
• -Bedingungsfehler (falsch ausgewertet Bedingungen)
• -Fehler im Datenfluss
• -Schleifenfehler (N+1 mal durchlaufen)

• -Betrachtung nur die ausführbaren Quellcodezeilen
• -if (false) {print"abgedeckt;"}

• -Co-Test, jede Anweisung mind. 1x
• -Beachtung, dass kein toter Code existiert 
• -Wenn jede Anweisung durchläuft, dann Abdeckung
• -Nur Knoten testen

• 1.Tätigkeiten: 
• -Übergabe des Gesamtprodukts+Dokumentation an den Auftraggeber
• -Belastung + Stresstests
• -Abnahmeprotokolle

• 2.Abnahme:
• -erst nach erfolgreichem Tests d.Produkts
• -benötigt schriftliche Erklärung

• 3.Externer Auftraggeber:
• -A kann Produkt nur nutzen
• -A kann Produkt nutzen pflegen und warten

• 4.Produktnutzung:
• -Qualitätsmerkmale, Usability, Integrität, Effizienz, Korrektheit, Verlässlichkeit

• 5.Wartung:
• Standhaftigkeit,Festbarkeit,Flexibilität

• 6.Abnahmetest: 
• -Erfüllung der Qualitätsmerkmale
• -Für Wartung und Pflege Entwurfs + Implementierungsdokumente

• 1.Tätigkeiten: 
• -Installation des Produkts in Zielumgebung
• -Schulung der Benutzer+Personal
• -Inbetriebnahme des Produkts

• 2.Einführungsprotokoll:
• -sorgfältig geplant
• -Umfangreiche Produkteinführung
• -Wie Innovation behandeln

• 3.Umstellung:
• -Zeitpläne mit Netzplänen
• -Anpassen des Datenbestandes
• -Neue Programme notwendig?

• 1. Direkte Umstellung:
• -unmittelbar von alt (stopp) auf neu (start)
• -in Wochenends Feiertagsperiode
• -könnte ohne Zeit zu Risiken führen

• 2.Parallelauf:
• -Bewegungsdaten werden zunächst im allen & im neuem Systemverlauf
• -Hohe Kosten
• -gilt aber als sicher

• 3.Versuchslauf:
• a)Neues System arbeitet mit alten Daten und MUSS gleiche Ergebnisse liefern
• b)Abgestufte Übernahme des neuen Systems

-Pilotinstallation bei Produkt für den anonymen Markt (Betatest)

Ende der Produktentwicklung mit der Freigabe

• -beginnt nach erfolgreicher Abnahme + Einführung
• -Anpassung Umweltbedingungen(HardSoft+ Orga)
• -Fehlerbereinigungen
• -Neue Bedürfnisse + Funktionen
• -neue Geschwindigkeit + Benutzeroberfläche nötig
• -Alterung von Software, wenn sie  nicht mehr Wirklichkeit entspricht

• -alle Tätigkeiten, die dazu dienen Fehler zu beheben
• -alte Fehler & bei Wartung neu entstandene Fehler
• -nur minimale Fehlerabdeckungstest wirtschaftlich aber vertretbar
• -0,75% Fehlerquote
• -Wartungsfehler "Second Level Defects"

• -frisch eingesetzte Software
• -verbraucht Zeit und Speicher
• -selten vor erster Freigabe
• -Optimierung bleibt bei der Wartung vorbehalten

• -Änderung der technischen Umgebung (neue Software)
• -Änderung User Content
• -Änderung in den Funktionen (Gesetze , betriebliche)

• -funktionale Ergänzung des Produkts
• -Funktionen, die bei Erstimplementierung nicht vorgenommen wurden
• -Neue Funktionen und Bedürfnisse

• -Finden von Software / Leistungs Implementierungsfehler
• -Notfall Reparaturen
• -Implementierung von spezifizierten Produktanforderungen
• -ändernde Produktumgebung
• -perfektionierende Aktivität, auch Erweiterungen

• -Finden + Beheben von Fehlerursachen von Software im Betrieb, wenn Fehlerwirkung bekannt ist
• -Basis fehlerhaft & inkonsistens
• -Anweichungen zwischen Teilprodukten
• -einzelner Fehler oft wenig Auswirkung auf Gesamtprodukt
• -Fehlerkorrekturen beziehen sich auf Implementierung
• -Ereignis gesteuert, nicht vorhersehbar, planbar

• -Durchführung von Änderungen & Erweiterungen im Betrieb
• -Basis ist konsistentes Produkt
• -kleine + große Modifikation in allen Teilprodukten
• -planbar
• -Bereiche: Definition, Entwurf, Implementierung
• -Wartung + Pflege größer als Entwicklungsaufwand
• -inkrementelles + evolutionäres Prozessmodell
• -Sanierung? Wirtschaftlich?->Lebenserwartung?
• -Korrekturen, Verbesserungen, Anpassungen, Umgebungen, Anforderungen, Spezifikation

• -Analysierbarkeit (Mängel, Ursachen, Versagen, Änderbarkeit)
• -Modifizierbarkeit ( Verbesserung, Fehlerbeseitigung, Umwelt)
• -Stabilität (unerwartete Wirkung von Änderungen)
• -Prüfbarkeit (Prüfung geänderte Software)
• -Übertragbarkeit in eine andere Umgebung
• -Anpassbarkeit
• -Installierbarkeit, Konformität (Normen)
• -Anwendbarkeit

• -Zuverlässigkeit, Reife, Fehlertoleranz
• -Wiederherstellbarkeit, Verbrauchsverhalten
• -Effizienz, Effektivität
• -Änderungsmanagement bei Fehlmeldungen, Problemen, Verbesserungen, Änderungen, Pflege und Wartung
• -Organisation, Wartung eigenständig, Teil der Entwicklung

• -Unified Modeling Language
• -Definiert für jeden einzelnen Diagrammtyp eigene Begriffe, Beziehungen, Elemente & Beziehungen
• -Diagramme als grafische Darstellung von Teilausschnitte dieser Modelle

• a)Strukturdiagramme
• -Klassendiagramm
• -Objektdiagramm
• -Paketdiagramm

• b)Verhaltensdiagramm
• -Anwendungsfalldiagramm
• -Aktivitätsdiagramm
• -Zustandsdiagramm
• -Sequenzdiagramm

• -Klassenmodell beschreibt, welche Klassen existieren & in welchen Beziehungen sie zueinander stehen
• -Klassen werden als Rechtecke dargestellt
• -beinhaltet Attribute + Eigenschaften
• -Assoziationen in Form von Verbindungen
• -Pfeilform mit Richtung
• -Komposition (unabdingbare Eigenschaft)
• -Aggregation (leer) Eigenschaft
• -Abstrakte Klasse kursiv, Oberklasse, bleibt leer

• -im laufenden System konkret agierende Einheit
• -Objekt ist ein Exemplar einer Klasse
• -kann Nachrichten empfangen & besitzt dafür Operationen
• -beginnt mit Kleinbuchstaben
• -für einen limitierten Zeitabschnitt
• -Momentaufnahme

• -bestimmte Sicht auf die Strukturen des modellierten Systems
• -Schichtung aufgezeigt
• -Pfeil = Vererbung
• - gestrichelter Pfeil = Abhängigkeit

• -Verhaltensdiagramm
• -keine Ablaufbeschreibung
• -welche Fälle der Anwendung können eintreten
• -Anwendungsfälle in Ellipsen
• -Personen als Strichmännchen, können auch außerhalb des Rechtecks sein
• -großes Rechteck als Ganzes
• -Rechteck als Systemgrenzen

• -endliche Automaten, Protokollzustand
• -Zustände des Systems
• -abgerundetes Rechteck
• -mit Start und Endpunkt
• -Raute ist Kontrollpunkt
• -entity behavior
• -exit behavior
• -do behavior
• -event behavior

• -bestimme Sicht auf dynamische Dinge
• -Ablauf eines Anwendungsfalls
• -Spaghetti

• -Austausch von Nachrichten zw. Ausprägungen
• -einen Weg durch Entscheidungsbaum

• -bündelt alle möglichen Szenarien
• -beschreibt was inhaltlich beim Versuch der Zielerreichung passieren kann
• -kann Erfolg oder Fehler/Abbruch sein

• 1. Name
• 2. Beschreibung
• 3.Akteure
• 4.Status
• 5.verwendete Fälle
• 6.Auslöser
• 7.Vorbedingungen
• 8.Invarianten
• 9.Nachbedingungen
• 10.Standardablauf
• 11.Alternative
• 12.Zusatzhinweise
• 13.Änderungsgeschichte

• -Im Mittelpunkt steht das selbstorganisiertes Entwicklerteam -->ohne Projektleiter, agile SW
• -es gibt aber SCRUM - Master, Methodenfachmann
• -SCRUM - Master ist Schnittstelle zum Product Owner

• -Anforderungen, priorisieren, definieren(tauschen)
• -2-4 Wochen "Sprints" Entwicklerteam darf nicht gestört werden
• -Währen Sprint werden Ideen ins Product Backlog eingetragen um kommende Sprints einzutragen

• -15 Minuten
• -Was habe ich seit letztem Daily SCRUM getan?
• -Das hat mich behindert
• -Was tue ich bis zum nächsten Daily?
• -Sprint Review, Sprint Retrospektive
• -Informationsaustausch

• -am Ende des Sprints, Product Backlog anpassen?
• -Ergebnisse präsentiert, Überprüfung der Sprint Zeit
• -Nächstes Ziel

• -Überprüft Arbeitsweise
• -gute Praktiken und/oder Verbesserung
• -Tabelle:
• good
• could have been better
• Improvement

• -soll Ergebnis eines Sprints sein
• -implementiert, getestet, Richtlinien, dokumentiert
• - "Definition of done"