Die Evolution von extreme Programming
|
|
- Sara Meissner
- vor 2 Jahren
- Abrufe
Transkript
1 Die Evolution von extreme Programming Wieso extreme Programming so ist, wie es ist. Von Michael Kircher Der aktuelle Trend bei der Software-Entwicklung wird derzeit von Java und E-Commerce Projekten getrieben. Es gibt momentan immermehr Projekte, die in immer kürzerer Zeit fertig gestellt werden müssen. Aus diesem Grund werden häufig mächtige Frameworks, wie EJB und Servlets eingesetzt. Diese allein können aber nicht einen ausreichenden Leistungsgewinn in Bezug auf die Entwicklungszeit bringen. Es stellt sich die Frage wie man Software im Internetzeitalter schnell und trotzdem mit guter Qualität ausliefern und dabei noch das Risiko minimieren kann. Bei mächtigen Entwicklungsprozessen, wie der Rational Unified Process [Jacobsen], wird auf die Hilfe von OOA, OOD Werkzeugen, wie Rational Rose, gesetzt. Leider sind die Entwicklungsprozesse dadurch sehr aufwendig und erfordern damit einen sehr hohen Grundaufwand. Für kleinere Teams sind daher komplexe Entwicklungsprozesse oft nicht gerechtfertigt. Hier sind leichtgewichtige Entwicklungsprozesse gefragt. extreme Programming (XP) ist ein solcher leichtgewichtiger Entwicklungsprozess. Er basiert auf den pragramatischen Vorgehensweisen der Entwickler, aber auch der Projektleiter. Die Erfahrungen bis zum heutigen Tag zeigt, dass der Prozess sich bis zu Teamgrößen von Leuten anwenden läßt. Ist das Team größer, so steigt der Kommunikationsaufwand [Brooks] überproportional. Für XP heißt das, dass der Austausch von Wissen über direkte Gespräche, auf denen die Kommunikation in XP hauptsächlich beruht, nicht mehr effizient gestaltet werden kann und damit der enge Zusammenhalt des Entwicklungsteams verloren geht. Im Folgenden werden die Grundzüge von extreme Programming anhand von Problem-Lösungs Paaren dargestellt. Damit lässt sich zeigen wie aktuelle Probleme bei der Software-Entwicklung von XP gelöst werden. Risikomanagement durch interative Entwicklung Trotz vieler Jahre Erfahrung in Software Engineering und den Büchern von Frederick P. Brooks bergen Software-Entwicklungs Projekte noch immer sehr hohe Risiken. Diese Risiken sind vielfältig. Besonders hervorzuheben ist die Schätzung des Aufwandes und die schlecht
2 Kontrollmöglichkeiten. Was sich nicht fassen lässt, ist schwer zu messen und zu kontrollieren. Um das Risiko bei der Software-Entwicklung zu reduzieren ist es wichitg viele kurze Iterationen zu haben. Innerhalb einer Iteration wird das Software-System um vorher festgelegte Leistungsmerkmale erweitert. Am Ende einer jeden Iteration steht ein lauffähiges System, das in jeder Iteration mehr von der eigentlichen Funktionalität implementiert. Kurze Iterationen erlauben es in den Entwicklungsprozess eingreifen zu können und ihn an Ereignisse anzupassen. Solche Ereignisse können das Ausfallen eines Entwicklers, drastische Qualitätsverluste im Quellcode, oder eine Änderung der Anforderungen des Kunden sein. Je kleiner die atomaren Tätigkeiten einer Iteration sind, desto sanfter kann der Entwicklungsprozess gesteuert werden. Die Steuerung eines solchen Entwicklungsprozesses ist ähnlich dem Steuern eines PKWs auf einer Straß. Eines der wichtigsten Dinge, die ein Fahrschüler lernen muss ist das Gefühl für das Lenkrad, um ein Übersteuern in eine Richtung zu vermeiden. In traditionellen Entwicklungsprozessen spielt der Kunde nur zu gewissen Zeitpunkten eine Rolle. Hauptsächlich sind diese die Analysephase zu Beginn eines Projektes und die Abnahme der Software durch den Kunden am Ende des Projektes. Die geringe Involvierung des Kunden während der eigentlichen Entwicklung stellt jedoch ein erhebliches Risiko dar. XP versucht dieses zu minimieren. Zu diesem Zweck fordert XP den sogenannten On-Site-Customer. Das bedeutet, dass der Kunde, bzw ein von ihm ernannter Vertreter, in das Entwicklungsteam integriert ist. Der On-Site-Customer arbeitet bei dem Entwicklungsteam vor Ort im gleichen Raum wie die Entwickler. Der On-Site-Customer hilft bei der Steuerung des Entwicklungsprozess, indem er dem Team schnell Feedback über die akutelle und geplante neue Richtung geben kann. Der Kunde ist schließlich derjenige, der das Ziel am klarsten vor sich sieht. Eine der wichtigsten Regeln ist ständig ein lauffähiges System zu behalten. Die erste Iteration in einem neuen Projekt ist dafür verantwortlich ein solches zu erstellen. Die fortlaufende Integration neuer Funktionalität während den darauf folgenden Iterationen muss gewährleisten, dass das System weiterhin lauffähig bleibt. Planungs-Spiel statt unrealistischer Meilensteine Unrealistische Planung von Meilensteinen durch den Projektleiter führt bei den Entwicklern zu dem Gefühl Unmögliches erreichen zu
3 müssen und schon zu Anfang verloren zu haben. Letztendlich führt es zu unzufriedenen und frustrierten Entwicklern. Die Folge solcher Umstände ist das Überwechseln der Entwickler zu anderen Firmen, vielleicht sogar zur Konkurrenz. Dass dies ein enormer Wissensverlust für das Team bedeutet und ab einer gewissen Zahl von Verlusten das gesamte Projekt gefährden kann wird oft vergessen, bzw ignoriert. Das Planungs-Spiel, ein weiterer Hauptbestandteil von XP, soll dafür sorgen, dass weder nur Geschäftsinteressen, zumeist vertreten durch den Kunden und den Projektleiter, noch die Interessen der Entwickler einseitig oder vorrangig behandelt werden. Vielmehr wird eine Aufteilung beschlossen: Personen die Geschäftsinteressen vertreten entscheiden über den Fokus der Iterationen, die Priorität von Leistungsmerkmalen und welche Leistungsmerkmale zu welchem Zeitpunkt zur Verfügung stehen sollen. Die Entwickler hingegen entscheiden über den Aufwand, der notwendig ist um ein Leistungsmerkmal zu implementieren. Der Kunde formuliert seine Erwartungen über die Leistungsmerkmale in Form von Benutzungsbeispielen. Diese Anwendungsbeispiele werden auf Karten (größere Karteikarten) handschriftlich festgehalten. Während der Kunde Prioritäten auf die einzelnen Karten vergibt, schätzen die Entwickler den Aufwand, der notwendig ist um das entsprechende Leistungsmerkmal zu implementieren. Der Kunde und der Projektleiter respektieren und akzeptieren diese Schätzungen. Danach wählt der Kunde die Karten aus, welche er in der nächsten Iteration implementiert haben möchte. Die Entwickler schätzen dabei in Ideal-Tagen, die noch mit einem Last-Faktor multipliziert werden, um sie als absolute Schätzung abzugeben. Der Last-Faktor ist zu Beginn eines Projektes mit einem neuen Team meist unbekannt und muss daher zuerst ermittelt werden. Bei Teams, die schon zuvor an ähnlichen Projekten gearbeitet haben, liegen meist schon Erfahrungswerte vor. Er ergibt sich aus dem Verhältnis der eigentlichen Dauer einer Tätigkeit zu der Schätzung, wie sie die Entwickler anfangs genannt hatten. Die Entwickler lernen dabei das richtige Schätzen von Aufwänden und gewinnen das Vertrauen in den Prozess. Sie hängen also nicht mehr von den gutmütigen Schätzungen und Versprechungen des Projektleiters ab, sondern sind selbst für ihre Schätzungen verantwortlich. Durch das Planungs-Spiel hat der Kunde bei jedem Release Einfluss darauf, welche Funktionalität enthalten sein wird.
4 Teil von XP ist die Regel, dass den Entwicklern nicht mehr als eine 40-Stunden Woche zugemutet werden sollte. Die Praxis zeigt, dass Entwickler, die über einen längeren Zeitraum mehr als 40 Stunden pro Woche arbeiten, eine geringere Konzentration bei ihren Aufgaben haben. Viele Überstunden führen in der Regel zu vermehrten Fehlern im Programm-Code und dies nicht nur durch Nachlässigkeit beim Testen. Wartung durch einfache Architektur auf Basis von Entwurfsmustern erleichtern Die Wartung von großen Software-Systemen bereitet häufig große Probleme. Dass ein Stück Software nicht, oder nur mit sehr großem Aufwand, wartbar ist hat häufig mehrere Gründe. Unter anderem sind dies über die Jahre gewachsene, komplexe Architekturen, die meist noch schlecht dokumentiert sind. Duplizierter Quellcode, oft durch Cut&Paste Programmierung entstanden, und verwaister Quellcode tun ihr übriges um ein solches System schwer verständlich zu machen. XP spiegelt eine Grundregel erfahrener Programmierer wieder, welche besagt, dass die Architektur einer Applikation immer so einfach wie möglich gehalten werden sollte. Einfache Architekturen sind jedoch nicht immer einfach zu erreichen. Bei der Entwicklung ist es wichtig das Rad nicht immer neu zu erfinden, sondern von Expertenwissen in Form von Muster-Lösungen, sogenannten Design Patterns, zu profitieren. Viele bekannte Design Patterns erlauben es eine einfache, aber trotzdem erweiterbare, Architektur zu erarbeiten. Der schrittweise Umbau einer existierenden Software-Architektur wird sehr gut durch Refactoring [Fowler99] durchgeführt. Damit lassen sich nicht nur komplizierte Architekturen vereinfachen, sondern auch schon einfache Architekturen weiter umbauen. Auch Refactoring baut auf den Regel des sanften Lenkens auf. Refactoring empfiehlt Programmänderungen in sehr kleinen Schritten zu machen und diese sofort durch einen Test zu verifizieren. Eine Liste von elementaren Änderungen, wie sie sich für objekt-orientierte Programmiersprachen ergeben, ist in Martin Fowler's Refactoring Buch beschrieben. Eine Eigenschaft von einfachen Architekturen ist auch, dass sie die DRY-Regel [Hunt99] beachten. DRY steht hierbei für "Don't repeat yourself," und besagt, dass eine Funktionalität nur einmal im Quellcode implementiert werden sollte. Findet man zwei äquivalente Stellen, so sollten diese durch Refactoring zu einer reduziert werden. Neben des Bestrebens einfache Architekturen zu erstellen ist es
5 hilfreich, die Tests vor dem eigentlichen Applikations Quellcode zu schreiben. Mit dieser Regel wird gewährleistet, dass der Entwickler sich auf das eigentliche Problem fokusiert und nicht falsche oder unnötige Funktionalität implementiert. Wichtige Features werden dabei von einem sogenannten Unit-Tests überprüft. Ein Unit-Test stellt die kleinste Testeinheit eines System-Tests dar und überprüft genau ein Feature. Ein sehr interessanter Nebeneffekt ist auch, dass damit die Test Suite des Projektes, die sämtliche Unit-Tests enthält, ständig wächst und sich ergänzt. Bei der Integration von neuem bzw. geändertem Quellcode stehen sämtliche Tests aller Entwickler zur Verfügung. Es kann also während der Integration gesehen werden, ob und welche Test-Fälle durch den integrierten Quellcode nicht mehr korrekt ablaufen. Die Integration ist erst beendet, wenn sämtliche Testfälle der Test Suite korrekt durchlaufen werden. Gemeinsame Code-Verantwortung statt Abhängigkeit von einzelnen Entwicklern Welcher Entwickler wünscht sich nicht unersetzbar zu sein? Manche Entwickler schaffen es tatsächlich für die Entwicklung einer Software unersetzbar zu sein. So gut dies für den einzelnen Entwickler sein mag, z.b. bei Gehaltsforderungen, so schlecht ist es für das Projekt selbst. Denn sollte dieser Entwickler ausfallen, verliert das Team zunächst ersatzlos die Betreuung für ein wesentliches Stück Quellcode. Die Lösung zu diesem Problem ist die gemeinsame Code-Verantwortung. Dies bedeutet, dass das Team gemeinsam für den gesamten Quellcode verantwortlich ist und jeder an jeder Stelle Änderungen machen kann. Um nicht Chaos in das System zu bringen ist es wichtig, dass diese durch ein leistungsfähiges Versionsverwaltungs-Tool koordiniert wird. Der Transfer von Wissen erfolgt im Wesentlichen über die Paar-Programmierung. Paar-Programmierung funktioniert folgendermaßen: Zwei Entwickler entwickeln zusammen an einem Rechner, d.h. eine Maschine, ein Monitor, eine Tastatur und eine Maus. Während der eine schreibt, kann der andere schon die nächsten Ideen, bzw. Schritte, ausdenken und/oder den Quellcode reviewen. Die Rolle desjenigen der schreibt ist nicht fest vorgegeben, sollte der andere schon ein komplettes Refactoring gedanklich vorbereitet haben, so übernimmt dieser. Durch den ständigen Wechsel der Paare wird das Wissen zwischen allen Mitgliedern des Teams verteilt. Jedes Teammitglied kann daher kompetent Änderungen an einem Stück Quellcode vornehmen, das ursprünglich ein anderes Teammitglied entwickelt hat.
6 Falls "smelling code", sogenannter "riechender Quellcode", von einem Teammitglied entdeckt wird, so bemüht sich dieses Teammitglied den Quellcode mit Hilfe von Refactoring so zu verändern, dass er nicht mehr riecht. Bei gemeinsamer Code-Verantwortung besteht die Gefahr, dass Entwickler viel Zeit mit der Anpassung des Quellcodes an ihren Formatierstil verbringen, und dies teilweise nur um eine geschweifte Klammer nicht am Ende der vorhergehenden Zeile zu haben, sondern am Anfang der nächsten. Darum ist es nicht nur wegen der gemeinsamen Code-Verantwortung sinnvoll Codier-Richtlinien aufzustellen, sondern auch wegen der Verständlichkeit und der Qualität. Da XP versucht den Entwicklungsprozess so schlank wie möglich zu halten, wird dabei auf viel traditionelle Dokumentation verzichtet. Sogenannte "sprechende Bezeichner" sind die Grundlage eines sich selbst dokumentierenen Quellcodes. Natürlich unter der Prämisse, dass der Quellcode den Codier-Richtlinien entspricht. System-Metaphern helfen, das Ganze im Blick zu behalten Während der Entwicklung einer Lösung sind die Entwickler oft so vertieft in die Details ihres Problemes, dass sie keinen Überblick über das gesamte Projekt haben und es ihnen schwer fällt sich in andere Probleme, als das an dem sie gerade arbeiten, hinein zu denken. Dies kann unter anderem zu dupliziertem Quellcode und nicht benötigter Funktionalität führen. Ziel muss es sein dies zu vermeiden aber trotzdem den Entwickler nicht aus seiner Welt zu reißen. Um dies zu erreichen schlägt XP vor eine System-Metapher für das Projekt zu wählen. Diese System-Metapher beschreibt den Kontext und die Komponenten innerhalb des Projektes konsistent mit Begriffen, die z.b. aus der realen Welt stammen können. Sind keine solchen Assoziationen mit der realen Welt möglich, wie es bei Frameworks der in der Regel der Fall ist, so eignen sich dafür auch Design Patterns und daraus entstehende Pattern Languages. Eine eindeutige Begriffswelt hilft nicht nur bei der aktuellen Arbeit, sondern auch um neue Teammitglieder in das Team zu integrieren - sogenanntes "Insourcing". Intensives Mentoring durch Paar-Programmierung und die Verwendung der System-Metapher bieten den Neulingen einen schnellen Einstieg in das Projekt.
7 Zusammenfassung Bei der Darstellung der Gründe, wieso XP so ist, wie es ist, dürfte klar geworden sein, dass es oft nicht eine bestimmte Lösung für ein gegebenes Problem gibt. Oftmals sind es vernetzte Zusammenhänge, die eine Lösung für ein Problem darstellen. Daher ist es schwierig sich Teile von XP heraus zu nehmen und sie einzeln in Isolation mit einem anderen Prozess zu verwenden. Am besten funktioniert dies noch mit Unit-Tests und dem Refactoring. Sie können auch der Anfang einer langsamen Migration eines traditionellen Software-Projektes hin zu einem XP Projekt darstellen. [Brooks75] F. P. Brooks, The Mythical Man-Month. Reading, MA: Addison-Wesley, 1975 [Beck99] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999 [Beck00] Kent Beck and Martin Fowler, Planning Extreme Programming, Addison-Wesley, 2000 [Fowler99] Martin Fowler, Refactoring, Addison Wesley, 1999 [Jeffries00] Ron Jeffries, Ann Anderson, and Chet Hendrickson, Extreme Programming Installed, Addison-Wesley, 2000 [Hunt00]Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley, 1999 [Jacobsen98] Ivar Jacobsen, Grady Booch, James Rumbaugh: The Unified Software Development Process, Addison-Wesley, 1998
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
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:
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
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,
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
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
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,
Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)
Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:
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
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
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
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
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.
Informationswirtschaft II Rational Unified Process (RUP)
Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das
Informationswirtschaft II
Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe
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
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
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
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.
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,
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
Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer
Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Inhalt Top Themen Requirements Testen Testautomatisierung Change-Management Risiko-Management Agile Methoden Traceability
3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.
1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes
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
- 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
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
Einführung in Generatives Programmieren. Bastian Molkenthin
Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung
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?
Extremes Programmieren
Extremes Programmieren Erschienen im Informatik-Spektrum 23(2), 2000, S. 118-121 als Aktuelles Schlagwort Ralf Reißing Universität Stuttgart Institut für Informatik Abteilung Software Engineering Breitwiesenstr.
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
Qualität bei evolutionärer Entwicklung
Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 3 Qualität bei evolutionärer Entwicklung 2007, 2010 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht
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
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?
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
Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014
Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Überblick Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution Evolutionsprozesse Techniken für Software-Evolution
Software-Lebenszyklus
Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung
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:
Kapitel 8: Fehlervermeidung
Kapitel 8: Fehlervermeidung Inhalt 8.1 Prozesse mit kontinuierlicher Prüfung 8.2 Systematisches Entwerfen und Programmieren 8.3 Dokumentier- und Codierrichtlinien Schlüsselbegriffe Cleanroom, Fehlervermeidung,
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
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
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
Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit
IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational
(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
Agile Methoden. David Tanzer. Oliver Szymanski
Agile Methoden David Tanzer Oliver Szymanski Ziel von Softwareentwicklung Anforderungen zuverlässig und effizient in lauffähige Software verwandeln. Ziel von Softwareentwicklung Bedürfnisse des Kunden
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
3. Vorgehensmethoden/Prozessmodelle
3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen
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,
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
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,
Die Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
RE-Metriken in SCRUM. Michael Mainik
RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value
Comparing Software Factories and Software Product Lines
Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich
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
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
Sind wir nicht alle ein bisschen agil? Dipl.-Inform. Tammo Freese xpdays, Karlsruhe, 22. November 2004
Sind wir nicht alle ein bisschen agil? Dipl.-Inform. Tammo Freese xpdays, Karlsruhe, 22. November 2004 Das Manifest der agilen Softwareentwicklung Ähnliche Werte bei XP, ASD, Crystal, DSDM, FDD, Scrum,...
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
extreme Programming (XP)
Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung
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
The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert
The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses
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
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
Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003
Agile Software Entwicklung mit Raffael Schweitzer 18. November 2003 Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche Erfolgsfaktoren Fazit Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche
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
Seminar Software Engineering Universität Zürich, Winter 03/04. Agile vs. klassische Methoden der Software-Entwicklung
Seminar Software Engineering Universität Zürich, Winter 03/04 Agile vs. klassische Methoden der Software-Entwicklung EXTREME PROGRAMMING Manuel Meyer Rosenstrasse 9, 8152 Glattbrugg Matrikelnr. 99-905-739
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
AGILE SOFTWAREENTWICKLUNG NACH BERTRAND MEYER (AGILE!)
HOCHSCHULE ESSLINGEN FAKULTÄT INFORMATIONSTECHNIK STUDIENGANG SOFTWARETECHNIK UND MEDIENINFORMATIK AGILE SOFTWAREENTWICKLUNG NACH BERTRAND MEYER (AGILE!) WISSENSCHAFTLICHE PRÜFUNG WOJCIECH LESNIANSKI 22.01.2016
10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?
10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann
SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de
SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden
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
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...
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
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
Ü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
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
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,
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
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/
Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?
Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung
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
Softwareentwicklungsprozess im Praktikum. 23. April 2015
Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit
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
Software für die Wirklichkeit.
Software für die Wirklichkeit. S oftwareentwicklung ist einfach. Man nimmt ein paar Programmierer, sagt Ihnen, was man Visionen sind die Kraft der Zukunft. will und dann sitzen diese introvertierten, genialen
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?
Kapitel 2: Der Software-Entwicklungsprozess
Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken
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
Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16
Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle
Agile Programmierung: Case Studies
Agile Programmierung: Case Studies Fachbereich Informatik Fakultät für Mathematik, Informatik und Naturwissenschaften Universität Hamburg 2015-07-07 Betreuung: Dr. Julian Kunkel 1/22 Gliederung Einfluss
SE Besprechung. Übung 3 Softwareprozesse
SE Besprechung Übung 3 Softwareprozesse SE, 08.11.11 Mengia Zollinger Analyse der Systemkomponenten(3 Punkte) Mögliche Ansätze: 3-Schichten-Architektur (tree-tier-architecture) Präsentation Anwendungslogik
Die Phasen der Software-Entwicklung
Die Phasen der Software-Entwicklung c OSTC GmbH, T. Birnthaler 2011-2015 V1.7 [sw-entwicklung-phasen.txt] 1 Übersicht Die Entwicklung von Software im Rahmen eines Projekts umfasst im wesentlichen die Phasen
ZuuL - Entwicklung eines Adventures
ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht
Kontinuierliche Architekturanalyse. in 3D
Kontinuierliche Architekturanalyse in 3D Stefan Rinderle Bachelor an der HS Karlsruhe Master "Software Engineering" in München / Augsburg Seit 2013 bei Payback 2 Software-Visualisierung Visualisierung
den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015
Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre
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
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
Lohnt sich Requirements Engineering?
Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen
Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen
Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?
Vorstellung. Wie entsteht Architektur in Scrum
Vorstellung Thema Architektur - Begriffsdefinition Eine Architektur (vοn griechisch αρχή = Anfang, Ursprung und lateinisch tectum = Haus, Dach) beschreibt in der Informatik im Allgemeinen das Zusammenspiel
Agile Projekte in Auftrag geben
Agile Projekte in Auftrag geben Jens Coldewey (BDU) Coldewey Consulting Toni-Schmid-Str. 10 b D-81825 München Germany Tel: +49-700-COLDEWEY Tel: +49-700-26533939 Fax: +49-89-74995703 jens.coldewey@coldewey.com
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
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