Page 1

issn 1869-5442

Magazin

Nr. 9 | November 2013

Softwareentwicklung aus Karlsruhe

Alles kontorlliert? Gut, besser, am besten Automatisierte Builds und Tests in einem Multi-Plattform-Umfeld Warum guter Code und agile Tests ein schönes Paar sind VKSI hat Special Interest Group »Enterprise Agility« gegründet

Das Magazin des

Verein der Karlsruher Software-Ingenieure


EDITORIAL

Willkommen!

Liebe Leserin, lieber Leser, Die Erkenntnis an sich ist nicht neu, aber sie führt zu immer neuen Konsequenzen: Qualität erfordert die Bereitschaft aller Beteiligten. Da aber Produkte und Dienstleistungen heute in der Regel von großen Gruppen hergestellt werden, in denen der Beitrag des Einzelnen gar nicht mehr nachzuvollziehen ist, wird eben diese Bereitschaft immer wichtiger. Und damit werden auch die Umgebungen, in denen Menschen ihr Bestes geben wollen und können, immer wichtiger. Ein zentraler Aspekt ist es daher, dass jede/r die eigene Arbeit als Beitrag zu einer komplexen Leistung sehen kann und damit die Integration des eigenen Beitrags als Teil der Qualitätssicherung. Dieser Beitrag hat viele Gesichter. Einige Aspekte von Qualitätssicherung beschreiben VKSI Autoren in diesem Magazin: Unter dem Titel »Warum guter Code und agiles Testen ein schönes Paar sind« beschreiben Maynard Harstick und Daniel Knapp, wie »Agiles Testen« den Ansatz verfolgt, Testen und Entwickeln eng zu verzahnen. »Professionelle Qualitätssicherung in einem Multi-Plattform-Umfeld« lautet der Titel des Artikels von Alexander Schmitt, Jürgen Ockert und Ralf Payer. Und schließlich fragen sich Edgar Schüber und Sven Fischer, ob die Kombination »­Prozesse und Qualität« ein Oxymoron ist, also eine rhetorische Figur aus zwei sich gegenseitig ausschließenden Begriffen. Ralf Eichhorn schreibt über smarter city Karlsruhe, hier geht es nicht zuletzt um die Lebensqualität in unserer Stadt. Und da das Thema Qualitätssicherung und Tests auch auf dem Entwicklertag, der jährlich in Karlsruhe stattfindenden Konferenz für Software Engineering, eine große Rolle gespielt hat, haben wir noch eine kleine Übersicht über die dort gehaltenen ­Beiträge beigefügt.

Christian Popp, Arvato Infoscore, Prof. Dr. Ralf Reussner, KIT / FZI

Auch der VKSI versucht, seine Sache immer besser zu machen. Daher haben wir auf dem Karlsruher Entwicklertag sehr genau zugehört und daraufhin unter anderem die Anregung aufgegriffen, weitere Austauschmöglichkeiten für das Thema »Enter­ prise Agility«, die Übertragung der Werte und Prinzipien der Agilität auf das ganze Unternehmen zu schaffen. Wir haben eine Special Interest Group »Enterprise Agility« innerhalb des VKSI gegründet und konnten dank unserer Sponsoren für das »kick-off«-Meeting die Scrum-Legende Ken Schwaber engagieren. Die Special Interest Group »Enterprise Agility« wird in Zukunft eine Plattform für den direkten und regelmäßigen Austausch innerhalb der regionalen IT -Community bieten. Auch einen Infomarkt des Cyberforums haben wir zum Thema Erfolgsfaktoren einer agilen Transition gestaltet. Wir planen zur Zeit weitere Aktivitäten dieser SIG Enterprise Agility für das nächste Jahr uns freuen uns über Ihre Anregungen und Beiträge. Doch auch eine traurige Nachricht haben wir zu vermelden: Professor Krüger, einer der Gründerväter der deutschen Informatik, ist am 9.10.2013 verstorben. Unseren Nachruf lesen Sie auf Seite 13.

Freundliche Grüße Ihre Christian Popp und Ralf Reussner

2

VKSI MAGAZIN Nr. 9 November 2013


INHALT

Magazin

Softwareentwicklung aus Karlsruhe

EDITORIAL

Christian Popp, Professor Dr. Ralf Reussner: Willkommen! 

GUT, BESSER, AM BESTEN

Drum prüfe, wer sich ewig bindet –

Warum guter Code und agile Tests ein schönes Paar sind. 

Nr. 9 | November 2013

3

4

Karlsruhe wird zur SmarterCity –

Vernetztes Handeln erhöht die Strahlkraft von Stadt und Region 

8

Automatisierte Builds und Tests –

Professionelle Qualitätssicherung in einem Multi-Plattform-Umfeld 10 Werkzeuge und Erfahrungen –

Der Track »Quality Assurance und Testing« auf dem Entwicklertag 201316 Prozesse und Qualität –

Oxymoron oder schwerlich zu erreichender Idealzustand 22

NACHRUF

Professor Dr. Gerhard Krüger

RÜCKSCHAU

Sneak-Previews des VKSI:

13

HockeyApp Framework, Robolectric und Saphir Fork.

VKSI Sneak Preview zum Thema »Android QS« 

Test-Design, Performance-Analyse und Neuerungen bei JUnit 4.11.

VKSI Sneak Preview zum Thema »Testen, aber agil« 

15

KOLUMNE CYBERTRENDS

Free WLAN Karlsruhe – jetzt noch draht- und kostenloser! 

20

VKSI INTERN

VKSI hat Special Interest Group „Enterprise Agility“ gegründet

27

NACHLESE

Gut, besser, am besten

26

IMPRESSUM 

ANZEIGE

VKSI MAGAZIN Nr. 9 November 2013

14

26

Wirtschaftsföderung Karlsruhe 

25

3


GUT, BESSER, AM BESTEN

Drum prüfe, wer sich ewig bindet Warum guter Code und agile Tests ein schönes Paar sind

What you get is what you see – was passiert jedoch, wenn man beim Testen nicht sieht, was man sehen wollte? Werden Tests und Entwicklung zu sehr getrennt, dann kann »zurück auf Los« ein sehr weiter Weg sein. Besonders ein großer zeitlicher Abstand zwischen der Codeerstellung und den Tests kann die Entwicklungsgeschwindigkeit deutlich verlangsamen. Je später mangelhafte Codequalität offen gelegt wird, umso aufwändiger wird es, sie zu verbessern. Agiles Testen verfolgt daher den Ansatz, Testen und Entwickeln eng zu verzahnen.

4

Automatisierte, einfache Tests von Anfang an reduzieren die Zahl komplexer Tests am Ende. Außerdem fungieren die Tests als Sicherheitsnetz für Entwickler beim Refaktorisieren. Dadurch bleibt der Code flexibel und kann kontinuierlich an die gegebenen Anforderungen angepasst werden. Eine hohe Testabdeckung wird so zum Schlüssel für bessere Softwarequalität. Es klingt paradox und ist doch nur eine Frage von Ursache und Wirkung: Softwaretests stehen für einen Anfang, unabhängig davon, an welcher Stelle des Produktionsprozesses sie

VKSI MAGAZIN Nr. 9 November 2013


von Maynard Harstick und Daniel Knapp

4. Integrationstests

Dauer

Anzahl

Wenige, umfangreiche Tests; hohe Ausführungszeit

3. Test mit realer Persistenzschicht

mit Applikationsserver ohne Applikationsserver

2. Test mit Persistenzschicht (HSQL-DB) 1. Test von POJOs (reine Business-Logik) Viele Tests; geringe Ausführungszeit

Abbildung 1: Testpyramide

platziert sind. Das gilt zumindest dann, wenn sie nicht hundertprozentig fehlerfrei durchlaufen werden. Ein Test legt die funktionale Qualität der Software offen; verändern kann und soll er sie nicht. Insofern ist er die Instanz, die entscheidet, ob die Marschrichtung hin zur Auslieferung eingeschlagen wird oder zurück an den Start. Aber das ist nur die Wirkung. Die Ursache liegt nicht im Test selbst, es sei denn, er wurde fehlerhaft aufgesetzt. Sie liegt im Code. Und damit verlangt jeder Fehler im Code, an den Anfang der Programmierung oder gar der Konzeptionierung zurückzukehren. Diese Rückkehr kann aufwändig und teuer werden, und das umso mehr, je größer das Delta zwischen Entwicklung und Eintreffen des Feedbacks wird. Gerade der klassische Ansatz, der Entwicklung und Test personell wie zeitlich komplett trennt, kann hier problematisch werden. Anstatt also das Testen einer eigenen – und autark agierenden – Abteilung zu überlassen,

Erschienen im Java Magazin 9.2013. Das Java-Magazin über sich: Mehr als neun Millionen Entwickler nutzen Java. Je größer die Anwendergruppe desto wichtiger ist ein Magazin, das Java-Themen praxisnah aufbereitet. Softwarearchitekten, Projektleiter und Entwickler vertrauen auf die Kompetenz des Java Magazins. Anerkannte Autoren lassen ihre Leser an ihrem Know-how über Java, Enterprise-Architektur, Cloud, Agile Methoden und Tools teilhaben. Das Java Magazin hat sich im deutschsprachigen Europa zur unangefochtenen Nr. 1 der Java-Bewegung entwickelt.

VKSI MAGAZIN Nr. 9 November 2013

bringt die agile Vorgehensweise die Testexperten und die Entwickler zusammen, idealerweise ins gleiche Team. Denn der rein »externe« Blick hat einige Nachteile: Es bedeutet Zeit und Aufwand, sich in Produktinkremente hineinzudenken, die jemand anders erstellt hat. Je länger die Zeitspanne zwischen Programmierung und Feedback wird, desto höher ist die Wahrscheinlichkeit, dass auch der Entwickler inzwischen gedanklich in andere Themen involviert ist und sich dann selbst erneut einarbeiten muss. Nicht zuletzt steigt die Gefahr, dass auf den fehlerhaften Code längst andere Inkremente aufbauen, die dann zwangsläufig mitbetroffen sind – ein Dominoeffekt der unerwünschten Art. Das ist ein Grund, warum agiles Software Engineering auf konstantes und direktes Feedback setzt und dazu Entwicklung und Testen zu engen Freunden oder Kooperationspartnern macht. Der Test wird zu einer »ausführbaren Spezifikation«, die entweder der Entwickler oder der Tester aufsetzt, sobald die Anforderungen vollständig sind. Unit Tests entstehen vor und beim Schreiben von eigentlichem Produktivcode. Man kann sagen, der Produktivcode wird anhand eines Unit Tests entwickelt. Dabei entspricht der Test einer recht feingranularen Spezifikation der jeweiligen Funktonalität. Insofern erfüllt der Code immer die zugrunde liegende Spezifikation eines Unit Tests. Insgesamt klingt das zunächst, als ob gerade Unit Tests viel Aufwand für die Entwickler verursachen. Tatsächlich sind sie jedoch gleich aus zwei Gründen rationell: Erstens, weil für den Produktivcode eben nur so viel entwickelt wird, bis der die Anforderung spezifizierende Test erfüllt ist. Zweitens, weil die Fülle an Unit Tests am Anfang verhindert, während des Lebenszyklus der Software Bugschulden anzuhäufen. Natürlich p

5


GUT, BESSER, AM BESTEN

p

ist es schön, wenn sich Entwickler rein auf die Funktionalität konzentrieren können. Nur bringt es nicht viel, wenn die Zahl der zu fixenden Bugs synchron mit der Lebensdauer der Software steigt und daher mehr und mehr Zeit ausschließlich für Reparaturarbeiten benötigt wird – bis, im Extremfall, nur noch Schadensbegrenzung möglich ist. Diese Art von Hypothek sollte beim agilen Vorgehen gar nicht erst entstehen. Beispielsweise deswegen nicht, weil der Code praktisch ständig refaktorisiert wird. Für dieses Refaktorisieren bilden die Tests eine Art Sicherheitsnetz, indem sie die Funktionalität einer Software dokumentieren. Mit diesem Schutz können die Entwickler den Code »aufräumen«, verschlanken und an ihm feilen, ohne Funktionalitäten zu gefährden. Test nicht gleich Test Unabhängig von der Vielzahl an Bezeichnungen, Testtypen und Nomenklaturen lassen sich Testfälle in der so genannten Testpyramide (Abb. 1) nach ihrer Abstraktionsebene gliedern. Anders gesagt unterscheiden sich die Testfälle der einzelnen Ebenen hinsichtlich ihrer Komplexität und Zeitdauer. Demnach empfiehlt es sich, die einzelnen Testfälle in der Praxis unterschiedlich einzusetzen. Wie, das zeigt ein Beispiel aus dem Unternehmen arvato infoscore GmbH, ein Dienstleister für ein integriertes und wertorientiertes Management von Kundenbeziehungen und Zahlungsflüssen. Als solcher bearbeitet das Unternehmen bis zu 50 000 Bonitätsanfragen pro Stunde. Die durchschnittliche Antwortzeit beträgt für drei Viertel aller Bonitätsanfragen weniger als eine Sekunde, bei insgesamt ca. 40 Millionen gespeicherten Merkmalen. Die zugrunde liegende Systemlandschaft ist seit fünfzehn Jahren gewachsen und entsprechend komplex. Einzelne Systemkomponenten hatte die arvato infoscore GmbH selbst entwickelt, andere wurden von Dienstleistern erstellt und später übernommen. Derzeit werden nun die Einzelsysteme in einer plattformbasierten Lösung konsolidiert. Dazu erteilte die arvato infoscore GmbH dem Karlsruher Beratungs- und Entwicklungshaus andrena objects den Auftrag, die Systeme

