Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien

Größe: px
Ab Seite anzeigen:

Download "Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien"

Transkript

1 Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien Christoph Oberhokamp Franz-Hitze Str. 27, Paderborn Abstract. Software-Produktlinien (SPL) umfassen mehrere individuelle Ausprägungen eines Softwareproduktes, die auf Basis einer gemeinsamen Plattform entwickelt werden. Um die Unterschiede zwischen den einzelnen Produkten ausdrücken zu können, werden Teile der gemeinsamen Plattform als variabel definiert. Das Verwalten und die Verfolgbarkeit (Traceability) dieser Variabilität stellt eine große Herausforderung dar. Da bei einer Software-Produktlinienentwicklung Variabilität in allen Entwicklungsartefakten und über den gesamten Entwicklungszyklus hinweg vorkommt, ist die Verfolgbarkeit dieser eine komplexe Aufgabe. Diese Seminararbeit gibt einen Überblick über das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien und stellt ausgewählte Ansätze zur Lösung des Problems vor. Keywords: Software-Produktlinien, Variabilitätsmanagement, Verfolgbarkeit, Traceability, Tracing 1 Einleitung Da der Markt heutzutage Software-Produkte fordert, die nach immer kürzeren Release-Zyklen und zu möglichst niedrigen Entwicklungskosten zur Verfügung stehen, wird in der Entwicklung ein hohes Maß an Effizienz und Flexibilität benötigt. Mit Hilfe des Entwicklungsparadigmas Software-Produktlinien sollen genau diese Anforderungen erfüllt werden. Die Software-Produktlinienentwicklung basiert auf der geplanten, strategischen, systematischen und somit pro-aktiven Wiederverwendung von Software-Artefakten. Im Vergleich zur Entwicklung von Einzel-Software- Systemen erlaubt dies eine Senkung der Entwicklungskosten und eine Verkürzung der Entwicklungszeit bei gleichzeitiger Steigerung der Qualität [21]. Eine Software-Produktlinie wird basierend auf den Gemeinsamkeiten und Unterschieden, die zwischen ähnlichen Produkten existieren, entwickelt. Die Gemeinsamkeiten definieren dabei die Eigenschaften, die zwischen den Produkten gleich sind, während die Unterschiede variable Eigenschaften der Produkte beschreiben. Diese Variabilität innerhalb einer SPL muss explizit definiert und verwaltet werden. Dabei muss Sie auf unterschiedlichen Abstraktionsebenen und über alle generischen Ent- 1

2 wicklungsartefakte, wie zum Beispiel Anwendungsfallbeschreibungen mit Variabilität, verwaltet werden. Hierbei spielt die Verfolgbarkeit der Variabilität eine wesentliche Rolle. Eine gute Verfolgbarkeit verbessert die Verständlichkeit eines Systems und trägt zu einer vereinfachten Wartbarkeit und Evolution einer Software- Produktlinie bei [2]. Die vorliegende Arbeit gliedert sich in fünf Kapitel. Kapitel 2 gibt zunächst eine Einführung in die grundlegenden Eigenschaften und den Entwicklungsprozess des Entwicklungsparadigmas Software-Produktlinie. Im darauf folgenden Kapitel 3 wird der Begriffe des Variabilitätsmanagements im Kontext einer Software-Produktlinienentwicklung näher betrachtet und eine Einordnung der Verfolgbarkeit von Variabilität in die Anforderungen an einen allgemeingültigen Variabilitätsmanagement-Ansatz vorgenommen. Anschließend wird im Kapitel 4 das Grundproblem der Verfolgbarkeit von Variabilität in Software-Produktlinien erläutert und zwei ausgewählte Ansätze zur Lösung des Problems vorgestellt und bewertet. Kapitel 5 fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf zukünftige Arbeitsfelder in Bezug auf das behandelte Thema. 2 Software-Produktlinien Produktlinien werden in der Literatur, zum Beispiel in [7], als das dominante Software-Entwicklungsparadigma des 21. Jahrhunderts bezeichnet. Der grundlegende Gedanke besteht darin, mehrere Software-Produkte aus möglichst vielen gemeinsamen Teilen zu entwickeln, damit der Entwicklungsaufwand für diese Teile nur einmal geleistet werden muss. Gleichzeitig besitzt jedes Produkt spezifische Teile, die für das jeweilige Produkt charakteristisch sind. Die so entwickelten, ähnlichen Software-Produkte sind für eine bestimmte Domäne wie zum Beispiel Informationssysteme (CRM-Systeme, ERP-Systeme) oder eingebettete Systeme (Kfz-, Schiffsund Flugzeugelektronik, Telekommunikation) vorgesehen. Durch die konsequente Wiederverwendung von Entwicklungsartefakten wie Anforderungen, Spezifikationen, Architekturbeschreibungen, Quellcode und Testfälle können Entwicklungskosten gespart, die Software-Qualität erhöht und die Time-to-Market verkürzt werden [21]. Clements & Northrop vom Software Engineering Institute der Carnegie Mellon University definieren eine Software-Produktlinie wie folgt: Software-Produktlinie (software product line) A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [8]. Die Abbildung 1 zeigt den Entwicklungsprozess einer SPL von Pohl et al. [21]. Der wichtigste Unterschied zu anderen Entwicklungsprozessen ist die Aufteilung in einen Plattform- und einem dazu korrespondierenden Produkt-Entwicklungsprozess. 2

3 Beide Prozesse umfassen die Phasen Analyse, Design, Realisierung und Testen. Entwicklungsartefakte, die im Plattform-Entwicklungsprozess entwickelt werden, beinhalten variable Teile (schwarz und grau). Abbildung 1 Software-Produktlinen Entwicklungsprozess (abgewandelt aus [21]) Bei der Entwicklung (Ableitung) eines Produktes aus der Plattform wird die Variabilität in den Entwicklungsartefakten der Plattform gebunden. Das heißt, es wird eine konkrete Auswahl aus den variablen Elementen getroffen. In der Beispielabbildung ist das schwarze Artefakt in der Plattform Analyse Teil eines abgeleiteten Produktes, während das graue es nicht ist. Die Auswahl wirkt sich sukzessive auf alle Entwicklungsphasen und die darin enthaltenen Artefakte wie Klassen, Komponenten und Testfälle aus. Die Entwicklung von Produkten im Rahmen einer Software-Produktlinie stellt jedoch hohe Ansprüche an den Entwicklungsprozess, das technische und organisatorische Management sowie an die Personen, die an der Entwicklung beteiligt sind [8]. Die Abhängigkeiten der variablen Teile in verschiedenen Entwicklungsphasen müssen erkannt und verwaltet werden. Das zentrale Konzept für die Definition und Dokumentation der Variabilität einer Software-Produktlinie sind Variationspunkte und Varianten. Ein Variationspunkt spezifiziert, was variieren kann. Eine Variante definiert eine konkrete Variation. In der Produktentwicklung werden die Variationspunkte gebunden, indem die Varianten, die den anwendungsspezifischen Anforderungen entsprechen, ausgewählt werden [15]. Weitere Details über den Software-Produktlinien-Ansatz und seinem Entwicklungsprozess sind in [8], [21] und [6] zu finden. 3

4 3 Variabilitätsmanagement in Software-Produktlinien Um den vollen Nutzen einer Software-Produktlinie zu erhalten, müssen die Variabilität und insbesondere die Variationspunkte und deren Beziehungen zueinander in einer angemessenen und konsistenten Art über den gesamten Softwareentwicklungsprozess hinweg verwaltet werden [4]. Dies bedeutet, dass unabhängig von der Abstraktionsebene und unabhängig von der Entwicklungsphase die Variabilität in einer einfachen Art und Weise, am besten mit einem allgemeingültigen Ansatz, gemanagt werden sollte. Nach Berg und Muthig [3] sollte ein allgemeingültiger Ansatz für das Variabilitätsmanagement in Software-Produktlinien vier wichtige Charakteristika erfüllen. Der Ansatz sollte konsistent und skalierbar sein, er sollte eine gute Verfolgbarkeit zwischen Variationspunkten auf verschiedenen Abstraktionsebenen und durch alle Entwicklungsphasen hindurch ermöglichen und er sollte eine Möglichkeit bieten, Variabilität zu visualisieren: Konsistenz: Durch eine Standardisierung können Konfusionen und einem fehlerhaften Gebrauch des Ansatzes vorgebeugt werden. Deshalb sollte die Variabilität auf den verschiedenen Abstraktionsebenen und in den verschiedenen Entwicklungsphasen gleich gehandhabt werden. Ein konsistenter Ansatz reduziert außerdem die Möglichkeit von Fehlern, die auftreten könnten, wenn verschiedene Methoden für das Managen der Variabilität auf unterschiedlichen Abstraktionsebenen benutzt würden. Skalierbarkeit: Die Variabilität muss leicht handhabbar sein, egal ob es sich um eine einzelne Komponente oder um ein komplexes System handelt. Es reicht dabei nicht aus, wenn eine Methode das Verwalten der Variabilität im kleinen Umfang ermöglicht, im größer werdenden Umfang aber zu komplex und nicht mehr handhabbar wird. Verfolgbarkeit: Variabilität auf verschiedenen Abstraktionsebenen und in verschiedenen Entwicklungsphasen steht im Zusammenhang zueinander. Diese Zusammenhänge müssen miteinander verknüpft werden. Durch eine angemessene Verwaltung dieser multi-dimensionalen Beziehungen können die Wartbarkeit und die Evolution einer Software-Produktlinie vereinfacht werden. Visualisierung: Eine Visualisierung der Variabilität und der Abhängigkeiten zwischen Produkten in einer Produktlinie ermöglicht einen Überblick über die Zusammenhänge und fördert somit die Verständlichkeit und Wartbarkeit der Software-Produktlinie. Der Fokus in dieser Seminararbeit liegt auf der Verfolgbarkeit im Kontext eines solchen universellen Variabilitätsmanagement-Ansatzes. 4

5 4 Verfolgbarkeit von Variabilität in Software-Produktlinien Bei der Entwicklung von Einzelsystemen wird die Entscheidung, ob eine bestimmte Eigenschaft in einem Produkt vorhanden sein soll oder nicht, während der Anforderungs- oder Analysephase getroffen und das Produkt basierend darauf entwickelt. Bei der Entwicklung von Software-Produktlinien wird diese Entscheidung so lange wie möglich hinausgezögert, mindestens bis zu dem Punkt, an dem es der Organisation den meisten Nutzen bringt [11]. Dies hat zur Folge, dass die Variabilität nicht nur in der Anforderungs- und Analysephase, sondern in allen Entwicklungsphasen von der Anforderungsanalyse bis hin zur Implementierung verwaltet werden muss [19]. Das Verwalten der Variabilität beinhaltet als einen zentralen Punkt die Verfolgbarkeit von Variabilität über den gesamten Entwicklungszyklus hinweg. Dabei kann gut eingeführte Verfolgbarkeit die Verständlichkeit einer Produktlinien und ihrer Produkt-Entwicklung verbessern und die Evolution und Wartbarkeit unterstützen [23]. 4.1 Verfolgbarkeit Als Verfolgbarkeit wird eine Verknüpfung verstanden, welche eine Relation oder Abhängigkeit zwischen Entwicklungsartefakten beschreibt, die während der verschiedenen Phasen des Software Engineerings entwickelt wurden [3]. Entwicklungsartefakte können dabei beispielsweise Anforderungsspezifikationen, Architekturbeschreibungen, Source Code und Testpläne sein. Beim Traditionellen Software Engineering (nicht SPL) werden zwei Arten von Verfolgbarkeit definiert: vertikale und horizontale Verfolgbarkeit [1]. Vertikale Verfolgbarkeit beschreibt Beziehungen zwischen Artefakten derselben Abstraktionsebene, wie zum Beispiel zwischen verwandten Anforderungen, zwischen Modellen oder zwischen Softwarekomponenten. Horizontale Verfolgbarkeit bezieht sich auf die Beziehungen zwischen verschiedenen Abstraktionsebenen, wie zum Beispiel zwischen den Anforderungen und der Implementierung. Zu diesen zwei Arten der Verfolgbarkeit kommt bei der Entwicklung von Softwareproduktlinien eine dritte Art hinzu, welche sich mit Variabilität und seinen Auswirkungen befasst [3]. Verfolgbarkeits-Verknüpfungen haben dabei ebenfalls eine vertikal und eine horizontale Ausprägung. Sie werden benötigt, um Variationspunkte zu ihren Varianten, Varianten untereinander, Variationspunkte untereinander, Entwicklungsartefakte zu Variationspunkten oder Varianten und Entscheidungen, die bei der Produktentwicklung getroffen wurden, zu den angebotenen Optionen der Plattformentwicklung in Verbindung zu setzen [1]. Die Abbildung 2 veranschaulicht die Verfolgbarkeit von Variabilität am Beispiel des klassischen V-Modells [5]. Der Vollständigkeit halber sei erwähnt, dass eine weitere Dimension an Verfolgbarkeit entsteht, wenn das Konfigurationsmanagement einer Software-Produktlinien betrachtet wird. Diese Ebene wird oftmals als Evolution bezeichnet, da Relationen zwischen verschiedenen Versionen und Revisionen eines Artefaktes der Produktlinie betrachtet werden [1]. 5

6 Abbildung 2 Verfolgbarkeit von Variabilität am Beispiel des klassischen V-Modells Die Ausführungen in dieser Seminararbeit beziehen sich aber ausschließlich auf die Verfolgbarkeit von Variabilität in Software-Produktlinien. 4.2 Grundproblem der Verfolgung von Variabilität in SPL Das Grundproblem der Verfolgbarkeit von Variabilität zwischen Entwicklungsartefakten aus verschiedenen Abstraktionsebenen ist direkt mit dem sogenannten Feature Interaktionsproblem verwand, welches in [10] wie folgt beschrieben wird: Feature Interaktionsproblem Das Problem ist, dass individuelle Features typischerweise nicht direkt zu einer individuellen Komponente oder einem Cluster von Komponenten verfolgt werden können das bedeutet, wenn ein Produkt durch die Auswahl einer Gruppe von Features definiert wird, dann ist eine sorgfältig abgestimmte und komplizierte Mixtur an Teilen von verschiedenen Komponenten involviert. [10] Der Begriff Feature ist in der Literatur leider nicht eindeutig definiert. Plath et al. definieren ein Feature zum Beispiel als eine funktionale Einheit, die einem System hinzugefügt oder aus einem System weggelassen werden kann [20]. Im Allgemeinen werden als Feature markante und wichtige Charakteristiken einer Domäne oder eines Software-Systems verstanden [14]. Die Beschreibung des Feature Interaktionsproblems impliziert eine n-zu-n Relation zwischen Features und Komponenten oder Designelementen. Diese n-zu-n Relation zwischen Elementen aus dem sogenannten Problemraum und Elementen aus dem sogenannten Lösungsraum stellt das grundlegende Problem der Verfolgung von Variabilität in Software-Produktlinien dar. Die Begriffe Problemraum und Lösungsraum sind in Vergangenheit durch Czarnecki und Eisenecker eingeführt worden [9]. Der Problem- und Lösungsraum 6

7 zusammen repräsentieren die Entwicklungsphasen einer Software-Produktlinienentwicklung (siehe Abbildung 3). Der Problemraum umfasst dabei im Allgemeinen die Systemspezifikation, die während der Anforderungsanalyse- und Designanalysephase entwickelt wird, während der Lösungsraum das konkrete System umfasst, welches während der Architektur-, Design- und Implementierungsphase erstellt wird. Alle Entwicklungsartefakte zusammen bilden die Produktlinien Infrastruktur. Abbildung 3 Problem- und Lösungsraum (entnommen aus [3]) Eine ideale Verfolgbarkeit sollte eine Verknüpfung der Relationen und Abhängigkeiten zwischen allen Variationspunkten in den Entwicklungsartefakten vom Problemraum zum Lösungsraum bieten [25]. Dies würde eine 1-zu-1 Mapping zwischen Variationspunkten der verschiedenen Räume bedeuten. Wie oben schon erwähnt wurde, existiert jedoch typischerweise ein n-zu-n Mapping zwischen den Variationspunkten in den Entwicklungsartefakten des Problem- und denen des Lösungsraumes. Zum Beispiel könnte ein Variationspunkt in der Anforderungsspezifikation durch mehrere Variationspunkte, die über verschiedene Komponenten verteilt sind, realisiert werden. Zur gleichen Zeit könnte eine einzige Komponente mehrere variable Anforderungen realisieren (siehe Abbildung 4). Eine solche Beziehung wird auch als Streuung bezeichnet [26]. Abbildung 4 Beziehung zwischen Features und anderen Entwicklungsartefakten (entnommen aus [22]) Um eine Verfolgung der Variabilität zwischen den Artefakten aus verschiedenen Abstraktionsebenen zu ermöglichen, ist es erforderlich eine 1-zu-1 Beziehung zwischen allen Artefakten, die im Problem- sowie im Lösungsraum entwickelt werden, herzustellen. Die Abbildung 5 veranschaulicht, dass ein spezifisches Zwischenmodell benötigt wird, welches die individuellen Beziehungen erfasst und ein dazugehöriges Mapping bereitstellt, um eine solche 1-zu-1 Beziehung zwischen allen Artefakten des Problem- und des Lösungsraums zu erreichen. 7

8 Abbildung 5 Beziehung zwischen Artefakten im Problem- und Lösungsraum (entnommen aus [4]) Die im folgenden Abschnitt vorgestellten Ansätze zielen darauf ab, ein geeignetes Zwischenmodell zu finden, um eine Verfolgbarkeit der Variabilität in Software- Produktlinien zu ermöglichen. 4.3 Bestehende Lösungsansätze In der Literatur existieren einige Ansätzen zur systematischen Verfolgbarkeit von Variabilität in Software-Produktlinien. Sie unterscheiden sich im Grad der Abdeckung des Lebenszyklus (für eine Phase, mehrere Phasen oder den ganzen Lebenszyklus) und in ihrer Notation und Notationsabhängigkeit [24]. Verschiedene Ansätze betrachten die Variabilitätsmodellierung und das Variabilitätsmanagement lediglich für eine einzige Phase oder für zwei Lebenszyklus-Phasen. So betrachten zum Beispiel Moon und Chae in [16] die Verfolgbarkeit der Variabilität zwischen den Anforderungen und der Architektur einer Software-Produktlinie. Wie oben bereits erwähnt, ist jedoch ein Ansatz, der den gesamten Entwicklungs- Lebenszyklus abdeckt, wünschenswert. Es gibt einige Ansätze, die ein Variabilitätsmanagement für den gesamten Lebenszyklus vorschlagen [3, 12, 13, 17, 24]. Den meisten liegt ein sogenanntes Entscheidungsmodell (decision model) zugrunde, was den Kern des Variabilitätsmanagements und somit der Verfolgbarkeit bildet. Aus den vorhandenen Ansätzen werden die Ansätze von Schmid et al. [24] sowie von Berg et al. [3] im Folgenden etwas genauer erläutert. Die beiden Ansätze geben einen guten Einblick in die Herangehensweisen und Lösungsansätze für eine erfolgreiche Verfolgung von Variabilität in Software-Produktlinien. Schmid et al. präsentieren einen Ansatz, der ein homogenes Variabilitätsmanagement über die verschiedenen Entwicklungs-Lebenszyklus-Phasen unabhängig von einer spezifischen Notation verspricht [24]. Sie gehen bei Ihrem Vorgehen davon 8

9 aus, dass ein Unternehmen bereits eine Einzelsystementwicklung betrieben hat und daran interessiert ist, so viel wie möglich der existierenden Notationen, Ansätze und Prozesse zu behalten. Wenn zum Beispiel ein Unternehmen in der Vergangenheit eine textbasierte Anforderungsdefinition vorgenommen hat, soll diese bei der Umstellung auf eine Produktlinien-Entwicklung erhalten und mit Variabilitätskonzepten angereichert werden. Für eine umfassende Variabilitätsmanagement-Technik sehen sie fünf Kernpunkte, die von einem allgemeingültigen Ansatz erfüllen werden sollten: 1. Die Definition von Variationspunkten in den Basis-Artefakten 2. Die Definition von Elementen, die potenziell an diese Variationspunkte gebunden werden können 3. Die Definition von Relationen zwischen Variationspunkten und potenziell gebundenen Elementen 4. Die Definition von Bedingungen, die die potenziellen Instantiierungen zwischen potenziellen Variationspunkt-Bindungen einschränken 5. Ein Auswahlmechanismus, zur Definition der Elemente, die in ein spezifisches Produkt einfließen sollen. Dieser Auswahlmechanismus kann sowohl eine manuelle als auch eine Tool-unterstützte Elementauswahl unterstützen Neben diesen hauptsächlich technischen Anforderungen stellen Schmid et al. noch einige weitere Anforderungen an einen allgemeingültigen Variabilitätsmanagement- Ansatz, die sie aus Erfahrungen aus verschiedenen Industrieprojekten abgeleitet haben. Der Ansatz soll notationsunabhängig sein Der Ansatz soll auf alle Arten an Lebenszyklus-Artefakte anwendbar sein Der Ansatz soll die Verfolgbarkeit von Variabilität sowohl horizontal als auch vertikal unterstützen Es soll möglich sein, den Ansatz hierarchisch zu strukturieren Den Ansatz, den Schmid et al. basierend auf diesen selbst definierten Anforderungen entwickelt haben, besteht aus den folgenden fünf Komponenten: 1. Ein Entscheidungsmodell als Basis für die Charakterisierung der Auswirkungen von Variabilität 2. Einem Mechanismus, um Interaktionen zwischen verschiedenen Entscheidungen (decision) zu beschreiben 3. Einem Mechanismus, um Relationen zwischen Variationspunkten und den spezifischen Entscheidungen (oder einer Gruppe von Entscheidungen), von denen die Auflösung der Variabilität abhängt, zu beschreiben 4. Eine allgemeine (maximale) Menge an Auswahltypen 5. Ein begleitendes Mapping der Auswahltypen zu einer spezifischen Notation, um die Variationspunkte in den Artefakten auszudrücken Lediglich die letzte Komponente, das Mapping, muss auf eine spezifische Repräsentationstechnik, die ein Unternehmen bei der Umstellung auf eine Produktlinienentwicklung beibehalten hat, angepasst werden. Die anderen Komponenten des 9

10 Ansatzes sind unabhängig von einer spezifischen Repräsentationstechnik, also notationsunabhängig. Die Abbildung 6 veranschaulicht diese Situation und den Variabilitätsmanagement-Ansatz von Schmid et al.. Abbildung 6 Variabilitätsmanagement-Ansatz nach Schmid et al. (entnommen aus [24]) Die ersten vier Teile des Ansatzes sind für alle Anwendungen identisch. Ausschließlich das spezifische Mapping muss jeweils angepasst und modifiziert werden. Die übrigen Elemente des Ansatzes bleiben unverändert, sodass Entwickler und Ingenieure fast wie zuvor modellieren und vorhandene Modellierungsartefakte nutzen können. Lediglich die Variationspunkte müssen in den Entwicklungsartefakten spezifiziert und im Entscheidungsmodell eingetragen werden. Im Folgenden wird das Entscheidungsmodell des Ansatzes genauer erläutert, da es für die Verfolgbarkeit eine entscheidende Rolle einnimmt. Die weiteren Komponenten des Ansatzes sind für die Verfolgbarkeit nicht ausschlaggebend und werden daher nicht weiter betrachtet. Das Entscheidungsmodell des Ansatzes von Schmid et al. besteht aus einer Menge von Entscheidungsvariablen (decision variable), die in Tabellenform notiert werden. Jede Entscheidungsvariable repräsentiert dabei eine (variable) Entscheidung, die bei der Instanziierung eines Produktes aus der Produktlinie getroffen werden muss. Eine solche Entscheidungsvariable kann dabei für mehrere Variationspunkte in den Entwicklungsartefakten verwendet werden. Sie bestehen zumeist aus den folgenden Informationen: Name: Ein eindeutiger Name, der die Entscheidungsvariable treffend beschreibt Relevanz: Die Relevanz einer Entscheidungsvariable kann von der Ausprägung einer anderen Entscheidungsvariable abhängen. So ist eine Entscheidungsvariable gegebenenfalls nicht mehr relevant, sobald eine andere einen bestimmten Wert annimmt Beschreibung: Eine textuelle Beschreibung der Entscheidung, die durch die Entscheidungsvariable erfasst wird 10

11 Wertebereich: Der Wertebereich gibt die möglichen Werte an, die eine Entscheidungsvariable annehmen kann Kardinalität: Die Kardinalität drückt aus, wie viele der definierten Werte aus dem Wertebereich von der Entscheidungsvariable angenommen werden können Bedingungen: Bedingungen werden dazu verwendet, um Wechselbeziehungen zwischen verschiedenen Entscheidungsvariablen zu beschreiben Abhängig vom spezifischen Kontext kann es vorkommen, dass eine Auswahl aus diesen Entscheidungsvariablen-Informationen verwendet wird. Es handelt sich jedoch immer um eine Teilmenge der oben genannten Informationen. Angemerkt sei auch, dass es aus praktischen Gründen und Gründen der Konsistenz immer nur ein Entscheidungsmodell für alle Entwicklungsphasen gibt. Die Tabelle 1 veranschaulicht an einem Beispiel den möglichen Aufbau des Entscheidungsmodells nach Schmid et al. und die Ausprägung einiger Entscheidungsvariablen. Tabelle 1 Beispiel eines Entscheidungsmodells nach Schmid et al. (entnommen aus [24]) Die Abbildung 7 soll die beispielhafte Verwendung einer Entscheidungsvariable in einem Entwicklungsartefakt, das eine textuelle Notation verwendet, verdeutlichen. Anzumerken ist hierbei, dass die beiden spitzen Klammern << und >> Elemente sind, die noch nicht in der textuellen Notation verwendet wurden und dass opt für optional und alt für alternativ steht. Abbildung 7 Beispielhafte Verwendung einer Entscheidungsvariable in einem textbasierten Entwicklungsartefakt (entnommen aus [24]) 11

12 Das Entscheidungsmodell bildet die Basis, um individuelle Produkte der Produktlinien zu beschreiben. Ein spezifisches Produkt kann beschrieben werden, indem Entscheidungen getroffen und damit den Entscheidungsvariablen im Entscheidungsmodell Werte zugewiesen werden. Die Bedingungen zwischen den Entscheidungsvariablen geben dabei die zulässigen Werte vor. Mit diesen zugewiesenen Entscheidungen können die Variationspunkte in den Entwicklungsartefakten, die mit den Entscheidungsvariablen in Bezug stehen, instanziiert werden. Die Abbildung 8 veranschaulicht den Zusammenhang des Entscheidungsmodells und der Entwicklungsartefakte. Abbildung 8 Zusammenhang zwischen Entscheidungsmodell und Entwicklungsartefakten Jedem Variationspunkt in den Entwicklungsartefakten ist eine Entscheidungsvariable im Entscheidungsmodell zugewiesen. Eine Verfolgbarkeit der Variabilität ist somit über das Entscheidungsmodell gegeben, da es eine 1-zu-1 Beziehung zwischen Variationspunkten und Entscheidungsvariablen herstellen. Berg et al. [3] haben einen Ansatz vorgestellt, in dem sie Variabilitätsmanagement in einer dritten Dimension, in einem sogenannten konzeptionellen Variabilitätsmodell (conceptual variability model) darstellen. Sie fassen das Software Engineering für Einzelsysteme in einem zweidimensionalen Raum auf, einen für den Entwicklungsprozess und einen für die Abstraktionsebene (siehe Abbildung 9). Alle Entwicklungsartefakte können in diesem zweidimensionalen Raum platziert werden. Für die Variabilität einer Software-Produktlinie fügen sie eine dritte Dimension hinzu, in der explizit alle Variabilitätsinformationen gekapselt werden. So werden zum Beispiel die Beziehungen und Abhängigkeiten von Variationspunkten zu Variationspunkten in anderen generischen Artefakten oder auf anderen Abstraktionsebenen in diesem konzeptionellen Variabilitätsmodell gekapselt [3]. Der Ansatz von Berg et al. basiert auf einigen der Ideen der multi-dimensionalen Separierung von Eigenschaften (separation of concerns), bei der Softwareartefakte durch Separierung von sich überlappenden Eigenschaften entlang mehrerer 12

13 Dimensionen durch Komposition und Dekomposition modelliert und implementiert werden [26]. Durch die explizite Beschreibung von Variabilitätsinformationen in der dritten Dimension erreichen sie ebenfalls eine Separierung der Variabilitätsinformationen aus den generischen Artefakten. Da für jedes generische Artefakt die individuellen Variationspunktinformationen und insbesondere die Beziehungen und Abhängigkeiten zu Variationspunkten in anderen Artefakten im konzeptionellen Variabilitätsmodell gekapselt werden, kann mithilfe dieses Modells eine Verfolgbarkeit der Variabilität gewährleistet werden. Somit ist ein 1-zu-1 Mapping zwischen Variationspunkten der verschiedenen Räume möglich (siehe Abbildung 9). Abbildung 9 Konzeptionelles Modell für die Verfolgbarkeit von Variabilität (entnommen aus [3]) Jeder Variationspunkt, der in einem Entwicklungsartefakt definiert wird, steht im Bezug zu einer Entscheidung (decision) [18]. Eine Entscheidung ist das Resultat der Beantwortung einer Frage, welche die Essens der Variabilität beschreibt, die in einem Variationspunkt ausgedrückt werden soll [3]. Entscheidungen können andere Variationspunkte einschränken und zu einer Begrifflichkeit aus einer konkreten Domäne in Bezug gesetzt werden. Eine einfache Entscheidung (simple decision) ist ein Variationspunkt, der lediglich an einer Stelle in einem generischen Artefakt auftritt. Es ist eine Entscheidung, die nur im Bezug zu einem generischen Artefakt und nicht im Bezug zu anderen Variationspunkten steht. Die Entscheidungen werden im Ansatz von Berg et al. im konzeptionellen Variabilitätsmodell gekapselt, während die einfachen Entscheidungen in den generischen Artefakten bleiben. Die Entscheidungen mit den dazugehörigen Informationen können in Tabellenform oder in einer baumartigen Struktur notiert werden. 13

14 4.4 Bewertung der vorgestellten Lösungsansätze Die beiden vorgestellten Ansätze von Schmid et al. und Berg et al. zur Verfolgbarkeit von Variabilität in Software-Produktlinien basieren grundsätzlich auf derselben Idee. In beiden Ansätzen werden die Variabilitätsinformationen außerhalb der Entwicklungsartefakte, die während der verschiedenen Phasen des Entwicklungsprozesses erstellt werden, gekapselt und verwaltet. Die Verfolgbarkeit der Variabilität erfolgt dann über diese gekapselten Variabilitätsinformationen. Nutzt man im Ansatz von Berg et al. zur Notation der in der dritten Dimension verwalteten Entscheidungen eine Tabelle, so wird eine starke Ähnlichkeit zum Entscheidungsmodell von Schmid et al. offensichtlich. Die beiden Ansätze unterscheiden sich jedoch in ihrem Ursprung und in der Herangehensweise an einen allgemeingültigen Variabilitätsmanagement Ansatz. Schmid et al. gehen davon aus, dass bereits eine Einzelsystementwicklung betrieben wurde. Sie versuchen mit ihrem Ansatz, bei der Umstellung auf eine Produktlinienentwicklung, möglichst viele der bestehenden Methoden und Vorgehensweisen zu erhalten und weiterhin zu nutzen. Lediglich das Entscheidungsmodell kommt als neues Modell zu den bereits vorhandenen hinzu. Sie fassen es als neuartiges, zusätzliches Entwicklungsartefakt auf, in dem ausschließlich die Variabilität verwaltet wird. Ein großer Vorteil der Methode liegt in der Notationsunabhängigkeit und der damit gegebenen universellen Anwendbarkeit. Als einen Nachteil kann man die Unübersichtlichkeit des Entscheidungsmodells bei größeren Produktlinien anführen. Die Auswahl von Eigenschaften, die ein Produkt der Produktlinie enthalten soll, ist nur möglich, indem das komplette Entscheidungsmodell durchlaufen und jede Entscheidung einzeln getroffen wird. Somit ist es nur sehr schwer möglich, diejenigen Eigenschaften, die insgesamt für ein Produkt zur Auswahl stehen, zu erfassen. Berg et al. hingegen gehen davon aus, dass es bereits eine Software-Produktlinienentwicklung gibt, in der auch bereits ein eigenes Variabilitätsmodell, wie zum Beispiel ein Feature-Diagramm [13], vorhanden sein kann. Zu dieser bestehenden Produktlinienentwicklung führen sie in einer dritten, orthogonalen Ebene eine Kapselung von Variabilitätsinformationen ein. Sie verwalten die Variabilität in einer separaten Ebene, die den gesamten Entwicklungszyklus überspannt. Schmid et al. dagegen verwalten diese in einem weiteren Entwicklungsartefakt. Ein Vorteil des Ansatzes ist, dass er auf jede bestehende Produktlinienentwicklung angewendet werden kann. Schwächen hat der Ansatz von Berg et al. ebenfalls im Bereich der Übersichtlichkeit und Wartbarkeit. Selbst bei einer Darstellung der Variabilitätsinformationen in einer hierarchischen, baumartigen Struktur, ist die Übersicht über alle möglichen Eigenschaften eines Produktes bei großen Produktlinien nur sehr eingeschränkt gegeben. Die Wartbarkeit der Entscheidungen ist ebenfalls sehr aufwendig, da nach einer Änderung alle zugeordneten einfachen Entscheidungen überprüft und gegebenenfalls ebenfalls geändert werden müssen. Obwohl die grundsätzliche Idee für die Verfolgbarkeit von Variabilität in beiden Ansätzen gleich ist, haben beide Ansätze aufgrund ihrer Unterschiede im Hinblick auf einen allumfassenden Variabilitätsmanagement-Ansatz ihre Daseinsberechtigung. 14

15 5 Zusammenfassung und Ausblick Das zentrale Ziel dieser Arbeit war es, einen Einblick in das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien zu geben und ausgewählte Lösungsansätze vorzustellen. Nachdem die Grundlagen des Entwicklungsparadigmas Software-Produktlinien beschrieben wurden und dargestellt wurde, was Variabilitätsmanagement in Software- Produktlinien bedeutet, ist in Kapitel 4 das Grundproblem der Verfolgbarkeit von Variabilität in Software-Produktlinien beschrieben worden. Anschließend sind zwei ausgewählte Ansätze von Schmid et al. und Berg et al. zur Lösung des Problems vorgestellt und bewertet worden. Das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien wird im Allgemeinen als einen Teil eines allgemeingültigen, universellen Variabilitätsmanagement Ansatze für Software-Produktlinien verstanden. Die beiden vorgestellten Ansätze geben dazu einen Einblick in die in der Literatur vorhandenen Lösungsansätze. Beide Ansätze sind von der grundsätzlichen Idee her ähnlich. Sie lösen das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien durch Kapselung von Variabilitätsinformationen. Dabei weisen beide Ansätze jedoch deutliche Schwächen in der Übersichtlichkeit und Wartbarkeit auf. Die Unterstützung der vorhandenen Ansätze durch Tools ist bis heute nur sehr eingeschränkt und nicht durchgängig durch alle Entwicklungsphasen möglich. Es ist zu erwarten, dass in Zukunft weitere Tools entwickelt werden, die die Ansätze zu Verfolgung von Variabilität in Software-Produktlinien unterstützen. Literatur 1. Anquetil, N., Grammel, B., Galvao Lourenco da Silva, I., Noppen, J., Shakil Khan, S., Arboleda, H., Rashid, A., Garcia, A.: Traceability for Model Driven, Software Product Line Engineering. In: ECMDA Traceability Workshop Proceedings 2008, pp (2008) 2. Bayer, J., Widen, T.: Introducing traceability to product lines, In: Proceedings of the 4th International Workshop on Product Family Engineering 2001, pp , Lecture Notes in Computer Science, vol. 2290, Springer, Heidelberg (2001) 3. Berg, K., Bishop, J., Muthig, D.: Tracing Software Product Line Variability: From Problem to Solution Space. In: Proceedings of SAICSIT 2005, ACM International Conference Proceeding Series, vol. 150, pp White River, South Africa (2005) 4. Berg, K., Muthig, D.: A Critical Analysis of Using Feature Models for Variability Management. Technical Report, University of Pretoria, South Africa (2005) 5. Boehm, B.W.: Guidelines for Verifying and Validating Software Requirements and Design Specification. In: EURO IFIP 1979, pp (1979) 6. Böckle, G., Knauber, P., Pohl, K., Schmid, K. : Software Produktlinien: Methoden, Einführung und Praxis. Dpunkt, Heidelberg (2004) 7. Clements, P.: Software Product Lines: A New Paradigm for the New Century, Cross Talk: The Journal of Defense Software Engineering, pp (1999) 15

16 8. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Addison-Wesley, Boston, USA (2001) 9. Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley. Boston, USA (2000) 10. Griss, D., Allen, R., d Allesandro, M.: Integrating Feature Modelling with the RSEB. In: Proceedings of the 5th International Conference of Software Reuse (ICSR) 1998, pp , IEEE Computer Society, Washington, DC, USA (1998) 11. Gurp, J.v., Bosch, J., Svahnberg, M.: Managing Variability in Software Product Lines. In Proceedings of IEEE/IFIP Conference on Software Architecture (WICSA) 2001, pp , IEEE Computer Society Press, Washington, DC, USA (2001) 12. John, I., Muthig, D.: Tailoring Use Cases for Product Line Modeling: In: Proceedings of the International Workshop on Requirements Engineering for Product Lines (REPL) 2002, pp Proceedings. S.l.: Avaya Labs (2002) 13. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA (1990) 14. Maßen, T.v.: Feature-basierte Modellierung und Analyse von Variabilität in Produktlinienanforderungen. Dissertation, RWTH Aachen, Shaker, Aachen (2007) 15. McGregor, J.D.: Testing a Software Product Line. Technical Report CMU/SEI-2001-TR- 022, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA (2001) 16. Moon, M., Chae, H. S.: A Metamodel Approach to Architecture Variability in a Product Line, 9th International Conference on Software Reuse, pp , Lecture Notes in Computer Science, vol. 4039, Springer, Heidelberg (2006) 17. Muthig, D.: A Light-weight Approach Facilitating an Evolutionary Transition Towards Software Product Lines. PhD Theses in Experimental Software Engineering. Fraunhofer IESE, Kaiserslautern (2002) 18. Muthig, D., Atkinson, C.: Model-Driven Product Line Architectures. In: Proceedings of the 2nd International Software Product Line Conference, SPLC 2002, pp , Lecture Notes in Computer Science, vol Springer, Heidelberg (2002) 19. Myllymäki, T.: Variability Management in Software Product Lines. Technical Report, Institute of Software Systems, Tampere University of Technology (2002) 20. Plath, M.C., Ryan, M.D.: Feature Integration Using a Feature Construct. Science of Computer Programming, vol. 41, pp , Elsevier, Niederlande (2001) 21. Pohl, K., Böckle, G., Linden, F.v.: Software Product Line Engineering: Foundations, Principles, and Techniques, Springer, Heidelberg (2005) 22. Riebisch, M.: Towards a More Precise Definition of Feature Models. In: Workshop at ECOOP Pp , Books On Demand, Darmstadt (2003) 23. Sametinger, J., Riebisch, M.: Evolution Support by Homogenously Documenting Patterns, Aspects and Traces. In: Proceedings of the 6th European Conference on Software Maintenance and Reengineering 2002, pp , IEEE Computer Society Press (2002) 24. Schmid, K., John, I.: A customizable approach to full-life cycle variability management. Science of Computer Programming, vol. 53, No. 3, pp (2004) 25. Sochos, P., Philippow, I., Riebisch, M.: Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture. In: Proceedings of the 5th Annual International Conference on Object-Oriented and Internet-Based Technologies, Concepts, and Applications for a Networked World, NODe 2004, pp , Lecture Notes in Computer Science, vol Springer, Heidelberg (2004) 26. Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S. M.: N Degrees of Separation: Multi- Dimensional Separation of Concerns. In: Proceedings of the 21st International Conference on Software Engineering 1999, pp , IEEE Computer Society Press (1999) 16

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9)

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9) Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9) Christoph Oberhokamp Franz-Hitze Str. 27, 33102 Paderborn co1@upb.de Abstract.

Mehr

Vom Projekt zum Produkt durch Produktlinien und Variantenmanagement

Vom Projekt zum Produkt durch Produktlinien und Variantenmanagement om Projekt zum Produkt durch Produktlinien und ariantenmanagement Kim Lauenroth paluno the Ruhr Institute for Software Technology Universität Duisburg-Essen Gerlingstraße 16 45127 Essen kim.lauenroth@paluno.uni-due.de

Mehr

Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden

Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden Softwaretechnologie Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden Einleitung Was würden Sie machen, wenn Ihr Auftraggeber oder Chef

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Effiziente Softwareproduktion durch. Effiziente Softwareproduktion durch

Effiziente Softwareproduktion durch. Effiziente Softwareproduktion durch tze Dr. Klaus Schmid Universität Hildesheim Fachbereich III: Informations- und Kommunikationswissenschaften Institut für Mathematik und Angewandte Informatik schmid@sse.uni-hildesheim.de Inhalt 1. Motivation

Mehr

Herausforderungen an ein durchgängiges Variantenmanagement in Software-Produktlinien und die daraus resultierende Entwicklungsprozessadaption

Herausforderungen an ein durchgängiges Variantenmanagement in Software-Produktlinien und die daraus resultierende Entwicklungsprozessadaption Herausforderungen an ein durchgängiges Variantenmanagement in Software-Produktlinien und die daraus resultierende Entwicklungsprozessadaption Christian Manz Research and Development Daimler AG, Germany

Mehr

Software-Produktlinien

Software-Produktlinien Software-Produktlinien Methoden, Einführung und Praxis von Günter Böckle, Peter Knauber, Klaus Pohl, Klaus Schmid 1. Auflage Software-Produktlinien Böckle / Knauber / Pohl / et al. schnell und portofrei

Mehr

Requirements Engineering im SPL-Umfeld

Requirements Engineering im SPL-Umfeld Requirements Engineering im SPL-Umfeld Manuel Wörmann 16.02.2015 Requirements Engineering im SPL-Umfeld Inhalt 1. Definition 2. Ziele 3. Domain Requirements Engineering 4. Application Requirements Engineering

Mehr

State-of-the-Art in Software Product Line Testing and Lessons learned

State-of-the-Art in Software Product Line Testing and Lessons learned State-of-the-Art in Software Product Line Testing and Lessons learned Sebastian Oster Sebastian Oster oster@es.tu-darmstadt.de Tel.+49 6151 16 3776 ES Real-Time Systems Lab Prof. Dr. rer. nat. Andy Schürr

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden. Michael Spijkerman 27.02.2013

Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden. Michael Spijkerman 27.02.2013 Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden Michael Spijkerman 27.02.2013 Methodenentwicklung in s-lab Projekten Strukturierte Entwicklungsmethoden ermöglichen bessere

Mehr

Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung

Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) 1 Agenda Produktlinien

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

Konsolidierung von Software-Varianten in Software-Produktlinien ein Forschungsprogramm

Konsolidierung von Software-Varianten in Software-Produktlinien ein Forschungsprogramm Konsolidierung von Software-Varianten in Software-Produktlinien ein Forschungsprogramm Rainer Koschke Universität Bremen Workshop Software-Reengineering Bad Honnef 5. Mai 2005 Bauhaus Forschungskooperation

Mehr

SPES_XT Abschlussveranstaltung

SPES_XT Abschlussveranstaltung SPES_XT Abschlussveranstaltung EC5: Durchgängiges Variantenmanagement und Wiederverwendung Peter Manhart, Daimler AG Ottobrunn, 10. Juli 2015 EC5 Partner 2 EC5 Überblick Projektergebnisse 05/2014 04/2015

Mehr

Erweiterung eines MDSD-Systems zur Unterstützung von Produktlinien duch Feature-Modelle

Erweiterung eines MDSD-Systems zur Unterstützung von Produktlinien duch Feature-Modelle Erweiterung eines MDSD-Systems zur Unterstützung von Produktlinien duch Feature-Modelle Rolf-Helge Pfeiffer und Peter Hänsgen Intershop Communications AG 07740 Jena h.pfeiffer@uni-jena.de, p.haensgen@intershop.de

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

I. Pflege und Wiederverwendung von Anwendungssoftware-Systemen

I. Pflege und Wiederverwendung von Anwendungssoftware-Systemen I. Pflege und Wiederverwendung von Anwendungssoftware-en SE 2006: Projektvorschläge Fraunhofer IESE PRE Park, Kaiserslautern 19. Januar 2005 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Benutzbare Produktlinien

Benutzbare Produktlinien Benutzbare Integration von und aspekten in der Anforderungsanalyse Isabel John, Kirstin Kohler, Klaus Schmid Erlangen November 2003 Fraunhofer Institut Experimentelles Software Engineering Sauerwiesen

Mehr

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Traceability Workshop SE 2013 Aachen 26. Feb. 2013 Elke Bouillon 1, Baris Güldali 2, Andrea Herrmann 3, Thorsten Keuler

Mehr

Feature Modelling und Product Sets. Seminar Softwareengineering SS 2007 Felix Schwarz, Olaf Otto TU Berlin

Feature Modelling und Product Sets. Seminar Softwareengineering SS 2007 Felix Schwarz, Olaf Otto TU Berlin Feature Modelling und Product Sets Seminar Softwareengineering SS 2007 Felix Schwarz, Olaf Otto TU Berlin Agenda Einleitung Variabilitätsmodellierung und Feature-Bäume Staged Configuration Multi-Level

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

TOGAF The Open Group Architecture Framework

TOGAF The Open Group Architecture Framework TOGAF The Open Group Architecture Ein Überblick Gesellschaft für Informatik, Regionalgruppe München Dr. Michael Bulenda München, 7.12.2009 Vorstellung Dr. M. Bulenda Seit 2001 bei Cirquent IT Management

Mehr

Einführen einer Software Produktlinien

Einführen einer Software Produktlinien Einführen einer Software Produktlinien Zhonghua He Universität Siegen he.zhonghua.0921@gmail.com ABSTRACT Um einen flüchtigen Einblick in die Software Produktlinie (SPL) zu verschaffen, beschäftigt sich

Mehr

End-User Development

End-User Development End-User Development S E M I N A R W E B E N G I N E E R I N G K E N S C H M I D T Betreuer: Alexey Tschudnowsky Gliederung 2 Einleitung End-User Development Nutzergruppen End-User Programming End-User

Mehr

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

Mehr

Application Life Cycle Management

Application Life Cycle Management Application Life Cycle Management Konzepte von ALM Hermann Lacheiner +43 7236 3343 849 Hermann.Lacheiner@scch.at www.scch.at Das SCCH ist eine Initiative der Das SCCH befindet sich im Anwendungsorientierte

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

Standardisiertes Anforderungsmanagement mit Serena Dimensions

Standardisiertes Anforderungsmanagement mit Serena Dimensions AFCEA e.v. Mittagsforum 24.10.2008 Godesburg, Bonn-Bad Godesberg Standardisiertes Anforderungsmanagement mit Serena Dimensions Vorgestellt durch Hans-Joachim Erchinger Michael Lindner Vice President EMEA

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Agile Entwicklung und Architektur. Leon Fausten Grundseminar WS 2014/15 12.12.2014

Agile Entwicklung und Architektur. Leon Fausten Grundseminar WS 2014/15 12.12.2014 Agile Entwicklung und Architektur Leon Fausten Grundseminar WS 2014/15 12.12.2014 Agenda Scrum Motivation Refactoring Das Agile Manifesto und Architektur Agile Model Driven Development Architektur im Sprint

Mehr

Variantenkonfiguration von Modellbasierter Embedded Automotive Software

Variantenkonfiguration von Modellbasierter Embedded Automotive Software Model-Driven Development & Product Lines Leipzig, 19. Oktober 2006 Jens Weiland DaimlerChrysler AG (GR/ESS) Die Rolle von Varianten für den Bereich Automotive Vielzahl variabler Funktionen Beispiel Mercedes

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

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Hetero-Homogene Data Warehouses

Hetero-Homogene Data Warehouses Hetero-Homogene Data Warehouses TDWI München 2011 Christoph Schütz http://hh-dw.dke.uni-linz.ac.at/ Institut für Wirtschaftsinformatik Data & Knowledge Engineering Juni 2011 1 Data-Warehouse-Modellierung

Mehr

Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz ( Version 0.9 )

Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz ( Version 0.9 ) Test von Use Case basierten Produkt Linien mit dem PLUTO Ansatz ( Version 0.9 ) Frederik Eichler, mail@frederik-eichler.de 1. Juli 2008 Universität Paderborn Seminar Software-Qualitätssicherung bei Prof.

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

Agenda. Lösungsentwicklungsprozess Rahmenbedingungen für arvato SPL Entwicklungsarchitektur

Agenda. Lösungsentwicklungsprozess Rahmenbedingungen für arvato SPL Entwicklungsarchitektur Lösungsorientierte Software Produktlinienentwicklung in heterogenen Systemlandschaften Andreas Wübbeke Dr. Thomas von der Maßen Workshop Produktlinien im Kontext 2009 25.05.2009 Agenda Ausgangssituation:

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

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

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

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

Anforderungen und Auswahlkriterien für Projektmanagement-Software Anforderungen und Auswahlkriterien für Projektmanagement-Software Anika Gobert 1,Patrick Keil 2,Veronika Langlotz 1 1 Projektmanagement Payment Giesecke &Devrient GmbH Prinzregentenstr. 159, Postfach 800729,

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

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 2007-09-27 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computing Science, Univ. of Manchester 1989-1995:

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

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

RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen

RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen RTLOpen - Eine Methode zur interdisziplinären Entwicklung von software-intensiven Echtzeit-Systemen Thorsten Keuler (thorsten.keuler@iese.fraunhofer.de) IESE Fraunhofer Institut Experimentelles Software

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

Understanding the Requirements for Developing Open Source Software 17. JuniSystems

Understanding the Requirements for Developing Open Source Software 17. JuniSystems Understanding the Requirements for Developing Open Source Software Systems Integrations Engineering HFU-Furtwangen 17. Juni 2009 2009 1 / 16 1 Autor 2 Paper Thema des Papers Vorgehen des Autors 3 Inhalt

Mehr

Konfigurationsprüfung für Standardsoftware mit Hilfe von Merkmalmodellen

Konfigurationsprüfung für Standardsoftware mit Hilfe von Merkmalmodellen Konfigurationsprüfung für Standardsoftware mit Hilfe von Merkmalmodellen Verification of standardsoftware configurations with feature models Dipl.-Ing. (FH) Wolfgang Frieß, AUDI AG, Ingolstadt Dipl.-Wi.-Inf.

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

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

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

Software Systems Engineering. Sommersemester 2013. Prof. Dr. Klaus Schmid. 28.01.2013, SoSe 13 Prof. Dr. Klaus Schmid 1

Software Systems Engineering. Sommersemester 2013. Prof. Dr. Klaus Schmid. 28.01.2013, SoSe 13 Prof. Dr. Klaus Schmid 1 Software Sommersemester 2013 Prof. Dr. Klaus Schmid 1 Kapitel 1: Java - Grundlagen Inhalt 1. Veranstaltungen im Sommersemester 2013 2 2. Aktuelle Abschluss- und Projektarbeiten 8 3. Offene HiWi Stellen

Mehr

Software-Evolution im Staged Lifecycle Model

Software-Evolution im Staged Lifecycle Model Unterstützung evolutionärer Softwareentwicklung durch Merkmalmodelle und Traceability-Links Matthias Riebisch Technische Universität Ilmenau, matthias.riebisch@tu-ilmenau.de Arbeitsgruppe Software-Wartung

Mehr

Aspektorientierte Softwareentwicklung. Vorstellung

Aspektorientierte Softwareentwicklung. Vorstellung Seminar im Hauptstudium WS 07/08: Aspektorientierte Softwareentwicklung Vorstellung Seite 1 Thema Modularisierung von aus objektorientierter Sicht quer verstreuten Zuständigkeiten (Crosscutting Concerns)

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

Phasen. Gliederung. Rational Unified Process

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

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

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

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

Mehr

Alexander Delater, Barbara Paech RUPRECHT-KARLS-UNIVERSITÄT HEIDELBERG

Alexander Delater, Barbara Paech RUPRECHT-KARLS-UNIVERSITÄT HEIDELBERG , Barbara Paech Ins$tute of Computer Science Chair of So4ware Engineering Im Neuenheimer Feld 326 69120 Heidelberg, Germany hgp://se.ifi.uni- heidelberg.de delater@informa$k.uni- heidelberg.de RUPRECHT-KARLS-UNIVERSITÄT

Mehr

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch Keynote ALMconf 2010 in Stuttgart 26. bis 28. Oktober 2010 Thomas Obermüller elego Software Solutions GmbH - 2010 1 Welcome & Outline Open Source basiertes ALM ganz praktisch Agenda Application Lifecycle

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

Die Macht, die uns umgibt. Design Prinzipien. Schneller und besser Software entwickeln. 2012 Jörg Bächtiger

Die Macht, die uns umgibt. Design Prinzipien. Schneller und besser Software entwickeln. 2012 Jörg Bächtiger Die Macht, die uns umgibt Design Prinzipien Schneller und besser Software entwickeln 2012 Jörg Bächtiger Joerg.Baechtiger@Abraxas.ch http://www.xing.com/profile/joerg_baechtiger Übersicht geben Zusammenhänge

Mehr

Systematische Testfallableitung und Tests durchführen

Systematische Testfallableitung und Tests durchführen Systematische Testfallableitung und Tests durchführen Testen Bereich Kontrolle Aktivität Interne Qualitätssicherung durchführen (Verifikation) Ziele Tests werden systematisch und zielgerichtet erstellt

Mehr

Di 4.1. Variabilitätsmanagement in der Software-Produktlinienentwicklung. Kim Lauenroth

Di 4.1. Variabilitätsmanagement in der Software-Produktlinienentwicklung. Kim Lauenroth Di 4.1 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich ariabilitätsmanagement in der Software-Produktlinienentwicklung Kim Lauenroth ariabilitätsmanagement in der The key

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

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

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

CMMI und SPICE im Automotive Umfeld

CMMI und SPICE im Automotive Umfeld Vorträge 2006 CMMI und SPICE im Automotive Umfeld Inhalt Motivation Übersicht zu CMMI Anwendung in Entwicklungsprojekten Prozess Management als Lösungsansatz SPICE Motivation Jährliche Kosten für Prozessverbesserung

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

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

Toolunterstützte Validierung der Anforderungsabdeckung

Toolunterstützte Validierung der Anforderungsabdeckung Wir nehmen Kurs auf Ihren Erfolg Toolunterstützte Validierung der Anforderungsabdeckung Businessanalyse toolunterstützt DI Mag. Martin Lachkovics 1040 Wien, Operngasse 17-21 Agenda Die heikle Aufgabe der

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

Mehr

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von

Mehr

Software ubiquitärer Systeme

Software ubiquitärer Systeme Software ubiquitärer Systeme Software-Produktlinien Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund Olaf.Spinczyk@tu-dortmund.de http://ess.cs.uni-dortmund.de/~os/

Mehr

Kapitel 1 Software-Prozessmodelle

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

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

Systems Quality Day - Technical

Systems Quality Day - Technical Systems Quality Day - Technical Software Quality in der Praxis - Software-Qualitätsmanagement für den Mittelstand - Frank Guder, Tynos Bremen, 3. Juli 2008 Tynos Software-Qualität und Dienstleistungen

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

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

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

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

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

OGC-konforme Services für 3D-Stadtmodelle

OGC-konforme Services für 3D-Stadtmodelle OGC-konforme Services für 3D-Stadtmodelle Jürgen DÖLLNER Hasso-Plattner-Institut Universität Potsdam www.hpi3d.de Einführung Zum Begriff Service-Oriented Architectures Service-Oriented Architecture - A

Mehr

Universität Passau. Fachbereich Informatik/Mathematik. Bachelorarbeit. im Studiengang Business Administration and Economics

Universität Passau. Fachbereich Informatik/Mathematik. Bachelorarbeit. im Studiengang Business Administration and Economics Universität Passau Fachbereich Informatik/Mathematik Bachelorarbeit im Studiengang Business Administration and Economics Thema: Klassifizierung von Methoden zur Qualitätsbeurteilung in der Software-Produktlinienentwicklung

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

Rich Internet Applications. Leif Hartmann INF-M3 - Seminar/Ringvorlesung - Wintersemester 2007/2008 07. Dezember 2007

Rich Internet Applications. Leif Hartmann INF-M3 - Seminar/Ringvorlesung - Wintersemester 2007/2008 07. Dezember 2007 Rich Internet Applications Leif Hartmann INF-M3 - Seminar/Ringvorlesung - Wintersemester 2007/2008 07. Dezember 2007 Inhalt Einleitung Problemstellungen Daten Anwendungslogik Präsentation Kommunikation

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

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

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

ISO 5500x-Normenfamilie

ISO 5500x-Normenfamilie ISO 5500x-Normenfamilie 5 Fakten zur ISO 5500x-Normenfamilie ISO 55000 - Overview, principles and terminology ISO 55001 - Requirements ISO 55002 - Guidelines on the application of ISO 55001 Generelles

Mehr