> Jonas Barci Barcikowski: 434853
> Mete Han Cinar: 434823
> Tom Keller: 434576
# Softwaretechnik Woche 1
## Aufgabe 1.1
### a) Wasserfallmodell
- Benutzer der Software schulen
- `Wartung` weil Software fertig und Integration durchgeführt
- Qualitätssicherung des Pflichtenheftes durchführen
- `Analyse`, da Anforderungen des Lastenhefts durch das Pflichtenheft Spezifiziert, bzw. bestätigt werden. Pflichtenheft Produkt der Analyse.
- Gesetzliche Rahmenbedingungen prüfen
- `Analyse`, da Abwegung der Durchführbarkeit in der Analyse stattfindet
- Konzept und Prototyp einer Benutzeroberfläche erstellen
- Konzept erstellen: `Analyse`, da im Wasserfallmodell jegliche Planung in der Analyse stattfinden muss
- Protoypen erstellen: `Entwurf`, da bei Implementierung nicht mehr Prototyp
- Entwicklerteam zusammenstellen
- Vor `Analyse` oder in `Analyse`, falls spezialisten angeheuert werden sollen
- Code eines Programmmoduls debuggen
- `Implentierung`, da Menschen beim Programmieren fehler machen
- `Test, Integration`, da neue Fehler bekannt werden
- Zwei Subsysteme verbinden und testen
- `Integration`, weil Subsystem schon programmiert, also Implentierung abgeschlossen, aber Produkt noch nicht vollständig, also nicht Wartung
- Termine und Kosten des Projektes planen
- `Analyse`, weil Termine und Kosten vor beginn des Programmierens festgestellt sein müssen
- Datenstrukturen festlegen
- `Entwurf`, da für die Implementierung die Entwurfsspezifikationen, wie Datenstrukturen festzulegen, bereits festzustehen haben
- Evtl auch `Implementierung`, da im Laufe dieser auffallen könnte, das geplante Datenstruktur nicht passt. Man kann diskutieren ob man dann nicht wieder in Entwurf zurückgeht.
- Vorhandene Altlasten des Kunden analysieren
- `Analyse`, da vorhandene Altlasten (z.B. alter, nicht geupdateter Server) den Entwicklungsprozess maßgeblich beeinflussen und geplant werden muss.
- Schnittstellen von Programmmodulen definieren
- `Entwurf`, da Schnittstellen vor beginn des Programmierens feststehen sollten, bzw. handelt es sich hier um einen konkreten Entwurf für die folgende Implementierung
- Leistung der Entwickler bewerten und belohnen
- `Wartung`, da erst das abgeschlossene Programm bewertet und die fertigen Programmierer belohnt werden können
- Software an neue Umgebung anpassen
- `Integration`, da Software fertig, also nach Implementierung.
- Oder `Wartung`, wenn Kunde z.B. Infrastruktur ändert
- Kunden eine Rechnung stellen
- `Analyse`, da Kunde vor eigentlicher Arbeit bezahlen sollte, abhängig von Kostenanalyse.
- Test-Eingabedaten für ein Programmmodul ermitteln
- `Test, Integration`: Da hier im Wasserfallmodell das erste mal Tests geschrieben werden
- Strukturmodell des gesamten Softwaresystems entwerfen
- `Entwurf`, da dies bis zur Implementierung feststehen muss und es sich hier um einen sehr konkreten Entwurf handelt
- Dokumentation des Projektablaufes bewerten und archivieren
- Am Anfang der `Wartung`, um den Entwicklungsprozess zu bewerten
- Am Ende der `Wartung`, um das Projekt als ganzes bewerten und archivieren zu können
- Nach bereits vorhandenen, wiederverwendbaren Software-Bibliotheken suchen
- `Entwurf`, da danach alles feststehen sollte
- Performance-Prognose des Softwaresystems erstellen
- `Analyse`, da oft Teil des Pflichtenhefts
- Programmcode kommentieren
- `Implementierung`, da man während des Programmierens bereits kommentieren sollte, um Missverständnisse zu vermeiden

### b) V-Modell
- Benutzer der Software schulen
- keins, da nach Abnahmetest, da fertiges Produkt notwendig. Nicht in V-Modell berücksichtigt
- Qualitätssicherung des Pflichtenheftes durchführen
- `Abnahmetest`, da Pflichtenheft in Analyse geschrieben und Testfälle dann in Abnahmetest verwendet werden.
- Gesetzliche Rahmenbedingungen prüfen
- `Analyse`, da Abwegung der Durchführbarkeit in der Analyse stattfindet
- Konzept und Prototyp einer Benutzeroberfläche erstellen
- `Analyse`, da dort Konzept erstellt wird
- `Grobentwurf`, da dort Prototypen erstellt werden
- Entwicklerteam zusammenstellen
- Vor `Analyse`, weil Entwicklerteam notwendig, um V-Modell durchzuführen oder in `Analyse`, falls spezialisten angeheuert werden sollen
- Code eines Programmmoduls debuggen
- `Feinentwurf`, `Implementierung`, `Modultest`, `Integrationstest`, `Systemtest`, `Abnahmetest`, da in all diesen Aktivitäten Programmiert wird (werden kann) und beim Programmieren nunmal Fehler auftreten
- Zwei Subsysteme verbinden und testen
- `Implentierung`, für verbinden der Subsysteme
- `Modultest` für Test ob Verbindung funktioniert
- `Integrationstest` für Test ob Verbindung dem Feinentwurf entspricht
- Termine und Kosten des Projektes planen
- Kosten müssen in `Analyse` feststehen
- Termine werden eigentlich während jeder Aktivität gemacht
- Datenstrukturen festlegen
- `Feinentwurf`, da dort technische Details geklärt werden
- Vorhandene Altlasten des Kunden analysieren
- `Analyse`, da vorhandene Altlasten (z.B. alter, nicht geupdateter Server) den Entwicklungsprozess maßgeblich beeinflussen und geplant werden muss.
- Schnittstellen von Programmmodulen definieren
- `Grobentwurf`, grobe Idee der Schnittstellen
- `Feinentwurf`, spezifizierung
- Leistung der Entwickler bewerten und belohnen
- Jede Testphase, da dort die Errungenschaften der Entwickler überprüft und getestet werden.
- Software an neue Umgebung anpassen
- keine, da V-Modell die Wartung nicht berücksichtigt.
- Kunden eine Rechnung stellen
- `Analyse`, da niemand umsonst arbeiten möchte.
- Test-Eingabedaten für ein Programmmodul ermitteln
- `Analyse`, `Grobentwurf`, `Feinentwurf`, `Implementierung`, da dies Besonderheit des V-Modells
- Strukturmodell des gesamten Softwaresystems entwerfen
- Erstmals im `Grobentwurf`, konkretisierung im `Feinentwurf`
- Dokumentation des Projektablaufes bewerten und archivieren
- nach `Abnahmetest`, da Produkt vollendet sein muss.
- Nach bereits vorhandenen, wiederverwendbaren Software-Bibliotheken suchen
- `Grobentwurf`, da dort offensichtlich benötigte Bibliotheken ermittelt werden
- `Feinentwurf`, falls noch mehr spezialisierte Bibliotheken benötigt werden.
- Performance-Prognose des Softwaresystems erstellen
- `Analyse`, weil in Lasten-/Pfilchtenheft und weil **Prognose**
- Programmcode kommentieren
- `Feinentwurf`, da Prototyp kommentiert wird (guter Programmierstiel)
- `Implementierung`, da fertiger Code kommentiert sein sollte + guter Programmierstiel

### c)
Bei Vorgehensmodellen handeln es sich um abstrakte vereinfachungen der Realität, dementsprechend sind die Grenzen für die gegebenen Tätigkeiten bezüglich der Grundaktivitäten fließend.
Des weiteren ist bei den Tätigkeiten jeweils Spielraum für interpretation, was von unterschiedlichen Unternehmen unterschiedlich gehandhabt werden kann.

## Aufgabe 1.2
- Rollen:
- `Scrum master`
- `Product Owner`
- `Entwicklungsteam`
- Aktivitäten
- `Sprint Plannig`
- `daily Scrum meeting`
- `Sprint Review`
- `Sprint Retrospective`
- Artefakte
- `Product Backlog`
- `Sprint Backlog`
- `auslieferbares Produktinkrement`

---

- `Entwicklungsteam`:
- `Daily Scrum meeting`
- `Sprint Review`
- `Sprint Retrospective`
- `Sprint Backlog`
- (erzeugung von) `auslieferbares Produktinkrement`

- `Product Owner`:
- `Sprint review`
- `Sprint Retrospective`
- `daily Scrum meeting`
- `Product Backlog`
- `auslieferbares Produktinkrementk`

- `Scrum master`:
- `Daily Scrum meeting`
- `Sprint Review`
- `Sprint Retrospective`

## Aufgabe 1.3
- `funktionale` Anforderungen
- über ein komfortables Interface zu bedienen
- Fahrer interargiert mit Ladestation
- Autos aufladen
- Ladestation kann zusätzlich mit Auto interagieren (optional!)
- Überprüfung ob Ladekabel ordnungsgemäß verbunden ist
- Man kann bezahlen
- `nicht-funktionale` Anforderungen
- Das Ladenetz soll eine Ausfallsquote von unter 1% haben
- Autos *schnell* aufladen
- Überprüfung ob Ladekabel ordnungsgemäß verbunden ist, geschieht durch die Übertragung von Autodaten
- Verschlüsselte Bezahlung per Kreditkarte oder Carmpere App