Transcript Vorlesung

Bachelor Informatik (21)
Ralf-Oliver Mevius
Fallstudie
Prozessmodellierung (21.3)
Inf(21) WS10/11
Allgemeines- Teilgebiete der Softwaretechnik
Kernprozesse
1. Planung
2. Analyse
3. Entwurf
Ralf-Oliver Mevius
4. Programmierung
5. Validierung und Verifikation
Inf(21) WS10/11
Allgemeines- Teilgebiete der Softwaretechnik
Unterstützungsprozesse
6. Anforderungsmanagement
7. Projektmanagement
8. Qualitätsmanagement
Ralf-Oliver Mevius
9. Konfigurationsmanagement
10. Dokumentation
Inf(21) WS10/11
1. Planung
 Lastenheft (Anforderungsdefinition)
 Pflichtenheft (Mit technischen Ansätzen
verfeinertes Lastenheft)
Ralf-Oliver Mevius
 Aufwandsschätzung (z. B. mittels
Function-Point-Verfahren oder COCOMO)
 Vorgehensmodell
Inf(21) WS10/11
1. Planung - Lastenheft
Ralf-Oliver Mevius
 Ein Lastenheft (auch Anforderungsspezifikation,
Kundenspezifikation
oder
Requirements
Specification)
beschreibt
die
unmittelbaren
Anforderungen durch den Besteller eines Produktes.
Inf(21) WS10/11
1. Planung - Lastenheft
Ralf-Oliver Mevius
 Es enthält jedoch lediglich im Rahmen eines
Werkvertrages oder Werkliefervertrages und der
dazu gehörenden formellen Abnahme die
nachprüfbaren Leistungen und Lieferungen.
Inf(21) WS10/11
Ralf-Oliver Mevius
1. Planung - Lastenheft
 Es kann nicht die Erwartungen und
Wünsche an ein geplantes Produkt
enthalten.
 Diese abstrakten Merkmale wären, wenn
nicht durch eine Prüfung zu belegen,
kaum durch denjenigen, der das Produkt
herstellen soll, so einzuschätzen, dass sie
zielführend berücksichtigt werden könnten.
Inf(21) WS10/11
1. Planung - Lastenheft
 Gemäß DIN 69905 (Begriffe der
Projektabwicklung) beschreibt das
Lastenheft die
Ralf-Oliver Mevius
 „vom Auftraggeber festgelegte Gesamtheit
der Forderungen an die Lieferungen und
Leistungen eines Auftragnehmers innerhalb
eines Auftrages“.
Inf(21) WS10/11
1. Planung - Lastenheft
Ralf-Oliver Mevius
 Das Lastenheft beschreibt in der Regel
also, was und wofür etwas gemacht
werden soll (Fachkonzept). Die
Adressaten des Lastenhefts sind der
(externe oder firmeninterne) Auftraggeber
sowie die Auftragnehmer.
Inf(21) WS10/11
1. Planung - Lastenheft
Ralf-Oliver Mevius
 In der Softwaretechnik ist das Lastenheft
das Ergebnis der Planungsphase und wird
in der Regel einvernehmlich von den
Bestellern und den Entwicklern als
Vorstufe des Pflichtenhefts überarbeitet.
Inf(21) WS10/11
Ralf-Oliver Mevius
1. Planung - Lastenheft
 Um ein Lastenheft übersichtlich zu halten, wird es
vorzugsweise in knapp orientierendem Text gefasst und
mit Detaillierungen beispielsweise in tabellarischer Form,
mit Zeichnungen oder Grafiken ergänzt. Es gibt dazu
auch formalisierende Ansätze, wie die
Beschreibungssprache UML.
 Das Pflichtenheft beschreibt dann, was und womit etwas
realisiert werden soll. Dabei können gewöhnlich jeder
Anforderung des Lastenhefts eine oder mehrere
Leistungen des Pflichtenheftes zugeordnet werden. So
wird auch die Reihenfolge der beiden Dokumente im
Entwicklungsprozess deutlich: Die Anforderungen
(requirements) werden durch Leistungen (features)
erfüllt.
Inf(21) WS10/11
Ralf-Oliver Mevius
1. Planung - Lastenheft
 Nach DIN 69905 enthält das Pflichtenheft die „vom
Auftragnehmer erarbeiteten Realisierungsvorgaben
aufgrund der Umsetzung des vom Auftraggeber
vorgegebenen Lastenheftes“.
 Je nach Einsatzgebiet und Branche können sich
Lastenhefte in Aufbau und Inhalt stark unterscheiden.
Auch werden in der Praxis die Begriffe Lastenheft,
Pflichtenheft und Spezifikation oft nicht klar
gegeneinander abgegrenzt oder gar synonym
verwendet. Die unscharfe Verwendung der Begriffe
Lastenheft und Pflichtenheft sowie die fehlende
Trennung technischer Information und operationeller
Absichten ist häufig Ursache für Missverständnisse.
Inf(21) WS10/11
Ralf-Oliver Mevius
1. Planung - Lastenheft
 Auf einen Kaufvertrag nach BGB §433 oder einen
rechtlich gleichgestellten Liefervertrag sind die Kriterien
eines Lastenheftes in der Regel nicht anzuwenden, da
die Lieferungen im Kaufvertrag von einer durch den
Lieferanten einseitig vorgegebenen Spezifikation in der
Art und von der durch den Besteller einseitig
vorgegebenen Liefermenge bestimmt werden.
 Auf einen Dienstvertrag sind die Kriterien eines
Lastenheftes in der Regel nicht anzuwenden, da die
Leistungen im Dienstvertrag nicht einer formellen
Abnahme unterzogen werden.
Inf(21) WS10/11
1. Planung - Pflichtenheft






Ralf-Oliver Mevius

Das Pflichtenheft, auch Technische Richtlinien, Fachspezifikation, fachliche Spezifikation, Fachfeinkonzept, Sollkonzept,
Funktionelle Spezifikation, oder Feature Specification beschreibt die unmittelbaren Anforderungen durch den Besteller in der
Interpretation des Herstellers für sein Produkt. Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und
der dazu gehörenden formellen Abnahme die prüfbaren Leistungen und Lieferungen. Es kann, genauso wie das Lastenheft, nicht die
Erwartungen und Wünsche an ein geplantes Produkt enthalten. Solche abstrakten Merkmale wären, wenn nicht durch eine Prüfung oder
Messung zu belegen, durch denjenigen, der das Produkt herstellt, auch eher nicht so einzuschätzen, dass sie zielführend während der
Bearbeitung des Werkes und final bei der Abnahme berücksichtigt werden könnten.
Das Pflichtenheft ist die vertraglich bindende, detaillierte Beschreibung eines zu erstellenden Werkes, zum Beispiel des Aufbaus einer
technischen Anlage, der Konstruktion eines Werkzeugs oder auch der Erstellung eines Computerprogramms. Die dazu erforderliche
Arbeit liegt allein in der Verantwortung des Herstellers oder Auftragnehmers, diese ist zunächst nicht der Einrede des Bestellers oder
Auftraggebers unterworfen, es sei denn, beide arbeiten gemeinsam an dem zu erstellenden Werk.
Laut DIN 69905 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom
Auftraggeber vorgegebenen Lastenhefts“. Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes Pflichtenheft genannt) sind
nun präzisiert, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.
Das Pflichtenheft wird vom Auftragnehmer (Entwicklungsabteilung/-firma) formuliert und auf dessen Wunsch vom Auftraggeber bestätigt.
Idealerweise sollten erst nach dieser Bestätigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen. Der Auftragnehmer
hat einen durch den Vertrag bestimmten Anspruch auf solche Bestätigung (Mitwirkungspflicht nach §643 BGB).
Im Gegensatz zum technischen Design (auch technische Spezifikation – Wie wird es umgesetzt?) beschreibt das Pflichtenheft die
geplante technische Lösung – in unserem Beispiel die Software – als Black Box (Was wird umgesetzt?). Entsprechend enthält es in der
Regel nicht die betriebliche Lösung der Aufgabenstellungen des Auftraggebers. Schon gar nicht beschreibt es die (hier beim
Softwarebeispiel) Implementierungsprobleme, sondern allenfalls die Schnittstellen, deren sorgfältige Beschreibung solche Probleme
vermeiden soll.
Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Fälle
explizit ein- oder auszuschließen.
Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausführung des Werkvertrages oder auch des Kaufvertrages
beschließt. Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Software die Forderungen des
Pflichtenheftes in dem Verständnis des Bestellers erfüllt.
Wir d in der Vorlesung Synonym für eine kurze Beschreibung verwendet !
Inf(21) WS10/11
1. Planung - Aufwandsschätzung











Ralf-Oliver Mevius






Struktur der Kosten
Im Softwarebereich sind die Hauptkosten die Personalkosten; die Schätzung bezieht
sich daher hauptsächlich darauf.
Daneben gibt es noch Sachkosten (soweit nicht in den Personalkosten enthalten) wie
z. B.
benötigte Computer,
Rechenzeiten und Netzwerkkosten,
Lizenzen für Betriebssysteme und Tools,
Testhardware,
Kurse,
Reisekosten.
Diese hängen oft von den Personalkosten ab, denn je länger ein Projekt dauert, je
mehr Leute damit beschäftigt sind, desto mehr Sachkosten fallen auch an.
Für die zu erwartenden Gesamtkosten sind darauf noch erhebliche kaufmännische
Aufschläge erforderlich, so für
Realisierungsrisiko (Ein Großteil der IT-Projekte wird abgebrochen, ist nicht machbar
etc.)
Sicherheitsaufschlag für Fehleinschätzung (Eisberg-Faktor)
Vorfinanzierungskosten
Inflation, Personalkostensteigerung (bei länger laufenden Projekten)
Wechselkursrisiken (bei Auslandsprojekten)
weitere Aspekte…
Inf(21) WS10/11
1. Planung - Vorgehensmodell




Ralf-Oliver Mevius


Entwicklungsplan [Bearbeiten]
Da komplexe Software nur schwer zu erstellen und zu warten ist, bedienen sich
Softwareentwickler eines Planes zur Entwicklung von Software. Dieser Plan (das
Vorgehensmodell) unterteilt den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich
begrenzte Phasen. Die Software wird somit Schritt für Schritt fertiggestellt.
Vorgehensmodelle spalten einzelne Aktivitäten auf verschiedene Phasen im Entwicklungsprozess
auf und diese werden dann – u. U. mit geringen Modifikationen – einmal (z. B. Wasserfallmodell)
oder mehrmals durchlaufen (z. B. Spiralmodell). Bei mehrmaligen Durchläufen erfolgt eine
iterative (d. h. wiederholte) Verfeinerung der einzelnen Softwarekomponenten. Um die optimalen
Vorgehensmodelle herrscht Uneinigkeit. In der Regel trifft aber zu, dass die Betrachtungsweise
umso weniger mit der Praxis der Programmierung zu tun hat, je statischer und eindimensionaler
sie ist.
Vorgehensmodelle unterscheiden sich wesentlich in ihrem Detaillierungsgrad. Es sind OOTCApproach, Rational Unified Process, Rapid Application Development etc. detailliert ausgearbeitete
Vorgehensweisen, die den an der Entwicklung Beteiligten konkrete Arbeitsanweisungen an die
Hand geben. Das V-Modell nimmt diesbezüglich übrigens eine Zwitterstellung ein: Es ist sowohl
ein Prinzip (jeder Stufe der Entwicklung entspricht eine Testphase) als auch (wie zumeist
gebräuchlich) ein detailliertes Modell.
Die Agile Softwareentwicklung beschäftigt sich mit Methoden, die den Entwickler kreativ arbeiten
und Verwaltungsaspekte zurücktreten lassen. Alternative Softwaretechnologien (Universal
Application, Software Fabric u. ä.) verfolgen Ansätze, welche die konventionelle Vorgehensweise
von Softwareentwurf und anschließender Programmierung grundsätzlich in Frage stellen, indem
vorgefertigte universalisierte Software per Konfiguration an die jeweiligen Anforderungen
angepasst wird.
Es gibt verschiedene Bewertungsverfahren für den Softwareprozess, u. a. das Capability Maturity
Model (Integration) oder "Spice".
Inf(21) WS10/11
1. Planung - Vorgehensmodell





Ralf-Oliver Mevius








Typen von Vorgehensmodellen
Es gibt drei unterschiedliche Typen von Vorgehensmodellen:
Software-Entwicklungsprozesse dienen zur Steuerung einer Softwareentwicklung von der
Konzeption bis zum Einsatz im Echtbetrieb inklusive der im Echtbetrieb anfallenden Änderungen
einer Software. Eines der ältesten Modelle ist das Wasserfallmodell, das eine starre Abfolge der
einzelnen Phasen annimmt. Weiterentwicklungen wie das Spiralmodell sehen hingegen
Iterationen vor, d. h. ein und derselbe Arbeitsschritt (z. B. die Analyse) wird mehrmals durchlaufen
und die Ergebnisse des Arbeitsschrittes pro Durchlauf verfeinert und verbessert).
siehe auch: Liste von Softwareentwicklungsprozessen
Software-Lebenszyklusmanagement erweitert die Phasen über den gesamten Lebenszyklus
einer Software. Das Vorgehensmodell definiert die Anforderungen an gelebte Prozesse (das
"was") und beschreibt die konkreten, gelebten Prozesse (das "wie"). Dieser Typ ist eine Mischung
aus Ist-Beschreibung und normativer Vorgabe. Je nach Standardisierungsgrad werden
verschiedene Entwicklungsstufen vergeben. Unternehmen können sich diese Entwicklungsstufen
von externen Stellen zertifizieren lassen.
Norm ISO/IEC 12207
Capability Maturity Model (CMM)
Capability Maturity Model Integration (CMMI)
Softwareentwicklungs-Philosophie entspricht einer Programmierer-Philosophie, einem
bestimmten Ansatz, wie Software nach Ansicht der Proponenten am besten entwickelt werden
sollte. Diese Philosophien beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls
als Prozessmodell bezeichnet.
Extreme Programming
Prototyping (Softwareentwicklung)
Rational Unified Process
und weiteres…
Inf(21) WS10/11
2. Analyse
Anforderungsanalyse
Auswertung
Mock-up
Prozessanalyse / Prozessmodell
Systemanalyse
Strukturierte Analyse (SA)
Objektorientierte Analyse (OOA)
Ralf-Oliver Mevius







Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse - Anforderungsanalyse
 Das ingenieurmäßige Erheben der
Anforderungen (englisch requirements
engineering) ist ein Teil des Software- und
Systementwicklungsprozesses. Ziel ist es,
die Anforderungen des Auftraggebers an
das zu entwickelnde System (oft ein
Anwendungsprogramm) zu ermitteln und
zu verwalten.
Inf(21) WS10/11
2. Analyse - Anforderungsanalyse
 IEEE Die Anforderungserhebung kann in Anforderungsaufnahme
(requirements elicitation), Anforderungsanalyse (requirements
analysis), Anforderungsspezifikation (requirements specification)
und Anforderungsbewertung (requirements validation) unterteilt
werden. Diese Schritte überlappen einander und werden oft auch
mehrfach – iterativ – durchgeführt.
Ralf-Oliver Mevius
 SEI, Carnegie Mellon Das Software Engineering Institute der
Carnegie Mellon Universität unterscheidet in ihrem Capability
Maturity Model Integration das Management von Anforderungen,
und die Entwicklung der Anforderungen.
 Volere In dem von den Robertsons entwickelten Vorgehensmodell
existieren Anforderungsspezifikation, Stakeholder-Analyse,
Bedarfsanalyse, Analyse der Priorisierung, und die Aufzeichnung
der elementaren Anforderungen.
Inf(21) WS10/11
2. Analyse - Anforderungsanalyse


Sammeln, Analysieren
Beim Sammeln der Anforderungen (engl. elicitation) ist der
Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer
Bedeutung. Folgende Kriterien sind zu erfüllen:








Ralf-Oliver Mevius



vollständig - alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine
impliziten Annahmen des Kunden über das zu entwickelnde System geben.
eindeutig definiert / abgegrenzt - präzise Definitionen helfen, Missverständnisse zwischen
Entwickler und Auftraggeber zu vermeiden.
verständlich beschrieben - damit sowohl der Auftraggeber als auch der Entwickler mit
vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.
atomar - es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium
für ein "Atom" sollte die Entscheidbarkeit einer Anforderung sein.
identifizierbar - jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung
oder Nummer).
einheitlich dokumentiert - die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen
Dokumenten stehen oder unterschiedliche Strukturen haben.
notwendig - gesetzliche Vorschriften sind unabdingbar.
nachprüfbar - die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der
Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden (Ableitung von Testfällen
aus den Abnahmekriterien).
rück- und vorwärtsverfolgbar - damit einerseits erkennbar ist, ob jede Anforderung vollständig
erfüllt wurde und andererseits für jede implementierte Funktionalität erkennbar ist, aus welcher
Anforderung sie resultiert, also nicht Überflüssiges entwickelt wird.
Konsistenz - Konsistenz beschreibt den Grad, in dem die definierten Anforderungen
untereinander widerspruchsfrei sind.
Das Ergebnis der Anforderungsaufnahme ist das Lastenheft.
Inf(21) WS10/11
2. Analyse - Anforderungsanalyse
 Strukturierung und Abstimmung
 Nach der Erfassung muss eine Strukturierung und Klassifizierung
der Anforderungen vorgenommen werden. Damit erreicht man, dass
die Anforderungen übersichtlicher werden. Dies wiederum erhöht
das Verständnis von den Beziehungen zwischen den
Anforderungen. Kriterien sind hierbei:
 abhängig - Anforderungen müssen daraufhin überprüft werden, ob sie sich nur
gemeinsam realisieren lassen oder ob eine Anforderung die Voraussetzung für
eine andere ist.
 zusammengehörig - Anforderungen, die fachlich-logisch zusammengehören,
sollten nicht allein realisiert werden.
 rollenbezogen - jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen,
die damit unterstützt werden soll.
 Weitere Strukturierungsmöglichkeiten sind
Ralf-Oliver Mevius
 Funktionale und nichtfunktionale Anforderungen
 Fachlich motivierte (fachliche und technische) und technisch motivierte (nur
technische) Anforderungen.
 Die so strukturierten Anforderungen müssen dann zwischen Kunde
und Entwickler abgestimmt werden. Diese Abstimmung kann
gegebenenfalls zu einem iterativen Prozess werden, der zur
Verfeinerung der Anforderungen führt.
Inf(21) WS10/11
2. Analyse - Anforderungsanalyse
Ralf-Oliver Mevius
 Prüfung und Bewertung
 Nach der Strukturierung, zum Teil auch parallel dazu,
erfolgt die Qualitätssicherung der Anforderungen nach
diesen Qualitätsmerkmalen:
 korrekt - die Anforderungen müssen insbesondere widerspruchsfrei
sein.
 machbar - die Anforderung muss realisierbar sein.
 notwendig - was nicht vom Auftraggeber gefordert wird, ist keine
Anforderung.
 priorisiert - es muss erkennbar sein, welche Anforderungen am
wichtigsten sind. Ziel der Priorisierung ist es, häufig benötigte
Funktionen vor den weniger häufig benötigten bereitzustellen. Man
erreicht es über eine Quantifizierung der Funktionszweige.
 nutzbar, nützlich - auch bei teilweiser Realisierung soll bereits ein
produktives System entstehen.
 benutzerfreundlich - die Benutzerfreundlichkeit des Systems muss
sichergestellt sein.
 Das Ergebnis der Prüfung stellt die Basis für das
Pflichtenheft dar.
Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse - Anforderungsanalyse
 Requirements Management
 Requirements Management (RM, deutsch
„Anforderungsmanagement“) umfasst
Maßnahmen zur Steuerung, Kontrolle und
Verwaltung von Anforderungen. Dazu
gehört auch das verwalten von
Änderungen der Requirements und deren
Auswirkung auf abhängige
Lieferergebnisse.
Inf(21) WS10/11
2. Analyse - Auswertung






Ralf-Oliver Mevius


Auswertung (engl. evaluation als Beschreibung, Analyse und Bewertung) bezeichnet in der
Informatik den Vorgang, der einem Ausdruck (eventuell in einem gegebenen Kontext von
Variablenbindungen) einen Wert zuordnet.
Programmiersprachen sind nach ihrer Auswertungsstrategie unterscheidbar:
Bei strenger Auswertung oder strikter Auswertung (engl. eager bzw. strict evaluation) werden
Ausdrücke sofort ausgewertet. Z. B. bei der Berechnung einer Funktion werden bei strikter
Auswertung erst die Argumentausdrücke ausgewertet, bevor der Funktionsrumpf ausgewertet
wird.
Dem gegenüber steht die Bedarfsauswertung oder verzögerte Auswertung (engl. lazy
evaluation), bei der Ausdrücke erst ausgewertet werden, wenn deren Wert in einer Berechnung
benötigt wird. Dadurch lassen sich z. B. unendlich große Datenstrukturen (z. B. die Liste aller
natürlicher Zahlen, die Liste aller Primzahlen, usw.) definieren und bestimmte Algorithmen
vereinfachen sich. Diese Datenstrukturen bezeichnet man als Ströme (engl. streams).
Manche Berechnungen lassen sich mit strenger Auswertung, andere mit Bedarfsauswertung
effizienter ausführen.
Bei der Auswertung von Funktionen mit mehreren Argumenten, besteht ein weiterer Freiheitsgrad
darin, in welcher Reihenfolge die Argumente ausgewertet werden. In der Theoretischen Informatik
(Lambda-Kalkül) wird formal gezeigt, dass die Reihenfolge der Auswertung keine Rolle spielt, was
den berechneten Wert eines Ausdrucks angeht, so er denn ausgewertet werden kann; siehe auch
Currying bzw. Schönfinkeln.
Die Anwendung der Funktion (bzw. Funktionsdefinition) auf ihre Argumente bezeichnet man auch
als Applikation.
Eng verwandt mit dem Begriff der Auswertung ist der Begriff der Semantik, das ist eine Abbildung,
die einem Programm (meistens ein Programmtext bzw. Quellcode) seine berechenbare Funktion
zuordnet. Dieses stimmt mit der umgangssprachlichen Deutung des Begriffs Semantik als
Bedeutungszuordnung gut überein.
Inf(21) WS10/11
2. Analyse – Mock-up

Ralf-Oliver Mevius

Ein Mock-up in der Softwareentwicklung bezeichnet einen rudimentären
Wegwerfprototyp der Benutzeroberfläche einer zu erstellenden Software. Mock-ups
werden insbesondere in frühen Entwicklungsphasen eingesetzt, um Anforderungen
an die Benutzeroberfläche in Zusammenarbeit mit Auftraggeber und Anwendern
besser ermitteln zu können. Es handelt sich meist um ein reines Grundgerüst der
Bedienelemente ohne weitere Funktionalität.
Sogenannte Mock-Objekte werden beim Testen verwendet, was insbesondere beim
Unit test genutzt wird. Zu Beginn der Entwicklung werden sie als Platzhalter für noch
nicht vorhandene Objekte eingesetzt, wenn die noch nicht vorhandenen
Komponenten für das Testen eines anderen Moduls nötig sind (s. auch Test Driven
Development). In späteren Phasen kommen Mock-Objekte zur Anwendung, weil zum
Beispiel die Initialisierung des (vorhandenen, funktionsfähigen) Objekts zu aufwendig
oder in einer Testumgebung mangels Verbindung zu produktiven Backend-Systemen
gar nicht möglich ist. Ein weiterer häufiger Grund für den Einsatz eines MockObjektes ist ein nichtvorhersehbares Verhalten der eigentlichen Klasse, zum Beispiel
die Rückgabe des aktuellen Wechselkurses oder aber Verhalten, das aufgrund des
objektorientierten Prinzips der Kapselung vor dem Aufrufer der Methode abgeschirmt
wird; dies ist bei neueren Umgebungen wie J2EE vor allem bei Containerfunktionen
der Fall.
Inf(21) WS10/11
2. Analyse - Prozessanalyse





Ralf-Oliver Mevius












Als Prozessanalyse bezeichnet man die systematische Untersuchung von Geschäftsprozessen (lat. procedere =
voranschreiten) und die Zerlegung in seine Einzelteile, um Schwachstellen und Verbesserungspotentiale zu
erkennen. (vgl. Oberbegriff Analyse)
Die Prozessanalyse versucht durch das Zerlegen eines Vorgangs (vgl. Top-down-Methode) in seine Einzelschritte
einen eventuell aufgetretenen Fehler oder Ungereimtheiten in dem Gesamtprozess sichtbar und Fehlerkorrekturen
oder Verbesserungen möglich zu machen.
Hierdurch kann man Vereinheitlichungen in Standardprozessen erlangen und eine gruppenübergreifende
Synchronisation erreichen.
Besonders im Qualitätsmanagement ist es unabdingbar, bei auftretenden Fehlern möglichst schnell deren
Ursache(n) zu entdecken und Abstellmaßnahmen einzuleiten. Dieser kontinuierliche Verbesserungsprozess (KVP)
trägt dazu bei, auch bei verwandten Prozessen schnell und effizient einzugreifen, da Teilprozesse ähnlich oder
gleich sein können.
Prozessorientiertes Denken und Handeln ist ein wichtiger Bestandteil der modernen Marktwirtschaft. Nur so kann
man innerhalb eines kurzen Zeitraums flexibel agieren anstatt nur zu reagieren (Fehlervermeidung vor
Fehlerbeseitigung). Durch das vorausschauende Handeln können Probleme meist schon im Vorfeld gelöst
werden.
Die genaue Beschreibung von Prozessen ist hierbei genauso wichtig wie ihre ständige Pflege und Kontrolle. Durch
das Versehen von Prozessen mit Informationen wird darüber hinaus auch das Auffinden von Schlüsselindikatoren
erleichtert, die das Bewerten eines Prozesses zulassen.
Durchführung der Prozessanalyse. Die Prozessanalyse wird in zwei Schritten durchgeführt:
1. Istaufnahme der bestehenden Organisation
Hierfür werden Organisations- und Arbeitsunterlagen ausgewertet und gegebenenfalls
Mitarbeiterinterviews durchgeführt.
2. Istanalyse der Prozesse Folgende Methoden werden zum Beispiel eingesetzt:
Benchmarking
Schwachstellenanalyse
Workflowanalyse
Checklistentechnik
Referenzanalyse
Vorgangskettenanalyse
Inf(21) WS10/11
2. Analyse - Prozessmodell





Ralf-Oliver Mevius

Ein Vorgehensmodell zur Softwareentwicklung (auch Prozessmodell) ist ein für die Softwareentwicklung
angepasstes Vorgehensmodell. Es dient dazu, die Softwareentwicklung übersichtlicher zu gestalten und in der
Komplexität beherrschbar zu machen.
Entwicklungsplan
Da komplexe Software nur schwer zu erstellen und zu warten ist, bedienen sich Softwareentwickler eines Planes
zur Entwicklung von Software. Dieser Plan (das Vorgehensmodell) unterteilt den Entwicklungsprozess in
überschaubare, zeitlich und inhaltlich begrenzte Phasen. Die Software wird somit Schritt für Schritt fertiggestellt.
Vorgehensmodelle spalten einzelne Aktivitäten auf verschiedene Phasen im Entwicklungsprozess auf und diese
werden dann – u. U. mit geringen Modifikationen – einmal (z. B. Wasserfallmodell) oder mehrmals durchlaufen
(z. B. Spiralmodell). Bei mehrmaligen Durchläufen erfolgt eine iterative (d. h. wiederholte) Verfeinerung der
einzelnen Softwarekomponenten. Um die optimalen Vorgehensmodelle herrscht Uneinigkeit. In der Regel trifft
aber zu, dass die Betrachtungsweise umso weniger mit der Praxis der Programmierung zu tun hat, je statischer
und eindimensionaler sie ist.
Vorgehensmodelle unterscheiden sich wesentlich in ihrem Detaillierungsgrad. Es sind OOTC-Approach, Rational
Unified Process, Rapid Application Development etc. detailliert ausgearbeitete Vorgehensweisen, die den an der
Entwicklung Beteiligten konkrete Arbeitsanweisungen an die Hand geben. Das V-Modell nimmt diesbezüglich
übrigens eine Zwitterstellung ein: Es ist sowohl ein Prinzip (jeder Stufe der Entwicklung entspricht eine Testphase)
als auch (wie zumeist gebräuchlich) ein detailliertes Modell.
Die Agile Softwareentwicklung beschäftigt sich mit Methoden, die den Entwickler kreativ arbeiten und
Verwaltungsaspekte zurücktreten lassen. Alternative Softwaretechnologien (Universal Application, Software Fabric
u. ä.) verfolgen Ansätze, welche die konventionelle Vorgehensweise von Softwareentwurf und anschließender
Programmierung grundsätzlich in Frage stellen, indem vorgefertigte universalisierte Software per Konfiguration an
die jeweiligen Anforderungen angepasst wird.
Es gibt verschiedene Bewertungsverfahren für den Softwareprozess, u. a. das Capability Maturity Model
(Integration) oder "Spice".
Inf(21) WS10/11
2. Analyse - Prozessmodell





Ralf-Oliver Mevius







Typen von Vorgehensmodellen
Es gibt drei unterschiedliche Typen von Vorgehensmodellen:
Software-Entwicklungsprozesse dienen zur Steuerung einer Softwareentwicklung von der
Konzeption bis zum Einsatz im Echtbetrieb inklusive der im Echtbetrieb anfallenden Änderungen
einer Software. Eines der ältesten Modelle ist das Wasserfallmodell, das eine starre Abfolge der
einzelnen Phasen annimmt. Weiterentwicklungen wie das Spiralmodell sehen hingegen
Iterationen vor, d. h. ein und derselbe Arbeitsschritt (z. B. die Analyse) wird mehrmals durchlaufen
und die Ergebnisse des Arbeitsschrittes pro Durchlauf verfeinert und verbessert).
siehe auch: Liste von Softwareentwicklungsprozessen
Software-Lebenszyklusmanagement erweitert die Phasen über den gesamten Lebenszyklus
einer Software. Das Vorgehensmodell definiert die Anforderungen an gelebte Prozesse (das
"was") und beschreibt die konkreten, gelebten Prozesse (das "wie"). Dieser Typ ist eine Mischung
aus Ist-Beschreibung und normativer Vorgabe. Je nach Standardisierungsgrad werden
verschiedene Entwicklungsstufen vergeben. Unternehmen können sich diese Entwicklungsstufen
von externen Stellen zertifizieren lassen.
Norm ISO/IEC 12207
Capability Maturity Model (CMM)
Capability Maturity Model Integration (CMMI)
Softwareentwicklungs-Philosophie entspricht einer Programmierer-Philosophie, einem
bestimmten Ansatz, wie Software nach Ansicht der Proponenten am besten entwickelt werden
sollte. Diese Philosophien beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls
als Prozessmodell bezeichnet.
Extreme Programming
Prototyping (Softwareentwicklung)
Rational Unified Process
Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse – Systemanalyse
 Die Systemanalyse ist eine praktisch anwendbare
Methode der Systemtheorie. Dabei konstruiert der
Betrachter des Systems ein Modell eines bereits
existierenden oder geplanten Systems zunächst als
Black Box und verfeinert dieses im weiteren Verlauf.
Dabei hat der Bearbeiter eine Auswahl bezüglich der
relevanten Elemente und Beziehungen des Systems zu
treffen. Das erstellte Modell ist immer ein begrenztes,
reduziertes, abstrahiertes Abbild der Wirklichkeit, mit
dessen Hilfe Aussagen über vergangene und zukünftige
Entwicklungen und Verhaltensweisen des Systems in
bestimmten Szenarien gemacht werden sollen. Der
Vorgang ist auf nahezu jedes System anwendbar,
einschließlich Physik, Biologie, Demographie, Wirtschaft,
Geographie, Technik und Informatik.
Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse – Systemanalyse
 Was ist Systemanalyse?
 Der ganzheitliche Ansatz Systemanalyse ist ein iterativer,
heuristischer und rückgekoppelter Prozess der durch die
Dimensionen: Organisation, Technologie und Motivation
gekennzeichnet werden kann.
 Arbeitsschritte einer Systemanalyse
 Festlegen der Systemgrenzen zur Unterscheidung von System und
Umwelt.
 Feststellen derjenigen Systemelemente, die für die Fragestellung
als relevant betrachtet werden.
 Feststellen derjenigen Beziehungen zwischen den
Systemelementen, die für die Fragestellung als relevant betrachtet
werden.
 Feststellen der Systemeigenschaften auf der Makroebene.
 Feststellen der Beziehungen des Systems zur Umwelt bzw. zu
anderen Systemen, wenn von der Betrachtung des Systems als
isoliertes oder geschlossenes System zum offenen System
übergegangen wird.
Inf(21) WS10/11
2. Analyse – Systemanalyse









Datenflussdiagramm, stellt die Verarbeitung und Speicherung der Datenströme dar.

STD (State Transition Diagram)

ERD (Entity Relationship Diagram)

ESTD (Entity State Diagram)




Ralf-Oliver Mevius
Darstellung
Darstellung der Analyseergebnisse:
qualitativ: Concept-Map, Flussdiagramm, Wirkungsdiagramme
halbquantitativ: Pfeildiagramm (je-desto-Beziehungen)
quantitativ: x-y-, x-t-Diagramme u. a., mathematische Gleichungssysteme
Für die Systemanalyse werden formale Methoden und graphische Methoden eingesetzt.
Edwards behilft sich in seinem Werk mit den folgenden Elementen, um damit diverse MusterSysteme darzustellen:
DFD (Data Flow Diagramm)



Zustandsübergangsdiagramm, zeigt zeitliches Verhalten.
Gegenstands-Beziehungs-Diagramm, stellt Datenverknüpfungen zueinander dar.
Gegenstands-Zustands-Diagramm, als Mischform aus STD und ERD. Zeigt Statusänderungen in
Abhängigkeit von zeitlichen Ereignissen.
Weiterhin benennt er noch die folgenden theoretisch möglichen Kombinationen, die aber praktisch
nur sehr begrenzt zweckdienlich sind:
Zuordnung zwischen Datenstromdarstellung und Datenspeichern (zur Verifikation).
Zeitliche Veränderung der Datenverarbeitung durch Steuersignale (zur Funktionskontrolle).
Die Herleitung von Zuständen („States“) durch Ereignisse („Events“) und umgekehrt ist möglich.
Eine ständige Begrenzung auf eine für die jeweilige Detailierungsebene sinnvolle Elementmenge
ist nötig um zu einem tauglichen, sprich durchschaubaren und damit brauchbaren Ergebnis zu
kommen. Die Darstellung unterscheidet zwischen Steuerströmen, Datenströmen,
Augenblicksereignissen und physikalischen Strömen von Materie oder Energie.
Inf(21) WS10/11
2. Analyse – Strukturierte Analyse (SA)
Ralf-Oliver Mevius
 Die Strukturierte Analyse (SA) ist eine hauptsächlich von Tom
DeMarco entwickelte Methode zur Erstellung einer formalen
Systembeschreibung im Rahmen der Softwareentwicklung. Sie wird
während der Analysephase eines Software-Projekts eingesetzt.
Strukturiertes Design verfeinert die Ergebnisse der SA soweit, dass
sie dann umgesetzt werden können. Sie ist eine Methode der
Systemanalyse.
 Das Ergebnis der Strukturierten Analyse ist ein hierarchisch
gegliedertes technisches Anforderungsdokument für das
Systemverhalten. Die Strukturierte Analyse ist eine graphische
Analysemethode, die mit Hilfe eines Top-Down-Vorgehens ein
komplexes System in immer einfachere Funktionen bzw. Prozesse
aufteilt und gleichzeitig eine Datenflussmodellierung durchführt. In
ihrer Grundform ist die SA eine statische Analyse, die jedoch später
um Methoden für dynamische Analysen erweitert wurde.
Inf(21) WS10/11
2. Analyse – Strukturierte Analyse (SA)






Ralf-Oliver Mevius






Strukturierte Analyse
In der Strukturierten Analyse werden folgenden Elemente verwendet:
Kontextdiagramm (engl. Context-Diagram): Dieses Diagramm ist die Wurzel des Analyse-Baums.
Es grenzt das System von seiner Umwelt ab und definiert damit, welche Aspekte von der Analyse
betrachtet werden und welche nicht.
Datenflussdiagramm (engl. Data Flow Diagram, kurz DFD): Ein DFD visualisiert in welche
Teilprozesse sich der auf dem DFD dargestellte Prozess aufteilt und wie die Verwendung der
Daten in diesem Prozess abläuft.
Minispezifikation (engl. Mini-Specification): Die Mini-Spec ist eine formale Beschreibung eines im
Rahmen der Analyse nicht mehr weiter geteilten Elementarprozesses. Die Beschreibung erfolgt
mit Hilfe eines Pseudocodes, der nicht genormt ist und sich im Regelfall an der später
verwendeten Programmiersprache orientiert. Weitere Möglichkeiten der Beschreibung sind
Entscheidungstabellen und Entscheidungsbäume.
Datenwörterbuch (engl. Data Dictionary, kurz DD): Eine Sammlung aller Datendefinitionen, die in
der Analyse verwendet werden.
Die ersten beiden Diagramme verwenden folgende grafischen Elemente:
Datenfluss, dargestellt als ein Pfeil
Daten, Beschriftung am Pfeil
Speicher, zwei parallele waagerechte Linien, dazwischen der Name des Speichers
Teil- und Elementarprozesse, Kreis mit dem Namen und der Nummer des Teilprozesses in dem
Kreis
Externe Datenempfänger/sender (nur auf dem Kontextdiagramm), Viereck mit eingeschlossenem
Namen
Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse – Strukturierte Analyse (SA)
 Strukturierte Real-Time-Analyse (RT)
Die Strukturierte Real-Time-Analyse
erweitert die normale strukturierte Analyse
um eine Echtzeitkomponente. Erreicht
wird dies durch die Festlegung des
Verhaltens der Prozessschicht unter allen
möglichen externen und internen
Bedingungen und Betriebsarten.
Entworfen wurde das System von Imtiaz
A. Pirbhai und Derek J. Hatley.
Inf(21) WS10/11
2. Analyse – Strukturierte Analyse (SA)






Ralf-Oliver Mevius

Dynamische Analyse
Neben den Definitionen der Statischen Analyse werden zusätzlich folgende Elemente
definiert:
Entscheidungstabelle (engl. Decision Table, kurz DT): Aus mehreren Eingangswerten
wird in tabellarischer Form definiert wie der Ausgangswert gesetzt wird.
Zustandsübergangsdiagramm (engl. State Transition Diagram, kurz STD): Zustände
werden auf diesem Diagramm als Vierecke und Übergänge als Pfeile dargestellt. Das
STD hat Eingangs- und Ausgangswerte, die in Abhängigkeit von den Übergängen
und Zuständen gesetzt werden.
Prozessaktivierungstabelle (engl. Process Activation Table, kurz PAT): Die Tabelle
beschreibt die Reihenfolge der Aktivierung der in der Tabelle aufgezählten Prozesse.
Ein DFD beinhaltet stets nur eine PAT und beliebig viele DT und STD. Alle drei
neuen Elemente werden grafisch durch einen senkrechten Strich dargestellt. Pfeile
von links sind die Eingangs-, Pfeile nach rechts die Ausgangsparameter.
Kontrollflüsse (engl. Control Flow): Dargestellt als gestrichelter Pfeil werden über
Kontrollflüsse nur Daten mit Boolescher Definition gesendet. Diese dienen der
Ansteuerung der DT und STD und tragen selbst keine wahren Daten, sondern dienen
nur der Modellierung des dynamischen Ablaufs.
Inf(21) WS10/11
Ralf-Oliver Mevius
2. Analyse – Strukturierte Analyse (SA)
 Verwendung in der Praxis
 Eins der größten Softwareprojekte, die mit Hilfe
der Strukturierten Analyse in Deutschland
realisiert wurden, ist die Software für den
Zentralrechner des Kampfflugzeugs Tornado.
 Ansonsten ist die Strukturierte Analyse vielerorts
durch die Unified Modeling Language abgelöst,
wird aber noch in vielen Projekten eingesetzt.
 Softwaretools
 Innovator von MID
 case/4/0 von microTOOL
Inf(21) WS10/11
2. Analyse – OO Analyse und Design


Ralf-Oliver Mevius

Objektorientierte Analyse und Design (OOAD) ist eine Phase der
objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der
Domänenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs
(Objektorientiertes Design) aufgliedert.
In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben,
die das zu entwickelnde Softwaresystem erfüllen soll. Stark vereinfacht ausgedrückt
sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und überprüft
sie. Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software
Requirements Specification. Das darauf aufbauende Objektorientierte Analysemodell
(OOA-Modell) ist eine fachliche Beschreibung mit objektorientierten Konzepten, oft
mit Elementen der Unified Modeling Language (UML) notiert. Es hebt das
Wesentliche hervor und lässt Unwichtiges weg. Ein Bezug zur Informationstechnik ist
in dieser Phase ausdrücklich unerwünscht. Das OOA-Modell kann ein statisches
und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der
Benutzerschnittstelle enthalten.
Beim objektorientierten Design wird das in der Analyse erstellte Domänenmodell
weiterentwickelt und darauf aufbauend ein Systementwurf erstellt. Das Design
berücksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse
auch technische Gegebenheiten. In einem Wasserfall-Vorgehensmodell folgt als
nächste Phase die objektorientierte Programmierung (OOP).
Inf(21) WS10/11
2. Analyse – OO Analyse und Design



Ralf-Oliver Mevius


Vorgehensmodelle
Hauptartikel: Vorgehensmodell (Software)
Mehrere Autoren und Hersteller kommerzieller Werkzeuge haben versucht,
den Entwicklern durch die Beschreibung von Vorgehensmodellen eine
Sammlung von Werkzeugen an die Hand zu geben, die dazu dienen soll,
die Zusammenarbeit der an der Entwicklung Beteiligten zu verbessern, die
Kommunikation mit dem Kunden zu verbessern, das Verständnis für den
eigenen Entwurf zu vertiefen und die Dokumentation zu standardisieren.
UML
Der Erfolg stellte sich ein, als in der Firma Rational Software Corporation
die drei dominanten Autoren James Rumbaugh, Grady Booch und Ivar
Jacobson zusammen eine erste Version der vereinigten
Modellierungssprache Unified Modeling Language (UML) erarbeiteten. Sie
haben sich auf eine gemeinsame Notation zur Darstellung von
Modellierungsergebnissen geeinigt. UML ist mittlerweile durch die Object
Management Group (OMG) standardisiert und hat sich in der Praxis
bewährt und durchgesetzt. Allerdings ist auch UML eher ein
Werkzeugkasten als ein klares Vorgehensmodell.
Inf(21) WS10/11
3. Entwurf
 Softwarearchitektur
 Strukturiertes Design (SD)
 Objektorientiertes Design (OOD)
Ralf-Oliver Mevius
 Unified Modeling Language (UML)
 Fundamental Modeling Concepts (FMC)
Inf(21) WS10/11
3. Entwurf – Softwaerarchitektur


Ralf-Oliver Mevius





Eine Softwarearchitektur beschreibt die grundlegenden Komponenten und deren
Zusammenspiel innerhalb eines Softwaresystems. Eine Definition von Helmut Balzert beschreibt
den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie
Beschreibung ihrer Beziehungen“ (Lit.: Balzert, S. 716). Die beschriebenen Komponenten bilden
eine Zerlegung des Gesamtsystems, d. h., jedes Softwareelement ist einer
Architekturkomponente eindeutig zugeordnet. Die Softwarearchitektur ist zu unterscheiden vom
Softwareentwurf. Während sich Entwurfsentscheidungen auf lokale Aspekte innerhalb des
architektonischen Rahmens der Software beziehen, ist die Softwarearchitektur eine globale
Eigenschaft des Gesamtsystems.
Im Rahmen der Softwareentwicklung repräsentiert die Softwarearchitektur die früheste
Softwaredesign-Entscheidung (Architekturentwurf). Sie wird wesentlich durch nicht-funktionale
Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt. Eine
einmal eingerichtete Softwarearchitektur ist später nur mit hohem Aufwand abänderbar. Die
Entscheidung über ihr Design ist somit eine der kritischsten und wichtigsten Punkte im
Entwicklungsprozess einer Software. Zur grafischen Visualisierung von Softwarearchitekturen
werden unterschiedliche Methoden eingesetzt. Beispielsweise:
Unified Modeling Language (UML)
Fundamental Modeling Concepts (FMC)
Mit der Bewertung von Softwarearchitekturen befasst sich die Softwarearchitekturbewertung.
Beispiel [Bearbeiten]
Eine Architekturbeschreibung umfasst etwa im Falle einer Web-Anwendung den Aufbau des
Systems aus Datenbanken, Web-/ Application-Servern, E-Mail- und Cachesystemen − siehe etwa
Wikipedia selbst − wobei häufig auch Diagramme (z. B. in der Unified Modeling Language) zum
Einsatz kommen.
Inf(21) WS10/11
3. Entwurf – Strukturiertes Design




Ralf-Oliver Mevius






Strukturiertes Design (SD) ist ein Entwurfsmuster in der Softwaretechnik nach Edward Yourdon und Larry Constantine, welches
modulares Design unterstützt, um neben der reinen Funktionshierarchie auch die Wechselwirkungen von übergeordneten Modulen zu
beschreiben. SD wird mit der Strukturierten Analyse (SA) in der Softwaretechnik verwendet.
Das Strukturierte Design schlägt eine Brücke zwischen der technologieneutralen Analyse und der eigentlichen Implementierung. Im
Strukturierten Design werden technische Randbedingungen eingebracht und die Grobstruktur des Systems aus technischer Sicht
festgelegt. Es stellt damit die inhaltliche Planung der Implementierung dar.
Die Methodik stellt mittels Strukturdiagrammen funktionale Module hierarchisch dar und zeigt dadurch die einzelnen Aufrufhierarchien der
Module untereinander. Ein funktionales Modul besteht aus einer oder mehreren funktionalen Abstraktionen. Diese wiederum stellt eine
der ersten Abstraktionsmechanismen dar und gruppiert mehrere zusammengehörende Programmbefehle zu Einheiten (Funktionen). Ein
Beispiel wäre die Berechnung der Quadratwurzel sqrt(x). Der Benutzer muss keine Details über die Implementierung wissen, sondern
wendet die Funktion nur an. Dafür benötigt er eine entsprechende Schnittstellenbeschreibung, die ebenso zum Strukturierten Entwurf
gehört wie das Erstellen der Modulhierarchie. Ein Funktionales Modul besitzt kein internes Gedächtnis, das heißt es beinhaltet keine
Daten (private Daten), die nur im Modul sichtbar sind. Es kann nur in globalen Daten Informationen hinterlegen (beispielsweise bei der
Berechnung einer Zufallszahl). Spätere darauf aufbauende Methoden, wie das Modulare Design (MD), führen abstrakte Datentypen und
Datenobjekte ein.
Bei Banken, Versicherungen und im Embedded-Bereich finden noch viele Systementwicklungen mit strukturierten Methoden statt.
Insbesondere im Bereich des m-Business werden oft Rechnersysteme verwendet, die über limitierte Ressourcen verfügen, für die eine
objektorientierte Realisierung mit ihrem Overhead zu teuer ist. Weiterhin sind im Rahmen der Integration von bestehenden Anwendungen
im Rahmen von EAI oft Teilsysteme zu realisieren, die nicht mit objektorientierten Sprachen umgesetzt werden können. Daher würden
objektorientierte Analyse und Design falsche Implementierungsvorbereitungen darstellen.
Funktionsorientierte Methode
Aufgaben werden top-down in Teilaufgaben zerlegt und dann diese auf die Module abgebildet (Prinzip der Modularisierung).
Beschreibungsmittel sind Strukturdiagramme in denen die Module und die Verbindungen zwischen Modulen dargestellt werden.
Beispiel [Bearbeiten]
Menü Kundenverwaltung wird unterteilt in Formular Kunde und Bericht Kunde.
Formular Kunde wird erneut unterteilt in Aktualisieren und Umsatzrabatt, Bericht Kunde in Seitenansicht und Drucken.
Inf(21) WS10/11
3. Entwurf – OO Design


Ralf-Oliver Mevius

Objektorientierte Analyse und Design (OOAD) ist eine Phase der
objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der
Domänenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs
(Objektorientiertes Design) aufgliedert.
In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben,
die das zu entwickelnde Softwaresystem erfüllen soll. Stark vereinfacht ausgedrückt
sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und überprüft
sie. Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software
Requirements Specification. Das darauf aufbauende Objektorientierte Analysemodell
(OOA-Modell) ist eine fachliche Beschreibung mit objektorientierten Konzepten, oft
mit Elementen der Unified Modeling Language (UML) notiert. Es hebt das
Wesentliche hervor und lässt Unwichtiges weg. Ein Bezug zur Informationstechnik ist
in dieser Phase ausdrücklich unerwünscht. Das OOA-Modell kann ein statisches
und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der
Benutzerschnittstelle enthalten.
Beim objektorientierten Design wird das in der Analyse erstellte Domänenmodell
weiterentwickelt und darauf aufbauend ein Systementwurf erstellt. Das Design
berücksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse
auch technische Gegebenheiten. In einem Wasserfall-Vorgehensmodell folgt als
nächste Phase die objektorientierte Programmierung (OOP).
Inf(21) WS10/11
3. Entwurf - UML





Ralf-Oliver Mevius



Die Unified Modeling Language (UML, engl. Vereinheitlichte Modellierungs-Sprache) ist eine
von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die
Modellierung von Software und anderen Systemen. Im Sinne einer Sprache definiert die UML
dabei Bezeichner für die meisten Begriffe, die für die Modellierung wichtig sind, und legt mögliche
Beziehungen zwischen diesen Begriffen fest. Die UML definiert weiter grafische Notationen für
diese Begriffe und für Modelle von statischen Strukturen und von dynamischen Abläufen, die man
mit diesen Begriffen formulieren kann.
Die UML ist heute eine der dominierenden Sprachen für die Modellierung von betrieblichen
Anwendungssystemen (Softwaresystemen). Der erste Kontakt zur UML besteht häufig darin, dass
Diagramme der UML im Rahmen von Softwareprojekten zu erstellen, zu verstehen oder zu
beurteilen sind:
Projektauftraggeber und Fachvertreter prüfen und bestätigen zum Beispiel Anforderungen an ein
System, die Wirtschaftsanalytiker in Anwendungsfalldiagrammen der UML festgehalten haben.
Softwareentwickler realisieren Arbeitsabläufe, die Wirtschaftsanalytiker in Zusammenarbeit mit
Fachvertretern in Aktivitätsdiagrammen beschrieben haben.
Systemingenieure installieren und betreiben Softwaresysteme basierend auf einem
Installationsplan, der als Verteilungsdiagramm vorliegt.
Die graphische Notation ist jedoch nur ein Aspekt, der durch die UML geregelt wird. Die UML legt
in erster Linie fest, mit welchen Begriffen und welchen Beziehungen zwischen diesen Begriffen
sogenannte Modelle spezifiziert werden – Diagramme der UML zeigen nur eine graphische Sicht
auf Ausschnitte dieser Modelle. Die UML schlägt weiter ein Format vor, in dem Modelle und
Diagramme zwischen Werkzeugen ausgetauscht werden können.
Ein Vorgehensmodell, welches die UML anwendet, kann wegen der strengen Formalisierung kein
agiler Prozess sein.
…
Inf(21) WS10/11
Ralf-Oliver Mevius
3. Entwurf – Fundamental
Modeling Concepts
 Fundamental Modeling Concepts (FMC) ist eine semiformale Methodik zur Kommunikation über komplexe
Softwaresysteme.
 Seit Ende der 1970er Jahre wurden ihre Grundlagen von
Siegfried Wendt und seinen Mitarbeitern und Schülern
an der Universität Kaiserslautern entwickelt. Am 1999
unter Leitung von Siegfried Wendt gegründeten HassoPlattner-Institut an der Universität Potsdam wurden
diese Konzepte zunächst unter dem Namen SPIKES
(Structured Plans for Improving Knowledge Transfer in
Engineering of Systems) gelehrt, bevor sie im Jahre
2001 den Namen FMC (Fundamental Modeling
Concepts) erhielten.
 …
Inf(21) WS10/11
4. Programmierung
 Normierte Programmierung
 Strukturierte Programmierung
 Objektorientierte Programmierung (OOP)
Ralf-Oliver Mevius
 Funktionale Programmierung
Inf(21) WS10/11
5. Validierung und Verifikation
 Modultests (Low-Level-Test)
 Integrationstests (Low-Level-Test)
 Systemtests (High-Level-Test)
Ralf-Oliver Mevius
 Akzeptanztests (High-Level-Test)
Inf(21) WS10/11
Ralf-Oliver Mevius
6. Anforderungsmanagement
Inf(21) WS10/11
7. Projektmanagement
 Risikomanagement
 Projektplanung
Ralf-Oliver Mevius
 Projektverfolgung und -steuerung
 Management von
Lieferantenvereinbarungen
Inf(21) WS10/11
Ralf-Oliver Mevius
8. Qualitätsmanagement
 Capability Maturity Model
 Spice (Norm) (Software Process Improvement
and Capability Determination)
 Incident Management
 Problem Management
 Softwaremetrik (Messung von
Softwareeigenschaften)
 statische Analyse (Berechnung von
Schwachstellen)
 Softwareergonomie
Inf(21) WS10/11
9. Konfigurationsmanagement
 Versionsverwaltung
 Änderungsmanagement /
Veränderungsmanagement
Ralf-Oliver Mevius
 Release Management
 Application Management (ITIL)
Inf(21) WS10/11
10. Dokumentation
 Software-Dokumentationswerkzeug
 Systemdokumentation (Weiterentwicklung und
Fehlerbehebung)
 Betriebsdokumentation (Betreiber/Service)

 Bedienungsanleitung (Anwender)
Ralf-Oliver Mevius
 Geschäftsprozesse (Konzeptionierung der
Weiterentwicklung)
 Verfahrensdokumentation (Beschreibung rechtlich
relevanter Softwareprozesse)
Inf(21) WS10/11