Seminararbeit Agile Softwareentwicklung mit

Größe: px
Ab Seite anzeigen:

Download "Seminararbeit Agile Softwareentwicklung mit"

Transkript

1 Seminararbeit Agile Softwareentwicklung mit Extreme Programming (XP) Johannes Hecker, Alexandre Matic, Camil Pogolski, Wintersemester 14/15 1

2 Inhaltsverzeichnis 1 Einleitung 3 2 Geschichte 4 3 Bestandteile Prinzipien Werte Praktiken Risiken der Softwareentwicklung 10 5 Phasen Planungsphase Designphase Programmierphase Testphase Sicht Kundensicht Programmiersicht Projektsicht Wirtschaftliche Sicht Besonderheiten von Extreme Programming 19 8 Preis- und Vertragsmodelle 20 9 Kritik Fazit Literaturverzeichnis Glossar 24 2

3 1 Einleitung Extreme Programming ist ein Prozess der Agilen Softwareentwicklung für kleine Teams und bietet zusätzliche Methoden mit vier sich bis zur Fertigstellung wiederholenden Zyklen an. Planung - Design - Programming - Test - Planung - Design -... Der Ablauf beim Extreme Programmings gilt als merkwürdig, scheinbar ineffektiv und als aufwändig. Dabei ist Extreme Programming ein bewusster Prozess von gewolltem Experimentieren und ständiger Verbesserung des Codes, sodass automatisch gute Softwareprodukte entstehen. Ein Programmierer programmiert nur wenige, dauerhaft bleibende und korrekte Codezeilen. Oft werden durchschnittlich nur bis zu 5 Codezeilen pro Arbeitstag geschrieben. Da niemand perfekt ist, dennoch jeder eine fehlerfreie und perfekte Software haben möchte, wird im Extreme Programming Perfektion durch einen kontinuierlichen Verbesserungsprozess (KVP) ermöglicht. Extreme Programming ist eine exakte Implementierung bzw. Umsetzungen des japanischen Kaizen. Kaizen (kai = Veränderung, zen = zum Besseren) ist ein in Japan erstandener KVP und Bezeichnet sowohl eine japanische Lebens- und Arbeitsphilosophie wie auch ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht. Die unendliche Verbesserung erfolgt in einer schrittweisen, punktuellen Perfektionierung oder Optimierung eines Produktes oder Prozesses. [GS09] Extreme Programming gilt als ein sehr durchdachtes Kaizen-Konzept, wobei Extreme Programming in 4 verschiedenen Phasen aufgeteilt ist. Diese Phasen werden zyklisch immer wieder durchlaufen. Die Effekte dieser Phasen werden erst in der Dynamik sichtbar, und deren Logik haben einen tieferen Sinn, welche nicht immer direkt durchschaubar sind. So kann es für ein Teammitglied schwer zu verstehen sein, dass Prozesse, welche einem individuellen Teammitglied einen Nachteil verschaffen, dem gesamten Team aber vom Vorteil sind. 3

4 2 Geschichte Kent Beck, Ward Cunningham und Ron Jeffries haben 1995 bei Daimler Chrysler an einem Projekt namens C3 gearbeitet. Dieses Projekt beschäftigte sich mit der Bereitstellung eines neuen Programmes, zur Gehaltsabrechnung und sollte veralte Programme durch eines mit größerem Umfang und stabilerem Laufverhalten ablösen wurde Kent Beck zum Projektleiter da der externe Dienstleister, welcher nach dem Wasserfallmodel in knapp einem Jahr keinen wesentlichen Fortschritt erzielte. Er passte die Entwicklungsmethoden an, um das Projekt effizienter umsetzen zu können. Auch wenn diese Methoden relativ neu sind, findet man deren Wurzeln teilweise bedeutend früher. Leo Brodie schreibt in seinem 1984 veröffentlichten Buch zum Beispiel über Praktiken wie Refactoring, Modularität oder Bottom-Up-Design. Im Verlauf der mehrjährigen Entwicklung gab es zahlreiche Probleme und da das Projekt die Erwartungen nicht erfüllen konnte wurde das C3 Projekt bei der übernahme von Chrysler durch die Daimler-Benz AG eingestellt. 4

5 3 Bestandteile Die Grundlegenden Bestandteile von Extreme Programming sind die Prinzipien, die Werten und die Praktiken. 3.1 Prinzipien Da die Prinzipien nicht nur Teil vom Extreme Programming, sondern auch der anderen Verfahren zur agilen Softwareentwicklung sind, verweisen wir an dieser Stelle auf die Seminararbeit: Grundprinzipien der agilen Softwareentwicklung unserer Kommilitoninnen Natali Brozmann und Marie Claire Dzukou. 3.2 Werte Kent Beck definierte in seiner zweiten Auflage die 5 Werte von Extreme Programming: 1. Kommunikation: Kommunikation ist sehr wichtig, da sich laut Kent Beck viele Fehler vermeiden ließen, wenn man ausreichend miteinander kommunizieren würde. Auch die Entscheidungen und die Anforderungen des Kunden können nur mit ausreichender Kommunikation optimal erreicht werden. 2. Einfachheit: Software ist heutzutage meist sehr komplex, jedoch wird diese einfacher wenn man diese aufteilt oder sich nicht zu sehr auf die Optimierung des Codes vertieft. Einfachheit ist schwer zu erreichen, da man meist vorausschauend und optimierend denkt. Umso einfacher ein System wird, umso besser lässt sich dieses auch anderen vermitteln, was sich wiederum positiv auf den Wert Kommunikation auswirkt. 3. Feedback: Nicht nur Feedback des Kunden ist wichtig, um zu wissen was gemacht werden muss, sondern auch Feedback von allen anderen Beteiligten. Feedback ergänzt Einfachheit und Kommunikation, da die verschiedene Personen jeweils den aktuellen Stand des Projektes oder auch Tester Probleme oder Änderungen bekannt geben. 5

6 4. Mut: Mut ist ein wichtiger Punkt in Extreme Programming. Das Experimentieren, Code zu verwerfen und zu ändern, verlangt oft viel Mut, den die Programmierer manchmal nicht haben. Es kommt auch oft vor, dass Arbeit eines Teammitgliedes komplett verworfen wird und dieses dann Angst hat nichts für das Projekt geleistet zu haben. Manche plagt dann der Gedanke, dass sie entlassen werden könnten, wenn sie nichts vorzuweisen hätten. Sogar der Kunde muss Mut haben der Extreme Programming-Methoden zu vertrauen und sie nicht voreilig fallen zu lassen. 5. Respekt: Respekt kam erst bei der zweiten Auflage von Kent Becks Buch zu Extreme Programming hinzu. Respekt baut vor allem auf Mut auf und beschreibt das Respektieren von Teammitgliedern, auch wenn Arbeitet dieser verworfen wurde. 6

7 3.3 Praktiken Die Praktiken teilen sich wiederum in allgemeine Arbeitsweisen, welche phasenübergreifend angewendet werden können und denen welche in speziellen Phasen umgesetzt werden sollten. Akzeptierte Verantwortung Das Management sollte einem Extreme Programming Team auf Probleme hinweisen, aber was zu tun ist, sollten Kunden und Programmierer ohne zutun des Managments selbst entscheiden. Teameinschätzung und Widerspieglung Das Management sollte den Teammitgliedern stets zeigen wo sie gerade stehen und herausfinden, in welchen Bereichen Hilfe benötigt wird. Durch Metriken kann der Fortschritt des Teams oder zu lösende Probleme anschaulich dargestellt werden. Kritik Nach jedem Entwicklungszyklus sollte nochmal über die getane Arbeit vom gesamten Team diskutiert werden. Hier soll die Arbeitsweise kritisch reflektiert werden, sodass man nicht die selben Fehler wiederholt. Natürlich sollen hier auch die positiv aufgefallenen Arbeitsweisen aufgezählt werden, um die Motivation zu fördern. Arbeitsumgebung und Ausstattung Die Arbeitsplätze sollten so dicht wie möglich beieinander liegen, sodass eine einfache Kommunikation gewährleistet ist. Die Monitore sollte so platziert sein, dass zu zweit an einem Computer gearbeitet werden kann. Jeder Arbeitsraum sollte mit Wandtafeln und Flipcharts ausgestattet sein. Ein Fehler sollte nicht erneut Auftreten. Stellt man einen Fehler fest, so sollten die Tests sicherstellen, dass dieser nicht nochmal Vorkommt. Natürlich müssen die Unit-Tests hierfür entsprechend angepasst werden. 7

8 Da Extreme Programming eine Teamarbeit ist, wird die Motivation und der Mannschaftsgeist durch Überstunden geschwächt. Es hilft auch nicht das Team zu vergrößern, falls ein Termin nicht eingehalten werden kann. Oftmals hilft es eher eine Nacht darüber zu schlafen, da man so neue Energie tanken kann und man sich erholt. Durch Unruhe im Team wird die Entwicklung im Gesamten nicht beschleunigt. Hektik kann die Fehlerquote erhöhen. Die Fehlersuche ist aber sehr viel anstrengender und Zeitfressender als das Codieren selbst. Lieber sollte sich der Programmierer Zeit und Ruhe nehmen, um genauer nachdenken zu können und so fehlerfrei zu programmieren. Pair Programming Wie der englische Begriff schon sagt, handelt es sich um das Programmieren zu zweit. Es ist zu Beginn sehr gewöhnungsbedürftig, aber für die Ruhepausen zum Nachdenken, die jeder braucht, notwendig. In der Regel benötigt man mehr Zeit zum Nachdenken, als zum eigentlichen programmieren. Nicht selten kommt es auch vor, dass ein Programmierer beim Programmieren eine Blockade hat und nicht weiter kommt. Da der Programmierpartner nicht mit dem schreiben des Codes beschäftigt ist, kann sich dieser mehr auf den Code konzentrieren. So werden Fehler schneller gefunden und das Resultat ist eine sehr viel bessere Codequalität mit anschließend weniger Refactoring. Zu beachten ist, dass bei besonderen Umständen oder auftretenden Problemen die Regeln des Extreme Programmings gebrochen werden dürfen. Extreme Programming ist kein festgelegtes Prozedere, sondern darf, den Anforderungen und den Umständen entsprechend wohlbegründet, abgeändert werden. [LI] Meetings Es sollten täglich kurze Meetings vor dem Arbeitsbeginn gemacht werden. Dies vermeidet längere Teamsitzungen bei auftretenden Problemen. Bei den Meetings sollten tägliche Aufgaben zugeordnet und Arbeitskapazitäten neu aufgeteilt werden. 8

9 Fachkenntnisse Beim Pair Programming bzw. beim Extreme Programming allgemein, sollte nicht auf besondere Fachkenntnisse oder Niveau anderer Programmierer im Team hingewiesen werden. Dennoch wird dies oft gemacht. Diese Wahrnehmung mag vielleicht korrekt sein, dennoch sei zu bedenken, dass niemand Perfekt ist und nicht jeder das Glück hatte, gute Lehrer gehabt zu haben. Jeder Mensch ist durch seiner Familie, Freunde oder vielleicht auch fremde Menschen beeinflusst worden. Positiv beim Pair Programming ist gerade, dass ständig neue Paarungen im Team entstehen und so jedes Individuum in kürzester Zeit sehr viel dazulernt. So entsteht im Team ein einheitliches Niveau wovon alle im Team profitieren. Rotationsprinzip Im Rotationsprinzip werden ständig Programmierer innerhalb der Paarungen getauscht. Dadurch werden häufig auftretende Effekte, dass aufgrund des Ausfalls eines Teammitgliedes, das gesamte Team drunter leidet bzw. es gar zum Stillstand kommt, verhindert. Durch dieses Prinzip kennt sich jedes Teammitglied anschließend mit der Software aus und kann ggf. einspringen. In Projekten mit hoher Komplexität und starker Kopplung der Module trifft dies häufiger zu. Außerdem können Programmierer flexibler eingesetzt werden, wenn es Probleme geben sollte. Damit können auch sogenannte Wissensinseln (dass nur sehr wenige im Team das nötige Wissen haben, einen Aufgabenteil zu bearbeiten) vermieden werden. Gerade an diesem Punkt gibt es die größten Widerstände, da sich jeder kostbarer und einmalig machen möchte besteht die Angst des Jobverlustes. Durch ein solches Prinzip passt man aber in jedes neue Programmier-Team, wenn man die Denkweise des Extreme Programmings verinnerlicht hat. Man ist flexibler und sammelt Erfahrung und findet so immer Arbeit. 9

10 4 Risiken der Softwareentwicklung Softwareprojekte unterscheiden sich von Entwicklungsprojekten in anderen Bereichen, wie z.b. bei der Herstellung materieller Güter. Die 3 wesentlichen Unterschiede sind: [SV01] 1. Da Software nicht greifbar ist, kann man den Fortschritt nicht so offensichtlich wie zum Beispiel bei einem Bauprojekt nicht erkennen. Um diesen Fortschritt sichtbar und messbar zu machen, muss ein höherer Aufwand betrieben werden. 2. Für jedes einzelne Projekt muss ein passendes Vorgehensmodell gefunden oder entwickelt werden. Da es sich in der Regel um Anpassungen eines vorhandenen Modelles handelt, existieren meist keine Erfahrungen mit diesem. 3. Inhaltlich unterscheiden sich Softwareprojekte fast immer von vorhergegangenen Projekten. dadurch können Erfahrungen mit ähnlicher Vorgehensweise, Lösungen oder Techniken oft nicht direkt auf neue Projekte übertragen werden. Diese Punkte führen dazu, dass Softwareprojekte mehr Risiken und Probleme als Projekte in anderen Bereichen hervorbringen. Die Einhaltung eines festgelegten Zeit- und Budgetplans ist besonders schwierig. 10

11 5 Phasen Die Phasen wiederholen sich zyklisch. Ein Zyklus wird Entwicklungszyklus oder auch Iteration genannt. Zu beachten ist, dass Entwicklungszyklen immer stets so kurz wie möglich zu halten sind. In jedem Entwicklungszyklus wird die Geschwindigkeit der Projektentwicklung neu abgeschätzt. Insgesamt werden pro Zyklus % der Zeit für die Planung verwendet. Unit-Tests und Refactoring werden direkt mit eingeplant. Da sich die Anforderungen und Kundenwünsche ständig ändern, werden alle ein bis drei Wochen die Entwicklungszyklen neu definiert. Durch die kleinen Entwicklungszyklen, werden unrealistische Ziele wahrgenommen und behoben. 5.1 Planungsphase User-Story Basierend auf dem aktuellem Zwischenrelease, skizziert und beschreibt der Kunde weitere Arbeitsabläufe, Änderungen am Benutzer-Interface und sonstige Ideen dem Entwicklungsteam. Diese dienen zur weiteren Abschätzung des Projekt-Umfangs und der Festsetzung weiterer Entwicklungszyklen. 11

