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

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

Lösungen zum Test objektorientierter Software

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

Mehr

Agile Softwareprozess-Modelle

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

Mehr

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

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

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

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

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

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

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

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

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

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

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

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

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

Was versteht man unter einem Softwareentwicklungsmodell?

Was versteht man unter einem Softwareentwicklungsmodell? Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen

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

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

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

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

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

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

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

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

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

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

Realisierung von Softwareprojekten. Bachelorstudiengang Informatik/IT-Sicherheit. Autoren: Hans-Georg Eßer Prof. Dr.-Ing. Felix C.

Realisierung von Softwareprojekten. Bachelorstudiengang Informatik/IT-Sicherheit. Autoren: Hans-Georg Eßer Prof. Dr.-Ing. Felix C. 20 60 10 30 35 50 70 90 5 7 11 12 15 21 24 33 38 43 45 52 55 65 67 69 80 85 96 Bachelorstudiengang Informatik/IT-Sicherheit Realisierung von Softwareprojekten Autoren: Hans-Georg Eßer Prof. Dr.-Ing. Felix

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

- 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 - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

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

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

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

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

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

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

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

Mehr

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

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

Mehr

Scrum in der Praxis (eine mögliche Umsetzung)

Scrum in der Praxis (eine mögliche Umsetzung) Scrum in der Praxis (eine mögliche Umsetzung) ALM Talk, 26. Oktober 2011 Stefan Stettler Ausgangslage Viele Projektbeteiligte Verkauf, Entwickler, PM, Designer, Ergonomen Unterschiedliche Sichten und Vorstellungen,

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

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

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

Some Software Engineering Principles

Some Software Engineering Principles David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen

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

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

Ü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

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

Software Engineering

Software Engineering Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE

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

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

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

(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

IKP Uni Bonn Medienpraxis EDV II Internet Projekt

IKP Uni Bonn Medienpraxis EDV II Internet Projekt IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

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

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

Software Engineering. Organisation von Softwareentwicklungsprojekten

Software Engineering. Organisation von Softwareentwicklungsprojekten Software Engineering Organisation von Softwareentwicklungsprojekten Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

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

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

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

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

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

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

Fragebogen zur Anforderungsanalyse

Fragebogen zur Anforderungsanalyse Fragebogen zur Anforderungsanalyse Geschäftsprozess Datum Mitarbeiter www.seikumu.de Fragebogen zur Anforderungsanalyse Seite 6 Hinweise zur Durchführung der Anforderungsanalyse Bevor Sie beginnen, hier

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

Agiles Projektmanagement

Agiles Projektmanagement Agiles Projektmanagement A B U S I N E S S P E R S P E C T I V E Christian Setzwein Agenda Rahmenbedingungen für Projekte Der Umgang mit Unsicherheit im klassischen PM Agiles PM: Techniken, Prinzipien,

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] 1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl

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

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

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

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

Software Engineering

Software Engineering Software Engineering Informatik II. 9. Software-Entwicklung Dokumentation Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden Ausarbeitungen

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

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN 1 EINLEITUNG Auch Unternehmen, die Software-Produkte einkaufen, stehen vor der Herausforderung, eine geeignete Auswahl treffen zu müssen. Neben

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

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

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

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

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

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

Wachsende Anzahl kommunaler Aufgaben Schwindende Finanzspielräume Demografischer Wandel Hohe IT-Ausstattung der Arbeitsplätze > Technische

Wachsende Anzahl kommunaler Aufgaben Schwindende Finanzspielräume Demografischer Wandel Hohe IT-Ausstattung der Arbeitsplätze > Technische Wachsende Anzahl kommunaler Aufgaben Schwindende Finanzspielräume Demografischer Wandel Hohe IT-Ausstattung der Arbeitsplätze > Technische Komplexität steigt > Wachsende Abhängigkeit von der IT Steigende

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG CONTINUOUS DELIVERY Entmystifiziert WIE SOFTWARE LIEFERN? 01.07.2014 2 WAS IST CONTINUOUS DELIVERY? Robust Wiederholbar Effektiv 01.07.2014 3 LANDSCHAFTEN Continuous Integration Public / Private Hybrid

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

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

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

Rezeptverwaltungs-Software: Kurzanleitung

Rezeptverwaltungs-Software: Kurzanleitung Rezeptverwaltungs-Software: Kurzanleitung Die CD des Medienpakets Restaurant & Gast enthält u. a. eine Rezepte-Software inkl. vielen Rezepten des Buches. Die Software berechnet Nährwerte auf Grundlage

Mehr