Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme

Größe: px
Ab Seite anzeigen:

Download "Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme"

Transkript

1 Die Bedeutung expliziter Modellierung für die Entwicklung komplexer und langlebiger Software-Systeme Markus Pizka, Tilman Seifert TU München Marcus Peisker BMW Group Die Entwicklung von Software stellt immer eine Form von Modellierung dar: Ein Ausschnitt der realen Welt wird herausgegriffen und mit Hilfe einer formalen Beschreibungssprache, spätestens mit einer Programmiersprache, beschrieben. Der Nutzen expliziter Modellierung mit Hilfe textueller oder grafischer Modellierungssprachen ist erstaunlicherweise umstritten. Dieses Papier zeigt, warum sich der explizite Einsatz von Modellierungsmethoden für die Software-Entwicklung lohnt. 1 Einleitung Ein Modell ist eine Abstraktion eines bestimmten Ausschnittes der realen Welt oder eines anderen Modells. Es beschreibt einen bestimmten Aspekt dieses Ausschnitts präzise und abstrahiert dabei von anderen Aspekten, die zur Analyse im Moment nicht von Bedeutung sind. Software-Entwicklung ist immer Modellierung: Ein Ausschnitt unserer realen Umgebung wird in ein Software-System abgebildet und mit formalen Sprachen, d. h. Programmiersprachen, beschrieben. Ein Software-System ist nichts anderes als ein Modell der Begriffe, Objekte oder Vorgänge, für deren Verwaltung bzw. Unterstützung es entwickelt wurde. Ein einfaches Beispiel stellt die Kundenverwaltung in einem betrieblichen Informationssystem dar: Der Kunde wird modelliert, indem alle für das Unternehmen relevanten Daten des Kunden im System verarbeitet werden. Die Beziehung des Unternehmens zum Kunden wird in Form der bisher erteilten Aufträge oder eines Protokolls der bisherigen Kontakte modelliert. Im Entwicklungsprozess werden in jeder Phase, von der Anforderungsanalyse über die Implementierungsphase bis zum Testen, auf jeden Fall Modelle erstellt entweder explizit in Form von textuell oder grafisch beschriebenen Modellen, oder auch nur implizit in Form von Freitext oder auch einfach in den Köpfen der Entwickler. Im Falle von impliziten Modellen mag das unbewusst sein, dennoch entstehen Modelle, die für die Entwicklung verwendet werden. Bei der Entwicklung von großen, komplexen oder langlebigen Systemen stellt sich daher nicht die Frage, ob überhaupt modelliert werden muss, sondern nur die Frage, in welcher Form und zu welcher Zeit im Projekt welche Aspekte explizit modelliert werden, also als Modell notiert werden. Kapitel 2 klärt, was in diesem Papier genau unter Modellierung verstanden wird, was die Ziele sind und welche Eigenschaften Modelle erfüllen müssen. Kapitel 3 zeigt die Integration expliziter Modellierung in den Entwicklungsprozess und stellt die gängigsten Modellierungstechniken vor. Kapitel 4 zeigt eine Reihe von Charakteristika auf, die für viele Projekte gelten und analysiert den Bedarf an expliziter Modellierung für derartige Projekte. 2 Was ist Modellierung? Modellierung bedeutet, sich ein Bild zu machen von der Realität oder eine kondensierte Sicht auf ein abstraktes Gebilde zu schaffen. Um bestimmte Aspekte besser verstehen und erklären zu können, muss von anderen Aspekten abstrahiert werden. Modellierung bedeutet die Verein-

