Die Technologie ermöglicht es, kontinuierlich mehr Daten zu sammeln und zu verwenden – im Gegenzug werden diese Möglichkeiten seitens des Gesetzgebers bewusst reguliert. Kein leichtes Unterfangen also für die Unternehmen, hier durchgängig konform zu agieren. Hilfestellung bei dieser Zwickmühle bietet das Konzept ‚Privacy-by-Design’, bei dem bereits während der Planung von Applikationen sowie insgesamt digitalen Angeboten die Vorgaben des Datenschutzes in technischer und organisatorischer Hinsicht einbezogen werden. Eine technische Umsetzung, mit deren Unterstützung Datensparsamkeit, Zweckbindung und die eigenverantwortliche Steuerung der Datenflüsse gewährleistet werden kann, ist bei der zunehmend vernetzten und vollautomatisierten Welt nahezu unerlässlich.

Im Rahmen des Vortrags soll erörtert werden, warum es für Unternehmen nicht nur notwendig sondern unter dem Kosten-/Nutzeneffekt auch sinnvoll ist, sich mit dem Konzept Privacy-by-Design zu beschäftigen und wie Unternehmen hier bestmöglich vorgehen können. Aber auch wo hier noch mögliche Fallstricke bei der Umsetzung liegen können.

Das Ziel dieser Arbeit ist es, Funktions- und Werkzeugentwicklern zu helfen, eine Anzahl von Schwachstellen zu erkennen, die bei der Implementierung von physikalischen Modellen in Controllercode für sicherheitskritische eingebettete Systeme immer wieder auftauchen. Die Trends bei automobiler Softwareentwicklung für eingebettete Systeme gehen in die Richtung von model-predictive control (MPC), virtuellen Sensoren oder modellbasierter Diagnose, welche vor allem im Bereich der erweiterten Fahrassistenzsysteme (ADAS) und des automatisierten Fahrens genutzt werden. Solche Applikationen nutzen physikalische Modelle in den Kontrollalgorithmen, um Aussagen über die kontrollierten Systeme treffen zu können. Die Einbindung physikalischer Modelle ist ein riskantes Unterfangen, da Schwachstellen, wie die Nutzung von Gleitkommaarithmetik und Diskretisierungsmethoden oder Modelleigenschaften wie Unstetigkeiten und Nichtlinearität, schnell ein Projekt zum Scheitern bringen oder Fehler im finalen Produkt etablieren. Die Verwendung erprobter Absicherungsmethoden ist oft nicht möglich oder vermittelt falsche Sicherheit. Diese Arbeit soll Entwicklern helfen, die Schwachstellen zu verstehen und neue Verifikations- und Validierungsmethoden zu entwickeln, die speziell auf physikbasierten Steuergerätecode zugeschnitten sind. Dafür wurden die Schwachstellen in aktuellen industriellen Projekten identifiziert, gesammelt und analysiert. Darauf aufbauend werden Vorschläge und Techniken für die Diagnose oder die Vermeidung von potentiellen Fehlern präsentiert, um Tester und Qualitätsmanager zu ermutigen, neue Ansätze für die Absicherung von und Fehleridentifikation in kritischem, physikbasierten, eingebetteten Code zu finden. Der Fokus hierbei liegt auf der Analyse der Fehlerquellen.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen, dass die Integration physikbasierter Modelle auf eingebetteten Systemen mit vielen Herausforderungen verbunden ist. Gerade auch Probleme, die fälschlicherweise als gelöst betrachtet werden, wie numerische Fehler durch Gleitkommaarithmetik oder Diskretisierungsfehler, haben hier kritische Auswirkungen, was viele industrielle projekte im Haus ETAS und Bosch scheitern lassen hat. Das Bewusstsein für diese probleme soll wieder gesteigert werden. Die Zuhörer profitieren von den gesammelten Erfahrungen der Auswirkungen der Schwachstellen, die bei Projekten, im Rahmen dieser Arbeit, identifiziert wurden. Sie lernen, welche Absicherungsmethoden eingesetzt wurden und welchen Beitrag diese zur Lösung der Probleme hatten. Davon ausgehend werden theoretische angepasste Absicherungs- und Diagnosemethoden in einem Ausblick vorgestellt, die direkt auf Probleme durch Schwachstellen der Nutzung physikbasierter Modelle in kritischen eingebetteten Systemen angepasst wären.

Neben den funktionalen Sicherheitstests werden in der Automobilentwicklung Security Tests immer wichtiger. Zum einen ist vielfach nicht klar, welche Tests wie und in welchen Umfang durchgeführt werden müssen, und zum anderen, welche Werkzeuge bzw. Werkzeugketten und Methoden dabei zum Einsatz kommen sollen und können. Welche Anforderungen aus den entsprechenden Normen sind dafür relevant?

sepp.med hat im Rahmen eines Förderprojektes untersucht, welche Anforderungen sich aus den Normen (z.B. ISO 26262, ISO/SAE 21434) für Security Tests ergeben und daraus ein Vorgehen abgeleitet, wie auch die Zertifizierung selbst werkzeuggestützt durchgeführt werden kann.

Die Industrie 4.0 charakterisiert sich durch die globale Vernetzung aller Beteiligten eines Produktionsprozesses und schließt Hersteller und Kunden nicht nur ein, sondern bringt die verschiedenen Parteien näher zusammen. Um dieses angestrebte Ziel greifbar zu machen, müssen die neuen Kommunikationskanäle Vertrauen schaffen, welches nur durch die Einhaltung umfangreicher Schutzziele erreicht werden kann.

Besonders für klassische Maschinenbauunternehmen stellt diese Aufgabe eine große Herausforderung mit immensen Investitionen im Bereich Personal- und Produktentwicklung sowie der Einführung neuer Technologien einhergeht.

Die Arbeitsgruppe Safety und Security der Hochschule Hamm-Lippstadt knüpft genau an dieser Stelle mit einem neuen konzeptionellen Vorgehen an. Hierfür wurden die vorhandenen Erfahrungen eigener Projekte im industriellen Umfeld gebündelt, um ein Konzept in Form einer Best-Practice-Umsetzung für die Industrie zu entwickeln. Aufgrund der Allgemeingültigkeit der gesammelten Safety- und Security-Mechanismen stellt sich dies als ein adaptierbares Verfahren für alle Interessengruppen aus der Industrie dar.

Diese Blaupause inkludiert eine anfängliche Sicherheits- und Risikobewertung und erstreckt sich über alle Ebenen der Produktentwicklung sowie des Prozessmanagements hinweg bis hin zur Betrachtung sicherheitskritischer Komponenten und Daten im Produktlebenszyklus. Hierbei wird neben Security by Design auch die Umsetzung von Sicherheitsmaßnahmen im gesamten Lebenszyklus vorgschlagen.

Das bedeutet, dass sich dieses Modell direkt von Anfang an bei der Entwicklung und Produktion neuer Hard- und Software mit relevanten Sicherheitsthemen befasst und sich bis zur Einbettung sowie Wartung beim Kunden erstreckt und erst bei der Verschrottung und Entsorgung endet.Dabei kommen diverse strukturelle Probleme zum Tragen, wie beispielsweise die eines sicher funktionierenden Schlüsselmanagements und den zu Grunde liegenden Verschlüsselungsverfahren insbesondere bei eingeschränkten Umgebungen, wie leistungsschwachen eingebetteten Systemenen. Des Weiteren müssen alle Sicherheitsziele, über alle Infrastrukturkomponenten hinweg, für die sichere Datenkommunikation gewährleistet sein. Dieses Vorhaben schließt in der Industrie 4.0 auch Cloud-Systeme und Mobile Endgeräte mit ein.

Ebenso gilt es neben den typischen Angriffsvektoren in der Industrie neue Schwachstellen durch Neubewertungen von Bedarfsmaßnahmen zu erfassen und passende Interventionsmaßnahmen durchzuführen. Dafür werden Verfahren und Werkzeuge an die Seite gelegt, die eine Grundsicherung im Rahmen von Penetrationstests gewährleisten.

Alle hier entwickelten und definierten Prozesse werden im Kontext von etablierten nationalen und internationalen Normen durchgeführt, die dem Ziel einer Zertifizierung ermöglich. Der Fokus bezieht sich insbesondere auf die ISO 62443, welche sich besonders an Betreibern von Automatisierungssystemen wendet.

