af Taha Emircan Gökduman 24 timer siden
27
Mere som dette
✅ Menschliche Faktoren:
✅ Organisatorische Faktoren:
✅ Fachliche Faktoren:
✅ Ziel: Bewertung eines Produkts oder Prototyps durch reale Nutzer.
✅ Ablauf:
1️⃣ Planung: Zielgruppen & Testaufgaben definieren, Testpersonen rekrutieren.
2️⃣ Durchführung: Nutzer bearbeiten Aufgaben, oft mit Thinking-Aloud-Technik.
3️⃣ Auswertung: Daten analysieren, Probleme kategorisieren & bewerten.
4️⃣ Ergebnispräsentation: Erkenntnisse & Empfehlungen vorstellen.
✅ Definition:
✅ Zweck:
⚠ Limitierung: Peripheres Blickfeld wird nicht erfasst.
✅ Expertenbewertung der Usability anhand von Heuristiken (Theorien & Erfahrung).
✅ Ergebnisse: Probleme & Verbesserungsvorschläge, nach Schweregrad kategorisiert.
✅ Vorteil: Klare Identifikation & konkrete Lösungen.
✅ Nachteil: Zeitaufwendig & erfordert erfahrene Experten.
✅ Grundprinzipien für Usability:
1️⃣ Sichtbarkeit des Systemzustands – Klare Rückmeldung für Nutzer.
2️⃣ Übereinstimmung mit der Realwelt – Vertraute Begriffe & Konzepte nutzen.
3️⃣ Nutzerkontrolle & Freiheit – Aktionen rückgängig machen können.
4️⃣ Konsistenz & Standards – Einheitliches Design & Verhalten.
5️⃣ Fehlerprävention – Probleme vorab vermeiden.
6️⃣ Wiedererkennen statt Erinnern – Wichtige Infos sichtbar halten.
7️⃣ Flexibilität & Effizienz – Anpassbarkeit für verschiedene Nutzer.
8️⃣ Ästhetik & Minimalismus – Klare, nicht überladene Interfaces.
9️⃣ Fehlermanagement – Erkennen, Bewerten & Beheben erleichtern.
🔟 Hilfe & Dokumentation – Unterstützende Infos bereitstellen.
✅ Ziel:
✅ Ablauf:
1️⃣ Input definieren: Personas, Aufgaben & idealer Ablauf.
2️⃣ Interaktionssequenz analysieren: Schritt-für-Schritt-Prüfung.
3️⃣ Kritische Informationen gewichten: Probleme & unklare Begriffe identifizieren. 🚀
✅ Übersicht:
✅ SUS-Score Berechnung:
✅ Definition:
Interaktionsdesign beschreibt, wie ein Produkt oder System auf Nutzereingaben reagiert. Es folgt psychologischen Theorien wie mentalen Modellen und strukturiert die Anordnung von Funktionen innerhalb der Benutzeroberfläche.
✅ Komponenten des Interaktionsdesigns:
1️⃣ Interaktionsfluss:
📌 Interaktionsfluss:
📌 Inhalt:
📌 Darstellung:
✅ Fazit: Durch Interaktionsfluss, Inhalte & Darstellung wird eine intuitive und effektive Nutzerführung sichergestellt.
✅ ISO 9241-110: Grundsätze der Interaktionsgestaltung
✅ ISO 9241-112: Grundsätze der Informationsdarstellung
✅ Definition:
✅ Zweck:
✅ Definition:
✅ Beschreibungselemente:
✅ Zweck:
✅ Vorteile:
Konzepte
✅ Storyboarding:
✅ Defining Components:
✅ Process Visualization:
✅ Workflow Maps:
✅ Screen Transition:
✅ Screen Transition Storyboard:
✅ Wireframes:
✅ Funktionale Prototypen:
✅ Horizontale vs. Vertikale Prototypen:
✅ Tools für Prototypen:
Axure, Adobe XD, Figma, InVision – Erstellung klickbarer HTML-Prototypen.
1️⃣ Ziel festlegen: Nutzer definiert, was er erreichen will.
2️⃣ Intentionen formulieren: Planung von Handlungsabsichten.
3️⃣ Aktionen planen: Spezifizierung der notwendigen Schritte.
4️⃣ Aktionen ausführen: Umsetzung über die Benutzeroberfläche.
5️⃣ Systemzustand wahrnehmen: Nutzer nimmt Rückmeldung des Systems wahr.
6️⃣ Systemzustand interpretieren: Bewertung der Systemreaktion.
7️⃣ Vergleich mit Ziel: Erfolg prüfen → Ziel erreicht oder neuer Zyklus.
✅ Goal:
✅ Execution:
✅ Evaluation:
Nutzer muss Systemzustand einfach mit seinem Ziel vergleichen können (klare Anzeigen).
✅ Idee:
✅ Varianten:
1️⃣ Offenes Card Sorting: Nutzer erstellen eigene Kategorien & benennen sie.
2️⃣ Geschlossenes Card Sorting: Kategorien sind vorgegeben, Nutzer ordnen Inhalte ein.
3️⃣ Reverse Card Sorting: Nutzer bewerten eine bestehende Struktur & geben an, wo sie Inhalte erwarten.
✅ Definition:
Ein mentales Modell beschreibt, wie eine Person denkt, dass etwas funktioniert.
✅ Merkmale:
✅ Eigenschaften:
✅ Relevanz für Interaktionsdesign:
🔹 Designer vs. Nutzer:
1️⃣ Produkt an mentale Modelle der Nutzer anpassen.
2️⃣ Nutzer durch Training & bessere Erklärungen unterstützen.
3️⃣ Eindeutige Bezeichnungen & transparente UI gestalten.
✅ Voraussetzung:
✅ Methoden zur Anpassung:
Beschreibt, wie effektiv, effizient und zufriedenstellend ein Produkt von bestimmten Nutzern in einem bestimmten Kontext verwendet werden kann.
Umfasst alle Emotionen, Wahrnehmungen und Reaktionen eines Nutzers vor, während und nach der Nutzung eines Produkts.
Das TORE (Task-Oriented Requirements Engineering) Entscheidungs-Rahmenwerk strukturiert anforderungsrelevante Entscheidungen auf vier Ebenen:
✅ Systementwicklung wird durch Aufgaben & Geschäftsprozesse gesteuert.
✅ Jede Systementscheidung ist begründbar und nachvollziehbar.
✅ Zielerreichung wird strukturiert sichergestellt.
✅ Erleichtert Kommunikation zwischen Fachlichkeit & Entwicklung.
Es verbindet Requirements Engineering, Usability Engineering und Business Informatics, um eine fundierte Entscheidungsfindung zu gewährleisten. ✅
✅ Kernfragen:
1️⃣ Wie interagieren Nutzer/externe Systeme mit der Software?
2️⃣ Welche Systemfunktionen sind erforderlich?
3️⃣ Welche Daten werden ausgetauscht?
4️⃣ Wie werden Daten & Funktionen in der UI gruppiert?
✅ Systemfunktionen umfassen:
🔹 Falls nötig, können sie mit UML oder Rupp’s Satzschablone detailliert werden.
✅ Ableitung aus Use Cases:
📌 Dokumentation: Als Erweiterung der Use Cases oder Datenmodelle.
✅ Leitfrage: Welche Daten & Funktionen gehören zusammen?
✅ Ableitung aus Use Cases.
✅ Visualisierung: Logische Bereiche oder Papierprototypen.
🔹 Ist-Situation: Aktuelle Prozesse analysieren (Stärken & Schwächen).
🔹 Soll-Situation: Zukünftige Gestaltung zur Zielerreichung.
🔹 Systemverantwortlichkeiten: Zuständigkeiten klären.
🔹 Geschäftsdaten & -regeln: Wichtige Daten & Regeln berücksichtigen.
✅ Kernfragen:
🔹 Fokus auf Aufgaben statt Features – Analyse der IST-Situation aus Nutzersicht.
🔹 Ziel: Probleme & Verbesserungspotenziale erkennen, Anforderungen ableiten, Nutzertests vorbereiten.
✅ Kernfragen zur Aufgabenanalyse:
Ein Sequence Model beschreibt detailliert, wie ein Nutzer eine Aufgabe in einem bestimmten Kontext Schritt für Schritt ausführt. Es erfasst Aktionen, Denkprozesse, Probleme und Unterbrechungen.
1️⃣ Trigger: Nutzer möchte einen Flug buchen.
2️⃣ Suche: Nutzer gibt Abflughafen, Ziel, Datum ein.
3️⃣ Auswahl: Filtert nach Preis, Airline, Flugzeiten.
4️⃣ Buchung: Gibt Passagierdaten ein, wählt Zahlungsmethode.
5️⃣ Bestätigung: Erhält E-Ticket per E-Mail.
6️⃣ Mögliche Probleme: Kreditkarte wird abgelehnt, unklare Gebühren.
7️⃣ Lösung: Nutzer versucht alternative Zahlungsmethoden oder kontaktiert den Support.
✅ Nutzen: Sequence Models helfen, Benutzerinteraktionen zu verstehen, Probleme zu identifizieren und UX zu verbessern.
Grafische Methode zur Modellierung von Geschäftsprozessen.
🔹 Elemente:
✅ Aufgaben verstehen:
✅ Kontext verstehen:
✅ Ressourcen & Hilfsmittel:
✅ Optimierung der Ist-Situation unter Beibehaltung von Stärken:
✅ Detaillierung der Soll-Situation mit Modellierungstechniken:
Systemverantwortlichkeiten
✅ Aktivitätsklassifikation in der Soll-Situation:
Beschreibung von Systemunterstützten Aktivitäten mit User Stories
ALS <<ROLLE>> MÖCHTE ICH <<TÄTIGKEIT>> UM <<ZIEL>>
Beschreibung von Systemautomatisierten Aktivitäten mit Standard-Satzschablone
<NAME> MUSS <wem> die Möglichkeit geben <Objekt> <Prozesswort>
SOLL fähig sein
KANN
Beschreibung von Systemautomatisierten Aktivitäten mit erweiterter Satzschablone
<WENN> MUSS <NAME> <wem> die Möglichkeit geben <Objekt> <Prozesswort>
SOLL fähig sein
KANN
✅ Schritte:
1️⃣ Begriffe aus Geschäftsprozessen ableiten.
2️⃣ Daten mit Stakeholdern verfeinern (Attribute klären).
3️⃣ Konzeptionelle Zusammenhänge & Kardinalitäten modellieren.
✅ Regeln aus Daten, Prozessen & Funktionen ableiten:
Kreativität
Kreativität
"Kreativität ist die Fähigkeit, Arbeit zu schaffen, die sowohl neuartig (d. h. originell, unerwartet) als auch angemessen (d. h. nützlich und anpassungsfähig in Bezug auf Aufgabenbeschränkungen) ist."
"Kognitive Prozesse, die zu einer originellen (z. B. neuartigen, einzigartigen oder ungewöhnlichen) und adaptiven (z. B. passenden, nützlichen) Erkenntnis, Idee oder Lösung führen."
Basic Elemente von Kreativität
Kopieren Transformieren Kombinieren
✅ Phasen:
1️⃣ Exploration: Ideenfindung ohne Bewertung (Kreativitätstechniken anwenden).
2️⃣ Combination & Transformation: Ideen strukturieren, analysieren & kombinieren.
3️⃣ Convergence: Vielversprechende Ideen auswählen & konsolidieren.
4️⃣ Evaluation: Ideen auf Eignung prüfen & für Produktentwicklung nutzen.
👉 Vorteil: Trennung von Ideenfindung & Bewertung fördert Kreativität & Innovation.
✅ Ideengenerierung:
✅ Ideenbewertung & Auswahl:
✅ Assoziative Techniken:
🔹 Eine kreative Methode zur schnellen Ideenfindung in Gruppen.
🔹 Struktur: 6 Teilnehmer schreiben je 3 Ideen in 5 Runden → max. 80 Ideen.
✅ Ablauf:
1️⃣ Jeder Teilnehmer erhält ein Arbeitsblatt mit einer Fragestellung.
2️⃣ Moderator setzt Zeitlimit (z. B. 3–5 Minuten pro Runde).
3️⃣ Jeder schreibt 3 Ideen in die erste Zeile.
4️⃣ Blätter werden weitergereicht, der nächste ergänzt oder erweitert bestehende Ideen.
5️⃣ Vorgang wird wiederholt, bis alle Zeilen gefüllt sind.
👉 Ziel: Strukturierte Ideengenerierung & Weiterentwicklung ohne direkte Diskussion.
✅ Zentrale Idee im Mittelpunkt, umgeben von 8 Ideenblättern.
✅ Erste Runde: Ideen zu dieser Hauptidee sammeln.
✅ Zweite Runde: Jede Idee wird zum neuen Zentrum, weitere Ideen entwickeln.
✅ Besonders geeignet für Weiterentwicklungen bestehender Produkte/Prozesse.
✅ Ziel: Den zukünftigen Erfolg eines Produkts aus Nutzersicht definieren.
✅ Ablauf:
1️⃣ Teilnehmer versetzen sich zwei Jahre in die Zukunft (z. B. 2026).
2️⃣ Sie beschreiben, wie das Produkt ihr Leben verbessert hat.
3️⃣ Danach gehen sie weitere zwei Jahre in die Zukunft (z. B. 2028) und konkretisieren, was das Produkt geleistet hat.
✅ Wichtig: Frage in der Vergangenheitsform formulieren → realistischere & detailliertere Ergebnisse.
✅ Ziel: Neue, unerwartete Ideen durch Kombination von Merkmalen finden.
✅ Ablauf:
1️⃣ Merkmale (Attribute) eines Produkts/Systems in eine Matrix schreiben.
2️⃣ Mögliche Ausprägungen der Merkmale rechts daneben notieren.
3️⃣ Merkmalkombinationen bilden:
✅ Ziel: Produktverpackung entwerfen (auch für virtuelle Produkte)
✅ Schritte:
1️⃣ Wichtigste Botschaft festlegen → Was überzeugt den Kunden?
2️⃣ Produktname wählen, der die Idee transportiert.
3️⃣ Bild/Skizze ergänzen, die das Produkt symbolisiert.
4️⃣ Wichtige Features auflisten.
5️⃣ Anforderungen an die Umgebung definieren.
✅ Ziel: Features priorisieren durch simulierten Kaufprozess.
✅ Ablauf:
1️⃣ Liste möglicher Features mit Preisen erstellen.
2️⃣ Teilnehmer (Kunden/Nutzer) erhalten Spielgeld.
3️⃣ Sie investieren in gewünschte Features.
4️⃣ Teure Features fördern Verhandlungen & Gruppenentscheidungen.
✅ Ergebnis: Die wichtigsten Features aus Kundensicht identifizieren.
✅ Gruppendiskussion mit 6 Denkweisen (Hüte):
✅ Ziel: Verschiedene Perspektiven einnehmen, um fundierte Entscheidungen zu treffen.
Kontext Analyse
KONTEXTANALYSE
...wie können die Ergebnisse dokumentiert werden?
✅ Physical Models:
✅ Artifact Models:
✅ Flow Models:
Entscheidungen der Projektebene
✅ Thema: Welches Problem oder Ziel steht im Fokus?
✅ Stakeholder: Wer ist betroffen (Organisationen, Personen)?
✅ Ziele: Was soll erreicht oder geschaffen werden?
✅ Prozesse: Welche fachlichen Aufgaben müssen analysiert oder optimiert werden?
Thema
Projektbeschreibung
Name: Name des Projektes
Kurzbeschreibung: Gegenstand / Thema des Projektes, kurze Motivation
Zeitraum: Geplante Projektlaufzeit, Releases, etc. Kunde Name, Kontaktdaten
Sonstige Informationen: z.B. ausgeschlossene Themen / Änderungen, etc.
Stakeholder
Feld Beschreibung
ID: Eindeutige Kennung für den Stakeholder
Bezeichnung: Name oder Bezeichnung des Stakeholders
Funktion / Rolle: Rolle im Projekt (z. B. Nutzer, Sponsor)
Kontaktdaten: Ansprechpartner und deren Kontaktinformationen
Verfügbarkeit: Erreichbarkeit der Ansprechpartner im Projekt
Interesse: Einstellung des Stakeholders zum Projekt
Einfluss: Macht & Entscheidungsbefugnis im Projekt
Ziele / Interessen: Wichtige Zielsetzungen und Interessen im Projekt
Hilfsmittel
🔹 Schicht 1: Enge Beteiligung (Projektleiter, Entwickler)
🔹 Schicht 2: Betroffene durch Änderungen (Endnutzer)
🔹 Schicht 3: Externe Einflussnehmer (Sponsoren, Behörden, Politik)
Stakeholder werden nach Einfluss (niedrig/hoch) und Interesse (gering/hoch) eingeteilt:
🔹 A (hoch/hoch): Schlüsselakteure, in Planung & Entscheidungen einbinden (z. B. Projektleiter, Sponsoren).
🔹 B (hoch/gering): Mächtig, aber wenig interessiert, Entscheidungen in ihrem Interesse treffen (z. B. Führungskräfte).
🔹 C (gering/hoch): Hoher Einsatz, wenig Macht, gut informieren & einbinden (z. B. Endnutzer, Berater).
🔹 D (gering/gering): Kaum Einfluss & Interesse, minimal informieren (z. B. Betriebsrat).
✅ Ziel: Wichtige Stakeholder gezielt einbinden & Widerstände vermeiden.
✅ Ermittlung der gewünschten Zielzustände der Stakeholder
🔹 Top-Down-Analyse:
🔹 Bottom-Up-Analyse:
Feld Beschreibung
ID Eindeutige Kennung für das Ziel
Bezeichnung Klarer, eindeutiger Name des Ziels
Priorität Wichtigkeit des Ziels (hoch, mittel, gering)
Kritikalität Relevanz für den Projekterfolg
Quelle Ursprung des Ziels (Stakeholder, Dokument, System)
Unterstützte Stakeholder Personen/Gruppen, die von der Zielerreichung profitieren Beschreibung Detaillierte Erklärung des Ziels
Übergeordnete Ziele Zugehörige Hauptziele inkl. Verfeinerungstyp (UND/ODER) Untergeordnete Ziele Subziele inkl. Verfeinerungstyp (UND/ODER)
Weitere Zielbeziehungen Verknüpfungen zu anderen Zielen (z. B. Konflikte)
Feld Beschreibung
ID Eindeutige Kennung der Aufgabe/des Prozesses
Bezeichnung Klarer, eindeutiger Name
Zielsetzung Zweck der Aufgabe/des Prozesses
Involvierte Rollen Stakeholder (Rollen), die beteiligt sind
Durchführungsprofil Häufigkeit der Durchführung (häufig, selten)
Motive Übergeordnete Ziele, die die Aufgabe antreiben
Priorität Wichtigkeit der Aufgabe/des Prozesses
Vorbedingungen Voraussetzungen für die erfolgreiche Durchführung
Benötigte Informationen Relevante Daten/Dokumente als Input
Ergebnisse Resultate nach der Durchführung (Dokumente, Daten)
User Research
✅ Nutzer verstehen: Ziele, Bedürfnisse, Eigenschaften
✅ Psychologische Aspekte: Motivation, Einstellung, Erfahrung
✅ Fachliche Faktoren: Wissen, Beruf, Software-Erfahrung
✅ Physische Merkmale: Alter, Geschlecht, Einschränkungen
✅ Fiktiver Stereotyp, basierend auf User Research
✅ Erleichtert Nutzerverständnis & Produktanforderungen
✅ Inhalte: Name, Demographie, Rolle, Zitat, Bild
✅ Fokus: Ziele, Aufgaben, Nutzungskontext, Herausforderungen
Allgemeines Vorgehen zur Erstellung einer Persona
Proto Persona erstellen->Daten erheben->Daten analysieren&validieren (Kreislauf)
Warum ist eine Priorisierung von Personas wichtig?
Zu viele Personas führen zu Feature-Überladung und schlechter Nutzeranpassung.
👉 Lösung: Priorisierung in primäre, sekundäre & ausgeschlossene Personas.
Customer Journey
✅ Gesamter Nutzerprozess: Von Erstkontakt bis nach dem Kauf.
✅ Bestandteile:
Sales-Funnel Model
Das Sales Funnel Modell beschreibt die Phasen, die ein Kunde durchläuft, bevor er eine Kaufentscheidung trifft. Es ähnelt der Customer Journey, fokussiert sich jedoch stärker auf den Verkaufsprozess.
🔹 Awareness (Bewusstsein): Kunde erfährt vom Produkt.
🔹 Interest (Interesse): Kunde informiert sich weiter.
🔹 Decision (Entscheidung): Kunde erwägt den Kauf.
🔹 Action (Aktion): Kunde kauft das Produkt.
✅ Ziel: Nutzer gezielt durch den Verkaufsprozess führen & Conversion optimieren.
Empathy Map
Eine Empathy Map ist ein Tool zur Analyse der Nutzerperspektive. Sie hilft, das Verhalten, die Gedanken und Emotionen der Nutzer besser zu verstehen.
Sie besteht aus vier Hauptbereichen:
🔹 Sagt – Was äußert der Nutzer?
🔹 Denkt – Was beschäftigt ihn innerlich?
🔹 Fühlt – Emotionen, Sorgen, Wünsche
🔹 Tut – Wie verhält er sich?
✅ Ziel: Tiefere Nutzerkenntnis für eine nutzerzentrierte Produktentwicklung.
✅ Workshop (~20 Min.) mit Team, das die Zielgruppe kennt.
✅ Fokus festlegen:
✅ Ziel: Anforderungen systematisch spezifizieren & verwalten, Stakeholder-Konsens erreichen, Fehlentwicklungen vermeiden.
RE → Design → Implementierung → Integration → Einführung → Wartung
⚠ Fehlerquellen in Projekten:
📌 Beispiel für Missverständnis:
Anforderung: Umkehrschub nur nach Landung aktivierbar.
Fehlinterpretation: Aktivierung erst, wenn Räder schnell drehen.
Folge: Kein Umkehrschub bei Aquaplaning → Flugzeug verlässt Landebahn → Unfall. 🚨
🛠 Herausforderungen:
Dokumentanalyse&Systemarchäologie
✅ Dokumentanalyse:
✅ Systemarchäologie:
❌ Nachteile:
Apprenticing
✅ Beschreibung:
✅ Vorteile (zusätzlich zur Feldbeobachtung):
❌ Nachteile (zusätzlich zur Feldbeobachtung):
Contextual Inquiries
✅ Beschreibung:
✅ Best Practices:
Feldbeobachtung
✅ Beschreibung:
✅ Vorteile:
❌ Nachteile:
Interviews
✅ Vorteile:
❌ Nachteile:
✅ Vorbereitung:
✅ Gesprächsbeginn:
✅ Durchführung:
✅ Gesprächsende:
✅ Nachbereitung:
🔹 Ziel: Klare, strukturierte Interviews, die relevante Informationen liefern und Missverständnisse vermeiden. ✅
Fokusgruppe
✅ Eigenschaften:
✅ Vorteile (vs. Einzelinterviews):
❌ Nachteile:
1. Vorbereitung:
2. Beginn:
3. Durchführung:
4. Ende:
5. Nachbereitung:
Umfragen
✅ Vorteile:
❌ Nachteile:
🔹 Mit der Zeit werden Begeisterungsmerkmale zu Leistungs- oder Basismerkmalen.
🔹 Technischer Fortschritt erhöht Kundenerwartungen.
🔹 Erfolgreiche Produkte erfüllen Basismerkmale, bieten nützliche Leistungsmerkmale und heben sich durch Begeisterungsmerkmale ab.
🔹 Nutzungskontext beeinflusst Erwartungen – Benutzerziele, physisches & soziales Umfeld berücksichtigen.
✅ Begriff "Bug":
✅ Auswirkungen von Software-Bugs:
✅ Fehlertypen:
✅ Testing – Ziele:
1️⃣ Bugs finden
2️⃣ Qualität prüfen
3️⃣ Vertrauen erhöhen
✅ Testing – Definition:
✅ Validation vs. Verification:
✅ Qualitätskriterien & Tests:
✅ Testing vs. Qualität:
✅ 7 Regeln des Testings:
1️⃣ Tests beweisen Bugs, nicht deren Abwesenheit.
2️⃣ 100% Testabdeckung ist unmöglich.
3️⃣ Früh testen!
4️⃣ Fehler treten oft in Clustern auf.
5️⃣ Wiederholtes Testen reicht nicht.
6️⃣ Use Cases bestimmen Testfokus.
7️⃣ Ein funktionierendes System ≠ ein zufriedenes System. 🚀
✅ V-Modell – Teststufen:
1️⃣ Component Testing: Prüfung einzelner Komponenten (Unit & Class Testing).
2️⃣ Integration Testing: Überprüfung der Zusammenarbeit von Komponenten (Bottom-Up, Top-Down).
3️⃣ System Testing: Test des gesamten Systems auf funktionale & nicht-funktionale Anforderungen.
4️⃣ Acceptance Testing: Validierung, ob das System alle Nutzeranforderungen erfüllt.
✅ Regression Testing (Wartungstests):
✅ Testkategorien:
✅ Statisches vs. Dynamisches Testing:
Idee:
Grenzwerte in if-then-else-Strukturen oder Schleifen sind fehleranfällig (z. B. Off-by-One-Fehler). Besonders effektiv in Kombination mit Äquivalenzpartitionierung.
Wichtige Prüfungen:
Vor- & Nachteile:
✅ Häufige Fehlerquelle → Hohe Fehlererkennung.
✅ Effiziente Kombination mit anderen Methoden.
❌ Komplexe Identifikation aller Grenzen.
❌ Erfordert kreative Testfälle.
Äquivalenzklassenbildung teilt Eingaben in Gruppen mit ähnlichem Verhalten ein. Ein Wert aus einer Partition repräsentiert die gesamte Gruppe – wenn er einen Fehler aufdeckt, tut es jeder andere Wert in der Gruppe auch. Ebenso gilt, dass ein fehlerfreier Wert für alle in der Gruppe gilt.
✅ Reduziert Testfälle, effizient für viele Eingaben.
❌ Berücksichtigt schwer Interdependenzen, sollte mit Grenzwertanalyse kombiniert werden.
✅ Testmethoden:
1️⃣ Blackbox Testing: Testet das System ohne Kenntnis des Codes (eingabe- & ausgabebasiert).
✅ Begriffe:
✅ Ziel dynamischer Tests:
🚀 Herausforderung:
Advanced Testing Strategies
private → public etc.super) entfernen.Mutation Testing hilft, Testfälle zu verbessern, indem es überprüft, ob sie Code-Modifikationen erkennen.
when(itemRepository.findById("it1")).thenReturn(mockedItem);
verify(itemRepository, times(1)).findById("it1");
Mocking hilft, Klassen isoliert zu testen, Fehlerquellen zu minimieren und stabile Unit-Tests zu schreiben.
Whitebox Testing
Diese Konzepte helfen, die Testbarkeit und Qualität von Code zu bewerten und zu verbessern. 🚀
Controllflow-based Testing
Diese Methoden helfen dabei, eine möglichst hohe Code-Abdeckung zu erreichen und Fehler frühzeitig zu erkennen.
✅ Review-Typen:
1️⃣ Informal Review: Einzelprüfung, kein fester Prozess, günstig, optional dokumentiert.
2️⃣ Walkthrough: Autor präsentiert das Dokument, informell, keine Vorbereitung nötig.
3️⃣ Technical Review: Formelle Prüfung durch Experten, erfordert Dokumentation.
4️⃣ Inspection: Strukturierteste & formellste Methode, mit festen Rollen & Checklisten.
✅ Review-Prozess:
🔹 Planung: Festlegung von Dokumenten, Team & Kriterien.
🔹 Kick-Off: Vorstellung der Dokumente & Sammeln von Checklisten.
🔹 Individuelle Vorbereitung: Jeder prüft das Dokument auf Fehler.
🔹 Meeting: Moderator führt durch den Review, Diskussionen sind nicht erlaubt.
🔹 Ergebnisse: Fehlerbewertung (kritisch, Hauptfehler, geringfügig, akzeptiert).
🔹 Rework: Fehlerbehebung & erneuter Review bei Bedarf.
🔹 Abschluss: Messwerte sammeln, entscheiden, ob weitere Reviews nötig sind. 🚀
✅ Vorteile von Reviews:
✅ Probleme bei Reviews:
✅ Grundsatz:
✅ Können Entwickler ihre eigenen Programme testen?
✅ Unabhängiges Testing-Team:
✅ Fehlermeldung & Kommunikation:
✅ Testplanung & Steuerung:
✅ Testanalyse & Design:
✅ Testimplementierung & Ausführung:
✅ Test Oracle (Erwartete vs. Tatsächliche Ergebnisse):
✅ Testauswertung & Abschluss:
Modellbildung
ist zentrale Aufgabe des Entwicklungsprojekts.
Ziel ist die Beschreibung der wesentlichen Eigenschaften des Zielsystems.
-->ggf. durch vereinfachte, abstrakte Repräsentation in Form eines Systemmodells.
Systemmodelle
entstehen sukzessive während des Entwicklungsprozesses.
werden schrittweise verfeinert und konkretisiert.
hauptsächlich während der Analyse und Design Aktivitäten
verschiedene Abstraktionsstufen möglich: Analysemodell, Designmodell, Architekturmodell etc.
Aspekte der Modellbildung
Gegenstände der Modellierung
Anwendungskontext der Modellierung
Sichten der Modellierung
Modellierungskonzepte
Methodik der Modellbildung
Aspekte der Verhaltensmodellierung lassen sich grob drei verschiedenen Sichten zuordnen.
Externe Verhaltenssicht
beschreibt:
Die Anwendungssituationen, in denen das System zum Einsatz kommt.
Das extern sichtbare Verhalten des Systems in verschiedenen Anwendungssituationen
-->externe Szenarien.
Interne Verhaltenssicht
beschreibt:
die dynamische Interaktion, Kommunikation und Synchronisation der Objekte, durch die das externe Verhalten intern realisiert wird
-->interne Szenarien.
Objektsicht
beschreibt:
welche Verantwortlichkeiten ein bestimmtes Objekt erfüllt.
wie ein Objekt auf den Eintritt von bestimmten Ereignissen reagiert.
unter welchen Umständen ein Objekt seinen Zustand verändert.
Die Unified Modeling Language (UML)
ist eine standardisierte, universelle, semi-formale Modellierungsnotation zur Visualisierung, Spezifikation, Entwicklung und Dokumentation von Softwaresystemen, die 1997 zum ersten Mal veröffentlich wurde.
ist keine Methodik sondern nur visuelle Darstellung
ist eine Modellierungsnotation mit graphischen unt textuellen Notationselementen
besitzt wohldefinierte Syntax und Semantik
dient der Modellierung von Softwaresystemen.
Notation, die Aspekte ,Sichten und Abstraktionsebenen eines Systemmodells beschreibt.
kann in allen Aktivitäten des Softwareentwicklungsprozesses eingesetzt werden.
bietet Notationselemente für statistische Systemstruktur, dynamisches Systemverhalten und Systemarchitektur.
ist keine Modellierungsmethode, sondern eine Modellierungsnotation.
unterstützt den Entwicklungsprozess, schreibt aber keinen bestimmten vor.
erzwingt keine bestimmte Programmiersprache.
erzwingt keine bestimmten Modellierungs-oder Entwicklungswerkzeuge
erzwingt keine bestimmten Vorgehensmodelle
Syntax legt formal fest, ob eine Modellbeschreibung korrekt im Sinne der UML-Sprachdefinition ist.
Semantik legt semi-formal fest, wie eine syntaktisch korrekte Modellbeschreibung zu verstehen ist.
• UML ist selbst in UML formuliert (UML-Metamodell).
Rollen
beschreiben ,welche Funktion ein Objekt ein einer Verknüpfung innehat
zu jeder an einer Assoziation beteiligten Klasse kann eine Rolle definiert werden
Der Gebrauch von Rollen ist optional
Meist ergibt sich die Rolle bereits aus dem Namen der Klasse
Rollen sind verpflichtet ,wenn zwischen zwei Klassen mehr als eine Assoziation besteht.
+------------+ +------------+
| Mitarbeiter| | Abteilung |
+------------+ +------------+
| |<>------->| Leiter |
| |--------->| Mitglied |
+------------+ +------------+
Oder wenn eine Assoziation Objekte der gleichen Klasse miteinander verknüpft
+---------+
| Person |
+---------+
| |<----+
| | |
+---------+ |
^ |
| "Vorgesetzter"
|
"Untergebener"
Objekte
Objektname : Klassenname (Unterstrichen)einKunde : Kunde
Anrede=Herr
Vorname:"Hans"
Adresse="Musterstr. 1 97212 Deutschland"
Spezifikation von Attributen
Attributname
Attributtyp(opt.):String,boolean,Date
Typkonformer Initialwert(opt.)
Kunde
-----------------
Anrede: Anredetyp
Vorname: String[30]
Nachname:String[30]
Adresse:String[200]
Alter:Integer
Darstellung von Operationen
Operationsname
Signatur(opt.)
zusätzliche Eigenschaften(opt.)
Sichtbarkeit von Operationen
• + public • - private • # protected • ~package
Beispiel
[+|-|#] Name(Parameterliste) [: Rückgabetyp]
+ addiere(a: int, b: int): int
- speichereDaten(daten: String)
[Visibility] → + (public), - (private), # (protected)
Op_Name → Name der Methode
Parameter_List → Liste der Parameter
: Return_Type → Rückgabewert (optional)
["in"|"out"|"inout"] → Definiert die Datenflussrichtung (meist in als Standard)
Default_Value → Standardwert für Parameter (optional)
Kunde
-------------
Anrede Titel
Vorname
Nachname
Straße
PLZ
-------------
erfassen
aktualisieren
löschen
(Darstellung einer Klasse)
Assoziationen
Kunde hat ein Konto
Konto-----------------Kunde
Ein Mitarbeiter arbeitet in einer Firma
Firma------------------- beschäftigt>-----------Mitarbeiter
-------- <arbeitet für ----------------
name name
anschrift anschrift
Kardinalitäten und Multiplizitäten
1:1 1
1:n(n>=1) 1..*
1:n(n>=0) 0..*/*
optional 0..1
feste c (3/5/10)
Intervall 5..15
Ordnungs- {ordered}
beziehung
Aggregationsbeziehung: Eine "hat-ein"-Beziehung, bei der ein Teil unabhängig vom Ganzen existieren kann. Beispiel: Eine Universität besteht aus Fakultäten, aber eine Fakultät kann auch ohne eine bestimmte Universität existieren.
Eine hohle Raute an der Seite des Ganzen.
Universität ◇── FakultätKompositionsbeziehung: Eine stärkere "besteht-aus"-Beziehung, bei der die Teile ohne das Ganze nicht existieren können. Beispiel: Ein Haus besteht aus Räumen, die ohne das Haus nicht sinnvoll existieren.
Eine ausgefüllte Raute an der Seite des Ganzen.
Haus ◆── Raum
UML
Strukturdiagramme
Objektdiagramm
Klassendiagramm
Komponentendiagramm
Verteilungsdiagramm
Paketdiagramm
Kompositionsstrukturdiagramm
Profildiagramm
Verhaltensdiagramme
Use Case Diagramm
Aktivitätsdiagramm
Zustandsdiagramm
Interaktionsübersichtsdiagramm
Sequenzdiagramm
Kommunikationsdiagramm
Timingdiagramm
Softwareentwicklungsprozess
Analyse
Use Case Diagramm
Objektdiagramm
Analyse&Design
Klassendiagramm
Aktivitätsdiagramm
Zustandsdiagramm
Interaktionsdiagramme
Paketdiagramm
Kompositionsstrukturdiagramm
Design
Komponentendiagramm
Verteilungsdiagramm
Sequenzdiagramme
UML-Notation für Interaktionen
Jede Interaktion wird durch ein Rechteck spezifiziert und enthält:
• Das Schlüsselwort sd gefolgt vom Namen
• Eine Liste von Ein-/Ausgabeparametern (optional)
• Eine Liste lokaler Attribute (optional)
• Vor- und Nachbedingungen (optional)
• Ein Interaktionsdiagramm
Sequenzdiagramme
Primäre Zielsetzung: Beschreibung des zeitlischen Ablaufs der Interaktion.
Speziell geeignet zur Darstellung von nichttrivialen Kontrollstrukturen.
Interaktionspartner
Dargestellt durch Rechteck mit Beschriftung (Name).
Eine gestrichelte Lebenslinie, die nach unten berläuft.
Typische Interaktionspartner sind Objekte oder Aktoren.
Virtuelle Zeitachse
Bestimmt die zeitliche Ordnung der dargestellten Ereignisse
Verläuft parallel zu den Lebenslinien der Interaktionspartner von oben dach unten.
Wird nicht explizit dargestellt.
Aktivitätsbalken
Darstellung als Rechteck, das die Lebenslinie überlappt.
Symbolisiert Aktivität des Interaktionspartners.
Oder das Warten auf eine Antwort.
Nachrichten
Jede Kommunikation zwischen zwei Interaktionspartnern wird durch eine Nachricht modelliert.
Eine Nachricht wird durch einen Pfeil zwischen den Lebenslinien repräsentiert.
Eine Nachricht besitzt einen Namen.
Rückgabewert und Parameter sind optional: typ:=name(ar1,..,argn)
Synchroner Nachrichtemechanismus
Bei synchronen Nachrichten wartet der Sender, bis er Antwort erhält.
Synchroner Selbstaufruf
Selbstaufrufe eines Objektes werden durch gestapelte Aktivitätsbalken dargestellt.
Asynchroner Nachrichtenmechanismus
Sender und Empfänger arbeiten unabhängig voneinander
Der Sender wartet nicht auf eine Antwort
Der Empfänger kann die Nachricht parallel zu Aktivitäten des Senders bearbeiten
Objekterzeugung&-zerstörung
Die Erzeugung eines Objekts wird durch eine Konstruktor-Nachricht dargestellt.
Die Vernichtung wird durch das vorzeitige Ende der Lebenslinie angezeigt (Kreuz).
Zeitbedingungen
zur Formulierung von Zeiteigenschaften besteht die Möglichkeit
• einen Zeitpunkt mit einer Zeitmarke (kurze horizontale Linie) zu kennzeichnen,
• die aktuelle Systemzeit an einer Zeitmarke mit now abzufragen,
• ein Zeitintervall zwischen zwei Zeitpunkten zu kennzeichnen,
• und die Dauer eines Zeitintervalls mit duration abzufragen.
Kombinierte Fragmente
Motivation
Kombinierte Fragmente bieten eine übersichtliche Notation für Fallunterscheidungen, Schleifen und Nebenläufigkeit.
Ein kombiniertes Fragment besteht aus:
• Einem rechteckigen Fragmentrahmen
• Einen Interaktionsoperator
• Interaktionsoperanden, die durch gestrichelte Linien separiert sind
• Interaktionsbedingungen
alt-Operator
• Beim alt-Operator stehen n Ablaufalternativen zur Auswahl (n > 1)
• Jede Ablaufalternative wird durch einen Interaktionsoperanden spezifiziert
• Anhand der Interaktionsbedingungen genau eine der Alternativen ausgewählt
opt-Operator
• Dient zur Modellierung typischer if/then Strukturen ohne else.
• Hat nur einen Interaktionsoperanden.
• Ist die Bedingungen erfüllt, wird er ausgeführt,
• ansonsten übersprungen.
break-Operator
• Dient zur Modellierung von Fehlersituationen oder Ausnahmen.
• Hat nur einen Interaktionsoperanden.
• Wird der Interaktionsoperand ausgeführt, wird die umgebende Interaktion vollständig beendet.
loop-Operator
• Dient zur Modellierung von Schleifen.
• Hat nur einen Interaktionsoperanden → Schleifenrumpf
par-Operator
• Der par-Operator hat n Operanden (n > 1), die nebenläufig abgewickelt werden können.
• Ereignisse können quasi parallel stattfinden
• Die Ereignisse innerhalb eines Operanden bleiben allerdings sequenziell.
critical-Operator
• der critical-Operator hat genau einen Interaktionsoperanden, der atomar abgewickelt wird
Use Case Diagramme
Ein Use-Case-Diagramm zeigt zusammengehörige Use Cases, Akteure und deren Beziehungen. Ziel ist die Modellierung des externen Systemverhaltens, die Abgrenzung des Systems sowie die Definition seines Einsatzzwecks und erwarteten Verhaltens. Es wird während der Anforderungsdefinition genutzt.
Notationselemente
Knoten
Das System -> charakterisiert die Abgrenzung der zu erstellenden Anwendung gegenüber der Außenwelt.
Akteure -> repräsentieren Personen oder andere externe Systeme, die mit dem Zielsystem interagieren.
Use Cases-> beschreiben Funktionalitäten des Systems.
Kanten
Assoziationen zwischen Use Cases und Akteuren ≡ Kommunikationsverbindungen
Abhängigkeitensbeziehungen zwischen Use Cases (include oder extend)
Generalisierungsbeziehungen zwischen Use Cases
Generalisierungsbeziehungen zwischen Akteuren
Akteure
definiert die Rolle eines Objektes außerhalb des Zielsystems, das mit dem Zielsystem interagiert.
Anwender des Systems in ihren unterschiedlichen Rollen.
Organisationseinheiten oder Abteilungen, die das System kollektiv nutzen.
Externe Peripheriegeräte, wie Sensoren, Geräte Drucker.
Externe Systeme, die über Datenschnittstellen mit dem Zielsystem kommunizieren.
Akteure und Use Cases
werden im UCD durch eine Kommunikationsverbindung miteinander verknüpft, wenn:
Der Akteur den Use Case initiiert.
Der Akteur bei Durchführung des Use Cases anderweitig mit dem System interagiert.
Der Akteur infolge der Durchführung des Use Cases direkt oder indirekt durch das System mit Informationen versorgt wird.
Kommunikationsverbindungen sind Spezielfälle von Assoziationen und ein Use Case kann mit mehreren Akteuren verknüpft sein.
Checkliste für die Beschreibung der Use Cases
1. Kurzbeschreibung
2. Vorbedingungen
3. Nachbedingungen
4. Akteure
5. Trigger
6. Beschreibung des Default-Szenarios
7. Fehlersituationen / Alternativen / Varianten
• Kurzbeschreibung
Ein Termin kann für einen oder mehrere Teilnehmer von dazu berechtigten Benutzern erfasst werden. Pro Termin können bis zu drei Notifikationen spezifiziert und Teilnehmer ihnen zugeordnet werden. Alle Teilnehmer müssen über diesen neuen Termin verständigt werden. Neue Termine müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden.
• Vorbedingungen Benutzer ist dem System bekannt
• Nachbedingungen Neuer Termin ist erfasst. Alle Teilnehmer sind verständigt und gegebenenfalls informiert. Alle Sichten sind aktualisiert
• Akteure Benutzer, Email-System, Fax-System
• Trigger keine
• Beschreibung des Default-Szenarios
1. Benutzer meldet sich an
2. Eckdaten des neuen Termins werden erfasst
3. Alle Teilnehmer werden dem Termin zugeordnet
4. Benutzer ist berechtigt für alle Teilnehmer den Termin zu erfassen
5. Termin führt bei keinem zu Kollisionen
6. Alle Teilnehmer werden benachrichtigt
7. Alle geöffneten Kalender werden aktualisiert
• Fehlersituationen / Alternativen / Varianten Benutzer hat für keinen der Teilnehmer die Berechtigung, den Termin im Kalender des Teilnehmers einzutragen.
Beziehungen
Einschlußabhängigkeit
Mehrere unterschiedliche Use Cases können identische Sequenzen enthalten
Der gemeinsame Anteil kann als eigener Use Case separiert werden
Der separierte Use Case wird durch eine <<include>>-Beziehung einbezogen (Pfeilspitze zeigt zum separaten Use Case)
Geld abheben --------------<<include>>-------------->Kunde identifizieren
Erweiterungsabhängigkeit
Varianten, Fehler- und Ausnahmesituationen eines Use Cases können als eigenständige Use Cases separat modelliert werden
Der Use Case ,der die Variante bzw. die Ausnahmesituation beschreibt, wird durch eine <<extend>>-Beziehung einbezogen (Pfeilspitze zeigt zum Standard-Use-Case)
Der Standard-Use-Case enthält einen Extension Point
Meldung über Kreditlinienüberschreitung----<<extends>>---->Geld abheben//extensionpoints(Kredilimit überschreiten)
Generalisierung/Spezialisierung
Ein Use Case kann durch andere Use Cases spezialisiert werden,die die Spezifikation seines externen Verhaltens vollständig übernehmen und weitere,spezielle Eigenschaften hinzufügen.
Der speziellere Use Case kann den allgemeineren Use Case in seinem Kontext ersetzen.
Ein Akteur kann ebenfalls durch einen anderen Akteur spezialisiert werden.
Passwort prüfen-------------->Benutzeridentität prüfen
• Anforderungsdefinition: Welche Anforderungen will man mit dem Zielsystem erfüllen?
• Analyse: Wie kann das Zielsystem mit seinen Anforderungen modelliert werden?
• Design: Wie kann das Modell inklusive technischer Rahmenbedingungen umgesetzt werden?
• Implementierung Wie können die Komponenten des Entwurfs umgesetzt werden?
• Integration Wie können die lauffähigen Komponenten zu einem Gesamtsystem zusammengesetzt werden?
• Stabilisierung Wie kann überprüft werden, ob das Gesamtsystem die ursprünglichen Anforderungen erfüllt?
Software (Strukturierte Sichtweise)
ist eine Sammlung von Prozeduren, die eine vorgegebene Funktionalität zur Verfügung stellen.
Die Funktionalität steht im Vordergrund.
Von Prozeduren werden Daten ver- und bearbeitet.
Vorhandene Daten werden von einer Vielzahl von Programmen genutzt.
Struktur der Daten ist den Prozeduren bekannt.
Nachteile der strukturierten Sichtweise
Daten und Programmen sind miteinander verflochten.
Daten werden von Umständen von mehreren Programmen genutzt.
Änderungen von Daten benötigen evtl. Änderungen von Programmen.
Daten sind ungeschützt.
Wiederverwendbarkeit von Programmen ist nur bedingt gegeben.
Objektorientierte Sichtweise
Software wird als Sammlung realer Objekte betrachtet, die Daten und zugehörige Methoden kapseln.
Eine Software besteht aus einer Menge von Objekten, die einen Bezug zur Realität haben.
Ein Objekt besitzt Daten und Methoden, durch die Daten manipuliert werden können.
Auf die Daten eines Objektes kann nur über dessen Methoden zugegriffen werden.
Objekte integrieren durch das Versenden von Nachrichten.
Das Verhalten eines Objekts wird durch seine Methoden beschrieben.
Sie wollen ein Schachspiel programmieren. Welche Objekte wären dafür sinnvoll?
Schachbrett: 2D-Array (String[][]), das die Positionen der Figuren speichert.
Figur: Klasse mit Typ (Bauer, Dame etc.) und Farbe (String).
Spieler: Enthält Name und Farbe.
Spiel: Verwaltet den Spielablauf, z. B. Zugvalidierung und Status.
