Title: Sepm

1. Single Responsibility Principle (SRP): A class should have only one reason to change. In other words, a class should have only one responsibility.
2. Open-Closed Principle (OCP): A class should be open for extension but closed for modification. This means that you should be able to add new functionality to a class without changing its existing code.
3. Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types. In other words, a subclass should be able to replace its parent class without affecting the correctness of the program.
4. Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. This means that you should split up large interfaces into smaller, more focused ones.
5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. This means that you should use interfaces to abstract away the implementation details of your code.

BPM steht für Business Process Management und bezieht sich auf die Praxis der Modellierung, Automatisierung, Überwachung und Optimierung von Geschäftsprozessen innerhalb einer Organisation.
SOA steht für Service Oriented Architecture und ist eine Architektur- und Integrationsmethode, die darauf abzielt, Geschäftsfunktionen in Form von Services anzubieten.
BPM und SOA sind eng miteinander verbunden, da BPM auf der Automatisierung und Überwachung von Geschäftsprozessen basiert, während SOA auf der Bereitstellung von Services basiert, um diese Geschäftsprozesse zu unterstützen. Zusammen können sie helfen, die Effizienz, Flexibilität und Agilität von Geschäftsprozessen zu erhöhen.

Anweisungsüberdeckungstest (C0) (zumindest ein Testfall pro Knoten eines
Kontrollflussdiagramms)
Einfacher Bedingungsüberdeckungstest (C2) (Atomare Entscheidungen müssen
einmal einen wahren und einmal einen falschen test haben)
Mehrfach-Bedingungsüberdeckungstest (C3) (zusätzlich zu den atomaren
Teilentscheidungen werden die Gesamtentscheidungen einmal mit wahr und einmal
mit falsch gestestet)
Pfad-Überdeckungstest (C4) (Alle unterschiedlichen Pfade des Testpbjekts zumindest
einmal durchlaufen

• Teamstruktur (Personell): Qualifikation des Teams muss bei agilen Methoden
höher sein als bei plangetriebenen
• Dynamik der Anforderungen (Dynamism):Je häufiger Anforderungen geändert
werden, desto einfacher muss dies möglich sein.
• Entwicklungskultur (Culture): Agile Methoden können je Entwicklungskultur
eingesetzt werden.
• Teamgröße (Size): Agile Methoden werden oft bei kleinen, oder mittelgroßen
Teams effizient eingesetzt.
• Kritikalität (Criticality): Höhere Prüfung der SW, wenn Menschenleben davon
abhängen.

Q: 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!
A: 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

Q: 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.
A: 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.

Q: 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.
A: 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