Objektorientiertes Software-Engineering

Größe: px
Ab Seite anzeigen:

Download "Objektorientiertes Software-Engineering"

Transkript

1 Objektorientiertes Software-Engineering Vorlesung I Inhalt der 1. Vorlesung (SE-Prozess) Strukturierte Analyse / Strukturiertes Design () Datenorientierte Software-Entwicklung () Prozesse für Objektorientierte Softwareentwicklung Rational Unified Process (RUP) Extreme Programming (XP) Weitere Vorgehensmodelle Anhang:, Grundlage und weiterführend Folie 2

2 Folie 3 Themen e Objektorientierte Software-Entwicklung UML Design Patterns Basisliteratur siehe abschnitt Technisches 12 Vorlesungen à 3 Stunden ( bis ) zusätzlich: 1 Stunde Übung - freie Termine Termin: Freitags 13:30-16:00 Uhr ACHTUNG: Zusatztermin am Uhr Tiefenhörsaal, Jägerstr. 56/58 Testat - Prüfung im vorletzten Vorlesungstermin Referent: DaimlerChrysler AG EP/QIM Tel. (07031) oder (0711) Was ist ein? Folie 4 Zergliederung der Entwicklungstätigkeit in Teilprozesse und Aktivitäten I Aktivitäten haben definierte Eingangsvoraussetzungen: R eingetretene Ereignisse, Dokumente, Zeitpunkte Aktivitäten haben definierte Ergebnisse: Dokumente, Meilensteine, Auslöser für andere Aktivitäten Rollen sind Definitionen von Verantwortlichkeiten, Kompetenzen und erforderlichen Fähigkeiten (Beispiel: Architekt). Personen werden Rollen zugeordnet Zu Aktivitäten sind Rollen zugeordnet A O

3 Elemente von en Klassische Schritte der Software-Entwicklung Analyse Design Implementierung Weiterer Umfang im Rahmen des Software Life Cycle Dokumentation Test Wartung Anfangs nicht erwähnt wurden Erfahrung sammeln Design- und Implementierungsanalyse Projektmanagement Folie 5 Fortschritt in Softwareentwicklungsprozessen Paradigmenwechsel Software-Entwicklung in einem iterativen und inkrementellen Prozess Phasen nicht mehr streng getrennt, sondern fließen ineinander über Konzept des Roundtrip Engineering Fokus weg von Anwendungen und Anwendungsorganisation hin zur Datenmodellierung und Umgang mit Daten Ursache ist die unterschiedliche Lebensdauer der Hard- und Systemware 2 bis 4 Jahre Anwendungen 3 bis 6 Jahre Modelle 1 bis 30 Jahre (nach [Hel94, S. 180]) Folie 6

4 Wozu Softwareentwicklungsprozesse? Wozu Modelle? Ein Modell soll Fragen zu einem System beantworten können,ohne mit dem System selbst arbeiten zu müssen. Ein gutes Modell beantwortet eben diese Fragen Folie 7 Warum? Qualität von Software ist entscheidend abhängig von der Qualität und Produktivität des zugrunde liegenden Software- Entwicklungsprozesses! Qualität des es DIN EN ISO 9000 Teil 3 : Geschichte der Abstraktion Folie 8 von Spannungen und Strömen: die Programmiersprache von Befehl und Datum: die von-neumann-maschine von einzelnen Bits: Oktal- und Hexadezimalcode von Befehlscodes: Operatorsymbole von Speicheradressen: Bezeichner von Maschinenoperationen: Ausdrücke von Berechnungsvorschriften und Daten: Funktionen von Befehlssequenzen: Prozeduren von speziellen Operationen: Funktions-/Prozedur- Parameter von verschiedenen Merkmalen: Generische Einheiten von der Datenimplementierung: Kapselung von einer Typimplementierung: Abstrakte Datentypen (ADT) von ähnlichen Operationen: Overloading von ähnlichen Typen: Vererbung

5 Strukturierte Analyse / Strukturiertes Design (1) Ursache: Softwarekrise Ende der 1960er / Anfang 1970er Jahre. Die Software hielt mit steigenden Leistungsmerkmalen der Hardware nicht mehr mit wurde mit höheren Anforderungen und Erweiterungen komplexer, fehleranfälliger und unüberschaubarer wurde immer teurer, aufgrund des hohen manuellen Programmieraufwands (niedriger Automatisierungsgrad - keine Software Reuseability) Ziel: Weg von der unkoordinierten unstrukturierten Programmentwicklung hin zum Software Engineering [KKST79] Folie 9 Strukturierte Analyse / Strukturiertes Design (2) Entwicklung der Strukturierten Analyse (SA) und des Strukturierten Design (SD), zusammengefasst Hauptmerkmale Modulares Programmieren Prozedurale Programmierung Bestimmung notwendiger Prozeduren mit bestgeeigneten Algorithmen Modulares Programmieren mit Verbergen der Daten in Modulen Datenabstraktion... hilft, Funktionalitäten allgemein zu realisieren, die prinzipiell gleichartig mit unterschiedlichen Daten arbeiten Für jeden Datentyp wird eine Menge von Operationen unterstützt Folie 10

