
**Klausurtermine Mi: 07.02.2024, 28.03.2024, 9 Uhr, Raum 032a-c**
"Ich möchte nicht sehen was Sie nicht können, Ich möchte sehen was Sie können."
Vorlesung des 15. 16. fällt aus.
# Inhaltsverzeichnis
- [[#Klausur|Klausur]]
- [[#Labor|Labor]]
- [[#Inhalt|Inhalt]]
- [[#Software|Software]]
- [[#Softwaresystem|Softwaresystem]]
- [[#Keine Ahnung wohin damit|Keine Ahnung wohin damit]]
- [[#Entwicklungsprozess|Entwicklungsprozess]]
	- [[#Entwicklungsprozess#Begriffe und Grundlegendes|Begriffe und Grundlegendes]]
		- [[#Begriffe und Grundlegendes#Projektphasen|Projektphasen]]
	- [[#Entwicklungsprozess#Aktivitäten / Phasen|Aktivitäten / Phasen]]
		- [[#Aktivitäten / Phasen#Überblick|Überblick]]
		- [[#Aktivitäten / Phasen#Entwurf|Entwurf]]
			- [[#Entwurf#Grobentwurf|Grobentwurf]]
			- [[#Entwurf#Feinentwurf|Feinentwurf]]
		- [[#Aktivitäten / Phasen#Implementierung|Implementierung]]
		- [[#Aktivitäten / Phasen#Phasenübergreifende Aspekte|Phasenübergreifende Aspekte]]
			- [[#Phasenübergreifende Aspekte#Projektmanagement|Projektmanagement]]
			- [[#Phasenübergreifende Aspekte#Projekt und Konfigurationsmanagement|Projekt und Konfigurationsmanagement]]
- [[#Vorgehensmodell|Vorgehensmodell]]
- [[#Wasserfallmodell / Phasen und Ergebnisse|Wasserfallmodell / Phasen und Ergebnisse]]
- [[#Wasserfall-Verbesserung|Wasserfall-Verbesserung]]
	- [[#Wasserfall-Verbesserung#Iterativ / Inkrementell / Evolutionär|Iterativ / Inkrementell / Evolutionär]]
				- [[#Projekt und Konfigurationsmanagement#Probleme:|Probleme:]]
	- [[#Wasserfall-Verbesserung#Spiral-Modell|Spiral-Modell]]
	- [[#Wasserfall-Verbesserung#Prototyping zur Unterstützung der Iteration|Prototyping zur Unterstützung der Iteration]]
			- [[#Phasenübergreifende Aspekte#Experimentelle Prototypen|Experimentelle Prototypen]]
			- [[#Phasenübergreifende Aspekte#Horizontal- vs. Vertikale Prototypen|Horizontal- vs. Vertikale Prototypen]]
	- [[#Wasserfall-Verbesserung#Rational Unified Process (RUP)|Rational Unified Process (RUP)]]
- [[#Agile Vorgehensmodelle|Agile Vorgehensmodelle]]
- [[#Das V-Modell|Das V-Modell]]

# Vorlesungseinführung
[Discord Channel](discord.gg/AGQsZGwY2) , Aulis bleibt klassische Platform
Labor ist verpflichetend und wird bewertet (Raum 236 als Diskussionsraum)
Folien, die in den Vorlesungen nicht behandelt wurden müssen privat bearbeitet werden.

## Klausur
- Klausur ist bei mind. 50% bestanden, allerdings wird Zeitdruck in der Klausur simuliert ("Klausur ist sportlich"')
- 1 bei 90% "Ich gehe aber sowieso davon aus, dass Sie die 10% nicht bekommen.".(Big OOOF)
- DIN A4 doppelseitig beschrieben (Handschriftlich) als Formelsammlung kann mitgenommen werden.
- Strategie + Konzentration sind Schlüssel
- 20% Theorie, Kompetenzstufe 6
## Labor
- **Laborraum: I233** 
- **Laboraufgaben am Labortag bis 23:55**
- Laboraufgaben sind skalierbar (wenn jemand austeigen sollte, werden die Aufgaben geringer)
- vergabe von Teamnoten und Kennzeichnung von Eigenleistung, bei bedarf kann die Benotung als Einzelperson erfolgen

## Inhalt
- Paradigmenvergleiche bei Programmiersprachen für unterschiedliche Kontexte.
- UML macht einen Comeback und muss gründlich durchegenommen werden anhand der UML Folien und von Beispielsweise bearbeitung von [UML Glasklar]() 
- Literatur von vor 5 Jahren schon teilweise obsolet und daher nur als Grundlagen verwenden
- IEEE, ACM, GI, INCOSE, GfSE

# Vorlesung 01 (Einführung)
## Software
- Software altert teilweise schneller als Hardware
- "Wir machen etwas, was an den Rest passen muss"
- Wohin gehen die Wissensschnittstellen, welche Grenzen haben diese?
## Softwaresystem
- Software+ Hardware
- Software defakto überall
- Immer Architektur, durch bewusstes Design oder ausversehen entstanden
- Sinnvolle Architektur ist wichtig

## Keine Ahnung wohin damit
- UML ist nicht Mittel zum Zweck, sondern ein Tool um strukturellen Kontext
___
# Vorlesung 02 (Entwicklungsprozess)
- Wenn die Techniken der Softwareentwicklung nicht beherscht sind, dann ist jegliche Bewertung von Zeitaufwand, Personal etc nicht möglich.
- Abschluss der 1. Vorlesungsfolien
## Entwicklungsprozess
### Begriffe und Grundlegendes
- Prozess: Vorgehensweise zur Erstellung des Produkts
- Produkt: Resultat des Prozesses
- Projekt: Das gesamte Vorhaben als (Phasen-) Abfolge zum Erstellen des Produkts
#### Projektphasen
- Studien- und Planungsabschnitt (Vorstudie, Konzeption, Definition & Planung)
- Realisierungsabschnitt (Entwicklung, HW Fertigung)
- Betriebsabschnitt (Betrieb & Wartung, Entsorgung)
### Aktivitäten / Phasen
#### Überblick

#### Entwurf
- erstellen eines Systems, welches die Anforderungsanalyse entspricht
- Entwurf Abhängig von dem was gebraucht wird und welche Qualitätsmerkmale gefragt werden
##### Grobentwurf
- Lines & Boxes
- Kapselung notw. DIesnte
- Testen auf Anforderungen
##### Feinentwurf
- Wie wird konkret realisiert?
- Unit-test ist teil der Implementierung
#### Implementierung
- Entwurf dient als Grundlage
- Programming in the small vs. Programming in the large (Ground up und Top down)
- Integrations und Systemtest

#### Phasenübergreifende Aspekte
##### Projektmanagement
##### Projekt und Konfigurationsmanagement
- urspr. Lösen der steigenden Produktkomplexität


___
# Vorlesung 03 (Vorgehensmodelle)
## Vorgehensmodell
- Ziel: Geplant zu qual.hochw. Produkt
- Arbeits- aufteilung und vorgang
- 4Ws machen ihren come-back bei der Aufbereitung
## Wasserfallmodell / Phasen und Ergebnisse
- früher: stagewise model
	- weiterentwicklung u.a. durch Royce
- Für das Verständnis des zusammenhangs und der Funktion von bspw. SCRUM ist das Verstehen von dem Modell wichtig
- Pflichtenheft vorhanden
- Wenn sauber bearbeitet wurde entstehen zwei Dokumente (Pflichtenheft und Anf.Spez.)
- sukzessive Entwicklung von Software, praktisch aber nicht wirklich umsetzbar
	- Kunde kann Lastenheft innerhalb der Bearbeitungszeit überarbeiten etc.
- "Wartungsdefinition nicht so gut definiert"
- vollst. Durchführung der Phasen nicht immer sinnvoll
## Wasserfall-Verbesserung
- verbesserung durch interativ, inkrementelle Wiederholungen
### Iterativ / Inkrementell / Evolutionär
- Iterativ: Wiederholen
- Inkrement: Vergrößern
- Evolutionär: 
- Kosten können nach jeder Iteration überprüft werden
- Agile hat nicht iterativ, inkrementelles Vorgehen **nicht** erfunden
###### Probleme:
- Prozess nicht wirklcih sichtbar
- schlechte Strukturierung kann enstehen
- Vertraglich gebunden
- "Safe ist grausam (zu komplex und nicht unbedingt agil)"
- Für reine Softwaresysteme
### Spiral-Modell
1. Analyse
2. Evaluierung
3. Realisierung
4. Planung
- Entwickeln mehrerer Prototypen $\rightarrow$ treibung durch Prototypentwicklung
### Prototyping zur Unterstützung der Iteration
- keine ad-hoc Vorgehensweise
##### Experimentelle Prototypen
- Nachweis der Machbarkeit
##### Horizontal- vs. Vertikale Prototypen
Horizontal: real. nur einer spez. Ebene
Vertikal:
### Rational Unified Process (RUP)
- Initial 1998 von Kruchten vorgestellt
- basiert auf UML
- "Zu kompliziert für reale Welt"
- RUP wird nicht abgefragt, trotzdem interessant
## Agile Vorgehensmodelle
- inkr. Ansatz aus vielen kleinen Iterationen
- **neu**: Am Ende jeder Iteration folgt ein Reviews und ggf. Re-Evaluation von Projektprioritäten
- "Agile kann man sich nicht nennen, Agile muss man sein" (cringe)
### Agiles entwickeln mit Scrum
![[Pasted image 20231102101622.png]]
### Das V-Modell
- defakto aus Militär
- Absolut viele unterschiedlichen Modelle (wie auf wiki. zu lesen)
- entgegensetzen von Implementation und Testens
![[Pasted image 20231102105704.png]]

- Benutzen eines Hybridmodelles hier sinnvoll, weil Anforderungsänderungen hier teilweise sehr teuer werden können.

# Vorlesung 04 (Anforderungsanalyse)

## Definition
Definiert nach IEE als die dok. Darstellung einer Beschaffenheit oder Fähigkeit, die von einem Benutzer oder Lösung eines Problems oder Erreichung eines Ziels benötigt wird oder die ein System oder Systemteil erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.

## Anforderungsanalyse - Grundlagen
- Pflichtenheft ist ein Vertragsdokument

## Lasten-/Pflichtenheft
- Lastenheft besch. Anf. aus Kundensicht
- Pflichtenheft besch. Anf. aus Lieferantensicht
	- Vertragsgrundlage
	- von allen am Projekt Beteiligten akzeptiert

## Arten von Anforderungen
![[Pasted image 20231102115045.png]]
## Eigenschaft einer Anforderung
### Inhalt
![[Pasted image 20231102115639.png]]
### Behandlung
![[Pasted image 20231102115326.png]]

## Schritte
### 3. Schritt
- Benutzer des Systems 
- Rollen der Benutzer
### Akteure in UML
- Rolle, welche ein Benutzer im System spielt
- Beeinflusst Sys.
## 4. Schritt
- Fortschrittsequenz der Geschäftsprozesse
### 5. Schritt
- Anwendungsfälle deklarieren (Use-Cases)
- Anwendung von UML2 als gängige Notation
### 6. Schritt
- Anwendungsfälle zerlegen Geschäftsprozesse in Portionen, welche aus Sicht des Anwenders sinnvoll ist.
- Reihenfolge kann sich später ändern, daher ist eine Festlegung der Reihenfolge am Anfang unwichtig
### 7. Schritt
- Ausarbeitung der Anwendungsfälle (ins Detail gehend)
- Die Analyse kann als UML-, Text-, Diagrammentwurf  beispielsweise erstellt werden (Schablonen ebenfalls)
Präsentiert wird dann Folie 44,45 und 46, welche eine Beispielschablone für die Bearbeitung des 7. Schrittes ist.klk
___
# Vorlesung 05 (Entwurf)
- festl. Architektur des Sys.
## Allgemeines
## Entwurfskriterien
- Kopplung:
	- Maß für ene interne Beschaffenheit eines Entwurfs 
	- Koplung über eine Schnittstelle
	- Ziel: lose/geringe Kopplung
		- Fehlerbehebung ohne größeren Aufwand
- Kohäsion:
	- Maß für die (funktionale) Bindung der Elemente innerhalb eines Bausteins
	- Kohäsion bewertet den inneren Zusammenhalt
	- Ziel: starke/hohe Kohäsion
		- benötigte Infos und Ops zur Lösung in einem Baustei vorhanden
- Zulänglichkeit:
	- Maß für Erfüllung der Anforderungen
	- Ziel: überschaubare, einsichtige Zulänglichkeit
- Vollständigkeit
	- Maß für vollständige Umsetzung der Anforderungen
	- Ziel: Vollständigkeit in Bezug zur Aufgabe
- EInfachheit
	- Maß für die Umsetzung von hinreichender Funktionalität mit angemessener Schnittstelle des Bausteins
	- Ziel: KIS - keep it simple
## Entwurfsprinzipien
- Grundsatz, dem man seinem Handeln zugrunde legt
- Noch unabhängig von konkreten Methoden und Techniken
- Modelltypen
	- deskriptiv
	- präskriptiv
## Sichtweisen/Vorgehensweisen zum Entwurf
- Orientierung ist egal
## Heuristiken
- Aus Projektumfeld
	- Anforderungen Hinterfragen
	- Betrachtung Use-Cases
	- Nach Feedback suchen
- Für den Entwurf
	- KIS
	- auf "richtige" Detailebene bleiben
	- nicht übergeneralisieren
	- so lokal wie möglich entwickeln
Off Topic stuff:
- Basiswissen-Softwaretest-Modul laut Matevska ein gutes Modul
- Informatik ist Denglisch at its peak

___
# Vorlesung 8
- Paper-Reviews können blind betrachtet werden um vorurteile etc beiseite zu schieben
- Review-sitzung soll zieloreintiert durchgezogen werden
- Nachbearbeitung kann zu wiederholung des Reviews führen
- Je komplexer die thematik, umso besser muss man in der Materie sein

- systematisches Vorgehen und kein ad hoc (spezifizierter Test und nicht über den Tellerrand schauend)
- Eigang von Unit lvl. aber auch komplex lvl.

Testfälle:
- Bei Tests Versionen etc. mit angeben (der Stubs beispielsweise)
- Reproduzierbarkeit des Tests ist eine grundlage für das gute Testen
- Womit wurde getestet?
	- Beispiel Compilereinstellungen sind wichtig anzugeben weil unterschiedliche Ergebnisse rauskommen können
- Auf Testfälle kommt man anhand der Anforderungsdefinitionen, Systemspez. und allg. Richtlinien
Äquivalenzklassenbildung
- Auswahl an Eingabeparameter, bei denen eine keine unterschiedlichen Ausgaben herauskommen

___
# Vorlesung 9
Whitebox Test Folie 48-50 Prüfungsrelevant

# Vorlesung 10 Implementierung
- Dokumentation um zu Wissen was innerhalb geschieht

Compiler, Interpreter, Precompiler und Linker
Imperativ => Herrschen, Beherschen

OOP: Vererbung segen und Fluch 
