Softwareproduktlinien-Entwicklung Domain Engineering: Konzepte, Probleme und Lösungsansätze
|
|
- Pia Ursler
- vor 8 Jahren
- Abrufe
Transkript
1 UNIVERSITÄT LEIPZIG Fakultät für Mathematik und Informatik Institut für Informatik Softwareproduktlinien-Entwicklung Domain Engineering: Konzepte, Probleme und Lösungsansätze Betrachtung im Rahmen einer Fallstudie über die Entwicklung eines Portals und eines Frameworks zur Unterstützung elektronischer Prüfungsabläufe Diplomarbeit Leipzig, April 2007 vorgelegt von Berger, Thorsten geboren am 26. Oktober 1981 Studiengang Informatik
2 Abstract Software Product Line Engineering (SPLE) has become the most successful approach for software reuse in the last ten years. It has proven to reduce development times, lower costs and improve the quality of software-intensive systems. One of its key points is the up-front development of a flexible and highly extensible platform (Domain Engineering) as a basis for deriving concrete applications (Application Engineering). The thesis describes the Domain Engineering in a case study that deals with the development of an Open Source project in the J2EE environment. It mainly focuses on concerns regarding the high-level architecture and process descriptions as proposed by the framework. To fit the needs of the project it also had to be tailored in numerours aspects. Furthermore, the experience gained during the lifecycle of the project yields an estimation of theoretical and practical issues of the development approach. The thesis also shows open questions in the SPLE research field. One of the most important enablers of SPLE in the case study has been the usage of J2EE portal standards, which provide an extensive infrastructure for web application delivery and integration. In a product line view, portals offer mechanisms for extreme late binding of complex functionality. However, there have been many more technologies and frameworks that supported building the platform. These have been e.g. an IoC component framework, MVC frameworks, AOP or model-driven/generative approaches, whose application in the product line context of the case study will be shown. The case study comprises the Domain Requirements Engineering, Domain Design and Domain Realisation subprocesses of the Product Line Framework. In addition, an overview of verification and validation techniques (static analysis as well as the Domain Testing) for the platform will be shown. 1
3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Abgrenzung Aufbau der Arbeit Betrachtungsgegenstand Entstehung elateportal-projekt Technologien, Umgebungen und Ansätze Weitere Arbeiten Softwareproduktlinien Grundlagen und Definition Begriffsbestimmung Klassisches Domain Engineering Vorteile Kosten und Risiken Methodiken und Frameworks Produktlinien-Framework Referenzprozess Product Management Variabilitäts-Modell Einfluss agiler Prinzipien Domain Requirements Engineering Kontext Artefakte Vorgehen und Aktivitäten Basisanforderungen in der Fallstudie Commonality Analysis Variability Analysis Variability Modelling Auswertung Domain Design Kontext Artefakte Vorgehen und Aktivitäten Komponenten-Framework Referenzarchitektur
4 Inhaltsverzeichnis 6.6 Aufgaben-Framework elateportal Prüfungsserver Auswertung Domain Realisation Kontext Artefakte Vorgehen und Aktivitäten Build-Management und Deployment Detailliertes Design des Aufgaben-Frameworks Detailliertes Design des elateportals Detailliertes Design des Prüfungsservers Bindung von Variabilität Auswertung Verifikation und Validierung Inspektionstechniken Domain Testing Automatische statische Analyse Unit-Tests Integrations-Tests System-Tests Zusammenfassung Produktlinien-Forschung Tailoring und Praxis Ausblick Anhang A.1 Aufgaben-Framework: Implementierte Aufgabentypen A.2 Orthogonales Variabilitätsmodell A.3 Detaillierte Design-Artefakte A.4 Test-Strategien für Produktlinien Abbildungsverzeichnis Abkürzungsverzeichnis Literaturverzeichnis
5 Einleitung 1 Einleitung 1968 wurde auf einer NATO-Konferenz in Garmisch-Partenkirchen zum ersten Mal der Begriff des Software Engineering in Bezug auf die ingenieurmäßige Erstellung von softwareintensiven Systemen geprägt. Diese Disziplin stellte eine Antwort auf die damalige Software-Krise dar und hat im Laufe der Zeit verschiedene Methodiken zur Entwicklung von Software hervorgebracht. Während lange Zeit schwergewichtige und streng phasenorientierte Entwicklungsprozesse das Software Engineering dominierten, die sich für große Systeme mit einer langen Lebensdauer bewährt haben, sind seit den letzten zehn Jahren neue Trends erkennbar, die den geänderten Anforderungen an heutige Software Rechnung tragen sollen. Software muss schneller entwickelt werden können, soll besser an sich ändernde Umgebungen anpassbar sein und trotzdem weniger Kosten verursachen sowohl in der Entwicklung als auch in der Wartung. Außerdem werden heute viel seltener Systeme von Grund auf neu entwickelt, häufiger soll bestehende Software wiederverwendet oder mit anderen Legacy-Applikationen kombiniert werden. Ältere Entwicklungsmethoden erwiesen sich in diesen Bereichen als zu starr, wenig anpassbar und erzeugten häufig unnötigen Overhead. Der sich ändernde Kontext des Software Engineerings führte zu einem Umdenken in zwei Richtungen: zum einen in der Favorisierung leichtgewichtiger, stark adaptiver Entwicklungsparadigmen und zum anderen in der Serienfertigung von Software durch Ausnutzen des Wiederverwendungspotentials bestehender Produkte. Letzteres wird auch als Industrialisierung des Software Engineerings bezeichnet, in Anlehnung an traditionelle Entwicklungszweige wie die Automobilindustrie, die bereits seit langer Zeit auf standardisierte und flexibel verwendbare Bauteile setzen. Neben neuen Vorgehensweisen bestimmen aber mittlerweile auch neue Architekturansätze und Technologien das Software Engineering. Dazu gehören beispielsweise die Serviceorientierte Architektur, Generative bzw. Modellbasierte Entwicklung oder ausgereiftere Komponententechnologien. Trotz signifikanter Fortschritte stellt Software Engineering noch keine reife Disziplin in der Informatik dar [Pa98b]. Dazu gibt es nach wie vor zu viele Projekte, die nicht im anvisierten Zeitrahmen, nicht mit dem veranschlagten Budget oder sogar überhaupt nicht fertiggestellt werden können [St03]. Die Ursachen für diese Probleme sind vielfältig und ihre Identifizierung ist Aufgabe der aktuellen Forschung. 1.1 Motivation Mit Software-Wiederverwendung wird die Vorgehensweise bezeichnet, Softwareprodukte nicht von Grund auf neu zu erstellen, sondern aus bereits entwickelter Software abzuleiten. Obwohl die Idee bereits 1968 von McIlroy [Il68] innerhalb der NATO-Konferenz als einfache und leistungsfähige Lösung der Software-Krise aufgezeigt worden ist, dauerte es mehr als 20 Jahre bis man im Software Engineering von funktionierenden Ansätzen zur Software-Wiederverwendung sprechen konnte. Obwohl die Idee relativ einfach erschien, gestaltete sich die Praxis als ausgesprochen schwierig. Durch mittlerweile verfügbare neue Technologien und umfassendere Abstraktionskonzepte konnten sich in den letzten zehn bis 15 Jahren funktionierende Ansätze zur Software- Wiederverwendung etablieren. Einen der erfolgreichsten stellt dabei die Softwareprodukt- 4
6 Einleitung linien-entwicklung dar, die ihre praktische Anwendbarkeit in zahlreichen Projekten bewiesen hat. Dafür existieren verschiedene Studien, die den Erfolg von Produktlinien in großen Organisationen mit kommerziellem Hintergrund belegen [CN01]. Während auch Erfahrungsberichte zur Einführung von Produktlinienentwicklung in kleinen und mittelgroßen Unternehmen verfügbar sind [Kn00, VK05], ist mittlerweile noch keine Fallstudie bekannt, welche die Anwendbarkeit des Ansatzes im Rahmen von Open- Source-Projekten untersucht, die oft auf weiterer freier Software basiert und die teilweise ihren eigenen Gesetzen und Regeln folgt. 1.2 Zielsetzung In der vorliegenden Arbeit erfolgt eine Betrachtung des Softwareproduktlinien-Ansatzes anhand einer Fallstudie. Es wird die Entwicklung einer Plattform im Rahmen eines Open- Source-Projektes beschrieben, das aus den Anforderungen von drei Fakultäten an der Universität Leipzig entstanden ist. Die Ausarbeitung zielt auf eine Beantwortung der folgenden Fragestellungen, die sich auf zwei verschiedenen Abstraktionsebenen ergeben und eng miteinander verknüpft sind. Zum einen sind das auf einer theoretischen Ebene: (1) Wodurch ist die Produktlinienentwicklung charakterisiert, wie ist ihr Kontext im Software Engineering und von welchem Forschungsstand kann ausgegangen werden? (2) Welche Problemstellungen der Produktlinienentwicklung sind identifizierbar, für die weitere Forschung notwendig ist? Auf einer praxisorientierten Ebene wird im Rahmen der Fallstudie die Anwendung eines Produktlinien-Frameworks auf das Projekt erläutert. Insbesondere zielt die Arbeit auf eine Darstellung von Ansätzen, wie ein Tailoring auf Projekte mit ähnlicher Ausrichtung möglich ist. Auf dieser Ebene wird eine Beantwortung der folgenden Fragestellungen verfolgt: (3) Wie wurde das Framework auf die Anforderungen in der Fallstudie maßgeschneidert? (4) Welchen Einfluss hatten die verwendeten Technologien und wie konnten sie die Entwicklung unterstützen? 1.3 Abgrenzung Abbildung 1 zeigt vier Belange, mit denen sich die Produktlinienforschung befasst. Während die meisten Produktlinien-Methodiken auf eine umfassende Unterstützung der Entwicklung zielen, ist der Fokus dieser Arbeit auf die folgenden zwei Belange gerichtet. 5
7 Einleitung Business Architecture Process Organisation Abbildung 1 BAPO-Modell (nach [Li02]) So konzentriert sich die Arbeit auf die Architektur und den Prozess zur Entwicklung der Plattform (Architecture und Process), sie beschäftigt sich weder mit wirtschaftlichen noch mit organisationsspezifischen Aspekten (Business und Organisation). Zu letzteren wird jedoch eine Übersicht gegeben, die zur Charakterisierung der Produktlinienentwicklung notwendig ist und ihre Popularität aufzeigt. Weiterhin wird in der Produktlinienentwicklung zwischen zwei Hauptprozessen unterschieden: Domain Engineering, das der Entwicklung einer (Produktlinien-)Plattform dient Application Engineering, das konkrete Applikationen aus der Plattform ableitet Die Arbeit fokussiert in der Fallstudie das Domain Engineering. Hingegen werden zum Application Engineering nur einige Charakteristika aufgezeigt, die Auswirkungen auf das Tailoring des verwendeten Produktlinien-Frameworks hatten. In der Arbeit werden Ausschnitte von Diagrammen und Modellen dargestellt, die zur Erläuterung relevanter Artefakte bzw. Vorgehensweisen notwendig sind. Aufgrund des Projekt-Umfangs ist keine detaillierte Darstellung des gesamten Entwicklungsprozesses möglich. Für weitergehende Implementierungs-Details sei auf die Projekt-Homepage (siehe Kapitel 2.2) verwiesen. 1.4 Aufbau der Arbeit Das Kapitel 2 stellt zunächst den Betrachtungsgegenstand der Fallstudie vor. Kapitel 3 enthält eine Einführung in den Produktlinien-Ansatz, in der eine grundlegende Charakterisierung erfolgt. Insbesondere werden Punkte betrachtet, die den Erfolg von Softwareproduktlinien im Software Engineering erläutern. Daran schließt sich eine Übersicht zu den wichtigsten Produktlinien-Frameworks an und Kapitel 4 beschreibt das ausgewählte Framework im Hinblick auf die Fallstudie genauer. Die nächsten drei Kapitel stellen den Hauptteil der Arbeit dar, in denen mit einem Top- Down-Ansatz jeweils die produktlinienspezifischen Aspekte bei der Entwicklung des Projekts dargestellt werden. So befasst sich Kapitel 5 mit dem Requirements Engineering, Kapitel 6 mit dem groben Design in Form der Referenzarchitektur und Kapitel 7 mit dem detaillierten Design sowie der Implementierung. In jedem Kapitel erfolgt zunächst eine Erläuterung der Theorie, daran schließt sich eine spezifische Betrachtung innerhalb der 6
8 Einleitung Fallstudie an und am Ende wird eine Auswertung sowohl nach praktischen als auch theoretischen Gesichtspunkten gegeben. Kapitel 8 enthält darüber hinaus Ausführungen zur Verifikation und Validierung der entwickelten Plattform. Die Arbeit schließt mit einer Zusammenfassung der gesamten Vorgehensweise in Kapitel 9 ab, in der eine Beurteilung erfolgt, wie die Fragestellungen aus der Zielsetzung beantwortet werden konnten. 7
9 Betrachtungsgegenstand 2 Betrachtungsgegenstand In diesem Kapitel erfolgt eine Einführung in das elateportal-projekt als Betrachtungsgegenstand der Fallstudie. Beginnend mit einem kurzen Abriss über die Entstehungsgeschichte werden fachliche Aspekte des Projekts erläutert. Das beinhaltet zum einen die Funktionalität des Systems sowie eine Beschreibung von Einsatzszenarien an der Universität Leipzig, aber auch technische und organisatorische Rahmenbedingungen. Insbesondere werden Gründe aufgezeigt, die zur Anwendung eines Produktlinien-Ansatzes geführt haben. Das Gesamtprojekt ist bereits in [BW06] vorgestellt worden, wobei der Fokus auf Architektur-Gesichtspunkten lag. Insbesondere enthält die Veröffentlichung eine Schilderung von Praxiserfahrungen, die durch den Einsatz des elateportals gewonnen werden konnten. 2.1 Entstehung Die Idee hinter der Einführung des elateportal-projekts lässt sich auf das ältere und wesentlich kleinere Open-Source-Projekt UebManager 1 zurückführen, das eine webbasierte Umgebung zur Unterstützung von Übungsseminaren bereitstellte und erfolgreich an der Abteilung Betriebliche Informationssysteme 2 (BIS) der Universität Leipzig eingesetzt worden ist. Es war ausgerichtet auf typische Abläufe in einem Übungsbetrieb wie Einschreibungen, Bereitstellung von Unterrichtsmaterialien oder die Kommunikation mittels Foren. Hauptbestandteil war die Durchführung und Korrektur von Übungsserien, bei denen von Teilnehmern Lösungen in Form von PDF-Dateien hochgeladen oder Multiple-Choice-Fragen beantwortet werden konnten. Basierend auf den Ergebnissen wurden die Teilnehmer automatisch zur Klausur zugelassen. Nach der reinen Verwendung im Übungsbetrieb kamen weitere Einsatzszenarien hinzu, welche auf die Durchführung von Prüfungsklausuren unter Examensbedingungen in der Erziehungswissenschaftlichen Fakultät 3 zielten. Gründe dafür stellten hohe Prüfungsbelastungen in Grundstudiums-Vorlesungen durch bis zu 900 Teilnehmer sowie eine aufwendig zu korrigierende Papierklausur dar. Auf Basis des UebManager-Projekts wurde zunächst ein Prototyp entwickelt, der zur ersten elektronischen Klausur im Wintersemester 2004 an der Erziehungswissenschaftlichen Fakultät führte. Da das vorhandene alte Aufgabenmodell für den Übungsbetrieb die neuen Anforderungen nicht realisieren konnte, bestand ein Hauptteil der Arbeit in der Entwicklung eines neuen Modells für komplexere Aufgaben sowie einen umfassenderen Prüfungsablauf. Eine Eigenentwicklung war notwendig, da verfügbare Lösungen entweder kommerziell waren oder für den anvisierten Einsatz nur einen ungenügenden Funktionsumfang aufwiesen und keine vollständige Unterstützung von Prüfungsprozessen besaßen. Außerdem fehlten den meisten Lösungen angemessene Erweiterungsmöglichkeiten, mit denen man sie hätte adaptieren können
10 Betrachtungsgegenstand Obwohl der Prototyp ausgeprochen stabil lief und der erste Einsatz uneingeschränkt positiv ausfiel, zeigten sich schnell Grenzen auf. So war die Architektur des UebManagers nicht auf derartige Erweiterungen wie das neue Aufgabenmodell ausgelegt, es mussten viele Änderungen, auch in Kernbereichen, vorgenommen werden. Das machte den Prototypen inkompatibel mit anderen Versionen des UebManagers. Die Folge war, dass mit angemessenem Aufwand keine konsistente Weiterentwicklung der UebManager-Basis mehr möglich war. Darüber hinaus hatte das Projekt verschiedene weitere Grenzen, die seine Einsatzmöglichkeiten beschränkten (vgl. [Be05a]). Inzwischen bestand auch Interesse am Einsatz für elektronische Prüfungen seitens der Selbständigen Abteilung für Allgemeinmedizin 1, die außerdem eine Web-Präsenz benötigte. So existierten schließlich Anforderungen an ein neues System in unterschiedlichen Ausprägungen von drei verschiedenen Abteilungen. Einerseits war die Unterstützung eines integrierten Ablaufs für Prüfungsklausuren und Übungsaufgaben von zentraler Bedeutung, andererseits sollten weitere universitäre Abläufe durch das System umgesetzt werden. Dazu kamen hohe Sicherheitsanforderungen, welche z.b. eine Trennung sensibler Prüfungsdaten von (ebenso sensiblen) Einschreibungs- und Studentendaten erforderten. 2.2 elateportal-projekt Neben den genannten Anforderungen und Einsatzszenarien lag ein weiteres Ziel in der Entwicklung einer Plattform, die auch für weitere Projekte ähnlicher Ausrichtung verwendet werden kann und sich in ein Umfeld vorhandener (Hochschul-) Informationssysteme integrieren lässt. Das elateportal-projekt startete im Sommer 2005 und ist unter der GNU Public License (GPL v.2) lizenziert. Die Projektseite ist über erreichbar und wird von SourceForge.net 2 gehostet. Über sie sind die Quelltexte, Dokumentationen, Bug- und Feature-Tracker sowie die Mailinglisten des Projekts verfügbar
11 Betrachtungsgegenstand Taskmodel-CORE-VIEW Taskmodel-API Taskmodel-CORE (RI mit Spring) TaskletContainer Lifecycle Tasklet TaskDef TaskletCorrection Web Service examserver J2EE-Webapplikation elateportal J2EE-Portalapplikation Abbildung 2 elateportal, Prüfungsserver und Aufgaben-Framework Dabei bezeichnet das elateportal-projekt die Gesamtheit aus dem elateportal, dem Prüfungsserver, einem Aufgaben-Framework sowie einem Editor zur Erstellung von komplexen Aufgaben bzw. von Aufgaben-Pools. In Abbildung 2 sind die beiden erstgenannten Systeme, in denen jeweils eine Implementierung des Aufgaben-Frameworks enthalten ist, dargestellt elateportal Das elateportal ist eine J2EE-Portalapplikation [AH03], die zur Organisation und zum Management von Lehrveranstaltungen eingesetzt wird, wobei hier der Fokus auf einer Integrierbarkeit mit vorhandenen (Hochschul-) Informationssystemen sowie der Unterstützung elektronischer Klausuren liegt. Die folgenden Screenshots vermitteln einen ersten Eindruck 1 über das elateportal. In Abbildung 3 ist die persönliche Oberfläche eines Nutzers dargestellt, die er an seine Bedürfnisse anpassen kann, wie in Abbildung 4 zu sehen ist. Insbesondere ermöglicht das Portal das Hinzufügen weiterer Anwendungen (Portlets), wie bspw. das Portlet zur Darstellung von RSS-Feeds links unten. 1 siehe auch: 10
12 Betrachtungsgegenstand Abbildung 3 Persönliche Oberfläche Abbildung 4 Anpassung der Oberfläche 11
13 Betrachtungsgegenstand Die nächsten Abbildungen zeigen jeweils verschiedene Administrations-Portlets. Abbildung 5 -benachrichtigungen In Abbildung 5 ist ein Portlet zum Editieren von -vorlagen abgebildet. Derartige s werden auf verschiedene Ereignisse von Komponenten verschickt, z.b. bei der Erstellung von News- und Foren-Beiträgen oder bei der Registrierung am Portal. Abbildung 6 Veranstaltungs-interne Einschreibungen 12
14 Betrachtungsgegenstand Abbildung 6 zeigt die Administration von Einschreibungen, die innerhalb von Veranstaltungen angelegt werden können, wie bspw. Tutorien, Übungsgruppen oder die Wahl des Prüfungstermins. Abbildung 7 Veranstaltungs-Konfiguration 13
15 Betrachtungsgegenstand Die Oberfläche zur Konfiguration von Veranstaltungen ist in Abbildung 7 dargestellt und ermöglicht neben allgemeinen Einstellungen auch die Konfiguration von Fragen zur Einschreibung sowie deren Restriktion durch Kennungen und Transaktionsnummern (TANs) Prüfungsserver Der Prüfungsserver stellt eine leichtgewichtige Webapplikation für die Durchführung von Prüfungsklausuren dar, wobei er entweder eigenständig oder mit Anbindung an das elateportal verwendet werden kann. Seine Installation erfolgt nur zur Prüfung und der Zugriff ist auf das Computerkabinett beschränkt. Nach Ende einer Prüfungsperiode kann er archiviert und wieder gelöscht werden. Abbildung 8 Prüfungsserver Aufgaben-Framework Zur Unterstützung umfassender Prüfungsabläufe wurde ein eigenständiges Framework mit der folgenden Zielsetzung entwickelt: Erweiterbarkeit mit neuen Aufgabentypen Integrierbarkeit in verschiedene (Java-)Systeme Unterstützung eines Prüfungsprozesses, der von Einschreibung über die Durchführung bis zur Einsichtnahme reicht. Derzeit sind fünf Aufgabentypen implementiert: Multiple-Choice (Einfach- als auch Mehrfachauswahl), Zuordnung, Lückentext, Freitext und Graphische Darstellung. Abbildungen von Beispiel-Aufgaben sind in Anhang A.1 zu finden. Das Framework unterstützt die Erstellung von Fragenpools, die randomisierte Zusammenstellung individueller Prüfungen und insbesondere die semiautomatische Korrektur von Aufgaben. Letzteres bedeutet, dass nicht automatisch auswertbare Aufgaben Korrektoren zugeordnet werden können. 14
16 Betrachtungsgegenstand In der Praxis erfolgte die Korrektur von bis zu 900 Klausuren in einer Korrektursitzung mit ca. 15 studentischen Hilfskräften (SHK) innerhalb von ca. zwei Stunden. Es mussten nur Freitext- und Graphikaufgaben manuell korrigiert werden. Lückentexte wurden nur in Zweifelsfällen den SHKs vorgelegt. Das Aufgaben-Framework stellt ein zentrales Artefakt im elateportal-projekt dar, dessen Referenzimplementierung in das elateportal und den Prüfungsserver integriert ist. Abbildung 9 zeigt beispielhaft die Oberfläche einer Pädagogik-Übungsklausur. Abbildung 9 Klausur-Oberfläche Aufgaben-Editor Der als Desktop-Applikation eigenständige Aufgaben-Editor dient der Erstellung und Bearbeitung von Aufgaben-Pools, die als XML-Dokumente abgespeichert werden. Aufgrund der Komplexität des dazugehörigen XML-Schemas (siehe Abbildung 55, Anhang A.3) wurde zur Entwicklung des Editors ein modellbasierter Ansatz in Form des kommerziellen JAXFront 1 verwendet. Obwohl während der Entwicklung des Editors umfangreiche Erfahrungen mit dem in dieser Form einzigartigen modellbasierten Ansatz von JAXFront gemacht werden konnten, stellt er keinen Betrachtungsgegenstand der Fallstudie dar. Interessant ist jedoch, dass JAXFront zwar zu den modellbasierten Ansätzen, jedoch nicht zu den generativen [CE00] gehört, da es keinen Code erzeugt. Stattdessen erstellt JAXFront erst zur Laufzeit eine
17 Betrachtungsgegenstand Editor-Oberfläche, die entsprechend aus einem Objekt-Baum in Form von Java-Swing- Elementen besteht. Sie repräsentieren die Struktur des XML-Schemas. Abbildung 10 zeigt die Erstellung einer Aufgabe des Typs Graphische Darstellung mit dem Editor. Abbildung 10 Graphik-Aufgabe im Aufgaben-Editor 2.3 Technologien, Umgebungen und Ansätze Das gesamte Projekt wurde überwiegend mit Frameworks und Technologien aus der J2EE- Plattform [Su03a] sowie deren Umfeld entwickelt. Von zentraler Bedeutung für das elateportal war die Verwendung eines Portalservers in Form von Apache Jetspeed-2 1, der zum Java-Portlet-Standard JSR168 [AH03] kompatibel ist. Der Vorteil von Portalen lag zum einen in der Bereitstellung einer grundlegenden Infrastruktur für das elateportal sowie in der Erweiterbarkeit mit fremden, JSR168- kompatiblen Portlets. Letztere stellen in Portalen die eigentliche und auch beliebig umfangreiche Funktionalität dar. Sie werden wiederum zu sog. Portletapplikationen zusammengefasst. Außerdem stellen Portale eine einheitliche, personalisierbare Oberfläche, Single-Sign-On-Funktionalität (SSO) und Sicherheitsmodelle (i.d.r. basierend auf dem JAAS 2 -Framework) bereit. Für einen Überblick über J2EE-Portalserver sowie eine Einführung in verschiedene Standards aus diesem Bereich sei an dieser Stelle auf [LM04, Be05b] verwiesen. Darüber hinaus kamen bei der Entwicklung des elateportal-projekts u.a. auch aspektorientierte Programmierung (AOP) und Generative (GSE) bzw. Modellbasierte Ansätze (MDE) zum Einsatz. Ein Standardwerk zu GSE stellt [CE00] dar, das die Erstellung von Produktlinien durch Code-Generierung verfolgt. Für eine Einführung in MDE-Techniken,
18 Betrachtungsgegenstand die häufig GSE zugeordnet werden 1, sei auf [VS06, BBG05] verwiesen. Neben dem JAXFront-Beispiel, das bzgl. dieser Zuordnung eine Ausnahme darstellt, wird insbesondere in Kapitel eine auf Templates und in Kapitel eine auf Modelltransformation basierende MDE-Technik erläutert. 2.4 Weitere Arbeiten Derzeit befindet sich eine weitere Arbeit in der Entstehung, deren Fokus speziell auf das Aufgaben-Framework gerichtet ist und die auf den Ergebnissen der vorliegenden aufbaut. Während sich das Aufgaben-Framework seit über zwei Jahren in Prüfungen unter Examensbedingungen bewährt hat, sind für erweiterte Einsatzszenarien umfangreichere Aufgabentypen und differenziertere Lebenszyklen notwendig. Dazu gehören z.b. Aufgaben aus der theoretischen oder praktischen Informatik, deren Auswertung weitaus aufwendiger ist. Bezüglich ersteren wird eine Anbindung an das System Autotool [Wa02] und bzgl. zweiteren die Verwendung von Unit-Test-Frameworks (vgl. Kapitel 8.2.1) zur dynamischen Verifizierung von Programmieraufgaben angestrebt. Die Basis der Arbeit ist eine Weiterführung des Produktlinien-Ansatzes unter Evaluierung und (voraussichtlicher) Anwendung des OSGi-Frameworks [OS03], das ein dynamisches Modulsystem in Form einer serviceorientierten Architektur (SOA) bereitstellt. Die Bindung von Variationspunkten erfolgt durch das Deployment sog. Service-Bundles. Durch diesen Ansatz wird ein flexibleres Hinzufügen neuer Aufgabentypen verfolgt. 1 auch AOP wird oft den generativen Ansätzen zugeordnet 17
19 Softwareproduktlinien 3 Softwareproduktlinien Der erste Teil dieses Kapitels stellt zunächst den Softwareproduktlinien-Ansatz vor. Neben grundlegenden Prinzipien und Voraussetzungen werden auch wirtschaftliche Aspekte beschrieben, die wesentlich zum Erfolg von Produktlinien beigetragen haben. Für die Anwendung der Produktlinienentwicklung existiert eine Vielzahl von Methodiken bzw. Frameworks, von denen die wichtigsten im zweiten Teil dargestellt sind. Dabei werden jeweils verschiedene Eckpunkte beschrieben und ihre Eignung für das elateportal- Projekt erläutert. 3.1 Grundlagen und Definition Damit Wiederverwendung von Software funktioniert muss sie durch Vorgehensmodelle geplant und organisiert werden, da sonst die Gefahr besteht, dass mehr Kosten als für eine Neuentwicklung verursacht werden [PBL05, Kapitel 2]. Auf diesem Grundsatz basierend ist die Softwareproduktlinien-Entwicklung ein Ansatz im Software-Engineering, der die schnellere und effizientere Erstellung von qualitativ hochwertiger Software verfolgt. Durch die zielgerichtete Verwendung von Produktlinien- Artefakten werden Gruppen von Softwaresystemen für eine bestimmte Domain entwickelt, die alle eine gemeinsame Menge von Merkmalen aufweisen: A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy 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. [CN01] Die Produktlinienentwicklung stellt unter den oben genannten Bedingungen einen Meilenstein im Software-Engineering gegenüber den traditionellen Entwicklungsprozessen, wie z.b. Wasserfall-, Spiral- oder V-Modell [BF99] dar, die nicht auf die speziellen Anforderungen von Produktlinien ausgerichtet sind. Es wird nicht mehr der Fokus auf die reaktive Entwicklung kompletter Systeme auf Kundenwunsch gesetzt, sondern die proaktive Schaffung einer Basisplattform favorisiert. Diese besteht aus einer Menge von Produktlinien-Artefakten, die im sog. Domain Engineering-Prozess entwickelt werden. Zentral ist dabei die Modellierung von Variabilität in den Artefakten, um später im Rahmen des Application Engineering eine Vielzahl konkreter Applikationen ableiten zu können Prinzipien Von wesentlicher Bedeutung für die Softwareproduktlinienentwicklung sind die folgenden zwei Grundlagen [Bo04b]: Modellierung von Variabilität in Produktlinien Trennung von Domain und Application Engineering [WL99] In Abbildung 11 ist ein Produktlinien-Referenzprozess aus dem europäischen Forschungsprojekt PRAISE [Es97] dargestellt, der die beiden genannten Grundsätze veranschaulicht. Alle Produktlinien-Methodiken basieren im Wesentlichen auf dieser Struktur, unterschei- 18
20 Softwareproduktlinien den sich aber häufig hinsichtlich der Herangehensweise an bestimmte Teilgebiete sowie der unterschiedlichen Gewichtung einzelner Prozesse. Domain engineering Legacy code Domain expertise Domain analysis Domain terminology Feedback / adaptations / reverse architecting Domain Domain design implementation Reference architecture Reusable components Reference requirements... Requirements Traceability Traceability Components Family asset repository Application engineering New requirements Application requirements Application design Application coding Abbildung 11 PRAISE-Referenzprozess [Es97] Für die erfolgreiche Entwicklung und Etablierung einer Softwareproduktlinie genügen nicht nur technische Beschreibungen von Vorgehensmodellen. Produktlinienentwicklung betrifft in gleichem Maße auch die organisatorischen Maßnahmen, die in Unternehmen durchgeführt werden müssen. Sie benötigen unternehmerische Voraussicht, Investitionen, Planung und Führung, d.h. strategisches Denken, das über den Horizont einer einzelnen Applikation hinausgeht (vgl. BAPO-Modell, Kapitel 1.3) Voraussetzungen Der Erfolg des Produktlinienansatzes geht neben den genannten Entwicklungsparadigmen einher mit neuen Lösungen und Technologien im Bereich der Software-Architekturen, Laufzeit-Umgebungen und Kommunikationsinfrastrukturen. In der Praxis bedeutet das derzeit eine Fokussierung auf die Verwendung von Komponententechnologien in Verbindung mit objektorientierten Programmiersprachen. Wie bereits in der Einleitung erwähnt, kamen mittlerweile weitere Ansätze bzw. Technologien dazu, wie bspw. AOP, GSE/MDE oder SOA. Abbildung 12 zeigt das im Laufe der Zeit gesteigerte Wiederverwendungspotential verschiedener Entwicklungsparadigmen, die von strukturierter und objektorientierter Programmierung über komponentenbasierte Entwicklung bis zu den genannten modellbasierten Ansätzen reichen. Außerdem ist im Diagramm die agentenbasierte Entwicklung dargestellt, dessen Konzept auf die Anwendung künstlicher Intelligenz und einer SOA ausgerichtet ist, indem sog. Agenten autonom miteinander interagieren (Multi- Agentensysteme) [LAI04]. 19
21 Softwareproduktlinien Reuse level Single systems multiple system families Domainpervasive reuse Architected reuse Managed reuse Planned reuse Informal code reuse No reuse Structured programming Object-oriented development Component-based development Model-Driven Development Agent-based development?? Abbildung 12 Development paradigms Steigerung Software-Wiederverwendbarkeit (erweiterte Version von [Li02]) Die Begriffe der Komponente und des Komponenten-Frameworks werden für die weiteren Ausführungen in der Arbeit eine wichtige Rolle spielen. Weil insbesondere ersterer bereits sehr überladen und in der Literatur nicht eindeutig definiert ist, sei an dieser Stelle auf eine der bekanntesten Definitionen von Szyperski [Sz02] verwiesen. Da es auch Komponenten- Frameworks im J2EE-Bereich gibt, die nicht vollständig konform zu dieser Definition sind, ist der Komponentenbegriff immer im Kontext zu sehen. Insbesondere wird in [CE00, Kapitel 1] auf die allgemeine Problematik bei der Definition von Komponenten hingewiesen. 3.2 Begriffsbestimmung Für Softwareproduktlinien existieren verschiedene Bezeichnungen, die teilweise synonym verwendet werden. So gibt es für den in der amerikanischen Forschung geprägten Begriff Product Line im europäischen Raum die Bezeichnung Product Family, genauso wie ihre Bestandteile entweder Core Assets oder Artefacts genannt werden. Das lässt sich darauf zurückführen, dass sich ursprünglich amerikanische und europäische Forschungsgemeinschaften getrennt mit der Software-Produktlinienentwicklung beschäftigt haben. Als es 1996 in Las Navas, Spanien zu einem ersten Arbeitskontakt kam, waren beide Terminologien bereits etabliert [Li02]. Außerdem gibt es in Europa noch eine weitere Bedeutung für Software-Produktlinien: so bezeichnen einige Unternehmen mit Product Line eine Menge ähnlicher Produkte, die aber auf unterschiedlichen Technologien basieren. Viele Geräte in der Unterhaltungsindustrie sehen für Endanwender ähnlich aus (VCRs, CD-Player, DVD-Player usw.), obwohl sie sich intern stark unterscheiden können. Um keine Verwechslungen zu provozieren wurde deshalb in vielen europäischen Forschungsprojekten explizit Product Family (oder auch System Family) verwendet. Außerdem gilt es hier zu beachten, dass Product Lines in Product Families enthalten sein können und umgekehrt. Bezüglich dieser Terminologie ist also der Begriff Product Line markt- und kundenorientiert, wohingegen eine Product Family ein technologie- bzw. implementierungsabhängiges Konzept ist. Für weitere Informationen sei an dieser Stelle auf [CE00, Kapitel 2] verwiesen, das beide Begriffe im europäischen Sinn definiert. Clements und Northrop [CN01, Kapitel 1] setzen darüber hinaus beide Terminologien in Relation zueinander. 20
22 Softwareproduktlinien Mit Product Population führte Van Ommering [Om00] eine weitere Bezeichnung für spezielle Produktlinien ein, die zwar auf unterschiedlichen Technologien basieren, aber auch viele gemeinsame Komponenten besitzen. Bezogen auf das Unterhaltungsindustrie- Beispiel haben neue Geräte häufig Funktionen, die man früher nur in separaten Geräten fand, etwa Dolby-Digital-Soundsysteme oder DVD-Player in Fernsehern. Inzwischen wird allerdings auch in der europäischen Literatur häufiger der Begriff Produktlinie bzw. Product Line verwendet (vgl. [PBL05]), sodass er auch in der vorliegenden Arbeit benutzt wird. Im Sinne der Definition von Kapitel 3.1 bezeichnet eine Produktlinie in der vorliegenden Arbeit immer eine Menge von Produkten bzw. Artefakten, die auf derselben technischen Basis realisiert worden sind. 3.3 Klassisches Domain Engineering Klassische Domain Engineering-Methoden basieren auf der Idee einer Domain, welche den Fachbereich einer Software bestimmt und den Umfang der Wiederverwendung impliziert. Czarnecki und Eisenecker [CE00, Kapitel 2] definieren Domain Engineering folgendermaßen: Domain Engineering is the activity of collecting, organizing and storing past experiences in building systems or parts of systems in a particular domain in the form of reuseable assets (i.e., reusable work products), as well as providing an adequate means for reusing these assets (i.e., retrieval, qualification, dissemination, adaption, assembly, and so on) when building new systems. In ihrem Buch ist auch eine umfangreiche Übersicht zu Domain Engineering-Methoden zu finden, die in Form eines Stammbaums dargestellt sind. Da ohne zusätzliche Abgrenzung immer eine annähernd vollständige Betrachtung der Domain durchgeführt wird, umfassen klassische Domain Engineering-Methoden meist alle möglichen Applikationen, die aus der Domain entwickelt werden können. Es hat sich nach Bayer et al. [Ba99] herausgestellt, dass der Ansatz viel zu weit gefasst und deswegen problematisch bei der Entwicklung großer Systeme ist. Oftmals müssen zu viele Bereiche betrachtet werden, die ohne Belang für die zu entwickelnden Applikationen sind. Stattdessen fokussieren Unternehmen ganz zielgerichtet bestimmte Produkte, die in der Regel nur einen kleinen Teil der Domain betreffen. Zur Lösung dieses Problems wird im Produktlinien-Ansatz der sog. Scoping-Prozess eingeführt, welcher die Tätigkeiten im Domain Engineering auf die wirklich benötigten Bereiche beschränkt. Zusammen mit weiteren wichtigen Aktivitäten verfolgt der Produktlinien-Ansatz eine gesamtheitliche, produktzentrierte Betrachtung von sowohl Domain als auch Application Engineering und geht damit über klassische Domain Engineering-Methoden hinaus. 3.4 Vorteile Die Entscheidung für oder gegen die Einführung von Produktlinienentwicklung in Unternehmen hat in der Regel wirtschaftliche Gründe und kann wesentlich den Erfolg in einem Marksegment bestimmen. Zu den häufigsten Gründen für die Einführung einer Produktlinie gehören die Steigerung der Produktivität, Verkürzung der Time-To-Market, 21
23 Softwareproduktlinien Verbesserung der Produkt-Qualität oder sogar die Kompensation von Fachkräftemangel [CN01, Kapitel 2]. Mit der Etablierung einer Produktlinien-Plattform lassen sich im Rahmen des Application Engineerings Einsparungen durch Wiederverwendung von Plattform-Artefakten erreichen. Dazu zählen nicht nur Quelltexte, sondern auch Requirements, Architekturen, Komponenten sowie Modelle und Analysen. Auch Test-Pläne, unternehmensspezifische Prozesse und Analysen können wiederverwendet werden. Darüber hinaus lassen sich Entwickler flexibler im Projekt einsetzen. Ein höherer Reifegrad der Plattform führt außerdem zu weniger Softwarefehlern. Erkannte Fehler werden einmal entdeckt und beseitigt in keiner Applikation der Produktlinie wieder vorkommen. Dem steht allerdings auch die Gefahr der Fehlerfortpflanzung aus der Plattform in alle Produkte gegenüber, was besonders in sicherheitskritischen Bereichen von Relevanz ist. Neben organisatorischen Benefits ergeben sich auch persönliche Vorteile für viele Beteiligte, auf die hier nicht näher eingegangen wird. Clements und Northrop [CN01, Kapitel 2] erläutern praxisorientiert den Nutzen für Manager, Entwickler, Kunden und Endbenutzer. 3.5 Kosten und Risiken Die Entscheidung zur Einführung einer Produktlinie sollte nicht wahllos getroffen werden, sondern muss mit konkreten Geschäftszielen verknüpft werden. Neben den oben genannten Vorteilen ist die Einführung auch mit Kosten verbunden, welche in die Entscheidungsfindung mit einfließen müssen. Dies sind einerseits Start-Investitionen für die Etablierung der Produktlinie und andererseits Wartungs- und Pflegekosten, um den Pool von Artefakten instand zu halten. Erstere spielen aber mit jeder neuen Applikation aus der Produktlinie eine mehr und mehr untergeordnete Rolle und amortisieren sich in der Regel nach wenigen Releases. Nach den Erfahrungen von McGregor [Gr02] kann der Break Even bereits nach drei Applikation erreicht sein. Neuere Erfahrungsberichte sprechen mitunter auch von nur zwei entwickelten Produkten [Za07]. In [Co02] werden allerdings auch Risiken genannt, die sich insbesondere auf Widerstände in der Organisation, dem Management und von Entwicklern beziehen. In Tabelle 1 sind die Ergebnisse einer Befragung zu den häufigsten Risiken von Produktlinien dargestellt. Probleme Genannt von Widerstände in der Organisation 52% Widerstände im Management 36% Widerstände von Entwicklern 32% Bedenken bzgl. Zusatzinvestitionen 45% Fehlen entsprechend geschulten Personals 29% Unfähigkeit Auswirkungen einschätzen zu können 19% Bedenken bzgl. der langen Vorlaufzeit 18% Tabelle 1 Einschätzung der Risiken von Produktlinien [Co02] 22
24 Softwareproduktlinien So passen Produktlinien-Ansätze nicht immer zum Marktsegment eines Unternehmens. Wenn sich Märkte zu schnell zu stark ändern, sich vorhandene Produkte zu sehr unterscheiden oder die Zukunft des Marktsegments ungewiss ist, bieten sich nicht genügend Möglichkeiten, einen Return-On-Invest (ROI) zu erreichen. In diesen Fällen sollte von einer Produktlinie abgesehen werden. Interessant ist an dieser Stelle jedoch, dass die in Tabelle 1 dargestellten Risiken nur sehr begrenzt auf Open-Source-Projekte zutreffen Einführungs-Strategien Bei der Einführung von Produktlinienentwicklung wird zwischen leichtgewichtigen und schwergewichtigen Strategien unterschieden, die jeweils den Break Even beeinflussen [Gr02]. Mit schwergewichtigen wird die Produktion in einem Schritt umgestellt, wodurch wesentlich höhere Startkosten nötig sind. Hingegen verfolgen leichtgewichtige Strategien den Ansatz, Artefakte von bestehenden oder in Entwicklung befindlichen Produkten für die Einführung zu verwenden. Ihre Startkosten bewegen sich dann zwischen denen von Einzelsystemen und denen schwergewichtiger Strategien. Abbildung 13 verdeutlicht diesen Sachverhalt. 600, ,000 Single product Heavyweight Lightweight 400, , , ,000 o Number of products Abbildung 13 Kostenvergleich Einführungsstrategien [Gr02] Cumulative costs of products (US dollars) Zur genaueren Berechnung der Einführungskosten von Produktlinien existieren Kostenmodelle auf unterschiedlichen Abstraktionsstufen. An dieser Stelle sei vor allem auf das detaillierte Modell COCOMO II von [Bo00] sowie einen allgemeineren Ansatz in [Bo04a] verwiesen Change Requests Ein weiteres Risiko in der Produktlinienentwicklung stellen nachträgliche Änderungen in Form von Change Requests dar. So muss immer explizit entschieden werden, ob diese nur in der Applikation umgesetzt werden oder auch in die Plattform einfließen sollen. Die erste Strategie führt zwar schneller zur gewünschten Änderung, schöpft aber das Wiederverwendungspotential nicht voll aus und kann die Konsistenz der gesamten Produktlinie in Gefahr bringen. Bei der zweiten Strategie kann es wiederum passieren, dass Kunden durch die Anpassung der Plattform unverhältnismäßig lange auf kleine Änderungen warten müssen [Bo04b, Kapitel 1]. 23
25 Softwareproduktlinien Mit den Auswirkungen von Change Requests auf die Produktlinienentwicklung befasst sich auch Carbon et al. [Ca06]. Sie vergleichen diese mit Change Requests bei agilen Methodiken anhand eines dafür erarbeiteten ROI-Frameworks. Es soll zu weitergehenden Betrachtungen und einem besseren Verständnis bezüglich einer Kombination von agilen und Produktlinien-Methodiken führen (vgl. agile Prinzipien in Kapitel 4.4). Da die Ergebnisse in dem Paper noch nicht vollständig analysiert worden sind, können an dieser Stelle keine Rückschlüsse gezogen werden. 3.6 Methodiken und Frameworks Basierend auf dem Erfolg des Produktlinien-Ansatzes sind verschiedene Methodiken bzw. Frameworks entwickelt worden, welche die Umsetzung in der Praxis ermöglichen sollen. Im Folgenden werden die wichtigsten Entwicklungsmethoden charakterisiert und ihre Eignung für die vorliegende Arbeit erläutert. Die Auswahl orientiert sich an [TH03] FAST Die von Weiss [We95] eingeführte Methodik Family-oriented abstraction, specification and translation (FAST) war die erste, die den klassischen Produktlinienprozess mit expliziter Trennung von Domain und Application Engineering einführte, wie in Abbildung 14 dargestellt. So konzentrierte sich FAST bzgl. des erstgenannten Prozesses auf eine systematische Vorgehensweise zur Analyse möglicher Produktlinien und bzgl. des zweitgenannten auf Techniken zur effizienten Ableitung konkreter Applikationen aus den Produktlinien-Artefakten. Außerdem existieren zwischen den beiden Prozessen Feedback- Schleifen [WL99]. Feedback (Customer needs) Domain Engineering Define the family and develop production facilities Feedback (Production needs) Production Facilities: Application Engineering Environment Application Engineering: Produce Applications Key: Applications Product Process Abbildung 14 Der FAST-Prozess [We95] FAST identifiziert insbesondere die Notwendigkeit einer ausführlichen Analyse der Anforderungen an die Produktlinie (Domain-Analyse) sowie des Findens angemessener 24
26 Softwareproduktlinien Abstraktionen. Wichtig ist, dass die Abstraktionen während des gesamten Lebenszyklusses der Produktlinie stabil bleiben müssen. FAST war für das elateportal-projekt aufgrund der folgenden Eigenschaften nicht geeignet: Die Domain-Analyse und Requirements-Spezifikation ist zu komplex, da die Anforderungen sehr präzise definiert werden müssen, um daraus Code erzeugen zu können [TH03]. Die Traceability von Requirements ist nicht betrachtet worden, was später zu Problemen durch Inkonsistenzen führen kann [TH03]. FAST beschreibt nur einen Prozess und würde im elateportal-projekt ein zu aufwendiges Tailoring implizieren Fraunhofer PuLSE Die Product Line Software Engineering-Methodik (PuLSE) [Ba99] ist eine Entwicklung des Fraunhofer-Instituts für Experimentelles Software-Engineering 1 (IESE) und basiert auf Erfahrungen, die aus der Auftragsforschung mit Industrie-Partnern stammen. Das Institut bietet mit PuLSE kommerzielle Beratungsleistungen an, um Kunden in der Produktlinienentwicklung zu unterstützen. Deployment Phases Technical Components PuLSE Initialization Product Line Infrastructure Construction Product Line Infrastructure Usage Product Line Infrastructure Evolution Customizing Scoping Modeling Architecting Designing Coding Testing and Inspection Evolving and Managing Instantiating Project Entry Points Organizational Issues Maturity Scale Support Components Abbildung 15 PuLSE-Übersicht [Ba99] Das Design der Methodik beruht auf der Erkenntnis, dass bestehende Domain Engineering- Methoden zu sehr auf organisatorische Prozesse fokussiert waren, wohingegen PuLSE einen produkt-zentrierten Ansatz verfolgt. In Abbildung 15 sind die Hauptkomponenten von PuLSE dargestellt
27 Softwareproduktlinien Die Grundlagen der Methodik lassen sich folgendermaßen charakterisieren [TH03]: Mit PuLSE wird ein vollständiges Framework angeboten, das den gesamten Entwicklungsprozess unterstützt, der in drei Phasen unterteilt wird (Deployment Phases). PuLSE ist modular und anpassbar. Es besteht aus sechs technischen (Technical Components) und drei unterstützenden Komponenten (Support Components), die spezielle Bedürfnisse der zu etablierenden Produktlinie abdecken. Sie werden ausgewählt, instanziiert und in den Entwicklungsphasen angewendet. PuLSE kann inkrementell eingeführt und an bestehende Prozesse bzw. Systeme adaptiert werden, um speziellen Anforderungen zu entsprechen. PuLSE führt bereits etablierte Notationen fort und erweitert sie entsprechend, anstatt neue einzuführen. Allerdings konzentriert sich auch PuLSE auf den Entwicklungsprozess auf einem abstrakten Niveau und muss an die konkrete Umgebung durch ein Tailoring angepasst werden. Eine Adaption stellt z.b. das nachfolgend erläuterte KobrA dar. Obwohl PuLSE sich nach [Ba99] auch für kleine und mittelgroße Projekte eignet, war es durch den kommerziellen Charakter und das Fehlen umfassender freier Dokumentation nicht für das elateportal-projekt geeignet Fraunhofer KobrA Die Komponentenbasierte Anwendungsentwicklungs-Methode [ABM00] des IESE ist eine auf die Unified Modeling Language (UML) [OMG04] und komponentenbasierte Entwicklung maßgeschneiderte Version von PuLSE. Ziel ist eine Verbindung der Wiederverwendung im Großen mit der Wiederverwendung im Kleinen. Die Autoren erklären: the product-line and component-based approaches to software development seem to have complementary strengths. They both represent powerful techniques to support reuse, but essentially at the opposite ends of the granularity spectrum [ABM00]. KobrA bietet sehr spezifische Lösungen für die Umsetzung der Produktlinienentwicklung und deckt aufgrund seiner Herkunft nahezu alle wichtigen Aspekte des Ansatzes ab. Interessant ist weiterhin, dass das Design der Methodik sich nicht nur auf Produktlinien, sondern auch auf Einzelsysteme anwenden lassen soll [Ma04]. Außerdem unterstützt es einen modellgetriebenen Ansatz für die abstrakte Beschreibung der Architektur. KobrA ist produktlinien-typisch wieder in zwei Prozesse unterteilt, die als Framework Engineering und Application Engineering bezeichnet werden. In ersterem wird die Plattform entwickelt, welche nach KobrA eine Art Framework darstellen, das aus einer Menge sog. KobrA-Komponenten besteht, die in einer baumartigen Hierarchie angeordnet sind. Zusammengefasst stellt KobrA eine einfache Methodik dar, die nicht zu viel Entwicklungs-Overhead erzeugt und mit angemessenem Aufwand von Entwicklern anwendbar ist [Ma04]. Außerdem ist KobrA in Buchform dokumentiert [ABB01]. Nachteilig wirkt sich die Verwendung von UML in der Version 1.0 auf die Möglichkeiten 26
28 Softwareproduktlinien der Architekturbeschreibung aus [Ba04]. Inzwischen stehen mit UML 2.0 umfangreichere Modellierungsmöglichkeiten zur Verfügung FeatuRSEB Featured Reuse-Driven Software Engineering Business (FeatuRSEB) ist eine Erweiterung der Produktlinien-Methodik RSEB [JGJ97] mit Konzepten aus FODA [Ka90], einer klassischen Domain Engineering-Methode. Der Ansatz von RSEB basiert auf der Erstellung von Anwendungsfällen (Use Cases), welche die Anforderungen an die Produktlinie beschreiben. Darauf folgt eine Ausarbeitung der Architektur, aus der am Ende Objektmodellen abgeleitet werden, die mit den ursprünglichen Use Case-Diagrammen durch Traceability-Links verbunden sind. Zur Definition von Variationspunkten in den Modellen erweitert RSEB UML-Diagramme mit neuen Notationen. Im Einzelnen sind in RSEB die folgenden Prozesse definiert: Requirements Engineering Architecture Family Engineering Component System Engineering Application System Engineering Durch die Kombination mit FODA kommen in FeatuRSEB die beiden Schritte Domain Engineering und Feature Modelling hinzu. Insbesondere mit letzteren wurde RSEB um ein formales Feature-Modell zur Definition von Gemeinsamkeit und Variabilität der Plattform erweitert. In FeatuRSEB sind dementsprechend sowohl Use Case- als auch Feature-Modelle von zentraler Bedeutung. In Kapitel 4.3 wird jedoch eine kritische Betrachtung von Feature- Modellen zur Beschreibung der Variabilität von Produktlinien erfolgen. Beide Diagrammtypen werden nebeneinander erstellt und zwischen ihnen Traceability-Links spezifiziert. Die Notation von Variationspunkten erfolgt durch eigene Erweiterungen von UML- Diagrammen SEI Produktlinien-Framework Das Produktlinien-Framework des Software Engineering Institutes (SEI) der Carnegie Mellon University ist in [CN01] veröffentlicht und seitdem ständig weiterentwickelt worden. Die Dokumentation des Frameworks ist sowohl in Buchform als auch über die Webseiten der Produktlinien-Initiative 1 des SEI verfügbar. Das in Abbildung 16 dargestellte Logo der Initiative stellt die drei Hauptaktivitäten Core Asset Development, Product Development und Management in Relation. Die ersten beiden entsprechen den aus anderen Methodiken bekannten Prozessen Domain und Application Engineering. Der dritte stellt die technischen und organisatorischen Management- Tätigkeiten zur Initiierung und Erhaltung der Produktlinie dar
29 Softwareproduktlinien Charakteristisch ist die feste Verzahnung der drei Aktivitäten miteinander sowie der im Gegensatz zu anderen Frameworks stärker hervorgehobene Management-Prozess. Core Asset und Product Development stellen iterative Vorgehen dar, die nebenläufig durchgeführt werden können, da entweder Core-Assets aus bestehenden Produkten abgeleitet oder Produkte aus Core-Assets entwickelt werden. Die beiden Aktivitäten stehen dabei immer unter der Kontrolle des Management-Prozesses. Von zentraler Bedeutung sind auch wieder Feedback-Schleifen zwischen den Prozessen: Core Assets können mit den Erfahrungen jedes neuen Produktes verbessert werden und umgekehrt profitiert jedes neue Produkt von bewährten Core-Assets. Damit das Feedback seine Wirkung zielgerichtet entfalten kann, werden Traceability-Links zur Verbindung von Core Assets in beiden Entwicklungsprozessen definiert. Core Asset Development Product Development Management Abbildung 16 Hauptaktivitäten im Framework des SEI [CN01] Zur Umsetzung der drei Hauptprozesse enthält das Framework 29 sogenannte Practice Areas, die Richtlinien und Vorgehensweisen zu einzelnen Tätigkeiten in der Produktlinienentwicklung beschreiben und von Einzelsystemen adaptiert wurden. Sie sind in folgende Bereiche unterteilt: Software Engineering Practice Areas bezeichnen Tätigkeiten, die sich mit der Entwicklung und Wartung von Core-Assets sowie von Produkten beschäftigen. Dazu zählen z.b. Architekturentwicklung, Requirements Engineering, Komponenten-Entwicklung und Testen. Technical Management Practice Areas sind organisatorische Aktivitäten, wie bspw. Risikomanagement, Projektplanung, Scoping oder Konfigurationsmanagement. Organizational Management Practice Areas bezeichnen betriebswirtschaftliche Aufgaben, zu denen bspw. Marktanalyse, Organisationsplanung, Geschäftsmodellentwicklung oder Training gehören. Sie werden u.a. zur Einführung und Evolution der Produktlinienentwicklung im Unternehmen benötigt. Das SEI-Framework beschreibt Tätigkeiten auf einem abstrakten Niveau und kann an unterschiedliche Prozesse angepasst werden. Es ist nicht sofort einsetzbar, sondern es muss zunächst ein Tailoring auf die Projekt-Umgebung stattfinden. Das Framework stellt jedoch ein Standardwerk mit vielen Lösungen zu einzelnen Problemen dar, die auch unabhängig von der Entwicklungsmethodik anwendbar sind. 28
30 Softwareproduktlinien Framework nach Pohl, Böckle, Van der Linden Das Produktlinien-Framework nach [PBL05] basiert auf Ergebnissen der drei großen europäischen Forschungsprojekte ESAPS 1, CAFÉ 2 und FAMILIES 3. Es ist umfangreich in Lehrbuchform dokumentiert und deckt alle wichtigen Bereiche der Produktlinienentwicklung ab. Das Buch stellt das erste in einer Serie von drei Büchern dar, welche die Ergebnisse der Forschungsprojekte publizieren und systematisch aufbereiten. Es zählt damit zu den aktuellsten Werken auf dem Gebiet der Produktlinienentwicklung. An dieser Stelle sei auch auf das zweite Buch [KD06] aus der Serie verwiesen, das ein Sammelwerk von derzeit neuesten Forschungsbeiträgen ist. Das Framework enthält Lösungen zu allen Bereichen des BAPO-Modells (siehe Einleitung, Kapitel 1.3) auf einer abstrakten Ebene und muss durch ein Tailoring an die konkrete Projektumgebung angepasst werden. Ein wichtiges Merkmal des Frameworks gegenüber den anderen erläuterten Methodiken stellt ein Variabilitätsmodell dar, das orthogonal zu vorhanden Diagrammen definiert verwendet werden kann. Dazu ist keine Einführung neuer Notationen nötig. Außerdem unterstützt das Framework die Auswahl und Integration von COTS-Komponenten (commercial-off-the-shelf [PBL05, Kapitel 14]) in die Plattform. Der im Framework beschriebene Prozess ähnelt aufgrund der gleichen Herkunft dem PRAISE-Referenzprozess (vgl. Kapitel 3.1.1, Abbildung 11) mit der klassischen Trennung von Domain und Application Engineering. Zusätzlich fügt es einen Product Management- Teilprozess sowie Qualitätssicherungsmaßnahmen in Form des Domain und Application Testings ein. Die Autoren weisen darauf hin, dass für eine erfolgreiche Produktlinienentwicklung alle im Framework spezifizierten Teilprozesse zur Anwendung kommen müssen. Jedoch können sie in existierende, organisationsspezifische Prozesse eingebettet werden, wie bspw. in den FAST-Prozess [PBL05, Kapitel 2]. Für die Fallstudie wurde dieses Framework aufgrund seiner Flexibilität, der guten Dokumentation in Lehrbuchform sowie der Tatsache, dass es als derzeit modernste Produktlinien-Methodik bezeichnet werden kann, ausgewählt. Im nächsten Kapitel erfolgt eine umfassendere Einführung
31 Produktlinien-Framework 4 Produktlinien-Framework In den vorhergehenden Kapiteln wurden die Grundlagen der Produktlinienentwicklung erläutert und sechs konkrete Methodiken bzw. Frameworks vorgestellt, aus denen das Framework nach [PBL05] als Basis für das elateportal-projekt ausgewählt worden ist. Da es keinen expliziten Namen besitzt, wird es in den weiteren Erläuterungen mit der Bezeichnung SPL-Framework referenziert. Wie in der Einleitung erwähnt, liegt das Hauptaugenmerk der Fallstudie auf der Architektur sowie dem Entwicklungsprozess. Obwohl Geschäfts- und Organisationsbetrachtungen in kommerziellen Anwendungen eine sehr wichtige Rolle spielen, haben sie im Open-Source-Bereich oft eine eher untergeordnete Bedeutung was auch auf das elateportal-projekt zutrifft. 4.1 Referenzprozess Abbildung 17 zeigt eine Übersicht des Frameworks mit einer Darstellung der beiden Hauptprozesse Domain und Application Engineering sowie ihren entsprechenden Teilprozessen. Domain Engineering Product Management Domain Requirements Engineering Domain Design Domain Realisation Domain Artefacts incl. Variability Model Domain Testing Requirements Architecture Components Tests Application Engineering Application Requirements Engineering Application Design Application Realisation Application N Artefacts incl. Variability Model Application 1 Artefacts incl. Variability Model Application Testing Requirements Architecture Components Tests Abbildung 17 SPL-Framework [PBL05] Domain Engineering Im Domain Engineering wird die Produktlinien-Plattform mit ihren wiederverwendbaren Artefakten entwickelt. Dazu müssen zunächst die Gemeinsamkeit und Variabilität der Produktlinie ermittelt und die späteren Applikationen spezifiziert werden, bevor die Definition und Realisierung der Artefakte erfolgen kann. Das Domain Engineering besteht aus fünf Teilprozessen, von denen die in der Fallstudie betrachteten in Abbildung 17 gelb hinterlegt sind. 30
32 Produktlinien-Framework Der Hauptunterschied zur Einzelsystementwicklung besteht in dem Vorhandensein von Variabilität, die im Variabilitätsmodell definiert ist. Jeder Teilprozess muss dieses Modell verfeinern und in der Regel auch zusätzliche Variabilität einführen. Außerdem erfolgt neben dem Erstellen von Artefakten für den nachfolgenden Prozess auch Feedback zurück zum vorhergehenden (Feedback-Schleifen). Die Fallstudie konzentriert sich auf Domain Requirements Engineering, Domain Design sowie Domain Realisation, welche die eigentlichen Entwicklungs-Prozesse darstellen. Im Domain Requirements Engineering erfolgt die Erfassung von variablen und gemeinsamen Anforderungen an die Produktlinie. Diese sind Vorausetzung für das Domain Design, das eine Referenzarchitektur (grobes Design) definiert, die schließlich im Domain Realisation verfeinert und implementiert wird. Eine Betrachtung des Domain Testings als zentraler Qualitätssicherungsprozess im SPL- Framework erfolgt in Kapitel 8, das eine allgemeine Sichtweise auf die Verifikation und Validierung der Plattform enthält. Es beschränkt sich nicht nur auf Testen, sondern erläutert auch Ansätze zur statischen Analyse des Quellcodes Application Engineering Im Application Engineering erfolgt die Erstellung konkreter Applikationen aus der Plattform mit dem Ziel, einen hohen Wiederverwendungsgrad zu erreichen. Wie in Abbildung 17 dargestellt, besteht es aus vier Teilprozessen, die jeweils in Relation zu ihrem Äquivalent im Domain Engineering stehen. Die Application Engineering- Teilprozesse nutzen einerseits die Plattformartefakte und bieten andererseits Feedback bzgl. ihrer Anwendbarkeit. Dazu gehören auch Anfragen nach neuer Funktionalität, die noch nicht Bestandteil der Plattform ist. Da die Plattform oft nicht alle für eine bestimmte Applikation nötigen Artefakte bereitstellen kann, besteht eine wichtige Aufgabe in der Ermittlung der sog. Deltas. Sie beschreiben, welche Artefakte im Application Engineering zusätzlich zu den bereits vorhandenen entwickelt werden müssen und ermöglichen damit eine Bestimmung des Aufwands bzw. der Zusatzkosten. Außerdem erfolgt im Application Engineering die Bindung der Variabilität durch Auswahl konkreter Varianten für Variationspunkte. Obwohl, wie bereits in der Einleitung erläutert, das Application Engineering keinen direkten Betrachtungsgegenstad der Fallstudie darstellt, sind vereinzelt Erfahrungen aus der Praxis enthalten, die zur Charakterisierung der Vorgehensweise sinnvoll sind. 4.2 Product Management Der Teilprozess des Product Management befasst sich mit den ökonomischen Aspekten von Produktlinien und hat damit wesentlichen Einfluss auf die wirtschaftliche Zukunft eines Unternehmens. Alle Teilprozesse des Domain und Application Engineerings sind von den Ergebnissen des Product Managements betroffen. Ergebnis des Product Managements ist eine Roadmap mit zukünftigen Produkten, ihren Features und einem Zeitplan. Features bezeichnen dabei die nach außen bzw. für Benutzer sichtbaren Funktionen der Produkte. Um auf neue Entwicklungen des Marktes reagieren zu können, sollte die Roadmap auch mögliche weitere, erst in Zukunft relevante Einsatzszena- 31
33 Produktlinien-Framework rien berücksichtigen. Wie bereits in Kapitel 3 erwähnt, fließen häufig auch bereits existierende Systeme in die Betrachtung mit ein. Dementsprechend nimmt das Product Management für Produktlinien einen wesentlich höheren Stellenwert als bei der Einzelsystementwicklung ein. Das SPL-Framework betrachtet ausführlich die mit Product Management zusammenhängenden Tätigkeiten, die von traditionellen Aktivitäten, wie Produktstrategieentwicklung und Produkteinführung, über das Portfolio-Management bis hin zum essentiellen Scoping (vgl. Kapitel 3.3) reichen. Ob diese ökonomischen Betrachtungen auch im Open-Source- Bereich nötig sind, hängt von den Sponsoren und Entwicklern ab, die evtl. ein bestimmtes Geschäftsmodell mit Open-Source-Software verknüpfen. Für ausführlichere Betrachtungen sei an dieser Stelle auf [Be99] verwiesen. Im Rahmen der Fallstudie beschränkte sich das Product Management auf konzeptionelle Betrachtungen zu möglichen späteren Einsatzfeldern sowie auf Abgrenzungskriterien zu bereits in der Hochschullandschaft existierenden Systemen, mit denen eine Integration angestrebt wurde. 4.3 Variabilitäts-Modell Die Modellierung von Variabilität ist eine grundlegende Tätigkeit der Produktlinienentwicklung, die alle Teilprozesse des Domain Engineerings betrifft. Einen wichtigen Vorteil des SPL-Frameworks stellt die Verwendung eines Variabilitätsmodells dar, das orthogonal zu bestehenden Diagrammen definiert wird. In den meisten Produktlinien-Frameworks wurde die Modellierung von Variabilität durch Erweiterung bestehender Metamodelle und durch Einführung neuer Notationen realisiert. So existieren insbesondere für UML verschiedene Erweiterungen, um sie mit Variabilität versehen zu können [JM02, ML02]. Diese Ansätze haben allerdings folgende Nachteile [BLP04]: Die Modelle werden durch die Erweiterungen komplexer und unübersichtlicher. Variationspunkte und Varianten können nicht modellübergreifend definiert und damit Änderungen schlecht bzgl. der Darstellung in anderen Diagrammen nachverfolgt werden. Die Variabilität kann nicht konsistent über mehrere Teilprozesse hinweg modelliert werden. Darüber hinaus werden oft Feature-Modelle (vgl. FODA in Kapitel 3.6.4) zur Anforderungsmodellierung verwendet, da diese selbst bereits Variabilität enthalten [KLD02, FFB02]. Allerdings haben speziell Feature-Modelle das Problem, dass deren Ausdruckskraft bestimmten Aspekten von Produktlinien nicht gerecht wird. Zum Beispiel muss oft Variabilität modelliert werden, die zur Implementierung bestimmter Funktionalität nötig, aber nicht für die Produktlinie relevant ist. Zum einen ist diese Unterscheidung in Feature- Modellen nicht möglich und zum anderen beschreiben sie nur eine statische Sicht der Produktlinie. Allerdings existieren wiederum verschiedene Erweiterungen für Feature- Modelle, auf die an dieser Stelle nicht näher eingegangen wird. Um den genannten Problemen zu begegnen enthält das SPL-Framework als integralen Bestandteil ein orthogonales Variabilitätsmodell. Eine erste Version des Modells ist bereits 32
34 Produktlinien-Framework von Bachmann et al. in [Ba03] vorgestellt worden. Von zentraler Bedeutung ist, dass damit die Modellierung von Variabilität über Artefakte und Prozessgrenzen hinweg ermöglicht wird und keine Eingriffe in bestehende Modelle notwendig sind Metamodell Das orthogonale Variabilitätsmodell besteht aus zwei Bestandteilen: einem Metamodell und einer darauf basierenden graphischen Notation. Das Metamodell definiert die beiden zentralen Elemente Variationspunkt (Variation Point) und Variante (Variant), die zueinander in Relation stehen. Abbildung 18 stellt den entsprechenden Ausschnitt des Metamodells dar, eine vollständige Version ist in Anhang A.1, Abbildung 51 zu finden. 1..* 1..* Variation Point Variant {complete, disjoint} Variability Dependency Internal Variation Point {complete, disjoint} External Variation Point Optional Mandatory Abbildung 18 Variationspunkt und Variante im Metamodell [PBL05] In der Abbildung ist zu erkennen, dass bei Variationspunkten zwischen externer und interner Variabilität unterschieden wird. Dabei bezeichnet erstere die nach außen, d.h. für Auftraggeber und Nutzer, sichtbare Variabilität. Zur Umsetzung impliziert sie oft die Einführung zusätzlicher, interner Variabilität, welche aus Gründen der Übersichtlichkeit und Komplexitätsreduktion nach außen versteckt werden soll. Darüber hinaus formalisiert das orthogonale Variabilitätsmodell weitergehende Beziehungen zwischen einzelnen Varianten sowie die Erstellung von Traceability-Links Traceability Traceability gewährleistet die Nachverfolgbarkeit zwischen Elementen des Variabilitätsmodells und ihrer Repräsentation in anderen Artefakten, wie z.b. Diagrammen, Implementierungen und Testdokumenten, siehe Abbildung 19. Variabilität Veranstaltung konfigurieren «include» «include» «include» /** * Generate the PSML tree from course hierarchy definitions ElatePortalException */ public synchronized void build() throws ElatePortalException { Einschreibungen verwalten FileArea administrieren RuntimeException e = (RuntimeException) Subject.doAsPrivileged( admin, new PrivilegedAction(){ Forum administrieren public Object run(){ try { Requirements Design Realisation Test Abbildung 19 Traceability im Variabilitätsmodell (nach [PBL05]) 33
Agile Vorgehensmodelle in der Softwareentwicklung: Scrum
C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was
IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit
IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft
Microsoft SharePoint 2013 Designer
Microsoft SharePoint 2013 Designer Was ist SharePoint? SharePoint Designer 2013 Vorteile SharePoint Designer Funktionen.Net 4.0 Workflow Infrastruktur Integration von Stages Visuelle Designer Copy & Paste
Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen
Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.
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.
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
Softwareanforderungsanalyse
Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen
Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.
Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung
Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08
Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer
Use Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
StuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.
StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
Beschreibung des MAP-Tools
1. Funktionen des MAP-Tool 2. Aufbau des MAP-Tools 3. Arbeiten mit dem MAP-Tool Beschreibung MAP-Tool.doc Erstellt von Thomas Paral 1 Funktionen des MAP-Tool Die Hauptfunktion des MAP-Tools besteht darin,
MO 27. Aug. 2007, 17:00 UHR JAVA FRAMEWORKS TIPPS VON PROFI-GÄRTNERN GEGEN WILDWUCHS
072 MO 27. Aug. 2007, 17:00 UHR JAVA FRAMEWORKS TIPPS VON PROFI-GÄRTNERN GEGEN WILDWUCHS Die Flut von Open Source Frameworks ist vergleichbar mit dem Markt von kommerziellen Produkten Es gibt eine Vielzahl
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
Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5
Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat
arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek
arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis
360 - Der Weg zum gläsernen Unternehmen mit QlikView am Beispiel Einkauf
360 - Der Weg zum gläsernen Unternehmen mit QlikView am Beispiel Einkauf Von der Entstehung bis heute 1996 als EDV Beratung Saller gegründet, seit 2010 BI4U GmbH Firmensitz ist Unterschleißheim (bei München)
Sehr geehrte Faktor-IPS Anwender,
März 2014 Faktor-IPS 3.11 Das neue Release Faktor-IPS 3.11 steht Ihnen zum Download zur Verfügung. Wir informieren Sie über die neusten Feautres. Lesen Sie mehr Sehr geehrte Faktor-IPS Anwender, Auf faktorzehn.org
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
Software Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle
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
Um zusammenfassende Berichte zu erstellen, gehen Sie folgendermaßen vor:
Ergebnisreport: mehrere Lehrveranstaltungen zusammenfassen 1 1. Ordner anlegen In der Rolle des Berichterstellers (siehe EvaSys-Editor links oben) können zusammenfassende Ergebnisberichte über mehrere
Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken
Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen
Content Management System mit INTREXX 2002.
Content Management System mit INTREXX 2002. Welche Vorteile hat ein CM-System mit INTREXX? Sie haben bereits INTREXX im Einsatz? Dann liegt es auf der Hand, dass Sie ein CM-System zur Pflege Ihrer Webseite,
extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?
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
Umfrage zum Informationsbedarf im Requirements Engineering
Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine
Research Note zum Thema: Laufzeit von Support-Leistungen für Server OS
Research Note zum Thema: Laufzeit von Support-Leistungen für Axel Oppermann Advisor phone: +49 561 506975-24 mobile: +49 151 223 223 00 axel.oppermann@experton-group.com November 2009 Inhalt 1 EINFÜHRUNG
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
Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003
Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen
Multichannel Challenge: Integration von Vertriebsorganisation und Contact Center in der Versicherung
Philip Michel CRM Project Manager 23 June 2011 Multichannel Challenge: Integration von Vertriebsorganisation und Contact Center in der Versicherung 2009 IBM Corporation Die Multichannel Challenge eines
Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009
- Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur
Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.
Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat
Die Lernumgebung des Projekts Informationskompetenz
Beitrag für Bibliothek aktuell Die Lernumgebung des Projekts Informationskompetenz Von Sandra Merten Im Rahmen des Projekts Informationskompetenz wurde ein Musterkurs entwickelt, der den Lehrenden als
EIDAMO Webshop-Lösung - White Paper
Stand: 28.11.2006»EIDAMO Screenshots«- Bildschirmansichten des EIDAMO Managers Systemarchitektur Die aktuelle EIDAMO Version besteht aus unterschiedlichen Programmteilen (Komponenten). Grundsätzlich wird
[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL
[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL Was bedeutet Customer Service by KCS.net? Mit der Einführung von Microsoft Dynamics AX ist der erste wichtige Schritt für viele Unternehmen abgeschlossen.
Speicher in der Cloud
Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG
SDD System Design Document
SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen
.. für Ihre Business-Lösung
.. für Ihre Business-Lösung Ist Ihre Informatik fit für die Zukunft? Flexibilität Das wirtschaftliche Umfeld ist stärker den je im Umbruch (z.b. Stichwort: Globalisierung). Daraus resultierenden Anforderungen,
Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt
Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse
Software Systems Engineering
Software : SoSe 08 Prof. Dr. Klaus Schmid Software Produktlinien Ein neues Programm soll erstellt werden. Das habe ich doch schon mal programmiert, oder? Alter Code passt aber nicht ganz! Wird passend
SCHULUNG MIT SYSTEM: E-LEARNING VON RAUM21
SCHULUNG MIT SYSTEM: E-LEARNING VON RAUM21 - Schulungskonzept - Moodle Das E-Learning System - Die E-Learning-Plattform von raum21 - Ansprechpartner D A S S C H U L U N G S K O N Z E P T V O N R A U M
Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.
Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation
Interkulturelles Projektmanagement in internationalen Projekten am Beispiel von afghanischen Mitarbeitern. Bachelorarbeit
Interkulturelles Projektmanagement in internationalen Projekten am Beispiel von afghanischen Mitarbeitern Bachelorarbeit zur Erlangung des akademischen Grades,,Bachelor of Science (B.Sc.) im Studiengang
Objektorientierte Programmierung für Anfänger am Beispiel PHP
Objektorientierte Programmierung für Anfänger am Beispiel PHP Johannes Mittendorfer http://jmittendorfer.hostingsociety.com 19. August 2012 Abstract Dieses Dokument soll die Vorteile der objektorientierten
Analyse zum Thema: Laufzeit von Support-Leistungen für ausgewählte Server OS
Analyse zum Thema: Laufzeit von Support-Leistungen für Axel Oppermann Advisor phone: +49 561 506975-24 mobile: +49 151 223 223 00 axel.oppermann@experton-group.com Januar 2010 Inhalt Summary und Key Findings
Windows Server 2012 R2 Essentials & Hyper-V
erklärt: Windows Server 2012 R2 Essentials & Hyper-V Windows Server 2012 R2 Essentials bietet gegenüber der Vorgängerversion die Möglichkeit, mit den Boardmitteln den Windows Server 2012 R2 Essentials
OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten
Outsourcing Advisor Bewerten Sie Ihre Unternehmensanwendungen auf Global Sourcing Eignung, Wirtschaftlichkeit und wählen Sie den idealen Dienstleister aus. OUTSOURCING ADVISOR Der Outsourcing Advisor ist
Primzahlen und RSA-Verschlüsselung
Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also
1 Mathematische Grundlagen
Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.
Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch
Ein Blick voraus des Autors von C++: Bjarne Stroustrup 04.06.2005 Conrad Kobsch Inhalt Einleitung Rückblick Nur eine Übergangslösung? Was würde C++ effektiver machen? Quelle 2 Einleitung Wo steht C++,
Einführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
Business Application Framework für SharePoint Der Kern aller PSC-Lösungen
Business Application Framework für SharePoint Der Kern aller PSC-Lösungen Überblick pscbaf Dieses Dokument liefert die Antworten auf folgende Fragen: Was ist das Portal Systems Business Application Framework
Aufgabenheft. Fakultät für Wirtschaftswissenschaft. Modul 32701 - Business/IT-Alignment. 26.09.2014, 09:00 11:00 Uhr. Univ.-Prof. Dr. U.
Fakultät für Wirtschaftswissenschaft Aufgabenheft : Termin: Prüfer: Modul 32701 - Business/IT-Alignment 26.09.2014, 09:00 11:00 Uhr Univ.-Prof. Dr. U. Baumöl Aufbau und Bewertung der Aufgabe 1 2 3 4 Summe
Die PROJEN-GmbH bietet ihren Kunden einheitliche
Die PROJEN-GmbH Hintergründe und Entstehung Der Ursprung der PROJEN-GmbH liegt in der Projektmanagement-Beratung. Die Firmengründer haben 2011 gemeinschaftlich ein ganzheitliches Konzept für professionelles
SPI-Seminar : Interview mit einem Softwaremanager
Erstellung eines Fragenkatalogs der die Beurteilung der Level 2 Key Process Areas in einem ca. einstündigen Interview mit einem Software Manager ermöglicht Vortrag von Matthias Weng 1 Aufbau Geschichte
Mobile Intranet in Unternehmen
Mobile Intranet in Unternehmen Ergebnisse einer Umfrage unter Intranet Verantwortlichen aexea GmbH - communication. content. consulting Augustenstraße 15 70178 Stuttgart Tel: 0711 87035490 Mobile Intranet
Kapitel 2: Der Software-Entwicklungsprozess
Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken
Cloud Architektur Workshop
Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell
Bei der Focus Methode handelt es sich um eine Analyse-Methode die der Erkennung und Abstellung von Fehlerzuständen dient.
Beschreibung der Focus Methode Bei der Focus Methode handelt es sich um eine Analyse-Methode die der Erkennung und Abstellung von Fehlerzuständen dient. 1. F = Failure / Finding An dieser Stelle wird der
AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b
AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität
Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.
1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich
Kursdemo zum Kurs Vertragsgestaltung und Vertragsmanagement. Prof. Dr. Inge Scherer
Kursdemo zum Kurs Vertragsgestaltung und Vertragsmanagement Prof. Dr. Inge Scherer Inhaltsverzeichnis Der Onlinekurs Vertragsgestaltung und Vertragsmanagement soll Ihnen die Technik der Vertragsgestaltung
Eine Logikschaltung zur Addition zweier Zahlen
Eine Logikschaltung zur Addition zweier Zahlen Grundlegender Ansatz für die Umsetzung arithmetischer Operationen als elektronische Schaltung ist die Darstellung von Zahlen im Binärsystem. Eine Logikschaltung
SWOT-Analyse. Der BABOK V2.0 (Business Analysis Body Of Knowledge) definiert die SWOT-Analyse wie folgt:
SWOT-Analyse Die SWOT-Analyse stammt ursprünglich aus dem militärischen Bereich und wurde in den 1960er-Jahren von der Harvard Business School zur Anwendung in Unternehmen vorgeschlagen. Die SWOT-Analyse
Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter
Leseprobe Thomas Konert, Achim Schmidt Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41230-9 sowie im Buchhandel. Carl
Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
Erfolgreiche ITIL Assessments mit CMMI bei führender internationaler Bank
Turning visions into business Oktober 2010 Erfolgreiche ITIL Assessments mit CMMI bei führender internationaler Bank David Croome Warum Assessments? Ein strategisches Ziel des IT-Bereichs der Großbank
D i e n s t e D r i t t e r a u f We b s i t e s
M erkblatt D i e n s t e D r i t t e r a u f We b s i t e s 1 Einleitung Öffentliche Organe integrieren oftmals im Internet angebotene Dienste und Anwendungen in ihre eigenen Websites. Beispiele: Eine
SMART Newsletter Education Solutions April 2015
SMART Education Newsletter April 2015 SMART Newsletter Education Solutions April 2015 Herzlich Willkommen zur aktuellen Ausgabe des Westcon & SMART Newsletters jeden Monat stellen wir Ihnen die neuesten
Einleitung: Frontend Backend
Die Internetseite des LSW Deutschland e.v. hat ein neues Gesicht bekommen. Ab dem 01.01.2012 ist sie in Form eines Content Management Systems (CMS) im Netz. Einleitung: Die Grundlage für die Neuprogrammierung
Intranet/Extranet: Zentrales CMS oder Portal-Lösung
Intranet/Extranet: Zentrales CMS oder Portal-Lösung Erstellt am durch Jan Eickmann Ihr Ansprechpartner: Jan Eickmann Telefon: 0221-569576-22 E-Mail: j.eickmann@kernpunkt.de Inhalt Einleitung... 3 Content
Was sind Jahres- und Zielvereinbarungsgespräche?
6 Was sind Jahres- und Zielvereinbarungsgespräche? Mit dem Jahresgespräch und der Zielvereinbarung stehen Ihnen zwei sehr wirkungsvolle Instrumente zur Verfügung, um Ihre Mitarbeiter zu führen und zu motivieren
Übungsaufgaben zum Software Engineering: Management
Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie
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
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
Outsourcing und Offshoring. Comelio und Offshoring/Outsourcing
Outsourcing und Offshoring Comelio und Offshoring/Outsourcing INHALT Outsourcing und Offshoring... 3 Comelio und Offshoring/Outsourcing... 4 Beauftragungsmodelle... 4 Projektleitung vor Ort und Software-Entwicklung
Georg Grzonka. Prozesse im Unternehmen strukturieren und darstellen. - Leseprobe -
Georg Grzonka Prozesse im Unternehmen strukturieren und darstellen Übersicht über die Arbeitshilfen Prozessbeschreibung in Tabellenform (datei_01.doc) Prozessdarstellung als Kombination von Ablaufdiagramm
Mit der Maus im Menü links auf den Menüpunkt 'Seiten' gehen und auf 'Erstellen klicken.
Seite erstellen Mit der Maus im Menü links auf den Menüpunkt 'Seiten' gehen und auf 'Erstellen klicken. Es öffnet sich die Eingabe Seite um eine neue Seite zu erstellen. Seiten Titel festlegen Den neuen
ANYWHERE Zugriff von externen Arbeitsplätzen
ANYWHERE Zugriff von externen Arbeitsplätzen Inhaltsverzeichnis 1 Leistungsbeschreibung... 3 2 Integration Agenda ANYWHERE... 4 3 Highlights... 5 3.1 Sofort einsatzbereit ohne Installationsaufwand... 5
Urlaubsregel in David
Urlaubsregel in David Inhaltsverzeichnis KlickDown Beitrag von Tobit...3 Präambel...3 Benachrichtigung externer Absender...3 Erstellen oder Anpassen des Anworttextes...3 Erstellen oder Anpassen der Auto-Reply-Regel...5
Implementation of a Framework Component for Processing Tasks within Threads on the Application Level
Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Deutsches Krebsforschungszentrum, for Processing Task within Threads on the Application Level Motivation
geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen
geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde
Kurzfassung der Studienarbeit
Kurzfassung der Studienarbeit Abteilung Informatik Namen der Studenten Roman Widmer Mikkala Pedersen Studienjahr Sommersemester 2004 Titel der Studienarbeit.NET Skript Debugger Examinator Der GUI-Builder
Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung
Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und
Das Wasserfallmodell - Überblick
Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung
Kostenstellen verwalten. Tipps & Tricks
Tipps & Tricks INHALT SEITE 1.1 Kostenstellen erstellen 3 13 1.3 Zugriffsberechtigungen überprüfen 30 2 1.1 Kostenstellen erstellen Mein Profil 3 1.1 Kostenstellen erstellen Kostenstelle(n) verwalten 4
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:
Vortrag von: Ilias Agorakis & Robert Roginer
MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile
Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten
Das große x -4 Alles über das Wer kann beantragen? Generell kann jeder beantragen! Eltern (Mütter UND Väter), die schon während ihrer Elternzeit wieder in Teilzeit arbeiten möchten. Eltern, die während
Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität
Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen
Ishikawa-Diagramm. 1 Fallbeispiel 2. 2 Was ist ein Ishikawa-Diagramm 2. 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2.
Ishikawa-Diagramm 1 Fallbeispiel 2 2 Was ist ein Ishikawa-Diagramm 2 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2 4 Vorteile 5 5 Nachteile 5 6 Fazit 5 7 Literaturverzeichnis 6 1 Fallbeispiel
Was versteht man unter Softwaredokumentation?
Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie
Energetische Klassen von Gebäuden
Energetische Klassen von Gebäuden Grundsätzlich gibt es Neubauten und Bestandsgebäude. Diese Definition ist immer aktuell. Aber auch ein heutiger Neubau ist in drei (oder vielleicht erst zehn?) Jahren
ZENITY - Die Software für Ihre Unternehmens-Releaseplanung
ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen
REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1
REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir
Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks