Upload
meinhard-apfelbaum
View
103
Download
0
Embed Size (px)
Citation preview
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehensmodelle: Wasserfallmodell
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehensmodelle: V-Modell
OO Softwareentwicklung inkrementell prototypisch iterativ Use-Cases driven Architekturbeschreibung durch Klassendiagramme
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehensmodelle: V-Modell
Submodule Projektmanagement Qualitätssicherung Softwareentwicklung Konfigurations-
Management
definiert Rollen
beschreibt Aktivitäten und Produkte
definiert Werkzeuge
Spiralmodel nach Barry W. Boehm
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Anforderungen
Design
Implementierung
Test
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehensmodelle: Der Unified Process [JBR]
objektorientiert
benutzt die UML
Use-Case driven
inkrementell und iterativ
Architektur basiert
Phasen Konzeptionsphase (englisch Inception) Entwurfsphase (englisch Elaboration) Konstruktionsphase (englisch Construction) Übergabephase (englisch Transition)
Arbeitsschritte ähnlich dem Wasserfallmodell
beschreibt Rollen / Aktivitäten / Dokumente / Produkte
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehensmodelle: Der Unified Process
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Requirements Capturing
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Requirements Refinement
Story Driven Modeling
1. requirements scenarios
2. application scenarios
3. story boards & GUI mockups
4. class diagrams
5. tests
6. method development
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Quanten Metapher von Kurt Schneider
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Datenflussmodellierung mit FLOW (Kurt Schneider)
Communication Patterns (Kurt Schneider)
Dokumente Reproduzierbar, Aufwendig Nachfragen schwierig
Gespräche Nicht reproduzierbar Billig Interaktiv
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Communication Patterns
Meetings Eingeschränkt reproduzierbar durch Minutes Mittlere Kosten Mittlere Interaktivität
Mail Reproduzierbar (auch wenn es sich privat anfühlt) Mittlere Kosten Mittlere Interaktivität
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Communication Patterns (Kurt Schneider)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
eXtreme Programming
Lehrmeinung zur Softwaretechnik Architektur ist ganz wichtig Process ist ganz wichtig Vollständige Anforderungsdefinition ist unabdingbar Alles in Dokumenten festhalten
Kent Beck (Berater im Silicon Valley)’s Meinung zur Softwaretechnik: Der ganze Quatsch hält nur auf lasst uns lieber Programmieren . . .
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Übersicht
eXtreme Programming Das Planungsspiel Testen Pair Programming Raumaufteilung on-site customer Design Metapher Gemeinsamer Codebesitz
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
eXtreme Programming Prinzipien / Elemente
Das Planungsspiel (The planning game) der Kunde schreibt „User Stories" auf Story-Karten
(Use Cases mit kurzer textueller Beschreibung) Die Entwickler schätzen den Entwicklungsaufwand
(basierend auf grober Zeiterfassung und Vergleich mit früheren Schätzungen, aber ohne besondere Techniken)
Kunde wählt (begrenzt durch den gesteckten Zeit- und Kostenrahmen) zu realisierende Stories für das nächste Release aus
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Story Card
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Task Card
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testen
Stories werden in Implementierungs-Tasks / (Teil-) Funktionalitäten runtergebrochen
Kunde schreibt Tests für seine Stories / Tasks
bevor man eine Funktionalität implementiert wird als erstes dafür ein "einfacher" Test (Test-first) geschrieben
dann wird solange implementiert, bis der Test durchläuft
fertig, nächste Funktionalität
oder Test erweitern und Implementierung erweitern
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testen
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Paar-Programmierung (Pair Programming)
Man sitzt immer zu zweit vor dem Rechner
Einer tippt, erklärt, . . .
Einer schaut, fragt, meckert, achtet auf Vorgehen und Standards, ...
Paare werden Task-weise neu zusammengestellt
Ersatz für Reviewing-Techniken
Ziele sind die selben
Paar-Programmierung ist eXtremer als Reviewing
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Raumaufteilung
großer Raum für das ganze Team Rechner in der Mitte mit genügend Platz damit bis drei Leute davor sitzen
können Hilfe auf Zuruf ist möglich Kein Teppich, damit die Stühle besser hin und her rollen können Cubicles an den Außenwänden Tisch für Besprechungen Kaffee Ecke mit (jeder Menge) Snacks und kleinen Spielen, ... Tafeln für Diskussionen Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik,
Empowerment, ...)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Raumaufteilung
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Kunde vor Ort (on-site customer)
Ein Kundenvertreter sitzt die ganze Zeit beim Entwickler-Team (lebende Anforderungsdefinition)
Der Kundenvertreter kennt die Anwendungsdomäne, ist selber zukünftiger Anwender oder Anwender des Vorgängersystems
Der Kundenvertreter schreibt Stories (Use-Cases)
Der Kundenvertreter implementiert Tests für die Stories
Der Kundenvertreter priorisiert Anforderungen im Planungsspiel
Der Kundenvertreter nimmt Releases ab und entscheidet über Projektfortsetzung
(Wo kriegt man solche Kunden her?)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Einfaches / simples Design
Lehrmeinung: Kosten für Änderungen steigen exponentiell mit Projektlaufzeit
Kent Beck’s Meinung: Änderungen werden mit der Projektlaufzeit eher billiger
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Einfaches / simples Design
Die Lehrmeinung impliziert:
Kent Beck’s Meinung impliziert
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Design in XP
kein "Voraus-Design"
kein Design für Wiederverwendung
kein Product-Line-Design
immer nur die gerade notwendigsten Klassen und Methoden
Refactoring Hilfen
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Metapher
eines der ungelösten Mysterien des XP
Metapher ist gemeinsame bildhafte Vorstellung des Systems
z.B.: Bahnhof, Postamt, Markt, Agentensystem, ...
Metapher sorgt für gemeinsame Sprachwelt im Team und mit dem Kunden
Der Begriff bleibt im Buch ziemlich unklar
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Kleine Releases
frühes erstes Teil-Release in "Produktion" (z.B. nach drei Monaten) viele kleine Releases (z.B. monatlich) Im Prinzip "iterativen" Lebenszyklusmodells (wie beim Unified Process) frühes Feedback durch Kunden Steuerung noch möglich automatisches Testen Funktionalität geht nicht verloren
Achtung: Altdatenbestände / festgeschriebene Bedienungsabläufe können Redesign-Schritte behindern
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Gemeinsamer Codebesitz
Keine Aufteilung des Programms in Verantwortungsbereiche
Jeder ist für das gesamte verantwortlich
Jeder darf überall beliebig ändern
Aber: die Tests müssen weiter durchlaufen
Das machen wir in Fujaba auch so
funktioniert gut (obwohl wir bisher nur wenig automatische Tests haben)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Coding Standards
damit "gemeinsamer Code-Besitz" funktioniert muss Code möglichst überall gleich aussehen
starke Coding Standards werden benötigt
Paar-Programmierung stellt Einhaltung der Standards sicher
das machen wir in Fujaba mit Eclipse
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Refactoring
Refactoring heißt Code-Reorganisation / kleiner Redesign-Schritte Copy-Paste Code in Methoden auslagern Klassenhierarchie überarbeiten Hilfsklassen, -methoden, -strukturen einführen . . .
Immer wenn man was sieht, was man mal überarbeiten sollte, auf die Task-Card schreiben
bevor man neue Funktionalität implementiert, gegebenenfalls Desginänderungen vornehmen
während der Implementierung nicht gleichzeitig refactorn
nach der Implementierung Refactoring-Tasks abarbeiten
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Kontinuierliche Systemintegration
fertige Teilfunktionalitäten werden so früh wie möglich (täglich) in die Team-Master-Kopie integriert
dafür gibt es einen extra Integrations-PC
das machen wir mit SVN
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
40 Stunden Woche
müde Leute machen Fehler
müde Leute sind unproduktiv
Kent möchte genügend Zeit für seine Kinder haben
entspricht allen allgemeinen Empfehlungen zur Produktivität von Arbeitskräften
widerspricht der industriellen Praxis (gerade bei IT-Start-Ups)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Rollen in einem XP-Projekt
Programmierer: fast alle sind Programmierer Tests schreiben Refactoring Tests implementieren kommunizieren pairen
Kunde ein Kundenvertreter vor Ort "lebende" Anforderungsdefinition funktionale Anforderungen als Stories formulieren funktionale Tests schreiben Funktionalität für die Releases auswählen Verbindung nach Hause halten
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Rollen in einem XP-Projekt
Tester einer im Team unterstützt den Kunden beim Schreiben der funktionalen Tests
Tracker einer im Team schiebt die "Done" Markierungen auf dem Balkenplan weiter führt Produktivitätsstatistiken
Coach einer im Team verantwortlich für die Einhaltung / Umsetzung der XP Prinzipien wichtig beim Einstieg in die XP-Arbeitsweise etwas auch für die Architektur verantwortlich:
wenn nötig, Refactoring initiieren
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Rollen in einem XP-Projekt
Consultant XP fördert / produziert "allround" Programmierer für komplizierte / neue Technik(en) braucht man
gegebenenfalls einen Berater
Big Boss der "Projektmanager" vertritt / beschützt das Team nach außen hin trifft gelegentlich Personalentscheidungen mischt sich nicht in technische Sachen / die eigentliche
Arbeit ein
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Bewertung
XP hat viele gute Elemente / "Best Practices" Test-First Prinzip Paar-Programmierung (Reviewing funktioniert oft schlecht) Planungsspiel und On-Site-Kunde (wenn das der Kunde mit macht)
XP hat klare Beschränkungen kleine Projekte keine sicherheitskritischen Systeme wo zertifizierte
Entwicklungsprozesse verlangt werden
XP und Softwaretechnik sind eigentlich kein Widerspruch
Scrum / Kunagi:
User Stories / Tasks wie XP
Product Owner == Onsite Customer
Kleine Releases
Burn Down Charts >== Planungsspiel
Scrum Master >== ?
Daily Scrum Meeting >== ?
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Kanban
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Semat Software Engineering Method and Theory
Ivar Jacobson
Comming soon …
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Das liebe Geld
Angebot
Bestellung
Rechnung
Festpreis Produkt(Design by Budget)
Dienstleistung (Arbeitsstunden)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Twenty dirty tricks to train software engineers; Ray Dawson ICSE 2000
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University