Herunterladen von vtuloop.

com

Softwaretechnik [15CS42]

5. AGILE SOFTWAREENTWICKLUNG
5.1 Umgang mit Veränderung
Die Systemanforderungen ändern sich, während das Unternehmen, das das System beschafft, darauf reagiert.

Äußere Druckfaktoren und Managementprioritäten ändern sich.

Änderungen erhöhen die Kosten der Softwareentwicklung, da sie in der Regel bedeuten, dass Arbeit
Was abgeschlossen ist, muss neu gemacht werden. Das wird Nacharbeit genannt.

Es gibt zwei verwandte Ansätze, die verwendet werden können, um die Kosten für Nacharbeiten zu reduzieren:

1. Änderungsvermeidung, bei der der Softwareprozess Aktivitäten umfasst, die

mögliche Änderungen vorhersehen, bevor erhebliche Nacharbeit erforderlich ist. Zum Beispiel,
Ein Prototyp-System kann entwickelt werden, um einige Schlüsselfunktionen des Systems zu zeigen.

mit den Kunden. Sie können mit dem Prototyp experimentieren und ihn verfeinern.
Anforderungen vor der Verpflichtung zu hohen Softwareproduktionskosten.
2. Änderungs-Toleranz, bei der der Prozess so gestaltet ist, dass Änderungen vorgenommen werden können

zu relativ niedrigen Kosten untergebracht. Dies beinhaltet normalerweise irgendeine Form von

inkrementelle Entwicklung.
Es gibt 2 Möglichkeiten, mit Veränderungen und sich ändernden Systemanforderungen umzugehen.

1. Systemprototyping, bei dem eine Version des Systems oder eines Teils des Systems ist
schnell entwickelt, um die Anforderungen des Kunden und die Machbarkeit zu überprüfen
einige Designentscheidungen. Dies unterstützt die Vermeidung von Änderungen, da es den Benutzern ermöglicht, zu

Experimentieren Sie mit dem System vor der Lieferung und verfeinern Sie so Ihre Anforderungen.

2. Inkrementelle Lieferung, bei der Systeminkremente an den Kunden geliefert werden

für Kommentare und Experimente. Dies unterstützt sowohl die Vermeidung von Veränderung als auch

Änderungsbereitschaft. Es vermeidet das vorzeitige Festlegen auf Anforderungen für die

das gesamte System und ermöglicht es, Änderungen in spätere Inkremente zu integrieren.
relativ niedrige Kosten.

5.1.1 Prototyping
Ein Prototyp ist eine erste Version eines Softwaresystems, das zur Demonstration verwendet wird

Konzepte, Designoptionen ausprobieren und mehr über das Problem und seine möglichen
Lösungen.
Ein Softwareprototyp kann in einem Softwareentwicklungsprozess verwendet werden, um zu helfen
Änderungen antizipieren, die erforderlich sein könnten:

Prof. Mamatha E, Assist. Prof., Abt. für ISE, SVIT, Bengaluru Page 1
 herunterladen von vtuloop.com

Software Engineering [15CS42]

1. Im Anforderungsentwicklungsprozess kann ein Prototyp helfen mit der

Erhebung und Validierung von Systemanforderungen.
2. Im Systemdesignprozess kann ein Prototyp verwendet werden, um bestimmte
Softwarelösungen und zur Unterstützung des Benutzeroberflächendesigns.

Systemprototypen ermöglichen es den Nutzern, zu sehen, wie gut das System ihre Arbeit unterstützt.

Sie könnten neue Ideen für Anforderungen erhalten und Bereiche von Stärken und Schwächen finden in
Die Software. Sie können dann neue Systemanforderungen vorschlagen.
Ein Systemprototyp kann verwendet werden, während das System entworfen wird, um durchzuführen
Experimente entwerfen, um die Machbarkeit eines vorgeschlagenen Designs zu überprüfen.

Zum Beispiel kann ein Datenbankdesign prototypisiert und getestet werden, um zu überprüfen, ob es unterstützt.

effizienter Datenzugriff für die gängigsten Benutzeranfragen.

Ein Prozessmodell für die Prototypenentwicklung ist in Abbildung 5.1 dargestellt.

Abb. 5.1: Der Prozess der Prototypenentwicklung

Die Ziele des Prototypings sollten zu Beginn des Prozesses eindeutig festgelegt werden.
Diese könnten darin bestehen, ein System zu entwickeln, um die Benutzeroberfläche zu prototypisieren, ein System zu entwickeln

um funktionale Systemanforderungen zu validieren oder ein System zu entwickeln, um das zu demonstrieren

Machbarkeit der Anwendung für die Manager.

Der nächste Schritt im Prozess besteht darin, zu entscheiden, was hinein- und vielleicht mehr

Wichtig ist, was im Prototypensystem weggelassen werden soll.

Die letzte Phase des Prozesses ist die Prototypbewertung.
Entwickler stehen manchmal unter Druck von Managern, wegwerfbare Prototypen zu liefern.
insbesondere wenn es Verzögerungen bei der Lieferung der endgültigen Version der Software gibt.

Das ist jedoch normalerweise unweise:

Es könnte unmöglich sein, den Prototyp so abzustimmen, dass er nicht-funktionale Anforderungen erfüllt.

Anforderungen wie Leistung, Sicherheit, Robustheit und Zuverlässigkeit

Anforderungen, die während der Prototypentwicklung ignoriert wurden.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 2

 herunterladen von vtuloop.com

Softwaretechnik [15CS42]

2. Schnelle Veränderungen während der Entwicklung bedeuten unvermeidlich, dass der Prototyp ...

undokumentiert. Die einzige Entwurfsspezifikation ist der Prototypcode. Das ist nicht
gut genug für langfristige Wartung.
3. Die Änderungen, die während der Prototypentwicklung vorgenommen wurden, haben wahrscheinlich beeinträchtigt.

Die Systemstruktur. Das System wird schwierig und teuer zu warten sein.
4. Die organisatorischen Qualitätsstandards werden normalerweise für Prototypen gelockert.

Entwicklung
5.1.2 Inkrementelle Lieferung
Inkrementelle Lieferung (Abb. 5.2) ist ein Ansatz zur Softwareentwicklung, bei dem einige
Die entwickelten Inkremente werden dem Kunden geliefert und für die Nutzung bereitgestellt in einer

Betriebsumgebung. In einem inkrementellen Lieferprozess identifizieren die Kunden, in

Umreißen Sie die Dienstleistungen, die von dem System bereitgestellt werden sollen.

Abb. 5.2: Inkrementelle Lieferung

Sie identifizieren, welche der Dienstleistungen am wichtigsten und welche am wenigsten wichtig sind.

zu ihnen.
Sobald die Systeminkremente identifiziert wurden, die Anforderungen an die Dienstleistungen für
im ersten Inkrement bereitgestellt werden, sind im Detail definiert und dieses Inkrement ist

entwickelt.
Während der Entwicklung kann eine weitere Anforderungsanalyse für spätere Inkremente stattfinden.
aber Änderungen der Anforderungen für den aktuellen Inkrement werden nicht akzeptiert.

Die inkrementelle Lieferung hat eine Reihe von Vorteilen:

1. Kunden können die frühen Inkremente als Prototypen verwenden und Erfahrungen sammeln, die
informieren ihre Anforderungen für spätere Systemerweiterungen. Im Gegensatz zu Prototypen,

dies sind Teile des echten Systems, sodass es kein erneutes Lernen gibt, wenn das gesamte
Das System ist verfügbar.

Prof. Mamatha E, Assoziierte Professorin, Fachbereich ISE, SVIT, Bengaluru Page 3

 von vtuloop.com herunterladen

Software Engineering [15CS42]

2. Kunden müssen nicht warten, bis das gesamte System geliefert wird, bevor sie
darüber profitieren kann. Der erste Anstieg erfüllt ihre kritischsten
Anforderungen, damit sie die Software sofort nutzen können.
3. Der Prozess bewahrt die Vorteile der inkrementellen Entwicklung, da er
Sollte relativ einfach sein, Änderungen in das System zu integrieren.
4. Da die Dienstleistungen mit der höchsten Priorität zuerst geliefert werden und dann Inkremente folgen

Integriert erhalten die wichtigsten Systemdienste die meisten Tests. Dies

bedeutet, dass Kunden seltener auf Softwarefehler stoßen.
wichtige Teile des Systems.
Es gibt jedoch Probleme mit der inkrementellen Lieferung:
Die meisten Systeme benötigen eine Reihe grundlegender Einrichtungen, die von verschiedenen Teilen verwendet werden.

das System. Da die Anforderungen nicht im Detail definiert sind, bis ein Inkrement zu
Es kann schwierig sein, gemeinsame Einrichtungen zu identifizieren, die benötigt werden.
durch alle Fortschritte.

2. Iterative Entwicklung kann auch schwierig sein, wenn ein Ersatzsystem entwickelt wird.
entwickelt. Die Nutzer wünschen sich alle Funktionen des alten Systems und sind oft
nicht bereit, mit einem unvollständigen neuen System zu experimentieren. Daher, das Bekommen

Nützliche Kundenrückmeldungen sind schwierig.

3. Im inkrementellen Ansatz gibt es keine vollständige Systemspezifikation, bis

der finale Zuschlag ist festgelegt. Dies erfordert eine neue Form des Vertrags, die
Große Kunden wie Regierungsbehörden könnten es schwierig finden, ...
unterbringen.

5.2 Planungsorientierte und Agile Entwicklung

Agile Ansätze zur Softwareentwicklung betrachten Design und Implementierung als
die zentralen Aktivitäten im Softwareprozess.
Sie integrieren andere Aktivitäten wie die Anforderungserhebung und das Testen in
Entwurf und Implementierung.
In einem planorientierten Ansatz erfolgt die Iteration innerhalb von Aktivitäten mit formalen Dokumenten.
wurde verwendet, um zwischen den Phasen des Prozesses zu kommunizieren.

Zum Beispiel werden sich die Anforderungen weiterentwickeln und letztendlich eine Anforderung

Spezifikation wird erstellt.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 4

 herunterladen von vtuloop.com

Software Engineering [15CS42]

Dies ist dann ein Input für den Design- und Implementierungsprozess.
In einem agilen Ansatz erfolgt die Iteration über Aktivitäten. Daher sind die Anforderungen
und das Design wird gemeinsam entwickelt, statt separat
Ein planorientierter Softwareprozess kann inkrementelle Entwicklung und Lieferung unterstützen.

Es ist durchaus machbar, Anforderungen zuzuordnen und das Design sowie die Entwicklung zu planen.
Phase als eine Reihe von Inkrementen.
Ein agiler Prozess ist nicht zwangsläufig kodierungsorientiert und kann einige Designs hervorbringen.

Dokumentation.
Abb. 5.3 zeigt die Unterschiede zwischen plangetriebenen und agilen Ansätzen zur Systementwicklung.

Spezifikation

Abb. 5.3: Plan-gestützte und agile Spezifikation

5.3 Extreme Programming

In Extreme Programming werden Anforderungen als Szenarien (genannt Benutzer
Geschichten), die direkt als eine Reihe von Aufgaben implementiert werden.

Programmierer arbeiten paarweise und entwickeln Tests für jede Aufgabe, bevor sie den Code schreiben.

Alle Tests müssen erfolgreich ausgeführt werden, wenn neuer Code in das System integriert wird.
Abbildung 5.4 zeigt den XP-Prozess zur Erstellung eines Inkrements des Systems, das erstellt wird.
entwickelt.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 5

 Herunterladen von vtuloop.com

Softwaretechnik [15CS42]

Abb. 5.4: Der Release-Zyklus für Extreme Programming

Extreme Programming umfasst eine Reihe von Praktiken, die in Abb. 5.5 zusammengefasst sind, die

die Prinzipien agiler Methoden widerspiegeln:

