Software Engineering II (SE)

Größe: px
Ab Seite anzeigen:

Download "Software Engineering II (SE)"

Transkript

1 Software Engineering II (SE) 1) Einführung Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: SommerSemester 09 (Stand: ) Studiengang InBac 2, Hochschule Augsburg, 2009 Die vorliegenden Unterlagen dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

2 Literatur Begleitend zum Unterricht Ian Sommerville: Software Engineering, 6. Auflage, Pearson Studium, Addison-Wesley, 2001 Bernd Oestereich: Die UML-Kurzreferenz für die Praxis, Oldenbourg, 2001 Literatur Roger S. Pressman: Software Engineering, A Practitioner s Approach, 4. Auflage, The McCraw-Hill Companies Inc., 1997 Helmut Balzert: Lehrbuch der Software-Technik (Band 1): Software-Entwicklung, Spektrum Akademischer Verlag, 2000 Helmut Balzert: Lehrbuch der Software-Technik (Band 2): Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung, Spektrum Akademischer Verlag (1998) Christine Rupp et al.: Requirements-Engineering und Management, 3.Auflage, Hanser, 2004 Jeckle, Rupp, Hahn, Zengler, Queins: UML 2 glasklar, 1.Auflage, Hanser, 2003 Rumbaugh/Jacobson/Booch: The Unified Modeling Language Reference Manual, Auflage: Bk&CD-Rom, Addison-Wesley Professional, 1998 Peter Liggesmeyer: Software-Qualität: Testen, Analysieren und Verifizieren von Software, Spektrum Akademischer Verlag,

3 Literatur 3

4 Gliederung Einführung 1. Überblick und Terminologie 2. Geschichtlicher Überblick und Software Krise 3. Modellbildung 4. Software Ingenieur 5. Ziele der Vorlesung 4

5 Legende zu den Folien Schwarze Textfarbe Text ist auf Folien der Studierenden vorhanden Erklärender Text Blaue Textfarbe Text ist nicht auf Folien der Studierenden vorhanden Zu ergänzender Text Rote Textfarbe, fettgedruckter oder kursiver Text Hervorgehobener Text 5

6 1. Überblick und Terminologie (1) 6

7 1. Überblick und Terminologie (2) Software (SW) computer programs, procedures, rules, and possibly associated documentation and data pertaining to the operation of a computer system IEEE Standard Glossary of Software Engineering Softwaresystem: Ein System (oder Teilsystem), dessen Komponenten aus Software bestehen Software-Produkt: Ein Produkt ist ein in sich abgeschlossenes, i. A. für einen Auftraggeber bestimmtes Ergebnis eines erfolgreich durchgeführten Projekts oder Herstellungsprozesses. Ein abgeschlossener Teil eines Produktes wird als Teilprodukt bezeichnet SW-Produkt: Produkt, das aus Software besteht 7

8 1. Überblick und Terminologie (3) SW Eigenschaften immateriell wird nicht durch physikalische Gesetze begrenzt Modellbildung schwierig Anforderungen oft unzureichend geklärt Kann Defekte enthalten Beispiele: Konstruktionsfehler, Spezifikationsfehler oder Portierungsfehler Ersatzteile gibt es nicht (nur evtl. Patches) schwer zu vermessen Was ist gute und was ist schlechte Software? leicht änderbar kein Verschleiß aber SW Aging (Alterung) ständige Veränderungen nötig 8

9 1. Überblick und Terminologie (4) Was ist Software Engineering? The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. IEEE Standard Gegenstand des Software Engineering ist die ingenieurmäßige Entwicklung komplexer Softwaresysteme hoher Qualität unter Berücksichtigung der einzusetzenden Arbeits- und Zeitressourcen 9

10 1. Überblick und Terminologie (5)... Gebietseinordnung Elektrotechnik Software Engineering Maschinenbau... Physik Informatik Psychologie Betriebswirtschaft... Mathematik Ingenieurwissenschaften Grundlagenwissenschaften Hilfswissenschaften M. Broy, D. Rombach: Software Engineering. Wurzeln, Stand und Perspectiven, in: Informatik Spektrum 25:6, pp ,

11 1. Überblick und Terminologie (6) Die SE Phasen Planungsphase Problemdefinition Definitionsphase Designphase Anforderungen Spezifikation Entwurf (Modell) System Design zeitlicher Ablauf? Implementationsphase Abnahme- u. Einführungsphase SW Entwicklung Verifkation und Testen Wartungs- u. Pflegephase 11

12 1. Überblick u. Terminologie (7) Schwierigkeiten bei der SW Entwicklung Kommunikationsprobleme mit Usern wenig Wissen über die Anwendung bei Designern und Entwicklern Anwender hat unklare Vorstellungen des Systems Arbeitsabläufe werden durch SW oft verändert Akzeptanz- und Integrationsprobleme SW Varianten Konfiguration und Versionierung wird schwieriger SW Einsatz in verschiedenen Umgebungen Portabilitätsprobleme Abhilfe: Standards, Methoden und Werkzeugen 12

13 1. Überblick u. Terminologie (8) CASE Tools CASE: (engl.) Computer Aided SW Engineering Tools: Einsatz von Werkzeugen Beispiele Visual Paradigm (Visual Paradigm International) Rational Rose (Rational) Enterprise Architekt (Sparx)... Inhalte: im Mittelpunkt steht die Modellierung UML (Unified Modeling Language) Transformation in verschiedene Programmiersprachen Datenstrukturen Reverse Engineering Generierung von Prototypen 13

14 2. Geschichtlicher Überblick und SW Krise (1) agile Modelle V-Modell Wasserfallmodell, Spiralmodell 14

15 2. SW-Krise (2) Phänomen: tratt erstmals Mitte der 60er auf Erstmalig: Kosten für SW > Kosten der HW Folge: erste große SW-Projekte scheiterten Grund: die bisher genutzten Techniken konnte nicht mit dem Umfang und der Komplexität der SW mithalten Auf einer NATO Tagung (1968) wurde das Phänomen diskutiert und als Reaktion der Begriff des Software Engineering eingeführt 15

16 2. SW-Krise(3) Standish Group CHAOS Studie über IT-Projekte, Kostenüberschreitungen bleiben die Regel 16

17 2. SW-Krise (4) Schlussfolgerungen aus der Software-Krise Früher war SW-Entwicklung ähnlich wie der Bau von Häusern OHNE Architekten, Pläne und Maschinen,. SW-Entwicklung ist keine (nicht nur) kreative Kunst SW-Entwicklung ist hauptsächlich eine ingenieurmäßige Wissenschaft mit wohldefinierter Vorgehensweise => Aus Fehlern anderer Lernen! 17

18 3. Modellbildung (1) Girl and globe Quibeldey-Cirkel, Objekt-Paradigma, 1994, S

19 3. Modellbildung (2) Poppers 3 Welten Sir Karl Raimund Popper (*1902; 1994) war ein österreichisch-britischer Philosoph, der mit seinen Arbeiten u.a. zur Erkenntnistheorie beitrug 19

20 3. Modellbildung (3) Bedeutung von Modellen für SE Terminologische Unterscheidung zwischen Realität und Modellen ist wichtig Reales Objekt und Modell-Objekt (z.b. repräsentiert durch OO Klasse) wird unterschieden Modelle sind nötig damit wir Menschen komplexe Abläufe verstehen Vereinfachung, Abstraktion Je ähnlicher ein Modell einem realem Objekt wird, desto besser ist das Modell Abwägungen zwischen Kosten/Zeit und Nutzen sind notwendig 20

21 3. Modellbildung (4) Überblick UML Diagrammarten (aktuelle Version: V2.0 -> V2.1) UML-Diagramme Strukturdiagramme Verhaltensdiagramme * * * * * * Komponenten -diagramme * * Klassendiagramme Objektdiagramme Kompositionsstrukturdiagramme Paketdiagramme Verteilungsdiagramme * * Interaktionsdiagramme Zeitdiagramme Interaktionsübersicht Use Casediagramme Aktivitätsdiagramme Zustandsdiagramme Kommunikationsdiagramme Sequenzdiagramme 21

22 4. Der SW-Ingenieur Bezeichnung für einen Menschen der systematisch SW entwirft und implementiert Aufgaben und Kenntnisse des SW-Ingenieurs: SW-Produkt: Anwendungsgebiet Bedienung u Ergonomie (Zukunfts-) Pläne Ressourcen: Team HW/SW Plattformen Hilfsmittel (Tools) SW-Prozess: Prozessablauf Methoden SW-Entwicklung Wiederverwendung Projekt: Projektformen Projektmanagement Schätzverfahren 22

23 5. Ziele der Vorlesung (1) Vorschau Vorlesung Kapitel 2: Vorgehensmodelle und Planungsphase Kapitel 3: Definitionsphase Kapitel 4: Designphase Kapitel 5: Implementierungsphase Kapitel 6: Abnahme- und Einführungsphase Kapitel 7: Wartungs- und Pflegephase 23

24 5. Ziele der Vorlesung (2) Was ist Software Engineering und warum ist die Erstellung von qualitativ hochwertiger Software so schwer? Ingenieurstätigkeit zur Softwareerstellung SW ist immateriell und die Modellbildung schwierig Verstehen und beherrschen der einzelnen Phasen bei der Entstehung von Software Phasen: Problemanalyse, Anforderungsdefinition, System- und Softwareentwurf, Implementierung, Integration und Systemtests, Betrieb und Wartung Studieren einer breiten Auswahl wichtiger und nützlicher Verfahren die dazu beitragen Software mit Qualität zu produzieren Beispiele: Vorgehensmodelle, Requirement Engineering, UML, SW-Architekturen, Testverfahren, Managementmethoden, Wartung und Weiterentwicklungstechniken... 24

25 Software Engineering II (SE) 2) Vorgehensmodelle und Planungsphase Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: Hochschule Augsburg, 2008 Die vorliegenden Unterlagen dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

26 Gliederung 1. Vorgehensmodelle 2. Übersicht Planungsphase 3. Lastenheft 4. Projektplanung 5. Projektmanagement 6. Aufwandsschätzung 7. Risikomanagement 2

27 Lernziel Was beinhaltet ein Vorgehensmodell? Was sind die Aufgaben und Ergebnisse der Planungsphase? Welche Schätzverfahren gibt es für den Aufwand einer SW? Was sind Ziele des Risikomanagements? 3

28 1. Vorgehensmodelle (1) Abstrakte Darstellung Modell - für das Vorgehen während des Prozesses des SE Stellt die Lebenszyklen von SW dar Legt Aktivitäten fest Gibt eine Reihenfolge der Aktivitäten vor Die Aktivitäten werden zu Phasen zusammengefasst Jede Phase hat Phasenziele Aktivitäten und Rollenzuordnungen Dokumentation Methoden, Richtlinien, Konventionen, Werkzeuge und Sprachen 4

29 1. Vorgehensmodelle (2) Vorteile Leitfaden für die Systementwicklung gemeinsame und verbindliche Sicht der logischen und zeitlichen Struktur eines Projekt projektbegleitende Dokumentation Planbarkeit Zertifizierbarkeit Personenunabhängigkeit frühzeitige Fehlererkennung durch festgeschriebene Testaktivitäten 5

30 1. Vorgehensmodelle (3) Die SE Phasen die alle Vorgehensmodelle beinhalten Planungsphase Problemdefinition Definitionsphase Designphase Anforderungen Spezifikation Entwurf (Modell) System Design Implementationsphase SW Entwicklung Abnahme- u. Einführungsphase Verifkation und Testen Wartungs- u. Pflegephase 6

31 1. Vorgehensmodelle (4) Das Wasserfallmodell (Royce, 1970) Planungsphase Definitionsphase Designphase Implementationsphase Abnahme- u. Einführungsphase Wartungs- u. Pflegephase 7

32 1. Vorgehensmodelle (5) Das Wasserfallmodell Beschreibung Aus jeder Phase gehen Dokumente hervor, die reviewed und abgenommen werden Vorgängerphasen sollen abgeschlossen sein Vorteile Linearer Prozess: einfach zu verstehen, klarer Ablauf Top-Down Vorgang Nachteile Starre Aufteilung in die Phasen Keine Rückkopplung auf frühere Phasen möglich Verpflichtungen zu frühen Zeitpunkten Neu dazukommende Anforderungen nicht integrierbar Entspricht häufig nicht den Notwendigkeiten in der Praxis Praxis Phasenüberlappungen und Informationsaustausch 8

33 1. Vorgehensmodelle (6) Verbesserte Wasserfallmodelle Planungsphase Iterativ Definitionsphase Inkrementell Planungsphase Definitionsphase Designphase Designphase Implementationsphase Abnahme- u. Einführungsphase Wartungs- u. Pflegephase Implementationsphase Abnahme- u. Einführungsphase Wartungs- u. Pflegephase 9

34 1. Vorgehensmodelle (7) Verbesserte Wasserfallmodelle Beschreibung Wie Wasserfallmodell aber Wiederholung der einzelnen Phasen bei Bedarf Vorteile Linearer Prozess: einfach zu verstehen, klarer Ablauf Wiederholungen sind möglich Ausbau des Produkts in mehreren Versionen möglich Nachteile Starre Aufteilung in die Phasen Verpflichtungen müssen zu einem frühen Zeitpunkt eingegangen werden Neu dazukommende Anforderungen sind aber integrierbar Praxis Viele Wiederholungen sind teuer 10

35 1. Vorgehensmodelle (8) Das V-Modell Modernere Versionen V-Modell 97 V-Modell XT 11

36 1. Vorgehensmodelle (9) Das V-Modell Dokumente werden als Produkte bezeichnet Jedes definierte Produkt durchläuft vier Zustände Aktivitäten: Tätigkeiten, die Produkte verändern 12

37 1. Vorgehensmodelle (10) Das V-Modell Vier Submodelle: Systemerstellung (SE) Qualitätssicherung (QS) Konfigurationsmanagement (KM) Projektmanagement (PM) Jedes Submodell hat Aktivitäten, Produkte und Rollen Aktivitäten auf verschiedenen Abstraktionsebenen möglich logische Abhängigkeiten zwischen Aktivitäten und Produkten Personen haben Rollen 13

38 1. Vorgehensmodelle (11) Das V-Modell Beschreibung lediglich Aktivitäten und Ergebnisse werden definiert Keine strikte zeitliche Abfolge Keine Abnahmen am Phasenende Vorteile Geeignet für große Systeme und Komplexität Detaillierte Vorgaben, Ergebnismuster, Rollendefinitionen Nachteile Testaktivitäten erst recht spät Zu strikter Phasenablauf Hoher Schulungsaufwand Praxis Vorgehensmodell für die Softwareentwicklung für staatliche Organisationen und Behören in Deutschland Für kleine Projekt oft zuviel Overhead 14

39 1. Vorgehensmodelle (12) Das Spiralmodell (Böhm, 1988, IEEE) 15

40 1. Vorgehensmodelle (13) Das Spiralmodell Beschreibung Iterative Behandlung der Phasen Flexibles Modell: Vorgehensmodell für jeden Zyklus und jedes Teilprodukt separat festlegbar 16

41 1. Vorgehensmodelle (14) Das Spiralmodell Vorteile Inkrementeller Ansatz Jeder Spiralzyklus führt zu Verbesserungen, Änderungen und Erweiterungen In kurzer Zeit einsatzfähige Produkte Flexibles Modell Nachteile Phasen werden immer wieder von neuem Durchlaufen Prototypen können komplett neue Programmierung erfordern Hoher Managementaufwand (neue Entscheidungen) Praxis Viele Spiralzyklen sind teuer Für große Projekte geeignet 17

42 1. Vorgehensmodelle (15) Rational Unified Process (RUP) Empirischer Sammlung von best practices Iterative Softwareentwicklung Anforderungsmanagement Verwendung komponentenbasierter SW-Architekturen Visuell gestützte SW-Modellierung (UML) Kontrolliertes Änderungsmanagement Eigenschaften Ist Objektorientiert Basiert auf Wasserfallmodell Neue Softwareversion mit jedem Durchlauf des Wasserfalls Iterative Vorgehensweise in Phasen Iterationsschritte innerhalb der Phasen Inkrementelles Wachstum über mehrere Zyklen (Firma Rational) 18

43 1. Vorgehensmodelle (16) Rational Unified Process (RUP) 19

44 1. Vorgehensmodelle (17) Rational Unified Process (RUP) Vorteile RUP ist architekturorientiert und anwendungsorientiert Bietet disziplinierten Weg für Aufgaben und Rollen im Projekt Gute Tool-Unterstützung (UML) Viele Erfahrungen sind eingeflossen Nachteile Komplexes Modell Qualitätssicherung ist nicht richtig integriert Abhängigkeit von kommerziellen Tools Praxis Geignet für große und komplexe Systeme 20

45 1. Vorgehensmodelle (18) Das agile Modell Weiterentwicklung des iterativen Paradigmas, bei der die Planung der Iterationen dynamisch erfolgt stetige Anpassung an Änderungen Prinzipien: Individuum und Interaktion ist wichtiger als Prozess und Werkzeug ausführbare SW ist wichtiger als vollständige Dokumentation Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlung Berücksichtigung von Änderungen ist wichtiger als Bestehen auf Plänen Beispiele SCRUM, XP (extreme Programming) 21

46 1. Vorgehensmodelle (19) Das agile Modell (Hindel et al., Basiswissen SW- Projektmanagement,,dpunkt Verlag, 2006) 22

47 1. Vorgehensmodelle (20) Das agile Modell Projektmanagement Planning Game Small Releases 40-hour Week (sustained pace) Architektur Simple Design Refactoring Dokumentation Coding Standard Metaphor Spezifikation und Validation Testing (Test First) Pair Programming On-Site Customer Collective Ownership Continuous Integration 23

48 1. Vorgehensmodelle (21) Das agile Modell Beispiel: Projektmanagement 24

49 1. Vorgehensmodelle (22) Das agile Modell Der Mensch steht mit im Mittelpunkt Bescheidenheit Respekt Innovation Menschliche Werte Feedback Kommunikation Mut zur Wahrheit Ehrlichkeit 25

50 1. Vorgehensmodelle (23) Das agile Modell Prinzipien 40 h Woche CCO-Collective Code Ownership Mehrfache Verwendung von Ressourcen (Wirtschaftlichkeit) Customer on Site Anforderungen werden erst umgesetzt wenn sie benötigt werden Prinzipien Dokumentation nur wo nötig/viele Bausteine Einfachheit (z.b. Konzepte, Sprache) Totale Qualitätsorientierung (ähnlich zu TQM) 26

51 1. Vorgehensmodelle (24) Das agile Modell Methoden Code Konventionen Ständige Integration Pair-Programming Testgetriebene Entwicklung Refactoring Methoden Story Cards Rapid Code Reviews Automatisierte Buildprozesse 27

52 1. Vorgehensmodelle (25) Das agile Modell Beschreibung Lightweightes Modell (Wasserfall, iterativ, incrementell, Spiral,...) Vorteile geringer bürokratischer Aufwand Wenige und flexible Regeln Nur soviel Dokumentation wie nötig Verspricht besseres Kosten/Nutzen-Verhältnis Vermutlich durchschnittliche Code-Qualität besser Nachteile Gesamtes Team muss sich an Regeln halten Ergebnis ist nicht vorhersagbar Refactoring geht nicht bei nicht OO-Sprachen Praxis Geeignet für kleine Projektteams und kleine, flexible Systeme 28

53 2. Übersicht Planungsphase (1) Grundsätzliche Vorgehensweise 1. Ist-Aufnahme Beschreibung des momentanen Systems und dessen Zustand (Ist-Aufnahme) 2. Ist-Analyse Wie ist der Zustand des momentanen Systems, kann das System verbessert werden und wenn ja wo? Schwachstellenanalyse Wo sind Änderungen notwendig? 29

54 2. Übersicht Planungsphase (2) Grundsätzliche Vorgehensweise 3. Verbesserungsvorschläge Sammlung von Lösungsalternativen Grobe Beschreibung wie die Veränderungen aussehen sollen Beschreibung wie die Veränderungen herbeigeführt werden können 4. Soll-Konzept Auswahl einer Alternative Formales Modell momentanen Zustands Formales Modell der geplanten Alternative Spezifikation: Lastenheft 30

55 2. Übersicht Planungsphase (3) 31

56 2. Übersicht Planungsphase (4) Aufgaben 1. Voruntersuchung Ist-Aufnahme und Ist-Analyse, Verbesserungsvorschläge, Soll-Konzept, Festlegung der prägnantesten Anforderungen 2. Machbarkeitsstudie Untersuchung der Realisierbarkeit, Prüfung auf Abdeckung Standard-SW, Verfügbarkeitsprüfung von Ressourcen, Risikoanalyse 3. Produktplanung Auswählen des Produkts, Trendstudien, Marktanalysen, Integration von Forschungsergebnissen, Kundenanfragen/-analysen 4. Projektplanung Projektplan: Aufwandsschätzung mit Kosten-, Ressourcen- und Terminplan 32

57 2. Übersicht Planungsphase (5) Schriftliche Ergebnisse 1. Voruntersuchung: Lastenheft 2. Machbarkeitsstudien : Studien 3. Produktplanung: Studien, Risikoanalyse 4. Projektplanung: Kosten-, Termin- u. Ressourcenplan Beteiligte Auftraggeber Projektleiter Anwendungsspezialist Fachlicher Entwickler 33

58 3. Lastenheft (1) Lastenhefterstellung in der Planungsphase Verfeinerung in Definitionsphase zum Pflichtenheft Unterschiede? Lastenheft: Auftraggebersicht Pflichtenheft: Auftragnehmersicht Vertragsgegenstand ist das (verfeinerte) Pflichtenheft Vorgehensweise Outside-in: Zuerst Systemumgebung modellieren, dann Systeminterna modellieren Inside-out: Zuerst Systeminterna modellieren, dann Systemumgebung modellieren 34

59 3. Lastenheft (2) Aufgabe Zusammenfassung aller fachlichen Basisanforderungen Produktbeschreibung aus Sicht des Auftraggebers Beschreibung des WAS nicht des WIE Stakeholder Auftraggeber, Projektleiter, Anwendungsspezialist, fachlicher Entwickler Sprache Verbale Schrift, Diagramme, Graphiken Nummerierung jeder Anforderung Beispiel: siehe weitere Vorlesungsunterlagen 35

60 4. Projektplanung (1) Managementaufgaben Erstellung des Angebots Projekt- und Zeitplanung Projektkostenkalkulation Projektüberwachung und Reviews Auswahl und Beurteilung Ressourcen (Personal, Sachmittel) Präsentation und Erstellen von Berichten 36

61 4. Projektplanung (2) Ablauf Projektplanung 1. Randbedingungen aufstellen 2. Erste Einschätzungen der Projektparameter treffen 3. Meilensteine und Lieferschritte des Projekts definieren 4. Randbedingungen verhandeln Projektzeitplan aufstellen Aktivitäten gemäß Zeitplan beginnen Projektparameter überarbeiten Technische Reviews u mögl. Überarbeitung Projektfortschritt prüfen 37

62 5. Projektmanagement (1) DIN-Norm (DIN 69901): Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes Hauptaufgaben des Projektmanagers Terminmanagement Kostenmanagement Inhalt und Umfang der Aufgaben definieren, koordinieren und steuern Personalmanagement Ein Projektmanager hat die Funktion die Erwartungen der Stakeholder zu erfüllen 38

63 5. Projektmanagement (2) Wissensgebiete des Projektmanagements (PMI: Project Management Institute, 39

64 5. Projektmanagement (3) t Beispiel für zeitlichen Ablauf PM Projekt definieren PM Projekt verfolgen und steuern PM Projektplan erstellen PM Projekt abschließen SE Anforderungen analysieren SE Detailkonzept verfeinern SE integrieren & testen der Komponenten SE Installation beim Kunden SE Detailkonzept erstellen SE entwickeln der Komponenten SE Systemintegration SE Auslieferung vorbereiten QM QS Testplan erstellen Individuelle Komponentenentwicklung Standard Komponentenentwicklung QM Systemtestfälle festlegen QM Systemtest durchführen QM Prüfmethoden & Kriterien festlegen KM KM-Plan erstellen KM Projektbegleitende KM Dienste 40

65 5. Projektmanagement (4) Gantt-Diagramm (Ablaufplan) 41

66 5. Projektmanagement (5) Pert-Diagramm (Netzplan) 42

67 6. Aufwandsschätzung (1) Während der Projektplanung wird das Projekt in Aufgaben unterteilt Jede Aufgabe wird bezüglich ihres Aufwands, ihrer Zeit und ihrer Kosten geschätzt (Soll-Ist) Regelmäßige Soll-Ist Analysen sind wichtig Beispiel: Anforderung_nr: 433 Aufgabe_nr: 23 Funktion: UserLogin() Aufwand: 2 Personen Zeit: a` 2 Manntage Kosten: 8h*2Personen*2Tage* 80Euro/h = 2560 Euro 43

68 6. Aufwandsschätzung (2) Gesamtkosten Projekt bestehen hauptsächlich aus HW-, SW-Kosten, Wartung Reisekosten, Schulungskosten Personalkosten SW-Entwicklerkosten Raumkosten (Heizung, Beleuchtung, Miete) Supplementäres Personal: techn. Personal, Sekretärinnen,... Kommunikationskosten (Netze, ,...) Kosten für zentrale Einrichtungen: Druckereidienste Sozialversicherungen (SV, KV, Mitarbeiterzuwendungen, Renten...) 44

69 6. Aufwandsschätzung (3) Produktivität Analogie Fertigungssystem: Produktivität = produzierte Stückzahl / Anzahl für die Produktion erforderlichen Personenstunden Produktivität in SW-Systemen unterliegt anderen Regeln Unterschiedliche Problemlösungen möglich SW hat Performance- bzw. Effektivitätsunterschiede die nicht mit obiger Formel berechnet werden können Maße für SW-Produktivität Größenspezifische Maße: LOC (Lines of Code), Anzahl gelieferter Objektcodeanweisungen, Anzahl Seiten der Dokumentation Funktionsspezifische Maße: Function Points, Object Points 45

70 6. Aufwandsschätzung (4) Einflussfaktoren auf die Produktivität Erfahrungen im Anwendungsgebiet Kenntnisse ermöglichen effektive SW Entwicklung Prozessqualität Verwendetes Vorgangsmodell Projektgröße Beispiel: große Projekte erfordern mehr Kommunikation Techn. Unterstützung Gute Hilfstools Arbeitsumgebung Persönliches Wohlbefinden 46

71 6. Aufwandsschätzung (5) LOC Probleme Keine Standards zur Zählung vorhanden Programmiersprachenabhängig Ausführliche Programmierung versus komprimierter Programmierung Datendeklarationen Leerzeilen Aussagekraft? Guter oder schlechter Code nicht unterscheidbar Produktivitätsvergleiche zwischen Systemen sind nur mit Vorbehalten durchführbar 47

72 6. Aufwandsschätzung (6) Function Points Albrecht (1979), Gaffney 1983) Sprachunabhängig Produktivität zwischen Systemen kann verglichen werden Ein FP wird pro Personenmonat erzeugt Eignet sich für Ein- und Ausgabeorientierte Datenverarbeitungssysteme Gesamtanzahl Function Points = Messung der Anzahl von Externen Ein- und Ausgaben Benutzerinteraktionen Externe Schnittstellen Vom System verwendete Dateien 48

73 6. Aufwandsschätzung (7) Function Points Gewicht: Jede Funktion hat Komplexitätswert (z.b. einfach 1 bis komplex 10) UFC: Unadjusted Function Point Count UFC= Σ(Anzahl der Häufigkeit der Funktion * Gewicht) Weitere Faktoren die mit UFC multipliziert werden können Grad verteilte Verarbeitung Ausmaß Wiederverwendbarkeit Leistungsfähigkeit... Folge: subjektive Schätzung AVC: Durschnittliche Codegröße einer Programmiersprache Codegröße = AVC * Anzahl Function Points 49

74 6. Aufwandsschätzung (8) Function Points (Balzert, Lehrbuch SW-Technik, S.86) 50

75 6. Aufwandsschätzung (9) Object Points Banker et al. (1992) Einsetzbar wenn 4GLs oder vergleichbare Sprachen eingesetzt werden Schätzmodell COCOMO2 verwendet Ops OP!= Klassen OP = Anzahl der angezeigten Bildschirmmasken (einfache =1 OP, komplexe=3 OPs) Anzahl erzeugter Berichte (einfache =2 OP, komplexe=8 OPs) Anzahl der 3GL Module (höhere Programmiersprache), die zur Ergänzung des 4GL Codes entwickelt werden müssen (1 Modul = 10 Ops) Einfacher zählbar als Function Points 51

76 6. Aufwandsschätzung (10) Probleme bei Maßen mit Volumen/Zeit Nicht-funktionale Eigenschaften der SW werden nicht berücksichtigt Zuverlässigkeit, Wartungseigenschaften, Verbesserung von Code,... Wiederverwendung wird nicht berücksichtigt Sie setzen voraus: Mehr = Besser Manager sollten daher geschult werden und vorsichtigen Umgang mit diesen Maßen pflegen 52

77 6. Aufwandsschätzung (11) Schätzverfahren Algorithmisches Aufwandsmodell * LOC/Projektkosten Expertenbeurteilung Mehrere Schätzungen werden gemittelt oder sich auf eine geeinigt Analogieschätzung Kosten analog zu abgeschlossenem ähnlichen Projekt schätzen Parkinsons Gesetzt Arbeit dehnt sich immer so aus, dass sie genau die Zeit braucht, die man für sie erübrigen kann. Kosten = verfügbare Ressourcen und Lieferfrist Price to win Kosten = Kunden-Budget 53

78 6. Aufwandsschätzung (12) Algorithmisches Aufwandsmodell Kann durch Analyse der Kosten und Merkmale abgeschlossener Projekte entstehen Schätzung der Kosten aufgrund Projektgröße Anzahl SW-Designer, SW-Entwickler Prozess- und Produktfaktoren Exponentialfaktor Kosten steigen nicht linear mit Projektumfang Multiplikatoren können Merkmale berücksichtigen Merkmale des Produkts Entwicklungsplattformen Prozess- und Personenmerkmale (z.b. Erfahrungsgrade) 54

79 6. Aufwandsschätzung (13) Allgemeine Formel für Softwarekosten Aufwand = A * Größe B * M (Kitchenham 1990) A: konstanter Faktor für Unternehmenseigene Praktiken und Art der SW Größe: Schätzung der Größe LOC, Function Points oder Object Points B: Aufwand für übergroße Projekte und liegt zwischen 1,0..1,5 M: Multiplikator und setzt sich aus einer Kombination von Prozess-, Produkt- und Entwicklungsmerkmalen zusammen 55

80 6. Aufwandsschätzung (14) Unsicherheit der Schätzung (Sommerville, SE, S.529 aus Boehm et al. 1995) 56

81 6. Aufwandsschätzung (15) Das (algorithmische) COCOMO-Modell 81 COCOMO (engl. Constructive Cost Model) Basiert auf Erfahrungen Wasserfall-Modell und Neuentwicklung der SW Drei-Stufen-Modell 1. Grunddaten (grobe Schätzung) (Boehm, 1981) 2. Verbesserung durch Projekt- und Prozessmultiplikatoren 3. Einzel-Schätzung für verschiedene Projektphasen Frei verfügbar (Public Domain), gut dokumentiert Wird häufig verwendet 57

82 6. Aufwandsschätzung (16) Das (algorithmische) COCOMO-Modell 81 (Boehm, 1981) KDSI: Kilo Lines of Delivered Source Instructions PM: Aufwand in Personenmonaten Projektkomplexität Einfach Mittel Komplex, Eingebettet Formel PM=2,4*(KDSI) 1,05 *M PM=3,0*(KDSI) 1,12 *M PM=3,6*(KDSI) 1,20 *M 58

83 6. Aufwandsschätzung (17) Das (algorithmische) COCOMO-2 Komplexere und detailliertere Schätzung Basiert auf Verschiedene Vorgehensmodelle und Verfahren (z.b. Prototyp, Komponenten, 4GLs) Stufen sind mit Vorgängen im SW-Prozess verbunden ->frühe Schätzungen möglich Drei-Stufen-Modell 1. Frühe Prototypstufe: Größenschätzung mit Object Points 2. Frühe Entwurfsstufe: Systemanforderung abgeschlossen; Größenschätzung mit Function Points 3. Stufe nach Architekturenwurf: Genaue Schätzung 59

84 6. Aufwandsschätzung (18) Teufelsviereck (Sneed, 1983) 60

85 7. Risikomanagement (1) Risikokategorien Projektrisiken: Zeitplan, Ressourcen Personalveränderungen, Managementveränderungen, Nichtverfügbarkeit von HW/SW, Änderung von Anforderungen, Verzögerungen, Unterschätzung des Umfangs Produktrisiken: Qualität, Leistung Änderung von Anforderungen, Verzögerungen, Unterschätzung des Umfangs, schlechte CASE-Tools, unzureichende Hilfsmittel Wirtschaftliche Risiken: Auswirkung auf Unternehmen Technologieveränderungen, Konkurrenz 61

86 7. Risikomanagement (2) Risikoerkennung Risikoanalyse Risikoplanung Risikoüberwachung Liste potentieller Risiken Priorisierte Liste pot. Risiken Risikovermeidungsplan, Notfallplan Risiko Bewertung 62

87 Lernziel Was beinhaltet ein Vorgehensmodell? Ein Vorgansmodell beinhaltet Aktivitäten die den SW Lebenszyklus darstellen. Das Vorgansmodell gibt die Reihenfolge der Aktivitäten vor. Die Aktivitäten sind zu Phasen zusammengefasst. Was sind die Aufgaben und Ergebnisse der Planungsphase? Aufgaben: Voruntersuchung, Machbarkeitsstudie, Produktplanung, Projektplanung Ergebnisse: Lastenheft, Studien, Risikoanalyse, Kosten-, Terminund Ressourcenplan Welche Schätzverfahren gibt es für den Aufwand einer SW? Algorithmisches Aufwandsmodell, Expertenbeurteilung, Analogieschätzung, Parkinsons Gesetz, Price to win Was sind Ziele des Risikomanagements? Projekt-, Produkt-, und Wirtschaftliche Risiken frühzeitig erkennen, dokumentieren, und Vermindern 63

88 Software Engineering II (SE) 3) Definitionsphase und Requirements Engineering Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: Hochschule Augsburg, 2008 Die vorliegenden Unterlagen zur Vorlesung dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

89 Gliederung 1. Überblick Definitionsphase 2. Pflichtenheft 3. Requirements Engineering 1. Anforderungen 2. Erhebung von Anforderungen 3. Anforderungsanalyse Notationen im Überblick 4. Validation von Anforderungen 5. Anforderungsmanagement 2

90 Lernziel Was ist Requirements Engineering? Welche Eigenschaften haben gute Anforderungen? Wie findet man Anforderungen? Wie testet man Anforderungen? 3

91 1. Überblick Definitionsphase (1) Grundsätzliche Vorgehensweise Definieren der (Produkt-) Anforderungen Modellierung der fachlichen Lösung Anforderungsmanagement vieler Anforderungen iterativ Was ist eine Anforderung? Eine Anforderung spezifiziert die qualitativen und quantitativen Eigenschaften eines Produkts aus Sicht des Auftraggebers Eine Anforderung muss eindeutig und testbar sein Anforderungen sind die Grundlage für die Systemarchitektur 4

92 1. Überblick Definitionsphase (2) Aufgabe: Requirements Engineering (Systemanalyse, Anforderungsanalyse) Anforderungen ermitteln Anforderungen analysieren Anforderungen beschreiben Anforderungen als fachliche Lösung modellieren Optional: Anforderungen animieren, simulieren, ausführen Anforderung verabschieden Woher kommen die Anforderungen? Auftraggeber Fachabteilung Benutzer oder Repräsentanten der Endbenutzer Marketingabteilung 5

93 1. Überblick Definitionsphase (3) Requirements Engineering Prozess Input: Anwenderwissen, Dokumentation, Vorschriften,... Anf. ermitteln Anf. analysieren Anf. dokumentieren Anf. prüfen Output: Pflichtenheft 6

94 1. Überblick Definitionsphase (4) Beteiligte Auftraggeber Projektleiter und... Schriftliches Ergebnis: Pflichtenheft (Balzert, SE, S.99) 7

95 2. Pflichtenheft (1) Enthält alle fachlichen Anforderungen, die das SW-Produkt aus Sicht des Auftraggebers enthalten muss Beschreibung des WAS nicht des WIE Ist Vertragsbestandteil = Lieferumfang Gleiche Gliederung wie Lastenheft Unterschiede Lastenheft - Pflichtenheft Lastenheft: Problemspezifikation Sicht des Kunden für den SW-Produzent Pflichtenheft: Anforderungsspezifikation Sicht des SW-Produzent für den Kunden Input 8

96 2. Pflichtenheft (2) Benutzer Pflichtenheft Anwendungsspezialist / Systemkunden Anforderungen festlegen Überprüfen ob Anforderung Erwartungen entspricht Anforderungsänderungen Projektmanager Erstellen des Angebots Planung des SW-Entwicklungsprozesses SW-Entwickler Aufgrund Anforderungen verstehen was für ein System entwickelt werden soll Systemtester Benutzung der Anforderungen für Validierungstests Wartungspersonal Systemintegration, Wartung, Pflege 9

97 3. Requirements Engineering 3.1 Anforderungen (1) Inhalt einer Anforderung Fachlicher Inhalt Zusätzlicher Inhalt Die Art des Systems Verwendete Normen und Standards Die Kritikalität des Systems Systemumfang Komplexität der Systemabläufe Beobachtbarkeit der Arbeitsschritte Art der Anforderung Erfahrung im Fachgebiet Detaillierungsgrad der Anforderungen 10

98 3.1 Anforderungen (2) Anforderungsarten Funktionale Anforderung Beschreibung Dienste die das System leisten soll Aktionen die das System selbstständig ausführen soll Oder allgemeine funktionale Vereinbarungen und Einschränkungen Beispiel: Sende Fehlermeldung XYZ zum Nachbarssystem wenn Ereignis ABC eingetreten ist Lese Datei XYZ in den Hauptspeicher ein 11

99 3.1 Anforderungen (3) Anforderungsarten Nicht-funktionale Anforderung Beschreibung Technische Anforderungen, Anforderungen an die zu verarbeitenden Informationen, Qualitätsanforderungen... Beispiel: Eingabefelder die Pflicht für den Benutzer sind sollen mit einem Sternchen markiert werden Der Algorithmus XYZ muss in 2 Sec ausführbar sein 12

100 3.1 Anforderungen (4) 13

101 3.1 Anforderungen (5) Anforderungsarten Problembereichsanforderung Beschreibung Anforderungen die sich aus dem Anwendungsbereich ergeben Spezielle Bedürfnisse von Systembenutzern Beispiel: Es sollte eine Standardbenutzerschnittstelle zu allen beteiligten Datenbanken geben, die auf dem Z39.50-Standard basiert 14

102 3.1 Anforderungen (6) Anforderungsarten Benutzeranforderung Beschreibung Anforderungen die das externe Verhalten des Systems betreffen (Ein-, Ausgaben) Anforderungen sollen verständlich für Systembenutzer geschrieben werden Beispiel: Es soll ein Report XYZ ausgedruckt werden, wenn der Button Drucken vom Benutzer gewählt wird 15

103 3.1 Anforderungen (7) Anforderungsarten Systemanforderung Beschreibung Anforderungen die als genauere Beschreibung der Benutzeranforderungen dienen Beschreiben wie die Benutzeranforderungen umgesetzt werden sollen (nicht zu Verwechseln mit wie es implementiert werden soll!) Beispiel: Das Datenaustauschformat für die zu übertragende Datei der Benutzeranforderung A soll XML sein Das System soll eine Client-Server Architektur besitzen 16

104 3.1 Anforderungen (8) Qualitätsmerkmale für Anforderungen Vollständigkeit Korrektheit Klassifizierbarkeit Konsistenz Prüfbar Eindeutigkeit Verständlichkeit Aktualität Realisierbarkeit Notwendigkeit Verfolgbarkeit Bewertbarkeit (Rupp et al. Requirment Engineering und Management, S. 21, 2004) 17

105 3.1 Anforderungen (9) Sprache bei Anforderungen Natürlich sprachliche Anforderungen Methoden Standardformulare Vorlagen Beispiele Word/Excel Vorlagen Probleme Vorlagen oft zu wenig Strukturiert Mangel an Genauigkeit Verwirrung bei Anforderungen Verschmelzung von Anforderungen 18

106 3.1 Anforderungen (10) Sprache bei Anforderungen Natürlich sprachliche Anforderungen Vollständige Schablone mit Bedingungen Wann? Unter welcher Bedingung? MUSS SOLL KANN DAS SYSTEM <wem> DIE MÖGLICHKEIT BIETEN FÄHIG SEIN <Objekt & Ergänzung des Objekts> <Prozess -wort> (Rupp, RE, S.492) Beispiel: Das System A muss dem Administrator die Möglichkeit bieten, eine Fehlermeldung auf dem Netzwerkdrucker zu drucken 19

107 3.1 Anforderungen (11) Sprache bei Anforderungen Anforderungen in strukturierter Sprache Methode Ähnlich wie Programmiersprache Definition eines Befehlssatzes Beispiele PDLs (engl. Program Description Languages) Eigenkreationen Pseudocode Probleme Befehlssatz nicht ausreichend / genau genug Nur für SW-Entwickler verständlich Anforderungen können für einen Entwurf gehalten werden 20

108 3.1 Anforderungen (12) Sprache bei Anforderungen Anforderungen in graphischer Notation Methode Graphische Sprache Ergänzt durch Kommentare und Anwendungsfallbeschreibungen Beispiele SA (Structured Analysis) UML: Use-Case Diagramm Probleme Manchmal sagen Worte mehr als Bilder Kommentare werden oft zu spärlich eingesetzt Nur für SW-Designer/SW-Entwickler verständlich 21

109 3.1 Anforderungen (13) Probleme bei der Anforderungsanalyse Unklare Zielvorstellungen Hohe Komplexität Sprachbarrieren Veränderliche Anforderungen Schlechte Qualität der Anforderungen Beschreibung unnötiger Merkmale Ungenaue Planung und Verfolgung des Projekts 22

110 3.2 Erhebung von Anforderungen (1) Einige Ermittlungstechniken Kreativitätstechniken Brainstorming Ereignisse sammeln Methode Teilnehmer entwickeln je 3 Ideen und geben diese auf je einem Kärtchen dem jeweiligen Nachbarn, der diese dann kommentiert. Karten weitergeben bis jeder Teilnehmer jede Karte besessen hat (5-mal) Beobachtungstechniken Feldbeobachtung Systemanalytiker beobachtet die Arbeitsabläufe von Stakeholdern während ihrer täglichen Arbeit Apprenticing ( in die Lehre gehen ) Systemanalytiker erlernt die Arbeitsabläufe der Stakeholder unter deren Anleitung 23

111 3.2 Erhebung von Anforderungen (2) Einige Ermittlungstechniken Befragungstechniken Fragebogen Multiple-Choice Fragen, offene Fragen an Stakeholder Interview Systemanalytiker stellt Stakeholder mündliche Fragen On-Site Customer Ein Stakeholder ist als Vertreter beim SW-Entwickler vor Ort Vergangenheitsorientiert Techniken Systemarchäologie Analoge existierende Systeme und die dazugehörigen Dokumente werden beobachtet bzw. gelesen Reuse Anforderungen eines ähnlichen Systems werden wiederverwendet und abgeändert 24

112 3.2 Erhebung von Anforderungen (3) Anwendbarkeit von Ermittlungstechniken (Rupp et al., RE, S.84) 25

113 3.3 Anforderungsanalyse Notationen im Überblick (1) SA (Strukturierte Analyse) (Tom DeMarco 1978) Eine SA eines Systems besteht aus DFD: Datenflußdiagramme Stufen: Top-Down Verfeinerung DD: Data Dictionary Minispezifikationen: kleine Prozessbeschreibungen Stufenkonzept Ebene 0: Kontextdiagramm Ebene 1: Erste Verfeinerungsebene Ebene 2: Zweite Verfeinerungsebene (je Funktion aus 1) Ebene 3:

114 3.3 Anforderungsanalyse Notationen im Überblick (2) SA (Strukturierte Analyse) Beispiel: Ebene 0: Kontextdiagramm Kunde Suchanfrage Liste von Partnern Adressbestellung Partnerschaftsvermittlung verwalten Suchanfrage Liste von Partnern Mitarbeiter Bestellbestätigung Neuer Partner 27

115 3.3 Anforderungsanalyse Notationen im Überblick (3) SA (Strukturierte Analyse) Beispiel: Ebene 1 Kunde Suchanfrage Adressbestellung Liste von Partnern Partner suchen Bestellung durchführen Partner Bestellungen Suchanfrage Mitarbeiter Liste von Partnern Neuer Partner Partner eintragen Bestellbestätigung 28

116 3.3 Anforderungsanalyse Notationen im Überblick (4) SA (Strukturierte Analyse) Notationselemente Externe Schnittstelle Datenfluss Funktion (Beschreibung: Hauptwort + Verb!) Speicher Wichtig: Alles wird beschriftet! 29

117 3.3 Anforderungsanalyse Notationen im Überblick (5) SA (Strukturierte Analyse) Vorteile Möglichkeit zur Abbildung komplexer Systeme Übersichtlichkeit durch Stufenkonzept Leicht erlernbar Gut geeignet für prozedurale SW-Entwicklung Nachteile Zeitliche Reihenfolge der Ereignisse nicht festgelegt Schwer lesbar für Nicht-Informatiker Speicher und Schnittstellen können nicht verfeinert werden Nicht-funktionale Anforderungen nicht darstellbar 30

118 3.3 Anforderungsanalyse Notationen im Überblick (6) Use-Case Diagramm (Anwendungsfalldiagramm) UML-Diagrammtyp (engl. Unified Modelling Language) Eine Use-Case Diagramm eines Systems besteht aus Systemrahmen: Systemgrenzen Akteuren: Personen, Fremdsysteme Assoziationen: Wer tut was Use-Cases: Funktionen Verfeinerung durch andere Diagrammtypen aus UML 31

119 3.3 Anforderungsanalyse Notationen im Überblick (7) Use-Case Diagramm Notationselemente Akteur Assoziation Use-Case (Beschreibung: Hauptwort + Verb!) Systemgrenze Wichtig: Alles wird beschriftet! 32

120 3.3 Anforderungsanalyse Notationen im Überblick (8) Use-Case Diagramm Beispiel 33

121 3.3 Anforderungsanalyse Notationen im Überblick (9) Use- Case Diagramm Beschreibung eines Use-Cases Use Case: Partner suchen 34

122 3.3 Anforderungsanalyse Notationen im Überblick (10) Use-Case Diagramm Vorteile Möglichkeit zur Abbildung komplexer Systeme Leicht erlernbar Funktionale Anforderungen aus Sicht des Anwenders gut darstellbar Übersichtlichkeit durch Top-Down Vorgehen Durch Beschreibungen für natürliche Sprache geeignet Gut geeignet für OO SW-Entwicklung Nachteile Zeitliche Reihenfolge der Ereignisse nicht festgelegt Schwer lesbar für Nicht-Informatiker Nicht-funktionale Anforderungen nicht darstellbar 35

123 3.3 Anforderungsanalyse Notationen im Überblick (11) (J.D. Schulz: Requirements-based Unified Modeling Language, A Borland White Paper, 2003) 36

124 3.3 Anforderungsanalyse Notationen im Überblick (12) (J.D. Schulz: Requirements-based Unified Modeling Language, A Borland White Paper, 2003) 37

125 3.3 Anforderungsanalyse Notationen im Überblick (13) (J.D. Schulz: Requirements-based Unified Modeling Language, A Borland White Paper, 2003) 38

126 3.4 Validation von Anforderungen (1) Ziele guter Anforderungen Syntaktisch Verfolgbarkeit, Redundanzfreiheit, gute Struktur, angemessener Umfang, Eindeutigkeit, Notwendigkeit, rechtliche Verbindlichkeit Semantisch (inhaltlich fachliche Aspekte) Korrektheit, Gültigkeit, Vollständigkeit Weiterverwendung Realisierbarkeit, Bewertbarkeit, Verständlichkeit 39

127 3.4 Validation von Anforderungen (2) Prüfung von Anforderungen Ziele Qualitätskriterien für die Anforderung erfüllen Aufdecken von Fehlern und Schwächen Fehlende Informationen (Lücken), Widersprüche, Redundanzen, Fehlerhaftes Systemverhalten Vorgehen Zeitpunkt: Nach Definition, vor Implementation Prüfer identifizieren Prüftechnik festlegen Prüfung durchführen 40

128 3.4 Validation von Anforderungen (3) Prüfung von Anforderungen Potentielle Prüfer (Rupp et al., RE, S.293) 41

129 3.4 Validation von Anforderungen (4) Prüftechniken Stellungnahmen von Stakeholdern Prototyp/Simulationsmodell Verhalten des Prototypen testen Analysemodell z.b. Mengengerüste für Daten aufstellen Reviews, Inspektion, Walkthrough Gemeinsames Verständnis aller Beteiligten suchen Manchmal: Kickoff-, Follow-up- und Exit-Meetings Sprachliche Schablonen prüfen Abnahmekriterien aufstellen und prüfen 42

130 3.4 Validation von Anforderungen (5) Beispiel für Abnahmekriterien Aufbau von Entscheidungstabellen Abnahmekriterium AN3 Nutzer Neue Daten Kunde Alter: [0-17] nein Fehler auf-getreten syntaktisch semantisch n.a. - A1: Fehlermeldung Keine passenden Partner vorhanden X Abnahmekriterium Nr Ergebnis Datum/ Uhrzeit Tester AN3: Fehlermeldung zu A1 OK Schz 43

131 3.5 Anforderungsmanagement (1) Gruppierung von Anforderungen...Ordung ist das halbe Leben......Wer suchet der findet... Nach Anforderungsart Nach Merkmalen Beispiele: Zuverlässigkeit, Benutzbarkeit, Effizienz,... Nach Detailebenen des System Nach Priorität Nach Kritikalität Nach rechtlicher Verbindlichkeit: Muss, Kann,... 44

132 3.5 Anforderungsmanagement (2) Requirement Management Tools Beispiele DOORS (Telelogic) RequisitePro (IBM Rational) RTM (Integrated Chipware) Caliber (Borland) CARE (Sophist Group) (Rupp et al., RE, S.391) 45

133 Lernziel Was ist Requirements Engineering? Requirements Engineering umfasst die Anforderungsanalyse und das Anforderungs-management mit ingenieurmäßigem Vorgehen Welche Eigenschaften haben gute Anforderungen? Vollständig, korrekt, klassifizierbar, konsistent, prüfbar, eindeutig, verständlich, aktuell, realisierbar, hat Notwendigkeit, verfolgbar, bewertbar Wie findet man Anforderungen? Durch Kreativität, Beobachten (Vergangenheit oder aktuelles Vorgehen), Befragen und nutzen unterstützender Techniken Wie testet man Anforderungen? Zeitpunkt: Nach Definition, vor Implementation, Prüfer identifizieren, Prüftechnik festlegen, Prüfung durchführen 46

134 Software Engineering II (SE) 4) SW Design Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: Hochschule Augsburg, 2008 Die vorliegenden Unterlagen zur Vorlesung dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

135 Gliederung SW Design 1. Überblick SW Design 2. Notationen 3. Grundlagen 4. Schlüsselthematiken 5. SW Struktur und Architektur 6. DW Design und Qualität 7. Strategien und Methoden 2

136 Lernziel Welche Techniken des SW Designs gibt es im allgemeinen? Welche Diagrammtypen gibt es grundsätzlich um SW Design auszudrücken? Was ist der Unterschied zwischen Makroarchitektur und Mikroarchitektur? 3

137 1. Überblick SW Design (1) SW Design ist der Prozess die SW Architektur, Komponenten, Schnittstellen und andere Merkmale eines Systems oder einer Komponente zu definieren das Ergebnis dieses Prozesses [IEEE Std (R2002), Standard Glossary of Software Engineering Terminology, 1990] 4

138 1. Überblick SW Design (2) Prozesssicht: SE Lebenzyklus Aktivität in der die Anforderungen analisiert werden um die interne Struktur der SW zu produzieren Ergebnissicht: Beschreibung der SW Architektur: Wie SW zerlegt wird, in Komponenten organisiert wird und wie die Schnittstellen zwischen den Komponenten sind 5

139 1. Überblick SW Design (3) Aufgaben Wichtige Phase bei der SW Herstellung Definition der Vorgehensweise Modellbildung SW Ingenieure produzieren eine Vielzahl an unterschiedlichen Modellen Die Modelle bilden einen Plan wie die Lösung implementiert werden kann Die Modelle werden analysiert und evaluiert ob sie die Anforderungen (erstellt in der Definitionsphase) erfüllen Alternative Lösungen und deren Zielkonflikte werden diskutiert Die resultierende Modellierung dient als Startpunkt für die Implementierung und als Vorlage für die Testphase 6

140 1. Überblick SW Design (4) Aktivitäten 1. Erstellung der SW Architektur (Makroarchitektur) Top-Level Design: Beschreibung der Software auf hohem Abstraktionsniveau und deren Organisation Identifikation der SW Komponenten 2. Erstellung des Detailkonzepts (Mikroarchitektur) Detaillierte Beschreibung jeder Einzelkomponente um die Implementierung zu ermöglichen 7

141 1. Überblick SW Design (5) Ergebnis Pflichtenheft u. evtl. erweitertes Entwurfsdokument Inhalt: Vielzahl von Modellen für jede Komponente der SW Frage die beantwortet wird: WIE soll die SW entwickelt werden Beteiligte Systemanalytiker SW-Entwickler 8

142 2. Notationen (1) Notationen dienen dazu SW Design Artefacte zu repräsentieren Sie helfen dabei eine einheitliche Sprache zu bilden beim SW Design Häufig durch graphische Darstellungen repräsentiert, aber auch andere Darstellungsformen sind manchmal sinnvoll Einsatz Manche Notationen eigenen sich mehr zur Darstellung der Makroarchitektur, andere eher zur Darstellung der Mikroarchitektur Manche Notationen können in der SW Definitions- und in der SW Design Phasen eingesetzt werden 9

143 2. Notationen (2) Überblick UML Diagrammarten (aktuelle Version: V2.0 -> V2.1) UML-Diagramme Strukturdiagramme Verhaltensdiagramme * * * * * * Komponenten -diagramme * * Klassendiagramme Objektdiagramme Kompositionsstrukturdiagramme Paketdiagramme Verteilungsdiagramme * * Interaktionsdiagramme Zeitdiagramme Interaktionsübersicht Use Casediagramme Aktivitätsdiagramme Zustandsdiagramme Kommunikationsdiagramme Sequenzdiagramme 10

144 2. Notationen (3) Beispiel Klassendiagramme Technisches Konzept Fachliches Konzept 11

145 2. Notationen (4) Beispiel Aktivitätsdiagramm [ja] 12

146 3. Grundlagen (1) Allgemeine Designkonzepte SW ist nicht das einzige Gebiet indem Design eine Rolle spielt Man kann Design als eine Form von Problemlösung bezeichnen Beispiel für eine andere Problemlösung Diskussion der Grenzen des Systems, nicht aber des Inhalts Allgemeine Vorgehensweise: Ziele setzen, Einschränkungen ermitteln, Alternativen diskutieren, Lösungen präsentieren und umsetzen 13

147 3. Grundlagen (2) Techniken des SW Designs Abstraktion Abstraction is the process of forgetting information so that things that are different can be treated as if they were the same (F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, 1996) Methoden: Parametrisierung und Spezifikation Typen: Prozedurale Abstraktion, Datenabstraktion, Kontrollabstraktion (Iteration) 14

148 3. Grundlagen (3) Techniken des SW Designs Abstraktion Beispiel Methode: Example_Controller() Erlaubte Eingabewerte: 1-3 1: User hat Button OK gedrückt->daten speichern 2: User hat Button CANCEL gedrückt->daten verwerfen 3: User hat Button BACK gedrückt->seite zurückblättern Abhängig vom Parameterwert werden unterschiedliche Funktionen ausgeführt Abstraktion für Kommandozentrale 15

149 3. Grundlagen (4) Techniken des SW Designs Kopplung Stärke der Beziehung zwischen Modulen Beispiele Lose Kopplung: Datenaustausch zweier Komponenten über eine Message Queue Sender Empfänger Enge Kopplung: direkter Datenaustausch Sender Empfänger 16

150 3. Grundlagen (5) Techniken des SW Designs Kohäsion Wie Elemente innerhalb eines Moduls aufgebaut sind Stärke der funktionalen Bindung Starke Kohäsion hat eine Programmeinheit wenn sie für genau eine wohldefinierte Aufgabe verantwortlich ist Beispiele: Kontroll-Kohäsion Funktional: Nur genau die Aktivitäten für eine spezifische Aufgabe werden aktiviert Prozedural: Von einer Aktivität an die nächste Zeitlich: unabhängige Aktivitäten werden im zeitl. Zusammenhang aktiviert Meist wird unerwünschte Code-Duplizierung durch schwache Kohäsion verursacht. 17

151 3. Grundlagen (6) Techniken des SW Designs Dekomposition und Modularisierung Zerlegung einer großen SW in sinnvolle kleinere Teile SW Teile sollten möglichst unabhängig voneinander sein Ziel ist unterschiedliche Funktionalitäten und Verantwortlichkeiten in getrennten Komponenten unterzubringen 18

152 3. Grundlagen (7) Techniken des SW Designs Dekomposition und Modularisierung Beispiel 19

153 3. Grundlagen (8) Techniken des SW Designs Kapselung und Information Hiding Gruppieren und in geeigneten Paketen unterbringen Abstrakte Datentypen verwenden (z.b. Person, Bestellung,...) Interne Details eines abstrakten Datentyps nicht nach außen geben und nicht sichtbar machen Zugriff auf die internen Details von außen sperren 20

154 3. Grundlagen (9) Beispiel: Punkt Entfernung zweier Punkte Punkt P1 Punkt P2 d = PP = ( x2 x1 ) + ( y2 y1) include <math.h> class POINT { } privat: float x,y; public: POINT(float a, float b) { x=a; y=b; } float distance (POINT a) { float dx, dy; dx=x-a.x; dy=y-a.y; return (sqrt(dx*dx + dy*dy)); } 21

155 3. Grundlagen (10) Techniken des SW Designs Trennung von Schnittstellendefinition und Schnittstellenimplementierung Eine Komponente wird definiert durch ihre öffentliche Schnittstellendefinition und ihre separate Schnittstellenimplementierung Nur die öffentliche Schnittstelle wird dem benutzenden Clientprogramm bekannt gegeben Das Clientprogramm kennt jedoch nicht die Details wie die Schnittstelle implementiert ist Ändert sich die Schnittstellenimplementierung ist das Clientprogramm code-seitig davon nicht betroffen 22

156 3. Grundlagen (11) Beispiel: Programm zum Mittelwert- und Standardabweichung ermitteln Schnittstelle: Number.h typedef int Number; Number randnum(); leicht austauschbar zu int, float,... Implementierung: int.c #include <stdlib.h> #include Number.h Number randnum() { return rand(); } Clientprogramm: avg.c #include <iostream.h> #include <math.h> #include Number.h Int main (int argc, char *argv[]) { int N = atoi(argv[1]); float m1=0.0, m2=0.0; for (int i=0; i<n; i++) { Number x = randnum(); m1 += ((float) x)/n; m2 += ((float) x*x)/n; } cout << Mittelwert: <<m1<<endl; cout << Standardabw: <<sqrt(m2- m1*m1) <<endl; 23 }

157 3. Grundlagen (12) Techniken des SW Designs Einfachheitsprinzip: Ausreichend, Vollständig und Primitiv Eine SW Komponente sollte alle wichtigen Eigenschaften des abstrakten Datentyps abbilden Nicht mehr und nicht weniger Einfach zu verstehender Code sollte verwendet werden (mit Kommentaren!) 24

158 4. Schlüsselthematiken (1) Übergreifende Designaspekte Übergreifende Designaspekte sind weniger Einheiten der funktionalen Dekomposition, sondern Eigenschaften welche die Performance oder die Semantik von Komponenten beeinflussen systematisches Vorgehen Komponentenübergreifend 25

159 4. Schlüsselthematiken (2) Übergreifende Designaspekte Nebenläufigkeit Techniken wie man SW in Prozesse und Threads bringt. Prozesse und Threads können parallel (nebenläufig) ablaufen Zu berücksichtigen gilt: Effektivität Atomarität Synchronisation Scheduling Beispiel: Dining Philosophers Ψ Ψ Ψ Ψ Ψ 26

160 4. Schlüsselthematiken (3) Übergreifende Designaspekte Ereignisorientiertes Design Kontrolle und Behandlung von Events Kontrollfluss- und Datenfluss-Organisation Methodenauswahl für unterschiedliche Eventtypen (z.b. reaktive und temporale Events) Implizite Innvocation Call-backs Event.Handler einrichten Event-Quelle Event Objekt Event Listener Event Listener Event Listener 27

161 4. Schlüsselthematiken (4) Übergreifende Designaspekte Ereignisorientiertes Design Beispiel: HTML Eventhandler onclick <html><head><title>test</title> </head> <body> <form name="test" action=""> <input type="text" size="30" name="ausgabe" readonly="readonly"><br> <input type="button" value="letzter Update" onclick="this.form.ausgabe.value = document.lastmodified"> </form> </body> </html> 28

162 4. Schlüsselthematiken (5) Übergreifende Designaspekte Verteilung von Komponenten Konzept wie die SW auf die HW verteilt wird Kommunikation zwischen den Komponenten Verwendung von Middleware um mit heterogener SW umgehen zu können 29

163 4. Schlüsselthematiken (6) Übergreifende Designaspekte Fehler, Ausnahmebehandlung und Fehlertoleranz Konzept wie Fehler behandelt bzw. toleriert werden Und wie mit Ausnahmen umgegangen wird Beispiel: Datenbanktabelle Error_message DB-Absturz Falsche Eingabe Error_type ERROR WARNING Tolerance_level

164 4. Schlüsselthematiken (7) Übergreifende Designaspekte Interaktion und Präsentation Konzept wie mit dem Benutzer interagiert wird Struktur und Organisation der Interaktionen Beispiel: Modell-View-Controller Ansatz: Separation der Präsentations- und der Business Logik Präsentationsschichtsaufbau (Wie nicht Was) Präsentations-Logik Business-Logik 31

165 4. Schlüsselthematiken (8) Übergreifende Designaspekte Datenpersistenz Strikte Trennung von Daten und Programmen Persistenzschicht um auf Daten über (austauschbaren) Datenbanken zugreifen zu können Präsentationslogik Schicht Business Logik Schicht Datenpersistenz Schicht Daten 32

166 5. SW Struktur und Architektur (1) Eine Softwarearchitektur ist eine Beschreibung der Subssysteme und Komponenten eines SW Systems und der Beziehungen dazwischen Beinhaltet Makroarchitektur: High-Level Architektur Mikroarchitektur: Softwarestruktur Wiederverwendbarkeit Produktlinien Frameworks 33

167 5. SW Struktur und Architektur (2) Makroarchitektur Generelle Architekturen Schichten Beispiel: ISO-OSI 7-Schichtenmodell Pipes: FIFO Konstrukte Beispiel: Message Queues, allgemeine Warteschlangen Filter Beispiel: Spamfilter Blackboards Architekturmodell: Expertengruppe, Zusammenarbeit, Lösungen in hierarchisch organisierter Form ablegen 34

168 5. SW Struktur und Architektur (3) Makroarchitektur verteilte Architekturen Three-tier Architekturen Client Server Applikations Server Datenbank Server Client-Server Architekturen Benutzeroberfläche Applikationsserver Datenbankserver Operation anfordern Daten anfordern t Auf Ergebnis warten Auf Daten warten Daten zurückgeben Ergebnis zurückgeben 35

169 5. SW Struktur und Architektur (4) Makroarchitektur verteilte Architekturen Broker Architektur: Beispiel: Request Broker (Vermittler-Komponenten) Client Anwendung Client-side Proxy Logische Kommunikation Server Anwendung Server-side Proxy Request Broker physische Kommunikation 36

170 5. SW Struktur und Architektur (5) Makroarchitektur Interaktive Systeme Modell-View-Controller Präsentations-Logik Business-Logik Presentation-Abstraction-Control: Präsentationsschicht, Businessschicht, Datenpersistenzschicht, Datenschicht 37

171 5. SW Struktur und Architektur (6) Makroarchitektur Adaptive Systeme (deu: anpassungsfähig) Mikrokernel: Server Prozess Client Prozess Mikrokernel Speicher Interprozesskommunikation Reflektion: Zur Laufzeit (per Programm) nachsehen welche Funktionen ein Assembly anbietet 38

172 5. SW Struktur und Architektur (7) Makroarchitektur Andere Architekturen Batch Prozesse Interpreter Prozess Kontrolle Regel-basierte Systeme... 39

173 5. SW Struktur und Architektur (8) Mikroarchitektur Design Pattern Beispiele: SOA Service orientierte Architekturen Makroarch.: Client-Server Mikroarch.: Design Pattern z.b. Singelton 40

174 5. SW Struktur und Architektur (9) Mikroarchitektur Design Pattern Erzeugung: Singelton, Factory, Prototype, Builder Beispiel: Singelton (deu: Das Einzelstück) erzeugt und verwaltet das einzige Objekt der Klasse bietet globalen Zugriff auf dieses Objekt über eine Instanzoperation (getinstance(); ) die Instanzoperation ist eine Klassenmethode, das heißt statisch gefunden das private Attribut Instanz (instance) ist ein Klassenattribut, das heißt ein statisches Attribut 41

175 5. SW Struktur und Architektur (10) Mikroarchitektur Design Pattern Struktur: Facade, Adapter, Bridge, Composite, Decorator, Flyweight, Proxy Beispiel: Fassade Facade +Do_it() Client Complx_Facade Subsystem Bietet eine vereinfachte Schnittstelle zu einer Menge von Schnittstellen in einem Subsystem Vereinfachung des Gebrauchs des Subsystems Die komplizierten Schnittstellen des Subsystems werden gewrapped 42

176 5. SW Struktur und Architektur (11) Mikroarchitektur Design Pattern Verhalten: Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Visitor Beispiel: Observer Weitergabe von Änderungen an einem Objekt an von diesem Objekt abhängige Strukturen 43

177 5. SW Struktur und Architektur (12) SW Wiederverwendung (engl. Reuse) Produktlinien: Identifizieren von gemeinsamen Eigenschaften von Teilnehmern und Gründung einer Produktfamilie 44

178 5. SW Struktur und Architektur (13) SW Wiederverwendung (engl. Reuse) Frameworks: Ein teilweise fertiges SW System, dass vom SW Entwickler erweitert werden kann oft OO oft werden spezielle Plug-ins instanziiert Beispiel: Microsoft.NET Framework Common Language Infrastructure (CLI) Common Language Runtime (CLR) ist die Virtual Machine von.net Client-PC benötigt zur Ausführung das installierte.net Framework Veröffentlichter Code unter Microsoft Reference License; Es ist jedoch nicht erlaubt, den Quellcode zu modifizieren 45

179 6. SW Design Qualität (1) Qualitätsmerkmale Wartbarkeit Portabilität Testbarkeit Nachvollziehbarkeit Zur Laufzeit: Performance, Sicherheit, Verfügbarkeit, Funktionsfähigkeit, Verwendbarkeit Nicht zur Laufzeit: Modifizierbarkeit, Wiederverwendbarkeit, Integrationsfähigkeit, Testbarkeit Architektur-orientierte Merkmale Konzeptuelle Integrität, Korrektheit, Vollständigkeit, Buildability 46

180 6. SW Design Qualität (2) Qualitätsanalyse und Evaluierungstechniken SW Design Reviews: informal oder semi-formal Häufig in Gruppenform Untersuchung von SW Artefakten Architektur Review Design Review Inspektionen Scenario-orientierte Techniken Anforderungsnachverfolgung 47

181 6. SW Design Qualität (3) Qualitätsanalyse und Evaluierungstechniken Statische Analyse: formal oder semi-formal Untersuchung von SW Artefakten Fehlerbaumanalyse Automatisiertes Querchecken (z.b. Unit Test) Simulation und Protoyping: Dynamische Techniken ein Design zu evaluieren Performance Simulation Prototype bauen und prüfen 48

182 7. Strategien und Methoden (1) Strategien und Methoden helfen den Design Prozess zu leiten Methoden sind mehr spezifisch als Strategien und werden meist zusammen mit einer Menge von Notationen vorgeschlagen Methoden sind wichtig zum Wissenstransfer und dienen als eine Art Framework für SW Ingenieure 49

183 7. Strategien und Methoden (2) Generelle Strategien Teile und Herrsche template <class Item> void quicksort (Item a[], int l, int r) { if (r<=1) return; int i=partition(a, l, i-1); quicksort(a, l, i-1); quicksort(a,i+1,r); } Schrittweise Verfeinerung 50

184 7. Strategien und Methoden (3) Generelle Strategien Top-Down Vorgehen Bottom-Up Vorgehen 51

185 7. Strategien und Methoden (4) Generelle Strategien Datenabstraktion und Informtion Hiding Verwendung von Heuristiken Methode, komplexe Probleme, die sich nicht vollständig lösen lassen, mit Hilfe einfacher Regeln und unter Zuhilfenahme nur weniger Informationen zu entwirren Bei komplexen Aufgaben wird ein Kompromiss zwischen Laufzeit und der Güte der gefundenen Lösung eingegangen Beispiele: Einige evolutionäre Algorithmen, Such nach kürzesten Wegen in Graphen,... 52

186 7. Strategien und Methoden (5) Generelle Strategien Verwendung von Design Pattern Iteratives Vorgehen Wasserfallmodell Inkrementelles Vorgehen Release-Management: R1 R1.1 R2.0 R++ R

187 7. Strategien und Methoden (6) Funktions-orientiertes Design Klassische Methode Dekomposition Identifizieren der wichtigsten Funktionen zuerst Top-Down Vorgehen Bearbeiten und Verfeinern Verwendung von Diagrammtypen wie Structured Analysis Strukturcharts 54

188 7. Strategien und Methoden (7) Objekt-orientiertes Design Simpler Anfang Objekte zu identifizieren Noun = object Verb = method Adjective = attribute Vorgehensmöglichkeiten Komponenten-basiertes Vorgehen Vererbung und Polymorphismus identifizieren Daten-orientiertes Vorgehen Datenabstraktion Zuständigkeits-orientiertes Vorgehen Responsibilities identifizieren Meta-Informationen sammeln gewinnen und anwenden durch z.b. Reflektion Verwendung von allen UML Diagrammtypen Wiederverwendung steht im Vordergrund 55

189 7. Strategien und Methoden (8) Datenstruktur-orientiertes Design Beispiel: Entity-Relationship Diagramme, HIPO Diagramm SW Ingenieur beginnt zuerst Inputs und Outputs zu beschreiben Kontrollstruktur wird aufgrund der entstandenen Datenstrukturen entworfen Häufig werden Heuristiken eingesetzt Beispiel: wenn ein Versatz zwischen Input- und Outputdaten vorkommt 56

190 7. Strategien und Methoden (9) Komponenten-orientiertes Design Komponente: unabhängige Einheit Schnittstellen definieren Abhängigkeiten abschätzen Unabhängigkeit der Komponenten fördern wenn möglich Anbieten, entwickeln und integrieren von Komponenten Wiederverwendung stärken wo möglich 57

191 7. Strategien und Methoden (10) Andere Methoden Formale Methoden Transformationsmethoden Transaktionsmethoden... 58

192 Lernziel Welche Techniken des SW Designs gibt es im allgemeinen? Abstraktion, Kopplung, Kohäsion, Dekomposition, Modularisierung, Kapselung, Information Hiding, Trennung von Schnittstellendefinition und Schnittstellenimplementierung, Einfachheitsprinzip Welche Diagrammtypen gibt es grundsätzlich um SW Design auszudrücken? Strukturdiagramme, Verhaltensdiagramme Was ist der Unterschied zwischen Makroarchitektur und Mikroarchitektur? Makro: Beschreibung der Software auf hohem Abstraktionsniveau und deren Organisation Mikro: SW-Struktur 59

193 Software Engineering II (SE) 5) Verifikation und Validation Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: Hochschule Augsburg, 2008 Die vorliegenden Unterlagen zur Vorlesung dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

194 Gliederung 1. Grundlagen 2. SW Tests statisch dynamisch diversifizierend 2

195 Lernziel Welche Merkmale enthält Qualitäts-SW? Nennen Sie jeweils ein passendes Testverfahren dazu. Wie unterscheiden sich statische Testverfahren von dynamischen Testverfahren? Was ist eine Äquivalenzklasse und wofür wird Sie eingesetzt beim Testen? 3

196 1. Grundlagen (1) SW-Qualität nach ISO 9126 (DIN 66272) Funktionalität Korrektheit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit Zuverlässigkeit Reife, Fehlertoleranz, Wiederherstellbarkeit Benutzbarkeit Verständlichkeit, Bedienbarkeit, Erlernbarkeit, Robustheit Effizienz Wirtschaftlichkeit, Zeitverhalten, Verbrauchsverhalten Wartungsfreundlichkeit Analysierbarkeit, Änderbarkeit, Stabilität, Testbarkeit Übertragbarkeit Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit (Deutsches Institut für Normung e. V.,1994) Beispielmaß für Zuverlässigkeit: MTBF = gesamte Betriebszeit Anzahl der Ausfälle 4

197 1. Grundlagen (2) Testen Aktivität die ausgeführt wird um die SW Qualität zu evaluieren und zu verbessern indem Defekte und Probleme identifiziert werden Geprüft wird gegen erwartetes Verhalten (Anforderungsspezifikation) 5

198 1. Grundlagen (3) Ablauf Testfälle Test- Daten Test- Ergebnisse Test- Protokolle Entwerfen der Testfälle Erstellen der Testdaten Testausführung mit Testdaten Vergleich: Ergebnisse Testfälle (I. Sommerville, 2001, S. 427 ) Warum Testen? SW-Qualität Verifikation Spezifikation SW-Produkt Validierung Eignung SW-Produkt bezogen auf Einsatzzweck 6

199 1. Grundlagen (4) Aufgaben Tests planen Tests organisieren Tests durchführen Letzte Kontrollinstanz vor Freigabe Beteiligte SW Entwickler Prüfpersonal (z.b. unabhängige Organisation) SW Designer 7

200 2. SW Tests (1) Statischer Test Merkmale Es erfolgt keine Ausführung der zu prüfenden Software Alle statischen Analysen können prinzipiell ohne Computerunterstützung ausgeführt werden Es werden keine Testfälle gewählt Vollständige Aussagen über die Korrektheit oder Zuverlässigkeit können nicht erzeugt werden statisch verifizierend formal Zusicherungsverfahren symbolisch analysierend Maße Stilanalyse Grafiken und Tabellen Slicing Datenflussanomalieanalyse Inspektions- u Review-Technik Algebraische Techniken Automatenbasierte Techniken Sitzungstechnik formal Kommentartechnik informal (Liggesmeyer, SW-Qualität, 2002, S.34) 8

201 2. SW Tests (2) Statischer Test Stilanalyse (analysierende Technik) Beschreibung: Werkzeuge arbeiten ähnlich wie Compiler (lexikalische, syntaktische Prüfung) Analyse der Struktur des Codes Prüfung auf Einhaltung von Programmierrichtlinien Werkzeugunterstützung ist sinnvoll Beispiel: Syntaktische Prüfung: If (a==b) { Öffnende und schließende Klammer a=3; eines Blocks stehen stets alleine } else { in einer Zeile b=7; } Semantische Prüfung: Namenskonventionen: Keine Variablen die nur einen Buchstaben lang sind 9

202 2. SW Tests (3) Statischer Test Stilanalyse Einsatz: Die Stilanalyse ist bei Programmiersprachen mit liberaler, qualitätsmindernder Syntax (z.b. C im Gegensatz zu Ada) oft wichtig Vorteile: Werkzeugunterstützte Prüfung einiger Programmierrichtlinien Nachteile: Zusätzlicher Arbeitsschritt Keine Aussage zu Laufzeitverhalten 10

203 2. SW Tests (4) Statischer Test Inspektions- und Reviewtechnik (analysierende Technik) Beschreibung: Varianten Reviews in Kommentartechnik: grob, schnell, unkompliziert Informale Reviews: gründlich, zeitaufwendig, günstig Formale Reviews: sehr gründlich, sehr zeitaufwendig, teuer Prinzip der externen Qualitätskontrolle Eigenschaften: Festgelegte Eingangs- und Ausgangskriterien Definierte Inspektionsphasen mit QS-Zielvorgaben Teilnehmer mit verteilten Rollen Sammlung, Analyse von Inspektionsdaten einschließlich Rückkopplung auf den Inspektionsprozess Protokoll über erkannte Fehler 11

204 2. SW Tests (5) Statischer Test Inspektions- und Reviewtechnik (analysierende Technik) Inspektionsphasen Planung Vorbereitung Überblicksveranstaltung Inspektionssitzung Nacharbeit Follow-Up Organisatorische Vorbereitung Informationsverteilung über das Produkt Jeder Inspektor bereitet sich getrennt vor mit Inspektionsunterlagen Durchführung in Sitzungstechnik Durchführung der Fehlerkorrekturen Überprüfung der Fehlerkorrekturen und Anfertigung der Inpektionsberichte 12

205 2. SW Tests (6) Statischer Test Inspektions- und Reviewtechnik Einsatz: Semantische Prüfungen Ergebnis ist oft Meilenstein am Ende jeder Entwicklungsphase Wird häufig zu frühen Phasen sehr genau durchgeführt Vorteile: Effektivität in Bezug auf Anzahl gefundener Fehler steigt Nachteile: Keine Aussage zu Laufzeitverhalten 13

206 2. SW Tests (7) Dynamischer Test Merkmale Übersetzte, ausführbare SW wird mit konkreten Eingabewerten versehen und ausgeführt Es kann in der realen Betriebsumgebung getestet werden Dyn. Testtechniken sind Stichprobenverfahren Dyn. Testtechniken können die Korrektheit der getesteten SW nicht beweisen Ziel ist Testfälle zu erzeugen die repräsentativ fehlersensitiv redundanzarm und ökonomisch sind 14

207 2. SW Tests (8) Dynamischer Test dynamisch strukturorientiert kontrollflussorientiert Anweisungsüberdeckungstest Zweigüberdeckungstest Bedingungsüberdeckungstest Strukturierter Pfadtest und boundary interor Pfadtest Pfadtest LCSAJ-basierter Test Pfadüberdeckungstest datenflussorientert Defs-/Uses Kriterien Required k-tupels Test Datenkontext- Überdeckung funktionsorientiert funktionale Äquivalenzklassenbildung Zustandsbasierter Test Ursache-Wirkungs- Analyse Syntaxtest Transaktionsflussbasierter Test Test auf Basis von Entscheidungstabellen Unit Test (Liggesmeyer, SW-Qualität, 2002, S.34) 15

208 2. SW Tests (9) Dynamischer Test Techniken White-Box Techniken Strukturorientiert Testvollständigkeit anhand der Abdeckung der Strukturelemente des Codes Korrektheit wird anhand der Spezifikation beurteilt Einteilung kontrollflussorientiert datenflussorientiert (Liggesmeyer, SW-Qualität,2002, S.37) 16

209 2. SW Tests (10) Dynamischer Test Zweigüberdeckungstest (strukturorientierte, kontrollflussorientierte Technik) Beschreibung: Zweigüberdeckungstest subsumiert Anweisungsüberdeckungstest Ziel ist die Ausführung aller Zweige des Codes Testfälle mit definierten Eingabedaten finden, so dass alle Zweige abgedeckt werden Testmaß: C primitv = Anzahl ausgeführter primitiver Zweige Anzahl primitiver Zweige 17

210 2. SW Tests (11) Dynamischer Test Zweigüberdeckungstest Beispiel: Funktionsaufruf: Gesamtzahl=0 Eingelesene Zeichen: A, B, 1 Durchlaufener Pfad: (n start, n 1,n 2,n 3,n 4,n 5,n 2,n 3,n 5,n 2 n final ) (Liggesmeyer, SW-Qualität,2002, S.82) 18

211 2. SW Tests (12) Dynamischer Test Zweigüberdeckungstest Überdeckungsrate als Funktion der Testfallanzahl 19

212 2. SW Tests (13) Dynamischer Test Zweigüberdeckungstest Einsatz: Zweigüberdeckungstest ist weit verbreitet und oft Standard in Modultestwerkzeugen Vorteile: Aufspüren von nicht ausführbaren Programmzweigen Nachteile: Ungeeignet für den Test von zusammengesetzten Entscheidungen und für den Test von Schleifen Nichtlinearer Zusammenhang zwischen Überdeckungsrate und Testfallanzahl 20

213 2. SW Tests (14) Dynamischer Test Techniken Black-Box Techniken Funktionsorientiert Umsetzung der Spezifikation in Testfälle Testvollständigkeit anhand der Abdeckung der Eingabewerte und Äquivalenzklassen Korrektheit wird anhand der Spezifikation beurteilt Keine garantierte Vollständigkeit der Abdeckung der Programmstruktur (Liggesmeyer, SW-Qualität,2002, S.38) 21

214 2. SW Tests (15) Dynamischer Test Äquivalenzklassenbildung (funktionsorientierte Technik) Beschreibung: Es ist schwierig eine Auswahl von aussagekräftigen Testfällen aus einer großen Menge von Betriebssituationen zu gewinnen Es darf kein Fall ungetestet bleiben Gute Stellvertreter der Grundgesamtheit an Testfällen werden benötigt Äquivalenzklassenbildung durch Teile-und-herrsche Prinzip Komplexität wird durch Zerlegung reduziert Ein Wert einer Äquivalenzklasse wird stellvertretend für alle anderen der Klasse ausgeführt Durchführung von fortgesetzten Fallunterscheidungen für Eingabe- und Ausgabebedingungen 22

215 2. SW Tests (16) Dynamischer Test Äquivalenzklassenbildung Beispiel: Die Spezifikation lässt ausschließlich positive ganzzahlige Eingabewerte zu Gültige Äquivalenzklassen: 1: positive ganzzahlige Werte 2: Grenzwert: 0 Ungültige Äquivalenzklassen: 3: negative ganzzahlige Werte 4: nicht ganzzahlige Werte 5: Andere Zeichen Zugehörige Ausgabewertebereiche finden Aufstellen von Ergebnistabellen 23

216 2. SW Tests (17) Dynamischer Test Äquivalenzklassenbildung Einsatz: Modultest: Test konkreter Ein- Ausgabewerte Integrationstest: Test der Interaktionen über Schnittstellen Systemtest: Test unterschiedlicher Anwendungsfälle Vorteile: Test sehr einfach verständlich Nachteile: Programmcode wird nicht vollständig getestet Wechselwirkungen zwischen Äquivalenzklassen sind nicht testbar Nicht geeignet bei zustandsbasierter SW 24

217 2. SW Tests (18) Dynamischer Test Unit-Test (funktionsorientierte Technik) Beschreibung: Automatisierte Unit-Tests werden implementieren und stetig wiederholt Zu jeder Klasse wird eine entsprechende Testklasse implementiert Prüfung eines sehr kleinen und autarken Teil z.b. eine Methode Ein Testfall ist eine Methode und mit Testdaten zu konfrontieren Die laut Spezifikation zu erwartenden Ausgabewerte werden verglichen Stimmt das erwartete Ergebnis mit dem gelieferten Ergebnis der Funktion oder Methode überein, so gilt der Test als bestanden Häufig Betrachtung von Grenzfällen (sehr große/kleine Werte) und besonderer Werte (Null-Zeiger, Objekte in speziellen Zuständen) 25

218 2. SW Tests (19) Dynamischer Test Unit-Test Beispiel: //Programmcode public class Euro { public float GetEuroAmount(float dm) { float euro = dm / 1.955; // Console.WriteLine("dm->euro {0}=={1} ", dm, euro); return euro; } } //Testmethode public class TestEuro { public void TestGetEuroAmount() { Euro euro = new Euro(); Assertion.AssertEquals(euro.GetEuroAmount(1.955f), 1f); } } 26

219 2. SW Tests (20) Dynamischer Test Unit-Test Einsatz: Modultest OO-orientierte Systeme Vorteile: Automatisierte stetige Wiederholung eines minimalen Modultests Entwickler hält Methoden möglichst einfach und entwirft Objektstrukturen sauber, um einfache Tests implementieren zu können Unglücklich gewählte Schnittstellen fallen auf Komplexer Code fällt auf und wird refaktorisiert (vereinfacht) Weg zu Test-Driven Development Nachteile: Nicht geeignet für Benutzeroberflächen Bibliotheksfunktionen sind nicht testbar Nebenläufigkeit ist schwierig zu testen 27

220 2. SW Tests (21) Dynamischer Test Techniken diversifizierende Techniken Vergleich der Testergebnisse der diversitären SW Vermeidung der aufwändigen Bewertung der Korrektheit der Testergebnisse gegen die Spezifikation Häufig ist Automatisierung möglich (Liggesmeyer, SW-Qualität,2002, S.174) 28

221 2. SW Tests (22) Dynamischer Test - diversifizierend dynamisch diversifizierend Back to Back-Test Mutationen-Test Regressionstest (Liggesmeyer, SW-Qualität, 2002, S.34) ergänzt um Stresstest 29

222 2. SW Tests (23) Dynamischer Test Regressionstest (diversivizierende Technik) Beschreibung: Nachweis das Modifikationen keine unerwünschten Auswirkungen auf die Funktionalität besitzen Mehrmalige Ausführung einer Teilmenge der Testfälle ist nötig Vergleich der Ergebnisse mit Spezifikation und Vorgänger- Version der SW Automatisierter Test mit Werkzeug ist sinnvoll 30

223 2. SW Tests (24) Dynamischer Test Regressionstest Beispiel: (Liggesmeyer, SW-Qualität,2002, S.188) 31

224 2. SW Tests (25) Dynamischer Test Regressionstest Einsatz: Modultest Integrationstest Systemtest Vorteile: Erkennung von Veränderungen zur Vorversion einer SW Praxis-relevant Tools bieten oft auch Möglichkeiten zur Lasterzeugung für Leistungs- und Stresstests Nachteile: Fehler die in Vorversion schon vorhanden waren werden nicht sicher erkannt 32

225 Lernziel Welche Merkmale enthält Qualitäts-SW? Nennen Sie jeweils ein passendes Testverfahren dazu Funktionalität Unit Test, Zuverlässigkeit - MTBF, Benutzbarkeit - Regressionstest, Effizienz O-Notation, (Stresstest) Wartbarkeit - Regressionstest, Übertragbarkeit Black-Box Testen (Transaktionsflussbasiertes Testen) Wie unterscheiden sich statische Testverfahren von dynamischen Testverfahren? Statische: keine Ausführung der zu prüfenden Software Dynamische: Übersetzte, ausführbare SW wird mit konkreten Eingabewerten versehen und ausgeführt Was ist eine Äquivalenzklasse und wofür wird Sie eingesetzt beim Testen? Äquivalenzklasse: Stellvertreter der Grundgesamtheit von Daten Ein Wert einer Äquivalenzklasse wird stellvertretend für alle anderen der Klasse ausgeführt zur Reduktion der Testfälle 33

226 Software Engineering (SE) 6) SW Wartung Prof. Dr. Anja Schanzenberger Hochschule Augsburg, Fakultät für Informatik Kontakt: Hochschule Augsburg, 2008 Die vorliegenden Unterlagen zur Vorlesung dürfen nur verwendet werden für Studienzwecke durch Studierende der Hochschule Augsburg.

227 Gliederung 1. Grundlagen 2. Wartungsprozess 3. Wartungstechniken 2

228 Lernziel In welche Kategorien kann Wartung eingeteilt werden und wie unterscheiden sich diese Kategorien? Warum bezeichnet man SW Entwicklung in der Wartungsphase als evolutionär? Was ist der Unterschied zwischen Re-Engineering und Reverse Engineering? 3

229 1. Grundlagen (1) Was ist Wartung? Maßnahmen und Dienstleistungen zum Erhalt der Verwendbarkeit und Betriebssicherheit einer SW Phase im Lebenszyklus eines SW Produkts Aktivitäten um SW kosten-effektiv am Leben zu erhalten und dafür Support zu leisten Maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment (Standard IEEE 1219) 4

230 1. Grundlagen (2) Ziel in der Wartungsphase Existierende SW modifizieren Dabei soll die Integrität des SW Produkts erhalten bleiben Natur der Wartung Wartung ist eine Phase im Lebenszyklus eines SW Produkts Änderungsanfragen werden dokumentiert und verfolgt Der Einfluss von geplanten SW Änderungen wird bestimmt Code und auch die Spezifikation wird modifiziert, getestet und neue Versionen werden freigegeben Training und täglicher Support für Anwender wird geleistet 5

231 1. Grundlagen (3) Beteiligte SW Entwickler SW Designer Support Mitarbeiter 1-Level Support: Aufnahme und Klärung von Anwenderfragen 2-Level-Support: Experten 3-Level-Support: oft SW Entwickler Projektmanager 6

232 1. Grundlagen (4) Änderungsanforderungsprozess (Balzert, Lehrbuch der SW Technik, S.1097) 7

233 1. Grundlagen (5) Änderungsformular (Sommerville, SE, S ) 8

234 1. Grundlagen (6) Aufgaben des Wartungspersonals Beibehalten der Kontrolle über die gebräuchlichen Funktionen der SW Beibehalten der Kontrolle über SW Modifikationen Verbesserung von existierenden Funktionen Vorsorgen das die Leistungsdaten der SW nicht unakzeptabel werden Warum wird Wartung benötigt? Wartung stellt sicher, dass die SW immerzu den Anwenderwünschen entspricht SW ist evolutionär: Anforderungen können sich über die Zeit ändern 9

235 1. Grundlagen (7) Der Eisberg der SW- Wartung (Martin, J.; McClure, C.: Software maintenance: The problem and its solutions. Englewood Cliffs 1983, S.7) 10

236 1. Grundlagen (8) Kategorien der Wartung (ISO/IEC 14764) Korrigierende Wartung Reaktive Modifikation eines SW Produkts nach Auslieferung um beobachtete Probleme zu korrigieren Adaptive Wartung Modifikationen eines SW Produkts nach Auslieferung um SW in einer veränderten oder veränderlichen Umgebung am Leben zu erhalten Perfektive Wartung Modifikation eines SW Produkts nach Auslieferung um Leistungsfähigkeit oder Wartbarkeit zu verbessern Präventive Wartung Modifikation eines SW Produkts nach Auslieferung um latente Fehler zu entdecken und zu korrigieren bevor diese Fehler zu effektiven Fehlern heranwachsen 11

237 2. Wartungsprozess (1) Prozessmodell 12

238 2. Wartungsprozess (2) Wartungsspezifische Aktivitäten Transition Sequenz von Aktivitäten die kontrolliert und koordiniert zur Übergabe zwischen SW Entwickler und Wartungspersonal stattfindet Änderungsanforderungsmanagement Akzeptanz / Ablehnung Änderungsanforderungen mit größerem Umfang können zu Entwicklern weitergeleitet werden Betreibung von Help Desks Anwender-Support Trigger für die Bewertung, Priorisierung und Ausführung von Änderungsanforderungen Impact Analyse 13

239 2. Wartungsprozess (3) Wartungsspezifische Aktivitäten SW Support Hilfe und Rat für Anwender bezüglich Fragen Hilfe zur Erlangung von Sonderinformationen (z.b. ad-hoc Reports) Erstellung und Einhaltung von Service-Level-Agreements Vertragspunkte im Wartungsvertrag Enthalten sind die Verantwortlichkeitsbereiche des Wartungspersonals 14

240 3. Wartungstechniken (1) Re-Engineering Engineering (Neuer Entwurf von SW) Anforderungen Entwurf Code Re-Engineering Vorhandene Anforderungen Vorhandener Entwurf Vorhandener Code 15

241 3. Wartungstechniken (2) Re- Engineering Identifikation der Komponenten und deren Beziehungen (Teil-) Neuimplementierung von Legacy-Systemen Mögliche Ergebnisse Beschreibungen des Systems, Beschreibung der Architektur Transformation einer Repräsentation in eine andere Untersuchung und Änderung (Reverse Engineering) des Systems Nachqualifizierung vorhandener SW Häufige Aufgaben Plattformanpassungen Änderung der Programmiersprache neuer Standard, neue Sprache, neues Paradigma 16

242 3. Wartungstechniken (3) Re-Engineering Ablauf (Sommerville, SE, S.633) 17

243 3. Wartungstechniken (4) Re-Engineering Vorteile Verbesserung der Wartungseigenschaften eines SW Systems Alternative zur kosteneffektiven Weiterentwicklung eines Alt- Systems ökonomische Vorteile durch Einsatz bereits vorliegender, bewährter Produkte Zuverlässigkeitssteigerung der SW möglich Geringeres Risiko als bei Neuentwicklung Geringere Kosten im Vergleich mit Neuentwicklung Nachteile Neuentwicklung beinhaltet bessere, neuere Spezifikationen Strukturierung und Modularisierung ist bei Neuentwicklungen i.a. verbessert Neuentwicklung verwendet i.d.r. moderne Techniken 18

244 3. Wartungstechniken (5) Reverse Engineering (E. J. Byrne, A Conceptual Foundation for Software Re- Engineering, ICSM 1992, pp ) 19

Software Engineering (SE)

Software Engineering (SE) Software Engineering (SE) 3) Planungsphase Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand: 15.03.2014), Hochschule Augsburg,

Mehr

Software Engineering 4) Definitionsphase und Requirements Engineering

Software Engineering 4) Definitionsphase und Requirements Engineering Software Engineering 4) Definitionsphase und Requirements Engineering Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand:

Mehr

Software Engineering (SE)

Software Engineering (SE) Software Engineering (SE) 1) Einführung Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand: 15.03.2014), Hochschule Augsburg,

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Weiterführende Literatur

Weiterführende Literatur Literatur [Art.Metriken06] Artikel Messbare Qualität in Anforderungsdokumenten. Veröffentlicht in: Java Magazin 1/2006. Manage IT! 2/2006. ObjektSPEKTRUM 4/2006. [Bandler94] Richard Bandler (1994) Metasprache

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Klausurvorbereitung Software Engineering I @ TFH Berlin

Klausurvorbereitung Software Engineering I @ TFH Berlin Teil 1 Einführung in Software Engineering Definition: Was ist Software Engineering? Unter Software Engineering (SE) versteht man den systematischen, disziplinierten und in seiner Größe abschätzbaren Ansatz,

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

Softwarepraktikum. Gernot A. Fink SS 2005 Softwarepraktikum Gernot A. Fink SS 2005 Einführung Wichtige Grundbegriffe Was ist Softwareengineering? Software- und Projektentwicklung Anfordernugen and Softwareentwicklung Softwareprozesse und Vorgehensmodelle

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Agenda. Einführung und Motivation. Verteilte Objekte und Komponenten. Verteilte Softwarearchitekturen. J2EE-Plattform

Agenda. Einführung und Motivation. Verteilte Objekte und Komponenten. Verteilte Softwarearchitekturen. J2EE-Plattform Agenda Einführung und Motivation Verteilte Objekte und Komponenten Verteilte Softwarearchitekturen J2EE-Plattform J2EE-basierte Softwarearchitektur Aspekte der Verteilung von J2EE-Anwendungen 21 Ziele

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Software Engineering

Software Engineering Software Engineering Einführung in das Software Engineering Ein Tutorial von Wirtschaftsinformatik-24.de Inhaltsverzeichnis Einleitung 2 Ziele vom Software Engineering.2 Prinzipien, Methoden und Verfahren..3

Mehr

Anforderungen dokumentieren, validieren und verwalten

Anforderungen dokumentieren, validieren und verwalten Anforderungen dokumentieren, validieren und verwalten iks-thementag: Requirements Engineering 16.11.2010 Autoren Christoph Schmidt-Casdorff Carsten Schädel Agenda Einleitung Anforderungen dokumentieren

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

Mehr

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim Software- Der Strategien und ist der zum Definieren der Architektur, der Komponenten, der Schnittstellen und anderer Charakteristika (Datenstrukturen, Algorithmen etc.) eines Systems oder einer Komponente

Mehr

Semester: -- Workload: 300 h ECTS Punkte: 10

Semester: -- Workload: 300 h ECTS Punkte: 10 Modulbezeichnung: Modulnummer: BWIT IT Management Semester: -- Dauer: Minimaldauer 1 Semester Modultyp: Wahlpflicht Regulär angeboten im: WS, SS Workload: 300 h ECTS Punkte: 10 Zugangsvoraussetzungen:

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Freie Software Engineering Trainerin und Forscherin www.herrmann-ehrlich.de Übersicht 1. Motivation 2. Fragen 3. Durchführung 4. Ergebnisse

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Das V-Modell: Produkte 1/5

Das V-Modell: Produkte 1/5 Das : Produkte 1/5 Problem-Beschreibung, Lastenheft Beschreibung des Problems/der Probleme, das/die gelöst werden soll Quellen: Markt-Analyse, Marketing, Kunden-Zirkel etc. Kunden-Anforderungen, Pflichtenheft

Mehr

Softwaretechnik (Medieninformatik) Überblick

Softwaretechnik (Medieninformatik) Überblick Softwaretechnik (Medieninformatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 Überblick UML-Diagramme

Mehr

Requirements-Engineering und -Management

Requirements-Engineering und -Management Requirements-Engineering und -Management Chris Rupp, SOPHIST GROUP Professionelle, iterative Anforderungsanalyse für die Praxis ISBN 3-446-22877-2 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Softwaretechnik Prozessmodelle

Softwaretechnik Prozessmodelle Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things

Mehr

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Überblick Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution Evolutionsprozesse Techniken für Software-Evolution

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik login: pw: Prof. Dr.-Ing. habil Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik email: ilka.philippow@tu-ilmenau.de Tel. 69 2826 Sekr. 69 2870, Frau Meusel, Zuse Bau Zi

Mehr

Software Engineering Vorlesung für Medieninformatik

Software Engineering Vorlesung für Medieninformatik Software Engineering Vorlesung für Medieninformatik Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung

Mehr

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 2. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Anforderungen in Open Source Projekten Edna Rosen Institut für Informatik FU Berlin 06.07.2006. Anforderungen in Open Source Projekten 1

Anforderungen in Open Source Projekten Edna Rosen Institut für Informatik FU Berlin 06.07.2006. Anforderungen in Open Source Projekten 1 Anforderungen in Open Source Projekten Edna Rosen Institut für Informatik FU Berlin 06.07.2006 Anforderungen in Open Source Projekten 1 Inhalt Open Source Definition Der klassische SW-Prozess klassischer

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Grundlagen der Programm- und Systementwicklung

Grundlagen der Programm- und Systementwicklung Grundlagen der Programm- und Systementwicklung Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. Alexander Malkis,

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 3: Softwareplanung FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 2 Problem und Lösung Aufnehmen

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle)

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap 8.1 http://homepages.cs.ncl.ac.uk/brian.randell/nato/ The first International Conference

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Software Engineering. Risikomanagement in der Softwareentwicklung

Software Engineering. Risikomanagement in der Softwareentwicklung Software Engineering Risikomanagement in der Softwareentwicklung Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Übersicht Entwicklungsprozess Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall

Mehr

Software-Engineering und Optimierungsanwendungen in der Thermodynamik

Software-Engineering und Optimierungsanwendungen in der Thermodynamik Software-Engineering und Optimierungsanwendungen in der Thermodynamik Software-Engineering 4 Entwurfs-, Implementierungs- und Abnahmephase Prof. Dr. Rolf Dornberger OPTSWE_SWE: 4 Entwurfs-, Implementierungs-

Mehr

Softwaretechnik Überblick

Softwaretechnik Überblick Softwaretechnik Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6 Objektorientiertes Design

Mehr

Software Engineering

Software Engineering Software Engineering Informatik II. 10. Software-Entwicklung Konfigurations-Management Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Grundlagen der Anforderungsanalyse. 28. Oktober 2014

Grundlagen der Anforderungsanalyse. 28. Oktober 2014 Grundlagen der Anforderungsanalyse 28. Oktober 2014 Überblick Wie analysiert man die Anforderungen an ein neues Softwaresystem? Welche Methoden und Techniken gibt es? Welche Probleme kann es bei der Anforderungserfassung

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Erstellung eines Pflichtenhefts (I)

Erstellung eines Pflichtenhefts (I) 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Lehrplan: Projektmanagement

Lehrplan: Projektmanagement Lehrplan: Projektmanagement Tobias Brückmann Volker Gruhn Gliederung 1 Grundlagen der industriellen So?ware Entwicklung 2 Grundprinzipien und Aufgaben im Projektmanagement 3 Stakeholder- Management 4 Ziel-

Mehr