Programmierpraktikum


Herbsttrimester 2004

 

 

 

Inhalt dieser Seite:

0. News
1. Worum geht es?
2. Worauf achten die Betreuer?
3. Die beteiligten Personen (zu den Gruppenlinks)
4. Phasen, Dokumente und Termine
5. Wichtige Informationen, Werkzeuge, Links
6. Literatur

 

 


 

0. News

 

Datum News
21.10.2004 Zur Vorbeteitung der Präsentationen steht der EC ab sofort länger zur Verfügung:
  • mittwochs, 07 Uhr - 20 Uhr
  • donnerstags, 07 Uhr - 10 Uhr
Einzige Ausnahme: Am Mittwoch, 10.11.2004, steht der EC von 7 Uhr - 10 Uhr nicht zur Verfügung.
21.10.2004 Für die Einarbeitung sind Aufgabe B.3 (SalesPoint-Framework) bzw. Aufgabe 3 (ePoint-Framework) ersatzlos gestrichen.
14.10.2004 Die Lizenzen für Together 6.2 sind nun verfügbar.
06.10.2004 Zur Vorbeteitung der Präsentationen steht der EC zu den folgenden Zeiten zur Verfügung:
  • mittwochs, 7 Uhr - 13 Uhr und 15 Uhr - 20 Uhr
  • donnerstags, 7 Uhr - 10 Uhr
Einzige Ausnahme: Am Mittwoch, 10.11.2004, steht der EC von 7 Uhr - 10 Uhr nicht zur Verfügung.
06.10.2004 Die Framework-Unterrichte finden wie folgt statt (Raum 33/3331):
Gruppen Betreuer Termin
01,02,03 Jung,Schulz Montag, 11.10.04, 15 Uhr - 16 Uhr
04,05,06 Oesterreich,Akkermann Montag, 18.10.04, 15 Uhr - 16 Uhr
07,08,09 Domberg,Linnnebaum Montag, 11.10.04, 14 Uhr - 15 Uhr
10,11,12 Neumann,Hänel Montag, 18.10.04, 14 Uhr - 15 Uhr

 

 


 

1. Worum geht es?

Die in den Übungen zur Einführung in die Informatik I - III behandelten Programmieraufgaben lassen sich wie folgt charakterisieren:

  • relativ klein: innerhalb einer Woche zu bearbeiten;
  • präzise beschriebene Problemstellung, häufig mit angedeutetem Lösungsweg;
  • in verlangter Programmiersprache formulierter Code ist wesentliches Ergebnis.

Im Programmierpraktikum sollen Sie lernen, in Teams von 7 - 8 Studenten praxisnahe Aufgaben systematisch anzugehen. Diese Aufgaben sind

  • umfangreicher: beschäftigen ein Team ein Trimester lang;
  • nur vage formuliert: Ihre erste Aufgaben wird sein, das gestellte Problem zu analysieren und in Verhandlung mit dem Auftraggeber die konkrete Aufgabe auszuhandeln;
  • Entwicklungsaufgaben, die in vorgegebenen Phasen durchgeführt werden müssen. Ebenso wichtig wie das zu erstellende Programm sind die während der Entwicklung anfallenden Dokumente.

Von Nutzen wird Ihnen dabei alles sein, was Sie in der Einführungsvorlesung unter dem Thema "Objektorientierte Programmierung" gelernt haben über Java und seine Klassenbibliotheken, Wiederverwendung, CRC-Karten, UML-Diagramme, Muster und Frameworks.

Außerdem steht Ihnen mit dem Framework SalesPoint eine "Halbfertiglösung" zur Verfügung, die Sie "nur noch" zu einer vollständigen Lösung ausbauen müssen - sobald die eigentliche Aufgabenstellung erarbeitet ist. Leider haben auch hier die Götter den Schweiß vor den Erfolg gesetzt: Bevor man das Framework nutzen kann, muß man es verstehen. Mit einer neuen verbesserten Version des Frameworks und einer ausführlichen Dokumentation haben wir uns bemüht, Ihnen den Einstieg so einfach wie möglich zu machen.

2. Worauf achten die Betreuer?

Die Situation der Praktikum-Betreuer ähnelt der von Projektleitern in einem kleinen Softwarehaus, die einen Kundenauftrag

  • unter Einbeziehung des Firmen-Know-Hows (gegeben in Form eines Frameworks und seiner Dokumentation)
  • mit relativ unerfahrenen Entwicklern
  • termingerecht

abwickeln sollen. Damit die Projekte trotz dieser schwierigen Rahmenbedingungen erfolgreich durchgeführt werden können, sind die folgenden Regelungen unbedingt einzuhalten!

 

Zum Framework

Aus folgenden Gründen ist die möglichst weitgehende Verwendung des Frameworks bindend vorgeschrieben:

  1. Durch das Framework ist eine Grundarchitektur vorgegeben. Das erleichtert den für Unerfahrene schwierigen OO Entwurf.
  2. Einarbeitung in bestehende Programmsysteme gehören zum Arbeitsalltag des Software-Entwicklers. Das Framework ist durch die ausführliche Beschreibung und die flexible Anpassungsschnittstelle vergleichsweise gut zugänglich.
  3. Es soll Wiederverwendbarkeit bewußt eingeübt werden. Unerfahrene Entwickler neigen dazu, laufend das Rad neu zu erfinden. Auf diese Weise entstehen unkontrollierte Code-Doubletten, die - weil nicht zusammenhängend - nicht systematisch gewartet (verbessert oder an neue Gegebenheiten angepaßt) werden können. Im Gegensatz dazu erfordert die Wiederverwendung von Bausteinen deren laufende Anpassung und führt dadurch zu immer flexibleren und verläßlicheren Komponenten: die Qualität steigt, die investierte Mühe lohnt sich mittelfristig.

Neben dem zweckgemäßen Einsatz des Frameworks werden daher auch Beiträge zu dessen Verbesserung (neue, universell einsetzbare Bausteine, oder überarbeitete alte) besonders positiv gewertet.

Um Wildwuchs zu vermeiden, soll das Framework nicht im Quelltext von den Anwendungsentwicklern modifiziert werden. Es werden daher nicht die Quellen, sondern nur die übersetzte Fassung des Frameworks bereitgestellt.

Zur Termintreue

Wie unten ausführlich dargestellt, zerfällt die Projektentwicklung in fünf aufeinanderfolgende Phasen (Analyse, Einarbeitung, ..., Wartung), die zu festgelegten Zeitpunkten mit schriftlichen Ergebnissen und mündlicher Präsentation abgeschlossen werden. Auf Termintreue wird besonderer Wert gelegt. Bei  Nichteinhaltung eines Termins setzt der Betreuer dem Team eine Nachfrist von 2 - 3 Tagen. Teams, die auch am Ende der Nachfrist kein zufriedenstellendes Phasenergebnis vorgelegt haben oder die mehr als zwei Nachfristen benötigen, scheiden aus dem Praktikum ohne Schein aus. Vor dem Ausscheiden oder bei Terminüberschreitungen aus nicht von den Teilnehmern zu verantwortenden Gründen findet eine Konsultation zwischen Team, Tutor und Praktikumsleiter statt.

Ein Unterschreiten des Zeitplans ist erlaubt, sogar erwünscht!

Teams, die vorzeitig fertig werden, können sich früher auf die DVP-Vorbereitung konzentrieren.

Zur Transparenz

Die Betreuer und der Projektleiter müssen den Projektfortschritt kontinuierlich beobachten, um bei Fehlentwicklungen so früh wie möglich korrigierend eingreifen zu können. Bei den Ergebnispräsentationen am Ende einer Phase ist es dafür meist schon zu spät. Aus diesem Grund muß

  1. der Projektfortschritt laufend in Form der aktuellen Fassungen der geforderten Dokumente und Programme auf den gruppeneigenen WWW-Seiten dokumentiert werden, so daß alle Änderungen so rasch wie möglich sichtbar werden (spätestens am Ende der ersten Praktikumswoche und danach jeweils einen Tag vor der ersten Präsenattion muß das Material zur aktuellen Phase eingestellt sein);
  2. regelmäßig mündlich Bericht erstattet werden, und zwar wöchentlich zu den festgelegten Terminen (jeweils ca. 15 Minuten Bericht, anschließend Fragen) von jedem Team im Electronic Classroom der Fakultät, der dafür bereits reserviert ist. Dabei soll jedes Teammitglied seinen aktuellen Arbeitsbeitrag vorstellen und ggfs. Fragen dazu kompetent beantworten.

 

Die Abschlußpräsentation am Ende des Praktikums dauert eine Stunde je Team und dient der Abnahme der fertigen Arbeit.

Präsentationen wie die Endabnahme, die Zwischenberichte und Phasenabschlüsse sind von den Teams sorgfältig vorzubereiten. Insbesondere ist sicherzustellen, daß auf dem Vorführrechner im Electronic Classroom alles vor Beginn der Präsentation ablaufbereit vorliegt.

Während oder nach den Zwischenberichten und Phasenabschlüssen können noch Verbesserung eingefordert werden, da die Ergebnisse teilweise nicht in der gewünschten Ausführlichkeit vorhanden sind. Da es hierbei immer wieder zu Missverständnissen bezüglich der Anmerkungen gibt, möchte ich noch einmal auf folgendes hinweisen: Kritik wird meist nur an einigen Beispielen (fehlende Dokumentation an einem UML-Diagramm, fehlende Javadoc-Beschreibung der Klasse XYZ etc.) geäußert. Verstehen Sie dieses jedoch nicht nur als Aufforderung, das angesprochene Objekt zu ändern, sondern als Anweisung gemäß den am Beispiel gestellten Anforderungen die gesamte Dokumentation der Phase zu überarbeiten!

Zum "geistigen Eigentum"

Die offene Darstellung aller Zwischenergebnisse auf WWW-Seiten soll bewußt ein Klima der Kooperation auch über Teamgrenzen hinweg fördern (ganz im Sinne des Internet): Es ist ausdrücklich erlaubt, gute Ideen von anderen Gruppen sinngemäß für die eigenen Lösungen zu verwenden. Wichtigstes Ziel ist es, daß alle möglichst viel lernen - und dies bei den Präsentationen und durch die Qualität der eigenen Produkte nachweisen.

Natürlich ist es nicht erlaubt, fertige Dokumente oder Programmteile von anderen zu übernehmen (außer dem Framework). Begründete Ausnahmen sind mit der Praktikumsleitung im Einzelfall abzusprechen (und auch entsprechend zu kennzeichnen).

Ein Tipp: Sehen Sie sich mal die WWW-Seiten der letztjährigen Praktikumsgruppen an (und versuchen Sie, es noch besser zu machen)! Als Vorbild für den Inhalt nehmen Sie bitte die Ergebnisse des letzten Jahres, zu empfehlen sind z.B. die Gruppen der diesjährigen Tutoren (1, 2, 3, 5, 10 und 12).

3. Die beteiligten Personen

Unterschiedliche Personenkreise sollen zum Gelingen des Praktikums beitragen, teilweise sogar in mehreren Rollen.

a) Der Praktikumsleiter (Michael Ebert)

Als Praktikumsleiter bin ich für die Durchführung des Praktikums verantwortlich. Meine wichtigste Aufgabe während der Durchführung des Praktikums ist die Kontrolle der Arbeitsleistung der Studenten und die entsprechende Vergabe der Scheine. Zu diesem Zweck werde ich laufend

  • die Zwischenergebnisse auf den WWW-Seiten,
  • die gezeigte Termintreue und
  • die Arbeitsqualität beobachten,
  • den Präsentationen beiwohnen und
  • die Betreuer nach ihrem Eindruck befragen.

Meine Kommentare und Hinweise werde ich in der Regel über die Betreuer an die Teams weitergeben lassen.

 

b) Die Betreuer/Auftraggeber

Acht Studenten des Jahrgangs 2003, die im letzten Herbst selbst das Praktikum erfolgreich absolviert haben, übernehmen die Betreuung der Teams:

Marc Akkermann
Dominik Oesterreich
Michael Domberg
Christoph Linnenbaum
Andreas Hänel
Michael Neumann
Matthias Jung
Jörn Schulz

 

Alle Betreuer haben gegenüber ihrem Team zwei Rollen:

  • als Vertreter des Auftraggebers handeln Sie im den Teams die genaue Aufgabenstellung aus und lassen sich laufend über den Arbeitsfortschritt berichten;
  • als Berater stehen Sie den Teams jederzeit mit Rat zur Verfügung, wenn dort technische oder organisatorische Probleme auftreten, die nicht vom Team selbst gelöst werden können.

 

Tipp an die Teams: In Zweifelsfällen lieber frühzeitig die Betreuer fragen, als durch Mißverständnisse wertvolle Arbeitszeit vergeuden !

c) Die Studenten

Die Projektaufgaben werden von Studententeams weitgehend autonom bearbeitet. Ein Team besteht aus 7 - 8 Studenten, die alle als Entwickler arbeiten und einzeln für bestimmte Programmteile, deren Entwicklung und Dokumentation verantwortlich sind. Das Team ordnet dreien seiner Mitglieder zusätzliche Rollen zu:

  • der Chef des Teams koordiniert die Zusammenarbeit im Team und fungiert als Sprecher nach außen;
  • der Stellvertreter des Chefs übernimmt dessen Aufgaben (bei Erkrankungen o.ä.)
  • der Dokumentar des Teams ist zuständig für die Präsentation auf den WWW-Seiten. Dazu erhält er fertige Beiträge von den Teammitgliedern, die er ggf. redaktionell überarbeitet, verlinkt, versioniert und sichert.

 

Die insgesamt 12 Teams sollen möglichst leistungsähnlich sein (also nicht Teams aus lauter Starken oder lauter Schwachen). Falls wider Erwarten keine vernünftige Teameinteilung zustande kommt oder Streitigkeiten entstehen, behalte ich mir Änderungen vor.

Sollte ich Hinweise bekommen oder auf Präsentationen den Eindruck bekommen, daß einzelne Teammitglieder ihren Beitrag nicht leisten, dann werde ich (nach Rücksprache mit dem Teamchef und Betreuer) diese Studenten abmahnen und ggfs. aus dem Praktikum ausschließen.
Ein solches Verhalten empfinde ich als äußerst unkameradschaftlich, da es Kommilitonen Zusatzarbeit aufbürdet. Teamchefs dürfen dies im Interesse der anderen Teammitglieder nicht dulden!

 

Die WWW-Seiten der Gruppen:

 

 

Weitere Links sind im folgenden zu finden:

 

d) Die Ansprechpartner für die Technik

Bei Fragen im Zusammenhang mit den Gruppenkennungen auf den Institutsrechnern wenden Sie sich bitte an Frau Beckh.

Bei Fragen betreffend die Rechner und Geräte des Electronic Classrooms wenden Sie sich bitte an Herrn Langer.

4. Phasen, Dokumente und Termine

Das Praktikum wird in fünf aufeinanderfolgenden Phasen nach folgendem Zeitplan durchgeführt (vgl. auch Regelungen zur Termintreue):

Phase Beginn am Ende am
1: Analyse 04.10. 21.10.
2: Einarbeitung 22.10. 04.11.
3: Design & Prototyp 05.10. 18.11.
4: Implementierung 19.11. 02.12.
5: Wartung 03.12. 16.12.

Jeweils (allerspätestens!) eine Woche vor Phasenende (also zur Zwischenpräsentation) muß ein wesentlicher Teil erledigt und auf den WWW-Seiten dokumentiert sein.

Die WWW-Dokumentation soll phasenweise organisiert sein, damit der Projektfortschritt sichtbar bleibt. An jedem Phasenende soll deshalb die Dokumentation zur Phase "eingefroren" werden. Wird ein Dokument in einer späteren Phase aktualisiert (modifiziert bzw. erweitert), dann sollen diese Änderungen an einer Kopie des Dokuments vorgenommen werden.

ZumSchluß erfolgt die Endabnahme.

Beginnen Sie ihr Praktikum indem Sie:

  • Rollen im Team festlegen
  • WWW-Startseite einrichten
  • Werkzeuge (wieder?) beschaffen

Nun zu den einzelnen Phasen:

Phase 1: Analyse

Zweck dieser Phase ist es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten und die Anforderungen des Auftraggebers zu erkennen. Die Reihenfolge der Arbeitsschritte, mit denen Sie sich der Aufgabe nähern ist sehr wichtig, da jeder folgende Schritt auf die Ergebnisse und das Wissen aus dem vorigen Schritt aufbaut. Deswegen ist es von besonderer Wichtigkeit, die unten angegebenen Dokument der Phase 1 auch in der Reihenfolge auszuarbeiten.

Gehen Sie wie folgt vor.

  1. Identifizieren Sie anhand der Themenbeschreibung einige wichtige Anwendungsfälle (engl.: Use-Cases). Diese Anwendungsfälle sollen durch kurze Teilsätze (z. B.: "Kunde anlegen", "Photoauftrag im Internet annehmen") beschrieben werden. Die Liste dieser Anwendungsfälle soll alle möglichen durch die Aufgabe implizierten Funktionalitäten des Programms wiedergeben. Ordnen Sie die Anwendungsfälle ihren realen Benutzern zu.
  2. Spielen Sie konkrete Szenarien zu diesen Anwendungsfällen durch (mitprotokollieren!) und stellen Sie dabei CRC-Karten auf (ebenfalls aufschreiben). Die Szenarien basieren auf den Anwendungsfällen. Sie sollen konkrete vorstellbare Abläufe innerhalb des Programms wiederspiegeln, z. B. "Nicht registrierter Kunde sendet Photoauftrag per Post ein". Jedes Szenarium soll so detailliert wie möglich beschreiben, welche einzelnen Programmeinheiten und -datenstrukturen beteiligt sein werden. Aus der in den Szenarien dokumententierten Interaktion zwischen diesen Einheiten lassen sich dann die CRC-Karten ableiten. Nutzen Sie dazu auch das Mittel der CRC-Kartensitzungen, um die Szenarien eventuell detaillierter zu gestalten. Dokumentieren Sie Szenarien und CRC-Karten auf der Webseite ausführlich.
  3. Suchen Sie nach Aspekten, die in der Aufgabenstellung nur angedeutet sind oder ganz fehlen könnten. Behandeln Sie diese analog.
  4. Erst wenn Sie alle möglichen Aspekte in den bisher angegeben Schritten behandelt haben, ordnen Sie die gefundene Funktionalität in einer Prioritätenliste an, wobei Sie aus Anwendersicht (!) unterscheiden sollten,
    • was das zu erstellende Programm auf jeden Fall leisten muß (siehe Schlußsatz zu Phase 3);
    • was es darüber hinaus leisten soll (siehe Phase 4);
    • welche Dinge es noch leisten kann, wenn dafür die Entwicklungszeit reicht.
    Stellen Sie die Prioritätenliste erst auf, nachdem Sie sich gründlich mit der Aufgabenstellung auseinandergesetzt haben (unter 1.-3. beschriebene Aktivitäten)! Natürlich möchte man so bald wie möglich wissen, was insgesamt zu leisten ist. Bevor man beim Auftraggeber mit einem konkreten Vorschlag Erwartungen weckt, sollte man aber deren Umsetzbarkeit prinzipiell durchdacht haben. Aus Auftraggebersicht sollte der Plan ein attraktives Produkt mit abgerundeter Funktionalität skizzieren. Das ein oder andere geplante "Highlight" zeigt dem Kunden, daß die Entwickler seine Interessen im Auge haben.
  5. Legen Sie diese Arbeitsergebnisse (CRC-Karten, Ablaufprotokolle zu Szenarien, Prioritätenliste) dem Auftraggeber vor. Klären Sie mit ihm Zweifelsfälle ab und verhandeln Sie über die Prioritäten,  die am Ende (!) der Analysephase "verbindlich" festgelegt werden - nicht vorher, sonst ist es sinnlos, weiter zu analysieren.
  6. Erstellen Sie auf der Basis der bisherigen Ergebnisse
    • ein vorläufiges, aber ausführliches Benutzerhandbuch (hier kann bisher Vergessenes auftauchen);
    • ein UML-Klassendiagramm, welches die statischen Zusammenhänge der gefundenen Kassen beschreibt; dokumentieren Sie diese Zusammenhänge und vernachlässigen Sie die Prozesssicht in UML-Klassendiagramm. Relevant sind hier die Organisation der Informationen.
    • zu den komplizierteren Anwendungsfällen UML-Sequenzdiagramme bzw. UML-Aktivitätsdiagramme.
    Die Dokumentation dieser Phase soll für den Kunden, d.h. für Laien lesbar sein. Vermeiden Sie daher programmiertechnische Termini und verwenden Sie die Sprache des Anwendungsbereichs (z.B. bei Klassennamen).
  7. Revidieren Sie anhand der zusätzlichen Dokumente Ihre Prioritätenliste und legen Sie alles nochmals dem Auftraggeber zur Zustimmung vor.

Anforderung: Verwenden Sie für die von Ihnen entwickelten Klassen, Methoden und alle anderen Programmbezeichner durchgängig englische Bezeichnungen. Halten Sie Ihre Kommentare im Quellcode, Webseite und die darin befindliche Dokumentation allerdings auf deutsch!

Hinweis: Achten Sie darauf, eine realistische, d.h. erfüllbare Anforderungsliste zu erstellen. Lassen Sie sich dabei von groben Aufwandsabschätzungen leiten. Bieten Sie umgekehrt dem Auftraggeber Funktionen an, die Sie leicht implementieren können.

Phase 2: Einarbeitung

Ziel der Einarbeitungsphase ist es, sich mit dem SalesPoint/EPoint-Framework vertraut zu machen. Dazu soll das Tutorial und die kleine Beispiel-Applikation "Videoverleihautomat" (SalesPoint), bzw. "TicketService" (EPoint) durchgearbeitet und etwas modifiziert werden. Die Vorgaben für die Modifikationen am Videoverleihautomten finden Sie hier (pdf) und die für den TicketService sind hier zu finden.

Für beide Frameworks gibt es Dokumentation. Die des SalesPoint-Frameworks (hier) ist bereits sehr ausgereift, die des EPoint-Frameworks (hier) ist in den ersten Versionen vorhanden. Da die Struktur des EPoints stark an die des SalesPoints, was Cataloge, Prozesse und GUI angeht, angelehnt ist, sollten sich die Nutzer des EPoints erst einen groben Überblick des SalesPoint-Frameworks verschaffen.

Verwenden Sie die erste Tage dieser Phase, um sich intensiv in die Framework-Dokumentation einzuarbeiten (Alles ansehen, besonders gründlich die Überblicksseiten und das Tutorial).

Danach soll der "Videoverleihautomat" überarbeitet werden. Gehen Sie dabei analog zum Tutorial vor, wo auch alle benötigten Techniken beschrieben sind. Erstellen Sie entsprechende Dokumente (s.u.) und legen Sie sie ins Netz (auch schon im halbfertigen Zustand; laufend dort aktualisieren!). Bearbeiten Sie oben zum Herunterladen bereitgestellten Aufgaben. Pflicht sind A.*, B.2, B.4, C.2 und C.5. Alle anderen Aufgaben können zur weiteren Übung auch bearbeitet werden. Die zu bearbeitende Videomaschine, das Framework, etc. finden unter "Wichtige Informationen".

  • UML-Klassendiagramm zum modifizierten Videoverleihautomaten (falls erforderlich, in übersichtliche Teildiagramme aufteilen!)
  • Quellen und übersetzte Programme in zip- bzw jar-Files.
  • javadoc-Dokumentation der modifizierten Quellen
  • Kurzgefasstes Handbuch (alle Menüpunkte kurz (!) erläutern und ein paar Screenshots zur Illustration verwenden).

 

Phase 3: Design & Prototyp

Ziel dieser Phase ist es, die Gesamtstruktur der Implementierung zu entwerfen sowie wichtige bzw. kritische Funktionen in einem Prototyp zu implementieren und dem Auftraggeber zur Verfügung zu stellen, damit sein Feedback dazu in der nächsten Phase berücksichtigt werden kann.

Ein genauer Abgleich zwischen dem Analyseergebnis und der Beschreibung des Frameworks ist erforderlich, um festzustellen

  • welche der geforderten Funktionen das Framework abdeckt;
  • welche weiteren Funktionen es nach Anpassungen ("wie genau sehen die aus?") abdeckt;
  • was darüber hinaus zu ergänzen und wie einzubinden ist.

 

Die Verantwortlichkeiten der in der Analysephase gefundenen Klassen müssen dabei solchen Klassen des Frameworks zugeordnet werden, die eben dies schon leisten, oder solchen anwendungsspezifischen Unterklassen von Frameworkklassen, die zwecks Anpassung an die konkrete Problemstellung einzurichten sind. Es entstehen neue Klassenbeschreibungen und ein neues statisches Klassendiagramm. (An diesem Diagramm und dem aus der Analysephase werden die Gemeinsamkeiten und die Unterschiede zwischen Analysemodell und zu implementierendem Modell deutlich.)

Wichtige Anpassungsschritte sind:

  • die Festlegung konkreter Katalogs- und Bestandsklassen;
  • die Umsetzung von Anwendungsfällen in SaleProcesses (mit Hilfe von Zustandsübergangsdiagrammen, die jetzt auszuarbeiten sind);
  • die Darstellung von Katalogen und Beständen (nebst Sortierung und Filterung) in der grafischen Oberfläche; Bereitstellung von Operationen über Menüpunkte und Knöpfe (das Benutzerhandbuch ist entsprechend zu aktualisieren).

Dokumentieren Sie ausführlich die Gründe für Ihre Anpassungsentscheidungen. Falls sich bereits änderungen gegenüber der Analyse Phase ergeben, sind diese auch zu erläutern, mit Referenz auf die Ergebnisse der dieser Phase und einer Begründung der geänderten Struktur.

 

 

In dieser Phase fallen folgende Ergebnisse an:

  • Ergebnis des Abgleichs: Klassenbeschreibungen und statisches Klassendiagramm einschließlich textueller Dokumentation (Konzepte, Zusammehänge);
  • Arbeitsplan: welcher Entwickler für welche Klassen zuständig ist (wann Fertigstellung?);
  • Aktualisiertes Benutzerhandbuch mit vollständiger Menübeschreibung;
  • Zustandsübergangsdiagramme zu den Anwendungsfällen, bzw. den erstellten Prozessen;
  • Zum erstellten Prototypen:
    • javaDoc-Dokumentation mit Erläuterungen zur Implementierung im Stil der Framework-Dokumentation. Zusätzlich soll der Zusammenhang zur Aufgabe und zur technischen Dokumentation hergestellt werden, und zwar in Form von HTML-Links in die bestehende Dokumentation (an relevante Stellen des Handbuchs, auf UML-Diagramme usw.). Dadurch werden Querbezüge sichtbar und gleichzeitig Dokumentationsaufwand und Wiederholungen in einem erträglichen Rahmen gehalten.
    • Quellen und übersetzte Programme in zip- bzw. jar-Files.
  • Dokumentation jeglicher Anpassungsschritte an das genutzte Framework. Diese kann in die obigen Dokumente einfließen, beispielsweise im Klassendiagramm durch Oberklassen, sollen aber auch textuell begründet werden.
  • Falls sich bereits Modellierungsänderungen gegenüber der vorigen Phase ergeben sollten, so sind diese ausführlich zu begründen und zu dokumentieren.

 

Der Prototyp soll im Wesentlichen die Rubrik "muß" der Prioritätenliste erfüllen.

Phase 4: Implementierung

In dieser Phase wird der Prototyp zum vollständigen Programm ausgebaut. Dabei sind in der Regel die Rubriken "muß" und "soll" der Prioritätenliste vollständig zu erfüllen. Abweichungen davon bitte frühzeitig mit Betreuer und Praktikumsleiter absprechen!

Die Ergebnisse aus der letzten Phase werden vervollständigt und aktualisiert. Auch hier gelten die gleichen Anmerkungen bezüglich der Ausführlichkeit der zu erstellenden Dokumentation.

Ausgiebige Tests mit anschaulichen Testdaten stellen sicher, daß das Programm robust funktioniert (die Daten werden für Vorführungen ohnehin benötigt).

Phase 5: Wartung

In diese Phase werden verbliebene Fehler ausgemerzt und kleinere Ergänzungswünsche des Auftraggebers erfüllt. Es werden also alle in der Implementierungsphase noch nicht behobenen Fehler beseitigt, allgemein noch nicht befriedigende Arbeitsergebnisse überarbeitet und vervollständigt.

Durch Erfüllen zusätzlicher Anforderungen des Auftraggebers soll nachgewiesen werden, daß das erstellte Programm so entworfen und implementiert wurde, daß Änderungen ohne großen Aufwand möglich sind.

Bei entsprechender Zufriedenheit der Auftraggeber kann diese Phase teilweise oder ganz erlassen werden.

Endabnahme

Folgender Ablauf der Endabnahme ist vorgesehen:

  • Zuerst präsentiert das Team gemeinsam in einer 10-minütigen Demo das erstellte Programm.
  • Der Teamchef gibt dann anhand der erstellten Dokumente einen Überblick über Entwurf und Implementierung, insbesondere später notwendige Änderungen (5-10 Minuten).
  • Anschließend erläutern die einzelnen Teammitglieder (jeder etwa 5 Minuten lang) ihren Entwicklungsbeitrag, indem sie ihn
    • in den Gesamtentwurf einordnen;
    • interessante Stellen / Probleme herausgreifen und erläutern;
    • Fragen zu Entwurf und Programmtext beantworten.
  • In einer abschließenden Manöverkritik werden Erfahrungen ausgetauscht (vor allem konstruktive Verbesserungsvorschläge sind willkommen!).

 

5. Wichtige Informationen, Werkzeuge, Links

Framework:

Sämtliche Informationen zum Framework SalesPoint sind über diese Seite zugänglich. Die einander ergänzenden Beschreibungen sollen Ihnen den Einstieg in das Framework und in seine Verwendung erleichtern:

  1. eine Übersicht , die an den Aufbau, die Komponenten und die Anpassungsschnittstelle heranführt;
  2. die VideoMachine, das die Verwendung anhand des relativ einfachen Beispiels "Videoverleihautomat" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungendienen kann;
  3. die javaDoc-Beschreibung des Frameworks, in die unter der Rubrik Hooks auch die Beschreibung der Anpassungsschnittstellen und ihrer Verwendung (in Form von "how to"-Rezepten) integriert ist.
  4. Eine erweiterte Form der Hooks, die HowTo's finden Sie unter: HowTo's.

 

Alle Beschreibungen enthalten technische Anteile, die möglicherweise erst beim wiederholten Lesen oder aufgrund eigener Erfahrungen verständlich werden. Also öfter mal wieder zu Hand nehmen - das könnte sehr nützlich sein!Während die Übersicht und das Tutorial fortlaufend gelesen werden sollten, wird man die javaDoc-Beschreibung zum Nachschlagen und zur Klärung von Zweifelsfällen verwenden.

Werkzeuge und Links:

Es empfiehlt sich, bei der Anwendungsentwicklung die gleichen Werkzeuge einzusetzen, die auch bei der Entwicklung von Framework und Tutorial (und in den Übungen zur Einführungsvorlesung, siehe auch dort angegebene Links!) verwendet wurden:

Sehr viel Wissenswertes über Java und OO allgemein ist auf folgenden Seiten zusammengetragen worden:

 

Wenn Sie UML-Diagramme mit CASE-Werkzeugen erstellen und pflegen wollen, finden Sie hier zwei nützliche Systeme:

 

Wer WWW-Seiten pflegt, kann dazu den Netscape Composer verwenden oder sich gründlicher mit HTML befassen:

  • SelfHTML ausführliche Beschreibung aller Aspekte von HTML
  • Anleitung und Download-Seite zu einem nützlichen HTML-Editor (Freeware)

 

Together 6.2

Seit einiger Zeit verfügen wir über wir über eine Together-Campuslizenz. Die Sekretäre interessierter Gruppen mögen sich bitte an Frau Beckh wenden! Nachdem Sie sich die Lizenz von Frau Beck besorgt haben, können Sie die Software von argonaut.informatik.unibw-muenchen.de herunterladen (mit Hilfe ihres SSH-Clients. Verzeichnis: /local/src/Together6.2) oder eine CD von Frau Beckh ausleihen.

 

Zum Einloggen in die Homeverzeichnisse

(auf argonaut.informatik.unibw-muenchen.de) wird SSH benötigt. Für Windows eignet sich dieser Client, da er neben dem Terminallogin auch eine Dateitransferumgebung bereitstellt. Für Unix-Systeme bietet sich OpenSSH an.

 

6. Literatur:

Eine kleine, subjektive Auswahl von Büchern, die für das Praktikum von Nutzen sein können:

 

  1. D. Flanagan: Java (Examples) in a Nutshell. O'Reilly, 1999 (3. Aufl.). Kompetente Einführung in Java, viele Beispiele, systematische Klassenübersicht.
  2. T. Budd: Understanding Object-Oriented Programming with JAVA. Addison-Wesley, 1998. Gute allgemeine Einführung in OOP mit Bezug zu Java (auch viele Beispiele).
  3. E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Addison-Wesley, 1995. Die Autoren (werden auch als "gang of four" bezeichnet) haben die "Pattern-Bewegung" mit diesem Buch eingeleitet. Das Buch stellt auch die OO Grundbegriffe klar und im Zusammenhang dar.
  4. N. Wilkinson: Using CRC Cards. SIGS Books, 1995. Ausführliche Darstellung der CRC-Karten und ihrer Verwendung in allen Phasen der Entwicklung.
  5. R. Wirfs-Brock, B. Wilkerson, L. Wiener: Objekt-Orientiertes Software-Design. Hanser-Verlag, 1993. Umfassende Einführung in OO Analyse und verantwortungsbezogenen Entwurf, beschreibt iteratives Vorgehen bei der Entwicklung: insgesamt OO-Vorgehen pur.
  6. I. Sommerville: Software Engineering. Addison-Wesley, 1996. Eine prägnante Übersicht über alle Aspekte der Software-Entwicklung und der einschlägigen Techniken (nicht nur aus dem OO Bereich).

 

Praktikum: SalesPoint V3.1 Homepage EPoint 1.0 Einführungsvortrag (Praktikumsleiter) Einführungsvortrag I (SalesPoint) Einführungsvortrag II (SalesPoint) Einführungsvortrag (EPoint)
SalesPoint Framework v3.1

Fragen und Anregungen zu dieser Seite bitte an

Michael Ebert

... zurück zur Praktikumsseite ...

 

Shortcuts zu den Aufgaben

  1. Der kleine Magic-Laden
  2. Online DVD-Verleih
  3. Stundenplanungsprogramm für die MSM
  4. Zum lustigen Studenten
  5. Call-a-Cocktail
  6. Studienverwaltung
  7. Winf-O-Mania (EPoint)
  8. Projektverwaltung (EPoint)
  9. Schwarzes-StudFBer-Brett (EPoint)
  10. Wohnbereich-Verwaltung
  11. Low Budget Fluglinie LoBuFLY
  12. Autovermietung FastRent

 

Die Aufgaben

 

  1. Der kleine Magic-Laden - Betreuer: Matthias Jung - Präsentation: 10.00 Uhr - 10.30 Uhr - zum Seitenanfang

    Der kleine Magic-Laden erlebt einen Inhaberwechsel. Der neue Besitzer stellt fest, dass die von seinem Vorgänger verwendete Verwaltungssoftware veraltet und sogar fehlerhaft ist. Er beschließt, ein neues System einzusetzen und betraut ihr Unternehmen mit der Ausarbeitung und Umsetzung.

    Das Geschäft verkauft Produkte des Sammelkartenspiels "Magic: The Gathering" (Einzelkarten, Booster, Decks, Zubehör etc). Diese werden von einem Großhändler bezogen und direkt an die Kunden verkauft. Neben der Unterstützung der obligatorischen Geschäftsprozesse (Verkauf, Nachbestellung, Bilanzierung, ...) plant der Besitzer auch eine Erfassung der Stammkunden. Diese sollen dann mit gezielten Informationen (Sonderangebote, Turniere, Gewinnspiele) bedacht werden können, sofern sie dies wünschen.

    Den Stammkunden soll weiterhin die Möglichkeit geboten werden ihre zum Teil recht umfangreiche Kartensammlung verwalten zu können. Hierbei soll folgendes möglich sein:

    • eine Übersicht über sämtliche Karten
    • anzeigen aller relevanten Eigenschaften einer Karte (am besten mit Bild)
    • geeignete Suchmöglichkeiten in den Karten
    • sinnvolle Sortier- und Filtermöglichkeiten, so dass z.B. nur bestimmte Kartentypen angezeigt werden können
    • Gliederung der Karten in selbstdefinierbare Kategorien, um die Zusammmenstellung von Decks zu unterstützen
    • eine aussagekräftige Statistik über die ganze Sammlung bzw. die einzelnen Kategorien
    Ein weiterer Vorteil der angebotenen Kartenverwaltung ist die Möglichkeit, die verwalteten Karten den anderen Stammkunden zum Verkauf oder Tausch anzubieten.

    Weiterhin sind in regelmäßigen Abständen Spielabende geplant. Hierbei stellt der Inhaber die Räumlichkeit zur Verfügung, so dass Kunden direkt im Geschäft spielen können. Alle Spiele sollen mit Ergebnis gespeichert werden, so dass eine interne Rangliste der Spieler erstellt werden kann. Auch kleine Turniere unter den bestplatzierten Spielern sollen regelmäßig veranstaltet werden. Die Einladungen hierfür soll das System automatisch erstellen.

    Schließlich ist für die nahe Zukunft die Errichtung einer Internetplattform geplant. Natürlich soll in erster Linie der Verkauf per Online-Shop realisiert werden. Dies bedeutet u.a. Präsentation des Angebots im Web, Versendung der Waren per Post sowie eine neue Zahlungsart (Rechnung, Überweisung). Weiterhin sollte natürlich die Kartenverwaltung für die Stammkunden sowie deren Verkaufsmöglichkeit auch über das Internet möglich sein. Auch die Kundeninformationen sollen auf Wunsch per eMail zugestellt werden können.

    Fakten zum Spiel:

    • für 2 und mehr Spieler
    • Partie wird mit 60 oder mehr Karten pro Spieler begonnen ("Deck")
    • einzelne Karte über Namen eindeutig identifiziert, besitzt weitere Eigenschaften
    • gewonnen hat, wer zuerst Lebenspunkte des Gegners auf 0 reduziert
    • komplette Regeln und weitere Informationen sind erhältlich auf der Homepage des Spiels oder per Nachfrage beim Auftraggeber

     

  2. Online DVD-Verleih - Betreuer: Jörn Schulz - Präsentation: 10.45 Uhr - 11.15 Uhr - zum Seitenanfang

    Da Onlinevideotheken in letzer Zeit wie Pilze aus dem Boden schießen, möchte die Firma DVD Online Verleih (DOV) sich auch ein Stück vom Kuchen abschneiden. Alles was ihr im Moment noch fehlt (ausser einem Kundenstamm und Kapital) ist eine leistungsfähige Software. Deshalb wurde ihre Firma zunächst mit der Erstellung eines Prototyps beauftragt.

    DOV will seinen Kunden verschiedene Abonement-Modelle anbieten. Die Abonements ermöglichen dem Kunden für einen festen monatlichen Betrag, eine bestimmte Anzahl von DVDs so oft zu tauschen (auf dem Postweg), wie er möchte. Die Abonements unterscheiden sich im Monatsbeitrag (im Moment 10, 20 bzw. 30 Euro) und in der Anzahl der gleichzeitig ausgeliehenen DVDs (im Moment 2, 4 bzw. 6). Neben dem Monatsbeitrag trägt der Kunde auch die Portokosten.

    Damit die DVDs von Abo-Kunden verzugsfrei getauscht werden können, muss der Kunde eine Wunschliste mit seinen Wunschfilmen anlegen. Diese muss mindestens zehn mal mehr Filme enthalten, als er gleichzeitig ausleihen kann (also im Moment 20, 40 und 60). Die Wunschliste ist linear geordnet und spiegelt die Präferenz des Kunden wieder. Der Kunde soll die Liste natürlich beliebig umsortieren, Filme daraus entfernen und Filme hinzufügen können. Weiterhin soll er aus der Liste direkt in eine Detailanzeige der Filme kommen. Weiterhin sollen dem Kunden die Filme angezeigt werden, die er schon ausgeliehen hat. Auch von dieser Ansicht soll er zu den Film-Details kommen.

    Da es dem durschnittlichen Kunden nicht besonders leicht fallen wird so viele Filme auf seine Wunschliste zu setzen, ist für die Filmeverwaltung besondere Sorgfalt geboten. Zunächst sollen für alle ausleihbaren Filme Details angegeben werden können, z.B. Genere, Schauspieler, Regiseur, Handlungszusammenfassung etc. Diese werden in der schon erwähnten Detailansicht angezeigt, nach diesen Details und dem Titel soll aber auch gesucht werden können. So soll es z.B. möglich sein, alle verfügbaren Filme, in denen Bruce Willis mitgespielt hat, anzeigen zu können. Wünschenswert wäre darüberhinaus, dass Informationen nicht nur zu Filmen, sondern auch zu Schauspielern, Regisseuren etc. verwaltet werden können.

    Zusätzlich zu den festen Details, soll es den Kunden möglich sein, Noten für bestimmte Filme zu vergeben und kurze Kommentare zu den Filmen zu schreiben. Die Kommentare werden den anderen Kunden direkt zugänglich gemacht, aus den Noten dagegen wird eine Durchschnittsnote berechnet und angezeigt. Allerdings muss zuerst eine festlegbare Anzahl an Noten abgegeben worden sein, bevor eine Durchschnittsnote überhaupt berechnet und angezeigt wird.

    Um den Kunden das Anlegen der Wunschliste weiter zu vereinfachen werden Empfehlungen ausgesprochen. Diese untergliedern sich in verschiedene Gruppen. Zum einen werden die Filme mit dem besten Notendurchschnitt empfohlen, zum anderen die Filme, die am meisten ausgeliehen wurden, bzw. auf den meisten Wunschlisten stehen. Dies soll jeweis global, als auch nach Generes geschehen. Weiterhin werden einem Kunden A Filme empfohlen, die von den anderen Kunden ausgeliehen und gut bewertet wurden, die ähnliche Filme wie Kunde A ausgeliehen haben. Es sollen aber immer nur Filme empfohlen werden, die der Kunde noch nicht ausgeliehen oder noch nicht auf seiner Wunschliste hat.

    Natürlich muss das Programm auch das Verwalten der Kunden (Erstellen von Rechnungen, merken welcher Kunde welche DVD hat, Eingang von zurückgesendeten DVDs, Angabe, welche neue DVDs an wen versendet werden sollen, aktualisieren der Listen usw.) ermöglichen. Weiterhin soll ein Kunde per eMail informiert werden, wenn seine zurückgesendeten DVDs eingegangen sind bzw. welche neuen DVDs an ihn versendet wurden. Weiterhing sollen Statistik- und Bilanz-Funktionen enthalten sein.

     

  3. Stundenplanungsprogramm für die MSM - Betreuer: Jörn Schulz - Präsentation: 11.15 Uhr - 11.45 Uhr - zum Seitenanfang

    Für diese Aufgabe wurde ein Pflichtenheft durch die Marineschule Mürwik erstellt. Das geforderte Programm soll prototypisch realisiert werden. Algorithmisch schwierige Aufgaben, wie automatisches Planen, sollen identifiziert, können jedoch ausgeklammert werden!

     

  4. Zum lustigen Studenten - Betreuer: Dominik Oesterreich - Präsentation: 12.15 Uhr - 12.45 Uhr - zum Seitenanfang

    Die Münchener Studentenkneipe Zum lustigen Studenten führt derzeit ihre gesamte Buchhaltung auf Papier. Da der Chef der Kneipe dieses System für veraltet hält, beauftragt er Sie, eine entsprechende Software zu entwickeln.

    In der Kneipe wird bargeldlos bezahlt. Zu diesem Zweck besitzt im lustigen Studenten jeder Gast ein Konto auf das er Einzahlungen vornehmen kann. Die Verwaltung der Konten sowie die Abrechnung ist die wichtigste Aufgabe, die durch diese Software geleistet werden soll. Jeder Gast kann seinen aktuellen Kontostand über das Programm abfragen, überprüfen, was er in den vergangenen vier Wochen zu welchem Preis verzehrt hat. Für die übrige Zeit kann er eine persönliche Statistik abrufen.

    Zusätzlich zum Konto bekommt jeder Gast einen Status, der manuell geändert werden kann. Nach diesem Status richtet sich u.a. der Preis für Bier. Im Moment gibt es folgende Status für die momentan folgende Preise gelten:

    Status Preis pro Bier
    Besitzer und spezielle Gäste 0,70
    Stufe 1 0,85
    Stufe 2 1,00
    Gast / Stufe 3 1,15

    Alle sonstigen Preise (z.B. für kleine Snacks) sind für alle Gäste gleich. Da Preislisten geändert werden können, soll aus Transparenz- und Statistikgründen eine Historie der Preisänderungen mit Datum gespeichert werden. Sind keine Bestellungen mit einer geänderten Preisliste bedient worden oder liegt eine Preisänderung länger als vier Wochen zurück und alle Konten sind für den Zeitpunkt der Preisänderung ausgeglichen, kann die Änderung manuell aus der Historie gelöscht werden.

    Wie auch in anderen Kneipen gibt es im Zum lustigen Studenten eine Glocke. Sollte diese Glocke betätigt werden, gibt der jenige eine Runde Bier an alle anwesenden Gästen aus. Derzeit werden alle Runden aufgeschrieben. Sollte jemand ein Bier bestellen wird in der aktuellen Freibierliste nachgeschaut, ob der jenige ein Freibier erhält. Gleichzeitig kann so festgestellt werden, wer das Bier ausgegeben hat. Jeder Gast soll dann über seine Kontostandabfrage auch angezeigt bekommen, ob (und von wem) er noch Freibiere genießen kann. Obwohl das System letzten Endes genau diese Verarbeitung unterstützen soll, ist für eine Übergangszeit das führen einer globale Liste aller Freibiere denkbar.

    Grundsätzlich gibt es Zeiten zu denen nur Freibier ausgegeben wird. Diese Option soll, nachdem alle sonstigen wichtigen Funktionen implementiert wurden, dem Geschäftsführer zur Verfügung stehen.

    Besonders wichtig ist dem Geschäftsführer, dass jederzeit eine aktuelle Statistik vorhanden ist. Diese Statistik soll neben dem aktuellen Kontostand und dem getrunken Bier (in Litern) eine Monatsstatistik enthalten. Dabei soll die Liste nach unterschiedlichen Kriterien sortiert werden können, auf jeden Fall muss aber nach dem aktuellen Status sortiert werden können. Weiterhin ist eine Funktion vorzusehen, um die Listen in HTML zu exportieren.

    Das Programm soll weiterhin verschiedene Termine verwalten und an sie erinnern können. Es gibt einfache Termine, wie z.B. ein Dart-Turnier, und Termine mit Wiederholung, wie z.B. gesetzlich vorgeschriebene Untersuchungen (Schankanlage) oder Geburtstage. Den Terminen kann eine Vorankündigungs-Nachricht und eine Fälligkeits-Nachricht zugeordnet werden. Für die Vorankündigung soll es möglich sein, einen eigenen Vorankündigungs-Zeitpunkt vor der Fälligkeit zu wählen (z.B. Vorankündigung eine Woche vor einem Geburtstag).

    Die Nachrichten werden dann, nach überschreiten des Vorankündigungs-Zeitpunkts, bzw. des Fälligkeits-Zeitpunkts, einer wählbaren Personengruppe beim Einloggen in das System automatisch angezeigt. So soll z.B. die Vorankündigung (Einladung) zum Dart-Turnier allen Gästen, die mindestes den Status Stufe 2 erreicht haben, angezeigt werden. Die Fälligkeits-Nachricht (also Heute ist Dart-Turnier) soll dagegen allen Gästen angezeigt werden. Die Vorankündigung und Fälligkeit der Schankanlagen-Untersuchung soll dagegen nur den Besitzern angezeigt werden.

    Vor einem Einsatz des Systems möchte der Geschäftsführer, dass ihm die Software präsentiert wird. Hierfür ist eine Simulation zu implementieren.


     

  5. Call-a-Cocktail - Betreuer: Marc Akkermann - Präsentation: 13.00 Uhr - 13.30 Uhr - zum Seitenanfang
    Gestern abend in der Badewanne (bei einem gepflegten Manhatten) hatten Leo die Idee für ein neues Geschäftsmodell: Ein Cocktail-Heimservice!

    Regelmäßig hatte er Lust auf einen Cocktail und nicht die richtigen Zutaten zu Hause (und wegen des Ladenschlussgesetztes auch keine Möglichkeit sie sich zu besorgen). Ein Problem waren natürlich die Fruchtsäfte, die man auf Grund der geringen Haltbarkeit direkt Verbrauchen musste (deshalb hatte er sich auch nur einen Manhatten gemacht, obwohl er eigentlich Lust auf einen Mai Tai hatte). Das gleiche gilt natürlich für das frische Obst für eine stilvolle Verzierung des Glases. Die Spirituosen konnte man zwar lange aufbewahren, aber um keine geschmackliche Langeweile aufkommen zu lassen, brauchte man sehr viele verschiedene.

    Sein Heimservice wird das Leben, für solch gequälte Seelen wie ihn, ein wenig lebenswerter machen. 24 Studen an 7 Tagen die Woche soll der Service erreichbar sein. Kurze Zeit nach der Bestellung wird der Cocktail in idealer Trinktemperatur ausgeliefert. Standardmäßig erhält man den Cocktail frisch zubereitet in einem klein Plastikbeutel luftdicht verpackt. Eis und Glasverzierung kommen in jeweils getrennten Beuteln.

    Wenn das nicht stilvoll genug ist, kann aus einer ganzen Palette an Service-Zusätzen gewählt werden.

    • Zuerst soll es möglich sein, passende Gläser zu bekommen. Hierfür gibt es die Möglichkeit billige Plastikbecher oder aber edle Gläser aus echtem Glas (diese können aus unterschiedlichen Stilrichtungen gewählt werden) zu kaufen. Die Gläser können gegen Pfand geliehen werden - die Plastikbecher nicht. Das Pfand entspricht dem Kaufpreis und wird einbehalten, falls die Gläser nicht spätestens bei der nächsten Bestellung zurückgegeben werden.
    • Werden Gläser bestellt, kann auch ein Zucker- oder Salzrand (wenn das zum Cocktail passt) mitbestellt werden.
    • Als Luxusoption stellt sich Leo vor,
      • dass der Cocktail vor Ort gemixt wird und
      • in passenden Gläsern mit
      • professioneller Verziehrung serviert wird.
      • Um das Luxuspaket abzurunden, ist der Auslieferer passend gekleidet - auch für die Kleidung kann unter verschiedenen Stilrichtungen gewählt werden.
      Die einzelnen Unterpunkte der Luxuxoption sollen auch einzeln bestellt werden können.
    • Das Sortiment des Heimlieferservices umfasst auch Snacks und kleine Knabberein, die passend zum Cocktail empfohlen werden sollen.
    • Vielleicht fallen Leo sogar noch mehr Zusatzoptionen ein.

    Was Leo nun noch fehlt ist eine leistungsfähige Software, die seine Idee optimal unterstützt. Mit diesem Anliegen tritt er an Sie heran. Neben der Möglichkeit Cocktails zu bestellen wird eine Produktverwaltung benötigt, in der die angebotenen Cocktails und ihre Rezepte verwaltet werden sollen, insbesondere auch alles, was zum Anbieteen der obigen Service-Optionen benötigt wird. So müssen z.B. für jeden Cocktail nicht nur alle benötigten Zutaten mit genauen Mengenangaben gespeichert werden, sondern auch Verzierungen für den Cocktail geeignet sind, welche Glasarten passen, was für die Zubereitung vor Ort an Barbesteck mitzuführen ist usw.

    Des weiteren wird eine Kundenverwaltung benötigt, in der Adressen, Anfahrtsbeschreibung und eine Statistik über den Kunden (Kauf- /Konsumverhalten) geführt werden soll. Ebenso muss verwaltet werden, ob der Kunde noch Gläser geliehen hat. Weiterhin wäre wünschenswert, mit Hilfe der Statistik dem Kunden anzubieten das Übliche zu bestellen. Der Auslieferer benötigt für den Kunden eine gedruckte Rechnung/Quittung, die das Programm bei jeder abgeschlossenen Bestelltung automatisch erstellen muss.

    Weiterhin sollen alle gelagerten Zutaten (mit Haltbarkeitsdatum), Gläser, Verziehrungen, Anzüge der Lieferer, Barbestecke für Zubereitung vor Ort etc. verwaltet werden. Ebenso benötigt er eine Verwaltung seiner Fahrzeugflotte, der Ice-Crusher etc. mit Wartungsintervallen (bei Fälligkeit soll automatisch erinnert werden!) und Auslastungsstatistik.

    Bei einer Bestellung soll unmittelbar überprüft werden, ob diese ausführbar ist, d.h. ob alle Zutaten auf Lager sind, ob ein Fahrzeug für die Auslieferung verfügbar ist, usw. Weiterhin soll dem Kunden mitgeteilt werden, wann er mit der Lieferung seiner Bestellung rechnen kann. Bei einer abgeschlossenen Bestellung sollen die verbrauchten Zutatenmengen automatisch aktualisiert werden. Unterschreiten die gelagerte Menge einer Zutat einen gewissen Meldebestand, soll autmatisch ein Bestellvorschlag generiert werden. Dieser soll akzeptiert, gelöscht oder in eine Warteliste aufgenommen werden können. Weiterhin muss das Zufügen neu gekaufter Ware möglich sein. Um in bestimmten Zeitabschnitten die logischen mit den tatsächlichen Beständen abzugleichen ist eine Inventurfunktion notwendig.

    In naher Zukunft plant Leo, dass eine Bestellung auch über das Internet getätigt werden kann. Die Möglichkeit hierzu, am besten über eine Simulation, soll im Programm vorgesehen sein.

    Da es sich um einen neuen Service handelt, ist es notwendig regelmäßig zu überprüfen, wie das Geschäft läuft. Hierfür wird eine Art Statistik/Buchhaltungs-Funktionalität benötigt, welche eine Übersicht über das ganze Geschäft ermöglicht. So zum Beispiel Gewinn-/Verlustrechung, Kundenübersicht, Kassenbuch, etc.

     

  6. Studienverwaltung - Betreuer: Marc Akkermann - Präsentation: 13.30 Uhr - 14.00 Uhr - zum Seitenanfang

    Als Student der Universität der Bundeswehr München bekommt man laufend zu hören, dass das Zeitmanagement eine große Herausvorderung im Studium darstellt. Als Informatikstudent fragt man sich daraufhin mitunter, welche Software eine genau auf diese Problemstellung zugeschnitten Hilfestellung gibt. Fast freiwilligig ;-) haben Sie sich deshalb entschlossen, in ihrem Programmierpraktikum eine (prototypische) Antwort auf obige Frage zu geben.

    Der zu erstellende Prototyp soll eine umfassende Verwaltung eines Studiums an der Universität der Bundeswehr München ermöglichen. Vorgesehen ist die Verwaltung einer StudFBerGrp pro Programminstanz. Es gibt verschiedene Interessengruppen mit unterschiedlichen Anliegen. Zumindest folgende können direkt identifiziert werden:

    • Die militärischen Vorgesetzten. Sie möchten eine Übersicht über akademische und militärische Leistungen. Weiterhin wollen Sie verpflichtende Veranstaltungen verwalten (eintragen, ändern, löschen, entschuldigte Soldaten merken) und Dienstpläne erstellen und drucken können. Auch Notizen mit Bezug auf (einen oder mehrere) Studenten oder Veranstaltungen sollen möglich sein.
    • Die akademische Seite. Sie ist nur an akademischen Leistungsnachweisen interessiert. Weiterhing möchte sie Termine für Prüfungen festlegen können, zu denen sich Studenten über dieses System anmelden können. Ebenfalls sollen Vorlesungen, Praktika, Studien-/Diplomarbeiten, Seminare und andere Veranstaltungen verwaltet werden können. Ebenso sollen Übungen mit Einsende-Aufgaben o.ä. organisiert werden können.
    • Die Studenten. Sie wollen ihre dienstlichen, akademischen und privaten Vorhaben koordinieren und über diese den Überblick behalten. Dies ist die Hauptanwendung und das Programm soll für diese Aufgabe optimiert sein.

    Jeder Student soll seine persönliche Planung anhand vorgegebener Termine (z.B. Dienstplan, Stundenplan) erstellen können. Er soll die Möglichkeit haben, für ihn interessante Veranstaltungen auswählen und mit Prioritäten versehen zu können. Weiterhin soll er eigene Veranstaltungen (d.h. fester Zeitraum, event. mit Wiederholung) bzw. Aktivitäten (nur Zeitbedarf festgelegt, dafür Milestones und Deadlines) anlegen können. Für Aktivitäten soll neben einer Priorität auch der aktuelle Erfüllungsgrad verwaltet werden können. Eigene Veranstaltungen können z.B. das wöchentliche Basketball-Training aber auch Urlaub sein, Aktivitäten können z.B. Studienarbeiten, Praktika, Lernen auf Prüfungen aber auch Vorbereitungsarbeiten für die Infomania sein. Weiterhin soll festgelegt werden können, welche Aktivität vor bzw. nach welchen anderen Aktivitäten erfolgen müssen und welche Hilfsmittel (z.B. Bücher, PC) dafür notwendig sind.

    Aus Aktivitäten und Veranstaltungen soll es dann möglich sein einen Wochenplan zu erstellen. Dies geschieht, indem Zeiträumen bestimmten Aktivitäten zugeordnet werden. Dafür ist eine gute Visualisierung (Wochen-/Tagesübersicht) notwendig. Diese soll zumindest alle Veranstaltungen, alle Zeiträume, denen Aktivitäten zugeordnet sind und alle Aktivitäten, für die noch Arbeit notwendig ist, umfassen.

    Um das Studienziel, das Bestehen des Studiums, nicht aus dem Auge zu verlieren, soll eine Noten- und Scheinverwaltung implementiert werden. Grundlage bildet die (geeignet konfigurierbare) Prüfungsordnung. Jeder Student kann die Scheine markieren die er ablegen will, zusätzlich kann bei benoteten Scheinen die angestrebte Note mit abgelegt werden. Jedem Schein, den ein Student ablegen will, wird in der Regel eine Aktivität zugeordnet, die als Ziel das Bestehen des Scheins hat. Das Programm soll den aktuell angestrebten bzw. den tatsächlichen Notendurchschnitt berechnen können, wenn alle Informationen vorhanden sind.

    Neben den akademischen sollen auch die militärischen Leistungen verwaltet werden. So zum Beispiel eine Übersicht über den aktuellen Stand des DSA oder wie viele Leistungsmärsche/Schießen schon abgelegt wurden (mit Ergebnis). Ebenso soll überprüft werden können, ob alle geforderten Leistungen erbracht wurden.

    Ebenfalls wünschenswert ist eine Art Statistikmodul in der gewisse Statistiken von Zugangsberechtigten schnell abgerufen werden können (zum Beispiel, wieviele Studenten ihre DVP-Zulassung schon haben, wieviele Sportabzeichen, etc.)

    Wie schon angeklungen spielt die Wahrung der Vertraulichkeit der Daten eine besonders große Rolle. Wegen der unterschiedlichen Nutzergruppen ist stets sicherzustellen, dass kein Nutzer Informationen sehen oder ändern kann, wenn er dazu keine Berechtigung hat. Die Zugriffsrechte müssen mindestens in Lese- und Schreibzugriffe aufgegliedert sein. Wünschenswert wäre allerdings eine feinere Abstufung. So will z.B. Student Hans, dass Student Paul, mit dem er zusammen an einer Studienarbeit arbeitet, sieht, wann er Zeit für diese Aktivität eingeplan hat. Für alle anderen Aktivitäten will Hans, dass Paul nur sieht, dass er in dieser Zeit beschäftigt ist, nicht aber, mit was. Der militärische und akademische Seite möchte Hans dagegen, grundsätzlich nichts über seine private Zeitplanung sichtbar machen.

     

  7. Winf-O-Mania (EPoint) - Betreuer: Christoph Linnenbaum - Präsentation: 14.15 Uhr - 14.45 Uhr - zum Seitenanfang

    Die Firma DistrEvents ist eine Event-Agentur, die sich auf die Bewirtschaftung von Parties spezialisiert hat. Auf diesen Parties stellt sie mehrere, voneinander unabhängige Getränketheken auf, richtet Lager für Getränke ein und stellt eine Kasse, sowie eine zentrale Verwaltung auf.

    Bisher wurden die Theken ad hoc mit Getränken beliefert und rechneten am Ende des Abends ab. Die zentrale Verwaltung hatte keine Übersicht über den momentanen Umsatz, den Lagerstand, und die anwesenden Besucher. Dadurch entstanden oft Lieferengpässe, da der zu erwartende Verbrauch nicht abgeschätzt werden konnte.

    Ihre Aufgabe ist es nun, ein System zu entwickeln und zu implementieren, dass zum einen die Bestellung, Abrechnung und Verwaltung automatisiert. Folgende Kernforderungen hat DistrEvents dabei gestellt.

    • Theken haben eine festgelegte Auswahl an Mixgetränken. Sie kennen ihren Bestand an Rohstoffen und den Meldebestand, bei dem eine Bestellung an das zuständige Lager abgesetzt wird.
    • Die Theke sammelt Geld ein und gibt Getränke aus.
    • Es gibt mehrere Theken mit unterschiedlichem Getränkeangebot.
    • Jede Theke ist genau einem Lager zugeordnet.
    • Lager haben einen Bestand an Rohstoffen für Getränke. Jedes Lager kennt seinen Bestand und die Theken, die ihm zugeordnet sind.
    • Jedem Lager sind eine oder mehrere Theken zugeordnet.
    • Das Lager kann manuelle Lieferungen von Rohstoffen erhalten.
    • Kassen sammeln die Eintrittsgelder der Gäste ein. Dabei zählen sie die Anzahl der Gäste. Da nicht immer sichergestellt werden kann, dass die Gäste die Veranstaltung über eine Kasse verlassen, können die Gäste, die die Veranstaltung verlassen nicht gezählt werden. Hierfür ist eventuell ein Schätz-Mechanismus vorzusehen.
    • Der zentrale Server kennt alle angeschlossenen Theken, Lager und Kassen. In ihm wird das Geld der Theken und Kassen gesammelt.
    Die Geschäftsführung kann Rezepte an Theken schicken, den Bestand an Rohstoffen sowohl in Theken, als auch in Lagern kontrollieren, Sperrbestände festlegen und Statistiken über momentanen, absoluten und zu erwartenden Verbrauch anlegen. Weiterhin sollen sinnvolle Statistikfunktionen, sowie eine Abrechnungsfunktion implementiert werden.

    Weiterhin ist eine Personalplanung vorzusehen. Zur Durchführung der Party müssen Theken auf- und abgebaut, sowie betrieben werden. Jede Theke benötigt Zeit für Auf- und Abbau sowie eine minimale Anzahl an hierfür benötigtem Personal. Ebenso gibt es eine minimale und eine maximale Anzahl an Personen, die eine Theke während der Party betreiben können. Die optimale Anzahl der zum Betrieb notwendigen Personen hängt vom aktuellen Umsatz der Theke ab. Neben dem Theken-Personal werden noch DJs und Security-Personal benötigt, deren Anzahl von der aktuellen Gästeanzahl abhängt.

    Zur optimalen Durchführung einer Party will DistrEvents mit der Software nun Schichtpläne für die gesamte Party erstellen können. Die Software soll diese auf Plausibilität überprüfen. Während der Party soll ständig überprüft werden können, welche Theken über- bzw. unterbesetzt sind. Um auf einseitige Personalengpässe reagieren zu können, soll die Software die spontane Umschichtung von Personal unterstützen.

     

  8. Projektverwaltung (EPoint) - Betreuer: Christoph Linnenbaum - Präsentation: 14.45 Uhr - 15.15 Uhr - zum Seitenanfang

    Projektverwaltung Die Firma IPN (InnoProject Neubiberg) möchte für ihre umfangreichen Projekte eine professionelle Projektverwaltung benutzen. Mit den bestehenden Lösungen, die am Markt erhältlich sind, ist sie dabei unzufrieden, da sie die besonderen Strukturen der Firma nicht abbilden können.

    Die Firma besteht aus Managern, Senior Consultants und Consultants. Jede Person hat eine Menge von Fähigkeiten. Fähigkeiten sind hierarchisch geordnet, d.h. es gibt Fähigkeiten, die eine Menge anderer Fähigkeiten umfasst. Die Fähigkeit Englisch Kenntnisse könnte sich z.B. aus den Fähigkeiten schriftliche Englischkenntnisse und mündliche Englischkenntnisse zusammensetzen. Weiterhin haben die Fähigkeiten eine Ausprägung. Die Fähigkeit gute mündliche Englischkenntnisse umfasst dabei die Fähigkeit mittelmäßige mündliche Englischkenntnisse vollständig.

    Manager können Projekte erstellen und diesen zur Leitung des Projekts benötigte Fähigkeiten zuordnen. Sie verwalten das Personal ihrer Abteilung, indem sie Senior Consultants zu Projekten zuteilen und Consultants den Senior Consultants unterstellen.

    Senior Consultants erstellen innerhalb eines Projektes Aufgaben, ordnen diesen benötigte Fähigkeiten zu und teilen einen oder mehrere Consultants zu diesen Aufgaben zu. Ein Consultant bearbeitet die ihm zugewiesenen Aufgaben.

    Die Verwaltung der dabei erstellten Dokumente soll schon vorbereitet werden, die vollständige Implementierung kann aber auch in einer Folgeversion erfolgen.

    Die Aufgaben, die von Senior Consultants erstellt wurden, müssen eindeutig identifiziert werden können. Sie müssen ein Erstellungsdatum, ein Fortschrittsattribut, eine freie Beschreibung ihres Fortschritts, eine freie Beschreibung ihres Inhalts, eine quantitative Beschreibung ihres Umfangs und ihrer Laufzeit, sowie einen Hauptverantwortlichen haben. Zur besseren Gliederung von Aufgaben sollen diesen Milestones und Deadlines zugeordnet werden können.

    Projekte, die von Managern erstellt wurden, müssen dieselben Eigenschaften wie Aufgaben haben. Der Fortschritt eines Projektes soll dabei den Fortschritt der letzten Aufgabe abbilden.

    Um die Leistungsfähigkeit der eigenen Firma besser einschätzen zu können, um Mängel abzustellen und gezielt Ausbilden zu können, soll eine Auswertung der Projekte und Aufgaben möglich sein. Interessant hierbei ist z.B. die durchschnittliche Dauer von Projekten oder wie gut Terminvorgaben gehalten werden. Insbesondere eine personenbezogene Auswertung scheint zweckdienlich, um steuernd eingreifen zu können.

    Zur Ausbildungsplanung scheint eine Auswertung der Fähigkeiten sinnvoll, z.B. ob es bestimmte Fähigkeiten gibt, die kaum erfüllt werden. Insbesondere schein auch interessant zu sein, wie gut die (vermuteten) benötigten Fähigkeiten mit den tatsächlich vorhandenen Fähigkeiten zusammenpassen (hierbei ist auf die Hierarchie zu achten!). Zusätzlich interessiert dann, wie oder ob das Verhältnis der abgedeckten zu nicht abgedeckten Fähigkeiten mit dem Projekterfolg korreliert ist.

     

  9. Schwarzes-StudFBer-Brett (EPoint) - Betreuer: Michael Domberg - Präsentation: 15.30 Uhr - 16.00 Uhr - zum Seitenanfang

    Für den Studentenfachbereich (StudFBer) B soll ein elektronisches schwarzes Brett entwickelt und implementiert werden, dass die noch vorhandenen Bretter der StudFBerGrp überflüssig macht.

    Ein Fachbereich besteht aus einem Studentenfachbereichsleiter, mehreren Gruppenleitern und vielen Studenten. Er ist dabei hierarchisch organisiert.

    Ein Student ist genau einem Gruppenleitern und dem StudFBerLtr unterstellt. Er kann Nachrichten, Bekanntmachungen und Listen seiner Gruppe, sowie des StudFBerLtr lesen. Sein Gruppenleiter kann ihm die das Recht einräumen selbst bestimmte Nachrichten, Bekanntmachungen oder Listen für seine Gruppe zu erstellen. Dies kann für den Einzelfall oder allgemein geschehen. Der StudFBerLtr kann ihm diese Rechte für den gesamten StudFBer oder für spezielle weitere Gruppen erteilen.

    Ein Gruppenleiter hat mehrere unterstellte Studenten und ist dem StudFBerLtr unterstellt. Er muss die ihm unterstellten Studenten erfassen und kann Nachrichten, Bekanntmachungen und Listen für seine Gruppe veröffentlichen. Dieses Recht kann er an unterstellte Studenten weitergeben. Er kann die Nachrichten, Bekanntmachungen und Listen seiner Gruppe, sowie des SFBLtr lesen. Der StudFBerLtr kann ihm die das Recht einräumen selbst bestimmte Nachrichten, Bekanntmachungen oder Listen für den StudFBer oder für bestimmte weitere Gruppen zu erstellen. Dies kann für den Einzelfall oder allgemein geschehen.

    Der StudFBerLtr befehligt die Gruppenleiter, sowie alle Studenten. Er kann seine Gruppenleiter organisieren. Er kann Nachrichten, Bekanntmachungen und Listen für eine oder mehrere Gruppen veröffentlichen und lesen. Weiterhin kann er diese Rechte an ihm unterstellte Soldaten weitergeben.

    Nachrichten haben genau einen Absender und genau einen Empfänger. Bekanntmachungen haben genau einen Absender und einen oder mehrere Empfänger. Listen haben genau einen Absender und eine oder mehrere Gruppen als Empfänger.

    Zu einer Liste gehört ein Nachrichtenteil und der eigentliche Listeteil. Studenten und Gruppenleiter können sich in diese Listen eintragen. Das Ergebnis der Liste kann dann vom Absender eingesehen werden. Der Absender einer Liste kann entscheiden, ob die Empfänger die bereits eingetragenen Personen sehen dürfen.

    Der Absender einer Nachricht, einer Bekanntmachung bzw. einer Liste kann diese auch wieder löschen. Weiterhin kann er schon bei der Erstellung ein Datum eingeben, an dem diese automatisch gelöscht wird.

    Auch die Anwesenheitskontrolle soll durch das System abgewickelt werden können. Um sicherzustellen, dass ein Student wirklich auf dem Campus anwesend ist, wird ein mit Fingerabdruck-Scanner ausgestatteter PC frei zugänglich aufgestellt. Weiterhin gibt es eine spezielle Art von Listen, deren Nachrichtenteil man zwar lesen kann, in die man sich aber nur von dem speziell ausgestatteten PC eintragen kann. Der Eintrag in die Liste muss mit einem Fingerabdruck bestätigt werden (hier simuliert durch Eingabe einer PIN) und wird mit Datum, Uhrzeit und MAC-Adresse der ersten Netzwerkkarte des absendenden PCs protokolliert.

     

  10. Wohnbereich-Verwaltung - Betreuer: Michael Neumann - Präsentation: 17.00 Uhr - 17.30 Uhr - zum Seitenanfang

    NetGem, GetGem, CopyGem, HausGem und was es sonst noch alles gibt (oder gegeben hat :o) im Wohnbereich der Informatiker. Trotz vielfachem Anlauf in Einzelbereichen gibt es bis heute nicht einmal in dieser abgeschlossener Brutstätte künftiger Informatik-Profis eine einheitliche, redundanzarme und zuverlässige Verwaltung der notwendigen Daten. Nun, immerhin wirft das ein Thema für das Programmierpraktikum ab...

    Das zu erstellende Programm soll nun alles einfacher machen. Zu allererst wird natürlich eine neu Gem, genannt SuperGem, gebildet. Ein neuer Informatiker wird hinfort einfach Mitglied in dieser SuperGem und bekommt damit Zugang zu dem zu erstellenden Programm. Er ist dann dafür verantwortlich die eigenen Daten (die er dem Programm anvertrauen will) aktuell zu halten. Zunächst will er sich wohl anzeigen lassen, welchen anderen Gems er beitreten kann.

    Diese verlangen normalerweise, dass eine gewisse Menge an persönlichen Daten im System vorhanden sind und wollen Lesezugriff darauf. Manche benötigen eine eMail-Adresse, andere den RealName, manche sogar PK oder Heimatanschrift oder ähnliches. Nur eines wollen natürlich alle Gems, nämlich GELD. Normalerweise wir ein einmaligen Betrittsbetrag, eventuell auch eine Einlage, erhoben. Weiterhin müssen regelmäßig wiederkehrende Beträge entrichtet werden. Diese sind manchmal konstant (NetGem), manchmal aber auch deutlich voneinnader verschieden (GetGem). Manchmal wird sogar körperliche Arbeit gefordert (GetGem-Lieferung)!

    Zur Führung der Gems werden üblicherweise Konten geführt. Die Kontobewegungen werden oft über Listen berechnet, die eine abgespeckte Spreadsheet-Funktionalität besitzen/benötigen. Weiterhin werden Mitteilungen an einzelne oder alle Mitglieder versendet, die sicher (überprüfbar) angekommen sein müssen. Ebenso müssen Gem-speziefische Termine verwaltet werden (z.B. Hausputz-Aktionen). Für alle diese Bedürfnisse der Gem-Chefs soll das Programm eine generische Lösungsmöglichkeit anbieten.

    Eine weitere Eigenschaft der Gems ist die Einführung neuer Hierarchien mit unterschiedlichen Rechten - denkt nur an die Hausgemeinschaften... Zumindest gibt es für jede Gem aber einen Chef, und der soll das dann für seine Gem klären. Um das zu ermöglichen muss allerdings einiges an Intelligenz in eine geeignete Rechteverwaltung gesteckt werden! Diese könnte z.B. wie folgt aussehen:

    Die Wohnbereichsbeauftragten(Wbb) der einzelnen Wohnbereiche zusammen mit dem SuperGem-Chef bilden den SuperGem-Rat :-). Dieser darf als einziger neue Rechte anlegen und Rechte vergeben, die er selbst nicht besitzt. Jeder der ein Recht zugewiesen bekommen hat, darf dieses auch anderen einräumen. Die Weitergabe von Rechten wird stets allen Betroffenen mitgeteilt. Der SuperGem-Rat darf als einziger Rechte aberkennen. Allerdings darf sich jeder ansehen, wer im Moment welche Rechte hat, und was derjenige dadurch darf. Rechte können den Zugriff auf spezielle Daten oder die Berechtigung bestimmte Aktionen durchzuführen beinhalten.

    Z.B. könnte ein Recht für einen GetGem-Chef angelegt werden, das das Eintragen von Terminen mit der Titelzeile "GetGet-Lieferung" in den Terminkalendern der Mitglieder der entsprechenden GetGem erlaubt. Ebenso wird ihm erlaubt das GetGetm-Konto der Mitglieder der GetGem zu führen. Weiterhin kann er sich alle Mitglieder seiner GetGem anzeigen lassen, zusammen mit ihren RealNames, ihren Netznamen und ihrer Stubennummer. Gibt er das Recht weiter, wird dies allen Mitgliedern der entsprechenden GetGem mitgeteilt.

     

  11. Low Budget Fluglinie LoBuFLY - Betreuer: Anderas Hänel - Präsentation: 17.45 Uhr - 18.15 Uhr - zum Seitenanfang

    Die neu gegründete Low Budget Fluglinie LoBuFLY beauftragt Sie mit der Implementierung einer Verwaltungssoftware.

    Um besonders günstige Preise anbieten zu können, hatten die Gründer von LoBuFLY die Idee, Güter- und Personenverkehr zu kombinieren. Dies nennen Sie kombinierten Transport. Grundsätzlich wird versucht die Kosten eines Fluges schon mit dem Frachtverkehr abzudecken. Der Gewinn soll dann mit dem Personentransport gemacht werden. Die Gründer versprechen sich hiervon unschlagbar günstige Preise sowohl für den Güter- als auch für den Personentransport anbieten zu können.

    Ein weiteres Plus für die Fluggäste ist die Möglichkeit, auch nach dem Flug im kombinierten Transport, also im LKW oder im Güterzug, weiterreisen zu können. Dieser Service ist für die Fluggäste, bei verfügbaren Kapazitäten, kostenlos.

    Für den Gütertransport bietet LoBuFLY an, entwerder nur den Lufttransport durchzuführen, oder auch den An- und Abtransport zum Flughafen zu organisieren.

    Für den Personenverkehr bietet LoBuFLY neben dem Buchen eines Flugs von Flughafen zu Flughafen im Moment folgende Optionen an:

    • buchen der An- und Abreise im kombinierten Transport. Dies wird nur zugesagt, wenn Frachtgut entsprechend transporiert werden muss. Wenn nicht, dann kommt die Buchung auf eine Warteliste.
    • Menu-Wünsche
    • Ausschluss des Transports mit bestimmten Warengruppen (insbesondere kombinierter Transport mit Tieren hat sich in einer Testphase als problematisch Erwiesen)
    • Transport nur in getrennten Abteilen mit Gütern
    Da die Idee so neu ist, kann nicht ausgeschlossen werden, dass sich die Liste häufig ändert. Ist die gesamte Kapazität des Flugzeugs zugeordnet, werden den Fluggästen Informationen über die Warengruppen gesendet, mit denen sie gemeinsam transportiert werden.

    Um die laufenden Kosten im Bereich der Planung und Unterhaltung der Flugzeuge und ihrer Routen zu senken, soll die Software sowohl die Flugplätze und die Flugzeuge, als auch die gesamte Strecken- und Personalplanung unterstützen.

    Mit der Software muss planbar sein, welches Flugzeug auf welchen Routen in welchen Zeiträumen verkehrt. Ebenso muss verwaltet werden, welche verbindlichen Zusagen für Güterverkehr bzw. für Personenverkehr bereits gemacht wurden.

    Die Geschäftsführung soll durch einen Tarifplaner die Preise der angebotenen Leistungen berechnen können. Dazu sollen zum Beispiel Flugplatzgebühren, der Kaufpreis eines Flugzeuges und dessen Kerosinverbrauch, die Anzahl der im Schnitt belegten Plätze, die üblicher weise transportierte Gütermenge und die Personalkosten ausgewertet werden. Des Weiteren müssen Bilanzen und Abrechnungen zu bestimmten Zeiträumen erstellt werden.

    Letzendlich soll den Kunden eine Informationsplattform Auskunft über Flugpläne und Tarife zur Verfügung gestellt werden. Hierfür ist eine Suchfunktion vorzusehen.

     

  12. Autovermietung FastRent - Betreuer: Anderas Hänel - Präsentation: 18.15 Uhr - 18.45 Uhr - zum Seitenanfang

    Die Autovermietung FastRent möchte expandieren. Dazu sollen zu dem bestehenden Hauptstandort weitere Standorte eröffnet werden. Um die Verwaltung der anfallenden Daten aller Standorte zu vereinfachen sucht die Firmenleitung nach einer leistungsfähigen Verwaltungssoftware. Sie werden mit der Implementierung einer solchen Software beauftragt.

    Wichtig für die Vermieterin ist die Übernahme des vorhandenen Fuhrparks, mit den Fahrzeugklassen und entsprechenden Fahrzeugen. Weiterhin muß die Software sowohl Informationen über jeden Standort und seinen Fuhrpark, als auch über den gesamten Fuhrpark und alle Fahrzeuge liefern. Gleiches gilt für das eingesetze Personal.

    Dem Kunden soll eine Informationsplattform zur Verfügung gestellt werden, mit der er Preis und Verfügbarkeitsinformationen bezügliche bestimmter Fahrzeugklassen zu bestimmten Zeiten erhalten kann.

    Mögliche Erweiterungen des bestehenden Angebotes (nur Zeit-/Kilometerabhängige Abrechnung) könnten z.B. Wochenendangebote (ohne Kilometerbegrenzung) oder ähnliches sein.

    Da FastRent Reperaturkosten sparen will, waren bisher zusätzlich zwei weitere Services eingerichtet. Zum einen wurden die gebrauchten Autos zum Verkauf angeboten. Zum anderen hat FastRent eine eigene kleine Werkstatt, in der es bisher die eigenen Autos repariert hat. Im Rahmen der Expansion sollen nun beide Services ausgebaut werden.

    Zum einen soll das System eine allgemeine Plattform zum Kauf- und Verkauf von Autos bereitstellen. D.h. Kunden sollen nun auch eigene Autos über das System zum Verkauf anbieten. Hiervon verspricht sich FastRent, dass auch die eigenen Angebote besseren Absatzt finden. Überlegt wird, ob das System auch über ein Auktions-Modul verfügen soll, so dass die Autos wahlweise auch versteigert werden können.

    Ebenso soll die Werkstatt deutlich ausgebaut werden und ihre Reparaturdienste öffentlich anbieten. Abgerundet werden soll das Angebot der Werkstatt durch einen Abschleppdienst und eine Shop für Autozubehör.

    Für die nahe Zukunft plant FastRent die Autovermietung, die Kauf-/Verkauf-Plattform für Autos sowie den Zubehör-Shop im Internet zu platzieren.

    Weiterhin ist der Vermieterin wichtig, ständig aussagekräftige Daten über das gesamte Geschäftsnetz zu bekommen. Hierfür wird eine Art Statistik/Buchhaltungs-Funktionalität benötigt, welche eine Übersicht über das ganze Geschäft ermöglicht. So zum Beispiel Gewinn-/Verlustrechung, Kundenübersicht, Kassenbuch, etc.

Download-Links

EPoint-Dokumentation

EPoint: Quellcode-Generator