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

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

Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1 3. Analyse Gliederung: 1. Einführung 2. Anforderungsdefinition 3. Analyse

Wasserfallmodell versus Scrum - fernuni-hagen.de · PDF fileFernuniversität Hagen Lehrgebiet Programmiersysteme Prof. Dr. Friedrich Steimann Feithstraße 152 58097 Hagen Wasserfallmodell

Programmiermethodik SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1338)

Ansatz zur Strukturierung verschiedener Konstruktions- und ... · VDI 2221/2222 Wasserfallmodell V-Modell Y-Modell Systems Engineering Münchener Vorgehensmodell (MVM) (Lindemann)

Design Pattern SS 15 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)

Programmierung unter GNU/Linux für Einsteiger · 2016. 9. 8. · Testgetriebene Softwareentwicklung 4/35. Programmierung Entwicklungsmodelle Wasserfallmodell Extreme Programming

Fachgebiet Software Engineering Übersicht © 09.02.2014 Albert Zündorf, Kassel University Compilerbau und Reverse Engineering m Vorlesung im Wintersemester

Gruppe IV Soziale Netzwerke und Cyber-Mobbing 09.02.2014 1

Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1 6. Tipps, Tricks, Idiome Gliederung: 1. Einführung 2. Anforderungsdefinition 3

Maisonette-Wohnung (71 m²) in Köln-Porz (Zündorf) gesucht wird ein/e Mitbewohner/-in zur Gründung einer Wohngemeinschaft

Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)

Grundlagen der Pharm. Biologie – Morphologie und Anatomiedingerma/Podcast/MorphologieSS11_1.pdf · Grundlagen der Pharm. Biologie – Morphologie und Anatomie Dr. Ilse Zündorf

09.02.2014 Seite 1 Europe, Mediterranean, Central Asia Sabine Jüngling Abteilungsstrategie 706 Fokussierung Diversifizierung Dezentralisierung Fachverbund

Fachgebiet Software Engineering Übersicht © 09.02.2014 Albert Zündorf, Kassel University Client Architecture Data Model GUI KI Socket Connection

Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Kostenschätzung m Wieviel Stunden brauchen Sie, um ein Programm

Quantitative Spektroskopie des Überriesen Deneb 09.02.2014 Florian Schiller Betreut durch Norbert Przybilla

Programmiermethodik WS 2013/14 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1332)

Programmiermethodik WS 2012/13 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1332)

intuitive Verständlichkeit • Ausdrucksmächtigkeit ... fileAlbert Zündorf GraphentechnikSS09.03.BasicRewriteRulesfm.fm,5 Def. 5: Basisgraphersetzungsregeln Eine Graphersetzungsregel

Dr. Thorsten Arendt Marburg, 22. Oktober 2015 · Das Wasserfallmodell von Barry Boehm 3 Software-Evolution WS 2015/2016 System Requirements Software Requirements Preliminary Design