Die Teilnehmer erlangen aktuelle praktische Kenntnisse zur Sicherheit von Web-basierten Architekturen in Entwicklung und Einsatz, inkl. Schutzmaßnahmen und Best Practices. Insbesondere wird die kürzlich veröffentlichte Version 2021 der „OWASP Top 10 Security Vulnerabilities“ des „Open Web Application Security Project“ vorgestellt, die alle vier Jahre aktualisiert werden. Es gibt praktische Übungen mittels Open-Source-Werkzeugen für die Sicherheitsanalyse von Architekturen und Implementierungen, für die ein Laptop mitgebracht werden sollte.

Benötigte Software: SonarQube und das Microsoft Threat Modelling Tool

Maximale Teilnehmerzahl: 20

Zielpublikum: Architekt:innen, Entwickler:innen, QA-Manager, Projektleiter:innen, Product Owners
Voraussetzungen: Grundlegendes Verständnis von Webanwendungen
Schwierigkeitsgrad: Anfänger

Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high.

To address these challenges the right timing in testing is critical but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!

Maximum number of participants: 50

Target Audience: Test Architects, Test Engineers, Product Owners, Quality Managers, Software Architects, Developers
Prerequisites: Basic knowledge about testing and quality engineering
Level: Advanced

Extended Abstract
Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high. Our test systems increase in size, volume, flexibility, velocity, complexity, and unpredictability. Additionally, digitalization requires more than just a face lift in testing.

To address these challenges the right timing in testing (“when to do what kind of testing and how?”) is critical, but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!

Some of the areas in testing that are covered in the tutorial are:

• When to do what kind of testing in the lifecycle – agile, lean, DevOps, and beyond
• Testing too early vs. too late – risks and opportunities
• Test automation and the test pyramid – shift-left, shift-right
• When to stop testing – test exit criteria
• Repetition in testing – regression testing

This tutorial introduces to agile requirements engineering. The half day delivers practical guidance from our projects across different industries. While being based on the IREB agile RE primer curriculum, it has more practical focus and avoids agile basics and theory. Yet, participants are eligible to IREB certification. We give practical tips for designing agile requirements processes. Attendees will learn how to combine needs of systematic requirements engineering with agile principles. Special focus is given to connect RE with agile project management and with testing. A hands-on case study shows practical usage of agile RE.

Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced

Extended Abstract
Agile projects need agile requirements engineering. Innovations in increasingly complex systems under cost pressure and in global competition demand for continuous alignment towards value and costs. The key to value delivery is requirements. They are no longer "collected" but must be developed in a targeted manner with suitable interest groups. Requirements are not frozen at an early stage but must be flexibly addressed throughout the project and product. However, agile requirements engineering is difficult to implement, especially in critical systems because of complex dependencies, growing quality requirements and diverse coordination processes.

Agile requirements engineering is not just a trivial priority setting. Leaving our some requirements when time and budget are scarce does not work in critical systems. Design thinking and team-based decision-making are nice for small applications, but hardly scale in larger industrial projects. Describing requirements vaguely and hoping that they become clear in the course of the project has already ruined many projects. Agile requirements engineering in critical and compliant context must combine the needs of classic requirements engineering with the flexibility of agile action.

This tutorial introduces to agile requirements engineering. It offers many practical examples from our industry projects when introducing agility. The training considers the IREB agile RE primer curriculum, however with more practical focus from many agile projects across industries. Participants are eligible to IREB certification. We give practical tips for designing agile requirements processes.

This begins with a value-oriented elaboration of the actual need. Then we look at techniques like Kano model, planning poker, design thinking, Kanban etc. In an industry case study, we present experiences and benefits of agile requirements engineering in a medical technology project with Siemens Healthineers. In particular, we use concrete examples and industry experience to show how agile requirements engineering is implemented in practice. This allowed us to reduce the costs for reworking by about 30%. The experience gained can be transferred to other projects and environments.

As a product manager or project manager, you will learn how to merge systematic requirements engineering with agile principles. As a successful requirements engineer or system analyst, you will learn how to use and scale agile techniques for requirements engineering.

Functional programming is the future of software development. As software gets ever more complex, unintended side effects flourish - you push on one side, and something unexpected squirts out the other. Functional programming cuts down on complexity through high-level abstractions and avoids unintended side effects through pure functions. The result is simple and elegant code that captures the essence of the problem you're trying to solve. Fortunately, functional programming is easy to learn, and this tutorial will get you started.

Target audience: Architects, Developers
Prerequisites: none
Level: Basic

Extended Abstract
Functional programming is the logical continuation of object-oriented programming: OOP managed to encapsulate mutable state with the goal of ultimately eliminating it one day, and functional programming finally realizes that vision. Language implementations have been mature and robust for many years now, and the practical functional languages - Haskell, OCaml, Scala, Clojure, F#, Racket, Erlang, Elixir, Swift - all have thriving communities and ecosystems. Moreover, decades of experience and research teaching functional programming have produced effective didactic approaches that enable anyone into programming to easily get into FP. The time to get started is now!

Security is an important topic, especially when developing software. But it is seen as complex and is holding everyone back, often put off until the end and delegated to an external person or group.

To be effective security needs to be a continuous part of the development process and to involve the whole team.

Security games can help to achieve this. They involve the whole team and facilitate the learning and application of security principles. They offer a way to integrate expert knowledge and make security less scary, maybe even fun.

Maximum number of participants: 50

Target Audience: Architects, Developers, Project Leaders, Testers, Security Experts
Prerequisites: General interest in security, basic development experience
Level: Basic

Agile Coaches und Scrum Master sind in Transformationsprojekten besonders gefordert. Es braucht kontinuierliche Selbstreflexion und Klarheit, um in einer Veränderung eine neue Kultur vorzuleben und dabei selbst in Balance zu bleiben. In der Sozialen Arbeit ist Supervision der Standard und ein elementarer Teil der Qualitätssicherung, sowie der Burn-out-Prophylaxe für Mitarbeiter:innen. Wird es Zeit, auch im agilen Unternehmenskontext Supervision als Standard anzubieten? Wir glauben schon!

Maximale Teilnehmerzahl: 20

Zielpublikum: Scrum Master, Agile Coaches, Agile Führungskräfte
Voraussetzungen: Coaching, Neugierde auf sich selbst, Selbstreflexion
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das Wort Supervision kommt aus dem Lateinischen und bedeutet so viel wie „von oben betrachten”. Hier wird das eigene berufliche Handeln mithilfe eines Supervisors - der den „Blick von außen bzw. oben“ mitbringt - reflektiert. Supervision unterstützt das professionelle Handeln und macht Dynamiken, Zwickmühlen und Unausgesprochenes besprechbar.

Wir zeigen, was Supervision ist und auch was die Unterschiede zwischen Coaching, Supervision und Therapie sind. Außerdem erläutern wir, was Rahmenbedingungen und Handlungsanlässe für Supervision sein können.

Die Teilnehmer:innen werden Supervision in der Praxis erleben, Tools zur eigenen Supervision kennenlernen und sich - falls gewünscht - aktiv einbringen können.

Wir möchten so einen Beitrag für die Professionalisierung der Arbeit von agilen Führungskräften leisten, indem wir bewährte Qualitätsstandards der Sozialen Arbeit mit dem wirtschaftlichen Kontext verbinden.

Traditionally, requirements were used as a means to communicate between customers and development organizations. Unfortunately, requirements suffer from many limitations.

An alternative approach is to focus on outcomes and to use value modeling as a mechanism to quantitatively define the desired outcomes. This value model can then be used for experimentation by humans using DevOps and A/B testing or using machine learning models for automated experimentation.

The tutorial provides introduction of the topics and exercises.

Target Audience: Architects, Product Managers, Senior Developers, Business Leaders
Prerequisites: None
Level: Basic

Do you know that some forecasts project that in 2030 IT will account for 21% of all energy consumption? So, if we do not change the way we implement software, we will contribute to the increase in the carbon footprint. This means it is about time to take another look at how agile development can help decrease energy consumption.

In this workshop, we'll explore how the agile principles can guide us to more sustainability, and we'll provide you with concrete ideas for increasing sustainability in your product development.

Maximum number of participants: 100

Target Audience: Developers, Managers, Scrum Master, Product Owners, Coaches, ...
Prerequisites: Basic knowledge in agile would be helpful
Level: Advanced

Extended Abstract
The Agile Manifesto captures "better ways of developing software" yet, could this better way also take the environmental, economic, and social footprints of your software into account?

Software lifecycle creates direct and indirect carbon emissions: it has a footprint, worsening environmental problems. So, this session tries to provide the first answers to "how can the agile principles contribute to or guide sustainability?" In this workshop, we want to examine how the principles of the Agile Manifesto can provide guidance for implementing sustainability in IT.

In this workshop, we will explore the impact of the agile principles on sustainability, and how a greater awareness can change our current way of working for providing our contribution to addressing climate change.

There are several architecture models with prescribed views and notations. The Keep It Short & Simple architecture model is different. We create pieces of documentation iff they benefit stakeholders. We do so using drawing tools, not modeling tools. We say no to BDUF and yes to Important Design Up Front. We follow 7 tips for creating diagrams that are expressive, not ambiguous, and help you to successfully understand and evolve them, and build a system from them. We complement the design diagrams that describe structure and behavior with ADRs.

Target Audience: Developers and anyone else who plays the role of architect.
Prerequisites: If you've ever developed software, you're ready.
Level: Basic

Extended Abstract
Do you create or use architecture documentation? Have you ever been confused and wondered about the meaning of a box or arrow in a design diagram? Do you think architecture documentation is costly or time consuming? If your answer is yes to any of these questions, this tutorial has practical and valuable information for you. There are several proposed architecture models with prescribed views and notations. The Keep It Short and Simple architecture model is different. We create pieces of documentation if they benefit stakeholders. We do so primarily use drawing tools, not modelling tools. We say no to Big Design Up Front (BDUF) but say yes to Important Design Up Front (IDUF). We follow 7 guidelines for creating informal design diagrams that are expressive, not ambiguous, and effectively help you and others to successfully understand them, evolve them, and build a system from them. Finally, we complement the essential design diagrams that describe structure and behaviour with architecture decision records (ADRs) for the important design decisions.

In the tutorial we look at several example architectures from real world systems. Most are good examples, but we also turn a critical eye on known products' architecture diagrams with several opportunities for improvement. Participants can also share their experience throughout. The tutorial also includes a fun online game and a hands-on exercise.

Tutorial minutiae include: what is the minimum architecture documentation expected, what design decisions are important enough to deserve an ADR, examples of drawing tools, who should be responsible for architecture documentation, how to complement structural diagrams with behavior diagrams.