Was ist unter eXtreme Programming zu verstehen? Springen dabei Entwickler mit hängenden Augenringen, ohne soziale Kontakte und einem Laptop vor den Bauch geschnallt Bungee? Oder handelt es sich beim XP um „hacking-as-usual“, ein fröhliches Cowboy-Hacking schick verpackt hinter einem provokanten, avantgardistisch anmutenden Terminus?
Die Antwort ist einfach – die Antwort ist: Nein. XP ist ein strenges, sehr viel Disziplin erforderndes Vorgehensmodell für die Softwareentwicklung, was durch aktuelle Probleme im Bereich der Softwareentwicklung motiviert frischen Wind in die Diskussion über den grundsätzlichen Ablauf eines Entwurfsprozesses bringen konnte.
Keine Frage – XP ist anders. Das X aber steht nicht etwa für eXtremes Verhalten oder eXtremes Loslassen vom Herkömmlichen. Es steht auch nicht für eXtremes Risiko oder eXtremen Erfolg. Das X steht für die eXtreme Intensität, die dieses Verfahren von seinen Partizipanten verlangt, eXtreme Identifikation mit den Werten und ein möglichst eXtremes Umsetzen der operativen, durch das XP geforderten Instrumente. EXtrem bezieht sich auf Disziplin und fordert Teamfähigkeit und Kompetenz – viel mehr als der Titel auf den ersten Blick zu suggerieren vermag.
Was genau man hinter XP zu verstehen hat und wo genau dessen Einflüsse auf die Qualität vom Endprodukt – der Software – vermutet werden können, das ist Aufgabe und primäres Ziel dieser Auseinandersetzung. Dem Leser soll bewusst werden, wo sowohl die Befürworter als auch die Widersacher des XPs argumentativ ansetzen, wenn es um die Verteidigung respektive dem Angriff von bzw. gegen XP geht. Es liegt hierbei sicherlich keine vollständige Abhandlung über XP vor; das meiner Meinung nach Wichtigste wird hier erörtert.
Um darüber hinaus das XP in die Welt der Softwarequalitätsbegriffe einordnen zu können, wird die Arbeit durch hinreichende Informationen zu diesem Thema mit einer strikten Hinführung zum XP begonnen.
Für wen leistet XP welchen Beitrag bezüglich der Qualität eines Softwareproduktes und wie verspricht es, dieses zu gewährleisten? Ziel der Abhandlung ist es, hierfür eine plausible Antwort zu finden.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
I) Einleitung
I.1) Problemstellung
I.2) Gang der Untersuchung
I.3) Anmerkungen zur Literatur
II) Software-Qualitätsbegriffe im Kontext der Arbeit
II.1) Qualität und Qualitätsmerkmale
II.2) Prozesse
II.2.1) Herkömmliche Verfahren
II.2.2) Agile Methoden
III) Extreme Programming
III.1) Grundlagen
III.1.1) Rollen in einem XP-Projekt
III.1.2) Werte
III.2) Überblick über die Techniken des XPs
III.2.1) Programmiertechniken
III.2.1.1) Einfaches Design
III.2.1.2) Refactoring
III.2.2) Interaktionstechniken
III.2.2.1) Testen
III.2.2.2) Programmieren in Paaren
III.2.2.3) Gemeinsame Verantwortung und Programmierstandards
III.2.2.3) Fortlaufende Integration
III.2.3) Integrations-Techniken
III.2.3.1) Kunde vor Ort
III.2.3.2) Planungsspiel
III.2.3.3) Metapher
III.2.3.4) 40-Stunden-Woche
III.2.3.5) Kurze Releasezyklen
IV) Kritische Auseinandersetzung mit XP
IV.1) Erfahrungen mit XP
IV.2) Kritik an XP
IV.3) Anwendbarkeit und Zukunft von XP
V) Schlussbemerkung
Anhang
A.1) Literaturverzeichnis
A.2) Principles behind the Agile Manifesto
A.3) Quantitative Survey on Extreme Programming Projects
Abbildungsverzeichnis
Abb. 2.1: Zufriedenheitshypothese
Abb. 3.1: Cost-Of-Change-Kurve traditionellerVorgehensmodelle
Abb. 3.2: Cost-Of-Change-Kurve beim XP
Abb. 3.3: Bewertung einzelner Techniken
Abb. 3.4: 1:n – Beziehung zwischen Releases und Iterationen
Abb. 4.1: Einsatz der einzelnen Techniken
Abb. 4.2: Anwendbarkeit von XP
Tabellenverzeichnis
Tab. 2.1: Wechselwirkungen ausgewählter Qualitätsmerkmale
Tab. 3.1: Überblick über die Techniken
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
I) Einleitung
I.1) Problemstellung
Was ist unter eXtreme Programming zu verstehen? Springen dabei Entwickler mit hängenden Augenringen, ohne soziale Kontakte und einem Laptop vor den Bauch geschnallt Bungee? Oder handelt es sich beim XP um „hacking-as-usual“, ein fröhliches Cowboy-Hacking schick verpackt hinter einem provokanten, avantgardistisch anmutenden Terminus?
Die Antwort ist einfach – die Antwort ist Nein. XP ist ein strenges, sehr viel Disziplin erforderndes Vorgehensmodell für die Softwareentwicklung, was durch aktuelle Probleme im Bereich der Softwareentwicklung motiviert frischen Wind in die Diskussion über den grundsätzlichen Ablauf eines Entwurfsprozesses bringen konnte.
Keine Frage – XP ist anders. Das X aber steht nicht etwa für eXtremes Verhalten oder eXtremes Loslassen vom Herkömmlichen. Es steht auch nicht für eXtremes Risiko oder eXtremen Erfolg. Das X steht für die eXtreme Intensität, die dieses Verfahren von seinen Partizipanten verlangt, eXtreme Identifikation mit den Werten und ein möglichst eXtremes Umsetzen der operativen, durch das XP geforderten Instrumente. EXtrem bezieht sich auf Disziplin und fordert Teamfähigkeit und Kompetenz – viel mehr als der Titel auf den ersten Blick zu suggerieren vermag.
Was genau man hinter XP zu verstehen hat und wo genau dessen Einflüsse auf die Qualität vom Endprodukt – der Software – vermutet werden können, das ist Aufgabe und primäres Ziel dieser Auseinandersetzung. Dem Leser soll bewusst werden, wo sowohl die Befürworter als auch die Widersacher des XPs argumentativ ansetzen, wenn es um die Verteidigung respektive dem Angriff von bzw. gegen XP geht. Es liegt hierbei sicherlich keine vollständige Abhandlung über XP vor; das meiner Meinung nach Wichtigste wird hier erörtert.
Um darüber hinaus das XP in die Welt der Softwarequalitätsbegriffe einordnen zu können, wird die Arbeit durch hinreichende Informationen zu diesem Thema mit einer strikten Hinführung zum XP begonnen.
Für wen leistet XP welchen Beitrag bezüglich der Qualität eines Softwareproduktes und wie verspricht es, dieses zu gewährleisten? Ziel der Abhandlung ist es, hierfür eine plausible Antwort zu finden.
I.2) Gang der Untersuchung
Für die Antwort auf diese Leitfrage sind drei Schwerpunkte vorgesehen.
Im nachfolgenden Kap. II soll XP in den Kontext der Software-Qualität eingeordnet und dadurch ein Wissensfundament erzeugt, das ausreicht, um die einzelnen Argumentationen für oder gegen XP nachvollziehen zu können. Dabei wird nach einer grundsätzlichen Definition von Qualität auf Qualitätsmerkmale eingegangen. Deren Ausprägungen können als möglicher Indikator für bzw. gegen Qualität dienen. Zuletzt wird XP in die Welt der Vorgehensmodelle eingeordnet, um auch zwischen den Alternativen argumentieren zu können.
Das Kap. III stellt den Kern der Ausarbeitung dar und erläutert XP, seine Werte und seine Techniken. Da es aus Redundanzgründen müßig wäre, getrennt einen Abschnitt für die qualitative Bewertung vor allem der Techniken zu öffnen, wird immer unmittelbar Bezug zum Qualitätsbeitrag – je nachdem in welchem Maße ein solcher Sinn macht – hergestellt.
Den dritten Schwerpunkt bildet das Kap IV - eine kritische Auseinandersetzung mit XP. Dabei werden Argumente für und gegen XP vorgetragen und soweit es nötig ist auch kommentiert. Abschließend werden die Anwendbarkeit auch in Hinsicht auf Alternative Vorgehensmodelle und das zukünftige Potenzial von XP kurz durchleuchtet.
In einem kurzen Fazit (Kap. V) wird dann zusammenfassend resümiert. Dabei soll abschließend auch versucht werden, eine sinnvoll hergeleitete Antwort auf die Leitfrage zu finden.
I.3) Anmerkungen zur Literatur
Doch bevor es nun losgeht noch ein paar Bemerkungen zu evtl. hilfreicher Sekundärliteratur.
An Material für diese Ausarbeitung wurden Quellen verschiedenster Art identifiziert. Darunter sind sowohl Bücher (deutsch wie englisch) als auch eine Studie, veröffentlichte Artikel wie auch Vorlesungsunterlagen und einfache Artikel auf Internetseiten. Im Literaturverzeichnis (A1) können die im Internet verfügbaren Quellen direkt über den angegebenen Link nachgeschlagen werden. Alle Internetreferenzen sind zudem mit vielen anderen Materialien auf der beiliegenden CD Offline verfügbar.
Ein besonderes Augenmerk wurde auf das Buch von LIPPERT, ROOCK und HENNING gelegt. Hier werden die Grundlagen des XPs anhand praktischer Erfahrungen dargestellt.
Einen besonderen Schmankerl über die Wirkung und die Akzeptanz von XP findet sich dann in der durch RUMPE und SCHRÖDER veröffentlichten und frei verfügbaren Studie, an der 47 Unternehmen aus der ganzen Welt, die Erfahrungen mit XP gesammelt haben, teilgenommen haben. Leider ist die Studie von 2001 und damit an Aktualität überholt. Aber grundsätzliche Aussagen und Tendenzen gerade in Hinblick auf die von den Befragten empfundene Qualität und den Einsatz von XP lassen sich hier ablesen. Diese Studie ist in den Anhang A2 gestellt.
II) Software-Qualitätsbegriffe im Kontext der Arbeit
II.1) Qualität und Qualitätsmerkmale
Qualität ist ein weitgreifender Begriff, der allgemein nach der DIN 55350-11 als „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse […] zu erfüllen“[1] verstanden wird. Somit steht die Beziehung zwischen realisierter Beschaffenheit und den einzelnen Anforderungen, den so genannten Qualitätsanforderungen, im Mittelpunkt aller die Qualität betreffenden Überlegungen.
Abbildung in dieser Leseprobe nicht enthalten
WALLMÜLLER konstatiert bei dieser Betrachtung, dass gerade im Kontext des in dieser Ausarbeitung interessierenden Bereiches der Softwareentwicklung bzw. -produkte „Die Eignung ein und derselben Sache […] für verschiedene Verwendungen unterschiedlich sein“[2] kann. Umfangreiche Produkte bzw. Systeme, die in komplexen Situationen allen Qualitätsanforderungen genügt, können in anderen weniger komplexen Situationen ungeeignet wirken. So mag SAP zwar allen (betriebswirtschaftlichen) Anforderungen eines Fünf-Mann-Unternehmens entsprechen, aber wegen der unnötigen Komplexität einfach nicht für einen effektiven Einsatz zweckdienlich sein.
Zur Bewertung der Qualität eines Betrachtungsgegenstandes werden Qualitätsmerkmale herangezogen. Diese beschreiben „Eigenschaften einer Funktionseinheit […], anhand derer ihre Qualität beschrieben und beurteilt“[3] werden kann. Im Bereich der Softwareentwicklung[4] zählen hierzu unter anderem Sicherheit, Funktionalität, Integrität bzw. Korrektheit, Zuverlässigkeit, Verfügbarkeit, Robustheit, Speicher- und Laufzeiteffizienz, sowie Änder- und Erweiterbarkeit, Portabilität, Wartbarkeit, Prüfbarkeit, Adäquatheit und letzten Endes auch die Benutzbarkeit bzw. Erlernbarkeit einer Software[5]. In bestimmten Fällen ist auch die Interoperabilität bzw. Kompatibilität zu anderen Systemen von entscheidender Bedeutung. HÄRTL klassifiziert die aus seiner Sicht wichtigsten Merkmale in drei Kategorien: Die Gebrauchstauglichkeit (Usability) stellt die direkte Benutzersicht dar und umfasst Funktionalität, Zuverlässigkeit, Integrität, Korrektheit, Benutzerfreundlichkeit, Robustheit und Effizienz einer Software. Die zweite Gruppe umfassen die Merkmale zur Revisionsfähigkeit einer Software. Dazu zählen die Änderbarkeit, die Erweiterbarkeit und die Ausbaufähigkeit, die Wartbarkeit und die Überprüfbarkeit bzw. die Verifizierbarkeit. Zu guter Letzt wird die Transitionsfähigkeit genannt. Diese beschreibt Merkmale, die ein Produkt oder Produktteile insgesamt auch noch anderweitig nutzbar machen. Dieses wird durch ein hohes Maß an Portabilität, Wiederverwendbarkeit und auch Interoperationalität bzw. Kompatibilität gefördert[6]. Während die Gebrauchstauglichkeit vor allem die kurzfristige Kundenzufriedenheit beeinflusst, befrieden Revisions- und Transitionsaspekte stärker die strategischen und damit langfristigeren Ansprüche des Kunden bzw. der Entwickler (Abb. 2.1).
Abbildung in dieser Leseprobe nicht enthalten
Häufig bewirkt die Verbesserung der Qualität hinsichtlich eines Merkmals die Verschlechterung eines anderen. POMBERGER und BLASCHEK liefern eine solche Gegenüberstellung dieser Wechselwirkungen in Hinsicht auf eine eigene Merkmalsselektion (s. Tab. 2.1).
[...]
[1] Liggesmeyer, Peter: Software-Qualität, Berlin, 2002, S. 5
[2] Wallmüller, Ernest: Software-Qualitätsmanagement, München, 2001, S. 12
[3] Liggesmeyer, Peter: Software-Qualität, Berlin, 2002, S. 5
[4] Pomberger, Gustav/Blaschek, Günther: Software Engineering, S.14
[5] vgl. Liggesmeyer, Peter: Software-Qualität, Berlin, 2002, S. 6ff
[6] vgl Härtl, Hartmut: Software Engineering – Softwarequalität, o.O., o.D.
-
-
-
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.