Prozess-Modelle. Modelle. Einführung in UML

Größe: px
Ab Seite anzeigen:

Download "Prozess-Modelle. Modelle. Einführung in UML"

Transkript

1 Modelle Prozess-Modelle Wasserfallmodell V-Modell Prototypenmodell Evolutionäres/inkrementelles Modell Objektorientiertes Modell Nebenläufiges Modell Spiralmodell Einführung in UML Klassendiagramme Anwendungsfalldiagramme

2 Einführung Prozess-Modelle legen den organisatorischen Rahmen einer Software-Entwicklung fest Prozess-Modelle legen folgendes fest: Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte) Durchzuführende Aktivitäten Definition der Teilprodukte (einschließlich Layout und Inhalt) Fertigungskriterien (Wann ist ein Teilprodukt fertiggestellt) Notwendige Mitarbeiterqualifikation Einzuhaltende Standards, Richtlinien und Werkzeuge 2

3 Prozess-Modelle Wasserfallmodell V-Modell Prototypenmodell Evolutionäre/inkrementelle Modell Objektorientierte Modell Nebenläufige Modell Spiralmodell 3

4 Das Wasserfall-Modell (1) System- Anforderungen Software- Anforderungen Analyse Entwurf Codierung Testen Betrieb 4

5 Das Wasserfall-Modell (2) Jede Aktivität ist in der richtigen Reihenfolge und in voller Breite durchzuführen Am Ende jeder Aktivität steht ein fertiggestelltes Dokument (Dokumentengetriebenes Modell) Sequentielle Abfolge der Aktivitäten (Keine Überlappung von Aktivitäten) Iterationen sind nur zwischen zwei aufeinanderfolgenden Stufen erlaubt 5

6 Das Wasserfall-Modell: Bewertung Vorteile Einfach, verständlich Geringer Management-Aufwand Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf Nachteile Die Sequentialität und volle Breite der Entwicklungsschritte oft nicht sinnvoll Gefahr einer Überbewertung der Dokumentation Risiken werden zu wenig berücksichtigt Benutzerbeteiligung nur bei Anforderungen und im Betrieb Möglichkeit von Feedback kaum gegeben 6

7 Das V-Modell (1) Validierung Anforderungs- Definition Anwendungsszenarien Abnahmetest Grobentwurf Testfälle Systemtest Verifikation Feinentwurf Testfälle Integrationstest Modul- Implementation Testfälle Modultest 7

8 Das V-Modell (2) Erweiterung des Wasserfall-Modells Berücksichtigung der Qualitätssicherung Verifikation: Überprüfung der Übereinstimmung zwischen Software- Produkt und Spezifikation Validierung: Überprüfung der Eignung eines Produktes bezogen auf Einsatzzweck Submodelle im V-Modell: PM: Projektmanagement SE: Systemerstellung QS: Qualitätssicherung KM: Konfigurationsmanagement 8

9 Das V-Modell: Submodelle PM Projekt planen und kontrollieren Voraussetzungen schaffen und SEU bereitstellen Plandaten Istdaten SEU Istdaten QS- Anforderungen vorgeben SEU SE Produkt entwickeln SEU Konfigurationsstruktur Plandaten Plandaten Plandaten Istdaten Istdaten SEU Produktstruktur planen QS- Ergebnis Produkte prüfen QS-Anforderung Produkt Rechte Produkte/ Rechte verwalten QS Produkt KM 9

10 Das V-Modell: Rollen Submodell Manager Verantwortliche Durchführende PM Projektmanager Projektleiter Rechtsverantwortlicher Controller Projektadministrator SE Projektmanager IT-Beauftragter Anwender Projektleiter Systemanalytiker Systemdesigner SW-Entwickler HW-Entwickler Technischer Autor SEU-Betreuer Datenadministrator IT-Sicherheitsbeauftragter Datenschutzbeauftragter Systembetreuer QS Q-Manager QS-Verantwortlicher Prüfer KM KM-Manager KM-Verantwortlicher KM-Administrator 10

