Entscheidungsprozess für rationale Architekturentscheidungen

Größe: px
Ab Seite anzeigen:

Download "Entscheidungsprozess für rationale Architekturentscheidungen"

Transkript

1 Entscheidungsprozess für rationale Architekturentscheidungen Sven Wohlfarth Fachgebiet Softwaresysteme/Prozessinformatik Technische Universität Ilmenau, Ilmenau, Germany Zusammenfassung Eine hohe Architekturqualität geschäftskritischer Softwaresysteme ist eine zentrale Voraussetzung, um auf Marktveränderungen zeitnah reagieren zu können. Die Entscheidung für die richtige Architektur ist jedoch von vielen Faktoren abhängig: Qualitätsziele, Aufwand, Rahmenbedingungen. Erfolgt die Entscheidung auf Basis subjektiver und zu optimistischer Erwartungen drohen negative Konsequenzen, deren Beseitigung mit erheblichem Mehraufwand verbunden ist. Zur Reduzierung der Risiken wird ein Prozess entwickelt, mit dem rationale Entscheidungen bei der Architekturentwicklung ermöglicht werden. Architekturentwicklung, Entscheidungstheorie, Architekturorientieres Refactoring, Softwarequalität 1. Risiken bei Architekturentscheidungen Die immer kürzeren Innovationszyklen bei Technologiegütern zwingen Unternehmen zu Flexibilität und Anpassungsfähigkeit. Mit modernen Mobiltelefonen können z.b. Informationen, Podcasts oder Video-Downloads aus dem Internet geladen werden. Solche Innovationen schaffen ihre eigenen Märkte und Medienunternehmen sind gezwungen diese Inhalte anzubieten. Können die Abrechnungssysteme jedoch nicht zeitnah angepasst werden, drohen Verluste aufgrund zu hoher Kosten. Es ist teuerer, den Podcast-Nutzern Rechnungen zu schicken, als das Inkassosystem des Mobilfunkanbieters zu nutzen. Eine der wichtigsten Voraussetzungen, um geschäftskritische Softwaresysteme zeitnah anpassen zu können, eine hohe Architekturqualität. Die Architektur muss u.a. verständlich, wartungsfreundlich und leicht zu testen sein, damit Veränderungen oder Erweiterungen zügig umgesetzt werden können. Um eine hohe Architekturqualität zu erzielen ist ein strukturiertes und planvolles Vorgehen notwendig. Dies gilt einerseits für die Entwicklung eines neuen Softwaresystems, bei der eine geeignete Architektur zur Erfüllung der Qualitätsziele auszuwählen ist. Andererseits müssen bei der Restrukturierung gewachsener Legacy-Systeme die richtigen Architekturentscheidungen getroffen werden. Bei der Entscheidung für oder gegen eine Architekturalternative (z.b. Einsatz des Architekturmusters Broker) müssen neben nicht-funktionalen Anforderungen weitere Faktoren berücksichtigt werden: - Konkurrierende Ziel-Beziehungen (z.b. Wartbarkeit versus Performance) - Vermeidung von Einschränkungen an der Funktionalität (z.b. funktionale Restriktionen durch das Sandbox- Prinzip beim Einsatz von Java-Applets) - Berücksichtigung und Einhaltung organisatorischer und technischer Rahmenbedingungen (z.b. Termine, Budget, Beachtung von Standards) Im Entscheidungsfall müssen alle Faktoren ausgewogen berücksichtigt werden. In der Praxis erfolgt dies häufig auf Basis subjektiver und meist zu optimistischer Erwartungen. Das führt dazu, dass mittelmäßige Kompromisslösungen als ideale Systemstrukturen aufgefasst werden. Es drohen unerwartete negative Seiteneffekte und Veränderungen am funktionalen Verhalten, deren Beseitigung mit einem erheblichen Mehraufwand verbunden ist. Zur Reduzierung des subjektiven Einflusses auf die Entscheidung soll ein Prozess entwickelt werden, um rationale Entscheidungen bei der Architekturentwicklung zu ermöglichen. Das Ziel ist es, Architekturalternativen durch ein geeignetes methodisches Vorgehen systematisch auszuwählen, deren Konsequenzen objektiv zu ermitteln und sie anhand der Erfüllung der Qualitätsziele und Rahmenbedingungen rational zu bewerten. Der Ausgangspunkt für die Prozessentwicklung sind die Konzepte der Entscheidungstheorie. Diese werden im zweiten Kapitel analysiert, um zu bestimmen, welche Anpassungen für Entscheidungen bei der Architekturentwicklung notwendig sind. Der entwickelte Entscheidungsprozess wird im dritten Kapitel anhand eines praktischen Beispiels dargestellt. 2. Adaption der Entscheidungstheorie Im Rahmen der Entscheidungstheorie werden der deskriptive und der präskriptive Ansatz unterschieden [1]. Während ersterer das Entscheidungsverhalten von Individuen auf kognitiver Ebene beschreibt, ist das Ziel des präskriptiven Ansatzes die Festlegung eines Vorgehens, um Entscheidungen rational treffen zu können. Ein rationales Handeln liegt vor, wenn die Entscheidungsfindung systematisch und objektiv ist.

2 Außerdem sind konsistente Entscheidungsgrundlagen (Ziele, Annahmen) erforderlich. Um rationale Entscheidungen zu ermöglichen wird im Rahmen der präskriptiven Entscheidungstheorie eine Dekomposition angestrebt [1]. Das Entscheidungsproblem wird aufgeteilt, um durch die isolierte Betrachtung der Teilprobleme die Komplexität zu reduzieren. Danach umfasst ein rationaler Entscheidungsprozess die folgenden Aktivitäten: - Strukturierung der Ziele: Der Ausgangspunkt ist die widerspruchsfreie Strukturierung der Ziele, die durch den Einsatz einer Alternative zu erreichen sind. - Vorauswahl der Alternativen: Im Rahmen der Vorauswahl werden jene Alternativen ausgewählt, welche zur Zielerreichung prinzipiell geeignet sind. - Analyse der Konsequenzen: Im Anschluss werden die Konsequenzen ermittelt. Das sind die Ergebnisse (z.b. Qualitätsverbesserungen), die nach der Entscheidung und Umsetzung einer Alternative zu erwarten sind. - Bewertung der Alternativen: Abschließend wird der Wert der Alternativen für den Entscheidungsträger bestimmt. Eine Alternative wird umso höher bewertet, je stärker die Konsequenzen zur Zielerreichung beitragen. Auf rationaler Ebene ist die Alternative mit dem höchsten Wert auszuwählen, da diese vom Entscheidungsträger am stärksten präferiert, bzw. bevorzugt wird. Der Entscheidungsträger im Rahmen von Architekturentscheidungen ist der Entwickler. Im Kontext von Architekturentscheidungen sind zwei weitere Aspekte zu beachten. Zur Ermittlung der kritischen Architekturbereiche sowie zur Bestimmung der Eignung von Alternativen ist eine Beschreibung der Architektur erforderlich. Darüber hinaus ist durch geeignete Verfahren zu analysieren, ob durch die Implementierung einer Alternative Einschränkungen an der Funktionalität drohen. Die Relevanz der beiden Aspekte wird an einem vergleichbaren, bereits vorgestellten Entscheidungsprozess für architekturorientiertes Refactoring deutlich [3]. Refactoring ist eine Form der Restrukturierung eines Softwaresystems, bei dem die Qualität verbessert, das funktionale Verhalten jedoch nicht verändert wird [4]. Die Refactoringalternativen sind neben Qualitätsaspekten danach zu bewerten, ob Änderungen am funktionalen Verhalten drohen. Für diese Analyse ist eine Beschreibung der relevanten Komponenten erforderlich. 3. Entscheidungsprozess für rationale Architekturentscheidungen Der Entscheidungsprozess zur Bewertung von Architekturalternativen umfasst vier Phasen. Die Aktivitäten des im vorangegangenen Kapitel dargestellten Entscheidungsprozesses wurden um die zwei zusätzlichen Aspekte erweitert (vgl. Abb.1). Die ersten beiden Phasen stehen in engem Zusammenhang zueinander und sind daher nebeneinander angeordnet. Zur Identifizierung der Ziele müssen u.a. die kritischen Bereiche der Architektur bekannt sein. Daran schließt sich die Auswahl und Konkretisierung der Alternativen an. Zur Auswahl stehen Muster, Stile, Technologien oder Softwareprodukte. In der vierten Phase werden die die Konsequenzen ermittelt, mit Schwerpunkt auf die funktionalen Auswirkungen, und es erfolgt die abschließende Bewertung der Alternativen. (1) Strukturierung der Ziele und Rahmenbedingungen (2) Beschreibung der Architektur (3) Vorauswahl und Konkretisierung der Alternativen (4) Ermittlung der Konsequenzen und Bewertung der Alternativen Basis: Muster, Stile, Technologien und Softwareprodukte Abb. 1: Entscheidungsprozess bei Architekturalternativen Praxisbeispiel: Typo3-Architekturveränderung Die Phasen werden anhand einer Architekturveränderung von Typo3 dargestellt. Typo3 ist ein quelloffenes Content-Management-System, um die Inhalte (Content) von umfangreichen und komplexen Webseiten zu verwalten [5]. Über verschiedene Werkzeuge (z.b. RTF- Editoren) werden die Inhalte einer Webseite eingegeben und in einer Datenbank gespeichert. Bei Anfrage eines Clients erfolgen die Abfrage der Inhalte aus der Datenbank und die dynamische Generierung der Webseiten. Gerade für kommunikationsintensive Unternehmen und Bildungseinrichtungen ist Typo3 kritisches Softwaresystem. So erfolgt z.b. der gesamte Webauftritt der TU Ilmenau auf Basis von Typo3. Die Einsatzmöglichkeiten von Typo3 in der Version sind jedoch beschränkt, da ausschließlich MySQL- Datenbanken eingesetzt werden können. Gerade im Unternehmensumfeld können jedoch z.b. aus Sicherheitsgründen häufig keine MySQL-Datenbanken installiert werden. Durch eine qualitätsorientierte Architekturveränderung ist dieses Portabilitätsproblem zu beheben. 3.1 Ziele und Rahmenbedingungen In der ersten Phase werden die zu erfüllenden Qualitätsziele identifiziert und widerspruchsfrei strukturiert. Darüber hinaus sind die organisatorischen und technischen Rahmenbedingungen zu ermitteln. Sind die Schwachstellen noch nicht im Detail bekannt, können sie durch szenariobasierte Architekturanalysen ermittelt werden. Eine der wichtigsten Analysemethoden ist die Architecture-Tradeoff-Analysis-Method (ATAM) [6]. Auf Basis von Szenarien werden zentrale Bereiche der Architektur analysiert, in wie weit sie geeignet sind, festgelegte Qualitätsziele zu erfüllen. Es wird z.b. analysiert, ob bei kritischen Fehlern in einer Komponente die Zuverlässigkeit gewahrt bleibt. Im Anschluss an die Identifizierung erfolgt die widerspruchsfreie Strukturierung der Qualitätsziele. Ziel- Mittel- sowie konkurrierende Beziehungen zwischen Zielen sind aufzulösen. Hierfür wird in der Ent-

3 scheidungstheorie eine Klassifikationsmethode vorgeschlagen [2]. Die Ziele werden in Fundamental- und Instrumentalziele klassifiziert. Die Erfüllung von stets niederrangigen Instrumentalzielen ist die Voraussetzung zur Erreichung der Fundamentalziele. Die Verständlichkeit ist z.b. ein Instrumentalziel zur Verbesserung der Wartbarkeit. Zusätzlich sind die organisatorischen und technischen Rahmenbedingungen zu ermitteln [7]. Organisatorische sind z.b. Budget- und Terminvorgaben, sowie die Anzahl der verfügbaren Mitarbeiter zur Implementierung einer Alternative. Technische Rahmenbedingungen sind z.b. verfügbare Hardwareressourcen, einzuhaltende Standards (z.b. Protokolle) oder bereits implementierte Systemstrukturen (z.b. Muster oder Stile). Die zu erwarteten Qualitätsauswirkungen und der Implementierungsaufwand wird von diesen Faktoren maßgeblich beeinflusst. In Abb. 2 sind die Qualitätsziele für die Typo3- Architekturveränderung aufgeführt. Das Fundamentalziel ist die Verbesserung der Portabilität. Um dies zu erreichen ist eine Restrukturierung des Datenbankzugriffes erforderlich. Eine erste Grobanalyse zeigte, dass hierfür die Kapselung des Datenbankzugriffes durch eine Abstraktionsschicht sinnvoll ist. In dieser Schicht soll die notwendige Funktionalität implementiert sein, um auf verschiedene Datenbanken (z.b. MySQL, Oracle) zugreifen zu können. Ein konkurrierendes Ziel ist die Performance im Hinblick auf die Datenbank-Zugriffszeiten. Diese dürfen keinesfalls negativ verändert werden. Portabilität (Fundamental) Performance (Konkurrierendes Ziel) Restrukturierung des Keine Veränderungen Datenbankzugriffs an den Zugriffszeiten Instrumentalziel 1 Kapselung des Datenbankzugriffes durch API Instrumentalziel 2 Abb. 2: Qualitätsziele für Tyop3-Architekturveränderung Als organisatorische Rahmenbedingung sollte die Dauer der Architekturveränderung 50 Personentage nicht überschreiten. Unter technischen Gesichtspunkten ist Typo3 vollständig in der Skriptsprache PHP programmiert und benötigt zur Laufzeit einen entsprechenden Webserver. Trotz der Architekturveränderung soll Typo3 zu früheren Versionen abwärtskompatibel sein. 3.2 Beschreibug der Architektur In der zweiten Phase wird die Architektur des Softwaresystems beschrieben. Das ist notwendig, um die Eignung der Alternativen und deren Konsequenzen zu bestimmen. Zur Komplexitätsreduzierung ist es erforderlich die richtige Sicht auf die Architektur zu wählen. Die Architekturbeschreibung sollte alle Komponenten umfassen, die direkt und indirekt von der Architekturveränderung betroffenen sind. Die direkt betroffenen sind die zu verändernden Komponenten; die indirekt betroffenen Komponenten bauen auf der Funktionalität der veränderten auf. Um die Architektur zu beschreiben muss die Informationsgrundlage analysiert und strukturiert werden. Quellen sind die Dokumentation, bereits existierende Architekturbeschreibungen oder auch der Quellcode. Der Entwickler muss die Validität der Informationen überprüfen, z.b. in wie weit eine evtl. vorliegende Architekturbeschreibung mit dem entwickelten System übereinstimmt. Im Falle der Entwicklung eines neuen Softwaresystems steht noch keine Architektur zur Verfügung. Die Praxis zeigt jedoch, dass häufig zuerst ein Grundkonzept der Architektur erarbeitet wird, um die funktionalen Anforderungen zu erfüllen (z.b. ein Prototyp). Erst im Anschluss erfolgt die Berücksichtigung der Qualitätsaspekte. Somit kann auch in diesem Fall ein Grobkonzept der Architektur oder ein Prototyp beschrieben werden. Für die Beschreibung steht eine Vielzahl an Beschreibungssprachen zur Verfügung: ACME [8], die UML [9] oder die relativ moderne xadl [10]. Da die Vorauswahl der Architekturalternativen erst in der nächsten Phase erfolgt, kann eine Erweiterung der Beschreibung notwendig werden. In Abb. 3 ist ein Überblick über die Architektur von Typo3 dargestellt. Zentrales Element ist der Typo3-Kern, welcher Bibliotheken für die grundlegenden Funktionen enthält (z.b. die Rechteverwaltung). In der Version existiert mit 'T3lib_db' eine Abstraktionsschicht, welche Funktionen für den ausschließlichen Zugriff auf MySQL- Datenbanken zur Verfügung stellt. Dies sind native PHP- Funktionen in der Form 'mysql_query(sql-statement)'. Für Typo3 steht eine Reihe an Erweiterungen zur Verfügung, die über eine 'Extension API' auf den Kern zugreifen können. Über das Backend erfolgen die Eingabe der Inhalte und die Konfiguration der Webseiten; das Frontend dient zur dynamischen Generierung der Webseiten. Frontend Weitere Kernkomponenten, z.b. T3lib_tcemain Database Abstraction Base API (T3lib_db) Typo3 Kern Extension Extension Extension API MySQL-Datenbank Backend Abb. 3: Überblick über die Typo3-Architektur 3.3 Vorauswahl und Konkretisierung In der dritten Phase erfolgt die Vorauswahl der Alternativen. Dies ist notwendig, um nur die Alternativen zu berücksichtigen, die für die qualitätsorientierte Architekturentwicklung geeignet sind. Zur Auswahl stehen einerseits Architekturmuster und mit Einschränkungen (...)

4 Entwurfsmuster. Dies sind häufig eingesetzte Musterlösungen bei Entwurf von Architekturen oder umfangreichen Komponentenstrukturen [11]. Entwurfsmuster, die lediglich Quellcode-Fragmente umfassen sind aufgrund des geringen Abstraktionsgrades nicht als Architekturalternativen geeignet. Zum Beispiel beschreibt das Singelton lediglich einen Referenzzähler, um die Instanzen einer Klasse zu zählen. Darüber hinaus können Architekturstile sinnvolle Alternativen darstellen. Mit Stilen (z.b. dem Schichten-Stil) werden auf abstrakter Ebene grundlegende Komponentenstrukturen, sowie Kontroll- und Datenflüsse spezifiziert. Andererseits können Technologien und Softwareprodukte als Alternativen eingesetzt werden (z.b. Komponententechnologien, bestimmte Programmiersprachen oder Bibliotheken) [7]. Die Vorauswahl der Alternativen basiert auf deren erwarteten Qualitätsauswirkungen. Für einzelne Muster und Stile sind die Qualitätseigenschaften bekannt [11]. Eine Kapselung von Komponenten kann z.b. durch den Einsatz der Entwurfsmuster Fassade oder Vermittler ermöglicht werden. Ein Qualitätsmodell zur übergreifenden Analyse von Alternativen fehlt indes. Im Rahmen der Vorauswahl erfolgt eine prototypische Modell-Implementierung. Nachdem ca. 5 bis 6 prinzipiell geeignete Alternativen ermittelt wurden, werden sie prototypisch in das bereits vorliegende Architekturmodell implementiert. Ein UML-Klassendiagramm wird z.b. um eine Fassade oder Vermittler ergänzt; die Klassenstruktur wird entsprechend verändert. Auf dieser Basis kann grob abgeschätzt werden, welche Qualitätsauswirkungen zu erwarten sind und ob die Rahmenbedingungen eingehalten werden können. Das Ziel ist die Reduzierung die Menge an Alternativen auf 2 bis 3 besonders geeignete. Eine Übersicht über das Verfahren der Vorauswahl ist in Abb. 4 dargestellt. Menge an Alternativen Bekannte Qualitätsauswirkungen 5 bis 6 Alternativen Prototypische Modell-Implementierung 2 bis 3 Alternativen Geeignete Qualitätsauswirkungen und Erfüllung der Rahmenbedingungen Abb. 4: Vorauswahl der Alternativen Im Anschluss erfolgt die Konkretisierung der Alternativen. Für jede der 2 bis 3 Alternativen wird die Folge an Implementierungsschritten ermittelt, die zur Erreichung der Ziele im konkreten Anwendungsfall notwendig sind. Im Falle der Alternative Fassade ist bspw. zu ermitteln, welche Komponenten zur Realisierung der Kapselung hinzuzufügen oder zu verändern sind. Die Konkretisierung ist ein iterativer Prozess. Die Schrittfolge wird so lange ergänzt oder korrigiert, bis die Qualitätsziele im erforderlichen Umfang erfüllt werden. Eine Iteration umfasst die folgenden Schritte: - Festlegung der Schrittfolge: Ausgangspunkt der Konkretisierung ist die prototypische Modell- Implementierung. Auf Basis der schrittweisen Modellveränderung (z.b. der Veränderung des Klassendiagramms) werden die konkreten Implementierungsschritte abgeleitet. Somit wird die zukünftige Architektur des Softwaresystems auf konkreter Basis deutlich (z.b. mit implementierten Fassade-Muster). - Szenarioanalyse: Im Anschluss wird überprüft, ob die erforderlichen Qualitätsziele erreicht werden. Dies erfolgt anhand von Szenarien, die aus den Qualitätszielen abgeleitet werden. Ein Beispiel ist das Szenario 'Austausch einer Komponente' für das Ziel Wartbarkeit. Durch Walkthroughs wird geprüft, ob mit der zukünftigen Architektur die Qualitätsziele erfüllt werden. Ein Walkthrough ist ein Peer-Review eines Szenarios [14]. - Reaktion: Werden die Qualitätsziele nicht oder nur teilweise erfüllt, sind zusätzliche Implementierungsschritte notwendig oder die bisherige Schrittfolge ist zu korrigieren. In diesem Fall wird eine erneute, evtl. reduzierte Szenarioanalyse erforderlich. Andernfalls ist die Konkretisierung der Alternative beendet. Der zu erwartende Qualitätszustand kann jedoch nicht immer mit Sicherheit bestimmt werden. Unsicherheiten treten vor allem dann auf, wenn technische Rahmenbedingungen die Qualitätsauswirkungen der Alternativen beeinflussen. Ein Beispiel sind wahrscheinliche Wechselwirkungen mit einem bereits implementierten Muster. Es werden ergänzende Schritte spezifiziert, die nur dann anzuwenden sind, wenn die Wechselwirkungen tatsächlich eintreten. Somit existieren optimistische und pessimistische Implementierungsvarianten. Um bei Typo3 über eine Datenbank-Abstraktionsschicht transparent auf verschiedene Datenbanksysteme zugreifen zu können sind drei Alternativen prinzipiell geeignet: - ADODB: Es kann die Bibliothek eingesetzt werden [12]. Diese beinhaltet Funktionen zur Transformation von SQL-Statements. Transformationen sind aufgrund von Lücken im SQL-Standard notwendig [13]. Da z.b. das Format von Timestamps im aktuellen SQL-Standard nicht festgelegt ist, sind diese bei nahezu jedem Datenbanksystem anders implementiert. - Native Datenbanktreiber: Die zweite Alternative ist die Entwicklung spezieller Bibliotheken für den Zugriff auf die jeweiligen Datenbanksysteme (Oracle, MySQL...). Darin werden native PHP-Funktionen zum Datenbankzugriff implementiert, z.b. 'ora_parse (SQL-Statement, Parameter)' für den Zugriff auf Oracle. Zur Kapselung der Bibliotheken kann bspw. das Entwurfsmuster Fassade eingesetzt werden. - ANSI-SQL: Eine weitere Alternative ist die Einschränkung der SQL-Statements auf ANSI-SQL [13]. Im Vergleich zur aktuellen Version von SQL (SQL2 oder SQL-92) steht nur ein reduzierter SQL-Syntax zur Verfügung. Dieser ist jedoch bei den aktuellen Datenbanksystemen einheitlich implementiert. Ein im ANSI-

5 SQL-Syntax formuliertes SQL-Statement erfordert daher keine weiteren Transformationen. Eine prototypische Modell-Implementierung zeigte, dass mit der ANSI-SQL Alternative grundlegende Änderungen am SQL-Syntax notwendig sind; die geforderte Abwärtskompatibilität ist damit nicht mehr gegeben. Die ersten zwei Alternativen erfüllen die Vorauswahl-Kriterien und werden anschließend konkretisiert. In Abb. 5 sind die konkretisierten Typo3-Alternativen dargestellt. Die ersten Schritte der Alternative sind die Implementierung der gleichnamigen Bibliothek sowie die Anpassung der 'T3lib_db', damit das Typo3- System über die Funktionen auf die Datenbank zugreifen kann. Durch die Transformationen drohen erhebliche Performance-Einbußen. Mit einer Wahrscheinlichkeit von 40% sind daher ergänzende Optimierungen notwendig. Im Rahmen der zweiten Alternative sind die entsprechenden Bibliotheken (hier für MySQL und Oracle) zu entwickeln. Analog zur ersten Alternative ist die 'T3lib_db' anzupassen, damit die Bibliotheken vom Typo3-System genutzt werden können. Alternative Implementierung Bibliothek Entwicklung Oracle- Bibliothek Anpassung T3lib_db Entwicklung MySQL- Bibliothek Native Datenbanktreiber Abb. 5: Konkretisierte Typo3-Alternativen Wahrscheinlichkeit Performance Optimierungen 40% Anpassung T3lib_db 100% 3.4 Ermittlung der Konsequenzen und Bewertung In der letzten Phase des Entscheidungsprozesses werden die Konsequenzen der Alternativen ermittelt. Das ist notwendig, da nur auf dieser Basis eine rationale Bewertung und Entscheidung über die Alternativen erfolgen kann. Die folgenden Konsequenzen sind zu berücksichtigen: - Funktionale Einschränkungen: Im ersten Schritt werden drohende Einschränkungen im funktionalen Verhalten ermittelt. Dies erfolgt erneut auf Basis einer Szenarioanalyse. Die Szenarien basieren auf den funktionalen Anforderungen an das Softwaresystem. Über Walkthroughs wird vor allem bei den direkt veränderten Komponenten analysiert, ob die funktionalen Anforderungen erfüllt werden. Werden diese nicht in vollem Umfang erfüllt, sind entweder Korrekturen an den Implementierungsschritten notwendig. Kleinere Probleme können aber auch bei der tatsächlichen Implementierung behoben werden. Gerade für diese Analyse ist es wichtig, dass die Architekturbeschreibung alle relevanten Komponenten und Beziehungen umfasst. - Implementierungsaufwand: Im zweiten Schritt wird der Aufwand in Stunden oder Personentagen ermittelt, der für die Implementierung der Alternative notwendig ist. Die Basis für die Ermittlung sind u.a. historische Vergleichsdaten. Bei Alternativen mit optimistischen und pessimistischen Implementierungsvarianten werden mehrere Aufwandszahlen ermittelt. - Qualitätsauswirkungen: Es steht zwar bereits fest, dass mit den Alternativen der erforderliche Qualitätszustand erreicht werden kann. Der Grad der Zielerreichung muss durch den Entwickler noch quantifiziert werden (z.b. durch Noten oder Prozentwerte). In Abb. 6 sind die Konsequenzen der beiden Alternativen dargestellt. Die Alternative führt in beiden Fällen zu einer Portabilität mit der Note 2. Mit den Optimierungen verbessert sich die Performance um eine Note auf 2, jedoch erhöht sich der Aufwand um 20 auf 50 Personentage (PT). Die zweite Alternative erfordert durch die Entwicklung der Bibliotheken einen hohen Aufwand in Höhe von 50 PT. Das Ergebnis ist jedoch eine hohe Portabilität und Performance (je Note 1). Durch eine Szenarioanalyse konnte ermittelt werden, dass keine funktionalen Einschränkungen drohen, da eine MySQL- Abstraktionsschicht ohnehin existiert. Konsequenzen Portabilität / Performance / Aufwand 2 / 3 / 30 PT Alternative Performance 2 / 2 / 50 PT Optimierungen 40% Native Datenbanktreiber 1 / 1 / 50 PT Abb. 6: Konsequenzen der Typo3-Alternativen Die abschließende Bewertung der Alternativen umfasst zum einen die Normalisierung der Konsequenzen und deren Gewichtung. Sind Wahrscheinlichkeiten zu berücksichtigen ist der Erwartungswert zu berechnen. Dieses rationale Bewertungsverfahren wird im Rahmen der Entscheidungstheorie thematisiert [1]. Im ersten Schritt werden die Konsequenzen aufgrund der unterschiedlich skalierten Werte (Noten, Personentage ) auf ein Intervall zwischen null und eins normalisiert. Die Konsequenzen, die der Entwickler am stärksten präferiert (z.b. geringster Aufwand) werden mit eins normalisiert. Die nicht präferierten Konsequenzen (z.b. keine bis geringe Qualitätsverbesserungen) werden mit null normalisiert. Die Werte zwischen beiden Extremen werden zwischen null und eins verteilt. Die Verteilung kann individuell oder z.b. mittels der Direct- Rating-Methode erfolgen [15]. Abb. 7 stellt die Normalisierung am Beispiel der Typo3-Alternativen dar. Portabilität / Performance / Aufwand 2 / 3 / 30 PT 0 / 0 / 1 Alternative 2 / 2 / 50 PT 0 / 0.5 / 0 40% Native Datenbanktreiber 1 / 1 / 50 PT 1 / 1 / 0 100% Abb. 7: Normalisierung der Konsequenzen Im zweiten Schritt werden die normalisierten Konsequenzen gewichtet. Das ist notwendig, da der Gesamtwert der Alternativen mit der Anzahl der betrachteten Konsequenzen stetig ansteigt. Die Gewichtung

6 erfolgt anhand der Relevanz oder Bedeutung der Ziele. Die Summe müssen alle Faktoren den Wert eins ergeben. Im Rahmen der Typo3-Architekturveränderung sind die Qualitätsziele für den Entwickler doppelt so wichtig wie der Aufwand. Die Gewichtungsfaktoren für die Qualitätsziele sind jeweils 0.4, für den Aufwand 0.2. Die Gewichtung der Konsequenzen ist in Abb. 8 dargestellt. Da bei der Alternative zur Implementierung nativer Datenbanktreiber keine Wahrscheinlichkeiten zu berücksichtigen sind, beträgt der Gesamtwert 0.8. Native Datenbanktreiber Alternative Portabilität / Performance / Aufwand 40% 100% 0 / 0 / 1 0 / 0.5 / 0 1 / 1 / 0 Abb. 8: Gewichtung der Konsequenzen 0.0 / 0.0 / / 0.2 / / 0.4 / 0.0 Im letzten Bewertungsschritt wird der Erwartungswert bei Alternativen mit optimistischen und pessimistischen Implementierungsvarianten ermittelt. Das ist der Mittelwert, der mit dem Einsatz der Alternative erwartet werden kann. Zur Berechung werden die normalisierten und gewichteten Konsequenzen mit den entsprechenden Wahrscheinlichkeiten multipliziert. Dies ergibt in der Summe den Erwartungswert der Alternative. Für die Alternative ist der Erwartungswert 0.2. Unter einer rationalen Betrachtung sollte sich der Entwickler für die Alternative mit dem höchsten Wert entscheiden. Das ist jene Alternative, die er unter rationalen Gesichtspunkten am stärksten präferiert. Im Falle der Typo3-Architekturveränderung präferiert der Entwickler mit einem Wert von 0.8 eindeutig die Alternative zur Implementierung nativer Datenbanktreiber. 4. Zusammenfassung und Fazit In den vorangegangenen Kapiteln wurde ein rationaler Entscheidungsprozess für die Architekturentwicklung vorgestellt. Entsprechend dem Konzept der präskriptiven Entscheidungstheorie erfolgt zum einen eine widerspruchsfreie Strukturierung der Ziele und Rahmenbedingungen sowie die Beschreibung aller relevanten Komponenten der Architektur. Zum anderen wird eine systematische Vorauswahl und Konkretisierung sowie eine rationale Bewertung der Alternativen durchgeführt. Durch die Komplexitätsreduzierung und das objektive Vorgehen werden Entscheidungen auf Basis riskanter und zu optimistischer Erwartungen vermieden. Bei der Typo3-Architekturveränderung konnten z.b. die Schwachpunkte die Alternative objektiv begründet werden. Die Ausführungen zeigen, dass für die systematische Entwicklung der Architekturqualität eine rationale Entscheidungsfindung sinnvoll ist. Bei der Entscheidung ist zu beachten, dass kurzfristige Entscheidungen im Vergleich zu Langfristigen nicht pauschal negativ beurteilt werden. Der Entscheidungsträger muss zwischen Risiko und dem Return-on-Invest abwägen. Erfahrungen aus der Praxis zeigen, dass die langfristige Option nicht immer die Bessere ist. Die Anwendung des Entscheidungsprozesses ist mit zusätzlichem Analyseaufwand verbunden. Dieser ist jedoch gerade bei der Entwicklung der Architektur geschäftskritischer Softwaresysteme gerechtfertigt. Die Erfahrungen aus der Praxis zeigen, dass der Mehraufwand zur Korrektur von Fehlentscheidungen den zusätzlichen Analyseaufwand um ein Vielfaches übersteigt. 5. Literaturverzeichnis [1] F. Eisenführ und M. Weber, Rationales Entscheiden, Springer, Berlin u.a., [2] E. Forman und M.A. Selly, Decision By Objectives, World Scientific Publishing Company, Washington, [3] S. Wohlfarth und M. Riebisch, "Evaluating Alternatives for Architecture-Oriented Refactoring", Proceedings of Conference on the Engineering of Computer Based Systems, IEEE Press, Los Alamitos (CA), 2006, S [4] M. Fowler, K. Beck und E. Gamma, Refactoring: Improving the design of existing code, Addison-Wesley, Boston, [5] K. Skrhj, "TYPO3 Core APIs", documentation/document-library/core-documentation/doc_core_ api/current/view/, Abruf: [6] R. Kazman, M. Klein und P. Clements, "ATAM: Method for Architecture Evaluation", documents/00.reports/pdf/00tr004.pdf, Abruf: [7] T. Posch, K Birken und M. Gerdom, Basiswissen Softwarearchitektur Verstehen, entwerfen, bewerten und dokumentieren, dpunkt.verlag, Heidelberg, [8] D. Garlan, T. Monroe und D. Wile, "Acme: Architectural Description of Component-Based Systems", Proceedings of CASCON`97, [9] G. Booch, J. Rumbaugh und I. Jacobson, Das UML Benutzerhandbuch, Addison-Wesley, München u.a., [10] E.M. Dashofy, A. v.d. Hoek und R.N. Taylor, "A Highly- Extensible, XML-Based Architecture Description Language", Proceedings of the Conference on Software Architectures, [11] J. Bosch, Design & Use of Software Architectures: Adopting and evolving a product line approach, Addison-Wesley, Harlow, [12] J. Lim, "ADOdb Database Abstraction Library for PHP ( )", Abruf: [13] A. Eisenberg und J Melton, "SQL standardization: the next steps", ACM SIGMOD Record - Volume 29 - Issue 1 (März 2000), S [14] R.S. Pressman, Software engineering: a practitioner's approach, McGraw Hill, Boston (Mass), [15] Peter C. Fishburn, "Methods of Estimating Additive Utilities", Management Science - Vol No. 7 - Series A, Sciences (1967), S

Entwicklung eines rationalen Entscheidungsprozesses für Architekturentscheidungen

Entwicklung eines rationalen Entscheidungsprozesses für Architekturentscheidungen Entwicklung eines rationalen Entscheidungsprozesses für Architekturentscheidungen Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) vorgelegt an der Fakultät für Informatik

Mehr

Review und Analyse von Softwarearchitekturen

Review und Analyse von Softwarearchitekturen Review und Analyse von Softwarearchitekturen Vorgehensweisen und Werkzeuge Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Sommersemester 2015 Übersicht Architekturreview

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Kapitel 1 Applikations-Architektur V

Kapitel 1 Applikations-Architektur V Kapitel 1 Applikations-Architektur V Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile und

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Inhaltsverzeichnis. xiii

Inhaltsverzeichnis. xiii Inhaltsverzeichnis 1 Einleitung... 1 1.1 Ausgangslage und Zielsetzung des Buches...2 1.2 Was ist Software-Architektur?...8 1.3 Leser-Leitfaden... 11 1.3.1 Buchaufbau... 11 1.3.2 Zielpublikum... 15 1.3.3

Mehr

Kapitel 1 Applikations-Architektur VI

Kapitel 1 Applikations-Architektur VI Kapitel 1 Applikations-Architektur VI Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

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

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

Mehr

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

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

Mehr

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

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

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Aufbau und Pflege von Internetseiten leicht gemacht

Aufbau und Pflege von Internetseiten leicht gemacht Aufbau und Pflege von Internetseiten leicht gemacht Einführung in die Grundlagen der CMS (Content Management Systeme) Was ist ein CMS? frei übersetzt: Inhaltsverwaltungssystem ist ein System, das die gemeinschaftliche

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

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

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec

Abschlussvortrag Masterarbeit: Operationalizing Architecture in an agile Software Projec Abschlussvortrag Masterarbeit: Operationalizing in an agile Software Projec Freie Universität Berlin, Institut für Informatik February 2, 2015 Übersicht 2 Was ist Softwarearchitektur? Softwarearchitektur

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

ERP-Systemeinsatz bewerten und optimieren

ERP-Systemeinsatz bewerten und optimieren ERP-Systemeinsatz bewerten und optimieren Handlungsfelder zur Optimierung des ERP-Systemeinsatzes ERP-Lösungen werden meist über viele Jahre lang eingesetzt, um die Geschäftsprozesse softwaretechnisch

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

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

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Problemlösungstechniken Systematisch analysieren & sicher entscheiden

Problemlösungstechniken Systematisch analysieren & sicher entscheiden Problemlösungstechniken Systematisch analysieren & sicher entscheiden Vancore Group GmbH & Co. KG Frankfurt Talstrasse 23 60437 Frankfurt am Main Germany Tel.: +49 (0) 69 509 299 790 Fax: +49 (0) 69 509

Mehr

Experten-Review für Ihre Microsoft SharePoint-Architektur. Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm

Experten-Review für Ihre Microsoft SharePoint-Architektur. Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm Experten-Review für Ihre Microsoft SharePoint-Architektur Maximaler Nutzen, hohe Stabilität und Sicherheit für Ihre SharePoint-Farm Heben Sie mit Materna die Potenziale Ihrer SharePoint-Umgebung. Microsoft

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Scenario-Based Analysis of Software Architecture

Scenario-Based Analysis of Software Architecture Scenario-Based Analysis of Software Architecture Rick Kazman et al. Sebastian Schaner, HS Furtwangen, 18.06.09 Agenda Vorstellung der Autoren - Weitere Veröffentlichungen Beitragsinhalt - Kernaussagen

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Homepage mit einem WCMS: Typo3

Homepage mit einem WCMS: Typo3 Homepage mit einem WCMS: Typo3 Universität Zürich Institut für Mathematik Ziele Das Institut möchte sich anspruchsvoll darstellen. Daten (Vorlesungen/ Seminare/ Publikationen) sollen aktuell sein und durch

Mehr

GEDS Dienstleistungen. Software Engineering

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

Mehr

Checkliste zur qualitativen Nutzenbewertung

Checkliste zur qualitativen Nutzenbewertung Checkliste zur qualitativen Nutzenbewertung Herausgeber Pentadoc Consulting AG Messeturm Friedrich-Ebert-Anlage 49 60308 Frankfurt am Main Tel +49 (0)69 509 56-54 07 Fax +49 (0)69 509 56-55 73 E-Mail info@pentadoc.com

Mehr

TYPO3 Slide 1 www.lightwerk.com 2005 Lightwerk GmbH

TYPO3 Slide 1 www.lightwerk.com 2005 Lightwerk GmbH TYPO3 Slide 1 Inhaltsverzeichnis Was ist ein CMS Was ist TYPO3 Editier-Möglichkeiten / Frontend-Editieren Slide 2 Was ist ein CMS (WCMS) Ein Web Content Management System (WCMS) ist ein Content-Management-System,

Mehr

Agile Programmierung - Theorie II SCRUM

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

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung

Mehr

(Titel des Berichts)

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

Mehr

Requirements Engineering im SPL-Umfeld

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

Mehr

CIB DOXIMA PRODUKTINFORMATION

CIB DOXIMA PRODUKTINFORMATION > CIB Marketing CIB DOXIMA PRODUKTINFORMATION Dokumentenmanagement & Dokumentenarchivierung > Stand: Februar 2012 THE NEXT GENERATION DMS Mit neuen Ideen, innovativen Lösungen und dem Produkt CIB doxima

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

Softwarepraktikum. Gernot A. Fink SS 2005 Softwarepraktikum Gernot A. Fink SS 2005 Einführung Wichtige Grundbegriffe Was ist Softwareengineering? Software- und Projektentwicklung Anfordernugen and Softwareentwicklung Softwareprozesse und Vorgehensmodelle

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Einbezug von Nutzungsversprechen und Requirements Engineering in die Entwicklung von AAL-Systemen

Einbezug von Nutzungsversprechen und Requirements Engineering in die Entwicklung von AAL-Systemen Einbezug von Nutzungsversprechen und Requirements Engineering in die Entwicklung von AAL-Systemen 4. AAL-Kongress Berlin, 25. 26. Januar 2011 Alexander Rachmann, Hochschule Niederrhein Dr. Irene Maucher,

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

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

Mehr

Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem

Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem Inhalt Content Management (CM) Allgemeines über CMS CMS Typen Open Source vs. Lizenzsoftware Joomla! Quellen Content Management

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

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

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

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen

Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen Bedeutung von Interoperabilität und Standards in Grid Infrastrukturen LMU SS 2012 Grid Computing Morris Riedel Federated Systems and Data Jülich Supercomputing Centre Forschungszentrum Jülich m.riedel@fz-juelich.de

Mehr

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System Fortgeschrittenenpraktikum bei Prof. Dr. Martin Wirsing vorgelegt von:

Mehr

// Mehr, als Sie erwarten //

// Mehr, als Sie erwarten // // Mehr, als Sie erwarten // // Unitek entwickelt seit 1988 innovative Software, mitten in der Altstadt von Zürich. Gegründet von ETH-Absolventen, hat Unitek dank massvollem Wachstum, anhaltender Begeisterung

Mehr

Code-Quality-Management

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

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Gemeinsam mehr erreichen.

Gemeinsam mehr erreichen. Gemeinsam mehr erreichen. Microservices in der Oracle SOA Suite Baden 10. September 2015 Ihr Ansprechpartner Carsten Wiesbaum Principal Consultant carsten.wiesbaum@esentri.com @CWiesbaum Schwerpunkte:

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

Requirements Engineering

Requirements Engineering Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

Mehr

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV 1 Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg Dr. Harald Bayer Innenministerium BW, StaV 2 Zum Redner Mitarbeiter der Stabsstelle für Verwaltungsreform (StaV) des Innenministeriums

Mehr

BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND. AIT GmbH & Co. KG Ihr Software effizienter entwickelt.

BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND. AIT GmbH & Co. KG Ihr Software effizienter entwickelt. BESSER SPÄT ALS FRÜH ARCHITEKTURENTSCHEIDUNGEN AUF DEM PRÜFSTAND AIT GmbH & Co. KG Ihr Software effizienter entwickelt. AGENDA Problemstellung Architekturmuster vs. Designmuster MVVM Das Wesentliche Fazit

Mehr

3. VisitorsDB Fokustreffen

3. VisitorsDB Fokustreffen 3. VisitorsDB Fokustreffen Max Planck Institut für Physik Komplexer Systeme Agenda: Auswertung zur Nutzerfunktionalität (10min) Potenziale des neuen Frameworks (10min) Erkenntnisse aus dem Softwareentwicklungsprozeß

Mehr

Integrating Architecture Apps for the Enterprise

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

Mehr

Das Redaktionssystem UCMS. Beschreibung Technisches Profil

Das Redaktionssystem UCMS. Beschreibung Technisches Profil 1/6 CONTENTMANAGEMENTSYSTEM UCMS 03.12.08 Das Redaktionssystem UCMS Beschreibung Technisches Profil Das vorliegende Dokument gibt einen Überblick über das System und geht auf die Ankopplung oder Integration

Mehr

Abschlussarbeiten 2010 in der Medizininformatik

Abschlussarbeiten 2010 in der Medizininformatik Abschlussarbeiten 2010 in der Medizininformatik Ansprechpartner: Prof. Dr. Eberhard Beck eberhard.beck@fh-brandenburg.de FACHHOCHSCHULE BRANDENBURG FACHBEREICH INFORMATIK UND MEDIEN Konzeption und prototypische

Mehr

Model Driven Architecture Praxisbeispiel

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

Mehr

Die Windows Workflow Foundation in Microsoft.NET 3.0

Die Windows Workflow Foundation in Microsoft.NET 3.0 Die Windows Workflow Foundation in Microsoft.NET 3.0 Klaus Rohe (klrohe@microsoft.com) Developer Platform & Strategy Group Microsoft Deutschland GmbH Agenda Was ist Windows Workflow Foundation? Microsoft

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

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

Mehr

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

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

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

PQ4Agile Agiler Referenzprozess

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

Mehr

VLADISLAVA ARABADZHIEVA

VLADISLAVA ARABADZHIEVA VLADISLAVA ARABADZHIEVA Bachelor of Science Informatik Geburtsjahr 1987 Profil-Stand August 2015 Triona Information und Technologie GmbH Wilhelm-Theodor-Römheld-Str. 14 55130 Mainz Fon +49 (0) 61 31 9

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Kurzübersicht Unified Process und Agile Prozesse

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

Mehr

Quality Point München

Quality Point München Quality Point München Test webbasierter Applikationen - Vorgehen, Instrumente, Probleme Gestern habe ich mich wieder über eine fehlerhafte Webanwendung geärgert. Muss das sein? Test ist halt auch hier

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

Mehr

Softwaretechnik (Medieninformatik) Überblick

Softwaretechnik (Medieninformatik) Überblick Softwaretechnik (Medieninformatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 Überblick UML-Diagramme

Mehr

inxire Enterprise Content Management White Paper

inxire Enterprise Content Management White Paper inxire Enterprise Content Management White Paper inxire Enterprise Content Management Einleitung Die Informationstechnologie spielt eine zentrale Rolle für den Informationsaustausch und die Zusammenarbeit

Mehr

User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien

User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien Natascha Andres Forschungsgruppe Geriatrie, Charité, Universitätsmedizin Berlin Agenda Thematischer Hintergrund

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte Stefan Toth Befehl von unten: Softwarearchitektur für dynamische Projekte [ ] Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Qualität ist nicht (nur) die Abwesenheit von Fehlern. Jede Aussage über Qualität ist eine Aussage von einer oder mehrere Personen.

Qualität ist nicht (nur) die Abwesenheit von Fehlern. Jede Aussage über Qualität ist eine Aussage von einer oder mehrere Personen. Beobachtungen Qualität ist nicht (nur) die Abwesenheit von Fehlern Qualität ist relativ Qualität ist die "Erfüllung der Anforderungen Qualität ist die "Erfüllung der Anforderungen einer Person Jede Aussage

Mehr