Software Engineering I (IB) Semesteraufgabe

Transkript

1 Semesteraufgabe Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München Wintersemester 2014/ :26 Entwerfen und erarbeiten Sie eine Softwarelösung für einen Pizzadienst. Die Arbeit ist in Gruppen von 2 Studenten durchzuführen. Dabei sind zwei Meilensteine zu erreichen. Im Folgenden werden zunächst Vorgehensweise und Ergebnisse und dann die funktionalen Anforderungen beschrieben. Vorbemerkung zu Git Die Abgaben erfolgen über ein Ihrer Gruppe zur Verfügung gestelltes Git- Repository mit dem Namen Semesteraufgabe-grpXX, wobei XX durch Ihre Gruppennummer aus Moodle ersetzt wird. In den Repositories finden Sie neben einem initialen Play-Projekt auch einen Feedback-Branch. Lesen Sie unter unter der Übeschrift Feedback in den Repositories durch, was Sie damit machen sollen. Lesen Sie außerdem die Datei README.txt und befolgen Sie die Anweisungen dort. Ein Meilenstein ist nur dann abgegeben, wenn das Repository mit dem Tag MilestoneX (X aus {1,2}) versehen ist und bis zum angegebenen Termin in das Git-Repository auf dem Server gepusht wurde. Die Abgabe muss im master-branch sein. Sie können bei Bedarf für sich beliebige andere Branches (außer feedback) anlegen. 1

2 Projektvorgehen und Meilensteine Es sind die folgenden Projektphasen vorgesehen: Phase 1: Teambildung, Projektplanung, erste Version der Web-Applikation, erste Version der Dokumente. Abgabe , 23:59 Uhr im Git-Repository mit dem Tag Milestone1 Phase 2: Zweite Projektiteration. Abgabe , 23:59 Uhr im Git- Repository mit dem Tag Milestone2 Phase 1 Ziel der Phase 1 ist es, das Projektteam zu organisieren, eine erste Projektplanung durchzuführen und sich technisch und fachlich einzuarbeiten. Meilenstein 1 Zum Abschluss von Phase 1 (Meilenstein 1) sind folgende Artefakte abzugeben: 1. Statusbericht: a. was wurde schon gemacht, wo steht das Projekt, was kann der Prototyp (siehe 3.)? b. Zuordnung Verantwortlichkeiten im Team (wer macht was?) c. Projektplan für die Restlaufzeit des Projekts (Aktivitäten, Zuordnung zu Teammitgliedern, Zeiträume (Aktivitäten wochenweise herunterbrechen)) d. Risikoanalyse (welche Risiken sind in dem Projekt erkennbar (zeitliche Risiken, technische Risiken, Risiken im Team ) und welche Gegenmaßnahmen sind geplant? e. Aufwandsnachweis (tageweise Aufstellung der Arbeiten der einzelnen Mitarbeiter). 2. Lastenheft 3. Lauffähiger Prototyp (die Funktionalität des Prototyps bleibt Ihnen überlassen, er muss jedoch mindestens die Preisberechnung bei Bestellungen enthalten) Die Artefakte von Meilenstein 1 sind im zur Verfügung gestellten Git-Repository abzugeben. Folgendes muss dabei gelten: Der Prototyp ist ein Scala-Play-Projekt das top-level im Git-Repository liegt und mit activator run gestartet werden kann. Alle Dokumente (Statusbericht, Lastenheft etc.) müssen als Plain-Text (Dateiendung.txt, formatiert mit Markdown) oder als PDF im Unterverzeichnis doc 2014 Oliver Braun 2

3 liegen. Die Dokumente aus denen Sie das PDF generiert haben (Office etc.) können in einem anderen Ordner oder in einem Unterverzeichnis von doc liegen. Nicht aber direkt in doc. Der abzugebende Stand im Git-Repository hat den Tag Milestone1. Phase 2 Erarbeiten der endgültigen und vollständigen Projektergebnisse. Projektabschluss (Meilenstein 2) Zum Abschluss von Phase 2 sind folgende Dokumente sowie die lauffähige Web- Applikation im Repository abzugeben: 1. Statusbericht: a. Kurze Zusammenfassung und Überblick über das Projekt b. Hinweise auf Einschränkungen, Hinweise zur Benutzung, etc. (falls vorhanden) c. Aufwandsnachweis (Gesamtprojekt) d. Rückblickende Analyse ( Post-Mortem ): 2. Pflichtenheft i. Was lief gut? Was lief schlecht? ii. Was würden wir das nächste Mal besser machen? iii. Feedback an den Auftraggeber zur Semesteraufgabe das Pflichtenheft muss mindestens drei UML-Diagramme verschiedenen Typs enthalten muss den unten angegebenen Funktionsumfang spezifizieren; die Spezifikation muss auch angeben welche Funktionen im Prototyp realisiert sind und welche nicht. 3. Lauffähige Web-Applikation. a. Die Web-Applikation muss mindestens den Minimalumfang der 1. Version umfassen (siehe unten) b. Für eine sehr gute Note müssen einige Funktionen der 2. Version implementiert werden. c. Die Web-Applikation wird in einer kurzen Vorführung im Rahmen des Praktikums vorgestellt. Dabei muss das ganze Team anwesend sein. Darüber hinaus eine Erklärung auszudrucken und ausgefüllt und unterschrieben am in der letzten Vorlesung abzugeben. Das PDF-Formular für die Erklärung finden Sie in Moodle Oliver Braun 3

4 Der Projektabschluss ist per Git-Repository zum o.a. Termin mit dem Tag Milestone2 versehen abzugeben. Regeln Ziel des Projektes ist es ein professionelles Projektvorgehen zu üben und qualitativ hochwertige Ergebnisse abzuliefern. Technische und optische Highlights sind erlaubt (und der Dozent freut sich darüber), gehen aber nur untergeordnet in die Bewertung ein. Bewertungskriterien: Professionelles und gut dokumentiertes Projektvorgehen (Statusbericht) Klarheit und Korrektheit der Dokumentation Korrektheit der implementierten Lösung Gute Programmstruktur, sinnvoll und gut kommentierter Code Qualität (Robustheit gegenüber Fehlersituationen; übersichtlicher und verständlicher Quellcode) Spezifikation und Realisierung von Funktionen, die über den Minimalumfang hinausgehen. Die Aufgabe ist als Gruppenarbeit in Gruppen von 2 Teilnehmern gem. Einteilung in Moodle zu lösen. Offensichtlich abkopierte Lösungen werden als nicht bestanden gewertet. Fragen zum Verständnis der Aufgabe dürfen (sollen!) im Moodle-Forum oder zu den Praktikumsterminen gestellt werden. Verspätete Abgabe eines Meilensteins (auch schon Meilenstein 1!) führt zu Notenabzug von 0,5 pro angefangene Woche. Die Aufgabe bildet die Studienarbeit zur Veranstaltung Software Engineering 1. Die Studienarbeit wird zu 40% bewertet. Die Arbeit muss mit bestanden gewertet werden damit die Gesamtveranstaltung Software Engineering 1 als bestanden gewertet werden kann. Funktionale Anforderungen Wir sind ein kleines und innovatives Softwarehaus und wir haben einen neuen Auftrag bekommen. Um die Ecke will ein neuer Pizzadienst aufmachen, der eine Software zur Auftragsabwicklung benötigt Oliver Braun 4

5 Im Pizzashop werden verschiedene Produkte angeboten (z.b. Pizza Margerita, Pizza Funghi, Cola, Tiramisu). Diese Produkte sind nach Kategorien eingeteilt (z.b. Pizza, Getränke, Desserts). Kunden können diese Produkte online bestellen. Dazu können sich Kunden auf der Seite registrieren. Die Kunden sollen sich auch über ihre bisherigen Bestellungen informieren können. Dabei soll auch der bisherige Gesamtumsatz ausgegeben werden. Die Pizzashop-Mitarbeiter können zusätzliche Funktionen nutzen: Produkte verwalten: Anlegen, Löschen, Anzeigen, Ändern (Löschen nur, wenn keine Bestellung zu dem Produkt vorhanden ist), Produkte können aus dem Sortiment herausgenommen werden, ohne dass sie gelöscht werden. Kunden verwalten: Kunden sollen angelegt, angezeigt, geändert und gelöscht werden können (Löschen jedoch nur, wenn der Kunde noch keine Bestellungen getätigt hat). Auswertungen: Den Mitarbeitern werden verschiedene Auswertungen zur Verfügung gestellt: alle Bestellungen nach Datum sortiert anzeigen (mit Gesamtumsatz), alle Bestellungen pro Kategorie anzeigen (mit Umsatz und Durchschnittsbestellwert für diese Kategorie), alle Bestellungen in einem Zeitraum anzeigen (mit Umsatz in diesem Zeitraum), und ggf. andere Die Preisberechnung für eine Bestellung ist nicht so ganz einfach. Grundidee: Ein Produkt kann eine Größe (Size) haben, diese wird in Units gemessen. Zum Beispiel kann eine Pizza einen Durchmesser (Size) in cm (Unit) haben, eine Cola eine Flaschengröße (Size) in Litern (Unit). Jede Unit hat einen Preis. Zusätzlich können Produkte noch Extras haben (z.b. Pizza: extra Käse, extra Soße), Jedes Extra kostet einen zusätzlichen Standardpreis. Beispiel: Pizza Capriciosa: Kostet pro cm 0,5, jedes Extra auch 0,5. Eine Bestellung mit 2 Pizzen à 20 cm Durchmesser und je 2 Extras kostet 22. Zusätzlich soll bei einer Bestellung auch die geschätzte Lieferzeit berechnet werden. Diese errechnet sich aus der Distanz zum Kunden. Die Pizzabackzeit ist 10 min. Pro Kilometer kommen 2 min Fahrzeit hinzu. Es werden nur Kunden bis zu einer Distanz von 20 km bedient. Kunden und Mitarbeiter verwalten wir der Einfachheit halber in einer gemeinsamen Tabelle. Mitarbeiter werden durch ein Attribut gekennzeichnet. Wir haben mit dem Auftraggeber folgenden Plan erarbeitet: In einer ersten Version wollen wir nur minimale Funktionalität liefern: 2014 Oliver Braun 5

6 Kategorien müssen noch nicht über eine Benutzerschnittstelle verwaltet werden können (sondern nur direkt im Datenbestand (Datenbank)) Kunden und Produkte müssen nicht gelöscht werden können Ein sicheres Login-Verfahren mit Passwort ist nicht notwendig: Kunden und Mitarbeiter wählen aus einer Drop-Down-Liste aus, in welcher Rolle sie gerade arbeiten. Ein Mitarbeiter mit Namen Padrone soll standardmäßig eingerichtet sein. Pro Bestellung kann nur ein Produkt bestellt werden (dieses aber in größerer Anzahl) Die Lieferzeitberechnung ist noch nicht notwendig Ein Status der Bestellung muss noch nicht mitgeführt werden (z.b. bestellt, in Lieferung, ausgeliefert, storniert) nur wenige, einfache Auswertungen Eine zweite Version soll dann die Einschränkungen der ersten Version nicht mehr haben und ggf. noch weitere sinnvolle Funktionen anbieten. Wenden Sie alles an was Sie über gute Programmierung bisher gelernt haben. (Sichtbarkeiten, Separation of Concerns, MVC-Architektur, Dokumentation, ) Ergänzende Angaben zur Semesteraufgabe. Terminologie: Version 0.5 entspricht Meilenstein 1 Version 1 entspricht Meilenstein 2 und damit endgültige Minimalversion, damit ist maximal die Note 2,0 möglich Version 2 mögliche zukünftige Programmversion bzw. zusätzliche Features daraus für eine sehr gute Note, je nach Aufwand müssen mindestens noch 2 bis 3 zusätzliche Use Cases umgesetzt werden um in den Notenbereich 1,3/1,0 zu kommen. Minimalfunktionalität für Version 1 (Meilenstein 2): Login über Dropdown-Liste (ohne Passwortabfrage). Ein Kunde mit Namen Emil und ein Mitarbeiter mit Namen Padrone soll standardmäßig eingerichtet sein. Unterscheidung Mitarbeiter/Kunde bei der Nutzung des Dienstes. Kunden können sich selbst registrieren Kunden können Produkte im Sortiment bestellen (inkl. Preisberechnung und Lieferzeitangabe); pro Bestellung kann nur ein Produkt bestellt werden (dieses aber in größerer Anzahl) Kunden können ihre eigenen Bestellungen anschauen (inkl. Gesamtsumme über alle Bestellungen) Mitarbeiter können Produkte anzeigen Mitarbeiter können User verwalten (anzeigen, hinzufügen, ändern) Mitarbeiter können Bestellungen ansehen nach folgenden Kriterien: 2014 Oliver Braun 6

7 Alle Bestellungen anzeigen (mit Angabe von Gesamtumsatz und Durchschnittswert aller Bestellungen) Alle Bestellungen pro Kunde anzeigen (mit Gesamtumsatz und Durchschnittswert für diesen Kunden) Funktionalität Version 2 (zusätzlich zu Minimalfunktionalität Version 1): Produkt-Verwaltung (anzeigen, hinzufügen, ändern) Kategorien-Verwaltung Löschen von Kunden und Produkten (Löschen jedoch nur, wenn es noch keine zugehörige Bestellung gibt, andernfalls nur deaktivieren) Login-Verfahren mit Name und Passwort Pro Bestellung können mehrere Produkte bestellt werden Status der Bestellung mitführen (z.b. bestellt, in Lieferung, ausgeliefert, storniert) Weitere Auswertungen über Bestellungen Weitere Funktionen nach eigenem Wunsch Ihr Milestone 2 muss die Minimalfunktionalität (== Version 1) enthalten. Sie können Ihre Version 1 durch zusätzliche Funktionalität aus Version 2 anreichern und dadurch Ihre Note verbessern. Zum Pflichtenheft: Das Pflichtenheft soll die Funktionalität von Version 1 und 2 spezifizieren. Geben Sie dabei jeweils an, welche Funktionen Sie in Ihrer Version 1 implementiert haben und welche nicht. Das Pflichtenheft muss wenigstens 3 UML-Diagramme enthalten. Das Pflichtenheft soll maximal 8 Use Cases definieren (wenn Sie mehr Use Cases benötigen, dann konzentrieren Sie sich auf die 8 wichtigsten). Das Pflichtenheft soll maximal 10 Seiten lang sein Oliver Braun 7