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



Pages:     | 1 |   ...   | 3 | 4 || 6 |

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

-- [ Page 5 ] --

und Janoff (2000) diskutieren die gelungene Verwendung in einer Softwareentwicklungsumgebung im Telekommunikationsbereich; sie führen die folgenden Vorteile auf:

1 Das Produkt wird in eine Reihe von verwaltbaren und verständlichen Teilstücken zerlegt.

2 Instabile Anforderungen behindern den Fortschritt nicht.

3 Jedes Teammitglied hat Sicht auf das gesamte System, wodurch die Teamkommunikation gefördert wird.

4 Kunden bekommen die einzelnen Inkremente fristgerecht geliefert und erhalten Feedback über die Funktionsweise des Produkts.

5 Zwischen Kunden und Entwicklern wird Vertrauen aufgebaut und eine positive Atmosphäre erzeugt, in der jeder davon ausgeht, dass das Projekt gelingt.

Scrum wurde ursprünglich für Teams entworfen, deren Mitglieder sich alle an einem Ort befinden und die jeden Tag für Stand-up-Meetings zusammenkommen können.

Heute findet Softwareentwicklung oft mit Teams statt, bei denen sich die Teammitglieder an unterschiedlichen Orten auf der ganzen Welt befinden. Es gibt deshalb verschiedene Versuche, Scrum auf verteilte Entwicklungsumgebungen anzupassen (Smits und Pshigoda, 2007; Sutherland et al., 2007).

3 Agile Softwareentwicklung

3.5 Skalieren von agilen Methoden Agile Methoden wurden als Werkzeuge für kleine Programmierteams entwickelt, deren Mitglieder im gleichen Raum zusammenarbeiten und sich informell austauschen konnten. Agile Methoden wurden daher meistens für die Entwicklung von kleinen und mittelgroßen Systemen eingesetzt. Das Bedürfnis, die Software schneller auszuliefern – was eher den Kunden entgegenkommt –, betrifft natürlich auch größere Systeme. Deshalb gibt es ein großes Interesse an der Skalierung von agilen Methoden, um mit komplexeren Systemen, die von großen Unternehmen entwickelt werden, zurecht zu kommen.

Denning et al. (2008) argumentieren, dass die einzige Art und Weise, die üblichen Software-Engineering-Probleme zu vermeiden (zum Beispiel Systeme, die die Bedürfnisse des Kunden nicht erfüllen, oder Budgetüberziehungen), darin besteht, agile Methoden auf große Systeme anzuwenden. Leffingwell (2007) diskutiert, welche agilen Verfahren auf die Entwicklung von großen Systemen angepasst werden können.

Moore und Spens (2008) berichten über ihre Erfahrung, mit einem agilen Ansatz ein großes medizinisches System zu entwickeln, an dem 300 Entwickler beteiligt waren, die in geografisch verteilten Gruppen arbeiteten.

Die Entwicklung von großen Softwaresystemen unterscheidet sich von der Entwicklung von kleinen Systemen auf viele Arten:

1 Große Systeme sind in der Regel Sammlungen von separaten, kommunizierenden Systemen, wobei jedes Teilsystem von getrennten Teams entwickelt wird. Häufig arbeiten diese Teams an unterschiedlichen Orten, manchmal in verschiedenen Zeitzonen. Es ist praktisch unmöglich, jedem Team eine Sicht auf das gesamte System zu geben. Daher liegt die Priorität jedes einzelnen Teams gewöhnlich darin, seinen Teil des Systems ohne Rücksicht auf übergreifende Systemaspekte zu vervollständigen.

2 Große Systeme sind sogenannte „Brownfield-Systeme“ (Hopkins und Jenkins, 2008). Das heißt, sie beinhalten eine Reihe existierender Systeme, die untereinander interagieren. Viele Systemanforderungen betreffen diese Interaktion und eignen sich daher eigentlich nicht für flexible und inkrementelle Entwicklung.

Auch politische Aspekte können hier eine Rolle spielen: Oft ist es die einfachste Lösung, ein vorhandenes System zu ändern, doch dazu sind Verhandlungen mit dem Systemmanager nötig. Dieser muss überzeugt werden, dass die Änderungen implementiert werden können, ohne die Systemoperationen zu gefährden.

3 Wenn mehrere Teilsysteme integriert werden, um ein großes System zu bilden, so wird ein weit größerer Anteil der Entwicklungszeit für die Systemkonfiguration als für die ursprüngliche Codeentwicklung verbraucht. Dies lässt sich nicht unbedingt mit inkrementeller Entwicklung und häufiger Systemintegration in Einklang bringen.

4 Große Systeme und ihre Entwicklungsprozesse werden oft von externen Regeln und Vorschriften eingeengt, die beispielsweise die Art und Weise der Entwicklung beschränken oder bestimmte Arten der Systemdokumentation vorschreibt.

5 Große Systeme habe eine lange Auftrags- und Entwicklungszeit. Es ist schwierig, die Zusammensetzung des Teams über eine solche Zeitspanne hinweg aufrechtzuerhalten, da einige Mitglieder – unvermeidlich – zu anderen Arbeitsstellen oder Projekten wechseln.

–  –  –

6 Bei großen Systemen gibt es in der Regel viele unterschiedliche Interessengruppen. Beispielsweise könnten Pflegepersonal und Systemadministratoren die Endnutzer eines medizinischen Systems sein, doch das leitende medizinische Personal, Krankenhausverwalter usw. gehören ebenfalls zu den Anwendern des Systems. Es ist praktisch unmöglich, all diese unterschiedlichen Gruppen in den Entwicklungsprozess einzubeziehen.

Es gibt zwei Perspektiven beim Skalieren von agilen Methoden:

1 Eine „Scale-up“-Perspektive, die sich mit dem Anwenden dieser Methoden zum Entwickeln großer Softwaresysteme befasst, die nicht von einem kleinen Team entwickelt werden können.

2 Eine „Scale-out“-Perspektive, die sich damit beschäftigt, wie agile Methoden in großen Organisationen, die über viele Jahre Erfahrung in der Softwareentwicklung besitzen, eingeführt werden können.





Agile Methoden müssen auf die Entwicklung von großen Systemen angepasst werden.

Leffingwell (2007) behauptet, dass es hauptsächlich auf die Erhaltung der grundlegenden Elemente von agilen Methoden – flexible Planung, häufige Systemreleases, kontinuierliche Integration, testgetriebene Entwicklung und gute Teamkommunikation – ankommt. Ich denke, dass die entscheidenden Anpassungen, die eingeführt werden

müssen, die folgenden sind:

1 Für die Entwicklung von großen Systemen ist es nicht möglich, sich nur auf den Code für das System zu konzentrieren. Man muss im Voraus mehr Entwurfsarbeit leisten und Systemdokumentation herstellen. Die Softwarearchitektur muss entworfen werden und es muss Dokumentation erstellt werden, um kritische Aspekte des Systems zu beschreiben, wie Datenbankschemata, die Arbeitsaufteilung zwischen den Teams usw.

2 Es müssen Mechanismen zur teamübergreifenden Kommunikation entwickelt und angewandt werden. Darin sollten regelmäßige Telefonate und Videokonferenzen zwischen Teammitgliedern und häufige, kurze elektronische Konferenzen enthalten sein, bei denen die Teams sich gegenseitig auf den aktuellen Stand bringen. Zahlreiche Kommunikationskanäle wie E-Mail, Instant Messaging, Wikis und soziale Netzwerke sollten zur Verfügung stehen, um den Informationsaustausch zu erleichtern.

3 Wenn mehrere separate Programme integriert werden müssen, um das Gesamtsystem zu erzeugen, dann ist es praktisch unmöglich, das Konzept der fortlaufende Integration aufrechtzuerhalten. Dies würde nämlich bedeuten, dass jedes Mal das gesamte System gebaut werden muss, sobald ein Entwickler eine Änderung vornimmt. Es ist jedoch wichtig, das System häufig zusammenzusetzen und regelmäßige Systemreleases durchzuführen. Dies könnte bedeuten, dass neue Werkzeuge zur Konfigurationsverwaltung, die die Entwicklung durch mehrere Teams unterstützen, eingeführt werden müssen.

Kleine Softwareentwicklungsunternehmen gehörten zu den enthusiastischsten Anwendern der agilen Methoden. Diese Firmen werden nicht durch organisationsinterne Bürokratie oder Standardprozesse eingeengt und können sich schnell umstellen, um neue Konzepte zu übernehmen. Natürlich haben auch größere Unternehmen

3 Agile Softwareentwicklung

mit agilen Methoden in einzelnen Projekten experimentiert, aber es ist hier viel komplizierter, diese Methoden mittels eines „Scale-out“ im gesamten Unternehmen einzuführen. Lindvall et al. (2004) diskutieren einige der Probleme beim „Scale-out“ von agilen Methoden in vier großen Technologieunternehmen.

Es ist aus einer Reihe von Gründen schwierig, agile Methoden in großen Unternehmen

einzuführen:

1 Projektmanager, die keine Erfahrung mit agilen Methoden haben, könnten zurückhaltend auf das Risiko eines neuen Ansatzes reagieren, da sie nicht wissen, wie sich dieses Vorgehen auf ihre eigenen Projekte auswirkt.

2 Große Organisationen haben häufig Qualitätsverfahren und -standards, die von allen Projekten angewendet werden müssen und die aufgrund ihrer Bürokratie wahrscheinlich inkompatibel mit agilen Methoden sind. Manchmal werden diese Verfahren durch Softwarewerkzeuge unterstützt (z. B. Werkzeuge zur Anforderungsverwaltung), deren Einsatz für alle Projekte vorgeschrieben ist.

3 Agile Methoden scheinen am besten zu funktionieren, wenn die Teammitglieder hoch qualifiziert sind. Innerhalb von großen Organisationen gibt es jedoch vermutlich eine große Bandbreite von Qualifikationen und Fähigkeiten, doch weniger qualifizierte Mitarbeiter sind in agilen Prozessen eventuell keine effektiven Teammitglieder.

4 Es gibt möglicherweise einen kulturellen Widerstand gegen agile Methoden, besonders in solchen Organisationen, die seit Langem konventionelle Systementwicklungsprozesse verwenden.

Änderungsmanagement und Testprozeduren sind Beispiele für Verfahren in einem Unternehmen, die mit agilen Methoden eventuell nicht kompatibel sind. Das Änderungsmanagement steuert die Änderungen in einem System, sodass die Auswirkungen dieser Änderungen vorhersehbar und die Kosten kontrollierbar sind. Alle Änderungen müssen vor der Ausführung genehmigt werden, doch dies steht dem XP-Konzept des Refactoring entgegen, bei dem jeder Programmierer an jedem Codestück Verbesserungen vornehmen kann, ohne dafür eigens eine Erlaubnis einzuholen. Bei großen Systemen gibt es außerdem standardisierte Testverfahren, bei denen ein erzeugtes System an ein externes Testteam übergeben wird. Hier könnte es einen Konflikt mit dem Ansatz testgetriebenen und häufig zu testen geben, die in XP verwendet werden.

Das Einführen und Erhalten des Einsatzes von agilen Methoden innerhalb von großen Unternehmen setzt einen kulturellen Wandel voraus. Einen Wandel in der Unternehmenskultur zu erreichen dauert lange und es bedarf der Unterstützung durch das Management. Unternehmen, die agile Methoden einsetzen möchten, brauchen begeisterte Verfechter, um diesen Wandel zu fördern. Dem Änderungsprozess muss ein beträchtlicher Anteil der Ressourcen geopfert werden. Zum jetzigen Zeitpunkt haben nur wenige große Unternehmen den erfolgreichen Übergang zur agilen Entwicklung innerhalb der gesamten Organisation durchgesetzt.

–  –  –

Zusammenfassung  Agile Methoden sind inkrementelle Entwicklungsverfahren, die sich auf schnelle Entwicklung, häufige Softwarereleases, das Reduzieren von zusätzlichem Prozessaufwand und die Produktion von hoch qualitativem Code konzentrieren. Der Kunde wird dabei unmittelbar in den Entwicklungsvorgang einbezogen.

 Die Entscheidung darüber, ob ein agiler oder ein plangesteuerter Ansatz verwendet wird, sollte von der Art der zu entwickelnden Software, der Leistungsfähigkeit des Entwicklerteams und der Kultur des Unternehmens, die das System entwickelt, abhängen.

 Extreme Programming ist eine bekannte agile Methode, die sich verschiedener guter Programmierpraktiken wie häufige Softwarereleases, kontinuierlicher Softwareverbesserung und der Einbeziehung des Kunden in das Entwicklerteam bedient.

 Eine besondere Stärke des Extreme Programming ist die Entwicklung automatisierter Tests vor dem Erstellen einer Programmfunktion. Alle Tests müssen erfolgreich ausgeführt werden, wenn ein Inkrement in das System integriert wird.

 Die Scrum-Methode ist eine agile Methode, die einen Rahmen für das Projektmanagement bietet. Das Kernkonzept von Scrum ist eine Folge von Sprints – eine festgelegte Zeitperiode, in der ein Systeminkrement entwickelt wird. Die Planung basiert auf der Zuordnung von Prioritäten zu den einzelnen Aufgaben eines Backlogs und dem Auswählen der Aufgabe mit der höchsten Priorität für einen Sprint.

 Das Skalieren von agilen Methoden auf große Systeme ist schwierig. Für große Systeme muss der Entwurf im Voraus festgelegt werden, außerdem ist eine gewisse Menge an Dokumentation unumgänglich. Wenn mehrere separate Entwicklerteams zusammen an dem Projekt arbeiten, ist fortlaufende Integration praktisch unmöglich.

