P R A X I S A R B E I T. extreme Programming im Einsatz

Größe: px
Ab Seite anzeigen:

Download "P R A X I S A R B E I T. extreme Programming im Einsatz"

Transkript

1 BERUFSAKADEMIE LÖRRACH STAATLICHE STUDIENAKADEMIE UNIVERSITY OF COOPERATIVE EDUCATION P R A X I S A R B E I T extreme Programming im Einsatz Verfasser: Kurs: Fachrichtung: Fachbereich: Firma: Abgabetermin: Sebastian Galenski WWI 2000 B Wirtschaftsinformatik SE FreiNet GmbH 04. November 2002

2 Seite 2 von 20 Inhaltsverzeichnis Seite Abbildungsverzeichnis... 3 Abkürzungsverzeichnis...4 Anlagenverzeichnis Problemstellung Was ist extremes Programmieren? Definition Ursprung Praktiken der extremen Programmierung Kleine Releases Planungsspiel Tests Systemmetapher Einfacher Entwurf Refaktorisierung Pair Programming Gemeinsames Code-Eigentum Fortlaufende Code-Integration Stunden-Woche Kundenvertreter im Team Programmierrichtlinien Voraussetzungen für XP Vergleich Traditionelle Modelle XP Folgen und Konsequenzen Anwendungsbereich Bewertung und Ausblicke von XP Literaturverzeichnis Anlagen... 20

3 Seite 3 von 20 Abbildungsverzeichnis Abbildung 1 Der XP Prozess in seiner Gesamtheit... 8 Abbildung 2 Zusammenhang: Release, Iteration, Task... 9 Abbildung 3 Entwicklung der Kosten einer Änderung in traditionellen Modellen Abbildung 4 Entwicklung der Kosten einer Änderung im XP-Modell Tabelle 1 Konsequenzenvergleich... 17

4 Seite 4 von 20 Abkürzungsverzeichnis XP... extreme Programming (dt. extremes Programmieren)

5 Seite 5 von 20 Anlagenverzeichnis Anlage 1 Ehrenwörtliche Erklärung...20 Anlage 2 Firmenbestätigung...20

6 Seite 6 von 20 0 Problemstellung Bei herkömmlichen Prozessmodellen besteht immer das Problem, nicht schnell genug beziehungsweise unkompliziert im Nachhinein oder während der Softwareentwicklung auf Kundenwünsche zu reagieren. Ebenso werden mit anwachsendem Fortschritt des Projektes die Kosten für solche Änderungen immer höher. Die Prozessmodelle sind schwergewichtig. Schwergewichtige Modelle wie der Wasserfall bieten nicht die Flexibilität, welche heutzutage erwartet wird. Die Änderungen von Kundenseite aus, kommen meist erst dann, wenn der Kunde das entwickelte System zum ersten Mal in der Realität gesehen und angetestet hat. Es stellt sich meist heraus, dass die Vorstellungen doch ganz anders, beziehungsweise das Handling nicht optimal ist. Ein erster Ansatz nach dem Wasserfall-Modell war der Unified Process. Zwar muss er hinsichtlich der Teamgröße, Kultur und Projektart konfiguriert werden, aber er passt schon besser in die Anforderungen an ein leichtgewichtigeres Modell. Jedoch bietet er den Entwicklern und Kunden noch nicht allzu viel Freiheit. Nicht jedoch das im folgenden beschriebene Prozessmodell der extremen Programmierung. Es ist leichtgewichtig, weil es die Änderungswünsche der Kunden wie auch die Möglichkeiten der Entwickler berücksichtigt. Vor allem der hohe Stellenwert der Änderungswünsche macht XP zu einem leichtgewichtigen und flexiblen Prozess.

