Klausurvorbereitung Software Engineering TFH Berlin

Größe: px
Ab Seite anzeigen:

Download "Klausurvorbereitung Software Engineering I @ TFH Berlin"

Transkript

1 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, Software zu entwickeln, zu betreiben und zu warten (IEEE). Man versteht darunter aber auch die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieursmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen. (H. Balzert, Lehrbuch der Software-Technik). Zielorientiert Berücksichtigung von z.b. Kosten, Zeit, Qualität. Zusammengefasst kann man sagen, dass SE Die Entwicklung komplexer Software erlaubt Den Einsatz von Werkzeugen und Methoden bedeutet Zeit und Kosten spart (sparen kann) Qualität und Produktivität erhöht (erhöhen kann) Hinweis: Die Definition des IEEE ist von mir frei aus dem Englischen übersetzt. Dort lautet sie: The systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. Ich gehe davon aus, dass man diesen englischen Satz zwar verstehen aber nur schwer übersetzen kann und rate zur Verwendung der deutschsprachigen Definition. Das Teufelsquadrat nach Sneed Das Teufelsquadrat nach Sneed zeigt die vier wichtigsten Faktoren bei der Entwicklung von Software-Projekten. Dabei hängen die einzelnen Faktoren voneinander ab, wodurch sich die beiden inneren Vierecke ergeben (eigentlich sind das rote, verzerrte Viereck und das Quadrat in der Mitte das gleiche, nur in unterschiedlichen Situationen). Im Beispiel ist zu sehen, dass eine Erhöhung der Qualität bei Verkürzung der Entwicklungsdauer zwangsweise mit einer Reduktion der Quantität und einer Erhöhung der Entwicklungskosten einhergeht. Das Viereck, welches aus den vier Faktoren gebildet wird, zeigt die Produktivität an, die mit den gegebenen Faktoren erreicht werden kann. Die Fläche des Vierecks bleibt immer gleich. Verschiebungen eines Faktors ergeben also weitere Verschiebungen, so dass sich Gebilde wie das hier rot eingezeichnete Viereck ergeben. Klar, ohne direkten Zusammenhang zum Teufelsquadrat: Erhöht man die Anforderungen an eine Software (z.b. die Quantität der implementierten Funktionen), so muss entweder die Qualität darunter leiden, oder aber Entwicklungsdauer und/oder kosten steigen an. Eben diesen Sachverhalt stellt das Teufelsquadrat dar. Anmerkung: In der heutigen Vorlesung ( ) hieß es, dass die senkrechten Seiten des Produktivitäts-Vierecks immer senkrecht sein müssen Das würde allerdings bedeuten, dass man ein Software-Projekt nur dann mit einer höheren Qualität ausstatten kann, wenn man die Entwicklungsdauer reduziert und das ergibt in meinen Augen wenig Sinn 1

2 Wissensgebiete des Software Engineering nach IEEE Software Requirements Was soll eine Software leisten? Software Design Wie wird die Software aufgebaut (Architektur)? Software Construction Realisierung der Software gemäß dem Design Software Testing Systematische Fehlerfindung und behebung Software Maintenance Wartung und Weiterentwicklung nach Auslieferung Software Configuration Management Verwaltung von Software-Versionen und Konfigurationen Software Engineering Management Projektmanagement von Personen, Organisationen, Zeit, etc. Software Engineering Process Definition und Verbesserung von Software-Entwicklungsprozessen Software Engineering Tools and Methods Werkzeuge und Methoden für die Software-Entwicklung Software Quality Messung und Verbesserung der Software-Qualität 2