6

zu analysieren und Empfehlungen abzuleiten. Eine dieser Empfehlungen lautete, die Testabdeckung weiter zu erhöhen, besonders bei den älteren Systembestandteilen. Denn diese hohe Testabdeckung bildet die Voraussetzung für umfangreiche Systemumstrukturierungen, beispielsweise, um eine technische Schichtung einzuführen. Die angestrebte Erhöhung der Testabdeckung ist in diesem Fall ein Synonym für »Ausbau der automatisierten Tests«. Dazu entwickelte andrena objects ein Testkonzept, das primär für ein Teilprojekt pilotiert wurde. Seine beiden wesentlichen Eigenschaften bestehen darin, erstens die Testfälle nach ihrer Abstraktionsebene zu klassifizieren – sprich, die oben ­erwähnte Testpyramide einzuführen. Zweitens unterstützen entsprechende Hilfsklassen jede Testebene. Dazu nehmen sie n ­ ötige Konfigurationen vor und stellen oft benötigte Funktionen bereit. Das ermöglicht den Entwicklern, sich auf das Schreiben der Tests zu konzentrieren. Innerhalb der Testpyramide bilden codenahe, reine Unit Tests die unterste und breiteste Ebene. Sie testen ausschließlich die Businesslogik, prüfen einzelne Klassen, sind permanent ausführbar und nehmen nur Sekunden an Laufzeit in Anspruch. Gemeinsam bilden sie das primäre Fangnetz, innerhalb dessen die Software restrukturiert und weiterentwickelt werden kann. Rein theoretisch ließe sich die gesamte Funktionalität auf dieser Ebene prüfen. Die Praxis hingegen ist häufig komplexer, weil Fremdsysteme angebunden werden, im speziellen Fall eine Datenbank. Deshalb stehen auf der zweiten Ebene Integrationstests, in der lokalen Entwicklungsumgebung allerdings nicht gegen die reale Persistenzschicht, sondern gegen eine »HSQL -inMemory«-Datenbank. Diese virtuelle Datenbank ist auch für mehrere gleichzeitig testende Entwickler schnell ansprechbar und sichert die lokale Unabhängigkeit der Tests und damit die Konsistenz des Zustands. Gleichbleibende Ausgangslagen bedeuten wiederholbare Tests, und die sind ihrerseits eine der Grundbedingungen für agiles Testen. Alle Änderungen der Datenbank nach dem Test zurückzunehmen – was hier der Fall

VKSI MAGAZIN Nr. 9 November 2013


ist –, verhindert die unerwünschten Interferenzen zwischen den einzelnen Tests. Trotzdem sind natürlich auch Tests gegen die reale Datenbank sinnvoll. Sie laufen in der dritten Ebene und gewährleisten, dass die Persistenzschicht richtig konfiguriert wurde. Diese drei Arten von Testfällen bewegen sich innerhalb der Java Virtual Machine, im Idealfall werden sie alle innerhalb eines definierten Zeitplans automatisiert ausgeführt, z. B. auf einem Build-Server (wie Hudson oder Jenkins). Die oberste Schicht an Integrationstests berücksichtigt, dass sich manche Konfigurationen erst nach dem Hochfahren des Servers überprüfen lassen, wenn ein System auf einem Applikationsserver läuft. Tests der Ebene 4 starten zuerst den Server und schicken dann von außen Anfragen an das zu testende System. Diese Tests werden sowohl manuell als auch automatisiert durchgeführt. Der Testmanager innerhalb des Scrum-Teams leitet diese Tests, die einen hohen Automatisierungsgrad haben. Die Ergebnisse dieser Tests und die enge Zusammenarbeit der Entwickler mit den Testmanagern innerhalb des Sprints helfen hierbei, dann schnell auf eventuelle Fehler zu reagieren. Unabhängig davon, wer testet: Generell lautet die Faustregel, dass die Anzahl der Tests abnehmen sollte, je höher die Testebene ist. Denn synchron mit der Ebene steigt die Komplexität, nicht nur im Schreiben der Tests, sondern auch in der Ausführung. Wird etwa die Businesslogik in allen denkbaren Varianten auf der untersten, also Unit-Test-Ebene durchgespielt, dann reichen auf der Ebene der Integrationstests exemplarisch ein positives und ein negatives Beispiel. Da die Tests der untersten Ebene die schnellsten und einfachsten sind, sinkt der Gesamtaufwand signifikant. Der abgestufte Einsatz der verschiedenen Testfälle macht es den Entwicklern leichter, ihr Testmanagement in diesem Sinne effizienter zu gestalten.

VKSI MAGAZIN Nr. 9 November 2013

Fazit Tests gezielt weitreichend zu automatisieren und, je nach Ab­straktionsgrad, unterschiedlich einzusetzen, erhöht die Testabdeckung und damit mittelbar die Codequalität. Damit sinken die ansonsten sehr häufigen, späteren Kosten zur Fehlerbehebung deutlich. Außerdem ist die hohe Testabdeckung elementare Voraussetzung für das Refaktorisieren, das seinerseits zur Basis des agilen Programmierens gehört. Und für agiles Programmieren hat sich das Beispielunternehmen arvato infoscore GmbH klar entschieden. Dazu werden bereits XP-Techniken wie Pair Programming und Test-First eingesetzt. Erste Eindrücke der betroffenen Entwickler und Fachbereiche sind sehr positiv. Im Verbund mit den Testfällen auf verschiedenen Ebenen wurde also die Basis gelegt, die Softwarequalität noch weiter zu erhöhen – sei es aus Anwender- oder aus Entwicklersicht. Womit dann auch geklärt wäre, warum agiles Testen und guter Code ein wirklich schönes Paar sind. Agiles Testen unterstützt Entwickler dabei, guten Code zu entwickeln. Guter Code ist das Ziel jedes Entwicklers. Und wirtschaftlich sinnvoll. Maynard Harstick ist Testmanager bei arvato infoscore im Bereich IT-Risk Management. Er ist seit über fünfzehn Jahren in der Softwarequalitätssicherung sowohl im klassischen Entwicklungsbereich als auch im agilen Umfeld tätig. Daniel Knapp studierte Wirtschaftsingenieur­ wesen am KIT und arbeitet seit 2005 als Softwareentwickler bei der Maynard Harstick andrena objects ag. 2010 wurde er zum Leiter des Geschäftsfelds Lösungen berufen. Sein Hauptinteresse gilt dem Agile Software Engineering.

Daniel Knapp

7


GUT, BESSER, AM BESTEN

Karlsruhe wird zur SmarterCity

Die SmarterCity Karlsruhe steht für Nachhaltigkeit. So hat sie mit dem geplanten Innovationspark Karlsruhe auch zukunftsweisende Produktionsformen wie die vernetzte Fabrik im Blick.

Unternehmen, Forschungs- und Bildungseinrichtungen und auch ihre Standorte stehen im Wettbewerb um Marktanteile, Technologien und Arbeitskräfte. Mit der Initiative Smarter­ City will Karlsruhe die Lebensqualität seiner Bürger, die Innovationsfähigkeit der Unternehmen und die Strahlkraft von Stadt und Region erhöhen.

Über 60 Partner aus Wirtschaft und Forschung arbeiten unter Federführung der Stadt Karlsruhe seit mehr als zwei Jahren in der Initiative SmarterCity Karlsruhe zusammen. Durch vernetztes Handeln Entwickeln sie gemeinsam neue Geschäftsmodelle und Leuchtturmprojekte, die die Innovationsfähigkeit der Unternehmen steigern, aber auch Signale für Karlsruhe als Zukunftsstandort setzen sollen. Hierzu wurden verschiedene Handlungsbereiche identifiziert: Smart House, intelligente Mobilität, Leben in der Stadt/Public Services, Kombi-Lösung, Energie und Smart Culture.

8

Das Konzept Smart House umfasst das erstmals in Deutschland entwickelte Mieterserviceportal der Volkswohnung GmbH, welches sämtliche Vorgänge rund um das Wohnen bündelt. Zum Beispiel können Mieter über ein mobiles altersgerechtes Gerät mit Touchscreen ihren aktuellen Wärme- und Wasserverbrauch abrufen und Einsparpotenziale erkennen. Mit dem eMobilitätszentrum Karlsruhe ist eine Plattform für die Zusammenarbeit der regionalen Partner in der Elektromobilität entstanden. Die Mobilitätsplattform Green Mobility ermöglicht Veranstaltern, die Anreise ihrer Gäste umweltfreundlich zu organisieren und CO2 -Emissionen deutlich zu reduzieren. Das von der SmarterCity Karlsruhe ausgezeichnete Konzept »IchFahrApp« für Smartphones erlaubt es, kurzfristig Mitfahrgelegenheiten anzubieten und zu finden. Diese und viele andere Projekte stehen für eine moderne Stadt im Wandel, für eine SmarterCity. Die nachhaltig angelegten Entwicklungen gehen aber weiter und werden durch einen von Wirtschaftsförderung Karlsruhe und Fraunhofer-Institut

VKSI MAGAZIN Nr. 9 November 2013


von Ralf Eichhorn

für System- und Innovationsforschung (ISI ) moderierten Prozess für ein »Roadmapping 2025« vorangetrieben. Drei Leuchtturmprojekte stehen dabei im Vordergrund der Konzeption: die Entwicklung eines Modellquartiers, die Realisierung eines Hightech Produktionsparks sowie einer intelligenten und intermodalen Mobilitätsplattform mit Modellcharakter. »Insgesamt sollen im Prozess neue Konzepte für Wohnen und Arbeiten entwickelt werden, die den Karlsruher Bürgerinnen und Bürgern nutzen, und außerdem den Unternehmen und dem Wirtschaftsstandort Innovationen und Wettbewerbsvorteile verschaffen«, resümiert Michael Kaiser, Direktor der Wirtschaftsförderung Karlsruhe.

SmarterCity Partner Automotive Engineering Network CAS Software AG

Cyberforum e.V. FZI

Fraunhofer IOSB Hochschule Karlsruhe IHK Karlsruhe

Init Klimaschutz- und Energieagentur Baden-Württemberg GmbH KMK GmbH

Siemens AG Stadtplanungsamt Karlsruhe Stadt Karlsruhe, Erste Bürgermeisterin Tiefbauamt Karlsruhe Wirtschaftsförderung

Mit Hilfe der Innovationen aus dem geplanten Produktionspark etwa könnte eine Hightech-Produktion entstehen, die wirtschaftlich wichtige Impulse für die gesamte Region setzen würde. Vergleichen könnte man eine solche Initiative mit dem Erfolg Karlsruhes in den 80er Jahren, als sich die TechnologieRegion Karlsruhe mit der Realisierung des Hightech-Gründerzentrums Technologiefabrik und des Technologieparks Karlsruhe entwickelt hat. Heute sollen Kompetenzen aus dem IT-Bereich mit Kompetenzen im Produktionsbereich gebündelt werden. Kleine Start-ups in der Gründungsphase wie auch bereits etablierte Unternehmen würden sich in einem solchen Produktionspark bestens entwickeln. Dies wiederum befördert Investitionen, schafft zukunftsweisende Arbeitsplätze und integriert innovative Produktionsformen wie beispielsweise die Vernetzung intelligenter Systeme im Maschinen- und Anlagenbau. Das Ziel ist die intelligente Fabrik, die ressourcenschonend arbeitet und eine hohe Flexibilität in der Produktion möglich macht. www.karlsruhe.de/wirtschaft

Albtal-Verkehrs-Gesellschaft mbH CarMedialab GmbH EnBW Fraunhofer ICT Fraunhofer ISI Hochschule für Gestaltung IBM KASIG KIT / KSRI RA Consulting

Stadtmarketing Karlsruhe GmbH Stadtwerke Karlsruhe GmbH Stadtwerke Karlsruhe, Dezernat 4 Volkswohnung ZKM

Ralf Eichhorn ist bei der Wirtschaftsförderung Karlsruhe zuständig für technologieorientierte Unternehmen und Forschungseinrichtungen, Cluster und Netzwerke, Innovationsförderung sowie Internationales.

VKSI MAGAZIN Nr. 9 November 2013

9


GUT, BESSER, AM BESTEN

Automatisierte Builds und Tests Professionelle Qualitätssicherung in einem Multi-Plattform-Umfeld Regelmäßige automatisierte Builds und Tests sind unverzichtbare Elemente in der Entwicklung von Software-Produkten und deren Weiterentwicklung. Die Komplexität steigt, wenn nicht nur Software, sondern auch dazugehörige HardwareKomponenten weiterentwickelt und getestet werden.

