• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/171

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

171 Cards in this Set

  • Front
  • Back
Ziele von Case - Allgemein
Allgemein:
-Unterstützung der Software Entwicklung durch Werkzeuge für
-Konstruktion
-Analyse
-Management
-Effizienz- / Produktivitätsgewinn
-Qualitätsverbesserung
-Erleichterung des Managements
Ziele von Case Detailziele: Technisch
Technisch:
-Automatisierung von Entwicklungsaktivitäten
-Methoden für Konsistenz und Redundanzprüfungen
-Verbesserung der Qualität der Dokumentation
-Erleichterung der Wiederverwendbarkeit
-Verwalten von Konfigurationen und Änderungen
-Messen und Bewerten
Ziele von CASE - Wirtschaftlich
Wirtschaftlich:
-Erhöhung der Effizienz
-Schnellere Entwicklung von Produkten (Time-To-Market)
-Erhöhung der Qualität von Produkten
-Reduzierung des Wartungsaufwandes
-Verringerung der Personenabhängigkeit
Ziele von Case - Detailziel: Organisatorisch
Organisatorisch:
-Unterstützung des gewählten Prozesses
-Präzisierung der Entwicklungsmethoden
-Erhöhung der Standardisierung
-Jederzeitige Information über den Soll-/Ist-Stand
-Anpassung an geänderte Rahmenbedingungen
CASE-Ansatz
Ein reifer Entwicklungsprozess lässt sich effektiver durch Werkzeuge unterstüzten, da einzelne Aktivitäten klar definiert sind und Ein- und Ausgabeartefakte spezifiziert sind.
Definition: CASE-Tool
Ein CASE Werkzeug ist ein Software-Produkt, welches mindestens eine einzelne bei der Softwareerstellung benötigte Aktivität unterstützt bzw. automatisiert
CASE-Framework
Eine CASE-Plattform bzw. ein CASE Framework stellen einen Rahmen für die Integration von CASE-Werkzeugen in eine CASE-Umgebung dar.
CASE-Workbench
Ein CASE-Workbench besteht aus einer geringen Anzahl an CASE-Tools mit oft geringer Integration
CASE - Rahmenbedingungen
CASE darf den Entwickler nicht belasten, sondern soll Routine-Aufgaben erleichtern bzw. abnehmen. Damit soll die Konzentration auf kreative Arbeiten gefördert werden.

Eine Einführung von Werkzeugen führt nicht zwangsläufig zur Verbesserung (A fool with a tool is still a fool.

Ein guter Softwareingenieur wird schneller gute Software erstellen ein schlechter, schneller noch schlechtere Software.

Es müssen also Methoden eingeführt werden, die dann sinnvoll von Werkzeugen unterstützt werden.
Klassifikation von CASE Allgemein
-Prozessperspektive
-Einordnung bezüglich der Prozessschritte oder -phasen, die unterstützt werden
-Funktionale Perspektive
-Einordnung bezüglich der unterstützten Art der Funktion bzw. Entwicklungsaktiviät
-Integrationsperspektive
-Einordnung nach dem Grad der Integration (Umfang der unterstützten Prozessschritte /-fragmente)
CASE Klassifikation: Prozessperspektive
-Je nach Schwerpunkt der Unterstützung existieren verschiedene Kategorien
CASE-Klassifikation: Funktionale Perspektive
Codierung (Lower-CASE)
-Eingabe (Editor)
-Übersetzung (Compiler)
Analytische Qualitätssicherung
-Test
-Debugging
-statische / dynamische Analyse
-formale Verifikation
Modifizierung /Spezifikation UPPER-CASe
-Modellierung / Spezifikation (Upper-CASE)
-Zustandsautomaten
-Funktionen
-Objekt-Orientierte Modelle: UML, SDL
-Requirements-Engineering und Management (Upper-CASE)
CASE-KLassifikation:
Funktionale Perspektive & Bezug zu Prozessperspektive
-Prototyping und Simulation (Upper-CASE)
-Code-Generierung (Übergang Upper- zu Lower-CASE)
-Reverse Engineering (CARE)
-Versions und Konfiguarionsverwaltung, Änderungsmanagement (I-CASE)
-Planung (I-CASE)
-Dokumentation
Historische CASE Werkzeug Entwicklung
traditionelle Entwicklungstechniken(Implementierung von Hand)
-Werkzeuge zur Generierung von Werkzeugteilen
Aktuelle CASE Werkzeugentwicklung
- modellbasierte CASE-Toolentwicklung
-Generierung von Werkzeugen bzw. Werkzeugteilen aus Modellen
Typische Probleme: #1 Einlesen von Eingangsartefakten
Beispiele:
-Programm-Code
-Konfigurationsdokumente (z.B. XML)
-Eingangsartefakte haben typischerweise ein vorgegebenes Format bzw. eine vorgegebene Struktur (Textdokumente)
-Ergebnis des Einlesens ist interne Repräsentation (Datenstruktur) für die Bearbeitung durch ein Werkzeug

Fragestellung: Kann man Code für die Aktivität „Einlesen“ generieren?
Lösung: Parser Generator
Parser-Generatoren
Ziele: Automatische Erstellung von Code zum Einlesen von Artefakten mit gegebener Struktur (Syntax), Überprüfung auf Einhaltung der Struktur und zum Überführen in eine interne Datenstruktur

Parser-Generatoren sind bereits „seit langem“ verbreitet und werden vor allem im Compiler-Bau verwendet.
Hintergrundwissen Parsergeneratoren
Grafik
Allgemeiner Ansatz: Parsergeneratoren
Grafik
Backus-Naur-Form (BNF)
Die BNF ist eine Notation zur Beschreibung der Produktionsregeln einer Kontextfreien Grammatik.
Parsevorgang
Der Parsevorgang besteht aus drei Bestandteilen, die nun näher erläutert werden.
1.Lexikalische Analyse
a.Gruppierung einzelner Zeichen zu „Tokens“
b.Elimination von „Whitespaces“
2.Syntaxanalyse
a.Gruppierung der Token zu „grammatikalischen“ Einheiten
b.Angrenzung zur lexikalischen Analyse ist z.T. willkürlich
i.z.B getrieben durch Effizienzgründe oder einfacherer Umgang mit den Parseergebnissen
1.z.B. zusammenfassung von Ziffern und Zahlen
c.Repräsentation als Parse-Baum bzw AST (interne Datenstruktur)
3.Semantische Analyse
a.Überprüfung auf „semantische Fehler“ z.B.
i.Type-Checking (Zuweisung eines Ausdrucks entspricht Datentyp der Variablen
ii.richtige Indizierung eines Arrays (z.b. nicht mit Real)
Parse-Baum
Die Wurzel des Baums ist immer das Startsymbol Z. Alle Blattknoten sind Terminalsymbole. Alle internen Knoten sind Nichtterminalsymbole
Abstract Syntax Tree (AST)
-Parse-Bäume reflektieren „Struktur“ der konkreten Syntax
-ASTs Spiegeln abstrakte Syntax wider
-abstrahieren von der konkreten Darstellung und machen die Bearbeitung der internen Datenstruktur einfacher
Typische Probleme: #2 Darstellung der Daten und Reaktion auf Benutzereingaben
Visualisierung der internen Datenstrukturen des Werkzeugs
-Möglichkeit für (grafische Benutzereingaben und Modifikationen der internen Datenstrukturen)

Ziele: Erstellung von grafischen Benutzeroberflächen ohne „manuelle Programmierung“
-Eingabe durch Klicken
-Auswahl der Widget aus einer Palette
Model View Controller
Der View beinhaltet die graphische oder textuelle Ausgabe. Der Controller interpretiert die Maus und Tastatureingaben und verarbeitetet die Programmlogik. Das Model verwaltet die Daten (auf Anweisung des Controllers)
Model-View-Controller Statechard
Typische Probleme #3: Erzeugung von Ausgangsartefakten
-Überführung der internen Datenstruktur in lesbare Ausgabedokumente (Textdokumente)
-Beispiele
-Ausgangsartefakte haben typischerweise ein vorgebendes Format/Struktur

Fragestellung: Generierung von Code für die Aktivität „Ausgaben?“
Lösung: Template-Engines
Template Engines
Ziel: Erzeugung von Dokumenten mit einer vorgegebenen Struktur auf der Basis von Templates. Ein Template ist ein Dokument mit Platzhaltern für konkrete Daten
Template Sprache
-Beschreibung der Templates und insbesondere der Platzhalter
-unterstützen
-Suchen und Ersetzen
-Komplexere Anfragen
-Iterationen
Template Engine Allgemeiner Ansatz:
-Java Server Pages
-Velocity - Java basierte Template Engine
-Java Emitter Templates
-Untermenge von JSP
-Teil von EMF Eclipse
-wird genutzt um Java-Code ausgehend von Modellen zu generieren
JET Konzepte
Zwischenschritt: Generierung von Template Klassen
-Template Klassen übernehmen das Erzeugen der eigentlichen Ausgabe zur Laufzeit
-Effizienzgewinn durch Kompilation
Zusammenfassung der Allgemeinen Probleme
Grafik
Probleme bei Werkzeugintegration
-Kombination der einzelnen Tools zu Workbenches oder Umgebungen (Upper-/Lower-/I-Case) oft schwierig
-Beispiel RE Tool zu Design-Tool (wenn beide Tools unschiedliche Methoden unterstützen)
-fehelen Zwischenschritte oder Überlappung von „Funktionen“/“Diensten“ (von einem Tool automatisierten Aktivitäten)
-Bsp: zwei Tools jeweils eigener Versionsverwaltung
-fehlende „standardisierte“ Prozeduren und Mechanismen für die Übertagung von Daten von einem Werkzeug zum anderen und die Synchronisation der Aktivitäten zwischen den Tools
-PDF->Word
-mangelnde Übersicht über den Gesamtforschritt der Aktivitäten und die Zwischenschritte von Artefakten, welche produziert wurden
-hoher Aufwand in der Systemadministration (Installation, Betrieb, ...)
-Bsp: Standard-Software unter Windows
Wassermannmodell Integrationsebenen
Plattformintegration
Oberflächenintegration
Datenintegration
Steuerungsintegration
Prozessintegration
Wassermann-Modell: Plattformintegration
-Werkzeuge laufen auf der selben Plattform (Hardware- und Software)
-Bsp: Portierung der UNIX-Tools für Windows

- Definition:
- einzelner Rechner
- über ein Netzwerk verbundene Workstations/Arbeitsplätze (typischer Fall)

- Betriebssysteme
- Mac OS X, Windows, Linux
Wassermann-Modell: Oberflächenintegration
-Werkzeuge besitzen dasselbe Look-and-Feel
- Ziele:
- Verringerung des Lernaufwands für ein neues Tool - werden erreicht durch
- gleiches Erscheinungsbild aller Tools - z.B. identische „Knöpfe“
- gleiche Kommandos
- z.B. File->Load
- gleiche Metaphern
- z.B. Papierkorb, Karteischrank
- Integration auf Ebene des Windowing-Systems

- Tools benutzen alle das Selbe Windowing-System
- Tools besitzen identische Fenster oder auch identische Widget (Fenster +
Bildauflieisten,Buttons, ...)
Wassermann-Modell: Datenintegration
-Daten lassen sich zwischen den Werkzeugen austauschen
-Bsp: XML

- Ziele:
- Unterschiedliche Werkzeuge können
- Daten austauschen
- bzw. gemeinsam darauf zugreifen -
Hauptfragen der Datenintegration: - Austausch von Daten
- Welche Daten werden gespeichert?
- d.h. persistente vs nicht-persistente Daten
- Wo werden die Daten gespeichert?
- Wie erfolgt der Zugriff auf die Daten? - Semantische Mechanismen
- Inwiefern besitzen die Tools ein gemeinsames „Verständnis“ der Daten?
- Welche Mechanismen werden zur Unterstützung des Gemeinsamen Verständnisses verwendet?
- Ansätze:
Werkzeugintegration: Steuerungsintegration
-Dienste eines anderes Werkzeuges lassen sich aufrufen
-Tool kann von anderem Werkzeug über Ereignisse benachrichtigt werden
Wassermann-Modell: Prozessintegration
Zusammenarbeit der Tools im Rahmen eines definierten Prozesses
-CASE Umgebung kennt Prozessmodell
Wassermann-Modell: Probleme nach Brown
Das Wassermann-Modell hat nach Brown aber auch einige Probleme, so sind die Dimensionen nicht unbedingt orthogonal, somit können Sie nicht immer unabhängig voneinander betrachtet werden.
Beispiel: Daten- und Steuerungsintegration
-Einschränkung des Datenzugriffs ist eine Form der Steuerung
-Nachrichtenaustausch zwischen Werkzeugen beinhalten i.d.R. auch Daten (Informationen)

Ebenso impliziert eine Zunahme entlang der Achsen nicht unbedingt eine Verbesserung
So werden die Techniken zwar ausgefeilter, aber nicht notwendigerweise die Übereinstimmung bzgl. der „Semantik“

Beispiel: Datenintegration
-File (XML) kann mehr „semantische“ Information tragen als Datenbank (mit nur einer einzelnen Tabelle)
Brown Modell: Allgemein
„Three Level Conceptual Model“
Brown-Modell:End-User Services
abstrakte Beschreibung der Funktionalität (Dienste)
-Integration beschreibt, wie diese Dienste auf abstrakter Ebene zusammenarbeiten
-Zusammenhang zwischen Versionsverwaltung und Datenhaltung
-„What does this Environment do?“
Brown-Modell: Mechanismen
technologische Umsetzung und Architektur zur Realisierung der Services
-Integration bezieht sich auf die Implementierungsaspekte
-Bsp_ Austausch von Nachrichten (Control) und Daten über CORBA-Middleware
-„What components are used and how does this environment integrate the various components?“
Brown-Modell: Prozesse
-Einbettung der Services in den Kontext des Gesamtprozesses
-Integration besschreibt die mögliche Abfolge der Services (Prozessbeschreibung)
-Bsp: Bug-Tracking und Versionverwaltungservices werden nach Auffinden/Korrigieren nötig
-
-„Which processes does this environment support and how does the process influence the use of end-user services?“
Brown-Modell: Abschließend
Grafik
Wassermannmodell: Besipiele von Oberflächenintegration
- Beispiele
- X11
- Windowing für UNIX
- OSF/Motif - MS Windows
- Klassischer Stil - XP Stil
- Windows 7 Stil
- OS X
- Aqua

- Kommando „Integration“
- Vergleichbare Befehle/Aktionen besitzen
- denselben Namen
- sind an der Selben Stelle im Menü - besitzen selbe Darstellung
- BSP: Office

- Interaktions-Integration
- Maniplaution grafischer Elemente ist analog/identisch - Beispiel:
- Lasso in Powerpoint und in Poseidon
Wassermannmodell: Ziele der Plattformintegration
- Ziele:
- Verstecken der Verteilung der einzelnen Software-Komponenten (Tools)
- Ausgleich der Heterogenität der Hardware und Betriebssysteme
- Verteiltes Dateisystem
- Standardfunktionen zur Dateiverwaltung (create,delete)
- Speicherung auf Servern, die vom Netzwerk zugänglich sind
- Kommunikations-Services
- Unterstützung der Interprozess Kommunikation zwischen den Computern des Netzwerkes
- Prozessmanagement-Services
(gemient sind hier Betriebssystemprozesse, d.h. Funktionne dienen zum Starten / Beenden von anderen Tools. Hat zunächst nichts mit Prozessintegration zu tun)
- Erzeugen, Starten, Beenden von Prozessen (Programmen) auf Rechnern des Netzwerks
- Druck-Services
- Ausdruck aus dem Netzwerk
Wassermann-Modell: Datenintegration Ansätze
- Beschreibung von Meta-Daten
- Spezifikation der Bedeutung der Daten - z.B. Datum ist vom Typ „Konto“

- Unterschiedliche Ansätze
- Gemeinsames Datenformat
- Bedeutung ist durch Struktur der Daten festgelegt
- Anwendung hauptsächlich für den Import/ Export
- z.B. zuerst kommt Kontonummer, dann BLZ im File

- Gemeinsames Schema
- Bedeutung ist durch Beziehungen
zwischen den Daten und durch
„Datentypen“ festgelegt
- Anwendung hauptsächlich für den
„Gemeinsamen Datenspeicher“-Ansatz -
Wassermann-Modell: Datenintegration Ansätze - Probleme
Probleme: Schema beschriebt
- Typen von Daten (Objekten)
- Eigentschaften dieser Objekte (Attribute)
- Beziehungen zwischen den Objekten
(Relationen)
- Zugriff auf Objekte

- Probleme
- Entwicklung eines gemeinsamen Schemas erfordert einen hohen Abstimmungsaufwand zwischen den einzelnen Tool-Entwicklern z.b. über
- zu Grunde liegende Modellierungssprache: relation,ER,OO
- Granularität
- gemeinsame Konzepte (Typen)

- UML Profile
- spezielle MetaModelle für spezifische Anwendungsgebiete
- Profile for „Schdualability, Performance and Time“ -
- Konsistenz der Daten
- Wie wird die Konsistenz der Daten gewährleistet - Wie redundanzarm sind die Daten?
Wassermann-Modell: Datenintegration Praxis
- Praxis:
- OMG Standards zur Lösung obiger
Probleme
- modellbasierte Software Entwicklung
- zusätzlich Persistenz der Modelle durch
Im-/Export von Dokumenten -

MOF (Meta Obkect Facility)
- Standard Metamodellierungssprache -
XMI (XML Metadata Interchange)
- XML-Dialekt für Import/Export von MOF Basierten Modellen
- XMI-Schema = Metamodell - XML- Dokument = Modell
- Gemeinsames Datenformaat = gemeinsames Schema
Wassermann-Modell: Datenintegration Prinzipielle Ansätze
Prinzipielle Ansätze
- Import/Export

- Gemeinsamer Datenspeicher
Toaster Modell
Grundidee:
- standardisierte Grundgerüst (Framework) zum Vergleich von CASE-Umgebungen
- abstrahiert von der konkreten Architektur der CASE-Umgebungen (Ausblendung technischer Details)
- Framework beinhaltet eine Menge tool-unabhängiger (grundlegender) Dienste, welche für die Realisierung einer CASE Umgebung benötigt werden.
Synonyme:
- (integration) platform = infrastructure = common services

Repository Services:
- Verwaltung von Entitäten und deren Beziehungen (inkl. Veteilung der Objekte bei
verteilten Systemen)


Data-Integration Services
- höhere „semantische“ Strukturierung der Daten (z.B. entsprechend einens Metamodells) - Versions- und Konfigurationsmanagement
- Datenaustausch mit externen CASE-Tools

Process-Management Services
- Verwaltung und Ausführung zu erledigender Aufgaben - Aufrufsequenzen der einzelnen Tools
Message Services:
- Kommunikation zwischen
- den Tools
- den Services
- den Tools und den Services

User-Interface Services
- einheitliche Benutzungsschnittstelle (Metaphern, Views, Controller) - trennt Bedienung von Funktionalität
Toaster Modell vs OSI Referenzmodell
Message Services ermöglichen die Kommunikation zwischen Tools und Framework (Common Services)
Nachrichtenversand
- Unterschiedliche Sender/Empfänger
- tool-tool
- service-service - tool-service
- Versandarten
- point-to-point
- broadcasting - multicasting
Werkzeug-Registrierung
- erlaubt einem Werkzeug sich für den Empfang spezieller Nachrichtentypen zu
registrieren (-> Multicast)
Toaster-Modell
Vollintegrierte Tools:
- gesamte Daten werden durch Common Services verwaltet und innerhalb des
Frameworks implementiert
Teil-abgetrennte Tools (semi-detached tools)
- verwalten eigene Datenstrukturen aber die Files, mit dem der Inhalt der Datenstrukturen,
werden über Common Services verwaltet
Fremde Werkzeuge
- laufen auf derselben Maschine (Netzwerk)
- benutzen nur Betriebssystemdienste für die Integration/Konfiguration
- Dautenaustausch mit der Tool-Umgebung erfolgt über Data Interchange Services
Software-Prozess Modellierung Definition
Software-Prozessmodellierung befasst sich mit der Definition, Verfeinerung und Erprobung von Prinzipien, Methoden, Techniken und Werkzeugen zur Unterstützung

- der Kommunikation über Software-Entwicklungsprozesse
- der Ablage von Software-Engineering-Prozessen
- basierend auf wiederverwendbaren „Komponenten“,
- der Analyse von Prozessen und dem Ziehen von Schlussfolgerungen
- der Projektsteuerung und -kontrolle
- der automatischen Unterstützung durch PCSEEs
Toaster Modell: Reale Architektur
Software-Prozess Definition
Ein Software-Prozess entspricht der Durchführung einer Software-Entwicklung.
Ein Software-Prozess ist gekennzeichnet durch

- wann und von wem welche Aktivitäten durchgeführt werden
- welche Artefakte bei der Durchführung der Aktivität verarbeitet / erzeugt werden
Software-Prozessmodell Definition
Ein Software-Prozessmodell dokumentiert SW-Prozesse
- durch Definition von:
- (alle) Arten von Aktivitäten die in der Entwicklung durchzuführen sind
- Reihenfolge in der Aktivitäten durchzuführen sind
- dann oft Vorgehensmodell genannt
- Methoden und Werkzeuge, die zur Unterstützung dieser Aktivitäten verwendet werden sollen
- Arten von Artefakten, die durch die Ausführung der Aktivitäten erzeugt und verarbeitet werden
-- werden i.d.R. in einem Produktmodell genauer definiert
Warum Proessmodellierung
Einführung Warum Software-Prozessmodellierung?

 Beherrschung von Komplexität

 Steigerung von Qualität

 Steigerung von Produktivität

 Wiederholbarkeit

 Unterstützung der Prozessverbesserung („if you do not know where you are, a map won‘t help“ [Humphrey89])

 Unterstützung des Projektmanagements

 Unterstützung des Risikomanagements

 Rechnergestützte Anleitung während der Projektdurchführung

 Automatische Abwicklung von Prozessmodellen (Enactment)

 Unterstützung der Analyse des Entwicklungsprozesses

 Verbesserung der Kommunikation zwischen Projektmitgliedern
Bestandteile eines Prozesses
 Ein Prozess besteht aus zwei Arten von Prozesselementen:

– Subprozesse, die wiederum als „eigenständige“ Prozesse betrachtet werden können.

– Prozessschritte, die atomar sind und nicht weiter verfeinert werden können und somit eng zusammenhängende Tätigkeiten umfassen.
Prozess Hierarchie
– so lange, bis keine weiteren sinnvollen Strukturierungen möglich sind; wegen…

… starker personeller und zeitlicher Kopplung der Tätigkeiten … keine assoziierten Produkte/Artefakte existieren

 Beispiel: „Durchführung eines Testfalls“ (Prozessschritt)

– Tätigkeiten:

- Testumgebung starten - Testfall durchführen - Testergebnisse protokollieren
Prozess Hirarchie: rekursive Verfreinerung
so lange, bis keine weiteren sinnvollen Strukturierungen möglich sind; wegen
starker personeller und zeitlicher Kopplung der Tätigkeiten
keine assoziierten Produkte/Artefakte existieren
Prozessschritte: Attribute
Rollen
Bspw. Tester
Anwendbare Prozess und Produktstandards
JUnit-Testfallbeschreibung
Anwendbare Prozeduren, Methoden, Werkzeuge und Ressourcen
Bspw. Test-Driven Developement
JUnit Tool
2 Tester für 1 Tag verfügbar
Eingangs-Kriterien
Bsp: Testfall und „Artefact under test“ fertiggestellt
Eingabeartefakte
Bsp: Testfsll unf „Artefact under test“
Produkt und Prozessmaße die gesammelt und verwendet wurden
Bsp: Anzahl Fehlerwirkungen (Failures)
Verifikationspunkte
Bsp: 80% Testüberdeckung
Ausgabe-Artefakte
Bsp: Test-Protokoll
Schnittstellen
Bsp: Übergang zu Debugging
Ausgangskritierien
Bsp: Bar is green
Prozesse: Beziehungen
Schnittstellen
- zwischen Prozesselementen
- zu externen Prozessen
Prozesse: Reihenfolge der Ausführung der Prozesselemente
- Sequenz
- Alternative
- Schleife
- Fork/Join
Prozesse: Abbhängigkeiten zwischen den Prozesselementen
z.B. Einschränkung der Reihenfolge: A begonnen, dann darf B starten
Prozessmodell: Definition
Ein Prozessmodell ist die definierte Beschreibung eines Prozesses, d.h. es umfasst Prozesselemente und deren Beziehungen.

Ein Prozessmodell enthält (über Attribute der Prozessschritte)
- Input-/Outputprodukte (Artefakte)
- Rollen und ihre Zuordnung
- Zuordnung von Techniken, Methoden und Werkzeugen
Prozessmodell: Projektplan
spzielle Sicht auf ein Prozessmodell
basierend auf projektspezifischen Informationen (Ressourcen, Einschränkungen) angepasst angereichert und instanziert
Prozessmodell: Eigenschaften
- Entwicklung großer Software-Systeme ist ein komplexer Prozess
- Quantitative und qualitative Vielfalt von Aufgaben
- Große Zahl an beteiligten Personen (Stakeholder)
- Entwicklung komplexer Systeme erfordert
Prinzipien, Techniken, Methoden
Werkzeuge
- Software-Entwicklungsprozess -> Projektplan
- „Entwicklung eines großen Systems verhält sich zur Programmierung kleiner Systeme wie das Management eines Industriekonzerns zur Leitung eines Kleingewerbs“
Prozessmodell: Abhängigkeit zur Qualität
Es besteht eine direkte Abhängigkeit zwischen dem Software-Entwicklungsprozess und den Qualitätseigenschaften der Software
Prozessqualität beeinflusst die Produktqualität
Konzentration auf isolierte Methoden und Techniken des Software Engineerings allein genügt nicht
-> Entwicklungsprozesse müssen als ganzes betrachtet werden.
Prozessmodell: Unterteilung der Prozesse
- Kernprozesse vs. strategische Prozesse
- Tätigkeiten im Kerngeschäft
z.B: Kundenbetreuung,Auftragsbearbeitung
- Supportprozesse
- Geringere strategische Bedeutung
- Unterstützende Tätigkeinten
- z.B. Büchführung, Kostenrechnung, Personal
Prozessmodell: Besondere Eigenschaften von Software
Das Produkt Software besitzt einige besondere Eigenschaften, das es von anderen Produkten grundlegend unterscheidet.

- Komplexität
- Größe
- Anzahl der Funktionen
- Änderbarkeit
- Versionierung
- Unsichtbarkeit
- Virtualität
- Art der Fertigung

- Innovationsgrad
Prozessmodell: Art der Fertigung von Software
eigentlich gibte s bei SW keine Fertigung nur Entwicklung
Fertigung bei SW ist reines kopieren
Art der „Zuverfügungstellung“
neben Kauf eines SW Produkts auch reine Nutzung eins SW Service möglich
Prozessmodell: Innovationsgrad von Software
Software Produkte sind häufig völlig neuartig -> nicht vergleichbar mit ex. Produkten
Prozessmodell: Vergleich mit Geschäftsprozessen
Software Prozesse ähneln Geschäftsprozessen, es gibt aber zusätzliche Herausforderungen


Granularität
- Softness und Anpassbarkeit („Taylorability“)
- Änderungen/Evaluation des Prozessmodells wegen
- Änderung der Entwicklungsmethdoen
- Änderung der Werkzeuge
- Änderugnen der Technologie
- Änderungen des Prozesses (Während der Durchführung) wegen
- Änderung der Produktanforderungen
Prozessmodell: Prozessmodell-Typen
- Universal U
- Worldly W
- Atomic A
Prozessmodell: Universal U
Waterfall
Spiral Modell
- Prototyping
- Incremental
- Reusable software model
- Agile Development
Prozessmodell: Worldly W
- Beschreibt die prinzipielle Abfolge von Schritten
-Unterstützt den Entwickler
Prozessmodell: Atomic A
- Beschreibt Prozessschritte, die in einer systematischen und evtl. automatisierten Art und Weise durchgeführt werden können
- Prozeduren, Algorithmen
Prozesmodell-Abstraktionsebenen: Generisch
- Organisationsweiter Standard/Rahmen
- Vereinfacht Training, Review und Tool-Support
Prozesmodell-Abstraktionsebenen:
Angepasst
- Passend für spezifische Projketcharakteristiken
- oder Projekte in einer Spezifischen Abteilung
Prozessmodell: Besondere Eigenschaften von Software
Das Produkt Software besitzt einige besondere Eigenschaften, das es von anderen Produkten grundlegend unterscheidet.

- Komplexität
- Größe
- Anzahl der Funktionen
- Änderbarkeit
- Versionierung
- Unsichtbarkeit
- Virtualität
- Art der Fertigung

- Innovationsgrad
Prozessmodell: Art der Fertigung von Software
eigentlich gibte s bei SW keine Fertigung nur Entwicklung
Fertigung bei SW ist reines kopieren
Art der „Zuverfügungstellung“
neben Kauf eines SW Produkts auch reine Nutzung eins SW Service möglich
Prozessmodell: Innovationsgrad von Software
Software Produkte sind häufig völlig neuartig -> nicht vergleichbar mit ex. Produkten
Prozessmodell: Vergleich mit Geschäftsprozessen
Software Prozesse ähneln Geschäftsprozessen, es gibt aber zusätzliche Herausforderungen


Granularität
- Softness und Anpassbarkeit („Taylorability“)
- Änderungen/Evaluation des Prozessmodells wegen
- Änderung der Entwicklungsmethdoen
- Änderung der Werkzeuge
- Änderugnen der Technologie
- Änderungen des Prozesses (Während der Durchführung) wegen
- Änderung der Produktanforderungen
Prozessmodell: Prozessmodell-Typen
- Universal U
- Worldly W
- Atomic A
Prozessmodell: Universal U
Waterfall
Spiral Modell
- Prototyping
- Incremental
- Reusable software model
- Agile Development
Prozessmodell: Worldly W
- Beschreibt die prinzipielle Abfolge von Schritten
-Unterstützt den Entwickler
Prozessmodell: Atomic A
- Beschreibt Prozessschritte, die in einer systematischen und evtl. automatisierten Art und Weise durchgeführt werden können
- Prozeduren, Algorithmen
Prozesmodell-Abstraktionsebenen: Generisch
- Organisationsweiter Standard/Rahmen
- Vereinfacht Training, Review und Tool-Support
Prozesmodell-Abstraktionsebenen:
Angepasst
- Passend für spezifische Projketcharakteristiken
- oder Projekte in einer Spezifischen Abteilung
Prozesmodell-Abstraktionsebenen:
Angepasstes Modell + konkrete Ressourcen
Prozesmodell-Abstraktionsebenen:Enacted
instanziierter Projektplan
Prozessmodelle Einsatzzweck: Deskriptive Prozessmodellierung
- Erfassung und Beschreibung des tatsächlichen Prozesses zur Kommunikation & Analyse
- Zweck: Verstehen, Kommunizieren, Messen, Führen
- Geeignet für Prozessverbesserung
Prozessmodelle Einsatzzweck: Präskriptive Prozessmodellierung
- Konzeption und Beschreibung des gewünschten Ablaufs
- Geeignet für Anleitung von Prozessbeteiligten
Prozessmodelle Beschreibungsansatz: Ablauforientiert (operational)
-explizite Steuerung in welcher Reihenfolge Aktivitäten durchlaufen werden
- Pro: Verständlichkeit
- Contra: Flexibilität
Prozessmodelle Beschreibungsansatz:Constraint-basiert (deklarartiv)
- psychologische Beobachtungen zeigen: Eintwickler sind in einer einengenden Umgebung nicht kreativ und produktiv
- nur diejenigen Prozessabfolgen ausschließen, die sich als Kontraproduktiv zu den Zielen des Unternehmens herausstellen
- ergebnisorientiert (Akzeotanzkriterien für Produkte)
- Pro: psychologischen Erkenntnissen wird Rechnung getragen
- Contra: kein Prozess sichtbar, Verständnis und Steuerung erschwert.
Prozessmodelle Praxis:
Parallelität zum RE
- Verschiedene Stakeholder
- Verschiedene Sichten
- Domänenkenntnisse
- Unvollständigkeit, Widerspruche, mangelnde Korrektheit
SPEM: Definition
SPEM ist eine Sprache zur Definition von Software-Prozessen:
- abstrakte Syntax und Well-Formedness Rules
- Durch Metamodell und Profile spezifiziert
- Konkrete Syntax
-Notaitionsmöglichkeiten werden beispielhaft beschreiben
- Semantik
- natürlichsprachlich beschrieben
Einsatzbereich von SPEM:
- Definition von Softwareprozessmodellen
- inbesondere solche, bei denen UML eine Rolle spielt
- Instanziierung und Enacment sind nicht teil von SPEM
- entsprechende Konzepte beinhaltet das Metamodell auch nicht
UML-Profil von SPEM
SPEM ist eine Spezialisierung der UML (Profil)
- Daher sind alle UML- Diagramme auch zur Prozessmodellierung einsetzbar
- gültige SPEM Modelle sind auch gültige UML-Modelle
-> Vorteil: Gesamter Sprachumfang der UML für Prozessmodellierung verfügbar
Konzeptuelles Model von SPEM
Ein Software Prozess in SPEM ist eine Kollaboration
- zwischen abstrakten Entitäten
- welche Operationen
- auf konkreten bearbeitbaren Einheiten durchführen können

Oberstes Ziel des Prozesses ist es, die Work-Products in einen wohldefinierten Zustand zu bringen
SPEM-Sprachkonzept Guidance
Guidance = Ergänzung eines Prozesselements um Detailinformationen
- Technique
- Technik zur Erstellung des Work-Products
- UML Profile
- Zu verwendende Spezialisierung der UM:
- Checklist
- Prüfpunkte
- ToolMentor
- Einsatz eines spezifischen Tools
- Guideline
- Regeln, Best-Practises
- Template
- Strukturierte Vorgabe für Dokumente
- Estimate
- geschätzter Aufwand
SPEM: Notation
SPEM Sprachkonzept: Dependencies
Prozesselemente sind Spezialisierungen von Classifier,Operation
- daher sind existierende UML - Beziehungen nutzbar
SPEM definiert zusätzlich Beziehungen
- start_start
- finish_start
- finish_finish

Klassendiagramm
- existierende UML Beziehung Komposition

Use Case Diagram:
- spezielle Stereotxpe für UML Assoziation
SPEM Sprachkonzept: Use Case-Diagramm
Use Case Diagram:
spezielle Stereotype für UML Assoziation
SPEM Sprachkonzept: Beispiel für spezielle Usage-Beziehung: Precedes
Reihenfolgeabhängigkeiten zwischen Activities
Unterscheidung in:
- finish-finish (FF)
-Aktivität muss fertig sein, bevor abhängige Aktivität beendet werden kann
- finish-start (FS)
- Aktivität muss fertig sein, bevor abhängige Aktivität starten kann
- start-start (SS)
- Aktivität muss gestartet sein, bevor abhängige Aktivität starten kann
Anwendung von SPEM:
UML Aktivitätsdiagramme
- typische Sicht auf verhaltensaspekte, die auch zur Modellierung von Prozessen geeignet ist
- seit UML 2-0 ist die Semantik der AD die der Petrinetze
UML Aktivitätsdiagramm Definition: Aktivität
- Eine Aktivität bildet einen Graphen bestehend aus Aktivitätsknoten und Flüssen
- Ein Aktivitätsknoten kann sein:
- Eine Aktion
die Ausführung einer Anweisung
- Ein Kontrollknoten
zu Steuerung eines Kontrollflusses
ein Objektknoten
repräsentiert ein Objekt
UML Aktivitätsdiagramm Definition:
Ein Aktivitätsdiagramm dokumentiert eine Aktivität in dem es die Knoten und Flüsse modelliert
Aktivitätsdiagramme eignen sich zur Visualisierung von abläufen zur Erreichung eines bestimmten Verhaltens für Operationen, Aktivitäten, Szenarien,Geschäftsprozesse
SPEM Notation
UML Aktivitätsdiagramm: Aktivität
Eine Aktion ist ein primitiver Aktivitätsknoten, der einen Verarbeitungsschritt entspricht
Name der Aktion sollte aussagekräftig sein (Generiere Bericht)
UML Aktivitätsdiagramm - Kontrollfluss:
Ein Kontrollfluss definiert die Ausführungsreihenfolge von Aktivitätsknoten, in dem zwei Knoten verbunden werden
Ein Knoten ist so lange aktiv, wie die Ausführung der Aktion benötigt wird.
Semantik: Aktive Knoten werden durch ein Token markiert.
UML Aktivitätsdiagramm - Kontrollknoten
Es gibt Fork-, Join-,Decision-,Merge, Start- und End-Knoten
UML Aktivitätsdiagramm - Kontrollknoten
Decision,Merge Knoten Diagramm
UML Aktivitätsdiagramm Objektknoten:
Ein Objektknoten repräsentiert ein Objekt - das von einer Aktion produziert wurde oder von einer anderen Aktion benutzt wird.


Objektknoten spichern Daten, die entlang des Kontrollflussen zwischen Aktionen ausgetauscht werden
UML Aktivitätsdiagramm - Fluss-Pin:
Ein Pin ist ein spezieller Objektknoten, der Ein und Ausgabeparameter einer Aktion expliziert definiert
Ein Pin dient als Verbindungspunkt für einen Kontrollfluss
Der Pin kann mit einen Namen und einem Typen versehen werden
Eine Aktion kann mehrere Ein und Ausgabe Pins besitzen
UML Aktivitätsdiagramm Strukturierung durch Swinlanes:
Zur Strukturierung komplexer Aktivitäten bieten sich Partitionen an, die ein Aktivitätsdiagramm nach der Verantwortlichkeit gliedern.
SPEM 2.0: Übersicht
- Bessere Trennung von Konzepten
- Unterscheidung in
- Methodenbeschreibung
- Prozessbeschreibung / modellierung
- Unterstützung der Prozessplanung
- Beschreibung von Variabilität in Prozessen
- Initiale Unterstützung für Enactment
- Konzepte zur Beschreibung wie ein Prozess enacted werden sollte
- Änderung der Symbole
SPEM 2.0: Trennung von Konzepten
- Method Content bschreibt Schritt-für-Schritt Anleitung, um spezifische Entwicklungsziele zu erreichen
- Process beschreibt die Einbettung und Reihenfolge der Method Content Elemente für spezifische Arten von Projekten

- Guidance Elmente können sowohl für Method Content als auch für Process definiert werden
SPEM 2.0: Prozessanpassung
Neue Sprachkonstrukte zur Beschreibung von Variabilität und Erweiterbarkeit von Prozessen
Projektrisiken: Welche Projektrisiken kann es geben
- Anforderungsänderungen
- Unklare Anforderungen
- Personal
- Beherrschbarkeit der Technologie
- Zeitdruck
- zu kleine Budgets
- Fehlende Managementunterstützung
- Vertriebler
- Mangelnde Koordination zwischen Team-Mitgliedern
- Schelechte Spezifikation
- Zu frühe Fertigstellung
- Fehlende Qualitätssicherung
- Falsche / gar keine Beurteilung der Risiken
SPEM 2.0 Notation
Projektrisiken Checkliste: Risiken im Projektumfeld
- Steht das Management hinter dem Projekt?
- Welche Bedeutung hat das Projekt im Unternehmen?
- Wer ist Unterstützer oder Gegner des Projektes?
- Sind während der Projektlaufzeit Marktveränderungen zu erwarten, die sich auf das Projekt auswirken können?
- Welche gesetzlichen Veränderungen sind während der Projektzeit zu erwarten?
- Welche Abhängigkeiten gibt es?
Projektrisiken Checkliste:Risiken bei der Projektplanung?
- Wichtige Aktivitäten werden vergessen oder übersehen
- Definition von überflüssigen Arbeitspaketen, weil Ziel nicht klar genug vorgegeben
- Schelchte (zu optimistische Schätzung) von Aufwänden und Kosten
- Unklare Projektziele (I‘ll know it when i see it“)
Projektrisiken Checkliste:Personelle Risiken
- Fehlende Motivation der Projektmitarbeiter
- Mitarbeiter sind nicht ausreichend verfügbar oder sie besitzen nicht die erforderlichen Qualifikationen
- Projektleiter ist mangelhaft ausgebildet
- Mitarbeiterfluktuation
- Mangelnde Innovationsbereitschaft („That‘s how we‘Ve always done it“)
- Kulturelle Unterschiede („One size uniormly fits all“)
Projektrisiken Checkliste: Technische Risiken
- Einsatz neuer Techniken, Technologieänderungen
- Fehlende Hard und/oder Software komponenten
- Fehlende Erfahrungen mit Entwicklungsumgebung
- Mangelnde Kompabilität von Schnittstellen
- Geplante Lösung ist technisch nicht umsetzbar
Projektrisiken Checkliste: Betriebswirtschaftliche Risiken
- Auftraggeber wird zahlungsunfähig
- Lieferanten sind unzuverlässig, fallen aus oder liefern Produkte minderer Qualität
- Abhängigkeiten von Währungskursen
- Budgetkürzungen
Projektrisiken Checkliste: Risiken während der Projektdurchführung
- Terminliche Verzögerungen bei kritischen Arbeitspaketen
- Änderungen in den Anforderungen / Unvollständige Anforderungen
- Ausfürungsmängel
- Kein aktives Risikomanagement
- Mangelnde Einbeziehung der Nutzer
- Fehlende Ressourcen
Projektrisiken Checkliste: Risiken beim Projektabschluss
- Produkt wird nicht termingerecht fertig
- Produkt ist mangelhaft
- Unzufriedenheit der Anwender mit dem neuen Produkt
- Budget wurde überzogen
- Fehlende Post-mortem Projekt reviews
- Unrealistische Erwartungen
Risikomanagement Definition: Projektrisiko
Risiko, das die erfolgreiche Beendigung des Projekts gefährdet
Risikomanagement: Definition Produktrisiko
Risiko, welches durch den Einsatz des Produkts hervorgerufen wird
Der Risikobegriff: Quantifizierung
allgemein: R(E) = f(P(E),C(E))
P(E) = Häufigkeit für Eintreten des Risikoereignisses
C(E) = Schadensausmaß bei Eintreten des Ereignisses
In der Praxis wählt man typischerweise für f das Produkt also R = P X C
Der Risikobegriff: Beispiele für Einflussfaktoren
Häufigkeit:
- Art des Systems
- Änderungswahrscheinlichkeit

Schadensausmaß
- Vertragsstrafen
- Schadenersatzforderungen
- Fehlerbehebungskosten
- Zulassenungskosten
- Rufschädigung
Aufgaben des Risikomanagements: Risikobewertung Risikoidentifikation
- Aufdeckung und Beschreibung spezifischer Risiken
- Brainstroming/Checklisten
- Risikoanalyse
- Abschätzung der Häufigkeit des Auftretens eines Schadensfalls und die mögliche Konsequenz für jedes Risiko
- Techniken zur Analyse und Bewertung von Risiken sind: detaillierte Beschreibung, qualitative und quantitative Analysen
Aufgaben des Risikomanagements: Risikobewertung Risikopriorisierung
Konzentration auf wesentliche potenzielle Problemfelder abhängig vom Schadensausmaß und Eintrittshäufigkeit
Aufgaben des Risikomanagements: Risikobeherrschung - Risikoplanung
Risikoplanung
- Vorbereitung der Aktivitäten zur Risikokontrolle und Integration in Projektplanung
- Es geht um die Strategie zur Behandlung von Risiken
Aufgaben des Risikomanagements: Risikobeherrschung - Risikobehandlung
Risikobehandlung
- Alle Aktivitäten zur Minimierung oder Beseitigung eines potenziellen Problems
- Strategien sind: Risikoakzeptanz,Risikovermeidung, Risikoschutz, Risikoreduzierung, Risikoforschung, Risikoreserve, Risikotransfer
Aufgaben des Risikomanagements: Risikobeherrschung - Risikoüberwachung
Risikoüberwachung
- Verfolgung von Risiken und der Fortschritte bei deren Überwindung
- eine Laufende Überwachung der Risiken, da diese sich im Lafe eines Projektes verändern können.
Prozessverbesserung: Motivation
Prozessqualitäts beeinflusst die Produktqualität. Eine Verbesserung der Prozessqualität ermöglicht nachhaltige Verbesserung der Produktqualität
Prozessverbesserung: Ziele
Interative oder inkrementelle Verbesserung und Erhöhung des Reifegrades der Prozesse
Prozessverbesserung: Voraussetzung
Prozesse, Produkte, Softwarecharakteristika und Ziele müssen bekannt sein, bevor der Prozess verbessert werden kann. Prozessmodellierung ist notwendig und die Verbesserung ist kontextspezifisch
Prozessverbesserung: Vorgehensweise
Ziele werden unter Berücksichtigung der Charakteristika einer Organisation gesetzt.
Es werden sinnvolle Verbesserungsmaßnahmen ausgewählt. Nach der Einführung einer Maßnahme werden die Effekte Beobachtet und weitere Maßnahmen abgeleitet.
Prozessverbesserung: Bewertung ("Assessment") -Ziele
Ziele: Bewertung des Reifegrads der Prozesse einer Organisation, Identifikation von Verbesserungsmaßnahmen (Qualität und Planbarkeit)
Prozessverbesserung: Bewertung Assessment - Vorgehensweise
Vergleich des SW-Entwicklungs-Prozesses einer Organisation mit einem Ideal-Prozess (siehe CMMI oder Spice).. Ed wird die Existenz von Aktivitäten geprüft. Prozessverbesserung ist dann die Eliminierung der Unterschiede. Verbesserungspfad wird vorgegeben
Product Quality: Prinzipien
Es werden Faktoren abhängig von Projektcharakteristika gewichtet.
- Bei kleinen Team werden die Qualität der Mitarbeiter und der Entwicklungstechnologie bewertet, da ein Großteil der Arbeit auf die tatsächliche Entwicklung entfällt
- Bei großen Teams wiird die Prozessqualität bewertet, da ein Großteil der Arbeit auf Kommunikation/Abstimmung/Steuerung
- Kosten, Zeitpläne sind unabhängig von Teamgröße immer wichtig, Ist die zeit zu knapp leidet die Qualität
Software Process Improvement: Prinzipien
Der Fokus liegt auf dem Prozess und nicht auf dem Produkt, da bessere Prozesse eine Produktverbesserung implizieren. Der Prozess wird beobachtet und gemessen. Die Messdaten sind Grundlage für die Verbesserungsschritte. Die Ursachen der Probleme werden identifiziert und lokalisiert. Die kritischen Stellen werden entfernt und durch zielgerichtete Maßnahmen ersetzt
Software Process Improvement:
Schritte
1. Prozessanalyse
2. Identifikation von Verbesserungspotential
3. Vorstellung der Prozessänderung
4. Üben der Prozessveränderung
5. Anpassen der Verbesserung (Effizienzsteigerung)
Software Process Improvement: Paradigmen
Es gibt Messungsbasierte Verbesserungen wie SPICE und CMMI und evolutionäre Methoden wie PCDA,TQM
Evolutionäre Prozessverbesserung:
ziel
Iterative Verbesserung der Prozess qualität
Evolutionäre Prozessverbesserung:

Annahme
Eine Organisation muss ihre Produkte, Prozesse und Ziele kennen bevor sie Prozesse verbessern kann.
Evolutionäre Prozessverbesserung:Grundprinzip
Grundprinzip: Bottom-Up
Ziele Setzen
Auswahl sinnvoller verbesserungsmaßnahmen
Beobachtung der Effekte
Ableitung weiterer Maßnahmen
Evolutionäre Prozessverbesserung: Plan-Check-Do-Act
Ziel Ansatz und Aktivitäten
Ziel: Optimierung einer einzelnen Produktlinie
Ansatz: Wiederholungsfolgen, statistische Kontrollen
Aktivitäten: Planen,Machen, Kontrollieren,Agieren.
Evolutionäre Prozessverbesserung: Total Quality Management TQM
Erfolg eines Unternehmens wird durch Zufriedenheit des Kunden bestimmt.
Qualität ist höchstes Ziel von Mitarbeitern über Hierarchie-Ebenen hinweg, bei der Gestaltung der Aufgaben.
Evolitionäre Prozessverbesserung: Total Quality Management (TQM): Triangle
Managment commitment ist essentiell für ein qualitätssystem, Prozesskontrolle generiert raw data
Evolutionäre Prozessverbesserung TQM: Demings 14 Punkte
Create constancy of purpose
Adapt new philosophy;
eliminate the need for inspections by building quality into the product
Minimize total cost
Improve constantly and forever the system of production and service
Institutionalize training on the job
Institutionalize leadership
Drive out fear
Break down barriers between departments
eleminatioan of numeric goals, aim of zero objects
Institutionalize a program of education and self-improvement
Put everybody in the company to work to accomplish the transformation
Assesmentbasierte Prozessverbesserung: Ziele
Bewerung des Reifegrades
Identifikation von Verbesserungsmaßnahmen

Grundprinzip: Top Down
Vergleich des SW Prozesses mit dem Ideal
Verbesserung ist Eliminierung der Unterschiede
Verbesserungspfad wird vorgegeben.
Assesmentbasierte Prozessverbesserung: CMMI Reifestufen Maturity
Initial
Wiederholbar
Definiert
Gesteuert
Optimierend
Assesmentbasierte Prozessverbesserung: CMMI - Vorteile
systematische Möglichkeit der Prozessverbesserung
sorgfältiges Assessment deckt Schwächen des aktuellen Prozesses auf
empirische Untersuchen zeigen dass Nutzen den Aufwand übersteigt
erlaubt Evaluierung des aktuellen Prozesszustandes und damit auch den Vergleich auf andere Firmen
Assesmentbasierte Prozessverbesserung: CMMI - Nachteile
kein Garantierte Zusammenhang zwischen hohem Reifegrad und erfolgreicher Software Entwicklung
stark technikbezogen
um eine hohe Stufe zu erreichen müsseln alle Forderungen der niedrigen Stufen erreicht werden.
CMMI Modelle: Grundlegend
CMMI ist aufgeteilt in Disziplinen wie Software-, Systems Engneering, Repräsentationen wie Stage und Continious, Training und Appraisal Methods
CMMI Modelle: Integration
CMMI Modelle können verschiedene Disziplinen integrieren wie CMMI-SW (für Software Engineering)
CMMI Modell: Komponenten
spezifische Ziele
generische Ziele
spezifische Praktiken
genrische Praktiken
Ziele werden immer benötigt
CMMI Prozessbereich
Ein Prozessbereich ist ein Zusammenschluss von verwandten Praktiken die eine Menge von Zielen erreichen.
CMMI Ziele:
Ein Ziel repräsentiert einen gewünschten Endstatus
Spezifische Ziele sind für einen einzelnen Bereich anwendbar.
Generische Ziele kann man mehrfach anwenden
CMMI Praktiken
Eine Praktik repräsentiert den Aufwand um ein Ziel zu erreichen.
Spezifische Praxis erreicht ein spezifisches Ziel
Generische Praxis erreicht ein generisches Ziel
CMMI Maturity Level
Wie gut sind wir?
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
CMMI Capability Level
Wie gut sind wir in Bereich X?
0. Incomplete
1. Performed
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizinges
CMMI Continious Repräsentation