Change decision support:extraction and analysis of late architecture changes using change characterization and software metrics

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. Giving software developers the information that they need to make quality decisions about changes that will negatively affect their software systems is a key aspect to mitigating those risks. This dissertation presents work performed to assist developers to collect and process data that plays a role in change decision-making during the maintenance phase. To address these problems, developers need a way to better understand the effects of a change prior to making the change. This research addresses the problems associated with increasing architectural complexity caused by software change using a twoold approach. The first approach is to characterize software changes to assess their architectural impact prior to their implementation. The second approach is to identify a set of architecture metrics that correlate to system quality and maintainability and to use these metrics to determine the level of difficulty involved in making a change. The two approaches have been combined and the results presented provide developers with a beneficial analysis framework that offers insight into the change process

Nutzen und Kosten von serviceorientierten Architekturen

Die vorliegende Forschungsarbeit liefert einen Beitrag zum Verständnis desArchitekturkonzeptes "serviceorientierte Architektur" (SOA). Durch die Forschungsarbeit wird erreicht, dass das Wissen bezüglich des Wirtschaftlichkeitspotentials einer SOA wesentlich erweitert und zusammenhängend dargestellt wird. Die innovativen Ergebnisse der Forschungsarbeit sind: Erstens wird eine allgemein tragfähige Definition einer SOA aufgestellt. Zweitens wird ein Qualitätsmodell hergeleitet, das zur Architekturbewertung geeignet ist. Dies erwies sich insbesondere deswegen als notwendig, weil bisherige Bewertungsmethoden aktuellen Ansprüchen nicht mehr gerecht werden oder auf die Bewertung spezifischer Situationen ausgerichtet sind. Drittens wird eine Bewertung des Wirtschaftlichkeitspotentials für SOA beispielhaft anhand der festgestellten Nutzen- und Kostenpotentiale vorgenommen. Weder die Praxis noch die Forschung konnten sich auf eine einheitliche Definition �SOA� festlegen. Bestrebungen um allgemein festzulegen, was unter eine SOA zu verstehen ist, wurden bisher nicht unternommen. Aus diesem Grund wird eine (Arbeits-) Definition aufgestellt, die diesem Anspruch gerecht werden kann: "Eine SOA ist ein Konzept für eine Softwarearchitektur, in dem Funktionen in Form von wiederverwendbaren, technisch voneinander unabhängigen und fachlich lose gekoppelten Services implementiert werden. Services können unabhängig von zugrunde liegenden Implementierungen über wohldefinierte und veröffentlichte Serviceschnittstellen aufgerufen werden. Serviceinteraktion findet über eine dafür vorgesehene Kommunikationsinfrastruktur statt. Mit einer SOA werden insbesondere die Gestaltungsziele der Geschäftsprozessorientierung, der Wandlungsfähigkeit, der Wiederverwendbarkeit und der Unterstützung verteilter Softwaresysteme verbunden." Ein Qualitätsmodell zur einheitlichen Bewertung einer Softwarearchitektur wird aufgestellt, das den Anforderungen zur Bewertung entsprechend den heute gestellten Anforderungen an eine Softwarearchitekturbewertung gerecht wird. Dazu zählen insbesondere Anforderungen bzgl. geschäftlicher Qualitätsattribute. Auch wird die Perspektive eines Qualitätsmodells erweitert: es wird erkannt, dass nicht nur die Perspektive von Softwareentwicklern, sondern auch die des Managements eines Unternehmens muß in eine Bewertung einfließen. Aus diesen Gründen wird auf Grundlage bestehender Forschungsergebnisse ein Qualitätsmodell abgeleitet, das die Qualitätsattribute Funktionserfüllung, Wandlungsfähigkeit, Benutzbarkeit, Verlässlichkeit, Effizienz, Wiederverwendbarkeit, Portabilität, Strategieunterstützung, Nachhaltigkeit und Integriertheit enthält. Zu diesen zehn Qualitätsattributen werden 32 Unterqualitätsattribute identifiziert. Um ein Wirtschaftlichkeitspotential aufstellen zu können, wird zunächst auf Grundlage des Qualitätsmodells eine Analyse des Nutzenpotentials einer �SOA� vorgenommen. Es wird festgestellt, dass eine allgemeine Bewertung einer SOA nur unter Unsicherheiten vorgenommen werden kann. Für konkrete Situationen lässt sich mittels des aufgestellten Qualitätsmodells eine spezifische Bewertung durchführen. Für die zehn Qualitätsattribute werden Bewertungen von �sehr negativ� bis �sehr positiv� und somit über die gesamte Skala vorgenommen. Die Bewertung �sehr negativ�, �negativ� und �positiv� werden jeweils einmal, �neutral� wird keinmal vergeben. Mit sieben Bewertungen von �sehr positiv� lässt sich eine klare Tendenz der positiven Bewertung des Nutzenpotentials feststellen. Anschließend wird das Kostenpotential einer SOA bewertet. Hier werden Kosten analysiert, die im Zusammenhang mit der Verwendung einer Unternehmens-IT entstehen. Für die Kosten der Infrastruktur, der Entwicklung und des Managements einer Unternehmens-IT, als auch für die Kosten des organisatorischen Wandels aufgrund des Einsatzes einer Unternehmens-IT, wird argumentiert, dass spezifische Kosten durch den Einsatz einer SOA entstehen. Mit Hilfe des argumentierten Nutzen- und Kostenpotentials wird ein Wirtschaftlichkeitspotential bzgl. der Kundenzufriedenheit, Mitarbeiterzufriedenheit, Wettbewerbssituation, der Beziehung zu Geschäftspartnern und interner Wirkungen aufgestellt. In diesem Bewertungsschritt wird dargestellt, wie eine Softwarearchitektur auf ein Unternehmen und das Ökosystem in dem es agiert, Einfluss ausübt. Mittels dieser getroffenen Argumentationen kann für eine spezifische Situation festgestellt werden, welche Auswirkungen eine SOA für das zugrunde gelegte Bewertungsumfeld aufweist