Wer heute ein Auto kauft erwartet, dass es längerfristig problemlos funktioniert. Diese Erwartungshaltung besteht berechtigterweise auch beim Kauf einer Software oder Hardware und erfordert eine professionelle Qualitätssicherung in der Software-Entwicklung. Dazu gehören neben dem Erfassen der Anforderungen und der Implementierung auch regelmäßige Builds und automatische Tests. Insbesondere dann, wenn das Produkt im Zuge der Weiterentwicklung um zusätzliche Funktionalitäten erweitert wird und die Kompatibilität zu Vorgängerversionen bewahrt sowie Stabilität, Performance und Speicherverbrauch im Auge behalten werden muss. Verschärft werden die Anforderungen, wenn die gleiche Software für verschiedene Plattformen erzeugt wird, die Software noch mit einer Hardware zusammenarbeitet sowie die neuesten Betriebssysteme und Technologien unterstützt werden sollen. Hier bieten sich standardisierte Vorgehensweisen während des Entwicklungsprozesses an, die sich für jede Version wiederholen, sich aber auch an neueste Erfahrungen und Forschungen anpassen. Im Folgenden wird auf die Maßnahmen der Qualitätssicherung des hardware- und software-basierten Schutz- und Lizenzierungssystems CodeMeter von Wibu-Systems eingegangen [1]. Herz der Technologie sind die CodeMeter-Lizenzcontainer. Lizenzen sind entweder in einer rein softwarebasierten CmActLicense oder im SmartCard-basierten CodeMeter Dongle gespeichert. Hiermit können flexible Lizenzmodelle abgebildet werden. Weiterhin gibt es Entwicklertools zur Integration des Schutzes in die Kundensoftware und die CodeMeter License Central zur Integration in Vertriebsprozesse, die das Erstellen, Verwalten und Ausrollen der Lizenzen erledigt. Test-Driven Development (TDD) Bei einer testgetriebenen Entwicklung werden vor der Implementierung einer Funktionalität zuerst die dazugehörigen Unit-Tests geschrieben. Wird eine Software von Grund auf neu entwickelt, erlaubt dies von Beginn an, eine möglichst vollständig getestete Software zu schreiben. Bei inkompatiblen Änderungen schlagen diese Tests dann umgehend fehl. Schwieriger gestaltet es sich, wenn bestehende Software erweitert werden soll. Vorhandene Sourcen sind dann meist aufgrund ihrer Größe und Komplexität nicht Unit-Test-tauglich und verlangen eine Prüfung, wie die neue Funktionalität so eingebaut werden kann, dass zumindest der neu implementierte Teil über Unit-Tests abgedeckt ist. Dies gelingt nicht im ersten Anlauf und die Sourcen müssen mittel- bis langfristig umgebaut werden. Die Weiterentwicklung sollte dann Maßnahmen umfassen, wie das Kapseln von Funktionalitäten und Verkleinern von 10

Funktionen, die es erlauben, für die umgebauten Teile UnitTests zu integrieren. Die Lesbar- und Überschaubarkeit der Sourcen wird dadurch gesteigert. Multi-Plattform-Entwicklung Die Anzahl der Computer-Plattformen hat sich in den letzten Jahren nur scheinbar verringert. Zwar ist die Verbreitung der UNIX-Derivate stark zurückgegangen, doch ist neben den Haupt-Plattformen Windows, Linux und OS X durch den vermehrten Einsatz von Embedded-Systemen die Gesamtzahl der für Kunden relevanten Systeme gestiegen. Diese sind vor allem ARM-basierte Systeme (Linux, Windows CE) sowie ein PowerPC-basiertes Linux. Als letztes großes Unix ist Oracle Solaris auf SPARC und Intel-Plattform im Einsatz. Als Entwicklungsrechner kommen derzeit nur Windows-, Linux- und Mac-Systeme zum Einsatz. Da für die EmbeddedPlattformen Cross-Compiler zur Verfügung stehen, kann die Entwicklung auf dem Hauptrechner stattfinden; Tests müssen allerdings auf einem Endgerät oder einer vorbereiteten Virtuellen Maschine stattfinden. Für Solaris, OS X und Linux können die lokalen Laufwerke auf den Build-Rechnern eingebunden und remote gebaut werden. Die bei Wibu-Systems hauptsächlich verwendete Programmiersprache ist C/C++, in Teilprojekten kommen auch C# und Java zum Einsatz. Für C/C++ ergeben sich hierbei die größten Herausforderungen: jede Plattform hat ihren bevorzugten Compiler und makefiles. Unter Windows kommen MS-Compiler und nmake zum Einsatz, unter den anderen Plattformen gcc (Solaris, Linux) oder llvm/clang (OS X) und gnumake. Der Einsatz von Multi-Plattform-Bibliotheken (Qt und eine Eigenentwicklung) hält den Anteil an betriebssystemspezifischem Code in Grenzen. In den meisten Fällen werden die Änderungen daher nur noch auf der Entwicklungsplattform gebaut und getestet, die anderen Plattformen werden dem »System« überlassen. Continuous Integration (CI) CI als Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung ist einer der Kernpunkte im Entwicklungsablauf. Vom Source-Verwaltungssystem Git wird ein Jenkins-Server kontaktiert, der mit Hilfe von Jenkins-Clients die veröffentlichten Änderungen für ausgewählte Plattformen baut und – falls möglich – auch gleich die Unit-Tests durchführt.

Abbildung 1: Steuerung der Continuous Integration VKSI MAGAZIN Nr. 9 November 2013


RUBRIK

von Alexander Schmitt, Jürgen Ockert und Ralf Payer Das Ergebnis wird per E-Mail an den Entwickler aufbereitet, der mit wenigen Klicks bei Fehlern die entsprechenden (Compiler-) Ausgaben im Browser öffnet. Oft sind es die gleichen »Flüchtigkeitsfehler« beim Programmieren: fehlendes ­include auf einer speziellen Plattform, Warnungen aufgrund nicht genau passender Datentypen, nicht korrekt kodierte Zeichenketten. Die Geschwindigkeit spielt eine wichtige Rolle: die durchschnittliche Zeit für einen Durchlauf beträgt momentan etwa vier Minuten, wobei die Zeitspanne von 30 Sekunden bis 20 Minuten für generierten C++ Code mit vielen Templates reicht. Messung der Code-Qualität Software-Qualität lässt sich auch über die Überprüfung der Source Code-Qualität sichern. Verschiedenen Tools für unterschiedliche Programmiersprachen erzeugen standardisierte Kennzahlen. Axivion Bauhaus [2] prüft C/C++ Sourcen und bekämpft die Software-Erosion als Hauptursache für Probleme bei der Änderbarkeit und Wartbarkeit von Software. Der stete Verfall der inneren Struktur eines Software-Systems führt zu einer exponentiell steigenden inneren Komplexität der Software und bedingt einen ebenso stark steigenden Zeitbedarf für die Implementierung neuer Funktionalität. Die Aufwände, aus Kundensicht qualitativ hochwertige Software zu erstellen, steigen ebenfalls. Gleichzeitig vermindert die steigende Komplexität die Produktivität in der Entwicklung. Ein Leitstand macht die Erosion für ein aktives Gegensteuern transparent und bietet konkrete Handlungsanweisungen für Entwickler, zeitnahe Maßnahmen gegen die Verursacher der Erosion, wie Architekturverletzungen, Copy-Paste-Klone, Zyklen, toter Code, Stilverstöße und Metrik-Verletzungen, zu ergreifen. Die Abbildung 2 zeigt Build-Ergebnisse des Axivion Dashboard. Erfahrungen zeigen, dass die Durchführung eines Axivion-Builds pro Woche und dessen Auswertung ein sinnvoller Zyklus ist.

Abbildung 2: Axivion Dashboard VKSI MAGAZIN Nr. 9 November 2013

Daily Build Erscheint der CI-Prozess noch übersichtlich, ist das automatisierte Build komplexer. Build-Aktionen werden auf den gleichen Rechnern wie für den CI-Prozess ausgeführt. Das Build wird dabei auf dem Windows-Rechner gestartet. Nach dem Setzen der Build-Nummer werden die plattformunabhängigen Artefakte (Java-Module) erzeugt, auf die anderen Plattformen verteilt und der Startschuss für die parallele Build-Ausführung gegeben. Der Einsatz von virtualisierten Build-Maschinen, die das Rückspielen alter Backups/Snapshots erlauben, hat sich bewährt. Für OS X ist die integrierte Backup-Lösung Time Machine ein sicherer Anker. Eine Besonderheit stellt das zu bauende Wibu-Systems Tool AxProtector dar: die Windows-Variante dieses Programms enthält Linux und OS X-Binaries, sodass vor dem Bauen dieser Windows-Komponenten die anderen Plattformen beendet sein müssen.

Abbildung 3: Abhängigkeitspfade des Build-Systems

Die Build-Zeit mit über 2 Stunden ist recht hoch, wobei Windows bremst. Während die anderen Plattformen nach wesentlich kürzerer Zeit fertige Installer liefern, benötigt der InstallerBau unter Windows allein 35 Minuten. Durch den Einsatz von gnumake unter Windows, mit der Möglichkeit parallele Targets zu bauen, gibt es aber auch hier noch Spielraum. In der Praxis warten aber noch mehr Fallstricke. Obwohl durch den CI-Prozess die »einfachen« Build-Fehler abgefangen werden, kommt es überraschend oft zu Problemen. Hier die häufigsten Fehler und Gegenmaßnahmen: Bei Problemen mit der digitalen Signierung von Komponenten half die Wiederholung der Signierung in kürzeren Abständen. Das Build-System stellt ein massiv paralleles Testsystem für Compiler, Linker, Source Code-Verwaltung und andere Entwicklungstools dar. Fehler umfassen hier Linker-Bugs, Warnungen oder Fehlerdialoge, die das System zum Stehen bringen können. Meist hilft es, den Job aus der Ferne neu zu starten. 11


GUT, BESSER, AM BESTEN

Bei der Verwaltung von Versionsständen über einen CVSServer war das Setzen von Tags problembehaftet. Der Umstieg auf git bot eine saubere Lösung. Begrenzter Speicherplatz ist immer kritisch. Das Build hantiert mit über 200 GB Daten, die erzeugten und archivierten Artefakte haben momentan eine Größe von 2,5 GB. Hierbei sind aber nicht nur lokale Festplatten ein Problem: die fertigen Produkt-Installer, Test-Programme und Symbol-Dateien landen nach dem Build auf einem zentralen Server mit begrenztem Speicherplatz. Überblick des Testsystems

Abbildung 4: Architektur des Daily Integration Tests

Neben den Unit-Tests werden die Produkt-Installer für alle Plattformen vom Testsystem täglich automatisierten Integrationstests unterzogen. Die Build-Maschine kopiert die Installer auf einen Server. Dies ist die Schnittstelle zum Testsystem, das von Jenkins gesteuert wird. Liegen die Installer bereit, feuert ein Trigger in Jenkins. Die Installer werden mittels Jenkins-Jobs auf die Testmaschinen kopiert und vollautomatisch installiert. Anschließend führt ein Postinstall-Job auf jeder Testmaschine eine umfangreiche Test-Suite am installierten Produkt aus. Die Tests laufen mehrere Stunden. Derzeit sind sieben Testmaschinen im Einsatz. Um die Testläufe auswerten, vergleichen und Fehler eingrenzen zu können, werden die Log-Dateien archiviert und die Ergebniswerte mit den Randbedingungen in einer MySQLDatenbank gespeichert. Eine PHP -Weboberfläche, der sogenannte QA dmin, unterstützt bei der Analyse der Ergebnisse und der Erstellung eines Reports, der an die Entwickler verschickt wird. Test-Automatisierung Die Kosten für eine Test-Automatisierung entsprechen nicht nur den reine Aufwänden für die Implementierung. Auch die zusätzliche Komplexität, die ein Test in das Gesamt-Testsystem 12

Abbildung 5: CmSwitch bei der Test-Automatisierung

einbringt, verursacht Folgekosten. Und genauso wie für das Produkt ist für das Testsystem auch wieder eine Qualitätssicherung notwendig. Hier gilt, dass die Komplexität des Testsystems deutlich unter der des Produkts bleiben muss, ansonsten entsteht eine rekursive Endlosschleife der Qualitätssicherung. Das Hauptziel beim Einsatz der Test-Automatisierung ist das schnelle Auffinden von Produktfehlern und Sicherstellen, dass sie zeitnah gefixt werden. Die Test Suite ist eine umfangreiche Sammlung von TestProgrammen, hauptsächlich in Java implementiert. Somit läuft sie auf allen Ziel-Plattformen. Die Test-Suite ist auch die Schnittstelle zur Datenbank und speichert dort per JDBC die Ergebnisse und Randbedingungen von Test-Läufen. Die Tests der Test Suite sind hierarchisch organisiert. Es gibt Test-Gruppen, Test-Batches, Test-Serien und Tests. Mehrere Test-Serien mit bestimmten Parameter oder Randbedingungen werden zu Test-Batches zusammengefasst und thematisch zusammengehörige Test-Batches zu Test-Gruppen. Zu jeder Test-Serie werden die verwendeten Dongles mit Typ, Firmware-Version und allen relevanten Eigenschaften in einer eigenen Tabelle gespeichert, um hardware-zentrierte Auswertungen zu ermöglichen. Die Abbildung 5 zeigt den CmSwitch, der bei der Test-Automatisierung dazu benutzt wird, einzelne USB -Ports an- und abzuschalten. Dies erlaubt das Anstecken und Abziehen von Dongles zu simulieren. Das Build startet abends und wirft im Anschluss die Tests an. Idealerweise sind die Tests auf allen sieben Test-Maschinen am nächsten Morgen beendet. In der Report-Übersicht des QAdmin wird geprüft, ob alle Tests gelaufen sind und falls nicht, wird die Ursache behoben. Bei Test-Serien mit Fehlern ist es oft sinnvoll, diese nochmals gezielt anzustoßen und nachzutesten, um die Ursachen näher einzugrenzen. Ist ein Fehler ein Produktfehler, ein Fehler im Testsystem, ein Konfigurationsproblem, ist er überhaupt reproduzierbar? Erkannte Fehler werden im Issue-Tracking System FogBugz [4] erfasst und an den zuständigen Entwickler weitergeleitet. Eine Herausforderung bei mehrstündig laufenden Tests ist die Datenflut zu beherrschen. Wichtig ist eine Übersicht über aufgetretene Fehler und kurze Pfade zu den Problemstellen in den Log-Dateien. Dazu zeigt der QAdmin auf der Ebene der Test-Gruppen einen Übersichts-Report für jede Test-Maschine. Die Abbildung 6 zeigt einen aktuellen Ausschnitt für eine Maschine. VKSI MAGAZIN Nr. 9 November 2013


NACHRUF

Wir trauern um Abbildung 6: Report eines Testlaufes

Test-Gruppen mit Warnungen oder Fehlern sind gelb oder rot markiert. Hyperlinks öffnen eine detailliertere Tabelle mit den betroffenen Test-Serien und von dort schließlich im Browser die Log-Datei. Aufgetretene Fehler können im Report und FogBugz nachverfolgt werden. Das erlaubt das Beobachten sporadischer Probleme und verhindert, dass gleiche Probleme mehrmals eingetragen werden. Nicht zu jedem automatisierten Test muss auch ein Report erstellt werden. In gewissen Phasen, wie etwa vor Beginn eines anvisierten Final-Tests sowie bei dessen Durchführung wird die Frequenz allerdings erhöht. Fazit Software wird heute immer komplexer. Die Qualität kann nicht allein durch einen abschließenden Final-Test nach Beendigung des Entwicklungszykluss sichergestellt werden. Vielmehr ist es notwendig, bei jedem Schritt Maßnahmen zur Sicherung der Qualität durchgeführt werden. Automatisierte Builds und Tests und deren Auswertung helfen, die Qualität ständig zu überprüfen und bei einer Verschlechterung entgegenzusteuern. TDD und Tools zur Messung von Code-Qualität unterstützen diesen Prozess. Literatur [1] WIBU-SYSTEMS AG, »CodeMeter,« 2013. [Online]. Available: http://www.wibu.com. [2] Axivion, »Axivion – Stopping Software Erosion,« 2013. [Online]. Available: http://www.axivion.com/. [3] Jenkins, »Jenkins,« 2013. [Online]. Available: http://jenkins-ci.org. [4] Fog Creek, »FogBugZ,« 2013. [Online]. Available: http://www.fogcreek.com/fogbugz/.

Autoren

Alexander Schmitt ist seit 1998 bei Wibu-Systems und leitet die Software-Entwicklung. Jürgen Ockert arbeitet seit 2001 bei Wibu-Systems und ist stellvertretender Leiter der Software-Entwicklung. Sein Schwerpunkt ist die Betreuung des Build-Systems. Ralf Payer ist seit 2005 bei Wibu-Systems. Er leitet die Test-Abteilung und arbeitet schwerpunktmäßig an der Test-Automatisierung.

Professor Dr. phil. nat. Dr.-Ing. e.h., Dr. rer. nat. h.c. Gerhard Krüger. (geb. 9.6.1933; gest. 9.10.2013) Mit Professor Gerhard Krüger ist am 9.10.2013 einer der ­Gründerväter der deutschen Informatik verstorben.

Nach dem Physikstudium in Jena und Berlin und der Promotion in Gießen 1959 arbeitete Gerhard Krüger seit 1960 am Forschungs­zentrum Karlsruhe, seit 1971 als Professor für Informatik an der Universität Karlsruhe (TH). Heute sind beide Arbeitgeber zum Karlsruher Institut (KIT) fusioniert; Gerhard Krügers Lebenslauf scheint dies geradezu vorweggenommen zu haben. Mit besonderem Weitblick erkannte als einer der ersten schon in den Siebziger Jahren die Rolle der Informatik für die Nachrichten­technik und sah damit die Internet-Revolution schon voraus. Folgerichtig gründete er das Gebiet der Telematik (als Kunstwort abgeleitet aus den Wörtern »Telekommunikation« und »Informatik«) und 1982 das gleichnamige Institut an der damaligen Universität Karlsruhe (TH). Die aus diesem Institut hervorgegangenen 30 Professorinnen und Professoren verbreiteten den Begriff der Telematik und trugen so einen weiteren Begriff aus Karlsruhe in die Welt. Neben seinen Leistungen als Wissenschaftler und Lehrer war Herr Krüger auch als Wissenschaftsmanager nachhaltig prägend. Auch auf sein Engagement hin wurde das FZI – Forschungszentrum Informatik in Karlsruhe 1985 gegründet. Bei der Wiedervereinigung half Gerhard Krüger nachhaltig auch vielen Ostdeutschen Universitäten auf dem Weg ins neue gesamtdeutsche Wissenschaftssystem. Sein gesellschaftliches Engagement zeigte sich vielfältig: Als Mitglied und Präsident des Lionsclubs Waldbronn ebenso wie als Präsident der Gesellschaft für Informatik 1985-1986, deren Ehrenmitglied er war. Persönlich behalten wir Gerhard Krüger als »Diplomaten« im besten Sinne des Wortes in Erinnerung, der potenziell kritische Situation mit seinem Humor und auch der Fähigkeit sich selbst nicht zu ernst zu nehmen, entschärfte. Seine Auszeichnungen sind vielfältig, hier hervorgehoben pars-pro-toto seine fünf Ehrendoktorwürden. Der VKSI wird Herrn Professor Gerhard Krüger als Gründervater der deutschen Informatik, als prägende Gestalt der Karlsruher Informatik und als vorbildlichen Menschen in ehrender Erinnerung halten. Prof. Dr. Ralf Reussner

VKSI MAGAZIN Nr. 9 November 2013

13


SNEAK PREVIEWS

HockeyApp Framework, Robolectric und Saphir Fork VKSI Sneak Preview zum Thema »Android QS«

Die Referenten der Sneak Preview im Juli 2013 beschäftigte sich mit Qualitätssicherung im Bereich der mobile APP Entwicklung. Der Fokus lag auf der Android Plattform. Es gab wieder drei spannende Vorträge, die sich mit unterschiedlichen BestPractices und Technologien für die Qualitätsbewusste Entwicklung von Android Apps beschäftigen.

Unit Testing unter Android mit Robolectric Eric Gailus (B2M Software AG) Im Gegensatz zu Systemtests, welche ein Softwaresystem als ganze Einheit testen, versuchen Unit-Tests, die kleinstmögliche zu testende Einheit eines Softwareprojekts in Isolation zu dem Rest zu testen. Dabei ist das Testen einer Unit in Isolation von dem Rest das Problem, da Softwaresysteme ein Netz aus kollaborierenden und miteinander verflochtenen Objekten darstellen. Die Lösung: In Unit-Tests werden Mocks oder Stubs verwendet, welche das Verhalten komplexer, realer Objekte simulieren. Es gibt etliche Mock-Frameworks für viele moderne Programmiersprachen. Jedoch funktionieren die meisten Mock Frameworks nicht oder nur eingeschränkt unter Android. Was wäre aber, wenn man stattdessen alle Tests als JavaProjekt auf dem PC in der JVM ausführt? Geht nicht, führt Eric Gailus aus, denn das mit dem Android SDK ausgelieferte »android.jar« sei ausschließlich zum Kompilieren gedacht, enthalte keine funktionalen Class-Dateien und sei daher auf dem PC in der JVM nicht lauffähig. Führe man Methodenaufrufe in die »android.jar« aus, bekomme man zur Laufzeit eine »java.lang. RuntimeException: Stub!« Exception. Die Lösung, die Eric Gailus vorstellt, heißt Robolectric: »Mit Robolectric kann man Android Tests auf dem PC in der JVM innerhalb von Sekunden starten und alle herkömmlichen Java Mock-Frameworks zur Testisolation einsetzen, indem Aufrufe in das Android Framework abgefangen und auf entsprechende »Shadow« Implementierungen, die Robolectric zur Verfügung stellt, umgebogen werden.«, sagt Gailus. Eric Gailus arbeitet seit 2012 bei der B2M Software AG, wo er hauptsächlich  Anwendungen im mobilen Umfeld entwickelt. Er bringt etliche Jahre Erfahrung im Bereich des Software-Test und Testmanagements von der Nero AG mit, wo er unter anderem als Unit Testing Evangelist fungierte.

Qualitätssicherung mit dem HockeyApp Framework? Johannes Tysiak (arconsis IT-Solutions GmbH) Als Herausforderungen bei der Qualitätssicherung von Apps nannte Johannes Tysiak von arconsis IT Solutions GmbH verschiedene Aspekte. Zum einen die »Fragmentierung«: Unterschiedliche Gerätetypen, Unterschiedliche OS Versionen und Hersteller-Brands, dazu müssen unterschiedliche Gerätekonfigurationen beim Testen berücksichtigt werden. Automatisierte 14

Unit und UI Tests seien häufig nicht ausreichend, daher seien manuelle Tests auf vielen Geräten notwendig. Probleme bei der Durchführung von manuellen Tests wiederum beschreibt er unter flgenden Aspekten: Distribution: Wie erhalten Tester stets aktuelle Test-Versionen?, Crash Reports: Wie erfolgt das Feedback über Abstürze der App?, Feedback: Wie können Nutzer Rückmeldungen aus den Tests geben? Und Analytics: Wie kann erhoben werden, was bereits wie gut getestet wurde? Johannes Tysiak berichtet von den üblicherweise zu bewältigenden Problemen und den verschiedenen Lösungsansätzen, die sie bei arconsis IT Solutions verglichen haben. Schließlich haben sie sich für HockeyApp entschieden. Die Gründe, von denen die volle Kontrolle über die eigenen Daten zu behalten, nur einer ist, hat er in seinem Vortrag erläutert. Johannes Tysiak ist Gesellschafter und Prokurist bei der arconsis IT-Solutions GmbH in Karlsruhe. Johannes ist Spezialist in den Bereichen Prozesse und Werkzeuge für Collaboration, Build- und Testautomatisierung und begeisterter Verfechter der mit der agilen Softwareentwicklung verbundenen Werte. Der Fokus seiner Arbeit liegt insbesondere auf den frühen Phasen der Software-Entwicklung.

Saphir, native Android Apps einfach entwickelt Robert M. Münch (Saphirion AG) Folgende Überlegungen veranlassten die Saphirion AG, in die Saphir Entwicklung zu investieren, das heißt Rebol 2 als Saphir Fork weiterzuführen: »Rebol 2 wird nicht mehr weiterentwickelt (End-Of-Life Risk)!, doch sei es nach wie vor eine sehr gute Technologie mit einer umfangreichen Code-Basis. Dazu sei Rebol 3 zu 90% fertiggestellt. Außerdem fügt Münch folgende Gründe an: Interpreter seit Anfang 2012 als Open-Source verfügbar, die Technologie sei besser als Rebol 2. Das Testprodukt »Treemapper« zeige, dass professionelle Produkte möglich sind und neben weiteren Gründen betont er, dass mit Rebol mehr als 15 Jahre Entwicklungsknow-how verfügbar seien. Die bisherigen Meilensteine zeigten, dass eine kontinuierliche Verbesserung möglich sei, erläutert der CEO der S ­ aphirion AG. Robert M. Münch ist Gründer mehrerer Unternehmen (Schwerpunkte: Prozessorentwicklung, Unternehmensberatung und KostenmanagementSoftware). Sein Hauptinteresse ist es, schnell einfache und gute Software zu produzieren und durch Nutzung eines eigenen Technologie-Stacks »NonValue-Complexity« aus allem herauszuhalten. VKSI MAGAZIN Nr. 9 November 2013


Test-Design, Performance-Analyse und JUnit 4.11 Die Neuerungen. VKSI Sneak Preview zum Thema »Testen, aber agil«

Software-Qualität ist nach wie vor eines der wichtigsten Themen in der Software-Entwicklung. Testen ist hierbei eine nicht zu vernachlässigende Kernaufgabe, die aber gerade bei agilen Vorgehensweisen richtig angegangen werden muss, um nicht zu einem hemmenden Faktor zu werden. In dieser Sneak Preview berichteten drei Experten aus dem Bereich über Erfahrungen sowie neue Entwicklungen im Umfeld der Testplanung und -entwicklung.

