Projektantrag: Raumbuchungs-App für Mitarbeiter

[Gast garanwa]

Hallo Leute,

ich mache gerade eine Umschulung als FIAE. Ich muss einen Antrag für das Abschlussprojekt einreichen. ich würde mich über Feedback und Kommentare zum Antrag freuen:

 

Betriebliche Projektarbeit

Projekt Details

Thema

Entwicklung einer Raumbuchung App

Beschreibung: 

Ist Zustand

Die xx GmbH hat keine Software, die es den Mitarbeitern ermöglicht, ihren Arbeitsplatz zu reservieren, was meistens sehr zeitaufwändig ist. Aus diesem Grund hat sich der Firma entschieden, diese Software zu erstellen.

Gründe, eine Raumbuchungs-App für Mitarbeiter zu erstellen:

·         Verbesserte Effizienz: Eine Raumbuchungs-App kann den Prozess der Verwaltung von Mitarbeiterreservierungen rationalisieren, sodass die ein größeres Buchungsvolumen effizienter bearbeiten kann.

·         Gesteigerte Produktivität: Indem eine Raumbuchungs-App Mitarbeitern die Buchung von Plätzen erleichtert, kann sie potenziell die Produktivität steigern, indem sie den Zeit- und Arbeitsaufwand für die Verwaltung von Reservierungen reduziert.

·         Kosteneinsparungen: Eine Raumbuchungs-App kann potenziell die Kosten reduzieren, die mit der Verwaltung von Mitarbeiterreservierungen verbunden sind, wie z. B. Verwaltungszeit und -ausgaben.

Anforderungen:

·         User-Anmeldung und Authentifizierung:

·         Sitzplatzverfügbarkeit: Die App sollte Echtzeitinformationen über die Verfügbarkeit von Sitzplätzen enthalten.

·         Buchungs- und Reservierungssystem: Mitarbeiter sollten die Möglichkeit haben, einen Sitzplatz für einen bestimmten Zeitraum zu buchen, z. B. einen halben Tag oder einen ganzen Tag. Die App soll es den Mitarbeitern auch ermöglichen, ihre Buchungen zu stornieren oder umzubuchen.

·         Benutzerfreundliche Oberfläche: Die App sollte eine einfache, intuitive Oberfläche haben, die für die Mitarbeiter einfach zu bedienen ist.

 

Projektumfeld

Das Projekt wird in den Räumlichkeiten der abc GmbH durchgeführt

 

Schnittstelle, Technologie:

React

Ruby on rails

Git

IDE’s: VSstudio, Webstrom, Insomnia

 

 

Projektphasen/Zeitplanung

Information

Recherche                                                                                                                                        7

 

Planung

Anforderungen erarbeiten                                                                                                        4

Modelle erstellen                                                                                                                          6

 

Durchführung

Implementieren benutzerfreundliche Oberfläche                                                           40

Implementieren ein Buchunnas-und-Reservierungssystem

Erstellen User Login/Sign-up

Kontrolle und Abschluss

·         Testen                                                                                                                                20

·         Abnahme

·         Entwickler Dokumentation

·         Projekt Dokumentation

 

Dokumentation und Hilfsmittel

Lastenheft, Pflichtenheft

Entwicklerdokumentation

Klassendiagramm

[MartinSt]

Mir fehlt eine sinnvolle Make-or-Buy Entscheidung.

Bitte die Zeiten feiner gliedern und die Implementierungsschritte mit mehr Details. Außerdem fehlt mir der ganze administrative Teil der Software, also Erstellen und Verwalten der User, der Räume, Feiertage usw.
Laut den aufgelisteten Technologien nutzt Du keine Datenbank? 🙄

[Gast garanwa]

Danke @MartinSt für das Feedback, reicht es, wenn ich noch mit Implementierung noch hinzufüge

-implementieren Admin Dashboard

mit Ruby on rails wurde automatisch mit sqlite mitinstalliert. Aber kann ich noch hinzufügen. 

[MartinSt]

Ich nutze seit über 20 Jahren jeweils die zur Anforderung passende DB oder auch eine wo ich schon Kenntnisse aus früheren Projekten habe.

Aber man kann natürlich auch einfach die nehmen, die beim Setup mitkommt. 😁
Das zeugt dann von besonderer fachlicher Expertise.

[charmanta]

77 Stunden ? Ich würde auf 80 Stunden gehen

[Jinju]

Also wie @MartinStschon sagte, würde ich hier auf jeden Fall noch begründen wieso keine gekaufte Software dafür hinhalten kann. Solltet ihr z.b. die entsprechenden Microsoft Lizenzen haben, könnte man das ganz leicht über Microsoft Bookings lösen. Das solltest du dem Prüfungskomitee erläutern können, denn die Frage nach dem wieso wird ziemlich sicher aufkommen.

[pr0gg3r]

vor 12 Stunden schrieb garanwa:

React

Ruby on rails

Warum React und Ruby on Rails? 

vor 12 Stunden schrieb garanwa:

Implementieren benutzerfreundliche Oberfläche                                                           40

Implementieren ein Buchunnas-und-Reservierungssystem

Erstellen User Login/Sign-up

 

Räumst du hier nicht das Feld von der falschen Seite auf? Würde eher mit dem Backend und dessen Schnittstellen anfangen und dann um das Frontend kümmern (es sei denn du willst im Frontend alles mocken). Wieso steht User Login/Signup nicht an erster Stelle? Oder kannst du buchen ohne Login?

[allesweg]

Wie wurden die Räume bisher verwaltet?

Welche Art von Räumen sind das, wenn die Buchung Einfluss auf die Produktivität hat?

Wie viele Räume sind das?

Dazu noch die bereits genannte Entscheidung make or buy:

Womit organisiert ihr eure Termine und gibt es darin kein entsprechendes Feature, welches keine zusätzliche Entwicklungs- und Betriebskosten verursacht?

[Maniska]

Gibt es einen Exchange bzw eine 365 Umgebung? Wenn ja, was spricht gegen die dort vorhandenen Möglichkeiten der Ressourcenverwaltung?

[Gast garanwa]

vor 14 Stunden schrieb Jinju:

Also wie @MartinStschon sagte, würde ich hier auf jeden Fall noch begründen wieso keine gekaufte Software dafür hinhalten kann. Solltet ihr z.b. die entsprechenden Microsoft Lizenzen haben, könnte man das ganz leicht über Microsoft Bookings lösen. Das solltest du dem Prüfungskomitee erläutern können, denn die Frage nach dem wieso wird ziemlich sicher aufkommen.

Weil ich gerade ein Praktikum mache und die Firma vertraut mir anscheinend nicht, echte Projekte durchzuführen, die sie Zeit und Geld kosten können. 

 

[Gast garanwa]

vor 12 Stunden schrieb pr0gg3r:

Warum React und Ruby on Rails? 

Räumst du hier nicht das Feld von der falschen Seite auf? Würde eher mit dem Backend und dessen Schnittstellen anfangen und dann um das Frontend kümmern (es sei denn du willst im Frontend alles mocken). Wieso steht User Login/Signup nicht an erster Stelle? Oder kannst du buchen ohne Login?

weil ich gut beide Framworks arbeiten kann. 

 

[Gast garanwa]

vor 17 Stunden schrieb charmanta:

77 Stunden ? Ich würde auf 80 Stunden gehen

danke, das habe ich jz geändert. 

[Gast garanwa]

vor 3 Stunden schrieb allesweg:

Wie wurden die Räume bisher verwaltet?

Welche Art von Räumen sind das, wenn die Buchung Einfluss auf die Produktivität hat?

Wie viele Räume sind das?

Dazu noch die bereits genannte Entscheidung make or buy:

Womit organisiert ihr eure Termine und gibt es darin kein entsprechendes Feature, welches keine zusätzliche Entwicklungs- und Betriebskosten verursacht?

garnichts bis jetzt

[allesweg]

vor 4 Minuten schrieb garanwa:

Weil ich gerade ein Praktikum mache und die Firma vertraut mir anscheinend nicht, echte Projekte durchzuführen, die sie Zeit und Geld kosten können. 

 

Sie müssen dir aber ein prüfungstaugliches Projekt ermöglichen. Diese Verpflichtung sind sie mit dem hoffentlich existierenden Praktikumsvertrag eingegangen.

 

vor 1 Minute schrieb garanwa:

garnichts bis jetzt

Ach bisher trifft man sich und sucht im Rudel einen leeren Besprechungsraum in passender Größe? Oder geht es gar um Arbeitsplätze?

[Gast garanwa]

mit dem Vertrag steht nicht, dass mir eines echten Projektes ermöglichen sollen. 

 

ja es geht um Arbeitsplätze und nicht Seminarräume.

[Gast breathtaking]

vor 4 Stunden schrieb garanwa:

Weil ich gerade ein Praktikum mache und die Firma vertraut mir anscheinend nicht, echte Projekte durchzuführen, die sie Zeit und Geld kosten können. 

 

Geh da trotzdem ran als wäre es ein echtes Projekt. wenn die Firma absolut kein Entgegenkommen zeigt, zieh dir was aus der Nase, erfinde was, aber realistisch. Dein projekt ist super wichtig und sollte für dich gerade im Vordergrund stehen. ein Kampf mit dem Betrieb, der dir kein echtes Projekt geben will (wieso auch immer) lohnt sich nie.

Also, versuche so viel wie möglich rauszufinden, was die Firma aktuell hat, wie der Ablauf jetzt ist, welche Linzensen haben sie usw...Auch wenn das am ende nicht deployed wird, hast du eine gute Projektarbeit abgeliefert. Versuche dich hinein zu versetzen, du bist die Firma, wie würdest du dabei vorgehen, diese Idee umzusetzen. Du solltest am Anfang nie schon alles fest stehen haben, weder Framework, noch Programmiersprache, noch Make or Buy,  noch die engültige Lösung. Das musst du alles im Projekt "planen" und durchgehen, auch wenn es für dich im Hinterkopf schon feststeht.

Bei meinem Projekt hat eine Buy-Entscheidung viel mehr Sinn gemacht, aber ich habe trotzdem das Programmieren durchgezogen, weil der Chef das so wollte. Das kann man sogar auch dem Prüfungsausschuss so sagen, aber weil Firma trotz Kosten das selber machen wollte hat manns eben gemacht.

Das Analysieren, Recherchieren,Abwägen, Planen und danach Umsetzen ist das wichtigste bei der Projektarbeit.

[Maniska]

vor 4 Stunden schrieb garanwa:

mit dem Vertrag steht nicht, dass mir eines echten Projektes ermöglichen sollen. 

Muss es auch nicht, das ergibt sich aus der Natur dieses Vertrages.

Was sagen denn Kostenträger (wahrscheinlich Jobcenter) und Bildungsträger dazu?

[pr0gg3r]

vor 6 Stunden schrieb garanwa:

weil ich gut beide Framworks arbeiten kann. 

Das reicht mir nicht als Begründung.

Wieso brauchst du noch React, wenn du doch RoR verwendest?

Tip: Sage im Projektantrag nicht, welche Technologien du verwendest. Sondern pack das mit in die Projektdoku rein (z. B. "Vergleich verschiedener Webframeworks und Auswahl eines Frameworks für die App"). Mach dort deine Entscheidungen objektiv nachvollziehbar.

 

[Gast garanwa]

vor 54 Minuten schrieb pr0gg3r:

Das reicht mir nicht als Begründung.

Wieso brauchst du noch React, wenn du doch RoR verwendest?

Tip: Sage im Projektantrag nicht, welche Technologien du verwendest. Sondern pack das mit in die Projektdoku rein (z. B. "Vergleich verschiedener Webframeworks und Auswahl eines Frameworks für die App"). Mach dort deine Entscheidungen objektiv nachvollziehbar.

 

Das war ich unsicher, weil normalweise mit MVC kann man auch Views benutzen. Danke dir.  

 

[Gast garanwa]

vor 2 Stunden schrieb breathtaking:

Geh da trotzdem ran als wäre es ein echtes Projekt. wenn die Firma absolut kein Entgegenkommen zeigt, zieh dir was aus der Nase, erfinde was, aber realistisch. Dein projekt ist super wichtig und sollte für dich gerade im Vordergrund stehen. ein Kampf mit dem Betrieb, der dir kein echtes Projekt geben will (wieso auch immer) lohnt sich nie.

Also, versuche so viel wie möglich rauszufinden, was die Firma aktuell hat, wie der Ablauf jetzt ist, welche Linzensen haben sie usw...Auch wenn das am ende nicht deployed wird, hast du eine gute Projektarbeit abgeliefert. Versuche dich hinein zu versetzen, du bist die Firma, wie würdest du dabei vorgehen, diese Idee umzusetzen. Du solltest am Anfang nie schon alles fest stehen haben, weder Framework, noch Programmiersprache, noch Make or Buy,  noch die engültige Lösung. Das musst du alles im Projekt "planen" und durchgehen, auch wenn es für dich im Hinterkopf schon feststeht.

Bei meinem Projekt hat eine Buy-Entscheidung viel mehr Sinn gemacht, aber ich habe trotzdem das Programmieren durchgezogen, weil der Chef das so wollte. Das kann man sogar auch dem Prüfungsausschuss so sagen, aber weil Firma trotz Kosten das selber machen wollte hat manns eben gemacht.

Das Analysieren, Recherchieren,Abwägen, Planen und danach Umsetzen ist das wichtigste bei der Projektarbeit.

danke dir @breathtaking, so macht keinen Sinn mehr die Begründung eine App zu machen? Soll ich das rauslassen? 

[Whiz-zarD]

vor 3 Stunden schrieb breathtaking:

Du solltest am Anfang nie schon alles fest stehen haben, weder Framework, noch Programmiersprache, noch Make or Buy,  noch die engültige Lösung. Das musst du alles im Projekt "planen" und durchgehen, auch wenn es für dich im Hinterkopf schon feststeht.

Das ist nicht taktisch Klug. In vielerlei Hinsicht. Bei einem richtigen Projekt findet die Make or Buy-Entscheidung VOR einem Projekt statt. Schließlich setzt man sich ja mit dem Thema auseinander und schreibt dafür auch einen Projektantrag. Während eines Projektes wäre es sehr blöd, wenn man dann nach zwei Stunden herausfindet, dass es so ein Tool schon für'n Appel und nen Ei zu kaufen gibt und das Projekt somit keinen Sinn mehr macht und dann durchfällt. Macht man eine Make or Buy-Entscheidung während des Projektes wird natürlich immer die Make-Entscheidung gewinnen. Im Zweifel lügt man sich also was zurecht.

Auch was Frameworks und Programmiersprachen angeht, legt man sich schon im Vorwege fest. Ich finde, es ist auch gar nicht schlimm, wenn Frameworks und Programmiersprachen vornherein bekannt sind. Schließlich ist dies auch im Sinne der Wirtschaftlichkeit. Niemand würde auf die Idee kommen, eine NoSQL-Datenbank zu nehmen, wenn die ganze Ausbildung nur mit relationalen Datenbanken zu tun hatte. Schließlich muss die Software auch mit den verfügbaren Mitteln gepflegt werden. Wenn also eine Firma mit C# und MS SQL Server arbeitet, wird niemand auf die Idee kommen, Python und MongoDB zu nehmen, weil dafür nicht extra Mitarbeiter geschult oder eingestellt werden sollen. Wer während des Projektes Frameworks und Programmiersprachen aufwiegt, lügt sich in den meisten Fällen was zurecht.

Man darf auch nicht vergessen, dass es sich hier um ein Projekt mit maximal 80 Stunden handelt. Das sind 10 Arbeitstage, wobei ca. 2 Tage allein nur für die Dokumenation draufgehen und nun überlegt euch mal, was ihr in 8 Tagen wirklich schafft. Mit Sicherheit keine komplette Raumbuchung-App. Allein nur für die Authentifizerung und Authorisierung kann man schon 8 Tage verballern. Mit Verschlüsselung, Berechtigungskonzepten, etc. Mit einer simplen Klartext-Passwort-Abfrage ist es doch lang nicht mehr getan. Es braucht hier auch z.B. Nutzerrollen. Nutzer dürfen zwar neue Buchungen anlegen aber dürfen Buchungen von anderen Nutzern nicht überschreiben. Admins und vielleicht das Sekretariat vom Chef aber schon (z.B. für ein Kundenbesuch). Außerdem könnte es vielleicht Nutzer geben, die nur einen lesenden bzw. eingeschränkten Zugriff haben dürfen (z.B. Praktikanten), etc.

Wenn man sich aber mal Beispiele von Projektdokumentationen anschaut, stellt man fest, dass nur sehr wenige bis keiner eine komplette Anwendung baut, sondern überwiegend nur eine bestehende Anwendung erweitert oder eine Funktionalität gegen eine neue ersetzt. Denk dir also ein weitaus weniger komplexes Projekt aus. Wie auch schon hier angedeutet, gibt es inzwischen viele Raumbuchungstools. Da macht eine Eigenentwicklung kaum Sinn.

[Gast breathtaking]

vor 4 Stunden schrieb garanwa:

danke dir @breathtaking, so macht keinen Sinn mehr die Begründung eine App zu machen? Soll ich das rauslassen? 

grundssätzlich, finde ich, macht es schon sinn, diese App zu machen. es klingt nach einem coolen projekt, nicht zu abstrakt, bei dem man viel lernen kann. es ist aber tatsächlich, wie @Whiz-zarD sagt, ein komplexeres thema. falls du das schon draufhast und eine vorstellung hast wie manns machen kann, in der gegebenen zeit, warum nicht.

wie gesagt, man muss es eben begründen können, warum make und  nicht buy. dazu gehört auch eine amortisation. aber da kann der grund "ist zwar teurer als buy, aber chef will so" durchaus durchgehen, gibt genug bekloppte (zb. mein ex-chef). angestellter macht was chef sagt.

