diff --git a/docs/IF_Projekte/Bruteforce/Allgemein.md b/docs/IF_Projekte/Bruteforce/Allgemein.md
new file mode 100644
index 0000000..b072b0f
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Allgemein.md
@@ -0,0 +1,36 @@
+# Allgemein
+
+Created: 2025-09-05 07:39:40 +0200
+
+Modified: 2025-11-26 13:12:33 +0100
+
+---
+
+**Endtermin**
+
+Ende Probezeit 24. Oktober 2025
+
+
+
+**Meilensteine**
+
+| Datum | Ergebnis |
+|-------|-----------------------|
+| | Code Eingabe über CYD |
+| | BruteForce |
+| | |
+
+
+
+| **Phase / Aufgabe** | **Dauer (in Tage)** | **Zeitraum** | **Meilenstein** |
+|:-----------------------------:|:--------:|:------------------:|:-----------:|
+| Informieren | 1 | Mi, 26. Nov | Grundlagen klar |
+| Planen (SMART-Ziel, Anforderungen, Risikoanalyse, System & User Kontext, SW-Architektur & Design, Tools, BackUp Strategie (Datenverlust) ) | 4 | Do, 27. Nov; Fr, 28. Nov (Nachmittag) Mi, 3. Dez; Do, 4. Dez | Konzept + Anforderungen |
+| Entscheiden (Algorithmus, Aufbau wählen, Material fixieren) | 1 | Fr, 5. Dez (Nachmittag) | Lösungsweg fix |
+| Realisieren (TouchPad, LEDs, CYD, M5Stamp) | 6 | Mi, 10. Dez -- Fr, 12. Dez (Na); Mi, 17. Dez -- Do, 18. Dez | Hardware läuft |
+| Realisieren (Software / Bruteforce Algorithmus) | 6 | Fr, 19. Dez (Nachmittag); Mi, 7. Jan -- Fr, 9. Jan | Code läuft |
+| Kontrollieren & Testen | 2 | Mi, 14. Jan -- Do, 15. Jan | System stabil |
+| Auswerten & Dokumentation | 4 | Fr, 16. Jan (Nachmittag); Mi, 21. Jan -- Fr, 23. Jan | Doku fertig |
+| Reserve / Puffer | 2 | Mi, 28. Jan -- Do, 29. Jan | Für unerwartete Probleme |
+| | | | |
+| Total Tage | 26 Tage | | |
diff --git a/docs/IF_Projekte/Bruteforce/Allgemein/Ideen,-Gedanken,-Notizen.md b/docs/IF_Projekte/Bruteforce/Allgemein/Ideen,-Gedanken,-Notizen.md
new file mode 100644
index 0000000..5a40140
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Allgemein/Ideen,-Gedanken,-Notizen.md
@@ -0,0 +1,9 @@
+# Ideen, Gedanken, Notizen
+
+Created: 2025-09-26 12:41:09 +0200
+
+Modified: 2025-11-26 12:22:36 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Allgemein/Kanban-Board.md b/docs/IF_Projekte/Bruteforce/Allgemein/Kanban-Board.md
new file mode 100644
index 0000000..6f448c3
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Allgemein/Kanban-Board.md
@@ -0,0 +1,49 @@
+# Kanban-Board
+
+Created: 2025-09-05 08:14:03 +0200
+
+Modified: 2025-12-12 12:05:53 +0100
+
+---
+
+Wenn du deine anderen Lernaufträge erledigt hast oder sonst wie anstehst und nicht mehr weiterkommst, kannst du dir hier einen Job aussuchen. Wer mehr Jobs erledigt, zeigt dass er ein schnelles Arbeitstempo hat und der Arbeit grundsätzlich nicht aus dem Weg geht. Jeder Job gibt Credits und diese Credits kann man gegen was einlösen. Credits gibt es aber nur für richtig abgeschlossene Jobs. Wenn die Jobs keinen Link haben, so musst du kurz beim Berufsbildner nachfragen, damit er mit dir den Job besprechen kann. Dazu gehört auch die Qualitätserwartung.
+
+Wenn du links von einem Job auf den Pfeil klickst, kannst du die Zelle bewegen:
+
+1. Such dir einen Job aus und bewege ihn in die Spalte "In work". Ergänze dabei die Zelle mit deinen Initialen und einem geschätzten Zeitaufwand in Stunden [HB, 1.5h] (VornameNachname, z.B. HB für Harry Bo) damit alle wissen, wer diesen Job bearbeitet und wieviel Zeit dafür eingeplant ist.
+2. Hast du den Job erledigt, dann verschiebe ihn in die Spalte "Ready for Proof". Ergänze die Zelle mit deinem effektivem Aufwand in Stunden [HB, 1.5h/2h]. Du kannst nun einen neuen Job in Angriff nehmen. Es dürfen aber maximal nur 2 Jobs gleichzeitig von dir bearbeitet werden.
+3. Solange der Job in "Ready for Proof" ist, ist er noch nicht abgeschlossen. Das heisst konkret, dass irgendwer noch eine Qualitätskontrolle macht und bei Beanstandungen wieder zurück gibt.
+4. Ist der Job geprüft und für gut befunden worden, verschiebt der Auftraggeber ihn zu "Done"
+
+:
+
+| 🗃️ **Backlog (To-Do-Liste)** |
+|:------------------------------------------:|
+| Die Code-Eingabe in den Safe transferieren |
+| UART; WebSockets; HTTP; Testen |
+| Grafische Inhalte / Doku |
+| |
+| |
+| |
+
+| 🛠️ In work (In Bearbeitung) |
+|:-------------------------------------------------:|
+| Planung (Meilensteine) |
+| Bedienungsanleitung für Code-Eingabe => muss ausdruckbar sein (laminieren und in den Safe legen) |
+| |
+| |
+
+| 🔎 Ready for Proof (Frei zum Testen) |
+|:-----------------------------------------------------------:|
+| 4x4 RGB TP-M5: Code-Eingabe (0-9) und Anzeige über LED |
+| 4x4 RGB Touchpad mit M5Stamp ansteuern => PowerON-LED-Test |
+| RE: Stakeholder (Tabelle) [NP, 0.5h/0.75h] |
+| RE: Stakeholder (Diagramm) [NP, 0.5h/0.5h] |
+| |
+| |
+
+| ✅ Done (Erledigt) |
+|:------------------:|
+| |
+| |
+| |
diff --git a/docs/IF_Projekte/Bruteforce/Allgemein/Theorie.md b/docs/IF_Projekte/Bruteforce/Allgemein/Theorie.md
new file mode 100644
index 0000000..3a1055a
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Allgemein/Theorie.md
@@ -0,0 +1,33 @@
+# Theorie
+
+Created: 2025-11-26 10:18:00 +0100
+
+Modified: 2025-11-26 10:18:14 +0100
+
+---
+
+1. Bruteforce im Allgemeinen
+
+Bruteforce bedeutet, dass man alle möglichen Codes nacheinander ausprobiert, bis der richtige gefunden wird. Zum Beispiel bei einem vierstelligen Code von 0000 bis 9999. Diese Methode ist sehr einfach, aber auch eher langsam, weil wirklich jede Kombination getestet werden muss. So sieht man gut, wie Sicherheit und Zeit zusammenhängen und warum zu einfache Codes nicht wirklich sicher sind.
+
+
+
+2. Warum Bruteforce wichtig ist
+
+Mit Bruteforce lernt man verschiedene Dinge:
+
+- Wie Algorithmen funktionieren (z. B. Schleifen und Bedingungen)
+- Warum manche Lösungen länger dauern und andere schneller sind
+- Wie einfach ein Code geknackt werden kann, wenn er kurz oder zu simpel ist
+- Wie Hardware und Software zusammenarbeiten
+- Wie man Systeme verbessern oder optimieren kann
+
+Bruteforce ist also ein gutes Beispiel, um zu verstehen, wie Sicherheit in der Informatik aufgebaut ist.
+
+
+
+3. Bruteforce in meinem Projekt
+
+In meinem Projekt probiert mein System automatisch alle Codes durch, bis der Safe den richtigen akzeptiert. So sehe ich, wie viele Versuche nötig sind und wie lange das Bruteforce braucht. Ich lerne dabei, wie man ein Touchpad automatisch steuert, wie man LEDs und ein Display nutzt, um den Status anzuzeigen, und wie man einen Bruteforce‑Algorithmus richtig aufbaut.
+
+Das Projekt zeigt sehr gut, dass einfache PIN-Codes schnell gefunden werden können und dass man für echte Sicherheit stärkere Passwörter braucht.
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement.md b/docs/IF_Projekte/Bruteforce/Projektmangement.md
new file mode 100644
index 0000000..cb0c98a
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement.md
@@ -0,0 +1,9 @@
+# Projektmangement
+
+Created: 2025-11-26 10:22:54 +0100
+
+Modified: 2025-11-26 10:22:56 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Auswerten.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Auswerten.md
new file mode 100644
index 0000000..8229781
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Auswerten.md
@@ -0,0 +1,9 @@
+# Auswerten
+
+Created: 2025-11-26 12:20:09 +0100
+
+Modified: 2025-11-26 12:20:13 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Entscheiden.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Entscheiden.md
new file mode 100644
index 0000000..d707e1d
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Entscheiden.md
@@ -0,0 +1,170 @@
+# Entscheiden
+
+Created: 2025-11-26 12:19:42 +0100
+
+Modified: 2025-12-05 13:01:06 +0100
+
+---
+
+| Hardware: | Software | IDE | Owner |
+|-----------|---------------------|-------------|-----------------------|
+| M5Stamp | Selbst programmiert | Arduino IDE | Noah |
+| CYD | Selbst programmiert | Arduino IDE | Noah |
+| TouchPad | Selbst programmiert | Arduino IDE | Noah (Hardware=Fredy) |
+
+
+
+Projektversionierung (Backup): Gitea
+
+
+
+
+
+
+
+WebSockets
+
+
+
+
+
+
+
+
+
Nachteile
+
Vorteile
+
+
+
+
+
+
Hoher Strom Konsum
+
Keine Kabel verbindung nötig
+
+
+
Hohe latenz
+
schnell
+
+
+
Netzwerk / Server
+
Multi client
+
+
+
+
Lange distanz
+
+
+
+
+
+
+
+
+I2C
+
+
+
+
+
+
+
+
+
Nachteile
+
Vorteile
+
+
+
+
+
Kurze Distanz
+
Multi Client
+
Mehrere geräte am gleichen Bus
+
+
+
Pull Ups nötig
+
Integrierte ACK-Rückmeldung
+
+
+
Kann Daten blockieren oder verlieren
+
+
+
+
+
+
+
+
+
+
+
+
+
+Uart
+
+| Nachteile | Vorteile |
+|------------|------------------------|
+| End to End | Niedriges Strom Konsum |
+| | Braucht kein Internet |
+| | Wenig Latenz |
+| | RealTime |
+| | 0 packet loss |
+
+
+
+HTTP (GET/POST)
+
+
+
+Speed: 2/5
+
+50-150 Codes pro Sekunde
+
+
+
+Pro Request ca. 5-20ms Latenz
+
+Viel Overhead
+
+===========================================
+
+============================================
+UART (Seriell)
+
+
+
+Speed: 5/5
+
+5k-20k Codes pro Sekunde möglich
+
+
+
+Keine Netzwerklatenz
+
+Keine HTTP-Header
+
+============================================
+
+WebSockets
+
+
+
+Speed: 4/5
+
+500-2000 Codes pro Sekunde
+
+Persistent connection (keine neue Verbindungen)
+
+Kleinste Latenz über WiFi
+
+
+
+============================================
+
+
+
+I2C - wenig aufwand, schnell
+
+MQTT - bräuchte WLAN/LAN + Rpi5
+
+
+
+**TESTS NICHT IM CORP DURCHFÜHREN!!!!**
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Informieren.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Informieren.md
new file mode 100644
index 0000000..57f700f
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Informieren.md
@@ -0,0 +1,60 @@
+# Informieren
+
+Created: 2025-11-26 10:23:03 +0100
+
+Modified: 2025-11-27 13:39:03 +0100
+
+---
+
+============================================
+UART (Seriell)
+
+
+
+Speed: 5/5
+
+5k-20k Codes pro Sekunde möglich
+
+
+
+Keine Netzwerklatenz
+
+Keine HTTP-Header
+
+============================================
+
+WebSockets
+
+
+
+Speed: 4/5
+
+500-2000 Codes pro Sekunde
+
+Persistent connection (keine neue Verbindungen)
+
+Kleinste Latenz über WiFi
+
+
+
+============================================
+
+HTTP (GET/POST)
+
+
+
+Speed: 2/5
+
+50-150 Codes pro Sekunde
+
+
+
+Pro Request ca. 5-20ms Latenz
+
+Viel Overhead
+
+===========================================
+
+
+
+I^2^C
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Kontrollieren.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Kontrollieren.md
new file mode 100644
index 0000000..7fbb5f4
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Kontrollieren.md
@@ -0,0 +1,9 @@
+# Kontrollieren
+
+Created: 2025-11-26 12:20:03 +0100
+
+Modified: 2025-11-26 12:20:03 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen.md
new file mode 100644
index 0000000..2c43d36
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen.md
@@ -0,0 +1,25 @@
+# Planen
+
+Created: 2025-11-26 12:19:41 +0100
+
+Modified: 2025-11-26 13:30:13 +0100
+
+---
+
+| **Phase / Aufgabe** | **Dauer (in Tage)** | **Zeitraum** | **Meilenstein** |
+|:----------------------------:|:--------:|:------------------:|:-----------:|
+| Informieren | 1 | Mi, 26. Nov | Grundlagen klar |
+| Planen (SMART-Ziel, Anforderungen, Risikoanalyse, System & User Kontext, SW-Architektur & Design, Tools, BackUp Strategie (Datenverlust) ) | 4 | Do, 27. Nov; Fr, 28. Nov (Nachmittag) Mi, 3. Dez; Do, 4. Dez | Konzept + Anforderungen |
+| Entscheiden (Algorithmus, Aufbau wählen, Material fixieren) | 1 | Fr, 5. Dez (Nachmittag) | Lösungsweg fix |
+| Realisieren (Software / Bruteforce Algorithmus) | 6 | Fr, 19. Dez (Nachmittag); Mi, 7. Jan -- Fr, 9. Jan | Code läuft |
+| Kontrollieren & Testen | 2 | Mi, 14. Jan -- Do, 15. Jan | System stabil |
+| Auswerten & Dokumentation | 4 | Fr, 16. Jan (Nachmittag); Mi, 21. Jan -- Fr, 23. Jan | Doku fertig |
+| Reserve / Puffer | 2 | Mi, 28. Jan -- Do, 29. Jan | Für unerwartete Probleme |
+| | | | |
+| Total Tage | 26 Tage | | |
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Anforderungen.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Anforderungen.md
new file mode 100644
index 0000000..7dbfe09
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Anforderungen.md
@@ -0,0 +1,40 @@
+# Anforderungen
+
+Created: 2025-11-26 13:13:11 +0100
+
+Modified: 2025-11-27 13:16:13 +0100
+
+---
+
+Funktionale Anforderungen (Was das System können muss)
+
+1. Das CYD muss automatisch alle PIN‑Codes von 0000 bis 9999 durchprobieren.
+2. Es muss den richtigen Code erkennen und den Vorgang dann sofort stoppen.
+3. Das CYD soll
+
+ - den aktuellen getesteten Code anzeigen,
+ - den Fortschritt (z. B. Kombination 1234 von 9999),
+ - und die bisher benötigte Zeit.
+
+4. Das CYD sollen den Systemstatus anzeigen (z. B. „läuft", „Code gefunden", „Fehler").
+5. Ein Start‑Button soll den Bruteforce‑Vorgang auslösen.
+6. Das CYD soll nach dem Finden des Codes die Gesamtzeit anzeigen.
+7. Das M5Stamp muss zuverlässig die automatisch gesendeten Eingaben akzeptieren.
+
+
+
+Nicht‑funktionale Anforderungen (Wie gut es funktionieren soll)
+
+1. Das System soll stabil laufen, ohne während der Eingabe abzustürzen.
+2. Die Anzeige auf dem CYD muss leicht lesbar sein.
+3. Die Bedienung soll einfach sein (Taste drücken → System startet).
+4. Die Zeitmessung soll präzise sein.
+5. Der Code darf keine unnötigen Verzögerungen enthalten (effiziente Laufzeit).
+
+
+
+Rahmenbedingungen
+
+1. Verwendet werden ausschlieslich vorhandene Bauteile (M5Stamp, CYD, TouchPad).
+2. Die Software wird selbst programmiert.
+3. Das Projekt muss bis Ende der Sportferien fertig sein.
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/BackUp-Strategie.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/BackUp-Strategie.md
new file mode 100644
index 0000000..f10618d
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/BackUp-Strategie.md
@@ -0,0 +1,27 @@
+# BackUp Strategie
+
+Created: 2025-11-26 13:13:12 +0100
+
+Modified: 2025-11-27 13:50:13 +0100
+
+---
+
+Backup‑Strategie
+
+Um keinen Fortschritt zu verlieren, soll eine einfache Backup‑Strategie genutzt werden:
+
+1. Git‑Repository anlegen
+
+ - Code regelmässig pushen (gitea.psi.ch).
+
+2. Nach jeder grösseren Änderung committen
+
+ - Klar benannte Versionen, z. B. *"v1.2 -- CYD‑Anzeige verbessert"*.
+
+3. Wöchentliches Komplett‑Backup
+
+ - Projektordner zusätzlich in einer Cloud (9500 Laufwerk).
+
+4. Hardware‑Backup (optional)
+
+ - Zweites Touchpad, M5Stamp oder CYD bereithalten, falls etwas kaputtgeht.
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Konzept.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Konzept.md
new file mode 100644
index 0000000..746cb57
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Konzept.md
@@ -0,0 +1,131 @@
+# Konzept
+
+Created: 2025-12-12 13:25:55 +0100
+
+Modified: 2025-12-12 15:12:26 +0100
+
+---
+
+**1. Ausgangslage**
+
+Im Werkraum unserer Schule stand schon länger ein alter Safe. Niemand wusste genau, woher er kommt oder wie er funktioniert. Viele sagten einfach, er sei kaputt und man solle ihn irgendwann entsorgen.
+
+Ich fand das schade, denn für mich war der Safe ein spannendes technisches Objekt. Da er aber nicht mehr richtig funktionierte, entschied ich mich, eine **schulfreundliche Simulation** zu bauen, die zeigt, wie solche Systeme logisch arbeiten und wie Informatik damit umgeht.
+
+**2. Idee**
+
+Ich entwickle zwei kleine Geräte mit Cheap‑Yellow‑Displays (CYD):
+
+**CYD 1 -- Safe‑Simulator**
+- zeigt an, wie viele Codes pro Sekunde ankommen
+- zeigt den zuletzt geprüften Code
+- zeigt den Status: ❌ geschlossen / 🔄 prüfen / ✅ geöffnet
+- hat einen Knopf, um den Safe‑Code zu ändern
+
+**CYD 2 -- Bruteforce‑Gerät**
+- generiert nonstop Codes und sendet sie an den Safe
+- Geschwindigkeit ist per Slider einstellbar (ca. 10 bis 20'000 Codes pro Sekunde)
+- zeigt nur eigene Daten: aktueller Code, Geschwindigkeit, gesendete Anzahl
+- zeigt **nicht**, ob der richtige Code gefunden wurde
+- läuft endlos weiter, bis jemand auf STOP drückt
+
+**3. Ziel des Projekts**
+
+Mit diesem Projekt möchte ich zeigen:
+
+- wie man systematisch alle möglichen Werte testet (Bruteforce‑Algorithmus)
+- wie Geräte miteinander kommunizieren
+- wie Echtzeit‑Daten visualisiert werden können
+- wie wichtig Benutzeroberflächen sind
+- dass Informatik logisch ist und nicht zufällig funktioniert
+
+Das Projekt hat nichts mit echtem „Safeknacken" zu tun, es ist ein reines Lernprojekt für Informatik.
+
+**4. Funktionsweise & Datenfluss**
+
+**4.1 Kommunikation**
+
+- Das Bruteforce‑Gerät sendet laufend Codes an den Safe.
+- Der Safe prüft intern, ob ein Code übereinstimmt.
+- Der Safe sendet **keine Rückmeldung** zurück.
+- Das Bruteforce‑Gerät bleibt komplett blind es weiss nicht, ob es Erfolg hatte.
+
+**4.2 Endless‑Modus**
+
+Der Bruteforce‑CYD:
+
+- startet einen Code‑Generator
+- sendet ohne Pause weiter
+- weiss nie, ob der Safe geöffnet wurde
+- wird nur durch den Benutzer gestoppt
+
+Der Safe zeigt den Öffnungs‑Status ausschliesslich auf seinem eigenen Display.
+
+**5. Benutzeroberflächen**
+
+**5.1 Safe‑Simulator**
+
+Zeigt:
+
+- eingehende Codes pro Sekunde
+- zuletzt geprüften Code
+- Status (geschlossen / prüfen / geöffnet)
+- Knopf zum Code ändern
+
+Die Mitschülerinnen und Mitschüler sollen hier beobachten, ob sich etwas verändert.
+
+**5.2 Bruteforce‑Gerät**
+
+Zeigt:
+
+- Geschwindigkeit
+- aktuellen Code
+- gesendete Gesamtanzahl
+- Start/Stop
+
+Zeigt **nie**:
+
+- Treffer
+- Erfolg
+- Status des Safes
+
+Es ist eine reine „Code‑Maschine".
+
+**6. Didaktischer Nutzen**
+
+Das Projekt eignet sich gut für den Informatikunterricht, weil man dabei lernt:
+
+- wie Algorithmen funktionieren
+- wie Geräte Daten austauschen
+- wie man Prozesse visualisiert
+- wie Endlosschleifen und Benutzerinteraktion zusammenspielen
+- wie technische Abläufe logisch beobachtet werden
+
+Der Safe dient als verständliches Beispiel für ein System, das Eingaben prüft und seinen Status ändert.
+
+**7. Ablauf für den Unterricht**
+1. Bruteforce‑Gerät starten
+2. Geschwindigkeit einstellen
+3. Auf dem Safe‑Display beobachten:
+
+ - kommen die Codes an?
+ - bleibt die Rate stabil?
+ - ändert sich der Status irgendwann?
+
+4. Sobald „Safe geöffnet" erscheint, können die Schüler entscheiden, wann sie stoppen.
+
+**8. Erweiterungen**
+
+Falls später Zeit bleibt:
+
+- Animationen oder Diagramme
+- Anzeige der Verzögerung der Datenpakete
+- andere Code‑Längen
+- verschiedene Suchstrategien
+- Statistiken speichern oder exportieren
+
+**9. Fazit**
+
+Aus einem alten Safe, den viele schon abgeschrieben hatten, wurde ein spannendes Informatik‑Projekt. Die zwei CYDs machen sichtbar, wie Systeme miteinander kommunizieren und wie Informatik‑Prozesse wirklich aussehen.
+
+Ich zeige damit, dass man technische Probleme nicht sofort aufgeben muss mit Logik, Ausdauer und Neugier kann man vieles verstehen und selber nachbauen.
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Risikoanalyse.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Risikoanalyse.md
new file mode 100644
index 0000000..1754a1e
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Risikoanalyse.md
@@ -0,0 +1,28 @@
+# Risikoanalyse
+
+Created: 2025-11-26 13:13:11 +0100
+
+Modified: 2025-12-12 15:13:52 +0100
+
+---
+
+Bei meinem Projekt besteht nur ein kleines Risiko für Datenverlust, aber es gibt ein paar Punkte, die man beachten muss:
+
+- Code‑Verlust: Wenn ich meinen Programmcode falsch speichere oder ausversehen lösche, kann wichtige Code verloren gehen.
+- Hardwareausfall: Das CYD könnten kaputtgehen.
+- Fehler beim Flashen: Beim Compilen kann es passieren, dass Daten überschrieben werden.
+
+
+
+
+
+Umgang mit dem Risiko:
+
+1. Regelmässig den Code sichern (Gitea oder 9500 Laufwerk).
+
+- Versionen speichern, damit man jederzeit zurück kann.
+- Komponenten vorsichtig benutzen und testen.
+
+
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SMART.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SMART.md
new file mode 100644
index 0000000..f00fcb8
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SMART.md
@@ -0,0 +1,47 @@
+# SMART
+
+Created: 2025-11-26 12:28:46 +0100
+
+Modified: 2025-11-27 15:06:34 +0100
+
+---
+
+**Spezifisch:**
+
+Ich baue ein kleines System, das automatisch alle möglichen PIN‑Codes auf dem M5Stamp / TouchPad eingibt, bis der richtige Code gefunden wird. Auf einem CYD sieht man jederzeit, was das System gerade macht.
+
+
+
+**Messbar:**
+
+Das System soll komplett selbstständig alle Kombinationen von **0000 bis 9999** durchprobieren. Wenn es den richtigen Code findet, zeigt es an, wie lange es dafür gebraucht hat.
+
+
+
+**Attraktiv / Erreichbar:**
+
+Die Hardware habe ich schon: ein M5Stamp, ein Touchpad, ein CYD.
+
+Die Programmierung kann ich mit meinen aktuellen Fähigkeiten gut schaffen.
+
+
+
+**Realistisch:**
+
+Einen vierstelligen PIN zu bruteforcen ist technisch gut machbar. Dabei lerne ich auch etwas über Algorithmen, die Steuerung von Hardware und wie man ein Projekt richtig dokumentiert.
+
+
+
+**Terminiert:**
+
+Das komplette System soll bis **Ende der Sportferien** fertig sein.
+
+
+
+**Endziel / Visualisierung:**
+
+Am Ende soll ein kleines, sauberes Gerät auf dem Tisch stehen, das aus diesen Teilen besteht:
+
+- M5Stamp Mikrocontroller
+- Touchpad für die PIN‑Eingabe
+- CYD für Fortschritt, Zeit und aktuellen Code, Statusanzeigen
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SW-Architektur-Design.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SW-Architektur-Design.md
new file mode 100644
index 0000000..5d04923
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/SW-Architektur-Design.md
@@ -0,0 +1,72 @@
+# SW Architektur Design
+
+Created: 2025-11-26 13:13:11 +0100
+
+Modified: 2025-12-03 15:20:43 +0100
+
+---
+
+Software‑Architektur / Design
+
+Die Software soll klar aufgebaut sein, damit man sie verstehen und erweitern kann. Ein möglicher Aufbau:
+
+
+
+1. Eingabe‑Modul
+
+Steuert das Touchpad und führt die PIN‑Eingaben automatisch aus.
+
+
+
+2. Bruteforce‑Modul
+
+Generiert alle Codes von 0000 bis 9999.
+
+Zuständig für: Start, Schleifen, Abbruch wenn Code akzeptiert.
+
+
+
+3. Anzeige‑Modul
+
+CYD: zeigt aktuellen Code, Fortschritt, Zeit
+
+
+
+4. Zeitmess‑Modul
+
+Startet Timer bei Beginn, stoppt wenn Code gefunden wird.
+
+
+
+5. System‑Controller
+
+Verbindet alle Module, reagiert auf Start‑Taste, koordiniert den Ablauf.
+
+
+
+| {width="2.84375in" height="6.21875in"} | {width="4.760416666666667in" height="6.197916666666667in"} |
+|----------------------------|--------------------------------------------|
+
+
+
+{width="8.552083333333334in" height="1.8229166666666667in"}
+
+
+
+
+Auf diesem Link siehst du immer das neuste UI, inklusiv kannst du es als Animation abspielen.
+
+UI wurde zuletzt angepasst am: 03.12.2025
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Storytelling.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Storytelling.md
new file mode 100644
index 0000000..5a32f6f
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Storytelling.md
@@ -0,0 +1,41 @@
+# Storytelling
+
+Created: 2025-11-28 14:55:51 +0100
+
+Modified: 2025-11-28 16:04:19 +0100
+
+---
+
+In unserer Schule stand schon seit längerer Zeit ein alter Safe im Werkraum. Niemand wusste genau, woher er kam oder wem er ursprünglich gehörte. Die meisten sagten nur, er sei „kaputt" oder „wertlos", und dass man ihn irgendwann entsorgen sollte. Für viele war er einfach ein schwerer Metallkasten ohne Bedeutung.
+
+
+
+Für mich war er das nicht.
+
+Ich heisse Max, bin 14 Jahre alt und mein Hobby ist Technik, ich liebe Informatik. Als ich den Safe das erste Mal sah, hatte ich sofort das Gefühl, dass er nicht defekt ist sondern dass einfach nur der Code verloren gegangen war. Und wenn etwas logisch aufgebaut ist, dann kann man es auch logisch wieder öffnen.
+
+
+
+So entstand die Idee für mein Schulprojekt.
+
+Ich wollte zeigen, dass man ein technisches Problem nicht gleich aufgeben muss, nur weil es schwierig aussieht. Ein Safe funktioniert am Ende einfach nach Regeln: Er vergleicht einen eingegebenen Code mit einem gespeicherten Wert. Und wo Regeln sind, kann man sie systematisch durchprobieren.
+
+
+
+Darum entschied ich mich für einen Bruteforce‑Ansatz. Aber nicht irgendeinen, sondern einen, der zeigt, wie moderne Informatik wirklich arbeitet: schnell, effizient und möglichst nahe an der Hardware.
+
+
+
+Ich entwickelte ein System, das nicht mit Text, sondern direkt mit **binären 64‑Bit‑Werten** kommuniziert. So spare ich Zeit, Bandbreite und unnötige Verarbeitung. Mein Bruteforce‑Gerät generiert tausende Codes pro Sekunde, packt sie als Binärdaten in grosse Pakete und sendet sie über WebSockets an den Safe. Der Safe prüft jede Kombination intern und sendet nur ein einziges Byte zurück, wenn der richtige Code gefunden wurde: **0xFF**.
+
+
+
+Für mich war das Projekt eine Mischung aus Technik, Logik und Neugier. Ich wollte wissen, ob ich es schaffe, ein vollständiges, funktionierendes System zu bauen vom Algorithmus über die Datenübertragung bis zur Reaktion des Safes.
+
+Als das Gerät schliesslich funktionierte, wurde es plötzlich still im Raum.
+
+Der Safe sendete das „OK" Signal zurück. Das bedeutete: Der Code wurde tatsächlich gefunden. Kein Zufall, keine Gewalt, keine Tricks einfach Informatik.
+
+
+
+Für meine Mitschülerinnen und Mitschüler wurde der Safe so vom alten Schrottobjekt zu einem Beispiel dafür, wie man mit logischem Denken, sauberer Programmierung und etwas Geduld Probleme lösen kann. Und für mich wurde es zu einem Projekt, das zeigt, warum ich diesen Beruf gewählt habe.
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Tools.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Tools.md
new file mode 100644
index 0000000..7c9eaf6
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Planen/Tools.md
@@ -0,0 +1,27 @@
+# Tools
+
+Created: 2025-11-26 13:13:11 +0100
+
+Modified: 2025-12-12 15:14:22 +0100
+
+---
+
+Folgende Tools werden in diesem Projekt verwendet:
+
+Entwicklungs‑Tools
+
+- Arduino IDE (um den M5Stamp und CYD zu programmieren)
+- Git (Versionskontrolle und Backups)
+
+Dokumentation
+
+- OneNote (Texte, Doku) / GiteaPages
+- Flowgorithm
+- Figma (Visualisierungen, Grafiken, Mockup)
+
+Hardware‑Tools
+
+- CYD
+- Kabel
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Projektmangement/Realisieren.md b/docs/IF_Projekte/Bruteforce/Projektmangement/Realisieren.md
new file mode 100644
index 0000000..bb9b860
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Projektmangement/Realisieren.md
@@ -0,0 +1,15 @@
+# Realisieren
+
+Created: 2025-11-26 12:19:56 +0100
+
+Modified: 2025-12-12 15:14:43 +0100
+
+---
+
+Test: Projekte erstellen,
+
+
+
+Display,
+
+Verbindung I2C / HTTP / WS / UART
diff --git a/docs/IF_Projekte/Bruteforce/Requirements-Engineering.md b/docs/IF_Projekte/Bruteforce/Requirements-Engineering.md
new file mode 100644
index 0000000..49d016f
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Requirements-Engineering.md
@@ -0,0 +1,9 @@
+# Requirements-Engineering
+
+Created: 2025-09-05 07:42:52 +0200
+
+Modified: 2025-09-05 07:43:05 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Bruteforce/Requirements-Engineering/1.0-Stakeholder.md b/docs/IF_Projekte/Bruteforce/Requirements-Engineering/1.0-Stakeholder.md
new file mode 100644
index 0000000..bbb1d80
--- /dev/null
+++ b/docs/IF_Projekte/Bruteforce/Requirements-Engineering/1.0-Stakeholder.md
@@ -0,0 +1,63 @@
+# 1.0 Stakeholder
+
+Created: 2025-09-05 08:32:54 +0200
+
+Modified: 2025-10-07 14:44:39 +0200
+
+---
+
+Im Folgenden sind die Stakeholder aufgeführt
+
+
+
+
+
+
+
+
+
+
+
+
Stakeholder
+
Einflussbereich
+
Motivation
+
+
+
+
+
Schule & ÜK-Center
+
Ausbildungsmodule => kann ein Nutzen sein bezüglich Ausbildung und Zeit (Synergien), kann aber auch zu widersprüchlichen Ausbildungsinhalten führen
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren.md
new file mode 100644
index 0000000..16e4005
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren.md
@@ -0,0 +1,22 @@
+# Informieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-31 15:36:09 +0100
+
+---
+
+13:17
+
+
+
+IPERKA
+
+| **1** | **Informieren** |
+|-------|-----------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/Fragen.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/Fragen.md
new file mode 100644
index 0000000..f7baf7b
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/Fragen.md
@@ -0,0 +1,59 @@
+# Fragen
+
+Created: 2025-10-21 12:36:12 +0200
+
+Modified: 2025-10-31 14:13:02 +0100
+
+---
+
+**(Leit-) Fragen:**
+
+
+
+- Strategie
+ - Was wäre das Worst-Case-Szenario? Was kann passieren, dass du am Schluss ohne brauchbares Ergebnis dastehst?
+ - Anhand welchen Kriterien wirst du bei der IPA bewertet? Welche Gewichtung haben die einzelnen Kriterien?
+ - Was sind die Tod-Sünden bei der IPA?
+ - Welche Strategie verfolge ich bei dieser Aufgabenstellung?
+ - Warum verfolge ich gerade diese Strategie? Was sind die Vor- und Nachteile?
+ - Was ist deine Backup-Strategie?
+
+
+
+- SW-Qualität
+ - Wie definiert sich SW-Qualität?
+ - Welche Qualitätskriterien werden in deinem Fall erwartet?
+ - Wie überprüfe ich die Erreichung der Qualitätskriterien? Wie kann man dies messen und was wäre ein akzeptabler Messbereich, bzw. ab wann erfüllt man dies nicht mehr?
+ - Wie behalte ich diese Nicht funktionalen Anforderungen im Auge?
+ - Was bedeutet das SOLID-Prinzip?
+
+
+
+- Modularisierung
+ - Welche zeitgemässen Strategien gibt es in der SW-Entwicklung?
+ - Was ist ein Monolith und was sind die Vor- und Nachteile?
+ - Wie visualisiere ich meine SW-Module, -Komponenten, -Klassen, -Methoden, ...?
+
+
+
+- Interfaces
+ - Was ist ein Interface?
+ - Was sind die Vor- & Nachteile von Interfaces?
+ - Wann und wo setze ich Interfaces ein?
+
+
+
+- Test
+ - Wie gewährleistest du, dass deine Tests von einer anderen Person ausgeführt werden kann? Kommen 10 Personen auch wirklich zum gleichen Testergebnis?
+ - Wie prüfst du eine valide Eingabe, bzw. ob all deine Prüfkriterien wirklich funktionieren?
+ - Auf welche unerwarteten Eingaben prüfst du deine SW?
+ - Wie könnte man Tests automatisieren? Wie gewährleistest du, dass nach Änderungen die ganze SW wieder getestet wird?
+
+
+
+- Dokumentation
+ - Welche Strategie verfolge ich beim Dokumentieren?
+ - Gibt es nur eine Word-Datei oder Arbeite ich z.B. mit einem Anhang?
+ - Wann arbeite ich mit anderen Tools und Formaten? Wann gebe ich mich mit Word nicht zufrieden?
+ - Was mache ich, wenn sich Sachen im Word nicht veranschaulichen lassen?
+ - Wie gewährleiste ich, dass Resultate aus anderen Tools sich auch später noch bearbeiten lassen und nicht komplett neu erstellt werden müssen?
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/IPA-Bewertungskriterien.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/IPA-Bewertungskriterien.md
new file mode 100644
index 0000000..d9082d8
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Informieren/IPA-Bewertungskriterien.md
@@ -0,0 +1,583 @@
+# IPA-Bewertungskriterien
+
+Created: 2025-10-21 14:54:53 +0200
+
+Modified: 2025-10-31 14:13:02 +0100
+
+---
+
+Kriterien Auswahl [27.01.2025]
+
+
+
+
+
+{width="6.15625in" height="2.9479166666666665in"}
+
+
+
+
+
+{width="5.34375in" height="1.84375in"}
+
+
+
+1. Bewertungskriterien A1 -- A 11
+
+[*A1: Auftragsanalyse und Wahl einer Projektmethode *](https://2025.pkorg.ch/dashboard)
+
+| Leitfrage | Wie erfolgt die Auftragsanalyse? Welche Projektmethode kommt zum Einsatz? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Auftrag wurde ausreichend analysiert, um sicherzustellen, dass alle Anweisungen im weiteren Projektverlauf Berücksichtigung finden. | |
+| | 2. Eine zur Aufgabe passende Projektmethode wurde ausgewählt. | |
+| | 3. Die Wahl der Projektmethode ist nachvollziehbar und schriftlich begründet. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt ist erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+[*A2: Informations-Recherche*](https://2025.pkorg.ch/dashboard)
+
+| Leitfrage | Wie werden Informationen recherchiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Fehlende und für die IPA relevante Informationen wurden identifiziert und systematisch recherchiert. | |
+| | 2. Es wurde darauf verzichtet, allgemein bekannte Sachverhalte ausführlich wiederzugeben. | |
+| | 3. Alle verwendeten Informationen, einschliesslich solcher, die auf den Einsatz von künstlicher Intelligenz oder ähnlichen Technologien zurückzuführen sind, und die nicht auf eigener Leistung beruhen, sind entsprechend deklariert. | |
+| | 4. Die recherchierten Informationen sind verlässlich, aktuell und gültig. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+*[A3: Informations-Aufbereitung und -Verwendung]{.underline}*
+
+| Leitfrage | Wie werden Informationen effektiv aufbereitet und verwendet? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die verwendeten Informationen finden in einer klaren und übersichtlichen Dokumentation Niederschlag. | |
+| | 2. Es werden geeignete Visualisierungsmethoden wie Grafiken, Diagramme oder Tabellen eingesetzt. | |
+| | 3. Die bereitgestellten Informationen erlauben es einer Fachperson, ein umfassendes Verständnis der IPA (Dokumentation, Lösung) anzueignen. | |
+| | 4. Alle verwendeten Informationen stehen im Auftragskontext und finden im Projekt sinnvolle Anwendung. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A4: Zeitplan]{.underline}*
+
+| Leitfrage | Was sind die Anforderungen an den Zeitplan? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Zeitplan ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Der Zeitplan ist übersichtlich gestaltet. | |
+| | 3. Struktur und Elemente des Zeitplans orientieren sich nach der gewählten Projektmethode. | |
+| | 4. Es wurde eine Zeitachse definiert (Datum), die Zeitachse weist eine vernünftige Granularität auf (bspw. Stundenblöcke). | |
+| | 5. Die identifizierten Aktivitäten sind zweckmässig und folgen einer sinnvollen Logik. | |
+| | 6. Die IPA-Zeitvorgabe ist im Zeitplan korrekt berücksichtigt. | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+*[]{.underline}*
+
+*[A5: Überprüfung und Dokumentation der Fortschritte und Risiken]{.underline}*
+
+| Leitfrage | Wie erfolgt die Überprüfung und Dokumentation des Projektfortschritts und der Risiken? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Fortschritt wurde regelmässig überprüft, verständlich und korrekt dokumentiert. | |
+| | 2. Es gibt eine genaue Gegenüberstellung des geplanten und tatsächlichen Zeitplans (Soll-/Ist-Vergleich). | |
+| | 3. Es erfolgte eine periodische Risiko- und Problemüberprüfung. Bei einem allfälligen Eintreten eines Risikos oder Problems wurde professionell darauf reagiert. Es besteht hierzu ein schriftlicher Nachweis. | |
+| | 4. Nicht erreichte Ziele wie auch Korrekturmassnahmen und Nacharbeiten zur IPA sind beschrieben. Falls solche Aspekte nicht existieren, ist dies entsprechend begründet. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A6: Leistungsfähigkeit]{.underline}*
+
+| Leitfrage | Wie ist die Leistung einzustufen? | ? |
+|-------------|------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Ziele wurden effektiv verfolgt. | |
+| | 2. Die Produktivität entspricht der einer Fachperson. | |
+| | 3. Qualitätsansprüche wurden erfüllt. | |
+| | 4. Interaktionen mit anderen Personen erfolgten konstruktiv und effizient. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A7: Selbständiges Arbeiten]{.underline}*
+
+| Leitfrage | Wie selbständig wurde gearbeitet? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Ziele und Aufgaben wurden eigenständig verfolgt. | |
+| | 2. Eine ausgeprägte Fähigkeit zur Problemlösung wurde demonstriert; Hindernisse wurden eigenständig überwunden und/oder fremde Hilfe wurde angemessen in Anspruch genommen. | |
+| | 3. Die Fähigkeit zur Selbstmotivation wurde gezeigt, das Engagement war hoch. | |
+| | 4. Die Fähigkeit zur Selbstreflexion wurde gezeigt. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A8: Anwendung der Fachsprache]{.underline}*
+
+| Leitfrage | Wie ist die Anwendung der Fachsprache zu beurteilen? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Spezifische Begriffe und Terminologien wurden korrekt und konsistent verwendet. | |
+| | 2. Komplexe Fachthemen wurden präzise wiedergegeben oder erläutert. | |
+| | 3. Informationen wurden in einer logischen und strukturierten Weise wiedergegeben, um das Verständnis zu gewährleisten. | |
+| | 4. Es wurde eine Sprache gewählt, die dem Zielpublikum (externe Fachperson) angemessen ist. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A9: Anwendung der Fachkompetenz]{.underline}*
+
+| Leitfrage | Wie ist die Anwendung der Fachkompetenz zu beurteilen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das theoretische Wissen ist vorhanden und konnte in praktischen Situationen erfolgreich angewandt werden. Bei offensichtlichem Mangel an theoretischem Wissen wird dieser Punkt nicht gesprochen. | |
+| | 2. Informationen und Sachverhalte wurden kritisch analysiert, um fundierte Schlussfolgerungen zu ziehen. | |
+| | 3. Der Anspruch der Transferleistung ist erfüllt, da Fähigkeiten und Kenntnisse auf unerwartete oder neuartige Aufgabenstellungen angewandt wurden. | |
+| | 4. Methoden und Werkzeuge wurden passend zur gewählten Projektmethode ausgewählt und wirkungsvoll eingesetzt. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A10: Interaktion im Projektteam]{.underline}*
+
+| Leitfrage | Wie ist die Interaktion des Kandidaten mit den anderen Projektmitgliedern zu beurteilen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Standpunkte anderer Projektmitglieder wurden erkannt, eventuelle Unklarheiten wurden beseitigt. | |
+| | 2. Empfangende Informationen erhielten die nötige Aufmerksamkeit und wurden angemessen berücksichtigt. | |
+| | 3. Es wurde proaktiv kommuniziert und konstruktiv Rückmeldungen gegeben. | |
+| | 4. Es wurde effizient kommuniziert, bspw. unter Einsatz geeigneter Kommunikationstools | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A11: Abbildung der Projektaufbauorganisation]{.underline}*
+
+| Leitfrage | Welche Informationen zur Projektaufbauorganisation sind verlangt? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Projektaufbauorganisation ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Die zur Projektmethode passenden Rollen wurden identifiziert. | |
+| | 3. Die Rollen wurden prägnant und verständlich beschrieben. | |
+| | 4. Die Abhängigkeit der Rollen zueinander wurde korrekt dargestellt oder beschrieben. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+2. Bewertungskriterien A12-1 oder A12-2
+
+*[A12-1: Abnahme der Lösung]{.underline}*
+
+| Leitfrage | Wie erfolgt die Abnahme der Lösung? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Relevante Testszenarien wie auch Testkomponenten (bspw. Funktionen, Daten, Dokumente, Performance, Schnittstellen etc.) sind inkl. der erwarteten Ergebnisse beschrieben. | |
+| | 2. Es wurde eine Beschreibung der Testinfrastruktur und des Umfelds bereitgestellt, sodass eine externe Fachperson die Tests mit gleichen Ergebnissen reproduzieren kann. | |
+| | 3. Die Tests wurden durchgeführt. Die Ergebnisse sind korrekt und übersichtlich dokumentiert. | |
+| | 4. Verbesserungspotential wie auch Nacharbeiten wurden identifiziert und Umsetzungsvorschläge wurden erarbeitet. Falls weder Verbesserungspotential besteht noch Nacharbeit nötig ist, ist dies plausibel beschrieben. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+3. Bewertungskriterien A13 und A14
+
+*[G1: Dokumentation fachlicher und technischer Anforderungen]{.underline}*
+
+| Leitfrage | Wie wurden die fachlichen und technischen Anforderungen erfasst und dokumentiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Fachliche und technische Anforderungen sind vollständig und lösungsneutral dokumentiert. | |
+| | 2. Die Anforderungen sind hinsichtlich ihrer Relevanz für das Projekt und die Zielgruppe priorisiert. | |
+| | 3. Jede Anforderung ist klar definiert, mit Beispielen untermauert und leicht verständlich für alle Stakeholder. | |
+| | 4. Die Dokumentation enthält eine klare Abgrenzung der Anforderungen sowie die Begriffsdefinitionen, um Missverständnisse zu vermeiden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G8: Ausarbeitung des Realisierungskonzepts]{.underline}*
+
+| Leitfrage | Wie wird das Realisierungskonzept für die ausgewählte Umsetzungsvariante entwickelt? | ? |
+|-----------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das fachliche und technische Realisierungskonzept wurde schrittweise ausgearbeitet, inklusive Use Cases, Komponenten, Schichten, Abläufen, Schnittstellen, Klassen und Datenmodell. | |
+| | 2. Relevante Daten, Abläufe, Systeme und Schnittstellen wurden analysiert und die Ergebnisse präzise dokumentiert. | |
+| | 3. Zur Dokumentation und Darstellung des Konzepts wurden geeignete Werkzeuge und/oder Methoden (bspw. UML) verwendet. | |
+| | 4. Bei Bedarf wurden Anpassungen für bestehende Applikationen entworfen und in das Konzept integriert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+4. Bewertungskriterien A15 -- A22
+
+*[A14: Machbarkeitsstudie (Proof of concept)]{.underline}*
+
+| Leitfrage | Wie ist eine Machbarkeitsstudie durchzuführen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Umfang der Machbarkeitsstudie ist korrekt identifiziert und beschrieben. | |
+| | 2. Sinnvolle Erfolgskriterien wurden identifiziert und beschrieben. | |
+| | 3. Die Machbarkeitsstudie liefert brauchbare Rückschlüsse zur Anwendbarkeit der geplanten Lösung. | |
+| | 4. Die Machbarkeitsstudie liefert eine solide und dokumentierte Grundlage, um über die nächsten Schritte zu befinden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[B4: Identifikation relevanter Prozessinformationen]{.underline}*
+
+| Leitfrage | Was umfasst die Identifikation relevanter Prozessinformationen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Prozessinformationen wurden vollständig erfasst und umfassen mindestens die Bezeichnung des Prozesses, das auslösende Ereignis, das erwartete Ergebnis, den Auslöser des Prozesses und den Empfänger des Ergebnisses. | |
+| | 2. Die erfassten Prozessinformationen wurden klar und präzise dokumentiert, um eine eindeutige Zuordnung zu ermöglichen. | |
+| | 3. Es wurde sichergestellt, dass die erfassten Informationen den tatsächlichen Ablauf des Geschäftsprozesses vollständig abbilden und keine wesentlichen Details fehlen. | |
+| | 4. Die Identifikation erfolgte unter Berücksichtigung der spezifischen Anforderungen des Kunden und der branchenüblichen Standards für die Prozessdokumentation. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C2: Datenmodelle entwickeln]{.underline}*
+
+| Leitfrage | Wie wird ein Datenmodell entwickelt? | ? |
+|-----------|--------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Es wurde eine geeignete Datenmodellierungsmethodik (bspw. relational, objektorientierte, ER-Modellierung) gewählt, die Wahl wurde sinnvoll begründet. | |
+| | 2. In der Umsetzung des Datenmodells wurden die spezifischen Geschäftsanforderungen korrekt widerspiegelt. | |
+| | 3. Die Grundsätze der Normalisierung wurden sinnvoll angewandt. | |
+| | 4. Das Datenmodell ist flexibel und skalierbar. | |
+| | 5. Das Datenmodell ist ausreichend dokumentiert, damit andere Entwickler das Modell verstehen und damit arbeiten können. | |
+| | 6. Die Performanceanforderungen sind dokumentiert und es wurde ihnen entsprochen (bspw. via Indexierungen). | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C3: Datenmodell implementieren]{.underline}*
+
+| Leitfrage | Wie wird ein Datenmodell implementiert? | ? |
+|------------|--------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Es wurde ein geeignetes Datenbankmanagementsystem (bspw. MySQL) ausgewählt. Die Wahl wurde plausibel begründet. | |
+| | 2. Basierend auf dem Datenmodell wurden im Datenbankmanagementsystem Tabellen und Beziehungen angelegt. | |
+| | 3. Die Datenintegrität wurde durch den Einsatz von Integritätsregeln (Constraints) sowie Primär- und Fremdschlüsseln sichergestellt. | |
+| | 4. Es wurden Sicherheitsmassnahmen implementiert, um die Vertraulichkeit und Integrität der Daten zu gewährleisten. | |
+| | 5. Es wurden Massnahmen - wie bspw. Indexierung - zwecks Entsprechung der Performanceerwartung umgesetzt. | |
+| Gütestufe 2 | Drei oder vier Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C8: Planung und Implementierung eines Rollenkonzepts]{.underline}*
+
+| Leitfrage | Wie wird ein Rollenkonzept geplant und implementiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die entsprechenden Rollen wurden korrekt identifiziert und beschrieben. | |
+| | 2. Ein einsetzbares Berechtigungsmanagement wurde entwickelt, welches die Rollen mit entsprechenden Zugriffsrechten verknüpft. | |
+| | 3. Das Prinzip der geringsten Privilegien (Least Privilege) wurde korrekt angewandt. | |
+| | 4. Das Konzept wurde erfolgreich implementiert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G10: Konforme Implementierung und Versionierung]{.underline}*
+
+| Leitfrage | Wie werden Applikationen und Schnittstellen konform implementiert und versioniert? | ? |
+|------------|-------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Back-End und Front-End wurden gemäss den definierten Anforderungen und unter Einhaltung der Programmiersprachen, Entwicklungstools und Sicherheitsvorgaben implementiert. | |
+| | 2. Regelmässige Überprüfungen der Implementierung gegen die Anforderungen (funktional, nicht-funktional, Sicherheit) wurden durchgeführt, mit kontinuierlicher Anpassung und Optimierung. | |
+| | 3. Die Einhaltung von Coderichtlinien wurde überprüft, um Nachvollziehbarkeit und Verständlichkeit des Codes zu sichern. | |
+| | 4. Alle Änderungen und Erweiterungen wurden übersichtlich und zuverlässig in einem Softwareverwaltungssystem abgelegt, wobei firmeninterne Richtlinien beachtet wurden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G11: Testkonzepterstellung und Testfalldefinition]{.underline}*
+
+| Leitfrage | Wie wurden Testkonzepte und Testfälle für die Applikationen und/oder Schnittstellen entwickelt? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das Testumfeld wurde vollständig beschrieben, inklusive System, Akteure, Daten, Benutzer und Berechtigungen. | |
+| | 2. Eine Auswahl geeigneter Testarten (Unit Tests, Integrationstests, Sicherheitstests etc.) wurde getroffen und die benötigten Testmittel definiert. | |
+| | 3. Testfälle wurden klar in Bezug auf Anwendungsfälle und Anforderungen beschrieben, unter Berücksichtigung verschiedener Testperspektiven, und sind wiederholbar gestaltet (automatisiert oder manuell). | |
+| | 4. Erwartete Ergebnisse für jeden Testfall wurden definiert und sind nachvollziehbar dokumentiert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G12: Durchführung und Auswertung von Tests]{.underline}*
+
+| Leitfrage | Wie wird die Durchführung von Tests organisiert und deren Ergebnisse ausgewertet? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Eine geeignete Testumgebung wurde gemäss dem Testkonzept aufgebaut und alle automatisierbaren Testfälle wurden implementiert. | |
+| | 2. Testfälle wurden umfassend durchgeführt, wobei besonderes Augenmerk auf die Sorgfalt der Testdurchführung und die Nachvollziehbarkeit der Protokollierung gelegt wurde. | |
+| | 3. Ergebnisse der Testläufe wurden systematisch ausgewertet und dokumentiert; nicht erfolgreiche Testfälle wurden identifiziert und Korrekturmassnahmen eingeleitet. | |
+| | 4. Die Implementierung wurde gemäss dem Sicherheitskonzept überprüft, und bei Abweichungen wurden geeignete Korrekturmassnahmen getroffen. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+
+
+
+
+5. Dokumentation Pflichtkriterien BF
+
+*[Doc1: Gliederung]{.underline}*
+
+| Leitfrage | Wie ist die Dokumentation gegliedert? | 3 |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der IPA-Bericht gliedert sich in Teil 1 und 2 sowie allfällige Anhänge: Teil 1 umfasst die durch die Prüfungsorganisation zusätzlich geforderten Inhalte, während Teil 2 die Umsetzungsdokumentation beinhaltet. Etwaiger Quellcode oder weitere Ergänzungen wie Richtlinien sind Bestandteil des Anhangs. | |
+| | 2. Sinnvolle Erfolgskriterien wurden identifiziert und beschrieben. | |
+| | 3. Die strukturellen Eigenheiten der gewählten Projektmethode sind in Teil 2 umgesetzt. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt sind erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+*[Doc2: Gestaltung der Dokumentation]{.underline}*
+
+| Leitfrage | Wie ist die Dokumentation gestaltet? | 3 |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Es wird ein einheitlicher Formatsatz angewandt, der Konsistenz gewährleistet und dem Leser eine klare Orientierung bietet. | |
+| | 2. Es kommen ausgewogene Abstände zwischen Texten und Elementen zur Anwendung. | |
+| | 3. Die Gestaltung von Überschriften, Texten und Grafiken erleichtert den Lesefluss und behindert ihn nicht. | |
+| | 4. Die Überschriften enthalten relevante Informationen und erleichtern dem Leser die Orientierung. | |
+| | 5. Qualitative Seitenumbrüche stellen sicher, dass keine einzelnstehenden Zeilen am Ende oder am Anfang einer Seite auftreten. | |
+| Gütestufe 2 | Vier Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[Doc3: Formale Vollständigkeit des IPA-Berichts]{.underline}*
+
+
+
+
+
+
+
+
+
+
Leitfrage
+
Was sind die Anforderungen an die formale Vollständigkeit des IPA-Berichts?
+
3
+
+
+
+
+
Gütestufe 3
+
Der IPA-Bericht enthält…
+
1. auf allen Seiten (optional Titelblatt) eine Kopf- oder Fusszeile, eine korrekte Seitennummerierung, das aktuelle Druckdatum und den Kandidatennamen.
+
+
+
+
+
2. ein vollständiges Inhaltsverzeichnis.
+
+
+
+
+
3. ein alphabetisch sortiertes Glossar, das präzise Erläuterungen zu den verwendeten Fachbegriffen und Abkürzungen bietet. Die Bestandteile des Glossars sind auf externe Fachpersonen ausgerichtet. Es fehlen maximal drei relevante Komponenten.
Wie sind Rechtschreibung, Interpunktion und Grammatik zu beurteilen?
+
3
+
+
+
+
+
Gütestufe 3
+
1. Der Schreibstil ist flüssig, der Text ist durchweg klar und verständlich geschrieben.
+
2. Die Sätze sind vollständig und ausführlich formuliert.
+
3. Rechtschreibung, Interpunktion und Grammatik weisen keine oder nur vereinzelt kleine Schwächen auf.
+
+
+
+
Gütestufe 2
+
Die Gütestufe 3 wurde nicht vollständig erreicht. Bspw. aus folgenden Gründen: Der Schreibstil zeigt einige Schwächen, die Klarheit des Textes könnte verbessert werden. Einige Sätze sind nicht vollständig oder ausführlich genug. Rechtschreibung, Interpunktion und Grammatik weisen kleinere Schwächen auf, die die Lesbarkeit nicht beeinträchtigen.
+
+
+
+
Gütestufe 1
+
Die Gütestufe 3 wurde wesentlich verfehlt. Bspw. aus folgenden Gründen: Der Schreibstil ist wenig flüssig, der Text weist erhebliche Verständnisschwierigkeiten auf. Viele Sätze sind unvollständig oder knapp formuliert. Rechtschreibung, Interpunktion und Grammatik zeigen deutliche Schwächen, die die Lesbarkeit erheblich beeinträchtigen.
+
+
+
+
Gütestufe 0
+
Die Gütestufe 3 wurde nicht annähernd erreicht. Bspw. aus folgenden Gründen: Der Schreibstil ist mangelhaft, der Text ist schwer verständlich. Viele Sätze sind unvollständig oder undeutlich formuliert. Rechtschreibung, Interpunktion und Grammatik weisen erhebliche Mängel auf, die die Gesamtqualität stark beeinträchtigen.
+
+
+
+
+
+
+
+*[Doc5: Visuelle Anforderungen an Abbildungen]{.underline}*
+
+| Leitfrage | Welche visuellen Kriterien sind für Abbildungen (bspw. Grafiken, Bilder, Diagramme und Tabellen) zu erfüllen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Abbildungen sind gut lesbar, wobei ausreichender Kontrast und angemessene Grösse berücksichtigt wurden (als Referenz dient der Ausdruck auf Format A4). | |
+| | 2. Die Abbildungen sind klar und verständlich, um eine einfache Interpretation und Informationsaufnahme zu ermöglichen. | |
+| | 3. Die Abbildungen weisen aussagekräftige Beschriftungen/Legenden auf, um den Inhalt zu erklären und zu kontextualisieren. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt sind erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+*[Doc6: Kurzfassung des IPA-Berichts]{.underline}*
+
+| Leitfrage | Was sind die Anforderungen an eine Kurzfassung? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Kurzfassung ist Bestandteil von Teil 2 des IPA-Berichts. | |
+| | 2. Es werden die Kerninformationen wiedergegeben, weder mehr noch weniger. | |
+| | 3. Die Kurzfassung beschränkt sich auf eine A4-Seite und enthält keine Grafik. | |
+| | 4. Die Kurzfassung weist eine klare Struktur auf und beinhaltet 3 bis 4 Kapitel. | |
+| | 5. Die Ausrichtung auf die Zielgruppe ist gewährleistet. | |
+| | 6. Die Kurzfassung endet sinnvoll, bspw. mit einer Schlussfolgerung oder einer Empfehlung. | |
+| | 7. Die Kurzfassung ist objektiv und verzichtet auf die Schilderung persönlicher Erfahrungen. | |
+| Gütestufe 2 | Fünf oder sechs Punkte sind erfüllt. | |
+| Gütestufe 1 | Drei oder vier Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als drei Punkte sind erfüllt. | |
+
+
+
+*[Doc7: Führung des Arbeitsjournals]{.underline}*
+
+| Leitfrage | Was ist beim Führen des Arbeitsjournals zu beachten? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das Arbeitsjournal ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Die Darstellung ist übersichtlich, klar und verständlich. | |
+| | 3. Das Arbeitsjournal besteht aus individuellen Tagesberichten. | |
+| | 4. Alle Aktivitäten gemäss Zeitplan sowie Überzeiten und ungeplante Arbeiten sind erwähnt. | |
+| | 5. Erfolge und Misserfolge sind erwähnt. Misserfolge werden kritisch hinterfragt. | |
+| | 6. Sämtliche in Anspruch genommenen Unterstützungen, einschliesslich externer Hilfe und KI-Nutzung, sind umfassend aufgeführt und entsprechend begründet. | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[Doc8: Persönliches Fazit]{.underline}*
+
+
+
+
+
+
+
+
+
+
Leitfrage
+
Was ist beim Verfassen des persönlichen Fazits zu berücksichtigen?
+
?
+
+
+
+
+
Gütestufe 3
+
1. Das persönliche Fazit ist Bestandteil von Teil 1 des IPA-Berichts.
+
+
+
+
+
Das persönliche Fazit gewährt einen objektiven Einblick in folgende Komponenten:
+
2. Herausforderungen
+
+
+
+
+
3. Lernerfahrung
+
+
+
+
+
4. Entwicklungsperspektiven. Es wird aufgezeigt, was bei einem künftig ähnlichen Projekt besser oder anders gemacht wird.
+
+
+
+
+
5. Beurteilung des Erfolgs.
+
+
+
+
Gütestufe 2
+
Drei oder vier Punkte sind erfüllt.
+
+
+
+
Gütestufe 1
+
Zwei Punkte sind erfüllt.
+
+
+
+
Gütestufe 0
+
Weniger als zwei Punkte sind erfüllt.
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Kontrollieren.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Kontrollieren.md
new file mode 100644
index 0000000..3f4beea
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Kontrollieren.md
@@ -0,0 +1,17 @@
+# Kontrollieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-31 14:13:02 +0100
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|-------------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| **5** | **Kontrollieren** |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen.md
new file mode 100644
index 0000000..5b5ccd8
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen.md
@@ -0,0 +1,26 @@
+# Planen
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-31 15:32:08 +0100
+
+---
+
+13:17
+
+
+
+IPERKA
+
+| 1 | Informieren |
+|-------|---------------|
+| **2** | **Planen** |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Hardware.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Hardware.md
new file mode 100644
index 0000000..b28bef4
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Hardware.md
@@ -0,0 +1,176 @@
+# Hardware
+
+Created: 2025-11-14 17:52:25 +0100
+
+Modified: 2025-11-20 15:31:56 +0100
+
+---
+
+| Raspberry Pi | Microcomputer |
+|-------------------------|----------------------------------|
+| Timer / Datengenerierung | Zusätzliche Sensoren oder Input |
+| Lokale Speicherung (JSON/CSV) | Evtl. Datenvorverarbeiten (Messwerte filtern) |
+| Erste Validierung | Kommunikation mit dem Raspberry Pi |
+
+
+
+1. Jeder Microcomputer arbeitet für sich.
+
+ a. Erzeugt eigene Daten
+
+ b. Speichert und sendet es selbst
+
+
+
+2. Kommunikation passiert nur über definierte Übergabe
+
+Es gibt nur zwei Arten zur Kommunikation:
+
+- Datei --> Ordner(lokal)
+- Nachricht --> Netzwerk (HTTP, MQTT, UDP, ...
+
+
+
+3. Ein gerät spielt "Erzeuger" Rolle (z.B Pi)
+
+ a. Timer
+
+ b. Daten erzeugen
+
+ c. Speichern oder senden
+
+
+
+4. Ein gerät spielt "Beobachter/Validator" Rolle: (z.B ESP32 or Arduino)
+
+ a. Warten
+
+ b. Nimmt Daten an (Datei oder Nachricht)
+
+ c. Prüft sie
+
+ d. Meldet Fehler/Status
+
+
+
+
+
+Ablauf:
+
+Gerät A (Raspberry Pi) --> Erzeugt Daten --> übergibt --> Gerät B (Esp32 prüft) --> Resultat --> zurück an Raspberry PI
+
+
+
+# Kommunikation
+
+## Weg A: Seriell / UART (direkte Verbindung)
+
+- Via TX/RX (Transmit and Receive)
+
+
+
+| Pro: | sehr einfach, wenig Protokoll-Overhead, Echtzeitnah |
+|---------|--------------------------------------------------------------|
+| Contra: | Gerät muss nah beieinander liegen, Verbindungslänge begrenzt |
+
+
+
+{width="5.0in" height="2.8125in"}
+
+### Weg B : Netzwerk-Kommunikation (z.B über HTTP, MQTT)
+
+- Pi sendet Daten über Netzwerke an Microcomputer oder Server oder umgekehrt.
+
+| Pro: | Geräte können räumlich getrennt sein, Kommunikation klar definiert, einfach erweiterbar auf mehre Geräte. |
+|--------|---------------------------------------------------------------|
+| Conta: | Etwas komplexer aufsetzten (Netzwerk, Protokoll, Fehlerbehandlung). |
+
+
+
+
+
+{width="5.0in" height="3.8229166666666665in"}
+
+
+
+
+
+
+
+
+
+
+
+
+
+// Auf Pi
+
+TIMER => erzeugt Daten (JSON/CSV)
+
+lokaler Ordner => Datei speichern
+
+
+
+VALIDIERUNGSPROZESS {
+
+Ordner überwachen
+
+Datei auslesen
+
+validieren()
+
+if Fehler {
+
+error.log
+
+console("Fehler erkannt")
+
+} else {
+
+log
+
+}
+
+}
+
+
+
+// Optional: Netzwerk
+
+API-Request senden an ValidatorServer {
+
+Datei im Body
+
+Header: Content-Type, Timestamp, Auth
+
+}
+
+
+
+ValidatorServer {
+
+empfangen(Request)
+
+validieren(Status)
+
+Response => Erfolg / Fehler
+
+Loggen
+
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Diagramme.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Diagramme.md
new file mode 100644
index 0000000..6eae101
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Diagramme.md
@@ -0,0 +1,43 @@
+# Prozess - Diagramme
+
+Created: 2025-10-17 14:02:54 +0200
+
+Modified: 2025-12-18 15:45:41 +0100
+
+---
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Versionen.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Versionen.md
new file mode 100644
index 0000000..bde7253
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Versionen.md
@@ -0,0 +1,221 @@
+# Prozess - Versionen
+
+Created: 2025-10-27 09:01:31 +0100
+
+Modified: 2025-11-14 14:13:39 +0100
+
+---
+
+Fragen:
+
+- Wie wiederverwendbar ist es?
+- Wie viel Sinn und Zweck hat es?
+- Wie viele verschiedene einzelne Prozesse hat das Projekt?
+- Entkoppelt?
+- Genug Traffic damit ein Lernende (Plattformentwickler) dran arbeiten kann?
+
+
+
+
+
+Hauptprozess Testlandschaft:
+
+- **Start → Sensor/API**: Reproduzierbare Daten werden automatisch geholt.
+- **Validierungsprozess**: Daten werden automatisch geprüft.
+- **Transmit**: Gültige Daten werden weitergeleitet.
+- **Logging**: Alle Daten (auch ungültige) werden protokolliert.
+- **Fehleranalyse/Review**: Ungültige Daten können überprüft werden, z. B. mit Diagrammen, um Debugging und Fehlererkennung zu üben.
+
+Alles läuft**automatisch**, Lernende greifen nur bei der**Fehleranalyse**ein.
+
+
+
+Version - 1:
+
+In diesem Fall werden Fake-Daten erzeugt. Für den ersten Projekt Aufbau wird eine API automatisch reproduzierbare Fake-Daten generieren.
+
+
+
+Schritt 1:
+
+
+
+
+
+
+
+
+
API
+
Erzeugt automatisch reproduzierbare Fake-Daten.
+
+
+
+
+
Datenformat
+
JSONoder CSV (leicht für Validierung und Loggen)
+
+
+
+
Daten-Art
+
+
Ganzzahlen /Int-Werte
+
Lineare Gleichungen (y = mx + b)
+
Zeitreihen (z.B. Sensormessung prosek.)
+
Fehlerhafte Daten (Ausreisser)
+
+
+
+
+
Ziel
+
+
Eine API erzeugt automatisiert reproduzierbare Testdaten.
+
Sie simuliert Sensorwerte oder externe API-Responses
+
inklusiv möglicher Fehlerfälle
+
stellt diese Daten über eine Endpunkt bereit, um den Validierungsprozess zu triggern.
+
+
+
+
+
+
+
+Schritt 2:
+
+
+
+
+
+
+
+
+
Validierungsprozess
+
Automatisiert
+
+
+
+
+
Ziel
+
Nimmt die vom API gelieferten Daten entgegen.
+
Prüft automatisch Gültigkeit und Konsistenz der Daten.
+
Kann Fehler oderUnstimmigkeit erkennen.
+
Gibt ein Validierungs-Status oder Fehlerliste aus (z.B. Falsches Format, Werte aussenhalb erlaubter Bereiche).
+
Gibt ein Validierungs-Status oder ein Fehlerliste aus, die später im Logging oder Review verwendet wird.
+
+
+
Technische – Ziele
+
Formatprüfung
+
Bereichsprüfung / Grenzen
+
Konsistenzprüfung
+
Ausreisererkennung
+
Logging
+
+
+
+
+
+
+Schritt3:
+
+
+
+
+
+
+
+
+
Transmit
+
+
+
+
+
+
Ziel
+
+
Nimmt die validierten Daten vom Validierungsprozess.
+
Sendet sie an den nächsten Prozess oder ein Zielsystem (z.B. Dashboards/Analyse,Datenbank)
+
Kann Übertragungsarten nutzen:
+
Übertragung von Fehlerdaten
+
+
+
+
Übertragungsarten
+
+
API-Call
+
Messaging-Queue (Sender und Empfänger)
+
Datei Export
+
+
+
+
+
+
+
+Schritt 4:
+
+
+
+
+
+
+
+
+
Logging
+
Log-Daten
+
+
+
+
+
Ablauf
+
1) Nimmt alle Daten vom Transmit-Schritt entgegen (gültig + ungültige).
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Projektmanagement/Realisieren.md b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Realisieren.md
new file mode 100644
index 0000000..cebac82
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Projektmanagement/Realisieren.md
@@ -0,0 +1,17 @@
+# Realisieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-31 14:13:02 +0100
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|-----------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| **4** | **Realisieren** |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Testlandschaft/Testlandschaft.md b/docs/IF_Projekte/Testlandschaft/Testlandschaft.md
new file mode 100644
index 0000000..39e924d
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Testlandschaft.md
@@ -0,0 +1,26 @@
+# Testlandschaft
+
+Created: 2025-10-17 09:28:03 +0200
+
+Modified: 2025-11-14 14:16:43 +0100
+
+---
+
+{width="5.5in" height="4.21875in"}
+
+
+
+Das "Testlandschaft" Projekt soll eine automatisierte Umgebung schaffen, die den Ablauf echter IoT-Datenverarbeitung bis zur Fehleranalyse realitätsnah nachzubilden.
+
+
+
+Dies dient als Lern- und Übungsplattform für Lernende in der Informatikausbildung. So können Lernende praxisnah verstehen, wie Datenflüsse, Validierung und Fehleranalyse in komplexen Systemen zusammenwirken.
+
+
+
+Zugleich verfolge ich mit dem Projekt das persönliche Ziel, ein tieferes Verständnis mit Zusammenarbeiten mit Hardware-Komponenten zu gewinnen und ein besseres Verständnis für ein gesamten Prozess von Datenerfassung bis zur Auswertung zu erhalten. Die Idee entstand, weil mir beim Debuggen oft auffällt, das ich nicht genau weiss, worauf ich achten muss bzw. wie ich Fehler erkenne und dies analysiere.
+
+
+
+
+
diff --git a/docs/IF_Projekte/Testlandschaft/Testlandschaft/Ausgangslage-&-Ziele.md b/docs/IF_Projekte/Testlandschaft/Testlandschaft/Ausgangslage-&-Ziele.md
new file mode 100644
index 0000000..f445068
--- /dev/null
+++ b/docs/IF_Projekte/Testlandschaft/Testlandschaft/Ausgangslage-&-Ziele.md
@@ -0,0 +1,107 @@
+# Ausgangslage & Ziele
+
+Created: 2024-08-27 16:47:23 +0200
+
+Modified: 2025-10-31 15:26:35 +0100
+
+---
+
+**Ausgangslage**
+
+
+
+Es gilt den Lernenden und somit den angehenden Berufsleuten das Thema "Testen" möglichst früh und praxisnah beizubringen.
+
+Dazu möchten wir eine Test-Landschaft realisieren, die über einen einfachen Funktionstest hinausgeht.
+
+
+
+Gerade wenn die Qualität eine Rolle spielt und ein Produkt verkauft werden soll, bekommt das Testen eine wichtige Bedeutung. Bei einer Gratis-SW werde ich wohl niemanden verklagen. Wenn ich aber für ein Produkt bezahle, dann werde ich mir dies je nach Preis und den damit verbundenen Auswirkungen schon eher überlegen. Je wichtiger die Anwendung, desto höher der Aufwand. An einen Fitness-Tracker habe ich nicht die gleichen Erwartungen wie an ein medizinisches Gerät im Spital. Vor allem Produkte oder Services die hohe Risiken bergen wie medizinische Produkte (Protonen-Therapie am PSI) oder Sicherheitssysteme (PSI-Grossforschungsanlagen), wie auch der ganze Forschungsaufwand (Grundlagen, Datenbasis, Beweisführung) stellen erhöhte Anforderungen. Dort kann ein Ausfall, eine Störung oder ein unzuverlässiges Funktionieren die Reputation zerstören oder langjährige Forschung zunichte machen und vielleicht die Weiterexistenz einer Firma, bzw. einer Institution gefährden.
+
+
+
+Die geplante Theorie vermittelt Begriffe wie:
+
+- Teststrategie
+
+{width="5.854166666666667in" height="3.5in"}
+
+
+
+
+
+- Test-Bedingungen
+
+{width="5.885416666666667in" height="1.6354166666666667in"}
+
+
+
+- Test-Daten / Ergebnisse
+
+{width="5.875in" height="2.5416666666666665in"}
+
+
+
+
+
+- Test-Protokoll
+
+{width="5.875in" height="3.3020833333333335in"}
+
+
+
+- Automatisierte reproduzierbare Tests
+
+{width="5.90625in" height="2.8645833333333335in"}
+
+
+
+- Wirtschaftliche Auswirkungen von schlechten oder fehlenden Tests
+
+{width="5.84375in" height="3.5208333333333335in"}
+
+
+
+Wir wollen eine reale Landschaft aufbauen, um die Theorie in die Praxis umsetzen zu können. Die Vor- und Nachteile einer durchdachten Teststrategie sollen zum Ausdruck kommen und spürbar sein. Diese Vor- und Nachteile können dann bei der Fehlersuche oder bei einer SW- oder HW-Anpassung live erlebt werden. Zuerst darf man ohne "Hilfsmittel" (Test-Daten, Test-Funktionen, Test-Dokumentation) Probleme beheben und danach mit Hilfe von integrierten Testystemen die bereits bei der Entwicklung berücksichtigt wurden.
+
+
+
+
+
+**Ziele**
+
+Es gibt verschiedene Ziele die wir in diesem Projekt verfolgen:
+
+
+
+- Test-Landschaft:
+ - Entwicklung eines funktionierenden Systems aus funktionaler Sicht
+ - Berücksichtigung der Theorie mit dem Ziel einen bestmöglichen Praxistransfer zu ermöglichen.
+ - Integration der Thematik Test bei der Entwicklung von Anfang an (Test-Driven-System)
+
+
+
+- Visitenkarte
+
+Das Projekt ist eine gute Gelegenheit, zu zeigen, dass SW auf verschiedenen Plattformen entwickelt werden kann und dass es somit ein Zusammenspiel von verschiedenen HW- und SW-Komponenten ist, welche miteinander kommunizieren. Es ist eine anspruchsvolle und vernetzte Aufgabe wo viele Handlungskompetenzen notwendig sind und auch zum Einsatz kommen.
+
+
+
+- Effizienzsteigerung
+
+Eigene Prozesse optimieren, Erfahrungen sammeln und ein Grundgerüst aufbauen, welches den ganzen Lifecycle betrachtet. Erst dann macht es Sinn für andere Dienstleistungen zu erbringen, die abgestimmt auf die vorhandenen Fähigkeiten und Möglichkeiten der Berufsbildung sind.
+
+
+
+- Lernziele
+ - Prozess SW-Engineering
+ - In Etappen planen. Vorarbeit - Test-IPA - Lerntransfer - Real-IPA - Nacharbeit
+ - Fullstack-Anwendung
+ - Komplexe und vernetzte Anwendung (CI/CO)
+ - Testing (Test-Patterns, -Strategien, -Daten, -Ergebnisse, -Automatisierung, ...)
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Auswerten.md b/docs/IF_Projekte/Traffic-Generator/Auswerten.md
new file mode 100644
index 0000000..1bf9ec4
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Auswerten.md
@@ -0,0 +1,9 @@
+# Auswerten
+
+Created: 2025-11-26 12:56:41 +0100
+
+Modified: 2025-11-26 12:57:07 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Dokumentation.md b/docs/IF_Projekte/Traffic-Generator/Dokumentation.md
new file mode 100644
index 0000000..ff7cc9f
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Dokumentation.md
@@ -0,0 +1,9 @@
+# Dokumentation
+
+Created: 2025-12-02 08:59:54 +0100
+
+Modified: 2025-12-16 07:57:46 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Entscheiden.md b/docs/IF_Projekte/Traffic-Generator/Entscheiden.md
new file mode 100644
index 0000000..e49f2c4
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Entscheiden.md
@@ -0,0 +1,9 @@
+# Entscheiden
+
+Created: 2025-11-26 12:56:16 +0100
+
+Modified: 2025-11-26 12:57:13 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Idee.md b/docs/IF_Projekte/Traffic-Generator/Idee.md
new file mode 100644
index 0000000..ed89c6d
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Idee.md
@@ -0,0 +1,48 @@
+# Idee
+
+Created: 2025-10-14 12:39:50 +0200
+
+Modified: 2025-12-09 07:55:08 +0100
+
+---
+
+Ich möchte gerne eine Anwendung haben, mit der ich den Traffic auf einem Netzwerk bewusst generieren kann, um Fehler finden zu können und um feststellen zu können, ab wann es zu Problemen kommt. Wann funktioniert ein reales Netzwerk einwandfrei und ab wann ist mit Übertragungsproblemen zu rechnen?
+
+Was ist die mittlere, die schnellste und die langsamste Übertragungszeit aus einer abgefeuerten Serie?
+
+Um diese Probleme in der Berufswahl aufzeigen zu können, müssten wir das Ganze reproduzieren können. Idealerweise können wir das Intervall laufend erhöhen und an der Empfangsstelle prüfen (loggen) was reinkommt.
+
+
+
+Anbei ein paar Fragestellungen für dein Projekt:
+
+1. Was ist der Unterschied zwischen TCP und UDP?
+
+- Wie lautet eine mögliche Teststrategie diese beiden Protokolle auszutesten und die Nachteile von UDP praktisch beweisen zu können?
+- Was wäre, wenn wir verschiedene Pakete mit einer fortlaufenden Nummer an einen Brocker senden und dort schauen was ankommt und in welcher Reihenfolge die Pakete eintreffen?
+
+2. Wie würdest du einen IP-Scanner realisieren und wie machen es andere?
+3. Wie findet man offene Ports? Wie sieht das Protokoll aus?
+4. Wie findet man die verfügbaren WLAN-Netze heraus und welche Eigenschaften kommt man «gratis» mitgeliefert?
+5. Welche Sicherheits-Levels gibt es bei MQTT und wie kann man die praktisch beweisen?
+6. Wie lange ist die durchschnittliche Antwortzeit einer Anfrage? Wer kommt zuerst Antwort, wenn 2 Teilnehmer gleichzeitig eine Anfrage stellen? Ist dies immer gleich oder zufällig?
+7. Was wenn 2 Dienste gleichzeitig eine Anforderung stellen? Der eine Dienst ist ein medizinischer Notfall und der andere Dienst liefert ein periodischer Temperaturmesswert. Wie kann ich eine Priorität vergeben und wie kann ich das Testen?
+
+
+
+Weitere Fragen:
+
+- In welcher Reihenfolge wollen wir vorgehen => Planung Baugruppe?
+- Was kannst du und was müsstest du selbst noch erlernen?
+- Welche HW könnten, bzw. wollen wir einsetzen?
+- Gibt es bereits bestehende SW-Tools, wo wir Traffic generieren könnten?
+- Was wenn wir es selbst programmieren würden => kleines Handheld-Device (Raspberry Pi, CYD)? Wie sieht eine mögliche Menüführung auf dem Display aus?
+
+
+
+Vielleicht ergeben sich auch ein paar Fragen an Green:
+
+- Was garantieren sie ihren Kunden?
+- Welche Tools setzen sie für das Monitoring ein?
+- Welche Probleme müssen sie in ihrem Alltag lösen?
+- ...
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren.md b/docs/IF_Projekte/Traffic-Generator/Informieren.md
new file mode 100644
index 0000000..0ab68a9
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren.md
@@ -0,0 +1,30 @@
+# Informieren
+
+Created: 2025-11-26 12:56:02 +0100
+
+Modified: 2025-12-09 09:59:04 +0100
+
+---
+
+| Informieren | |
+|-----------------------|-------------------------------------------------|
+| Welche Programmiersprache | Code: Python |
+| | GUI: HTML/CSS/JS |
+| | |
+| Risiken | Zeit, mögliches nicht funktionieren von Applikationen oder Programmen |
+| | Noch nicht weit genug bei den Kursen --> auf Hilfe von Noah (Aimo) angewiesen |
+| | |
+| Wie viele Tage | Sicher 8 Dienstage, noch unklar, ob 4 Tage mehr (2. Woche Sportferien) |
+| | |
+| | |
+| Welches Protokoll | TCP: Stabilität, Latenz und Antwortzeiten messen |
+| | UDP: Durchsatz, Paketverlust und Netzwerkgrenzen testen |
+| | |
+| Firewall | Grundlagen der Firewall verstehen |
+| | Wie die Firewall den Traffic beeinflusst |
+| | Aufbau einer Firewall |
+| | |
+| VSC / VS 2022 | Welche App ist besser, VSC / VS 2022 |
+| | |
+| | |
+| | |
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/1.0-Stakeholder.md b/docs/IF_Projekte/Traffic-Generator/Informieren/1.0-Stakeholder.md
new file mode 100644
index 0000000..a6a4584
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/1.0-Stakeholder.md
@@ -0,0 +1,63 @@
+# 1.0 Stakeholder
+
+Created: 2025-09-05 08:32:54 +0200
+
+Modified: 2025-11-26 12:55:32 +0100
+
+---
+
+Im Folgenden sind die Stakeholder aufgeführt
+
+
+
+
+
+
+
+
+
+
+
+
Stakeholder
+
Einflussbereich
+
Motivation
+
+
+
+
+
Schule & ÜK-Center
+
Ausbildungsmodule => kann ein Nutzen sein bezüglich Ausbildung und Zeit (Synergien), kann aber auch zu widersprüchlichen Ausbildungsinhalten führen
Definiert die Ausbildungsinhalte und Handlungskompetenzen für diesen Lehrberuf
+
+
+
Zielpublikum
+
+
Schüler, die in der Berufswahl stehen und den richtigen Lehrberuf und die richtige Lehrfirma suchen
+
Allgemein interessierte Personen, die ein Produkt unserer Informatik-Lernenden sehen wollen
+
+
Sie sind die eigentlichen Anwender des Safes
+
+
+
Entwicklungsteam
+
Informatikerlernende der Fachrichtung Applikationsentwicklung in verschiedenen Lehrjahren
+
Anspruchsvolle, ganzheitliche vernetzte Anwendung im Team realisieren. Visitenkarte der eigenen IPA
+
+
+
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/1.1-Stakeholder-(Diagramm).md b/docs/IF_Projekte/Traffic-Generator/Informieren/1.1-Stakeholder-(Diagramm).md
new file mode 100644
index 0000000..9fd3e25
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/1.1-Stakeholder-(Diagramm).md
@@ -0,0 +1,10 @@
+# 1.1 Stakeholder (Diagramm)
+
+Created: 2025-09-05 10:24:13 +0200
+
+Modified: 2025-11-26 12:55:32 +0100
+
+---
+
+-image1.png){width="28.125in" height="2.4270833333333335in"}
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen.md b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen.md
new file mode 100644
index 0000000..b745f33
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen.md
@@ -0,0 +1,29 @@
+# Anforderungen
+
+Created: 2025-11-26 13:46:17 +0100
+
+Modified: 2025-12-09 09:55:44 +0100
+
+---
+
+Funktionale Anforderungen
+
+1. Der Benutzer kann über eine Weboberfläche (Frontend) Traffic erzeugen und stoppen.
+2. Unterstützung von TCP‑ und UDP‑Traffic, um unterschiedliche Netzwerkzustände zu simulieren.
+3. Eingabe von Ziel‑Adresse, Port, Protokoll und Anzahl der Requests über die Website.
+4. Der Generator zeigt Status‑ und Rückmeldungen im Frontend an (z. B. erfolgreiche/verlorene Pakete, HTTP‑Statuscodes, Latenzzeit).
+5. Integration einer Firewall‑Komponente oder Simulation, um das Verhalten geblockter bzw. erlaubter Verbindungen zu prüfen.
+
+
+
+
+
+Nicht-funktionale Anforderungen
+
+Sicherheit: Keine Fremdsysteme ohne Erlaubnis ansprechen; Zugriff nur für autorisierte Nutzer.
+
+Benutzerfreundlichkeit: Einfache Bedienoberfläche (klarer Start/Stop‑Button).
+
+Stabilität: Der Generator darf nicht abstürzen, auch bei längerer Laufzeit oder hoher Frequenz.
+
+Nachvollziehbarkeit: Logging‑Funktion für Traffic und Ergebnisse (inkl. Zeitstempel).
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/Risikoanalyse.md b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/Risikoanalyse.md
new file mode 100644
index 0000000..2afab13
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/Risikoanalyse.md
@@ -0,0 +1,26 @@
+# Risikoanalyse
+
+Created: 2025-11-26 13:45:56 +0100
+
+Modified: 2025-12-09 09:55:55 +0100
+
+---
+
+Bei meinem Projekt, dem Traffic-Generator besteht ein grösseres Problem, die Zeit. Nebenbei gibt es noch ein paar kleinere Punkte:
+
+- Code‑Verlust: Wenn ich meinen Programmcode falsch speichere oder ausversehen lösche, kann wichtige Code verloren gehen.
+- Hardwareausfall: Der Raspberry Pi Pico W oder das CYD könnten kaputtgehen.
+- Fehler beim Flashen: Beim Compilen kann es passieren, dass Daten überschrieben werden.
+
+
+
+Wie umgehe ich das Risiko mit der Zeit?
+
+- Ich kann das Risiko nicht umgehen, weil ich die Kurse zuerst abschliessen muss
+
+
+
+Wie kann ich die restlichen, kleineren Risiken umgehen?
+
+- Regelmässige Backups (9500 Laufwerk)
+- Vorsichtiges Umgehen mit Hardware
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/SW-Architektur-Design.md b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/SW-Architektur-Design.md
new file mode 100644
index 0000000..89c54d8
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/Anforderungen/SW-Architektur-Design.md
@@ -0,0 +1,23 @@
+# SW Architektur Design
+
+Created: 2025-11-26 14:07:07 +0100
+
+Modified: 2025-12-09 09:56:04 +0100
+
+---
+
+Software‑Architektur / Design
+
+Die Software soll klar aufgebaut sein, damit man sie verstehen und erweitern kann. Ein möglicher Aufbau:
+
+
+
+1. **Python Programm**: Wird per Knopfdruck getriggert und löst Traffic aus.
+
+
+
+2. **Website**: Dort findet man die Knöpfe und die Anzeige, welche den Traffic visualisiert.
+
+
+
+3. **Host**: Raspberry Pi Pico W
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/Infos-Green-Datacenter-AG.md b/docs/IF_Projekte/Traffic-Generator/Informieren/Infos-Green-Datacenter-AG.md
new file mode 100644
index 0000000..f97b40e
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/Infos-Green-Datacenter-AG.md
@@ -0,0 +1,70 @@
+# Infos Green Datacenter AG
+
+Created: 2025-12-09 07:52:57 +0100
+
+Modified: 2025-12-09 08:19:31 +0100
+
+---
+
+Fragen an Green:
+
+- Was garantieren sie ihren Kunden?
+
+***Green CH:***
+
+*Wir garantieren unseren Privatkunden:*
+
+- *Einen stabilen und leistungsfähigen Internetanschluss*
+- *Den Betrieb und die Erreichbarkeit ihrer Webseiten*
+- *Die Verfügbarkeit ihrer E-Mail-Adressen*
+
+***Green Datacenter:***
+
+*Wir garantieren unseren Geschäftskunden eine definierte**Verfügbarkeit nach SLA (Service Level Agreement)**, zum Beispiel**99,9 % Uptime**.*
+
+*Das entspricht einer maximalen Ausfallzeit von**8,76 Stunden pro Jahr**.*
+
+*Diese Garantie bezieht sich auf die gesamte Hardware-Infrastruktur wie Server, Router, Switches und Firewalls, inklusive Stromversorgung, Kühlung und weiterer für den Betrieb notwendiger Komponenten.*
+
+*Ebenso garantieren wir eine hohe Verfügbarkeit nach SLA für Internetzugänge und VPN-Verbindungen unserer Grosskunden.*
+
+
+
+- Welche Tools setzen sie für das Monitoring ein?
+
+***Green CH:***
+
+*Das Monitoring erfolgt in erster Linie durch**Kundenrückmeldungen**, also durch direkte Problemmeldungen per Telefon oder E-Mail.*
+
+***Green Datacenter:***
+
+*Für das Monitoring und den Betrieb setzen wir verschiedene Tools ein:*
+
+- ***Interne IT:** Nimsoft*
+- ***Netzwerk:** Observium*
+- ***Datacenter-Überwachung:** Verschiedene interne und teils selbst entwickelte Programme (Details sind vertraulich)*
+
+
+
+- Welche Probleme müssen sie in ihrem Alltag lösen?
+
+***Green CH:***
+
+*Wir übernehmen den gesamten**Kundensupport** für Privat- und Geschäftskunden. Dazu gehören:*
+- *Lösen von Problemen mit Webseiten und E-Mail-Konfigurationen*
+- *Versand und Einrichtung von Routern*
+- *Beratung und Unterstützung bei technischen Anliegen*
+
+***Green Datacenter:***
+
+*Unsere täglichen Aufgaben umfassen:*
+
+- ***Planung, Bau und Verwaltung** von Rechenzentren*
+- ***Verkauf und Support** von Rechenzentrumsräumen und Racks*
+- *Sicherstellung von**Stromversorgung und Kühlung und weiter Notwendige Komponente***
+- ***Server-Support** im Datacenter*
+- *Aufbau und Unterhalt von**Netzwerken** sowie Bereitstellung von**Internet- und VPN-Zugängen** für Grosskunden*
+
+
+
+- ...
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/SMART.md b/docs/IF_Projekte/Traffic-Generator/Informieren/SMART.md
new file mode 100644
index 0000000..782c82b
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/SMART.md
@@ -0,0 +1,65 @@
+# SMART
+
+Created: 2025-11-26 12:59:06 +0100
+
+Modified: 2025-12-09 08:06:33 +0100
+
+---
+
+**Spezifisch**
+
+Ich programmiere ein System, welches per Buttons Traffic automatisch auslöst.
+
+Diese Buttons werden auf einer selber gemachten Website zu finden sein.
+
+Diese Website werden wir auf einem Raspberry Pi Pico W hosten.
+
+
+
+
+
+**Messbar**
+
+Das System soll per Knopfdruck Traffic "auslösen".
+
+Diesen Traffic wird dann auf einer Anzeige auf der Website visualisiert.
+
+
+
+
+
+
+
+**Attraktiv**
+
+Den Raspberry Pi Pico W ist bereits vorhanden.
+
+Für die Programme und die Website bin ich im Moment an Udemy Kursen.
+
+Bei diesen Kursen lerne ich mit Python programmieren und das Webdevelopmet.
+
+
+
+
+
+**Realistisch**
+
+Das Ganze zu entwickeln, ist mit den bestimmten Skills gut machbar.
+
+Das einzige Risiko was sein kann, ist die Zeit.
+
+Ich habe noch ca. 15 Tage Zeit und die beiden Kurse zusammen dauern ca. 120h.
+
+
+
+
+
+**Terminiert**
+
+Der Traffic-Generator soll bis **Ende Sportferien fertig** sein.
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Informieren/Tools.md b/docs/IF_Projekte/Traffic-Generator/Informieren/Tools.md
new file mode 100644
index 0000000..ef42781
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Informieren/Tools.md
@@ -0,0 +1,27 @@
+# Tools
+
+Created: 2025-11-26 13:43:34 +0100
+
+Modified: 2025-12-09 09:55:23 +0100
+
+---
+
+Hardware-Tools:
+
+Raspberry Pi Pico W
+
+Kabel
+
+
+
+Dokumentation:
+
+OneNote
+
+
+
+
+
+Entwicklungs-Tools:
+
+Visual Studio Code
diff --git a/docs/IF_Projekte/Traffic-Generator/Kontrollieren.md b/docs/IF_Projekte/Traffic-Generator/Kontrollieren.md
new file mode 100644
index 0000000..5c35f5c
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Kontrollieren.md
@@ -0,0 +1,9 @@
+# Kontrollieren
+
+Created: 2025-11-26 12:56:57 +0100
+
+Modified: 2025-11-26 12:57:10 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Planen.md b/docs/IF_Projekte/Traffic-Generator/Planen.md
new file mode 100644
index 0000000..bb512cf
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Planen.md
@@ -0,0 +1,35 @@
+# Planen
+
+Created: 2025-11-26 12:56:11 +0100
+
+Modified: 2025-12-09 09:59:34 +0100
+
+---
+
+| Planen | |
+|---------------|---------------------------------------------------------|
+| Was für Programme | Programme selber schreiben -->Udemy Kurs Python & Noah (Aimo) |
+| | |
+| Zeitplan | Siehe weiter unten |
+| | |
+| Ziele | Traffic-Generator beim Escape-Room oder bei den Schnupperlehren verwenden |
+| | UI selber als Website gestalten --> Udemy Kurs Webdevelopment |
+| | |
+| Kurse | An beiden Kursen weitermachen, dass man mit der Website oder dem Programm anfangen kann |
+| | |
+| Website | Die Website hostet man über einen Raspberry Pi Pico W |
+| | |
+| Eigenes GUI | Man hat eine Website, wo es Knöpfe und eine Anzeige, mit dem Traffic gibt |
+| | Mit den Knöpfen kann man den Traffic "auslösen" und er wird dann auf der Anzeige angezeigt |
+| | |
+| HK | Welche Handlungsziele werden beim Projekt Traffic-Gen abgedeckt? |
+| | a, a1, a2, a4, a7, c4, d, d4, e5, e6, f8 |
+| | |
+| Grafik | Di, 02.12.25 ein Bild machen, wie die Website aussehen soll |
+| | |
+| Rapberry Pi Pico W | Kleines Input Feld, wo man dann die IP adresse vom Gerät, welches den Traffic erhalten soll, eingeben kann. |
+
+
+
+{width="16.302083333333332in" height="8.28125in"}
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Planen/Kanban-Board.md b/docs/IF_Projekte/Traffic-Generator/Planen/Kanban-Board.md
new file mode 100644
index 0000000..a64f251
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Planen/Kanban-Board.md
@@ -0,0 +1,52 @@
+# Kanban-Board
+
+Created: 2025-09-05 08:14:03 +0200
+
+Modified: 2025-11-14 17:02:31 +0100
+
+---
+
+Wenn du deine anderen Lernaufträge erledigt hast oder sonst wie anstehst und nicht mehr weiterkommst, kannst du dir hier einen Job aussuchen. Wer mehr Jobs erledigt, zeigt dass er ein schnelles Arbeitstempo hat und der Arbeit grundsätzlich nicht aus dem Weg geht. Jeder Job gibt Credits und diese Credits kann man gegen was einlösen. Credits gibt es aber nur für richtig abgeschlossene Jobs. Wenn die Jobs keinen Link haben, so musst du kurz beim Berufsbildner nachfragen, damit er mit dir den Job besprechen kann. Dazu gehört auch die Qualitätserwartung.
+
+Wenn du links von einem Job auf den Pfeil klickst, kannst du die Zelle bewegen:
+
+1. Such dir einen Job aus und bewege ihn in die Spalte "In work". Ergänze dabei die Zelle mit deinen Initialen und einem geschätzten Zeitaufwand in Stunden [HB, 1.5h] (VornameNachname, z.B. HB für Harry Bo) damit alle wissen, wer diesen Job bearbeitet und wieviel Zeit dafür eingeplant ist.
+2. Hast du den Job erledigt, dann verschiebe ihn in die Spalte "Ready for Proof". Ergänze die Zelle mit deinem effektivem Aufwand in Stunden [HB, 1.5h/2h]. Du kannst nun einen neuen Job in Angriff nehmen. Es dürfen aber maximal nur 2 Jobs gleichzeitig von dir bearbeitet werden.
+3. Solange der Job in "Ready for Proof" ist, ist er noch nicht abgeschlossen. Das heisst konkret, dass irgendwer noch eine Qualitätskontrolle macht und bei Beanstandungen wieder zurück gibt.
+4. Ist der Job geprüft und für gut befunden worden, verschiebt der Auftraggeber ihn zu "Done"
+
+:
+
+| 🗃️ **Wird Morgen gemacht** |
+|:-------------------------------------------------:|
+| Lernziele definieren (persönlich & Anwender) |
+| Anforderungen definieren |
+| Test-Strategien definieren => was möchten wir mit dem Traffic-Generator genau testen können? Performance, Datenverlust |
+| Synergien mit Noah (Brutforce) klären |
+| Konzept User-Interface (Interaktive PowerPoint-Slides) |
+| Übersicht der verfügbaren WLAN-Netze |
+| Login für ausgewähltes WLAN-Netz |
+| Auswahl von Protokoll (UDP, TCP, MQTT, SMTP, Telegram, ...) |
+| Eingabe Message |
+| Einmaliges Ereignis auslösen => Einstellmöglichkeit für Protokoll, Eingabe Message, ... |
+| Intervall-Ereignisse starten/stoppen => Einstellmöglichkeit für Zeitabstand, Protokoll, fortlaufende Nummer (Start- & Stoppwert), ... |
+| Random-Ereignisse starten/stoppen => Einstellmöglichkeit für Protokoll, Lorem-Ipsum-Generator oder fortlaufende Nummer, ... |
+| Ziel-Destination ist Node-RED (MQTT-Brocker), wo die Events in einem File geloggt werden |
+
+| 🛠️ In work (In Bearbeitung) |
+|:---------------------------:|
+| |
+| |
+
+| 🔎 Ready for Proof (Frei zum Testen) |
+|:------------------------------------:|
+| |
+| |
+
+| ✅ Done (Erledigt) |
+|:------------------:|
+| |
+| |
+| |
+
+
diff --git a/docs/IF_Projekte/Traffic-Generator/Planen/Zeitplan.md b/docs/IF_Projekte/Traffic-Generator/Planen/Zeitplan.md
new file mode 100644
index 0000000..25d019e
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Planen/Zeitplan.md
@@ -0,0 +1,44 @@
+# Zeitplan
+
+Created: 2025-11-26 12:59:36 +0100
+
+Modified: 2025-12-16 08:27:20 +0100
+
+---
+
+| Zeitplan | | | | | |
+|--------------------|---------------------|--------------|-----|--------|-------|
+| **Datum** | **Ziel** | Meilenstein | Ja | in Arbeit | Nein |
+| 25.11.25 - 27.11.25 | Informieren & Planen abschliessen | Grundlagen klar | | | |
+| | wissen, wo ich nächste Woche anfangen muss | Planung | | | |
+| | | | | | |
+| 02.12.25 - 04.12.25 | Meilensteine rausfinden, klare Struktur haben | | | | |
+| | | | | | |
+| 09.12.25 - 11.12.25 | Erster kleiner Web-Server auf dem Raspi Pico testen | Web-Server hosten | | | |
+| | | | | | |
+| 16.12.25 - 18.12.25 | Mockup Wireframe machen, Wie wird der Traffic Generator aussehen | Räumliche Idee | | | |
+| | | | | | |
+| 06.01.26 - 08.01.26 | Aufarbeiten, wo ich stehen geblieben bin, Anfangen mit UI erstellen | UI Kenntnisse | | | |
+| | | | | | |
+| 13.01.26 - 15.01.26 | UI Abschliessen und mit Python Anfangen | UI / Python Kenntnisse | | | |
+| | | | | | |
+| 20.01..26 - 22.01.26 | Python abschliessen und feinschliff Doku | Python Kenntnisse | | | |
+| | | | | | |
+| 27.01.26 - 29.01.26 | Abschluss, Doku fertig,ca. 1 Tag reserve | | | | |
+| | | | | | |
+
+
+
+**Endtermin**
+
+Ende Semester 13. Februar 2026
+
+
+
+**Meilensteine**
+
+| Datum | Ergebnis |
+|-------|----------|
+| | |
+| | |
+| | |
diff --git a/docs/IF_Projekte/Traffic-Generator/Realisieren.md b/docs/IF_Projekte/Traffic-Generator/Realisieren.md
new file mode 100644
index 0000000..9362c32
--- /dev/null
+++ b/docs/IF_Projekte/Traffic-Generator/Realisieren.md
@@ -0,0 +1,9 @@
+# Realisieren
+
+Created: 2025-11-26 12:56:35 +0100
+
+Modified: 2025-11-26 12:57:11 +0100
+
+---
+
+
diff --git a/docs/IF_Projekte/Töggelikasten/Restplanung.md b/docs/IF_Projekte/Töggelikasten/Restplanung.md
new file mode 100644
index 0000000..dc725e7
--- /dev/null
+++ b/docs/IF_Projekte/Töggelikasten/Restplanung.md
@@ -0,0 +1,393 @@
+# Restplanung
+
+Created: 2025-05-23 08:52:28 +0200
+
+Modified: 2025-06-16 10:37:19 +0200
+
+---
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Name
+
Kurzbeschreibung
+
Priorität
+
Lead
+
Termin
+
Aufwand
+
Erledigt
+
Bemerkungen
+
+
+
+
+
Ballförder-System
+
Signale zur Steuerung im Backend implementieren
+
1
+
Aimo
+
+
+
+
+
+
+
Ballförder-System
+
Timings, eingestellt vom Frontend, abspeichern in einer txt Datei
+
1
+
Aimo
+
+
+
+
+
+
+
I2C Daten
+
Testdaten ausgeben auf Terminal
+
1
+
Aimo
+
+
+
+
+
+
+
I2C Daten
+
Testdaten mit Frontend verbinden
+
1
+
Aimo
+
+
+
+
+
+
+
Sound
+
Die Sounds im Backend abspielen
+
2
+
Aimo
+
+
+
+
+
+
+
Sound
+
Testen ob die Sounds hörbar sind und an den
+richtigen Momenten abgespielt wird
+
2
+
Aimo
+
+
+
+
+
+
+
Frontend
+
Bezeichnungen im Settings Menu anpassen
+
2
+
Aimo
+
+
+
+
+
+
+
Start-up
+
Wird alles gestartet beim Power-On? => Python starten, Bildschirm maximieren => Autostart
+
+
+
+
+
+
+
+
+
Shut-Down
+
Taster
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Raspberry Pi On/Off
+
Steckanschluss für On/Off-Taster, inklusive Test
+
+
Fredy
+
+
Mai
+
+
0.5
+
ja
+
2 x für aus- und 1x für einschalten
+
+
+
Beschaffung SD-Card
+
Mindestens 2 SD-Cards 32GB beschaffen
+
2
+
Fredy
+
+
+
+
Sind bestellt und unterwegs
+
+
+
Raspberry Pi Audio
+
Welche Möglichkeiten gibt es Audio-Dateien abzuspielen => Raspberry Pi als Audioplayer, über USB, externer Audioplayer der angesteuert wird (UART, GPIOs, …)
+
+
+
+
+
+
USB-A-Klinken3.5-Kabel bestellt 27. Mai
+
+
+
Connector-Panel Bestellung
+
Material für Panel bestellen => HDMI, USB, LAN, On/Off-Taster, 230V-Buchse
+
2
+
Fredy
+
+
+
+
Liefertermin 3. Juni
+
+
+
Connector-Panel produzieren
+
Panel realisieren mit HDMI, USB, LAN, On/Off-Taster, 230V-Buchse
+
2
+
Fredy
+
Mo 16. Juni
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Test "Entwicklung"
+
Test an einem Entwicklungsaufbau auf dem Schreibtisch => Simulationsumgebung
+
+
+
Do 12. Juni
+
+
+
+
+
+
Einbau Raspberry Pi
+
Wie und wo wird der Raspberry Pi mit seinem Steckernetzgerät eingebaut
+
+
Fredy
+
Mo 16: Juni
+
+
+
+
+
+
Verdrahtung BA
+
Ballauswurf
+
+
Fredy
+
Mo 16: Juni
+
+
+
+
+
+
Verdrahtung BE
+
Bedieneinheit
+
+
Fredy
+
Mo 16: Juni
+
+
+
+
+
+
Verdrahtung LS
+
Lichtschranke
+
+
Fredy
+
Mo 16: Juni
+
+
+
+
+
+
Beschaffung HDMI
+
Ein internes HDMI-Kabel, ca. 1m und ein externes Kabel 5m
+
+
Fredy
+
+
+
+
Bestellt 27. Mai
+
+
+
Verdrahtung Audio
+
Verstärker
+
+
Fredy
+
Mo 16: Juni
+
+
+
+
+
+
Connector-Panel einbauen
+
Loch in Töggelikasten
+
+
Fredy
+
Mo 16: Juni
+
2h
+
+
+
+
+
Test "Production"
+
Test am Töggelikasten
+
+
+
Mo 23. Juni
+
+
+
+
+
+
Meeting 17. Juni
+
Paul ist der Ansicht, dass man bei diesem Meeting den fertigen Töggelikasten bewundern und testen kann
+
+
+
Di 17. Juni
+
+
+
+
+
+
Image SD-Card
+
Ein Image vom Raspberry Pi als Backup erstellen
+
+
+
+
+
+
+
+
+
Backup SD-Cards
+
2 Reserve-SD-Cards erstellen und auch testen
+
+
+
+
+
+
+
+
+
Bedienungsanleitung
+
Wer ist in der Lage den Töggelikasten zu bedienen? Welche Abhängigkeiten gibt es? Wer dokumentiert dies?
+
+
+
+
+
+
+
+
+
Transport
+
+
+
+
Fr 27. Juni
+
+
+
+
+
+
Lehrberufe à la carte
+
+
+
+
So 29. Juni
+
+
+
+
+
+
+
+Abklärungen für die Sitzung vom Di 3. Juni:
+
+- Termin & Verantwortung Transport?
+- Test vor Ort (Freitag oder Sonntag)?
+- Verlängerungskabel 230V 5m
+
+
+
+
+
+Anmeldung Rpi
+
+| **User** | **Passwort** |
+|----------|--------------|
+| fredy | psiifadmin |
+| ax5 | psiifadmin |
+
+
+
+Materialbestellungen
+
+| Stückzahl | Artikel | Datum | Wer | Lager |
+|-----------|----------------------------|-------|-------|----------------------|
+| 1 | Kabel HDMI 5m | | | |
+| 3 | SD-Card 32GB | | | 1 Stück |
+| 1 | Raspberry Pi 5 4GB | | Fredy | Ja |
+| 1 | HDMI-Adapter Buchse/Buchse | | Fredy | Liefertermin 3. Juni |
+| 1 | USB-Adapter Buchse/Buchse | | Fredy | Liefertermin 3. Juni |
+| 1 | RJ45-Adapter Buchse/Buchse | | Fredy | Liefertermin 3. Juni |
+| 1 | Kabel Mini-DP/HDMI 1m | | Fredy | Ja |
+| 1 | Kabel USB-A/USB-A 1m | | Fredy | Ja |
+| 1 | Kabel LAN RJ45/R45 1m | | Fredy | Ja |
+| | | | | |
+| | | | | |
+| | | | | |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Berufsanforderungen-Informati.md b/docs/IF_Projekte/Webseite-Berufserkundung/Berufsanforderungen-Informati.md
new file mode 100644
index 0000000..14f9e5e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Berufsanforderungen-Informati.md
@@ -0,0 +1,35 @@
+# Berufsanforderungen Informatiker
+
+Created: 2025-12-05 07:56:55 +0100
+
+Modified: 2025-12-05 07:58:51 +0100
+
+---
+
+Für Informatiker werden vor allem ein**logisches und abstraktes Denkvermögen**, eine**systematische Arbeitsweise**,**Konzentrationsfähigkeit**,**Geduld und Ausdauer**sowie**Teamfähigkeit**benötigt. Auch gute Englischkenntnisse und die Fähigkeit, sich schnell in neue Themen einzuarbeiten, sind wichtige Anforderungen.
+
+Persönliche Fähigkeiten
+
+- **Logisch-abstraktes Denkvermögen:**Um komplexe Probleme zu durchdringen und zu lösen.
+- **Kreativität:**Bei der Suche nach Lösungsansätzen.
+- **Konzentrationsfähigkeit:**Für präzises und konzentriertes Arbeiten.
+- **Systematische Arbeitsweise:**Um Prozesse strukturiert anzugehen und nachzuvollziehen.
+- **Geduld und Ausdauer:**Um auch bei schwierigen Problemen hartnäckig zu bleiben.
+- **Teamfähigkeit:**Da die Arbeit oft in Teams erfolgt.
+- **Rasche Auffassungsgabe:**Um neue Technologien und Konzepte schnell zu verstehen.
+
+
+
+Fachliche und schulische Voraussetzungen
+
+- **Gute Englischkenntnisse:**Da Englisch oft die Sprache der Informatik ist.
+- **Gute schulische Leistungen:**Insbesondere in Mathematik, Deutsch und Englisch sind von Vorteil.
+- **Technisches Verständnis:**Eine Grundkenntnis der Materie ist hilfreich.
+- **Lernbereitschaft:**Die Bereitschaft zur kontinuierlichen Weiterbildung ist entscheidend, da sich die Technik ständig weiterentwickelt.
+
+
+
+Weitere Anforderungen
+
+- **Interesse an Mathematik und Informatik:**Dies ist die Basis für eine erfolgreiche Ausbildung oder ein Studium.
+- **Vorstellungsvermögen:**Um komplexe Abläufe im Kopf zu visualisieren.
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Gamification.md b/docs/IF_Projekte/Webseite-Berufserkundung/Gamification.md
new file mode 100644
index 0000000..786f053
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Gamification.md
@@ -0,0 +1,36 @@
+# Gamification
+
+Created: 2025-12-03 14:36:22 +0100
+
+Modified: 2025-12-03 14:40:20 +0100
+
+---
+
+**Motivation ist wichtiger als Effizienz**
+
+
+
+- Funktionsorientiertes Design
+
+
+
+{width="5.9375in" height="1.71875in"}
+
+
+
+
+
+- Menschenorientiertes Design
+
+
+
+{width="5.947916666666667in" height="2.5in"}
+
+
+
+
+
+{width="4.552083333333333in" height="1.3125in"}
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement.md
new file mode 100644
index 0000000..a1b98d8
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement.md
@@ -0,0 +1,9 @@
+# Projektmanagement
+
+Created: 2024-09-18 11:35:45 +0200
+
+Modified: 2024-09-18 11:36:06 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Auswerten.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Auswerten.md
new file mode 100644
index 0000000..bdd1671
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Auswerten.md
@@ -0,0 +1,17 @@
+# Auswerten
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:23:16 +0200
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|---------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| **6** | **Auswerten** |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden.md
new file mode 100644
index 0000000..c511efe
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden.md
@@ -0,0 +1,17 @@
+# Entscheiden
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:21:49 +0200
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|-----------------|
+| 2 | Planen |
+| **3** | **Entscheiden** |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden/Übersicht.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden/Übersicht.md
new file mode 100644
index 0000000..aa6603b
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Entscheiden/Übersicht.md
@@ -0,0 +1,35 @@
+# Übersicht
+
+Created: 2025-10-22 09:46:35 +0200
+
+Modified: 2025-10-22 09:49:45 +0200
+
+---
+
+
+
+
+
+
+
+
+
+
Datum
+
Bereich
+
Beschreibung
+
+
+
+
+
2025-10-22
+
Projekt
+
Titel für Dokumentationen "WebApp-Berufserkundung"
+
Dateiordner "WebApp_Berufserkundung"
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren.md
new file mode 100644
index 0000000..f5215e5
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren.md
@@ -0,0 +1,17 @@
+# Informieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:19:55 +0200
+
+---
+
+IPERKA
+
+| **1** | **Informieren** |
+|-------|-----------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Fragen.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Fragen.md
new file mode 100644
index 0000000..92cd45a
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Fragen.md
@@ -0,0 +1,59 @@
+# Fragen
+
+Created: 2025-10-21 12:36:12 +0200
+
+Modified: 2025-10-21 15:01:43 +0200
+
+---
+
+**(Leit-) Fragen:**
+
+
+
+- Strategie
+ - Was wäre das Worst-Case-Szenario? Was kann passieren, dass du am Schluss ohne brauchbares Ergebnis dastehst?
+ - Anhand welchen Kriterien wirst du bei der IPA bewertet? Welche Gewichtung haben die einzelnen Kriterien?
+ - Was sind die Tod-Sünden bei der IPA?
+ - Welche Strategie verfolge ich bei dieser Aufgabenstellung?
+ - Warum verfolge ich gerade diese Strategie? Was sind die Vor- und Nachteile?
+ - Was ist deine Backup-Strategie?
+
+
+
+- SW-Qualität
+ - Wie definiert sich SW-Qualität?
+ - Welche Qualitätskriterien werden in deinem Fall erwartet?
+ - Wie überprüfe ich die Erreichung der Qualitätskriterien? Wie kann man dies messen und was wäre ein akzeptabler Messbereich, bzw. ab wann erfüllt man dies nicht mehr?
+ - Wie behalte ich diese Nicht funktionalen Anforderungen im Auge?
+ - Was bedeutet das SOLID-Prinzip?
+
+
+
+- Modularisierung
+ - Welche zeitgemässen Strategien gibt es in der SW-Entwicklung?
+ - Was ist ein Monolith und was sind die Vor- und Nachteile?
+ - Wie visualisiere ich meine SW-Module, -Komponenten, -Klassen, -Methoden, ...?
+
+
+
+- Interfaces
+ - Was ist ein Interface?
+ - Was sind die Vor- & Nachteile von Interfaces?
+ - Wann und wo setze ich Interfaces ein?
+
+
+
+- Test
+ - Wie gewährleistest du, dass deine Tests von einer anderen Person ausgeführt werden kann? Kommen 10 Personen auch wirklich zum gleichen Testergebnis?
+ - Wie prüfst du eine valide Eingabe, bzw. ob all deine Prüfkriterien wirklich funktionieren?
+ - Auf welche unerwarteten Eingaben prüfst du deine SW?
+ - Wie könnte man Tests automatisieren? Wie gewährleistest du, dass nach Änderungen die ganze SW wieder getestet wird?
+
+
+
+- Dokumentation
+ - Welche Strategie verfolge ich beim Dokumentieren?
+ - Gibt es nur eine Word-Datei oder Arbeite ich z.B. mit einem Anhang?
+ - Wann arbeite ich mit anderen Tools und Formaten? Wann gebe ich mich mit Word nicht zufrieden?
+ - Was mache ich, wenn sich Sachen im Word nicht veranschaulichen lassen?
+ - Wie gewährleiste ich, dass Resultate aus anderen Tools sich auch später noch bearbeiten lassen und nicht komplett neu erstellt werden müssen?
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/IPA-Bewertungskriterien.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/IPA-Bewertungskriterien.md
new file mode 100644
index 0000000..50b24ca
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/IPA-Bewertungskriterien.md
@@ -0,0 +1,583 @@
+# IPA-Bewertungskriterien
+
+Created: 2025-10-21 14:54:53 +0200
+
+Modified: 2025-10-22 09:39:42 +0200
+
+---
+
+Kriterienauswahl [27.01.2025]
+
+
+
+
+
+{width="6.15625in" height="2.9479166666666665in"}
+
+
+
+
+
+{width="5.34375in" height="1.84375in"}
+
+
+
+1. Bewertungskriterien A1 -- A 11
+
+[*A1: Auftragsanalyse und Wahl einer Projektmethode *](https://2025.pkorg.ch/dashboard)
+
+| Leitfrage | Wie erfolgt die Auftragsanalyse? Welche Projektmethode kommt zum Einsatz? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Auftrag wurde ausreichend analysiert, um sicherzustellen, dass alle Anweisungen im weiteren Projektverlauf Berücksichtigung finden. | |
+| | 2. Eine zur Aufgabe passende Projektmethode wurde ausgewählt. | |
+| | 3. Die Wahl der Projektmethode ist nachvollziehbar und schriftlich begründet. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt ist erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+[*A2: Informations-Recherche*](https://2025.pkorg.ch/dashboard)
+
+| Leitfrage | Wie werden Informationen recherchiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Fehlende und für die IPA relevante Informationen wurden identifiziert und systematisch recherchiert. | |
+| | 2. Es wurde darauf verzichtet, allgemein bekannte Sachverhalte ausführlich wiederzugeben. | |
+| | 3. Alle verwendeten Informationen, einschliesslich solcher, die auf den Einsatz von künstlicher Intelligenz oder ähnlichen Technologien zurückzuführen sind, und die nicht auf eigener Leistung beruhen, sind entsprechend deklariert. | |
+| | 4. Die recherchierten Informationen sind verlässlich, aktuell und gültig. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+*[A3: Informations-Aufbereitung und -Verwendung]{.underline}*
+
+| Leitfrage | Wie werden Informationen effektiv aufbereitet und verwendet? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die verwendeten Informationen finden in einer klaren und übersichtlichen Dokumentation Niederschlag. | |
+| | 2. Es werden geeignete Visualisierungsmethoden wie Grafiken, Diagramme oder Tabellen eingesetzt. | |
+| | 3. Die bereitgestellten Informationen erlauben es einer Fachperson, ein umfassendes Verständnis der IPA (Dokumentation, Lösung) anzueignen. | |
+| | 4. Alle verwendeten Informationen stehen im Auftragskontext und finden im Projekt sinnvolle Anwendung. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A4: Zeitplan]{.underline}*
+
+| Leitfrage | Was sind die Anforderungen an den Zeitplan? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Zeitplan ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Der Zeitplan ist übersichtlich gestaltet. | |
+| | 3. Struktur und Elemente des Zeitplans orientieren sich nach der gewählten Projektmethode. | |
+| | 4. Es wurde eine Zeitachse definiert (Datum), die Zeitachse weist eine vernünftige Granularität auf (bspw. Stundenblöcke). | |
+| | 5. Die identifizierten Aktivitäten sind zweckmässig und folgen einer sinnvollen Logik. | |
+| | 6. Die IPA-Zeitvorgabe ist im Zeitplan korrekt berücksichtigt. | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+*[]{.underline}*
+
+*[A5: Überprüfung und Dokumentation der Fortschritte und Risiken]{.underline}*
+
+| Leitfrage | Wie erfolgt die Überprüfung und Dokumentation des Projektfortschritts und der Risiken? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Fortschritt wurde regelmässig überprüft, verständlich und korrekt dokumentiert. | |
+| | 2. Es gibt eine genaue Gegenüberstellung des geplanten und tatsächlichen Zeitplans (Soll-/Ist-Vergleich). | |
+| | 3. Es erfolgte eine periodische Risiko- und Problemüberprüfung. Bei einem allfälligen Eintreten eines Risikos oder Problems wurde professionell darauf reagiert. Es besteht hierzu ein schriftlicher Nachweis. | |
+| | 4. Nicht erreichte Ziele wie auch Korrekturmassnahmen und Nacharbeiten zur IPA sind beschrieben. Falls solche Aspekte nicht existieren, ist dies entsprechend begründet. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A6: Leistungsfähigkeit]{.underline}*
+
+| Leitfrage | Wie ist die Leistung einzustufen? | ? |
+|-------------|------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Ziele wurden effektiv verfolgt. | |
+| | 2. Die Produktivität entspricht der einer Fachperson. | |
+| | 3. Qualitätsansprüche wurden erfüllt. | |
+| | 4. Interaktionen mit anderen Personen erfolgten konstruktiv und effizient. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A7: Selbständiges Arbeiten]{.underline}*
+
+| Leitfrage | Wie selbständig wurde gearbeitet? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Ziele und Aufgaben wurden eigenständig verfolgt. | |
+| | 2. Eine ausgeprägte Fähigkeit zur Problemlösung wurde demonstriert; Hindernisse wurden eigenständig überwunden und/oder fremde Hilfe wurde angemessen in Anspruch genommen. | |
+| | 3. Die Fähigkeit zur Selbstmotivation wurde gezeigt, das Engagement war hoch. | |
+| | 4. Die Fähigkeit zur Selbstreflexion wurde gezeigt. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A8: Anwendung der Fachsprache]{.underline}*
+
+| Leitfrage | Wie ist die Anwendung der Fachsprache zu beurteilen? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Spezifische Begriffe und Terminologien wurden korrekt und konsistent verwendet. | |
+| | 2. Komplexe Fachthemen wurden präzise wiedergegeben oder erläutert. | |
+| | 3. Informationen wurden in einer logischen und strukturierten Weise wiedergegeben, um das Verständnis zu gewährleisten. | |
+| | 4. Es wurde eine Sprache gewählt, die dem Zielpublikum (externe Fachperson) angemessen ist. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A9: Anwendung der Fachkompetenz]{.underline}*
+
+| Leitfrage | Wie ist die Anwendung der Fachkompetenz zu beurteilen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das theoretische Wissen ist vorhanden und konnte in praktischen Situationen erfolgreich angewandt werden. Bei offensichtlichem Mangel an theoretischem Wissen wird dieser Punkt nicht gesprochen. | |
+| | 2. Informationen und Sachverhalte wurden kritisch analysiert, um fundierte Schlussfolgerungen zu ziehen. | |
+| | 3. Der Anspruch der Transferleistung ist erfüllt, da Fähigkeiten und Kenntnisse auf unerwartete oder neuartige Aufgabenstellungen angewandt wurden. | |
+| | 4. Methoden und Werkzeuge wurden passend zur gewählten Projektmethode ausgewählt und wirkungsvoll eingesetzt. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A10: Interaktion im Projektteam]{.underline}*
+
+| Leitfrage | Wie ist die Interaktion des Kandidaten mit den anderen Projektmitgliedern zu beurteilen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Standpunkte anderer Projektmitglieder wurden erkannt, eventuelle Unklarheiten wurden beseitigt. | |
+| | 2. Empfangende Informationen erhielten die nötige Aufmerksamkeit und wurden angemessen berücksichtigt. | |
+| | 3. Es wurde proaktiv kommuniziert und konstruktiv Rückmeldungen gegeben. | |
+| | 4. Es wurde effizient kommuniziert, bspw. unter Einsatz geeigneter Kommunikationstools | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[A11: Abbildung der Projektaufbauorganisation]{.underline}*
+
+| Leitfrage | Welche Informationen zur Projektaufbauorganisation sind verlangt? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Projektaufbauorganisation ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Die zur Projektmethode passenden Rollen wurden identifiziert. | |
+| | 3. Die Rollen wurden prägnant und verständlich beschrieben. | |
+| | 4. Die Abhängigkeit der Rollen zueinander wurde korrekt dargestellt oder beschrieben. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+2. Bewertungskriterien A12-1 oder A12-2
+
+*[A12-1: Abnahme der Lösung]{.underline}*
+
+| Leitfrage | Wie erfolgt die Abnahme der Lösung? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Relevante Testszenarien wie auch Testkomponenten (bspw. Funktionen, Daten, Dokumente, Performance, Schnittstellen etc.) sind inkl. der erwarteten Ergebnisse beschrieben. | |
+| | 2. Es wurde eine Beschreibung der Testinfrastruktur und des Umfelds bereitgestellt, sodass eine externe Fachperson die Tests mit gleichen Ergebnissen reproduzieren kann. | |
+| | 3. Die Tests wurden durchgeführt. Die Ergebnisse sind korrekt und übersichtlich dokumentiert. | |
+| | 4. Verbesserungspotential wie auch Nacharbeiten wurden identifiziert und Umsetzungsvorschläge wurden erarbeitet. Falls weder Verbesserungspotential besteht noch Nacharbeit nötig ist, ist dies plausibel beschrieben. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+3. Bewertungskriterien A13 und A14
+
+*[G1: Dokumentation fachlicher und technischer Anforderungen]{.underline}*
+
+| Leitfrage | Wie wurden die fachlichen und technischen Anforderungen erfasst und dokumentiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Fachliche und technische Anforderungen sind vollständig und lösungsneutral dokumentiert. | |
+| | 2. Die Anforderungen sind hinsichtlich ihrer Relevanz für das Projekt und die Zielgruppe priorisiert. | |
+| | 3. Jede Anforderung ist klar definiert, mit Beispielen untermauert und leicht verständlich für alle Stakeholder. | |
+| | 4. Die Dokumentation enthält eine klare Abgrenzung der Anforderungen sowie die Begriffsdefinitionen, um Missverständnisse zu vermeiden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G8: Ausarbeitung des Realisierungskonzepts]{.underline}*
+
+| Leitfrage | Wie wird das Realisierungskonzept für die ausgewählte Umsetzungsvariante entwickelt? | ? |
+|-----------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das fachliche und technische Realisierungskonzept wurde schrittweise ausgearbeitet, inklusive Use Cases, Komponenten, Schichten, Abläufen, Schnittstellen, Klassen und Datenmodell. | |
+| | 2. Relevante Daten, Abläufe, Systeme und Schnittstellen wurden analysiert und die Ergebnisse präzise dokumentiert. | |
+| | 3. Zur Dokumentation und Darstellung des Konzepts wurden geeignete Werkzeuge und/oder Methoden (bspw. UML) verwendet. | |
+| | 4. Bei Bedarf wurden Anpassungen für bestehende Applikationen entworfen und in das Konzept integriert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+4. Bewertungskriterien A15 -- A22
+
+*[A14: Machbarkeitsstudie (Proof of concept)]{.underline}*
+
+| Leitfrage | Wie ist eine Machbarkeitsstudie durchzuführen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der Umfang der Machbarkeitsstudie ist korrekt identifiziert und beschrieben. | |
+| | 2. Sinnvolle Erfolgskriterien wurden identifiziert und beschrieben. | |
+| | 3. Die Machbarkeitsstudie liefert brauchbare Rückschlüsse zur Anwendbarkeit der geplanten Lösung. | |
+| | 4. Die Machbarkeitsstudie liefert eine solide und dokumentierte Grundlage, um über die nächsten Schritte zu befinden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[B4: Identifikation relevanter Prozessinformationen]{.underline}*
+
+| Leitfrage | Was umfasst die Identifikation relevanter Prozessinformationen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Prozessinformationen wurden vollständig erfasst und umfassen mindestens die Bezeichnung des Prozesses, das auslösende Ereignis, das erwartete Ergebnis, den Auslöser des Prozesses und den Empfänger des Ergebnisses. | |
+| | 2. Die erfassten Prozessinformationen wurden klar und präzise dokumentiert, um eine eindeutige Zuordnung zu ermöglichen. | |
+| | 3. Es wurde sichergestellt, dass die erfassten Informationen den tatsächlichen Ablauf des Geschäftsprozesses vollständig abbilden und keine wesentlichen Details fehlen. | |
+| | 4. Die Identifikation erfolgte unter Berücksichtigung der spezifischen Anforderungen des Kunden und der branchenüblichen Standards für die Prozessdokumentation. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C2: Datenmodelle entwickeln]{.underline}*
+
+| Leitfrage | Wie wird ein Datenmodell entwickelt? | ? |
+|-----------|--------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Es wurde eine geeignete Datenmodellierungsmethodik (bspw. relational, objektorientierte, ER-Modellierung) gewählt, die Wahl wurde sinnvoll begründet. | |
+| | 2. In der Umsetzung des Datenmodells wurden die spezifischen Geschäftsanforderungen korrekt widerspiegelt. | |
+| | 3. Die Grundsätze der Normalisierung wurden sinnvoll angewandt. | |
+| | 4. Das Datenmodell ist flexibel und skalierbar. | |
+| | 5. Das Datenmodell ist ausreichend dokumentiert, damit andere Entwickler das Modell verstehen und damit arbeiten können. | |
+| | 6. Die Performanceanforderungen sind dokumentiert und es wurde ihnen entsprochen (bspw. via Indexierungen). | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C3: Datenmodell implementieren]{.underline}*
+
+| Leitfrage | Wie wird ein Datenmodell implementiert? | ? |
+|------------|--------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Es wurde ein geeignetes Datenbankmanagementsystem (bspw. MySQL) ausgewählt. Die Wahl wurde plausibel begründet. | |
+| | 2. Basierend auf dem Datenmodell wurden im Datenbankmanagementsystem Tabellen und Beziehungen angelegt. | |
+| | 3. Die Datenintegrität wurde durch den Einsatz von Integritätsregeln (Constraints) sowie Primär- und Fremdschlüsseln sichergestellt. | |
+| | 4. Es wurden Sicherheitsmassnahmen implementiert, um die Vertraulichkeit und Integrität der Daten zu gewährleisten. | |
+| | 5. Es wurden Massnahmen - wie bspw. Indexierung - zwecks Entsprechung der Performanceerwartung umgesetzt. | |
+| Gütestufe 2 | Drei oder vier Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[C8: Planung und Implementierung eines Rollenkonzepts]{.underline}*
+
+| Leitfrage | Wie wird ein Rollenkonzept geplant und implementiert? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die entsprechenden Rollen wurden korrekt identifiziert und beschrieben. | |
+| | 2. Ein einsetzbares Berechtigungsmanagement wurde entwickelt, welches die Rollen mit entsprechenden Zugriffsrechten verknüpft. | |
+| | 3. Das Prinzip der geringsten Privilegien (Least Privilege) wurde korrekt angewandt. | |
+| | 4. Das Konzept wurde erfolgreich implementiert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G10: Konforme Implementierung und Versionierung]{.underline}*
+
+| Leitfrage | Wie werden Applikationen und Schnittstellen konform implementiert und versioniert? | ? |
+|------------|-------------------------------------------------|:---:|
+| Gütestufe 3 | 1. Back-End und Front-End wurden gemäss den definierten Anforderungen und unter Einhaltung der Programmiersprachen, Entwicklungstools und Sicherheitsvorgaben implementiert. | |
+| | 2. Regelmässige Überprüfungen der Implementierung gegen die Anforderungen (funktional, nicht-funktional, Sicherheit) wurden durchgeführt, mit kontinuierlicher Anpassung und Optimierung. | |
+| | 3. Die Einhaltung von Coderichtlinien wurde überprüft, um Nachvollziehbarkeit und Verständlichkeit des Codes zu sichern. | |
+| | 4. Alle Änderungen und Erweiterungen wurden übersichtlich und zuverlässig in einem Softwareverwaltungssystem abgelegt, wobei firmeninterne Richtlinien beachtet wurden. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G11: Testkonzepterstellung und Testfalldefinition]{.underline}*
+
+| Leitfrage | Wie wurden Testkonzepte und Testfälle für die Applikationen und/oder Schnittstellen entwickelt? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das Testumfeld wurde vollständig beschrieben, inklusive System, Akteure, Daten, Benutzer und Berechtigungen. | |
+| | 2. Eine Auswahl geeigneter Testarten (Unit Tests, Integrationstests, Sicherheitstests etc.) wurde getroffen und die benötigten Testmittel definiert. | |
+| | 3. Testfälle wurden klar in Bezug auf Anwendungsfälle und Anforderungen beschrieben, unter Berücksichtigung verschiedener Testperspektiven, und sind wiederholbar gestaltet (automatisiert oder manuell). | |
+| | 4. Erwartete Ergebnisse für jeden Testfall wurden definiert und sind nachvollziehbar dokumentiert. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[G12: Durchführung und Auswertung von Tests]{.underline}*
+
+| Leitfrage | Wie wird die Durchführung von Tests organisiert und deren Ergebnisse ausgewertet? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Eine geeignete Testumgebung wurde gemäss dem Testkonzept aufgebaut und alle automatisierbaren Testfälle wurden implementiert. | |
+| | 2. Testfälle wurden umfassend durchgeführt, wobei besonderes Augenmerk auf die Sorgfalt der Testdurchführung und die Nachvollziehbarkeit der Protokollierung gelegt wurde. | |
+| | 3. Ergebnisse der Testläufe wurden systematisch ausgewertet und dokumentiert; nicht erfolgreiche Testfälle wurden identifiziert und Korrekturmassnahmen eingeleitet. | |
+| | 4. Die Implementierung wurde gemäss dem Sicherheitskonzept überprüft, und bei Abweichungen wurden geeignete Korrekturmassnahmen getroffen. | |
+| Gütestufe 2 | Drei Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+
+
+
+
+5. Dokumentation Pflichtkriterien BF
+
+*[Doc1: Gliederung]{.underline}*
+
+| Leitfrage | Wie ist die Dokumentation gegliedert? | 3 |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Der IPA-Bericht gliedert sich in Teil 1 und 2 sowie allfällige Anhänge: Teil 1 umfasst die durch die Prüfungsorganisation zusätzlich geforderten Inhalte, während Teil 2 die Umsetzungsdokumentation beinhaltet. Etwaiger Quellcode oder weitere Ergänzungen wie Richtlinien sind Bestandteil des Anhangs. | |
+| | 2. Sinnvolle Erfolgskriterien wurden identifiziert und beschrieben. | |
+| | 3. Die strukturellen Eigenheiten der gewählten Projektmethode sind in Teil 2 umgesetzt. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt sind erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+*[Doc2: Gestaltung der Dokumentation]{.underline}*
+
+| Leitfrage | Wie ist die Dokumentation gestaltet? | 3 |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Es wird ein einheitlicher Formatsatz angewandt, der Konsistenz gewährleistet und dem Leser eine klare Orientierung bietet. | |
+| | 2. Es kommen ausgewogene Abstände zwischen Texten und Elementen zur Anwendung. | |
+| | 3. Die Gestaltung von Überschriften, Texten und Grafiken erleichtert den Lesefluss und behindert ihn nicht. | |
+| | 4. Die Überschriften enthalten relevante Informationen und erleichtern dem Leser die Orientierung. | |
+| | 5. Qualitative Seitenumbrüche stellen sicher, dass keine einzelnstehenden Zeilen am Ende oder am Anfang einer Seite auftreten. | |
+| Gütestufe 2 | Vier Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[Doc3: Formale Vollständigkeit des IPA-Berichts]{.underline}*
+
+
+
+
+
+
+
+
+
+
Leitfrage
+
Was sind die Anforderungen an die formale Vollständigkeit des IPA-Berichts?
+
3
+
+
+
+
+
Gütestufe 3
+
Der IPA-Bericht enthält…
+
1. auf allen Seiten (optional Titelblatt) eine Kopf- oder Fusszeile, eine korrekte Seitennummerierung, das aktuelle Druckdatum und den Kandidatennamen.
+
+
+
+
+
2. ein vollständiges Inhaltsverzeichnis.
+
+
+
+
+
3. ein alphabetisch sortiertes Glossar, das präzise Erläuterungen zu den verwendeten Fachbegriffen und Abkürzungen bietet. Die Bestandteile des Glossars sind auf externe Fachpersonen ausgerichtet. Es fehlen maximal drei relevante Komponenten.
Wie sind Rechtschreibung, Interpunktion und Grammatik zu beurteilen?
+
3
+
+
+
+
+
Gütestufe 3
+
1. Der Schreibstil ist flüssig, der Text ist durchweg klar und verständlich geschrieben.
+
2. Die Sätze sind vollständig und ausführlich formuliert.
+
3. Rechtschreibung, Interpunktion und Grammatik weisen keine oder nur vereinzelt kleine Schwächen auf.
+
+
+
+
Gütestufe 2
+
Die Gütestufe 3 wurde nicht vollständig erreicht. Bspw. aus folgenden Gründen: Der Schreibstil zeigt einige Schwächen, die Klarheit des Textes könnte verbessert werden. Einige Sätze sind nicht vollständig oder ausführlich genug. Rechtschreibung, Interpunktion und Grammatik weisen kleinere Schwächen auf, die die Lesbarkeit nicht beeinträchtigen.
+
+
+
+
Gütestufe 1
+
Die Gütestufe 3 wurde wesentlich verfehlt. Bspw. aus folgenden Gründen: Der Schreibstil ist wenig flüssig, der Text weist erhebliche Verständnisschwierigkeiten auf. Viele Sätze sind unvollständig oder knapp formuliert. Rechtschreibung, Interpunktion und Grammatik zeigen deutliche Schwächen, die die Lesbarkeit erheblich beeinträchtigen.
+
+
+
+
Gütestufe 0
+
Die Gütestufe 3 wurde nicht annähernd erreicht. Bspw. aus folgenden Gründen: Der Schreibstil ist mangelhaft, der Text ist schwer verständlich. Viele Sätze sind unvollständig oder undeutlich formuliert. Rechtschreibung, Interpunktion und Grammatik weisen erhebliche Mängel auf, die die Gesamtqualität stark beeinträchtigen.
+
+
+
+
+
+
+
+*[Doc5: Visuelle Anforderungen an Abbildungen]{.underline}*
+
+| Leitfrage | Welche visuellen Kriterien sind für Abbildungen (bspw. Grafiken, Bilder, Diagramme und Tabellen) zu erfüllen? | ? |
+|------------|--------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Abbildungen sind gut lesbar, wobei ausreichender Kontrast und angemessene Grösse berücksichtigt wurden (als Referenz dient der Ausdruck auf Format A4). | |
+| | 2. Die Abbildungen sind klar und verständlich, um eine einfache Interpretation und Informationsaufnahme zu ermöglichen. | |
+| | 3. Die Abbildungen weisen aussagekräftige Beschriftungen/Legenden auf, um den Inhalt zu erklären und zu kontextualisieren. | |
+| Gütestufe 2 | Zwei Punkte sind erfüllt. | |
+| Gütestufe 1 | Ein Punkt sind erfüllt. | |
+| Gütestufe 0 | Kein Punkt ist erfüllt. | |
+
+
+
+*[Doc6: Kurzfassung des IPA-Berichts]{.underline}*
+
+| Leitfrage | Was sind die Anforderungen an eine Kurzfassung? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Die Kurzfassung ist Bestandteil von Teil 2 des IPA-Berichts. | |
+| | 2. Es werden die Kerninformationen wiedergegeben, weder mehr noch weniger. | |
+| | 3. Die Kurzfassung beschränkt sich auf eine A4-Seite und enthält keine Grafik. | |
+| | 4. Die Kurzfassung weist eine klare Struktur auf und beinhaltet 3 bis 4 Kapitel. | |
+| | 5. Die Ausrichtung auf die Zielgruppe ist gewährleistet. | |
+| | 6. Die Kurzfassung endet sinnvoll, bspw. mit einer Schlussfolgerung oder einer Empfehlung. | |
+| | 7. Die Kurzfassung ist objektiv und verzichtet auf die Schilderung persönlicher Erfahrungen. | |
+| Gütestufe 2 | Fünf oder sechs Punkte sind erfüllt. | |
+| Gütestufe 1 | Drei oder vier Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als drei Punkte sind erfüllt. | |
+
+
+
+*[Doc7: Führung des Arbeitsjournals]{.underline}*
+
+| Leitfrage | Was ist beim Führen des Arbeitsjournals zu beachten? | ? |
+|------------|-------------------------------------------------|:----:|
+| Gütestufe 3 | 1. Das Arbeitsjournal ist Bestandteil von Teil 1 des IPA-Berichts. | |
+| | 2. Die Darstellung ist übersichtlich, klar und verständlich. | |
+| | 3. Das Arbeitsjournal besteht aus individuellen Tagesberichten. | |
+| | 4. Alle Aktivitäten gemäss Zeitplan sowie Überzeiten und ungeplante Arbeiten sind erwähnt. | |
+| | 5. Erfolge und Misserfolge sind erwähnt. Misserfolge werden kritisch hinterfragt. | |
+| | 6. Sämtliche in Anspruch genommenen Unterstützungen, einschliesslich externer Hilfe und KI-Nutzung, sind umfassend aufgeführt und entsprechend begründet. | |
+| Gütestufe 2 | Vier oder fünf Punkte sind erfüllt. | |
+| Gütestufe 1 | Zwei oder drei Punkte sind erfüllt. | |
+| Gütestufe 0 | Weniger als zwei Punkte sind erfüllt. | |
+
+
+
+*[Doc8: Persönliches Fazit]{.underline}*
+
+
+
+
+
+
+
+
+
+
Leitfrage
+
Was ist beim Verfassen des persönlichen Fazits zu berücksichtigen?
+
?
+
+
+
+
+
Gütestufe 3
+
1. Das persönliche Fazit ist Bestandteil von Teil 1 des IPA-Berichts.
+
+
+
+
+
Das persönliche Fazit gewährt einen objektiven Einblick in folgende Komponenten:
+
2. Herausforderungen
+
+
+
+
+
3. Lernerfahrung
+
+
+
+
+
4. Entwicklungsperspektiven. Es wird aufgezeigt, was bei einem künftig ähnlichen Projekt besser oder anders gemacht wird.
+
+
+
+
+
5. Beurteilung des Erfolgs.
+
+
+
+
Gütestufe 2
+
Drei oder vier Punkte sind erfüllt.
+
+
+
+
Gütestufe 1
+
Zwei Punkte sind erfüllt.
+
+
+
+
Gütestufe 0
+
Weniger als zwei Punkte sind erfüllt.
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Nicht-funktionale-Anforderung.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Nicht-funktionale-Anforderung.md
new file mode 100644
index 0000000..851b28e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Nicht-funktionale-Anforderung.md
@@ -0,0 +1,249 @@
+# Nicht-funktionale Anforderungen
+
+Created: 2025-10-21 12:36:12 +0200
+
+Modified: 2025-11-12 08:48:11 +0100
+
+---
+
+**Nicht-funktionale Anforderungen**
+
+
+
+ISO / IEC25010 - Qualität von Software
+
+Jedes Kriterium wird mit einem Wert auf Wichtigkeit auf einer Skala 1 (unwichtig, vernachlässigbar) - 10 (sehr wichtig, unverzichtbar) taxiert
+
+
+
+
+
+
+
+
+
Verlässliche Software
+
+
4
+
Die Verlässlichkeit in Softwarebezieht sich auf die ständigeVerfügbarkeitund Fehlertoleranz. Das bedeutet, dass die Software auch bei unerwarteten Bedingungen oder Fehlern weiterhin funktionieren sollte. Eine gute Wiederherstellbarkeit nach Ausfällen ist ebenfalls entscheidend für die Zuverlässigkeit.
+
+
Verfügbarkeit
+
+
+
Wir haben nur bedingt Einfluss auf die Zuverlässigkeit unseres Dienstleisteranbieters. Dennoch sollen sich Gedanken und Vorschläge zu diesem Thema gemacht werden. Es könnte z.B. sein, dass der Betreiber die Applikation auf Standby setzt, weil nicht auf eine Anfrage reagiert wurde oder eine Regeländerung nicht akzeptiert wurde. Wann merken wir, dass die Webseite seit 2 Monaten inaktiv ist?
+
+
+
Fehlertoleranz
+
+
+
Die SW soll auf Fehler angepasst reagieren und darf nicht gänzlich den Arbeitsdienst verweigern
+
+
+
Wiederherstellbarkeit
+
+
+
Das Projekt muss mit Hilfe der Dokumentation neu aufgesetzt werden können
+
+
+
+
+
+
Effiziente Performance
+
+
3
+
+
Effizienz in der Softwareleistungbedeutet, dass die Software nicht nur schnell und reaktionsschnell ist, sondern auch Ressourcen wie Speicher und Prozessorleistung sparsam verwendet, um die Systemkapazitäten nicht unnötig zu belasten.
+
+
gutes Zeitverhalten
+
+
Auf eine Eingabe soll innerhalb einer Sekunde eine Aktion erfolgen
+
Die Applikation soll bei 30 Benutzer (eine Schulklasse) gleichzeitig immer noch die geforderte Reaktionszeit einhalten
+
+
Ressourcen effektiv nutzen
+
+
+
+
+
+
Kapazitäten schonen
+
+
+
Es sollen die AGB bezüglich der verwendeten Ressourcen gelesen werden und in der Dokumentation Einzug finden. Ab wann wird es kostenpflichtig? Was sind die Limiten in der kostenlosen Version?
+
+
+
+
Höchste Sicherheit
+
+
5
+
Dies umfasst denSchutz sensibler Daten, dieWahrung der Integrität der Softwaregegen unerlaubte Änderungen, sichere Administrationsmethoden und den Schutz von Benutzerkonten vor unbefugtem Zugriff,einschließlich starker Authentifizierungsverfahren.
+
+
Datenschutz
+
+
+
Wenn mit persönlichen Daten gearbeitet wird, muss das Einverständnis des Anwenders eingeholt werden und die Absicht dahinter transparent kommuniziert werden (z.B. Personifiziertes Zertifikat für Bewerbung)
+
+
+
Integrität
+
+
+
+
+
+
nicht manipulierbar
+
+
+
Es darf keine Manipulation möglich sein, die die Sicherheit oder den Ruf des PSI verletzt.
+
+
+
sichere Administration und geschützte Benutzer-Accounts
+
+
+
+
+
+
Authentizierbarkeit
+
+
+
+
+
+
+
Hohe Kompatibilität
+
+
4
+
Kompatible Softwarekann problemlos mit anderen Programmen und Systemen zusammenarbeiten, was die Interoperabilität zwischen verschiedenen Softwarelösungen und Plattformen ermöglicht. Dies ist besonders wichtig in heterogenen IT-Umgebungen.
+
+
optimale Co-Existenz zu weiterer Software
+
+
+
Entwicklung mit einer anderen IDE, GitHub statt Gitea, anderes Betriebssystem, …
+
+
+
Interoperabilität
+
+
+
Gute und dokumentierte Schnittstellen (Interfaces)
+
+
+
+
Perfekte Usability
+
+
8
+
Benutzerfreundliche Softwareist intuitiv verständlich, leicht zu erlernen und zu bedienen. Sie sollte auch Schutzmechanismen gegen Fehlbedienungen bieten und ein ästhetisch ansprechendes Benutzerinterface haben, das die Zugänglichkeit und das Nutzererlebnis verbessert.
+
+
optimale Erkennbarkeit
+
+
+
Möglichst alle jeweils benötigten Informationen sollen sichtbar sein und auf ein unnötiges "Scrollen" oder "Pagen" in diesem Zusammenhang soll verzichtet werden. Bei Eingaben soll klar sein was und wie etwas eingegeben werden muss.
+
+
+
leicht erlernbar und lernfähig
+
+
+
Bei neuen Räumen und beim Anwenden von neuen Skills soll eine Unterstützung vorgesehen werden. Eine kleine Demo oder ein "Minigame"
+
+
+
gute Bedienbarkeit
+
+
+
Intuitive Bedienung und wo nicht möglich Zugang zu Hilfestellungen. Es sollen allgemein übliche Standards verwendet werden und auf eigenwillige Benutzerführungen soll verzichtet werden
+
+
+
Schutz vor Fehlbedienung durch den Nutzer
+
+
Eingabefehler verhindern indem man Drop-Down-Menüs und Checkboxen anstelle von Texteingaben verwendet
+
Mit Pflichtfelder arbeiten und diese als solche kennzeichnen
+
Einzelne Eingaben direkt auf Validität prüfen und nicht Gesamtrechnung am Schluss präsentieren
+
+
Ästetisches User-Interface
+
+
+
Das Frontend soll ansprechend sein und zum Gebrauch einladen. Es ist unsere Visitenkarte nach aussen und repräsentiert unsere Liebe zum Detail (eigene Massstäbe) aber auch unsere Fähigkeiten.
+
+
+
leichter Zugang
+
+
Die Software muss barrierefrei sein
+
Es sollen die Sprachen D, F, I und E berücksichtigt werden
+
+
+
+
+
Einfache Wartung
+
+
9
+
Einegut wartbare Softwarezeichnet sich durch eine modulare Struktur aus, die einfache Updates und Anpassungen ermöglicht. Wiederverwendbare Komponenten und umfassende Testfunktionen tragen ebenfalls zur leichten Wartbarkeit und langfristigen Stabilität der Software bei.
+
+
modularer Aufbau
+
+
+
Durch einen modularen Aufbau und integrierten Testmöglichkeiten kann im Fehlerfall ein Problem schnell lokalisiert werden
+
+
+
wiederverwendbare Komponenten
+
+
+
Es ist sehr wichtig sich zu diesem Thema Gedanken zu machen. Es muss vermieden werden, dass Anpassungen an verschiedenen Stellen im Programm gemacht werden müssen. Wollen wir z.B einem Raum ein Fenster hinzufügen, dann möchte ich nicht alle existierenden Räume überarbeiten müssen.
+
+
+
Räume können in verschiedenen Stockwerken wiederverwendet werden
+
Objekte können in verschiedenen Räumen wiederverwendet werden
+
Interaktionen können bei verschiedenen Objekten zum Einsatz kommen
+
+
+
gute Analyse-Funktion
+
+
+
Es muss einfach sein die Software zu analysieren. Dazu braucht es sicher mehr als nur Code.
+
+
+
leicht modifizierbar
+
+
+
Die Software muss von deinem Nachfolger erweitert werden können:
+
+
+
Ein Stockwerk muss aus einem Grundgerüst bestehen, in dem verschiedene neue Räume hinzugefügt werden oder bestehende Räume bearbeitet werden können
+
Ein Raum muss aus einem Grundgerüst bestehen, in dem verschiedene neue Objekte hinzugefügt werden bearbeitet werden können
+
Ein Objekt muss aus einem Grundgerüst bestehen, in dem verschiedene neue Interaktionen (Aktion & Reaktion, bzw. Input & Ausgabe) hinzugefügt oder bearbeitet werden können
+
Es müssen neue Benutzerinteraktionen hinzugefügt oder bearbeitet werden können
+
+
+
umfangreiche Testoptionen
+
+
Es muss klar sein wie man die Funktionstüchtigkeit der SW testen kann. Ideal wären 100%
+
Es muss verhindert werden, dass ohne Tests ein Update oder eine Erweiterung "deployed" werden kann
+
+
+
+
+
Leichte Portierbarkeit
+
+
5
+
Software mit guter Portierbarkeitlässt sich problemlos auf verschiedene Plattformen und Systeme übertragen. Dies beinhaltet einfache Installations- und Austauschprozesse sowie die Fähigkeit, sich an unterschiedliche Umgebungen und Anforderungen anzupassen.
+
+
gute Adaptivität
+
+
+
x
+
+
+
leicht zu installieren
+
+
+
Das Projekt muss mit Hilfe der Dokumentation neu aufgesetzt werden können
+
+
+
einfach austauschbar
+
+
+
Der Server kann sich ändern (abgekündigt, kostenpflichtig, …)
+
+
+
+
?
+
+
?
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Schnupperlehrsuche-(Google).md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Schnupperlehrsuche-(Google).md
new file mode 100644
index 0000000..3d93a93
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Schnupperlehrsuche-(Google).md
@@ -0,0 +1,67 @@
+# Schnupperlehrsuche (Google)
+
+Created: 2025-11-17 09:17:54 +0100
+
+Modified: 2025-11-17 09:27:09 +0100
+
+---
+
+Wie komme ich zu einer Schnupperlehre als Informatiker*in EFZ am PSI => ich "google" es mal.
+
+
+
+
+
+-image1.png){width="5.3125in" height="2.7291666666666665in"}
+
+
+
+
+
+-image2.png){width="8.322916666666666in" height="5.427083333333333in"}
+
+-image3.png){width="8.322916666666666in" height="1.5in"}
+
+
+
+
+
+-image4.png){width="8.34375in" height="7.208333333333333in"}
+
+-image5.png){width="4.21875in" height="1.7395833333333333in"}
+
+
+
+
+
+-image6.png){width="5.71875in" height="5.489583333333333in"}
+
+
+
+
+
+-image7.png){width="7.3125in" height="2.1979166666666665in"}
+
+**Fazit**
+
+- Auf 50 Bewerbungen bekomme ich ca. 1 Telefon
+- 10% der E-Mails kommen über die Leitung Berufsbildung
+- 90% der E-Mail anfragen kommen direkt an mich
+- Bei 40% der E-Mail-Anfragen muss ich zurückfragen wegen Termin und vollständigen persönlichen Angaben
+- 5% der E-Mail-Anfragen sind für Mediamatiker und nicht für mich => weiterleiten
+- Habe ich keine Termine muss ich die Berber vertrösten => Interesse an Warteschlange und je nachdem auf Warteliste setzen und dann informieren wenn neue Termine aufgeschaltet sind.
+
+
+
+**Ziel**
+
+Eine Standard E-Mail-Antwort auf alle Anfragen => Link auf Berufswahlseite (RTFM) => geführt durch Berufserkundung und gezwungen zur vollständigen Schnupperlehrbewerbung.
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Storytelling--Fiona-.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Storytelling--Fiona-.md
new file mode 100644
index 0000000..f010192
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Storytelling--Fiona-.md
@@ -0,0 +1,117 @@
+# Storytelling "Fiona"
+
+Created: 2025-10-22 13:39:40 +0200
+
+Modified: 2025-11-12 08:36:43 +0100
+
+---
+
+Fiona ist 14 Jahre alt und besucht die Sekundarschule in Gipf-Oberfrick. In der Schule befasst sie sich aktuell mit der Berufswahl. Ein Thema das die Eltern zu Hause auch schon angesprochen haben. Sie hat nun einen konkreten Auftrag von ihrem Lehrer bekommen, sich für eine Schnupperlehre anzumelden, was einfacher gesagt als getan ist.
+
+Fiona hat im Internet recherchiert und viele beschreibende Texte und Fotos, sowie einige Videos zu den einzelnen Berufen gefunden. Sie hat auch schon verschiedene allgemeine Tests gemacht und versucht herauszufinden, was sie gerne macht, wo ihre Stärken liegen und mit welchen Berufen diese Vorlieben und Stärken übereinstimmen, um die Auswahl einzugrenzen. Die ganze Recherche fühlt sich aber irgendwie steril an. Es gibt kaum eine Möglichkeit durch berufsspezifische Aufgaben oder Aufträge herauszufinden, wie sich das anfühlt.
+
+
+
+Es ist das eine einen in Frage kommenden Beruf zu finden, es ist aber etwas anderes einen freien Schnupperlehrplatz in einem Lehrbetrieb im näheren Umfeld und in nächster Zeit zu finden.
+
+Sie hat jetzt bereits 5 Anfragen gemacht:
+
+- Dabei hat sie 2 Absagen bekommen
+- Einmal blieb ihre Anfrage unbeantwortet
+- Ein möglicher Termin kollidiert mit ihren eigenen Plänen, wo sie dem Betrieb wohl oder übel selbst absagen musste
+- Eine erste Zusage für eine Schnupperlehre hat sie mittlerweile bekommen, allerdings erst in 4 Monaten.
+
+
+
+Per Zufall ist sie bei der weiteren Recherche auf die Webseite "Berufserkundung" am PSI gestossen. Sie stand da vor dem virtuellen PSI-Berufsbildungsgebäude und gelangte, nachdem sie die Eingangstür betreten hatte an die Reception. Die nette Rezeptionistin erklärte ihr kurz die Möglichkeiten im Gebäude verschiedene Berufe zu erkunden. Auf jedem Stockwerk befindet sich einer der 17 Lehrberufe am PSI. Es gibt auf jedem Stockwerk verschiedene Räume und in jedem Raum gibt es verschiedene berufsspezifische Aufgaben zu lösen. Je mehr Aufgaben man lösen kann, desto mehr Punkte kann man ergattern. Die Räume sind ähnlich wie Escape-Rooms aufgebaut. Für diejenigen denen es gelingt genügend Punkte zu erreichen, öffnet sich eine Tür zum nächsten Raum.
+
+
+
+Fionas Interesse war geweckt und sie hat sich entschlossen mal so ein Stockwerk zu erkunden. Sie liess sich von der Rezeptionistin eine Badge ausstellen, die sie berechtigt den Lift zu benutzen und sich frei im Gebäude zu bewegen.
+
+{width="2.21875in" height="1.7395833333333333in"}
+
+Fiona ging zum Lift und drückte die Taste 3, für das dritte Stockwerk, bzw. für den Lehrberuf Informatikerin EFZ Fachrichtung Applikationsentwicklung. Da sie zum ersten Mal hier ist, führt der Weg nur über den Raum 1. Die anderen Räume sind ihr noch verschlossen, bis auf den Trainingsraum. Sie entschied sich mal einen Blick in den Trainingsraum zu werfen und trat ein. Dort wurden ihr die möglichen Interaktionen verständlich erklärt und sie konnte es auch gleich selbst austesten. Im Trainingsraum stehen verschiedene Objekte wie ein Fenster, ein Bücherregal, ein Tisch mit Schublade und Computer, Teppich am Boden, ein Bild an der Wand, einen Lichtschalter und eine Tischlampe
+
+Indem man mit der Maus über die verschiedenen Objekte «hoovert» erscheinen Hinweise wie man mit dem Objekt interagieren kann:
+
+
+
+| **Objekt** | **Hinweis** |
+|--------------|----------------------------------------------------------|
+| **Fenster** | Am Fenster kann man den Blickwinkel mit den Pfeiltasten verändern und gelangt zu neuen Informationen |
+| **Bücherregal** | Es lässt sich ein Buch rausziehen, aufschlagen und umblättern |
+| **Schublade** | Man kann die Schublade rausziehen |
+| **Computer** | Indem man mit der Maus auf die virtuelle Tastatur zeigt und selbst eine Taste an der eigenen Tastatur betätigt, wird der Computer aufgeweckt. Man hat dann die gleichen Möglichkeiten wie mit dem realen Computer. Man kann auf dem virtuellen Computer mit der Maus agieren und Eingaben per Tastatur machen. Der virtuelle Bildschirm hat einfach einen gut sichtbaren farbigen Rand und kann mit der ESC-Taste auch wieder verlassen werden. |
+| **Teppich** | Der Teppich kann an verschiedenen Stellen aufgehoben werden um einen Blick darunter zu ermöglichen |
+| **Bild** | Es gibt eine Lupe, mit der man Details im Bild selbst erkennen kann und es gibt die Möglichkeit das Bild zu entfernen, um die Rückseite zu betrachten |
+| **Lichtschalter** | Indem man auf den Lichtschalter an der Wand drückt, wird die Deckenlampe ein- und ausgeschaltet und leuchtet so den Raum besser aus, so dass zusätzliche Hinweise überhaupt sichtbar werden |
+| **Tischlampe** | Indem man den Schalter der Tischlampe betätigt, werden wieder Hinweise sichtbar |
+
+
+
+Das Repertoire von Objekten und Interaktionen wird laufend ausgebaut und kommt je nach Beruf (Stockwerk) und Raum (Level) in unterschiedlicher Weise zum Einsatz. Weitere Hinweise innerhalb eines Raumes ermöglichen weitere Interaktionen, wie z.B. in Form eines Shortcuts, Doppelklick, ... Man lernt dann innerhalb der Räume neue Skills und die jeweilige Handlungskompetenz wächst von Raum zu Raum und von Stockwerk zu Stockwerk.
+
+Nachdem Fiona genug geübt hat, verlässt sie den Trainingsraum und betritt den Raum 1. Es ist ein kleines Büro mit 2 Computerarbeitsplätzen. Sie findet auf den ersten Blick folgende Objekte im Raum: Fenster, Kaffeemaschine, eine Pinwand mit vielen Zettelchen, einen Lateralschrank, 2 Computer, 1 Tablett, ...
+
+Als sie die Tür zumacht, sieht sie die Spielanleitung für diesen Raum an der Tür. Der Auftrag lautet:
+
+*«Find das Passwort für das Tablett heraus, gib es ein und du wirst den letzten Hinweis finden, um die Türe zu öffnen»*
+
+
+
+1. Fiona geht zum Tablett und aktiviert es mit einem Touch. Sie kann dort entnehmen das das Passwort eine **fünfstellige Zahl** ist. Sie schlussfolgert scharfsinnig, wie sie ist, dass sie jetzt wohl die **5 Zahlen** finden muss **und** dann noch überlegen muss in welcher **Reihenfolge** sie diese eingeben muss.
+
+
+
+2. Sie geht zur Pinwand und sieht viele kleine Post-it-Zettelchen. Ihr stechen sofort die 6 pinkfarbenen Post-it auf denen gerade Mal ein einziger Buchstabe ist ins Auge. Die Buchstaben «I -- B -- E -- N -- E -- S». Mittels «Drag and Drop» arrangiert sie die Post-it neu und es dauert nicht lange bis die Buchstaben einen Sinn ergeben «**SIEBEN**».
+
+
+
+3. Sie dreht sich um und dort fällt ihr eine Notiz auf dem Tisch auf. Darauf steht von Hand geschrieben «Hex-Code = 32, ASCII-Code = ?». Auf dem Tisch liegt auch eine ausgedruckte Tabelle mit dem Titel ASCII-Tabelle. In der Spalte Hex-Code mit dem Wertz 32 findet sie das ASCII-Zeichen für die **Zahl 2**
+
+
+
+4. Wo sie schon am Tisch ist und nach dem Besuch des Trainingsraumes weiss, dass man mit einem Computer interagieren kann, tippt sie auf die Tastatur und sieht auf dem Bildschirm ein Flussdiagramm. Das Flussdiagramm beginnt bei START und endet bei x = ? Sie geht den Ablauf des Flussdiagramms durch. Am Anfang werden Variablen initialisiert und dann je nach Wert gelangt man zu unterschiedlichen Rechenoperationen, wo die Werte verändert werden. Sie findet so heraus, dass x am Ende **5** ist.
+
+
+
+5. Nachdem, dass sie bei der Kaffeemaschine nichts Auffälliges gefunden hat, geht sie zum anderen Computer und tippt wieder auf die Tastatur. Sie findet dort eine SW-Entwicklungsumgebung mit einem RUN-Button. Sie betätigt diesen Button, bekommt dann aber eine Fehlermeldung in Form einer Dialogbox mit einem Hinweis der Art des Fehlers. Sie analysiert den Programmcode und findet heraus, dass am Ende einer Zeile im Gegensatz zu allen anderen Zeilen kein Semikolon ';' steht. Dies deckt sich auch mit dem Fehlerhinweis in der Dialogbox. Als sie erneut den RUN-Button betätigt, erscheint eine andere Dialogbox mit der **Zahl 9**.
+
+
+
+6. Sie schaut sich weiter im Raum herum geht zum Lateralschrank hin und dort fällt ihr das folgende Buch auf, welches ihr vielleicht weiterhelfen könnte.
+
+{width="1.4583333333333333in" height="2.1041666666666665in"}
+
+Als sie darin blättert, fällt ein Zettel heraus und dort steht. Sortieren sie die Zahlen der Grösse nach. Beginnen sie bei der kleinsten. Das scheint der Hinweis für die Reihenfolge bei der Eingabe des Passortes zu sein.
+
+7. Ihr fällt am linken Arbeitsplatz eine kleine Plastik-Ente auf. Sie hat schon mal gehört, dass Programmierer -- wenn sie nicht mehr weiterkommen -- ihr Problem der Rubber Duck erklären. Beim Erklären kommt man dann häufig selbst auf die Lösung. Sie geht zur Ente und schaut sich diese genauer an und findet auf der Unterseite die Zahl 3.
+
+
+
+8. Nun wo sie glaubt alle Zahlen zum Passwort zu haben begibt sie sich erneut zum Tablet und gibt die Zahlen 2 -- 3 -- 5 -- 7 -- 9 ein und stellt erfreut fest, dass sich die Türe zum Raum 2 öffnet und ihr Skills-Score-Level um 1 erhöht hat.
+
+
+
+Sie bemerkt, dass nun oben rechts eine «Map» erschienen ist. Sie sieht den Grundplan des Stockwerkes und die verschiedenen Räume. Raum 1n den sie gerade gemeistert hat ist in grün dargestellt, während die Räume 2 bis 10 noch in schwarz erscheinen. Auch wird ihre Badge eingeblendet. Dort wird als Balkenanzeige der Fortschritt beim Beruf IF-AE angezeigt (aktuell bei 2%).
+
+Es erscheint auch eine Dialogbox. Fiona hat die Möglichkeit auf einer Skala von 1 bis 10 ein Rating abzugeben für:
+
+- Wie schwierig war dieser Level für dich?
+
+1 (sehr einfach) 10 (sehr schwer)
+
+- Wie viel Spass haben dir die Aufgaben bereitet?
+
+1 (gar kein Spass) 10 (maximaler Spassfaktor)
+
+Oben rechts ist ein Fragezeichen eingeblendet. Beim Draufklicken erscheint der Hinweis, dass diese Angaben hilfreich bei der Berufswahl sind und später bei Bedarf nebst dem Score Rückschlüsse zu den verschiedenen Berufen zulässt.
+
+
+
+Unten sind noch die 2 Buttons «Exit» und «Neuer Raum» eingeblendet. Leider fehlt Fiona aktuell die Zeit, um weiterzumachen und sie betätigt den Button «Exit». Das Absolvieren des ersten Raums hat ihr aber sehr viel Spass gemacht und sie möchte auf jeden Fall mehr Räume, wie auch mehr Stockwerke erkunden. Daher entscheidet sie sich, sich anzumelden, damit sie sich erneut einloggen und weiterspielen kann. Mit ihrer E-Mail-Adresse und einem Passwort, kann sie sich später immer wieder problemlos einloggen und ihr Spielstand und alle Informationen bleiben gespeichert. Ohne Login, muss man einfach wieder von vorne beginnen.
+
+Wenn man sich mal eingeloggt hat, kann man sich ein Zertifikat generieren lassen. Dazu muss man dann allerdings seinen richtigen Namen zusätzlich eingeben und bekommt ein persönliches Zertifikat, welches man seiner Schnupperlehr-Bewerbung beilegen kann. Man hat dann auch zusätzlich die Möglichkeit sich statistische Auswertungen zu den einzelnen Scores anzeigen zu lassen. Über die Scores und Fortschrittskontrolle lässt sich indirekt auch eine Berufseignung machen. In welchem Beruf habe ich den grössten Score erreicht? Welcher Beruf hat mir am meisten Spass gemacht? Welche Aufgaben haben mich am wenigsten, bzw. am meisten gefordert?
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Was-gibt-es-schon-.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Was-gibt-es-schon-.md
new file mode 100644
index 0000000..803003c
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Informieren/Was-gibt-es-schon-.md
@@ -0,0 +1,15 @@
+# Was gibt es schon?
+
+Created: 2025-10-29 11:55:27 +0100
+
+Modified: 2025-10-29 11:59:13 +0100
+
+---
+
+| **Interaktive Story der digitalen Berufe für Schülerinnen und Schüler** |
+|------------------------------------------------------------------------|
+| Pizza, wie wär's? Damit so alltägliche Dinge wie Essenslieferungen überhaupt stattfinden können, sind Berufsleute aus allen digitalen Berufen gefragt. Unsere neue interaktive Story lädt Schülerinnen und Schüler in der Berufswahlphase auf spielerische Art ein, die ICT-Berufe zu entdecken. |
+
+
+
+[Pizza Slice: Gönn dir ein Stück der digitalen Zukunft | ICT-Berufsbildung](https://www.ict-berufsbildung.ch/index.html?id=264)
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Kontrollieren.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Kontrollieren.md
new file mode 100644
index 0000000..274ba0b
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Kontrollieren.md
@@ -0,0 +1,17 @@
+# Kontrollieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:22:54 +0200
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|-------------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| **5** | **Kontrollieren** |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen.md
new file mode 100644
index 0000000..46561c4
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen.md
@@ -0,0 +1,17 @@
+# Planen
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:21:22 +0200
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|---------------|
+| **2** | **Planen** |
+| 3 | Entscheiden |
+| 4 | Realisieren |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Ressourcenplanung.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Ressourcenplanung.md
new file mode 100644
index 0000000..e719247
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Ressourcenplanung.md
@@ -0,0 +1,100 @@
+# Ressourcenplanung
+
+Created: 2024-09-18 11:37:06 +0200
+
+Modified: 2025-11-26 12:23:50 +0100
+
+---
+
+**Ressourcen Manpower**
+
+| Name | Initialen | Beruf-Lehrjahr | Projekt-Arbeitstage | Bemerkungen |
+|-------------|---------|-------------|------------------|------------|
+| Aimo Altorfer | AA | IF-AE-4 | 4 - 5 Tage / Woche | |
+| Noah Pombas | NP | IF-AE-1 | ab Februar | |
+| Fredy Albisser | FA | IF-BB | Wenn sich Zeit ergibt | |
+
+
+
+**Coachs**
+
+
+
+
+
+
+
+
+
+
Name
+
Initialen
+
Bemerkungen
+
+
+
+
+
Jonas Bandi
+
JB
+
Extern, im Auftragsmandat,
+
Honorar 200.- / h => Budget 2026 ca. 15-20 h
+
Dozent & Freelancer
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Aufgabenbereiche & -verteilung**
+
+| System | |
+|------------------------------|-----------------------------------------|
+| Requirements | |
+| Architektur | |
+| Projekt-Management | OneNote |
+| Git (Versionierung & Backup) | Gitea |
+| Frontend | |
+| Backend | |
+| Database | |
+| Prototyping | |
+
+**Arbeitsordner:**
+
+[FS0195009502_RPRP_AAResultateBerufswahlWebApp_Berufserkundung](file://FS01/9500/9502/_RP/RP_AA/Resultate/Berufswahl/WebApp_Berufserkundung)
+
+
+
+**Ordnerstruktur:**
+
+| **Ordner** | **Unterordner** | **Bemerkung** |
+|--------------|---------------------------|-------------------------------|
+| 01_Informieren | | Alles im Zusammenhang mit der Informationsbeschaffung einigermassen sinnvoll in Ordner strukturiert |
+| 02_Planen | | Aktuelle Planung |
+| | 01_Arbeitsjournale | |
+| | 02_Ressourcenplanung | |
+| | _old | Alles was nicht gültig und/oder aktuell ist, aber zur Rekonstruktion / Vergangenheitsbewältigung noch benötigt wird |
+| 03_Entscheiden | | Alle getroffene Entscheidungen und Entscheidungsgrundlagen |
+| | 01_Anforderungen | |
+| | 02_Konzepte | |
+| | _old | Alles was nicht gültig und/oder aktuell ist, aber zur Rekonstruktion / Vergangenheitsbewältigung noch benötigt wird |
+| 04_Realisieren | | |
+| | 01_Prototyping | Verschiedene Testversuche in entsprechenden Unterordner mit einem ReadMe und/oder mit einem Link auf das jeweilige Repo |
+| | 02_Versions | Übersicht über den Entwicklungsprozess in Form von Unterordner und/oder Link-Liste auf die verschiedenen Repos |
+| | 03_Final | Abgabe für Experten / Nachfolger ohne Zugriff auf Gitea |
+| 05_Testen | | |
+| | 01_NichtFunktionaleAnforderungen | |
+| | 02_UnitTests | |
+| | 03_PerformanceTest | |
+| | 04_AutomationTest | |
+| 06_Auswerten | | Alles im Zusammenhang mit der Auswertung |
+| 10_Doku | | IPA-Doku |
+| | 00_Dateivorlagen | Alle aktuellen Dateivorlagen => Dienstleistung an die nächste Generation |
+| | 01_TIPA | |
+| | 02_IPA | |
+| | _old | Alles was nicht gültig und/oder aktuell ist, aber zur Rekonstruktion / Vergangenheitsbewältigung noch benötigt wird |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Roadmap.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Roadmap.md
new file mode 100644
index 0000000..fb2032e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Roadmap.md
@@ -0,0 +1,65 @@
+# Roadmap
+
+Created: 2025-10-21 14:42:26 +0200
+
+Modified: 2025-10-21 15:51:27 +0200
+
+---
+
+
Beispiel eines professionellen Games (Landschaft, Skills => Begriffe)
+
+
+
+
Ziele definieren
+
Vorarbeiten für die verbleibenden 4 Wochen
+
Test-IPA
+
+
+
+
Strukturen
+
Festlegen für Räume, Objekte und Interaktionen
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Vorgehensmethoden.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Vorgehensmethoden.md
new file mode 100644
index 0000000..2f4468f
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Planen/Vorgehensmethoden.md
@@ -0,0 +1,100 @@
+# Vorgehensmethoden
+
+Created: 2025-11-17 08:09:43 +0100
+
+Modified: 2025-11-17 08:36:01 +0100
+
+---
+
+An der IPA muss das Vorgehen zu Beginn der IPA bestimmt und begründet werden.
+
+
+
+Es gibt mehr als nur IPERKA. Selbst wenn man IPERKA wählt, was durchaus zulässig ist, so stellt sich für den Experten die Frage: "Wieso IPERKA? Was wäre die/eine Alternative gewesen? Welche Alternativen gibt es genau und was sind die Unterschiede, bzw. die jeweiligen Vor- und Nachteile?" Es wäre gut, wenn man sich also auch mal Gedanken gemacht hat, was es ausser IPERKA sonst noch gibt und man für den einen oder anderen Arbeitsschritt nicht weitere Methoden einsetzen könnte?
+
+
+
+**Planen und Priorisieren => MoSCoW-Methode**
+
+{width="5.416666666666667in" height="2.7083333333333335in"}
+
+
+
+**Planen => MVP**
+
+{width="4.1875in" height="2.375in"}
+
+
+
+**Entscheidung => Nutzwert-Analyse**
+
+
+
+{width="8.604166666666666in" height="2.59375in"}
+
+
+
+**Entscheidungen => Morphologischer Kasten**
+
+
+
+{width="8.666666666666666in" height="5.239583333333333in"}
+
+
+
+**Ganzheitliche Entwicklungsprozesse => DevOps => CI / CD**
+
+{width="7.0in" height="3.90625in"}
+
+
+
+{width="6.979166666666667in" height="2.4583333333333335in"}
+
+
+
+
+
+{width="7.0in" height="3.1770833333333335in"}
+
+
+
+{width="6.989583333333333in" height="2.90625in"}
+
+
+
+**Strukturierte Reihenfolge und Software-Engineering-Fragen:**
+
+1. **Problem & Ziel**
+ *Was soll gelöst oder erreicht werden -- und warum?*
+
+2. **Stakeholder & Nutzer**
+ *Wer interagiert mit dem System, welche Bedürfnisse haben sie?*
+
+3. **Kontext & Rahmenbedingungen**
+ *Budget, Zeit, Plattformen, Standards, bestehende Systeme?*
+
+4. **Funktionale Anforderungen**
+ *Welche Features muss die Software unbedingt haben? Was ist optional?*
+
+5. **Nicht-funktionale Anforderungen**
+ *Performance, Sicherheit, Usability, Skalierbarkeit, Zuverlässigkeit?*
+
+6. **Technische Architektur & Technologieauswahl**
+ *Welche Technologien passen zu den Anforderungen und deiner Expertise?*
+
+7. **Risiken & Machbarkeitsanalyse**
+ *Was könnte schiefgehen? Welche Risiken können wir früh testen?*
+
+8. **Roadmap & iterative Planung**
+ *Wie bauen wir das Projekt sinnvoll in Versionen und Meilensteinen?*
+
+9. **Qualitätssicherung**
+ *Wie testen wir? CI/CD? Wie stellen wir langfristige Wartbarkeit sicher?*
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Realisieren.md b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Realisieren.md
new file mode 100644
index 0000000..4e6628f
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Projektmanagement/Realisieren.md
@@ -0,0 +1,17 @@
+# Realisieren
+
+Created: 2025-10-21 13:17:33 +0200
+
+Modified: 2025-10-21 13:22:31 +0200
+
+---
+
+IPERKA
+
+| 1 | Informieren |
+|-------|-----------------|
+| 2 | Planen |
+| 3 | Entscheiden |
+| **4** | **Realisieren** |
+| 5 | Kontrollieren |
+| 6 | Auswerten |
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-.md b/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-.md
new file mode 100644
index 0000000..1d9fc1b
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-.md
@@ -0,0 +1,15 @@
+# Webseite "Berufserkundung"
+
+Created: 2024-08-27 16:28:11 +0200
+
+Modified: 2025-10-15 15:34:13 +0200
+
+---
+
+Dieses Projekt ist eine Weiterführung vom Projekt "Webseite Berufswahl"
+
+Daher soll ein neuer Projektmitarbeiter sich zuerst mit diesem Projekt auseinandersetzen. Es wird hier nicht nochmals alles dokumentiert.
+
+
+
+Dieses Projekt wird von Aimo realisiert und soll einen krönenden Abschluss mit seiner IPA finden (plus etwas Nachbearbeitung) => Termin Ende April 2026
diff --git a/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-/Ausgangslage-&-Ziele.md b/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-/Ausgangslage-&-Ziele.md
new file mode 100644
index 0000000..d0b8593
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufserkundung/Webseite--Berufserkundung-/Ausgangslage-&-Ziele.md
@@ -0,0 +1,109 @@
+# Ausgangslage & Ziele
+
+Created: 2024-08-27 16:47:23 +0200
+
+Modified: 2025-11-12 08:51:21 +0100
+
+---
+
+**Ausgangslage**
+
+Zur Berufsausbildung von Lernenden gehört es auch ein Berufswahl-Angebot zur Verfügung zu stellen, damit sich Schüler überhaupt für einen Beruf und einen Ausbildungsbetrieb entscheiden können. Für jeden Beruf in der Schweiz gibt es eine Bildungsverordnung und einen Bildungsplan welche die grundlegenden zu erwerbenden Handlungskompetenzen, die Rahmenbedingungen und das Qualifikationsverfahren regeln.
+
+Sich darunter aber einen konkreten Tagesablauf vorzustellen und wie sich das Arbeitsumfeld und die Arbeit selbst anfühlt ist allerdings schwierig, weshalb die Schüler darauf angewiesen sind an mehr spürbare Informationen zu kommen.
+
+Das aktuelle Berufswahl-Angebot sieht bei den ICT-Berufen folgendermassen aus:
+
+{width="9.75in" height="2.4791666666666665in"}
+
+
+
+Man kann sich vielleicht vorstellen, dass dieser ganze Berufswahlprozess einiges an Zeit und Ressourcen kostet. Anbei ein paar Fakten:
+
+- Der E-Mail-Verkehr im Zusammenhang mit den Anmeldungen für die Berufserkundungstage und die Schnupperlehren umfasst im Zeitraum von
+ - April 2023 bis September 2024 **663 E-Mail**s.
+ - Oktober 2024 bis Mai 2025 345 (Bewerber) + 101 (interne Organisation) = 446
+ - Juni 2025 bis Oktober 2025 192 (Bewerber) + 42 (interne Organisation) = 234
+
+
+
+- Bewerber (Stand 15.10.2025)
+
+| Lehrjahr | Anfragen | Berufserkundungstag | Schnupperlehre 1-tägig | Schnupperlehren 2-tägig | Events | Bemerkungen |
+|--------|--------|---------------|------------|-------------|-------|------------|
+| 2023 / 2024 | 100+ | 45 | - | 12 | 16 | |
+| 2024 / 2025 | 119 | 30 | 33 | 30 | 10 | BET + SL 6, Termin nicht wahrgenommen 12 |
+| 2025 / 2026 | 71 | 39 | 20 | - | 8 | Events aktuell geplant |
+
+
+
+- Nicht allen Bewerbern konnten wir ein passendes Angebot machen. Manchmal verloren die Schüler selbst das Interesse, manchmal passten die Termine nicht (mehr Glück bei anderen Ausbildungsbetrieben), es gab aber auch Fälle von kurzfristigen Absagen (Krankheit, Interessenverlagerung, Termin vergessen, ...). In einem Fall ist von den 3 angemeldeten Schüler*innen gar niemand am Tag x erschienen.
+
+
+
+- Der Organisatorische und administrative Aufwand muss für die Durchführung vor Ort ebenfalls berücksichtigt werden:
+ - Siehe Anmeldungen
+ - Termine festlegen unter Berücksichtigung der verfügbaren Räume und der Schultage von Lernenden
+ - Badge Organisieren
+ - IT-Ressourcen bereitstellen
+ - Inhalte ausarbeiten und ausdrucken
+ - Bestätigungen vorbereiten
+
+
+
+**Ziele**
+
+Es gibt verschiedene Ziele die wir in diesem Projekt verfolgen:
+
+
+
+- Berufswahlangebot reduzieren.
+ - Wir wollen den Berufserkundungstag bei den Informatikern eliminieren. Man kann nur einmal ans PSI zum Schnuppern des Informatikers kommen. Man kann also nur eine einzige Schnupperlehre machen. Entweder als IF-AE oder IF-PE.
+ - In Berufen wo wir auf den nächsten Bewerbungstermin keine Lehrstelle angeboten werden kann, erfolgt auch kein Schnupperlehrangebot. Der Antrag erfolgt jeweils im Juni für August im Folgejahr. Da für den Lehrberuf ICT-Fachfrau / -mann EFZ auch 2027 angeboten wird, entfällt auch das Schnupperlehrangebot für diesen Beruf.
+
+
+- In einem ersten Schritt soll der Berufserkundungstag durch ein Online-Angebot ersetzt werden
+ - Berufsbeschreibung /-präsentation (Video)
+ - Einblick in Arbeitsplatz (Fotos / Videos)
+ - Üblicher Tages-/Wochenablauf (Schule, ÜKs, Arbeitstage, Meetings
+ - Eignungstest als minimale Hürde um sich überhaupt für eine Schnupperlehre am PSI anmelden zu können. Dies kann z.B. eine Überprüfung in Form von Frage & Antwort bezüglich der Online-Berufserkundung sein. Man muss sich im Klaren sein, dass nicht alle Bewerber den Berufswahl-Prozess gleich ernst nehmen. Einige werden von den Lehrern und den Eltern dazu gezwungen, andere wissen, dass sie an die Kanti gehen.
+ - Erweiterungen in Form von Gamification. Viele Schüler*innen welche Informatiker werden wollen, gamen gerne
+
+
+
+- Später können weitere Erweiterungen implementiert werden, wie z.B.
+ - Einbinden von Chat-Bots => Frage und Antwort spezifisch auf das PSI-Umfeld
+ - Interaktionen mit den Lehrberufen, dem PSI und seinen Forschungsanlagen und den einzelnen Forschungsgebieten
+ - Virtualität (Lernende durch Avatare ersetzen => zeitlos)
+ - Das ganze Berufswahlverfahren mit all seinen Interaktionen landet in der Datenbank und steht später bei der Bewerbung zur Verfügung
+
+
+- Visitenkarte
+
+Die Web-Applikation ist eine ideale Plattform zu zeigen, wozu PSI-Applikationsentwickler in der Lage sind.
+
+
+
+- Effizienzsteigerung
+
+Eigene Prozesse optimieren, Erfahrungen sammeln und ein Grundgerüst aufbauen, welches den ganzen Lifecycle betrachtet. Erst dann macht es Sinn für andere Dienstleistungen zu erbringen, die abgestimmt auf die vorhandenen Fähigkeiten und Möglichkeiten der Berufsbildung sind.
+
+
+
+- Lernziele
+ - Prozess SW-Engineering
+ - In Etappen planen. Vorarbeit - Test-IPA - Lerntransfer - Real-IPA - Nacharbeit
+ - Fullstack-Anwendung
+ - Komplexe und vernetzte Anwendung (CI/CO)
+ - Modularer Aufbau
+ - in einem ersten Schritt die PSI-ICT-Berufe (ICT-Fachfrau/-mann EFZ, Informatiker3in EFZ mit Fachrichtung Applikationsentwicklung und Plattformentwicklung, eventuell auch Mediamatiker*in EFZ). Später folgen die anderen Berufe
+ - Eine neue Unterseite sollte einfach integriert werden können. Hat eine Unterseite ihren Zweck erfüllt, sollte sie möglichst ohne Altlasten entfernt werden können und darf sicher keine Abhängigkeiten zu anderen Unterseiten haben. Das Berufswahlangebot ist von Beruf zu Beruf unterschiedlich. Es gibt Lehrberuf die werden überrannt und es gibt Lehrberufe wo kaum Nachfrage besteht
+ - Wiederkehrende Informationen sollen im Header oder Footer untergebracht sein. Es soll vermieden werden, dass man mit "copy & paste" Informationen rumkopieren muss.
+ - Die Webseite(n) sollen aus einem Guss daherkommen und kein Flickwerk sein. Sie trägt die Handschrift des PSI und der PSI-Berufsbildung.
+ - Die Webseite soll übersichtlich gestaltet (nicht zu überladen) und einfach bedienbar sein. Die Webseite soll "responsive" sein. Sie soll auch den Kriterien der Barrierefreiheit genügen.
+ - Die Webseite soll mehrsprachig aufgebaut sein
+ - Damit fremdsprachige Mitarbeiter des PSI nicht ausgeschlossen sind, soll die Webseite auch in Englisch verfügbar sein.
+ - Wünschenswert wären auch noch Französisch und Italienisch, da es unsere Berufe in 3 Landessprachen gibt und unsere Dienstleistung auch ausserhalb des PSI und über die Sprachgrenzen hinweg Anklang finden könnte (Reichweite erhöhen und berücksichtigen, dass unsere Steuergelder aus der ganzen Schweiz kommen).
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/4.-UML.md b/docs/IF_Projekte/Webseite-Berufswahl/4.-UML.md
new file mode 100644
index 0000000..689dabc
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/4.-UML.md
@@ -0,0 +1,19 @@
+# 4. UML
+
+Created: 2024-10-09 08:03:34 +0200
+
+Modified: 2024-10-09 08:03:56 +0200
+
+---
+
+
+
+{width="10.3125in" height="7.375in"}
+
+
+
+{width="5.104166666666667in" height="7.541666666666667in"}
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Deploymend-&-Hosting.md b/docs/IF_Projekte/Webseite-Berufswahl/Deploymend-&-Hosting.md
new file mode 100644
index 0000000..5f25bdb
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Deploymend-&-Hosting.md
@@ -0,0 +1,44 @@
+# Deploymend & Hosting
+
+Created: 2024-09-18 08:19:58 +0200
+
+Modified: 2024-09-18 08:21:27 +0200
+
+---
+
+**Build, Deployment und Hosting**
+
+Der grundsätzliche Ablauf, um ausgehend vom Quelltext einer Webanwendung ein fertiges Produkt zu erstellen und für Nutzer über das Internet erreichbar zu machen, ist in der folgenden Abbildung zu sehen ...
+
+{width="4.333333333333333in" height="2.7291666666666665in"}
+
+
+
+... und besteht im Wesentlichen aus drei Schritten:
+
+- Build: Bauen der Webanwendung für den Produktiveinsatz
+
+Im ersten Schritt, dem sogenannten Build-Prozess (oder kurz Build), erstellt man auf Basis des Quelltextes eine »gebaute« Webanwendung. Hierzu zählt beispielsweise die Kompilierung des Quelltextes in Maschinencode (bei kompilierten Programmiersprachen), das Komprimieren bzw. Minifizieren von Quelltext (bei interpretierten
+
+Programmiersprachen wie beispielsweise JavaScript) und generell das Generieren von sonstigen Build-Artefakten wie zum Beispiel Programmpaketen. Der Build-Prozess kann dabei auf einem Entwicklungsrechner ausgeführt werden oder auf speziellen Build-Servern. Letzteres ist insbesondere für die Arbeit im Team oder bei aufwendigen Build-Prozessen ratsam. Häufig wird der Build-Prozess dabei auch automatisch von sogenannten CI-Servern angestoßen (CI für Continuous Integration), etwa bei Änderungen am Quelltext, die zentral über ein Versionskontrollsystem hochgeladen werden.
+
+
+
+- Deploy: Installieren der »gebauten« Webanwendung auf dem Hosting-Server
+
+Den Schritt, um die »gebaute« Webanwendung von dem Entwicklungsrechner (oder dem Build-Server) auf den Server zu übertragen, der die Webanwendung über das Internet bereitstellt, nennt man Deployment. Grundsätzlich gibt es hierfür verschiedene Möglichkeiten:
+
+- FTP (File Transfer Protocol)
+- SCP (Secure Copy)
+- Container Management
+
+
+
+
+
+- Host: Bereitstellen der »deployten« Webanwendung auf dem Hosting-Server
+
+Den Server, der eine Webanwendung für Nutzer bereitstellt, nennt man Hosting-Server oder kurz Host. Das Hosting ist dabei nicht wirklich ein »Schritt«, sondern eher ein »Zustand«. Man sagt auch: Der Hosting-Server "hostet" die Webanwendung. Den Hosting-Server bzw. den entsprechenden Webspace (also den Speicherplatz, den Sie für Ihre Webanwendung benötigen) mieten Sie über einen Hosting-Anbieter. Zusätzlich zum Webspace benötigen Sie noch eine Domain wie beispielsweise »webdevhandbuch.de«, damit Nutzer diese im Browser eingeben können (und eventuell noch ein SSL-Zertifikat, damit Sie die Webanwendung auch über HTTPS ausliefern
+
+können).
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Implementierung.md b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung.md
new file mode 100644
index 0000000..c3f1b9c
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung.md
@@ -0,0 +1,9 @@
+# Implementierung
+
+Created: 2024-09-18 11:34:02 +0200
+
+Modified: 2024-09-18 11:34:06 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/CSS.md b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/CSS.md
new file mode 100644
index 0000000..3bc836e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/CSS.md
@@ -0,0 +1,73 @@
+# CSS
+
+Created: 2024-08-27 16:34:49 +0200
+
+Modified: 2024-09-17 15:18:41 +0200
+
+---
+
+**Definieren, was alles im CSS definiert werden soll**
+
+
+
+- Farb-Palette
+- Schriftarten und -grössen
+- Tabellenstyling
+- ...
+
+
+- Namensgebung für class, id, ...
+
+
+
+
+
+**CSS vereinfachen mit CSS-Präprozessoren**
+
+Die Arbeit mit CSS kann relativ schnell sehr unübersichtlich werden und ist -- wenn man mal ehrlich ist -- nicht selten mit Schweißperlen der Verzweiflung verbunden. In den Werkzeugkasten von professionellen Webentwicklern gehören daher Tools, die die Arbeit mit CSS vereinfachen.
+
+
+
+**Die Funktionsweise von CSS-Präprozessoren**
+
+Grundsätzlich handelt es sich bei Präprozessoren (bzw. englisch Pre-Processors) um Programme, die Eingabedaten verarbeiten und ein bestimmtes Ausgabeformat erzeugen. Im Fall von CSS-Präprozessoren (bzw. englisch CSS Pre-Processors) handelt es sich konkret um Programme, die CSS-Präprozessorsprachen verarbeiten und daraus CSS-Code generieren (Abbildung 9.2). Die Generierung geschieht dabei in der Regel nicht zur Laufzeit, sondern während des Build-Prozesses, also in dem Moment, wo ein Webprojekt »gebaut« bzw. der endgültige Code generiert wird, der von der entsprechenden Webapplikation verwendet wird. Oder anders gesagt: Der generierte CSS-Code wird wie gewohnt in den entsprechenden HTML-Dateien eingebunden. Mit den Eingabedaten (sprich dem Format der jeweiligen CSS-Präprozessorsprache) sind die HTML-Dateien also nicht direkt verknüpft.
+
+{width="4.875in" height="3.3020833333333335in"}
+
+
+
+**Features von CSS-Präprozessoren**
+
+CSS-Präprozessorsprachen stellen Features zur Verfügung, über die die Sprache CSS selbst nicht verfügt (oder nicht immer verfügt hat): So lassen sich beispielsweise Variablen verwenden, eine Reihe von Funktionen, diverse Operatoren und andere Konstrukte wie Schleifen und Verzweigungen, die man so nur aus Programmiersprachen
+
+kennt (zur Erinnerung: CSS ist keine Programmiersprache!). Auch die Verschachtelung von CSS-Regeln ist in Präprozessorsprachen möglich, wodurch der Code im Allgemeinen sehr viel übersichtlicher und platzsparender wird. Zusammenfassend sind die wichtigsten Features, die CSS-Präprozessorsprachen zur
+
+Verfügung stellen, folgende:
+
+- Variablen: CSS-Präprozessorsprachen erlauben es, innerhalb des »CSS«-Codes Variablen zu verwenden. Auf diese Weise können Sie Werte, die Sie an verschiedenen Stellen innerhalb des CSS-Codes verwenden wollen, einmal zentral in einer Variablen definieren und statt des Wertes die Variable referenzieren. Ändert sich im Laufe eines Projekts der Wert (beispielsweise die Primärfarbe für ein Layout), müssen Sie diesen nur an einer Stelle, nämlich bei der Definition der Variablen, anpassen.
+- Operatoren: CSS-Präprozessorsprachen stellen verschiedene Operatoren zur Verfügung, beispielsweise Vergleichsoperatoren, mathematische Operatoren und konditionale Operatoren. Mithilfe dieser Operatoren können beispielsweise CSS-Werte dynamisch berechnet werden.
+- Verzweigungen: Ein weiteres Feature sind Verzweigungen (also if-else-Konstrukte), mithilfe derer Sie abhängig von bestimmten Bedingungen entweder den einen oder anderen CSS-Code generieren können.
+- Schleifen: Für wiederkehrende Aufgaben stellen CSS-Präprozessorsprachen Schleifen zur Verfügung, wie Sie sie aus Programmiersprachen kennen. Mithilfe dieser Schleifen ist es beispielsweise sehr einfach, ähnlich lautende CSS-Regeln oder CSS-Deklarationen zu generieren.
+- Funktionen: Funktionen -- das klassische Konstrukt für wiederverwendbaren Code -- ermöglichen es, den Code für die Generierung von CSS in wiederverwendbare Codebausteine zu strukturieren. CSS-Präprozessorsprachen stellen diesbezüglich zum einen von Haus aus eine Reihe von Funktionen bereit, die sich innerhalb des »CSS«-Codes verwenden lassen, und ermöglichen es zum anderen, eigene Funktionen zu definieren.
+- Verschachtelung: Ein Feature, welches man bei der Arbeit mit CSS besonders vermisst, ist die Verschachtelung von CSS-Regeln. Die Syntax und Semantik von CSS lädt durch die geschweiften Klammern und das Konzept der Vererbung von Selektoren mehr oder weniger schon dazu ein, CSS-Regeln schachteln zu können, ermöglicht es aber laut CSS-Standard leider nicht. CSS-Präprozessorsprachen dagegen rüsten diese Möglichkeit dankenswerterweise nach, was enorm zu der Übersichtlichkeit von CSS-Regeln beiträgt.
+- Vererbung: Ähnlich wie Sie es von der objektorientierten Programmierung her kennen, stellen CSS-Präprozessorsprachen das Konzept der Vererbung zur Verfügung. Hierüber ist es möglich, dass einzelne CSS-Regeln von anderen CSS-Regeln erben, was wiederum zu weniger redundantem und übersichtlicherem CSS-Code führt.
+
+
+
+**Sass, Less und Stylus**
+
+Grundsätzlich gibt es verschiedene CSS-Präprozessoren, wobei sich vor allem Sass (»Syntactically Awesome Style Sheets«, ), Less (»Leaner Style Sheets«, ) und Stylus () durchgesetzt haben. Alle drei dieser CSS-Präprozessoren sind sich bezüglich der Features sehr ähnlich,
+
+sodass die Entscheidung für oder gegen die Verwendung vor allem eine Geschmackssache ist oder davon abhängt, ob es bereits in einem bestehenden Projekt verwendet wird oder nicht.
+
+
+
+Hinweis
+
+Entwicklungsumgebungen wie Visual Studio Code (Abbildung 9.3) unterstützen übrigens Syntax-Highlighting für das Sass-Format meist schon standardmäßig von Haus aus oder lassen sich über entsprechende Plugins diesbezüglich erweitern.
+
+{width="2.9479166666666665in" height="2.5625in"}
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/HTML.md b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/HTML.md
new file mode 100644
index 0000000..81ba771
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Implementierung/HTML.md
@@ -0,0 +1,22 @@
+# HTML
+
+Created: 2024-08-27 16:38:28 +0200
+
+Modified: 2024-08-27 16:46:12 +0200
+
+---
+
+**Konventionen für HTML**
+
+
+
+Neue Mitarbeiter / Lernende sollen sich hier einen Überblick verschaffen können, um sich an Coding-Styles für HTML halten zu können. Es soll hier kein neuer und eigener Style definiert werden, sondern man orientiert sich an den gängigsten Praktiken und hält diese fest.
+
+
+
+- Wir arbeiten mit Visual Studio Code
+- Als Web-Services arbeiten wir mit [www.stackblitz.com](http://www.stackblitz.com)
+- Der jeweilige HTML-Editor soll auf ein Tab von 4 Spaces eingestellt werden
+- HTML-Dateien welche auf der Produktiven Ebene zum Einsatz kommen, sollen vor dem Hochladen von jeglichem Balast befreit werden. Zu Balast zählen Kommentare, Leerzeilen, Leerzeichen, ...
+
+Wir verwenden dazu das Tool / Plugin => ...?
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement.md b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement.md
new file mode 100644
index 0000000..a1b98d8
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement.md
@@ -0,0 +1,9 @@
+# Projektmanagement
+
+Created: 2024-09-18 11:35:45 +0200
+
+Modified: 2024-09-18 11:36:06 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Backlog--No-SW-Eng.md b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Backlog--No-SW-Eng.md
new file mode 100644
index 0000000..a2c6a80
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Backlog--No-SW-Eng.md
@@ -0,0 +1,24 @@
+# Backlog: No SW-Eng
+
+Created: 2024-09-11 08:16:12 +0200
+
+Modified: 2024-09-30 13:57:00 +0200
+
+---
+
+| 🗃️ **Backlog (To-Do-Liste)** |
+|:--------------------------------------------------------------------:|
+| GitLab-Einführung durch Basil Bruhn [Alle,2h] |
+| Abklärungen für einheitliche Visual Studio Code Installation / Konfiguration => schriftlich auch für Neuankömmlinge |
+| VisualStudio Code => GitHub Co-Pilot |
+| |
+
+| **🛠️ In work (In Bearbeitung)** |
+|:--------------------------------------------------------------------:|
+| Workshop für den Berufserkundungstag am 26. September vorbereiten und dann auch durchführen und auswerten |
+| |
+| |
+
+| **✅ Done (Erledigt)** |
+|:----------------------:|
+| |
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Fullstack-Entwickler.md b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Fullstack-Entwickler.md
new file mode 100644
index 0000000..47bb57f
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Fullstack-Entwickler.md
@@ -0,0 +1,120 @@
+# Fullstack-Entwickler
+
+Created: 2024-09-30 07:37:43 +0200
+
+Modified: 2024-09-30 07:42:32 +0200
+
+---
+
+- **Was versteht man unter Client und Server?**
+
+Webseiten und Webanwendungen bestehen aus dem**Frontend**, der auf der Clientseite ausgeführt wird, und dem**Backend**, der auf der Serverseite ausgeführt wird. Auf Serverseite sorgt ein**Webserver**dafür, dass die Webseite bereitgestellt wird. Auf Clientseite greift man über einen**Webclient**, auch*User Agent*genannt, auf die Webanwendung zu. In der Regel handelt es sich dabei um einen Webbrowser. Es gibt aber auch andere Arten von Clients, wie z. B. Screenreader, kommandozeilenbasierte bzw. programmgesteuerte HTTP-Clients oder Headless Browser, die keine grafische Oberfläche haben.
+
+{width="4.416666666666667in" height="1.4270833333333333in"}
+
+Das Prinzip von Client und Server
+
+Ruft man im Browser eine Webseite auf, folgt man dabei diesem Ablauf: Auf Clientseite gibt der Nutzer im Browser die Adresse ein, die URL (*Uniform Resource Locator*), und bestätigt mit entsprechender Taste bzw. entsprechendem Button im Browser das Laden der Webseite. Der Browser generiert daraufhin im Hintergrund eine Anfrage, die über das HTTP-Protokoll an den Server gesendet wird, auch*HTTP-Request*genannt. Auf Serverseite nimmt der Webserver die Anfrage entgegen und generiert eine passende Antwort, eine*HTTP-Response*, die er dann an den Client zurückschickt. Der Browser wiederum nimmt die Antwort entgegen und rendert, sprich visualisiert die Webseite. Benötigte Ressourcen wie beispielsweise Bilder lädt der Browser dabei automatisch nach, damit sie dargestellt werden können.
+
+- **Was sind Software-Stacks?**
+
+Bei einem Software-Stack, auch*Stack*oder*Solution-Stack*genannt, handelt es sich um eine**konkrete Auswahl bestimmter Komponenten**, die gemeinsam eine Plattform bilden, mit der eine Applikation entwickelt und betrieben wird. Einzelne Komponenten des Stacks können sein:
+
+Das**Betriebssystem**, auf dem die Software bzw. Applikation läuft (sowohl auf Clientseite als auch auf Serverseite). Hierzu zählen die klassischen Betriebssysteme[→ Linux](https://www.rheinwerk-verlag.de/linux-das-umfassende-handbuch/), macOS und Windows, aber auch mobile Betriebssysteme wie Android oder iOS.
+
+Der**Webserver**, der die Applikation hostet, z. B. nginx oder der Apache HTTP Server.
+
+Die**Programmiersprache**, die verwendet wird, um die Applikationslogik zu implementieren, z. B.[→ JavaScript](https://www.rheinwerk-verlag.de/programmieren-lernen-mit-javascript/),[→ Java](https://www.rheinwerk-verlag.de/programmieren-lernen-mit-java/),[→ C++](https://www.rheinwerk-verlag.de/grundkurs-c-plusplus/)oder[→ PHP](https://www.rheinwerk-verlag.de/einstieg-in-php-und-mysql-ideal-fuer-programmieranfaenger/).
+
+**Programmierwerkzeuge**(Tools), die während der Entwicklung zum Einsatz kommen, wie z. B. bestimmte Compiler, die für Menschen lesbaren Quelltext in für Computer lesbaren Maschinencode übersetzen.
+
+**Bibliotheken**, die zum Einsatz kommen, z. B. Frontend-Bibliotheken wie Lodash oder jQuery.
+
+**Frameworks**, die zum Einsatz kommen, z. B. Web-Frameworks wie Express.
+
+Die**Laufzeitumgebung**, unter der die Applikation ausgeführt wird, z. B. die JavaScript-Laufzeitumgebung[→ Node.js](https://www.rheinwerk-verlag.de/nodejs-das-umfassende-handbuch/), die es ermöglicht, JavaScript-Code auch auf Serverseite auszuführen.
+
+Die verwendeten**Datenbanken**, etwa relationale Datenbanken wie MySQL und PostgreSQL oder nicht-relationale Datenbanken, auch NoSQL-Datenbanken genannt, wie MongoDB.
+
+Der Begriff Stack rührt daher, dass die einzelnen**Komponenten in der Plattform hierarchisch angeordnet**und wie »übereinandergestapelt« sind.
+
+
+
+{width="6.4375in" height="3.1770833333333335in"}
+
+Software-Stacks: Komponenten für die Entwicklung einer Applikation
+
+Bei Webapplikationen unterscheidet man darüber hinaus oft auch zwischen einem**serverseitigen Stack (Server-Stack)**und einem**clientseitigen Stack (Client-Stack)**, die grundsätzlich verschieden sein können. Es ist nicht unüblich, für die Implementierung des Backends auf eine Programmiersprache wie Java zurückzugreifen und das Frontend mit[→ HTML, JavaScript und CSS](https://www.rheinwerk-verlag.de/schroedinger-lernt-html5-css-und-javascript/)umzusetzen. Umgekehrt ist es denkbar, das Backend in JavaScript zu programmieren und das Frontend in Java, z. B. bei der Entwicklung einer Android-basierten App für Smartphones.
+
+
+
+- Welche Stacks gibt es?
+
+Eines der bekanntesten und ältesten Beispiele für einen**Backend-Stack**ist der**LAMP-Stack**, eine Kombination aus dem Betriebssystem Linux, dem Webserver Apache, der Datenbank MySQL und der Programmiersprache PHP. Alternative Varianten dieses Stacks verwenden statt Linux ein anderes Betriebssystem und nennen sich dann**WAMP**(Windows-Variante) bzw.**MAMP**(macOS-Variante). Neuere Varianten dieses Stacks verwenden anstelle von PHP auch Ruby oder Python als Programmiersprache.
+
+Nicht so alt, aber dafür in den letzten Jahren umso bekannter geworden, ist der**MEAN-Stack**-- der allerdings nicht ganz sauber zwischen Backend und Frontend unterscheidet. MEAN steht für die nicht-relationale Dokumentendatenbank MongoDB, das Web-Framework Express, das Frontend-Framework Angular sowie die serverseitige JavaScript-Laufzeitumgebung Node.js. Diese Kombination hat für Entwickler den charmanten Vorteil, dass sowohl für die Clientseite als auch für die Serverseite dieselbe Programmiersprache zum Einsatz kommt.
+
+Der beliebte**MERN-Stack**ist eine leichte Abwandlung des MEAN-Stacks, bei dem für das Frontend statt Angular das Framework React zum Einsatz kommt. Die anderen Komponenten des Stacks, also MongoDB, Express und Node.js, bleiben gleich.
+
+Der**Frontend-Stack**besteht aus den grundlegenden Webtechnologien**HTML, CSS und JavaScript**. Dieser Stack hat für die Entwicklung von Frontends eine so große Relevanz, dass gar nicht mehr explizit von einem Stack gesprochen wird.
+
+- Fullstack-Entwicklung -- das steckt dahinter
+
+In den vergangenen Jahren hat sich die Berufsbezeichnung »Fullstack-Entwickler*in« immer mehr etabliert. Dabei geht es nicht darum, dass Sie in einem Webprojekt alles können müssen. Es geht darum, einen**Überblick über das Gesamtsystem einer Webapplikation**zu haben und die**Zusammenhänge zu verstehen**. Das beginnt bei der Infrastruktur, auf der die Applikation ausgeführt wird, über die Organisation der Datenhaltung und des Backends der Applikation bis hin zur Umsetzung des Frontends. Ein Fullstack Developer ist dabei nicht nur mit einem sehr breiten, aber flachen Wissen ausgestattet, sondern kann sich in einem Thema spezialisieren. Wichtig ist, dass der erwähnte Blick für das Gesamtsystem nicht verloren geht.
+
+Fullstack-Entwickler
+
+Montag, 30. September 2024
+
+07:37
+
+
+
+- Was ist ein Fullstack-Entwickler?
+
+Der Begriff**Fullstack umfasst den gesamten Stack**, also sowohl den Backend- als auch den Frontend-Stack. Sind Sie in der Fullstack-Entwicklung aktiv, kennen Sie sich daher gleichermaßen mit Backend- und Frontend-Technologien aus. Als Fullstack-Entwickler*in sind Sie ist also**ein echter Allrounder**: Sie können sowohl eine Weboberfläche mit HTML, CSS und JavaScript als auch einen Webservice implementieren, der auf Serverseite läuft und Anfragen vom Client verarbeitet. Sie sind außerdem in der Lage, je nach Anforderungen die richtige Datenbank auszuwählen, und wissen auch, wie die gesamte Applikation für den Produktiveinsatz vorbereitet werden kann.
+
+{width="8.104166666666666in" height="4.125in"}
+
+Einordnung der verschiedenen Themen
+
+****
+
+- Anforderungen an die Fullstack-Entwicklung
+
+In einem Webprojekt gibt es verschiedene Rollen in der Entwicklung. Neben den drei folgend vorgestellten Gruppen kann es speziellere Untergruppen geben, wie zum Beispiel Datenbankspezialist*innen, Mitarbeitende im Frontend-Design, im UX-Design, Texten und viele mehr.
+
+Als**Frontend-Entwickler*in**können Sie mit HTML, CSS und JavaScript komplexe Weboberflächen bauen und haben im besten Fall auch Erfahrung im Design. Sie kennen sich außerdem mit Frontend-Bibliotheken und -Frameworks wie Angular, React und Vue aus, kennen die entsprechenden Tools wie WebPack oder Babel und wissen mit CSS-Präprozessorsprachen umzugehen.
+
+Als**Backend-Entwickler*in**können Sie komplexe Applikationslogik für die Serverseite entwickeln und diese z. B. über Webservices zur Verfügung stellen. Sie kennen sich mit dem Design von Webservice-APIs aus und wissen, welche Datenbank für welchen Zweck geeignet ist.
+
+Als**DevOps-Spezialist*in**-- DevOps setzt sich aus den Begriffen*Development*, also Entwicklung, und*Operations*, also Vorgänge, zusammen -- vereinen Sie in sich Fähigkeiten, die für die Softwareentwicklung und den IT-Betrieb notwendig sind. Zu den Aufgaben von[→ DevOps](https://www.rheinwerk-verlag.de/professional-computing/devops/)-Teams zählen z. B. Anwendungen für das Produktivsystem zusammenzustellen (*deployen*), Build-Systeme zu konfigurieren und Webserver zu administrieren. Darüber hinaus kennen sich DevOps-Teams auch oft mit Themen wie Sicherheit und Performance von Webanwendungen aus.
+
+
+
+{width="4.072916666666667in" height="2.3229166666666665in"}
+
+Fullstack-Entwicklung: Alle Fähigkeiten in einer Person vereint
+
+Als**Fullstack-Entwickler*in**erfüllen Sie im besten Fall alle der genannten Anforderungen und vereinen die drei Rollen bis zu einem gewissen Grad in einer Person. Keine leichte Aufgabe und zudem eine, für die Sie einige Jahre lang Erfahrung sammeln müssen.
+
+
+
+- Fullstack-Entwickler vs. Spezialisten
+
+Aufgrund der**breit gestreuten Anforderungen**laufen Sie als Fullstack-Entwickler*in allerdings auch schnell Gefahr, »alles nur ein bisschen, dafür aber nichts ganz richtig zu können«. Demgegenüber stehen die Spezialist*innen, die sich genau auf ein bestimmtes Gebiet festgelegt haben. Ein Datenbankspezialist kennt sich mit Datenbanken in der Regel besser aus als eine Fullstack-Entwicklerin, ein Frontend-Designer kennt im Zweifelsfall besser die verschiedenen CSS-Kniffe, die notwendig sind, um ein Layout genau nach Vorlage umsetzen zu können. Und eine DevOps-Spezialistin ist bei der Arbeit auf der Kommandozeile und der Verwaltung von Servern oft effektiver als jemand aus der Fullstack-Entwicklung.
+
+In großen Unternehmen bzw. großen Softwareprojekten ist es häufig so, dass es**für verschiedene Bereiche des verwendeten Stacks ganze Teams**gibt. Ein Team kümmert sich um die Datenbank, ein weiteres um das Frontend-Design, ein anderes ist für die Umsetzung des Designs in eine konkrete Weboberfläche zuständig. Dennoch kann umfassendes Wissen -- das in der Fullstack-Entwicklung vereint wird -- von Vorteil sein, da die einzelnen**Bereiche nicht komplett unabhängig voneinander agieren**, sondern in der Regel ineinandergreifen.
+
+Oftmals werden Fullstack-Entwickler*innen insbesondere in kleineren Firmen oder Start-ups benötigt, die**agiler und flexibler auf Anforderungen reagieren**können -- oder müssen.
+
+
+- Wie wird man Fullstack-Entwickler?
+
+Fullstack-Entwickler*in werden Sie nicht von heute auf morgen. Wenn Sie den ersten Schritt auf Ihrem Weg in die Fullstack-Entwicklung machen möchten, sollten Sie sich einen**Überblick**über alle Themen, die für die**Umsetzung einer vollwertigen Webapplikation**von Bedeutung sind, verschaffen: angefangen beim Frontend mit HTML, CSS und JavaScript über Backend-Schnittstellen bis hin zur Speicherung von Informationen in Datenbanken. Aber auch Themen wie**Testing**,**Deployment**und die Organisation des**Quellcodes mit Versionskontrolle**sind für Sie relevant. Sie sollten mit modernen Technologien umgehen können, Konzepte kennen, die für das Verständnis einer Applikation notwendig sind, und mit den gängigen Bibliotheken und Frameworks vertraut sein.
+
+**JavaScript**als Technologie bildet eine wichtige Grundlage, da es sowohl client- als auch serverseitig eingesetzt werden kann. Um ein**solides Grundwissen**in dieser Sprache kommen Sie daher nicht herum. Wenn Sie JavaScript in Form der Node.js-Plattform auch serverseitig einsetzen, machen Sie sich das Leben als Fullstack-Entwickler*in deutlich leichter. Aber auch hier gilt: Werfen Sie einen Blick auf**andere Lösungsansätze**wie beispielsweise C# oder[→ Python](https://www.rheinwerk-verlag.de/python-3-das-umfassende-handbuch/). Lassen Sie sich inspirieren, und finden Sie den Ansatz, der zu Ihnen passt.
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Manpower.md b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Manpower.md
new file mode 100644
index 0000000..36b9e9e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Manpower.md
@@ -0,0 +1,33 @@
+# Ressourcen: Manpower
+
+Created: 2024-09-18 11:37:06 +0200
+
+Modified: 2024-09-18 11:41:57 +0200
+
+---
+
+**Ressourcen Manpower**
+
+| Name | Initialen | Beruf-Lehrjahr | Projekt-Arbeitstage | Bemerkungen |
+|-------------|---------|-------------|------------------|------------|
+| Yannick Oser | YO | IF-AE-4 | Di, Mi & Do | |
+| Aimo Altorfer | AA | IF-AE-3 | 1-2 Tage / Woche | |
+| Alwin Litscher | AL | IF-AE-1 | Ab November | |
+| Fredy Albisser | FA | IF-BB | Wenn sich Zeit ergibt | |
+
+
+
+
+
+**Aufgabenverteilung**
+
+| System | |
+|------------------------------|-----|
+| Requirements | |
+| Architektur | |
+| Projekt-Management (Jira) | |
+| Git (Versionierung & Backup) | |
+| Frontend | |
+| Backend | |
+| Database | |
+| | |
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Tools.md b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Tools.md
new file mode 100644
index 0000000..2693703
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Projektmanagement/Ressourcen--Tools.md
@@ -0,0 +1,119 @@
+# Ressourcen: Tools
+
+Created: 2024-09-18 11:45:52 +0200
+
+Modified: 2024-10-09 08:01:51 +0200
+
+---
+
+
Eine Startseite (index.html) als Grundgerüst mit Header, Footer, Nav Bar und Content erstellen.
+
Header, Footer & Nav Bar sollen in allen Unterseiten gleich aussehen. Um dies gewährleisten zu können, wäre ein Template oder eine Integration als Div sinnvoll.
Ein globales Stylesheet für alle Webseiten definieren und erste Wünsche für Inhalte aufnehmen (Farbkombinationen, Schriftarten & -grössen, Tabellen, Boxen,
+
Alle
+
+
+
+
+
Wie sieht eine coole erstrebenswerte Webseite aus und was zeichnet diese aus? 3 Beispiele suchen an was wir uns orientieren wollen!
RE: Prototyping => Ideen-Sammlung für einen Escaperoom
+
Alle
+
+
+
+
+
+
+
+
+
3
+
W-40
+
Wochenbesprechung Mo 08:30 - 09:00
+
Alle
+
+
+
+
+
Einrichten und synchronisieren von Visual Studio Code => Firmen-/Abteilungsspezifisches Teamwork => Hilfestellungen, Vertrautheit bei Demonstrationen, Übernahme von Projekten, …
+
Alle
+
+
+
+
+
GitLab Einführung am PSI durch Basil Bruhn Di 08:30 - 11:30
+
Alle
+
+
+
+
+
Angular-Kurs und Schulung / Coaching durch Jonas Bandi
+
+
+
+
+
+
Individuelle Schulungen definieren => CSS-Präprozessoren, TypeScript, Angular, Node.js, Express.js, Next.js, Nest.js oder alle .js
Auswertung Umfrage am Berufserkundungstag => Integration in OneNote 2. Anforderungsanalyse // Soll am 31. Oktober nochmals eine Umfrage durchgeführt werden?
+
Aimo
+
+
+
+
+
Was speichern wir wo? => Ich werde das OneNote zügeln (neues Laufwerk wo alle Zugang haben, also Lernende und Fachvorgesetzte)
+
+
+
+
+
+
Recherche "E-Mail generieren und versenden" => Der Bewerber gibt seine E-Mail-Adresse ein und erhält ein Bestätigung E-Mail mit Betreff, einem Standard-Text und 2 PDFs im Anhang (Anmeldebestätigung und Anfahrtsplan)
+
+
+
Aimo
+
+
+
+
+
Recherche "PDF generieren" => In der Datenbank ist ein Template (Dateivorlage) gespeichert und diese muss mit den individuellen Informationen des Bewerbers 2.8. Anmeldebestätigung
+
Yannick
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
4
+
W-41
+
Yannick Ferien, Aimo =>
+
+
+
+
+
+
+
+
+
+
+
+- Hat viele gute Elemente, Barrierefreiheit, Kacheln mit den Personen, (PSI-) Landschaft zoomen [Link](https://spin2030.com/)
+- Nicht überladen, schon fast leer, dafür viel scrollen [Link](https://oh-nord.de/website-studio/?utm_source=google&utm_medium=cpc&utm_campaign=erstgespraech&gad_source=1&gclid=CjwKCAjw59q2BhBOEiwAKc0ijaRf7_GXlhGXKFfYhegauhhI9nVEepQs3s5ncfWjSrIAnOGVW2inVBoCTTMQAvD_BwE)
+- Einblendungen und Übergänge [Link](https://www.on.com/de-de/)
+- Etwas unorthodox, aber interessant zum Erkunden, aber nicht unbedingt zum schnell etwas finden [Link](https://uclab.fh-potsdam.de/arete/de/artefacts/kapitale-aus-vergils-aeneis)
+- Sehr eindrückliche Effekte [Link](https://curious.co/)
+- Beispiel für gutes responsive design [Link](https://www.nowness.com/)
+- Tolle Effekte [Link](https://www.dropbox.com)
+- Minimalistisch, nur das Wichtigste [Link](https://www.google.com)
+- Nicht so überladen wie andere Shopping Seiten wie z.B Amazon: [Link](https://galaxus.ch)
+- Starkes Flatdesgign [Link](https://selemen.liqium.com/)
+
+
+
+
+
+{width="9.3125in" height="4.739583333333333in"}
+
+
+
+Webseite
+
+- Programmiersprachen
+- Frontend: HTML, CSS, JS, TS & Angular
+- Backend: Node.js, JS
+
+Weitere: Sprache Anwendungsbereich
+
+Java & C# Grössere, komplexere Backend-Anwendungen, zählen zu den einfacheren Sprachen, OOP
+
+C/C++ Performant, Gamedesign (das letzte rauskitzeln), eher schwierig und hardwarenah
+
+Python KI, Machine Learning, vielseitig
+
+Go In Maschinencode oder JS compilieren, mit Framework Gin, Revel oder GoKit / GoMicro für microServices
+
+PHP Content Management Systeme (WordPress & Joomla sind in PHP), ausschliesslich für Webentwicklung, LAMP-Stack (Linux, Apache, MySQL & PHP)
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering.md
new file mode 100644
index 0000000..f4cea79
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering.md
@@ -0,0 +1,203 @@
+# Requirements Engineering
+
+Created: 2024-09-03 07:28:50 +0200
+
+Modified: 2024-09-16 15:34:20 +0200
+
+---
+
+Die Anforderungsanalyse ist entscheidend, um sicherzustellen, dass die Software die Bedürfnisse und Erwartungen der Stakeholder erfüllt. Hier wird festgelegt, **was die Software tun soll**, bevor man sich darauf konzentriert, wie sie es tun soll.
+
+
+
+Die Anforderungsanalyse baut auf mehreren Konzepten auf. Es versteht sich von selbst, dass für ein kleines Projekt nicht der gleiche Aufwand wie für ein grosses Projekt betrieben werden muss. Wenn aber mehrere Personen am Projekt arbeiten, ein wichtiger Termin einzuhalten ist und eine Software über Jahre im Betrieb sein soll, eine andere Herangehensweise gebraucht wird, als für eine kleine Schul-Programmieraufgabe.
+
+
+
+In der Anforderungsanalyse gibt es eine gewisse logische Reihenfolge, in der die Konzepte üblicherweise angewendet werden, sowie Abhängigkeiten zwischen einigen der Konzepte. Andere Konzepte können parallel oder unabhängig voneinander betrachtet werden. Hier sind die einzelnen Konzepte in der Reihenfolge, in der sie typischerweise umgesetzt werden, sowie Hinweise zu ihren Abhängigkeiten und zur parallelen Bearbeitbarkeit:
+
+****
+
+**Typische Reihenfolge der Konzepte und Abhängigkeiten**
+
+****
+
+1. **Stakeholder-Analyse** (Abhängigkeitsstufe: Hoch)
+
+ - **Definition**: Die Stakeholder-Analyse identifiziert und analysiert alle Personen oder Organisationen, die von dem Projekt betroffen sind oder Einfluss darauf haben.
+ - **Zweck**: Hilft, die Bedürfnisse, Erwartungen und Einflussmöglichkeiten der Stakeholder zu verstehen, um ihre Anforderungen gezielt zu berücksichtigen. Diese Analyse ist grundlegend, da sie bestimmt, von wem die Anforderungen gesammelt werden.
+ - **Schritte**: Identifikation von Stakeholdern, Analyse ihrer Interessen und Einflussmöglichkeiten, Kommunikation und Abstimmung.
+ - **Abhängigkeit:** Dies ist der Ausgangspunkt. Ohne Stakeholder-Analyse weiß man nicht, von wem Anforderungen gesammelt werden sollen.
+ - **Parallelität:** Meist eigenständig und vor allem anderen durchgeführt.
+
+
+
+2. **Anforderungsermittlung** (Abhängigkeitsstufe: Hoch)
+
+ - **Definition**: Die Anforderungsermittlung ist der Prozess, bei dem die Bedürfnisse, Wünsche und Erwartungen der Stakeholder gesammelt werden.
+ - **Zweck**: Sammeln aller Anforderungen
+ - **Schritte**: Hier einige Methoden, die zur Ermittlung von Anforderungen eingesetzt werden können:
+ - Interviews: Direkte Gespräche mit den Stakeholdern, um ihre Bedürfnisse und Wünsche zu verstehen.
+ - Workshops: Gruppendiskussionen mit Stakeholdern, um Anforderungen gemeinsam zu erarbeiten.
+ - Beobachtung: Analyse von bestehenden Prozessen und Nutzerverhalten, um Anforderungen abzuleiten.
+ - Fragebögen: Systematische Befragung von Stakeholdern zur Ermittlung ihrer Anforderungen.
+ - Dokumentenanalyse: Untersuchung bestehender Dokumente (z.B. aktuelle Systeme, Verträge), um Anforderungen zu identifizieren.
+ - **Abhängigkeit**: Die Anforderungsermittlung hängt direkt von der Stakeholder-Analyse ab, da die Stakeholder die Quelle der Anforderungen sind.
+ - **Parallelität**: In dieser Phase können verschiedene Methoden zur Ermittlung der Anforderungen parallel angewendet werden (z.B. Interviews und Workshops).
+
+
+
+3. **Persona-Erstellung** (Abhängigkeitsstufe: Mittel)
+
+ - **Definition**: Eine Persona ist ein fiktiver, repräsentativer Benutzer, der eine bestimmte Zielgruppe verkörpert.
+ - **Zweck**: Hilft, die Bedürfnisse und Verhaltensweisen der Nutzer zu verstehen und diese in den Entwicklungsprozess zu integrieren.
+ - **Beispiel**: „Lisa ist 35 Jahre alt, arbeitet als Marketing-Managerin und nutzt die Software, um Kampagnen zu planen und zu analysieren."
+ - **Abhängigkeit:** Baut auf den Ergebnissen der Stakeholder-Analyse und der Anforderungsermittlung auf, da die Personas auf echten Nutzerdaten basieren.
+ - **Parallelität:** Kann parallel zu anderen Analysemethoden erstellt werden, sobald erste Anforderungen bekannt sind.
+
+
+
+4. **Use Cases / User Stories** (Abhängigkeitsstufe: Mittel)
+
+****
+
+4.1. **Use Case (Anwendungsfall)**
+
+- **Definition**: Ein Use Case beschreibt eine Interaktion zwischen einem Benutzer (Akteur) und dem System, um ein bestimmtes Ziel zu erreichen.
+- **Zweck**: Dient dazu, die Funktionalitäten des Systems aus der Sicht des Nutzers zu erfassen und zu dokumentieren.
+- **Struktur**: Ein Use Case besteht aus dem Namen des Anwendungsfalls, dem Ziel, den beteiligten Akteuren und einer Beschreibung des Ablaufs.
+- **Beispiel**: „Buchung eines Tickets" -- der Benutzer wählt ein Ziel, gibt persönliche Daten ein, und bestätigt die Buchung.
+
+****
+
+4.2. **User Story**
+
+- **Definition**: Eine User Story ist eine kurze, einfache Beschreibung einer Funktion aus der Perspektive des Endbenutzers.
+- **Zweck**: Dient der klaren und verständlichen Kommunikation von Anforderungen und legt den Fokus auf den Nutzen für den Nutzer.
+- **Struktur**: „Als [Benutzerrolle] möchte ich [Ziel/Wunsch], um [Nutzen]."
+- **Beispiel**: „Als Marketing-Managerin möchte ich die Klickrate meiner Kampagnen sehen, um deren Erfolg zu bewerten."
+
+
+
+4.3. **Gemeinsamkeiten**
+
+- Genereller Zweck: Spezifikation der Interaktionen zwischen Nutzern und dem System.
+- Abhängigkeit: Erfordert eine erste Erfassung der funktionalen Anforderungen und ein grundlegendes Verständnis der Stakeholder und deren Bedürfnisse.
+- Parallelität: Sobald die grundlegenden Anforderungen klar sind, können Use Cases oder User Stories unabhängig entwickelt werden.
+
+
+
+5. **Business-Rule-Analyse** (Abhängigkeitsstufe: Mittel)
+
+ - **Definition**: Analyse von Geschäftsregeln, die die Entscheidungslogik innerhalb des Systems steuern.
+ - **Zweck**: Sicherstellen, dass alle relevanten Geschäftsregeln korrekt und vollständig in den Anforderungen abgebildet sind.
+ - **Beispiel**: „Eine Bestellung darf nur dann versendet werden, wenn die Zahlung bestätigt wurde."
+ - **Abhängigkeit:** Baut auf den funktionalen Anforderungen auf, da Geschäftsregeln oft detailliertere oder spezifischere Bedingungen und Einschränkungen darstellen.
+ - **Parallelität:** Kann parallel zu anderen Analysen durchgeführt werden, insbesondere zu Use Cases oder User Stories.
+
+
+
+6. **Kontextdiagramm** (Abhängigkeitsstufe: Mittel)
+
+ - **Definition**: Ein Kontextdiagramm ist eine grafische Darstellung, die das System in seiner Umgebung zeigt und die Interaktionen mit externen Akteuren oder Systemen darstellt.
+ - **Zweck**: Es gibt einen Überblick über das System und seine Schnittstellen zu anderen Systemen oder Benutzergruppen.
+ - **Beispiel**: Ein Kontextdiagramm für eine Webanwendung könnte das System in der Mitte darstellen, umgeben von Benutzergruppen (z.B. Administratoren, Endnutzer) und externen Systemen (z.B. Datenbanken, Zahlungsgateways).
+ - **Abhängigkeit:** Setzt eine grundlegende Ermittlung der Anforderungen voraus, da die Interaktionen und Schnittstellen erst bekannt sein müssen.
+ - **Parallelität:** Kann parallel zu den User Stories/Use Cases entwickelt werden, sobald die Hauptakteure und externen Systeme klar sind.
+
+
+
+7. **Prototyping** (Abhängigkeitsstufe: Mittel)
+
+ - **Definition**: Das Erstellen eines vereinfachten Modells (Prototyps) des Systems, um Anforderungen zu testen und zu verfeinern.
+ - **Zweck**: Hilft, Anforderungen zu klären und frühes Feedback von Stakeholdern einzuholen.
+ - **Arten von Prototypen**:
+ - Low-Fidelity: Einfache Skizzen oder Wireframes.
+ - High-Fidelity: Interaktive, aber nicht voll funktionsfähige Modelle des Systems.
+ - **Abhängigkeit:** Prototypen basieren auf den funktionalen Anforderungen, Use Cases und den Ergebnissen der Persona-Erstellung.
+ - **Parallelität:** Kann parallel zur Anforderungsermittlung und Validierung verwendet werden, da es auch ein Mittel zur Verfeinerung der Anforderungen ist.
+
+
+
+8. **SWOT-Analyse** (Abhängigkeitsstufe: Gering)
+
+ - **Definition**: Eine SWOT-Analyse untersucht die Stärken (Strengths), Schwächen (Weaknesses), Chancen (Opportunities) und Risiken (Threats) eines Projekts.
+ - **Zweck**: Unterstützt die strategische Planung und hilft, potenzielle Risiken frühzeitig zu erkennen. Bewertung der internen und externen Faktoren, die das Projekt beeinflussen könnten.
+ - **Anwendung**: Oft eingesetzt, um die Rahmenbedingungen für das Projekt zu bewerten und daraus Anforderungen abzuleiten.
+ - **Abhängigkeit**: Kann zu jedem Zeitpunkt durchgeführt werden, ist aber besonders nützlich, wenn die Anforderungen und Rahmenbedingungen des Projekts klarer werden.
+ - **Parallelität**: Kann unabhängig von der detaillierten Anforderungsanalyse durchgeführt werden.
+
+
+
+9. **Ergonomie- und Usability-Analyse** (Abhängigkeitsstufe: Mittel)
+ - **Definition**: Analyse der Benutzerfreundlichkeit und Ergonomie des Systems.
+ - **Zweck**: Sicherstellen, dass das System für den Endnutzer leicht verständlich und bedienbar ist.
+ - **Techniken**: Usability-Tests, Interviews mit Nutzern, Erstellung von Prototypen, um Feedback zur Benutzerfreundlichkeit zu sammeln.
+ - **Abhängigkeit**: Die Benutzerinteraktionen (User Stories, Use Cases, Prototypen) müssen bekannt sein, damit die Benutzerfreundlichkeit bewertet werden kann.
+ - **Parallelität**: Kann parallel mit Prototyping und User Stories durchgeführt werden, sobald erste Benutzerschnittstellen bekannt sind.
+
+
+
+10. **Requirements Traceability Matrix (RTM)** (Abhängigkeitsstufe: Hoch)
+
+ - **Definition**: Eine Tabelle, die die Rückverfolgbarkeit von Anforderungen über den gesamten Entwicklungsprozess hinweg sicherstellt.
+ - **Zweck**: Hilft, sicherzustellen, dass alle Anforderungen in den entsprechenden Entwicklungs- und Testaktivitäten berücksichtigt werden.
+ - **Struktur**: Die Matrix verknüpft Anforderungen mit entsprechenden Testfällen, Design-Elementen und Implementierungsdetails.
+ - **Abhängigkeit**: Diese Matrix kann erst erstellt werden, wenn die Anforderungen festgelegt sind.
+ - **Parallelität**: Kann parallel zu Tests und Implementierung geführt werden, sobald die Anforderungen dokumentiert sind.
+
+
+
+11. **Priorisierungstechniken (z.B. MoSCoW, Kano-Modell)** (Abhängigkeitsstufe: Hoch)
+
+ - **MoSCoW-Methode**: Anforderungen werden in Must-have, Should-have, Could-have und Won't-have kategorisiert.
+ - **Kano-Modell**: Analysiert Anforderungen basierend auf den Erwartungen der Benutzer und kategorisiert sie in Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren.
+ - **Zweck**: Anforderungen nach ihrer Wichtigkeit und Dringlichkeit priorisieren.
+ - **Abhängigkeit**: Die Anforderungen müssen bekannt sein, bevor sie priorisiert werden können.
+ - **Parallelität**: Kann in späteren Phasen der Anforderungsermittlung oder nach deren Erhebung durchgeführt werden.
+
+
+
+12. **Risikomanagement** (Abhängigkeitsstufe: Mittel)
+
+ - **Definition**: Analyse und Management potenzieller Risiken, die die Erreichung der Projektziele gefährden könnten.
+ - **Zweck**: Frühes Erkennen und Gegensteuern von Risiken, die sich aus den Anforderungen oder deren Umsetzung ergeben könnten.
+ - **Schritte**: Risikoidentifikation, Risikoanalyse, Risikobewertung, Risikosteuerung.
+ - **Abhängigkeit**: Die Anforderungen und Rahmenbedingungen des Projekts müssen bekannt sein, um Risiken richtig einschätzen zu können.
+ - **Parallelität**: Kann während des gesamten Projekts laufend durchgeführt werden, aber ein Großteil der Analyse erfolgt in den frühen Phasen.
+
+
+
+13. **Scope Management** (Abhängigkeitsstufe: Hoch)
+
+ - **Definition**: Verwaltung des Projektumfangs, um sicherzustellen, dass das Projekt nur die genehmigten Arbeiten umfasst.
+ - **Zweck**: Verhindert „Scope Creep" (ungeplante Erweiterungen des Umfangs), der zu Verzögerungen und höheren Kosten führen kann.
+ - **Techniken**: Definition eines klaren Projektumfangs, regelmäßige Überprüfungen und Anpassungen bei Änderungen.
+ - **Abhängigkeit**: Muss in allen Phasen angewendet werden, insbesondere sobald Anforderungen erfasst und dokumentiert sind.
+ - **Parallelität**: Wird während des gesamten Projekts angewendet, um sicherzustellen, dass der Umfang stabil bleibt.
+
+
+
+**Konzepte, die parallel laufen können:**
+
+- **SWOT-Analyse:** Da sie eher auf Rahmenbedingungen als auf spezifische Anforderungen fokussiert ist, kann sie weitgehend unabhängig durchgeführt werden.
+- **Stakeholder-Analyse und Anforderungsermittlung**: Diese beiden Konzepte können eng zusammenarbeiten und auch parallel stattfinden, insbesondere bei komplexeren Projekten mit mehreren Stakeholdern.
+- **Ergonomie- und Usability-Analyse:** Sobald Prototypen oder erste Entwürfe vorliegen, kann parallel die Benutzerfreundlichkeit getestet werden.
+- **Business-Rule-Analyse:** Geschäftsregeln lassen sich oft unabhängig von den funktionalen Anforderungen detailliert betrachten.
+
+****
+
+**Fazit zur Reihenfolge und Abhängigkeiten:**
+
+Die Anforderungsanalyse beginnt typischerweise mit der Stakeholder-Analyse und der Anforderungsermittlung, da diese die Basis für viele andere Konzepte liefern. Darauf aufbauend folgen spezifizierende und strukturierende Techniken wie Use Cases, Kontextdiagramme und Business-Rule-Analysen. Einige Konzepte, wie Prototyping, können parallel zur weiteren Verfeinerung der Anforderungen durchgeführt werden, während andere, wie das Risikomanagement oder die Usability-Analyse, den gesamten Prozess begleiten und in mehreren Phasen zum Einsatz kommen.
+
+
+
+Hier ist ein Gantt-Diagramm, das die Reihenfolge und Dauer der verschiedenen Konzepte in der Anforderungsanalyse visualisiert. Es zeigt, welche Aufgaben parallel laufen können und wie sie zeitlich aufeinander abgestimmt sind.
+
+
+
+{width="4.78125in" height="3.21875in"}
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/1.-Stakeholder.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/1.-Stakeholder.md
new file mode 100644
index 0000000..3b5c56a
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/1.-Stakeholder.md
@@ -0,0 +1,124 @@
+# 1. Stakeholder
+
+Created: 2024-09-03 08:00:21 +0200
+
+Modified: 2024-09-18 15:17:00 +0200
+
+---
+
+Im Folgenden sind die Stakeholder aufgeführt
+
+
+
+
+
+
+
+
+
+
+
+
Stakeholder
+
Einflussbereich
+
Motivation
+
+
+
+
+
PSI
+
Entscheidungsträger für Lehrberufe-Angebot, Anzahl Lehrstellen pro Beruf, Budget.
+
Schätzen positive Rückmeldungen (Lob) mehr als negative (Beschwerden)
+
+
+
PSI-Berufsbildung
+
Gemeinsamer Nenner bezüglich den 17 Lehrberufen im PSI. Sorgt dafür, dass – wo sinnvoll – sich die verschiedenen Lehrberufe an einen gemeinsamen Standard (Web-Auftritt, Broschüren, Flyers, …) halten
+
Wenn unsere Web-Applikation Anklang findet ist es naheliegend, dass alle Berufe integriert werden
+
+
+
AIT
+
Linienzugehörigkeit für Fachbezug, stellt auch die grösste Anzahl der Rotationsplätze und somit der Rotationsplatzbetreuer. AIT-Plattformanbieter (Server, OS, DB, E-Mail, Security-Guidelines, Lizenzen, Lifecycle, …)
+
Fachkompetenz und Manpower (Lernender auf Rotationsplatz)
+
+
+
GFA & ZPT
+
Anbieter eines Rotationsplatzes für Applikationsentwickler im 3. und 4. Lehrjahr
+
Fachkompetenz und Manpower (Lernender auf Rotationsplatz)
+
+
+
AWI
+
Anbieter eines Rotationsplatzes für Plattformentwickler (Linux-Core-Team)
+
Fachkompetenz und Manpower (Lernender auf Rotationsplatz)
+
+
+
Schule & ÜK-Center
+
Ausbildungsmodule => kann ein Nutzen sein bezüglich Ausbildung und Zeit (Synergien), kann aber auch zu widersprüchlichen Ausbildungsinhalten führen
+
Synergien
+
+
+
PSI-Kommunikations-abteilung
+
Definiert, was und wie etwas im Namen des PSI veröffentlicht werden darf
Definiert die Ausbildungsinhalte und Handlungskompetenzen für diesen Lehrberuf
+
+
+
Informatik-Lernende
+
3- und 4-jährige Berufslehre, Produkt der Berufsbildung
+
Mitwirkende bei der Berufswahl
+
+
+
Zielpublikum
+
+
Schüler, die in der Berufswahl stehen und den richtigen Lehrberuf und die richtige Lehrfirma suchen
+
Eltern, die sich für ihre Kinder schlau machen wollen
+
Mitarbeiter welche sich für interne Belange interessieren oder von Bekannten angefragt werden, ob das PSI Lernende ausbildet und bei wem man sich melden muss und wie man vorgehen muss um an eine Lehrstelle zu kommen.
+
Lehrer, die sich informieren wollen
+
Allgemein interessierte Personen, die ein Produkt unserer Informatik-Berufsbildung sehen wollen
+
+
Sie sind die eigentlichen Anwender der Web-Applikation
+
+
+
ICT-Berufsbildung Aargau / PK-Org
+
Gut möglich, dass ein Teil dieser Arbeit als (Test-) IPA realisiert wird, in diesem Fall gelten all die Vorgaben und Anforderungen für eine IPA
+
+
Bildungsverordnung
+
Bildungsplan
+
IPA-Wegleitung für Kandidaten
+
IPA-Wegleitung für begleitenden Fachbetreuer
+
Chef-Experte
+
Validierender Experte
+
Begleitender Experte
+
Expertengremium für Notenniveau
+
+
Aufgabenstellung muss einer IPA würdig sein, also ein bestimmtes Level beinhalten. Die Aufgabe muss aber auch für den Kandidaten mit gewohnten Mitteln und Methoden zu realisieren sein.
+
+
+
Fachverantwortlicher Berufsbildner
+
Umsetzung Bildungsvorgaben, verantwortlich für Schnittstelle zu allen Stakeholder, verantwortlich für Aktualität des Webseiten-Inhaltes (Lehrberufe, Berufsreformen, Berufswahlangebot, Termine, …)
+
Arbeitserleichterung durch Automation beim ganzen Berufswahl-Prozess
+
+
+
Entwicklungsteam
+
Informatikerlernende der Fachrichtung Applikationsentwicklung in verschiedenen Lehrjahren
+
Anspruchsvolle, ganzheitliche vernetzte Anwendung im Team realisieren. Visitenkarte der eigenen IPA
Allgemeines Portal in der Berufswahl-Unterstützung
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken.md
new file mode 100644
index 0000000..bece51e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken.md
@@ -0,0 +1,9 @@
+# 11. Priorisierungstechniken
+
+Created: 2024-09-19 16:29:23 +0200
+
+Modified: 2024-09-19 16:29:52 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken/11.1-Kano-Modell.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken/11.1-Kano-Modell.md
new file mode 100644
index 0000000..28c4f07
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/11.-Priorisierungstechniken/11.1-Kano-Modell.md
@@ -0,0 +1,40 @@
+# 11.1 Kano-Modell
+
+Created: 2024-09-19 16:04:07 +0200
+
+Modified: 2024-09-19 16:31:29 +0200
+
+---
+
+**Anforderungskategorisierung nach dem Kano-Modell**
+
+Für die Anforderungsermittlung ist das Wissen, welche Bedeutung die Anforderungen für die Zufriedenheit der Stakeholder haben, sehr hilfreich. Diese Zufriedenheit wird mit den jeweiligen Merkmalen eines Produkts, von denen sie abhängen, nach dem Modell von Kano in drei Kategorien eingeteilt [Kano et al. 1984]:
+
+
+
+- Basisfaktoren sind selbstverständlich vorausgesetzte Systemmerkmale (unterbewusstes Wissen)
+
+Basisfaktoren muss das System in jedem Fall vollständig erfüllen, sonst stellt sich beim Stakeholder massive Unzufriedenheit ein. Vollständig erfüllte Basisfaktoren erzeugen keine positive Stimmung, sondern vermeiden lediglich, dass starke Unzufriedenheit entsteht. Basisfaktoren werden vor allem durch bereits vorhandene Systeme geprägt. Für deren Ermittlung eignen sich deshalb besonders Beobachtungstechniken und dokumentenzentrierte Techniken.
+
+
+
+- Leistungsfaktoren sind die explizit geforderten Systemmerkmale (bewusstes Wissen)
+
+Leistungsfaktoren sind die Merkmale, Leistungsfaktoren die der Stakeholder bewusst und explizit fordert. Die Erfüllung dieser Merkmale erzeugt Stakeholderzufriedenheit und ist erstrebenswert. Fehlen einige der geforderten Merkmale, akzeptiert der Stakeholder das Produkt vermutlich, doch seine Zufriedenheit sinkt mit jedem fehlenden Leistungsfaktor. Leistungsfaktoren lassen sich gut durch Befragungstechniken ermitteln.
+
+
+
+- Begeisterungsfaktoren sind Systemmerkmale, die der Stakeholder nicht kennt und erst während der Benutzung als angenehme und nützliche Überraschungen entdeckt (unbewusstes Wissen)
+
+Begeisterungsfaktoren sind Merkmale eines Systems, deren Wert ein Stakeholder erst erkennt, wenn er sie selbst ausprobieren kann oder sie vom Requirements Engineer vorgeschlagen bekommt. Für die Ermittlung solcher Begeisterungsfaktoren sind insbesondere Kreativitätstechniken geeignet.
+
+
+
+{width="4.385416666666667in" height="3.5208333333333335in"}
+
+
+
+Im Laufe der Zeit werden aus Begeisterungsfaktoren Leistungsfaktoren und schließlich Basisfaktoren, denn der Nutzer gewöhnt sich an Merkmale eines Systems. Bei der Ermittlung der Anforderungen sind alle drei Anforderungskategorien zu berücksichtigen.
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/12.-Risikomanagement.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/12.-Risikomanagement.md
new file mode 100644
index 0000000..e58999c
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/12.-Risikomanagement.md
@@ -0,0 +1,481 @@
+# 12. Risikomanagement
+
+Created: 2024-10-15 17:00:42 +0200
+
+Modified: 2024-10-22 09:35:14 +0200
+
+---
+
+**Risikoanalyse:**
+
+****
+
+Eine Risikoanalyse für eine Webseite ist ein strukturiertes Verfahren zur Identifizierung, Bewertung und Minderung von Risiken, die mit dem Betrieb und der Nutzung einer Webseite verbunden sind. Sie umfasst mehrere Aspekte, darunter technische, rechtliche, operative und sicherheitsbezogene Risiken. Hier ist eine Übersicht, wie eine solche Risikoanalyse aussehen kann und welche Elemente sie umfasst:
+
+
+
+1. **Gegenstand der Analyse: Webseite "Berufswahl-Schnupperlehranmeldung"** Datum: 15.10.2024
+
+
+2. **Verwendete Unterlagen:**
+
+ - **OneNote-Notizbuch "IF-Projekte" > Register "Webseite Berufswahl"**
+
+****
+
+
+
+3. **Identifizierung der Risiken**
+
+ - **Sicherheitsrisiken**
+ - **Hacking, Malware, DDoS-Angriffe**
+ - **Schwachstellen in der Webanwendung (z. B. SQL-Injection, Cross-Site-Scripting)**
+ - **Unsichere Passwörter oder Authentifizierungsmechanismen**
+
+
+
+- Betriebsrisiken
+ - Ausfallzeiten (Server, Netzwerk)
+ - Fehlfunktionen der Webseite oder des Content Management Systems (CMS)
+ - Unzureichende Wartung oder fehlende Updates
+ - Ungetestete Updates
+
+
+
+- Datenschutzrisiko
+ - Verletzung der Datenschutzgrundverordnung (DSGVO)
+ - Verlust von Nutzerdaten durch unzureichende Verschlüsselung oder unsichere Speicherung
+
+
+
+- Rechtliche Risiken
+ - Urheberrechtsverletzungen (z. B. unlizenzierte Bilder oder Texte)
+ - Haftung für Benutzerinhalte (z. B. Kommentare oder Forenbeiträge)
+ - Unzureichende oder falsche AGB/Datenschutzerklärungen
+
+
+
+- Reputationsschaden
+ - Negative Auswirkungen auf die Marke bei Sicherheitsverletzungen oder Ausfällen
+ - Schlechte Benutzererfahrung (Usability, Performance, Responsivität)
+
+
+
+4. **Bewertung der Risiken**
+
+Nach der Identifizierung werden die Risiken hinsichtlich ihrer **Wahrscheinlichkeit** und **Auswirkungen** bewertet. Dies hilft dabei, Prioritäten festzulegen und zu entscheiden, welche Risiken zuerst angegangen werden sollten. Ein häufig verwendetes Modell ist eine **Risikomatrix**, die das Risiko in einem zweidimensionalen Raster darstellt:
+
+- **Wahrscheinlichkeit**: Wie wahrscheinlich ist es, dass das Risiko eintritt?
+
+A (häufig), B (oft), C (gelegentlich), D (selten), E (unwahrscheinlich), F (praktisch unmöglich)
+
+- **Auswirkung**: Wie gravierend wären die Folgen, wenn das Risiko eintritt?
+
+IV (unbedeutend), III (klein), II (kritisch), I (katastrophal),
+
+
+
+| **Nr** | **Risiko / Beschreibung / Begründung der Bewertung** | **Auswirkung** | **Häufigkeit** |
+|:---:|------------------------------------------|:----------:|:---------:|
+| 1 | Hacking | I | D |
+| 2 | Malware (Hochladen von Dateien wie Lebenslauf und Zeugnisse) | I | D |
+| 3 | DDoS-Angriffe (lahmlegen, Termine sinnlos buchen) | II | D |
+| 4 | Unsichere Passwörter oder Authentifizierungsmechanismen | II | B |
+| 5 | Ausfallzeiten (Server, Netzwerk) | III | D |
+| 6 | Fehlfunktionen der Webseite oder des Content Management Systems (CMS) | III | C |
+| 7 | Unzureichende Wartung oder fehlende Updates | III | C |
+| 8 | Ungetestete Erweiterungen | III | C |
+| 9 | Verletzung der Datenschutzgrundverordnung (DSGVO) | I | C |
+| 10 | Verlust von Nutzerdaten durch unzureichende Verschlüsselung oder unsichere Speicherung | II | D |
+| 11 | Urheberrechtsverletzungen (z. B. unlizenzierte Bilder oder Texte) | II | E |
+| 12 | Haftung für Benutzerinhalte (z. B. Kommentare oder Forenbeiträge) | IV | E |
+| 13 | Unzureichende oder falsche AGB/Datenschutzerklärungen | II | B |
+| 14 | Negative Auswirkungen auf die Marke bei Sicherheitsverletzungen oder Ausfällen | III | C |
+| 15 | Schlechte Benutzererfahrung (Usability, Performance, Responsivität) | IV | C |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Eintrittswahrscheinlichkeit
+
A
+
Häufig
+
+
+
+
+
+
+
+
+
+
B
+
Oft
+
+
+
+
+
+
+
+
C
+
Gelegentlich
+
15
+
+
+
+
+
+
+
D
+
Selten
+
+
+
+
1
+
+
+
+
E
+
Unwahrscheinlich
+
+
+
+
+
+
+
+
F
+
Praktisch Unmöglich
+
+
+
+
+
+
+
+
+
+
IV
+
unbedeutend
+
III
+
klein
+
II
+
kritisch
+
I
+
katastrophal
+
+
+
+
+
+
Tragweite
+
+
+
+
+
+
+
+
+
+5. **Risikominderung**
+
+
+
+
+
+
+
+
+
+
+
+
+
Nr
+
Risiko / Beschreibung / Begründung der Bewertung
+
Auswirkung
+
Häufigkeit
+
+
+
+
+
1
+
Hacking
+
Implementierung einer Firewall, Intrusion Detection Systems (IDS)
+
I
+
D
+
+
+
2
+
Malware (Hochladen von Dateien wie Lebenslauf und Zeugnisse)
+
+
D
+
+
+
3
+
DDoS-Angriffe (lahmlegen, Termine sinnlos buchen)
+
+
D
+
+
+
4
+
Unsichere Passwörter oder Authentifizierungsmechanismen
+
Starke Passwortrichtlinien und Zwei-Faktor-Authentifizierung (2FA)
+
+
+
+
+
5
+
Ausfallzeiten (Server, Netzwerk)
+
Backup-System, Implementierung eines Notfallplans (Disaster Recovery Plan)
+
Automatisierter "Daily-Test" mit einer Pseudo-Anmeldung, wenn diese nicht kommt, dann Warn-E-Mail an Admin
+
+
+
+
+
6
+
Fehlfunktionen der Webseite oder des Content Management Systems (CMS)
Benutzer nicht ignorieren, bzw. als unwichtig taxieren. Durch viele Personen testen lassen
+
IV
+
C
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Eintrittswahrscheinlichkeit
+
A
+
Häufig
+
+
+
+
+
+
+
+
+
+
B
+
Oft
+
+
+
+
+
+
+
+
C
+
Gelegentlich
+
15
+
+
+
+
+
+
+
D
+
Selten
+
+
+
+
1
+
+
+
+
E
+
Unwahrscheinlich
+
+
+
+
+
+
+
+
F
+
Praktisch Unmöglich
+
+
+
+
+
+
+
+
+
+
IV
+
unbedeutend
+
III
+
klein
+
II
+
kritisch
+
I
+
katastrophal
+
+
+
+
+
+
Tragweite
+
+
+
+
+
+
+
+
+
+**Weitere Massnahmen:**
+
+- Regelmässige Schulung von Mitarbeitern im Bereich IT-Sicherheit und Datenschutz
+
+
+
+
+
+6. **Überwachung und Kontrolle**
+
+Die Risiken und die getroffenen Maßnahmen sollten kontinuierlich überwacht werden, da sich die Bedrohungslage ändern kann. Dies beinhaltet regelmäßige Audits und Sicherheitsüberprüfungen sowie die Aktualisierung der Risikoanalyse bei Änderungen an der Webseite, wie z. B. neuen Funktionen oder rechtlichen Rahmenbedingungen.
+
+
+
+7. **Dokumentation und Berichtwesen**
+
+Jede Risikoanalyse sollte gründlich dokumentiert werden. Die Dokumentation enthält eine detaillierte Übersicht über:
+
+- Identifizierte Risiken
+- Bewertungen der Risiken (Wahrscheinlichkeit und Auswirkungen)
+- Getroffene Maßnahmen zur Risikominderung
+- Verbleibende Restrisiken
+
+Zusätzlich sollten regelmäßige Berichte erstellt werden, um die Geschäftsführung oder Verantwortliche auf dem Laufenden zu halten.
+
+
+
+8. **Fazit**
+
+Eine Risikoanalyse für eine Webseite ist ein zentraler Bestandteil der IT-Sicherheitsstrategie und hilft dabei, potenzielle Bedrohungen frühzeitig zu identifizieren und geeignete Gegenmaßnahmen zu treffen. Sie ist nicht statisch, sondern sollte regelmäßig überprüft und aktualisiert werden, um neuen Risiken und Bedrohungen gerecht zu werden.
+
+**Was ist „DDoS"?**
+
+Ein DDoS-Angriff ist eine spezielle Art der [Cyber-Kriminalität](https://www.myrasecurity.com/de/knowledge-hub/cybercrime/). Der Distributed-Denial-of-Service (DDoS) Angriff ist ein „verteilter" Denial-of-Service (DoS) Angriff, der wiederum eine Dienstblockade darstellt. Diese liegt vor, wenn ein angefragter Dienst nicht mehr bzw. nur noch stark eingeschränkt verfügbar ist. Auslöser ist in den meisten Fällen eine mutwillig herbeigeführte Überlastung der IT-Infrastruktur. Angreifer nutzen diese Art der Cyber-Kriminalität, um von ungeschützten Organisationen Lösegelder zu erpressen oder um andere kriminelle Handlungen durchzuführen, zu vertuschen oder vorzubereiten.
+
+{width="5.666666666666667in" height="3.625in"}
+
+
+
+**Was ist „SQL Injection"?**
+
+| {width="3.3229166666666665in" height="2.5416666666666665in"} | {width="4.78125in" height="2.53125in"} |
+|------------------------------|------------------------------------------|
+
+
+
+**Was ist „Cross-Site Scripting"?**
+
+{width="3.4166666666666665in" height="2.5833333333333335in"}
+
+
+
+**Was ist ein Intrusion Detection System (IDS)?**
+
+Ein Intrusion Detection System, abgekürzt IDS, ist in der Lage, auf Computer, Server oder Netzwerke gerichtete Angriffe zu erkennen und darüber zu informieren. Oft ergänzt das Intrusion Detection System die üblichen Funktionen einer Firewall.
+
+{width="3.3333333333333335in" height="3.3333333333333335in"}
+
+Ein Intrusion Detection System erkennt anhand bestimmter Muster selbständig Angriffe auf Computersysteme oder Netzwerke und informiert Anwender oder Administrationen. Ein IDS kann als eigenständige Hardware in einem Netzwerk installiert oder als Softwarekomponente auf einem vorhandenen System realisiert sein. Gegenüber einem so genannten Intrusion Prevention System (IPS) grenzt sich das IDS klar ab, da es Angriffe nur erkennt aber nicht aktiv verhindert und abwehrt.
+
+Die entsprechenden Gegenmaßnahmen bei Angriffen werden von den Administratoren oder von weiteren Systemen aufgrund der Alarmierung durch das IDS eingeleitet. Gegenüber einer reinen Firewall bietet das Intrusion Detection System einen besseren Schutz, da es Angriffe auch nach einem Durchbruch durch die Firewall erkennen kann. Um wirksame Maßnahmen zur Abwehr der Attacke zu treffen, ist es wichtig, dass das IDS genaue Informationen über die Art und die Herkunft des Angriffs liefert. So lassen sich beispielsweise betroffene Services anhalten oder Ports sperren.
+
+{width="9.875in" height="3.8958333333333335in"}
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse.md
new file mode 100644
index 0000000..6b99bfc
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse.md
@@ -0,0 +1,9 @@
+# 2. Anforderngsanalyse
+
+Created: 2024-09-17 11:13:21 +0200
+
+Modified: 2024-09-17 11:13:37 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.1.-Ist-Analyse-=--User.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.1.-Ist-Analyse-=--User.md
new file mode 100644
index 0000000..539d22a
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.1.-Ist-Analyse-=--User.md
@@ -0,0 +1,44 @@
+# 2.1. Ist-Analyse => User
+
+Created: 2024-09-06 12:32:37 +0200
+
+Modified: 2024-09-19 16:33:38 +0200
+
+---
+
+Hier sind Meinungen zur aktuellen Webseite aufgeführt
+
+
+
+
+
+
+
+
+
+
+
Alwin
+
ich finde die Website sehr gut. Mir gefallen die Gliederung und das minimalistische Design. Meiner Meinung nach vermittelt das einen professionellen und schnieken Eindruck. Auch die interaktiven Elemente ergeben für mich Sinn. Ich frage mich nur, ob der "Jetzt bewerben"-Button eventuell direkt oben am Anfang der Seite sein könnte. Im Grossen und Ganzen finde ich die Website inhaltlich sowie gestalterisch gut gemacht.
+
+
+
+
+
Lazar
+
Im Auftrag stand, dass man ein Feedback zur Informatiker Website machen sollte. Da ich nicht genau wusste welche, sah ich mir die Bewerbungsseite an.
+
+
Im Allgemeinen ist die Webseite gut und man kommt auch sehr gut und ohne Probleme mit der Website aus, aber ich würde sagen die Schrift könnte ein wenig grösser sein, weil ich zum Beispiel kann es immer noch lesen aber nicht mit einer grösseren Distanz vom Notebook. Von mir aus wäre dies eigentlich alles, was ich zum Sagen hätte, weil die Website an sich recht gut ist.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.10.-Schnupperlehrbestätigun.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.10.-Schnupperlehrbestätigun.md
new file mode 100644
index 0000000..8f86c1b
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.10.-Schnupperlehrbestätigun.md
@@ -0,0 +1,42 @@
+# 2.10. Schnupperlehrbestätigung (PDF)
+
+Created: 2024-09-30 10:21:21 +0200
+
+Modified: 2024-10-14 13:56:24 +0200
+
+---
+
+Es soll automatisch eine Schnupperlehrbestätigung in Form einer PDF-Datei generiert werden
+
+
+
+Die aktuelle Schnupperlehrbestätigung sieht folgendermassen aus:
+
+
+
+-image1.png){width="6.635416666666667in" height="9.375in"}
+
+
+
+Die eingefärbten Daten haben folgende Bedeutung:
+
+- Nebst dem Logo und der Dateistruktur kann der weisse Text für alle Schnupperlehren verwendet werden. Dies könnte als Ausgangslage in einem Template realisiert werden (Einheitlicher Auftritt der Berufsbildung)
+
+
+- Ausgewählter Beruf (Wenn wir das Geschlecht wüssten, könnten wir die entsprechende Bezeichnung verwenden
+
+
+- Angaben zum jeweiligen Berufsbildner entsprechend dem gewählten Schnupperlehr-Beruf
+
+
+- Vom jeweiligen Berufsbildner definierte Textbausteine entsprechend dem gewählten Schnupperlehr-Beruf
+
+
+- Online-Eingabedaten des Bewerbers
+
+
+- Datum von der Schnupperlehre, bzw. vom letzten Schnupperlehrtag
+
+
+- Effektive Beurteilung => von Hand ausfüllen oder eine Eingabemaske welche der Schnupperlehrbetreuer ausfüllen kann.
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.2.-Interview-BB.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.2.-Interview-BB.md
new file mode 100644
index 0000000..04ea881
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.2.-Interview-BB.md
@@ -0,0 +1,65 @@
+# 2.2. Interview BB
+
+Created: 2024-09-03 08:02:03 +0200
+
+Modified: 2024-09-19 16:33:29 +0200
+
+---
+
+**Interview Berufsbildner (Alfred Albisser)**
+
+****
+
+**Im Folgenden wird der Berufsbildner der Informatiker*in EFZ Fachrichtung Applikations- & Plattformentwicklung wie auch ICT-Fachfrau/-mann EFZ interviewt**
+
+****
+
+1. **Warum soll eine neue Webseite für die ICT-Schnupperlehre realisiert werden?**
+
+**
+
+*Die Webseite ist veraltet und hat vor 10 Jahren mehr oder weniger schon so ausgesehen. Ich denke das der viele Text und 1 Foto heutzutage die junge Generation nicht mehr anspricht.*
+
+*Die Webseite entspricht jedenfalls nicht dem Bild einer innovativen Informatik-Berufsbildung, welche am Puls der Zeit agiert.*
+
+*Auch habe ich 2 unterschiedliche Berufe und ein Beruf davon hat 2 Fachrichtungen. Diese unterschiedlichen Berufe & Fachrichtungen haben Gemeinsamkeiten, aber natürlich auch Unterschiede. Ich muss mich dem Korsett der Berufsbildung unterordnen und dies verwirrt die Informationssuchenden mehr als es ihnen hilft.*
+
+*Dies führt dazu, dass ich fast gezwungen bin Berufserkundungstage durchzuführen, um die Unterschiede erklären zu können damit sich die Schüler für die richtige Schnupperlehre entscheiden können. Manchmal wollen Schüler alle 3 Schnupperlehren machen. Das Organisieren und Durchführen von Berufserkundungstagen und Schnupperlehren kostet sehr viel Zeit und die Nachfrage bei den Informatikern ist sehr gross. Mir ist es nicht möglich alle Anfragen zu berücksichtigen, möchte aber mindestens eine gute Informationsmöglichkeit auf der Webseite bieten.*
+
+**
+
+
+
+2. **Was sollte denn die Webseite Ihrer Meinung nach beinhalten, damit sie dem Zeitgeist entspricht?**
+
+**
+
+*Ich stelle mir folgendes vor:*
+
+1. *Die Berufe sollen online erkundet werden können. Ich möchte den Berufserkundungstag durch das Webseitenangebot ersetzen.*
+2. *Die Lernenden könnten ihre Arbeitsplätze auch in einem Video zeigen, wie auch ihre typischen Arbeiten erklären. Allenfalls könnte man mit AI auch Avatare statt Lernende einsetzen. Aktuell sind nur junge Männer in der Lehre, da könnte man mit Geschlechtern und Rassen einen Diversity-Touch reinbringen.*
+3. *Ich stelle mir auch eine interaktive Erkundungstour vor. Ähnlich wie in einem Escape-Room muss man berufsspezifische Arbeiten erledigen. Wer dies gut und richtig macht, dem gehen neue Türen auf und man erreicht neue Levels (Räume). Viele Schüler die Informatiker werden wollen, sind Gamer. Wenn die Berufserkundung wie ein Game daherkommt (Gamification) steigt der Reiz auch alle Informationen genau zu lesen und zu befolgen. Wer erfolgreich ist kommt zur Schnupperlehranmeldung, wer nicht hat Pech gehabt, besser als nach Bewerbungseingang, Schulniveau oder Wohnort zu filtern.*
+4. *Allenfalls könnte die Erkundungstour und die dabei erreichten Punkte auch als Eignungstest verwendet werden. Bis anhin gab es den ICT-Test, dieser gibt es so nicht mehr. Die entsprechenden Räume und Fragen könnten ja berufs-, bzw. fachspezifisch sein.*
+5. *Cool wäre auch ein ChatGPT-Bot, dem man Fragen zur Berufswahl stellen kann und der einem auf der Webseite als Hilfestellung zur Verfügung steht*
+
+
+
+3. **Wie sollte die Webseite aussehen?**
+
+**
+
+*Mir persönlich ist die Funktionalität wichtig, Hauptsache ich spare Zeit zugunsten der Lernenden in Ausbildung. Beim Aussehen wissen die Jungen wohl besser, was ein paar Jahre noch jüngere cool finden. Wir müssen allerdings allfällige Vorgaben des PSI bezüglich Aussehens und Inhalte berücksichtigen. Das Aussehen und die Inhalte dürfen nicht verletzend sein und keine Sicherheitsrisiken beinhalten.*
+
+**
+
+4. **Gibt es bezüglich der Anmeldung für eine Schnupperlehre Wünsche?**
+
+**
+
+*Ja, aktuell muss ich bei jeder zweiten E-Mail-Bewerbung rückfragen. Zum Teil fehlen Angaben zur Person, Dokumente werden nicht hochgeladen und man gibt mir keinen Termin an. Da frage ich mich manchmal schon, was der ganze Text bringt.*
+
+*Ich finde, dass man einen gewissen Aufwand erwarten darf. Schlussendlich nehmen wir uns Zeit, stellen ein Berufswahlangebot auf die Beine und wollen den Schülern etwas bieten. Es geht ja nicht darum einen Tag lang einem Programmierer beim Programmieren über die Schulter zu schauen. Das kann man einfacher mit einem YouTube-Video abdecken.*
+
+*Ich wünsche mir eine Online-Anmeldung mit Pflichtfeldern und einer Anzeige der verfügbaren Termine. Wer es schafft alle Pflichtfelder auszufüllen, wird für die Schnupperlehre gebucht und erhält automatisch eine Anmeldebestätigung per E-Mail mit weiteren Angaben zu Treffpunkt und Zeit. Wer es nicht schafft, hat halt Pech und hat die erste Berufswahlhürde nicht erklimmen können. Dies wäre wohl auch nicht gerade unser Wunschkandidat. Sind alle Schnupperlehrplätze belegt, wird der entsprechende Termin als ausgebucht gekennzeichnet. Die eingegebenen Daten werden auch in eine Datenbank aufgenommen und stehen später für die Nachvollziehbarkeit und weiteren Berufswahlschritte zur Verfügung.*
+
+*Es wäre auch praktisch, wenn gleich ein Grundgerüst für eine Schnupperlehr-Bestätigung/Beurteilung anhand der Daten erstellt wird, so dass ich lediglich noch meine Eindrücke festhalten muss. Diese Schnupperlehrbeurteilung müsste ich ausdrucken können. Bei einer späteren Bewerbung um eine Lehrstelle, wäre dann der Zugriff auf die Daten dienlich. Es gibt Sachen, die ich jeweils für mich notiere (intern) und Sachen, die auf der effektiven Beurteilung stehen (extern).*
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.3.-Anmeldedaten.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.3.-Anmeldedaten.md
new file mode 100644
index 0000000..ce38816
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.3.-Anmeldedaten.md
@@ -0,0 +1,71 @@
+# 2.3. Anmeldedaten
+
+Created: 2024-09-10 16:52:07 +0200
+
+Modified: 2024-09-19 16:33:23 +0200
+
+---
+
+**Für eine Schnupperlehranmeldung benötige ich aus den folgenden Gründen ...**
+
+- Zutritt ans PSI (Badge)
+- Erreichbarkeit im PSI
+- Automatisiertes Bestätigungsschreiben
+- Adressatenanalyse
+- Dienstleistungs-Angebot optimieren
+
+
+
+**... folgende Angaben:**
+
+- Vorname
+- Nachname
+- Vollständige Adresse
+ - Strasse
+ - Hausnummer
+ - Postleitzahl (CH, D)
+ - Wohnort
+- E-Mail-Adresse (für Einladung)
+- Telefonnummer (Natel, Festnetz)
+- Geburtsdatum
+- Schulstufe => Bezirksschule (Sek A), Sekundarschule, Realschule, 10. Schuljahr, Berufsumsteiger, ...
+- Schulort
+- Textfeld für Motivationsschreiben
+- Für welche Schnupperlehre meldet er sich effektiv an (IF-AE, IF-PE oder ICT)
+
+
+
+**Zusätzlich sind die folgenden Dokumente hochzuladen:**
+
+- Lebenslauf
+- Letztes Schulzeugnis
+
+**Automatisierte Prozesse:**
+
+- Buchungssystem (Aktualisierung "Freie Plätze", ausgebucht, ...)
+- Anmeldebestätigung generieren und per E-Mail versenden => Lesebestätigung auswerten
+- Datenbank aktualisieren (Zeitstempel)
+- Berufsbildner über Bewerbungseingang informieren (Link in Datenbank zwecks Kontrolle)
+- Erinnerungs-E-Mail eine Woche vor Termin
+
+
+
+Anmelde-Hinweise:
+
+- Schnupperlehre wird in deutscher Sprache durchgeführt
+- Den Anweisungen des Personals ist Folge zu leisten
+- Die Schnupperlehre wird mit mehreren Teilnehmern durchgeführt
+- Respektloses Verhalten führt zur Wegweisung vom PSI
+- Diebstahl wird geahndet
+- Es gibt eine schriftliche Teilnahme-Bestätigung am Ende des Tages
+- Es kann nur eine ICT-Schnupperlehre besucht werden
+
+
+
+
+
+**Probleme / Risiken:**
+
+- Was, wenn sich jemand vertippt bei der E-Mail-Adresse => bekommt keine Anmeldebestätigung mit detaillierten Informationen. Kommt er dann? Hat er/sie die Möglichkeit die E-Mail-Adresse zu ändern (wenn ja wie)
+- Mehrfachanmeldung => wie verhindern wir, dass uns jemand verarscht und "leere" Plätze bucht?
+- Was, wenn sich zwei Personen gleichzeitig für den letzten Schnupperlehrplatz anmelden => wie erfährt der eine, dass der letzte Platz gerade weggeschnappt wurde?
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.4.-Handlungskompetenzen.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.4.-Handlungskompetenzen.md
new file mode 100644
index 0000000..11b3803
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.4.-Handlungskompetenzen.md
@@ -0,0 +1,20 @@
+# 2.4. Handlungskompetenzen
+
+Created: 2024-09-17 15:03:52 +0200
+
+Modified: 2024-09-19 16:33:18 +0200
+
+---
+
+Gemäss dem Fachbuch "Fullstack-Entwicklung: Das Handbuch für Webentwickler"
+
+
+
+
+
+Sähe eine mögliche Roadmap folgendermassen aus:
+
+{width="9.010416666666666in" height="4.583333333333333in"}
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.5.-Beobachtung-Anmeldeproze.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.5.-Beobachtung-Anmeldeproze.md
new file mode 100644
index 0000000..f4b48b2
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.5.-Beobachtung-Anmeldeproze.md
@@ -0,0 +1,39 @@
+# 2.5. Beobachtung Anmeldeprozess
+
+Created: 2024-09-19 16:04:07 +0200
+
+Modified: 2024-10-11 14:06:55 +0200
+
+---
+
+**Theorie: Beobachtungstechniken**
+
+Für Situationen, in denen Fachspezialisten nicht die Zeit besitzen, das benötigte Wissen an den Requirements Engineer weiterzugeben, oder nicht fähig sind, dieses Wissen zu formulieren, eignen sich Beobachtungstechniken. Dabei werden die entsprechenden Stakeholder vom Requirements Engineer bei ihrer Arbeit beobachtet, ihre Arbeitsschritte dokumentiert und daraus die vom System zu unterstützenden Arbeitsabläufe, aber auch potenzielle Fehler, Risiken und offene Fragen
+
+ermittelt. Dies alles sind potenzielle Kandidaten, um daraus Anforderungen zu formulieren. Die Stakeholder können dem Requirements Engineer ihr Wissen hierbei aktiv in der Anwendung demonstrieren oder nur beobachtet werden. Dabei sollte der Requirements Engineer die beobachteten Abläufe hinterfragen, um die Soll-Situation zu ermitteln, da ansonsten die Gefahr besteht, dass viele veraltete Technologie-Entscheidungen und suboptimale Prozesse (Ist-Situation) dokumentiert werden. Als externer Beobachter hat der Requirements Engineer gute Chancen, ineffiziente Prozesse zu erkennen und bessere Lösungen vorzuschlagen.
+
+Er besitzt mehr Abstand zum gelebten Prozess als die Stakeholder, die häufig aus Gewohnheit ihre Arbeitsschritte wiederholen, ohne sie kritisch zu reflektieren. Beobachtungstechniken eignen sich gut dazu, detaillierte Anforderungen und Basisfaktoren zu ermitteln, denn der Requirements Engineer nimmt Basisfaktoren wahr, die viele Stakeholder als bekannt voraussetzen oder nur unterbewusst kennen. Außerdem lernt der Requirements Engineer dabei den jeweiligen Fachjargon,
+
+was weitere Befragungen erleichtert. Leistungsfaktoren können nur beobachtet werden, wenn sie bereits im gelebten Prozess oder Vorgängersystem umgesetzt sind, deshalb eignet sich diese Technik nicht bei völlig neuen Prozessen. In der Systementwicklung eignen sich insbesondere die Feldbeobachtung und das »Apprenticing« als Ermittlungstechniken.
+
+
+
+- Feldbeobachtung
+
+Der Requirements Engineer ist vor Ort bei den Spezialisten bzw. Anwendern des Systems und beobachtet und dokumentiert unmittelbar die stattfindenden Prozesse, Handgriffe und Arbeitsabläufe. Aus diesen Beobachtungen ermittelt er die Anforderungen. Häufig wird dies durch Audio- oder Videoaufzeichnungen unterstützt. Diese Technik ist gut geeignet bei sprachlich schwer vermittelbaren Arbeitsabläufen, jedoch nur bei wirklich beobachtbaren Abläufen.
+- Apprenticing
+
+Das Apprenticing (»in die Lehre gehen«) erfordert vom Requirements Engineer, dass er die Tätigkeiten der Stakeholder konkret erlernen und ausführen muss. Wie ein Lehrling wird der Requirements Engineer aufgefordert, unklare und unverständliche Handlungsschritte sofort zu hinterfragen, um in dem Bereich Erfahrung zu sammeln. Er kann hierdurch Anforderungen erfahren, die für den Stakeholder so selbstverständlich sind, dass er sie nicht mehr äußert. Ein weiterer Vorteil ist, dass das typische Machtverhältnis zwischen dem fragenden Requirements Engineer und dem antwortenden
+
+Spezialisten umgekehrt wird, denn der Stakeholder nimmt nun die Rolle des »Meisters« ein, der Wissen hat, das dem Lehrling noch fehlt.
+
+
+
+Die Entwickler beobachten die Arbeitsschritte und den Prozessablauf einer Schnupperlehranmeldung bei der zuständigen Sekretärin des ICT-Berufes.
+
+
+
+1. Arbeitsprozess anhand 2 verschiedenen E-Mail-Anfragen beobachten und sich Notizen machen
+2. Verständnis-Fragen stellen
+3. Wünsche und Ideen aufnehmen
+4.
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.6.-Workshop--BE-Tag-.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.6.-Workshop--BE-Tag-.md
new file mode 100644
index 0000000..f5cf0a0
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.6.-Workshop--BE-Tag-.md
@@ -0,0 +1,85 @@
+# 2.6. Workshop "BE-Tag"
+
+Created: 2024-09-18 16:46:48 +0200
+
+Modified: 2024-10-11 14:08:15 +0200
+
+---
+
+Am 26. September findet ein Berufserkundungstag mit 10 Schülern statt.
+
+
+
+Wir planen an diesem Tag 1h ein, um einen Workshop mit den Schüler*innen zu machen. Das Ganze soll eine Win-Win-Situation für beide Seiten sein. Die Schüler*innen sehen den Sinn & Zweck dahinter und lernen dabei einen wichtigen Entwicklungsprozess kennen. Im Gegenzug erhalten wir Informationen, um auf ihre Bedürfnisse eingehen zu können:
+
+
+
+- Wer fühlt sich Berufswahlreif?
+
+
+- Wegen welchem Beruf bist du hierhergekommen? ICT-FM, IF-PE, IF-AE, MM, ICT-Allg, das geringste Übel, das Erstbeste, meine Freunde sind hier, Hauptsache PSI, ...
+
+
+
+- Welches Hobby würdet du gerne zum Beruf machen?
+
+
+
+- Was empfinden die Schüler*innen, wenn sie persönliche Angaben Online machen müssen? Welche Bedenken haben sie und was könnte diese Bedenken mindern? Was sind für euch "No Goes"
+
+
+
+- Wie sehen die Schüler*innen das aktuelle Berufswahlverfahren?
+ - Terminplanung
+ - Unterstützung Schule / Lehrer
+ - Unterstützung Familie / Bekannte
+
+
+
+- Was hilft dir beim bestehenden (Online-) Angeboten?
+ - Wer war beim Ask?
+ - Wer war auf Lena?
+
+
+
+- Wie wichtig ist es ihnen in einen Betrieb zu kommen? Spielt der Ausbildungsbetrieb für die Berufsfindung eine Rolle?
+
+
+
+- Wer ist in der Pflicht ein Angebot bereit zu stellen? Für wie viele Schüler*innen?
+
+
+
+- Was darf der Ausbildungsbetrieb von den Schüler*innen erwarten? Was muss er sich nicht gefallen lassen?
+
+
+
+- Was würdest du vermissen, wenn du die Berufe Online in einer Virtuellen Welt erkunden könntest und so zu den gleichen Informationen kämst?
+
+
+
+- Was wäre wenn die Berufserkundung als Online-Spiel stattfinden würde, wo es einen Punkte-Score gibt und nur diejenigen die einen Mindest-Score erreicht haben, sich für eine Schnupperlehre anmelden könnten?
+
+PS: Der Mindest-Score erreicht man, indem man die Online-Berufserkundung durchgeführt hat und einfache Fragen dazu beantworten kann?
+
+
+
+- Was wäre wenn man einen Eignungstest, z.B. in Form eines virtuellen Escape-Rooms durchlaufen könnte. Man geht in einen virtuellen Berufsraum und muss dort verschiedene berufsspezifische Aufgaben lösen. Die Anzahl Punkte entsprächen in etwas der Eignung für die erkundeten Berufe?
+
+
+- Wie viele Tage sollte eine Schnupperlehre dauern?
+ - Ohne eigene Aktivitäten => mehr oder weniger zuschauen und hinterherlaufen
+ - Mit eigenen praktischen Aktivitäten => Wissensvermittlung und praktische Umsetzung
+
+
+
+- Wer weiss worauf es bei einer Bewerbung drauf ankommt? Wann beginnt die Bewerbung? Wo und wann hinterlasse ich erste prägende Eindrücke?
+
+
+- Wie häufig liest du deine E-Mails? Was ist deine durchschnittliche Reaktionszeit um ein E-Mail zu beantworten?
+
+
+
+Die Ermittlung kann mit Papier, mit Findme oder über eine Smartphone-App realisiert werden.
+
+Die Auswertung müsste hier Einzug finden
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.7.-Auswertung-Umfrage-26.9..md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.7.-Auswertung-Umfrage-26.9..md
new file mode 100644
index 0000000..4fcb836
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.7.-Auswertung-Umfrage-26.9..md
@@ -0,0 +1,283 @@
+# 2.7. Auswertung Umfrage 26.9.24
+
+Created: 2024-09-30 09:38:01 +0200
+
+Modified: 2024-10-16 16:10:54 +0200
+
+---
+
+**Teilnehmer vom Berufserkundungstag am 26. September 2024**
+
+| Zeitstempel | Vorname: |
+|-------------------:|--------------|
+| 9.26.2024 15:21:04 | Matteo |
+| 9.26.2024 15:22:44 | Mateo |
+| 9.26.2024 15:22:45 | Alexander |
+| 9.26.2024 15:23:52 | Leon Tessaro |
+| 9.26.2024 15:23:56 | Nando |
+| 9.26.2024 15:24:01 | Ann-Fabienne |
+| 9.26.2024 15:25:32 | Kanina |
+| 9.26.2024 15:28:14 | Alper |
+
+(Jemand hat das Quiz nicht ausgefüllt)
+
+
+
+**Wie Berufswahlreif fühlst du dich?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Wegen welchem Beruf bist du hierhergekommen?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Welches Hobby würdest du gerne zum Beruf machen?**
+
+| Sachen gestalten |
+|-------------------------------------------|
+| Unihockey |
+| Programmieren |
+| Fussball |
+| Modellflug |
+| Tennis und Klavier spielen |
+| Mit Freunde rausgehen ( kontaktfähigkeit) |
+| In ein Programmierkurs |
+
+
+
+**Wie wohl fühlst du dich dabei, persönliche Daten online anzugeben?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Welche Bedenken hast du, wenn du persönliche Informationen online teilen musst?**
+
+| Dass sie geklaut werden |
+|-----------------------------------------------------------------------|
+| Gehackt oder Virus |
+| |
+| Das man gehackt werden kann. |
+| was machen sie mit den daten |
+| Ich habe schon Bedenken, zB. Adresse, E-Mail, Telefonnummer |
+| Ich möchte nicht so gerne das die meisten Menschen die ich nicht kenne oder so Sachen über mich weissen. |
+| Ich will gar keine Information bei Webseiten abgeben weil sie mir virusen oder geld nehme |
+
+
+
+**Was sind für dich absolute „No Goes" beim Umgang mit deinen persönlichen Daten online?**
+
+| |
+|--------------------------------------------------------------------|
+| konto Daten ausser man kauft was |
+| |
+| Das man die Telefonnummer anderen gibt ohne die Person zu fragen der die Nummer gehört. |
+| Fotos an unbekannte Personen schicken |
+| |
+| Das jemand sie z.B. weiterleitet. Oder wenn sie mein Geschlecht usw. sagen. |
+| Nummer von bankkarte, Adresse |
+
+
+
+**Wie schwierig ist das aktuelle Berufswahlverfahren für dich?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Ist die Terminplanung dabei ein grosses Problem?**
+
+{width="5.0in" height="2.09375in"}
+
+
+
+**Wie viel Unterstützung bekommst du bei der Berufswahl von der Schule?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Wie viel Unterstützung bekommst du bei der Berufswahl von deinen Eltern?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Bei welchen Berufswahlhilfe-Angeboten warst du bereits?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Wie wichtig ist es dir in einen Betrieb zu kommen?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Spielt der Ausbildungsbetrieb für die Berufsfindung eine Rolle?**
+
+{width="5.0in" height="2.09375in"}
+
+
+
+**Wer ist in der Pflicht ein Angebot bereit zu stellen?**
+
+{width="5.0in" height="2.375in"}
+
+
+
+**Was darf der Ausbildungsbetrieb von den Schüler*innen erwarten?**
+
+| |
+|----------------------------------------------------------------|
+| Freundlich, Innteressiert, gewisse Leistungen also nicht übertrieben aber so 4.5 oder so |
+| Anstand und Aufmerksamkeit |
+| Respekt und höflichkeit |
+| respekt |
+| Das man gut mitmacht und lernt. |
+| Das sie z.B. gut im Teamarbeiten können oder sie sind hilfsbereit. |
+| Pünktlich sein, Repekt haben, Geduld, wissen über den Beruf. |
+
+
+
+**Was muss der/ die Schüler*innen sich nicht gefallen lassen?**
+
+| |
+|--------------------------------------|
+| Zu hohe Erwartungen |
+| |
+| Schlecht behandelt zu werden |
+| |
+| |
+| Wenn jemand sie falsch unterschätzt. |
+| Wenn Sie Ihn beleidigen |
+
+
+
+**Was würdest du vermissen, wenn du die Berufe Online in einer Virtuellen Welt erkunden könntest und so zu den gleichen Informationen kämst?**
+
+| Nichts |
+|--------------------------------------|
+| Eltern, Freunde, Unihockey |
+| Den beruf richtig ausüben zu können. |
+| Nichts |
+| man hat niemand um sich |
+| Von Mensch zu Mensch reden |
+| Nichts. |
+| Nichts |
+
+
+
+**Was wäre wenn die Berufserkundung als Online-Spiel stattfinden würde, wo es einen Punkte-Score gibt und nur diejenigen die einen Mindest-Score erreicht haben, sich für eine Schnupperlehre anmelden könnten?**
+
+| Wäre toll |
+|---------------------------------------------------------|
+| Würde ich Punkte sammeln |
+| Das nicht jeder eine Schnupperlehre bekommt |
+| Es wäre nicht schlecht wenn es um den Beruf geht um den man sich bewirbt. |
+| speziell aber spannend |
+| Interessant |
+| Das wäre vielleicht nicht so toll. |
+| Also es wäre gut weil man dan weiss wer was kann . |
+
+
+
+**Was wäre wenn man einen Eignungstest, z.B. in Form eines virtuellen Escape-Rooms durchlaufen könnte. Man geht in einen virtuellen Berufsraum und muss dort verschiedene berufsspezifische Aufgaben lösen. Die Anzahl Punkte entsprächen in etwas der Eignung für die erkundeten Berufe?**
+
+| Es wäre schlau |
+|-----------------------------------------------------|
+| Ist okay ich würde mitmachen |
+| |
+| |
+| were ich dabei |
+| Das wäre sehr cool. |
+| Das wäre vielleicht etwas so praktisches oder so weiss jetzt auch nicht. |
+| - |
+
+
+
+**Wie viele Tage sollte eine Schnupperlehre dauern, in welcher man nur zuschaut und hinterherläuft?**
+
+{width="5.0in" height="2.09375in"}
+
+
+
+**Wie viele Tage sollte eine Schnupperlehre dauern, in welcher man auch praktische Umsetzungen durchführt usw.?**
+
+{width="5.0in" height="2.2604166666666665in"}
+
+
+
+**Worauf kommt es bei einer Bewerbung drauf an? Wann beginnt die Bewerbung? Wo und wann hinterlasse ich erste prägende Eindrücke?**
+
+
+
+
+
+
+
+
Dass sie schön und ohne Rechtschreibfehler ist.
+
Anfang Sommerferien.
+
Beim Bewerbungsgespräch.
+
+
+
+
+
Freundlich sein offen sein
+
+
+
+
+
+
Man sollte höflich sein beim Bewerbungsgespräch.
+
+
+
+
+
+
+
+
+
Ich würde wie in der Mitte so am Mittelpunkt halt z.B. deine Lieblingsfächer sagen deine Hobbys usw.
+
+
+
-
+
+
+
+
+
+
+**Wie häufig liest du deine E-Mails?**
+
+{width="5.0in" height="2.09375in"}
+
+
+
+**Was ist deine durchschnittliche Reaktionszeit um ein E-Mail zu beantworten?**
+
+{width="5.0in" height="2.09375in"}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.8.-Anmeldebestätigung-(PDF).md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.8.-Anmeldebestätigung-(PDF).md
new file mode 100644
index 0000000..3aae670
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.8.-Anmeldebestätigung-(PDF).md
@@ -0,0 +1,40 @@
+# 2.8. Anmeldebestätigung (PDF)
+
+Created: 2024-09-30 10:21:21 +0200
+
+Modified: 2024-10-14 15:10:32 +0200
+
+---
+
+Es soll automatisch eine Anmeldebestätigung in Form einer PDF-Datei generiert werden
+
+
+
+Die aktuelle Anmeldebestätigung sieht folgendermassen aus:
+
+-image1.png){width="5.4375in" height="7.666666666666667in"}
+
+
+
+Die eingefärbten Daten haben folgende Bedeutung:
+
+- Nebst dem Logo und der Dateistruktur kann der weisse Text für alle Schnupperlehren verwendet werden. Dies könnte als Ausgangslage in einem Template realisiert werden (Einheitlicher Auftritt der Berufsbildung)
+
+
+- Ausgewählter Beruf (Wenn wir das Geschlecht wüssten, könnten wir die entsprechende Bezeichnung verwenden
+
+
+- Angaben zum jeweiligen Berufsbildner entsprechend dem gewählten Schnupperlehr-Beruf
+
+
+- Vom jeweiligen Berufsbildner definierte Textbausteine entsprechend dem gewählten Schnupperlehr-Beruf
+
+
+- Online-Eingabedaten des Bewerbers
+
+
+- Aktuelles Anmeldedatum
+
+
+- Vom Berufsbildner definiertes Schnupperlehrangebot und vom Bewerber effektiv gewähltes Datum der Schnupperlehre
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.9.-Anmeldebestätigung-(E-Ma.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.9.-Anmeldebestätigung-(E-Ma.md
new file mode 100644
index 0000000..0550943
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/2.-Anforderngsanalyse/2.9.-Anmeldebestätigung-(E-Ma.md
@@ -0,0 +1,78 @@
+# 2.9. Anmeldebestätigung (E-Mail)
+
+Created: 2024-10-14 11:25:32 +0200
+
+Modified: 2024-10-14 12:33:21 +0200
+
+---
+
+Es soll automatisch eine Anmeldebestätigung per E-Mail generiert werden
+
+
+
+Die aktuelle Anmeldebestätigung (Screenshot) sieht folgendermassen aus:
+
+-image1.png){width="11.895833333333334in" height="6.53125in"}
+
+
+
+
+
+
+
+
+
+
+
Absender
+
+
E-Mail von meiner E-Mail-Adresse senden, so dass man mir direkt antworten kann
+
+
+
+
+
+
E-Mail-Signatur
+
+
+
+
+
+
+
+
+
Adressat
+
Schnupperlehr-Bewerber gemäss E-MAIL (gespeichert in der Datenbank)
+
+
+
Betreff
+
PSI-Schnupperlehrbestätigung im BERUF am TERMIN
+
+
+
Anrede
+
Hallo VORNAME
+
+
+
Inhalt
+
Text-Baustein "Bla bla … BERUF + TERMIN … bla bla"
+
+
+
Anhang
+
+
Generiertes PDF mit Schnupperlehr-Bestätigung
+
+
+
+
+
+
PSI-Anfahrtsplan
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas.md
new file mode 100644
index 0000000..bc86fd6
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas.md
@@ -0,0 +1,9 @@
+# 3. Personas
+
+Created: 2024-09-17 11:12:59 +0200
+
+Modified: 2024-09-17 11:13:06 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.1.-Rollen.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.1.-Rollen.md
new file mode 100644
index 0000000..c5d172a
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.1.-Rollen.md
@@ -0,0 +1,43 @@
+# 3.1. Rollen
+
+Created: 2024-09-18 17:35:26 +0200
+
+Modified: 2024-09-24 08:11:09 +0200
+
+---
+
+Anhand all der Stakeholder definieren wir hier die verschiedenen Benutzer-Rollen
+
+
+
+- ADMIN
+
+Zu den Administratoren gehören in erster Linie die Entwickler
+
+
+
+- SERVICE
+
+Die eigentlichen Anbieter sind die PSI-Lehrberufe, also alle Berufsbildner und die Leitung Berufsbildung.
+
+Diese Gruppe bearbeiten den Inhalt der Webseite. Sie stellen ein Angebot zur Verfügung welches stets aktualisiert werden muss und nur von ihnen bestimmt werden kann.
+
+
+
+- END-USER
+
+Die End-Anwender sind, diejenigen Personen welche unser Dienstleistungsangebot nutzen wollen. Dazu gehören, Schüler*innen, Lehrer, Eltern, ...
+
+
+
+- EXPERT
+
+Wir brauchen Experten um zu lernen und Profis zu werden. Sie müssen einen Zugang ins System erhalten, um hinter die Kulissen schauen zu können und uns Feedback geben zu können. Dazu brauchen sie Zeit und müssen auch über den Zeitpunkt selbst bestimmen können. Im Prinzip reichen dazu Leserechte.
+
+- DELIVERY
+
+Wir sind auf Dienstleistungen anderer angewiesen und haben ihnen gegenüber auch eine Rechenschaftspflicht. Zu dieser Rolle gehören die internen und externen Anbieter von Servern, Datenbank, SW-Tools mit Benutzer-Accounts, ... Sie müssten Zugriff auf ihren Bereich haben.
+
+Es wäre auch denkbar, dass ein Admin sich einloggt und den Bildschirm teilt oder Remote-Zugriff erlaubt.
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.2.-Persona-=--Fritz,-2.-Sek.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.2.-Persona-=--Fritz,-2.-Sek.md
new file mode 100644
index 0000000..64da33a
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.2.-Persona-=--Fritz,-2.-Sek.md
@@ -0,0 +1,58 @@
+# 3.2. Persona => Fritz, 2. Sek
+
+Created: 2024-09-03 08:01:36 +0200
+
+Modified: 2024-09-20 16:46:25 +0200
+
+---
+
+
+
+
+
+
+
+
+
+
+
+
Fritz ist 14 Jahre alt und wohnt in Brugg
+
+
+
+
+
Berufsbild
+
Er ist im August neu in die 2. Sekundarschule gekommen
+
+
+
Familienstand
+
Fritz wohnt mit seiner älteren Schwester die in die Kanti geht und den Eltern zusammen.
+
Die Mutter hat einen Teilzeitjob im KV-Bereich und sein Vater arbeitet als Einkäufer in einer renommierten Firma.
+
+
+
Bedürfnisse
+
Er hat von seinem Lehrer den Auftrag bekommen, sich mit der Berufswahl auseinander zu setzen. Ihm steht in der dritten Septemberwoche eine volle Woche für die Berufswahl zur Verfügung. Er muss nun Firmen anfragen, ob er die ganze Woche oder einzelne Tage bei ihnen eine Schnupperlehre machen kann. Er kann Montag und Dienstag in der Firma seines Vaters 2 Tage als Raumpfleger schnuppern. Aber eigentlich möchte Fritz lieber einen Beruf erlernen wo der Computer sein Arbeitsinstrument ist.
+
+
+
Ziele
+
Auf der PSI- Webseite hat er auch den Beruf ICT-Fachmann entdeckt. Er ist sich noch nicht im Klaren worin sich diese Berufe im Detail unterscheiden und beim Informatiker gibt es sogar unterschiedliche Fachrichtungen, den Applikations- und den Plattformentwickler. Von seinem Onkel hat er schon einiges vom PSI gehört, da dieser mal dort gearbeitet hat und immer wieder von den interessanten Forschungsprojekten erzählt bei denen er mitgewirkt hat. Daher möchte Fritz unbedingt eine Schnupperlehre am PSI machen. So bekäme er sowohl in die Berufe wie auch in das Forschungsinstitut einen Einblick.
+
Per E-Mail hat er nun eine Anfrage nach einer Schnupperwoche gestellt. Am liebsten würde er die ganze Woche ans PSI kommen um alle ICT-Berufe kennen zu lernen und auch um nicht mehr weiter nach Schnupperlehrplätzen suchen zu müssen.
+
+
+
Motivation
+
Fritz interessiert sich sowohl für Computer-Hardware wie auch für die Programmierung von SW-Applikationen. In der Schule hat er schon mit Scratch gearbeitet und mit seinem Onkel hat er auch schon einen ferngesteuerten Roboter gebaut und einen Arduino programmiert. Er kann stundenlang mit seinen Kollegen gamen. Dafür hat er an Weihnachten zu Hause selbst einen Gaming-PC zusammengebaut. Die notwendigen Komponenten hat er selbst evaluiert und er durfte sich die Komponenten als Weihnachtsgeschenk bestellen. Daher ist klar, dass er Informatiker werden will.
+
In der Schule behagt im nebst Mathematik und Englisch auch das Fach "Medien und Informatik".
+
+
+
+
+
+
+*Die Vorstellungen von Fritz sind:*
+
+
+
+*Fritz geht auf die Webseite vom PSI und findet dort die beiden Berufe Informatiker EFZ und ICT-Fachmann EFZ, welche ihn interessieren. Sie bilden beim Informatiker sogar beide Fachrichtungen aus. Die jeweiligen Berufsbilder sind nicht nur beschrieben, es gibt auch Videos von den Lernenden. Diese erklären ihren Arbeitsalltag und man bekommt einen Einblick von ihrem Arbeitsplatz. Auch demonstrieren sie einige Arbeiten die sie gemacht haben. Fritz findet es cool, welche Kompetenzen sich die Lernenden angeeignet haben und wie integriert sie bereits nach kurzer Zeit sind. Auf der Webseite gibt es auch knifflige Aufgaben zu lösen. Als Gamer gefällt ihm dies sehr und er fühlt sich richtig angespornt, eine gute Punktzahl zu erreichen. Am Ende bekommt er sogar eine Auswertung gezeigt, die ihm seine Stärken aufzeigt. Während er im Bereich als Plattformentwickler durchschnittlich abgeschnitten hat, hat er sowohl als ICT-Fachmann wie auch als Applikationsentwickler sehr gut abgeschnitten.*
+
+*Fritz hat ein sehr gutes Bild von den ICT-Berufen gewonnen und das PSI als Lehrbetrieb überzeugt ihn vollends. Er möchte unbedingt mehr davon sehen. Fritz kann der Webseite entnehmen, dass die Schnupperlehren einen identischen Teil haben, wo es um das Vorstellen vom PSI, den Rundgang am PSI, die Berufslehre am PSI und das Bewerbungsverfahren geht. Leider kann das PSI nicht jedem Schüler eine Schnupperlehre in jedem einzelnen Beruf ermöglichen. Sie möchten verständlicherweise lieber 3 Schülern einen Einblick ermöglichen als einem Schüler 3 Einblicke und daher muss man sich für einen der ICT-Berufe entscheiden. Da Fritz gerne die BM machen möchte und ihn die SW-Entwicklung besonders anspricht ist klar, dass er eine Schnupperlehre als Informatiker mit Fachrichtung Applikationsentwicklung machen will. Er füllt die geforderten Eingabefelder für die Schnupperlehr-Anmeldung aus und lädt sein aktuelles Schulzeugnis hoch. Er sieht welche Termine generell zur Verfügung stehen und auch ob sie ausgebucht sind oder nicht. Leider gibt es keinen Termin in der Woche, welche der Lehrer bestimmt hat. Die Schule unterstützt und ermöglicht es den Schülern für die Berufswahl auch andere Termine wahrzunehmen. Fritz muss einfach vor der Schnupperlehre eine Einladung und nach der Schnupperlehre eine Bestätigung vorweisen, dass er den Termin auch wahrgenommen hat. Fritz wählt einen für ihn passenden Termin aus und sendet die Anmeldung ab. Kurz danach geht bei ihm ein E-Mail ein und der Termin wird bestätigt. Er bekommt im Anhang ein PDF mit allen notwendigen Angaben gesendet. Dies kann er morgen gleich mit zur Schule nehmen und dem Lehrer abgeben. Er weiss nun wann er wo sein muss, wen er verlangen muss und was er alles mitnehmen muss. Als Fritz die Webseite verlassen will, sieht er, dass er Glück gehabt hat. Der von ihm gewählte Termin ist nun ausgebucht. Fritz freut sich auf die Schnupperlehre und dass er in der Berufswahl ein grosses Stück weitegekommen ist. 😊*
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.3.-Persona-=--Birgit,-Hausf.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.3.-Persona-=--Birgit,-Hausf.md
new file mode 100644
index 0000000..7490257
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/3.-Personas/3.3.-Persona-=--Birgit,-Hausf.md
@@ -0,0 +1,32 @@
+# 3.3. Persona => Birgit, Hausfrau
+
+Created: 2024-09-03 08:01:36 +0200
+
+Modified: 2024-09-18 17:35:17 +0200
+
+---
+
+
+
+| {width="0.7395833333333334in" height="0.875in"} | *Brigit ist 38 Jahre alt und wohnt in einem Einfamilienhaus in Birmenstorf* |
+|---------------|---------------------------------------------------------|
+| *Berufsbild* | *Birgit ist Hausfrau. Sie hat früher als Kauffrau gearbeitet. Nach der Geburt des 3. Kindes hat sie das Teilzeitpensum aufgegeben und widmet sich nun ausschliesslich um die Familie und das Haus.* |
+| *Familienstand* | *Birgit ist Mutter von 3 Kindern, Thomas 16 Jahre (Kanti), Eva 14 Jahre (2. Bezirksschule) und Kevin 12 Jahre (6. Klasse)* |
+| *Bedürfnisse* | *Eva hat von ihrem Lehrer den Auftrag bekommen sich mit der Berufswahl auseinanderzusetzen und muss nun nach Schnupperlehrplätzen suchen. Eva hat aber keine Lust dazu. Da sie eine gute Schülerin ist, will sie wie ihr älterer Bruder an die Kanti gehen. Daher nimmt sich die Mutter dieser Aufgabe an und recherchiert zu verschiedenen Berufe und Ausbildungsbetriebe die in Frage kommen könnten.* |
+| *Ziele* | *Birgit möchte, dass Eva keine Probleme in der Schule bekommt und sich ernsthaft mit dem Berufs- & Arbeitsleben auseinandersetzt. Auch sie wird irgendwann arbeiten gehen müssen, um ein Einkommen zu erlangen. Auch ist noch nicht klar welche Richtung sie an der Kanti machen will. Da könnte eine Schnupperlehre auch eine Entscheidungshilfe sein.* |
+| *Motivation* | *Birgit kann sich vorstellen in ein paar Jahren zurück ins Berufsleben zu wechseln. Sie interessiert sich daher auch persönlich für die aktuellen Berufe. Sie hat als Kauffrau viel am Computer gearbeitet und sie war häufig erste Ansprechperson bei Computerproblemen. Sie gestaltet auch gerne in ihrer Freizeit Dokumente und kreiert auch eigene Geburtstagskarten.* |
+
+
+
+*Die Vorstellungen von Birgit sind:*
+
+
+
+*Birgit möchte für Eva die Sache in die Hand nehmen und ihr einen interessanten Schnupperlehrplatz verschaffen. Von ihrem Schwager hat sie erfahren, dass das PSI bekannt ist für seine gute Berufsbildung und auch später nach dem Studium eine gute Adresse sein könnte.*
+
+*Birgit stöbert auf der Webseite der Berufsbildung und ihr Fokus liegt auf dem Finden eines geeigneten Schnupperlehr-Termines. Sie wünscht sich eine Liste zu finden, wo nach Terminen all die angebotenen Schnupperlehren zu finden sind. Nebst dem Termin interessiert sie auch der Beruf und die Dauer der Schnupperlehre, wie auch ein Link zur Online-Anmeldung. Sie hat eigentlich keine Lust jeden Beruf einzeln durchzugehen und die Termine innerhalb der Berufsbeschreibung herauszufinden und für sich selbst eine Liste zu erstellen. Im heutigen Computer-Zeitalter sollte es doch möglich sein, eine solche Liste zu generieren. Es sind ja alle Informationen vorhanden, es müsste nur jemand so weit denken. Sie entschliesst sich danach zu suchen und gibt die Begriffe "PSI Angebot Übersicht Schnupperlehre" ein und siehe da, das PSI hat wirklich weiter gedacht als andere und liefert die gewünschten Angaben. Es gibt sogar eine Sortierfunktion nach Berufen und nach Datum. Auch die Verfügbarkeit wird angezeigt.*
+
+*Birgit sieht, dass es in der vom Lehrer festgelegten Berufswahlwoche 2 verfügbare Angebote gibt, eines als Laborantin Chemie und eines als Informatikerin mit Fachrichtung Applikationsentwicklung. Sie entscheidet sich für das Informatikerin-Angebot und meldet unkompliziert ihre Tochter an.*
+
+*😊*
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases.md
new file mode 100644
index 0000000..d1f1f12
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases.md
@@ -0,0 +1,118 @@
+# 4. Use Cases
+
+Created: 2024-09-16 15:36:06 +0200
+
+Modified: 2024-09-17 11:13:51 +0200
+
+---
+
+Use Case - das Verhalten eines Systems aus Anwendersicht beschreiben
+
+
+
+**Schablone zur Spezifikation eines Use Case**
+
+
+
+
+
+
+
+
+
+
+
+
Nr.
+
Abschnitt
+
Inhalt/Erläuterung
+
+
+
+
+
1
+
Use Case Nummer
+
Eindeutiger Bezeichner des Use Case
+
+
+
2
+
Name
+
Eindeutiger Name für den Use Case
+
+
+
3
+
Autoren
+
Namen der Autoren, die an dieser Use-Case-Beschreibung mitgearbeitet haben
+
+
+
4
+
Priorität
+
Wichtigkeit des Use Case gemäß der verwendeten Priorisierungstechnik
+
+
+
5
+
Kritikalität
+
Kritikalität des Use Case, z.B. hinsichtlich des Schadensausmaßes bei Fehlverhalten des Use Case
+
+
+
6
+
Quelle
+
Bezeichnung der Quelle ([Stakeholder | Dokument | System]), von der der Use Case stammt
+
+
+
7
+
Verantwortlicher
+
Der für diesen Use Case verantwortliche Stakeholder
+
+
+
8
+
Kurzbeschreibung
+
Komprimierte Beschreibung des Use Case
+
+
+
9
+
Auslösendes
+
Ereignis
+
Angabe des Ereignisses, das den Use Case auslöst
+
+
+
10
+
Akteure
+
Auflistung der Akteure, die mit dem Use Case in Beziehung stehen
+
+
+
11
+
Vorbedingung
+
Eine Liste notwendiger Voraussetzungen, die erfüllt sein müssen, bevor die Ausführung des Use Case beginnen kann
+
+
+
12
+
Nachbedingung
+
Eine Liste von Zuständen, in denen sich das System unmittelbar nach der Ausführung des Hauptszenarios befindet.
+
+
+
13
+
Ergebnis
+
Beschreibung der Ausgaben, die während der Ausführung des Use Case erzeugt werden
+
+
+
14
+
Hauptszenario
+
Beschreibung des Hauptszenarios eines Use Case
+
+
+
15
+
Alternativszenarien
+
Beschreibung von Alternativszenarien des Use Case oder lediglich Angabe der auslösenden Ereignisse. Hier gelten oftmals andere Nachbedingungen als in (12) enthalten.
+
+
+
16
+
Ausnahmeszenarien
+
Beschreibung von Ausnahmeszenarien des Use Case oder lediglich Angabe der auslösenden Ereignisse. Hier gelten oftmals andere Nachbedingungen als in (12) enthalten.
Über das Login wird festgestellt, ob eine Person die Berechtigung hat Inhalte auf ihrer berufsspezifischen Webseite anzupassen
+
+
+
Auslösendes
+
Ereignis
+
Auf der Startseite wird Login gewählt
+
+
+
Akteure
+
Berufsbildner
+
+
+
Vorbedingung
+
Die Webseite funktioniert und ist von extern zugänglich
+
+
+
Nachbedingungen
+
Nach erfolgreicher Authentifizierung und Autorisierung wird der nachfolgende Post-Prozess gestartet (als eigene Use Cases definiert) ausgelöst:
+
+
Die Bearbeitungsseite für den jeweiligen Beruf wird angezeigt
+
+
+
+
Ergebnis
+
Der Berufsbildner kann die Inhalte bearbeiten
+
+
+
Hauptszenario
+
+
Neue Schnupperlehr-Termine eingeben
+
Die verschiedenen Text-Bausteine bearbeiten
+
Speichern
+
+
+
+
Alternativszenarien
+
+
Der Berufsbildner verlässt die Seite ohne die Inhalte zu bearbeiten
+
+
+
+
Ausnahmeszenarien
+
+
System hängt => Timeout
+
Kein Zugriff auf Datenbank => Fehlermeldung
+
+
+
+
Qualitäten
+
Im Ermessen des jeweiligen Berufsbildners
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.3.-UC--SL-Anmeldung.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.3.-UC--SL-Anmeldung.md
new file mode 100644
index 0000000..1bc35f7
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.3.-UC--SL-Anmeldung.md
@@ -0,0 +1,125 @@
+# 4.3. UC: SL-Anmeldung
+
+Created: 2024-09-16 15:36:06 +0200
+
+Modified: 2024-09-17 16:50:50 +0200
+
+---
+
+Use Case "Anmeldebestätigung für Schnupperlehre"
+
+
+
+
+
+Änderungshistorie
+
+| Datum | Version | Beschreibung | Autor | Zustand |
+|------------|---------|-----------------------|-----------------|---------|
+| 17.09.2024 | 0.1 | Initiale Formulierung | Alfred Albisser | geplant |
+
+
+
+
+
+
+
+
+
+
+
+
+
Use Case Nummer
+
UC-SL-01
+
+
+
+
+
Name
+
Anmeldeformular für Schnupperlehre
+
+
+
Autoren
+
Alfred Albisser
+
+
+
Priorität
+
Wichtigkeit für Systemerfolg »hoch«
+
Technologisches Risiko »hoch«
+
+
+
Kritikalität
+
Hoch
+
+
+
Quelle
+
Berufsbildner
+
+
+
Verantwortlicher
+
Alfred Albisser
+
+
+
Kurzbeschreibung
+
Ein Bewerber kann einen verfügbaren Termin auswählen, sein Angaben in das Formular eingeben und Dateien hochladen. Diese Daten werden in der Datenbank gespeichert und stehen für Folge-Prozesse zur Verfügung
+
+
+
Auslösendes
+
Ereignis
+
Bewerber hat seine Schnupperlehr-Anmeldung online abgeschickt
+
+
+
Akteure
+
Schnupperlehr-Bewerber
+
+
+
Vorbedingung
+
Die Webseite funktioniert und ist von extern zugänglich
+
+
+
Nachbedingungen
+
Nach der Übermittlung und Speicherung der eingegebenen Daten werde folgende Post-Prozesse (als eigene Use Cases definiert) ausgelöst:
+
+
Anmeldebestätigung generieren
+
Buchungssystem aktualisieren
+
Berufsbildner über neuen Bewerbungseingang informieren (Kontrolle / Übersicht)
+
+
+
+
Ergebnis
+
Der Berufsbildner kommt durch die Automatisierung zu allen geforderten Angaben und
+
+
+
Hauptszenario
+
+
Der Bewerber hat die AGB gelesen und akzeptiert
+
Der Bewerber wählt einen verfügbaren Termin in seinem bevorzugten Beruf aus
+
Der Bewerber lädt die geforderten Dateien hoch
+
Der Bewerber füllt die restlichen Angaben in die Eingabemasken ein. Das System validiert diese Daten
+
Der Bewerber übermittelt die eingegebenen Daten
+
Die Daten werden in die Datenbank aufgenommen
+
Es werden allfällige Post-Prozesse initiiert
+
+
+
+
Alternativszenarien
+
+
Bewerber bemerkt, dass er einen Fehler gemacht hat (z.B. falsche E-Mail-Adresse)
+
Eine Stornierungs-Möglichkeit (Terminkonflikt, Falscheingabe, …)
+
Verhindern, dass sich ein Bewerber mehrmals bewerben kann
+
+
+
+
Ausnahmeszenarien
+
+
Bewerber verlässt die Webseite => die Eingabedaten werden verworfen
+
Die Webseite "hängt" => Timeout
+
Es gehen gleichzeitig mehrere Bewerbungen ein und der letzte Schnupperlehrplatz ist gerade vergeben worden
+
+
+
+
Qualitäten
+
Useabilty, Barrierefreiheit
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.4.-UC--SL-Anmeldebestätigun.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.4.-UC--SL-Anmeldebestätigun.md
new file mode 100644
index 0000000..a5ed9c0
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/4.-Use-Cases/4.4.-UC--SL-Anmeldebestätigun.md
@@ -0,0 +1,117 @@
+# 4.4. UC: SL-Anmeldebestätigung
+
+Created: 2024-09-17 11:45:49 +0200
+
+Modified: 2024-09-18 07:26:20 +0200
+
+---
+
+Use Case "Anmeldebestätigung für Schnupperlehre"
+
+
+
+
+
+Änderungshistorie
+
+| Datum | Version | Beschreibung | Autor | Zustand |
+|------------|---------|-----------------------|-----------------|---------|
+| 17.09.2024 | 0.1 | Initiale Formulierung | Alfred Albisser | geplant |
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm.md
new file mode 100644
index 0000000..970670e
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm.md
@@ -0,0 +1,9 @@
+# 6. Kontextdiagramm
+
+Created: 2024-09-18 07:52:24 +0200
+
+Modified: 2024-10-11 14:09:04 +0200
+
+---
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.1.-System.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.1.-System.md
new file mode 100644
index 0000000..6a324c6
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.1.-System.md
@@ -0,0 +1,27 @@
+# 6.1. System
+
+Created: 2024-09-18 07:52:24 +0200
+
+Modified: 2024-09-18 15:59:41 +0200
+
+---
+
+**Kontextdiagramm "System"**
+
+
+
+Wir unterscheiden zwischen dem Entwicklungsrechner (Localhost) und später auf einem Server gehostete Web-Applikation.
+
+{width="4.333333333333333in" height="2.7291666666666665in"}
+
+Da eine Web-Applikation, welche nur auf dem Entwicklungsrechner funktioniert keinen Nutzen hat, stellt sich die Frage, ab wann wechseln wir auf die gehostete Web-Applikation? Weitere Punkte die es zu beachten gilt sind:
+
+- Arbeiten im Team. Wie arbeiten Front- und Backend auf unterschiedlichen Entwicklungsrechner zusammen? Wie gross ist der Aufwand für diese Workarounds und was schleppt man später noch als Altlast mit sich rum?
+- Braucht es eine 1:1 Test-Umgebung für die Entwicklung? Wir möchten ja nicht "live" entwickeln. Erst wenn wir auf der Test-Umgebung eine zufriedenstellende Web-Applikation haben möchten wir diese "scharf" schalten und auf die Production-Umgebung wechseln
+
+
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.2.-Stackholder.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.2.-Stackholder.md
new file mode 100644
index 0000000..2cff862
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/6.-Kontextdiagramm/6.2.-Stackholder.md
@@ -0,0 +1,24 @@
+# 6.2. Stackholder
+
+Created: 2024-09-18 07:52:24 +0200
+
+Modified: 2024-09-18 16:40:11 +0200
+
+---
+
+**Kontextdiagramm "Stakeholder"**
+
+
+
+
+
+Bei der Plattform ist es eine Vermischung von System-Services und den dahintersteckenden Lieferanten
+
+Der äussere Kontext interessiert uns zur Zeit nur am Rande, kann aber auf den Lifecycle bezogen einen nicht zu vernachlässigenden Einfluss haben.
+
+{width="13.802083333333334in" height="9.75in"}
+
+
+
+
+
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/8.-SWOT-Analyse.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/8.-SWOT-Analyse.md
new file mode 100644
index 0000000..9546444
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/8.-SWOT-Analyse.md
@@ -0,0 +1,56 @@
+# 8. SWOT-Analyse
+
+Created: 2024-09-16 14:48:23 +0200
+
+Modified: 2024-09-16 15:33:07 +0200
+
+---
+
+**SWOT-Analyse zum Team "Webseite Berufswahl"**
+
+
+
+| **Das Team besteht aus:** |
+|------------------------------|
+| Yannick Oser IF4 (Di - Do) |
+| Aimo Altorfer IF3 (Mo - Fr) |
+| Alwin Litscher IF1 (Di - Do) |
+
+
+
+| **SWOT-Analyse:** | | **Externe Analyse („Blick nach außen")** | |
+|----------------|---------------|----------------------|--------------------|
+| Einfaches Werkzeug zur Untersuchung und Positionierung des eigenen Unternehmens bezüglich ausgewählter Betrachtungsobjekte (Produkte, Standorte, Personal ...) und zur Ableitung von ganzheitlichen Lösungsstrategien. | | **Opportunities (Chancen)** | **Threats (Gefahren)** |
+| | | Ein sichtbares Produkt realisieren (Kein Edelschrott, Fussspuren hinterlassen, Visitenkarte, ...) | Ziele (Erwartungshaltung) sind nicht klar |
+| | | Nah am Zielpublikum | Berufsbildner, Auftraggeber hat zu wenig Zeit auszubilden und Anforderungen zu definieren |
+| | | Teamwork (SCRUM) | Unklare Aufgabenteilung (Verantwortung, Schnittstelle, ...) |
+| | | Projektmanagement | Team-Mitglieder sind in unterschiedlichen Lehrjahren und haben unterschiedliche Kompetenzen |
+| | | Vernetztes Denken | Motivation sinkt, wenn es nicht mehr so schnell und einfach vorwärts geht (Pareto-Prinzip) |
+| | | Alle lernen voneinander (Schwarmintelligenz) | |
+| | | | |
+| | | | |
+| | | | |
+| | | | |
+| **Interne Analyse ("Blick nach innen")** | **Strength (Stärken)** | **Stärken-Chancen- (SO-) Strategien:** | **Stärken-Gefahren- (ST-) Strategien:** |
+| | | Mit den eigenen Stärken bestehende Chancen nutzen | Mit den eigenen Stärken bestehende Gefahren abwehren |
+| | Flexibilität (noch nicht festgefahren) | Alle sind jung und in erster Ausbildung. Es ist noch nicht lange her, wo man sich selbst um eine Lehrstelle beworben hat und sich in das Zielpublikum hineinzudenken vermag. | Am richtigen Ort flexibel sein. Das Ziel ist gegeben, der Weg dorthin gestalten wir. |
+| | Motiviert für praktische Umsetzung | Was gibt es besseres um seine Fähigkeiten unter Beweis zu stellen als eine coole Webseite zu realisieren, welche die ganze Welt sehen kann? es liegt an euch etwas beeindruckendes zu realisieren. | Darauf achten nicht aus purem Eifer reinzuschiessen. Das Sprichwort wer kein Kopf hat, hat Beine kommt nicht von ungefähr und im IPERKA gibt es noch 3 Schritte vor dem Realisieren. |
+| | Motiviert im Team zu arbeiten | Bewusst sein, dass es ein performantes Arbeitsteamund kein Kaffeekränzchen ist. Mit Freude und Spass zu einer erfolgreichen Web-Anwendung arbeiten wo jeder einen wertvollen Beitrag leistet. Es besteht hier die Möglichkeit agil mit SCRUM zu arbeiten und das Projekt hat auch eine Grösse, so dass ein Projektmanagement wirklich Sinn ergibt. Auch haben wir in diesem Projekt eine Komplexität welche vernetztes Denken erfordert. | Es müssen alle ins Team geholt werden, unabhängig vom Lehrjahr und den Fähigkeiten. Akzeptieren, wenn andere manchmal die höherstehende Aufgaben übernehmen. |
+| | Motiviert Neues zu lernen | Offen für Neues und Grösseressein. Man hat nicht immer die Möglichkeit als Lernender in diesen Dimensionen zu arbeiten. | Was nichts kostet ist nichts wert => bei 20 % Aufwand hat man eigentlich auch nur 20% Erfahrung gesammelt. Wie weit reicht dies in der Berufswelt?Kleine Teilziele setzen, so dass man das Gefühl hat es geht stetig voran und immer wieder zu Erfolgserlebnissen kommt. Z.B. in Form von Sprints. |
+| | | | |
+| | | | |
+| | | | |
+| | | | |
+| | | | |
+| | **Weakness (Schwächen)** | **Schwächen-Chancen- (WO-) Strategien:** | **Schwächen-Gefahren- (WT-) Strategien:** |
+| | **** | Eigene Schwächen beseitigen, um bestehende Chancen zu nutzen | Eigene Schwächen beseitigen, um drohende Gefahren abwenden zu können |
+| | Das herauszupicken was Spass macht (Coden) | Das Wachstum bezüglich Handlungsfähigkeiten sehen. Die Berufsbezeichnung lautet Applikationsentwickler und nicht Programmierer | Einen akzeptablen Wochenablauf gestalten zwischen Pflicht & Kür |
+| | Kaum Erfahrung (Sinn & Zweck SW-Engineering) | Recherche, warum ist die SW-Entwicklung zu diesen Erkenntnissen gekommen? Zur Einsicht kommen, dass man nicht einfach drauflos coden kann, wenn man ein gutes Produkt entwickeln will. Irgendwann ist man nur noch am Flicken / Basteln und würde am liebsten wieder bei Null beginnen. | |
+| | Identifikation mit Zielen | Ziele nach SMART definieren => attraktiv, lohnend | Sich im Klaren sein, warum wir diese Web-Anwendung wollen und für wen sie gedacht ist. |
+| | Anfänger (wenig Akzeptanz für Ratschläge) | Nachfragen wenn der Sinn nicht klar ist. | Aus Fehlern lernen => funktioniert aber nur wenn man die eigenen Fehler auch selbst ausbaden muss und nicht dem nächsten auf den Tisch legt. |
+| | Copy & Paste => den einfachen Weg gehen | Profi werden, stolz sein auf seine Kompetenzen. Was ist das Ziel, dass YouTube und ChatGPT mir Lösungen anbieten, weil ich es nicht selbst schaffe das Problem zu lösen? | Es ist nicht falsch nach Lösungen zu suchen, aber wenn wir dann die Anforderungen an die gefundenen Lösungen anpassen, wird kein Kunde zufrieden sein. |
+| | | | |
+| | | | |
+| | | | |
+| | | | |
+| | | | |
diff --git a/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/9.-Usabilty---Barrierefrei.md b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/9.-Usabilty---Barrierefrei.md
new file mode 100644
index 0000000..267d1c2
--- /dev/null
+++ b/docs/IF_Projekte/Webseite-Berufswahl/Requirements-Engineering/9.-Usabilty---Barrierefrei.md
@@ -0,0 +1,380 @@
+# 9. Usabilty - Barrierefrei
+
+Created: 2024-09-06 13:17:59 +0200
+
+Modified: 2024-09-17 14:57:35 +0200
+
+---
+
+Bei dem Design und der Implementierung von Webseiten wird eine Nutzergruppe von vielen Entwicklern (und Designerinnen) leider immer wieder vergessen, nicht berücksichtigt oder zumindest vernachlässigt. Die Rede ist von Nutzenden mit Behinderungen, beispielsweise Nutzer mit Sehschwächen, Hörschäden oder anderen körperlichen oder neurologischen Einschränkungen.
+
+
+
+Wenn Sie eine Website barrierefrei implementieren, tun Sie aber nicht nur den Nutzern mit Behinderungen einen großen Gefallen und richten sich im Falle oben genannter Websites nach dem Gesetz. Je barrierefreier eine Website ist, desto zugänglicher wird sie auch für andere Nutzergruppen, beispielsweise:
+
+- Für Personen, die Mobiltelefone, Smartwatches, Smart-TVs oder andere Geräte mit kleinen Bildschirmen für den Zugriff auf die Website verwenden
+- Für ältere Nutzer mit veränderten Fähigkeiten aufgrund des Alterns, Nutzern mit »vorübergehenden Einschränkungen« wie etwa einem gebrochenen Arm
+- Für Nutzer mit »Situationsbeschränkungen« wie hellem Sonnenlicht oder in einer Umgebung, in der sie keinen Sound hören können
+- Für Nutzer, die eine langsame Internetverbindung verwenden oder über eine begrenzte oder teure Bandbreite verfügen
+
+
+
+**Barrierefreiheit und Suchmaschinenoptimierung**
+
+Darüber hinaus verbessern viele der Techniken, die zu barrierefreien Webseiten bzw. einer barrierefreien Website führen, auch die Bewertung der Website für Suchmaschinen (Stichwort: SEO bzw. Suchmaschinenoptimierung). Ihre Website erlangt also bei Suchmaschinen eine höhere Bewertung und verbessert damit die Position (das Ranking) innerhalb der Suchergebnisse.
+
+
+
+
+
+**Nutzergruppen und assistive Technologien**
+
+Für den Zugriff auf Webseiten verwenden Nutzer mit Behinderungen oftmals besondere Hard- und Software, sogenannte assistive Technologien bzw. unterstützende Technologien.
+- Blinde Nutzer beispielsweise nutzen Screenreader, also Software, die den Inhalt des Bildschirms (bzw. einer Webseite) vorliest oder auf einer speziellen Braille-Tastatur ausgibt.
+- Nutzer mit körperlichen Einschränkungen verwenden spezielle Eingabegeräte wie beispielsweise besonders ergonomische Tastaturen oder andere Eingabegeräte wie Head/Eye Controls.
+- Nutzer mit Farbsehstörungen verwenden oft einen Schwarz-Weiß- bzw. High-Contrast-Modus, bei dem der Inhalt des Bildschirms in Schwarz und Weiß bzw. einem hohen Kontrast dargestellt wird.
+- Nutzer mit Sehschwächen verwenden Bildschirmlupen, um Teile des Bildschirms vergrößert darzustellen.
+- Nutzer mit Hörschäden verwenden in der Regel keine Soundausgabe und sind daher beispielsweise in Videos auf Untertitel angewiesen.
+
+
+
+**Webseiten semantisch strukturieren**
+
+Webseiten ähneln sich häufig bezüglich ihres Aufbaus: So haben die meisten Webseiten einen Kopfbereich (der zum Beispiel das Firmenlogo enthält), einen Fußbereich (in dem sich zum Beispiel Links zum Impressum, zum Kontaktformular oder zu sozialen Netzwerken befinden), einen Navigationsbereich (in dem die Hauptnavigation
+
+angesiedelt ist), einen Hauptbereich (der den Hauptinhalt der jeweiligen Webseite enthält) und mitunter auch Randbereiche, die zusätzliche Informationen bereitstellen.
+
+{width="3.6770833333333335in" height="2.9479166666666665in"}
+
+
+
+Früher hat man die gewünschte Struktur mit
realisiert. Mittlerweile sollten Sie die mit HTML5 eingeführten semantischen Elemente zur Definition der Struktur verwenden. Zur Erinnerung:
+
+- Das Element definiert den Kopfbereich einer Webseite,
+-