VKSI-Magazin #9

Das Magazin des

issn

186

9-54

42

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

Softwareentwicklung aus Karlsruhe

Nr. 9 | November 2013Magazin

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 kom-plexen Leistung sehen kann und damit die Integration des eige-nen 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 verzah-nen. »Professionelle Qualitätssicherung in einem Multi-Platt-form-Umfeld« lautet der Titel des Artikels von Alexander Schmitt, Jürgen Ockert und Ralf Payer. Und schließlich fra-gen sich Edgar Schüber und Sven Fischer, ob die Kombination » Prozesse und Qualität« ein Oxymoron ist, also eine rhetori-sche 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 Kon-ferenz für Software Engineering, eine große Rolle gespielt hat, haben wir noch eine kleine Übersicht über die dort gehaltenen Beiträge beigefügt.

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 aufgegrif-fen, 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 enga-gieren. 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 Infor-matik, ist am 9.10.2013 verstorben. Unseren Nachruf lesen Sie auf Seite 13.

Freundliche GrüßeIhreChristian Popp und Ralf Reussner

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

2 VKSI MAGAZIN Nr. 9 November 2013

INHALT

EDITORIAL Christian Popp, Professor Dr. Ralf Reussner: Willkommen! 3

GUT, BESSER, AM BESTEN Drum prüfe, wer sich ewig bindet –

Warum guter Code und agile Tests ein schönes Paar sind. 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 2013 16

Prozesse und Qualität –

Oxymoron oder schwerlich zu erreichender Idealzustand 22

NACHRUF Professor Dr. Gerhard Krüger 13

RÜCKSCHAU Sneak-Previews des VKSI:

HockeyApp Framework, Robolectric und Saphir Fork.

VKSI Sneak Preview zum Thema »Android QS« 14

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 26

ANZEIGE Wirtschaftsföderung Karlsruhe 25

Nr. 9 | November 2013Softwareentwicklung aus Karlsruhe

Magazin

VKSI MAGAZIN Nr. 9 November 2013 3

GUT, BESSER, AM BESTEN

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än-diger wird es, sie zu verbessern. Agiles Testen verfolgt daher den Ansatz, Testen und Entwickeln eng zu verzahnen.

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 Test-abdeckung 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, unab-hängig davon, an welcher Stelle des Produktionsprozesses sie

Drum prüfe, wer sich ewig bindetWarum guter Code und agile Tests ein schönes Paar sind von Maynard Harstick und Daniel Knapp


platziert sind. Das gilt zumindest dann, wenn sie nicht hun-dertprozentig 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 feh-lerhaft 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 Ein-treffen 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,

bringt die agile Vorgehensweise die Testexperten und die Ent-wickler 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 Wahr-scheinlichkeit, 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 feingranula-ren 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

Drum prüfe, wer sich ewig bindetWarum guter Code und agile Tests ein schönes Paar sind von Maynard Harstick und Daniel Knapp

p

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 aufbe-reitet. 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 unangefochte-nen Nr. 1 der Java-Bewegung entwickelt.

1. Test von POJOs (reine Business-Logik)

3. Test mit realer Persistenzschicht

4. Integrationstests mit Applikationsserver

ohne Applikationsserver

Viele Tests; geringe Ausführungszeit

Wenige, umfangreiche Tests; hohe Ausführungszeit

Dau

er

2. Test mit Persistenzschicht (HSQL-DB)

Anz

ahl

1. Test von POJOs (reine Business-Logik)

2. Test mit Persistenzschicht (HSQL-DB)

3. Test mit realer Persistenzschicht

4. Integrationstests

Abbildung 1: Testpyramide



ist es schön, wenn sich Entwickler rein auf die Funktionali-tä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. Beispiels-weise deswegen nicht, weil der Code praktisch ständig refak-torisiert wird. Für dieses Refaktorisieren bilden die Tests eine Art Sicherheitsnetz, indem sie die Funktionalität einer Soft-ware 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 Dienstleis-ter für ein integriertes und wertorientiertes Management von Kundenbeziehungen und Zahlungsflüssen. Als solcher bearbei-tet das Unternehmen bis zu 50 000 Bonitätsanfragen pro Stun-de. 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 Sys-temkomponenten 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 erteil-te die arvato infoscore GmbH dem Karlsruher Beratungs- und Entwicklungshaus andrena objects den Auftrag, die Systeme

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 umfangrei-che Systemumstrukturierungen, beispielsweise, um eine tech-nische 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 entspre-chende 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 perma-nent ausführbar und nehmen nur Sekunden an Laufzeit in Anspruch. Gemeinsam bilden sie das primäre Fangnetz, inner-halb dessen die Software restrukturiert und weiterentwickelt werden kann. Rein theoretisch ließe sich die gesamte Funktio-nalität auf dieser Ebene prüfen.

Die Praxis hingegen ist häufig komplexer, weil Fremdsys-teme 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-in-Memory«-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

p


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 Appli-kationsserver läuft. Tests der Ebene 4 starten zuerst den Server und schicken dann von außen Anfragen an das zu testende Sys-tem.

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 Zusammen-arbeit 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 Faustre-gel, dass die Anzahl der Tests abnehmen sollte, je höher die Testebene ist. Denn synchron mit der Ebene steigt die Kom-plexitä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 durchge-spielt, dann reichen auf der Ebene der Integrationstests exem-plarisch 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.

Fazit Tests gezielt weitreichend zu automatisieren und, je nach Ab straktionsgrad, unterschiedlich einzusetzen, erhöht die Test-abdeckung und damit mittelbar die Codequalität. Damit sinken die ansonsten sehr häufigen, späteren Kosten zur Fehlerbehe-bung deutlich. Außerdem ist die hohe Testabdeckung elemen-tare Voraussetzung für das Refaktorisieren, das seinerseits zur Basis des agilen Programmierens gehört. Und für agiles Pro-grammieren hat sich das Beispielunternehmen arvato infoscore GmbH klar entschieden. Dazu werden bereits XP-Techniken wie Pair Programming und Test-First eingesetzt. Erste Ein-drücke der betroffenen Entwickler und Fachbereiche sind sehr positiv. Im Verbund mit den Testfällen auf verschiedenen Ebe-nen wurde also die Basis gelegt, die Softwarequalität noch wei-ter 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 unter-stü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 Softwarequali-tätssicherung sowohl im klassischen Entwick-lungsbereich als auch im agilen Umfeld tätig.

Daniel Knapp studierte Wirtschaftsingenieur-wesen am KIT und arbei-tet seit 2005 als Soft-wareentwickler bei der andrena objects ag. 2010 wurde er zum Leiter des

Geschäftsfelds Lösungen berufen. Sein Hauptinte-resse gilt dem Agile Software Engineering.

Daniel Knapp

Maynard Harstick



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 Inno-vationsfä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 ver-netztes Handeln Entwickeln sie gemeinsam neue Geschäfts-modelle 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.

Das Konzept Smart House umfasst das erstmals in Deutsch-land entwickelte Mieterserviceportal der Volkswohnung GmbH, welches sämtliche Vorgänge rund um das Wohnen bündelt. Zum Beispiel können Mieter über ein mobiles alters-gerechtes 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 Elektro-mobilität entstanden. Die Mobilitätsplattform Green Mobili-ty ermöglicht Veranstaltern, die Anreise ihrer Gäste umwelt-freundlich 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 angeleg-ten Entwicklungen gehen aber weiter und werden durch einen von Wirtschaftsförderung Karlsruhe und Fraunhofer-Institut

Karlsruhe wird zur SmarterCity von Ralf Eichhorn

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


für System- und Innovationsforschung (ISI) moderierten Prozess für ein »Roadmapping 2025« vorangetrieben. Drei Leuchtturmprojekte stehen dabei im Vordergrund der Konzep-tion: 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 Wettbewerbsvor-teile verschaffen«, resümiert Michael Kaiser, Direktor der Wirt-schaftsförderung Karlsruhe.

Mit Hilfe der Innovationen aus dem geplanten Produkti-onspark 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 Technologie-Region Karlsruhe mit der Realisierung des Hightech-Gründer-zentrums Technologiefabrik und des Technologieparks Karls-ruhe entwickelt hat.

Heute sollen Kompetenzen aus dem IT-Bereich mit Kom-petenzen 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 inno-vative 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

Karlsruhe wird zur SmarterCity von Ralf Eichhorn

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

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örde-rung Karlsruhe zuständig für techno-logieorientierte Unternehmen und Forschungseinrich-tungen, Cluster und Netzwerke, Innovati-onsförderung sowie Internationales.



Regelmäßige automatisierte Builds und Tests sind unverzicht-bare Elemente in der Entwicklung von Software-Produkten und deren Weiterentwicklung. Die Komplexität steigt, wenn nicht nur Software, sondern auch dazugehörige Hardware-Komponenten weiterentwickelt und getestet werden.

Wer heute ein Auto kauft erwartet, dass es längerfristig prob-lemlos funktioniert. Diese Erwartungshaltung besteht berech-tigterweise 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 Funkti-onalitäten erweitert wird und die Kompatibilität zu Vorgänger-versionen bewahrt sowie Stabilität, Performance und Speicher-verbrauch 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 Hard-ware zusammenarbeitet sowie die neuesten Betriebssysteme und Technologien unterstützt werden sollen. Hier bieten sich standardisierte Vorgehensweisen während des Entwicklungs-prozesses 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ätssiche-rung des hardware- und software-basierten Schutz- und Lizen-zierungssystems CodeMeter von Wibu-Systems eingegangen [1]. Herz der Technologie sind die CodeMeter-Lizenzcontainer. Lizenzen sind entweder in einer rein softwarebasierten CmAct-License 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 Imple-mentierung 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än-dig getestete Software zu schreiben. Bei inkompatiblen Ände-rungen 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 wer-den 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 wer-den. Die Weiterentwicklung sollte dann Maßnahmen umfas-sen, wie das Kapseln von Funktionalitäten und Verkleinern von

Funktionen, die es erlauben, für die umgebauten Teile Unit-Tests zu integrieren. Die Lesbar- und Überschaubarkeit der Sourcen wird dadurch gesteigert.

Multi-Plattform-EntwicklungDie Anzahl der Computer-Plattformen hat sich in den letz-ten 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 ver-mehrten 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 Power-PC-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 Embedded-Plattformen Cross-Compiler zur Verfügung stehen, kann die Entwicklung auf dem Hauptrechner stattfinden; Tests müssen allerdings auf einem Endgerät oder einer vorbereiteten Virtuel-len 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 Program-miersprache 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-Compi-ler 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 betriebssystemspezi-fischem 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 Kompo-nenten zu einer Anwendung ist einer der Kernpunkte im Ent-wicklungsablauf. 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 durch-führt.

Automatisierte Builds und TestsProfessionelle Qualitätssicherung in einem Multi-Plattform-Umfeld von Alexander Schmitt, Jürgen Ockert und Ralf Payer

Abbildung 1: Steuerung der Continuous Integration


RUBRIK

Das Ergebnis wird per E-Mail an den Entwickler aufbereitet, der mit wenigen Klicks bei Fehlern die entsprechenden (Com-piler-) 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 Zeichen-ketten.

Die Geschwindigkeit spielt eine wichtige Rolle: die durch-schnittliche 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ätSoftware-Qualität lässt sich auch über die Überprüfung der Source Code-Qualität sichern. Verschiedenen Tools für unter-schiedliche 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 Imple-mentierung neuer Funktionalität. Die Aufwände, aus Kun-densicht 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 Gegensteu-ern 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 Dash-board. Erfahrungen zeigen, dass die Durchführung eines Axi-vion-Builds pro Woche und dessen Auswertung ein sinnvoller Zyklus ist.

Daily BuildErscheint der CI-Prozess noch übersichtlich, ist das automa-tisierte Build komplexer. Build-Aktionen werden auf den glei-chen 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 ent-hält Linux und OS X-Binaries, sodass vor dem Bauen dieser Windows-Komponenten die anderen Plattformen beendet sein müssen.

Die Build-Zeit mit über 2 Stunden ist recht hoch, wobei Win-dows bremst. Während die anderen Plattformen nach wesent-lich kürzerer Zeit fertige Installer liefern, benötigt der Installer-Bau 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 Komponen-ten half die Wiederholung der Signierung in kürzeren Abstän-den.

Das Build-System stellt ein massiv paralleles Testsystem für Compiler, Linker, Source Code-Verwaltung und andere Ent-wicklungstools dar. Fehler umfassen hier Linker-Bugs, War-nungen oder Fehlerdialoge, die das System zum Stehen bringen können. Meist hilft es, den Job aus der Ferne neu zu starten.

Automatisierte Builds und TestsProfessionelle Qualitätssicherung in einem Multi-Plattform-Umfeld von Alexander Schmitt, Jürgen Ockert und Ralf Payer

Abbildung 2: Axivion Dashboard

Abbildung 3: Abhängigkeitspfade des Build-Systems



Bei der Verwaltung von Versionsständen über einen CVS-Server war das Setzen von Tags problembehaftet. Der Umstieg auf git bot eine saubere Lösung.

Begrenzter Speicherplatz ist immer kritisch. Das Build han-tiert 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 Pro-dukt-Installer, Test-Programme und Symbol-Dateien landen nach dem Build auf einem zentralen Server mit begrenztem Speicherplatz.

Überblick des Testsystems

Neben den Unit-Tests werden die Produkt-Installer für alle Plattformen vom Testsystem täglich automatisierten Integra-tionstests 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 Test-maschinen kopiert und vollautomatisch installiert.

Anschließend führt ein Postinstall-Job auf jeder Testmaschi-ne eine umfangreiche Test-Suite am installierten Produkt aus. Die Tests laufen mehrere Stunden. Derzeit sind sieben Testma-schinen im Einsatz.

Um die Testläufe auswerten, vergleichen und Fehler ein-grenzen zu können, werden die Log-Dateien archiviert und die Ergebniswerte mit den Randbedingungen in einer MySQL-Datenbank gespeichert. Eine PHP-Weboberfläche, der soge-nannte QAdmin, unterstützt bei der Analyse der Ergebnisse und der Erstellung eines Reports, der an die Entwickler ver-schickt wird.

Test-AutomatisierungDie 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