12 5.2 Designphase Einfachheit oder auch KISS-Prinzip (Keep It Simple, Stupid!) Durch Dokumentation an den notwendigen Stellen, ist alles im Projekt durchschaubar. Dadurch findet sich jeder Programmierer in der Arbeit eines anderen zurecht und sollte nach kurzer Einarbeitungszeit mitwirken können. Die Austauschbarkeit des Programmierers ist hier der Hauptaspekt. CRC-Karten (Class, Responsibilities, Collaboration) Durch CRC-Karten oder UML-Diagramme wird dem Team das Systemdesign näher gebracht. Bei CRC-Karten handelt es sich um Mindmapping in einer Sitzrunde. Jeder Programmierer hält eine Karte in der Hand, welche eine Klasse mit den Abhängigkeiten zu anderen Klassen repräsentiert. Anschließend spricht jedes Teammitglied über seine Karte, welche Objekte wie mit Anderen kommunizieren, uvm. Durch das Diskutieren und gemeinschaftliche Denken werden Schwächen im Design entdeckt und können behoben werden. Namen und Bezeichner Das Team sollte sich auf einheitliche Namen und Bezeichner im Code einigen, dies erleichtert die Kommunikation und Einarbeitung in den Code anderer. Bei Problemen Treten technische oder Design-Probleme auf, so sollte der Programmierer ein einfaches Programm entwickeln, welches das Problem unter Nichtberücksichtigung aller anderen Probleme löst. (Das Testprogramm wird sowieso später verworfen, da es nur zu Testzwecken dient). Dadurch werden die Zuverlässigkeit der User-Stories erhöht und das Risiko eines Fehldesigns reduziert. Stellt man fest, dass das Problem eventuell die Gesamtentwicklung verlangsamen könnte, so sollten sich zwei Entwickler mit dem Problem beschäftigen, bis dieses behoben ist. 12

13 Rafactoring Höchste Priorität in der Designphase hat das Refactoring, ein Prozess der ständigen Verbesserung der Code-Struktur. Code muss leicht verständlich und erweiterbar sein. Dabei sollen überflüssige Funktionen verworfen und Redundanzen aufgelöst werden. Sollten mehrere Designe existieren kann es durch Refactoring passieren, dass sein eigenes, bevorzugtes Design fallen gelassen werden muss, da sich andere besser eignen. 5.3 Programmierphase In dieser Phase sollte der Kunde stets anwesend sein, da er ein wichtiger Bestandteil des Extreme Programmings ist. Der Kunde bestimmt das Aussehen und die Funktionalität der Software und ist somit der Verantwortliche für die User-Stories, mit welche die GUI ständig angepasst und verbessert wird. Wichtig wird dies, wenn der Kunde im Laufe des Projektes neue Funktionalitäten einführen möchte. Er ist auch derjenige der Auskunft über vergessene oder übersehene Details geben kann. Es kann natürlich auch vorkommen, dass Sonderwünsche oder kleinere Features aus Preis- oder Aufwandsgründen nicht realisiert werden. Der Kunde selbst ist des weiteren immer bei Unit-Tests und Funktionalitätstests anwesend. Styleguide Um das verstehen des Codes für das gesamte Team zu vereinfachen, muss ein sogenannter Styleguide berücksichtigt bzw. abgesprochen werden. Für jede Programmiersprache gibt es einen solchen der bspw. im Internet zu finden ist. Dies beinhaltet z.b. Bezeichner wie Pointer oder auch Namensgebungen und vieles mehr. Dadurch wird die Lesbarkeit, Verständlichkeit und die Einarbeitungszeit für andere erleichtert. Unit-Tests Im Extreme Programming ist es Pflicht, bevor auch nur eine Zeile Code geschrieben wird, eine Testroutine zu schreiben, die die genauen Erwartungen an ein Programm überprüft. Für Methoden, Prozedere oder Klassen sind Unit-Tests relativ einfach und schnell zu schreiben, wogegen es bei Datenbankanwendungen oder GUIs mit Ein- und Ausgabe und einer Benutzerinteraktion schwieriger wird. (Da bei Datenbankanwendungen nämlich Testdatensätze definiert werden müssen). Durch die Qualitätssicherung (also Unit-Tests) gibt es aber mehrere positive Nebeneffekte. Der Programmierer kann sich mithilfe dieser Tests auch nur auf das Wesentliche konzentrieren 13

14 und muss nur so wenig Code schreiben, welcher benötigt wird, damit die Tests laufen. Ebenso zeigt es anderen Projektmitarbeitern, die Arbeitswesen der Funktionen, Prozedere oder Klassen bzw. für welchen Zweck sie verwendet werden. Dies kann natürlich auch als kleines Tutorial für die Mitarbeiter genutzt werden. Keine Unnötigen Funktionen Es sollte darauf geachtet werden, keine unnötigen Funktionalitäten zu programmieren. Häufig wird dazu geneigt zusätzliche Funktionen zu programmieren, obwohl diese vom Kunden nicht gewünscht worden sind. Man sollte sich selbst disziplinieren können, da im Extreme Programming sowieso nicht alle geschriebenen Codezeilen in der finalen Software bleiben. In der Entwicklungsphase sollte niemals Code optimiert werden, dieser muss erst lauffähig gemacht werden. Optimierung ist ein Teil der Testphase. 5.4 Testphase Unit-Tests Unit-Tests sind sehr wichtig für Extreme Programming. Jede neue Implementierung muss durch solche Tests überprüft werden. Es darf kein Code genutzt werden, der die Unit-Tests nicht bestanden hat. Ist ein Codestück nicht komplett getestet worden, so müssen die fehlenden Tests noch erstellt werden. Gegen Ende der Entwicklung, also kurz vor der Fertigstellung, ist es oft am schwierigsten, saubere Unit-Tests zu erstellen. Grade hier sollte man nicht nachlässig sein, da eine Fehlersuche sehr viel aufwändiger ist als einen Unit-Test zu schreiben. Natürlich kann auch der Debugger genutzt werden, der findet aber nur einfache Programmierfehler, aber keine Logikfehler. Je härter es ist, einen Unit-Test zu schreiben, umso mehr wird er auch tatsächlich benötigt, und umso größer wird die Zeitersparnis bei evtl. Fehlersuche sein. [LI15] 14

15 Akzeptanztests Ein weiterer großer Bestandteil der Tests im Extreme Programming sind die Akzeptanz-Tests. Diese sind für die Sicherstellung der Bedienbarkeit und der Funktionalität verantwortlich. Szenarien werden vom Kunden beschrieben, damit der Programmierer weiß auf was getestet werden soll. Der Kunde beschreibt hier die Erstellung, Überprüfung und Einhaltung der Anforderung an das System. Ist mindestens ein Akzeptanz-Test nicht erfüllt worden, so gilt die User-Story als nicht vollständig. Das bedeutet dann auch, dass falls kein Fortschritt in einem Entwicklungszyklus erzielt wurde, neue Akzeptanz-Tests geschrieben werden müssen. 15

16 6 Sicht 6.1 Kundensicht Extreme Programming bezieht den Kunden stark in das Projekt ein, dabei lenkt dieser das Projekt und prüft ob es seinen Erwartung entspricht oder ob sich die Spezifikationen geändert haben. Der Kunde muss sich genauso einbringen wie das Entwicklerteam und ist deshalb meist auf dem selben Stand wie die Entwickler. Im besten Fall unterstützt er das Team durch das Schreiben von User-Stories (sowie in seltenen Fällen von Unit-Tests) und dem Bestimmen der Wichtigkeit einzelner Komponenten, sodass das Projekt immer den aktuellen Anforderungen entspricht. Der Kunde muss deshalb bei Extreme Programming [...] auf eine formale Festlegung der Projektinhalte (Spezifikation) verzichten. [LF] Das Entwicklerteam wird dabei eigene Ideen und Features für das Produkt vorschlagen. Hierbei muss der Kunde entscheiden, ob diese Leistungsmerkmale benötigt werden oder nicht. Im Idealfall entsteht zwischen dem Kunden und dem Entwickler eine Geschäftsbeziehung, wodurch Extreme Programming im Nachfolgenden stark profitiert, da der Kunde und das Entwicklerteam bessere Vorstellungen voneinander haben. Bringt der Kunde sich nicht ausreichend ein oder hält an starre Softwareprojektmanagement Abläufe fest, so funktionieren die Methoden des Extreme Programmings nicht. 6.2 Programmiersicht In Extreme Programming sollen die einzelnen Programmierer entlastet werden und durch die ständige Kommunikation kann das Wissen einzelner besser verteilt werden. Deshalb verzichtet Extreme Programming auf eine strikte Rollenverteilung und überlässt den Programmieren die Aufgabenverteilung, sodass diese sich immer zu der Situation und Fähigkeiten passende Aufgaben übernimmt und keine ungleichmäßig ausgelasteten Mitarbeiter entstehen. Leider hat Extreme Programming den Nachteil, dass sich Programmierer manchmal vernachlässigt oder nutzlos fühlen, wenn ihr eigentlicher Code verbessert oder verworfen wurde. Ohne Mut funktioniert XP einfach nicht. - Kent Beck [KB03] Andererseits ist das Wissen und die Möglichkeit Code anderer zu verändern positiv aufzufassen, da die Programmierer öfters durch experimentieren und ausprobieren bessern Code erzielen. Bei einem Ausfall einzelner Programmierer kann sogar das gesamte Team weitermachen ohne sich großartig in den vorhanden Code erst einmal einzuarbeiten. 16