Inkrementelle Entwicklung wird durch kleine, häufige Veröffentlichungen unterstützt.
System. Die Anforderungen basieren auf einfachen Kundenstories oder Szenarien, die
werden als Grundlage dafür verwendet, welche Funktionalität in eine
Systemincrement.
Die Einbindung der Kunden wird durch das kontinuierliche Engagement unterstützt.
Kunde im Entwicklungsteam. Der Kundenvertreter nimmt teil an
die Entwicklung und ist verantwortlich für die Definition von Akzeptanztests für die

System.
Menschen, nicht Prozesse, werden durch Pair Programming, kollektive unterstützt.
Eigentum des Systemcodes und ein nachhaltiger Entwicklungsprozess, der
beinhaltet keine übermäßig langen Arbeitszeiten.
Änderungen werden durch regelmäßige Systemveröffentlichungen an Kunden und einen Test-zuerst-Ansatz angenommen.

Entwicklung, Refactoring zur Vermeidung von Code-Degeneration und kontinuierlich

Integration neuer Funktionen.

Die Aufrechterhaltung von Einfachheit wird durch ständige Refaktorisierung unterstützt, die den Code verbessert.

Qualität und durch die Verwendung einfacher Designs, die zukünftige Entwicklungen nicht unnötig vorwegnehmen

Änderungen am System.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 6

 Herunterladen von vtuloop.com

Software-Engineering [15CS42]

Abbildung 5.5: Extreme-Programming-Praktiken

5.3.1 Testen in XP
XP beinhaltet einen Ansatz zum Testen, der die Wahrscheinlichkeit verringert, Fehler einzuführen.

nicht entdeckte Fehler in der aktuellen Version des Systems.

Die Hauptmerkmale des Testens in XP sind:
Testzuerst-Entwicklung
*Inkrementelle Testentwicklung aus Szenarien,
*Benutzereinbindung in die Testentwicklung und Validierung, und
Die Verwendung von automatisierten Testframeworks.

Abb. 5.6 ist eine verkürzte Beschreibung eines Testfalls, der entwickelt wurde, um zu überprüfen, dass
Die verschriebene Dosis eines Medikaments überschreitet nicht die bekannten sicheren Grenzen.

Prof. Mamatha E, Assistenzprofessor, Fachbereich ISE, SVIT, Bengaluru Page 7

 Laden Sie von vtuloop.com herunter

Software Engineering [15CS42]

Abbildung 5.6: Testfallbeschreibung für die Dosisüberprüfung

Die Rolle des Kunden im Testprozess besteht darin, Akzeptanztests zu entwickeln für
die Geschichten, die in der nächsten Version des Systems implementiert werden sollen.

Testautomatisierung ist entscheidend für die Tests zuerst Entwicklung.

Tests werden als ausführbare Komponenten geschrieben, bevor die Aufgabe implementiert wird.

Diese Testkomponenten sollten eigenständig sein und die Einreichung simulieren.

Eingabe, die getestet werden soll, und sollte überprüfen, ob das Ergebnis den Ausgabespezifikationen entspricht.

Ein automatisiertes Testframework ist ein System, das es einfach macht, ausführbare Tests zu schreiben.
und eine Reihe von Tests zur Ausführung einreichen.

Testgetriebene Entwicklung und automatisiertes Testen führen in der Regel zu einer großen Anzahl von Tests.
geschrieben und ausgeführt werden.

Dieser Ansatz führt jedoch nicht unbedingt zu einer gründlichen Programmtests.

Es gibt drei Gründe dafür:
Programmierer ziehen das Programmieren dem Testen vor und manchmal nehmen sie
Kurzbefehle beim Schreiben von Tests. Zum Beispiel können sie unvollständige Tests schreiben.

die nicht alle möglichen Ausnahmen überprüfen, die auftreten können.

2. Einige Tests können sehr schwierig inkrementell zu schreiben sein. Zum Beispiel in einem

Komplexe Benutzeroberfläche, es ist oft schwierig, Unit-Tests für den Code zu schreiben, der
implementiert die 'Anzeige-Logik' und den Workflow zwischen Bildschirmen.

Es ist schwierig, die Vollständigkeit einer Testreihe zu beurteilen. Obwohl es viele gibt
Von Systemtests kann der Testsatz möglicherweise keine vollständige Abdeckung bieten. Entscheidende Teile

des Systems möglicherweise nicht ausgeführt werden kann und somit ungetestet bleibt.

5.3.2 Paarprogrammierung
Eine weitere innovative Praxis, die in XP eingeführt wurde, ist, dass Programmierer arbeiten
in Paaren, um die Software zu entwickeln.

Prof. Mamatha E, Assoziierte Professorin, Fachbereich ISE, SVIT, Bengaluru Page 8

 Herunterladen von vtuloop.com

Software Engineering [15CS42]

Sie sitzen tatsächlich an derselben Arbeitsstation, um die Software zu entwickeln.

Die Verwendung von Pair Programming hat eine Reihe von Vorteilen:

Es unterstützt die Idee des kollektiven Eigentums und der Verantwortung für das System.
*Es fungiert als ein informeller Prüfprozess, da jede Codezeile von
mindestens zwei Personen. Code-Inspektionen und -Überprüfungen sind sehr erfolgreich in

Entdeckung eines hohen Prozentsatzes an Softwarefehlern.

Es unterstützt das Refactoring, das ein Prozess zur Verbesserung der Software ist.
Die Schwierigkeit, dies in einer normalen Entwicklungsumgebung umzusetzen, besteht darin, dass

Der Aufwand für die Überarbeitung wird für langfristige Vorteile aufgewendet. Eine Person, die

Praktiken des Refactorings können als weniger effizient beurteilt werden als die einesjenigen, der einfach

entwickelt weiter Code. Wo Pair-Programming und kollektive

Eigentum wird genutzt, andere profitieren sofort von der Umstrukturierung, sodass sie
werden wahrscheinlich den Prozess unterstützen.

5.4 Agiles Projektmanagement

Die Hauptverantwortung von Softwareprojektmanagern besteht darin, das Projekt zu verwalten, damit
dass die Software pünktlich und innerhalb des geplanten Budgets für das Projekt geliefert wird.
Sie überwachen die Arbeit der Software-Ingenieure und überwachen, wie gut die Software funktioniert.

Die Entwicklung schreitet voran.

Abb. 5.7 ist ein Diagramm des Scrum-Managementprozesses.

Abb. 5.7: Der Scrum-Prozess

Scrum schreibt die Anwendung von Programmierpraktiken wie Pair Programming nicht vor.
und testbasierte Entwicklung.
Es kann daher mit technischeren agilen Ansätzen wie XP verwendet werden, um bereitzustellen
ein Managementrahmen für das Projekt.
Es gibt drei Phasen im Scrum.

Prof. Mamatha E, Assistenzprofessor, Fachbereich ISE, SVIT, Bengaluru Page 9

 herunterladen von vtuloop.com

Softwaretechnik [15CS42]

Die erste Phase ist eine grobe Planungsphase, in der Sie die allgemeinen Ziele festlegen für
das Projekt und entwerfen die Softwarearchitektur.
Darauf folgt eine Serie von Sprintzyklen, bei denen jeder Zyklus ein Increment entwickelt.
des Systems.
Schließlich beendet die Projektabschlussphase das Projekt und schließt die erforderlichen ab.

Dokumentationen wie Systemhilfegerüste und Benutzerhandbücher und bewertet die Lektionen

aus dem Projekt gelernt.
Ein Scrum-Sprint ist eine Planungseinheit, in der die zu erledigende Arbeit bewertet wird, Funktionen
werden für die Entwicklung ausgewählt, und die Software wird implementiert.

Am Ende eines Sprints wird die abgeschlossene Funktionalität den Stakeholdern geliefert. Schlüssel

Die Merkmale dieses Prozesses sind wie folgt:

1. Sprints haben eine feste Dauer, normalerweise 2–4 Wochen. Sie entsprechen dem
Entwicklung einer Veröffentlichung des Systems in XP.
2. Der Ausgangspunkt für die Planung ist das Produkt-Backlog, das die Liste der Arbeiten ist.
während der Bewertungsphase des Sprints, dies ist zu erledigen.
prüft und Prioritäten sowie Risiken werden zugewiesen. Der Kunde ist eng
an diesem Prozess beteiligt und kann neue Anforderungen oder Aufgaben einführen.
Beginn jedes Sprints.
3. Die Auswahlphase umfasst das gesamte Projektteam, das mit dem arbeitet
Der Kunde kann die Merkmale und Funktionen auswählen, die entwickelt werden sollen während der

Sprint.
4. Sobald diese vereinbart sind, organisiert sich das Team, um die Software zu entwickeln.
Kurze tägliche Meetings, an denen alle Teammitglieder teilnehmen, werden abgehalten, um den Fortschritt zu überprüfen.

und falls nötig, die Arbeit neu priorisieren.

5. Am Ende des Sprints wird die geleistete Arbeit überprüft und präsentiert an
Stakeholder. Der nächste Sprintzyklus beginnt dann.
Vorteile:
Das Produkt wird in eine Reihe von handhabbaren und verständlichen
Stücke.
*Instabile Anforderungen halten den Fortschritt nicht auf.

Das gesamte Team hat Sichtbarkeit auf alles und folglich das Team
Die Kommunikation hat sich verbessert.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 10

 herunterladen von vtuloop.com

Software Engineering [15CS42]

*Kunden sehen die pünktliche Lieferung von Inkrementen und erhalten Feedback darüber, wie die
Produkt funktioniert.

Das Vertrauen zwischen Kunden und Entwicklern wird aufgebaut und eine positive Kultur.
wird geschaffen, in dem jeder erwartet, dass das Projekt erfolgreich ist.

5.5 Skalierung agiler Methoden

Agile Methoden wurden für den Einsatz durch kleine Programmierteams entwickelt, die arbeiten konnten

gemeinsam im selben Raum sein und informell kommunizieren.

Agile Methoden wurden daher hauptsächlich für die Entwicklung von kleinen und
mittelgroße Systeme.
Die Entwicklung großer Softwaresysteme unterscheidet sich von der Entwicklung kleiner Systeme in einem
Anzahl der Möglichkeiten:

Große Systeme sind normalerweise Sammlungen separater, kommunizierender Systeme.

wo separate Teams jedes System entwickeln. Häufig sind diese Teams
In verschiedenen Orten zu arbeiten, manchmal in verschiedenen Zeitzonen. Es ist praktisch
Es ist unmöglich, dass jedes Team einen Überblick über das gesamte System hat.

Große Systeme sind 'Bestandsysteme', das heißt, sie beinhalten und interagieren mit einem
Anzahl der vorhandenen Systeme. Viele der Systemanforderungen betreffen
Mit dieser Interaktion und so eignen sie sich nicht wirklich für Flexibilität und
inkrementelle Entwicklung
* Wo mehrere Systeme integriert sind, um ein System zu schaffen, ist ein erheblicher Teil
Die Entwicklung bezieht sich eher auf die Systemkonfiguration als auf die ursprüngliche
Code-Entwicklung. Dies ist nicht unbedingt mit inkrementellen Methoden kompatibel.

Entwicklung und häufige Systemintegration.

Große Systeme und ihre Entwicklungsprozesse sind oft eingeschränkt durch
äußere Regeln und Vorschriften, die die Art und Weise einschränken, wie sie entwickelt werden können, die

bestimmte Arten von Systemdokumentationen erfordern, dass sie erstellt werden, usw.

*Große Systeme haben eine lange Beschaffungs- und Entwicklungszeit. Es ist schwierig, um
kohärente Teams aufrechterhalten, die über das System in diesem Zeitraum Bescheid wissen, da,

Inevitabel ziehen die Menschen weiter zu anderen Jobs und Projekten.

*Große Systeme haben in der Regel eine vielfältige Gruppe von Interessengruppen. Zum Beispiel Krankenschwestern.

und Administratoren können die Endbenutzer eines medizinischen Systems sein, aber die Führungskräfte

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 11

 von vtuloop.com herunterladen

Software Engineering [15CS42]

Medizinisches Personal, Krankenhausmanager usw. sind ebenfalls Stakeholder im System. Es ist

praktisch unmöglich, all diese verschiedenen Interessengruppen einzubeziehen in die
Entwicklungsprozess.
Es gibt zwei Perspektiven zur Skalierung agiler Methoden:
1.Ein ‚Skalierung‘-Perspektive, die sich mit der Anwendung dieser Methoden beschäftigt für
Entwicklung großer Softwaresysteme, die nicht von einem kleinen Team entwickelt werden können.

2. Eine 'Scaling Out'-Perspektive, die sich mit der Frage beschäftigt, wie agile Methoden

in einer großen Organisation mit vielen Jahren Software eingeführt werden

Entwicklungserfahrung.
Es ist aus mehreren Gründen schwierig, agile Methoden in großen Unternehmen einzuführen:
*Projektmanager, die keine Erfahrung mit agilen Methoden haben, könnten sein
widerwillig, das Risiko eines neuen Ansatzes zu akzeptieren, da sie nicht wissen, wie dies

wird ihre jeweiligen Projekte beeinflussen.

*Große Organisationen haben oft Qualitätsverfahren und Standards, die alle

Projekte sollten folgen und aufgrund ihrer bürokratischen Natur, diese
sind wahrscheinlich inkompatibel mit agilen Methoden. Manchmal sind dies
unterstützt durch Software-Tools (z. B. Anforderungsmanagement-Tools) und die Verwendung
Dieses Werkzeug ist für alle Projekte vorgeschrieben.
*Agile Methoden scheinen am besten zu funktionieren, wenn die Teammitglieder ein relativ hohes Maß an

Fähigkeitsniveau. In großen Organisationen wird es jedoch wahrscheinlich ein breites Spektrum geben
Fächer von Fähigkeiten und Fertigkeiten, und Menschen mit niedrigeren Fertigkeitsniveaus sind möglicherweise nicht

effektive Teammitglieder in agilen Prozessen.

Es könnte kulturelle Widerstände gegen agile Methoden geben, insbesondere in denen
Organisationen, die eine lange Geschichte in der Nutzung konventioneller Systeme haben

Ingenieurprozesse

5.6 Das Agile Manifest: Werte und Prinzipien

Werte
Individuen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Kundenzusammenarbeit über Vertragsverhandlungen
Auf Veränderungen reagieren statt einem Plan zu folgen

Prof. Mamatha E, Assoziierte Professorin, Fachbereich ISE, SVIT, Bengaluru Page 12

 Herunterladen von vtuloop.com

Software Engineering [15CS42]

Prinzipien:
Die höchste Priorität besteht darin, den Kunden durch frühzeitige und kontinuierliche Zufriedenheit zu gewährleisten.

Lieferung wertvoller Software

*Willkommen, sich ändernde Anforderungen, sogar spät in der Entwicklung. Agile Prozesse
Nutzen Sie den Wandel für den Wettbewerbsvorteil der Kunden
Liefern Sie häufig funktionierende Software, von ein paar Wochen bis zu ein paar
Monate, mit einer Präferenz für den kürzesten Zeitraum
Geschäftsleute und Entwickler müssen täglich zusammenarbeiten.
Projekt.
Schaffe Projekte rund um motivierte Einzelpersonen. Gib ihnen die Umgebung und
die Unterstützung, die sie brauchen, und vertrauen ihnen, die Arbeit zu erledigen

Die effizienteste und effektivste Methode zur Übermittlung von Informationen an und
Innerhalb eines Entwicklungsteams ist das persönliche Gespräch
Funktionierende Software ist das wichtigste Maß für den Fortschritt

Agile Prozesse fördern die nachhaltige Entwicklung. Die Sponsoren, Entwickler

und Benutzer sollten in der Lage sein, unendlich lange ein konstantes Tempo beizubehalten

Ständige Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität
Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist unerlässlich.

Die besten Architekturen, Aufgaben und Designs entstehen aus selbstorganisierenden

Teams.
*In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann, dann
stimmt seine Verhaltensweisen ab und passt sie entsprechend an.

Prof. Mamatha E, Assistenzprofessorin, Fachbereich ISE, SVIT, Bengaluru Page 13