Neue Datei hochladen

Lerntagebuch.md

@@ -0,0 +1,590 @@
+## SU 01  Lerntagebuch   (26.10.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+-die künstliche und handwerkliche Eingenschaften eines Softwareentwickler
+-der Unterschied zwischen einen Amateur und Profi, sowie die Merkmale eines Profi
+-wie ein kleiner Programmierfehler oder eine Nichtbeachtung einer Kleinigkeit beim Codieren zum Sturz eines wichtigen Programmes geführt hat, was in Folge riesiege Kosten bzw. Verluste verursacht hat
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+Jeder Mitglied einer Gruppe hat Eigenschaften eines Softwareentwicklers, die für einen Gruppenprojekt von Vorteil sind = Jeder Mitglied ist somit wichtig und sollte Beachten werden.
+Beim Programmieren des Gruppenprojekts sollte man möglich viel Fachwissen anwenden, die fachgemäße Werkzeuge anwenden und sich an Prinzipien halten
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Es ist sehr wichtig beim Programmieren sich an die Prinzipien zu halten, die Codierungen noch mal zu überprufen, um Fehler zu vermeiden.
+Außerdem ein Softwareentwickler kommt mir vor, als jemand, der ständig zwischen einem Handwerker und Künstler switcht. Meiner Meinung nach nur die Verbinndung von beiden ermöglicht die Erschaffung eines ausgezeichneten Programms 
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+Die Vorlesung und Präsentation waren sehr interessant und kreativ gestalltet.
+Leider die git-Repository und vor allem alle Codierungen (in Opensource), die dazu gehörten, waren sehr ungenau erklärt, sodass die Mehrheit es nicht verstanden hat. 
+
+
+
+
+
+## SU 02  Lerntagebuch   (26.10.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel → Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+
+Paradigmen:
+
+-imperative Programmierung = Beschreibt den Lösungsweg. Es sind bestimmte Befehle in der bestimmten Reihenfolge
+
+        -prozedurale Programmierung = eine Ergänzung zur imperativen Programmierung. Die Befehle haben einen Algorithmus, die überschaubar in Teile zerlegt ist.   
+
+-deklarative Programmierung = Beschreibt die Lösung, sowie das Ergebnis wird angegeben
+
+        -funktionale Programmierung = Vereinfachung der deklarativen Programmierung. Die Funktionen werden definiert, angewendet, sowie die Daten miteinander verknüpft, sodass ein Ergebnis rauskommt
+
+-objektorientierte Programmierung = Es findet eine Zusammenfassung den Objekten/Klassen mit Daten, sowie darauf arbeitenden Routinen, zu Einheiten.
+
+-typisierte Programmiersprache = Es findet eine Festlegung der Inhalt der Variable durch einen Datentyp
+
+-typenlose Programmiersprache = verfügen über keinen gegliederten Datentyp
+
+-Beachte diese Prinzipien:
+
+    -die Solid-Prinzipien = Separations of Concern, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle Dependency Inversion Principle 
+
+    -die Stupid-Prinzipien = Singelton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming, Duplication 
+
+    -KISS Keep It Simple (and) Stupid
+    -FCoH Favor Composition over Inheritance
+    -LSA Single Layer of Abstraction 
+    -YAGNI You Ain’t Gonna Need It
+    -IOC Inversion of Control 
+    -DI Dependency Injection
+
+
+### Erkenntnis → Was kann ich für das Gruppenprojekt anwenden?
+
+Die Kenntnis der Programmierparadigmen vereinfacht die Wahl des geeigneten Programms für das Programmieren eines Spiels. Die Design-Prinzipien vereinfachen das Codieren und machen die Software verständlicher.
+
+
+### Wiederholung → Einen Begriff/Ein Thema in eigenen Worten erklären.
+
+Programmierparadigmen ist eine Zusammensetzung aus verschiedenen Techniken und Ansätzen. Es beschreibt einen fundamentalen Stil eines Programms bzw. wie das Programm entworfen worden ist. Die Mehrheit der Programmiersprachen beschränken sich nicht nur auf ein Paradigma.
+
+
+###Kritik → Was möchte ich dem Dozenten mitteilen?
+
+
+
+
+## SU 03  Lerntagebuch   (15.11.2022)
+##Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+
+- Entwurfsmuster sind erprobte Lösungsschablonen für wiederkehrende Entwurfsprobleme bzw. es sind bestimmte Konstruktionsvorschriften, die helfen ein bestimmtes Problem zu lösen. 
+
+- Es wird im Makro-Design für Modulebene und im Makro-Design für Klassenebene angewendet
+
+-Entwurfsmuster teilt sich auf:
+    -in Erzeugungsmuster (creational) → Erzeugung von Klassen und Objekten
+    -in Strukturmuster (structural) → Aufbau und Organisation vom Klassen und Objekten
+    -in Verhaltensmuster (behavioral) → Beeinflussung von Klassen und Objekten
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+
+Während des Programmierens unseres Codes kann zu den Programmierfehlern kommen, den zu finden als unmöglich scheint. In diesem Punkt wäre es nicht verkehrt, sich mit dem typischen Entwurfsmuster auseinanderzusetzen und analysieren, wo der Fehler in unserem Quellcode sein könnte.
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+
+Entwurfsmuster beschreiben, wie ein bestimmtes Problem, das schon bei vielen Programmierer zuvor aufgetreten ist, in einem Code auch gelöst werden könnte.
+Design Pattern zeigt vor allem, wie man bestimmte Fehler und Probleme in seinem Code lösen kann.
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+Es wäre schöner, wenn Sie noch mehr ins Gespräch mit den Studenten während der Vorlesung  kämmen. Zum Beispiel durch Fragen stellen, wo die meisten sich angesprochen fühlen könnten, dies lockt nämlich deren Aufmerksamkeit.
+
+
+
+
+
+## SU 04  Lerntagebuch   (15.11.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+-Git und seine Vorteile:
+    • Der Zugriff auf letzte gespeicherte Arbeit ist immer möglich
+    • Zugriff auf Produktion, Entwicklung
+    • Vergleich zwischen vorherigen Versionen möglich
+    • Einfach Lokal zu speichern/ kopieren
+    • Einfach zu verstehen und einfache Methoden
+    
+-Git ist zentralisiert, also die Geschichte bzw. Verlauf existiert auf einer zentralen Netzwerkressource. Die Entwickler haben nur eine funktionale Kopie von der Datei.
+    Pro:
+    • Jeder Commit ist für jedes Gruppenmitglied verfügbar
+    • Man kann immer auf die aktuelle Datei zugreifen und die umändern, was für jeder sichtbar ist
+    • Eine zusätzlich Kopie
+    • unbegrenzte Ressourcen für das Repository
+
+    Contra:
+    • Das parallele Arbeiten verursacht mehrere verschiedene Dateien aus einer Datei.
+    • Nach dem Puschen verschiedenen Dateien von verschiedenen Glieder, kommt zum Merg, also alle Dateien werden zusammen gefasst
+    • Online Arbeiten nicht möglich
+    
+-Git ist verteilt, das heißt, dass jeder Entwickler seine eigene Version der Geschichte hat.
+    Pro:
+    • Es erfordert keinen zentralen Server
+    • Jeder kann es auf seinem eigenem Computer, Lokal es bearbeiten 
+    • Keine direkte Kopie
+    • Lokale Experimente bleiben privat
+    • Funktioniert auch ohne ständigen Internetzugang
+
+    Contra:
+    • Die Lokale Geschichten sind nicht mit einander synchronisiert
+    • Die Datei wird nicht mehr geschützt, wenn gleichzeitig Veränderungen vorgenommen werden
+    
+-In dem Konzept von Git, hauptsächlich geht es darum, zu zeigen, wie viel Mal eine Datei verändert worden ist. Jedoch, es basiert nicht auf Dateien. Hier gibt es Branches, die etwas Vergleichbares wie eine Etikette bzw. Beschriftung für den Commit ist. Sowie eine Staging area, die eine Datei ist, die das Teil den nächsten Commit wird, was in Grunde die Datei verändern wird.
+
+-Kurze Commits verwenden, diese ermöglichen automatische (oder manuelle) Lösung der Konflikte. Dadurch ist auch der Verlauf mehr detailliert und übersichtlicher aufgebaut, sodass die Veränderungen einfach zu finden sind.
+
+-Saubere Commits also erst committen, wenn das ganze Projekt alle Tests bestanden hat und alle wesentliche Informationen enthalten sind.
+    • Committen, wenn:
+        ○ ingle New Behavior abgeschlossen worden ist
+        ○  Single Refactoring-Schritt abgeschlossen worden ist
+        ○ Merge/Rebase-Konflikte behoben worden sind
+    
+-Branches unterteilt sich in:
+    • Master => eine Standardbezeichnung
+        ○ Wird vom ursprünglichen Commit erzeugt
+        ○ Unendliche Lebensdauer
+        ○ Alle Commits haben eine Versionsnummer
+        ○ Es sind keine direkten Commits, sondern Merge
+        
+    • Hotfix => Schnelle Reparatur zu dem Code
+        ○ Haben kurze Lebensdauer
+        ○ Kommen direkt von Master 
+        ○ Jeder Entwickler kann es committen
+        ○ Merge zurück zu Develop und Release
+    • Release => entstehen aus Develop, wird veröffentlicht 
+        ○ Kurze Lebensdauer, nur währen Feature frezze
+        ○ Es ist keine neue Feature, wenn dann nur kleine Reparaturen
+        ○ Jeder Entwickler kann es committen
+        ○ Merge zurück zum Develop
+    • Develop => Hier wird Code entwickelt
+        ○ Unendliche Lebensdauer
+        ○ Erster Commit startet das Programm
+        ○ Ist immer Versandbereit, alle autDmatische Test sind bestanden
+        ○ Jeder Entwickler kann einen versandfertigen feature commiten
+    • Feature =>
+        ○ Begrenztes Lebensdauer
+        ○ Kommen von develop und kehren dahin zurück
+        ○ Nur zugewiesene Entwickler sollen committen
+   
+-Merge
+    Nutzen:
+    • Ein sichtbarer Verlauf der Parallelarbeit
+    • Die Lösung des Konflikts nur ein mal möglich
+    • konfigurierbare automatische Konfliktlösung
+
+    Nachteile:
+    • Komplexer Arbeitsverlauf
+    • Konfliktlösung zwischen Zuständen
+    
+    Wähle Merge wenn:
+    • Aktueller Branch ist ein Developer oder Master
+    • Der Verlauf soll synchronisch zu der Zeit und Ort sein
+    •Dein aktueller Branch war schon mindestens einmal ,,gemerge' (merged).
+    
+-Rebase 
+    Nutzen:
+    • Sauberer Verlauf = Alle Feature werden nacheinander übertragen
+    •  Lösung des Konflikts mit dem Commit (weniger Änderungen auf einmal)
+        ○ Bevorzugt eine automatische Lösung
+        ○ Einfacher eine manuelle Lösung
+    Nachteil:
+    • Verlauf zeigt nicht wie die genaue Zuordnung war
+    • Solche Commits können widersprüchlich sein
+    • Die Commits haben dann keinen Verlauf, wovon sie entstanden sind
+    
+    Wähle Rebase wenn:
+    • man an einem Feature immer noch arbeitet, er unvollendet ist und noch nicht mit den anderen Branchen verbunden werden soll
+    • Für sauberes Verlauf
+    • Um ”squash-commit” zu vorbereiten
+    • Eigener Branch viele Commits hat
+    
+    
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+Git zu verstehen ist sehr wesentlich, denn so kann die Gruppe genau und transparent arbeiten. Je mehr Entwickler (bzw. Mitglieder einer Gruppe), desto mehr Commits, die miteinander verknupft werden müssen. Deswegen kurze und saubere Committs vereinfachen der Gruppe die Veränderungen nachzuvollziehen und zusätzliche Fehler möglich schnell bekämpfen zu können.
+
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Git besteht aus unterschiedlichen Committen, die sich wiederum aus verschieden Branches zusammensetzten. Diese haben seine Funktionen und dadurch vereinfachen sie das Arbeiten im Git, als auch machen den Verlauf übersichtlicher. Wenn zwei Commiten gleichzeitig entstehen, die sich auf die gleiche Programmierzeile beziehen, kann man den Commit mit Merge und Rebase umändern.
+
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+
+
+
+
+
+## SU 05  Lerntagebuch   (23.11.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+
+-Software-Projekte:
+    -Die Softwareprojekten werden nicht mehr einzeln ausgeführt, heutzutage ist es hauptsächlich eine Zusammenarbeit mehrerer Programmierentwickler. 
+    -Da die Komplexität des Arbeitsprozesses steigt, sind diese in spezialisierte Arbeitsgruppen aufgeteilt, sodass ist die Einzelarbeit fast ausgeschlossen. 
+    -Jeder beeinflusst jedem
+
+-Da die Leistungen Einzelpersonen zusammengeführt werden und dabei sich verschiedene Sichten entwickeln, kann es meistens zu technischen als auch persönlichen Konflikten führen
+
+-Vorteile von CI Systemen
+    -Automatisierung des Prozesses, die den Aufwand verringern
+    -Ausführen von den automatischen Tests, die den Arbeitsprozess beschleunigen, da es auch im Hintergrund laufen kann.
+    -Konfliktpotenzial ist geringer, wenn formale Prozesse eingesetzt werden
+    
+-Softwareentwicklungsprozess:
+    -Entwicklung des Programms zu dem jeder Entwickler Zugang hat und das Programm bzw. den Code sehen kann. Es ist am sinnvollsten, die neuste Version des Programms zu haben, um sich die Zeit und den Aufwand sparen zu können. Code kann auch von Entwicklern umändern werden, falls es nicht über einstimmig ist. 
+    -Zu beachten ist, dass nur einzelne Versionen gespeichert werden
+    -Letztendlich wird ein Lieferprojekt erzeugt.
+
+    -Semantische Versionierung:
+    MAJOR => einer Änderung bedeutet, dass es nicht mehr kompatible ist
+    MINOR => es sind zusätzliche Features, die zu des anderen Programmteil verträglich bleibt (Abwärtskompatibel)
+    PATCH=> die Fehler werden dadurch beheben, diese Veränderung ist für den Programmierteil abwärtskompatible 
+
+    -Regeln der semantischen Versionierung:
+    - ausschließlich Ziffern und Punkte 
+    - MINOR und PATCH werden unabhängig voneinander inkrementiert 
+    - wenn MAJOR erhöht, wird werden MINOR und PATCH auf 0 zurückgesetzt. 
+    - wenn MINOR erhöht wird, wird PATCH auf 0 zurückgesetzt. 
+    
+    -Source Code Management System:
+    -Der Source Code, auch als Quelltext oder Quellcode bezeichnet, ist der für Menschen lesbare Text in einer Programmiersprache. Ein Computer kann diesen automatisch in Maschinensprache übersetzen und das Programm lauffähig machen. 
+
+    • Eigene Arbeit sowie von den anderen Entwicklern wird gesichert
+    • Die Programmierungen werden bereitgestellt.
+    • Gleichzeitig sich veränderte Datei wird zusammengefügt
+    • Parallele Entwicklung verschiedener Features ist möglich
+    • Wechseln zwischen den Entwicklungsstufen möglich (branches)
+    
+    -Zu den Erstellungsprozessen gehören:
+    -Ausführung von automatisierten Test
+    -Ergebnisse aus einem Arbeitsprozess => Eine Datei von Quellcode, sodass es zu Lieferprogramm wird
+    -Bereitstellung von Software
+
+    -Build-Tools =>Ein Build-System, auch Build-Tool genannt, ist ein Programm zum automatisierten den Prozess von Erzeugen der Software. Vom Code zum Anwendungsprogramm ermöglichen:
+   make (c~, gnu~) vorwiegend C/C++, keine Abhängigkeitsverwaltung 
+   maven / gradle vorwiegend Java  npm vorwiegend JavaScipt / TypeScript 
+
+-Problem des CI:
+    -Automatisierter Test z.B nach der Arbeit durchführen, um zu wissen, was noch zu verbessern ist
+    -Kompilierbar bedeutet nicht immer, dass es ausführbar ist (bei Testen kann etwas Derartiges rauskommen, deswegen ist testen so wichtig
+    -Das Projekt muss nicht nur kompatibel sein, sondern muss auch funktionieren
+
+
+-Vorteile des automatisierten Tests:
+    -Wenn sich an der Software nicht ändert, kann der Test immer wieder durchgeführt werden und es solle gleiches Ergebnis kommen
+    -Im Vergleich zu dem manuellen Test, sind der automatisierte Test laufen immer wieder wiederholbar, dazu ist es viel schneller als manuelle Tests.
+
+
+-Grenzen automatisierter Tests:
+    -finden nur Abweichungen von gewünschten/bekanntem Verhalten, also die finden nicht das, was der Entwickler und Tester übersehen hat.
+    -finden keine neuen fachlichen Fehler 
+
+-Gemeinsames remote Repository:
+    -Alle Entwickler arbeiten gegen denselben Repository, zu der jeder Zugriff hat
+    -Vorteil: einfache Synchronisation
+    -Puschen=> für alle wird sichtbar und nutzbar
+
+
+
+-Privater fork:
+    -es gibt ein zentrales remote Repository (= master), sowie ein separates remote Repository (= fork), das jeder Entwickler hat
+    -Jede lokale Repository hat 2 remote Repositories, origin also master, kann nur gelesen beziehungsweise nicht umgeändert werden, sowie Upstream, ein privater fork (eine Repository mit den Schreibrechten) 
+
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+
+Die Nutzung des CI Systems und desen automatisierten Tests, kann den Gruppenprojekt vorschnellen, vor allem der manuelle Tests sehr demotivierend sein könnten. Da die Softwareentwicklung von technischen als auch persönlichen Konflikten betroffen sein kann, ist es bedeutungsvoll verschiedene Sichten des Entwicklers zu berücksichtigen, sowie die in Betracht ziehen. 
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Softwareentwicklung ist heutzutage hauptsächlich nur möglich, wenn die Entwickler zusammen miteinander arbeiten und die dabei entstehende Probleme gemeinsam lösen. Um diese Arbeitsprozesse zu erleichtern, gibt es ein Continous Integration (CI) System, das automatische Tests des Softwareprogramms durchführt. Ein anderer sehr bedeutsamen Systeme ist Source Code Management (SCM) System, welches die Arbeiten der einzelner Entwickler speichert oder diese zur Verfügung gestellt werden.
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+
+
+
+
+
+
+## SU 06  Lerntagebuch   (30.11.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+- Grundlagen:
+    - Regelprozess-Nicht alles, was im Unternehmen ist, sind Projekte, es existieren auch Prozesse
+    - Linienmaßnahme-Organisationseinheit, welcher allein bearbeitet werden kann, ohne Unterstützung
+    - Projekt, wenn das Vorhaben, finanzielle und Personalressourcen zuordnet sind, definiert es externe Ressourcen
+    - Komplexe Handlungsabläufe -> fachübergreifend
+    - Risiko-> nicht alle Informationen vorliegen, die vorsagen, wie alles vorlaufen wird. 
+    - Risiko weil: ein Projekt ist einmalig, immer unterschiedliche Rahmen, ist anders, d.h das, was in einem Projekt funktioniert hat, muss nicht in den nächsten funktionieren. Sich nicht auf vorherige Projektabläufe und Prozesse verlassen.
+    
+- Projekt Beispiele:
+    - Organisationsprojekte ->  die Struktur des Unternehmens wird verändert
+    - IT-Projekte -> Software Projekte als auch IT Projekte 
+    - Mitarbeiter - einmaliges Projekt für einmaliges Zweck-> Weiterbildung ist sehr wichtig
+    - Kundenaufträge -> sind bei kleinen firmen wie Projekte
+    
+- Projektmanagement ->  formuliert, was man erreichen will und wie man dahin kommt
+    - Kontrolle -> Ist das Ziel des Projekts erreicht? 
+    - Sammeln von Informationen -> Welche Optionen habe ich überhaupt, dieses Ziel zu erreichen, z.B Programmiersprachen, welche Skills werden benötigt
+    - Erkennen der Idee ->(Sehr oft)Kunden wissen nicht, welche Möglichkeiten sie mit der Software bekommen Planung - Zeit, Personal, Geld, welche Abläufe werden stattfinden
+    - Organisation>Rechner, System - Umsetzung
+    - Beziehung zwischen Menschen und Verhaltungsregeln im Team sind eine Priorität
+    - Konflikte immer auf persönliche Ebene -> sachlich zuerst aber im Grunde persönlich, die das Projekt und Zusammenarbeit beeinflussen.
+
+- Rollen im Projektmanagement:
+    - Arbeitgeber bestimmt:-> z.B Rechnertausch,  Zeitplan für den Arbeitgeber (ist entscheidend),  welche Kosten, was ist für den seine Firma wichtig
+    - Projektleiter -> wie viel Geld bleibt am Ende?, Projektmitarbeiter entscheidet, wann und was fertig wird, falls Probleme auftreten, den Vorgesetzten informieren, damit alles zeitlich geschafft wird (frühseitige Intervention).
+    - Projektmitarbeiter -> programmiert, bearbeitet die Teilaufgaben
+    - Betroffene ->Vorgibt, welcher Datenbank zu benutzen ist (technische Einschränkungen), rechtliche Rahmenbedingungen
+    
+- Modelle:    
+    - Wasserfall Modell->  jede der Fase (Prozessschritte) läuft linear und nur ein mal ab.
+    - V - Modell ist eine Erweiterung des Wasserfalls Modells -> alles auf der linken Seite wird mit dem Test auf der rechten Seite übergestellt.
+        - Jeder dieser Schritte wird aufgeteilt, von unten nach oben 
+        - Maschinenbau -> lässt sich gut mit WFM abbilden
+        - Am Anfang steht ganz oft nicht fest, wie das Projekt verlaufen wird
+    - Agile Modelle:
+        - nachdem Zeitfestlegung 
+        - Scheitert das Projekt, weil Geld und Zeit schlecht angepasst würde (fehlt min, einer)
+        - Aufwand und Zeit festlegen und ein einsetzbares, funktionierten  Projekt schaffen, wenn Zeit reicht dann mit Features verbessern.
+        - Dokumentation ist wichtig, jedoch lieber Aufwand in Programmierung hereinstecken als für die Aktualisierung des Dokuments
+        - Wenn Kunde etwas anders haben möchte, ist wichtig seinen Bedürfnissen nachzugehen, auf ihr hören, denn er wird die Software am Ende nutzen
+- Techniken:
+    - Kanban => zum Beispiel: Fahrzeugproduktion
+        - Gut überschaubare kleine Teile zerlegen mit überschaubarer Zeitplanung
+        - Backlog -  dort werden die Aufgaben gesammelt, dadurch wird der  Aufwand gekannt.
+        - Im Workflow-Darstellung sind schon fertige Aufgaben 
+    - Burn-Down-Chart
+        - Relativ gleichmäßige Aufarbeitung der Aufgaben
+        - Arbeitspakete mit geschätztem Aufwand. Arbeitspakete ändern sich nicht
+- Scrum:
+    - Softwareentstehung ->Aufwand und Zeit fixieren (14 Tage Orientierung)
+    - regelmäßige Meetings werden am Anfang geplant, es muss berücksichtigt werden, wie viele Story Points ein Team bzw. Teammitglied schaffen kann, wird auch besprochen, was jeder gemacht hat, wo stehen geblieben ist 
+    - Wie viele Story Point hat, man in dem Sprint geschafft uns so wird abgeschätzt wie viel in nächsten Sprint gemacht wird
+    - Kein Wettbewerb zwischen den Teams also man vergleicht es aber nicht zwischen den Teams
+
+- Aufwandsschätzung:
+    - man weiß nie genau wie viel  Zeit und Aufwand ein Projekt nimmt, deswegen verwendet  man die Schätzmethoden 
+    - Schätzverfahren müssen nachvollziehbar sein, die sollen liefern, wie komplex eine bestimmte Aufgabe ist und welcher Zeitaufwand dabei entsteht
+    - Zeit ist mit der Aufwand verknüpft
+    - Schätzverfahren sollten möglich kurz dauern und wenig kosten 
+    - Vorteil:  die Story Points bleiben die gleichen, egal welcher Mitarbeiter sie ausführt,
+    - Jeder muss man die Schätzung anpassen
+    - Wie viele Point als Team in einem Sprint  geschafft werden kann
+    - Schätzen den Aufwand für Testen 
+    - Zeit für automatisierte Test einplanen 
+    - Je später fangen sie mit der Schätzung einer Aufgabe, desto genauer ist die Schätzung, denn erst sieht man wie viel zu tun ist
+    - Es ist besser für den Kunden und Vorgesetzten (Projektmanager), wenn Projektmitarbeiter ein Nein sagen kann. Ein Nein ist wichtig, wenn man Zweifeln hat, dass irgendetwas zeitlich nicht geschafft wird ,,Nein" Sagen ist kein Fehler oder Schwäche.
+    - eine Aufgabe mir 3 Werten messen:
+        - Erwartet normaler Aufwand, wenn alles wie erwartet abläuft
+        - Minimum => Was ist, wenn die dinge die ich als aufwand für diese Aufgabe gar ich notwendig sind
+        - Maximum => was, wenn nichts läuft? - wie viel Zeit braucht ma,  um den Features zu schreiben, trotz der Widerstände.
+    - wenn man nicht ganz neu in dem Geschäft ist, hat man Erfahrung
+    - dennoch, wenn man neu ist, sollte man die Erfahrung der Kollegen nutzen, nachfragen, wie viel Zeit und Aufwand oder welche Werkzeuge sie benutzt haben
+    - Planning Poker
+        -> je komplexer sie ist, desto großer die Aufgabe und die Schätzung 
+        -> jeder für sich soll die Aufgabe schätzen, dann werden die Schätzungen aufgedeckt 
+        -> Befragung der Teammitglieder, die extremen Werte (oder Zeit) eingeplant/eingegeben haben
+        -> Bildung eines Mittelwerts, wenn mehr als 3 verschiedene Zahlen eingeplant wurde
+
+- Dokumentation:
+    Klassisch:
+        - Lastenheft wird festgelegt, was die Auftragsgeberin gernhaben möchte (Kunde beschreibt sein Vorhaben)
+        - Systembeschreibung Arc42 ist eine Dokumentation für eine Themenbeschreibung eines Softwares (Softwarte Architektur)
+    Agil:
+        - man arbeitet mit Ticketsystem und erzeugt Storys
+        - Der Benutzer definiert, was bzw. welche Reaktion er von dem System/ Software erwartet
+        - User Storys werden im Ticketsysteme gebracht  anstatt der Lastenheft (abgeschafft)
+
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+
+Wenn man etwas nicht kann oder nicht versteht, es ist wichtig sich zu trauen auf die andere Mitglieder zuzugehen, vor allem, dass man zusammen arbeitet. Außerdem können Entwickler dabei sein, die viel mehr Erfahrung haben und Codes anwenden können, die man noch nicht kennengelernt hat.
+Auch die Aufwandsschätzungen sind sehr bedeutend, denn so können wir als Gruppe überprüfen, wie viel Zeit eingeplant worden ist, und überprüfen, ob es richtig eingeschätzt wurde, sowie ob letztendlich für nächstes Treffen mehr Zeit eingeplant werden soll.
+
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+
+Die Planung, die Organisation, die Durchführung und die Kontrolle gehören zu den Prozessen des Projektmanagements, die in Grunde dazu dienen sollen, genauer zu formulieren, was für Ziel man erreichen möchte, sowie wie dieses Ziel letztendlich aussehen soll. Es gibt verschiedene Modelle des Arbeitsablaufes, die diese Prozesse begleiten bzw. unterstützen. Die klassischen sind: Wasserfall und darauf basiertes V-Modell.
+
+
+### Kritik => Was möchte ich dem Dozenten mitteilen
+Das Einführen des Planning Poker in die Gruppenübung hat mir sehr gefallt, denn jeder an das "Spiel" beteiligt war. Es hat die Stunde sehr interessant gemacht und dazu haben wir was Neues auf eine spannende Weise kennengelernt.
+
+
+
+
+
+## SU 07  Lerntagebuch   (07.12.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+- Motivation
+    - Man sollte davon ausgehen, dass jeder Mensch Fehler macht, deswegen ist es sehr wichtig zu überprüfen, ob oder sogar welche Fehler vorhanden sind.
+    - übersehbare Fehler, sowie nicht realisierte Gewinne sind sehr teuer
+    
+- Grundlagen
+    - Qualitätssicherung => Abteilung die sich um den Endprodukt kümmern, bzw. dass es den Normen sowie Ansprüchen/Wünschen angepasst wird
+    - Testmanagement =>dazu zählt Konzeption, Planung, Schätzung usw.
+    - Testumgebung => Umfeld in der sich unsere Software bewähren muss. Testumgebung ist definiertes Bedienung für die Testentwicklung
+    - Test =>  ein methodischer Versuch, der die Eigenschaften und Leistungen überprüfen soll
+    - Prüfen =>   wird festgestellt, wieweit und ob ein (Prüf)Objekt eine bestimmte Forderung erfüllt. 
+    - Software =>Beziehen sich auf Test bzw. Prüfung 
+    - Fehler => Anforderungen die in der Dokumentanion enthalten sind
+    - Ereigniskette => eine Person macht Fehler - Error, was zu einem Defekt führt und in Endeffekt zum Fehlerverhalten des Programms
+    - Akuter => bei normaler Programmausführung, direkter Verstoß gegen die Anforderungen
+    - Latenter => besteht alle Test, genau die laufen in die Produktion. Ein Fehler in einer Stelle verursacht einen Fehler auf einer anderen Stelle
+    - Maskierter Fehler  => kann erst gefunden werden, wenn der andere Fehler gefunden ist
+    - Nur weil der Test keine Fehler gefunden hat, heißt es nicht dass das Programm fehlerfrei ist!
+    - Fehler der zu einem Defekt führt:
+        - Syntaktisch =>wird meistens vom Compiler erkannt
+        - Semantisch =>Irrtum an Bedeutung des Wortes
+        - Lexigraphisch
+        - Logisch =>ein Gedankenfehler
+        - Design => ist nicht geeignet oder die Programmiersprache ist nicht angepasst
+
+- Testmethodologie
+    - Arten:
+        - Automatisierte Test
+        - Manuelle Test
+        - Statische Codeanalyse = funktioniert das, was im Code steht
+        -Dynamische Tests = Vollständige Ausführung des Programms
+    - Bestandteile: 
+        - Jeder einzelner Test ist eine Stichprobe
+        - Definieren was man testen möchte (Testdaten) und welches Ergebnis man erwartet
+        - Testobjekt
+        - Testumgebung => PC usw.
+        - Testziel => Test ohne Ziel ist nicht Wert, Zielformulierung ist sehr wichtig, 
+        - Wertevergleich => sind die Erwartungen erfüllt worden? Welcher Wert ist korrekt oder akzeptierbar, muss der Mensch entscheiden
+    - Testziele => jeder hat einen bestimmten, hauptsächlich vorzeigen vom Fehlern
+    - Qualität => wie viele der Anforderungen werden erfüllt
+    - Testen der Stabilität
+    - Der Test sagt nicht wo genau der Fehler ist, deswegen lieber kleine Stück des Codes testen um schneller rauszufinden wo genau der Fehler sich befindet = Separates Testen jeder Teil eines Codes (Bestandteile)
+    - Je weniger Tests desto größerer Potenzial eines Fehlers/Absturz des Programms
+
+- Testprozess
+    - Entwurfsmethode -> Testfällen Ermittlung
+    - Beeinflusste / liegt Umgebung fest
+    - Fehlerverhalten => Welches Fehler genau?
+    - Fehlerkategorie => hoch, mittel, niedrig
+    - Testreport => er fasst das Ergebiss aller vorherigen Test zusammen
+    - Vergleich von Testausführungen
+    - Lieferfähig heißt nicht, dass es keine Fehler existieren. Nun die Fehler beeinflussen den Programm nicht
+
+- Psychologische Aspekte
+    - Warum ist Test unbeliebt? => Niemand gibt den Fehler zu, es wird nicht gut angesehen, führt zur Spannung
+    - Wir sind nicht in der Lage unsere Lösung objektiv zu bewerten, deswegen sind andere Entwickler gebraucht, die unser Programm objektiv testen
+    - Entwicklertest /Fehler gut formulieren
+    
+    
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+Durchführung von Tests ist sehr wichtig, denn so findet man Fehler, die die Software negativ/ungünstig beeinflussen oder das Programm nicht laufen lassen. Jedoch man kann sich nicht nur auf Test verlassen, denn nicht immer werden alle Fehler entdeckt.
+Wenn ein Mitglied der Gruppe ein Code schreibt, sollte es noch von jemanden angeschaut oder überprüft werden, denn derjenige eine andere Perspektive haben kann.
+
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Dank des Testes von Software kann man Fehler im Programm herausfinden, die dann letztendlich nicht zum Defekts der Software führen. Es gibt verschiedene Fehler, sowie darauf folgende Fehler, die für die Entstehung verschiedene Defekte beeinflussen.
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+
+
+
+
+
+## SU 08  Lerntagebuch   (14.12.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+- Automatisierter Test ist kein vollständiger Ersatz für manuellen Test
+- Je länger man mit dem Test beschäftigt ist, desto eher verliert man den roten Faden
+- Testprotokoll ist die Abspreche, wobei jeder kann es anders verstehen = Komplikationen
+- Tester muss gut ausgebildet sein, sowie muss die Prozesse der Software verstehen, um das Ergebnis des Testes gut bewerten zu können = wissen über Fachlichkeit
+- Testwerkzeuge zum Beispiel Exceltabelle
+- Aufwand = jeder Testdurchlauf erfordert Menschen => Langsamkeit sowie Arbeitszeit
+- Geringe Kosten = geringe  Qualität
+- Qualität steigt = steigen auch die Kosten
+
+- Gründe, um automatischen Tests nicht zu machen:
+    - Nur User Interface => Programm ist zu komplex und/oder Fehlende Testumgebung
+    - Geerbter Code =>Zu höher Auswand und/oderDeadline
+
+-Kriterien für automatischen Test:
+    - Test, der sich einfach maschinell überprüfen, wiederholen, als auch testen lässt, hat eine hohe Bedeutung 
+- Ein begrenztes Codeabschnitt = Unittest
+- Modultest = testet, ob die richtige Rechnung gewählt wurde
+
+- Applikation/Module-Tests => späte Ausführung im Entwicklungsprozess, komplexe Testwerkzeuge, aufwendig zu warten, zeigen die Existenz vom Fehler, jedoch nicht genau, wo er sich befindet, d. h.. Man muss selber feststellen.  Wo der Fehler liegt
+- Unit-Teste unterscheiden sich genau in oben genannten Punkten, laufen früh im Entwicklungsprozess, Werkzeuge sind einfach, Fehler werden gezeigt und Unittest ist gegen Änderungen stabil
+
+- Ein Unittest dokumentiert, was man an Anforderungen verstanden hat und ob es erfüllt ist oder nicht. Hier werden keine Code oder Implementierung, sondern Verhalten von Code getestet. Dabei ist zu beachten, dass nur eine einzige Erwartung wird getestet. Wenn man mehrere Soll Bereiche hat, wird nur zu dem ersten Fehler bearbeitet, der Rest nicht mehr
+
+- Ein Unittest - muss genug schnell sein, damit man direkt während des Arbeitens Test durchführen kann, 
+voneinander unterschiedlich sein, ein Test kann nicht von anderen Test abhängig sein. Dazu muss es auch wiederholbar und 
+digital sein, Soll-Ist-Vergleich muss innerhalb des Testest durchgeführt werden. Außerdem muss es zeitnah sein. 
+Erst wird der Code geschrieben, dann Unittest => Probleme: zu enger Beziehung, wird nur Code getestet, nicht sein Verhalten. Erst Unittest dann das Verhalten implementiert/umsetzt => Probleme: weiß man nicht, ob die Merge oder Test nicht gut sind
+
+- Da Tests und Code werden mehrmals gelesen als geschrieben, müssen die kurz wie möglich sein und Eigenschaften der Parameter und Ergebnisse anlegen
+- Zusätzlich Tests müssen sehr einfach geschrieben sind, denn je komplizierter, desto mehr Fehler können vorhanden sein. 
+
+- Arten von Test-Doubles
+    - Stub=> Minimal interpretierter Interface
+    - Fake => Höhere Form vom Stub, hier stehen hart codierte werde, die wir für den Test konfigurieren
+    - Vereinfachen bedeutet beschleunigen
+    - Mock=> zusätzliche Infrastruktur, antwortet auf die Fragen: welche Methoden, wie oft
+
+- Geschriebener Test kann später in andrem Kontext benutzt werden
+- Wenn man von Anfang an clean Code schreibt, so verhindert man die Fehler und langes Testen
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+Am besten kleine Abschnitte unseres Codes mit Unittest testen, denn so findet man eigene die Fehler oder auch von den anderen Entwicklern. Je mehr Tests man als Gruppe macht, desto "sicher" der Code ist, was die Spannung in der Gruppe entnimmt. Es ist sehr wichtig automatisierte, als auch manuelle Tests zu machen
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Die Unittests haben die Aufgabe, die Geschäftslogik zu überprüfen, wobei Applikationen oder Module-Tests für die Verdrahtungssystem verantwortlich sind. Beim Testen ist es wichtig das Verhalten vom Test zu testen, nicht den Code oder die Implementierung. Ein guter Unittest muss schnell, unabhängig, wiederholbar, zeitnah und selbst auswertend sein
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?
+
+
+
+
+
+## SU 09  Lerntagebuch   (21.12.2022)
+## Daria Popa        fdai7460        Matrikelnummer:1436682
+
+### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
+- Sicherheit schafft vertrauen
+- In dem Graphen der Kostenoptimierung, Testen drucken die Kurve nach unten
+- Die Unittest zu schreiben und mit der Anwendung zu entwickeln
+- Es ist wichtig, die Unittest zu schreiben und mit der Anwendung zu entwickeln
+- Unittest ist vertrauenswürdig, wenn Produktivcode tatsächlich ausgeführt wird und wenn der Test aus dem richtigen Grund Fehler schlägt
+- Units entstehen zeitnah zum getesteten Code
+- Vom allen automatisierten Tests, wird am häufigsten Unittest gewählt. Zur Erstellung dieser geeignet wäre Test Driven Development
+- Testabdeckung führt zu dem Vertrauen
+- Test Driver Development  führt zu 100 % Anforderungsabdeckung
+
+- Vorgehen:
+    - Entwicklungsprozess wird formalisiert. Es gibt einen definierten Prozess
+    - Kleine Schritte = Weniger Fehler
+    - Flow bei Programmieren => man verpasst(sieht nicht) andere Umsetzungsmöglichkeiten
+
+- TDD micro cycle:
+    - Anforderungsdokument im Vordergrund haben
+    - So viele Produktivcode schreiben, bis der Unittest sich damit kombiniert lässt
+    - Refactoring  = hier wird der Code sauber gemacht, in Ordnung gebracht
+    - In einer kürzeren Zeit sollen wir eine Rückmeldung bekommen, ob man auf dem richtigen Weg ist
+
+### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
+Besser ist es, den Test in kleine Schritte zu zerlegen, denn so verhindert man Fehler.
+
+### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
+Test Driven Development benutzt man, um Unittest zu erstellen. Unittest ist ein der häufigsten benutzten automatisierten Test in dem Softwareentwicklungsprozess.
+Test Driven Development gibt Sicherheit und dies in Folge schafft das Vertrauen. Je mehr man Tests durchführt, der mehr Sicherheit, dass das Code richtig ist und das Vertrauen in Tests.
+
+### Kritik => Was möchte ich dem Dozenten mitteilen?