VKSI-Magazin #2

Agil!Agile Software- entwicklung: Rollenspiel. Kombinationsspiel. Passspiel...

Außerdem in diesem Heft:

Multi-Core: Die Softwareentwicklung neu erfinden

Innere Qualität: Clean Code Development

Entwicklertag 2010

Das neue Magazin des

issn

18

69

-54

42

Softwareentwicklung aus Karlsruhe

Nr. 2 | Februar 2010

Magazin

Verein der Karlsruher Software-Ingenieure

VKSIMagazin-1002-08.indd 1 03.02.2010 17:08

VEREIN

* Antragsformular auf S. 39

Softwaretechnik (oder Software-Engineering) ist eine der Kerndisziplinen der Informatik und Grundlage fast aller Informatik-

Anwendungen. Eine Grundlage allerdings, die im Verborgenen liegt und von einer breiteren Öffentlichkeit nur ungenügend ver-

standen wird. Als Folge davon wird Softwaretechnik auch zu wenig als eigenständige Disziplin wahrgenommen und gewürdigt.

Obwohl (oder gerade weil) die Innovationsgeschwindigkeit in der Softwaretechnik so groß ist, wird der Stand der Technik in

der praktischen Softwareentwicklung sehr oft nur ungenügend berücksichtigt. Aus diesem Grund ergreifen wir eigenständige und

fokussierte Maßnahmen, 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,●● den wissenschaftlich-technischen Nachwuchs zu fördern.

In Karlsruhe und der Region sind herausragende Kompetenzen der Softwaretechnik versammelt: Am KIT und den anderen

Hochschulen, in den Forschungseinrichtungen der öffentlichen Hand und der privaten Wirtschaft, in vielen mittelständischen

Software-Unternehmen, bei nationalen und internationalen Marktführern. Diese Kompetenzträger erhalten mit dem VKSI eine

Plattform zur Außendarstellung und zum Austausch.

Wir haben uns viel vorgenommen. Dafür braucht der Verein Ihre Unterstützung!

Warum sollten Sie persönlich Mitglied werden?*

●● Der VKSI hilft mit, das einzigartige Karlsruher Ökosystem

von Software-Ingenieuren, Software-Firmen, Hochschulen

und anderen Forschungs- und Ausbildungseinrichtungen

weiter zu entwickeln. Davon profitieren wir alle.

●● Im VKSI lernen Sie interessante Kolleginnen und Kollegen

aus der Region kennen.

●● Der VKSI hilft Ihnen, fachlich auf dem Laufenden zu bleiben.

●● Der VKSI hält Sie informiert: Wir bündeln die Aktivitäten der

zahlreichen Karlsruher Software-Initiativen.

●● Der VKSI verschafft Ihnen einen Überblick über den Arbeits-

markt in der Region Karlsruhe: Wer macht was und wer

sucht wen?

Warum sollte Ihr Unternehmen Mitglied werden?*

●● Das einzigartige Karlsruher Ökosystem von Software-

Ingenieuren, Software-Unternehmen, Hochschulen und

anderen Einrichtungen muss noch bekannter werden. Der

VKSI macht die Vielfalt von »Software Engineering in Karls-

ruhe« öffentlich. Davon profitieren wir alle.

●● Der VKSI hat das Ziel, »Software Engineering aus Karls-

ruhe« als Qualitätsmerkmal zu prägen. Das unterstützt Sie

bei der Vermarktung Ihre Produkte und Dienstleistungen.

●● Der VKSI hilft Ihnen, Ihr Unternehmen bei den Studieren-

den der Karlsruher Hochschulen bekannt zu machen und

frühzeitig Kontakte zu Absolventen herzustellen.

●● Der VKSI hilft Ihren Mitarbeitern, durch gezielte Weiterbil-

dungsmaßnahmen fachlich auf dem Laufenden zu bleiben.

Werden Sie Mitglied im Verein der Karlsruher Software-Ingenieure e.V.


Verein der Karlsruher Software-Ingenieure (VKSI) e.V.

c/o Prof. Dr. Ralf Reussner

Forschungszentrum Informatik,

Haid- und Neustr. 10-14 | 76131 Karlsruhe

www.vksi.de | [email protected]

Vorstand: Dr. Dirk Feuerhelm, Prof. Dr. Ralf Reussner,

Prof. August Wegmann

Vereinsregister Karlsruhe 3406

2 VKSI MAGAZIN Nr. 2 Februar 2010


EDITORIAL

Willkommen!

Liebe Leserin, lieber Leser,

unseren Titel ziert ein Rugby-Ball. Wer die agile Szene kennt,

versteht sofort die Anspielung auf die Managementmethode

Scrum: Scrum (engl. für Gedränge) beschreibt die Standard-

situation im Rugby, um das Spiel nach einer Unterbrechung

neu zu starten. Beim Rugby geht es letztlich darum, den Ball ins

Ziel zu bringen. Bei der Softwareentwicklung geht es im Prinzip

um das Gleiche, nämlich darum, lauffähige Software abzulie-

fern.

2004 wurden im Karlsruher Technologiepark die ersten

deutschsprachigen Zertifizierungskurse für Scrum angeboten.

Große Unternehmen wie SAP, EnBW, 1&1 Internet AG etc.

wurden darauf aufmerksam und holten dieses Wissen in ihre

Häuser. Inzwischen ist der IT-Standort Karlsruhe eine wichtige

Referenz für agiles Know-how in Deutschland. International

erlangen agile Entwicklungsmethoden immer größere Auf-

merksamkeit – aus einer Grass-Roots-Initiative ist ein Wettbe-

werbsvorteil geworden.

So war Karlsruhe mal wieder erster in Deutschland: erste

Informatik-Vorlesung, erste Informatik-Fakultät, erste E-Mail

– und erste Scrum-Kurse. Als Schwerpunktthema unseres

aktuellen VKSI-Magazins lassen wir Karlsruher Scrum-Pro-

tagonisten über Einsichten und Projekte berichten und setzen

uns mit der Frage auseinander, ob und wie sich »Architektur«

und »agile Entwicklung« sinnvoll kombinieren lassen. Außer-

dem lesen Sie in diesem Heft über Erfolge mit Multikern-Sys-

temen und über weitere herausragende Themen des Karlsruher

Software-Engineering.

In seinem ersten Jahr hat der Verein der Karlsruher Soft-

ware-Ingenieure einiges erreicht: Das Karlsruher Manifest

für Software Engineering hat eine stattliche Anzahl promi-

nenter Unterzeichner gewonnen. Zum VKSI-Day im Rahmen

des einwöchigen Karlsruher Entwicklertags kamen fast 200

Teilnehmer (auch 2010 wird es daher einen VKSI-Day beim

Entwicklertag geben). Die erste Sneak Preview mit exklusiven

Informationen von Mitgliedern für Mitglieder hat stattgefun-

den und wir werden dieses Format ausbauen.

Entlang der Konturen des Karlsruher Manifests integrieren

wir 2010 weitere neue Projekte, z.B. widmen wir uns verstärkt

dem »Lebenslangen Lernen«. Und ganz besonders liegt uns

folgendes Projekt am Herzen: Um mehr Schülerinnen und

Schüler für den Beruf des Software-Ingenieurs zu begeistern,

werden wir BOGY in neuer Form fortführen. BOGY ist das Kür-

zel für den Prozess der Berufs- und Studienorientierung an den

allgemein bildenden Gymnasien in Baden-Württemberg. Ziel

unserer Aktion ist es, die Jugendlichen frühzeitig für die Infor-

matik zu interessieren und Vorurteile abzubauen. Das BOGY@

TPK war auf große Resonanz gestoßen. Das erweiterte Konzept

heißt: informatikBOGY. Träger ist die Fakultät für Informatik

des KIT, unser Verein wird die Industrie-Partner integrieren.

Wenn Ihr Unternehmen teilnehmen will oder auch wenn Sie

erst mal mehr erfahren wollen, schreiben Sie einfach an bogy@

vksi.de.

Unter den Siegern der zweiten Runde des Spitzencluster-

Wettbewerbs ist auch Europas »Silicon Valley«, der Software-

Cluster um Karlsruhe, Darmstadt, Kaiserslautern, Saarbrücken

und Walldorf. Damit ist die IT-Region Karlsruhe Teil des größ-

ten europäischen Software-Clusters. Darin vertreten sind die

großen deutschen Hersteller von Unternehmenssoftware IDS

Scheer AG, SAP AG und Software AG sowie über 350 kleine

und mittlere Unternehmen. Die drei führenden Informatik-

forschungszentren (DFKI, Fraunhofer, FZI) und die renom-

mierten Informatikfakultäten des Karlsruher Institut für Tech-

nologie, der TU Darmstadt, der TU Kaiserslautern und der

Universität des Saarlandes bringen ihre Kompetenzen in For-

schung, Entwicklung und Ausbildung in den Cluster ein.

Die IT-Region Karlsruhe bringt ihren Sachverstand im Soft-

ware Engineering ein. Auf dieses Know-how richtet der VKSI

den Fokus. Wir laden Sie ein, mit in das Scheinwerferlicht zu

treten: Werden Sie Mitglied im VKSI. Arbeiten Sie mit. Einen

Aufnahmeantrag finden Sie unter www.vksi.de.

Freundliche Grüße

Ihre

Dirk Feuerhelm und Ralf Reussner

Dr. Dirk Feuerhelm, 1&1 Internet AG, Prof. Dr. Ralf Reussner, KIT / FZI

VKSI MAGAZIN Nr. 2 Februar 2010 3


Steffi Krauses Erfahrungen

VEREIN Werden Sie Mitglied 2

EDITORIAL Dr. Dirk Feuerhelm, Professor Dr. Ralf Reussner: Willkommen! 3

AGILE SOFTWAREENTWICKLUNG MIT SCRUM*

ROLLENSPIEL I Der Scrum Master ist zuständig für alles: Zehn nützliche Regeln 6

ROLLENSPIEL II Die Schnittstelle zum Entwicklerteam: Sechs Regeln für den Product Owner 8

EINWURF Lizenzieren und Schützen eines Softwareprodukts: 10

KOMBINATIONSSPIEL Architektur und Agilität 12

AUSWECHSELSPIELER Rationalisierung der Kopfarbeit: Interview mit Andreas Boes 16

PASSSPIEL Vernetzt zum Erfolg bei der Energiebörse Leipzig: 18

ROLLENSPIEL III Selbstorganisiert: Zitate von Mitgliedern verschiedener Scrum-Teams 20

UM DEN BALL SCHIEBEN Schneller ans Ziel: Agile Softwareentwicklung bei 1&1 23

Christoph Schlenzigs Erfolg

Dr. Susann Mathis, Kommunikations-beratungwww.comm-coop.de

* Scrum ist eine Managementmethode im Rahmen agiler Softwareentwicklung. Der Begriff stammt aus dem Rugby.

Robert Hartmann, Software-Entwickler,CodeWrights GmbH

Redaktion und Gestaltung:


Nr. 2 | Februar 2010Softwareentwicklung aus Karlsruhe

Magazin


INHALT

Prof. Tichys Forschung Stefan Liesers Armbänder

KOLUMNE CyberTrends: Kolumne von Hagen Buchwald 9

F+E Multikern-Systeme: Neuerfindung der Softwaretechnik 24

F+E Bingo Voting: Sichere Wahlen durch vertrauenswürdigen Zufall 26

STANDORT Nachwuchskräfte: Neue Perspektiven in der Ausbildung 27

INITIATIVE Clean Code Developer: Initiative für professionelle Softwareentwicklung 28

STANDORT Gebündelte Kräfte: Starker IT-Standort Karlsruhe 31

TREND Kooperative Produktentwicklung: Rich-Client-Anwendungen mit Eclipse RCP 32

NACHLESE In eigener Sache: off-/online 34

IMPRESSUM 34

THINGS TO COME Vorschau: Programm Entwicklertag 2010 35

BERICHT Karlsruher Eclipse DemoCamp 36

XP Days 2009 37

informatikBOGY 37

VEREIN Karlsruher Entwickler tag 2009 38

VKSI Mitglieder versammlung, Sneak Preview und Weih nachts feier 38

Formular: Antrag auf Mitgliedschaft 39

Timm Reinstorf, Software-Ingenieur, andrena objects ag

Jochen Härtel, Härtel Design www.comm-coop.de

Redaktion und Gestaltung:



AGIL: ROLLENSPIEL I

Die Verantwortungen der drei Primär-

rollen in Scrum sind bekanntermaßen

ganz einfach:●● Der Product Owner ist verantwortlich

für das WAS.●● Das Team ist verantwortlich für das

WIE.●● Und beim Scrum Master wird’s noch

einfacher: Er ist verantwortlich für

ALLES.

Das heißt, ein Scrum Master sorgt dafür,

dass die Menschen in den verschiedenen

Rollen entsprechend ihrer Verantwort-

lichkeit befähigt werden. Er ist also in

erster Linie Coach.

Natürlich muss er auch Meister im

Anwenden der Scrum-Werkzeuge sein:

Er weiß, was eine Produktvision ist

(und was nicht), wie sie entsteht, was

dabei wichtig ist, er kennt den gesamten

Problemraum vom Anforderungsma-

nagement und der Beplanung, der Rea-

lisierung bis hin zur Qualitätssicherung

und Auslieferung. Ein Scrum Master ist

Experte jedes wichtigen Detailschritts

im Prozess der iterativ-inkre-

mentellen Produktentwicklung,

moderiert versiert die Meetings

und lässt die angemessenen

Artefakte entstehen.

So weit so gut. Aber was ist

jetzt der Coach im Scrum

Master?

In der einschlägigen Literatur ist

zu diesem Aspekt der Arbeit

eines Scrum Masters

bisher wenig zu fin-

den. Vielleicht ist

das auch der

Grund dafür, dass einige Teams und

Scrum Master einem ungesunden Dog-

matismus verfallen. Sicher haben Sie

Zitate wie: » das steht aber so in diesem

Buch…« oder »Im Training wurde das

aber anders gemacht….« etc., gehört.

Wenn solche Aussagen als Argumenta-

tion für bestimmte Vorgehensweisen

herhalten müssen, wissen Sie: Da stimmt

was nicht!

Die reale Welt ist größer als die Modelle

Scrum modelliert ein Management-

Framework. Und wie immer ist die reale

Welt größer als Modelle. Das heißt, wel-

che Gesetze akribisch eingehalten wer-

den müssen, welche Werkzeuge wirk-

lich unterstützen, welche Strukturen

zerstört oder geschaffen werden sollten

– das hängt ganz von der individuellen

Situation ab. Und genau diese muss ein

Scrum Master verstehen, bevor er seinen

Werkzeugkoffer auspackt. An dieser Stel-

le wird er oft feststellen: Das Team funk-

tioniert so nicht. Die Menschen

haben meist eine mehr oder

weniger ausgepräg-

te Leidensgeschichte

hinter sich und befin-

den sich im Zustand der

Lethargie und Antriebs-

losigkeit. Mit einer Pro-

zess-Schulung ist hier

wenig auszurichten.

Vielleicht hatten Sie

schon einmal ein Kör-

perteil

nach

einem Unfall für längere Zeit eingegipst:

Erinnern Sie sich an die Zeit unmittelbar

nach Abnahme der Bandage? Daran, wie

unbeholfen sich der Körperteil anfühlte?

Wie lange es gedauert hat, ihn als routi-

niertes Rädchen im Gesamtsystem Kör-

per wieder zu integrieren?

Ein desolates Team hat mit demselben

Effekt zu kämpfen. Die Menschen haben

sich in ihre Komfortzonen zurückgezo-

gen und ein hübsches Mäuerchen um die

eigene Persönlichkeit errichtet. Denken

muss wieder geübt, Verantwortung neu

begriffen und gelernt werden.

Erste Aufgabe: die innere Zustimmung

des Teams

Neben dem Verständnis für das Unter-

nehmen und das Projekt mit seinen Zie-

len, ist die allererste Aufgabe des Scrum

Masters also herauszufinden, wo jedes

Individuum im Team steht: Welches

Teammitglied hat womit die größten

Schwierigkeiten? Entspricht die Arbeit

seiner Leidenschaft und Expertise? Tut

er sie freiwillig? Wie sähe seine Wunsch-

liste für eine glücklichere Arbeitswelt

aus?

Kommen Sie den Menschen ein Stück

entgegen, bevor Sie einen großen Teil

ihrer Komfortzonen zerstören! Lassen

Sie die Teammitglieder die Relevanz

ihrer Expertise spüren und die Wichtig-

keit ihrer Kreativität! Ohne die innere

Zustimmung eines jeden Einzelnen im

Team werden Sie es als Scrum Master

schwer haben, Veränderungsprozesse

anzustoßen und erfolgreich zu imple-

mentieren. Schaffen Sie auf allen rele-

vanten Ebenen ein Problem-Com-

mitment, bevor Sie mit Lösungen

winken!

Denn eines ist unumstößlich: Sie

brauchen die Menschen, wenn Sie ein

leistungsfähiges, selbstorganisiertes

Team entstehen lassen wollen. Es ist

übrigens gut möglich, dass Sie auf dem

Weg den einen oder anderen verlieren,

das ist in Ordnung! Nicht jeder mag selb-

storganisiert und eigenverantwortlich

Der Scrum Master ist zuständig für alles Scrum Coach Steffi Krause fasst ihre Erfahrungen zu zehn nützlichen Regeln für Scrum Master zusammen

Fot

o: T

om K

ohle

r



arbeiten. Je eher das erkannt wird, desto

besser!

Hat ein Scrum Master es geschafft,

Bereitschaft und Motivation für Verände-

rungen im Team zu erzeugen, ist der Rest

nicht mehr so schwer. Der Werkzeug-

kasten wird gerne begutachtet, das eine

oder andere Werkzeug wird mit Freude

ausprobiert, Fertigkeiten optimiert und

zu guter Letzt werden neue Werkzeuge

erfunden, die ganz spezifische Probleme

lösen. All das passiert völlig automatisch,

wenn Menschen sich verantwortlich füh-

len und mit Leidenschaft und Freude

arbeiten.

Jetzt haben wir den Salat: ein guter

Scrum Master muss neben seiner metho-

dischen Expertise ein Mensch sein, der

andere Menschen begeistern und moti-

vieren kann und zudem noch eine gewis-

se innere Autorität ausstrahlt!

Zehn Regeln für Scrum Master:

1 Erst die Regeln lernen, dann brechen.

Bestehen Sie anfangs auf das komplette

Design des Prozesses, damit sich Wich-

tigkeiten und Nichtigkeiten herausbilden

können.

2 Die Adlerperspektive behalten.

Wenn Sie zu tief im Detail stecken, sehen

Sie das Gesamtbild nicht mehr und kön-

nen dem Team schlechter helfen: Der

Umfang des Waldes lässt sich nicht erfas-

sen, wenn man mittendrin steht.

3 Im Zweifelsfall den gesunden Menschen verstand einsetzen.

Ist das Team mit einem Problem kon-

frontiert, auf das Scrum keine Lösung

weiß, fragen Sie einfach Ihren Kopf.

Manchmal hilft es, die Szene in das Pri-

vatleben zu übersetzen und zu fragen:

Was würdest Du jetzt als Privatperson

tun? In der Regel kommen hier die bes-

ten Vorschläge.

4 Das Warum und Wozu klären.

Stellen und beantworten Sie sich selbst

ständig diese Fragen: Warum tue ich das

gerade? Welches Problem löse ich damit

und inwiefern wird meine Welt dadurch