11 Das V-Modell: Bewertung Vorteile Integrierte, detaillierte Darstellung von SE, QS, KM und PM Generisches Vorgehensmodell mit definierten Möglichkeiten zur Anpassung an projektspezifischen Anforderungen Gut geeignet für große Projekte Nachteile Die Vorgehenskonzepte, die für große Projekte geeignet sind werden unreflektiert auf andere Projekte übertragen Für kleine und mittlere Softwareentwicklungen führt das V- Modell zu einer unnötigen Bürokratie Die im V-Modell definierten Rollen (bis zu 25) sind für gängige Softwareentwicklungen nicht realistisch Ohne geeignete Werkzeug-Unterstützung ist das V-Modell nicht handhabbar 11

12 Das Prototypen-Modell Probleme bei der Verwendung des Wasserfall- und V-Modells Auftraggeber und Endbenutzer können ihre Anforderungen an ein Software-Produkt oft nicht explizit und vollständig formulieren In der Entwicklungsphase ist ein Austausch zwischen Anwendern und Software-Entwicklern notwendig Für manche Anforderungen gibt es unterschiedliche Lösungen, die mit dem Auftraggeber diskutiert werden müssen Die Realisierbarkeit mancher Anforderungen kann theoretisch nicht garantiert werden und muss durch Experimente ermittelt werden Für die Projektakquisition muss der (potentielle) Auftraggeber von der Software-Lösung überzeugt werden Lösung: Prototypen-Modell Prototypen dienen dazu, relevante Anforderungen oder Entwicklungsprobleme zu klären Prototypen stellen Diskussionsbasis dar und helfen bei der Entscheidungsfindung Prototypen dienen dazu, Experimente durchzuführen und damit erste Erfahrungen mit der Anwendung zu sammeln 12

13 Das Prototypen-Modell Prototyping Unterstützt die frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Systems Dient zur Ermittlung der Realisierbarkeit von Anforderungen Arten von Prototypen Demonstrationsprototyp: Stellt ein mögliches Aussehen einer geplanten Software-Lösung dar Dient zur Auftragsakquisition (Wird i.a. nach Erfüllung der Aufgabe weggeworfen) Prototyp im engeren Sinne: Realisiert Teile der Funktionalität (z.b. Benutzerschnittstelle) Dient zur Analyse des Anwendungsbereichs Labormuster: Demonstriert technische Umsetzbarkeit der Anforderungen Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen Pilotsystem: Ist Kern des Produktes Wird in Zyklen zum Endprodukt weiterentwickelt 13

14 Das Prototypen-Modell: horizontale vs. Vertikale Prototypen Benutzeroberfläche Anwendung Horinzontale Prototypen Netzanbindung Datenhaltung Systemsoftware Vertikale Prototypen Horizontale Prototypen: Realisierung spezifischer Ebenen des Systems Vertikale Prototypen: Realisierung ausgewählter Teile des Zielsystems durch alle Ebenen hindurch 14

15 Vorteile Das Prototypen-Modell: Bewertung Reduzierung von Entwicklungsrisiken durch frühzeitige Verwendung von Prototypen Verbesserung der Planung von Software-Entwicklungen Starke Rückkopplung mit dem Endbenutzer bzw. Auftraggeber Förderung der Kreativität bei der Ermittlung von Alternativen für die Problemlösung Nachteile Aufwand für die Entwicklung von Prototypen Aufwand für Prototypentwicklung oft vertraglich schwer zu fassen Gefahr der Weiterverwendung von (Wegwerf-)Prototypen 15

16 Das evolutionäre Modell Nullversion X:=0 Definieren Version X X:=X+1 Änderungen Partielles Modell Änderungen Entwerfen Version X partielle Architektur Implement. Version X Produkt Version X Wünsche Einsetzen Version X 16

17 Das evolutionäre Modell Kern bzw. Mussanforderungen des Auftraggebers definieren Produktkern Produktkern wird als erstes entworfen und entwickelt (Nullversion) Erfahrungen mit Nullversion führen zu neuen Anforderungen aus denen eine neue Version entwickelt wird Merkmale des evolutionären Modells Stufenweise Entwicklung des Produkts, gesteuert durch Erfahrung von Endbenutzern Gut geeignet, wenn der Auftraggeber seine Anforderungen noch nicht vollständig überblickt Die Entwicklung im evolutionären Modell ist Codegetrieben: Der Fokus liegt jeweils auf lauffähigen Teilprodukten 17

18 Das evolutionäre Modell: Bewertung Vorteile Einsatzfähige Produkte in kurzen Zeitabständen Lässt sich mit dem Prototypen-Modell kombinieren Auswirkungen des Produkteinsatzes lassen sich untersuchen und die gewonnene Erfahrungen werden in der folgenden Version berücksichtigt Die Richtung der Entwicklung ist leichter steuerbar: statt einem Ergebnis gibt es mehrere Zwischenergebnisse Nachteile Falls in der Nullversion Kernanforderungen übersehen wurden muss die Systemarchitektur u.u. vollständig überarbeitet werden Die Nullversion kann sich als zu unflexibel für spätere Anpassungen erweisen 18

19 Das Inkrementelle Modell Variation des evolutionären Modells: Die Anforderungen werden zunächst vollständig erfasst Teile der Anforderungen werden inkrementell umgesetzt Definieren Ziel: Sicherstellen, dass inkrementelle Entwicklungen zu bisherigen Zwischenergebnissen passen Änderungen Vollständiges Produktmodell modifiz. Modell Definieren Änderungen If X=0 Nullversion X:=0 X:=X+1 Entwerfen Version X If X>0 Änderungen Änderungen partielle Architektur Implement. Version X Wünsche Produkt Version X Einsatz Version X 19

20 Definieren Kernsystem Das nebenläufige Modell partielles Modell Änderungen Definieren Ausbaustufe 1 Entwerfen Kernsystem partielle Architektur Änderungen erweitertes Modell Entwerfen Ausbaustufe 1 Änderungen Definieren Ausbaustufe 2 Erweitertes Produktmodell... Implement. Kernsystem Kernsystem erweiterte Architektur Implementieren Ausbaustufe 1 Änderungen Entwerfen Ausbaustufe 2 Erw. Produktarchitektur... erweitertes Kernsystem Implementieren Ausbaustufe 2 erweitertes Produkt... Produkt 20

21 Das Nebenläufiges Modell Parallelisierung des sequentiell organisierten Entwicklungsprozesses Förderung der Zusammenarbeit der einzelnen Personengruppen Dadurch Reduzierung unnötiger Korrekturen Erfahrungen der unterschiedlichen Personengruppen werden frühzeitig berücksichtigt Reduzierung von Wartezeiten und Zeitverzögerungen durch Parallelisierung Minimierung des Ausprobierens (Motto: right the first time : richtige Entscheidungen von Anfang an!) Reduzierung der Wartezeiten zwischen organisatorisch verbundenen Aktivitäten 21

22 Vorteile Das Nebenläufiges Modell: Bewertung Frühzeitige Erkennung und Lösung von Problemen Optimale Zeitausnutzung Nachteile Frühzeitige Entscheidungen können falsch sein Grundlegende und kritische Entscheidungen werden zu spät getroffen: Dadurch werden Iterationen notwendig Hoher Planungs- und Personalaufwand, um Fehler zu vermeiden bzw. zu antizipieren 22

23 Das Spiralmodell 23

24 Das Spiralmodell: Schritte (1) Schritt 1 Identifikation der Ziele des Teilprodukts (Leistung, Funktionalität,...) Ermittlung alternativer Realisierungsmöglichkeiten (Entwurf A, Entwurf B, Wiederverwendung, Kauf, etc.) Ermittlung der Randbedingungen für jede Alternative (Kosten, Zeit, Schnittstellen usw.) Schritt 2 Evaluierung der Alternativen unter Berücksichtigung der Ziele und Randbedingungen. Zeigt die Evaluierung, dass es Risiken gibt, dann ist eine kosteneffektive Strategie zu entwickeln, um die Risiken zu überwinden (Prototypen, Simulationen, Benutzerbefragungen, etc.) 24

25 Das Spiralmodell: Schritte (2) Schritt 3 In Abhängigkeit von den verbleibenden Risiken wird das Prozessmodell für diesen Schritt festgelegt (z.b. evolutionäres Modell, Prototypenmodell oder Wasserfallmodell) Kombination von verschiedenen Modellen ist möglich, wenn dadurch die Risiken minimiert werden Schritt 4 Planung des nächsten Zyklus einschließlich der benötigten Ressourcen Überprüfung (Review) der Schritte 1 bis 3 einschließlich der Planung für den nächsten Zyklus durch die betroffenen Personengruppen oder Organisationen. Einverständnis (Commitment) über den nächsten Zyklus herstellen 25

26 Meta-Modell Das Spiralmodell Risikogetriebenes Modell, oberstes Ziel: Risikominimierung Für jedes Teilprodukt und für jede Verfeinerungsebene sind die vier zyklischen Schritte zu durchlaufen Ziele eines Zyklus ergeben sich aus den Ergebnissen des letzten Zyklus Separate Spiralzyklen können für verschiedene Software- Komponenten durchgeführt werden Keine Trennung von Entwicklung und Wartung 26

27 Das Spiralmodell: Bewertung Vorteile Flexibles Modell Periodische, risikogetriebene Überprüfung und erneute Festlegung des Ablaufs Ein Prozessmodell wird nicht für die gesamte Entwicklung festgelegt, Integration anderer Prozessmodelle Fehler und ungeeignete Alternativen werden früh eliminiert Unterstützung der Wiederverwendung durch Betrachtung von Alternativen Nachteile Hoher Managementaufwand, da oft Entscheidungen über den Prozessablauf getroffen werden müssen Für kleine und mittlere Projekte ungeeignet Wissen über die Handhabung von Risiken nicht immer verfügbar 27

28 Zusammenfassung Prozess- Modell Primäres Ziel Antreibendes Moment Benutzerbeteiligung Charakteristika Wasserfall- Modell Dokumente gering sequentiell, volle Breite V-Modell minimaler Managementaufwand Prototypen- Modell maximale Qualität (safe-to-market) Dokumente gering sequentiell, volle Breite, Validation, Verifikation Risikominimierung Code hoch nur Teilsysteme Evolutionäres- Modell Inkrementelles Modell Nebenläufiges Modell minimale Entwicklungszeit (fast-to-market) minimale Entwicklungszeit Risikomimimierung minimale Entwicklungszeit Code mittel nur Kernsystem Code mittel volle Definition, dann zunächst nur Kernsystem Zeit hoch volle Breite, nebenläufig Spiralmodell Risikominimierung Risiko mittel Entscheidung pro Zyklus über weiteres Vorgehen 28

29 Einführung in UML UML (Unified Modeling Language) ist eine standardisierte Sprache und Notation zur Darstellung, Konstruktion, Dokumentation und Spezifikation von (objektorientierten) Modellen UML verwendet verschiedene Diagrammtypen zur Darstellung unterschiedlicher Aspekte eines Systems Statische Aspekte Dynamische Aspekte Benutzeranforderungen an das System Implementierungsbezogene Aspekte 29

30 Diagrammtypen in UML Modellierung der statischen Aspekte Klassen- und Objektdiagramme: Darstellung von Klassen, Objekten und deren statischen Beziehungen Modellierung der dynamischen Aspekte Verhaltensdiagramme: Beschreiben das Verhalten von Objekten des Systems Sequenzdiagramme: Darstellung von Nachrichtenfolgen zwischen Objekten einer oder mehrerer Klassen Kollaborationsdiagramme: Beschreiben das Zusammenwirken von Objekten beim Ausführen von Operationen Zustandsdiagramme: Darstellung der Zustände und Zustandsübergänge der Objekte einer Klasse Modellierung der funktionalen Anforderungen an das System Anwendungsfalldiagramme: Darstellung der Interaktionen zwischen externen Objekten (Akteuren) und dem System Modellierung implementierungsbezogener Aspekte (Komponentendiagramme, Einsatzdiagramme) 30

