Projekttag Informatik

Teamleiter: Alex Eisner

Teammitglieder: Roman Leuch, Lias Vogler

Projektbeschreibung

In unserem Projekt entwickeln wir einen sogenannten RedKey mit einem Raspberry Pi Pico. Dabei handelt es sich um ein kleines Gerät, das vom Computer als Tastatur erkannt wird und vordefinierte Eingaben automatisch ausführen kann. Ziel ist es zu zeigen, wie man in einer erlaubten Testumgebung wieder Zugriff auf einen eigenen Windows-Computer bekommen kann, wenn man das Passwort vergessen hat.

Das Projekt verbindet verschiedene Bereiche wie IT-Sicherheit, Mikrocontroller, Programmierung, Automatisierung und 3D-Druck. Besonders spannend war für uns, dass ein so kleines Gerät wie der Raspberry Pi Pico Eingaben wie eine normale Tastatur senden kann. Dadurch konnten wir lernen, wie HID-Geräte funktionieren und welche Verantwortung beim Umgang mit solchen Techniken wichtig ist.

Für die Umsetzung entschieden wir uns für MicroPython, weil diese Variante einfacher, schneller und besser für unseren aktuellen Projektstand geeignet war. C++ wurde ebenfalls betrachtet, war für uns aber deutlich schwieriger und zeitaufwendiger.

Zusätzlich zum Programmieren des Raspberry Pi Pico haben wir eine eigene 3D-gedruckte Hülle erstellt. Dafür wurden in Fusion 360 mehrere Teile modelliert, darunter die Haupthülle, der Tastenhalter, die Keycaps und die Schrauben. Am Ende sollte ein kompakter RedKey entstehen, der verschiedene Tastaturlayouts unterstützt, auf einem Windows-11-Testgerät funktioniert und keine zusätzliche Software auf dem Zielcomputer benötigt.

Was hat gut funktioniert?

Die Recherche zu HID-Geräten und Raspberry Pi Pico hat gut funktioniert.
Die Entscheidung für MicroPython war passend für unser Projekt.
Der Raspberry Pi Pico wurde als Eingabegerät erkannt.
Die Steuerung über mehrere Buttons konnte umgesetzt werden.
Die Auswahl verschiedener Tastaturlayouts konnte getestet werden.
Die 3D-Hülle wurde passend konstruiert und gedruckt.
Der Pico passte in das Gehäuse und der USB-Anschluss blieb erreichbar.
Die wichtigsten Anforderungen konnten erfolgreich getestet werden.
Die Dokumentation wurde mit Planung, Umsetzung, Tests und Auswertung ergänzt.
Das Projekt wurde nur in einer erlaubten Testumgebung durchgeführt.

Was hat weniger gut funktioniert?

Kleine Fehler hatten teilweise grosse Auswirkungen auf den Ablauf.
Falsche Tastaturlayouts führten zu fehlerhaften Eingaben.
Sonderzeichen mussten je nach Layout angepasst werden.
Das richtige Timing der automatisierten Eingaben war teilweise schwierig.
Manchmal war nicht sofort klar, ob ein Fehler im Code, im Layout, bei Windows oder beim Timing lag.
Die Programmierung, Tests, Hülle und Dokumentation mussten parallel koordiniert werden.
Da das Thema sicherheitsrelevant ist, musste besonders sorgfältig und verantwortungsvoll dokumentiert werden.

Fazit

Das Projekt war insgesamt sehr spannend und lehrreich. Wir konnten praktisch herausfinden, wie ein Raspberry Pi Pico als HID-Gerät funktioniert und wie automatisierte Eingaben technisch umgesetzt werden können.

Besonders hilfreich war, dass wir verschiedene Themen miteinander verbinden konnten: Programmierung, Mikrocontroller, Tastaturlayouts, Windows-Verhalten und 3D-Druck. Dadurch war das Projekt abwechslungsreich und praxisnah.

Trotz einiger Schwierigkeiten konnten wir am Ende einen funktionierenden Prototyp erstellen und die wichtigsten Anforderungen erfolgreich testen. Für ein nächstes Projekt würden wir früher mit Zwischentests beginnen, die Tests genauer protokollieren und die Dokumentation regelmässiger während der Arbeit ergänzen.

https://gitlab.bbbaden.ch/projekttag/redkey

Teammitglieder:
Jeffrey Finn Wertli, Samuel Kaefer Ferreira, Davide Alessio Palladino, Loris Kadolli

Projektbeschreibung

In unserem Projekt haben wir ein PowerShell-System-Management-Tool entwickelt. Ziel des Projekts war es, ein Tool zu erstellen, mit dem verschiedene Aufgaben im Bereich Windows-Systemverwaltung direkt über PowerShell ausgeführt werden können. Das Tool besteht aus einem Hauptmenü und mehreren Modulen, die der Benutzer auswählen kann.

Die vier wichtigsten Module unseres Projekts sind System-Monitoring, Netzwerk-Analyse, Benutzer- und Rechte-Analyse sowie Backup und Restore. Beim System-Monitoring werden wichtige Informationen wie Windows-Version, CPU, Arbeitsspeicher, Festplatteninformationen, Dienste und Prozesse angezeigt. Die Netzwerk-Analyse liest Netzwerkadapter, IP-Adressen, DNS-Server und aktive Verbindungen aus und führt zusätzlich einen Ping-Test durch. Die Benutzer- und Rechte-Analyse zeigt lokale Benutzer, Gruppen und Administratoren an. Im Backup- und Restore-Modul können Testdateien erstellt, gesichert und wiederhergestellt werden.

Das Tool erstellt zusätzlich Reports und Log-Dateien. Dadurch können die Ergebnisse später nochmals nachvollzogen und als Nachweis verwendet werden. Unser Projekt zeigt, wie PowerShell genutzt werden kann, um verschiedene Systeminformationen automatisch auszulesen und einfache administrative Aufgaben zu automatisieren.

Bilder oder Screenshots

Für die Dokumentation haben wir mehrere Screenshots erstellt. Dazu gehören das Hauptmenü des Tools, die Ausgabe des System-Monitorings, die Netzwerk-Analyse, die Benutzer- und Rechte-Analyse sowie die Backup- und Restore-Funktion. Zusätzlich wurden Screenshots der Ordnerstruktur, des Reports-Ordners und des Logs-Ordners gemacht. Diese Bilder zeigen, dass das Tool erfolgreich gestartet wurde, die Module funktionieren und die Ergebnisse gespeichert werden.

Was gut lief

Gut funktioniert hat vor allem der modulare Aufbau des Projekts. Durch die Aufteilung in einzelne PowerShell-Dateien konnten die verschiedenen Bereiche getrennt voneinander bearbeitet und getestet werden. Das Hauptmenü sorgt dafür, dass alle Module übersichtlich gestartet werden können.

Auch das Testen der einzelnen Module hat gut funktioniert. Das System-Monitoring, die Netzwerk-Analyse, die Benutzer- und Rechte-Analyse sowie Backup und Restore konnten erfolgreich ausgeführt werden. Besonders hilfreich war, dass automatisch Reports und Logs erstellt wurden. Dadurch konnten wir die Ergebnisse gut dokumentieren.

Ausserdem konnten wir unsere Kenntnisse aus dem Modul 122 praktisch anwenden. Wir haben gelernt, wie man PowerShell-Befehle kombiniert, Ausgaben verarbeitet, Dateien erstellt und mehrere Skripte zu einem gemeinsamen Tool verbindet.

Was nicht so gut lief

Nicht ganz so gut lief am Anfang die Umsetzung einzelner PowerShell-Befehle. Einige Befehle haben länger geladen oder Fehlermeldungen verursacht. Besonders bei der Netzwerk-Analyse mussten wir einzelne Stellen im Code anpassen, damit das Modul korrekt funktioniert.

Ein weiteres Problem war die Darstellung von Umlauten in der PowerShell. Einige Wörter wurden nicht korrekt angezeigt, zum Beispiel bei „öffnen“ oder „zurück“. Dieses Problem hatte jedoch keinen Einfluss auf die Funktion des Tools.

Auch das Testen und Dokumentieren brauchte mehr Zeit als erwartet. Da jedes Modul einzeln getestet und mit Screenshots dokumentiert werden musste, war eine saubere Planung wichtig.

Fazit

Das Projekt war für uns sehr lehrreich. Wir konnten ein eigenes PowerShell-Tool entwickeln und dabei verschiedene Inhalte aus dem Modul 122 praktisch anwenden. Besonders wichtig war die Arbeit mit PowerShell-Skripten, Modulen, Reports und Log-Dateien.

Am Ende entstand ein funktionierendes System-Management-Tool, das über ein Hauptmenü bedient werden kann. Die wichtigsten Funktionen wurden erfolgreich getestet und dokumentiert. Das Projekt hat uns gezeigt, wie PowerShell im Bereich Systemverwaltung eingesetzt werden kann und wie wichtig eine saubere Struktur bei grösseren Skript-Projekten ist.

Für zukünftige Projekte würden wir noch früher mit dem Testen beginnen und die Dokumentation laufend ergänzen. Insgesamt sind wir mit dem Ergebnis zufrieden, da das Tool funktioniert und die wichtigsten Anforderungen erfüllt.

Gruppenmitglieder: Aline Remund, Olivia Franz, Nicole Erismann

Projektbeschrieb

In diesem Projekt haben wir draussen in der Natur Bilder mit uns als Motiven gemacht. Die Idee für dieses Projekt kam vom Fotografie ÜK den wir abgeschlossen haben. In dem ÜK mussten wir auch draussen Fotos machen gehen und hatten dabei oft mal das Problem, dass es schwierig war mit der Beleuchtung. Da das Licht sich ständig veränderte, weil mal wieder die Wolken kamen oder wir an einen anderen Ort gingen mit anderen Lichtverhältnissen, mussten wir die Kamera immer neu einstellen. In diesem Projekt wollten wir das nochmal ein wenig besser lernen. Eine weitere Motivation für dieses Projekt war Pinterest. Uns wurden schon oft Bilder angezeigt, die in dieselbe Richtung gingen wie das, was wir uns vorgestellt haben. So hatten wir eine Inspirationsquelle.

Zu dem Projekt gehört nicht nur das Fotografieren, sondern auch anschliessend das Color Grading. Auch in dem Bereich wollten wir noch mehr Erfahrung sammeln und einfach mal ein wenig experimentieren.

Was lief gut

Die Planung und die Absprache für unser Projekt lief sehr gut. Wir waren uns stets einig und hatten auch dieselben Vorstellungen davon, wie die Bilder schlussendlich aussehen sollten.

Auch die Suche nach der passenden Location lief gut. Zuerst waren wir uns nicht sicher, wo wir die Fotos machen sollten, aber nach etwas Recherche haben wir einen schönen Ort gefunden. Dieser Ort ist gut mit dem ÖV erreichbar und wir hatten alle gute Verbindungen. Dieser Spot hatte alle Anforderungen, die wir hatten, erfüllt und wir waren sehr zufrieden.

Was lief nicht so gut

Schwierigkeiten hatten wir grundsätzlich keine. Das einzige, was ein wenig unvorteilhaft war bei diesem Projekt, ist, dass das Wetter nie besonders gut war. Wir wären froh gewesen, wenn die Sonne geschienen hätte. Trotz des nicht ganz so idealen Wetter, kamen dabei trotzdem schöne Bilder heraus.

Fazit

Das Projekt hat uns dabei geholfen, die Kameraeinstellungen nochmal ein bisschen mehr zu verstehen, und es fällt uns inzwischen um einiges leichter, die Kameraeinstellungen den Lichtverhältnissen gemäss anzupassen. Auch mit dem Color Grading haben wir uns vertrauter gemacht und haben verschiedene Stile ausprobiert, was sehr interessant war.

Die Teamarbeit hat gut geklappt und wir hatten Spass beim Fotografieren.

Teamleiter: Lean Muhovic
Teammitglieder: Tharun Thiripuranathan, Elvin Brian Röthlisberger und Walid Sekandari