3 Teil 1.1 Die Pre-Analyse-Phase Die Pre-Analyse-Phase beinhaltet alle Schritte, die getan werden müssen, bevor man mit der OOA beginnen kann bzw. sollte. Entsprechend Ein erster Schritt ist die Machbarkeitsstudie (Feasibility Study), in der vor dem Beginn des eigentlichen Projekts geprüft wird, ob das Projekt überhaupt durchführbar ist. Diese Prüfung kann projekt- oder marktbezogen durchgeführt werden. Es wird also eine Analyse des Projekts durchgeführt, die zu Lösungsvorschlägen führt. Aufgaben der Machbarkeitsstudie Beschreibung und Analyse des Projekts selbst Prioritäten der Funktionen setzen (was muss drin sein, was kann, was nicht,...) Verschiedene Lösungsansätze erarbeiten Abschätzung von Kosten (ROI Return of Investment), Umfang und Risiken sowie Zeitund Personalaufwand Erstellen eines Angebots Aus der Machbarkeitsstudie gehen hervor: Lastenheft (grobe fachliche Anforderungen) Projektkalkulation (Schätzung von Umfang und Entwicklungskosten) Projektplan (Zeitplan und Festlegung der Phasenergebnisse) Angebot an den Auftraggeber Das Lastenheft Das Lastenheft besteht aus sieben Teilen: 1. Zielbestimmung Hier wird festgelegt, welche Ziele das Projekt erreichen soll 2. Produkteinsatz Welche Anwendungsbereiche hat die Software? 3. Produktfunktionen Dieser Teil beschreibt die Hauptfunktionen des Projekts 4. Produktdaten Beschreibt die Hauptdaten zur permanenten Speicherung 5. Produktleistungen Hier finden sich besondere Anforderungen an Hauptfunktionen oder Hauptdaten 6. Qualitätsanforderungen Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Portierbarkeit, Ergänzungen Sonstiges eben Glossar Erklärung aller in den Punkten 1 bis 7 verwendeten Begriffe Adressaten für das Lastenheft sind sowohl Auftraggeber, als auch Auftragnehmer. Es sollte übersichtlich gegliedert sein und auf wenigen Seiten prägnante Sätze in natürlicher Sprache enthalten, die die fundamentalen Eigenschaften des Produktes aus der Sicht des Kunden zusammenfassen. Es sollte vor einem Vertragsabschluss angefertigt werden. 3

4 Anforderungen Man unterscheidet zwischen funktionalen und nichtfunktionalen Anforderungen. Nichtfunktionale Anforderungen Produktanforderungen o Benutzbarkeit o Effizienz (Performanz und Speicher) o Zuverlässigkeit o Portierbarkeit Unternehmensanforderungen o Lieferung o Umsetzung o Standards Externe Anforderungen o Kompatibilität o Interoperabilität o Ethische Anforderungen o Rechtliche Anforderungen (Datenschutz, Sicherheit,...) Funktionale Anforderungen Fachliche Funktionen Ein-/Ausgabedaten Verhalten der Software 4

5 Teil 2 Vorgehensmodelle Vorgehensmodell im Software Engineering werden auch als Software-Lebenszyklus bezeichnet und stellen verschiedene Vorgehensweisen zur Software-Entwicklung zur Verfügung. Sie sind in Phasen unterteilt, die entweder inhaltlich oder zeitlich voneinander abgegrenzt sind. Mit den Vorgehensmodellen ist die Steuerung komplexer Projekte möglich. Für jedes Projekt kann und muss das richtige bzw. passende Modell gefunden werden, da es unterschiedliche Detaillierungsgrade gibt. Vorgehensmodelle können sehr komplex sein, helfen aber dabei, komplexe Projekte zu bewältigen. Oft sind sie firmenintern oder vom jeweiligen Auftraggeber vorgegeben. Je mehr Erfahrung ein Entwickler oder ein Team von Entwicklern mit einem solchen Modell hat, desto effizienter können Zeit und Kosten gespart werden. Das Wasserfallmodell Dieses Modell stammt aus dem Jahre 1970 und ist auch als Phasenmodell bekannt. Es ist in die folgenden Phasen unterteilt: Anforderungsdefinition System- und Software-Design Implementierung (Programmierung) und Modultest Integration und Systemtest Installation und Wartung Diese Phasen bauen (mit Ausnahme der obersten natürlich), als Kaskade aufeinander auf. Man kann von einer Phase zu ihrem Vorgänger zurückgehen, aber keine Stufe überspringen. Wichtig ist, dass jede Phase erst komplett abgeschlossen sein muss, bevor die ihr nachfolgende Phase begonnen werden kann. abgeschlossene und genehmigte Dokumente. Jede Phase liefert ein oder mehrere Vorteile Dokumentation am Ende jeder Phase Kompatibel zu anderen Vorgehensmodellen Geeignet für den Einsatz bei Projekten mit klaren Anforderungen Nachteile Anforderungen werden früh eingefroren Unflexibel (nachträgliche Änderungen sind nicht eingeplant) Die Kosten- und Ressourceneinschätzung ist ungenau 5

6 Das Spiralmodell (Boehm, 1988) Beim Spiralmodell nach Boehm handelt es sich um eine Kombination vorhandener Modelle unter Berücksichtigung von Managementaspekten. Es enthält zwei Achsen: 1. Die Zeitachse 2. Die Kostenachse In den Windungen finden sich die Aktivitäten, in den Winkeln die Fortschritte der einzelnen Projektzyklen. Die einzelnen Windungen sind in vier Sektoren aufgeteilt: Festlegung von Zielen, Beurteilung von Alternativen Risikoanalyse Planung des nächsten Zyklus Entwicklung und Test Im Spiralmodell beginnt der Lebenszyklus eines Projekts im Zentrum der Spirale und verläuft auf ihr nach außen hin. Vorteile Frühzeitiges Erkennen von Risiken und Fehlern Lösungsalternativen Prototypbasiert Kontinuierliche Wartung und Erweiterung Iterativ und inkrementell Nachteile Nicht geeignet für kurzzeitige, kleine Projekte 6

7 Das V-Modell (1986) Beim V-Modell handelt es sich um eine Erweiterung des Wasserfallmodells, in dem aber keine strikten zeitlichen Abfolgen und keine Abnahmen am Ende der einzelnen Phasen vorhanden ist. Beim V-Modell XT handelt es sich um den Entwicklungsstandard für IT-Systeme des Bundes. Es wurde im Februar 2005 in der Version 1.2 vorgestellt. Aktivitäten und Produkte des Entwicklungs- und Planungsprozesses sind festgelegt. Eine Qualitätssicherung ist integriert. So werden die einzelnen Phasen verifiziert ( Wird ein korrektes Produkt entwickelt? ) und validiert ( Wird das richtige Produkt entwickelt? ). Vorteile Das V-Modell ist standardisiert und dennoch flexibel Die Softwarequalität wird gewährleistet Kosten werden reduziert Die Kommunikation zwischen den einzelnen Mitarbeitern/Teams wird erhöht Auftraggeber und nehmer haben eine gemeinsame Sprache Nachteile Anfangs sind Abstimmungsprozesse notwendig 7

8 Weitere Vorgehensmodelle (nicht im Detail relevant für die Klausur) RUP Rational Unified Process Beim RUP handelt es sich um ein Vorgehensmodell und Produkt von IBM Rational. Es bietet statische, dynamische und Praxis-Perspektiven. XP extreme Programming Bei XP findet die Entwicklung in kleinen Schritten statt. Dadurch werden Kommunikation und Tests besonders wichtig. MMD Model Driven Development Auf Grundlage von UML 2.0 wird zunächst ein Modell entwickelt, aus dem später der Code generiert wird (viele UML-Tools können dies automatisch durchführen). 8

9 Teil 3 UML 3.1 Phasen der objektorientierten Entwicklung Die objektorientierte Entwicklung teilt sich in drei Stufen bzw. Phasen ein: OOA, OOD und OOP. Am Anfang steht die OOA, die objektorientierte Analyse. Hier werden fachliche Anforderungen erfasst und beschrieben. Die zweite Phase, das OOD, das objektorientierte Design, befasst sich mit dem technischen Design und der Architektur des Projekts. Am Schluss wird in der OOP, der objektorientierten Programmierung, das Design in einer objektorientierten Sprache (z.b. Java, C#,...) umgesetzt Die Phasen der objektorientierten Analyse (OOA) Die einzelnen Phasen werden mit UML realisiert. 1. Beschreibung von Anwendungsfällen mit Use-Case-Diagrammen 2. Modellierung von Abläufen mit Aktivitätsdiagrammen 3. Darstellung von Zustandsänderungen mit Zustandsdiagrammen 4. Datenmodellierung mit Objekt- und Klassendiagrammen 5. Textuelle Beschreibung der Anforderungen Als Ergebnis erhält man ein detailliertes Pflichtenheft Unterschied zwischen Pflichten- und Lastenheft Unter einem Lastenheft versteht man die Anforderungen eines Kunden, die auch eine grobe Beschreibung des Konzepts enthalten sollen. Ein Pflichtenheft wird dagegen meistens vom Auftragnehmer erstellt. Es geht aus dem Lastenheft hervor und enthält detaillierte Anforderungen. 3.2 Was ist UML? Bei UML (Unified Modelling Language) handelt es sich um eine Modellierungssprache, die als Spezifikation von OMG (Object Management Group), einem Konsortium der Computerindustrie, die Integrationsstandards für Unternehmen entwickelt, herausgegeben wird und sich seit 2004 in der Version 2.0 befindet. UML wird als visuelle bzw. grafische Programmiersprache eingesetzt und hat wie alle anderen Programmiersprachen eine feste Syntax bzw. eine einheitliche Notation. Unter xuml versteht man die ausführbare Variante von UML. Diese ermöglicht es, ein erstelltes Analysemodell als Prototyp auszuführen (man spricht dann vom ausführbaren Pflichtenheft). 9

10 3.3 Die verschiedenen UML-Diagrammarten In UML 2.0 gibt es zunächst einmal zwei verschiedene Typen von Diagrammen: 1. Strukturdiagramme (statisch) 2. Verhaltensdiagramme (dynamisch) Strukturdiagramme Klassendiagramm Objektdiagramm Paketdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Einsatz- und Verteilungsdiagramm (Deployment) Verhaltensdiagramme Anwendungsfalldiagramm (Use Case) Aktivitätsdiagramm (Activity) Zustandsdiagramm (State Machines) Interaktionsdiagramm o Sequenzdiagramm o Kommunikationsdiagramm o Interaktionsübersichts-Diagramm o Zeitdiagramm 10

11 3.4 Das Anwendungsfalldiagramm (Use Case-Diagramm) Beim Anwendungsfalldiagramm in UML werden Geschäftsprozesse dargestellt. Ebenso wird das Verhalten des Systems aus der Sicht des Anwenders beschrieben Die Notation Geschäftsprozesse werden als Oval dargestellt und enthalten eine Beschreibung von sich selbst, die immer aus Substantiv und Verb bestehen muss. Akteure werden als Strichmännchen dargestellt. Bei ihnen handelt es sich um eine Person oder auch ein Teilsystem, welche(s) einen Geschäftsprozess auslöst. Assoziationen Anwendungsfalldiagramme unterscheiden sechs Arten von Assoziationen, die die Beziehungen zwischen den Geschäftsprozessen und Akteuren untereinander darstellen. Einfache Assoziation Beide sind beteiligt, bidirektionaler Informationsfluss Gerichtete Assoziation Quelle löst Ziel aus, Informationsfluss unidirektional Generalisierung Quelle ist Spezialisierung des Ziels Abhängigkeit Quelle ist vom Ziel abhängig, Ziel ist unabhängig Include-Beziehung Quelle enthält die Funktionalität des Ziels Extend-Beziehung Quelle erweitert die Funktionalität des Ziels Sonstige Assoziationen können durch Label beschriften werden. Notizen sind auch möglich und können mit Geschäftsprozessen und/oder Akteuren verlinkt werden. 11

12 Beispiel für ein Anwendungsfalldiagramm Erläuterungen Die gedachte Firma hat sowohl Privat- als auch Geschäftskunden. Diese werden unter dem Begriff Kunde zusammengefasst, haben aber unterschiedliche Eigenschaften. Die Generalisierungen unter den Akteuren auf der linken Seite zeigen diesen Umstand. Der Akteur Kunde kann den Geschäftsprozess Kfz reservieren auslösen, der auch über eine integrierte -Bestätigung verfügt (include). Natürlich sind sowohl Kunde als auch Mitarbeiter am Geschäftsprozess Kfz vermieten beteiligt, der durch den Geschäftsprozess Kfz-Zubehör vermieten in seiner Funktionalität erweitert wird. Der Kfz-Mitarbeiter ist am Geschäftsprozess Kfz reservieren beteiligt (klar). Unten rechts findet sich ein Beispiel für eine Notiz, die mit dem Akteur Kfz-Mitarbeiter verlinkt ist. Beschriftungen über Label wurden hier nicht vorgenommen. Diese erscheinen als Text an den Assoziationen. Findung der Anwendungsfälle Um die Anwendungsfälle zu finden, geht man wie folgt vor: Geschäftsprozesse werden von einem Ereignis ausgelöst und enden mit einem Ergebnis. Zum Beispiel wäre in diesem Fall der Wunsch eines Kunden nach einer Reservierung das auslösende Ereignis und die Reservierung das Ergebnis. Sowohl Auslöser als auch Ergebnis müssen eindeutig festgelegt sein! Anwendungsfälle sind abstrakt. Sie sind daher unabhängig von konkreten Möglichkeiten und technischer Umsetzung. In den Anwendungsfällen spielt es keine Rolle, ob der Kunde einen VW Golf oder einen Raumgleiter reservieren möchte diese Beschränkungen werden erst später berücksichtigt. 12

13 Textuelle Beschreibung Zu einem Anwendungsfalldiagramm gehört auch eine textuelle Beschreibung in Tabellenform. Diese ergänzt das Diagramm, ermöglicht eine detaillierte Beschreibung und bietet zusätzliche Möglichkeiten. Beispiel für eine textuelle Beschreibung Beschreibung des Anwendungsfalls Name (Use Case) Kurzbeschreibung Auslöser oder Motivation Ergebnis Akteure Eingehende Informationen Vorbedingungen Nachbedingungen Kfz reservieren Kunde reserviert ein Kfz Kunde wendet sich mit dem Wunsch nach einer Reservierung an die Firma Für den Kunden wird ein Kfz reserviert Kunde Kundennr., Kundendaten, Reservierungswunsch Keine Es wurde ein Kfz für den Kunden reserviert Ablaufschritte Kunde identifizieren Reservierungswunsch aufnehmen Reservierung prüfen Kfz reservieren Reservierung bestätigen Achtung! Textuelle Beschreibung ist nicht klausurrelevant, sondern nur der Vollständigkeit halber hier! 13

14 3.5 Das Aktivitätsdiagramm (activity) Aktivitätsdiagramme beschreiben in UML einen Ablauf. Es handelt sich dabei um die Schritte der Anwendungsfälle, wobei Bedingungen und Sonderfälle berücksichtigt werden. Aktivitätsdiagramme bestehen aus einer Reihe von Knoten, die miteinander verbunden sind. Im UML 2.0-Standard gilt: Aktivität Aktivitätsdiagramm Aktion Ablaufschritt Die Notation Aktionsknoten Abgerundetes Rechteck. Aktionsknoten stellen einen Ablaufschritt dar und werden mit einem Substantiv und einem Verb bezeichnet. Objektknoten Gibt ein Objekt an und kann als ein- oder ausgehender Parameter genutzt werden. Startknoten (Kontrollknoten) Zeigt den Anfang einer Aktivität bzw. des Diagramms an Endknoten (Kontrollknoten) Das Gegenteil vom Startknoten, zeigt also das Ende an Ablaufende (Kontrollknoten) Zeigt das Ende eines einzelnen Kontrollflusses an Entscheidung, Zusammenführung oder beides (Kontrollknoten) Mit einer Raute wird eine Entscheidung, eine Zusammenführung oder beides dargestellt (genauere Informationen nächste Seite) Teilung, Synchronisation oder beides (Kontrollknoten) Mit einem Balken wird eine Teilung, eine Synchronisation oder beides dargestellt (genauere Informationen nächste Seite) Signal senden/gesendetes Signal Benachrichtigung über ein Ereignis wird verschickt Signal empfangen/empfangenes Signal Benachrichtigung über ein Ereignis löst einen Kontrollfluss aus 14

15 Teilungen, Synchronisationen Von links nach rechts: Teilung (Splitting) Ein Wert geht als Eingangsparameter hinein, zwei gehen hinaus. Beispielsweise könnte man so den Preis einer Ware in Warenwert und Mehrwertsteuer teilen. Synchronisation (und) Das Gegenteil der Teilung ist die Synchronisation. Hier wäre ein gutes Beispiel das addieren der Mehrwertsteuer zum Warenwert, da aus zwei Eingangsparametern ein Ausgangsparameter gemacht wird. Teilung und Synchronisation Eine Kombination der beiden vorherigen Kontrollknoten. Eigentlich müsste dieser Kontrollknoten Synchronisation und Teilung heißen. Ein Beispiel wäre vielleicht ebenfalls, dass als Eingangsparameter Warenwert und Mehrwertsteuer synchronisiert werden und als Ausgangsparameter der Endpreis und die Mehrwertsteuer hinausgehen (wenn man sie dem Kunden anzeigen will). Spezifizierte Synchronisation Hier handelt es sich um eine Art der logischen Verknüpfung. Drei Eingangsparameter gehen hinein, nur einer kommt hinaus. Nehmen wir an, dass es sich bei den drei Eingangsparametern um boolean-werte handelt, die als Beispiel die Werte A = true, B = false und C = true annehmen, dann müsste als Ausgangsparameter ein true herauskommen ( ( w f) ( w w) ergibt ( f w) und das ist natürlich wahr). Das soll aber nur ein Beispiel sein. 15

16 Entscheidungen und Zusammenführungen Von links nach rechts: Entscheidung Von oben kommt ein Eingangsparameter (hier: x) in die Entscheidung. Die drei Pfeile stehen für bestimmte Wege, die der Aktivitätsfluss nehmen kann. Links entspräche der Tatsache, dass x < 0 ist. Rechts entspräche der Tatsache x > 0, während unten für x = 0 stehen würde. Diese Entscheidung in UML entspricht einer if-else if-else-struktur. Zusammenführung (oder) Die drei Eingangsparameter werden sozusagen mit einem logischen oder verknüpft. Ein Beispiel wäre, dass ein Entwickler drei Benutzereingaben erwartet. Sobald auch nur eine davon ausbleibt, möchte er eine Fehlermeldung ausgeben. Also wären die drei Eingangsparameter entsprechende Werte, die kontrollieren würden, ob eine Eingabe ausgeblieben ist und der Ausgangsparameter der Weg zur Fehlermeldung (etwas umständlich, zugegeben, aber was besseres fiel mir grad nicht ein). Entscheidung und Zusammenführung Die Kombination der beiden vorherigen Kontrollstrukturen. Am linken Pfeil steht x<0, am rechten x>0. Swimlanes Swimlanes bezeichnen Verantwortungsbereiche innerhalb eines Aktivitätsdiagramms. Sie werden beispielsweise nach Sachverhalten oder Aufgabenbereichen/Fachbereichen getrennt. 16

17 Beispiel für ein Aktivitätsdiagramm Der Benutzer (der sich bereits registriert hat, klar) möchte sich am System anmelden. Dazu muss er seine Benutzerdaten, also Benutzername und Passwort, eingeben. Hat er dies getan, wird zunächst der Benutzername überprüft. Ist er in der Datenbank nicht vorhanden, also falsch, geht es zum Ausgangspunkt zurück. Ist der Benutzername in Ordnung, wird das Passwort geprüft. Ist dieses falsch, geht es wieder zurück zum Ausgangspunkt. Ist das Passwort korrekt, wird eine Willkommensmeldung ausgegeben und der Benutzer ist am System angemeldet. Anmerkung: Das ist nicht unbedingt ein Beispiel aus der Realität, da hier nur ein Bruchteil dessen gezeigt wird, was bei einem reellen Login, beispielsweise bei einem Forum, tatsächlich passiert. Als Beispiel sollte es aber reichen. 17

18 Testfälle Unter Testfällen versteht man detaillierte Anforderungen an die Abläufe im Aktivitätsdiagramm. Sie stellen die Vollständigkeit der Abläufe sicher. Pro Kontrollfluss gibt es einen Testfall, wobei alle Pfade und Varianten durchlaufen werden müssen. Es kann auch vorkommen, dass ein Testfall eine neue Aktion zur Folge hat (es kann ja immer passieren, dass beim Erstellen des Diagramms ein wichtiger Punkt vergessen wurde). Testfälle decken also praktisch die möglichen Situationen ab, die ein Kontrollfluss im Betrieb des Projekts zu bewältigen haben könnte. Beispiel für Testfälle Benutzername prüfen Benutzername nicht gefunden Benutzername gefunden Passwort prüfen Passwort falsch Passwort richtig Diese Testfälle würden also bedeuten, dass die Entwickler das System/Projekt auf vier Fälle testen müssten: Sie geben jeweils einen falschen und einen richtigen Benutzernamen ein, gleiches gilt für das Passwort. Andere Anwendungsfälle sind beispielsweise: Spezielle Eingabedaten für Algorithmen (z.b. 0, 1, negative Zahlen, etc.). Achtung! Ableitung der Testfälle aus dem Aktivitätsdiagramm ist nicht klausurrelevant und nur der Vollständigkeit halber hier! 18

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

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

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

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

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

Mehr

Vorlesung Programmieren

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

Mehr

UML (Unified Modelling Language) von Christian Bartl

UML (Unified Modelling Language) von Christian Bartl UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

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

Mehr

IT-Projekt-Management

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

Mehr

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

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

Mehr

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

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

Mehr

Software-Lebenszyklus

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

Mehr

Software- und Systementwicklung

Software- und Systementwicklung Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

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

Mehr

Software-Engineering

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

Mehr

Vorlesung Programmieren

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

Mehr

Unified Modeling Language 2

Unified Modeling Language 2 Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was

Mehr

Analyse und Modellierung von Informationssystemen

Analyse und Modellierung von Informationssystemen Analyse und Modellierung von Informationssystemen Dr. Klaus Höppner Hochschule Darmstadt Sommersemester 2013 1 / 18 UML Einführung Klassendiagramme in der UML Relationen zwischen Klassen 2 / 18 UML: Grundsätzliches

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

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:

Mehr

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

Mehr

Software-Engineering

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

Mehr

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

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

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

Ü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

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

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

Softwarearchitekturen I Softwareentwicklung mit Komponenten

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

Mehr

Die Unified Modeling Language UML

Die Unified Modeling Language UML Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 4 Die Unified Modeling Language UML Universität Zürich Institut für Informatik Inhalt 4.1 Hintergrund 4.2 Grundkonzepte der UML 4.3 Die Rolle

Mehr

Methodische objektorientierte Softwareentwicklung

Methodische objektorientierte Softwareentwicklung Methodische objektorientierte Softwareentwicklung Eine Integration klassischer und moderner Entwicklungskonzepte von Mario Winter 1. Auflage Methodische objektorientierte Softwareentwicklung Winter schnell

Mehr

Softwaretechnik SS 2006

Softwaretechnik SS 2006 Softwaretechnik SS 2006 7. Vorlesungseinheit Prof. Dr. Urs Andelfinger Darmstadt, 22. Mai 2006 Softwaretechnik (SWT) Vorlesung und Praktikum SS 2006 Inhaltsübersicht SW-Management SW-Entwicklung SW-Qualitätsmgmt.

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

Einführung in die Informatik

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

Mehr

Gliederung des Vortrages

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

Mehr

12. Vorgehensmodelle Softwaretechnik (CNAM)

12. Vorgehensmodelle Softwaretechnik (CNAM) 12. Vorgehensmodelle Softwaretechnik (CNAM) Wintersemester 2011 / 2012 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Einordnung in den gesamten Kurs 1. Einführung 2. Analyse: Anforderungen

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

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

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

Mehr

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

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

Mehr

UML 2.0 Das umfassende Handbuch

UML 2.0 Das umfassende Handbuch Christoph Kecher V.-M \MM UML 2.0 Das umfassende Handbuch Galileo Computing Inhalt Vorwort 11 1 Einführung 13 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3 Die Geschichte

Mehr

Das umfassende Handbuch

Das umfassende Handbuch Christoph Kecher UML 2.0 Das umfassende Handbuch. Jfjf- Ali' ' w v^i* >" '-«(."', Galileo Press Inhalt Vorwort 11 1 Einführung 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3

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

Vorlesung Software-Engineering I

Vorlesung Software-Engineering I Vorlesung Software-Engineering I im 3. und 4. Semester 05. Basiskonzepte Sichten auf das Produkt PD-TES/Hoyer, Frank-Michael SWE1: 05. Basiskonzepte - Sichten 16. Juli 2010 geändert: 4. Oktober 2013 SW-Architektur

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

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

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

Mehr

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

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes Dozent: G.Döben-Henisch (Version vom 16.April 2005) PPmP VL2 VL2: Softwareprojekt - Anforderungsanalyse Inhalt 1. Struktur eines Softwareprojektes 2. Anforderungsanalyse 1. Struktur eines Softwareprojektes

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

Objektorientierte Softwareentwicklung

Objektorientierte Softwareentwicklung Objektorientierte Softwareentwicklung Analyse- und Designmethoden Analyse- & Designmethoden Strukturierte, traditionelle Methoden Objektorientierte Methoden Funktionsorientierte Methoden Datenorientierte

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

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

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

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

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

Mehr

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

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

Vortrag von: Ilias Agorakis & Robert Roginer

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

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

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

Anforderungsanalyse, Requirements Engineering

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

Mehr

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

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

Software-Engineering

Software-Engineering SWE43 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML SWE43 Slide 2 UML: Was ist das? UML = Unified Modelling Language ist ein Standard,

Mehr

Christoph Kecher UML2. Das umfassende Handbuch. Galileo Press

Christoph Kecher UML2. Das umfassende Handbuch. Galileo Press Christoph Kecher UML2 Das umfassende Handbuch Galileo Press Vorwort 11 TEIL I Strukturdiagramme i '...,....,...,.;..,,,...,, 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für

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

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

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

Ü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

Verfeinerung der Use Case-Dokumentation

Verfeinerung der Use Case-Dokumentation Verfeinerung der Use Case-Dokumentation 4.3 Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze

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

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

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

Mehr

1. Grundbegriffe des Software-Engineering

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

Mehr

Softwaretechnik 2015/2016

Softwaretechnik 2015/2016 Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon

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

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

Unified Modeling Language (UML )

Unified Modeling Language (UML ) Unified Modeling Language (UML ) Seminar: Programmiersprachenkonzepte Inhalt Einleitung UML 2.0 Diagrammtypen 2 Einleitung Objektorientierte Modellierungssprache Definiert vollständige Semantik Dient der

Mehr

Quality is our Passion!

Quality is our Passion! Quality is our Passion! Quality is our Passion! Quality is our Passion! 2 Knowledge Department ist ein Dienstleistungsunternehmen im Software-Entwicklungs-Bereich. Das Serviceangebot umfasst Trainings,

Mehr

Folien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 4: Modellierung von betrieblichen Informationssystemen

Folien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 4: Modellierung von betrieblichen Informationssystemen Folien zum Textbuch Kapitel 2: Planung, Entwicklung und Betrieb von IS Teil 4: Modellierung von betrieblichen Informationssystemen Textbuch-Seiten 209-245 WI Planung, Entwicklung und Betrieb von IS IS-Modellierung

Mehr

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller Leistungen,

Mehr

Software Engineering (SE)

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

Mehr

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel Jason T. Roff UML IT Tutorial Übersetzung aus dem Amerikanischen von Reinhard Engel Inhaltsverzeichnis Inhaltsverzeichnis Einführung 11 Grundlagen der UML 15 Warum wir Software modellieren 16 Analyse,

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

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

Mehr

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

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

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Manfred Thaller WS 2010/11 Referentin: Sanja Wiechmann

Mehr

Software Engineering und Projektmanagement

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

Mehr

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann

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

Mehr

Objektorientierte Analyse (OOA) Inhaltsübersicht

Objektorientierte Analyse (OOA) Inhaltsübersicht Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der

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

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

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

Mehr

Kundenanforderungen dokumentieren

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

Mehr

Objektorientierte Softwareentwicklung

Objektorientierte Softwareentwicklung Objektorientierte Softwareentwicklung Grundkonzepte der UML Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus sind viele Teile direkt aus der Vorlesung

Mehr

Software-Entwicklung

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

Mehr

RUP Analyse und Design: Überblick

RUP Analyse und Design: Überblick Inhaltsverzeichnis Übersicht [, 2, 8] 3. Vorgehensweise............................... 5 2 Planungsmethoden 37 2. Definitionsphase.............................. 6 3 Rational Unified Process [5, 6] und

Mehr

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

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

Mehr

Phasen der Softwareentwicklung

Phasen der Softwareentwicklung Frühe Dipl. Wirtsch. Ing. Alexander Werth 5-1 Phasen der Softwareentwicklung Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung 5-2 Problemdefinition Worum geht

Mehr

Von UML 1.x nach UML 2.0

Von UML 1.x nach UML 2.0 Zürich Soft Summer 2005 Fortgeschrittene Aspekte der Software Technologie Von UML 1.x nach UML 2.0 Prof. Dr. Martin Glinz www.ifi.unizh.ch/req Ergänzendes Material zur Vorlesung Spezifikation und Entwurf

Mehr

Software Entwicklung 2. Lastenheft / Pflichtenheft

Software Entwicklung 2. Lastenheft / Pflichtenheft Software Entwicklung 2 Lastenheft / Pflichtenheft Inhalt Einführung & Überblick Lastenheft Glossar Pflichtenheft 2 Lernziele Erläutern können was ein Lastenheft, Glossar, Pflichtenheft ist Die Funktionen

Mehr