Extreme Programming (XP)

Größe: px
Ab Seite anzeigen:

Download "Extreme Programming (XP)"

Transkript

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

2 Inhaltsverzeichnis 1. Einleitung Klassische und agile Vorgehensmodelle 3 2. Probleme und Risiken bei Softwareprojekten 5 3. XP aus der Sicht von Kent Beck Der Lösungsansatz bei XP Die Verfahren Planspiel Kurze Releasezyklen Metapher Einfaches Design Testen Refactoring Pair Programming Gemeinsame Verantwortlichkeit Continuous Integration Stunden-Woche Kunde vor Ort Programmierstandards Wann XP nicht eingesetzt werden kann Besonderheiten und Vorteile von XP Gegenargumente Testqualität Preis- und Vertragsmodelle Literatur 19 Seite 2 von 19

3 1. Einleitung Helmut Balzert beschreibt im Lehrbuch der Software-Technik, was unter einem Vorgehensmodell verstanden wird: Jede Software-Entwicklung soll in einem festgelegten organisatorischen Rahmen erfolgen. Ein [...] Vorgehensmodell [...] beschreibt einen solchen Rahmen. In ihm wird festgelegt, welche Aktivitäten in welcher Reihenfolge und von welchen Personen erledigt werden und welche Ergebnisse [...] dabei entstehen und wie diese in der Qualitätssicherung überprüft werden. (Balzert 2000, S. 54) Bei der Entwicklung von Software ist ab einer bestimmten Projekt- und Teamgröße ein Vorgehensmodell erforderlich. Ohne Vorgehensmodell steigen Kosten- und Zeitaufwand deutlich an und die Qualität des Produkts kann nicht sichergestellt werden. 1.1 Klassische und agile Vorgehensmodelle Es gibt eine Vielzahl von Vorgehensmodellen. Eine der ältesten und einfachsten Varianten ist das sog. Wasserfallmodell: Analyse Entwurf Implementierung Integration und Test Betrieb und Wartung Seite 3 von 19

4 Dabei werden die dargestellten Phasen nacheinander durchlaufen. Eine neue Phase kann nur nach Abschluß der vorherigen begonnen werden, ggf. wird zur vorhergehenden Phase zurückgesprungen. Die klassischen Modelle bauen in der Regel auf dem Wasserfallmodell auf. Dabei wird das Modell abgewandelt und weiterentwickelt, es werden Zyklen eingeführt, oder es wird parallelisiert. Trotzdem sind die einzelnen Phasen des Wasserfallmodells in der dargestellten Reihenfolge zumindest in Ansätzen wiederzuerkennen. Agile Modelle unterscheiden sich stärker vom Wasserfallmodell, hier werden einzelne Phasen komplett in Frage gestellt oder in eine völlig neue Reihenfolge gebracht. Eins der bekanntesten agilen Modelle ist Extreme Programming (XP), dieses Modell soll in der vorliegenden Ausarbeitung näher betrachtet werden. Seite 4 von 19

5 2. Probleme und Risiken bei Softwareprojekten Softwareprojekte unterscheiden sich von Entwicklungsprojekten in anderen Bereichen, wie z.b. bei der Herstellung materieller Güter. Die 3 wesentlichen Unterschiede sind (Sommerville 2001, S. 84): 1. Software ist nicht greifbar. Bei einem Bauprojekt kann man den Fortschritt von außen sehen, Software hingegen ist nicht unmittelbar sichtbar. Für eine Bewertung des Projektfortschritts muß mehr Aufwand betrieben werden, oder man muß sich auf Aussagen anderer verlassen. 2. Für jedes Projekt muß ein geeignetes Vorgehensmodell gefunden werden, dabei handelt es sich in der Regel um eine Anpassung eines bestehenden Modells auf die aktuelle Situation. Erfahrungen mit diesem Modell existieren meist nicht. 3. Inhaltlich sind Softwareprojekte fast immer einzigartig, sie unterscheiden sich stark von allen vorhergehenden Projekten. Gesammelte Erfahrungen mit ähnlichen Techniken oder Lösungen können oft nicht auf das aktuelle Projekt übertragen werden. Das führt dazu, daß die Durchführung von Software-Entwicklungsprojekten mehr Probleme und Risiken birgt, als es in anderen Bereichen der Fall ist. Deshalb stellt auch die Einhaltung einen vorher festgelegten Zeit- und Budgetplans eine besondere Herausforderung dar. Seite 5 von 19

