Praxis der Forschung SS15/Architecture-based Assessment and Planning of Change Requests

Aus SDQ-Wiki

BibTeX Eintrag

@inproceedings{rostami2015a,
	Address = {Montreal, QC, Canada},
	Author = {Kiana Rostami AND Johannes Stammel AND Robert Heinrich AND Ralf Reussner},
	Booktitle = {Proceedings of the 11th International ACM SIGSOFT Conference on the Quality of Software Architectures (QoSA'15)},
	Doi = {10.1145/2737182.2737198},
	Publisher = {ACM},
	Series = {QoSA'15},
	Title = {{A}rchitecture-based {A}ssessment and {P}lanning of {C}hange {R}equests},
	Year = {2015},
}

Abstract

Software architecture reflects important decisions on structure, used technology and resources. Architecture decisions influence to a large extent requirements on software quality. During software evolution change requests have to be implemented in a way that the software maintains its quality, as various potential implementations of a specific change request influence the quality properties differently. Software development processes involve various organisational and technical roles. Thus, for sound decision making it is important to understand the consequences of the decisions on the various software engineering artefacts (e.g. architecture, code, test cases, build, or deployments) when analysing the impact of a change request. However, existing approaches do not use sufficient architecture descriptions or are limited to software development without taking management tasks into account. In this paper, we present the tool-supported approach Karlsruhe Architectural Maintainability Prediction (KAMP) to analyse the change propagation caused by a change request in a software system based on the architecture model. Using context information annotated on the architecture KAMP enables project members to assess the effects of a change request on various technical and organisational artefacts and tasks during software life cycle. We evaluate KAMP in an empirical study, which showed that it improves scalability of analysis for information systems due to automatically generated task lists containing more complete and precise context annotations than manually created ones.

Eigene Zusammenfassung

  • stellt als Beispiel ein Usermanagagementsystem vor, betrachteter Change ist eine Datentyperweiterung
  • stellt KAMP vor
  • formalisiert KAMP
  • related work:
    • Task-basierte Projektplanung
      • Hierarchical Task Analysis (HTA); Goals, Operators, Methods and Selextion rules model (GOMS), Keystroke level method, Function Point Analysis, COCOMO II
      • die Softwarearchitektur wird, wenn überhaupt, bei diesen Ansätzen nur oberflächlich genutzt, was akkurate Vorhersagen erschwert
    • Architekturbasierte Projektplanung
      • Architecture- Centered Software Project Planning (ACSPP), Kombination aus Top-down und Bottom-up Aufwandsschätzungen, Softwarearchitektur als Artefakt der Projektplanung
      • Carbon, Synchronisation von Produktplanung / -design und Produktionsplanung im Softwareentwicklungskontext, erlaubt frühzeitige Problemerkennung und Vollständigkeitsprüfung der Architektur
      • keine Unterstützung für Aufwandsschätzungen basierend auf einer Architektur
      • keine Automatisierte Change Impact Analyse und Ableitung von Aufgaben
    • Architecture-based Software Evolution
      • keine Unterstützung für Änderungsaufwandsschätzungen und automatisierte Change Impact Analyse
    • Scenario-based Architecture Analysis
  • Evaluation
    • 3 Testgruppen: unerfahrene Nutzer mit KAMP (TG), unerfahrene Nutzer ohne KAMP (CG), erfahrene Nutzer ohne KAMP
    • arbeiten am beschriebenen Beispiel
    • 2 Metriken:
      • Vollständigkeit und Präzision der Aufgabenlisten im Vergleich TG zu CG (Erwartung TG >= CG) im Hinblick auf
        • Aufgabentypen
        • Aufgabenannotationen
      • Vollständigkeit und Präzision der Aufgabenlisten im Vergleich TG bzw. CG zu EXG (Erwartung TG >= CG) im Hinblick auf
        • Aufgabentypen
        • Aufgabenannotationen
    • setzen 4 Change Requests um
      1. Erweiterung von Datentyp um zusätzliches Feld
      2. Parametererweiterung einer von einem Interface definierten Methode
      3. Datenformatänderung eines Rest Interfaces von XML zu JSON
      4. Ersetzung von Hibernate durch eigenentwickletes ORM Framework
    • Ergebnisse
      • Erwartungsgemäß hat die Kontrollgruppe bessere Metriken erzielt

Notizen

Verweise

Abgerufen von „https://sdq.kastel.kit.edu/mediawiki-sdq-extern/index.php?title=Praxis_der_Forschung_SS15/Architecture-based_Assessment_and_Planning_of_Change_Requests&oldid=23506“