besser?

5 Den Rahmen stecken.

Machen Sie sich selbst und dem Team

klar, was unveränderbare Rahmenbe-

dingungen sind! Das hilft, nicht sinnlos

gegen Windmühlen zu kämpfen und die

Energie auf strukturelle Probleme und

Lösungen zu fokussieren.

6 Schrittweise vorgehen.

Alles auf einmal geht nicht, priorisieren

Sie Veränderungen. Befreien Sie das

Team, das Projekt, das Unternehmen

zuerst von den schlimmsten Schmerzen.

Die Geschwindigkeit der Veränderungen

hängt vom Reifegrad des Teams und/

oder des Unternehmens ab.

7 Die Angst nehmen.

Oft haben die Teammitglieder Angst,

gewisse Grenzen zu überschreiten.

Machen Sie ihnen klar, in welcher Gesell-

schaft und Unternehmenskultur sie sich

befinden und worin die wirkliche Gefahr

besteht. In der Regel werden sie feststel-

len: Es gibt keine konkrete Bedrohung.

8 Das Team fordern.

Beschützen Sie Ihr Team, aber vergessen

Sie nicht, es zu fordern! Unsere Komfort-

zonen verlassen wir nur, wenn es sich für

uns lohnt.

9 Hilfe zur Selbsthilfe geben.

Ein guter Scrum Master arbeitet daran,

sich selbst überflüssig zu machen. Leh-

ren Sie das Team, sich selbst zu helfen,

auch wenn Sie anfangs viele Lösungen

vorschlagen.

10 Spaß haben.

Zeigen Sie, dass Veränderungen und Ler-

nen Spaß machen. Fehler gehören dazu.

Sorgen Sie für entspannte Zusammen-

künfte außerhalb der Arbeitszeit.

Im Übrigen gibt es keine Garantie dafür,

dass der Scrum Master helfen kann, alle

Probleme zu lösen. Aber eines kann er

mit Sicherheit: jedes Hindernis und seine

negative Auswirkung unmittelbar für das

Unternehmen sichtbar machen und somit

die beste Entscheidungsgrundlage für

oder gegen eine Veränderung schaffen.

Und manchmal ist das alles, was wir

brauchen.

Steffi Krause hat sich nach mehreren Jahren als Projektleiterin in IT-Unternehmen (Internet Communication, Infotainment) mit GOagile! selbstständig gemacht.

Seit Frühjahr 2004 beschäftigt sie sich mit der Einführung von Scrum bei national und international tätigen Unternehmen als Coach und Trainer. go-agile.de

Scrum (engl. für Gedränge) ist eine Managementmethode im Rahmen agiler

Software entwicklung. Der Begriff stammt aus dem Rugby.

Ein Scrum-Prozess gliedert sich in Iterationen, so genannte Sprints. Jeder Sprint

liefert ein Stück lauffähige Software. Sprints haben eine definierte Länge und wer-

den durch Planungssitzungen (Sprint Planning Meeting) vorbereitet und in Rück-

schausitzungen (Sprint Review Meeting und Retro spective Meeting) zur beständi-

gen Optimierung analysiert.

Scrum kennt genau drei Rollen: Team, Product Owner und Scrum Master. Die

Anforderungen werden in einer Product Backlog genannte Liste verwaltet.●● Der Product owner sortiert kontinuierlich den Product Backlog, d.h. er prio-

risiert die Anforderungen. ●● Im SPrint Planning meeting wählt das team aus dem Product Backlog

Anforderungen mit der höchsten Priorität aus und verpflichtet sich – nach einer

aktuellen Aufwandsschätzung – zu deren Umsetzung. ●● Der Scrum maSter erfragt in täglichen Teamsitzungen (daily Scrum) den

Fortschritt der Arbeit und eventuelle Hindernisse auf dem Weg zum Ziel. Seine

Aufgabe ist es, diese Hindernisse aus dem Weg zu räumen und steuernd und

fokussierend einzugreifen.

Mehr über Scrum schreibt Ken Schwaber, einer der Begründer, auf scrum.org bzw. controlchaos.com



AGIL: ROLLENSPIEL II

Nikolaus Reuter hatte exakt neun Monate

Zeit, die Etengo (Deutschland) AG, ein

junges Unternehmen im Bereich der spe-

zialisierten Personaldienstleistung, das

sich auf die Vermittlung freiberuflicher

IT-Experten fokussiert hat, auf die Beine

zu stellen. In diesem straffen Zeitplan

war auch die Entwicklung der unterneh-

menseigenen Software inbegriffen. Für

Etengo – wie auch für andere Personal-

dienstleister – ist Software ein entschei-

dender Wertschöpfungsfaktor, um den

Kunden möglichst schnell den perfekt

passenden IT-Spezialisten für einen Pro-

jekteinsatz vorstellen zu können. Nach

nunmehr eineinhalbjähriger Erfahrung

mit der Methode Scrum hat Reuter die

aus seiner Sicht entscheidenden Erfolgs-

kriterien zusammengetragen.

1 Uneingeschränkte Entscheidung für Scrum

Scrum entfaltet wirklich nur dann seine

volle Wirkungskraft, wenn man es kon-

sequent von A bis Z durchzieht und lebt.

Also immer in zeitlich fest definierten

Sprints arbeitet, in denen wiederum fest

definierte Anforderungen bzw. Funkti-

onalitäten zu liefern sind. Das Product-

Backlog (die To-Dos) gewissenhaft mit

ausreichend klein »portionierten« User

Stories (Arbeitspaketen) befüllt, die sich

idealerweise in einem Sprint bearbeiten

und fertigstellen lassen. Es ist immens

wichtig, dem Team die anstehenden Pro-

grammierherausforderungen im Sprint-

Planning verständlich zu kommunizieren

und die dahinter stehenden fachlichen

Aspekte und Anforderungen klar darzu-

legen. Der Product Owner muss immer

in einem sehr engen Dialog mit dem Ent-

wicklungsteam stehen. Auch während

der Sprints. Wer zwischendurch diesen

Weg verlässt, und zum Beispiel einen

geplanten Sprint über den Haufen wirft,

riskiert damit den Projekterfolg.

2 Der Product Owner ist die einzige Schnittstelle zum Team

Viele Software-Entwicklungsprojekte

kranken daran, dass zu viele Köche auf

Kundenseite mit spontanen Ideen, »das

brauchen wir auch noch ganz dringend«,

den Brei verderben. Bei Scrum ist der

Product Owner die einzige Schnittstelle

zwischen Auftraggeber und Entwickler-

Team. Er trägt die volle Verantwortung

gegenüber dem Auftraggeber und trifft

gleichzeitig alle wichtigen Entscheidun-

gen gemeinsam mit dem Team. Er legt zu

Beginn eines jeden Sprints das gemein-

same Ziel fest, stellt das Budget zur Ver-

fügung, vertritt die fachliche Sicht, stellt

die Anforderungen und beurteilt, ob die

Umsetzung den Wünschen entspricht,

sowohl was Funktionalität, Benutz-

barkeit, Performanz als auch Qualität

betrifft. Das sind viele Hüte, die diese

Person tragen muss. Der Erfolg des Pro-

duct Owners steht und fällt deshalb mit

dem bedingungslosen Rückhalt in seiner

eigenen Organisation.

3 User Stories statt Pflichtenheft

Statt in monatelanger Kleinarbeit ein

mehr oder minder verständliches, voll-

ständiges und (meist schon bei Projekt-

start nicht mehr) aktuelles Pflichtenheft

zu verfassen, werden vom Product Owner

so genannte User Stories geschrieben.

Eine User Story schildert einzelne Funkti-

onalitäten eines Programms aus Anwen-

dersicht mit so wenigen Abhängigkeiten

wie möglich. Ein Beispiel:

»Jeder Kontakt mit Unternehmen

und mit Freelancern soll entsprechend

dem Customer Relationship Gedanken

genau dokumentiert werden: Wann

hat ein direkter Kontakt stattgefunden,

mit wem, wie lautete das Thema, was

war das Ergebnis« ist z.B. eine zentrale

eigenständige Komponente des Etengo-

Systems. Solche Merkmale und Beson-

derheiten sind in den einzelnen User

Stories formuliert. Daraus entsteht dann

wiederum das so genannte Product Back-

log, das letztlich alle Funktionalitäten

des zu entwickelnden Produkts enthält.

Eine User Story ist aber ihrer Natur nach

längst nicht so detailliert wie ein traditi-

onelles Pflichtenheft. Viele Punkte sind

meist noch offen oder nur grob skizziert,

daher kommt es öfter zu Rückfragen sei-

tens des Entwickler-Teams. Dies erfor-

dert natürlich einen höheren Einsatz des

Product Owners. Das böse Erwachen am

Ende eines »Pflichtenheft-Projekts« ist

dadurch allerdings ausgeschlossen.

4 Testen, testen, testen

Scrum ist durch seine kurzen Entwick-

lungszyklen sehr schnell getaktet, so

dass der Product Owner immer nah am

Entwicklungsprozess dran bleiben muss:

Nach Ablauf eines Sprints erhielt Etengo

jedes Mal eine lauffähige Software zum

Testen. Dann muss aber auch das Team

möglichst schnell mit Feedback versorgt

werden, um im nächsten Sprint eventuel-

le Bugs oder neue bzw. geänderte Anfor-

derungen schnell umsetzen zu können.

Nach dem Sprint ist also immer vor dem

Sprint. Und: die Software wird von Sprint

zu Sprint umfangreicher und das Testen

dadurch immer aufwendiger. Der große

Vorteile dieses Vorgehens: Beim finalen

Test werden in aller Regel weniger Bugs

und Unzulänglichkeiten auftreten, da

alle Teil-Entwicklungen ja bereits perma-

nent an den Sprint-Enden getestet wur-

den. Und: Es gibt auch hier kein böses

Erwachen nach dem Motto, das funkti-

oniert ja alles gar nicht, aber wir haben

jetzt keine Zeit mehr, alles umzubauen.

Das ständige Testen ist zeitraubend aber

entscheidend für den Erfolg von Scrum.

5 Den Business Value als einzige Priorisierung nutzen

Wichtig bei Scrum ist die geschäftsrele-

vante Priorisierung: Die einzelnen User

Stories bewertet der Product Owner nach

ihrem Business Value auf einer Skala

von 1-10. Darüber hinaus definiert er

» Der Product Owner kann sich nicht zurückziehen.«

Sechs Regeln für den Product Owner eines erfolgreichen Scrum-Projekts von Nikolaus Reuter, Etengo Deutschland



die Penalties, so etwa ein Log-in auf dem

Web-Frontend, dessen Business Value

recht hoch ist und gleichzeitig einen

Penalty-Wert von 10 hat, denn wenn ein

Freelancer sein Profil nicht schnell und

einfach bei Etengo online anlegen kann ist

das eine große Hürde bzw. deutlich mehr

interner Aufwand. Die Sprint-Inhalte

müssen demzufolge immer der Priorität

nach gefüllt werden und nicht etwa nach

der Macht des »Auftraggebers«.

6 Das Projekt mit Lernprozessen und Feedback steuern

Alle zwei Wochen eine lauffähige Soft-

ware zu erhalten hat auch einen Haken:

Man muss auch alle zwei Wochen Feed-

back dazu geben. Der Product Owner

kann sich nicht zurückziehen. Wird Zeit

verschwendet, weil unnütze Programm-

Features erstellt werden, so hat das der

Product Owner zu verantworten. Durch

die eng getaktete Rückkopplung werden

die Vorstellungen des Product Owner

schnell und regelmäßig mit der Umset-

zung durch das Team konfrontiert. Das

verhindert Fehlentwicklungen.

Fazit: Die drei wichtigsten Vorteile von

Scrum liegen 1. in seiner Transparenz,

2. seiner Flexibilität und 3. der durch

den Product Owner kanalisierten Ver-

antwortung.

Nikolaus Reuter ist Vorstandsvorsitzender der Etengo (Deutschland) AG. Die Etengo-Software wurde in einer Rekord-zeit von nur neun Mona ten mit der Management-Methode Scrum ent wickelt und Reuter dadurch quasi über Nacht in einem herausfordernden Scrum-Entwicklungs-projekt zum Product Owner. etengo.de

Vorgestern sagte man noch: IT nutzt

Infra struktur. Gestern korrigierte man:

IT ist Teil der Infrastruktur. Heute

begreift man: IT ist die Infrastruktur

der Infrastruktur. Und diese Infra-

struktur wird immer vernetzter, immer

dynamischer, immer komplexer. Mor-

gen wird man sagen: IT ist Komplexi-

tätsmanagement. Entscheidend ist: Die

Komplexität der Aufgaben wird immer

größer – wir müssen unsere Werkzeuge

anpassen. Zwei Trends sind für die aktu-

elle IT-Wirtschaft bestimmend:

Trend 1 Multicore: Parallele Prozesse in

eine sequentielle Software-Struktur zu

pressen, war schon immer ein Mittelding

zwischen Verbrechen und Strafarbeit

und letzten Endes eine Kapitulation vor

der Komplexität. In der Softwareentwick-

lung aber ist es inzwischen möglich, par-

allele Prozesse auch als solche zu behan-

deln, mit Multicore-Prozessoren, die

mehrere CPUs auf einem Chip integrie-

ren. Die Programmierung von Pa rallel-

verarbeitung bezeichnet Prof. Tichy am

IPD des KIT als Paradigmenwechsel.

An seinem Institut hat Markus Hossner

eine Diplomarbeit zur Transportplanung

bei SAP erstellt, die Ende 2009 mit dem

ObjektForum-Förderpreis ausgezeichnet

wurde (Seite 22). Dabei hat er komplexe

Tourenplanungs-Prozesse auf 24 CPUs

parallelisiert und damit um den Faktor

23 beschleunigt. Das bedeutet: Statt ein-

mal pro Tag eine Anpassung der Touren-

planung an aktuelle Ereignisse ist nun 23

Mal pro Tag möglich – und damit deut-

lich näher an der dynamischen Realität.

Die Beschleunigung veranschaulicht

die Zielrichtung für die Industrie: da die

Leistungssteigerungen der Zukunft nicht

mehr über Taktraten, sondern über Par-

allelität erreicht werden, muss die Soft-

wareindustrie diese Herausforderung

annehmen und den Umgang mit den par-

allelen Prozessoren lernen.

Trend 2 Agilität: Bei der (für uns in

Karls ruhe zentralen Individualentwick-

lung) haben Software-Ingenieure immer

mehr Management-Aufgaben. Daher ist

das wirklich Revolutionäre an den agilen

Prozessen im Allgemeinen und Scrum

im Besonderen, dass der Kunde in den

Prozess der Softwareentstehung einge-

bunden wird. Scrum ist ein effizientes

Management-Werkzeug für Software-

Ingenieure, die komplexe Projekte steu-

ern. Bekanntlich ist es ein Merkmal solch

komplexer Entwicklungsaufgaben, dass

man den Kunden nicht einfach fragen

kann. Woher sollte er die Antwort wis-

sen? Noch dazu – das wissen wir alle aus

Erfahrung – verändern sich die Antwor-

ten im Laufe des Entwicklungsprozes-

ses. Scrum bietet die Managementum-

gebung, die eine effiziente gemeinsame

Lernkurve von Entwickler und Kunden

ermöglicht.

Karlsruhe hat bei agilen Prozessen die

Nase weit vorn. Nicht zuletzt einige Bei-

träge in diesem Heft weisen das nach.

Und das ist auch gut so. Für die Unter-

nehmen im IT-Bereich werden die Anfor-

derungen nicht geringer, doch bei der

permanenten Veränderung bleibt das

Erfolgsrezept immer das Gleiche: Trends

vorwegnehmen, nicht zu teuer sein.

Wer den Trends nicht folgt, fällt zurück.

Wer die Trends jedoch prägt, gestaltet

Zukunft. Und der beste Weg, die Zukunft

vorherzusagen, ist sie zu gestalten! Emb-

race Concurrency!

Hagen Buchwald ist Vorstandsvorsitzender des CyberForum. Er war von 2002 – 2008 Vor-standsmitglied der entory AG (heute Cirquent

GmbH). Sein Schwer-punktthema Business Process Management in Wertschöpfungsnetz-werken vertieft er zur-zeit als wissenschaftli-cher Mitarbeiter am Karlsruher Institut für Technologie (KIT). cyberforum.de

CyberTrends Kolumne von Hagen Buchwald, Vorstandsvorsitzender des CyberForums



AGIL: EINWURF*

Lizenzieren und Schützen eines Softwareprodukts innerhalb eines Sprints Von OIiver Winzenried, WIBU-SYSTEMS AG

* Einwurf: ein Spieler wirft den Ball in das Gedränge oder die Gasse ein.

Lizenzgeber Lizenznehmer

Ges

chüt

zte

Soft

war

e

Ges

chüt

zte

Soft

war

e

Ung

esch

ützt

e So

ftw

are

Software

Lizenz

CD/Download

Das Entwickeln von Software kostet viel Zeit und Geld. Umso

ärgerlicher ist es, wenn die Software unberechtigt vervielfäl-

tigt wird. Durch diese Raubkopien entsteht dem Softwareher-

steller ein erheblicher wirtschaftlicher Schaden. Noch drama-

tischer ist der Schaden, wenn Know-how aus der Software, z.B.

mathematische Algorithmen, vom Mitbewerber extrahiert

und in eigenen Produkten verwendet wird. Durch modulare

Softwarelizenzierung profitiert der Softwarehersteller drei-

fach: nicht nur vergrößert er seinen Kundenkreis, er schützt

sein Produkt auch vor Raubkopien und sichert sein Know-how.

Vorbereitung und Ziele

Vor Beginn werden die grundsätzlichen Fragen beantwortet:

Welche Lizenzmodelle sollen den Kunden angeboten werden,

z.B. Einzelplatzlizenzen, Namenslizenzen, Netzwerklizenzen,

Modulare Lizenzen, zeitlich limitierte Lizenzen (Mietlizenzen),

Pay-Per-Use Lizenzen, Downgrade Lizenzen, Hot- und Cold

Standby Lizenzen, Overflow Lizenzen, Volumenlizenzen oder

andere. Weiterhin muss klar sein, wie die Lizenzen ausgeliefert

werden und wie die Auslieferung in die bestehenden Vertriebs-

prozesse integriert wird.

Heutige Schutz- und Lizenzierungssysteme bieten sowohl

Lizenzspeicherung in spezieller Hardware, z.B. USB-Dong-

les, als auch in Lizenzdateien, die durch Aktivierung an einen

bestimmten PC gebunden werden.

Zwei Aufgaben für einen Sprint

Der Sprint hat zwei Ziele: Die Integration des Schutzes in die

Software inklusive Test der einzelnen Module sowie die Inte-

gration in die Back-Office Prozesse. In großen Organisatio-

nen kann diese Aufgabe auch auf zwei Sprint-Teams verteilt



werden, da stark unterschiedliche Kompetenzen benötigt wer-

den, einerseits den Schutz in der eigenen Software zu imple-

mentieren und andererseits die Integration in Vertriebsprozes-

se, beispielsweise Integration in ein ERP-System wie SAP, zu

realisieren.

Der Product Owner kennt die Lizenzierungs- und Schutz-

strategie des Unternehmens sowie die Anforderungen an die

Verteilung der Lizenzen und die Integration in Vertriebsprozes-

se. Er legt das gemeinsame Ziel für die Implementierung beider

Aufgaben im Rahmen des Sprints fest. Das Team schätzt die