2 fachung von komplexen Zusammenhängen bzw. Abstraktion und dient der Konzentration auf bestimmte Eigenschaften, um diese präzise analysieren und beschreiben zu können. Bei der Zusammenarbeit von n Experten, die über ein komplexes Software-System aus m unterschiedlichen Perspektiven sprechen, sind gute Modelle unerlässlich. 2.1 Zentrale Ziele der Modellierung Die Ziele der expliziten Modellierung lassen sich wie folgt zusammenfassen: 1. Verständnis der fachlichen Anforderungen, der technischen Umgebung und der Randbedingungen der zu erstellenden Lösung schaffen oder erleichtern. Je komplexer das zu entwickelnde System ist, umso wichtiger wird die Modellierung einzelner Aspekte. 2. Kommunikation mit und Verständnis für andere durch einfache, präzise Dokumentation, die zu jedem Zeitpunkt auf dem aktuellsten Stand ist. Insbesondere für langlebige Systeme ist entscheidend, wie gut das System auch im Falle von Mitarbeiter-Fluktuation verstanden, gewartet und weiterentwickelt werden kann. 3. Automatisierung im Entwicklungsprozess, z. B. konsistente Generierung von Code, Tests und Dokumentation aus einem Modell oder automatische Konsistenz- oder Korrektheitsprüfungen. Bei großen Systemen kann mit Hilfe von Automatisierung nicht nur Mehrarbeit gespart, sondern gleichzeitig eine ganze Klasse von Fehlern ausgeschlossen werden. Um dies zu gewährleisten, ist ein hohes Maß an Präzision erforderlich; das begründet auch den Formalisierungsgrad von Syntax und Semantik von Modellen. Die Ziele sind also sowohl in der Effizienz der Entwicklung als auch in der Qualität der Software begründet. 2.2 Forderungen an Modelle Die genannten Ziele sind nur erreichbar, wenn für die Verwendung von Modellen ein gemeinsames Modellverständnis vorliegt. Daher wird von Modellen eine eindeutige Notation verlangt, die als (semi-) formale Sprache definiert ist. Dies kann eine textuelle oder eine grafische Notation sein. So wird eine eindeutige Syntax zur Darstellung definiert. Zusätzlich ist die Definition der Semantik erforderlich, damit das Modell sowohl zur Kommunikation als auch zur Automatisierung genutzt werden kann. Weiterhin fordern wir von einem Modell, dass es sich auf einen sinnvoll abgegrenzten Aspekt des Systems bezieht, um das Verständnis dieses speziellen Aspektes zu erleichtern. Modelle sollen genau den entscheidenden Aspekt isoliert beschreiben können. Dies umfasst sowohl horizontal verschiedene Sichten, also Modelle unterschiedlicher Aspekte des Systems, als auch vertikal verschiedene Sichten, also unterschiedliche Abstraktionsstufen des Systems. Ersteres ist erforderlich zur vollständigen Modellierung des Systems, letzteres zur schrittweisen Verfeinerung. Explizite Modelle sind nur dann sinnvoll, wenn dem (Zusatz-) Aufwand, der durch ihre Erstellung entsteht, ein entsprechender Nutzen gegenübersteht. Die hier genannten Forderungen zielen auf einen solchen Nutzen ab: So ist z. B. die verbesserte, eindeutige Kommunikation von Systemeigenschaften ein direkter Nutzen, denn früh erkannte Missverständnisse können einfach ausgeräumt werden später im Projektverlauf wird es deutlich teurer, wie Abbildung 1 zeigt (vgl. z. B. [5]). Dazu muss die Modellierung in den gesamten Prozess der Entwicklung und Betreuung integriert sein; diese Fragestellung wird im Abschnitt 3 untersucht. 2

3 Abbildung 1: Kosten je Fehler, abhängig vom Zeitpunkt der Entdeckung (aus [5, S. 114]) 2.3 Modelltypen Es existieren unterschiedliche Modellierungstechniken, um unterschiedliche Aspekte besonders herauszuarbeiten. Sie können etwa in die folgenden Gruppen eingeteilt werden. Darstellung statischer Strukturen: Architektur, Klassendiagramme, ER-Diagramme Darstellung von Abläufen. Hier dienen z. B. Petri-Netze, Agenten, Sequenz-Diagramme oder Use Case-Diagramme. Abbildung der Kommunikationsstruktur zwischen Sub-Systemen Weitere Aspekte, wie z. B. Darstellung von Sicherheits- oder Performance-Eigenschaften: Solche zusätzlichen, nichtfunktionalen Anforderungen können prinzipiell auf zwei Wegen gelöst werden: Durch Ergänzungen zu vorhandenen Modellierungstechniken, oder durch neue Modelltypen, die genau diesen speziellen Aspekt modellieren. Beispielsweise kann die Sicherheit (security) einer Kommunikationsverbindung zwischen zwei Systemen durch zusätzliche Angaben zur Angreifbarkeit der Verbindung modelliert werden. In der Regel werden Modelle jeder Gruppe benötigt, um ein System umfassend zu beschreiben. Dies ist die horizontale Unterscheidung verschiedener Modelle. Man unterscheidet weiterhin zwischen formalen und semi-formalen Modellierungsmethoden. Für ein formales Modell sind sowohl Syntax als auch Semantik exakt definiert; im Gegensatz dazu besitzt die Semantik eines semi-formalen Modells noch gewisse Freiheitsgrade. Daher sind semi-formale Modellierungstechniken in der Regel leichter zu entwickeln. Mathematisch formale Modelle besitzen allerdings den Vorteil, dass ihre Semantik klar ist und sie so ein eindeutiges Verständnis ohne Interpretationsspielraum ermöglichen. Zudem können sie dann auch automatisch verarbeitet werden, z. B. zur Vollständigkeits- oder Konsistenzprüfung. 3

4 Der Nutzen eines Modells in der jeweiligen Situation hängt von der Lesbarkeit eines Modells ab. Die Lesbarkeit ist unabhängig vom Grad der Formalisierung. Die Aussagekraft eines Modells hängt vor allem von der Angemessenheit der Modellierungstechnik im jeweiligen Zusammenhang ab, eventuell auch noch vom Geschick oder der Übung des Modellierers. Entscheidend ist, wie präzise ein Modell die betrachteten Aspekte beschreiben kann. Modelle können textuell oder grafisch notiert werden. Große Bedeutung haben vor allem Modelle mit grafischen Notationen, die den Vorteil besitzen, dass sie die große Bandbreite des visuellen Kanals beim Menschen und seine Fähigkeit zur assoziativen Mustererkennung ausnutzen und einen wahlfreien Zugriff gestatten. (vgl. [3] und [6]). Jedoch können grafisch notierte Modelle den Text nicht vollständig ersetzen. Für das Verständnis eines grafischen Modells ist oft noch zusätzlicher, erläuternder Text notwendig. 2.4 Bewertung von Modellierungstechniken Modellierungstechniken werden anhand folgender Kriterien bewertet: 1. Bewusste Durchführung der Modellierung: Da Modellierung in jedem Fall stattfindet, sollten Modelle bewusst entwickelt werden und die Modellierung als fester Bestandteil in den Entwicklungsprozesses integriert werden. 2. Explizite Formulierung: Explizit notierte Modelle können in Reviews beurteilt und in Folgephasen und/oder zur Dokumentation herangezogen werden. 3. Präzisionsgrad des Modells: Je nach Modellierungstechnik kann ein gewisser Interpretationsspielraum existieren. Im Umgang mit komplexen Systemen sollte dieser jedoch möglichst gering sein. Ein präzises, mathematisch formales Modell kann zudem in Folgephasen leichter weiterverwendet werden. 4. Angemessenheit der Modellierungstechnik: Für die Auswahl der geeigneten Modellierungstechnik sind der genaue Einsatzzweck und der erwartete Nutzen zu berücksichtigen. Werden die Modelle zur Kommunikation mit dem Kunden eingesetzt, sind unter Umständen andere Prioritäten zu setzen als für Modelle, die ausschließlich im Entwicklerteam bearbeitet werden. 3 Modellierung in Entwicklung und Wartung Ein guter Entwicklungsprozess unterstützt die Transparenz jedes Projektes, fördert die Kommunikation zwischen allen Projektbeteiligten und führt zu einem geplanten Vorgehen. Siehe dazu auch [10]. Aktivitäten der Modellierung müssen in den Prozess integriert sein, und die Ergebnisse (die Modelle) müssen in Folgephasen zur Weiterentwicklung, zur Erhöhung der Qualität und zur Dokumentation verwendbar sein. Dies gilt unabhängig vom verwendeten Prozess sowohl für klassische als auch für agile Prozesse. Prozesse wie z. B. der Rational Unified Process (RUP) [8] sehen die Modellierung explizit als festen Bestandteil in der Software-Entwicklung vor. Aber auch agile Verfahren können Modellierung effektiv einsetzen. Neben dem Vier-Augen-Prinzip des Pair Programming [2] spricht nichts gegen Pair Modeling. Gemeinsam ist allen Vorgehensweisen, dass Modelle, die im Nachhinein ausschließlich zu Dokumentationszwecken niedergeschrieben werden, nicht dieselbe Qualität erreichen wie Modelle, die zur Konstruktion der Software verwendet werden und deshalb ihren Zweck nur begrenzt erfüllen. 3.1 Tool-Unterstützung Entscheidend für den Nutzen der Modelle für die entwickelte Software und für die Effizienz im Projekt ist die Unterstützung durch Werkzeuge, welche Syntax und Semantik der Modelle ken- 4

5 nen und unterstützen. Eine Textverarbeitung kann nicht als universelles Modellierungswerkzeug herhalten genauso wenig wie alle Reparaturen am Auto mit nur einem Schraubenzieher durchgeführt werden könnten. Die Frage nach der einzusetzenden Methode kann deshalb nicht ohne die Frage nach dem eingesetzten Werkzeug beantwortet werden. Die Mächtigkeit der eingesetzten Werkzeugkette bestimmt, inwiefern Aktivitäten wie Modellierung oder Dokumentation als Erleichterung oder als Last empfunden werden. Abbildung 2 zeigt, dass Modell und Code nur dann ohne Zusatzaufwand konsistent gehalten werden können, wenn die eingesetzten Werkzeuge Round-Trip-Engineering unterstützen, d. h. dass Änderungen, die direkt am Code vorgenommen werden, automatisch in das Modell übernommen werden. Plattformunabhängig (PIM) Plattformspezifisch (PSM) Code Round-Trip Abbildung 2: Vom plattformunabhängigen Modell zum Code, hier am Beispiel der MDA 3.2 Die wichtigsten Modellierungstechniken Zu den bekanntesten und wichtigsten Modellierungstechniken zählen die im Folgenden aufgelisteten. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. Die Auswahl ist eingeschränkt auf Techniken, die relativ bekannt sind und für die adäquate Werkzeugunterstützung existiert, damit die Relevanz für den Einsatz diskutiert werden kann. UML Die Unified Modeling Language, entwickelt von Booch, Rumbaugh und Jacobson (siehe [4] oder [7]) seit Anfang der 90er Jahre, zählt heute wohl zu den am weitesten verbreiteten Modellierungssprachen. UML kennt eine Reihe verschiedener Diagramm-Typen, die sowohl statische als auch dynamische Sichten auf ein System erlauben. Für die Modellierung mit UML sind zahlreiche Werkzeuge verfügbar, die damit werben, Code- Generierung und Round-Trip-Engineering zu unterstützen, z. B. Rational Rose oder TogetherCC. Petri-Netze modellieren das Verhalten von dynamischen Systemen mit nebenläufigen und nichtdeterministischen Vorgängen [1]. GPM Geschäftsprozessmodellierung: z. B. mit eepk (erweiterte ereignisgesteuerte Prozesskette). ERM Entity-Relationship-Modelle dienen zur Beschreibung persistenter Daten und ihre Beziehungen untereinander aus fachlicher Sicht. SDL Specification Description Language. Mit der SDL werden insbesondere Kommunikationsprozesse modelliert; sie wird als Standard ( Recommendation ) von der ITU gepflegt 5

6 [11]. Der Einsatzbereich der SDL geht aber über Telekommunikation hinaus und umfasst insbesondere eingebettete Systeme. Strichzeichnungen sind schnell an die Tafel gemalt, nicht formal festgelegt und nicht unbedingt semantisch eindeutig. Sie können als semi-formale Ad-Hoc-Modellierung durchaus hilfreich sein. 3.3 Kritik an Modellierungstechniken Beispiel UML Die Modellierungsmethoden im letzten Abschnitt werden recht kontrovers diskutiert. Insbesondere UML als wohl prominentester Vertreter hat neben einer Reihe von Befürwortern auch eine nicht zu vernachlässigende Menge an Kritikern. Sie bemängeln vor allem die unzureichende Formalisierung: Die Bedeutung von Sprachelementen wird oft nicht eindeutig definiert, sondern anhand von Beispielen erklärt. Die Forderung nach einer formal festgelegten, eindeutigen Syntax und Semantik wird nicht erfüllt. Das Ziel der Modellierung ist jedoch genau die Vermeidung von Mehrdeutigkeiten und die präzise Beschreibung eines bestimmten Aspektes. Die Diagramme benötigen in der Regel zum vollständigen Verständnis nach wie vor erklärende Texte. Für die Strukturierung dieser Erläuterungen existiert keinerlei Unterstützung, und die Konsistenz zwischen Diagramm und Text kann nicht überprüft werden. Ein weiterer Kritikpunkt ist der Umfang der UML: Wohl mit aufgrund der Kommerzialisierung der UML nimmt der Umfang immer weiter zu, und es wird immer schwieriger, auf dem aktuellsten Stand zu bleiben. Diese Einwände sind sicher berechtigt. Dem sind aber dennoch einige Vorteile für den praktischen Einsatz gegenüberzustellen: Zahlreiche Werkzeuge sind verfügbar, die in den Entwicklungsprozess eingebunden werden können. Der Bekanntheitsgrad unter den Entwicklern vereinfacht den Einsatz, da ein gemeinsames Verständnis für die Semantik bereits vorhanden ist und nicht erst das gesamte Entwicklungs-Team zur Schulung geschickt werden muss. Es ist relativ leicht, neue Entwickler hinzuzunehmen (aus anderen Projekten, neu eingestellt oder von Fremdfirmen). Da das Wissen über UML in weiteren Projekten genutzt werden kann, ist eine gewisse Investitionssicherheit gegeben (sowohl bezüglich der Werkzeuge als auch des Wissens der Entwickler). UML wird kontinuierlich weiter entwickelt. Im Moment laufen die Arbeiten zur Version UML 2.0 [9]. Immer mehr für die praktische Software-Entwicklung relevante Aspekte werden berücksichtigt, wie z. B. Echtzeitfähigkeit oder Sicherheit. 3.4 Bedeutung von expliziter Modellierung für den Entwicklungszyklus Jede Phase des Entwicklungszyklus ist gekennzeichnet durch die in ihr erstellten Ergebnisse - dies können reine Textdokumente oder Programmcode oder eben auch erstellte bzw. weiterentwickelte oder verfeinerte Modelle sein. Für die Erarbeitung der Ergebnisse ist ein exaktes Verständnis der gegebenen Problemstellung bzw. der erarbeiteten Lösung erforderlich. Beim Übergang in eine neue Projektphase müssen die Ergebnisse (z. B. im Review) auch anderen Projektbeteiligten verständlich kommuniziert werden. Die nächste Projektphase kann besonders effizient durchgeführt werden, wenn die Ergebnisse automatisch oder toolunterstützt weiterverarbeitet werden können. Diese Anforderungen decken sich genau den Zielen expliziter Modellierung (s. Abschnitt 2.1). Die Erwartungen an die einzelnen Phasen des Entwicklungsprozess führen also direkt zu der Forderung, Modellierung explizit durchzuführen. Zur Bewertung der Qualität eines Entwicklungsprozesses kann das Capability Maturity Model (CMM) [10] herangezogen werden. Das CMM prüft, ob bestimmte Teilprozesse für die Software- Entwicklung auf Projekt- und auf Unternehmensebene existieren und gelebt werden und legt so eine Metrik für die Qualität der Software-Entwicklung fest. Aus den Forderungen des CMM können als Essenz die Qualitätskriterien Kommunikation, Transparenz sowie die Einhaltung eines geplanten Vorgehens herausgearbeitet werden. Explizite Modellierung trägt dazu bei, diese Qualitätskriterien zu erfüllen: 6

7 Kommunikation: Hierbei werden zwei Aspekte angesprochen. Es geht erstens um die Kommunikation innerhalb des Entwicklerteams und zwischen Entwicklern und anderen Projektbeteiligten. Zweitens ist die Erstellung von aussagekräftiger und aktueller Dokumentation für die Weiterentwicklung des Systems von Bedeutung. Die definierte Syntax von Modellen verlangt ein einheitliches Verständnis und unterstützt so die Kommunikation zwischen den Beteiligten. Aus einem Modell können z. B. Code, Testfälle, weitere Modelle oder Dokumentation (allgemein: Artefakte) erzeugt werden; so werden verschiedene Artefakte immer konsistent und auf dem neuesten Stand gehalten. Transparenz: Die Projektziele jedes Beteiligten sowie alle Entscheidungen, die für den Projektverlauf relevant sind, sowie deren Gründe müssen allen Projektbeteiligten transparent sein. Auch wenn die Transparenz insgesamt eher ein Thema der Projektkultur ist, können explizite Modelle dazu beitragen, technische Umstände zu klären und damit technische Entscheidungen transparent und verständlich zu begründen. Geplantes Vorgehen: Es werden abprüfbare und in der nächsten Projektphase direkt nutzbare Ergebnisse verlangt. Explizite Modelle haben hier gegenüber informell formulierten Dokumenten (zumindest zum Teil) den Vorteil, dass ihre Konsistenz und Vollständigkeit automatisch überprüft werden kann und damit die Projektplanung unterstützt wird. Mit diesen Eigenschaften bieten Modellierungstechniken wenn sie mit Bedacht ausgewählt und eingesetzt werden eine gute Prozessunterstützung, unabhängig vom gewählten Prozessmodell. 3.5 Pro und Kontra Modellierung Die Vor- und Nachteile von Modellierung, die als fester Bestandteil in den Entwicklungsprozess integriert wird, werden immer wieder diskutiert. Dieser Abschnitt stellt die häufigsten typischerweise ausgetauschten Argumente kurz dar und erläutert sie Pro Modellierung schafft Überblick. Modellierung wird eingesetzt zur Beschreibung von Systemen und zur Abstraktion von bestimmten Eigenschaften. Dies kann eine Top-Down-Verfeinerung von Systemen sein: Vom Domain-Chart, das den Anwendungsbereich beschreibt, bis hin zum detaillierten Klassendiagramm, aus dem der Code (oder Teile davon) generiert werden können (vertikal unterschiedliche Sichten). Die Abstraktion kann sich dabei auf beliebige Teilaspekte des Systems beziehen, wie z. B. das Verhalten bei Nebenläufigkeit o. Ä. (horizontal unterschiedliche Sichten). Modellierung mit (semi-) formalen Methoden verbessert die Kommunikation zwischen Kunde und Auftragnehmer. Falsch verstandene Anforderungen oder Prioritäten werden teurer, je später sie bemerkt werden. Hier kann (semi-) formale Modellierung helfen, die Kommunikation zwischen Kunde und Auftragnehmer zu verbessern. Dies funktioniert genau dann, wenn die Notation exakt genug ist, um eindeutiges Verständnis zu erzielen, aber noch allgemein genug verständlich, dass nicht nur der Software-Fachmann damit zu Recht kommt. Ohnehin ist bei der Kommunikation zwischen Kunde und Auftragnehmer die Verwendung eines gemeinsamen, präzisen Vokabulars essentiell. (Semi-) formale Modellierung unterstützt dies. Steigerung von Effizienz und Qualität im Entwicklungsprozess: Modelle, die frühzeitig im Prozess erstellt werden, steigern gleichzeitig sowohl die Effizienz als auch die Qualität. Denn so können eventuelle Missverständnisse früh ausgeräumt werden, Inkonsistenzen entdeckt werden, und Code und Dokumentation entstehen aus denselben Artefakten, sind also per Konstruktion konsistent. 7

