- 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.
fdai7764
1 year ago