Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung V-Modell Allgemeines Anwendung des V-Modells...

Transkript

1 Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung V-Modell Allgemeines Anwendung des V-Modells SCRUM-Modell Allgemeines Anwendung des SCRUM-Modells Fazit... 7 I

2 1 Problemstellung Als Projektleiter der Firma PortalSoft haben wir die Aufgabe ein passendes Vorgehensmodell für die Umsetzung des Gepäcktracking Portals auszuwählen. Die HebAb!Air wünscht eine Vorstellung und Gegenüberstellung der zwei am besten geeigneten Modelle, darunter ein traditionelles und ein agiles Softwareentwicklungsmodell. Wir haben uns hier für das V-Modell und das SCRUM-Modell entschieden, welche im Folgenden zuerst erläutert und dann auf den Case angewendet werden. Am Ende wird eine Empfehlung gegeben, welches Modell für den Case besser geeignet ist und ausgewählt werden sollte. 2 V-Modell 2.1 Allgemeines Das V-Modell stellt eine Weiterentwicklung des klassischen Wasserfall-Modells um den Aspekt der Qualitätssicherung dar. Insbesondere werden zu jeder Phase des Planungsmodells Anwendungsszenarien oder Testfälle konzipiert, die im späteren Testprozess eingesetzt werden. Der Unterschied zum Wasserfall-Modell liegt darin, dass das Modell nicht mehr stark sequenziell abläuft und die vorherige Phase komplett abgeschlossen sein muss. Zudem entfallen die Abnahmen, mit denen eine Phase abgeschlossen wird. Das Hauptproblem beim V-Modell besteht darin, dass gerade bei kleineren Projekten die Dokumentation, beispielsweise der Umfang der Planungsphase und die Dokumentation der Testfälle, sehr groß ist. Das V-Modell eignet sich somit besonders gut für Großprojekte, bei denen bereits vor Projektbeginn ein Großteil der Anforderungen bekannt und festgehalten sein muss. 1

3 Abbildung 1: V Modell Ablauf des V-Modells: - In der Anforderungsdefinition werden die Anforderungen, die die Software erfüllen muss, festgelegt und bereits Anwendungsszenarien für den finalen Abnahmetest erstellt. - Im Grobentwurf werden die grundlegenden Problemstellungen der Software analysiert und alternative Lösungsmöglichkeiten für diese Problemstellungen ermittelt. Aus dem Grobentwurf ergeben sich außerdem die Testfälle für den Systemtest. - Im Feinentwurf werden alle benötigten Module, Daten und Schnittstellen definiert und Testfälle für den Integrationstest abstrahiert. - In der Modulimplementierung erfolgt die eigentliche Programmierung der Software sowie die Gewinnung von Testdaten für den Modultest. Vorteile: Durch die Erweiterung um eine Qualitätssicherung werden bei großen und unüberschaubaren Projekten Risiken minimiert, die in ihrer Durchführung ansonsten bestehen würden. 2

4 Nachteile: Die große Zahl an Dokumenten, die in den einzelnen Phasen erstellt werden müssen, ist für kleine Projekte jedoch nicht sinnvoll, da der benötigte Aufwand zur Dokumentation hier keinen wirklichen Nutzen bringt. Ein weiterer Nachteil des Modells ist, dass die Anforderungen an die zu entwickelnde Software bereits vor Projektbeginn weitgehend bekannt sein müssen und Änderungen meist nur sehr kostenintensiv vorgenommen werden können. 2.2 Anwendung des V-Modells Anforderungsdefinition: Mögliche Anforderungen an das Gepäcktracking Portal stellen - die Statusabfrage für nicht-registrierte Kunden über das Webportal, - die Statusabfrage für registrierte Kunden (Bereich Kofferverfolgung) über das Webportal, - die automatische Benachrichtigung bei Statusänderung, - die Datenbank zur Speicherung der relevanten Informationen, - und das E- Mail Kontaktformular dar. Daraus ergibt sich zum Beispiel folgendes Anwendungsszenario: - Ein Kunde versucht durch die Eingabe der TAN im Webportal den Aufenthaltsort seines Koffers zu ermitteln. Grobentwurf: Eventuelle Problemstellungen könnten zum einen die Echtzeitanforderungen an das System darstellen oder mögliche Überlastbereiche, wenn viele Kunden gleichzeitig versuchen den Status ihres Koffers abzufragen. Als Testfälle können hier Lasttests benutzt werden. Feinentwurf: Das System besitzt eine Schnittstelle, die vom Unternehmen LogistikSoft eingerichtet wird und die Datenbank mit den relevanten Informationen versorgt. Die Module entsprechen grob denen in der Anforderungsdefinition genannten Anforderungen. 3

5 Testfälle für den Integrationstest stellen das Zusammenspiel mehrerer Module dar. Modulimplementierung: Umsetzung und Test der im Feinentwurf definierten Module. 3 SCRUM-Modell 3.1 Allgemeines Scrum ist ein Vorgehensmodell der agilen Softwareentwicklung. Es ist ein iterativer Prozess, der von einem sich schnell ändernden Umfeld und damit auch ändernden Anforderungen ausgeht und nach jedem Teilschritt ein lauffähiges System zur Verfügung stellen sollte. Der Fokus liegt sehr stark auf dem Entwicklungsteam, dessen Selbstorganisation, Kommunikation und ständige Weiterentwicklung. Scrum wird auch als leichter Managementprozess bezeichnet, da es keine Praktiken zur Softwareentwicklung enthält. Die verschiedenen Bestandteile des Modells sowie die feste Rollenverteilungen werden in Abbildung 2: SCRUM-Prozessmodell verdeutlicht und anschließend erläutert. Abbildung 2: SCRUM-Prozessmodell 4

6 Bestandteile: - Der Sprint ist das iterative Element des Modells, welches immer wieder durchlaufen wird und ungefähr 30 Tage andauern sollte. - Im Product Backlog werden alle Anforderungen, die im Endprodukt enthalten sein sollen, festgehalten. Die enthaltenen Anforderungen werden vom Product Owner verwaltet und priorisiert und jedes Teammitglied kann die Aufnahme weiterer Anforderungen beim Product Owner vorschlagen. - Der Sprint Backlog enthält alle Anforderungen die erfüllt sein müssen, um das Ziel des Sprints zu erfüllen. Während eines Sprints ist es nicht möglich weitere Anforderungen in den Sprint Backlog aufzunehmen, damit die Arbeit und die Selbstorganisation des Teams nicht gestört werden. - Das Daily-Scrum ist ein maximal 15-minütiges Meeting, das während der Sprint-Phase täglich durchgeführt wird, um das gesamte Team auf dem neusten Stand zu halten und Blockaden im Arbeitsablauf von Teammitgliedern zu beseitigen. - Im Sprint Review werden die Ergebnisse des Sprints dem Kunden und dem Product Owner vorgeführt. Der Kunde prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht oder ob Änderungen im Product Backlog vorgenommen werden müssen. - Der Sprint Retrospektive betrachtet die zurückliegende Sprint-Phase im Hinblick auf die Fragen Was war gut? und Was könnte verbessert werden? mit dem Ziel, Verbesserungen im Team zu erreichen und in einen Prozess ständiger Verbesserung zu gelangen. Rollenverteilung: - Der Product Owner legt das gemeinsame Ziel der Entwicklung fest. Er stellt das Budget zur Umsetzung der Ziele, verwaltet das Product Backlog und setzt Prioritäten für die darin enthaltenen Anforderungen. - Der Scrum Master sorgt in seiner eher passiven Management- Rolle dafür, dass die Grundsätze von Scrum im Projekt verwirklicht werden. Er leitet das Daily- 5

7 Scrum und fungiert als Coach für das Projektteam. Des Weiteren ist er für die Beseitigung von Hindernissen während der Sprints verantwortlich und er trifft Entscheidungen, wenn das Team dazu selbst nicht in der Lage ist. - Das Scrum Team organisiert sich während des Sprints selbst und trifft auch selbstständig Entscheidungen. Es sollte aus fünf bis maximal acht Personen bestehen und es sollten alle Fähigkeiten im Team vorhanden sein, um die Ziele des Sprints erfüllen zu können. Das Team schätzt außerdem die Aufwände der einzelnen Backlog Elemente und entscheidet unter Berücksichtigung der Prioritäten des Product Owners, welche Anforderungen des Backlogs im nächsten Sprint umgesetzt werden. Vorteile: Das Scrum-Modell besitzt eine einfache Struktur mit klar definierten Rollen. Es ist ein flexibler Entwicklungsprozess, in dem viel Wert auf die Veränderbarkeit des Produktes während der Entwicklungsphase gelegt wird. Durch die Selbstorganisation des Teams und dem Fokus auf die Kommunikation innerhalb des Teams werden insbesondere bei kleineren Projekten Effizienzvorteile erreicht. Nachteile: Die Anwendbarkeit des Modells auf große und komplexe Projekte ist nur sehr begrenzt möglich. Außerdem wird unterstellt, dass alle Mitarbeiter hoch-motiviert und an einem stetigen Verbesserungsprozess interessiert sind, was aber in der Praxis häufig nicht der Fall ist. Des Weiteren besteht das Risiko dominanter Teammitglieder, die den Prozess der Selbstorganisation stören ohne einen gleichwertigen Teil zur Problemlösung beizutragen. Das Modell setzt ein hohes Know-How und eine hohe Kommunikationsbereitschaft der Mitarbeiter voraus. Außerdem lassen sich Anforderungen nicht immer soweit unterteilen, dass nach einer Sprint-Phase ein lauffähiges Programm fertiggestellt ist. 6

8 3.2 Anwendung des SCRUM-Modells Da das Scrum-Modell auf eine umfangreiche Planung verzichtet, müssen zu Beginn lediglich die verschiedenen Rollen verteilt und die Anforderungen, die zu Beginn schon feststehen, in das Product Backlog übernommen werden. Das Product Backlog könnte beispielsweise folgende Einträge enthalten: - Statusabfrage für nicht-registrierte Kunden über das Webportal (Priorität hoch) - Statusabfrage für registrierte Kunden (Bereich Kofferverfolgung) über das Webportal (Priorität Mittel) - automatische Benachrichtigung bei Statusänderung (Priorität Mittel) - Datenbank zur Speicherung der relevanten Informationen (Priorität hoch) - E- Mail Kontaktformular (Priorität Mittel) Anschließend beschließt das Team unter Berücksichtigung der Prioritäten die Anforderungen für den Sprint Backlog. Die Anforderungen für einen Sprint könnten beispielsweise lauten: - Statusabfrage für nicht-registrierte Kunden über das Webportal o GUI entwerfen zur TAN-Eingabe o GUI entwerfen zur Anzeige des Kofferstatus o GUIs in HebAb!Air Homepage einbinden o Implementierung der dynamischen Webseiten o Datenbankabfrage implementieren o Verschlüsselung der Daten realisieren Es ist wichtig, dass die HebAb!Air aktiv am Entwicklungsprozess beteiligt ist und zwischen den einzelnen Sprints die Zwischenergebnisse begutachtet, da die Anforderungen im voraus noch nicht alle genau definiert sind. 4 Fazit Bei der Umsetzung des Gepäcktracking Portals für die HebAb!Air handelt es sich um ein mittelgroßes Projekt, bei dem die Anforderungen schon vor Projektbeginn relativ klar definiert sind. Da die größten Probleme und Unsicherheiten in der Umsetzung bei den Schnittstellen liegen und diese Aufgabe und damit auch die Risiken vom 7

9 Unternehmen LogistikSoft übernommen werden, ist unser Ziel relativ klar abgesteckt und es besteht wenig Gefahr bei der Entwicklung in die falsche Richtung zu geraten. Deshalb wird die Flexibilität während der Entwicklung nicht unbedingt benötigt. Da das Scrum-Modell eine hohe Qualifikation und Kommunikation innerhalb des Teams voraussetzt, die aber bei diesem Projekt nicht unbedingt in allen Bereichen benötigt wird, haben wir uns in diesem Case für ein abgeschwächtes V-Modell entschieden, wobei abgeschwächt bedeutet, dass das Vorgehensmodell nicht allzu dokumentgetrieben realisiert werden soll. Damit kann man dem Nachteil des V- Modells, dass es gerade bei kleinen Projekten zu viel Bürokratie beinhaltet, effektiv entgegenwirken. 8