Ausgabe 16 - SQ
Transcrição
Ausgabe 16 - SQ
Arbeitskreis Software-Qualität und -Fortbildung e.V. Ausgabe 16 | September 2010 Arbeitskreis Software-Qualität und -Fortbildung e.V. K O S T E N F R EI K O S T E N F R EI E S CONQUEST-Tages für ASQF-Mitglie et CONQUEST-Tagestick für ASQF-Mitglieder 20 – 22 September 2010 Dresden, Germany MARITIM Hotel & International Congress Center Im Fokus: Projektmanagement Prominenter Schwung: Golfturnier mit vielen Stars © Jochen K – Fotolia.com Freier Eintritt: ASQF Mitglieder kostenlos zur CONQUEST Schulungen mit Aussicht Inhouse-Schulungen weltweit auf Deutsch, Englisch, Spanisch und Französisch http://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 Kurfürstendamm, Berlin © Katrin Schülke - Änderungen vorbehalten 06.09.10-10.09.10 13.09.10-16.09.10 04.10.10-07.10.10 11.10.10-13.10.10 11.10.10-15.10.10 18.10.10-19.10.10 19.10.10-21.10.10 25.10.10-29.10.10 26.10.10-28.10.10 02.11.10-05.11.10 08.11.10-12.11.10 15.11.10-18.11.10 22.11.10-26.11.10 29.11.10-30.11.10 01.12.10-03.12.10 07.12.10-09.12.10 13.12.10-17.12.10 Certified Tester Advanced Level – TECHNICAL TEST ANALYST Certified Tester Foundation Level Certified Tester Foundation Level Certified Tester Foundation Level – Kompaktkurs Certified Tester Advanced Level – TESTMANAGER Testen für Entwickler Certified Tester Foundation Level – Kompaktkurs Certified Tester Advanced Level – TEST ANALYST Certified Professional for Requirements Engineering – Foundation Level Certified Tester Foundation Level Certified Tester Advanced Level – TEST ANALYST Certified Tester Foundation Level Certified Tester Advanced Level – TESTMANAGER Testen für Entwickler Certified Professional for Requirements Engineering – Foundation Level Certified Tester Foundation Level – Kompaktkurs Certified Tester Advanced Level – TESTMANAGER Berlin Berlin Berlin Hannover München Berlin Frankfurt Stuttgart Berlin München Berlin Berlin Frankfurt Berlin Berlin Düsseldorf/Köln Berlin 3 Ausgabe 16 | September 2010 Editorial Liebe Freunde des ASQF Bürokratieabbau ist eine erstrebenswerte Zielsetzung – an einigen Stellen sogar der zusätzliche Treibstoff für unseren Wirtschaftsmotor. Doch wenn ich einen Diesel fahre, dann brauche ich kein Benzin. Ähnlich verhält es sich mit dem Verfahren zum elektronischen Entgeltnachweis ELENA. Seit dem 1. Januar sind die Arbeitgeber verpflichtet, die Entgeltdaten ihrer Beschäftigten an eine bei der Deutschen Rentenversicherung angesiedelte zentrale Speicherstelle zu übermitteln. Mit einem Kosteneinsparungspotenzial von 500 Mio. € gestarStephan Goericke, Geschäftsführer ASQF e.V. und iSQI GmbH 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 Unternehmen 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 Wirtschaftsminister 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, zukunftsweisenden, trendsaufspürenden, austauschgeprägten Miteinander auf der CONQUEST 2010. Und für alle ASQF-Mitglieder gilt: Sie erhalten ein kostenfreies 1-TagesTicket. 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! INHALT 3 Editorial 4ASQF-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 „Requirements Engineering“-Standard mit neuem Lehrplan Neu im iSQI Portfolio: Der ISEB Intermediate in Software Testing Im Fokus: CONQUEST Test Maturity Model integrated (TMMi) als Modell zur Prozessverbesserung 8 Dr. Jekyll and Mr. Hyde – Die zwei Seiten von Requirements Engineering 10 Erfolgsfaktoren für die MBT-Einführung 6 6 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 Automobilhersteller durch Software im Fahrzeug flexibel bleiben 18 Interview: mit G. Ó Súilleabháin 26 26 28 30 Im Fokus: Projektmanagement Agilität und Verteilte Entwicklung Der Migrationstest-Prozess Wie man agiles Vorgehen nach Scrum mit dem V-Modell XT kombiniert 36 „Software Quality“ in Dresden 37 37 39 40 Im Fokus: Medizintechnik Der Software-Lebenszyklus für medizinische Geräte Medizinische Software agil entwickeln Dank RE für den Weltmarkt entwickeln – trotz Normenvielfalt 42 Mitglieder 6. Berlin-Brandenburger Golfers-Cup Ihr Stephan Goericke. 43Quiz 44 Fachgruppen-Termine NEWS Angefordert: Fachgruppe Requirements Engineering Die ASQF-Fachgruppen bekommen Zuwachs. Mit dem Thema „Requirements Engineering“ erschließt der ASQF in den Regionen Franken und Berlin/Brandenburg ein weiteres Fachgebiet der Qualitätssicherung. Für die Fachgruppenleiter ist RE dabei nicht als isolierte Disziplin zu betrachten, sondern als integrativer Bestandteil 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 ASQF Ausgabe 16 | September 2010 4 Neu: Medical Device Day in Erlangen Mit dem Medical Device Day (MDD) hat der ASQF eine weitere Ganztagesveranstaltung in sein Programm aufgenommen. Unter dem Motto „Komplexität beherrschen“ laden der ASQF und der Spitzencluster Medical Valley EMN am 16.09. zum Erfahrungsaustausch im hochkomplexen Umfeld „Medizinprodukte“. Die insgesamt neun Fachreferenten beschäftigen sich dabei mit der Komplexität im technischen Projektmanagement sowie der Komplexität in den Medizinprodukten selbst. www.asqf.de/medical-device-day Rückblick: Agil im Projektmanagement 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 Erwartungen 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 Projekterfolgs und den Do’s and Dont’s bei der Einführung von SCRUM wurden die Möglichkeiten der Projektvorhersage unter den Bedingungen der nichtlinearen Zukunft diskutiert und durch sehr praxisnahe Berichte über Erfahrungen 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. Bis zu 150 Teilnehmer kamen zum 2. PM-Day in die Fürther Pyramide Ausblick: heißer Herbst mit drei ASQF-Days 30. SEPTEMBER, Ludwigsburg: 2. Baden-Württemberg Testing-Day Unter dem Motto „Test the Best“ lädt die Fachgruppe Software-Test Baden-Württemberg zum zweiten Testing-Day nach Ludwigsburg ein. 07. OKTOBER, Frankfurt: 4. Rhein-Main Testing-Day Der 4. Rhein-Main Testing-Day steht wieder unter dem Leitsatz „Aus der Praxis für die Praxis“. Referenten berichten aus ihrem Praxisalltag und diskutieren mit den Teilnehmern. 26. OKTOBER, Nürnberg: 19. Automation Day Nürnberg Wie 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 Automation Valley Nordbayern wieder ein hervorragendes Programm erstellt werden. www.asqf.de/automation-day. 5 Ausgabe 16 | September 2010 iSQI Punktabzug: IREB „Requirements Engineering“-Standard mit neuem Lehrplan Das International Requirements Engineering Board (IREB e.V.) hat zum 01. September 2010 eine überarbeitete Version des Lehrplans zum „Certified Professional for Requirements Engineering“ veröffentlicht. Einhergehend 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 Dateien zum neuen Lehrplan zur Verfügung, bei denen eine im Änderungsmodus das schnelle Auffinden der Neuerungen im Vergleich zum bisherigen Lehrplan ermöglicht. Informationen zu IREB-Schulungsterminen, Öffentlichen Prüfungen und EExam in diesem Heft und auf www.isqi.org. Fragen können Sie gern unter der Kontaktadresse [email protected] stellen. Neu im iSQI Portfolio: Der ISEB Intermediate in Software Testing 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 neben Foundation- und Advanced Level, den Intermediate, der allerdings unabhä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 Teilnehmer 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 Intermediate 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 Schulungsterminen, können Sie sich gerne jederzeit an die Zertifizierungsabteilung des iSQI wenden. NEWS Neu: Öffentliche Prüfungen jetzt auch in Stuttgart Aufgrund der hohen Nachfrage nach öffentlichen 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 besonders 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, Frau Helbig ([email protected]/ Tel.: 0331 231810-29). International: iSQI zu Gast in Riga iSQI war im Juli beim Internationalen ITForum 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 Certification“ referiert. Am letzten Konferenztag, der dem in Lettland recht neuen Thema „Business Analysis“ gewidmet war, sprach er über eine der Schlüsseldisziplinen der SoftwareEntwicklung: 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-Zertifizierung anbieten. Im Fokus Dienstag, 21. Sept. Ausgabe 16 | September 2010 6 Session C1, 1.3 Test Maturity Model integrated (TMMi) als Modell zur Prozessverbesserung Matthias Rasking und Simon Lamers Einleitung – Warum messbare und referenzierbare Prozessverbesserung? Effiziente und effektive Prozesse bilden den Rahmen jeder 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 Fragen zur Qualitätsverbesserung wie “Wo fange ich bei meinem 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 gewü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 Referenzmodell Das Testing Maturity Model Integrated (TMMi) dient einer transparenten, offenen und standardisierten Beschreibung von Prozessen im Bereich Software Testing. Die Ursprünge 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 TMMiStandard sowie ein Bewertungsschema für die Reifegradanalyse von Testprozessen zu schaffen. Die TMMi Foundation wird dabei von zahlreichen Partnern aus Industrie und Forschung unterstützt. Die jeweils 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 Polytechnic University, Improve QS, SysQA und Wipro an der Fertigstellung der Maturity Level 4 und 5 (geplant zum Dezember 2010). Jeder ist eingeladen, der TMMi Foundation als individuelles Mitglied beizutreten und so an der Weiterentwicklung des Modells mitzuarbeiten. Überblick TMMi Der TMMi-Standard beschreibt die Evolution einer Testorganisation über fünf aufeinander aufbauende Level unterschiedlicher Reifegrade. Wird ein neuer Level erreicht, so dokumentiert dies eine deutliche Verbesserung innerhalb der Organisation. Gleichzeitig wird damit die Grundlage geschaffen, um auf den folgenden Level springen zu können. Hierzu enthält TMMi Methoden, welche die Organisation anleitet, sich Schritt für Schritt weiterzuentwickeln. Simon Lamers Matthias Rasking Die fünf Reifegrade des TMMi Befindet sich eine Organisation auf dem untersten Level 1 (Initial) des TMMi-Standards, so ist kein fixer Testprozess 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 kontrollierter 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 Methoden über den gesamten Softwareentwicklungszyklus gemessen und der Testprozess anhand der Messergebnisse 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 darauf, Fehler zu finden, sondern versucht nun auch, Fehler proaktiv zu vermeiden. Für die Level 2 bis 5 definiert der TMMi-Standard ferner unterschiedliche Prozessgebiete pro Level, deren Einhaltung anhand der „spezifischen Ziele“ gemessen werden kann. „Spezifische Verfahrensweisen“ („Specific Practices“) unterstützen beim Erreichen der Ziele. Jede Verfahrensweise 7 CONQUEST Ausgabe 16 | September 2010 in TMMi ist mit typischen Arbeitsergebnissen und Prozessschritten versehen und wird anhand anschaulicher Beispiele erklärt, so dass die Prozessverbesserung mit konkreten Aktivitäten geplant werden kann. Hierbei lohnt sich der Aufbau eines unternehmensspezifischen Glossars (zum Beispiel auf Basis des ISTQB-Glossars), um die Fachbegriffe in TMMi für die Beteiligten verständlich zu machen. Prozessverbesserung mit TMMi Basierend auf diesen Grundlagen kann das TMMi-Referenzmodell als Ausgangspunkt und Zieldefinition für Software-Testing-Prozesse verwendet werden. Die klare und frei erhältliche, an CMMi und ISO 15504 angelehnte Struktur 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 Framework (zum Patent angemeldet) dient hierbei als Fragenkatalog, um die einzelnen Bereiche strukturiert zu erfassen und auswerten zu können. Die fünf TMMi Reifegrade und deren Prozessgebiete Nach der Ausarbeitung der einzelnen Punkte können diese in Pilotprojekten überprüft und mit den gewonnenen Erkenntnissen überarbeitet werden, um sie dann in der Breite verfügbar zu machen. Begleitende Schulungen und vielfältige Kommunikationsmaßnahmen sind in diesem Schritt sehr wichtig, um die Änderungen verständlich zu machen und so eine Akzeptanz zu erreichen. Vorgehen für eine Prozessverbesserung mit TMMi 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öglicht dabei den Beteiligten, die Einführung von Veränderungen jederzeit durch eine erneute Analyse zu überprüfen, Prioritäten zu setzen und an die jeweilige Situation im Unternehmen 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 angegangen werden kann. Hierbei empfiehlt sich eine anfängliche 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 Arbeitspakete aufgeteilt werden können. TMMi bietet sich also als offener Standard für die Prozessverbesserung im Test- und Qualitätsmanagement an und unterstützt Unternehmen bei der Effizienz- und Effektivitätssteigerung ihrer IT-Prozesse. Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! 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 Engineering in komplexen IT-Projekten spezialisiert. Zudem ist er Mitglied der Working Group für Modellentwicklung und –wartung bei der TMMi Foundation. Im Fokus Mittwoch, 22. Sept. Ausgabe 16 | September 2010 8 Session C4, 4.3 Dr. Jekyll and Mr. Hyde – Die zwei Seiten von Requirements Engineering: Was jede Organisation über die Einführung von Anforderungsmanagement-Praktiken wissen sollte Christian Lescher, Helmut Frauenknecht Effektives Requirements Engineering (RE) ist Voraussetzung, um die Erwartungen der Kunden und des Markts zu treffen, sowie Fehlleistungen und Zeitverzögerungen zu vermeiden. 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 Ergebnissen führt, ist mehr Requirements Engineering ab einem bestimmten Punkt kontraproduktiv. Anstatt so viele Anforderungsmanagement-Praktiken wie möglich zu implementieren, brauchen Organisationen eine fokussierte Strategie. Insbesondere im Kontext von global verteilten Entwicklungsprojekten muss sich das Vorgehen auf Zusammenarbeit und Kommunikation fokussieren. Welche RE-Strategie soll eine Organisation verfolgen? In unserem Beitrag bei der CONQUEST 2010 fassen wir Erfahrungen 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, Entwicklungsleitern und Systemtestverantwortlichen. Christian Lescher Helmut Frauenknecht duktiv für das Ergebnis ist. Erfolgreicher ist eine fokussierte Strategie zu verfolgen, die im jeweiligen Kontext angemessen ist. Als unterscheidbare Kontexte haben sich typische Projektszenarien herauskristallisiert, für die eine spezielle REStrategie empfehlenswert ist. Vier Projekttypen sind hier beschrieben, siehe Abbildung 1. Die Analyseergebnisse zeigen, dass ein RE-Prozess für jedes 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 Requirements 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. Insbesondere kommt es darauf an, frühzeitig die richtige Strategie 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 Anforderungen 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- Abb. 1. Unterschiedliche Projekttypen erfordern eine fokussierte RE-Strategie 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 zwischen den Kundenanforderungen und dem eigenem System bzw. Produkt aufzudecken. Dazu dienen gut dokumentierte standardisierte System-/Produkt-Anforderungen. 9 CONQUEST Ausgabe 16 | September 2010 Komplexe Projekte sind häufig Projekte mit hohem Risiko, die sich auf neuem technologischen Gebiet bewegen und/ oder sich durch hohe Komplexität auszeichnen. Organisationen 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 herauszuarbeiten. Nur so sind ein zielgerichtetes Vorgehen und eine effektive Diskussion mit dem Kunden möglich. Es ist erforderlich, Anforderungen und Lösungen vorab zu überprüfen, z.B. durch Simulation komplexer Systeme, um zu ermitteln, ob ein gewählter technischer Ansatz den Kundenanforderungen genügt. • Der Aufwand im Änderungsmanagement explodierte, insbesondere da die Anforderungsänderungen schneller eintrafen, als die Verarbeitung von Änderungen im Prozess dauerte. • Letztendlich liefen die Anforderungsdatenbank und die tatsä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 „Gesetz des abnehmenden Ertrags“ folgt (Abbildung 2). Das bedeutet, dass ab einem bestimmten Punkt jeder zusätzliche in RE investierte Aufwand zu immer weniger Ergebnis führt. Evolutionäre Produktentwicklungen werden in der Regel von der internen Forschung und Entwicklung beauftragt und bezahlt. Die Anzahl der Anforderungen ist wesentlich niedriger (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 Anforderungen 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 Budget- und Zeitrahmen haben und deshalb nur sehr beschränkte 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-Praktiken am erfolgreichsten sind, wenn sie der vorhandenen Projektsituation angepasst werden. Zusätzlich haben wir gelernt, dass dies notwendig, aber nicht unbedingt hinreichend ist, um erfolgreich zu sein. Eines der untersuchten komplexen Projekte hat erheblichen Aufwand betrieben, um Anforderungen im Detail zu sammeln und zu dokumentieren, was zu einer Reihe von Problemen führte: • Die Anzahl der Anforderungen war zu groß, um den großen Zusammenhang zu sehen, der Überblick ging verloren und es kam schlussendlich zu einer „Big Bang“ Integration und Test. • Die feine Granularität brachte die Gefahr mit sich, sich in technischen Details zu verlaufen, z.B. in Vertragsverhandlungen und Diskussionen mit dem Kunden. Abb. 2. Das Gesetz des abnehmenden Ertrags für RE Anforderungsmanagement in global verteilten Projekten Insbesondere in global verteilten Projektteams ist Kommunikation und Zusammenarbeit im RE der entscheidende Erfolgsfaktor. Eine bewährte „best practice“ ist der sogenannte Cross-Funktionale Requirements Workshop, bei dem Teammitglieder aus verschiedenen Disziplinen und von mehreren Standorten in einer frühen Phase des Projekts gemeinsam die Anforderungen analysieren. In diesem Workshop werden alle Anforderungen in der gesamten cross-funktionalen Gruppe durchgesprochen. So können Unklarheiten und Abhängigkeiten frühzeitig erkannt werden. Zum Beispiel hat der Systemtester oft eine sehr gute Vorstellung des Gesamtsystems und wie es beim Kunden eingesetzt werden soll. Auch wenn dies als aufwändige Prozedur erscheint: Unsere Erfahrung hat gezeigt, dass der Fokus auf Kommunikation und Zusammenarbeit sich im Projekt immer auszahlt. Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Die Autoren 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. Im Fokus Dienstag, 21. Sept. Ausgabe 16 | September 2010 10 Session B2, 2.3 Erfolgsfaktoren für die MBT-Einführung – ein Erfahrungsbericht Dr. Christian Brandes 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 belastbaren 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 gemeint – etwa aus der objektorientierten Analyse auf Basis von UML-Diagrammen – oder sollen eigenständige Testmodelle entstehen, die aus Testsicht mehr „Platz“ für testrelevante 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: • die Ziele, die man sich von einem MBT-Einsatz zu erreichen hofft. • der Reifegrad der etablierten Testprozesse, die um MBT angereichert werden sollen. • die Modellierungskenntnisse des Testpersonals. In Abbildung 1 sind drei Ausprägungen von modellbasiertem Testen zu sehen. Sie unterscheiden sich hinsichtlich der Rolle, die Modelle im Testprozess einnehmen, und im Reifegrad der Integration der eingesetzten Werkzeuge. Entscheidend ist, dass der gewählte MBT-Ansatz zum vorhandenen Testreifegrad passt: So ist der Einsatz eines MBT-Werkzeugs, das massive UML- und OCL-Kenntnisse zur Modellerstellung voraussetzt, problematisch Christian Brandes 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 einerseits 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 Modellierungskonventionen aufsetzen, denn andernfalls wird der Generator mit „Input“ konfrontiert, der zu unbrauchbaren oder ungenü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 Traceability unterstützen. Und schließlich durchzieht das Thema „Versionierung“ auch den modellbasierten Testprozess: Wenn keine wohldefinierten Baselines für die eingesetzten 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 entstehen, der von den Beteiligten als Gewinn, Arbeitserleichterung und Hilfsmittel betrachtet wird. Eine gute Einstiegshilfe zur Ermittlung des eigenen MBTBedarfs und der vorhandenen MBT-Fähigkeiten ist zu finden in [1]. Dort wird anhand von Entscheidungsdiagrammen 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. Abbildung 1: Drei Ausprägungen von modellbasiertem Testen (aus [2]) 11 CONQUEST Ausgabe 16 | September 2010 LITERATUR: [1] Güldali, B.; Jungmayr, S.; Mlynarski, M.; Neumann, S.; Winter, M.: Starthilfe für modellbasiertes Testen: Entscheidungsunterstützung für Projekt- und Testmanager. OBJEKTspektrum 3/10, S. 6369, 2010. [2] Roßner, T.; Brandes, C.; Götz, H; Winter, M.: „Basiswissen Modellbasierter Test“, dpunkt.verlag 2010 Abbildung 2: Die Skill-Schnittmenge zwischen Modellierern und Testern ist heute noch gering (aus [2]). Während Entwickler schon seit vielen Jahren z.B. UML-Diagramme 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. Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! 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 Schwerpunkte sind Tests in einer SOA und der methodische Übergang von Softwaremodellen zu automatisiert ausführbaren Tests. Anzeige Zielsicher zum Erfolg So 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® Certified Tester“ Neben allen ISTQB®-Seminaren finden 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 CONQUEST 2010 Ausgabe 16 | September 2010 12 Monday, September 20, Day 1 8:00 Tutorial Registration – Welcome Coffee 12.00 Tutorial I (de) Room: Konferenz 3 Testprozessverbesserung mit TPI-Next Graham Bath T-Systems GEI, Germany 12:00 Lunch Break (12:00 – 13.00) 9:00 _ 13:00 _ 16.00 Tutorial III (de) Room: Konferenz 3 Ganzheitliches ProjektEngineering mit dem Quality Risk Management Framework Daniel Simon E.ON Energy Trading SE, Germany Frank Simon SQS, Germany Tutorial II (en) Room: Konferenz 4 Applying the Scrum management framework in a real life project scenario Frank Beeh/ Ralph Jocham Zühlke Engineering, Germany Tutorial IV (de) Room: Konferenz 4 .mzT – Testen mit Modellen im industriellen Umfeld Martin Beißer sepp.med, Germany 16:00 Conference Pre-Registration – Coffee Break 16:30 Public Examination 13:15 Full Day Tutorial (de) Room: Konferenz 5 Die perfekte CPREVorbereitung Chris Rupp SOPHIST, Germany Full Day Tutorial (de) Room: Konferenz 5 Die perfekte CPREVorbereitung Chris Rupp SOPHIST, Germany 13:20 – 13:40 14:20 – 14:40 14:45 – 15:35 15:35 15:40 – 16:00 Tuesday, September 21, Day 2 8:00 9:00 9:30 10:20 10:30 _ Conference Registration – Coffee Break - Exhibition Opening Room: Konferenz 6 Stephan Goericke (Conference Chair), iSQI GmbH, Germany Ina Schieferdecker (Program Committee Chair), Fraunhofer FOKUS, Germany + Welcome Adress from Said Zahedani Opening Keynote Room: Konferenz 6 Testing extends to the Cloud – Same Same, but Different…? (en) Said Zahedani, Microsoft, Germany Coffee Break – Exhibition (10:20 – 10.50) Industrial Presentation Room: Exhibition Softwaretests Open Source als „Test as a Service“ (de) Peter Kaufmann, T-Systems MMS 16:05 – 16:50 16:55 – 17:40 10.50 10:50 _ 11.35 11:40 _ 12.25 12:30 – 13:15 Session C1 Room: Konferenz 5 Lunch Break (13:15 – 14.45) Industrial Presentation Room: Exhibition TPI (Test Process Improvement) in a complex organization with multiple system environments Arjan Brands, Díaz & Hilterscheid, Germany Industrial Presentation Room: Exhibition Testen Sie Ihre aktuellsten Anforderungen? Oliver Böhm MKS, Germany 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) Coffee Break – Exhibition (15:35 – 16.05) Industrial Presentation Room: Exhibition Saxonia Systems – Der sächsische Qualitäts-Dienstleister Wir lieben IT und leben Qualität. Marco Fischer, Saxonia Systems, Germany Session A2 Room: Session B2 Room: Session C2 Room: Konferenz 3 Konferenz 4 Konferenz 5 Safety SIG Model Based SoftwareentwicklungsChair: Bernhard Testing und Testprozesse Sechser Chair: Florian Prester Chair: Helmut Pichler presented by presented by Method Park Software SIG MBT A2.1 Functional Safety in Standards (en) Klaudia Dussa-Zieger Method Park Software, Germany B2.1 „MBT quo Vadis?“ (de) Florian Prester sepp.med, Germany C2.1 Agile Methoden in einem ERP Migrationsprojekt (de) Sven Tissot pdv TAS, Germany Sebastian Middeke C1 WPS, Germany A2.2 Der steinige Weg vom Produktrisiko zum Softwarerisiko (de) Markus Manleitner Dräger Medical, Germany B2.2 Modellbasiertes Testen – Design und Implementierung am Beispiel „Vespa Shop“(de) Heike Urban T-Systems Multimedia Solutions, Germany C2.2 Rangliste der Einflussfaktoren auf den Testaufwand (de) Melanie Wohnert Loyalty Partner Solutions, Germany A2.3 Combined Use of SPICE and ISO 26262 – A Case Study from a German Task Force (en) Richard Messnarz ISCN, Austria B2.3 Erfolgsfaktoren für die MBT-Einführung – ein Erfahrungsbericht (de) Christian Brandes Bundesagentur für Arbeit, Germany C2.3 Fehlerbasierte Softwareprozessverbesserung – Methodik und Anwendungserfahrungen (de) Ralph Trittmann Rheinische Fachhochschule Köln, Germany Session A1 Room: Konferenz 3 Session B1 Room: Konferenz 4 Classic or Agile – What Counts is Business Value Chair: Manfred Baumgartner presented by ANECON Modellbasiertes Testen Testing Processes – Ein Fall, der sich Chair: Peter Zimmerer rechnet! Chair: Thomas Weber presented by SQS 17:45 – 18:30 A1.1 Software-Test als Teil der eGovernment Umsetzungs-Strategie des Freistaates Sachsen (de) Jan Overbeck ANECON, Austria B1.1 Prüfung kommunaler Programme in Sachsen (de) Axel Lohmann SAKD, Germany C1.1 Integrating Open Source Tools to Catalyze Flex Application Testing (en) Rohit Kothari LNT Infotech, India 18:30 Break 19:00 Social Event – Meeting Point: Foyer (Entrance level) A1.2 Efficiency and Effectivenes – Test Methodology and Automation (en) Thomas Bucsics ANECON, Austria B1.2 Der Methodische Ansatz des modellbasierten Testens incl. ROI (de) Frank Simon SQS, Germany C1.2 A Systematic Method for Identifying Testing Project Risks (en) Andreas Schmietendorf Berlin School of Economics, Germany A1.3 Agile Testing in SCRUM (de) Gerald Grossmayer bwin Interactive Entertainment, Austria Manfred Baumgartner ANECON, Austria B1.3 SQS - Praxisbeispiel aus dem Testumfeld (de) Hans-Jürgen Kohns SQS, Germany C1.3 Process Improvement with TMMi (en) Matthias Rasking Accenture, Germany Wednesday, September 22, Day 3 8:30 9:00 9:50 10:00 – 10:20 Conference Registration Keynote Room: Konferenz 6 Experiences in Testautomation Dorothy Graham, Grove Consultants, UK Coffee Break – Exhibition (09:50 – 10.20) Industrial Presentation Room: Exhibition Modular Test Case Design Michael Oestereich, profi.com, Germany Session A3 Room: Konferenz 3 Session B3 Room: Konferenz 4 Session C3 Room: Konferenz 5 State-of-the-art Requirements Engineering in der Praxis Chair: Chris Rupp presented by SOPHIST Certifications and Project Management Chair: Bernd Hindel Software Development Chair: Maud Schlich Programmänderungen vorbehalten / Stand August 2010 13 CONQUEST 2010 Ausgabe 16 | September 2010 A3.1 Klassische Anforderungen vs. Product Backlog (de) Chris Rupp / Hajo Hoffmann SOPHIST, Germany B3.1 Managing Software Development with the Approach of P2M: Program and Project Management framework3 (en) Susumu Sasabe JUSE, Japan A3.2 Systemanalyse auf den Punkt gebracht (de) Chris Rupp SOPHIST, Germany B3.2 ISEB Intermediate Foundation für den Advanced Level (de) Werner Lieblang Diaz & Hilterscheid, Germany 12:00 – 12:45 A3.3 Modelle und Qualität – natürliche Verbündete (de) Stefan Walburg / Christian Brandes Bundesagentur für Arbeit, Germany B3.3 ISTQB Foundation Level: Key Fundamentals for Specialists (en) Hans Hartmann OBJENTIS Software Integration, Austria 12:45 Lunch Break (12:45 – 14:00) 12:50 – 13:10 14:00 – 14:50 Industrial Presentation Room: Exhibition .getmore – Der Testfallgenerator Armin Metzger, sepp.med, Germany Keynote Room: Konferenz 6 Software Quality in the Age of Globalization Jutta Eckstein / Nicolai Josuttis, IT communication, Germany 14:50 Coffee Break – Exhibition (14:50 – 15:20) 10:20 – 11:05 11:10 – 11:55 C3.1 New Metrics for Global Software Engineering: Improving Project Management through Communication-based Early Warning Indicators (en) Christian Lescher TU Munich, Germany C3.2 Patterns for Testing in Global Software Development (en) Frank Salger capgemini, Germany 15:20 – 16:05 16:10 – 16:55 C3.3 Specification Metrics for Event-B Developments (en) Marta Olszewska Åbo Akademi University/ TUCS, Finland 17:00 – 17:45 17:45 Session A4 Room: Konferenz 3 Session B4 Room: Konferenz 4 Session C4 Room: Konferenz 5 Die Evolution der Testautomatisierung und des Testdatenmanagement für geschäftskritische Anwendungen Chair: Mike Schlabinger presented by TRICENTIS Medical IT Chair: Werner Reichel Requirements Engineering Chair: Markus Gärtner A4.1 10 Jahre Testmanagement bei der Deutschen Bank Bauspar AG – eine Erfolgsstory (de) Johannes Helders Deutsche Bank Bauspar, Germany B4.1 Normkonforme Softwareentwicklung nach IEC 62304 mit TFS. (de) Stefan Angele, Volker Majewski infoteam Software, Germany C4.1 Die RE-Völkerverständigung: Wissenswertes rund um die Zertifizierung zum „Certified Professional for Requirements Engineering“ (de) Chris Rupp, Rainer Grau, IREB, Germany A4.2 B4.2 C4.2 Der Nutzen von eines Funktionale Sicherheit Bridging the Gap fachlich orientierten von Medizinprodukten – between Business Automatisierungswerk- Sichtweise der genann- and IT with Enterprise zeugs und Quality Gates ten Stelle(n) (de) Mashups – An analysis in einem SAP Entwick- Werner Reichel of the Current Possibililungsprojekt (de) Siemens, Germany ties (en) Henry Smid / Dennis Andreas SchmietenKallies dorf, Berlin School of C:1 Solutions, Germany Economics and Law, Germany A4.3 Die Behebung des Testdatenproblems (de) Mike Schlabinger TRICENTIS, Germany B4.3 Introducing the “Certified Professional for Medical Software” training program (en) Georg Götz sepp.med, Germany Christian Johner Institut für IT im Gesundheitswesen, Germany C4.3 Dr. Jekyll and Mr. Hyde – The Two Sides of Requirements Engineering: What Every Organization Should Know When Introducing Requirements Engineering Practises (en) Christian Lescher / Helmut Frauenknecht Siemens, Germany Closing & Awards (17:45 – 18.00) www.conquest-conference.org 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] Kolumne Ausgabe 16 | September 2010 14 hier schreibt in regelmäßigen Abständen der Beirat des ASQF e.V. „Outsourcing - Gefahr oder Chance für Tester?“ Rudolf van Megen 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 Leistung, 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 outgesourct“ sei, während 33 Prozent erklärten, dass sie sowohl externe Tester als auch eigene Mitarbeiter einsetzen. 53 Prozent meldeten, dass sie alles Testen inhouse abwickeln. • In den sechs bis zwölf Monaten nach der Befragung planten acht Prozent der Befragten, „ihre Testaufgaben an einen 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 ökonomischen 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 werden.) Die Kostenvorteile entstehen beim Outsourcing primär dadurch, 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 Beispiel in Deutschland, Österreich oder der Schweiz - für Testmanager, funktionale Testexperten oder technische Testexperten? 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, solange keine stärkeren Zu- oder Abwanderungsbewegungen stattfinden. Zudem wird aufgrund der demoskopischen Entwicklung der Anteil der arbeitenden Bevölkerung gravierend abnehmen. Dies führt dazu, dass das Wirtschaftspotenzial von Europa nur erhalten werden kann, wenn mehr Leistungen von außen bezogen werden – unter anderem auch beim SoftwareTesten. Das Testen in IT-Projekten oder das Re-Testen während der Wartung und Weiterentwicklung (MainteRudolf van Megen nance) wird in Zukunft wesentlich arbeitsteiliger erbracht werden: • Testmanagement und Testdesign größtenteils onsite, also vor Ort • Testvorbereitung und Testausführung können offshore (z.B. Indien, Ägypten) oder nearshore, (z.B. baltische Staaten, Central Eastern Europe) erbracht werden • Testauswertung wiederum größtenteils onsite. Da also die besonders wichtigen Aufgaben des Testmanagements und der Testauswertung unbedingt vor Ort erbracht werden müssen, ist dies eine Chance für entsprechend qualifizierte Tester. Erfahrungsgemäß müssen auch in OffshoreProjekten mindestens 30 Prozent der Arbeitsleistung onsite erbracht werden, wenn diese Vorhaben erfolgreich sein wollen. Am Beginn der Verlagerung liegt der Vor-Ort-Anteil sogar bei 70 Prozent. Wer etwas anderes behauptet, will sich lediglich die Durchschnittskosten schön rechnen. Die onsite verbleibenden, höher qualifizierten Aufgaben bedeuten daher 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önlichen Voraussetzungen schaffen, wenn sie diese Chancen aufgreifen wollen. Testmanager zum Beispiel wird man nicht über Nacht. Vielmehr sind zwei Dinge wichtig: Aus- und Weiterbildung, etwa durch weitere Qualifizierungen nach dem Avanced Level der Certified-Tester-Ausbildung des International Software Testing Qualifications Board (ISTQB) und natü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. 15 Ausgabe 16 | September 2010 International SPICE Days International SPICE Days 2010 – Reflektionen des Conference Chairs Hans-Jürgen Kugler Dieses Jahr waren wir Teil des Open Forum 2010: International SPICE Days und Automotive Safety & Security – zwei Konferenzen unter einem Dach mit gemeinsamen Keynotes und der Möglichkeit, an Sitzungen beider Konferenz teilzunehmen. 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” Charakters der International SPICE Days verstärkt hat. Diskussionen in kleinen und größeren Gruppen fanden nicht nur zur Kaffeezeit an den Tischen in der Ausstellung statt. Die Mehrheit 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 SoftwareAspekten immer wichtiger. Dies liegt an der zunehmenden Komplexität und Sicherheitsrelevanz von immer vernetzteren Produkten. Die Beherrschung der Komplexität und Sicherheit 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 Organisationen beinhalten, sind verlässliche Prozesse eine Vorbedingung. Vorträge und Diskussionen über die Erweiterung der methodischen 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 verbunden 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 Heinecke, Geschäftsführer BMW Car IT, in seiner Keynote. Er beschrieb community-basierte Entwicklung als „Überlebensstrategie“ 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 erhöhen. Vertrauen war hier der Schlüsselbegriff – was besonders relevant ist für Prozesse im Bereich kreativer, menschlicher Zusammenarbeit. Prozesse sind nicht zur Maximierung der Kontrolle da, sondern sie sollten verbinden und Vertrauen 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 – unterstü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. Im Fokus Ausgabe 16 | September 2010 16 Ein Code für alle Fälle – Wie Automobilhersteller durch Software im Fahrzeug flexibel bleiben Volker Wilhelmi Im nächsten Jahr wird das Automobil 125 Jahre alt. Doch gegenwärtig gibt es kaum Grund zum Feiern: Die Weltwirtschaftskrise 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 Prozent, 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 Herausforderungen in Entwicklung und Produktion. Die Automobilindustrie ist gerade dabei, ihre Entwicklungsprozesse radikal anzupassen. Vor allem weist sie der Elektronik 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 heutzutage komplexe, vernetzte mechatronische Systeme mit mehreren tausend voneinander abhängigen Einzelfunktionen. Ein Leitungssatz kann bis zu fünf Kilometer Einzeldrähte umfassen – Tendenz steigend. Gesamtvernetzung der neuen Mercedes-Benz E-Klasse Flexibel durch modularen Ansatz Die Industrie tritt diesen Herausforderungen mit einem modularen Entwicklungsansatz entgegen, der sich an den einzelnen Funktionen des Systems „Auto“ orientiert. Er ermö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 Plattformen 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 herstellerübergreifende, internationale Verbund AUTOSAR (AUTomotive Open System ARchitecture), der einen offenen Standard für Software-Architekturen in Kraftfahrzeugen entwickelt und vorantreibt. AutomobilherVolker Wilhelmi steller können so SoftwareModule 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 verschiedenen Funktionseigenschaften ausstatten und mehrfach 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 Kombinationen eingeschaltet sein dürfen. Über individuell codierte 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 Funktionen Doch wie funktioniert das in der Praxis? Die länderspezifischen Vorgaben zur Lichtausgestaltung formuliert der Hersteller in Form einer Spezifikation und übergibt sie an den Zulieferer, der die gewünschten Anforderungen umsetzt, indem er ein darauf abgestimmtes Software-Modul entwickelt. Im nächsten Schritt liefert der Entwicklungspartner die Elektronik mit dem entsprechenden generierten Spezial-Code an den Automobilhersteller. Nach Implementierung des E/ESystems in das Fahrzeug, lädt der Hersteller den jeweils benö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ünsche umsetzen. Bevor Module oder Systemplattformen als baureihenübergreifende Standard-Komponenten zum Einsatz kommen, 17 Ausgabe 16 | September 2010 20.11.2010 Kongresshotel Potsdam am Templiner See TULIP 2010 sind diese ausgiebig zu testen. Die Kosten für eine nachträgliche Fehlerbehebung 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/ESystemen 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. Die Deutsche Parkinson Gala Jennifer Rush und weitere Künstler Der Zulieferer gibt dann die getesteten Komponenten mit einem Prüfprotokoll an den Automobilhersteller weiter. Dieser testet mit einem „Hardwarein-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. Getestet wird in Echtzeit und unter realen Umweltbedingungen. Dazu gehören zum Beispiel auch Tests für nicht-funktionale Anforderungen wie zum Beispiel 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 funktionieren. Jedes Testereignis wird protokolliert und ausgewertet. Damit ist eine frühe Analyse des entwickelten Gerätes möglich. Testfahrten zum Abschluss Hat ein E/E-System bewiesen, dass es funktioniert und stabil läuft, implementieren die Ingenieure es in das Fahrzeug und stoßen in einem letzten Schritt den Funktions- und Integrationstest im Gesamtfahrzeug an – in einem Prototypen also. Da diese Vorabexemplare einer späteren Serienfertigung sehr teuer sind, ist es umso wichtiger, dass alle elektrischen Funktionen, 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 Hersteller 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 Funktionsvariante 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 LIVE AUF DER TULIP ! Jennifer Rush Durch Ihre Teilnahme an der Gala unterstützen Sie die Entwicklung einer alternativen Bewegungstherapie für Parkinsonkranke in der Fachklinik Beelitz-Heilstätten Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Der Autor Volker Wilhelmi war Keynote-Referent auf der Konferenz iqnite. Diese fand vom 28. – 30. April 2010 in Düsseldorf statt. Die Konferenz zählt zu den wichtigsten Foren für den Gedanken- und Ideenaustausch innerhalb der Software Quality Community. www.parkinson-gala.org Medienpartner elm The Project: T he overall aim of the ELM project is to transfer a successful online assessment and qualification 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 offer online, multimedia-rich training courses. Certification is offered through the ECQA exam portal and certification system. Capability Advisor Learning System Course Unit: Pedagogy Cours Unit: Course Techn Technology Cours Unit: Course Manag Management ECQA Exam for Certification Job Role: E-Learning Manager Links: ELM Project Website: http://deis.ie/elm ECQA Website: http://ecqa.org DEIS Website: http://deis.ie “e-learning for e-learning managers” Interview Ausgabe 16 | September 2010 18 Interview mit Gearoid Ó Súilleabháin, leitender Koordinator des E-Learning Manager (ELM) Projekts 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 bedeutet? 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 definiert es sich weitaus umfassender – digitale Technologie trifft auf Lernen und schließt dabei auch Bildungsfernsehen, Videokonferenzen, DVD/Bluray, Mobilfunktechnologie, Computerspiele usw. mit ein. Für mich persönlich finde ich, dass es am meisten Sinn macht, E-Learning von anderen, vorhergehenden Traditionen wie Fernstudium und computergestütztem Lernen zu unterscheiden, 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 Entscheidungsträger in privaten Einrichtungen noch vom Konzept des E-Learnings ü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 traditionellen und größtenteils asynchronen Learning und Content Management Systemen vorzuziehen. Jemandem, der gerade anfängt sich mit E-Learning zu befassen, empfehle ich Kinderschritte zu machen, also klein anzufangen mit einem gut definierten Pilotprojekt. Alle Beteiligten müssen mit einbezogen und teure frühe Fehler vermieden werden. Jede Implementierung sollte beides berücksichtigen: 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 erfordert. Da Sie gemeinsam mit dem iSQI und anderen Partnern eine Berufsbeschreibung 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 richten, 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 19 Ausgabe 16 | September 2010 sind, E-Learning Lösungen zu beschaffen. Unserer Erfahrung nach arbeiten solche Individuen auf Managementebene in einer Personal- oder Fortbildungsabteilung und tragen die Verantwortung für eine ganze Reihe von sehr unterschiedlichen 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 Gesichtspunkten 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 Entwicklung 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 ELearning Manager Kurses bilden, wurden mit Hilfe des Feedbacks von professionellen E-Learning Managern und durch extensives Studieren und Auswerten der vorhandenen Literatur 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 Manager Kurs über ein integriertes e-Portfolio und Lernmanagement System zu absolvieren und anschließend eine europaweit 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 zweiten Pilotphase oder für eine Zertifizierung interessiert, kann sich auf der Projekt-Website unter http://deis.ie/elm/register registrieren. Anzeige TOSCA Testsuite™ Elevates Software Testing to a business discipline Öffentliche Trainings erstmals auch in Deutschland und in der Schweiz 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 Level 17.-19.11.2010: TOSCA Certified Quality Designer 01.-03.12.2010: TOSCA Certified User Advanced Level (Unterrichtssprache aller Termine: Deutsch) 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 Anforderungen im Systems und Software Engineering, wo sich Unternehmen in immer kürzeren Entwicklungszyklen immer neuen Veränderungen stellen müssen. Renommierte Referenten zeigen Ihnen in praxisnahen Case Studies Wege, Informationen und Anmeldung: www.technologieforum.com wie Sie die Chancen nutzen können, die Ihnen der kontinuierliche Wandel bietet. Sie erhalten Hilfestellungen, wie Ihr Unternehmen die zahlreichen Herausforderungen meistert, die Veränderung mit sich bringt. Der amerikanische Experte Paul Nielsen, CEO des Software Engineering Institute, berichtet als Keynote-Speaker aus seinem Wissens- und Erfahrungsschatz. Schulungen 2010 4. 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. Ort Anbieter 06.09.10 Tage Schulungstitel 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 Berlin Díaz & Hilterscheid Unternehmsberatung 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 STAND: September 2010 Datum International Software Quality Institute [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 01.11.10 3,5 ISTQB® Certified Tester, Foundation Level Wiesbaden Muth Partners 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 4 ISTQB Certified Tester, Foundation Level Berlin Díaz & Hilterscheid Unternehmsberatung 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 ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® ® 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 14.12.10 3,5 ISTQB Certified Tester, Foundation Level Wiesbaden Muth Partners GmbH ® ® ® ® ebot Alle Themen auch als Inhouse-Ang buchbar! Seminare 2010 4. Quartal (Auswahl – Weitere Termine auf www.isqi.org/nc/seminare/programm) Das iSQI fungiert hier als Vermittler. Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org Datum 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 2 Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von IBM Cognos 8 Berlin QMETHODS - Business & IT Consulting GmbH 27.09.10 2 Safety Norm IEC 61508 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-Tooltag) 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 Effiziente Testautomatisierung mit TTCN-3 – Grundlagen und Anwendungen 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 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH 08.10.10 1 Upgrade CMMI for Services München Anywhere.24 GmbH 08.10.10 1 Lernen Sie IBM Cognos 8 BI und Planning kennen (kostenfreies Seminarangebot) 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-3 und UTP für Schnelleinsteiger Röttenbach sepp.med gmbh 2 Funktionale Sicherheit von softwarebestimmten Systemen / Sicherheitsrelevante Automotive Software Kornwestheim KUGLER MAAG CIE 13.10.10 Dauer International Software Quality Institute ® ® ® ® ® ® ® International Software Quality Institute 13.10.10 3 TOSCA Testsuite™ Certified User Foundation Level Wien TRICENTIS Technology & Consulting GmbH 18.10.10 5 Praktische Softwarearchitektur Hamburg oose Innovative Informatik 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 25.10.10 3 SEI autorisiertes CMMI -DEV Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE 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- und Performancetest auf Basis von HP LoadRunner 9.5 Berlin QMETHODS - Business & IT Consulting GmbH 28.10.10 1 Services Supplement for CMMI® V1.2 Kornwestheim KUGLER MAAG CIE 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 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag) Hamburg oose Innovative Informatik GmbH 08.11.10 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Zertifizierung) Hamburg oose Innovative Informatik 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 12.11.10 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik 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 2 Service Desk und Change Request Management auf Basis des SAP Solution Manager 7.0 Berlin QMETHODS - Business & IT Consulting GmbH 29.11.10 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag) Hamburg oose Innovative Informatik GmbH 29.11.10 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Zertifizierung) Hamburg oose Innovative Informatik GmbH 29.11.10 4 Java für fortgeschrittene Anwendungsentwickler Hamburg oose Innovative Informatik GmbH 01.12.10 2 Effiziente Testautomatisierung mit TTCN-3 – Grundlagen und Anwendungen 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 03.12.10 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH 06.12.10 5 Praktische Softwarearchitektur Hamburg oose Innovative Informatik 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 13.12.10 3 SEI autorisiertes CMMI -DEV Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE 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 2 Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von IBM Cognos 8 Berlin QMETHODS - Business & IT Consulting GmbH 16.12.10 1 Services Supplement for CMMI® V1.2 Kornwestheim KUGLER MAAG CIE 20.12.10 3 Einführung in CMMI® for Services (3-Tage-Kurs) München Anywhere.24 GmbH ® ® ® ® ebot buchbar! Alle Themen auch als Inhouse-Ang Irrtümer, Termin- und Preisänderungen vorbehalten. Es gelten die allgemeinen Geschäfts- und Preisbedingungen des jeweiligen Veranstalters. 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 Am Weichselgarten 19 91058 Erlangen David-Gilly-Straße 1 14469 Potsdam Ansprechpartner One Stop Agency Services: Franziska Böckenkamp Tel +49 9131 91910-0 Fax +49 9131 91910-10 Tel +49 331 231810-0 Fax +49 331 231810-10 E-Mail: [email protected] Tel +49 331 231810-40 STAND: September 2010 [Fortsetzung Seminare 2010] 25 Ausgabe 16 | September 2010 Advertorial Wenn Ihr Leben davon abhängt, dass Software einwandfrei funktioniert Thomas Wolf, Head of Division Quality & Compliance, EXCO GmbH Stellen Sie sich vor, Sie kaufen in einer Apotheke ein kleines Messgerät zur Bestimmung Ihres Blutzuckers. 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önThomas Wolf nen. Was erwarten Sie aber von der Qualität des Gerätes? Sicher doch, dass es Ihre Blutzuckerwerte genau bestimmt, dass das Ergebnis schnell angezeigt 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önnen… Also eine hohe Qualität, die sichergestellt sein muss. Sind Sie von Beruf Software-Tester, erkennen Sie, dass es einige 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 InsulinDosis zu gering oder zu hoch wäre? Eine Rückrufaktion möchte keiner der Hersteller medizintechnischer Geräte Dass 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 wurden. Weitere 101 Rückrufe lassen sich allgemein dem Bereich Elektrik/ Programmierbare Elektronik zuordnen. Ein besonders hohes Risiko für das Leben der Patienten stellt ein Softwarefehler dar, bei dem durch einen plötzlichen Shutdown 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 Sprachumstellung, aber auch diese führten zu Rückrufen, die dem Hersteller 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 unterschiedlichste Maßnahmen und eben auch durch professionelles Testen unter allen Umständen vermeiden möchten. Mit risikobasiertem Testen zur erfolgreichen Markteinführung Im obigen Beispiel des Blutzuckermessgerätes wurde dies durch einen risikobasierten Ansatz realisiert, der erst jede spezifizierte Anforderung bewertet und dann eine dazugehö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 CSVvalidiert. Das Projekt-Team bestand aus sieben bis acht Software-Testerinnen und –Testern unseres Unternehmens sowie ein bis vier Testern von Seiten des Kunden. Alle Tester waren selbstverständlich mindestens als Certified Tester Foundation Level zertifiziert und hatten langjährige Erfahrung im Bereich 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 risikobasierten Testen medizintechnischer Geräte, der entsprechend den Anforderungen der jeweiligen Pharmaunternehmen auf deren Bedürfnisse und konkrete Projektsituationen angepasst wird. Unsere Projekterfahrungen und unser Spezialwissen in der Medizintechnik geben wir in unseren Certified Tester Schulungen an Sie weiter. Nächste ISTQB® CTFL Schulung: 20.-23.09.2010. Infos und Anmeldung unter www.exco.de. Blutzuckermessgeraete Abbildung 1: Testaufbau DAB Tuner Advertorial Im Fokus Ausgabe 16 | September 2010 26 Agilität und Verteilte Entwicklung – Ein Erfahrungsbericht Michael Sperber 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 dagegen 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 verschiedene Zeitzonen dazu, d.h. die in einem 24-Stunden-Zeitraum für gemeinsame Besprechungen effektiv verfügbare Zeit schrumpft erheblich. Unterschiedliche Feiertage in verschiedenen Ländern reduzieren diese Zeit weiterhin. Sprachbarrieren, kulturelle Unterschiede und unterschiedliche Ausbildung wirken weiterhin erschwerend. Auch wer sich mehrfach rückversichert, dass das Gesagte auch als das Gemeinte verstanden wurde, wird nicht gefeit sein gegen Mißverständnisse. Agilität oder Verteilte Entwicklung? Wenn agile und verteilte Entwicklung nicht zusammen passen, dann wäre es das einfachste, sich für eines von beiden zu entscheiden. Das macht die Sache aber nicht besser. In derungen usw. sind keine Eigenheiten agilen Vorgehens. Agile Modelle lassen uns solche Mißverständnisse und Lücken aber erheblich schneller erkennen und korrigieren! Technische Infrastruktur zur Kommunikation Heute existieren eine ganze Vielzahl von Hilfsmitteln, mit denen eine KommuMichael Sperber nikation auch über weite Entfernungen schmerzlos erfolgen kann. Auf einige sei hier eingegangen: „Meetings“, also Besprechungen mit persönlicher Anwesenheit, sind bei vielen Teilnehmern und weiter Entfernung ein ganz erheblicher Kostenfaktor. In den ersten Monaten eines anlaufenden Projekts machen diese Besprechungen 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 Telefonkonferenzen. Zeitaufwendige, unkritische Details können so vorab vorgeklärt werden. „Telefonkonferenzen“ lassen sich mit jedem gängigen Telefon leicht durchführen. Eine gute Telefonanlage oder ein entsprechender 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. Bild 1 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 Entwicklung. 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 ausgesprochene, weil ebenfalls als selbstverständlich vermutete Anfor- „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 abwechselnd bearbeitete Dokumente, etwa Spezifikationen, Testpläne, sind in der (prä-) historischen Umlaufvariante alles andere als agil. In Kombination mit Portalen oder Werkzeugen zur Zusammenarbeit über Internet (z.b. Netmeeting), sind sie aber ein hervorragendes Mittel, in einer virtuellen Besprechungsrunde gleich „Nägel mit Köpfen“ zu machen und den gefundenen Kompromiss gleich auszuformulieren. 27 Ausgabe 16 | September 2010 Kommunikation ist nicht nur ein technisches Problem Kommunikation ist aber nicht nur ein technisches Problem. An beiden Enden der Kommunikation sitzen Menschen. Dinge 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 Hintergründe unterschiedlich interpretiert werden, etwa in China oder Indien. Projektmanagement 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 dauern; ist eine Phase länger als 3 Monate, ist sie meist durch Meilensteine im Abstand von nicht mehr als 3 Monaten unterteilt. Im Leitungskreis sind alle Standorte und Fachthemen repräsentiert, nicht nur die Entwicklung. Eine standardisierte Methodik wird meist nicht angewendet, wesentliches Augenmerk 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 Leitungskreis 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 Ebenen 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. Bild 2 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 vergessene empfindlich reagieren. Bildung von hierarchischen Gruppen oder Teams Die Lösung, die wir in einigen Projekten (in der Größenordnung von insgesamt 30 bis 50 Entwicklern) bereits erfolgreich praktiziert haben, besteht in der Bildung von hierarchisch gegliederten Gruppen oder Teams. Das können streng hierarchisch organisierte Einheiten sein [siehe Bild 1] oder eher gleichberechtigt kooperierende Gruppen [siehe Bild 2]. Gemeinsames Kennzeichen ist, dass die Vereinbarungen zwischen den eigenständigen Gruppen nicht-agil sind, während innerhalb einer jeden Gruppe agil gearbeitet wird. Dadurch wird der Kommunikationsaufwand reduziert, die Agilität Zusammenfassung Kommunikation ist essentiell in jeder Entwicklung, in agiler Entwicklung noch mehr, und erfordert wegen der unvermeidbaren 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 unserer Erfahrung, die Agilität mit all ihren Vorzügen zu erhalten 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. Diskutieren Sie mit uns zu diesem Thema in der Der Autor ASQF XING-Gruppe unter www.xing.com/net/asqf ! Michael Sperber ist Mitglied des Vorstands der infoteam Software AG. Er ist Fachgruppenleiter der FG Automatisierung. Im Fokus Ausgabe 16 | September 2010 28 DER MIGRATIONSTEST-PROZESS Harry M. Sneed & Richard Seidl Kurzbeschreibung: Ein Softwaremigrations-Projekt erfordert einen anderen Testansatz als ein Entwicklungsprojekt. Denn es existiert im Regelfall weder eine Anforderungsspezifikation noch ein Designmodell als Testgrundlage. Das entscheidende Testkriterium ist dann die vollständige funktionale Gleichheit von Alt- und migriertem System – und dafür müssen spezielle Methoden und Werkzeuge zum Einsatz kommen. Darüber hinaus sollte im Migrationstest schrittweise 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 Migrationsprojekten 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 Quellcode, den Datenbank-Schemata, den Definitionen des Benutzerinterfaces sowie den Systemschnittstellen gewonnen werden [3]. Abbildung 1 Die Erfahrung vergangener Projekte zeigt, dass der Zeitaufwand 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 MIGRATIONSTESTS Zeit- 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 (OnlineTransaktion, Batch-Prozess etc.) sowie jener an zu validierenden Testobjekten. Ein Testobjekt wiederum kann aus den Harry M. Sneed Richard Seidl Produktionsdaten generiert werden: In Form eines BenutzerInterfaces, einer Datei, einer Datenbank-Tabelle, einer Systemschnittstelle etc. So gelangt man zu einer Rohschätzung für das aktuelle Migrationstest-Projekt. Diese Schätzung kann z.B. mittels Produkttyp oder des Testwiederholungsfaktors verfeinert werden [4]. Das Ergebnis der Testplanung ist ein Testkonzept gemäß ANSI/IEEE-Standard 829. In diesem sollte besonderes Augenmerk auf die Testziele und die Testendekriterien sowie deren Messung gelegt werden. Denn nur wenn diesen beiden 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 Testobjekte erfolgen. [5]. DAS DESIGN DES MIGRATIONSTESTS Um einen Migrationstest zu designen, muss man berücksichtigen, was (Testfälle und Testobjekte) und wie (Testvorgehen) 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 Datenelementen, die jedes Datenobjekt besitzt, von besonderer Bedeutung. Dazu zählen z.B. Felder und Spalten sowie deren Wertebereiche. DIE GEWINNUNG VON TESTDATEN FÜR EIN MIGRATIONSPROJEKT In einem Migrationsprojekt gewinnt man die Testdaten am besten direkt aus dem Produktionssystem, indem man einen Teil der Produktionsdaten abzieht (und anonymisiert). Im Testdesign sollte man bereits einzelne Transaktionen, Ereignisse und Batchläufe mit repräsentativem Charakter identifiziert haben. Vor jedem Test müssen Abbildungen des Benutzer-Bedienfeldes, der Eingabedateien und des Datenbankinhaltes ar- 29 Ausgabe 16 | September 2010 chiviert werden. In der gleichen Form müssen nach jedem Test die neuen Abbildungen derselben Objekte sowie zusä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 MIGRATIONSTESTS Etwa 60% bis 80% des Gesamtaufwandes werden in Migrationsprojekten 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. mittels Automatisierungswerkzeugen) Messfühler vor Teststart in z.B. jedem Zweig oder zumindest in jeder Methode platziert 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 MIGRATIONSTESTS Im sechsten Schritt werden die Ergebnisse des Migrationstests evaluiert, um festzustellen, ob das migrierte System die Erwartungen erfüllt: Nämlich dieselbe Leistung (inkl. Performance), wie das Altsystem zu erbringen. Zu Validierungszwecken werden die Bildschirminhalte, Schnittstellendaten und Datenbank-Tabellen der Tests aus beiden Systemen automatisch miteinander verglichen. Weichen die Formate voneinander ab, muss zugunsten einer Vergleichbarkeit eine Konvertierung in ein einheitliches Format 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 MIGRATIONSTEST Die vor der Testausführung automatisch im Code eingepflanzten Messfühler oder Verfolgungspunkte werden während 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 Testtransaktion 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 Projektmanagement Systems sind die (Transformations-) Fehler allerdings subtilerer Natur: Nachkommastellen gehen verloren, Datensätze werden zerstört, Daten haben sich an einen anderen Ort verlagert usw. Abbildung 2 Die einzige Möglichkeit zur Aufdeckung solcher Fehler ist es, alle Daten zu vergleichen; kombiniert mit einer Abdeckung des kompletten Programmcodes. Jede Anweisung muss getestet werden – das bedeutet, dass eine wiederholte Durchfü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 vorausgesagten Fehler zu messen. Mit diesen Informationen kann man feststellen, wann der Test beendet werden kann (Abbildung 3). Abbildung 3 Eine ausführliche Version dieses Fachbeitrages sowie das vollständige Literaturverzeichnis finden Sie unter www.asqf.de/publikationen Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Die Autoren 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. Im Fokus Ausgabe 16 | September 2010 30 Wie man agiles Vorgehen nach Scrum mit dem V-Modell XT kombiniert – ein pragmatischer Ansatz für prozessbasiertes Projektmanagement Ursula Meseberg Die Integration von agilen und schwergewichtigen Prozessen zur Systementwicklung ist längst kein „methodisches“ Tabu mehr. Mit der Verbreitung von Scrum, dem derzeit wohl populärsten agilen Projektmanagementprozess, sehen sich immer mehr Unternehmen mit der Frage konfrontiert: Was kann man als Auftragnehmer Ursula Meseberg tun, wenn man einem Auftraggeber 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 Projektsteuerungsmechanismen beider Prozesse. Projekte mit dem V-Modell XT steuern Das V-Modell XT kann durch seinen modularen Aufbau aus Vorgehensbausteinen an unterschiedliche Projektsituationen angepasst werden. Die Vorgehensbausteine definieren, 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 Entscheidungspunkte – 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 Auftragnehmerprojekte 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 steuern Ein Scrum-Projekt gliedert sich in gleich lange Sprints (Iterationen). „Motor“ eines Projekts ist das Product Backlog, 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. Innerhalb 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 Vorgaben des V-Modell XT, die auf das Erreichen von Entscheidungspunkten zielen, liegen auf einer Makro-Management-Ebene. Der Scrum-Ablauf, der auf der Realisierung Bild 2: Ausschnitt aus der neuen Projektdurchführungsstrategie für das V-Modell XT mit Scrum 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 Inkrementelle Systementwicklung vereinfacht (Bild 2). Bild 1: Ausschnitt aus der Projektdurchführungsstrategie Inkrementelle Systementwicklung Die Entscheidungspunkte werden bis einschließlich Projekt beauftragt übernommen. Danach folgt der Entscheidungspunkt Release geplant. Er entspricht dem ursprünglichen Entscheidungspunkt Iteration geplant, wurde aber umbenannt, um Verwirrung zwischen den verschiedenen Iterationsbegriffen in Scrum und im V-Modell XT zu ver- 31 Projektmanagement Ausgabe 16 | September 2010 meiden. Der gesamte Zyklus bis zur Lieferung an den Auftraggeber 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 Auftraggeber/Auftragnehmer-Schnittstelle nicht beeinträchtigt wird. Die vier dazwischen liegenden Meilensteine von System entworfen bis System integriert werden zu einem Entscheidungspunkt Sprint abgeschlossen zusammengefasst, der jeweils ein Sprint-Ende markiert. Auf den Punkt gebracht Die so entstandene integrierte Lösung bietet dem Auftraggeber als Erbschaft beider Prozesse erheblichen Spielraum, 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. Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Die Autorin 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. Anzeige online training ISTQB® Certified Tester Foundation Level (englisch & deutsch) ISTQB® Certified Tester Advanced Level Test Manager (englisch) Unsere Firma spart bis zu 60% an Schulungskosten durch Online Training. Die gewonnenen Kenntnisse und die Einsparungen sichern die Wettbewerbsfähigkeit unseres Unternehmens. © iStockphoto/Yuri_Arcurs www.te-trainings-shop.com Advertorial Ausgabe 16 | September 2010 32 Last- und Performancetests für Jedermann Matthias Zieger Schwache Anwendungsleistung kostet Unternehmen jedes Jahr Millionenbeträge und mindert deren Ansehen. Die Gründe hierfür sind offensichtlich: Kunden können auf die erforderlichen Websites nicht zugreifen oder Kaufvorgänge für die gewünschten Produkte nicht abschließen, da die Anwendungen entweder Matthias Zieger überhaupt nicht oder nur sehr langsam reagieren. Und das sind nur die Schwierigkeiten, die bei Webanwendungen auftreten – interne Unternehmensanwendungen 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 Anwendungsperformance selbst unter anspruchsvollsten Bedingungen, damit Ihre Anwendungen in jeder Situation erwartungsgemäß 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ührung der Belastungs- und Stresstests erforderlich waren. beispielsweise komplexe Gültigkeitsregeln hinzufügen müssen, die nicht von den unmittelbar verfügbaren Regeln 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 Benutzeroberfläche auf Web Services zu, nun können Sie die Leistung dieser Dienste unabhängig von den Client-Anwendungen testen, um deren Leistungsfähigkeit sicherzustellen. 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 Lasten sehr effizient einsetzen. ERSTELLEN VON LASTTESTS 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 Datenquellen gebunden werden, um datengetriebene Tests zu implementieren. Zusätzlich zu all diesen Features sind Last- und Stresstests außerdem erweiterbar – wenn Sie 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 Netzwerkbandbreiten 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, Bedenkzeit zwischen den Testdurchläufen berücksichtigen und festlegen, von welchen Computern Leistungsindikato- Abbildung 1 – Ausgabe eines Last- und Stresstests. 33 Ausgabe 16 | September 2010 Advertorial Diagrammansicht des Load Test Analyzers gibt Ihnen die Möglichkeit, Ihre Leistungsergebnisse zusammen mit den Aktivitäten und Konditionen auf den Servern zu analysieren, 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 Abbildung 2 – Angeben eines Testmixes anhand von angenommenen Benutzerszenarien. 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 speziell von Ihnen benötigte Informationen zu erfassen. Durch diese Datenkollektoren ist es beispielsweise möglich, benutzerdefinierte Anwendungsprotokolle, den Netzwerkverkehr und so gut wie alle weiteren benötigten Informationen zusammenstellen. Zusätzlich zu all diesen Optionen – viel zu viele, um sie alle hier aufzulisten – können Sie Ihre Testumgebung quasi uneingeschränkt skalieren. Die Lasttest-Controller und -Agenten können echte Enterprise-Szenarien mit Zehntausenden von Benutzern mit einem geringeren Kostenaufwand 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 Auswertung der Testergebnisse nicht besonders nützlich. Die Sobald Sie ein Problem erkannt haben, muss dieses auch beseitigt werden können – zu diesem Zweck wird ein Profiler mitgeliefert. Dieser gibt Ihnen die Möglichkeit, sowohl Ihren eigenen als auch fremden Code zu untersuchen, um Engpässe bis auf Methodenebene festzustellen. Nachdem Abbildung 4 – Detailanalyse einer Funktion. Sie ein Performance-Problem identifiziert haben, können Sie den Profiler einsetzen, um detaillierte Informationen zu allen Methodenaufrufen während der Testsitzung aufzuzeichnen (Abbildung 4). So kann der langsamste Ausführungspfad in Ihrem Code schnell ermittelt werden. EINFACHES ERSTELLEN GROßER DATENSÄTZE MITHILFE DER DATENGENERIERUNG Ein bei Last- und Stresstests häufig übersehener Gesichtspunkt betrifft die Mengen der Testdaten in den Datenbanken. 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 3 – Zusammenfassung der Lasttestergebnisse. Advertorial Advertorial Abbildung 5 – Datengenerierung. BERICHTSERSTELLUNG Visual Studio 2010 umfasst viele Berichte, mit deren Hilfe Sie Ihre Testläufe analysieren und die Ergebnisse an weitere Projektbeteiligte kommunizieren können. Außerdem können Sie rasch und unkompliziert mehrere Testläufe miteinander vergleichen, wie in Abbildung 6 veranschaulicht. In der gezeigten Ansicht können Sie die Antwortzeiten von Webseiten für einen bestimmten Vorgang analysieren – sowohl wann die Anwendung langsam reagierte als auch wie die Reaktionszeiten sich verbesserten. Ausgabe 16 | September 2010 34 Abbildung 6 – Leistungsvergleich von Webseiten. 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 vorgesehen oder ob sie geschäftskritisch sind oder nicht, können Ihnen die Belastungs- und Stresstesttools von Visual Studio dabei helfen, die Leistungsfähigkeit Ihrer Anwendungen 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 lassen, wie Sie und Ihr Unternehmen von den neuen Testwerkzeugen von Microsoft profitieren können. Weitere Informationen finden Sie auch unter www.microsoft.de/visualstudio/qs. Abbildung 7 – Transaktionszeiten. Abbildung 7 zeigt die Transaktionszeiten in einer Vergleichsansicht, d.h. die Zeiten zur Ausführung einer Abfolge von Schritten entsprechend verschiedener Benutzerszenarien. Bei den dargestellten Szenarien handelt es sich unter anderem 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 bilden eine ausgereifte, stabile und erweiterbare Plattform zur Ausführung von Leistungstests, zur Analyse der Testergebnisse und zur direkten Anwendung der Schlussfolgerungen. Aufgrund der engen Integration mit der Entwicklungsumgebung sind die Ergebnisse von Belastungs- und Stresstests unmittelbar anwendbar. Entwicklungsteams können die Daten analysieren, den Code im Detail inspi- Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Der Autor Matthias Zieger beschäftigt sich seit mehreren Jahren mit Themen rund um die Prozesse des Application Lifecycle Management, insbesondere Requirements Management und Qualitätssicherung. Dabei stehen vor allem die Integration von Organisationen, Prozessen und Werkzeugen im Fokus. Seit Januar 2009 ist er bei Microsoft in der DPE (Developer Plattform & Evangelism) tätig und betreut dort Kunden aus allen Branchen zum Thema Entwicklungsprozesse und Werkzeuge. Davor war er als Berater für ALM bei Borland, als J2EEArchitekt bei Seals.net (Tieto-Enator) und bei IBM Global Services beschäftigt. Advertorial 35 Ausgabe 16 | September 2010 Microsoft ist Mitglied im ASQF ENDLICH: nie wieder “no-repro-bugs” BEIM TESTEN! mit Lab Management 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. Machen sie schluß mit no-repro-Bugs: alle informationen, whitepaper und kostenlose Testversionen finden Sie unter www.microsoft.de/visualstudio/qs Besuchen sie uns auf der cOnQuesT cOnference On QualiTy engineering in sOfTware TechnOlOgy Zur Auswertung von IntelliTrace-Daten wird Visual Studio 2010 Ultimate benötigt. Weitere Informationen finden Sie unter www.microsoft.de/visualstudio. CONQUEST Ausgabe 16 | September 2010 36 „Software Quality“ in Dresden noch vor dem Nationalen IT-Gipfel Die Bundesregierung hält Dresden für den richtigen Ort, um im Dezember auf dem Nationalen IT-Gipfel 2010 über aktuelle Themen rund um die digitale Gesellschaft zu debattieren. Die CONQUEST 2010 ist schon vorher da und alle ASQFMitglieder 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 Software Technology) zu einem intellektuellen, praxisnahen, kreativen, zukunftsweisenden, trendsaufspürenden, austauschgeprägten Miteinander der Software-Qualitäts-Verfechter. K OS K O S T E N F R EIE S CONQ für A tick et CONQUEST-Tages er für ASQF-Mitglied 20 – 22 September 2010, Dresden, Germany MARITIM Hotel & International Congress Center 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. 1 WANN? 20. bis 22. September WO? Maritim Hotel & International Congress Center, Dresden. JETZT ONLINE REGISTRIEREN! www.conquest-conference.org/tickets-registration Anzeige Als Sponsor der MedConf freuen wir uns über Ihren Besuch: Forschung und Entwicklung Modellierung, .mzT und Generierung Besuchen Sie unseren Stand und sehen Sie: Welche Vorteile der modellzentrierte Test und die Testfallgenerierung mit .getmore bieten Die Validierung eines Dentalgeräts mittels .mzT, .getmore und 4CSmeditec Integration der Testfallgenerierung in ALM-Systeme Für weitere Informationen besuchen Sie bitte unsere Homepage: www.seppmed.de Qualitätssicherung Prozess- und Qualitätsmanagement Systemintegration Beratung und Schulung Beratung Realisierung Innovation 37 Medizintechnik Ausgabe 16 | September 2010 Der Software-Lebenszyklus für medizinische Geräte nach IEC 62304 in der Praxis Birgit Stehlik R EIE S S T E NFMit dem steigenden Anteil der durch Software realisier- estick et ten Funktionalität in medizinischen Geräten wird es immer QUEST-Tag schwieriger, er ed die Sicherheit dieser Geräte nachzuweisen. Um gli ASQF-Mitder 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 SoftwareLebenszyklus 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 Prozesse Software-Risikomanagement, Software-Konfigurationsmanagement und Software-Problemlösung. Eine wesentliche Anforderung aus der IEC 62304 ist die Nach- Prozessleitfaden beinhaltet. Dem Projektmanager und dem Risikomanager stehen Tools und Datenbankabfragen für die Auswertung und das Projektcontrolling zur Verfügung. Es können damit beispielsweise Informationen über die Anzahl von gemeldeten oder gelösten Fehlern abgerufen werden. Die Anforderungen aus Spezifikations- und ArchiBirgit Stehlik 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 werden. Die risikoreduzierende Maßnahme wird als Anforderung ebenfalls im TFS hinterlegt. Ein Testfall beweist die Umsetzung der Anforderung im Quellcode. Die Nachverfolgbarkeit wird mit Hilfe eines Tools iTrace ausgewertet und als TraceMatrix angezeigt. Abb. 1: Software-Lebenszyklus nach IEC 62304 verfolgbarkeit zwischen System-Anforderungen, SoftwareAnforderungen, Software-System-Test und der in der Software implementierten risikoreduzierenden Maßnahmen. Aus diesem Grund muss ein vollständiger Entwicklungsprozesses für medizinische Software auch den Produkt-Risikomanagementprozess beinhalten. Damit diese Prozesse effizient und ergebnisorientiert gelebt werden und den Softwareentwickler 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 Ergebnisse im Verlauf eines Projektes zentral verfolgt und koordiniert werden können. Für die Softwareentwickler ist damit eine komplette Softwareproduktionsumgebung verfügbar, welche Quellcode- und Versionsverwaltung, Testautomatisierung sowie eine integrierte Kooperationsumgebung mit Dokumentenmanagement, Kommunikationsplattform und Abb. 2: Nachverfolgbarkeit von Risiken und Anforderungen mit dem TFS und dem iTrace-Tool Mit diesem Entwicklungsprozess ist es gelungen, das Projektmanagement 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 dargestellte Prozesse die Effizienz deutlich steigern und zudem den Nachweis gegenüber benannten Stellen deutlich erleichtern. Die Autorin Birgit Stehlik arbeitet bei der infoteam Software AG als Projektleitern im Bereich der Software- und Applikationsentwicklung für medizinische Geräte und für die Laborautomatisierung. Peter Löw, Roland Pabst, Erwin Petry Funktionale Sicherheit in der Praxis Anwendung von DIN EN 61508 und ISO/DIS 26262bei der Entwicklung von Serienprodukten Softwareentwicklung & Projektmanagement 2010, 365 Seiten, Festeinband E 49,90 (D) ISBN 978-3-89864-570-6 Jorge Marx Gómez, Susanne Strahringer, Frank Teuteberg (Hrsg.) Green Computing & Sustainability HMD - Praxis der Wirtschaftsinformatik Heft 274 NEU 2010, 128 Seiten, Broschur E 24,00 (D) ISBN 978-3-89864-674-1 Niklas Spitczok von Brisinski, Guy Vollmer Pragmatisches IT-Projektmanagement Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen NEU 2010, 288 Seiten, Festeinband E 39,90 (D) ISBN 978-3-89864-651-2 NEU BESTSELLER IN DER 4. AUFLAGE Josephine Hofmann (Hrsg.) IT-basiertes Innovationsmanagement HMD - Praxis der Wirtschaftsinformatik Heft 273 2010, 128 Seiten, Broschur E 24,00 (D) ISBN 978-3-89864-673-4 Andreas Spillner, Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard 4., überarb. und akt. Auflage 2010, 308 Seiten, Festeinband E 39,90 (D) ISBN 978-3-89864-642-0 VORS C H AU Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf Basiswissen Medizinische Software Aus- und Weiterbildung zum Certified Professional for Medical Software s.html ebook echer/ ? -Books rt an E kt.de/bu ie s s e r n pu Inte www.d dpunkt.verlag GmbH · Ringstraße 19 B · D-69115 Heidelberg fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99 e-mail: [email protected] · www.dpunkt.de 4. Quartal 2010, ca. 250 Seiten, Festeinband ca. E 44,90 (D) ISBN 978-3-89864-688-8 39 Medizintechnik Ausgabe 16 | September 2010 Medizinische Software agil entwickeln Beispiel: Gebrauchstauglichkeit Michael Engler Medizinische Software agil entwickeln Mit der Änderung der Medizinprodukte-Richtlinie hat der Gesetzgeber klargestellt, dass Software ein eigenständiges 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 iterativinkrementell 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 VModell orientierten Prozess ist es dann meist kostspielig, Änderungen 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 orientieren. 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 Entwicklung, simple Architekturen und die Detaillierung von Anforderungen 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 Agile Vorgehensweise in diesem Zusammenhang oft verwendet. In der SoftwareEntwicklung für Medizinprodukte wird jedoch häufig ein Prozess 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: Gebrauchstauglichkeit Am Beispiel der Gebrauchstauglichkeit können die Vorteile einer stark iterativen Entwicklung gut gezeigt werden. Usability Engineering geht davon aus, dass nach der Erhebung von Daten mit und über die Nutzer ein Interaktions- und ein grafisches Design für eine Software erstellt werden. Insbesondere das Interaktionsdesign wird mithilfe von Nutzertests möglichst vor der Implementierung überprüft. In einem Vorgehen entsprechend dem VModell müssen die größten Teile des Interaktionsdesign idealerweise vor Beginn der Michael Engler Designphase fertig gestellt sein. Am Ende der Implementierung wird die Software dann anhand von Nutzertests validiert. Dies erschwert das Vorgehen der Designer, da sie die Software erst nach Abschluss der Implementierung testen können. Mit agilem Vorgehen hingegen ist es möglich, die bereits fertige 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 ScrumTeam auf zwei Ebenen vor: zum einen auf der Entwicklungsebene 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ährenddessen 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 implementieren die Entwickler die Funktionalität für das im Zyklus 1 entwickelte Design. Die Usability-Experten führen im Zyklus 2 Nutzertests mit der in Zyklus 1 entwickelten Funktionalitä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 vorzunehmen. 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 Gebrauchstauglichkeit zeigt, dass eine enge Integration von Usability Engineering in ein agiles Vorgehen potenziell große Vorteile birgt. Der Autor 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. Im Fokus Ausgabe 16 | September 2010 40 Dank RE für den Weltmarkt entwickeln - trotz Normenvielfalt Hajo Hoffmann Der Markt für medizinische Geräte ist hochregulativ. Das ist angesichts der potenziellen Gefahr für Patienten und Bedienungspersonal 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, Grenzwerte, Qualitätssicherungsprozesse, Testverfahren, usw. halten müssen. Für die Hersteller bedeutet dies, sich bezüglich geltender Normen stets auf dem Laufenden halten zu müssen 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 internationalen Markt abgesetzt werden sollen. Die Normen unterscheiden 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, marktspezifischen Produktvarianten begegnen, sondern die Geräte möglichst universal entwickeln möchte, heißt dies, die sich aus dieser heterogenen Normen- und Verfahrensvielfalt ergebenden Anforderungen übersichtlich zu verwalten. Dies ist keine leichte Aufgabe: Es gelten oft viele verschiedene, teils übergreifende, teils für spezifische 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 ermittelt 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, inwiefern eine Weiterentwicklung auch Anpassungen an die aktuellen Anforderungen enthalten muss. Der Problemraum ist damit noch nicht vollständig beschrieben, denn es steht ein Paradigmenwechsel in der Normenwelt an: Im europäischen Raum wird ab 2012 die dritte Version der Normenreihe IEC-60601 gültig. Mit dieser enthalten diese Produktnormen eine Vielzahl von Prozessanforderun- gen. Bei einer Zertifizierung werden dann nicht nur Produkte, sondern auch relevante Prozesse überprüft. Wann dieser Paradigmenwechsel auf den anderen Märkten ansteht, ist nur eine Frage der Zeit. Abhilfe kann eines methodisches, toolunabhängiges Konzept schaffen, das es Herstellern von medizinischen Geräten erlaubt, die Hajo Hoffmann aus den Normen abgeleiteten Anforderungen zu verwalten, Produktkonfigurationen und varianten anzulegen, Auswirkungen auf Entwicklungsprozesse zu analysieren und sich auf die Zertifizierungen vorzubereiten. Um Auswirkungsanalysen zu ermöglichen, muss dabei viel Wert auf eine durchgängige Verfolgbarkeit der Anforderungen von der Norm bis zu den Testfällen gelegt werden. 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 besser 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ässigen Gerätehersteller ein Vortrag zu diesem Thema gehalten. Vielleicht gibt er Ihnen die ersten Denkanstöße, wie Sie dank Requirements Engineering den Weltmarkt erobern können – trotz der erdrückenden Normenvielfalt. Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf ! Der Autor Hajo Hoffmann ist Berater der SOPHIST GmbH und ist spezialisiert auf Produktlinienspezifikation in der auch sehr regulativen Automotive-Branche. Vor seiner Zeit als SOPHIST war er an der Entwicklung von ComputertomographieSoftware in Forchheim beteiligt. BOOK AND EXAM GET 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® Certified Professional for Project Management + Vorbereitungsbuch (deutsch) 300 € – International Software Quality Institute Mitglieder Wetten, dass?!: Mit dem ASQF FrankenExpress zur CONQUEST ASQF-Mitglieder erhalten zur CONQUEST 2010 in Dresden ein kostenfreies Tages-Ticket für den 21. oder 22. September. Doch damit nicht genug. Für die Heimatregion des ASQF, Franken, ist ASQF Geschäftsführer Stephan Goericke eine spezielle Wette eingegangen: Schafft es ASQF-Gründungsmitglied 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. Ausgabe 16 | September 2010 42 6. Berlin-Brandenburger Golfers-Cup Das Van der Valk Hotel Berliner Ring und der ASQF laden ein zum 6. Berlin-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-Golferball“ statt. Alle Teilnehmer und die Organisatoren unterstützen einen wohltä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, Sopranistin, 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 Anzeige Konferenz für Software Qualität 24.–26. Mai 2011 | Düsseldorf, Deutschland Call for Papers Einsendeschluss September 2010 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 findet in deutscher Sprache statt. www.iqnite-conferences.com/de 43 Quiz Ausgabe 16 | September 2010 SUDOKU 5 9 2 5 6 6 7 5 4 3 7 8 4 2 7 8 3 8 9 2 4 6 1 Buchstaben: 1 = N, 2 = W, 3 = S, 4 = I, 5 = U, 6 = H, 7 = C, 8 = G, 9 = Q Lösungswort: __ __ __ __ __ __ __ Nachverfolgbarkeit ist eine wesentliche Anforderung zur Lösung des Sudoku. Nachverfolgbarkeit ist auch eine wesentliche Anforderung aus der IEC 62304 – der Norm für den Softwarelebenszyklus. Das Buch „Basiswissen Medizinische Software. Aus- und Weiterbildung zum Certified Professional for Medical Software“, Christian Johner, Matthias HölzerKlüpfel, Sven Wittorf, steht ab Oktober im dpunkt.verlag zur Verfügung. Es deckt das komplette Curriculum der Ausbildung zum „Certified Professional for Medical Software“ ab und ergänzt dieses durch ein durchgängiges Beispiel sowie Übungsaufgaben. Einen Schwerpunkt bildet der Inhalt der Norm IEC 62304 zum Softwarelebenszyklus, deren Forderungen mit gängigen Softwareentwicklungsprozessen und praktischen Software-Engineering-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 ausgeschlossen. Teilnehmer erklären sich mit der Veröffentlichung Ihres Namens in der Folgeausgabe einverstanden. Gewinner SQ-Magazin Nr. 15 Die Redaktion bedankt sich an dieser Stelle bei den fünf heldenhaften „FehlerdrachenBezwingern“ und gratuliert recht herzlich. Wir danken für die zahlreichen Zuschriften und wünschen viel Spaß mit den „Geschichten vom SCRUM. Von Sprints, Retrospektiven 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. 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 Kundenanforderungen 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] empfiehlt „dilbert“ zur leichteren Alltagsbewältigung Impressum Herausgeber ASQF e.V. Am Weichselgarten 19, 91058 Erlangen Tel +49 9131 91910-0 Fax +49 9131 91910-10 Fachgruppentermine September - November 2010 SEPTEMBER 2010 KW Fotos: ASQF e.V. und iSQI GmbH Titelbild: © Jochen K – Fotolia.com S. 25 – iStockphoto.com © Bochkarev Photography S. 40 – iStockphoto © TommL S.42 – mit freundlicher Genehmigung Eagles Charity Golf Club e.V. So KW 1 2 3 4 5 39 Mo Di Mi Do NOVEMBER 2010 Fr Sa So KW Mo Di Mi Do Fr Sa 1 2 3 44 1 2 3 4 5 6 So 7 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 FG Software-Test, Berlin-Brandenburg | 06.09.2010, Berlin GUI-Testen mit Open-Source-Frameworks Dr.-Ing. Dehla Sokenou (GEBIT Solutions GmbH) FG Maturity Models, Franken | 08.09.2010 Vorankündigung N.N. FG Automotive, Franken | 14.09.2010, Röttenbach RiskCAT 26262 – Die neue Norm für Funktionale Sicherheit in der Fahrzeugelektronik und deren Anwendung in der Praxis Dr. Günter Glöe (CATS Software Tools GmbH) FG Softwaretest, Bayern Süd | 14.09.2010, Unterschleißheim Managen von virtuellen Testumgebungen Matthias Zieger, Microsoft Deutschland GmbH FG Medizintechnik, Franken – 1. Medical Device Day | 16.09.2010, Erlangen diverse Komplexität beherrschen FG Software Test, Schwaben | 22.09.2010, Ulm Testmethodik für Embedded Software in der Automobil- und Medizintechnik Dr. Thomas Zurawka (SYSTECS Informationssysteme GmbH) FG Safety, Rhein-Main | 23.09.2010, Wiesbaden IEC 61508 Konzeptphase in der Praxis Dipl. Ing. Michael Lange und Vera Gebhardt (tecmata GmbH) FG Modellierung, Franken | 23.09.2010, N.N. Methoden zum Vergleich von Modellen einschl. Änderungsmanagement auf Modellen N.N. FG Automotive, NRW | 29.09.2010, Bochum Praxiserfahrungen mit AUTOSAR Dipl.-Ing. Arne Lenz (Delphi Deutschland GmbH) FG Software Test, Baden-Württemberg, 2. Software-Testing Day | 30.09.2010, Ludwigsburg diverse Test the best Oktober 2010 November 2010 Namentlich gekennzeichnete Beiträge müssen 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 Daten nicht an Dritte weitergegeben und ausschließlich zur internen Auswertung herangezogen werden können. Sa 8 Druckauflage: 3.000 Stück Haben Sie Anregungen zu den Inhalten des SQ-Magazins, dann schreiben Sie an: [email protected] Fr 7 Druck: te Neues, Kempen Mediadaten Gern senden wir Ihnen unsere Mediadaten zu. Richten Sie Ihre Anfrage an presse@ asqf.de. Weitergabe und Vervielfältigung, auch auszugsweise, ist unter vollständiger Angabe der Quelle erlaubt. Do 6 Alle Portraits und Grafiken mit freundlicher Genehmigung der Autoren. Internetausgabe www.asqf.de/sqmagazin OKTOBER 2010 Mi 36 September 2010 Satz/Layout: Frenkelson Werbeagentur, Potsdam www.frenkelson.de Di 35 David-Gilly-Str. 1, 14469 Potsdam Tel +49 331 231810-0 Fax +49 331 231810-10 [email protected], www.asqf.de Redaktion V.i.S.d.P.: Stephan Goericke (Geschäftsführer) Redaktion: Jana Noack, Felix Winter [email protected] Mo FG Automatisierung, Franken | 30.09.2010, Bubenreuth wird noch bekannt gegeben Dr. Hans Egermeier (Bernecker + Rainer Industrie-Elektronik GmbH) FG Projektmanagement, Franken | 06.10.2010, Bubenreuth Erfolgsfaktoren im Projektmanagement (Teil 1) – Der Mensch Sven Opitz (MenschSystem-Erfolg.de) FG Software-Test, Rhein-Main – 4. Rhein-Main Testing Day | 07.10.2010 Aus der Praxis für die Praxis diverse FG Automatisierung, Franken | 14.10.2010, Bubenreuth Vorankündigung N.N. FG Software-Test | 18.10.2010, Berlin Softwaretesting in agilen Umgebungen – Werkzeuge und Methoden Dipl.-Inf. Udo Spring, Loyal Team FG Maturity Models Franken | 19.10.2010, Erlangen SCRUM setzt CMMI um - oder denken Sie anders? Filippo Vitiello, Michael Engler (Method Park Software AG) FG Softwaretest, Sachsen | 19.10.2010, Dresden Fit mit Modellen Steffen Stundzig (itemis AG) FG Automation, Franken – 19. Automation Day | 26.10.2010, Nürnberg Automatisierung im Jahr 2015 diverse FG Software-Test, Franken | 09.11.2010, Erlangen Managed Test Services in Deutschland Dr. Andreas Reuys (Logica Deutschland GmbH) FG Modellierung, Franken | 11.11.2010, N.N. MDSD, MDA - wo stehen wir heute? Haben sich die Prophezeiungen erfüllt? Prof. Jörg Robra 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 Vorankündigung N.N. FG Maturity Models, Baden-Württemberg | 23.11.2010, Sindelfingen Joining models - to fit all needs (CMMI and Automotive SPICE) Michaela Reinhardt, Tobias Barth (MBtech Group) FG Softwaretest, Sachsen | 23.11.2010 Vorankündigung N.N.