7 Seite 7 von 20 1 Was ist extremes Programmieren? 1.1 Definition Extremes Programmieren ist ein Prozessmodell für die objektorientierte Software- Entwicklung. Wie der Name andeutet, handelt es sich um ein code-zentriertes Prozessmodell, bei dem bestimmte Techniken in extremem Maße angewendet werden. Einige Annahmen und Techniken von XP stehen in starkem Widerspruch zum Software Engineering, das vom Capability Maturity Model und ISO 9000 geprägt ist. Diese Widersprüche führen zu lebhaften Diskussionen über diverse Aspekte von XP. Durch einen hochgradig iterativen Entwicklungsprozess ist XP prädestiniert für Projekte mit unklaren oder sich ändernden Anforderungen. 1.2 Ursprung XP wurde von Kent Beck, Ward Cunningham und Ron Jeffries entworfen und durch Erprobung in Projekten weiterentwickelt. Im Ansatz ist XP gedacht für kleinere Projekte mit unklaren und sich immer wieder ändernden Anforderungen. Der Kunde hat gleichzeitig hohe Ansprüche an die Qualität der Software. Zwei Forderungen motivierten die Entwicklung von XP: Develop for today Man konzentriert sich ausschließlich auf Probleme, welche heute anstehen. Es wird davon ausgegangen, dass eine Änderung jederzeit und mit vertretbarem Aufwand eingearbeitet werden kann. Do the simplest thing that could possibly work Es wird immer das einfachste Design verwendet, um ein Problem zu lösen (näheres dazu finden sie unter 2.5 Einfacher Entwurf ). 2 Praktiken der extremen Programmierung XP ist ein Prozessmodell, das sich durch 12 Techniken auszeichnet, die in der XP Terminologie Praktiken heißen. Diese Praktiken sind nur in ihrer Gesamtheit sinnvoll (Abbildung 1).

8 Seite 8 von 20 Abbildung 1 Der XP Prozess in seiner Gesamtheit Das Weglassen wichtiger Praktiken kann zum Scheitern des XP Ansatzes führen, da sich die Praktiken gegenseitig stützen. Keine der eingesetzten Praktiken ist wirklich neu - neu ist die Kombination und der extreme Grad, in dem diese Praktiken eingesetzt werden. 2.1 Kleine Releases Aufgrund der sich ständig ändernden Anforderungen wird ein hochgradig iterativer Entwicklungsprozess mit einen Release Zyklus von ein bis drei Monaten angestrebt. Ein Release besteht aus mehrere Iterationen. Die Iterationen, mit einer Dauer von ein bis vier Wochen, wiederum zerfallen in Arbeitspakete (Tasks) mit einer Dauer von ein bis drei Tagen (Abbildung 2). Nach jeder Iteration kann der Kunde Abweichungen von seinem Wünschen feststellen und korrigieren.

9 Seite 9 von 20 Abbildung 2 Zusammenhang: Release, Iteration, Task Das erste Release sollte bereits ein funktionierendes Kernsystem sein, das dann in weiteren Releases inkrementell ausgebaut wird. So bekommt der Kunde frühzeitig von ihm als wichtig eingeschätzte Funktionalitäten. Die Entwickler haben den Vorteil des schnellen Feedbacks. 2.2 Planungsspiel Die Planung der Iterationen erfolgt im Planungsspiel. Ziel des Spieles ist es, für die kommende Iteration auf Grund vorgegebener Spielregeln die verfügbaren Entwicklungsressourcen und die Kundenwünsche in Einklang zu bringen. Die Anforderungen werden in Form sogenannter User Storys niedergelegt. Sie sind ähnlich den UML Use Cases, werden in der Regel auf je eine Karteikarte notiert und sind rudimentäre Anwendungsfälle. Der Kunde versieht seine Storys mit Prioritäten. Er bestimmt, welche Storys in der kommenden Iteration zu implementieren sind und wann die Iteration abgeschlossen sein soll. Daraufhin geben die Entwickler Schätzungen ab, wie viel Aufwand zur Implementierung notwendig sein wird. In diese Schätzung wird noch ein sogenannter (loadfactor) eingebaut. Mit dessen Hilfe, bekommt der Entwickler noch eine Art Puffer, um seiner Abschätzung gerecht zu werden. Falls der Aufwand die verfügbaren Ressourcen übersteigen sollte, muss der Kunde einige Storys auf spätere Iterationen verschieben.

10 Seite 10 von 20 Dies wird so lange wiederholt, bis ein Gleichgewicht erreicht ist. Auf diese Weise gelangt man zu einer relativ realistischen Planung für die kommende Iteration. Falls die Schätzungen der Entwickler daneben lagen, kann bei Bedarf nachverhandelt werden. 2.3 Tests Automatisierte Tests spielen die zentrale Rolle bei XP - ohne sie ist XP nicht realisierbar. Da außer den User Storys keine Spezifikation des Systems und seiner Bestandteile vorliegt, wird das Wissen über die gewünschte Funktion in Testfällen niedergelegt. Die Entwickler schreiben Tests für ihre Klassen (unit tests). Diese beschreiben die Klassenfunktion aus technischer Sicht, haben Dokumentationscharakter und geben eine Art von Sicherheit beim Durchführen von Änderungen. Der Kunde entwickelt Testfälle für seine User Storys (functional tests), die von einem Tester in Tests umgesetzt werden. Durch sie sollen funktionale Fehler möglichst früh aufgedeckt werden und der Kunde hat durch sie auch einen Nachweis, dass eine Funktionalität auch bereitgestellt wird. Die Testfälle werden so implementiert, dass sich alle Tests jederzeit automatisch ausführen lassen. Wichtig ist, dass die Entwickler erst die Tests schreiben und dann implementieren. Das zwingt sie dazu, eine rudimentäre Spezifikation der zu testenden Funktionen in Form von Fallbeispielen anzugeben. Sobald dann die Implementierung vorliegt, kann sie gegen die Tests geprüft werden. Die Tests müssen schnell und automatisch ausführbar sein. 2.4 Systemmetapher Die Systemmetapher steht für die grundsätzliche Idee hinter der Architektur des Systems. Sie soll sowohl für die Entwickler als auch für den Kunden verständlich sein. Die Systemmetapher soll dazu dienen, einen Architekturentwurf zu ersetzen. Sie soll eine Vorstellung darüber vermitteln, welche Form neue Programmteile annehmen sollten und an welcher Stelle sie sich in das System integrieren lassen.

11 Seite 11 von Einfacher Entwurf Beim Entwurf soll immer nach einer einfachen Lösung gesucht werden, die nur die momentan anstehenden Anforderungen abdeckt. Beck nennt das the simplest thing that could possibly work 1. Zukünftige Erweiterungen sollen zunächst nicht berücksichtigt werden, da sich die Anforderungen ändern können, wodurch sich die zusätzlich eingebaute Flexibilität als nutzlos erweist. Sollten später Änderungen notwendig sein, wird der Entwurf refaktorisiert. Der einfache Entwurf enthält verschiedene Aspekte: Erfüllung der Anforderungen Der Entwurf muss der Aufgabe gerecht werden, wie sie zu diesem bestimmten Zeitpunkt verstanden wird. Redundanzfreiheit Jede Information darf nur einmal gehalten werden. Refactoring Das Design besteht aus der geringst möglichen Anzahl von Klassen, Attributen und Methoden (mehr dazu finden Sie unter 2.6 Refaktorisierung ). 2.6 Refaktorisierung Refaktorisierung dient zur Vereinfachung des Entwurfs eines bestehenden Systems unter Beibehaltung der Semantik. Dabei soll die Verständlichkeit und die Änderbarkeit des Codes verbessert werden. Da die gewünschte Funktion in den Tests niedergelegt ist, kann nach einer Refaktorisierung durch Tests geprüft werden, ob dabei Fehler unterlaufen sind. Laut Beck lässt sich beobachten, dass ein großer Teil der Dokumentation, die erstellt wird, mangels laufender Anpassung, sehr schnell veraltet und daher gar nicht benutzt wird. Deshalb beschränkt XP die Dokumentation auf den Code selbst. Dieser muss daher in hohem Maße selbsterklärend sein. Die Selbsterklärungsfähigkeit soll vor allem aus der Struktur und der Namensgebung kommen. Wenn der Code an einer Stelle eines erklärenden Kommentars bedarf, sollte so refaktorisiert werden, dass der Code auch ohne Kommentar verständlich ist. Nach dem Vorgang der Refaktorisierung sollte das Design wieder aus einer geringst möglichen Anzahl von Klassen, Attributen und Methoden bestehen. Durch den ständigen Fluss im Design spricht man hier auch von kontinuierlichem Refactoring 2. 1 /1/ 2 /6/

12 Seite 12 von Pair Programming Entwurf, Codierung und Test werden von zwei Entwicklern gemeinsam durchgeführt. Sie haben nur eine Tastatur, eine Maus und einen Rechner. Hier muss also eine Rollenverteilung stattfinden. Es gibt eine Implementierer-Rolle und eine Reviewer-Rolle. Bei Bedarf tauschen die beiden Entwickler die Rollen. Die Paarbildung ist nicht fest, sondern man sucht sich für jedes Arbeitspaket einen geeigneten Partner aus. Die dynamische Paarbildung hat den positiven Nebeneffekt, dass sich das Wissen über alle Aspekte des Systems auf alle Entwickler verbreitet. Wenn ein Entwickler ausfällt, kann er daher relativ problemlos ersetzt werden. Während also einer der beiden Entwickler programmiert, prüft der Partner den Code auf Schreibfehler und logische Fehler. Außerdem behält er andere Ziele im Auge, z. B. ob der Code zum Entwurf passt, der Entwurf verbessert werden kann oder ob zu dem Code noch Tests fehlen. Auf diese Weise werden der Code, der Entwurf und die Tests einer kontinuierlichen Begutachtung unterzogen. Williams und Cockburn 3 haben die Auswirkungen des Programmierens in Paaren empirisch untersucht. Ihrer Untersuchung zufolge nimmt der Entwicklungsaufwand im Vergleich zu allein arbeitenden Entwicklern nur leicht (um etwa 15%) zu, während der Code besser verständlich ist und viel weniger Fehler (bis zu 60%) aufweist. 2.8 Gemeinsames Code-Eigentum Der entstehende Code gehört nicht einem bestimmten Entwickler, sondern allen Entwicklern im Projekt. Das bedeutet, dass jedes Entwicklerpaar jederzeit überall Änderungen vornehmen darf, um z. B. die Verständlichkeit des Codes zu verbessern. Dabei besteht natürlich die Gefahr, dass die Änderungen fehlerhaft sind. Daher muss das Paar nach jeder Änderung alle Tests durchlaufen. 2.9 Fortlaufende Code-Integration Neu entwickelter oder geänderter Code wird alle paar Stunden in die aktuelle Code-Basis integriert. Zur Integration dient ein dedizierter Integrationsrechner. Dort spielt ein Paar seine 3 /2/, siehe Seite 3 und Seite 9

13 Seite 13 von 20 Änderungen ein und lässt danach alle Tests laufen. Treten dabei Fehler auf, muss das Paar seine Änderungen zurücknehmen oder dafür sorgen, dass alle Fehler behoben werden. Auf diese Weise ist immer ein lauffähiges System verfügbar. Außerdem zerfallen durch das Vorgehen die Arbeitspakete in kleine, überschaubare Teile Stunden-Woche Das Programmieren in Paaren stellt hohe Ansprüche an die Partner. Beide müssen jederzeit hoch konzentriert bei der Sache sein. Das können sie aber nicht, wenn sie erschöpft sind. Daher werden bei XP geregelte Arbeitszeiten gefordert (die 40 Stunden sind dabei nur ein Richtwert). Überstunden, hier definiert als unfreiwillige Mehrarbeit, sollen nur in Ausnahmefällen gemacht werden Kundenvertreter im Team Da keine echte Spezifikation, User Stories sind nicht detailliert genug, vorhanden ist, gibt es viele Rückfragen an den Kunden. Daher muss ein Vertreter des Kunden für die Entwickler permanent verfügbar sein (on-site customer). Es soll sich um einen zukünftigen Anwender des Systems handeln. Der Kundenvertreter entwickelt die Testfälle für die funktionalen Tests Programmierrichtlinien Um das Arbeiten in Paaren und das gemeinsame Code-Eigentum zu erleichtern, halten sich alle Entwickler an feste Programmierrichtlinien. Diese werden von den Entwicklern untereinander vereinbart und strikt eingehalten. Auf diese Weise erhält man einheitlichen Code, der von allen verstanden und geändert werden kann. 3 Voraussetzungen für XP Wie man den einzelnen Praktiken entnehmen kann, hat XP einige Voraussetzungen für eine erfolgreiche Implementierung:

14 Seite 14 von 20 Die Änderungskosten steigen höchstens logarithmisch mit der Zeit. Ansonsten wird der Ansatz des einfachsten Entwurfs durch die ständige Refaktorisierung zur Integration neuer Anforderungen zu teuer. Das Management, alle Teammitglieder und der Kunde müssen sich auf die XP- Praktiken einlassen. Außerdem muss der Kunde in der Lage sein, einen qualifizierten Mitarbeiter abzustellen. Das Entwicklerteam darf nicht zu groß sein. Obergrenze: Entwicklern. Die Entwickler sind an einem Ort konzentriert und haben die gleichen Arbeitszeiten, da sonst Kommunikation und Paarbildung erschwert sind. Die Testfälle müssen automatisch und in kurzer Zeit ausführbar sein. Lange Übersetzungs- und Ausführungszeiten sind von großem Nachteil. Beck empfiehlt eine schrittweise Einführung von XP. Es sollte immer nur eine Praktik auf einmal eingeführt werden, und zwar immer diejenige, die das momentan dringlichste Problem angeht 4. Natürlich sind dabei die Abhängigkeiten der Praktiken untereinander zu berücksichtigen. 4 Vergleich 4.1 Traditionelle Modelle Zu den traditionellen Modellen zählen zum Beispiel das Wasserfall-Modell oder der Unified Process. Diese Modelle sind schwergewichtig sie bieten keine bis wenig Flexibilität und Freiheit. Auf Äderungswünsche von Kunden kann vom Entwickler nur schwer eingegangen werden beziehungsweise die Änderung wird mit fortschreitendem Projektstand immer teurer. Beim Wasserfall wird oftmals sogar von einem exponentiellen Anstieg, beim Unified Process von einem linearen Anstieg gesprochen (Abbildung 3). 4 /1/

15 Seite 15 von 20 Abbildung 3 Entwicklung der Kosten einer Änderung in traditionellen Modellen Ausgangspunkt für diese Annahme sind immer folgende Überlegungen: Was kostet eine Änderung in der Analysephase? Was kostet eine Änderung in der Designphase? Was kostet eine Änderung in der Implementierungsphase? Im Gegensatz zu XP steht dem ganzen Prozess ein größerer Planungsaufwand (Analysephase) und eine erst späte Implementierung/Codierung (Implementierungsphase) gegenüber. 4.2 XP XP ist ein leichtgewichtiges Prozessmodell. Diese Eigenschaft wird wie folgt geprägt: Geringer Planungsaufwand zu beginn des Projektes frühe Codierung Änderungswünsche der Kunden werden berücksichtigt De Möglichkeiten der Entwickler werden berücksichtigt Nur ein einfaches Design erlaubt, Anforderungen, die später auftreten, auch erst zu diesem späteren Zeitpunkt zu berücksichtigen, ohne dass die Kosten dabei linear oder gar exponentiell ansteigen (Abbildung 4).

16 Seite 16 von 20 Abbildung 4 Entwicklung der Kosten einer Änderung im XP-Modell Durch den Einsatz von objektorientierten Sprachen, einfachem Design, automatisierten Tests und Erfahrungen im Ändern sind die geringen Änderungskosten also zu erklären. 4.3 Folgen und Konsequenzen In einigen Bereichen gibt es jedoch noch nicht genug Erfahrung mit XP, sodass man dort vorerst nicht sagen kann, ob es mit XP funktioniert: Festpreisprojekte Das Angebot richtet sich nach den User Stories. Es sollte kein Problem sein, neue Anforderungen aufzunehmen. Für jede neue Anforderung wird eine andere vorhandene Anforderung gleichen Umfangs herausgenommen. Framework-Entwicklung Bei der Framework-Entwicklung ist kein Kunde mit im Team. Jedoch könnte ein Teammitarbeiter, der bereits eine Applikation in der Zieldomäne des Frameworks entwickelt hat, die Rolle des Kunden übernehmen. Er bestimmt dann, welche Anforderungen im nächsten Release berücksichtigt werden, kümmert sich um die funktionalen Test, spezifiziert die meisten Anforderungen und legt deren Prioritäten fest. Dabei besteht die größte Gefahr darin, dass technische und geschäftsbedingte Entscheidungen vermischt werden. Welche Konsequenzen zieht man nun, wenn man sich für ein traditionelles oder ein XP- Modell entscheidet:

17 Seite 17 von 20 Traditionelle Modelle (z.b. Unified Process) XP-Modell Änderungen antizipieren Erst bedenken wenn gefordert Änderungsmöglichkeiten einbauen Nicht einbauen, nur das notwendigste Implementieren Umfang der Software komplex einfach Anfangskosten hoch gering Gesamtkosten gering gering Projektfortschritt Anfangs langsamer schneller Gesamtzeit gering gering Tabelle 1 Konsequenzenvergleich 5 Anwendungsbereich Der Einsatz von XP ist nur dann möglich, wenn die Voraussetzungen (siehe 3 Voraussetzungen für XP ) erfüllt sind. XP empfiehlt sich für Projekte, welche unsichere oder sich ständig ändernde Anforderungen aufweisen. Meist ist dies bei individueller Software der Fall. Die Entwicklung von Standardsoftware mit XP ist hier natürlich nicht ausgeschlossen. Jedoch wird über die Skalierbarkeit und die möglichen Projektgrößen noch kontrovers diskutiert, da es noch an Erfahrungen mangelt. 6 Bewertung und Ausblicke von XP An Kritik am extremen Programmieren mangelt es nicht. Im folgenden einige herausgegriffene Punkte 5 : Das Fehlen einer expliziten Spezifikation und einer Entwurfsdokumentation ist besonders kritisch. Es gibt zwar die Dokumentation in Form der Testfälle und des Codes, doch ist es zweifelhaft, ob diese allein auch für Entwickler ausreicht, die nicht Mitglied im XP-Team waren. Ohne die beteiligten Entwickler geht es vermutlich nicht. 5 /3/

18 Seite 18 von 20 Das gemeinsame Code-Eigentum kann zu einigen Problemen führen. Die Entwickler müssen mangels eines Übersichtsdokuments den Entwurf als mentales Modell im Kopf haben. Ändert ein anderer Entwickler den Entwurf im Code, muss das mentale Modell angepasst werden, da sonst mit falschen Voraussetzungen codiert wird und dadurch Fehler entstehen. Außerdem kann es zu konkurrierenden Änderungen an denselben Klassen kommen, was zu Integrationsproblemen führt. Darüber hinaus ziehen Änderungen am Entwurf in der Regel auch Änderungen an den Tests nach sich. Da viele XP-Praktiken voraussetzen, dass die Tests korrekt sind, muss hier besonders sorgfältig gearbeitet werden. Ob die Begutachtung beim Programmieren in Paaren wirklich ausreicht, die Schwächen des Testansatzes zur Qualitätssicherung zu kompensieren, ist fraglich. Problematisch ist, dass XP bisher nur unzureichend dokumentiert ist, insbesondere wenn es um die konkrete Umsetzung geht. Zum Beispiel ist das Konzept der Systemmetapher reichlich nebulös. Es gibt auch keine Daten, die nachweisen, dass XP anderen Vorgehensweisen überlegen ist. Empirische Untersuchungen wurden bisher nicht durchgeführt. Andererseits gibt es viele positive Berichte aus Projekten, in denen XP eingesetzt wurde. Das bekannteste Projekt ist das C3-Projekt bei DaimlerChrysler 6. Bei Beck finden sich auch Berichte aus anderen Projekten. Aus den Berichten geht hervor, dass alle beteiligten Gruppen mit XP zufrieden sind. Entwickler berichten von hoher Motivation und Freude bei der Arbeit, das Management freut sich über die gute Termineinhaltung, und die Kunden begrüßen die frühe Verfügbarkeit eines funktionierenden Systems sowie die hohe Qualität. 6 /4/

19 Seite 19 von 20 Literaturverzeichnis /1/ BECK, Kent Extreme Programming Explained: Embrace Change. /2/ WILLIAMS, Laurie / COCKBURN, Alistair The Costs and Benefits of Pair Programming oder CD:\Quellen\williams_laurie.pdf /3/ Xp-forum /4/ C3 Team: Chrysler Goes to Extremes. Distributed Computing, Oktober 1998, /5/ ECKSTEIN, Jutta XP extreme Programming oder CD:\Quellen\eckstein_jutta.pdf /6/ FOWLER, Martin Refactoring Wie Sie das Design vorhandener Software verbessern Addison-Wesley 2000

20 Seite 20 von 20 Anlagen Ehrenwörtliche Erklärung Ich versichere hiermit, dass ich die vorliegende Praxisarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Freiburg i. Br. Ort 04. November 2002 Datum Unterschrift Firmenbestätigung Freiburg i. Br. Ort 04. November 2002 Datum Unterschrift und Stempel

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Erschienen im Informatik-Spektrum 23(2), 2000, S. 118-121 als Aktuelles Schlagwort Ralf Reißing Universität Stuttgart Institut für Informatik Abteilung Software Engineering Breitwiesenstr.

Mehr

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Stefan Roock, roock@jwam.de APCON Workplace Solutions GmbH & Universität Hamburg Vogt-Kölln-Strasse 30 22527 Hamburg Germany

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Praktische Softwaretechnologie Vorlesung 8

Praktische Softwaretechnologie Vorlesung 8 Praktische Softwaretechnologie Vorlesung 8 Martin Giese Johann Radon Institute for Computational and Applied Mathematics Österr. Akademie der Wissenschaften Linz PSWT 2006 12. Dezember 2006 p.1/32 Die

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

Extreme Programming 1/28

Extreme Programming 1/28 Extreme Programming 1/28 Risiko: Das Grundproblem 2/28 Jedes Projekt der Softwareentwicklung hat Risiken: Der Termin wird nicht eingehalten Die Kosten werden nicht eingehalten Die Qualitätsziele werden

Mehr

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 2. Methodologien Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 2. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Die Evolution von extreme Programming

Die Evolution von extreme Programming Die Evolution von extreme Programming Wieso extreme Programming so ist, wie es ist. Von Michael Kircher Der aktuelle Trend bei der Software-Entwicklung wird derzeit von Java und E-Commerce Projekten getrieben.

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Extreme Programming (XP)

Extreme Programming (XP) Einführung in Extreme Programming 1 Extreme Programming (XP), wolf@jwam.de Martin Lippert, lippert@jwam.de Stefan Roock, roock@jwam.de Universität Hamburg & APCON Workplace Solutions GmbH Vogt-Kölln-Strasse

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Extreme Programming. Lutz Kirchner. www.exedio.com

Extreme Programming. Lutz Kirchner. www.exedio.com Extreme Programming Lutz Kirchner www.exedio.com 2 Blaues Wunder: eine bewunderte Ingenieursleistung Ein Bedürfnis wird elegant erfüllt Die Technologie ist neuartig Das Design ist hochmodern und rekordhaltig

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Kapitel 15. Agile Softwareentwicklung und

Kapitel 15. Agile Softwareentwicklung und Vorlesung Softwaretechnologie Wintersemester este 2009 R O O T S Kapitel 15. Agile Softwareentwicklung und Extreme Programming (XP) Stand: 05.02.2009 Was sind Agile Methodologien? Eine Methodologie ist

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Agile Methoden: Leichtgewichte der Softwaretechnik

Agile Methoden: Leichtgewichte der Softwaretechnik Agile Methoden: Leichtgewichte der Softwaretechnik Prof. Dr. Gerald Lüttgen Lehrstuhl Softwaretechnik & Programmiersprachen Universität Bamberg www.swt-bamberg.de 2011 Gerald Lüttgen Vortrag IT Cluster

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Software-Engineering

Software-Engineering SWE6 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 6: Projektmanagement Wasserfallmodell SWE6 Slide 2 Wasserfallmodell Zeitliche Einordnung in Breiten-/Tiefenraster Funktionale Breite

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Software Expedition. Seminar Systems Engineering extreme Programming

Software Expedition. Seminar Systems Engineering extreme Programming Software Expedition Seminar Systems Engineering extreme Programming Übersicht (1) Einleitung Von der klassischen Expedition zur Software-Expedition Software-Expedition als Vorgehensweise in einem instabilen

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Werte 2.0 - Weil ich es mir wert bin. Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de

Werte 2.0 - Weil ich es mir wert bin. Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de Werte 2.0 - Weil ich es mir wert bin Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de Danke, Johannes... 2 Ich sah sie überall... 3 Werte des Extreme Programmings Kommunikation

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

Software entwickeln mit extreme Programming

Software entwickeln mit extreme Programming Martin Lippert Stefan Roock Henning Wolf Software entwickeln mit extreme Programming Erfahrungen aus der Praxis dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1 Die XP-Werte 4 1.2 Die XP-Prinzipien

Mehr

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Einleitung 3 Methoden

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Informationssystemanalyse Personal Software Process 8 1

