Post on 13-Jul-2020
Grundlagen der Softwaretechnik
Prof. Dr. Kurt SchneiderFachgebiet Software Engineering
Systematisch erfolgreiche Software entwickeln
Vorlesung im Wintersemester 2019/2020
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 2 SWT WS19/20 - 2Kurt Schneider, Leibniz Universität Hannover
Kurzvorstellung: Kurt Schneider
• Informatik-Studium: Universität Erlangen
• Promotion in Software Engineering: Univ. Stuttgart
• Postdoktorand: University of Colorado at Boulder, USA
• Industrieforschung: Daimler AG, Forschungszentrum Ulm
• Professor für Software Engineering, LUH– 2007-2011 Studiendekan Informatik– 2015-2017 Dekan der Fakultät ET+INF
– Gastaufenthalte im Ausland• OpenUniversity, Milton Keynes, England• Technical Research Center of Finland (VTT), Oulu• BTH Karlskrona, Schweden• Fondazione Bruno Kessler, Trento, Italien
– Kooperationen mit Unternehmen u. internat. Forschern
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 3 SWT WS19/20 - 3Kurt Schneider, Leibniz Universität Hannover
Bedeutung von Software
• Welche Software nutzen Sie?
• Welche großen Softwaresysteme kennen Sie?
• Software ist im allgemeinen Bewusstsein:– Windows, Facebook, Google– Amazon, Ebay– StudIP, QIS, Smartphones
– Intelligente Robotik, Magnet-Resonanz-Tomograph (MRT)– Flugleitsysteme, Marsmissionen– Börsensoftware, Hochfrequenzhandel
– Ja, auch: Toll-Collect, Abgassteuerung, Gesundheitskarte …Aus: Johanning, Mildner: CarIT kompakt, Springer, 2015
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 4 SWT WS19/20 - 4Kurt Schneider, Leibniz Universität Hannover
Riesige Software-Systeme
• Telefonvermittlungssoftware EWSD (Version 8.1):12,5 Mio. Code-Zeilen ca. 6000 Personenjahre
• ERP-Software SAP R/3 (Version 4.0) ca. 50 Mio. Code-Zeilen
• Gesamtumfang der verwendeten Software (Anfang 2000):
– Credit Suisse 25 Mio. Zeilen – Chase Manhattan Bank: 200 MLOC– Citicorp Bank: 400 MLOC
– Telefonie AT&T: 500 Mio. LOC– General Motors: 2 Mrd. Code-Zeilen
Quelle: Prof. Uwe Aßmann, TU Dresden
Vorlesung Softwaretechnologie
Figure taken from the Goose Reengineering Tool, analysing a Java class system [Goose, FZI Karlsruhe, http://www.fzi.de]
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 5 SWT WS19/20 - 5Kurt Schneider, Leibniz Universität Hannover
Wie kann man sich das vorstellen?
Quelle:„Code City“
Michele Lanza
REVEAL Research groupFaculty of InformaticsUniversity of Lugano
https://www.google.com/search?q=code+city+lanza&client=firefox-b-ab&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiouLvbnPLdAhVF6qQKHfhJBsYQ_AUIDigB&biw=1376&bih=763#imgdii=B1lDITcIJF9WLM:&imgrc=YZ6Yv0E7xuF_-M:
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 6 SWT WS19/20 - 6Kurt Schneider, Leibniz Universität Hannover
Was wäre, wenn …
• Heute die gesamte SW ausfiele
• Oder jedes Programm erkennbar mehr Fehler hätte
• Oder – noch schlimmer - wir nicht wüssten, ob es so ist
Informatik hat eine Verantwortung:Wir hier müssen verantwortlich handeln
und unseren Beitrag leisten, damit man es verantworten kann,
SW in kritischen Bereichen einzusetzen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 7 SWT WS19/20 - 7Kurt Schneider, Leibniz Universität Hannover
Anspruch der Veranstaltung
Lernziele von SWT (Vorlesung und Übungen):
• Sie können in einem Softwareprojekt sinnvoll mitarbeiten und sind auf zukünftige Entwicklungen vorbereitet
– Sie kennen die Prinzipien des Software Engineering– Sie können anderen erklären, wie sie umgesetzt werden – Sie wissen, wie traditionelle u. agile Methoden prinzipiell funktionieren
– Sie achten beim Programmieren auf Verständlichkeit– Sie wissen, wie wichtig Testen ist und tun es auch– Sie setzen fortgeschrittene Techniken (wie Design Patterns) ein– Sie kennen grundlegende Verfahren der Projektplanung
• Sie lernen hier dagegen nicht– Grundlagen des Programmierens: Java (Basics) ist vorausgesetzt – Irgendein kommerzielles Werkzeug zu bedienen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 8 SWT WS19/20 - 8Kurt Schneider, Leibniz Universität Hannover
SWT im Studienplan
Vorlesung
Grundlagen der Softwaretechnik
(SWT)
Vorlesung, Übung
Programmieren
Vorlesung
Algorithmen und Datentrukturen
Weitere Vorlesungen
Theorie usw.
VorlesungenSoftware-Qualität
LaborXPlab
LaborFortgeschritt. SWP
LaborUElab
LaborAPPlab
Projekt
Software-Projekt
VorlesungRequirements Eng.
VorlesungModerne SW-
Entwicklungsmethoden
Ber
uf
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 9 SWT WS19/20 - 9Kurt Schneider, Leibniz Universität Hannover
Organisatorisches und Material
• Sie erhalten:– Die Folien, ein Dokument mit Erklärungen dazu, ein Spezifikationstemplate– Übungsaufgaben, Teamaufgaben– Wir verwenden StudIP zum Verteilen der Materialien und für Nachrichten– Auch Bonuspunkte werden in StudIP angezeigt (eigene Datei)
• Klausur SWT– Geplant: Mi., 12.2.2020, 17:00 Uhr (75 Min.), Räume E 415, E 214, E 001
Irrtum und Änderungen vorbehalten
Lesen Sie kurz vorher www.se.uni-hannover.deUnd in den offiziellen Listen der Fakultät
• Übungen: Beginnen am 28.10.19 (immer dasselbe Thema pro Woche)– Oliver Karras ( Oliver.Karras@inf.uni-hannover.de )– Nils Prenner ( Nils.Prenner@inf.uni-hannover.de )
– Beachten Sie die Übungszeiten!
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 10 SWT WS19/20 - 10Kurt Schneider, Leibniz Universität Hannover
Teamaufgaben
• Manche realistischen Aufgaben dauern etwas länger:1. Vollständige Spezifikation schreiben2. Software-Entwurf mit Design Patterns in UML erstellen3. Agil arbeiten mit User Stories und Task-Board
• Das sollen Sie dementsprechend bearbeiten:– Sie erhalten dafür Zeit am Ende der Übungsgruppen– In Teamarbeit: Sie dürfen und sollen sich helfen (ca. 4 Personen)– Sie können pro Teamaufgabe einen Klausurpunkt erhalten
– Machen Sie mit!• Bringt Punkte• Wird in der Klausur vertieft abgefragt• Brauchen Sie im SWP (5. Semester) ganz konkret• Brauchen Sie später im Beruf
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 11 SWT WS19/20 - 11Kurt Schneider, Leibniz Universität Hannover
Ziel: Professionelle Softwareentwicklung
http://www.csss.cs.ubc.ca/files/images/DSCN2559.preview.jpg(29.9.06)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 12 SWT WS19/20 - 12Kurt Schneider, Leibniz Universität Hannover
Wieso „Software Engineering?“
• Hardware wurde um 1960 immer billiger und besser– Speicher wird größer, schneller, billiger– Rechner auch– Netzwerke auch
• Software kann nicht mithalten → „Produktivitätsgap“– Denn Software entsteht im wesentlichen „im Hirn“– Das wächst nicht so schnell wie Chips und Speicher
• Verzahnung mit Wirtschaft und Gesellschaft– Immer mehr Software in allen Bereichen– steigende Komplexität– wachsende Lebensdauer– größere Technologiesprünge
SW=Risiko+Chance
Muss man systematischangehen, nicht zufällig
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 13 SWT WS19/20 - 13Kurt Schneider, Leibniz Universität Hannover
Kurze Geschichte des Software Engineering
• Vision: ingenieursmäßig vorgehen, auch bei Software !– Verklärung des Ingenieurs
• Bei Hardware klappt es so gut, wie bei Brücken und Häusern
– Aber Software ist anders• SW ist immateriell nur Entwicklung, keine Fertigung• SW hat unstetiges Verhalten Testen viel schwieriger• universelles Material für alle möglichen Anwendungen• amorphes Material keine implizite Struktur• SW-Entwickler überschätzen sich regelmäßig
– Ziel: SW genauso gut in den Griff kriegen wie HW
• F.L. Bauer, NATO Science Conference, Garmisch-Partenkirchen 1968„Anwendung von Ingenieursprinzipien für zuverlässige SW, die auf realen Rechnern läuft und mit wirtschaftlichen Mitteln erstellt wird.“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 14 SWT WS19/20 - 14Kurt Schneider, Leibniz Universität Hannover
Der Beginn: NATO Science Conferencein Garmisch-Partenkirchen 1968
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/
Der Begriff „Software Engineering“wird geprägt
Prof. F.L. Bauer
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 15 SWT WS19/20 - 15Kurt Schneider, Leibniz Universität Hannover
„Ingenieursprinzipien“
„A systematic, disciplined, quantifiable approach to the development, operation, and maintenance of X“
Konsequenzen– Kostendenken
• Kein Perfektionismus
– Qualitätsbewußtsein • „es läuft“ reicht nicht
– Anwendung von Normen und Regeln • keine Künstler
– Probleme durch Zerlegung lösen• „divide et impera“
– Baugruppen und Wiederverwendung• statt „not invented here
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 16 SWT WS19/20 - 16Kurt Schneider, Leibniz Universität Hannover
SW-Entwicklung
Softwareentwicklung planenund modellieren
Computer/Ressource
Person
7300Day One
7200Info-Material
12
a: BedienkonzeptEntwickeln (3)
3
b: KassiererschulungErarbeiten (3)
4d: InfomaterialEntwickeln (3)
e: Infomaterialverteilen
(1)
5
c: Kassierer-Schulung
halten(2)
6f: erster Tagoperativ
(1)
03
6
6
9/9
/8/7
/6
/3
/4
/0
7 8
Plan
Phase
Projekt-definition
Abfolge
Rolle
Anforderungs-erhebung
Codierung
Aktivitäten
Dokument
Handbuch
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 17 SWT WS19/20 - 17Kurt Schneider, Leibniz Universität Hannover
SW-Entwicklung
Modelle sind Voraussetzung für Planung
Rolle
Computer/Ressource
Dokument
Person
7300Day One
7200Info-Material
12
a: BedienkonzeptEntwickeln (3)
3
b: KassiererschulungErarbeiten (3)
4d: InfomaterialEntwickeln (3)
e: Infomaterialverteilen
(1)
5
c: Kassierer-Schulung
halten(2)
6f: erster Tagoperativ
(1)
03
6
6
9/9
/8/7
/6
/3
/4
/0
7 8
Plan
Phase
Projekt-definition
Abfolge
Anforderungs-erhebung
Codierung
Aktivitäten
Handbuch
Modell
Original
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 18 SWT WS19/20 - 18Kurt Schneider, Leibniz Universität Hannover
Grundbegriff „Modell“ – für Ihr ganzes Studium
• Fragen zu Charakterisierung und Verständnis– Was ist das Original?– Modell für wen?– Modell zu welchem Zweck (welche Operationen)?– Welche Eigenschaften sind dafür relevant?
Original Modell
Relevante Eigenschaften
PräterierteEigenschaften
AbundanteEigensch.
Modell-Abbildung
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 19 SWT WS19/20 - 19Kurt Schneider, Leibniz Universität Hannover
Zentrale Begriffe für die Vorlesung
• Software (SW)– Computer programs, procedures and possibly associated
documentation and data pertaining to the operation of a computer system (IEEE Std 610.12 - 1990)
• Bemerkungen: „Computer system“ im weiteren Sinn: embedded
• Software Engineering (SE)(1)the application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application of engineering to software
(2) the study of approaches as in (1) (IEEE Std 610.12 - 1990)
• offenbar ist also Engineering: „ a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of X“
• Parnas: „SE erst ab 2 Personen und 2 Versionen“
• Softwaretechnik (SWT): hier als Synonym für „Software Engineering“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 20 SWT WS19/20 - 20Kurt Schneider, Leibniz Universität Hannover
• Motivation: Software Engineering und die Ziele
• Rückschau: Jeder Ansatz im Zusammenhang; Mischungen
Aufbau der Vorlesung
Agiler Ansatz
Was als „agile Methoden“
oder SCRUM heute in den meisten
Unternehmen (angeblich)
praktiziert wird.
Traditioneller Ansatz
Was man bis ca. zum Jahr 2000
überall getan oder versucht hat
Prinzipien des Software Engineering
Was man in jedem Ansatz
umsetzen sollte
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 21 SWT WS19/20 - 21Kurt Schneider, Leibniz Universität Hannover
Zeitschiene des SE
• 1968 Einführung des Namens „Software Engineering“• 1972 Information Hiding Parnas• 1972 C Kernighan/Ritchie• 1979 Wasserfallmodell Royce• 1985 RCS Konfigurationsmanagement Tichy• 1986 V-Modell• 1990 UML• 1994 Design Patterns Gamma• 1999 XP Beck• 1995 SCRUM• 1995 Java SUN• 1996 Service-Oriented Architecture• 2001 Agile Manifesto• 2008 Android
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 22 SWT WS19/20 - 22Kurt Schneider, Leibniz Universität Hannover
Durchbrüche des SE in der Vorlesung
• 1968 Einführung des Namens „Software Engineering“• 1972 Information Hiding Parnas• 1972 C Kernighan/Ritchie• 1979 Wasserfallmodell Royce• 1985 RCS Konfigurationsmanagement Tichy• 1986 V-Modell• 1990 UML• 1994 Design Patterns Gamma• 1999 XP Beck• 1995 SCRUM• 1995 Java SUN• 1996 Service-Oriented Architecture• 2001 Agile Manifesto• 2008 Android
Wird in der Vorlesung besprochen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 23 SWT WS19/20 - 23Kurt Schneider, Leibniz Universität Hannover
Prinzipien des Software Engineering
Systematisch arbeiten
Anforderungen wirksam berücksichtigen
Struktur entwerfen mit Information Hiding
Verständlich Programmieren
Prüfen und Qualität hochhalten
Fortschritt schätzen
Angemessene Planung und Management
Bewusst mit Risiken umgehen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 24 SWT WS19/20 - 24Kurt Schneider, Leibniz Universität Hannover
Gliederung
Einführung: heute
Die Prinzipien des SE und ihre Umsetzung1. Systematisch arbeiten2. Anforderungen wirksam berücksichtigen3. Struktur entwerfen mit Information Hiding4. Verständlich Programmieren5. Prüfen und Qualität hochhalten6. Fortschritt schätzen7. Angemessene Planung und Management8. Bewusst mit Risiken umgehen
ZusammenfassungAusblick
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 25 SWT WS19/20 - 25Kurt Schneider, Leibniz Universität Hannover
• Motivation: Software Engineering und die Ziele
• Rückschau: Jeder Ansatz im Zusammenhang; Mischungen
Aufbau der Vorlesung
Agiler Ansatz
– Agile Manifesto– SCRUM– eXtreme
Programming– Test-Driven Dev.– …
Traditioneller Ansatz
– Ingenieursmäßig– Wasserfallmodell– Reifegrade– Spezifikation– Verträge– …
Prinzipien
Systematisch arbeitenAnforderungen berücksichtigen
Struktur entwerfen mit Information Hiding
Verständlich Programmieren
Prüfen und Qualität hochhalten
Fortschritt schätzenAngemessene Planung
und ManagementBewusst mit Risiken
umgehen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 26 SWT WS19/20 - 26Kurt Schneider, Leibniz Universität Hannover
Hinweise auf den Folien
• Prinzipien sind grau hinterlegt
• Auf eigenen FolienGehört zum
TraditionellenAnsatz
Gehört zumAgilenAnsatz
Folien ohne Randfärbung sind allgemeiner Natur
Sind in beiden Ansätzen einsetzbar
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 27 SWT WS19/20 - 27Kurt Schneider, Leibniz Universität Hannover
Der traditionelle Ansatz
• Geprägt durch die NATO Science-Conference 1968
• Leitbild „Ingenieur“
• Wichtige Tätigkeiten dokumentieren, dadurcherfolgreich wiederholen
• Vorschriften u. Templates
• Dokumentieren, prüfen und unterschreiben
• Gut vorarbeiten, um späte Änderungen zu vermeiden
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 28 SWT WS19/20 - 28Kurt Schneider, Leibniz Universität Hannover
Systematisch arbeiten (1970er)
• Problem/Situation– Jedes Projekt fühlt sich neu an– Man kann wenig aus den alten Projekten lernen– Man vergisst viel; neue Kollegen machen die gleichen Fehler– Unklar: Was passiert da eigentlich?– Unklar: Womit sollte man im Projekt anfangen?
• Idee: Also schreiben wir doch einmal auf, was wir tun!– So abstrakt, dass es für mehrere Projekte gilt– So genau, dass es mir im nächsten Projekt hilft– Das diskutieren und verbessern wir– Dabei kommen evtl. Varianten heraus Das
Wasserfall-Modell!
Winston W. Royce
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 29 SWT WS19/20 - 29Kurt Schneider, Leibniz Universität Hannover
Wasserfallmodell nach Royce
Rücksprünge
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 30 SWT WS19/20 - 30Kurt Schneider, Leibniz Universität Hannover
Wasserfallmodell, fortgeschrittener Teil
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 31 SWT WS19/20 - 31Kurt Schneider, Leibniz Universität Hannover
Der Agile Ansatz
• Kundenzufriedenheit ist das Wichtigste– Wenn das späte Änderungen erfordert: ok
• Änderungen billiger machen– technisch und organisatorisch
• Direkte Kommunikation fördern
• Agieren – Reflektieren – besser machen
• Wenig Bürokratie, nur kurzfristige Planung
• Wenige Dokumente: travel light
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 32 SWT WS19/20 - 32Kurt Schneider, Leibniz Universität Hannover Taken from http://www.controlchaos.com/
SCRUM: Verschränkte Zyklen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 33 SWT WS19/20 - 33Kurt Schneider, Leibniz Universität Hannover
SCRUM-Idee: „Im Team“ vs. „außen“
• Ziel: Schnell, flexibel, wenig Aufwand. Kunde zufrieden.
• (Hidden goal: nicht alles auf einmal ändern)
• SCRUM: Entkoppelung zwischen Innen und Außen– Innen: Im Projektteam; Außen: alles andere– Product-Owner organisiert Backlog (außen)– Team innen übernimmt Sprint-Backlog davon– Dann ist erst einmal Ruhe, Team arbeitet innen– Team kann nach außen kommunizieren, muss aber nicht– Tätigkeit im Team ist nicht von SCRUM festgelegt
– Kontakt mit Außen: Nach dem Sprint oder bei (Innen-) Bedarf
Backlog
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 34 SWT WS19/20 - 34Kurt Schneider, Leibniz Universität Hannover
SCRUM Master
SCRUMRoom
SCRUM team 7+/-2
ProductBacklog
(priorisiert)
Product Owner
SPRINT: 30 days
Andere
Daily SCRUM15 min.
SPRINTBacklog
Increment
SCRUM1
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 35 SWT WS19/20 - 35Kurt Schneider, Leibniz Universität Hannover
Gliederung
Einführung
Die Prinzipien des SE und ihre Umsetzung1. Systematisch arbeiten2. Anforderungen wirksam berücksichtigen3. Struktur entwerfen mit Information Hiding4. Verständlich Programmieren5. Prüfen und Qualität hochhalten6. Fortschritt schätzen7. Angemessene Planung und Management8. Bewusst mit Risiken umgehen
ZusammenfassungAusblick
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 36 SWT WS19/20 - 36Kurt Schneider, Leibniz Universität Hannover
Systematisch arbeitenPrinzip
• System – Besteht aus Einheiten (SW, Personen, Dokumenten usw.)– und Beziehungen (Abhängigkeiten) dazwischen
• Systematisch– Nach klaren Regeln arbeiten– Das ganze System bedenken (nicht nur Ausschnitt)
• Systematisch arbeiten– Alle wichtigen Tätigkeiten in der SW-Entwicklung– … systematisch durchführen, nicht ad-hoc
• Vorteil: – Softwareentwicklung wird erlernbar– Ist nicht vom Zufall und von Einzelnen abhängig
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 37 SWT WS19/20 - 37Kurt Schneider, Leibniz Universität Hannover
Vorgehensweisen aufzeichnen, weitergebenProzesse und Prozessmodelle
Aktivitäten und Abläufe
Heute anerkannt:
Der traditionelle Ablauf
Analyse(Anford.) Entwurf Codierung Integration Betrieb
Code&fix: so nicht!
Codierung Codierung CodierungFix Fix
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 38 SWT WS19/20 - 38Kurt Schneider, Leibniz Universität Hannover
Beispiel für eine sinnvolle Variante
Prototyping – auch davon gibt es noch Unter-Varianten
Analyse(Anford.) Codierung
Integration Betrieb
EntwurfAnalyse(Anford.) Codierung
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 39 SWT WS19/20 - 39Kurt Schneider, Leibniz Universität Hannover
Grundlegender Entwicklungsprozess„Der (einfache) traditionelle Entwicklungsprozess“
• Diese Aktivitätenund Dokumentartenmuss man kennen
• Später kann man einiges variieren
Fein-entwurf
Code
Test-pläne
Benutzer-Handbuch
Dokumente sind Teil von „Software“ (vgl. IEEE-Def)
TechnischeDoku-
mentation
Roll-Out-Plan
BetriebIntegra-tion
Codie-rungEntwurf
Lasten-heft
Pflichten-heft
Analyse(Anford.)
Grob-entwurf
Test
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 40 SWT WS19/20 - 40Kurt Schneider, Leibniz Universität Hannover
V-Modell 97
Test-pläne
Benutzer-Handbuch
TechnischeDoku-
mentationRoll-Out-
Plan
BetriebIntegra-tion
Code
Codie-rung
Lasten-heft
Pflichten-heft
Analyse(Anford.)
Fein-entwurf
Entwurf
Grob-entwurf
Test
Ein weithin bekanntes Entwicklungsmodell
Abs
trak
tions
nive
au
Zeit
DokumentartDokum.-
Art =Leicht andere Modellsyntax:
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 41 SWT WS19/20 - 41Kurt Schneider, Leibniz Universität Hannover
Software
V-Modell 97kennt jede/r in der Praxis
• Anwenderforderungen [System]• Systemarchitektur• Technische Anforderungen• Schnittstellenübersicht• Schnittstellenbeschreibung• Integrationsplan• SWPÄ [Roll-out plan]
• SW Architektur• SW Entwurf• Datenkatalog [data dictionary]• Implementierungsdokumente• (mehr in anderen Submodellen)
• Info. zum Anwendungshandbuch• Info. zum Diagnosehandbuch• Info. zum Betriebs-Handbuch
SoftwareQuelle: www.v-modell.iabg.de
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 42 SWT WS19/20 - 42Kurt Schneider, Leibniz Universität Hannover
Schematisierte Darstellung
System-Anforderungen
System-Entwurf
Freigabe
SystemintegrationSystemtest
Software-Integration
Integrations-test
Software-Anforderungen
Software-Design/Arch.
Review
Review
Review
ReviewReview
Implementierung
Modultest
In diesem Modell relevant: Die Ebenen des Testens (blau)
Beginntbeim System
Software istunser Fokus
Integrieren undTesten
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 43 SWT WS19/20 - 43Kurt Schneider, Leibniz Universität Hannover
Planbarer arbeiten (1990er)
• Problem/Situation– Immer mehr SW ist nötig– Immer mehr Leute müssen sie schreiben– Wissen und Erfahrung fehlen– Fehler haben gravierende Folgen– Man wünscht sich mehr Vorgaben; eigentlich: mehr Hilfe
• Idee: Wir regeln möglichst viel, SW wie nach Kochrezept– Die Aktivitäten werden genauer unterteilt– Alle denkbaren Dokumente und „Deliverables“ definiert– Prüfungen explizit eingezeichnet– V-Modell wird vorgeschrieben
• Für alle Projekte bei Bundesministerien– Verwaltung des V-Modells: iabg– Jahrzehnt der Reifegradmodelle
CMM !
www.v-modell.iabg.de
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 44 SWT WS19/20 - 44Kurt Schneider, Leibniz Universität Hannover
CMM - Capability Maturity Model
• Entwickelt seit 1987 – SEI (Software Engineering Institute) – Carnegie Mellon University (CMU) – Im Auftrag des DoD (US Verteidigungsministerium)
• Ziel: Bewertung von Softwarelieferanten über Referenzmodell– Nicht Prozess vorschreiben,– Sondern Reife eines (beliebigen) Prozesses– (Aber: CMM schreibt NICHT das Wasserfallmodell vor!)
• Vorgehen: Einordnung in 5-stufige Skala (CMM-Level)– Vergleichbar– Verständlich für viele Stakeholder (Management, Entwickler)– Fortschritt sichtbar
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 45 SWT WS19/20 - 45Kurt Schneider, Leibniz Universität Hannover
Qualität von EntwicklungsprozessenWas ist und wie misst man Prozessreife?
Das Capability Maturity Model (CMM)
1
initialChaotischer Zustand;
Erfolg hängt aneinzelnen “Helden”;
Feuerwehreinsätze sind an der Tagesordnung
2
repeatable Prozesse auf Projektebenebeschrieben. Erfolg hängt noch an
Individuen, aber bessere Unterstützung
3
definedPersonen können sich auf eingespielte Prozesse stützen; integrierte Prozesse projektübergreifendProbleme werden vorhergesehen und vermieden
4
managedProzesse stabil undquantitativ im Griffechtes Teamwork
5
optimizingvorausschauendeSteuerung und
InnovationRequirements Management
ProjektplanungProjektverfolgung und -überblick
LieferantenmanagementQualitätssicherung
Configuration Management
Sicherheit
Ris
iko
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 46 SWT WS19/20 - 46Kurt Schneider, Leibniz Universität Hannover
Wahrscheinlichkeit
Schätzwert
Projektdauer, Projektkosten
Schätzwert
Leve
l 1
Wahrscheinlichkeit
Projektdauer, Projektkosten
Leve
l 2
Istwert
Istwert
Was sich auf höheren Ebenen ändert
• Veränderung der Vorhersagegenauigkeit
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 47 SWT WS19/20 - 47Kurt Schneider, Leibniz Universität Hannover
Die Auswirkungen reiferer Prozesse
Carnegie Mellon University, Software Engineering Institute (1995): The Capability Maturity Model, Addison Wesley
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 48 SWT WS19/20 - 48Kurt Schneider, Leibniz Universität Hannover
Traditionelle Softwareentwicklung
Stärken +– Systematisch,
nachvollziehbar– Gut dokumentiert– Saubere Spezifikation– UML-Modelle– Projektziele früh klar– Detaillierte Planung,
Vorgaben, Abläufe
Probleme -– Relativ langsam– Viel Aufwand– Dokumente veralten oft,
bevor man sie braucht– Anforderungen oft
missverstanden– Änderungen aufwändig
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 49 SWT WS19/20 - 49Kurt Schneider, Leibniz Universität Hannover
Systematisch agil arbeiten
• Auch systematisch, aber nacheinem anderen System
• Vorher überlegen, was zu tun ist
• Nicht Prozesse, sondern Praktiken
• Auch hier: Wissen, Können und Erfahrungen weitergeben
• Auch hier: Nicht zu sehr von Einzelnen abhängen
• Aber: Nicht auf Dokumentation setzen, sondern auf Interaktion
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 50 SWT WS19/20 - 50Kurt Schneider, Leibniz Universität Hannover
Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. “
Kent Beck, Alistair CockburnMartin Fowler, Jim Highsmith, Ron Jeffries
Ken Schwaber und 11 andere
www.agilemanifesto.org
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 51 SWT WS19/20 - 51Kurt Schneider, Leibniz Universität Hannover
Konspirativ präsentiert: Agile Alliance
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 52 SWT WS19/20 - 52Kurt Schneider, Leibniz Universität Hannover
Inkrementelles EntwicklungsmodellPrinzip Einfachheit
• Entwicklung in Bausteinen (Inkrementen)• Grobe Vision (Master-Plan)• Spätere Inkremente nicht detailliert• Jeweils ein Inkrement genauer• Kurze Inkremente, zusammengesetzt
• Versetzte Entwicklungsstränge• Jedes Inkrement für sich vollwertig einsetzbar• Von vornherein als Ausbaustufen vorgesehen • Relativ unabhängig während der Entwicklung
• Time Boxing: immer im gleichen Zeittakt
Gesamtsystem
Master-Plan
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 53 SWT WS19/20 - 53Kurt Schneider, Leibniz Universität Hannover
Kurze Release-ZyklenPrinzip Einfachheit
• Ziel: Häufiges Feedback durch den Kunden– Operative Nutzung der Inkremente (nicht nur Prototypen!)– Aufteilung in Teillieferungen scheint schwierig – geht aber meist
• Begriffsklärung– „Release“ = „Inkrement“ = Auslieferung zur operativen Nutzung– Dazwischen Iterationen: auch lauffähig, gehen nicht an Kunden
• „Saubere Spezifikation für alles ist besser“ – stimmt das?– ist aber oft nicht zu erreichen– Kostet so viel Aufwand, dass keine Zeit für Umsetzung bleibt– Veraltet, bevor Projekt zu Ende ist
• Selbst bei Projekt-Abbruch ist schon Nützliches entstanden
… wenn man das Wichtigste zuerst macht!
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 54 SWT WS19/20 - 54Kurt Schneider, Leibniz Universität Hannover
Agile PrinzipienAuswahl
• Höchste Priorität: Kundenzufriedenheit– durch frühe und häufige Auslieferung laufender Software
Enge Kundeneinbindung, Planungssitzung
• Einfachheit ist wichtigstes Konstruktionsprinzip– Möglichst wenig unnötige Arbeit, nicht auf Vorrat arbeiten
Inkrementelle Entwicklung, kurze Releases, wenig Dokumente
• Auch späte Änderungen werden willkommen geheißen– Änderungen bedeuten Verbesserungen für den Kunden
Ständig testen, integrieren, vereinfachen; Pair Programming
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 55 SWT WS19/20 - 55Kurt Schneider, Leibniz Universität Hannover
Systematisch arbeiten, aber mit einem anderen SystemSCRUM: die zurzeit bekannteste agile MethodeeXtreme Programming: nahe an der EntwicklungGrundideen, Bestandteile und PraktikenZusammenhänge und Abhängigkeiten
SCRUM und XP
Schwerpunktthema
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 56 SWT WS19/20 - 56Kurt Schneider, Leibniz Universität Hannover
SCRUM-Idee: „Im Team“ vs. „außen“
• Ziel: Schnell, flexibel, wenig Aufwand. Kunde zufrieden.
• (Hidden goal: nicht alles auf einmal ändern)
• SCRUM: Entkoppelung zwischen Innen und Außen– Innen: Im Projektteam; Außen: alles andere– Product-Owner organisiert Backlog (außen)– Team innen übernimmt Sprint-Backlog davon– Dann ist erst einmal Ruhe, Team arbeitet innen– Team kann nach außen kommunizieren, muss aber nicht– Tätigkeit im Team ist nicht von SCRUM festgelegt
– Kontakt mit Außen: Nach dem Sprint oder bei (Innen-) Bedarf
Backlog
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 57 SWT WS19/20 - 57Kurt Schneider, Leibniz Universität Hannover
Zentral: Product Backlog
• Idee: Stapel von „User Stories“– Ein Stapel kleiner, jeweils nützlicher Feature-Beschreibungen– Jedes Feature enthält alle Teile, DB bis GUI usw.– Aber so einfach wie möglich
– WICHTIG: muss nach Nutzen-für-Kunden sortiert sein!– Dafür ist der Kunde zuständig
• Handling– Kunde schreibt, oft von Entwicklern unterstützt– Entwickler schätzen relativen Aufwand– Kunden sortieren nach Nutzen – unter Berücksichtigung des
Aufwands– PO (Product Owner) managed „die Kunden“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 58 SWT WS19/20 - 58Kurt Schneider, Leibniz Universität Hannover
User Stories
• Es gibt Varianten, SCRUM schreibt keine davon vor– Am einfachsten: Unstrukturierter DIN A4-Zettel
• „Die SW liest alle geleisteten Arbeitsstunden ein und erstelltein Balkendiagramm, sortiert nach Bearbeiter“
Zu vage.Passt nicht
Einfacher,besser
– Verbreitet, aber nicht unumstritten: User Story-FormulareAls Abteilungsleiter (Rolle) möchte ich das Arbeitsprofil meiner Mitarbeiter bewerten (Funktion), damit ich intervenieren kann (Nutzen).• Damit <Nutzen>, möchte ich als <Akteur> <Funktion-ausführen>
„Damit ich weiß, ob jemand unregelmäßig arbeitet, möchte ich als Abteilungsleiter eine visuelle Darstellung der geleisteten Stunden sehen.“
– Häufig: Grober Ablauf1.Die SW öffnet die Datei Arbeitsstunden.xml und liest Daten ein2.Benutzer kann Person auswählen3.Die Arbeitsstunden dieser Person über die letzten sechs Monate
werden als Säulendiagramm angezeigt
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 59 SWT WS19/20 - 59Kurt Schneider, Leibniz Universität Hannover
Wichtig: Sortierung nach Nutzen
• Klingt gut: User Stories müssen nach Nutzen sortiert sein
• ABER: Jemand muss das sicherstellen. Der Product Owner!
• Machen Sie sich klar:• Es ist die PFLICHT des Product Owners/Kunden,
die User Stories nach dem Nutzen zu sortieren.– Und das immer wieder zu aktualisieren („außen“).
• Tut er es nicht, führt er das Projekt in die Irre
• In der Regel braucht der PO dazu Angaben zum relativen Aufwand der User Stories.
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 60 SWT WS19/20 - 60Kurt Schneider, Leibniz Universität Hannover
SCRUM-Idee: Selbst-Organisation
• Es gibt keinen PL, das Team organisiert sich selbst– Autonomie, Schnelligkeit, keine Bürokratie– 7+/-2 Leute oder Paare
• Treffen sich täglich: Daily SCRUM– Erklären, was sie tun– SCRUM-Master moderiert das– Er hilft auch bei Problemen und nach außen
• Wenige Rollen, die sind aber wichtig– PO: Product Owner (= Backlog Owner)– SCRUM-Master– Entwickler– Oft: Coach
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 61 SWT WS19/20 - 61Kurt Schneider, Leibniz Universität Hannover
Arbeitstagoder auch
Projekt ausSPRINTS
SPRINTmit Backlog und Goal
Koord.mehrerer
Teams mehrere SCRUM-Teams sprinten parallel. Master-SCRUMs
Arbeitstag Ein Arbeitstag:Von SCRUM zu SCRUM
Dailiy SCRUM Nach-Build (15 min.) bespr.
SPRINT Planung
SPRINTReview 3h
SPRINT erzeugt ein Produkt-Inkrement
Zeitaufteilung in SCRUMProjekt-Ziele: Projekt Backlog
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 62 SWT WS19/20 - 62Kurt Schneider, Leibniz Universität Hannover
SCRUM Master
SCRUMRoom
SCRUM team 7+/-2
ProductBacklog
(priorisiert)
Product Owner
SPRINT: 30 days
Andere
Daily SCRUM15 min.
SPRINTBacklog
Increment
SCRUM
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 63 SWT WS19/20 - 63Kurt Schneider, Leibniz Universität Hannover
SCRUM Praktiken (1)Rollen und Backlog
• SCRUM Master (nicht der Projektleiter! )– Zuhören, Probleme identifizieren (im Team)– Hindernisse ausräumen– Entscheidungen treffen – auch unter Unsicherheit
• Product Backlog– Strikt nach Priorität (Nutzen) geordnet– SCRUM startet, sobald Vision und Backlog für einen SPRINT da ist.– Fortschritts-Schätzungen sind wichtig – aber nicht bindend
• SCRUM Team– Ist im Sprint völlig selbst-organisierend: keine Eingriffe!– Spezialisierungen (QS) und Teilzeitkräfte sind möglich
• Daily Scrum– Dauer und Ablauf geregelt; findet täglich am selben Ort statt
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 64 SWT WS19/20 - 64Kurt Schneider, Leibniz Universität Hannover
SCRUM Praktiken (2)
Sprint– Während Sprint ist das Team autonom wie ein Pionier-Trupp
• Keine weiteren Anforderungen• Keine Änderungen• Keine fremden Einflüsse
– Sprint kann abgebrochen werden– Normalerweise nach Abschluss d. Sprint: 4-Stunden Sprint-Meeting
• Lange Vorbereitung verboten (max. 2 Stunden)• Folienvorträge verboten• Meist sehr informell
Anpassungen von SCRUM (längere Sprints, andere Meetings…)– Ist ok; aber erst, wenn es mal gelaufen ist– Nur auf Erfahrungsbasis – nicht ohne Erfahrungen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 65 SWT WS19/20 - 65Kurt Schneider, Leibniz Universität Hannover
Wie steht SCRUM heute da?
• Heute fast synonym: „agil“ und „SCRUM“• Fast immer dabei:
– PO mit Varianten– Product Backlog aus User Stories– SCRUM-Master– Daily Scrum
• Manchmal– Fortschrittsverfolgung (über Aufwand oder Anzahl)– Andere agile Methode (XP) als Innere Vorgehensweise
• SCRUM ist eine Management-Hülle– Innerhalb der Hülle muss letztlich programmiert werden– Wasserfall, Spiralmodell möglich – XP sogar häufig
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 66 SWT WS19/20 - 66Kurt Schneider, Leibniz Universität Hannover
Was ist agil? Struktur agiler Methoden
Grundwerte„change over plan“
Prinzipien
Praktiken(Umsetzung,
sehr bekannt)
Höchste Priorität: Kundenzufriedenheitfrühe und häufig laufende Software
Einfachheitunnötige Arbeit vermeiden
Auch späte Änderungen willkommenbedeuten Verbesserungen für den Kunden
...
Direkte Mensch-zu-Mensch Kommunikation
Beste Möglichkeit zum Informationsaustausch
Regelmäßige Überprüfung und Verbesserung der eigenen Effektivität
Feedback auf mehreren Ebenen
Allgemeine Struktur
Spezifische XP-Prinzipien
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 67 SWT WS19/20 - 67Kurt Schneider, Leibniz Universität Hannover
Weitere XP-Prinzipien
• Über die Prinzipien auf der letzten Folie hinaus– Unmittelbares Feedback– Einfachheit anstreben
• „Vorbeugen wollen“ ist sinnlos • (das lernt man sonst im Studium anders!)
– Inkrementelle Veränderung• Zur Risikominimierung
– Qualitätsarbeit• Will jeder Entwickler leisten - muss man ermöglichen
– Auf Sieg Spielen (Play to Win)• Nicht „Fehler vermeiden“, sondern „Erfolge anstreben“ (trotz Fehlern)• Was nicht mehr gewinnen kann, wird gestoppt
– Mit leichtem Gepäck reisen (Travel Light)• Mehr Hilfsmittel im Rucksack -> Expedition geht langsamer voran
Kent Beck
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 68 SWT WS19/20 - 68Kurt Schneider, Leibniz Universität Hannover
Praktiken von „eXtreme Programming“
On-site Customer
40 hour week
Acceptance Testing
Planning Game
Metaphor
RefactoringSimple Design
Pair Programming
Unit Testing
Short Releases
Continuous IntegrationCoding Standards
Collective Ownership
http://luxusuhren-pro.de/technik/das-mechanische-uhrwerk
Kundeneinbindung
System einfachhalten
Ständiges Testen
Selbstorganisation
Reflexion
Planung
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 69 SWT WS19/20 - 69Kurt Schneider, Leibniz Universität Hannover
Was heißt hier eXtreme?
• Agile Entwickler sind keine Anarchisten
• eXtreme Programming erfordert extreme Disziplin
• Bewährte Praktiken aus der SW-Entwicklung...... werden ins Extrem geführt
• Beispiel: Code-Reviews haben sich bewährt...... daher: Ständige Code-Reviews durch Pair Programming
• Beispiel: (Frühe) Tests haben sich bewährt...... daher: Ständig mehrmals täglich testen…daher: vor dem Implementieren die Testfälle erstellen (Test First)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 70 SWT WS19/20 - 70Kurt Schneider, Leibniz Universität Hannover
Pair Programming
• Metapher: Fahrer und Beifahrer
• Jedes Paar arbeitet an einer Story Card– oder Task Card (Teile einer Story Card)– häufiges Abwechseln der Rollen– möglichst tägliches Tauschen der Paare
• Ständiges Review– Vermeidet vor allem Flüchtigkeitsfehler– Eine(r) schreibt, zweite(r) denkt und kontrolliert– Vier-Augen-Prinzip
• Ständiges Lernen voneinander– Hebt Entwickler kontinuierlich auf ein einheitliches Niveau
• Ist effektiv und effizient– Belegen einige Studien; andere belegen das Gegenteil– es gibt verschiedene Erfahrungen
Pair Programming
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 71 SWT WS19/20 - 71Kurt Schneider, Leibniz Universität Hannover
Pair Programming
• Pair Programming heißt:
Keine Arbeitsteilung, sondern alles gemeinsam!– Tastatur geht schnell hin und her (10 Min)
• Auch die Paar-Zusammenstellung wechselt ständig– Spezialwissen verteilt sich so im Team („Truck-Factor“)– Einheitlicherer Code– Mindestens 50% der Leute müssen „gut“ sein– Das hat aber Grenzen: Spezialisten und Domain-Subteams– Nicht jeder kann Pair-Programmieren
• Sparpotenzial Rechnerkauf?– Allenfalls als Nebeneffekt. – Meist braucht jeder trotzdem einen Arbeitsplatzrechner
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 72 SWT WS19/20 - 72Kurt Schneider, Leibniz Universität Hannover
Pair ProgrammingDiskussion
• Programmieren in Paaren: Auswirkungen– Zwang zur Disziplin (keine emails, keine Telefonate!)– Zwang zur Teamfähigkeit (mit allen können)
• Auch soziale Kontrolle in Stresszeiten– Stärkere Konzentration auf die Aufgabe
– Lerneffekt• Meist erklärt einer (mit der Tastatur), warum er/sie etwas tut• Schlechtere lernen schnell hinzu• Bessere werden aber langsamer
• Nebenwirkungen– Zu viele Paare auf zu engem Raum: schwierig– Aber zwei oder drei sind ok; Beifahrer hören sich gegenseitig
– Mobiliar muss so aufgestellt sein, dass Wechsel einfach ist
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 73 SWT WS19/20 - 73Kurt Schneider, Leibniz Universität Hannover
Pair ProgrammingTipps und Erfahrungen
• Pair Programming lernen– Ist nötig! Es dauert, sich daran zu gewöhnen– Ständiges Feedback: was ist gut gelaufen, was weniger?
• In der Durchführung– Pausen nicht am Arbeitsplatz verbringen; aufstehen, weggehen!– Unterbrechungen minimieren– Konzeptdiskussionen begrenzen– Oft wechseln! Notfalls Story Card zerlegen– Management muss Pair Programming explizit stützen
• Wenn einer sich nicht einfügt– Kann man ihn evtl. nicht zwingen– Möglichst aus dem Team nehmen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 74 SWT WS19/20 - 74Kurt Schneider, Leibniz Universität Hannover
Abhängigkeiten zwischen Techniken(nach Kent Beck)
• S.10• Ein Bild oder sechs Worte „Alles hängt von allem anderen ab“
• „Mit 80% Techniken nur 20% Nutzen!“
(sagt Beck)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 75 SWT WS19/20 - 75Kurt Schneider, Leibniz Universität Hannover
Feedback beim eXtreme Programming (XP)
Release Plan
Iteration Plan
Stand Up Meeting
Pair Negotiation
Unit Test
Pair Programming
Monate
Wochen
Ein Tag
Stunden
MinutenSekunden
Basiert auf Folien von Stefan Roock, it-agile, Hamburg
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 76 SWT WS19/20 - 76Kurt Schneider, Leibniz Universität Hannover
Gliederung
Einführung
Die Prinzipien des SE und ihre Umsetzung1. Systematisch arbeiten2. Anforderungen wirksam berücksichtigen3. Struktur entwerfen mit Information Hiding4. Verständlich Programmieren5. Prüfen und Qualität hochhalten6. Fortschritt schätzen7. Angemessene Planung und Management8. Bewusst mit Risiken umgehen
ZusammenfassungAusblick
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 77 SWT WS19/20 - 77Kurt Schneider, Leibniz Universität Hannover
Anforderungen wirksam berücksichtigenPrinzip
• Anforderungen legen fest, was SW leisten soll
• Gravierendes Problem: Anforderungen oft unterschätzt– Ohne Anforderungen: Kein Ziel, keine Erfolgskontrolle– In der Regel: Auch keine zufriedenen Kunden
• Problem: Anforderungen ändern sich– Wie bekommt man das mit?– Darf man das erlauben?– Wie zieht man die Änderungen nach?
• Vielen Kunden sind ihre Anforderungen gar nicht bewusst
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 78 SWT WS19/20 - 78Kurt Schneider, Leibniz Universität Hannover
Anforderungen traditionell erheben
• Umfangreiche Spezifikation
• Lange und genau Anforderungen erfassen
• Unterschreiben und festschreiben
• Vorlagen für Inhalt, Aufbau der Spezifikation
• Aktivitäten um die Anforderungen beschreiben
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 79 SWT WS19/20 - 79Kurt Schneider, Leibniz Universität Hannover
Wer ist „der Kunde“?
• Grundidee ist einfach: Mit dem Kunden sprechen
• Aber wer ist „Kunde“?• Wer ist betroffen?• Wer soll mitreden?
Nutzer
Käufer
Manage-ment
?
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 80 SWT WS19/20 - 80Kurt Schneider, Leibniz Universität Hannover
„Symmetry of Ignorance“nach Gerhard Fischer
Unverständnis zwischen Informatikern und Kunden führt zu vielen Missverständnissen und zu Frustration
• Kunden/Fach-Leute wissen nicht– was Software leisten kann– was Informatiker können– wovon sie reden (UML)– welche Lösungen möglich wären– dass die Informatiker sie auch
nicht verstehen
? ?
• Informatiker wissen nicht– wie das Geschäft läuft– was Kunden wollen, brauchen– was sie meinen– was das Problem ist– dass sie es nicht wissen
Hinterfragen Sie scheinbare„Selbstverständlichkeiten“
Hüten Sie sich davor zu glauben,Sie wüssten sowieso, was der Kunde will
Unverständnis auf beiden Seiten(„symmetrisch“)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 81 SWT WS19/20 - 81Kurt Schneider, Leibniz Universität Hannover
Abhilfe: Requirements Engineering
Erinnerung – wieder einmal Engineering:„ a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of Requirements“
Konsequenzen auf den Umgang mit Anforderungen– Kostendenken– Qualitätsbewußtsein
• nicht nur subjektiv definiert
– Anwendung von Normen und Regeln • keine Künstler
– Baugruppen und Wiederverwendung• statt „not invented here“
– Probleme durch Zerlegung lösen• „divide et impera“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 82 SWT WS19/20 - 82Kurt Schneider, Leibniz Universität Hannover
Was muss man immer tun, um Anforderungen zu erheben?Welche Arten von Anforderungen gibt es?Wie schreibt man sie auf (Spezifikation)?
Requirements Engineering
Schwerpunktthema
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 83 SWT WS19/20 - 83Kurt Schneider, Leibniz Universität Hannover
Requirements Engineering
Systemanalyse Req. ManagementE
licita
tion
Inte
rpre
tatio
n
Neg
otia
tion
Dok
umen
tatio
n
Valid
./Ver
if.
Cha
nge
Mgm
t.
Trac
ing
Aktivitäten im Requirements Engineering
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 84 SWT WS19/20 - 84Kurt Schneider, Leibniz Universität Hannover
Anforderungen suchen: Elicitation
• „Herauskitzeln“ von Anforderungen• Grober Ablauf
1. Stakeholder herausfinden: wer ist betroffen?2. Umfeld des Systems erheben: Altsysteme, Schnittstellen, Doku.3. Sprechen mit Stakeholdern
• „Sprechen“: Interviews, Workshops, Fragebögen• Beobachtung und Aufzeichnung• Regelrechte Elicitation-Techniken für „tacit knowledge“
• „Rohanforderungen“ müssen danach veredelt werden
• Beispiel Bankomat– Stakeholder: Kunden; die Bank; DB-Admin; Geldbefüller– Schnittstellen: zur DB, zu Schalterauszahlung u. Money-Mgmt.– Sprechen: Interview mit Schalterbeamten, Kundenfragebogen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 85 SWT WS19/20 - 85Kurt Schneider, Leibniz Universität Hannover
Interpretation von Anforderungen
• Die Anforderungen werden inhaltlich bearbeitet– Dazu ist Interpretation (=Zusprechen von Bedeutung) nötig– Diese Interpretation kann falsch sein!
• Spreu vom Weizen trennen– Was ist essenziell, was Nebensache– Was ist wirklich gefordert, was nur Erläuterung
• Ordnen und Sortieren, Strukturieren– Ähnliche Anforderungen zusammen
• Detaillieren und Konkretisieren– Formulierungen schärfen (erfordert Interpretation)– Prüfbar machen
• Beispiel Bankomat– Identifikation: Stornierung ist vor „ok“-Button gefordert, danach nicht mehr– Sortieren: Anford. an die Bedienung; an die Geschwindigkeit; an die Funktion– Konkretisieren: Jede Kontostandprüfung muss in 5 s. fertig und bestätigt sein
1 Identifikation
2 Strukturierung• Verfeinern
• Verschmelzen• Gruppieren
3 Konkretisierung
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 86 SWT WS19/20 - 86Kurt Schneider, Leibniz Universität Hannover
Anforderungen verhandeln: Negotiation
1. Abhängigkeiten identifizieren– Eine Anforderung erzwingt andere.
• Beispiel: Online-Überweisung => Alpha-Tastatur => Sicherheitsanf.– Anforderungen widersprechen sich
2. Widersprüchliche Anforderungen identifizieren– Bsp.: Mächtiges Werkzeug oder billiges Hilfsmittel?– Bsp.: Für Laien oder für Experten optimiert?
3. Konflikt ist üblich: Verhandlungsprozess, Moderation nötig– Es gibt nicht eine objektive Wahrheit, sondern viele Interessen
4. Inkonsistenzen auflösen – oder auch nicht!– Entscheidungsprozess– Selten eine technische Entscheidung– Mit gewissen Widersprüchen kann man leben
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 87 SWT WS19/20 - 87Kurt Schneider, Leibniz Universität Hannover
Dokumentation
• Anforderungen zu hören reicht nicht
• Anforderungen müssen fixiert werden– Und trotzdem ändern sie sich!– Aber nur bei dokumentierten merkt man es
• Anforderungen dürfen sich ändern– Dann muss man nachdokumentieren– Und bezahlen muss das der Urheber (meistens)
• Sehr wichtig: mehr dokumentieren als reine Anforderungen– Gesprächspartner, Rollen, Ziele– Hintergründe und Randbedingungen– Annahmen– Absichten, Rivalitäten, alte Fehlversuche
1 Fixieren
2 Zerlegen inEinzelanforderungen
3 Mit Attributen beschreiben
4 Anforderungenverbinden
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 88 SWT WS19/20 - 88Kurt Schneider, Leibniz Universität Hannover
Beispiel: Verbesserte Noteneinsicht
• Stellen Sie sich vor, es gibt eine Idee:– Noten sollen schon vor Einsichtnahme zu sehen sein– Aber noch nicht freigegeben – kann sich ja noch ändern!
• Daran hängen viele weitere Anforderungen – Von Studierenden– Von Lehrenden– Von Fachschaft– Von Prüfungsamt
• Werden erhoben wie oben beschrieben (Elicitation, Int., …)
FiktivesBeispiel
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 89 SWT WS19/20 - 89Kurt Schneider, Leibniz Universität Hannover
Dokumentation(Auszug)
[R01] Studierende haben Zugang über Name und PINEntscheidungstabelle, in Workshop abgesegnet (Negot.-WS)
[R02] PIN fünfstellig, nicht mit Matrikelnummer korreliertMatrikelnummer steht öffentlich auf Studentenausweis (Dekan)Fünfstellige PINs ausreichend (Theorie-Vertreter)
[R03] Alle Verbindungen zum Notenserver sind verschlüsseltFordern Dekanat, Prüfungsamt, Dozenten. Studierende implizit.
[R04] Zugriff nur auf die eigenen Noten möglichKein online-Gesamtaushang, damit keine externen Robots (anonyme) Notenprofilauswertungen vornehmen können
[R05] Statistik ebenfalls nur dort sichtbar, nicht offenSiehe [R04]
[R06] Alle eigenen Noten des laufenden Prüfungszeitraums zusammenbei einem Login zu sehen
Studenten wollen sich weder mehrfach einloggen noch Klausurnamen merken
FiktivesBeispiel
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 90 SWT WS19/20 - 90Kurt Schneider, Leibniz Universität Hannover
Klassifikation von Anforderungen
• Funktionale Anforderungen an das Produkt– Was die SW tun soll
• Nicht-funktionale Anforderungen an das Produkt– In welcher Weise die SW es tun soll
– Qualitätsanforderungen• Flexibilität, Portabilität, Wartbarkeit, Schnelligkeit usw.
– Andere nicht-funktionale Anforderungen• Mengengerüst
• Prozessanforderungen– Welchen Abläufen und Vorgaben das Projekt folgen soll
• Projektanforderungen– Zeit- und Geldbudget des Projekts
Con
stra
ints
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 91 SWT WS19/20 - 91Kurt Schneider, Leibniz Universität Hannover
Constraints
• Produkt-Anforderung beschreiben, welche Funktionen oder Eigenschaften die Software haben soll.
• Prozess- und Projektanforderungen legen fest, mit welchen Mitteln und auf welchem Wege das Projekt ablaufen soll.
• Constraints schränken dagegen den Lösungsraum ein. – „MVC muss verwendet werden“– „Das Play!-Framework darf nicht verwendet werden“– „Unsere hausinterne Bibliothek ist vorzuziehen“– „Zur Planung muss MS Project verwendet werden“
• Es gibt Überschneidungen; Abgrenzung ist schwierig
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 92 SWT WS19/20 - 92Kurt Schneider, Leibniz Universität Hannover
Anforderungen hängen zusammen
• Experten kennen diese Abhängigkeiten• Templates dienen dazu, sie nicht zu vergessen• Werkzeuge unterstützen die Verwaltung
Rand-bedingungen
Anforderungen GlossarParameterParameter-formate
verwendetFormat
wird eingeschränktdurch
verwendet
Schnittstellenverwendet
definiert in
definiert in
verfeinert
verwendetBegriff
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 93 SWT WS19/20 - 93Kurt Schneider, Leibniz Universität Hannover
Empfohlene Inhalte der SpezifikationDas „Volere-Template“ (Robertson99)
• Product Constraints– Purpose of the Product– Client, Customer, Stakeholders– Users– Requirements Constraints– Naming Conventions and Defs.– Relevant Facts– Assumptions
• Functional Requirements– Scope of the Product– Functional and Data Reqs.
• Non-Functional Requirements– Look and Feel Reqs.– Usability Reqs.– Performance Reqs.– Operational Reqs.
– Maintainability and Portability – Security Reqs– Cultural and Political Reqs– Legal Requirements
• Project Issues– Open Issues– Off-the-Shelf Solutions– New Problems– Tasks– Cutover (Roll-out)– Risks– Costs– User Documentation– Waiting Room
(aufgeschobene Reqs.)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 94 SWT WS19/20 - 94Kurt Schneider, Leibniz Universität Hannover
Klassifikation(Fiktives Beispiel; Auszug)
[R01] Studierende haben Zugang über Name und PINEntscheidungstabelle, in Workshop abgesegnet (Negot.-WS)
[R02] PIN fünfstellig, nicht mit Matrikelnummer korreliertMatrikelnummer steht öffentlich auf Studentenausweis (Dekan)Fünfstellige PINs ausreichend (Theorie-Vertreter)
[R03] Alle Verbindungen zum Notenserver sind verschlüsseltFordern Dekanat, Prüfungsamt, Dozenten. Studierende implizit.
[R04] Zugriff nur auf die eigenen Noten möglichKein online-Gesamtaushang, damit keine externen Robots (anonyme) Notenprofilauswertungen vornehmen können
[R05] Dozent kann Jahresstatistik anzeigenGenauer: NUR Dozent kann das (siehe R04)
[R06] Noten aller Prüfungen einer Person zusammen sichtbarStudenten wollen sich weder mehrfach einloggen noch Klausurnamen merken
Funktional
Funktional
Funktional
Funktional
SicherheitQualitätsanford.
SicherheitQualitätsanford.
FiktivesBeispiel
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 95 SWT WS19/20 - 95Kurt Schneider, Leibniz Universität Hannover
Klassifikation(Fiktives Beispiel; Auszug, fortgesetzt
[R42] Der jetzige Arbeitsablauf von Dozenten und Prüfungsamt ist zu beachten. Mehraufwand ist zu vermeiden …
[R61] Die technische Schnittstelle zu den HIS-Programmen steht nicht zur Disposition und muss beachtet werden.
…[R82] Das Programm soll bis zum Sommersemester
operativ laufen …[R89] Alle Studierenden der Fakultät sollen dann alle
neuen Klausurnoten einsehen können.…
[R90] Eine Zugriffsrate von 200 Personen pro Tag, bis zu 20 gleichzeitig muss verkraftet werden und darf nicht zu Antwortzeiten von über 10 sek.führen
Funktional(Geschäftsproz.)
Constraint
Qualität/Geschw.unklar def.
Mengengerüst
Mengengerüst
Projektanford.
FiktivesBeispiel
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 96 SWT WS19/20 - 96Kurt Schneider, Leibniz Universität Hannover
Validierung und Verifikation: Prüfung
• Begriffe– Validierung :=
„sind die dokumentierten auch die wirklichen Anforderungen?“
• Egal, was bisher aufgeschrieben wurde
– Verifikation := „stimmen Anf. mit zuvor dokumentierten überein?“
• Egal, ob der Kunde das (noch) wirklich will
Spez.
Ent-wurf
Kunde
Entwickler
Validierung: Inhaltliche PrüfungIst der Entwurf das, was der Kunde will?
Verifikation: Formale PrüfungErfüllt der Entwurf die Spezifikation?
• PrüfungstechnikenValidierung: Befragung, Interview, Nachprüfung, Konfrontation
Verifikation: Formale Verfahren, Konsistenzprüfungen, Erreichbarkeit
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 97 SWT WS19/20 - 97Kurt Schneider, Leibniz Universität Hannover
Requirements Management
• Die Verwaltung der Anforderungen
• Leicht handhabbar ablegen– Werkzeug (wie Doors, RequisitePro)
• Änderungen und Versionen im Griff behalten
– Besonders interessant: auch die Gründe für Änderungen erfassen und aufbewahren!
• Änderungen weitergeben, Verfolgbarkeit in beide Richtungen (Tracing)
– Das ist sehr schwer!– Schon seit Jahrzehnten ungelöst– Hier helfen Werkzeuge
Verfolg-barkeit
(Tracing)
Änderungs-management
Änderungs-wünsche
Versionen vonAnforderungen
(Historie)
Propagierender Änderung(-> Tracing)
Festhaltender Annahmen,
Quellen vonAnforderungen
(pre-tracing)
Auswirkungenvon Anforderg.
im System(post-tracing)
Req. Management
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 98 SWT WS19/20 - 98Kurt Schneider, Leibniz Universität Hannover
In der Praxis sehr weit verbreitetAuch in der Forschung präsentSehen einfach aus – muss man selbst anwendenViele Entwicklungsschritte bauen darauf auf
Use Cases
Schwerpunktthema
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 99 SWT WS19/20 - 99Kurt Schneider, Leibniz Universität Hannover
Wichtig: Use Cases
• DefinitionBeschreibung einer Interaktion zwischen (min.) einem Akteur und dem System, durch das ein Ziel des Hauptakteurs erreicht wird.
• Beispiel Bankomat (Kern eines Use Case)
Use Case „Geld abheben“
1. Kunde führt Karte in Kartenschlitz ein
2. System fragt nach PIN
3. Kunde gibt PIN ein
4. System fragt nach gewünschter Aktion
5. Kunde wählt Abhebung und gibt Betrag ein
6. System gibt zuerst Karte aus, dann Geld
7. Kunde kann sich Quittung geben lassen
8. System geht in den Ausgangszustand über
Akteur(„Actor“)
Ziel: Geld haben
Absichten, keine Interface-Details!
Sys-Grenzen?(„Scope“)
Interaktion...
Ablauf...
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 100 SWT WS19/20 - 100Kurt Schneider, Leibniz Universität Hannover
Wozu Use Cases?
• Beschreiben das Systemverhalten– Das ganze, extern wahrnehmbare Systemverhalten– Aber nicht mehr als das (keine Interna, keine Qualitätsanforderungen)
• Meist von Entwicklern geschrieben– In Zusammenarbeit mit Fach-Experten– Diskussion führt zu Reflexion, klärt vieles („elicitation“)
• Sind Basis für alle weiteren Aktivitäten– Stellen Analyse-Schritt dar (Ist-Use Cases)– Repräsentieren Requirements (Soll- Use Cases)– Design muss Use Cases ermöglichen– Testfälle können aus Use Cases abgeleitet werden
• Hinweis: Einfacher Use Case ist nahe an Testfall – ist aber keiner• Use Case: „Klasse“ von Abläufen. Testfall: ein ganz konkreter
– Als „Contract“ (Vertrag) dienen sie beim Abnahmetest
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 101 SWT WS19/20 - 101Kurt Schneider, Leibniz Universität Hannover
Formate für Use Cases
• Im Prinzip ist jedes Format möglich - wenn es hilft
• In der Literatur dominieren die „graphischen UML-Modelle“
• Aber Achtung! – Diagramme zeigen nur den Überblick
• Welche use cases gibt es?• In welcher Beziehung stehen Actors und use cases?
– Sie zeigen nicht: den eigentlichen „Kern des Use Cases“• die Abfolge der Schritte,Vor- u. Nachbedingung etc.
Geld abheben <<actor>>Bankomat
Primary Actor Use Case Systemgrenze Actor (System)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 102 SWT WS19/20 - 102Kurt Schneider, Leibniz Universität Hannover
Use Case-Diagramme
Allgemein
«actor»<Name>
<Name>
Aktoren mit Namen Name• Rechteck für Systeme
• Stereotype <<actor>>• Strichmännchen sonst
«include» AusgeklammerterTeil-Use Case
«extend» OptionaleErweiterung
<UC name> Use Case mit Namen UC name
<Actor> nimmt teil an <UC>
Systemgrenze (Rahmen)
Geld abheben
Beispiel
Kunde
Kontostand prüfen
Quittung drucken
«include»«extend»
«actor»Konten-DB
BetreuerBonität prüfen
«include»
Makler
«actor»Bankomat
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 103 SWT WS19/20 - 103Kurt Schneider, Leibniz Universität Hannover
Formate für Use Cases
• Die Interaktionen können in vielen Notationen beschrieben werden
– Ablaufdiagramm– Struktogramme– Petri-Netze– Pseudo-Code– Echter Code
• Wichtig: ihre Aufgabe ist Kommunikation unter Menschen
• Daher eignet sich für viele Use Cases besonders: Text
• Aber den sollte man strukturieren
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 104 SWT WS19/20 - 104Kurt Schneider, Leibniz Universität Hannover
Stile textbasierter Use Casesnach Alistair Cockburn / (meine deutschen Entsprechungen)
• Narrative / Geschichtchen (noch kein Use Case)„Peter braucht schnell Geld fürs Kino. Er betritt den Bankomatenraum und steckt seine ec-Karte ein. Dadurch wird er identifiziert und durch seine PIN authentifiziert. Er gibt den Betrag ein, erhält Geld und Karte.“
• Brief / Kurzfassung– Ein Absatz: Zusammenfassung, oft des Haupt-Erfolgsszenarios.
• Casual / Informell– Mehrere informell geschriebene Absätze, darin mehrere Abläufe.
• Fully dressed / Detailliert– Am ausgefeiltesten.
In Tabellenform sind alle Schritte und Varianten detailliert aufgeführt. Zusatzangaben wie „Voraussetzungen“, „Garantien“.
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 105 SWT WS19/20 - 105Kurt Schneider, Leibniz Universität Hannover
Elemente von Use Case Beschreibungen
• Akteure / Actors– außerhalb der Systemgrenzen– Interagiert mit dem System im Rahmen des Use Case– Hauptakteur (Primary Actor): der, dessen Ziel erreicht werden soll
• Stakeholder– Jemand mit Interesse am Use Case - muss nicht daran teilnehmen– Wer ist das? Fertigkeiten, Aufgaben, Hintergrund? -> Separate Tabelle
• Systemgrenzen / Scope– Was gehört noch zum modellierten System, was nicht mehr?
• Erfolgsfall und Misserfolgsfall / success and failure– Wenn der gewünschte Fall eintritt bzw. wenn er nicht eintritt
• Garantie– Was man auch im Misserfolgsfall noch sicherstellen kann
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 106 SWT WS19/20 - 106Kurt Schneider, Leibniz Universität Hannover
Formular für einen vollen Use Case
Use Case Nr. <nr>UmfeldSystemgrenzenEbeneHauptakteurStakeholderu. Interesse
VoraussetzungGarantienErfolgsfallAuslöserBeschreibung
Erweiterungen
Technologie ...
<Name: kurzer, aktiver Satz> <Wo, unter welchen Umständen ausgeführt><Scope: was gehört dazu, was nicht?><Überblick, Aufgabe oder Teilfunktion><Kurzbeschreibung dessen, der Ziel hat>Stakeholder Interesse<erste> <ihre Interessen><zweiter> <seine Interessen>
<wovon kann man bei Beginn ausgehen?><was in jedem Fall gewährleistet ist><Zustand bei erfolgreicher Beendigung><wann der Use Cases startet>Schritt Aktion1 <von Auslöser bis Aufräumen>
2 <z.B.: „..zurück in Ausgangsz.“
1a WENN ... DANN <and. Use Case><Variationen durch Technik>
Szenario :=Ein Ablauf in
einem Use Case
in Anlehnung an Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 107 SWT WS19/20 - 107Kurt Schneider, Leibniz Universität Hannover
Drei EbenenAm wichtigsten ist die „Sehhöhe“ der Aufgaben
aus Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001
„Aufgabenebene“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 108 SWT WS19/20 - 108Kurt Schneider, Leibniz Universität Hannover
Beispiel: BankomatUC Geld abheben (Teil 1)
Fortsetzung folgt …
Der hier beschriebene UC-Ablauf soll möglich sein.
Weitere Anforderungenkann man annotieren/anfügen
[R27] verfügbar ist Guthaben plus Kreditrahmen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 109 SWT WS19/20 - 109Kurt Schneider, Leibniz Universität Hannover
Beispiel: BankomatUC Geld abheben (Teil 2)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 110 SWT WS19/20 - 110Kurt Schneider, Leibniz Universität Hannover
Beispiel 2: UC Überweisung tätigenTeil 1
Fortsetzung folgt …
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 111 SWT WS19/20 - 111Kurt Schneider, Leibniz Universität Hannover
Beispiel 2: UC Überweisung tätigenTeil 2
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 112 SWT WS19/20 - 112Kurt Schneider, Leibniz Universität Hannover
Use Case-Templatehier beispielsweise für Excel; finden Sie auf StudIP
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 113 SWT WS19/20 - 113Kurt Schneider, Leibniz Universität Hannover
Wie man Use Cases einsetzt
1. Akteure identifizieren1. Wer benutzt das System? Wozu? Stakeholder-Profile-Tabelle2. Wer ist mit Ein- und Ausgaben konfrontiert? Acteure
2. Systemgrenzen festlegen– Akteure sind außen, Use Cases beschreiben das Hin und Her
3. Wichtigste Use Cases identifizieren– Narrative, Beziehung zwischen Use Case und Actor herstellen (UML)
4. Zunehmend genauer beschreiben1. Narrative (Geschichtchen)2. Kurzfassung -> Informell oder Detailliert
1. Erfolgsszenarien2. Fehlerszenarien
3. Use Cases mit dem Kunden diskutieren4. Bei Bedarf: grafische Übersicht (UML, Beziehungen) ergänzenZwei Schleifen: über alle Use Cases, durch die Ebenen; mit Kunden
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 114 SWT WS19/20 - 114Kurt Schneider, Leibniz Universität Hannover
Wann ist man fertig?
• Fertig, sobald– alle Hauptakteure identifiziert wurden– ihre Ziele genannt haben– Jedes Ziel von mindestens einem Use Case abgedeckt ist.
• Und wenn alle Use Cases klar und verständlich sind:– Sponsoren bestätigen („agree“), damit Abnahme machen zu
können– Nutzer bestätigen, dass Systemverhalten zutreffend beschrieben– Sponsoren bestätigen, dass die Use Cases (vorerst) vollständig
sind
• Natürlich ist man dann nicht endgültig fertig!
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 115 SWT WS19/20 - 115Kurt Schneider, Leibniz Universität Hannover
Tipps und Tricks
• Use Cases erfassen nur funkt. Anforderungen, die aber alle
• Zuerst in die Breite arbeiten, dann in die Tiefe
• Eher zu wenig als zu viel schreiben– Sonst liest es doch keiner, dann hilft es nichts
• Es geht um das Geschriebene (UC), nicht das Gemalte (Diag.)
• Diskussion über Formalität und Stil nicht übertreiben– Es kommt letztlich halt auf Klarheit an - egal, wie
• Keine „if-Konstrukte“ in Hauptszenarios– Sond. Extensions/Abzweig-Szenarien
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 116 SWT WS19/20 - 116Kurt Schneider, Leibniz Universität Hannover
Team-Aufgabe: Spezifikation
• Gegeben: Template
• Hier: SWP-Template
• Sonst oft: firmenspezifisch
• Nun RE durchführen, Ergebnis ins Template
• Als Ausgangsbasis, wie in der Team-Aufgabe, ein aufgezeichnetes Interview mit Kunden
Kunden-interview
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 117 SWT WS19/20 - 117Kurt Schneider, Leibniz Universität Hannover
Team-Aufgabe: Spezifikation
• Deckblatt standardisiert
• Projektname, Version!
• Verantwortliche
• Zwei Fragen – nicht rhetorisch• Unterschrift: Verantwortung
• Hier gleich mit drauf:– Kundenreaktion– Kundenunterschrift (Bindung)
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 118 SWT WS19/20 - 118Kurt Schneider, Leibniz Universität Hannover
„Standardisierung“ durch Spezifikationstemplate Softwareprojekt, Leibniz Universität Hannover
1 Mission des Projekts1.1 Erläuterung des
zu lösenden Problems1.2 Wünsche und Prioritäten
des Kunden1.3 Domänenbeschreibung1.4 Maßnahmen zur
Anforderungsanalyse2 Rahmenbedingungen
und Umfeld2.1 Einschränkungen und Vorgaben2.2 Anwender2.3 Schnittstellen und an-
grenzende Systeme3 Funktionale Anforderungen
3.1 Use Case-Diagramm3.2 Use Case-Beschreibungen3.3 Technische Anforderungen
4 Qualitätsanforderungen4.1 Qualitätsziele des Projekts4.2 Qualitäts-Prioritäten
des Kunden4.3 Wie Qualitätsziele erreicht
werden sollen5 Probleme und Risiken6 Optionen zur
Aufwandsreduktion6.1 Mögliche Abstriche6.2 Inkrementelle Arbeit
7 <Zur freien Verfügung>8 Glossar9 Abnahme-Testfälle
Lasten-heft
Pflicht-enheft
„Spezifikation“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 119 SWT WS19/20 - 119Kurt Schneider, Leibniz Universität Hannover
Spezifikation schreiben
• Erinnern Sie sich:– Elicitation, u.a. Kundengespräch– Interpretation: Sollen Sie jetzt machen– Negotiation: entfällt (nur 1 Kunde)– Dokumentation: Durch das Template erleichtert
• Erforderliches Material– Mitschrift aus Kundeninterviews (hier: Video)– Template für Spezifikation– Weiteres relevantes Material
• Resultat– Erster Entwurf der Spez. nach der Interpretation– Dann verifizieren und validieren– Änderungen nach Unterschrift kosten den Kunden Geld
Spez.-Template
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 120 SWT WS19/20 - 120Kurt Schneider, Leibniz Universität Hannover
Anforderungen wirksam berücksichtigenPrinzip, nun die agile Umsetzung
• Planning Game
• User Stories
• On-Site Customer• Product Owner
• Direkte Kommunikation
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 121 SWT WS19/20 - 121Kurt Schneider, Leibniz Universität Hannover
Planen, Arbeiten und Feedbackder agile Zyklus
6 ausliefern
5 imple-mentieren
5 schreiben
Code Document(Manual)
VageAnford. On-site
CustomerEntwickler
Paare
Kunden
3 : schätzen
Planning Game4: auswählen
2
FIRMA* Story Card Nr. 10Kommentarfeld und Erläuterung
• Ich gehe gerade die Fragen in der Sitzung durch.• Ich sehe alle Felder (lesend), auch die Erläuterung.
– Die Erläuterung erscheint als Feld oder Sprechblase etc.
• In einem Feld kann ich einen ca. 5-Zeilen-Kommentar angeben bzw. ändern.– Darin wird gesagt, wieso die Bewertung ausgewählt wird.
Oder Bemerkungen gemacht.– Beim Vor- und Zurückblättern taucht er wieder auf und
ich kann noch mal ändern– Ebenso, wenn die die DB verlasse und später wieder
zurückkomme.
Status:neu5 Ph, 2(2) B.
1
7 benutzen
8 feedback
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 122 SWT WS19/20 - 122Kurt Schneider, Leibniz Universität Hannover
Anforderung
Aufwand,Datum der Erledigunggeschätzt: 6 Pkt./ 1 Wo
1. Authentifizieren2. Betrag eingeben3. Prüfen4. Auszahlen
Geld abheben7.6.04, D.Autor
Planning Game / Planungssitzung
• Anforderungen werden auf Story Cards gesammelt– vom Kunden umgangssprachlich geschrieben– Informell, auf A5 od. A4-Karten, evtl. mit kleinen Skizzen
• Entwickler schätzen Aufwand für jede Story Card– abstraktes Maß (z.B. 1-5 Punkte)– Schätzung durch Erfahrung (ähnliche Karten)– Nachfragen und Feedback an Kunden
(interaktive Anforderungs-Klärung)– Neue Erkenntnisse auf Story Cards notieren
• Kunde wählt Story Cards für nächste Release(s) aus– (Meistens, möglichst!) nach Nutzen priorisiert– Bisherige Produktivität des Entwicklungsteams ergibt Limit
• Story Cards sind Grundlage für Akzeptanz-Tests• Es gibt keine gewohnte, „ordentliche Spezifikation“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 123 SWT WS19/20 - 123Kurt Schneider, Leibniz Universität Hannover
Planning Game / Planungssitzungeine wichtige Verpflichtung
• Jedes Inkrement muss so definiert werden, dass es dem Auftraggeber (AG)/Kunden Nutzen stiftet!
• Welchem AG würde das nicht gefallen?
• Aber Achtung: das ist eine Verpflichtung an den AG, nicht den Entwickler!
– Sonst nimmt er dem Entwickler die Chance zum Erfolg– Die Entwickler werden den Kunden daran erinnern
(evtl. im Vertrag)– Und ihm bei der Auswahl helfen
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 124 SWT WS19/20 - 124Kurt Schneider, Leibniz Universität Hannover
Planning Game / PlanungssitzungTipps
• Begriff Planungs“spiel“ ist für Deutschland zu unernst• Kunde wählt Story Cards für nächste Release(s) aus
– (Meistens) nach Nutzen priorisiert– Dabei kann – und muss – man oft rückfragen– Für diesen Schritt müssen Story Cards physisch vorliegen (nicht im Computer)
• Entwicklerpaar nimmt sich oberste Story Card vom Stapel; nicht wählen!– Zufallselement sorgt für Mischung
• Story Cards sind Grundlage für Akzeptanz-Tests– Müssen daher testbar sein– Tests entwickeln sich ebenfalls im Laufe der Zeit– Es gibt zusätzlich Task Cards: feinere/technisch motivierte Aufgaben
• Streitfall: Was geschieht mit Story Cards weiter?– Variante 1: Dokumentation der Anforderungen– Variante 2: Wegwerfen! Anforderungen ändern sich ja
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 125 SWT WS19/20 - 125Kurt Schneider, Leibniz Universität Hannover
Story Cards mehrerer Iterationen
Prinzipbild aus dem Werkzeug „JIRA“
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 126 SWT WS19/20 - 126Kurt Schneider, Leibniz Universität Hannover
Planning Game / Planungssitzung
• Arbeiten auf Basis von Story- und Task-Cards fordert Konzentration– Man muss das umsetzen, was gefordert ist– Weitergehende Ideen sind nicht gefragt, und man hat keine Zeit– Die Arbeit ist sehr intensiv und anstrengend
• Gefahr: Ausbrennen von Entwicklern– Zu lange am engen Zügel geführt, kein „gold plating“ mehr erlaubt– Zu lange im Stress– Zu lange keine neuen technischen Herausforderungen mehr
• Abhilfe: Gold Cards– Ein „Joker“ für einen lange angespannt arbeitenden Mitarbeiter– Muss mal (z.B. ein, zwei Tage lang) an einer
neuen technischen Frage knobeln– Darf rumprobieren und Grundlagen legen– In der Schätzung gehen die automatisch ein, sofern regelmäßig durchgeführt
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 127 SWT WS19/20 - 127Kurt Schneider, Leibniz Universität Hannover
On-site Customer / Kunde vor Ort
• Kunde ist über die gesamte Projekt-Laufzeit vor Ort– zumindest leicht und jederzeit erreichbar
• Schreibt Story Cards (Entwickler dürfen helfen)– Ständige Weiterentwicklung der Anforderungen
• Beantwortet Fragen der Entwickler, auch unter Ungewissheit– Kein Zeitverlust bei Entscheidungen– Keine Fehlentscheidungen durch Entwickler
• Voraussetzung: Kompetenz und Entscheidungsgewalt
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 128 SWT WS19/20 - 128Kurt Schneider, Leibniz Universität Hannover
On-site Customer / Kunde vor OrtPraktische Erfahrungen
• Verhaltensweisen von Kunden– Oft werden Soll- mit Istprozessen verwechselt– Altsystem wurde lange „umgangen“– Stellen sich oft nur lokale Änderungen dazu vor
• Daher: Entwickler helfen Kunden beim Story Card-Schreiben– Erinnern an die Prüfbarkeit– Fragen nach drastischeren Alternativen
• Ganz wichtig für den Erfolg– Anwenderkontakt ist unverzichtbar für XP– Wenn Entwicklerteam unsicher ist: nicht selbst raten, fragen!– Anwender entscheidet über Alternativen– Kundenanwesenheit nutzen, Kunden nicht ausnutzen oder nerven
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 129 SWT WS19/20 - 129Kurt Schneider, Leibniz Universität Hannover
On-site Customer / Kunde vor OrtTipps
• Muss nicht 100% vor Ort sein, aber kurzfristig erreichbar– Z.B. tägliches „Stand-up Meeting“ (ähnlich SCRUM)– Auf lange Frist könnte 100%-anwesender Kunde
sonst sogar die „Kundigkeit“ verlieren– Oft sind verschiedene „Kunden-Arten nötig“: Anwender/Kunden?
• Wichtige Unterscheidung– Anwender beantwortet fachliche Rückfragen– Kunde priorisiert Story Cards
• Häufig versuchen Projekte, den Kunden zu ersetzen– Kunden haben wenig Zeit– Kompetente, entscheidungsfähige erst recht– On-Site Customer sitzt zeitweise untätig im Projekt herum– Konsequenz: Selbst „On-Site Customer“ spielen!
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 130 SWT WS19/20 - 130Kurt Schneider, Leibniz Universität Hannover
„Customer Proxy“ Konzept
• Entwickler „spielt Kunde“– gute Kenntnis des
Anwendungsbereichs– intensiver Kontakt mit
Entwicklern– nimmt an Abstimmungen der
Teil-Kunden teil
• Wichtig– schnelle Entscheidungen durch eine
Person– falsche Entscheidungen später
revidierbar– das haben wir in der Praxis gesehen
und selbst gemacht: es funktioniert!
GB 1Entwickler
TeamGB 2
GB 3Abstimmung
der Teil-Kunden CP
PL
Auftraggeber Auftragnehmer
Aus: Schneider, K. (2003): SQM congress 2003, Köln, SQS
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 131 SWT WS19/20 - 131Kurt Schneider, Leibniz Universität HannoverSiehe: Ambler (2002): Agile Modeling
Dokumentation als Kommunikationsmittel
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 132 SWT WS19/20 - 132Kurt Schneider, Leibniz Universität Hannover
FLOW: Aggregatzustände
Aggregat-zustand
Speicher FlussProjektinfo. Erfahrung
Aktivitättransformiert Flüsse
Fest
<Name><Informationsart>
(optional)
Flüssig
<Name><Informationsart>
(optional)
<Aktivität>
Steuerung
Unterstützung
In/Out
Oft:Erfahrung
InfoFLOW, TeamFLOW: DFG-Forschungsprojekte am FG Software Engineering
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 133 SWT WS19/20 - 133Kurt Schneider, Leibniz Universität Hannover
FLOW-Beispiel
• Wie viele Indirektionsstufen liegen zwischen – Kunde und Code– Req. Analytiker und Tester?
Tester
ProgrammerDesignerReq. AnalystCustomer
Test Report
CodeSpecification
meeting: 1,2 talk: 1,0 email: 1,4
program: 2,1
read: 1,6read: 1,6
write: 1,7
Definebusiness proc.
User
Chinese whisper pattern (indirection between Customer and Programmer)
Die Quantifizierung der Kommunikationskanäle ist noch Forschungsgegenstand.Die Zahlen hier sind Beispiele.
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 134 SWT WS19/20 - 134Kurt Schneider, Leibniz Universität Hannover
Prinzip und Denkweise von Agilen Methoden
Bisheriger Ansatz Agiler Ansatz
Mitwirkung desKunden
unwahrscheinlich kritischerErfolgsfaktor
Etwas Nützlicheswird geliefert
erst nach einiger(längerer) Zeit
mindestens allesechs Wochen
Das Richtigeentwickeln durch
langes Spezifizieren,Vorausdenken
Kern entwickeln,zeigen, verbessern
Nötige Disziplin formal, wenig informell, vielÄnderungen erzeugen Widerstand werden erwartet und
toleriertKommunikation über Dokumente zwischen Menschen
Vorsorge fürÄnderungen
durch Versuch derVorausplanung
durch „flexibelBleiben“
Karol Frühauf,Conquest
Kurt Schneider, Leibniz Universität HannoverMEM (2017/18) - 135 SWT WS19/20 - 135Kurt Schneider, Leibniz Universität Hannover
• Anforderungen: Bezugspunkt von SW-Entwurf, -Entwicklung, -Test
• Anforderungen sind aber nicht leicht zu bekommen– Sie erfordern Kommunikation mit „Fach-Leuten“– „Symmetry of ignorance“– Alle Schwierigkeiten üblicher Kommunikation eingeschlossen
• Requirements Engineering umfasst mehrere Aktivitäten– Elicitation: Herauskitzeln– Interpretation: Das Gehörte deuten– Negotiation: Priorisieren, Widersprüche auflösen, Verhandeln– Dokumentieren: Aufschreiben– Validation & Verification: Prüfen– Managen und Tracen: Verfolgen, Änderungen einarbeiten
• Anforderungen wirksam berücksichtigen– Die obigen Aktivitäten ausführen– Die verschiedenen Arten von Anforderungen sammeln– Im (z.B. Volere-) Template sammeln, mit Use Cases
Wiederholung: Anforderungen