TITELTHEMA: Quality Driven DevOps · YouTube 28% Facebook 12% Unternehmensblogs 78% 60% 48h...

Folgen Sie uns auf Twitter und Facebook.

twitter.com/SQMagazin facebook.com/SQforyou ISSN 2367-3516

PLUS: Die aktuellen Schulungs-termine für 2017

IM GESPRÄCH:

mit dem DevOps- ExpertenUwe Friedrichsen

TITELTHEMA:

Quality Driven DevOps

Ausgabe 42 | März 2017

1.9MILLIARDENMENSCHEN WELTWEIT NUTZEN SOCIAL MEDIA

1 MINUTE im Internet

DER GRÖSSTEN DEUTSCHEN MARKEN NUTZEN AKTIV SOCIAL MEDIA

ÜBER 78% DER DEUTSCHEN

INTERNETNUTZER VERWENDEN

SOCIAL MEDIA NETZWERKE

39%Twitter

37% YouTube

28% Facebook

12% Unternehmensblogs

78%

60%

48hVideomaterial auf YouTube geladen

3.000 Fotos auf Flickr geladen

685.000Facebook-Inhalte geteilt

100.000 neue Tweets

2+ Mio.Suchanfragen auf Google

SOCIAL IMPACTTHE STARTUP BOOSTER

Supporting startups in the development

of their employee’s skills

QUALITY IS THEBEST BUSINESS PLAN

„

High5

high5startups.com

Join High5´s breakfast TV live from the SXSW

March 10-13, 2017 | 9 AM (CST)

Meet the experts and follow the trends of the world´s largest digital and creative gathering via High5´s breakfast TV!

©Rawpixel.com_shutterstock.com

Europa droht auseinanderzubrechen, das be-hauptet zumindest US-Präsident Donald Trump. Und es gibt einige, die seine Ansicht teilen. Grie-chenland-Fiasko, Brexit, das Erstarken der rechten Parteien in Holland, Frankreich und Polen – was wird wohl als nächstes kommen?

Deutschland, so schien es, war bis vor kurzem eine sichere, feste Burg inmitten von Ungewissheit und Destabilität. Doch dann kam Herr Schulz. Seither geht die German Angst wieder um. In den Medien zeichnet der designierte SPD-Kanzlerkandidat ein düsteres Bild von Deutschland: ungerecht und un-sozial gehe es zu. Man müsste meinen, die ersten Barrikadenkämpfe zwischen der geknechteten Unterschicht und den gierigen Oberetagen-Mana-gern stünden kurz bevor.

Was hier mit Bezug auf Herrn Schulz mehr als überspitzt formuliert ist, erweckt den Eindruck, Deutschland taumle angesichts sozialer und wirt-schaftlicher Ungerechtigkeit langsam aber sicher dem Abgrund entgegen. Dabei geht es Deutsch-land so gut wie nie zuvor. „Kaum ein anderer In-dustriestaat hat sich mit Blick auf die eigene Zu-kunftsfähigkeit in den vergangenen zehn Jahren so positiv entwickelt“, ergibt eine Studie der Bertels-mann-Stiftung, die die Regierungsführung in den entwickelten Industrieländern bewertet. Mit seiner Kritik an der Agenda 2010 versucht Schulz einen anderen Eindruck zu erwecken – und verwandelt sich damit immer mehr zu einem Abziehbild von Donald Trump, jedenfalls in den Methoden.

Das Klagen und Schimpfen von Herrn Schulz för-dert nicht gerade den Optimismus und die Stabili-tät unseres Landes. Genau das Gegenteil von Pes-simismus – eine positive Einstellung zur Zukunft – ist das, was wir brauchen, um erfolgreich zu sein. Damit meine ich nicht, wir sollten alles schön re-den. Aber wir sollten uns zumindest fragen, ob die Dinge wirklich so schlecht sind, wie sie andere

Editorial

3 Ausgabe 42 | März 2017

malen. Wir stehen nicht nur vor einer sozialen He-rausforderung, sondern auch vor der Frage, wie sich angesichts einer voranschreitenden Digita-lisierung unsere Arbeit, Produktion, Kommunika- tion, unsere (ethischen) Werte und unsere Gesell-schaft verändern werden. Das allein ruft schon eine gewisse Unsicherheit hervor. Deshalb ist ein positives Denken so wichtig. Keine Neiddebatte.

Herr Schulz und seine Forderungen mögen der Stimmung in der SPD zuträglich sein – doch sie reden das klein, was unser Land bisher stark ge-macht hat. In Deutschland geht die Angst um.

Dabei bräuchten wir mehr Mutmacher, wie den zukünftigen Bundespräsidenten Frank-Walter Steinmeier.

Herzlichst

Ihr Stephan GoerickeASQF-Hauptgeschäftsführer

Es geht ein Gespenst um in Deutschland…

Was ist Ihre Meinung oder Erfahrung? Teilen Sie mir Ihre Gedanken mit! Ich freue mich auf Ihre Zuschrift und einen anregenden Austausch zu den verschiedensten Themen. [email protected]

Ausgabe 41 | Dezember 2016 4ASQF NEWS

5 ASQF-NEWS

TITELTHEMA

8 Quality Driven DevOps

16 DevOps – Ein Geschenk für Software-Produktmanager

34 Hohe Qualität durch eine testgetriebene Entwicklung

14 IM GESPRÄCH mit DevOps-Experte Uwe Friedrichsen

28 GERMANY GOES SXSW

32 iSQI-NEWS

Inhalt

DevOpsQuality-Driven

8

28

14

GERMANY GOES SXSWMIT EINER EIGENEN DELEGATION IST DEUTSCHLAND AUCH IN

DIESEM JAHR AUF DER SXSW IN AUSTIN/TEXAS PRÄSENT.

DevOpsEine Revolution im Kopf

Der ASQF, wichtigstes Netzwerk von Software-Qualitätsexperten im deutschsprachigen Raum, wurde 1996 im fränkischen Erlangen gegründet. Seitdem gestaltet der Arbeitskreis maßgeblich die Entwicklung und Sicherung von Software- bzw. System-Qualität. Als Repräsentant und Stimme der Software-Branche befindet sich der Verband im Dialog mit Entscheidungsträgern in Wirtschaft und Politik. Über die Jahre hat der Verein wesentlich dazu beigetragen, die Verfahren im Bereich Qualitäts-sicherung zu definieren und weiterzuentwickeln.Auch für Fortbildung eintretend, fördert der ASQF eine international einheitliche Aus- und Weiterbildung von IT-Fachkräften – Stichwort „Certified Tester“, welcher in Deutschland von einer Arbeitsgruppe des ASQF entwickelt und in die Industrie gebracht worden ist. Wesentliche Beiträge zur Etablierung von z.B. Spice® und INTACS™ wurden vom ASQF initiiert und umge-setzt. Es werden stetig weiter Vorschläge erarbeitet, die den neuen Anforderungen der Digitalisierung Rechnung tragen, aktuell in der Arbeitsgruppe zum Thema Internet of Things. Diese arbeitet derzeit an einem Zertifizierungsstandard für das Quality Engineering für das Internet der Dinge. Das Herz des ASQF sind weiterhin seine Fach-gruppen und der inhaltliche Austausch in den Netzwerken. So werden leistungsstarke Start-Ups, Mittelständler, Global Player und Hochschu-leinrichtungen miteinander verbunden.

Feier zum 20-jährigen Jubiläum

Im Dezember 2016 feierte der ASQF e.V. sein 20-jähriges Bestehen mit einem festlichen Emp-fang im CINIQ Center Berlin. Mit Blick auf die Zukunft sagte ASQF-Präsidentin Prof. Dr. Ina Schieferdecker: „Nach wie vor ist Software-Qualität für viele Menschen ein schwer greifbares Thema. Hinsichtlich Automatisierung und Digitalisierung müssen wir ihnen Antwor-ten geben, wie bestimmte Prozesse, z.B. beim autonomen Fahren, abgesichert werden können. Neue Technologien werden nur akzeptiert, wenn ihnen die Menschen vertrauen. Wir müssen da-her unser Bestes tun, um die Gemeinschaft auf dem Weg der Digitalisierung mitzunehmen.“Stephan Goericke, Hauptgeschäftsführer des ASQF, stimmte in seiner Begrüßungsrede zu: „Wir haben immer Themen gesetzt und den Weg nach vorn gezeigt. Nun müssen wir darüber dis-kutieren, wie die nächsten 20 Jahre aussehen sollen.“

Ehrenpreis verliehen

Im Rahmen der Jubiläumsfeier wurde Prof. Dr. Bernd Hindel für sein Lebenswerk mit dem Deut-schen Preis für Software-Qualität ausgezeichnet. Prof. Dr. Bernd Hindel ist ASQF-Gründungsmit-glied und Präsident der ersten Stunde. Er nahm den Ehrenpreis auf der Veranstaltung in Berlin persönlich entgegen. In seiner Laudatio verdeut-lichte Dr. Walter Wintersteiger, Ehren-Präsident der Österreichischen Vereinigung für Software-Qualität, warum Prof. Dr. Bernd Hindel in sei-nen Augen die „Inkarnation von ganzheitlicher Software-Qualitätssicherung“ ist. Prof. Dr. Bernd Hindel, Gründer der Method Park Unternehmens-gruppe, hat die Entstehung, Etablierung und Strukturierung des Berufsstandes des Software-Testers im deutschsprachigen Raum maßgeblich beeinflusst und mitgetragen. Dies wurde von Dr. Walter Wintersteiger betont, der ausführte: „Bernd Hindel ist es im Wesentlichen zu ver-danken, dass es ein Branchennetzwerk wie den ASQF nur im deutschsprachigen Raum gibt. Mit dem Satz „Wir machen das jetzt“, setzte er um, was sich viele wünschten, aber nicht zutrauten: Die Gründung eines Netzwerkes, in dem sich die Tester-Community austauschen konnte.“

Das Expertennetzwerk für Software-QualitätASQF

Nach wie vor ist Software-Qualität für viele Menschen ein schwer greif-bares Thema.

ASQF-Präsidentin Prof. Dr. Ina Schieferdecker

Prof. Dr. Bernd Hindel nimmt den Deutschen Preis für Software-Qualität für sein Lebenswerk von Stephan Goericke entgegen.

ASQF NEWS5

Ausgabe 42 | März 2017 6

Während einer Absolventenfeier an der Friedrich-Alexander-Universität Erlangen-Nürnberg wurde Anfang Fe-bruar der ASQF-Förderpreis an Mar-cel Busch verliehen. Die mit 500 Euro dotierte Auszeichnung wurde dieses Mal von der infoteam Software AG gesponsert. ASQF-Vizepräsident Nor-bert Kastner überreichte zusammen mit Michael Strobel von der infoteam Software AG die Auszeichnung.Marcel Busch widmete sich in sei-ner Abschlussarbeit, betreut durch Dr. Tilo Müller und Dipl.-Inf. Myko-la Protsenko, dem Thema „Android Application Protection Reinforced by Off-Device Ahead of Time Compila-tion“. Lob hierfür gab es unter ande-rem von der Leitung des Lehrstuhls Informatik an der FAU. „Herr Busch entwickelte einen innovativen Ansatz zum Schutz von mobile Android Apps, der diese zuverlässig gegen Reverse-Engineering-Angriffe auf Bytecode-Ebene härtet. Herr Busch hat diesen Ansatz sehr selbstständig und fach-lich hervorragend realisiert und damit einerseits einen Beitrag zum Schutz hochqualitativer Software vor dem

Kopieren geleistet. Andererseits ist die sorgfältig ausgearbeitete Lösung auch beispielhaft für Software mit ho-her Qualität“, würdigte Prof. Dr. Frei-ling, Leiter des Lehrstuhls Informatik 1 (IT-Sicherheitsinfrastrukturen), die Arbeit des Preisträgers.Der ASQF e.V., größtes Experten-netzwerk für Software-Qualität im deutschsprachigen Raum, vergibt seit 2006 seinen Förderpreis an junge Ta-lente. Er wird einmal im Semester an Studenten und/oder Absolventen ver-liehen und würdigt besonders gute Leistungen während des Studiums, eine kurze Studiendauer und eine Abschlussarbeit, die in besonderem Maße Praxisnähe und Software-Qua-litätsaspekte berücksichtigt. In Koope-ration mit verschiedenen Hochschu-len wird der ASQF-Förderpreis derzeit an der FU Berlin, FH Brandenburg, BTU Cottbus, TU München, FH Nürn-berg und der Friedrich-Alexander- Universität Erlangen-Nürnberg ver-geben.


Marcel Busch erhält ASQF-Förderpreis für seine Masterthesis

ASQF-Vizepräsident Norbert Kastner (r.) und Michael Strobel (l.) von der infoteam Software AG überreichten den ASQF-Förderpreis an Marcel Busch.

DEVOPS

www.anecon.com/blog

DevOps - Wir wollen alle dasselbe!Christian Eggbauer, ANECON

DevOps, ein neues Buzzword das viele Un-ternehmen beschäftigt - und das zu Recht! Der Ansatz lässt Fehler so früh erkennen wie keine andere Methode und reduziert drastisch die Gesamtdurchlaufzeit durch effiziente, rasche Fehlerbehebung.

Hohe Geschwindigkeit. Steigende Qualität. Mehr Innovation.

Mühsame manuelle Tests werden automa-tisiert. Mit Hilfe von Service Virtualisierung gelingt eine simple Abbildung ganzer heterogener Systemlandschaften, um frühzeitige Tests schnell und produktions-nah durchzuführen. Ebenso werden die Themen Deployments, LogFiles durchgra-ben, Abstimmungen über falsche Versionen, Fallbackszenarien oder Releasenotes somit obsolet. Und dies alles spart Zeit!

Mindset schärfen - zusammen bewegen wir mehr!

Nichtsdestotrotz - DevOps muss verstan-den, etabliert und gelebt werden. Dafür ist, ein durchgängiges Commitment seitens des Managements notwendig. Schritt für Schritt und DevOps-Teams werden einen hohen Mehrwert für das Unternehmen bringen!

Lesen Sie den ganzen Artikel am ANECON Blog - das Thema wird aus Sicht der Projektleitung beleuchtet - und das realitätsbezogen und ehrlich! https://goo.gl/jOkdqd

ASQF NEWS7

Ausführlich wurde beim vergangenen ASQF Quality Day in Berlin über Herausforderungen und Ansätze für das Inter-net of Things in Praxis und Theorie diskutiert, sei es modell-getriebene Entwicklung und Tests, Prozesserfordernisse, Plattformen oder Services. Gerade die Herausforderungen an die Software-Qualität und die Sicherheit sind im hoch vernetzten Internet of Things enorm. Dies betonte auch Dr. Andrej Pietschker in seiner Keynote „Im Testen nichts Neues“. In seinem Vortrag über die vergangenen 20 Jahre der Testautomatisierung schlug er eine Brücke von Ansät-zen in der Testautomatisierung und -beratung hin zu aktu-ellen Themen des Software-Tests, besonders die künftigen Herausforderungen im IoT-Umfeld. Um diesen Herausforderungen begegnen zu können, benö-tigt es Quality Engineering für das Internet der Dinge, wie Armin Metzger vom ASQF betonte. Hierfür werde gerade in einer Kooperation des Expertennetzwerkes ASQF und des German Testing Boards ein Trainingsschema entwickelt.Besonders interessant für IoT sind die Sicherheitsaspekte. Eindrucksvoll stellte Thomas Haase dar, wie leicht es Ha-ckern gemacht wird, an Passwörter und andere empfind-

liche Daten zu gelangen. In Bezug auf das Internet of Things ist diese Gefahr bzw. Unsicherheit nicht zu unterschätzen.Insgesamt schätzten die Teilnehmer die gute und aktuelle Themenzusammenstellung des ASQF Quality Days. Auch Günter Schneider (Sulzer GmbH), Aussteller und Sponsor, betonte: „Die Vorträge waren sehr spannend. Wir habengute und intensive Gespräche mit den Teilnehmern ge-führt.“ Das Internet of Things ist und bleibt weiterhin ein sehr interessantes Thema, zu dem es noch mehr Veranstal-tungen vom ASQF geben wird.

Qualitätssicherung fürdas Internet der DingeASQF Quality Day in Berlin

Zuwachs: Neue Mitglieder im ASQF e.V.

rola Security Solutions GmbHOberhausenwww.rola.com

Werden Sie Mitglied im ASQF!Jetzt Mitgliedsantrag stellen und Teil einer Community aus über 1.400 Qualitätsexperten werden. www.asqf.de/asqf/mitglied-werden

New Elements GmbHNürnbergwww.newelements.de

Anlässlich seines 20-jährigen Bestehens hat der ASQF eine Sonderschrift mit dem Titel „20 Jahre im Dienst von Qualität“ herausgegeben. In ausgewählten Beiträgen erörtern hochka- rätige Branchenexperten unterschiedliche Fragen von Soft-ware-Qualität. Mitglieder des ASQF erhalten dieses umfang-reiche Werk kostenfrei.

JETZT MITGLIED DES ASQF WERDEN: Erhalten Sie zur Begrüßung eine Sonderschrift kostenfrei und nutzen Sie den Zugang zu hochwertigen (ko-stenfreien) Events, die einen persönlichen Austausch mit Experten aus Wirtschaft und Politik auf persönlicher Ebene unterstützen. MEHR ZU IHREN VORTEILEN ALS ASQF-MITGLIED ERHALTEN SIE AUF www.asqf.de/asqf/mitglied-werden

20 Jahre Software-Qualität

Titelthema Ausgabe 42 | März 2017 8

von Sven Euteneuer DevOps

Quality-Driven

99

Was ändert sich, was bleibt gleich − und wie können Qualitätssicherung und Test von DevOps profitieren?

Unter DevOps (Abkürzung für Deve-lopment und Operations) versteht man eine Philosophie, die seit langer Zeit organisatorisch getrennten Be-reiche Entwicklung und Betrieb von IT-Systemen wieder an einen Tisch zusammenbringt und Kommunikati-on, Zusammenarbeit und Interaktion fördert. Neben organisatorischen und prozessualen Mitteln wird auch darauf gesetzt, wiederkehrende Tätigkeiten weitestgehend zu automatisieren.Getrieben wird die Einführung von DevOps in Unternehmen dadurch, dass sich Anforderungen − insbeson-dere überall dort, wo IT an der Kun-denschnittstelle oder in Produkten eingesetzt wird − häufig und hochfre-quent ändern. Die Zeit stabiler Pflich-tenhefte, die in wasserfallartigen Prozessen umgesetzt, verifiziert und

validiert werden können, ist hier vor-bei. In vielen Branchen treiben neue, leichtgewichtige Player die etablierten Marktteilnehmer dabei vor sich her. In einschlägigen Umfragen geben be-reits bis zu 65 Prozent der Befragten an, monatliche, wöchentliche oder so-gar tägliche Releases zu planen. Wenn nun ein Ansatz wie DevOps es sich auf die Fahnen schreibt, schnel-le Reaktionsfähigkeit zu ermöglichen, gleichzeitig aber damit wirbt, Quali-tät zu steigern und Kosten zu senken, dann ist ihm die Aufmerksamkeit von Entscheidern sicher. Die Effektivität von DevOps-Vorgehen lässt sich dort nachweisen, wo der Ansatz systema-tisch, geplant und diszipliniert ein-geführt und gelebt wird. Aber auch DevOps ist nicht die sprichwörtliche „Silver Bullet“ – auch für DevOps gibt es Leitplanken, Vorbedingungen und Erfolgsfaktoren. Dazu gehören: Zu-sammenarbeit von Development und Operations, Automation, eine Conti-nuous Delivery sowie eine Anpassung der Software- und Systemarchitek-turen.

Parallel dazu hat die gesamtwirt-schaftliche Lage in Deutschland dazu geführt, dass gerade in der IT ein akuter Fachkräftemangel spürbar ist. Überall dort aber, wo das Angebot an einem Gut (hier qualifizierter Ar-beit) knapp ist, treten die Nachfrager desselben automatisch in einen Wett-bewerb, der einerseits über Gehälter und Sonderleistungen stattfindet, andererseits auch zu „Techie-freund-licheren“ Arbeitsumgebungen führt; dazu gehört auch ein zeitgemäßes Vorgehensmodell. Kein gestandener Entwickler und erst recht keiner der

Titelthema

vielbeschworenen Millenials wird sich freiwillig auf ein Wasserfallmodell kurz vor dem großen „Go-Live“ ein-lassen. Wer hier einen moderneren, iterativen, werkzeugunterstützen An-satz bieten kann, ist klar im Vorteil.

DevOps und Fachkräftemangel ver-ändern Entwicklungsumgebungen

Wenn nun ein starker Fokus darauf liegt, Technikern attraktive Bedin-gungen zu bieten, ist es ganz zwangs-läufig, dass die gewählten Lösungen häufig stark technikfokussiert sind. An dieser Stelle kommen die Trends DevOps und Fachkräftemangel zu-sammen. Sie sorgen dafür, dass das Umfeld, in dem heute Software ent-wickelt, integriert und betrieben wird, viel stärker auf technische Affinität zu-rückgreift, auch und gerade über die klassisch technischen Rollen hinaus.Man muss nicht weit schauen, um Indizien hierfür zu finden: So finden sich in vielen Disziplinen wie Netz-

werk- oder Umgebungsmanagement Tendenzen hin zu Configuration- oder Infrastructure-as-Code. Das heißt, es werden vermehrt Artefakte in Form von Quellcode hinterlegt. Ein weiteres Indiz ist die Veränderung der Stellen-profile von Test- und QS-Rollen in Pro-jekten. War hier traditionell eine gute Kombination aus Domänen- (Fach-lichkeit) und Methodenkompetenz (Testmethodik) gefragt, so tritt hier mittlerweile die Anforderung nach Entwickler-Know-how, Programmier-sprachen und Testautomatisierung immer stärker in den Vordergrund.

Und die Qualität?

Die beschriebenen Veränderungen haben massive Auswirkungen – und wie jede Veränderung birgt auch diese das Risiko des Scheiterns. Allerdings stehen wir hier vor einer Situation, in der Rollen mit Qualitätsbezug einen wesentlichen Beitrag zum Gelingen dieser Transition leisten können. Ganz

konkret sind dies die folgenden drei Beiträge:

Etablierung cross-funktionaler Teams über die Entwicklung hinaus,

Aufsetzen einer funktionierenden Conti-nuous Delivery Pipeline,

Schaffung von Transparenz im Tagesge-schäft.

Cross-funktionale Teams

Nicht erst seitdem DevOps zum Hype wurde, hat sich die Erkenntnis durch-gesetzt, dass strenge, anhand einer industriellen Fertigungsstraße aus-gerichtete arbeitsteilige, Vorgehen in der komplexen, interdependenten und sich schnell ändernden Welt der IT nicht die optimale Lösung darstel-len. So ähnelt Software-Entwicklung doch mehr der Entwicklung eines Pro-dukts denn seiner industrialisierten Fertigung.Daher fordern schon Ansätze aus der agilen Software-Entwicklung die Auf-


Abbildung 1: Eigenschaften von DevOps

stellung von interdisziplinären oder auch cross-funktionalen Teams. In diesen Teams gibt es keine schema-tische Arbeitsteilung. Jedes Team-mitglied sollte ein T-förmiges Fä-higkeitsprofil mitbringen, das heißt: Spezialist in einem Bereich sein, aber breites Oberflächenwissen in anderen Bereichen mitbringen. Hier wird jedoch häufig zu kurz ge-dacht. Während es sinnvoll ist, solche interdisziplinären Entwicklungsteams aufzustellen, ist es wenig sinnvoll, danach sofort aufzuhören. Allzu häu-fig führt dies zu Situationen, in denen hochagil arbeitende Entwicklungs-teams ad absurdum geführt werden, wenn der Rest der Organisation wie Fachbereich, Betrieb oder auch nur weitere Teams, die andere Systeme verantworten, nicht eingebunden sind. DevOps versucht solchen Fehlent-wicklungen zu begegnen, indem grundsätzlich und von Beginn an alle operativen Stakeholder Teil des cross-funktionalen Teams sind. Das be-deutet, dass insbesondere der Fach-bereich und die zukünftigen Nutzer beziehungsweise Betreiber der Soft-ware im Team vertreten sind.Während schon der Begriff DevOps klar macht, dass neben der klas-sischen Entwicklungssicht nun auch eine Betriebssicht integraler Bestand-teil wird, besteht das Risiko, dass die Qualitätssicht wenig Beachtung findet beziehungsweise sogar ausgeklam-mert und als späteres Implementie-rungsdetail verkannt wird. Hier muss eingegriffen werden. Nur, wenn das gemischte Team adäquat auch mit QS-bezogenen Skills und Rollen aus-gestattet ist, kann ein DevOps-Ansatz Erfolg haben. Allein die Idee, Ände-rungen mehr oder weniger automa-tisch in den Live-Betrieb zu schieben, muss wahnsinnig erscheinen, wenn nicht über den gesamten Prozess von der Entwicklung bis zum Betrieb eine stringente Qualitätssicherung sicher-gestellt ist.Die koordinierte Integration einzelner Komponenten in größere und kom-plexere Systeme kann dabei mit Me-

chanismen wie MicroServices gelöst werden, die sicherstellen, dass einzel-ne Teams gleichzeitig handlungsfähig bleiben, aber auch klare Schnittstel-len zu ihrer Umgebung anbieten. Eine regelmäßige Koordination zwischen den Teams ist notwendig, um zum Beispiel die Ablösung einer Schnitt-stelle durch eine neuere Version mit anderer Signatur zu koordinieren. Aus einer übergreifenden, architekturge-triebenen QS-Rolle kann eine solche Koordination über eine Vielzahl klei-ner DevOps-Zellen oder -Pods effektiv und effizient geleistet werden.

Continuous Delivery Pipeline

Die zweite wesentliche Säule, auf der DevOps steht, ist die Umsetzung einer Continuous Delivery (CD) Pipeline. Der Automationsgrad einer solchen Pipe-line kommt hier vor allem der schnel-len Überführung von Änderungen in den IT-Betrieb zu Gute. In voller Aus-baustufe werden Änderungen, be-ginnend vom Check-In, automatisiert durch die Pipeline geschleust. Werden keine Abweichungen erkannt, geht die Änderung je nach Risikoprofil auch direkt live. Auf diese Art und Weise bleiben Unternehmen wie Spotify am Puls der Zeit und können Anregungen durch Nutzer teilweise innerhalb von Tagen umsetzen.Darüber hinaus liegt der Vorteil von CD darin, schnell und systematisch erwiesenermaßen funktionieren-de Software-Releases produzieren zu können. Das erleichtert nicht nur die Arbeit des eigentlichen Release-Managements, welches weniger Auf-wand benötigt, ein Release technisch herzustellen. Darüber hinaus erleich-tert dieses Vorgehen auch die Zusam-menarbeit mit anderen Teams oder bei der Integration in große Systeme von Systemen. Überall dort ist es von Vorteil, erkannte Probleme schnell zu korrigieren, zu testen und in ein ent-sprechendes Release zu deployen. Abbildung 2 zeigt ein Beispiel für eine solche Pipeline. Konkrete Implemen-tierungen sind immer bezogen auf ein konkretes technisches Umfeld (Hard-

111111

Titelthema

ware, Betriebssystem, Technologie-Stack, Programmiersprache, Build- und Compiler-Infrastruktur oder Testwerkzeuge). Im Grunde besteht eine Pipeline dabei aber immer aus einer Abfolge sogenannter Stages (in der Abbildung dunkel dargestellt) mit ihren jeweiligen Prozessschritten (hell dargestellt). Jede Stage entspricht dabei einer Tätigkeit im Entwicklungs-prozess beziehungsweise einer neuen Integrationstiefe. Sinnvollerweise beginnt die Pipeline mit den ersten Artefakten aus dem Pro-zess. Das können Modelle oder Quell-code sein. Wird das System zunächst in Modellen entworfen, stellt die Ana-lyse die erste Stage der Pipeline dar. Manuell entwickelter Code stößt an-schließend dazu (in nicht-modellge-triebenen Ansätzen stellt dies üblicher-weise die erste Stufe der Pipeline dar). Unterstützt durch durchgängige Re-positories für alle Artefakte integriert hier ein CI-System die Quellcodeliefe-rungen und unterzieht sie Build- und Test-Prozessen. Ein Vorteil ist dabei, dass das CI-System damit zum „Quell der Wahrheit“ wird und offizielle Buil-ds herausgibt. Lokal erzeugte Builds, mit allen ihren Problemen rund um das Konfigurationsmanagement, werden weniger wichtig.Neben dem eigentlichen Build laufen auf dem CI-System erste Code-nahe Tests ab. Üblicherweise werden hier-zu sowohl fachliche Tests (z.B. mittels fachlichen Unit Tests) als auch nicht-fachliche Tests implementiert (z.B.


mittels nichtfachlicher Unit Tests oder mittels anderer Verfahren wie sta-tischer Analyse für bestimmte Anfor-derungen zu Wartbarkeit, Übertrag-barkeit oder Sicherheit).Für jede Stufe der Pipeline gilt: Sind alle Schritte auf dieser Stufe erfolg-reich durchlaufen, so darf eine Stufe weitergerückt werden. Schlägt zum Beispiel der Build oder ein Test fehl, wird nicht weitergerückt; eine nach Analyse und Bugfix eingecheckte Ver-sion, die das Problem korrigiert, kann sich dann erneut „bewerben“.Nun folgt eine Reihe von Teststufen, die je nach konkretem Umfeld, Or-ganisation und Integrationstiefe un-terschiedlich implementiert werden. Meist sind eine fachliche Abnahme der Lieferung dabei („Acceptance Test“) sowie gegebenenfalls eine Stufe, die dedizierte dynamische Prü-fungen nicht-fachlicher Anforderun-gen vornimmt („NFT Test Stage“). Während auf der Commit Stage noch keine dedizierten Umgebungen ange-bunden waren, werden diese nun zum Thema. In aller Regel müssen hier virtualisierte (Simulator/Emulator) oder physische Umgebungen (x-in-the-loop) angebunden sein. Um einen hohen Automationsgrad zu erreichen, ist hier häufig Integrationsaufwand zu leisten, so dass Umgebungen au-tomatisiert zusammengestellt, initia-lisiert, genutzt und wieder abgebaut werden können.Sind auch diese Stufen der Pipeline erfolgreich durchlaufen, kann das Er-gebnis freigegeben werden. Auch,

Abbildung 2: Beispiel für eine CD-Pipeline

MODDELING STAGE COMMIT STAGE ACCEPTANCE TEST STAGE

NFT TEST STAGE

PRODUCTIONSTAGE

Analyzeindividual

items

Package

Analyze integrated

items

Compile

Execute Unit Test

Package

Execute Code Analysis

Configure Environment

Deploy Binaries

Execute Smoke Tests

Execute Acceptance Tests


Deploy Binaries

Execute Smoke Tests

Execute UserAcceptance Tests


Deploy Binaries

Execute Smoke Tests

Sven Euteneuer verantwortet bei SQS technische Beratungs- und Testservices in der DACH-Region. In dieser Rolle unterstützt er Kunden von SQS dabei, nichtfachliche Qualität messbar und transpa-rent zu machen und hilft Ihnen dabei, die nötigen Voraussetzungen für die erfolgreiche Nutzung von Ansätzen wie DevOps zu schaffen. Der Diplom-Informatiker ist seit über 20 Jahren im IT-Bereich tätig, zehn Jahre davon in der Softwareentwicklung. Danach implementierte er technische QS-Maß-nahmen, nichtfachliche Tests und Lifecycle-Au-tomationslösungen.

13

wenn es eine Produktionsumgebung im Sinne der IT nicht gibt, kann ein solcher Build intern bereitgestellt oder nach Durchlaufen weiterer inter-ner Prozesse auch „live“ eingesetzt werden. All diese qualitäts- und testbezo-genen Aufgaben in der CD-Pipeline erfordern ein gehöriges Investment in Qualität, zunächst im Aufbau und spä-ter auch im Tagesgeschäft. Über alle Stufen der Pipeline ist eine Qualitäts-strategie zu ziehen, so dass sicherge-stellt ist, dass alle relevanten Aspekte auch durch Analysen bzw. Tests in ei-ner der Stufen abgedeckt sind. Nicht zu vergessen ist auch, dass in einem viel stärkeren Ausmaß automatisiert wird – dies bedeutet zwangsläufig, dass sich Aufwände vom manuel-len Test hin zur Automatisierung und Wartung der Automationslösungen verschieben. Die Notwendigkeit der Automatisierung erfordert auch einen stärkeren Fokus auf Unterstützungs-disziplinen wie Testdaten- bzw. Um-gebungsmanagement. Semiautoma-tische Lösungen und Workarounds sind nicht mehr gut genug – sie halten die Pipeline an, wie ein Fließband in einer Fahrzeugfertigung.

Mehr Nachverfolgbarkeit und Transparenz

Eine andere Organisationsform und eine automatisierte Deployment Pipe-line sind das eine – die Anforderung an eine lückenlose Nachverfolgbarkeit der Zusammenhänge zwischen Arte-fakten ist das andere. In manchen Um-feldern wird es nur intern gefordert, in anderen ist es aufgrund regulato-rischer Anforderungen (wie Safety) unabdingbar.Eine CD-Pipeline ist dabei ein wei-terer Schritt in die richtige Richtung. Schließlich lässt sich für alles, das automatisiert in dieser Pipeline ab-läuft ein „Paper Trail“ aufzeichnen, so dass eine dichtere Nachverfolgbarkeit möglich wird.Die Pipeline alleine ist aber nur eine Lösungskomponente. Die Informa-tionen müssen noch in einem ge-

meinsamen Modell zusammenge-führt werden, welches es erlaubt, die Informationen nach verschiedenen Aspekten wie Artefakten, Betrach-tungsgegenständen, Anforderungen, Qualitätseigenschaften, Prozesspha-sen oder Meilensteinen anzufragen. Da hierfür derzeit leider noch keine Out-of-the-box-Lösung verfügbar ist, können an dieser Stelle beträchtliche Aufwände bei der Integration und der Anpassung existierender Lösungen an die konkreten Anforderungen ent-stehen. Konzeptuell existieren allerdings tragfähige Modelle. Es ist aber noch notwendig, diese Modelle individuell in entsprechende Analyse- und Da-shboardsysteme zu implementieren bzw. zu konfigurieren. Aufgrund des durch DevOps weiter steigenden Be-darfs, entwickelt sich hier aber gerade eine erhebliche Dynamik, so dass in naher Zukunft Lösungen der nächsten Generation mit erheblich geringeren Aufwänden angepasst und eingesetzt werden können.DevOps ist das Buzzword der Stunde – es kommt eine Reihe von Trends in der IT zusammen und entwickelt eine ei-gene Dynamik. Aus Qualitätssicht er-geben sich große Chancen, Vorgehen, Infrastruktur und Methodik so anzu-passen, dass nicht nur die DevOps-Transition gelingt, sondern dass auch das Fundament für eine spürbar bes-sere Produktqualität gelegt wird. Ist der Schritt hin zu DevOps gelungen, bleibt nur mit Herbert Grönemeyer zu schließen – es „bleibt alles anders“!

Im Gespräch

Mit DevOps soll ein lang schwelender Konflikt zwischen Software-Entwick-lern und IT-Verantwortlichen endlich beigelegt werden. Die Befürworter des neuen Prozessverbesserungsan-satzes versprechen sich davon kür-zere Entwicklungszeiten, häufigere Releases und qualitativ höherwertige Software. Doch kann DevOps halten, was es verspricht? Wie sollte man in DevOps einsteigen und wo liegen die Stolpersteine? Das SQ-Magazin befragte dazu DevOps-Experte Uwe Friedrichsen.

SQ: Wie definieren Sie Dev Ops gemäß Ihrer prak-tischen Erfahrungen?Uwe Friedrichsen: Hier ist zu unter-scheiden, was ich in der Praxis in Un-ternehmen antreffe, die von sich sa-gen, dass sie „DevOps machen“ und, was DevOps wirklich ist. In Unterneh-men und in Diskussionen sehe ich ein perfektes Durcheinander von Inter-pretationen, beginnend mit sinnvollen Ansätzen bis hin zu Skurrilitäten wie neu geschaffene Teams, die zwischen den unveränderten Entwicklungs- und Betriebsabteilungen vermitteln sollen; Managern, die gegenüber Entwicklern mit „You build it, you run it“ Drohku-lissen aufzubauen versuchen; oder der Vorstellung, dass man mit DevOps keine Betriebsexperten mehr braucht, sondern alles zukünftig von den Ent-wicklern gemacht wird und man so die IT-Kosten kräftig senken kann.


SQ: Der Ansatz von Dev Ops scheint also vielen noch nicht klar zu sein?

Leider treffen die meisten Ansätze die Ideen von DevOps nicht wirklich, sondern sind entweder so abstrus wie zuvor skizziert, oder beschränken sich häufig im Kern auf das Einführen einer mehr oder weniger durchgängigen Continuous Delivery Pipeline (verein-facht ausgedrückt eine Automatisie-rung von Build, Test und Deployment).Tatsächlich ist DevOps aber ein viel umfassenderes Konzept. Es ist sehr gut in dem Buch „The Phoenix Project“ [1] und als Referenz kurz in dem zuge-hörigen Blog Post [2] beschrieben. Im Kern geht es bei DevOps darum, die gesamte IT-Wertschöpfungskette kontinuierlich mit dem Ziel möglichst kurzer Durchlaufzeiten (Cycle Times) zu optimieren, das heißt salopp aus-gedrückt: „Wie schnell kann ich eine Idee durch die IT-Wertschöpfungsket-te bringen, so dass der Kunde sie sieht und mir Feedback geben kann?“

SQ: Das ist ein fundamen-taler Unterschied zu der Art und Weise, wie IT in der Vergangenheit optimiert worden ist.Seit der Software-Krise, die ihren Be-ginn in den späten Sechzigern des letzten Jahrhunderts hatte, hat man eigentlich immer nur versucht, ko-steneffizient die Produktion von Soft-

DevOpsEine Revolution im Kopf

151515

ware zu skalieren, also mehr Software für weniger Geld zu erstellen. Die Konzepte des Software Engineerings, die Aufteilung der IT-Wertschöpfungs-kette in „Arbeitsstationen“ (wie z.B. Anforderungserhebung, Architektur, Programmierung, Test und den ganzen Betriebsdisziplinen), welche durch ein virtuelles Fließband, nämlich den Software-Entwicklungsprozess mitei-nander verbunden sind – all das sind die Konzepte der industriellen Produk-tion, auf die Software-Entwicklung angewandt.Der Kerngedanke der industriellen Produktion ist Kosteneffizienz, denn je günstiger ich ein Teil produzieren kann, desto höher ist meine Marge. Allerdings setzt industrielle Produkti-on auch weite, träge Märkte voraus, in denen die Nachfrage deutlich hö-her ist als das Angebot, denn die Ko-

steneffizienz geht zu Lasten der Re-aktionsgeschwindigkeit. Je optimaler sich ein Unternehmen hinsichtlich von Kosteneffizienz aufgestellt hat, desto langsamer kann es auf Verände-rungen von außen reagieren. Das liegt an typischerweise großen Batches in der Produktion, um die Fixkostenan-teile zu minimieren, langen, zentrali-sierten Entscheidungsketten und ei-ner hochgradigen Spezialisierung in den einzelnen Arbeitsstationen, die über Prozesse und Artefakte verbun-den sind, die detailliert im Vorfeld de-finiert worden sind.Das ist kein Problem, solange die Mär-kte träge sind, das heißt, die Hersteller aufgrund der überwiegenden Nach-frage die Veränderungsgeschwindig-keit selber definieren können. Kippt aber das Verhältnis von Angebot und Nachfrage, das heißt, das Angebot

übersteigt die Nachfrage deutlich, dann werden Märkte eng und dyna-misch. Kunden kaufen nicht mehr dankbar das, was da ist, sondern das, was ihre persönlichen Bedürfnisse am besten trifft. Sie haben ja die Wahl. Damit bewegt sich der Markt sehr schnell und wird von denen getrie-ben, die sich am schnellsten auf die sich verändernden Bedürfnisse der Kunden einstellen können.In solchen sogenannten post-industri-ellen Märkten ist Kosteneffizienz nicht mehr der primäre Treiber für Optimie-rung, sondern Cycle Times, d.h. wie schnell man neue Ideen zu den Kun-den bringen kann. Man muss sich so aufstellen, dass man sich so schnell wie möglich verändern kann und kontinuierlich an die Bedürfnisse der Kunden anpassen kann. Das beginnt damit, dass man die Entscheidungs-kompetenz dezentralisiert, das heißt, dahin delegiert, wo die Probleme sind, nämlich an den Grenzen zum Markt, also zu den Teams, die direkten Marktkontakt haben. Und man richtet auch alles andere konsequent darauf aus, so schnell wie möglich auf sich verändernde Marktbedürfnisse rea-gieren zu können.

SQ: Was hat das mit IT im Allgemeinen und DevOps im Speziellen zu tun? Nun, zweierlei. Zum einen hat sich die Rolle der IT seit den Anfangszeiten des Software Engineering massiv ver-ändert. Hat IT damals noch einzelne Teilfunktionen des Business unter-stützt, so ist IT heute das Nervensy-stem eines jeden nicht-trivialen Unter-nehmens. Die gesamte Business-DNA ist in IT kodiert. Es ist nicht mehr mög-lich, Geschäftsprozesse, Produkte oder auch nur Features zu ändern, ohne die IT anzufassen. Damit ist die

Uwe Friedrichsen ist ein langjähriger Reisender

in der IT-Welt. Als CTO der codecentric AG ist er

stets auf der Suche nach innovativen Ideen und

Konzepten. Er teilt und diskutiert seine Ideen re-

gelmäßig auf Konferenzen, als Autor von Artikeln,

Blog Posts, Tweets und im direkten Gespräch.

Im Gespräch Ausgabe 42 | März 2017 16

Durchlaufzeit einer Änderung durch die IT-Wertschöpfungskette zu einem begrenzenden Faktor für die mögliche Veränderungsgeschwindigkeit eines Unternehmens geworden.Zum anderen haben sich die Märkte stark verändert, in denen sich die mei-sten Unternehmen bewegen. Waren die Märkte in den Zeiten, in denen die Grundlagen des Software Enginee-rings gelegt wurden (und nach denen heute noch die meisten IT-Bereiche von Unternehmen handeln), in der Regel noch weit und träge, so sind sie heute fast überall durch Globali-sierung, Internet-Handel und ähnliche Einflüsse eng und dynamisch. Wir müssen mit der IT also ganz andere Anforderungen erfüllen. Die vielbe-schworene Digitalisierung treibt das auf die Spitze, denn Digitalisierung bedeutet vereinfacht „IT ist Business und Business ist IT“. IT ist also nicht mehr nur ein Unterstützer des Busi-ness im Hintergrund, sondern Teil der Produkte, die dem Kunden angebo-ten werden, steht also an „vorderster Front“ und unter ständiger Beobach-tung des Marktes.DevOps ist letztlich nichts anderes als ein Ansatz, der diesen Veränderungs-treibern Rechnung trägt, indem er Cy-cle Times und nicht Kosteneffizienz in den Fokus stellt, um so Unterneh-men die erforderliche Veränderungs-

geschwindigkeit zumindest aus der IT heraus zu ermöglichen. (Natürlich reicht es nicht, wenn die IT schnell wird, wenn der Rest des Unterneh-mens sich nicht ebenfalls an die ver-änderten Marktbedingungen anpasst, aber das liegt außerhalb der Einfluss-bereiche von IT und DevOps.)

SQ: DevOps beinhaltet einer-seits einen technologischen Aspekt, andererseits hat es etwas mit Unternehmens-kultur zu tun. Inwiefern ist Kultur für DevOps wichtig und fördernd?

Kultur ist wichtig für jede Art von Ver-änderung, denn Kultur ist im Prinzip nichts anderes als die Summe der vergangenen Erfolge und Misserfolge inklusive der zugehörigen Handlungs-muster, die in den Mitarbeitern eines Unternehmens und deren Bezie-hungen untereinander abgespeichert sind.Wann immer eine neue Aufgabe zu bewältigen ist, werden erfolgreiche Handlungsmuster aus der Vergangen-heit angewendet, während in der Ver-gangenheit nicht erfolgreiche sowie unbekannte Handlungsmuster abge-lehnt werden.Durch die wechselseitige Bestärkung

bezüglich erfolgreicher und Abschwä-chung nicht erfolgreicher Handlungs-muster entstehen Handlungsimpe-rative, also „wie man Dinge macht“, ohne vorherige Analyse der Ange-messenheit des Handlungsmusters für den konkreten Kontext. Der Satz „Das haben wir schon immer so ge-macht“ ist im Prinzip die Essenz von Kultur.Man kann Kultur auch als einen adap-tiven Reglungskreis verstehen, in dem die Vergangenheit die Gegenwart steuert und jeder neue Erfolg und Misserfolg die „Parameter“ des Re-gelkreises ein wenig verändert – aber halt auch nur ein wenig.Das muss man berücksichtigen, wann immer man Dinge verändern möch-te. Kultur ist ein Trägheitsmoment aus der Vergangenheit, das Verän-derungen entgegensteht. Erst indem man häufig genug Erfolge mit neuen, anderen Handlungsmustern wieder-holt, diffundieren diese über die Zeit in die Kultur und können damit über die Zeit nachhaltig werden.Ein paar vereinzelte Leuchtturmer-folge gehen in dem großen kollektiven Gedächtnis der Kultur einfach unter. In diesen Fällen wird man bei neuen Herausforderungen wieder auf die kulturell verfestigten Handlungsmu-ster zurückgreifen, was diese weiter bestärkt und die wenigen neuen Er-

171717

folge mit anderen Handlungsmustern vergessen macht.DevOps bedeutet letztlich eine „Re-volution im Kopf“. Anstatt wie in den vergangenen 40+ Jahren üblich die IT vorrangig unter dem Aspekt Kostenef-fizienz zu optimieren, wird bei DevOps die Reaktionsgeschwindigkeit in den Vordergrund gestellt.Damit sind alle in der Vergangenheit trainierten Handlungsmuster obsolet geworden oder müssen zumindest kritisch in Bezug auf die neue Optimie-rungsgröße hinterfragt werden. Aber genau diese obsoleten Handlungs-muster sind die Muster, die fest in der Kultur der Unternehmen gespeichert sind und sich mit all ihrer Kraft und Trägheit neuen Mustern entgegen-stellen.Deshalb ist gerade bei einer so grund-legenden Veränderung der zugrunde-liegenden Werte wie bei DevOps das Thema Kultur essentiell wichtig. Es zu ignorieren würde ein sicheres Schei-tern jeder DevOps-Initiative bedeuten, denn Kultur fördert eine Veränderung wie DevOps – zumindest am Anfang – niemals, sondern wirkt ihr immer ent-gegen.

SQ: Sind DevOps ein Hype oder ein Ansatz mit Zu-kunft?Hier gilt es den Begriff DevOps und die damit verbundenen Ziele zu unter-scheiden. Der Begriff DevOps ist der-zeit ein Modebegriff. Viele Parteien schmücken ihre Angebote damit wie seinerzeit mit „agile“ oder „lean“ – häufig ohne, dass das Angebot irgen-detwas mit den Zielen von DevOps zu tun hat. So gesehen kann es durchaus passieren, dass der Begriff DevOps irgendwann einmal verbrannt sein wird, weil zu viel Schindluder damit getrieben worden ist. Das wäre zwar schade, passiert aber leider regelmä-ßig in der IT.Auf der anderen Seite stehen die Ziele hinter DevOps, nämlich die kontinu-ierliche ganzheitliche Optimierung der

IT-Wertschöpfungskette mit dem Ziel, die Cycle Times zu reduzieren. Wenn man akzeptiert, dass post-industrielle Märkte und Digitalisierung nicht nur kurzfristige Hypes sind, sondern fun-damentale Veränderungen in der Be-ziehung zwischen Marktteilnehmern und Unternehmen bedeuten, und wenn man außerdem akzeptiert, dass IT heute nicht mehr nur ein lästiges Cost Center, sondern ein existentieller Produktionsfaktor der meisten Unter-nehmen ist, dann ist DevOps nicht nur kein Hype, dann gibt es keine Alterna-tive dazu, wenn man als Unternehmen mittelfristig überleben will. Natürlich gehört zum Überleben mehr als nur DevOps, aber das liegt, wie schon zu-vor beschrieben, außerhalb des Wir-kungsbereichs der IT.

SQ: Wie sollten Unternehmen in DevOps einsteigen?

Zunächst sollte man überlegen, ob man DevOps überhaupt benötigt. Es passiert mir immer wieder, dass ich mit Leuten spreche, die DevOps ein-führen wollen und bei denen ich in-nerhalb weniger Minuten feststelle, dass es ihnen gar nicht um DevOps geht.Als Lackmustest verwende ich das „magische Dreieck“ bestehend aus den Begriffen „schnell“ (kurze Cy-cle Times), „billig“ (Kosteneffizienz) und „gut“ (Qualität) und bitte meine Gesprächspartner, die zwei Begriffe zu wählen, die ihnen am wichtigsten sind.Sehr häufig fällt die Wahl dann auf das Paar „billig & gut“, also industri-elle Software-Produktion. Die betref-fenden Personen versprechen sich in dem Fall von DevOps entweder di-rekte Kosteneinsparungen oder eine Erhöhung der Qualität, ohne von dem Primärziel der Kosteneinsparung ab-zurücken.Das kann DevOps aber nicht lei-sten, weil es ein ganz anderes Ziel hat. DevOps befindet sich auf der Kante „schnell & gut“ des Dreiecks,

also der postindustriellen Software-Produktion. Solange die führenden Entscheider nicht der Meinung sind, dass Reaktionsgeschwindigkeit für sie wichtiger ist als Kosteneffizienz, egal ob aus berechtigten Gründen oder Verharrungsreflexen, braucht man über DevOps nicht weiter nachzuden-ken.Ist diese Grundsatzfrage positiv be-antwortet, muss man einen Weg fin-den, nicht direkt von der Kultur ge-fressen zu werden, denn wie zuvor beschrieben, steht die etablierte Un-ternehmenskultur einer Veränderung in Richtung DevOps üblicherweise entgegen.Ein guter erster Einstieg in Richtung DevOps ist aus meiner Erfahrung Continuous Delivery, also die Auto-matisierung von Build, Test und De-ployment. Continuous Delivery eignet sich deshalb recht gut, weil es sowohl auf der Kante „billig & gut“ als auch auf der Kante „schnell & gut“ funkti-oniert. Man kann die Automatisierung nutzen, um Kosten zu sparen, ohne die Qualität zu kompromittieren; man kann sie aber auch nutzen, um die Cy-cle Times ohne Verlust von Qualität zu reduzieren.Und auch wenn sich die konkreten Implementierungen je nach gewähl-tem Ziel etwas unterscheiden wer-den, kann man so schon eine wichtige Grundvoraussetzung für DevOps im-plementieren und eine erste „Erfolgs-geschichte“ vorweisen, ohne direkt in den Kulturkampf gehen zu müssen.

SQ: Was ist ausschlaggebend für den Erfolg von DevOps? Was sind die Risiken, die ein Unternehmen beachten sollte?Im Prinzip sind die wichtigsten Er-folgsfaktoren bereits genannt wor-den: Revolution und Umsetzung. Bei der „Revolution im Kopf“ müssen sich alle Entscheider und Beteiligten einig sein, dass die Beschleunigung der IT-Wertschöpfungskette für den

Im Gespräch Ausgabe 42 | März 2017 18

Unternehmenserfolg wichtiger ist, als Kosteneinsparungen um jeden Preis. Das zweite ist die „Evolution in der Umsetzung“. Um den „Kampf ge-gen die Kultur“ gewinnen zu können, darf man es nicht als Kampf ansehen, sondern muss es als eine lange und kontinuierliche Folge von Erfolgser-lebnissen verstehen, die man dem Unternehmensgedächtnis hinzufügt, um darüber die Kultur sukzessiv zu verändern.Letzteres klingt einfacher, als es in der Praxis meistens ist. Gerade ein Thema wie DevOps, das im Kern eine radikale Veränderung der Denk- und Verhal-tensweisen erfordert, fordert die Kul-tur eines Unternehmens sehr heraus. Versucht man zu viele Veränderungen auf einmal zu etablieren, wird die Kul-tur versuchen, sie zu bekämpfen, wie ein Immunsystem Fremdkörper in einem Organismus bekämpft.Deshalb ist es, wie zuvor beschrieben, sinnvoll, erste Erfolgserlebnisse (z.B. mit Continuous Delivery) zu realisie-ren, ohne die Abwehrkräfte herauszu-fordern.

SQ: Welche weiteren Schrit-te empfehlen Sie?

Es kann helfen, geschützte Bereiche aufzubauen, in denen neue Ideen er-probt (und weitere Erfolgsgeschich-ten erzeugt) werden können, ohne, dass die geballte Kraft der Unterneh-menskultur auf sie einwirkt. Das kann man auf zwei Arten machen. Entwe-der man trennt ein Team organisato-risch komplett vom Rest der Organi-sation (der „Lab“-Gedanken, den man derzeit in diversen Unternehmen beo-bachten kann) oder, man erklärt eine veränderte Vorgehensweise zu einem zeitlich beschränkten Versuch: „Lasst es uns für <Zeitraum X> einmal so versuchen. Wenn das nicht funktionie-ren sollte, dann können wir wieder zur alten Vorgehensweise zurückkehren.“Irgendwann wird die Konfrontation mit den „alten Werten“ der Kultur un-umgänglich sein. Bis dahin sollte man idealerweise schon eine Reihe sicht-

barer Erfolge mit DevOps-Vorgehens-weisen vorzuweisen haben. Einfach wird es aber trotzdem nicht werden. Man wird eine Menge Geduld, Beharr-lichkeit und Geschick benötigen, um eine DevOps-Transition erfolgreich umzusetzen.

SQ: Was kann ein Unterneh-men tun, um eine DevOps-Kultur nachhaltig einzufüh-ren?Die Antwort ist eigentlich schon in der Frage enthalten: Es ist notwendig, die Kultur des Unternehmens über eine Vielzahl von Erfolgen so zu ver-ändern, dass die neuen DevOps-be-zogenen Handlungsmuster die alten Handlungsmuster in der Kultur „über-schreiben“. Erst wenn das gelungen ist, ist die Veränderung nachhaltig.Aber nochmals: Das klingt auf dem Papier deutlich einfacher, als es in der Praxis ist. Das theoretische Wissen darum, was Kultur ist und wie man sie beeinflussen kann, heißt noch lan-ge nicht, dass sich dies in der Praxis einfach umsetzen ließe. Da gilt es wie bei jeder größeren Veränderung viele Widerstände zu überwinden, manche offen sichtbar, viele aber unsichtbar und nicht alle Angriffe auf die Verän-derungsbemühungen werden fair ver-laufen.Es hilft auch nicht, wenn man auf

der rationalen Ebene vermittelt be-kommt, dass die Veränderung für das Überleben des Unternehmens (oder zumindest der IT-Abteilung) unum-gänglich ist. Veränderungen lösen bei den meisten Menschen Ängste aus und diese sind irrational und tief im menschlichen Verhalten verankert. Solche Ängste erreicht man nicht mit rationalen Argumenten, sondern nur auf einer emotionalen Ebene.Deshalb empfehle ich als Laie in sol-chen Themengebieten auch geschütz-te Räume und wiederholte Erfolgser-lebnisse. Aber am Ende des Tages bin ich Informatiker und kein Psychologe. Entsprechend bin ich auch kein Ex-perte für Veränderungsprozesse und kann nur ein paar elementare Anre-gungen zu dem Thema anbieten.Wenn Sie DevOps also nachhaltig in Ihrem Unternehmen einführen wol-len, wäre meine abschließende Emp-fehlung, dass Sie für so ein Vorhaben nicht nur einen DevOps-Experten an Bord haben, sondern mindestens auch einen Veränderungsexperten.

REFERENZEN[1] Gene Kim, Kevin Behr, George Spafford, „The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win“, It Revolution Press, 2014[2] „The Three Ways: The Principles Underpin-ning DevOps“, siehe http://itrevolution.com/the-three-ways-principles-underpinning-devops/

Die Fragen stellten Christin Senftleben und Anja Schreinert.

Schulungen 2017April - Juni 2017Certified-Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt. Das iSQI fungiert hier als Vermitt-ler. Anmeldeformular und Preise unter www.isqi.org.

Ort Datum (Start) Tage Anbieter

CMAP Mobile App Testing

München 03.04.17 2 Sogeti Deutschland GmbH

Berlin 03.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart 08.05.17 2 Sogeti Deutschland GmbH


Wien 04.04.17 2 ANECON

Frankfurt 10.04.17 2 CGI Deutschland Ltd. & Co. KG

Braunschweig 27.04.17 2 BREDEX GmbH

Berlin 18.05.17 2 Loyal Team GmbH

Hamburg 18.05.17 2 Loyal Team GmbH

Bremen 18.05.17 2 Loyal Team GmbH

Braunschweig 22.05.17 2 BREDEX GmbH

Hamburg 01.06.17 2 SQS

München 08.06.17 2 CGI Deutschland Ltd. & Co. KG

Frankfurt am Main 19.06.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

Frankfurt 26.06.17 2 Loyal Team GmbH

Köln 26.06.17 2 Loyal Team GmbH

Braunschweig 26.06.17 2 BREDEX GmbHCMAP Mobile App Test Automation

Berlin (in Englisch) 05.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH



Stuttgart 10.05.17 3 CGI Deutschland Ltd. & Co. KG


Frankfurt 21.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbHiSQI® Certified Agile Business Analysis



Stuttgart 28.06.17 2 Sogeti Deutschland GmbHiSQI® Certified Agile Essentials





München 02.05.17 2 Loyal Team GmbH

Hamburg 04.05.17 2 Sogeti Deutschland GmbH

Stuttgart 04.05.17 2 Loyal Team GmbH





Düsseldorf 06.06.17 2 Sogeti Deutschland GmbH

Frankfurt 29.06.17 2 Loyal Team GmbHiSQI's CAT Certified Agile Tester

Hannover 03.04.17 5 Díaz & Hilterscheid Unternehmensberatung GmbH

Offenbach 24.04.17 5 Sogeti Deutschland GmbH


Köln 24.04.17 5 SQS


Düsseldorf 15.05.17 5 Integrata / CGI Deutschland Ltd. & Co. KG




München 29.05.17 5 Method Park Consulting GmbH

München 19.06.17 5 Integrata / CGI Deutschland Ltd. & Co. KG




Termine to goeinfach aus der Heftmitte heraustrennen

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/seminare.html

STA

ND

: Feb

ruar

201

7

http://www.isqi.org

iSQI´s Certified Agile Test Driven DevelopmentWien 08.05.17 3 ANECON

ISTQB® Certified Tester – Foundation LevelStuttgart 04.04.17 4 abilex GmbH

Wien 07.03.17 4 OBJENTIS Software Integration GmbH


München 03.04.17 4 ISARTAL akademie GmbH

Erlangen 03.04.17 4 Method Park Consulting GmbH

Dresden 03.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin 07.04.17 4 CGI Deutschland Ltd. & Co. KG




Hamburg 10.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Münster 18.04.17 4 CGI Deutschland Ltd. & Co. KG


Frankfurt 24.04.17 4 SQS

Frankfurt 24.04.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH





Köln 08.05.17 4 SQS

Münster 08.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Braunschweig 09.05.17 4 Muth Partners GmbH


Ingolstadt 10.05.17 3 sepp.med GmbH


München 15.05.17 3 Philotech Academy



Wiesbaden 16.05.17 4 Muth Partners GmbH

Wiesbaden 16.05.17 4 Muth Partners GmbH



Braunschweig 29.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Nürnberg 30.05.17 4 CGI Deutschland Ltd. & Co. KG



Düsseldorf 06.06.17 4 CGI Deutschland Ltd. & Co. KG


Köln/Düsseldorf 12.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Stuttgart 16.06.17 4 Freitage abilex GmbH




München 19.06.17 4 SQS

Bielefeld 19.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH


Hamburg 20.06.17 4 CGI Deutschland Ltd. & Co. KG





Hamburg 26.06.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH


Dortmund 05.07.17 3 Díaz & Hilterscheid Unternehmensberatung GmbHISTQB® Certified Tester – Foundation Level Extension, Agile Tester

Dresden 06.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH


Münster 11.05.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH






Köln 01.06.17 2 SQS




Bielefeld 22.06.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH

München 26.06.17 2 Method Park Consulting GmbHISTQB® Certified Tester – Advanced Level, Test Manager



Köln 24.04.17 5 SQS








Stuttgart 29.05.17 5 CGI Deutschland Ltd. & Co. KG





Berlin 19.06.17 5 SQS

Erlangen 26.06.17 5 Method Park Consulting GmbH


Köln/Düsseldorf 26.06.17 5 Díaz & Hilterscheid Unternehmensberatung GmbHISTQB® Certified Tester – Advanced Level, Test Analyst

Köln 03.04.17 4 SQS

Frankfurt am Main 02.05.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH










Düsseldorf 19.06.17 4 CGI Deutschland Ltd. & Co. KG

München 19.06.17 5 Method Park Consulting GmbH


Köln 26.06.17 4 SQSISTQB® Certified Tester – Advanced Level, Technical Test Analyst







Köln 15.05.17 3 CGI Deutschland Ltd. & Co. KG


München 07.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Köln 19.06.17 3 SQS

Stuttgart 21.06.17 3 CGI Deutschland Ltd. & Co. KGISTQB® Certified Tester – Foundation Level Extension, Model-Based Tester


Röttenbach 17.05.17 2 sepp.med GmbHIREB® Certified Professional for Requirements Engineering – Foundation Level




Berlin 03.04.17 3 microTOOL GmbH

Nürnberg 10.04.17 3 SOPHIST GmbH

Düsseldorf 26.04.17 3 SOPHIST GmbH







Erlangen 22.05.17 3 Methdo Park Consulting GmbH

Köln 22.05.17 3 SQS



Frankfurt 07.06.17 3 SOPHIST GmbH

Stuttgart 07.06.17 3 Methdo Park Consulting GmbH




Wien 28.06.17 3 ANECONIREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements Elicitation and Consolidation



München 24.04.17 3 SOPHIST GmbH






Köln 12.06.17 3 SQS

Stuttgart 28.06.17 3 SOPHIST GmbH

Zusätzliche Schulungs- und Seminartermine finden Sie auf www.isqi.org!

Mandy KrauseExamination and Evaluation+49 331 [email protected]

Ansprechpartner:Caroline LadekExamination and Organization+49 331 [email protected]

Irrtümer, Termin- und Preisänderungen vorbehalten. Es gelten die allgemeinen Geschäfts- und Preisbedingungen des jeweiligen Veranstalters.

SIE WOLLEN IHR SEMINAR AUCH IMNÄCHSTEN SQ-MAGAZIN BEWERBEN? Wir freuen uns über eine Nachricht. Bitte sendenSie uns Ihre Termine per E-Mail zu: [email protected]

Friedrich-Engels-Straße 24 14473 PotsdamTel.: +49 331 231810-0Fax: +49 331 231810-10

Alle Themen auch als Inhouse-Angebot buchbar!

Das iSQI fungiert hier als Vermittler.Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org

Seminartitel Ort Datum(Start) Tage Anbieter

Anforderungen mit Prosa und Modellen clever erheben und dokumentieren" München 03.04.17 2 SOPHIST GmbH

Agiles RE - Vom Stakeholder zum Backlog Frankfurt 20.04.17 2 SOPHIST GmbH

Train-the-Trainer München 24.04.17 3 ISARTAL akademie GmbH

Erfolgreich im Reviewteam mitarbeiten - Präsenz-Workshop Kirchheimbolanden 28.04.17 1 Maud Schlich, THE QUALITEERS

Doku Agil - Fachliches Wissen in agilen Projekten dokumentieren München 02.05.17 2 SOPHIST GmbH

Reviews effizient moderieren - Präsenz-Workshop Kirchheimbolanden 05.05.17 2 Maud Schlich, THE QUALITEERS

Einführung in die Funktionale Sicherheit (Automotive - ISO 26262) (deutschsprachig) Kornwestheim 08.05.17 2 KUGLER MAAG CIE GmbH

Agiles RE - Vom Stakeholder zum Backlog Nürnberg 11.05.17 2 SOPHIST GmbH

Agile in Automotive (deutschsprachig) Kornwestheim 12.05.17 1 KUGLER MAAG CIE GmbH

Automotive SPICE® - iNTACS™ certified Provisional Assessor (deutschsprachig) Kornwestheim 15.05.17 5 KUGLER MAAG CIE GmbH

TTCN-3 Training "Theory and Practice of TTCN-3" Berlin 15.05.17 3 Spirent Technologies GmbH

GTB® Certified Automotive Softwaretester München 15.05.17 2 ISARTAL akademie GmbH

"Requirements-Engineering in der Praxis: Anforderungen mit Prosa und Modellen clever erheben und dokumentieren"

Düsseldorf 16.05.17 2 SOPHIST GmbH

"Business Analyse - Wie Sie Geschäftsprozesse für alle Beteiligten besser abbilden" Nürnberg 22.05.17 2 SOPHIST GmbH

Praxistaugliche Testkonzepte optimal erstellen und nutzen 02.06.175 Live-

SessionsMaud Schlich, THE QUALITEERS

360° Testautomatisierung Wien 07.06.17 2 ANECON

"Requirements-Engineering in der Praxis: Anforderungen mit Prosa und Modellen clever erheben und dokumentieren"


Agiles RE - Vom Stakeholder zum Backlog Düsseldorf 20.06.17 2 SOPHIST GmbH

Qualitätsmetriken für Anforderungsspezifikationen: Von der Spezifikation zur Kennzahl Nürnberg 23.06.17 1 SOPHIST GmbH

Automotive SPICE® - iNTACS™ zertifizierter Provisional Assessor (englischsprachig) Kornwestheim 26.06.17 5 KUGLER MAAG CIE GmbH

Doku Agil - Fachliches Wissen in agilen Projekten dokumentieren Nürnberg 29.06.17 2 SOPHIST GmbH

Seminare 2017April - Juni 2017

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/seminare.html

STA

ND

: Feb

ruar

201

7

S O F T WA R E T E S T I N G

P R O D U C T M A N A G E R M E D I C A L W E I T E R E A N G E B O T E

U S A B I L I T Y S P E C I A L I S E D

R E Q U I R E M E N T S E N G I N E E R I N G S E C U R I T Y M O B I L E

P R O J E C T M A N A G E M E N T

A G I L E

IREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements ModelingMünchen 03.04.17 3 Loyal Team GmbH



Erlangen 24.04.17 3 Methdo Park Consulting GmbH






Nürnberg 26.06.17 3 SOPHIST GmbHUXQB® Certified Professional for Usability and User Experience, Foundation Level



Köln 26.06.17 3 ProContext Consulting GmbHCertified Professional for Requirements Engineering Foundation Level - Blended Learning




http://www.isqi.org/de/seminare.html

Das ASQF-KarriereportalWir haben den passenden Job für Sie!

Die ausführlichen Stellenangebote finden Sie auf www.asqf.de/karriereportal

IT-Systemadministrator (w/m)ASTRUM IT GmbH

Erlangen

Testmanager (m/w)netcare Business Solutions GmbH

Frankfurt oder Neustetten bei Stuttgart

Testspezialist (w/m)G. Muth Partners GmbH

Wiesbaden

Senior IT Enterprise Architect (m/w)VON ESSEN GmbH & Co. KG

Bankgesellschaf Essen

IT & Process Support Specialist (m/w)netcare Business Solutions GmbH

Neustetten

Softwaretester/ Mitarbeiter IT Quali-tätssicherung (w/m)

affilinet GmbH Hannover

Consultant: Software Tester / Testau-tomatisierung (m/w)

Qytera Software Testing Solutions GmbH Eschborn

Senior Software Quality Engineer (m/w)

TecAlliance GmbH München, Weikersheim oder Köln

SOFTWARE TESTER (M/W)Panasonic AVC Langen

Langen

Software Tester – Quality AssurancebeQualified GmbH

Köln

Technical Software Tester (m/w)Testautomatisierung & Last- und

Performance Testsnetcare Business Solutions GmbH

Frankfurt a.M., Stuttgart

Senior IT Enterprise Architect (m/w)VON ESSEN GmbH & Co. KG

Bankgesellschaf Essen

Junior / Senior Softwaretester (m/w)OMNINET GmbH

Eckental

(Senior) Testmanager/-in (m/w)ckc group

Braunschweig

Consultant: Software Tester – Testma-nagement / Software Testmanager

(m/w) Qytera Überall

Webentwickler C# / ASP.NET (m/w)iucon GmbH Anwendungsentwicklung &

Webentwicklung Berlin

Requirements Engineer/ Business Ar-chitekt (m/w) im Gesundheitswesenazh Abrechnungs- und IT-Dienstleistungs-

zentrum für Heilberufe GmbH Aschheim bei München

Hier könnte Ihre Anzeige stehen!

Schreiben Sie uns unter [email protected]

Titelthema

EIN GESCHENK FÜR SOFTWARE-PRODUKTMANAGER?


DEVOPS

Das Ziel von DevOps ist die Verkür-zung der Durchlaufzeiten vom Ab-schluss einer Code-Änderung bis zur Kundenverfügbarkeit. Für Software-

Produktmanager bietet das viele Vorteile: Sie können schnell auf aktuelle Entwicklungen re-agieren, die Produkte zügiger optimieren und Flexibilität gewinnen. Oft steigert DevOps die Produktivität und schafft mehr Kapazität für In-novation und Verbesserung. DevOps birgt für Software-Produktmanager aber auch Heraus-forderungen, insbesondere bei der Release-Pla-nung und der Vermittlung des Kundennutzens.

WELCHE NEUERUNGEN BRINGT DEVOPS AUS PRODUKTMANAGEMENT-SICHT?

In der Entwicklung setzt DevOps ein hochgradig iteratives Vorgehen voraus, in der Regel mit agi-len Methoden. Für Software-Produktmanager ändern sich mit der Einführung von DevOps vor allem das Herangehen an die Planung, die Pla-nungszyklen werden kürzer, und die Zusammen-arbeit mit den Entwicklungsteams muss neu ge-staltet werden.Auf der technischen Seite erfordert DevOps die Automatisierung der Integrations-, Test- und De-livery-Prozesse. Die sofortige Bereitstellung ak-tualisierter Produktversionen für den Kunden ist möglich aber nicht zwingend. DevOps kann da-her nicht nur für web-basierte Dienste eingesetzt werden, sondern auch für On-Premise-Produkte und Software-intensive Systeme. Ein ausführlich dokumentiertes Beispiel für Software-intensive Systeme ist die gemeinsame Firmware für HP’s Enterprise LaserJet-Drucker [1] [2]. Dort erfolgt das Deployment in größeren Zeitintervallen.

DEVOPS-VORTEILE FÜR PRODUKTMANAGER

DevOps bietet viele Vorteile für Software-Pro-duktmanager. So bezeichnet Suzie Prince in einem Blog-Artikel Continuous Delivery und Dev Ops als die besten Freunde des Produktmana-gers [3]. Zwei Effekte von DevOps sind dafür be-sonders verantwortlich: Effizienzgewinne durch Automatisierung und verkürzte Durchlaufzeiten.Die Automatisierung, etwa durch Continuous In-tegration und Testing, senkt den Aufwand für die Entwicklungsteams. So kann die Organisation bei gleichem Budget bzw. bei gleichbleibenden Teamstärken mehr Kapazität in kundenrelevante Themen investieren: Innovation, neue Features oder Qualitätsverbesserung.

HP’s LaserJet Firmware-Entwicklung hatte in ei-ner global verteilten Organisation mit über 400 Entwicklerinnen und Entwicklern nur etwa fünf Prozent der Bandbreite für Neuentwicklungen zur Verfügung − zu wenig, um dauerhaft in einem sehr wettbewerbsintensiven Markt zu bestehen. Durch DevOps stieg die für Innovationen verfüg-bare Kapazität auf 40 Prozent. Die Produktmana-ger erhielten wesentlich mehr Gestaltungsfrei-heit zur Weiterentwicklung der Produkte.Die Verkürzung der Durchlaufzeiten bringt Än-derungsanfragen ebenso wie neue Features we-sentlich schneller zu den Kunden. Bei HP sank mit DevOps die Zeit vom Einchecken einer Code-Änderung bis zum getesteten Software-Paket enorm: von mehr als sechs Wochen auf wenig mehr als einen Tag.Produktmanager können dadurch wesentlich schneller auf Probleme reagieren, etwa bei Kunden-Eskalationen, die Funktionalitätsände-rungen erfordern. Es ist klar, dass die Zufrieden-heit der Kunden steigt, wenn man schnelle Lie-ferung zusagen kann. Nicht zuletzt profitiert die Qualität des Produkts. Gerade bei Sicherheitslü-cken ist eine schnelle Lösung enorm wichtig.Aber nicht nur die Reaktion auf Probleme ge-winnt. Das Produkt kann auch schneller pro-aktiv weiterentwickelt werden. Ein Beispiel ist die Adaptive Maintenance, die ein Produkt an veränderte Umgebungsbedingungen anpasst, etwa an eine neue Betriebssystemversion. Mit DevOps können solche Anpassungen schneller und früher auf den Markt gelangen. Das Gleiche gilt für die Umsetzung neuer Erkenntnisse, die Produktmanager beispielsweise aus A/B-Tests, aus Kunden-Feedback oder aus der Markt- und Wettbewerbsanalyse beziehen.Verallgemeinert gilt: Die Verkürzung der Durch-laufzeiten ermöglicht schnellere Feedback-Schlei-fen, die auch bei konstantem Entwicklungsauf-wand eine gezieltere Ausrichtung des Produkts auf Markterfordernisse erlauben.

HERAUSFORDERUNGEN FÜR PRODUKTMANAGER

DevOps konfrontiert das Produktmanagement auch mit neuen Herausforderungen: So müssen die Produktmanager dafür sorgen, dass die Ent-wicklung wirklich den geschäftlichen und strate-gischen Zielen folgt. Denn die DevOps-Konzepte fokussieren stark auf die internen Abläufe von Entwicklung und Betrieb.Beispielsweise fördert DevOps die Verlagerung von Entscheidungen in die Entwicklung, als ein

252525

Titelthema Ausgabe 42 | März 2017 26

REFERENZEN[1] G. Kim: The Amazing DevOps Transformation of the HP LaserJet Firmware Team (Gary Gruver); DevOps Blog, IT Revolution Press. (http://itrevolution.com/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/)[2] G. Gruver, M. Young, P. Fulghum: A Practical Approach to Large-Scale Agile Development - How HP Transformed LaserJet FutureSmart Firmware; Addison-Wesley, 2012.[3] S. Prince: Why Continuous Delivery And DevOps Are Product Managers’ Best Friends; MindThe-Product Blog, July 2016. (http://www.mindtheproduct.com/2016/07/continuous-delivery-devops-pro-duct-managers-new-bff/)[4] G. Heller: DevOps Release Planning; pd7.group Blog, February 2017. (http://pd7.group/2017/de-vops-release-planning)

Barbara Hoisl

Dr. Andreas Birk

Gerald Heller

Die Autoren sind Partner bei pd7.group (http://pd7.group), einem Netzwerk von Exper-ten aus dem Software-Produktmanagement. Gerald Heller ist Gründungsmitglied und Board-Member der International Software Product Management Association (ISPMA, http://ispma.org), Bar-bara Hoisl ist ISPMA Fellow.

Mittel zur Beschleunigung der Durch-laufzeiten. Damit entsteht jedoch die Gefahr, dass Entwicklung und Betrieb sich von geschäftlichen und strate-gischen Zielen abkoppeln. Produktma-nager müssen hier gegensteuern.Eine zweite Herausforderung für Pro-duktmanager schafft DevOps durch das kontinuierliche Deployment. Aus Sicht von Kunden und Benutzern kann das zu einem unstrukturierten Strom von Aktualisierungen führen, in dem das Profil der Software verschwimmt: Kleine Änderungen stören etablierte Benutzungsprozesse, wichtige Neue-rungen gehen unter und erzielen nicht die gewünschte Aufmerksamkeit im Markt. Auch hier muss das Pro-duktmanagement eingreifen.

NEUE AUFGABENSCHWERPUNKTE FÜR PRODUKTMANAGER

Wie kann das Produktmanagement mit den neuen Herausforderungen im DevOps-Kontext umgehen? Als Er-stes muss es sich überhaupt ins Spiel bringen und die Kommunikation mit den Entwicklungsteams neu justieren. Diese sollen eigenständig arbeiten können, etwa bei dringenden Fehler-behebungen. Die Entwickler müssen aber auch wissen, wann sie die Ab-stimmung mit den Produktmanagern suchen sollen.Für die Weiterentwicklung des Pro-duktes muss das Produktmanagement Orientierung und Vorgaben bieten. Das beginnt mit Vision, Produktdefi-nition und Produktpositionierung. Bei DevOps sind Release-Planung und Roadmaps besonders wichtig, um die richtigen Prioritäten in der Entwick-lung sicher zu stellen.

Die Release-Planung muss dafür sor-gen, dass Kunden wichtige Neue-rungen im Produkt gut wahrnehmen. Die hohe Aktualisierungsrate im Con-tinuous Deployment bewirkt zunächst häufige Releases mit vielen kleine Än-derungen.Für wichtige Neuerungen müssen Produktmanager die nötigen Features passend gruppiert in die Entwicklung einbringen. Mit Marketing und Ver-trieb, sowie bei der Kommunikation mit Analysten müssen sie betreffende Releases besonders ankündigen.Gegenüber der Entwicklung werden die Release-Inhalte vor allem über Roadmaps mit definierten Schwer-punktthemen vermittelt. Eine Umfra-ge unter erfahrenen Produktmana-gern hat ergeben, dass Roadmaps in DevOps als Rahmen formuliert wer-den sollten, in dem die Entwicklungs-teams Details eigenständig gestalten können [4].Wenn Produktmanager diese Heraus-forderungen meistern, dann ist Dev Ops wirklich ein Geschenk für sie: Sie erwei-tern ihren Gestaltungsspielraum und erhalten damit beste Voraussetzungen für ein erfolgreiches Produkt.

Bei DevOps sind Release-Planung und Roadmaps besonders wichtig, um die richtigen Prioritäten in der Entwicklung sicher zu stellen.

272727

Termin für 2018 steht

Der nächste Termin steht bereits fest: die

Jubiläums-Konferenz – 10 Jahre Software

Quality Days – wird vom 16. bis 19. Januar

2018 stattfinden. Veranstaltungsort ist, wie

in den Jahren zuvor, die österreichische

Landeshauptstadt Wien.

Zum Jahresbeginn drehte sich auf den Software Quality Days in Wien alles um das Schwerpunktthema „Quality of Things: Complexity and Challenges of Software Engineering in Emerging Technologies“. Rund 380 Teilnehmer aus über 20 Län-dern nutzten auch in diesem Jahr das Event als Plattform für Informations-austausch, Interaktion und Networ-king. Die Teilnehmer bildeten eine gute Mischung aus Wirtschaft, Indus-trie, Anbietern und Anwendern aus dem universitären Bereich. Auf der Konferenz wurde unter an-derem in sechs parallelen Vortrags-Tracks ein breit gefächertes Spektrum an Vorträgen mit aktuellen Themen des modernen Software Engineerings angeboten. Gemeinsam mit 21 anderen Ausstel-lern präsentierte sich das Internatio-nal Software Quality Institute (iSQI) bei den Software Quality Days. Be-stehende Bekanntschaften und Ver-bindungen konnten gepflegt und neue geknüpft werden.

IoT im Zentrum der Diskussion

Diskussionen zum Thema „Internet of Things“ (IoT) werden längst nicht mehr „nur“ im rein technischen Kon-

SOFTWARE QUALITY DAYS 2017 IN WIEN

text geführt. Die technischen Lö-sungen werden immer mehr in den Kontext der politischen, gesellschaft-lichen und ethischen Rahmenbedin-gungen gestellt. Auch der Meinungs-austausch auf den Software Quality Days verdeutlichte das große Interes-se an derartigen Fragestellungen. Ethische Entscheidungen waren zu-mindest bisher in hohem Maße dem Menschen als Bediener der Systeme überlassen. Im Kontext des IoT wan-dern ethische Fragestellungen aber mehr und mehr auch in die Algorith-mik und die künstliche Intelligenz der Maschinen. Daher birgt das Internet der Dinge nicht nur bezüglich seiner Architekturen, sondern auch hinsicht-lich der ethischen Regelwerke Heraus-forderungen, die zukünftig zu lösen sind.

Im Fokus

E. Wolff

MicroservicesGrundlagen flexibler Softwarearchitekturen

2016, 386 Seiten€ 36,90 (D) ISBN 978-3-86490-313-7

Wieblinger Weg 17 · D-69123 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: [email protected]

www.dpunkt.de

T. Linz

Testen in Scrum-Projekten Leitfaden für Software-qualität in der agilen WeltAus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension

2. Auflage2017, 270 Seiten€ 34,90 (D) ISBN 978-3-86490-414-1

C. Larman · B. Vodde

Large-Scale ScrumScrum erfolgreich skalieren mit LeSS

2017, 396 Seiten€ 34,90 (D) ISBN 978-3-86490-376-2

Larm

an .

Vodd

eLa

rge-

Scal

e Sc

rum

YES, OF COURSE!BECAUSE...

IST DAS WIRKLICH SO EINFACH?

KANN DAS FUNKTIONIEREN?

JA, NATÜRLICH! WEIL …

→ Aus dem Englischen übersetzt von Björn Jensen und Alexander Marquart→ Mit einem Geleitwort von Stephen Denning

Scrum erfolgreich skalieren mit LeSS

Large-Scale Scrum

Craig Larman . Bas Vodde

MorewithLeSS

9 783864 903762

www.dpunkt.deInteresse am E-Book? www.dpunkt.de/plus

Thema• Skalierung • Produktentwicklung• Softwareentwicklung• Agile Methoden • Projektmanagement

Leser• Führungskräfte • Product Owner und

Produktmanager• Scrum Master • Organisations- und

Team-Coaches • Softwareentwickler • Projektmanager

€ 34,90 (D)ISBN 978-3-86490-376-2

Craig Larman . Bas Vodde

Large-Scale Scrum

Wie können wir agiles Arbeiten in großen, komplexen Organisationen skalieren? Eine Frage, die sich vielen Unternehmen stellt. Mit Large-Scale Scrum (LeSS) liegen nun zwei Frame-works (LeSS und LeSS Huge) vor, mittels derer Scrum konsequent ohne viel Zusatz skaliert werden kann, um als Unternehmen agil und überlebensfähig zu sein.

In diesem Buch haben Craig Larman und Bas Vodde ihre Erkenntnisse aus mehr als einem Jahrzehnt an Erfahrung in der Einführung von LeSS in groß angelegten Umgebungen gebün-delt. Es sind konkrete Wegweiser entstanden, die dabei helfen, mehr Flexibilität durch weni-ger Komplexität, mehr Wert durch weniger Verschwendung und mehr Sinnhaftigkeit durch weniger Vorschriften im Unternehmen zu verankern.

Es werden u.a. folgende Themen adressiert:

• Implementierung von LeSS für die Entwicklung in großen Umgebungen

• Auswahl der richtigen Umsetzungsstrategie und des Organisationsdesigns

• Ausrichtung und Strukturierung einer großen Entwicklungsorganisation hin zum Kunden-nutzen

• Klärung der Rolle des Managements, des Product Owners und des Scrum Masters

• Skalierung von Produktdefinition, Anforderun-gen, Planung und Produktmanagement

• Synchrones Arbeiten mit mehreren Feature-Teams

• Koordination und Integration zwischen den Teams

• Integration von Scrum in Multisite- und Offshore-Projekten

• Skalierung von Design und Architektur

DevOps & Co.

Buch + E-Book:

www.dpunkt.de/plus

E. Wolff

Continuous DeliveryDer pragmatische Einstieg

2. Auflage2016, 282 Seiten€ 34,90 (D) ISBN 978-3-86490-371-7

A. Mouat

DockerSoftware entwickeln und deployen mit Containern

2016, 368 Seiten€ 36,90 (D) ISBN 978-3-86490-384-7

282828

JOERG BLUMTRITT IST DATA SCIENTIST UND BLOGGER. ER IST MITGRÜNDER DER DATARELLA GMBH, DIE IM VERGANGENEN JAHR DURCH HIGH5 UNTERSTÜTZT WURDE. AUCH FÜR SEIN UNTERNEHMEN HAT SICH DER BESUCH DER SXSW GELOHNT. HIER SAGT ER WARUM:

Für uns bei Datarella war das Jahr seit der letz-ten SXSW-Konferenz äußerst bewegt. Durch ein Kundenprojekt hatten wir 2015 begonnen, uns mit der Blockchain und mit Smart Contracts zu beschäftigen. Blockchain – die Technolgie hin-ter Bitcoin und anderen sogenannten Crypto-Währungen – ist vermutlich DAS Buzzword des Jahres. Die SXSW-Konferenz, die traditionell der „Jahrmarkt der Buzzwords“ ist, war da natürlich perfekt, um interessante Leute zu treffen und uns in der Community zu vernetzen.

Auf der SXSW kommt man mit Experten, poten-ziellen Partnern und Kunden leicht in Kontakt, selbst mit Menschen, die sonst sehr schwer er-reichbar sind. Mit dem „German Haus“ steht zu-dem ein angenehmer Ort für Termine und Tref-fen zur Verfügung.Seit damals hat unser Blockchain-Geschäft ex-trem zugelegt. Wir arbeiten für eine Reihe inter-nationaler Konzerne und Regierungsorganisati-onen, nicht nur als Berater, sondern vor allem in der Software-Entwicklung. Dabei fokussieren wir uns auf Anwendungen jenseits der Finanz-branche.

RASANTER GESCHÄFTSERFOLG

Regelmäßig veranstalten wir ein Meetup zur Blockchain, mit 80 bis 120 interessierten Besu-chern und internationalen Speakern in München, Stuttgart, Köln, Hamburg und Danzig.

Auf der SXSW-Konferenz 2017 trete ich auch im Hauptprogramm auf – und darauf bin ich beson-ders gespannt!

GERMANY GOES SXSWEin Event, an dem im März keiner vorbei kommt, ist die South by Southwest (SXSW) in Austin, Texas. Vom 10. bis 19. März treffen sich in den USA Professi-onals, Tech-Jünger und Start-up-Stars, um den Trends von morgen nachzugehen. Der Kalender der SXSW ist prall gefüllt. Über 1.000 Sessions und Events stehen 2017 im Programm. Sie bieten die perfekte Gelegenheit, um den eigenen Horizont zu erweitern und neue Branchenkontakte zu knüpfen.

HIgh5 ünterstützt als Partner des „German Haus“ wiederholt vielver-sprechende deutsche Start-ups. Das Stuttgarter Unternehmen Smoope hat den Durchbruch bereits geschafft. Unterstützt von High5 nahm die jun-ge Firma im vergangenen Jahr an der SXSW teil. Im Interview erzählt Smo-ope-Mitgründer und Geschäftsführer Eleftherios Hatziioannou, wie es nach der SXSW-Teilnahme weiterging.

SQ: HERR HATZIIOANNOU, WARUM HAT SICH DIE SXSW FÜR IHR UNTERNEHMEN GELOHNT?

Die SXSW ist aus unserer Sicht die kompakteste Tech-Veranstaltung der Welt. Kaum ein anderes Event bietet in so kurzer Zeit und auf so engem Raum so viel. Sowohl inhaltlich bei den Workshops, Präsentationen, Dis-kussionsrunden als auch, wen man dort so alles trifft. Die wichtigsten und interessantesten Köpfe und Mar-ken der Tech-Szene sind präsent und ansprechbar. Wir konnten für uns die wichtigsten Trends mitnehmen und ableiten, wohin sich der Markt in den nächsten 12 bis 24 Monaten entwickeln wird. Das hat uns letztlich geholfen, unsere Prioritäten zu hinterfragen und die richtigen Maßnahmen zu ergreifen, um unsere Technologie marktgerecht weiterzuentwickeln.

WELCHE MEILENSTEINE KONNTEN SIE IM VERGANGE-NEN JAHR SETZEN?

Ein wichtiger Meilenstein war für uns, dass wir einen tiefgreifenden Verän-derungsprozess initiiert haben, der letztlich sogar zu einem modifizierten Geschäftsmodell geführt hat, mit dem wir uns jetzt noch schneller und bes-

ser entwickeln konnten. Wir haben uns weg vom reinen App-Anbieter hin zum Infrastruktur-Lieferant für sicheres, in-tegrierbares und skalierbares Messag- ing verändert und helfen Unterneh-men dabei, sich fit für das Zeitalter des Conversational Commerce zu machen. Messaging als integraler Bestandteil von Webseiten, Kundenportalen und Apps von Unternehmen – statt einer separaten App.

IHR NEUESTES PROJEKT IST…?

Dass wir mit unserer Technologie mittlerweile höchsten Ansprüchen in Sachen Datenschutz, Sicherheit und Individualisierung gerecht werden und deshalb insbesondere in sensitiven Branchen wie der Finanz- und Versi-cherungswirtschaft stark wachsen. Wer hätte anfangs gedacht, dass heute Banken, Versicherungen und Finanz-dienstleister den größten Anteil un-serer Kundschaft ausmachen. Als wir vor drei Jahren gestartet sind, wollten wir eigentlich die Mobilfunk-Shops meines Mitgründers mit Ihren Kunden vernetzen.

IHR BESTER TIPP FÜR START-UP-GRÜNDER?

Mein SXSW-Tipp: Das Programm ist fast schon überwältigend, deshalb rate ich jedem zu einer guten Vorbereitung. Unbedingt vorher prüfen, welche Ses-sions interessant sind und sich nicht mehr als 3-4 pro Tag vornehmen, da-mit noch genug Zeit für zufällige Ge-spräche und Netzwerken bleibt. Mein Tipp für Start-ups allgemein: Gerade in der Startphase sollte man flexibel bleiben und nicht an der Ur-sprungsidee festhalten, wenn sie nicht

TIEFGREIFENDE VERÄNDERUNGEN

Smoope-Mitgründer und

Geschäftsführer Eleftherios Hatziioannou

funktioniert. Letztlich tastet man sich als Start-up voran bis zum Product-Market-Fit. Dieser ist erst dann gege-ben, wenn ein echtes Kundenproblem gelöst wird, für das Kunden bereit sind, Geld auf den Tisch zu legen. Nicht die Gründer, sondern der Markt sollten entscheiden, was letztlich das Produkt sein wird. Die Fragen stellte Christin Senftleben.

Ausgabe 42 | März 2017 30GERMANY GOES SXSW

HOLOPLOT

HOLOPLOT hat ein komplett neuar-tiges und bahnbrechendes profes- sionelles Lautsprecher-System ent-wickelt, welches die Grenzen im Au-dio- Bereich neu definiert. Das Pro-dukt, bestehend aus Hardware und Software erlaubt es, Schall zu richten wie einen Lichtstrahl. Somit kann nun präzise bestimmt werden, wo etwas zu hören ist oder – vielleicht noch inte-ressanter – wo nicht. Die Schallwellen des Systems haben dabei konstante Lautstärke auf Distanz – eine revolu-tionäre Innovation im Audio-Bereich – und erlauben es, nun alle Zuhörer mit derselben Qualität zu versorgen, unabhängig von ihrer Distanz oder Position zum Sound-System.

Das intuitive Software Interface er-laubt dabei die einfache Kontrolle über mehrere Kanäle gleichzeitig, wo-bei in Echtzeit mehrere Sound Beams mit unterschiedlichem Inhalt, Rich-tung und Größe gesteuert werden können. Dies macht HOLOPLOT zum perfekten Tool für viele Bereiche von Konferenzen, Konzerten, Messen bis hin zu jeder Umgebung mit schwie-riger Akustik.Darüber hinaus liegt eine große Stär-ke des Systems im Erstellen von 3D-immersiven Audio-Umgebungen. Das System ist in der Lage, die Akustik von Räumen zu verändern. Der Zuhö-rer kann dabei den Lautsprecher nicht mehr als Quelle identifizieren und

RISING STARS DER SXSWDIESE START-UPS PRÄSENTIEREN SICH MIT UNTERSTÜTZUNG VON HIGH5 IN AUSTIN

komplett in die akustische Umgebung eintauchen. Das eröffnet neue Mög-lichkeiten im Entertainment Bereich, besonders auch für neuartige Techno-logien wie Virtual Reality.

MIT EVOPARK FINDET JEDER EINEN PARKPLATZ

Einen Parkplatz in der überfüllten Innen-stadt finden, die letzte freie Parklücke im Parkhaus sichern – nichts ist leichter als das, versprechen die Gründer von evopark. Das Start-up wurde 2014 mit dem Ziel gegründet, das Parken neu zu erfinden. Eine Parkkarte öffnet per RFID-Funkchip Schranken im Parkhaus automatisch. Der Nutzer spart sich das Schlange stehen am Kassenauto-maten, er zahlt bargeldlos und bequem am Monatsende. Ergänzt wird die evo-park Karte durch eine kostenlose App, die freie Parkhäuser in der Umgebung zeigt und auf Wunsch dorthin navigiert. Vier Absolventen der WHU – Otto Beis-heim School of Management haben evopark gegründet und führen es seit-her gemeinsam: Maximilian Messing, Tobias Weiper, Sven Lackinger und Marik Hermann. Die Parkkarte und App sind bereits sehr erfolgreich im Einsatz, auch dank der engen Zusammenarbeit mit den größten Systemherstellern und Parkhausbetreibern in Deutschland.

Zahlreiche namhafte Unternehmen nutzen evopark Lösungen, u.a. AXA Deutschland und NOVOFLEET. Aktuell verzeichnet evopark bereits mehr als 20.000 Kunden. Mit seinem innovativen Konzept hat das Kölner Start-up bereits 14 Preise gewonnen, darunter den DWNRW Award 2015, überreicht von NRW-Wirtschaftsminister Garrelt Duin. Im September 2016 erhielt evopark auf dem CODE_n new.New Festival den Hauptpreis der Sparte Connected Mo-bility, verliehen durch Hewlett Packard Enterprise. Damit wurde evopark für das vielversprechendste Geschäftsmo-dell, die innovativste Technologie und das beste Kundenerlebnis auf dem Ge-biet der vernetzten Mobilität geehrt.Namhafte Business Angels haben in das Unternehmen investiert. Im

Juni 2016 hat sich zudem Porsche mit einem siebenstelligen Betrag an evo-park beteiligt – die erste Investition des Automobilherstellers in ein Start-up. Auf der SXSW Interactive präsentiert sich evopark mit Unterstützung von High5 einem internationalen Publikum und potentiellen Kunden.Übrigens: Mit seinem Produkt über-zeugte das clevere Gründerteam bereits die Start-up-Investoren Frank Thelen und Carsten Marschmeyer in der VOX-Sendung „Die Höhle der Löwen“.

BREAKFAST TV LIVE VON DER MESSESo frisch wie das warme Brötchen vom Bäcker bekommen „Daheimge-bliebene“ vom 10. bis 13. März die be-sten News und Innovationen von der SXSW im „High 5 Breakfast TV“ ser-viert. iSQI-CEO Stephan Goericke lädt sich im Daily Talk interessante Ge-sprächspartner an den Frühstücktisch ein. Zusätzlich präsentiert das kurz-weilige Format informative Beiträge rund um SXSW-Events und Keynotes. Schalten Sie ein zum High5 Breakfast TV via Livestream direkt aus dem High5-Haus in Texas.

HIGH 5 FÜR DEUTSCHE START-UPS

Mit einer eigenen Delegation ist Deutschland auch in diesem Jahr auf der SXSW präsent. Im Vorjahr zähl-te sie über 900 Teilnehmer. In diesem Jahr dürfte die Zahl sogar noch etwas darüber liegen. Zentraler Anlaufpunkt für viele während der SXSW ist das German Haus. Unter der Federführung der Initiative Musik und der Beteili-gung mehrerer Bundesländer reprä-sentiert das German Haus (inklusive eines Standes auf der Trade Show) die deutsche Kultur- und Kreativbran-che. Als Partner des German Haus hat sich das Tochterunternehmen des iSQI, die High5 GmbH, die Förderung der beteiligten Start-ups auf die Fah-nen geschrieben. So werden in diesem Jahr junge Firmen aus Bayern, Baden-Württemberg, Berlin-Brandenburg und Nordrhein-Westfalen finanziell unterstützt. Zudem erhalten die Unter-nehmen fachlichen Support in Sachen nachhaltiger Unternehmens- und Per-sonalplanung.

high5startups

WEB: high5startups.com

ANTELOPE.TECHWEAR - DIE ERSTE LEISTUNGSSTEIGERNDE SPORTBE-KLEIDUNG DER WELT

Schneller, stärker, ausdauernder – ANTELOPE erhöht jeden Trainings-effekt. Die Sportbekleidung der Zu-kunft ist eine Fusion aus Sportswear und Wearable Technology. ANTELOPE besteht aus einer Kompressionsbeklei-dung mit integrierten Elektroden, einer smartphonegroßen Elektronikeinheit sowie einer App zur Steuerung des Systems. Über elektrische Impulse von außen werden Muskelkontraktionen

beim Sport verstärkt – jede sportliche Betätigung wird damit intensiver und deutlich effektiver. Die einzigartige Sportswear setzt auf Elektromuskel-

GRAMMOFY – DAS SPOTIFY FÜR KLASSIK-FANSKlassische Musik neu entdecken und erlebbar machen – das hat sich Gram-mofy aus Stuttgart auf die Fahnen geschrieben. Der Streaming-Dienst ist etwas für Neugierige und Kenner, denn er bietet die Möglichkeit, sowohl neue musikalische Welten kennenzu-lernen, als auch nach bekannten Kom-ponisten und Künstlern aus verschie-denen Klassik-Epochen zu stöbern. Im Zentrum des Angebots stehen wö-chentlich kuratierte „Collections” in denen ausgewählte Werke vorgestellt und von Hintergrundinformationen im Podcast-Format begleitet werden.Das junge Start-up um Gründer Lukas Krohn-Grimberghe will auf diese Wei-se neben Klassikfans vor allem neue Zielgruppen ansprechen, indem es klassische Musik für das Online-Stre-aming zugänglicher macht. Ähnliche

Dienste wie z.B. Spotify sind im Main-streambereich bereits sehr erfolgreich. Mit Grammofy gibt es nun ein Pendant für Klassikfans. Basierend auf mo-dernsten Technologien hat sich Gram-mofy ganz der Liebe zu klassischer Mu-sik, Filmmusik und Jazz verschrieben. Momentan ist der Streaming-Dienst in 17 Ländern präsent. „Wir wollen eine Brücke schlagen zwischen moderner Technologie, zeitgemäßen Formen des Musikkonsums und der Klassischen Musik“, sagt Grammofy-Gründer Lu-kas Krohn-Grimberghe. Die SXSW bietet für ihn eine hervorragende Mög-lichkeit, um neue Kontakte im internati-onalen Musik-Business zu knüpfen.

stimulation (EMS) – eine Technologie, die aus der Rehabilitation sowie dem Leistungssport stammt. Die Elite der Sportwelt hat den Nutzen von EMS bereits erkannt. Stars wie Usain Bolt, Rafael Nadal oder die Fußball-Teams von Bayern München und Real Madrid profitieren seit Jahren von den Trai-ningseffekten dieser Technologie. Wearable Life Science GmbH (“WLS”) ist das Unternehmen hinter der Marke ANTELOPE. Es wurde im März 2014 von Philipp G. Schwarz, Kay Rath-schlag und Patrick Thumm gegründet. Dr. Mynia Deeg stieß im Januar 2016 zum Management Team. Aktuell be-steht das interdisziplinäre Team aus über 25 Mitgliedern, darunter: Serial Entrepreneurs, EMS-Pionieren, Textil- und Elektroingenieuren, Software- und IT-Spezialisten, Sportwissenschaftlern, Vertriebs-, Marketing- und PR-Experten sowie einem Professor der Neurophy-siologie. Viele mit einem internationa-len Background. Unterstützt wird das Team von einem renommierten Beirat sowie sieben Business Angels, die ne-ben der finanziellen Unterstützung ihr Know-how mit in den Entwicklungs-prozess einfließen lassen.

iSQI NEWS

Aus dem iSQI-Konferenzplaner 2017

Vom 20. bis zum 22. März 2017 findet der siebente World Congress for Soft-ware Quality (WCSQ) in Lima (Peru) statt. Er bringt internationale Soft-ware-Experten, innovative Praktiker und inspirierende Redner aus Wirt-schaft und Wissenschaft zusammen.

SOFTWARE QUALITY MEETS IoT

In den drei Tagen wird den Besuchern ein vielfältiges Programm geboten, mit bemerkenswerten Keynotes, pra-xisnahen Tutorials und Workshops so-wie einer Fachausstellung und einem Social Event. Der WCSQ ermöglicht

7. World Congress for Software Quality20. bis 22. März / Lima, Peru


06.03. – 09.03.2017SXSW Edu // Austin

10.03. – 14.03.2017SXSW Interactive // Austin

15.03.2017Swiss Testing Day // Zürich

20.03. – 22.03.20177th World Congress for Software Quality // Lima

25.03. – 31.03.2017HOOD ReConf // München

24.04. – 28.04.2017Mobile Dev & Test Conference // San Diego

15.05.2017TestNet // Nieuwegein

22.05. – 23.05.2017National Software Testing Conference // London

Mit dem Ziel, ein einheitliches Aus- und Weiterbildungsschema für Fach-kräfte des Requirements Engineering zu festigen, haben sich das IREB® und REQB® dazu entschlossen, ihre Bestrebungen nach einer allgemein verbindlichen Ausbildung im Bereich RE unter der Flagge des IREB® fort-zuführen.Durch den Zusammenschluss gewinnt das bereits etablierte Ausbildungspro-gramm IREB® CPRE (Certified Profes-sional for Requirements Engineering) weiter an Bedeutung. Seine Reputati-on und Stellenwert werden zusätzlich gestärkt. Als Zertifizierungsspezialist für das IREB®-Schema unterstützt iSQI die Bündelung der Kräfte.

KOMPETENT UND ERFAHREN BERATEN

Mit iSQI haben Fachkräfte einen erfah-renen IREB®-Partner an ihrer Seite, der

Relevanz des IREB®-CPRE erneut bestätigt

einen tiefen Einblick in das Hauptthe-ma „Software Quality meets IoT“ und in viele andere spannende Themen, wie Mobile Apps, Frauen in der Tech-nologie, Big Data und vieles mehr.

NEUES TRIFFT AUF ALTES

Außerdem haben Besucher die Ge-legenheit, Peru kennenzulernen – ein Land mit vielen kulturellen Einflüssen und einer außergewöhnlichen inter-nationalen Atmosphäre. In dem Kon-trast von Neuem und Alten befindet sich die IT-Branche in einem starken Wachstum.

sich mit der IREB® CPRE-Zertifizierung bestens auskennt und sie kompetent beraten kann. Durch leistungsstarke und innovative Prüfungsverfahren, sein hervorragendes, internatio-nales Netzwerk und dem Angebot von Online-Prüfungen in über 5.200 Pearson VUE-Testcentern unterstützt iSQI maßgeblich das internationale Wachstum des IREB® CPRE.

RABATT AKTION

Mit dem Aktionscode wcsq_isqi_15 erhalten Sie 15 Prozent Rabatt auf den Ticketpreis! Mehr Informationen finden Sie unter: www.wcsq.org

333333

Ende des vergangenen Jahres war das International Software Quality Institutes (iSQI) zu Gast an der Uni-versidad Tecnologica de la Habana. CEO Stephan Goericke und COO Ro-nald Huster trafen dort die Dekanin Dra. Martha Delgado und weitere Unidozenten der Facultad de Ingenie-ria Informatica. Im Gespräch wurden die Kooperationsmöglichkeiten im Rahmen des develoPPP.de-Förderpro-jektes vorgestellt und besprochen. Speziell für die kubanischen Studie-renden des Fachbereichs Centro Estu-dies Ingenier Software (CEIS), wurde nach Zusatzqualifikationen in den Bereichen Software-Testing, Require-ments Engineering, Project-Manage-ment sowie Software Security nach-gefragt. Ende Dezember 2016 wurde ein ent-sprechendes Memorandum of Un-

Partnerschaft mit Universität in Havanna

derstanding für die Zusammenarbeit vereinbart.In der ersten Jahreshälfte 2017 plant iSQI nun zunächst eine TTT-Ausbil-dung im Bereich Software-Testing für die kubanischen Dozenten der Fakul-tät. Diese befähigt die Dozenten dazu, selbst Ausbildungskurse für die Stu-dierenden anzubieten und durchzu-führen.Mit dem Anliegen, Hilfestellung bei der Einführung international aner-kannter Qualifizierungsstandards zu liefern und sich gleichermaßen mit Kubas IT-Experten zu vernetzen, ist iSQI einen weiteren Schritt vorange-gangen. Zusätzlich zu den angebotenen Quali-fizierungsmaßnahmen wird das iSQI der Bibliothek des Fachbereichs eine Auswahl an Fachliteratur zu Verfü-gung stellen.

Die Bayerische Landeshauptstadt München macht sich mit Hilfe des In-ternational Software Quality Institute (iSQI) fit für die Zukunft. Im Rahmen eines speziellen Qualifizierungspro-gramms soll die IT-Fachkompetenz der Beschäftigten weiterentwickelt werden. Hierzu werden von der Stadt verschiedene Ausbildung-Angebote initiiert, die mit einer Abschlussprü-fung enden sollen. Die Stadt München hat zu diesem Zweck das iSQI mit der Organisation, Durchführung und Auswertung die-ser Prüfungen beauftragt. Erste Prü- fungen sollen voraussichtlich schon in diesem Frühjahr stattfinden. Der Kooperationsvertrag läuft vorerst bis Ende 2020.

München startet Qualifizierungs-programm für IT-Fachkräfte

Titelthema

EINFÜHRUNGFalls das Test Driven Development doch noch nicht jedem ein Begriff ist, hier eine kurze Zusammenfassung: Es handelt sich hierbei um eine Vor-gehensweise bestehend aus kurzen Zyklen, in denen der erste vorgenom-mene Schritt immer das Schreiben des Testfalls ist. An dieser abstrakten Definition kann man bereits erahnen: Testen ist hier, wie der Name schon sagt, nicht der Nebenprozess, der durch die einzelnen Projekt-Phasen meist nur mühevoll mitgezogen wird, sondern tatsächlich einer der Haupt-prozesse, an denen sich alle nachfol-genden Schritte orientieren. Das TDD kann somit auch als eine Methode des Software-Design bezeichnet wer-den.

DAS VORGEHENIm Rahmen des TDD werden die Tests bereits vor der ersten Zeile Code ge-schrieben. Dies geschieht natürlich nicht für die gesamte Software, son-dern immer nur für den kleinstmög-lichen lauffähigen Teil der Software, der in diesem Moment umgesetzt werden soll. Das Vorgehen ist hier im-mer das gleiche: Der erste Schritt ist das Schreiben des funktionalen Tests. Die kommende Funktionalität wird in einem Testfall aus Sicht des Benutzers beschrieben. Für funktionale Tests bie-ten sich Abnahmekriterien aus User Stories bestens an. Dieser funktionale Test kann zum Beispiel automatisiert in Selenium1 realisiert werden. Wird etwa einem Onlineshop eine Funktio-nalität hinzugefügt, wie ein Benutzer-login, beschreibt der automatisierte Test eine noch gar nicht existierende Eingabemaske. Das Ziel ist hierbei, dass der Testfall fehlschlägt.

PRAKTISCHE VOR- UND NACHTEILEAls Vorteil fällt hier bereits auf, dass die ersten Tests so elementar und einfach sein müssen, dass sie bis zum Ende des Entwicklungsprozesses be-stehen bleiben und angewendet wer-den können. Man arbeitet also nicht

Vorsichtig, aber zielsicher, sucht sich die Testing Goat, die ihre Heimat in der Python- Welt hat, ihren Weg durch die Software- Entwicklung. Sie interessiert sich nicht für Dirty Hacks und bleibt auch nicht stehen für unpräzise Anforderungen. Dafür hört sie auf User Stories und Testautomatisierung. Der Leser wird hier zwar nicht Bekanntschaft mit der Testing Goat machen, dafür aber ihre „Lebensart“ kennenlernen und verstehen.


Hohe Qualität durch eine testgetriebene Entwicklung

VOR- UND NACHTEILE VON TEST DRIVEN DEVELOPMENT (TDD)

mehr mit komplexen und langen Tests und Test-Szenarien, die bei jeder neuen Anforde-rung umgeschrieben werden müssen, sondern erreicht eine viel höhere Geschwindigkeit durch kurze und essenzielle Tests, auf denen nach Be-lieben aufgebaut werden kann. Der Nachteil ist natürlich genauso offensicht-lich: Zeit. Es kostet anfangs eine Menge Zeit sich daran zu gewöhnen, Testfälle vor dem Code zu schreiben und es kostet Zeit, die Test-fälle vorzubereiten. Existiert ein funktionaler Test, kann die Umset-zung der Funktionalität im Code geplant werden, damit der Testfall gelingt. An dieser Stelle bietet es sich an, Unit Tests zu schreiben, um den kom-menden Code zu prüfen. Dieses Vorgehen stellt sicher, dass es am Ende keine ungetestete Zeile Code mehr gibt. Die Unit Tests setzen genauso wie die funktio-nalen Tests auf einer elementaren Ebene an und decken immer nur den kleinstmöglichen Teil ab, sich orientierend an der fachlichen Umsetzung. Hier besteht wieder der gleiche Vorteil: Die Tests werden so einfach ausfallen, dass sie bis zum Ende des Entwicklungsprozesses behalten wer-den können.Allerdings findet sich auch hier wieder der Nach-teil der Zeit und Umgewöhnung. Dazu kommt noch, dass ein Entwickler, der die Fachlichkeit nicht kennt, Schwierigkeiten haben wird, Unit Tests für einen noch nicht existierenden Code zu schreiben.Existieren jetzt also fehlschlagende funktionale und nicht-funktionale Tests, wird genau so viel Code geschrieben wie notwendig ist, um die Tests beim Ausführen grün zu bekommen.Der letzte, nicht immer erwähnte Schritt ist das „Refactoring“ von Code. (s. Abb. 1) Da sich der funktionale Test auf einer abstrakte-ren Ebene befindet als die Unit Tests, folgen die Unit Tests und der geschriebene Code also dem funktionalen Test - der funktionale Test stellt in diesem Vorgehen eine klar definierte Anforde-rung mit einem klaren Ziel dar. Erst wenn der funktionale Test grün ist, kann davon gespro-chen werden, dass die Anforderung auch tat-sächlich erfüllt wurde.Dieses Vorgehen hat den Vorteil, dass abstrakte fachliche Zusammenhänge als automatisierte Testfälle existieren, bevor mit der Entwicklung begonnen wird, und damit ein klares Ziel ge-schaffen wird, auf das hingearbeitet wird.

WOZU IST DIESER PROZESS NOTWENDIG?Kent Beck, der Quasi-Erfinder des TDD, hat die Notwendigkeit mit einer Metapher beschrieben (Test-Driven Development by Example 2002, S. 10): Das Heben eines Eimer Wassers aus einem Brunnen. Ist der Brunnen nicht allzu tief und der Eimer nicht ganz voll, lässt sich der Ei-mer problemlos heben. Ist der Brunnen tief und der Eimer randvoll, wird das Heben sehr schnell sehr anstrengend. Um zu verhindern, dass der Eimer nach einem Ausrutscher wieder nach un-ten fällt, existiert TDD. Eine der großartigsten Eigenschaften des TDD ist, dass man sich keine Gedanken mehr machen muss, etwas bereits Umgesetztes zu vergessen. Man führt einfach seine automatisierten fach-lichen Testfälle erneut aus und schon ist das Ziel wieder klar erkennbar. Hier wird erkennbar, warum TDD auch als Methode des Software De-signs bezeichnet wird. Offensichtlich entsteht hierbei aber auch ein Nachteil: Sollten die Testfälle von niedriger Qua-lität sein, wird auch die Fachlichkeit der Soft-ware nur ungenügend ausfallen, was spätestens bei den Abnahmetests zu enormen Problemen führt.Wird TDD von Anfang an befolgt, wachsen die Testfälle genau wie die Funktionalität. Anfangs wird vielleicht nur eine dreizeilige Funktion ge-testet, nach ein paar Tagen wird die Funktion erweitert und der Testfall wächst mit. Nach ein paar Sprints, wenn die Funktion zu einer poly-morphen Metaklasse herangewachsen ist, ist die eigentliche Funktionalität immer noch über die Testfälle nachvollziehbar.

DER VORTEIL VON TEST-EXPERTEN IN TDDBei all der Testautomatisierung fragt man sich irgendwann, ob man überhaupt noch eigene Test-Experten braucht. Die Antwort lautet defi-nitiv: ja! Tester sind näher an der Fachlichkeit, er-kennen mit ihrer Erfahrung auch Szenarien, die sonst keine Beachtung finden würden, und sind in der Lage, Entwicklern im Bereich der Automa-tisierung einen Teil der Arbeit abzunehmen. In einem agilen Projekt existiert zwar keine absolu-te Abgrenzung zwischen den Aufgabengebieten, trotzdem sollte die Rolle des Testers Beachtung finden. Die Erfahrung zeigt, dass eine Rolle, wel-che sich primär um das Erkennen von Risiken und Fehlern in der Software kümmert, auch bes-sere Ergebnisse liefert als eine gemischte Rolle, der diese Aufgabe nur zufällig zugeteilt wurde.

TEST DRIVEN DEVELOPMENT besteht aus kurzen Zyklen, in denen der erste vorgenommene Schritt immer das Schreiben des Testfalls ist.

353535

Titelthema

Zum Beispiel übersieht ein Entwickler, der sich primär nur mit einem kleinen Teil der Software beschäftigt, schnell themenübergreifende Test-fälle, die man nur ableiten kann, wenn man sich auch bereits aktiv mit Komponenten und Um-Systemen auseinandergesetzt hat.Software-Tests nur um des Testens Willen hel-fen nicht viel, am Ende steht man vor einem Berg von Tests, hat keinen Überblick, was eigentlich genau getestet wird, und bei jeder Code-Ände-rung werden viele der Units und funktionalen Tests rot. Schlimmstenfalls dauert das Fixen der Tests dann genauso lange wie das Schreiben des Codes selbst.Es ist leicht, bei einer komplexen Business-Soft-ware den Überblick zu verlieren. Genauso leicht ist es, die relevanten Tests aus den Augen zu verlieren. Ohne Kontrolle und Leitung mit klarem Testvorgehen kann eine Test-Suite schnell ge-nauso komplex und unüberschaubar werden, wie die eigentliche Software. Hier hilft auch nur die Erfahrung eines professionellen Testers, der


von Anfang an mit einem klaren Testvorgehen den Blick auf das Wesentliche lenkt.

DAS TESTEN ALS ROTER FADENDen Grundstein legen hier auch bereits die An-forderungen an die Software. Wenn mit einer Spezifikation gearbeitet wird, ist es wichtig sich von Details zu entfernen. Nicht das Wie sollte spezifiziert werden, sondern das Was. Es sollten Fachlichkeiten und keine Geschäftslogik im Pro-satext geliefert werden.Fehlt ein grundsätzlicher Bezug zur Fachlichkeit, wird nur noch das umgesetzt, was die Spezifika-tion vorgibt, ohne zu verstehen, was eigentlich gerade passiert. Entsprechend wird die Entwick-lung auch keine Fachlichkeiten mehr abdecken, sondern nur noch komplexe, unüberschaubare Regelwerke, die sie selbst nicht versteht.Legt man den Fokus auf Fachlichkeit anstatt auf technische Details, ist der Vorteil, dass sich eine Fachlichkeit, wenn sie richtig beschrieben wird, so bald nicht ändern sollte. Technische Details

Abb. 1: Der vereinfachte TDD Prozess. Quelle: selbsterstellte Grafik

SCHREIBE DEN

FUNKTIONALEN TEXT

SCHREIBE CODE

IST DER

TEST GRÜN?

SOLLTE REFACTORED

WERDEN?JA

JA

NEIN

NEIN

373737

hingegen ändern sich ständig – mit jedem neuen Release können sich größere und kleinere technische De-tails ändern, während die Fachlichkeit gleichbleibt.Auch in der agilen Entwicklung treten immer wieder dieselben Irrtümer auf: Man glaubt, nah an der Entwicklung zu sein, aber in Wirklichkeit bewegt sich alles in abstrakten Regelwerken und kafkaesker Geschäftslogik. Gibt die Spezifikation bereits Datentypen und Funktionslogik vor, sinkt die Motivati-on die eigene Arbeit zu verstehen, sig-nifikant. Durch die Beschränkung auf Use Cases und anfängliches Realisie-ren durch fachliche Tests können diese Gefahren überwunden werden.

ANFÄNGLICHE HÜRDEN ÜBERWINDENDas gesamte Vorgehen hört sich in der Theorie gut an, lässt sich in der Praxis allerdings meistens nur schwer reali-sieren. Abgesehen von den bekannten Widerständen in einem Projekt muss hierfür auch die richtige Einstellung im Team vorhanden sein. Die Umstel-lung, zuerst Testfälle zu schreiben und danach den Code, scheint anfangs zu aufwändig und umständlich. Einfacher wird es, wenn man sich die Rosinen heraus pickt und nicht verlangt, dass sofort eine komplette Umstellung erfolgt. Hier sind die Test-Experten gefragt, da für sie der Um-stieg am einfachsten ist. Wenn man als Tester bereits eng mit der Entwick-lung zusammenarbeitet, ist es gar kein Problem, eine GUI zu automatisieren, bevor die Entwicklung überhaupt be-

Sascha Rezagholinia ist Technical Test Analyst bei Sogeti Deuschland. Er beschäftigt sich intensiv mit Techno-logien, Methoden und Lösungsansätzen im Bereich der Software Entwicklung.

gonnen hat. Somit wird Fachlichkeit von Anfang an durch automatisierte Tests abgebildet und der Entwickler orientiert sich bei der Umsetzung sei-ner Arbeit an den vorgegebenen Tests.Schlägt ein Testfall fehl, leitet dieser den Entwickler über Stacktraces Schritt für Schritt zum Ziel. Das hört sich kom-pliziert an – werden die Testfälle al-lerdings ausführlich und methodisch geschrieben, ergibt sich hierdurch ein roter Faden, dem der Entwickler fol-gen kann. Folglich orientiert sich der Entwickler nicht an Fließtext und Stich-punkten aus User Stories, sondern an praktischen Beispielen über die Test-fälle.Wichtig für den Tester ist hierbei auch, sich nicht zum Over Engineering der Tests verleiten zu lassen. Kleine, ein-fache Skripte, die möglichst nah an der Fachlichkeit und branchenspezi-fisch sind, nach Bedarf einzelnen Sto-ries und Abnahmekriterien zugeordnet werden können und dem Entwickler jederzeit zur Verfügung stehen, sind definitiv einem großen Automatisie-rungsframework vorzuziehen.In einem aktuellen agilen Projekt von Capgemini konnte durch das Anwen-den der TDD-Methodologie, verant-wortlich geführt durch das Test-Team, der Testprozess vor den Entwicklungs-prozess gestellt werden. Die Verände-rung wurde vom Entwicklungsteam und den Projektverantwortlichen als sehr positiv bewertet.Als besonders hilfreich bei der Umstel-lung hat sich gezeigt, dass es am be-sten ist, die neuen Ideen anfangs nur

mit einem oder zwei Lead Developern zu besprechen und diese dann die neu-en Ideen ins Team tragen zu lassen. Zur Unterstützung der Tester wurde in dem Projekt die webbasierte GUI der Software so angepasst, dass alle Ele-mente mit fixen IDs versehen wurden. So konnten automatisierte Testfälle, die von den Entwicklern auch aktiv ge-nutzt wurden, bereits zu Anfang des Sprints entwickelt werden, um ihre Arbeit zu kontrollieren. Durch die Un-terteilung der Test Automatisierung in kleine, in sich geschlossene Skripte konnten diese auch problemlos im Versionsverwaltungstool Git in jedem Softwarebranch geführt werden und so immer der richtige Test zur richtigen Version zugeordnet werden.

FAZIT Durch Anwenden der Methode der testgetriebenen Entwicklung erreicht man quasi eine Fusion des Test- und des Entwicklungsprozesses. Durch die zusätzliche Fokussierung auf den Schwerpunkt Test rückt die Qualität in den Vordergrund, als Anforderung an das gesamte Projekt. So kann nicht nur eine stetig hohe Qualität geliefert wer-den, sondern auch komplexe Ände-rungen können so durch das gesamte Projekt hindurch verfolgt werden.

Abb. 2: IDs ermöglichen es bereits GUI Testfälle zu erstellen, ohne dass eine GUI überhaupt vorhanden ist.

Quelle: selbsterstellte GrafikQUELLVERWEIS:https://www.sogeti.de/blog-selenium

Docker-Container bieten eine einfache, schnelle und robuste Möglichkeit, Software zu ent-wickeln, zu verteilen und laufen zu lassen – besonders in dyna-mischen und verteilten Umge-bungen. Mit diesem praktischen Leitfaden lernen Sie, warum

Container so wichtig sind, was durch den Einsatz von Docker möglich ist und wie Sie es in Ihren Entwicklungsprozess einbinden. Dieses Buch ist ideal für Entwickler, Operations-Techniker und

Sudoku

4 1

1 6 4 7

9

6 8 2 9

6

3 9 5 6

1

4 2 7 1

6 4

Buchstaben: 1=M, 2=E, 3=U, 4=G, 5=H, 6=A, 7=Z, 8=N, 9=S

LÖSUNGSWORT

*Der Rechtsweg ist wie immer ausgeschlossen. Die Mitarbeiter der iSQI GmbH und des ASQF e.V. sowie sämtliche am Gewinnspiel beteiligten Personen sind von der Teilnahme ausgeschlossen. Teilnehmer erklären sich mit der Veröffentlichung ihres Namens in der Folgeausgabe einverstanden.

SQ № 43

Thema: Qualitätssicherung in der Digitalisierung

Anzeigenschluss:15.05.2017

Redaktionsschluss: 28.04.2017

erscheint im Juni 2017№ 43

HERAUSGEBER

ASQF e.V.

Friedrich-Engels-Str. 24, 14473 Potsdam

Tel +49 331 231810-29

Fax +49 331 231810-10

[email protected], www.asqf.de

REDAKTION

V.i.S.d.P.:

Stephan Goericke (Hauptgeschäftsführer)

Chefredaktion: Christin Senftleben

Redaktionsteam: Julia Schirmer,

Anja Schreinert, Isabel von Gustedt

Friedrich-Engels-Str. 24, 14473 Potsdam

Tel +49 331 231810-56

Fax +49 331 231810-10

[email protected],

www.sq-magazin.de

SATZ / LAYOUT

Frenkelson Werbeagentur, Potsdam

www.frenkelson.de

FOTOS: ASQF e.V. und iSQI GmbH

Titel: ©PR Uwe Friedrichsen

Seite 4, 8, 11 ©shutterstock_d1sk

Seite 5 ©shutterstock_hanoiki

Seite 18 ©shutterstock_Rawpixel

Seite 24 ©shutterstock_MrCreative

Seite 28 ©shutterstock_RoschetzkyProductions

Seite 28 PR Smoope

Seite 28 PR Datarella

Seite 30 PR Holoplot

Seite 30 PR evopark

Seite 31 PR Wearable Life Science

Seite 31 PR Grammofy

Seite 31 ©shutterstock_Dja65

Seite 32 ©shutterstock_ UNIKYLUCKK

Seite 33 ©shutterstock_Prasit Rodphan

Seite 34 ©shutterstock_Timofey123

Seite 36 ©shutterstock_dotshok

Alle Portraits und Grafiken mit freundlicher

Genehmigung der Autoren.

DRUCK: PRINTEC OFFSET, Kassel

DRUCKAUFLAGE: 4.000 Stück

INTERNETAUSGABE: www.sq-magazin.de

MEDIADATEN

Gern senden wir Ihnen unsere Mediadaten zu.

Richten Sie Ihre Anfrage an

[email protected]

Namentlich gekennzeichnete Beiträge müssen

nicht mit der Meinung der Redaktion überein-

stimmen. Die Redaktion behält sich das Recht

auf sinngerechte Kürzung und Bearbeitung

eingereichter Manuskripte vor. Wir machen da-

rauf aufmerksam, dass Daten nicht an Dritte

weitergegeben und ausschließlich zur internen

Auswertung herangezogen werden können.

Im Gespräch Impressum

Administratoren – insbesondere, wenn Sie einen DevOps-Ansatz verfolgen. Es nimmt Sie mit auf eine Reise von den Grundlagen bis hin zum Ausführen Dutzender Container auf einem Multi-Host-System mit Networking und Sche-duling. Im Verlauf des Buches erfahren Sie, welche Schritte zum Entwickeln, Testen und Bereitstellen einer Webanwendung mit Docker notwendig sind. Senden Sie bis zum 4. Mai das Lösungswort des Gewinnspiels an [email protected] und gewin-nen Sie eines von fünf Büchern.

Mitmachen und gewinnen!

Die Lösung des letzten

Sudokus lautete:

USER EXPERIENCE

Die Gewinner aus Heft 41 sind:

Dino Saric, Aachen // Timo Fischer,

Paderborn // Christina Papava-

sileiou, Konstanz // Frank Ossig,

München // Christian Frederking //

Nürnberg

Qualitätssicherung in der Digitalisierung Das ist unser Schwerpunktthema in der Juniausga-be. Die Beiträge unserer Autoren beleuchten ver-schiedene Blickwinkel rund um das Thema.

Sie haben eine Meinung dazu oder möchten einen interessanten Artikel einreichen? Dann schreiben Sie uns an: [email protected]

Branchenticker

Fachgruppentermine: März - Juni 2017

Alle Termine und Anmeldung unter: www.asqf.de/events

MÄRZ 2017

KW Mo Di Mi Do Fr Sa So

09 1 2 3 4 5

10 6 7 8 9 10 11 12

11 13 14 15 16 17 18 19

12 20 21 22 23 24 25 26

13 27 28 29 30 31

APRIL 2017


13 1 2

14 3 4 5 6 7 8 9

15 10 11 12 13 14 15 16

16 17 18 19 20 21 22 23

17 24 25 26 27 28 29 30

MAI 2017


18 1 2 3 4 5 6 7

19 8 9 10 11 12 13 14

20 15 16 17 18 19 20 21

21 22 23 24 25 26 27 28

22 29 30 31

JUNI 2017


22 1 2 3 4

23 5 6 7 8 9 10 11

24 12 13 14 15 16 17 18

25 19 20 21 22 23 24 25

26 26 27 28 29 30

MÄ

RZ

09.03.2017: FG Requirements Engineering, Franken 18:00 – 20:00 UhrThema: Anforderungen an sichere Software ermitteln und dokumentieren

16.03.2017: FG Agilität, Franken 19:00 – 21:00 UhrThema: Agile Hardware, aber wie? Ein Erfahrungsbericht

21.03.2017: FG Safety & Security, Rhein-Main 18:00 – 20:00 UhrVorankündigung

AP

RIL

03.04.2017: FG Requirements Engineering, NRW 18:00 – 20:00 UhrThema: Save lifes and save time – efficient and effective safety requirements analysis and elicitation

05.04.2017: FG Software Test, Norddeutschland 18:00 – 20:00 UhrThema: Change Management

06.04.2017: FG Requirements Engineering, Franken 18:00 – 20:00 UhrVorankündigung

10.04.2017: FG Mobile Devices & Apps, Rhein-Main 18:00 – 20:00 Uhr

MA

I 07.05.2017: FG Software Test, Niedersachsen 18:00 – 20:00 UhrVorankündigung

JU

NI 01.06.2017: FG Requirements Engineering, Franken 18:00 – 20:00 Uhr

Vorankündigung

Die ASQF-Arbeitsgruppe IoT befindet sich auf einem guten Kurs für einen geplanten Release des Schemas in der zweiten Jahreshälfte 2017 – Halbzeit sozusagen. Ende letzten Jahres wurden in einem eintägigen Workshop der AG die Details des inhaltlichen Outlines für diesen Kurs freigegeben. Damit kann die Arbeitsgruppe nun die Detaillierung der Lehrplaninhalte ausarbeiten. Vermittelt werden sollen die Grundlagen der technischen Expertisen eingebunden in die spezifischen Soft Skills. „Quality Engineering“ ist hierbei Programm. Dadurch soll der Industrie Hilfe in Form von Methoden, Leitlinien zur Qualitätssicherung und Absicherung von IoT-Lösungen durch Qualifizierungsschemata und ein Glossar als De-facto-Stan-dard angeboten werden.

Beider GFB EDV Consulting und Services GmbH, Oberursel, gibt es Veränderungen in derGeschäftsführung. GFB-Gründer und Geschäftsführer Bernhard Baumgarten gibt die Führung ab, bleibt jedoch weiterhin als Key-Account-Managerund Senior Consultant für die GFB tätig. Michael Völker, langjähriger Ge-schäftsführer, bleibt weiterhin in dieser Position. Neu in der-Geschäftsführung sind Andreas Günther, zuletzt Vice Presi-dent der Capgemini Gruppe,und Peter Laggner, Vorstand und einer der Gründer der Trimetis Gruppe.

HALBZEIT! Quality Engineering für das Internet der Dinge

ASQF Rhein-Main Testing Day Jürgen-Ponto-Platz 1, 60329 Frankfurt am Main

Motto: „Aus der Praxis – für die Praxis: Austausch im Open Space Format“Keynote: Claudine Villemot-Kienzle

ASQF Testing Day NRW Life Science Center, Merowinger Platz 1a, 40225 Düsseldorf

Motto: Future of TestingKeynote: Prof. Dr. Andreas Spillner

Trimetis AG übernimmt GFB

FUNDAMENTALS OF TESTINGFür Einsteiger und Profis: ISTQB® Certification Product Portfolio

www.german-testing-board.info

T-Systems Multimedia Solutions GmbH

GTB Premium Partner

GTB-Anz-SQ-Mag_A4_170210.indd 1 10.02.17 07:14

Date post:	15-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

TITELTHEMA: Quality Driven DevOps · YouTube 28% Facebook 12% Unternehmensblogs 78% 60% 48h...

Documents