SWEII

Integer

Boolean

String

unlimitednatural

Benutzergeführte (z.B. CLI, Abfrage-, Makro- & Programmiersprachen)

Systemgeführte (z.B. Menüs, Prompts, Formulare. Das System gibt den Ablauf vor)

Gemischte (z.B. Dialoge mit wechselnder Initiative oder alternativen Eingabemöglichkeiten

Aufgabenangemessenheit: Zu erledigende Aufgaben müssen effektiv und effizient erledigbar sein durch passenden Infogehalt & und Werkzeuge

Selbstbeschreibungsfähigkeit: "Intuitive Bedienung" durch selbsterklärung und dezente Rückmeldung des Systems

Lernförderlichkeit: Dialogsystem muss einfach erlernbar sein durch einheiltiches und einprägsames Strickmuster (z.B. Buttons immer an der gleichen Stelle)

Steuerbarkeit: Ablauf muss selbst bestimmbar und die Richtung/Geschwindigkeit des Dialogs beeinflussbar sein

Erwartungskonformität: Erfüllung der Nutzererwartung an Abläufe und Kontinuität der Oberfläche

Individualisierbarkeit. Individuelle Vorlieben Berücksichtigen. Anpassung an jeweilige Arbeitsaufgabe möglich. Anpassungen müssen jedoch zu mehr effizienz führen.

Fehlertoleranz: System ist gegen offensichtliche Fehleingaben resistent und kann diese selbst korrigieren.

Organisatorische: Projektorganisation, Softwareprozesse

Konstruktive: Architektur, Entwurf

Analytische: Validierung, Test, Inspektion

Kosten vermeiden

Vertrauen schaffen

Fehler finden

Qualität nachweisen

Risiko minimieren

Wähle destruktiven Ansatz: Test ist erfolgreich wenn Fehler gefunden

Vollständiges Testen ist nicht möglich: Ab gewisser Komplexität nur Stichprobenartig mit gewissem Abdeckungsgrad

Beachte Kakerlaken Prinzip: Ein gefundener Fehler in einer Komponente lässt auf weitere schließen. Abdeckungsgrad erhöhen

So früh wie möglich beginnen: z.B. mit Usability Driven Design (Papierprototypen, Mockups)

Test ist immer Kontextbezogen: Abhängig von der Umgebung, Anwender, Arbeitsplatz, Umfeld

Beachte das Pestizid Paradoxon: Test unter gleichem Kontext zu wiederholen ist sinnlos

Vermeide Trugschlüsse auf Brauchbarkeit: Fehlerfreiheit ungleich Brauchbarkeit

C0: Anweisungsüberdeckung

C1: Zweigüberdeckung

C2: Pfadüberdeckung

Fehler: Fehlverhalten des Systems, nichterfüllung festgelegter Forderungen

Defekt: Fehler durch mangelndes Problemverständnis

Mangel: Nichterfüllung angemessener aber nicht dokumentierter Erwartungen

Programmierfehler: im Code während der Entwicklung

Infektion: Fehlerzustand zur Laufzeit

Fehlfunktion: sichtbare Manifestation eines Fehlers

Die meisten Kosten entstehen durch Fehler aus der Anforderungsdefinition. Diese Fehlerquelle soll SWE minimieren.

Besteht aus Zeit, Kosten, Qualität und Quantität.

Es lassen sich immer nur zwei Merkmale erfüllen, die anderen beide resultieren aus diesen.

Komplexität von IC's verdoppelt sich alle 12-24 Monate. Zwar gibt es bessere Programmiersprachen, jedoch wird der technische Fortschritt dieser Entwicklung immer davon laufen.

Klassendiagramm: Konstruktionszeichnung des Systems. Bildet Klassen, innere Struktur und Beziehungen ab

Paketdiagramm: Zeigt Pakete und Beziehungen zwischen Pakete

Komponentendiagramm: Zeigt Struktur des Systems

Kompositionsstrukturdiagramm: Zeigt konkreten inneren Aufbau einer Komponente

Objektdiagramm: Zeigt Instanzen und Beziehungen/Inhalt zwischen Instanzen zu eniem bestimmten Zeitpunkt zur Laufzeit des Systems

Verteilungsdiagramm/Einsatzdiagramm: Zeigt konkrete Installation eines Systems

Anwendungsfalldiagramm: WAS leistet das System für den Anwender

Aktivitätsdiagramm: WIE realisiert das System etwas grob. Verfeinert use-cases

Zustandsdiagramm: Zustand und Zustandswechsel einer Klasse

Sequenzdiagramm: Fein, dokumentiert den konkreten Ablauf z.B. einer Methode

Kommunikationsdiagramm: Wer kommuniziert mit wem, NICHT wann

Zeitverlaufsdiagramm: Zustände und Zustandswechsel von mehreren Objekten in einem Zeitintervall

Architektur (nicht-funktionale Anforderungen) ist teil des Entwurfs und daraufhin erfolgt die Konstruktion (funktionale Anforderungen.

Mehrebenenarchitektur wie MVC. Damit erreicht man die Austauschbarkeit von Ebenen

Das Konzept ein Anwendungssystem in grundlegende Komponenten zu zerlegen und deren Zusammenspiel über Schnittstellen zu beschreiben.

Anforderungserhebung ist der Übersetzungsprozess von der Fachperspektive in die Entwicklerperspektive.

Nicht-funktionale Anforderungen: Wartbarkeit (Architekturentscheidung), Robustheit usw.

funktionale Anforderungen: Was das System machen soll (Konstruktionsentscheidung)

Hier werden Anforderungen von Fachperspektive in Entwicklerperspektive überführt.

Use-Case: Welche Aufgaben muss das System für den Benutzer generell erfüllen (Kundensicht)

Aktivity: Wie müssen diese Aufgaben konkret erfüllt werden (Kundensicht)

Fachklassenmodell: Aus Fließtext die erste Abstraktion der Anforderungen. Wie hängen die einzelnen Klassen auch in der Realität zusammen.

Klassendiagramm: Verfeinerung des Fachklassenmodells z.B. durch erste benötigte Attribute und Methoden.

Komponentendiagramm: Aufteilung des Systems in Programmbestandteile zur Zuteilung zu bestimmten Entwicklern.

Paketdiagramm: Welche Pakete und Beziehungen können erstellt werden.

Zustandsdiagramm: Beschreibt mögliche/erlaubte, Zustände/Werte einer Klasse und deren erwartete Veränderung

Klassendiagramm: Anpassung/Erweiterung des Klassenmodells an Probleme die sich aus dem Entwicklungsprozess ergeben (z.B. weitere (Hilfs-)Attribute und Methoden, zusätzliche Abstraktion)

Sequenzdiagramm: umgesetzter Ablauf einer Methode und Code Abarbeitung

Kompositionsstrukturdiagramm: Konkrete Implementation einer Komponente aus der Entwurfphase

Klassendiagramm: Abgleichen der fertigen Implementation mit der "Konstruktionszeichung". Wurde alles eingehalten und das System gemäß den Anforderungen konstruiert?

Objektdiagramm: Instanzen und Beziehungen zu einem bestimmten Zeitpunkt lassen sich beim debuggen nachvollziehen und prüfen.

1. "Kunst": Maschinencode

2. "Normierung": Sprungorientierung

3. "Strukturierung": Sequenzierung/Iteration/Verzweigung, Kein Sprung,

4. "Objektorientierung": Abstraktion, Kapselung