Aufwände vor Beginn des Sprints ab und entscheidet mit dem

Product Owner, einzelne Anforderungen bereits vor Beginn des

Sprints in das Product Backlog zu nehmen.

Innerhalb von rund zwei Wochen erfolgt die Implementie-

rung: Integration des AxProtector in den Build-Prozess, um die

komplette Anwendung sowie die individuell lizenzierten Modu-

le gemäß Definition zu verschlüsseln. Die individuell geschütz-

ten Module werden gemäß Anforderungen definiert und die

Benutzerführung sowie die Entschlüsselung vor Aufruf in den

Quellcode der Anwendung implementiert. Dies ist für norma-

le Win32/64-Anwendungen genauso möglich wie für Java-,

.NET-, MacOS- oder Linux-Anwendungen.

Innerhalb einer weiteren Woche wird die Lizenzauslie-

ferung in die Vertriebsprozesse integriert. Dabei übernimmt

eine datenbankbasierte Anwendung alle lizenzspezifischen

Aufgaben. Sie erhält Aufträge manuell über ein Webinterface

oder automatisch über eine SOAP-Schnittstelle aus einem ERP-

System. Eine Administrationsschnittstelle dient zum Einpfle-

gen neuer Produkte und liefert Supportinformationen. Das

Depotinterface ermöglicht dem Anwender das manuelle Abho-

len der Lizenz oder das automatisierte Übertragen auf Anforde-

rung der geschützten Anwendung.

Innerhalb dieses Sprints werden außerdem die ersten Produk-

te eingepflegt sowie die Schnittstelle zum Vertrieb realisiert,

entweder nur durch einfache Gestaltung der Weboberfläche

im Intranet oder Programmierung eines Connectors, um diese

Datenbank an das ERP-System anzubinden. Weiterhin wird

die Lizenzabholung in die geschützte Anwendung integriert

und die Installationsprogramme werden so erweitert, dass die

Softwarekomponenten des Schutzsystems mit ausgeliefert und

installiert werden.

Review

Im Rahmen des Reviews wird geprüft, inwieweit alle Anfor-

derungen erfolgreich umgesetzt sind und die Testergebnisse

analysiert. Erweiterungen und neue Kundenanforderungen

werden in den Product Backlog aufgenommen. Innerhalb von

maximal vier Wochen sollte eine erste Umsetzung erledigt sein.

Oliver Winzenried ist Mitbegründer und Vor-stand der WIBU-SYSTEMS AG in Deutschland. Er ist aktiv in Standardisierungsgremien wie USB, PCMCIA und SDA sowie Verbänden wie BITKOM

oder VDMA und lokalen Vereinen. Das Unterneh-men hat sich auf die Bereiche Digital-Rights-Management, Softwareschutz, Lizenzmanage-ment, Dokumentenschutz und Zugangsschutz spezialisiert. wibu.de



AGIL: KOMBINATIONSSPIEL

Unsere Disziplin ist schnelllebig. Das ist kein Wunder: Software Engineering ist

eine lebendige Wissenschaft, die vor ständig neuen Herausforderungen steht und

sich selbst ständig neue Herausforderungen definiert. Und auf dem Software-Markt

wird viel Geld verdient. Jeder Marktplatz hat auch seine Marktschreier.

Industrialisierung des Software-Engineering – Architektur und Agilität Von Matthias Grund, andrena objects ag und Ralf Reussner, KIT

Aber: Jenseits von schnelllebigen

Stichworten und Hypes lässt sich in

den 50 Jahren Software Engineering ein

Generaltrend erkennen, und der heißt

Industrialisierung. Wir erkennen dabei

zwei zentrale Beiträge:

1. Die Wiederverwendung von Software

auf verschiedenen Ebenen (Standardi-

sierung von Produkten, Standardisie-

rung von Basis-Technologie, Produkt-

linien, Frameworks, Komponenten).

Die Mehrzahl von Softwaresystemen

wird heute nicht mehr individuell ent-

wickelt. Der geplante Einsatz bereits

existierender Komponenten verlangt

Modellierung und Architektur-Ver-

ständnis.

2. Die Herausbildung eines Software-

Entwicklungsprozesses, der dem Cha-

rakter eines industriellen Entwick-

lungsprozesses gerecht wird bezüglich

Messbarkeit und Steuerbarkeit. Agile

Ansätze (wie Scrum und extreme

Programming, auf die wir uns im

Folgenden beziehen) bringen die drin-

gend notwendige Flexibilität. Dabei

wird keine Beliebigkeit zugelassen,

sondern auf den wirtschaftlichen Wert

fokussiert.

Architektur und Agilität: feindliche

Brüder?

Agilität und Architektur scheinen

zunächst zwei widerstreitende Modelle

der Industrialisierung von Software-

Engineering zu repräsentieren.

Agile Entwicklung ist Code-zentriert –

Architektur ist Modell-zentriert.

Agile Entwicklung lässt Entwurfsent-

scheidungen so lange wie möglich offen

– Architekten bestehen auf früh zu fixie-

renden Architekturen.

Agile Rollenmodelle kennen das Team

als zentralen Verantwortungsträger für

alle Entwurfsentscheidungen. Architek-

ten bestehen auf der Funktion »Archi-

tekt« als besonderen Know-how-Träger.

Das schlägt sich auf der persönli-

chen Ebene in Form von Vorurteilen

nieder: Architektur-Dokumente unter-

liegen aus agiler Sicht dem Verdacht,

»Waste » zu sein. Architekten gar gelten

als »Chicken«. Die Wahrnehmung aus

umgekehrter Sicht ist in der Regel nicht

weniger unfreundlich. »Extreme Pro-

grammer« gelten als Hacker, die sich

plan- und kopflos ins Projekt stürzen.

Agile Prozesse: Getrieben von volatilen

Geschäftsinteressen, getragen von

Testautomatisierung

Agile Entwicklungsprozesse haben

einen zentralen Grundsatz: Die Ent-

wicklungsrichtung meines Projektes ist

getrieben vom Geschäftswert, den die

nächste Iteration bringt. Die Erkenntnis,

welcher Geschäftswert mit dem neuen

System erreicht werden kann, wird sich

im Projektverlauf des Öfteren ändern:

Märkte und Kundenbedürfnisse ändern

sich, neue Technologie eröffnet neue

Möglichkeiten, das Projekt selbst beför-

dert neue Erkenntnisse, ...

Das verlangt vom in Entwicklung

befindlichen System ein hohes Maß an

Veränderbarkeit. Diese Veränderbarkeit

wird z. B. durch die diversen Prinzipien

des extreme Programming erreicht.

Die Grundvoraussetzung ist Testauto-

matisierung auf verschiedenen Ebenen

(Unit-Tests, Akzeptanztests, Integrati-

onstest).

Ohne Testautomatisierung keine

Refaktorisierbarkeit. Ohne Refaktori-

sierbarkeit keine anpassbaren Systeme.

Ohne anpassbare Systeme keine Agilität.

Architektur: Basis für

Wiederverwendung

Architekturmodellierung ist kein

Selbstzweck. Sie unterstützt in Unter-

nehmen konkrete Ziele. Beispielhaft sind

zu nennen: frühzeitige Bewertung von

Entwurfsentscheidungen, systematische

Umsetzung von Qualitätsanforderungen,

Sicherung der nachhaltigen Wartbarkeit,

Prägung eines Kommunikationsvoka-

bulars nach innen und außen, geplante

Wiederverwendung durch Produktlinien

oder modellgetriebene Softwareentwick-

lung, Identifikation sanfter Migrations-

stragegien zu Zielarchitekturen, Kosten-

schätzung, Teamorganisation, um nur

einige zu nennen.

Es wird klar, dass bei einer sol-

chen Vielfalt von Aufgaben zum einen

nicht nur eine einzige Architektur-

beschreibungssprache all diese Auf-

gaben gleichmäßig unterstützen kann,

zum anderen wird klar, dass Kästchen-

und-Linien-Diagramme (am besten im

Powerpoint-Format) für die meisten

dieser Aufgaben ungeeignet sind. Statt-

dessen besitzen moderne Architekturbe-

schreibungsansätze klar definierte Meta-

modelle und eine Reihe von Sichten.

Beides ist in der Regel zielorientiert zur

Unterstützung der o.a. Ziele entworfen.

»Chicken und Hacker…«



So ist z.B. das am KIT und FZI entwi-

ckelte Palladio-KomPonenten-meta-

modell (PCM) bewusst entworfen, um

Analysen von Qualitätseigenschaften wie

Performanz, Skalierbarkeit, Ressourcen-

dimensionierung, Zuverlässigkeit, Ver-

fügbarkeit und Wartbarkeit möglichst

automatisiert durchzuführen.

Bei all dieser Vielfalt von Aufgaben

von Architekturen so zeigt sich, dass die

Essenz der Architekturmodellierung

darin liegt, Entwurfsentscheidungen zu

dokumentieren, die frühzeitig im Projekt

getroffen werden müssen. Dazu gehören

die Frage nach zu unterstützenden Evo-

lutionsszenarien, nach zu erstellenden

wiederverwendbaren Komponenten und,

umgekehrt wiederzuverwendenden exis-

tierenden Software-Komponenten, was

auch Frameworks einschließt, welche oft

selbst schon eine Architektur der Anwen-

dung induzieren. Weiterhin muss die

grundlegende Strukturierung festgelegt

werden, z.B. durch Muster und Stile. Es

muss entschieden werden, wie bestimm-

te Qualitätsanforderungen an Ausfall-

sicherhheit, Performanz, Sicherheit etc

berücksichtigt werden. Im Gegensatz

zur Architekturanalogie im Bau-Ingeni-

eurwesen hat aber der Software-Entwurf

die Besonderheit, dass so gut wie jede

Architektur-Entscheidung offengelassen

werden kann, um erst beim

Deployment oder zur Lauf-

zeit entschieden zu werden.

Dies gilt für jede einzelne

Entscheidung, allerdings ist klar, dass

nicht alle Entwurfsentscheidungen im

gleichen Entwurf »nach hinten« verla-

gert werden können.

Es bleibt also die Entscheidung,

welche Entscheidung treffe ich

zur Entwurfszeit, welche lasse ich

bewusst offen, um sie in Form einer

Konfigurationsmöglichkeit später zu

treffen. Insofern muss also doch jede

Entscheidung, auch die bewusst offen-

gelassenen, in der Architektur doku-

mentiert werden. Dabei ist klar, dass

das Offenlassen von Entscheidungen

auch die Qualitätseigenschaften und

die Kosten bei Entwicklung und Betrieb

beeinflussen wird. Klassischerweise hat

sich gezeigt, dass mindestens drei Sich-

ten notwendig sind, um die »üblichen«

Arten von Architektur-Entwurfsent-

scheidungen in der Architektur zu doku-

mentieren. Dies ist eine strukturelle Sicht

(die klassischen Kästchen-und-Linien,

allerdings mit einer klaren Semantik,

jenseits von Graphik-Symbolen), eine

Verhaltensbeschreibung (wie der Kont-

roll- und Datenfluss innerhalb und zwi-

schen den Komponenten verläuft) und

eine Deployment-Sicht (wie sind die

Komponenten auf Ressourcen abgebildet

(wie Server, Rechner, Virtuelle Maschi-

nen, Netzwerkverbindunge, etc).

Mit diesen Informationen über Archi-

tekturmodellierung wird klar, dass zum

einen Architekturentwurf Aufwand ver-

ursacht, u.U. in einer Höhe, der sich erst

nach mehreren Projekten durch Wieder-

verwendung amortisiert; dies macht die

Industrialisierung des Software-Engineering – Architektur und Agilität Von Matthias Grund, andrena objects ag und Ralf Reussner, KIT

Das Palladio Component Model Tool wird am KIT und FZI zur Analyse vonSoftware-Architekturen eingesetzt.

»Chicken und Hacker…« »…die klassischen Kästchen und Linien«



AGIL: KOMBINATIONSSPIEL

Integration in agile Prozesse zur Heraus-

forderung. Auf der anderen Seite bieten

frühzeitige Bewertungen der System-

Qualität auf Basis der Architektur eine

Agilität im Ausprobieren verschiedener

System-Entwürfe, welche beim jewei-

ligen Ausimplementieren und Testen

deutlich teurer und schwergewichtiger

wäre. Es gibt also auch gute Gründe für

den Versuch einer Integration.

Architektur im agilen Kontext

Die Fragen »Brauchen wir Architektur?

Wenn ja, wann und wieviel davon?«

haben die agile Community längst

erreicht.

Der Begriff der »Iteration Zero«

wurde geprägt, um zu verdeutlichen,

dass jedes Projekt vor dem Beginn des

iterativ-inkre mentellen Entwicklungs-

prozesses Vorbereitung braucht. In der

»Iteration Zero« sollten die Dinge fixiert

werden, die im weiteren Verlauf eines

Projektes tunlichst stabil gehalten wer-

den sollten. Dazu gehört auch so etwas

wie eine »Architektur«.

Nach Ansicht der Autoren reicht der

Verweis auf die Iteration Zero allerdings

nicht aus.

Architekturentscheidungen haben

Implikationen, die über das Projekt hin-

ausgehen und den natürlichen Scope

des Entwicklungs-Teams überschreiten.

Scrum z.B. kennt die Rollen »Team« und

»Product Owner«. Wer aber vertritt wo

und wann die Stakes einer Enterprise

Architektur?

Architektur und Agilität:

Sowohl die Architektur-Community als

auch die Agile Community haben ausge-

reifte Konzepte und ein industrieerprob-

tes Vorgehen.

Es gilt nun, aufeinander zuzugehen.

Dabei macht es keinen Sinn, Buzzword

Mixins zu entwickeln, sondern Differen-

zen herauszuarbeiten und von den Erfah-

rungen des Gegenüber zu lernen.

Wir sehen die folgenden Herausforde-

rungen und Fragen – an Industrie und

akademische Forschung:

●● Wie können Architektur-Überlegun-

gen und Modellierung im agilen Pro-

zess eine dem jeweiligen Kontext ange-

messene Berücksichtigung finden?●● Wer vertritt wann und wie die Stakes

einer Enterprise Architektur im agilen

Prozess? ●● Wenn Geschäftswert der zentrale Trei-

ber ist, wer bewertet den Geschäfts-

wert von Architektur?●● Wann muss welche Architekturent-

scheidung getroffen werden? oder:

Wie lange darf sie offen bleiben? oder:

Wie bewusst ist die Entscheidung, eine

Entscheidung zu verschieben?●● Lässt sich Architekturmodellierung

mit den zentralen Konzepten »Test-

automatisierung« und »Refaktori-

sierung« zusammenbringen? oder:

Wie können wir die Adaptibilität und

Agilität von Architekturen erhöhen?●● Wie ist die Beziehung zwischen dem

»Testmodell« beim testgetriebenen

Entwickeln und dem »Modell« beim

modellgetriebenen Entwickeln?●● Welche Unterstützung können wir von

domänenspezifischen Sprachen erhal-

ten?

Eine systematische Nutzung von Archi-

tekturen hätte in agilen Projekten ein

hohes Potential: die projektübergreifen-

de Wiederverwendung von Komponen-

ten, Produktlinien, Entwürfen und Gene-

ratoren wäre in der Tat ein wichtiger

Beitrag zur Software-Industrialisierung.

Matthias Grund ist Vorstand der andrena objects ag. Er ist seit 1986 als Berater und Pro-jektmanager international aktiv. 1995 gründete er ge meinsam mit Dieter Kuhn andrena objects in Karls ruhe, um hochwertige Dienstleistungen in objekt-orientiertem Software-Engineering anzubieten. andrena objects hat 2003 Scrum nach Deutschland gebracht. andrena.de Prof. Dr. Ralf Reussner, Vorstand des VKSI, ist Leiter des Lehrstuhls Software-Entwurf und -Qualität am Institut für Programmstrukturen und Datenorganisation (IPD) der Fakultät für Infor-matik des Karlsruher Instituts für Technologie (KIT) und Direktor im For-schungsbereich Soft-wareentwicklung des Forschungszentrums Infor-matik (FZI) in Karlsruhe. sdq.ipd.kit.edu

»Aufeinander zugehen«

… sucht Könner mit Charakter!

Das Internet der Zukunft …

United Internet AGPersonalabteilungZentrales Bewerbermanagement c/o 1&1 Internet AGBrauerstraße 4876135 Karlsruhe

Die United Internet AG ist ein börsennotierter und international tätiger Internet Service Provider (ISP). Über die Marken 1&1, GMX und WEB.DE werden InternetLösungen an anspruchsvolle Privat und Firmenkunden vertrieben.

Mit rund 9 Mio. Kundenverträgen, über 1,6 Mrd. Euro Jahresumsatz und rund 4.600 Mitarbeitern ist United Internet eines der führenden InternetUnternehmen weltweit.

Für die 1&1 Internet AG mit Dienstsitz in Karlsruhe suchen wir ab sofort eine/n:

Systemadministrator (m/w) Kennziffer: KA-AT091102 Sie verstärken unser Team bei der Administration unserer rund 1.600 LinuxServer, die täglich mehr als 20 Terabyte Daten ins Internet schicken.

Aufgaben

Sie sind für die Pflege und Überwachung der Systeme in unseren Hochleistungs-Rechenzentren zuständig. Außerdem tragen Sie zur Weiterentwicklung unseres hochautomatisierten Systemmanagement-Konzeptes und unserer Server-Cluster bei und sind ein kompetenter Ansprechpartner für andere Abteilungen.

Anforderungen

In dieser Position erwarten wir mehrjährige Berufserfahrung im Linux-Umfeld (OS und Internet-Dienste), die Sie sich neben theoretischem Know-how auch durch praktische Tätigkeiten angeeignet haben. Sie verfügen über Programmier-erfahrung in den Script-Sprachen Bash, Perl und Python. Sie sind mit den Instal-lations- und Paketmanagement-Systemen der wichtigsten Linux-Distributionen vertraut.

Darüber hinaus erwarten wir fundierte Kenntnisse über TCP/IP und die gängigen Internetprotokolle, die Konfiguration von Web-, Mail-, DNS-, und Datenbank-Ser-vern und deren Anwendungen (Apache, Tomcat, QMail, bind, Oracle und MySQL). Erfahrungen in den Bereichen Storage (FC, SCSI, SAS, SATA, SAN), Load-Balancer-Systeme (LVS) sowie sichere Englischkenntnisse im technischen Umfeld runden Ihr Profil ab.

Interessiert? Wir freuen uns auf Ihre aussagefähige Bewerbung Detailinformationen finden Sie http://jobs.united-internet.de Ihre Ansprechpartnerin: Frau Nadine Vogler, Telefon 0721-91374-6894, E-Mail: [email protected]

Product Backlog: Priorisierte Produkt-Features des Kunden

Sprint Goal: dem Sprint zugewiesene Features

Der Scrum-Prozess

Sprint Backlog: dem Team zugeordnete Aufgaben

2-4-Wochen- Sprint

Neue Funktionalität am Ende des Sprints

Dai lySc rum



1/1 Anzeige

… sucht Könner mit Charakter!

Das Internet der Zukunft …

United Internet AGPersonalabteilungZentrales Bewerbermanagement c/o 1&1 Internet AGBrauerstraße 4876135 Karlsruhe

Die United Internet AG ist ein börsennotierter und international tätiger Internet Service Provider (ISP). Über die Marken 1&1, GMX und WEB.DE werden InternetLösungen an anspruchsvolle Privat und Firmenkunden vertrieben.

Mit rund 9 Mio. Kundenverträgen, über 1,6 Mrd. Euro Jahresumsatz und rund 4.600 Mitarbeitern ist United Internet eines der führenden InternetUnternehmen weltweit.

Für die 1&1 Internet AG mit Dienstsitz in Karlsruhe suchen wir ab sofort eine/n:

Systemadministrator (m/w) Kennziffer: KA-AT091102 Sie verstärken unser Team bei der Administration unserer rund 1.600 LinuxServer, die täglich mehr als 20 Terabyte Daten ins Internet schicken.

Aufgaben

Sie sind für die Pflege und Überwachung der Systeme in unseren Hochleistungs-Rechenzentren zuständig. Außerdem tragen Sie zur Weiterentwicklung unseres hochautomatisierten Systemmanagement-Konzeptes und unserer Server-Cluster bei und sind ein kompetenter Ansprechpartner für andere Abteilungen.

Anforderungen

In dieser Position erwarten wir mehrjährige Berufserfahrung im Linux-Umfeld (OS und Internet-Dienste), die Sie sich neben theoretischem Know-how auch durch praktische Tätigkeiten angeeignet haben. Sie verfügen über Programmier-erfahrung in den Script-Sprachen Bash, Perl und Python. Sie sind mit den Instal-lations- und Paketmanagement-Systemen der wichtigsten Linux-Distributionen vertraut.

Darüber hinaus erwarten wir fundierte Kenntnisse über TCP/IP und die gängigen Internetprotokolle, die Konfiguration von Web-, Mail-, DNS-, und Datenbank-Ser-vern und deren Anwendungen (Apache, Tomcat, QMail, bind, Oracle und MySQL). Erfahrungen in den Bereichen Storage (FC, SCSI, SAS, SATA, SAN), Load-Balancer-Systeme (LVS) sowie sichere Englischkenntnisse im technischen Umfeld runden Ihr Profil ab.

Interessiert? Wir freuen uns auf Ihre aussagefähige Bewerbung Detailinformationen finden Sie http://jobs.united-internet.de Ihre Ansprechpartnerin: Frau Nadine Vogler, Telefon 0721-91374-6894, E-Mail: [email protected]


AGIL: AUSWECHSELSPIELER?

Agile Methoden aus Sicht der Arbeitssoziologie

Interview mit Dr. Andreas Boes, ISF München

VKSI: Warum interessiert sich ein Soziologe für die agilen

Methoden der Softwareentwicklung?

Andreas Boes: Als Soziologe befasse ich mich seit 20 Jahren mit der

IT Industrie und vor allem mit dem Wandel der Arbeit in dieser

Branche. In unserem Team beim ISF München untersuchen

wir unter anderem, wie sich die Arbeit von hochqualifizierten

Entwicklern und Ingenieuren verändert.

Wir vermuten tatsächlich, dass wir gegenwärtig einen tief

greifenden Umbruch in diesen Tätigkeitsfeldern erleben, der

äußerlich vor allem als eine neue Phase der Globalisierung

erlebt wird, im Inneren aber auf einen neuen Typ der Industria-

lisierung hinauslaufen könnte.

VKSI: Bisher geht man aber doch davon aus, dass agile Methoden

die Zusammenarbeit in selbstorganisierten Teams gestalten,

aber gerade mit Industrialisierung nichts zu tun haben.

Andreas Boes: Zunächst klingt es auch wie ein unvereinbarer

Widerspruch: auf der einen Seite die Industrialisierung mit

ihrer hochgradigen Arbeitsteilung, minutiösen und vollstän-

dige Planung, sowie bürokratischen Entmündigung; auf der

anderen Seite selbstorganisierte und autonome Teams, inkre-

mentelle und pragmatische Planungsverfahren sowie ganzheit-

liche Tätigkeitszuschnitte.

In diesem Zusammenhang ist es interessant, dass die großen

Unternehmen bei der Umorganisation ihrer Softwareentwick-

lung nicht von agil, XP oder Scrum sprechen, sondern von lean.

Wir erinnern uns: die Verfechter des Toyota-Konzepts haben es

als Abkehr von der Massenproduktion angepriesen. Tatsächlich

aber war das keine Abkehr sondern vielmehr eine neue Form

der Industrialisierung.

In Interviews im Rahmen unserer Forschungsprojekte sind

wir jedoch immer wieder erfahrenen Softwareentwicklern

begegnet, die dieser Melange aus »agil« und »lean« skeptisch

begegnen. Ein zentraler Aspekt dabei ist die Ersetzbarkeit:

Durch die Entwertung des Wissens wird der Experte entwertet.

Und Ersetzbarkeit, das haben wir gelernt, ist gerade im Zusam-

menhang mit der Globalisierung und Auslagerung von Arbeit

ein zentraler Faktor

VKSI: Das heißt, Kritiker befürchten, dass die agilen Methoden

für die Unternehmen bessere Möglichkeiten bieten, die Krea-

tivität zu nutzen, aber sich dennoch vom einzelnen Entwickler

unabhängig zu machen?

Andreas Boes: So könnte man es beschreiben. Übertrage ich die

kreative Leistung auf ein Team, so kann zwar durchaus auch

dort ein einzelner genialer Entwickler einen ebenso genialen

Code schreiben. Doch in der Regel ist der dort normal begabte

kreative Entwickler austauschbar.

Dies geht einher mit einer grundlegenden Umkehr in der

Organisation der Softwareentwicklung: Nicht die individuel-

le Kreativität des einzelnen Entwicklers fungiert nunmehr als

Erfolgsrezept der Unternehmen, sondern die Entwicklung

robuster und stabiler Prozesse, in denen sich das Know-how

und die Leistungsfähigkeit der Organisation materialisieren.

Intelligente Standards schalten die geistigen Potenziale der

Beschäftigten eben nicht aus, sondern ermöglichen eine effizi-

ente und systematische Nutzung der geistigen Produktivkraft in

neuer Qualität.

Auf der einen Seite bleiben zwar Nischen für innovative

Tätigkeiten erhalten beziehungsweise entstehen neue, auf der

anderen Seite wird jedoch für einen wachsenden Bereich von

Tätigkeiten eine konsequente Prozessorientierung angestrebt.

VKSI: Überwiegen in großen Unternehmen also die Risiken für

Software-Entwickler?

Andreas Boes: Nicht unbedingt, denn in erster Linie haben agile

Methoden unbestritten große Vorteile: Sie verbinden eine kon-

sequente Kundenorientierung mit Effizienz und menschenge-

rechter Arbeit und reduzieren so die teilweise enormen Arbeits-

belastungen und die Gesundheitsrisiken in der Branche. Agile

Methoden sind ein lebendiger Gegenentwurf zur bürokrati-

schen Organisation der Softwareentwicklung.

Doch ich plädiere dafür, aufmerksam die Konsequenzen im

Blick zu behalten. Immer mehr große Unternehmen verlassen

sich bei kritischen Projekten auf agile Methoden. Und je mehr

sie Erfolg haben, desto leichter werden die Befürworter agi-

ler Methoden in Zukunft Gehör bei den Entscheidern in den

Unternehmen finden.

Gleichzeitig geraten diese Befürworter in Zukunft in den

Unternehmen in ein komplexes und häufig unübersichtliches

Rationalisierung der Kopfarbeit



Vier Unternehmen an zwei Produktionsstandorten in Karlsruhe und Leimen-St.Ilgen Tel +49 (0)721 / 9 62 [email protected]

Die E&B Gruppe zählt zu den innovativsten

und leistungsfähigsten Bogenoffset-Druckereien

in Deutschland.Engelhardt und Bauer und

WDW Druck gehören dazu.

Offsetat its best!

Vier Unternehmen an zwei Produktionsstandorten in Karlsruhe und Leimen-St.Ilgen Tel +49 (0)721 / 9 62 [email protected]

Die E&B Gruppe zählt zu den innovativsten

und leistungsfähigsten Bogenoffset-Druckereien

in Deutschland.Engelhardt und Bauer und

WDW Druck gehören dazu.

Offsetat its best!

Agile Methoden aus Sicht der Arbeitssoziologie

Interview mit Dr. Andreas Boes, ISF München

Spannungsfeld unterschiedlicher Interessen. Denn Mitarbei-

ter, die Angst haben, sich ersetzbar zu machen, taugen nicht als

Protagonisten bei der Einführung neuer Konzepte.

VKSI: Und was bedeutet das für die weitere Entwicklung agiler

Methoden?

Andreas Boes: Es gibt kein Patentrezept. Die Befürworter agiler

Methoden sollten sich jedoch in Zukunft viel mehr damit aus-

einandersetzen, wie ihre Konzepte mit anderen Konzepten in

einem komplexen organisatorischen Umfeld interagieren und

welche Effekte dies hat.

In Zukunft wird viel davon abhängen, ob sich die Befürwor-

ter agiler Methoden konstruktiv und kritisch mit diesen neuen

Herausforderungen auseinandersetzen. Ein aktiver und sen-

sibler Umgang mit den neuen Widersprüchlichkeiten im Span-

nungsfeld unterschiedlicher Interessen wird daher zu einem

zentralen Erfolgsfaktor bei der Weiterentwicklung und Verbrei-

tung agiler Methoden in der Praxis.

VKSI: Herr Boes, besten Dank für das Gespräch.

PD Dr. Andreas Boes ist Wissenschaftler am ISF München

und lehrt als Privatdozent an der Technischen Universität

Darmstadt. Er ist Vorstandsmitglied des ISF München e.V.

Seine Forschungsschwerpunkte legt er auf Informatisierung

der Gesellschaft, Zukunft der Arbeit, Qualifikationsentwick-

lung von Computerspezialisten, Entwicklung der IT-Industrie

Die Fragen stellte Susann Mathis, Redaktion VKSI-Magazin.

Auf den German XP-Days in Karlsruhe hat Andreas Boes

einen Vortrag gehalten mit dem Titel »Agile Methoden

als Wegbereiter eines neuen Typs der Industrialisierung

der Softwareentwicklung«. Dem VKSI-Magazin hat er

dazu einige Fragen beantwortet.



AGIL: PASSSPIEL

Im Januar 2009 veröffentlicht die European Energy Exchange

AG (EEX) in Leipzig eine Ausschreibung zur Erstellung einer

Transparenzplattform für den Energiemarkt und fordert

die Seven2one Informationssysteme GmbH auf, ein Angebot

abzugeben. Die neue Informationsplattform für Erzeugungs-

und Verbrauchsdaten soll mehr Transparenz im europäischen

Strommarkt schaffen. Initiatoren der Plattform sind die vier

deutschen Übertragungsnetzbetreiber.

Nach einem ersten Blick in die Ausschreibungsunterlagen steht

fest: Dieses technologisch anspruchsvolle und für Seven2one

strategisch wichtige Projekt ist wegen der vielfältigen Anforde-

rungen und wegen des extrem straffen Zeitplans nur mit zusätz-

lichen Partnern zu gewinnen.

Seven2one ist Gründungsmitglied des VKSI. Was liegt also

näher, als hier nach Partnern in der Region zu suchen? Schon

nach wenigen Telefonaten steht das Team fest: Seven2one stellt

mit der eigenen Software Plattform Mesap die Datenbank-

Infrastruktur zur Verwaltung und zur automatisierten Auf-

bereitung der gemeldeten Datenströme bereit. Die andrena

objects ag bringt das notwendige Know-how für Java-basierte

Web-Anwendungen ein und entwickelt den Webservice für

die Datenübermittlung von den Meldern an die Plattform. Die

Secorvo Security Consulting GmbH liefert das nötige Sicher-

heitskonzept für die Identifizierung und Authentifizierung

der Melder und erstellt die EEX eigene Public Key Infrastruk-

tur (PKI) zur Ausstellung und Verwaltung der Zertifikate. Die

Karlsruher Firmen Bluehands und Aratom unterstützen als

langjährige Software-Entwicklungspartner von Seven2one das

Konsortium.

Netzwerke erleichtern die Partnersuche

Beim Aufbau des Konsortiums zeigte sich, wie wichtig langfris-

tiges Engagement in Netzwerken ist. Ausschreibungen lassen

nur wenig Zeit, um in Ruhe geeignete Partner zu suchen. In

Netzwerken hingegen lernt man potentielle Partner und ihre

Qualitäten frühzeitig kennen und baut Kontakte auf, so dass bei

Bedarf schnell und unkompliziert Kooperationen geschlossen

werden können.

Gerade für kleinere Unternehmen bieten Netzwerke die

Chance, zusammen mit Partnern Projekte zu gewinnen, für die

sie selbst nicht genügend Ressourcen hätten. Wer gewohnt ist,

sich in Netzwerken zu engagieren und zu organisieren, koope-

riert leichter. Obwohl Seven2one, andrena und Secorvo bisher

noch kein gemeinsames Projekt realisiert haben, sind inner-

halb einer Woche die Aufgaben verteilt und die Modalitäten der

Zusammenarbeit geklärt.

Das Projekt gemeinsam an Land ziehen

Lediglich vier Wochen bleiben den Partnern für die gemein-

same Angebotserstellung. Acht Unternehmen nehmen an der

Ausschreibung teil, drei Unternehmen kommen in die engere

Wahl. Darunter auch das Team aus Karlsruhe.

Schon eine Woche später soll das Angebot auf »höchster

Ebene« in der 23. Etage des »Steilen Zahns« im City-Hochhaus

in Leipzig, dem Sitz der EEX, präsentiert werden. Die wenige

Zeit reicht dem Team, eine Präsentation »aus einem Guss« auf-

zubauen und sich auf mögliche Fragen vorzubereiten. Die letz-

ten Abstimmungen werden im Auto auf dem Weg nach Leipzig

gemacht.

Das Angebot überzeugt. Die EEX schätzt besonders das

schon im schriftlichen Angebot erkennbare fundierte Fach-

wissen und die Referenzen von Seven2one in der Energie-

wirtschaft. Das Konzept, die verschiedenen Anforderun-

gen des Projekts bezüglich Datenbank, Web-Service und

Vernetzt zum Erfolg bei der Energiebörse Leipzig von Christoph Schlenzig, Seven2one

Die neue Transparenzplattform: www.transparency.eex.com

» Wir hatten einen extrem straffen Zeitplan. Nur durch

eine effiziente Ressourcenplanung und und eine perfekte

Zusammenarbeit konnten wir den vorgegebenen Zeitplan

einhalten«

— Mustafa Yilmaz, Projektleiter bei andrena objects ag



Sicherheitsinfrastruktur mit jeweils ausgewiesenen Experten

umzusetzen, bringt zusätzliche Pluspunkte.

Mitte März beginnen die Vertragsverhandlungen mit Seven-

2one als Konsortialführer. Anfang April startet das Projekt –

zwei Monate nach der Ausschreibung.

Apply, inspect, adapt – Schritt für Schritt zur fertigen Software

Der vorgegebene Zeitplan ist sehr eng. Ende Juni soll bereits die

erste Version der Transparenzplattform ausgeliefert werden.

Während beim Bundesverband der Energie- und Wasserwirt-

schaft BDEW in Berlin noch die letzten Details der Spezifikation

mit den meldenden Kraftwerksbetreibern abgestimmt werden,

läuft parallel die Softwareentwicklung an.

Für das Projektmanagement orientieren sich die fünf

Unternehmen am Konzept der Agilen Softwareentwicklung

und der Scrum-Methode: die Entwicklerteams organisieren

sich in zweiwöchigen Sprints. Zu Beginn eines Sprints werden

im Team die Funktionen festgelegt, die im Sprint umgesetzt

werden sollen. In vierzehntägigem Rhythmus finden Integ-

rationstreffen statt, in denen die Teams sich abstimmen, die

entwickel ten Module integrieren und Funktionstests durchfüh-

ren. »Kurze Wege, ähnliche Firmenkulturen und ein professio-

nelles Projektmanagement«, nennt Dirk Fox, Geschäftsführer

bei Secorvo, als Gründe für die reibungslose Zusammenarbeit.

Dank dieser Vorgehensweise erreichen die Partner in kurzen

Zyklen lauffähige Module, die erst intern und dann beim Kun-

den getestet werden. So können bereits in frühen Phasen des

Projektes Fehler erkannt und korrigiert oder Änderungswün-

sche des Kunden berücksichtigt werden.

Mit gebündeltem Know-how Herausforderungen meistern

Drei Monate nach der Auftragserteilung und pünktlich zur jähr-

lichen EEX Party – ein Highlight für Mitarbeiter, Kunden und

Lieferanten – installiert das Team aus Karlsruhe die erste Ver-

sion der Software. Die Projektmitarbeiter vor Ort erleben eine

schlaflose Nacht – nicht wegen der Inbetriebnahme der Soft-

ware, sondern wegen des rauschenden Festes bis in die frühen

Morgenstunden.

Im September 2009 startet der Testbetrieb nach fünf Mona-

ten Entwicklung. Ende Oktober 2009 geht die fertige und kom-

plette Transparenzplattform auf der Webseite transparency.

eex.com online.

Zielorientierte stufenweise Umsetzung, schlankes Projekt-

management, strenge Qualitätssicherung, hohe Teamkompe-

tenz und partnerschaftliche Zusammenarbeit innerhalb des

Teams und mit der EEX sind die Erfolgsfaktoren dieses Pro-

jekts.

Bei einem gemeinsamen Bowlingabend feiert die EEX gemein-

sam mit dem Karlsruher Team den erfolgreichen Projekt-

abschluss in Leipzig. Die Kugel rollt weiter.

Dr. -Ing. Christoph Schlenzig, Mitglied des Präsi-diums des VKSI, ist Geschäftsführer der Seven-2one GmbH. Seven2one Informationssysteme GmbH wurde 2001 als Spin-Off des Instituts für Energiewirtschaft der Universität Stuttgart gegründet. Das Ziel der Gründer war die Weiter-entwicklung und Vermarktung strategischer Informationssysteme zur Entscheidungsunter-stützung in der Energiewirtschaft. seven2one.de

Vernetzt zum Erfolg bei der Energiebörse Leipzig von Christoph Schlenzig, Seven2one

» Für dieses Projekt brachte jedes Unternehmen seine

Ex pertise ein: exzellente Branchenkenntnis, Erfahrung

mit der Entwicklung hochwertiger Web-Anwendungen

und Security-Kompetenz. So waren wir in der Lage, ein

maßgeschneidertes Angebot zu unterbreiten«

— Christoph Schlenzig

» Kurze Wege, ähnliche Firmenkulturen und ein

professionelles Projektmanagement waren die wichtigsten

Gründe für die reibungslose Zusammenarbeit«

— Dirk Fox, Geschäftsführer Secorvo



AGIL: ROLLENSPIEL III

Selbstorganisiert: Zitate von Mitgliedern verschiedener Scrum-Teams

»Die Nähe zu den Fachanforder-ungen verbessert den Projektablauf. Die Nähe zu den Kunden gibt den Fachanforderungen ein Gesicht. Das macht viel mehr Spaß in der Arbeit, denn man tut es für jemanden.«

»Das konsequente Durchführen und Einfordern von Retrospektiven hat bei uns endlich dazu geführt, dass wir unsere Arbeitsweise reflektieren und kontinuierlich verbessern – und diese Themen nicht wie früher im Alltagsstress untergehen.«

»Man bleibt flexibel und fährt sich nicht fest. Man kann flexibel auf Einflüsse und Veränderungen reagieren.«

»Die Sprints geben dem Projekt einen regelmäßigen Herzschlag und damit dem Team die Sicherheit, dass es voran geht.«

»Wenn der Product Owner einfach nur nicht genau weiß, was er will und sich nicht festlegen will, so macht einen sein Vorschlag, das Projekt mit Scrum durchzuführen, eher skeptisch.«

»In einzelnen Fällen kann es zu organisatorischen Problemen führen: zum Beispiel welche Aufgabe hat ein Entwicklungsleiter in einem Scrum Projekt. Für jemanden, der aus dem klassischen Projektmanagement kommt, tauchen Ungereimtheiten auf.«

»Die Zufriedenheit der einzelnen Mitglieder ist hoch, die Transparenz und auch das Feedback motivieren.«

VKSI MAGAZIN Nr. 2 Februar 201020


Wir wollen noch mehr Meinungen lesen und die Diskussion

online bei vksi.de weiterführen. Schreiben Sie Ihre Erfahrung

im Scrum-Team an [email protected]

»Definitiv ist Scrum eine hervor-ragende Methode zum Projekt-management und ich würde nur ungern wieder wechseln wollen.«

»Das Entwicklerteam bekommt mit Scrum mehr Rechte, aber auch mehr Pflichten – diese gewachsene Verantwortung muss vom Team auch angenommen werden.«

»Natürlich existiert das Risiko, dass die mittelmäßigen Leute bei solcher Transparenz eher auffallen.«

»In Zukunft wird die Verknüpfung von klassischen und agilen Projekten häufiger. Dabei ist es schwierig, Leute zu finden, die in beiden Welten zuhause sind.«

»Als Mitglied in einem agilen Ent-wicklungsteam identifiziere ich mich viel stärker mit dem ent-wickelten Produkt, als wenn ich als kleines Zahnrad im Getriebe nur mir zugewiesene Arbeitspakete abarbeite.«

»Scrum ersetzt nicht das Projekt management. Scrum ist ein Vor gehens modell für die Softwareentwicklung, aber die Planung der Ressourcen, Meilensteine und die kaufmännische Planung müssen trotzdem separat gelöst werden.«

»Die Zufriedenheit beim Kunden ist wesentlich größer. Die innere Qualität der Software wird davon allerdings nicht zwangsläufig berührt. Sie hängt stark vom Team im Einzelnen ab.«



Termine 2010

10.-12. März Karlsruhe21.-23. Mai Karlsruhe1.-3. Dezember Karlsruhe

Vorbereitung zur Erlangung des Zertifikats zum IREB „ Certified Professional for Requirements Engineering (CPRE)“

Experts in agile software engineering

Scrum Master Zertifizierung

TRAINING

Termine 2010

14./15. April Karlsruhe20./21. Oktober Karlsruhe17./18. November Zürich

Joseph Pelrine

Requirements Engineering & Management

Scrum Master & Scrum Product Owner Zertifizierung

Joseph Pelrine

Termine 2010

14.-16. April* Karlsruhe07.-09. Juli* Frankfurt/M.20.-22. Oktober* Karlsruhe

24.-26. Februar* Frankfurt/M.15.-17. September* Stuttgart

* Für alle, die mehr wissen wollen: Interaktiver Workshop, Scrum Clinic und Open Space. Alle Teilnehmer können sich zu konkreten Problemen und der praktischen Umsetzung von Scrum aus tauschen und sich von den Trainern und weiteren Coaches beraten lassen. Dieser 3. Tag ist optional, also nicht Teil der Zertifizierung und er ist offen für alle, die Scrum in der Praxis einsetzen. Weitere Informationen zu dem dritten Tag unter www.andrena.de.

Dr. Christoph Mathis

Dr. Peter Hruschka

Simon Roberts

www.andrena.deandrena objects agAlbert-Nestler-Straße 1176131 KarlsruheTelefon 0721 6105-122Telefax 0721 6105-140

andrena VKSI 2010.2 A4 100203.indd 1 03.02.2010 11:52VKSIMagazin-1002-08.indd 22 03.02.2010 17:09

AGIL: UM DEN BALL SCHIEBEN*

Termine 2010

10.-12. März Karlsruhe21.-23. Mai Karlsruhe1.-3. Dezember Karlsruhe

Vorbereitung zur Erlangung des Zertifikats zum IREB „ Certified Professional for Requirements Engineering (CPRE)“

Experts in agile software engineering

Scrum Master Zertifizierung

TRAINING

Termine 2010

14./15. April Karlsruhe20./21. Oktober Karlsruhe17./18. November Zürich

Joseph Pelrine

Requirements Engineering & Management

Scrum Master & Scrum Product Owner Zertifizierung

Joseph Pelrine

Termine 2010

14.-16. April* Karlsruhe07.-09. Juli* Frankfurt/M.20.-22. Oktober* Karlsruhe

24.-26. Februar* Frankfurt/M.15.-17. September* Stuttgart

* Für alle, die mehr wissen wollen: Interaktiver Workshop, Scrum Clinic und Open Space. Alle Teilnehmer können sich zu konkreten Problemen und der praktischen Umsetzung von Scrum aus tauschen und sich von den Trainern und weiteren Coaches beraten lassen. Dieser 3. Tag ist optional, also nicht Teil der Zertifizierung und er ist offen für alle, die Scrum in der Praxis einsetzen. Weitere Informationen zu dem dritten Tag unter www.andrena.de.

Dr. Christoph Mathis

Dr. Peter Hruschka

Simon Roberts

www.andrena.deandrena objects agAlbert-Nestler-Straße 1176131 KarlsruheTelefon 0721 6105-122Telefax 0721 6105-140

andrena VKSI 2010.2 A4 100203.indd 1 03.02.2010 11:52

Anfang der 90er Jahre gab es die ersten Ansätze der Agilen

Software Entwicklung. So richtig bekannt wurde sie aber erst

1999 durch das »extreme Programming« genannte Verfah-

ren, das Kent Beck mit Kollegen als gleichnamiges Buch ver-

öffentlichte. In den folgenden Jahren hat sich diese Methode

vor allem in der IT-Branche durchgesetzt. Viele Unternehmen

haben erkannt, dass Projekte schneller und effizienter mit agi-

len Prozessen umzusetzen sind, nicht zuletzt deshalb, da die

Agile Software Entwicklung mit geringem bürokratischen

Aufwand und wenigen Regeln auskommt. So werden in regel-

mäßigen Besprechungen kurze Entwicklungsschritte geplant,

um die Prozesse besser und schneller vorantreiben zu können.

Auch der Bereich Qualitäts sicherung ist fester Bestandteil des

Prozesses, die eine schnelle Bearbeitung der Bugs gewährleis-

tet und somit die gesamte Entwicklung besser überwacht und

steuert.

Unser Team besteht aus zwölf Entwicklern und drei Testern. In

einer straffen Organisation werden einmal wöchentlich Relea-

ses geplant und die kommenden Roll-Outs vorbereitet. Da die

Teams an den Standorten in Karlsruhe und München arbeiten,

tauschen wir uns telefonisch oder über den hauseigenen Mul-

timessenger aus und unterrichten über laufende oder anste-

hende Aufgaben. Zudem bespricht das Team einmal wöchent-

lich per Videokonferenz die Vorgehensweise für das nächste

Release. In dieser Runde schätzen Entwickler und Teamleiter

gemeinsam die Wochenziele ab, definieren die Aufgaben und

teilen diese zu. Die Planung erfolgt hierbei immer für die nächs-

ten sieben Tage, einen Tag vor der neuen Konferenz erfolgt ein

Codefreeze – eine Fixierung des aktuellen Entwicklungsfort-

schritts. Damit alle im Team die laufenden Prozesse sowie den

aktuellen Status der Entwicklungen verfolgen können, werden

die Aufgaben in einem Wiki eingetragen. Sobald eine Aufgabe

abgearbeitet ist, wird diese vom jeweiligen Entwickler als erle-

digt gekennzeichnet.

Diese Vorgehensweise fördert ein flexibles Arbeiten, da sich

die Kollegen untereinander unterstützen und stärkt darüber

hinaus die enge Zusammenarbeit und das Teambewusstsein.

Ist es den Entwicklern nicht möglich eine der Aufgaben bis zum

Codefreeze umzusetzen, wird diese im Wiki rot markiert und

in die nächste Planung mit aufgenommen. Nach dem Code-

freeze am Abend vor der Wochenkonferenz wird die bis dahin

entwickelte Version des Produktes an die Qualitätssicherung

gegeben. Dort testen die Kollegen die bis dahin vorliegende

Version des Produktes im Endkunden-Status. Dies gewährleis-

tet, dass sie sich nicht zu weit aus der Sicht des Kunden ent-

fernen und Fehler schneller entdeckt werden. Testphase und

Bugfixing dauern insgesamt drei Werktage, sodass einen Tag

später die getestete Version in den Roll-Out gehen kann. In der

wöchentlichen Aufwandsabschätzung muss vor allem beachtet

werden, dass mindestens zwei bis drei Entwickler für die Behe-

bung der Bugs eingeteilt sind. Sobald die ersten Bugs von der

Qualitätssicherung spezifiziert wurden, beginnt die Reparatur,

während der Rest des Teams mit der Entwicklung des nächsten

Release beginnt.

Eine der Herausforderungen bei der Agilen Software Entwick-

lung ist mit Sicherheit die Planung. So müssen vorab alle neuen

Features durchdacht und die Aufwände abgeschätzt werden,

um die zur Verfügung stehende Zeit der nächsten Woche opti-

mal verteilen zu können. Eine disziplinierte Organisation macht

sich im Ergebnis bezahlt, da die Kollegen durch die kurzen Ent-

wicklungsintervalle sowie durch die sofortige Bearbeitung der

Bugs in der Gesamtentwicklung schneller vorankommen, als

mit herkömmlichen Entwicklungsmethoden wie beispielsweise

dem Wasserfall- oder V-Modell.

Collin Rogowski, Head of Mail Ser vices International bei der 1&1 Internet AG, ist mit seinem Team für die Weiterentwick-lung des Maildienstes GMX.com für die Länder Spanien, Frankreich, Großbritannien und USA verantwortlich. Vor einigen Jahren führte er in seinem Team die Agile Softwareentwicklung ein. Gründe hierfür waren der Wunsch nach kurzen Release-Zyklen, um schnell auf Änderungen am Markt reagieren zu können sowie der Bedarf nach iterativer Featureentwicklung unter Einbezug der Usercommunity. 1und1.de

Schneller ans Ziel – Jede Woche ein ReleaseAgile Software Entwicklung bei 1&1 von Collin Rogowski, 1&1 Internet AG

1&1-Standort in Karlsruhe

* Um den Ball schieben: Die Spieler versuchen, durch gemein sames Drücken den Gegner wegzuschieben und somit den Ball für das eigene Team freizugeben.



FORSCHUNG + ENTWICKLUNG

Seit 2002 sind die Taktraten bei Mikroprozessoren kaum noch

gestiegen – durch Hitzeentwicklung und Energieverbrauch

sind deutliche Grenzen erreicht. Um die Performance weiter

zu steigern, setzen Hardwarehersteller nun auf Multicore-Pro-

zessoren. Auch für die Energieersparnis an Rechenzentren

kann die Mehrkern-Technologie einen wesentlichen Beitrag

leisten. Multicore-Prozessoren integrieren meh rere unab-

hängige Kerne sowie gemeinsam genutzte Cache-Speicher auf

einem Chip. Sie erzeugen im Vergleich zu Single-Core-Prozes-

soren bei ähnlicher Rechenleistung weniger Abwärme.

Multikern-Systeme – Neuerfindung der Softwaretechnik von Walter F. Tichy, FZI/KIT

Erfolgreich parallelisierte Anwendungen bieten neben der

erheblichen Verbesserung der Laufzeiten weitere Vorteile. Wo

heute spezielle Hardware nötig ist, könnte bald ein daumenna-

gelgroßer Chip ausreichen, um die gleiche Aufgabe zu erfüllen.

Beispiel ist die Straßenschilderkennung in hochwertigen Autos,

die momentan nur kostenintensiv umsetzbar ist (s. oben).

Grundlagen der Informatik neu überdenken

Schon jetzt ist es schwierig, einen Rechner mit nur einem Pro-

zessor zu kaufen. Die Mooresche Regel muss neu formuliert

werden: Die Anzahl der Kerne pro Chip verdoppelt sich alle

zwei Jahre. Doch mehr Chips führen noch nicht unmittelbar

zu mehr Leistung. Um die Performance mittels Mehrkern-

Chips weiter steigern zu können, müssen die Entwickler

Anwendungen aller Art parallelisieren. Sprachen, Debugger,

Analysewerkzeuge sind für Parallelität nicht geeignet und nicht

zuletzt sind die meisten Programmierer noch nicht auf diesen

Umschwung vorbereitet.

Zwar kann die Softwaretechnik auf dem langjährigen Ein-

satz der Parallelität in der Disziplin des wissenschaftlichen

Rechnens aufbauen. Jedoch sind numerische Anwendun-

gen klein und arbeiten mit einer überschaubaren Menge von

Datenstrukturen. Parallelität im großen Maßstab einzusetzen

verlangt, dass die großen Anwendungen auf PCs und Servern

mit ihren Millionen Zeilen Code neu erarbeitet werden müssen.

Auch ist es nicht möglich, die Parallelisierung den Compilern zu

übertragen: Die automatische Parallelisierung entspricht der

Herleitung eines parallelen Algorithmus für ein Problem, für

das nur eine sequenzielle Implementierung – und damit nicht

einmal eine Spezifikation – vorliegt. Schon die automatische

Oben: Originalbild, aufgenommen von einem Kamerapaar auf dem Dach des autonomen Autos Annieway des KIT. Unten: der gleiche Bildausschnitt mit aus dem linken und rechten Kamerabild berechneter Stereo-Disparität. Diese Berechnung zur Fahrbahnerkennung ist rechenaufwändig und ein Einsatz-gebiet für die parallele Verarbeitung.

© Andreas Geiger, Institut für Mess- und Regelungstechnik



Herleitung sequenzieller Algorithmen aus präzisen Spezifika-

tionen ist kaum praktikabel; im parallelen Fall ist das Problem

noch weiter verschärft. Die Softwaretechnik braucht Methoden,

die nicht weniger tun, als die Softwareentwicklung in vollkom-

men neue Bahnen zu lenken. Viele der Grundlagen der Infor-

matik müssen neu überdacht werden.

Was tun mit all den Kernen?

Höhere Leistung durch mehr Kerne beschleunigt nicht nur

alle Berechnungen, die heute zu langsam sind, wie z.B. vor-

ausschauende Anwendungen, die »ahnen«, was der Benutzer

will. Die höhere Leistung erhöht auch die Zuverlässigkeit der

Anwendungen. Aber damit müssen wir uns nicht zufriedenge-

ben: Die Leistungsfähigkeit der Prozessoren könnte ganz neue

Funktionen möglich ma chen. Wie wäre es z.B. mit einem »trag-

baren automatischen Protokollführer«, der bei Besprechungen

assistiert, indem er Aussagen protokolliert und sie den einzel-

nen Sprechern zuordnet, simultan übersetzt, zusammenfasst

oder auch parallel Suchaufträge erledigt; Oder einer Inhalt-

basierten Bildsuche, die mit Hilfe von Ähnlichkeitsmetriken

nicht indizierte Bilder oder auch komplexe Bilder mit Personen,

Objekten, Orten, Ereignissen findet?

Parallelisierung in Karlsruhe

Was Parallelisierung betrifft, sind die Informatiker am KIT

unter den Forschungseinrichtungen in Deutschland führend.

Mehrere Arbeitsgrup pen, Sonderforschungsbereiche, Koope-

rationsprojekte mit der In dustrie und die Young Investigator

Group »Software Engineering für Multicoresysteme« arbeiten

an verschiedenen Aspekten der Parallelisierung wie den Rech-

nerarchitekturen oder Betriebssystemen. Aktuelle Projekte

des Instituts für Programmstrukturen und Datenorganisation

– ipd.uka.de – beschäftigen sich zum Beispiel mit der Gesichts-

erkennung bei Videoüberwachung (BMBF), mit einer paral-

lelen Lernphase für Sprachübersetzer (mit CMU) und mit der

Schaltkreis-Platzierung für Mikroprozessoren (mit SUN).

Beispiel Transportproblem – ObjektForum Förderpreis

Eine an unserem Institut erstellte Diplomarbeit von Markus

Hossner widmete sich dem »Lösen großer Transportproble-

me durch Parallelisierung auf Multikern-Systemen« bei SAP

und erhielt Ende 2009 den ObjektForum Förderpreis. Dieses

Projekt ist insofern exemplarisch, da es a) die Tücken bei der

Implementierung nachweist und b) den unmittelbaren direk-

ten Nutzen verdeutlicht:

Das verallgemeinerte »Problem des Handlungsreisenden«

sucht einen kostenoptimalen Transportplan, der bestimmt,

welche Aufträge auf welchen Fahrzeugen über welche Strecken

ausgeführt werden. Bei den realen Transportszenarien – mit

einem jeweiligen Volumen von 800 bis 8.000 zu koordinie-

renden Aufträgen – müssen nicht nur die unterschiedlichen

Stationen und Fahrzeuge, sondern auch Ruhezeiten der Fahrer,

Ladezeiten, Fahrzeugtypen und -kapazitäten, Anhänger, Auf-

tragsprioritäten, Fähren und Schiffe.... berücksichtigt werden.

Für gute Lösungen dieses Touren- und Zeitplanungsproblem

sind bei SAP üblicherweise mehrere Stunden Rechenzeit nötig.

Jedoch brachten Parallelisierungen hier zunächst keine

Beschleunigung. Bei den parallelen Metaheuristiken stellten

sich zwei Flaschenhälse heraus: Zum einen der Heap, in dem

Objekte oder Elemente abgelegt und wieder entnommen wer-

den. Hier musste eine skalierende Speicherverwaltung einge-

setzt werden – im Fall der SAP-Implementierung eine eigene

Lösung nach dem Hoard Vorbild. Der zweite Flaschenhals

zeigte sich bei den gemeinsam genutzten Ressourcen. Zur

Lösung dieses Problems wurden Strategien für gemeinsame

Zugriffe entwickelt: kritischer Abschnitt mit Sperre, Master-

Slave-Ansatz und privater Zugriff mit Aggregation. Nach dieser

Optimierung zeigte die Analyse, dass bei der Optimierung eines

Szenarios für das Transportproblem in zwei Minuten 23,16 mal

mehr Lösungen überprüft wurden: Während beim sequentiel-

len Verfahren 18 Mio. Lösungen überprüft wurden, waren es

beim sequentiellen Verfahren 431 Mio. Lösungen.

Die Chance nutzen

Die Beispiele zeigen: Um das volle Potenzial der Multicore-

Rechner nutzen zu können, müssen wir auf die Entwicklung

paralleler Software auf breiter Front umstellen. Wir erleben

eine fundamentale Umwälzung in der Informatik und bekom-

men die Chance, neuartige Anwendun-

gen zu entwickeln. Nutzen wir sie!

Prof. Dr. Walter F. Tichy bekleidet seit 1986 den Lehrstuhl für Softwaretechnik der Fakul-tät für Informatik des Karlsruher KIT. Von 2002 bis 2004 war er Dekan der Informatik-Fakultät. Seit 1998 ist er außerdem Direktor für Softwaretechnik am Forschungszentrum Informatik (FZI) in Karlsruhe. ipd.uka.de

Gegeben:●● Lieferaufträge●● Fahrzeuge●● SteckennetzWelche

Aufträge?

Auf welchen Fahrzeugen?

Über welche Strecken?

Transportproblem

Ziel:kostenoptimaler Transportplan



FORSCHUNG + ENTWICKLUNG

Eine Wahl muss unmittelbar, gleich, frei und geheim sein. Das

steht im Grundgesetz. Mit Hilfe von Maschinen zu wählen ist

nur dann interessant, wenn man dadurch Vorteile gegenüber

dem herkömmlichen Wahlverfahren erzielt. Ein Gesichts-

punkt ist die Kostenersparnis. Darüber hinaus soll die Aus-

zählung zügig vonstattengehen. Doch kryptografische Wahl-

verfahren leisten noch mehr: Der Wähler kann zusätzlich

kontrollieren, ob seine Stimme richtig gezählt wurde.

Wahlmaschinen sind nichts Neues. Genauso wenig wie die Kri-

tik an ihnen. Gewiss, kein System ist völlig fälschungssicher,

schon gar nicht die Abstimmung mit Zettel und Bleistift. Doch

die physische Präsenz des Zettels in der Urne vermittelt Sicher-

heit. Der Einsatz von Wahlcomputern zur Stimmabgabe oder

zur Auszählung dagegen stellt die Nachvollziehbarkeit in Frage.

Nachvollziehbarkeit für Wahlmaschinen bietet nun das am

KIT entwickelte Verfahren Bingo Voting. Sein Vorteil ist, dass

sich das Verfahren mit jeder Art von Wahlmaschine kombi-

nieren lässt. Insbesondere mit Scanner-basierten Verfahren

mit Wahlzettel und Urne oder mit Wahlmaschinen, die einen

Stimmzettel für eine separate Urne ausdrucken.

Bingo Voting garantiert die vollständige und beweisbare

Verifizierbarkeit des Wahlergebnisses, ohne jedoch das Wahl-

geheimnis zu gefährden. Bingo Voting wurde am Institut für

Kryptographie und Sicherheit des KIT entwickelt und mit dem

Deutschen IT-Sicherheitspreis ausgezeichnet.

Herzstück des Wahlverfahrens: ein vertrauenswürdiger

Zufallsgenerator

Vor der Wahl erhält jeder Kandidat gleich viele Zufallszahlen,

so genannte Füllstimmen.

Auch die in der Wahlkabine abgegebene Stimme wird durch

eine Zufallszahl repräsentiert. Diese jedoch wird vor den Augen

des Wählers von einem vertrauenerweckenden Zufallszahlen-

generator erzeugt wie z.B. einer Lottotrommel oder einem Bin-

gokäfig. Daher stammt auch der Name »Bingo Voting«.

Jeder Wähler erhält direkt nach der Stimmabgabe einen

Beleg, mit dessen Hilfe nur er die korrekte Zählung seiner Stim-

me überprüfen kann und niemand sonst. Stimmenkauf und

Erpressung sind so unmöglich. Auf diesem Beleg steht neben

jedem Kandidaten eine Zahl. Nur eine dieser Zahlen reprä-

sentiert eine abgegebene Stimme – sie ist die in der Wahlka-

bine generierte Zufallszahl. Die anderen Zahlen sind die oben

beschriebenen Füllstimmen.

Nach der Wahl werden Kopien aller Belege veröffentlicht.

Nun kann der Wähler mit Hilfe seines ausgedruckten Belegs

überprüfen, ob seine Stimme korrekt gezählt wurde. Diese

Möglichkeit besteht bei den herkömmlichen Wahlzetteln nicht.

Der von ihm gewählte Kandidat hat eine seiner – schon

vorher festgelegten und ihm zugeordneten – Füllstimmen

übrig behalten, wohingegen alle anderen Kandidaten eine

Füllstimme für den Beleg »aufbrauchen«. Diese Anzahl der

Füllstimmen bildet die Basis für den nach der Wahl erfolgenden

Beweis der Korrektheit der Auszählung: Je weniger Füllstim-

men ein Kandidat verbraucht, desto mehr echte Stimmen hat

er erhalten.

Vorteil: Beim Wahlvorgang unterstützen

Darüber hinaus kann mit dem kryptografischen Wahlverfah-

ren Bingo Voting praktisch ausgeschlossen werden, dass irr-

tümlich ein ungültiger Stimmzettel abgegeben wird. Außerdem

kann dem Wähler die verbleibende Anzahl der Stimmen ange-

zeigt werden, was besonders beim Kumulieren und Panaschie-

ren hilfreich ist. Wer seine Brille vergessen hat, kann sich die

Schrift vergrößern lassen. Zusätzlich sind weitere Maßnahmen

für Menschen mit Behinderungen denkbar, zum Beispiel eine

Audio-Ausgabe für blinde Wähler.

Sicherheit: Schutz vor Auszählungsfehlern

Ein Auszählungsfehler wie jüngst in Schleswig-Holstein wäre

beim Bingo-Voting gleich bemerkt worden, insbesondere nicht

durch schwache Indizien, wie eine Abweichung vom erwarteten

Wahlergebnis, sondern durch den Sicherheitsmechanismus,

der bei Bingo Voting die Korrektheit garantiert.

Zum Beispiel mit Hilfe der Zero-Knowledge-Beweise nach

dem Prinzip des Randomized Partial Checking, die es ermögli-

chen nachzuweisen, dass jeder Kandidat gleich viele Füllstim-

men erhalten hat, ohne dabei irgendwelche Information darüber

hinaus preiszugeben. Um dies effizient zu erlauben, werden als

Commitment-Verfahren sogenannte Pedersen Commitments

eingesetzt. Die während des Beweises zu treffenden Zufalls-

wahlen werden, der allgemeinen Nachvoll-

ziehbarkeit wegen, über Hashfunktionen

berechnet (Fiat Shamir Methodology).

Prof. Dr. Jörn Müller-Quade leitet den Lehrstuhl für IT-Sicherheit am IKS (Institut für Kryptogra-phie und Sicherheit) der Fakultät für Informatik des KIT und ist Leiter des Europäischen Instituts für Systemsicherheit. iks.kit.edu

Bingo Voting: Sichere Wahlen durch vertrauenswürdigen Zufall von Jörn Müller-Quade, IKS/KIT

In der Wahlkabine: Der Wähler hat per Wahlcomputer (links) Kandidat B gewählt und bekommt einen Beleg, bei dem die zu Kandidat B gehörende Zufallszahl mit der Anzeige des Zufallszahlengenerators (oben rechts) übereinstimmt.



STANDORT

Karlsruhe ist nicht nur Internethauptstadt, sondern nach

Untersuchungen des Cluster Obsevatory der drittgrößte IT-

Standort Europas – mit ca. 3.600 Unternehmen und annä-

hernd 36.000 Arbeitsplätzen.

Viele der regionalen Unternehmen benötigen für weiteres

Wachstum und Stabilisierung in erster Linie Fachkräfte. Hat

man noch vor einigen Jahren nur an den Informatikfakultäten

der Hochschulen rekrutiert, geht zwischenzeitlich der Trend zu

den dualen Ausbildungsberufen.

Die neuen Ausbildungsberufe wie Fachinformatiker/in,

IT-Systemkaufmann/frau, Informatikkaufmann/frau oder

Mathematisch-technischer Softwareentwickler/in sorgen für

den benötigten Nachwuchs. Im Kammerbezirk der IHK Karls-

ruhe hat die Anzahl der angebotenen Ausbildungsplätze in den

letzten 10 Jahren um über 300% zugenommen. Potentielle

Auszubildende sind Abiturienten, die nicht studieren wollen,

gute Realschüler und vermehrt auch Studienabbrecher.

Das regionale Hightech.Unternehmer.Netzwerk CyberFo-

rum unterstützt diese Ausbildungsberufe seit seiner Gründung

im Jahre 1997 mit seiner Ausbildungsinitiative. Im Durch-

schnitt werden pro Jahr über 300 Bewerber per Auswahlver-

fahren aus den gesamten Bewerbungen herausgefiltert, die

dann den Unternehmen vorgestellt werden. Durch diese Akti-

vität konnten im genannten Zeitraum über 300 Nachwuchs-

kräfte erfolgreich ausgebildet werden.

Seit März 2009 wird diese Initiative durch das Projekt

»Durchstarter«, einem »JOBSTARTER-Projekt des Bundes-

ministeriums für Bildung und Forschung und der EU, ergänzt.

Durch gezielte Aktivitäten und Programme sollen bis Februar

2012 über 100 zusätzliche Ausbildungsplätze in IKT-Unter-

nehmen initiiert werden.

Gerade für Klein- und mittelständische Unternehmen sind

diese zukünftigen Arbeitnehmer eine interessante Alternative,

da sie während ihrer - meist dreijährigen - Ausbildung nicht

nur in der Berufsschule die notwendigen theoretischen Inhalte

vermittelt bekommen, sondern die Unternehmen in den Pra-

xisphasen bereits nach kurzer Einarbeitungszeit von der Mitar-

beit der Auszubildenden profitieren können.

Durch gezielte Aktivitäten an Schulen und Universitäten

informieren die Verantwortlichen über die neuen Berufsbilder.

Da aktuell auch auf Grund des demographischen Wandels die

Akquirierung von Nachwuchskräften immer schwieriger wird,

versucht man auch durch die Vermittlung von entsprechenden

Praktika Schüler und Studienabbrecher für technische Berufe

zu begeistern.

Die Hauptaufgabe für die Projektverantwortlichen im

CyberForum liegt in der Zusammenführung von interessierten

Unternehmen und potentiellen Auszubildenden. Seit Projekt-

start im März 2009 konnten schon 13 zusätzliche und neue

Ausbildungsplätze besetzt werden.

Nachwuchskräfte für regionale IT-UnternehmenNeue Perspektiven in der Ausbildung

Hintergrund: CyberForumDas CyberForum wurde 1997 als Privat-Public-Partnership

als Existenzgründernetzwerk gegründet. Im Mittelpunkt

aller Aktivitäten steht die Vermittlung von Business-Wissen

unter dem Motto »aus dem Netzwerk für das Netzwerk«.

Heute ist der gemeinnützige Verein mit über 770 Mitglie-

dern das größte regional agierende Hightech.Unternehmer.

Netzwerk in Deutschland.

DURCHSTARTER…ist ein Projekt des CyberForums und wird gefördert als

JOBSTARTER-Projekt durch das Ministerium für Bildung

und Forschung und den Europäischen Sozialfonds der Euro-

päischen Union.

www.cyberforum.dewww.it-durchstarter.de



INITIATIVE

VKSI: Stefan, ich freue mich dieses Interview mit Dir für den

VKSI machen zu dürfen. CCD hat meine Arbeits weise im ver-

gangenen Jahr stark beeinflusst. Für mich persönlich stellt

es einen Baustein auf dem Weg in Richtung des Karlsruher

Manifests² des VKSI dar. Kannst Du bitte den Lesern, welche

noch nicht mit Eurer Initiative vertraut sind, kurz vorstellen,

was die wesentlichen Ziele bei CCD sind?

Stefan Lieser: Am Anfang der Initiative stand für Ralf Westphal und

mich die Frage, was einen professionellen Software Entwickler

ausmacht. So haben wir begonnen, Bausteine zusammen zu

tragen, von denen wir glauben, dass sie zu innerer Qualität von

Software beitragen. Als wir ungefähr 40 Prinzipien und Prakti-

ken zusammengetragen hatten, kamen wir darauf, diese Bau-

steine unter einem Wertesystem zusammenzufassen. Zusam-

mengefasst ist also das Ziel der Clean Code Developer Initiative,

die innere Qualität von Software zu verbessern, indem die Ent-

wicklung von Software professionalisiert wird.

VKSI: Es gibt schon einige andere Ansätze, die Qualität in der

Softwareentwicklung zu verbessern. Was ist der Unterschied

bei CCD?

Stefan Lieser: Laut ISO 9000 wird mit Qualität der Grad bezeich-

net, mit dem Merkmale eines Produktes Anforderungen erfül-

len. Ein Merkmal von Software ist beispielsweise ihre Sicher-

heit. Ohne Anforderungen an dieses Merkmal zu stellen, kann

man jedoch keine Aussage über die Qualität in diesem spezi-

ellen Merkmal treffen. Folglich müssen zur Betrachtung der

Qualität nicht nur Merkmale definiert werden, sondern auch

die jeweiligen Anforderungen an diese Merkmale. Daraus ent-

steht dann die zentrale Frage: wer definiert die Anforderungen

an Software? Die reflexartige Antwort lautet natürlich: König

Kunde.

Diese Antwort ist jedoch nicht ausreichend. Würden die

Anforderungen ausschließlich von Kunden definiert, wären nur

Qualitätsmerkmale zu betrachten, die dem Kunden vertraut

sind. Daher müssen den völlig berechtigten Anforderungen der

Kunden die Anforderungen derjenigen hinzugefügt werden, die

hinter die Kulissen schauen. Noch deutlicher wird das Prob-

lem, wenn man an Ergänzungen oder Änderungen von Fea-

tures denkt. Natürlich geht der Kunde davon aus, dass er zu

einem späteren Zeitpunkt weitere Features einfordern kann.

Dass wir als Softwareentwickler dafür jedoch Vorsorge tragen

müssen, kann und soll ihn nicht interessieren. Dies ist unsere

Verantwortlichkeit, weil nur wir die Details der Softwareent-

wicklung kennen.

Die Clean Code Developer Initiative ist damit ein Gegenge-

wicht zu den Anforderungen der Kunden. Unser Fokus liegt auf

der inneren Qualität. Wir wollen versuchen, einen Ausgleich

zu schaffen zwischen den Anforderungen der Kunden und sol-

chen, die sich nur aus der Kenntnis der inneren Details ergeben

können.

VKSI: Im Zusammenhang mit CCD wird von »professioneller«

Softwareentwicklung gesprochen. Was unter scheidet die

CCD Definition von »Professionell« von der etablierten Vor-

stellung?

Stefan Lieser: Für uns verfügt ein professioneller Softwareentwick-

ler sowohl über ein Wissensgebäude als auch über ein Wer-

tesystem. Dass Softwareentwickler über ein gewisses Maß an

Kenntnissen verfügen müssen, dürfte allgemein anerkannt

sein. Ein Wertesystem konnten wir allerdings bislang nicht

ausmachen. Das führte uns dazu, die vier Werte Evolvierbar-

keit, Korrektheit, Produktionseffizienz und Reflexion zu for-

mulieren. Damit weichen wir meiner Einschätzung nach jedoch

mit unserem Begriff von „Professionell“ nicht von etablierten

Vorstellungen ab. Unter Softwareentwicklern etabliert sich

langsam die Ansicht, dass automatisiertes Testen eine nützli-

che Praktik ist. Aber eben nicht zum Selbstzweck, sondern weil

damit die Werte Evolvierbarkeit, Korrektheit, Produktionseffi-

zienz und Reflexion positiv beeinflusst werden.

Inhaltlich steht natürlich die Frage im Raum, ob denn aus-

gerechnet das von uns vorgeschlagene Wertesystem ausreicht

bzw. zum Ziel der höheren inneren Qualität führt. Dieser Dis-

kussion stellen wir uns gerne und fordern sie sogar ein. An

dieser Stelle sei auf die Diskussionsmöglichkeiten bei google

(http://groups.google.de/group/clean-code-developer) und

xing (https://www.xing.com/net/ccd) hingewiesen.

VKSI: Bei Entwicklerveranstaltungen trifft man immer mehr

Entwickler mit CCD Armbändern an. Was hat es mit den Bän-

dern auf sich?

Stefan Lieser: Die Armbänder können mehrere Funktionen über-

nehmen. Zum einen dienen sie dazu, denjenigen der eines trägt

daran zu erinnern, dass er sich mit den Bausteinen der Clean

Code Developer Initiative auseinandersetzen will. Bei über

40 Bausteinen ist es nicht damit getan, sich mal ein paar Tage

damit zu beschäftigen. Es erfordert in vielerlei Hinsicht ein

Clean Code Developer – Initiative für professionelle Softwareentwicklung

Interview mit Stefan Lieser

¹ Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin), Prentice Hall International, 2008 ISBN 0-13-235088-2.² VKSI Karlsruher Manifest für Software Engineering: http://www.vksi.de/karlsruher-manifest.html

Anfang 2009 wurde von Ralf Westphal und Stefan Lieser die

Initiative »Clean Code Developer (CCD)« ins Leben gerufen.

Die Idee dazu basiert auf dem Buch »Clean Code« von Robert

C. Martin¹. Da beide aus dem Lager der .NET Entwickler kom-

men, erfreut sich CCD dort einer großen Beliebtheit und

schlägt sich inzwischen auch in den Medien nieder.



Umdenken und Lernen. Solche Veränderungsprozesse erfor-

dern Disziplin und da kann es helfen, wenn man durch ein Arm-

band immer wieder daran erinnert wird, sich mit den Baustei-

nen und Werten auseinander zu setzen. An der Stelle möchte

ich betonen, dass wir das Armband als eine Möglichkeit unter

vielen verstehen. Wer sich durch ein Knoten im Taschentuch

erinnert, verzichtet eben auf das Armband.

Da es sehr viele Prinzipien und Praktiken zu erlernen und

umzusetzen gilt, haben wir sie in fünf sogenannte Grade ein-

geteilt. Dabei haben wir darauf geachtet, die Bausteine in eine

sinnvolle Reihenfolge zu bringen. Ferner haben wir jeden Grad

mit einer Farbe versehen und haben uns dabei am Regenbo-

gen orientiert. Die Kernidee der Grade ist, sich für jeweils etwa

drei Wochen schwerpunktmäßig mit den Bausteinen eines Gra-

des vertraut zu machen. Danach wechselt man zum nächsten

Grad. Irgendwann muss man dann mal alle Bausteine in ihrer

Gesamtheit berücksichtigen, dazu dient der weiße Grad. Er ver-

einigt sozusagen alle Grade in sich, so wie Weiß alle Farben

enthält. Nachdem man dies ebenfalls für einige Zeit getan hat,

sollte man übrigens wieder von vorne beginnen. Insofern ist

der Begriff Grad vielleicht etwas irreführend. Wir wollen damit

nicht implizieren, dass jemand, der sich mit dem gelben Grad

auseinandersetzt besser ist, als jemand der am roten Grad

arbeitet. Unsere Horrorvorstellung wäre, wenn Personalabtei-

lungen plötzlich auf die Idee kämen, Entwickler zu suchen die

mindesten den gelben Grad absolviert haben. Die Grade dienen

nur der Einteilung der Bausteine in handhabbare Teilmengen.

Eine weitere Funktion der Armbänder ist das Marketing

bzw. die Kennzeichnung. Wir möchten die Idee der Clean

Code Developer Initiative natürlich verbreiten, weil wir glau-

ben, dass die gesamte Branche sich langfristig auf ein gemein-

sames Werte system verständigen sollte. Ob das am Ende das

Wertesystem der Clean Code Developer Initiative ist, sei dahin

gestellt, wir möchten gerne auf das Problem mangelnder inne-

rer Qualität hinweisen und eine mögliche Lösung anbieten.

Wer nun mit den Armbändern nichts anfangen kann, lässt

sie halt weg. Auch das ist uns wichtig zu betonen.

VKSI: Das hört sich nach viel Aufwand für den Entwickler an.

Welchen Vorteil hat er in der täglichen Arbeit?

Stefan Lieser: Das Anwenden der Clean Code Developer

Prinzipien und Praktiken führt meiner Beobachtung nach zu

größerer Ruhe und Zufriedenheit. Es gibt ein sicheres Gefühl zu

wissen, dass die Software die man gerade erstellt, für zukünftige

Anforderungen gerüstet ist. Ferner sind die Rückläufer durch

Fehler geringer. All dies wirkt sich positiv auf den Alltag des

Entwicklers aus, so dass sich der Aufwand, sich mit den Bau-

steinen auseinanderzusetzen, in mehrfacher Hinsicht lohnt.

VKSI: Vom Management hört man entsprechend die Frage

nach den höheren Kosten. Was »kostet« CCD Deiner Meinung

nach?

Stefan Lieser: Meine Gegenfrage lautet: was kostet es, wenn man

CCD oder vergleichbare Konzepte nicht einsetzt? Die Kosten,

die nach der eigentlichen Entwicklung der Software anfallen,

werden in aller Regel nicht näher betrachtet. Ich habe Teams

Clean Code Developer – Initiative für professionelle Softwareentwicklung

Interview mit Stefan Lieser

,



INITIATIVE

Clean Code Developer – Interview mit Stefan Lieser

erlebt, in denen es ein Verhältnis von Supportmitarbeitern zu

Entwicklern von 1:1 gab. Und jeder Softwareentwickler kann

von einem Projekt erzählen, bei dem nach einiger Zeit nur noch

Neuschreiben in Frage kam. Das sind Kosten, die in keinem

Verhältnis stehen zu den Kosten, die mit der Beschäftigung mit

CCD oder vergleichbarem anfallen.

VKSI: Welche Änderungen hat die Einführung von CCD für das

Management? Bzw. kann das Management die Einführung von

CCD unterstützen?

Stefan Lieser: Das Management kann ruhiger schlafen. Schließlich

stehen auch sie in der Schusslinie, wenn die innere Qualität der

Software zu wünschen übrig lässt. Daher sollte eine angemes-

sene innere Qualität im Interesse aller sein. Managementun-

terstützung bedeutet hier zuerst einmal, das absolute Vertrau-

en, dass die Entwickler nach Kräften versuchen, das Beste zu

geben. Dies ist vor allem in der Phase wichtig, in der die Wei-

terentwicklung an den Produkten langsamer voranschreitet.

Die Einführung von CCD ist ein Veränderungsprozess. Solche

Veränderungen bringen es mit sich, dass einige lieb gewordene

Angewohnheiten in Frage gestellt werden, dass eine Zeit lang

Unruhe herrscht. Gerade in dieser Phase muss das Manage-

ment zu den Entwicklern stehen. Und am Ende muss natürlich

Zeit sein, sich mit CCD auseinanderzusetzen. Leider wird die

Weiterbildung von Entwicklern oft als persönliches „Problem“

der Mitarbeiter angesehen. Auch hier kann das Management

also unterstützen.

VKSI: Was kannst Du einem Entwickler ans Herz legen, wenn er

jetzt gleich mit CCD beginnen möchte? Welche Voraussetzun-

gen gibt es?

Stefan Lieser: Zunächst sollte sich ein interessierter Entwickler

einen Überblick über die CCD Initiative verschaffen. Dazu kann

er sich z.B. auf clean-code-developer.de umschauen, dort gibt

es auch zahlreiche Literaturhinweise. Vermutlich werden nicht

alle Bausteine neu für ihn sein, das relativiert den Eindruck,

dass es eine Menge neuesNeues zu lernen gilt. Tja und dann

hilft nur, anfangen! Sich mit den Bausteinen im ersten, dem

roten Grad, vertraut machen und sie über einen Zeitraum von

drei Wochen im Blick behalten. Wer sich mit anderen austau-

schen möchte, kann sich im Kollegenkreis umschauen oder in

der örtlichen Usergroup nachhören ob es dort CCD Interessier-

te gibt. Und natürlich kann in den Foren diskutiert werden. Ich

wünsche viel Erfolg!

Stefan Lieser ist freiberuflicher Berater/Trainer/Autor aus Leidenschaft. Sein Interesse gilt den agilen Methoden der Softwareentwicklung und er sucht ständig nach Verbesserung und neuen Wegen. Bereits während des Informatikstudiums setzte er seinen Schwer punkt im Bereich Software Technik. Über die Jahre hat er sich intensiv mit Patterns und Principles auseinandergesetzt. Dies spiegelt sich auch in seinen zahlreichen Vorträgen wider. Das Interview führt Ralf Schoch, Mitglied des Präsidiums des VKSI und Mitglied der .NET User Group Karlsruhe. Er ist freiberuflicher Soft-wareentwickler im .NET Umfeld und Certified Scrum Product Owner. Sein Schwerpunkt liegt im Bereich der Entwicklung von Webapplikationen, der Verbesserung der Entwicklungsprozesse und der Code Qualität.

,



STANDORT

Karlsruhe war im letzten Jahr mit der 1984 ersten auf deut-

schen Servern empfangenen E-Mail in den Medien zum Thema

Internet präsent. Doch diese Revolution in der Kommunikation

ist längst nicht das einzige Merkmal, das den IT-Standort Karls-

ruhe auszeichnet.

Laut European Cluster Observatory nimmt das IT-Cluster

im europäischen Vergleich hinter Oxford und München Platz 3

ein. Weltweit gibt es elf große Grid-Zentren, die IT-Ressourcen

verknüpfen, um riesige Datenmengen aufzubewahren und zu

verarbeiten. Eines der elf großen Zentren befindet sich in Karls-

ruhe am KIT, wo 16 Petabyte pro Jahr verarbeitet und gespei-

chert werden.

In Karlsruhe wurde auch erstmals das Internet über das

Stromnetz angezapft. Hier steht auch ein Hochleistungsrechen-

zentrum, das hohe Maßstäbe in Europa setzt und mit zentralen

Internet-Knoten in den USA und Europa verbunden ist.

Gerade auch mit seiner führenden Informatikfakultät am

KIT bringt Karlsruhe IT-Experten hervor, die ihr Wissen in den

regionalen IT-Unternehmen und Forschungseinrichtungen

einbringen oder auch selbst ein neues Unternehmen gründen.

Im Bereich der IT-Sicherheit nimmt Karlsruhe eine Vorrei-

terrolle ein. An der Universität Karlsruhe wurde die erste Lehr-

veranstaltung zum Thema IT-Sicherheit gehalten und ebenso

wurde von Karlsruhe aus die erste europäische Expertenkon-

ferenz im Bereich IT-Sicherheit mitinitiiert. Bei der Entwick-

lung neuer Technologien und den damit stets neu anfallenden

IT-Sicherheits-Herausforderungen, werden in Karlsruhe neue

Lösungen gesucht und gefunden.

Die IT als Querschnittstechnologie führt zu Produktivitäts-

steigerungen in zahlreichen Bereichen. So setzen Karlsruher

Ideen Standards für die Geschäftsprozesse in Banken, LKWs

können unter Berücksichtigung ihrer Ladung zielsicher navi-

giert werden und auch intelligente Wohnumgebungen für ältere

Menschen werden mithilfe von IT-Technologien in Karlsruhe

entwickelt. Die Stärke der IT-Branche hat daher einen positiven

Einfluss auf die anderen Branchen, die die Effizienzgewinne

durch den Softwareeinsatz realisieren. Daher ist die IT-Branche

ein wichtiger Wachstumsmotor.

Dank eines von unten natürlich gewachsenen Netzwerks

(„Bottum-up“-Cluster) kann der Technologietransfer von der

Erforschung neuer Techniken bis hin zur Markteinführung

des Produkts leichter von statten gehen. In Karlsruhe werden

die Kontakte zwischen KIT, Hochschule Karlsruhe, dem For-

schungszentrum Informatik (FZI), den Fraunhofer Instituten

sowie kleineren und großen IT-Firmen lebendig genutzt. Dabei

sind – unter anderen – auch das CyberForum, die Karlsruher

IT-Sicherheitsinitiative (KA-IT-Si) sowie die IHK Karlsruhe

ständig aktiv, um das Netzwerk zu erweitern und den Wissen-

stransfer durch Veranstaltungen zu stärken.

Die Informations- und Kommunikationstechnologie prägt

immer stärker unseren Alltag und stellt uns vor neue Heraus-

forderungen. Karlsruhe wird daher immer wieder neue Lösun-

gen finden, in seiner Stärke als IT-Standort weiter wachsen und

damit den Weg tiefer in die vernetzte Welt hinein weiter ebnen.

Ansprechpartner

Dipl.-Vw Birgit Strunck, Telefon: 0721 174-438, E-Mail: [email protected]

Gebündelte Kräfte – starker IT-Standort Karlsruhe

25 Jahre E-Mail in Deutschland



TREND

Eclipse als Java-Entwicklungsumgebung

Zunächst von IBM und ab 2001 als Open Source Projekt unter

der Führung der Eclipse Foundation entwickelt (kostenlos

gemäß der ecliPSe Public licenSe (EPL)), war Eclipse lange

Zeit vor allem als integrierte Entwicklungsumgebung für Java

bekannt. Seit Juni 2009 ist nun die aktuelle Version 3.5 für alle

verbreiteten Plattformen verfügbar (Windows, Linux, Mac).

Erweiterungen für Eclipse

Aufgrund des modularen Aufbaus gibt es für die Eclipse-Platt-

form eine große Anzahl von Erweiterungen (»Plugins«). Damit

eignet sich Eclipse außer für die Entwicklung von Anwendun-

gen in der Java Standard Edition auch für die Enterprise Ver-

sion (JEE), sowie eine Vielzahl weiterer Programmiersprachen

(z.B. PHP, C/C++). Darüber hinaus stehen Erweiterungen

zur Modellierung (EMF) inklusive der Erstellung graphischer

Editoren (GMF), für Reporting (BIRT), den Datenbankzugriff

(EclipseLink) und vieles mehr zur Verfügung. Downloads unter

www.eclipse.org oder http://eclipse-plugins.2y.net (Drittan-

bieter). Die Entwicklung von Plugins wird durch die offene

Architektur der Eclipse-Plattform begünstigt.

Architektur von Eclipse-Plugins

Seit Version 3 basiert Eclipse auf dem dynamischen Java-

Komponentenframework OSGi (oPen Service gateway

initiative) und besteht zunächst nur aus dem leichtgewich-

tigen Kern » ecliPSe equinox«. Eine Anwendung, wie z.B.

die Java-Entwicklungsumgebung selbst, besteht nun jeweils

aus einer bestimmten Zusammenstellung von Plugins. Einem

Plugin in der Eclipse-Terminologie entspricht dabei exakt eine

OSGi Komponente, die auch Bundle genannt wird. Jede Kom-

ponente spezifiziert in ihrer Beschreibungsdatei »MANIFEST.

MF« - neben Versionierungs- und Namenseigenschaften und

der benötigten Laufzeitumgebung - explizit ihre Abhängigkei-

ten zur Außenwelt. Dabei muss einerseits spezifiziert werden,

welche anderen Java-Klassen oder OSGi-Bundles in welcher

Version von der Komponente benötigt werden und anderseits,

welche Java-Pakete von der Komponente an andere exportiert

werden sollen. Diese Metadatei wird anschließend mit den

übersetzten Java-Paketen sowie evtl. weiteren Ressourcen in

ein Java-Archiv (JAR) gepackt. Die Laufzeitumgebung Equin-

ox sorgt dann beim Laden der Komponente zunächst dafür,

dass die benötigten anderen Komponenten geladen werden.

OSGi erlaubt dabei auch das dynamische Laden oder Entla-

den von Bundles. Darüber hinaus kann ein Bundle gleichzeitig

mehrmals innerhalb einer Laufzeitumgebung in verschiedenen

Versionen geladen sein. Dies ermöglicht zumindest theoretisch

die Aktualisierungen von Plugins ohne Neustart der Umgebung

und damit minimale bis keine Ausfallzeiten.

Vor allem bei der Entwicklung von Anwendungen mit grafi-

schen Oberflächen kann durch Verwendung der Eclipse-Platt-

form von vielen bereits vorhandenen Mechanismen aus den

eclipse.ui.* Komponenten profitiert werden. Damit lassen sich

oft mit wenig eigenem Programmcode komplexe und dennoch

komfortable Fensteraufbauten, Menüs usw. im Stil der Eclipse-

IDE erstellen. Besonders stark macht sich dies bei der Imple-

mentierung von Anwendungen aus dem Modellierungsumfeld

bemerkbar. Hier können dank der Eclipse-Modellierungs-Pro-

jekte EMF und GMF recht einfach eigene Modellierungswerk-

zeuge für bestimmte Anwendungsdomänen entwickelt werden.

Mit »server-side equinox« gibt es aber auch bereits Ansätze

dafür, das Equinox-Framework bei Serveranwendungen einzu-

setzen. Trennt man strikt in »für grafische Oberfläche zustän-

dige« und »sonstige« Plugins, lassen sich auf einfache Art und

Weise dieselben Komponenten sowohl Server- als auch Client-

seitig einsetzen. Weiter unten zeigen wir diese Vorgehensweise

beim »HoruS buSineSS modeler«.

HalloRCP – Anwendungserstellung auf Basis von Eclipse-RCP

Die Eclipse-Plattform bietet zwei grundsätzliche Möglichkeiten

zur Anwendungserstellung. Entweder kann ein Plugin in die

(z.T. aus mehr als 1000 weiteren Plugins bestehende) Eclipse-

Entwicklungsumgebung geladen werden oder in Form einer

Eclipse-RCP-Anwendung eine eigenständige Anwendung mit

einer genau definierten Menge an zu ladenden Plugins imple-

mentiert werden. Der Aufbau der einzelnen Plugins unterschei-

det sich in beiden Fällen nicht wesentlich und auch in einer

eigenständigen RCP-Anwendung können bestehende Eclipse-

Plugins problemlos genutzt werden. Zur Entwicklung eigener

Eclipse-Plugins bietet sich die Nutzung der »Eclipse for RCP/

Plug-in Developers«-Variante an, welche bereits alle nötigen

Bestandteile enthält.

Die ersten Schritte zum eigenen Eclipse-Plugin werden

durch den »Plug-in Project Wizard« im Datei-Menü unter-

stützt. Dieser fragt zunächst Basisinformationen wie Name,

Version und Laufzeitumgebung des Plugins ab. Außerdem

unterscheidet er zwischen RCP- und »reinen« Plugin-Pro-

jekten und fragt, ob die Komponente zur grafischen Oberflä-

che beiträgt. Eine einfache grafische RCP-Anwendung kann

im letzten Schritt über die Vorlage »RCP Application with a

view« erzeugt werden. Die grafische Oberfläche von auf Eclipse

basierenden Anwendungen besteht aus einer oder mehreren

Perspektiven, wobei jede Perspektive eine initiale Menge an

»Views« und deren Aufteilung auf der Oberfläche umfasst. Eine

einzelne View unterstützt jeweils eine bestimmte Aufgabe. In

der Entwicklungsumgebung sind beispielsweise der Projektex-

plorer oder die Eigenschaftenanzeige als Views realisiert. Die

generierte Beispielanwendung besitzt genau eine Perspektive

(Perspective.java), welche von der einzigen View (View.java)

Kooperative ProduktentwicklungRich-Client-Anwendungen mit Eclipse RCP von Johannes Michler, PROMATIS software GmbH



voll ausgefüllt wird. Diese View enthält zunächst eine einfache

Liste mit drei Elementen, welche mit den ebenfalls als Plugins

bereitgestellten Basistechnologien (JFace und SWT) imple-

mentiert ist. Über den Eclipse-Erweiterungsmechanismus wer-

den View und Perspektive in der Datei plugin.xml, welche mit

dem in Abb. 1 gezeigten Editor einfach editiert werden kann, im

Basis-Plugin »org.eclipse.ui« registriert. Wie aus der Manifest-

Beschreibung hervorgeht hängt die Beispiel-RCP-Anwendung

damit unter anderem von diesem Plugin ab.

Abb. 1: Plugin-Editor

Ausführen der Anwendung

Zur Ausführung der RCP-Anwendung müssen die zugehöri-

gen Plugins in der Equinox-Laufzeitumgebung registriert und

gestartet werden. Dies kann über »Launch an Eclipse Appli-

cation« auf der Übersichtsseite des in Abb. 1 gezeigten Plugin-

Editors erfolgen. Dabei wird automatisch eine Ausführungs-

konfiguration erzeugt, welche neben dem eigenen »Testplugin«

automatisch die von diesem Plugin in der MANIFEST.MF defi-

nierten abhängigen Plugins enthält. Inklusive geschachtelter

Abhängigkeiten besteht so selbst die minimale HalloWelt-

Anwendung bereits aus 45 Einzelkomponenten.

Der Erweiterungsmechanismus von Eclipse kann durch die

Definition von Erweiterungspunkten auch von eigenen Plugins

verwendet werden. Durch geschickte Zusammenstellung einer

Menge von Plugins ist es möglich, verschiedene Varianten einer

Softwareanwendung aus einer Menge von eigenen und vorhan-

denen Plugins zusammenzustellen.

Anwendungsszenario

Der HoruS buSineSS modeler (siehe Kasten) modelliert

Geschäftsprozesse mithilfe der Eclipse Rich Client Plattform.

Dabei kann zum einen von existierenden Plugins (für grafische

Modellierung, Persistenz, usw.) profitiert werden. Zum ande-

ren erleichtert die Aufteilung des Tools in mehrere lose gekop-

pelte Plugins und die Verwendung der im vorigen Abschnitt

beschriebenen Erweiterungsmechanismen sowohl die verteilte

Entwicklung durch die beteiligten Institutionen als auch fle-

xible Reaktionen auf geänderte oder neue Anforderungen. Oft

können neue Funktionalitäten in einem neuen Plugin (oder

zumindest durch Änderungen an nur sehr wenigen bestehen-

den Komponenten) realisiert werden. Dieses wird zunächst nur

von den an ihm direkt beteiligten Entwicklern aktiviert. Dabei

bleibt es jederzeit möglich, zwischen den Versionen durch

Laden oder nicht Laden des zusätzlichen Plugins zu wechseln

(sowohl für Entwickler als auch für die Erstellung von Beta-

Versionen). Nach Erreichen einer gewissen Reife kann die neue

Komponente schließlich in die Standard-Konfiguration aufge-

nommen werden und steht anschließend für alle zur Verfügung.

Hiermit konnten beispielsweise einfach nachträglich weitere

Persistierungsmöglichkeiten (hier über die JPA-Implementie-

rung EclipseLink) oder Modelltypen mitsamt Editoren hinzu-

gefügt werden.

Eclipse RCP und Karlsruhe

Bei der Entwicklung der Horus Business Process Engineering-

Produkte arbeitet die Horus software GmbH mit einer Reihe

von Innovationspartnern zusammen. Zwei renommierte Karls-

ruher Institutionen konnten für eine Kooperation gewonnen

werden: Das Forschungszentrum Informatik (FZI) und das Ins-

titut für angewandte Informatik und formale Beschreibungs-

verfahren (AIFB) am Karlsruher Institut für Technologie (KIT).

Der Know-how-Gewinn durch die Zusammenarbeit mit diesen

beiden Einrichtungen ist beträchtlich. Aber auch zahlreiche

»Eclipse Demo Camps« und »Eclipse Application Developer

Days« zeugen von der aktiven Eclipse und Eclipse RCP Com-

munity in und um Karlsruhe.

Fazit

Insgesamt ermöglicht der komponentenorientierte Ansatz der

Eclipse-Plattform eine agile und verteilte Entwicklung großer

Rich-Client-Anwendungen. Dazu tragen wesentlich die Mög-

lichkeiten der expliziten Definition von Abhängigkeiten, das

Konzept der Erweiterungspunkte, sowie die große Vielzahl an

einfach verwendbaren Plugins bei.

Johannes Michler studierte Informatik an der Universität Karlsruhe. Nach seinem Diplom im April 2009 ging er als Software-Entwickler und Berater zu Promatis Software GmbH in Ettlingen bei Karlsruhe. Er verantwortet unter anderem den Horus Business Modeler. horus.biz

Horus Business Process Engineering

Mit den Horus Business Process Engineering-Produkten

lässt sich das in einem Unternehmen oder einer vernetzten

Business Community verfügbare Organisationswissen

nutzbar machen. Zur Verfügung stehen frei verfügbare

(Freeware) Modellierungs- und Simulations-Tools sowie

die Enter prise- Produktlinie. Intuitive Bedienelemente,

vorgefertigte Best Practice-Referenzlösungen und die Nut-

zung von Web 2.0-Technologien sorgen für Effizienz und

Qualität. horus.biz



NACHLESE

In eigener Sache

offline. Gute Frage: Warum drucken wir ein Magazin auf

Papier, wo es doch das Internet gibt? Ganz einfach: Weil man

das Internet niemandem in die Hand drücken kann. Das VKSI-

Magazin (das wir aus diesem Grund auf erstklassigem Papier

drucken), soll nicht nur ein optisch sondern auch haptisch

einen Eindruck vermitteln. Zugegeben, das ist nicht neu, dafür

aber sinnlich: Anfassen – das geht online nicht.

online. Frank Schirrmacher, einer der Herausgeber der

»Frankfurter Allgemeine« schrieb unlängst auf der ersten

Seite der FAZ: »Die Informatiker müssen aus den Nischen

in die Mitte der Gesellschaft geholt werden. Sie müssen die

Scripts erklären, nach denen wir handeln und bewertet wer-

den.« Das mit dem Herausholen aus der Nische finden wir

gut. Die Debatte um die Maschinenlesbarkeit der Menschen

führt an dieser Stelle zu weit. Darum hier nur so viel: es muss

auch jemand wissen wollen. Sicherheitshalber betonen wir

also nochmal: Der VKSI hat nichts zu verheimlichen, ganz

im Gegenteil. Unser Vorschlag lautet daher: Googeln Sie den

VKSI, googeln Sie die Mitglieder des Vereins und die Autoren

dieses Magazins, »Software + Karlsruhe + Verein« geht auch,

Sie werden viele interessante weiterführende Informationen

finden.

off- und online. Unser Magazin ist eine Visitenkarte zum

Umblättern. Der Umfang eines Magazins ist naturgemäß

beschränkt. Die Redaktion des Magazins trifft daher eine

Auswahl. Nicht alles können wir unterbringen, dafür geben

wir einen Einblick in das Ökosystem des Karlsruher Software

Engineering. Und wenn Sie Papier so gar nicht mögen, geben

Sie Ihr Exemplar einfach weiter und lesen Sie selber das Maga-

zin online unter www.vksi.de.

feedback. Wie hat Ihnen das Magazin gefallen? Was würden

Sie gerne in der nächsten Ausgabe lesen? Wir freuen uns auf

Antworten an: [email protected].

Herzlich,

Ihre Susann Mathis

ImpressumOrgan des VKSI – Verein der Karlsruher Software-Ingenieure

2. Jahrgang, Heft 2 / Februar 2010

www.vksi.de ISSN 1869-5442

ViSdP.: Dr. Dirk Feuerhelm, Prof. Dr. Ralf Reussner, Prof. August Wegmann

Herausgeber:VKSI – Verein der Karlsruher Software-Ingenieure e.V., www.vksi.de Vorstand: Dr. Dirk Feuerhelm, 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 (Telefon +49 721 38 42 435), www.comm-coop.de, Robert Hartmann, Timm Reinstorf, [email protected]

Gestaltung:Jochen Härtel, Härtel Design, München, www.haerteldesign.de

Druck:E&B Engelhardt und Bauer, Karlsruhe

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 Drit-ter 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 weiter-zugeben, 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 Viel-falt von Software Engineering in Karlsruhe zu vermitteln und die Attrakti-vität des Karlsruher Software-Arbeitsmarktes zu transportieren.

Bildnachweis:David Shyr/Fotolia.com 1; Andreas Geiger S. 5, 24; Jochen Härtel S. 12, 13, 14, 16, 17, 38; Knorpelwerk / TPK S. 37; Tom Kohler S. 4, 6; Susann Mathis S. 3, 5, 9, 29, 30, 37; Stadt Karlsruhe S. 31; Mustafa Yilmaz S. 36

IMPRESSUM



THINGS TO COME

Tutorial Days: 21. / 22. JuniZugesagt: Ken Schwaber (Scrum in Depth, inclusive Master Zertifizierungskurs) Peter Hruschka (Certified Professional for Requirements Engineering)

Agile Day: 23. Juni 2010Keynote: Ken Schwaber »Agile Revisited« Ken Schwaber stellt vor: »Scrum in Depth« und »Scrum Developer«

Conference Day: 24. Juni 2010Tracks: Eclipse | Spring | dot.NET | Multicore

VKSI Day: 25. Juni 2010Tracks: Agile Karlsruhe | Cloud Karlsruhe

OpenSource Karlsruhe | Networking Karlsruhe Abschließende Podiumsdiskussion und Empfang des VKSI

Karlsruher Entwicklertag 2010Software Made in Germany – Strategien für den Entwicklungsstandort DeutschlandAGILITÄT – INNOVATION – QUALITÄT

21. bis 25. Juni 2010

Ken Schwaber kommt

www.entwicklertag.de



RUBRIK

Im Dezember 2009 fand das dritte Karlsruher Eclipse Demo-

Camp statt. Den rund achtzig Teilnehmern aus Wirtschaft

und Forschung bot sich die Gelegenheit, in den Räumen des

Forschungszentrums für Informatik (FZI) neueste Eclipse-

basierte Technologien kennenzulernen. Neben den Präsen-

tationen konnten die Vortragenden ihr Publikum mit Live-

Demos begeistern:

Markus Tiede

●● Mit seinem Vortrag über die Tücken plattformübergrei-

fender GUI-Tests eröffnete Markus Tiede (Bredex GmbH)

den Abend. Er stellte fest, dass Unterschiede zwischen den

Zielplattformen bereits während der Testplanung sowie bei

der Auswahl der GUI-Testwerkzeuge berücksichtigt werden

müssen.

●● Im Anschluss führte Klaus Krogmann vom Karlsruher

In stitut für Technologie (KIT) das im Rahmen EU-Projekts

»Q-ImPrESS« entstandene Werkzeug SoMoX (Software

Model eXtractor) vor. SoMoX soll automatisches Reverse

Engineering von Software-Architekturen ermöglichen.

●● Markus Knauer von EclipseSource demonstrierte in einer

Live-Demo wie eine OSGI-basierte Anwendung in wenigen

Schritten in einer Cloud-Umgebung zum Laufen gebracht

werden kann. Er stellte fest, dass durch die Verwendung des

Werkzeugs g-Eclipse anbieterspezifische Unterschiede wei-

testgehend vor dem Entwickler verborgen werden können.

●● Anschließend wurde das Open-Source-Projekt ‚Usus‘ von

seinen Initiatoren Leif Frenzel, Nicole Rauch und Stefan

Schürle (andrena objects ag) vorgestellt. In einem kleinen

Schauspiel zeigten sie, wie Usus auf Metriken basierende

Qualitätsindikatoren berechnet und Softwareentwickler bei

ihrer täglichen Arbeit unterstützt.

●● Johannes Michler (Horus Software GmbH) und Thomas

Schuster vom FZI präsentierten ein auf Eclipse RCP basie-

rendes Werkzeug, welches die kooperative Modellierung von

Geschäftsprozessen über Unternehmensgrenzen hinweg

ermöglicht.

Nicole Rauch, Stefan Schürle

Leif Frenzel

●● Anhand eines fiktiven Szenarios, in dem es um zentralisiertes

Deployment von Software auf die Fahrzeuge eines Trans-

portunternehmens ging, stellte Benjamin Muskalla von

EclipseSource vor, wie verschiedenste Eclipse-Technologien

wie Equinox, RAP, EclipseLink, BIRT und Riena miteinander

kombiniert und verwendet werden können.

●● Im letzten Vortag des Abends präsentierte Igor Novakovic

(Empolis GmbH) das Eclipse-Projekt SMILA (SeMantic

Information Logistics Architecture), welches die automati-

sche Extraktion von Ontologien aus unstrukturierten Daten

ermöglicht.

Das Karlsruher Eclipse DemoCamp wird seit 2007 in regel-

mäßigen Abständen von der andrena objects ag, EclipseSource

und dem FZI organisiert. Gefördert wird die Veranstaltung

von der Eclipse Foundation. — Mustafa Yilmaz

Karlsruher Eclipse DemoCamp

BERICHT



BERICHT

BOGY ist das Kürzel für den Prozess

der Berufs- und Studienorientierung

an den allgemein bildenden Gymna-

sien in Baden-Württemberg und gibt

frühzeitig Hilfestellungen für die spä-

tere Berufswahl. Das BOGY-Praktikum

wurde für Schülerinnen und Schüler der

Jahrgangsstufen 10-13 in G9 bzw. der

Jahrgangsstufen 9-12 in G8 in Baden-

Württemberg in das Curriculum aufge-

nommen.

2009 fanden in Zusammenarbeit

der Informatikfakultät des KIT mit dem

Technologiepark und verschiedenen

Karlsruher IT-Unternehmen Orien-

tierungswochen für Schülerinnen und

Schüler im IT-Bereich statt. Ziel der

Aktion ist es, die Jugendlichen frühzeitig

für die Informatik zu interessieren und

Vorurteile abzubauen.

Das Konzept bogy@tpk ist auf große

Resonanz gestoßen und soll 2010 in

neuer, breiter angelegter, Form fortge-

führt werden. Es soll vor allem gelingen,

das Bogy-Konzept für noch mehr IT-Fir-

men attraktiv zu machen. Das erweiterte

Konzept heißt: informatikBOGY.

Träger: KIT / Fakultät für Informa-

tik; in das einwöchige Programm sind

Exkursionen zu Industrie-Partnern inte-

griert. Der VKSI koordiniert die Indus-

trie-Partner. Schüler und Schülerinnen

bewerben sich bei [email protected].

Interessenten aus der Industrie können

sich wenden an [email protected] — Tatiana

Rhode

Vielleicht sollte ich mich zuerst einmal vorstel-

len: Mein Name ist Chiang Mai und ich bin ein

Poken. Falls Ihr meine Rasse noch nicht kennt:

Wir sind sehr schicke elektronische Visiten-

karten, die man um den Hals tragen kann. Das

Beste an uns ist unser phänomenales Namens-

gedächtnis.

Von einem tollen Erlebnis möchte ich hier

berichten: Vom 26. bis 28. November fanden in

Karlsruhe die xP dayS germany 2009 statt.

An dieser Konferenz durfte ich zusammen mit

vielen weiteren Pokens zum ersten Mal teilneh-

men. Jeder meiner Artgenossen war Begleiter

eines menschlichen Konferenzteilnehmers

und konnte sich drei Tage lang viele interessante Vorträge über

Agile Software Entwicklung und Extreme Programming anhö-

ren, andere Pokens treffen, Kontaktdaten austauschen und den

Teilnehmern bei vielen Gesprächen und Diskussionen zuhören.

Warm-Up Day: Nach zwei Tutorials am Vormittag starte-

te die eigentliche Konferenz um 14:00 Uhr. Schon 150 Kon-

ferenzteilnehmer konnten sich an zahlreichen Vorträgen in

verschiedenen Formaten erfreuen: Rasante Pecha Kucha Ses-

sions – von den Teilnehmern mit begeistertem Applaus belohnt

– wechselten sich mit ein- und halbstündigen Vorträgen und

Präsentationen ab. Agile Werte und Praktiken, Scrum und zwi-

schenmenschliche Beziehungen in Teams sowie Technologien

und Tools bildeten das Themenspektrum. Ein weiteres High-

light des ersten Tages war die unterhaltsame Pausen-Session

»TDD mit den Stars«. Vier Teams stellten in

je fünf Minuten ihr Können unter Beweis und

wurden anschließend von einer sehr strengen

Jury und dem Publikum bewertet.

Der zweite Tag, der sogenannte Conference-

Day, begann schon früh am Morgen mit Vor-

trägen in vier parallelen Tracks. Weitere 100

neue Teilnehmer komplettierten die Konfe-

renz, die mit insgesamt mehr als 250 Anmel-

dungen mehr als 2 Wochen vorher ausgebucht

war. Und das Feedback gab den Veranstaltern

(andrena objects und it-agile) und dem Pro-

grammkomitee Recht: Sehr viele interessante

Vorträge, zwei weitere Pecha Kucha Sessions

und das Finale von TDD mit den Stars führten zu einer sehr

guten Bewertung der Gesamtkonferenz. Nicht zu vergessen der

kleine Höhepunkt des Tages mit der Keynote von Alistar Cock-

burn: »Hard-Agile: Effective Software Development in the 21st

Century«.

Am Samstag dem letzten Tag der Konferenz fand ein Agile

Future Café statt und es blieb viel Zeit für spannende Diskus-

sionen während des Open Space. Für das Knüpfen von Kontak-

ten und viele nette Unterhaltungen boten auch die Abendveran-

staltungen der ersten beiden Tage Raum.

Voll mit lauter neuen Kontakt daten und glücklich über die

zufriedenen Gesichter unser menschlichen Begleiter zogen wir

Pokens ein durchweg positives Resultat aus dieser Konferenz.

— Franziska Widmaier

XP Days 2009

informatikBOGY

BOGY hilft Schülern bei der Berufswahl.

Poken »Chiang Mai«



VEREIN

Karlsruher Entwickler tag 2009 und Karls ruher Manifest für Software Engineering

VKSI Mitglieder versammlung, Sneak Preview und Weih nachts feier

Am Karlsruher Entwicklertag vom

22. Juni bis zum 27. Juni nahmen über

600 Besucher teil. Die Konferenz wid-

mete sich dem Thema »Software Made

in Germany – Strategien für den Ent-

wicklungsstandort Deutschland«.

Auf der Auftaktveranstaltung, dem

vom Verein der Karlsruher Software-

ingenieure e.V. (VKSI) gestalteten

»VKSI Day« stellten die Initiatoren das

Karlsruher Manifest für Software Engi-

neering vor über 200 Besuchern aus

Industrie und Hochschulen vor.

»Software wird in Deutschland weder

als Primärbranche, noch als Sekundär-

branche ausreichend wahrgenommen.

Die Bedeutung der Software-Branche ist

in Deutschland aber mit der des Automo-

bilbaus vergleichbar« erläuterte Profes-

sor Reussner, Lehrstuhlinhaber am KIT

und einer der Initiatoren des Karlsruher

Manifests seine Beweggründe. Matthias

Grund, Vorstand des Karlsruher Soft-

ware-Spezialisten andrena objects ag

ergänzte: »Wir finden in der industriel-

len Praxis immer wieder Software vor,

die bei Design und Codierung weit hin-

ter dem Stand der Technik zurückliegt.

Das liegt daran«, so Matthias Grund,

»dass Software Engineering zu wenig

Beachtung findet. Das verursacht eine

gewaltige Verschwendung von Geld und

Arbeitskraft.«

Mitglieder des VKSI mahnen bei

der Industrie mehr Aufmerksamkeit

für den Stand der Technik an, fordern

eine bessere Ausbildung und lebens-

langes Lernen für Software-Ingenieure

und wollen Schülerinnen und Schüler

für den Beruf des Software-Ingenieurs

begeistern.

Der Verein der Karlsruher Software-

Ingenieure e.V. hatte zuvor gemeinsam

mit der Fachzeitschrift »OBJEKTspek-

trum eine Umfrage zum Thema »Wie

steht es um die Ausbildung unse-

rer Softwareingenieure?« durchge-

führt. Jens Coldewey, der Chefredak-

teur des OBJEKTspektrum, hat die

ersten Ergebnisse auf dem VKSI Day

vorgestellt. Coldewey warnte: »Wenn

wir weiter in der Weltspitze mitmi-

schen wollen, brauchen wir eine neue,

intensive Diskussion über Inhalte und

Formate der Informatikausbildung!«

Den vollständigen Wortlaut des Mani-

fests finden Sie unter vksi.de/manifest

Am 15. Dezember 2009 wurde zur VKSI

Mitgliederversammlung und zur ersten

‚Sneak Preview‘ des VKSI ins FZI eingela-

den. Mit diesem besonderen Format gibt

der VKSI seinen Mitgliedern Einblicke

in aktuelle Entwicklungen aus der Regi-

on Karlsruhe. Diesmal präsentierte Dirk

Feuerhelm den Mitgliedern – anhand

des DSL-HomeNet Projekt der 1&1 AG –

die Zukunft des Internets und die erfolg-

reiche Orchestrierung aller mobilen und

multimedialen Geräte.

Im Anschluss wurde die ordentli-

che Mitgliederversammlung des VKSI

durchgeführt. Mit einer Rückschau

auf die vergangenen Jahre 2008, dem

Gründungsjahr des VKSI und dem Jahr

2009 wurde deutlich, was der Verein bis-

her geleistet hat. Neben der Gründung

und der Beantragung der Gemeinnützig-

keit im Jahr 2008 wurde im Jahr 2009

das erste VKSI Magazin veröffentlicht

und der VKSI-Day im Rahmen des Karls-

ruher Entwicklertags gestaltet. Der Vor-

stand Prof. Dr. Ralf Reussner, Dr. Dirk

Feuerhelm und Prof. August Wegmann

sprachen allen freiwilligen Helfern den

Dank aus. Nach dem Kassenbericht 2008

und dem vorläufigen Kassenbericht

2009 wurde der Vorstand für das Jahr

2008 mit drei Enthaltungen und ohne

Gegenstimmen entlastet.

Die weiteren Ziele und Aufgaben des

Vereins für das Jahr 2010 umfassen

neben der hier vorliegenden zweiten Auf-

lage des VKSI Magazins den VKSI-Day

beim Entwicklertag 2010 und die Umset-

zung des berufsorientierten Praktikums

für Gymnasiasten (BOGY). Die ‚Sneak

Preview‘ wird in einem definierten

Rhythmus fortgeführt.

Auf der anschließenden Weihnachts-

feier konnten sich die VKSI Mitglieder

austauschen. Das Fazit der Redaktion

und der VKSI Mitglieder über die gelun-

gene Mitgliederversammlung ist sehr

positiv, so dass wir beherzt ins Jahr 2010

starten. — Robert Hartmann

Jens Coldewey, Dr. Dirk Feuerhelm, Prof. Dr. Andreas Oberweis, Matthias Grund, Heidi Kupke,

Prof. Dr. Ralf Reussner vor dem Karlsruher Manifest für Software Engineering



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




Powering your decisionsWissen aufbauen,

Informationsvorsprung vergrößern,

Entscheidungen unterstützen –

mit Energie und Know-how entwickeln wir

maßgeschneiderte Lösungen für

Energieerzeuger, Energiehändler

und Netzbetreiber.

www.seven2one.de

Seven2one-Ad.indd 3 02.02.2010 18:33:09VKSIMagazin-1002-08.indd 40 03.02.2010 17:09

Documents

VKSI-Magazin #2