Test-Design Dr. Jürgen Heymann Wie oft haben wir schon gehört: »Alle möglichen Kombinationen zu testen ist völlig unmöglich – da nehmen wir uns ein paar raus und mehr geht nicht«. Um diesem Vorurteil zu widersprechen, stellte Dr. Jürgen Heymann eine Testdesign Methode vor, die systematisch mit Kombinatorik umgeht, um mit minimalem Aufwand 70-90% aller Fehler zu finden. Jürgen Heymann ist Chief Development Expert in der zentralen ‚Software Engineering‘ Abteilung der SAP. Er studierte Informatik an der TU Braunschweig und am Georgia Institute of Technology in Atlanta, und promovierte dann in Informatik an der TU München. Nach fünf Jahren Entwicklungsarbeit bei verschiedenen Firmen in USA wechselte er 1995 zur SAP nach Walldorf. Dort war er zuerst in der Entwicklung von ABAP Objects, dann Architekt und Manager im Produktbereich »SAP Portals«. Seit 2009 ist er in der zentralen Software Engineering Abteilung der SAP und treibt dort das »Agile Software Engineering« Programm.

Performance Analyse in einem komplexen Software System Gebhard Ebeling Aufbauend auf seinem Vortrag »Nicht funktionale Software­ tests« bei der Sneak Preview vom 11.10.2012 stellte Ebeling die heute bei Arvato Infoscore angewandte Vorgehensweise für Performance Analysen vor: »Die webbasierten Systeme, die in einem komplexen Umfeld betrieben werden, bringen eine Vielzahl von Parametern und Einstellmöglichkeiten mit sich. Jede dieser Stellschrauben wirkt sich auf das System und seine Performance aus.« In seinem Vortrag zeigte er an einem Fallbespiel, wie diese Komplexität gezielt reduziert werden kann, um Ursachen von auftretenden Performance Problemen aufzuspüren und reproduzieren zu können. Es wird gezeigt, wie Querbezüge zwischen verschiedenen Systemkomponenten und Datenquellen erstellt und dargestellt werden, um geeignete VKSI MAGAZIN Nr. 9 November 2013

Entscheidungsgrundlagen für die Behebung von Fehlerquellen zu liefern. Dipl. Ing. Gebhard Ebeling ist Testmanager bei der Arvato Infoscore GmbH, Baden – Baden. Dort verantwortlich für die Nicht funktionalen Softwaretests innerhalb der Arvato Infoscore – IT, Bereich Risikomanagement. Er bringt als Diplom Ingenieur der technischen Informatik viele Jahre Erfahrung in der Softwareentwicklung, SoftwareTest und Testmanagement mit.

JUnit 4.11 – Die Neuerungen Marc Philipp JU nit ist das älteste und am weitesten verbreitete Testing

Framework für Java. Neben Unit Tests lassen sich damit auch Integrations- und Akzeptanztests automatisieren. Marc Philipp zeigte in seinem Vortrag, dass sich seit der Umstellung auf Annotationen in JUnit 4.0 einiges getan hat. Die aktuelle Version 4.11 biete unter anderem einen verbesserten Assertion-Mechanismus (mit Hamcrest Matchers), die Möglichkeit, Vorbedingungen für Testfälle anzugeben und einen neuen Regel-basierten Ansatz, der es erlaube, komplizierte TestSetups auf wiederverwendbare Art und Weise zu definieren. »Die Neuerungen bieten Entwicklern deutlich einfachere und zugleich mächtigere Möglichkeiten, Assertions zu f­ ormulieren, Tests zu schreiben und zu strukturieren. Das Resultat ist kompakterer Code, der besser lesbar und somit leichter wartbar ist.« Marc Philipp arbeitet seit 2008 als Softwareentwickler und Trainer bei der andrena objects ag. Er engagiert sich als Organisator von Konferenzen wie den XP Days Germany, die dieses Jahr in Karlsruhe stattfinden. Außerdem arbeitet er an verschieden Open-Source-Projekten, wie JUnit und Project Usus, mit. Alle Vortragsfolien auf der VKSI-Website: http://www.vksi.de/sneak-preview/vergangenesneak-previews.html

15


ENTWICKLERTAG

Werkzeuge und Erfahrungen Der Track »Quality Assurance und Testing« auf dem Entwicklertag 2013

Einen ganzen Track widmete der VKSI dem Thema Quality Assurance und Testing. Eine kurze Übersicht über Vorträge, die sich mit Testen beschäftigen, finden Sie auf dieser und den folgenden Seiten. Alle Vorträge sind auf http://www.entwicklertag.de/ karlsruhe/2013/vortragsfolien verlinkt und die Charts können als PDF nachgelesen werden. Einige der Vorträge sind außerdem als Videos dokumentiert und auf der gleichen Seite verlinkt.

Acceptance Tests für Web-UIs »Automatisierte Tests gehören inzwischen für viele Entwickler zum Alltag. Auch Web-Entwickler greifen häufig zu Unit-Tests und Integration-Tests, um den serverseitigen Code zu prüfen. Wir zeigen, wie man einen Schritt weitergeht und durch Acceptance Tests der Web-UI sicherstellt, dass der Benutzer auch genau das sieht was er sich gewünscht hat. Am Beispiel einer KnockoutJS-basierten Seite führen wir Selenium, PhantomJS und SpecFlow vor, um von der Beschreibung in Textform zu einer Implementierung in .NET zu kommen.«, versprach die Ankündigung. Abgerundet wurde die Demo durch konkrete Hinweise aus der Entwicklerpraxis. Malte Clasen ist promovierter Softwareingenieur und seit über 10 Jahren als Entwickler tätig. Sein Schwerpunkt liegt auf agiler Software­ entwicklung mit .NET. Sie erreichen ihn via http://malteclasen.de.

Effizientere agile Prozesse – Testfall-basierte Anforderungsdokumentation »Feedback ist in agilen Prozessen die entscheidende Kraft, die eine hohe Qualität und Effizienz in der Umsetzung ermöglicht und den Prozess in der Spur hält. Wir beobachten jedoch, dass wichtiges Feedback aufgrund der verbreiteten Prosaform von Anforderungen und durch das Fehlen von expliziten Akzeptanzkriterien oft erst viel zu spät gegeben werden kann. Die Idee der Testfall-basierten Anforderungsdokumentation setzt dort an und macht Testfälle zu zentralen Arbeitsmaterialien im agilen Prozess. Wir haben den sehr pragmatischen TAD-Ansatz ursprünglich aus der Not heraus entwickelt und in zahlreichen agilen Projekten mit der Zeit verfeinert. Teile des TAD-Ansatzes ähneln bekannten Konzepten, wie Requirements-Engineering mithilfe von Use-Cases, TDD und automatisierten Akzeptanztests. Der TAD-Ansatz bezieht sich jedoch nicht nur auf einen einzelnen Aspekt des agilen Prozesses, sondern hat zum Ziel, die Effizienz des gesamten Prozess zu steigern.«, lautete die Ankündigung. Die Referenten wollten darüber hinaus ihre guten Ergebnisse »gerade in Projekten mit Qualitätsproblemen, sowie in internationalen und verteilten Projekten, in denen die Kommunikation erschwert ist« vorstellen und daher »den TAD-Ansatz, seinen positiven Effekt im agilen Prozess und unsere konkreten Erfahrungen mit einem breiteren Publikum teilen und zu diskutieren.« Jörn Koch arbeitet bei der C1 WPS als Senior Software-Architekt in den Bereichen IT-Beratung, Architektur, agiles Coaching und Durchführung von IT-Projekten. Er verfügt über mehrjährige Erfahrung in der Durchführung und im Coaching agiler Projekte, sowie als Entwickler und Architekt in der Konstruktion, Restrukturierung und der Bewertung großer Anwendungssysteme für unterschiedliche Branchen. Sebastian Middeke ist Senior Software Qualitätsmanager bei der C1 WPS GmbH. Schon seit Studienzeiten liegt sein Fokus auf der Qualitätssicherung von agilen Entwicklungsprozessen sowie der funktionalen und technischen Qualitätssicherung von objektorientiert entwickelten Anwendungssystemen. Er verfügt über langjährige Erfahrung in der Beratung und Qualitätssicherung von agil durchgeführten Entwicklungsprojekten in vielfältigen Branchen. Sebastian Middeke ist Quality Assurance Management Professional (QAMP) und Trainer für Certified Agile Tester (CAT).

16

VKSI MAGAZIN Nr. 9 November 2013


2013 KARLSRUHER ENTWICKLERTAG

Multicore überall: Testwerkzeuge für nebenläufige Anwendungen

Exploratives Testen – Für Programmierer, Tester und Sie!

Der Vortag stellte Testwerkzeuge für nebenläufige Anwendungen vor. »Fehler in nebenläufigen Anwendungen sind durch ihre Abhängigkeit vom Scheduling charakterisiert; sie treten nur bei bestimmten Interleavings auf. Um Nebenläufigkeitsfehler effektiv und effizient zu finden und zu reproduzieren, beeinflussen die vorgestellten Werkzeuge das Scheduling. Dabei gehen sie im Gegensatz zu Maßnahmen wie Stress-Tests oder wiederholte Ausführung von Unit-Tests systematisch vor. Für jedes Werkzeug werden die Funktionsweise sowie das Schreiben von nebenläufigen Tests gezeigt.«, so der Referent.

»Exploratives Testen ist weit verbreitet unter Entwicklern – und das schließt Programmierer genau so ein wie Tester. Obwohl ein hoher Automatisierungsgrad viele Regressionsfehler finden kann, können nicht alle Fehler durch Automatisierung allein gefunden werden. Wenn Sie an den schwer zu reproduzierenden Bug denken, der durch eine lange Kette von Schritten verursacht wurde, oder den einen »Design faux pas«, bei dem das Eingabefeld hinter einem anderen Vordergrundelement versteckt war, dann wir Ihnen klar, dass Testautomatisierung diese Fehler nicht finden kann, sondern sogar Sie sogar in falscher Sicherheit gewogen hat. Zu einer funktionierenden Teststrategie gehört deshalb auch Exploratives Testen«, kündigten die Referenten an. Für Programmierer und Tester sollte diese Session die Grundlagen und fortgeschrittenen Themen des Explorativen Testens bieten. Die Referenten haben versprochen: »Wir werden Ihre Fähigkeiten herausfordern, Ihnen Tools und Strukturen für Exploratives Testen an die Hand geben, und Ihnen damit dabei helfen, außerhalb Ihrer Komfortzone zu denken.«

Oliver Denninger leitet am FZI Forschungs­ zentrum Informatik die Forschung zum Thema Multicore-Software. Er arbeitet zusammen mit Industriepartnern an Techniken zur automatischen Fehlererkennung und an Testwerkzeugen für parallele Anwendungen.

Markus Gärtner arbeitet als testender Programmierer, Trainer, Coach und Berater für it-agile GmbH, Hamburg. Markus schrieb unter anderem ATDD by Example – A Practical Guide to Acceptance Test-Driven Development und steuert zur Softwerkskammer, der deutschen Software Craftsmanship Bewegung bei. Auf Englisch bloggt er regelmäßig auf http://www.shino.de/blog, auf Deutsch unter http://www.mgaertne.de. Meike Mertsch arbeitet als agiler Tester, Trainer und Coach für die it-agile GmbH in Hamburg. Ihre Hauptinteressen liegen im agilen Testen, Kanban, Scrum und Pairprogramming. In Schulungen, Coaching und beim Entwickeln liegt ihr Hauptaugenmerk auf der Zusammenarbeit des Teams untereinander und mit allen Schnittstellen, um die Teams bestmöglich bei ihrer Arbeit zu unterstützen. Meike bloggt auf http://agiletester.webnode.com/blog über T ­ esten, Teams und Kanban.

p VKSI MAGAZIN Nr. 9 November 2013

17


ENTWICKLERTAG

p

Werkzeuge und Erfahrungen

Continuous Integration and Automated Testing in a multisite .NET/Cloud Project The field report describes practical experiences with the implementation of the continuous integration and automated testing in a .Net/Amazon Cloud project. The scope of the project included development and testing of a new »Sitecore«-CMS based Web Presence. The duration of this agile project was about one year and involved 60 developers and testers located in different cities in Germany and India. After an overview about the project infrastructure, the field report describes project-specific implementation of the continuous integration process, shares experiences of using projectspecific Microsoft/Cloud technologies and tools, and shows how process automation helped to reduce the overall project costs. Vladislav Kublanov studierte Informatik an der RWTH Aachen. Sein Berufsleben startet er im Jahre 1999 als Entwickler in der Telekommunikationsindustrie. Seit 2008 ist er bei Tata Consultancy Services Deutschland GmbH, Düsseldorf als Entwickler, ScrumMaster und Projektleiter beschäftigt. Insgesamt arbeitet Vladislav Kublanov seit mehr als zehn Jahren in größeren internationalen Projekten. Die Vorzüge von Continuous Integration und des Automatischen Testen lernte er kennen und lieben, so dass er in zahlreichen Projekten zum Evangelisten für deren Einsatz wurde. Dr. Margret Hesselmann promovierte Informatk an der TU Bergakademie Freiberg. Sie arbeitet seit mehr als einem Jahrzehnt als Software-Entwickler, Architektin und Agiler Coach in größeren internationalen Projekten. Ihre Erfahrungen basieren vorrangig an ihrer Mitarbeit an Software-Plattform-Entwicklungen bei Nokia Networks. Agile Software-Entwicklung lernte Dr. Margret Hesselmann im Jahre 2006 zu schätzen und lieben. Sie propagiert diese ihre Liebe zu Agile seit 2008. Seit 2008 arbeitet sie bei Tata Consultancy Services Deutschland GmbH.

18

Agiles Testen in Großprojekten »Agile Ansätze sind aus der heutigen Softwareentwicklung nicht mehr wegzudenken. Während bei kleineren Projekten mit überschaubaren Anforderungen eine Erfolgsstory nach der anderen veröffentlich wird, existieren sehr wenig Erfahrungen bei dem richtigen Einsatz der agilen Software-Entwicklung in Großprojekten. In klassischen Großprojekten mit langfristigem Betrachtungshorizont sind dedizierte Rollen zur Planung und Steuerung wie Projektleiter, Testmanager oder Architekten ein fester Bestandteil. Sie sollen die Orchestrierung des Großprojektes unterstützten sowie den Abstimmungs- und Kommunikationsaufwand reduzieren. Diese Rollen sind in der agilen Welt gänzlich unbekannt. Damit scheint die Anwendung der agilen Prinzipien auf Großprojekte nicht ohne weiteres übertragbar zu sein«, hinterfragte Stephan Salmann in seinem Vortrag. Stephan Salmann ist Geschäftsführer und Mitgründer der corporate quality consulting GmbH. Er studierte Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität zu Köln. Nach seinem Studium war er lange Zeit in der IT-Beratung tätig. Dort war im Bereich KeyAccount-Management, strategische Unternehmensentwicklung, Business Development und Projektleitung engagiert. In letzter Zeit hat er sich verstärkt mit den Themen IT-Industrialisierung, Strategische Steuerung der IT, Internationalisierung und IT-Produktmanagement beschäftigt. Im April 2005 gründete er mit Oliver Kuklok sein eigenes Beratungshaus, welches sich dem nachhaltigen und ganzheitlichen Brückenbau zwischen Business und IT verschrieben hat.

VKSI MAGAZIN Nr. 9 November 2013


QS »From Scratch« –

Erfahrungsbericht über die Einführung von QS in einem kleinen Softwareunternehmen »Ihr Chef möchte ab sofort in Ihrem Unternehmen Qualitätssicherung betreiben! Gut wäre es jetzt, wenn die Firma gerade im Aufbau ist und noch niemand eine einzige Zeile Code geschrieben hat. Dann hat der QS -Beauftragte genug Zeit und Möglichkeiten, die entsprechenden Maßnahmen direkt in den Entwicklungsprozess einfließen zu lassen.In der Realität sieht es jedoch meist anders aus. Die Idee QS einzuführen kommt erst auf, wenn in einem bestehenden Unternehmen etwas gewaltig schief gelaufen ist – häufig mit entsprechenden finanziellen Auswirkungen. Hier wird die Umsetzung von QS zu einer kostspieligen Mammutaufgabe, insbesondere wenn der Betrieb nicht für einige Zeit stillgelegt werden kann. Es gibt aber auch einen Mittelweg. Die Firma ist noch recht jung, die Entwickler haben hoch motiviert ein Produkt geschaffen und eigentlich funktioniert alles ganz gut. Jedoch ist ein Umbruch im Gang. Die Komplexität des Produkts steigt von Tag zu Tag und gleichzeitig steigen die Anforderungen an die Performance des Produkts mit wachsender Kundenzahl. Waren Fehler in der Produktion bisher zwar schmerzhaft, aber weniger dramatisch, so werden diese nun immer kritischer und müssen auf jeden Fall so gut es geht verhindert werden. Bisherige Maßnahmen zur Vermeidung von Problemen beschränken sich eher auf Bauchgefühl und oberflächliche Tests als auf strukturierte Kontrollen. Dabei wird klar: hier muss QS her.

VKSI MAGAZIN Nr. 9 November 2013

Wie aber etabliert ein frisch gebackener QS -Beauftragter eine Kultur der Qualitätssicherung aus dem sprichwörtlichen »Nichts«?« Dieser Frage stellte sich Yves Schubert und zeigte an einem realen Beispiel, wie diese Herausforderung in einer kleinen Softwarefirma angegangen wurde. Von der Erkenntnis, dass Qualitätssicherung notwendig ist, über die Einführung verschiedener Maßnahmen und dem Spagat zwischen Lehrbuch und Pragmatismus bis hin zu Methoden, wie die Akzeptanz der Entwickler gewonnen und eine langfristige Wirkung erzielt werden kann, stellte Schubert dar, wie QS auch in schwierigen Umfeldern mit einfachen Mitteln umsetzbar ist. Yves Schubert hat 2010 das Studium der Softwaretechnik an der Universität Stuttgart abgeschlossen und arbeitet seit dem bei der Cinovo AG in Stuttgart. Dort ist er für Java-, Web- und Mobile-Entwicklung und Koordinierung der Qualitätssicherung zuständig. Schon seit 10 Jahren beschäftigt er sich mit Softwareentwicklung sowohl im Embedded-Bereich während der Ausbildung zum Industrietechnologen bei der ­Siemens AG in München und später bei Vector Informatik in Weil im Dorf, als auch in der Webentwicklung.

19


CYBERTRENDS

Free WLAN Karlsruhe – jetzt noch draht- und

Gut für den Teint: Freies WLAN für Karlsruhe

S

eit einigen Wochen gärt es in Karlsruhe. Das kleine Pforzheim, bis jetzt eher als Schmuckstadt bekannt, hat mit dem laut Pressemeldung »ersten kostenlosen freien WLAN in einer deutschen Großstadt« einen Marketingcoup gelandet und der IT-Metropole um die Ecke die Rücklichter gezeigt.

Das lässt die Karlsruher Politik gerade im Vorfeld der Kommunalwahl 2014 nicht ruhen. In seltener Einmütigkeit haben die Fraktionen die Stadtverwaltung aufgefordert, die seit Längerem andauernden Diskussionen zu dem Thema zu einen schnellen Ergebnis zu führen. Umgehend berief der Oberbürgermeister eine Elefantenrunde mit Politikern, IT -Experten, Juristen, Marketingspezialisten und Vertretern der Wirtschaft zusammen. Ziel war es, ein Konzept für eine zügige Abdeckung zumindest der hochfrequentierten Plätze in der Innenstadt mit kostenlosem WLAN zu entwickeln. Zur großen Überraschung der meisten Anwesenden kam dabei heraus, dass der

20

gemeinnützige Verein INKA , 1998 aus der Universität heraus entstanden, schon vor 10 Jahren ein Free WLAN rund um die Uni, im Schlossgarten und entlang der Via Triumphalis bis zum Festplatz installiert hatte. Zum Stadtfest 2004 lief alles wie geschmiert. In der Folge trat aber ein typisch Karlsruher Wesenszug zu Tage. Die großartige technische Ausgangsposition wurde locker verspielt. Anträge zum Weiterbetrieb versandeten in der Verwaltung, die Router wurden schließlich fast alle wieder abgebaut. Der Verein geriet in Vergessenheit wie die namensgleiche Hochkultur und mit ihm das drahtlose freie Internet in Karlsruhe. Nur auf und um den KIT-Campus versorgt das WIKIT Studenten und

KIT -Angestellte mit satter Bandbreite.

Nach dem Launch der PF -LAN in der Goldstadt wird nun hinterher gelaufen. Wenn der politische Wille da ist und Imageverlust droht, geht es auf einmal flott und die Frage nach der Finanzierung spielt eine untergeordnete Rolle. Die feine Ironie dabei ist, dass Outdoor WLAN aufgrund von LTE-/UMTSVerbreitung und Daten-Flat-Rates unter 10 Euro im Monat stetig an Bedeutung verliert und weiter verlieren wird. Für die Nutzer ist der Einspareffekt meist gering und das Registrierungsprozedere oft beschwerlich. WLAN hat bei überlasteten Netzen und seiner hohen Bandbreite seine Berechtigung, macht aber vor allem in Gebäuden und bei großer

VKSI MAGAZIN Nr. 9 November 2013


kostenloser! Kolumne von Matthias H0rnberger, Vorstand CyberForum

Inka-Website von 2003: Damals gab es in Karlsruhe freies WLAN.

Flächendeckung und automatischem Login Sinn. Dann kann es private Flat Rates ergänzen oder gar ersetzen. Auch muss ein öffentliches WLAN neben dem reinen Zugang Mehrwerte z.B. auf den Splash Screens bieten, etwa zur Verkehrssituation, zu Veranstaltungen oder kostenlose Augmented Reality-Anwendungen für Touristen. Es muss also eine langfristige Gesamtstrategie geben. Ein gutes erstes Ziel wäre öffentliches WLAN in allen öffentlichen Räumen und Gebäuden einschließlich ÖPNV zumindest mit Haltestellen und den S-Zügen. Die im Bau befindlichen U-Strab-Bahnhöfe sollte das mit einschließen. Eine schnelle Lösung auf Basis von INKA ist gut, aber nur ein erster Schritt.

VKSI MAGAZIN Nr. 9 November 2013

Für die Studenten bringt eine WLAN -Lösung unter Verwendung der

alten INKA -Strukturen große Vorteile. Ein Roaming vom KIT über die ganze Innenstadt wäre das Ergebnis. Der neue Schwung muss genutzt werden. Der OB hat eine Lösung bis zum Frühsommer 2014 zugesagt und wenn die INKA Grundlagen gut genutzt werden, ist das auch ohne weiteres möglich. So könnte Karlsruhe aus dem PR -Desaster eine schöne Geschichte machen, vielleicht mit der Headline in einer Pressemitteilung zum Stadtgeburtstag 2014: »10 Jahre Free WLAN in Karlsruhe – jetzt noch draht- und kostenloser!«

Matthias Hornberger ist seit 2010 Vorstandsvorsitzender des CyberForum e.V.. Er ist im Hauptberuf CFO der KIZOO AG (ehemals WEB.DE AG), deren Vorstand er seit dem Börsen­gang im Jahr 2000 angehört. Die Durlacher KIZOO Technology Ventures hilft jungen Startup-Teams im IT-Umfeld zu wachsen. Der Schwerpunkt liegt auf Seed- und Frühphasen-Finanzierungen von SaaS, Internet & Mobile Services und Social Applications.

21


GUT, BESSER, AM BESTEN

BPM: Prozesse und Qualität – Oxymoron oder 

W

ie kann die Qualität von Prozessen sichergestellt werden? Geschäftsprozesse und Business Process Management (BPM) sind schon seit geraumer Zeit bekannt, die Vorteile, Herausforderungen, Tools und Notationen zu deren Umsetzung mit BPMN , BPEL, etc. hinlänglich diskutiert. Und dennoch stellt sich mitunter die Frage nach der Sinnhaftigkeit oder dem Nutzen der einmal eingeführten Prozesse. Insbesondere dann, wenn die Prozesse nicht nur dokumentiert, sondern implementiert oder bereits automatisiert wurden. Hier muss der/die geneigte Mitarbeiter/in dann dem vorgegebenen Prozessfluss folgen und er/sie stellt sich zeitnah die Frage nach der Qualität der eingeführten Prozesse und deren Weiterentwicklung. Diese Fragen sind an sich nicht verwerflich, da in einem ersten Schritt gewöhnlich eine deutliche Optimierung der ProzessErgebnisqualität erreicht wird. Dabei kann aber nur bedingt eine Aussage über die reine Prozessqualität – im Sinne eines Vorher-nachher-Vergleiches – getroffen werden, da die Differenz von »manuell« und »unzureichend dokumentiert« zu »systematisch und IT-unterstützt« zu groß ist. Kleine Nachjustierungen werden in der Praxis immer notwendig sein. Selbstredend sollte man sich über die Gewährleistung einer möglichst hohen Qualität des Prozesses bereits zu Beginn eines BPM-Projektes Gedanken machen. Eine agile Vorgehensweise, der Bottom-Up-Approach oder Herangehensweisen wie »Start small, scale fast, reuse best practices« verleiten dazu, notwendige Standardisierungen im Vorgehen und Qualitätsmanagementmethoden hinten anstehen zulassen. Zu Beginn genügen häufig einfache Dinge wie Modellierungsrichtlinien, zugelassene Symbole und Prozess-Muster, Versionierungsvorgaben und ein dezidierter Freigabeprozess für neue Prozesse oder Versionen. Sind diese grundlegenden QS -Anforderungen umgesetzt, dann sollten generellere Fragen gestellt werden: Sind Qualitätsmerkmale, wie sie bei Produkten oder Software unabdingbar sind, auch bei Prozessen notwendig? Wie können solche Merkmale identifiziert werden? Gibt es allgemeingültige Ansätze diese Problematik zu lösen oder muss bei jedem Prozess neu darüber diskutiert werden?

