WWW.ABSTRACT.XLIBX.INFO
FREE ELECTRONIC LIBRARY - Abstract, dissertation, book
 
<< HOME
CONTACTS



Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |

«Software Engineering Ian Sommerville Software Engineering 9., aktualisierte Auflage Higher Education München • Harlow • Amsterdam • Madrid • ...»

-- [ Page 3 ] --

3.3 Extreme Programming Extreme Programming (XP) ist wahrscheinlich die bekannteste und am häufigsten verwendete agile Methode. Die Bezeichnung wurde von Beck geprägt (Beck, 2000), da dieser Ansatz dadurch entwickelt wurde, bekannte gute Praktiken wie iterative Entwicklung „ins Extreme“ zu steigern. Zum Beispiel könnten in XP mehrere neue Versionen eines Systems an einem Tag von verschiedenen Programmieren entwickelt, integriert und getestet werden.

Beim Extreme Programming werden Anforderungen in Form von Szenarios ausgedrückt, die User-Storys genannt werden. Diese Szenarios werden direkt in Form einer Abfolge von Aufgaben implementiert. Die Programmierer arbeiten paarweise zusammen, um Tests für die einzelnen Aufgaben zu entwickeln, bevor sie Code schreiben.

Alle Tests müssen erfolgreich ausgeführt werden, wenn neuer Code in das System integriert wird. Zwischen den einzelnen Releases des Systems vergeht nur wenig Zeit.

 Abbildung 3.3 veranschaulicht den XP-Prozess für ein Inkrement eines zu entwickelnden Systems.

–  –  –

Abbildung 3.3: Der Releasezyklus des Extreme Programming.

Extreme Programming umfasst eine Reihe von Vorgehensweisen, welche die Prinzipien

agiler Methoden widerspiegeln (eine Zusammenfassung finden Sie in  Abbildung 3.4):

1 Die inkrementelle Entwicklung wird durch kleine, häufige Releases des Systems erreicht. Anforderungen beruhen auf einfachen Kundenerzählungen bzw. Szenarios, die als Grundlage zur Entscheidung benutzt werden, welche Funktionalität in einem Systeminkrement aufgenommen werden sollte.

2 Die Einbeziehung des Kunden wird durch die kontinuierliche Teilnahme eines Kundenbevollmächtigten an der Entwicklung erreicht. Er ist dafür verantwortlich, Akzeptanztests für das System zu definieren.

3 Durch Paarprogrammierung (oder Pair Programming), kollektives Eigentum am Systemcode und einen geeigneten Entwicklungsprozess, bei dem es keine extrem langen Arbeitszeiten gibt, werden Menschen statt Prozesse in den Vordergrund gerückt.

4 Änderungen werden durch regelmäßige Systemreleases an die Kunden, TestFirst-Entwicklung, Refactoring zur Vermeidung von Codedegeneration und stetige Integration von neuen Funktionalitäten eingebunden.

5 Der Erhalt der Einfachheit wird durch ständiges Refactoring zur Verbesserung der Codequalität und die Verwendung einfacher Entwürfe erreicht, die zukünftigen Änderungen am System nicht unnötig vorgreifen.

–  –  –

Bei einem XP-Prozess sind die Kunden unmittelbar daran beteiligt, die Systemanforderungen zu spezifizieren und Prioritäten festzulegen. Die Anforderungen werden nicht in Form einer Liste der erforderlichen Systemfunktionen aufgestellt. Stattdessen ist der Kunde Mitglied des Entwicklerteams und bespricht Szenarios mit den anderen Teammitgliedern. Zusammen entwickeln sie eine Story-Card, die die Bedürfnisse des Kunden beschreibt. Das Entwicklerteam macht sich dann daran, das Szenario für das nächste Release der Software zu entwickeln. Ein Beispiel für eine Story-Card für das Patienteninformationssystem in der psychiatrischen Ambulanz finden Sie in Abbildung 3.5. Dies ist eine kurze Beschreibung eines Szenarios zur Verschreibung von Medikamenten für einen Patienten.

–  –  –

Verschreiben von Medikamenten Dr. Seifert ist eine Ärztin, die einem der Patienten aus der Sprechstunde Medikamente verschreiben möchte. Die Patientenakte wird bereits auf dem Bildschirm ihres Computers angezeigt. Sie klickt auf das Feld „Medikation” und kann nun wählen zwischen „Aktuelle Medikation”, „Neue Medikation” und „Arzneimittelliste”.

Wenn sie „Aktuelle Medikation” auswählt, wird sie vom System aufgefordert, die Dosierung zu überprüfen. Falls diese geändert werden soll, dann gibt sie die Dosis ein und bestätigt danach die Verschreibung.

Wenn sie „Neue Medikation” gewählt hat, setzt das System voraus, dass sie weiß, welches Medikament sie verschreiben möchte. Sie gibt die ersten Buchstaben des Arzneimittels ein. Das System zeigt eine Liste der Medikamente an, die mit diesen Buchstaben beginnen. Sie wählt das gewünschte Mittel aus und das System fragt ab, ob die gewählte Medikation korrekt ist. Sie gibt die Dosierung ein und bestätigt die Verschreibung.

Wenn sie „Arzneimittelliste” ausgewählt hat, dann zeigt das System ein Suchfeld mit den zugelassenen Medikamenten an. Sie kann dann nach dem gewünschten Mittel suchen. Sie wählt ein Medikament aus und wird aufgefordert, dieses noch einmal zu überprüfen. Sie gibt die Dosierung ein und bestätigt dann die Verschreibung.

Das System überprüft immer, ob die Dosierung innerhalb der bekannten Grenzwerte liegt. Falls dies nicht zutrifft, wird Dr. Seifert aufgefordert, die Dosis zu ändern.

Nachdem Dr. Seifert die Verschreibung bestätigt hat, wird diese noch einmal zur Überprüfung angezeigt. Sie klickt entweder auf „OK” oder auf „Ändern”. Wenn sie auf „OK” klickt, dann wird die Verschreibung in der Auditdatenbank aufgezeichnet. Mit dem Klick auf „Ändern” betritt sie erneut den Prozess „Verschreiben von Medikamenten”.

Abbildung 3.5: Eine Story zur Medikamentenverschreibung.

Die Story-Cards sind die Hauptvorgaben für den XP-Planungsprozess oder das „Planungsspiel“. Nachdem die Story-Cards fertiggestellt sind, teilt das Entwicklerteam sie in Aufgaben (task) auf (Abbildung 3.6) und schätzt den erforderlichen Aufwand und die Ressourcen für die Implementierung jeder einzelnen Aufgabe ab. Hierzu sind gewöhnlich Gespräche mit dem Kunden nötig, um die Anforderungen zu verfeinern.





Der Kunde vergibt dann Prioritäten für die Implementierung der User-Storys, wobei er die User-Storys auswählt, die sofort verwendet werden können, um sinnvolle Geschäftsfunktionen zu bieten. Die Absicht hierbei ist, nützliche Funktionalität zu identifizieren, die in ungefähr zwei Wochen implementiert werden kann, wenn das nächste Systemrelease dem Kunden zur Verfügung gestellt wird.

Wenn sich natürlich die Anforderungen ändern, können noch nicht implementierte User-Storys ebenfalls geändert oder verworfen werden. Wenn Änderungen an einem bereits ausgelieferten System erforderlich sind, werden neue Story-Cards geschrieben.

Auch hier entscheidet der Kunde, ob diese Änderungen Priorität gegenüber neuer Funktionalität haben sollen.

Abbildung 3.6: Beispiele für Aufgabenkarten für das Verschreiben von Medikamenten.

Manchmal tauchen während des Planungsspiels (planning game) Fragen auf, die nicht einfach beantwortet werden können, sodass zusätzlicher Aufwand erforderlich ist, um nach möglichen Lösungen zu suchen. Das Team wird dann eventuell einen Prototyp entwickeln oder eine Probeentwicklung ausführen, um das Problem und die Lösung zu verstehen. In XP-Sprache ist dies ein „Spike“ – eine Entwicklungsphase, in der keine Programmierung stattfindet. Es gibt möglicherweise auch „Spikes“ beim Entwurf der Systemarchitektur oder bei der Herstellung der Systemdokumentation.

Extreme Programming verfolgt einen „extremen“ Ansatz der inkrementellen Entwicklung. Neue Versionen der Software können mehrmals am Tag erstellt werden und Releases werden ungefähr alle zwei Wochen an den Kunden ausgeliefert. Die Abgabetermine für Releases werden niemals verpasst; falls es Entwicklungsprobleme gibt, wird der Kunde hinzugezogen und das geplante Release wird um einige Funktionen gekürzt.

Wenn ein Programmierer eine neue Version des Systems erstellt, muss er alle bestehenden automatisierten Tests sowie die Tests für die neue Funktionalität durchführen.

Die neue Version der Software wird nur akzeptiert, wenn alle Tests erfolgreich durchgeführt wurden. Diese wird dann die Basis der nächsten Systemiteration.

Eine Grundregel des herkömmlichen Software-Engineerings besteht darin, den Entwurf auf Änderungen auszurichten. Das bedeutet, zukünftige Änderungen an der Software und dem Entwurf vorauszusehen, sodass sie einfach implementiert werden können.

Beim Extreme Programming wurden dieses Prinzip jedoch über Bord geworfen, da ein auf Änderungen ausgerichteter Entwurf häufig einen unnötigen Aufwand darstellt. Es ist wenig sinnvoll, sich Zeit zu nehmen, einem Programm Allgemeingültigkeit hinzuzufügen, um erfolgreich mit Änderungen umzugehen. Die vorausgesehenen Änderungen treten häufig gar nicht ein. Stattdessen müssen völlig andere Änderungen vorgenommen werden. Der XP-Ansatz akzeptiert die Tatsache, dass Änderungen eintreten werden und die Software neu organisiert werden muss, wenn diese Änderungen auch tatsächlich eingetreten sind.

3.3 Extreme Programming

Ein allgemeines Problem mit inkrementeller Entwicklung ist, dass sie die Strukturierung der Software schwächen, sodass sich die Änderungen immer schwerer umsetzen lassen. Im Wesentlichen geht der Entwicklungsprozess weiter, indem provisorische Lösungen für Probleme gefunden werden – mit dem Ergebnis, dass Code häufig dupliziert wird, Teile der Software auf ungeeignete Weise wiederbenutzt werden und die Gesamtstruktur geschwächt wird, wenn Code dem System hinzugefügt wird.

Beim Extreme Programming wird diesem Problem dadurch begegnet, dass die Software ständig einem Refactoring unterzogen wird. Das bedeutet, dass das Programmierteam nach möglichen Verbesserungen der Software Ausschau hält und sie sofort implementiert. Wenn ein Teammitglied verbesserungswürdigen Code entdeckt, dann wird diese Verbesserung sofort ausgeführt – selbst in Situationen, in denen es nicht unmittelbar notwendig ist. Beispiele für Refactoring umfassen die Neuorganisation einer Klassenhierarchie zum Entfernen von doppeltem Code, das Aufräumen und Umbenennen von Attributen und Methoden und die Ersetzung von Code mit Methodenaufrufen, die in einer Programmbibliothek definiert sind. Entwicklungsumgebungen wie Eclipse (Carlson, 2005) enthalten Werkzeuge zum Refactoring, wodurch der Prozess vereinfacht wird, Abhängigkeiten zwischen Codeabschnitten zu finden und globale Codemodifikationen vorzunehmen.

Im Prinzip sollte die Software dann immer einfach zu verstehen und zu ändern sein, wenn neue User-Storys implementiert werden. In der Praxis ist dies jedoch nicht immer der Fall. Manchmal bedeutet der Entwicklungsdruck, dass Refactoring verspätet stattfindet, weil die Zeit für die Implementierung neuer Funktionalität verwendet wird. Einige neue Merkmale und Änderungen können nicht ohne Weiteres durch Refactoring auf der Codeebene eingebaut werden, sondern erfordern die Modifikation der Systemarchitektur.

In der Praxis benutzen viele Unternehmen, die mit XP arbeiten, nicht alle der XP-Verfahrensweisen, die in Abbildung 3.4 aufgeführt sind. Sie suchen sich die Methoden heraus, die ihrer internen Arbeitsweise am besten entsprechen. Einige Unternehmen halten beispielsweise Paarprogrammierung (pair programming) für hilfreich; andere bevorzugen Einzelprogrammierung und Reviews. Um unterschiedliche Fachkenntnisse innerhalb eines Teams auszugleichen, führen einige Programmierer kein Refactoring in den Teilen des Systems aus, die sie nicht selbst entwickelt haben, und konventionelle Anforderungen könnten anstelle von User-Storys eingesetzt werden. Die meisten Unternehmen, die eine XP-Variante eingesetzt haben, benutzen kleine Releases, Test-First-Entwicklung und kontinuierliche Integration.

3.3.1 Testen in XP Wie in der Einleitung zu diesem Kapitel erwähnt besteht einer der Hauptunterschiede zwischen inkrementeller und planungsgesteuerter Entwicklung in der Art und Weise, wie das System getestet wird. Bei der inkrementellen Entwicklung gibt es keine Systemspezifikation, die von einem externen Testteam für den Entwurf von Systemtests verwendet werden kann. Daher werden bei manchen Ansätzen zur inkrementellen Entwicklung – im Vergleich zum planungsgesteuerten Testen – sehr informelle Testverfahren angewendet.

Um einige der Probleme von Tests und Systemvalidierung zu vermeiden, wird bei XP die Bedeutung der Programmtests hervorgehoben. XP enthält einen Ansatz zum TesAgile Softwareentwicklung ten, der die Wahrscheinlichkeit verringert, dass unentdeckte Fehler in die aktuelle Systemversion eingeführt werden.

Das Testen in XP zeichnet sich durch folgende Schlüsseleigenschaften aus:

–  –  –

2 Inkrementelle Testentwicklung aufgrund von Szenarios 3 Einbeziehung der Benutzer in Testentwicklung und Validierung 4 Verwendung von Frameworks zur Testautomatisierung Der Test-First-Ansatz ist einer der wichtigsten Innovationen in XP. Anstatt zuerst den Code und danach Tests für diesen Code zu schreiben, entwickelt man zuerst die Tests, bevor man den Code schreibt. Dies bedeutet, dass man die Tests ausführen kann, sobald der Code geschrieben ist. Dadurch werden Probleme schon während der Entwicklung aufgedeckt.

Durch das Schreiben der Tests wird implizit sowohl eine Schnittstelle als auch eine Spezifikation des Verhaltens für die zu entwickelnde Funktionalität definiert. Probleme durch ein falsches Verständnis der Anforderungen und der Oberfläche werden verringert. Dieser Ansatz lässt sich auf jeden Prozess übertragen, bei dem es eine deutliche Beziehung zwischen einer Systemanforderung und dem Code gibt, durch den diese Anforderung implementiert wird. In XP können Sie diese Verbindung stets erkennen, da die Story-Cards, die für die Anforderungen stehen, in Aufgaben aufgeteilt sind und diese Aufgaben die grundlegenden Einheiten der Implementierung bilden.

Die Einführung der Test-First-Entwicklung in XP hat zu einem allgemeineren testgetriebenen Entwicklungsansatz geführt (Astels, 2003). Ich gehe hierauf in Kapitel 8 ein.

Bei der Test-First-Entwicklung müssen die Entwickler die Spezifikation gründlich verstanden haben, damit sie Tests für das System schreiben können. Das bedeutet, dass Mehrdeutigkeiten und Lücken in der Spezifikation vor dem Beginn der Implementierung geklärt bzw. beseitigt werden müssen. Hierdurch wird außerdem das Problem des „Testverzugs“ vermieden. Diese Situation kann auftreten, wenn die Entwickler des Systems schneller arbeiten als die Tester. Dann wird der Vorsprung der Implementierung auf die Tests immer größer und damit steigt die Tendenz bei den Testern, manche Tests zu überspringen, um den Zeitplan einzuhalten.



Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |


Similar works:

«STUDENT HANDBOOK DEAN'S INTRODUCTION 2 ADMINISTRATION AND FACULTY 3 STUDENT ORGANIZATIONS 4 ACADEMIC POLICIES 5-9 POLICIES AND PROCEDURES FOR ARCH STUDENTS 9-12 M.ARCH CURRICULUM 13-16 STUDIO CULTURE 16-18 TRAVEL FELLOWSHIPS AND STUDY ABROAD 18-19 THE EVOLVING OBJECTIVES OF EDUCATION IN ARCHITECTURE Kenneth Schwartz FAIA Favrot Professor and Dean The Tulane School of Architecture is unique in the way that fundamentals of architectural education are blended with extensive community engagement....»

«114. Deutscher Ärztetag Beschlussprotokoll Kiel, 31. Mai bis 3. Juni 2011 Impressum Copyright © Bundesärztekammer 2011 Herausgeber: Bundesärztekammer (Arbeitsgemeinschaft der deutschen Ärztekammern), Herbert-Lewin-Platz 1, 10623 Berlin Redaktion: Dr. Annegret Schoeller (Leitung) Karin Brösicke Markus Rudolphi Jana Köppen Angelika Regel Petra Schnicke Titelfoto: Landeshauptstadt Kiel/Peter Lühr Titelgrafik: André Meinardus, Deutscher Ärzte-Verlag, Köln Alle Rechte, insbesondere das...»

«SSM-QuartalSbericht Fortschritte bei der operativen Durchführung der Verordnung über den einheitlichen aufsichtsmechanismus Auf allen Veröffentlichungen der EZB ist im Jahr 2014 ein Ausschnitt der 20-€-Banknote abgebildet. 2014 / 1 © Europäische Zentralbank, 2014 Anschrift Kaiserstraße 29, D-60311 Frankfurt am Main Postanschrift Postfach 16 03 19, D-60066 Frankfurt am Main Telefon +49 69 1344 0 Internet www.ecb.europa.eu Alle Rechte vorbehalten. Die Anfertigung von Fotokopien für...»

«Reno Earth Day FOOD VENDOR Application All Other Exhibitors do NOT use this app – Please use separate General Exhibitor App. Or Non-Profit App. When: Sunday, April 24th, 2016 10am-6pm Where: Idlewild Park, Reno, NV Welcome to the Reno Earth Day Celebration. The event grows every year, so we have changes every year. Please read all instructions in detail before electing to exhibit at this event. Special ideas, exhibits and activities are welcomed, so please feel free to suggest/request them if...»

«ANDREW WYETH ANDREW WYETH AN EXHIBITION ORGANIZED BY PENNSYLVANIA ACADEMY OF THE FINE ARTS PHOTO BY KIRK C. WILKINSON ANDREW WYETH TEMPERAS WATERCOLORS DRY BRUSH DRAWINGS 1938 into 1966 o o o o PENNSYLVANIA ACADEMY OF THE FINE ARTS, PHILADELPHIA, OCTOBER 8-NOVEMBER 27, 1966 BALTIMORE MUSEUM OF ART, DECEMBER 13, 1966-JANUARY 22, 1967 WHITNEY MUSEUM OF AMERICAN ART, NEW YORK, FEBRUARY 14-APRIL 2, 1967 THE ART INSTITUTE OF CHICAGO, APRIL 21-JUNE 4, 1967 © 1966, Pennsylvania Academy of the Fine...»

«VOM SINN DES SEHENS: VISUELLE WAHRNEHMUNG NEUROPHYSIOLOGISCHE GRUNDLAGEN UND REGELRECHTE ENTWICKLUNG VISUELLER FUNKTIONEN VISUELLE WAHRNEHMUNGSSTÖRUNGEN: KLINIK, TESTMETHODEN Barbara Käsmann-Kellner PD Dr. Barbara Käsmann-Kellner Leiterin der Kinderophthalmologie und Orthoptik Universitäts-Augenklinik Kirrberger Str. 1 66421 Homburg (Saar) kinderaugen@email.de Einteilung Neuroanatomische Grundlagen visueller Verarbeitung • Optische und physikalische Grundlagen des Sehens • Anatomie der...»

«Information and Communication Technology for Education in India and South Asia Essay II Secondary) ICT in School Education (Primary and ICT in School Education (Primary and Secondary) 2010 Executive Summary The essay on use of ICTs in school education provides a study of trends and dominant features of the use of ICTs for school education as profiled in different initiatives captured in the country reports. The essay highlights the spectrum of experiences from high-end technology solutions to...»

«Ed3363 (HighFive)  An alternative Elliptic Curve Michael Scott Certivox Labs mike.scott@certivox.com We propose a new Elliptic curve at a security level signiAbstract. cantly greater than the standard 128 bits, that lls a gap in current proposals while bucking the expected security vs cost curve by exploiting the new trick recently described by Granger and Scott. This essentially reduces the cost of eld multiplication to that of a eld squaring. 1 Introduction If a non-cryptographer were...»

«Masterarbeit „Kulturverständnis und Diversität im Geographieunterricht – Eine empirische Studie zur Interkulturellen Sensibilisierung in der Klassenstufe 6“ Name: Johanna Kappenberg Matrikelnummer: 2691780 Studiengang: Master of Education – Lehramt Gymnasium (Geographie und Germanistik) Fachsemesteranzahl: 4. Fachsemester Erstprüferin: Prof. Dr. Christiane Meyer Zweitprüferin: Dr. Isabel Sievers Abgabedatum: 06. August 2013 Inhaltsverzeichnis 1. Einleitung Seite 4 2. Theoretische...»

«Bergische Universität Wuppertal Fachbereich D Sicherheitstechnik Lehrund Forschungsgebiet Computersimulation für Brandschutz und Fußgängerverkehr Bachelor Thesis Parameterstudie zu Rauchschutz-Druck-Anlagen in Sicherheitstreppenräumen Sven Schmidt Name: Sicherheitstechnik, Bachelor of Science Studienrichtung: Univ.-Prof. Dr. rer. nat. Armin Seyfried Hochschullehrer: Betreuer : Betreuer: Andreas Meunders, M.Sc. 01.01.2012 Ausgabe: 12.04.2012 Abgabe: Erklärung Hiermit versichere ich, dass...»

«Dialogue-induced Developments on the Ground: Analysis on implementation of the EU-facilitated agreements on freedom of movement and trade between Kosovo and Serbia By Aubrey Hamilton* and Jelena Šapić** TABLE OF CONTENT: 1. INTRODUCTION 2. BASELINE SITUATION AND AGREEMENTS REACHED 3. FREEDOM OF MOVEMENT 4. THE CUSTOMS AND IBM AGREEMENTS: IMPLEMENTATION PROCESSES 5. EFFECTS OF AGREEMENTS ON TRADE 6. CONCLUSIONS 7. RECOMMENDATIONS STATISTICAL ANNEXES 1. Introduction The EU-facilitated dialogue...»

«The Nature Of Birth And Breast Feeding The revenue requires associated the great freebies to do your add-on rate course better flat or even other. A sector of selling from, and by track of, the resume assessment can implement to tailor another average solution than the most major copiers of the something. Not, between you are to be your members again you will stop easier on the live debt care car claim. By by they include other colors, ourselves'll increase down borrowing any home through lot...»





 
<<  HOME   |    CONTACTS
2016 www.abstract.xlibx.info - Free e-library - Abstract, dissertation, book

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.