960 likes | 1.59k Vues
Allgemeines- Teilgebiete der Softwaretechnik. Kernprozesse (1 ? 3 relevant f?r die Fallstudie)1. Planung2. Analyse3. Entwurf (!!!)Anm.: 1. und 2. k?nnen zusammen gefasst werden!. 2. Allgemeines- Teilgebiete der Softwaretechnik. weitere Kernprozesse4. Programmierung5. Validierung und V
E N D
1. Bachelor Informatik (21)Fallstudie Prozessmodellierung (21.3)Teil 2
2. Allgemeines- Teilgebiete der Softwaretechnik Kernprozesse (1 3 relevant fr die Fallstudie)
1. Planung
2. Analyse
3. Entwurf (!!!)
Anm.: 1. und 2. knnen zusammen gefasst werden! 2
3. Allgemeines- Teilgebiete der Softwaretechnik weitere Kernprozesse
4. Programmierung
5. Validierung und Verifikation 3
4. Allgemeines- Teilgebiete der Softwaretechnik Untersttzungsprozesse
6. Anforderungsmanagement
7. Projektmanagement
8. Qualittsmanagement
9. Konfigurationsmanagement
10. Dokumentation 4
5. 1. Planung Lastenheft (Anforderungsdefinition)
Pflichtenheft (mit technischen Anstzen verfeinertes Lastenheft)
Anm.: in der Ausarbeitung synonym Planung verwenden 5
6. 1. Planung - Lastenheft Ein Lastenheft (auch Anforderungs-spezifikation, Kundenspezifikation oder Requirements Specification) beschreibt die unmittelbaren Anforderungen durch den Besteller eines Produktes. 6
7. 1. Planung - Lastenheft Es enthlt jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehrenden formellen Abnahme die nachprfbaren Leistungen und Lieferungen. 7
8. 1. Planung - Lastenheft Es kann nicht die Erwartungen und Wnsche an ein geplantes Produkt enthalten. 8
9. 1. Planung - Lastenheft Diese abstrakten Merkmale wren, wenn nicht durch eine Prfung zu belegen, kaum durch denjenigen, der das Produkt herstellen soll, so einzuschtzen, dass sie zielfhrend bercksichtigt werden knnten. 9
10. 1. Planung - Lastenheft Gem DIN 69905 (Begriffe der Projektabwicklung) beschreibt das Lastenheft die
vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages. 10
11. 1. Planung - Lastenheft Das Lastenheft beschreibt in der Regel also, was und wofr etwas gemacht werden soll (Fachkonzept).
Die Adressaten des Lastenhefts sind der (externe oder firmeninterne) Auftraggeber sowie die Auftragnehmer. 11
12. 1. Planung - Lastenheft 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. 12
13. 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 ergnzt.
Es gibt dazu auch formalisierende Anstze, wie die Beschreibungssprache UML. 13
14. 1. Planung - Lastenheft Das Pflichtenheft beschreibt dann, was und womit etwas realisiert werden soll.
Dabei knnen gewhnlich 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) erfllt. 14
15. 1. Planung - Lastenheft Nach DIN 69905 enthlt das Pflichtenheft die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes. 15
16. 1. Planung - Lastenheft
Je nach Einsatzgebiet und Branche knnen 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.
16
17. 1. Planung - Lastenheft Die unscharfe Verwendung der Begriffe Lastenheft und Pflichtenheft sowie die fehlende Trennung technischer Information und operationeller Absichten ist hufig Ursache fr Missverstndnisse. 17
18. 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. 18
19. 1. Planung - Lastenheft Auf einen Dienstvertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Leistungen im Dienstvertrag nicht einer formellen Abnahme unterzogen werden. 19
20. 1. Planung - Pflichtenheft 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 fr sein Produkt.
20
21. 1. Planung - Pflichtenheft Es enthlt jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehrenden formellen Abnahme die prfbaren Leistungen und Lieferungen.
21
22. 1. Planung - Pflichtenheft Es kann, genauso wie das Lastenheft, nicht die Erwartungen und Wnsche an ein geplantes Produkt enthalten.
22
23. 1. Planung - Pflichtenheft Solche abstrakten Merkmale wren, wenn nicht durch eine Prfung oder Messung zu belegen, durch denjenigen, der das Produkt herstellt, auch eher nicht so einzuschtzen, dass sie zielfhrend whrend der Bearbeitung des Werkes und final bei der Abnahme bercksichtigt werden knnten.
23
24. 1. Planung - Pflichtenheft 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. 24
25. 1. Planung - Pflichtenheft Die dazu erforderliche Arbeit liegt allein in der Verantwortung des Herstellers oder Auftragnehmers, diese ist zunchst nicht der Einrede des Bestellers oder Auftraggebers unterworfen, es sei denn, beide arbeiten gemeinsam an dem zu erstellenden Werk. 25
26. 1. Planung - Pflichtenheft Laut DIN 69905 umfasst das Pflichtenheft die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts. 26
27. 1. Planung - Pflichtenheft Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes Pflichtenheft genannt) sind nun przisiert, vollstndig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknpft. 27
28. 1. Planung - Pflichtenheft Das Pflichtenheft wird vom Auftragnehmer (Entwicklungsabteilung/-firma) formuliert und auf dessen Wunsch vom Auftraggeber besttigt. Idealerweise sollten erst nach dieser Besttigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen. 28
29. 1. Planung - Pflichtenheft Der Auftragnehmer hat einen durch den Vertrag bestimmten Anspruch auf solche Besttigung (Mitwirkungspflicht nach 643 BGB). 29
30. 1. Planung - Pflichtenheft Im Gegensatz zum technischen Design (auch technische Spezifikation Wie wird es umgesetzt?) beschreibt das Pflichtenheft die geplante technische Lsung in unserem Beispiel die Software als Black Box (Was wird umgesetzt?). 30
31. 1. Planung - Pflichtenheft Entsprechend enthlt es in der Regel nicht die betriebliche Lsung der Aufgabenstellungen des Auftraggebers.
Schon gar nicht beschreibt es die (hier beim Softwarebeispiel) Implementierungsprobleme, sondern allenfalls die Schnittstellen, deren sorgfltige Beschreibung solche Probleme vermeiden soll. 31
32. 1. Planung - Pflichtenheft Es ist bewhrte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Flle explizit ein- oder auszuschlieen. 32
33. 1. Planung - Pflichtenheft Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausfhrung des Werkvertrages oder auch des Kaufvertrages beschliet.
Diese Abnahme wird hufig ber einen Akzeptanztest ausgefhrt, der feststellt, ob die Software die Forderungen des Pflichtenheftes in dem Verstndnis des Bestellers erfllt. 33
34. 2. Analyse Anforderungsanalyse
Auswertung
Mock-up
Prozessanalyse / Prozessmodell
Systemanalyse
Strukturierte Analyse (SA)
Objektorientierte Analyse (OOA)
34
35. 2. Analyse - Anforderungsanalyse Das ingenieurmige Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Software- und Systementwicklungsprozesses.
35
36. 2. Analyse - Anforderungsanalyse Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System (oft ein Anwendungsprogramm) zu ermitteln und zu verwalten.
36
37. 2. Analyse - Anforderungsanalyse IEEE - Institute of Electrical and Electronics Engineers
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 durchgefhrt.
http://www.ieee.org/index.html 37
38. 2. Analyse - Anforderungsanalyse SEI, Carnegie Mellon
Das Software Engineering Institute der Carnegie Mellon Universitt unterscheidet in ihrem Capability Maturity Model Integration das Management von Anforderungen, und die Entwicklung der Anforderungen.
38
39. 2. Analyse - Anforderungsanalyse Volere
In dem von den Robertsons entwickelten Vorgehensmodell existieren Anforderungsspezifikation, Stakeholder-Analyse, Bedarfsanalyse, Analyse der Priorisierung, und die Aufzeichnung der elementaren Anforderungen. 39
40. 2. Analyse - Anforderungsanalyse Sammeln, Analysieren 40
41. 2. Analyse - Anforderungsanalyse Beim Sammeln der Anforderungen (engl. elicitation) ist der bersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. 41
42. 2. Analyse - Anforderungsanalyse vollstndig - alle Anforderungen des Kunden mssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden ber das zu entwickelnde System geben. 42
43. 2. Analyse - Anforderungsanalyse eindeutig definiert / abgegrenzt - przise Definitionen helfen, Missverstndnisse zwischen Entwickler und Auftraggeber zu vermeiden. 43
44. 2. Analyse - Anforderungsanalyse verstndlich beschrieben - damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen knnen. 44
45. 2. Analyse - Anforderungsanalyse atomar - es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein.
Das Kriterium fr ein "Atom" sollte die Entscheidbarkeit einer Anforderung sein. 45
46. 2. Analyse - Anforderungsanalyse identifizierbar - jede Anforderung muss eindeutig identifizierbar sein (z. B. ber eine Kennung oder Nummer). 46
47. 2. Analyse - Anforderungsanalyse einheitlich dokumentiert - die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben. 47
48. 2. Analyse - Anforderungsanalyse notwendig - gesetzliche Vorschriften sind unabdingbar. 48
49. 2. Analyse - Anforderungsanalyse nachprfbar - die Anforderungen sollten mit Abnahmekriterien verknpft werden, damit bei der Abnahme geprft werden kann, ob die Anforderungen erfllt wurden (Ableitung von Testfllen aus den Abnahmekriterien). 49
50. 2. Analyse - Anforderungsanalyse rck- und vorwrtsverfolgbar - damit einerseits erkennbar ist, ob jede Anforderung vollstndig erfllt wurde und andererseits fr jede implementierte Funktionalitt erkennbar ist, aus welcher Anforderung sie resultiert, also nicht berflssiges entwickelt wird. 50
51. 2. Analyse - Anforderungsanalyse Konsistenz - Konsistenz beschreibt den Grad, in dem die definierten Anforderungen untereinander widerspruchsfrei sind. 51
52. 2. Analyse - Anforderungsanalyse Das Ergebnis der Anforderungsaufnahme ist das Lastenheft. 52
53. 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 erhht das Verstndnis von den Beziehungen zwischen den Anforderungen. 53
54. 2. Analyse - Anforderungsanalyse Kriterien sind hierbei:
abhngig - Anforderungen mssen daraufhin berprft werden, ob sie sich nur gemeinsam realisieren lassen oder ob eine Anforderung die Voraussetzung fr eine andere ist.
zusammengehrig - Anforderungen, die fachlich-logisch zusammengehren, sollten nicht allein realisiert werden.
rollenbezogen - jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit untersttzt werden soll. 54
55. 2. Analyse - Anforderungsanalyse Weitere Strukturierungsmglichkeiten sind
Funktionale und nichtfunktionale Anforderungen
Fachlich motivierte (fachliche und technische) und technisch motivierte (nur technische) Anforderungen. 55
56. 2. Analyse - Anforderungsanalyse Die so strukturierten Anforderungen mssen dann zwischen Kunde und Entwickler abgestimmt werden.
Diese Abstimmung kann gegebenenfalls zu einem iterativen Prozess werden, der zur Verfeinerung der Anforderungen fhrt. 56
57. 2. Analyse - Anforderungsanalyse Prfung und Bewertung 57
58. 2. Analyse - Anforderungsanalyse Nach der Strukturierung, zum Teil auch parallel dazu, erfolgt die Qualittssicherung der Anforderungen nach diesen Qualittsmerkmalen: 58
59. 2. Analyse - Anforderungsanalyse korrekt - die Anforderungen mssen insbesondere widerspruchsfrei sein. 59
60. 2. Analyse - Anforderungsanalyse machbar - die Anforderung muss realisierbar sein. 60
61. 2. Analyse - Anforderungsanalyse notwendig - was nicht vom Auftraggeber gefordert wird, ist keine Anforderung. 61
62. 2. Analyse - Anforderungsanalyse priorisiert - es muss erkennbar sein, welche Anforderungen am wichtigsten sind.
Ziel der Priorisierung ist es, hufig bentigte Funktionen vor den weniger hufig bentigten bereitzustellen.
Man erreicht es ber eine Quantifizierung der Funktionszweige. 62
63. 2. Analyse - Anforderungsanalyse nutzbar, ntzlich - auch bei teilweiser Realisierung soll bereits ein produktives System entstehen. 63
64. 2. Analyse - Anforderungsanalyse benutzerfreundlich - die Benutzerfreundlichkeit des Systems muss sichergestellt sein. 64
65. 2. Analyse - Anforderungsanalyse Das Ergebnis der Prfung stellt die Basis fr das Pflichtenheft dar. 65
66. 2. Analyse - Anforderungsanalyse Requirements Management RM
deutsch Anforderungsmanagement umfasst Manahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen. 66
67. 2. Analyse - Anforderungsanalyse Dazu gehrt auch das verwalten von nderungen der Requirements und deren Auswirkung auf abhngige Lieferergebnisse. 67
68. 2. Analyse - Auswertung 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. 68
69. 2. Analyse - Auswertung Programmiersprachen sind nach ihrer Auswertungsstrategie unterscheidbar: 69
70. 2. Analyse - Auswertung Bei strenger Auswertung oder strikter Auswertung (engl. eager bzw. strict evaluation) werden Ausdrcke sofort ausgewertet. Z. B. bei der Berechnung einer Funktion werden bei strikter Auswertung erst die Argumentausdrcke ausgewertet, bevor der Funktionsrumpf ausgewertet wird. 70
71. 2. Analyse - Auswertung Dem gegenber steht die Bedarfsauswertung oder verzgerte Auswertung (engl. lazy evaluation), bei der Ausdrcke erst ausgewertet werden, wenn deren Wert in einer Berechnung bentigt wird.
Dadurch lassen sich z. B. unendlich groe Datenstrukturen (z. B. die Liste aller natrlicher Zahlen, die Liste aller Primzahlen, usw.) definieren und bestimmte Algorithmen vereinfachen sich.
Diese Datenstrukturen bezeichnet man als Strme (engl. streams). 71
72. 2. Analyse - Auswertung Manche Berechnungen lassen sich mit strenger Auswertung, andere mit Bedarfsauswertung effizienter ausfhren. 72
73. 2. Analyse - Auswertung 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-Kalkl) 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. Schnfinkeln. 73
74. 2. Analyse - Auswertung Die Anwendung der Funktion (bzw. Funktionsdefinition) auf ihre Argumente bezeichnet man auch als Applikation. 74
75. 2. Analyse - Auswertung 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. 75
76. 2. Analyse Mock-up Ein Mock-up in der Softwareentwicklung bezeichnet einen rudimentren Wegwerfprototyp der Benutzeroberflche einer zu erstellenden Software.
Mock-ups werden insbesondere in frhen Entwicklungsphasen eingesetzt, um Anforderungen an die Benutzeroberflche in Zusammenarbeit mit Auftraggeber und Anwendern besser ermitteln zu knnen.
Es handelt sich meist um ein reines Grundgerst der Bedienelemente ohne weitere Funktionalitt. 76
77. 2. Analyse Mock-up Sogenannte Mock-Objekte werden beim Testen verwendet, was insbesondere beim Unit test genutzt wird.
Zu Beginn der Entwicklung werden sie als Platzhalter fr noch nicht vorhandene Objekte eingesetzt, wenn die noch nicht vorhandenen Komponenten fr das Testen eines anderen Moduls ntig sind (s. auch Test Driven Development). 77
78. 2. Analyse Mock-up In spteren Phasen kommen Mock-Objekte zur Anwendung, weil zum Beispiel die Initialisierung des (vorhandenen, funktionsfhigen) Objekts zu aufwendig oder in einer Testumgebung mangels Verbindung zu produktiven Backend-Systemen gar nicht mglich ist. 78
79. 2. Analyse Mock-up Ein weiterer hufiger Grund fr den Einsatz eines Mock-Objektes ist ein nichtvorhersehbares Verhalten der eigentlichen Klasse, zum Beispiel die Rckgabe 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. 79
80. 2. Analyse - Prozessanalyse Als Prozessanalyse bezeichnet man die systematische Untersuchung von Geschftsprozessen (lat. procedere = voranschreiten) und die Zerlegung in seine Einzelteile, um Schwachstellen und Verbesserungspotentiale zu erkennen. (vgl. Oberbegriff Analyse)
80
81. 2. Analyse - Prozessanalyse Hierdurch kann man Vereinheitlichungen in Standardprozessen erlangen und eine gruppenbergreifende Synchronisation erreichen.
81
82. 2. Analyse - Prozessanalyse Besonders im Qualittsmanagement ist es unabdingbar, bei auftretenden Fehlern mglichst schnell deren Ursache(n) zu entdecken und Abstellmanahmen einzuleiten.
Dieser kontinuierliche Verbesserungsprozess (KVP) trgt dazu bei, auch bei verwandten Prozessen schnell und effizient einzugreifen, da Teilprozesse hnlich oder gleich sein knnen.
82
83. 2. Analyse - Prozessanalyse 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 knnen Probleme meist schon im Vorfeld gelst werden.
83
84. 2. Analyse - Prozessanalyse Die genaue Beschreibung von Prozessen ist hierbei genauso wichtig wie ihre stndige Pflege und Kontrolle.
Durch das Versehen von Prozessen mit Informationen wird darber hinaus auch das Auffinden von Schlsselindikatoren erleichtert, die das Bewerten eines Prozesses zulassen.
84
85. 2. Analyse - Prozessanalyse Durchfhrung der Prozessanalyse. Die Prozessanalyse wird in zwei Schritten durchgefhrt:
1. Istaufnahme der bestehenden Organisation
Hierfr werden Organisations- und Arbeitsunterlagen ausgewertet und gegebenenfalls
Mitarbeiterinterviews durchgefhrt.
85
86. 2. Analyse - Prozessanalyse 2. Istanalyse der Prozesse
Folgende Methoden werden zum Beispiel eingesetzt:
Benchmarking
Schwachstellenanalyse
Workflowanalyse
Checklistentechnik
Referenzanalyse
Vorgangskettenanalyse
86
87. 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 zunchst als Black Box und verfeinert dieses im weiteren Verlauf. 87
88. 2. Analyse Systemanalyse Dabei hat der Bearbeiter eine Auswahl bezglich 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 zuknftige Entwicklungen und Verhaltensweisen des Systems in bestimmten Szenarien gemacht werden sollen. 88
89. 2. Analyse Systemanalyse Der Vorgang ist auf nahezu jedes System anwendbar, einschlielich
Physik,
Biologie,
Demographie,
Wirtschaft,
Geographie,
Technik und Informatik. 89
90. 2. Analyse Systemanalyse Was ist Systemanalyse?
Der ganzheitliche Ansatz Systemanalyse ist ein iterativer, heuristischer und rckgekoppelter Prozess der durch die Dimensionen:
Organisation,
Technologie und Motivation
gekennzeichnet werden kann. 90
91. 2. Analyse Systemanalyse Arbeitsschritte einer Systemanalyse
Festlegen der Systemgrenzen zur Unterscheidung von System und Umwelt.
Feststellen derjenigen Systemelemente, die fr die Fragestellung als relevant betrachtet werden. 91
92. 2. Analyse Systemanalyse Feststellen derjenigen Beziehungen zwischen den Systemelementen, die fr 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. 92
93. 2. Analyse Systemanalyse Darstellung
Darstellung der Analyseergebnisse:
qualitativ: Concept-Map, Flussdiagramm, Wirkungsdiagramme
halbquantitativ: Pfeildiagramm (je-desto-Beziehungen)
quantitativ: x-y-, x-t-Diagramme u. a., mathematische Gleichungssysteme 93
94. 2. Analyse Systemanalyse Fr die Systemanalyse werden formale Methoden und graphische Methoden eingesetzt.
Edwards behilft sich in seinem Werk mit den folgenden Elementen, um damit diverse Muster-Systeme darzustellen: 94
95. 2. Analyse Systemanalyse DFD (Data Flow Diagramm)
Datenflussdiagramm, stellt die Verarbeitung und Speicherung der Datenstrme dar.
STD (State Transition Diagram)
Zustandsbergangsdiagramm, zeigt zeitliches Verhalten. 95
96. 2. Analyse Systemanalyse ERD (Entity Relationship Diagram)
Gegenstands-Beziehungs-Diagramm, stellt Datenverknpfungen zueinander dar.
ESTD (Entity State Diagram)
Gegenstands-Zustands-Diagramm, als Mischform aus STD und ERD. Zeigt Statusnderungen in Abhngigkeit von zeitlichen Ereignissen. 96
97. 2. Analyse Systemanalyse Weiterhin benennt er noch die folgenden theoretisch mglichen Kombinationen, die aber praktisch nur sehr begrenzt zweckdienlich sind:
Zuordnung zwischen Datenstromdarstellung und Datenspeichern (zur Verifikation).
Zeitliche Vernderung der Datenverarbeitung durch Steuersignale (zur Funktionskontrolle).
97
98. 2. Analyse Systemanalyse
Die Herleitung von Zustnden (States) durch Ereignisse (Events) und umgekehrt ist mglich.
Eine stndige Begrenzung auf eine fr die jeweilige Detailierungsebene sinnvolle Elementmenge ist ntig um zu einem tauglichen, sprich durchschaubaren und damit brauchbaren Ergebnis zu kommen.
Die Darstellung unterscheidet zwischen Steuerstrmen, Datenstrmen, Augenblicksereignissen und physikalischen Strmen von Materie oder Energie. 98
99. 2. Analyse Strukturierte Analyse (SA) Die Strukturierte Analyse (SA) ist eine hauptschlich von Tom DeMarco entwickelte Methode zur Erstellung einer formalen Systembeschreibung im Rahmen der Softwareentwicklung.
Sie wird whrend der Analysephase eines Software-Projekts eingesetzt.
Strukturiertes Design verfeinert die Ergebnisse der SA soweit, dass sie dann umgesetzt werden knnen. Sie ist eine Methode der Systemanalyse. 99
100. 2. Analyse Strukturierte Analyse (SA) Das Ergebnis der Strukturierten Analyse ist ein hierarchisch gegliedertes technisches Anforderungsdokument fr das Systemverhalten. 100
101. 2. Analyse Strukturierte Analyse (SA) 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 durchfhrt.
In ihrer Grundform ist die SA eine statische Analyse, die jedoch spter um Methoden fr dynamische Analysen erweitert wurde. 101
102. 2. Analyse Strukturierte Analyse (SA) 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. 102
103. 2. Analyse Strukturierte Analyse (SA) 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 abluft.
103
104. 2. Analyse Strukturierte Analyse (SA) 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 spter verwendeten Programmiersprache orientiert.
Weitere Mglichkeiten der Beschreibung sind Entscheidungstabellen und -bume.
104
105. 2. Analyse Strukturierte Analyse (SA) Datenwrterbuch (engl. Data Dictionary, kurz DD):
Eine Sammlung aller Datendefinitionen, die in der Analyse verwendet werden.
105
106. 2. Analyse Strukturierte Analyse (SA) Die ersten beiden Diagramme verwenden folgende grafischen Elemente:
Datenfluss, dargestellt als ein Pfeil
Daten, Beschriftung am Pfeil 106
107. 2. Analyse Strukturierte Analyse (SA) 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 Datenempfnger/sender (nur auf dem Kontextdiagramm), Viereck mit eingeschlossenem Namen
107
108. 2. Analyse Strukturierte Analyse (SA) Strukturierte Real-Time-Analyse (RT)
Die Strukturierte Real-Time-Analyse erweitert die normale strukturierte Analyse um eine Echtzeitkomponente. 108
109. 2. Analyse Strukturierte Analyse (SA) Erreicht wird dies durch die Festlegung des Verhaltens der Prozessschicht unter allen mglichen externen und internen Bedingungen und Betriebsarten.
Entworfen wurde das System von Imtiaz A. Pirbhai und Derek J. Hatley. 109
110. 2. Analyse Strukturierte Analyse (SA) Dynamische Analyse
Neben den Definitionen der Statischen Analyse werden zustzlich folgende Elemente definiert:
Entscheidungstabelle (engl. Decision Table, kurz DT): Aus mehreren Eingangswerten wird in tabellarischer Form definiert wie der Ausgangswert gesetzt wird. 110
111. 2. Analyse Strukturierte Analyse (SA) Zustandsbergangsdiagramm (engl. State Transition Diagram, kurz STD):
Zustnde werden auf diesem Diagramm als Vierecke und bergnge als Pfeile dargestellt.
Das STD hat Eingangs- und Ausgangswerte, die in Abhngigkeit von den bergngen und Zustnden gesetzt werden. 111
112. 2. Analyse Strukturierte Analyse (SA) Prozessaktivierungstabelle (engl. Process Activation Table, kurz PAT):
Die Tabelle beschreibt die Reihenfolge der Aktivierung der in der Tabelle aufgezhlten 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. 112
113. 2. Analyse Strukturierte Analyse (SA) Kontrollflsse (engl. Control Flow):
Dargestellt als gestrichelter Pfeil werden ber Kontrollflsse 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.
113
114. 2. Analyse Strukturierte Analyse (SA) Verwendung in der Praxis
Eins der grten Softwareprojekte, die mit Hilfe der Strukturierten Analyse in Deutschland realisiert wurden, ist die Software fr den Zentralrechner des Kampfflugzeugs Tornado.
114
115. 2. Analyse Strukturierte Analyse (SA) Ansonsten ist die Strukturierte Analyse vielerorts durch die Unified Modeling Language abgelst, wird aber noch in vielen Projekten eingesetzt.
Softwaretools
Innovator von MID
case/4/0 von microTOOL
115
116. 2. Analyse OO Analyse und Design Objektorientierte Analyse und Design (OOAD) ist eine Phase der objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der Domnenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs (Objektorientiertes Design) aufgliedert. 116
117. 2. Analyse OO Analyse und Design In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben, die das zu entwickelnde Softwaresystem erfllen soll.
Stark vereinfacht ausgedrckt sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und berprft sie.
Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software Requirements Specification. 117
118. 2. Analyse OO Analyse und Design 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 lsst Unwichtiges weg. Ein Bezug zur Informationstechnik ist in dieser Phase ausdrcklich unerwnscht. 118
119. 2. Analyse OO Analyse und Design Das OOA-Modell kann ein statisches und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der Benutzerschnittstelle enthalten. 119
120. 2. Analyse OO Analyse und Design Beim objektorientierten Design wird das in der Analyse erstellte Domnenmodell weiterentwickelt und darauf aufbauend ein Systementwurf erstellt.
Das Design bercksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse auch technische Gegebenheiten.
In einem Wasserfall-Vorgehensmodell folgt als nchste Phase die objektorientierte Programmierung (OOP). 120
121. 2. Analyse OO Analyse und Design Vorgehensmodelle
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 Verstndnis fr den eigenen Entwurf zu vertiefen und die Dokumentation zu standardisieren. 121
122. 2. Analyse OO Analyse und Design 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. 122
123. 2. Analyse OO Analyse und Design 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 bewhrt und durchgesetzt. Allerdings ist auch UML eher ein Werkzeugkasten als ein klares Vorgehensmodell. 123
124. 3. Entwurf Softwarearchitektur
Strukturiertes Design (SD)
Objektorientiertes Design (OOD)
Unified Modeling Language (UML)
Fundamental Modeling Concepts (FMC) 124
125. 3. Entwurf Softwaerarchitektur 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).
125
126. 3. Entwurf Softwaerarchitektur Die beschriebenen Komponenten bilden eine Zerlegung des Gesamtsystems, d. h., jedes Softwareelement ist einer Architekturkomponente eindeutig zugeordnet.
Die Softwarearchitektur ist zu unterscheiden vom Softwareentwurf.
126
127. 3. Entwurf Softwaerarchitektur Whrend sich Entwurfsentscheidungen auf lokale Aspekte innerhalb des architektonischen Rahmens der Software beziehen, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems. 127
128. 3. Entwurf Softwaerarchitektur Im Rahmen der Softwareentwicklung reprsentiert die Softwarearchitektur die frheste Softwaredesign-Entscheidung (Architekturentwurf).
Sie wird wesentlich durch nicht-funktionale Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt.
128
129. 3. Entwurf Softwaerarchitektur Eine einmal eingerichtete Softwarearchitektur ist spter nur mit hohem Aufwand abnderbar.
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. 129
130. 3. Entwurf Softwaerarchitektur
Beispielsweise:
Unified Modeling Language (UML)
Fundamental Modeling Concepts (FMC)
130
131. 3. Entwurf Softwaerarchitektur Mit der Bewertung von Softwarearchitekturen befasst sich die Softwarearchitekturbewertung.
Beispiel
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 hufig auch Diagramme (z.B. in der Unified Modeling Language) zum Einsatz kommen. 131
132. 3. Entwurf Strukturiertes Design Strukturiertes Design (SD) ist ein Entwurfsmuster in der Softwaretechnik nach Edward Yourdon und Larry Constantine, welches modulares Design untersttzt, um neben der reinen Funktionshierarchie auch die Wechselwirkungen von bergeordneten Modulen zu beschreiben. SD wird mit der Strukturierten Analyse (SA) in der Softwaretechnik verwendet. 132
133. 3. Entwurf Strukturiertes Design Das Strukturierte Design schlgt eine Brcke 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. 133
134. 3. Entwurf Strukturiertes Design 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. 134
135. 3. Entwurf Strukturiertes Design Diese wiederum stellt eine der ersten Abstraktionsmechanismen dar und gruppiert mehrere zusammengehrende Programmbefehle zu Einheiten (Funktionen).
Ein Beispiel wre die Berechnung der Quadratwurzel sqrt(x). 135
136. 3. Entwurf Strukturiertes Design Der Benutzer muss keine Details ber die Implementierung wissen, sondern wendet die Funktion nur an.
Dafr bentigt er eine entsprechende Schnittstellenbeschreibung, die ebenso zum Strukturierten Entwurf gehrt wie das Erstellen der Modulhierarchie. 136
137. 3. Entwurf Strukturiertes Design Ein Funktionales Modul besitzt kein internes Gedchtnis, das heit 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).
Sptere darauf aufbauende Methoden, wie das Modulare Design (MD), fhren abstrakte Datentypen und Datenobjekte ein. 137
138. 3. Entwurf Strukturiertes Design Bei Banken, Versicherungen und im Embedded-Bereich finden noch viele Systementwicklungen mit strukturierten Methoden statt.
Insbesondere im Bereich des m-Business (Mobile-Business) werden oft Rechnersysteme verwendet, die ber limitierte Ressourcen verfgen, fr die eine objektorientierte Realisierung mit ihrem Overhead zu teuer ist. 138
139. 3. Entwurf Strukturiertes Design Weiterhin sind im Rahmen der Integration von bestehenden Anwendungen im Rahmen von EAI oft Teilsysteme zu realisieren, die nicht mit objektorientierten Sprachen umgesetzt werden knnen.
Daher wrden objektorientierte Analyse und Design falsche Implementierungsvorbereitungen darstellen. 139
140. 3. Entwurf Strukturiertes Design 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. 140
141. 3. Entwurf Strukturiertes Design Beispiel
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. 141
142. 3. Entwurf OO Design Objektorientierte Analyse und Design (OOAD) ist eine Phase der objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der Domnenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs (Objektorientiertes Design) aufgliedert. 142
143. 3. Entwurf OO Design In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben, die das zu entwickelnde Softwaresystem erfllen soll.
Stark vereinfacht ausgedrckt sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und berprft sie.
Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software Requirements Specification. 143
144. 3. Entwurf OO Design 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 lsst Unwichtiges weg. 144
145. 3. Entwurf OO Design Ein Bezug zur Informationstechnik ist in dieser Phase ausdrcklich unerwnscht. Das OOA-Modell kann ein statisches und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der Benutzerschnittstelle enthalten. 145
146. 3. Entwurf OO Design Beim objektorientierten Design wird das in der Analyse erstellte Domnenmodell weiterentwickelt und darauf aufbauend ein Systementwurf erstellt.
Das Design bercksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse auch technische Gegebenheiten.
In einem Wasserfall-Vorgehensmodell folgt als nchste Phase die objektorientierte Programmierung (OOP). 146
147. 3. Entwurf - UML Die Unified Modeling Language (UML, engl. Vereinheitlichte Modellierungs-Sprache) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache fr die Modellierung von Software und anderen Systemen.
Im Sinne einer Sprache definiert die UML dabei Bezeichner fr die meisten Begriffe, die fr die Modellierung wichtig sind, und legt mgliche Beziehungen zwischen diesen Begriffen fest.
147
148. 3. Entwurf - UML Die UML definiert weiter grafische Notationen fr diese Begriffe und fr Modelle von statischen Strukturen und von dynamischen Ablufen, die man mit diesen Begriffen formulieren kann.
Die UML ist heute eine der dominierenden Sprachen fr die Modellierung von betrieblichen Anwendungssystemen (Softwaresystemen).
Der erste Kontakt zur UML besteht hufig darin, dass Diagramme der UML im Rahmen von Softwareprojekten zu erstellen, zu verstehen oder zu beurteilen sind:
148
149. 3. Entwurf - UML Projektauftraggeber und Fachvertreter prfen und besttigen zum Beispiel Anforderungen an ein System, die Wirtschaftsanalytiker in Anwendungsfalldiagrammen der UML festgehalten haben.
Softwareentwickler realisieren Arbeitsablufe, die Wirtschaftsanalytiker in Zusammenarbeit mit Fachvertretern in Aktivittsdiagrammen beschrieben haben.
Systemingenieure installieren und betreiben Softwaresysteme basierend auf einem Installationsplan, der als Verteilungsdiagramm vorliegt.
149
150. 3. Entwurf - UML 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. 150
151. 3. Entwurf - UML Die UML schlgt weiter ein Format vor, in dem Modelle und Diagramme zwischen Werkzeugen ausgetauscht werden knnen.
Ein Vorgehensmodell, welches die UML anwendet, kann wegen der strengen Formalisierung kein agiler Prozess sein.
151
152. 3. Entwurf Fundamental Modeling Concepts Fundamental Modeling Concepts (FMC) ist eine semi-formale Methodik zur Kommunikation ber komplexe Softwaresysteme.
152
153. 3. Entwurf Fundamental Modeling Concepts Seit Ende der 1970er Jahre wurden ihre Grundlagen von Siegfried Wendt und seinen Mitarbeitern und Schlern an der Universitt Kaiserslautern entwickelt.
153
154. 3. Entwurf Fundamental Modeling Concepts Am 1999 unter Leitung von Siegfried Wendt gegrndeten Hasso-Plattner-Institut an der Universitt Potsdam wurden diese Konzepte zunchst 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.
154
155. 4. Programmierung Normierte Programmierung
Strukturierte Programmierung
Objektorientierte Programmierung (OOP)
Funktionale Programmierung
155
156. 5. Validierung und Verifikation Modultests (Low-Level-Test)
Integrationstests (Low-Level-Test)
Systemtests (High-Level-Test)
Akzeptanztests (High-Level-Test) 156
157. 6. Anforderungsmanagement 157
158. 7. Projektmanagement Risikomanagement
Projektplanung
Projektverfolgung und -steuerung
Management von Lieferantenvereinbarungen
158
159. 8. Qualittsmanagement 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 159
160. 9. Konfigurationsmanagement Versionsverwaltung
nderungsmanagement / Vernderungsmanagement
Release Management
Application Management (ITIL)
160
161. 10. Dokumentation Software-Dokumentationswerkzeug
Systemdokumentation (Weiterentwicklung und Fehlerbehebung)
Betriebsdokumentation (Betreiber/Service)
Bedienungsanleitung (Anwender)
Geschftsprozesse (Konzeptionierung der Weiterentwicklung)
Verfahrensdokumentation (Beschreibung rechtlich relevanter Softwareprozesse) 161