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



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

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

-- [ Page 1 ] --

Software Engineering

Ian Sommerville

Software

Engineering

9., aktualisierte Auflage

Higher Education

München • Harlow • Amsterdam • Madrid • Boston

San Francisco • Don Mills • Mexico City • Sydney

a part of Pearson plc worldwide

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Die Informationen in diesem Buch werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht.

Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.

Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht ausgeschlossen werden.

Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen.

Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Autor dankbar.

Authorized translation from the English language edition, entitled SOFTWARE ENGINEERING by IAN SOMMERVILLE, published by Pearson, Inc., publishing as Addison-Wesley, Copyright © 2011, GERMAN Language edition published by Pearson Deutschland GmbH, Copyright © 2012.

Es konnten nicht alle Rechteinhaber von Abbildungen ermittelt werden. Sollte dem Verlag gegenüber der Nachweis der Rechtsinhaberschaft geführt werden, wird das branchenübliche Honorar nachträglich gezahlt.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien.

Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.

Fast alle Produktbezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschützt.

Da es nicht möglich ist, in allen Fällen zeitnah zu ermitteln, ob ein Markenschutz besteht, wird das ®-Symbol in diesem Buch nicht verwendet.

ISBN 978-3-86894-099-2 © 2012 by Pearson Deutschland GmbH Martin-Kollar-Straße 10-12, D-81829 München/Germany Alle Rechte vorbehalten www.pearson.de A part of Pearson plc worldwide Programmleitung: Birger Peil, bpeil@pearson.de Development: Alice Kachnij, akachnij@pearson.de Fachlektorat: Professor Dr. Andrea Baumann Übersetzung: Katharina Pieper, Berlin; Petra Alm, Saarbrücken Korrektorat: Katharina Pieper, Berlin Einbandgestaltung: Thomas Arlt, tarlt@adesso21.net Herstellung: Monika Weiher, mweiher@pearson.de Satz: mediaService, Siegen (www.media-service.tv) Druck und Verarbeitung: Drukarnia Dimograf, Bielsko-Biala Printed in Poland Agile Softwareentwicklung

3.1 Agile Methoden.................................. 88

–  –  –

Einführung Das Ziel dieses Kapitels ist, Sie in die Methoden der agilen Softwareentwicklung einzuführen. Wenn Sie dieses Kapitel gelesen haben, werden Sie  die Grundprinzipien der Methoden in der agilen Softwareentwicklung, das agile Manifest und den Unterschied zwischen agiler und plangesteuerter Entwicklung verstehen;

 die wichtigsten Methoden von Extreme Programming kennen und verstehen, wie diese mit den allgemeinen Prinzipien von agilen Methoden verwandt sind;

 den Scrum-Ansatz zum agilen Projektmanagement verstehen;

 sich der Kernfragen und Probleme der skalierbaren agilen Methoden bei der Entwicklung von großen Softwaresystemen bewusst sein.

Unternehmen sind heute in globalen, sich schnell verändernden Umfeld tätig. Sie müssen auf neue Gelegenheiten und Märkte, veränderte wirtschaftliche Bedingungen und das Erscheinen von Konkurrenzprodukten und -dienstleistungen reagieren. Software ist nahezu Teil aller Geschäftstätigkeiten, daher wird neue Software schnell entwickelt, um neue Gelegenheiten zu nutzen und auf Konkurrenzdruck zu reagieren.

Heutzutage sind deswegen die schnelle Entwicklung und Auslieferung häufig die entscheidendsten Anforderungen an Softwaresysteme. Tatsächlich sind viele Unternehmen bereit, Softwarequalität und die Einhaltung von Anforderungen gegen die schnelle Auslieferung einzutauschen, um eine schnellere Entwicklung der benötigten Software zu erreichen.

Da diese Unternehmen in einem sich ändernden Umfeld tätig sind, ist es oft unmöglich, eine vollständige Menge stabiler Softwareanforderungen zu gewinnen. Die vorgeschlagenen Anforderungen ändern sich unweigerlich, da die Kunden kaum vorhersagen können, wie ein System die Arbeitsabläufe beeinflussen und wie es mit anderen Systemen zusammenarbeiten wird und welche Benutzerprozesse automatisiert werden sollten. Es kann sein, dass die wirklichen Anforderungen erst dann deutlich werden, wenn ein System ausgeliefert wurde und die Benutzer Erfahrungen damit gesammelt haben. Selbst dann ist es wahrscheinlich, dass die Anforderungen sich schnell und unvorhersehbar aufgrund externer Faktoren ändern. Die Software ist dann möglicherweise schon bei der Auslieferung veraltet.

Verfahren, die auf der vollständigen Spezifikation der Anforderungen und dem anschließenden Entwerfen, Erstellen und Testen des Systems basieren, zielen nicht auf schnelle Softwareentwicklung ab. Wenn sich die Anforderungen ändern oder Probleme mit den Anforderungen entdeckt werden, muss der Systementwurf oder die Implementierung angepasst und erneut getestet werden. Folglich dauert ein konventioneller





Einführung

Wasserfallprozess oder ein spezifikationsbasiertes Verfahren gewöhnlich sehr lange, sodass die endgültige Software lange Zeit nach der ursprünglichen Spezifikationserstellung an den Kunden ausgeliefert wird.

Für einige Softwarearten wie sicherheitskritische Steuerungssysteme, bei denen eine vollständige Analyse des Systems von entscheidender Bedeutung ist, ist ein plangesteuerter Ansatz die richtige Wahl. In einer schnell wechselnden Geschäftsumgebung jedoch kann dieser Ansatz zu großen Problemen führen. Bis die Software zur Verfügung steht, kann sich der ursprüngliche Grund für ihre Bestellung so grundlegend geändert haben, dass die Software letztlich nutzlos ist. Daher sind vor allem für Geschäftssysteme Entwicklungsverfahren wichtig, die sich auf schnelle Softwareentwicklung konzentrieren.

Es ist schon vor einiger Zeit erkannt worden, dass eine schnelle Systementwicklung sowie Verfahren, die mit sich ändernden Anforderungen umgehen können, benötigt werden. IBM hat die inkrementelle Entwicklung in den 1980er Jahren eingeführt (Mills et al., 1980). Auch die Einführung der sogenannten Sprachen der vierten Generation – ebenfalls in den 1980er Jahren – unterstützte die Idee der schnellen Softwareentwicklung und -auslieferung (Martin, 1981). Einen wahrhaften Aufschwung erlebte die Idee jedoch in den späten 1990er Jahren mit der Entwicklung von agilen Ansätzen wie DSDM (Stapleton, 1997), Scrum (Schwaber und Beedle, 2001) und Extreme Programming (Beck, 1999; Beck, 2000).

Prozesse zur schnellen Softwareentwicklung sind dazu gedacht, in kurzer Zeit nützliche Software zu entwerfen. Die Software wird nicht als Einheit entwickelt, sondern als eine Folge von Inkrementen, in denen jeweils neue Systemfunktionalität hinzugefügt wird. Zwar gibt es viele Ansätze zur schnellen Softwareentwicklung, doch weisen

sie einige grundlegende Gemeinsamkeiten auf:

1 Die Prozesse für Spezifikation, Entwicklung und Implementierung erfolgen verzahnt. Es gibt keine detaillierte Systemspezifikation, die Entwurfsdokumentation ist minimal oder wird automatisch von der zur Implementierung verwendeten Programmierumgebung erstellt. Die Dokumentation der Benutzeranforderungen definiert lediglich die wichtigsten Systemeigenschaften.

2 Das System wird in einer Reihe aufeinander aufbauender Versionen entwickelt. Die Endbenutzer und andere am System Beteiligte werden in die Entwicklung und Evaluation aller Versionen eingebunden. Sie können Softwareänderungen und neue Anforderungen vorschlagen, die in spätere Versionen der Software einfließen können.

3 Die Benutzeroberflächen werden normalerweise unter Benutzung eines interaktiven Entwicklungssystems erstellt, das einen schnellen Oberflächenentwurf ermöglicht, indem Symbole gezeichnet oder ausgewählt und auf der Benutzeroberfläche platziert werden. Das System kann dann eine webbasierte Oberfläche für einen Browser oder eine Oberfläche für eine bestimmte Plattform wie Microsoft Windows erstellen.

Agile Methoden sind inkrementelle Entwicklungsmethoden, bei denen die Inkremente klein sind und bei denen typischerweise alle zwei oder drei Wochen neue Versionen des Systems erzeugt und dem Kunden zur Verfügung gestellt werden. Sie beziehen Kunden in den Entwicklungsprozess ein, um schnelle Rückmeldungen auf sich ändernde Anforderungen zu bekommen. Indem eher informelle Kommunikation eingesetzt wird anstatt formelle Sitzungen mit schriftlichen Unterlagen abzuhalten, wird die Dokumentation minimiert.

3 Agile Softwareentwicklung

3.1 Agile Methoden In den 1980er und frühen 1990er Jahren war die Ansicht weitverbreitet, dass die beste Möglichkeit, bessere Software zu erreichen, in sorgfältiger Projektplanung, formalisierter Qualitätssicherung, Analyse- und Entwurfsmethoden mithilfe von CASE-Werkzeugen und kontrollierten und strikten Softwareentwicklungsprozessen bestand.

Diese Ansicht wurde von der Software-Engineering-Gemeinschaft aufgestellt, die verantwortlich war für die Entwicklung von großen, langlebigen Softwaresystemen wie Systemen für die Raumfahrt und die Regierung.

Software dieser Art wurde von großen Teams entwickelt, die für unterschiedliche Unternehmen arbeiteten. Die Teams waren häufig weiträumig verstreut und arbeiteten jeweils lange Zeit an der Software. Ein Beispiel für diese Art von Software sind Steuerungssysteme für moderne Flugzeuge, bei denen von der ursprünglichen Spezifikation bis zur Bereitstellung bis zu zehn Jahre vergehen können. Diese plangesteuerten Ansätze erfordern einen deutlichen zusätzlichen Aufwand für die Planung, den Entwurf und die Dokumentation des Systems. Dieser Mehraufwand ist gerechtfertigt, wenn die Arbeit von mehreren Entwicklerteams koordiniert werden muss, wenn es sich um ein kritisches System handelt und wenn an der Wartung der Software während ihrer Einsatzzeit viele verschiedene Menschen beteiligt sind.

Wenn dieser schwergewichtige, plangesteuerte Entwicklungsansatz jedoch auf kleine und mittlere Geschäftssysteme angewendet wird, erweist sich der Aufwand als so hoch, dass er den gesamten Softwareentwicklungsprozess beherrscht. Es wird mehr Zeit für die Planung der Systementwicklung aufgewendet als für die eigentliche Programmentwicklung und die Tests. Bei Änderungen der Systemanforderungen sind Umarbeitungen erforderlich. Dabei müssen – zumindest im Prinzip – die Spezifikation und der Entwurf zusammen mit dem Programm geändert werden.

Die Unzufriedenheit mit diesen aufwendigen Ansätzen des Software-Engineerings brachte eine Reihe von Softwareentwicklern in den 1990er Jahren dazu, neue „agile Methoden“ vorzuschlagen. Diese Methoden erlaubten es dem Entwicklerteam, sich auf die Software selbst zu konzentrieren statt auf ihren Entwurf und die Dokumentation. Alle agilen Methoden stützen sich auf einen inkrementellen Ansatz für Softwarespezifikation, -entwicklung und -auslieferung. Sie sind bei der Entwicklung von solchen Geschäftsanwendungen am besten geeignet, bei denen sich die Systemanforderungen während der Entwicklung schnell ändern. Der Sinn ist, in kurzer Zeit funktionierende Software an den Kunden auszuliefern, der dann neue und veränderte Anforderungen vorschlagen kann, die in spätere Iterationen des Systems aufgenommen werden sollen. Agile Methoden helfen, die Prozessbürokratie zu reduzieren, indem Arbeit vermieden wird, die einen zweifelhaften Langzeitwert hat, und indem Dokumentation abgeschafft wird, die vermutlich niemals benutzt wird.

Die Philosophie hinter agilen Methoden spiegelt sich im agilen Manifest wider, auf das sich viele der führenden Entwickler dieser Vorgehensweise geeinigt haben. Dies

Manifest besagt:

Wir suchen nach besseren Wegen, Software zu entwickeln, indem wir es selbst

tun und anderen dabei helfen. Durch diese Arbeit haben wir schätzen gelernt:

Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

Funktionierende Software hat Vorrang vor umfangreicher Dokumentation.

3.1 Agile Methoden

Stetige Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsvereinbarungen.

Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Obwohl die jeweils zuletzt genannten Punkte auch ihren Wert haben, so schreiben wir doch den erstgenannten Punkten einen größeren Wert zu.

Die wahrscheinlich bekannteste agile Methode ist das Extreme Programming (Beck, 1999; Beck, 2000), die ich später in diesem Kapitel beschreibe. Weitere agile Ansätze sind Scrum (Cohn, 2009; Schwaber, 2004; Schwaber und Beedle, 2001), Crystal (Cockburn, 2001; Cockburn, 2004), Adaptive Software Development (Highsmith, 2000), DSDM (Stapleton, 1997; Stapleton, 2003) und Feature Driven Development (Palmer und Felsing, 2002). Der Erfolg dieser Methoden hat zu einer gewissen Integration mit traditionelleren Entwicklungsverfahren auf der Grundlage der Systemmodellierung geführt. Ergebnis davon sind die Gedanken zur agilen Modellierung (Ambler und Jeffries, 2002) und die agile Verwendung des Rational Unified Process (Larman, 2002).

Obwohl alle diese agilen Methoden auf inkrementeller Entwicklung und Auslieferung beruhen, setzen sie unterschiedliche Prozesse ein, um dieses Ziel zu erreichen. Allerdings teilen sie eine Reihe von Prinzipien, die alle auf dem agilen Manifest basieren, sodass sie viel gemeinsam haben. Diese Prinzipien sind in  Abbildung 3.1 aufgelistet. Verschiedene agile Methoden setzen diese Prinzipien auf unterschiedliche Art um und ich habe hier nicht den Platz, alle agilen Methoden zu besprechen. Stattdessen konzentriere ich mich auf zwei der verbreitetsten Verfahren: Extreme Programming (Abschnitt 3.3) und Scrum (Abschnitt 3.4).

–  –  –

Abbildung 3.1: Die Prinzipien der agilen Methoden.

3 Agile Softwareentwicklung

Agile Methoden waren für einige Arten der Systementwicklung sehr erfolgreich:



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


Similar works:

«NCTU Hsinchu Taiwan Marco polo general report Study abroad in Taiwan Meryl Schotanus 1. Home institution and exact dates abroad Home University: University of Groningen Host University: National Chiao Tung University (Hsinchu, Taiwan) Semester abroad: 15 September – 15 January 2. Contact with home faculty, preparation and journey Contact Contact home University: Henk Ritsema Faculty: Ina Venhuizen Preparation Before going to Taiwan you need to make sure that you get the right vaccinations....»

«ALITALIA – ANCILLARY SERVICES FULFILMENT ANCILLARY SERVICES FULFILMENT THROUGH EMD WITH GDS AMADEUS Vers. 1.1 – September 2012 ALITALIA – ANCILLARY SERVICES FULFILMENT Summary 1. Purpose of this document.. 3 2. Ancillary services payment in connection with Alitalia flights. 3 3. General information about EMD.. 4 4. Reservation service process..5 5. Cancellation of the service.. 5 6. Issuance of the EMD.. 6 7. EMD void.. 8 8. EMD refund.. 8 9. EMD exchange.. 8 10. Impact on EMD in case of...»

«GROSS-ZAGIER REVISITED BRIAN CONRAD Contents 1. Introduction 1 2. Some properties of abelian schemes and modular curves 3 3. The Serre-Tate theorem and the Grothendieck existence theorem 7 4. Computing naive intersection numbers 10 5. Intersection formula via Hom groups 12 6. Supersingular cases with rA (m) = 0 15 7. Application of a construction of Serre 21 8. Intersection theory via meromorphic tensors 29 9. Self-intersection formula and application to global height pairings 34 10....»

«Romanian Biotechnological Letters Vol. 18, No.2, 2013 Copyright © 2013 University of Bucharest Printed in Romania. All rights reserved ORIGINAL PAPER Genetic Structure Analysis of Sclerotinia Sclerotiorum (Lib.) de Bary Population from Different host plant species in North of Iran Received for publication, November 7, 2012 Accepted, March 14, 2013 HOSSEIN BARARI1, SEYED ALIREZA DALILI1, SEYED ALI AKBAR REZAII and SUSSANNA M. BADALIAN2 1.Agriculture and Natural Resources Research Center of...»

«Criminal court statistics quarterly, England and Wales July to September 2015 Ministry of Justice Statistics bulletin Published 17th December 2015 Contents Introduction 2  Changes and revisions in this publication 4  Key findings 5  Criminal Courts 6  1.  Criminal cases in the magistrates’ courts 6  2.  Criminal cases in the Crown Court 7  3.  Timeliness 10  Annex A: Enforcement of financial impositions 13  Annex B: List of accompanying tables and CSV 16  Annex C: Explanatory...»

«©Naturhistorisches Museum Wien, download unter www.biologiezentrum.at Ann. Naturhist. Mus. Wien 100 B 671-676 Wien, Dezember 1998 On the taxonomy of Catapyreniumplumbeum (lichenized Ascomycetes, Verrucariaceae) O. Breuß* Abstract Catapyrenium plumbeum is shown to comprise three species, two of which belong to Verrucaria, and one to Placopyrenium. Verrucaria inficiens is a nomen novum, Verrucaria cetera and Placopyrenium noxium are described as new. They differ in spore size, presence or...»

«Was verstehen wir unter Test? Abstraktionsebenen, Begriffe und Definitionen Dr.-Ing. Gerd Baumann, FKFS, Stuttgart 1. AutoTest; Fachkonferenz zum Thema Test und Diagnose in der Automobilentwicklung. Stuttgart, 26./26.10.2006. Zusammenfassung Beim Test von elektronischen Steuergeräten und Embedded Software für Kraftfahrzeuge wird eine Vielzahl von Methoden eingesetzt, die sich in den einzelnen Entwicklungsphasen der Elektronik für ein neues Kraftfahrzeug signifikant unterscheiden. Heute sind...»

«Département fédéral des transports, des communications et de l'énergie N° 1603 Rapport Final du Bureau d’enquêtes sur les accidents d’aviation concernant l‘accident de l'avion Piper PA-28 Warrior II, HB-PCG du 5 février 1995 à Fey (commune de Nendaz) / VS Zusammenfassung HB-PCG Am Samstag 4. Februar 1995 war der Pilot mit drei Bekannten in Sitten zu einem VFR-Vergnügungsflug nach Turin gestartet. Im Raum Brig stellte er fest, dass die Wetterverhältnisse für einen Weiterflug...»

«Rational theory choice: Arrow undermined, Kuhn vindicated Seamus Bradley May 12, 2014 In a recent paper, Samir Okasha presented an argument that suggests that there is no rational way to choose among scientific theories. This would seriously undermine the view that science is a rational entreprise. In this paper I show how a suitably nuanced view of what scientific rationality requires allows us to avoid Okasha’s conclusion. I go on to argue that making further assumptions about the space...»

«Mystery of CapitalCRev 2/18/08 11:13 AM Page 35 from Barry Smith, David Mark and Isaac Ehrlich (eds.), The Mystery of Capital and the Construction of Social Reality, Chicago: Open Court, 2008, 35-51. Searle and de Soto: 3 The New Ontology of the Social World Barry Smith 1. A Game of Chess What is a game of chess? This simple question has, in the simplest case, a simple answer: A game of chess is a sequence of deliberate moves of certain distinctively shaped pieces across a distinctively...»

«УДК 347.934 Голова Светлана Ивановна Golova Svetlana Ivanovna преподаватель кафедры предварительного Lecturer, Preliminary Investigation Subdepartment, расследования Krasnodar University of Краснодарского университета МВД России the Ministry of Internal Affairs of Russia ПОНЯТИЕ И СИСТЕМА ГАРАНТИЙ THE CONCEPTION AND THE SYSTEM ЗАЩИТЫ ПРАВ...»

«Carnegie Mellon University Research Showcase @ CMU Institute for Software Research School of Computer Science The Amulet Prototype-Instance Framework Brad Myers Carnegie Mellon University Richard G. McDaniel Carnegie Mellon University Robert C. Miller Carnegie Mellon University Follow this and additional works at: http://repository.cmu.edu/isr This Working Paper is brought to you for free and open access by the School of Computer Science at Research Showcase @ CMU. It has been accepted for...»





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