fachgebiet software engineering Übersicht © 09.02.2014 albert zündorf, kassel university...

Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University

Vorgehensmodelle: Wasserfallmodell


Vorgehensmodelle: V-Modell

OO Softwareentwicklung inkrementell prototypisch iterativ Use-Cases driven Architekturbeschreibung durch Klassendiagramme


Vorgehensmodelle: V-Modell

Submodule Projektmanagement Qualitätssicherung Softwareentwicklung Konfigurations-

Management

definiert Rollen

beschreibt Aktivitäten und Produkte

definiert Werkzeuge

Spiralmodel nach Barry W. Boehm


Anforderungen

Design

Implementierung

Test


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


Vorgehensmodelle: Der Unified Process


Requirements Capturing


Requirements Refinement

Story Driven Modeling

1. requirements scenarios

2. application scenarios

3. story boards & GUI mockups

4. class diagrams

5. tests

6. method development


Quanten Metapher von Kurt Schneider



Datenflussmodellierung mit FLOW (Kurt Schneider)

Communication Patterns (Kurt Schneider)

Dokumente Reproduzierbar, Aufwendig Nachfragen schwierig

Gespräche Nicht reproduzierbar Billig Interaktiv


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


Communication Patterns (Kurt Schneider)



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


Übersicht

eXtreme Programming Das Planungsspiel Testen Pair Programming Raumaufteilung on-site customer Design Metapher Gemeinsamer Codebesitz


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


Story Card


Task Card


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


Testen


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


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


Raumaufteilung


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


Einfaches / simples Design

Lehrmeinung: Kosten für Änderungen steigen exponentiell mit Projektlaufzeit

Kent Beck’s Meinung: Änderungen werden mit der Projektlaufzeit eher billiger


Einfaches / simples Design

Die Lehrmeinung impliziert:

Kent Beck’s Meinung impliziert


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


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


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


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)


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


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


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


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)


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



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



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


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 >== ?


Kanban


Semat Software Engineering Method and Theory

Ivar Jacobson

Comming soon …


Das liebe Geld

Angebot

Bestellung

Rechnung

Festpreis Produkt(Design by Budget)

Dienstleistung (Arbeitsstunden)


Twenty dirty tricks to train software engineers; Ray Dawson ICSE 2000


fachgebiet software engineering Übersicht © 09.02.2014 albert zündorf, kassel university...

Documents