Anwendungen Motivation. Motivation Prozess der Entwicklung von Web- Gregor Engels, Marc Lohmann, Annika Wagner

Größe: px
Ab Seite anzeigen:

Download "Anwendungen. 10.1. Motivation. Motivation 1. 10. Prozess der Entwicklung von Web- Gregor Engels, Marc Lohmann, Annika Wagner"

Transkript

1 Motivation Prozess der Entwicklung von Web- Anwendungen Gregor Engels, Marc Lohmann, Annika Wagner Zusammenfassung Ist es möglich klassische Softwareentwicklungsprozesse für die Entwicklung von Web-Anwendungen zu nutzen? Dazu formulieren wir sechs grundlegende Anforderungen an den Prozess der Entwicklung von Web-Anwendungen. Diese Anforderungen werden zur Evaluation des Rational Unified Process (RUP) und von Extreme Programming (XP) verwendet. Dabei konzentrieren wir uns auf den eigentlichen Prozess, d.h. die Organisation des Ablaufs der Entwicklung, und lassen die zugrunde liegenden Methoden so weit wie möglich ausgeklammert. Es zeigt sich, dass keiner der Prozesse in der Lage ist, alle Anforderungen zu erfüllen. Die Stärken des RUP liegen in seiner Anpassbarkeit an den Grad der Komplexität der zu entwickelnden Anwendung. Die Stärken von XP dagegen liegen im Umgang mit kurzen Entwicklungszeiten und sich erst entwickelnden bzw. sich ändernden Anforderungen Motivation Mit der zunehmenden Komplexität von Web-Anwendungen wächst auch die Bedeutung, die einem geordneten und organisierten Prozess ihrer Entwicklung zukommt. Eine allzu pragmatische Vorgehensweise, wie man sie heute noch weit verbreitet vorfindet [McWe01a], führt zwar zu schnellen, aber auch unsauberen Entwicklungen, deren Qualitätsmängel zu Problemen im Betrieb und der Wartung beitragen (vgl. Kapitel 1). Die Disziplin des Web Engineering ist noch so jung, dass sich bisher keine eigenen Prozesse für die Entwicklung von Web-Anwendungen entwickelt haben. Stattdessen versucht man für die traditionelle Softwareentwicklung konzipierte Prozesse anzupassen [WaRA02]. Dies erscheint auf den ersten Blick vielversprechend, weil diese Prozesse die Möglichkeit der Anpassung an die spezifischen Projektbedürfnisse bereits beinhalten. In diesem Kapitel verfolgen wir zunächst den gleichen Ansatz. Dazu betrachten wir als erstes die gegenüber

2 Grundlagen von Softwareentwicklungsprozessen 2 herkömmlichen Anwendungen spezifischen Anforderungen von Web-Anwendungen an einen Softwareentwicklungsprozess, die sich aus den spezifischen Eigenschaften von Web-Anwendungen ableiten lassen. Diese spezifischen Anforderungen nutzen wir, um zunächst die Möglichkeiten der Nutzung existierender Prozesse zu analysieren. Am Ende stellen wir dann unsere Vision eines Prozesses für die Entwicklung von Web-Anwendungen vor. Bevor wir damit jedoch beginnen können, sollen im folgenden Unterkapitel die dafür notwendigen grundlegenden Begriffe Methode, (leicht- und schwergewichtiger) Prozess, Iteration und Phase kurz erläutert werden Grundlagen von Softwareentwicklungsprozessen Wir unterscheiden zwischen der Definition eines Prozesses und der verwendeten Methoden bei der Entwicklung von Software. In der Literatur werden beide Begriffe häufig synonym verwendet, denn sowohl Prozess als auch Methode beschreiben das Vorgehen bei der Softwareentwicklung. Ein Prozess beschreibt jedoch eher das Vorgehen im Großen, während eine Methode das Vorgehen im Kleinen zum Inhalt hat. Den Unterschied erkennt man am besten, wenn man zunächst die gemeinsamen Merkmale betrachtet. Sowohl das Vorgehen im Kleinen wie auch das im Großen sind geprägt von der Verfolgung bestimmter Ziele und von den Randbedingungen, die sich aus Abhängigkeiten bestimmter Schritte untereinander und von äußeren Gegebenheiten ableiten. Methodische Abhängigkeiten ergeben sich aus inhaltlichen Gesichtspunkten, wenn z.b. das Ergebnis eines Schrittes als Eingabe für den nächsten Schritt benötigt wird. Ziele der Methoden sind ebenso inhaltlicher Art, so z.b. das Finden der Anforderungen oder die Beschreibung von Geschäftsprozessen. Außerdem beruhen Methoden auch auf der zur Realisierung zu verwendenden Technologie. So bereiten etwa Methoden zu objektorientierter Analyse und Entwurf eine objektorientierte Implementierung vor. Gemäß dieser Definition wurden in den Kapiteln 2, 3, 5 und 9 dieses Buches Methoden für die Entwicklung von Web-Anwendungen vorgestellt. Ziele des Prozesses dagegen betreffen die Organisation des Ablaufes der Softwareentwicklung. Das übergeordnete Ziel lautet vernünftiger Umgang mit den Projektrisiken. So ist z.b. die ökonomisch sinnvolle Planung des Personaleinsatzes ein Ziel des Prozesses. Organisatorische Abhängigkeiten ergeben sich z.b. aus der zur Verfügungen stehenden Zeit oder dem zur Verfügung stehenden Budget. Zusammenfassend werden also inhaltliche Gesichtspunkte der Planung von Softwareentwicklung durch Methoden behandelt, während organisatorische Gesichtspunkte dem Prozess vorbehalten sind. Methoden liefern daher Antworten auf die Fragen, WIE man etwas tun sollte und WANN man es (unter inhaltlichen Gesichtspunkten) machen KANN. Der Prozess dagegen beschreibt, WANN man etwas (unter organisatorischen Gesichtspunkten) tun SOLLTE. Der

3 Grundlagen von Softwareentwicklungsprozessen 3 Entscheidungsspielraum des Prozesses ist durch die ihm zugrunde liegende Methoden bereits eingeschränkt, da im Prozess die methodischen Abhängigkeiten berücksichtigt werden müssen. Andersherum definieren organisatorische Bedürfnisse, wie etwa die Notwendigkeit zur Kommunikation zwischen den Projektbeteiligten, auch Anforderungen an die Methoden. So kommt es, dass Methoden und Prozess eng aufeinander abzustimmen sind. Außer bei ganz allgemeinen Betrachtungen wie etwa der Unterscheidung des Wasserfallmodells der Softwareentwicklung vom Spiralmodell [GhMJ02] werden mit einem neuen Prozess fast immer gleichzeitig auch neue Methoden definiert. Dieses Konglomerat aus Prozess und Methoden wird dann in der Literatur häufig als Prozess bezeichnet. Beispiele hierfür sind der Rational Unified Process (RUP) [JaBR99, Kruc99] oder auch Extreme Programming (XP) [Beck99, BeFo00]. Wenn die Verwendung einer bestimmten UML [OMG01] Diagrammart wie im RUP zur Erreichung eines konkreten Zieles empfohlen werden, so ist dies Teil der Methoden da hier ein inhaltliches Ziel verfolgt wird. Soll die Programmierung in Paaren erfolgen, wie es von XP vorgeschlagen wird, so ist dies ebenso eine methodische Empfehlung. Denn die Vorteile eines solchen Vorgehens liegen in erster Linie darin, dass die Qualität des erzeugten Codes verbessert wird. Weiterhin übernimmt die Programmierung in Paaren auch die Aufgabe, Wissen im Team zu verbreiten. Das Programmieren in Paaren ist also ein Teil der Methode von XP, während die Entscheidung es durchgängig einzusetzen, Teil des Prozesses von XP ist. Eine adäquate Trennung zwischen Prozess und Methode ist bei heutigen Softwareentwicklungsprozessen also schwer zu bestimmen. Eine wesentliche Eigenschaft moderner Softwareentwicklungsprozesse ist das iterative Vorgehen. Darunter versteht man die langsame Fortentwicklung eines ersten Ergebnisses zum Endprodukt. Wichtig dabei ist die stetige Weiterentwicklung und Überarbeitung des Produktes, d.h. dieselben methodischen Schritte werden mehrfach angewendet. Dafür wird der gesamte Prozess in einzelne Iterationen unterteilt. Iteratives Vorgehen empfiehlt sich immer dann besonders, wenn ein eingespieltes Team in einer neuen Anwendungsdomäne eingesetzt werden soll. Durch die aufeinander folgenden Iterationen ist es dem Team möglich, einerseits sich langsam den unbekannten Anforderungen der neuen Anwendungsdomäne anzunähern und andererseits aus den eigenen Erfahrungen zu lernen (siehe auch [IBM97]). Eine zweite Möglichkeit der Unterteilung des Prozesses neben den Iterationen stellen die Phasen dar. In der Literatur werden Phasen fälschlicher Weise häufig gleichgesetzt mit den methodischen Tätigkeiten Anforderungsdefinition, Analyse, Entwurf, Implementierung, Testen und Wartung. Dies entspricht einem Vorgehen nach dem klassischen Wasserfallmodell, bei dem die methodischen Tätigkeiten linear aufeinander folgen. Das Problem bei diesem Ansatz besteht darin, dass die Risiken in die Zukunft verschoben werden. Tritt ein mögliches Risiko dann tatsächlich ein, so werden die Kosten zur Behebung eines Fehlers umso teurer, je später er bemerkt wird (siehe auch Kapitel 2). Eine Möglichkeit hier Abhilfe zu schaffen, ist ein phasen-

4 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess 4 orientiertes Vorgehen. Dabei bezeichnet eine Phase einen zeitlichen Ausschnitt der Softwareentwicklung und wird mit einem Meilenstein abgeschlossen. Jede Phase setzt sich ein den methodischen Tätigkeiten übergeordnetes Ziel. Die Auswahl dieses Zieles dient der möglichst frühzeitigen Behandlung von Risiken für das Projekt. Eine Phase definiert sich also in erster Linie durch die in ihr behandelten Risiken. Erst in zweiter Linie kann man einer Phase bestimmte methodische Tätigkeiten zuordnen, die gerade für die Behandlung der jeweiligen Risiken sinnvoll erscheinen. Bei den bekannten Softwareentwicklungsprozessen kann man zwischen den so genannten leichtgewichtigen Prozessen und den schwergewichtigen unterscheiden. Leicht bzw. schwer bezeichnet dabei den Grad der Formalisierung des Prozesses, d.h. wie viele Dokumente und Modelle erstellt werden. Damit sollte man also, um bei unserer Terminologie zu bleiben, besser von leichtgewichtigen und schwergewichtigen Methoden sprechen. Denn die Erstellung von Dokumenten und Modellen in einer bestimmten Form wird schon durch die Methode festgelegt. Schwergewichtige Prozesse werden insbesondere immer dann verwendet, wenn große Entwicklerteams Anwendungen mit hohen Qualitätsansprüchen entwickeln. Leichtgewichtige Prozesse sind dagegen bei weniger umfangreichen Anwendungen und dementsprechend kleineren Entwicklerteams ausreichend. Die große Auswahl verschiedenartiger Prozesse spiegelt die große Breite unterschiedlicher Softwareentwicklungsprojekte wider. Kein Prozess ist für alle Projekte gleichermaßen geeignet. Die Art der vorhandenen Risiken steuert die Auswahl des Prozesses. Web-Anwendungen weisen, wie auch bereits in Kapitel 1 bemerkt wurde, im Unterschied zu traditionellen Softwareprodukten eine Reihe von Besonderheiten auf. Dabei handelt es sich zum Teil um Aspekte, die in herkömmlichen Anwendungen gänzlich fehlen oder um Eigenschaften, die in Web- Anwendungen besonders stark ausgeprägt sind [RaPB02, McWe01b, Whit02]. Diese Charakteristika haben einen Einfluss auf die Anwendbarkeit herkömmlicher Entwicklungsprozesse. Die Diskussion dieser Anwendbarkeit soll im Zentrum des Kapitels stehen. Wir betrachten dazu den Rational Unified Process als Stellvertreter der Klasse schwergewichtiger, phasenorientierter und iterativer Prozesse sowie Extreme Programming als Beispiel für leichtgewichtige, iterative Prozesse. Bevor wir jedoch die Anwendbarkeit dieser Prozesse auf die Entwicklung von Web- Anwendungen betrachten, wollen wir aus den Charakteristika von Web- Anwendungen Anforderungen an ihren Entwicklungsprozess ableiten Anforderungen von Web-Anwendungen an einen Entwicklungsprozess Neben den in Kapitel 1 vorgestellten Charakteristiken von Web-Anwendungen haben noch die Ziele ihrer Erstellung, die damit verbundenen Risiken sowie die angestrebten Qualitätsmerkmale einen Einfluss auf die Anforderungen an einen

5 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess 5 Entwicklungsprozess. In der Literatur gibt es darüber hinaus empirische Studien, die tatsächliche Entwicklungsprozesse untersuchen [McWe01a, McWe01b, Low02]. Manche der Ergebnisse dieser Studien lassen sich als grundsätzliche Anforderungen an einen Entwicklungsprozess auffassen. Andere Ergebnisse zeigen Probleme bei der Entwicklung von Web-Anwendungen, die nicht mit gegenwärtigen Prozessen gehandhabt werden können. Im Folgenden leiten wir so die sechs, in unseren Augen wichtigsten Anforderungen von Web-Anwendungen an ihren Entwicklungsprozess ab. Aus den sechs Hauptanforderungen ergibt sich eine Reihe von Konsequenzen, die wir in diesem Zusammenhang auch diskutieren Umgang mit kurzen Entwicklungszeiten Eine mehrfach empirisch festgestellte Tatsache ist die besonders kurze Entwicklungszeit von Web-Anwendungen, die sechs Monate nicht übersteigt und im Durchschnitt sogar unter drei Monaten liegt [McWe01a, McWe01b]. Die Gründe für diese kurzen Entwicklungszeiten sind für Web-Anwendungen derart typisch, dass man davon ausgehen muss, im Umgang mit kurzen Entwicklungszeiten eine erste Anforderung an den Prozess der Entwicklung von Web-Anwendungen gefunden zu haben. Diese kurzen Entwicklungszeiten lassen weniger Spielraum für einen systematischen Entwicklungsprozess. Im Bereich des Webs ist der Konkurrenzdruck außerordentlich stark (vgl. auch Kapitel 1). Unverzüglicher Präsenz wird ein höherer Stellenwert beigemessen als einer langfristigen Perspektive [Pres98]. Beim Web handelt es sich um einen internationalen Markt, dessen Größe nicht einschätzbar ist. Als Ergebnis ergibt sich eine extreme Notwendigkeit, anderen auf dem Markt zuvorzukommen, um sich einen Marktanteil zu sichern [RaPB02]. Die Möglichkeit aufgrund des impliziten Auslieferungsmechanismus des Webs (vgl. Kap. 1) ein Produkt sofort zu veröffentlichen verstärkt diese Notwendigkeit noch. Wenn eine überraschende neue Funktionalität durch einen Konkurrenten zuerst auf den Markt gebracht wird, entsteht ein enormer Druck, diese Funktionalität auch anzubieten. Ansonsten besteht die Gefahr außerordentlich schnell Marktanteile zu verlieren. Der Grund ist, dass wie bereits in Kapitel 1 beschrieben keine Loyalität eines Kunden zum Web-Anbieter erwartet werden kann, da die Konkurrenz nur einen»mausklick«entfernt ist. Außerdem ist zu beachten, dass es sich bei vielen Web-Anwendungen um ein Instrument des Marketings handelt. Marketingmaßnahmen unterliegen einem besonderen Zwang neu und aktuell zu sein, da sie nur dadurch attraktiv bleiben und ihren Zweck erfüllen können.

6 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess Umgang mit sich erst entwickelnden bzw. sich ändernden Anforderungen, Inhalten und Technologien Ein mit der vorigen Anforderung stark verwandter Punkt ist die Tatsache, dass sich die Anforderungen an eine Web-Anwendung häufig erst während ihrer Entwicklung herausstellen bzw. sich in dieser Zeit sowohl inhaltlich als auch technologisch noch sehr stark verändern. Schließlich bewegt man sich mit einem solchen Projekt meistens in einem unbekannten Geschäftsfeld und die Geschäftsbedürfnisse können sich durch ein besseres Verständnis des Geschäftsfeldes, wie es während des Projektes zwangsläufig entsteht, drastisch ändern [RaPB02]. Neue Anforderungen, die sich durch eine geänderte Marktlage ergeben, müssen schnell eingearbeitet werden, um der Konkurrenz keinen zu großen Marktvorsprung zu erlauben. Als Konsequenz der oben beschriebenen Fokussierung auf eine schnelle Entwicklung ist eine präzise Definition von Anforderungen häufig gar nicht möglich. Unvollständige und mehrdeutige Anforderungen müssen akzeptiert werden, da ohnehin nicht davon ausgegangen werden kann, dass die Anforderungen stabil bleiben und daher eine ausführlichere Beschäftigung mit ihnen lohnenswert wäre. Eine zur Festlegung stabiler Anforderungen notwendige detaillierte Analyse der Nutzergruppe ist für Web-Anwendungen sowieso eher unrealistisch, da sich diese wie bereits in Kapitel 1 beschrieben durch eine nicht bestimmbare Heterogenität auszeichnet. Stattdessen hat sich, aufgrund der Tatsache, dass die Verteilung der Software (auch in Teilen) sofort erfolgen kann, die Praxis eingebürgert, aus den Reaktionen der Endkunden auf die Veröffentlichung von Teilen der Web-Anwendung Rückschlüsse auf die tatsächlichen Anforderungen zu ziehen. Selbst Funktionalitäten, die aufgrund neuerer Erkenntnisse nicht mehr unbedingt als notwendig und wichtig erscheinen, werden trotzdem mit dem Wunsch veröffentlicht, eventuell die Aufmerksamkeit des Marktes auf sich zu ziehen [RaPB02]. Bei Webprojekten fällt es den Auftraggebern häufig noch wesentlich schwerer als bei anderen Softwareentwicklungsprojekten, ihre Anforderungen zu formulieren, da sie sich mit dem Problembereich und mit möglichen Lösungen nicht auskennen [Low02]. Dadurch haben Entwicklungsprozesse für Web-Anwendungen häufig einen leicht verschobenen Fokus [CrCl99, Four98], in der Hinsicht, dass sie auch eine Entwicklung des Verständnisses des Problembereichs unterstützen. Auch eine direkte Verbindung zum möglichen Mehrwert, der durch die Entwicklung einer Funktionalität oder die Bereitstellung gewisser Inhalte erzielt werden soll, ist nicht immer sichtbar [WaRA02]. Die notwendige ständige Aktualisierung der bereitgestellten Daten ist ein weiterer Aspekt der zu häufigen Änderungen der Anforderungen an die Anwendungslogik führt, da dies häufig auch eine Neustrukturierung der Daten sowie veränderte Qualitätsansprüche der Auftraggeber an die Inhalte nach sich zieht (vgl. auch Kapitel 1). Neben diesen Ursachen für den Evolutions-Aspekt von Web-Anwendungen ist die permanente Änderungsdynamik auch auf die entsprechend hohe Änderungsrate der Technologien und Standards zurückzuführen. Der bereits oben angesprochene hohe

7 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess 7 Konkurrenzdruck macht eine Anpassung an diese Technologien und Standards erforderlich [KaRS00, Scha00]. Auch wird in empirischen Untersuchungen zu diesem Punkt häufig die mangelnde Erfahrung bei der Entwicklung derartiger Produkte beklagt [RaPB02, McWe01b]. Nie zuvor war es möglich ein und dieselbe Funktionalität einem derart heterogenen Benutzerkreis zugänglich zu machen, der zudem auch noch unterschiedliche Plattformen verwendet (vgl. auch Kapitel 1). Besonders betrifft dies den Bereich der Benutzungsschnittstellen. Mehr und mehr Funktionalität muss den Anwendern mit einer eingeschränkten Benutzungsschnittstelle zur Verfügung gestellt werden. Versucht man Rückschlüsse auf die Zukunft der Entwicklung von Web- Anwendungen zu ziehen, so könnten die Unsicherheiten und die Instabilität, die von den letzten beiden Punkten ausgeht, in Zukunft durchaus irgendwann wegfallen bzw. geringer werden. Wir betrachten den Umgang mit sich erst entwickelnden bzw. sich ändernden Anforderungen an eine Web-Anwendung dennoch als eine Anforderung an den Prozess der Entwicklung von Web-Anwendungen, da die Möglichkeit der Erprobung der Software und die damit verbundene Evolution der Anforderungen sowie der starke Konkurrenzdruck niemals verschwinden werden. Eine direkte Konsequenz dieser Anforderung an den Prozess betrifft die Bindung des Auftraggebers an das Entwicklungsteam. Durch die sich erst entwickelnden und nicht stabilen Anforderungen sind die Auftraggeber stark in die Entwicklungsfortschritte eingebunden. Optimal wäre es, wenn Auftraggeber sich häufig am selben Ort wie das Entwicklungsteam befinden und sich dadurch durchgehend an der Entwicklung beteiligen können. Gleichzeitig ist der eng eingebundene Auftraggeber auch für die Produktion, Integration und Aktualisierung der Inhalte der Web-Anwendung von Vorteil [McWe01b]. Diese Notwendigkeit ist ein Unterscheidungsmerkmal für Web-Anwendungen (vgl. Kapitel 1). Die rechtzeitige Produktion der Inhalte stellt eines der größten Risiken eines Web- Projektes dar Definition eines Release mit festen Deadlines, aber flexiblen Inhalten ermöglichen Eine indirekte Konsequenz der letzten Anforderung an den Prozess stellt die Notwendigkeit dar, eine spezielle Art des Prototypings im Entwicklungsprozess zu verankern. Hierbei werden»wegwerf«-releases entwickelt, um die Anforderungen der Auftraggeber zu validieren und zu detaillieren. Diese explorative Art der Entwicklung einer Systemspezifikation wurde als gängige Praxis unter anderem von Lowe [Low02] und McDonald und Welland [McWe01b] ermittelt. Die Auftraggeber beschreiben die grundlegende Funktionalität und die Prototypen werden schnell zu Demonstrationszwecken entwickelt. Prototyping dient somit zur Kommunikation mit dem Auftraggeber. Anders als bei der herkömmlichen Softwareentwicklung werden die»wegwerf«-releases einer Web-Anwendung jedoch veröffentlicht. Ein

8 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess 8 veröffentlichtes Produkt kann ja schnell mal eben durch eine neue Version ersetzt werden. Aus den Reaktionen auf die Veröffentlichung lassen sich zudem ggf. interessante Rückschlüsse auf die Weiterentwicklung der Anforderungen ziehen. Die Abstände zwischen den Releases sind verhältnismäßig klein (zwischen zwei und fünfzehn Tagen gilt gegenwärtig als normal) [RaPB02]. Wichtiger als die Planung der Anforderungen an ein Release ist die zeitliche Planung der Folge von Releases sowie deren Evaluation. Damit definiert sich ein Release nicht über bestimmte, im Vorfeld festgelegte Inhalte, sondern lediglich über eine einzuhaltende Deadline, zu der das Release fertig gestellt sein muss. Einzelne Features, deren Fertigstellung bis zu diesem Zeitpunkt nicht gelingt, werden problemlos in das nächste Release verschoben. Die Anforderungen an das nächste Release müssen variabel sein, um der durchgehenden Marktbeobachtung und Priorisierung der Features gerecht zu werden. Features können auf ein späteres Release verlagert werden, aber auch vorgezogen werden. Dies stellt aufgrund der kurzen Abstände zwischen den Releases und der Einfachheit ihrer Verteilung (durch die keine nennenswerten Kosten entstehen) kein gravierendes Problem dar. Ebenso wichtig in diesem Zusammenhang ist, dass es sich bei Web-Anwendungen selten um kritische Anwendungen (wie etwa im Bereich der Medizin) handelt. Denn hohe Qualitätsanforderungen setzen eine stärkere inhaltliche Planung an ein Release voraus. Insbesondere die Wartbarkeit ist bei Web-Anwendungen eine häufig vernachlässigte Qualitätsanforderung. Wenn die Software schnell überholt ist und durch neu entwickelte Versionen ersetzt wird, ist Wartbarkeit nicht von besonderem Interesse. Diese Art der Release-Orientierung hat neben den oben aufgeführten Gründen, die unserer Meinung nach auch langfristig erhalten bleiben werden, noch einen weiteren Vorteil. Ein Hauptproblem der Entwicklung von Web-Anwendungen ist das Fehlen geeigneter Metriken, mit deren Hilfe Aufwand und Entwicklungszeit gemessen, verglichen und dann auch solide geschätzt werden können. Projekte mit derart vagen und veränderlichen Anforderungen längerfristig zu planen, scheint zum gegenwärtigen Zeitpunkt unrealistisch. Die Release-Orientierung bietet hier eine geeignete Alternative (vgl. auch Kapitel 9) Möglichkeit zur parallelen Entwicklung verschiedener Releases Die Stärke des Wettbewerbs veranlasst die Konkurrenten, die Releasezyklen so zu verkürzen, dass nur noch überlappende, parallele Entwicklung unter diesem Zeitdruck zum Ziel führen kann. Die einzelnen methodischen Tätigkeiten aus Design, Implementierung und Qualitätssicherung erfolgen also gleichzeitig für verschiedene Releases (vgl. auch Kapitel 1). In der Regel arbeiten mehrere kleine Entwicklerteams parallel an ähnlichen Aufgaben [McWe01b]. Daraus ergeben sich neue Anforderungen für die Planung des Einsatzes der Mitarbeiter in Webprojekten.

9 Anforderungen von Web-Anwendungen an einen Entwicklungsprozess 9 Die notwendigen Absprachen sind bei der Entwicklung von Web-Anwendungen besonders umfangreich. Dafür werden in Prozessen wie z.b. Scrum [RiJa00, ScBe01], die explizit die parallele Entwicklung verschiedener Releases vorschlagen, kurze regelmäßige Treffen aller Projektmitarbeiter vorgesehen. Solche Treffen würden wir nicht direkt als Anforderung an den Prozess der Entwicklung von Web-Anwendungen ansehen. Ein wie auch immer gearteter Umgang mit dem erhöhten Kommunikationsbedarf muss jedoch durch den Prozess geregelt werden. Insbesondere folgt hieraus die oben bereits angesprochene Beschränkung der Teamgröße Unterstützung der Abstimmung mit Entwicklungsprozessen anderer (Web-)Anwendungen Zu den Konsequenzen des enormen Zeitdrucks bei der Entwicklung von Web- Anwendungen zählt die Tatsache, dass die Entwickler versuchen müssen, so viele Komponenten wie möglich wieder zu verwenden [RaPB02]. Häufig geht es in der Entwicklung um die Interoperabilität und Integration verschiedener Komponenten, die extern entwickelt oder eingekauft wurden. Der Entwicklungsprozess einer Web-Anwendung ist daher nicht losgelöst von den Entwicklungsprozessen anderer Web-Anwendungen innerhalb derselben Organisation durchführbar. Soll eine widerverwendbare Komponente entwickelt werden, so ist ihre Entwicklung mit den Entwicklungsprozessen der sie verwendenden Web- Anwendungen abzustimmen. Ebenso verhält es sich im umgekehrten Fall, dass eine Komponente einer anderen Web-Anwendung wieder verwendet werden soll. Häufig ist es auch lohnend für mehrere Web-Anwendungen eine gemeinsame Architektur zu entwickeln. Es sind also sowohl die angestrebten Ergebnisse als auch die Vorgehensweisen zu deren Erreichung abzustimmen. Wie diese Abstimmung erfolgen soll ist jedoch nicht ausschließlich ein Problem des Prozesses, sondern ist auch massiv von den verwendeten Methoden abhängig. Ein Problem hierbei ist, dass die Konzepte zur Wiederverwendung von Komponenten bei Web-Anwendungen noch nicht ausgereift sind, da Web-Anwendungen häufig nicht objektorientiert entwickelt werden. Weiterhin steigt mit der wachsenden Integration von Web-Anwendungen in allgemeine Geschäftsprozesse auch die Notwendigkeit der Integration der Web- Anwendungen mit bereits existierenden und sich in der Entwicklung befindenden (Web-)Anwendungen. Auch diese Integration erfordert eine Abstimmung der Entwicklungsprozesse aufeinander. Hier prallen die Bedürfnisse der Entwicklung von Web-Anwendungen und die herkömmlicher Softwareentwicklungprojekte aufeinander.

10 Analyse des Rational Unified Process (RUP) Anpassung an die Entwicklungsstufe der Web- Anwendung Wie bereits oben beschrieben wird bei der Entwicklung von Web-Anwendungen der Einhaltung kürzerer Entwicklungszeiten ein höherer Stellenwert beigemessen als einigen Qualitätsanforderungen. Skalierbarkeit und Wartbarkeit sind Beispiele für solche zurückgestellten Qualitäten. Es werden sukzessive weitergehende Funktionalitäten von Produkten veröffentlicht. In frühen Entwicklungsstufen noch fehlende Qualitäten werden später in nachfolgenden Veröffentlichungen behoben, indem Komponenten ersetzt und neu entwickelt werden. Dies wird einer ausführlichen Planung und Dokumentation vorgezogen. Bis zu einem gewissen Grad an Komplexität, was sowohl die Applikationslogik als auch die Inhalte angeht, stellt das ein brauchbares Vorgehen dar. Mit der wachsenden Integration einer Web-Anwendung in die Geschäftsprozesse des Auftraggebers, wird dieses Vorgehen jedoch immer weniger praktikabel. Die Entwicklung der Web-Anwendung ist dann aufgrund der gestiegenen Komplexität nicht mehr adhoc ohne eine detaillierte Planung beherrschbar. Somit ist der Prozess zur Entwicklung von Web-Anwendungen abhängig von ihrer Komplexität, von den Qualitätsanforderungen und damit letztendlich von der Einordnung in die Kategorien von Web-Anwendungen aus Kapitel 1. Er muss sich dynamisch der Entwicklungsstufe anpassen Zusammenfassung Viele Charakteristiken, die typisch für die Entwicklungsprozesse von Web- Anwendungen sind, können auch bei traditionellen Softwareentwicklungsprozessen berücksichtigt werden, nur sind das gemeinsame Auftreten und die Intensität anders [RaPB02]. So steht z.b. fast jedes Softwareentwicklungsprojekt unter Zeitdruck und auch Änderungen der Anforderungen sind durchaus üblich. Die besondere Intensität dieser Charakteristiken führt bei der Entwicklung von Web- Anwendungen jedoch dazu, dass sich eine andere Art von Releaseplanung zumindest in den frühen Entwicklungsstufen einer Web-Anwendung als vorteilhaft erwiesen hat. Die Tatsache, dass solche Entwicklungsstufen sich überhaupt in der Art auszeichnen lassen, stellt eine Besonderheit der Entwicklung von Web-Anwendungen dar. Ein Grund ist die einfache Möglichkeit, ein neues Release zu veröffentlichen und damit dem Endkunden zugänglich zu machen Analyse des Rational Unified Process (RUP) In diesem Unterkapitel soll die Übertragbarkeit des RUP auf die Entwicklung von Web-Anwendungen diskutiert werden. Dazu fassen wir zunächst die wesentlichen Eigenschaften des RUP zusammen, die für das Verständnis der folgenden

11 Analyse des Rational Unified Process (RUP) 11 Überlegungen notwendig sind. Ausgehend von den vier Phasen die ein Vorgehen nach dem RUP charakterisieren, machen wir dann einige generelle Einschränkungen, was die Übertragbarkeit auf die Entwicklung von Web-Anwendungen angeht. Danach betrachten wir umgekehrt die in Unterkapitel 10.3 aufgestellten Anforderungen an den Prozess der Entwicklung von Web-Anwendungen und untersuchen, welche von ihnen der RUP erfüllen kann Kurze Einführung RUP Der RUP [JaBR99] wird hier stellvertretend analysiert für die Familie schwergewichtiger, phasen-orientierter, inkrementeller und iterativer Prozesse. Ziel dieser Prozesse ist es, die Entwicklung eines qualitativ hochwertigen Produktes innerhalb eines festen Zeitraumes und zu einem festen Preis zu ermöglichen. Dieses Produkt soll einen fest definierten Mehrwert für den späteren Nutzer darstellen. Wie oben bereits erläutert verfügen die meisten Softwareentwicklungsprozesse über angepasste Methoden, ohne dass Prozess und Methoden überhaupt sauber voneinander getrennt werden. Im RUP werden die Methoden zu verschiedenen Kernworkflows zusammengefasst (vgl. Teil II in [JaBR99]) und auch entsprechend beschrieben. Diese Namensgebung trägt u. a. der Tatsache Rechnung, dass einzelne methodische Schritte wie die Aktivitäten eines beliebigen anderen Workflows voneinander abhängig sein können. Der Charakter der Kernworkflows, in denen ausführliche Modelle und Dokumente erstellt werden, macht den RUP zu einem schwergewichtigen Prozess. Dieser Aspekt des RUP soll hier jedoch nicht näher betrachtet werden. Für Überlegungen zu Methoden für die Entwicklung von Web- Anwendungen verweisen wir auf die Kapitel 2, 3, 5 und 9 dieses Buches. Die inkrementelle Vorgehensweise basiert auf der Grundidee, dass ein System in seiner Gesamtheit geplant, aber in Teilen realisiert wird - mit einem ständigen, stufenweisen Zuwachs an Funktionalität bzw. Qualität. Im Regelfall wird an den Anwender möglichst frühzeitig eine erste Systemversion ausgeliefert, welche die Basisfunktionalität bietet. Später entwickelte (und gelieferte) Systemteile erweitern die Funktionalität im Wesentlichen nur. Auf diese Art und Weise soll mit der wachsenden Komplexität von Softwaresystemen umgegangen werden, deren Beherrschung als Risiko anzusehen ist. Es wird bei dieser inkrementellen Vorgehensweise davon ausgegangen, dass die Anforderungen der Anwender bereits in ihren wesentlichen Aspekten vollständig zu Beginn der Entwicklung erfasst werden können und dass es möglich ist, das gesamte System in verschiedenen Teilabschnitten bzw. Ausbaustufen (im Englischen»increments«oder»builds«) zu entwerfen, zu entwickeln, einzuführen und zu nutzen. Die inkrementelle Vorgehensweise spiegelt sich in den Zielen der vier Phasen des RUP wider [Kruc99]. Die erste Phase ist die so genannte»anfangsphase«(inception phase). Ziel dieser Phase ist es, mit den Auftraggebern und den späteren Nutzern des Systems eine gemeinsame Vision des Endproduktes zu entwickeln. Dazu gehört die

12 Analyse des Rational Unified Process (RUP) 12 Festlegung der grundlegenden Anforderungen, d.h. eine Abgrenzung dessen, was das System leisten soll, von dem, was es nicht leisten soll. Dies ist die Basis für das inkrementelle Vorgehen. Außerdem gehört dazu aber auch die Überprüfung der Machbarkeit der Architektur, d.h. innerhalb der Anfangsphase muss mindestens eine Architektur für die Anforderungen gefunden und ausprobiert werden. Die zweite Phase des RUP ist die»ausarbeitungsphase«(elaboration phase). Das übergeordnete Ziel dieser Phase ist, die größten Projektrisiken soweit auszuschalten, dass am Ende dieser Phase eine Festpreisentwicklung möglich ist. Die Wahl einer optimalen, erweiterbaren Architektur und die Einarbeitung der Mitarbeiter in die zu verwendenden Technologien dienen diesem Ziel. Auf die Ausarbeitungsphase folgt dann die»konstruktionsphase«(construction phase), in der es um die Implementierung aller verbleibenden Komponenten und ihre Integration in das Produkt geht. Ausführliche Tests sind ebenso Bestandteil dieser Phase. Abgeschlossen wird das Projekt durch die»übergangsphase«(transition phase), in der es um die Integration des Produktes in die Umgebung des Benutzers geht. Der RUP ist ein iterativer Prozess, da innerhalb der einzelnen Phasen ein iteratives Vorgehen vorgesehen wird. Dabei ordnet sich der Charakter der Iterationen innerhalb einer Phase den Zielen der Phase unter. So dient etwa eine Iteration in der Anfangsphase der Entwicklung eines Prototyps des Systems, mit dessen Hilfe die Anforderungen mit dem Auftraggeber und dem Nutzer abgeklärt werden sollen. Eine oder mehrere Iterationen in der Ausarbeitungsphase dagegen haben in der Regel den Anspruch einen Teil der Architektur (ohne die komplette Funktionalität) zu realisieren. Alternativ kann die Entwicklung einer für die spätere Akzeptanz des Systems besonders entscheidenden Funktionalität des Systems bereits in dieser Phase Inhalt einer Iteration sein, wenn damit gleichzeitig neue Mitarbeiter eingearbeitet werden oder die Mitarbeiter sich mit einer neuen Technologie vertraut machen. In der Konstruktionsphase schließlich setzt man Iterationen ein, wenn z.b. bei einer Menge ähnlicher Funktionalitäten die Realisierung einer dieser Funktionalitäten als Vorlage für die übrigen verwendet werden kann. Auch eine Steigerung von Performance- Anforderungen von Iteration zu Iteration ist denkbar. Gemeinsam ist allen diesen Möglichkeiten der Grundgedanke des iterativen Vorgehens aus den Fehlern und Unzulänglichkeiten der vorhergehenden Iteration etwas für die kommenden Iterationen zu lernen Eignung der Phasen des RUP zur Entwicklung von Web-Anwendungen In diesem Abschnitt wird die Übertragbarkeit der Phasen des RUP auf die Entwicklung von Web-Anwendungen diskutiert. Damit wird überprüft ob auch bei der Entwicklung von Web-Anwendungen das angestrebte Ziel des RUP erreicht werden kann. Hierzu muss beurteilt werden, ob die Projektrisiken in den frühen Phasen so weit auszuschließen bzw. zu reduzieren sind, dass der meiste

13 Analyse des Rational Unified Process (RUP) 13 Entwicklungsaufwand innerhalb eines festen Zeitraumes und zu einem festen Preis in der Konstruktionsphase investiert werden kann (vgl. [Kruc99, S. 68]). Anfangsphase: Die Definition der ersten Phase ist bei der Entwicklung von Web-Anwendungen problematisch. Eine derart konkrete Vision des Gesamtproduktes, wie sie vom RUP erwartet wird, entsteht hier erst im Laufe der Projektlaufzeit. Als Instrument des Marketings hat eine Web-Anwendung eine Zielgruppe, deren Bedürfnisse im Vorfeld nur unzureichend bekannt sind und die sich auch durch den Einfluss des Marktes ständig ändern. Dadurch ist es notwendig, Annahmen über die Akzeptanz durch die Nutzer fortlaufend empirisch zu überprüfen und die Vision des Produktes gemäß den Ergebnissen dieser empirischen Untersuchung anzupassen. Die Vision einer Web-Anwendung entwickelt sich also stetig fort, während sich die Web-Anwendung bereits im Einsatz befindet. Aufwändige Untersuchungen zur Festlegung der Vision bevor mit der Entwicklung begonnen wird würden viel zuviel Zeit in Anspruch nehmen. Es besteht dann die Gefahr, dass die Vision bei der Fertigstellung des Produktes bereits wieder überholt ist. Ausarbeitungsphase: Auch diese Phasendefinition entspricht unseres Erachtens nicht den Anforderungen bei der Entwicklung von Web-Anwendungen. Wichtigstes Argument dafür ist die Tatsache, dass statt einer Festpreisentwicklung für ein eindeutig definiertes Endprodukt viel eher eine extrem kurze Entwicklungszeit einer ersten Produktversion angestrebt wird. Ursache hierfür ist, dass die mit dem Einsatz der Software verbundenen Risiken schwerer wiegen als die Risiken der eigentlichen Entwicklung. Der wirtschaftliche Erfolg einer Web-Anwendung lässt sich noch schwerer vorhersehen als der eines herkömmlichen Softwareproduktes. Web-Anwendungen haben nämlich im Gegensatz zu herkömmlicher Software kaum die Möglichkeit eine dauerhafte Kundenbindung zu erreichen (vgl. z.b. die Verdrängung anderer Suchmaschinen durch Google). Die einzige bekannte Art der Kundenbindung wird dadurch erreicht, dass eine Web-Anwendung als erste ihrer Art auf den Markt kommt (vgl. z.b. das Internetauktionshaus Ebay). Betrachten wir nun die untergeordneten Ziele dieser Phase. Die Einarbeitung der Mitarbeiter in die zu verwendenden Technologien ist sicherlich auch für die Entwicklung von Web-Anwendungen ein wichtiger Punkt. Ohne den Druck einer Festpreisentwicklung, die zu einem bestimmten Zeitpunkt beginnt, kann diese Einarbeitung jedoch auch noch später erfolgen. Sie sollte lediglich abgeschlossen sein, bevor die Komplexität der anstehenden Aufgaben zu groß wird. Die frühzeitige Festlegung einer gegenüber Änderungen stabilen Architektur ist ebenso wünschenswert. Die grobe Systemarchitektur ist durch die technischen Randbedingungen des Internets (Client-Server Architektur) ohnehin vorgegeben (vgl. Kapitel 4). Was feingranulare frühzeitige Architekturentscheidungen anbetrifft, stellt sich im Moment weniger die Frage, ob das wünschenswert wäre,

14 Analyse des Rational Unified Process (RUP) 14 als die der Machbarkeit. Solche feingranularen Architekturentscheidungen betreffen die Wahl der Technologie, wie z.b. JSP, PHP oder ASP, zur Realisierung einer Web-Anwendung auf der Serverseite. Diese Technologien unterliegen noch einem stetigen Wandel, wodurch methodische Unterstützung zur Auswahl der richtigen Technologie sich heutzutage kaum entwickeln kann. Konstruktionsphase: Selbstverständlich gibt es auch bei der Entwicklung von Web-Anwendungen Phasen, in denen die eigentliche Konstruktion stattfinden muss. Aufgrund der oben bei der Anfangsphase geführten Diskussion ist lediglich fraglich, ob es einen Zeitpunkt geben kann, zu dem genau feststeht, welche weiteren Komponenten noch zu entwickeln sind. Übergangsphase: Die Übergangsphase ist auch bei Web-Anwendungen unter Umständen sinnvoll. Vor allem, wenn einer Web-Anwendung iterativ neue Funktionalitäten hinzugefügt werden, kann dies eine Datenmigration oder einen Parallelbetrieb zweier Versionen nach sich ziehen. Die Übergangsphase kann sich jedoch auch sehr einfach gestalten, wenn es möglich ist, eine existierende Anwendung einfach durch eine neue Version zu ersetzen. Anders als bei herkömmlicher Software ist keine Distribution im eigentlichen Sinne zum Anwender notwendig, da diese aufgrund der Architektur des Webs automatisch gegeben ist. Auch gibt es in der Regel keine Schulungen für die Anwender. Die Diskussion der Übertragbarkeit der Phasen hat gezeigt, dass das angestrebte Ziel einer Konzentration des Entwicklungsaufwandes auf eine Phase, zu deren Beginn die meisten Projektrisiken bereits ausgeschlossen sind, für die Entwicklung von Web- Anwendungen relativ unrealistisch erscheint RUP und die Anforderungen der Entwicklung von Web- Anwendungen Lassen wir für die folgenden Betrachtungen einmal die Bedenken bzgl. der Tauglichkeit der Phasen außer Acht und nehmen wir an, dass wir ein Web Engineering Projekt mit den so definierten Phasen durchführen wollen. Dann soll im Folgenden untersucht werden, in wieweit ein so gestalteter Prozess den weiter oben definierten Anforderungen der Entwicklung von Web-Anwendungen gerecht werden kann. 1. Umgang mit kurzen Entwicklungszeiten Die typischen Laufzeiten eines Projektes, für das der RUP entwickelt wurde, unterscheiden sich stark von denen, die für die Entwicklung von Web- Anwendungen normal sind. Kurze Entwicklungszeiten einzuhalten, würde

15 Analyse des Rational Unified Process (RUP) 15 deutliche Abstriche bei der Erstellung von Modellen und daraus resultierenden Dokumenten sowie Iterations- und Phasenplänen verlangen. Das Problem liegt also in der Schwergewichtigkeit des Prozesses. Entzieht man dem Prozess jedoch seine methodischen Grundlagen, ist unklar, ob die für die einzelnen Phasen definierten Ziele dann überhaupt noch erreichbar sind. Insgesamt ist diese Anforderung daher als sehr kritisch anzusehen. 2. Umgang mit sich erst entwickelnden bzw. sich ändernden Anforderungen, Inhalten und Technologien Gemäß der Definition der Phasen des RUP muss am Ende der Anfangsphase eine konkrete Vision der zu entwickelnden Web-Anwendung existieren. Angesichts sich erst entwickelnder Anforderungen würde diese Phase im Vergleich zu vielen herkömmlichen Softwareentwicklungsprojekten somit eher mehr Zeit in Anspruch nehmen. Dies steht im Widerspruch zur obigen Forderung nach kurzen Entwicklungszeiten. Diese Problematik wurde bereits bei der Diskussion der Machbarkeit einer Anfangsphase für die Entwicklung von Web-Anwendungen ausführlich behandelt. Insgesamt ist diese Anforderung daher auch als kritisch anzusehen. 3. Definition von Releases mit festen Deadlines, aber flexiblen Inhalten ermöglichen Im RUP steht am Ende jeder Iteration ein Release. Die Anforderung lautet also die Planung der Iteration so zu gestalten, dass die Inhalte flexibel bleiben, aber das Ende der Iteration feststeht. Dies steht im Gegensatz zur Forderung des RUP, die Planung einer Iteration bereits vor deren Beginn abzuschließen. Hier wird eine Iteration gerade als»genau die richtige (planbare) Zeitspanne«angesehen [Kruc99, S.114]. Diese Iterationspläne können im Detail noch angepasst werden. Anpassungen müssen jedoch innerhalb eines gewissen Rahmens bewegen, der die grundsätzliche Planung nicht in Frage stellt. Dies wird deutlich, wenn man berücksichtigt, dass der Iterationsplan unter anderem die Aufgabe hat den Erfolg der Iteration überprüfbar zu machen und so einen möglichst objektiven Maßstab für den Projektfortschritt zu schaffen. Der Erfolg einer Iteration mit flexiblen Inhalten ist in diesem Sinne gar nicht überprüfbar. Er definiert sich einzig und allein durch die Einhaltung des geplanten Endes der Iteration. Eine Beurteilung des Projektfortschrittes auf dieser Basis erscheint schwierig. Die frühzeitige Zuordnung von Tätigkeiten und Verantwortlichkeiten zu Projektmitarbeitern in einem Iterationsplan ist in dem Moment, wo von vornherein klar ist, dass die Ziele und Inhalte der Iteration sich ändern können, nicht mehr sinnvoll. Hält man an der Erstellung eines solchen Planes fest, so muss er ständig aktualisiert werden. Der Änderungsaufwand zur Aktualisierung der Iterationspläne, um die Inhalte eines Release flexibel zu gestalten, steht im Gegensatz zum recht fragwürdigen Nutzen, den der Plan noch hätte, da er dann nicht mehr der Überprüfbarkeit des Projektfortschrittes dient. Damit wird diese Anforderung nicht erfüllt.

16 Analyse des Rational Unified Process (RUP) Möglichkeit zur parallelen Entwicklung verschiedener Releases Die parallele Entwicklung verschiedener Releases müsste im RUP in parallelen Iterationen erfolgen. Vorgesehen ist dies im RUP nur innerhalb der Konstruktionsphase [Kruc99, S.71]. Innerhalb anderer Phasen ist es jedoch auch denkbar. Phasenübergreifende Parallelentwicklung widerspricht jedoch der Grundidee der Phasen, nachdem erst mit der Erreichung des Meilensteines der vorherigen Phase mit der nächsten begonnen werden sollte. Insgesamt kann diese Anforderung jedoch als durch den RUP erfüllt betrachtet werden. 5. Unterstützung der Abstimmung mit Entwicklungsprozessen anderer (Web-) Anwendungen Der RUP ist ein komponenten-basierter Entwicklungsprozess. Ziel des RUP ist es, wiederverwendbare Komponenten zu entwickeln. Jedoch wird die Entwicklung wiederverwendbarer Komponenten nicht durch den Prozess selbst, sondern durch die verwendeten objektorientierten Methoden erreicht. Auch die Abstimmung mit Entwicklungsprozessen anderer Anwendungen wird im RUP nicht beschrieben. Die Möglichkeit einer strukturierten Abstimmung mit anderen Anwendungen scheint kompliziert, da in Abhängigkeit der Phasen, in welchen sich die Entwicklung der verschiedenen Anwendungen befindet, festzulegen ist, welche Informationen ausgetauscht werden. Hier ergeben sich komplexe Abhängigkeiten, da nicht davon auszugehen ist, dass sich alle Projekte in der gleichen Phase befinden. Insgesamt ist die Unterstützung der Abstimmung mit anderen Entwicklungsprozessen mit dem RUP nur schwer möglich. 6. Anpassung an die Entwicklungsstufe der Web-Anwendung Der RUP ist ein Prozess Framework, welches unterschiedlichen Anwendungen und organisatorischen Anforderungen angepasst werden kann. Somit existieren im RUP verschiedene Konstanten, wie z.b. die vier Phasen und die fünf Workflows als auch verschiedene Faktoren, die variieren können, wie z.b. die Länge einer Phase oder die Anzahl der Iterationen in einer Phase. Das bedeutet, die durch den RUP vorgegebenen Phasen und damit das Ziel, Projektrisiken in den frühen Phasen so weit auszuschließen bzw. zu reduzieren, dass der meiste Entwicklungsaufwand innerhalb eines festen Zeitraumes und zu einem festen Preis realisiert werden kann, können nicht durch eine Anpassung des Prozesses beeinflusst werden. Somit kann der Rational Unified Process durch entsprechende Anpassungen an die späten Entwicklungsstufen einer Web-Anwendung angepasst werden, wenn durch eine steigende Integration in die Geschäftsprozesse des Auftraggebers die Komplexität der Anwendung so groß wird, dass Qualitätsanforderungen stärker berücksichtigt werden müssen. Der RUP kann jedoch nicht so weit angepasst werden, dass er die Anforderungen an Entwicklungsprozesse in den frühen Entwicklungsstufen einer Web-Anwendung erfüllen kann. Die Gründe hierfür

17 Analyse von Extreme Programming (XP) 17 sind in den Punkten eins bis drei dieser Aufzählung genannt, welche vor allem die frühen Entwicklungsstufen einer Web-Anwendung charakterisieren Analyse von Extreme Programming (XP) In diesem Unterkapitel soll die Übertragbarkeit von XP [Beck99, BeFo00] auf die Entwicklung von Web-Anwendungen diskutiert werden. Dazu geben wir zunächst eine kurze Einführung in XP, die für das Verständnis der folgenden Überlegungen notwendig sind. Hierfür konzentrieren wir uns auf den Prozess und lassen die zugrunde liegenden Methoden soweit wie möglich unbeachtet. Danach betrachten wir wiederum die in Unterkapitel 10.3 aufgestellten Anforderungen an den Prozess der Entwicklung von Web-Anwendungen und untersuchen, welche von ihnen XP erfüllen kann Kurze Einführung in XP XP wird hier stellvertretend für leichtgewichtige, iterative Prozesse analysiert. Es wäre auch möglich an dieser Stelle agile Prozesse wie etwa SCRUM [RiJa00, ScBe01] zu betrachten. Unsere Wahl von XP ist lediglich durch dessen größeren Bekanntheitsgrad begründet. Die Unterschiede zwischen agilen Prozessen wie SCRUM und XP liegen in unseren Augen eher auf der methodischen Ebene, die im Rahmen dieses Kapitels nicht betrachtet werden, als auf der Ebene des Prozesses. Eine Besonderheit von SCRUM, die uns für XP nicht bekannt ist, ist die Diskussion des Umganges mit mehreren verwandten bzw. besonders großen Projekten. Daher werden wir darauf am Ende dieses Abschnittes eingehen. Bei der Einführung in XP wird im Allgemeinen nicht zwischen Prozess und Methoden unterschieden. Stattdessen werden stets die vier prägenden Werte Kommunikation, Einfachheit, Feedback und Mut sowie zwölf Merkmale bzw. Techniken von XP Projekten erläutert. Die vier Werte stellen die tragenden Säulen eines XP Projektes dar. Ihr Verständnis erscheint uns unerlässlich. Was die Merkmale und Techniken angeht, wollen wir uns hier jedoch auf den einem XP Projekt zugrunde liegenden Prozess konzentrieren und werden nur diejenigen Merkmale von XP erläutern, die den Prozess beeinflussen. Methodische Aspekte klammern wir dabei soweit wie möglich aus. Für eine komplette Einführung verweisen wir auf [Beck99]. Das Prinzip der Kommunikation stellt den persönlichen Austausch zwischen den Projektbeteiligten über jede Art von schriftlichem Dokument. Dies gilt sowohl für den Kontakt zwischen Auftraggeber und Entwickler als auch für den Kontakt der Entwickler untereinander. Das Prinzip der Einfachheit basiert auf der These, dass man am meisten erreicht und das auch noch mit dem geringsten Risiko, wenn man den nächsten Schritt so einfach wie möglich gestaltet. Daher wird in einem XP Projekt wiederholt nach der einfachsten Lösung gesucht und Komplexität gemieden. Man löst

18 Analyse von Extreme Programming (XP) 18 immer nur das dringendste Problem und verschiebt andere mit niedrigerer Priorität in die Zukunft. Langfristige Visionen werden ignoriert. Stattdessen wird praktisch nutzbares ausgeliefert und das sofort. Aufgabe des Prinzips (wechselseitiges) Feedback ist es dafür zu sorgen, dass die Entwickler den Grad der Zufriedenheit des Kunden mit dem gegenwärtig ausgelieferten Produkt kennen und dass der Auftraggeber die Folgen einer Entscheidung für eine bestimmte Weiterentwicklung absehen kann. Das letzte Prinzip von XP ist mit Mut (engl. courage) nur sehr unzureichend übersetzt. Engagement und Tatendrang sind hier ebenso gemeint. Ohne großartige Planung und Absicherung einfach etwas zu tun erfordert Mut. Dieses Prinzip fordert dazu auf, Dinge einfach anzupacken und erst nach einer gewissen Zeit dann wieder auf ihren Erfolg hin zu überprüfen. Mit diesem Grundverständnis der Werte von XP wollen wir jetzt mit der Beschreibung des zugrundeliegendes Prozesses beginnen. Bei einem XP Projekt wird der Projektablauf durch das Erstellen von Releases gegliedert. Ein solches Release zu erstellen dauert lediglich ein paar Monate. Diese schnell aufeinander folgenden Releases sind bereits das erste Merkmal von XP. Die Erstellung eines Release beginnt mit der Release Planung. Die eigentliche Entwicklung erfolgt dann in mehreren aufeinander folgenden Iterationen. Änderungen der Anforderungen bzw. neu hinzukommende Anforderungen können jederzeit zu einer erneuten Release Planung führen. Ein erfolgreich absolvierter Akzeptanztest führt zur Auslieferung des Releases. Dieser grobe Ablauf eines XP Projektes wird in Abb visualisiert. Die Iterationen, in denen die eigentliche Entwicklung stattfindet, beginnen jeweils auch wieder mit einer Iterationsplanung. Iterationen dauern in der Regel zwei Wochen. Länger als vier Wochen sollten sie auf keinen Fall sein. Sowohl die Releaseplanung als auch die Iterationsplanung wird als eine gemeinsame Aufgabe von Entwicklern und Auftraggeber angesehen. Die dabei angewandte Technik wird als Planungsspiel bezeichnet. Aufgabe des Auftraggebers im Rahmen der Planung ist die Priorisierung möglicher Weiterentwicklungen. Aufgabe der Entwickler ist die Schätzung von deren Aufwand, um damit eine Grundlage für die Priorisierung zu schaffen. [geänderte Anforderung/ neue Anforderung] [nächste Iteration] Release Release Planung Planung Iteration Iteration [Alle Akzeptanztests erfolgreich] Veröffentlichung Veröffentlichung [Projektende] [sonst] Abb. 10-1: Ablauf eines XP Projektes als Folge von Releases

19 Analyse von Extreme Programming (XP) 19 <Abb_10_1.ppt> Der Ablauf einer Iteration ist in Abb schematisch dargestellt. Nach der Iterationsplanung bilden die Entwickler Paare, die für den Ablauf dieser Iteration zusammenarbeiten sollen. In der nächsten Iteration werden die Paare dann anders zusammengestellt. Auf diese Art und Weise wird das Prinzip der Kommunikation im Prozess verankert und Wissen über das Team verteilt. Für die eigentliche Entwicklung hat jedes Paar eine Aufgabe zugewiesen bekommen. Die Bearbeitung einer Aufgabe beginnt das Paar stets mit dem Schreiben eines Unit Testes. Dieser Test formalisiert die Anforderungen. Erst wenn er fehlschlägt, wird mit der eigentlichen Entwicklung begonnen. Dieses Vorgehen entspricht dem Merkmal vorausgehender Tests von XP und erstreckt sich ebenso auf die Akzeptanztest, die zu Beginn der Arbeit an einer Release erstellt werden. Die Zusammenarbeit der Paare heißt, dass die Entwickler paarweise vor einem Rechner sitzen und den Programmcode entwickeln. Dies ist das wohl bekannteste Merkmal des XP, die Programmierung in Paaren. Es basiert auf der These, dass zwei mehr sehen als einer und gemeinsam bessere Ideen entwickeln können als einer allein das könnte. Durch die dadurch erzielte Qualitätssteigerung wird der Mehraufwand wieder ausgeglichen. Ein Paar hat seine Aufgabe beendet, wenn der zu Anfang ihrer Arbeit geschriebene Unit Test erfolgreich verläuft. Zum Abschluss nimmt das Paar sofort die Integration seines Arbeitsergebnisses in das Gesamtprojekt vor. Bei der so entstehenden fortlaufenden Integration handelt es sich auch um ein Merkmal von XP. Es sorgt dafür, dass der Arbeitsfortschritt für das gesamte Team immer deutlich sichtbar ist. Eine Voraussetzung dafür, dass die fortlaufende Integration überhaupt machbar ist, stellt das Merkmal der gemeinsamen Verantwortung für den Code dar. Jedes Paar darf Code auch dann ändern, wenn er von einem anderen Paar entwickelt wurde. Durch die vorhandenen Unit Tests ist sichergestellt, dass Änderungen nicht zu unerklärlichen neuen Fehlern führen. Zum Abschluss dieses Abschnittes soll der Prozess der Durchführung mehrerer verwandter Projekte bzw. eines großen Projektes mit Hilfe des agilen Prozesses SCRUM [ScBe01] dargestellt werden, da uns entsprechende Aussagen für XP nicht bekannt sind. Die wesentliche Aussage zur Durchführung mehrerer verwandter Projekte ist die, niemals mehrere Projekte zum gleichen Zeitpunkt zu starten. Man startet also immer mit der Durchführung von zunächst einem Projekt. Für dieses Projekt hat seine rechtzeitige und ordnungsgemäße Abwicklung oberste Priorität. Für die Wiederverwendbarkeit einzelner Komponenten wird als methodischer Ansatz die Entwicklung einer Schichtenarchitektur empfohlen. Ansonsten verlässt man sich auf die Möglichkeiten des Refactorings und empfiehlt (wie auch XP) wenig bis keine Ressourcen in das Vorhersehen von möglicherweise Nützlichem zu investieren.

20 Analyse von Extreme Programming (XP) 20 Kommt dann zu einem späteren Zeitpunkt die Entwicklung einer weiteren, verwandten Anwendung hinzu, so wird dies durch die Auslagerung gemeinsam genutzter Komponenten vorbereitet. Für die Wartung und Weiterentwicklung dieser Komponenten wird ein eigenes Team eingesetzt. Regelmäßige Treffen (mindestens einmal pro Woche) zwischen den Managern der einzelnen Teams, Scrum Master genannt, sind vorgesehen. Diese Treffen werden als»scrum of Scrums«bezeichnet. Für die Durchführung größerer Projekte wird im wesentlichen eine ähnliche Vorgehensweise wie bei mehreren verwandten Projekten empfohlen. Dies setzt die Aufteilung des größeren Projektes auf mehrere kleine Teilprojekte voraus. Auch hier sollte Kernfunktionalität für die Entwicklung in einem Pilotprojekt ausgewählt werden und keinesfalls mit mehreren Teilprojekten gleichzeitig begonnen werden.

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

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

Ü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

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

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

Mehr

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

Kapitel 2: Der Software-Entwicklungsprozess

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

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

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

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

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

- 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

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

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

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

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

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

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

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

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

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

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

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

6 Zusammenfassende Bewertung und Ausblick

6 Zusammenfassende Bewertung und Ausblick 437 6 Zusammenfassende Bewertung und Ausblick Immer wieder scheitern Projekte zur Software-Gestaltung im Öffentlichen Dienst bzw. sie laufen nicht wie geplant ab. Dies ist für sich genommen nicht weiter

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Lösungen zum Test objektorientierter Software

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

Mehr

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

Effizientes Änderungsmanagement in Outsourcing- Projekten

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

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

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

Mehr

Extremes Programmieren

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

Mehr

Software Engineering

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

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

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

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

Mehr

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

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

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

Mehr

Informationswirtschaft II

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

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

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

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

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

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz ISIS Das Navigationssystem für angemessene Qualität und hohe Effizienz Inhalt Softwarequalität und Prozessqualität ISIS: das Ziel Messen der Prozessqualität Der Werkzeugzoo Die Wirkung Maßnahmen zur Prozessoptimierung

Mehr

Einführung in die Informatik

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

Mehr

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

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

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

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems

Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems Aspekte zur Vorgehensweise bei Planung & Einführung eines SDM-Systems Martin Liebscher DYNAmore GmbH Stuttgart, 2. Juli 2013 1 Überblick Phasen der Softwareentwicklung / -beschaffung Anforderungsanalyse

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

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

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

Mehr

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

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

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:

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte

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

Mehr

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

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

Anforderungen und Auswahlkriterien für Projektmanagement-Software Anforderungen und Auswahlkriterien für Projektmanagement-Software Anika Gobert 1,Patrick Keil 2,Veronika Langlotz 1 1 Projektmanagement Payment Giesecke &Devrient GmbH Prinzregentenstr. 159, Postfach 800729,

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

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

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

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

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Konsolidierung und Neuimplementierung von VIT Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Inhaltsverzeichnis 1 Was ist der Kontext?... 1 2 VIT: Ein sehr erfolgreiches

Mehr

RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen

RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen Thorsten Keuler (thorsten.keuler@iese.fraunhofer.de) IESE Fraunhofer Institut Experimentelles Software

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

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

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Individuelle Software für Ihr Unternehmen

Individuelle Software für Ihr Unternehmen Individuelle Software für Ihr Unternehmen Maßgeschneidert passt besser logisch, werden Sie sagen und an einen auf den Leib geschneiderten Anzug denken. Aber haben Sie sich schon einmal überlegt, wie gut

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

PQ4Agile Agiler Referenzprozess

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

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle)

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap 8.1 http://homepages.cs.ncl.ac.uk/brian.randell/nato/ The first International Conference

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

1 Software Projektplanung

1 Software Projektplanung 1 Software Projektplanung Zu Beginn wird von dem Projektleiter (Projektverantwortlicher) ein Projektplan erstellt. In dieser ersten Version des Projektplans müssen alle Aktivitäten enthalten, sowie gewisse

Mehr

Ablauf der Vorstudie zu einem Projekt

Ablauf der Vorstudie zu einem Projekt Ablauf der Vorstudie zu einem Projekt DHPol Seminar 2011 Dipl.-Ing. Thomas Schlüter, MBA Projektdefinition Vorstudie Internet: www.korff-schlueter.de, E-Mail: info@korff-schlueter.de 1 von 22 Projektplanung

Mehr

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

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

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

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

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

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

Evolutionäres Phasenmodell. Vorgehensmodelle

Evolutionäres Phasenmodell. Vorgehensmodelle Evolutionäres Phasenmodell Vorgehensmodelle PM 1 Die Phase Projektinitialisierung wird in enger Zusammenarbeit zwischen Projektauftraggeber und Auftragnehmer durchgeführt. Die Informationen aus dem Projektportfolio,

Mehr

Kapitel 1 Software-Prozessmodelle

Kapitel 1 Software-Prozessmodelle Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr