01intro

1.1 Motivation 

1.2 Grundbegriffe 

1.3 Modellierung 

1.4 Vorgehensmodelle 

1.5 Der Unified Process 

1.6 Das V-Modell der SW-Entwicklung 

1.7 Zusammenfassung 

© H. Lichter, U. Schroeder -- RWTH Aachen 

Mit Kommentaren (Interaktion) 

- 1 -




Software als Industriefaktor 

Qualitätsmerkmale 

Softwarekonstruktion als Ingenieursdisziplin 

Erfolgsfaktoren bei der SW-Entwicklung 







- 2 -


Wirtschaftliche Bedeutung 

2001: weltweiter Elektronikumsatz von 1,2 Billionen US-$ 

Industrielle Produkte (HighTech): 

mindestens 30 % Softwarekosten (KfZ, ...) 

Umweltgesetze, ... 

Funktionalität 

? 

- 3 -

employed in professional areas 


Information/Knowledge Society 

Information 

80's: more people employed in the information industry than in any other 

2000's: more than half of the working population 

- 4 -


Software als Industriefaktor 

Einfluss der Software auf unsere Produkte 

Immer mehr Produkte „enthalten“ Software 

Immer mehr Produkte unterscheiden sich von Konkurrenzprodukten nur 

durch Software Alleinstellungsmerkmale 

Software ist zu einem entscheidenden Wettbewerbsfaktor geworden 

Einfluss auf die Gesellschaft 

Software-Entwicklung ist ein wichtiger Wirtschaftsfaktor 

Unsere Gesellschaft vertraut Software und baut auf Software 

Es wird immer mehr Software benötigt, 

die immer schneller verfügbar sein soll 

die immer günstiger sein soll 

die immer besser sein soll 

funktional umfangreicher, komfortabler, sicherer, schneller, … 


- 5 -

Funktionalität 

Korrektheit 

interoperabel 


Sicherheit 

angemessen 

Zeit 

Verbrauch 

Systemqualität (ISO9126) 

ordnungsmäßig 

Zuverlässigkeit Benutzbarkeit 

Reife 

Fehlertoleranz 

Analysierbarkeit 

Modifzierbarkeit 

Wiederherstellbarkeit 

Stabilität 

Prüfbarkeit 

Bedienbarkeit 

Erlernbarkeit 

Anpassbarkeit 

Installierbarkeit 

Effizienz Änderbarkeit Übertragbarkeit 

Verständlichkeit 

Konformität 

Austauschbarkeit 

Q 

u 

a 

li 

t 

ä 

t 

s 

s 

y 

s 

t 

e 

m 

- 6 -


Systematische Softwareentwicklung 

Wer hat schon ein Programm geschrieben? 

yalleine? 

ydirekt am Rechner entwickelt? 

yohne vorherige Planung, Skizze, ...? 

yHat es funktioniert ? 

Gratuliere! 

Programmieren im Kleinen lässt sich leider nicht 

direkt auf große Probleme anwenden 

- 7 -


Building a dog house 

Booch, Software Architecture 

Can be built by one person 

requires 

Minimal modeling 

Simple process 

Simple tools 

- 8 -


Building a house 

Built most efficiently and timely by a team 

requires 

Modeling 

Well-defined process 

Power tools 


- 9 -

Die Software-Technik stellt 

auch hierfür Methoden 

bereit, die z.T. noch reifen 

müssen … 


Architecting a high rise 


- 10 -

Models 

abstraction 

views 

purpose 


Modeling a house 


• representations of the system to-be-built 

• vehicle for communications with various 

stakeholders 

• Visual models, blueprints, Scale 

• reasoning about some characteristic 

- 11 -


Systematische Produktentwicklung 

Bauingenieur: z.B. Hochhaus, Brücke, ... 

Strukturierung des Entwicklungsprozesses 

Planung 

Berechnung 

Ausführung (in mehreren Phasen) 

verschiedene Spezialistenteams 

Engineering seeks quality 

Prüfung des Ergebnisses 

Strukturierung des Produktes 

Fundament 

Außen- und Innenwände 

Geschoßdecken 

Dach 

Innenausbau 

- 12 -


Software Development Process 

... defines who is doing what when and how 

dependent on 

Technology 

modeling & programming languages, computer systems 

Tools 

programming environments, computer systems 

People 

skills and learning 

Organizational Pattern 

process adaption to globality 

- 13 -

Erfolgsfaktoren bei der SW-Entwicklung 

Gut ausgebildete Mitarbeiter 


Sie sind der Schlüssel zum Erfolg! 

Besseres Engineering 

Gute Prozesse 

stetige Prozessverbesserung 

Einsatz geeigneter Werkzeuge 

Einsatz vielversprechender Technologien 

Objekttechnologie 

Komponententechnik 

Nicht immer alles von Neuem erfinden 

Wiederverwendung gezielt anstreben 

Produktentwicklung auf der Basis von Wiederverwendung 

organisieren 


- 14 -




Software und Programm 

Programmentwicklung 

Eigenschaften von Software 

Systemdreieck 

Werkzeug, Werkstoff, Methode 

Software-Engineering 



1.5 Unified Process 




- 15 -


Software und Programm 

Software 

IEEE Standard Glossary of Software Engineering Terminology 

"Computer programs, procedures, and possibly associated 

documentation and data pertaining to the operation of a computer 

system.„ 

Software umfasst danach also 

Programme, Abläufe, Regeln, auch Dokumentation und Daten, die mit 

dem Betrieb eines Rechnersystems zu tun haben. 

Software ist ein technisches Produkt 

Es wird von Ingenieuren systematisch entwickelt. 

Es ist durch feststellbare Eigenschaften (Funktionalität, Qualität) 

gekennzeichnet. 

Programm 

IEEE Standard Glossary of Software Engineering Terminology 

"A combination of computer instructions and data definitions that 

enable computer hardware to perform computational or control 

functions". 


- 16 -


Programmentwicklung 

Unter dem Begriff Programmieren versteht man 

das Lösen von Problemen unter Zuhilfenahme eines Rechners 

Problem 

Komplexer Prozess 

viele Rückgriffe 

Algorithmus Programm 

Programmiersprache 


Daten 

Rechner 

Programmieren (im Kleinen) ≠ Software-Entwicklung 

Programmieren ist ein Teil der Software-Entwicklung 

⊂ 

Lösung 

- 17 -


Systemdreieck 

Methode, Sprache und Werkzeug bilden ein System, wenn 

sie durch gemeinsame Konzepte verbunden sind. 

Sprache 

Konzepte 

Methode 

Werkzeug 


- 18 -


Werkzeug, Werkstoff, Methode 

Werkzeuge 

dienen zur Ausführung einer Arbeit 

Im Produkt ist das Werkzeug nicht mehr enthalten (es sei denn als 

Ausrüstung für die Wartung). 

Typische (Software-)Werkzeuge sind Editoren, Übersetzer, Integrierte 

Programmierumgebungen, CASE-Tools, Datenbank-Systeme. 

Werkstoffe 

sind von den Werkzeugen deutlich unterschieden, weil aus ihnen das 

Produkt geformt wird; die Werkstoffe bleiben im Produkt. 

Wir benutzen als Werkstoffe unserer Produkte Sprachen, sowohl 

„natürliche“ als auch formale. 

innerhalb von Sprachen lassen sich Bausteine (Bibliothekselemente) 

konstruieren. 

Methoden 

sind Handlungsanweisungen, also Regeln, die den Menschen bei der 

Wahl seiner Aktionen führen. 


- 19 -


Eigenschaften von Software 

Software ist immateriell. 

Kopie und Original sind völlig gleich. 

Software wird nicht gefertigt, sondern nur entwickelt. 

Software verschleißt nicht; die „Wartung“ stellt nicht den alten Zustand wieder 

her, sondern einen neuen. 

Software Fehler entstehen nicht durch die Benutzung, darum kündigen sie sich 

nicht an. 

Die Software-Leute unterschätzen meist das Problem ... oder überschätzen 

sich selbst! 

Ein Programm realisiert keine stetige Funktion. 

Die Korrektheit der Funktionalität ist durch Test nicht zeigbar. 

Software-Systeme sind sehr komplex. 

Die Entwicklung guter Software ist darum unvermeidlich aufwendig (teuer). 

Die wenigen „Werkstoffe“ der Software - die Sprachen - sind amorph 

und universell. 

Die Werkstoffe induzieren keine sinnvollen (Grob-) Strukturen. Diese müssen 

darum aktiv geschaffen werden. 

Software spiegelt (in vielen Fällen) die Realität. 


- 20 -


Software-Engineering 

Software-Krise 

Ende der 60er Jahre wurden Softwareentwicklungen nicht mehr mit den 

bekannten Mitteln beherrschbar. 

Konsequenz: 

Etablierung eines Fachs, das die ingenieurmäßige Entwicklung von Software 

zum Inhalt hat. 

Definitionen 

Software Engineering ist die Entdeckung und Anwendung solider Ingenieur- 

Prinzipien mit dem Ziel, auf wirtschaftliche Art Software zu bekommen, die 