Können Standards helfen? Die Liste an Standards zur Beurteilung der Qualität von Prozessen ist überschaubar. Zwar gibt es übergeordnete Standards und QS-Modelle wie die ISO 9000 (Grundlagen und Begriffe von Qualitätsmanagementsystemen) oder speziellere IT-Standards wie die ISO 25000 (Leitfaden für Qualitätskriterien und die Bewertung von Softwareprodukten). Doch mit BPM und der damit verbundenen Qualität der zugehörigen IT-gestützten Prozesse – auch betrachtet im Kontext der heutigen Trends und Möglichkeiten wie Cloud, Big Data oder Mobil – hat sich noch kein vergleichbares Modell etabliert. Interessant wäre das 2010 neu formulierte EFQM-Modell, wobei auch hier die technischen 22

Rahmenbedingungen weitgehend außer Acht gelassen werden. Allen Modellen gemeinsam ist, dass die Definition und Verbesserung der Prozessqualität zu sehr im Allgemeinen bleibt und nur implizit definiert ist. Welche Qualitätsmerkmale anlegen? Für die Beschreibung von Qualität passt die Definition aus der Norm EN ISO 9000:2005: »Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.« Übersetzt in die BPM-Welt: Wie gut werden die fachlichen Anforderungen durch einen Prozess erfüllt? Die Qualität eines bestimmten Prozesses genau zu messen ist nicht trivial. Oft liegt das eigentliche Potenzial zur Prozessverbesserung in der Erkennung von Flaschenhälsen. Bei Produktionsprozessen in der Industrie mit verfügbaren physikalischen Messgrößen wie Gewicht, Stärke und Beschaffenheit ist dies einfacher. Für Geschäftsprozesse bei Dienstleistern in der Entwicklung, Vertrieb oder Verwaltung sind eindeutige Maßstäbe eine Herausforderung. Klar ist: für qualitativ hochwertige Produkte oder Dienstleistungen müssen die Qualität des Prozesses und eine gewisse Prozessstabilität vorhanden sein. Entscheidend für den Erfolg ist letzten Endes jedoch die direkt beim Kunden auftretende Produkt- oder Ergebnisqualität. Die Prozessqualität ist eigentlich nur Mittel zum Zweck. Prozessqualitätsmerkmale in einem BPM-Umfeld könnten also u.a. sein: eine sachlich korrekte einheitliche Modellierung, Durchlaufzeiten, Fehlerfreiheit, Effizienz. Ist nicht auch der Kontext der Prozesse entscheidend? Doch können überhaupt die gleichen Qualitätsmerkmale und davon abgeleiteten Maßnahmen für alle Prozessarten gleichermaßen gelten? Denken wir an »mobile Prozesse« wie sie heute im Außendienst gelebt werden: wenn Barcodes gescannt, Dokumente VKSI MAGAZIN Nr. 9 November 2013


schwerlich zu erreichender Idealzustand von Sven Fischer und Edgar Schüber im Backend abgerufen, Unterschriften auf dem Tablet geleistet werden sind das Schritte, die mit stationären Systemen oft nicht möglich waren. Gelten hier dieselben Qualitätsmerkmale? Ja, da hier nur eine weitere Verbesserung des Prozesses beschrieben wird. Die Alternativen wären längere Laufzeiten, andere Abstimmungen, Umgehungen der Beschränkungen oder Nacharbeiten. Fehlt die Methodik bei der Umsetzung von Geschäftsprozessen? Den gegenwärtigen Zustand der Qualitätsmanagementmaßnahmen und Best Practices aus der Qualitätssicherung von Geschäftsprozessen hat eine Studie von der Fachhochschule Koblenz (Prof. Ayelt Komus) untersucht. Dabei ergab sich: ●● über 40% der identifizierten Fehler im Prozess wären vermeidbar gewesen ●● über 35% der Unternehmen mussten wesentliche Nacharbeiten vor Produktivsetzung vornehmen ●● reine Prozessmanager erzielen bessere Projektergebnisse als IT- oder fachliche Projektleiter ●● bei ca. 50% der Unternehmen sind die Prozessbeschreibungen nicht eindeutig genug und lassen somit Raum für Missverständnisse ●● Prozesse werden sehr häufig verändert, aber nur die Hälfte der Unternehmen haben hierfür eine Methodik Es fällt v. a. die unstrukturierte Vorgehensweise und fehlende Methodik bei der Umsetzung von Geschäftsprozessen auf. Da scheinen Industrieproduktion oder Softwareentwicklung weiter zu sein. Organisatorisch verankern Prozesse enden nicht an Abteilungsgrenzen, sondern umfassen Kunden und Partner, also auch fremde Hoheitsgebiete. Für ein systematisches Qualitätsmanagement und die Verantwortung für den Gesamtprozess eine Herausforderung. Selten gibt es einen wirklichen Verantwortlichen für diese End-to-End Prozesse. Und damit auch keine Überwachung der Leistungsfähigkeit der Prozesse und damit keine Prozessqualitätssicherung. Die Beurteilung der Qualität bleibt dem Kunden überlassen. Einbettung in den QM-BPM-Zyklus Betten wir das Prozessmanagement in einen definierten QMBPM Zyklus ein, schaffen wir die Rahmenbedingungen für den Prozessdurchlauf und das Erkennen von Schwachstellen. Die dafür notwendigen Rollen – Prozesseigner, Prozessanalyst, BPM -Entwickler, Prozessmitarbeiter, Prozesscontroller – werden geschaffen. Zentral ist die Durchgängigkeit der Prozessentwicklung: Der dokumentierte Prozess wird umgesetzt, ausgeführt, gemessen und nachjustiert. Es gilt die »ARISWandtapeten« zu vermeiden, die oft zum Zeitpunkt der Fertigstellung schon veraltet sind.

Flankierend werden Qualitätssicherungsmaßnahmen – Reviews, Feedbackrunden, Quality Gates, Freigabemechanismus, Anforderungsmanagement – in allen Phasen – Modellierung, Entwicklung, Ausführung – den Prozesszyklus begleiten. Idealerweise sind diese Maßnahmen in eine umfassendere Unternehmensstrategie eingebettet, so wird Nachhaltigkeit erreicht. Einen möglichen QM-BPM Zyklus zeigt Abbildung 1.

Abbildung 1: BPM-Zyklus (in Anlehnung an IBM)

Geschäftskennzahlen und KPIs bereits bei Prozessbeschreibung Geschäftskennzahlen beschreiben die für eine Überwachung relevanten Aspekte des Leistungsmanagements in einem Unternehmen. Diese vorab definierten Leistungsindikatoren umfassen Messwerte, KPIs (Key Performance Indicator), Zähler und Stoppuhren. KPIs sind Voraussetzung für die Verbesserung oder Verschlechterung der Prozesse: Nur durch Messung, Vergleich und Einleitung von Maßnahmen ist eine Steigerung der Prozessqualität möglich. Erst nach Definition und Bereitstellung dieser fachlichen Geschäftskennzahlen sollten Geschäftsprozesse modelliert, implementiert und ausgeführt werden. Die definierten Kennzahlen und KPI s können dann stetig gesammelt, ausgewertet und weiteren Prozessen zur Verfügung gestellt werden. Diese Qualitätskennzahlen-Datenbasis ist notwendig, um die Prozess­qualität zu messen, eventuell notwendige Anpassungen an den Prozessen, der Aufbau- und Ablauforganisation oder den Kennzahlen selbst vorzunehmen. Abbildung 2 zeigt mögliche KPIs und Grenzwerte aus einem Logistikbeispiel.

Abbildung 2: Messung und Darstellung von KPIs VKSI MAGAZIN Nr. 9 November 2013

23


GUT, BESSER, AM BESTEN

Die Darstellung der KPIs in Dashboards kann in den meisten BPM-Tools relativ frei gewählt werden.

Abbildung 3: Grafische Aufbereitung von KPIs

Die KPIs dienen anschließend als Auslöser, um etwa Alarmmeldungen oder Benachrichtigungen zu verschicken, falls bestimmte Grenzwerte (Indikation für Probleme im Prozessablauf) erreicht werden. Entsprechend konfigurierte BPM -Systeme können diese Kennzahlen im laufenden Betrieb erheben und sich auf diese Weise potentiell selbst steuern (Stichwort Dunkelverarbeitung). Diese Mittel dienen in erster Linie zur operativen Überwachung, Steuerung und Automatisierung von Prozessen (Stichwort Business Activity Monitoring). Übergreifend müssen die daraus abgeleiteten Erkenntnisse aber im Rahmen des QM BPM Zyklus an die für Prozessverbesserung verantwortliche Stelle, idealerweise ein Process Competence Center oder den Prozesseigner, weitergeleitet werden. BPMN 2.0

Für die Definition von Messpunkten bietet die Notation BPMN 2.0 einige Konstrukte: als einfache Annotation, als Datenobjekt, als Nachricht oder als definierte System-Aktivität oder Service. In Ausnahmefällen muss gegebenenfalls vom IdealProzess-Sollzustand abgewichen werden, um eine saubere, eindeutige und vergleichbare Messung des Prozesses zu erreichen.

Quality Gates im QM-BPM Zyklus Durch die Realisierung eines Quality-Gate-Konzepts wird sichergestellt, dass nur bei Einhaltung von vorab eindeutig bestimmten Qualitätskriterien eine Freigabe für die nächste Projektphase erteilt wird. Auch bei der Prozessausführung können Quality Gates eingesetzt werden, hier darf der Prozess nur dann weiterlaufen, wenn die definierten Ergebnisse erreicht wurden. Inhaltlich ist ein Quality Gate in den meisten Fällen eine Checkliste, die es innerhalb des Quality Reviews abzuarbeiten gilt. Auch hier liegt die Schwierigkeit darin, geeignete Messpunkte für Quality Gates innerhalb des Prozesses zu definieren. Im QM-BPM Zyklus ist der Phasenübergang ein geeigneter Zeitpunkt. Für die konkrete Ausgestaltung eines Quality Gates im Prozessumfeld sind folgende Punkte wichtig: ●● die Aktivitäten, Anforderungen und Ergebnisse müssen definiert sein ●● das Ergebnis der Prüfung muss einfach darstellbar sein, z. B. als Ampel Diese Vorgehensweise stellt sicher, dass frühestmöglich Erkenntnisse über Abweichungen vorliegen und an kritischen Schnittstellen eine Fehlerweitergabe verhindert wird.

Fazit Die Definition von Prozessqualität ist nicht trivial, es ist zu Beginn schwierig, den Idealzustand eines Prozesses zu definieren. Meist kann nur eine schrittweise Annäherung, im Sinne eines agilen Vorgehens, im Rahmen eines QM -BPM Zyklus erfolgen. Eine reine Orientierung am Ergebnis des Prozesses ist aus vielerlei Hinsicht nicht mehr zeitgemäß. Viele Unternehmen definieren heute Kennzahlen und KPIs, die auch andere Aspekte wie Kundenzufriedenheit, Qualitätsaspekte und ProzessSLAs im Rahmen einer Balanced Scorecard umfassen.

Abbildung 4: Business Monitoring – Alarmmeldung

24

VKSI MAGAZIN Nr. 9 November 2013


Für BPM -Projekte sollten die Verantwortlichkeiten klar geregelt sein: wer ist Prozesseigner, wer dokumentiert den Prozess, wer setzt ihn um? Wie und wohin werden Ergebnisse und Schwierigkeiten kommuniziert? Was sind die Freigabemechanismen und Quality Gates? Für die Prozessdokumentation sind Konventionen, Pattern, Best Practices und fachliche Muster wichtig, die auch breit im Unternehmen gestreut werden sollten. Hilfreich ist eine Kombination von grafischer BPMNModellierung und von Wikis. Die Anregungen und Vorschläge mögen teilweise formalistisch klingen, sind dennoch aus Sicht der Autoren durchaus gerechtfertigt. Mindestens sollte vor Projektbeginn erarbeitet werden, was für das konkrete Unternehmen notwendig, sinnvoll und umsetzbar ist. Nichtsdestotrotz ist es manchmal wichtiger, pragmatisch an die Prozessumsetzung zu gehen, um rasche Erfolge vorweisen und erst einmal loslegen zu können. Dann jedoch muss in einem zweiten Schritt der Prozess formalisiert werden, damit Skaleneffekte und eine Lernkurve eintreten. »Prozesse mit BPMN zu beschreiben ist einfach, einfach lesbare und qualitativ hochwertige Prozesse mit BPMN zu beschreiben ist eine Kunst für sich.« (camunda, 2012)

Literaturverzeichnis

camunda. (2012). BPMCon 2012 , Berlin David McCoy, G. (2005). Business Process Management: Preparing for the Process-Managed. IBM. (2012). IBM – BPM Software. Von http://www-03.ibm.com/software/products/de/de/category/bpm-software abgerufen Prof. Ayelt Komus, F. K. (2012). Qualität im Geschäftsprozess-Management – Internationale Studie »Experten-Befragung«. Von http://www. hs-koblenz.de/www-Q-in-BPM-info.4232.0.html abgerufen

Sven Fischer, Senior Consultant BPM bei der logicline GmbH Edgar Schüber, Geschäftsführer bei der logicline GmbH

www.logicline.de Sven Fischer

Edgar Schüber

Anzeige

KARLSRUHE

LIEGT RICHTIG

