PROGRAMM

Die im Konferenzprogramm der OOP 2021 Digital angegebenen Uhrzeiten entsprechen der Central European Time (CET).

Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.

Track: Testing & Quality

Nach Tracks filtern
Alle ausklappen
  • Dienstag
    09.02.
  • Mittwoch
    10.02.
09:00 - 10:45
Di 8.1
Performance ist nicht statisch
Performance ist nicht statisch

Das Projekt läuft, die Rahmenbedingungen sind abgesteckt, die Performance des Systems ist gut - ideale Bedingungen also. Leider ist die Realität oft anders. Der Nutzungskontext ändert sich und plötzlich muss ein Vielfaches der ursprünglichen Last bewältigt werden, natürlich in Erwartung gleichbleibender Qualität.

Wie man diese Herausforderung mit gezielten Maßnahmen aus dem Baukasten der Qualitätssicherung beherrschen kann, zeigen wir am Beispiel verschiedener Systeme, die wir auf dem Weg vom Projekt zum Produkt begleitet haben.

Zielpublikum: Tester:innen, Qualitätsmanager:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
:
Das Projekt läuft, die Rahmenbedingungen sind abgesteckt, neue Anforderungen bewegen sich in diesem Rahmen, die Performance des Systems ist gut - ideale Bedingungen also. Leider ist die Realität oft anders. Die Software kommt auch in anderen Abteilungen der Kund:innen gut an und schnell erweitert sich der Nutzerkreis. Oder neue Kund:innen interessieren sich für die gleiche Software und schon wird aus einem Projekt für einen Kunden schnell ein Produkt, das verschiedene Kunden im Einsatz haben. Der Nutzungskontext ändert sich, die Anforderungen verlassen den gesteckten Rahmen und plötzlich sieht sich die Entwicklung damit konfrontiert, ein Vielfaches der ursprünglichen Datenmengen oder Anfragen managen zu müssen. Und natürlich gibt es die Erwartung gleichbleibender Qualität, insbesondere gleichbleibender Performance.

Wie schafft man es, die Hotspots schnell zu identifizieren? Wie helfen architekturelle Entscheidungen? Was sagt man den Kund:innen, welche Probleme die neue Last bedeutet, und wie schätzt man schnell ab, in welchem Zeitraum man diese beheben kann. Wie misst man, wie stark der Host skalieren muss, um zukunftsfähig zu bleiben? Wie muss man Last- und Performancetests gestalten, dass sie wirklich Antworten auf die Fragen geben?

Wie man diese Problemstellungen beherrschen kann, zeigen wir anhand verschiedener Beispiele, bei denen wir Systeme auf dem Weg vom Projekt zum Produkt begleitet haben. Wir stellen insbesondere die Maßnahmen vor, mit denen wir die Herausforderungen erfolgreich gemeistert haben.

Dr. Dehla Sokenou promovierte 2005 an der TU Berlin über UML-basiertes Testen. Sie fühlt sich in allen Phasen der Software-Entwicklung zu Hause, einen besonderen Schwerpunkt bilden allerdings auch weiterhin alle Themen rund um Qualitätssicherung und Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin sowie Software-Architektin tätig. Daneben ist sie ein aktives Mitglied der GI-Fachgruppe TAV und im Sprechergremium des Arbeitskreises Testen objektorientierter Programme.
Continuous-Performance-Testing - Regelmäßig prüfen, ob man noch mit den Anfragen mitkommt
Continuous-Performance-Testing - Regelmäßig prüfen, ob man noch mit den Anfragen mitkommt

Bevor wir uns in die Zukunft bewegen, in der wir unsere schicke neue Applikation oder unsere neuen Features auf echte Benutzer loslassen, sollten wir wissen, ob sie mit den zu erwartenden Anfragen umgehen kann.

Moderne Performance-Test-Tools unterstützen hier nicht nur durch einmalige manuelle Tests, sondern auch mit der Möglichkeit, Lasttests als Teil der Continuous-Integration-Pipelines durchzuführen. Dieser Vortrag soll mit Live-Demos eine Einführung in nötige Voraussetzungen bieten und aufzeigen, wie man Ergebnisse visualisieren kann.