Dieser Vortrag stellt das Vorgehensmodell für die Entwicklung, die Umsetzung und den Betrieb (IT-)sicherer Systeme in der Industrie 4.0 vor und präsentiert erste Ergebnisse einer prototypischen Umsetzung in einem Industriebetrieb. Die zur Definition der Schutzziele zugrunde liegende Risikoanalyse wird dargelegt. Die ganzheitliche Betrachtung bezieht sich auf den gesamten Lebenszyklus des Systems. Das Vorgehensmodell ist im Rahmen eines Forschungsprojektes zur Umsetzung intelligenter, sicherer industrieller Produkte entwickelt worden und wurde vom Ministerium für Wirtschaft, Innovation, Digitalisierung und Energie des Landes Nordrhein-Westfalen gefördert. Ziel des Projektes ist neben der konkreten exemplarischen Umsetzung die Schaffung von Best-Practices und Blaupausen für smarte aber sichere industrielle Anwendungen der Zukunft. Hierbei werden vorhandene Standards und Best-Practices vereint und bezüglich spezifischer industrieller Anforderungen konkretisiert und damit handhabbarer gemacht.

Wir werfen einen kurzen Blick auf die Geschichte der Kryptographie und die fast ebenso lange Geschichte der Kryptoanalyse. Schliesslich widmen wir uns den heute verbreiteten und den (noch) sicheren Verschlüsselungsverfahren der Gegenwart. Wie kommunizieren Sie mit Ihrer Bank? Was bedeutet das grüne Schloss in der Adresszeile Ihres Browsers wirklich und weshalb werden immer wieder Daten gestohlen? Wir stellen symmetrische und asymmetrische Verschlüsselungsverfahren gegenüber und erklären Anhand von aktuellen Beispielen die Begriffe TLS, Certificate und CA. Ein grundlegendes Verständnis für die vorgestellten Verfahren ist hilfreich um bei der Entwicklung neuer IoT-Produkte konzeptionelle Fehler bereits im Vorfeld zu vermeiden.

Hersteller von Cybersicherheitslösungen versuchen, die Komplexität und Häufigkeit von Cyberattacken mit Künstlicher Intelligenz und Machine Learning in den Griff zu bekommen. Diese Technologien werden eingesetzt, um Anomalien aufzudecken, die auf bösartiges Verhalten – sei es von Cyberkriminellen, Malware, verärgerten Mitarbeitern oder anderen Angreifern - im Unternehmensnetzwerk hinweisen.

Allerdings sind solche KI-basierten Sicherheitslösungen keine Wunderwaffe im Kampf gegen Angriffe auf die IT-Sicherheit. Denn leider geht das auch umgekehrt und so gab es bereits vereinzelte Fälle, in denen ein von KI unterstützter Cyberangriff Sicherheitsvorkehrungen umging, beispielsweise durch Nachahmung menschlichen Verhaltens.

Unternehmen müssen auch weiterhin auf mehrschichtige Sicherheitssysteme setzen und gezielt menschliche Intelligenz in Form von spezialisierten Experten einsetzen, wenn der Maschine Daten fehlen, um eine Entscheidung zu treffen, ob es sich wirklich um eine Bedrohung handelt und wie der Angriff abgewehrt werden soll. Das Zusammenspiel von KI-Algorithmen und Sicherheitsanalysten erhöht die Qualität der Cyberabwehr in modernen Unternehmen erheblich. Wie das funktioniert, erklärt Rüdiger Trost, und beantwortet in seinem Vortrag Fragen wie:

• Was genau machen Cybersicherheits-Anbieter mit KI und ML?
• Wofür genau werden diese neuen Technologien eingesetzt und warum sind sie bei der Erkennung von Angriffen schneller und effizienter?
• Wird KI menschliche Sicherheitsexperten ersetzen?

In der agilen Software Entwicklung mit ihren kurzen, dynamischen Entwicklungszyklen ist eine stets lauffähige Software zentraler Bestandteil des Entwicklungsprozesses. Aussehen und Funktion des geforderten Produkts lassen sich viel einfacher an einer funktionstüchtigen Applikation diskutieren als an einem Lasten- und Pflichtenheft, wie es im klassischen V Modell zu finden ist. Welche Möglichkeiten bieten moderne Software Entwicklungssysteme Fortschritte zu demonstrieren wenn die zugrunde liegende Hardware noch nicht verfügbar ist? Die Antwort ist Simulation. Simulatoren erlauben parallele Produkt-Entwicklungen für Hardware und Software und sind somit ein zentrales Mittel des dynamischen Entwicklungsprozesses. Darüber hinaus unterliegen Simulatoren nicht den Hardware üblichen limitierten Flash-Zyklen und sind daher auch prädestiniert für agile Entwicklungsmethoden wie Test Driven Development. Andere agile Entwicklungsmethoden wie z.B. Rapid Prototyping können ebenfalls von automatisiert erstellten Testfällen profitieren, während die automatisierte Testfall-Ausführung den Regressionstest und Continuous Integration unterstützen.

Was lernen die Zuhörer in dem Vortrag?

Der Vortrag legt die zentrale Bedeutung von Simulation und Test in der agilen Software Entwicklung dar. An praktischen Beispielen wird demonstriert wie heutige Entwicklungswerkzeuge den agilen Entwicklungsprozess durch Simulation und Test Automation erst ermöglichen.

Der Vortrag stellt Ergebnisse eines internationalen Forschungsprojektes vor, das sich mit der Modellierung und Analysemethoden für adaptive Systeme beschäftigt. Dabei wurde mit Simulink ein Softwaremodell zur Simulation einer Flotte von Transportrobotern entwickelt und getestet. Der Schwerpunkt lag auf der Adaptivität des Systemverhaltens hinsichtlich dynamisch veränderlicher Kontextvariablen. Dazu wurde u.a. ein Kontextmodell um eine Einheit erweitert, die ein Manufacturing Execution System repräsentiert. Diese Einheit steuert zur Laufzeit verschiedene Produktionsziele, wie z.B. die Maximierung von Sparsamkeit, Robustheit oder Performance oder die Minimierung des Wartungsaufwandes. Die Änderung dieser Ziele muss im Sinne eines sich dynamisch ändernden Kollaborationsprotokolls beachtet werden und wurde entsprechend im Modell umgesetzt. Des Weiteren wurde das Zusammenspiel von systemweit gültigen Produktionszielen und lokalen Restriktionen am Beispiel eines Mindestbatteriestandes modelliert. Die Anforderungen an die Adaptivität des Systemverhaltens wurden mit Hilfe einer formalen Spezifikationssprache formuliert. Mit Hilfe passender Testsequenzen konnten diese Anforderungen durch Simulation des semi-formalen Modellartefaktes automatisiert validiert werden, sodass eine entsprechende Methodik zur virtuellen Systemspezifikation und -validation etabliert wurde.

Was lernen die Zuhörer in dem Vortrag?

Praxisbericht Testmethoden für Modelle von eingebetteter Software. Kennenlernen einer formalen Spezifikationssprache für Requirements.

Nachdem Agile Methoden großen Einzug in Softwareentwicklungsprojekte gehalten haben sind Sie zunehmend auch Teil von Systementwicklungen im Automotive Bereich. Hierbei stellt sich jedoch die Frage, wie Agilität und die Entwicklung von sicherheitsrelevanter Software miteinander vereinbar sind. Kurze Releasezyklen, funktionierende Software über umfangreiche Dokumentation und spätest-mögliche Entscheidungen scheinen sich direkt mit den Anforderungen der ISO 26262 zu widersprechen. Oft wird eine umfangreiche Spezifikation und ein Sicherheitskonzept erstellt, dann die Software iterativ umgesetzt. Aber ist das wirklich sinnvoll?

In diesem Vortrag werden die Vorteile agiler Entwicklungsmethodik aufgezeigt und die Probleme im Umgang mit Normen erläutert. Daraufhin wird ein Metamodell zur Anforderungsverwaltung vorgestellt, um die Übersicht über Spezifikation, Risikobewertung und Umsetzung in einem agilen Projekt zu behalten. Dieses Metamodell bietet die Möglichkeit zu jeder Zeit im Projekt den Überblick über aktuelle Risiken, Sicherheitsanforderungen und ausstehende User Stories zu behalten. Der Einsatz des Modells wird beispielhaft mit dem ALM-Werkzeug Polarion von Siemens demonstriert.

