DER BEGEISTERUNGS- FAKTOR - SQ-Magazin ISEB Intermediate (deutsch) Der ISEB Intermediate Kurs ist das Bindeglied zwischen dem ISTQB Certified Tester Foun-dation Level und dem Advanced
Post on 25-Aug-2020
8 Views
Preview:
Transcript
Ausgabe 17 | Dezember 2010
Arbeitskreis Software-Qualität und -Fortbildung e.V.
Arbeitskreis Software-Qualität und -Fortbildung e.V.
... im Software-Test
... im Requirements Engineering
... im ASQF
DER BEGEISTERUNGS-
FAKTOR
ISEB Intermediate (deutsch)
Der ISEB Intermediate Kurs ist das Bindeglied zwischen dem ISTQB Certified Tester Foun-dation Level und dem Advanced Level. Er erweitert die Inhalte des Foundation Levels, ohne dass man sich bereits für eine Spezialisierung - Test Management, technisches Tes-ten oder funktionales Testen - entscheiden muss. In drei Tagen werden Reviews, risiko-basiertes Testen, Test Management und Testanalyse vertieft; zahlreiche Übungsbeispiele erlauben die direkte Anwendung des Gelernten.
Eine einstündige Prüfung mit ca. 25 szenario-basierten Fragen schließt den Kurs ab. Das „ISEB Intermediate Certificate in Software Testing“ erhält man ab 60% korrekter Ant-worten.
Voraussetzungen
Für die Zulassung zur Prüfung zum “Intermediate Certificate in Software Testing“ muss der Teilnehmer die Prüfung zum Certified Tester Foundation Level (ISEB/ISTQB) bestan-den haben UND entweder mindestens 18 Monate Erfahrung im Bereich Software Test-ing ODER den akkreditierten Trainingskurs “ISEB Intermediate” abgeschlossen haben - vorzugsweise alle drei Anforderungen.
Termine
06.12.10–08.12.10
09.02.11–11.02.11
05.04.11–07.04.11
€1600,00 plus Prüfungsgebühr €200 zzgl. MwSt.
http://training.diazhilterscheid.com
1. akkreditiertes Unternehmen
im deutschsprachigen RaumISEB Intermediate (deutsch)
Der ISEB Intermediate Kurs ist das Bindeglied zwischen dem ISTQB Certified Tester Foun-dation Level und dem Advanced Level. Er erweitert die Inhalte des Foundation Levels, ohne dass man sich bereits für eine Spezialisierung - Test Management, technisches Tes-ten oder funktionales Testen - entscheiden muss. In drei Tagen werden Reviews, risiko-basiertes Testen, Test Management und Testanalyse vertieft; zahlreiche Übungsbeispiele erlauben die direkte Anwendung des Gelernten.
Eine einstündige Prüfung mit ca. 25 szenario-basierten Fragen schließt den Kurs ab. Das „ISEB Intermediate Certificate in Software Testing“ erhält man ab 60% korrekter Ant-worten.
Voraussetzungen
Für die Zulassung zur Prüfung zum “Intermediate Certificate in Software Testing“ muss der Teilnehmer die Prüfung zum Certified Tester Foundation Level (ISEB/ISTQB) bestan-den haben UND entweder mindestens 18 Monate Erfahrung im Bereich Software Test-ing ODER den akkreditierten Trainingskurs “ISEB Intermediate” abgeschlossen haben - vorzugsweise alle drei Anforderungen.
Termine
06.12.10–08.12.10
09.02.11–11.02.11
05.04.11–07.04.11
€1600,00 plus Prüfungsgebühr €200 zzgl. MwSt.
http://training.diazhilterscheid.com
1. akkreditiertes Unternehmen
im deutschsprachigen Raum
Nach dem Modell von Kano sind Be-geisterungsfaktoren die Produktmerk-male, die man nicht kennt und erst während der Benutzung als angeneh-me und nützliche Überraschungen ent-deckt. Im Laufe der Zeit werden aus den Begeisterungsfaktoren die explizit geforderten Leistungsfaktoren und ir-gendwann werden sie als selbstver-ständliche Basisfaktoren vorausgesetzt. Dieses Modell lässt sich wunderbar auf unsere Gesellschaft anwenden, in der Politik aber auch in der Bildung. Was heute noch ein Begeisterungsfaktor ist, ist schon übermorgen ein Basisfaktor.
Frisch von der Uni oder aber die Meisterprüfung gerade abgelegt, ist unser Wissen noch ein Begeisterungsfaktor für uns selbst und den Arbeitgeber. Die Halbwertszeit dieses Spitzenwissens ist aber oftmals kurz und so gilt es, durch Strategien des lebenslangen und berufsbegleitenden Lernens, sein Wissen immer wieder zum Begeisterungsfaktor zu steigern. Auch das ist ein notwendiger Weg, um dem Fachkräftemangel entgegenzuwirken: Wir brauchen in der Schlüsselindustrie IKT nicht nur qualifizierte Fachkräf-te, sondern auch welche, die es dauerhaft bleiben. Mit der neuen IKT-Strategie „Deutschland Digital 2015“ versucht auch die deutsche Bundesregierung einen neuen Begeisterungsfaktor für die IKT zu starten. Sie setzt dabei auf Innovation vor allem durch die KMUs. Dabei un-terstreicht die Regierung den Wert regionaler Cluster, von denen starke Im-pulse auch für branchenübergreifende Innovationen ausgehen, und weist der Standardisierung und Interoperabilität im IKT-Bereich eine strategische Bedeutung zu. „Die Standardisierung ist eine Voraussetzung für die Inter-operabilität komplexer technischer Systeme. Wer Standards setzen und durchsetzen kann, verschafft sich klare Wettbewerbsvorteile.“ steht dort geschrieben. Für mich ein weiterer Beleg, dass wir mit der erfolgreichen Ar-beit des ASQF und iSQI seit nunmehr fast 15 Jahren auf dem richtigen Weg sind: Zusammen mit Ihnen setzen wir die Standards für mehr Software-Qualität und das auch in 2011. Mit den guten Wirtschaftszahlen im Gepäck und den vollen Auftragsbü-chern unterm Arm – nicht nur bei unseren Trainingsprovidern – können wir also mehr als positiv ins nächste Jahr marschieren und dann das 15-jähri-ge Jubiläum des ASQF gemeinsam feiern. Ich lade Sie ein, auch 2011 wieder mit uns für neue Begeisterungsfaktoren in der IKT-Branche zu sorgen. Mit dem aktuellen SQ-Magazin halten Sie gerade unseren nächsten Begeisterungsfaktor in der Hand. Ich wünsche Ihnen ein besinnliches und frohes Weihnachtsfest und einen guten Start in das Jahr 2011! Packen wir es an!
Ihr Stephan Goericke
Was uns antreibt
Editorial
Stephan Goericke, Geschäftsführer ASQF e.V. und iSQI GmbH
3 Ausgabe 17 | Dezember 2010
3 Editorial
4 ASQF-News- Begeisterungsfaktor I: Fachgruppe Requirements Engineering- Begeisterungsfaktor II: Die ASQF-Days
5 iSQI-News- Nächste Stufe: Advanced Level
Requirements Engineering des IREB ab 2011
- Neu im Portfolio: Die ECQA Zer-tifizierungsschemen „SPI Mana-ger“ und „E-Learning Manager“
- CALL FOR PAPERS
6 Im Fokus: Requirements Engineering6 Eine Streitschrift – eine Provoka-
tion – jenseits von Lösungen! 8 User Stories als Instrument des RE10 Traceability: Tipps zur Realisie-
rung nachvollziehbarer Anforde-rungen
12 Kolumne: Keine Innovation ohne Strategie14 Pfade zum Requirements- basierten Testen
16 Rückblick - CONQUEST 2010
22 Im Fokus: Softwaretest22 Unabhängigkeit im Testen: Nur
Marketing oder idealer Ansatz?24 Aus dem Leben eines Testberaters26 TestSPICE – SPICE für Testprozesse28 V-Modell® XT 1.3: Gut, aber wei-
tere Verbesserungen möglich
33 Fachgruppe Safety33 Echte Innovation lässt sich nicht aufhalten!
34 Mitglieder34 Boxweltmeister Sven Ottke ge-
winnt den ASQF-Wanderpokal
35 Quiz
36 Fachgruppen-Termine36 Impressum/Mediadaten
INHALT
ISEB Intermediate (deutsch)
Der ISEB Intermediate Kurs ist das Bindeglied zwischen dem ISTQB Certified Tester Foun-dation Level und dem Advanced Level. Er erweitert die Inhalte des Foundation Levels, ohne dass man sich bereits für eine Spezialisierung - Test Management, technisches Tes-ten oder funktionales Testen - entscheiden muss. In drei Tagen werden Reviews, risiko-basiertes Testen, Test Management und Testanalyse vertieft; zahlreiche Übungsbeispiele erlauben die direkte Anwendung des Gelernten.
Eine einstündige Prüfung mit ca. 25 szenario-basierten Fragen schließt den Kurs ab. Das „ISEB Intermediate Certificate in Software Testing“ erhält man ab 60% korrekter Ant-worten.
Voraussetzungen
Für die Zulassung zur Prüfung zum “Intermediate Certificate in Software Testing“ muss der Teilnehmer die Prüfung zum Certified Tester Foundation Level (ISEB/ISTQB) bestan-den haben UND entweder mindestens 18 Monate Erfahrung im Bereich Software Test-ing ODER den akkreditierten Trainingskurs “ISEB Intermediate” abgeschlossen haben - vorzugsweise alle drei Anforderungen.
Termine
06.12.10–08.12.10
09.02.11–11.02.11
05.04.11–07.04.11
€1600,00 plus Prüfungsgebühr €200 zzgl. MwSt.
http://training.diazhilterscheid.com
1. akkreditiertes Unternehmen
im deutschsprachigen Raum
Erst wenn man es selbst ausprobiert, erkennt man den Begeisterungsfak-tor, der in unseren Fachgruppen steckt. Große Begeisterung war vorhanden beim Kick-Off der neuen Fachgruppe Requirements Engineering, die am 18.10. unter Leitung von Frau Chris Rupp, SOPHIST GmbH, in Franken ge-startet ist. Über 70 Teilnehmer fanden sich zur Auftaktveranstaltung in den Räumlichkeiten der SOPHISTen in Nürnberg ein. Den begeisternden Eröff-nungsvortrag „Systemanalyse auf den Punkt gebracht“ hielt die RE-Exper-tin Chris Rupp. Fortsetzung fand die Begeisterung bei dem ebenfalls ausge-buchten Kick-Off der regionalen FG Requirements Engineering am 11.11. in Berlin/Brandenburg: Unter der Leitung von Heiko Köppen (Avenqo GmbH) fanden sich über 50 Teilnehmer in den Räumlichkeiten des Fraunhofer FO-KUS ein, um zum Thema „Anwendung von User Stories im RE - Methoden & Erfahrungen“ zu diskutieren. Der ASQF wünscht der Fachgruppe RE in Fran-ken und Berlin/Brandenburg ein gutes Gelingen, stets viele Teilnehmer und freut sich schon auf den Kick-Off der Fachgruppe RE im Stuttgarter Raum. Weitere Infos und aktuelle Termine wie immer auf www.asqf.de.
Der ASQF-Spätsommer 2010 war vollgepackt mit vier spannenden ASQF-Days. Bereits zum 19. Mal lud die Fachgruppe Automatisierung zusammen mit dem Automation Valley Nordbayern zum Automation Day ein. Mit dem Motto „Automatisierung im Jahr 2015“ lockte die Mutter aller ASQF-Days wieder 100 Teilnehmer aus Nah und Fern, um sich zusammen über die aktu-ellen Trends in der Automatisierungstechnik auszutauschen. Für die Keynote konnte Prof. Dr. Reinhart, Leiter des iwb (TUM) und Sprecher des Clusters Mechatronik und Automation, gewonnen werden, der die Auswirkungen der globalen Megatrends wie Globalisierung und demographischer Wandel auf die Automatisierungstechnik darstellte.Große Begeisterung beim Fachpublikum lösten auch die beiden Testing-Days aus. Getreu der Devise „Test the Best“ kamen über 130 Teilnehmer zum zweiten Testing Day in Baden-Württemberg. Mit insgesamt vier Fach-vorträgen und einer attraktiven Ausstellung punktete die Veranstaltung der Fachgruppe in Baden-Württemberg erneut bei ihrem Publikum. Gleiches gelang auch der regionalen Testgruppe aus Rhein-Main. Zum nunmehr 4. Rhein-Main Testing Day kamen an die 100 Teilnehmer. „Aus der Praxis für die Praxis“ lautet hier der Leitsatz des Days. Aus fachlicher Sicht stand be-sonders das Thema „Agilität“ im Vordergrund. Neu in der Reihe der ASQF-Days war der 1. Medical Device Day Franken. Gemeinsam mit dem Spitzencluster Medical Valley EMN e.V. veranstalte-te der ASQF erstmals diese ganztägige Vortragsreihe rund um das Thema
„Komplexität in der Medizintechnik“. In acht Fachvorträgen wurde darüber referiert, was Aristoteles schon zu Softwareentwicklung gesagt hätte, wie agil die Entwicklung medizinscher Software sein kann oder ob wir uns das besondere Gut Gesundheit so noch leisten können. Die nahezu hundert Teil-nehmer waren vom Angebot des ersten Medical Device Day begeistert und zeigten sich von der Vielfalt der Vorträge und der begleitenden Ausstellung beeindruckt. Der nächste Medical Device Day wurde schon für Juli 2011 in Aussicht gestellt. www.asqf.de
Begeisterungsfaktor I: Fachgruppe Requirements Engineering
Begeisterungsfaktor II: Die ASQF-Days
Partner: ASQF in Erlangen mit neuen Partnern
Seit Oktober bietet der ASQF zwei Seminar-expertinnen ein neues Zuhause. Und das nicht nur im Verein, sondern auch in den Büroräumen. Um die Auslastung der Se-minarräume in Erlangen weiter zu erhöhen, sind nun Hailka Proske und Sigrid Triebfürst mit im Erlanger Büro integriert. Neben den ASQF und iSQI-üblichen Vorträgen finden Sie in unseren Räumen nun auch Seminare im Produktmanagement und Vertrieb für die Medizintechnikbranche oder Coaching und Beratung zu Kommunikation, Selbst-management oder Führungskräfteberatung. Für ASQF-Mitglieder gilt: Es gibt Rabatte auf die Teilnahmegebühren.
Zuwachs: Neue Mitglieder
- C1 WPS Work Place Solutions GmbH, Hamburg, www.c1-wps.de- D-LABS, Potsdam, www.d-labs.com- e-velopment GmbH, Hamburg, www.e-velopment.de- Hailka Proske Training & Beratung, Erlangen, www.hailka-proske.de- KS-Consulting, Frankfurt, www.ks-consulting.biz- Loyal Team, Berlin, www.loyal-team.com- qme Software GmbH, Berlin, www.qme-software.de- Sigrid Triebfürst. medtech-semiare & coaching, Erlangen, www.sigrid-triebfuerst.de - Validas AG, München, www.validas.de
NEWS ASQF Ausgabe 17 | Dezember 2010 4
iSQI NEWS
Im ersten Quartal 2011 wird das IREB das CPRE Schulungs-und Zertifi-zierungsangebot um den Advanced Level erweitern. Zu Beginn des neuen Jahres werden dann die Module “Requirements Modeling” und “Require-ments Elicitation and Consolidation” verfügbar sein. Weitere Module des CPRE Advanced Level werden folgen. Die Lehrpläne und die Prüfungs-ordnung werden in Kürze auf der IREB-Homepage (www.certified-re.de) veröffentlicht. Seit 2007 haben über 5.000 Personen die Foundation Level Prüfung welt-weit abgelegt. Auch in diesem Jahr verzeichnete das iSQI ein starkes Wachstum der Zertifizierungszahlen. Besonders erfreulich ist die stetig wachsende internationale Anerkennung des Zertifikats, die sich darin zeigt, dass das iSQI in den vergangenen zwei Jahren IREB Prüfungen in 18 Län-dern weltweit abnehmen konnte.
Die Konferenz für Tester im Bereich Banken und Finanzwesen „Testing and Finance“ steht im nächsten Jahr unter dem Motto „The Future of Banking – Agility and Security“. Für das Konferenzprogramm am 9. und 10. Mai in Bad Homburg (Frankfurt) können noch Beiträge bis zum 31. Dezember einge-reicht werden. www.testingfinance.com/europe/de/
Das iSQI, das seit mehreren Jahren offizielle Zertifizierungsstelle der Euro-pean Certification and Qualification Association (ECQA) ist, hat nun zwei weitere Zertifizierungsschemen dieser Institution in sein Portfolio aufge-nommen. Seit diesem Herbst bietet das iSQI Prüfungen zum Software System Service Process Improvement Manager (SPI Manager) an. Das Schulungs-und Zertifizierungsprogramm wurde von Experten aus Finnland, Dänemark, Norwegen, Österreich, Deutschland und Ungarn entwickelt. In dem Training werden u.a. der Einsatz von Prozess- (CMMI®, ITIL, Test SPI-CE etc.) und Beschreibungsmodellen (BPMN, EPK, Swimlane etc.) sowie die Anwendung von Lebenszyklusmodellen (V-Modell®, RuP, Agile Vorge-hensweisen u.a.) behandelt. Weitere Themen sind bspw. Management-An-forderungen an Prozesse, Kultur und Motivation bei der Umsetzung von Veränderungen und Planung von Prozessverbesserungsvorhaben.Mit der „ECQA Certified E-Learning Manager“-Zertifizierung wird zu Beginn des kommenden Jahres ein weiteres ECQA Berufsbild von iSQI angebo-ten werden. Das Schulungsprogramm besteht aus den drei Hauptmodulen Pädagogik, Technologie und Management. Zu jedem Modul wird das Wis-sen vermittelt, das man benötigt, um effektives E-Learning in einem Un-ternehmensumfeld zu entwickeln, zu beschaffen und gewinnbringend zu nutzen. Weitere Informationen zu den Berufsbildern der ECQA finden Sie unter www.ecqa.org.
International: Software Architecture auch auf Englisch
Ab Januar kann die Zertifizierung zum CPSA-F (Certified Professional for Software Architecture, Foundation Level) des iSAQB e.V. auch in englischer Sprache erfolgen. Erste lizenzierte Schulungsanbieter bieten bereits Schulungen in englischer Sprache an. Die Prüfungsfragen selbst wurden inhaltlich erheblich überarbeitet. Ab Januar werden die Prüfungen nach diesem neuen Schema durchgeführt.
Online: Secure Software Engineering als E-Exam
Ab sofort bietet das iSQI die Zertifizierung zum ISSECO-Certified Professional for Secu-re Software Engineering (CPSSE) neben der papiergestützten Prüfung auch als E-Exam über den weltweit agierenden Partner Pear-son VUE an. Die Zertifizierung zum CPSSE richtet sich vornehmlich an Softwareentwick-ler, die in den Bereichen Design, Architektur, Testing, Requirements Engineering und Pro-jectmanagement tätig sind. Der Inhalt der Schulung zielt darauf ab, dass Sicherheitslü-cken identifiziert werden, die in allen Phasen der Softwareentwicklung entstehen können und bietet Lösungsansätze, wie diesen Si-cherheitsrisiken vorgebeugt werden kann.www.isseco.org
Wir wollen Sie begeistern!
Anlässlich des diesjährigen Weltqualitätsta-ges am 11. November hat das iSQI seine gro-ße Kundenzufriedenheitsumfrage gestartet. Um im nächsten Jahr noch besser zu werden und die Wünsche unserer Kunden unmittel-bar umsetzen zu können, würden wir uns sehr über Ihr Feedback freuen. Gibt es etwas, das Sie uns schon lange sagen wollten? Anregungen, Lob, Kritik: Wir wollen alles hören! Besuchen Sie unsere Umfrage unter www.isqi.org und werden Sie Teil unseres aktiven Qualitätsmanagements. Erste Ergeb-nisse werden wir Anfang 2011 veröffentli-chen. Vielen Dank!
Nächste Stufe: Advanced Level Require-ments Engineering des IREB ab 2011
CALL FOR PAPERS
Neu im Portfolio: Die ECQA Zertifizierungs-schemen „SPI Manager“ und „E-Learning Manager“
5 Ausgabe 17 | Dezember 2010
PLEASE RATE YOUR EXPERIENCE WITH US!
Man könnte das, was Sie jetzt hier lesen, als „Braindump“ bezeichnen. Ein Braindump eines verregneten Samstags, an dem ich mich beim Surfen im Web über Artikel ärgere. Artikel, die die Welt so einfach zeichnen, als wären wir alle noch einmal fünf Jahre alt und würden mit Puppenhäu-sern und Feuerwehrautos spielen.
Warum ich ärgerlich in die Tastatur greife?
a) Vielleicht, weil es regnet und ich deshalb surfe anstatt etwas anderes zu tun.
b) Vermutlich auch, weil meine nächste Woche aus Termi-nen bei Kunden besteht, die mit bestechend schlich-ten Lösungen (die sie meist „Scrum“ nennen) gerade ein Projekt an die Wand fahren.
Warum ich mich über die gelesenen Artikel ärgere?
a) Zu dogmatische Thesen zum Thema Requirements Engineering (RE). Deren Autoren ignorieren, dass eine dicke Spezifikation allein keinen Anwender glücklich macht – geschweige denn zu einem guten System führt.
b) Zu schlichte Thesen zum Thema Agilität. Deren Auto-ren scheinen die Projektrealität und das, was die Infor-matik in den letzten 20 Jahren im Bereich RE gelernt hat, zu ignorieren.
RE und Agilität: Beides wird gerne in Reinform gedacht: einfach, lecker, logisch. Das geht, sobald man sich den Kontext für seine Argumentation selbst wählen kann. Man blendet die Realität aus und alles wird möglich.
Manchmal will man mehr als eine gut formulierte Spezi-fikation oder einen geschmiert laufenden Entwicklungs-prozess – zum Beispiel Folgendes:
- Das Wissen darüber, was der Markt und die Anwender wollen, professionell erheben – damit man ein Produkt baut, welches seine Nutzer begeistert.
- Die Konsolidierung aller Wünsche sicherstellen – inklu-sive der Lösung aller Konflikte - bevor irgendein Sys-tem geliefert wird und dieses später per Change Re-quest repariert werden muss.
- Eine grobe Ahnung haben, was zu welchem Zeitpunkt geliefert werden kann und was es kostet – um das Pro-jekt stoppen zu können, wenn es sich nicht rechnet.
- Die Flexibilität erhalten, das Projekt nachjustieren zu können – denn ich weiß heute noch nicht alles, was ich in einem Jahr weiß.
- Sicherstellen, dass das Entwicklungsteam vor dauernden Änderun-gen geschützt ist – um effektive Arbeit zu er-möglichen.
- Sicher sein, dass schnell ein einsatzfä-higes Produkt vorliegt – denn manchmal will man nicht auf eine per-fekte Lösung warten, sondern schnell eine Arbeitserleichterung nutzen können.
All diese Wünsche gleichzeitig zu erfüllen, schafft weder klassisches RE (im Rahmen eines klassischen Entwick-lungsprozesses) noch Scrum.
Mein Zielpublikum, das ich mit meinen Thesen gerne provoziere, sind die Menschen, die über das Vorgehen in einem neuen Projekt oder in einem Unternehmen ent-scheiden. Mir ist klar, dass in diesem Umfeld sehr viele, sehr kluge Entscheidungen getroffen werden. Aber die Tendenz, unreflektiert auf ein publiziertes Vorgehens-modell aufzuspringen, scheint in letzter Zeit zu steigen. Ich erlebe gehäuft, dass aktuellen Trends oder der Mas-se gefolgt wird, und Scrum scheint momentan der Lieb-lingskandidat zu sein. Ich möchte betonen, dass ich Sc-rum sehr schätze, und es oft verflixt gut funktioniert. Aber auch klassisches RE in Kombination mit anderen Vorge-hensmodellen funktioniert oft verflixt gut. Beide Ansätze haben signifikante Stärken, werden aber gerne wie eine Religion dogmatisch verteidigt und lassen in ihrer Anwen-dung oft den gesunden Pragmatismus vermissen.
Das klingt so, als ob eine Kombination aus RE-Know-how und Scrum-Know-how zu gesteigerter Projektglücksse-ligkeit führt. Und – ja, ich gestehe – das habe ich auch schon erlebt. Da ich aber eine Streitschrift schreiben wollte und keinen Lösungsvorschlag, werfe ich hier paar Thesen in die Runde, die zu einer angeregten Diskussion führen sollen.
Eine Erweiterung von Scrum um fundierte RE-Erfahrun-gen kann folgende Auswirkungen haben.
- Das Konsolidieren von differierenden Stakeholder-meinungen ist eine wichtige Tätigkeit. Wenn man am
Eine Streitschrift – eine Provokation – jenseits von Lösungen! Chris Rupp
Im Fokus Ausgabe 17 | Dezember 2010 6
Chris Rupp
Anfang eines Projektes fünf Stakeholder nach ihrer Meinung fragt, bekommt man sieben unterschiedli-che Antworten. Dazu sind die Konflikte oft so grund-legend, dass sie dringend geklärt werden müssen, be-vor ein System entwickelt werden kann. Also müssen sich alle Beteiligten an einen Tisch setzen und sich auf eine grundlegende Richtung einigen, was die Konsoli-dierung zu einem Zeit und Nerven kostenden Prozess macht. Dazu fehlt während eines Scrum-Sprints leider oft die Zeit. Auch sind dann die relevanten Ansprech-partner bereits außen vor und der Konflikt kann gar nicht mehr gelöst werden. Eine Vorstudie, in der die härtesten Kämpfe schon mal ausgefochten werden, kann hier helfen. Nach dieser Vorstudie muss der Pro-duct Owner nicht mehr ständig mit Querschüssen aus dem Fachbereich rechnen, denn die schlimmsten Kon-flikte sind bereits gelöst.
- Irgendeine Art der Dokumentation des Gelernten ist wichtig, denn durch Dokumentation kann Wissen asynchron mitgeteilt werden. Nicht immer sind alle Teammitglieder im War-Room vertreten oder nehmen an den täglichen Stand-Up-Meetings teil, denn es gibt auch verteilt arbeitende Projekte. Auch müssen - bei vorhandener Dokumentation - während der nächsten Neuentwicklung in fünf Jahren nicht alle Businesspro-zesse und -Artefakte wieder von Neuem ermittelt wer-den. Dafür muss nicht zwingend eine dicke Prosaspe-zifikation entstehen. Wie wäre es mit ein paar BPNM- oder UML-Klassendiagrammen, die das Scrum-Team pflegt?
- Indirekte Kommunikation über den Produkt Owner muss möglichst vermieden werden. Wenn Hansi Mül-ler als Fachexperte etwas beitragen soll, dann direkt – und nicht mittelbar über den Produkt Owner. Ich fal-le jedes Mal vom Glauben ab, wenn mir einerseits ein Entwicklungsteam ein Loblied über direkte Kommuni-kation singt, und andererseits den Vorschlag macht, das Wissen der Stakeholder nur über den Produkt Owner in das Team einzubringen. Das ist Stille-Post-Spielen für Erwachsene und sehr ineffizient.
- Der Einsatz von professionellen Ermittlungstechniken im Rahmen der Kommunikation mit Stakeholdern ist auch in agilen Projekten sinnvoll. User Dass es neben dem abrufbaren Wissen noch unter- bzw. unbewusstes Wissen gibt, ist ein alter Hut. Nur die verlangten Leis-tungsfaktoren abzuarbeiten ist die halbe Miete. Um ein wirklich tolles Produkt zu entwickeln muss man wis-sen, was die Nutzer erwarten aber nicht explizit verlan-gen (Basisfaktoren) und was sie noch gar nicht kennen aber was sie wirklich aus den Socken haut (Begeiste-rungsfaktoren). Dabei helfen Ermittlungstechniken, wie
sie in der einschlägigen Literatur seit Jahren zu finden sind (z.B. unserem Buch Chris Rupp und die SOPHIS-Ten „Requirements Engineering & Management)“.
- Rituale und Regeln sollten mit Sachverstand reflektiert werden – sonst werden sie zu Dogmen. Wenn ich wäh-rend der Stand-Up-Meetings feststelle, dass die dafür vorgegebenen 15 Minuten zu kurz oder zu lang sind, dann traue ich mir so viel Sachverstand zu, diese Zeit-vorgabe zu ignorieren.
- Ich habe nichts gegen die klare Rollendefinition, die Scrum bietet. Aber was tue ich, wenn mein Produkt Owner vorhersehbar überlastet ist? Wie wäre es, einen Scrum-Prozess zu nehmen, diesen um eine Rollende-finition für die Tätigkeiten der Wissensvermittlung und Konsolidierung zu erweitern? Wir können es ja dann immer noch Scrum nennen oder behaupten, wir ma-chen „agiles RE“.
Viele dieser Themen werden wir in der neu gegründeten RE-Fachgruppe des ASQF diskutieren – und darauf freue ich mich! Zudem sind auch die Facebook-Seiten
„Requirements Engineering“ (http://www.facebook.com/pages/Requirements-Engineering/124179417595915) und „Certified Professional for Requirements Engineering“ (http://www.facebook.com/pages/Certified-Professional-for-Requirements-Engineering/ 104108786304427) geeig-nete Plattformen für einen Erfahrungsaustausch. Ich freue mich auf Feedback.
Wenn ich über Methoden nachdenke und in meinem Kopf die Projektrealität meiner Kunden zuschalte, dann sind Requirements Engineering und Agilität in der Welt der schwer lösbaren Widersprüche angekommen! In der Theorie war die blankgebürstete Geschichte von RE und von Scrum nur perfekt, in der praktischen Kom-bination wird sie sicher schwierig, vermutlich aber inte-ressant und vielleicht sogar bedeutsam.
Die Autorin
Chris Rupp (www.sophist.de/chris.rupp) liefert durch Ihre Publikationen und Vorträge immer wieder wichtige Impulse für die Bereiche Requirements Engi-neering und Objektorientierung. Erfindungen von Ihr und den SOPHISTen leg-ten die Basis des modernen Requirements Engineering. Chris ist Geschäfts-führerin der SOPHIST GmbH (www.sophist.de oder http://www.facebook.com/SOPHIST.GmbH).
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
7 Ausgabe 17 | Dezember 2010 Requirements Engineering
Im Fokus
User Stories als Instrument des RE Heiko Köppen
Bei unserem letzten „RE Stammtisch Berlin-Brandenburg“ wurde ich gefragt, wie man User Stories im Requirements Engineering (RE) einsetzen kann und was die Unterschiede zu den sonst üblichen RE-Instrumenten sind. In diesem Arti-kel möchte ich ein wenig Licht ins Dunkel bringen und zeigen, dass es sich bei den User Stories nicht (nur) um eine andere Notation handelt, sondern vielmehr um einen anderen, prag-matischen RE-Ansatz.
Warum scheitern Projekte insbesondere am RE?
Verschiedene Studien zeigen, dass mangelndes RE die wich-tigste Ursache für gescheiterte Projekte ist. Insbesondere die Tatsache, dass
- Anforderungen unvollständig sind,- Anforderungen sich im Projektverlauf ändern,- Kunden und Anwender zu wenig in die Anforderungsarbeit
eingebunden sind,- Anforderungen unrealistisch sind bzw. falsch/nicht priori-
siert werden
kann den Projekterfolg gefährden.Gängige Lehrprogramme (vgl. [1]), aber auch Standards (IEEE610) gehen davon aus, dass alle wesentlichen Anforde-rungen am Anfang eines Projektes erhoben und vollständig dokumentiert werden (Text, UML, ...). Diese werden in einem Requirements Management System detailliert erfasst, attri-butiert und unterliegen anschließend einem komplizierten, zeitlich aufwendigen Change Request Verfahren.
Soweit zur Theorie. Doch sind wir mal ehrlich: In der Pra-xis werden wir als Anforderungsingenieure immer wieder mit den o.a. Tatsachen konfrontiert. DASS diese Situationen auf-treten, ist durch uns häufig nicht zu verhindern. Also stellt sich die Frage, WIE wir damit umgehen sollten. Ist es wirklich immer notwendig, alle Anforderungen im Vorfeld zu definie-ren und detailliert zu dokumentieren?
Ich meine: Nein. Viele agile Konzepte greifen aus diesem Grund auf sogenannte User Stories zurück. Dabei wird die Tatsache akzeptiert, dass Anforderungen immer veränderlich und immer unvollständig sind. Dieser Tatsache wird dadurch Rechnung getragen, dass die stetige Kommunikation zwi-schen allen Beteiligten (Kunde, Nutzer, Entwickler, Tester, …) eine fundamentale Rolle spielt.
Was ist eine User Story?
Eine User Story ist ein in der Sprache des Kunden formu-lierte Anforderung, die eine für den Kunden/Nutzer wertvolle
Funktionalität beschreibt. Sie besteht aus drei Kom-ponenten: Der Story Card, der Konversation und den Akzeptanzkriterien.
Die Story Card beschreibt den Kern der Anforderung unter Verwendung des fol-genden Schemas:
Als <Benutzerrolle> will ich <das Ziel> so dass <Be-gründung>.
Beispiel:Als Kunde will ich Artikel suchen können, so dass ich diese dem Warenkorb hinzufügen kann.
Das Schema unterstützt einerseits das Denken in Rollen, an-dererseits wird der Kundennutzen für den Leser transparent gemacht. Die User Story mit Ihrer zugehörigen Story Card stellt das Versprechen dar, dass sich Kunde und Team über das betreffende Thema austauschen werden. Die diesbezüglich stattfindende Konversation ist der eigent-liche Informationslieferant. In jedem dieser Gespräche wird
die User Story durch Konversation weiter vervollständigt.Die zur User Story gehörenden Akzeptanzkriterien geben die Erwartungshaltung des Kunden wieder. Akzeptanzkriterien beschreiben, wann eine User Story fertig ist und dem Kun-den einen Mehrwert liefert.
Wenn es um die Formulierung von User Stories geht, muss beachtet werden, dass sie nicht dazu geeignet sind, nicht-funktionale Anforderungen festzuhalten wie bspw. Perfor-
Heiko Köppen
Abbildung 1: Bestandteile einer User Story
Ausgabe 17 | Dezember 2010 8
Requirements Engineering
manz-, Usability- oder Sicherheitsanforderungen. Trotzdem ist es notwendig, diese als Constraints zu ermitteln und festzuhalten. Aus meiner Erfahrung heraus empfehle ich, nichtfunktionale Anforderungen zusätzlich zu User Stories auf separaten Karteikarten festzuhalten. Außerdem stellen gefundene Fehler (Bugs) ebenfalls eine wichtige Anforde-rungsquelle dar.
Wie finde ich geeignete User Stories?
In seinem Buch „User Stories“ (das ich übrigens sehr emp-fehle) schlägt Mike Cohn das INVEST-Modell zur Bewertung guter User Stories vor. An dieser Stelle möchte ich nur zwei Aspekte aus der Praxis näher beleuchten.
User Stories müssen klein seinIn allen agilen Methoden ist es das Ziel des Entwicklerteams, dem Kunden am Ende einer Iteration eine oder mehrere funk-tionierende User Stories zur Verfügung zu stellen. Demzufol-ge müssen User Stories eine geeignete Größe haben. Diese fängt bei ca. einem Tag an und kann nicht größer werden, als es eine Iteration vorgibt.Ist eine User Story zu groß, spricht man von einem Epic. Je-des Projekt startet zuerst mit Epics (Visionsdokument), die im Verlauf des Projekts auf anwendbare User Stories herunter gebrochen werden müssen. Bzgl. anwendbarer Strategien zum Herunterbrechen sei hier noch einmal auf [2] verwiesen.
User Stories müssen testbar seinUser Stories müssen zu verschiedenen Zeitpunkten getestet werden: Während der Entwicklung, am Iterationsende (Kun-dentest) und im weiteren Projektverlauf (Regressionstest). Mit Hilfe der Definition von Akzeptanzkriterien kann diese Forderung an User Stories erreicht werden. Voraussetzung hierfür ist, dass der Autor der User Stories (z.B. Kunde) me-thodisch dazu in der Lage ist. Das ist häufig eben nicht der Fall aufgrund fehlender Testmethodikkenntnisse. Aus diesem Grund empfehle ich dringend, dass bereits beim Schreiben von User Stories auch Tester eingebunden werden, um den Autor zielgerichtet methodisch zu unterstützen. Ein weiterer Nebeneffekt ist, dass auf diese Weise bereits frühzeitig Wis-sen über zukünftige User Stories in das Team getragen wird.
Wie arbeitet man mit User Stories?
Am Beispiel des agilen Vorgehensmodells Scrum möchte ich nun erläutern, wie sich User Stories in den Entwicklungspro-zess einbinden lassen. Bei Scrum enthält das sogenannte Product Backlog alle User Stories. Um eine User Story als Grundlage einer Iteration (Sprint) in der Projektarbeit verwenden zu können, muss sie zuerst „sprintfähig“ gemacht werden. Dazu müssen sie drei Arbeitsschritte durchlaufen: Ermitteln, Priorisieren, Schätzen.
Die initiale Ermittlung von User Stories liegt in der Verantwor-tung des Product Owners und unterscheidet sich nicht von der üblichen Herangehensweise im RE. Bemerkenswert ist lediglich die Tatsache, dass sich User Stories durch die statt-findende Konversation noch bis zum letzten Augenblick (bis zum Ende des Sprintplanungsmeetings) ändern können. Dar-über hinaus empfehle ich auch hier noch einmal dringend die Einbindung von Testern zur Definition von Abnahmekriterien.
Die Priorisierung der User Stories erfolgt durch den Product Owner nach einem geeigneten Modell (Kano-Modell, MuS-CoW, ...). Sie bestimmt wesentlich die Reihenfolge der Re-alisierung.
Die Schätzung der User Stories erfolgt durch das Scrum Team. In der inhaltlichen Konversation mit dem Product Ow-ner leitet das Team die anstehenden Aufgaben ab und ermit-telt den Aufwand für die Realisierung.
Zusammenfassung
Die Verwendung von User Stories im RE bietet einen praktika-blen, pragmatischen und nutzenorientierten Ansatz zum Um-gang mit Anforderungen. Voraussetzung für einen erfolgrei-chen Einsatz ist jedoch, dass die konkrete Projektumgebung den Einsatz dieser agilen Methodik überhaupt möglich macht.
Quellenangabe[1] K.Pohl, C.Rupp, Basiswissen Requirements Engineering,
dpunkt.verlag, 2.Auflage 2010[2] M. Cohn, User Stories für die agile Software-Entwicklung
mit Scrum, XP u.a., mitp 2010
Abbildung 2: RE-Bestandteile
Dipl.-Ing. Heiko Köppen ist CEO der Avenqo GmbH. Neben Beratung und Trai-ning rund um die Themen RE, Test und DQM steht das hauseigene ALM-Tool Avenqo PEP im Fokus des Unternehmens.
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
Der Autor
9 Ausgabe 17 | Dezember 2010
Im Fokus
Was ist Traceability?Traceability ist in aller Munde, aber was ist das genau? Gemäß DIN EN ISO 9000 ist Traceability (dt. Rückverfolg-barkeit) die „Möglichkeit, den Werdegang, die Verwendung oder den Ort des Betrachteten zu verfolgen“. Einfacher ausgedrückt: Traceability bedeutet die Verfolgbarkeit von Projektinformationen, insbesondere Anforderungen, im ge-samten Systemlebenszyklus.
Diverse Prozessstandards fordern Traceability, u.a.:- ISO/IEC 15288, Systems and software engineering – Sys-
tem life cycle processes- DIN EN 50128, Bahnanwendungen – Telekommunikations-
technik, Signaltechnik und Datenverarbeitungssysteme- CEI/IEC 62304, Medical device software – Software life
cycle processes- Capability Maturity Model Integration (CMMI)- ISO 15504, Information Technology - Process Assessment
(SPICE)
Nutzen von TraceabilityDie aufgeführten Standards fordern Traceability aber nur, weil sie einen Nutzen bringt. Traceability erleichtert es Ih-nen, die Auswirkungen einer Änderung (z.B. die Änderung einer Kundenanforderung) zu analysieren. Sie können sicherstellen, dass jede Kundenanforderung umgesetzt wird. Keine Änderung geht verloren, da leicht zu prüfen ist, ob es von jeder Kundenanforderung einen Trace (also eine explizite Dokumentation der Rückverfolgbarkeit zwischen
Informationen) in mindes-tens eine Systemanfor-derung gibt. Umgekehrt können Sie überflüssige Funktionen vermeiden, in-dem Sie prüfen, ob sich jede Systemanforderung über mindestens einen Trace auf eine Kundenan-forderung zurückführen lässt. Auch bestimmte Messungen sind ohne eine Traceability kaum durch-führbar. Z.B. kann man nur schwer bestimmen, wie viele Systemanforderungen bereits erfolgreich im System getestet wurden, ohne eine Traceability zwischen Systemanforderungen und System-testfällen erstellt zu haben.
Nachteile von TraceabilityUm den vollen Nutzen aus der Traceability zu ziehen, muss man allerdings auch einige Nachteile in Kauf nehmen. Die Erstellung und Pflege der Traces ist sehr aufwändig, denn prinzipiell müssen alle Projektinformationen, die inhaltlich voneinander abhängen, miteinander verknüpft werden. Dies setzt sehr viel Disziplin bei den verantwortlichen Mitarbei-tern voraus. Hier können Requirements Management Tools mit einer Traceability-Funktionalität bis zu einem gewissen Grad helfen. Aber sobald Traces zu Informationen außer-
halb des Werkzeuges gezo-gen werden müssen, versagt die Traceability-Funktionalität des Werkzeuges im Allgemei-nen (Medienbruch).
Realisierung von TraceabilityEs gibt verschiedene Arten von Traces und deren Reali-sierung. Man muss diese ver-schiedenen Arten kennen, um im Einzelfall die einfachste und effektivste Art der Trace-ability auswählen zu können. Grundsätzlich unterscheidet man zwischen uni- und bi-di-rektionalen Traces. Bei uni-di-rektionalen Traces kann man nur von der Quelle bis zum Ziel des Traces navigieren, bei
Traceability: Tipps zur Realisierung nachvollziehbarer Anforderungen Jens Palluch
Jens Palluch
Abb. 1: Informationsmodell als Basis für die Realisierung von Traceability
Ausgabe 17 | Dezember 2010 10
bi-direktionalen Traces kommt man auch wieder zurück zur Quelle. Darüber hinaus wird differenziert zwischen ex-pliziten und impliziten Traces. Bei den expliziten Traces ist die Verknüpfung zwischen zwei Informationen explizit do-kumentiert. Bei impliziten Traces basiert die Rückverfolg-barkeit von Informationen entweder auf dem Wissen eines Projektmitarbeiters oder lässt sich über mehrere explizite Traces ableiten. Bei expliziten Traces muss es sich nicht immer um Traces oder Links in einem Werkzeug handeln. Weitere Möglichkeiten zur Erstellung von Traces sind die Verwendung von Text-IDs über Attribute, die hierarchische Anordnung von Informationen oder die manuelle Pflege ei-ner Traceability-Matrix.
Basierend auf dem sog. Informationsmodell, das explizit oder implizit existiert und die verwendeten Informationen und deren Zusammenhänge aufzeigt (Abb. 1), ist festzule-gen, welche Abhängigkeiten durch explizite Traces darge-stellt und welche Art der Realisierung verwendet werden sollen.
Tipps zur TraceabilityTraceability ist oft ein „ungeliebtes Kind“ und wird nicht an-gemessen behandelt. Prüfen Sie daher genau, welche Tra-ces der Kunde oder ein Standard von Ihnen fordert, und welche Traces Ihnen einen Nutzen bringen. Traces sind eine aufwändige Angelegenheit. Beschränken Sie sich deshalb auf die notwendigen und nutzbringenden Traces. Definieren Sie die Bedeutung der Traces, z.B. „ist abgeleitet von“ oder
„realisiert“. Legen Sie fest, wer für welche Traces verant-wortlich ist, wie die Qualitätssicherung der Traces sicherge-stellt und wann die Traceability erstellt und gepflegt werden soll. Dann sind Sie bestens gewappnet!
Automatisiertes Testen von Android Anwendungen
Der Autor
Jens Palluch studierte Technomathematik an der Technischen Universität Clausthal. Seit 2005 ist er für die Method Park Software AG als Trainer und Berater tätig und dort verantwortlich für die Themen Systems Engineering und Requirements Engineering.
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
11 Ausgabe 17 | Dezember 2010 Requirements Engineering
Advertorial
Mobile Betriebssysteme wie Android begleiten uns immer häufiger im Alltag, die Zahl der verfügbaren Anwendungen nimmt stetig zu. Damit steigt auch die Wichtigkeit diese effi-zient zu testen. Das Testautomatisierungswerkzeug expecco bietet dafür eine komfortable Schnittstelle. (www.exept.de) Bei komplexen Systemen auf mobilen Endgeräten sind Da-tenbanken, Desktop-Anwendungen, Webinterfaces und vie-les mehr involviert. Umso wichtiger ist es diese effizient zu testen.
Das neue expecco Android Plugin ermöglicht vollautomati-siertes Testen der Android Anwendungen, die auf den ver-schiedensten Geräten ausgeführt werden können.In expecco ist eine komplette Android Bausteinbibliothek verfügbar. Die Bausteine können per Drag&Drop nach Bedarf zur Modellierung der Testabläufe verwendet werden. Der GUI Browser ermöglicht es, die zu testende Anwendung explora-tiv und auf GUI-Ebene zu erkunden. Das Modell kann wiederholt und parallel gegen die verschie-densten Implementierungen und Geräte laufen. Tests werden auf einfache Weise grafisch modelliert und anschließend mit nur einem Klick ausgeführt. Benötigt man für den automa-tisierten Testablauf zusätzliche Geräte und/oder Applikatio-nen, so können diese über weitere Plugins mit eingebunden werden.
eXept bietet Ihnen die Möglichkeit dieses Plugin in Verbin-dung mit der Testautomatisierungssoftware expecco zu tes-ten. Nähere Infos zum Android Plugin finden Sie unterwww.exept.de/files/android.pdf.
Ausgabe 17 | Dezember 2010 12Kolumne
Wussten Sie schon, dass das Informationszeitalter vor-bei ist? – Das behaupten jedenfalls die Kondratieff-
„Jünger“. Und Kondratieff war kein Sektenführer, sondern Direktor des Moskauer Instituts für Konjunkturforschung (www.kondratieff.net). Er legte in den 20-iger Jahren des letz-ten Jahrhunderts die Grundlagen für so manchen Nobelpreis in der Sparte Wirtschaft. Er war einer der ersten, der begrün-dete, warum die Weltwirtschaftskonjunktur in Zyklen verläuft, die sich an Innovationen orientieren: Dampfmaschine, Eisen-bahn, Elektrotechnik, Automobil, Informationstechnik.
Die Theorie besagt weiter, dass gerade jetzt, am Anfang des 21. Jahrhunderts, das Zeitalter der Informationstechnik zu Ende geht und die nächsten Innovationen mit Auswirkun-gen auf die Weltwirtschaft aus den Bereichen Gesundheit und Arbeitsorganisation kommen. Mit anderen Worten, es wird darum gehen, wie man Arbeit so organisiert, dass sich eine längere und produktivere Lebensarbeitszeit ergibt. Dies erfordert Innovationen beim richtigen Einsatz von Informati-
onstechnik und bei der Wei-terentwicklung der Technik selbst.
Na, wenn das kein Aufruf an die Anwendungsent-wickler ist! Doch welche Anwendungen sollen denn entwickelt werden? Hierfür ist eine Innovationsstrategie notwendig. Falls Sie mehr zu diesem Thema lesen möchten, so schauen Sie doch nach un-ter www.wois-innovation.de. WOIS steht für „Widerspruchs-Orientierte InnovationsStrategie“. Wenn Sie mehr über Kon-dratieff und die Auswirkungen seiner Theorie auf die Zukunft wissen wollen, dann empfehle ich Ihnen das Buch „Die Ge-schichte der Zukunft“ von Erick Händeler.
Keine Innovation ohne Strategie Prof. Dr. Bernd Hindel
hier schreibt in regelmäßigen Abständen der Beirat des ASQF e.V.
Prof. Dr. Bernd Hindel
Anzeige
Der Call for Papers für den 5. Weltkongress für Software-Qualität (WCSQ) läuft auf Hochtouren. Die renommierte internationale Zusammen-kunft von Softwarequalitätsexperten fi ndet im kommenden Jahr im KIC in Shanghai (China) statt. Das International Software Quality Institute (iSQI) freut sich sehr darauf, die Delegationen aus Europa, dem Mittleren Osten und Afrika im Auftrag der European Organization for Quality (EOQ-SG) zu leiten. Themenschwerpunkte sind unter anderem: Software Qualitätsmanagement in Organisationen oder Projekten, Grundlagen von Software Qualität oder Software Qualitätsanalyse und -evaluierung.
International Software Quality Institute (iSQI, Germany) on behalf of European Organization for Quality - Software Group (EOQ-SG)
Reichen Sie ein!
5WCSQ: 5th World Congress for Software Quality31 October – 4 November, 2011, Shanghai, China
United Under One BannerBest of Best Quality
Call for PapersEinreichung der Fachbeiträge bis zum 15. Januar 2011Weitere Themenschwerpunkte und Informationen zu den Einreichungsmodalitäten fi nden Sie unter:
http://www.isqi.org/konferenzen/wcsq/5-wcsq/call-for-papers/
Der Call for Papers für den 5. Weltkongress für Software-Qualität (WCSQ) läuft auf Hochtouren. Die renommierte internationale Zusammen-kunft von Softwarequalitätsexperten fi ndet im kommenden Jahr im KIC in Shanghai (China) statt. Das International Software Quality Institute (iSQI) freut sich sehr darauf, die Delegationen aus Europa, dem Mittleren Osten und Afrika im Auftrag der European Organization for Quality (EOQ-SG) zu leiten. Themenschwerpunkte sind unter anderem: Software Qualitätsmanagement in Organisationen oder Projekten, Grundlagen von Software Qualität oder Software Qualitätsanalyse und -evaluierung.
International Software Quality Institute (iSQI, Germany) on behalf of European Organization for Quality - Software Group (EOQ-SG)
Reichen Sie ein!
5WCSQ: 5th World Congress for Software Quality31 October – 4 November, 2011, Shanghai, China
United Under One BannerBest of Best Quality
Call for PapersEinreichung der Fachbeiträge bis zum 15. Januar 2011Weitere Themenschwerpunkte und Informationen zu den Einreichungsmodalitäten fi nden Sie unter:
http://www.isqi.org/konferenzen/wcsq/5-wcsq/call-for-papers/
13 Ausgabe 17 | Dezember 2010
Wenn Sie mit Ihrer Wohnsituation unzufrieden sind, kann das mehrere Ursachen haben: Die Gegebenheiten ent-sprechen nicht mehr modernen Wohnbedürfnissen, die Betriebskosten sind zu hoch, Optik und Ausstattung ver-hindern jeglichen Wohlfühlfaktor oder die Bausubstanz ist bereits als Sicherheitsrisiko einzustufen.
In dieser Situation werden Sie sich intensiv mit unterschied-lichen Lösungsmöglichkeiten auseinandersetzen: Diese reichen von umfassenden Ansätzen, wie neuem Standort oder Abriss/Neubau über Sanierung oder Teilsanierung bis zu punktuellen Reparaturarbeiten. Für eine nachhaltige Ent-scheidung ist es notwendig, die eigenen Bedürfnisse klar zu definieren und die bestehende Bausubstanz zu bewer-ten. So hängen z.B. Adaptierungs- und Sanierungskosten in hohem Maße von der Qualität oder Struktur der beste-henden Baulichkeiten ab.
Ähnlich verhält es sich, wenn Sie für das Management ei-ner Applikation/eines Applikationsportfolios verantwortlich sind. Ausgelöst durch hohe Lizenzkosten, auslaufenden Produktsupport, Pensionierung des Wartungspersonals, massive Änderungen der Anforderungen oder neue Unter-nehmensstrategien sind Sie früher oder später aufgerufen oder gezwungen, Modernisierungsstrategien zu entwickeln. Wie ein Sachverständigen-Gutachten für Ihr Haus ist ein solches auch für das Assessment einer Applikation/eines Applikationsportfolios von unschätzbarem Nutzen. Ein Ap-plication Value Assessment dient der Vermessung der exis-tierenden Software in den Dimensionen
- Qualität- Quantität - Komplexität und ermöglicht auf Basis umfassender Metriken eine fun-dierte Bewertung des funktionalen Umfangs (z.B. auf Ba-sis von Function Points), der Architektur sowie der inneren Qualität der Software. So wie Bausachverständige mit Ultraschallgeräten und Infrarotkameras dem Mauerwerk zu Leibe rücken, kom-
men auch in der Software-Vermessung spezielle Werkzeuge, wie z.B. die ANECON-Tools SoftAudit und SoftEval, zum Einsatz. Darin ist eine Vielzahl von Metriken implementiert, wie sie auch im neuen Buch der ANECON-Auto-ren Sneed, Seidl, Baum-gartner „Software in Zah-len“ erläutert sind. Ohne Werkzeugeinsatz wäre eine Analyse und Aufbereitung der Informationen nicht möglich.
Auf Basis der Assessment-Ergebnisse können entspre-chende Modernisierungsstrategien (Sanierung/Erhaltung, Migration/Transformation, Neu-entwicklung/Reimplementierung, Ablöse durch Standardsoftware) entwickelt und kosten- bzw. aufwandsseitig fundiert einge-schätzt und geplant werden.Aber wie bei der Erhaltung eines Hauses ist es auch bei Software besser, diese nicht alle zehn bis zwanzig Jahre in einem großen Projekt zu erneuern, sondern durch laufende Modernisierung den Sanierungsfall zu vermeiden.
Software Modernisierung Manfred Baumgartner
Manfred Baumgartner
Abb.3.: Software in Zahlen, Hanser Verlag 2010, ISBN-10: 3446421750ISBN-13: 978-3446421752
Advertorial
Advertorial
Abb.1.: Modernisierungsstrategien
Abb.2.: Dimensionen von Software
Der Call for Papers für den 5. Weltkongress für Software-Qualität (WCSQ) läuft auf Hochtouren. Die renommierte internationale Zusammen-kunft von Softwarequalitätsexperten fi ndet im kommenden Jahr im KIC in Shanghai (China) statt. Das International Software Quality Institute (iSQI) freut sich sehr darauf, die Delegationen aus Europa, dem Mittleren Osten und Afrika im Auftrag der European Organization for Quality (EOQ-SG) zu leiten. Themenschwerpunkte sind unter anderem: Software Qualitätsmanagement in Organisationen oder Projekten, Grundlagen von Software Qualität oder Software Qualitätsanalyse und -evaluierung.
International Software Quality Institute (iSQI, Germany) on behalf of European Organization for Quality - Software Group (EOQ-SG)
Reichen Sie ein!
5WCSQ: 5th World Congress for Software Quality31 October – 4 November, 2011, Shanghai, China
United Under One BannerBest of Best Quality
Call for PapersEinreichung der Fachbeiträge bis zum 15. Januar 2011Weitere Themenschwerpunkte und Informationen zu den Einreichungsmodalitäten fi nden Sie unter:
http://www.isqi.org/konferenzen/wcsq/5-wcsq/call-for-papers/
Seit Anfang 2001 ist Manfred Baumgartner als Berater für Qualitätsmanage-ment und Software Test bei ANECON Software Design und Beratung GmbH tä-tig, 2003 übernahm er die Leitung des strategischen Geschäftsfeldes Software Test mit derzeit 45 Mitarbeitern. Besonderes Augenmerk gilt den Testdesigns, dem Einsatz von Testmetriken sowie der Anwendung von Testwerkzeugen in der Vorbereitung, Durchführung (Automatisierung) und dem Controlling der Tests. Die Durchführung von Prozess-Assessments (CMMi, TPI) runden sein Aufgabengebiet ab.
Der Autor
Ausgabe 17 | Dezember 2010 14Im Fokus
Wirksames Testen ist ohne klare Requirements nicht mög-lich. Doch häufig bleiben die Requirements hinter den Er-fordernissen des Testens zurück, oder es gibt Brüche beim Übergang von den Anforderungen zu den Tests. Durch den Ausbau des Requirements-basierten Testens richten Test-manager die Software-Entwicklung an den Business-Erfor-dernissen aus, und sie erhöhen nachhaltig Produktqualität und Effektivität der Projekte. Mit Requirements-basiertem Testen unterstreichen die Testmanager, dass sie eine zent-rale Bedeutung für die Software-Entwicklung besitzen. Da das Requirements-Management (RM) in vielen Organisati-onen nicht klar ausgeprägt ist, können die Testmanager es mitgestalten. Sie betonen so die Geschäftsausrichtung des Testens und fördern eine übergreifende, effiziente IT-Infra-struktur für Software-Projekte.
Viele Wege führen nach RomDas unterstreichen drei Beispiele für Herangehensweisen – oder Pfade – zum Aufbau des Requirements-basierten Tes-tens. Sie gehen aus von unterschiedlichen Gegebenheiten in Software-Organisationen. Die Fallbeispiele verdeutlichen, welche Möglichkeiten Testmanager durch die stärkere Be-achtung des RM besitzen.Das erste Beispiel zeigt, wie eine Abteilung vom internen Dienstleister für technische Tests zum Repräsentanten des Business innerhalb der Software-Organisation werden kann. Die Abteilung wurde initiiert als Competence-Center für die Last- und Performance-Tests der geschäftskritischen Inter-net-Applikationen des Unternehmens. Schnell wurde klar, dass sie auch die funktionalen Tests wirkungsvoll unterstüt-zen kann, wenn sie eine einheitliche Prozess- und Tool-Infra-struktur für Testmanagement und -automatisierung aufbaut.Durch die Unterstützung der funktionalen Tests bildet die Testabteilung nun eine wichtige Schnittstelle zwischen den Fachbereichen und der Software-Entwicklung. Sie stößt aber an Grenzen, weil jeder Fachbereich seine eigenen Herange-hensweisen an das RM hat. So ist es schwierig, die Test-
fälle übersichtlich zu struk-turieren. Das erschwert die Erstellung der Testfälle wie auch die Aussagekraft der Testergebnisse.
Testmanagement als Part-ner der Fachbereiche Diese Schwierigkeiten beim funktionalen Testen kann die Testabteilung überwin-den, wenn sie gemeinsam mit den Fachbereichen einheitliche Requirements-Praktiken etabliert. Die Fachbereiche müssen greifbare Erleichterungen und Verbesserungen erhalten: So sollen Requirements-Templates die Definition der Anforderungen beschleunigen und ihre Qualität erhöhen.Im genannten Beispielprojekt hat die Testabteilung die Spe-zifikationsdokumente der Fachbereiche zunächst noch nicht angetastet. Aber sie hat die Anforderungen in einem integ-rierten Requirements- und Testmanagement-Tool, hier HP Quality Center, als Requirements-Hierarchie hinterlegt und mit den Testfällen verknüpft. Dadurch kann sie den Fachbe-reichen für jede sie interessierende Anforderung den Teststa-tus darstellen.Für die Etablierung des Requirements-basierten Testens ist wichtig, dass die Testabteilung die Requirements-Praktiken aktiv mitgestaltet und dem Fachbereich als Knowhow-Träger, Coach und unterstützender Dienstleister gegenüber tritt.
Testaspekte in der Spezifikation verankernIm zweiten Beispiel geht es um die kontinuierliche Weiter-entwicklung einer internen Unternehmensapplikation. Ein Fachbereich spezifiziert die Anforderungen in Form von Change-Requests (CR), die ein externer Systemlieferant im-plementiert. Die IT-Abteilung koordiniert das Gesamtprojekt und steuert den Lieferanten.
Bei den Abnahmetests übernahm die IT-Abteilung zunächst nur die formale Organisation, während Fachbereich und Lie-ferant die Tests oft erst spät und unvollständig ausführten. Daraufhin hat die IT die CR-Dokumentenvorlagen um Testkri-terien erweitert. Ein Stage-Gate-Verfahren sorgt dafür, dass die Systemanalytiker bereits bei der Spezifikation die Test-kriterien angeben und so früh mit der Testplanung beginnen.Da der Fachbereich sich nun früh im Projektverlauf mit den Testfällen beschäftigt, sind Requirements-Qualität, Termin-treue und Testabdeckung gestiegen. Die IT-Abteilung hat eine stärkere Kontrolle über den Projektablauf gewonnen. Dieses Vorgehen wird durch den Einsatz von Testmanage-
Pfade zum Requirements-basierten Testen Andreas Birk
Andreas Birk
Abb. 1: Good Practices für das Requirements-basierte Testen, eingeordnet in ein V-Modell der Software-Entwicklung, das um explizite Testvorbereitung ergänzt ist.
15 Ausgabe 17 | Dezember 2010 Requirements Engineering
ment-Tools gefördert, funktioniert aber auch bei rein doku-mentenbasierter Spezifikation.
Klare Zuständigkeiten und AbläufeBeispiel Drei kommt aus der Produktentwicklung eingebet-teter Software: Die Entwicklungsorganisation hat ihr Fehler-management neu aufgesetzt und durch ein neues Defect-Management-Tool unterstützt. Dabei wurde das RM selbst zwar nicht verändert. Mit dem Fehlermanagement ist aber ein Prozess etabliert, der für das Testen eine ähnliche Be-deutung besitzt wie das Requirements-Management, etwa für das Monitoring der Re-Tests bei der Fehlerbehebung.Das Fehlermanagement kann auch ein Zwischenschritt hin zum Requirements-basierten Testen sein. Wiederum sind wichtige Erfolgsfaktoren, dass das Testmanagement klare Zuständigkeiten etabliert – hier für die Definition und Durch-führung des Fehlermanagements – und geeignete Tool-Un-terstützung anbietet.Abbildung 1 fasst die wichtigen Good Practices zusammen, die Pfade zum Requirements-basierten Testen bilden:
- Klare Zuständigkeiten für das Requirements-Management schaffen (v.a. Competence Center und interner Dienstleis-ter für RM).
- Früh von den Requirements zu den Tests übergehen (ins-bes. Dokumente aufeinander abstimmen, Testfälle früh de-finieren und mit den Requirements verbinden).
- Fehlermanagement in engem Zusammenhang mit dem RM betrachten und ausgestalten.
- Effiziente Tool-Unterstützung für Requirements-basiertes Testen aufbauen und klar auf die Stakeholder-Sichten und Abläufe ausrichten.
Die drei Beispielfälle veranschaulichen: Es lohnt sich, für den Testmanager das Requirements-Management voran zu trei-ben. Er fördert so auch die Situation des Testens und ver-bessert die Produktqualität. Zugleich stärkt er die Rolle des Testmanagements im Unternehmen und macht es zu einem wichtigen Bindeglied zwischen Business und Software-Ent-wicklung.
Der Autor
Dr. Andreas Birk ist Gründer und Principal Consultant von Software.Process.Management. Er hilft Organisationen, ihre Software-Prozesse optimal an den Ge-schäftszielen auszurichten.
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
Anzeige
Konferenz für Software Qualität24.–26. Mai 2011 | CCD Congress Center Düsseldorf
Lassen Sie den Funken überspringen
In 2011 wird die Konferenz unter dem Motto „Industrialisierung – Software-Qualität 2020“ stattfi nden.
Die Industrialisierung der Software schreitet immer weiter voran und wirft folglich Fragestellungen in diversenBranchen auf: Welche Methoden sind effi zient und kostengünstig? Welche Ideen und Visionen gibt es bzgl. Software-Qualität?
Finden Sie Ihre ganz persönlichen Antworten auf der iqnite 2011 Deutschland. Mehr dazu erfahren Sie unter:
www.iqnite-conferences.com/de
Rückblick CONQUEST
Auf der CONQUEST – der COnference on QUality Enginee-ring in Software Technology – treffen sich seit 1997 einmal jährlich hunderte Softwareentwickler, Programmierer, Tes-ter und Softwareberater, um sich über die wichtigsten Ent-wicklungen und Innovationen im Bereich Softwarequalität zu informieren und auszutauschen. Ziel der Konferenz ist es, in der Branche ein Bewusstsein für die Notwendigkeit von mehr Prozessqualität in der Softwareentwicklung zu schaf-fen und nach und nach verbindliche Standards im Bereich Softwarequalität zu etablieren, die Kunden mehr Zuverläs-sigkeit bieten können.
Die dreizehnte CONQUEST fand in diesem Jahr vom 20. bis 22. September in Dresden statt. Der aufstrebende IT-Stand-ort Sachsen bot die geeignete Umgebung für das neue, richtungsweisende Konzept, das 2010 auf der etablierten Konferenz initiiert wurde. Erstmalig beteiligten sich führen-de Unternehmen aus der Industrie aktiv an der Programm-gestaltung – Microsoft Deutschland war Platinum-Partner der diesjährigen CONQUEST –, sodass die intensive Ver-zahnung von Theorie und Praxis in der Softwarequalität noch besser gelingen konnte. Das neue Programm stieß bei den rund 300 Teilnehmern auf großes Interesse. In der interaktiven Expertenrunde sowie in über 50 weiteren Vor-trägen und Tutorials fanden sich zahlreiche Gelegenheiten zum intensiven Erfahrungsaustausch über neue Wege der Implementierung von Softwarequalität in der Praxis. Na-menhafte Keynote Speaker wie Dorothy Graham, die bri-tische Testing-Expertin, oder Ken Johnston, Principle Test Manager von Microsoft Bing!, unterstrichen die internati-onale Ausrichtung der Konferenz. Der Best Presentation Award ging in diesem Jahr an Chris Rupp und ihren Vortrag
„Systemanalyse auf den Punkt gebracht“. Für das Best Pa-per wurde Frank Salder mit seinen Ausführungen zu Test-mustern in der globalen Softwareentwicklung ausgezeich-net. Ein Highlight der besonderen Art bot in diesem Jahr außerdem das Social Event der CONQUEST, das bei allen
Teilnehmern auf großen Zuspruch traf: mit der Kutsche ging es auf zur Stadtrundfahrt durch das abendliche Elbflorenz Dresden und zum anschließenden Dinner ins italienische Dörfchen.
Das Programm der CONQUEST 2010 wurde eingerahmt von einer Ausstellung von Dienstleistern und Werkzeug-anbietern. Ein umfassendes Tutorial-Programm am ersten Tag bot verschiedene Einstiege in das Thema der Qualitäts-sicherung. So wurde beispielsweise über Testprozessver-besserung mit TPI-Next mit Graham Bath, ganzheitliches Projekt-Engineering mit dem Quality Risk Management Framework mit Daniel Simon und Frank Simon oder aber über das Testen mit Modellen im industriellen Umfeld mit Martin Beißer debattiert. Die technischen Beiträge zu Soft-wareentwicklungs- und Testprozessen, Software Entwick-lung und zu Requirements Engineering wurden ergänzt um eingeladene Beiträge zu agilen Methoden, zu funktionaler Sicherheit, Requirements Engineering in der Praxis, zur Evolution von Testautomatisierunglösungen, zum modell-basierten Testen, zu Zertifizierung und Projektmanagement als auch zu Medizinischer IT. Wie von vielen Teilnehmern bestätigt: Ein gelungenes Programm, das zur Diskussion und zu neuen Ansätzen für die eigene Arbeit angeregt hat.
Da 2011 zum nunmehr fünften Mal der World Congress for Software Quality stattfindet – in diesem Jahr in Shanghai – und das International Software Quality Institute sich mit Freude der Betreuung und des Programmvorsitzes der De-legation Europa, Nahost und Afrika für den 5. WCSQ ange-nommen hat, wird die CONQUEST zum nächsten Mal im Jahr 2012 stattfinden. Wir freuen uns in der Zwischenzeit auf einen erfolgreichen 5. Weltkongress, zu dem Sie herz-lich eingeladen sind.
Weitere Impressionen finden sie unter: www.conquest-conference.org
CONQUEST 2010 – Reflektionen des Program Commitee Chairs Prof. Dr. Ina Schieferdecker
Ausgabe 17 | Dezember 2010 16
STA
ND
: Dez
embe
r 20
10
Datum Tage Schulungstitel Ort Anbieter
01.12.10 3 ISTQB® Certified Tester, Foundation Level Berlin qme Software GmbH
06.12.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. Logica Deutschland GmbH & Co. KG
06.12.10 3 iSAQB® Certified Professional for Software Architecture München Method Park Software AG
06.12.10 4 ISTQB® Certified Tester, Foundation Level Hamburg Method Park Software AG
06.12.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. SQS AG
06.12.10 4 ISTQB® Certified Tester, Foundation Level Dresden SQS AG
06.12.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Köln SQS AG
06.12.10 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5; englisch) Frankfurt a.M. SynSpace GmbH
07.12.10 3 ISTQB® Certified Tester, Foundation Level Düsseldorf/Köln Díaz & Hilterscheid Unternehmsberatung GmbH
08.12.10 2 x 2 ISTQB® Certified Tester, Foundation Level (englisch) Basel SynSpace AG
13.12.10 5 ISTQB® Certified Tester, Advanced Level, Test Manager Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
13.12.10 4 ISTQB® Certified Tester, Foundation Level Hamburg Logica Deutschland GmbH & Co. KG
13.12.10 1 ISTQB® Certified Tester, Advanced Level, Test Manager Köln SQS AG
13.12.10 4 ISTQB® Certified Tester, Foundation Level München SQS AG
13.12.10 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Hamburg SQS AG
13.12.10 3,5 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. TESNET GROUP GMBH
13.12.10 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Basel SynSpace AG
14.12.10 3,5 ISTQB® Certified Tester, Foundation Level Wiesbaden Muth Partners GmbH
15.12.10 3 ISTQB® Certified Tester, Foundation Level München sepp.med gmbh
15.12.10 3 ISTQB® Certified Tester, Foundation Level Berlin qme Software GmbH
10.01.11 4 ISTQB® Certified Tester, Foundation Level Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
12.01.11 3 ISTQB® Certified Tester, Foundation Level Berlin qme Software GmbH
13.01.11 4 ISTQB® Certified Tester, Foundation Level Köln SQS AG
17.01.11 4 ISTQB® Certified Tester, Foundation Level Köln Logica Deutschland GmbH & Co. KG
17.01.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager (englisch) Zürich SynSpace AG
17.01.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Dublin ISCN Ltd.
19.01.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Wien ANECON Software Design und Beratung GmbH
24.01.11 3,5 ISTQB® Certified Tester, Foundation Level München TESNET GROUP GMBH
24.01.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
24.01.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Kornwestheim KUGLER MAAG CIE GmbH
24.01.11 4 iSQI® Certified Professional for Project Management München Method Park Software AG
25.01.11 4 ISTQB® Certified Tester, Foundation Level Erlangen Method Park Software AG
26.01.11 3 ISTQB® Certified Tester, Foundation Level Röttenbach sepp.med gmbh
26.01.11 3 TTCN-3® Testing and Test Control Notation Berlin Testing Technologies IST GmbH
27.01.11 2 x 2 ISTQB® Certified Tester, Foundation Level Bern SynSpace AG
27.01.11 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. SQS AG
28.01.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Köln SQS AG
31.01.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Hamburg Logica Deutschland GmbH & Co. KG
07.02.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Hamburg Logica Deutschland GmbH & Co. KG
07.02.11 3 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. Díaz & Hilterscheid Unternehmsberatung GmbH
07.02.11 3,5 ISTQB® Certified Tester, Foundation Level Hamburg Muth Partners GmbH
09.02.11 3 ISTQB® Certified Tester, Foundation Level München sepp.med gmbh
International Software Quality Institute
International Software Quality Institute
Schulungen 2010 / 2011Dezember 2010 - März 2011 (Auswahl – Alle Termine für das 1.Halbjahr 2011 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.
[Fortsetzung Schulungen 2011]
11.02.11 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Köln SQS AG
14.02.11 3 ISTQB® Certified Tester, Foundation Level Berlin qme Software GmbH
14.02.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. Díaz & Hilterscheid Unternehmsberatung GmbH
14.02.11 3,5 ISTQB® Certified Tester, Foundation Level Wiesbaden Muth Partners GmbH
14.02.11 4 ISTQB® Certified Tester, Foundation Level Wien ANECON Software Design und Beratung GmbH
14.02.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Hamburg Method Park Software AG
15.02.11 2 x 2 ISTQB® Certified Tester, Foundation Level Hamburg SynSpace GmbH
17.02.11 4 ISTQB® Certified Tester, Foundation Level Hamburg oose Innovative Informatik GmbH
21.02.11 3,5 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. TESNET GROUP GMBH
21.02.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Zürich SynSpace AG
21.02.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. SynSpace GmbH
21.02.11 4 ISTQB® Certified Tester, Foundation Level Wien OBJENTIS Software Integration GmbH
21.02.11 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
21.02.11 5 intacs™ certified ISO/IEC 15504 Competent Assessor (ISO/IEC 15504-5) Kornwestheim KUGLER MAAG CIE GmbH
21.02.11 3 ISTQB® Certified Tester, Advanced Level, Test Manager Berlin Method Park Software AG
21.02.11 4 ISTQB® Certified Tester, Foundation Level Hamburg Method Park Software AG
22.02.11 4 ISTQB® Certified Tester, Foundation Level München Logica Deutschland GmbH & Co. KG
25.02.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Köln SQS AG
25.02.11 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Hamburg SQS AG
28.02.11 5 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Stuttgart Logica Deutschland GmbH & Co. KG
28.02.11 3 ISTQB® Certified Tester, Advanced Level, Technical Test Analyst Erlangen Method Park Software AG
28.02.11 4 iSQI® Certified Professional for Project Management Hamburg Method Park Software AG
01.03.11 4 ISTQB® Certified Tester, Foundation Level (englisch) Basel SynSpace AG
03.03.11 4 ISTQB® Certified Tester, Foundation Level München SQS AG
07.03.11 4 ISTQB® Certified Tester, Advanced Level, Test Manager Frankfurt a.M. Logica Deutschland GmbH & Co. KG
07.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst München SynSpace GmbH
07.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager München Díaz & Hilterscheid Unternehmsberatung GmbH
07.03.11 5 intacs™ certified ISO/IEC 15504 Competent Assessor (ISO/IEC 15504-5) Graz ISCN Ltd.
07.03.11 3 Wo. ECQA® Certified Innovation Manager online ISCN Ltd.
07.03.11 3 Wo. ECQA® Certified E-Learning Manager online ISCN Ltd.
07.03.11 3 Wo. ECQA® Certified Software Process Improvement Manager online ISCN Ltd.
07.03.11 3 Wo. ECQA® Certified EU Project Manager online ISCN Ltd.
09.03.11 3 ISTQB® Certified Tester, Foundation Level Berlin qme Software GmbH
11.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Frankfurt a.M. SQS AG
14.03.11 4 ISTQB® Certified Tester, Foundation Level Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
14.03.11 3,5 ISTQB® Certified Tester, Foundation Level Bönnigheim Muth Partners GmbH
14.03.11 4 iSQI® Certified Professional for Project Management Erlangen Method Park Software AG
16.03.11 3 ISTQB® Certified Tester, Foundation Level Röttenbach sepp.med gmbh
16.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst (englisch) Wien ANECON Software Design und Beratung GmbH
17.03.11 4 ISTQB® Certified Tester, Foundation Level Köln SQS AG
21.03.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) München SynSpace GmbH
21.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Manager München SynSpace GmbH
21.03.11 5 ISTQB® Certified Tester, Advanced Level, Test Analyst Berlin Díaz & Hilterscheid Unternehmsberatung GmbH
21.03.11 5 ECQA® Certified Software Process Improvement Manager Erlangen Method Park Software AG
22.03.11 3,5 ISTQB® Certified Tester, Foundation Level Salzburg Muth Partners GmbH
23.03.11 3 TTCN-3® Testing and Test Control Notation Berlin Testing Technologies IST GmbH
24.03.11 4 ISTQB® Certified Tester, Foundation Level Hamburg SQS AG
28.03.11 3,5 ISTQB® Certified Tester, Foundation Level München TESNET GROUP GMBH
28.03.11 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. Logica Deutschland GmbH & Co. KG
28.03.11 4 ISTQB® Certified Tester, Foundation Level Frankfurt a.M. SynSpace GmbH
28.03.11 2 Agile Testing Training - Test und Testmanagement in agilen Projekten Wien ANECON Software Design und Beratung GmbH
28.03.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Kornwestheim KUGLER MAAG CIE GmbH
Datum Dauer Titel Ort Anbieter
01.12.10 2 Effiziente Testautomatisierung mit TTCN-3 – Grundlagen und Anwendungen Erlangen Fraunhofer FOKUS
01.12.10 3 TOSCA Testsuite™ Certified User Advanced Level Wien TRICENTIS Technology & Consulting GmbH
02.12.10 2 Testmanagement auf Basis von HP Quality Center 10.0 Berlin QMETHODS - Business & IT Consulting GmbH
03.12.10 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH
06.12.10 1 Funktionale Sicherheit von sicherheitsbezogenen HW/SW-Systemen Röttenbach sepp.med gmbh
06.12.10 5 Praktische Softwarearchitektur Hamburg oose Innovative Informatik GmbH
09.12.10 2 Nutzerorientierte Anforderungsanalyse: User Research Potsdam D-LABS GmbH
09.12.10 2 Usability Engineering Berlin qme Software GmbH
10.12.10 3 Agiles Requirements Engineering Hamburg oose Innovative Informatik GmbH
13.12.10 5 Das Analytiker-Seminar mit UML Hamburg oose Innovative Informatik GmbH
13.12.10 3 SEI autorisiertes CMMI®-DEV Einführungstraining v1.2 Kornwestheim KUGLER MAAG CIE
13.12.10 4 Testgetriebene Softwareentwicklung Hamburg oose Innovative Informatik GmbH
14.12.10 2 Testmethodik für Software Entwickler München GQ-Solutions
15.12.10 3 Einführung in das Capability Maturity Model (CMMI®DEV v1.3) München Anywhere.24 GmbH
16.12.10 2Kennzahlen als Grundlage für die Business Intelligence-Umsetzung auf Basis von IBM Cognos 8
Berlin QMETHODS - Business & IT Consulting GmbH
16.12.10 1 Services Supplement for CMMI® v1.3 Kornwestheim KUGLER MAAG CIE
17.12.10 1 Effiziente Projektarbeit durch strukturierte Nutzergruppenbeschreibungen Potsdam D-LABS GmbH
20.12.10 3 Einführung in CMMI® for Services (SVC v1.3) München Anywhere.24 GmbH
10.01.11 1 Erfolgsrezept Prototyping Potsdam D-LABS GmbH
17.01.11 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag & Zertifizierung) Hamburg oose Innovative Informatik GmbH
17.01.11 5 Certified Scrum Master und Führen als Scrum Master Hamburg oose Innovative Informatik GmbH
20.01.11 2 Implementierung und Test auf Basis des SAP Solution Manager 7.0 Berlin QMETHODS - Business & IT Consulting GmbH
20.01.11 2 Requirements Engineering Berlin qme Software GmbH
21.01.11 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH
24.01.11 1 Einführung in die Systems Modeling Language (SysML) Röttenbach sepp.med gmbh
25.01.11 3 Requirements Engineering und Systems Engineering mit SysML (RESESysML) Röttenbach sepp.med gmbh
27.01.11 1 Generierung von Testdaten für WhiteBox- und BlackBox-Tests Berlin QMETHODS - Business & IT Consulting GmbH
31.01.11 5 Agiles Software-Projektmanagement Hamburg oose Innovative Informatik GmbH
31.01.11 2 Agiles Testen Hamburg oose Innovative Informatik GmbH
01.02.11 3 SEI autorisiertes CMMI®-DEV Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE GmbH
04.02.11 1 Services Supplement for CMMI® V1.2 (Dienstleistungs-Ergänzung für CMMI® V1.2) Kornwestheim KUGLER MAAG CIE GmbH
07.02.11 4 Java für fortgeschrittene Anwendungsentwickler Hamburg oose Innovative Informatik GmbH
07.02.11 3 Kommunikation & Moderationstechniken Hamburg oose Innovative Informatik GmbH
08.02.11 2Funktionale Sicherheit von softwarebestimmten Systemen / Sicherheitsrelevante Automotive Software
Kornwestheim KUGLER MAAG CIE GmbH
International Software Quality Institute
International Software Quality Institute
Seminare 2010 / 2011
Das iSQI fungiert hier als Vermittler.Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org
Dezember 2010 - März 2011 (Auswahl – Alle Termine für das 1.Halbjahr 2011 auf www.isqi.org/nc/seminare/programm)
28.03.11 4 ISTQB® Certified Tester, Foundation Level Stuttgart Method Park Software AG
28.03.11 5 intacs™ certified ISO/IEC 15504 Provisional Assessor (ISO/IEC 15504-5) Erlangen Method Park Software AG
29.03.11 3 ISTQB® Certified Tester, Foundation Level München Díaz & Hilterscheid Unternehmsberatung GmbH
Alle Themen auch als Inhouse-Angebot buchbar!
STA
ND
: Dez
embe
r 20
10
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 1991058 Erlangen
Tel +49 9131 91910-0Fax +49 9131 91910-10
David-Gilly-Straße 1 14469 Potsdam
Tel +49 331 231810-0Fax +49 331 231810-10
Ansprechpartner One Stop Agency Services:Franziska Böckenkamp
E-Mail: trainings@isqi.orgTel +49 331 231810-40
Irrtümer, Termin- und Preisänderungen vorbehalten. Es gelten die allgemeinen Geschäfts- und Preisbedingungen des jeweiligen Veranstalters.
[Fortsetzung Seminare 2010 / 2011]
09.02.11 3 TOSCA Testsuite™ Certified User Foundation Level Wien TRICENTIS Technology & Consulting GmbH
09.02.11 3 Last- und Performancetest auf Basis von HP LoadRunner 9.5 Berlin QMETHODS - Business & IT Consulting GmbH
10.02.11 2 Usability Engineering Berlin qme Software GmbH
14.02.11 2 Qualitätsmanagement in der agilen Software-Entwicklung Stuttgart sepp.med gmbh
14.02.11 3 Testgetriebene Softwareentwicklung Hamburg oose Innovative Informatik GmbH
15.02.11 1 Modellierung mit UML2 Röttenbach sepp.med gmbh
16.02.11 1 Einführung in die Simulation Röttenbach sepp.med gmbh
17.02.11 1 Funktionale Sicherheit von sicherheitsbezogenen HW/SW-Systemen Röttenbach sepp.med gmbh
17.02.11 2 TOSCA Testsuite™ Certified Administrator Wien TRICENTIS Technology & Consulting GmbH
17.02.11 2 Projekte erfolgreich steuern - Erfolgsfaktoren jenseits von Tools & Technik Berlin QMETHODS - Business & IT Consulting GmbH
21.02.11 1 Funktionale Sicherheit von sicherheitsbezogenen HW/SW-Systemen München sepp.med gmbh
21.02.11 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag & Zertifizierung) Hamburg oose Innovative Informatik GmbH
24.02.11 2 Testautomation auf Basis von HP QuickTest Professional 10.0 Berlin QMETHODS - Business & IT Consulting GmbH
25.02.11 1 Certified UML Professional Fundamental (Vorbereitung und Test) Hamburg oose Innovative Informatik GmbH
28.02.11 5 Das Analytiker-Seminar mit UML Hamburg oose Innovative Informatik GmbH
28.02.11 3 Agiles Requirements Engineering Hamburg oose Innovative Informatik GmbH
02.03.11 3 Einführung in CMMI® für Produktentwicklung (DEV v1.3) Zürich Anywhere.24 GmbH
03.03.11 2Service Desk und Change Request Management auf Basis des SAP Solution Manager 7.0
Berlin QMETHODS - Business & IT Consulting GmbH
07.03.11 2 Nutzerorientierte Anforderungsanalyse: User Research Potsdam D-LABS GmbH
09.03.11 3 TOSCA Testsuite™ Certified Quality Designer Wien TRICENTIS Technology & Consulting GmbH
14.03.11 3 Das modellzentrierte Testen München sepp.med gmbh
14.03.11 3 SEI autorisiertes CMMI®-DEV Einführungstraining Version 1.2 Kornwestheim KUGLER MAAG CIE GmbH
14.03.11 5 Agiles Software-Projektmanagement Hamburg oose Innovative Informatik GmbH
14.03.11 4 Java für fortgeschrittene Anwendungsentwickler Hamburg oose Innovative Informatik GmbH
17.03.11 2 Testmanagement auf Basis von HP Quality Center 10.0 Berlin QMETHODS - Business & IT Consulting GmbH
21.03.11 2 Requirements-Management mit HP Quality Center Stuttgart sepp.med gmbh
21.03.11 5 Certified Scrum Master und Führen als Scrum Master Hamburg oose Innovative Informatik GmbH
23.03.11 2 Agile Software-Entwicklung mit HP Quality Center umfassend unterstützen Stuttgart sepp.med gmbh
24.03.11 2 Leichtgewichtiges Anforderungsmanagement in der Praxis Berlin QMETHODS - Business & IT Consulting GmbH
24.03.11 2 Requirements Engineering Berlin qme Software GmbH
25.03.11 3 TOSCA Testsuite™ Certified User Advanced Level Wien TRICENTIS Technology & Consulting GmbH
25.03.11 1 Effiziente Projektarbeit durch strukturierte Nutzergruppenbeschreibungen Potsdam D-LABS GmbH
28.03.11 3 Einführung in CMMI® für Produktentwicklung (DEV v1.3) München Anywhere.24 GmbH
28.03.11 5 Paketangebot Einführung in CMMI-DEV+ACQ+SVC (v1.3) München Anywhere.24 GmbH
28.03.11 5 Objektorientierte Analyse und Design mit UML (inkl. UML-Tooltag & Zertifizierung) Hamburg oose Innovative Informatik GmbH
30.03.11 1 Funktionaler und Nicht-funktionaler Test von HW/SW-Systemen Röttenbach sepp.med gmbh
30.03.11 1 Erfolgsrezept Prototyping Potsdam D-LABS GmbH
31.03.11 1 TTCN-3 und UTP für Schnelleinsteiger Röttenbach sepp.med gmbh
31.03.11 1 Upgrate zu CMMI® für Akquisition/Beschaffung (ACQ v1.3) München Anywhere.24 GmbH
Alle Themen auch als Inhouse-Angebot buchbar!
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.
ExklusivEs AngEbot für AsQf-MitgliEdEr
Rufen Sie uns an und wir vermitteln Ihnen einen kostenlosen und unverbindlichen technischen Beratungstermin, wie Test Professional in Ihrem Unternehmen Ihre Testprozesse verbessern kann: +49 (0) 89 3176 5959 (Frau Ostrochovska) oder per Mail an vsinfos@microsoft.com
nie wieder “no-repro-bugs” BEIM TESTEN!
ENDLICH:
Zur Auswertung von IntelliTrace-Daten wird Visual Studio 2010 Ultimate benötigt. Weitere Informationen finden Sie unter www.microsoft.de/visualstudio.
mit Lab Management
Machen sie schluß mit no-repro-bugs: Alle informationen, Whitepaper und kostenlose testversionen finden Sie unter www.microsoft.de/visualstudio/qs
Microsoft ist Mitglied im ASQF
VisualStudioTestProfessional2010_Anzeige_Update_V01.indd 1 10.11.2010 13:54:09
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.
ExklusivEs AngEbot für AsQf-MitgliEdEr
Rufen Sie uns an und wir vermitteln Ihnen einen kostenlosen und unverbindlichen technischen Beratungstermin, wie Test Professional in Ihrem Unternehmen Ihre Testprozesse verbessern kann: +49 (0) 89 3176 5959 (Frau Ostrochovska) oder per Mail an vsinfos@microsoft.com
nie wieder “no-repro-bugs” BEIM TESTEN!
ENDLICH:
Zur Auswertung von IntelliTrace-Daten wird Visual Studio 2010 Ultimate benötigt. Weitere Informationen finden Sie unter www.microsoft.de/visualstudio.
mit Lab Management
Machen sie schluß mit no-repro-bugs: Alle informationen, Whitepaper und kostenlose testversionen finden Sie unter www.microsoft.de/visualstudio/qs
Microsoft ist Mitglied im ASQF
VisualStudioTestProfessional2010_Anzeige_Update_V01.indd 1 10.11.2010 13:54:09
Eine wesentliche Aufgabe des Testens ist, objektiv und beleg-bar ein bestimmtes Verhalten oder spezifische Charakteristika für eine Applikation nachzuweisen. Wenn ein System-Integra-tions-Test zum Beispiel ergibt, dass eine bestimmte Interak-tion mit einem anderen Teilsystem nicht funktioniert, so wird diese erzeugte Transparenz bei der weiteren Projektsteuerung verwendet: Kann das System trotzdem die nächste Teststufe – wenn vorhanden – beschreiten oder sogar live gehen? Oder müssen Nacharbeiten am System eingeplant werden?
Dem Testen kommt damit objektives, wahrhaftiges zu: So finden sich auch in der ISTQB-Definition rund ums Testen nur sehr deterministische und absolute Begriffe: Die Testdurch-führung ist dort z.B. als „Ausführung eines Tests für eine Komponente oder ein System [verstanden], der Ist-ergebnis-se erzeugt“. Der Test selbst wird als einer oder mehrere Test-fälle verstanden, der Eingabeparameter, erwartete Ergebnis-se sowie Nachbedingungen umfasst. Subjektive Deutungen und Interpretationen sind hier unerwünscht. Handelt damit jeder, der testet, zwangsläufig unabhängig, d.h. unabhängig von subjektiven Befindlichkeiten, Präferenzen etc? Spielt es also keine Rolle, ob ein System durch einen explizit als un-abhängig auftretenden Tester oder durch einen internen, jah-relangen Experten der Materie durchgeführt wird? Wenn das Testen auf die Testausführung beschränkt wird, so kann die-se Frage mit einem klaren „Ja“ beantwortet werden: Schließ-lich kann eine solche Testausführung grundsätzlich auch von Test-Automaten durchgeführt werden, und denen wird nie-mand eine Abhängigkeit absprechen.
Testen besteht heutzutage aber aus deutlich mehr Aktivitäten und Facetten, die in der Regel unter einem Qualitätsmanage-ment zusammengefasst sind. Testen umfasst demzufolge heute „alle Aktivitäten des Lebenszyklus […], die sich mit der Planung, Vorbereitung und Bewertung eines Softwarepro-dukts und dazugehöriger Arbeitsergebnisse befassen“ (ISTQB). Testen beinhaltet daher z.B. folgende Aktivitäten:
- Qualitätssicherung von Anforderungsdokumenten, z.B. um daraus später Testfälle abzuleiten, oder auch, um Fehler möglichst frühzeitig zu erkennen.
- Testen der Gebrauchstauglichkeit von Benutzungsoberflä-chen und Workflows.
- Testmanagement, d.h. auch die Planung, Überwachung und Kontrolle von Testaktivitäten.
Ist die Unabhängigkeit eines solchen Testens ebenso ein-fach gegeben? Klar ist, dass ein solches Testen sehr viel mehr Entscheidungsräume besitzt (z.B. welche Dokumente werden mit als Testbasis herangezogen, welche Testobjekte werden als besonders wichtig klassifiziert) und auch im kon-
kreten Vorgehen viel mehr Subjektivität erfordert (z.B. beim Prüfen von Anforde-rungen auf Vollständigkeit). Wer kann diese Aktivitäten unabhängig, d.h. objektiv und belegbar durchführen?Hier helfen Ergebnisse der Erkenntnistheorie: Eine wesentliche Erkenntnis dort ist der Irrtum anzu-nehmen, „die Menschen brauchten nur die Augen aufzuschlagen und könnten dann die Dinge um sich einfach anschauen.“ Vielmehr „ist die Wirklichkeit, die wir erfassen, schon immer interpretierte Wirklichkeit“. Jeder Blick ist demzufolge verstellt durch „die Befangenheit im Betrieb“. Die Befangenheit ist dabei keine bewusste Eigenart, sondern gegeben durch das „A priori unserer Wahrnehmung“, gegeben durch Erfahrung, Wissen, Kenntnisse etc. Im allgemeinen Sprachgebrauch wird dies als „Scheuklappenblick“, „betriebsblind“ oder „den Wald vor lauter Bäumen nicht sehen“ bezeichnet.1
Was bedeutet das für den Tester: Dass der Befangene und der Unabhängige aufgrund der unterschiedlichen A priori die Wirklichkeit, z.B. ein Anforderungsdokument, unterschiedlich wahrnehmen: Der Erkenntnistheorie zufolge bedeutet Wahr-nehmung (z.B. von Fehlern) ein „Aufmerken und Beachten“, im Gegensatz zum Anschauen und Betrachten. Und erfah-rungsgemäß kann dies nur geschehen, wenn etwas Neues, Unbekanntes, Unerfahrenes in die Erfahrungswelt eintritt. Je ausgeprägter also dieser A priori Spiegel eines Menschen ist, desto schwieriger wird Wahrnehmung (s. Abbildung). Das Phanomem kennt jeder aus dem daily business, oder sind die zwei Rechtschreibfehler in Phänomen und der Sprachen-
Unabhängigkeit im Testen: Nur Marketing oder idealer Ansatz? Frank Simon
Ausgabe 17 | Dezember 2010 22
Frank Simon
Abbildung
Im Fokus
23 Ausgabe 17 | Dezember 2010
wechsel aufgefallen? Einer, der nicht fortwährend deutsche und englische Texte liest, hätte hier etwas wahrgenommen, der „befangene“ Mensch nicht. Der A Priori Spiegel assimi-liert teilweise sogar die Wirklichkeit, damit Erfahrungen wie-derverwendet werden können.Die Kunst eines unabhängigen Testens liegt demzufolge im Zurücktreten und dem Abschalten eigener Interessen und Ziele, d.h. dem Abbauen des A Priori-Spiegels, ansonsten können keine objektiven, belegbaren Testergebnisse garan-tiert werden.Andere Disziplinen haben die Notwendigkeit des Zurücktre-tens schon lange erkannt und auch schon erfolgreich etab-liert: So gilt in den medizinischen Wissenschaften beispiels-weise die Doppelblindstudie als Königsweg, da hier weder der Patient noch der behandelnde Arzt noch der auswerten-de Statistiker kennen, welche Teilnehmer die echte und wel-che nur die Placebo-Behandlung erfahren. Unabhängigkeit wird hier durch Personen realisiert, die sich schlichtweg un-abhängig vom Gesamtkontext bewegen können.In der Judikative sind Befangenheitsanträge ebenso selbst-verständlich wie die allgemein akzeptierte Aussage, eine Au-towerkstatt sei keine unabhängige TÜV-Prüfstelle (und darf daher auch kein TÜV-Prüfsiegel herausgeben).Und beim Testen? Kann ein Entwickler nach Implementierung seinen Code testen und dabei seine eigene „Befangenheit“,
seinen a priori Spiegel ablegen? Kann ein alteingesessener Kollege, der das Geschäft seit Jahrzehnten beherrscht, An-forderungen auf Vollständigkeit testen und Testfälle ableiten, ohne dabei „befangen“ zu sein?Wenn die Aufgabe des Testens darin besteht, Qualität für ein bestimmtes Artefakt nachzuweisen, sollte folglich vielmehr Wert auf die Unabhängigkeit gelegt werden. Dies kann durch das bewusste Zurücktreten versucht werden, allerdings be-steht hier immer die Gefahr, dass bei der Suche nach dem individuellen Vorteil die Objektivität auf der Strecke bleibt. Oder aber es kann durch den temporären Zukauf externer Experten erfolgen, bei denen allerdings auch auf organisato-rischer Ebene die Unabhängigkeit sichergestellt sein muss: Kooperationen zwischen Unternehmen, Tochter-Mutterkon-zernverhältnisse oder auch persönliche Verstrickungen sind da kontraproduktiv.
[1] Prof. Dr. Otto Friedrich Bollnow: „Der Weg zur Anschauung – ein Beitrag zur Philosophie der Erkenntnis“, in Universitas, 36. Jg. 1981, S. 1137 - 1146
Dr. Frank Simon arbeitet seit 10 Jahren in der SQS AG und leitet dort seit 2008 die international agierende Research & Development Einheit. Er ist Programme Chair der iqnite 2011 Deutschland, der Konferenz für Software-Qualität und Tes-ten. Im kommenden Jahr steht die Konferenz unter dem Motto „Industrialisierung – Software-Qualität 2020“. www.iqnite-conferences.com/de
Der Autor
Softwaretest
Anzeige
Zielsicher zum ErfolgSQS, Ihr Seminaranbieter – erfahren und vielfältig
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.
SQS bietet Ihnen:
Zertifi zierungen – ISTQB®, IREB, iNTACSTM, iNTCCMTM, ECQA®, ISSECO, CMMI®, iSQI®
Seminare zu den Themen: – Microsoft Project für Testmanager– Effi zienter Einsatz von Reviews– Projektmanagement Offi ce– Test SPICE
Garantierte Seminartermine
Seminarpakete – maßgeschneiderte Weiterbildung
Praxistage zu allen Seminaren aus der Reihe ISTQB® Certifi ed Tester
Das gesamte Fortbildungsangebot der SQS fi nden Sie unter www.sqs.de/training_events.php
Anmeldung über seminarteam@sqs.de oder 02203 9154-17
SQS Software Quality Systems AG
Stollwerckstraße 11 | 51149 Köln | Telefon 02203 9154-17 | Fax 02203 9154-15
NEU
Anz Training SQ Magazin 210x136.indd 1 22.10.2010 15:51:28
Zielsicher zum ErfolgSQS, Ihr Seminaranbieter – erfahren und vielfältig
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.
SQS bietet Ihnen:
Zertifi zierungen – ISTQB®, IREB, iNTACSTM, iNTCCMTM, ECQA®, ISSECO, CMMI®, iSQI®
Seminare zu den Themen: – Microsoft Project für Testmanager– Effi zienter Einsatz von Reviews– Projektmanagement Offi ce– Test SPICE
Garantierte Seminartermine
Seminarpakete – maßgeschneiderte Weiterbildung
Praxistage zu allen Seminaren aus der Reihe ISTQB® Certifi ed Tester
Das gesamte Fortbildungsangebot der SQS fi nden Sie unter www.sqs.de/training_events.php
Anmeldung über seminarteam@sqs.de oder 02203 9154-17
SQS Software Quality Systems AG
Stollwerckstraße 11 | 51149 Köln | Telefon 02203 9154-17 | Fax 02203 9154-15
NEU
Anz Training SQ Magazin 210x136.indd 1 22.10.2010 15:51:28
Ausgabe 17 | Dezember 2010 24
Qualitätssicherung in der Software-Entwicklung ist nicht al-lein mit dem Test getan. Vielmehr beginnt mit der Erhebung der zu implementierenden Anforderungen auch die Arbeit eines Testberaters. Sein Ziel ist es, für den gesamten Le-benszyklus der Software, alle Maßnahmen zu identifizieren, die bei der speziellen Applikation zu einem Höchstmaß an Qualität beitragen und die erfolgreiche Einführung in den Wirkbetrieb sicherstellen. Beginnend mit der Anforderungsphase des SW-Lebenszy-klus ist zu ermitteln, ob die Anforderungen überhaupt do-kumentiert vorliegen und wenn ja, ob diese interpretations-, widerspruchsfrei, vollständig, verständlich und redundanz-frei formuliert wurden. Ist die schriftliche Anforderungserhe-bung mit den genannten Eigenschaften gegeben, können von diesen mit hoher Wahrscheinlichkeit auch adäquate Testfälle abgeleitet werden. Ob dies der Fall ist, ist Bestand-teil der Analyse innerhalb der Testberatung. Aber nicht nur die mögliche Ableitung des Testdesigns ist in der Anforde-rungsphase für die QS in der Software-Entwicklung ein Ana-lyseaspekt sondern auch die Prüfung, welche Testarten im
späteren Lebenszyklus heran gezogen werden müssen, um die Realisierung der vom Kunden gewünschten als auch der impliziten, dem Kunden nicht offensichtlichen aber re-levanten Anforderungen nachzuweisen. Beispielhaft seien hier Usability-, Penetrations- und Lasttest genannt. Eine andere mögliche Untersuchung des Testberaters in der An-forderungsphase ist es, zu ermitteln, ob bestimmte Anfor-derungen mittels automatisierter Tests angegangen werden können. Dies macht vor Allem bei Applikationen mit lan-gen Entwicklungszyklen und mehreren Releases Sinn, um
bspw. durch Regressions-test sicherzustellen, dass durch Codeerweiterungen oder Bugfixing keine neuen Fehler in bereits erfolgreich getestetem Quellcode inte-griert wurden.
In der Phase Design, in der durch die Entwicklung Spe-zifikationen für die Imple-mentierung der Anforderun-gen erstellt werden, werden optimalerweise auch die Testspezifikationen erstellt. Hier wird die Testberatung bei-spielsweise in der Priorisierung der Testelemente tätig, um zu entscheiden, mit welcher Intensität und in welcher Reihenfol-ge diese abzuprüfen sind. Des Weiteren trägt der Testberater in dieser Phase Sorge, dass für sämtliche geplante Testar-ten alle relevanten Prüfkriterien berücksichtigt und schrift-lich fixiert sind. Als Ergebnis dieser Maßnahmen berät er bei
Evaluierung bzw. Auswahl der geeigneten Testumgebung und klärt die Bereitstellung der benötigten Testdaten ab.
Sind alle Vorarbeiten getan und die Entwicklung hat eine testbare Software-Version ausgeliefert, kann der ei-gentliche Test beginnen. Hier unterstützt die Testberatung bspw. bei der Ermittlung und Erhebung geeigneter Met-riken zur Bestimmung des Testfortschritts, der Testabde-ckung sowie des Fehlersta-tus, um jederzeit Transparenz bzgl. des Testens sicherzu-stellen.
Nach Testabschluss, bspw. wenn alle Abnahmekriterien erfüllt und der vereinbarte Fehler-Korridor erreicht wurde, kann die Software in den Livebetrieb überführt werden. In dieser sowie den zwei sich anschließenden Phasen des SW-Lebenszyklus ist es Aufgabe der Testberatung zu ana-lysieren, welche weiteren Verbesserungspotentiale nutz-bringend umgesetzt werden können. Denkbar sind hier z. B. Codeanalysen zur Bestimmung der Wartbarkeit / Er-weiterbarkeit der Applikation oder Performanceanalysen zur Optimierung der Laufzeit. Die o.g. Beratungsaufgaben
Aus dem Leben eines Testberaters Ute Seidel
Ute Seidel
Abbildung 1: Ermittlung Status Quo - Qualitätscheck Testvorgehen
Im Fokus
25 Ausgabe 17 | Dezember 2010
lassen sich am Einfachsten bei Kunden anwenden, die be-reits über ein Testvorgehen verfügen. Da es aber auch eine Reihe von Unternehmen gibt, die gerade beginnen, sich mit dem Thema Test zu befassen oder dieses optimieren wollen, ist für die Testberatung ebenfalls ein Hauptbestand-teil ihrer Aktivitäten einen auf das Unternehmen adäquat zugeschnittenen Testprozess zu designen bzw. zu überar-
Die Wirtschaftsinformatikerin Ute Seidel ist als Consultant im Test and Integration Center der T-Systems Multimedia Solutions GmbH tätig und besitzt umfassendes Know-how zum Qualitäts- und Prozessmanagement.
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
Die Autorin
Abbildung 2: Application Lifecycle
Softwaretest
Unsere Firma spart bis zu
60% an Schulungskosten durch Online Training.
Die gewonnenen Kenntnisse und die Einsparungen sichern die Wettbewerbsfähigkeit unseres
Unternehmens.
www.te-trainings-shop.com
online trainingISTQB® Certified Tester Foundation Level (englisch & deutsch)ISTQB® Certified Tester Advanced Level - Test Manager (englisch)ISTQB® Certified Tester Advanced Level - Test Analyst (englisch)ISTQB® Certified Tester Advanced Level - Technical Test Analyst (englisch)
© iS
tock
phot
o/Yu
ri_Ar
curs
Anzeige
beiten und einzuführen. Um zu ermitteln, wie dieser opti-mal auszugestalten ist, führt der Testberater entweder ein TPI-Assessment oder einen Kurzcheck im betreffenden Un-ternehmen durch, dem sich die in der Grafik (Abbildung 1) skizzierten Folgeaktivitäten anschließen. Unternehmen, die bereits über einen Testprozess verfügen, nun aber vor der Herausforderung stehen, ein eigenes Testlabor etablieren zu wollen, können ebenfalls Anleitung und Unterstützung durch die Testberatung erfahren.
Im Fokus Ausgabe 17 | Dezember 2010 26
Die TestSPICE IdeeInternationale Testprozessexperten aus Wissenschaft, Software-Firmen mit spezialisierten Testabteilungen, Test-Dienstleister und Test-Beratungsfirmen haben sich in der TestSPICE Special Interest Group (TestSPICE SIG) zusam-mengeschlossen und erarbeiten ein SPICE konformes Test-prozess-Assessmentmodell zur schrittweisen Verbesserung von Testprozessen. Testabteilungen, die ihre Prozesse nach TestSPICE verbessern, optimieren ihre Dienstleistung unter anderem für solche Entwicklungsabteilungen, die sich an ISO/IEC 15504-5 (SPICE) oder AutomotiveSPICE® orientie-ren.
Die Motivation für TestSPICEDer Standard ISO/IEC 15504 (SPICE) ist insbesondere im Bereich der Entwicklung Software basierter Systeme zur do-minierenden Prozessbewertungsmethode in Europa gewor-den. Das SPICE Modell ist so konstruiert, dass es für einen spezifischen Anwendungsbereich erweitert werden kann. Das für diesen Bereich spezifische Prozess-Wissen wird hinsichtlich Prozess-Struktur samt Prozess-Zweck und Pro-zess-Ergebnissen in einem Prozess-Referenz-Modell (PRM) zusammengefasst. In einem Prozess-Assessment-Modell (PAM) werden diese Angaben erweitert, beispielsweise um Best-Practices von Aktivitäten und Dokumenten je Prozess. Inzwischen sind eine Reihe von PRMs und PAMs verfügbar. Das aktuell am häufigsten verwendete Modell ist Automo-tiveSPICE®. Es wird zur Bewertung und Verbesserung der Automotive-Entwicklungsprozesse verwendet, sowohl bei Lieferanten als auch bei Fahrzeugherstellern.
Im Test-Business sind die Vorgaben der bisherigen SPICE konformen Prozess-Assessment-Modelle zwar richtig und wichtig (und daher grundlegend), aber oft nicht umfassend genug bezüglich einer Reihe von Aspekten zur Optimierung von Testdienstleistungen. Daher sind im Testumfeld andere Modelle als Grundlage für Prozessverbesserungen bekannt: TPI® NEXT und TMMI®. Zudem existieren verschiedene Sys-teme für die Fortbildung zu Testexperten wie beispielsweise ISTQB, das zumindest in Deutschland als de-facto Standard gilt und ein eigenes Prozessmodell beinhaltet. Diese Test-Prozessmodelle spiegeln das Prozess-Wissen dieser Do-mäne wider, aber in unterschiedlicher und zueinander nicht konformer Form. Zudem ist keine Assessment-Methode etabliert, die eine Vergleichbarkeit über Projekt- und Firmen-grenzen hinweg ermöglicht.
Was läge da näher, als diese zwei Welten zusammenzu-bringen: Einerseits die Welt der Test-Prozessmodelle samt dem Test-Domänen-Wissen und der diesbezüglichen Ex-pertise, und andererseits die Welt der etablierten Prozess-
bewertungsmethode ISO/IEC 15504 (SPICE) mit be-währtem Vorgehen, festen Bewertungsschema, Mess-rahmen und etablierten Be-deutung bestimmter Level der Prozesskapazität bzw. Reife. Dies ist die Idee von TestSPICE.
Die TestSPICE Special In-terest GroupEs geht aber nicht nur da-rum, zwei Welten zusam-menzubringen, sondern auch, die jeweiligen Experten-Com-munities an einen Tisch zu bringen. Von Anfang an wird auf eine möglichst breite Unterstützung geachtet, um gemein-schaftlich ein von vielen Experten getragenen Standard zur Bewertung und Verbesserung von Testprozessen zu erarbei-ten. Daher wurde am 27. Juli 2010 eine TestSPICE Special Interest Group (TestSPICE SIG) gegründet, eine internatio-nale Interessensgemeinschaft aus Testexperten, Prozessex-perten und Anwendern aus bisher fünf europäischen Staaten. Im Gründungsvertrag wurde festgehalten, dass der Zweck der TestSPICE SIG ist, gemeinsam ein TestSPICE PRM und PAM zu definieren und weiterzuentwickeln. Zudem werden Empfehlungen erarbeitet für die Erweiterung des bisherigen SPICE Assessor Zertifizierungsschemas um eine TestSPICE Assessor Zertifizierung, die auf angepassten Lehrplänen zu TestSPICE, gemeinsamen Schulungsunterlagen und eine eigene TestSPICE Assessoren Ausbildung basieren. Die TestSPICE SIG wird in ihrem Bemühen sowohl von Universi-täten unterstützt, um auf dem wissenschaftlichen Stand der Technik zu bleiben, als auch durch Firmen mit spezialisierten Testabteilungen, um die essentielle Praxisnähe beibehalten zu können und die Anwendbarkeit und Eignung der einzel-nen Prozesselemente validieren zu können. Die TestSPICE SIG hat sich entsprechend ihrer spezifischen Aufgaben in verschiedene Gruppen untergliedert (Abb. 1).
Das TestSPICE ModellTestSPICE unterstützt eine schrittweise Verbesserung der Testprozesse. Testabteilungen, die ihre Prozesse nach Test-
TestSPICE – SPICE für Testprozesse Christian Knüvener
Christian Knüvener
Abb. 1 - Struktur der TestSPICE SIG
27 Ausgabe 17 | Dezember 2010
SPICE ausrichten, optimieren ihre Dienstleistung unter ande-rem für solche Entwicklungsabteilungen, die sich beispiels-weise an ISO/IEC 15504-5 (SPICE) oder AutomotiveSPICE® orientieren. Zu den Kernanforderungen an das TestSPICE Modell gehören konsequenterweise sowohl die inhaltliche große Übereinstimmung zu den bestehenden Testexpertisen (siehe weiterführende Literatur), als auch die formale Kon-formität zu ISO/IEC 15504 Teil 2 (SPICE). Hervorzuheben ist beispielsweise der Prozess „TPM.7 Integrated Project Management“, indem der Fokus auf die systematische, pro-jektbezogene Zusammenarbeit mit dem Entwicklungsprojekt gelegt wird, in dem die zu testenden (Teil-)Produkte entste-hen (Abb. 2).
Der TestSPICE AusblickTestSPICE Version 0.9 (PRM und PAM) entstand aus der Konsolidierung einer ersten Konzept- und Reviewrun-de. Es wurde im August 2010 von der ISO/IEC Testpro-zess-Initiative in einer internen Präsentation als rele-vantes Dokument in betracht gezogen. TestSPICE wird aktuell vom International Assessor Certification Scheme e.V. (www.intacs.info) validiert und wird voraussichtlich noch die-ses Jahr als 3. valides SPICE Modell bestätigt. Gleichzeitig erfolgt ein intensives Review des PRM, indem weitere, inter-nationale Testexperten eingebunden werden. Wir erwarten eine Konsolidierung des Feedbacks und somit eine Aktua-lisierung des Modells bis Ende 2010. Für das erste Quartal 2011 ist ein umfangreiches Review des PAM geplant. Ab Sommer 2011 ist mit den ersten TestSPICE Erfahrungen in Form von Anwendungsberichten zu rechnen. Weitere Infor-mationen, beispielsweise über Möglichkeiten der Mitwirkung an der Ausgestaltung des Modells, können unter christian.knuevener@intacs.info erfragt werden. Veröffentlichungen werden künftig unter www.intacs.info verfügbar sein.
Weiterführende Literatur1. ISO/IEC15504-5 Information Technology–Process Assessment–
Part 5: An exemplar Process Assessment Model.2. ISTQB Standard glossary of terms used in Software Testing, Ver-
sion 2.1, 2010, http://istqb.dedicated.adaptavist.com/display/ISTQB/Home.
3. ISTQB Certified Tester–Foundation Level Syllabus, 2010, ISTQB.4. ISTQB Certified Tester, Advanced Level Syllabus, 2007, ISTQB.5. Michael Steiner, Monique Blaschke, Michael Philipp and Tomas
Schweigert Make test process assessment similar to software process assessment–the Test SPICE approach (JOURNAL OF SOFTWAREMAINTENANCE AND EVOLUTION: RESEARCH AND PRACTICE, Published online in Wiley Online Library (wiley-onlinelibrary.com). DOI: 10.1002/smr.507).
6. De Vries G., Visser B., Wilhelmus L.. TPI Next: Business Driven Test Process Improvement.
7. Sogeti. TPI® Next - Business Driven Test Process Improvement: Geschäftsbasierte Verbesserung des Testprozesses.
8. Pol M, Koomen T, Spillner A. Management und Optimierung des Testprozesses, Heidelbeg, dpunkt, 2000.
9. van Ewijk A, Linker B, van Oosterwijk M, Visser B, de Vries G, Wilhelmus L, Marselis R. TPI® Next, Business Driven Test Pro-cess Improvement. UTN Publishers’s-Hertogenbosch 2009.
10. Blaschke M, Philipp M, Schweigert T. The Test SPICE Approach, Test process assessments follow in the footsteps of software process assessments. Testing Experience 12/2009 S. 56ff.
11. Test Maturity Model Integration (TMMi) (TMMi Foundation, Versi-on 1.0, February 2008).
12. Bäro T. Analyse und Bewertung des Testprozesses von Automo-bilsteuergeräten, Dissertation, Karlsruhe, 2008.
13. Kömmerling T, Bäro T. PROVEtech:TP5 – A new PRM and PAM for assessing test processes, Stuttgart, SPICE Days 2010.
Christian Knüvener ist SEI zertifizierter CMMI Instructor, intacs autorisierter Trai-ner für AutomotiveSPICE® competent Assessor Kurse und Trainer für den ISTQB® Certified Tester Foundation Level. Er arbeitet mit im intacs Advisory Board, ASQF FG MM Board, Gate4SPICE Board, CLIB und TestSPICE SIG Steuerkreis. Seit 2005 arbeitet er bei Mercedes Benz technology (MBtech Group GmbH & Co. KGaA).
Diskutieren Sie mit uns zu diesem Thema in der ASQF XING-Gruppe unter www.xing.com/net/asqf !
Der Autor
Abb. 2 - Struktur von TestSPICE Version 0.9.3
Softwaretest
Im Fokus Ausgabe 17 | Dezember 2010 28
Zukünftiger Qualitätsstandard ISO/IEC 29119 als richtungweisendes MaßSchlüssig aufgebaut, transparent und ergebnisorientiert – zu Recht erfreut sich das V-Modell® XT 1.3, welches das Vor-gehen zur Planung und Durchführung von Systementwick-lungsprojekten beschreibt, breiter Zustimmung. Zudem ist es eines der wenigen Vorgehensmodelle, das konsequent ergebnisbasiert aufgebaut ist. Nachdem mit der aktuellen Version 1.3 eine schlüssige Gesamtstruktur vorliegt, wäre es ein weiterer Fortschritt, wenn die Autoren des V-Modells ihr Augenmerk in Hinblick auf mögliche Folgeversionen nun in-tensiver auf Qualitätsmanagement (QM), Qualitätssicherung (QS) und Test, sowie die Integration der Grundideen der Qua-litätsstandards ISTQB® Syllabus, IEEE 829 und insbeson-dere der kommenden ISO/IEC 29119 richten würden. Eine derartige Überarbeitung würde sich positiv auf typische Pro-jektrisiken im Qualitätssektor auswirken, für die das Modell bisher keine wirksame Dämpfung bereitstellt. Dieser Beitrag zeigt die Risiken sowie Möglichkeiten auf, diese Aspekte auf Projekt-, Organisations- und Modellebene zu adressieren.
Der feststehende Verlauf des V-Modells® XT gibt Anwendern eine klare Struktur für den Pro-jektablauf vor:Dabei zeigt das V-Modell® XT 1.3 übersichtlich die jeweiligen Produkte der einzelnen Akti-vitäten im Entwicklungsver-lauf auf. So lässt sich schnell erkennen, wie die jeweiligen Produkte von einander abhän-gen oder ob sie schon soweit abgeschlossen und verifiziert sind, dass die nächste Aktivi-tät auf Basis eines korrekten
Produkts eingeleitet werden kann. Betrachtet man das V-Modell aus der Qualitätssicht, so ergeben sich bereits in der operativen Projektabwicklung einige Aspekte, die es für ein erfolgreiches Projekt zu beachten gilt:Auch wenn mit der Version 1.3 des V-Modell® XT eine strin-gente und zusammenhängende Darstellung der Phasen (vgl. Abb. 1) erreicht ist, verbleiben für QM, QS und Test noch Verbesserungspotentiale mit dem Ziel, eine ganzheitliche Sicht auf das Thema Qualität und somit einen geschlosse-nen Qualitätsprozess zu ermöglichen.
Strukturelle VerbesserungspotentialeDie Suche innerhalb des V-Modell® XT 1.3 nach den Worten
„Test“ oder „Software Test“ ergibt auf Detailebene nur wenige Treffer. Ein Grund dafür ist unter anderem, dass im V-Modell nicht von „Testen“ sondern von „Prüfen“ gesprochen wird. An dieser Stelle ist aus Sicht des Testens eine Angleichung zwischen dem Sprachgebrauch im V-Modell® XT und dem
„ISTQB®/GTB Standardglossar der Testbegriffe“ wünschens-wert (aktuelle Version: http://www.german-testing-board.info/downloads/pdf/CT_Glossar_DE_EN_V21.pdf).
Zwar kennt das V-Modell® XT 1.3 den Vorgehensbaustein „Qualitätssicherung“, dieser liefert jedoch weder eine ge-
V-Modell® XT 1.3: Gut, aber weitere Verbesserungen möglich Martin Regenbogen, Tomas Schweigert
Tomas SchweigertMartin Regenbogen
Abb. 1: Phasen des V-Modells über Zeit und Detaillierung (Quelle: V-Modell)
Abb. 2: QS im V-Modell
Softwaretest29 Ausgabe 17 | Dezember 2010
schlossene Sicht auf QM, QS und Test, noch eine detaillierte Handlungsanleitung. Davon betroffen sind das QS-Hand-buch, der Prüfplan sowie die Prüfspezifikation und -prozedur als auch das Prüfprotokoll. Eine Lösung wäre hier die IEEE 829:2008 (IEEE Standard for Software and System Test Do-cumentation) als Quelle bzw. positives Beispiel nutzbar zu machen. Darüber hinaus fehlen für ein QM-Handbuch sowie die typischen organisatorischen Vorgaben wie Testrichtlinie und Teststrategie brauchbare Vorlagen: Die operativen Test-tätigkeiten sind nicht im Vorgehensbaustein QS, sondern in den Entwicklungsbausteinen adressiert, beispielsweise im Produkt „Implementierungs-, Integrations- und Prüfkonzept-System.“ Das mag zwar in der derzeitigen Struktur des V-Modell® XT 1.3 durchaus Sinn ergeben, verwehrt aber eine geschlossene Übersicht über QM, QS und Test. Zumal auch hier für die Vorlage der Hinweis auf die IEEE 829 gültig ist.
Zerklüftete ZuständigkeitenDer Vorgehensbaustein QS des V-Modell® XT 1.3 ist durch-aus stringent: Neben einem Verantwortlichen für QS, der sich u.a. für das QS-Handbuch verantwortlich zeichnet, sieht es einen Prüfer vor, der sich u.a. um die Prüfspezifikation küm-mert. Dennoch liegen Produkte wie das „Implementierungs-, Integrations- und Prüfkonzept-System“, die für den Test wesentlich sind, außerhalb dieses Vorgehensbausteins und werden vom Systemarchitekten erstellt. Abgesehen davon, dass Prüfen nicht in das Spezialgebiet von Systemarchitek-ten fällt, verdeutlicht diese Aufgabenverteilung das Verbes-serungspotential im V-Modell® XT 1.3 beim Thema Qualität: Die Anforderungen im QS-Handbuch (erstellt vom QS-Ver-antwortlichen) und die des Prüfkonzept-Systems (erstellt von einem Systemarchitekten) werden unabhängig voneinander festgehalten und gehen nicht Hand in Hand. Dieser fehlen-de Informationsfluss führt dazu, dass notwendige Prüfungen nicht oder nur unzureichend definiert oder entkoppelt vom Qualitätskapitel, wo sie nicht angewiesen sind, ausgeführt werden. An dieser Stelle ist eine stringentere Unterstützung gerade auch für die Organisationssicht in Testrichtlinie und Teststrategie wünschenswert.
Risiken für Organisationen, die das V-Modell® XT 1.3 nutzenHat der Auftraggeber eines Projekts, das nach V-Modell® XT 1.3 durchgeführt wird, weder eigene Expertise in QM, QS und Test, noch einen unabhängigen Dienstleister für diese Aufgaben, bestehen signifikante Risiken für Budget, Liefer-termin und Lieferqualität. Grund dafür sind zumeist schlecht beschriebene Anforderungen und eine unzureichende Test-abdeckung auf allen Integrationsstufen. Dies führt häufig zu einer Fehleinschätzung des Projektstatus und schließlich zu Qualitätsproblemen an der gelieferten Software.
Doch wie lässt sich das V-Modell® XT näher an den Anforde-rungen entsprechender Qualitätsstandards ausrichten?
Workarounds schaffen erste Abhilfe für ProjekteWie beschrieben, weist das V-Modell® XT 1.3 in QM, QS und Test noch Verbesserungspotentiale auf. Das sollte für Anwen-der jedoch kein Grund sein, im Projektalltag zu resignieren. Die gängigen Werkzeuge für Projektmanagement und Test Management können adäquate Unterstützung für QS und Test bereitstellen. Ein entscheidender Vorteil des V-Modell® XT 1.3 ist dabei, wie der Name XT = Extreme Tailoring schon sagt, dass es sich für einzelne Organisationen anpassen und auf individuelle Bedürfnisse zuschneiden lässt. Dazu verfügt die aktuellen Version 1.3 sowohl über ein Tailoring-Konzept als auch über ein Tailoring-Tool. Mit diesen lassen sich feh-lende Rollen, Produkte und Produktabhängigkeiten in das Modell einbringen. Der Anwender erhält so eine ganzheitli-che Sicht auf das Thema Qualität und dadurch auch eine höhere Wahrscheinlichkeit, dass ein Projekt glatt im Zeitplan und Budget verläuft.
Eine Orientierung, was ein derartiges Tailoring innerhalb des V-Modell-Vorgehens umfassen bzw. leisten sollte, bietet ein vergleichender Blick auf den derzeitigen Working Draft der ISO/IEC 29119:
Standardisierung langfristig notwendigTailoring kann zwar in individuellen Fällen Qualitätsprozesse gezielt optimieren, dennoch ist für mögliche Folgeversionen des V-Modell® XT eine standardisierte Beschreibung anzu-streben, d.h. eine Kompatibilität zu ISO/IEC 29119 bzw. zu dem „ISTQB®/GTB Standardglossar der Testbegriffe“, die den Aufbau einer funktionierenden Qualitäts- und Teststra-tegie ermöglicht. So können sich Testexperten, die zumeist nach ISTQB® zertifiziert sind, schnell im Modell zurechtfin-den und auf Organisations- und Projektebene umgehend produktiv werden. Voraussetzung hierfür ist das Bestücken der Vorlagen mit einer sinnvollen Inhaltsstruktur, analog zu IEEE 829 bzw. der kommenden ISO/IEC 29119 sowie einer (generischen) Vorgabe, welche Inhalte wann, wo und wie in-nerhalb eines Produkts erwartet werden.
Abb. 3: Der Testprozess nach ISO/IEC 29119 (Working Draft)
Im Fokus Ausgabe 17 | Dezember 2010 30
Anzeige
Grundsätzlich ist das V-Modell® XT 1.3 eine gute Basis für die Entwicklungsarbeit in Projekten. Ziel im weiteren Ausbau sollte es sein, die QS über den gesamten Entwicklungszyklus begleitend so sicherzustellen, dass die erzeugten Ergebnis-se den vereinbarten Anforderungen entsprechen und somit weiterverwendbar sind. Zwar lassen sich Qualitätsmankos im Rahmen von Workarounds bzw. der Entwicklung oder Fortschreibung eines organisationsspezifischen V-Modell®
XT 1.3 mit verfügbaren Tailoring-Mitteln bereinigen, dennoch ist langfristig eine Standardisierung und die Kompatibilität zur ISO/IEC 29119, die Testprozesse und grundlegende Er-gebnistypen definiert, erforderlich.
Die Autoren stellten ihre Erkenntnisse im November im Rah-men der jährlichen Konferenz VMEA des ANSSTAND e.V. vor, auf der Mitglieder und geladene Referenten Projekterfahrun-gen und Neuentwicklungen vorstellen und den Teilnehmern die Gelegenheit zum Erfahrungsaustausch und zur Diskussi-on gegeben wird. Der ANSSTAND e.V. bildet die Interessen-vertretung der Anwender des Systementwicklungsstandards V-Modell. Seit seiner Gründung 1993 bietet der Verein allen Interessierten eine Plattform zum Austausch von Erfahrun-gen rund um das V-Modell. Der ANSSTAND e.V. versteht sich als Forum für den Meinungs- und Informationsaustausch
zum V-Modell sowie Informationsbörse für aktuelle Informa-tionen, Veranstaltungshinweise und Aktivitäten rund um das Thema V-Modell. Zu den Mitgliedern gehören neben Anwen-dern des Standards auch eine Reihe der in den Standardi-sierungsgremien federführenden Institutionen und Unter-nehmen. Der ANSSTAND e.V. ist offen für Unternehmen und Einzelpersonen. Für Institutionen der öffentlichen Verwaltung gelten besondere Regelungen für die Mitgliedschaft.
Weitere Informationen sind auf der Webseite des ANSSTAND e.V. zu finden (www.ansstand.de).
EXCO The Quality Company – Ihr unabhängiger Spezialist für Qualitäts-sicherungsprojekte, spezialisiert auf das regulierte Medizintechnikumfeld.Das Automatisierte Testen von Software ist eines unserer Spezialgebiete.
Profitieren Sie von diesem Praxiswissen in unseren ISTQB® Certified Tester Foundation Level Schulungen!
ISTQB®
Unser Know-how für Ihren Erfolg!
Services for Industry, Business, R&D and Science
ISTQB ® Certified Tester Foundation Level
Nächste ISTQB® CTFL Schulung: 11.-14.04.2011Infos und Anmeldung: www.exco-services.com
Ihre Vorteile auf einen Blick:
• Einblick in das Automatisierte Testen
• Aktuelle Übungsbeispiele aus der Medizintechnik
• 10-jährige Praxiserfahrung im Testen
• Zertifizierung nach DIN EN ISO 13485
www.exco-services.com
SQ-Magazin-NEU.10.indd 1 05.10.2010 10:49:55 Uhr
Martin Regenbogen ist bei der SQS Software Quality Systems AG als Senior Consultant mit den Tätigkeitsschwerpunkten Prozessmanagement und Auditie-rung, Qualitätsmanagement und Testmanagement tätig. Er ist unter anderem zertifiziert als V-Modell®XT Pro und ISTQB® Certified Tester Advanced Level – Test Manager.
Tomas Schweigert ist seit 1991 Berater bei der SQS Software Quality Systems AG. Zu Beginn seiner Tätigkeit befasste er sich mit Testmethoden und Testma-nagement. Derzeit ist er als Senior Principal Consultant mit den Tätigkeitsschwer-punkten Prozessberatung, Prozessassessment, Coaching und Training tätig. Tomas Schweigert hält Zertifikate als V-Modell XT PING, intacs SPICE Principal Assessor und PMP.
Die Autoren
EXCO The Quality Company – Ihr unabhängiger Spezialist für Qualitäts-sicherungsprojekte, spezialisiert auf das regulierte Medizintechnikumfeld.Das Automatisierte Testen von Software ist eines unserer Spezialgebiete.
Profitieren Sie von diesem Praxiswissen in unseren ISTQB® Certified Tester Foundation Level Schulungen!
ISTQB®
Unser Know-how für Ihren Erfolg!
Services for Industry, Business, R&D and Science
ISTQB ® Certified Tester Foundation Level
Nächste ISTQB® CTFL Schulung: 11.-14.04.2011Infos und Anmeldung: www.exco-services.com
Ihre Vorteile auf einen Blick:
• Einblick in das Automatisierte Testen
• Aktuelle Übungsbeispiele aus der Medizintechnik
• 10-jährige Praxiserfahrung im Testen
• Zertifizierung nach DIN EN ISO 13485
www.exco-services.com
SQ-Magazin-NEU.10.indd 1 05.10.2010 10:49:55 Uhr
Klaus Pohl, Chris RuppBasiswissen Requirements EngineeringAus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level
2., akt. Auflage2010, 192 Seiten, FesteinbandE 29,90 (D)ISBN 978-3-89864-708-3
Softwareentwicklung & Projektmanagement
Henning Wolf, Wolf-Gideon Bleek
Agile SoftwareentwicklungWerte, Konzepte
und Methoden2., akt. und erw. Auflage2010, 216 Seiten, Broschur
E 29,90 (D)ISBN 978-3-89864-701-4
dpunkt.verlag GmbH · Ringstraße 19 B · D-69115 Heidelberg · fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: bestellung@dpunkt.de · www.dpunkt.de
Thomas Roßner, Christian Brandes, Helmut Götz, Mario WinterBasiswissen modellbasierter Test2010, 424 Seiten, FesteinbandE 42,90 (D)ISBN 978-3-89864-589-8
Harry M. Sneed, Ellen Wolf, Heidi Heilmann
Softwaremigration in der Praxis
Übertragung alter Softwaresysteme in eine
moderne Umgebung2010, 336 Seiten, Broschur
E 42,90 (D)ISBN 978-3-89864-564-5
Interessiert an E-Books?
www.dpunkt.de/ebooks
NEU
NEU
NEU QAMP-BroschüreLesen und lernen Sie mehr über QAMP! Aktion: Vom 6.12. bis 13.12. können Sie die QAMP-Broschüre (32 Seiten) kostenlos downloaden unter www.dpunkt.de/qamp
Klaus Pohl, Chris RuppBasiswissen Requirements EngineeringAus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level
2., akt. Auflage2010, 192 Seiten, FesteinbandE 29,90 (D)ISBN 978-3-89864-708-3
Softwareentwicklung & Projektmanagement
Henning Wolf, Wolf-Gideon Bleek
Agile SoftwareentwicklungWerte, Konzepte
und Methoden2., akt. und erw. Auflage2010, 216 Seiten, Broschur
E 29,90 (D)ISBN 978-3-89864-701-4
dpunkt.verlag GmbH · Ringstraße 19 B · D-69115 Heidelberg · fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99e-mail: bestellung@dpunkt.de · www.dpunkt.de
Thomas Roßner, Christian Brandes, Helmut Götz, Mario WinterBasiswissen modellbasierter Test2010, 424 Seiten, FesteinbandE 42,90 (D)ISBN 978-3-89864-589-8
Harry M. Sneed, Ellen Wolf, Heidi Heilmann
Softwaremigration in der Praxis
Übertragung alter Softwaresysteme in eine
moderne Umgebung2010, 336 Seiten, Broschur
E 42,90 (D)ISBN 978-3-89864-564-5
Interessiert an E-Books?
www.dpunkt.de/ebooks
NEU
NEU
NEU QAMP-BroschüreLesen und lernen Sie mehr über QAMP! Aktion: Vom 6.12. bis 13.12. können Sie die QAMP-Broschüre (32 Seiten) kostenlos downloaden unter www.dpunkt.de/qamp
www.isqi.org CERTiFYING PEOPLE
11% Rabattfür Frühbucher
ISTQB® Certified Tester, Foundation LevelISTQB® Certified Tester, Advanced Level ISEB® Intermediate Certificate in Software TestingiSQI® Certified Professional for Project ManagementV-Modell® XT ProiSAQB® Certified Professional for Software ArchitectureIREB® Certified Professional for Requirements EngineeringiNTACS™ certified ISO/IEC 15504 Provisional AssessoriNTACS™ certified ISO/IEC 15504 Competent AssessorTTCN-3® CertificateECQA® Certified Innovation ManageriNTCCM® Certified Professional for Configuration ManagementiSECMA® International Certified Professional for IT-Security ManagementISSECO® International Certified Professional for Secure Software EngineeringRFID ManagementQAMP® Quality Assurance Management Professional
BEGINNEN SIE DAS NEUE JAHR MIT EINEM LÄCHELN!
Die ersten 200 Teilnehmer, die sich für eine iSQI Prüfung im Januar 2011 registrieren, erhalten einen Frühbucherrabatt von 11%.
Zur Buchung kontaktieren Sie einfach unser Team:
certifi cation@isqi.org (Betreff: “2011”) oder unter +49 331 231810-24.
FG Safety33 Ausgabe 17 | Dezember 2010
TOSCA Certifi ed User Foundation Level:● 09.-11.02.2011● 13.-15.04.2011
TOSCA Certifi ed Quality Designer:● 09.-11.03.2011● 11.-13.05.2011
Öffentliche Trainings ● Termine Wien(Unterrichtssprache aller Termine: Deutsch)
TOSCA Testsuite™Elevates Software Testing to a business discipline
TOSCA Certifi ed Quality Designer:● 09.-11.03.2011● 11.-13.05.2011
TOSCA Certifi ed User Advanced Level:● 23.-25.03.2011● 08.-10.06.2011
TOSCA Certifi ed Administrator:● 17.-18.02.2011● 28.-29.04.2011
Anzeige
Auch im zweiten Jahr nach der Gründung erfreut sich die ASQF Fachgruppe Safety großer Beliebtheit. Allein im Raum Franken hatten mit bisher fünf Veranstaltungen zahlreiche In-teressierte die Möglichkeit, sich über die praktische Anwen-dung der verschiedenen Sicherheitsnormen zu informieren und auszutauschen.Zum Abschluss dieses Jahres können die Leiter und Promo-toren der Fachgruppe noch mit einem Highlight aufwarten: Bernd Gombert, Vice President Mechatronics der Schaeff-ler Gruppe, wird in seinem Vortrag „Entwicklung mechatro-nischer Produkte unter Berücksichtigung der Funktionalen Sicherheit“ am 9. Dezember 2010 über die enge Integration von Mechanik, Elektronik und Informationstechnik berichten.
Die Mechatronik eröffnet den Ingenieuren neue Wege in der Produktgestaltung. Ihre Aufgabe wird es sein, mechanisch einfach gestaltete und leichtgewichtige Produkte zu ermög-lichen und ihre Stabilität durch elektronische Regelungen zu gewährleisten. Die optimale Gesamtfunktion mechatro-nischer Systeme kann nur durch das ganzheitliche Zusam-menwirken elektronischer, informationstechnischer und mechanischer Komponenten entstehen, daher bekommt
die Funktionale Sicherheit einen immer größer wer-denden Stellenwert in der Entwicklung, um Verfügbar-keit und Funktionalität solch komplexer Systeme zu ge-währleisten.
Neben gut 180 internationa-len Patenten und rund 120 wissenschaftlichen Publika-tionen hält Gombert zahl-reiche Auszeichnungen, u.a. den Alfred-Kuhlenkamp-Preis für herausragende Leistungen in der Mechatronik, den Hermes Award, die Rudolf-Diesel-Medaille in Gold, sowie seit März 2009 das Verdienstkreuz am Bande der Bundesrepublik Deutschland für seine hervorragenden Ingenieurleistungen.
FG Safety Datum: 09.12.2010 ab 18 UhrOrt: Method Park Software AG, Wetterkreuz 19a, 91058 Erlangen, Anmeldung unter www.asqf.de
Echte Innovation lässt sich nicht aufhalten! Bernd Gombert
Bernd Gombert
TOSCA Certifi ed User Foundation Level:● 09.-11.02.2011● 13.-15.04.2011
TOSCA Certifi ed Quality Designer:● 09.-11.03.2011● 11.-13.05.2011
Öffentliche Trainings ● Termine Wien(Unterrichtssprache aller Termine: Deutsch)
TOSCA Testsuite™Elevates Software Testing to a business discipline
TOSCA Certifi ed Quality Designer:● 09.-11.03.2011● 11.-13.05.2011
TOSCA Certifi ed User Advanced Level:● 23.-25.03.2011● 08.-10.06.2011
TOSCA Certifi ed Administrator:● 17.-18.02.2011● 28.-29.04.2011
Mitglieder
Am 30. Oktober 2010 veranstalteten der ASQF und das Van der Valk Hotel Berliner Ring gemeinsam den 6. Berlin-Brandenburger Golfers Cup. Sich hinsichtlich des Networkings und Spaßes am sportlichen Wettkampf in die Tradition des ASQF Golf Cup einreihend, wurde diesmal auch für den guten Zweck in Gross Kienitz gespielt. Erstmals nahmen zahlreiche prominente Künstler und Sportler aus dem EAGLES Charity Golf Club e.V. teil, unter ihnen der Olympiasieger im Diskuswerfen Lars Riedel, der Weltmeister im Schwimmen Dr. Klaus Steinbach, der Weltmeister im Radfahren Rudi Altig, der Olympiasieger im Zehnkampf Christian Schenk, die Olympiasiegerin im Fünfkampf und Staatssekretärin a.D. Ingrid Mickler-Becker, der mehrfache Deutsche Meister und Champions League Gewinner des FC Bayern Mün-chen Franz Roth, der Schauspieler und Moderator Peter Bond sowie Box-weltmeister Sven Ottke. Letzterer bewies als Sieger des Golfturniers erneut Championsqualitäten: Mit insgesamt 27 Bruttopunkten sicherte er sich den Turniersieg. Den Nettosieg* holte sich in diesem Jahr Arnim Paschek. Den längsten Abschlag hatten Mario Stuck mit 246m und Ingrid Mickler-Becker mit 184m. Mit nur einem Schlag am nächsten an der Fahne lagen Manfred German (13,2m) und Christin Larkin-Peter (7,75m). Allen Gewinnern herz-lichen Glückwunsch!
Höhepunkt war in diesem Jahr die Übergabe von mehreren Spenden-schecks an Verbände und gemeinnützige Organisationen. Die Erlöse aus Galakarten, Tombola und vielen anderen Highlights des Abends kamen mehreren wohltätigen Projekten zugute. Zu ihnen zählen die Parkinson-hilfe Brandenburg, der Verein Pagasa Casalsagan e.V., der philippinische Kinder und Jugendliche bei der Ausbildung fördert und die Schulspeisung finanziert, sowie der Verein Disierto Florido e.V., der hilfsbedürftige Kinder in Argentinien unterstützt. Vielen Dank an dieser Stelle an die zahlreichen Sponsoren, die mit ihrem Engagement diese wohltätige Veranstaltung möglich gemacht haben.
* Bei der Nettowertung ist die erzielte Punkteanzahl abhängig vom Handicap
Begeistert: Kostenloses CONQUEST-Ticket!
Die diesjährige CONQUEST wartete für ASQF-Mitglieder mit einer Überraschung auf: Das kostenlose CONQUEST-Tagesticket nur für ASQF-Mitglieder. Möglich machte das eine neue Struktur der Konferenz in Zusammenarbeit mit den Ausstellern und Sponsoren. Nahezu 20 % der CONQUEST-Teilnehmer nahmen das ASQF-Ticket wahr und erlebten spannendes und neues Wis-sen zu Software-Quality an den Ufern der Elbe. Auch wenn es mit der Wette um den ASQF-Frankenexpress leider nicht geklappt hat, war die CONQUEST wieder einmal ein Begeisterungsfaktor! Einen Rückblick zur CONQUEST finden Sie in dieser Ausgabe auf Seite 16 oder unter www.conquest-conference.org.
Jubiläum: 15 Jahre ASQF und Präsidiumswahl
Das Jahr 2011 bietet wieder viele Mög-lichkeiten, sich aktiv zu treffen und auszutauschen. Eine davon ist die Mit-gliederversammlung im Frühjahr 2011. Präsidiumswahlen und ein großes Jubiläum geben Anlass genug für eine Reise nach Erlangen: 15 Jahre Software-Qualität und -Fortbildung aus Franken für die ganze Welt. Feiern Sie mit. Die Termine finden Sie zeit-nah unter www.asqf.de.
Boxweltmeister Sven Ottke gewinnt den ASQF-Wanderpokal
Ausgabe 17 | Dezember 2010 34
Boxweltmeister Sven Ottke (Mitte) erhielt als Siegerpokal den ASQF-Wanderpokal aus den Händen von ASQF-Geschäftsführer Stephan Goericke (li). Hoteldirektor Jan Polmann (re) gehörte zu den ersten Gratulanten.
Stephan Goericke mit den prominenten Teilnehmern. vlnr.: Frau Fleschenberger, Max Rieger, Franz Roth, Stephan Goericke, Ingrid Mickler-Becker, Alexander Pusch, Evi Mittermaier-Brundobler, Sven Ottke, Herbert Jung, Peter Bond, Marian-ne Kreuzer, Dr. Klaus Steinbach, Manfred Germar und Rudi Altig
Quiz
Wir suchen aufgeweckte Vor-, Mit- und Querdenker, die heute coole Software für morgen entwickeln!Sie gehen gerade Ihre ersten Schritte im Arbeitsleben oder sind bereits mehrere Jahre als Softwareexperte unterwegs?Internationale Projekte und knifflige Kunden anforderungen begeistern Sie? Wir freuen uns auf Ihre Bewerbung als Softwareentwickler (m/w) www.infoteam.de/jobs
So viele Zusendungen wie noch nie hat die Redaktion des SQ-Magazins zum Sudoku der letzten Ausgabe erhalten, aber nur fünf Teilnehmer können eines der begehrten Bücher „Basiswissen Medizinische Soft-ware“ gewinnen.
Die Gewinner lauten:Jörg Befard, MCS Arzt- und Ambulanzsysteme GmbH, Eltville
Sabine Buchholz, Lauf a. d. Pegnitz
Christian Crevecoeur, Thales Deutschland, Wilhelmshaven
Bernhard Glaser, how to organize GmbH, Potsdam
Thomas Kammerer, Astrum IT GmbH, Erlangen
Software ist Teamarbeit. Werden Sie Teil von infoteam Software.
empfiehlt „dilbert“ zur leichteren Alltagsbewältigung
Gewinner SQ-Magazin Nr. 16
Agile Softwareentwicklung bietet Methoden und Praktiken, die sich für eine Vielzahl von Softwareentwicklungsvorhaben einsetzen las-sen – oder aber für die Lösung eines Sudoku-Rätsels? Finden Sie es heraus. Das Buch „Agi-le Softwareentwicklung. Werte, Konzepte und Methoden“ von Henning Wolf und Wolf-Gideon Bleek, erschienen im dpunkt.verlag, führt in
die agile Sichtweise bei der Softwareentwicklung ein. Nach ei-nem Überblick über die Grundlagen agiler Werte und Konzepte wird agiles Vorgehen in der Softwareentwicklung auf den Ebenen Prozess, Management, Team und Programmierung betrachtet. Anhand von typischen Fragen und Problemen wird jeweils auf-gezeigt, wie diese mit agiler Softwareentwicklung gelöst werden. Eine Übersicht der prominenten agilen Methoden eXtreme Pro-gramming, Scrum, Feature Driven Development sowie Software-Kanban zeigt deren Schwerpunkte auf. Wenn Sie eines der fünf Bücher gewinnen wollen, dann schicken Sie das richtige Lösungswort bis 31. Januar an presse@asqf.de.
*Der Rechtsweg ist wie immer ausgeschlossen. Die Mitarbeiter der iSQI GmbH und des ASQF e.V. sowie sämtliche am Gewinnspiel beteiligten Personen sind von der Teilnahme ausgeschlos-sen. Teilnehmer erklären sich mit der Veröffentlichung Ihres Namens in der Folgeausgabe ein-verstanden.
7 1 3
4 9 5
9 4 8
6 5 4 1 8
1 7
5 3 6
2 1 7
6 2 1
3 6 9
Buchstaben: 1 = I, 2 = G, 3 = S, 4 = T, 5 = B, 6 = U, 7 = E, 8 = N, 9 = R
Lösungswort:
__ __ __ __ __ __ __ __ __ __ __ __
SUDOKU
35 Ausgabe 17 | Dezember 2010
Impressum
HerausgeberASQF e.V.Am Weichselgarten 19, 91058 ErlangenTel +49 9131 91910-0Fax +49 9131 91910-10
David-Gilly-Str. 1, 14469 PotsdamTel +49 331 231810-0Fax +49 331 231810-10info@asqf.de, www.asqf.de
RedaktionV.i.S.d.P.: Stephan Goericke (Geschäftsführer)
Redaktion: Jana Noack, Felix Winterpresse@asqf.de
Satz/Layout:Frenkelson Werbeagentur, Potsdam www.frenkelson.de
Fotos:ASQF e.V. und iSQI GmbHTitelbild: © Robert Kneschke - Fotolia.comSeite 34: © Van der Falk Hotel Berliner Ring
Alle Portraits und Grafiken mit freundlicher Genehmigung der Autoren.
Druck: te Neues, Kempen
Druckauflage: 3.000 Stück
Internetausgabewww.asqf.de/sqmagazin
MediadatenGern 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.
Haben Sie Anregungen zu den Inhalten des SQ-Magazins, dann schreiben Sie an:presse@asqf.de
Namentlich gekennzeichnete Beiträge müs-sen nicht mit der Meinung der Redaktion übereinstimmen. Die Redaktion behält sich das Recht auf sinngerechte Kürzung und Bearbeitung eingereichter Manuskripte vor.Wir machen darauf aufmerksam, dass Da-ten nicht an Dritte weitergegeben und aus-schließlich zur internen Auswertung heran-gezogen werden können.
Deze
mbe
r 201
0
FG Maturity Models Franken | 07.12.2010, Erlangen Gerhard Fessler, Method Park Software AGCMMI 1.3 - Evolution und Revolution
FG Safety Franken | 09.12.2010, Erlangen Bernd Gombert, Schaeffler Technologies GmbH & Co. KG
Entwicklung mechatronischer Produkte unter Berücksichtigung der Funktionalen Sicherheit
FG User Assistance Franken | 14.12.2010, Erlangen Michael Engler, Method Park Software AG„Usability Engineering für Medizin-Produkte -
Mehrwert durch die Erfüllung der IEC 62366 erzeugen“
FG Automotive, Franken | 16.12.2010, Röttenbach Jürgen Hartung, Kölsch & Altmann GmbH„CETES® - Kosteneffizientes Testen“
Janu
ar 2
011
FG Modellierung Franken | 20.01.2011, Erlangen N.N.
Vorankündigung
FG Software-Test Baden-Württemberg | 20.01.2011, Stuttgart Dr. Andreas Birk (Software.Process.Management)Methoden zum Vergleich von Modellen einschl. Änderungsmanagement auf Modellen
FG Software-Test Berlin-Brandenburg | 24.01.2011, Berlin Dipl.-Ing. Tibor Fakas, Match Technologies GmbH, Berlin„Automatisierte Reviews zur Erhöhung der Datenqualität im Entwicklungprozeß.“
FG Automatisierung Franken | 27.01.2011, Bubenreuth Thomas Debes, Leiter Maschinensoftware, manroland AG, Augsburg
Code-Generierung mit MATLAB/Simulink für Embedded Systeme mit Linux/Xenomai
FG Requirements Engineering Franken | 31.01.2011, Erlangen Andrea Paulsen, Bernhard Hertel , Siemens Health CareAnforderungen in der Partikeltherapie
Febr
uar 2
011
FG Software-Test Schwaben, Ulm | 09.02.2011, Neu-Ulm N.N.
Softwaremetriken zur Bestimmung des Testendes?
FG Maturity Models + Safety Rhein-Main | 10.02.2011, N.N. Vera Gebhardt, tec-mata GmbH
Aktivitäten zur Umsetzung von Anforderungen der ISO 26262.
FG Automatisierung Franken | 17.02.2011, Bubenreuth Alexander Beck, veo-TEC GmbH
Softwareunterstützung in der Instandhaltung – Oder: Warum es Alternativen zu Excel überhaupt gibt!
FG Software-Test Schwaben Baden-Württemberg | 17.02.2010, N.N. Dr. Erhardt Wunderlich (Bombardier Transportation GmbH)„Test Center und agile Tester: Ein Widerspruch?“
FG Maturity Models Franken | 23.02.2011 -
Vorankündigung
FG Software-Test Niedersachsen | 24.02.2011, Braunschweig Werner Beckmann, Bredex GmbH
AuftaktveranstaltungFG SoA, Berlin-Brandenburg, Berlin | 25.02.2011, Leipzig -
Besichtigung des DHL-Hub im Flughafen Leipzig.
Fachgruppentermine: Dezember 2010- Februar 2011DEZEMBER 2010 JANUAR 2011 FEBRUAR 2011
KW Mo Di Mi Do Fr Sa So KW Mo Di Mi Do Fr Sa So KW Mo Di Mi Do Fr Sa So
53 1 2 3 4 5 05 1 2 10 1 2 3 4 5 6
01 6 7 8 9 10 11 12 06 3 4 5 6 7 8 9 11 7 8 9 10 11 12 13
02 13 14 15 16 17 18 19 07 10 11 12 13 14 15 16 12 14 15 16 17 18 19 20
03 20 21 22 23 24 25 26 08 17 18 19 20 21 22 23 13 21 22 23 24 25 26 27
05 27 28 29 30 31 09 24 25 26 27 28 29 30 14 28
10 31
Die Preise und Formate für die Schaltung werblicher Beiträge wie Anzeigen oder Ad-vertorials bleiben unverändert. Sonderformen für Produkt- und Unternehmensmarke-ting auf Anfrage. www.asqf.de/kontakt-und-mediadaten.html
Mediadaten SQ-Magazin 2011
THEMEN UND TERMINE
März Juni September Dezember
„Medical IT“„die Zukunft des Softwaretestens“
„Softwarequalität / 15 Jahre ASQF“
„Qualität aus Anwendersicht“
Anzeigenschluss: 20.01.2011
Anzeigenschluss: 07.04.2011
Anzeigenschluss: 14.07.2011
Anzeigenschluss: 20.10.2011
Druckunterlagenschluss: 27.01.2011
Druckunterlagenschluss: 14.04.2011
Druckunterlagenschluss: 21.07.2011
Druckunterlagenschluss: 27.10.2011
top related