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

Systematische Berücksichtigung von Abhängigkeitsbeziehungen bei Architekturentscheidungen

Systematische Berücksichtigung von Abhängigkeitsbeziehungen bei Architekturentscheidungen Systematische Berücksichtigung von Abhängigkeitsbeziehungen bei Architekturentscheidungen Sven Wohlfarth, Matthias Riebisch TU Ilmenau, FG Prozessinformatik/Softwaresysteme, 98693 Ilmenau {sven.wohlfarth

Mehr

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

Mehr

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010 Architekturentscheidungen für große langlebige Softwaresysteme: Vendor-Lock-in- und Netz-Effekte Menschen beraten Menschen beraten BTC zeigt Wege auf - Sie entscheiden BTC zeigt Wege auf - Sie entscheiden

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

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

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

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

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

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

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

CIB DOXIMA PRODUKTINFORMATION

CIB DOXIMA PRODUKTINFORMATION > CIB Marketing CIB DOXIMA PRODUKTINFORMATION Dokumentenmanagement & Dokumentenarchivierung > Stand: Januar 2013 INHALT 1 CIB DOXIMA 2 1.1 The next generation DMS 3 1.2 Dokumente erfassen Abläufe optimieren

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

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

Software vergleichen. Andrea Herrmann AndreaHerrmann3@gmx.de. 25.11.2011 Fachgruppentreffen RE

Software vergleichen. Andrea Herrmann AndreaHerrmann3@gmx.de. 25.11.2011 Fachgruppentreffen RE Software vergleichen Andrea Herrmann AndreaHerrmann3@gmx.de 25.11.2011 Fachgruppentreffen RE Übersicht 1. Motivation 2. Stand der Forschung 3. Gap-Analyse versus Delta-Analyse 4. Grafischer Vergleich 5.

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

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

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter 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 Buchhandel.

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

Reengineering und Refactoring von Softwarearchitekturen

Reengineering und Refactoring von Softwarearchitekturen Methodische und Praktische Grundlagen der Informatik 3 Reengineering und Refactoring von Softwarearchitekturen Steffen Helke Technische Universität Berlin Fachgebiet Softwaretechnik WS 2008/2009 Lernziele?

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

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

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

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 1) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Besonderheiten und Eigenschaften von Software; Interne und Externe Eigenschaften 1 Aufgabe 1.1 Software

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

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

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

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

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

Informationssystemanalyse Use Cases 11 1

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

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

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

Mehr

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level Mahbouba Gharbi Arne Koschel Andreas Rausch Gernot Starke Basiswissen für Softwarearchitekten Aus- und Weiterbildung nach isaqb-standard zum Certified Professional for Software Architecture - Foundation

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

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

Praxisgerechte Validierung von Sicherheitsapplikationen

Praxisgerechte Validierung von Sicherheitsapplikationen Praxisgerechte Validierung von Sicherheitsapplikationen Dr. Michael Huelke, FB Unfallverhütung Produktsicherheit, BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung, Sankt Augustin

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1

vii Inhaltsverzeichnis 1 Einleitung 1 vii 1 Einleitung 1 1.1 Softwarearchitektur als Disziplin im Software Engineering........ 2 1.2 isaqb International Software Architecture Qualification Board.......... 4 1.3 Certified Professional for Software

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

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

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

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 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Die Softwareentwicklungsphasen!

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

Mehr

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

Softwarearchitektur und Qualitätsszenarien

Softwarearchitektur und Qualitätsszenarien Softwarearchitektur und Qualitätsszenarien Mechanismen, um Qualitätsmerkmale zu erreichen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Sommersemester 2015 Übersicht

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

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung

Verwertung und Wirtschaftlichkeit. Projektmanagement. Konzeptentwicklung. Technologische/Technische Klärung Zielsetzung und Einsatz: Die Checkliste dient als Hilfsmittel für die Gestaltung und Umsetzung einer Voruntersuchung. Die hier vorliegende ist auf die Abwicklung vergleichsweise komplexer Voruntersuchungen

Mehr

Software-Architektur. Spektrum k_/takademischht VERLAG

Software-Architektur. Spektrum k_/takademischht VERLAG Oliver Vogel / Ingo Arnold /Arif Chughtai / Edmund Ihler/Uwe Mehlig/Thomas Neumann/ Markus Völter/Uwe Zdun Software-Architektur Grundlagen - Konzepte - Praxis ELSEVIER SPEKTRUM AKADEMISCHER VERLAG Spektrum

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

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

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

Software-Evolution im Staged Lifecycle Model

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

Mehr

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

Workshop TYPO3-Extensions

Workshop TYPO3-Extensions Leibniz Universität IT Services Workshop TYPO3-Extensions Was sind TYPO3-Extensions Wo kommen sie her Wie werden sie eingesetzt und genutzt Welche Extensions gibt es im TYPO3@RRZN-Webservice Auswahlkriterien

Mehr

Anforderungen: Management

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

Mehr

Online Analytical Processing

Online Analytical Processing Online Analytical Processing Online Analytical Processing Online Analytical Processing (OLAP) ermöglicht die multidimensionale Betrachtung von Daten zwecks E rmittlung eines entscheidungsunterstützenden

Mehr

Software Projekt 2 / Gruppe Knauth Lernziele:

Software Projekt 2 / Gruppe Knauth Lernziele: Lernziele: Realisierung eines komplexen Software-Projektes unter Industrie-ähnlichen Bedingungen Organisiertes Arbeiten im Team Team Organisation: Rollen und Aufgaben der Team-Mitglieder bestimmen Spezifikation

Mehr

OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten

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

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

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

Softwareanforderungsanalyse

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

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Inhalt. TEIL I Grundlagen. 1 SAP HANA im Überblick... 31. 2 Einführung in die Entwicklungsumgebung... 75

Inhalt. TEIL I Grundlagen. 1 SAP HANA im Überblick... 31. 2 Einführung in die Entwicklungsumgebung... 75 Geleitwort... 15 Vorwort... 17 Einleitung... 19 TEIL I Grundlagen 1 SAP HANA im Überblick... 31 1.1 Softwarekomponenten von SAP HANA... 32 1.1.1 SAP HANA Database... 32 1.1.2 SAP HANA Studio... 34 1.1.3

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Software Product Line Engineering

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

Mehr

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

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

Mehr

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

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

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

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

Governance, Risk & Compliance für den Mittelstand

Governance, Risk & Compliance für den Mittelstand Governance, Risk & Compliance für den Mittelstand Die Bedeutung von Steuerungs- und Kontrollsystemen nimmt auch für Unternehmen aus dem Mittelstand ständig zu. Der Aufwand für eine effiziente und effektive

Mehr

Der Rational Unified Process

Der Rational Unified Process Philippe Kruchten Der Rational Unified Process Eine Einführung Deutsche Übersetzung von Cornelia Versteegen An imprint of Pearson Education München Reading, Massachusetts Menlo Park, California New York

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Software Engineering und Projektmanagement

Software Engineering und Projektmanagement Software Engineering und Projektmanagement Motivation! Fachliche Sicht trifft auf technische Realisierung Entwurf 2009W - 5. November 2009 Andreas Mauczka Email: andreas.mauczka@inso.tuwien.ac.at Web:

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

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

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

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

Mehr

Oracle White Paper März 2009. Realitätsnahere Prognosen: Getrennte Beurteilung von Chancen und Risiken sowie Unsicherheit

Oracle White Paper März 2009. Realitätsnahere Prognosen: Getrennte Beurteilung von Chancen und Risiken sowie Unsicherheit Oracle White Paper März 2009 Realitätsnahere Prognosen: Getrennte Beurteilung von Chancen und Risiken sowie Unsicherheit Executive Summary In diesem White Paper werden anhand eines Beispiels die Vorteile

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

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

Modes And Effect Analysis)

Modes And Effect Analysis) Gefahrenanalyse mittels FMEA (Failure Modes And Effect Analysis) Vortragender: Holger Sinnerbrink Betreuer: Holger Giese Gefahrenanalyse mittels FMEA Holger Sinnerbrink Seite: 1 Gliederung Motivation Einordnung

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

TYPO3 CMS 6.2 LTS. Die neue TYPO3- Version mit Langzeit- Support

TYPO3 CMS 6.2 LTS. Die neue TYPO3- Version mit Langzeit- Support Die neue TYPO3- Version mit Langzeit- Support Am 25. März 2014 wurde mit die zweite TYPO3- Version mit Langzeit- Support (Long- Term- Support, kurz: LTS) veröffentlicht. LTS- Versionen werden drei Jahre

Mehr

Das Open Source Content Management System

Das Open Source Content Management System Das Open Source Content Management System Erweiterbarkeit und Individualisierung visions-marketing Unternehmensberatung Alexander Winkler Postfach 950180 81517 München Tel.+Fax: 089 / 38 90 06 53 Mobil.:

Mehr

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement

Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Entwurfsmethode für service-orientierte Architekturen im dezentralen Energiemanagement Tanja Schmedes Betriebliches Informationsmanagement OFFIS Institut für Informatik tanja.schmedes@offis.de MKWI 2008

Mehr

Projektmanagement iterativer Projekte

Projektmanagement iterativer Projekte Übersicht Motivation zum iterativen Vorgehen Anleitung zur U Ca getriebenen Vorgehenswei Praktische Tipps Zusammenfassung Projektmanagement iterativer Rainer Schmidberger Universität Stuttgart Institut

Mehr

Produktphilosophie erstellen

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

Mehr

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

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

Verteidigung Masterarbeit Evaluating the Use of a Web Browser to Unify GUI Development for IDE Plug-ins

Verteidigung Masterarbeit Evaluating the Use of a Web Browser to Unify GUI Development for IDE Plug-ins Verteidigung Masterarbeit Evaluating the Use of a Web Browser to Unify GUI Development for IDE Plug-ins Christian Cikryt Freie Universität Berlin 13.08.2015 Überblick Motivation und Ziele Evaluation des

Mehr

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

ISO 9001:2015 und Risikomanagement ISO/DIS 9001 (E) 08/2014

ISO 9001:2015 und Risikomanagement ISO/DIS 9001 (E) 08/2014 ISO 9001:2015 und Risikomanagement ISO/DIS 9001 (E) 08/2014 Übersicht 1. Risikomanagement - Hintergrund 2. Risikomanagement ISO 9001: 2015 3. Risikomanagement Herangehensweise 4. Risikomanagement Praxisbeispiel

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

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

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

Mehr

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster

Mehr

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik

Mehr

Stellungnahme der Bundespsychotherapeutenkammer 11.04.2014

Stellungnahme der Bundespsychotherapeutenkammer 11.04.2014 Richtlinie des Gemeinsamen Bundesausschusses zur Regelung von Anforderungen an die Ausgestaltung von strukturierten Behandlungsprogrammen nach 137f Absatz 2 SGB V (DMP-Richtlinie/DMP-RL) und zur Zusammenführung

Mehr