Informationssystemanalyse Personal Software Process 8 1 Informationssystemanalyse Personal Software Process 8 1 Personal Software Process Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung. Vorgehensmodelle der Software-Entwicklung

Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung. Vorgehensmodelle der Software-Entwicklung Einführung in die Software-Entwicklung 7 Software-Entwicklung im Team 1. Von der Idee zur Software 2. Funktionen und Datenstrukturen 3. Organisation des Quellcodes 4. Werte- und Referenzsemantik 5. Entwurf

Mehr

XP und RUP Passt das zusammen?

XP und RUP Passt das zusammen? XP und RUP Passt das zusammen? Markus Barchfeld Roland Sand Johannes Link Andrena Objects GmbH, Albert-Nestler-Straße 9, 76131 Karlsruhe {markus.barchfeld roland.sand johannes.link}@andrena.de Zusammenfassung.

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung Seminar: Softwareentwicklung in der Wissenschaft Agile Softwareentwicklung Benjamin Pöpel Fakultät für Mathematik, Informatik und Naturwissenschaften Fachbereich Informatik Betreuer: Christian Hovy 23.

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Oktober 2014 PRODUKTENTWICKLUNG. Dr. Ralf Lauterbach

Oktober 2014 PRODUKTENTWICKLUNG. Dr. Ralf Lauterbach PRODUKTENTWICKLUNG Dr. Ralf Lauterbach Produktentwicklung digitaler Produkte - was ist zu tun? - Generelle Aufgaben bei jeder digitalen Produktentwicklung Produktmanagement Marktanalysen Markteingangsstrategie

Mehr

Agile Software-Entwicklung: Vom Hype zum Daily Business

Agile Software-Entwicklung: Vom Hype zum Daily Business Agile Software-Entwicklung: Vom Hype zum Daily Business Prof. Dr. Sven Overhage Lehrstuhl für Wirtschaftsinformatik, insb. Industrielle Informationssysteme Otto-Friedrich-Universität Bamberg sven.overhage@uni-bamberg.de

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Übersicht Entwicklungsprozess Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

MSP: Methoden des Software-Entwicklungsprozesses

MSP: Methoden des Software-Entwicklungsprozesses WS 2005/06 Mastermodul CS 5002 MSP: Methoden des Software-Entwicklungsprozesses Teamentwicklung extreme Programming Projekttagebuch Prof. Dr. Klaus Quibeldey-Cirkel Fachhochschule Gießen-Friedberg Forming

Mehr

Kapitel 1 Software-Prozessmodelle

Kapitel 1 Software-Prozessmodelle Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Extreme Programming (XP)

Extreme Programming (XP) (XP) Ausarbeitung zum Referat vom 20.11.2006 im Rahmen der Veranstaltung Softwareengineering-Projekt an der TU Berlin im WS 2006/07 Vorgelegt von: Matrikelnummer: 178256 Betreuer: Marco Mosconi Inhaltsverzeichnis

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java Hochschule München FK 07 SS 2009 Theis Michael - Senior Developer HVB Information Services GmbH März 2009 Grundlagen des

Mehr

Einführung Wasserfall RUP XP. Teil VIII. Prozessmodelle

Einführung Wasserfall RUP XP. Teil VIII. Prozessmodelle Teil VIII Prozessmodelle 424 8.1 Einführung Prozessmodelle legen fest: Elemente und Reihenfolge des Arbeitsablaufs Definition der Teilprodukte Fertigstellungskriterien notwendige Mitarbeiterqualifikationen

Mehr

extreme Programming Konzepte, Ziele, Methoden Praktische Erfahrungen aus XP-Projekten

extreme Programming Konzepte, Ziele, Methoden Praktische Erfahrungen aus XP-Projekten extreme Programming Konzepte, Ziele, Methoden Praktische Erfahrungen aus XP-Projekten Eine Arbeit im Rahmen des Seminars Refactoring in extreme Programming von Universität Paderborn AG Prof. Kastens Januar

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

Prozesse und Projekte

Prozesse und Projekte Universität Stuttgart 30.04.08 Prozesse und Projekte Planung unter schwierigen Randbedingungen Matthias Wetzel wetzelms@informatik.uni-stuttgart.de Abteilung Software Engineering 1 / 24 Agenda Inhalt der

Mehr

extreme Programming Was ist xp Wie wird heute gearbeitet? eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland

extreme Programming Was ist xp Wie wird heute gearbeitet? eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland extreme Programming eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Was ist xp Wie wird heute gearbeitet? Ein durchgehend geplanter

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr