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

Evaluierung und Erprobung von Ansätzen beim modellbasierten Design in Software Produktlinien

Evaluierung und Erprobung von Ansätzen beim modellbasierten Design in Software Produktlinien und Erprobung von n beim modellbasierten Design in 15.11.2006 Inhalt Motivation und Motivation und Motivation: für Automotive, Projekt MobilSoft (TP 6) Variantenvielfalt mit SPL und MDA lösen Fragestellung:

Mehr

Application Requirements Engineering

Application Requirements Engineering Application Requirements Engineering - Fokus: Ableitung von Produktanforderungen - Günter Halmans / Prof. Dr. Klaus Pohl Software Systems Engineering ICB (Institute for Computer Science and Business Information

Mehr

Softwareproduktlinien Teil 2: Entwicklungsprozess und Variabilitätsmodellierung

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

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, Thomas Thüm (Universität Magdeburg) 1 Agenda

Mehr

Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik

Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik Ausarbeitung zum Seminar Softwaretechnik, Institut für Softwaretechnik, TU Berlin Dozent: Ramin Tavakoli Koligari

Mehr

Softwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Softwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2010/11 Überblick I Software-Produktlinien Software-Produktlinien:

Mehr

Softwaretechnik. Überblick I. Prof. Dr. Rainer Koschke. Sommersemester 2006

Softwaretechnik. Überblick I. Prof. Dr. Rainer Koschke. Sommersemester 2006 Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Sommersemester 2006 Überblick I 1 Software-Produktlinien Software-Produktlinien:

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

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

Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien

Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien Andreas Wübbeke Sebastian Oster 23.02.2010 ES Real-Time Systems Lab Dept. of Electrical Engineering and

Mehr

Software Produktlinien

Software Produktlinien Software Produktlinien Einführung und Überblick Johannes Diemke Universität Oldenburg Department für Informatik 26111 Oldenburg Zusammenfassung Dieser Artikel soll einen Überblick über den Software Produktlinien

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

Software- Produktlinien

Software- Produktlinien Software- Produktlinien Informatik- Seminar im Rahmen des Studienganges Master Technische Informatik im Modul Software- Projekt- Management Referent: Prof. Dr. Hans Nissen von Karin Schuster Matrikelnummer:

Mehr

Anforderungsmanagement in der Automobilindustrie: Variabilität in Zielen, Szenarien und Anforderungen

Anforderungsmanagement in der Automobilindustrie: Variabilität in Zielen, Szenarien und Anforderungen Anforderungsmanagement in der Automobilindustrie: Variabilität in Zielen, Szenarien und Anforderungen Stan Bühne, Kim Lauenroth, Klaus Pohl Software Systems Engineering, ICB Universität Duisburg-Essen,

Mehr

Software Produktlinien: Einführung und Überblick

Software Produktlinien: Einführung und Überblick C A R L V O N O S S I E T Z K Y Software Produktlinien: Einführung und Überblick Johannes Diemke Vortrag im Rahmen des Seminars Software System Engineering im Wintersemester 2007/2008 Übersicht 1 Motivation

Mehr

Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 3: Software-Produktlinien

Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 3: Software-Produktlinien Erweiterte Programmierkonzepte für maßgeschneiderte Datenhaltung Teil 3: Software-Produktlinien Sven Apel, Christian Kästner, Gunter Saake Apel, Kästner, Saake EPMD Folie 3-2 Agenda Produktlinien und Programmfamilien

Mehr

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation

Mehr

Product Line Engineering (PLE)

Product Line Engineering (PLE) Product Line Engineering (PLE) Produktlinienentwicklung Von Christoph Kuberczyk Christoph Kuberczyk, SE in der Wissenschaft 2015, Product Line Engineering 1 Gliederung 1. Was ist PLE? 2. Motivation 3.

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

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Feature Net ein Ansatz zur Modellierung von automobilspezifischem Domänenwissen und Anforderungen

Feature Net ein Ansatz zur Modellierung von automobilspezifischem Domänenwissen und Anforderungen Feature Net ein Ansatz zur Modellierung von automobilspezifischem Domänenwissen und Anforderungen J. Hartmann, A. Fleischmann, C. Pfaller, M. Rappl, S. Rittmann, D. Wild Lehrstuhl für Systems und Software

Mehr

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Sebastian Oster, Philipp Ritter, Andy Schürr Sebastian Oster oster@es.tu-darmstadt.de Tel.+49 6151/16-3776 ES Real-Time Systems

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

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

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

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

Variabilitätsmodellierung in Softwareproduktlinien

Variabilitätsmodellierung in Softwareproduktlinien Variabilitätsmodellierung in Softwareproduktlinien Universität Siegen Siegen, den 16. Februar 2015 1 Variabilität Definition Variabilität Variationspunkt Variante Arten von Variabilität Interne vs Externe

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

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

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

Entwicklung verteilter eingebetteter Systeme. Visual Variability Analysis for Goal Models

Entwicklung verteilter eingebetteter Systeme. Visual Variability Analysis for Goal Models Ausarbeitung für das Seminar Entwicklung verteilter eingebetteter Systeme zum Thema Visual Variability Analysis for Goal Models Maximilian Schwerin 1 Technische Universität Berlin maximili@cs.tu-berlin.de

Mehr

Dokumentation spezifischer Anforderungen im Application Requirements Engineering der Produktlinienentwicklung 1

Dokumentation spezifischer Anforderungen im Application Requirements Engineering der Produktlinienentwicklung 1 Dokumentation spezifischer Anforderungen im Application Requirements Engineering der Produktlinienentwicklung 1 Günter Halmans, Klaus Pohl Software Systems Engineering Institut für Informatik und Wirtschaftsinformatik

Mehr

Integration Software und Usability Engineering. Arash Faroughi Roozbeh Faroughi FH-Köln Campus Gummersbach

Integration Software und Usability Engineering. Arash Faroughi Roozbeh Faroughi FH-Köln Campus Gummersbach Integration Software und Usability Arash Faroughi Roozbeh Faroughi FH-Köln Campus Gummersbach November 02, 2007 Einleitung Wie kann man die Lücke zwischen Software und Usability schließen? ca. 30 paper

Mehr

Feature Modelle. und ihre Anwendung. Feature Modelle und ihre Anwendungen. Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn

Feature Modelle. und ihre Anwendung. Feature Modelle und ihre Anwendungen. Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Feature Modelle und ihre Anwendung Feature Modelle und ihre Anwendungen 22.07.2010 1 Software-Produktlinien Zusammenfassung mehrerer verwandter Softwaresysteme zu einer Domäne (Anwendungsgebiet) Softwaresysteme

Mehr

Software Product Line Engineering

Software Product Line Engineering Software Product Line Engineering Grundlagen, Variabilität, Organisation Sebastian Steger steger@cs.tu-berlin.de WS 2005/2006 SWT: Entwicklung verteilter eingebetteter Systeme Software Product Line Engineering

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

Generatives Programmieren

Generatives Programmieren Generatives Programmieren Seminar Produktlinien WS03/04 Tammo van Lessen 08.01.2004 Outline Einleitung Generatoren Generatives Programmieren Fazit Einleitung Industrielle Entwicklung 1826 Austauschbare

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

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

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

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

Feature-basierte Modellierung und Verarbeitung von Produktlinien am Beispiel eingebetteter Software

Feature-basierte Modellierung und Verarbeitung von Produktlinien am Beispiel eingebetteter Software Feature-basierte Modellierung und Verarbeitung von Produktlinien am Beispiel eingebetteter Software 1 Christian Berger, 2 Holger Krahn, 1 Holger Rendel, 1 Bernhard Rumpe 1 RWTH Aachen Lehrstuhl für Software

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

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Vortrag im Rahmen des Proseminars Softwarequalität und -sicherheit von Marion Weber SS 2010 1 Einführung & Motivation Variabilität

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

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

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

Softwareproduktlinien Teil 2: Entwicklungsprozess und Variabilitätsmodellierung

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

Mehr

Data Processing, On-Board Software & Dependability (ASG72, ASG73)

Data Processing, On-Board Software & Dependability (ASG72, ASG73) Data Processing, On-Board Software & Dependability (ASG72, ASG73) Aktuelle Aktivitäten und Möglichkeiten der Zusammenarbeit Name: Norbert Binzer, Abt. ASG72 DLR - Raumfahrt-Industrietage in Friedrichshafen

Mehr

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8 Prof. Dr. Wilhelm Schäfer Paderborn, 8. Dezember 2014 Christian Brenner Tristan Wittgen Besprechung der Aufgaben: 15. - 18. Dezember 2014 Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung

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

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

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

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 in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Bernd Hedenetz, Markus Conrath, Klaus D. Müller-Glaser* E/E- (GR/PSA) Daimler AG

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

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Michael Eisenbarth Abteilung Requirements- und Usability-Engineering Fraunhofer-Institut für Experimentelles Software Engineering

Mehr

Feature-orientierte Plattformentwicklung und Verfolgbarkeit

Feature-orientierte Plattformentwicklung und Verfolgbarkeit Feature-orientierte Plattformentwicklung und Verfolgbarkeit Robert Brcina, IT-Designers GmbH Markus Prechtel, DaimlerChrysler AG Abstrakt Der Gewinn durch Wiederverwendung bei der Softwareentwicklung ist

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

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

Domain Analysis und Scoping

Domain Analysis und Scoping Domain Analysis und Scoping Wadim Schleicher Universität Stuttgart Universitätsstr. 38 D-70565 Stuttgart schleiwm@studi.informatik.uni-stuttgart.de Zusammenfassung Das Produktlinienengineering (PLE) hat

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

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Gliederung 1. Generative Programmierung 2. Möglichkeiten und Einsatzgebiet 3. Prozess / Tools 4. Zusammenfassung 19.03.2009 GENERATIVE PROGRAMMIERUNG

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

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

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien Arbeitsberichte des Instituts für Informatik Friedrich-Alexander-Universität Erlangen Nürnberg Band 40 Nummer 4 Juli 2007 Stefan Kubica Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

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

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

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

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

2. Automatische Codegenerierung mittels dynamischer Spezialisierung

2. Automatische Codegenerierung mittels dynamischer Spezialisierung 2 Automatische Codegenerierung mittels dynamischer Spezialisierung 1/16 Quelle: Vicente Pelechano, Oscar Pastor, Emilio Insfran Automated code generation of dynamic specializations: An approach based on

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

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

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

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

Unterschiede zur Klassischen Software-Entwicklung. SPL versus klassische SE Tim Serowski 1

Unterschiede zur Klassischen Software-Entwicklung. SPL versus klassische SE Tim Serowski 1 Unterschiede zur Klassischen Software-Entwicklung SPL versus klassische SE Tim Serowski 1 Agenda Kurzüberblick Fertigungsprozess Wiederverwendbarkeit von Komponenten Versionierung Kosten / Nutzen einer

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

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile

Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Übersetzung des Singapore Framework für Dublin-Core-Anwendungsprofile Identifier: http://www.kimforum.org/material/pdf/uebersetzung_singapore_20090213.pdf Title: Übersetzung des Singapore Framework für

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

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

(BABOK-v3-Technik 10.41)

(BABOK-v3-Technik 10.41) (BABOK-v3-Technik 10.41) Allgemeines Scope-Modelling gibt Antworten auf die Fragen Was gehört zum System und was nicht? sowie Woher kommen die Anforderungen? Diese Fragen sollten generell zu Beginn jeder

Mehr

Requirements-basiertes Testen am Beispiel des NI Requirements Gateways

Requirements-basiertes Testen am Beispiel des NI Requirements Gateways Requirements-basiertes Testen am Beispiel des NI Requirements Gateways National Instruments VIP Kongress München, M 8. Oktober 2008 Joachim Schulz QualityPark GmbH V-Modell Demands Business Requirement

Mehr

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012 Einführung in modellgetriebene Softwareentwicklung 24. Oktober 2012 Überblick Was sind die Grundprinzipien der modellgetriebenen Softwareentwicklung? Entwicklung einer MDD-Infrastruktur Modellgetriebene

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

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

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Tracing von Anforderungen Eine tool-unabhängige Betrachtung

Tracing von Anforderungen Eine tool-unabhängige Betrachtung Tracing von Anforderungen Eine tool-unabhängige Betrachtung Markus Won 03.09.2014 Der Begriff Traceability Traceability Kleine funktionale Anforderung im Rahmen des Requirements Management mit weitreichenden

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

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

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

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

Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben)

Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben) Komponenten Einführung Organisatorisches 2+1 SWS Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben) Klausur 28. Februar 2013 Unterlagen

Mehr

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

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

Mehr

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

Entwicklungswerkzeuge

Entwicklungswerkzeuge Entwicklungswerkzeuge Werner Struckmann & Tim Winkelmann 10. Oktober 2012 Gliederung Anforderungen Projekte Debugging Versionsverwaltung Frameworks Pattern Integrated development environment (IDE) Werner

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

Anforderungen: Management

Anforderungen: Management Anforderungen: Management Anforderungen: Management Der Begriff der Anforderungsanalyse ist grundsätzlich vom Begriff des Anforderungsmanagements zu trennen, obwohl beide Konzepte in vie l- fältiger Weise

Mehr