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

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

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

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

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

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

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

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

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

Ü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

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

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

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

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

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

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

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

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

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

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

Ü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

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

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

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

Software Engineering. 2. Requirements Engineering. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering. 2. Requirements Engineering. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 2. Requirements Engineering Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 2. Requirements Engineering 2 Definitionen Anforderungen (Requirements) legen fest,

Mehr

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

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

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

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

Software Engineering

Software Engineering Software Engineering Einführung in das Software Engineering Ein Tutorial von Wirtschaftsinformatik-24.de Inhaltsverzeichnis Einleitung 2 Ziele vom Software Engineering.2 Prinzipien, Methoden und Verfahren..3

Mehr

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

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

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

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

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

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

Zusammenfassung. Software Engineering 1 WS 2010/11. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig

Zusammenfassung. Software Engineering 1 WS 2010/11. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig Zusammenfassung Software Engineering 1 WS 2010/11 Dr.-Ing. Ina Schaefer Software Systems Engineering TU Braunschweig Ina Schaefer SE 1 - WS 2010/11 1 Inhalte Vorgehensmodelle Anforderungsanalyse Objektorientierte

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

Weiterführende Literatur

Weiterführende Literatur Literatur [Art.Metriken06] Artikel Messbare Qualität in Anforderungsdokumenten. Veröffentlicht in: Java Magazin 1/2006. Manage IT! 2/2006. ObjektSPEKTRUM 4/2006. [Bandler94] Richard Bandler (1994) Metasprache

Mehr

Zusammenfassung. Software Engineering 1 WS 2011/12. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig

Zusammenfassung. Software Engineering 1 WS 2011/12. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig Zusammenfassung Software Engineering 1 WS 2011/12 Dr.-Ing. Ina Schaefer Software Systems Engineering TU Braunschweig Ina Schaefer SE 1 - WS 2011/12 1 Inhalte Vorgehensmodelle Anforderungsanalyse Objektorientierte

Mehr

Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli

Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli Inhaltsverzeichnis 1 Rückblick auf Requirements Engineering Teil 1... 2 1.1 Was ist Requirements

Mehr

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Alistair Cockburn Use Cases effektiv erstellen Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Die Regeln für Use Cases sicher beherrschen A Abdeckung Grad der 163

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 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 5. UML Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 5. UML 2 Unified Modeling Language (UML) Standardisierte grafische Notationen um Strukturen und Abläufe eines

Mehr

UML 2.0 Quelltextgenerierung

UML 2.0 Quelltextgenerierung UML 2.0 Quelltextgenerierung Seminararbeit im Fach Informatik im Rahmen des Seminars Sicherheitskritische Systeme an der Universität Siegen, Fachgruppe für Praktische Informatik eingereicht bei Dr. Jörg

Mehr

Erstellung eines Pflichtenhefts (I)

Erstellung eines Pflichtenhefts (I) 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

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

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Die Phasen der Software-Entwicklung

Die Phasen der Software-Entwicklung Die Phasen der Software-Entwicklung c OSTC GmbH, T. Birnthaler 2011-2015 V1.7 [sw-entwicklung-phasen.txt] 1 Übersicht Die Entwicklung von Software im Rahmen eines Projekts umfasst im wesentlichen die Phasen

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

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

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

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

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

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

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

Inhalte von Lasten- und Pflichtenheften im OO- Umeld

Inhalte von Lasten- und Pflichtenheften im OO- Umeld 7. Projektdokumentation Dokumentenarten Inhalte von Lasten- und Pflichtenheften im OO- Umeld Technische Dokumentation 161 Grundsätzliches Die benötigte Dokumentation hängt stark von der Projektart ab,

Mehr

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

Mehr

Ziel der Software-Technik

Ziel der Software-Technik Vorlesung: Softwaretechnik I II. Software-Qualität Prof. Dr. Jens Grabowski Email Tel. 39 14 690 grabowski@cs.uni-goettingen.de SoftwEng (SS 07) II-1 Ziel der Software-Technik ist die effiziente Entwicklung

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

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

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

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

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

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

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

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

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Klausur Software Engineering für WI (EuI)

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

Mehr

Pflichtenheft Programmanwendung "Syntax Tool"

Pflichtenheft Programmanwendung Syntax Tool Projekt: Syntax Tool Autor: Michael Rattun Home: www.mrattun.de Letzte Änderung: 27.10.2011 1 SEITE Syntax Tool Inhaltsverzeichnis Inhaltsverzeichnis 1. Zielbestimmung... 3 1.1 Muss-Kriterien (Freeware)...

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

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

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

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

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer Modulbeschreibung Programmierung II / Software Engineering II Modulname Programmierung II / Software Engineering II Modulnummer -1.2 Inhalt Programmierung II Software Engineering II Grundlagen der objektorientierten

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

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

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

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

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11 xiii 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Fundamentaler Testprozess 11 2.1 Testplanung und -steuerung........................

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

Pflichtenheft. Software Engineering I WS 2011/2012. Dr.-Ing. Ina Schaefer 1. Software Systems Engineering TU Braunschweig

Pflichtenheft. Software Engineering I WS 2011/2012. Dr.-Ing. Ina Schaefer 1. Software Systems Engineering TU Braunschweig Pflichtenheft Software Engineering I WS 2011/2012 Dr.-Ing. Ina Schaefer 1 Software Systems Engineering TU Braunschweig 1 Folien von Prof. P. Liggesmeyer (TU Kaiserslautern und Fraunhofer IESE) Ina Schaefer

Mehr

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

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

Geschäftsprozesse modellieren mit Innovator Business

Geschäftsprozesse modellieren mit Innovator Business Geschäftsprozesse modellieren mit Innovator Business I N H A L T 1. Motivation und Begriffsklärung 2. Kurzeinführung in die Geschäftsprozessmodellierung 3. Anwendungsszenarien der GPM 2 Was Geschäftsprozessmodellierung

Mehr

Methodenbasiert in der Durchführung V-Modell XT-konform im Ergebnis

Methodenbasiert in der Durchführung V-Modell XT-konform im Ergebnis Methodenbasiert in der Durchführung V-Modell -konform im Ergebnis - 1 - So? oder gibt es einen anderen Weg? - 2 - Die Werkzeugfamilie Business professionelle Geschäftsprozessmodellierung mit UML Object

Mehr

SysML Die Zukunft des Systems Engineering?

SysML Die Zukunft des Systems Engineering? ECC 2012 Winterthur 5. Juni 2012 SysML Die Zukunft des Systems Engineering? Omar Naas, Senior Consultant, EVOCEAN GmbH 1934 Citroën 2CV Citroën Direktor Pierre-Jules Boulanger definierte 7 Anforderungen,

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

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

Vorlesungsveranstaltung

Vorlesungsveranstaltung Vorlesungsveranstaltung Softwareengineering Dipl.-Inform. Adriano Gesué Gesue@t-online.de Vorlesungsübersicht Inhalte Einführung Software und Softwareengineering Vorgehensmodelle Klassische Entwurfsmethoden

Mehr