einbringt, verursacht Folgekosten. Und genauso wie für das Produkt ist für das Testsystem auch wieder eine Qualitätssi-cherung notwendig. Hier gilt, dass die Komplexität des Testsys-tems 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 Test-Programmen, 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 Randbedingun-gen 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-Auto-matisierung 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 QAd-min 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 noch-mals 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 Über-sichts-Report für jede Test-Maschine. Die Abbildung 6 zeigt einen aktuellen Ausschnitt für eine Maschine.

Abbildung 4: Architektur des Daily Integration Tests

Abbildung 5: CmSwitch bei der Test-Automatisierung


NACHRUF

Test-Gruppen mit Warnungen oder Fehlern sind gelb oder rot markiert. Hyperlinks öffnen eine detaillierte-re 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 verhin-dert, 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üh-rung wird die Frequenz allerdings erhöht.

FazitSoftware 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. Automa-tisierte Builds und Tests und deren Auswertung helfen, die Qualität ständig zu überprüfen und bei einer Verschlechte-rung 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/.

AutorenAlexander Schmitt ist seit 1998 bei Wibu-Systems und leitet die Soft-ware-Entwicklung.Jürgen Ockert arbeitet seit 2001 bei Wibu-Systems und ist stellvertre-tender 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.

Nach dem Physikstudium in Jena und Berlin und der Pro-motion 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 Telema-tik (als Kunstwort abgeleitet aus den Wörtern »Telekommuni-kation« 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 wei-teren 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 – For-schungszentrum 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 Gesell-schaft 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ünder-vater der deutschen Informatik, als prägende Gestalt der Karls-ruher Informatik und als vorbildlichen Menschen in ehrender Erinnerung halten.

Prof. Dr. Ralf Reussner

Wir trauern um

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.

Abbildung 6: Report eines Testlaufes


SNEAK PREVIEWS

Die Referenten der Sneak Preview im Juli 2013 beschäftigte sich mit Qualitätssicherung im Bereich der mobile APP Entwick-lung. Der Fokus lag auf der Android Plattform. Es gab wieder drei spannende Vorträge, die sich mit unterschiedlichen Best-Practices 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ögli-che zu testende Einheit eines Softwareprojekts in Isolation zu dem Rest zu testen. Dabei ist das Testen einer Unit in Isolati-on 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 Java-Projekt auf dem PC in der JVM ausführt? Geht nicht, führt Eric Gailus aus, denn das mit dem Android SDK ausgelieferte »and-roid.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 Soft-ware 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 fun-gierte.

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 ver-schiedene Aspekte. Zum einen die »Fragmentierung«: Unter-schiedliche Gerätetypen, Unterschiedliche OS Versionen und Hersteller-Brands, dazu müssen unterschiedliche Gerätekonfi-gurationen beim Testen berücksichtigt werden. Automatisierte

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 wiede-rum 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 getes-tet wurde?

Johannes Tysiak berichtet von den üblicherweise zu bewäl-tigenden 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 verbunde-nen Werte. Der Fokus seiner Arbeit liegt insbeson-dere auf den frühen Phasen der Software-Ent-wicklung.

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 weiterentwi-ckelt (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 folgen-de Gründe an: Interpreter seit Anfang 2012 als Open-Source verfügbar, die Technologie sei besser als Rebol 2. Das Testpro-dukt »Treemapper« zeige, dass professionelle Produkte mög-lich 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 kontinuier-liche Verbesserung möglich sei, erläutert der CEO der Saphirion AG.

Robert M. Münch ist Gründer mehrerer Unter-nehmen (Schwerpunkte: Prozessorentwicklung, Unternehmensberatung und Kostenmanagement-Software). Sein Hauptinteresse ist es, schnell ein-fache und gute Software zu produzieren und durch Nutzung eines eigenen Technologie-Stacks »Non-Value-Complexity« aus allem herauszuhalten.

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

VKSI MAGAZIN Nr. 9 November 201314

Test-Design, Performance-Analyse und JUnit 4.11Die 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 Kombinatio-nen zu testen ist völlig unmöglich – da nehmen wir uns ein paar raus und mehr geht nicht«. Um diesem Vorurteil zu widerspre-chen, stellte Dr. Jürgen Heymann eine Testdesign Methode vor, die systematisch mit Kombinatorik umgeht, um mit minima-lem 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 Braun-schweig und am Georgia Institute of Technology in Atlanta, und promovierte dann in Informatik an der TU München. Nach fünf Jahren Entwicklungs-arbeit bei verschiedenen Firmen in USA wechselte er 1995 zur SAP nach Walldorf. Dort war er zuerst in der Entwicklung von ABAP Objects, dann Archi-tekt und Manager im Produktbereich »SAP Por-

tals«. 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 Fall-bespiel, wie diese Komplexität gezielt reduziert werden kann, um Ursachen von auftretenden Performance Problemen auf-zuspüren und reproduzieren zu können. Es wird gezeigt, wie Querbezüge zwischen verschiedenen Systemkomponenten und Datenquellen erstellt und dargestellt werden, um geeignete

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 Soft-waretests innerhalb der Arvato Infoscore – IT, Bereich Risikomanagement. Er bringt als Diplom Ingenieur der technischen Informatik viele Jahre Erfahrung in der Softwareentwicklung, Software- Test und Testmanagement mit.

JUnit 4.11 – Die Neuerungen Marc Philipp

JUnit ist das älteste und am weitesten verbreitete Testing Framework für Java. Neben Unit Tests lassen sich damit auch Integrations- und Akzeptanztests automatisieren. Marc Phi-lipp 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 Asserti-on-Mechanismus (mit Hamcrest Matchers), die Möglichkeit, Vorbedingungen für Testfälle anzugeben und einen neuen Regel-basierten Ansatz, der es erlaube, komplizierte Test-Setups auf wiederverwendbare Art und Weise zu definieren. »Die Neuerungen bieten Entwicklern deutlich einfachere und zugleich mächtigere Möglichkeiten, Assertions zu formulieren, Tests zu schreiben und zu strukturieren. Das Resultat ist kom-pakterer 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 Organisa-tor von Konferenzen wie den XP Days Germany, die dieses Jahr in Karlsruhe stattfinden. Außer-dem arbeitet er an verschieden Open-Source-Pro-jekten, wie JUnit und Project Usus, mit.

Alle Vortragsfolien auf der VKSI-Website: http://www.vksi.de/sneak-preview/vergangene-sneak-previews.html


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 Accep-tance 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 Akzep-tanzkriterien 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 agi-len Prozess.

Wir haben den sehr pragmatischen TAD-Ansatz ursprüng-lich 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 Prozes-ses, 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« vor-stellen 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 Soft-ware-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 unter-schiedliche Branchen.

Sebastian Middeke ist Senior Software Qualitätsmanager bei der C1 WPS GmbH. Schon seit Studienzeiten liegt sein Fokus auf der Qualitätssiche-

rung von agilen Entwicklungsprozessen sowie der funktionalen und technischen Qualitätssicherung von objektorientiert entwickelten Anwendungs-systemen. Er verfügt über langjährige Erfahrung in der Beratung und Qualitätssicherung von agil durchgeführten Entwicklungsprojekten in vielfäl-tigen Branchen. Sebastian Middeke ist Quality Assurance Management Professional (QAMP) und Trainer für Certified Agile Tester (CAT).

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.

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


ENTWICKLERTAG

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

Der Vortag stellte Testwerkzeuge für nebenläufige Anwendun-gen vor. »Fehler in nebenläufigen Anwendungen sind durch ihre Abhängigkeit vom Scheduling charakterisiert; sie treten nur bei bestimmten Interleavings auf. Um Nebenläufigkeitsfeh-ler effektiv und effizient zu finden und zu reproduzieren, beein-flussen 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 Schrei-ben von nebenläufigen Tests gezeigt.«, so der Referent.

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

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

»Exploratives Testen ist weit verbreitet unter Entwicklern – und das schließt Programmierer genau so ein wie Tester. Obwohl ein hoher Automatisierungsgrad viele Regressions-fehler finden kann, können nicht alle Fehler durch Automati-sierung 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 Vordergrun-delement versteckt war, dann wir Ihnen klar, dass Testauto-matisierung diese Fehler nicht finden kann, sondern sogar Sie sogar in falscher Sicherheit gewogen hat. Zu einer funktionie-renden 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 wer-den Ihre Fähigkeiten herausfordern, Ihnen Tools und Struk-turen für Exploratives Testen an die Hand geben, und Ihnen damit dabei helfen, außerhalb Ihrer Komfortzone zu denken.«

Markus Gärtner arbeitet als testender Program-mierer, Trainer, Coach und Berater für it-agile GmbH, Hamburg. Markus schrieb unter anderem ATDD by Example – A Practical Guide to Accep-tance Test-Driven Development und steuert zur Softwerkskammer, der deutschen Software Crafts-manship 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 Hauptau-genmerk auf der Zusammenarbeit des Teams untereinander und mit allen Schnittstellen, um die Teams bestmöglich bei ihrer Arbeit zu unter-stützen. Meike bloggt auf http://agiletester.webno-de.com/blog über Testen, Teams und Kanban.

KARLSRUHER ENTWICKLERTAG

2013

p


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ßpro-jektes unterstützten sowie den Abstimmungs- und Kommu-nikationsaufwand reduzieren. Diese Rollen sind in der agilen Welt gänzlich unbekannt. Damit scheint die Anwendung der agilen Prinzipien auf Großprojekte nicht ohne weiteres über-tragbar zu sein«, hinterfragte Stephan Salmann in seinem Vor-trag.

Stephan Salmann ist Geschäftsführer und Mit-gründer der corporate quality consulting GmbH. Er studierte Betriebswirtschaftslehre und Wirt-schaftsinformatik an der Universität zu Köln. Nach seinem Studium war er lange Zeit in der IT-Beratung tätig. Dort war im Bereich Key-Account-Management, strategische Unterneh-mensentwicklung, Business Development und Projektleitung engagiert. In letzter Zeit hat er sich verstärkt mit den Themen IT-Industrialisierung, Strategische Steuerung der IT, Internationalisie-rung und IT-Produktmanagement beschäftigt. Im April 2005 gründete er mit Oliver Kuklok sein eigenes Beratungshaus, welches sich dem nachhal-tigen und ganzheitlichen Brückenbau zwischen Business und IT verschrie-ben hat.

Continuous Integration and Automated Testing in a multisite .NET/Cloud Project

The field report describes practical experiences with the imple-mentation 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 conti-nuous integration process, shares experiences of using project-specific 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 Entwick-ler in der Telekommunikationsindustrie. Seit 2008 ist er bei Tata Consultancy Services Deutsch-land GmbH, Düsseldorf als Entwickler, Scrum-Master 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 lie-ben, 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 Jahr-zehnt als Software-Entwickler, Architektin und Agiler Coach in größeren internationalen Projek-ten. 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.

p Werkzeuge und Erfahrungen


ENTWICKLERTAG

QS »From Scratch« – Erfahrungsbericht über die Einführung von QS in einem kleinen Softwareunternehmen

»Ihr Chef möchte ab sofort in Ihrem Unternehmen Qualitätssi-cherung betreiben! Gut wäre es jetzt, wenn die Firma gerade im Aufbau ist und noch niemand eine einzige Zeile Code geschrie-ben hat. Dann hat der QS-Beauftragte genug Zeit und Mög-lichkeiten, die entsprechenden Maßnahmen direkt in den Ent-wicklungsprozess 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 gewal-tig schief gelaufen ist – häufig mit entsprechenden finanziel-len 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 geschaf-fen 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.

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 ver-schiedener 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 Soft-waretechnik an der Universität Stuttgart abge-schlossen und arbeitet seit dem bei der Cinovo AG in Stuttgart. Dort ist er für Java-, Web- und Mobi-le-Entwicklung und Koordinierung der Qualitäts-sicherung zuständig. Schon seit 10 Jahren beschäftigt er sich mit Softwareentwicklung sowohl im Embedded-Bereich während der Aus-bildung zum Industrietechnologen bei der Siemens AG in München und später bei Vector Informatik in Weil im Dorf, als auch in der Webentwicklung.


CYBERTRENDS

Seit 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 andau-ernden Diskussionen zu dem Thema zu einen schnellen Ergebnis zu führen. Umgehend berief der Oberbürgermeis-ter eine Elefantenrunde mit Politikern, IT-Experten, Juristen, Marketingspe-zialisten und Vertretern der Wirtschaft zusammen. Ziel war es, ein Konzept für eine zügige Abdeckung zumindest der hochfrequentierten Plätze in der Innen-stadt mit kostenlosem WLAN zu entwi-ckeln.

Zur großen Überraschung der meisten Anwesenden kam dabei heraus, dass der

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 Aus-gangsposition 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 Karls-ruhe. 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 Out-door WLAN aufgrund von LTE-/UMTS-Verbreitung 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 über-lasteten Netzen und seiner hohen Band-breite seine Berechtigung, macht aber vor allem in Gebäuden und bei großer

Free WLAN Karlsruhe – jetzt noch draht- und kostenloser! Kolumne von Matthias H0rnberger, Vorstand CyberForum

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


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 Ver-kehrssituation, zu Veranstaltungen oder kostenlose Augmented Reality-Anwen-dungen 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äu-den 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.

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 Vorstands-vorsitzender des Cyber-Forum 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 Tech-nology 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.

Free WLAN Karlsruhe – jetzt noch draht- und kostenloser! Kolumne von Matthias H0rnberger, Vorstand CyberForum

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



Wie kann die Qualität von Prozessen sichergestellt wer-den?

Geschäftsprozesse und Business Process Management (BPM) sind schon seit geraumer Zeit bekannt, die Vorteile, Heraus-forderungen, 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 Nut-zen der einmal eingeführten Prozesse. Insbesondere dann, wenn die Prozesse nicht nur dokumentiert, sondern imple-mentiert 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 ers-ten Schritt gewöhnlich eine deutliche Optimierung der Prozess-Ergebnisqualitä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 Dif-ferenz von »manuell« und »unzureichend dokumentiert« zu »systematisch und IT-unterstützt« zu groß ist. Kleine Nachjus-tierungen 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, notwen-dige Standardisierungen im Vorgehen und Qualitätsmanage-mentmethoden hinten anstehen zulassen. Zu Beginn genügen häufig einfache Dinge wie Modellierungsrichtlinien, zugelasse-ne Symbole und Prozess-Muster, Versionierungsvorgaben und ein dezidierter Freigabeprozess für neue Prozesse oder Versio-nen.

Sind diese grundlegenden QS-Anforderungen umgesetzt, dann sollten generellere Fragen gestellt werden: Sind Quali-tätsmerkmale, wie sie bei Produkten oder Software unabding-bar sind, auch bei Prozessen notwendig? Wie können solche Merkmale identifiziert werden? Gibt es allgemeingültige Ansät-ze 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 Pro-zessen ist überschaubar. Zwar gibt es übergeordnete Standards und QS-Modelle wie die ISO 9000 (Grundlagen und Begriffe von Qualitätsmanagementsystemen) oder speziellere IT-Stan-dards 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

Rahmenbedingungen weitgehend außer Acht gelassen werden. Allen Modellen gemeinsam ist, dass die Definition und Verbes-serung 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 Prozess-verbesserung in der Erkennung von Flaschenhälsen. Bei Pro-duktionsprozessen in der Industrie mit verfügbaren physikali-schen 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 Dienst-leistungen 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 eigent-lich 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 gleicher-maßen gelten?

Denken wir an »mobile Prozesse« wie sie heute im Außen-dienst gelebt werden: wenn Barcodes gescannt, Dokumente

BPM: Prozesse und Qualität – Oxymoron oder 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 ver-

meidbar gewesen●● über 35% der Unternehmen mussten wesentliche Nacharbei-

ten vor Produktivsetzung vornehmen●● reine Prozessmanager erzielen bessere Projektergebnisse als

IT- oder fachliche Projektleiter●● bei ca. 50% der Unternehmen sind die Prozessbeschreibun-

gen nicht eindeutig genug und lassen somit Raum für Miss-verständnisse

●● Prozesse werden sehr häufig verändert, aber nur die Hälfte der Unternehmen haben hierfür eine MethodikEs fällt v. a. die unstrukturierte Vorgehensweise und fehlen-

de Methodik bei der Umsetzung von Geschäftsprozessen auf. Da scheinen Industrieproduktion oder Softwareentwicklung weiter zu sein.

Organisatorisch verankernProzesse 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 Pro-zesse. Und damit auch keine Überwachung der Leistungsfähig-keit der Prozesse und damit keine Prozessqualitätssicherung. Die Beurteilung der Qualität bleibt dem Kunden überlassen.

Einbettung in den QM-BPM-ZyklusBetten wir das Prozessmanagement in einen definierten QM-BPM Zyklus ein, schaffen wir die Rahmenbedingungen für den Prozessdurchlauf und das Erkennen von Schwachstellen. Die dafür notwendigen Rollen – Prozesseigner, Prozessana-lyst, BPM-Entwickler, Prozessmitarbeiter, Prozesscontrol-ler – werden geschaffen. Zentral ist die Durchgängigkeit der Prozessentwicklung: Der dokumentierte Prozess wird umge-setzt, ausgeführt, gemessen und nachjustiert. Es gilt die »ARIS-Wandtapeten« zu vermeiden, die oft zum Zeitpunkt der Fertig-stellung schon veraltet sind.

Flankierend werden Qualitätssicherungsmaßnahmen – Reviews, Feedbackrunden, Quality Gates, Freigabemechanis-mus, Anforderungsmanagement – in allen Phasen – Model-lierung, Entwicklung, Ausführung – den Prozesszyklus begleiten. Idealerweise sind diese Maßnahmen in eine umfas-sendere Unternehmensstrategie eingebettet, so wird Nachhal-tigkeit erreicht. Einen möglichen QM-BPM Zyklus zeigt Abbil-dung 1.

Geschäftskennzahlen und KPIs bereits bei ProzessbeschreibungGeschä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äh-ler und Stoppuhren. KPIs sind Voraussetzung für die Verbesse-rung 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 Kenn-zahlen und KPIs können dann stetig gesammelt, ausgewer-tet 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ögli-che KPIs und Grenzwerte aus einem Logistikbeispiel.

BPM: Prozesse und Qualität – Oxymoron oder schwerlich zu erreichender Idealzustand von Sven Fischer und Edgar Schüber

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

Abbildung 2: Messung und Darstellung von KPIs



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

Die KPIs dienen anschließend als Auslöser, um etwa Alarm-meldungen oder Benachrichtigungen zu verschicken, falls bestimmte Grenzwerte (Indikation für Probleme im Prozessab-lauf) erreicht werden. Entsprechend konfigurierte BPM-Sys-teme 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 Überwa-chung, Steuerung und Automatisierung von Prozessen (Stich-wort 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.0Für die Definition von Messpunkten bietet die Notation BPMN 2.0 einige Konstrukte: als einfache Annotation, als Datenob-jekt, als Nachricht oder als definierte System-Aktivität oder Service. In Ausnahmefällen muss gegebenenfalls vom Ideal-Prozess-Sollzustand abgewichen werden, um eine saubere, ein-deutige und vergleichbare Messung des Prozesses zu erreichen.

Quality Gates im QM-BPM ZyklusDurch 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ön-nen 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 abzuar-beiten gilt. Auch hier liegt die Schwierigkeit darin, geeignete Messpunkte für Quality Gates innerhalb des Prozesses zu defi-nieren. Im QM-BPM Zyklus ist der Phasenübergang ein geeig-neter Zeitpunkt. Für die konkrete Ausgestaltung eines Quality Gates im Prozessumfeld sind folgende Punkte wichtig:●● die Aktivitäten, Anforderungen und Ergebnisse müssen defi-

niert sein●● das Ergebnis der Prüfung muss einfach darstellbar sein, z. B.

als AmpelDiese Vorgehensweise stellt sicher, dass frühestmöglich

Erkenntnisse über Abweichungen vorliegen und an kritischen Schnittstellen eine Fehlerweitergabe verhindert wird.

FazitDie Definition von Prozessqualität ist nicht trivial, es ist zu Beginn schwierig, den Idealzustand eines Prozesses zu definie-ren. 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 Aspek-te wie Kundenzufriedenheit, Qualitätsaspekte und Prozess-SLAs im Rahmen einer Balanced Scorecard umfassen.

Abbildung 3: Grafische Aufbereitung von KPIs

Abbildung 4: Business Monitoring – Alarmmeldung


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 Freigabeme-chanismen und Quality Gates? Für die Prozessdokumentation sind Konventionen, Pattern, Best Practices und fachliche Mus-ter wichtig, die auch breit im Unternehmen gestreut werden sollten. Hilfreich ist eine Kombination von grafischer BPMN-Modellierung und von Wikis.

Die Anregungen und Vorschläge mögen teilweise formalis-tisch klingen, sind dennoch aus Sicht der Autoren durchaus gerechtfertigt. Mindestens sollte vor Projektbeginn erarbei-tet 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 forma-lisiert werden, damit Skaleneffekte und eine Lernkurve eintre-ten.

»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)

Literaturverzeichniscamunda. (2012). BPMCon 2012, BerlinDavid McCoy, G. (2005). Business Process Management: Preparing for the Process-Managed.IBM. (2012). IBM – BPM Software. Von http://www-03.ibm.com/soft-ware/products/de/de/category/bpm-software abgerufenProf. Ayelt Komus, F. K. (2012). Qualität im Geschäftsprozess-Manage-ment – 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

Edgar SchüberSven Fischer

Anzeige

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/wirtschaftTelefon: 0721 133-7300 E-Mail: [email protected]

KARLSRUHE LIEGT RICHTIG

KWF_Anz_quer_210x145mm_rz-010813.indd 1 01.08.13 11:41


RUBRIK

Gut, besser, am bestenMachen 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 wer-den. 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 Bei-spiel 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 Men-schen. Dort äußern sich aber nicht nur, wie man jetzt denken könnte, zynische Qualitätsverweigerer, die zu oft den Fla-schenö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äs-sigte 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äß unterschied-lich ausfallen: Es ist das beständige Ringen um bessere Quali-tät, das in Unternehmen, in Teams und Organisationen zu Aus-einandersetzungen 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

ImpressumOrgan 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, [email protected] Telefon +49 721 38 42 435

Gestaltung:Jochen Härtel, designteam, München, www.designteam.eu

Druck:NINO Druck GmbH

Anzeigen: [email protected]

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 Abbil-dungen 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 weiterzuge-ben, Innovationen in der Softwaretechnik zu beschleunigen und zu verbrei-ten und den wissenschaftlich-technischen Nachwuchs zu fördern. Der Ver-ein 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

IMPRESSUM


http://www.vksi.de

http://www.vksi.de

http://www.hs-karlsruhe.de

http://www.haerteldesign.de

mailto:[email protected]

VKSI INTERN

Häufig treten Konflikte auf, wenn Scrum-Teams und das Management mit unterschiedlichen Zielsetzungen arbeiten. Die Blau-pause 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 Entwickler-tag 2013. Dort wurde vielfach der Wunsch nach weiteren Aus-tauschmöglichkeiten geäußert. Diese Anregung hat der VKSI aufgegriffen und eine eigene Special Interest Group »Enter-prise Agility« innerhalb des VKSI gegründet. Dank der Spon-soren 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 Bei-spiel von arvato infoscore die Transition von einer traditionel-len Projektorganisation hin zu einer agilen Organisation vorge-stellt.

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.

Agile UnternehmenVKSI hat Special Interest Group »Enterprise Agility« gegründet

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

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


VEREIN

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 Kalenderjahres von meinem Giro-konto durch Lastschrift einzuziehen. Wenn mein 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 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 Kalenderjahres 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

Verein der Karlsruher Software-Ingenieure

Documents

VKSI-Magazin #9