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

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

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

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001

Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001 Extreme Programming ACM/GI Regionalgruppe Bremen, 12.6.2001 Tammo Freese OFFIS, Oldenburg freese@acm.org http://www.tammofreese.de Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de

Mehr

Extremes Programmieren

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

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

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

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

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

- 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

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

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

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

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

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

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

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

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

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

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

(und was wir davon lernen können!)

(und was wir davon lernen können!) extreme Programming (und was wir davon lernen können!) extreme Programming Eine Einführung - basierend auf Kent Beck: extreme Programming explained Addison Wesley (2000) http://www.extremeprogramming.org

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

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

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

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

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

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

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

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

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

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

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Verlages gestattet. Agiles Projektmanagement Scrum, Use

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

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

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

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

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

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

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

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

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

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

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

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

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

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

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

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

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

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

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

Agiles Requirements Engineering mit Scrum. Rainer Fetscher Neuss, 16. November 2010

Agiles Requirements Engineering mit Scrum. Rainer Fetscher Neuss, 16. November 2010 Agiles Requirements Engineering mit Scrum Rainer Fetscher Neuss, 16. November 2010 1 Inhalt A. Vorstellung Creditreform B. Grundprinzipien in SCRUM C. IST-Stand D. Ausgangssituation E. Der Weg F. Fazit

Mehr

Agile Methoden. David Tanzer. Oliver Szymanski

Agile Methoden. David Tanzer. Oliver Szymanski Agile Methoden David Tanzer Oliver Szymanski Ziel von Softwareentwicklung Anforderungen zuverlässig und effizient in lauffähige Software verwandeln. Ziel von Softwareentwicklung Bedürfnisse des Kunden

Mehr

AGILE SOFTWAREENTWICKLUNG NACH BERTRAND MEYER (AGILE!)

AGILE SOFTWAREENTWICKLUNG NACH BERTRAND MEYER (AGILE!) HOCHSCHULE ESSLINGEN FAKULTÄT INFORMATIONSTECHNIK STUDIENGANG SOFTWARETECHNIK UND MEDIENINFORMATIK AGILE SOFTWAREENTWICKLUNG NACH BERTRAND MEYER (AGILE!) WISSENSCHAFTLICHE PRÜFUNG WOJCIECH LESNIANSKI 22.01.2016

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

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

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

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

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

Agile Software-Entwicklung: Überblick und Techniken. Prof. Dr. Stefan Kowalewski Dr. Carsten Weise 1/29

Agile Software-Entwicklung: Überblick und Techniken. Prof. Dr. Stefan Kowalewski Dr. Carsten Weise 1/29 Agile Software-Entwicklung: Überblick und Techniken Prof. Dr. Stefan Kowalewski Dr. Carsten Weise 1/29 Kapitel I Der agile Ansatz 2/29 Agilität agil = flink, beweglich geringer bürokratischer Aufwand wenige

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

2. Teil Porträt Alistair Cockburn Crystal Orange Crystal Orange Web (Fallstudie)

2. Teil Porträt Alistair Cockburn Crystal Orange Crystal Orange Web (Fallstudie) 2. Teil Porträt Alistair Cockburn Crystal Crystal Web (Fallstudie) 1 Porträt Alistair Cockburn - 1975: Abschluss in Informatik in Cleveland - bis 1984: verschiedene Arbeiten im Bereich der Computergrafik

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

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

SE Besprechung. Übung 3 Softwareprozesse

SE Besprechung. Übung 3 Softwareprozesse SE Besprechung Übung 3 Softwareprozesse SE, 08.11.11 Mengia Zollinger Analyse der Systemkomponenten(3 Punkte) Mögliche Ansätze: 3-Schichten-Architektur (tree-tier-architecture) Präsentation Anwendungslogik

Mehr

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm Übersicht Kurze Situationsübersicht Diskussion Prozesse Challenges in der SW-Entwicklung Wie geht Scrum

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

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

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

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

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

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

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

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

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

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

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

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

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

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

Softwareentwicklung: Variablen, Risiken, wirtschaftliche Gesichtspunkte. Jens Müller TU-Dresden

Softwareentwicklung: Variablen, Risiken, wirtschaftliche Gesichtspunkte. Jens Müller TU-Dresden Softwareentwicklung: Variablen, Risiken, wirtschaftliche Gesichtspunkte TU-Dresden Variablen: Überblick Kosten (Personal, Material) Zeit (Projektdauer) Qualität (z.b. Funktionalität, Zuverlässigkeit) Leistungsumfang

Mehr

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

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 Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

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

Qualitätsmanagement mit Continuous Integration Untersuchung anhand einer Machbarkeitsstudie in der Praxis. Abschlußpräsentation zur Studienarbeit

Qualitätsmanagement mit Continuous Integration Untersuchung anhand einer Machbarkeitsstudie in der Praxis. Abschlußpräsentation zur Studienarbeit Qualitätsmanagement mit Continuous Integration Untersuchung anhand einer Machbarkeitsstudie in der Praxis Abschlußpräsentation zur Studienarbeit Lars Gohlke Diplom-Informatiker (FH) University of Applied

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

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