Zielpublikum: Entwickler:innen, QA, Projektleiter:innen
Voraussetzungen: Basiswissen über Java, APIs und Continuous Integration sind von Vorteil, aber nicht dringend
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Regelmäßige Lasttests, auch schon während der Entwicklung, helfen dabei, möglichst gut einschätzen zu können, wie sich eine Anwendung samt ihrer Infrastruktur unter Last verhält, ob sie der anstehenden Nachfrage standhalten kann, oder ob sie vielleicht zu groß definiert ist.

Anhand von Demos mithilfe des Last-Test-Simulators "Gatling" wird gezeigt, wie man zu erwartende Last-Szenarien für eine (Web-)App als Code darstellen kann und wie sie je nach Anwendungsfall skaliert werden können.

Die Demo wird sich auch (kurz) damit beschäftigen, wie man mit Mocking für Dritt-Services umgehen kann, etwa wenn ein Service-Anbieter keine Performance-Tests gegen seine Dienste zulässt.

Die Ergebnisse lassen sich über Metrik-Exporte auch in modernen Visualisierungs-Tools wie Grafana anzeigen, auswerten und vergleichen.

Christian Kühn ist Softwareentwickler bei dmTECH
Er freut sich über das beste aus den beiden Welten Development und Operations und beschäftigt sich mit Java, Cloud-Infrastruktur und Sicherheitsthemen. Er organisiert das DevOps Meetup Karlsruhe und twittert unter: @CYxChris
Dehla Sokenou
Christian Kühn
Dehla Sokenou
Vortrag: Di 8.1-1
Christian Kühn
Vortrag: Di 8.1-2
flag VORTRAG MERKEN
14:00 - 14:45
Di 8.2
Back to the Data - Now That We (Machine) Learned From Test Results, What Else Did We Gain?
Back to the Data - Now That We (Machine) Learned From Test Results, What Else Did We Gain?

80% of machine learning is said to be data wrangling. Is all this wasted effort? Hardly - often the journey really is its own reward.

In this talk, we'll briefly describe a machine learning project that predicts the outcome of test cases in a large-scale software development cycle. We'll then show what we gained from collecting the necessary data and how these insights can have lasting impact on the day-to-day work of developers, testers and architects. This includes a quick answer to the well-known question: Whose defect is it anyway?

Target Audience
: Developers, Testers, Architects
Prerequisites: Basic knowledge of software development and testing and an interest in data analytics
Level: Basic

Extended Abstract
:
Data science folk wisdom holds that at least 80% of machine learning consists of data wrangling, i.e. finding, integrating, annotating, and cleaning the necessary data.

While sometimes viewed as less "glorious" than the deployment of powerful models, this journey has its own rewards as well.

Benefits may sometimes be somewhat expectable, if still non-trivial, like data cleaning potentially exposing errors in underlying data bases.

In other cases, though, there may be some low-hanging fruit a casual glance might miss even though they are indeed rewarding.

Data integration often reveals opportunities for statistical analyses that are relatively simple, but may still have high impact.

In this talk, we'll start at the destination: the result of a machine learning project where we successfully predicted test results from code changes.

A necessary task was the integration of several data sources from the full software development cycle - from code to testing to release in a large industry project with more than 500 developers.
Naturally, this required all typical steps in the data science cycle: building up domain knowledge and problem understanding, both semantic and technical data integration, data base architecture and administration, machine learning feature design, model training and evaluation, and communicating results to stakeholders.

These steps yielded several benefits, on which we will focus in our talk.

Among others these include data quality insights (e.g. about actual "back to the future" timestamps), and new analyses which were made possible by a unified view of the data (e.g. survival analysis of defects).

Last but not least, we demonstrate a simple answer to a well-known question, especially in larger software development contexts: Whose defect is it anyway - how can we avoid assigning defects to teams that have nothing to do with them?

Thanks to the integrated information sources from systems concerned with version control, test result logging, and defect management, we are able to support the claims made in this talk with statistics taken from 6 years of real-world data.

Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at codemanufaktur GmbH deals with Machine Learning and Data Analysis.
Marco Achtziger is Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.
Gregor Endler, Marco Achtziger
Gregor Endler, Marco Achtziger
Vortrag: Di 8.2
flag VORTRAG MERKEN
16:15 - 17:15
Di 8.3
Kann uns AI helfen, besser zu testen?
Kann uns AI helfen, besser zu testen?

Machine Learning hat uns privat längst erreicht: Netflix schlägt mir Filme vor, die mir oft sogar gefallen. Warum gibt es keine Software, die mir fundiert vorschlägt, was ich testen soll?

Es gibt Forschungsansätze, die das versprechen: Defect Prediction nutzt Machine Learning auf historischen Fehlerdaten, um vorherzusagen, wo am meisten Fehler sein sollen. Aber wie gut funktioniert das in der Praxis?

Wir haben solche Ansätze selbst implementiert und eingesetzt. In diesem Vortrag stelle ich die Ergebnisse aus Forschung und Praxis vor.

Zielpublikum: Entwickler:innen, Testende, Verantwortliche für Entwicklung und Test
Voraussetzungen: Interesse an Software-Test
Schwierigkeitsgrad: Fortgeschritten

Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit zehn Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Elmar spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Elmar wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.
Elmar Juergens
Elmar Juergens
Vortrag: Di 8.3
flag VORTRAG MERKEN
17:45 - 18:45
Di 8.4
Testsuite Yoga – Software-Tests zurück ins Gleichgewicht bringen
Testsuite Yoga – Software-Tests zurück ins Gleichgewicht bringen

Nicht nur Menschen, auch Testsuiten geraten unter Stress. Solche Tests sind fragil, langsam in der Durchführung oder kosten auf andere Art Zeit und Nerven.In diesem Vortrag beschreibe ich, wie man diesen Stress abbauen kann. Dazu gehören:- Tägliche *A*temübungen mit *A*utomatischen Analysen, die Probleme in Tests beim Erstellen verhindern- *M*editation über einfache *M*etriken zur Früherkennung von Stress in Testsuiten- Yoga-*P*ositionen in Form von *P*rozessen und Aktivitäten, um die Qualität von Tests von Anfang an in den Griff zu bekommen.

Zielpublikum: Testende, Qualitätsmanager:innen, Entwickler:innen
Voraussetzungen: Grundkenntnisse Testen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nicht nur Menschen (vor allem Software-Entwickler und -Tester), sondern auch Testsuiten geraten im Laufe ihres Lebens unter Stress. Woran zeigt sich das? Tests, die unter Stress stehen, sind fragil (also schlagen häufig fälschlich Alarm), langsam in der Änderung und Durchführung oder kosten auf andere Art Zeit und Nerven. Konkrete, messbare Symptome von Stress sind u. a. mehrdeutige Testfallbeschreibungen, eine unverständliche Struktur, unklare Testabdeckung oder zahlreiche Duplikate. Folgen des Stresses für das Projekt sind schlechte Software-Qualität und hohe Test- und Wartungskosten.In diesem Vortrag zeige ich Gründe für den Stress in Testsuiten auf. Vor allem aber beschreibe ich, wie man in Projekten diesen Stress abbauen kann. Dazu gehört:- Tägliche *A*temübungen mit *A*utomatischen Analysten, die Probleme in Testsuiten schon bei der Erstellung verhindern- *M*editation über einfache *M*etriken zur Erkennung von Stress in Testsuiten- *P*ositionen in Form von *P*rozessen und Aktivitäten, um die Qualität von Tests von Anfang an konstruktiv in den Griff zu bekommen.Wir haben diese Techniken seit etwa 5 Jahren in über 60 Projekten im Einsatz. In dem Vortrag berichte ich aus unseren Erfahrungen: Wann helfen diese Techniken der Testsuite Stress abzubauen? Und was steht auf dem Pfad zum inneren Gleichgewicht im Weg?

Dr. Henning Femmer leitet als Mitgründer den Bereich Requirements Engineering bei Qualicen. Dabei hilft Henning unterschiedlichsten Firmen, Qualität zu verstehen und pragmatisch zu steuern. Er hat im Bereich Software-Engineering an der Technischen Universität München promoviert und ist in verschiedensten Gremien tätig. Henning ist häufig Speaker auf nationalen und internationalen Konferenzen. In den letzten beiden Jahren ist er auf den Software Quality Days zu den besten Vortragenden gewählt worden, auf dem Berliner Requirements Engineering Symposium 2019 hat er die Keynote gehalten.
Henning Femmer
Henning Femmer
Vortrag: Di 8.4
flag VORTRAG MERKEN
09:00 - 10:45
Mi 8.1
The C4 Testpyramid - An Architecture-Driven Test Strategy
The C4 Testpyramid - An Architecture-Driven Test Strategy

The Test Pyramid is an efficient and effective approach for Software Testing but does not come with any details about concrete test methods or fixtures.

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to elaborate a specific test strategy for your software product in a simple manner.

Target Audience: Architects, Developers, QA Engineers
Prerequisites: Basic knowledge in Software Architecture and QA Engineering
Level: Advanced

Extended Abstract:
Software tests have to specify the behaviour of your product as extensive and reliable as possible. At the same time their implementation and maintenance costs should be kept at a minimum.

As Kent Beck said before: "I get paid for code that works, not for tests".

The Test Pyramid is a proven approach for this problem but leaves a lot of room for interpretation when elaborating a test strategy for your product.

Furthermore there are a lot of partly contradictory definitions of Unit, Service and Integration Tests and variations like “Test Diamond” and “Test Trophy” make it even more confusing. So, how do we get from the Test Pyramid to a concrete test strategy?

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to obtain a test concept tailored for your product. Examples taken from a recent project will demonstrate how this approach balances test coverage, maintainability and development costs.

Christian Fischer works as a Software Engineering Coach at DB Systel and loves TDD, Extreme Programming and Craft Beer.
Testing a Data Science Model
Testing a Data Science Model

What would your first thought be when you are told there is no testing or quality structure in a team? How would you inspire a team to follow vital processes to thoroughly test a data science model?

I would like to share my knowledge about testing a model in a data science team.

Data science is a very interesting area to explore. It presents testing challenges that are quite different from “traditional” software applications. I will share my journey introducing testing activities to help build quality into a data science model.

Target Audience: Testers, QA, Developers, delivery managers, product owners, scrum masters, everyone is welcome
Prerequisites: QA, Testing
Level: Basic

Laveena Ramchandani is a vibrant, motivated and committed individual, whose main aim towards the IT industry is to apply herself and dedicate her energy to becoming the best hire as a Technical and/or Business Consultant. Establish through this experience a bridge of trust between the company and her education.

She has been awarded a Business Computing degree from Queen Mary University Of London. She thoroughly enjoyed the technical aspects of the computing side of her degree applied those skills to the business side of her degree.

She will bring an innovative and valuable contribution to any programme through her aptitude for IT, her interest in the business world and interpersonal skills. She is and will be a practical and valuable member of any team, as she is able to work effectively and efficiently with others to complete any given task.

She has excellent communication skills gained from both academic and non-academic environments.

Christian Fischer
Laveena Ramchandani
Christian Fischer
Vortrag: Mi 8.1-1
Laveena Ramchandani
Vortrag: Mi 8.1-2
flag VORTRAG MERKEN
11:00 - 11:45
Mi 8.2
Test Automation in Zeiten des Digitalen Darwinismus am Beispiel einer internationalen Bank
Test Automation in Zeiten des Digitalen Darwinismus am Beispiel einer internationalen Bank

Raiffeisen Bank International (RBI) startete 2017 mit „Group Digital Solutions“ eine Reise, um die Digitalisierung der Bankenbranche nicht zu verschlafen.

Durch neue Vorgehensweisen wie DevSecOps & Continuous Testing, musste das Thema Software-Tests, egal ob manuell oder automatisiert, von Grund auf neu konzipiert und umgesetzt werden.

Dieser Vortrag gibt Einblicke in die Teststrategie & die FullStack-Testautomationsarchitektur, die dabei zum Einsatz kamen.

Zielpublikum: Tester, Developer, Architekt:innen, Manager:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Damit die Raiffeisen Bank International mit der Digitalisierung im Bankenbereich mithalten kann, setzt das Unternehmen bei der Umsetzung ihrer mobile Banking Strategie auf den Einsatz von nativen Apps, Microservices und REST-APIs in der Amazon Cloud. Um die Durchlaufzeit einer Anforderung von der Entwicklung bis zur Produktivsetzung von bisher mehreren Monaten auf wenige Tage zu reduzieren, kommen Continuous Delivery und DevOps zum Einsatz. Um dem DevOps-Mantra „Automate everything“ gerecht zu werden, wurde dazu eine FullStack-Testautomationsstrategie entwickelt, die auf Open-Source-Tools basiert und sämtliche Komponenten der Systemarchitektur berücksichtigt.

Durch die eigenständigen Services der Microservice-Architektur sind zusätzliche Schnittstellen sichtbar, die in einer monolithischen Architektur nicht vorhanden sind. Der Vorteil ist, dass sie unabhängig voneinander bereitgestellt und getestet werden können. Das Testen dieser Systeme ist wesentlich komplexer als das Testen einer herkömmlichen monolithischen Anwendung und stellt zusätzliche Anforderungen an die Testautomation, wobei klassische Integrationstests noch wichtiger für das Gesamtgefüge sind. Diese Integrationstests wurden durch Consumer-Contract Tests sinnvoll ergänzt. Aber auch End-2-End Tests dürfen nicht fehlen, da eine effektive Teststrategie sowohl das isolierte Testen einzelner Dienste als auch die Überprüfung des Gesamtsystemverhaltens berücksichtigen muss.

Eine Ausrichtung der Testautomation an der klassischen Testpyramide ist ein durchaus brauchbarer Ansatz, wenn die einzelnen Schichten als Grundlagen für das „Was wird getestet“ gesehen werden, und nicht als Maß für die Anzahl der Tests. Weil noch immer die alte Weisheit zählt: „Qualität vor Quantität!“.

Rudolf Grötz ist seit 30 Jahren in der IT unterwegs und seit 2008 passionierter Softwaretester. Er ist als Agile Engineering Coach für das Thema & Test Automation bei der Raiffeisen Bank International in Wien tätig und lebt den Leitspruch „Testautomation is not an act, Testautomation is a habit!“. Neben diverser Autorentätigkeiten, u.a. für das IX-Magazin, organisiert er in Wien das Agile (Test) Automation Meetup und 6x pro Jahr die TestBustersNight Vienna.
Matthias Zax arbeitet als Agile Engineering Coach bei Raiffeisen Bank International AG (RBI). Eigentlich gelernter Software Developer, beschäftigt er sich seit 2018 mit dem Testen von Software mit Schwerpunkt Testautomation im DevOps-Umfeld und organisiert die RBI Testautomation Community of Practice.
Rudolf Grötz, Matthias Zax
Rudolf Grötz, Matthias Zax
Vortrag: Mi 8.2
flag VORTRAG MERKEN
14:30 - 15:30
Mi 8.3
Validation of Autonomous Systems
Validation of Autonomous Systems

Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

Target Audience: Testers, Quality assurance, Architects, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: Testing basic know-how
Level: Advanced

Extended Abstract:
Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. There are many open questions about the validation of autonomous systems: How to define reliability? How to trace back decision making and judge afterwards about it? How to supervise? Or, how to define liability in the event of failure? The underlying algorithms are difficult to understand and thus intransparent. Traditional validations are complex, expensive and therefore expensive. In addition, no repeatable effective coverage for regression strategies for upgrades and updates is available, thus limiting OTA and continuous deployment.

With artificial intelligence and machine learning, we need to satisfy algorithmic transparency. For instance, what are the rule in an obviously not anymore algorithmically tangible neural network to determine who gets a credit or how an autonomous vehicle might react with several hazards at the same time? Classic traceability and regression testing will certainly not work. Rather, future verification and validation methods and tools will include more intelligence based on big data exploits, business intelligence, and their own learning, to learn and improve about software quality in a dynamic way.

Verification and validation depend on many factors. Every organization implements its own methodology and development environment, based on a combination of several of the tools presented in this presentation. It is however relevant to not only deploy tools, but also build the necessary verification and validation competences. Too often we see solid tool chains, but no tangible test strategy. To mitigate these pure human risks, software must increasingly be capable to automatically detect its own defects and failure points.

Various new intelligent validation methods and tools are evolving which can assist in a smart validation of autonomous systems.

This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in product development. Before he had been working for twelve years in global senior management positions. A trusted advisor for companies around the world and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including the most recent “Global Software and IT” published by Wiley and "Requirements Engineering" published by dPunkt and in China by Motor Press. Since many years he is serving on the editorial Board of the prestigious "IEEE Software" journal.
Michael Weyrich is the director of the University of Stuttgart’s Institute for Automation and Software Systems. Before he spent many years at Daimler and Siemens where he had senior management positions in engineering. Ever since he engages in technology transfer and is heading numerous industry projects on automation and validation. He authored several books including the leading reference book on "Industrial Automation" published by Springer. Since many years he serves on VDI in various leadership positions. He is leading the VDI/VDE committee on testing of connected systems and industry 4.0.
Christof Ebert, Michael Weyrich
Christof Ebert, Michael Weyrich
Vortrag: Mi 8.3
flag VORTRAG MERKEN
17:00 - 18:00
Mi 8.4
Architecture Fitness Functions demystified! Unser Weg zur praktischen Anwendung
Architecture Fitness Functions demystified! Unser Weg zur praktischen Anwendung

Um agiler auf Kundenbedürfnisse einzugehen und Entwicklungszyklen zu verkürzen, setzt die DATEV in der Breite auf Cloud-native Microservice Architekturen. Teams sollen damit in die Lage versetzt werden, weitgehend autonom an ihren Themen zu arbeiten und dabei kontinuierlich Wert zu liefern.

Wir berichten von unseren praktischen Erfahrungen, wie Teams nun qualitätsgetrieben ihre Systeme entwickeln und durch den Einsatz diverser Testmethoden die Erfüllung der geforderten Qualitätsanforderungen absichern: Architecture Fitness Functions demystified!

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider:innen, Product Owner, Projektleiter:innen
Voraussetzungen: Architekturkenntnisse, Grundwissen Testing
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Seit einigen Jahren wird das kontinuierliche Prüfen der Architektur und deren Tauglichkeit oder eben Fitness für die Nutzerbedürfnisse unter dem Schlagwort Architecture Fitness Function thematisiert.

Die DATEV eG befindet sich sowohl in einer technologischen als auch organisatorischen Modernisierung. Mit dem Ziel, schneller Wert für den Kunden zu liefern, entwickeln wir mehr und mehr Cloud-native Microservice-Architekturen, auf dessen Grundlage Teams weitgehend autark an ihren Themen arbeiten können. Dabei beschäftigte uns auch der agile Architekturentwurf, der Over-Engineering und aufwendige Big-Upfront-Designs vermeiden soll. Teams starten mit einer schlanken (lean) Architektur, die sich iterativ weiterentwickelt. Die Gratwanderung zwischen Entwickeln auf Sicht und dem nachhaltigen, systematischen Architekturentwurf meistern wir nun durch den frühzeitigen und konsequenten Einsatz der Architecture Fitness Functions.

In diesem Vortrag berichten wir von unserem begangenen Weg, diese Methode immer effektiver und effizienter im Projektalltag anzuwenden. Die Einführung und insb. das Demystifizieren des Begriffs Fitness Functions dauerte eine Weile. Wir zeigen unsere Maßnahmen auf: Wie und welches Fundament schufen wir dafür? Wie veränderten wir das Rollenzusammenspiel im Entwicklungsprozess und wie sorgten wir für die entsprechende Vorbereitung und Fokussierung? Leider war auch der Weg zu wirklich überprüfbaren Qualitätsanforderungen steinig. Aber wir konnten durch passende Techniken wie bspw. Quality Fathoming auch dort den Zustand deutlich verbessern.

Wir zeigen unsere ersten Gehversuche mit Tests der Architekturfitness und wie heute unsere Testnetze zur kontinuierlichen Überprüfung und Visualisierung der Architekturfitness aussehen. Zudem demonstrieren wir, wie sich unser agiler Architekturentwurf und die daraus resultierenden Architekturen durch den Einsatz von Fitness Functions verändert haben.

Andreas Hinkelmann ist ein Lead Architekt bei der DATEV eG. Dabei berät er andere Architekten, zudem schult und übt er mit diesen den systematischen Architekturentwurf und das Domain-driven Design.
Matthias Kindermann ist seit 2017 für die DATEV eg in Nürnberg tätig und agiert in der Rolle als zentraler Systemarchitekt. Sein Schwerpunkt liegt auf Cloud-native Architekturen und Web-Technologien.
Andreas Hinkelmann, Matthias Kindermann
Andreas Hinkelmann, Matthias Kindermann
Vortrag: Mi 8.4
flag VORTRAG MERKEN

Zurück