Jung, impulsiv und voller Ideen – Badens Wirtschaftsmetropole sprüht vor Lebenslust, die Zukunftsweichen klar auf Wachstum ausgerichtet. Die Voraussetzungen für erfolgreiche Unternehmen, für Wissenschaft und Innovationen, für Kunst und Kultur, vor allem aber als Zuhause und Lebensmittelpunkt sind überzeugend. Hiermit finden Sie direkten Zugang zu allen Informationen der Wirtschaftsförderung Karlsruhe. Ob Sie Existenzgründer oder Global Player sind, wir bieten Ihnen umfassende Service-Leistungen und unterstützen Sie in Ihren räumlichen Entwicklungsmöglichkeiten. www.karlsruhe.de/wirtschaft Telefon: 0721 133-7300 E-Mail: wifoe@karlsruhe.de

KWF_Anz_quer_210x145mm_rz-010813.indd 1

VKSI MAGAZIN Nr. 9 November 2013

01.08.13 11:41

25


RUBRIK

IMPRESSUM

Gut, besser, am besten Machen wir uns nichts vor, es geht immer um hervorragende Qualität. Mit einer Quick-and-dirty-Lösung möchte niemand bei seinem Kunden oder seinem Professor auftauchen. Jede und jeder möchte nachweisen, dass die eigenen Leistungen und Produkte von exzellenter und darum auszuwählender und zu bevorzugender Qualität sind. »Wenn du gut sein willst, dann nimm zuerst an, dass du schlecht bist«, wird denn auch seit dem Altertum gesagt und Gottfried Keller trieb sich und andere mit den berühmten Worten an: »Wir bleiben nicht gut, wenn wir nicht immer besser zu werden trachten.« Aber auch Trost bietet der Zitate-Schatz. Baruch de Spinoza, ein niederländischer Philosoph aus dem 17. Jahrhundert, hat trocken festgestellt: »Alles Vortreffliche ist ebenso schwierig wie selten.« Das hat ihn selber nicht daran gehindert, einer der vortrefflichsten Denker und meistzitierten Philosophen zu werden. Uns andere jedoch führt solche Selbsterkenntnis leider nicht unbedingt zu zitierfähigen Aphorismen, aber manchmal zu tiefer Gelassenheit. Dabei gelingt dann mitunter ein guter Wurf, wie zum Beispiel die liebenswert trotzige Kollektion einer kleinen Berliner Manufaktur. Ihre T-Shirts mit dem in großen, freundlichen Buchstaben geschriebenen Spruch »IS MIR EGAL ICH LASS DAS JETZT SO« haben einen ungebrochen großen Erfolg, die dazu angelegte Facebook-Fanseite gefällt fast 50.000 Menschen. Dort äußern sich aber nicht nur, wie man jetzt denken könnte, zynische Qualitätsverweigerer, die zu oft den Flaschenöffner mit dem Aufdruck »IS MIR EGAL ICH TRINK DAS JETZT NOCH «, verwenden. Vielmehr geht es dort um nachsichtig-ironisches Anprangern von »Gut gewollt und doch gescheitert« und in den meisten Fällen geht es um vernachlässigte Aufgaben im Haushalt. Bei der Arbeit jedoch verstehen die meisten von uns – was die Qualität anbelangt – keinen Spaß. Und auch wenn die Bewertungen der Arbeitsergebnisse naturgemäß unterschiedlich ausfallen: Es ist das beständige Ringen um bessere Qualität, das in Unternehmen, in Teams und Organisationen zu Auseinandersetzungen führt. Nicht immer ist dann Trägheit die Ursache für Argumentationen im Stil von »das haben wir schon immer so gemacht«. Oft ist es einfach Angst, eine bewährte Vorgehensweise gegen ein unsicheres Abenteuer zu tauschen. Aber Angst ist kein guter Ratgeber und Angst vor Fehlern führt zu lähmendem Stillstand. Für hervorragende Qualität aber braucht man Mut. Lasst uns also die Ohren steif halten und mutig weiter ringen, mehr Spaß hat man so auf alle Fälle,

herzlich, Ihre Susann Mathis

26

Impressum Organ des VKSI – Verein der Karlsruher Software-Ingenieure 5. Jahrgang, Heft 9 / November 2013 www.vksi.de ISSN 1869-5442 ViSdP.: Christian Popp, Prof. Dr. Ralf Reussner, Prof. August Wegmann Herausgeber: VKSI – Verein der Karlsruher Software-Ingenieure e.V., www.vksi.de Vorstand: Christian Popp, Prof. Dr. Ralf Reussner, Prof. August Wegmann Anschrift: Prof. Dr. Ralf Reussner FZI Forschungszentrum Informatik Haid-und-Neu-Straße 10-14 76131 Karlsruhe Redaktion: Dr. Susann Mathis, Karlsruhe, www.susann-mathis.de, redaktion@vksi.de Telefon +49 721 38 42 435 Gestaltung: Jochen Härtel, designteam, München, www.designteam.eu Druck: NINO Druck GmbH Anzeigen: redaktion@vksi.de Erscheinungsweise: 2 Ausgaben pro Jahr Urheberrecht: Die Zeitschrift und alle in ihr enthaltenen Beiträge und Abbildungen sind urheberrechtlich geschützt. Mit Ausnahme der gesetzlich zugelassenen Fälle ist eine Verwertung ohne Einwilligung des Verlages unzulässig. Alle Rechte vorbehalten. Gewährleistung: Die Angaben in den Beiträgen erfolgen nach bestem Wissen, aber ohne Gewährleistung. Beiträge: Beiträge sind grundsätzlich willkommen. Bitte sprechen Sie diese mit Dr. Susann Mathis ab. Für unverlangt eingesandte Manuskripte und Abbildungen wird keine Haftung übernommen. Verfasser stimmen dem Abdruck zu und versichern, dass die Einsendungen frei von Rechten Dritter sind. Namentlich gekennzeichnete Beiträge enthalten die Meinung der Autoren. Nicht gekennzeichnete Beiträge sind Beiträge der Redaktion. Der Verein der Karlsruher Softwareingenieure e.V. (VKSI) wurde im Oktober 2008 gegründet. Sein Vereinsziel lautet, eigenständige und fokussierte Maßnahmen zu ergreifen, um die öffentliche Wahrnehmung der Softwaretechnik als Ingenieurdisziplin zu fördern, Kenntnisse und Erfahrungen in der Softwaretechnik zusammenzuführen und weiterzugeben, Innovationen in der Softwaretechnik zu beschleunigen und zu verbreiten und den wissenschaftlich-technischen Nachwuchs zu fördern. Der Verein hat sich darüber hinaus zum Ziel gesetzt, ein Bild über die Vielfalt von Software Engineering in Karlsruhe zu vermitteln und die Attraktivität des Karlsruher Software-Arbeitsmarktes zu transportieren. Bildnachweis: Igor Negovelov/J. Härtel S. 1; ghoststone/J. Härtel S. 4, 6, 7, 22; Dr. Susann Mathis S. 15, 27; Tom ­Kohler S. 16-19; Adam Radosavljevic S. 20; viktoriagavril/J. Härtel S. 22

VKSI MAGAZIN Nr. 9 November 2013


VKSI INTERN

Agile Unternehmen

VKSI hat Special Interest Group »Enterprise Agility« gegründet

Häufig treten Konflikte auf, wenn Scrum-Teams und das Management mit unterschiedlichen Zielsetzungen arbeiten. Die Blaupause für Konflikte sieht dabei folgendermaßen aus: Das Team arbeitet mit kurzen Iterationen und regelmäßigem Feedback, während das Management die Erfüllung detaillierter, langfristig angelegter Pläne verfolgt.

Dass Enterprise Agility, die Übertragung der Werte und Prinzipien der Agilität auf das ganze Unternehmen, intensiv diskutiert wird, zeigte sich auch beim Karlsruher Entwicklertag 2013. Dort wurde vielfach der Wunsch nach weiteren Austauschmöglichkeiten geäußert. Diese Anregung hat der VKSI aufgegriffen und eine eigene Special Interest Group »Enterprise Agility« innerhalb des VKSI gegründet. Dank der Sponsoren arvato infoscore GmbH und andrena objects ag konnte der VKSI die neue Special Interest Group in einem »kick-off«Meeting mit der Scrum-Legende Ken Schwaber starten. Ken Schwaber, Autor zahlreicher bekannter Bücher wie »Agile Software Development mit Scrum« oder »Software

in 30 Tagen«, hat beim VKSI den »Agility Path – Enterprise Scrum as a continuous improvement framework« präsentiert, einen Weg zu durchgängiger Agilität im ganzen Unternehmen. Christian Popp hat im zweiten Teil der Veranstaltung am Beispiel von arvato infoscore  die Transition von einer traditionellen Projektorganisation hin zu einer agilen Organisation vorgestellt. Die Special Interest Group »Enterprise Agility« wird in Zukunft eine die Plattform für den direkten und regelmäßigen Austausch aller Interessenten innerhalb der regionalen IT Community bieten. Melden Sie sich beim VKSI, wenn Sie diese Gruppe mitgestalten wollen.

Hélène Valadon präsentiert gemeinsam mit Christian Popp, der Vortrag »Our Way to Agility« ist dokumentiert auf: www.parleys.com/ play/51ebc110e4b0038cdf2c1483/chapter0/about

Ken Schwaber präsentiert gemeinsam mit Gunter Verheyen »Agility Path. Continuous Improvement / Competitive Advantage«: www.parleys.com/ play/51ea9588e4b0354ac31ac511/chapter0/about

Ken Schwaber

Hagen Buchwald (andrena object ag) und Christian Popp (arvato infoscore GmbH)

VKSI MAGAZIN Nr. 9 November 2013

27


VEREIN

Verein der Karlsruher Software-Ingenieure

Antrag auf Mitgliedschaft für Einzelpersonen Ich beantrage die Mitgliedschaft im Verein der Karlsruher Software-Ingenieure e.V. (VKSI)

Vorname, Name

Anschrift

Telefonnummer E-Mail

Arbeitgeber

Ich bin seit

(Jahr/en) als Software-Ingenieur tätig.

Einzugsermächtigung (optional): Ich ermächtige den VKSI widerruflich die zu entrichtenden Beiträge zum Beginn des K ­ alenderjahres von meinem Girokonto durch Lastschrift einzuziehen. Wenn mein Konto die erforderliche Deckung nicht aufweist, besteht seitens des Kreditinstitutes keine V ­ erpflichtung zur Einlösung. Teileinlösungen werden im Lastschriftverfahren nicht vorgenommen.

Kontonummer, BLZ, Bank

Datum, Unterschrift

Der Mitgliedsbeitrag für natürliche Personen beträgt 50,- EUR, für Studierende und Auszubildenden 25,- EUR, für GI-Mitglieder 40,- EUR (Bescheinigungen bitte beilegen). Datenschutzerklärung: Persönliche Daten unterliegen dem Datenschutz. Sie werden nicht veräußert und ausschließlich zu vereinsinternen Zwecken ­verwendet, insbesondere zur Aufrechterhaltung des Kontakts zu den Mitgliedern.

Antrag auf Mitgliedschaft für Juristische Personen, Firmen und wirtschaftlich aktive Organisationen Wir beantragen die Mitgliedschaft im Verein der Karlsruher Software-Ingenieure e.V. (VKSI)

Firma, Name der Organisation

Anzahl der Mitarbeiter

Name des Ansprechpartners

Anschrift

Telefonnummer E-Mail

Name, Vorname des/der Unterschreibenden (in Klarschrift)

Datum, Unterschrift (Zeichnungsberechtigter)

Einzugsermächtigung (optional): Wir ermächtigen den VKSI widerruflich die zu entrichtenden Beiträge zum Beginn des K ­ alenderjahres von unserem Girokonto durch Lastschrift einzuziehen. Wenn unser Konto die erforderliche Deckung nicht aufweist, besteht seitens des Kreditinstitutes keine ­Verpflichtung zur Einlösung. Teileinlösungen werden im Lastschriftverfahren nicht vorgenommen.

Kontonummer, BLZ, Bank

Datum, Unterschrift

Der jährliche Mitgliedsbeitrag für Firmen und wirtschaftlich tätige Organisationen beträgt 250,- EUR (1 bis 9 Mitarbeiter), 500,- EUR (10 bis 99 Mitarbeiter), 1.000,- EUR (100 bis 999 Mitarbeiter), 2.000,- EUR (1.000 und mehr Mitarbeiter). Datenschutzerklärung: Persönliche Daten unterliegen dem Datenschutz. Sie werden nicht veräußert und ausschließlich zu vereinsinternen Zwecken ­verwendet, insbesondere zur Aufrechterhaltung des Kontakts zu den Mitgliedern. Verein der Karlsruher Software-Ingenieure (VKSI) e.V. | c/o Prof. Dr. Ralf Reussner | Forschungszentrum Informatik | Haid- und Neustr. 10-14 | 76131 Karlsruhe

VKSI-Magazin #9  

VKSI Autoren zu Qualitätssicherung: Unter dem Titel "Warum guter Code und agiles Testen ein schönes Paar sind" beschreiben Maynard Harstick...

Read more
Read more
Similar to
Popular now
Just for you