6 3. XP aus der Sicht von Kent Beck Kent Beck hat mit seinen Publikationen entscheidend für die Popularität von XP beigetragen. In diesem Kapitel soll XP aus seiner Sicht dargestellt werden. 3.1 Der Lösungsansatz bei XP Im vorigen Kapitel wurde gezeigt, daß es insbesondere bei Softwareprojekten schwierig ist, Zeitplan und Budget einzuhalten. XP bietet folgende Lösung: Normalerweise kann davon ausgegangen werden, daß die 3 Variablen Zeit, Kosten und Qualität einen festen Zusammenhang bilden. Ändert man bei einem Projekt die Rahmenbedingungen für eine dieser Variablen, so hat das Einfluß auf die beiden anderen. So erhöht z.b. Zeitdruck die Kosten und mindert die Qualität. Der Zusammenhang ist nicht symmetrisch, so kann man z.b. mit einem höheren Budget die Fertigstellungszeit nicht beliebig verkürzen. Diese Betrachtung setzt zunächst einen konstanten Leistungsumfang voraus. XP läßt einen variablen Umfang zu, wodurch Termine, Kosten und Qualitätsstandard auch bei auftretenden Schwierigkeiten eingehalten werden können. Im Falle von Problemen oder Verzögerungen werden Abstriche bei den Leistungsmerkmalen der Software gemacht, das Produkt wird zum geplanten Termin, aber mit weniger Funktionen ausgeliefert. Da bei XP immer die wertvollsten Funktionen zuerst implementiert werden, fallen weniger wichtige Features weg. Der Auftraggeber ist dadurch in einer deutlich besseren Lage, er kann die Software termingerecht einsetzen und muß lediglich auf einen Teil der Funktionalität verzichten. Andernfalls müßte er länger auf den Einsatz warten, was normalerweise mit mehr Verlusten oder Opportunitätskosten verbunden ist. Ein weiteres Problem bei Softwareprojekten sind nachträgliche Änderungen der Anforderungen. Hier muß normalerweise mit relativ hohen Zusatzkosten gerechnet werden, da bereits konzipierte oder entwickelte Komponenten Seite 6 von 19

7 umgeschrieben oder komplett ersetzt werden müssen. Je später die Änderungen angefordert werden, desto höher die Kosten. Das kann auch dazu führen, daß die in Betrieb befindliche Software an einem bestimmten Zeitpunkt unrentabel wird, da die Anpassungen an die sich verändernden Bedürfnisse mit der Zeit immer kostenintensiver werden, die Software ist dann nicht mehr wartbar oder erweiterbar. XP setzt hier auf eine günstigere Kostenkurve: Quelle: Während bei konventionellen Verfahren die Änderungskosten mit der Zeit stark ansteigen, wird bei XP eine flache Kurve erzielt. Die Kosten nähern sich asymptotisch einem Maximalwert an, den sie auch nach längerer Zeit nicht überschreiten. Dieser Effekt wird vor allem durch automatisierte Tests und Refactoring erreicht. Seite 7 von 19

