From 200eec4bd2fdcda7b050d6cea215324ce9267d7a Mon Sep 17 00:00:00 2001 From: fdai7764 Date: Sun, 10 Dec 2023 13:19:12 +0000 Subject: [PATCH] Update Lerntagebuch.md --- Lerntagebuch.md | 118 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 99 insertions(+), 19 deletions(-) diff --git a/Lerntagebuch.md b/Lerntagebuch.md index b7e6fea..b2af50f 100644 --- a/Lerntagebuch.md +++ b/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