An Investigation of a Method for Identifying a Software Architecture Candidate with respect to Quality Attributes

To sustain the qualities of a software system during evolution, and to adapt the quality attributes as the requirements evolve, it is necessary to have a clear software architecture that is understood by all developers and to which all changes to the system adheres. This software architecture can be created beforehand, but must also be updated to reflect changes in the domain, and hence the requirements of the software. The choice of which software architecture to use is typically based on informal decisions. There exist, to the best of our knowledge, little factual knowledge of which quality attributes are supported or obstructed by different architecture approaches. In this paper, we present an empirical study of a method that enables quantification of the perceived support different software architectures give for different quality attributes. This in turn enables an informed decision of which architecture candidate best fit the mixture of quality attributes required by a system being designe

An Investigation of a Method for Identifying a Software Architecture Candidate with respect to Quality Attributes

To sustain the qualities of a software system during evolution, and to adapt the quality attributes as the requirements evolve, it is necessary to have a clear software architecture that is understood by all developers and to which all changes to the system adheres. This software architecture can be created beforehand, but must also be updated to reflect changes in the domain, and hence the requirements of the software. The choice of which software architecture to use is typically based on informal decisions. There exist, to the best of our knowledge, little factual knowledge of which quality attributes are supported or obstructed by different architecture approaches. In this paper, we present an empirical study of a method that enables quantification of the perceived support different software architectures give for different quality attributes. This in turn enables an informed decision of which architecture candidate best fit the mixture of quality attributes required by a system being designe

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

On the Viability of Quantitative Assessment Methods in Software Engineering and Software Services

IT help desk operations are expensive. Costs associated with IT operations present challenges to profit goals. Help desk managers need a way to plan staffing levels so that labor costs are minimized while problems are resolved efficiently. An incident prediction method is needed for planning staffing levels. The potential value of a solution to this problem is important to an IT service provider since software failures are inevitable and their timing is difficult to predict. In this research, a cost model for help desk operations is developed. The cost model relates predicted incidents to labor costs using real help desk data. Incidents are predicted using software reliability growth models. Cluster analysis is used to group products with similar help desk incident characteristics. Principal Components Analysis is used to determine one product per cluster for the prediction of incidents for all members of the cluster. Incident prediction accuracy is demonstrated using cluster representatives, and is done so successfully for all clusters with accuracy comparable to making predictions for each product in the portfolio. Linear regression is used with cost data for the resolution of incidents to relate incident predictions to help desk labor costs. Following a series of four pilot studies, the cost model is validated by successfully demonstrating cost prediction accuracy for one month prediction intervals over a 22 month period

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

Quality-driven Reuse of Model-based Software Architecture Elements

In software development, components are increasingly being reused, especially for the implementation of standard functionalities making software development more cost-efficient. At design time, however, it is often unclear which solution providing these functionalities fits the requirements of the software system. This work proposes a method and tool enabling software architects to automatically evaluate the effects on the quality attributes of software architectures when reusing features