8 3.2 Die Verfahren In XP ist eine Reihe von Verfahren definiert, nach denen bei der Entwicklung vorgegangen wird. Teilweise unterscheiden sich diese Verfahren deutlich von der klassischen Vorgehensweise. Es folgt eine kurze Beschreibung der einzelnen Verfahren Planspiel Das Planspiel ist das Planungsverfahren von XP. Auf Storycards werden die Anforderungen in einer für Nicht-Techniker verständlichen Form aufgeschrieben. Der Kunde legt die Prioritäten fest, diese bilden gleichzeitig die Implementierungsreihenfolge. Außerdem bestimmt der Kunde, welche Releases es geben soll und welche Funktionalitäten jeweils enthalten sind. Anschließend werden Taskcards erstellt, die die Anforderungen auf kleine Arbeitsaufgaben mit einem Aufwand von mehreren Stunden bis zu einigen Tagen aufteilen. Die Teammitglieder schätzen den Aufwand der einzelnen Tasks. Gleichzeitig wird aus den vorangegangenen Tasks das Verhältnis zwischen geschätztem Aufwand und tatsächlich benötigter Kalenderzeit berechnet. Mit diesen Daten kann dann eine Zeitplanung für das aktuelle Projekt erstellt werden. Wenn sich Anforderungen ändern, werden die Storycards ggf. wieder neu priorisiert und in die entsprechende Reihenfolge gebracht. So wird sichergestellt, daß immer die für den Kunden wertvollsten Features zuerst implementiert werden Kurze Releasezyklen Die Releasezyklen werden so kurz wie möglich gehalten. Gerade so kurz, daß das Produkt für den Kunden sinnvoll einsetzbar ist. Dadurch bekommt das Team frühzeitig Feedback und der Kunde kann schneller sehen, ob das Projekt in die richtige Richtung geht. Oft werden die Anforderungen erst dann richtig klar, wenn der Kunde mit dem Produkt arbeiten kann. Änderungen und Ergänzungen der Anforderungen werden auf diese Weise früher eingebracht. Seite 8 von 19

9 3.2.3 Metapher Die Metapher dient der Kommunikation der Architektur nach innen und außen. Sie beschreibt umgangssprachlich die wesentlichen Konzepte, Komponenten und Funktionen des Produkts Einfaches Design Bei den herkömmlichen Vorgehensmodellen versucht der Entwickler vorausschauend zu arbeiten. Er wird beim Softwaredesign möglichst frühzeitig alle bis dahin bekannten Aspekte der Anwendung berücksichtigen, um späteren Änderungen und Erweiterungen vorzubeugen. Diese Vorgehensweise entspricht auch der natürlichen Intuition. Bei XP wird genau entgegengesetzt vorgegangen. Design und Implementierung sollen nur die im Moment gerade relevanten Aspekte beinhalten. Anforderungen, die im aktuellen Task noch nicht umsetzt werden sollen, werden im technischen Design auch nicht berücksichtigt. Statt dessen wird immer nur die einfachste Lösungsvariante gewählt, die die Anforderungen des aktuellen Task erfüllt, aber auf keinen Fall mehr leistet. Es wird darauf vertraut, daß man später bei Bedarf die fehlenden Teile oder Aspekte leicht hinzufügen kann. Diagramme können während des Designentwurfs erstellt werden, danach werden sie aber wieder verworfen. So fällt der Aufwand nicht an, das Diagramm zum Code aktuell zu halten Testen Programmierer schreiben vor der Implementierung oder dem Refactoring zuerst die Komponententests. Danach folgt die Entwicklung. Wenn alle Tests erfolgreich laufen, ist die Implementierung des Tasks abgeschlossen. Dann kann die Komponente integriert werden. Die Integration ist abgeschlossen, wenn alle Komponententests des gesamten Projekts erfolgreich sind. Die Komponententests sind automatisiert und laufen innerhalb kurzer Zeit durch. Seite 9 von 19

10 Kunden schreiben Funktionstests, mit denen sie prüfen können, inwieweit die geforderten Leistungsmerkmale implementiert sind. Diese Tests müssen nicht in jedem Fall zu 100% erfolgreich durchlaufen. Bei Bedarf finden weitere Tests statt, wie z.b. Paralleltest oder Lasttest Refactoring Die konventionelle Strategie läuft normalerweise darauf hinaus, daß ein Refactoring, also ein Überarbeiten und Ändern des Software-Designs, möglichst vermieden wird. Bei XP wird ständig überarbeitet. Da immer nur die einfachste Lösungsvariante implementiert wird, ohne vorausschauend alle bekannten oder denkbaren zukünftigen Anforderungen zu berücksichtigen, wird es häufig erforderlich, bestehende Komponenten zu erweitern. Refactoring ist auch notwendig, um Redundanzen zu vermeiden. Falls gerade eine Komponente entwickelt wird, die einer bestehenden Komponente in Teilen gleicht, dann wird in der Regel ein Refactoring durchgeführt, um zu verhindern, daß derselbe Code mehrfach existiert Pair Programming Grundsätzlich sitzen immer 2 Entwickler gemeinsam an einem Rechner, aber nur einer bedient Tastatur und Maus. Der andere schaut nicht nur zu, sondern denkt mit. Durch diesen permanenten Review erhöht sich die Qualität des Codes. Außerdem prüft er, ob die aktuell verfolgte Lösungsstrategie im übergeordneten Kontext funktioniert und sinnvoll ist. Weiterhin fördert das Programmieren in Paaren die Kommunikation und die Weitergabe von Fachwissen zwischen den Mitgliedern des Teams. Da sich die Paare bei jedem Task wieder neu bilden, hat jeder Einzelne innerhalb kurzer Zeit mit mehreren anderen Teammitgliedern Kontakt. Seite 10 von 19

