Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Fachgebiet Software Engineering Übersicht © 09.02.2014 Albert Zündorf, Kassel University Vorgehensmodelle: Wasserfallmodell.

Ähnliche Präsentationen


Präsentation zum Thema: "Fachgebiet Software Engineering Übersicht © 09.02.2014 Albert Zündorf, Kassel University Vorgehensmodelle: Wasserfallmodell."—  Präsentation transkript:

1 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Vorgehensmodelle: Wasserfallmodell

2 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Vorgehensmodelle: V-Modell m OO Softwareentwicklung l inkrementell l prototypisch l iterativ l Use-Cases driven l Architekturbeschreibung durch Klassendiagramme

3 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Vorgehensmodelle: V-Modell m Submodule l Projektmanagement l Qualitätssicherung l Softwareentwicklung l Konfigurations- Management m definiert Rollen m beschreibt Aktivitäten und Produkte m definiert Werkzeuge

4 Spiralmodel nach Barry W. Boehm Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Anforderungen Design Implementierung Test

5 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Vorgehensmodelle: Der Unified Process [JBR] m objektorientiert m benutzt die UML m Use-Case driven m inkrementell und iterativ m Architektur basiert m Phasen l Konzeptionsphase (englisch Inception) l Entwurfsphase (englisch Elaboration) l Konstruktionsphase (englisch Construction) l Übergabephase (englisch Transition) m Arbeitsschritte ähnlich dem Wasserfallmodell m beschreibt Rollen / Aktivitäten / Dokumente / Produkte

6 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Vorgehensmodelle: Der Unified Process

7 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Requirements Capturing

8 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Requirements Refinement

9 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 © Albert Zündorf, Kassel University

10 Quanten Metapher von Kurt Schneider Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

11 Datenflussmodellierung mit FLOW (Kurt Schneider)

12 Communication Patterns (Kurt Schneider) m Dokumente l Reproduzierbar, l Aufwendig l Nachfragen schwierig m Gespräche l Nicht reproduzierbar l Billig l Interaktiv Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

13 Communication Patterns m Meetings l Eingeschränkt reproduzierbar durch Minutes l Mittlere Kosten l Mittlere Interaktivität m Mail l Reproduzierbar (auch wenn es sich privat anfühlt) l Mittlere Kosten l Mittlere Interaktivität Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

14 Communication Patterns (Kurt Schneider) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

15 eXtreme Programming m Lehrmeinung zur Softwaretechnik l Architektur ist ganz wichtig l Process ist ganz wichtig l Vollständige Anforderungsdefinition ist unabdingbar l Alles in Dokumenten festhalten m Kent Beck (Berater im Silicon Valley)s Meinung zur Softwaretechnik: l Der ganze Quatsch hält nur auf l lasst uns lieber Programmieren l...

16 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Übersicht m eXtreme Programming l Das Planungsspiel l Testen l Pair Programming l Raumaufteilung l on-site customer l Design l Metapher l Gemeinsamer Codebesitz

17 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University eXtreme Programming Prinzipien / Elemente m Das Planungsspiel (The planning game) l der Kunde schreibt User Stories" auf Story-Karten (Use Cases mit kurzer textueller Beschreibung) l Die Entwickler schätzen den Entwicklungsaufwand (basierend auf grober Zeiterfassung und Vergleich mit früheren Schätzungen, aber ohne besondere Techniken) l Kunde wählt (begrenzt durch den gesteckten Zeit- und Kostenrahmen) zu realisierende Stories für das nächste Release aus

18 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Story Card

19 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Task Card

20 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Testen m Stories werden in Implementierungs-Tasks / (Teil-) Funktionalitäten runtergebrochen m Kunde schreibt Tests für seine Stories / Tasks m bevor man eine Funktionalität implementiert wird als erstes dafür ein "einfacher" Test (Test-first) geschrieben m dann wird solange implementiert, bis der Test durchläuft m fertig, nächste Funktionalität m oder Test erweitern und Implementierung erweitern

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

22 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Paar-Programmierung (Pair Programming) m Man sitzt immer zu zweit vor dem Rechner m Einer tippt, erklärt,... m Einer schaut, fragt, meckert, achtet auf Vorgehen und Standards,... m Paare werden Task-weise neu zusammengestellt m Ersatz für Reviewing-Techniken m Ziele sind die selben m Paar-Programmierung ist eXtremer als Reviewing

23 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Raumaufteilung m großer Raum für das ganze Team m Rechner in der Mitte mit genügend Platz damit bis drei Leute davor sitzen können m Hilfe auf Zuruf ist möglich m Kein Teppich, damit die Stühle besser hin und her rollen können m Cubicles an den Außenwänden m Tisch für Besprechungen m Kaffee Ecke mit (jeder Menge) Snacks und kleinen Spielen,... m Tafeln für Diskussionen m Gut ist, wenn sich das Team selbst einrichtet (Gruppendynamik, Empowerment,...)

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

25 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Kunde vor Ort (on-site customer) m Ein Kundenvertreter sitzt die ganze Zeit beim Entwickler-Team (lebende Anforderungsdefinition) m Der Kundenvertreter kennt die Anwendungsdomäne, ist selber zukünftiger Anwender oder Anwender des Vorgängersystems m Der Kundenvertreter schreibt Stories (Use-Cases) m Der Kundenvertreter implementiert Tests für die Stories m Der Kundenvertreter priorisiert Anforderungen im Planungsspiel m Der Kundenvertreter nimmt Releases ab und entscheidet über Projektfortsetzung m (Wo kriegt man solche Kunden her?)

26 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Einfaches / simples Design m Lehrmeinung: Kosten für Änderungen steigen exponentiell mit Projektlaufzeit m Kent Becks Meinung: Änderungen werden mit der Projektlaufzeit eher billiger

27 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Einfaches / simples Design m Die Lehrmeinung impliziert: m Kent Becks Meinung impliziert

28 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Design in XP m kein "Voraus-Design" m kein Design für Wiederverwendung m kein Product-Line-Design m immer nur die gerade notwendigsten Klassen und Methoden m Refactoring Hilfen

29 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Metapher m eines der ungelösten Mysterien des XP m Metapher ist gemeinsame bildhafte Vorstellung des Systems m z.B.: Bahnhof, Postamt, Markt, Agentensystem,... m Metapher sorgt für gemeinsame Sprachwelt im Team und mit dem Kunden m Der Begriff bleibt im Buch ziemlich unklar

30 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Kleine Releases m frühes erstes Teil-Release in "Produktion" (z.B. nach drei Monaten) m viele kleine Releases (z.B. monatlich) m Im Prinzip "iterativen" Lebenszyklusmodells (wie beim Unified Process) m frühes Feedback durch Kunden m Steuerung noch möglich m automatisches Testen Funktionalität geht nicht verloren m Achtung: Altdatenbestände / festgeschriebene Bedienungsabläufe können Redesign-Schritte behindern

31 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Gemeinsamer Codebesitz m Keine Aufteilung des Programms in Verantwortungsbereiche m Jeder ist für das gesamte verantwortlich m Jeder darf überall beliebig ändern m Aber: die Tests müssen weiter durchlaufen m Das machen wir in Fujaba auch so m funktioniert gut (obwohl wir bisher nur wenig automatische Tests haben)

32 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Coding Standards m damit "gemeinsamer Code-Besitz" funktioniert muss Code möglichst überall gleich aussehen m starke Coding Standards werden benötigt m Paar-Programmierung stellt Einhaltung der Standards sicher m das machen wir in Fujaba mit Eclipse

33 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Refactoring m Refactoring heißt Code-Reorganisation / kleiner Redesign-Schritte l Copy-Paste Code in Methoden auslagern l Klassenhierarchie überarbeiten l Hilfsklassen, -methoden, -strukturen einführen l... m Immer wenn man was sieht, was man mal überarbeiten sollte, auf die Task- Card schreiben m bevor man neue Funktionalität implementiert, gegebenenfalls Desginänderungen vornehmen m während der Implementierung nicht gleichzeitig refactorn m nach der Implementierung Refactoring-Tasks abarbeiten

34 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Kontinuierliche Systemintegration m fertige Teilfunktionalitäten werden so früh wie möglich (täglich) in die Team-Master-Kopie integriert m dafür gibt es einen extra Integrations-PC m das machen wir mit SVN

35 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University 40 Stunden Woche m müde Leute machen Fehler m müde Leute sind unproduktiv m Kent möchte genügend Zeit für seine Kinder haben m entspricht allen allgemeinen Empfehlungen zur Produktivität von Arbeitskräften m widerspricht der industriellen Praxis (gerade bei IT-Start- Ups)

36 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Rollen in einem XP-Projekt m Programmierer: l fast alle sind Programmierer l Tests schreiben l Refactoring l Tests implementieren l kommunizieren l pairen m Kunde l ein Kundenvertreter vor Ort l "lebende" Anforderungsdefinition l funktionale Anforderungen als Stories formulieren l funktionale Tests schreiben l Funktionalität für die Releases auswählen l Verbindung nach Hause halten

37 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Rollen in einem XP-Projekt m Tester l einer im Team l unterstützt den Kunden beim Schreiben der funktionalen Tests m Tracker l einer im Team l schiebt die "Done" Markierungen auf dem Balkenplan weiter l führt Produktivitätsstatistiken m Coach l einer im Team l verantwortlich für die Einhaltung / Umsetzung der XP Prinzipien l wichtig beim Einstieg in die XP-Arbeitsweise l etwas auch für die Architektur verantwortlich: wenn nötig, Refactoring initiieren

38 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Rollen in einem XP-Projekt m Consultant l XP fördert / produziert "allround" Programmierer l für komplizierte / neue Technik(en) braucht man gegebenenfalls einen Berater m Big Boss l der "Projektmanager" l vertritt / beschützt das Team nach außen hin l trifft gelegentlich Personalentscheidungen l mischt sich nicht in technische Sachen / die eigentliche Arbeit ein

39 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Bewertung m XP hat viele gute Elemente / "Best Practices" l Test-First Prinzip l Paar-Programmierung (Reviewing funktioniert oft schlecht) l Planungsspiel und On-Site-Kunde (wenn das der Kunde mit macht) m XP hat klare Beschränkungen l kleine Projekte l keine sicherheitskritischen Systeme wo zertifizierte Entwicklungsprozesse verlangt werden m XP und Softwaretechnik sind eigentlich kein Widerspruch

40 Scrum / Kunagi: m User Stories / Tasks wie XP m Product Owner == Onsite Customer m Kleine Releases m Burn Down Charts >== Planungsspiel m Scrum Master >== ? m Daily Scrum Meeting >== ? Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

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

42 Semat Software Engineering Method and Theory m Ivar Jacobson m Comming soon … Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

43 Das liebe Geld m Angebot m Bestellung m Rechnung m Festpreis Produkt (Design by Budget) m Dienstleistung (Arbeitsstunden) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

44 Twenty dirty tricks to train software engineers; Ray Dawson ICSE 2000 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

45


Herunterladen ppt "Fachgebiet Software Engineering Übersicht © 09.02.2014 Albert Zündorf, Kassel University Vorgehensmodelle: Wasserfallmodell."

Ähnliche Präsentationen


Google-Anzeigen