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 – Kompaktkurs
Certified Tester Advanced Level – TESTMANAGER
Testen für Entwickler
Certified Tester Advanced Level – TEST ANALYST
Certified Professional for Requirements Engineering – Foundation Level
Certified Tester Advanced Level – TEST ANALYST
Testen für Entwickler
Certified Professional for Requirements Engineering – Foundation Level
Berlin
Berlin
Berlin
Hannover
München
Berlin
Frankfurt
Stuttgart
Berlin
München
Berlin
Berlin
Frankfurt
Berlin
Berlin
Düsseldorf/Köln
Berlin
3
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
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
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.
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
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.
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
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.
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.
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
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.
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
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)
TPI (Test Process Improvement) in a complex organization with multiple
system environments
Arjan Brands, Díaz & Hilterscheid, Germany
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)
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
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
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
.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
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
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
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
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
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
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
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:
(Unterrichtssprache: Englisch)
Wien:
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
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
13.09.10
5
ISTQB® Certified Tester, Advanced Level, Test Analyst
Dresden
13.09.10
4
Berlin
13.09.10
5
ISTQB Certified Tester, Advanced Level, Test Analyst
München
Logica Deutschland GmbH & Co. KG
13.09.10
5
München
Method Park Software AG
13.09.10
4
ISTQB Certified Tester, Foundation Level
Köln
SQS AG
13.09.10
5
Wien
SQS AG
13.09.10
4
iSQI® Certified Professional for Project Management
Köln
SQS AG
14.09.10
4
Dresden
14.09.10
4
iSAQB® Certified Professional for Software Architecture
Düsseldorf
BITPlan GmbH
14.09.10
4
Erlangen
20.09.10
5
Berlin
20.09.10
4
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
20.09.10
5
Erlangen
20.09.10
4
Stuttgart
SQS AG
20.09.10
5
Essen
SQS AG
20.09.10
5
Wien
22.09.10
3
TTCN-3 Testing and Test Control Notation
Berlin
Testing Technologies IST GmbH
27.09.10
4
Hamburg
SQS AG
27.09.10
5
Frankfurt a.M.
SQS AG
27.09.10
4
München
TESNET GROUP GMBH
27.09.10
4
Wien
OBJENTIS Software Integration GmbH
04.10.10
4
Berlin
04.10.10
4
München
04.10.10
5
ISTQB® Certified Tester, Advanced Level, Technical Test Analyst
Berlin
04.10.10
3,5
Bönnigheim (Stgt.) Muth Partners GmbH
04.10.10
4
Wien
SQS AG
04.10.10
1
Köln
SQS AG
06.10.10
5
ISTQB Certified Tester, Advanced Level, Test Manager
Wien
06.10.10
5
ISTQB Certified Tester, Advanced Level, Test Analyst (englisch)
Wien
11.10.10
5
München
11.10.10
3,5
Hamburg
Muth Partners GmbH
11.10.10
4
München
SQS AG
11.10.10
5
Hamburg
SynSpace GmbH
18.10.10
5
Hamburg
18.10.10
1
Wien
SQS AG
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
International Software Quality Institute
STAND: September 2010
Datum
[Fortsetzung Schulungen 2010]
18.10.10
1
Hamburg
SQS AG
19.10.10
3
Frankfurt a.M.
20.10.10
3
Röttenbach
sepp.med gmbh
25.10.10
5
Stuttgart
25.10.10
5
München
25.10.10
3
Hamburg
25.10.10
4
iSQI Certified Professional for Project Management
Erlangen
25.10.10
4
Berlin
SQS AG
25.10.10
5
Frankfurt a.M.
SQS AG
25.10.10
4
Frankfurt a.M.
TESNET GROUP GMBH
26.10.10
4
München
SynSpace GmbH
01.11.10
3,5
Wiesbaden
Muth Partners GmbH
02.11.10
4
München
08.11.10
4
Dresden
08.11.10
5
Berlin
08.11.10
4
Wien
SQS AG
08.11.10
4
Hannover
SQS AG
08.11.10
4
iSQI Certified Professional for Project Management
Frankfurt a.M.
SQS AG
08.11.10
4
München
TESNET GROUP GMBH
09.11.10
4
Düsseldorf
BITPlan GmbH
10.11.10
5
ISTQB® Certified Tester, Advanced Level, Test Analyst
Wien
15.11.10
4
Berlin
15.11.10
5
ECQA® Certified Software Process Improvement Manager
Erlangen
ISCN Ltd.
15.11.10
5
ECQA Certified Software Process Improvement Manager
Erlangen
15.11.10
4
Frankfurt a.M.
SQS AG
22.11.10
5
iNTACS™ Certified ISO/IEC 15504 Competent Assessor
Hamburg
SynSpace GmbH
22.11.10
5
Frankfurt a.M.
22.11.10
5
ECQA Certified Innovation Manager
Erlangen
ISCN Ltd.
22.11.10
5
Köln
22.11.10
4
Frankfurt a.M.
22.11.10
5
München
22.11.10
5
ECQA® Certified Innovation Manager
Erlangen
22.11.10
3,5
Hannover
Muth Partners GmbH
22.11.10
1
München
SQS AG
22.11.10
5
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
Wien
OBJENTIS Software Integration GmbH
29.11.10
4
ISTQB Certified Tester, Foundation Level (englisch)
Wien
29.11.10
5
Erlangen
29.11.10
3,5
Bochum
Muth Partners GmbH
29.11.10
4
Hamburg
oose Innovative Informatik GmbH
29.11.10
4
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
Frankfurt a.M.
SynSpace GmbH
06.12.10
5
Frankfurt a.M.
06.12.10
3
München
06.12.10
4
Hamburg
06.12.10
1
Frankfurt a.M.
SQS AG
06.12.10
4
Dresden
SQS AG
06.12.10
5
Köln
SQS AG
06.12.10
4
Frankfurt a.M.
TESNET GROUP GMBH
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
®
07.12.10
3
Düsseldorf/Köln
13.12.10
5
Berlin
13.12.10
4
Hamburg
13.12.10
1
Köln
SQS AG
13.12.10
4
München
SQS AG
13.12.10
5
Hamburg
SQS AG
14.12.10
3,5
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
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
13.09.10
5
Praktische Softwarearchitektur
Hamburg
13.09.10
4
Java für fortgeschrittene Anwendungsentwickler
Hamburg
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
20.09.10
5
Kommunikation & Moderationstechniken
Hamburg
20.09.10
5
Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag)
Hamburg
22.09.10
3
Einführung in das Capability Maturity Model Integration (CMMI )
Berlin
23.09.10
2
Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von
IBM Cognos 8
Berlin
27.09.10
2
Safety Norm IEC 61508
Erlangen
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
04.10.10
5
Agiles Software-Projektmanagement
Hamburg
04.10.10
5
Hamburg
04.10.10
5
Objektorientierte Analyse und Design mit UML (inkl. UML-Zertifizierung)
Hamburg
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
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
Hamburg
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
®
®
®
®
®
®
®
13.10.10
3
TOSCA Testsuite™ Certified User Foundation Level
Wien
TRICENTIS Technology & Consulting GmbH
18.10.10
5
Hamburg
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
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
Düsseldorf
28.10.10
2
Last- und Performancetest auf Basis von HP LoadRunner 9.5
Berlin
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
08.11.10
5
Hamburg
08.11.10
5
Hamburg
08.11.10
3
Einführung in das Capability Maturity Model (CMMI®)
Zürich
Anywhere.24 GmbH
10.11.10
3
Zürich
12.11.10
1
Hamburg
15.11.10
5
Agiles Software-Projektmanagement
Hamburg
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
Warschau
KUGLER MAAG CIE
17.11.10
3
TOSCA Testsuite™ Certified Quality Designer
Wien
22.11.10
3
Testmanagement - effizient und einfach
München
GQ-Solutions
22.11.10
5
Kommunikation & Moderationstechniken
Hamburg
22.11.10
5
Java für Anwendungsentwickler
Hamburg
25.11.10
2
Service Desk und Change Request Management auf Basis des SAP Solution
Manager 7.0
Berlin
29.11.10
5
Hamburg
29.11.10
5
Hamburg
29.11.10
4
Java für fortgeschrittene Anwendungsentwickler
Hamburg
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
02.12.10
2
Testmanagement auf Basis von HP Quality Center 10.0
Berlin
03.12.10
1
Hamburg
06.12.10
5
Hamburg
13.12.10
5
Das Analytiker-Seminar mit UML
Hamburg
13.12.10
4
Testgetriebene Softwareentwicklung
Hamburg
13.12.10
3
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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.
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-
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
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
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
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
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
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.
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
250 €
200 €**
ISTQB® CERTIFIED TESTER – TEST ANALYST AND TECHNICAL TEST ANALYST
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 €
–
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.
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
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.

Ausgabe 16 - SQ

Transcrição

Documentos relacionados

Hotel am Triller

Ausgabe 11 - SQ

Ausgabe 1 - SQ

Mercure Airport Hotel Berlin Tegel

Mercure Hotel Offenburg am Messeplatz

Bewertungsbogen Dungeon Keeper 2.p65

erfahren - Sparkasse Mecklenburg

Wir suchen Sie!

Konferenzen · Wellness Bauernbuffet Kalte

Tagungsbroschüre Hotel Vier Jahreszeiten Starnberg

Lebenslauf (Adobe Acrobat Reader PDF)

Kulturförderung in den USA, Teil 1 Was ist die Kunst