• Keine Ergebnisse gefunden

Continuous Software Engineering

N/A
N/A
Protected

Academic year: 2022

Aktie "Continuous Software Engineering"

Copied!
2
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Jens Knoop, Uwe Zdun (Hrsg.): Software Engineering 2016, Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2016 113

Keynote: Continuous Software Engineering

Wilhelm Hasselbring1

Continuous Software Engineering ist seit Jahrzehnten ein kontinuierlich behandeltes Thema in der Forschung und der Praxis des Software Engineering. Traditionell fokussiert die kontinuierliche Softwareentwicklung auf Reverse und Re-Engineering Aktivitäten zur Weiterentwicklung langlebiger Softwaresysteme.

In den letzten Jahren hat dieses Thema in der Praxis durch die Verfügbarkeit von leistungsfähigen Werkzeugen zur Automatisierung stark an Bedeutung gewonnen.

Gleichzeitig ist eine Betonung automatisierter Qualitätssicherungsmaßnahmen zu beobachten. Continuous Integration und Continuous Delivery/Deployment sind dazu aktuelle Schlagworte.

Für die kontinuierliche Softwareentwicklung ist es nun auch wichtig neben der Konstruktion und Weiterentwicklung von Software auch schon in der Entwicklung den späteren Betrieb im Rechenzentrum oder in eingebetteten Systemen zu berücksichtigen.

Die DevOps-Bewegung zielt darauf ab die Zusammenarbeit von Softwareentwicklung (Dev für Development) und Betrieb (Ops für Operations) zu optimieren und Reibungsverluste zu vermeiden.

In der (agilen) Softwareentwicklung ist es das Ziel, schnell viele Features bereitzustellen. Im Betrieb ist es das Ziel, stabile Dienste bereitzustellen - häufige Änderungen werden hier traditionell als unerwünscht angesehen. DevOps verfolgt nun den Ansatz viele, stabile Releases bereitzustellen. Die dazu erforderliche Qualitätssicherung und Effizienzsteigerung wird durch die Automatisierung von Entwicklungs- und Betriebsaufgaben erreicht.

Generell führt die kontinuierliche Integration von Qualitätssicherungsmaßnahmen zu einer kontinuierlich hohen Qualität und damit zu vielen stabilen Releases. Zur kontinuierlichen Überwachung der resultierenden Softwaredienste und auch der sogenannten Deployment-Pipelines muss möglichst viel automatisiert gemessen und überwacht werden (Monitoring).

Durch DevOps bekommt das Thema Softwarearchitektur auch in der agilen Softwareentwicklung eine stärkere Bedeutung und Würdigung. Für DevOps ist es sinnvoll präskriptive und deskriptive Architektur-Modelle zu kombinieren. Präskriptive Modelle kommen aus der Softwareentwicklung (Forward Engineering). Deskriptive

1KoSSE, Universität Kiel, Deutschland, hasselbring@email.uni-kiel.de

(2)

114 Wilhelm Hasselbring

Modelle kommen aus der Beobachtung der im Betrieb befindlichen Softwaredienste (Reverse Engineering durch dynamische Analyse). In diesem Vortrag werde ich diskutieren, warum Softwarearchitektur ein zentrales Artefakt an der Schnittstelle zwischen Entwicklung und Betrieb ist. Speziell Microservice-Architekturen und dem kontinuierlichen Monitoring der resultierenden Systeme kommt hier eine besondere Rolle zu.

Referenzen

ÄHNLICHE DOKUMENTE

Frage 3.2: Nachdokumentation im Code (11 Punkte, ca. 8 Minuten Bearbeitungszeit) Der gegebene Programmcode enthält weder einen Klassen- noch einen Methodenkommentar. Schreiben Sie

●  Läuft das Programm nicht oder sind Ergebnisse offensichtlich falsch, werden die Defekte gesucht und behoben (“Debugging”)!. ●  Der „Test“ ist beendet, wenn das

❍  Experimente zeigen, dass die Sitzung kaum neue Befunde erbringt (die kein Gutachter in der Vorbereitung erkannt hat)!. ❍   Kritische Durchsicht der Individualbefunde durch

●  Ist eine Skala additiv, so muss es mindestens eine Verhältnisskala sein. Die Umkehrung gilt nicht immer.!.. Beispiel: Messung von Portabilität !!. ❍  

●  Wie soll das Risiko im Projekt verfolgt werden?. ●  Kann das Risiko auf Dritte

❍   Eine Zertifizierung nach ISO 9001 bedeutet nicht automatisch, dass dieses Unternehmen Software hoher Güte herstellt!. ❍  Überspitzt ausgedrückt ist auch die kontrollierte

Positiv: Produktverantwortlicher übernimmt Änderungen durch Mischen in die RU; publiziert neue Version in RU!... Problem 2: Änderung

●  Projektspezifische Vorgaben für die Qualität (vgl. Folien Kapitel 16). ❍