auch wenn die anwendung/app nicht fertig wird, mit begründung kann man das durchziehen. also wenn da nur noch kleinigkeiten übrig bleiben, aber wenn nur z.b. die hälfte fertig ist, dann ist das ein no go. dann ist das projekt zu groß. es hängt natürlich auch von der komplexität ab.

trotzdem ist bei dem projekt "der weg dahin" wichtiger, als das endergebnis.

falls du aber ein anderes, kleineres projekt als ausweiche hast, kannst du das auch mal hier reinposten.

 

ps: auch wenn es hier in dem forum anders rüber kommt, kann man nicht jedes projekt perfekt nach anleitung durchführen. wenn man einen blöden betrieb erwischt hat, muss man sich zu helfen wissen, denn am ende geht es um deine ausbildung.

[Gast garanwa]

vor 12 Stunden schrieb Whiz-zarD:

Das ist nicht taktisch Klug. In vielerlei Hinsicht. Bei einem richtigen Projekt findet die Make or Buy-Entscheidung VOR einem Projekt statt. Schließlich setzt man sich ja mit dem Thema auseinander und schreibt dafür auch einen Projektantrag. Während eines Projektes wäre es sehr blöd, wenn man dann nach zwei Stunden herausfindet, dass es so ein Tool schon für'n Appel und nen Ei zu kaufen gibt und das Projekt somit keinen Sinn mehr macht und dann durchfällt. Macht man eine Make or Buy-Entscheidung während des Projektes wird natürlich immer die Make-Entscheidung gewinnen. Im Zweifel lügt man sich also was zurecht.

Auch was Frameworks und Programmiersprachen angeht, legt man sich schon im Vorwege fest. Ich finde, es ist auch gar nicht schlimm, wenn Frameworks und Programmiersprachen vornherein bekannt sind. Schließlich ist dies auch im Sinne der Wirtschaftlichkeit. Niemand würde auf die Idee kommen, eine NoSQL-Datenbank zu nehmen, wenn die ganze Ausbildung nur mit relationalen Datenbanken zu tun hatte. Schließlich muss die Software auch mit den verfügbaren Mitteln gepflegt werden. Wenn also eine Firma mit C# und MS SQL Server arbeitet, wird niemand auf die Idee kommen, Python und MongoDB zu nehmen, weil dafür nicht extra Mitarbeiter geschult oder eingestellt werden sollen. Wer während des Projektes Frameworks und Programmiersprachen aufwiegt, lügt sich in den meisten Fällen was zurecht.

Man darf auch nicht vergessen, dass es sich hier um ein Projekt mit maximal 80 Stunden handelt. Das sind 10 Arbeitstage, wobei ca. 2 Tage allein nur für die Dokumenation draufgehen und nun überlegt euch mal, was ihr in 8 Tagen wirklich schafft. Mit Sicherheit keine komplette Raumbuchung-App. Allein nur für die Authentifizerung und Authorisierung kann man schon 8 Tage verballern. Mit Verschlüsselung, Berechtigungskonzepten, etc. Mit einer simplen Klartext-Passwort-Abfrage ist es doch lang nicht mehr getan. Es braucht hier auch z.B. Nutzerrollen. Nutzer dürfen zwar neue Buchungen anlegen aber dürfen Buchungen von anderen Nutzern nicht überschreiben. Admins und vielleicht das Sekretariat vom Chef aber schon (z.B. für ein Kundenbesuch). Außerdem könnte es vielleicht Nutzer geben, die nur einen lesenden bzw. eingeschränkten Zugriff haben dürfen (z.B. Praktikanten), etc.

Wenn man sich aber mal Beispiele von Projektdokumentationen anschaut, stellt man fest, dass nur sehr wenige bis keiner eine komplette Anwendung baut, sondern überwiegend nur eine bestehende Anwendung erweitert oder eine Funktionalität gegen eine neue ersetzt. Denk dir also ein weitaus weniger komplexes Projekt aus. Wie auch schon hier angedeutet, gibt es inzwischen viele Raumbuchungstools. Da macht eine Eigenentwicklung kaum Sinn.

danke dir @Whiz-zarD, ich verstehe, dass das Projekt zu komplex ist, aber, was wir gedacht haben, soll dieses Projekt erste Version sein und da muss man weiter erweitern. Nur 10 Tagen schafft einen Praktikanten es nicht. Deswegen in Dokumentation muss die Einschränkungen erwähnen. Und das Projekt soll auch nicht viel Funktionalität haben. Oder soll ich jetzt die Einschränkung mit dem Antrag schreiben, sodass man weiß, wie komplex dieses Projekt sein soll?