Logo des Repositoriums

Softwaretechnik-Trends 29(2) - 2009

https://dl.gi.de/handle/20.500.12116/41256
Auflistung nach:

Auflistung Softwaretechnik-Trends 29(2) - 2009 nach Erscheinungsdatum

Zu einem Punkt im Index springen:
1 - 10 von 28
  • Zeitschriftenartikel
    Extending SOMA for Model-Driven Software Migration into SOA
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Fuhr, A.; Horn, T.; Winter, A.; Gimnich, R.
  • Zeitschriftenartikel
    Domain Knowledge Driven Program Analysis
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Ratiu, D.
  • Zeitschriftenartikel
    Reengineering mal ohne Softwareänderung – Verlagerung eines komplexen IT-Betriebs
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Borchers, Jens
  • Zeitschriftenartikel
    Reengineering (von & mit) Architekturen
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Simon, Frank; Gawlik, Kai-Uwe
    Architekturen stellen prinzipiell ein mächtiges Mittel zur Unterstützung von Reengineering-Aktivitäten dar. In der Praxis scheitert dies allerdings häufig, da Architekturen nicht präzise definiert und sich insbesondere im völlig qualitätssicherungsfreien Raum befinden. In diesem Papier werden diejenigen qualitätssichernden Maßnahmen beschrieben, die VOR dem Einsatz von Architekturen für ein Reengineering zwangsläufig notwendig sind, um Architekturen tatsächlich gewinnbringend für das Reengineering einsetzen zu können.
  • Zeitschriftenartikel
    Einsatz und Nutzen von Use Cases - Ergebnisse einer empirischen Untersuchung
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Weidmann, Christoph; Hoffmann, Veit; Lichter, Horst
  • Zeitschriftenartikel
    Werkzeugunterstützung für iterative Modernisierungsprozesse
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Vianden, Matthias; Berretz, Frank; Rötschke, Tobias
    In dieser Arbeit stellen wir unsere Überlegungen und Erfahrungen bei der Werkzeugunterstützung für iterative Modernisierungsprozesse von formularbasierten Informationssystemen vor. Nachdem wir die Anforderungen für ein Werkzeug skizzieren, stellen wir deren beispielhafte Implementierung im Werkzeug SOPTIM CQM vor. Der zweite Teil beschäftigt sich mit unseren Erfahrungen bei der Einführung des Werkzeugs. Neben den Problemen und deren Lösungen erläutern wir, die Veränderungen durch die Einführung.
  • Zeitschriftenartikel
    Advanced Analysis for Code Clone Removal
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Schulze, Sandro; Kuhlemann, Martin
  • Zeitschriftenartikel
    Flow Graph Manipulator (FGM) – Reverse Engineering Tool für komplexe Softwaresysteme
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Beier, Anja; Uhlig, Denis
  • Zeitschriftenartikel
    Automotive Software: Characteristics and Reengineering Challenges
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Schulte-Coerne, Vincent; Thums, Andreas; Quante, Jochen
    Automotive software is different from the kind of software that is usually addressed by current reengineering research. This paper gives an overview of the particular conditions and challenges that we face in the automotive domain.
  • Zeitschriftenartikel
    From Architecture to Source Code – How to Ensure Architecture Compliance in the Implemented System
    (Softwaretechnik-Trends Band 29, Heft 2, 2009) Knodel, Jens
    Software architecture is the key factor for efficient communication, planning, development, maintenance, and hence, the overall success of the development project. Architecting is an upfront investment made by development organizations to assure that the resulting system(s) will meet the required quality criteria in time and effort. Among others, the software architecture captures the envisioned structure of the system at development time (i.e., the decomposition of the system in manageable units like components). Verifying this planned decomposition late in the lifecycle of the software system reveals – too often – that the implemented system is not compliant to the specified structure. Consequently, efforts spent for architecting were made in vain because the decision and assumption made are no longer reliable and useful. To pro-actively prevent this structural decay, we propose constructive architecture compliance checking, which constantly monitors the modifications made by several (teams of) developers starting at day one of the implementation phase. Whenever structural violations are detected, the particular developer receives live feedback on the violations. Thus, a prompt removal of violations is possible, which ensures compliance of the implemented system with the architecture. Hence, the investments made into architecting are sustained over time.