Softwaretechnik Vorgehensweisen

Transkript

1 Softwaretechnik Vorgehensweisen Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin The Emperor: Everything is proceeding as I have foreseen. (Return of the Jedi, 1983) Karsten Weicker, Nicole Weicker 1/ 44

2 Vorgehensweisen der Softwareentwicklung Defintion: Softwaretechnik Die Anwendung eines systematischen, disziplinierten, quantitativ bewertbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software; d.h. die Anwendung der Ingenieurswissenschaft auf Software. IEEE Std (1990) Karsten Weicker, Nicole Weicker 2/ 44

3 Vorgehensweisen der Softwareentwicklung Defintion: Softwaretechnik Die Anwendung eines systematischen, disziplinierten, quantitativ bewertbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software; d.h. die Anwendung der Ingenieurswissenschaft auf Software. IEEE Std (1990) Alternative Definition: Softwaretechnik ist Multi-Personen-Konstruktion von Multi-Versionen-Software. (nach David L. Parnas, 1974) Karsten Weicker, Nicole Weicker 2/ 44

4 Vorgehensweisen der Softwareentwicklung Tätigkeiten der Softwareentwicklung (informell) grobe Beschreibung der Aufgabe/Idee, was zu entwickeln ist Klärung, dass alle das Gleiche verstehen Identifikation von getrennten Aufgaben (Aufteilung der Aufgaben auf die Teammitglieder) Entwicklung der Software enge Kommunikation Integration der Teile Überprüfung, ob die Software das tut, was sie tun soll Karsten Weicker, Nicole Weicker 3/ 44

5 Vorgehensweisen der Softwareentwicklung Evolutionäre Entwicklung Gleichzeitig stattfindende Aktivitäten Spezifikation Anfangsversion Grobe Beschreibung Entwicklung Zwischenversionen Validierung Endversion Karsten Weicker, Nicole Weicker 4/ 44

6 Vorgehensweisen der Softwareentwicklung Wasserfall-Modell Anforderungsanalyse Anforderungsspezifikation Systementwurf Implementation Test Betrieb Karsten Weicker, Nicole Weicker 5/ 44

7 Vorgehensweisen der Softwareentwicklung Definition Definition (Vorgehensmodell) Ein Vorgehensmodell (oder auch Softwareprozess) ist eine Menge von Aktivitäten, die benötigt werden um Softwaresysteme zu entwickeln, sowie deren Anordnung bzw. Abfolge. Karsten Weicker, Nicole Weicker 6/ 44

8 Vorgehensweisen der Softwareentwicklung Definition Definition (Vorgehensmodell) Ein Vorgehensmodell (oder auch Softwareprozess) ist eine Menge von Aktivitäten, die benötigt werden um Softwaresysteme zu entwickeln, sowie deren Anordnung bzw. Abfolge. Beispiele: evolutionäre Entwicklung Wasserfallmodell weitere später Karsten Weicker, Nicole Weicker 6/ 44

9 Aufbau der Vorlesung als Spirale Aufbau der Vorlesung als Spirale Prozessmodelle Kostenschätzung Risikomanagement Qualitätsmanagement Vermeid. v. Missverständnis Nichtfunkt. Anforderungen Strukturen und Muster Testen funkt. Anforderungen UML Aufgaben des Projektmanagements Funkt. Anforderungen am Beispiel Vorgehensweisen Code-Verstehen D C B A A = Anforderungsanalyse B = Anforderungsspezifikation C = Systementwurf D = Implementation Karsten Weicker, Nicole Weicker 7/ 44

10 Identifikation der grundlegenden Abläufe A = Anforderungsanalyse Definition (Anforderung) Eine Anforderung ist eine vom Anwender benötigte Fähigkeit des Systems, um ein Ziel zu erreichen, bzw. eine Fähigkeit, die das System besitzen muss, damit es einen Vertrag, einen Standard oder ein anderes formelles Dokument erfüllt. Karsten Weicker, Nicole Weicker 8/ 44

