AUSWAHL EINES VORGEHENSMODELLS IM RAHMEN DER CASE STUDY HEBAB

Transkript

1 Seite I Abgabe: LOGISTIKSOFT AUSWAHL EINES VORGEHENSMODELLS IM RAHMEN DER CASE STUDY HEBAB Management von Softwareprojekten Case 3b Bearbeitet von Nadine Fox Simon Hansen Stefanie Hontheim

2 Seite II Inhalt Inhalt... II 1. Aufgabenstellung Zielsetzung Vorgehensmodell 1: V-Modell Historie Das Modell Vor- und Nachteile des Modells Anwendung des V-Modells auf das LogistikSoft-Projekt Vorgehensmodell 2: Scrum Historie Das Modell Vor- und Nachteile des Modells Anwendung des Scrum-Modells auf das LogistikSoft-Projekt Wahl des Vorgehensmodells... 10

3 Seite 1 1. Aufgabenstellung Als Projektleiter der Firma LogistikSoft ist es Ihre Aufgabe zunächst ein passendes Vorgehensmodell auszuwählen anhand dessen Sie das Projekt der Logistik-Schnittstelle planen können. Da Sie derzeit noch indifferent sind, was die Auswahl des geeigneten Modells angeht erstellen Sie zwei Modelle, die Sie auf die Problemstellung anwenden. Im Anschluss vergleichen Sie die gewählten Modelle. Entscheiden Sie sich auf der Basis Ihres Vergleichs für eines der Modelle und begründen Sie ihre Wahl. Geben Sie zu jedem Teilschritt an, was zu tun ist, sowie ein zum Anwendungsfall passendes Beispiel, welches als mögliches Ergebnis jeder Phase verwendet werden kann. 2. Zielsetzung Die Zielsetzung unserer Aufgabe besteht darin, ein geeignetes Vorgehensmodell für eine Software-Entwicklung zu finden. Zur Auswahl stehen zwei Modelle: Das V-Modell und Scrum. Beide Modelle werden auf die Aufgabenstellung angewendet und am Ende entscheiden wir uns für das am geeignetsten System zur Entwicklung der Software von LogistikSoft. Dabei setzt die Software genau am Datenaustausch zwischen den Scannern der Flughäfen bzw. Fluggesellschaften und der Schnittstelle, die für PortalSoft bereit gestellt wird, an. Aufgabe der Software ist es, die ankommenden Daten der Flughäfen bzw. der Fluggesellschaften in eine einheitliche Form zu transformieren und für die PortalSoft in geeigneter Weise bereit zu stellen. In der Informatik wird ein solcher Prozess auch ETL-Prozess genannt. Dieser beinhaltet die Extraktion der Daten aus einer Datenquelle, die Transformation der Daten und das Laden der Daten in eine geeignete Zieldatenbank. Darum wird LogistikSoft in ihrer Software verschiedene Module einsetzen, die genau diese Arbeitsbereiche der Extraktion, der Transformation und des Ladens behandeln. Wir nehmen an, es gibt nur vier unterschiedliche Scanner-Hersteller und somit müssen nur vier unterschiedliche Module erstellt werden, die die verschiedenen Daten der Scanner in eine einheitliche Form transformieren. Die harmonisierten und normalisierten Daten werden schließlich in die Schnittstelle in Form einer Datenbank übertragen. Abbildung 1 gibt einen Überblick über das in dieser Arbeit behandelte Aufgabengebiet:

4 Seite 2 Kunde Gepäckaufgabe Schnittstelle Daten Modul Scanner A Scanner Check-In Weg durch den Flughafen Daten Daten Modul Scanner B Modul Scanner C Modul Scannerzuordnung Flughafeninterne Scanner Scanner Rollfeld/Flugzeug Nächster / Ziel- Flughafen Gepäckstück wird eingeladen Gepäckstück wird befördert Daten Modul Scanner D Gepäckband Gepäckstück wird ausgegeben Zieldatenbank Datenaufbereitung Datenquellen Laden Transformation Extraktion Abbildung 1: Anwendung des ETL-Konzept auf die Aufgabenstellung Das erste Modul behandelt die Extraktion, d.h. die Bearbeitung der Daten aus den Datenquellen der Flughäfen. Ein nächstes Modul harmonisiert diese Daten, gleicht sie auf eine einheitliche Form ab und - sofern notwendig - aggregiert diese. Alle Daten müssen in diesem Modul auf die dritte Normalform gebracht werden. Hier wird also die Transformation erreicht. Ziel der Anwendung soll sein, alle verfügbaren Daten in einer Acid-Datenbank zu speichern. Im Modul Datenbank werden alle Daten harmonisiert, aggregiert und in der dritten Normalform bereit gestellt. Diese Datenbank soll damit als Schnittstelle zum Unternehmen PortalSoft dienen, mit dem der Datenaustausch, das Laden erfolgen soll. Damit das System möglichst ausfallsicher ist, gibt es ein weiteres Modul Reservedatenbank innerhalb der Software. Hier werden parallel alle ankommenden Datenbanken extern gespeichert, damit im Falle eines Ausfalls der Datenbank die PortalSoft auf die Reservedatenbank zugreifen kann.

5 Seite 3 3. Vorgehensmodell 1: V-Modell 3.1 Historie Die Aufgabe des V-Modells ist das Planen und Durchführen von Entwicklungsprojekten. Seinen Ursprung hat das V-Modell bei Barry Boehm im Jahr Die Namensgebung des V-Modells ist zum einen auf den Begriff Vorgehen (Vorgehensmodell) und zum anderen auf seine V- Förmige Darstellung zurückzuführen. Erste V-Modelle wurden in Deutschland für IT-Projekte, die von der öffentlichen Hand ausgeschrieben wurden, entwickelt. Heutzutage ist das V- Modell eine weitverbreitete Variante der Projektentwicklung, die zudem in der Privatwirtschaft zur Anwendung kommt. Das V-Modell ist in seinem Lebenszyklus bisher zwei Mal modifiziert worden. Im Jahr 1997 wurde es zum V-Modell 97 weiter entwickelt und im Jahr 2005 zum V-Modell XT. XT steht hierbei für Extreme Tailoring und soll somit für sämtliche individuellen Bedürfnisse zuschneidbar sein. Neben der Anpassung der individuellen Bedürfnisse wurden der Auftraggeber sowie eine stärkere Modularisierung und Orientierung zu den agilen Ansätzen in das Modell hinzugefügt. 3.2 Das Modell Zeit (1) Anforderungsdefinition Anwendungsszenarien (8) Abnahmetest Validierung (2) Grobentwurf Testfälle (7) Systemtest Details (3) Feinentwurf Testfälle (6) Integrationstest Verifikation (4) Modulimplementierung Testfälle (5) Modultest Abbildung 2: Das V-Modell Beim V-Modell werden schrittweise Stufen durchlaufen, die jeweils für spezielle Phasen im Produktentwicklungsbereich stehen (vgl. Abbildung 2). Die Stufen können dabei zyklisch oder iterativ durchlaufen werden. Das V-förmige Modell ist so konzipiert, dass auf der absteigenden linken Hälfte des V-Modells (Stufen 1 bis 4) die Entwicklung des Produkts im Mittelpunkt steht. Auf der aufsteigenden rechten Seite werden diese Entwicklungsschritte verifiziert und validiert. Dabei ist es nötig, bei jedem Schritt von 1 bis 4 Anwendungsszenarien bzw. Testfälle zu modulieren, die in den Testphasen von 5 bis 8 durchgeführt werden. Somit entsteht ein

6 Seite 4 Abhängigkeitsverhältnis zwischen Entwicklungsphase und Testphase, wobei immer Abhängigkeitspaare entstehen. Beispiel: Im ersten Schritt der Anforderungsdefinition werden Anwendungsszenarien für den Abnahmetest (Schritt 8) erstellt, die im Schritt 8 den Test erleichtern. Somit müssen stets genaue Dokumentation und vorausschauendes Denken gewährleistet sein. Zudem besteht ein kausales Abhängigkeitsverhältnis zwischen jedem Schritt und seinem Nachfolgeschritt. Ein Schritt sollte erst beendet werden, bevor man auf eine nächste Stufe gelangt. Dies soll allerdings nicht heißen, dass es nicht möglich ist, eine Stufe zu wiederholen. Wenn in einem Schritt Fehler einer vorherigen Stufe bekannt werden, ist es jederzeit möglich und sogar notwendig, für das Beheben des Fehlers eine Stufe wiederaufzunehmen. 3.3 Vor- und Nachteile des Modells Nicht nur die reine Softwareentwicklung, sondern das komplette Projekt wird durch das V- Modell abgedeckt. Die Aktivitäten sowie Ergebnisse (Produkte) und Zustände der Produkte werden beim V-Modell sehr genau definiert. Ein Vorteil ist, dass das V-Modell eine detaillierte Darstellung der Vorgehensbausteine Projektmanagement, Qualitätssicherung, Konfigurationsmanagement und Systemerstellung bereitstellt. Das V-Modell ist zudem ein generisches Vorgehensmodell, das an verschiedene Projekte anpassbar ist. Durch Tailoring ist das Modell für verschiedene Anwendungen nutzbar. Während für kleine, überschaubare Projekte das Wasserfallmodell geeignet sein kann, ist es für große Projekte unzureichend; vor allem weil der Test erst zu Ende erfolgt, was bei einem Projekt von großem Umfang zu erheblichen Problemen führen kann. Das V-Modell ergänzt das Wasserfallmodell um Aspekte der Qualitätssicherung. Es ist daher für große Projekte mit hohem Qualitätsanspruch gut geeignet. Durch die Verifikation wird sichergestellt, dass das Softwareprodukt mit der Spezifikation übereinstimmt. Außerdem wird durch die Validierung geprüft, ob sich das Produkt für den Einsatzzweck eignet. Es besteht eine Trennung zwischen konstruktiven und prüfenden Aktivitäten. Fehler, die in einer Konstruktionsphase unterlaufen, lassen sich am einfachsten in der ihr zugehörenden Prüfphase finden. Während das V-Modell gut für große Projekte geeignet ist, ist es bei kleinen und mittleren Projekten mit einem zu großen bürokratischem Aufwand verbunden. Bei kleinen Projekten werden vor allem die hohen Anforderungen an die Dokumentation als Problem angesehen.

7 Seite Anwendung des V-Modells auf das LogistikSoft-Projekt Um die Software für die Fluggesellschaft HebAb zu erstellen, wenden wir an dieser Stelle das V-Modell als Vorgehensmodell an. Dafür werden in einem ersten Schritt die Anforderungen an die zu programmierende Software und die nötigen Rahmenbedingungen definiert. Die Anforderungen an die Rahmenbedingungen wurden bereits im vorherigen Case definiert. So müssen Scanner an den beteiligten Flughäfen installiert sein und die Bereitstellung der Daten sicher gestellt sein. Als Anforderungen an die Software gelten die in Abschnitt 2 genannten Aspekte (ETL-Modell). Parallel werden Anwendungsszenarien entwickelt, die den späteren Abnahmetest erleichtern. Hierzu werden im Laufe eines Zeitraums von drei Monaten zufällig Gepäckstücke gesondert markiert und von den Scannern erfasst. Das Ziel des Tests ist es schließlich, dass sich sämtliche ausgewählte Gepäckstücke zu jedem Zeitpunkt in der Datenbank mit der richtigen Zuordnung wieder finden. In einem zweiten Schritt werden die Anforderungsdefinitionen präzisiert und zu einem Grobentwurf zusammengefasst. Da es vier unterschiedliche Scannertypen (Scanner A bis D) gibt, muss zunächst ein Modul Scannerzuordnung die Daten an ein weiteres Modul Scanner A, Scanner B, Scanner D übermitteln. In den jeweiligen Scanner-Modulen werden die Daten aufbereitet. Wie die Aufbereitung konkret aussieht, wird im Feinentwurf erklärt. Die aufbereiteten Daten werden in die finale Datenbank eingespeist. Diese bildet die Schnittstelle für den Zugriff von PortalSoft. Analog müssen Testfälle generiert werden, die im siebten Schritt für den Systemtest erforderlich sind. Für jeden Scannertyp wird jeweils ein Koffer auf die Reise geschickt und geprüft, ob diese Daten korrekt vom Scanner erfasst werden und in richtiger Form an die Datenbank weitergeleitet und dort gespeichert werden. Im Feinentwurf der dritte Schritt des V-Modells werden die Vorstellungen über die Software konkretisiert. Im Modul Scannerzuordnung kommen die Daten der verschiedenen Schnittstellen an den Flughäfen an und werden an das jeweils korrekte Scanner-Modul weitergeleitet. Dabei ist zu beachten, dass jedes Gepäckstück auf dem Weg vom Check-In zum Gepäckband des Zielflughafens mehrmals gescannt wird und jeweils unterschiedliche Daten weitergeleitet werden. Je nach Scanner-Typ werden diese Daten in einer unterschiedlichen Reihenfolge und unterschiedlichen Formaten gesendet. Aufgabe des Moduls Scannerzuordnung ist es daher, anhand der Daten den Scanner-Typ zu erkennen und an das korrekte Folgemodul weiterzuleiten. In den einzelnen Scanner-Modulen werden die erhaltenen Daten verarbeitet. Im Laufe der Verarbeitung werden die Daten sowohl harmonisiert, normalisiert als auch aggregiert. Im Anschluss daran werden die aufbereiteten Daten an das Modul Datenbank weitergeleitet. Bei diesem Modul handelt es sich um eine Acid-Datenbank. Damit PortalSoft auf die Datenbankschnittstelle zugreifen kann, müssen die Softwarelösungen von PortalSoft und LogistikSoft aufeinander zugeschnitten sein. PortalSoft hat die Datenbank wie folgt definiert: Personal_ID TAN Gepäck_ID CheckIn Beladung Entladung Kofferband A5G Trier Abbildung 3: Aufbau der Datenbank Ort Zeit Flugnummer Zeit Ort Zeit Ort Zeit 06:00/ KL :00/ Amerstamschiphol 08:30/ Band 1 09:00/

8 Seite 6 Es ist wichtig, sich mit PortalSoft noch im Laufe der Anforderungsdefinitionen und der Entwurfsphasen optimal abzustimmen, damit Redundanzen in der Datenbank vermieden werden. Dabei kann sich obiger Entwurf noch verändern. Es ist zudem vorgesehen, eine Reservedatenbank zur Verfügung zu stellen, die im Falle eines Stromausfalls oder anderen Problemen die Schnittstelle zu PortalSoft darstellt. Hierfür muss es ein letztes Modul Reservedatenbank entworfen werden. Im Abschnitt des Feinentwurfs müssen wiederum Testfälle kreiert werden, die sich auf den Integrationstest im sechsten Schritt beziehen. Dabei muss das Zusammenwirken der einzelnen Module getestet werden. Im nächsten Schritt der Modulimplementierung werden schließlich die verschiedenen Module programmiert. Gleichzeitig werden Testfälle für den Modultest konzipiert. Dies stellt den nächsten Schritt im V-Modell dar. Die Module müssen hier unter anderem auf Korrektheit, Robustheit, Effizienz und Konsistenz getestet werden. Auf dieser Stufe wird die Validierung eingeleitet. Sie befindet sich im aufsteigenden, rechten Ast des V-Modells. Das weitere Vorgehen im V-Modell sieht die Validierung und Verifizierung der vorherigen Abschnitte vor. Dabei werden nacheinander die verschiedenen, vorher definierten Testfälle abgearbeitet. 4. Vorgehensmodell 2: Scrum 4.1 Historie Im Gegensatz zum V-Modell gehört das Vorgehensmodell Scrum zu den agilen Modellen. Agile Modelle sind sehr viel besser an das jeweilige Projekt anpassbar, da sie keine strikte zeitliche Abfolge mit starren Vorschriften implizieren, sondern der Projekterfolg maßgeblich vom Wissen und Können der beteiligten Personen abhängt. Durch die Entwicklung neuartiger Vorgehensmodelle in den 1980er Jahren wollte man Abstand nehmen von übermäßiger Dokumentation und der damit verbundenen Bürokratie hin zu kreativen, innovativen Methoden zur Projektentwicklung. Die Zeitschrift Harward Business Review nannte die agilen Modelle einen Rugby-Ansatz und erklärte den Ansatz wie folgt: 1986 in "The New New Product Development Game": Die ( ) "Staffellauf-Vorgehensweise" in der Produktentwicklung ( ) gerät unter Umständen in Konflikt mit dem Ziel maximaler Geschwindigkeit und Flexibilität. Stattdessen könnte ein ganzheitlicher "Rugby-Ansatz" - in welchem ein Team versucht, Wege als Einheit zurückzulegen und dabei den Ball hin- und herspielt - den Anforderungen des heutigen Wettbewerbs dienlicher sein. Scrum wurde in den frühen 1990ern von Ken Schwaber, Jeff Sutherland und Mike Beedle erdacht. In Wicked Problems, Righteous Solutions von DeGrace und Stahl wurde Scrum das erste Mal in Zusammenhang mit der Software-Entwicklung gebracht. Heute arbeiten einige Firmen mit dieser Methode. Google zum Beispiel ließ sich Scrum von Jeff Sutherland persönlich erklären.

9 Seite Das Modell Das Scrum-Modell kann für das Softwareengineering angewendet werden. Im Modell wird zwischen drei verschiedenen Rollen unterschieden. Zum Einen gibt es den Product Owner, welcher den Auftraggeber darstellt. Dieser gibt die Anforderungen vor und analysiert die Umsetzung seines Zielsystems. Mögliche überprüfbare Anforderungen sind Funktionalität, Benutzbarkeit, Performanz und Qualität. Zum Anderen gibt es den Scrum Master, der die Verantwortung für die Umsetzung des Projektes trägt und gleichzeitig die gute Seele innerhalb des Entwicklungsteams darstellt. Er ist weniger als Chef im Scrum-Modell zu sehen sondern mehr als Mittelsmann mit offenem Ohr für Probleme, die er aus dem Weg zu räumen versucht. Als dritte Rolle gibt es die Rolle des Teams, wobei das Team für die Umsetzung der Anforderungen eingesetzt wird. Dem Team kommt dabei ein sehr hohes Maß an Selbstverantwortung und Initiative zu. Anders als in vielen anderen Formen des Teamworks gibt es keinen wirklichen Chef oder Teamleiter, sondern verschiedene Experten innerhalb eines Teams mit gleichen Rechten und Pflichten. In einigen Literaturquellen wird zudem zwischen Pigs und Chicken unterschieden. Der Scrum-Prozess besteht aus verschiedenen Schritten: Abbildung 4: Das Scrum-Modell Im Product-Backlog werden in einem ersten Schritt die Funktionen des zu entwickelnden Produkts dargelegt. Das heißt, es werden die Anforderungen, die der Kunde an das Produkt hat, niedergeschrieben. Die einzelnen Anforderungen werden anschließend priorisiert. Hoch positionierte Anforderungen werden im Gegensatz zu den niedrig positionierten Anforderungen sehr detailliert beschrieben. Die einzelnen Elemente des Product-Backlogs müssen vor jedem Sprint neu bewertet werden. Das heißt, das Product-Backlog wird kontinuierlich weiterentwickelt. Dabei können Elemente entfernt, hinzugefügt oder neu priorisiert werden.

10 Seite 8 Im zweiten Schritt, während der Sprint-Planung, wird für den bevorstehenden Sprint aus dem Product-Backlog das Sprint-Backlog erstellt. Das Team wählt zusammen mit dem Product Owner die hoch priorisierten Anforderungen aus, die im nächsten Sprint umgesetzt werden sollen. Das Sprint-Backlog enthält also eine Liste von Aufgaben, die erforderlich sind, um die für den Sprint ausgewählten Teile des Product Backlogs in auslieferbare Software umzusetzen. In einem dritten Schritt wird der Sprint gestartet. Der Entwicklungszyklus des Scrum-Modells besteht aus verschiedenen Sprints, die eine feste Dauer von circa 30 Tagen haben. Jeden Tag findet zu einem festen Zeitpunkt ein Daily Scrum statt. Während jedes Daily Scrums werden die folgenden drei Fragen beantwortet: - Was habe ich seit dem letzten Daily Scrum getan? - Was hat mich dabei gehindert? - Was werde ich bis zum nächsten Daily Scrum tun? Der Teilnehmerkreis beim Daily Scrum wird unterschieden in Chicken und Pigs. Pigs sind Projektmitarbeiter, die in diesem Meeting befragt werden. Chicken sind Zuhörer wie bspw. der Auftraggeber oder andere mittelbar Beteiligte. Am Ende des Sprints wird der Sprint-Review durchgeführt. Im Sprint-Review wird das Ergebnis des Sprints dem Kunden präsentiert, der eventuell Änderungswünsche äußert, die dann im Product-Backlog dokumentiert werden. Im Anschluss wird in der Sprint-Retrospektive das Vorgehen analysiert und Verbesserungsmöglichkeiten identifiziert. Dazu werden zwei Fragen beantwortet: - Was haben wir gelernt? - Was lässt sich verbessern? Die Antworten werden gesammelt und im nächsten Sprint umgesetzt. 4.3 Vor- und Nachteile des Modells Im Gegensatz zum V-Modell, existieren beim Scrum sehr diverse Ansichten über die Vor- und Nachteile dieses Modells wurden im "Manifesto for Agile Software Development" 4 Fundamentalprinzipien für agile Entwicklungskonzepte definiert: - Individuen und Interaktion gelten mehr als Prozesse und Tools. - Funktionierende Programme gelten mehr als ausführliche Dokumentationen. - Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. - Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

11 Seite 9 Diese Punkte werden als positive Aspekte des Scrum angesehen. Nichtsdestotrotz werden sie von einigen als unrealistisch und in der Praxis schwer umsetzbar erachtet. Als Vorteil von Scrum wird die Verbesserung von Kunden- und Teamzusammenarbeit angesehen. Hinzu kommt, dass Transparenz über den aktuellen Stand der Entwicklung herrscht. Auftretende Fehler oder Änderungen in den Rahmenbedingungen werden durch kontinuierliche Anpassungen berücksichtigt sodass eine hohe Flexibilität gewährleistet ist. Als ein weiterer Vorteil des Scrum wird genannt, dass keine Bürokratie herrscht und keine unnötige Dokumentation erstellt werden muss. Wobei natürlich zu bedenken ist, dass Dokumentation unerlässlich ist, um z.b. eine spätere Wartung zu ermöglichen. Auch eine Selbstorganisation des Teams ist schwer zu erreichen. Dominante Teamplayer können dies unter anderem dadurch verhindern, indem sie Aufgaben eigenmächtig zuteilen. Es wird außerdem vorausgesetzt, dass alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können. Tatsächlich verfügen aber nicht immer alle Teammitglieder über die benötigten Qualifikationen. Ein weiterer Nachteil ist, dass aufgrund des engen Zeitrahmens unter Umständen zu wenig Zeit für Tests zu Verfügung steht, wodurch die Qualität des Endprodukts leidet. 4.4 Anwendung des Scrum-Modells auf das LogistikSoft-Projekt Weitergehend wird die zu programmierende Software für die HebAb Fluggesellschaft anhand des Scrum-Modells beschrieben. Zuerst müssen im Product Backlog die bereits vorher definierten Rahmenbedingungen bzw. Anforderungen an die Software aufgeschrieben werden. Dazu gehören Scanner an den jeweiligen Flughäfen sowie die Bereitstellung der eingescannten Daten. Die zu programmierende Software und deren Anforderungen wurden bereits im Abschnitt 2 (ETL-Modell) erklärt. Im Product Backlog werden die wichtigsten Anforderungen priorisiert und in Aufwand geschätzt. Es ergibt sich daher folgende Reihenfolge: 1. Modul Datenbank/ Schnittstelle Dauer: ein Sprint, ca. 30 Tage 2. Modul Scannerzuordnung Dauer: ½ Sprint, ca. 15 Tage 3. Module Scanner A, Scanner B, und Scanner D Dauer: ½ Sprint, ca. 15 Tage 4. Funktionalitätstest / Fehlerbearbeitung Dauer: ein Sprint, ca. 30 Tage Im Zweiten Schritt des Scrums werden im Sprint Backlog alle Aufgaben für den nächsten Sprint definiert. Wie bereits oben festgelegt, befasst sich der komplette erste Sprint mit der Programmierung der Datenbank sowie Reservedatenbank. Dabei ist zu beachten, dass in der Datenbank folgende Daten gespeichert werden. - Personal_ID - TAN - Gepäck_ID - CheckIn: Ort und Zeit

12 Seite 10 - Beladung: Ort und Zeit - Entladung: Ort und Zeit - Kofferband: Ort und Zeit Zusätzlich muss der Zugriff für das Portal implementiert sein. Falls nötig, kann nach dem ersten Sprint der Product Backlog erweitert bzw. neu definiert werden. Erkenntnisse aus dem Sprint, welche durch den Sprint erworben wurden, sind somit jederzeit durchführbar. Im Review, den Daily Scrums sowie dem Impediment Backlog werden während bzw. nach dem Sprint aufgetretene Hindernisse verzeichnet, der Restaufwand täglich geschätzt und über das bis dahin produzierte Teilergebnis diskutiert. Da dies Faktoren der Zukunft darstellen, können diese nicht im Detail besprochen werden. Im nächsten Schritt beginnt das Scrum von vorne und definiert erneut im Sprint Backlog die Aufgaben für den zweiten Sprint. Wie bereits oben festgehaltem werden im zweiten Sprint weitere Module programmiert. Dabei wird ein erstes Modul Scannerzuordnung angelegt, das feststellen soll, von welchem Scannertyp die jeweiligen Daten kommen, um diese dann an das richtige Scannermodul weiterzuleiten. Im Scannermodul werden die Daten dann aufbereitet und per ETL-Methode transformiert, damit diese das richtige Format für die Datenbank haben. Im letzten Sprint Backlog werden die einzelnen Module auf ihre Funktionalität untereinander getestet sowie anfallende Fehler behoben. 5. Wahl des Vorgehensmodells Nach intensiver Betrachtung der beiden Modelle kommen wir zu dem Schluss, dass für das Projekt der LogistikSoft das V-Modell angewendet wird. Diese Entscheidung resultiert auf dem Abwägen der Vor- und Nachteile der beiden Modelle. Das Scrum-Modell birgt zu viele Risiken. Zum Einen ist die Selbstorganisation eines Teams ohne feste Hierarchie für uns in der Realität nicht ausführbar. Zum Anderen ist die optimale Besetzung der verschiedenen Rollen mit großen Problemen verbunden, da das Zusammenspiel der Personen untereinander im Voraus nicht planbar ist. Die Zukunft ist mit Unsicherheit belastet und Unsicherheit lässt sich bekanntlich nicht überlisten. Unter der Annahme, dass das Vorgehensmodell noch nie in dieser Form im Unternehmen der LogistikSoft angewendet wurde, möchten wir bei einem Projekt diesen Umfangs nicht das Risiko, das mit dem erstmaligen Verwenden des Scrum-Modells verbunden ist, eingehen. Das V-Modell hingegen ist mit weniger Risiko verbunden, wenn es um die Zusammenarbeit der einzelnen Individuen geht. Natürlich gibt es im V-Modell auch Teams, aber Fehler können besser kompensiert werden. Es kann sich niemand hinter der Selbstregulierung verstecken oder die Selbstorganisation des Teams ausnutzen. Die detaillierte Anfertigung von Anforderungen und Entwürfen führen zu vorausschauendem Denken und guter Dokumentation im gesamten Verlauf des Projekts. Wir sind davon überzeugt, dass durch die Grob- und Feinplanung in unserem Projekt die Anforderungsebenen besser analysiert wurden.

13 Seite 11 Wegen der ausführlichen Dokumentation ist es deutlich einfacher, Fehler auszubessern. Im Scrum-Modell kann es passieren, dass ein Fehler durch mehrere Sprints verschleppt wird und eine Fehlerbehebung am Ende äußerst kompliziert ist.