Für dieses Projekt haben wir eine webbasierte Anwendung in Form eines klassischen Memory-Spiels namens NavyMemory entwickelt. Die Idee entstand während der Brainstorming-Phase, in der wir verschiedene Projektansätze auf ihre Machbarkeit geprüft haben. Ein Memory-Spiel erwies sich als idealer Kompromiss: Es ist technisch anspruchsvoll genug, um wirklich etwas zu lernen, aber gleichzeitig klar genug, um es im vorgegebenen Zeitrahmen sauber umzusetzen. Im Zentrum des Spielprinzips steht das Aufdecken von verdeckten Karten und das paarweise Abgleichen der Motive. Die gesamte Logik dahinter – von der Zustandsverwaltung bis zur Zeitsteuerung – hat uns im Verlauf des Projekts viel abverlangt, uns aber gleichzeitig sehr viel gelehrt.

Die Aufgaben im Team waren klar verteilt. Als Teamleiter habe ich die Koordination übernommen und darauf geachtet, dass jeder weiss was er zu tun hat und die Arbeitspakete fair aufgeteilt sind. Ein Teil des Teams hat sich auf die JavaScript-Logik konzentriert – das Umdrehen der Karten, den algorithmischen Paarvergleich und die asynchrone Zeitsteuerung. Die anderen haben die HTML-Struktur aufgebaut, das Design mit Tailwind CSS umgesetzt und die Dokumentation nach IPERKA verfasst. Bei komplexen Problemen haben wir uns gegenseitig unterstützt, was die Arbeit deutlich effizienter gemacht hat.

Den gesamten Projektablauf haben wir nach der IPERKA-Methode strukturiert. Diese Vorgehensweise hat uns geholfen, den Überblick zu behalten und Entscheidungen nachvollziehbar zu begründen. Ein konkretes Beispiel dafür war die Variantenentscheidung: Wir haben eine browserbasierte Lösung mit lokalem Speicher einer serverbasierten Lösung mit Datenbank gegenübergestellt und uns bewusst für Variante 1 entschieden, da der Entwicklungsaufwand für ein Backend unsere Vorkenntnisse und den Zeitrahmen gesprengt hätte.

Das fertige Produkt NavyMemory läuft stabil, ist vollständig responsiv und überzeugt mit einem sauberen Navy-Blau-Design. Das Spielfeld passt sich automatisch an verschiedene Bildschirmgrössen an. Nach Spielende erscheint ein animiertes Overlay mit der Anzahl der benötigten Züge sowie einem Konfetti-Effekt. Alle im Pflichtenheft definierten Anforderungen wurden erfüllt, und das Endprodukt befindet sich in einem ausgereiften, abgabebereiten Zustand.

Was besonders gut gelaufen ist:

• Die teaminterne Koordination zwischen Tharun, Elvin, Walid und mir funktionierte hervorragend, was zu einer sehr hohen Produktivität führte.
• Die Einarbeitung in das Framework Tailwind CSS verlief sehr effizient und ermöglichte uns ein professionelles Styling sowie ein vollkommen responsives Grid Layout ohne grossen Zeitverlust.
• Die komplexe Logik der Echtzeit Auswertung der Kartenwerte in JavaScript konnte unter Zuhilfenahme von Tutorials und künstlicher Intelligenz absolut stabil und ohne Latenzen implementiert werden.
• Das fertige Programm bietet eine flüssige Benutzererfahrung inklusive toller visueller Effekte wie einer Konfetti Animation bei einem Sieg und erfüllt alle im Pflichtenheft definierten Anforderungen.

Was anfangs nicht ganz so optimal gelaufen ist:

Die initiale Konzeptionsphase bezüglich des genauen technischen Aufbaus verlief zu Beginn noch etwas unklar, bevor wir uns final für den unabhängigen Weg der Variante 1 mit lokalem Speicher anstelle einer komplexen Serverdatenbank entschieden haben.

Zu Beginn der Recherchephase herrschte durch das massive, unübersichtliche Informationsangebot im Internet kurzzeitig Unklarheit über die passenden JavaScript Funktionen, was jedoch durch die Gruppe schnell gefiltert werden konnte.

Die präzise Absicherung des Spielfelds gegen illegale Klicks während der Wartezeit erforderte mehrere Anläufe und Testreihen, bis die mathematische Logik der Statusverriegelung fehlerfrei war.

Fazit: NavyMemory war für uns ein lehrreiches und gelungenes Projekt. Wir haben gesehen, wie aus einer einfachen Idee eine funktionierende Webanwendung entsteht, und dabei konkret gelernt wie man JavaScript-Events, DOM-Manipulation, CSS-Animationen und asynchrone Zeitsteuerung in der Praxis einsetzt. Rückblickend war die saubere Planung nach IPERKA und die klare Aufgabenverteilung der entscheidende Faktor dafür, dass wir das Projekt termingerecht und in guter Qualität abschliessen konnten. Die Herausforderungen die wir hatten – vor allem beim Debugging der Spiellogik – haben uns gezeigt, dass strukturiertes Vorgehen und Geduld bei der Fehlersuche wichtiger sind als schnelles Drauflosprogrammieren.

MITGLIEDER:
Yaroslav Liashenko
Janosch Bilang

Für dieses Projekt haben wir eine vollständige virtuelle Unternehmensumgebung auf Basis von Windows Server 2022 aufgebaut. Die Idee entstand aus dem Wunsch, die im Unterricht gelernten Konzepte wie Active Directory, DNS und DHCP praktisch anzuwenden. Eine Windows-Domänenumgebung mit mehreren Servern erwies sich als ideales Projektziel: technisch anspruchsvoll genug, um echte Administrationskenntnisse zu entwickeln, aber gleichzeitig klar strukturiert genug, um es im vorgegebenen Zeitrahmen sauber umzusetzen.

Die Aufgaben im Team waren klar verteilt. Als Projektleiter habe ich die Koordination übernommen und den Domain Controller konfiguriert. Janosch hat sich auf den Fileserver, den DHCP-Server und den Windows Client konzentriert. Den Webserver haben wir gemeinsam eingerichtet. Bei technischen Problemen haben wir uns gegenseitig unterstützt, was die Arbeit deutlich effizienter gemacht hat.

Den gesamten Projektablauf haben wir nach der IPERKA-Methode strukturiert. Diese Vorgehensweise hat uns geholfen, den Überblick zu behalten und Entscheidungen nachvollziehbar zu begründen. Ein konkretes Beispiel war die Variantenentscheidung: Wir haben eine lokale VirtualBox-Umgebung einer Cloud-Lösung mit Microsoft Azure gegenübergestellt und uns bewusst für Variante 1 entschieden, da VirtualBox kostenlos ist, offline funktioniert und den grössten Lerneffekt bietet.

Das fertige Produkt umfasst vier virtuelle Maschinen, die vollständig miteinander vernetzt sind. Der Domain Controller stellt Active Directory, DNS und DHCP bereit. Der Fileserver bietet Netzwerkfreigaben mit Benutzerberechtigungen. Der Webserver liefert eine interne Unternehmenswebseite über IIS aus. Der Windows Client ist in die Domäne aufgenommen und alle Gruppenrichtlinien werden korrekt angewendet. Alle im Pflichtenheft definierten Anforderungen wurden erfüllt.

Was besonders gut gelaufen ist: Die schrittweise Vorgehensweise – zuerst DC01, dann Fileserver und Webserver, zuletzt Client und GPOs – hat sich bewährt und Fehler früh sichtbar gemacht. Die Konfiguration von Active Directory verlief reibungslos und das Verständnis für die Zusammenhänge zwischen DNS, Domänenbeitritt und Gruppenrichtlinien ist durch die praktische Umsetzung deutlich gewachsen. Die Teamarbeit und gegenseitige Unterstützung bei technischen Problemen haben das Projekt effizient vorangebracht.

Was anfangs nicht ganz so optimal gelaufen ist: Die Netzwerkkonfiguration in VirtualBox bereitete zu Beginn Schwierigkeiten, da die Unterscheidung zwischen NAT, Bridged und Internal Network nicht sofort klar war. Falsche Adaptereinstellungen führten dazu, dass VMs sich gegenseitig nicht erreichen konnten. Ausserdem haben wir den Dokumentationsaufwand anfangs unterschätzt und Screenshots nicht konsequent genug während der Realisierung gemacht.

Fazit: Der Aufbau der virtuellen Unternehmensumgebung war ein lehrreiches und praxisnahes Projekt. Wir haben gesehen, wie eine funktionierende IT-Infrastruktur Schritt für Schritt entsteht, und dabei konkret gelernt, wie Active Directory, DNS, DHCP, Gruppenrichtlinien und Netzwerkfreigaben in der Praxis zusammenspielen. Rückblickend war die klare Planung nach IPERKA und die strukturierte Aufgabenverteilung entscheidend dafür, dass wir das Projekt termingerecht abschliessen konnten. Die Herausforderungen beim Netzwerk-Setup haben uns gezeigt, dass systematisches Vorgehen und das Überprüfen der Grundkonfiguration wichtiger sind als schnelles Draufloskonfigurieren.

Projektleiter: Noah Scherrer

Teammitglieder: Finn Ratzinger, Alan Omar

Auto Simulator ist eine objektorientierte PHP-Konsolenapplikation, die virtuelle Fahrzeuge verwaltet und deren Fahrdynamik in Echtzeit simuliert.

Die Applikation läuft über zwei parallele CLI-Prozesse: Der Menü-Prozess erlaubt dem Benutzer, Fahrzeuge zu erstellen, anzuzeigen, zu mutieren und zu löschen. Der Simulations-Prozess interpoliert die Geschwindigkeit jedes fahrenden Fahrzeugs sekündlich in Richtung Zielgeschwindigkeit und akkumuliert die zurückgelegte Distanz. Beide Prozesse kommunizieren über eine gemeinsame JSON-Datei (carupdated.json) als Flag.

Technisch basiert das Projekt auf einer klaren OOP-Hierarchie: Die Basisklasse Vehicle wird von Car erweitert, welche zusätzlich das Interface Drivable implementiert. Fahrzeugdaten werden im JSON-Persistenzlayer (Car.json) gespeichert und über CarRepository gelesen und geschrieben.

Teamleiter: Alex Eisner

Teammitglieder: Roman Leuch, Lias Vogler

Projektbeschreibung

In unserem Projekt entwickeln wir ein eigenes 2D-Top-Down-Dungeon-Game mit der Game Engine Unity und der Programmiersprache C#. Ziel des Projekts ist es, ein spielbares Spiel zu erstellen, bei dem der Spieler verschiedene Räume erkunden, Gegner bekämpfen und Erfahrungspunkte sammeln kann.

Das Spiel orientiert sich an bekannten Spielen wie The Legend of Zelda und kombiniert verschiedene Elemente wie Kämpfe, zufällig generierte Räume und ein HUD-System. Dabei entwickeln wir viele Funktionen selbst, zum Beispiel das Gegner-System, die Animationen, die Lebens- und XP-Leisten sowie die Steuerung des Spielers.

Ausserdem gestalten wir das Spiel im Pixelart-Stil und entwickeln ein eigenes HUD mit Lebens- und Erfahrungspunkte-Leisten. Die Steuerung funktioniert sowohl mit Tastatur als auch mit einem Controller.

Am Ende soll das Spiel mehrere Räume besitzen, Gegner enthalten und ein funktionierendes Kampfsystem bieten. Ziel des Projekts ist es, unsere Kenntnisse in C# und Unity zu erweitern und praktische Erfahrungen im Bereich Game-Entwicklung zu sammeln.

Was hat gut funktioniert?

• Gute Zusammenarbeit im Team und klare Aufgabenaufteilung
• Die zufällig generierten Räume funktionieren korrekt
• Das HUD mit Lebens- und XP-Leiste funktioniert zuverlässig
• Die Animationen des Spielers und des Schwerts funktionieren
• Die Gegner können den Spieler verfolgen und Schaden verursachen
• Projektil-Gegner funktionieren korrekt
• Das Interface-System für Gegner funktioniert auch bei geklonten Gegnern
• Die Steuerung mit Tastatur und Controller konnte erfolgreich umgesetzt werden
• Die Pixelgrafik passt gut zum Stil des Spiels

Was hat weniger gut funktioniert?

• Kollisionen zwischen Gegnern, Projektilen und dem Spieler verursachten anfangs Probleme
• Die Berechnung der Lebens- und XP-Leisten musste mehrfach angepasst werden
• Einige Animationen funktionierten zuerst nicht korrekt
• Das Balancing der Gegner und Schadenwerte benötigte mehrere Tests

Fazit

Das Projekt war insgesamt sehr lehrreich und spannend. Wir konnten viele neue Kenntnisse im Bereich C#, Unity und Game-Entwicklung sammeln.

Besonders hilfreich war das Arbeiten mit Gegner-KI, Animationen, UI-Systemen und Kollisionen. Zusätzlich konnten wir lernen, wie mehrere Scripts miteinander kommunizieren und wie ein grösseres Projekt strukturiert wird.

Trotz einiger Probleme konnten wir am Ende ein funktionierendes Spiel entwickeln. Das Projekt hat uns geholfen, Theorie und Praxis miteinander zu verbinden und wichtige Erfahrungen für zukünftige Programmierprojekte zu sammeln.

https://gitlab.bbbaden.ch/projekttag/the-legend-of-c-sharp

Im Rahmen der Module 162, 164 und 106 haben wir eine webbasierte Umfrage entwickelt, die über PHP ausgefüllt wird und die Antworten automatisch in einer SQL‑Server‑Datenbank speichert. Ziel des Projekts war es, die theoretischen Inhalte aus den Modulen praktisch anzuwenden und ein funktionierendes System zu erstellen, das Feedback zur Informatik‑Ausbildung strukturiert erfassen kann.

Dazu haben wir ein HTML/PHP‑Formular erstellt, die benötigten SQL‑Tabellen aufgebaut und die Verbindung zwischen PHP und SQL-Server eingerichtet. Wir haben Treiber installiert, die Datenbank vorbereitet und die Eingaben so gestaltet, dass sie später ausgewertet werden können. Während der Umsetzung haben wir die Datenbankstruktur geplant, Testfälle definiert und die technische Umsetzung dokumentiert.

Obwohl das Interface und die Datenbank funktionierten, konnten wir die Umfrage am Ende nicht durchführen, da sie nur im gleichen Netzwerk erreichbar war und wir im Homeoffice gearbeitet haben. Trotzdem konnten wir viele technische Erfahrungen sammeln und unser Wissen über SQL, PHP und Datenbankverbindungen vertiefen.

Unsere Erfahrungen

Während des Projekts konnten wir unser SQL‑Wissen aus den Modulen gut anwenden und erweitern. Besonders spannend war es, PHP zum ersten Mal praktisch einzusetzen und zu sehen, wie Webformulare mit einer Datenbank zusammenarbeiten. Die Teamarbeit funktionierte gut, und wir konnten uns gegenseitig unterstützen, wenn technische Probleme auftraten.

Motivierend war vor allem, dass wir ein reales, funktionierendes System entwickeln wollten und dadurch einen klaren Praxisbezug hatten. Auch das Einrichten der Datenbank und das Erstellen der Tabellen hat uns gezeigt, wie viel wir bereits beherrschen.

Schlechte Erfahrungen

Eine grosse Schwierigkeit war die Verbindung zwischen PHP und SQL-Server, da die Treiber und Einstellungen teilweise komplex waren und mehrfach Fehler verursachten. Auch das Einrichten der Netzwerkzugriffe hat uns Zeit gekostet.

Der grösste Rückschlag war jedoch, dass wir die Umfrage am Ende nicht durchführen konnten, weil sie nur im lokalen Netzwerk funktionierte. Da wir im Homeoffice arbeiteten, war ein gemeinsamer Zugriff nicht möglich. Diese Einschränkung haben wir zu spät bemerkt, was unser Projektziel beeinträchtigt hat.

Verbesserungsmöglichkeiten

Für zukünftige Projekte könnten wir die technische Planung früher und detaillierter durchführen, insbesondere im Bereich Netzwerk und Serverzugriff. Eine frühere Testphase hätte uns geholfen, das Problem mit dem lokalen Netzwerk rechtzeitig zu erkennen.

Auch die Vorbereitung der PHP‑SQL‑Verbindung könnten wir besser strukturieren, z. B. durch frühere Tests, klarere Dokumentation der Treiberinstallation oder alternative Hosting‑Lösungen. Zudem wäre es sinnvoll, mögliche Risiken zu Beginn zu analysieren, um spätere Probleme zu vermeiden.