Nathdrack Geschrieben 16. Februar 2011 Teilen Geschrieben 16. Februar 2011 Huhu, Ich bitte um konkrete und ernstgemeinte Kritik an diesem Projekt, was ich verbessern könnte. lg Projektbeschreibung Heimdalls Erben betreibt das einzige mobile Wikingermuseum in Deutschland, welches von Veranstaltern für mittelalterliche Märkte gebucht wird. Damit wird die damalige Lebens und Wohnkultur repräsentiert und auch als Dienstleistung der Gastronomie angeboten, für Mittelalterinteressierte wie auch Marktteilnehmer und Lagernde. Bisher wurden die Reservierungen und Termine in ein Kalenderbuch eingetragen. Dieses Vorgehen wurde für sie immer unübersichtlicher, sehr fehlerträchtig und schwer aktualisierbar Ziel soll es sein, die Fehlerträchtigkeit abzustellen, das aktualisieren der Termine zu erleichtern, sowie die Liste einfacher und in kürzester Zeit zu erstellen. Zudem erhofft sich der Kunde eine bessere Auswertbarkeit der Daten, z.B. Ausdruck auf Papier. Für die meist mehrere Tage umfassenden Mittelaltermärkte wünscht der Kunde eine Webanwendung, die es ihm ermöglicht, Interessenten eine Terminliste anzubieten, in der sie sich die zeitlich festen Märkte befinden und diese von den Interessenten reserviert werden können. Zum einfachen Anlegen und Konfigurieren der Terminlisten wünscht der Kunde für die Administratoren Einstellungsmöglichkeiten im Backend der zu entwickelnden Anwendung, um die Grund- und Termindaten einzugeben. Termine sollen zudem einzeln gelöscht und editiert werden können. Die Interessenten die das fahrende Museum für Ihre Märkte reservieren wollen, müssen in einem Kontaktformular die benötigten Daten eingeben, der Eigentümer wird dann bei Bedarf diesen Termin wahrnehmen und die Anwendung wird dann automatisch eine Antwortemail mit den nötigen Daten, wie z.B. Standgröße, Strom, Wasser generieren und an den Interessenten schicken. Dazu müssen die Interessenten zuvor in der Anwendungsumgebung angemeldet sein. Wer über einen externen Link auf die Terminliste gerät, muss darüber informiert werden und auf die Anmeldeseite geleitet werden. Es soll eine Infoseite für nicht angemeldete Interessenten mit Link zur Benutzer-Registrierung bzw. Anmeldung und anschließendem link zurück in die Terminliste geben; bereits angemeldete Interessenten sehen die Terminliste direkt. Bearbeitet ein Interessent einen Termin, so muss dieser vor dem erscheinen auf der Liste von einem Administrator bestätigt werden. Die neue Terminapplikation soll dem Eigentümer des fahrenden Museums mindestens 3-4 Stunden in der Woche an Terminplanung ersparen und ihm somit mehr Zeit und Kosten für Reparaturen einsparen. Daraus resultieren folgende Projektziele: 1. Das Zeitersparnis der Terminplanung wird Optimiert, der Eigentümer hat mehr Zeit zu Verfügung die nötigen Reparaturen und Wartungen durchzuführen. 2. Der Terminkalender wird übersichtlicher und einfacher zu lesen 3. Die Termine lassen sich auf eine schnelle und einfache Art erstellen 4. Bei Bedarf kann der Eigentümer die Termine in geordneter Form ausdrucken lassen. 5. Durch die digitale Eingabe, kann der Schausteller seine Daten bei Fehlern schneller verbessern, die Fehlerträchtigkeit wird auf ein Minimum reduziert. 6. Das aktuell halten der Termine wird durch die Editierfunktion vereinfacht und verbessert. 7. Dadurch das es keine Termine zur selben Zeit in der Software geben kann, gibt es keine Redundanzen im Kalender. 4 Projektumfeld Zur Realisierung des Projekts werden folgende Hardware und Software benötigt: - PHP 5 - MySQL 5 - Notebook mit Windows 7 Home Professional - Apache 2 Webserver - Eclipse PDT Entwicklungsumgebung 5 Projektphasen mit Zeitplanung 1. Analysephase Ist-Analyse (2) Soll-Konzept erstellen (3) 2. Entwurfsphase Entwurf / Erweiterung des Datenmodells (10) Entwurf der benötigten Programmfunktionen (5) Entwurf der Benutzeroberfläche (3) 3. Realisierung Erstellung der DB-Tabellen (2) Programmierung der Abfrage-Funktionen (8) Funktionen zur Eingabekontrolle (6) Programmierung weiterer PHP-Funktionen (9) Erstellung der Ein- und Ausgabemasken mittels HTML und CSS (5) Installation auf dem Zielsystem 4. Testphase Integrations- und Funktionstests (2) 5. Abschlussphase Erstellen der Projektdokumentation (12) Übergabe der Anwendung an den Kunden (2) Zeitaufwand gesamt in Stunden: (70) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Akku Geschrieben 16. Februar 2011 Teilen Geschrieben 16. Februar 2011 Gar nicht mal so schlecht. Entwirfst du keine UML Diagramme? Entwirfst du kein ERM? Wie entwirfst du die benötigten Programmfunktionen? Womit entwirfst du die Benutzeroberflächen? Wofür sind die "weiteren" PHP-Funktionen ? Warum sagst du mir das nicht? Erstellst du keinen strukturierten Testplan? Bekommt dein Kunde keine Kundendokumentation? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Nathdrack Geschrieben 16. Februar 2011 Autor Teilen Geschrieben 16. Februar 2011 Gar nicht mal so schlecht. Entwirfst du keine UML Diagramme? Entwirfst du kein ERM? Wie entwirfst du die benötigten Programmfunktionen? Womit entwirfst du die Benutzeroberflächen? Wofür sind die "weiteren" PHP-Funktionen ? Warum sagst du mir das nicht? Erstellst du keinen strukturierten Testplan? Bekommt dein Kunde keine Kundendokumentation? Die benötigten Programmfunktionen entwerfe ich mit PHP, Die Benutzeroberfläche mit HTML und CSS Das programmieren der weiteren PHP-Funktionen, wollte ich als optionale erweiterungen führen. änder ich aber um, liest sich blöde. Inwiefern soll die Testphase strukturiert sein? wäre net wenn du mir ein Schema schildern könntest. der Kunde bekommt das Pflichtenheft und die Benutzerdokumentation. // (Hat mir nicht alles rauskopiert , die Dokumentation zur Projektarbeit : - Projektdokumentation - ER-Modell - Benutzerdokumentation - Pflichtenheft UML Diagramme hatte ich eigentlich nicht vor.. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Akku Geschrieben 16. Februar 2011 Teilen Geschrieben 16. Februar 2011 Die benötigten Programmfunktionen entwerfe ich mit PHP, Die Benutzeroberfläche mit HTML und CSS Das programmieren der weiteren PHP-Funktionen, wollte ich als optionale erweiterungen führen. änder ich aber um, liest sich blöde. Inwiefern soll die Testphase strukturiert sein? wäre net wenn du mir ein Schema schildern könntest. der Kunde bekommt das Pflichtenheft und die Benutzerdokumentation. // (Hat mir nicht alles rauskopiert , die Dokumentation zur Projektarbeit : - Projektdokumentation - ER-Modell - Benutzerdokumentation - Pflichtenheft UML Diagramme hatte ich eigentlich nicht vor.. Oh jeh, das wird hart. Noch mal langsam: In der Entwurfsphase (Design) wird noch nicht kodiert auch nicht in PHP, sondern erstmal ein Klassendiagramm oder andere UML-Diagramme entworfen, mit denen die in der Implementierungsphase kodiert werden kann. Das gleiche gilt für die Datenbank. In der Designphase ERM und in der Implementierung, die Umsetzung und das Erstellen der Tabellen. Du musst doch einen Plan haben, was du wie testest, welche Ergebnisse an ein Testpunkt erwartet werden und was tatsächlich dabei herausgekommen ist. (Ich glaube, das habe ich gestern schon mal so geschrieben) Soweit klar? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Nathdrack Geschrieben 16. Februar 2011 Autor Teilen Geschrieben 16. Februar 2011 ja soweit ist das klar, vielleicht habe ich das nur falsch gelesen gehabt... Das Datenbankmodell ist klar, das ich das vorher mache mit den kardinalitäten und was wo hingehört etc. dazugehörig noch ein ERM Für den PHP code wollte ich ein Struktogramm erstellen was mir aber bisjetzt noch leicht im unklaren ist, wie genau dieser Testplan aussehen soll/wird. code schnipsel und die zu erwartende Ausgabe? und was bei rumgekommen ist? oder doch ganz anderster. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.