6 Strukturierte Analyse / Strukturiertes Design (3) Structured Analysis (SA) von DeMarco, McMenamin und Palmer [DeM78] erfasst Anforderungen an die Implementierung Umfang: Flussdiagramme Data Dictionary Prozess-Spezifikationen Erfassung dynamischen Verhaltens mit Verhaltensdiagrammen Petrinetzen erweitert die SA zur SA/RT (SA for Realtime Systems) Darstellungsmethoden Structured Analysis Design Technique (SADT) IDEF0 (siehe [AK94a]) Folie 11 Strukturierte Analyse / Strukturiertes Design (4) Structured Design (SD) steht für die Implementierungsplanung, damit zwischen der technologieorientierten Analyse und der eigentlichen Realisierung Analyse der zugrundeliegenden Daten Erfassung des konzeptionellen Datenmodells in Strukturdiagrammen Modellierungssprache IDEF1X (siehe [AK94b]) Folie 12

7 Strukturierte Analyse / Strukturiertes Design (5) Vorgehensmodell: Das Wasserfallmodell von Royce [Roy70] PLAN CODE COMPONENT TEST SYSTEM TEST Folie 13 FIELD SUPPORT Strukturierte Analyse / Strukturiertes Design (6) Kritik: Brooks: Wasserfallmodell ist falsch [FPB95, S. 264ff.] Lineare Einwegrichtung von der Analyse zum Design zu idealisiert und inflexibel Später entdeckte Probleme führen zu lokalen Fixes ohne wesentliche Gesamtänderungen schwierig zu handhaben Unübersichtlichkeit Darstellungsbruch zwischen Analyse und Design Folie 14

8 Datenorientierte Software-Entwicklung (1) Datenorientierte Software-Entwicklung üblich bei Datenbankanwendungen: Verwendete Daten im Vordergrund Weniger wichtig: Prozedurale Techniken, wie mit diesen Daten umgegangen werden soll Weitere Bereiche der datenorientierten Software-Entwicklung: Konvertierungs-Prozessoren EDM-Systeme (EDM = Engineering Data Management) Integrationsarchitekturen Folie 15 Datenorientierte Software-Entwicklung (2) Externes Schema Konzeptionelles Schema Internes Schema Sicht der Einzelanwendungen auf die Daten Anwendungsübergreifende logische allgemeine Datenstruktur Beschreibung der technischen Realisierung Folie 16 3-Schema-Architekturvorschlag der ANSI-SPARC (American National Standards Institute - Standard Planning and Requirement Committee)

9 Datenorientierte Software-Entwicklung (3) Modellierung üblicherweise mit dem Entity-Relationship-Model (ERM) nach Chen [Che76] Basiselemente sind Entitäten als Objekte der realen Welt Beziehungen zwischen den Entitäten Darstellungsmittel sind Entity-Relationship-Diagramme Rechtecke für Entitäten Linien zwischen den Entitäten für Beziehungen Ellipsen für Beziehungs-Attribute Folie 17 Datenorientierte Software-Entwicklung (4) Übliches Vorgehensmodell [Moe98] Anforderungsanalyse Informationserfassung Welche Daten werden benötigt? Informationsverarbeitung Wie werden Daten verarbeitet? Konzeptioneller Entwurf Erfassen der Gegenstandstypen, Beziehungen und Attribute Semantisches Modell Folie 18

10 Datenorientierte Software-Entwicklung (5) Kritik: Semantik des Entity-Relationship-Models reicht für komplexe Anwendungen nicht aus Darstellung dynamischen Verhaltens nicht möglich Weiterentwicklung zum EER-Model (Extended Entity- Relationship-Model) mit Ober- und Unterklassen Vererbungshierarchien Entwicklung von objektorientierten und objektrelationalen Datenbanken Verhalten und Dynamik sind nicht darstellbar Resümee: Relationaler Ansatz reicht für die Datenverwaltung nicht immer aus. Folie 19 Objektorientierte Analyse und Design (1) In den 1980er Jahren: Entwicklung weg von Prozessorientierung hin zur Objektorientierung (OO) Entwicklung weg vom Wasserfallmodell hin zu iterativ inkrementellen Phasenmodellen Objektorientierte Software-Entwicklung (OOSE) umfasst: Objektorientierte Analyse (OOA) Erfassen der Aufgabenstellung aus Sicht des Anwenders Objektorientiertes Design (OOD) Strukturierung des Gesamtsystems und der Klassen Objektorientierte Programmierung (OOP) Umsetzung mit geeigneter Programmiersprache Folie 20 Ab Anfang der 1990er Jahre: Idee für Formalisierung der OOA und OOD; bis dahin Forschung in OO-Programmiersprachen-Entwicklung Verwendung der im Softwareentwurf

11 Objektorientierte Analyse und Design (2) Folie 21 Wichtigste Ansätze: Objektorientiertes Design (OOD) von Booch - auf kommerzielle Anwendungen ausgerichtet Object Modeling Technique (OMT) von Rumbaugh - an strukturierte Methoden angelehnt Object-Oriented Software-Engineering (OOSE) von Jacobson Objektorientierte Analyse (OOA) von Coad, Yourdon. In OMT, OOSE und der Booch-Methode waren Methode und Notation jeweils vereint. Vielfalt der objektorientierten Methoden und Notationen führte zur Zusammenarbeit von Rumbaugh und Booch, später stieß Jacobson hinzu 3 Amigos Die Versuche zur Vereinheitlichung schlossen zunächst Methode und Notation ein, erste Fassungen hießen noch UM für Unified Method. Objektorientierte Analyse und Design (3) Unter Federführung der Firma Rational entwickelten die 3 Amigos gemeinsam die Unified Modeling Language (UML): Grafische Sprache zur Beschreibung objektorientierter Modelle Einheitliche Notation - Die UML ist ausschließlich eine Sprache, eine Notation für die Analyse und das Design objektorientierter Systeme Standardisierung durch die OMG (www.omg.org) Keine Methode, kann aber Basis für Methoden sein Folie 22

12 Objektorientierte Analyse und Design (4) 1990 Methodenblüte 1995 Fraktionen und Allianzen OOSE Jacobsen 1997 Standardisierung Booch Booch UML Amigos UM 0.8 Booch/Rumbaugh UML 1.1 OMT Rumbaugh u.a. Fusion Coleman SOMA Graham Team Fusion Coleman u.a. Unified Process OOSA Shlaer/Mellor OOA Coad/Yourdon MOSES Henderson-Sellers OPEN/OML Open-Group 2000 UML 1.3 Folie /2004 UML 1.4 UML 2.0 Objektorientierte Analyse und Design (5): Vorgehensmodelle Rational Unified Process (RUP) extreme Programming (XP) V-Modell: Verbindlich in der Software-Entwicklung im wehrtechnischen Bereich und in der Bundesverwaltung mit Vorgehensmodell, Methodenzuordnung und funktionalen Werkzeuganforderungen Folie 24 Unternehmensinterne Vorgehensmodelle Interne Handbücher mit Vorgaben und Richtlinien zur Softwareentwicklung Ziel: Qualität und Verkürzung der Projektlaufzeiten

13 Objektorientierte Analyse und Design (6): Rational Unified Process (1) baut auf der UML auf ist ein inkrementeller und iterativer Entwicklungsprozess (von Jacobson, Booch und Rumbaugh 1999) basiert auf Phasen: Innerhalb jeder Phase können eine oder mehrere Iterationen stattfinden Iterationen: Innerhalb jeder Iteration finden die Aktivitäten in den Teilprozessen mit einer bestimmten Gewichtung statt Prozessen: Teilprozessen sind einzelne Workflows zugeordnet Folie 25 Objektorientierte Analyse und Design (7): Rational Unified Process (2) Teilprozesse Phasen Folie 26 Iterationen [Quelle: Rational Unified Process]

14 Objektorientierte Analyse und Design (8): RUP: Phasen (1) Die vier Phasen des Rational Unified Process: Inception (Konzeptphase) Umfang eines Projekts bestimmen Elaboration (Entwurfsphase) Projekt planen, Funktionen und Architektur festlegen Construction (Konstruktionsphase) Produkt erzeugen, Funktionsumfang ausbauen Transition (Übergangsphase) Produkt an den Anwender ausliefern. Folie 27 Objektorientierte Analyse und Design (8): RUP: Phasen (2) Inception Elaboration Construction Transition Aufwand Zeit ~ 5% 10% 20% 20%-40% 65% 40%-50% 10% 10% Tabelle 1: Typisches Verhältnis der Phasen zueinander Kurzes Projekt Typisches Projekt Komplexes Projekt Riskantes Projekt 3 Iterationen (0 I, 1 E, 1 C, 1 T) 6 Iterationen (1 I, 2 E, 2 C, 1 T) 9 Iterationen (1 I, 3 E, 3 C, 2 T) 10 Iterationen (2 I, 3 E, 3 C, 2 T) Tabelle 2: Typische Anhaltswerte für Iterationen pro Phase nach Art und Grösse des Projekts Folie 28

15 Objektorientierte Analyse und Design (9): RUP: Inception Phase Folie 29 Kleines Team (ca. 3-6 Personen), möglichst hohe Qualifikation Meilensteine der Inception Phase: Pläne Definition der Verantwortlichkeiten Grobplan aller Projektphasen (inkl. Iterationenplan) Detailplan für die Elaboration Phase Problembeschreibungen Baseline Vision Baseline Anforderungen und Use Case Modelle Lösungsbeschreibungen (Optional) Verwendbarkeit einer oder mehrere Architekturen demonstrieren Entwicklung/Kauf/Wiederverwendung-Abwägungen Erstes Designmodell Evaluierung Einverständnis der Projektbeteiligten und Anwender Anforderungen werden verstanden Glaubwürdigkeit der Abschätzungen, Risiken und des Prozesses Am Ende steht die "Go/No Go"-Entscheidung Objektorientierte Analyse und Design (10): RUP: Elaboration Phase Folie 30 Kleines Team (ca Personen) Meilensteine der Elaboration Phase: Pläne Detaillierter Construction Phase Plan Grobplanung der Transisition Phase Problembeschreibungen Stabile Vision und Anforderungen (ca. 90%) Evaluierungskriterien der Releases in der Construction Phase Skizzierung des Benutzerhandbuchs Lösungsbeschreibungen Stabiles Design-Modell Entwicklung/Kauf/Wiederverwendung Entscheidung Prototypen fr die kritischen Komponenten Evaluierung Stabilität der Produktvision und der Architektur Lösung der Risiken Hinreichender und glaubwürdiger Plan für die Construction Phase Finanzielle Zusage des Auftraggebers Wichtig: Überanalyse vermeiden ("Analysis Paralysis")!