31 Klassendiagramme Klassenname Attributname: Typ Attributname: Typ=Initialwert [+ - #]Attributname: Typ=Initialwert Klassenattributname: Typ=Initialwert Operationsname Operationsname: Rückgabetyp Operationsname (Parameter: Typ): Rückgabetyp [+ - #] Operationsname (Parameter: Typ): Rückgabetyp Klassenoperation (Parameter: Typ): Rückgabetyp Klassenname Attribute Methoden Sichtbarkeit +: public #: protected -: private 31

32 Klassendiagramme: Beispiele (1) Klassen werden durch Rechtecke dargestellt Klassenname muss eindeutig sein Person Kunde Firma GeomObjekt Position_x : int Position_y : int verschieben(int, int) 32

33 Klassendiagramme: Beispiel Klassensymbol GeomObjekt Position_x : int Position_y : int verschieben(int, int) Java-Umsetzung public class GeomObjekt { int Position_x; int Position_y; public void verschieben (int dx, int dy) { Position_x = Position_x +dx; Position_y = Position_y +dy; } } Objektsymbol MeinGeomObjekt:GeomObjekt Position_x : 0 Position_y : 0 33

34 Klassendiagramme: Beziehungen Assoziation: Darstellung struktureller Beziehungen Aggregation: Darstellung hierarchischer Beziehungen Generalisierung und Spezialisierung 34

35 Klassendiagramme: Assoziationen Strukturelle Beziehungen zwischen Klassen werden durch Assoziationen dargestellt Binäre, n-äre und reflexive Assoziationen sind möglich Zusatzinformationen bei Assoziationen: Name der Assoziation: Beschreibt Art der Beziehung (Optional kann die Leserichtung angegeben werden) Rollen in der Assoziation: Beschreiben die Rollen der an der Assoziation beteiligten Klassen Kardinalität der Assoziation: Gibt an, mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert sein kann Klasse 1 Klasse 1 Klasse 1 Klasse 1 Klasse 1 Klasse 1 Binäre Assoziation Reflexive Assoziation n-äre Assoziation (n=3) 35

36 Klassendiagramme: Assoziationen Mitarbeiter Name Adresse... Leserichtung * beschäftigt 1 Unternehmen Name Adresse... Katja: Person verheiratet mit Bernd: Person Rollenname Person Arbeitsnehmer Arbeitsgeber Unternehmen 36

37 Klassendiagramme: Aggregation Sonderform der Assoziation Dient zur Darstellung von Teil-ganzes-Beziehungen Unternehmen besteht aus Abteilung besteht aus Mitarbeiter 1 1..* 1 1..* Team besteht aus Teammitglied 1 1..n 37

38 Klassendiagramme: Generalisierung und Spezialisierung (1) Bei der Generalisierung und Spezialisierung werden Eigenschaften hierarchisch gegliedert, d.h allgemeine Eigenschaften werden Oberklassen und speziellere Eigenschaften Unterklassen zugeordnet Unterklassen verfügen über ihre speziellen Eigenschaften und erben die Eigenschaften ihrer Oberklassen Oberklasse Geschäftspartner Unterklase Kunde Lieferant 38

39 Klassendiagramme: Generalisierung und Spezialisierung (2) GeomObjekt Position_x : int Position_y : int Sichtbar: Boolean Anzeigen() verschieben(int, int): void Radius: int Kreis SetRadius(int) a : int b : int seta(neua) setb(neub) Rechteck a : int b : int C: int seta(neua) setb(neub) setc(neuc) Dreieck 39

40 Anwendungsfalldiagramme (1) Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungsfällen und stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar Anwendungsfälle beschreiben das für den Benutzer sichtbare Systemverhalten wie Akteure mit dem System interagieren Akteure repräsentieren Rollen (Konkrete Benutzer können gleichzeitig mehrere Rollen spielen) 40

41 UML-Notation Anwendungsfalldiagramme (2) Name Anwendungsfall Name oder <<actor>> Name Akteur <<actor>> Name Name Beziehung zwischen Anwendungsfall und Akteur: Der Akteur führt den Anwendungsfall aus. 41

42 Anwendungsfalldiagramme: Beispiel Auftrag annehmen <<actor>> Lieferant Auftrag ausliefern Bestellung tätigen <<actor>> Kunde Systemgrenze Auftrag abbrechen Lieferung akzeptieren 42

43 Literatur Balzert, H.: Lehrbuch der Software-Technik; Spektrum, Akad. Verl.; Heidelberg, 1996 Kahlbrandt, B.: Software-Engineering mit der Unified Modeling Language; Springer Verlag,

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

Software Entwicklung 2. Prozessmodelle

Software Entwicklung 2. Prozessmodelle Software Entwicklung 2 Prozessmodelle Inhalt Das Wasserfall-Modell Das V-Modell Das Prototypen-Modell Das evolutionäre/inkrementelle Modell Das nebenläufige Modell Überblick über die Prozessmodelle 2 Lernziele

Mehr

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering 1 Grundlagen Software Engineering Prozesse GSE: Prof. Dr. Liggesmeyer, 1 Organisation: Prozessmodelle Inhalt Das Wasserfall-Modell Das V-Modell Das evolutionäre/inkrementelle Modell Das nebenläufige Modell

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

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

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

4. Organisation: Prozess-Modelle

4. Organisation: Prozess-Modelle Software Management 4. Organisation: Prozess-Modelle 1 Übersicht der Vorlesung 1. 2. 3. 4. 5. 6. 7. 8. Grundlagen Planung Organisation: Gestaltung Organisation: Prozess-Modelle Personal Leitung Innovationsmanagement

Mehr

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,

Mehr

Klassendiagramm. (class diagram)

Klassendiagramm. (class diagram) : Klassendiagramm http:///topic95.html Klassendiagramm (class diagram) Klassendiagramm Objektdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Einstieg Paketdiagramm Aufbau

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

Ü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

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

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny 3. UML Klassendiagramm Nachtrag 3.1 Einführung UML UML ist eine standardisierte Sprache zur Modellierung von Systemen. In UML werden graphische

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

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung

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

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

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

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

Ü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

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

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

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

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

Ü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

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

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr - PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

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

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

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

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Dr. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2010 Allgemeine Bemerkungen Jedes Blatt ist mit

Mehr

Techniken der Projektentwicklungen

Techniken der Projektentwicklungen Von der Analyse zum Entwurf 5. Termin Vom Use Case zum Domänenmodell Bis zum nächsten Mal Vom Use Case zum Domänenmodell Vom Use Case zum Domänenmodell Was ist ein Domänenmodell? Graphische Beschreibung

Mehr

Software- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell

Software- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell 1. Vorgehensmodelle Software- Entwicklungsaktivitäten und Vorgehensmodelle a) Lebenszyklusmodell (Life- Cycle- Modell) b) V- Modell c) Wasserfallmodell d) Modifiziertes Wasserfallmodell e) Iterative Modelle