11 Quelle: Beck 2003, S. 78 Das Foto zeigt ein XP-Team bei DaimlerChrysler. Die Paare können sich gegenseitig sehen und hören. So können sie ggf. helfen, wenn sie Informationen haben, die ein anderes Paar gerade benötigt Gemeinsame Verantwortlichkeit Es gibt keine Zuständigkeiten einzelner Entwickler für bestimmte Bereiche oder Komponenten. Jeder kann und soll im gesamten Projekt arbeiten und Änderungen einbauen. So ist jeder für den kompletten Code verantwortlich. Vorteile: Der Code eines anderen Entwicklers kann kein Hindernis für den eigenen Task sein. Man kann ihn selbst ändern, wenn das für die aktuelle Aufgabe sinnvoll erscheint. Man muß auf niemanden warten und muß sich auch nicht mit unzweckmäßigen Schnittstellen abfinden. So bildet sich auch kein komplizierter Code. Denn wenn ein Teammitglied schwer zu lesenden oder umständlichen Code einbaut, dann ist die Seite 11 von 19

12 Wahrscheinlichkeit groß, daß dieser Code später von einem anderen Mitglied überarbeitet oder ersetzt wird. Voraussetzung für die gemeinsame Verantwortlichkeit sind natürlich die automatisierten Tests. Andernfalls könnte man nicht so leicht Änderungen einbauen, da schwer feststellbar wäre, ob alle anderen Komponenten nach der Änderung noch reibungslos funktionieren Continuous Integration Das fertige Produkt wird nach jeder Integration einer Änderung neu gebaut, mindestens einmal am Tag. Das ist Voraussetzung, um zeitnah die Integrationstests durchführen zu können Stunden-Woche Überstunden dürfen nur in Ausnahmefällen gemacht werden. XP erfordert ausgeruhte und kreative Mitarbeiter. Keiner soll unter Streß stehen Kunde vor Ort Ein Mitarbeiter des Kunden, der die Anforderungen gut kennt, muß bei dem XP-Team vor Ort mitarbeiten. Er ist Ansprechpartner für das Festlegen der Anforderungen und setzt die Prioritäten der einzelnen Leistungsmerkmale. Außerdem schreibt er die Integrationstests. Oft wird der Mitarbeiter damit nicht dauerhaft ausgelastet sein. In diesem Fall kann er die übrige Zeit dazu verwenden, sein normales Tagesgeschäft zu betreiben Programmierstandards Damit alle mit dem Code der anderen Teammitglieder gut umgehen können, sind Standards erforderlich, wie z.b. Code-Conventions. 3.3 Wann XP nicht eingesetzt werden kann XP eignet sich nicht für die folgenden Fälle: Seite 12 von 19

13 - in einer Unternehmenskultur, bei der die Teams genaue Vorgaben zum Vorgehensmodell bekommen, z.b. wenn zuerst eine ausführliche Spezifikation erstellt werden muß, - wenn ein zu hoher Erfolgsdruck herrscht, oder nicht erfüllbare Aufgaben gestellt werden, - bei Teams mit mehr als 10 Mitgliedern, - wenn Technologien im Einsatz sind, die die flache Kostenkurve für spätere Änderungen nicht ermöglichen, z.b. Entwicklung von Hardware, - wenn Build und Test nicht innerhalb kurzer Zeit durchgeführt werden können, z.b. bei langen Compilierzeiten, - falls kein Kunde vor Ort zur Verfügung steht, - oder wenn die räumlichen Gegebenheiten ungünstig sind, z.b. bei vielen kleinen weit voneinander entfernten Räumen. Seite 13 von 19

14 4. Besonderheiten und Vorteile von XP Der wichtigste Unterschied zwischen XP und den klassischen Vorgehensmodellen ist die Kostenentwicklung bei Änderungen und Erweiterungen während des Entwicklungsprozesses: der Aufwand steigt nicht wie sonst üblich mit der Zeit stark an, sondern nimmt nur leicht zu. Dadurch werden 2 Vorteile ermöglicht, durch die sich XP stark von den klassischen Modellen abgrenzt: 1. Änderungen bei den Anforderungen können zu jeder Zeit und mit überschaubarem Aufwand berücksichtigt werden. Das macht XP zu einem idealen Vorgehensmodell für Entrepreneure und für Softwareentwicklungen für Märkte, die sich gerade im Wandel befinden. 2. Die Konzeption und Umsetzung von Aspekten, die aktuell nicht die höchste Priorität haben, können ohne Nachteile auf später verschoben werden. Das führt zu besseren Entscheidungen, da zu einem späteren Zeitpunkt mehr und bessere Informationen zur Verfügung stehen. Im Fall einer zwischenzeitlichen Änderung der Anforderungen erspart man sich Anpassungen oder Neuentwicklungen der betroffenen Komponenten. Außerdem ergibt sich durch die zeitliche Verschiebung von Investitionen ein Zinsvorteil. Das Produkt ist in der ersten Version früher einsatzfähig und der Kunde kann die Vorteile eines schnellen Markteintritts nutzen oder zusätzliche Revenues generieren. Der günstige Verlauf der Änderungskosten wird im wesentlichen durch die automatisierten Tests erreicht. Diese vereinfachen den nachträglichen Umbau von Code und Schnittstellen deutlich. Nach einer Änderung kann der Entwickler sofort sehen, in welchen Komponenten es zu Fehlern gekommen ist. Werden keine Fehler angezeigt, kann er relativ sicher sein, daß es durch seine Änderung nicht zu Problemen kommt. Andere zeit- und kostenintensive Qualitätssicherungsmaßnahmen entfallen. Auch das permanente Refactoring führt zu niedrigeren Änderungskosten. Durch die häufigen Umbauten, die am System vorgenommen werden, Seite 14 von 19

15 erwerben die Entwickler die Fähigkeit, bestehenden Code effizient zu überarbeiten. Seite 15 von 19

16 5. Gegenargumente 5.1 Testqualität Der Erfolg von XP hängt in hohem Maße von den automatisierten Tests ab. Wurden Änderungen oder Erweiterungen im Produkt integriert, werden anschließend die Tests angestoßen um festzustellen, ob alle Komponenten reibungslos funktionieren und ob sich das System in allen Nutzungssituationen korrekt verhält. Die Aussagekraft der Tests hängt dabei stark von der Qualität und Vollständigkeit der Tests ab. Wenn wichtige Tests fehlen, oder bestehende Tests einen wichtigen Teil der Funktionalität nicht abdecken, dann werden eventuelle Bugs in diesem Bereich nicht gefunden. Das XP-Team hält das System für fehlerfrei, weil alle vorhandenen Tests erfolgreich durchgelaufen sind. Tatsächlich können Fehler im Produkt enthalten sein, die erst im produktiven Betrieb sichtbar werden und dort Schaden verursachen können. Die Anweisung von XP an die Entwickler lautet, alle Tests zu schreiben, die ihnen einfallen und die einen Informationsgewinn bringen. Es gibt keinen Prozeß der sicherstellt, daß hier nichts vergessen oder übersehen wird. 5.2 Preis- und Vertragsmodelle Ein möglicher Einwand gegen XP ist, daß man mit XP bei der Wahl des Vertragsmodells eingeschränkt ist. Insbesondere die häufig gewählte Variante des Werkvertrags zum Festpreis kann nicht angewendet werden. Bei diesen Verträgen werden die Anforderungen vor Abschluß im Pflichtenheft genau festgelegt, das wird dann Bestandteil des Vertrages. Sollen während des Projektverlaufs hier Änderungen erfolgen, zum Beispiel wenn eine Komponente wegfällt und statt dessen eine andere hinzukommen soll, dann muß diese Änderung erst ausgehandelt und der Vertrag überarbeitet werden. Dabei kann wertvolle Zeit verloren gehen, Kosten- und Zeitplan können sich verändern. Unter diesen Bedingungen kann XP nicht eingesetzt werden, da man bei XP den Umfang leicht ändern können muß. Seite 16 von 19

17 Als Alternative bietet sich das Vertragsmodell "Agiler Festpreis" an (Oestereich 2006). Dabei wird, ähnlich wie beim Festpreis, für eine bestimmte Menge von Anforderungen ein verbindlicher Gesamtpreis vereinbart. Ändern sich die Anforderungen, werden einzelne Leistungspakete durch andere ersetzt, der Vertrag bleibt im übrigen unverändert. Es dürfen aber nur Leistungen gegeneinander ausgetauscht werden, die denselben Wert haben, sodaß der Gesamtumfang des Projektes konstant bleibt. Dazu wird ein für den Auftraggeber transparentes Verfahren definiert, mit dem der Wert einzelner Teilleistungen geschätzt werden kann. Unter der Voraussetzung, daß ein brauchbares Verfahren für die Schätzung existiert, vereint dieses Vertragsmodell die Vorteile von Festpreis und Vergütung nach Aufwand, und es ist bei agilen Projekten gut einsetzbar: - Der Auftraggeber hat Budgetsicherheit. - Die Anforderungen sind inhaltlich flexibel. - Der Auftragnehmer kann mit einen festen Gesamtumsatz kalkulieren. Wie beim klassischen Festpreis auch, liegt das Umsetzungsrisiko beim Auftragnehmer. Sein Gewinn fällt um so höher aus, je weniger Aufwand anfällt. Steigt hingegen der Aufwand über den geschätzten Wert hinaus, muß er gegebenenfalls Verluste hinnehmen. Daraus erwächst für den Auftragnehmer die Motivation, möglichst wenig Aufwand zu betreiben, was sich nachteilig auf die Qualität auswirken kann. Dieses Problem besteht beim Vertrag nach Aufwand nicht, das Vertragsmodell ist natürlich für XP-Projekte gut anwendbar. Dabei besteht allerdings für den Auftragnehmer die umgekehrte Motivation: er ist jetzt an einem hohen Aufwand interessiert, denn so kann er seinen Gewinn maximieren. Die Interessen der Vertragspartner sind also entgegengerichtet, was eine ungünstige Ausgangsposition darstellen kann. Seite 17 von 19

18 Hinzu kommt, daß der Auftraggeber bei einer Abrechnung nach Aufwand keine Budgedsicherheit mehr hat, weshalb sich das Vertragsmodell in vielen Fällen nicht einsetzen läßt. Welcher Vertrag am besten geeignet ist, hängt außerdem stark vom Inhalt des Projekts und von der bestehenden Geschäftsbeziehung der Vertragspartner ab. Für Projekte, in denen XP zum Einsatz kommt, gibt es ein Repertoire an Vertragsmodellen, das für die meisten Fälle ausreichend Varianten bereitstellt. Der Nachteil, daß man mit XP bei der Vertragsgestaltung eingeschränkt ist, kommt daher nur selten zum tragen. Seite 18 von 19

19 6. Literatur Balzert 2000 BALZERT, HELMUT: Lehrbuch der Software-Technik, Bd. 1. Software-Entwicklung. Heidelberg, Berlin: Spektrum Akademischer Verlag GmbH (2000), 1. Nachdruck (2001). Beck 2003 BECK, KENT: Extreme Programming. München: Addison-Wesley Verlag (2003). Cockburn 2003 COCKBURN, ALISTAIR: Agile Software-Entwicklung. Bonn: mitp- Verlag (2003). Oestereich 2006 OESTEREICH, BERND: Der agile Festpreis und andere Preis- und Vertragsmodelle. In: OBJEKTspektrum Nr. 1/2006, S. 29f. Troisdorf: SIGS-DATACOM GmbH (2006). Summerville 2001 SUMMERVILLE, IAN: Software Engineering. München: Addison-Wesley Verlag, Pearson Studium (2001). Zuser 2004 ZUSER, WOLFGANG; GRECHENIG, THOMAS; KÖHLE, MONIKA: Software Engineering mit UML und dem Unified Process. München: Pearson Studium (2004). Seite 19 von 19

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

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

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

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

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

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

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

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

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

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

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

- 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

Software Engineering. Risikomanagement in der Softwareentwicklung

Software Engineering. Risikomanagement in der Softwareentwicklung Software Engineering Risikomanagement in der Softwareentwicklung Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

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

Ü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

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

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

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

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

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

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

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

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

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

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

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

Software Engineering Vorlesung für Medieninformatik

Software Engineering Vorlesung für Medieninformatik Software Engineering Vorlesung für Medieninformatik Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz 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

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

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

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL.

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. Die Erwartungen Ihrer Businesskunden an ihre IT steigen. Mehr denn je kommt es darauf an, die Software optimal am Kunden auszurichten

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

Weiterführende Literatur

Weiterführende Literatur Literatur [Art.Metriken06] Artikel Messbare Qualität in Anforderungsdokumenten. Veröffentlicht in: Java Magazin 1/2006. Manage IT! 2/2006. ObjektSPEKTRUM 4/2006. [Bandler94] Richard Bandler (1994) Metasprache

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

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

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

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

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

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

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

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

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

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Agile Softwareentwicklung Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Inhalt 1. Klassische Entwicklungstechnik 2. Agile Entwicklungstechnik - Allgemeines 3. Agiles Manifest

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

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

Zielvereinbarung. Team JAMT.

Zielvereinbarung. Team JAMT. Ziele des Projektes. Wer benötigt das Ergebnis des Softwareprojektes? Gruppenprozessleiter, welche keine Expertise auf dem Gebiet der Gruppenprozesserstellung haben Teams, die computergestützte Gruppenarbeit

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

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

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

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

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

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

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

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

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

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3.

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3. Projektplan Hive Version: 1.1 Autoren: Robin Goldberg (2453516) Hansjörg Schmauder (2531506) Benjamin Schmidt(2443953) Erstellt am: 15.02.2010 Letzte Änderung: 24.06.10 Inhaltsverzeichnis 1 Einleitung...

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

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

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Agiler Healthcheck Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Inhalt 1 2 3 Motivation Existierende Healthchecks Agiler Healthcheck der Allianz "Der Glaube an

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

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

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

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

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

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

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

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Kapitel 0: Vorlesungsüberblick Prof. Dr. Mario Winter SP2-0 FH Köln SP-2 (WI3) Vorlesungsüberblick 1. Softwaretechnik

Mehr

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen E-Mail : Berkan.Kutlutuerk@hs-furtwangen.de Seite

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

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Grundprinzipien der agilen Softwareentwicklung

Grundprinzipien der agilen Softwareentwicklung Grundprinzipien der agilen Softwareentwicklung Marie Claire Dzukou 38539 Natali Brozmann 40464 Wintersemester 14/15 1 Inhaltsverzeichnis 1 Agile Softwareentwicklung 3 2 Entstehung der agilen Softwareentwicklung

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

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

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

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

Software Engineering. Prozessmodelle zur Softwareentwicklung

Software Engineering. Prozessmodelle zur Softwareentwicklung Software Engineering Prozessmodelle zur Softwareentwicklung Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

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

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

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Qualitätsmanagement. Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner

Qualitätsmanagement. Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner Qualitätsmanagement Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner 2004, Bernhard Anzeletti, Rudolf Lewandowski, Klaudius Messner, All rights reserved,

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015 Migrationsstrategien Dr. Thorsten Arendt Marburg, 22. Januar 2015 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2014/2015 Überblick Probleme Wenn man ein bestehendes System re-engineered

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

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

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

P R A X I S A R B E I T. extreme Programming im Einsatz 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:

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

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

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

Das Kanbanboard Ein Beitrag zum Lean Software Development

Das Kanbanboard Ein Beitrag zum Lean Software Development Reklamations- QUALITY APPs Applikationen für das Qualitätsmanagement Das Kanbanboard Ein Beitrag zum Lean Software Development Autor: Prof. Dr. Jürgen P. Bläsing Bei Lean Software Development handelt es

Mehr