Ergänzende Literatur

Extreme Programming Explained. Dies war das erste Buch über XP und es ist möglicherweise immer noch das lesenswerteste. Es erklärt den Ansatz aus der Sicht eines seiner Erfinder, dessen Begeisterung sehr deutlich wird. (Kent Beck, Addison-Wesley, 2000. Deutsche Ausgabe: Extremprogrammierung. Das Manifest. Addison-Wesley, 2003.) „Get Ready for Agile Methods, With Care“. Eine tiefsinnige Kritik agiler Methoden, die ihre Stärken und Schwächen bespricht, geschrieben von einem sehr erfahrenen Softwareentwickler.

(B. Boehm, IEEE Computer, Januar 2002.) http://doi.ieeecomputersociety.org/10.1109/2.976920.

Scaling Software Agility: Best Practices for Large Enterprises. Obwohl auf Fragen des Skalierens agiler Entwicklung fokussiert, enthält dieses Buch auch eine Zusammenfassung der Prinzipien agiler Methoden wie XP, Scrum und Crystal. (D. Leffingwell, Addison-Wesley, 2007.) Running an Agile Software Development Project. Die meisten Bücher über agile Methoden konzentrieren sich auf bestimmte Methoden, doch dieses Buch schlägt einen anderen Weg ein und diskutiert, wie man XP ganz praktisch in einem Projekt anwenden kann. Gute, praktische Hilfestellung.

(M.Holcombe, John Wiley & Sons, 2008.) 3 Agile Softwareentwicklung

–  –  –

1 Erklären Sie, warum die schnelle Auslieferung und Bereitstellung neuer Systeme für Unternehmen oft wichtiger ist als die exakte Funktionalität.

2 Erklären Sie, wie die den agilen Methoden zugrunde liegenden Prinzipien zu einer beschleunigten Entwicklung und Bereitstellung von Software führen.

–  –  –

4 Extreme Programming drückt die Benutzeranforderungen in Form von User-Storys bzw. Szenarios aus, die jeweils auf eine Karteikarte geschrieben werden. Erörtern Sie die Vor- und Nachteile dieses Ansatzes zur Anforderungsbeschreibung.



Pages:     | 1 |   ...   | 3 | 4 || 6 |


Similar works:

«Förderung innovativer Lernansätze durch Integration von handys am Arbeitsplatz – onkologische Krankenpflege 518383-LLP-1-2011-1-ES-LEONARDO-LMP http://www.adam-europe.eu/adam/project/view.htm?prj=8255 Förderung innovativer Lernansätze durch Integration von handys am Arbeitsplatz – onkologische Krankenpflege (518383-LLP-1-2011-1-ES-LEONARDO-LMP) Projektinformation Titel: Förderung innovativer Lernansätze durch Integration von handys am Arbeitsplatz – onkologische Krankenpflege...»

«nlo KERESZTYBM \QMSKi A Z ORDASS LAJOS BARÁTI KÖR FOLYÓIRATA Űj folyam 8. szám ü 1990. DECEMBER TARTALOMJEGYZÉK oldal MEDITÁCIÓ SCHOLZ LÁSZLÓ: Advent 1 TANOLMÁNYOK VÁJTA VILMOS: A keresztény igazság 3 ITTZÉS GÁBOR: A Magyarországi Evangélikus Egyház a zsinat előtt ALPÁRNÉ SZÁLA ERZSÉBET: Lyceum Semproniense Hungaricum ELO TANUK LABORCZI ZOLTÁN: A nagybaráti találkozó: 1956. augusztus 28-30. OOKUMENTUMOK Levélváltás TEKUS OTTÓ FRENKL RÓBERT 42 MAGASSY SÁNDOR...»

«http://oac.cdlib.org/findaid/ark:/13030/tf409nb2cp No online items Finding Aid for the Henry E. Carter Papers, 1910-1940 Processed by UCLA Library Special Collections staff; machine-readable finding aid created by Caroline Cubé UCLA Library Special Collections UCLA Library Special Collections staff Room A1713, Charles E. Young Research Library Box 951575 Los Angeles, CA 90095-1575 Email: spec-coll@library.ucla.edu URL: http://www.library.ucla.edu/libraries/special/scweb/ © 1999 The Regents of...»

«Community 2 Nd Edition Show probably help your earning or meeting card with having their training track how investors actually continue. Prove certain you are to an look and influence all the free years. About, with all-in-all, borrower lots are remembered than last productivity services of world managers and many supplies. I have of into sending from it, you could mail loan, lot plus popularity. You also offer to lead who work government credit you know to control. In they had, them might help...»

«A publication of the European Crowdfunding Network in association with Osborne Clarke Regulation of Crowdfunding in Germany, the UK, Spain and Italy and the Impact of the European Single Market In association with June 2013 Tanja Aschenbeck-Florange, David Blair, Javier Beltran, Thomas Nagel, Umberto Piattelli, Laura Quintavalla with a foreword by Oliver Gajda Regulation of Crowdfunding in Germany, the UK, Spain and Italy and the Impact of the European Single Market – June 2013 Impressum...»

«Verfassungsschutzbericht Landesamt für erfassungsschutz www.hamburg.de/verfassungsschutz Verfassungsschutzbericht 2014  und Im Text finden Sie vielfach die Symbole Das Sinnbild „Buch“ verweist auf eine Fundstelle in diesem Verfassungsschutzbericht. Das Symbol „Weltkugel“ bedeutet, dass es zu dem Thema weitere Informationen auf unseren Internetseiten gibt. Unter http://www.hamburg.de/verfassungsschutz finden Sie regelmäßig aktuelle Informationen über alle Arbeitsfelder des...»

«ERSTE SCHRITTE Dieses Handbuch unterstützt Sie beim Einstieg in NVivo. Es enthält Schritte zur Installation der Software und zum Starten eines neuen Projekts und bietet eine Einführung in den NVivo-Arbeitsbereich und seine Funktionen. Copyright © 1999-2014 QSR International Pty Ltd. ABN 47 006 357 213. Alle Rechte vorbehalten. Die Begriffe und die Logos NVivo und QSR sind Marken oder eingetragene Marken von QSR International Pty Ltd. Microsoft,.NET, SQL Server, Windows, XP, Vista, Windows...»

«Biogeosciences Discuss., 4, 2959–3004, 2007 Biogeosciences www.biogeosciences-discuss.net/4/2959/2007/ Discussions © Author(s) 2007. This work is licensed under a Creative Commons License. Biogeosciences Discussions is the access reviewed discussion forum of Biogeosciences Three-dimensional Magnetic Resonance Imaging of fossils across taxa 1,2,3 4 1 4 4 4 D. Mietchen, M. Aberhan, B. Manz, O. Hampe, B. Mohr, C. Neumann, and F. Volke Fraunhofer Institute for Biomedical Engineering...»

«Guidelines Concerning Proceedings before the Office for Harmonization in the Internal Market (Trade Marks and Designs) Part M, International Marks Amendments to previous Chapter 13 of Examination Guidelines (Draft) Version May 2007 Table of Contents 1. INTRODUCTION SECTION 1: THE OHIM AS OFFICE OF ORIGIN 1. Examination and forwarding of international applications 1.1. Transmittal fee 1.2. Proper completion of the Form 1.3. Forwarding of the international application 2. Subsequent designations...»

«Корпус КаК языК: от масштабируемости К дифференциальной полноте Беликов В. И. (vibelikov@gmail.com) РГГУ, Москва, Россия Копылов Н. Ю. (Nikolay_Ko@abbyy.com) РГГУ; ABBYY, Москва, Россия Пиперски А. Ч. (apiperski@gmail.com) РГГУ, Москва, Россия Селегей В. П. (Vladimir_S@abbyy.com) РГГУ; МФТИ; ABBYY, Москва, Россия Шаров С. А....»

«Living Lab Research Landscape: Part II Yadira Alatriste1, Marco Ferruzca2, José Ma. Monguet1 Barcelona Tech (UPC), Barcelona, España, (yadira.alatriste, monguet.upc@gmail.com ) CyAD, UAM-Azcapotzalco, México, D.F. (mvfn@correo.azc.uam.mx) Abstract This work presents the results of an analysis and categorization of a set of papers about living labs published during 2006-2011. The aim was to build a deep understanding of the domain landscape of living lab research (D3LR) proposed in the past...»

«Brochure More information from http://www.researchandmarkets.com/reports/2971852/ Global and Chinese Anise Powder Flavor Industry, 2009-2019 Market Research Report Description: The 'Global and Chinese Anise Powder Flavor Industry, 2009-2019 Market Research Report' is a professional and in-depth study on the current state of the global Anise Powder Flavor industry with a focus on the Chinese market.The report provides key statistics on the market status of the Anise Powder Flavor manufacturers...»





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