Grundlagen der Softwaretechnikund sind auf zukünftige Entwicklungen vorbereitet – Sie kennen die...

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


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


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]


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:


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


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


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


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 ( [email protected] )– Nils Prenner ( [email protected] )

– Beachten Sie die Übungszeiten!


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


Ziel: Professionelle Softwareentwicklung

http://www.csss.cs.ubc.ca/files/images/DSCN2559.preview.jpg(29.9.06)


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


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.“


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


„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


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


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


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


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“


• 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


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


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


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


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


• 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


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


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


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


Wasserfallmodell nach Royce

Rücksprünge


Wasserfallmodell, fortgeschrittener Teil


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


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


SCRUM Master

SCRUMRoom

SCRUM team 7+/-2

ProductBacklog

(priorisiert)

Product Owner

SPRINT: 30 days

Andere

Daily SCRUM15 min.

SPRINTBacklog

Increment

SCRUM1


Gliederung

Einführung




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


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


Beispiel für eine sinnvolle Variante

Prototyping – auch davon gibt es noch Unter-Varianten

Analyse(Anford.) Codierung

Integration Betrieb

EntwurfAnalyse(Anford.) Codierung


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


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:


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


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


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


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


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


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


Die Auswirkungen reiferer Prozesse

Carnegie Mellon University, Software Engineering Institute (1995): The Capability Maturity Model, Addison Wesley


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


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


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


Konspirativ präsentiert: Agile Alliance


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


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!


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


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


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


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“


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


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.


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


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


SCRUM Master

SCRUMRoom

SCRUM team 7+/-2

ProductBacklog

(priorisiert)

Product Owner

SPRINT: 30 days

Andere

Daily SCRUM15 min.

SPRINTBacklog

Increment

SCRUM


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


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


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


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


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


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


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)


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


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


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


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


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)


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


Gliederung

Einführung




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


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


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

?


„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“)


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“


Was muss man immer tun, um Anforderungen zu erheben?Welche Arten von Anforderungen gibt es?Wie schreibt man sie auf (Spezifikation)?

Requirements Engineering

Schwerpunktthema


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


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


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


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


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


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


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


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


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


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


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.)


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


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


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


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


In der Praxis sehr weit verbreitetAuch in der Forschung präsentSehen einfach aus – muss man selbst anwendenViele Entwicklungsschritte bauen darauf auf

Use Cases

Schwerpunktthema


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...


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


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)


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


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


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“.


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


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


Drei EbenenAm wichtigsten ist die „Sehhöhe“ der Aufgaben

aus Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001

„Aufgabenebene“


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


Beispiel: BankomatUC Geld abheben (Teil 2)


Beispiel 2: UC Überweisung tätigenTeil 1

Fortsetzung folgt …


Beispiel 2: UC Überweisung tätigenTeil 2


Use Case-Templatehier beispielsweise für Excel; finden Sie auf StudIP


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


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!


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


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


Team-Aufgabe: Spezifikation

• Deckblatt standardisiert

• Projektname, Version!

• Verantwortliche

• Zwei Fragen – nicht rhetorisch• Unterschrift: Verantwortung

• Hier gleich mit drauf:– Kundenreaktion– Kundenunterschrift (Bindung)


„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“


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


Anforderungen wirksam berücksichtigenPrinzip, nun die agile Umsetzung

• Planning Game

• User Stories

• On-Site Customer• Product Owner

• Direkte Kommunikation


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


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“


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


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


Story Cards mehrerer Iterationen

Prinzipbild aus dem Werkzeug „JIRA“


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


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


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


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!


„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


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


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.


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


• 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

Grundlagen der Softwaretechnikund sind auf zukünftige Entwicklungen vorbereitet – Sie kennen die...

Documents

Transcript of Grundlagen der Softwaretechnikund sind auf zukünftige Entwicklungen vorbereitet – Sie kennen die...