Hilfe bei Strukturierung für Buchungssystem

[Mnze]

Hallo zusammen :)

Meine Aufgabe ist es eine Art Mitarbeiter-Buchungssystem zu planen/entwickeln. Da ich bisher meistens ohne Strukturierung, einfach los gelegt habe und das ziemlich viel Zeit gekostet hat (vor allem auch da ich nicht der fitteste Programmierer bin), möchte ich es diesmal besser machen, wofür ich eure Hilfe benötigen könnte :)

Aufgabenstellung:

1. Anwendung zur Reservierung von Mitarbeitern, die entweder alleine oder im Team arbeiten. Das Programm entscheidet automatisch welcher Mitarbeiter / welches Team reserviert wird.

1.1 Die Teams werden im vorhinein bestimmt und können nur vom Admin geändert werden. 

1.2 Die maximale Team-Größe beträgt vier Mitarbeiter.

2. Es müssen auch Arbeitsgruppen erstellt werden können, die aus mehreren Mitarbeitern/Teams bestehen. Auch die Arbeitsgruppen können nicht aus beliebigen Teams bestehen, sondern nur aus vorab definierten. Die Arbeitsgruppen können unterschiedlich groß werden, aber nie mehr als 10 Mitarbeiter beinhalten. 

3. Der Anwender muss entscheiden können, wie viele Mitarbeiter er benötigt. Übersteigt die gewünschte Mitarbeiterzahl die der freien Teams (falls 4 Mitarbeiter benötigt werden, aber nur noch einzelne Mitarbeiter frei sind), oder ist die gewünschte Anzahl ohnehin >4 muss das Programm automatisch eine Arbeitsgruppe erstellen.

3.1 Sind nur noch vereinzelt Mitarbeiter frei, die aber nur unterschiedlichen Arbeitsgruppen zugewiesen werden können, muss das Programm Mitarbeiter neu zuweisen, sodass eine Arbeitsgruppe erstellt werden kann. Ist das nicht mehr möglich, muss das dem Anwender angezeigt werden.

4. Mitarbeiter müssen mindestens X Stunden vor dem Termin gebucht werden (ausreichend Einarbeitungszeit)

5. Werden bestimmte Mitarbeiter/Teams (die auswärts unterwegs sind) gebucht, muss die gleiche Anzahl an Mitarbeitern aus der "Zentrale" gebucht werden

6. Allen Mitarbeitern müssen bestimmte Tools/Ausrüstung mit gebucht werden können, die nicht in unbegrenzter Anzahl zur Verfügung stehen. Das Programm muss also wissen, wie viele Tools während einer bestimmten Zeit noch zur Verfügung stehen.

7. Ein Termin dauert in der Regel X Stunden, für die der Mitarbeiter als reserviert gilt

 

Hat jemand mit so etwas ähnlichem schon Erfahrung gesammelt und kann mir vllt. ein paar Tipps geben wie ich das ganze angehe? 

Was fällt euch noch ein, auf was ich achten muss? Also zusätzliche Rahmenbedingungen, die ich oben nicht genannt habe. 

 

Beste Grüße 

Mnze

[tkreutz2]

Hallo,

vorab, ich werde die Frage nicht beantworten (können), denn die Thematik sprengt in der Komplexität die Möglichkeiten dieses Fachforums (persönliche Meinung).

Ich kann aber einen guten Buch-Tipp hierzu geben. Das Buch ist älter und nennt sich Access 2007 das Praxisbuch für Entwickler ISBN 978-3-8273-2459-7

https://www.pearson.ch/download/media/9783827324597_TC.pdf

Konzeptionell an dem Buch fand ich toll, dass es eben auch eine Art praktischen Leitfaden beinhaltete, der zeigt, wie man Anforderungen beim Auftraggeber erkennt und diese Step by Step in ein Produkt umsetzt.

Ich vermisse solche Bücher heute sehr, denn viele Bücher sind aus heutiger Sicht entweder extrem technisch lastig oder eben extrem Projekt lastig oder zu sehr theoretischer Natur (akademische Sicht).

Der Vorteil in diesem Buch ist es, dass es EINE Anforderung gibt, die sich wie ein roter Faden durch das Buch zieht und die dann stückchenweise weiter spezifiziert und implementiert wird.

Dabei werden auch Gespräche zwischen möglicher Projektrollen erläutert und Fehler, die man als Entwickler dabei machen kann (auch im Bereich Kommunikation).

Natürlich ist der technische Teil hiervon veraltet und auch in Sachen Projektmanagement gibt es sicher neuere Trends. Aber das kann man ja ggf. anpassen.

Wenn man das Buch als praktischen Leitfaden zur Anforderungsanalyse liest, kann es durchaus hilfreich sein.

Viel Erfolg !

Gruß

Thorsten

Bearbeitet 11. Juli 2020 von tkreutz2

[Mnze]

Hallo Thorsten,

vielen Dank für den Tipp

Bzgl. der Komplexität gebe ich dir Recht, jedoch habe ich gehofft, hier jemanden zu treffen, der so etwas ähnliches schon einmal gemacht hat und mit dem ich mich etwas austauschen könnte. Vielleicht findet sich ja noch so jemand 🤞

Grüße

Mnze

[0x00]

Ich habe bisher immer mit der Datenhaltung angefangen: In diesem Fall würde ich eine relationale Datenbank wählen.
Die entsprechenden Tabellen planen (inkl. Spalten, Kardinalitäten etc.). Dann evtl. nötige Logikgatter entwickeln (Mitarbeiter ausgebucht etc.). Als letztes dann die Schnittstellen (zum User, zu anderen Programmen, etc.). Am besten die einzelnen Programmteile lose über Interfaces koppeln, sodass sie in Zukunft einfach ausgetauscht werden könnten (z.B. neue Datenbank, zukünftige Integration in Outlook Kalender?, etc.)
Wichtig: Nach jedem Schritt Rücksprache mit Ausbilder(?) oder Kollegen halten, sodass nicht hinterher große (Planungs-)Fehler entdeckt werden.

[Whiz-zarD]

vor 2 Stunden schrieb 0x00:

Ich habe bisher immer mit der Datenhaltung angefangen: In diesem Fall würde ich eine relationale Datenbank wählen.

Das ist immer das Problem bei einer Drei-Schichten-Architektur. Man fängt immer mit der Datenbank an, weil alles darauf aufbaut und sich somit Probleme einhandelt. Aber womit verdient man bei einer Software sein Geld? Bei der Speicherung von Daten in eine Datenbank oder bei der Geschäftslogik? Die Antwort sollte die Geschäftslogik sein. Also warum steht die nie im Vordergrund? Die Datenbank, also die Persistenzschicht ist doch nur ein Detail. Ob ich eine relationale Datenbank oder eine dokumentenbasierte Datenbank wähle, sollte erstmal egal sein.

Darum bin ich inzwischen ein Freund der sog. Clean Architecture. Die stellt nämlich die Domänenlogik in den Vordergrund und alles andere wird nur als Detail hinzugefügt. Der Vorteil der Clean Architecture ist der, wenn sie man sie richtig anwendet, alles von einander getrennt ist und sich sogar einfach testen lässt. Auch kann man daraus ein Grundgerüst entwerfen, dies als Repository in eine Versionsverwaltung packen und für andere Projekte forken, da sie quasi universell einsetzbar ist.

Clean Architecture stammt von Robert C. Martin aka Uncle Bob und man findet einige Videos von ihm dazu auf Youtube. Auch hat er dazu ein Buch geschrieben.

 

Bearbeitet 12. Juli 2020 von Whiz-zarD

[tkreutz2]

Von Ian Sommerville ist gerade ein neues Buch erschienen "Modernes Software-Engineering".

https://www.pearson-studium.de/modernes-software-engineering.html

Hier sind neue Modelle sowie auch der Punkt "Cyber-Crime" und Sicherheit by Design mit verankert. Ich finde auch, dass dieser Punkt in den klassischen Ansätzen zu wenig- oder überhaupt nicht berücksichtigt wurde in der Vergangenheit.

 

Bearbeitet 13. Juli 2020 von tkreutz2