8 Langfristige Kostenersparnis: Liegt zu einem Anwendungssystem nur inkonsistente oder veraltete Dokumentation vor, so werden kostspielige Reverse-Engineering-Projekte notwendig. Fachliche Zusammenhänge werden aus vorhandenen Implementierungen herausgearbeitet. Werden jedoch schon bei der Entwicklung geeignete Modellierungstechniken eingesetzt, können solche Zusatzaufgaben vermieden werden Kontra Konsistenz von Modell und System: Ohne korrekte und umfassende Dokumentation sind große Projekte langfristig nicht wartbar, erweiterbar oder anpassbar. Dokumentation (insbesondere als freier Text) ist schwierig auf dem neuesten Stand zu halten. Ein immer wieder vorgetragenes Argument gegen explizite Modellierung besagt, dass Modell und Dokumentation oder sogar Modell und Code auseinander laufen könnten und die Pflege von unnötig vielen Artefakten erforderlich mache. Dies würde Wartung und Weiterentwicklung erheblich erschweren. In einem solchen Fall wurde eine nicht adäquate Modellierungsmethode gewählt oder es e- xistiert unzureichende Werkzeugunterstützung. Konsistenz zwischen System und Dokumentation bzw. Code ist zu erhalten, wenn Änderungen nur am Modell vorgenommen werden und daraus dann sowohl die Dokumentation als auch das System erzeugt werden. Dies setzt voraus, dass die eingesetzten Werkzeuge Round-Trip-Engineering ausreichend unterstützen. Damit wird das Argument hinfällig. Modellierung ist teuer. Soll eine explizite Modellierungsmethode eingeführt werden, ist das mit Kosten verbunden: Mitarbeiter müssen geschult werden, um die Methode nutzbringend einsetzen zu können. Entsprechende Werkzeuge müssen ausgewählt und angeschafft werden, und die Mitarbeiter müssen auch im Umgang mit diesen Werkzeugen geschult werden. Schließlich muss die Modellierung in den Prozess integriert werden, was ebenfalls Kosten nach sich zieht. Projekte stehen generell unter Kostendruck und sehen eben genannten Kostenfaktoren als zu hoch an, als dass sie im Projekt getragen werden könnten. Wenn jedoch das Kostenargument angeführt wird, ist das System über seine gesamte Lebensdauer zu betrachten, nicht das einzelne Projekt. Eventuelle Einsparungen in der Wartungs- und Weiterentwicklungsphase sind in die Kostenkalkulation mit einzubeziehen. Da die Wartung und Weiterentwicklung in der Regel die Aufwände der Ersterstellung bei weitem übersteigt [5], können die Ersparnisse allein aufgrund konsistenter Dokumentation erheblich sein. Zusätzlich ist zu berücksichtigen, dass sowohl die Weiterbildung der Mitarbeiter als auch ein verbesserter Prozess die Qualität der produzierten Software erhöhen wird. Prototypen sind besser zur Veranschaulichung als Modelle. Die typischen Probleme zwischen Kunde und Auftragnehmer können mit Oberflächen-Prototypen viel besser gelöst werden als mit umfangreichen Modellen. Für die technische Realisierung sind Durchstich-Prototypen notwendig, die jedes Element der eingesetzten Infrastruktur benutzen. Dies ist jedoch kein Argument gegen Modellierung im Entwicklungsprozess, sondern lediglich für den Einsatz von Prototypen. In der Regel ist das verbunden mit iterativer Entwicklung. Auch hier werden Modelle eingesetzt. Modelle sind unter Umständen für Reviewer schwierig zu handhaben und zu überblicken. Jeder Reviewer muss mit der Modellierungstechnik vertraut sein, um die Modelle auf Konsistenz, Korrektheit bezüglich der Anforderungen und Vollständigkeit beurteilen zu können. Abhängig von der Modellierungstechnik und der Verfügbarkeit von geschulten Mitarbeitern ist dieses Argument hinfällig. 8

9 4 Welche Modelle sind für Informationssysteme relevant Dieser Abschnitt gibt einen Überblick über die Eigenschaften typischer Informationssysteme im Industrieunternehmen. Anschließend wird anhand dieser Eigenschaften der Bedarf für Modellierung diskutiert. 4.1 Charakteristika typischer Projekte Diese Studie untersucht den Bedarf für Projekte mit folgenden Charakteristika: Systeme: Die Anwendungssysteme haben eine lange Lebensdauer, in der Regel viele Jahre bis mehrere Jahrzehnte. Entwicklungsprozess: Zusammenarbeit von eigenen Entwicklern und Fremdfirmen: Viele Entwicklungsaufgaben vor allem im Bereich der Implementierung, auch im Design, werden an Fremdfirmen vergeben. Entwickler: Sowohl der Einsatz der Mitarbeiter als auch ihr Wissen ist von Bedeutung: Die Entwickler implementieren und warten nicht immer auf demselben System. Es gibt über die System-Lebensdauer immer wieder Wechsel: Mitarbeiter wechseln zu anderen Projekten oder in andere Positionen. Die Fachdomäne ist unter den eigenen Entwicklern gut verstanden, bzw. Wissen ü- ber die Unternehmensstruktur ist vorhanden. Infrastruktur: Die Infrastruktur ist relativ konstant; sie wird im zentral festgelegt. Dadurch lässt sich mit der ebenso zentral definierten Werkzeugauswahl eine optimale Unterstützung erreichen. 4.2 Benötigte Modelleigenschaften Dies legt nahe, dass eingesetzte Modelle folgende Eigenschaften aufweisen sollten: Langlebigkeit: Die Modellierungstechnik muss erwarten lassen, dass die Werkzeugunterstützung auf absehbare Zeit gegeben ist, damit erfolgreiche und effiziente Wartung und Weiterentwicklung auf lange Sicht durchgeführt werden kann. Indikatoren dafür sind beispielsweise die aktuelle Verbreitung von Wissen über die Modellierungstechnik sowie am Markt verfügbare Werkzeuge. Integration und Prozessunterstützung: Sowohl die Werkzeuge als auch Modellierungstechnik als auch die erzeugten Modelle müssen sich in den Entwicklungsprozess des Unternehmens eingliedern und in die Werkzeugkette integrieren. Vielseitigkeit von Methoden und Werkzeugen: Die Modellierungstechniken sind in verschiedenen Projekten und für verschiedene Systeme anwendbar, um das Wissen der Mitarbeiter an vielen Stellen nutzen zu können. 4.3 Erreichbarer Nutzen Durch den konsequenten Einsatz von expliziter Modellierung im Entwicklungsprozess sehen wir die Chance, die Ziele Verbesserung des Verständnisses und der Kommunikation sowie Automatisierung zu erreichen. 9

10 Oft wird angenommen, dass sich die Ziele Kosteneinsparung und Qualitätssteigerung widersprechen dies ist nicht unbedingt richtig. Wird konstruktiv bessere Qualität erreicht, führt das (mindestens mittel- und langfristig, oft aber sogar schon kurzfristig) zu Kosteneinsparungen. In den frühen Phasen können Einsparungen realisiert werden, weil alle Projektbeteiligten ein gemeinsames Verständnis erreichen; in den späteren Phasen, weil Folgephasen die Ergebnisse der vorhergehenden Phasen besser weiterverarbeiten können. Die so vermiedene Mehrarbeit schließt gleichzeitig zusätzliche Fehlerquellen aus. Auf lange Sicht wird gleichzeitig die Dokumentation verbessert, was Wartungs- und Weiterentwicklungsprojekten besser planbar macht. Damit wird nicht nur die Höhe, sondern auch die Unsicherheit von Weiterentwicklungskosten reduziert. 5 Verwandte Arbeiten und Abgrenzung Zum Teil wurde diese Diskussion schon in Verbindung mit agilen Methoden geführt. Siehe dazu z. B. [2]. In unserem Zusammenhang steht aber nicht die Optimierung der für die erstmalige Systemerstellung benötigten Zeit im Vordergrund. Der Fokus liegt vielmehr auf der langfristigen Wartung und Weiterentwicklung der Systeme, ausgedrückt durch langfristig niedrige Wartungsund Erweiterungskosten. Dieses Papier beschäftigt sich mit Informationssystemen. Inwieweit die Ergebnisse dieses Papiers im Speziellen auch auf eingebettete Systeme übertragbar sind, bleibt noch zu prüfen. 6 Zusammenfassung und Ausblick Mit der expliziten Modellierung von Software-Systemen werden im Wesentlichen die drei Ziele Verbesserung des Verständnisses und der Kommunikation sowie die Unterstützung von Automatisierung im Entwicklungsprozess verfolgt. Modellierungstechniken werden anhand von vier Kriterien bewertet: Die Modellierung kann bewusst oder unbewusst erfolgen; Modelle können implizit verwendet oder explizit notiert und eingesetzt werden; sie unterscheiden sich im Grad der Präzision; und schließlich ist immer zu untersuchen, ob die gewählte Modellierungstechnik adäquat ist. Langlebige und komplexe Informationssystemen erfordert Modellierungstechniken, die langfristig und vielseitig einsetzbar sind, über die entsprechende Tool-Unterstützung verfügen und sich so in den Entwicklungsprozess eingliedern. Anhand der Kriterien zur Bewertung von Modellierungstechniken und der Charakteristika der Projekte sind nun geeignete Modelle auszuwählen und in den Entwicklungsprozess zu integrieren. Projekte und Prozesse sind kritisch zu überprüfen, ob mit den aktuell eingesetzten Tools alle Möglichkeiten optimal ausgenutzt werden. 10

11 Literatur [1] Balzert, Helmut: Lehrbuch der Software-Technik: Software-Entwicklung. Spektrum Verlag, [2] Beck, Kent: Extreme Programming Explained Embrace Change. Addison-Wesley, [3] Bergner, Klaus: Spezifikation großer Objektgeflechte mit Komponentendiagrammen. Doktorarbeit, Technische Universität München, [4] Booch, Grady, James Rumbaugh und Ivar Jacobson: The Unified Modelling Language User Guide. Addison-Wesley, [5] Ebert, Christof und Reiner Dumke (Herausgeber): Software-Metriken in der Praxis: Einführung und Anwendung von Software-Metriken in der industriellen Praxis. Springer, [6] Endres, Albert: Werkzeuge in der Programmentwicklung. Skript zur gleichnamigen Vorlesung im WS 95/96 an der TU München, [7] Hitz, Martin und Gerti Kappel: Work: Von der Analyse zur Realisierung. dpunkt.verlag, [8] Kruchten, Philippe: The Rational Unified Process. An Introduction. Addison-Wesley, [9] Object Management Group: UML Specification. April [10] Paulk, Mark C., Charles V. Weber, Bill Curtis und Mary Beth Chrissis: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison- Wesley, [11] SDL Forum Society. April

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

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

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

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

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

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

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

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

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06 Kapitel 0: Vorlesungsüberblick Prof. Dr. Mario Winter SP2-0 FH Köln SP-2 (WI3) Vorlesungsüberblick 1. Softwaretechnik

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

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

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

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

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

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

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

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

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

Mehr

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

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

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

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

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

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

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

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

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

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

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

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

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

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

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

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

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

Ü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

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 3 Dr. H. Ehler, S. Wagner 8. Februar 2007 Übungen zu Softwaretechnik Aufgabe 23 CMM Das Capability Maturity Model (CMM) wurde entwickelt, um die Fähigkeit von Auftragnehmern

Mehr

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

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

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

Mehr

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

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

Graphischer Editor für die technologieunabhängige User Interface Modellierung

Graphischer Editor für die technologieunabhängige User Interface Modellierung Universität Augsburg Lehrstuhl für Softwaretechnik und Programmiersprachen Prof. Dr. Bernhard Bauer Praktikum Modellgetriebene Softwareentwicklung SS 2008 Graphischer Editor für die technologieunabhängige

Mehr

Visuelle Sprachen. Gabriele Taentzer WS 2012/2013 Philipps-Universität Marburg

Visuelle Sprachen. Gabriele Taentzer WS 2012/2013 Philipps-Universität Marburg Visuelle Sprachen Gabriele Taentzer WS 2012/2013 Philipps-Universität Marburg 1 Beispiele für visuelle Sprachen Modellierungssprachen: Automaten, Statecharts Entity-Relationship-Diagramme (ER-Diagramme)

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Praktisches Wissensmanagement bei der Softwareentwicklung am Beispiel der Prozessmodelle Rational Unified Process (RUP) und Extreme Programming (XP)

Praktisches Wissensmanagement bei der Softwareentwicklung am Beispiel der Prozessmodelle Rational Unified Process (RUP) und Extreme Programming (XP) MITTEILUNGEN DER SCHWEIZER INFORMATIK GESELLSCHAFT 4/2004 Wissen erhalten trotz Redimensionierungen Praktisches Wissensmanagement bei der Softwareentwicklung am Beispiel der Prozessmodelle Rational Unified

Mehr

Modellgetriebene agile BI-Vorgehensweise

Modellgetriebene agile BI-Vorgehensweise Modellgetriebene agile BI-Vorgehensweise Thomas Neuböck Konrad Linner 12.11.2013 Inhalt Anforderungen und Lösungsansatz Agile Vorgehensweise Orientierung nach Fachthemen Architekturrahmen Modellorientierung

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

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

Kurzübersicht Unified Process und Agile Prozesse

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

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg Modellgetriebene Softwareentwicklung von mobilen Anwendungen WS 2014/15 Philipps-Universität Marburg Organisation der LV Umfang: 6 SWS, 9 ECTS Punkte Veranstalter:, Daniel Strüber, Steffen Vaupel Kontakt:

Mehr

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik login: pw: Prof. Dr.-Ing. habil Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik email: ilka.philippow@tu-ilmenau.de Tel. 69 2826 Sekr. 69 2870, Frau Meusel, Zuse Bau Zi

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

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

Mehr

Das V-Modell: Produkte 1/5

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

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Model Driven Requirements Engineering im Energiehandel Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Requirements Engineering ETG-RPI Autor Lars van Brackel V.10

Mehr

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die

Mehr

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de

Neue Produkte 2010. Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 www.p-und-z.de Neue Produkte 2010 Ploetz + Zeller GmbH Truderinger Straße 13 81677 München Tel: +49 (89) 890 635-0 Ploetz + Zeller GmbH. Symbio ist eine eingetragene Marke der Ploetz + Zeller GmbH. Alle anderen Marken

Mehr

Modellierung vonanforderungen

Modellierung vonanforderungen Modellierung vonanforderungen Dehla Sokenou GEBIT Solutions Koenigsallee 75b 14193 Berlin www.gebit.de dehla.sokenou (at) gebit.de Abstract: In der betrieblichen Anwendungsentwicklung werden in vielen

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

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

BPMN vs. EPK & Co. oder auf was es wirklich ankommt

BPMN vs. EPK & Co. oder auf was es wirklich ankommt BPMN vs. EPK & Co. oder auf was es wirklich ankommt Sebastian Adam, Norman Riegel 15. Mai 2012, St. Augustin Die Fraunhofer-Gesellschaft e.v. Benannt nach: Rolle der FraunhoferGesellschaft: Größe: Forschungsvolumen:

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

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

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

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten?

Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten? Gute Modelle Wie bewerten Sie die Ergebnisse von Modellierungsprojekten? Präsentation bei MID Insight 2012 Nürnberg, 20. November 2012 Dr. Jürgen Pitschke BCS Dr. Jürgen Pitschke www.enterprise-design.eu

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

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

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

Mehr

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement Basierend auf einem zentralen SOA-Projekt wird die Integration von Änderungsmanagement aus dem ApplicationLifeCycle

Mehr

Kiwi. Modellkonsistenz. Themenbereich Modellmanagement und Qualität

Kiwi. Modellkonsistenz. Themenbereich Modellmanagement und Qualität Kiwi. Kiwi. Modellkonsistenz Themenbereich Modellmanagement und Qualität Vortrag im Seminar Software-Qualität bei der modellbasierten Softwareentwicklung (SS2007) Stefan Marr Agenda 3 Softwareentwicklung

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

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

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

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

Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Modellgetriebene Softwareentwicklung bei der IBYKUS AG Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Die Evolution von extreme Programming

Die Evolution von extreme Programming Die Evolution von extreme Programming Wieso extreme Programming so ist, wie es ist. Von Michael Kircher Der aktuelle Trend bei der Software-Entwicklung wird derzeit von Java und E-Commerce Projekten getrieben.

Mehr

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

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

Mehr

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Stefan Link, Thomas Schuster, Philip Hoyer, Sebastian Abeck Institut für Telematik, Fakultät für Informatik Universität Karlsruhe (TH)

Mehr

Management von Anforderungen im Rational Unified Process (RUP)

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

Mehr

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

Code-Quality-Management

Code-Quality-Management Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht von Frank Simon, Olaf Seng, Thomas Mohaupt 1. Auflage Code-Quality-Management Simon / Seng

Mehr

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

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

Mehr

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

Projektmanagement (Modelle, Methoden & Tools)

Projektmanagement (Modelle, Methoden & Tools) Projektmanagement (Modelle, Methoden & Tools) Übersicht zu den Inhalten der Vorlesung Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus finden sich vielfältige

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr