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. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

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 WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

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

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

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

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

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

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

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

- 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

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

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

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

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

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

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

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

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

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

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken

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

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

Ü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

Was versteht man unter einem Softwareentwicklungsmodell?

Was versteht man unter einem Softwareentwicklungsmodell? Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen

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

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen

Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen White Paper Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen Die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen

Mehr

Übung Einführung in die Softwaretechnik

Übung Einführung in die Softwaretechnik Lehrstuhl für Informatik 3 RWTH Aachen Übung Einführung in die Softwaretechnik Lösungshinweise zum Übungsblatt 3 Aufgabe 6a) Welche Projekttypen gibt es, und wie ist deren Zusammenhang? Systementwicklung

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

Kundenanforderungen dokumentieren

Kundenanforderungen dokumentieren Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden

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

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

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

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

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

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

Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering

Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering Helmut Balzert Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering 3. Auflage Unter Mitwirkung von Heide Balzert Rainer Koschke Uwe Lämmel Peter Liggesmeyer Jochen Quante Spektrum

Mehr

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik

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

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

Mehr

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

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. Maria Spichkova

Mehr

Software Engineering. 3. Analyse und Anforderungsmanagement

Software Engineering. 3. Analyse und Anforderungsmanagement Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz

Mehr

PROJEKTMANAGEMENT GRUNDLAGEN_2

PROJEKTMANAGEMENT GRUNDLAGEN_2 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Softwaretechnik Dipl. Ing. Gerhard Strubbe IBM Deutschland GmbH Executive Project Manager (IBM), PMP (PMI) gerhard.strubbe@de.ibm.com

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

Softwaretechnik (Allgemeine Informatik) Überblick

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

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

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

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

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

Vorlesung Programmieren

Vorlesung Programmieren 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

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

Softwaretechnik (Allgemeine Informatik) Überblick

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

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

Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Prof. Dr. R. Dumke. Prüfungsklausur Softwaretechnik I. Bewertung

Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Prof. Dr. R. Dumke. Prüfungsklausur Softwaretechnik I. Bewertung Otto-von-Guericke Universität Magdeburg Fakultät für Informatik Prof. Dr. R. Dumke Prüfungsklausur Softwaretechnik I A Bewertung Aufgabe 1 (2 Punkte): Für die phasenbezogene Software-Entwicklung (Problemdefinition

Mehr

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

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

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Weiteren Verlauf der Vorlesung 31.10.2011(2 Std) OO Vorgehensmodelle, UML, Teamarbeit, Gruppenbildung,. 07.11.2011(2,5Std) Projektvorstellung, Planungsphase 14.11.2011(2 Std) Angebotspräsentation,

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

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Entwicklungsmethoden

Entwicklungsmethoden Slide 3.1 Entwicklungsmethoden Prof. Dr. Josef M. Joller jjoller@hsr.ch Development Methodologies Prof. Dr. Josef M. Joller 1 Session 3 Slide 3.2 SOFTWARE LIFE-CYCLE MODELLE Development Methodologies Prof.

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

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

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

Software Engineering und Projektmanagement

Software Engineering und Projektmanagement Software Engineering und Projektmanagement Motivation! Fachliche Sicht trifft auf technische Realisierung Entwurf 2009W - 5. November 2009 Andreas Mauczka Email: andreas.mauczka@inso.tuwien.ac.at Web:

Mehr

Kapitel 5: Das Design

Kapitel 5: Das Design Nach der Analyse kommt... Kapitel 5: Das Design SoPra 2008 Kap. 5: Das Design (1/20) Kapitel 5.1: Überblick Was ist Design? Ergebnis der Analyse: abstrakte Definitionen Objektmodell: Klassen, Assoziationen,

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE43 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML FH Wedel Prof. Dr. Sebastian Iwanowski

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering Winter '12/'13

Mehr

Gliederung des Vortrages

Gliederung des Vortrages Gliederung des Vortrages Unified Modeling Language Rational Rose Sergej Schwenk Oktober 1999 0. Einführung 1. Historie 2. Der Entwicklungsprozeß 3. UML 3.1 Anwendungsfalldiagramme 3.2 Klassendiagramme

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

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

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

Mehr

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE)

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Gliederung 1 Grundlagen der industriellen So@ware Entwicklung 2 Unternehmens- und Geschä@sprozessmodellierung 3 Grundlagen und Begriffe des

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

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

Agile Software Entwicklung. Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski

Agile Software Entwicklung. Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski Agile Software Entwicklung Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski Agenda zum Kurs Software Engineering Wasserfallmodell Agile Entwicklung Wer bin ich Studium der Computerlinguistik

Mehr

(BABOK-v3-Technik 10.41)

(BABOK-v3-Technik 10.41) (BABOK-v3-Technik 10.41) Allgemeines Scope-Modelling gibt Antworten auf die Fragen Was gehört zum System und was nicht? sowie Woher kommen die Anforderungen? Diese Fragen sollten generell zu Beginn jeder

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

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. 5) SW Design. Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik. Studiengang WiBac 4 (Stand: 15.03.

Software Engineering. 5) SW Design. Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik. Studiengang WiBac 4 (Stand: 15.03. Software Engineering 5) SW Design 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-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

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

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

Eine Tour durch das V-Modell 200x

Eine Tour durch das V-Modell 200x Eine Tour durch das V-Modell 200x WEIT Weiterentwicklung des Entwicklungsstandards für IT- Systeme des Bundes auf Basis des V-Modell-97 Stand der Arbeiten Workshop Softwareprozesse in Luft- und Raumfahrtprojekten

Mehr

Inhaltsverzeichnis. Vorwort...XIII. Aufbau des Buches...

Inhaltsverzeichnis. Vorwort...XIII. Aufbau des Buches... Inhaltsverzeichnis Vorwort...XIII Aufbau des Buches............................................... XV 1 Von der Idee zur Software..................................... 1 1.1 Beispielanwendung... 1 1.2 Schritte

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe

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