Update Lerntagebuch.md

Lerntagebuch.md

@@ -62,7 +62,7 @@ Programmierparadigmen:
     - Funktionen werden als gleichwertiger Datentyp angesehen
     - Eher für nebenläufige Prozesse geeignet
 - Typisiert:
-    - Jede Variable hat einen Datentyp --> Kann auch durch IDE zugewiesen werden
+    - Jede Variable hat einen Datentyp → Kann auch durch IDE zugewiesen werden
     - Codevervollständigung durch IDE, Kompiler kann Fehler vor der Ausführung des Programms erkennen
 - Typenlos:
     - Kein konkreter Datentyp für Variable
@@ -397,15 +397,15 @@ Keine
 
 **Seminarischer Unterricht:**
  
-- Programme werden Komplexer --> Man muss zusammenarbeiten
+- Programme werden Komplexer → Man muss zusammenarbeiten
 - Zusammenführen der Einzelleistungen
 - Probleme:
     - Unterschiedliche Formatierungen des Codes
-    - Technische Konflikte --> Selbe Stelle von zwei Entwicklern bearbeitet
-    - Persönliche Konflikte --> Streit
+    - Technische Konflikte → Selbe Stelle von zwei Entwicklern bearbeitet
+    - Persönliche Konflikte → Streit
 - Lösung: CI-System
     - Verringert Aufwand des Personals
-    - Erfordert formale Vorgehensweisen --> Autoformater, verhindert Streit
+    - Erfordert formale Vorgehensweisen → Autoformater, verhindert Streit
     - Vorstufe zu Continuous Delivery
 
 Softwareentwicklungsprozess
@@ -415,18 +415,18 @@ Softwareentwicklungsprozess
 - Integration
 - Build-Prozess
 - Kompilieren
-- Testen --> Automatisiert
+- Testen → Automatisiert
 - Bereitstellung nach den Erwartungen des Kunden
 
 Abhängigkeitsverwaltung
 - Abhängigkeiten sind Codestücke von anderen Entwicklern
 - Nicht im SCM eingecheckt, sondern zentral bereitgestellt (z.B. Github)
-- Zugriff auf einzelne Versionen --> Muss sich auf bestimmte Version beziehen, sonst eventuell inkompatibel
+- Zugriff auf einzelne Versionen → Muss sich auf bestimmte Version beziehen, sonst eventuell inkompatibel
 
 Versionsnummer
 Major.Minor.Patch-Label
 - Major: 
-    - Wenn erhöht: Inkompatible Änderungen --> Man muss Änderungen am eigenen Quellcode machen wenn man die Library nutzen will
+    - Wenn erhöht: Inkompatible Änderungen → Man muss Änderungen am eigenen Quellcode machen wenn man die Library nutzen will
 - Minor:
     - Wenn erhöht: Zusätzliche Features, bleibt aber abwärtskompatibel
 - Patch
@@ -434,7 +434,7 @@ Major.Minor.Patch-Label
 - Label
     - Build-Kennzeichnung, Beschreibung, möglichst ohne Label
     - Ausschließlich Ziffern und Punkte, rein amerikanisches Ascii
-- Immer wenn sich die höhere Nummer ändert werden die danach wieder auf 0 gesetzt --> Bessere Praxis: Patch-Level nie zurücksetzen
+- Immer wenn sich die höhere Nummer ändert werden die danach wieder auf 0 gesetzt → Bessere Praxis: Patch-Level nie zurücksetzen
 - Ein nicht vorhandenes Label ist eine höhere Version als mit Label
 
 SCM
@@ -451,7 +451,7 @@ Build-Prozess
 - Übersetzen des Codes
 - Automatisierte Tests
 - Liefer-Artefakt erzeugt
-- "Deployment" --> Herausgabe des fertigen Ergebnisses
+- "Deployment" → Herausgabe des fertigen Ergebnisses
 
 Compiler:
 - make / ceedling
@@ -465,7 +465,7 @@ Compiler:
     - JavaScript/TypeScript
 
 Was macht ein CI-System?
-- SCM überwachen --> "Ist neuer Code da?"
+- SCM überwachen → "Ist neuer Code da?"
 - Änderungen zusammenführen 
 - Build-Prozess
 - Auflösung der Abhängigkeiten
@@ -481,24 +481,24 @@ Automatisierte Tests
 - CI soll immer auslieferbaren Stand haben
 - Programm wird im CI-System ausgeführt mit automatisierten Tests
 - Dokumentation von gewünschtem Ergebnis → Laufzeitfehler können gefunden werden
-- Pro: Ausführungszeit von Arbeitszeit entkoppeln --> Kann über Nacht gemacht werden
-- Con: Test kann nur Abweichung von gewünschtem Ergebnis/Verhalten finden --> Es können nur bekannte Fehler entdeckt werden
+- Pro: Ausführungszeit von Arbeitszeit entkoppeln → Kann über Nacht gemacht werden
+- Con: Test kann nur Abweichung von gewünschtem Ergebnis/Verhalten finden → Es können nur bekannte Fehler entdeckt werden
 
 Vorgehensmodelle für Kooperation
 - Gemeinsames Remote-Repository
     - Alle arbeiten auf diesem Remote-Repository
-    - Alle brauchen Schreibzugriff darauf --> Aufwändige Verwaltung von Berechtigungen
+    - Alle brauchen Schreibzugriff darauf → Aufwändige Verwaltung von Berechtigungen
     - Jeder Developer braucht Accout bei Instanz
     - Einfache Synchronisation
-    - Gepushte Zwischenstände für alle verfügbar --> Änderungen gehen nicht verloren, unfertiger Stand problematisch
+    - Gepushte Zwischenstände für alle verfügbar → Änderungen gehen nicht verloren, unfertiger Stand problematisch
 - Private Fork
     - Jeder Dev hat eigene Kopie des zentralen Reps auf eigenem Rep
     - Nur der Dev selbst hat darauf Zugriff
-    - Zentrales Remote Rep --> Master, CI-System
+    - Zentrales Remote Rep → Master, CI-System
     - Jedes lokale Rep hat zwei remote Reps:
-    - Origin --> Master, read only
-    - Upstream --> Provater Fork, Schreibrechte
-    - Änderung mit Pull-Request aus Fork in Master --> Maintainer überprüft Code
+    - Origin → Master, read only
+    - Upstream → Provater Fork, Schreibrechte
+    - Änderung mit Pull-Request aus Fork in Master → Maintainer überprüft Code
 
 
 **Praxisübung:**
@@ -520,6 +520,86 @@ Aus dem Seminarischen Unterricht und der Praxisübung kann ich das Wissen über
 Ein Continous Integration System (kurz: CI-System) überwacht den aktuellen Stand im Source Code Management System. Werden Änderungen festgestellt, werden eventuelle Änderungen von anderen Entwicklern automatisch zusammengeführt. Danach wird das Projekt kompiliert, nachdem sich das CI-System um die Abhängigkeiten gekümmert hat. Das fertige Programm wird anschließend automatisch getestet, nach Erwartungswerten die der Programmierer vorher eingeben muss. Und schließlich gibt das CI-System einen Bericht über die Resultate zurück.
 
 
+### Kritik
+
+Keine
+
+---
+
+
+## SU 06 (05.12.2023) - Projektmanagement
+
+### Lernziel
+
+Seminarischer Unterricht:
+- Was ist überhaupt ein Projekt im Vergleich mit zum Beispiel einem Vorhaben?
+    - Start- und Endzeitpunkt, komplexe Handlungsabläufe
+    - Risikobehaftet
+- Projektmanagement Schritte:
+    - Methode 1:
+        - Planung → Evtl zeitl. Problem mit anderen Projekten
+        - Organisation → Den Leuten die in der Planung vorgesehen sind Bescheid sagen, evtl weiterbilden, Beschaffung der Resourcen, Büro etc
+        - Durchführung → Das tatsächliche Programmieren
+        - Kontrolle → Ist der Fortschritt ausreichend um das Ziel zu erreichen? → Ermöglicht Gegenmaßnahmen
+    - Methode 2:
+        - Sammeln von Informationen → Hintergrundwissen
+        - Erkennen der Idee → "Kunde weiß nicht was er will"
+        - Planung → Zeitlich, Nutzung der Informationen, Entwürfe
+        - Aufgabenverteilung
+        - Organisation → Voraussetzungen schaffen
+        - Kontrolle → Hindernisse und Risiken erkennen und rechzeitig gegenzusteuern → Je früher desto billiger
+- Rollen:
+    - AuftraggeberIn ("product owner")
+    - ProjektleiterIn ("Scrum Master")
+    - ProjektmitarbeiterIn
+    - Betroffene ("Stakeholder")
+- Modelle:
+    - Wasserfallmodell → Linear, jeder Schritt nur einmal
+    - V-Modell → Linke Seite Wasserfall, rechte Seite Testebene für jedes Element des Wasserfalls
+    - Agiles Modell → Fixiert Zeit statt Umfang, evtl hat das Projekt dann noch nicht alle Features, ist aber auf jeden Fall einsatzbereit
+- Methoden:
+    - Kanban → "Assembly Line"
+    - Burn-Down-Chart → Zeigt auf Graph ob man noch im Zeitplan liegt
+    - Scrum → Regelmäßige Meetings zur Besprechung des Fortschritts, tägliche Meetings, Meetings nach Sprint, Wertesystem der "Story Points"
+- Schätzverfahren
+    - Einschätzung des Aufwands ist wichtig für korrekte Einschätzung der Zeit und der Kosten
+    - Schätzung so früh wie es noch realistisch ist
+    - Reaktion auf Anforderungsänderungen
+    - Schätzung nach Story Points
+        - Testen und Refactoring immer einberechnen
+        - Aufgaben in möglichst kleine Teilaufgaben zerlegen → genauere Schätzung
+        - Nach Storypoints eher möglichst spät schätzen, damit Kundenänderungen dabei sind
+        - Wenn zu wenig Informationen vorliegen, Schätzung ablehnen
+    - Schätzung nach Drei-Werte-Weg
+        - Erwarteter Wert für normalen Aufwand → durch Erfahrung
+        - Erwarteter Wert, wenn keine Hindernisse auftreten → "best case"
+        - Erwarteter Wert, wenn alles schief läuft → "worst case"
+    - Schätzung durch historischen Vergleich
+        - Wie aufwändig waren Aufgaben, die ähnlich komplex waren?
+        - Wird mit zunehmender Erfahrung genauer
+    - Schätzung durch "Planning Poker"
+        - Jeder Mitarbeiter schätzt für sich einen Wert für die Komplexität
+        - Niedrigster und höchster Wert müssen begründet werden
+        - Diskussion und Abstimmung
+        - Durchschnitt bildet Wertung der Komplexität
+
+
+
+Praxisübung:
+- Recherche zu Meilensteinen, "Minimum Vaiable Increment" und Arc42
+- Planning Poker zu verschiedenen Szenarien
+
+
+### Erkenntnis
+
+Aus dem Seminarischen Unterricht und dem Praxisteil kann ich das Wissen zum Projektmanagement für das Gruppenprojekt mitnehmen.
+
+
+### Wiederholung
+
+Meilensteine sind Entscheidungspunkte nach einer Entwicklungsphase. Diese Phasen sind zum Beispiel Unit-Tests beim V-Modell. Meilensteine dienen der Einschätzung des Fortschritts hinsichtlich des Zeitplans. 
+
+
 ### Kritik
 
 Keine