While not every organization is a “Netflix” or “Facebook”, agile development offers very real benefits for most organizations and the key to unlocking that potential is removing the bottlenecks from the delivery pipeline. The most critical and complex bottleneck in the pipeline is testing – this key to ensure the delivery of quality of at speed of agile. But agile is often seen as a development lead initiate, leaving many testers questioning how they fit into the agile development process. For a team to be successful with agile both team dynamics and testing approaches need to evolve. In this presentation Jochem will address the cultural changes required for testers to succeed in an agile development environment and detail a pragmatic test automation strategy that uses intelligent analytics to ensure that test can keep pace with development and that you can make continuous delivery a reality in your organization.

Das Testen von Embedded Systemen wird mit zunehmender Komplexität erheblich schwerer.

Es stellen sich hierbei hauptsächlich drei Fragen: Erstens: Wie spezifiziert man das erwünschte oder unerwünschte Verhalten? Zweitens: Wie erzeugt man daraus Tests, die mit hoher Wahrscheinlichkeit fehlerhaftes Verhalten entdecken? Drittens: Wie findet man Fehler, die erst beim Einsatz des Systems auftreten, z.B. durch fehlerhafte Verwendung oder Umgebungsbedingungen?

In vielen Fällen kann man diese Fragen recht elegant durch den Einsatz von Contracts beantworten. Design by Contract (DbC) wurde entwickelt und eingeführt durch Bertrand Meyer. DbC erlaubt die Definition formaler Verträge für Schnittstellen und Verhalten von Software Komponenten.

Erweiterungen der Contract Methodik ermöglichen für nebenläufige Embedded Systeme die formale Spezifikation für allen Ebenen eines Systems. Aus den Contracts können mittels geeigneter Werkzeuge zum einen Tests generiert werden, die versuchen das korrekte Verhalten zu zeigen oder zu wiederlegen. Zum anderen können Software Monitore erzeugt werden, die während der Tests oder beim Einsatz eines Systems fehlerhaftes Verhalten zur Laufzeit entdecken, eindämmen und eine sehr exakte Analyse der Fehler ermöglichen.

Der Vortrag endet mit einer Live Demonstration einiger Contract Based Tests.

Was lernen die Zuhörer in dem Vortrag?

• Methodische Vorgehensweise zur formalen Spezifikation für Tests durch Contracts
• Ableitung von Tests und Laufzeitmonitoren aus den Contracts

Spätestens seit Mirai und seinen DDOS Angriffen ist das klar, dass Security ein wichtiger Aspekt für den embedded und insbesondere den IoT Bereich ist. Leider ist Security ein ziemlich umfangreiches Thema, das sich sowohl durch alle Phasen des Lebenszyklus als auch von der Hardware über die Systemebene bis zur Applikationsschicht durchzieht. Entsprechend vielfältig und komplex sind die technischen Aspekte, um alles sicher zu machen: Von der Validierung der Eingaben, über die Auswahl des passenden Kryptoalgorithmus bis zu den richtigen Kompilereinstellungen sollen Entwickler und Architekten alles wissen sowie richtig anwenden und (nebenbei?) auch noch die features implementieren. Wie soll man hier den Überblick behalten?

Die übliche Antwort ist: ein Softwareentwicklungsprozess, mit z.B. coding guidelines, statischer Codeanalyse oder review checklisten als typische Elemente. Im regulierten Umfeld ist deren Existenz oft normative Anforderung. Über deren Sinnhaftigkeit sagt das nichts. Wenn die Elemente gut aufeinander abgestimmt sind, dann können sie für Entwickler wirklich hilfreich sein. Wenn nicht, sind Codierungsrichtlinien oft nur Prozess-Leichen oder im Projektalltag schlicht ein ärgerliches Arbeitshindernis.

Im Vortrag geht es darum wie man das Zusammenspiel von security guidelines, Training für Entwickler, Werkzeuge zur Codeanalyse und Security Experten so gestalten kann, dass die tägliche Arbeit der Entwickler auch im heterogenen Umfeld tatsächlich unterstützt wird. Schließlich sollte ein embedded C++Entwickler z.B. auf type conversion vulnerabilities achten, während es dem am selben Projekt arbeitenden Could oder Web-Entwickler kaum interessiert. Diese sollten eher auf cross-site scripting usw. achten. Entsprechend ist es wichtig die Aufmerksamkeit der Entwickler und Architekten auf die für sie wichtigen Sicherheitsaspekte zu richten. Die eingesetzten Werkzeuge müssen diese Fokussierung unterstützen. Außerdem darf der Überblick über die security-relevanten Maßnahmen nicht irgendwann verloren gehen. So muss sichergestellt sein, dass in einem späteren service pack z.B. eine Compilerwarnung nicht einfach ersatzlos entfernt wird, wenn sie explizit als Maßnahme gegen buffer overflow Angriffen dient – egal wie sehr sie ggfs. stört. Entsprechend wichtig ist es den Zusammenhang zwischen konkrete Maßnahme bzw. Regel und ihrem Zweck für alle erkennbar zu definieren und auf dem aktuellen Stand zu halten. Zudem muss für den Entwickler klar sein wann, wo und wie die Implementierung erfolgen soll oder wie man eine fehlerhafte Umsetzung vermeidet. Zudem ist wichtig, wie die Regeln in der Praxis geprüft werden sollen und können. Hier kann der zielgerichtete Einsatz von Werkzeugen z.B. zur statischen Codeanalyse einen erheblichen Beitrag leisten oder eben auch die Entwicklung durch unnötige oder falsche Meldungen behindern.

Schließlich werden gerade für IoT gerade wegen Security in Zukunft Regulierungsmaßnahmen zunehmend diskutiert. Dann wird es wichtig – wie in bestehenden regulierten Bereichen auch heute – Maßnahmen zu dokumentieren. Insbesondere im Streitfall gilt es das Einhalten des Stands der Technik nachzuweisen. Dies kann nur gelingen, wenn man trotz der hohen Vielfalt an Einzelmaßnahmen wirklich den Überblick behält und diesen zudem nachweisen kann.

Einerseits gibt es viele gute Gründe eine Microservice-Architektur anzustreben, andererseits macht dieser Stil einige klassische QA-Prozesse schwieriger: Es gibt keinen großen Release-Kandidaten, der vor dem Live-Gang ausgiebig getestet werden könnte, kein zentrales Log-File, um nach Ursachen zu suchen und auch deutlich mehr als ein Team, dem man eventuelle Bugs zuweisen könnte. Statt dessen werden Services aktualisiert, während
Tests durchgeführt werden, es gibt genau so viele Log-Files wie Services und viele Teams, die ein Problem verursacht haben könnten.

Bei REWE digital haben wir als Antwort auf diese Herausforderungen einen QA-Ansatz gewählt, der vollständig durch die Teams getrieben wird. Wir haben eine Menge guter, aber auch schlechter Ideen an unserem Microservice Ökosystem ausprobiert. Sei es bei der Automatisierung von Tests, dem Monitoring von Services, dem Schreiben von Log-Files oder der Art wie wir mit Problemen (in Produktion) umgehen.

In meinem Vortrag werde ich einiger der besten und schlechtesten Maßnahmen erläutern und erklären, wie unser aktueller QA-Prozess (trotzdem) funktioniert.

Was lernen die Zuhörer in dem Vortrag?

Einige gute und einige schlechte Ideen, wie man in einem Microservice-Ökosystem Qualitätssicherung betreiben kann.

Mit der MDR ändert sich die Definition, was als Medizinprodukt betrachtet wird, sowie die (Höher-)Klassifizierung dieser Produkte. Die Produktgruppe der „automatischen externen Defibrillatoren“ ist dabei von der neuen Regel 22 betroffen. Zusammen mit den anderen Anforderungen der MDR hat dies Auswirkungen auf das Konformitätsbewertungsverfahren (scrutiny Verfahren), auf einige Geschäftsmodelle (OEM/PLM), auf die Marktüberwachung (PSUR, SSCP) und letztendlich auf die Produkt- und Unternehmensstrategie für den Umstieg von MDD zur MDR. Welche zusätzlichen Anforderungen aus überarbeiteten MEDDEV Empfehlungen, angepassten ZLG EK-Med Beschlüssen und weiteren nationalen Sonderverordnungen entstehen werden bleibt dabei als neues Risiko offen.

Der Tester ist tot, es lebe die Qualitätssicherung.

Im viel zitierten Scrum-Guide wird dem Team die Rolle "für die Qualität verantwortlich" zugeschrieben. Oft ist das der Grund warum viele meiner Kunden denken, dass die Tester nun nicht mehr gebraucht werden. Dabei ist das Testen immernoch unabdingbar.

Vor allem erfahrene Testspezialisten/Testspezialistinen können zur Qualität des Produkts sehr viel Beitragen in dem sie eine Brücke zwischen PO/Kunde und Entwickler stellen. Sie sprechen beide Sprachen, sowohl die des Kundens, weiss was dieser möchte, als auch die Technische des Programmierers. Sie können auf Schwachstellen im Programm als auch auf Usability-Anforderungen des Kundens hinweisen. Sie können Testinfrastruktur zur Verfügung stellen oder zumindest dafür sorgen, dass diese zur Verfügung stehen. Und ja, tatsächlich auch testen. Jede Testphase die dafür notwendig ist um die Qualität zu sichern, muss auch in der agilen Softwareentwicklung durchgeführt werden. Auch ist das Know-How der Tester notwendig um sicherzustellen, dass UserStories auch für sich testbar sind. und vieles Mehr

In diesem Vortrag möchte ich zeigen wie die Rolle des Tester in agilen Teams definiert und gelebt werden kann.

Was lernen die Zuhörer in dem Vortrag?

Welche Tätigkeiten können und sollen Tester in einem agilen Team durchführen um das ganze Team darin zu unterstützen die Qualität des Produkts zu steigern.

• Methoden zum Pairing von Tester und Entwickler
• als Übersetzer zwischen PO/Kunde/Fachbereich und Entwickler
• Verantwortlicher für Testinfrastruktur
• Risikomanagement

Das Layered-Blueprints-Denkmodell wurde entwickelt, damit PLT-Ingenieure selbst Verantwortung für die Security ihrer Systeme übernehmen, Security-Probleme und -Ziele definieren und verschiedene Security-Lösungen bewerten und in den Betrieb integrieren können.

Der Fokus liegt auf der technischen Analyse und Definition der sicherzustellenden Funktionalität. Ein Netzmodell reduziert zunächst die Netzwerkkomplexität auf die Security-relevanten Aspekte.

Für einen angemessenen Aufwand und klar definierte Schutzziele werden die funktionalen Anforderungen als Use-Cases beschrieben – immer aus Sicht der Automatisierungssystementwickler und -nutzer. Für jeden Anwendungsfall wird die erforderliche Netzwerkkommunikation analysiert.

Anschließend erfolgt die Risikoanalyse auf Basis von „Abuse Cases“. Hier können Ergebnisse einer Safety-Risikoanalyse synergetisch einfließen: Zusammen mit dem Partner TÜV Nord wurde ein Gesamtprozess für die Betrachtung von Safety- und Security-Risiken entwickelt.

Der Vortrag schildert reale Anwendungsbeispiele und gibt einen Ausblick, wie ein Datenmodell für eine maschinenlesbare Version (z.B. in AutomationML / OPC UA) des Denkmodells aussehen kann.

Was lernen die Zuhörer in dem Vortrag?

Die Zuhörer lernen ein Denkmodell kennen, welches PLT-Ingenieure dazu befähigt, selbst Verantwortung für die Security ihrer Systeme zu übernehmen. Mit dem vorgestellten Denkmodell können sie hinterher selbst Security-Lösungen strukturiert, technisch fundiert und pragmatisch entwickeln und hinterfragen.
Außerdem erfahren Zuhörer, wie sie synergetisch Ergebnisse und Denkansätze aus Safety-Analysen für Security verwenden können.

Als Consultant für Agiles Testen ist die Ausgangslage bei vielen Projekten vergleichbar: Bei der Einführung agiler Methoden wurde nicht an die Qualitätssicherung gedacht. Dabei bedeuten die kurzen Entwicklungszyklen und regelmäßig ausgelieferten Softwareversionen einen enormen Anstieg an Testaufwand; vor allem für Akzeptanz- und Regressionstest, die im Allgemeinen vor jeder Auslieferung durchgeführt werden. Bei langen Entwicklungs- bzw. Auslieferungszyklen (6 Monate oder mehr) lässt sich manuelles Testen noch rechtfertigen, besonders bei aufwendigen Test-Szenarien. Bei kurzen Entwicklungszyklen (beispielsweise 4 oder gar 2 Wochen) lässt sich der Test-Aufwand nur durch Automatisierung der Testfälle bewältigen.

Im meinem Vortrag beschreibe ich, wie wir Akzeptanz- und Regressionstests für die Software einer TV Set-Top-Box mehr und mehr automatisiert haben. Das Haupt-Augenmerk der Tests lag auf der Funktionalität des User Interfaces. Ich beschreibe die Ausgangslage und erkläre die Abweichung von Best-Practices erklärt werden. Anschließend zeige ich wie Testfälle mittels BDD leicht verständlich beschrieben und mit Confluence vereinheitlicht wurden. Weiterhin zeige ich wie wir BDD Testfälle mit Python und dem Framework Behave implementiert und ausgewertet haben und wie wir die Testausführung mit Jenkins gesteuert haben, eine Methode die für viele andere Testanwendungen nutzbar ist.

Falls noch Zeit bleibt, beschreibe ich abschließend wie wir die Testhardware für Tests des User Interfaces genutzt haben und wie das Page Object Model für die Testimplementierung angewendet haben.

Was lernen die Zuhörer in dem Vortrag?

• Tools (Stormtest setup vs bluetooth + framegrabber setup) und Methoden (Einsatz des Page Object Models) für visuelle Testanalysen
• Einsatz geeigneter Tools für die richtige Zielgruppe (komplizierte Tools für Ingenieure, einfache Tools für Nicht-Ingenieure)
• BDD Tools
• Herausforderungen und Probleme:
• Akzeptanz
• Kommunikation

Vorgestellt wird ein neuer Ansatz, der Testen mit Anforderungsanalyse, Modellierung, Code Generierung, Code Optimierung und Target Debugging in einem Prozess verbindet.

Der Vortrag erklärt die prinzipielle Methodik, die beteiligten Werkzeuge und welche Ergebnisse erzielt werden können.

Was lernen die Zuhörer in dem Vortrag?

Kennenlernen eines prinzipiellen Ansatzes, der Testen mit Anforderungsanalyse, Modellierung, Code Generierung, Code Optimierung und Target Debugging in einem Prozess verbindet und die Vor- und Nachteile der Lösung.

Die Prozesse für funktionale Sicherheit (Safety) und IT-Sicherheit (IT Security) werden seit über 25 Jahren entwickelt und sind gut ausgereift. Im Umfeld Automotive ist die Norm IEC 26262 „Road Vehicles – Functional Safety“ in 2018 überarbeitet erschienen und die Norm ISO 21434 „Road Vehicles – Cybersecurity Engineering“ als Commitee Draft verfügbar. Bei beiden Themen geht es grundsätzlich um Risikomanagement, der Unterschied steckt jedoch im Detail und sie beeinflussen sich in der Entwicklung gegenseitig. Deshalb werden erstmal die Unterschiede herausgearbeitet und die Prozesse gegenübergestellt, um dann die Vorgehensweisen in einer Synthese in den Systementwicklungsprozess zu integrieren. Für eingebettete Systeme muss dabei natürlich auch auf die besonderen Herausforderungen dort eingegangen werden.

Was lernen die Zuhörer in dem Vortrag?

Einen Ansatz, wie sich Security und Safety in der Entwicklung von eingebetten E/E-Systemen integrieren lassen.

Code Reviews sind ein häufiger Bestandteil der Definition of Done agiler Teams. Doch Feedback geben und annehmen will gelernt sein und muss für eine lösungsorientierte Teamkultur geübt werden, um konstruktiv mit Konflikten umgehen zu können. "Ja, aber" ist ein typisches Beispiel für einen Kommunikations-Fallstrick und schlechte Feedbackkultur, das sich In Code Reviews gerne in Dialogen der Art "Ja, aber ich hätte es anders gemacht oder fände es eleganter, wenn..." manifestiert. Wir wollen anhand konkreter Beispiele aus unserer Praxis aufzeigen, was gute Code Reviews ausmacht und an welchen Stellen ein moderierender oder vermittelnder Eingriff durch den Scrum Master notwendig ist. Dabei betrachten wir auch die psychologischen und gruppendynamischen Faktoren wie wertschätzendes Feedback oder das Johari-Fenster. Damit erklären wir, warum Reviews ein sensibles Thema sind und wie man die Effizienz von Reviews steigern und gleichzeitig die Teamkultur stetig weiterentwickeln kann.

Als limango 2007 mit nur zwei Entwicklern die Welt erobern will, sind schnell ein paar statische Seiten für den Internetauftritt zusammengeschraubt. Eine index.php hier, eine functions.php da – Code Qualität ist zuerst Nebensache.

Doch dann werden sie vom Erfolg eingeholt: jetzt skalieren, aber wie?
Auf einmal sitzt man in einem völlig überladenen Trabbi, soll schnell noch bei voller Fahrt den Reifen wechseln, und keiner weiß, warum die rote Kontrollleuchte blinkt!

Wie wurde aus dem kleinen Startup der heute auf Microservices basierende Shopping Club mit 18 Millionen Mitgliedern?
In dem Talk geht es darum, wie schnell Clean Code mit dem Wachstum eines Unternehmens wichtig wird, und wie wir bei limango heute dafür sorgen, dass die Clean Code Prinzipien ein fester Bestandteil im Team-Alltag sind.

In this presentation, we show how to build an automated software delivery pipeline, scalable to millions of lines of code, and with an optimal NULL release (the time it takes to rebuild and re validate the software under test with 1 line of code change). A novel approach called T(x) has been developed to automatically build and test applications whenever code changes are checked into the SCM system. The transitive closure of all changes is calculated, and an efficient change-based testing phase is started via an automated declarative Jenkins DevOps pipeline. Build improvements are also identified. The unit tests can be re-categorized as integration tests or software-hardware integration tests, through the efficient use of stubs and wrappers to intercept embedded target calls. Additionally, unit and integration tests can now be automatically generated directly from the software architecture visualization, and it is possible to enforce architecture intent through rules at build time. The implementation of the pipeline in Docker containers and across a Kubernetes topology is demonstrated. The approach has been validated and deployed at a large German Healthcare company - a real life case study is presented.

Das ist doch ein Spruch, den Eltern gerne mal ihren pubertierenden Töchtern entgegen schmettern. Aber zu oft möchten wir dies auch unseren Kollegen zu rufen.

Also wollen wir uns in diesem Vortrag mal die Frage stellen, wie sinnvoll oder böse Kommentare im Quellcode denn sind. Aber Vorsicht! Der Vortragende ist bei dem Thema voreingenommen, lässt aber gerne mit sich reden.

Zunächst soll betrachtet werden, welche Arten von Kommentaren es gibt.

Kommentare die...

• Code beschreiben
• Metadaten beinhalten
• Code deaktivieren (auskommentieren)
• visuell wahrgenommen werden (e.g. Ascii Art, Linien, Farbe)
• Emotionen vermitteln

Welche Probleme verursachen diese Kommentare bei zukünftigem Lesen und der weiteren Arbeit im Code?

Welche Kommentare sind tatsächlich wichtig?

Das alles wird unterlegt mit vielen Praxisbeispielen, manche zum Lachen, manche zum Weinen, aber alle zum Nachdenken.

Der effektive Einsatz der Web Development Tools ist sehr wichtig. Für PHP Entwickler umfasst das in erster Linie die IDE, das Terminal, Xdebug und Git.

In diesem Talk zeige ich den effektiven Einsatz von oh-my-zsh für eine schnelle Navigation im File-System mit dem Jump- und dem Z-Plugin. Dazu eine intelligente Kombination mit dem Autosuggestion- und dem History-Plugin. Dadurch kann man sehr schnell zwischen einzelnen Projekten wechseln und auch schnell Commands für die Ausführung von Tests, Builds, Updates oder Caches aufrufen und einsetzen.

Die IntelliJ IDE Palette umfasst neben PhPStorm auch zahlreiche andere vorkonfigurierte IDEs, wie z.B. WebStorm für den Schwerpunkt der Frontend Entwicklung. Dabei ist die Basisfunktionalität gleich. Alle Inhalte des Talks können so in jedem IntellJ Produkt verwendet werden. Konkrete Inhalte sind hier Live Templates, Multicursor und Refactoring.

Pick up any software tool brochure and the chances are that it will reference the kind of idealized V-model software development lifecycle illustrated in functional safety standards such as IEC 61508, ISO 26262 and IEC 62304. Whether following a V-model from such a standard or deploying a more fashionable Agile methodology, there is an underlying common principle that appropriate requirements must be available in an appropriately detailed form before programming work can commence.

But life isn’t always like that. So when a team within Renishaw, one of the world's leading engineering and scientific technology companies, were faced with the task of re-engineering their established RESOLUTE true-absolute, fine pitch optical encoder system to meet the demands of IEC 61508 SIL2, they had to adjust and enhance established best practice in order to bring the product development process to an efficient conclusion.

This presentation will outline the thinking that was followed in order to meet this aim, and how by deploying an embedded engineering tool chain for a functionally safe system as a tool kit to be selectively applied, Renishaw were able to complete the development of the functionally-safe RESOLUTE FS encoder in an efficient and timely manner.

Jedes Entwicklerteam weist eine eigene funktionierende Teamkultur auf. Die einzelnen Teammitglieder werden von unterschiedlichen Motiven getrieben. Je nach Zusammensetzung des Teams und der Motive der einzelnen Teammitglieder sollte die Einführung von Clean Code Prinzipien und Techniken individuell umgesetzt werden.
Um das passende Vorgehen für das betreffende Team zu gestalten müssen dazu verschiedene Fragen beantwortet werden.

• Wie findet man heraus, wie das Team aufgestellt ist?
• Gibt es Methoden um zu guten Ergebnissen bei der Analyse der Teamkultur zu gelangen?
• Wie verknüpfe ich die Einführung von Clean Code mit der Teamentwicklung?
• Welche Bedürfnisse, Ängste und Befindlichkeiten werden dadurch ggf. tangiert?
• Wie kann ein gemeinsames Qualitätsbewusstsein im Team entwickelt und verbessert werden?
• Welche Clean Code Prinzipien und Praktiken passen am besten zu den Werten des Teams? Welche nicht?

Diese und weitere Fragen haben wir uns gestellt. In verschiedenen Projekten bei sehr unterschiedlichen Kunden diversester Kulturen haben wir Teams bei ihrer Entwicklung unterstützt und Clean Code Methoden eingeführt. Unsere dabei gewonnenen Erkenntnisse möchten wir gerne mit den Zuhörern teilen und im Anschluss diskutieren.

Als eine neue Entwicklerin in einem Team vermuten Sie, dass Quellcode in Produktion zum Teil nicht verwendet wird. Automatisierte Tests existieren nicht, so dass der Nutzen des Quellcodes unklar ist. Auch die Kollegen können nicht weiterhelfen.

Was würden Sie machen? Eigentlich will man solchen Quellcode löschen, neigt aber aus Angst dazu, den Quellcode zu behalten. Wie oft haben Sie diesen Schritt gewagt? Haben Ihre Kollegen Ihnen die Rückendeckung im Team angeboten?

Es kann noch schlimmer werden. Eine Entwicklerin hat diesen Quellcode als Fundament für ein künftiges Feature vorausschauend geschrieben, um später Zeit zu sparen. Das Feature wird nicht zeitnah angefordert. Das Team benötigt heute mehr Zeit vorhandenen Code zu verstehen. Insgesamt steigen die Kosten, auch wenn die ursprüngliche Intention gut gemeint war.

Aus mehr als 50 Jahre Berufserfahrung in Softwareentwicklungsprojekten (eigene Erfahrungen aus zwei Jahrzehnten sowie Erfahrungen von Kollegen) haben wir eine Reihe von wiederholenden Probleme erlebt, die auf bestimmten Mustern zurückzuführen sind. Das Problem wird erst erkannt, wenn es bereits Akut ist. Im oben genannten Beispiel stehen Sie genau vor einem dieser Probleme.

Als professionelle SoftwareentwicklerIn bzw. „Clean Coder“ sollten solche Fehler vermieden werden. In diesem Vortrag stelle ich nicht nur die Probleme vor, sondern auch die Symptome, anhand dessen man rechtzeitig reagieren kann. Aus praktischen Erfahrungen stelle ich wirksame Lösungen vor. Zusätzlich gebe ich Einblicke in unsere misslungenen Versuche, die uns nicht weitergeholfen haben.

Product quality teams today are facing extraordinary challenges, and their importance is growing exponentially. With digitalization spreading like wildfire, product complexity in various industries is reaching a level never encountered before. Software maturity is becoming a key competence as Agile/DevOps strategies continue to accelerate the development lifecycle, forcing QA teams to spur and align their activities with the rest of the organization. In the meantime, safety-critical regulators are updating software standards and guidelines to focus on organizational and process excellence rather than a few "simple" compliance requirements on embedded software.

In this new environment, Quality Assurance teams are required to involve all stakeholders, achieve transparency in their activities, and support decisions by providing accurate and up-to-date quality information across the product development lifecycle.

Was lernen die Zuhörer in dem Vortrag?

In this talk, Intland Software's expert will explore how advanced practices such as automated testing, intelligent reports, and thorough fact-based compliance information contribute to development success in an Agile era. During this talk, we'll analyze the information needs of various roles and stakeholders, and how what best practices an Agile QA teams can use to support decisions at all levels of the organization.

Es ist geschafft: alle Entwickler haben sich zu Clean Code und Craftsmanship committed, das Manifest unterschrieben und tragen bunte Armbändchen. Die Qualität der Software steigt (was auch immer das jetzt genau bedeuten mag), in den Pull Requests finden keine Grundsatzdiskussionen mehr statt und dank Pair Programming gibt es weniger Wissensinseln.

Aber: trotz grüner Tests und fröhlicher Entwickler sind die Anwender noch immer nicht nicht zufrieden. Und warum sind unsere Entwicklungskosten noch immer so hoch und die Velocity zu niedrig? In diesem Vortrag, der auf Praxiserfahrung aus über 25 Jahren Beratung und Team-Coaching in der Software-Entwicklung basiert, erfahren Sie, wie Sie nicht nur Software richtig schreiben, sondern auch die richtige Software schreiben.

Wer Teams dazu bringen will Clean Code Prinzipien wirklich zu leben, muss Menschen überzeugen, motivieren und nicht zuletzt eine Menge Veränderungen anstoßen und begleiten.

(Lern)Spiele, auch Agile oder Serious Games, können dabei einen wertvollen Beitrag leisten: Sie lassen Menschen in kurzer Zeit wertvolle Erfahrungen machen, setzen gezielt Impulse und können ungeahnte Kreativität freisetzen. Und nicht zuletzt machen sie eine Menge Spaß!

Neugierig geworden? Dann kommt am 3.7. in unseren „Games Room“! Dort könnt ihr zusammen mit Claudia Simsek-Graf und Björn Meschede verschiedene Spiele kennenlernen, ausprobieren und das Ganze gleich reflektieren.

Welche Möglichkeiten habe ich, ein überlastetes System bezüglich Laufzeit zu optimieren? Wie plane ich in einer frühen Projektphase das Timing meiner Software? Und wie kann ich es im weiteren Projektverlauf automatisiert überwachen, gegebenenfalls über die Entwicklung hinaus, im Feld, in der Serie?

Der Vortrag stellt verschiedene Analysemöglichkeiten wie z.B. statische Codeanalyse, Tracing, Simulation oder Schedulinganalyse vor und zeigt deren jeweiligen Anwendungsgebiete sowie Vor- und Nachteile auf. Beispiele aus dem Automobilbereich unterstreichen die Praxisrelevanz, beschränken die Gültigkeit des Vortrags aber nicht auf diesen Bereich. Vielmehr sind die Inhalte auf andere Domänen übertragbar.

Ein Blick auf die Besonderheiten, die bei Multicoresystemen und POSIX-basierten Projekten eine Rolle spielen, rundet den Vortrag ab.

Was lernen die Zuhörer in dem Vortrag?

Laufzeitprobleme bei der Software erkennen, beheben und im besten Fall vermeiden.

Der fundamentale Testprozess nach Lehrbuch ist in der Realität, insbesondere im Embedded Umfeld, komplexer zu implementieren als die Theorie zunächst vermuten lässt. Werden Zeit und Ressourcen knapp, ist der Test häufig das Erste, was gekürzt wird – häufig mit dementsprechenden Qualitätseinbußen. Der Test wird erst deutlich später als geplant in die Entwicklung mit einbezogen oder das Konzept der Testautomatisierung stellt sich auf Dauer als weniger nachhaltig heraus als gedacht. Als Dienstleister, welcher unter anderem Embedded Software für verschiedenste Bereiche im Maschinenbau bis hin zur Sicherheits- oder Medizintechnik entwickelt, haben wir in der Qualitätssicherung bereits ein breites Band an Erfahrungen im manuellen und automatisierten Test dafür gewinnen können. Der Vortrag beinhaltet daher unsere „Lessons Learned“ und daraus entwickelten Best Practices oder zumindest Notlösungen für verschiedene Stufen des Test- und Entwicklungsprozesses, um Situationen wie die zuvor beispielhaft aufgeführten zu bewältigen. In diesem Kontext stellen wir ein Praxisbeispiel zum Thema Testautomatisierung von Embedded Software, basierend auf vorherigen Erfahrungen, vor.

Was lernen die Zuhörer in dem Vortrag?

Erfahrungsbericht/Best Practices

Der Markt rund um die umfassende Vernetzung von Autos, Häusern und Alltagsgegenständen sowie die Digitalisierung der Industrie, explodiert. Die steigende Komplexität der Systeme durch die zunehmende Vernetzung und gleichzeitig immer kürzer werdende Releases, stellen die bisherigen Entwicklungsprozesse in Frage. Unternehmen müssen ihre Abläufe so ausrichten, dass sie Releases schneller und qualitativ hochwertiger ausliefern können. Das Ziel, langfristig stabile und fehlerfreie End-to-End-Services zur Verfügung zu stellen, wird zur Herausforderung. Die Qualitätssicherung, insbesondere der Softwaretest, hat zunehmend Schwierigkeiten sicher zu stellen, dass die versprochene Funktionalität in der geforderten Qualität geliefert werden kann. Um Gesamtsysteme durchgehend auf ihre Funktionalität zu überprüfen, müssen gleichzeitig alle Technologien und Schnittstellen in einem Durchlauf und in Verbindung zueinander getestet werden. Auch lineare Abläufe reichen nicht mehr aus – die große Menge an anfallenden Tests erfordert einen parallelen Testablauf. Die Branchen, wie Industrie 4.0, Smart Home und Connected Car sind in besonderem Maße davon betroffen. Doch wie können vielschichtige Workflows realitätsgetreu abgebildet werden? Wie kann eine Automatisierung dieser Prozesse erfolgen, um eine hohe Softwarequalität auch bei immer kürzer werdenden Releasezyklen zu garantieren?

Der Vortrag skizziert die Herausforderungen aus Sicht des Softwaretests anhand von Bei-spielen aus verschiedenen Branchen. Zunächst werden exemplarisch die wichtigsten Problemstellungen, ihre Ursachen und deren Auswirkungen betrachtet. Basierend auf dieser Betrachtung wird anschließend ein Schritt für Schritt Vorgehensmodell erstellt, wie der Softwaretest die zukünftigen Anforderungen abdecken kann und welche Möglichkeiten es gibt, komplexe Gesamtsysteme unter Einbeziehung fehlender Komponenten zu testen. Zudem wird der Frage nachgegangen, wie solche Testszenarien in die bestehende IT-Infrastruktur integriert werden können, um einen vollautomatisierten End-to-End-Test zu ermöglichen, ohne die komplette Entwicklungsumgebung umstellen zu müssen.

Was lernen die Zuhörer in dem Vortrag?

Anhand realer Beispiele wird aufgeführt, wie ein End-to-End Test aufgebaut sein kann, so dass Backends, Frontends und mobile Geräte gemeinsam in einem Funktionstest überprüft werden können. Die Zuhörer erfähren wie von verschiedenen Standorten auf einer gemeinsamen Testumgebung in der Cloud gearbeitet und so Tests und Testabläufe unternehmensweit zur Verfügung gestellt werden können.

Eine Zertifizierung sicherheitskritischer Systeme erfordert umfangreiche und normgerechte Tests aller Funktionalitäten eines solchen Systems. Zeit und Kosten der Zertifizierung können durch den Einsatz eines praxisbewährten Testprozesses erheblich reduziert werden. Die erforderlichen Testdokumente werden dabei automatisch auf der Basis der Testergebnisse für die einzelnen System-Anforderungen erzeugt.

Die Präsentation beschreibt einen strukturierten Testprozess, der die Verlinkung von Anforderungen mit den erstellten Testartefakten sowie die anschließende Nachweisführung und Reporting ermöglicht. Anhand eines erfolgreich durchgeführten Testprogramms einer Flugzeugkomponente wird die Testmethode, der schrittweise Prozess sowie die verfügbare Werkzeugunterstützung und das damit mögliche Einsparungspotential vorgestellt.

Tendenziell steigt der Testaufwand und -Kosten bei der Realisierung von Kleinserien durch wachsende Komplexität, Funktionalität und Qualitätsanforderungen.

Die Testautomatisierung im Entwicklungslabor und in Produktion für Testgeräte mit LXI- Standard (Oscilloscope, Analoger Waveform Generator, Signal-, Power- und Protocol Analyzer) verringert Testengpässe, beschleunigt Test- und Entwicklungszeiten, reduziert Testwiederholungen beim Upscaling vom Prototyp zur Kleinserienproduktion mit optimierter Geräteauslastung.

Mit geringem Zeitaufwand für Testgenerierung, Testdokumentation und Implementierung der Testinhalte via Testsoftware TestC und Minitestsystems auf Basis eines modifizierten Raspberry PI können aus eine Vielzahl aktuell noch händischer Labor- und Produktionstests mit den verschiedenen Laborinstrumenten in übertragbare, verlässliche und wiederverwendbare Automatisierungstests zum Qualitäts- und Funktionsnachweis umgewandelt werden.

Was lernen die Zuhörer in dem Vortrag?

Möglichkeiten und Nutzen der kostengünstigen Automatisierung von Testequipment mittels Minitestsystem und Testsoftware und industrielle Einsatzoptionen des Raspberry PI als Testsystem gezeigt am Beispiel von Regressions-Tests für Steuermodule mit Power Analyzer.

Wie testen Sie? Nach der letzten Umfrage der Website www.softwaretest-umfrage.de in 2016 testen die meisten der deutschen Unternehmen ihre Software mit nachgelagerten Methoden. Bedeutet, erst baut ein Entwickler lustige Fehler in den Code ein. Dann haben die Tester etwas zu tun und Spaß beim Finden. Aber ist dieses Spiel, erst Fehler im Code einbauen um sie anschließend per Qualitätssicherung zu finden, nicht unnütz teuer? Ja wie, das machen doch alle so - werden die meisten jetzt denken.

Aber betrachten wir es mal aus einem anderen Winkel. Dieses Vorgehen ist in etwa so als würden Sie jeden Tag zum Arzt gehen um sicherzustellen, dass Sie gesund sind. Also würden Sie sich niemals Hände waschen und auch nicht warm anziehen, wenn es draußen kalt ist. Warum auch, Sie werden ja jeden Tag untersucht.

Oder leben Sie in einer agilen Familie? Das heißt ein Familienmitglied ist praktischerweise Arzt? Dieser würde dann nach jeder ausgeübten Tätigkeit einen kompletten Körper-Regressionstest durchführen. Und wenn dann eine Abweichung von der Normalfunktion entdeckt würde, würden Sie direkt an Ort und Stelle behandelt werden. Klingt nicht wirklich realistisch!

Ist es nicht sinnvoller die Fehler schon im Entstehen zu verhindern? Ist denn „da draußen“ nicht etwas, das uns hilft Fehler zu verhindern? Quasi die dicken Pullis gegen die Bugs?

Doch, denn es gibt auch Wasser und Seife sowie Schal und Mütze für den Entwicklungsprozess. Dieses alte Hausmittel nennt sich „konstruktive Qualitätssicherung“.

Georg Haupt stellt Ihnen einige Methoden vor um Fehler schon beim Entstehen zu erkennen, zu verhindern oder noch unerkannte Fehler aufzudecken.

Dann können Sie, nur bekleidet mit einem T-Shirt, auch im Winter ganz beruhigt coden!

Was lernen die Zuhörer in dem Vortrag?

Methoden um vorzeitig Fehler schon im Entstehen zu verhindern.

• Qualitätsoptimierung mit Eventstorming
• Codeverbesserung mit TestCaseReviews
• Prozessverbesserung mit Fehlerworkshops

Im Bereich der Eingebetteten Systeme nehmen die Funktionen und damit auch die Zahl der Steuergeräte bzw. smarten Aktuatoren immer weiter zu. Zusätzlich werden die Steuergeräte mehr und mehr in die Außenwelt eingebunden, also mit ihr verknüpft. Diese Verbindung zur Außenwelt erfolgt dabei über unterschiedlichste Sensoren und Aktoren. Bisher kamen bei den Sensoren Schnittstellen mit analogen - bzw. PWM-Signalen zum Einsatz. Viele Sensoren haben heute digitale Schnittstellen, wie zum Beispiel Serial Peripheral Interface (SPI), Peripheral Sensor Interface 5 (PSI5) oder Single Edge Nibble Transmission (SENT). Viele der durch Sensoren erfassten Werte dienen sicherheitskritischen Funktionen. Dies erfordert eine tief gehende Absicherung der Verarbeitung der Sensordaten sowie der Umsetzung der Fehlererkennungsmechanismen. Dies ist mit Einsatz realer Sensoren nicht vollständig möglich, da diese keine gezielte Einbringung spezifischer Fehler ermöglichen. Daher ist eine Simulation der Sensoren, genauer der Kommunikationsprotokolle der Sensoren, mit der Möglichkeit zum Einbringen spezifischer Fehler notwendig. Diese Simulation muss echtzeitfähig im Bezug auf das Verhalten des Sensors, aber auch in Bezug auf die Fehlerinjektion sein, um Fehlererkennungszeiten testen zu können. Weiterhin ist es nötig die Simulation in verschiedene Testsysteme, wie zum Beispiel Hardware in the Loop-Testsysteme oder Testsysteme am Entwicklerarbeitsplatz, zu integrieren.

Was lernen die Zuhörer in dem Vortrag?

Dieser Beitrag zeigt die Komplexität moderner Sensoren und ihrer digitalen Schnittstellen auf. Es werden dabei die Herausforderungen für die Entwicklung, aber vor allem für den Test dargestellt. Des Weiteren wird aufgezeigt, wie eine Emulation der Sensoren bzw. deren Protokolle in Verbindung mit Testverfahren, wie dem Hardware in the Loop-Test, eine weitreichende Absicherung, auch sicherheitskritischer Funktionen, ermöglicht.

Stellen wir uns einen Tester in einem typischen Software-Projekt vor: Das Release-Datum nähert sich, eine Kollegin aus dem Test-Team muss in einem anderen Projekt unterstützen und schon die Anforderungen wurden unter Zeitdruck aufgeschrieben. Das Test-Team steht vor der Aufgabe, unter diesen Bedingungen noch eine möglichst vollständige Test-Suite zu liefern. Ein für manchen überraschender Vorschlag ist, in einer solchen Situation Testmodelle aufzustellen und daraus Tests zu erzeugen. Aber sind Modelle nicht schwergewichtig und fressen Zeit anstatt sie zu sparen?

Wir stellen fest, dass sich mit Hilfe der leichtgewichtigen Modelle (Prozessdiagrammen und Ursache-Wirkungs-Diagrammen) der Aufwand in Grenzen hält und wir schnell zu Ergebnissen kommen. Unsere Erfahrung ist außerdem: Häufig ist das Ergebnis nicht mehr, sondern weniger Testfälle, dafür aber die richtigen! In diesem Vortrag berichten wir von unseren Erfahrungen beim Einsatz der Methode und stellen außerdem das Open-Source Werkzeug Specmate vor, dass wir entwickeln und auch selbst einsetzen.

Was lernen die Zuhörer in dem Vortrag?

• Wie sieht leichtgewichtige Modellierung aus?
• Was ist das Open-Source Werkzeug Specmate und wie funktionniert es?
• Welche Erfahrungen beim Einsatz gibt es?
• Wie weit kann man die Automtisierung treiben - kann man z.B. Tests direkt aus textuellen Anforderungen generieren?

Robert C. Martin hat den Begriff „Clean Code“ in seinem gleichnamigen Buch für die Software Entwicklung geprägt. Doch was ist sauberer Code und was hat dieser mit der Wartbarkeit von Software zu tun? Im Vortrag wird an vielen Beispielen praxisnah dargestellt, wie bereits kleine Verbesserungen der „Code Sauberkeit“ sehr positive Auswirkungen auf die Wartbarkeit Ihrer Software haben können. Anhand von Beispielen aus über 15 Jahren Projekterfahrung lernen Sie Techniken kennen, die Sie noch heute in Ihrem Code einsetzen können.

Tool-basierte statische Codeanalyse hat sich als Standardverfahren der Softwareentwicklung etabliert. Sie ermöglicht einen hocheffizienten Entwicklungsprozess durch automatische Prüfung des Codes nach einer Vielzahl von Kriterien. Hierzu zählen nicht nur die Prüfung von Codierrichtlinien, sondern auch tiefgehende semantische Analysen.

Aufgrund der Implementierungskomplexität stellt der Einsatz statischer Analysen auf Betriebssystemcode besondere Herausforderungen. PikeOS ist ein Echtzeitbetriebssystem, das in hochsicherheitskritischen Anwendungen eingesetzt wird. Aufgrund zunehmender Kommunikationsanforderungen spielen Security-Anforderungen eine immer größere Rolle. Um diesen Anforderungen zu genügen, wurde ein massgenschneiderter Satz von Codierrichtlinien auf Basis von MISRA C:2012, CERT-C und CWE entwickelt. Darüber hinaus wurde ein Konzept zur sicheren statischen Analyse der Betriebsystemschicht unter Verwendung des statischen Analysators Astrée entwickelt, mit dem die Abwesenheit von Laufzeitfehlern in kritischen Betriebssystemfunktionen sichergestellt werden kann. Mit Hilfe der Taint-Analyse von Astrée wurde zudem eine Erkennungs von Spectre-Verwundbarkeiten realisiert, die Vorkommen von Spectre v1, Spectre v1.1 und SplitSpectre-Verwundbarkeiten im Code meldet. Auf ähnliche Weise können auch funktionale Security-Anforderungen geprüft werden und Datenkorruptionsanalysen durchgeführt werden. Im Vortrag warden alle genannten Punkte vorstellt und experimentell belegt.

Was lernen die Zuhörer in dem Vortrag?

• Safety- und Security-Anforderungen an moderne Echtzeitbetriebssysteme
• Überblick über aktuelle Codierrichtlinien, insbesondere MISRA C:2012, CERT-C, CWE
• Vorgehensweise und Kriterien zum Tailoring der Codierrichtlinien-Standards an eignene Anforderungen
• Funktionsweise sicherer statischer Analyse und Anwendung auf Betriebssystemcode
• Funktionsweise von Taint-Analyse
• Funktionsweise von SPECTRE und entsprechender Code-Verwundbarkeiten
• Statische Analyse zur Erkennung von SPECTRE-Verwundbarkeiten

Der Begriff White-Box-Test bezeichnet eine Methode des Software-Tests, bei der die Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt werden. Gängige Qualitätskriterien in White Box tests sind z.B. die Ausführung aller Zeilen im Quellcode, die Ausführung aller Anweisungen, die Betrachtung aller Pfade durch ein Modul usw. In diesem Vortrag werden die Grundlagen der Codabdeckungsanalyse vermittelt und darüber hinaus gezeigt wie Modul-, Integrations- und System Tests aber auch Änderunsgsbasierte Testfallausführung und die Code Injektion die Qualität in der SW-Entwicklung signifikant steigert.

Was lernen die Zuhörer in dem Vortrag?

Den Zuhörern werden die Grundlagen und Vorteile von White Box tests vermittelt die die Grundlage für eine qualitativ hochwertige Software darstellt.

Usability can make the difference between pleasure and frustration. What technology can make easy will get done easily. That’s one of the reasons why we provide the most usable model-based verification solutions for safety related applications on the market – easy to learn and easy to use.

EverTest® software is an easy to use verification framework for safety related applications, enabling function developers to leverage advantages of model-based verification. You can automatically integrate existing C-Code into Simulink, generate requirements-based test cases and perform the unit testing with full support of all required methods for ISO 26262 compliance.

EverTest® software enables test-driven development of dynamic systems with C-Code, MATLAB®, Simulink® and Stateflow®. It supports MIL, SIL and PIL verification with manually developed or automatically generated external code.

EverTest® software generates an easy to review verification report with a requirements matrix, the coverage analysis results, the boundary values analysis results, the test cases with all the data, the verification results and the interactive plots.

Was lernen die Zuhörer in dem Vortrag?

Simple unit testing and reporting.

In unseren Projekten beobachten wir immer eine gewisse Unsicherheit bzgl. des Einsatzes modellbasierter Testverfahren. Dies beginnt schon mit der Definition. Die einen denken bei MBT sofort an MATLAB/Simulink-Modelle. Die anderen wenden zustandsbasierte Testentwurfsverfahren an, ohne dies explizit modellbasierten Test (MBT) zu nennen. Wieder andere nutzen Ablaufdiagramme für den System- und Abnahmetest.

Neben den vielfältigen Ausprägungen gibt es auch hinsichtlich der zu erwartenden Vor- und Nachteile immer wieder Fragen. Insbesondere wenn es um eine durchgängige Automatisierung der Testfallerstellung und Testdurchführung geht, sind die Erwartung oft sehr hoch gesteckt. Hier stößt MBT auch schon mal an seine Grenzen. Andererseits eröffnet der Ansatz Horizonte, die ohne MBT gar nicht sichtbar wären:

• Reduktion der Komplexität, welche dadurch überhaupt erst beherrschbar wird,
• automatische Erstellung und Pflege der Testfälle,
• Visualisierung von Zusammenhängen zwischen verschiedenen Anforderungen,
• verbesserte Kommunikation und damit auch verbesserte Qualität (sowohl der Anforderungen als auch der Tests),
• Messbarkeit der Testabdeckung
• u.v.a.m.

Falls Sie mit dem Gedanken spielen, MBT bei sich einzusetzen oder bereits erste Erfahrungen gemacht haben, sind Sie in diesem Intensivcoaching richtig. Bringen Sie Ihre Fragen mit. Gemeinsam werden wir klären, welcher der vielen MBT-Ansätze sich in Ihrem Zusammenhang anbietet und worauf Sie unseres Erachtens den Fokus legen sollten.

Heutzutage sind agile Methoden in Softwareentwicklungsprojekten nicht mehr wegzudenken. Häufig werde sie eingesetzt, nun ja, damit sie eben eingesetzt werden und manchmal um schnell auf einen sich verändernden Markt reagieren zu können.

Doch welcher Vorteil agiler Methoden bleibt erhalten, wenn sich die Software um ein Vielfaches langsamer verändern lässt, als die Anforderungen am Markt? Und wie kann erreicht werden, dass die Software auch noch nach Jahren erweiterbar bleibt?

Diese Intensivcoaching Session bietet die Plattform für Fragen aus den Bereichen:

• CCD & agile Softwareentwicklung
• CCD und die Auswirkungen auf die Entwicklungskosten
• Seiteneffekte von CCD
• Einführung von CCD in Legacy Code
• CCD in der Praxis