Zusammenfassung – Was ist Software-Engineering“ ? Software-Engineering ist - die effektive und effiziente Entwicklung und Weiterentwicklung komplexer.

Slides:



Advertisements
Ähnliche Präsentationen
Business Engineering Philipp Osl, Alexander Schmidt
Advertisements

1 Referenzmodelle für HISinOne Dr. Uwe Hübner, 02. Juli 2009.
V - Modell Anwendung auf große Projekte
Phasen und ihre Workflows
1 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand – Ergänzung FP Copyright: Dr. Klaus Röber Modul Ergänzungen zur.
Vorgehensmodell - Wasserfallmodell
Wissensanalyse von Aufgaben mit TKS Eine Methode zur Problemlösung
Rollenbasierter Entwurf am Beispiel eines benutzeradaptierbaren Hyperbooks Institut für Informatik Rechnergestützte Wissensverarbeitung Universität Hannover.
IT-Projektmanagement
WS 04/05 wiss. Übung: Systemanalyse und Softwaredesign
Manfred Thaller, Universität zu Köln Köln 28. Januar 2008
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Objektorientierter Entwurf (OOD) Teil 3: Qualitätsmodell
Risiken und Chancen Risiko Beurteilung: Dazu gehört die Identifikationen von Risiken, ihre Analyse und das Ordnen nach Prioritäten. Risiko Kontrolle: Dazu.
ISO - Normen Inhalt Qualität im SE Der ISO 9000-Ansatz
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
UML im Überblick – Dipl. Ing. Ulrich Borchert / FH Merseburg 1/22
Rational Unified Process (RUP) - Definitionen
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Software Engineering I m Vorlesung im Wintersemester 2010/11 m.
Die Bank von morgen - eine neue Welt für IT und Kunden? 23. Oktober 2001.
UML Begleitdokumentation des Projekts
Forschungszentrum Informatik, Karlsruhe Objektorientierte Systeme unter der Lupe Markus Bauer Oliver Ciupke.
Vorlesung Gestaltung von soziotechnischen Informationssystemen - RequirementsEngineering und Contextual Design- Thomas Herrmann, Lehrstuhl Informations-
Computer-Supported Cooperative Work (CSCW)
Spezifikation von Anforderungen
Software Engineering SS 2009
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Unified Modeling Language Repetition / Einführung zu UML
Service Design by EstherKnaus® Der Benchmark für Dienstleistungen
User-Centred Design Kosten und Gewinne des nutzerorientierten Gestaltungprozesses Irene Escudé Capdevila März 2012.
LVA , SS021 Im Mittelpunkt aller Bemühungen steht der Kunde und die Steigerung des Kundennutzens. Deswegen: Wer alles reinlässt kann nicht.
Verteidigung der Bachelor-Thesis Objektorientierte Geschäftsprozessmodellierung mit BPMN und UML Patrick Heydorn.
UML-Kurzüberblick Peter Brusten.
Engineering tools for the NEO engineer
Wasserfallmodell und Einzelbegriffe
Paradigmenwechsel in der Unternehmensmodellierung Prof. Dr. Wolfgang Voigt Dipl.-Ing. Päd. Alexander Huwaldt UML Extrakt UML Seminar, Chemnitz
Vom Geschäftsprozess zum Quellcode
Informatik und Programmieren 3
Daten- und Ablaufmodellierung
Rational Unified Process
Systematisches Requirements Engineering Anforderungen ermitteln, spezifizieren, analysieren und verwalten AM2 – Planung von Softwareprojekten Dozent:
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Kurze Rekapitulation aus der Einführungsvorlesung Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 20. Oktober 2011.
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Dieser Vortrag wird gesponsort von:
Modul Datenmodelle entwickeln
Programmiersprachen II Vorbesprechung Klausur Prof. Dr. Reiner Güttler Fachbereich GIS HTW.
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Entwurf Dr. Wolfgang Wörndl
Das Wiki System der Freien Universität Berlin. Vorstellungsrunde Bitte stellen Sie sich kurz vor! Wer sind Sie? Haben Sie Erfahrungen in der Nutzung.
© Till Hänisch, 2002 BA Heidenheim Methoden zur Aufwandsabschätzung Allgemein: –Reduktion der Komplexität –Vergleich mit Erfahrungswerten Probleme: –Erfassen.
Vorbereitung einer Anforderungsanalyse für ein GUI im Kreditkarten- Processing-Umfeld Yanik Dreiling MatrNr
A nwendungsfalldiagramm. Ü berblick  Allgemein  Anwendungsfalldiagramm in Stichpunkten  Zusammenhang  Anwendungsbereich  Diagramm.
Tagung „Softwareengineering – Anforderungsanalyse“ Prof. Dr.-Ing. Anna Sabine Hauptmann Hochschule für Technik und Wirtschaft Dresden,
Module und Modularisierung
Das Entwurfsmuster Model-View-Controller
Basiswissen Web-Business
[Name des Projektes] Post-Mortem
Systemanalyse BA Heidenheim 2002.
KEDOQ-Schmerz eine Initiative der Deutschen Schmerzgesellschaft zur Dokumentation und Qualitätssicherung in der spezialisierten Schmerztherapie Welche.
Datenakquisition in einem ‚Serious Game‘
Vorlesung Software Engineering I
Mögliche Stoffverteilung im Grundkurs
Anforderungsmanagement
Service-Design in SEPA
Practical Exercises and Theory
 Präsentation transkript:

Zusammenfassung – Was ist Software-Engineering“ ? Software-Engineering ist - die effektive und effiziente Entwicklung und Weiterentwicklung komplexer SW-Systeme - sowie begleitender Dokumente - in einem bewusst arbeitsteilig gestalteten Prozess -unter Anwendung bewährter Prinzipien, Methoden und Modellen. Warum haben Analyse und Definition von Anforderungen an das SW-System so große Bedeutung im Entwicklungsprozess? Auch heute werden noch die Hälfte aller SW-Projekte nicht wie geplant realisiert. 60% der Fehler resultieren aus Fehlern in der Analysephase. Die Behebung von Fehlern aus der Analysephase sind sehr teuer. 1

Was eigentlich sind Anforderungen? IEEE Std (1990) 2

Requirement (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documets. (3) A documented representation of a condition or capability as in (1) or (2). Requirement analysis (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements. IEEE Std (1990) 3 Was eigentlich sind Anforderungen? - 2 -

«A requirements is something that the product must do or a quality that the product must have.» Eine Anforderung ist (aus der Sicht des Nutzers) das, was das Produkt tun soll oder die Qualität, die es haben soll funktionale Anforderungen functional requirements nicht-funktionale Anforderungen non-functional requirements Robertson, Suzanne/ Robertson, James “Mastering the Requirements Process” – Seite 5f 4 Was eigentlich sind Anforderungen? - 3 -

Anforderungen funktionale Anforderungen nicht-funktionale Anforderungen QualitätsanforderungenRahmenbedingungen technisch/technologische Rahmenbedingungen rechtliche Rahmenbedingungen organisatorische Rahmenbedingungen 5 Was eigentlich sind Anforderungen? - 4 -

Anforderungen funktionale Anforderungen QualitätsanforderungenRahmenbedingungen technisch/technologische Rahmenbedingungen rechtliche Rahmenbedingungen organisatorische Rahmenbedingungen Nach: Pohl, Klaus „Requirements Engineering- Grundlagen, Prinzipien. Techniken“ ISBN Was eigentlich sind Anforderungen? - 5 -

Beispiele aus dem Kontext der HTW-Bibliothek: funktionale Anforderung: Eine Person meldet sich als Benutzer an. Qualitätsanforderungen: Das SW-System toleriert beim Anmelden mögliche Eingabefehler wie zum Beispiel die versehentliche Eingabe von Text bei der Datumsangabe. rechtliche Rahmenbedingungen: Für die Erfassung, Speicherung und Verarbeitung der Personendaten gilt die aktuelle Fassung des Datenschutzgesetzes. technisch/technologische Rahmenbedingungen: Die Daten werden in einer relationalen Datenbank gespeichert. Zum Einsatz kommt eine Oracle-Datenbank. organisatorische Rahmenbedingungen: Eine Person darf sich nur einmal als Benutzer anmelden. Worin bestehen die Risiken der Anforderungsanalyse? 7 Was eigentlich sind Anforderungen? - 6 -

SW-Qualität Funktionserfüllung Benutzbarkeit Wirtschaftlichkeit Zuverlässigkeit/Sicherheit Flexibilität Wiederverwendbarkeit Erweiterbarkeit/Änderbarkeit/Kompatibilität/Portabilität Welche Qualitätsmerkmale hat eine SW-System? 8

SW-Qualität Produkt-Qualität Qualität des SW-Produktes Prozeß-Qualität Qualität des SW-Entwicklungsprozesses, d.h. Qualität des Supportes während des Einsatzes Qualität der Teilprozesse: Analyse/Entwurf/Implementierung/ Test/Inbetriebnahme/Wartung integrierte Dokumentation  SW-Projektmanagement konstruktiveanalytische Qualitätssicherung organisatorisch Wie kann die Qualität erreicht werden?

Kosten SW-Qualität Zeit SW-Qualität erfordert Kosten und Zeit. Das will geachtet sein. 10 Wie kann die Qualität erreicht werden?-2 -

Analyse Entwurf Implementierung Test/Installation Einsatz und Wartung System-Entwicklung System-Nutzung „Eisberg-Effekt“: In der Entwicklung gesparte Kosten müssen um ein Vielfaches in der Wartung investiert werden. 11 Wie kann die Qualität erreicht werden?- 3 -

Abstraktion Strukturierung Zerlegung Standardisierung (integrierte) Dokumentation Hierarchisierung Kapselung 12 Welche Grundprinzipien stehen zur Verfügung?- 1 -

Booch, Grady „Objektorientierte Analyse und Design“ Addison Wesley, S. 62 Abstraktion 13 Welche Grundprinzipien stehen zur Verfügung?- 2 -

Gesamtes System Modell 1Kontextmodell Modell 2Funktionsmodell Modell 3Datenmodell Modell 4Datenflussmodell Modell 5Klassenmodell Modell 7… Untersuchungsziel / Perspektive /Abstraktion Kontext Funktionen Daten Datenflusss Klassen …… Modell 6Zustandsmodell Zustand 14 Welche Grundprinzipien stehen zur Verfügung?- 3 -

Booch, Grady „Objektorientierte Analyse und Design“ Addison Wesley, S. 84 Hierarchisierung 15 Welche Grundprinzipien stehen zur Verfügung?- 4 -

Booch, Grady „Objektorientierte Analyse und Design“ Addison Wesley, S. 77 Zerlegung Zusammen- setzung 16 Welche Grundprinzipien stehen zur Verfügung?- 5 -

Booch, Grady „Objektorientierte Analyse und Design“ Addison Wesley, S. 7 Kapselung 17 Welche Grundprinzipien stehen zur Verfügung?- 6 -

Booch, Grady „Objektorientierte Analyse und Design“ Addison Wesley, S. 103 Persistenz 18 Welche Grundprinzipien stehen zur Verfügung?- 7 -

Welche Rolle spielen Anforderungen des Kunden im Rahmen der Software-Entwicklung? Anforderungen sind Ausgangspunkt der Entwicklung. Daraus resultiert ihre große Bedeutung (sowohl inhaltlich als auch zeitlich). Die Anforderungen verbinden Kunden und Entwickler. Die Anforderungen sind das Maß der Dinge bei der Übergabe des Produktes. 19

Worin bestehen die Risiken der Anforderungsanalyse? Falsche Anforderungen werden ermittelt. Die Anforderungen werden unvollständige ermittelt. Ermittelte Anforderungen sind missverständlich formuliert. Ermittelte Anforderungen sind widersprüchlich. Die Prioritäten sind falsch gesetzt. Die Anforderungen sind umständlich/zu umfangreich beschrieben. Die Anforderungen sind nicht realisierbar. 20

Was kennzeichnet eine qualitativ gute Anforderungsanalyse? Korrektheit Vollständigkeit Eindeutigkeit Konsistenz Angemessenheit Minimalität Realisierbarkeit Nachprüfbarkeit 21

Wie kann den Risiken der Anforderungsanalyse begegnet werden? durch laufende Diskussion mit dem Kunden (auch mit den direkten Anwendern) durch bewusste Arbeit mit Prototypen Oberflächenprototyp experimenteller Prototyp evolutionärer Prototyp durch Wahl von geeigneten Beschreibungsstechniken grafische Modellierungstechniken (werkzeuggestützt ) Satzschablonen (nach Chris Rupp) 22 Wegwerfprototypen

Um das Wesen eines Systems (Prozesses,...) zu verstehen,  muss zuerst seine Grenze erforscht werden, d.h. sein Kontext und die Interaktion des Systems mit diesem Kontext muss erforscht werden. (vgl. Definition „System“) zur Erinnerung: Kontextmodell 23

Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext Eingabedaten Ausgabedaten besser: 24 Eingabedaten Ausgabedaten

Aber wer oder was gehört zum Kontext? „Die Entwicklung eines Systems bzw. Produkts hat das Ziel, die Bedürfnisse mehrerer Personen, Gruppen und Institutionen zu befriedigen, wobei die Bedürfnisse und Ansprüche sehr unterschiedlich, auch gegenläufig und widersprüchlich sein können. All diese Personen und Institutionen bezeichnen wir als Stakeholder.“ Requirements-Engineering und -Management Chris Rupp, SOPHIST GROUP Professionelle, iterative Anforderungsanalyse für die Praxis ISBN Leseprobe, S

Beispiel aus dem Kontext der HTW-Bibliothek: Stakeholder: Person Benutzer Bibliotheksleiter(in) (  Bibliothekar(in)) Bibliotheksmitarbeiter DV-Beauftragter der Bibliothek Träger der Bibliothek (z.B. HTW-Dresden) Partnerbibliotheken (für die Fernleihe) Dezernat für Finanzen der HTW Rechenzentrum der HTW (Bereitstellung der Hardware zur Datenspeicherung, Übergabe der Kennung für Studenten („s-nummer“), … Partnerbibliotheken, Bibliotheksverbund … Worin bestehen die Risiken der Anforderungsanalyse? 26

Voraussetzung: – fundierten Kenntnis der Ausgangssituation, – Probleme und Optimierungspotenziale der Ausgangssituation – Kenntnis der Stakeholder exakte Beschreibung der: – erhobenen Ziele, – Rahmenbedingungen – Systemgrenzen zum Beispiel durch eine kurze, schlagkräftige Metapher „Durch die software-gestützte Bibliotheksverwaltung sollen die Holzkästen mit den Karteikarten abgelöst werden. Nach Büchern kann jeder zu jeder Zeit an jedem Ort suchen. Jeder Nutzer kann in bestimmten Umfang Ausleihen selbständig verlängern.“ Ziele definieren 27

„Kapitel 5 - Stakeholder, Ziele und der Systemkontext Was muss ich sehr früh für eine Produkt-/Systementwicklung klären? Wie finde ich die Ziele und wie stimme ich sie mit allen relevanten Projektbeteiligten ab? Wie finde, kategorisiere und dokumentiere ich die Stakeholder? Was versteht man unter Stakeholder-Relationship-Management? Wie werden Ziele und Rahmenbedingungen erfasst und dokumentiert? Was ist unter dem Systembegriff zu verstehen? Wie grenze ich den Systemumfang vom Systemkontext ab?“ LeseprobeRequirements-Engineering und -Management Professionelle, iterative Anforderungsanalyse für die Praxis Chris Rupp, SOPHIST GROUP, Hanser Verlag ISBN

Welche Aktivitäten gehören zur Anforderungsanalyse? Anforderungen ermitteln („erheben“) Ermittlungstechniken Anforderungen dokumentieren Beschreibungstechniken Anforderungen validieren und verifizieren Verifikations-, Validierungstechniken Anforderungen verwalten Projektverwaltungswerkzeuge 29

Welche Ermittlungstechniken gibt es? 30 befragen (  Interview, Fragebogen, …) beobachten (  Videoaufzeichnung) Kreativitätstechniken Brainstorming (d.h. Dialog statt Diskussion) Perspektiven wechseln Simulationsmodell bauen (  Prototyp) Essenzbildung (Reduktion auf funktionale Anforderung) Nicht-Kommuniziertes zur Sprache bringen (Gefahr: nicht-kommunizierte Annahmen) Systemarchäologie als Ausgangspunkt (d.h. Dokumentation des Ist- Systems) …

Welche Dokumentationstechniken gibt es? 1.Text schreiben. Jeder kann den Text schreiben/lesen. Aber Text ist u.U. interpretierbar, mißverständlich.  Ergänzung durch grafische Darstellungen (mit Legende !), Bildschirmabzüge – screen shot, Skizzen, …. 31

Kommunikation zwischen Menschen.... Gedacht ist nicht zwingend gesagt ! Gesagt ist nicht zwingend gehört ! Gehört ist nicht zwingend verstanden !.... also auch zwischen Kunde und Entwickler 32

nach Prof. Alexander Schulz von Thun (von 1975 bis zur Pensionierung 2009 an der Universität Hamburg) u.a. „Miteinander reden“ Bd. 1-3 Die vier Aspekte einer Nachricht 33

Diese Baumaßnahme finanziert die Deutsche Kreditbank AG 34

Welche Dokumentationstechniken gibt es? 1.Text schreiben. Jeder kann den Text schreiben/lesen. Aber Text ist u.U. interpretierbar, mißverständlich.  Ergänzung durch grafische Darstellungen (mit Legende !), Bildschirmabzüge – screen shot, Skizzen, …. 2.Standardisierte Modelle bauen.  Modellierungssprache muss erlernt werden. (z.B. UML = Unified Modeling Language) 3.Satzschablonen benutzen.  verbindet Vorteile von 1 und 2 35

Tabellarische Beschreibung von essenziellen Funktionen essenzielle Funktion: kleinste, von anderen essenziellen Funktionen unabhängige Funktion wiederholbar, ohne dass eine andere ess. Fkt. ausgeführt werden muss hat einen Auslöser (Eingabedaten oder zeitliches Ereignis) hat eine, keine oder mehrere Reaktionen nach außen (Ausgabedaten) 36

Interaktion des Systems mit seinem Kontext (Beispiel Bibliothek) gewünschte Funktion Vor- bedingungen Eingabe- daten Ausgabe- daten Nach- bedingungen Invarianten Person als Benutzer anmelden vollständige Eingabeda- ten, noch nicht ange- meldet, Min- destalter Anmelde- daten Benutzer- ausweis ggf. Absage Benutzer- daten sind gespeichert Benutzer abmelden keine Aus- leih-/Mahn- vorgänge Abmelde- daten Entlastungs- schreiben ggf. Absage Benutzer- daten sind archiviert Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum … Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. 37

Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext gewünschte Funktion Vor- bedingungen Eingabe- daten Ausgabe- daten Nach- bedingungen Invarianten Person als Benutzer anmelden vollständige Eingabeda- ten, noch nicht ange- meldet, Min- destalter Anmelde- daten Benutzer- ausweis ggf. Absage Benutzer- daten sind gespeichert Benutzer abmelden keine Aus- leih-/Mahn- vorgänge Abmelde- daten Entlastungs- schreiben ggf. Absage Benutzer- daten sind archiviert Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum … Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. 38

Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext gewünschte Funktion Vor- bedingungen Eingabe- daten Ausgabe- daten Nach- bedingungen Invarianten Person als Benutzer anmelden vollständige Eingabeda- ten, noch nicht ange- meldet, Min- destalter Anmelde- daten Benutzer- ausweis ggf. Absage Benutzer- daten sind gespeichert Benutzer darf sich nur einmal anmelden, d.h. er hat nur eine Benutzer- nummer Benutzer abmelden keine Aus- leih-/Mahn- vorgänge Abmelde- daten Entlastungs- schreiben ggf. Absage Benutzer- daten sind archiviert Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum … Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. 39

Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext gewünschte Funktion Vor- bedingungen Eingabe- daten Ausgabe- daten Nach- bedingungen Invarianten Person als Benutzer anmelden vollständige Eingabeda- ten, noch nicht ange- meldet, Min- destalter Anmelde- daten Benutzer- ausweis ggf. Absage Benutzer- daten sind gespeichert Benutzer darf sich nur einmal anmelden, d.h. er hat nur eine Benutzer- nummer Benutzer abmelden keine Aus- leih-/Mahn- vorgänge Abmelde- daten Entlastungs- schreiben ggf. Absage Benutzer- daten sind archiviert Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum … Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. 40

Bau von Modellen  grafische Darstellungen  UML Laborübung 41 UML-Diagramme sind Strukturdiagramme: Sie besitzen Knoten und Kanten. (Syntax und Semantik) Sie haben eine Topologie. Für die Anforderungsmodellierung geeignete Diagramme: Anwendungsfalldiagramm Aktivitätsdiagramm (- - - > Datenflussdiagramm) Zustandsdiagramm Analyse-Klassendiagramm