11 Identifikation der grundlegenden Abläufe A = Anforderungsanalyse: Gegenstand der Anforderung funktionale Anforderung überprüfbare Funktionalität des Systems Produktfunktionen nichtfunktionale Anforderung andere Eigenschaften, u.a. Benutzbarkeit Effizienz Zuverlässigkeit Portierbarkeit Kompatibilität Datenschutz Sicherheit Karsten Weicker, Nicole Weicker 9/ 44

12 Identifikation der grundlegenden Abläufe Zwei Minuten Aufgabe Welche der folgenden Aussagen ist eine nicht-funktionale Anforderung? Neue Kunden können angelegt werden. Das System antwortet auf jede Anfrage in maximal 2 ms. Auf Kundendaten kann nur intern zugegriffen werden. Kundendaten können verändert werden. Die Bedienung des Systems ist leicht erlernbar. Die Kreditwürdigkeit eines Kunden kann berechnet werden. Karsten Weicker, Nicole Weicker 10/ 44

13 Identifikation der grundlegenden Abläufe Zwei Minuten Aufgabe Welche der folgenden Aussagen ist eine nicht-funktionale Anforderung? Neue Kunden können angelegt werden. Das System antwortet auf jede Anfrage in maximal 2 ms. Auf Kundendaten kann nur intern zugegriffen werden. Kundendaten können verändert werden. Die Bedienung des Systems ist leicht erlernbar. Die Kreditwürdigkeit eines Kunden kann berechnet werden. Karsten Weicker, Nicole Weicker 10/ 44

14 Identifikation der grundlegenden Abläufe A = Anforderungsanalyse: Lastenheft zur Dokumentation Lastenheft beschreibt Wünsche des Auftraggebers auf Ebene der Benutzungsanforderungen Was und Warum Form: natürliche Sprache wichtig: Verständlichkeit für Auftraggeber ist Vordokument zum Pflichtenheft Ist- und Soll-Analyse Karsten Weicker, Nicole Weicker 11/ 44

15 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Warum nach Analyse noch Spezifikation Beschreibung der Anforderungen in natürlicher Sprache vieldeutig missverständlich Eindeutigkeit in der Formulierung Analyse: Problemfeld mit Abläufen Analyse: keine Lösung durch System! Übertragung der Anforderungen in informatische Zusammenhänge Was muss das System können, damit es die Anforderungen erfüllen kann? Karsten Weicker, Nicole Weicker 12/ 44

16 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Pflichtenheft zur Dokumentation Pflichtenheft = Realisierungsvorhaben des Auftragnehmers auf Ebene der Systemanforderungen Wie und Womit keine programmiertechnischen/ architektonischen Details Übertragung der Benutzerwünsche Planung/ Machbarkeitsanalyse Form: strukturierte natürliche Sprache, grafische Notation oder mathematische Spezifikation wichtig: eindeutige Beschreibung für Entwickler wichtig: Vertragsgrundlage zwischen Entwickler und Kunden! verständlich bleiben Karsten Weicker, Nicole Weicker 13/ 44

17 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Validierung von Anforderungen Für jede Anforderung ist zu überprüfnen korrekt machbar eindeutig nachprüfbar Für den Katalog aller Anforderungen vollständig konsistent Karsten Weicker, Nicole Weicker 14/ 44

18 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Beispiel: Gliederung des Pflichtenhefts (IEEE) 1. Einleitung: a) Ziel, b) Anwendungsbereich des Produkts, c) Definitionen, d) Referenzen, e) Überblick über das Dokument 2. Allgemeine Beschreibung: a) Produktperspektive, b) Produktfunktion, c) Benutzercharakteristika, d) Beschränkungen, e) Voraussetzungen und Abhängigkeiten 3. Spezifische Anforderungen: funktionale/ nichtfunktionale Anforderungen, externe Schnittstellen 4. Anhänge 5. Index Karsten Weicker, Nicole Weicker 15/ 44

19 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Beispiel: Gliederung des Pflichtenhefts (Sommerville) 1. Vorwort: Versionsgeschichte 2. Einleitung: Notwendigkeit des Systems, Funktion, Zusammenarbeit mit anderen Systemen 3. Definition der Benutzeranforderungen 4. Systemarchitektur 5. Spezifikation der Systemanforderungen 6. Systemmodelle 7. Systementwicklung: erwartete Veränderungen 8. Anhänge, Index Karsten Weicker, Nicole Weicker 16/ 44

20 Identifikation der grundlegenden Abläufe B = Anforderungsspezifikation: Beispiel: Gliederung des Pflichtenhefts (Balzert) 1. Zielbestimmung: a) Muss b) Wunsch c) Abgrenzung 2. Produkteinsatz 3. Produktübersicht 4. Produktfunktionen 5. Produktdaten 6. Produktleistungen (Zeit und Genauigkeit) 7. Qualitätsanforderungen 8. Benutzungsoberfläche 9. Nichtfunktionale Anforderungen (Gesetze, Normen etc.) 10. Technische Produktumgebung 11. Anforderung an Entwicklungsumgebung 12. Glossar Karsten Weicker, Nicole Weicker 17/ 44

21 Identifikation der grundlegenden Abläufe Zwei Minuten Aufgabe Welche der folgenden Aussagen ist korrekt? Lastenheft ist gleich Pflichtenheft. Das Pflichtenheft wird nur intern verwendet. Beide Dokumente dienen der Kommunikation mit dem Kunden. Das Pflichtenheft ist die Vorbereitung für das Lastenheft. Das Lastenheft ist überwiegend in natürlicher Sprache verfasst. Das Pflichtenheft kann bereits Systemmodelle enthalten. Karsten Weicker, Nicole Weicker 18/ 44

22 Identifikation der grundlegenden Abläufe Zwei Minuten Aufgabe Welche der folgenden Aussagen ist korrekt? Lastenheft ist gleich Pflichtenheft. Das Pflichtenheft wird nur intern verwendet. Beide Dokumente dienen der Kommunikation mit dem Kunden. Das Pflichtenheft ist die Vorbereitung für das Lastenheft. Das Lastenheft ist überwiegend in natürlicher Sprache verfasst. Das Pflichtenheft kann bereits Systemmodelle enthalten. Karsten Weicker, Nicole Weicker 18/ 44

23 Identifikation der grundlegenden Abläufe C = Systementwurf Definition (Software-Architektur) Die Software-Architektur eines Systems beschreibt dessen Software-Struktur(en), dessen Software-Bausteine sowie deren sichtbaren Eigenschaften und Beziehungen zueinander (nach Bass et. al., 2003). Der Erstellungsprozess wird (Grob-)Entwurf genannt. Karsten Weicker, Nicole Weicker 19/ 44

24 Identifikation der grundlegenden Abläufe C = Systementwurf: Vorteile Vorteile eines expliziten Entwurfs (gegenüber einer evolutionären Entwicklung) Kommunikation zwischen den Projektbeteiligten: vereinfachte Darstellung des Systems als Diskussionsgrundlage Systemanalysen: früh Analysen bzgl. systemkritischer Anforderungen möglich, z.b. Performanz, Zuverlässigkeit, Wartbarkeit Wiederverwendung in großem Umfang: Übertragung der Architektur auf ähnliche Systeme Karsten Weicker, Nicole Weicker 20/ 44

25 Identifikation der grundlegenden Abläufe C = Systementwurf: Mögliche Inhalte statisches Strukturmodell: Darstellung der Komponenten des Systems dynamisches Strukturmodell: Welche Prozesse entstehen zur Laufzeit? Schnittstellenmodell: Details der Dienste der einzelnen Komponenten/Module Beziehungsmodelle: Datenflüsse, Kontrollflüsse etc. Karsten Weicker, Nicole Weicker 21/ 44

26 Identifikation der grundlegenden Abläufe C = Systementwurf: Einflüsse Leistungsfähigkeit: kritische Abläufe in möglichst wenigen Komponenten mit wenig Kommunikation Zugriffsschutz: evtl. Schichtenarchitektur, kritische Inhalte in untersten Schicht Sicherheit (d.h. Vertraulichkeit, Authentizität, Integrität): sicherheitskritische Aktivitäten in Subsystem verringert Kosten der Sicherheitsvalidierung Verfügbarkeit: redundante Komponenten zur Ausfallsicherheit bei Updates/Wartung Wartbarkeit: kleine austauschbare Komponenten, Trennung von Erzeugen und Benutzen von Daten, Vermeidung gemeinsamer Datenstrukturen Karsten Weicker, Nicole Weicker 22/ 44

27 Identifikation der grundlegenden Abläufe C = Systementwurf: Beschreibungsmittel schriftlich, textuell Visualisierungen: wichtigeste Aspekte Wegweiser durch die Beschreibung In den Visualisierungen: Rollen der Bausteine Beziehungen zwischen den Bausteinen Kommunikation Karsten Weicker, Nicole Weicker 23/ 44

28 Identifikation der grundlegenden Abläufe D = Implementation Aspekte der Implementation Dokumentation Programmierrichtlinien Testen Unit-Test Komponententest Integrationstest Systemtest Versionskontrolle Karsten Weicker, Nicole Weicker 24/ 44

29 Identifikation der grundlegenden Abläufe Aufbau der Vorlesung als Spirale Prozessmodelle Kostenschätzung Risikomanagement Qualitätsmanagement Vermeid. v. Missverständnis Nichtfunkt. Anforderungen Strukturen und Muster Testen funkt. Anforderungen UML Aufgaben des Projektmanagements Funkt. Anforderungen am Beispiel Vorgehensweisen Code-Verstehen D C B A A = Anforderungsanalyse B = Anforderungsspezifikation C = Systementwurf D = Implementation Karsten Weicker, Nicole Weicker 25/ 44

30 Vorgehensweise Anforderungsanalyse A: Ablauf der Anforderungsanalyse Start Konfliktlösung Anforderungsüberprüfung Lastenheft Verstehen des Anwendungsbereichs Setzen von Prioritäten Anforderungssammlung Klassifizierung Karsten Weicker, Nicole Weicker 26/ 44

31 Vorgehensweise Anforderungsanalyse A: Anforderungsanalyse: Schwierigkeit Beteiligte wissen nicht, was sie von einem System erwarten: unbewusste Anforderungen: Selbstverständlichkeit ungeahnte Anforderungen: Leistungsfähigkeit eines derartigen Systems nicht abschätzbar unterschiedliches Fachwissen/ Fachsprache Konflikte zwischen Anforderungen oder unterschiedliche Formulierungen derselben Anforderungen Veränderungen politischer, wirtschaftlicher oder geschäftlicher Randbedingungen Karsten Weicker, Nicole Weicker 27/ 44

32 Vorgehensweise Anforderungsanalyse A: Anforderungsanalyse Sie öffnen also morgens das Schloss am Haupteingang? Ja, habe ich Ihnen doch gesagt. Jeden Morgen? Natürlich. Auch am Wochenende? Nein, am Wochenende bleibt der Eingang zu. Und während der Betriebsferien? Da bleibt er natürlich auch zu. Und wenn Sie krank sind oder Urlaub haben? Dann macht das Herr Schmidt. Und wenn auch Herr Schmidt ausfällt? Dann klopft irgendwann ein Kunde ans Fenster, weil er nicht reinkommt. Was bedeutet eigentlich morgens?... (Ludewig/Lichter) Karsten Weicker, Nicole Weicker 28/ 44

33 Vorgehensweise Anforderungsanalyse Zwei Minuten Aufgabe Welche Kompetenzen benötigt Ihrer Meinung nach ein Informatiker zur Erhebung einer Anforderungsanalyse? Karsten Weicker, Nicole Weicker 29/ 44

34 Vorgehensweise: Anforderungsspezifikation B: Ablauf der Anforderungsspezifikation Datenanalyse Lastenheft Spezifikation Validierung Benutzer- und Systemanforderungen Durchführbarkeitsstudie Systemmodelle Pflichtenheft Karsten Weicker, Nicole Weicker 30/ 44

35 Vorgehensweise: Anforderungsspezifikation B: Anforderungsspezifikation: Durchführbarkeitsstudie Beantwortet eine (oder mehrere) der folgenden Fragen: Beitrag zur Verwirklichung der Gesamtziele des Unternehmens? Realisierbar unter Nutzung der derzeitigen Technologie und innerhalb des Kosten- und Zeitrahmens? Kompatibel mit bestehenden Systemen? Karsten Weicker, Nicole Weicker 31/ 44

36 Vorgehensweise: Anforderungsspezifikation B: Anforderungsspezifikation: Validierung Ziele: Gültigkeitsprüfungen Konsistenzprüfungen Vollständigkeitsprüfungen Realisierbarkeitsprüfungen Verifizierbarkeitsprüfungen Techniken: Anforderungs-Reviews Prototypen Testfallerzeugung automatische Konsistenzanalyse Karsten Weicker, Nicole Weicker 32/ 44

37 Vorgehensweise: Anforderungsspezifikation B: Anforderungsspezifikation Glass-Gesetz Mängel hinsichtlich der Anforderungen sind die Hauptursache für das Scheitern von Projekten. (nach Endres & Rombach, 2003) Karsten Weicker, Nicole Weicker 33/ 44

38 Vorgehensweise: Anforderungsspezifikation B: Anforderungsspezifikation Boehms erstes Gesetz Fehler kommen einerseits am häufigsten während der Anforderungs- und der Entwurfsphase vor und sind andererseits umso kostspieliger je später sie entfernt werden. (nach Endres & Rombach, 2003) Karsten Weicker, Nicole Weicker 34/ 44

39 Vorgehensweise: Anforderungsspezifikation Aufbau der Vorlesung als Spirale Prozessmodelle Kostenschätzung Risikomanagement Qualitätsmanagement Vermeid. v. Missverständnis Nichtfunkt. Anforderungen Strukturen und Muster Testen funkt. Anforderungen UML Aufgaben des Projektmanagements Funkt. Anforderungen am Beispiel Vorgehensweisen Code-Verstehen D C B A A = Anforderungsanalyse B = Anforderungsspezifikation C = Systementwurf D = Implementation Karsten Weicker, Nicole Weicker 35/ 44

40 Vorgehensweise Software-Entwurf C: Aktivitäten in allen Entwurfsprozessen Systemstrukturierung, z.b. Admin- Zugriff Kunden- Zugriff Datenspeichermodell: Berichtgenerator Datenspeicher Warenlager Karsten Weicker, Nicole Weicker 36/ 44

41 Vorgehensweise Software-Entwurf C: Aktivitäten in allen Entwurfsprozessen Systemstrukturierung, z.b. Admin- Zugriff Kunden- Zugriff Datenspeichermodell: Berichtgenerator Datenspeicher Warenlager Client 1 Client 2 Netzwerk Client-Server-Architektur: Katalog- Server Bilder- Server Web- Server Karsten Weicker, Nicole Weicker 36/ 44

42 Vorgehensweise Software-Entwurf C: Aktivitäten in allen Entwurfsprozessen Systemstrukturierung, z.b. Admin- Zugriff Kunden- Zugriff Datenspeichermodell: Berichtgenerator Datenspeicher Warenlager Client 1 Client 2 Netzwerk Client-Server-Architektur: Katalog- Server Bilder- Server Web- Server GUI Programmlogik Schichtenmodell: Datenbank Karsten Weicker, Nicole Weicker 36/ 44

43 Vorgehensweise Software-Entwurf C: Aktivitäten in allen Entwurfsprozessen Modellierung der Steuerung zentrale Steuerung Aufruf/Rückgabe-Modell hier sind Abweichungen vom Betrieb nur schwer möglich Managermodell (oder Event-Loop-Modell) ereignisgesteuerte Systeme Broadcast-Modell, z.b. Integration in einem Netzwerk Interrupt-getriebene Modelle, z.b. Echtzeitsysteme Karsten Weicker, Nicole Weicker 37/ 44

44 Vorgehensweise Software-Entwurf C: Aktivitäten in allen Entwurfsprozessen Dekomposition in Module Objektmodelle lose gekoppelte Objekte kommunizieren miteinander an Datenanalyse orientiert Datenflussmodell: Funktionalitäten werden gekapselt, die Daten transformieren Karsten Weicker, Nicole Weicker 38/ 44

45 Vorgehensweise Software-Entwurf C: Entwurf: Vorgehensweise Erstellung Architektur-Vision Lastenheft Pflichtenheft Dekomposition in Bausteine Architektur definieren Bewertung der Alternativen Karsten Weicker, Nicole Weicker 39/ 44

46 Vorgehensweise Software-Entwurf C: Entwurf: Erstellen der Architektur-Vision z.t. parallel zur Anforderungsanalyse erste Skizze der Architektur grundlegende Auswahl der Architekturstile (Strukturierung und Steuerung) Architektur-/Entwurfsmuster Technologien gesamte Bandbreite der Anforderungen abdecken Karsten Weicker, Nicole Weicker 40/ 44

47 Vorgehensweise Software-Entwurf C: Entwurf: Dekomposition des Systems in Bausteine basierend auf bekannten Lösungen Referenzarchitekturen, Architekturmuster etc. oder anhand von Architektur-Prinzipien anschließend: Iterative Verfeinerung der Architektur-Vision durch Ergebnisse aus der Anforderungsspezifikation Karsten Weicker, Nicole Weicker 41/ 44

48 Vorgehensweise Software-Entwurf C: Entwurf: Bewertung von Alternativen große Entscheidungsfreiheit führt zu vielen Architektur-Alternativen Bewertungsansätze: Checklisten: Liste detaillierter Fragen zu funktionalen und nicht-funktionalen Anforderungen Szenarien: Auftraggeber, Benutzer und Architekten erarbeiten Szenarien (z.b. zur Erweiterbarkeit) Architektur-Prototypen Karsten Weicker, Nicole Weicker 42/ 44

49 Vorgehensweise Software-Entwurf C: Entwurf: Bewertung von Alternativen Curtis Gesetz Ein guter Entwurf erfordert tiefes Wissen hinsichtlich des Anwendungsgebietes. (nach Endres & Rombach, 2003) Karsten Weicker, Nicole Weicker 43/ 44

50 Vorgehensweise Software-Entwurf Zwei Minuten Aufgabe Schlagen Sie für die folgenden Beispiele jeweils eine geeignete Systemstrukturierung vor. Suchmaschine zur Suche im Internet nach Bildern und Web-Seiten elektronisches Warenhaus Reinigungsroboter zum Säubern freier Fussbodenflächen, der Wände und andere Hindernisse erkennt Karsten Weicker, Nicole Weicker 44/ 44

51 Vorgehensweise Software-Entwurf Zwei Minuten Aufgabe Schlagen Sie für die folgenden Beispiele jeweils eine geeignete Systemstrukturierung vor. Suchmaschine zur Suche im Internet nach Bildern und Web-Seiten Client-Server elektronisches Warenhaus Schichtenmodell Reinigungsroboter zum Säubern freier Fussbodenflächen, der Wände und andere Hindernisse erkennt Datenspeichermodell Karsten Weicker, Nicole Weicker 44/ 44