17 6.3 Projektsicht Extreme Programming ist eine Risikomanagementstrategie die sich vor Ausfall oder Demotivation von Mitarbeitern, aber auch dem Risiko, dass das Projekt in die falsche Richtung entwickelt wird, absichert. Dem Kunden bringt es Vorteile in dem er sich zufriedener und sicherer fühlt. In der Regel ist der Kunde immer auf dem aktuellsten Stand des Projektes. Ein weiterer Vorteil ist, dass der Teamgeist vom Programmierteam gefördert wird. Der Einzelne vom Wissen der andere profitiert und die Aufgabenlast immer passend und gleichmäßig verteilt wird. Aufwandsabschätzungen werden verlässlicher, da sie im Team getroffen und ständig einer kritischen überprüfung (Review) unterzogen werden. [LF15] In der Regel werden Softwareprojekte nie rechtzeitig zum gewünschten Umfang fertig, jedoch kann durch Extreme Programming der Kunde immer auf eine funktionierende Iteration zurückgreifen, die für ihn meist den wichtigsten Teilumfang enthält. Sogar ein Extreme Programming-Projekt das vom Kunden fallen gelassen wird, lässt sich in andere Projekte weiterverwenden oder sogar bis zu der geschafften Iteration an andere verkaufen. 6.4 Wirtschaftliche Sicht Extreme Programming setzt hauptsächlich auf Pair Programming, was zunächst doppelt so viel Personalaufwand bedeutet, jedoch durch die größere Fehlervermeidung beim Pair Programming eine höhere Qualität und geringe Nachbesserung von Modulen mit sich führt, was zur Folge hat, dass sich zum Schluss diese Alternative stark rentiert. Genauso ist auch personaltechnisch der Mitarbeiter des Kunden, der für das Entwicklerteam zur Verfügung gestellt wurde (im besten Fall immer beim Entwicklerteam ist), nicht für die üblichen Einsatzgebiete innerhalb der eigenen Firma verfügbar. Dafür kann diese Person den Entwicklern die Richtung weisen, um schneller gewünschte Spezifikationen zu erreichen, sowie nicht gewollte Spezifikationen zu vermeiden. Dies erspart somit Zeit und Kosten bei der Entwicklung und die Entwickler können sich vermehrt auf die wichtigere Teile im Projekt vertiefen. 17

18 Das größte betriebswirtschaftliche Problem von Extreme Programming ist jedoch, dass durch die unvollständige Kenntnis, sowie laufend ändernde Spezifikation, keine voraussichtliche Kosten und Dauer abgeschätzt werden können. Lediglich ist eine Aufwandsabschätzung innerhalb einer Iteration möglich und basiert auch nur auf die Erfahrungen des Entwicklerteams. Umso länger das Team an einem Projekt arbeitet, desto genauer werden die Schätzungen. Generell ist die Extreme Programming-Methode günstiger wenn man auf ein qualitatives und langlebiges Projekt setzt oder bereits während der Entwicklungen Änderungen in den Spezifikationen auftreten können. Extreme Programming setzt auf eine sehr hohe Codequalität und dem Aufteilen des Wissens auf alle Teammitglieder, weshalb die Wartbarkeit und Erweiterbarkeit günstiger und risikoärmer ausfällt. Es wird nämlich allgemein angenommen, dass sich frühe Fehler im Verlauf des Projektes die Kosten exponentiell in die Höhe steigen lassen. Außerdem sorgen die Iterationen für eine ständige Überprüfung des Projektes, weshalb Fehler und Änderungen früh erkannt und behoben werden. 18

19 7 Besonderheiten von Extreme Programming Der größte und wichtigste Unterschied zwischen den klassischen Modellen und Extreme Programming ist, dass der Aufwand und damit Kosten bei Änderung während des Entwicklungsprozesses nur leicht steigen. Gewünschte Änderungen oder auch Ergänzungen des Kunden bzw. auch des Entwicklerteams lassen sich leicht berücksichtigen. Unwichtigere Aufgaben lassen sich ohne Nachteile auf später verschieben. Dies kann helfen Entscheidungen zu einem späteren Zeitpunkt mit mehr Informationen zu treffen und hilft Zeit einzusparen. So ist das Produkt früher einsatz- und testfertig. Durch automatisierte Tests wird ein günstigerer Verlauf mit kleinen Änderungskosten erreicht. Diese Tests vereinfachen auch den Umbau von Code im späteren Verlauf des Projektes. Fehler kann der Entwickler nach Änderungen so sofort sehen und lokalisieren. Treten keine Fehler auf, kann er sich sicher sein, dass es durch seine Änderung später zu keinen Problemen kommt. Andere Kosten- und Zeitintensive Qualitätssicherungsmaßnahmen entfallen. Die niedrigen Änderungskosten werden außerdem durch das permanente Refactoring erreicht. Durch die häufigen Anpassungen, Umbauten am Systemes und die Codeüberarbeitung, erwerben die Entwickler zusätzlich wichtige Fähigkeiten. 19

20 8 Preis- und Vertragsmodelle Ein Grund der gegen Extreme Programming spricht ist, dass man bei der Wahl des Vertragsmodells eingeschränkt ist. Vor allem ein Vertrag zum Festpreis kann nicht gewählt werden. Bei dieser Art des Vertrages werden in einem Pflichtenheft die Anforderungen genau spezifiziert und sind somit fester Bestandteil des Vertrages. Sollen während der Laufzeit des Projektes Änderungen erfolgen, zum Beispiel den Wegfall einer Komponente oder das Hinzufügen einer anderen, muss erst über diese neu verhandelt werden. Dabei geht Zeit verloren und der Zeit- und Kostenplan kann sich verändern. Deshalb kann Extreme Programming in solchen Fällen nicht eingesetzt werden, da man den Umfang leicht ändern können muss. Die Alternative zu diesem Modell wäre der Agiler Festpreis. Ähnlich wie beim Festpreis werden für die Menge an Anforderungen ein verbindlicher Gesamtpreis vereinbart. Es können aber Leistungen gegen andere, die denselben Wert haben, ausgetauscht werden. So bleibt der Gesamtumfang des Projektes gleich. Dafür wird ein transparentes Verfahren definiert, mit dem der Wert der Leistungen geschätzt werden kann. Wenn ein solches Verfahren für die Schätzung existiert, sind die Vorteile des Festpreis und Vergütung nach auf Aufwand vereint: Budgetsicherheit für den Auftraggeber Anforderungen sind flexibel Gesamtumsatz ist für den Auftragnehmer leicht kalkulierbar Wie beim Festpreis liegt das Umsetzungsrisiko beim Auftragnehmer. Der Gewinn steigt wenn der Aufwand sinkt. Wenn es anders herum läuft muss er Verluste hinnehmen. Dadurch wächst die Motivation für den Auftragnehmer, weniger Aufwand zu betreiben um sein Gewinn zu maximieren, was nachteilige Auswirkungen auf die Qualität haben kann. Beim Vertrag nach Aufwand besteht dieses Problem nicht. Daher ist dieses Modell gut für Extreme Programming-Projekte anwendbar. Jetzt ist der Auftragnehmer daran interessiert, den Aufwand zu erhöhen um seinen Gewinn zu steigern. Die Ausgangsposition für die Verhandlungen ist ungünstiger, da sich die Interessen der Vertragspartner entgegenrichten. Zusätzlich hat der Auftraggeber keine Budgetsicherheit mehr, was die Fälle indem ein solcher Vertrag zustande kommt reduziert. So gibt es für Extreme Programming-Projekte ein gutes Repertoire an Vertragsmodellen. Welcher am besten geeignet ist hängt stark von der bestehenden Geschäftsbeziehung und dem Inhalt des Projektes ab. Den Nachteil, dass die Vertragsgestaltung bei Extreme Programming eingeschränkt ist, gibt es deswegen eher selten. 20

21 9 Kritik In einer bestehenden Unternehmensumgebung erweist sich die Einführung von Extreme Programming als problematisch. Entwickler müssen ihrer Denkweise ändern, was ein hohes Maß an Toleranz verlangt. Ist die Einführung jedoch erfolgreich verlaufen, hat man ein flexibel einsetzbares Entwicklerteam, welches sich schnell an neue Anforderungen anpassen kann. Durch die Verwendung einzelner Methoden kann man zwar Verbesserungen erzielen, jedoch werden die besten Ergebnisse erst im Verbund dieser ermöglicht. Kurz vorm Scheitern befindliche Projekte können auch mit Extreme Programming nicht gerettet werden können. Die Einführung in das Vorgehensmodell erfordert Training und Zeit, daher sollte Extreme Programming nicht als Heilmittel betrachtet werden. Nicht für jeden Anwendungsfall sind alle Extreme Programming Methoden umsetzbar bzw. angebracht. So stellt der On-Site Customer z.b. als alleiniger Ansprechpartner eine Fehlerquelle dar. In Banken ist es beispielsweise üblich, einen Ansprechpartner für Softwareprojekte Vollzeit zur Verfügung zu stellen. Allerdings kann sich dieser mit der Zeit zu sehr von der Denkweise seines eigentlichen Arbeitsfeldes entfernen und sollte besser regelmäßig ausgetauscht werden. (vgl. [LM02]). Bei der Angebotserstellung für ein Projekt stellt sich die Preisfindung durch die iterative Vorgehensweise, die kurzen Releasezyklen und die Möglichkeit der kurzfristigen Änderung der Funktionalität, als schwierig heraus. Aufgrund der geringen Dokumentation ist Extreme Programming nicht für alle Branchen sinnvoll. Zum Beispiel in Branchen die mit Zertifizierungen oder gesetzliche Vorschriften arbeiten. Kommentare im Quelltext, User-Stories beziehungsweise die daraus erzeugten Dokumentationen und Akzeptanztests sind die einzigen Formen von Dokumentierung. in Extreme Programming werden keine vorausschauende Designs gemacht. Erst bei Auftritt von Problemen sollen diese gelöst werden. Nach dem aktuellem Entwicklungstandes des Projektes, wird das Gesamtprojekt weitergeplant. Dies steht aber im Kontrast zur Arbeit erfahrener Softwarearchitekten, da diese schon vor Projektbeginn versuchen, Zeit einzusparen indem Refactorings durch gute Designs verhindert werden. 21

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

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

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

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

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

Mehr

extreme Programming (XP)

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

Mehr

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

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

Mehr

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

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

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

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

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

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

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

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

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

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

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

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

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

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

Extreme Programming (XP)

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

Mehr

KVP Kontinuierlicher Verbesserungsprozess

KVP Kontinuierlicher Verbesserungsprozess KVP Kontinuierlicher Verbesserungsprozess Kerstin Stangl 0010455 1 Allgemeines über KVP 1.1 Was ist KVP? KVP hat seinen Ursprung in der japanischen KAIZEN Philosophie (KAIZEN, d.h. ändern zum Guten). KAIZEN

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

Grundprinzipien der agilen Softwareentwicklung

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

Mehr

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

Agile Programmierung - Theorie II SCRUM

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

Mehr

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

Mehr

Agile Projekte in Auftrag geben

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

Mehr

Mit agilen Methoden kommen Sie weiter

Mit agilen Methoden kommen Sie weiter Mit agilen Methoden kommen Sie weiter Wir machen Sie und Ihr Unternehmen fit für Scrum. Was ist Scrum? Scrum ist ein agiles Produktentwicklungs-Framework zur schlanken Entwicklung von Software. Da Scrum

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

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

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

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

Mehr

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

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

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

- 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

Test-Driven Developement Eine Einführung

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

Mehr

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

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

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

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

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

Mehr

Extremes Programmieren

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

Mehr

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

SE Besprechung. Übung 3 Softwareprozesse

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

Mehr

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

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

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

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

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

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

RE-Metriken in SCRUM. Michael Mainik

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

Mehr

Systemen - Testen im Softwarelebenszyklus

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

Mehr

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

Software für die Wirklichkeit.

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

Mehr

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST Gliederung 2 0. 1. 2. 3. Vorstellung Testvorbereitungen Planungsphase Definitionsphase Implementierungs-, Abnahme-und Einführungsphase Testphasen

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

eg e s c h ä f t s p r o z e s s MEHR ZEIT FÜR IHR GESCHÄFT SHD managed Ihre IT-Services

eg e s c h ä f t s p r o z e s s MEHR ZEIT FÜR IHR GESCHÄFT SHD managed Ihre IT-Services eg e s c h ä f t s p r o z e s s erfahrung service kompetenz it-gestützte MEHR ZEIT FÜR IHR GESCHÄFT SHD managed Ihre IT-Services erfolgssicherung durch laufende optimierung Als langjährig erfahrenes IT-Unternehmen

Mehr

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

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

Mehr

Agile Softwareverträge

Agile Softwareverträge Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

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

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

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

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

Mehr

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

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

Mehr

Informationssystemanalyse Personal Software Process 8 1

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

Mehr

Ü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

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

Was versteht man unter Softwarequalität?

Was versteht man unter Softwarequalität? Was versteht man unter? ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist

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

(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

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

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

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

Einführung in Generatives Programmieren. Bastian Molkenthin

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

Mehr

Oktober 2014 PRODUKTENTWICKLUNG. Dr. Ralf Lauterbach

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

Mehr

Fortgeschrittenes Programmieren mit Java. Test Driven Development

Fortgeschrittenes Programmieren mit Java. Test Driven Development Fortgeschrittenes Programmieren mit Java Test Driven Development Test getriebene Programmierung Benedikt Boeck Hochschule für Angewandte Wissenschaften Hamburg 6. November 2009 B. Boeck (HAW Hamburg) Test

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

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

Mehr

Agile Softwareentwicklung

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

Mehr

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren - Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich Erstellung einer Lebenslaufakte Nicole Scheeren

Mehr

wir garantieren Ihnen die BetRIeBsKosten von MoRgen.

wir garantieren Ihnen die BetRIeBsKosten von MoRgen. wir garantieren Ihnen die BetRIeBsKosten von MoRgen. GANZHEITLICH. EFFIZIENZSTEIGERND. NACHHALTIG. BILFINGER ONE IST DAS KONZEPT FÜR DIE NÄCHSTE GENERATION VON PARTNERSCHAFT IN DER IMMOBILIENWIRTSCHAFT.

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

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

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

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

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

Mehr

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

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

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

Mehr

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

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

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

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

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

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

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

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

DIN EN ISO 9001:2008 Qualitätsmanagement

DIN EN ISO 9001:2008 Qualitätsmanagement DIN EN ISO 9001:2008 Qualitätsmanagement Handbroschüre 2012 Unser Qualliitätsmanagement zur Anallyse und Darstellllung verfügbarer Ressourcen Nach erfolgreicher Einführung und Umsetzung des Qualitätsmanagementsystem

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

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

Mehr

itestra Software Tuning Mehr Leistung. Weniger Kosten. Software Productivity

itestra Software Tuning Mehr Leistung. Weniger Kosten. Software Productivity itestra Software Productivity Software Tuning Mehr Leistung. Weniger Kosten. Fit für die Zukunft Performance-Defizite in Software-Systemen verursachen jedes Jahr Mehrausgaben für Betrieb und Nutzung in

Mehr

Markus Schramm compeople AG Frankfurt

Markus Schramm compeople AG Frankfurt Markus Schramm compeople AG Frankfurt Scrum kurz vorgestellt Bedeutung für agile Teams Kompetenzen und Zuständigkeiten Zusammenhang mit Softskills Transition Markus Schramm compeople AG 2 Individuen und

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr