20 – 22 September 2010 Dresden, Germany - SQ-Magazin Wer hätte gedacht, dass Raben und Kakerlaken...

20 – 22 September 2010Dresden, GermanyMARITIM Hotel & International Congress Center

© J

oche

n K

– Fo

tolia

.com

Ausgabe 16 | September 2010

Arbeitskreis Software-Qualität und -Fortbildung e.V.

Arbeitskreis Software-Qualität und -Fortbildung e.V.

Freier Eintritt: ASQF Mitglieder kostenlos zur CONQUEST

Im Fokus: Projektmanagement

Prominenter Schwung: Golfturnier mit vielen Stars

KOSTENFREIES CONQUEST-Tagesticket

für ASQF-Mitglieder

KOSTENFREIES CONQUEST-Tagesticket


http://www.conquest-conference.de

www.asqf.de

Kurfü

rste

ndam

m, B

erlin

© K

atrin

Sch

ülke

Schulungen mit Aussicht

Inhouse-Schulungen weltweit auf Deutsch, Englisch, Spanisch

und Französischhttp://training.diazhilterscheid.com/

[email protected]

“Ein lockerer Vortragsstil von Herrn Lieblang, dazwischen trockene, einprägsame Kommentare. Dementsprechend hoch war meine Aufmerksamkeit. Bei dieser Vorbereitung war die Prüfung leicht.”

Mirko Goßler, T-Systems Multimedia Solutions GmbH

“Danke für die kurzweilige Einführung in ein komplexes Thema und die gründliche Vorbereitung auf die Zertifizierung. Wer hätte gedacht, dass Raben und Kakerlaken so wichtig für das Softwaretesten sein können ...”

Gerlinde Suling, Siemens AG

- Änderungen vorbehalten -

06.09.10-10.09.10 Certified Tester Advanced Level – TECHNICAL TEST ANALYST Berlin13.09.10-16.09.10 Certified Tester Foundation Level Berlin04.10.10-07.10.10 Certified Tester Foundation Level Berlin11.10.10-13.10.10 Certified Tester Foundation Level – Kompaktkurs Hannover11.10.10-15.10.10 Certified Tester Advanced Level – TESTMANAGER München18.10.10-19.10.10 Testen für Entwickler Berlin19.10.10-21.10.10 Certified Tester Foundation Level – Kompaktkurs Frankfurt25.10.10-29.10.10 Certified Tester Advanced Level – TEST ANALYST Stuttgart26.10.10-28.10.10 Certified Professional for Requirements Engineering – Foundation Level Berlin02.11.10-05.11.10 Certified Tester Foundation Level München08.11.10-12.11.10 Certified Tester Advanced Level – TEST ANALYST Berlin15.11.10-18.11.10 Certified Tester Foundation Level Berlin22.11.10-26.11.10 Certified Tester Advanced Level – TESTMANAGER Frankfurt29.11.10-30.11.10 Testen für Entwickler Berlin01.12.10-03.12.10 Certified Professional for Requirements Engineering – Foundation Level Berlin07.12.10-09.12.10 Certified Tester Foundation Level – Kompaktkurs Düsseldorf/Köln13.12.10-17.12.10 Certified Tester Advanced Level – TESTMANAGER Berlin

SQ_Magazin_dh07_10_deA4.indd 2 09.07.2010 14:18:41

Kurfü

rste

ndam

m, B

erlin

© K

atrin

Sch

ülke




[email protected]








http://www.spice-days.com

http://www.spice-days.com

http://training.diazhilterscheid.com

Bürokratieabbau ist eine erstrebens-werte Zielsetzung – an einigen Stellen sogar der zusätzliche Treibstoff für un-seren Wirtschaftsmotor. Doch wenn ich einen Diesel fahre, dann brauche ich kein Benzin. Ähnlich verhält es sich mit dem Verfahren zum elektronischen Ent-geltnachweis ELENA. Seit dem 1. Janu-ar sind die Arbeitgeber verpflichtet, die Entgeltdaten ihrer Beschäftigten an eine bei der Deutschen Rentenversicherung angesiedelte zentrale Speicherstelle zu übermitteln. Mit einem Kosteneinspa-rungspotenzial von 500 Mio. € gestar-tet, rechnet das Wirtschaftsministerium

derzeit nur noch mit einem Potenzial von 87 Mio. € – und geht dabei davon aus, dass die Entlastung doch nur größeren, aber kaum kleineren Unter-nehmen zugute komme. Technisch unausgereift, zeitlich stark belastend und datenschutzrechtlich mehr als fragwürdig, so kann man das Ergebnis nach einem halben Jahr ELENA aus Sicht des Mittelstandes beschreiben. Für mich weist ELENA den klassischen Projektfehler auf: Es wurde am Kunden – vor allem am Mittelstand – vorbei entwickelt. Dass Wirtschafts-minister Rainer Brüderle nun darüber nachdenkt, ein Moratorium gegen-über ELENA zu verhängen, sollte uns nicht davon abhalten, das Projekt dennoch in die richtige Richtung zu entwickeln.

Eine Gelegenheit zum Erfahrungsaustausch auch darüber bietet sich schon Mitte September. Die CONQUEST 2010 ist zu Gast in Dresden und das noch bevor der nationale IT-Gipfel dort tagt. Vom 20. bis 22. September lade ich Sie ein zu einem intellektuellen, praxisnahen, kreativen, zukunfts-weisenden, trendsaufspürenden, austauschgeprägten Miteinander auf der CONQUEST 2010. Und für alle ASQF-Mitglieder gilt: Sie erhalten ein kostenfreies 1-Tages-Ticket.

Schließlich lade ich Sie herzlich zu einem weiteren Höhepunkt im Herbst ein: Auf dem ASQF-Golf-Cup am 30. Oktober sammeln wir in diesem Jahr zusammen mit dem Van der Valk Hotel Berliner Ring für einen wohltätigen Zweck. Prominente Golfer wie Jan-Josef Liefers, Anna Loos, Axel Schulz, Lars Riedel und viele andere helfen uns dabei.

Ich freue mich auf Sie!

Ihr Stephan Goericke.

Liebe Freunde des ASQF

Editorial

Stephan Goericke, Geschäftsführer ASQF e.V. und iSQI GmbH

Kurfü

rste

ndam

m, B

erlin

© K

atrin

Sch

ülke




[email protected]








3 Ausgabe 16 | September 2010

3 Editorial

4 ASQF-News- Neu: Medical Device Day in Erlangen- Rückblick: Agil im Projektmanagement- Ausblick: heißer Herbst mit drei ASQF-Days

5 iSQI-News- Punktabzug: IREB „Require-

ments Engineering“-Standard mit neuem Lehrplan

- Neu im iSQI Portfolio: Der ISEB Intermediate in Software Testing

6 Im Fokus: CONQUEST6 Test Maturity Model integrated

(TMMi) als Modell zur Prozess-verbesserung

8 Dr. Jekyll and Mr. Hyde – Die zwei Seiten von Requirements Engineering

10 Erfolgsfaktoren für die MBT-Einführung

12 Programm - CONQUEST 2010

14 Kolumne: Outsourcing - Gefahr oder Chance für Tester?

15 International SPICE Days 2010 – Reflektionen

16 Ein Code für alle Fälle – Wie Au-tomobilhersteller durch Software im Fahrzeug flexibel bleiben

18 Interview: mit G. Ó Súilleabháin

26 Im Fokus: Projektmanagement26 Agilität und Verteilte Entwicklung28 Der Migrationstest-Prozess30 Wie man agiles Vorgehen nach

Scrum mit dem V-Modell XT kombiniert

36 „Software Quality“ in Dresden

37 Im Fokus: Medizintechnik37 Der Software-Lebenszyklus für medizinische Geräte39 Medizinische Software agil entwickeln40 Dank RE für den Weltmarkt ent-

wickeln – trotz Normenvielfalt

42 Mitglieder 6. Berlin-Brandenburger Golfers-Cup

43 Quiz

44 Fachgruppen-Termine

INHALT

Mit dem Medical Device Day (MDD) hat der ASQF eine weitere Ganztages-veranstaltung in sein Programm aufgenommen. Unter dem Motto „Komple-xität beherrschen“ laden der ASQF und der Spitzencluster Medical Valley EMN am 16.09. zum Erfahrungsaustausch im hochkomplexen Umfeld „Me-dizinprodukte“. Die insgesamt neun Fachreferenten beschäftigen sich dabei mit der Komplexität im technischen Projektmanagement sowie der Kom-plexität in den Medizinprodukten selbst. www.asqf.de/medical-device-day

30. SEPTEMBER, Ludwigsburg: 2. Baden-Württemberg Testing-DayUnter dem Motto „Test the Best“ lädt die Fachgruppe Software-Test Ba-den-Württemberg zum zweiten Testing-Day nach Ludwigsburg ein.07. OKTOBER, Frankfurt: 4. Rhein-Main Testing-DayDer 4. Rhein-Main Testing-Day steht wieder unter dem Leitsatz „Aus der Praxis für die Praxis“. Referenten berichten aus ihrem Praxisalltag und dis-kutieren mit den Teilnehmern. 26. OKTOBER, Nürnberg: 19. Automation Day NürnbergWie die Automatisierung im Jahr 2015 aussieht, das erfahren Interessierte auf dem 19. Automation Day am 26.10.2010 in Nürnberg. Unter der Leitung des neuen FG-Leiters Michael Sperber konnte zusammen mit dem Auto-mation Valley Nordbayern wieder ein hervorragendes Programm erstellt werden. www.asqf.de/automation-day.

Ein attraktives Thema hatte die Fachgruppe Projektmanagement für ihren 2. Project Management Day Franken gewählt. Unter der Spitze des Fürther Hotels Pyramide kamen nahezu 150 Fachleute zusammen. Die Erwartun-gen wurden dann auch mehr als erfüllt, hatte doch schon die Keynote von Michael Heinold mit dem Thema „ Agile Transition“ mitten in die Thematik hineingeführt. Neben Requirements Engineering als Fundament des Pro-jekterfolgs und den Do’s and Dont’s bei der Einführung von SCRUM wurden die Möglichkeiten der Projektvorhersage unter den Bedingungen der nicht-linearen Zukunft diskutiert und durch sehr praxisnahe Berichte über Erfah-rungen mit Agilität bei verteilter Entwicklung ergänzt. Zum Abschluss packte Martin Heider zusammen mit dem Auditorium seinen „agilen Koffer“ – ein guter Begleiter für jeden agilen Projektmanager. Das Feedback zum PM-Day war durchweg positiv – Teilnehmer und Fachgruppenleiter waren begeistert.

Neu: Medical Device Day in Erlangen

Ausblick: heißer Herbst mit drei ASQF-Days

Rückblick: Agil im Projektmanagement

Angefordert: Fachgruppe Requirements Engineering

Die ASQF-Fachgruppen bekommen Zu-wachs. Mit dem Thema „Requirements Engineering“ erschließt der ASQF in den Regionen Franken und Berlin/Branden-burg ein weiteres Fachgebiet der Quali-tätssicherung. Für die Fachgruppenleiter ist RE dabei nicht als isolierte Disziplin zu betrachten, sondern als integrativer Be-standteil und als Voraussetzung für die Verbesserung von Softwarequalität.Mit Herrn Heiko Köppen (Avenqo GmbH) und Frau Chris Rupp (SOPHIST GmbH) hat der ASQF zwei erfahrene RE-Experten für die FG-Leitung gewonnen. Die Fachgruppe startet am 11.11.2010 in Berlin mit dem Thema: „Die Anwendung von User Stories im RE - Methoden & Erfahrungen“.www.asqf.de/requirements-engineering

Zuwachs: Neue Mitglieder

- artundweise GmbH, Bremen, www.artundweise.de- AVL Software and Functions GmbH, Regensburg, www.avl.com - Dräger Medical AG & Co. KG, Lübeck, www.draeger.com - Elementhes GmbH, Kirchheim unter Teck, www.elementhes.de - GFB Softwareentwicklungsgesellschaft mbH, Oberursel, www.gfb-softwareentwicklung.de - Hella Electronics Engineering GmbH, Regensburg, www.hella.com - KUGLER MAAG CIE GmbH, Kornwestheim, www.kuglermaag.com - microTool GmbH, Berlin, www.microTOOL.de - nubix software-Design GmbH, Dresden, www.nubix.de - SYSTECS Informationssysteme GmbH, Leinfelden-Echterdingen, www.systecs.com - VIPA GmbH, Herzogenaurach, www.vipa.de

NEWS ASQF Ausgabe 16 | September 2010 4

Bis zu 150 Teilnehmer kamen zum 2. PM-Day in die Fürther Pyramide

iSQI NEWS

Das International Requirements Engineering Board (IREB e.V.) hat zum 01. September 2010 eine überarbeitete Version des Lehrplans zum „Cer-tified Professional for Requirements Engineering“ veröffentlicht. Einherge-hend mit dem neuen Lehrplan ändern sich auch die Prüfungsordnung und das Bewertungsschema. Falsch gegebene Antworten werden dann mittels Punktabzug in die Bewertung einbezogen.

Die neuen Dokumente stehen auf www.certified-re.de zum Download zur Verfügung. Neben der Datei zur neuen Prüfungsordnung stehen zwei Datei-en zum neuen Lehrplan zur Verfügung, bei denen eine im Änderungsmodus das schnelle Auffinden der Neuerungen im Vergleich zum bisherigen Lehr-plan ermöglicht.

Informationen zu IREB-Schulungsterminen, Öffentlichen Prüfungen und E-Exam in diesem Heft und auf www.isqi.org. Fragen können Sie gern unter der Kontaktadresse [email protected] stellen.

Das ISEB Intermediate Certificate in Software Testing ist die Ergänzung der Zertifizierungsmöglichkeiten für Software-Tester, die bereits den ISTQB Certified Tester Foundation Level abgelegt haben.Während der ISTQB Certified Tester zum einen auf dem Foundation Level basiert und zum anderen in der Advanced Level Stufe auf Spezialisierung setzt, verfolgt ISEB einen stärker differenzierenden Ansatz. So gibt es ne-ben Foundation- und Advanced Level, den Intermediate, der allerdings un-abhängig vom ISTQB ist.

Voraussetzung hierfür sind neben Foundation Zertifikat und Schulung, eine 18-monatige Berufserfahrung, da viele Inhalte der Intermediate-Schulung einen starken Praxisbezug aufweisen.Inhaltlich baut der Intermediate-Syllabus logisch auf dem Foundation Level auf und ergänzt das Wissen der Teilnehmer u.a. in den Bereichen: Testing and Risks, Test Management und Test Analysis. Dadurch wird der Teilneh-mer optimal auf weiterführende Zertifikate vorbereitet.Zahlreichen Anfragen von Kunden nach einer Zertifizierung zwischen dem etablierten ISTQB Foundation- und Advanced Level, waren für das iSQI mehr als Grund genug, das weltweit bereits sehr erfolgreiche ISEB Interme-diate Certificate in Software Testing in das vorhandene iSQI-Portfolio mit aufzunehmen und damit die Zertifizierungsmöglichkeiten im Bereich des Software-Testens abzurunden.

Das Intermediate-Exam ist bereits pc- und papiergestützt im Einsatz und kann jederzeit gebucht werden. Bei Interesse, auch hinsichtlich Schulungs-terminen, können Sie sich gerne jederzeit an die Zertifizierungsabteilung des iSQI wenden.

Neu: Öffentliche Prüfungen jetzt auch in Stuttgart

Aufgrund der hohen Nachfrage nach öffentli-chen Prüfungen im Südwesten Deutschlands bietet das iSQI ab sofort einmal monatlich eine öffentliche Prüfung in Stuttgart an. Es werden alle iSQI-Zertifizierungen angeboten, sofern nicht eine vorhergehende Schulung nötig ist. Die folgenden Termine eignen sich beson-ders für Wiederholer und Autodidakten:• 23.09.2010• 22.10.2010• 18.11.2010• 16.12.2010

Bei Interesse wenden Sie sich bitte direkt an unsere Assistentin der Zertifizierungsstelle, FrauHelbig([email protected]/Tel.:0331231810-29).

International: iSQI zu Gast in Riga

iSQI war im Juli beim Internationalen IT-Forum in Riga, Lettland, mit zwei Vorträgen vertreten. Stephan Goericke, Director des iSQI, hat vor dem interessierten Publikum zunächst über die „Latest Trends in IT Certifi-cation“ referiert. Am letzten Konferenztag, der dem in Lettland recht neuen Thema „Busi-ness Analysis“ gewidmet war, sprach er über eine der Schlüsseldisziplinen der Software-Entwicklung: Requirements Engineering. Neben der regelmäßigen Zertifizierung nach dem ISTQB-Standard in Lettland wird iSQI nun auch dem neuen Interesse nachgehen und die international anerkannte IREB-Zerti-fizierung anbieten.

Punktabzug: IREB „Requirements Engineering“-Standard mit neuem Lehrplan

Neu im iSQI Portfolio: Der ISEB Intermediate in Software Testing


Einleitung – Warum messbare und referenzierbare Prozessverbesserung?Effiziente und effektive Prozesse bilden den Rahmen je-der erfolgreichen Testing-Organisation. Jedoch kommt es häufig vor, dass die tatsächliche Reife dieser Prozesse und ihr Durchdringungsgrad in den Abteilungen und Projekten nicht transparent oder messbar sind. Vielmehr können Fra-gen zur Qualitätsverbesserung wie “Wo fange ich bei mei-nem Verbesserungsvorhaben an?” und “Wie messe ich, ob die Verbesserungen auch tatsächlich wirksam sind?“ nicht beantwortet werden. Oftmals werden Strategiepapiere und Prozessmodelle erarbeitet, die dann aber nicht zu den ge-wünschten Veränderungen führen. Eine Vielzahl erhältlicher, jedoch proprietärer oder an einzelne Personen geknüpfter Prozessverbesserungsmodelle für Software Testing führt zudem zu Konfusion und wirkt wenig zielführend.

Entwicklung TMMi als ReferenzmodellDas Testing Maturity Model Integrated (TMMi) dient einer transparenten, offenen und standardisierten Beschreibung von Prozessen im Bereich Software Testing. Die Ursprün-ge gehen auf die Arbeit des Illinois Institute of Technology zurück. Das Modell wurde 2004 von der TMMi Foundation, einer not-for-profit-Organisation mit Sitz in Irland, mit dem Ziel übernommen, einen international akzeptierten TMMi-Standard sowie ein Bewertungsschema für die Reifegrad-analyse von Testprozessen zu schaffen.

Die TMMi Foundation wird dabei von zahlreichen Part-nern aus Industrie und Forschung unterstützt. Die je-weils aktuelle Fassung des Referenzmodells ist frei unter www.tmmifoundation.org verfügbar. Die Weiterentwicklung dieses Modells ist ein kollaborativer Prozess. So arbeitet aktuell ein Team bestehend aus Vertretern von Accenture, AppLabs, Cognizant, Experimentus, Hong Kong Polytech-nic University, Improve QS, SysQA und Wipro an der Fertig-stellung der Maturity Level 4 und 5 (geplant zum Dezember 2010). Jeder ist eingeladen, der TMMi Foundation als indi-viduelles Mitglied beizutreten und so an der Weiterentwick-lung des Modells mitzuarbeiten. Überblick TMMi Der TMMi-Standard beschreibt die Evolution einer Testor-ganisation über fünf aufeinander aufbauende Level unter-schiedlicher Reifegrade. Wird ein neuer Level erreicht, so dokumentiert dies eine deutliche Verbesserung innerhalb der Organisation. Gleichzeitig wird damit die Grundlage ge-schaffen, um auf den folgenden Level springen zu können. Hierzu enthält TMMi Methoden, welche die Organisation anleitet, sich Schritt für Schritt weiterzuentwickeln.

Die fünf Reifegrade des TMMiBefindet sich eine Organisation auf dem untersten Level 1 (Initial) des TMMi-Standards, so ist kein fixer Testpro-zess definiert. Vielmehr wird der Test häufig als Teil des Debuggings betrachtet. Das Testen geschieht in der Regel ad-hoc und läuft zudem unstrukturiert und ungesteuert. Auf Level 2 (Managed) ist der Test bereits ein kontrollier-ter Prozess und hebt sich deutlich vom Debugging ab. Es existieren Teststrategien und das Testvorgehen wird durch eine Richtlinie vorgegeben, geplant und überwacht. Der Testumfang beschränkt sich allerdings weitestgehend auf den funktionalen Test. Ist ein Test vollständig in den Softwareentwicklungszyklus eingebettet und wird nicht mehr nur als eine auf die Programmierung folgende Phase betrachtet, dann befindet sich eine Test-Organisation auf Level 3 (Defined). Bei Erreichen dieses Reifegrades sind die Testprozesse organisationsweit standardisiert, jeweils von einer allgemeingültigen Testrichtlinie abgeleitet und schließen auch nicht-funktionale Tests mit ein. Auf Level 4 (Management and Measurement) wird zusätzlich die Qualität und die Prozesseffizienz mit statistischen Me-thoden über den gesamten Softwareentwicklungszyklus gemessen und der Testprozess anhand der Messergeb-nisse gesteuert. Befindet sich eine Testorganisation auf Level 5 (Optimization), ist der Testprozess vollständig in das Qualitätsmanagement eingebettet und wird laufend verbessert. Der Test beschränkt sich dabei nicht nur dar-auf, Fehler zu finden, sondern versucht nun auch, Fehler proaktiv zu vermeiden.

Für die Level 2 bis 5 definiert der TMMi-Standard ferner un-terschiedliche Prozessgebiete pro Level, deren Einhaltung anhand der „spezifischen Ziele“ gemessen werden kann.

„Spezifische Verfahrensweisen“ („Specific Practices“) un-terstützen beim Erreichen der Ziele. Jede Verfahrensweise

Test Maturity Model integrated (TMMi) als Modell zur Prozessverbesserung Matthias Rasking und Simon Lamers

Im Fokus

Matthias RaskingSimon Lamers

Ausgabe 16 | September 2010 6

Session C1, 1.3 Dienstag, 21. Sept.


in TMMi ist mit typischen Arbeitsergebnissen und Prozess-schritten versehen und wird anhand anschaulicher Beispie-le erklärt, so dass die Prozessverbesserung mit konkreten Aktivitäten geplant werden kann. Hierbei lohnt sich der Auf-bau eines unternehmensspezifischen Glossars (zum Bei-spiel auf Basis des ISTQB-Glossars), um die Fachbegriffe in TMMi für die Beteiligten verständlich zu machen.

Prozessverbesserung mit TMMiBasierend auf diesen Grundlagen kann das TMMi-Refe-renzmodell als Ausgangspunkt und Zieldefinition für Soft-ware-Testing-Prozesse verwendet werden. Die klare und frei erhältliche, an CMMi und ISO 15504 angelehnte Struk-tur erlaubt IT-Leitern und Testverantwortlichen, die Ausprä-gung ihrer Prozesse im Bereich Testing klar zu definieren und eine Ist-Analyse gegen die im TMMi-Modell definierten Ziele durchzuführen. Accentures Test Assessment Frame-work (zum Patent angemeldet) dient hierbei als Fragenkata-log, um die einzelnen Bereiche strukturiert zu erfassen und auswerten zu können.

Basierend auf diesen Informationen können dann mit Blick auf die im TMMi Modell definierten Verfahrensweisen und Beispiele Verbesserungsmöglichkeiten erarbeitet, bewertet und umgesetzt werden. TMMi als offener Standard ermög-licht dabei den Beteiligten, die Einführung von Veränderun-gen jederzeit durch eine erneute Analyse zu überprüfen, Prioritäten zu setzen und an die jeweilige Situation im Un-ternehmen oder Projekt anzupassen.

Die Prozessverbesserung sollte als eigenes Projekt geplant und in mehrere Stufen oder Arbeitspakete aufgeteilt werden, damit die Umsetzung der einzelnen Verbesserungspunkte konkret und möglichst unabhängig vom Tagesgeschäft an-gegangen werden kann. Hierbei empfiehlt sich eine anfäng-liche Bestandsaufnahme gegen die in TMMi hinterlegten Ziele sowie eine Zieldefinition für das Unternehmen selbst. So können bestehende Lücken und Kernbereiche erkannt werden, die dann anhand konkreter Ziele (zum Beispiel Qualitätsverbesserung, Kostenreduktion, Erhöhung der Mitarbeitermotivation, Erhöhung der Kundenzufriedenheit, Reduktion der Release-Zyklen) priorisiert und mit Hilfe der in TMMi definierten Verfahrensweisen in einzelne Arbeits-pakete aufgeteilt werden können.

Nach der Ausarbeitung der einzelnen Punkte können diese in Pilotprojekten überprüft und mit den gewonnenen Er-kenntnissen überarbeitet werden, um sie dann in der Breite verfügbar zu machen. Begleitende Schulungen und vielfälti-ge Kommunikationsmaßnahmen sind in diesem Schritt sehr wichtig, um die Änderungen verständlich zu machen und so eine Akzeptanz zu erreichen.

TMMi bietet sich also als offener Standard für die Prozess-verbesserung im Test- und Qualitätsmanagement an und unterstützt Unternehmen bei der Effizienz- und Effektivi-tätssteigerung ihrer IT-Prozesse.

CONQUEST

Vorgehen für eine Prozessverbesserung mit TMMi

Die Autoren

Matthias Rasking leitet den Bereich Accenture Test Services in Deutschland, Österreich und der Schweiz sowie Accentures globale Testing Community of Practice mit über 10.000 Testspezialisten. Zudem ist er der Working Group Manager für Modellentwicklung und –wartung bei der TMMi Foundation.

Simon Lamers arbeitet seit drei Jahren bei Accenture Test Services in Deutschland und hat sich auf Test Management und Requirements Enginee-ring in komplexen IT-Projekten spezialisiert. Zudem ist er Mitglied der Working Group für Modellentwicklung und –wartung bei der TMMi Foundation.

Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !


Die fünf TMMi Reifegrade und deren Prozessgebiete

Im Fokus

Dr. Jekyll and Mr. Hyde – Die zwei Seiten von Requirements Enginee-ring: Was jede Organisation über die Einführung von Anforderungsma-nagement-Praktiken wissen sollte Christian Lescher, Helmut Frauenknecht

Effektives Requirements Engineering (RE) ist Vorausset-zung, um die Erwartungen der Kunden und des Markts zu treffen, sowie Fehlleistungen und Zeitverzögerungen zu ver-meiden. Basierend auf Siemens-weiten Erfahrungen haben wir typische Herausforderungen und bewährte Strategien analysiert. Dabei hat sich herausgestellt, dass RE-Aktivitäten dem „Gesetz des abnehmenden Ertrags“ folgen: Während die Erhöhung des Aufwands anfänglich zu besseren Ergeb-nissen führt, ist mehr Requirements Engineering ab einem bestimmten Punkt kontraproduktiv. Anstatt so viele Anfor-derungsmanagement-Praktiken wie möglich zu implemen-tieren, brauchen Organisationen eine fokussierte Strategie. Insbesondere im Kontext von global verteilten Entwicklungs-projekten muss sich das Vorgehen auf Zusammenarbeit und Kommunikation fokussieren.

Welche RE-Strategie soll eine Organisation verfolgen? In un-serem Beitrag bei der CONQUEST 2010 fassen wir Erfahrun-gen aus der Analyse von erfolgreichen RE zusammen, die wir bei Siemens innerhalb der letzten Jahre gemacht haben. Ein großes, globales Unternehmen bietet die Möglichkeit, aus erster Hand von anderen zu lernen – Gründe für Erfolg und Misserfolg bei der Einführung und der täglichen Arbeit mit RE zu verstehen. Die Hauptquelle dieser Informationen waren Interviews mit u.a. Projektmitgliedern, Entwicklungs-leitern und Systemtestverantwortlichen.

Die Analyseergebnisse zeigen, dass ein RE-Prozess für je-des Projekt beliebiger Größe erforderlich ist. Mit klaren und prägnanten Anforderungen wissen Entwickler, was sie zu entwickeln haben, und Kunden, was sie erwarten können. Von gutem RE hängen praktisch alle anderen Aktivitäten im Entwicklungsprozess entscheidend ab. Die Qualität des Re-quirements Engineerings hat daher maßgeblichen Einfluss auf das Endergebnis eines Unternehmens.

Ein RE-Prozess muss jedoch nicht komplex oder teuer sein. Tatsächlich basiert erfolgreiches Anforderungsmanagement im Wesentlichen auf einfachen Praktiken und Methoden. Ins-besondere kommt es darauf an, frühzeitig die richtige Stra-tegie zu wählen.

Angenommen, Sie hätten ein unbeschränktes Budget und beliebige Ressourcen für RE. Was würde geschehen, wenn Sie alle erdenklichen „best practices“ anwenden und Anfor-derungen bis zum „Geht-nicht-Mehr“ erheben, analysieren, entwickeln und managen? Unsere Untersuchungen weisen darauf hin, dass dies nicht in den „Requirements Engineering Himmel“ führt, sondern wegen des Grenznutzens kontrapro-

duktiv für das Ergebnis ist. Erfolgreicher ist eine fokussierte Strategie zu verfolgen, die im jeweiligen Kontext angemes-sen ist.

Als unterscheidbare Kontexte haben sich typische Pro-jektszenarien herauskristallisiert, für die eine spezielle RE-Strategie empfehlenswert ist. Vier Projekttypen sind hier be-schrieben, siehe Abbildung 1.

Standard-Projekte sind mittelgroße Kundenprojekte. Sie besitzen typischerweise viele Anforderungen (z.B. mehr als 4000 Anforderungen). Systematische Wiederverwendung ist eine gängige Projektstrategie. In diesem Szenario liegt der Fokus von RE darauf, in einer effektiven Analyse Lücken zwi-schen den Kundenanforderungen und dem eigenem System bzw. Produkt aufzudecken. Dazu dienen gut dokumentierte standardisierte System-/Produkt-Anforderungen.

Christian Lescher Helmut Frauenknecht

Abb. 1. Unterschiedliche Projekttypen erfordern eine fokussierte RE-Strategie


Session C4, 4.3 Mittwoch, 22. Sept.


CONQUEST

Komplexe Projekte sind häufig Projekte mit hohem Risiko, die sich auf neuem technologischen Gebiet bewegen und/oder sich durch hohe Komplexität auszeichnen. Organisa-tionen haben typischerweise nur wenige dieser Projekte, dafür haben diese Projekt aber ein entsprechend hohes Volumen. Die RE-Strategie muss darauf fokussieren, die vorhandene Komplexität auf eine handhabbare Größe zu reduzieren und die Essenz der Anforderungen herauszuar-beiten. Nur so sind ein zielgerichtetes Vorgehen und eine effektive Diskussion mit dem Kunden möglich. Es ist erfor-derlich, Anforderungen und Lösungen vorab zu überprüfen, z.B. durch Simulation komplexer Systeme, um zu ermitteln, ob ein gewählter technischer Ansatz den Kundenanforde-rungen genügt.

Evolutionäre Produktentwicklungen werden in der Regel von der internen Forschung und Entwicklung beauftragt und bezahlt. Die Anzahl der Anforderungen ist wesentlich nied-riger (ca. 200) im Vergleich zu anderen Szenarien. Die Rolle des Kunden übernimmt das interne Produktmanagement. In diesem Szenario kommt es auf die Qualität der Anforde-rungen und die dahinter stehende Markt-Intelligenz an – das Wissen über den Markt und seine zukünftige Entwicklung.

Kleine Projekte (z.B. mit einem Volumen <15.000 EUR) sind Kundenprojekte, die typischerweise einen sehr engen Bud-get- und Zeitrahmen haben und deshalb nur sehr beschränk-te Ressourcen für RE einsetzen können. Andererseits sind Fehler, die durch unzureichendes Anforderungsmanagement verursacht werden, oft im Rahmen des engen Budget- und Zeitrahmens nicht mehr zu korrigieren. Die RE-Strategie muss sehr effektiv zwischen Aufwand für RE und Risiko für das Projekt balancieren. Typischerweise sind „Low Tech“-Lösungen mit einem speziellen Fokus auf die Expertise des Entwicklungsteams am erfolgreichsten. Ziel muss es sein, Nachbesserungen im Projekt zu vermeiden, da sonst sofort die Wirtschaftlichkeit gefährdet ist.

Insgesamt zeigte es sich, dass die angewandten RE-Prak-tiken am erfolgreichsten sind, wenn sie der vorhandenen Projektsituation angepasst werden. Zusätzlich haben wir ge-lernt, dass dies notwendig, aber nicht unbedingt hinreichend ist, um erfolgreich zu sein. Eines der untersuchten komple-xen Projekte hat erheblichen Aufwand betrieben, um Anfor-derungen im Detail zu sammeln und zu dokumentieren, was zu einer Reihe von Problemen führte:

• DieAnzahlderAnforderungenwarzugroß,umdengroßenZusammenhang zu sehen, der Überblick ging verloren und es kam schlussendlich zu einer „Big Bang“ Integration und Test.

• DiefeineGranularitätbrachtedieGefahrmitsich,sichintechnischen Details zu verlaufen, z.B. in Vertragsverhand-lungen und Diskussionen mit dem Kunden.

• DerAufwandimÄnderungsmanagementexplodierte,ins-besondere da die Anforderungsänderungen schneller ein-trafen, als die Verarbeitung von Änderungen im Prozess dauerte.

• Letztendlich liefen die Anforderungsdatenbank und dietatsächliche Situation völlig auseinander, was dazu führte, dass die Anforderungsdatenbank letztendlich überhaupt keinen Nutzen mehr hatte.

Basierend auf diesen Beispielen und den Interviews haben wir festgestellt, dass Anforderungsmanagement dem „Ge-setz des abnehmenden Ertrags“ folgt (Abbildung 2). Das be-deutet, dass ab einem bestimmten Punkt jeder zusätzliche in RE investierte Aufwand zu immer weniger Ergebnis führt.

Anforderungsmanagement in global verteilten ProjektenInsbesondere in global verteilten Projektteams ist Kommu-nikation und Zusammenarbeit im RE der entscheidende Er-folgsfaktor. Eine bewährte „best practice“ ist der sogenannte Cross-Funktionale Requirements Workshop, bei dem Team-mitglieder aus verschiedenen Disziplinen und von mehreren Standorten in einer frühen Phase des Projekts gemeinsam die Anforderungen analysieren. In diesem Workshop wer-den alle Anforderungen in der gesamten cross-funktionalen Gruppe durchgesprochen. So können Unklarheiten und Ab-hängigkeiten frühzeitig erkannt werden. Zum Beispiel hat der Systemtester oft eine sehr gute Vorstellung des Gesamtsys-tems und wie es beim Kunden eingesetzt werden soll. Auch wenn dies als aufwändige Prozedur erscheint: Unsere Erfah-rung hat gezeigt, dass der Fokus auf Kommunikation und Zusammenarbeit sich im Projekt immer auszahlt.

Abb. 2. Das Gesetz des abnehmenden Ertrags für RE

Christian Lescher ist Senior Consultant bei der Siemens AG, Corporate Research and Technologies in München. Helmut Frauenknecht ist Senior Consultant bei der Siemens AG, Corporate Research and Technologies in Erlangen.



Die Autoren

Im Fokus

Modellbasiertes Testen (MBT) ist heute definitiv kein blo-ßes „Hype-Thema“ mehr, sondern befindet sich auf dem Sprung von der Grundlagenforschung hin zur industriellen Anwendung. Entsprechend steigt der Bedarf an belastba-ren Informationen, Werkzeuglösungen sowie nicht zuletzt Vorgehensmodellen für eine erfolgreiche MBT-Einführung.

Wenn sich Testmanager, Projektleiter oder Testdesigner die Frage „Ist MBT etwas für uns?“ stellen – wobei „uns“ ein Projekt oder eine Organisation sein kann – sollten sie als erstes zur Kenntnis nehmen, dass es „das“ MBT „von der Stange“ nicht gibt. MBT verfolgt im weitesten Sinne das Ziel, Testfälle aus Modellen zu generieren. Schon hier stellen sich fundamentale Fragen: Von welchen Modellen ist die Rede? Sind bereits existierende Systemmodelle ge-meint – etwa aus der objektorientierten Analyse auf Basis von UML-Diagrammen – oder sollen eigenständige Testmo-delle entstehen, die aus Testsicht mehr „Platz“ für testrele-vante Informationen wie z.B. Testdaten bieten? Und was für

„Testfälle“ sollen generiert werden? Abstrakte oder konkrete Tests? Manuell oder automatisiert ausführbare Testskripte? Und schließlich: Wie soll die Generierung aussehen? Soll ein kommerzielles MBT-Produkt eingesetzt oder ein eigener Generator entwickelt werden? Wie passt der Generator zur vorhandenen Werkzeuglandschaft, sowohl im Test als auch in der Modellierung?

Für die Beantwortung dieser Fragen sind eine Reihe von Faktoren maßgeblich, von denen die wichtigsten lauten:

• dieZiele,diemansichvoneinemMBT-Einsatzzuerrei-chen hofft.

• derReifegradderetabliertenTestprozesse,dieumMBTangereichert werden sollen.

• dieModellierungskenntnissedesTestpersonals.

In Abbildung 1 sind drei Ausprägungen von modellbasier-tem Testen zu sehen. Sie unterscheiden sich hinsichtlich

der Rolle, die Modelle im Testprozess einnehmen, und im Reifegrad der In-tegration der eingesetzten Werkzeuge. Entscheidend ist, dass der gewählte MBT-Ansatz zum vorhan-denen Testreifegrad passt: So ist der Einsatz eines MBT-Werkzeugs, das mas-sive UML- und OCL-Kennt-nisse zur Modellerstellung voraussetzt, problematisch in einem Umfeld, in dem der Testprozess noch Mängel besitzt oder die Testerinnen und Tester nicht die geringsten Modellierungskenntnisse besitzen (siehe Abbildung 2). Fehlende Akzeptanz einer-seits sowie überzogene Erwartungen andererseits stellen Risiken dar, die im schlimmsten Fall dafür sorgen, dass das Thema MBT als Ganzes auf Jahre hinaus im eigenen Umfeld „verbrannt“ ist. Aber auch die Eigenentwicklung passgenauer MBT-Realisierungen führt zu nichttrivialen Herausforderungen. So muss der Testgenerator auf einem wohldefinierten Metamodell mitsamt Modellierungskon-ventionen aufsetzen, denn andernfalls wird der Generator mit „Input“ konfrontiert, der zu unbrauchbaren oder un-genügenden Ergebnissen führt. Das Problem fehlerhafter Modelle muss über geeignete QS-Maßnahmen adressiert werden. Die vom Generator zu erzielende Testabdeckung muss steuerbar sein, um Testfallexplosionen unterbinden zu können. Die beteiligten Werkzeuge müssen hinreichend anpassbar sein und eine werkzeug-übergreifende Tracea-bility unterstützen. Und schließlich durchzieht das Thema

„Versionierung“ auch den modellbasierten Testprozess: Wenn keine wohldefinierten Baselines für die eingesetz-ten Modelle existieren und es Probleme bei der Ermittlung des „Deltas“ zwischen zwei Modellständen gibt, wird auch die Testgenerierung an Effektivität und Effizienz einbüßen. Letztlich muss ein werkzeuggestützter Testprozess entste-hen, der von den Beteiligten als Gewinn, Arbeitserleichte-rung und Hilfsmittel betrachtet wird.

Eine gute Einstiegshilfe zur Ermittlung des eigenen MBT-Bedarfs und der vorhandenen MBT-Fähigkeiten ist zu fin-den in [1]. Dort wird anhand von Entscheidungsdiagram-men eine erste Orientierung zur Frage geboten, ob man tiefer in eine Kosten-Nutzen-Analyse zu MBT einsteigen soll oder doch lieber erst andere „Baustellen“ in seinem Testprozess behebt.

Erfolgsfaktoren für die MBT-Einführung – ein Erfahrungsbericht Dr. Christian Brandes

Christian Brandes


Abbildung 1: Drei Ausprägungen von modellbasiertem Testen (aus [2])

Session B2, 2.3 Dienstag, 21. Sept.


Während Entwickler schon seit vielen Jahren z.B. UML-Dia-gramme als selbstverständliches Arbeitsmittel betrachten, holt der Test seinen Rückstand in Einsatz und Nutzung von Modellen nun mit MBT auf. MBT ist aber kein Allheilmittel und führt auch nicht zu „Testen auf Knopfdruck“. MBT ist eine sinnvolle Ergänzung etablierter Testdesign-Methoden, muss aber unbedingt in Testprozess und Testmanagement integriert werden, um seine Stärken ausspielen zu können.

LITERATUR:

[1] Güldali, B.; Jungmayr, S.; Mlynarski, M.; Neumann, S.; Winter,

M.: Starthilfe für modellbasiertes Testen: Entscheidungsunterstüt-

zung für Projekt- und Testmanager. OBJEKTspektrum 3/10, S. 63-

69, 2010.

[2] Roßner, T.; Brandes, C.; Götz, H; Winter, M.: „Basiswissen Mo-

dellbasierter Test“, dpunkt.verlag 2010

CONQUEST

Der Autor

Dr. Christian Brandes ist Testarchitekt beim IT-Systemhaus der Bundesagentur für Arbeit. Der ISTQB® Certified Tester (Full Advanced Level) entwickelt Test- und QS-Standards für den Softwareentwicklungsprozess der BA. Aktuelle Schwer-punkte sind Tests in einer SOA und der methodische Übergang von Softwaremo-dellen zu automatisiert ausführbaren Tests.



Abbildung 2: Die Skill-Schnittmenge zwischen Modellierern und Testern ist heute noch gering (aus [2]).

Anzeige

Zielsicher zum ErfolgSo haben Sie Ihr Testmanagement fest im Griff

Testen von Software spart nicht nur Zeit und Geld, sondern bewahrt auch Ihren guten Ruf. Die Verantwortung für die Qualität Ihrer IT-Projekte ist herausfordernd und bedarf einer kontinuierlichen Weiterbildung.

Aufwandsschätzung für Testmanager

Kennzahlen für Testmanager

Projekt-Team-Training

Praxistage – Übungen, Best Practices und Erfahrungsaustausch zu den Seminaren aus der Reihe „ISTQB® Certifi ed Tester“

Neben allen ISTQB®-Seminaren fi nden Sie weitere Fortbildungsangebote der SQS unter www.sqs.de/training

Anmeldung über [email protected]

SQS Software Quality Systems AG

Stollwerckstraße 11 | 51149 Köln | Telefon 02203 9154-17 | Fax 02203 9154-15

Anz Training SQ Magazin 210x136.indd 1 16.04.2010 15:40:24

Zielsicher zum ErfolgSo haben Sie Ihr Testmanagement fest im Griff

Testen von Software spart nicht nur Zeit und Geld, sondern bewahrt auch Ihren guten Ruf. Die Verantwortung für die Qualität Ihrer IT-Projekte ist herausfordernd und bedarf einer kontinuierlichen Weiterbildung.

Aufwandsschätzung für Testmanager

Kennzahlen für Testmanager

Projekt-Team-Training

Praxistage – Übungen, Best Practices und Erfahrungsaustausch zu den Seminaren aus der Reihe „ISTQB® Certifi ed Tester“

Neben allen ISTQB®-Seminaren fi nden Sie weitere Fortbildungsangebote der SQS unter www.sqs.de/training

Anmeldung über [email protected]

SQS Software Quality Systems AG

Stollwerckstraße 11 | 51149 Köln | Telefon 02203 9154-17 | Fax 02203 9154-15

Anz Training SQ Magazin 210x136.indd 1 16.04.2010 15:40:24

http://www.sqs.de/training

CONQUEST 2010 Ausgabe 16 | September 2010 12

Monday, September 20, Day 1

Tuesday, September 21, Day 2

Wednesday, September 22, Day 3

8:00 Tutorial Registration – Welcome Coffee

9:00_

12.00

Tutorial I (de) Room: Konferenz 3

Tutorial II (en) Room: Konferenz 4

Full Day Tutorial (de) Room: Konferenz 5

Testprozessverbesse-rung mit TPI-NextGraham Bath T-Systems GEI, Germany

Applying the Scrum management fra-mework in a real life project scenarioFrank Beeh/ Ralph Jocham Zühlke Engineering, Germany

Die perfekte CPRE-VorbereitungChris RuppSOPHIST, Germany

12:00 Lunch Break (12:00 – 13.00)

13:00_

16.00

Tutorial III (de) Room: Konferenz 3

Tutorial IV (de) Room: Konferenz 4

Full Day Tutorial (de) Room: Konferenz 5

Ganzheitliches Projekt-Engineering mit dem Quality Risk Manage-ment FrameworkDaniel Simon E.ON Energy Trading SE, GermanyFrank Simon SQS, Germany

.mzT – Testen mit Mo-dellen im industriellen UmfeldMartin Beißer sepp.med, Germany

Die perfekte CPRE-VorbereitungChris Rupp SOPHIST, Germany

16:00 Conference Pre-Registration – Coffee Break

16:30 Public Examination

8:00 Conference Registration – Coffee Break - Exhibition

9:00

Opening Room: Konferenz 6Stephan Goericke (Conference Chair), iSQI GmbH, GermanyIna Schieferdecker (Program Committee Chair), Fraunhofer FOKUS, Germa-ny + Welcome Adress from Said Zahedani

9:30Opening Keynote Room: Konferenz 6 Testing extends to the Cloud – Same Same, but Different…? (en)Said Zahedani, Microsoft, Germany

10:20 Coffee Break – Exhibition (10:20 – 10.50)10:30

_

10.50

Industrial Presentation Room: ExhibitionSoftwaretests Open Source als „Test as a Service“ (de)Peter Kaufmann, T-Systems MMS

Session A1 Room: Konferenz 3

Session B1 Room: Konferenz 4

Session C1 Room: Konferenz 5

Classic or Agile – What Counts is Business ValueChair: Manfred Baum-gartnerpresented by ANECON

Modellbasiertes Testen – Ein Fall, der sich rechnet!Chair: Thomas Weberpresented by SQS

Testing ProcessesChair: Peter Zimmerer

10:50_

11.35

A1.1Software-Test als Teil der eGovernment Umsetzungs-Strategie des Freistaates Sach-sen (de)Jan OverbeckANECON, Austria

B1.1Prüfung kommunaler Programme in Sachsen (de)Axel LohmannSAKD, Germany

C1.1Integrating Open Sour-ce Tools to Catalyze Flex Application Testing (en)Rohit KothariLNT Infotech, India

11:40_

12.25

A1.2Efficiency and Effective-nes – Test Methodology and Automation (en)Thomas BucsicsANECON, Austria

B1.2Der Methodische Ansatz des modellba-sierten Testens incl. ROI (de)Frank SimonSQS, Germany

C1.2A Systematic Method for Identifying Testing Project Risks (en)Andreas SchmietendorfBerlin School of Econo-mics, Germany

12:30–

13:15

A1.3Agile Testing in SCRUM (de)Gerald Grossmayerbwin Interactive Enter-tainment, AustriaManfred BaumgartnerANECON, Austria

B1.3 SQS - Praxisbeispiel aus dem Testumfeld (de) Hans-Jürgen KohnsSQS, Germany

C1.3Process Improvement with TMMi (en)Matthias RaskingAccenture, Germany

13:15 Lunch Break (13:15 – 14.45)

13:20–

13:40

Industrial Presentation Room: ExhibitionTPI (Test Process Improvement) in a complex organization with multiple system environmentsArjan Brands, Díaz & Hilterscheid, Germany

14:20–

14:40

Industrial Presentation Room: ExhibitionTesten Sie Ihre aktuellsten Anforderungen?Oliver BöhmMKS, Germany

14:45–

15:35

Expertenrunde (de) Room: Konferenz 6„Was Sie schon immer über das Testen & QS wissen wollten... Fragen Sie unsere Experten!“, Moderation: Karin Vosseberg (HS Bremerhaven), Andreas Spillner (HS Bremen), Teilnehmer: Markus Gärtner (IT-agile), Bernd Hindel (Method Park Software), Maud Schlich (German Testing Board & IT-PROJECT-SERVICE), Peter Zimmerer (Siemens)

15:35 Coffee Break – Exhibition (15:35 – 16.05)

15:40–

16:00

Industrial Presentation Room: ExhibitionSaxonia Systems – Der sächsische Qualitäts-DienstleisterWir lieben IT und leben Qualität.Marco Fischer, Saxonia Systems, GermanySession A2 Room: Konferenz 3



SafetyChair: Bernhard Sechserpresented byMethod Park Software

SIG Model Based Testing Chair: Florian Presterpresented bySIG MBT

Softwareentwicklungs- und TestprozesseChair: Helmut Pichler

16:05–

16:50

A2.1Functional Safety in Standards (en)Klaudia Dussa-ZiegerMethod Park Software, Germany

B2.1„MBT quo Vadis?“ (de) Florian Prestersepp.med, Germany

C2.1Agile Methoden in einem ERP Migrations-projekt (de)Sven Tissot pdv TAS, GermanySebastian Middeke C1 WPS, Germany

16:55–

17:40

A2.2Der steinige Weg vom Produktrisiko zum Softwarerisiko (de)Markus ManleitnerDräger Medical, Germany

B2.2Modellbasiertes Testen – Design und Imple-mentierung am Beispiel „Vespa Shop“(de) Heike UrbanT-Systems Multimedia Solutions, Germany

C2.2Rangliste der Ein-flussfaktoren auf den Testaufwand (de)Melanie WohnertLoyalty Partner Solu-tions, Germany

17:45–

18:30

A2.3Combined Use of SPICE and ISO 26262 – A Case Study from a German Task Force (en)Richard MessnarzISCN, Austria

B2.3Erfolgsfaktoren für die MBT-Einführung – ein Erfahrungsbericht (de) Christian BrandesBundesagentur für Arbeit, Germany

C2.3Fehlerbasierte Soft-wareprozess-verbesserung – Metho-dik und Anwendungser-fahrungen (de)Ralph TrittmannRheinische Fachhoch-schule Köln, Germany

18:30 Break

19:00 Social Event – Meeting Point: Foyer (Entrance level)

8:30 Conference Registration

9:00Keynote Room: Konferenz 6 Experiences in TestautomationDorothy Graham, Grove Consultants, UK

9:50 Coffee Break – Exhibition (09:50 – 10.20)

10:00–

10:20

Industrial Presentation Room: Exhibition Modular Test Case DesignMichael Oestereich, profi.com, Germany




State-of-the-art Requi-rements Engineering in der PraxisChair: Chris Rupppresented by SOPHIST

Certifications and Project ManagementChair: Bernd Hindel

Software DevelopmentChair: Maud Schlich

CONQUEST 201013 Ausgabe 16 | September 2010

15:20–

16:05

A4.110 Jahre Testmanage-ment bei der Deutschen Bank Bauspar AG – eine Erfolgsstory (de)Johannes HeldersDeutsche Bank Bau-spar, Germany

B4.1Normkonforme Soft-wareentwicklung nach IEC 62304 mit TFS. (de)Stefan Angele, Volker Majewskiinfoteam Software, Germany

C4.1Die RE-Völkerverstän-digung: Wissens-wertes rund um die Zertifizierung zum „Certified Professional for Requirements Engineering“ (de)Chris Rupp, Rainer Grau, IREB, Germany

16:10–

16:55

A4.2Der Nutzen von eines fachlich orientierten Automatisierungswerk-zeugs und Quality Gates in einem SAP Entwick-lungsprojekt (de)Henry Smid / Dennis KalliesC:1 Solutions, Germany

B4.2Funktionale Sicherheit von Medizinprodukten – Sichtweise der genann-ten Stelle(n) (de)Werner ReichelSiemens, Germany

C4.2Bridging the Gap between Business and IT with Enterprise Mashups – An analysis of the Current Possibili-ties (en)Andreas Schmieten-dorf, Berlin School of Economics and Law, Germany

17:00–

17:45

A4.3Die Behebung des Test-datenproblems (de)Mike SchlabingerTRICENTIS, Germany

B4.3Introducing the “Certified Professional for Medical Software” training program (en)Georg Götzsepp.med, GermanyChristian JohnerInstitut für IT im Gesundheitswesen, Germany

C4.3Dr. Jekyll and Mr. Hyde – The Two Sides of Re-quirements Engineering: What Every Organization Should Know When In-troducing Requirements Engineering Practises (en)Christian Lescher / Helmut FrauenknechtSiemens, Germany

17:45 Closing & Awards (17:45 – 18.00)

10:20–

11:05

A3.1Klassische Anforde-rungen vs. Product Backlog (de)Chris Rupp / Hajo HoffmannSOPHIST, Germany

B3.1Managing Software Development with the Approach of P2M: Program and Project Management frame-work3 (en) Susumu SasabeJUSE, Japan

C3.1New Metrics for Global Software Engineering: Improving Project Management through Communication-based Early Warning Indica-tors (en)Christian LescherTU Munich, Germany

11:10–

11:55

A3.2Systemanalyse auf den Punkt gebracht (de)Chris RuppSOPHIST, Germany

B3.2ISEB Intermediate - Foundation für den Advanced Level (de) Werner LieblangDiaz & Hilterscheid, Germany

C3.2Patterns for Testing inGlobal Software Deve-lopment (en)Frank Salgercapgemini, Germany

12:00–

12:45

A3.3Modelle und Qualität – natürliche Verbündete (de)Stefan Walburg / Christian BrandesBundesagentur für Arbeit, Germany

B3.3ISTQB Foundation Le-vel: Key Fundamentals for Specialists (en) Hans HartmannOBJENTIS Software Integration, Austria

C3.3Specification Metrics for Event-B Develop-ments (en)Marta OlszewskaÅbo Akademi Universi-ty/ TUCS, Finland

12:45 Lunch Break (12:45 – 14:00)

12:50–

13:10

Industrial Presentation Room: Exhibition .getmore – Der TestfallgeneratorArmin Metzger, sepp.med, Germany

14:00–

14:50

Keynote Room: Konferenz 6 Software Quality in the Age of GlobalizationJutta Eckstein / Nicolai Josuttis, IT communication, Germany

14:50 Coffee Break – Exhibition (14:50 – 15:20)




Die Evolution der Test-automatisierung und des Testdatenmanage-ment für geschäftskri-tische AnwendungenChair: Mike Schlabingerpresented by TRICENTIS

Medical ITChair: Werner Reichel

Requirements EngineeringChair: Markus Gärtner

EXPERTENRUNDE„Was Sie schon immer über das Testen & QS wissen wollten... Fragen Sie unsere Experten!“

Moderation: Karin Vosseberg (HS Bremerhaven), Andreas Spillner (HS Bremen)Teilnehmer: Markus Gärtner (IT-agile), Bernd Hindel (Method Park Software), Maud Schlich (German Testing Board & IT-PROJECT-SERVICE), Peter Zimmerer (Siemens) Wir möchten Sie einladen mit uns und unseren Experten Ihre offenen Fragen zu diskutieren. Schicken Sie uns Ihre Fragen, Ideen und Anmerkungen bereits im Vorfeld der Konferenz und gestalten Sie damit aktiv ihre Expertenrunde.

Wir erwarten Ihre Fragen bis zum 15. September 2010 unter [email protected]

www.conquest-conference.org

Prog

ram

män

deru

ngen

vorb

ehal

ten

/ Sta

nd A

ugus

t 201

0


Kolumne Ausgabe 16 | September 2010 14

Besonders seit Beginn der Finanz- und Wirtschaftskrise Ende 2008 ist auch in Deutschland eines klar: Unternehmen und Organisationen müssen und wollen Kosten sparen. Ein Mittel dazu ist verstärktes Outsourcing. Wikipedia definiert Outsourcing als „die Abgabe von Unternehmensaufgaben und -strukturen an Drittunternehmen. Es ist eine spezielle Form des Fremdbezugs von bisher intern erbrachter Leis-tung, wobei Verträge die Dauer und den Gegenstand der Leistung fixieren.“

Der Trend zur Auslagerung betrifft auch die Community der dieses Magazin lesenden Software-Tester. In einer auf und von der IT-Konferenz „iqnite“ 2009 durchgeführten Survey ergab sich folgendes Bild:• Zum Zeitpunkt der Befragung gaben 14 Prozent der

Befragten an, dass „ein Teil ihres Testens komplett out-gesourct“ sei, während 33 Prozent erklärten, dass sie sowohl externe Tester als auch eigene Mitarbeiter einset-zen. 53 Prozent meldeten, dass sie alles Testen inhouse abwickeln.

• IndensechsbiszwölfMonatennachderBefragungplan-ten acht Prozent der Befragten, „ihre Testaufgaben an ei-nen externen Dienstleister auszulagern“ und 20 Prozent konnten sich vorstellen, dies zu tun.

Als Hauptgrund für das Outsourcing werden von 43 Prozent der Befragten Kostenvorteile erwartet. Das passt zur ökono-mischen Situation im Jahr 2009. Als zweitwichtigsten Grund nennen 27 Prozent die Flexibilität. (Der vollständige Report kann per E-Mail, team@iqnite-conferences, angefordert wer-den.)

Die Kostenvorteile entstehen beim Outsourcing primär da-durch, dass man Teilaufgaben in Niedriglohnländern, also offshore oder nearshore erbringen lässt, wobei der Erfolg ganz wesentlich von dem Zusammenspiel von onsite und offshore abhängt.

Ist dies eine Gefahr für die vielen Software-Tester zum Bei-spiel in Deutschland, Österreich oder der Schweiz - für Test-manager, funktionale Testexperten oder technische Testex-perten? Die eindeutige Antwort ist nein!

Die Gründe sind recht einfach: Makroökonomisch betrachtet steht seit längerem fest, dass die Bevölkerung in Europa in den kommenden Jahrzehnten von heute rund 450 Millionen Einwohnern auf etwa 320 Millionen schrumpfen wird, so-lange keine stärkeren Zu- oder Abwanderungsbewegungen stattfinden. Zudem wird aufgrund der demoskopischen Ent-wicklung der Anteil der arbeitenden Bevölkerung gravierend

abnehmen. Dies führt dazu, dass das Wirtschaftspoten-zial von Europa nur erhalten werden kann, wenn mehr Leistungen von außen be-zogen werden – unter an-derem auch beim Software-Testen.

Das Testen in IT-Projekten oder das Re-Testen wäh-rend der Wartung und Weiterentwicklung (Mainte-nance) wird in Zukunft we-sentlich arbeitsteiliger erbracht werden:

• TestmanagementundTestdesigngrößtenteilsonsite,alsovor Ort

• TestvorbereitungundTestausführungkönnenoffshore(z.B.Indien, Ägypten) oder nearshore, (z.B. baltische Staaten, Central Eastern Europe) erbracht werden

• Testauswertungwiederumgrößtenteilsonsite.

Da also die besonders wichtigen Aufgaben des Testmanage-ments und der Testauswertung unbedingt vor Ort erbracht werden müssen, ist dies eine Chance für entsprechend qua-lifizierte Tester. Erfahrungsgemäß müssen auch in Offshore-Projekten mindestens 30 Prozent der Arbeitsleistung onsite erbracht werden, wenn diese Vorhaben erfolgreich sein wol-len. Am Beginn der Verlagerung liegt der Vor-Ort-Anteil so-gar bei 70 Prozent. Wer etwas anderes behauptet, will sich lediglich die Durchschnittskosten schön rechnen. Die onsite verbleibenden, höher qualifizierten Aufgaben bedeuten da-her auch in Zukunft bessere Chancen für eine Testerkarriere

– wie viele Beispiele bereits belegen.

Natürlich müssen die hiesigen Tester dabei auch die persön-lichen Voraussetzungen schaffen, wenn sie diese Chancen aufgreifen wollen. Testmanager zum Beispiel wird man nicht über Nacht. Vielmehr sind zwei Dinge wichtig: Aus- und Wei-terbildung, etwa durch weitere Qualifizierungen nach dem Avanced Level der Certified-Tester-Ausbildung des Interna-tional Software Testing Qualifications Board (ISTQB) und na-türlich durch die praktische Erfahrung in der täglichen Arbeit.

Ihr Rudolf van Megen, CEO der SQS Software Quality Systems AG und Beirat des ASQF e.V.

„Outsourcing - Gefahr oder Chance für Tester?“Rudolf van Megen

Rudolf van Megen

hier schreibt in regelmäßigen Abständen der Beirat des ASQF e.V.

International SPICE Days15 Ausgabe 16 | September 2010

Dieses Jahr waren wir Teil des Open Forum 2010: Internati-onal SPICE Days und Automotive Safety & Security – zwei Konferenzen unter einem Dach mit gemeinsamen Keynotes und der Möglichkeit, an Sitzungen beider Konferenz teilzu-nehmen. Die Organisatoren der Konferenzen haben gut und hart gearbeitet und mit mehr als 330 Teilnehmern und einer ausverkauften Ausstellung mit über 30 Ausstellern einen neuen Rekord aufgestellt. Die Zahlen sind zwar erfreulich, aber noch wichtiger ist, dass sich der “Community” Charak-ters der International SPICE Days verstärkt hat. Diskussio-nen in kleinen und größeren Gruppen fanden nicht nur zur Kaffeezeit an den Tischen in der Ausstellung statt. Die Mehr-heit der Teilnehmer waren die Anwender, die versuchen, die Prozesse in ihrer Organisation zu verbessern, und denen der Erfahrungsaustausch offensichtlich eine äußerst wichtige Motivation für den Besuch der Konferenz ist.Der allgemeine Trend wurde bestätigt: Systemaspekte werden bei der Entwicklung gegenüber reinen Software-Aspekten immer wichtiger. Dies liegt an der zunehmenden Komplexität und Sicherheitsrelevanz von immer vernetzte-ren Produkten. Die Beherrschung der Komplexität und Si-cherheit sind oftmals bedeutender als Fragen der Kosten. Prozesse sind nur ein Teil der Lösung. Aber da die meisten Projekte eine Form der Zusammenarbeit zwischen Organi-sationen beinhalten, sind verlässliche Prozesse eine Vorbe-dingung.Vorträge und Diskussionen über die Erweiterung der me-thodischen Ansätze waren daher ein wichtiger Baustein im Programm. Agilität in der einen oder anderen Form scheint die Richtung der Wahl für viele Entwicklungsteams – und die Erfahrung zeigt auch, dass (Automotive) SPICE konforme Prozesse und Agilität durchaus kompatibel sind. In einigen Beiträgen wurde die Tatsache hervorgehoben, dass auch Six Sigma-Techniken mit SPICE-basierten Ansätzen kombiniert werden, und mit großer Wirkung – und nicht nur auf höheren Reifegradstufen.Die Keynotes spannten einen interessanten Rahmen um dieses Programm. Tom DeMarco von der Atlantic Systems

Guild sah die Grenzen des Verständnisses der einzelnen Menschen durch die immer komplexeren miteinander ver-bunden Systeme überschritten. “Selbst die kompetentesten Fachleute, oder auch fähige Unternehmen, können einzeln auf Dauer diese “Dynaxity” – Dynamik und Komplexität

– nicht in den Griff bekommen“, argumentierte Harald Hei-necke, Geschäftsführer BMW Car IT, in seiner Keynote. Er beschrieb community-basierte Entwicklung als „Überle-bensstrategie“ für die Automobilindustrie. Bjarne Stroustrup, der Vater von C++, betrachtete Muster und Richtlinien, die in der Codierung eine Rolle spielen sollten, um Zuverlässigkeit und Sicherheit sicherzustellen. Bernd Hindel von Method Park erinnerte die Zuhörer in seiner Rede daran, dass auch ohne den Menschen die Natur eine Reihe von „Strategien“ hervorgebracht hat, um Sicherheit zu erreichen oder zu er-höhen. Vertrauen war hier der Schlüsselbegriff – was beson-ders relevant ist für Prozesse im Bereich kreativer, menschli-cher Zusammenarbeit. Prozesse sind nicht zur Maximierung der Kontrolle da, sondern sie sollten verbinden und Vertrau-en schaffen. Die anschließende Podiumsdiskussion mit den Keynote-Rednern unterstrich die zunehmende Bedeutung des menschlichen Engagements, technisch und sozial, um mit den Herausforderungen der Dynaxity umzugehen. Community-basierte Software – inklusive Open-Source, im Zusammenspiel mit Modell-basierter Entwicklung – unter-stützt durch agile Methoden: Dies scheint der Schlüssel zu sein. Wie werden dann die Prozesse und Organisationen der Zukunft aussehen? Die Konferenz hatte keine eindeutige Antwort, aber es gibt wohl auch mehr als “eine Wahrheit”. Agilität und Open Source in der Automobilindustrie – dies ist ein großer Paradigmenwechsel, aber er findet statt. In der Automobilbranche hängen eben 80% und mehr von der Innovation – auch in der Sicherheit – der Software ab. Das

„Software-Auto“ hat Zukunft.

Die ausführliche Reflexion von Conference Chair Hans-Jürgen Kugler finden Sie unter www.spice-days.com.

International SPICE Days 2010 – Reflektionen des Conference Chairs Hans-Jürgen Kugler

Im Fokus Ausgabe 16 | September 2010 16

Im nächsten Jahr wird das Automobil 125 Jahre alt. Doch gegenwärtig gibt es kaum Grund zum Feiern: Die Weltwirt-schaftskrise führte durch den Einbruch der Absatzmärkte der traditionellen Autohersteller zu großen Überkapazitäten bei der Produktion von Fahrzeugen. Allein im letzten Jahr sanken die weltweiten Verkaufszahlen bei PKWs um 22 Pro-zent, bei LKWs um 40 Prozent und bei Vans sogar um 44 Prozent. Neue aufstrebende asiatische Automobilhersteller verschärfen zudem den globalen Wettbewerb und strenge CO2-Gesetzgebungen erhöhen den Innovationsdruck auf die Hersteller. Hinzu kommt: Länder- und marktspezifische Gesetze und Vorschriften stellen die Automobilindustrie vor zusätzliche wirtschaftliche und technologische Herausforde-rungen in Entwicklung und Produktion.

Die Automobilindustrie ist gerade dabei, ihre Entwicklungs-prozesse radikal anzupassen. Vor allem weist sie der Elek-tronik eine zentrale Rolle zu: Schätzungsweise 98 Prozent der Innovationen in einem Fahrzeug gehen mittlerweile auf das Konto elektrischer und elektronischer (E/E-)Systeme. 25 Prozent der Fertigungs- und Montage-Kosten entstehen durch die Elektronik. In einem PKW befinden sich heutzuta-ge komplexe, vernetzte mechatronische Systeme mit meh-reren tausend voneinander abhängigen Einzelfunktionen. Ein Leitungssatz kann bis zu fünf Kilometer Einzeldrähte umfas-sen – Tendenz steigend.

Flexibel durch modularen AnsatzDie Industrie tritt diesen Herausforderungen mit einem modularen Entwicklungsansatz entgegen, der sich an den einzelnen Funktionen des Systems „Auto“ orientiert. Er er-möglicht den baureihenübergreifenden und flexiblen Einsatz dieser Funktionsmodule und den Systemplattformen, auf denen sie basieren. Damit das Prinzip „Wiederverwendung“ funktioniert, ist eine Standardisierung der Module und Platt-formen erforderlich. Automobilhersteller nutzen dafür unter anderem unternehmensübergreifende Industriestandards, die insbesondere Bussysteme und die Software-Entwick-

lung betreffen. Dass das Thema „Standards“ in der Autoindustrie einen hohen Stellenwert besitzt, zeigt zum Beispiel der herstel-lerübergreifende, internati-onale Verbund AUTOSAR (AUTomotive Open System ARchitecture), der einen offenen Standard für Soft-ware-Architekturen in Kraft-fahrzeugen entwickelt und vorantreibt. Automobilher-steller können so Software-Module und deren Schnittstellen ohne Hürden integrieren und wiederverwenden.

Die standardisierten und modularen E/E-Systeme lassen sich durch Software an spezifische Gegebenheiten einzelner Fahrzeuge und deren Derivate anpassen, dadurch mit ver-schiedenen Funktionseigenschaften ausstatten und mehr-fach verwenden. Dieses Vorgehen ermöglicht es zudem, marktspezifische Funktionen und Vorschriften in einzelnen Ländern individuell zu erfüllen. Ein Beispiel sind die vorderen Lichter am Auto, wie das Fernlicht, das Abblendlicht und der Nebelscheinwerfer, die je nach Land nur in bestimmten Kom-binationen eingeschaltet sein dürfen. Über individuell codier-te Software-Versionen können die einheitlich konzipierten Lichtanlagen den unterschiedlichen Vorschriften individuell angepasst werden – ohne eine komplett neue Entwicklung oder separate Produktion.

Ein Bausatz – mehrere FunktionenDoch wie funktioniert das in der Praxis? Die länderspezifi-schen Vorgaben zur Lichtausgestaltung formuliert der Her-steller in Form einer Spezifikation und übergibt sie an den Zulieferer, der die gewünschten Anforderungen umsetzt, in-dem er ein darauf abgestimmtes Software-Modul entwickelt. Im nächsten Schritt liefert der Entwicklungspartner die Elek-tronik mit dem entsprechenden generierten Spezial-Code an den Automobilhersteller. Nach Implementierung des E/E-Systems in das Fahrzeug, lädt der Hersteller den jeweils be-nötigten Code herunter und konfiguriert das Fahrzeug online. Die länderspezifische Beleuchtung ist jetzt auf das Fahrzeug übertragen. Nach dem gleichen Prinzip kann der Hersteller ohne großen Entwicklungsaufwand individuelle Kundenwün-sche umsetzen.

Bevor Module oder Systemplattformen als baureihenüber-greifende Standard-Komponenten zum Einsatz kommen,

Ein Code für alle Fälle – Wie Automobilhersteller durch Software im Fahrzeug flexibel bleiben Volker Wilhelmi

Volker Wilhelmi

Gesamtvernetzung der neuen Mercedes-Benz E-Klasse


sind diese ausgiebig zu testen. Die Kosten für eine nachträgliche Fehler-behebung oder für einen Rückruf, wenn das Produkt schon auf dem Markt ist, wären um ein Vielfaches höher, als die Investitionen in das Testen – ganz zu schweigen vom Imageschaden des Unternehmens. Das Testen von E/E-Systemen umfasst drei Schritte: Nach dem Einzelkomponententest, folgt der Test der vernetzten Komponenten und zuletzt des Gesamtfahrzeugs. Der Komponententest, den in der Regel der Zulieferer durchführt, sichert die Funktionalität der einzelnen Komponenten sowie ihre Integrierbarkeit in das Gesamtsystem.

Der Zulieferer gibt dann die getesteten Komponenten mit einem Prüfproto-koll an den Automobilhersteller weiter. Dieser testet mit einem „Hardware-in-the-loop“-(HiL-) Prüfstand die bereits verdrahteten Komponenten: Von elektrischen Fensterhebern über alle Beleuchtungen bis hin zur kompletten Motor- und Antriebssteuerung. Integriert in eine simulierte Testumgebung, werden die softwaregesteuerten Komponenten entsprechend ihrer späteren Anwendung belastet – 24 Stunden, 7 Tage die Woche, rund um die Uhr. Ge-testet wird in Echtzeit und unter realen Umweltbedingungen. Dazu gehören zum Beispiel auch Tests für nicht-funktionale Anforderungen wie zum Bei-spiel große Temperaturgefälle, Beschleunigungsvorgänge, starke und lang anhaltende Vibrationen oder das Besprühen mit salzigem Nebel. Schließlich müssen die Autos in fast allen Klimaregionen der Welt reibungslos funktio-nieren. Jedes Testereignis wird protokolliert und ausgewertet. Damit ist eine frühe Analyse des entwickelten Gerätes möglich.

Testfahrten zum AbschlussHat ein E/E-System bewiesen, dass es funktioniert und stabil läuft, imple-mentieren die Ingenieure es in das Fahrzeug und stoßen in einem letzten Schritt den Funktions- und Integrationstest im Gesamtfahrzeug an – in ei-nem Prototypen also. Da diese Vorabexemplare einer späteren Serienferti-gung sehr teuer sind, ist es umso wichtiger, dass alle elektrischen Funktio-nen, die im Komponententest und HiL außerhalb des Automobils getestet wurden, reibungslos funktionieren. Der Prototypen-Test sichert, dass das Fahrzeug an den Kunden ausgeliefert werden kann. Mit ihm gibt der Her-steller die Fahrzeugfunktionen frei. Die gesamten Erprobungsergebnisse der E/E-Systeme – vom Check der einzelnen Komponenten bis zur Testfahrt mit dem Prototypen – werden dokumentiert und in einer zentralen Datenbank abgelegt. So lassen sich die Ergebnisse zentral verfolgen und bei Bedarf heranziehen – zum Beispiel wenn es darum geht, eine neue Funktionsva-riante oder einen weiteren Kundenwunsch zu berücksichtigen. So gibt der modulare, von Software getriebene und ausreichend qualitätsgesicherte Entwicklungsansatz den Herstellern jene Flexibilität, die sie im Wettbewerb brauchen. Der Autogeburtstag im kommenden Jahr kann also kommen.

Mehr Infos unter: www.iqnite-conferences.com

Jennifer Rush

Durch Ihre Teilnahme an der Gala

unterstützen Sie die Entwicklung

einer alternativen Bewegungs-

therapie für Parkinsonkranke in

der Fachklinik Beelitz-Heilstätten

Jennifer Rushund weitere und weitere Künstlerund weitere

LIVEAUF DER

TULIP !

www.parkinson-gala.org

Die Deutsche Parkinson GalaTULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010

20.11.2010Kongresshotel Potsdam am Templiner See

Medienpartner

Der Autor

Volker WilhelmiwarKeynote-ReferentaufderKonferenziqnite.Diesefandvom28.–30.April2010inDüsseldorf statt. Die Konferenz zählt zu den wichtigsten Foren für den Gedanken- und Ideenaustausch innerhalb der Software Quality Community.


Jennifer Rush

Durch Ihre Teilnahme an der Gala

unterstützen Sie die Entwicklung

einer alternativen Bewegungs-

therapie für Parkinsonkranke in

der Fachklinik Beelitz-Heilstätten

Jennifer Rushund weitere und weitere Künstlerund weitere

LIVEAUF DER

TULIP !

www.parkinson-gala.org

Die Deutsche Parkinson GalaTULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010TULIP 2010

20.11.2010Kongresshotel Potsdam am Templiner See

Medienpartner

http://www.parkinson-gala.org

Course Unit:ManagementCoursManag

Course Unit:Technology

Capability AdvisorLearning System

CoursTechn

Course Unit:Pedagogy

ECQA

Job Role:E-Learning

Manager

Exam forCertification

elmThe Project:

Links:

he overall aim of the ELM project is to transfer a successful online assess-ment and quali�cation system to the recognition and accreditation of the role of European e-learning manager. The project uses an integrated capability advisor and learning management system to assess prior knowledge and o�er online, multimedia-rich training courses. Certi�cation is o�ered through the ECQA exam portal and certi�cation system.

ELM Project Website: http://deis.ie/elmECQA Website: http://ecqa.orgDEIS Website: http://deis.ie

T

“e-learning fore-learning managers”

Interview Ausgabe 16 | September 2010 18

Mr Ó Súilleabháin, Sie betreiben schon seit einiger Zeit Forschungen zum Thema E-Learning und halten Vorlesungen zum Thema an Hochschulen. Wä-ren Sie so freundlich für uns zusammenzufassen, was E-Learning genau be-deutet? Es existieren sehr unterschiedliche Ansichten darüber, was E-Learning genau ist. Für einige bedeutetes es lediglich Lernen über das Internet, für andere de-finiert es sich weitaus umfassender – digitale Technologie trifft auf Lernen und schließt dabei auch Bildungsfernsehen, Videokonferenzen, DVD/Bluray, Mo-bilfunktechnologie, Computerspiele usw. mit ein. Für mich persönlich finde ich, dass es am meisten Sinn macht, E-Learning von anderen, vorhergehen-den Traditionen wie Fernstudium und computergestütztem Lernen zu unter-scheiden, indem man einfach sagt, E-Learning kann beides: Fern- und Face to Face-Unterricht und die hauptsächlich dafür verwandten Technologien sind web-basiert. Das Gebiet als solches ist vermutlich am ehesten als eine Verschmelzung von Pädagogik oder Lerntheorien mit Technologie zu sehen.

Anders als in der Berufsausbildung oder höheren Bildung, müssen die Ent-scheidungsträger in privaten Einrichtungen noch vom Konzept des E-Lear-nings überzeugt werden. Wieso sollte ein Unternehmen sich mit E-Learning befassen? Ich bin nicht sicher, ob es stimmt, dass die Firmenwelt besonders langsam bei der Einführung von E-Learning war. Es könnte allerdings stimmen, dass die Art des E-Learnings, die dort angewendet wird, sehr unterschiedlich von der ist, die von Instituten der höheren Bildung favorisiert wird. Zum Beispiel schienen viele der Firmenkunden, die ich betreut habe, synchrone oder Live E-Learning Tools wir Adobe Connect oder Centra Symposium den traditi-onellen und größtenteils asynchronen Learning und Content Management Systemen vorzuziehen. Jemandem, der gerade anfängt sich mit E-Learning zu befassen, empfeh-le ich Kinderschritte zu machen, also klein anzufangen mit einem gut defi-nierten Pilotprojekt. Alle Beteiligten müssen mit einbezogen und teure frühe Fehler vermieden werden. Jede Implementierung sollte beides berücksich-tigen: Das Lernen und die Lernenden. Also beispielsweise was sollen die Lernenden lernen? (Welche Art von Lernen ist das? Auf welchem Niveau wird gelernt und wie soll das Erreichte messbar gemacht werden?) Auch muss berücksichtigt werden, wer die Lernenden sind (sind sie zum Beispiel Web-affin? Sind sie gut im selbstständigen Lernen? Sind sie viel unterwegs? etc. etc.).

Die Verantwortung für ein E-Learning Projekt zu tragen ist eine reizvolle und facettenreiche Aufgabe, die profundes Wissen des E-Learning Managers er-fordert. Da Sie gemeinsam mit dem iSQI und anderen Partnern eine Berufs-beschreibung für den E-Learning Manager entwickelt haben, wer denken Sie profitiert am meisten von der Zertifizierung/dem Training? Wir wollten den Kurs und die Zertifizierung natürlich an diejenigen rich-ten, deren Hauptaufgabe im Beruf es ist, E-Learning Projekte zu managen. Gleichzeitig aber – und vielleicht etwas weniger offensichtlich – wollten wir auch denjenigen etwas bieten, die vielleicht nicht jeden Tag oder noch nicht einmal jeden Monat mit E-Learning arbeiten, die aber dennoch damit betraut

Interview mit Gearoid Ó Súilleabháin, leitender Koordinator des E-Learning Manager (ELM) Projekts

Course Unit:ManagementCoursManag

Course Unit:Technology

Capability AdvisorLearning System

CoursTechn

Course Unit:Pedagogy

ECQA

Job Role:E-Learning

Manager

Exam forCertification

elmThe Project:

Links:

he overall aim of the ELM project is to transfer a successful online assess-ment and quali�cation system to the recognition and accreditation of the role of European e-learning manager. The project uses an integrated capability advisor and learning management system to assess prior knowledge and o�er online, multimedia-rich training courses. Certi�cation is o�ered through the ECQA exam portal and certi�cation system.

ELM Project Website: http://deis.ie/elmECQA Website: http://ecqa.orgDEIS Website: http://deis.ie

T

“e-learning fore-learning managers”

http://deis.ie/elm


Anzeige

Düsseldorf: 27.-29.10.2010: TOSCA Certified User Foundation Level (Unterrichtssprache: Deutsch)

Zürich: 10.-12.11.2010: TOSCA Certified User Foundation Level (Unterrichtssprache: Englisch)

Wien: 13.-15.10.2010: TOSCA Certified User Foundation Level17.-19.11.2010: TOSCA Certified Quality Designer01.-03.12.2010: TOSCA Certified User Advanced Level(Unterrichtssprache aller Termine: Deutsch)

Öffentliche Trainings erstmals auch in Deutschland und in der Schweiz

TOSCA Testsuite™Elevates Software Testing to a business discipline

sind, E-Learning Lösungen zu beschaffen. Unserer Erfah-rung nach arbeiten solche Individuen auf Managementebene in einer Personal- oder Fortbildungsabteilung und tragen die Verantwortung für eine ganze Reihe von sehr unterschiedli-chen Aufgaben. Für Erstere bieten wir eine Qualifizierung, wo es vorher noch keine gab und erkennen auch vorhergehend Gelerntes an. Für Letztere bieten wir einen angemessenen Level von akkreditierten Fähigkeiten und Wissen, um sie bei der Auswahl aus den vielfältigen E-Learning Angeboten nach pädagogischen, technischen und wirtschaftlichen Gesichts-punkten zu unterstützen. Ich glaube wirklich, dass beide Gruppen von dieser Erfahrung profitieren werden.

Wie ist der Kurs aufgebaut? Welche Module werden unterrichtet?Es gibt drei Hauptabschnitte: Pädagogik, Technologie und Management. Jede dieser Einheiten ist in eine gewisse Anzahl von Elementen unterteilt. Die Elemente setzen sich aus Fähigkeits- und Wissensgebieten zusammen, die man beherrschen sollte, um effektives E-Learning zu bieten, zu entwickeln oder zu beschaffen. Die Technologie-Einheit zum Beispiel setzt sich zusammen aus Elementen wie der Ent-wicklung von E-Learning Inhalten, Nutzung von E-Learning Tools, E-Learning Plattformen, der Bereitstellung von E-Lear-

ning und aufkommenden Trends im Bereich des E-Learnings. Diese Einheiten und Elemente, die das “Skill Set” des E-Learning Manager Kurses bilden, wurden mit Hilfe des Feed-backs von professionellen E-Learning Managern und durch extensives Studieren und Auswerten der vorhandenen Li-teratur entwickelt. Sie repräsentieren das „ideale“ Set von Wissen und Fähigkeiten, über das ein effektiver E-Learning Manager verfügen sollte.

Wo erhalte ich das E-Learning Manager (ELM) Training und wie lange dauert es? Das E-Learning Manager Training wird über die European Certification and Qualification Association (www.ecqa.org) zu beziehen sein. Hier ist es möglich, den E-Learning Mana-ger Kurs über ein integriertes e-Portfolio und Lernmanage-ment System zu absolvieren und anschließend eine europa-weit anerkannte Zertifizierungsprüfung abzulegen. Derzeit geht das Projekt in die zweite Pilotphase. Es gibt nun eine überarbeitete Version des Kursinhalts basierend auf dem Feedback der ersten Pilotphase, die früher in diesem Jahr stattfand. Jeder, der sich für die Teilnahme an der zwei-ten Pilotphase oder für eine Zertifizierung interessiert, kann sich auf der Projekt-Website unter http://deis.ie/elm/register registrieren.

Düsseldorf: 27.-29.10.2010: TOSCA Certified User Foundation Level (Unterrichtssprache: Deutsch)

Zürich: 10.-12.11.2010: TOSCA Certified User Foundation Level (Unterrichtssprache: Englisch)

Wien: 13.-15.10.2010: TOSCA Certified User Foundation Level17.-19.11.2010: TOSCA Certified Quality Designer01.-03.12.2010: TOSCA Certified User Advanced Level(Unterrichtssprache aller Termine: Deutsch)

Öffentliche Trainings erstmals auch in Deutschland und in der Schweiz

TOSCA Testsuite™Elevates Software Testing to a business discipline

http://www.tosca-testsuite.com/training

Informationen und Anmeldung:www.technologieforum.com

9.Technologie-Forum

Making Change Happen:Wandel als Chance - oder lost in transition?

Melden Sie sich jetzt schon an und profitieren Sie von unserem Frühbucherrabatt!

2. Dezember 2010, Sheraton, Nürnberg

Auf dem diesjährigen Technologie-Forum dreht sich alles um das Thema Wandel. Erfahren Sie mehr über Trends, Möglichkeiten und Anforde-rungen im Systems und Software Engineering, wo sich Unternehmen in immer kürzeren Ent-wicklungszyklen immer neuen Veränderungen stellen müssen. Renommierte Referenten zeigen Ihnen in praxisnahen Case Studies Wege,

wie Sie die Chancen nutzen können, die Ihnen der kontinuierliche Wandel bietet. Sie erhalten Hilfestellungen, wie Ihr Unternehmen die zahl-reichen Herausforderungen meistert, die Ver-änderung mit sich bringt. Der amerikanische Experte Paul Nielsen, CEO des Software Engi-neering Institute, berichtet als Keynote-Speaker aus seinem Wissens- und Erfahrungsschatz.

Informationen und Anmeldung:www.technologieforum.com

9.Technologie-Forum

Making Change Happen:Wandel als Chance - oder lost in transition?

Melden Sie sich jetzt schon an und profitieren Sie von unserem Frühbucherrabatt!

2. Dezember 2010, Sheraton, Nürnberg

Auf dem diesjährigen Technologie-Forum dreht sich alles um das Thema Wandel. Erfahren Sie mehr über Trends, Möglichkeiten und Anforde-rungen im Systems und Software Engineering, wo sich Unternehmen in immer kürzeren Ent-wicklungszyklen immer neuen Veränderungen stellen müssen. Renommierte Referenten zeigen Ihnen in praxisnahen Case Studies Wege,

wie Sie die Chancen nutzen können, die Ihnen der kontinuierliche Wandel bietet. Sie erhalten Hilfestellungen, wie Ihr Unternehmen die zahl-reichen Herausforderungen meistert, die Ver-änderung mit sich bringt. Der amerikanische Experte Paul Nielsen, CEO des Software Engi-neering Institute, berichtet als Keynote-Speaker aus seinem Wissens- und Erfahrungsschatz.

http://www.technologieforum.com

STA

ND

: Sep

tem

ber

2010

Datum Tage Schulungstitel Ort Anbieter

06.09.10 4 ISTQB® Certified Tester, Foundation Level Wien ANECON Software Design und Beratung GmbH

06.09.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Berlin Díaz & Hilterscheid Unternehmsberatung GmbH

06.09.10 3,5 ISTQB® Certified Tester, Foundation Level Wiesbaden Muth Partners GmbH

06.09.10 5 iNTACS™ Certified ISO/IEC 15504 Provisional Assessor Frankfurt a.M. SQS AG

13.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Dresden ANECON Software Design und Beratung GmbH

13.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Dresden ANECON Software Design und Beratung GmbH

13.09.10 4 ISTQB® Certified Tester, Foundation Level Berlin Díaz & Hilterscheid Unternehmsberatung GmbH

13.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst München Logica Deutschland GmbH & Co. KG

13.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager München Method Park Software AG

13.09.10 4 ISTQB® Certified Tester, Foundation Level Köln SQS AG

13.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Wien SQS AG

13.09.10 4 iSQI® Certified Professional for Project Management Köln SQS AG

14.09.10 4 ISTQB® Certified Tester, Foundation Level Dresden ANECON Software Design und Beratung GmbH

14.09.10 4 iSAQB® Certified Professional for Software Architecture Düsseldorf BITPlan GmbH

14.09.10 4 ISTQB® Certified Tester, Foundation Level Erlangen Method Park Software AG

20.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Berlin Díaz & Hilterscheid Unternehmsberatung GmbH

20.09.10 4 ISTQB® Certified Tester, Foundation Level Neustadt/Weinstr. EXCO GmbH

20.09.10 5 ECQA® Certified Innovation Manager Erlangen ISCN Ltd.

20.09.10 3 iSAQB® Certified Professional for Software Architecture Berlin Method Park Software AG

20.09.10 5 iNTACS™ Certified ISO/IEC 15504 Provisional Assessor Erlangen Method Park Software AG

20.09.10 4 ISTQB® Certified Tester, Foundation Level Stuttgart SQS AG

20.09.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Essen SQS AG

20.09.10 5 ISTQB Certified Tester, Advanced Level, Technical Test Analyst Wien ANECON Software Design und Beratung GmbH

22.09.10 3 TTCN-3® Testing and Test Control Notation Berlin Testing Technologies IST GmbH

27.09.10 4 ISTQB® Certified Tester, Foundation Level Hamburg SQS AG

27.09.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Frankfurt a.M. SQS AG

27.09.10 4 ISTQB® Certified Tester, Foundation Level München TESNET GROUP GMBH

27.09.10 4 ISTQB® Certified Tester, Foundation Level Wien OBJENTIS Software Integration GmbH


04.10.10 4 ISTQB® Certified Tester, Foundation Level München Logica Deutschland GmbH & Co. KG

04.10.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Berlin Method Park Software AG

04.10.10 3,5 ISTQB® Certified Tester, Foundation Level Bönnigheim (Stgt.) Muth Partners GmbH

04.10.10 4 ISTQB® Certified Tester, Foundation Level Wien SQS AG

04.10.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Köln SQS AG

06.10.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Wien ANECON Software Design und Beratung GmbH

06.10.10 5 ISTQB Certified Tester, Advanced Level, Test Analyst (englisch) Wien ANECON Software Design und Beratung GmbH

11.10.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager München Díaz & Hilterscheid Unternehmsberatung GmbH

11.10.10 3,5 ISTQB® Certified Tester, Foundation Level Hamburg Muth Partners GmbH

11.10.10 4 ISTQB® Certified Tester, Foundation Level München SQS AG

11.10.10 5 iNTACS™ Certified ISO/IEC 15504 Provisional Assessor Hamburg SynSpace GmbH

18.10.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Hamburg Logica Deutschland GmbH & Co. KG

18.10.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Wien SQS AG

International Software Quality Institute


Schulungen 20104. Quartal (Auswahl – Weitere Termine auf www.isqi.org/schulungen-mit-zert/)Certified Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt.Das iSQI fungiert hier als Vermittler. Anmeldeformular und Preise unter www.isqi.org.

� � � ��

http://www.isqi.org/nc/schulungen-mit-zert/tester/foundation-level/

http://www.isqi.org/zertifizierung/istqbR-certified-tester/advanced-level/


http://www.isqi.org/nc/schulungen-mit-zert/isoiec-15504-assesor/provisional/








http://www.isqi.org/nc/schulungen-mit-zert/project-management/


http://www.isqi.org/nc/schulungen-mit-zert/software-architecture/




http://www.isqi.org/schulungen-mit-zert/innovation-manager/






http://www.isqi.org/nc/seminare/programm/?sid=166



















http://www.isqi.org

http://www.isqi.org

http://www.diazhilterscheid.de

http://www.sqs.de

http://www.oose.de

http://www.methodpark.de

http://www.iscn.com

http://www.tesnet-group.de

http://www.andagon.de

http://www.testingtech.com

http://www.seppmed.de

http://www.anecon.at

http://www.logica.com

http://www.muthpartners.de

http://www.interface-gmbh.de

http://www.virtualforge.de

http://www.bitplan.com

http://www.exco.de/

http://www.objentis.com

http://www.tricentis.com

http://www.synspace.com

[Fortsetzung Schulungen 2010]

18.10.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Hamburg SQS AG

19.10.10 3 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. Díaz & Hilterscheid Unternehmsberatung GmbH

20.10.10 3 ISTQB® Certified Tester, Foundation Level Röttenbach sepp.med gmbh

25.10.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Stuttgart Díaz & Hilterscheid Unternehmsberatung GmbH

25.10.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager München Logica Deutschland GmbH & Co. KG

25.10.10 3 iSAQB® Certified Professional for Software Architecture Hamburg Method Park Software AG

25.10.10 4 iSQI® Certified Professional for Project Management Erlangen Method Park Software AG

25.10.10 4 ISTQB® Certified Tester, Foundation Level Berlin SQS AG

25.10.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Frankfurt a.M. SQS AG

25.10.10 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. TESNET GROUP GMBH

26.10.10 4 ISTQB® Certified Tester, Foundation Level München SynSpace GmbH


02.11.10 4 ISTQB® Certified Tester, Foundation Level München Díaz & Hilterscheid Unternehmsberatung GmbH

08.11.10 4 ISTQB® Certified Tester, Foundation Level Dresden ANECON Software Design und Beratung GmbH

08.11.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Berlin Díaz & Hilterscheid Unternehmsberatung GmbH

08.11.10 4 ISTQB® Certified Tester, Foundation Level Wien SQS AG

08.11.10 4 ISTQB® Certified Tester, Foundation Level Hannover SQS AG

08.11.10 4 iSQI® Certified Professional for Project Management Frankfurt a.M. SQS AG

08.11.10 4 ISTQB® Certified Tester, Foundation Level München TESNET GROUP GMBH

09.11.10 4 iSAQB® Certified Professional for Software Architecture Düsseldorf BITPlan GmbH

10.11.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Wien ANECON Software Design und Beratung GmbH


15.11.10 5 ECQA® Certified Software Process Improvement Manager Erlangen ISCN Ltd.

15.11.10 5 ECQA® Certified Software Process Improvement Manager Erlangen Method Park Software AG

15.11.10 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. SQS AG

22.11.10 5 iNTACS™ Certified ISO/IEC 15504 Competent Assessor Hamburg SynSpace GmbH

22.11.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. Díaz & Hilterscheid Unternehmsberatung GmbH

22.11.10 5 ECQA® Certified Innovation Manager Erlangen ISCN Ltd.

22.11.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Köln Logica Deutschland GmbH & Co. KG

22.11.10 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. Logica Deutschland GmbH & Co. KG

22.11.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst München Method Park Software AG

22.11.10 5 ECQA® Certified Innovation Manager Erlangen Method Park Software AG

22.11.10 3,5 ISTQB® Certified Tester, Foundation Level Hannover Muth Partners GmbH

22.11.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager München SQS AG

22.11.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Wien SQS AG

22.11.10 5 iNTACS™ certified ISO/IEC 15504 Competent Assessor Köln SQS AG

22.11.10 3 ISSECO® Certified Professional for Secure Software Engineering Köln SQS AG

22.11.10 3 TTCN-3® Testing and Test Control Notation Berlin Testing Technologies IST GmbH

22.11.10 4 ISTQB® Certified Tester, Foundation Level Wien OBJENTIS Software Integration GmbH

29.11.10 4 ISTQB® Certified Tester, Foundation Level (englisch) Wien ANECON Software Design und Beratung GmbH

29.11.10 5 iNTACS™ Certified ISO/IEC 15504 Provisional Assessor Erlangen Method Park Software AG

29.11.10 3,5 ISTQB® Certified Tester, Foundation Level Bochum Muth Partners GmbH

29.11.10 4 ISTQB® Certified Tester, Foundation Level Hamburg oose Innovative Informatik GmbH

29.11.10 4 ISTQB® Certified Tester, Foundation Level Köln SQS AG

29.11.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Frankfurt a.M. SQS AG

06.12.10 5 iNTACS™ Certified ISO/IEC 15504 Provisional Assessor Frankfurt a.M. SynSpace GmbH

06.12.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. Logica Deutschland GmbH & Co. KG

06.12.10 3 iSAQB® Certified Professional for Software Architecture München Method Park Software AG

06.12.10 4 ISTQB® Certified Tester, Foundation Level Hamburg Method Park Software AG

06.12.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. SQS AG

06.12.10 4 ISTQB® Certified Tester, Foundation Level Dresden SQS AG

06.12.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Köln SQS AG

06.12.10 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. TESNET GROUP GMBH























http://www.isqi.org/schulungen-mit-zert/software-process-improvement-manager/

http://www.isqi.org/schulungen-mit-zert/software-process-improvement-manager/


http://www.isqi.org/nc/schulungen-mit-zert/isoiec-15504-assesor/competent/










http://www.isqi.org/nc/schulungen-mit-zert/isoiec-15504-assesor/competent/

http://www.isqi.org/schulungen-mit-zert/secure-software-engineering/

















Datum Dauer Titel Ort Anbieter

03.09.10 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH

08.09.10 3 Testmethodik - das Richtige Testen München GQ-Solutions

13.09.10 3 Testmanagement - effizient und einfach München GQ-Solutions

13.09.10 5 Das Analytiker-Seminar mit UML Hamburg oose Innovative Informatik GmbH

13.09.10 5 Praktische Softwarearchitektur Hamburg oose Innovative Informatik GmbH

13.09.10 4 Java für fortgeschrittene Anwendungsentwickler Hamburg oose Innovative Informatik GmbH

14.09.10 3 SEI autorisiertes CMMI®-DEV Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE

14.09.10 3 SEI autorisiertes CMMI®-SVC Einführungstraining Version 1.2 Warschau KUGLER MAAG CIE

15.09.10 3 Einführung in das Capability Maturity Model (CMMI®) Kiel Anywhere.24 GmbH

16.09.10 2 Testmanagement auf Basis von HP Quality Center 10.0 Berlin QMETHODS - Business & IT Consulting GmbH

17.09.10 1 Services Supplement for CMMI® V1.2 Kornwestheim KUGLER MAAG CIE

20.09.10 4 Testgetriebene Softwareentwicklung Hamburg oose Innovative Informatik GmbH

20.09.10 5 Kommunikation & Moderationstechniken Hamburg oose Innovative Informatik GmbH

20.09.10 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag) Hamburg oose Innovative Informatik GmbH

22.09.10 3 Einführung in das Capability Maturity Model® Integration (CMMI®) Berlin Method Park Software AG

23.09.10 2Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von IBMCognos8

Berlin QMETHODS - Business & IT Consulting GmbH

27.09.10 2 SafetyNormIEC61508 Erlangen Method Park Software AG

28.09.10 3 SEI autorisiertes CMMI®-SVC Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE

29.09.10 3 Grundlagen des Systems Engineering Erlangen Method Park Software AG

04.10.10 5 Agiles Software-Projektmanagement Hamburg oose Innovative Informatik GmbH


04.10.10 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Zertifizierung) Hamburg oose Innovative Informatik GmbH

04.10.10 3 Einführung in das Capability Maturity Model (CMMI®) München Anywhere.24 GmbH

04.10.10 5 Paketangebot Einführung in CMMI-DEV+ACQ+SVC München Anywhere.24 GmbH

05.10.10 3 Das modellzentrierte Testen Röttenbach sepp.med gmbh

06.10.10 2 EffizienteTestautomatisierungmitTTCN-3–GrundlagenundAnwendungen Erlangen Fraunhofer FOKUS

07.10.10 2 Implementierung und Test auf Basis des SAP Solution Manager 7.0 Berlin QMETHODS - Business & IT Consulting GmbH

07.10.10 1 Upgrate zu CMMI für Akquisition/Beschaffung München Anywhere.24 GmbH

07.10.10 1 Lernen Sie die IBM Rational Testsuite kennen (kostenfreies Seminarangebot) Frankfurt a.M. QMETHODS - Business & IT Consulting GmbH / IBM


08.10.10 1 Upgrade CMMI® for Services München Anywhere.24 GmbH

08.10.10 1 LernenSieIBMCognos8BIundPlanningkennen(kostenfreiesSeminarangebot) Frankfurt a.M. QMETHODS - Business & IT Consulting GmbH / IBM

11.10.10 1 Modellierung mit UML2 Röttenbach sepp.med gmbh

12.10.10 1 Einführung in die Simulation Röttenbach sepp.med gmbh

13.10.10 1 TTCN-3undUTPfürSchnelleinsteiger Röttenbach sepp.med gmbh

13.10.10 2Funktionale Sicherheit von softwarebestimmten Systemen / Sicherheitsrelevante Automotive Software

Kornwestheim KUGLER MAAG CIE



Seminare 2010

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

4. Quartal (Auswahl – Weitere Termine auf www.isqi.org/nc/seminare/programm)

07.12.10 3 ISTQB® Certified Tester, Foundation Level Düsseldorf/Köln Díaz & Hilterscheid Unternehmsberatung GmbH

13.12.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Berlin Díaz & Hilterscheid Unternehmsberatung GmbH

13.12.10 4 ISTQB® Certified Tester, Foundation Level Hamburg Logica Deutschland GmbH & Co. KG

13.12.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Köln SQS AG

13.12.10 4 ISTQB® Certified Tester, Foundation Level München SQS AG

13.12.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Hamburg SQS AG


Alle Themen auch als Inhouse-Angebot buchbar!





































http://www.isqi.org








STA

ND

: Sep

tem

ber

2010

Zusätzliche Inhouse-Themen finden Sie auf unserer Website www.isqi.org!Möchten auch Sie Ihr Seminar im nächsten SQ-Magazin bewerben, dann kontaktieren Sie bitte Franziska Böckenkamp (Kontakt s. unten)!

iSQI GmbH | www.isqi.org

AmWeichselgarten1991058Erlangen

Tel +49913191910-0Fax+49913191910-10

David-Gilly-Straße 1 14469Potsdam

Tel +49331231810-0Fax+49331231810-10

Ansprechpartner One Stop Agency Services:Franziska Böckenkamp

E-Mail: [email protected]+49331231810-40

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

[Fortsetzung Seminare 2010]

13.10.10 3 TOSCA Testsuite™ Certified User Foundation Level Wien TRICENTIS Technology & Consulting GmbH


18.10.2010 3 Systems Engineering Praxis mit SYSML München Anywhere.24 GmbH

21.10.10 2 Test und Testmanagement in agilen Projekten Wien ANECON Software Design und Beratung GmbH

25.10.10 2 Testmethodik für Software Entwickler München GQ-Solutions


27.10.10 1 Funktionale Sicherheit von sicherheitsbezogenen HW/SW-Systemen Röttenbach sepp.med gmbh

27.10.10 3 TOSCA Testsuite™ Certified User Foundation Level Düsseldorf TRICENTIS Technology & Consulting GmbH

28.10.10 2 Last-undPerformancetestaufBasisvonHPLoadRunner9.5 Berlin QMETHODS - Business & IT Consulting GmbH


01.11.10 3 Testmethodik - das Richtige Testen München GQ-Solutions

02.11.10 3 Validierung in der Pharmabranche Röttenbach sepp.med gmbh

04.11.10 2 Testautomation auf Basis von HP QuickTest Professional 10.0 Berlin QMETHODS - Business & IT Consulting GmbH



08.11.10 3 Einführung in das Capability Maturity Model (CMMI®) Zürich Anywhere.24 GmbH

10.11.10 3 TOSCA Testsuite™ Certified User Foundation Level Zürich TRICENTIS Technology & Consulting GmbH


15.11.10 5 Agiles Software-Projektmanagement Hamburg oose Innovative Informatik GmbH

15.11.10 1 Funktionaler und Nicht-funktionaler Test von HW/SW-Systemen Röttenbach sepp.med gmbh

16.11.10 3 Qualitätssicherung in der Medizin Röttenbach sepp.med gmbh

16.11.10 3 SEI autorisiertes CMMI®-DEV Einführungstraining Version 1.2 Warschau KUGLER MAAG CIE

17.11.10 3 TOSCA Testsuite™ Certified Quality Designer Wien TRICENTIS Technology & Consulting GmbH

22.11.10 3 Testmanagement - effizient und einfach München GQ-Solutions

22.11.10 5 Kommunikation & Moderationstechniken Hamburg oose Innovative Informatik GmbH

22.11.10 5 Java für Anwendungsentwickler Hamburg oose Innovative Informatik GmbH

25.11.10 2Service Desk und Change Request Management auf Basis des SAP Solution Manager 7.0




29.11.10 4 Java für fortgeschrittene Anwendungsentwickler Hamburg oose Innovative Informatik GmbH

01.12.10 2 EffizienteTestautomatisierungmitTTCN-3–GrundlagenundAnwendungen Erlangen Fraunhofer FOKUS

01.12.10 3 TOSCA Testsuite™ Certified User Advanced Level Wien TRICENTIS Technology & Consulting GmbH

02.12.10 2 Testmanagement auf Basis von HP Quality Center 10.0 Berlin QMETHODS - Business & IT Consulting GmbH



13.12.10 5 Das Analytiker-Seminar mit UML Hamburg oose Innovative Informatik GmbH

13.12.10 4 Testgetriebene Softwareentwicklung Hamburg oose Innovative Informatik GmbH


14.12.10 2 Testmethodik für Software Entwickler München GQ-Solutions

15.12.10 3 Einführung in das Capability Maturity Model (CMMI®) München Anywhere.24 GmbH

16.12.10 2Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von IBMCognos8



20.12.10 3 Einführung in CMMI®forServices(3-Tage-Kurs) München Anywhere.24 GmbH

Alle Themen auch als Inhouse-Angebot buchbar!















































Abbildung 1: Testaufbau DAB Tuner

Advertorial

Advertorial

Stellen Sie sich vor, Sie kaufen in einer Apotheke ein kleines Messgerät zur Bestimmung Ihres Blutzu-ckers. Dass dieses Gerät Software enthält, ahnen Sie sicher schon auf Grund der digitalen Anzeige. Allzu viel Geld haben Sie vermutlich dafür nicht ausgegeben – im Verhältnis zu so manch anderen Dingen, die Sie in einer Apotheke kaufen kön-nen. Was erwarten Sie aber von der Qualität des Gerätes? Sicher doch, dass es Ihre Blut-zuckerwerte genau bestimmt, dass das Ergebnis schnell an-gezeigt wird, dass die Handhabung so einfach ist, dass auch Ihre Großeltern dieses Gerät ohne Schwierigkeiten nutzen können, dass Sie keine unbeabsichtigten Fehler machen kön-nen… Also eine hohe Qualität, die sichergestellt sein muss.

Sind Sie von Beruf Software-Tester, erkennen Sie, dass es ei-nige mögliche Situationen gibt, die lebensbedrohlich für den Anwender sein können: Was, wenn der angezeigte Wert so falsch berechnet wird, dass die darauf aufbauende Insulin-Dosis zu gering oder zu hoch wäre?

Eine Rückrufaktion möchte keiner der Hersteller medizintechnischer GeräteDass solche Fragen nicht trivial sind, zeigt eine Auswertung der Rückrufe der zuständigen Behörde zur Zulassung von Medizinprodukten in den USA (FDA). Die Auswertung der von April bis Juni 2010 erfassten 500 Rückrufe ergab, dass 50 Produkte aufgrund von Softwarefehlern bemängelt wur-den. Weitere 101 Rückrufe lassen sich allgemein dem Be-reich Elektrik/ Programmierbare Elektronik zuordnen. Ein besonders hohes Risiko für das Leben der Patienten stellt

ein Softwarefehler dar, bei dem durch einen plötzlichen Shut-down die Zufuhr von Narkosemitteln und das gleichzeitige Monitoring des Patienten abbrachen. Nur 4 von 37 Fehlern sind von geringem Risiko, wie beispielsweise das Ignorieren bestimmter Zeichen, wie # @ 1 \ ] ‚ ( I ) bei der Sprachum-stellung, aber auch diese führten zu Rückrufen, die dem Her-steller hohe Kosten und einen Imageschaden verursachten. Solche Fehler können durch sorgfältiges Testen gefunden werden. Die mit einer Rückrufaktion verbundenen Kosten, der Imageschaden und drohende Verkaufsverbote sind hohe Risiken für die Unternehmen, die sie durch unterschiedlichs-te Maßnahmen und eben auch durch professionelles Testen unter allen Umständen vermeiden möchten.

Mit risikobasiertem Testen zur erfolgreichen MarkteinführungIm obigen Beispiel des Blutzuckermessgerätes wurde dies durch einen risikobasierten Ansatz realisiert, der erst jede spezifizierte Anforderung bewertet und dann eine dazuge-hörige Teststrategie definiert. Dies erlaubt eine effiziente Verteilung der Testtiefe und Gewichtung der Aktivitäten und bietet den weiteren Vorteil, dass entwicklungsbegleitend getestet werden kann. Bereits in den frühen Projektphasen wurden Testspezifikationen erstellt, die teils automatisiert, teils manuell durchgeführt wurden, sobald die ersten Geräte die Testeingangskriterien bestanden. Die dazu erforderlichen Tools und Umgebungen wurden regulatorisch bedingt CSV-validiert. Das Projekt-Team bestand aus sieben bis acht Soft-ware-Testerinnen und –Testern unseres Unternehmens sowie ein bis vier Testern von Seiten des Kunden. Alle Tester waren selbstverständlich mindestens als Certified Tester Foundati-on Level zertifiziert und hatten langjährige Erfahrung im Be-reich des Testens medizintechnischer Anwendungen. Nach der dreijährigen Laufzeit des Verifizierungs-Projektes stand einer Markteinführung im März 2009 nichts mehr im Wege.

Seit 1994 nutzt EXCO einen ausgefeilten Prozess zum risi-kobasierten Testen medizintechnischer Geräte, der entspre-chend den Anforderungen der jeweiligen Pharmaunterneh-men auf deren Bedürfnisse und konkrete Projektsituationen angepasst wird.

Unsere Projekterfahrungen und unser Spezialwissen in der Medizintechnik geben wir in unseren Certified Tester Schu-lungen an Sie weiter. Nächste ISTQB® CTFL Schulung: 20.-23.09.2010. Infos und Anmeldung unter www.exco.de.

Wenn Ihr Leben davon abhängt, dass Software einwandfrei funktioniert Thomas Wolf, Head of Division Quality & Compliance, EXCO GmbH

Thomas Wolf

Blutzuckermessgeraete

http://www.exco.de


Agilität und Verteilte Entwicklung?Agile und Verteilte Entwicklung scheinen nicht besonders gut zueinander zu passen. In der Agilen Entwicklung wird auf Kommunikation eher mehr Wert gelegt als bei anderen Vorgehensmodellen: tägliche Treffen der Entwickler, häufige Rücksprachen mit dem Kunden. Verteilte Entwicklung da-gegen macht die Kommunikation schwer. Unter Verteilung verstehe ich eine räumliche Entfernung, die ein einfaches Zusammenkommen der Entwickler ohne große Vorbereitung verhindert, etwa mehr als 200km.

Wird die Entfernung noch größer, dann kommen verschie-dene Zeitzonen dazu, d.h. die in einem 24-Stunden-Zeit-raum für gemeinsame Besprechungen effektiv verfügbare Zeit schrumpft erheblich. Unterschiedliche Feiertage in verschiedenen Ländern reduzieren diese Zeit weiterhin. Sprachbarrieren, kulturelle Unterschiede und unterschied-liche Ausbildung wirken weiterhin erschwerend. Auch wer sich mehrfach rückversichert, dass das Gesagte auch als das Gemeinte verstanden wurde, wird nicht gefeit sein ge-gen Mißverständnisse.

Agilität oder Verteilte Entwicklung?Wenn agile und verteilte Entwicklung nicht zusammen pas-sen, dann wäre es das einfachste, sich für eines von beiden zu entscheiden. Das macht die Sache aber nicht besser. In

unseren Projekten bestehen die Kunden in aller Regel darauf, die Software, die wir entwickeln, nicht nur zu bestellen, zu bezahlen und die Anforderungen vorzugeben, sondern sie wollen selbst aktiv mitarbeiten. Da unsere Kunden über die Welt verteilt sind, heißt das zwangsläufig verteilte Entwick-lung.

Ein nicht-agiles Vorgehensmodell, etwa ein starres V-Modell, schützt uns andererseits nicht vor Mißverständnissen in der Kommunikation: Unterschiedlich gebrauchte, scheinbar selbstverständliche Begriffe wie „Prototyp“, nie ausgespro-chene, weil ebenfalls als selbstverständlich vermutete Anfor-

derungen usw. sind keine Eigenheiten agilen Vorge-hens. Agile Modelle lassen uns solche Mißverständnis-se und Lücken aber erheb-lich schneller erkennen und korrigieren!

Technische Infrastruktur zur KommunikationHeute existieren eine gan-ze Vielzahl von Hilfsmitteln, mit denen eine Kommu-nikation auch über weite Entfernungen schmerzlos erfolgen kann. Auf einige sei hier eingegangen: „Meetings“, also Besprechungen mit persön-licher Anwesenheit, sind bei vielen Teilnehmern und weiter Entfernung ein ganz erheblicher Kostenfaktor. In den ersten Monaten eines anlaufenden Projekts machen diese Bespre-chungen oft 30% - 50% des Aufwands aus! Trotz dieses hohen Aufwands sind derartige Besprechungen schlicht unerlässlich, um Vertrauen und Verständnis herzustellen und zu erhalten. Der Aufwand für solche Besprechungen lässt sich reduzieren durch früher anreisende Teilgruppen bzw. (in Zeiten von Vulkanausbrüchen) durch vorbereitende Telefon-konferenzen. Zeitaufwendige, unkritische Details können so vorab vorgeklärt werden.

„Telefonkonferenzen“ lassen sich mit jedem gängigen Tele-fon leicht durchführen. Eine gute Telefonanlage oder ein ent-sprechender Diensteanbieter ermöglicht auch eine größere Zahl von Teilnehmern. Die Erfahrung zeigt, dass eine gute zusätzliche Freisprecheinrichtung die Qualität und damit die Akzeptanz erheblich steigert. Allerdings haben wir immer wieder Anlaufschwierigkeiten, bis neue Kunden diese Form der Konferenz akzeptieren und effektiv nutzen.

„Projektportale“ – wir setzen hier den Team Foundation Server von Microsoft ein – verwischen die räumlichen Unterschiede und erlauben eine Zusammenarbeit unabhängig vom Ort auf sehr hohem Niveau. Allerdings sind diese Tools vor allem im Betrieb keineswegs billig und erfordern einiges an Expertise.

„Gemeinsame Dokumente“, also gleichzeitig oder abwech-selnd bearbeitete Dokumente, etwa Spezifikationen, Testplä-ne, sind in der (prä-) historischen Umlaufvariante alles an-dere als agil. In Kombination mit Portalen oder Werkzeugen zur Zusammenarbeit über Internet (z.b. Netmeeting), sind sie aber ein hervorragendes Mittel, in einer virtuellen Bespre-chungsrunde gleich „Nägel mit Köpfen“ zu machen und den gefundenen Kompromiss gleich auszuformulieren.

Agilität und Verteilte Entwicklung – Ein Erfahrungsbericht Michael Sperber

Michael Sperber

Bild 1

Projektmanagement27 Ausgabe 16 | September 2010

Kommunikation ist nicht nur ein technisches ProblemKommunikation ist aber nicht nur ein technisches Problem. An beiden Enden der Kommunikation sitzen Menschen. Din-ge wie Verstehen und Vertrauen haben weit mehr Facetten als das ISO/OSI Referenzmodell glauben lässt. Wer einmal mit einem schnell sprechenden US-Amerikaner telefoniert hat, weiß wie schwer es sein kann, auch scheinbar vertraute Sprachen korrekt zu verstehen. Noch viel schwieriger wird das, wenn Worte aufgrund unterschiedlicher kultureller Hin-tergründe unterschiedlich interpretiert werden, etwa in China oder Indien.

Wenn die Anzahl der potentiellen Gesprächspartner groß wird, ist es nicht trivial, den richtigen Adressaten zu finden. Das kann man teilweise technisch lösen, durch Adresslisten, Listen von Ansprechpartnern, Listen von Kompetenzträgern, E-Mail-Verteilerlisten etc. Der nicht-technische Aspekt ist, dass zu wenig gefragte Personen sich ausgegrenzt, zu viel gefragte Personen sich überflutet fühlen, versehentlich ver-gessene empfindlich reagieren.

Bildung von hierarchischen Gruppen oder TeamsDie Lösung, die wir in einigen Projekten (in der Größenord-nung von insgesamt 30 bis 50 Entwicklern) bereits erfolgreich praktiziert haben, besteht in der Bildung von hierarchisch gegliederten Gruppen oder Teams. Das können streng hie-rarchisch organisierte Einheiten sein [siehe Bild 1] oder eher gleichberechtigt kooperierende Gruppen [siehe Bild 2]. Ge-meinsames Kennzeichen ist, dass die Vereinbarungen zwi-schen den eigenständigen Gruppen nicht-agil sind, während innerhalb einer jeden Gruppe agil gearbeitet wird. Dadurch wird der Kommunikationsaufwand reduziert, die Agilität

bleibt aber erhalten. Das soll am Beispiel der hierarchisch strukturierten Gruppen [Bild 1] erläutert werden.Die oberste Ebene, der „Leitungskreis“, trifft sich etwa alle 6 bis 8 Wochen. Hier wird die Entwicklung des gesamten Projekts, oft über mehr als 2 oder 3 Jahre, geplant und in Phasen heruntergebrochen, die typisch 3 bis 9 Monate dau-ern; ist eine Phase länger als 3 Monate, ist sie meist durch Meilensteine im Abstand von nicht mehr als 3 Monaten un-terteilt. Im Leitungskreis sind alle Standorte und Fachthemen repräsentiert, nicht nur die Entwicklung. Eine standardisierte Methodik wird meist nicht angewendet, wesentliches Augen-merk wird auf Controlling gelegt, hierfür sind Meilensteine oder Projekt-Enden in überschaubarem Abstand notwendig.Die obere operative Ebene, das „Team“, repräsentiert einen Standort oder ein Teilprojekt. Die Ziele werden vom Leitungs-kreis vorgegeben und sind nicht agil veränderbar. Die Phase, bzw. die durch Meilensteine definierten Teilphasen, werden in Iterationen weiter heruntergebrochen. Die Mitglieder des Teams treffen sich regelmäßig, z.B. wöchentlich. Einheitliche Tools werden nicht immer eingesetzt.

Die untere gezeigte operative Ebene, die Projektgruppe, kann innerhalb der vorgegebenen Ziele agil arbeiten, z.B. mit SCRUM, trifft sich regelmäßig bzw. sitzt nah bei einander. In kleineren Projekten fallen natürlich die beiden unteren Ebe-nen ganz oder teilweise zusammen. Die Grafik darf nicht dar-über hinwegtäuschen, dass die große Masse des Aufwands auf der unteren, operativen Ebene anfällt bzw. geleistet wird.

ZusammenfassungKommunikation ist essentiell in jeder Entwicklung, in agiler Entwicklung noch mehr, und erfordert wegen der unvermeid-baren Schwierigkeiten bei verteilter Entwicklung höchste Aufmerksamkeit – seitens aller Beteiligten: Auftraggeber und Auftragnehmer, Entwickler und Tester, Manager und Vertrieb.Eine Gruppenbildung, wie oben beschrieben, hilft nach un-serer Erfahrung, die Agilität mit all ihren Vorzügen zu erhal-ten und verteilte Entwicklungen dennoch geplant, pünktlich und mit kontrolliertem Aufwand durchzuführen. Die Kriterien, nach denen die Gruppen gebildet und definiert werden, sind allerdings in jedem komplexen Projekt neu zu suchen und zu finden.

Bild 2

Der Autor

Michael Sperber ist Mitglied des Vorstands der infoteam Software AG. Er ist Fachgruppenleiter der FG Automatisierung.



Kurzbeschreibung: Ein Softwaremigrations-Projekt erfor-dert einen anderen Testansatz als ein Entwicklungsprojekt. Denn es existiert im Regelfall weder eine Anforderungsspe-zifikation noch ein Designmodell als Testgrundlage. Das ent-scheidende Testkriterium ist dann die vollständige funktio-nale Gleichheit von Alt- und migriertem System – und dafür müssen spezielle Methoden und Werkzeuge zum Einsatz kommen. Darüber hinaus sollte im Migrationstest schrittwei-se vorgegangen werden:

DIE MESSUNG DES CODES„Man kann nicht planen, was man nicht messen kann“ [1]. Gemäß dieses Zitates von Tom deMarco muss im Rahmen der Planung eines Migrationstests das gemessen werden, was migriert werden soll: Der Quellcode. Denn in Migrations-projekten ist dieser Code des Altsystems die entscheidende Grundlage für die Aufwandsschätzung [2]. Welche Aspekte einer Messung unterzogen werden, hängt von der gewünschten Information und Zielgröße ab, die man mit der Messprozedur gewinnen will. Die gewünschten Metriken können anhand statischer Analyse aus dem Quell-code, den Datenbank-Schemata, den Definitionen des Be-nutzerinterfaces sowie den Systemschnittstellen gewonnen werden [3].

Die Erfahrung vergangener Projekte zeigt, dass der Zeit-aufwand für die Messung von Quellcode im Regelfall nicht mehr als 1 Woche beträgt; vorausgesetzt, man setzt dafür die geeigneten Messwerkzeuge ein. Im Laufe der Zeit sind Werkzeuge entstanden, die sich nicht nur für neue, sondern ebenso für alte Programmiersprachen eignen. Denn in den allermeisten Migrationsprojekten ist das Vorgängersystem in einer alten Programmiersprache wie PL/1, Cobol oder C geschrieben.

DIE PLANUNG DES MIGRATIONSTESTSZeit- und Aufwandsschätzung für die Testdurchführung sind Bestandteile der Testplanung. Der Testaufwand bemisst sich hier nach der Anzahl an zu exekutierenden Testfällen (Online-Transaktion, Batch-Prozess etc.) sowie jener an zu validie-renden Testobjekten. Ein Testobjekt wiederum kann aus den

Produktionsdaten generiert werden: In Form eines Benutzer-Interfaces, einer Datei, einer Datenbank-Tabelle, einer Sys-temschnittstelle etc. So gelangt man zu einer Rohschätzung für das aktuelle Migrationstest-Projekt. Diese Schätzung kann z.B. mittels Produkttyp oder des Testwiederholungs-faktors verfeinert werden [4].Das Ergebnis der Testplanung ist ein Testkonzept gemäß ANSI/IEEE-Standard 829. In diesem sollte besonderes Au-genmerk auf die Testziele und die Testendekriterien sowie deren Messung gelegt werden. Denn nur wenn diesen bei-den Aspekten entsprochen wird, kann der Kunde den Test am Ende abnehmen. Das kann z.B. mittels Kennzahlen über die durchgeführten Testfälle und über die validierten Testob-jekte erfolgen. [5].

DAS DESIGN DES MIGRATIONSTESTSUm einen Migrationstest zu designen, muss man berück-sichtigen, was (Testfälle und Testobjekte) und wie (Testvor-gehen) zu testen ist. Häufig ist mangels Verfügbarkeit und Aktualität einer Dokumentation des Altsystems die einzige Möglichkeit für die Erstellung eines Testdesigns, dass der Tester aufzeichnet, wie die Endbenutzern das System aktuell bedienen. Bei den Testobjekten ist die Anzahl an Datenele-menten, die jedes Datenobjekt besitzt, von besonderer Be-deutung. Dazu zählen z.B. Felder und Spalten sowie deren Wertebereiche.

DIE GEWINNUNG VON TESTDATEN FÜR EIN MIGRATIONSPROJEKTIn einem Migrationsprojekt gewinnt man die Testdaten am besten direkt aus dem Produktionssystem, indem man ei-nen Teil der Produktionsdaten abzieht (und anonymisiert). Im Testdesign sollte man bereits einzelne Transaktionen, Ereig-nisse und Batchläufe mit repräsentativem Charakter identifi-ziert haben.

Vor jedem Test müssen Abbildungen des Benutzer-Bedien-feldes, der Eingabedateien und des Datenbankinhaltes ar-

DER MIGRATIONSTEST-PROZESS Harry M. Sneed & Richard Seidl

Richard SeidlHarry M. Sneed

Abbildung 1

chiviert werden. In der gleichen Form müssen nach jedem Test die neuen Abbildungen derselben Objekte sowie zu-sätzlich gesendete Ausgabe-Nachrichten und ausgedruckte Reports festgehalten werden. All das führt zu einem großen Aufkommen an Testdaten.Hier können Testwerkzeuge und Capture-Replay-Tools als nützliche Helfer zum Einsatz kommen [6].

DIE DURCHFÜHRUNG DES MIGRATIONSTESTSEtwa 60% bis 80% des Gesamtaufwandes werden in Migra-tionsprojekten dem Test gewidmet. Sofern der Migrationstest also nicht automatisiert durchgeführt wird, ist es unmöglich, ihn innerhalb eines vernünftigen Zeitrahmens zu absolvieren. Damit man im Nachhinein feststellen kann, welcher Teil des migrierten Programmcodes getestet wurde, sollten (z.B. mit-tels Automatisierungswerkzeugen) Messfühler vor Teststart in z.B. jedem Zweig oder zumindest in jeder Methode plat-ziert werden. Nach jeder Transaktion oder jedem Batchprozess werden die Inhalte der Ausgabefelder, der Ausgabe-Nachrichten, das neue Erscheinungsbild der betroffenen Datenbank und Anomalien für eine spätere Evaluierung aufgezeichnet [7].

DIE EVALUIERUNG DES MIGRATIONSTESTSIm sechsten Schritt werden die Ergebnisse des Migrations-tests evaluiert, um festzustellen, ob das migrierte System die Erwartungen erfüllt: Nämlich dieselbe Leistung (inkl. Perfor-mance), wie das Altsystem zu erbringen.

Zu Validierungszwecken werden die Bildschirminhalte, Schnittstellendaten und Datenbank-Tabellen der Tests aus beiden Systemen automatisch miteinander verglichen. Wei-chen die Formate voneinander ab, muss zugunsten einer Vergleichbarkeit eine Konvertierung in ein einheitliches For-mat stattfinden.Ebenso werden die Inhalte der alten Datenbanken und jene der neuen, relationalen Datenbanken heruntergeladen und dabei zu Vergleichszwecken in komma-separierte (CSV-) Dateien umgewandelt (Abbildung 2). Im Falle des Vergleichs von Millionen von Datenausgaben ist der automatisierte Vergleich die beste Art und Weise, Fehler im migrierten Code aufzuspüren [8].

DIE MESSUNG IM MIGRATIONSTESTDie vor der Testausführung automatisch im Code einge-pflanzten Messfühler oder Verfolgungspunkte werden wäh-rend der Testausführung in Log-Dateien aufgezeichnet. Nach dem Testdurchlauf werden sie ausgewertet. Messreports können unterschiedliche Informationen dokumentieren: Den Testabdeckungsgrad, den Pfad jeder einzelnen Testtransak-tion etc. Beim Test eines komplett neu entwickelten Systems treten z.B. folgende Fehler auf: Es werden Funktionen ausgespart, Ergebnisse falsch kalkuliert usw. Beim Test eines migrierten

Systems sind die (Transformations-) Fehler allerdings subti-lerer Natur: Nachkommastellen gehen verloren, Datensätze werden zerstört, Daten haben sich an einen anderen Ort ver-lagert usw.

Die einzige Möglichkeit zur Aufdeckung solcher Fehler ist es, alle Daten zu vergleichen; kombiniert mit einer Abdeckung des kompletten Programmcodes. Jede Anweisung muss ge-testet werden – das bedeutet, dass eine wiederholte Durch-führung des Tests notwendig ist [9].

Neben der Messung der Testabdeckung ist es erforderlich, die Richtigkeit der Ausgabedaten und den Prozentsatz an tatsächlich aufgetretenen Fehlern relativ zu jenem der vor-ausgesagten Fehler zu messen. Mit diesen Informationen kann man feststellen, wann der Test beendet werden kann (Abbildung 3).

Eine ausführliche Version dieses Fachbeitrages sowie das vollständige Literaturverzeichnis finden Sie unter www.asqf.de/publikationen


Abbildung 2

Abbildung 3

Richard Seidl ist als Testspezialist und Testmanager bei der ANECON GmbH tätig. Er ist regionaler Fachgruppenleiter der FG Softwaretest Sachsen.Harry Sneed ist Autor zahlreicher Artikel und Bücher. Er ist Dozent und für die ANECON GmbH tätig.

Die Autoren

Projektmanagement



Die Integration von agilen und schwergewichtigen Prozessen zur Systement-wicklung ist längst kein „methodisches“ Tabu mehr. Mit der Verbreitung von Scrum, dem derzeit wohl populärsten agilen Pro-jektmanagementprozess, sehen sich immer mehr Unternehmen mit der Fra-ge konfrontiert: Was kann man als Auftragnehmer tun, wenn man einem Auf-traggeber gegenüber zum Einsatz des V-Modell XT, dem dominierenden „großen“ Standard, verpflichtet ist, aber in den eigenen Teams Scrum etabliert hat? Kann man das V-Modell XT mit seinen gut dreißig Rollen und fast hundert Produkttypen mit Scrum zusammenbringen?

Ansatzpunkte für das Zusammenführen von V-Modell XT und Scrum ergeben sich aus der Betrachtung der Projekt-steuerungsmechanismen beider Prozesse.

Projekte mit dem V-Modell XT steuernDas V-Modell XT kann durch seinen modularen Aufbau aus Vorgehensbausteinen an unterschiedliche Projektsituatio-nen angepasst werden. Die Vorgehensbausteine definie-ren, welche Produkte erstellt werden müssen, sagen aber nichts darüber aus, wann die Produkte entstehen sollen. Das übernehmen die Projektdurchführungsstrategien. Sie geben den Rahmen für die Projektplanung vor, indem sie die Meilensteine – im V-Modell XT Entscheidungspunk-te – definieren und festlegen, in welcher Reihenfolge sie durchlaufen werden können und welche Produkte pro Meilenstein vorhanden sein müssen.

Die gängige Projektdurchführungsstrategie für Auftrag-nehmerprojekte ist die Inkrementelle Systementwicklung (Bild 1). Der Ablauf, den sie beschreibt, kann wiederholt auf Teilmengen der Systemanforderungen angewendet werden, sodass das zu entwickelnde System inkrementell wächst. Projekte mit Scrum steuernEin Scrum-Projekt gliedert sich in gleich lange Sprints (Iterationen). „Motor“ eines Projekts ist das Product Back-log, eine Liste von priorisierten Anforderungen. Für einen Sprint werden daraus Anforderungen ausgewählt, die vom Team in Tasks, das heißt in elementare Aufgaben, zerlegt und im Sprint bearbeitet werden. In jedem Sprint wird ein potenziell lieferfähiges Produktinkrement erstellt. Inner-halb einer geplanten Zahl von Sprints entsteht ein Release.

Die Integrationslösung Die Steuerungsmechanismen von V-Modell XT und Scrum sind auf verschiedenen Niveaus angesiedelt: Die Vorga-ben des V-Modell XT, die auf das Erreichen von Entschei-dungspunkten zielen, liegen auf einer Makro-Manage-ment-Ebene. Der Scrum-Ablauf, der auf der Realisierung

von Anforderungen durch Tasks in kurzen Sprints basiert, bewegt sich auf einem Mikro-Management-Niveau. Die Mikro-Steuerung mit Scrum kann in die Makro-Steuerung nach dem V-Modell XT eingebettet werden. Zu diesem Zweck wird die Projektdurchführungsstrategie Inkremen-telle Systementwicklung vereinfacht (Bild 2). Die Entscheidungspunkte werden bis einschließlich Pro-jekt beauftragt übernommen. Danach folgt der Entschei-dungspunkt Release geplant. Er entspricht dem ursprüng-lichen Entscheidungspunkt Iteration geplant, wurde aber umbenannt, um Verwirrung zwischen den verschiedenen Iterationsbegriffen in Scrum und im V-Modell XT zu ver-

Wie man agiles Vorgehen nach Scrum mit dem V-Modell XT kombiniert – ein pragmatischer Ansatz für prozessbasiertes Projektmanagement Ursula Meseberg

Ursula Meseberg

Bild 1: Ausschnitt aus der Projektdurchführungsstrategie Inkrementelle Systementwicklung

Bild 2: Ausschnitt aus der neuen Projektdurchführungsstrategie für das V-Modell XT mit Scrum

online trainingISTQB® Certified Tester Foundation Level (englisch & deutsch)

ISTQB® Certified Tester Advanced Level Test Manager (englisch)

© iS

tock

phot

o/Yu

ri_Ar

curs

Unsere Firma spart bis zu

60% an Schulungskosten durch Online Training.

Die gewonnenen Kenntnisse und die Einsparungen sichern die Wettbewerbsfähigkeit unseres

Unternehmens.

www.te-trainings-shop.com


http://www.te-trainings-shop.com

Projektmanagement31 Ausgabe 16 | September 2010

meiden. Der gesamte Zyklus bis zur Lieferung an den Auf-traggeber wird, wie in Scrum, als Release bezeichnet. Nach Release geplant setzt der Scrum-Ablauf ein. Die Entscheidungspunkte System spezifiziert, Lieferung durchgeführt und Abnahme erfolgt bleiben erhalten, um zu gewährleisten, dass die im V-Modell XT definierte Auf-traggeber/Auftragnehmer-Schnittstelle nicht beeinträch-tigt wird. Die vier dazwischen liegenden Meilensteine von System entworfen bis System integriert werden zu einem Entscheidungspunkt Sprint abgeschlossen zusammenge-fasst, der jeweils ein Sprint-Ende markiert.

Auf den Punkt gebrachtDie so entstandene integrierte Lösung bietet dem Auftrag-geber als Erbschaft beider Prozesse erheblichen Spiel-raum, sich in das Auftragnehmerprojekt einzubringen. Die

Lösung ist flexibel angelegt und kann an einen höheren „Bedarf an V-Modell XT“ angepasst werden. Sie hat ihre Praxistauglichkeit bereits in mehreren Projekten bewiesen.



© iS

tock

phot

o/Yu

ri_Ar

curs




Unternehmens.



Anzeige

Ursula Meseberg ist Mitbegründerin und Geschäftsführerin der Berliner microTOOL GmbH. Davor hat sie als Consultant mehrere Jahre vorwiegend an der Einführung von Software Engineering Verfahren sowie an der Entwicklung von unternehmensspezifischen Vorgehensmodellen mitgewirkt. Sie ist Autorin zahlreicher Fachbeiträge.

Die Autorin




© iS

tock

phot

o/Yu

ri_Ar

curs




Unternehmens.





Ausgabe 16 | September 2010 32Advertorial

Schwache Anwendungs-leistung kostet Unterneh-men jedes Jahr Millio-nenbeträge und mindert deren Ansehen. Die Grün-de hierfür sind offensicht-lich: Kunden können auf die erforderlichen Web-sites nicht zugreifen oder Kaufvorgänge für die gewünschten Produkte nicht abschließen, da die Anwendungen entweder überhaupt nicht oder nur sehr langsam reagieren. Und das sind nur die Schwierig-keiten, die bei Webanwendungen auftreten – interne Un-ternehmensanwendungen mit schwacher Leistung sind ebenfalls ein Problem.

Schwache Anwendungsperformance kommt extrem teuer zu stehen – dies lässt sich allerdings verhindern. Microsoft Visual Studio 2010 umfasst die erforderlichen Tools zum Ermitteln, Verbessern und Überprüfen der Anwendungs-performance selbst unter anspruchsvollsten Bedingungen, damit Ihre Anwendungen in jeder Situation erwartungsge-mäß ausgeführt werden. In vielen Fällen wurde bisher auf Belastungs- und Stresstests verzichtet, häufig aufgrund der Kosten oder der Komplexität der Tools, die zur Durchfüh-rung der Belastungs- und Stresstests erforderlich waren.

SIMULIEREN DES BENUTZERVERHALTENS MIT LAST- UND STRESSTESTS

Last- und Stresstests lassen sich auf einfache Weise durch Aufzeichnung der http-Kommunikation erstellen. Der aufgezeichnete Datenverkehr kann dann in Lasttests zur Simulation von Benutzeraktionen eingespielt werden. Diese Tests lassen sich zur Generierung von großen Las-ten sehr effizient einsetzen.

Die Last- und Stresstests sind reich an Funktionalität: AJAX und andere Webseitenelemente werden automatisch richtig gehandhabt. Sie können problemlos Bedingungen und Schleifen zu Ihren Testdurchläufen hinzufügen, ohne hierfür Code erstellen zu müssen. Darüber hinaus werden dynamische Parameter, Cookies und Authentifizierung automatisch unterstützt. Die Tests können auch an Da-tenquellen gebunden werden, um datengetriebene Tests zu implementieren. Zusätzlich zu all diesen Features sind Last- und Stresstests außerdem erweiterbar – wenn Sie

beispielsweise komplexe Gültigkeitsregeln hinzufügen müssen, die nicht von den unmittelbar verfügbaren Re-geln abgedeckt werden, können Sie Ihre eigenen Regeln definieren und hinzufügen. VERWENDEN VON KOMPONENTENTESTS ZUR LASTGENERIERUNG

Einer der größten Vorteile der Last- und Stresstesttools von Visual Studio 2010 ergibt sich aus der Unterstützung von Komponententests (Unit Tests) und Oberflächentests (Coded UI Tests). Sie können Lasttests also viel früher als bisher in den Entwicklungsprozess einbeziehen, um mögliche Leistungsengpässe aufzuspüren. Dies ist auch ein großer Vorteil bei der Arbeit mit Web Services. Immer mehr Anwendungen greifen zur Unterstützung der Benut-zeroberfläche auf Web Services zu, nun können Sie die Leistung dieser Dienste unabhängig von den Client-An-wendungen testen, um deren Leistungsfähigkeit sicherzu-stellen.

ERSTELLEN VON LASTTESTS

Wie funktionieren die Belastungs- und Stresstests in Visual Studio 2010? Zur Erstellung steht Ihnen ein einfacher Assistent zur Verfügung, mit dem Sie komplexe Lasttests konstruieren können, welche verschiedene Netzwerkband-breiten berücksichtigen, bestimmte Lastmuster anwenden, einen Testmix ausführen und eine Vielzahl verschiedener Browsertypen simulieren können. Darüber hinaus können Sie eine Anlaufzeit definieren, die Testdauer angeben, Be-denkzeit zwischen den Testdurchläufen berücksichtigen und festlegen, von welchen Computern Leistungsindikato-

Last- und Performancetests für JedermannMatthias Zieger

Matthias Zieger

Abbildung 1 – Ausgabe eines Last- und Stresstests.

33 Ausgabe 16 | September 2010 Advertorial

ren erfasst werden sollen. Die Leistungsprofile können Sie in einem Assistenten angeben (Abbildung 2). Außerdem können Sie das Test-Framework mithilfe von benutzerdefinierten Datenkollektoren erweitern, um spe-ziell von Ihnen benötigte Informationen zu erfassen. Durch diese Datenkollektoren ist es beispielsweise möglich, be-nutzerdefinierte Anwendungsprotokolle, den Netzwerk-verkehr und so gut wie alle weiteren benötigten Informati-onen zusammenstellen.Zusätzlich zu all diesen Optionen – viel zu viele, um sie alle hier aufzulisten – können Sie Ihre Testumgebung qua-si uneingeschränkt skalieren. Die Lasttest-Controller und

-Agenten können echte Enterprise-Szenarien mit Zehntau-senden von Benutzern mit einem geringeren Kostenauf-wand als bisher simulieren. Der Bedarf an zusätzlichen Benutzern kann einfach durch den Erwerb von Virtual User Packs abgedeckt werden.

ANALYSIEREN VON TESTERGEBNISSEN

Lasttests sind auf jeden Fall sinnvoll, aber ohne Auswer-tung der Testergebnisse nicht besonders nützlich. Die

Diagrammansicht des Load Test Analyzers gibt Ihnen die Möglichkeit, Ihre Leistungsergebnisse zusammen mit den Aktivitäten und Konditionen auf den Servern zu analy-sieren, um zum Beispiel Fehler im Ereignisprotokoll oder übermäßige Ressourcenauslastung feststellen zu können (Abbildung 3). Für Leistungsindikatoren in Ihren Lasttests wurden darüber hinaus Schwellwertgrenzen automatisch konfiguriert. So können Sie die überlasteten Ressourcen schnell identifizieren. BESEITIGEN VON ENGPÄSSEN

Sobald Sie ein Problem erkannt haben, muss dieses auch beseitigt werden können – zu diesem Zweck wird ein Pro-filer mitgeliefert. Dieser gibt Ihnen die Möglichkeit, sowohl Ihren eigenen als auch fremden Code zu untersuchen, um Engpässe bis auf Methodenebene festzustellen. Nachdem

Sie ein Performance-Problem identifiziert haben, können Sie den Profiler einsetzen, um detaillierte Informationen zu allen Methodenaufrufen während der Testsitzung aufzu-zeichnen (Abbildung 4). So kann der langsamste Ausfüh-rungspfad in Ihrem Code schnell ermittelt werden. EINFACHES ERSTELLEN GROßER DATENSÄTZE MITHILFE DER DATENGENERIERUNG

Ein bei Last- und Stresstests häufig übersehener Gesichts-punkt betrifft die Mengen der Testdaten in den Datenban-ken. Je mehr Daten vorhanden sind, desto größer ist die Wahrscheinlichkeit, dass Abfragen langsam ausgeführt werden und Engpässe entstehen. Eines der Features von Visual Studio (ab Premium Edition) ist die Generierung von Testdaten – mit diesem Feature können Sie große Mengen realistischer Daten einfach und schnell generieren und für Tests verwenden (Abbildung 5).

Abbildung 2 – Angeben eines Testmixes anhand von angenommenen Benut-zerszenarien.

Abbildung 3 – Zusammenfassung der Lasttestergebnisse.

Abbildung 4 – Detailanalyse einer Funktion.

Advertorial

BERICHTSERSTELLUNG

Visual Studio 2010 umfasst viele Berichte, mit deren Hilfe Sie Ihre Testläufe analysieren und die Ergebnisse an wei-tere Projektbeteiligte kommunizieren können. Außerdem können Sie rasch und unkompliziert mehrere Testläufe miteinander vergleichen, wie in Abbildung 6 veranschau-licht. In der gezeigten Ansicht können Sie die Antwortzei-ten von Webseiten für einen bestimmten Vorgang analy-sieren – sowohl wann die Anwendung langsam reagierte als auch wie die Reaktionszeiten sich verbesserten.

Abbildung 7 zeigt die Transaktionszeiten in einer Vergleichs-ansicht, d.h. die Zeiten zur Ausführung einer Abfolge von Schritten entsprechend verschiedener Benutzerszenarien. Bei den dargestellten Szenarien handelt es sich unter an-derem um Anmeldevorgänge am System, die Auswahl von Artikeln und den Abschluss von Kaufvorgängen. BELASTUNGS- UND STRESSTESTS FÜR ALLE

Die Belastungs- und Stresstesttools von Visual Studio bil-den eine ausgereifte, stabile und erweiterbare Plattform zur Ausführung von Leistungstests, zur Analyse der Test-ergebnisse und zur direkten Anwendung der Schlussfolge-rungen. Aufgrund der engen Integration mit der Entwick-lungsumgebung sind die Ergebnisse von Belastungs- und Stresstests unmittelbar anwendbar. Entwicklungsteams können die Daten analysieren, den Code im Detail inspi-

zieren, ermittelte Engpässe beseitigen und die Tests erneut ausführen, um die Auswirkungen der Änderungen zeitnah zu überprüfen. Unabhängig davon, ob Ihre Anwendungen für eine kleine oder große Anzahl von Benutzern vorge-sehen oder ob sie geschäftskritisch sind oder nicht, kön-nen Ihnen die Belastungs- und Stresstesttools von Visual Studio dabei helfen, die Leistungsfähigkeit Ihrer Anwendun-gen zu verbessern – ohne dass Sie auf kostspielige Tools zurückgreifen und steile Lernkurven erklimmen müssen.

BESUCHEN SIE UNS AUF DER CONQUEST Microsoft ist als Sponsor der CONQUEST 2010 mit einem Stand und einer Keynote zum Thema Cloud Computing und Testen auf der Konferenz vertreten. Kommen Sie an unserem Stand vorbei, um sich ausführlich beraten zu las-sen, wie Sie und Ihr Unternehmen von den neuen Test-werkzeugen von Microsoft profitieren können.

Weitere Informationen finden Sie auch unter www.microsoft.de/visualstudio/qs.

Advertorial Ausgabe 16 | September 2010 34

Matthias Zieger beschäftigt sich seit mehreren Jahren mit Themen rund um die Prozesse des Application Lifecycle Management, insbesondere Require-ments Management und Qualitätssicherung. Dabei stehen vor allem die Inte-gration von Organisationen, Prozessen und Werkzeugen im Fokus. Seit Januar 2009isterbeiMicrosoftinderDPE(DeveloperPlattform&Evangelism)tätigund betreut dort Kunden aus allen Branchen zum Thema Entwicklungsprozes-se und Werkzeuge. Davor war er als Berater für ALM bei Borland, als J2EE-Architekt bei Seals.net (Tieto-Enator) und bei IBM Global Services beschäftigt.


Der Autor

Abbildung 5 – Datengenerierung.

Abbildung 7 – Transaktionszeiten.

Abbildung 6 – Leistungsvergleich von Webseiten.

Advertorial


Jetzt ist endgültig Schluss mit dem altbekannten Problem nicht-reproduzierbarerer Fehler („No-Repro-Bugs“) beim Testen: Visual Studio Test Professional 2010 mit Lab Management 2010 bricht die Silos zwischen Fachseite, Entwicklern und Testern endlich auf und ermöglicht erstmals eine reibungslose Zusammenarbeit zwischen allen Beteiligten.

Alle wichtigen Informationen wie Ereignisprotokolle, GUI-Interaktionen, Netzwerkemulation und Systeminformationen werden beim Testen automatisch für Fehlerberichte aufgezeichnet. Tester können in so genannten Rich Information Bugs ihre Aufzeichnungen um Screenshots und Videos ergänzen und mit IntelliTrace™ virtualisierte Momentaufnahmen ihrer Testumgebung nachstellen.

Auf Basis dieser vollständigen Systeminformationen können Entwickler dann alle Fehler jederzeit auch nachträglich unter Originalbedingungen reproduzieren. Testanforderungen sind durchgängig nachvollziehbar. Reports und Qualitätskennzahlen werden allen Teammitgliedern über das webbasierte Projektportal komfortabel zugänglich gemacht.

Besuchen sie uns auf der cOnQuesT cOnference On QualiTy engineering in sOfTware TechnOlOgy

nie wieder “no-repro-bugs” BEIM TESTEN!

ENDLICH:

Zur Auswertung von IntelliTrace-Daten wird Visual Studio 2010 Ultimate benötigt. Weitere Informationen finden Sie unter www.microsoft.de/visualstudio.

mit Lab Management

Machen sie schluß mit no-repro-Bugs: alle informationen, whitepaper und kostenlose Testversionen finden Sie unter www.microsoft.de/visualstudio/qs

Microsoft ist Mitglied im ASQF

VisualStudioTestProfessional2010_Anzeige_V05.indd 1 19.08.2010 19:59:54

Jetzt ist endgültig Schluss mit dem altbekannten Problem nicht-reproduzierbarerer Fehler („No-Repro-Bugs“) beim Testen: Visual Studio Test Professional 2010 mit Lab Management 2010 bricht die Silos zwischen Fachseite, Entwicklern und Testern endlich auf und ermöglicht erstmals eine reibungslose Zusammenarbeit zwischen allen Beteiligten.

Alle wichtigen Informationen wie Ereignisprotokolle, GUI-Interaktionen, Netzwerkemulation und Systeminformationen werden beim Testen automatisch für Fehlerberichte aufgezeichnet. Tester können in so genannten Rich Information Bugs ihre Aufzeichnungen um Screenshots und Videos ergänzen und mit IntelliTrace™ virtualisierte Momentaufnahmen ihrer Testumgebung nachstellen.

Auf Basis dieser vollständigen Systeminformationen können Entwickler dann alle Fehler jederzeit auch nachträglich unter Originalbedingungen reproduzieren. Testanforderungen sind durchgängig nachvollziehbar. Reports und Qualitätskennzahlen werden allen Teammitgliedern über das webbasierte Projektportal komfortabel zugänglich gemacht.

Besuchen sie uns auf der cOnQuesT cOnference On QualiTy engineering in sOfTware TechnOlOgy

nie wieder “no-repro-bugs” BEIM TESTEN!

ENDLICH:

Zur Auswertung von IntelliTrace-Daten wird Visual Studio 2010 Ultimate benötigt. Weitere Informationen finden Sie unter www.microsoft.de/visualstudio.

mit Lab Management

Machen sie schluß mit no-repro-Bugs: alle informationen, whitepaper und kostenlose Testversionen finden Sie unter www.microsoft.de/visualstudio/qs

Microsoft ist Mitglied im ASQF

VisualStudioTestProfessional2010_Anzeige_V05.indd 1 19.08.2010 19:59:54

http://www.microsoft.de/visualstudio/qs

KOSTENFREIES

CONQUEST-Tagesticket


KOSTENFREIES



CONQUEST

Als Sponsor der MedConf freuen wir uns über Ihren Besuch:

Besuchen Sie unseren Stand und sehen Sie:

Welche Vorteile der modellzentrierte Test und die Testfallgenerierung mit .getmore bietenDie Validierung eines Dentalgeräts mittels .mzT,.getmore und 4CSmeditecIntegration der Testfallgenerierung in ALM-Systeme

Für weitere Informationen besuchen Sie bitte unsere Homepage:

Forschung undEntwicklung

Modellierung,.mzT undGenerierung

System-integration

Prozess- undQualitäts-

management

Qualitäts-sicherung

Beratungund Schulung

BeratungRealisierungInnovation

www.seppmed.de

Anzeige


20 – 22 September 2010, Dresden, GermanyMARITIM Hotel & International Congress Center

Die Bundesregierung hält Dresden für den richtigen Ort, um im Dezember auf dem Nationalen IT-Gipfel 2010 über aktuel-le Themen rund um die digitale Gesellschaft zu debattieren. Die CONQUEST 2010 ist schon vorher da und alle ASQF-Mitglieder können kostenlos mit dabei sein!

Jedes ASQF-Mitglied 1 kann ein kostenfreies Tagesticket für den 21. oder 22. September buchen: Einfach unter www.conquest-conference.org/tickets-registration das One Day Conference Ticket (Tuesday) oder (Wednesday) anwählen 2 und bei den Kontaktdaten die Mitgliedsnummer eintragen. Machen Sie als Mitglied mit uns gemeinsam die 13. CONQUEST (Conference on Quality Engineering in Soft-ware Technology) zu einem intellektuellen, praxisnahen, kre-ativen, zukunftsweisenden, trendsaufspürenden, austausch-geprägten Miteinander der Software-Qualitäts-Verfechter.

WANN? 20. bis 22. September

WO? Maritim Hotel & International Congress Center, Dresden. JETZT ONLINE REGISTRIEREN!www.conquest-conference.org/tickets-registration

1 Neu-Mitglieder und diese, die es noch werden wollen, erhalten selbstverständlich ebenfalls ein Ticket. 2 Wenn Sie als Mitglied an mehreren Tagen der CONQUEST

teilnehmen wollen, so wenden Sie sich bitte direkt an das Konferenzteam unter [email protected] oder an den ASQF.

„Software Quality“ in Dresden noch vor dem Nationalen IT-Gipfel

http://www.seppmed.de


KOSTENFREIES




Mit dem steigenden Anteil der durch Software realisier-ten Funktionalität in medizinischen Geräten wird es immer schwieriger, die Sicherheit dieser Geräte nachzuweisen. Um der erhöhten Komplexität der Medizinprodukte Rechnung zu tragen, wurden entsprechende normative Schritte in der IEC 60601 (Medizinische elektrische Geräte), IEC 62304 (Software Lebenszyklus) und ISO 14971 (Risikomanagement) fixiert. Im vorliegenden Beitrag wird die Umsetzung des Software-Lebenszyklus nach IEC 62304 mit Hilfe des Microsoft Team Foundation Server (TFS) beschrieben.

Software-Lebenszyklus Die IEC 62304 beschreibt den Softwarelebenszyklus, nach dem medizinische Software zu entwickeln ist. In Abbildung 1 wird dieser Software-Lebenszyklus dargestellt. Neben dem eigentlichen Software-Entwicklungsprozess enthält er auch die in der Norm definierten entwicklungsbegleitenden Pro-zesse Software-Risikomanagement, Software-Konfigurati-onsmanagement und Software-Problemlösung. Eine wesentliche Anforderung aus der IEC 62304 ist die Nach-

verfolgbarkeit zwischen System-Anforderungen, Software-Anforderungen, Software-System-Test und der in der Soft-ware implementierten risikoreduzierenden Maßnahmen. Aus diesem Grund muss ein vollständiger Entwicklungsprozes-ses für medizinische Software auch den Produkt-Risikoma-nagementprozess beinhalten. Damit diese Prozesse effizient und ergebnisorientiert gelebt werden und den Softwareent-wickler in seiner Arbeit mehr unterstützen als einschränken, wurde der Entwicklungsprozess nach den Vorgaben der IEC 62304 und der ISO 14971 mit Hilfe des Team Foundation Servers realisiert. Der TFS ist eine Sammlung von Tools und Technologien mit deren Hilfe einzelnen Tätigkeiten und Er-gebnisse im Verlauf eines Projektes zentral verfolgt und koor-diniert werden können. Für die Softwareentwickler ist damit eine komplette Softwareproduktionsumgebung verfügbar, welche Quellcode- und Versionsverwaltung, Testautomati-sierung sowie eine integrierte Kooperationsumgebung mit Dokumentenmanagement, Kommunikationsplattform und

Prozessleitfaden beinhaltet. Dem Projektmanager und dem Risikomanager stehen Tools und Datenbankabfra-gen für die Auswertung und das Projektcontrolling zur Verfügung. Es können da-mit beispielsweise Informa-tionen über die Anzahl von gemeldeten oder gelösten Fehlern abgerufen werden.Die Anforderungen aus Spezifikations- und Archi-tekturdokumenten werden mit entsprechenden WorkItems im TFS synchronisiert und dort verwaltet. Ebenso verhält es sich mit erkannten Risiken aus der Risikoanalyse. In Abbildung 2 ist die Verknüpfung zwischen Dokumenten und dem Team Foundation Server dargestellt. Ein definiertes Risiko kann im TFS verwaltet wer-den. Die risikoreduzierende Maßnahme wird als Anforderung ebenfalls im TFS hinterlegt. Ein Testfall beweist die Umset-zung der Anforderung im Quellcode. Die Nachverfolgbarkeit wird mit Hilfe eines Tools iTrace ausgewertet und als Trace-Matrix angezeigt.

Mit diesem Entwicklungsprozess ist es gelungen, das Pro-jektmanagement für die Entwicklung medizinischer Software zukunftsorientiert und skalierbar zu gestalten.Die Erfahrungen bei der Anwendung in konkreten Projekten zeigen, dass besser geführte und transparent dargestell-te Prozesse die Effizienz deutlich steigern und zudem den Nachweis gegenüber benannten Stellen deutlich erleichtern.

Der Software-Lebenszyklus für medizinische Geräte nach IEC 62304 in der Praxis Birgit Stehlik

Birgit Stehlik

Abb. 1: Software-Lebenszyklus nach IEC 62304

Abb. 2: Nachverfolgbarkeit von Risiken und Anforderungen mit dem TFS und dem iTrace-Tool

Birgit Stehlik arbeitet bei der infoteam Software AG als Projektleitern im Be-reich der Software- und Applikationsentwicklung für medizinische Geräte und für die Laborautomatisierung.

Die Autorin

Medizintechnik

Peter Löw, Roland Pabst, Erwin PetryFunktionale Sicherheit in der PraxisAnwendung von DIN EN 61508 und ISO/DIS 26262bei der Entwicklung von Serien-produkten

2010, 365 Seiten, FesteinbandE 49,90 (D)ISBN 978-3-89864-570-6

Softwareentwicklung & Projektmanagement

Jorge Marx Gómez, Susanne Strahringer,

Frank Teuteberg (Hrsg.)Green Computing &

SustainabilityHMD - Praxis der Wirtschafts-

informatikHeft 274

2010, 128 Seiten, Broschur

E 24,00 (D)ISBN 978-3-89864-674-1

dpunkt.verlag GmbH · Ringstraße 19 B · D-69115 Heidelbergfon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: [email protected] · www.dpunkt.de

Niklas Spitczok von Brisinski, Guy VollmerPragmatisches IT-ProjektmanagementSoftwareentwicklungsprojekte auf Basis des PMBOK® Guide führen


Andreas Spillner, Tilo LinzBasiswissen SoftwaretestAus- und Weiterbildung zum Certifi ed Tester – Foundation Level nach ISTQB-Standard4., überarb. und akt. Aufl age


Josephine Hofmann (Hrsg.)IT-basiertes Innovations-

managementHMD - Praxis der Wirtschafts-

informatikHeft 273


E 24,00 (D)ISBN 978-3-89864-673-4

Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf

Basiswissen Medizinische Software

Aus- und Weiterbildung zum Certifi ed Professional

for Medical Software

4. Quartal 2010, ca. 250 Seiten, Festeinband

ca. E 44,90 (D)ISBN 978-3-89864-688-8

Interessiert an E-Books?

www.dpunkt.de/buecher/ebooks.html

NEU

NEU

NEU

BESTSELLER IN DER 4. AUFLAGE

VORSCHAU

Peter Löw, Roland Pabst, Erwin PetryFunktionale Sicherheit in der PraxisAnwendung von DIN EN 61508 und ISO/DIS 26262bei der Entwicklung von Serien-produkten


Softwareentwicklung & Projektmanagement

Jorge Marx Gómez, Susanne Strahringer,

Frank Teuteberg (Hrsg.)Green Computing &

SustainabilityHMD - Praxis der Wirtschafts-

informatikHeft 274


E 24,00 (D)ISBN 978-3-89864-674-1

dpunkt.verlag GmbH · Ringstraße 19 B · D-69115 Heidelbergfon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: [email protected] · www.dpunkt.de

Niklas Spitczok von Brisinski, Guy VollmerPragmatisches IT-ProjektmanagementSoftwareentwicklungsprojekte auf Basis des PMBOK® Guide führen


Andreas Spillner, Tilo LinzBasiswissen SoftwaretestAus- und Weiterbildung zum Certifi ed Tester – Foundation Level nach ISTQB-Standard4., überarb. und akt. Aufl age


Josephine Hofmann (Hrsg.)IT-basiertes Innovations-

managementHMD - Praxis der Wirtschafts-

informatikHeft 273


E 24,00 (D)ISBN 978-3-89864-673-4

Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf

Basiswissen Medizinische Software

Aus- und Weiterbildung zum Certifi ed Professional

for Medical Software

4. Quartal 2010, ca. 250 Seiten, Festeinband

ca. E 44,90 (D)ISBN 978-3-89864-688-8

Interessiert an E-Books?

www.dpunkt.de/buecher/ebooks.html

NEU

NEU

NEU

BESTSELLER IN DER 4. AUFLAGE

VORSCHAU

http://www.dpunkt.de

Medizintechnik39 Ausgabe 16 | September 2010

Medizinische Software agil entwickelnMit der Änderung der Medizinprodukte-Richtlinie hat der Gesetzgeber klargestellt, dass Software ein eigenständi-ges Medizinprodukt sein kann. Aufgrund dieser Neuerung ist es sinnvoll, das bisherige Vorgehen bei der Entwicklung von Software als Medizinprodukt zu überdenken. In der Software-Entwicklung werden zunehmend stark iterativ-inkrementell orientierte Vorgehensmodelle eingesetzt. Diese sogenannten agilen Methoden beruhen auf der Überlegung, dass Software-Entwicklung in einem klassischen V-Modell schwierig zu steuern ist, da sich Anforderungen nur schwer vollständig und korrekt spezifizieren lassen. In einem am V-Modell orientierten Prozess ist es dann meist kostspielig, Än-derungen an der Spezifikation, am Software-Design oder an bestehenden Software-Komponenten vorzunehmen.

Agiles Vorgehen hingegen geht davon aus, dass Änderungen während der Entwicklung unvermeidbar sind. Daher führen Entwickler in agilen Projekten Iterationen häufiger durch als in Entwicklungsprozessen, die sich am V-Modell orientie-ren. Zudem werden Maßnahmen ergriffen, die helfen sollen, Kosten für spätere Änderungen an der Software gering zu halten. Dazu gehören unter anderem testgetriebene Ent-wicklung, simple Architekturen und die Detaillierung von An-forderungen erst kurz vor der Umsetzung. Agiles Vorgehen wird in vielen Projekten erfolgreich eingesetzt und kann das Management von Software-Projekten deutlich verbessern. Insbesondere die Projektmanagement-Methode Scrum wird

in diesem Zusammenhang oft verwendet. In der Software-Entwicklung für Medizinprodukte wird jedoch häufig ein Pro-zess vorgeschrieben, der wenig agil und zudem hinderlich ist, wenn Software-Teams nach Scrum vorgehen. Dies liegt auch in der Struktur der zu erfüllenden Normen begründet, die sich in der Regel an einem Vorgehen nach dem V-Modell orientieren.

Beispiel: GebrauchstauglichkeitAm Beispiel der Gebrauchstauglichkeit können die Vorteile einer stark iterativen Entwicklung gut gezeigt werden. Usabi-lity Engineering geht davon aus, dass nach der Erhebung von

Daten mit und über die Nut-zer ein Interaktions- und ein grafisches Design für eine Software erstellt werden. Insbesondere das Interak-tionsdesign wird mithilfe von Nutzertests möglichst vor der Implementierung überprüft. In einem Vorge-hen entsprechend dem V-Modell müssen die größten Teile des Interaktionsdesign idealerweise vor Beginn der Designphase fertig gestellt sein. Am Ende der Implementierung wird die Software dann anhand von Nutzertests validiert. Dies erschwert das Vorge-hen der Designer, da sie die Software erst nach Abschluss der Implementierung testen können.

Mit agilem Vorgehen hingegen ist es möglich, die bereits fer-tige Funktionalität während der Entwicklung zu testen. Das Vorgehen sieht wie folgt aus: Im vorbereitenden Zyklus 0 werden Daten über Nutzer erhoben. Dann geht das Scrum-Team auf zwei Ebenen vor: zum einen auf der Entwicklungs-ebene und zum anderen auf der Usability-Ebene. Im Zyklus 1 wird auf der Entwicklungsebene Funktionalität entwickelt, die wenig mit der Nutzeroberfläche zu tun hat. Währenddes-sen entwickeln die Usability-Spezialisten ein Design für die in Zyklus 2 geplante Funktionalität und sammeln Daten über die Nutzer für das Design von Zyklus 3. Im Zyklus 2 imple-mentieren die Entwickler die Funktionalität für das im Zyklus 1 entwickelte Design. Die Usability-Experten führen im Zyk-lus 2 Nutzertests mit der in Zyklus 1 entwickelten Funktionali-tät durch, erstellen ein Design für den Zyklus 3 und sammeln Daten über Nutzer für den Zyklus 4.

Dieses Vorgehen erlaubt es, Änderungen an der Software aufgrund von Usability-Problemen ganz kurzfristig vorzu-nehmen. Da das Nutzer-Interface sehr zeitnah getestet wird, können die Nutzer die Entwicklung besser beeinflussen. So wird eine deutlich höhere Kundenzufriedenheit erreicht. Mögliche Risiken durch ein ungenügendes Nutzer-Interface können gesenkt werden. Das Beispiel der Gebrauchstaug-lichkeit zeigt, dass eine enge Integration von Usability Engi-neering in ein agiles Vorgehen potenziell große Vorteile birgt.

Medizinische Software agil entwickeln Beispiel: Gebrauchstauglichkeit Michael Engler

Michael Engler

Agile Vorgehensweise

Michael Engler ist seit 2007 als Berater bei der Method Park Software AG tätig. Seine Themenschwerpunkte sind agile Methoden (insbesondere Scrum), sowie Requirements und Usability Engineering in der Medizintechnik.

Der Autor


Der Markt für medizinische Geräte ist hochregulativ. Das ist angesichts der potenziellen Gefahr für Patienten und Bedie-nungspersonal auch verständlich. Die Gesundheit soll sich dank des Einsatzes der hochkomplexen Geräte verbessern und nicht gefährdet werden. Daher ist nachvollziehbar, dass sich Gerätehersteller möglichst exakt an Vorgaben, Grenz-werte, Qualitätssicherungsprozesse, Testverfahren, usw. hal-ten müssen. Für die Hersteller bedeutet dies, sich bezüglich geltender Normen stets auf dem Laufenden halten zu müs-sen und die für die eigenen Geräte relevanten Aspekte und deren Änderungen bei jeder Neu- und Weiterentwicklung zu berücksichtigen.

Richtig kompliziert wird dies, sobald Geräte auf dem interna-tionalen Markt abgesetzt werden sollen. Die Normen unter-scheiden sich je nach Markt sehr, werden unterschiedlich schnell aktualisiert und auf unterschiedliche Weise überprüft. Dabei geht die Spannweite von reinen QS-Audits über den Einsatz von Testhäusern bis hin zu behördlichen Überprüfungen. Wenn man als Hersteller dem nicht mit kostspieligen, marktspe-zifischen Produktvarianten begegnen, sondern die Geräte möglichst universal entwickeln möchte, heißt dies, die sich aus dieser heterogenen Nor-men- und Verfahrensvielfalt ergebenden Anforde-rungen übersichtlich zu verwalten.

Dies ist keine leichte Aufgabe: Es gelten oft viele verschiedene, teils übergreifende, teils für spezi-fische Produktkategorien geltende Normen, die nicht nur aufeinander aufbauen, sondern sich im Detail auch widersprechen. Soll ein Gerät für den Weltmarkt entwickelt werden, potenziert sich diese Komplexität. Es müssen aber nicht nur die relevanten Anforderungen er-mittelt werden, sondern auch die erfüllten Normen für sich im Feld befindliche Geräte nachvollziehbar bleiben. Denn eine besondere Eigenheit der Rechtslage für medizinische Geräte ist die, dass Weiterentwicklungen (selbst wenn sie noch so klein sind) ein erneutes Inverkehrbringen bedeuten. Es müssen dafür die bei Einführung rechtsgültigen Normen neu erfüllt werden. Also müssen Normänderungen seit der letzten Zertifizierung analysiert werden, um festzustellen, in-wiefern eine Weiterentwicklung auch Anpassungen an die aktuellen Anforderungen enthalten muss.

Der Problemraum ist damit noch nicht vollständig beschrie-ben, denn es steht ein Paradigmenwechsel in der Normen-welt an: Im europäischen Raum wird ab 2012 die dritte Ver-sion der Normenreihe IEC-60601 gültig. Mit dieser enthalten diese Produktnormen eine Vielzahl von Prozessanforderun-

gen. Bei einer Zertifizierung werden dann nicht nur Pro-dukte, sondern auch rele-vante Prozesse überprüft. Wann dieser Paradigmen-wechsel auf den anderen Märkten ansteht, ist nur eine Frage der Zeit.Abhilfe kann eines metho-disches, toolunabhängiges Konzept schaffen, das es Herstellern von medizini-schen Geräten erlaubt, die aus den Normen abgelei-teten Anforderungen zu verwalten, Produktkonfigurationen

und varianten anzulegen, Auswirkungen auf Entwick-lungsprozesse zu analysieren und sich auf die Zer-tifizierungen vorzubereiten. Um Auswirkungsanaly-sen zu ermöglichen, muss dabei viel Wert auf eine

durchgängige Verfolgbarkeit der Anforderungen von der Norm bis zu den Testfällen gelegt wer-den. Auch die Ausgliederung der Spezifikation einzelner Komponenten für Zulieferer wird damit möglich. Dieses methodische Wissen benötigen Hersteller, die sich auf den internationalen Markt ausbreiten oder bereits relevante Normen bes-ser analysieren möchten.

Wer einen ersten Eindruck von einem solchen Konzept haben möchte, für den ist der erste ASQF Medical Device Day am 16. September 2010 im

IZMP in Erlangen eine erste Anlaufstelle. Im Rahmen dieser Veranstaltung wird zusammen mit einem großen ortsansäs-sigen Gerätehersteller ein Vortrag zu diesem Thema gehal-ten. Vielleicht gibt er Ihnen die ersten Denkanstöße, wie Sie dank Requirements Engineering den Weltmarkt erobern kön-nen – trotz der erdrückenden Normenvielfalt.

Dank RE für den Weltmarkt entwickeln - trotz NormenvielfaltHajo Hoffmann

Hajo Hoffmann

Hajo Hoffmann ist Berater der SOPHIST GmbH und ist spezialisiert auf Pro-duktlinienspezifikation in der auch sehr regulativen Automotive-Branche. Vor seiner Zeit als SOPHIST war er an der Entwicklung von Computertomographie-Software in Forchheim beteiligt.

Der Autor


BOOK AND EXAMGET PREPARED TO GET CERTIFIED! ALL-IN-ONE OFFER.

IN ZUSAMMENARBEIT MIT UNSEREM PARTNER DPUNKT.VERLAG/ROCKY NOOK UNTERSTÜTZEN WIR IHR SELBSTSTUDIUM ZUR VORBEREITUNG AUF EINE ZERTIFIZIERUNGSPRÜFUNG: JETZT BUCHEN UND DAS PASSENDE VORBEREITUNGSBUCH ZUM VORTEILSPREIS ERHALTEN!

Wie funktioniert’s?

Schicken Sie einfach eine E-Mail mit der Betreffszeile „Book and Exam“ an [email protected] und geben Sie darin an, welche Prüfung Sie buchen wollen. Sobald der Rechnungsbetrag eingegangen ist, senden wir Ihnen den Voucher für die Prüfung zu und der dpunkt.verlag versendet das entsprechende Vorbereitungsbuch zum Aktionspreis.*Wir wünschen viel Erfolg!

* Alle Preise verstehen sich zzgl. Mehrwertsteuer. Nur solange der Vorrat reicht. ** In Deutschland ist das Ablegen einer ISTQB® Prüfung ausschließlich als Paper-based Exam möglich. E-Exam Preise sind daher nur außerhalb Deutschlands gültig.

DIE AKTIONSPREISE IM ÜBERBLICK: Paper-based E-Exam

ISTQB® CERTIFIED TESTER – FOUNDATION LEVEL+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

ISTQB® CERTIFIED TESTER – ADVANCED LEVEL: TEST MANAGER+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

ISTQB® CERTIFIED TESTER – TEST ANALYST AND TECHNICAL TEST ANALYST+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

IREB® CERTIFIED PROFESSIONAL FOR REQUIREMENTS ENGINEERING+ Vorbereitungsbuch (deutsch)

300 € 250 €

ISAQB® CERTIFIED PROFESSIONAL FOR SOFTWARE ARCHITECTURE+ Vorbereitungsbuch (deutsch, nur als e-Book erhältlich)

300 € –

iSQI® Certifi ed Professional for Project Management+ Vorbereitungsbuch (deutsch)

300 € –



BOOK AND EXAMGET PREPARED TO GET CERTIFIED! ALL-IN-ONE OFFER.

IN ZUSAMMENARBEIT MIT UNSEREM PARTNER DPUNKT.VERLAG/ROCKY NOOK UNTERSTÜTZEN WIR IHR SELBSTSTUDIUM ZUR VORBEREITUNG AUF EINE ZERTIFIZIERUNGSPRÜFUNG: JETZT BUCHEN UND DAS PASSENDE VORBEREITUNGSBUCH ZUM VORTEILSPREIS ERHALTEN!

Wie funktioniert’s?

Schicken Sie einfach eine E-Mail mit der Betreffszeile „Book and Exam“ an [email protected] und geben Sie darin an, welche Prüfung Sie buchen wollen. Sobald der Rechnungsbetrag eingegangen ist, senden wir Ihnen den Voucher für die Prüfung zu und der dpunkt.verlag versendet das entsprechende Vorbereitungsbuch zum Aktionspreis.*Wir wünschen viel Erfolg!

* Alle Preise verstehen sich zzgl. Mehrwertsteuer. Nur solange der Vorrat reicht. ** In Deutschland ist das Ablegen einer ISTQB® Prüfung ausschließlich als Paper-based Exam möglich. E-Exam Preise sind daher nur außerhalb Deutschlands gültig.

DIE AKTIONSPREISE IM ÜBERBLICK: Paper-based E-Exam

ISTQB® CERTIFIED TESTER – FOUNDATION LEVEL+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

ISTQB® CERTIFIED TESTER – ADVANCED LEVEL: TEST MANAGER+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

ISTQB® CERTIFIED TESTER – TEST ANALYST AND TECHNICAL TEST ANALYST+ Vorbereitungsbuch (deutsch oder englisch)

250 € 200 €**

IREB® CERTIFIED PROFESSIONAL FOR REQUIREMENTS ENGINEERING+ Vorbereitungsbuch (deutsch)

300 € 250 €

ISAQB® CERTIFIED PROFESSIONAL FOR SOFTWARE ARCHITECTURE+ Vorbereitungsbuch (deutsch, nur als e-Book erhältlich)

300 € –

iSQI® Certifi ed Professional for Project Management+ Vorbereitungsbuch (deutsch)

300 € –



http://www.isqi.org/zertifizierung/book-and-exam/

Mitglieder Ausgabe 16 | September 2010 42

Das Van der Valk Hotel Berliner Ring und der ASQF laden ein zum 6. Ber-lin-Brandenburger Golfers-Cup mit anschließendem Charity-Golferball, am Samstag, dem 30. Oktober 2010, auf dem Grün des Golfcenter Gross Kienitz.Im Zentrum steht das Spielen für einen guten Zweck! Im Anschluss an das Turnier findet im Hotel Van der Valk Berliner Ring der große „Charity-Golfer-ball“ statt. Alle Teilnehmer und die Organisatoren unterstützen einen wohl-tätigen Zweck. Wer zusammen mit einem prominenten Teilnehmer in einem Flight spielen oder zusammen mit diesem den Charity Ball verbringen will, kann sich diesen Wunsch für einen symbolischen Spendenbetrag erfüllen. Weitere Informationen zu Spenden, Startgeld, Ballkarten, Sponsoren und Flightreservierungen

über [email protected] oder unter www.asqf.de/asqf-golf-cup.

Folgende prominente Gäste freuen sich, am 30. Oktober für einen guten Zweck zu Golfen und am Abend das Tanzbein zu schwingen: Axel Schulz, Box Champion, Alfred Draxler, Chefredakteur der „BILD“, Anna Maria Kaufmann, So-

pranistin, Lars Riedel, Olympiasieger und Weltmeister, Christian Schenk, Olympiasieger

und Weltmeister, Jan Josef Liefers, Mime, Anna Maria Loos, Schauspielerin, Andrea L‘ Arronge, Schauspielerin …und viele mehr!www.asqf.de | www.vandervalk.de | www.grosskienitz.de

Konferenz für Software Qualität24.–26. Mai 2011 | Düsseldorf, Deutschland

Nutzen Sie die Chance, Ihre Kompetenzen mit einem Fachpublikum zu teilen. Wir freuen uns auf Ihre Vorschläge in Form von Vorträgen oder Workshops. Die Konferenz fi ndet in deutscher Sprache statt.

Call for Papers

Einsendeschluss September

2010 www.iqnite-conferences.com/de

Anzeige SQ-Magazin.indd 1 15.07.2010 16:40:44

Anzeige

Wetten, dass?!: Mit dem ASQF Franken-Express zur CONQUEST

ASQF-Mitglieder erhalten zur CONQUEST 2010 in Dresden ein kostenfreies Tages-Ti-cket für den 21. oder 22. September. Doch damit nicht genug. Für die Heimatregion des ASQF, Franken, ist ASQF Geschäftsfüh-rer Stephan Goericke eine spezielle Wette eingegangen: Schafft es ASQF-Gründungs-mitglied Andreas Ditze (MID GmbH) einen ganzen Bus voller ASQF-Mitglieder von Franken aus nach Dresden zu schicken, dann zahlt das iSQI den Bus! 60 Sitzplätze stehen zur Verfügung. Also melden Sie sich schnell an: [email protected]

Genaue Reisedaten werden unter www.asqf.de bekannt gegeben.

6. Berlin-Brandenburger Golfers-Cup

Konferenz für Software Qualität24.–26. Mai 2011 | Düsseldorf, Deutschland

Nutzen Sie die Chance, Ihre Kompetenzen mit einem Fachpublikum zu teilen. Wir freuen uns auf Ihre Vorschläge in Form von Vorträgen oder Workshops. Die Konferenz fi ndet in deutscher Sprache statt.

Call for Papers

Einsendeschluss September

2010 www.iqnite-conferences.com/de

Anzeige SQ-Magazin.indd 1 15.07.2010 16:40:44

http://www.ignite-conferences.com/de

Quiz

Wir suchen aufgeweckte Softwareentwickler (m/w). Wo sind die engagierten Vor-, Mit- und Querdenker? Sie bringen Programmier-Know How mit und sind ein ausgeprägter Teamplayer, den auch internationale Projekte und knifflige Kun-denanforderungen nicht schrecken? Sie möchten beruflich in der 1. Liga der Technologie mitspielen und dafür auch leistungsgerecht entlohnt werden? Und obendrein noch spannende Aufgaben, verlockende Karrierechancen, kollegiale Kollegen, ein prima Klima und jede Menge Spaß im Job? Das gibt es nicht? Bei uns schon! Kommen Sie zu den Experten in Sachen Software der Metropolregion Nürnberg und unterstützen Sie uns bei der Entwicklung von maßgeschneiderten Softwarelösungen für die Industrieautomatisierung und Medizintechnik – wir freuen uns auf Sie! www.infoteam.de/jobs. E-Mail: [email protected]

Die Redaktion bedankt sich an dieser Stelle bei den fünf heldenhaften „Fehlerdrachen-Bezwingern“ und gratuliert recht herzlich. Wir danken für die zahlreichen Zuschrif-ten und wünschen viel Spaß mit den „Ge-schichten vom SCRUM. Von Sprints, Ret-rospektiven und agilen Werten“!

Die Gewinner des Buches lauten:- Alexander Vogt, AIS Automation Dresden GmbH- Joerg Sievers, Ahrensburg,- Joachim Ullrich, Renesas Electronics Europe GmbH, Düsseldorf- Andreas Schreiner, C1 SetCon GmbH, Bochum- Rainer Ogger, Kaarst

Ein guter Job muss kein Traum bleiben – infoteam Software braucht Verstärkung.

empfiehlt „dilbert“ zur leichteren Alltagsbewältigung

Gewinner SQ-Magazin Nr. 15


Nachverfolgbarkeit ist eine wesentliche Anfor-derung zur Lösung des Sudoku. Nachverfolg-barkeit ist auch eine wesentliche Anforderung aus der IEC 62304 – der Norm für den Soft-warelebenszyklus. Das Buch „Basiswissen Medizinische Software. Aus- und Weiterbil-dung zum Certified Professional for Medical Software“, Christian Johner, Matthias Hölzer-

Klüpfel, Sven Wittorf, steht ab Oktober im dpunkt.verlag zur Ver-fügung. Es deckt das komplette Curriculum der Ausbildung zum

„Certified Professional for Medical Software“ ab und ergänzt die-ses durch ein durchgängiges Beispiel sowie Übungsaufgaben. Einen Schwerpunkt bildet der Inhalt der Norm IEC 62304 zum Softwarelebenszyklus, deren Forderungen mit gängigen Soft-wareentwicklungsprozessen und praktischen Software-Enginee-ring-Aspekten in Beziehung gesetzt werden. Wenn Sie eines der fünf Bücher gewinnen wollen, dann schicken Sie das richtige Lö-sungswort bitte bis 29. Oktober an [email protected].

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

5 2 9 7

9 8

3 6

7 5 6

5 4

8 3

7 8 4

4 2 6

2 1

Buchstaben: 1 = N, 2 = W, 3 = S, 4 = I, 5 = U, 6 = H, 7 = C, 8 = G, 9 = Q

Lösungswort:

__ __ __ __ __ __ __

SUDOKU

www.infoteam.de

Impressum

HerausgeberASQF e.V.AmWeichselgarten19,91058ErlangenTel +49913191910-0Fax +49913191910-10

David-Gilly-Str.1,14469PotsdamTel +49331231810-0Fax [email protected], www.asqf.de

RedaktionV.i.S.d.P.: Stephan Goericke (Geschäftsführer)

Redaktion: Jana Noack, Felix [email protected]

Satz/Layout:Frenkelson Werbeagentur, Potsdam www.frenkelson.de

Fotos:ASQF e.V. und iSQI GmbHTitelbild: © Jochen K – Fotolia.comS. 25 – iStockphoto.com © Bochkarev PhotographyS. 40 – iStockphoto © TommLS.42 – mit freundlicher Genehmigung Eagles Charity Golf Club e.V.

Alle Portraits und Grafiken mit freundlicher Genehmigung der Autoren.

Druck: te Neues, Kempen

Druckauflage:3.000Stück

Internetausgabewww.asqf.de/sqmagazin

MediadatenGern senden wir Ihnen unsere Mediadaten zu. Richten Sie Ihre Anfrage an [email protected]. Weitergabe und Vervielfältigung, auch auszugsweise, ist unter vollständiger Angabe der Quelle erlaubt.

Haben Sie Anregungen zu den Inhalten des SQ-Magazins, dann schreiben Sie an:[email protected]

Namentlich gekennzeichnete Beiträge müs-sen nicht mit der Meinung der Redaktion übereinstimmen. Die Redaktion behält sich das Recht auf sinngerechte Kürzung und Bearbeitung eingereichter Manuskripte vor.Wir machen darauf aufmerksam, dass Da-ten nicht an Dritte weitergegeben und aus-schließlich zur internen Auswertung heran-gezogen werden können.

Sept

embe

r 201

0

FG Software-Test, Berlin-Brandenburg | 06.09.2010, Berlin Dr.-Ing. Dehla Sokenou (GEBIT Solutions GmbH) GUI-Testen mit Open-Source-Frameworks

FG Maturity Models, Franken | 08.09.2010 N.N.

Vorankündigung

FG Automotive, Franken | 14.09.2010, Röttenbach Dr. Günter Glöe (CATS Software Tools GmbH)

RiskCAT 26262 – Die neue Norm für Funktionale Sicherheit in der Fahrzeugelektronikund deren Anwendung in der Praxis

FG Softwaretest, Bayern Süd | 14.09.2010, Unterschleißheim Matthias Zieger, Microsoft Deutschland GmbHManagen von virtuellen Testumgebungen

FG Medizintechnik, Franken – 1. Medical Device Day | 16.09.2010, Erlangen diverse

Komplexität beherrschen

FG Software Test, Schwaben | 22.09.2010, Ulm Dr. Thomas Zurawka (SYSTECS Informationssysteme GmbH)

Testmethodik für Embedded Software in der Automobil- und Medizintechnik

FG Safety, Rhein-Main | 23.09.2010, Wiesbaden Dipl. Ing. Michael Lange und Vera Gebhardt (tecmata GmbH)

IEC61508KonzeptphaseinderPraxis

FG Modellierung, Franken | 23.09.2010, N.N. N.N.

Methoden zum Vergleich von Modellen einschl. Änderungsmanagement auf Modellen

FG Automotive, NRW | 29.09.2010, Bochum Dipl.-Ing. Arne Lenz (Delphi Deutschland GmbH)Praxiserfahrungen mit AUTOSAR

FG Software Test, Baden-Württemberg, 2. Software-Testing Day | 30.09.2010, Ludwigsburg

diverse

Test the best

FG Automatisierung, Franken | 30.09.2010, Bubenreuth Dr. Hans Egermeier (Bernecker + Rainer Industrie-Elektronik GmbH)

wird noch bekannt gegeben

Okto

ber 2

010

FG Projektmanagement, Franken | 06.10.2010, Bubenreuth Sven Opitz (Mensch-System-Erfolg.de)

Erfolgsfaktoren im Projektmanagement (Teil 1) – Der Mensch

FG Software-Test, Rhein-Main – 4. Rhein-Main Testing Day | 07.10.2010 diverse

Aus der Praxis für die Praxis

FG Automatisierung, Franken | 14.10.2010, Bubenreuth N.N.

Vorankündigung

FG Software-Test | 18.10.2010, Berlin Dipl.-Inf. Udo Spring, Loyal Team

Softwaretesting in agilen Umgebungen – Werkzeuge und Methoden

FG Maturity Models Franken | 19.10.2010, Erlangen Filippo Vitiello, Michael Engler (Method Park Software AG)SCRUM setzt CMMI um - oder denken Sie anders?

FG Softwaretest, Sachsen | 19.10.2010, Dresden Steffen Stundzig (itemis AG)

Fit mit Modellen

FG Automation, Franken – 19.AutomationDay | 26.10.2010, Nürnberg diverse

Automatisierung im Jahr 2015

Nove

mbe

r 201

0

FG Software-Test, Franken | 09.11.2010, Erlangen Dr. Andreas Reuys (Logica Deutschland GmbH)Managed Test Services in Deutschland

FG Modellierung, Franken | 11.11.2010, N.N. Prof. Jörg Robra

MDSD, MDA - wo stehen wir heute? Haben sich die Prophezeiungen erfüllt?

FG Requirements Engineering, Berlin-Brandenburg Kick-Off-Veranstaltung! | 11.11.2010, Berlin

Heiko Köppen (Avenqo GmbH)

Die Anwendung von User Stories im RE – Methoden & Erfahrungen

FG Softwaretest, Baden-Württemberg | 18.11.2010 N.N.

Vorankündigung

FG Maturity Models, Baden-Württemberg | 23.11.2010, Sindelfingen Michaela Reinhardt, Tobias Barth (MBtech Group)Joining models - to fit all needs (CMMI and Automotive SPICE)

FG Softwaretest, Sachsen | 23.11.2010 N.N.

Vorankündigung

Fachgruppentermine September - November 2010SEPTEMBER 2010 OKTOBER 2010 NOVEMBER 2010

KW Mo Di Mi Do Fr Sa So KW Mo Di Mi Do Fr Sa So KW Mo Di Mi Do Fr Sa So

35 1 2 3 4 5 39 1 2 3 44 1 2 3 4 5 6 7

36 6 7 8 9 10 11 12 40 4 5 6 7 8 9 10 45 8 9 10 11 12 13 14

37 13 14 15 16 17 18 19 41 11 12 13 14 15 16 17 46 15 16 17 18 19 20 21

38 20 21 22 23 24 25 26 42 18 19 20 21 22 23 24 47 22 23 24 25 26 27 28

39 27 28 29 30 43 25 26 27 28 29 30 31 48 29 30

20 – 22 September 2010 Dresden, Germany - SQ-Magazin Wer hätte gedacht, dass Raben und Kakerlaken...

Documents

Transcript of 20 – 22 September 2010 Dresden, Germany - SQ-Magazin Wer hätte gedacht, dass Raben und Kakerlaken...