entwicklungsprozess - dhbw stuttgartrie/aswe/aswe10 entwicklungsprozess.pdf · workflow „analysis...

DHBW Stuttgart, Informatik, Advanced SW-Engineering Nov 2017

Seite 1

Entwicklungsprozess

Inhalt

• RUP (Rational Unified Proces)

– von der IBM entwickelt

– objektorientiertes Vorgehensmodell

– benutzt UML (Unified Modeling Language)

• 9 Workflows mit ihren Artefakten (Dokumentationen)

Ein paar kritische Anmerkungen zum RUP:

https://www.mathematik.uni-marburg.de/~hesse/papers/Hes_00a.pdf

Christoph Riewerts

Erläuterungen:

https://de.wikipedia.org/wiki/Rational_Unified_Process


Seite 2

Entwicklungsprozess (RUP)

Process Workflows

Supporting Workflows

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Iterationen umfassen jeweils alle Workflows einer Phase


Seite 3


Dokumenttypen (obligatorische in Fettschrift):

• Vision (grober Überblick ohne Details): Stakeholder (Beteiligte, Benutzer), Problemdefinition,

Produkteigenschaften, grobe Anforderungen, Risiken, Glossar

• Requirements Management Plan: Business Cases (Geschäftsprozesse), Use Cases

(Anwendungsfälle, Verhalten des Produkts), Priorisierung der Use Cases, Dokumentation der

Anforderungen

• SRS, Software Requirements Specification (Pflichtenheft): Anforderungen, Use Cases, Class

Diagram, Priorisierungen

• SDP, Software Development Plan (Projektplan): Organisation, Ressourcen, Aktivitäten,

Monitoring, Meilensteine, Risikomanagement

• SAD, Software Architecture Document: Überblick zur Architektur des Systems

• Design Model: Komponenten, Schnittstellen, wichtige Klassen, Datenmodell

• Implementation Model: Packaging, Integration, Deployment

• CM, Configuration Management: Konfiguration, Versionskontrolle, Change Requests (CR)

• Test Model: Akzeptanzkriterien, Testfälle, Ausführung

• Deployment Plan: Umgebung, Hardware, Softwarekomponenten, Dokumentation, Wartung,

Schulung


Seite 4


Häufig reduziert sich die Anzahl der notwendigen Dokumente; für die Semesterarbeiten

werden 2 Dokumente gefordert, die um Kapitel aus anderen Dokumentationen ergänzt

werden:

Software Requirements Specification (SRS, Pflichtenheft):

Anforderungen,

Use Cases,

Class Diagram,

Datenmodell (aus dem Design Model),

Testfälle und Ausführung (aus dem Test Model)

Software Development Plan (SDP, Projektplan):

Projektorganisation

Ressourcen

Aktivitäten (Planung) incl. Aufwände

Monitoring (Istwerte)

Meilensteine

Risikomanagement


Seite 5


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 6

Entwicklungsprozess (RUP)Business Modeling

liefert

Geschäftsprozesse

Nur zur Entwicklung von Software wird dies häufig nicht gemacht, sondern im

Workflow „Analysis & Design“ werden die Prozesse, die implementiert werden, im

Detail modelliert und als Analyse-Modell dokumentiert.

Zur grafischen Darstellung und Modellierung wird die „Business Process Model and

Notation“ (BPMN) verwendet:

https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation


Seite 7


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 8

Entwicklungsprozess (RUP)Requirements

liefert

Funktionale Anforderungen mittels Use Cases

Nichtfunktionale Anforderungen, z.B. an wesentliche Qualitätskriterien:

an die Verfügbarkeit

an die Ergonomie

an die Performance

an die Wartbarkeit


Seite 9

Funktionale Anforderungen (Funktionen und Daten) werden häufig aus der

Aufgabenbeschreibung bzw. aus dem Lastenheft kopiert. Ziel: Jede

funktionale Anforderung wird bei den Requirements als Use Case (s. UML)

spezifiziert mit folgenden Inhalten:

– Kurze Ablaufbeschreibung

– Input und Output

– Auslösendes Ereignis

– Durchführender

Bei komplexen Abläufen kommen zusätzlich das Aktivitätsdiagramm und das

Zustandsdiagramm der UML zum Einsatrz.

EntwicklungsprozessRequirements


Seite 10

Use case Titel: Auftrag ausführen Nummer: FREQ 21

Kurzbeschreibung (Ziel): Ware an Kunde geliefert

Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung

Auslösendes Ereignis: Bestellung des Kunden liegt vor

Vorbedingung: Bestellung

Nachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei

Buchhaltung

Nachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbar

Standardablauf: 1. Kundendaten abrufen

2. Lieferbarkeit prüfen

3. Rechnung erstellen

4. Auftrag vom Lager ausführen lassen

5. Rechnungskopie an Buchhaltung geben

Erweiterungen: 1a. Kundendaten aktualisieren

Alternativen: 1a. Neukunden erfassen

3a. Rechnung mit Nachnahme erstellen

3b. Rechnung mit Bankeinzug erstellen

Beispiel für ein Use Case

EntwicklungsprozessRequirements


Seite 11

Die Verfügbarkeitsanforderungen gelten für die Nutzung des Gesamtsystems (Hard- und

Software) durch den Endanwender.

Zur Vereinfachung der Spezifikation werden Leistungsanforderungen häufig kategorisiert

und müssen dann nur noch projektspezifisch ausgewählt werden (Angaben beziehen

sich auf einen Zeitmonat mit 30 Tagen/Monat und 24 Stunden/Tag):

Kategorie Zeitl. Verfügbarkeit Max. Ausfalldauer Max. Anzahl Ausfälle

A 99,75 % 30 Min. 4

B 99,5 % 3,6 Std. 4

C 99 % 7 Std. 10

D 98 % 14 Std. 10

Die Erfüllung der Verfügbarkeit wird im praktischen Betrieb über einen festgelegten Zeitraum

(z.B. 2 Monate vor Ablauf der Gewährleistungszeit) ermittelt.

EntwicklungsprozessRequirements (Verfügbarkeit)


Seite 12

Vorgabe eines Style-Guides, der verwendet werden muss.

Empfehlung: Grundsätze der Dialoggestaltung gemäß ISO 9241 sollen implementiert

werden.

– Aufgabenangemessenheit: Ist es möglich, wiederholtes Eingeben zu

vereinfachen? …

– Selbstbeschreibungsfähigkeit: Sind alle Systemmeldungen verständlich? …

– Steuerbarkeit: Können Sie bei Bedarf eine Aufgabe unterbrechen? …

– Erwartungskonformität: Sind Sie bei Wartezeiten sicher, dass das Programm

arbeitet? ...

– Fehlertoleranz: Bekommen Sie bei fehlerhaften Eingaben Korrekturhinweise?...

– Individualisierbarkeit: Können Sie das Programm so einstellen, dass das Arbeiten

leichter fällt? …

– Lernförderlichkeit: Ermöglicht Ihnen das Programm, etwas gefahrlos aus zu

probieren? …

Hier gibt’s mehr Infos:

http://www.scoreberlin.de/usability-artikel/usability-iso-norm/

EntwicklungsprozessRequirements (Ergonomie)

http://www.scoreberlin.de/usability-artikel/usability-iso-norm/


Seite 13

Das Antwortzeitverhalten eines Systems wird häufig in vier Kategorien eingeteilt. Eine

projektspezifische Festlegung könnte dann folgendermaßen aussehen:

Kategorie < 1,5 Sek < 2,5 Sek < 10 Sek

A 98 % 100 % 100 %

B 85 % 95 % 99 %

C 60 % 85 % 98 %

D 50 % 70 % 90 %

Die Erfüllung des Antwortzeitverhaltens wird im praktischen Betrieb über einen festgelegten

Zeitraum (z.B. 2 Monate vor Ablauf der Gewährleistungszeit) ermittelt.

Für häufig benötigte

Dialoge (Rückmeldungen,

Info-Funktionen)

für Dialoge mit

Transaktionen

(Terminplanung,

Stammdatenauskunft)für umfangreiche

Transaktionen

EntwicklungsprozessRequirements (Performance)


Seite 14

Welches Qualitätsmodell (Metriken) liegt zugrunde?– Klassische Metriken: Kommentarverhältnis, McCabe-Komplexität, ..– Für die Objektorientierung existieren weitere Metriken:

DIT: Je größer die Vererbungstiefe, desto größer die Fehlerwahrscheinlichkeit (FW)NOC: Je größer die Anzahl Subklassen einer Klasse, desto geringer die FWWMC: Je größer die Anzahl Methoden und Operatoren einer Klasse, desto größer

die FW

Welche Programmierrichtlinie ist zu verwenden?– Bei JAVA bieten sich die Code Conventions (Sep/97) von SUN an– für C# bietet Microsoft entsprechende Richtlinie an

Sind spezielle Entwurfsmuster oder getestete Komponenten (Reuse) aus anderen Systemen zu verwenden?

Welche Architektur-Standards sind einzusetzen, z.B. Vorgabe einer Referenzarchitektur oder eines Ebenenkonzept?

Welche Produkte sind vorgeschrieben für die Entwicklung?

Nachweis durch den Einsatz eines Source Code Analyse Tools, z.B. checkstyle

EntwicklungsprozessRequirements (Wartbarkeit)


Seite 15


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 16

Entwicklungsprozess (RUP)Analysis & Design

liefert

UML-Diagramme:

Klassendiagramm

Use Case Diagramm

Aktivitätsdiagramm

Zustandsautomat

Komponenten Diagramm


Seite 17

Der iterative OOA-Modellbildungsprozess besteht aus folgenden Aufgaben

• Analyse der relevanten Geschäftsprozesse

• Ableiten von Klassen aus den Geschäftsprozessen

• Erstellen des statischen Modells

• Parallel dazu Erstellung des dynamischen Modells

• Berücksichtigung der Wechselwirkungen beider Modelle.



Seite 18

Erstellen des statischen Modells

• Klassen identifizieren

– Für jede Klasse nur so viele Attribute und Operationen identifizieren wie für das

Problemverständnis und das identifizieren, wie für das Problemverständnis und das einwandfreie

Erkennen der Klasse notwendig sind.

• Assoziationen identifizieren

– Zunächst nur die reinen Verbindungen eintragen, d. h. noch keine genaueren Angaben, z. B. zur

Kardinalität oder zur Art der Assoziation machen.

• Attribute identifizieren

– Identifizieren aller Attribute des Fachkonzepts.

• Vererbungsstrukturen identifizieren

– Aufgrund der identifizierten Attribute Vererbungsstrukturen erstellen.

• Assoziationen vervollständigen

– Endgültig festlegen, ob eine »normale« Assoziation, Aggregation oder Komposition vorliegt sowie

Festlegung der Kardinalitäten, Rollen, Namen und Restriktionen.

• Attribute spezifizieren

– Für alle identifizierten Attribute eine vollständige Spezifikation erstellen.

• Muster identifizieren

– Das Klassendiagramm daraufhin überprüfen, ob Muster enthalten sind und diese richtig modelliert

wurden.



Seite 19

Erstellen des dynamischen Modells (Systemverhalten):

• Use Case Diagramm liefert die funktionelle Gliederung mit Angabe der Ein- und Ausgaben in

jedem Use Case (Kontext-Diagramm gibt es leider nicht in der UML)

• Use Cases ggfs. ergänzen durch Activity- und State-Diagramme (Zustandsautomaten)

Berücksichtigung der Wechselwirkungen beider Modelle

• Use Cases werden umgesetzt in Methoden von Klassen

• Ein- und Ausgaben werden umgesetzt in entsprechende Attribute von Klassen

• Akteure werden Klassen

Zu beachten

• Falls keine 1:1-Umsetzung sinnvoll ist, dann ist dies explizit zu dokumentieren, z.B. durch eine

Zuordnungs-Matrix „Use-Case zu Methode“

• Zuordnung Klassen zu Methoden frei wählbar

• Konsistenz wird erreicht durch Namensgleichheit und richtige Schreib- bzw. Leserichtung bei den

Daten



Seite 20

Erstellen des Design-Modells (aus dem OOA-Modell):

• Anpassung der Namen im Hinblick auf die Zielsprache

• Konsequenter Einsatz der Stereotyp-Bezeichnungen: <<stereotyp>>

• Konsequenter Einsatz von Bezeichnern für Klasseneigenschaften: {property}

• Definition von Container-Klassen, sofern noch nicht gemacht

• Definition von Schnittstellen-Klassen

• Festlegen der Sichtbarkeiten, sowohl für Attribute als auch für Operationen

• Vervollständigen der Signatur der Operationen

• Definition von abstrakten Operationen

• Angabe der Navigation bei den Assoziationen/Aggregationen

• Konkretisieren der Vererbung (Polymorphismus, Mehrfachvererbung)

• Definition von Paketen, sofern noch nicht gemacht



Seite 21

Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements



Entwicklungsprozess (RUP)Implementation


Seite 22

Entwicklungsprozess (RUP)Implementation

liefert

Anforderungen an die technische Realisierung

– Aussagen zur benötigten Hardware incl. Betriebssystem

– Aussagen zur verwendeten Programmiersprache

– Aussagen zum Einsatz von Fremdprodukten, Opensource-Produkten

– Aussagen zu den verwendeten Protokollen bei verteilten Subsystemen

Packaging

Source Code


Seite 23


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 24

Entwicklungsprozess (RUP)Test

liefert

Dokumentation der Testfälle für white box Testing

Dokumentation der Testfälle für black box Testing

white box Testing

• Programmtext als Ausgangspunkt der

Testdatenermittlung

• möglichst viele Programmabläufe

werden ausgeführt

• unterschiedliche Überdeckungen

werden angestrebt (C0, C1, …)

• Programme können getestet werden,

für die keine Spezifikation vorliegt

black box Testing

• Spezifikation des Testobjekts als

Ausgangspunkt der Testdatenermittlung,

• Testdaten werden in Klassen eingeteilt,

bei jedem Repräsentant einer Klasse

verhält sich das Testobjekt gleich

• Qualität der Testdaten hängt ab von der

Aussagekraft der Spezifikation

Zur Erinnerung: Anforderungen an das Testen müssen Bewertungsmaß, Erhebungsart

und Erfüllungsmaß enthalten.


Seite 25


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 26

Entwicklungsprozess (RUP)Deployment

liefert

Installationsanleitung

deployment diagram (Zuordnung von Artefakten, z.B. von Software-

Komponenten, auf Hardware-Einheiten) :

Beispiele:


Seite 27


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 28

Entwicklungsprozess (RUP)Configuration Mgmt

liefert

Angaben

• zu Konfiguration,

• zur Versionskontrolle und

• zu Change Requests


Seite 29


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 30

Entwicklungsprozess (RUP)Management

Liefert

Meilensteinplan

Projektstruktur

Reporting

Kommunikation zw. Auftraggeber und Auftragnehmer

Risikomanagement

Aufwandsplanung und –kontrolle

Unter Management wird hier im wesentlichen das Projekt-Management verstanden.

Bei Einsatz von Scrum wird im SDP folgendes dokumentiert (alle 2 Wochen

aktualisiert):

Zusammensetzung des Teams

User Stories (Produkt Backlog)

Tasks mit Verantwortlichem, Zeitdauer, Aufwand (Sprint Backlog)


Seite 31


Process Workflows


Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter.#1

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements




Seite 32

Entwicklungsprozess (RUP)Environment

Liefert

Beschreibung und Einsatz der Entwicklungsumgebung

Für die Android-Plattform ist zur Zeit die leistungsfähigste Entwicklungsumgebung

(IDE) unter https://developer.android.com/studio/index.html

herunterladbar („Android Studio“).

Anleitung dazu:

https://www.youtube.com/watch?v=Z98hXV9GmzY

https://developer.android.com/studio/index.html

https://www.youtube.com/watch?v=Z98hXV9GmzY

entwicklungsprozess - dhbw stuttgartrie/aswe/aswe10 entwicklungsprozess.pdf · workflow „analysis...

Documents