16 Objektorientierte Analyse und Design (11): RUP: Construction Phase Folie 31 Je nach Projektgröße sollte man alle 2-3 Monate ("mittelgroß") oder 6-9 Monate ("komplexes Projekt") ein Release planen. Während dieser Phase erreicht der Personalstand sein Maximum Meilensteine der Construction Phase: Pläne Detaillierter der Transisition Phase Problembeschreibungen Akzeptanzkriterien für die Produktreleases Fertiggestelltes Benutzerhandbuch Lösungsbeschreibungen Stabile Implementierung Kritische Features und Basisfähigkeiten Objektive Einsicht in die Produktqualität Evaluierung Stabilität und Reife der Produkt-Releases Lösung der Risiken Vorbereitungen für die Übergabe des Systems an die Anwender Jedes Release liefert eine Rückmeldung an die Entwickler, einen Kontrollpunkt für das Management und eine Versicherung für die Kunden Objektorientierte Analyse und Design (12): RUP: Transition Phase Folie 32 Verkleinertes Team, inklusive Support-Mitarbeiter, technischer Autoren, Trainer,... U.u. werden mehrere Releases erzeugt (Beta, "offizielles Release", Bugfixes,...) Meilensteine der Transition Phase: Pläne Eventuell Produktpläne für das nächste Release (Marketing) Problembeschreibungen Endgültige Anwenderdokumentation Lösungsbeschreibungen Stabile Auslieferung "Alle" Features Bestmögliche Qualität Evaluierung Zufriedenheit der Anwender Tatsächliche Projektkosten zu geplanten Projektkosten Jedes Release liefert eine Rückmeldung an die Entwickler, einen Kontrollpunkt für das Management und eine Versicherung für die Kunden

17 Objektorientierte Analyse und Design (13): RUP: Iterationen Artefakte werden im Laufe des Projekts vervollständigt. Während jeder Phase können Artefakte aus allen Bereichen entstehen oder weiterentwickelt werden. Folie 33 [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (14): RUP: Beispiel-Prozess Teilprozess Analysis and Design Ablauf beschränkt auf eine bestimmte Phase Start des Teilprozesses Analysis and Design Kontrollfluss Workflow Folie 34 Abschluss der Workflows innerhalb des Teilprozesses [Quelle: Rational Unified Process]

18 Objektorientierte Analyse und Design (15): RUP: Rollen, Aktivitäten und Artefakte Basiselemente des Workflows Rolle Werkzeuge für Aktivitäten Dokument ( Artifact ) Folie 35 Werkzeuge für Artefakte [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (16): RUP: Beispiel Prozessdetails Workflow am Beispiel Design Components Abhängiger Workflow / Folge- Workflow Folie 36 [Quelle: Rational Unified Process]

19 Objektorientierte Analyse und Design (17): RUP: Beispiel Aktivität Activity am Beispiel Subsystem Design Folie 37 [Quelle: Rational Unified Process] Objektorientierte Analyse und Design (18): Rollen im RUP Folie 38 Beispiele für Rollen im Rational Unified Process: Analysts (Business-Process Analyst, Business Designer, Requirement Specifier, System Analyst,etc.) Developers (Software Architect, Capsule Designer, Database Designer, Design Reviewer, Designer, Implementor, etc.) Testers (Test Designer, Tester) Managers (Change Control Manager, Configuration Manager, Deployment Manager, Project Manager, etc.) Verantwortung und Autorität von Rollen müssen genau definiert sein Sinnvolles Werkzeug dazu ist die RACI-Matrix RACI = Responsible, Accountable, Consulted, Informed Den Rollen müssen Personen zugeordnet werden (m:n- Abbildung) Diese Zuweisung muss nicht statisch über das ganze Projekt gleich sein, eine Änderung ist zu Beginn jeder Projektphase möglich

20 Objektorientierte Analyse und Design (18): Rational Unified Process: Kritik Zwar hat sich der RUP als Standard-Vorgehensmodell etabliert, dennoch werden Kritikpunkte geäußert [Hes01]: Der RUP folgt noch immer dem Wasserfallmodell Der RUP ist nicht ausreichend architekturzentriert Die Iterationen sind an Phasen gekoppelt, nicht an Blöcken Unnötige Komplexität der RUP Workflows (heute: Disciplines) Die Mittel Hierarchie, Rekursion und Orthogonalität werden nicht eingesetzt Ungenügende Management-Unterstützung, zu schwaches Meilensteine-Konzept Mangelnde Unterstützung der unterschiedlichen Rollen, insbesondere der Anwender-Rolle Folie 39 Objektorientierte Analyse und Design (19): Kritik In der Durchführung von OO-Projekte ergeben sich auch Probleme [va96]: Keine Durchgängigkeit Großes Fehlerrisiko bei der Erhebung und Modellierung der Anwenderspezifikationen teures Redesign Scheitern missgestalteter Applikationen Wiederverwendbarkeit im großen Maßstab bisher gescheitert Frameworks haben sich als weniger erfolgreich herausgestellt, als erwartet: für Prototyping ungeeignet Einarbeitungszeit dauert oft zu lange Anpassungsaufwand für konkreten Projekteinsatz zu groß Flexibilität Komplexität Folie 40

21 Objektorientierte Analyse und Design (20): Extreme Programming: Grundwerte Extreme Programming (XP) wurde 1996 von Kent Beck entwickelt und basiert auf vier Grundwerten: Communication: Ständige Kommunikation zwischen Kunden und Entwicklern sowie unter den Entwicklern selbst Simplicity: Kontinuierliche Überarbeitung des Source-Codes mit dem Ziel alles Überflüssige zu vermeiden Feedback: Basierend auf User Stories viele kleine Releases, laufende Integration, kontinuierliches Testen Courage: Ehrlichkeit, was man kann und was nicht Folie 41 XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the S.E.I. and its Capability Maturity Model were to the last. -- Tom DeMarco, Aus dem Vorwort von Planning Extreme Programming, 2001 Objektorientierte Analyse und Design (21): Extreme Programming: User Stories Anforderungen in XP werden durch sogenannte "User Stories abgehandelt. Der Kunde beschreibt alle Abläufe, die für die Lösung des Problems notwendig sind. Der Kunde kann während des Projekts neue User Stories ergänzen, entfernen und ändern, muss dies aber priorisieren. User Stories sind ein Versprechen für einen folgenden Dialog zwischen Kunde und Entwickler. Eine User Story passt normalerweise auf ein DIN A 5 Blatt. Folie 42

22 Objektorientierte Analyse und Design (22): Extreme Programming: 12 Praktiken (1) XP umfasst zwölf Praktiken, die sich gegenseitig unterstützen bzw.. verstärken: The Planning Game On-Site Customer Metaphor Small Releases Sustainable Pace Testing Simple Design Continuous Integration Pair Programming Collective Code Ownership Refactoring Das Planungsspiel ( Kunde ist anwesend) Coding Standards Am Beginn einer Iteration wird von Kunden PM und Entwicklern gemeinsam anhand der User Stories die Releaseplanung vorgenommen. Die Priorisierung der Stories erfolgt ausschließlich durch den Kunden, die Aufwandsschätzungen nur durch die Entwickler Folie 43 Kleine Releases Kurze Iterationszeiten werden eingehalten (+/- 4 Wochen) und die (Zwischen-)Releases werden dem Kunden zur Kontrolle und Feedback übergeben. Objektorientierte Analyse und Design (23): Extreme Programming: 12 Praktiken (2) Metapher Eine einfache "Story", wie das System grundsätzlich funktioniert. Die Metapher dient als Ersatz für die Architektur. Einfaches Design ( Refactoring) Design und Code sollen so einfach wie möglich gehalten werden Regelmäßig Codekontrollen durchführen und überflüssigen Code sofort entfernen Es wird nur implementiert, was direkt Auswirkung auf die Implementierung der aktuelle bearbeiteten User Story hat. Folie 44 Tests Die Entwickler schreiben (automatisch ausführbare) Unit- Tests bevor die eigentliche Funktionalität implementiert wird ("Test-First"-Ansatz) Der Kunde definiert parallel Abnahmetests

23 Objektorientierte Analyse und Design (24): Extreme Programming: 12 Praktiken (3) Refactoring ( Tests, Einfaches Design, Pair Programming) Wenn bei der Implementierung neuer Stories erkannt wird, dass die bisherige Implementierung geändert werden muss, so wird dies immer durchgeführt Die Unit-Tests sorgen dafür dass, der geänderte Code noch die gleiche Funktionalität implementiert. Kollektiver Codebesitz ( Pair Programming, Tests, Refactoring, Einfaches Design) Jeder hat das Recht, an jeder Stelle im Code Veränderungen vorzunehmen. Folie 45 Laufende Integration ( Tests) Immer wenn ein Teil der Implementierung (z.b. ein Story) fertig gestellt ist, wird dieser in das Gesamtsystem integriert. Vor der Integration müssen alle Tests durchlaufen, wenn während der Integration Fehler auftreten, muss die Ursache im neuen Code liegen. Nach der Integration müssen wieder alle Tests durchlaufen. Objektorientierte Analyse und Design (25): Extreme Programming: 12 Praktiken (4) Nachhaltige Entwicklung (war: 40-Stunden-Woche) Aufgrund der hohen Anforderungen beim Pair Programming kann bei XP-Projekten nicht (bzw. kaum) mit Überstunden gearbeitet werden. Pair Programming ( Nachhaltiges Arbeiten) Immer zwei Entwickler arbeiten zusammen an einem Arbeitsplatz (Kontinuierliches Codereview) Die Paare wechseln nach jeder Story, evtl. öfter, nach Bedarf Jede Codestelle wird somit von mindestens zwei Entwicklern gekannt. Kunde ist anwesend Der Kunde ist am Ort der Softwareentwicklung ständig anwesend (für Rückfragen, Stories, Tests) Folie 46 Programmierrichtlinien( Kollektiver Codebesitz, Pair Programming) Alle im Entwicklungsteam verpflichten sich, einen einheitlichen Codierungsstandard einzuhalten.

24 Objektorientierte Analyse und Design (26): Extreme Programming: Bewertung XP hat einige Voraussetzungen, die den Einsatz von "XP in Reinkultur" sehr erschweren können. Anwesenheit des Kunden Mangels entsprechend qualifizierter und verfügbarer Ressourcen beim Kunden kaum durchzusetzen. Planungsspiel Bestimmte Vertragsverhältnisse (z.b. Festpreisprojekt mit definiertem Umfang) macht den Einsatz von XP riskant bis unmöglich. Folie 47 Einige XP-Praktiken können aber auch im Rahmen anderer Entwicklungsprozesse sinnvoll angewandt werden. XP hat dem "Test-First"-Ansatz zum Durchbruch verholfen Kleine Releases und kontinuierliche (oder zumindest häufige) Integration haben sich auch in anderen Projekten bewährt. Pair Programming kann sehr effizient sein, kann aber auch ein Ressourcenverschwendung darstellen (abhängig von der Komplexität der Aufgaben und dem Verhalten der Entwickler) Refactoring wird zunehmend als notwendige Aktivität gesehen, um Projekte "gesund" zu halten. Weitere Vorgehensmodelle & Ausblick Evolutionäre objektorientierte Softwareentwicklung (EOS) [Hes01] Folie 48

25 Weitere Vorgehensmodelle & Ausblick Weitere Agile Prozesse: Scrum (Takeuchi / Nonaka, 1986; Schwaber / Beedle, 2002) Terminologie aus dem Rugby Bereich: Pregame Phase, Development Phase (Sprint), Postgame Phase Crystal-Prozessfamilie (Cockburn, 1998) Crystal Clear für kleine Projekte (bis ca. 6 Entwickler) Crystal Orange für mittelgroße Projekte (bis ca. 40 Entwickler) Feature Driven Development (FDD) (Coad et. al. 2000) Adaptive Software Development (Highsmith 2000) Folie 49 Weitere Vorgehensmodelle & Ausblick Weitere Vorgehensmodelle Springbrunnenmodell [Pil96] Aktivitäten können parallel verlaufen Eine hohe Iterationstiefe ist vorhanden Einzelne Phasen können sich überlappen Chaosmodell von Raccoon entworfen [Rac95] Flexibilität, innerhalb der einzelnen Schritte des SE- Prozesses bei Bedarf zu iterieren Open-Source-Software-Entwicklung Folie 50 Ausblick Neuere Entwicklungen wie die Komponentenorientierung werden zu neuen Vorgehensmodellen führen, die auf die grundlegenden Konzepte der objektorientierten Vorgehensmodelle aufbauen werden.

26 Zusammenfassung Wesentliches Merkmal aller Vorgehensmodelle: Abstrahieren der zu lösenden Probleme Es gibt Alternativen zum Wasserfallmodell mit strukturierter Analyse und Design Gemeinsamkeit aktueller Prozesse: Iterative Vorgehensweise Trend: Agile Prozesse (nur soviel Formalismus wie nötig) Folie 51 zur Vorlesung Karl Friedrich Gebhardt Objekt-orientiertes Software- Engineering, 2002, URL: Karl Friedrich Gebhardt UML - Unified Modeling Language, 2002, URL: Bernd Oestereich Objektorientierte Softwareentwicklung - Analyse und Design mit der Unified Modeling Language, 5. Auflage, Verlag Oldenbourg, 2001 URL: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, 1995 Folie 52

27 Weiterführende Folie 53 [AK94a] Adelsberger, Heimo H. und Frank Körner: IDEF-0 Eine Methode zur Funktionsmodellierung. Wirtschaftsinformatik für Produktionsunternehmen, Universität GH Essen, URL: [AK94b] Adelsberger, Heimo H. und Frank Körner: IDEF-1X Eine Methode zur Datenmodellierung. Wirtschaftsinformatik für Produktionsunternehmen, Universität GH Essen, URL: [Che76] Chen, P. P.: The Entity-Relationship Model: Toward a Unified View of Data. ACM Trans. on Database Systems 1, Seiten 9 36, [DeM78] DeMarco, Tom: Structured Analysis and Systems Specification. Yourdon Press, New York, [FPB95] Frederick P. Brooks, Jr.: The Mythical Man-Month. Addison-Wesley, [JCJO92] Jacobsen, Ivar, Magnus Christerson, Patrik Jonsson und Gunnar Overgaard: Object-Oriented Software Engineering. A Use Case Driven Approach.Addison-Wesley, [Hel94] Hellmuth, Thomas W.: Datenmodellierung zur marktgerechten Führung der Produktionsbereiche. B. G. Teubner Stuttgart, [Hes01] Wolfgang Hesse: Dinosaur meets Archaeopteryx?Seven Theses on Rational's Unified Process (RUP), Proc. CAiSE'01/IFIP 8.1 Int. Workshop on Evaluation of Modeling Methods in System Analysis and Design (EMMSAD'01), Ch. VII, Interlaken 2001 [KKST79] Kimm, R., W. Koch, W. Simonsmeier und F. Tontsch: Einführung in Software Engineering. Walter de Gruyter & Co., Berlin, [Moe98] Moekotte, Guido: Objektbanken, Vorlesung Lehrstuhl für Praktische Informatik III, Universität Mannheim. [Pil96] PILLAI, K.: The Fountain Model and its Impact on Project Schedule. ACM SIGSOFT Software Notes, 21(2):32 38, March [Rac95] RACCOON, L. B. S.: The Chaos Model and the Chaos Life Cycle. ACM SIGSOFT Software Notes, 20(1):55 66, January [Rat] Rational Software Corporation: Rational Unified Process 5.5 [Roy70] Royce, Winston W.: Managing the Development of Large Software Systems: Concepts and Techniques. In: WESCON, Band 14, Seiten A/1 1 A/1 9, Western Electronic Show and Convention, Los Angeles, Aug , [va96] Ammon, Rainer von: Wiederverwendung in der kommerziellen Softwareentwicklung läßt auf sich warten. Computerzeitung, 27:10,

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

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

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

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

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

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

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

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

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

- 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

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

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

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

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

Software-Engineering

Software-Engineering SWE6 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 6: Projektmanagement Wasserfallmodell SWE6 Slide 2 Wasserfallmodell Zeitliche Einordnung in Breiten-/Tiefenraster Funktionale Breite

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

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

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

Softwaretechnik Überblick

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

Mehr

9 Die Unified Modelling Language UML und der Rational Unified Process RUP / Objectory

9 Die Unified Modelling Language UML und der Rational Unified Process RUP / Objectory In diesem Kapitel: Geschichte von RUP/ROP Inkrementelle und iterative Softwareentwicklung Startphase (inception phase) Entwurfsphase (elaboration) Konstruktionsphase (construction phase) Übergangsphase

Mehr

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

Mehr

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

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

Mehr

3. Vorgehensmethoden/Prozessmodelle

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

Mehr

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

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

Agile Softwareprozess-Modelle

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

Mehr

1.2 System- und Softwareentwicklungsprozesse

1.2 System- und Softwareentwicklungsprozesse 1.2 System- und Softwareentwicklungsprozesse Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Vorgehensmodelle und UML Um Systeme und Software

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

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

Mehr

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle)

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

Mehr

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

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

Mehr

Software Engineering. Prozessmodelle zur Softwareentwicklung

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

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

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

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

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

Mehr

Projektmanagement. Projektmanagement

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

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

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

Mehr

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

Extreme Programming: Überblick

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

Mehr

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

Kapitel 1 Software-Prozessmodelle

Kapitel 1 Software-Prozessmodelle Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung

Mehr

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

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

Mehr

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

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

Mehr

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

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

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

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

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

Mehr

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

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

Mehr

V-Methode, RUP, Waterfall oder was?

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

Mehr

SWE12 Slide 1. Software-Engineering. Vorlesung 12 vom 17.01.2005 Sebastian Iwanowski FH Wedel

SWE12 Slide 1. Software-Engineering. Vorlesung 12 vom 17.01.2005 Sebastian Iwanowski FH Wedel SWE12 Slide 1 Software-Engineering Vorlesung 12 vom 17.01.2005 Sebastian Iwanowski FH Wedel SWE12 Slide 2 Projektmanagement Zeitliche Organisation des Projektablaufs Wasserfallmodell Prototyping Spiralmodell

Mehr

Agile Methoden: Leichtgewichte der Softwaretechnik

Agile Methoden: Leichtgewichte der Softwaretechnik Agile Methoden: Leichtgewichte der Softwaretechnik Prof. Dr. Gerald Lüttgen Lehrstuhl Softwaretechnik & Programmiersprachen Universität Bamberg www.swt-bamberg.de 2011 Gerald Lüttgen Vortrag IT Cluster

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

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

Der Rational Unified Process - ein Prozess- Framework für Software Projekte

Der Rational Unified Process - ein Prozess- Framework für Software Projekte IBM Software Group Der Rational Unified Process - ein Prozess- Framework für Software Projekte Hubert Biskup IT Specialist 2005 IBM Corporation Agenda Historie des Rational Unified Process Einige Grundprinzipien

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

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik 1 / 43 Softwaretechnik II Sommersemester 2014 Software-Qualität Stefan Berlik Fachgruppe Praktische Informatik Fakultät IV, Department Elektrotechnik und Informatik Universität Siegen 8. Mai 2014 Gliederung

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Management von Anforderungen im Rational Unified Process (RUP)

Management von Anforderungen im Rational Unified Process (RUP) Management von Anforderungen im Rational Unified Process (RUP) Peter Fröhlich ABB DECRC 69115 Heidelberg Fröhlich-8/98-1 Themen: Was ist RUP? RM im RUP Core Workflows Dokumente Tools Erfahrungen RUP Objectory

Mehr

Agile Software-Entwicklung: Überblick

Agile Software-Entwicklung: Überblick Agile Software-Entwicklung: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Inhalt Historie Agiles Manifest Agile Prinzipien Agile Methoden Agile SW-Entwicklungsprozesse Stefan Diener / Apr 18, 2007 /

Mehr

Verknüpfung des V-Modell XT mit dem RUP mithilfe des IBM Rational Method Composer. V-Modell XT Jahreskongress 24.04.2006. Run. Data Management Systems

Verknüpfung des V-Modell XT mit dem RUP mithilfe des IBM Rational Method Composer. V-Modell XT Jahreskongress 24.04.2006. Run. Data Management Systems IBM Software Group Verknüpfung des V-Modell XT mit dem RUP mithilfe des IBM Rational Method Composer Hubert Biskup IBM Rational Software V-Modell XT Jahreskongress 24.04.2006 2006 IBM Corporation Rational

Mehr

1 Objektorientierte Software-Entwicklung

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

Mehr

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

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

Mehr

extreme Programming (XP)

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

Mehr

Software entwickeln mit extreme Programming

Software entwickeln mit extreme Programming Martin Lippert Stefan Roock Henning Wolf Software entwickeln mit extreme Programming Erfahrungen aus der Praxis dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1 Die XP-Werte 4 1.2 Die XP-Prinzipien

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

Vorlesung Methoden des Software Engineering. Martin Wirsing. Einheit E.1, 22.1.2007

Vorlesung Methoden des Software Engineering. Martin Wirsing. Einheit E.1, 22.1.2007 Block E (SW-Prozess & Projektmanagement): Vorgehensmodelle 22.1.2007 1 Vorlesung Methoden des Software Engineering Block E Software-Prozess und Projektmanagement Vorgehensmodelle Martin Wirsing Einheit

Mehr

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

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

Mehr

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

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Stefan Roock, roock@jwam.de APCON Workplace Solutions GmbH & Universität Hamburg Vogt-Kölln-Strasse 30 22527 Hamburg Germany

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

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

Feature-based Programming

Feature-based Programming Stefan Richter Feature-based Programming Planung, Programmierung, Projekt-Management: Über die Kunst systematisch zu planen und mit Agilität umzusetzen ADDISON-WESLEY An imprint of Pearson Education München

Mehr

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

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

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Software-Engineering. Einführung. Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik. Klaus Mairon, M.Sc. www.mairon-online.

Software-Engineering. Einführung. Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik. Klaus Mairon, M.Sc. www.mairon-online. Software-Engineering Einführung Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Zu mir Mein Arbeitgeber - Metris GmbH - Zielmarkt: Software für Versicherungsunternehmen

Mehr

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

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

Mehr

Praktische Softwaretechnologie Vorlesung 8

Praktische Softwaretechnologie Vorlesung 8 Praktische Softwaretechnologie Vorlesung 8 Martin Giese Johann Radon Institute for Computational and Applied Mathematics Österr. Akademie der Wissenschaften Linz PSWT 2006 12. Dezember 2006 p.1/32 Die

Mehr

Softwaretechnik Prozessmodelle

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

Mehr

Das V-Modell: Produkte 1/5

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

Mehr

Einführung Wasserfall RUP XP. Teil VIII. Prozessmodelle

Einführung Wasserfall RUP XP. Teil VIII. Prozessmodelle Teil VIII Prozessmodelle 424 8.1 Einführung Prozessmodelle legen fest: Elemente und Reihenfolge des Arbeitsablaufs Definition der Teilprodukte Fertigstellungskriterien notwendige Mitarbeiterqualifikationen

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Navi & seitenzahl. Ein Toolset für agile Entwicklungsprojekte

Navi & seitenzahl. Ein Toolset für agile Entwicklungsprojekte Navi & seitenzahl Ein Toolset für agile Entwicklungsprojekte Warum Agil? Noch andere Gründe? Aktive Integration der Anwender Integration des Kunden Rückfragen, Priorisierungen Geschmack kommt beim Essen

Mehr

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) (Dr. Markus Nüttgens, Dipl.-Hdl. Michael Hoffmann, Dipl.-Inform. Thomas Feld, Institut für Wirtschaftsinformatik (IWi), Universität

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

Softwareentwicklung bei eevolution

Softwareentwicklung bei eevolution Softwareentwicklung bei eevolution Darstellung der Prozesse mit dem agilen Entwicklungsansatz Jan Freitag, COMPRA GmbH Jan Freitag Studium: IMIT Bachelor: 2005-2008 IMIT Master: 2008-2010 eevolution: Mitarbeit

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

REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis. Business Consulting & Analysis @ Sunrise

REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis. Business Consulting & Analysis @ Sunrise REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis Business Consulting & Analysis @ Sunrise Agenda 1. Sunrise 2. Ausgangslage Business Analysis Planning and Monitoring 3. Team

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

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr