TU Wien:Software Engineering und Projektmanagement VO (Grechenig)/Prüfung 2020-06-24
SEPM-Prüfung vom 24.06.2020 + Lösungsvorschlag (bewertet mit sehr gut)
1. Theoriefragen[Bearbeiten | Quelltext bearbeiten]
1.1. Nennen und erklären Sie drei der sieben Grundsätze des Softwaretests nach ISTQB![Bearbeiten | Quelltext bearbeiten]
- Testen zeigt die Anwesenheit von Fehlern
- Möglichst hohe Testabdeckung (Code Coverage) ist empfehlenswert, aber vollständiges Testen ist i.d.R. nicht möglich
- Nur weil es keine fehlschlagenden Tests gibt, heißt das nicht, dass die Software frei von Fehlern ist.
1.2. Was versteht man unter dem in der LVA diskutiertem Vorgehen "Entwicklung auf Zuruf"? Ist dieses Vorgehen einem Softwareprojekt zuträglich? Begründen Sie Ihre Antwort![Bearbeiten | Quelltext bearbeiten]
Entwicklung auf Zuruf beschreibt einen Ablauf, wo Entwickler Anfragen für neue Features oder Change Requests ohne formalen Prozess einfach direkt umsetzen. Dieser Ablauf ist nicht empfehlenswert, weil es keinen Überblick mehr gibt. In einem mehrköpfigen Team können u.U. hunderte Änderungen pro Jahr durchgeführt werden und diese sind nicht nachvollziehbar.
1.3. Was versteht man unter Anforderungsnachverfolgbarkeit (Traceability)? Warum ist Traceability bei der Durchführung eines Softwareprojekts wichtig?[Bearbeiten | Quelltext bearbeiten]
Traceability beschreibt den Grad der Übereinstimmung von Anforderungen und Software:
- Nachvollziehbarkeit der Quelle: Wer hat die Anforderung eingemeldet? Wann? Wie?
- Nachvollziehbarkeit zu anderen Anforderungen: Interdependenzen
- Nachvollziehbarkeit zu Ergebnissen/Artefakten: Zugehörige Spezifikationsteile, Testfälle
Ist wichtig, um den Überblick zu behalten und die Verbindung von Anforderung zu Implementierung und Testing nachvollziehen zu können. Zum Beispiel relevant für eine Abnahme.
1.4. Was versteht man unter den Begriffen Kopplung und Kohäsion? Welcher Zusammenhang besteht?[Bearbeiten | Quelltext bearbeiten]
Kopplung: Zusammenhalt zwischen verschiedenen Softwaremodulen (z.B. Klassen). Soll möglichst niedrig sein, da jede Klasse ihre eigene Funktionalität kapseln soll (wenig Abhängigkeiten).
Kohäsion: Interner Zusammenhalt eines Moduls, z.B. einer Klasse. Soll möglichst hoch sein --> Funktionalität ist in einer Klasse beisammen.
Niedrige Kopplung wird erreicht durch hohe Kohäsion.
1.5. Nennen und erklären Sie die vier in der LVA genannten Paradigmen der serviceorientierten Architektur. Was versteht man unter "business driven" im Kontext von SOA?[Bearbeiten | Quelltext bearbeiten]
- Geringe Kopplung, für gute Kapselung der Funktionalitäten
- Composable: Services können aus anderen Services bestehen
- Abstraktion: ermöglicht Wiederverwendung der Services
- Standardisierung von Schnittstellen, um die Services miteinander zu verbinden
Business-driven heißt, die Services sollen an Hand der Geschäftsprozesse des Unternehmens strukturiert werden, also soll die Wirklichkeit in der SOA abgebildet werden.
1.6. Was versteht man unter Microservices? Welche Vorteile und Herausforderungen bringen Microservices mit sich?[Bearbeiten | Quelltext bearbeiten]
Microservices sind kleine, einzeln entwickelte, betreib- und deploybare Services.
Vorteile:
- Team hat Eigenverantwortung über ihr Service
- Schnellere Time to Market, da eine kleinteiligere Struktur besteht
- Unterschiedliche Technologien pro Service möglich
Herausforderungen:
- Komplexe Tätigkeiten (Build, Continuous Integration, Deployment, Testen) müssen in jedem Team erneut gemacht werden
- Teamstruktur muss es erlauben, d.h. man braucht ein cross-funktionales Team
- Service Discovery zur Laufzeit ist kompliziert
- Dezentrale Datenhaltung und deren Synchronisierung
- Kommunikation zwischen Microservices (Transaktionen, Synchronisierung, Event Streams etc.)
1.7. Was versteht man unter Komponententest? Skizzieren und beschreiben Sie das in der LVA vorgestellte Test-Setup für den Komponententest![Bearbeiten | Quelltext bearbeiten]
Komponententests sind automatisierte Tests einer KOmponente (z.B: einer Klasse / eines Moduls). Dabei sollten externe Komponenten simuliert werden (Stubs), um die jeweilige Komponente isoliert testen zu können.
+ Skizze
1.8. Wozu dienen Design Patterns? Nennen Sie drei Design Patterns der Kategorie "Creational Patterns", erklären Sie eines davon anhand eines Beispiels.[Bearbeiten | Quelltext bearbeiten]
Design Patterns dienen dazu, häufig auftretende Herausforderungen durch bestimmte Strukturen abstrakt zu lösen.
Creational Patterns: Factory, Builder, Singleton.
Singleton: Es kann von einer Singleton-Klasse immer nur maximal 1 Instanz existieren. Das Singleton-Pattern ermöglicht es, auf diese Instanz zuzugreifen. Falls noch keine Instanz existiert, wird im Hintergrund eine erstellt und dann zurückgegeben.
1.9. Erklären Sie das Vorgehen bei Test Driven Development! Erläutern Sie weiters die "zwei goldenen Regeln" von Kent Beck![Bearbeiten | Quelltext bearbeiten]
Test-driven development bedeutet, dass zuerst Tests geschrieben werden, bevor neuer Business-Code geschrieben wird. Bevor der neue Business-Code enthalten ist, muss der Test daher fehlschlagen. Sobald der neue Code implementiert wurde, muss der Test erfolgreich durchlaufen.
2 goldene Regeln:
- Nur neuen Business-Code schreiben/ändern, wenn ein Test fehlschlägt.
- Keine Duplikate erzeugen
1.10. Was versteht man unter Inversion of Control? Erläutern Sie ein Beispiel dafür![Bearbeiten | Quelltext bearbeiten]
Inversion of Control heißt, dass nicht der Developer Code einer Library aufruft, sondern das Framework selbständig den Developer-Code aufruft.
Beispiel: In Spring Boot werden Endpoint-Methoden aufgerufen, wenn ein neuer REST Request zum jeweiligen Endpoint eintrifft.
1.11. Was versteht man unter den Begriffen Verifikation und Validierung im Kontext des Softwaretestens?[Bearbeiten | Quelltext bearbeiten]
Verifikation beschreibt das Testen, ob die Software der Spezifikation entspricht.
Validierung ist das Testen/Überprüfen, ob die Software den tatsächlichen Anforderungen (des Kunden bzw. Auftraggebers bzw. Nutzers) entspricht.
Kreativfragen[Bearbeiten | Quelltext bearbeiten]
Angabe siehe PDF: https://vowi.fsinf.at/images/6/66/TU_Wien-Software_Engineering_und_Projektmanagement_VO_%28Grechenig%29_-_Pr%C3%BCfung_2020-06-24.pdf
2.1. In Ihrer Rolle als ProjektleiterIn haben Sie die Aufgabe das Projekt in 6 Monaten abzuschließen. Skizzieren Sie das aus Ihrer Sicht optimale Projektteam! (Größe, Expertisen, ...) Welchen Softwareentwicklungsprozess würden Sie für das genannte Vorhaben wählen? Beschreiben Sie diesen ausführlich und begründen Sie Ihre Wahl![Bearbeiten | Quelltext bearbeiten]
Optimales Projektteam:
- 1 Product Owner
- 1 Scrum Master
- 3 Developer
- 1 UI/UX-Designer
- 1 Tester
Ich würde ein agiles Projektmanagement mit Scrum wählen. Das Team sollte daher cross-funktional und nicht zu groß sein. Außerdem sollten die Teammitglieder nicht nur fachliche Erfahrung, sondern auch Erfahrung mit agilem Arbeiten in Projektteams haben und eine hohe Eigenverantwortung übernehmen können/wollen.
Gründe / Kriterien für die Wahl von Scrum:
- Kritikalität: Es werden personenbezogene und Zahlungsdaten verarbeitet und das Programm sollte möglichst hoch verfügbar sein, es hängen aber keine Menschenleben von der Software ab und es kommt bei Fehlern auch nicht zu Sachschäden o.ä., aber evtl. zu Einnahmeausfällen.
- Anforderungen: Die Anforderungen scheinen nicht extrem volatil zu sein, allerdings gibt es noch keine klaren funktionalen und nichtfunktionalen Anforderungen. Auch ein User-Workflow und ein Design müssen erst erarbeitet werden.
- Teamgröße: Das Projekt ist m.M.n. mit dem o.g. Team in 6 Monaten abzuschließen.
- Teamstruktur: cross-funktional, s.o.
- Mindset: hohe Eigenverantwortung des Teams, s.o.
Mit agilem Projektmanagement werden die Projektphasen (Analyse, Design, Implementierung, Testen) mehrfach hintereinander durchlaufen, dadurch sind früher lauffähige Releases der Software möglich.Nach jedem Sprint sollte eine neue Version veröffentlicht und deployed werden. So erhält man acuh früher Feedback des Kunden
+ Skizze Scrum
Durch das cross-funktionale Team können verschiedene Funktionsbereiche in jedem Sprint abgedeckt werden:
- Requirements Engineering bzw Analyse
- Design, Entwurf
- Implementierung
- Testen
- Deployment
2.2. Erstellen Sie für das skizzierte Vorhaben ein Konzept zur Qualitätssicherung! Begründen Sie warum Sie welche Softwarequalitätssicherungsmethode in Ihrem Projekt anwenden.[Bearbeiten | Quelltext bearbeiten]
Statische Qualitätssicherung:
- Peer Reviews: Verifikation der Artefakte, Erkennen von Fehlern
- Sprint Reviews: Validierung der umgesetzten Features
Dynamische Qualitätssicherung:
- Automatisierte Tests (TDD), um (zukünftige) Fehler zu erkennen
- Manuelle Tests, um die Usability und Funktionalität zu prüfen
Organisatorische Qualitätssicherung:
- Wissensmanagement, um das Team weiterzuentwickeln
- Templates für Protokolle und Dokumente --> Traceability
- Checklisten und Testpläne für das manuelle Testen
2.3. Beschreiben Sie einen alternativen Softwareentwicklungsprozess ausführlich. Wenn Sie sich in 2.1 für einen agilen Prozess entschieden haben, beschreiben Sie einen Traditionellen. Sollten Sie sich in 2.1 für einen traditionellen Prozess entschieden haben, so wählen Sie nun einen Agilen.[Bearbeiten | Quelltext bearbeiten]
Im Gegensatz zu agiler Entwicklung werden die Projektphasen nacheinander und nur einmalig durchlaufen
Skizze Wasserfallmodell mit
- Analyse
- Entwurf
- Implementierung
- Testen
- Deployment
Dabei ist es besonders wichtig, nach jeder Phase eine Überprüfung der Ergebnisse zu machen, da sich zu spät erkannte Fehler fortpflanzen und zu enormen Kosten für die Behebung führen.