Turbo/peer-group-grading
9
3
Fork 0
Code Issues 44 Pull requests 2 Projects 1 Releases Packages Wiki Activity Actions
Page: Preperation of Expert Talk | German Guide
Pages
Feedbackgespräch Michael Pipeline UML Sequence Diagram Preperation of Expert Talk | German Guide Project Overview Project Requirements QnA Ticket cleanup UML Deploymentdiagram
10 Preperation of Expert Talk | German Guide
Underflow edited this page 2025-04-10 01:12:28 +02:00
Unescape Escape
Table of Contents
This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Teil 1: Fachgespräch

Einsatz und Begründung der Technologien: Verständnis zu den verwendeten Frameworks, Tools und Architektur und warum sie gewählt wurden

- Vue.js als Frontend-Framework und Rust als Backend-Framework
- Git für Repo-Management, Bruno für API, Woodpecker für CI, Miro für Retro und Designs/Konzepte, Drawio für Diagramme
- Architektur Frontend-Backend Kommunikation durch REST-API's

Architektur-Überblick: Verständnis über die Gesamtarchitektur des Projekts (z. B. Schichten, Abhängigkeiten)

FE: Mockups Crate Migration ERM

Stärken/Schwächen des Projekts: Kritische Auseinandersetzung mit Codequalität, Testabdeckung und Pipeline-Design und Wartbarkeit.

  • Codequalität kritisch auf Grund von neuem Framework und neuen Entwicklern im Frontend
  • Tests grundsätzlich eher weniger vorhanden (FE und BE) als gewünscht auf Grund von fehlender Logik etc.
  • Deployment Pipeline noch nicht voll funktionsfähig, weil Woodpecker ist falsch konfiguriert ist
  • Rust tendenziell weniger wartbar, auf Grund von steiler Lernkurve und teilweise Inselwissen

Lernprozess & Zukunftsperspektive Einsicht in gewonnene Erkenntnisse und realistische Ideen zur Weiterentwicklung

  • Mehr "Investition" in Lernbereitschaft und Zeitaufwand
  • Weniger Talk, mehr Code
  • Use-Case Ideen umsetzen, später zusätzliche Ideen implementieren

Fachsprache & Klarheit:

Verwendung präziser Begriffe, um komplexe Konzepte verständlich zu erklären.

  • Wir sind professionell

Fach- und Abnahmegespräch: Alle sind beteiligt, kein ausgeprägtes "Inselwissen"

  • Wir sind experten

Teil 2: Monitoring

CPU, RAM, Speicherplatz auf dem host wird gemonitored

Datenbank, Get Post updates and delete wird gemonitored

Prometheus und Grafana

Sie können ausgewählte Messedaten erfassen, speichern und über die Konsole ausgeben.

  • Nein

Sie legen mindestens einen Schwellenwert fest.

  • Nein, nicht applicable

Sie überprüfen mindestens einen Schwellenwert.

  • Nein, s. o.

Die Messdaten werden in einer Logdatei gespeichert

  • Nein s. o.

Die auf dem Server eingeloggten Nutzer werden ebenfalls geloggt

  • Nein s. o.

Sie haben eigene kleine Funktionen definiert.

  • Ja siehe Rust

Sie haben den Programmcode lesbar und verständlich gestaltet.

  • Ja, siehe Code

Sie haben das Programm für die umgesetzten Anforderungen getestet.

  • Wir testen nach den Anforderungen von Michael hier handelt es sich aber um Software Anforderung nicht um explizite Test-anforderungen

Sie haben einen automatisierten Test implementiert.

  • Ja siehe Rust

Sie haben ein Klassendiagramm oder Verteildiagramm ihrer Software erstellt.

https://git.mixel.cloud/Turbo/peer-group-grading/wiki/UML-Deploymentdiagram https://git.mixel.cloud/Turbo/peer-group-grading/wiki/Pipeline-UML-Sequence-Diagram

Zwei Module (Monitoring / Alarm) die miteinander arbeiten, sind realisiert und getestet.

  • Ne

Ein zweistufiges Alarmsystem (Soft- und Hardlimit) für mindestens zwei Messdaten und deren Schwellenwerte sind umgesetzt.

  • Ne

Sie können eine E-Mail mit entsprechender Warnung versenden.

  • Ne

Die Module sind verständlich strukturiert. Sie erstellen eine Hilfe, die mit dem Parameter „h“ aufgerufen werden kann.

  • Ne

Die Steuerung des Programms (z. B. Auswahl der zu prüfenden Messdaten) erfolgt über die Parameter beim Programmaufruf oder über die interaktive Abfrage in der Konsole.

  • Eventuell vorhanden. Ein Parameter durch Rust-feature-flags: serve -> started automatisch einen weiteren thread mit einem webserver indem das kompilierte frontend laufen könnte.

Der Programmcode ist leicht erweiterbar durch: eine gute Programmstruktur(Module, kleine Funktionen),

  • Ja

selbsterklärenden Programmcode.

  • Ja

aussagekräftige Namen der Variablen und Funktionen sowie sinnvolle Kommentare.

  • Vorhanden

Sie haben drei automatisierte Tests implementiert.

  • Ja: Pipeline tests.

Zwei Module (Monitoring / Alarm), die miteinander arbeiten, sind realisiert und getestet.

  • Nicht realisiert

Ein zweistufiges Alarmsystem (Soft- und Hardlimit) für mindestens zwei Messdaten und deren Schwellenwerte ist umgesetzt. Die E-Mails werden versendet, die Logindaten werden aus einer Datei gelesen.

  • Nicht realisiert

Sie nutzen für die Festlegung der Schwellwerte(Hard-/Softlimits) und für die Login- Daten eine INI-Datei, die Sie mit Hilfe des Standardmoduls configparser auslesen. Die Steuerung des Programms (z. B. Auswahl der zu prüfenden Messdaten) erfolgt über die Parameter beim Programmaufruf oder über eine INI-Datei. Sie bieten dem Nutzer eine Hilfe (help-Texte) für die Kommandozeilenparameter an.

  • Nicht realisiert

Sie haben fünf automatisierte Tests implementiert.

  • Ja, Redis datenbank wird gested wird automatisch in der Pipeline ausgeführt.

Sie entwickeln Ihre Module so, dass sie unabhängig vom Betriebssystem laufen. Testen Sie Ihre Module unter Windows und Linux.

  • Unsere App ist browserbasiert. Backend sollte überall kompiliert werden können.

Teil 3: Iterativer Softwarelebenszyklus

Sie halten die Verteilung der (Scrum)-Rollen sowie deren Beschreibung innerhalb Ihres Teams schriftlich fest.

Verteilung:

Mika - Backend/Implementation des Backends, Datenbanken, Programmen und APIs + Server Admin (Repo / Pipeline Host) Connor - Backend/Implementation des Backends, Datenbanken, Programmen und APIs Baran - Backend/LDAP Implementation Johannes - Backend/Implementation Pipelines + Server Admin (Pipeline Host) Niklas - Backend/Documentation - Documentation & Scrum Master/Product Owner

Mika(el) - Frontend/Implementation Frontend & Design Jan - Frontend/Implementation Frontend & Design Jan-Henry - Frontend/Implementation Frontend & Design

Sie legen die zu bearbeiteten Aufgaben fest, priorisieren und terminieren diese und legen Verantwortlichkeiten fest.

Sie teilen Ihr Planungsboard mit dem Lehrerteam.

  • Board ist öffentlich

Sie dokumentieren Ihre Ergebnisse der Retrospektiven.

Sie beschreiben mindestens eine weitere Methode oder ein Tool, welches Sie zur Planung oder Schätzung verwendet haben und beschreiben, ob dies ein Zugewinn für Ihr Team darstellte (oder nicht) und warum.

  • Miro wurde als alternative zu Figma für das Frontend Mockup benutzt da es schnell und einfach die Möglichkeit zum "Grayboxing" / Designen gegeben hat ohne viel aufwand dahinter.

Sie erweitern die Beschreibung der Rollen in Ihrem Team bezüglich weiterer (Scrum) Rollen, welche in komplexeren realen Projekten notwendig oder hilfreich sein können.

Product Owner: 
Er ist die brücke zwischen Entwicklungsteam und externen Parteien (Kunden, Management).
Sollte folgendes decken:
Kommuniziert die Produktidee und priorisiert, was entwickelt wird.
Items hinzufügen, entfernen, priorisieren.
Klare und verständliche Anforderungen formulieren.
  
Scrum Master:
Er ist verantwortlich für das Verständnis und die korrekte Anwendung von Scrum. Unterstützt das Team als Coach, Facilitator und Servant Leader.
Er hat folgende Beteiligungen:
  Events wie Daily Scrum, Sprint Review etc. moderieren oder ermöglichen.
  Hilft dem Team, sich selbst zu organisieren.
  Unterstützt beim entfernen von Hindernissen (Impediments).
  Schirm gegen externe Störungen (z. B. durch Stakeholder).

Developer:
Die Lieferung eines fertigen, funktionsfähigen Inkrements am Ende jedes Sprints.
Developer beschäftigen sich mit folgenden Aufgaben:
   Im Sprint Planning: Entscheiden gemeinsam, was und wie viel sie umsetzen können.
   **(Haupt) Arbeit im Sprint: Umsetzung, Test, Dokumentation etc.**
   Im Review: Vorstellen vom Produktes.
   In der Retrospektive: Feedback (geben) für kontinuierliche Verbesserung im Team.
  
Agile Coach:
Ist eine optionale Rolle, ein erfahrener Coach, der mehrere Teams, Scrum Master oder ganze Organisationen bei der agilen Transformation unterstützt.
Seine Aufgaben sind:
   Er ist ein Coach für Scrum Master oder Führungskräfte.
   Und unterstützt bei der einführung von agilen methoden.
   Unterstützt bei struktureller Hindernis entfernung in der Organisation (Problem Management im Team)
Er befasst sich mit *mehreren Teams*/der ganzen Organisation gleichzeitig.

UX Designer:
Spezialist:innen für User Experience (Nutzerfreundlichkeit, Design, Nutzerforschung).
Ein UX designer arbeitet oft eng mit dem Product Owner zusammen.
Sie können im Entwicklungsteams sein (z. B. helfen bei der umsetzung von UI).

Tester / QA:
Qualitätsprüfung die sich auf Tests konzentrieren.
Und ist oft teil des Entwicklungsteams.

Sie vergleichen iterative Prozesse wie Scrum mit traditionellen Softwareentwicklungsprozessen (z.B. das V-Modell oder das Wasserfallmodell) und benennen Vor- und Nachteile.

Scrum und Iterative Prozesse:

Vorteile:

  • Hohe Flexibilität - Änderungen können iterativ pro Sprint bearbeitet/verändert werden.
  • Schnelles Feedback - Durch kleine Sprints können schnelle und regelmäßige Feedbacks zum und vom Kunden kommen.
  • Transparenz - Regelmäßige Meetings sollen zur einer guten Teamkommunikation beitragen, schnelle und kurze Übersichten schaffen.
  • Frühe Ergebnise - Teilergebnise werden früh geliefert.
  • Selbstorganisation - Das Team muss sich selbst organisieren und haben damit eine höhere Eigenverantwortung das kann zu Motivation Schüben und besseren Planbarkeiten führen

Nachteile:

  • Meetings: Many Meetings, this can be time taxing.
  • Unklare grenzen: Wenn es kein klares Ziel/Zeitenziel gibt kann das Projekt ausufern (zu groß "scope creep")
  • Selbstorganisation - Das Team muss selbst bestimmt und diszipliniert arbeiten können.
  • Schwierige Dokumentation - Weniger Fokus auf stark umfassende Spezifikation der Anwendung/Dokumentation
  • Nicht ideal für feste Budgets und Deadlines - Da es ein Sklaierbares modell ist müssen die angeforderten Ressourcen sich oft daran anpassen (Es ist schwer monetär planbar, vorauskaluiert)

Wasserfall und Statische Modelle

Vorteile:

  • Klare Struktur und Planung – Es steht voraus wie der Ablauf sein wird
  • Gute Dokumentation - Alles wird detailliert dokumentiert - für Wartung nützlich
  • Planbarkeit - Feste Endzeiten und Kostenrahmen
  • Klare Anforderungen - Von Anfang an Klare Anforderungen

Nachteile:

  • Inflexibel - Änderungen sind schwierig und oft teuer (neu) umzusetzten.
  • Spätes feedback - Erst nach Abschluss sieht der Kunde oft das Projekt
  • Fehleranfällig - Falsche anfoderungen können erst spät identifiziert werden
  • Lange wartezeiten - Kein nutzbares Produkt vor projektende
  • Planarbeit - Wenig eigenanteil in der Entwicklung meistens rein nach Plan.