Softwareentwicklung

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 SichtweiseDaten 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 SichtweiseSoftware 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.

• 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? 

Modellbildungist zentrale Aufgabe des Entwicklungsprojekts.Ziel ist die Beschreibung der wesentlichen Eigenschaften des Zielsystems.-->ggf. durch vereinfachte, abstrakte Repräsentation in Form eines Systemmodells.Systemmodelleentstehen sukzessive während des Entwicklungsprozesses.werden schrittweise verfeinert und konkretisiert.hauptsächlich während der Analyse und Design Aktivitätenverschiedene Abstraktionsstufen möglich: Analysemodell, Designmodell, Architekturmodell etc.Aspekte der ModellbildungGegenstände der ModellierungAnwendungskontext der ModellierungSichten der ModellierungModellierungskonzepteMethodik der Modellbildung

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 Darstellungist eine Modellierungsnotation mit graphischen unt textuellen Notationselementenbesitzt wohldefinierte Syntax und Semantikdient 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 Entwicklungswerkzeugeerzwingt 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).

UMLStrukturdiagrammeObjektdiagrammKlassendiagrammKomponentendiagrammVerteilungsdiagrammPaketdiagrammKompositionsstrukturdiagrammProfildiagrammVerhaltensdiagrammeUse Case DiagrammAktivitätsdiagrammZustandsdiagrammInteraktionsübersichtsdiagrammSequenzdiagrammKommunikationsdiagrammTimingdiagrammSoftwareentwicklungsprozessAnalyseUse Case DiagrammObjektdiagrammAnalyse&DesignKlassendiagrammAktivitätsdiagrammZustandsdiagrammInteraktionsdiagrammePaketdiagrammKompositionsstrukturdiagrammDesignKomponentendiagrammVerteilungsdiagramm

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.NotationselementeKnotenDas 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.KantenAssoziationen zwischen Use Cases und Akteuren ≡ KommunikationsverbindungenAbhängigkeitensbeziehungen zwischen Use Cases (include oder extend)Generalisierungsbeziehungen zwischen Use CasesGeneralisierungsbeziehungen zwischen AkteurenAkteuredefiniert 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 Caseswerden 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.

EinschlußabhängigkeitMehrere unterschiedliche Use Cases können identische Sequenzen enthaltenDer gemeinsame Anteil kann als eigener Use Case separiert werdenDer separierte Use Case wird durch eine <<include>>-Beziehung einbezogen (Pfeilspitze zeigt zum separaten Use Case)Geld abheben --------------<<include>>-------------->Kunde identifizierenErweiterungsabhängigkeitVarianten, Fehler- und Ausnahmesituationen eines Use Cases können als eigenständige Use Cases separat modelliert werdenDer 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 PointMeldung über Kreditlinienüberschreitung----<<extends>>---->Geld abheben//extensionpoints(Kredilimit überschreiten)Generalisierung/SpezialisierungEin 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

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.

UML-Notation für InteraktionenJede 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 SequenzdiagrammePrimäre Zielsetzung: Beschreibung des zeitlischen Ablaufs der Interaktion.Speziell geeignet zur Darstellung von nichttrivialen Kontrollstrukturen.InteraktionspartnerDargestellt durch Rechteck mit Beschriftung (Name).Eine gestrichelte Lebenslinie, die nach unten berläuft.Typische Interaktionspartner sind Objekte oder Aktoren.Virtuelle ZeitachseBestimmt die zeitliche Ordnung der dargestellten EreignisseVerläuft parallel zu den Lebenslinien der Interaktionspartner von oben dach unten.Wird nicht explizit dargestellt.AktivitätsbalkenDarstellung als Rechteck, das die Lebenslinie überlappt.Symbolisiert Aktivität des Interaktionspartners.Oder das Warten auf eine Antwort.NachrichtenJede 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 NachrichtemechanismusBei synchronen Nachrichten wartet der Sender, bis er Antwort erhält.Synchroner SelbstaufrufSelbstaufrufe eines Objektes werden durch gestapelte Aktivitätsbalken dargestellt.Asynchroner NachrichtenmechanismusSender und Empfänger arbeiten unabhängig voneinanderDer Sender wartet nicht auf eine AntwortDer Empfänger kann die Nachricht parallel zu Aktivitäten des Senders bearbeitenObjekterzeugung&-zerstörungDie Erzeugung eines Objekts wird durch eine Konstruktor-Nachricht dargestellt.Die Vernichtung wird durch das vorzeitige Ende der Lebenslinie angezeigt (Kreuz).

MotivationKombinierte 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 • Interaktionsbedingungenalt-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ähltopt-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 → Schleifenrumpfpar-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 

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. 

Kunde-------------Anrede TitelVornameNachnameStraße PLZ-------------erfassenaktualisierenlöschendrucken(Darstellung einer Klasse)AssoziationenKunde hat ein KontoKonto-----------------KundeEin Mitarbeiter arbeitet in einer FirmaFirma------------------- beschäftigt>-----------Mitarbeiter-------- <arbeitet für ---------------- name name anschrift anschrift Kardinalitäten und Multiplizitäten1:1 11:n(n>=1) 1..*1:n(n>=0) 0..*/*optional 0..1feste c (3/5/10)Intervall 5..15Ordnungs- {ordered}beziehungAggregationsbeziehung: 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.Beispiel: 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.Beispiel: Haus ◆── Raum

Spezifikation von AttributenAttributnameAttributtyp(opt.):String,boolean,DateTypkonformer Initialwert(opt.)Kunde -----------------Anrede: AnredetypVorname: String[30]Nachname:String[30]Adresse:String[200]Alter:IntegerDarstellung von OperationenOperationsnameSignatur(opt.)zusätzliche Eigenschaften(opt.)Sichtbarkeit von Operationen• + public • - private • # protected • ~packageBeispiel[+|-|#] Name(Parameterliste) [: Rückgabetyp]+ addiere(a: int, b: int): int- speichereDaten(daten: String)[Visibility] → + (public), - (private), # (protected)Op_Name → Name der MethodeParameter_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)

ObjekteObjektbezeichnung: Objektname : Klassenname (Unterstrichen)Optional: Objektname oder Klassenname kann entfallenAttribute: Mit konkreten Werten möglicheinKunde : KundeAnrede=HerrVorname:"Hans"Adresse="Musterstr. 1 97212 Deutschland"

Rollenbeschreiben ,welche Funktion ein Objekt ein einer Verknüpfung innehatzu jeder an einer Assoziation beteiligten Klasse kann eine Rolle definiert werdenDer Gebrauch von Rollen ist optionalMeist ergibt sich die Rolle bereits aus dem Namen der KlasseRollen 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"

Aspekte der Verhaltensmodellierung lassen sich grob drei verschiedenen Sichten zuordnen.Externe Verhaltenssichtbeschreibt:Die Anwendungssituationen, in denen das System zum Einsatz kommt.Das extern sichtbare Verhalten des Systems in verschiedenen Anwendungssituationen-->externe Szenarien.Interne Verhaltenssichtbeschreibt:die dynamische Interaktion, Kommunikation und Synchronisation der Objekte, durch die das externe Verhalten intern realisiert wird-->interne Szenarien.Objektsichtbeschreibt: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.

Software Testing & Bugs ✅ Begriff "Bug":Thomas Edison nutzte den Begriff bereits 1878 für Fehler in technischen Geräten.✅ Auswirkungen von Software-Bugs:NASA (1979-1985): Ozonloch nicht erkannt.Ariane 5 (1996): Selbstzerstörung.F-18 Bug: Unkontrollierte Rotation durch Software-Reuse.Therac-25: Strahlenunfälle durch Softwarefehler.✅ Fehlertypen:Defect: Funktion erfüllt nicht die Anforderungen.Failure: Beobachtete Abweichung vom erwarteten Ergebnis.Fault: Fehlerhafter Prozess führt zu unerwartetem Verhalten.Bug: Fehler im Code, der sich manifestiert.Error: Ursache des Fehlers (z. B. Tippfehler).✅ Testing – Ziele: 1️⃣ Bugs finden 2️⃣ Qualität prüfen 3️⃣ Vertrauen erhöhen✅ Testing – Definition:Überprüfung, ob Software die spezifizierten Anforderungen erfüllt.✅ Validation vs. Verification:Validation: "Machen wir das Richtige?" (Stakeholder-Bedürfnisse).Verification: "Machen wir es richtig?" (Spezifikationsprüfung).✅ Qualitätskriterien & Tests:Funktionalität → FunktionstestsZuverlässigkeit → Robustheits- & ProvidertestsInteraktion → Usability & Accessibility-TestsPerformance → EffizienztestsSicherheit → Security & Penetration TestsFlexibilität → Rollout-Tests✅ Testing vs. Qualität:Testing misst & verbessert Qualität indirekt.✅ 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. 🚀

Testprozess ✅ Testplanung & Steuerung:Strategie, Ressourcen & Prioritäten festlegen.Testzeitplan & Controlling (Messen, Dokumentation, Updates).✅ Testanalyse & Design:Testbedingungen aus Anforderungen ableiten.Testfälle spezifizieren (logische vs. konkrete Testfälle).✅ Testimplementierung & Ausführung:Testfälle priorisieren, Daten erstellen & Automatisierung vorbereiten.Hauptfunktionen testen, Ergebnisse dokumentieren & Fehler nach Bugfixing erneut testen.✅ Test Oracle (Erwartete vs. Tatsächliche Ergebnisse):Quellen: Benutzerhandbuch, Vorgängerversionen, ähnliche Software.✅ Testauswertung & Abschluss:Ergebnisse analysieren, Codeabdeckung prüfen & Testbericht erstellen.Testtools & Infrastruktur dokumentieren und archivieren.Lessons Learned erfassen & Testprozess optimieren. 🚀

Psychology of Testing ✅ Grundsatz:Entwicklung ist konstruktiv (positiv), Testing dagegen destruktiv (negativ).✅ Können Entwickler ihre eigenen Programme testen?Pro: Sie kennen das System gut.Contra: Blind für eigene Fehler.✅ Unabhängiges Testing-Team:Pro: Unvoreingenommen & erfahren im Testen.Contra: Muss sich erst in das System einarbeiten.✅ Fehlermeldung & Kommunikation:Bugs müssen klar & nachvollziehbar an Entwickler und Management gemeldet werden.Kritik an der Arbeit anderer ist sensibel, daher klare, wiederholbare Berichterstattung. 🚀

Teststufen & Testarten✅ 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):Bug Testing: Wiederholung fehlgeschlagener Tests.Change Testing: Test geänderter Softwarebereiche.New Testing: Prüfung neuer Funktionen.Complete Regression Testing: Komplette Software erneut testen.✅ Testkategorien:Funktionales Testing: Überprüfung der Systemfunktionen.Nicht-funktionales Testing: Performance, Sicherheit, Usability.Strukturorientiertes Testing: Code- und Architekturtests.Änderungsorientiertes Testing: Regressionstests.✅ Statisches vs. Dynamisches Testing:Dynamisch: Test während der Ausführung des Codes.Statisch: Code wird ohne Ausführung geprüft (Dokumentenprüfung, Code-Reviews). 🚀

Review-Typen & Prozess ✅ 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:Frühe Fehlererkennung → kürzere Entwicklungszeiten.Wissensaustausch & Qualitätsverantwortung im Team.Reduziert Aufwand für spätere Tests.✅ Probleme bei Reviews:Fehlendes Personal, Zeit oder Management-Support.Mangelnde Vorbereitung & unklare Ziele. 🚧

Dynamisches Testing ✅ Testmethoden: 1️⃣ Blackbox Testing: Testet das System ohne Kenntnis des Codes (eingabe- & ausgabebasiert).Spezifikationsbasiert (Anforderungen als Grundlage). 2️⃣ Whitebox Testing: Testet mit Code-Kenntnis, misst Code-Abdeckung.Struktur- & datenflussbasiert. 3️⃣ Experience-based Testing: Setzt auf Wissen & Erfahrungen von Testern, Entwicklern & Nutzern.✅ Begriffe:Test Basis: Dokumente zur Ableitung von Testfällen.Test Condition: Ereignisse oder Einheiten, die geprüft werden können.Test Suite: Sammlung von Testfällen, deren Abfolge definiert ist.Stub/Dummy/Mock: Simulation nicht implementierter Komponenten während des Tests.✅ Ziel dynamischer Tests:Nachweis, dass Anforderungen erfüllt werden können.Fehlersuche & Überprüfung der Funktionalität mit geringerem Aufwand als manuelle Prüfungen.🚀 Herausforderung:Testobjekte müssen oft in eine Testumgebung integriert werden, da einzelne Module nicht eigenständig ausführbar sind.

Test Coverage MethodenTestkriterien vs. TestabdeckungTestkriterien: Definiert, welche Einheiten getestet werden müssen. Entweder erfüllt oder nicht.Testabdeckung: Misst, wie viel Code durch Tests abgedeckt wurde (in %).Statement CoverageTestfälle so wählen, dass jede Anweisung mindestens einmal ausgeführt wird.Formel: C0=Anzahl abgedeckter StatementsGesamtanzahl StatementsC_0 = \frac{\text{Anzahl abgedeckter Statements}}{\text{Gesamtanzahl Statements}}.Vorteile: Findet toten Code, einfache Implementierung.Nachteile: Schwache Methode, findet nicht alle Fehler.Branch CoverageTestfälle so wählen, dass alle Verzweigungen (if/else, loops) mindestens einmal durchlaufen werden.Formel: C1=Anzahl abgedeckter VerzweigungenGesamtanzahl VerzweigungenC_1 = \frac{\text{Anzahl abgedeckter Verzweigungen}}{\text{Gesamtanzahl Verzweigungen}}.Vorteile: Findet ungenutzte Codepfade, erkennt bedingte Fehler.Nachteile: Komplexe Bedingungen nicht vollständig getestet.Path CoverageTestfälle so wählen, dass jeder Pfad im Kontrollfluss mindestens einmal getestet wird.Formel: C∞=Anzahl abgedeckter PfadeGesamtanzahl PfadeC_\infty = \frac{\text{Anzahl abgedeckter Pfade}}{\text{Gesamtanzahl Pfade}}.Vorteile: Sehr gründlich, testet alle möglichen Abläufe.Nachteile: Unendlich viele mögliche Pfade in Schleifen.Boundary Interior TestingTestfälle müssen:Ohne Schleifen durchlaufen.Genau einmal die Schleife durchlaufen (Boundary-Test).Mindestens zweimal die Schleife durchlaufen (Interior-Test).Vorteile: Effektive Fehlererkennung an kritischen Punkten.Nachteile: Erfordert Kreativität zur Identifikation aller Grenzen.Beispiel-Testfälle für Statement & Branch CoverageStatement Coverage: Wie viele Testfälle sind nötig, um 100% Statement Coverage zu erreichen?Branch Coverage: Welche Eingaben sind nötig, um 100% Branch Coverage zu erreichen?Diese Methoden helfen dabei, eine möglichst hohe Code-Abdeckung zu erreichen und Fehler frühzeitig zu erkennen.

Control Flow GraphsDarstellung des Programmablaufs als Knoten (Befehlssequenzen) und Kanten (Übergänge).Pfade definieren mögliche Abläufe im Code.Ein Pfad ist ausführbar (feasible), wenn es Eingaben gibt, die ihn durchlaufen können.Anomalien im Kontroll- und DatenflussControl Flow Anomalien: Toter Code, Endlosschleifen, Sprünge aus/in Schleifen, Mehrfachausstiege.Data Flow Anomalien: Lesen undefinierter Werte, überschreiben ungenutzter Werte, mehrfaches Schreiben ohne Nutzung.McCabe’s Cyclomatic ComplexityMisst die Anzahl unabhängiger Pfade im Kontrollflussgraphen.Formel: v(G) = e − v + 2 (Kanten - Knoten + 2).Hohe Werte deuten auf komplexen, schwer testbaren Code hin.Diese Konzepte helfen, die Testbarkeit und Qualität von Code zu bewerten und zu verbessern. 🚀

Mutation Testing AnsatzMutanten erzeugen: Leichte Modifikationen am Originalprogramm.Testfälle ausführen:Ein Mutant wird "getötet", wenn ein Testfall fehlschlägt.Überlebt ein Mutant, sind neue Testfälle nötig.Arten des Mutation TestingsStark: Mutant muss ein anderes Ergebnis liefern als das Original.Schwach: Mutant wird bereits getötet, wenn ein Testfall fehlschlägt.Interpretation der TestergebnisseAlle Mutanten getötet → Gute Testfälle.Wenige überlebt → Zusätzliche Testfälle erforderlich.Viele überlebt → Testfälle schlecht, Neuentwicklung nötig.Achtung: Manche Mutanten sind äquivalent, erkennen und vermeiden!MutationsoperatorenOperanten ändern: Konstante/Variable ersetzen, Initialisierungen entfernen.Operatoren ändern: Mathematische, logische oder relationale Operatoren ersetzen.Statements modifizieren: Statement-Löschung, Switch-Case-Tausch, Codeblöcke verschieben.Zugriffsrechte ändern: private → public etc.Vererbung manipulieren: Methoden überschreiben, Schlüsselwörter (super) entfernen.Mutation Testing hilft, Testfälle zu verbessern, indem es überprüft, ob sie Code-Modifikationen erkennen.Mocks & Mockito Was ist ein Mock?Ziel: Unit-Tests sollen Methoden einer Klasse isoliert testen.Problem: Methoden nutzen oft andere Klassen oder externe Services, die schwer testbar sind.Lösung: Mocks ersetzen echte Abhängigkeiten, um Einflüsse von außen zu vermeiden.Mockito SyntaxMock erstellen & Verhalten definieren:when(itemRepository.findById("it1")).thenReturn(mockedItem); Überprüfen, ob eine Methode aufgerufen wurde:verify(itemRepository, times(1)).findById("it1"); PowerMock – Mocking für schwierige FälleErmöglicht:Mocking von statischen Methoden.Mocking von privaten Methoden & Konstruktoren.Manipuliert Bytecode und nutzt eigenen JUnit-Runner.Mocking hilft, Klassen isoliert zu testen, Fehlerquellen zu minimieren und stabile Unit-Tests zu schreiben.

Äquivalenzklassenbildung (Equivalence Partitioning)Ä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.Vorgehen:Domänen definieren: Mögliche Eingabe- und Ausgabewerte bestimmen.Partitionierung nach Regeln:Intervalle: 1 gültige, 2 ungültige Partitionen.Wertemenge: 1 Partition pro Wert, 1 ungültige Partition.Situationen: 1 gültige, 1 ungültige Partition.Weitere Aufspaltung bei ungleichen Behandlungen innerhalb einer Partition.Beispiele:Intervall: Gültiger Bereich 1 ≤ x ≤ 100 → Ungültig: x < 1, x > 100.Werte: Erlaubte Sportarten: Fußball, Basketball, Hockey → Ungültig: andere Sportarten.Situation: Club-ID beginnt mit Buchstabe → Ungültig: ID beginnt nicht mit Buchstabe.Optimierung:Minimierung der Testfälle: Mindestens 1 Testfall pro Partition.Gültige Partitionen kombinieren, ungültige nie zusammen testen (Vermeidung von Bug Masking).Vor- und Nachteile:✅ Reduziert Testfälle, effizient für viele Eingaben. ❌ Berücksichtigt schwer Interdependenzen, sollte mit Grenzwertanalyse kombiniert werden.

Boundary 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:Grenzwert selbst, ein Wert darunter und ein Wert darüber.Unterste und oberste gültige Werte eines Intervalls.Vor- & Nachteile: ✅ Häufige Fehlerquelle → Hohe Fehlererkennung. ✅ Effiziente Kombination mit anderen Methoden. ❌ Komplexe Identifikation aller Grenzen. ❌ Erfordert kreative Testfälle.

Usability & User ExperienceUsabilityBeschreibt, wie effektiv, effizient und zufriedenstellend ein Produkt von bestimmten Nutzern in einem bestimmten Kontext verwendet werden kann.User Experience (UX)Umfasst alle Emotionen, Wahrnehmungen und Reaktionen eines Nutzers vor, während und nach der Nutzung eines Produkts.Positive Emotionen & AuswirkungenGlücksgefühle (Dopamin, Endorphine) → Besseres Denken, Lernen, KreativitätWiederholungseffekt → Bevorzugte NutzungHöhere Motivation → Kleine Mängel werden verziehenBegeisterung → Weiterempfehlung & MarkenvertrauenNegative Emotionen & AuswirkungenStressreaktion → Höherer Herzschlag, aber mehr FehlerGehemmte Großhirnaktivität → Eingeschränkte Kreativität, höhere FehlerquoteProduktvermeidung → Um Stress zu vermeidenAllgemeinNutzererwartungen treffen auf Produkteigenschaften.Erwartungen übertroffen → Positives ErlebnisErwartungen nicht erfüllt → Negatives ErlebnisErwartungen sind unbewusst, vielschichtig und verändern sich mit der Zeit.

Kano-Modell Basismerkmale (rote Kurve): Werden erwartet, Fehlen führt zu Unzufriedenheit, Erfüllung nur zu neutraler Zufriedenheit.Leistungsmerkmale (blaue Kurve): Je besser umgesetzt, desto höher die Kundenzufriedenheit.Begeisterungsmerkmale (schwarze Kurve): Unerwartete Extras, die positiv überraschen.🔹 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.

Requirements Engineering✅ Ziel: Anforderungen systematisch spezifizieren & verwalten, Stakeholder-Konsens erreichen, Fehlentwicklungen vermeiden.Kernaktivitäten:Ermitteln – Anforderungen sammeln & konsolidieren.Dokumentieren – Anforderungen strukturiert erfassen.Validieren & Verhandeln – Anforderungen prüfen & abstimmen.Verwalten – Anforderungen & Artefakte organisieren.Arten von Anforderungen:Funktionale Anforderung: „Benutzer kann sich mit Name & Passwort anmelden.“Nicht-funktionale Anforderung: „Antwortzeit max. 2 Sekunden.“Randbedingung: „System läuft auf Linux-Server.“Software-Lebenszyklus:RE → Design → Implementierung → Integration → Einführung → Wartung⚠ Fehlerquellen in Projekten:Häufige Änderungen, schlechtes Change ManagementUnklare oder missverstandene AnforderungenFehlende Stakeholder-Einbindung & unrealistische PlanungKommunikationsprobleme & mangelndes Testing📌 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:Systemkomplexität, unausgesprochene AnnahmenDisziplinierte Anforderungsverwaltung trotz ÄnderungenFehlende Abstimmung, Testbezug & Zeitdruck

Anforderungsermittlung mit Fragebögen✅ Vorteile:Große Teilnehmerzahl möglich.Schnell & kostengünstig.Ermöglicht Bewertung vorformulierter Antworten für Stakeholder mit wenig Ausdrucksfähigkeit.❌ Nachteile:Nur bereits bekannte oder vermutete Infos können abgefragt werden.Erstellung ist aufwendig und erfordert Fachwissen & Psychologiekenntnisse.Keine direkte Rückkopplung → Probleme erst bei Auswertung erkennbar.

Fokusgruppe ✅ Eigenschaften:Spezielle Workshop-Form mit 6-8 Teilnehmern.Gute Moderation & Visualisierung entscheidend.✅ Vorteile (vs. Einzelinterviews):Vielfältige Perspektiven, direkte Konfliktlösung.❌ Nachteile:Hoher Zeitaufwand, erfordert gute Moderation & Umgang mit Gruppendynamik.Arbeitsschritte einer Fokusgruppe:1. Vorbereitung:Ziele, Fokus, Teilnehmer & Fragen festlegen.Material & Moderationstechniken vorbereiten.2. Beginn:Angenehme Atmosphäre schaffen, Vertraulichkeit zusichern.Vorstellungsrunde & Klärung von Fragen.3. Durchführung:Diskussion anhand Leitfragen, Ergebnisse visualisieren.4. Ende:Ergebnisse zusammenfassen & priorisieren.Feedback einholen, weitere Schritte erklären.5. Nachbereitung:Ergebnisse aufbereiten, Review mit Teilnehmern.Best Practices:Fokussiert & kurz (max. 3h) halten.Interaktive Gruppenarbeit, klare Anweisungen.Visuelle & haptische Methoden nutzen (Karten, Zeichnungen).Teilnehmer aktiv einbinden, Dominanz einzelner vermeiden.

Arten von Interviews:Offenes Interview: Freie Antworten, subjektive Eindrücke, schwer auszuwerten, interviewerabhängig.Halbstandardisiertes Interview: Leitfaden-basiert, flexibel anpassbar.Standardisiertes Interview: Hohe Objektivität, quantifizierbar, wenig Spielraum für Antworten. ✅Vorteile & Nachteile von Interviews✅ Vorteile:Fragen können sofort geklärt werden.Erfahrene Interviewer passen den Verlauf individuell an.Gezieltes Nachfragen fördert vollständige Antworten.❌ Nachteile:Hoher Zeitaufwand.Erfordert gute Interview-Skills.Grundlagen der Interviewführung 1. Bedeutung der InterviewführungInterviewführung ist ein Handwerk, das spezielle Fähigkeiten erfordert.Erfolgreiche Interviews setzen Fragetechniken, psychologische Effekte und Projektkenntnis voraus.Der Interviewer muss sich gleichzeitig auf viele Aspekte konzentrieren.2. Arbeitsschritte eines Interviews✅ Vorbereitung:Ziele und Fokus klären, vorhandene Dokumente prüfen.Stakeholder auswählen, Interviewart bestimmen (offen, halbstandardisiert, standardisiert).Fragen ausarbeiten, Termin vereinbaren, Material (z. B. Aufnahmegerät) vorbereiten.Protokollant ggf. einbinden.✅ Gesprächsbeginn:Angenehme Atmosphäre schaffen.Befragte Person über Ablauf, Vertraulichkeit und Zweck informieren.Vorabfragen klären.✅ Durchführung:Interview anhand der Leitfragen durchführen und aufzeichnen.✅ Gesprächsende:Aufzeichnung stoppen, informelles Gespräch führen.Weitere Schritte erklären, befragter Person das letzte Wort geben.✅ Nachbereitung:Antworten ausarbeiten, Befragten zur Überprüfung vorlegen.3. Fragetechniken für erfolgreiche InterviewsVon allgemeinen zu spezifischen Fragen übergehen.Offene und geschlossene Fragen kombinieren, Suggestivfragen vermeiden.Keine komplizierten, verschachtelten oder missverständlichen Fragen stellen.Fachjargon vermeiden, Befragte zur eigenen Wortwahl ermutigen.Noch offene Themen am Schluss ansprechen.4. Aktives Zuhören und GesprächsführungInteresse und Aufmerksamkeit zeigen, Paraphrasieren statt direkte Fragen stellen.Denkpausen akzeptieren, nicht vorschnell unterbrechen.Nonverbale Signale beachten, ins Wort fallen nur bei Redeschwall oder Abschweifung.Eigene Meinung zurückhalten, aber bei Anforderungen gezielt nachfragen (Sokratischer Dialog).🔹 Ziel: Klare, strukturierte Interviews, die relevante Informationen liefern und Missverständnisse vermeiden. ✅

Feldbeobachtung ✅ Beschreibung:Stakeholder in ihrer Arbeitsumgebung direkt (durch Requirements Engineers) oder indirekt (Video) beobachten.Erfasst implizites Wissen, unbewusste Handlungen & schwer erklärbare Prozesse.✅ Vorteile:Ermöglicht tiefes Verständnis der Anwendungsdomäne.Hilfreich bei schwer erreichbaren Stakeholdern.❌ Nachteile:Hoher Aufwand, Fokus nur auf Ist-Zustand.Sonderfälle können über- oder unterschätzt werden.Stakeholder könnten sich beobachtet fühlen.

Contextual Inquiry ✅ Beschreibung:Kombination aus Beobachtung & Interview, um Nachteile beider Methoden auszugleichen.Stakeholder werden während der Arbeit beobachtet, unbewusste Schritte erfasst.Gezieltes Nachfragen möglich, um kognitive Prozesse zu verstehen.✅ Best Practices:Stakeholder sollen laut denken.Angenehmere Atmosphäre als reine Videoaufzeichnung oder passive Beobachtung.

Apprenticing✅ Beschreibung:Requirements Engineer übernimmt Aufgaben des Stakeholders im realen Arbeitsumfeld.✅ Vorteile (zusätzlich zur Feldbeobachtung):Tieferes Domänenverständnis durch aktive Mitarbeit & viele Rückfragen.Stakeholder fühlt sich weniger beobachtet.❌ Nachteile (zusätzlich zur Feldbeobachtung):Noch zeitaufwändiger.Nicht geeignet für sicherheitskritische Systeme.

Dokumentanalyse & Systemarchäologie ✅ Dokumentanalyse:Aufgabenabläufe aus bestehenden Dokumenten (z. B. Handbücher, Tutorials) ermitteln.Hilft, Interviews gezielter vorzubereiten.Nützlichkeit hängt von der Dokumentationsqualität ab.✅ Systemarchäologie:Analyse alter Systeme oder Konkurrenzprodukte (Code, Doku, Nutzung).Verhindert das Vergessen essentieller Funktionen & bietet Inspiration.❌ Nachteile:Aufwändig & wenig sinnvoll bei schnelllebigen Systemen.Keine neuen Anforderungen, abhängig von Dokumentationsqualität.

TORE Entscheidungs-Rahmenwerk Das TORE (Task-Oriented Requirements Engineering) Entscheidungs-Rahmenwerk strukturiert anforderungsrelevante Entscheidungen auf vier Ebenen:Projekt-Ebene – Projektteam, Stakeholder, Ziele, unterstützte ProzesseFach-Ebene – Ist-/Soll-Situation, Verantwortlichkeiten, GeschäftsregelnInteraktions-Ebene – Interaktionen, Systemfunktionen, UI-StrukturSystem-Ebene – GUI, Architektur, interne Funktionen & DatenKernpunkte des TORE-Ansatzes:✅ 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. ✅

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.StakeholderStakeholderbeschreibung 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 HilfsmittelZwiebelschalen-Modell 🔹 Schicht 1: Enge Beteiligung (Projektleiter, Entwickler) 🔹 Schicht 2: Betroffene durch Änderungen (Endnutzer) 🔹 Schicht 3: Externe Einflussnehmer (Sponsoren, Behörden, Politik)Stakeholder-MatrixStakeholder 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.Zielerhebung ✅ Ermittlung der gewünschten Zielzustände der Stakeholder🔹 Top-Down-Analyse:Hauptziel festlegen, dann in Subziele/Nicht-Ziele mittels Und/Oder-Bäumen verfeinern.🔹 Bottom-Up-Analyse:Individuelle Ziele sammeln (z. B. Kartenabfrage).Konsolidierung & Organisation der Ziele im Plenum.ZielbeschreibungstabelleFeld 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) ProzessbeschreibungstabelleFeld 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)

Zielsetzung „User Research“ ✅ Nutzer verstehen: Ziele, Bedürfnisse, Eigenschaften ✅ Psychologische Aspekte: Motivation, Einstellung, Erfahrung ✅ Fachliche Faktoren: Wissen, Beruf, Software-Erfahrung ✅ Physische Merkmale: Alter, Geschlecht, EinschränkungenPersona ✅ Fiktiver Stereotyp, basierend auf User Research ✅ Erleichtert Nutzerverständnis & Produktanforderungen ✅ Inhalte: Name, Demographie, Rolle, Zitat, Bild ✅ Fokus: Ziele, Aufgaben, Nutzungskontext, HerausforderungenAllgemeines Vorgehen zur Erstellung einer PersonaProto 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.

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.Erstellung einer Empathy Map ✅ Workshop (~20 Min.) mit Team, das die Zielgruppe kennt. ✅ Fokus festlegen:Welche Personen? (z. B. Erstnutzer)Allgemein oder situationsbezogen? (z. B. am Arbeitsplatz)Mit oder ohne spezifisches Thema? (z. B. Reisebuchung) ✅ Leere Empathy Map auf Whiteboard/Flipchart skizzieren, Person in die Mitte eintragen. ✅ Team diskutiert & füllt die Map aus Nutzersicht aus.

Customer Journey✅ Gesamter Nutzerprozess: Von Erstkontakt bis nach dem Kauf. ✅ Bestandteile:PersonasTouchpoints & ChannelsEmotionen, Infos & Probleme an Touchpoints ✅ Ziel: Schwachstellen analysieren & Marketingstrategien optimieren.

Sales Funnel Modell 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.

Fachebene🔹 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:Wie sehen aktuelle Prozesse aus?Wie sollen sie in Zukunft gestaltet werden?Welche Prozesse können automatisiert werden?Welche Daten & Regeln sind relevant?IST-Analyse – Aufgabenanalyse 🔹 Fokus auf Aufgaben statt Features – Analyse der IST-Situation aus Nutzersicht. 🔹 Ziel: Probleme & Verbesserungspotenziale erkennen, Anforderungen ableiten, Nutzertests vorbereiten.✅ Kernfragen zur Aufgabenanalyse:Welche Ziele haben Nutzer bei der Aufgabendurchführung?Welche Schritte & Strategien nutzen sie?Was denken/erleben sie dabei?Welche Probleme treten auf & wie werden sie gelöst?Welches Vorwissen & Regeln sind erforderlich?Sequence Models Contextual DesignEin 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.Beispiel: Online-Flugbuchung1️⃣ 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.Ereignisgesteuerte Prozesskette (EPK) Grafische Methode zur Modellierung von Geschäftsprozessen. 🔹 Elemente:Ereignisse: Start-/Endpunkte (z. B. Bestell-Email eingegangen).Funktionen: Aktivitäten (z. B. Email bearbeiten).Organisationseinheiten: Beteiligte (z. B. Sachbearbeiter, Systeme). 🔹 Zweck: Klare Visualisierung, Analyse & Optimierung von Prozessen. Aufgaben- & Kontextanalyse✅ Aufgaben verstehen:Ziele & Intentionen der Nutzer erfassen.Schritte, Denkweise & Erlebnisse während der Aufgabe analysieren.Probleme & Lösungen identifizieren.Vorwissen & Regeln berücksichtigen.✅ Kontext verstehen:Ort & Umgebung: Raumgröße, Einrichtung, Licht, Lärm, Ablenkungen.Wege & Distanzen: Notwendige Bewegungen für Aufgaben.Regularien & Personen: Sicherheitsvorkehrungen, Interaktionen.✅ Ressourcen & Hilfsmittel:Genutzte Objekte & Werkzeuge (z. B. PC, Drucker, Notizen).Standort & Erreichbarkeit der Ressourcen.Besondere Eigenschaften von Hilfsmitteln, die Aufgaben beeinflussen.Definition der Soll-Situation ✅ Optimierung der Ist-Situation unter Beibehaltung von Stärken:Unnötige Schritte entfernenAutomatisierung & ParallelisierungProzessschritte kombinierenKreative Lösungen für verbleibende Schwächen✅ Detaillierung der Soll-Situation mit Modellierungstechniken:BPMN, EPK usw. zur Prozessdarstellung.

KONTEXTANALYSE...wie können die Ergebnisse dokumentiert werden?✅ Physical Models:Grafische Dokumentation der Umgebung (Ort, Bewegungsprofile, Geräte, Hindernisse).✅ Artifact Models:Detaillierte Infos zu physischen/elektronischen Objekten (Name, Aufbau, Nutzung, Probleme).✅ Flow Models:Kommunikations- & Koordinationsflüsse zwischen Personen/Gruppen (Rollen, Verantwortlichkeiten, Hindernisse).

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ätKopieren Transformieren KombinierenKreativitätsprozess✅ 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. Grundlegende Kreativitätstechniken✅ Ideengenerierung:Brainstorming: Freies Sammeln von Ideen.Mind Mapping: Visuelle Verknüpfung von Ideen.SCAMPER: Ideen durch Veränderung weiterentwickeln.✅ Ideenbewertung & Auswahl:Morphologischer Kasten: Systematische Variationen testen.Punktbewertung: Ideen anhand von Kriterien bewerten.✅ Assoziative Techniken:Reizwortanalyse: Zufällige Begriffe als Inspiration nutzen.Analogietechnik: Lösungen aus anderen Bereichen übertragen.6-3-5 Brainwriting 🔹 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. Lotus Blossom✅ 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.Remember the Future ✅ 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. Morphological Forced Connections ✅ 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:Systematisch: Multifaktorenmethode → reduzierte Auswahl.Intuitiv: Frei gewählte Kombinationen als alternative Lösungen betrachten. 4️⃣ Mehrere Kombinationen testen, um neue Features/Dienstleistungen zu entwickeln. Product Box ✅ 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. Buy a Feature ✅ 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. Six Thinking Hats ✅ Gruppendiskussion mit 6 Denkweisen (Hüte):⚪ Weiß: Analytisch – Fakten & Daten sammeln.🔴 Rot: Emotional – Bauchgefühl & Meinungen äußern.⚫ Schwarz: Kritisch – Risiken & Probleme hinterfragen.🟡 Gelb: Optimistisch – Chancen & Best-Case-Szenarien betrachten.🟢 Grün: Kreativ – Neue Ideen & Innovationen entwickeln.🔵 Blau: Moderierend – Prozess steuern & zusammenfassen.✅ Ziel: Verschiedene Perspektiven einnehmen, um fundierte Entscheidungen zu treffen.

Systemverantwortlichkeiten✅ Aktivitätsklassifikation in der Soll-Situation:Systemunterstützte Aktivitäten: Nutzer & System arbeiten zusammen.Systemautomatisierte Aktivitäten: Nur das System führt sie aus.Manuelle Aktivitäten: Ausschließlich vom Nutzer durchgeführt. Beschreibung von Systemunterstützten Aktivitäten mit User StoriesALS <<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 Identifikation von Geschäftsdaten ✅ Schritte: 1️⃣ Begriffe aus Geschäftsprozessen ableiten. 2️⃣ Daten mit Stakeholdern verfeinern (Attribute klären). 3️⃣ Konzeptionelle Zusammenhänge & Kardinalitäten modellieren. Identifikation von Geschäftsregeln✅ Regeln aus Daten, Prozessen & Funktionen ableiten:Fakten: PLZ hat 5 Stellen.Restriktionen: Antragsteller ≠ Genehmiger.Bedingte Fakten: Reise vor heute → ungültig.Bedingte Aktionen: Betrag >1000€ → Genehmigung nötig.Bedingte Berechnungen: Betrag >1000€ → 10% Rabatt.

Entscheidungen der Interaktionsebene ✅ 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? Anwendungsfall: [Name des Anwendungsfalls]ID: UC_1-25Name: [Eindeutiger Name des Anwendungsfalls]Zielsetzung: [Sinn und Zweck des Anwendungsfalls]Aktor: [Rolle oder externes System, das den Anwendungsfall durchführt]Vorbedingungen & eingehende Daten: [Bedingungen im System, benötigte Eingangsdaten/Dokumente]Ablauf:Der Benutzer…Das System…Alternative Abläufe: [Abweichungen vom Hauptablauf für den Erfolgsfall]Ausnahmefälle: [Verhalten bei Fehlern oder unerwarteten Situationen](Geschäfts-) Regeln: [Regeln, die während der Ausführung gelten müssen]Qualitätsanforderungen / NFRs: [Qualitätsanforderungen für den Ablauf oder einzelne Schritte]Fachdaten und Dokumente: [Benötigte Daten und Dokumente]Systemfunktionen: [Vom System ausgeführte Funktionen]Nachbedingungen & ausgehende Daten: [Zustand des Systems nach erfolgreicher Ausführung]Definition der Systemfunktionen ✅ Systemfunktionen umfassen:Systemautomatisierte Aktivitäten in Geschäftsprozessen.Systemschritte in Use Cases.🔹 Falls nötig, können sie mit UML oder Rupp’s Satzschablone detailliert werden. Festlegung von Interaktionsdaten ✅ Ableitung aus Use Cases:Welche Daten werden eingegeben/ausgegeben?Welche Listen/Sammlungen sind erforderlich?In welchem Format sollen die Daten vorliegen?📌 Dokumentation: Als Erweiterung der Use Cases oder Datenmodelle.Festlegung der UI-Struktur ✅ Leitfrage: Welche Daten & Funktionen gehören zusammen? ✅ Ableitung aus Use Cases. ✅ Visualisierung: Logische Bereiche oder Papierprototypen.

Interaction Design (IxD) ✅ 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:Definition von Aufgaben & Abläufen zwischen Nutzer und System.Identifikation von Varianten, Folgeaufgaben & alternativen Wegen. 2️⃣ Inhalt:Welche Informationen benötigt der Nutzer, um mit dem System zu interagieren?Definition von Aktionen & Reaktionen im Dialog zwischen Nutzer & System. 3️⃣ Darstellung:Organisation & Visualisierung von Informationen in der UI.Aussehen & Position der UI-Elemente festlegen.Beispiel: Park Distance Control (PDC) 🚗📌 Interaktionsfluss:Der Nutzer fährt rückwärts → System überprüft Abstand zum Hindernis.System informiert visuell & akustisch über die Distanz.Nutzer reguliert Geschwindigkeit basierend auf den Signalen.📌 Inhalt:Abstandswerte zum Hindernis (2m bis <0,5m).📌 Darstellung:Akustisches Feedback: Schnellere Pieptöne bei geringerer Distanz.Visuelles Feedback:Grün (2m - 1,1m) → Sicherer Abstand.Gelb (1m - 0,51m) → Vorsicht.Rot (<0,5m) → Stoppen!✅ Fazit: Durch Interaktionsfluss, Inhalte & Darstellung wird eine intuitive und effektive Nutzerführung sichergestellt.

Mentales Modell ✅ Definition: Ein mentales Modell beschreibt, wie eine Person denkt, dass etwas funktioniert.✅ Merkmale:Basierend auf Erfahrungen, Wahrnehmungen & unvollständigen Fakten.Beeinflusst Entscheidungen, Verhalten & Problemlösungen.Bestimmt, worauf Menschen in komplexen Situationen achten. Mentale Modelle im Interaktionsdesign✅ Eigenschaften:Nicht statisch, verändern sich durch Erfahrungen & Gespräche.Werden durch ähnliche Systeme & Interaktionen beeinflusst.Neue Konzepte können störend wirken, selbst wenn sie besser sind.✅ Relevanz für Interaktionsdesign:Nutzer handeln nach ihren mentalen Annahmen über das System.Die UI muss das System so kommunizieren, dass es zu diesen Modellen passt.Problem:🔹 Designer vs. Nutzer:Designer haben tiefes Systemwissen, Nutzer jedoch nicht → mentale Diskrepanz.Lösung:1️⃣ Produkt an mentale Modelle der Nutzer anpassen. 2️⃣ Nutzer durch Training & bessere Erklärungen unterstützen. 3️⃣ Eindeutige Bezeichnungen & transparente UI gestalten.✅ Voraussetzung:Ähnliche mentale Modelle der Nutzer erkennen & nutzen.UI-Optimierung nach Nutzerverhalten → Infos dort platzieren, wo sie gesucht werden.✅ Methoden zur Anpassung:Card Sorting, Storyboards, Thinking Aloud.

Card Sorting ✅ Idee:Nutzer ordnen Karten mit Menüpunkten/Inhalten in sinnvolle Kategorien.Hilft, eine intuitive Informationsarchitektur zu erstellen (z. B. mit Mind Maps oder Baumdiagrammen).✅ 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.

7 Stages of Action (Donald Norman) 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. Folgerungen fürs Interaktionsdesign ✅ Goal:Software muss den Nutzer klar zum Ziel führen.Transformation von Zielen in Handlungsabsichten sollte intuitiv sein (z. B. durch gute Anleitungen).✅ Execution:Erkennbare Handlungsschritte & Aktionen in jeder Situation.Buttons & Menüs verständlich anordnen, um Planung zu erleichtern.Softwarekonzepte auf Aufgaben ausrichten, nicht auf Implementierung.Aktionen dürfen den Nutzer nicht vom Ziel ablenken.✅ Evaluation:Systemzustand muss jederzeit erkennbar sein.Reaktionen & Zustände leicht interpretierbar gestalten.Nutzer muss Systemzustand einfach mit seinem Ziel vergleichen können (klare Anzeigen).

Sketching Basics ✅ Zweck:Schnelle Visualisierung & Kommunikation von Ideen in der frühen Entwicklungsphase.Fördert Abstraktion & neue Möglichkeiten.✅ Vorteile:Einfach & ressourcenschonendOffen & anpassbarFlexibel im Detail Konzepte✅ Storyboarding:Visuelle Darstellung einer Nutzerinteraktion mit dem System in mehreren Schritten.Zeigt den Ablauf und mögliche Szenarien durch Skizzen oder Comics.✅ Defining Components:Festlegen der UI-Bausteine (Buttons, Menüs, Eingabefelder).Klärt Funktion & Position der Elemente in der Benutzeroberfläche.✅ Process Visualization:Grafische Darstellung eines Ablaufs oder Prozesses.Zeigt Schritte & Entscheidungen, um Interaktionen verständlich zu machen.✅ Workflow Maps:Übersicht über Aufgaben & Interaktionen innerhalb eines Systems.Hilft, Arbeitsabläufe zu optimieren und Abhängigkeiten zu erkennen.✅ Screen Transition:Wechsel zwischen verschiedenen Bildschirmen/UI-Ansichten.Definiert, wie sich die Oberfläche bei Nutzeraktionen verändert.✅ Screen Transition Storyboard:Erweiterung des Storyboards für UI-Übergänge.Zeigt, wie sich Bildschirme bei Nutzerinteraktionen verändern. Wireframes & Prototypen ✅ Wireframes:Schematischer Entwurf des Frontends – Grundgerüst einer Anwendung.Bindeglied zwischen Interaktionsdesign & visuellem Design.Struktur & Funktionalitäten ohne Designvariablen wie Farben oder Schriftarten.✅ Funktionale Prototypen:Interaktive Simulation bestimmter Funktionen – frühzeitige Bewertung möglich.Nutzer können das Grundgerüst erleben & testen.✅ Horizontale vs. Vertikale Prototypen:Horizontale: UI-Überblick ohne echte Funktionen oder Backend.Vertikale: Vollständig funktionsfähige Untereinheit über alle Architekturschichten.✅ Tools für Prototypen: Axure, Adobe XD, Figma, InVision – Erstellung klickbarer HTML-Prototypen.

✅ ISO 9241-110: Grundsätze der InteraktionsgestaltungAufgabenangemessenheit – Unterstützt effiziente Zielerreichung.Selbstbeschreibungsfähigkeit – Verständliche Bedienung.Erwartungskonformität – Konsistentes Verhalten nach Nutzererwartungen.Erlernbarkeit – Leicht verständlich und anpassbar.Steuerbarkeit – Nutzer kontrolliert das System.Robustheit gegen Fehler – Fehlertoleranz & Unterstützung.Benutzerbindung – Fördert Engagement & Motivation.✅ ISO 9241-112: Grundsätze der InformationsdarstellungEntdeckbarkeit – Wichtige Infos gut sichtbar platzieren.Ablenkungsfreiheit – Unwichtige Infos nicht stören.Unterscheidbarkeit – Klare Trennung von Elementen.Eindeutige Interpretierbarkeit – Infos verständlich präsentieren.Kompaktheit – Nur relevante Infos anzeigen.Konsistenz – Einheitliche Darstellung ähnlicher Elemente. User Interface Design Patterns ✅ Definition:Wiederverwendbare bewährte Lösungen für wiederkehrende Usability-Probleme im UI- & Interaktionsdesign.Ursprung aus der Architekturtheorie von Christopher Alexander (1977).✅ Zweck:Best Practices dokumentieren & Designlösungen standardisieren, um Effizienz & Benutzerfreundlichkeit zu verbessern. User Interface Design Patterns✅ Definition:Ursprünglich aus der Architektur (Christopher Alexander, 1977).Bewährte Lösungen für wiederkehrende Usability-Probleme im UI-/Interaktionsdesign.✅ Beschreibungselemente:Problem: Welches Usability-Problem wird gelöst?Wann: In welchen Kontexten wird es angewendet?Prinzip: Grundidee hinter dem Pattern.Lösung: Wie das Problem adressiert wird.Warum: Vorteile & Nutzen des Patterns.Beispiele: Wo es erfolgreich eingesetzt wurde.Implementierung: Technische Umsetzung. 🚀

Usability Testing ✅ 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. Eyetracking✅ Definition:Erfasst Blickbewegungen & Fixationsdauer mit speziellen Monitoren oder Brillen.✅ Zweck:Unterscheidet zwischen Lesen & Scannen von Inhalten.Analysiert Fokusbereiche & Blickreihenfolge auf einer Webseite.Hilft, Nutzerverhalten besser zu verstehen.⚠ Limitierung: Peripheres Blickfeld wird nicht erfasst.

Standardisierte Fragebögen ✅ Übersicht:AttrakDiff: Misst pragmatische & hedonische Qualität sowie Attraktivität eines Produkts (28 Items).UEQ (User Experience Questionnaire): Bewertet Attraktivität, Verständlichkeit, Effizienz & Stimulierung (26 Items).SUS (System Usability Scale): Schnelle Usability-Bewertung mit 10 Fragen auf einer Likert-Skala (1–5).SUMI, QUIS, Isonorm 9241-10: Weitere Usability-Fragebögen für unterschiedliche Anwendungsfälle.✅ SUS-Score Berechnung:Antworten 0–4 kodieren, summieren (max. 40) und mit 2,5 multiplizieren → Wert zwischen 0–100 als Usability-Prozentwert. 🚀

Cognitive Walkthrough ✅ Ziel:Identifikation von Bedienproblemen & Erlernbarkeit durch Experten.Simulation des Nutzerverhaltens zur Analyse von Handlungsabläufen.Unterschiede zwischen Nutzer- & Entwicklerperspektive aufdecken.✅ 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. 🚀

Heuristische Evaluation ✅ 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. Nielsen Heuristiken ✅ 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.

Wichtige Einflussfaktoren im Kontext der Anforderungsermittlung✅ Menschliche Faktoren:Motivation, Kommunikationsfähigkeit, AbstraktionsvermögenUnterschiedliche Meinungen, Machtgefälle, Gruppendynamik✅ Organisatorische Faktoren:Marktbedingungen, Budget, Stakeholder-Verteilung & VerfügbarkeitAnzahl der Stakeholder✅ Fachliche Faktoren:Komplexität & Kritikalität des ThemasSystemumfang, Fachwissen, DetailgradNichtfunktionale Anforderungen