‏ ‏ ‎ ‏ ‏ ‎

1. 2025-09-16

  • Memory Types: Stack/Heap

  • Value Type/Reference Type

  • Call by Value/Call by Reference

  • Distributed vs centralized version control

2. 2025-09-23

Testtermine:

  • 2025-11-25 2025-12-02: 1. Test

  • 2026-01-13: 2. Test

  • 2026-04-21: 3. Test

  • 2026-06-09: 4. Test

2.1. Static Site Generators

https://jamstack.org/generators/

  • Was sind Static Site Generators (SSG)?

  • Vorteile von SSG

  • Bekannte SSG

2.2. Einführung git

Fragen:

  • Was ist ein VCS?

  • Welche Probleme lösen VCS?

  • Unterschiede zwischen git und VCS wie zB SVN? (verteiltes vs zentrales VCS)

  • git - clients

  • git - workflow

    Antwort
    git architecture

  • Unterschied zwischen git und GitHub/gitlab/bitbucket/…​?

  • Wie erstellt man ein lokales Repository?

  • Was ist ein Repository?

  • Unterschied zwischem rm und git rm?

  • Was ist der Unterschied zwischen git commit und git push?

3. 2025-10-07

Fragen:

  • Was ist eine Machbarkeitsstudie (feasibility study)? Wozu dient sie? Nenne ein Beispiel.

  • Inhalt eines Projektantrags?

  • Was versteht man unter Projektvarianten?

    • Wozu dienen diese?

  • Wie kann man Projektvarianten bewerten? Antwort: SWOT-Analyse

    • Wie ist eine SWOT-Analyse aufgebaut?

    • Warum ist eine SWOT-Analyse sinnvoll?

3.1. Zielbestimmung

siehe Buch Kap. 2.3

magische dreieck
projektziele
effektivitaet vs effizienz

Fragen:

  • Nennen und erläutern Sie die 3 Kategorien von Projektzielen. (Antwort: Magische Dreieck: Leistung, Termine, Kosten)

    • Durch welche Kategorie kann das Magische Dreieck ergänzt werden? (Antwort: Qualität)

  • Merkmale der Zielsetzung? (Antwort: erreichbar und quantifizierbar)

    • Bsp für ein messbares Ziel (quantifizierbar)?

  • Was versteht man unter Operatiionalisierung von Zielen? (Antwort: Ziele so lange in Unterziele zerlegen, bis sie messbar sind)

    • Nenne ein Beispiel.

  • Welche Zielbeziehungen gibt es? Nenne und erläutere diese. (Antwort: Zielkomplementarität, Zielneutralität, Zielkonkurrenz)

  • Erläutere das Verfahren nach Coverdale?

  • Was ist ein Projektkontext?

  • Was versteht man unter Projektabgrenzung?

    • Warum ist diese sehr wichtig?

  • Was ist ein Stakeholder?

4. 2025-11-04

5. 2025-10-xx

git 12 most common commands

5.1. Branching

5.1.1. Types of Branches

  • Feature Branch

  • Bugfix Branch

  • Hotfix Branch (wie Bugfix nur dringender)

  • Main Branch (Release Branch)

    Main Branch wurde früher Master Branch genannt

  • Develop Branch

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

5.1.2. Branching-Strategies

No-Flow
no flow
Figure 1. No-Flow in Programster’s Blog
Git-Flow Workflow
GitHub Flow

5.2. Stashing

6. 2025-11-05

6.1. Forks and Pull Requests

In case somebody wants to contribute to a repo (owned by another person or organization) a fork of the original repo has to be done. The contributor can now change the forked repo without any limitations. When the contributor to get their changes back into the original repo they do a pull request, i.e., the contributor asks the owner to merge the changes back to the original repo.

merge request scenarios.001

A fork of a repo can be seen as a smart copy of the original repository. Smart in this sense that the fork has a "backlink" to the original repo and is aware if the original has changed. As a contributor be aware if you ask for a pull request to have your fork synchronized with the original before creating a merge request.

merge request scenarios.002

6.2. Exercises

Work in pairs (called Student A and student B in the sequel) and accomplish the following tasks.

6.2.1. Simple Pull Request

  1. A creates a repository with one text file Readme.md.

  2. B forks it and clones it

  3. B makes some changes to Readme.md commits them and pushes them

  4. B creates a pull request to A to get the changes back to the original

Play around with the GitHub UI to get used to it. Reflect the different directions when to compare the pulled changes. Look closely on the arrows in the UI.

6.2.2. Sync A Given Fork

  1. A does some changes to Readme.md` commits and pushes

  2. B reloads their fork to get the info that the original has changed

  3. B syncs the changes

Again try the different scenarios GitHub offers (direct syncing, comparing) and get acquainted to the UI and functionality.

6.2.3. Create a Pull Request from a Non-Synced Fork

  1. A changes their repo and B reloads but does not sync!

  2. B changes their repo (same file and line as A) and creates a pull request

See what happens. How to deal with merge conflicts? How to avoid these?

6.2.4. Pull Requests from a Non-Synced Fork But Using a Branch

  1. A changes their repo and B reloads but does not sync!

  2. B creates a new branch, changes the same file and line as A and creates a pull request

Look again what’s happening? Prepare for a discussion next week about how to deal best with pull requests and especially which discipline to establish to avoid pain.

7. 2025-11-11

informationswuerfel

8. 2025-11-19

8.1. Merging vs. Rebasing

8.1.1. Technische Grundlagen

8.1.2. Warum Rebasing?

  • Git: Merging vs. Rebasing (Teil 1)

  • Git: Merging vs. Rebasing (Teil 2)

  • Fazit:

    • Beim Rebasing werden die Commits des Branches in die Historie des Ziel-Branches eingefügt, als ob sie direkt dort erstellt worden wären. Dies führt zu einer geradlinigeren und saubereren Historie, kann jedoch die ursprüngliche Kontextinformation der Commits verändern.

    • Beim Merge hingegen bleibt die ursprüngliche Historie erhalten, was zu einer komplexeren Struktur führen kann, aber den Kontext bewahrt. Branches werden oft nach dem Merge gelöscht, um die Repository-Historie übersichtlich zu halten.

8.2. Exercises

Work in teams of two students, accomplish the tasks given below and document each step in an adoc or md file. Grading will be done by taking a sample of your documentation. We will especially check the clarity and understandability of your documentation. Think of your document that it could serve as an explanation for your younger sibling (or any other younger relative you have and like) to understand merging and rebasing by reading the documentation of the following two tasks.

8.2.1. Merging

  1. Create a repository, add a file onMain.md and commit

  2. Create a branch a-feature, check it out, create a file onBranch.md and commit

  3. Add some more lines to onBranch.md and commit

  4. View and document the history

  5. Switch back to main branch and view and document the history as well as the content of your repository.

  6. Reflect and document: are there differences between the two histories and contents and why?

  7. Add some more lines to onMain.md and commit

  8. Repeat the last step a few times (at least twice)

  9. Document the history again

  10. Switch back to the feature branch

  11. Merge the main branch into the feature branch

  12. Document the history of the feature branch

8.2.2. Rebasing

Repeat the steps given in the last exercise but instead of merging the main branch into the feature branch rebase the feature branch on the last commit of the main branch. Of course, you need not document the histories etc. what you already did in the first example.

BUT document the history of the feature branch after rebasing. There should be a difference. Analyse and document it clearly.

9. 2025-12-03

Work on the exercises given on November 19. Keep the required documentation of your work. Maybe we need it to tie break unclear grading cases.

10. 2025-12-10

10.1. Forking vs. Templating

GitHub allows two ways to create a new repository based on the content of another:

  • Fork

  • Create from Templates

10.1.1. Forking

  • Creates a new repository with the same name in a different name space

  • Link to the "original" repo is maintained, therefore updates of the original can be merged rather easily into the fork and also the original can get content from the fork easily (Pull requests)

10.1.2. Templating

  • A template is a repository which is especially marked as a Template repo (Settings)

  • When creating a new repository one can choose the option to create it from a template

  • The new repository has no link back to the template

11. 2025-12-09

11.1. Virtualisierung mit Docker

12. 2025-12-23

Projekt 1 2 3 4 (5)

DnD Character Builder.

Marazovic(1)

Mamsaleh(1)

Music(1)

Trkulja(1)

Becer(1)

Dnd MapGenerator

Hadzic(1)

Reitbauer(1)

Grünzweil(1)

Haider(1)

Hasem(1)

Vinylverwaltung

Stoica(1)

Dirnberger(1)

Solomun(1)

Darabos(1)

Dürk(1)

Flashcards

Mostbauer(1)

Brunner(1)

Parzer(1)

Yagci(1)

Mobility Games Recommender

Ibo(1)

Kurtic(1)

Maric(1)

TripPlanner

Hassani(1)

Elgit(1)

Gashi(1)

BetterMindMaps

Heissinger(1)

Lohninger(1)

James(1)

Dönmez(1)

Satybaldy(1)

13. 2026-01-09

13.1. Software-Engineering

  • Buch Kap. 6, S.184ff

methoden im se

  • Vorgehensweise, um von der Realität zum "Modell" zu kommen

    • Top-down-Ansatz

    • Bottom-up-Ansatz

    • der evolutionäre Ansatz

  • Arten des Prototypings

    arten des prototypings

13.2. Phasenkonzepte und Phasenmodelle

  • SDLC - Software Development Life Cycle

    software development life cycle

13.3. Prozessmodelle

Die Begriffe "Phasenmodell" und Prozessmodell" werden synonym als Bezeichnung für die Vorgehensanleitung bei Software-Entwicklungsprojekten verwendet.

  • Phasenmodell ist der ältere Begriff. Er betont die zeitlich klar strukturierte Abfolge von Projektabschnitten. Aus der Bezeichnung der Abschnitte, zB "Analyse", "Entwurf" …., leiten sich die zu erledigenden Aufgaben ab.

  • Prozessmodell ist der neuere Begriff. Er streicht die Tätigkeiten (oder Prozesse) während des Software-Entwicklungsprojekts heraus. Aktivitäten im Projekt sind nicht mehr an eine strenge chronologische Anordnung gebunden, sondern können in kurzen, iterativen Zyklen oder überlappend erfolgen.

  • Bekannte Prozessmodelle:

    • Wasserfallmodell

    • Spiralmodell nach Boehm

    • V-Modell

Grundsätzlich unterscheidet man:

vorgehensmodelle
v modell
Bei den klassischen Vorgehensmodellen legt man i.a. sehr früh die Anforderungen fest und entwirft das Softwareprodukt im Voraus, um es dann zu implementieren und zu testen. Änderungen sind nur schwer möglich.

Darum wurden agile Vorgehensmodelle entwickelt, die flexibler auf Änderungen reagieren können.

v modell scrum

Die agilen Methoden besprechen wir später im Detail.

13.4. Systemanalyse und Anforderungen

Buch Kap. 7, S. 235ff

Da bei den klassischen Vorgehensmodellen die Anforderungen sehr früh festgelegt werden, ist eine sorgfältige Systemanalyse notwendig. Auch kann nun eine Systemspezifikation (Pflichtenheft) erstellt werden.

Spezifikation …​ technische Beschreibung

13.4.1. Anforderungsanalyse (Requirements Elicitation)

(siehe Buch für Details)

  • Interview

  • Fragebogen

  • Beobachtung

  • Selbstaufschreibung

  • Dokumentenanalyse

pdf requirements
Figure 4. Link to the presentation concerning Requirements (click on the image)

Fragen:

  • Welche Arten der Erfassungsmethoden gibt es?

    Antwort

    • direkte Erfassungsmethoden (Daten entstehen im Moment der Erhebung an der Quelle)

      • Interview

      • Beobachtung

    • indirekte Erfassungsmethoden (Daten werden über Aufzeichnungen oder vorhandene Unterlagen gewonnen)

      • Fragebogen

      • Selbstaufschreibung

      • Dokumentenanalyse

  • Interviewformen?

  • Durchführung von Interviews?

  • Phasen bei der Durchführung von Interviews?

  • Vor- und Nachteile von Interviews?

  • Arten von Fragebögen?

  • Fragebogen: Vor- und Nachteile?

  • Beobachtungsformen?

  • Beobachtung: Vor- und Nachteile?

  • Vorgehensrahmen bei der Selbstaufschreibung?

  • Selbstaufschreibung: Vor- und Nachteile?

  • Ist eine Dokumentenanalyse in einer Zeit der Digitalisierung noch sinnvoll?

    Antwort

    Ja, auch wenn es keine Papierdokumente gibt, so sind digitale Dokumente (z.B. Word, PDF, Excel, E-Mails, …​) immer noch Dokumente, die analysiert werden können. Auch Bildschirmformulare oder Reports können als Dokumente angesehen werden.

13.4.2. Pflichtenheft (!)

Fragen:

14. 2026-01-20

  • Persistenz: dauerhaft speichern von Daten. (Wenn die Daten den erstellenden Prozes überleben)

  • Transienz: flüchtig, temporär speichern von Daten

14.1. Docker

14.1.1. Volumes

14.1.2. Ports

15. 2026-01-21

15.1. General Overview on Scrum

15.1.1. The Roles

  • Product Owner: the one who knows the product, has the best technical overview, drives the project, represents the customer’s view

  • Scrum Master: the one who is coaching the team, removing impediments fostering continuous improvement

  • Team: developers, testers, architects, …​

15.1.2. The Most Important Artifacts

  • Product Backlog: Collection of user stories, prioritized and effort estimated; owned by the product owner

  • User Story:

    • A short story that describes a feature.

    • In the form: As a <role> I want to <feature> in order to <reason>

    • This form ensures that every feature described shows who is doing what with the system and why it is necessary to do it.

  • Sprint Backlog: Collection of tasks to be done during a sprint; owned by the team

  • Impediment Backlog: Collection of impediments; owned by the scrum master

15.1.3. Meetings and Folklore

  • Sprint: Period of time where features are implemented

  • Sprint planning meeting:

    • Done at the beginning of each sprint

    • Team defines which stories (based on the prios) to be done in the next sprint and refines them into clear tasks

    • Team and product owner refine the user stories which should come after this sprint

  • Daily scrum: aka Daily standup

    • Max 15 minutes every day where team stands together

    • Every team member tells what did I yesterday, what will I do today, are there any impediments?

    • Scrum master updates the team about the tasks in the impediment log

  • Sprint review

    • At the end of the sprint a shippable product is released and reviewed by the product owner and (ideally) the customer (product stake holders)

    • User stories are ticked off if ok

    • Progress and/or changes in the project are discussed

  • Sprint Retrospective: Team, scrum master and product owner reflect the last sprint: what was good, what was bad, how can we improve?

pdf sw lifecycle
Figure 6. Link to the presentation concerning SW development lifecycle (click on the image)

16. 2026-01-27

17. 2026-01-28

Review of system specs (Pflichtenheft) was done along one concrete example: DnD Character Builder

We discussed how to improve the Initial Situation (Ausgangssituation) by describing more details of the game. In general this section must contain enough information to make the reader understand the domain.

We found that the Actual State (Istzustand) must be improved by listing the already existing solutions available in the market. Further the feature set of the existing solutions should be briefly described. In general this section must contain enough information to make the reader understand how the problem can currently be tackled with existing solutions.

We found that the Problem (Problemstellung) must be improved by briefly adding shortcomings of the existing solution described in Actual State. This is also the general approach. In this section your way of thinking is Let me feel the pain.

We found that the functional requirements must not be one simple use case diagram. Although the diagram is important it is necessary to add a brief description of each requirement what it means in detail and why it is necessary. Think of the form of user stories: "As a <role> I want to <feature> in order to <reason>. The parts in the angular brackets have to be part of your description here.

General things discussed

  • Avoid general Bla-sentences, they only annoy the reader and make them skip lines and reading sloppy

  • If you use GenAI to make your text better readable YOU are the master of content!!

    • Generate a system spec for a DnD character builder BAD PROMPT!! You will only get Bla text which is immediately recognizable as being generated. If we get aware of such bullshit you are in DEEP TROUBLE!!

    • Please explain the game DnD in 8 lines. Especially emphasize the terms Dungeon Master, Problems, Classes, Peoples, Characters. The explanation shall be understandable by absolute beginners. Good prompt under the assumption that you read the generated text and add more specific prompts to improve the text.