Validierung

• Eignung bzw. der Wert des Produktes bezogen auf seinen Einsatzzweck

• Wird ein passendes Produkt entwickelt?

Verifikation

• Überprüfung der Übereinstimmung zwischen einem Produkt und seiner Spezifikation

• Wird das Produkt richtig entsprechend den Vorgaben entwickelt?

• Die Software läuft nicht auf den vereinbarten Rechnersystemen

• sie ist zu langsam oder kommt mit dem Speicher nicht aus

• Die Software kann nicht erweitert werden oder mit anderer Software zusammenarbeiten

• Kosten explodieren

• Zeitrahmen nicht eingehalten

• Die Software erfüllt nicht die Wünsche des Kunden

Software

• Immaterielles Produkt

  • man kann SW nicht „anfassen“, nicht „sehen“

  • nur Dokumentation beschreibt die Software

• Unterliegt keinem Verschleiß

  • Programme können beliebig oft ablaufen

    • „klassische Wartung“ nicht erforderlich

• Keine Ersatzteile

  • Programm wird nur einmal entwickelt

• Schwer zu „vermessen“

  • Qualität zu definieren und zu messen äußerst schwierig

• Altert

  • HW Leistungen und SW Techniken ändern sich ständig

• Im allgemeinen (!!) leichter und schneller änderbar

• Materielles Produkt

• Unterliegt einem Verschleiß

  • Nach 200000 KM ist der Motor defekt

• Ersatzteile

  • Neuer Motor kann eingebaut werden

• Einfach zu „vermessen“

  • Ob die Schraube für die Radbefestigung passt oder nicht, kann mit einer Schieblehre festgestellt werden

• Altert

• hoher Änderungsaufwand

• Änderung der Kofferraumgröße erfordert die Konstruktion neuer Werkzeuge für die Produktion

• Viele wichtige Komponenten sind heute kostenlos verfügbar, aber teure Individuialsoftware für Kernprozesse

• Das Verhältnis zwischen Hardware und Software Ausgaben bleibt etwa konstant bei 6:4

• Viele wichtige Komponenten sind heute kostenlos verfügbar, aber teure Individuialsoftware für Kernprozesse

  • Das Verhältnis zwischen Hardware und Software Ausgaben bleibt etwa konstant bei 6:4

• Die Herstellung großer Softwaresysteme unterscheidet sich qualitativ und nicht nur quantitativ von der Herstellung kleiner Software

  • Die Komplexität großer Softwaresysteme übersteigt die von einem Entwickler zu einem Zeitpunkt zu beherrschende Komplexität

  • Die Wahrscheinlichkeit für die Korrektheit eines Systems von Modulen ist wesentlich kleiner als die Wahrscheinlichkeit für die Korrektheit einzelner Module

• Die Zahl der noch im Produkt befindlichen Fehler kann zunächst schnell gesenkt werden

  • Die Fehlerzahl wird im allgemeinen nie Null erreichen

  • Änderungen und neue Anforderungen erhöhen die Fehlerzahl

  • Nach genügend vielen Revisionen entsteht ein nicht mehr handhabbares Produkt

• Programmiersprachen: kontinuierliche Einführung von Abstraktion (Datentypen, Funktionen, Module, Klassen, Bibliotheken, Frameworks)

• Dokumentation: Einheitliche Notationen für Entwicklungsanforderungen und ergebnisse (UML)

• Entwicklungsprozesse: Aufgabenbeschreibungen, wann was wie gemacht wird

• Vorgehensmodelle: Entwicklung passt sich an Bedürfnisse des Kunden an

Entwicklung und Nutzung von

• Vorgehensmodellen

• Methoden

• Notarionen

• Werkzeugen

Definition:

Software-Engineering wird sowohl für das wissenschaftliche Themengebiet der Entwicklung entsprechender Vorgehensmodelle, Methoden, Notationen und Werkzeuge verwendet als auch für ihre konkrete Nutzung in der Praxis

1. Methoden

   Planmäßig festgelegte, begründete Vorgehensweisen zur Erreichung eines Ziels

2. Werkzeuge

   Hilfmittel zur Unterstützung von Methoden und Notationen

3. Notation

   Darstellung von Sachverhalten durch Symbole und deren Bedeutung

Vorgehensmodell

• Vorgehensmodelle stellen Methoden und Elemente des Projektmanagements zu Prozessen und Phasen eines standardisierten Projektablaufes zusammen.

• Es erlaubt eine vereinfachte Darstellung des Softwareentwicklungs /Softwarebeschaffungs prozesses aus einer bestimmten Perspektive.

• Nur ein Teil der Informationen über den Prozess sind enthalten

• Bestimmter Ansatz für die Art der Durchführung und Reihenfolge der Teilaufgaben einer Systementwicklung

Vorgehens Meta Modell

• Modell eines Vorgehensmodells

• Einheitliche Beschreibung eines Vorgehensmodells ähnlich einer Sprache

• Vergleichbarkeit von Vorgehensmodellen => Forschung

Vorgehensmodell Strategie Überblick

• Durchläufe der Gestaltungsstufen

• Systemkonzept

• Vorgehensweise

• Ausgangspunkt

• Schwierigkeitsgrad

• Verwendungshäufigkeit

• Drchläufe der Gestaltungsstufen

  • Einmalig

  • iterativ

• Systemkonzept

  • datenorientiert

  • funktionsorientiert

  • objektorientiert

• Vorgehensweise

  • Top-Down

  • Bottom-Up

• Ausgangspunkt

  • induktiv

  • deduktiv

• Schwierigkeitsgrad

  • Easiest-first

  • Hardest-first

• Verwendungshäufigkeit

  • Einfachverwendung

  • Mehrfachverwendung

• Komplexität

  • Eine Schwierigkeit ist die wechselseitige Verknüpfung zwischen den Maßnahmen, die zum Software Engineering gerechnet werden.

1. das klassisch sequentielle Phasenmodell

2. das Wasserfall Modell

3. das evolutionäre bzw. prototyping orientierte Lebenszyklus Modell

4. das Spiralmodell nach BOEHM

5. das objektorientierte Lebenszyklus Modell

6. das Agile Modell

• Projekt-, Vorgehens-, und Rosikomanagement

• Anforderungserhebung

• Qualitätsmanagement

1. Wasserfallmodell

2. inkrementelle Entwicklung

3. evolutionäre Entwicklung

4. Prototypische Vorgehensmodelle

5. Pilotsystem

6. Spiralförmige Entwicklung

7. Spiralmodell

• Die Phasen des Wasserfallmodells entsprechen denen des Phasenmodells.

• Das Ergebnis einer jeden Phase ist eine Reihe von Artefakten, die in der nächsten Phase weiterverarbeitet werden.

• Am Ende einer Phase können deren Ergebnisse Qualitätssicherungsmaßnahmen unterzogen werden.

• Mit der nächsten Phase soll erst begonnen werden, wenn die vorige abgeschlossen ist.

• In der Praxis überlappen die Phasen sich jedoch häufig.

  
  

Vorteile

• In jeder Phase wird Dokumentation erstellt.

• Das Modell ist mit Vorgehensmodellen anderer Disziplinen kompatibel.

• Das Wasserfallmodell gibt einen klaren, aus Sicht des Projektmanagements beziehungsweise des Auftraggebers einfach zu verstehenden, linearen und gut kontrollierbaren Ablauf vor.

Nachteile

• Hauptnachteil ist die unflexible Aufteilung des Projektes in diskret sequentialisierte , gegeneinander abgegrenzte Phasen.

• Schon früh müssen weit reichende Festlegungen bei geringem Kenntnisstand gemacht werden, was den Umgang mit sich ändernden Anforderungen schwierig gestaltet.

• Projekte folgen üblicherweise nicht dem sequenziellen Fluss, den das Modell vorsieht.

• Grobe Fehler werden unter Umständen erst während des Einsatzes entdeckt.

• Ein einmal festgelegter Entwicklungsablauf wird starr eingehalten, ohne dass beispielsweise Projekt und Entwicklungsrisiken berücksichtigt werden.

• Zu Beginn eines Projektes sind die Anforderungen oft noch unklar und können nicht vollständig und präzise formuliert werden

• Hoher Dokumentationsaufwand

• umfasst eine (zumindest skizzenhafte) Darstellung aller Anforderungen, die das System erfüllen soll (vollständig).

• Jeder dieser Anforderungen wird Priorität zugewiesen.

• Daraufhin wird eine Anzahl von Iterationen geplant.

• Jede Iteration implementiert einen Teil der Anforderungen (schalenförmiger Aufbau).

• Die Anforderungen mit der höchsten Priorität werden dabei als erstes realisiert.

• Sobald die Inkremente festgelegt sind, definiert man detailliert die Anforderungen, die im ersten Inkrement implementiert werden sollen.

• Die Anforderungsanalyse wird während den Iterationen fortgesetzt, mit der Einschränkung, dass die Anforderungen des laufenden Inkrements nicht geändert werden dürfen.

• Sobald ein Inkrement fertig gestellt und ausgeliefert wurde, kann es von den Anwendern eingesetzt werden. Diese können so mit dem System experimentieren.

• Auf diese Weise erhalten sie Kenntnisse, die ihnen bei der weiteren Identifikation von Anforderungen helfen. Neue Inkremente werden in das System integriert, so dass dessen Funktionalität schrittweise erweitert wird.

Vorteile

• Die Kunden erhalten schon frühzeitig Teile des Systems und können damit schon früh Wert schöpfen.

• Die Kunden können die ersten Inkremente als Prototypen benutzen, mit denen sie Erfahrungen sammeln können, die ihnen bei der Aufstellung von Anforderungen helfen

• Diese Arbeit ist nachhaltig wegen konsolidierter Basis Architektur

• Das Risiko des vollständigen Scheiterns des Projektes wird vermindert.

• Selbst wenn einige Inkremente scheitern, können die anderen den Kunden immer noch von Nutzen sein.

• Inkrementelle Entwicklung erlaubt es, zu Beginn des Projektes mit weniger Entwicklern zu arbeiten.

Nachteile

• Da die Inkremente eher klein sein sollen, kann es schwierig sein die Anforderungen der Kunden Inkrementen angemessener Größe zuzuordnen.

• Reihenfolge der Inkremente ggf. schwer zu bestimmen.

• Festlegung der einer stimmigen Grob bzw. Basisarchitektur kritisch für den Erfolg.

• Ggf. langer Zeitraum für Festlegung der Anforderungen.

Ausgangspunkt: Kern und Mussanforderungen der Auftraggeber

=> Produktkern

• So wird beginnend mit einem Kernsystem eine Reihe von Versionen des Systems realisiert und ausgeliefert.

• Auf diese Weise können Auftraggeber und Anwender Erfahrungen mit dem System sammeln. Die Weiterentwicklung orientiert sich an ihrem Feedback.

• Auf diese Weise werden die Anforderungen an das System im Laufe des Projektes ermittelt.

• Steuerung durch den Auftraggeber

• Nach Sommerville (2001) ist der evolutionäre Ansatz für kleine und mittlere Systeme (bis zu 500.000 Zeilen Programmcode) der beste.

Vorteile

• Durch die inkrementelle Entwicklung der Spezifikation gewinnen Benutzer und Entwicklungsteam ein besseres Verständnis des Problems.

• Die Erfolgsquote, was die Erfüllung der Bedürfnisse des Kunden anbetrifft, ist höher als beim Wasserfallmodell.

• Wenn Time to Market sehr kritisch ist, kann eine komplette Version oft nicht schnell genug geliefert werden. Evolutionäre Ansätze erlauben es jedoch, rechtzeitig zumindest eine eingeschränkte Version zu realisieren.

• Team kann über die Inkremente hinweg lernen. Daher kann der Ansatz auch eingesetzt werden, wenn zu Beginn des Projektes die Erfahrung des Teams mit den verwendeten Entwicklungstechniken gering ist.

• Nicht zuletzt wird dadurch das Risiko gesenkt.

• Integrationstests werden vereinfacht, da nicht alles gleichzeitig integriert und getestet wird.

• Die Entwicklung eines Systems wird im Vergleich zum Wasserfallmodell in kleinere Einheiten überschaubarer Größe aufgeteilt.

• Dadurch ist es möglich, den Projektablauf an die im Projektverlauf gewonnenen Erfahrungen anzupassen

  
  

Nachteile

• Es besteht die Gefahr, dass frühe Versionen nicht flexibel genug sind, um sich an ungeplante Evolutionspfade anzupassen.

• Der Fortschritt ist schwerer zu erkennen d.h. aus Sicht des Managements geht bei der evolutionären Entwicklung die langfristige Planbarkeit eines Projektes verloren, da es bei nicht festgelegter Anzahl von Iterationen auch nicht möglich ist, das Projektende abzusehen.

• Aus technischer Sicht besteht die Gefahr, dass aufgrund neu hinzugekommener Anforderungen die Architektur des Systems überarbeitet werden muss.

• Probleme bei der Anpassbarkeit der Nullversion

• Die Benutzer müssen während des gesamten Projektes beteiligt werden. Es entsteht ein erhöhter Aufwand bzgl. Kommunikation, Koordination und Dokumentation.

• Möglichst schnelle Entwicklung einer rudimentär ablauffähigen Vorversion

• Wesentliche fachliche Funktionalität soll erkennbar sein

• Diskussionsbasis für die weitere Entwicklung

• Klärung von Problemen

• Teil der Produktdefinition

• Inkrementelle Entwicklung

Voraussetzungen

• Ausreichendes Wissen über Anwendungsgebiet

• Zugang zu Benutzern

• Beteiligung der Benutzer am Entwicklungsprozess

• Umfassende Dokumentation

• Verfügbarkeit geeigneter Werkzeuge

Demonstrationsprototyp

• Einsatz: Auftragsakquisition

• Vermittlung eines ersten Eindrucks

• Klare Abgrenzung zum Endprodukt

• Vernachlässigung softwaretechnischer Standards

Prototyp im engeren Sinn (explorativer Prototyp)

• Einsatz: Analyse des Anwendungsbereiches

• Erstellung parallel zur Modellierung des Anwendungsbereichs

• Veranschaulichung spezifischer Aspekte

  • Benutzungsschnittstelle

  • Teile der Funktionalität

• Provisorisches, ablauffähiges Software System

Labormuster (experimenteller Prototyp)

• Einsatz: Vergleich von konstruktionsbezogenen Alternativen

• Demonstration der technischen Umsetzbarkeit eines Produkt Modells (in Bezug auf Architektur oder Funktionalität)

• Keine Einbeziehung von Endbenutzern

Horizontaler Prototyp

• Realisierung einer spezifischen Ebene eines Systems

  • Beispiel: Umsetzung der Benutzungsschnittstelle

• Umsetzung der Ebene möglichst vollständig Vertikaler Prototyp

• Realisierung ausgewählter Teile eines Systems durch alle Ebenen

  • Beispiel: Umsetzung einer Echtzeitanforderung

• Umsetzung dieser Teile möglichst vollständig

Pilotsystem

• Kern des späteren Endprodukts

• Nach Erreichung eines Reifegrads wird das Pilotsystem in Zyklen weiterentwickelt

• Orientierung an Benutzerprioritäten

• Sorgfältige/r Entwurf und Dokumentation notwendig

Vorteile

• Das Entwicklungsrisiko wird durch den frühen Einsatz von Prototypen gesenkt.

• Eine starke Rückkopplung mit dem Endbenutzer und dem Auftraggeber wird gefördert.

• Die schnelle Erstellung eines ersten funktionsfähigen Systems erleichtert die Kommunikation zwischen Entwicklung, Management und Kunden.

Nachteile

• Prototypen werden oft als Ersatz für die fehlende Dokumentation angesehen.

• Prototypen können bei den Kunden falsche Erwartungen wecken.

• Aufwand für die Entwicklung von (Wegwerf-) Prototypen.

• Gefahr der Nutzung des Prototypen als Endprodukt (i.d.R. hohe Folgekosten)

Der Software Prozess wird als Spirale dargestellt:

• Jede Windung entspricht einer Phase des Softwareprozesses.

• So kann beispielsweise in der ersten Windung die Machbarkeit des Systems untersucht werden, in der nächsten die Systemanforderungen aufgestellt werden, in der folgenden der Systementwurf, etc.

  
  

Jede Windung ist in vier Sektoren unterteilt, die im Projekt iterativ zu durchlaufen sind:

1. Ziele aufstellen :

   • Risiken werden identifiziert und alternative Möglichkeiten bezüglich der Realisierung des Systems abgewogen beispielsweise unterschiedliche Architekturentwürfe, Wiederverwendung oder der Einsatz von Fertigprodukten.

2. Risiken einschätzen und verringern :

   • Es findet eine detaillierte Analyse jedes Projektrisikos statt. Maßnahmen zur Risikominderung werden eingeleitet.

3. Entwicklung und Validierung :

   • Für die Durchführung dieser Phase wird ein im Hinblick auf die identifizierten Risiken geeignetes Modell für die Entwicklung gewählt (Anwendung des Wasserfallmodells, des inkrementellen Modells, des protypischen Modells oder auch eine Kombination dieser Modelle).

   • Damit enthält das Spiralmodell „ andere Vorgehensmodelle als Spezialfälle und kann somit als eine Art Meta Vorgehensmodell verstanden werden.

4. Planung :

   • Das Projekt wird einer Begutachtung unterzogen und es wird entschieden, ob noch eine weitere Schleife durchlaufen werden soll. Falls das Projekt fortgesetzt wird, wird an dieser Stelle die nächste Phase des Projektes geplant.

   • Kosten und Terminplan werden angepasst. Zusätzlich passt der Projektmanager die gelante Anzahl verbleibender Iteration an.

   • Konfigurationsmanagement und Qualitätssicherung werden kontinuierlich während des gesamten Projektes durchgeführt.

   • Der Hauptunterschied zu anderen Modellen liegt in der expliziten Betrachtung von Risiken.

Charakteristika des Spiralmodells:

• Risiko getriebenes Modell

• Jede Windung der Spirale stellt iterativen Zyklus durch dieselben Schritte dar

• Ziele für jeden Zyklus werden aus Ergebnissen des letzten Zyklus abgeleitet

• Separate Spiralzyklen für verschiedene Software Komponenten möglich

• Keine Trennung von Entwicklung und Wartung

• Berücksichtigung von Qualitätszielen bei Zielbestimmung

Vorteile

• Risiken werden explizit betrachtet.

• Prototypen werden zur Verminderung des Risikos eingesetzt.

• Auf neue Erkenntnisse innerhalb des Projekts kann dynamisch reagiert werden.

• Anders als klassische Prozessmodelle, die enden wenn die Software ausgeliefert wird, kann das Spiralmodell auf den gesamten Lebenszyklus der Software angewandt werden.

• Andere Vorgehensmodelle werden als Spezialfälle integriert.

• Fehler und ungeeignete Alternativen werden frühzeitig eliminiert.

• Der Ansatz ist sehr flexibel.

• Durch die Betrachtung von Alternativen wird Wiederverwendung unterstützt.

Nachteile

• Es ist womöglich schwer, den Kunden davon zu überzeugen, dass der Ansatz kontrollierbar ist.

• Es besteht ein hoher Managementaufwand, da oft Entscheidungen über den weiteren Prozessablauf getroffen werden müssen.

• Für kleine und mittlere Projekte ist der Ansatz weniger gut geeignet.

• Identifizierung und Managen von Risiken wenig verbreitet

Man konzentriert sich darauf, bereits entwickelte und

für das System wieder verwendbare Teile zu

integrieren, anstatt sie von Grund auf neu zu

entwickeln.

• Die Unterschiede liegen in den folgenden Phasen:

  1. Analyse der Komponenten :

     • Ausgehend von der Anforderungsspezifikation werden bestehende Komponenten gesucht, die diese umsetzen.

     • Oft findet man dabei keine exakte Umsetzung, sondern nur Komponenten die einen Teil der geforderten Funktionalität realisieren.

  2. Anpassung der Anforderungen :

     • In dieser Phase werden die Anforderungen angepasst, so dass sie den vorhandenen Komponenten entsprechen.

     • Wenn eine Anpassung unmöglich ist, führt man die Komponentenanalyse erneut aus, um alternative Lösungen zu finden.

  3. Systementwurf mit Wiederverwendung :

     • In dieser Phase wird der Systementwurf erstellt.

     • Es wird dabei der Wiederverwendung von Komponenten Rechnung getragen.

  4. Entwicklung und Integration :

     • Die Funktionalität, die nicht durch bestehende Komponenten bereitgestellt wird, wird entwickelt.

     • Die Integration wird vorgenommen.

Vorteile

• Ein offensichtlicher Vorteil dieses Ansatzes liegt darin, dass weniger Software entwickelt werden muss, wodurch Zeit und Kosten gespart werden.

• Eine Organisation kann sich auf die eigenen Stärken konzentrieren und Komponenten, die Standardfunktionalität bereitstellen und/oder nicht der Kernkompetenz entsprechen, zukaufen.

• Komponentenbasierte Entwicklung lässt sich auch mit anderen Vorgehensmodellen kombinieren.

Nachteile

• Der Hauptnachteil liegt darin, dass Kompromisse bei den Anforderungen gemacht werden müssen, was dazu führen kann, dass die Bedürfnisse des Kunden nicht abgedeckt werden.

• Die Weiterentwicklung wird dadurch erschwert, dass man keine Kontrolle über neue Versionen der wiederverwendeten Komponenten hat.

• Obwohl das Prinzip der Wiederverwendung eine weite Verbreitung gefunden hat und in vielen Prozessen vorkommt, orientieren sich nur wenige Organisationen explizit daran.

1. Formale Systementwicklung

• Durch Verifikationen wird gewährleistet, dass diese Umwandlungen die Korrektheit erhalten und somit das Programm seiner Spezifikation entspricht.

• Diese Gewährleistung macht den Ansatz für sicherheitskritische Systeme interessant.

• Außerhalb dieser Systemdomäne wird er jedoch kaum verwendet.

1. Vor- und Nachteile

Vorteile

• Formale Systementwicklung ist besonders gut für die Entwicklung von Systemen geeignet, bei denen Sicherheit und Verlässlichkeit kritische Faktoren sind.

• Die Methode gewährleistet, dass das Programm der Spezifikation entspricht.

• Verträge können die Spezifikation des Systems als Grundlage verwenden.

Nachteile

• Der Zeit und Kostenaufwand ist sehr hoch.

• Umfangreiches Training ist nötig, da nur wenige Software Entwickler über das entsprechende Wissen verfügen.

• Die Kommunikation mit dem Kunden gestaltet sich schwierig, da dieser mit formalen Modellen in der Regel nicht viel anfangen kann.

Bei allen Schritten erfolg eine Dokumenteninspektion

Vorteile

• Hohe Testabdeckung, weil die Spezifikationen der jeweiligen Entwicklungsstufen die Grundlage für die Tests (Testfälle) in den entsprechenden Teststufen sind.

• Behauptung: Validierung vor Verifizierung (wirklich?)

Nachteile

• Die Anforderungen an ein neues System sind zu Beginn nie vollständig bekannt.

• Während der Entwicklung kann sich eine produktive Zusammenarbeit zwischen Benutzern und Entwicklern ergeben, aus der neue Realisierungsmöglichkeiten resultieren.

• Es gibt für eine Anforderung verschiedene Realisierungsmöglichkeiten.

• Vollständigkeit der Validierung ist offen

  (ist es denn eine?)

Vorteile

• Die Parallelisierung verkürzt Produkteinführungszeiten.

• Ansatz fördert die funktionsübergreifende Kollaboration und führt das gesammelte Expertenwissen frühzeitig zusammen.

• Durch die Integration aller Projektbeteiligten werden Probleme frühzeitig erkannt.

Nachteile

• Paralleles Ausführen von logisch nachgelagerten Aktivitäten birgt zusätzliche Risiken.

• Mit der nebenläufigen Entwicklung ist in jedem Fall ein sehr hoher Aufwand verbunden, um in der Planung Engpässe zu antizipieren.

• Paralleles Arbeiten erfordert präzises Management.

1. Merkmale:

   • Anwendungsfallgetrieben („Use Case driven”)

   • Architekturzentriert

   • Iterativ

   • Inkrementell

   • (Einsatz von UML)

     
     

2. Vor und Nachteile:

Vorteile:

• Risiken werden frühzeitig identifiziert und geprüft

• Frühzeitige Validierung der Architektur

• Frühzeitig „ablauffähige“ Ergebnisse und dadurch frühzeitiges Kundenfeedback: nach jeder Iteration kann der Kunde prüfen.

• Keine vollständige Definition der Anforderung erforderlich: Anforderung für zukünftige Iterationen können sich ändern ohne erhebliche Konsequenzen (wenig aufgelaufene Use Cases fördern die Konzentration darauf, was wirklich wichtig Anforderungen sind“)

Nachteile:

• Der Unified Process ( und UML ) sind leistungsfähig, aber komplex

• Finden der Architektur Baseline existentiell

• Zuordnung zu Iterationen

1. Definition Use Cases

   Die Beschreibung einer Interaktion zwischen einem System und seinen Benutzern, die typischerweise in Form von Szenarien oder Abläufen dargestellt wird, um die Funktionalitäten und Anforderungen zu verdeutlichen.

• „Welchen Mehrwert bringt eine Anforderung“ und nicht nur „diese Funktion hätte ich auch noch gerne“.

  
  

1. Actor

   Ein Actor ist eine außerhalb des Systems am Anwendungsfall beteiligte Rolle (nicht Person!).

• (Rollen für Geldautomat Beispiel: Bankkunde, Servicetechniker)

• Mehrere Rollen können durch ein und dieselbe Person ausgeübt werden: Herr Maier ist Bankkunde und Servicetechniker)

Beispiel:

Use Case name : „Benutzer holt Geld ab”

Vorbedingung: Karte im Automat ordnungsgemäß eingeführt und erkannt

Nachbedingung: Benutzer als „berechtigt“ identifiziert oder Benutzer als „unberechtigt“ identifiziert

Actors: Bankkunde

Nicht funktionale Anforderungen: Die Überprüfung darf nicht länger als 1 sec dauern.

Ablauf

• Der Use Case beginnt mit der Aufforderung an den Kunden, eine PIN Nummer einzugeben.

• Der Kunde kann nun eine PIN Nummer via Tastatur eingeben.

• Der Kunde bestätigt die Eingabe durch Enter Button.

• System checkt die PIN Nummer.

• Falls PIN Nummer korrekt ist der Zugang erlaubt, andernfalls ist der Use Case beendet.

Ablaufausnahme

• Der Kunde kann zu jeder Zeit die PIN Nummer mit dem clear Button löschen und eine neue eingeben.

• Falls der Kunde eine falsche PIN Nummer eingibt, startet der Use Case erneut. Falls das drei mal passiert, wird der Use Case abgebrochen und die Karte gesperrt.

Definition Architektur:

Die Architektur ist die grundsätzliche Struktur des Systems. Zur grundsätzlichen Struktur gehört die Zerlegung des Systems in Komponenten und deren Schnittstellen, das Verhalten des Systems und das Zusammenwirken Verhalten und Komponenten.

• Eine Beschreibung eines einzelnen Aspekts nennt man Architektursicht.

Fokussierung auf eine frühe Entwicklung einer ersten Baseline 1 einer Software Architektur; diese Baseline Architektur ist Bestandteil einer „Anforderungsphase“ und ist Grundlage für die Planung und Entwicklung Identifikation und Implementierung der SW Architektur für 5-10% aller Use Cases, die die Kernfunktionalität repräsentieren.

• Sukzessive Weiterentwicklung der SW Architektur bis stabile Architektur erreicht ist.

1. Iterativ

• Zerlegung der Gesamtfunktionalität in kleinere „Scheiben“

• Jede Iteration repräsentiert einen kompletten Entwicklungszyklus und durchläuft immer alle Haupttätigkeiten (Anforderung, Analyse, Entwurf, Implementierung, Test)

• Jede Iteration wird separat geplant und controlled (d.h. z.B. Termin und Ergebnisverfolgung) und ist daher ein „Mini Projekt“

• Jede Iteration erzeugt konsistente Teilergebnisse

1. Inkrementell

• Jede Iteration erzeugt ein Inkrement des Gesamtsystems.

• Sukzessive Weiterentwicklung der Gesamtfunktionalität, die i.d.R. in jeder Iteration wächst.

1. Gemeinsamkeiten

• Iterativ und Inkrementell ist die „Entwicklung in kleinen Schritten“

• Ein bisschen“ planen

• „Ein bisschen“ spezifizieren, entwerfen und implementieren

• „Ein bisschen“ integrieren, testen und ausführen in jeder Iteration

Software Projekt:

Änderungen im Laufe der Entwicklung durch

mögliche Nicht Realisierung wegen mangelnder Erfahrung /

Ressourcen oder Anforderungen des Kunden.

Unzufriedenheit in Software Entwicklung durch:

• Permanent neue Änderungen

• „Vorbeiimplementierung“ am Ziel

• Faktor Mensch unbeachtet

  => „Nicht meine Aufgabe“

• Zu spätes und weniges Testen

  => Mängel in Kosten/Zeit/Qualität

„lean” = “schlank”

• Frei übersetzt: “Konzentration auf das Wesentliche”

• Lean Ansätze sind Bestandteil vieler agiler Vorgehensweisen

• Zwei Dimensionen: Inhalt und Durchführung

• 80 % der Funktionalität wird durch 20 % der Anforderungen abgedeckt

• Hoher Anteil an Code, der wenig/nicht zur Funktionalität beiträgt (20-50 %)

• ”Flow“: Produktionsprozess muss fließend sein, ansonsten entsteht Verschwendung

• Verringerung der (Teil --)Projektlaufzeit führt zu höherer Qualität

• Alles, was nicht der Wertschöpfung dient, weglassen

Begriffe:

• Value: “Wert des Produkts in den Augen des Kunden”

• Value Stream: “Welche Schritte sind zur Herstellung des Produkts notwendig“

• Flow: “Produktionsprozess muss fliesend sein”

• Pull: “Anfordern des Produkts durch den Kunden”

Prinzipien:

• No waste

• Wissen bewahren

• Entscheidungen aufschieben

• Schnell liefern

• Qualität einbauen

• Das Team befähigen

• Das Ganze sehen

Untscheidungen aufschieben

• Entscheidungen so spät wie möglich treffen

• Sich mehrere Optionen offen halten ist besser, als sich

  frühzeitig mit viel Unsicherheit festzulegen

• Während die Entscheidung noch aussteht, können

  Informationen gesammelt werden

• Spart Zeit (keine Verschwendung)

Schnell liefern

• Frühe Ergebnisse zeigen

• Früheres Feedback des Kunden

• Weniger Risiko

• Software Entwicklung in kurzen Iterationen

• Unterstützt den Methode möglichst spät zu entscheiden

Team befähigen

• Motivation durch Selbstbestimmung und Verantwortung

• Entscheidungskompetenz ins Projektteam verlagern, dorthin wo schnell und richtig entschieden werden kann

• Bildung eines “Kernteams“

• Zeigt die Bereitschaft zur Umsetzung von Lean Konzepten

Agiles Manifest

• Individuen und Interaktionen

  • “… sind wichtiger als Prozesse und Werkzeuge.”

  • Kommunikation und Interaktion der Mitarbeiter erwünscht

• Funktionierende Software

  • „… ist wichtiger als umfassende Dokumentation.”

  • Nur notwendige Anzahl an Dokumenten bei Umsetzung

• Zusammenarbeit mit dem Kunden

  • „… ist wichtiger als Vertragsverhandlungen.”

• Gemeinsam beste Lösung während der Entwicklung entwerfen Vorbereitung auf unbekannte Änderungen

  • „… ist wichtiger als einem Plan zu folgen.”

  • Vorkehrungen treffen, um auf Änderungen adaptiv zu reagieren

Prinzipien

• Höchste Priorität = Bedürfnisse des Kunden

• Unbeständige Anforderungen

• Häufige Auslieferungen

• Zusammenarbeit von Geschäftsleuten und Entwicklern

• Mitarbeitermotivation und Vertrauen

• Direkte Kommunikation

• unktionierende Software als Maßstab

• Endlos beständiges Tempo

• Technische Exzellenz

• Einfachheit

• Sich selbst organisierende Teams

• Regelmäßige Selbstreflexion

Praktiken

• Konkrete Handhabungsformen zur Entwicklung

• Keine konkrete Auswahlvorgabe vom Manifest

• Vielzahl an Praktiken

• Oft für selbe Praktik unterschiedliche Namen

• Meist keine neuen „bahnbrechenden“ Praktiken

• Wahrer Nutzen oft erst durch Kombination ersichtlich

Beispiele:

• Retrospektiven

• Pair Programming

• Refactoring

• Regressionstesten

• Automatisierter Build Prozess

• Tägliches Stand Up Meeting

Eine agile Methodik ist …

• Inkrementell

  Aufbauen der Software durch Hinzufügen von Stücken zu existierender funktionierender Software.

• Kooperativ

  Ausgeprägte Zusammenarbeit der Mitarbeiter untereinander und mit dem Kunden durch Kommunikation.

• Unkompliziert

  Leichte Erlernbarkeit und Abänderbarkeit.

• Adaptiv

  Möglichkeit der kurzzeitigen Änderung der Arbeitsprodukte

Beispiele:

• Extreme Programming

• Scrum

• Crystal

• Adaptive Software Development

• Feature Driven Development

• Dynamic System Development Method

• Pragmatic Programming

• Test Driven Development

• Agile Unified Process Modell

Agiler Softwareentwicklungsprozess

• Eignet sich besonders für kleine Entwicklerteams

• Folgt der Annahme, dass Anforderungen vage sind und sich schnell ändern können

• Kunde ist stark in den Entwicklungsprozess integriert

• Es wird bereits frühzeitig innerhalb eines Projektes Geschäftswert erzeugt

Projektleiter:

• Verantwortlich für das Management und die Koordination des Projektes

• Verwaltet Ressourcen, Kosten und Zeitpläne

• Verfolgt das Ziel, eine optimale Qualität des auszuliefernden Produktes zu erreichen

Kunde:

• Mindestens ein Vertreter des Kunden muss permanent erreichbar sein, um mögliche Fragen zu klären

• Verantwortlich für die Akzeptanztests der Entwickelten Features

• Entscheidet über die Priorisierung der einzelnen User Stories / Use Cases

Kundenvertreter im Team:

• Da keine echte Spezifikation (User Stories sind nicht detailliert genug) => viele Rückfragen an den Kunden

• Deshalb sollte ein Kundenvertreter für die Entwickler ständig im Zugriff sein (on site customer

• Zukünftiger Anwender

• Entwickelt die Testfälle (funktionale Tests)

Entwicklerteam:

• Innerhalb des Entwicklerteams gibt es keine Rollentrennung

• Entwickler schätzen die User Stories im Rahmen des Planning Pokers

• Entwicklungsteam setzt die Anforderungen des Kunden um

  • Design

  • Implementierung

  • Test

Werte:

XP setzt deren Einhaltung für das erfolgreiche Entwickeln von Software voraus

Prinzipien:

• Bilden die Brücke zwischen abstrakten Werten und konkreten Praktiken

• XP zeichnet sich durch 12 Praktiken aus

• Stützen sich gegenseitig

  => nur in ihrer Gesamtheit sinnvoll (!?)

• Sonst kann der XP Ansatz scheitern

• Praktiken selbst sind nicht neu, jedoch die Kombination und der „extreme Grad“

Kleine Releases = kleine Projektteile oder Version

• Ein Release Zyklus dauert i.d.R. zwischen ein und drei Monaten

• Besteht aus mehreren Iterationen (Dauer etwa ein bis vier Wochen)

• Eine Iteration zerfällt in mehrere Tasks/Arbeitspakete (Dauer etwa ein bis drei Tage)

• Nach jeder Iteration kann der Kunde Abweichungen feststellen und korrigieren

• Das erste Release sollte bereits ein funktionierendes Kernsystem bilden

• Es wird dann inkrementell in weiteren Releases ausgebaut

Vorteile:

• Kunde bekommt frühzeitig wichtige Funktionalitäten

• Entwickler bekommen schnelles Feedback

• Test haben eine Zentrale Rolle, ohne sie geht´s nicht

• Wissen über gewünschte Funktion steckt in den Testfällen und den User Stories / Use Cases

Testarten:

• Entwicklertests für Klassen unit tests technische Sicht, Dokumentationscharakter, Sicherheit bei Änderungen

• Kundentests für User Stories functional tests funktionale Fehler abdecken, Nachweis über Bereitstellung der Funktion

• Müssen automatisch ausgeführt werden

• Müssen schnell ausführbar sein

• Erst die Tests, dann die Implementierung !!

  • Zwingt Entwickler / Kunde zu Fallbeispielen

XP-Systemmetapher

• Steht für die grundsätzliche Idee hinter der Architektur des Systems

• Sie soll für den Entwickler und den Kunden verständlich sein

• Sie soll den Architekturentwurf ersetzen

• in puncto neue Programmteile soll sie folgendes vermitteln:

  • Welche Form angenommen werden soll

  • An welche Stelle ins System integriert werden soll

Einfacher Entwurf:

• Es soll immer nach einer einfachen Lösung gesucht werden

  • do the simplest thing that could possibly work

• Nur die momentan anstehenden Anforderungen sollen abgedeckt werden

  • develop for today

• Sollten später Änderungen notwendig sein, so wird der Entwurf refaktorisiert

• Refaktorisierung geringstmögliche Anzahl von Klassen, Attributen und Methoden

• Aspekte des einfachen Entwurfs:

  • Erfüllung der Anforderungen der Entwurf muss der Aufgabe gerecht werden

  • Redundanzfreiheit jede Information darf nur einmal gehalten werden

  • Refaktorisierung geringstmögliche Anzahl von Klassen, Attributen und Methoden

XP Refaktorisierung

• Dient der Vereinfachung des Entwurfs unter Beibehaltung der Semantik/Funktionalität

• Verbesserung der Verständlichkeit und Änderbarkeit des Codes

• Selbsterklärungsfähigkeit

  • da sich die Dokumentation wegen der häufigen Anpassungen auf den Code beschränkt, sollten beim der Refaktorisierung Struktur und Namensgebungen selbsterklärend sein

  • Wenn also Code existiert, welcher eines Kommentares bedarf, so sollte der Code angepasst/vereinfacht werden

• Nach der Refaktorisierung

  • sollten immer die Tests durchlaufen werden

    • sollten der Code wieder die geringstmögliche Anzahl Klassen, Attribute und Methoden aufweisen

    • Ständiger Fluss im Design

      => kontinuierliche Refaktorisierung

• Entwurf, Codierung und Tests von zwei Entwicklern gemeinsam

• Eine Tastatur, eine Maus, ein Rechner

• Rollenverteilung: Implementierer Rolle, Reviewer Rolle

• Bei Bedarf kann getauscht werden

• Paarbildung ist nicht fest, sondern geeigneten Partner suchen

  • Positiver Nebeneffekt: Wissen über alle Aspekte des System breitet sich über alle Entwickler aus (Ausfallsicherheit)

• Einer programmiert, der andere prüft

• Der Reviewer hat andere Ziele im Auge:

  • Fehler (logische und syntaktische)

  • Passt der Code zum Entwurf

  • Kann der Entwurf verbessert werden

  • Fehlen noch Tests zum Code

    => Kontinuierliche Begutachtung Aber: Kosten???

• Entwicklungszeit nimmt im Vergleich zu allein arbeitenden Entwicklern ca. 40 60% zu

• Code ist leichter verständlich und hat weniger Fehler (ca.60%)

Gemeinsames Code-Eigentum

• Der Code gehört nicht einem sondern allen Entwicklern

• Jedes Entwicklerpaar darf zu jeder Zeit am gesamten Code Änderungen vornehmen. Um z.B. die Verständlichkeit zu verbessern.

• Änderungen können aber fehlerhaft sein

• Deshalb müssen nach jeder Änderung alle Tests durchlaufen werden

Fortlaufende Code-Integration:

• Neuer oder geänderter Code wird alle paar Stunden integriert

• Auf einen dedizierten Integrationsrechner

• Alle Tests nach Integration durchlaufen

  • Bei Fehlern muss der Code vom Paar zurückgenommen werden

  • Fehler müssen von dem Paar beseitigt werden

    => Es besteht immer ein lauffähiges System

• Um das Arbeiten in Paaren und das gemeinsame Code Eigentum zu erleichtern

• Werden von den Entwicklern untereinander vereinbart und eingehalten Hat zur Folge, dass:

• der Code einheitlich ist

• ihn alle verstehen

• ihn alle ändern können

• Kosten beim Wasserfall (exponentiell) oder UP (linear)

Ausgangspunkt für diese Annahmen:

• Was kostet eine Änderung in der:

  • Analysephase

  • Designphase

• Implementierungsphase Im Gegensatz zu XP:

  • größerer Planungsaufwand (Analysephase)

  • Späte Implementierung/Codierung (Implementierungsphase)

• Nur ein einfaches Design erlaubt:

• Späteres Auftreten von Anforderungen

  • Kosten steigen nicht linear oder exponentiell

• Die geringen Kosten sind zu erklären durch

  • einfaches Design

  • automatisierte Tests

  • Erfahrungen im Ändern

  • den Einsatz von objektorientierten Sprachen

Neutral

• Wasserfall oder Unified Process sind schwergewichtig

• Keine bis wenig Flexibilität und Freiheit

• Änderungswünsche sind teuer und schwer realisierbar

Contra

• Explizite Spezifikation und Entwurfsdokumentation fehlen

  • Zwar ist Dokumentation im Test und im Sourcecode, jedoch kennen diese nur die Teammitglieder

  • Gemeinsames Code Eigentum wird zum Problem

    • kein Übersichtsdokument vorhanden ist

    • Änderungen am Entwurf müssen kommuniziert werden, es existiert kein Übersichtsdokument

    • konkurrierende Änderungen an denselben Klassen

• Annahme über Änderungskosten sind weder begründet noch empirisch belegt

• Wiederverwendbarkeit von Programmteilen

  • Änderungen am Entwurf ziehen Änderungen an den Tests nach sich

    • Sorgfältige Arbeit ist nötig

    • Reicht die Begutachtung des Pair Programmings aus?

    • QS wird in Frage gestellt

    • Vorgehensweise nicht „ISO 9000“ konform

    • XP selbst ist nur unzureichend dokumentiert

      • Die Systemmetapher wird z.B. nur kurz und knapp erwähnt

      • Keine Nachweise über die Überlegenheit von der Vorgehensweise von XP

Pro

• C3 Projekt bei DaimlerChrysler

• Berichte über andere Projekte bei Beck

  • Alle beteiligten Gruppen waren mit XP zufrieden

  • Hohe Motivation und Freude am Programmieren bei den Entwicklern

  • Gute Termineinhaltung im Management

  • Frühe Verfügbarkeit und hohe Qualität eines laufenden Systems beim Kunden

• Einsatz von XP ist nur möglich, wenn die Voraussetzungen erfüllt sind

• Es empfiehlt sich, XP nur bei kleineren Projekten mit unklaren oder sich ständig ändernden Anforderungen einzusetzen

• Aus Mangel an Erfahrungen wird noch kontrovers über

  • die Skalierbarkeit

  • die möglichen Projektgrößen diskutiert

• Scrum ist ein agiler Prozess , der es erlaubt auf die Auslieferung der wichtigsten Geschäfts Anforderungen innerhalb kürzester Zeit zu reagieren

• Scrum gestattet es schnell und in regelmäßigen Abschnitten (von zwei Wochen bis zu einem Monat) tatsächlich lauffähige Software zu inspizieren

• Der Kunde setzt die Prioritäten selbst

• organisierende Entwicklungsteams legen das beste Vorgehen zur Auslieferung der höchstpriorisierten Features fest.

• Alle zwei Wochen bis zu einem Monat kann jeder lauffähige Software sehen und entscheiden , diese so auszuliefern oder in einem weiteren Abschnitt zu ergänzen

Product Owner:

• Definiert Produkt Features

• Bestimmt das Auslieferungsdatum und den Inhalt

• Ist verantwortlich für das finanzielle Ergebnis des Projekts

• Priorisiert die Features abhängig vom Marktwert bzw . Kundenwunsch

• Passt die Features und die Prioritäten nach dem Bedarf für jeden Sprint an

• Akzeptiert oder weist Arbeitsergebnisse zurück

Scrum Master:

• Repräsentiert das Management gegenüber dem Projekt

• Verantwortlich für die Einhaltung von Scrum Werten und Techniken

• Beseitigt Hindernisse im Team und Projektablauf

• Er stellt sicher , dass das Team vollständig funktional und produktiv ist

• Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen

• Er schützt das Team vor äußeren Störungen

Das Team:

• Typischerweise 5 9 Personen

• Funktionsübergreifend

• Architekt , Programmierer , UI Designer, etc.

• Mitglieder sollten Vollzeitmitglieder sein

• Wenige Ausnahmen z.B . Systemadministratoren

• Teams organisieren sich selbst

• Ideal: keine Titel aber manchmal nicht vermeidbar

• Status im Team sollte sich nur zwischen Sprints verändern

Daily Scrum Meeting:

• Täglich

• 15 Minuten lang

• Stand up

• Nicht zur Problemlösung

• Alle sind eingeladen

• Aber nur Team Mitglieder, der ScrumMaster, und der Produkt Owner dürfen reden

• Hilft , andere überflüssige Meetings zu vermeiden

Sprint:

• Prüft regelmäßig , was gut und nicht so gut funktioniert

• Typischerweise 15 30 Minuten lang

• Nach jedem Sprint

• Das ganze Team nimmt teil

• ScrumMaster

• Produkt Owner

• Team

• Vielleicht Endkunden und andere Personen (aber Vorsicht!)

Review-Meeting:

• Das Team präsentiert , was es während eines Sprints erreicht hat

• Typischerweise in Form einer Demo der neuen Features oder der zugrunde liegenden Architektur

• Informell

• Zwei Stunden zur Vorbereitung Regel

• Keine Folien

• Das ganze Team nimmt teil

• Kunden sind anwesend , Mitglieder anderer Teams ggf. auch

Product Backlog:

• Eine Liste aller gewünschten Projektarbeiten Anforderungen

• Idealerweise soll jeder Eintrag wertvoll für Benutzer des Produktes oder Kunden sein

• Vom Produkt Owner priorisiert

• Zu Beginn jedes Sprints re priorisiert

Meeting Sprint-Backlog:

• Team Mitglieder wählen Tasks aus Arbeit wird nie zugewiesen

• Die geschätzte restliche Arbeit wird täglich aktualisiert

• Jedes Team Mitglied kann Tasks hinzufügen, löschen oder ändern

• Neue , für den Sprint benötigte Arbeit taucht auf

• Wenn Arbeit unklar ist , wird eine Task mit einer größeren Zeitschätzung definiert , um später die Aufteilung der Task durchzuführen (Product Backlog)

• Updaten der verbleibende Arbeit, sobald mehr Informationen vorhanden sind

• Entwicklung oder Gestaltung des Systems orientiert sich an identifizierten, beschriebenen und priorisierten Anwendungsfällen.

• Betonung auf den Funktionalitäten und Interaktionen des Systems mit den Benutzern.

• Anwendungsfälle dienen als zentrale Elemente für das Verständnis und die Umsetzung von Anforderungen.

• Fokussiert auf konkrete Szenarien, um das System benutzerorientiert zu gestalten

3 Arten von Anforderungen

1. Eine funktionale Anforderung definiert eine vom System oder von einer Systemkomponente bereitzustellende Funktion des betrachteten Systems.

2. Eine Qualitätsanforderung definiert eine qualitative Eigenschaft, die das betrachtete System oder eine einzelne Funktion des Systems aufweisen soll.

3. Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.

Qualitätsanforderungen:

• legen gewünschte Qualitäten des zu entwickelnden Systems fest

• beeinflussen häufig (in größerem Umfang als die funktionalen Anforderungen) die Gestalt der Systemarchitektur.

• Bezug auf Qualitätsanforderungen des betrachteten Systems

  • die Performance,

  • die Verfügbarkeit,

  • die Zuverlässigkeit,

  • die Skalierbarkeit

  • die Portabilität

Randbedingungen:

• können von den Projektbeteiligten nicht beeinflusst werden.

• beziehen sich auf das betrachtete System UND auf den Entwicklungsprozess des Systems.

• im Gegensatz zu funktionalen Anforderungen und Qualitätsanforderungen schränken sie die Umsetzung ein und werden nicht umgesetzt.

• Befragungstechniken

  • Interview

  • Fragebogen

• Beobachtungstechniken

  • Feldebeobachung

  • Apprenticing

• unterstützende Techniken

  • Mind Mapping

  • Prototypen

  • Use-Cases

• Dokumentenzentrierte Techniken

  • Systemarchäogolien

  • perspektivenbasiertes Lesen

• Kreativitätstechniken

  • Brainstorming

  • Perspektivwechsel

  • Analogiewechsel

Was ist Dokumentation:

• jede Art der mehr oder weniger formalen Darstellung,

• erleichter die Verständigung zwischen den einzelnen Beteiligten erleichtert

• erhöht die Qualität der dokumentierten Anforderungen

Natürlichsprachliche Dokumentation:

Vorteile

• in der Praxis die am häufigsten genutzte Dokumentationsform für Anforderungen

• Keiner der Beteiligten muss eine neue Notation lernen

• man kann alle Arten von Anforderungen ausdrücken

Nachteile

• oft mehrdeutig interpretierbar

• Bei der Wahrnehmung und der Darstellung treten Transformationsprozesse auf:

  • Wahrnehmung: jeder Mensch nimmt die Realität anders wahr und macht sich ein individuelles Bild davon.

  • Darstellung: Es erfolgt eine Umwandlung, sobald ein Mensch sein Wissen in Sprache ausdrückt.

Regeln um Darstellungstransformationen zu vermeiden:

• Nominalisierung

  • Durch die Nominalisierung wird ein (oft länger währender) Prozess zu einem (einmaligen) Ereignis gemacht

• Substantive ohne Bezugsindex

  • Substantive bergen ebenfalls die Gefahr der unvollständigen Spezifizierung.

  • Sprachliche Vertreter:

    „Der Anwender“, „das System“, „der Controller“,…

• Universalquantoren

  • Universalquantoren sind Angaben über Häufigkeiten

  • Sprachliche Vertreter:

    „nie“, „immer “, „kein“, „jeder“, „alle“, „irgendeiner“, …

• Unvollständig spezifizierte Bedingungen

  • Anforderungen enthalten Bedingungen, die nicht vollständig spezifiziert sind

  • Sprachliche Vertreter:

    „wenn … dann “, „falls“, „abhängig von“, …

• Unvollständig spezifizierte Prozesswörter

  • Manche Prozesswörter (Verben) erfordern mehr als ein Substantiv, um vollständig spezifiziert zu werden. Das Verb „übertragen“ benötigt zum Beispiel drei Ergänzungen:

    • was

    • von wo und

    • wohin

      übertragen wird.

• Durch die Nominalisierung wird ein (oft länger währender) Prozess zu einem (einmaligen) Ereignis gemacht

Definition

In der modellbasierten Dokumentation von Anforderungen werden typischerweise die drei Perspektiven Struktur, Funktion und Verhalten unterschieden. Jede Perspektive wird getrennt voneinander unter Verwendung geeigneter konzeptueller Modellierungssprachen dokumentiert.

Strukturperspektive

• Dokumentation der Struktur von Ein und Ausgabedaten oder die statisch strukturellen Aspekte von Nutzungs und Abhängigkeitsbeziehungen des Systems im Systemkontext

  • Entity Relationship Modell

  • UML Klassen Diagramm

  • Use Case Diagramm

Funktionsperspektive

• Dokumentation, welche Informationen aus dem Gesamtkontext durch das zu entwickelnde System bzw. dessen Funktionen manipuliert werden und welche Daten vom System in den Systemkontext fließen.

  • Datenflussdiagramm

  • (UML Aktivitätsdiagramm)

Verhaltensperspektive

• Dokumentation des Systems und dessen zustandsorientierte Einbettung in den Systemkontext, indem zum Beispiel die Reaktion des Systems auf Ereignisse oder Bedingungen eines Zustandswechsels beschrieben werden.

  • (UML Zustandsdiagramm)

  • UML Aktivitätsdiagramm

  • Ereignisgesteuerte Prozessketten

Use Cases

• Untersuchen und dokumentieren die Funktionalität eines geplanten oder existierenden Systems

• auf Basis einfacher Modelle

Use Case Diagramme

• leicht verständliche

• aus einer Nutzungssicht

• geben Überblick über

  • die Funktionalitäten des betrachteten Systems

  • deren Beziehungen untereinander

  • die Beziehung des Systems zu dessen Umgebung (Systemkontext)

Entity Relationship Diagramme

• modelliert die Struktur eines Betrachtungsgegenstandes

• in Form von Entitätstypen und Beziehungstypen

• (Ist eine mögliche Darstellung der Strukturperspektive)

Entität

Wohlunterscheidbares Objekt der realen Welt oder unserer

Vorstellung. Beispiele für Entitäten: Individuen, Gegenstände,

Begriffe, Ereignisse. Entitäten gleichen Typs bilden sog.

Entitätsmengen und besitzen zusätzlich bestimmte Merkmale.

Entitäten besitzen eindeutigen Identifikationsschlüssel.

Beziehung

stellt eine Verbindung zwischen Entitäten dar. Beziehungen

gleichen Typs bilden Beziehungsmengen und können zusätzlich

bestimmte Merkmale tragen.

Übungsaufgabe 5:

Sie werden beauftragt, für ein Busreiseunternehmen eine Datenbank zu entwickeln. Gehen Sie hierbei von folgendem Wirklichkeitsausschnitt aus, der abgebildet werden soll. Das Unternehmen bietet ausschließlich Städtereisen an. Für verschiedene europäische Städte existieren bestimmte Reiseangebote (jeweils genau eines), die Eigenschaften wie den Namen der Stadt, den (konstanten) Preis sowie die Reisedauer (Anzahl der Übernachtungen) besitzen. Für jede Stadt bzw. das entsprechende Reiseangebot existieren verschiedene terminliche Ausprägungen. Eine solche konkrete Reise wird jeweils von genau einem Busfahrer durchgeführt. Die Busfahrer des Unternehmens besitzen jeweils nur Kenntnisse für bestimmte Städte; dementsprechend besitzen sie nur die Fähigkeit zur Durchführung bestimmter Reisen. Die Kunden des Unternehmens sind ebenfalls in dem System abzubilden. Hierbei ist auch abzubilden, welche Kunden welche konkreten Reisen gebucht haben bzw. hatten.

Geschäftsprozessmodellierung

Beschreibung und Darstellung aller relevanten

Aspekte eines Geschäftsprozesses in einer

definierten Beschreibungssprache.

Ergebnis der Modellierung ist die modellhafte

Nachbildung der Realität

EPKs

• EPK sind eine weitverbreitete Modellierung smethode für Geschäftsprozesse

• EPK sind nicht automatisierbar

• Ereignisse sind nur verbal beschrieben

• Können für Verzweigungen nicht interpretiert werden

• nicht geeignet für Workflow Modellierung / Ablaufsteuerung

• EPK sind nur eingeschränkt geeignet für Simulation

• Probleme mit der Semantik der ODER Verknüpfungen

  • wie werden Entscheidungen getroffen

  • wann werden Entscheidungen getroffen

• Fehlende semantische Fundierung

• EPK für Modellierung auf Fachebene

• Prozessmodellierung wird in vielen Bereichen eingesetzt

• Sprachen zur Prozessmodellierung und ihre Herkunft

• Aus der Betriebswirtschaft:

• Ereignisgesteuerte Prozessketten (EPK

• BPML

• Aus der Mathematik:

  • (High level) Petri Netze

• Aus der Informatik / Softwareentwicklung:

  • Datenflussdiagramme

  • Acitivity Diagrams

Grundelemente der Prozessmodellierung:

• Ereignisse

• Funktionen

• Verknüpfungsoperatoren: UND, ODER, XOR

Ereignisse:

• Ereignisse lösen Funktionen aus

• Funktionen erzeugen Ereignisse

• Ein Ereignis beschreibt einen eingetretenen betriebswirtschaftlich relevanten Zustand eines Informationsobjektes, der den weiteren Ablauf eines Geschäftsprozesses steuert oder beeinflusst.

• Ereignisse referenzieren auf Informationsobjekte des Datenmodells.

• “Kundenanfrage geprüft” (6-Eck)

Funktionen:

• Eine Funktion ist eine fachliche Aufgabe bzw. Tätigkeit an einem (Informations-)Objekt zur Unterstützung eines oder mehrerer Unternehmensziele.

• Die Funktion ist Träger von Zeiten und Kosten.

• “Kundenanfrage prüfen” (4-Eck)

Prozesse:

• beginnen mit einem Ereignis und

• enden in einem/mehreren Ereignissen

Zur Ablaufbeschreibung sind Kontrollstrukturen erforderlich.

Sequenz:

• Festlegung der Reihenfolge

Parallelität

• gleichzeitig zu bearbeitende Aktivitätsstränge

Verzweigung

• Unterschiedliche Wege in Abhängigkeit von Variablen

^ = UND-Verknüpfung: Parallelität

v = ODER-Verknüpfung: eine oder die andere Alternative

XOR = Entweder-Oder-Verknüpfung: genau eine Alternative

Objekt

• Objekte sind dadurch charakterisiert, dass sie

• einen Zustand (Datenaspekt) besitzen,

  • wird durch Attributwerte beschrieben

• ein Verhalten zeigen (Handlungsaspekt) und

  • wird durch seine Operationen (operations) oder

  • Methoden (methods) festgelegt

• eine Identität (als Ausprägung einer Klasse) haben

  • unterscheidet dieses Objekt von allen anderen Objekten

Objektidentität

• Zustand und Verhalten bilden eine Einheit

• die Daten eines Objekts können nur mit Hilfe der Operationen gelesen und geändert werden.

• Die Objektidentität wird bei der Implementierung durch einen Algorithmus realisiert, der Eindeutigkeit garantiert.

Objekte:

• Repräsentieren die konkreten Daten, die später von der Anwendung verwaltet werden

Klassen:

• Wichtig für die Modellierung, um Schablonen zu definieren, mit deren Hilfe später Objekte erzeugt werden können

Eine Klasse ist ein Muster für den Aufbau von Objekten

Attribut:

• Attribute beschreiben die Daten, die von den Objekten einer Klasse angenommen werden.

• Jedes Attribut ist von einem bestimmten Typ .

• Alle Objekte einer Klasse besitzen die selben Attribute, jedoch unterschiedliche Attributwerte.

Wie die Komponenten zusammenhängen nennt man Assoziation

Prinzipien:

• Vererbung

• Polymorphismus

• Datenkapselung und Geheimnisprinzip

Vererbung

• Jede Klasse erbt die Attribute und Operationen der darüber liegenden Klasse, diese wird als Superklasse (oder Oberklasse) bezeichnet.

• Jede darunter liegende Klasse heißt Subklasse (oder Unterklasse).

• Eine Superklasse kann ihre Attribute und Operationen an mehrere Subklassen vererben.

• Jede Subklasse besitzt jedoch i.d.R. zusätzliche Attribute und/oder Operationen.

Spezialisierung vs. Generalisierung

• bei der Bildung der Klassenhierarchie

• Generalisierung (führt zu Superklassen)

  • bottom up

    • Einfachvererbung oder Mehrfachvererbung

      • Vorteile:

        • Verringerung von Redundanzen

        • Vereinfachung der Wartung des Systems

• Spezialisierung (führt zu Subklassen)

• top down

Beispiel zur Einfachvererbung

Die Subklassen Debitoren und Kreditorenkonto der Finanzbuchhaltung erben nur von einer Superklasse, nämlich der Klasse Personenkonto.

Die Subklasse Personenkonto wiederum erbt (zusammen mit der Subklasse Sachkonto) ebenfalls nur von einer Superklasse, und zwar der Klasse Konto.

= „Vielgestaltigkeit“

• Bedeutet, ein und die selbe Nachricht an Instanzen unterschiedlicher Klassen zu senden.

• Im Umkehrschluss wird eine gleichnamige Methode in verschiedenen Klassen angewendet.

• Unterschiedliche Verarbeitungsschritte können durch die selbe Nachricht ausgelöst werden.

Vererbung erzeugt Polymorphie:

• Superklasse definiert generische Methoden

• Unterklassen überschreiben Methoden

• Schnittstelle und Semantik der Methoden bleibt erhalten

• Wiederverwendbarkeit

• Attributwerte eines Objektes können nur mit Hilfe von Methoden gelesen und geändert werden

• Die Repräsentation dieser Attributwerte (Daten) soll nach außen verborgen bleiben

• Ein Objekt realisiert also das Geheimnisprinzip

• Vergleichen Sie diesen Ansatz mit dem ERM bzw. die Umsetzung dieser Modelle in relationale Datenbanksysteme

(ich hab ehrlich auch keine Ahnung, was es sagen soll)

Klassen

• bestehen aus

  • Klassenname

  • Attributen

    • beschreiben Daten

  • Methoden/Operationen

    • definieren das Verhalten

Assoziationen

• Der Assoziationsname spezifiziert die Semantik der Beziehung

• Die Multiplizität spezifiziert die Stelligkeit der Beziehung, d.h. wie viele Objekte der einen mit wie vielen Objekten der anderen Klasse in Beziehung stehen

  ->spezifiziert die „Leserichtung“

Klassendiagramme

• Diagramme mit der Beschreibung von Klassen mit ihren

  • Vererbungsbeziehungen

  • Assoziationsbeziehungen

  • Aggregationsbeziehungen („Strukturdiagramme“)

• Modellierung der Dynamik von einzelnen Anwendungsfällen

• mehrere Handlungsstränge mit mehreren beteiligten Objekten

• Darstellung paralleler, unabhängiger Abläufe

• Fokus auf Aktivitäten

  • Aktivitäten sind Zustände

    • mit einer internen Aktivität

    • und einem oder mehreren Zustandsübergängen

Beinhaltet:

• Objekte

• Lebenszeiten von Objekten

• Nachrichten zwischen Objekten

• Kontrollfluss

Fokus:

• Kommunikation zwischen mehreren Objekten

• graphische Darstellung zeitlicher Abläufe der Interaktion

• zeigt Reihenfolge von Nachrichten

• beteiligte Objekte als Spalten

  • graue Balken zeigen aktive Objekte bzw. Steuerungsfokus

  • Hinzufügen von Objekten möglich

  • gestrichelte Lebenslinie zeigt Lebenslinie des Objektes

  • Zerstörung des Objektes durch X an Lebenslinie gekennzeichnet

  • Nachrichten als Pfeile zwischen den Lebenslinien der Objekte

• zeitliche Abfolge der Nachrichten von oben nach unten