F A C H H O C H S C H U L E F Ü R D I E W I R T S C H A F T F H D W, H A N N O V E R INTEGRATIONSPROJEKT SCRUM Beschreibung und Anmerkungen zur Durchführung Christoph Schulz, Arthur Brack 1 ZIELSETZUNG Ziel dieses Projekts ist es, ein Ticket-System zur Unterstützung der Zusammenarbeit von Teams nach dem Vorgehensmodell Scrum zu entwickeln. Dabei machen sich die Studenten theoretisch und praktisch mit dem Scrum-Vorgehensmodell vertraut, denn die Entwicklung der Software zur Unterstützung von Scrum-Teams orientiert sich selbst an dem Scrum- Vorgehensmodell. Die zu entwickelnde Anwendung soll nicht auf ein bestimmtes Unternehmen zugeschnitten sein, sondern soll zur Abbildung individueller Abläufe und Organisationseinheiten in einem Unternehmen flexibel konfiguriert werden können. Die Analyse und Anwendung von etablierten Techniken bei der Entwicklung von Informationssystemen (Persistenz/Datenbanken, Drei-Schichten-Architektur, verteilte Systeme) runden die Veranstaltung ab. 2 TEILAUFGABEN Das Projekt gliedert sich in zwei Semester und eine Hausaufgabe. Jedes Semester teilt sich auf in vier Phasen zu je zwei bis drei Wochen, in denen drei verschiedene Teilaufgaben von den Studenten in Gruppen bearbeitet werden. Jede Teilaufgabe wird mit einer Präsentation abgeschlossen, die in die Bewertung einfließt (s. u.). Hinweis: Jede Entwicklungstätigkeit umfasst das Anfertigen entsprechender Testfälle, anhand derer geprüft wird, ob das Programm korrekt arbeitet. Diese Testfälle sind bei der Präsentation als Teil der Programm-Demonstration vorzuführen (s. u.)! Weiterhin ist jede entwickelte Klasse und Operation mit JavaDoc-Kommentaren ordentlich zu dokumentieren! 2.1 SEMESTER I: KOLLABORATION IN EINEM TEAM Im ersten Semester liegt der Schwerpunkt neben der Erarbeitung der nötigen Grundlagen auf der Entwicklung eines Ticket-Systems zur Unterstützung der Zusammenarbeit in einem Scrum-Team. Das Semester ist wie folgt strukturiert: 2.1.1 Phase I: 1.-4. Woche Ziel: Erarbeitung von Grundlagen und Entwicklung der Programm-Architektur
Integrationsprojekt Scrum Präsentation und Abgabe: 26.01.2011 1. Grundlagen Scrum (5): In der ersten Teilaufgabe werden die theoretischen Grundlagen der Scrum-Vorgehensweise erarbeitet und zusammengetragen. Ein besonderer Augenmerk soll auf den Artefakten und Konzepten liegen, die in den folgenden Aufgaben eine Rolle spielen. Die Ergebnisse sollen so präsentiert und dokumentiert werden, dass hinterher alle Studenten die grundlegenden Begriffe und Konzepte von Scrum verinnerlicht haben. 2. Grundlagen Persistenz (4): In der zweiten Teilaufgabe soll eine einfache Architektur zum Speichern und Laden von im Programm anfallenden Daten erarbeitet werden. Die Verwendung der Java-Bibliothek XStream 1 wird empfohlen. Die Ergebnisse sollen so präsentiert und dokumentiert werden, dass möglichst alle Studenten in die Lage versetzt werden, persistente Objekte zu verwenden bzw. den Code nachvollziehen zu können. 3. Grundlagen GUI (4): In der dritten Teilaufgabe soll eine einfache Architektur zur Darstellung von Informationen und zur Interaktion des Programms mit dem Benutzer entwickelt werden. Die Verwendung der Java-Bibliothek Google Web Toolkit 2 wird empfohlen. Die Ergebnisse sollen so präsentiert und dokumentiert werden, dass möglichst alle Studenten in die Lage versetzt werden, Teile der Benutzungsoberfläche zu entwickeln bzw. den Code nachvollziehen zu können. Hinweis: Das Ticketsystem ist vorerst als Einzelplatzsystem zu konzipieren. Die Umstellung auf eine Mehrplatznutzung des Systems erfolgt in der Hausaufgabe zwischen den Projektsemestern. 2.1.2 Phase II: 4.-7. Woche Ziel: Benutzer können Product-Backlogs anlegen und Features zu einem Produkt verwalten. Abgabe: 16.02.2011, Präsentation: 21.02.2011 1. Product-Backlog (5): In der ersten Teilaufgabe gibt es folgende Anforderungen: Der Product Owner möchte Product-Backlogs anlegen, um Features und Bugs für ein Produkt zu verwalten und zu priorisieren. Der Product Owner möchte während einer Release-Planung Product-Backlog- Einträge priorisieren und einem Release zuordnen, um Auslieferungstermine und eine Abarbeitungsreihenfolge der Product-Backlog-Einträge festzulegen. Der Product Owner möchte zu Product-Backlog-Einträgen eine Aufwandsschätzung eintragen, die vom Team vorgegeben wird. Die Aufwandsschätzung dient als Planungshilfe und für Reporting-Zwecke. 2. Tickets I (4): In der zweiten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte Features zu einem Produkt anlegen, damit diese vom Product Owner priorisiert und einem Release zugeordnet werden können. Ein Feature soll eine Beschreibung sowie Hinweise auf detaillierte Informationen enthalten. 1 http://xstream.codehaus.org/ 2 http://code.google.com/webtoolkit/ 2
Teilaufgaben Der Product Owner möchte während der Sprint-Planung Akzeptanzkriterien für Product-Backlog-Einträge festlegen, anhand deren das Feature beim Sprint-Review bewertet werden kann. Der Ticketsystem-Benutzer möchte Features verändern und abschließen können. Der Ticketsystem-Benutzer möchte Beziehungen zwischen Features angeben (z. B. abhängig von, siehe auch ), um den Ticketsystem-Benutzer auf relevante Tickets hinzuweisen. 3. Organisationseinheiten (4): In der dritten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte Teams und Teammitglieder anlegen, um Sprints Teams zuzuweisen sowie nachvollziehen zu können, welcher Benutzer Änderungen an bestimmten Tickets vorgenommen hat. Der Ticketsystem-Benutzer möchte Rollen definieren und den Teammitgliedern zuweisen (z. B. Entwickler, Tester, Scrum Master, Product Owner usw.). Hinweis: Um zwischen den verschiedenen Teammitgliedern bzw. Rollen im System unterscheiden zu können, reicht es aus, wenn der Ticketsystem-Benutzer auf einfache Weise zu einem beliebigen anderen Teammitglied wechseln kann, wobei er dabei wieder auf der Startoberfläche der Anwendung landet. 3 Eine Authentifizierung von Benutzern oder eine Mehrplatznutzung des Systems soll nicht realisiert werden und ist erst Thema der Hausaufgabe. 2.1.3 Phase III: 7.-10. Woche Ziel: Ticketsystem-Benutzer können zu Product-Backlog-Einträgen Tasks für einen Sprint anlegen und in einem Taskboard verwalten. Burn-Down-Charts zeigen den Projektfortschritt an. Eine komfortable Suchfunktion ermöglicht das Finden von Tickets. Präsentation und Abgabe: 09.03.2011 1. Taskboard (5): In der ersten Teilaufgabe gibt es folgende Anforderungen: Das Teammitglied möchte während der Sprint-Planung Tasks anlegen, die Product- Backlog-Einträge realisieren sollen, die für den Sprint geplant sind. Das Teammitglied möchte auf einem Taskboard einem Task verschiedenen Zustände (z. B. offen, in Arbeit, fertig ) zuweisen können, um den Status der Tasks für andere Benutzer sichtbar zu machen. 2. Reporting I (4): In der zweiten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte einen Release-Burn-Down-Chart sehen, um den Fortschritt eines Releases zu begutachten. Der Ticketsystem-Benutzer möchte einen Sprint-Burn-Down-Chart sehen, um den Fortschritt eines Sprints zu begutachten. 3 Hier bietet sich ein Gast-Benutzer an, dem keine bestimmte Rolle zugeordnet ist und der standardmäßig beim Start der Anwendung genutzt wird. 3
Integrationsprojekt Scrum 3. Tickets II (4): In der dritten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte Bugs zu einem Produkt anlegen können, damit diese vom Product Owner priorisiert und einem Release zugeordnet werden können. Ein Bug soll eine Fehlerbeschreibung sowie Informationen zum eingesetzten System und zur eingesetzten Version enthalten. 2.1.4 Phase IV: 10.-12. Woche Ziel: Ticketsystem-Benutzer können Bugs anlegen. Tickets können zusätzliche Felder enthalten. Die Velocity von Teams sowie eine Projekthistorie können begutachtet werden. Präsentation und Abgabe: 08.04.2011 1. Suche (7): In der ersten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte anhand flexibel definierbarer Suchkriterien nach Tickets suchen können. Der Ticketsystem-Benutzer möchte Suchkriterien definieren und unter einem Namen speichern können um diese für häufige Suchanfragen verwenden zu können. 2. Reporting II (6): In der dritten Teilaufgabe gibt es folgende Anforderungen: Der Scrum Master möchte zu einem Sprint zusätzliche Informationen festhalten: Teammitglieder, Arbeitstage, besondere Ereignisse, Hindernisse usw., damit diese Informationen für die Retrospektive verwendet werden können und um eine Projekthistorie zu erhalten. Der Ticketsystem-Benutzer möchte den Verlauf der Velocity eines Teams sehen, um die Effizienz des Teams zu begutachten. 2.2 HAUSAUFGABE I: CLIENT-SERVER-SYSTEM Die Hausaufgabe hat zum Ziel, das entwickelte Ticket-System von einem Einzelplatzsystem zu einem Client-Server-System fortzuentwickeln. Dazu ist die Benutzungsoberfläche komplett von der Anwendungslogik zu trennen. Des Weiteren ist auf Anwendungsseite eine Sitzungsschicht zu entwickeln, die mehrere Sitzungen zur gleichen Zeit erlaubt, wobei jede Sitzung einem bestimmten Benutzer zugeordnet sein soll. Dies schließt die Entwicklung einer geeigneten Anmelde-Prozedur mit ein. Schließlich ist zu untersuchen, welche Anwendungsobjekte sitzungsübergreifend und welche an eine bestimmte Sitzung gebunden sind. Hierzu ist ggfs. auch die Persistenz-Schicht entsprechend zu erweitern. Präsentation und Abgabe: 29.06.2011 2.3 SEMESTER II: FLEXIBILITÄT UND BENUTZUNGSFREUNDLICHKEIT Im ersten Semester liegt der Schwerpunkt darauf, das Ticket-System benutzungsfreundlicher und flexibler zu gestalten. Das Semester ist wie folgt strukturiert. 2.3.1 Phase I: 1.-4. Woche Präsentation: 19.07.2011, Abgabe: 20.07.2011 4
Teilaufgaben 1. Abschluss Client/Server-System I (3): In der ersten Teilaufgabe sollen alle offenen Punkte (z.b. Bugs, Dokumentation), die im Rahmen der Umstellung des Ticketsystems auf das Client/Server-System entstanden sind bzw. im Rahmen dieser Phase entdeckt werden, behoben werden. Offene und behobene Bugs sind hierbei zu priorisieren und im Bugzilla- System festzuhalten. Eventuell ist die gewählte Software-Architektur zu überdenken; sind hier größere Veränderungen nötig, ist ein entsprechendes abgeändertes Konzept sowie ein Prototyp zu entwickeln. Schließlich ist eine Retrospektive zur Client/Server-Realisierung durchzuführen und zu dokumentieren. 2. Grundlagen Revisionssicherheit I (4): In der zweiten Teilaufgabe gibt es folgende Anforderung: Der Ticketsystem-Benutzer möchte, dass jeder Zustand im System revidierbar 4 und jede Zustandsveränderung im System nachvollziehbar ist. Hierfür sollen die Grundlagen zur Revisionssicherheit ausgearbeitet und ein entsprechender Entwurf für das Ticketsystem entwickelt werden. Zur Validierung des Entwurfs sollen die Konzepte prototypisch umgesetzt werden. 3. Meta-Modell I (4): In der dritten Teilaufgabe gibt es folgende Anforderung: Der Ticketsystem-Benutzer möchte eigene Tickettypen erstellen. Ein Tickettyp besteht aus einer Reihe von benutzerdefinierten Feldern (z. B. Hinweise für Releasestand, Test oder Installation; Produktkomponenten, Produktversionen, Plattformen, Wunschtermin von Kunden usw.), einer Menge von gültigen Zuständen (z. B. offen ) und einer Menge von gültigen Zustandsübergängen (z. B. offen geschlossen ). Die definierten Felder und Zustände sollen zusätzliche Suchkriterien darstellen. Die aktuell vorhandenen Tickettypen Anforderung, Bug und Task sollen als Exemplare des Meta-Modells als Standardtickettypen im Ticketsystem verfügbar sein (Hinweis: hierfür ist ein Refactoring erforderlich). In dieser Teilaufgabe sollen die gestellte Aufgabe analysiert sowie ein geeigneter Entwurf ausgearbeitet werden. Des Weiteren soll ein Refactoring-Plan aufgestellt werden, aus dem ersichtlich wird, wie die alten, fest verdrahteten Ticket-Typen in das neue Modell transferiert werden können. Die eigentliche Implementierung erfolgt in einer späteren Phase. 2.3.2 Phase II: 4.-7. Woche Präsentation und Abgabe: 24.08.2011 1. Abschluss Client/Server-System II: In der ersten Teilaufgabe sollen das in Aufgabe Abschluss Client/Server-System I erarbeitete Konzept und die prototypisch implementierte Architektur auf das eigentliche Scrum-System übertragen werden. 2. Grundlagen Revisionssicherheit II: In der zweiten Teilaufgabe sollen das in Aufgabe Grundlagen Revisionssicherheit I erarbeitete Konzept und der entwickelte Prototyp auf das eigentliche Scrum-System übertragen werden. 3. Meta-Modell II: In der dritten Teilaufgabe sollen der in Aufgabe Meta-Modell I erarbeitete Entwurf mit Hilfe des entwickelten Refactoring-Plans auf das eigentliche Scrum-System übertragen werden. 4 revidieren = wieder ansehen 5
Integrationsprojekt Scrum Die Aufgaben werden nach Absprache gemeinschaftlich von der gesamten Gruppe umgesetzt! Es erfolgt keine Zuteilung von Studenten zu den einzelnen Aufgaben! 2.3.3 Phase III: 7.-10. Woche Präsentation und Abgabe: 14.09.2011 1. Rollen und Rechte (4): In der ersten Teilaufgabe gibt es folgende Anforderungen: Der Ticketsystem-Benutzer möchte nur die Teile der Anwendung sehen und benutzen, die er gemäß seiner Rolle benötigt. Falls er mehrere, voneinander unabhängige Rollen einnehmen kann (etwa Team-Mitglied und Administrator ), soll er bei der Anmeldung die aktive Rolle auswählen können. Der Administrator möchte jedem Benutzerkonto einen Satz von möglichen Rollen zuweisen können. Hinweis: Diese Aufgabe erfordert zunächst die Erstellung eines Rechte- und Rollenkonzepts, in dem ausgearbeitet werden soll, (1) welche Rechte innerhalb der Anwendung benötigt werden und (2) welche vordefinierten Rollen welche Rechte umfassen. Dieses Konzept ist schriftlich anzufertigen und abzugeben. Zusätzlich soll das Konzept ordentlich umgesetzt (objektorientierter Entwurf, fehlerfreie Implementierung, ausführliche Testfälle) und dokumentiert (Klassen-, Attribut- und Operationskommentare) werden. 2. Benutzerdokumentation (3): In der zweiten Teilaufgabe existieren folgende Anforderungen: Der Ticketsystem-Benutzer möchte eine Benutzerdokumentation erhalten, in der alle Funktionen des Systems ausführlich beschrieben sind. Der Ticketsystem-Benutzer möchte innerhalb der Anwendung schnell auf eine kontextsensitive Online-Hilfe zugreifen können. Hinweis: Für den zweiten Punkt soll in dieser Phase nur evaluiert werden, wie entsprechende Teile der Benutzerdokumentation als Online-Hilfe in die Anwendung redundanzfrei integriert werden können. Hierfür soll ein Konzept inklusive Analyse und Entwurf erstellt werden. Die Implementierung des Entwurfs erfolgt in einer späteren Phase! 3. Aufräumen I (4): In der dritten Teilaufgabe soll der Quelltext nach allen Regeln der Kunst ordentlich gemacht werden. Hierzu sollen mindestens die Java-Analyse-Werkzeuge FindBugs, CheckStyle und Cobertura in Absprache mit den Projektbetreuern eingesetzt werden. 5 Angestrebt wird eine C0-Überdeckung von mindestens 90% und eine C1- Überdeckung von mindestens 70% für die server- und shared-pakete sowie null (!) FindBugs- und CheckStyle-Warnungen. Weiterhin soll für jeden in Bugzilla existierenden offenen Punkt (Bug/Feature) entweder direkt eine Lösung entwickelt und umgesetzt werden, oder (bei großflächigen/architekturellen Punkten) ein Lösungskonzept für spätere Entwicklungsphasen entwickelt werden. 5 Weitere Werkzeuge wie PMD und Classycle können, müssen jedoch nicht eingesetzt werden. Die zu verwendende FindBugs- und CheckStyle-Konfiguration muss mit den Projektbetreuern abgesprochen werden! 6
Teilaufgaben Schließlich soll die Struktur des SVN-Projektarchiv vereinfacht werden, indem nicht mehr genutzte Entwicklungszweige gelöscht werden und die Verzeichnisstruktur entschlackt wird. Alle Veränderungen (Typen behobener FindBugs- und CheckStyle-Probleme, ergänzte/verbesserte Testfälle, behobene Bugs bzw. entwickelte Lösungskonzepte, Umstellungen des SVN-Projektarchivs) sollen angemessen dokumentiert werden. 2.3.4 Phase IV: 10.-12. Woche Präsentation und Abgabe: 28.09.2011 1. Online-Hilfe (4): In der ersten Teilaufgabe wird das Konzept für die Online-Hilfe aus der Aufgabe Benutzerdokumentation umgesetzt. 2. Projektdokumentation (4): In der zweiten Teilaufgabe wird die komplette technische Dokumentation des Projekts zusammengetragen, auf den neuesten Stand gebracht und in einem einzelnen Dokument zusammengeführt. 3. Aufräumen II (3): In der dritten Teilaufgabe werden alle in der Aufgabe Aufräumen I offen gebliebenen Punkte fertig gestellt. 2.4 HAUSAUFGABE II: GUI-TEST Diese Hausaufgabe soll das Thema des GUI-Testens beleuchten. Dazu sollen zum einen die Vor- und Nachteile des GUI-Testens thematisiert, zum anderen die allgemeine Vorgehensweise beim Testen grafischer Oberflächen dargelegt und die verschiedenen technischen Möglichkeiten erörtert werden. Dabei soll der Fokus auf Web-Oberflächen liegen, wie sie im vorliegenden Projekt verwendet werden. Zum zweiten soll evaluiert werden, wie das Testen von Oberflächen im Scrum-Projekt konkret umgesetzt werden kann. Dazu sind entsprechende kostenfreie Werkzeuge ausfindig zu machen, zu vergleichen und zu bewerten. Dabei sollen die Merkmale Funktionsumfang und Automatisierbarkeit der Tests, insbesondere deren Integration in das im Projekt verwendete Continuous Engineering, im Vordergrund stehen. Schließlich sollen prototypisch Testfälle für die Oberfläche Projektdetails mit Hilfe des ausgesuchten Werkzeugs erstellt und in das Testprozedere des Projekts eingebunden werden. Die Ergebnisse der ersten beiden Punkte werden in einem Dokument im Umfang von ca. 15-20 Seiten festgehalten und abgegeben. Die Ergebnisse des letzten Punktes sind in den Quellcode des Projektes zu integrieren. In der Präsentation sollen innerhalb von 20-30 Minuten alle erarbeiteten Ergebnisse vorgestellt werden. Abgabe: 26.10.2011, Präsentation: Anfang November 2011 3 VORGEHEN UND BEWERTUNG 3.1 BEARBEITUNG An jeder Teilaufgabe arbeitet eine Gruppe von drei bis fünf Studenten. Zur Klärung und Bearbeitung bietet Ihr Betreuer Sprechzeiten an, die innerhalb der im Stundenplan 7
Integrationsprojekt Scrum festgelegten Zeiten liegen. Während dieser Zeiten sollen sich alle Projektgruppen im Klassenraum aufhalten. Jede Teilaufgabe hat entweder die Anfertigung eines Dokuments oder eines Programms zum Ziel. Dieses Dokument bzw. Programm wird dann zu den unten angegebenen Terminen an den Betreuer abgegeben. Ausarbeitungen können auch auf elektronischen Datenträgern abgegeben werden. Der Betreuer bewertet die Ausarbeitung so bald wie möglich und gibt ein entsprechendes Feedback. Für die einzelnen Arten der anzufertigenden Ergebnisse gelten folgende Richtlinien: Analyse: Sie sollen darstellen, dass Sie für die Aufgabenstellung ein tiefgreifendes Verständnis bekommen haben. Dies geschieht durch eine jeweils adäquate Darstellung aller wichtigen Hintergründe, die für das Verstehen der Aufgabenstellung notwendig sind. Dazu gehört neben einem Fachlexikon (Glossar) auch die Modellierung der Fachklassen mit Hilfe der UML. Entwurf: Sie sollen darstellen, wie Ihre Anwendung technisch realisiert werden wird. Hier sollen neben textuellen Elementen wieder Diagramme (Klassendiagramme, Ablaufdiagramme usw.) benutzt werden. Stellen Sie die wesentlichen Entwurfsentscheidungen Ihres Programms dar. Verwenden Sie wieder UML- Klassenmodelle. Implementierung: Das Programm soll in der Programmiersprache Java entwickelt werden. Ihre Ausarbeitung ist in dieser Phase ein lauffähiges Programm, das die Anforderungen der Aufgabe umsetzt, und eine kurze Installationsbeschreibung (sofern notwendig), so dass das Programm für den Betreuer ohne weitere Hilfestellung ausführbar ist. Präsentation: Sie stellen die Ergebnisse, die aus der Bearbeitung der Aufgabe resultieren, im Rahmen einer Präsentation dar. Der Umfang der Präsentation sollte 20 Minuten nicht überschreiten. Ist die Aufgabe das Entwickeln eines Programms, dann umfasst die Präsentation auch eine Demonstration der Funktionalität des Programms und ein Ausführen der im Rahmen der Entwicklung erstellten Testfälle. 3.2 BEWERTUNG Die Bewertung der Ausarbeitungen erfolgt nach den folgenden Gesichtspunkten: Verständlichkeit: Grundlage für eine Bewertung, ist, dass alle Aussagen Ihrer Arbeiten vom Leser verstanden werden können. Gehen Sie dabei nicht davon aus, dass der Leser sich besonders gut mit dem behandelten Thema auskennt. (Tipp: Geben Sie Ihre Ausarbeitung einem Kommilitonen einer anderen Gruppe zum Lesen!) Wissenschaftlichkeit: Wenn es notwendig ist, theoretische Hintergründe darzustellen, soll dies in einer adäquaten Form erfolgen. Ist das Programm korrekt? Erfüllt es die Anforderungen? Ist es bedienbar? Komplexität der Aufgabe: Die Aufgaben haben einen unterschiedlichen Schwierigkeitsgrad. Gute Lösungen von komplexen Problemen verdienen einen Bonus in der Bewertung. Effektivität des Entwurfs: Ist das System so entworfen und dokumentiert, dass leicht Erweiterungen oder Änderungen (auch von Projektfremden) vorgenommen werden können? Ist dabei sauber objektorientiert vorgegangen worden? 8
Können theoretische Inhalte richtig dargestellt und angewandt werden? Kreativität: Gute Ideen können die Note nur verbessern. Vorgehen und Bewertung Bewertet werden alle schriftlichen oder elektronischen Ausarbeitungen, die zu den angegebenen Zeitpunkten abgegeben werden. Die Ausarbeitungen werden wie folgt gewichtet: Ausarbeitung (Dokument/Programm/sonstiges Artefakt): 80 % Präsentation: 20 % Dabei werden die Teilaufgaben untereinander mit 25 % gleich gewichtet. Als Endergebnis ergibt sich eine Prozentzahl, aus der sich nach dem IHK-Notenschema die Gesamtnote des Fachs errechnet. Jede Gruppe erhält nur eine Note. Notenschema Prozent Note Prozent Note Prozent Note 0 5 72 3 89 1,7 50 4 77 2,7 92 1,3 59 3,7 81 2,3 97 1 67 3,3 85 2 3.3 WEITERE BEMERKUNGEN Bemerkung zu der Gestaltung der Benutzungsoberfläche: In den Anwendungen ist weniger darauf zu achten, dass Eingaben und Ausgaben über schicke Oberflächen erfolgen (es ist natürlich eine für die Anforderungen notwendige Benutzungsoberfläche bereitzustellen). Wer Entwicklungsumgebungen mit ausgereiften Oberflächen-Design-Werkzeugen kennt, soll diese natürlich benutzen. Man muss das aber nicht tun. Es ist wichtiger, die der Aufgabe zugrunde liegenden Strukturen zu analysieren (also zu verstehen!), sie in einem guten Entwurf umzusetzen und die jeweiligen Algorithmen effektiv zu entwickeln. Die Implementierung baut auf dem Entwurf, der Entwurf auf der Analyse auf. Das heißt nicht, dass z. B. Ihr Entwurf auf der bereits bewerteten Ausarbeitung der Analyse-Phase aufbauen muss. Gibt es in der Analyse Raum für Verbesserungen, so sollen diese Verbesserungen natürlich in die weiteren Ausarbeitungen einfließen. Bereits bestehende Bewertungen werden nicht beeinflusst. In diesem Fach wird keine Klausur geschrieben. Weitere Fragen können individuell mit dem Betreuer geklärt werden. 9
Integrationsprojekt Scrum 4 ZUORDNUNG DER TEILAUFGABEN 4.1 SEM. I / PHASE I Grundlagen Scrum Grundlagen Persistenz Grundlagen GUI Manuel, Angelina, Stefan, Sarah, Christin Christoph, Patrick, Niklas, Wilken Nils K., Nils V., Ulrike, Timo 4.2 SEM. I / PHASE II Product-Backlog Ulrike, Patrick, Manuel, Angelina, Timo Tickets I Niklas, Christoph, Stefan, Nils K. Organisationseinheiten Wilken, Sarah, Christin, Nils V. 4.3 SEM. I / PHASE III Taskboard Nils K., Manuel, Angelina, Ulrike, Stefan Reporting I Wilken, Christoph, Sarah, Nils V. Tickets II Niklas, Patrick, Christin, Timo 4.4 SEM. I / PHASE IV Suche Patrick, Christoph, Manuel, Niklas, Ulrike, Christin, Nils K. Reporting II Wilken, Sarah, Stefan, Timo, Angelina, Nils V. (alle) 4.5 HAUSAUFGABE 4.6 SEM. II / PHASE I Abschluss Client/Server- System I Grundlagen Revisionssicherheit I Meta-Modell I Patrick, Nils, Timo Wilken, Christoph, Ulrike, Christin Manuel, Angelina, Sarah, Stefan 4.7 SEM. II / PHASE II (alle) (alle) 10
Zuordnung der Teilaufgaben 4.8 SEM. II / PHASE III Rollen und Rechte Benutzerdokumentation Aufräumen I Ulrike, Stefan, Manuel, Angelina Patrick, Wilken, Christoph Niklas, Sarah, Christin, Timo 4.9 SEM. II / PHASE IV Online-Hilfe Projektdokumentation Aufräumen II Stefan, Christoph, Wilken, Ulrike Manuel, Angelina, Patrick, Timo Niklas, Christin, Sarah 11