BibTeX Eintrag

@inproceedings{stammel09a,
	Abstract = {In their lifetime software systems usually need to be adapted in order
	to fit in a changing environment or to cover new required functionality.
	The effort necessary for implementing changes is related to the maintainability
	of the software system. Therefore, maintainability is an important
	quality aspect of software systems. Today Software Architecture plays
	an important role in achieving software quality goals. Therefore,
	it is useful to evaluate software architectures regarding their impact
	on the quality of the program. However, unlike other quality attributes,
	such as performance or reliability, there is relatively less work
	on the impact of the software architecture on maintainability in
	a quantitative manner. In particular, the cost of software evolution
	not only stems from software-development activities, such as reimplementation,
	but also from software management activities, such as re-deployment,
	upgrade installation, etc. Most metrics for software maintainability
	base on code of object-oriented designs, but not on architectures,
	and do not consider costs from software management activities. Likewise,
	existing current architectural maintainability evaluation techniques
	manually yield just qualitative (and often subjective) results and
	also do concentrate on software (re-)development costs. In this paper,
	we present KAMP, the Karlsruhe Architectural Maintainability Prediction
	Method, a quantitative approach to evaluate the maintainability of
	software architectures. Our approach estimates the costs of change
	requests for a given architecture and takes into account re-implementation
	costs as well as re-deployment and upgrade activities. We combine
	several strengths of existing approaches. First, our method evaluates
	maintainability for concrete change requests and makes use of explicit
	architecture models. Second, it estimates change efforts using semi-automatic
	derivation of work plans, bottom-up effort estimation, and guidance
	in investigation of estimation supports (e.g. design and code properties,
	team organization, development environment, and other influence factors).},
	Author = {Stammel, Johannes and Reussner, Ralf},
	Booktitle = {Proceedings of the 1. Workshop des GI-Arbeitskreises Langlebige Softwaresysteme (L2S2): "Design for Future - Langlebige Softwaresysteme"},
	Editor = {Engels, Gregor and Reussner, Ralf and Momm, Christof and Sauer, Stefan},
	Pages = {87-98},
	Title = {KAMP: Karlsruhe Architectural Maintainability Prediction},
	Url = {http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-537/},
	Year = {2009},
	Bdsk-Url-1 = {http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-537/}}

Abstract

In their lifetime software systems usually need to be adapted in order to fit in a changing environment or to cover new required functionality. The effort necessary for implementing changes is related to the maintainability of the software system. Therefore, maintainability is an important quality aspect of software systems. Today Software Architecture plays an important role in achieving software quality goals. Therefore, it is useful to evaluate software architectures regarding their impact on the quality of the program. However, unlike other quality attributes, such as performance or reliability, there is relatively less work on the impact of the software architecture on maintainability in a quantitative manner. In particular, the cost of software evolution not only stems from software-development activities, such as reimplementation, but also from software management activities, such as re-deployment, upgrade installation, etc. Most metrics for software maintainability base on code of object-oriented designs, but not on architectures, and do not consider costs from software management activities. Likewise, existing current architectural maintainability evaluation techniques manually yield just qualitative (and often subjective) results and also do concentrate on software (re-)development costs. In this paper, we present KAMP, the Karlsruhe Architectural Maintainability Prediction Method, a quantitative approach to evaluate the maintainability of software architectures. Our approach estimates the costs of change requests for a given architecture and takes into account re-implementation costs as well as re-deployment and upgrade activities. We combine several strengths of existing approaches. First, our method evaluates maintainability for concrete change requests and makes use of explicit architecture models. Second, it estimates change efforts using semi-automatic derivation of work plans, bottom-up effort estimation, and guidance in investigation of estimation supports (e.g. design and code properties, team organization, development environment, and other influence factors).

Eigene Zusammenfassung

definiert Wartbarkeit auf Basis der ISO/IEC 9126- 1:2001(E):
"The capability of a software product to be modified. Modifications may include corrections, improvements or adaptation of the software to changes in environment, and in requirements and functional specification"
Vorstellung ähnlicher Ansätze:
- Szenario basierte Ansätze zur Qualitätsanalyse von Architekturen:
  - Software Architecture Analysis Method (SAAM)
    - nutzt informelles Architekturmodell
    - beginnt mit dem Sammeln von möglichen Änderungsszenarien mit betroffenen Komponenten und geschätzten Kosten
    - von vielen Änderungen betroffene Komponenten werden als kritisch eingestuft
    - Endet mit einer Sammlung anhand Kosten bewerteter Änderungsszenarien und ggf. geänderter Architektur mit weniger kritischen Komponenten
  - Architecture Trade-Off Analysis Method (ATAM)
    - baut auf SAAM auf
    - erweitert um Qualitätsdimensionen und deren Relationen (vs. nur Änderbarkeit)
    - Schätzung erst hinsichtlich einer Dimension, dann Zusammenführung ("Sensitivity Analysis")
  - The Architecture-Level Prediction of Software Maintenance (ALPSM)
    - basiert auf repräsentiven Szenarios, gegliedert nach Typ (z.B. Fehlerbehebungen, Anpassungen)
    - gewichtet diese anhand der Eintrittswahrscheinlichkeit
    - berechnet Wartungsaufwand eines Szenarios anhand geschätzter Komponentengrößen (z.B. in LOC)
    - daraus Ableitung der gesamten Wartungskosten über die Laufzeit
  - The Architecture-Level Modifiability Analysis (ALMA)
    - Erweiterung von ALPSM
    - unterstützt zusätzlich zur Wartbarkeit, Risikoschätzung und Vergleich von Architekturalternativen
    - berücksichtigt Seiteneffekte durch Erfahrung des Verantwortlichen Architekten / Entwickler (durch Bottom-up Schätzung)
    - erlaubt prinzipiell komplexere Metriken
    - berücksichtigt keine Software-Management Tätigkeiten (Re-Deployment, Upgradeinstallation usw.)
- Top-down Ansätze zur Wartungsaufwandsschätzung:
  - Function Point Analysis (FPA)
  - Comprehensive Cost Model (COCOMO) II
    - 3 Ansätze: Anforderungsphase, frühe Architekturentwurfsphse, späte Entwurfsphase (nur erster Top-down)
  - erste Phase aus COCOMO II und FPA sind relativ vergleichbar
    - Funktionalität wird in abstrakten Function Points bzw. Application Points anhand informeller Anforderungen geschätzt
    - Der Gesamtaufwand wird anhand des Quotienten der Summe aller Function Points und der Produktivität des Entwicklungsteams geschätzt
    - COCOMO II Phase 1 berücksichtigt auch den Erwarteten Grad an Wiederverwendbarkeit
    - In späteren Phasen betrachtet COCOMO II auch weitere Informationen (z.B. den Anteil an generiertem Code, Stabilitätsanforderungen, Plattformkomplexität, etc.)
    - Architekturinformationen werden nur oberflächlich genutzt
    - Es werden historische Daten zur Kalibrierung benötigt
    - Es wird als schwer eingeschätzt, zutreffende Vorhersagen mit Top-down Techniken zu machen
- Bottom-up Ansätze zur Wartungsaufwandsschätzung:
  - Architecture-Centric Project Management (ACPM)
    - Nutzt Architektur für Planungs- und Managementaktivitäten, näher beschrieben ist die architekturbasierte Kostenschätzung
    - geplante Änderungen werden anhand der Architektur in architekturspezifische Teilaufgaben zerlegt
    - der durchführende Entwickler schätzt diese geführt von vordefinierten Formularen
    - Vorteile gegenüber Top-down Techniken:
      - Architekturinformationen werden genutzt
      - persönliche Produktivitätsfaktoren werden implizit berücksichtigt (durch Schätzung durch den Entwickler)
    - Differenzierung zu KAMP:
      - KAMP basiert auf formalisierten Eingaben (Metamodellen) um Toolsupport zu ermöglichen
      - ACPM nutzt nur die Struktursicht der Architektur und berücksichtigt nicht die Softwaremanagementkosten (Re-Deployment, Upgradeinstallation usw.)
ausführliche Vorstellung von KAMP

Notizen

Verweise

potentiell wichtig:
- ISO/IEC. Software Engineering - Product Quality - Part 1: Quality. ISO/IEC 9126- 1:2001(E), Dec 1990
- ISO/IEC IEEE. Systems and software engineering - Recommended practice for ar- chitectural description of software-intensive systems. ISO/IEC 42010 IEEE Std 1471- 2000 First edition 2007-07-15, pages c1–24, 15 2007.
- E. Dobrica, L.; Niemela. A survey on software architecture analysis methods. Trans- actions on Software Engineering, 28(7):638–653, Jul 2002.