zuverlässig ist und auf realen Rechnern läuft. 

F.L. Bauer 

Software Engineering ist die Herstellung und Anwendung einer Software, wobei 

mehrere Personen beteiligt sind oder mehrere Versionen entstehen. 

D. L. Parnas 

The application of a systematic, disciplined, quantifiable approach to the 

development, operation, and maintenance of software; that is, the application of 

engineering to software. 

IEEE Standard Glossary of SE Terminology 


- 21 -

Scheitern von SW Projekten 


Software Krise 

immer noch aktuell Mautsystem, … 

SW zu spät ausgeliefert, Kosten ein Vielfaches, schlechte Performance, 

… 

Gründe vielfältig 

nicht die Inkompetenz der Manager und SW Entwickler 

im Gegenteil, in vielen großen (gescheiterten) Projekten waren Personen 

mit überdurchschnittlichen Fähigkeiten beteiligt (Brooks 75) 

SW Komplexität und Unterschätzen 

Ingenieursmethoden nicht direkt übertragbar auf SW 

- 22 -





Modelltheorie 

Modellierung 

Einsatz von Modellen 

Vorgehen bei der Modellierung 






- 23 -


Modelltheorie 

Modell und Original 

Ein Modell ist ein Abbild, ein Vorbild oder eine 

Repräsentation von etwas. 

Das abgebildete Etwas ist das Original; es kann real oder 

virtuell sein. 

Merkmale der Modellbildung 

Abbildungsmerkmal: Ein Modell ist eine Abbildung 

eines realen oder virtuellen Originals. 

Verkürzungsmerkmal: Modelle besitzen nicht alle 

Attribute des Originals, sondern beschränken sich auf 

relevante Attribute. 

Pragmatisches Merkmal: Welche Attribute ein Modell 

zeigt, hängt immer vom Einsatzzweck des Modells ab. 


- 24 -

Modellierung als Abbildung 

Beispiel 


Original 

Modellierung 


kontrastierte 

Attribute 

(Hervorhebung) 

Abbildung 

Modell 

präterierte 

Abbildungsvorbereich Attribute 

Abbildungsnachbereich 

(Abstraktion) 

transkodierte 

Attribute 

(neu belegte) 

Original: VW Mondo (virtuell) Modell: Karosserie-Modell 

präterierte Attribute abundante Attribute 

Motorleistung - Stoßfestigkeit 

Bremsweg - Entflammbarkeit 

abundante 

Attribute 

- 25 -


Pragmatisches Merkmal 

nicht alternative Darstellung 

z.B. Übersetzung eines Textes (englischDeutsch) versucht alle 

Informationen zu erhalten (Inhalt, Stil, …) 

gezielte Abstraktion 

Auswahl relevanter und für den Zweck irrelevanter Information 

Datenflussmodell beschreibt funktionale Transformation von Daten (aber 

nicht deren Struktur) 

ERM-Modell beschreibt Datenstrukturen, aber nicht die Funktionen eines 

Systems 

Zustandsmodell beschreibt Zustände mit Bedingungen für 

Zustandsübergänge, aber abstrahiert von Datenstrukturen 

- 26 -

Umgang mit Komplexität 


Einsatz von Modellen 

Wenn die Realität zu komplex ist, um sie mit vertretbarem Aufwand bei 

Bedarf zu überblicken und die Schlüsse daraus zu ziehen. 

Beispiel: Bewertung der Industrie durch Kennzahlen. 

Umgang mit Risiken 

Wenn eine anscheinend sinnvolle Änderung in der Realität zu riskant 

oder zu schwierig ist, um sie direkt herbeizuführen. 

Beispiel: Erstellung eines Gebäudes 

Risiko: dem Kunden gefällt das Gebäude nicht oder die Landschaft wird 

verschandelt. 

Es wird ein Modell angefertigt, das es gestattet, diese Risiken zu 

vermindern. 

Wir gehen also nicht direkt vom Ist-Zustand in den geplanten Zustand 

über, sondern zunächst in das deskriptive Modell (Vorbild). 


- 27 -


Vorgehen bei der Modellierung 

Original 

modifiziertes 

Original 

Originaloperation 

(riskant) 

Abbildung 

(Modellierung) 

Abbildung 

(Realisierung) 


Modelloperation 

Modell 

(Abbild) 

Modell 

(Vorbild) 

- 28 -







SW-Entwicklung als Prozess 

Software-Prozessmodelle 

Software Life Cycle 

Aktivitäten-orientierte Prozessmodelle 

Phasenmodelle 

Standard-Phasenmodell 

Inkrementelle Entwicklung 

Iterative Entwicklung 


1.6 V-Modell der SW-Entwicklung 


- 29 -


SW-Entwicklung als Prozess 

Software-Entwicklung ist ein Prozess 

Dieser ist arbeitsteilig (d.h. viele verschiedene Personen sind daran 

beteiligt). 

Am Ende des Prozesses steht das zu entwickelnde Produkt – das 

Software-System – zur Verfügung. 

SW-Entwicklungsprozess 

Definiert den Ablauf und die Organisationsstrukturen, in denen die 

Software erstellt und bearbeitet wird. 

Zentrale Bestandteile 

Aufgaben (Tätigkeiten) 

Was muss getan werden? 

Ergebnisse (Dokumente) 

Welche Zwischen- oder Endergebnisse sind zu entwickeln? 

Verantwortlichkeiten (Rollen) 

Wer erledigt die anfallenden Arbeiten? 


- 30 -

process 


Software-Prozessmodelle 

A sequence of steps performed for a given purpose; for example, the 

software development process. 

software development process 

The process by which user needs are translated into a software 

product. The process involves translating user needs into software 

requirements, transforming the software requirements into design, 

implementing the design in code, testing the code, and sometimes, 

installing and checking out the software for operational use. 

Note: These activities may overlap or be performed iteratively. 

Ein (Software-)Prozessmodell ist 

eine abstrakte Beschreibung ähnlicher Software-Prozesse, 

also eine Muster-Struktur für Organisation und Durchführung eines 

Software-Prozesses 


IEEE 

- 31 -


Software Life Cycle 

Produkt Lebenszyklus 

Jeder Gegenstand wird in einer Reihe von Schritten hergestellt. 

Am Anfang steht ein Wunsch, der konkretisiert wird. 

Dann wird die Struktur festgelegt und schließlich das Produkt angefertigt. 

Besteht es aus mehreren Teilen, so werden diese einzeln geprüft, montiert 

und als ganzes erneut geprüft. 

Schließlich wird das Produkt an den Kunden übergeben und in Betrieb 

genommen. Dabei kommt es öfter zu Modifikationen und Reparaturen. 

software life cycle 

The period of time that begins when a software product is conceived and ends 

when the software is no longer available for use. The software life cycle 

typically includes a concept phase, requirements phase, design phase, 

implementation phase, test phase, installation and checkout phase, operation 

and maintenance phase, and, sometimes, retirement phase. 

Note: These phases may overlap or be performed iteratively. 

software development cycle 

The period of time that begins with the decision to develop a software product 

and ends when the software is delivered. This cycle typically includes a 

requirements phase, design phase, implementation phase, test phase, and 

sometimes, installation and checkout phase. 


IEEE 

- 32 -


Software Life Cycle – Überblick - 1 

Analyse 

Spezifikation der Anforderungen 

Grobentwurf, Spezifikation der Module 

Feinentwurf 

Codierung und Modultest 

Integration, Test, Abnahme 


Betrieb, Wartung 

Auslauf, Ersetzung 

- 33 -



Analyse 

Durchdringen und Verstehen des Problems 

Wo kann Software bei der Problemlösung eingesetzt werden. 

Welche Aufgaben soll diese übernehmen 


Welche Anforderungen muss die Software erfüllen. 

Abstimmen der Anforderungen zwischen Auftragnehmer und 

Auftraggeber. 

Anforderungen bilden Arbeitsgrundlage. 

Grobentwurf, Spezifikation der Module 

Aufteilen des Systems in Module (Komponenten, Bausteine) 

Entwickeln der Software-Architektur 

Festlegen der Schnittstellen zwischen den Modulen 

Definition der Funktionalität der einzelnen Module 


- 34 -




Die einzelnen Module werden in der gewählten Programmiersprache codiert. 

Test auf Basis der Spezifiktion der Module. 

Korrigieren der entdeckten Fehler 

Integration, Test, Abnahme 

Zusammenbau des Systems auf Basis der Software-Architektur 

Test der festgelegten Schnittstellen 

Abnahme des Systems nach durchgeführtem Abnahmetest 

Betrieb und Wartung bzw. Weiterentwicklung 

Installation des Systems beim Auftraggeber 

Inbetriebnahme 

Korrektur der im Betrieb festgestellten Mängel 

Weiterentwicklung neuer Versionen 

Auslauf und Ersetzung 

Jedes Software-System wird irgendwann aus dem Betrieb genommen 

Rechtzeitige Planung eines Nachfolgesystems. 


- 35 -


Anforderungsspezifikation 

Systemanforderungen als Ganzes dokumentieren 

als Vertragsgrundlage, möglichst präzise, messbar 

Beteiligte 

Auftraggeber, Benutzer, Fachexperten, Software-Ingenieure, 

Betriebswirtschaftler (Manager), Betroffene (Umweltverbände…), … 

Anforderungsarten 

(abstrakte) funktionale Anforderungen 

Systemeigenschaften 

nicht-funktionale, sichtbare Eigenschaften des Systems 

Eigenschaften, die das System nicht haben darf 


- 36 -

Software-Entwurf und -implementierung 

Überführung der Spezifikation in ein ausführbares System 

Verzahnung 

Arhitekturentwurf 

System- 

Architektur 


Entwurfs- und Implementierungsaktivitäten 

Anforderungs_ 

spezifikation 

Abstrakte 

Spezifikation 

SW- 

Spezifikation 

Entwurfsaktivitäten 

Schnittstellenentwurf 

Schnittstellenspezifik. 

Komponentenentwurf 

Komponentenspezif. 

Entwurfsergebnisse 


Entwurf 

Datenstruktutren 

Datenstrukturen 

Entwurf 

Algorithmen 

Algorithmen 

- 37 -


Softwarevalidierung 

Verifikation 

(formale) Überprüfung, ob das System die Spezifikation erfüllt 

konstruieren wir das System richtig? 

Validation 

erfüllt das System die Anforderungen des Benutzers 

konstruieren wir das richtige System? 

mehrphasiges Testen 

Einzeltests 

Modultests 

Komponententest 

durch Programmierer 

Integrationstest 

durch Tester 

Subsystemtests 


Systemtest 

α -Test β -Test 

Benutzertest 

Abnahmetest 

- 38 -


Strukturierte Entwurfsmodelle 

es gibt verschiedene strukturierte Modelle 

Notationen für Zwischenergebnisse 

Erfahrungen im Umgang mit den Dokumenten (Versionen, Techn. 

Plattform, z.B. BSCW) 

Regeln zur systematischen Vorgehensweise 

z.T. werden diese Methoden durch Werkzeuge unterstützt 

Werkzeuge / Werkzeugsammlungen 

Integrierte Entwicklungsumgebungen 

CASE, insbesondere grafische Systemmodelle, Data Dictionaries, 

Debugging und Testen, automatische Transformationen 

Software Engineering bleibt kreative Tätigkeit 

nicht vollständig automatisierbar 

große Bedeutung der Kommunikation 


- 39 -


SW Prozessmodelle 

abstrakte Beschreibung des systematischen Vorgehens bei 

der SW Entwicklung 

ordnet die Aktivitäten 

nach logischen Kriterien 

nach Phasen 

nach zeitlicher Reihenfolge 

Regeln für die Aktivitäten 

Rollen und Zuständigkeiten 

Voraussetzungen und Ergebnisse von Aktivitäten 

in allen Modellen zumindest 

Anforderungsspezifikation (Requirements Engineering) 

Entwurf 

Implementierung 

Software-Validierung 


- 40 -

Aktivitäten-orientierte Prozessmodelle 

Wasserfall-Modell 

System- 

Analyse 


System- 

Spezifikation 

Werden Fehler Fehler davor davor 

liegender Tätigkeiten 

entdeckt, dann dann wird wird diese diese 

Tätigkeit erneut erneut 

aufgenommen. 

Ansatz erstes formalisiertes Modell (Royce 70) 

System- 

Entwurf 

Softwareentwicklung wird durch die Aktivitäten beschrieben 

Jede Aktivität produziert ein Ergebnis (oft ein Dokument) 

Aktivitäten werden zeitlich und inhaltlich geordnet 

In der Praxis gibt es mehrere Phasen 

übergreifende Iterationen! 

Modul-Spez. 

Entwurf 

Codierung 

Modultest 


Man Man beginnt beginnt oben oben links links 

und und arbeitet arbeitet sich sich nach nach 

rechts rechts unten unten vor. 

vor. 

Integration 

Systemtest 

Einsatz 

Wartung 

- 41 -

Grundlage 


Phasenmodelle 

Ordnet man die Aktivitäten eines Prozessmodells an der Zeitachse, so 

müssen Iterationen ausgeschlossen werden. 

Damit entsteht ein Phasenmodell. 

Vorteile 

Wird die Entwicklung und der Betrieb in Phasen eingeteilt, dann kann 

dadurch der Projektfortschritt besser bewertet und überprüft werden. 

Es erleichtert die organisatorische Durchführung eines Projektes. 

Phasen- oder Kostenmodell 

Die Software-Entwicklung wird vor Beginn in Phasen gegliedert, die 

zyklenfrei gekoppelt sind. 

Für jede Phase gibt es ein eigenes Budget. 

Beachte: Damit ist die spezielle Wahl und Reihenfolge der Phasen 

noch nicht festgelegt. 


- 42 -




Zuordnung der Tätigkeiten 

des Wasserfallmodells zu 

einzelnen Phasen 

"Einbahnstraßen"-Modell 

Jede Phase bezeichnet die 

wesentliche Tätigkeit 

Phasen enthalten 

unvermeidlich mehrere 

Tätigkeiten 

Meilenstein bezeichnet 

Übergabezeitpunkt und 

Form eines Dokuments 

sowie die Verantwortlichkeit 


Produktkonzeption 

Systemanalyse 


Systementwurf und Modulspezifikation 

Modulentwurf 


Integration und Systemtest 

Installation und Abnahmetest 

Betrieb und "Wartung" 

Außerbetriebnahme 

Entwicklungsprojekt 

Meilenstein 

- 43 -

Vor- und Nachteile von Phasenmodellen 

Management (Vorteile) 

leicht verständlich, intuitiv 

leicht kontrollierbar, wenig Managementaufwand 

Benutzerbeteiligung nur am Anfang (geringer Kommunikationsaufwand) 

einfache Verteilung auf jeweilige Expertengruppen 

Entwicklung (Nachteile) 

entspricht nicht dem natürlichen Problemlösen 

für größere Systeme unmöglich, das Ganze vollständig zu überblicken 

schriftliche Schnittstellen erzeugen hohen Aufwand 

Bedeutung der Dokumente zu hoher Stellenwert 

Anwendbarkeit 

in reiner Form kaum noch, allerdings immer noch die Grobstruktur für 

die meisten industriellen Projekte 

Wunsch des Managements, die Kontrolle zu haben, Instrumente, den 

Fortschritt zu bewerten, Budgetplanung durchzuführen, … 


- 44 -


Formalisierte Entwicklung 

sicherheitskritische Anwendungen 

Bsp. Cleanroom-Prozess 

Spezifikation erfolgt vollständig, detailliert und formal 

(mathematisches Modell) 

Entwicklung durch verifizierbare Transformationen bis zum 

ausführbaren Modell (z.T. automatisierbar) 

Formal transformations 

T1 T2 T3 T4 

Formal 

specification 

P1 

R1 

R2 

R3 

P2 P3 P4 

Proofs of transformation correctness 

Executable 

program 

Ian Sommerville: Software Engineering, 2000 

- 45 -


Wiederverwendungsmodelle 

zielen auf systematische Wiederverwendung 

Wiederverwendung ist üblich, aber ad-hoc 

WV-Modelle basieren auf der Verfügbarkeit wiederverwendbarer 

Komponenten CBD (komponentenbasierte Entwicklung) 

erfordern Kompromisse bei der Funktionserfüllung 

Schwerpunkt ist Auswahl geeigneter Komponenten und ihre Integration 

Nachteil 

Verlust der (vollständigen) Kontrolle 

Requirements 

specification 

Component 

analysis 

beinhaltet häufig den Erwerb kommerzieller 

Komponenten (off-shelf components) 

Requirements 

modification 

Development 

and integration 

System design 

with reuse 

System 

validation 


- 46 -


Prozesswiederholungen 

wiederholte Anwendung von Prozessschritten 

aufgrund von Fehlerbehebung oder 

evolutionärer, explorativer Ansätze 

generische Modelle 

Spiralmodell 

von einer groben Idee zum eingesetzten, validierten System 

inkrementelle / iterative Entwicklung 

in jeder Phase erfolgt eine schrittweise Erweiterung des (Zwischen-) 

Produkts 

in jedem Segment eine Tätigkeit, die zeitlich zu weiteren 

Konkretisierungen führt (gleiche Aktivität auf unterschiedlichen 

Abstraktionsebenen) 

- 47 -


Spiralmodell 

Boehm (IEEE 1988): 

betrachtet Risiken explizit 

umfasst andere Prozessmodelle 

Ziele 

Planung 

Determine objectives 

alternatives and 

constraints 

Plan next phase 

REVIEW 

Requirements plan 

Life-cycle plan 

Development 

plan 

Integration 

and test plan 

Risk 

analysis 

Risk 

analysis 

Risk 

analysis 

Risk 

analysis Proto- 

Prototype 2 

type 1 

Concept of 

Operation S/W 

requirements 

Requirement 

validation 

Design 

V&V 

Service 

Acceptance 

test 

Risikoanalyse 

Evaluate alternatives 

identify, resolve risks 

Prototype 3 

Operational 

protoype 

Simulations, models, benchmarks 

Product 

design 

Code 

Unit test 

Integration 

test 

Detailed 

design 

Develop, verify 

next-level product 

- 48 -

Evolutionäre Entwicklung (Prototyping) 

Wegwerfprototypen 

(revolutionär) vs. 

explorative 

Entwicklung 

(evolutionär) 

Outline 

description 

lediglich grobe Vorgaben 


Concurrent 

activities 

Specification 

Development 

Validation 


Initial 

version 

Intermediate 

versions 

Final 

version 

Schrittweise Verfeinerung der Spezifikation 

und der eingesetzten Systeme 

bindet Anwender ein! 

- 49 -



Vorteile der Phasen- und der evolutionären Modelle 

vereinigen 

einerseits strukturierter, verwaltbarer Prozess 

dennoch Verschieben der detaillierten Spezifikation weniger wichtiger 

Komponenten (näher am evolutionären Ansatz) 

"Produkt-Sicht" der Wiederholung 

grobe 

Anforderungsdef. 

Entwicklung einer 

Systemversion 

Anforderungen -> 

Subsysteme 

Validierung der 

Systemversion 

Validierung des 

Systems 

Entwurf 

Systemarchitektur 

Integration der 

Systemversion 

fertiges System 

- 50 -

Definition 



Die gesamte Funktionalität eines Systems wird in handhabbare Teile 

eingeteilt, die nacheinander – in Stufen - entwickelt werden. 

Feedback 

zielt ab auf Wiederholung von Prozessschritten 

Entwickeln 

Ausliefern 

Integrieren 

Antwort auf Probleme des “Wasserfall-Modells” 

kurze Entwicklungszeiten 

Feedback vom Anwender so früh wie möglich 

Vorteile 

Projektfortschritt wird durch ausführbare Systeme gezeigt. 

Jedes Inkrement implementiert eine Menge neuer Anforderungen. 


Ausbaustufe 

4 

Ausbaustufe 

3 

Kernsystem 

XP als 

Extermbeispiel 

- 51 -


Iterative Entwicklung 

Definition 

Kontrolliertes, stetiges Überarbeiten einer Software mit dem Ziel, 

Fehler zu beheben und Verbesserungen einzuarbeiten. 

Prozess-Sicht der Wiederholung 

“We get things wrong before we get them right” 

Antwort auf Probleme des “Wasserfall-Modells” 

Anforderungen lassen sich nicht vollständig und konsistent 

beschreiben. 

Der Einsatz eines Systems verändert die daran gestellten 

Anforderungen. 

Sog. Wartungsaktivitäten liegen nicht außerhalb der Entwicklung, 

sondern sind in die Entwicklung integriert. 


- 52 -

Diskussion iterativer, inkrementeller Modelle 

Vorteile 


wichtigste Teilfunktionalität schnell verfügbar 

Systemfunktionalität mit höchster Priorität zuerst verfügbar 

Ausbaustufen können variabel, je nach Bedarf hinzugenommen werden 

Nutzer eingebunden (partizipativ) 

Erfahrungen mit Einsatz im Betrieb, sich entwickelnde Anforderungen 

Nachteile / Probleme 

schwierig, Anforderungen auf geeignete Teilsysteme abzubilden 

gemeinsame Basisfunktionalität wird erst nach und nach erkennbar 

es entsteht ein "unstrukturiertes", barockes System 

Prozess nicht sichtbar und kaum plan- und verwaltbar, hoher Kommunik.-aufw. 

Anwendbarkeit 

Teilsysteme sollten klein genug sein 

bei größeren Systemen, gemischter Ansatz (Phasenmodelle mit evolutionären 

Anteilen für Teilsysteme und Wegwerf-Prototypen) 

gelegentliches Re-engineering notwendig 

- 53 -





1.5 Beispiel: Unified Process 



Beispiel eines iterativen und inkrementellen Prozesses 

Phasen und Iterationen 

UML Modelle im Unified Process 

1.6 Das V-Modell 


- 54 -

Inception Elaboration Construction Transition 

time 

Inception Define the scope of the project and 

develop business case 

Elaboration Plan project, specify features, and 

baseline the architecture 

Construction Build the product (series of releases) 

Transition Transition the product to its users 

(correcting defects, modifying ...) 


Unified Process: Lifecycle Phases 

Jacobsen, Applying UML 

- 55 -

Core Workflows 

Requirements 

Analysis 

Design 

Implementation 

Test 


UP: Phases, Workflow, Iterations 

Phases 


Preliminary 

Iteration(s) 

iter. 

#1 

iter. 

#2 

iter. 

... 

An iteration in the 

elaboration phase 

iter. 

... 

Iteration 

iter. 

#n-1 

Focus, emphasis 

iter. 

#n 

iter. 

... 

RUP 5.1 

- 56 -

Use case 

Model 


UP: Architecture and Iterations 

Design 

Model 

Implementation 

Model 

Content 

Deployment 

Model 


time 

Test 

Model 

- 57 -









Eigenschaften des V-Modells 

Struktur des V-Modells 

Die Submodelle des V-Modells 

Struktur des Submodells SE 


- 58 -


Eigenschaften des V-Modells 

Das V-Modell (Vorgehensmodell) ist Teil des 

Entwicklungsstandards für IT-Systeme des Bundes. 

Eigenschaften 

Das V-Modell ist als eine Weiterentwicklung des Standard- 

Phasenmodells ein aktivitätsorientiertes Modell. 

Das V-Modell ist ein Prozessmodell für Systementwicklungen (Hardund 

Software). 

Das V-Modell deckt nicht nur die technische Systementwicklung ab. 

Qualitätssicherung 

Konfigurationsmanagement 

Projektmanagement 

Das V-Modell unterstützt die inkrementelle Entwicklung. 

Das V-Modell ist als generisches Modell anpassbar 


- 59 -


Qualitätssicherung 

(QS planen, 

Produkte 

prüfen) 

Struktur des V-Modells 

Projektmanagement 

(Projekt initiieren, planen, kontrollieren, abschließen) 

Plan-/Istdaten 

Vorgaben 

Systemerstellung 

(Produkt 

entwickeln) 

Produkte 


Produkte 


Konfigurationsmanagement 

(Produkte und 

Änderungen 

verwalten) 


- 60 -


Die Submodelle des V-Modells 

Systemerstellung (SE) 

Beschreibt Entwicklung und Konstruktion eines Systems (Hard- und Software) 

Die Haupttätigkeiten dieses Submodells werden immer V-förmig dargestellt . 

Qualitätssicherung (QS) 

Fasst alle Aktivitäten zusammen, die durchgeführt werden müssen, damit die 

geforderte Qualität auch tatsächlich hergestellt wird. 

Konfigurationsmanagement (KM) 

In diesem Submodell werden die Aktivitäten aufgeführt, die notwendig sind, 

damit die Software-Einheiten des entstehenden Systems jederzeit eindeutig 

identifizierbar sind. 

Ebenfalls werden die Aktivitäten des Änderungsmanagements beschrieben. 

Projektmanagement (PM) 

Dieses Submodell definiert die Aktivitäten, die notwendig sind, um ein Projekt 

zu initiieren, es zu planen, den Projektfortschritt zu bewerten, zu steuern und zu 

dokumentieren, Unteraufträge zu vergeben und das Projekt abzuschließen. 


- 61 -

konstruierende 

Tätigkeiten 


Struktur des Submodells SE 

System- 

Anforderungsanalyse 

System- 

Entwurf 

SW/HW- 


SW-Grob- 

Entwurf 

SW-Fein- 

Entwurf 

SW-Implementierung 

System- 

Integration 

SW- 

Integration 

Überleitung 

in die 

Nutzung 


integrierende, 

prüfende 

Tätigkeiten 

- 62 -

Anforderungsspezifikation 

System- 

Entwurf 


Struktur des Submodells QS 

SW/HW- 


konstruierende 

Tätigkeiten 

SW-Grob- 

Entwurf 

Abnahmetestplan 

Integrationstestplan 

SW-Fein- 

Entwurf 

Subsystemtestplan 

SW-Implementierung 

System- 

Integration 

SW- 

Integration 

Überleitung 

in die 

Nutzung 


Abnahmetest 

Integrationstest 

integrierende, 

prüfende 

Tätigkeiten 

Komponententests 

- 63 -



Software ist ein technisches Produkt, das ingenieurmäßig 

entwickelt wird (werden sollte). 

Software Engineering 

Bei der SW-Entwicklung werden vielfältige Modelle 

eingesetzt. 

Modelle abstrahieren von Original und sind für einen Zweck gedacht. 

Vorgehensmodelle beschreiben, wie Software entwickelt 

werden kann 

Tätigkeiten und Phasen werden vorgegeben 

sequentiell, iterativ, inkrementell 

Das V-Modell definiert Submodelle, die nicht nur die 

konstruktiven Tätigkeiten beschreiben 

Qualitätssicherung, Konfigurationsverwaltung, Projektmanagement 

- 64 -

01intro

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?