Mehr

Änderungsmanagement bei iterativer SW-Entwicklung

Änderungsmanagement bei iterativer SW-Entwicklung Änderungsmanagement bei iterativer SW-Entwicklung Vortrag auf der regionalen Fachgruppe IT-Projektmanagement, 05.05.2006, Stuttgart Dr. Karsten Hoffmann, Steinbeis-Transferzentrum IT-Projektmanagement,

Mehr

Vorlesung Softwaretechnik - Vorgehensmodelle, V-Modell XT -

Vorlesung Softwaretechnik - Vorgehensmodelle, V-Modell XT - Vorlesung Softwaretechnik - Vorgehensmodelle, V-Modell XT - Prof. Dr.-Ing. Klaus-Peter Fähnrich WS 2007/2008 Prof. K.-P.Fähnrich 1 Übersicht Vorgehensmodelle Allgemein Vorgehensmodelltypen Das V-Modell

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

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

Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung

Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung Prof. Dr. Dr. h.c. M. Broy Klausurlösung Dr. H. Ehler, S. Wagner 2. Juli 2004 Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung Aufgabe 1 Prozessmodelle (4

Mehr

SWE5 Übungen zu Software-Engineering

SWE5 Übungen zu Software-Engineering 1 Übungen zu Software-Engineering 1) Klassen und Objekte 2) Telefonanlage 3) Objekt- und Klassendiagramme 4) Assoziationen 5) Telefonanlage (Erweiterung) 6) Fahrzeuge 7) Familien 2 Aufgabe 1: Klassen und

Mehr

Projektplan(ung) zu CYOUTOO

Projektplan(ung) zu CYOUTOO Seite 1 von 8 Projektplan(ung) zu CYOUTOO Inhalt Allgemeines 2 Die Meilensteine 3 Geplante Meilensteine des Projekts 3 Projektziel 1 4 Zielerläuterung 4 Meilensteine zu Projektziel 1. 4 Ergebnis 4 Projektziel

Mehr

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. K.-P. Fähnrich, Prof. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2012 Allgemeine Bemerkungen

Mehr

Zusammenfassung der Vorlesung

Zusammenfassung der Vorlesung Zusammenfassung der Vorlesung Die wichtigsten Punkte der Vorlesung waren... Dr. F. Sarre Wintersemester Wintersemester 20102013 / 2011 / 2014 Folie 307 Herausforderungen beim Projektmanagement Projektziel

Mehr

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan

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

Informationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:

Informationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen: Informationssystemanalyse Lebenszyklusmodelle 3 1 Aufgaben von Lebenszyklusmodellen Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen: Definition der Tätigkeiten im Entwicklungsprojekt Zusicherung

Mehr

Klausur Software Engineering für WI (EuI)

Klausur Software Engineering für WI (EuI) Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):

Mehr

GPP Projekte gemeinsam zum Erfolg führen

GPP Projekte gemeinsam zum Erfolg führen GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung. * * * Aufbau 1..

a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung. * * * Aufbau 1.. Software Engineering I Musterlösungen zur Klausur vom 3.7.2004 Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. zeigt eine mögliche Lösung. Turnier sportart

Mehr

3.2,,Eichung von Function Points (Berichtigte Angabe)

3.2,,Eichung von Function Points (Berichtigte Angabe) I N S T I T U T E F O R R E A L - T I M E C O M P U T E R S Y S T E M S TECHNISCHE UNIVERSIT ÄT MÜNCHEN P R O F E S S O R G. F Ä R B E R Software Engineering 3. Übung 22.05.2003 3.2,,Eichung von Function

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Motivation des Risikomanagements Ungefähr 80 Prozent

Mehr

Software Engineering I

Software Engineering I Vorlesung Software Engineering I Dynamische Basiskonzepte 2 Kontrollstrukturen Aktivitätsdiagramme Sequenzdiagramme 1 Basiskonzepte Beschreiben die feste Struktur des Systems, die sich während der Laufzeit

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 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

Seite 1. Grundlagen Software Engineering. Organisation: Prozessmodelle. Prozessmodelle. Organisation. Inhalt

Seite 1. Grundlagen Software Engineering. Organisation: Prozessmodelle. Prozessmodelle. Organisation. Inhalt Grundlagen Software Engineering Prozesse GSE: Kritische Faktoren in der Softwareentwicklung Procedures and methods defining the relationship of tasks B A D C PROCESS People with skills, training, and Tools

Mehr

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7 Java Einführung Umsetzung von Beziehungen zwischen Klassen Kapitel 7 Inhalt Wiederholung: Klassendiagramm in UML Java-Umsetzung von Generalisierung Komposition Assoziationen 2 Das Klassendiagramm Zweck

Mehr

<thema> Projektdokumentation zum Softwareentwicklungsprojekt. (Entwicklerdokumentation) 28. Mai 2015

<thema> Projektdokumentation zum Softwareentwicklungsprojekt. (Entwicklerdokumentation) 28. Mai 2015 Projektdokumentation zum Softwareentwicklungsprojekt (Entwicklerdokumentation) Lehrveranstaltung Software Engineering I / II 28. Mai 2015 Entwickler: , , Auftraggeber:

Mehr

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] 1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl

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

Neues Modul für individuelle Anlagen. Änderung bei den Postleitzahl-Mutationen

Neues Modul für individuelle Anlagen. Änderung bei den Postleitzahl-Mutationen NEWSLETTER APRIL 2015 Neues Modul für individuelle Anlagen Die LESS Informatik hat in Zusammenarbeit mit einem Kunden die Umsetzung des neuen Moduls 1e für die Anwendung von individuelle Anlagen in Angriff

Mehr

Robot Karol für Delphi

Robot Karol für Delphi Robot Karol für Delphi Reinhard Nitzsche, OSZ Handel I Version 0.1 vom 24. Januar 2003 Zusammenfassung Nach der Einführung in die (variablenfreie) Programmierung mit Robot Karol von Freiberger und Krško

Mehr

6. Programmentwicklung

6. Programmentwicklung 6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen

Mehr

SEP 114. Design by Contract

SEP 114. Design by Contract Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit

Mehr

Modul 07-203-2102. Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement

Modul 07-203-2102. Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Modul 07-203-2102 Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Fähnrich, Prof. Gräbe, Dr. Riechert Institut für Informatik Sommersemester 2013 Allgemeine Bemerkungen

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

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008

Traceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008 Traceability-Modell als Erfolgsfaktor für Process Enactment Einführung Referent Paul-Roux Wentzel Unternehmen method park Software AG 2008 method park Software AG Slide 2 Leistungsportfolio Training &

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

Requirements Engineering I. Der Spezifikationsprozess!

Requirements Engineering I. Der Spezifikationsprozess! Norbert Seyff Requirements Engineering I Zusammenfassung und Erweiterung Der Spezifikationsprozess! 2009, 2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den

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

4. AuD Tafelübung T-C3

4. AuD Tafelübung T-C3 4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {

Mehr

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 -

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule

Mehr

Prüfung Software Engineering I (IB)

Prüfung Software Engineering I (IB) Hochschule für angewandte Wissenschaften München Fakultät für Informatik und Mathematik Studiengruppe IB 3 A Wintersemester 2014/15 Prüfung Software Engineering I (IB) Datum : 21.01.2015, 14:30 Uhr Bearbeitungszeit

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Softwareentwicklungsprozess im Praktikum. 23. April 2015 Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit

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

Use Cases. Die Sicht des Nutzers. Fortgeschrittenenpraktikum SS 2004

Use Cases. Die Sicht des Nutzers. Fortgeschrittenenpraktikum SS 2004 Use Cases Die Sicht des Nutzers Fortgeschrittenenpraktikum SS 2004 Gunar Fiedler Lehrstuhl für Technologie der Informationssysteme Kontakt: fiedler@is.informatik.uni-kiel.de Use Cases 2 Was ist ein Use

Mehr

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

Mehr

Software Systems Engineering

Software Systems Engineering Software : SoSe 08 Prof. Dr. Klaus Schmid Software Produktlinien Ein neues Programm soll erstellt werden. Das habe ich doch schon mal programmiert, oder? Alter Code passt aber nicht ganz! Wird passend

Mehr

2. Tutorium zu Softwaretechnik I

2. Tutorium zu Softwaretechnik I 2. Tutorium zu Softwaretechnik I Lastenheft, Durchführbarkeitsuntersuchung und Klassendiagramme Michael Hoff 06.05.2014 INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION KIT Universität des Landes

Mehr

Software Maintenance - Musterlösung zum Übungsblatt 1

Software Maintenance - Musterlösung zum Übungsblatt 1 Software Maintenance - Musterlösung zum Übungsblatt 1 Beispiel 1) Kosten für 12 Monate: Kosten altes Produkt: 1000 * 12 = 12000 Kosten Neuentwicklung: 1000 Wartung des alten Produktes während der Entwicklung

Mehr

IKP Uni Bonn Medienpraxis EDV II Internet Projekt

IKP Uni Bonn Medienpraxis EDV II Internet Projekt IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung

Mehr

Whitebox-Tests: Allgemeines

Whitebox-Tests: Allgemeines -Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

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