Montag, 26. November 2012

Der Untergang des Titanics aus der Perspektive eines Qualitaetssicherers

Der Fall "Titanic" ist laengst untersucht in allen Einzelheiten.
Also mache ich es kurz nur mit einigen Gedanken aus der Perspektive der Qualitaetssicherung.

Welche waren die Ursachen fuer das Unglueck?
Warum mussten Menschen sterben?
Ganz knapp sind 2 Tatsachen dafuer zu nennen:
1. Das Schiff fuhr zu schnell
2. Es gab nicht genug Rettungsboote fuer alle Passagiere

Und... Warum war das Schif zu schnell?
War der Kapitaen leichtsinnig?
Es war doch seine letzte Fahrt. Alt genug war er also und Erfahrung soll man ihm nicht absprechen. Und schnell soll er gewesen sein weil er einen neuen Rekord aufstellen wollte. So wird es zumindest berichtet. Glauben soll man es nicht unbedingt (wo so viele Sachen, die berichtet werden, oft -sehr oft- gelogen oder bestenfalls erfunden sind). Doch Leichtsinn moechte ich ihm (aufgrund seines Berufslebens) nicht bescheinigen. Warum war er dann zu schnell?
Und warum gab es fuer alle Passagiere nicht genug Rettungsboote?
Auch leichtsinn?
Ja...
Eine Antwort die zu beide Fragen passt und noch dazu schoen geschichtlich belegt ist, ist die, dass das Schiff als unsinkbar galt.
Wenn man oft genug eine idiotische Aussage hoert, dann glaubt man am Ende langsam daran.
Sogar ein alter Kapitaen scheint daran geglaubt zu haben. Er haette es besser wissen, naemlich: Alles sinkt, wenn der Schaden bloss gross genug ist.
Alles. Holz- und Metalschiffe. Einruempfige und mehrruempfige Schiffe, alles.
Wenn der Glaube, dass das Schiff "unsinkbar" war, die Grundlage fuer den Leichtsinn zu gelten hat, dann wuerde ich behaupten, dass die Qualitaetssicherung ganz miserabel gegenueber der Werbung und den Slogansmachern versagt hat.
Die ernuechtende Qualitaetssicherung-Aussage "Alles sinkt wenn der Schaden gross genug ist" wurde ausser Acht gelassen, verdraengt durch die (falsche aber werbewirksame) Aussage "unser Schiff sinkt nicht". Und alle Menschen scheinen es geglaubt zu haben. Auch die, die das eigene Leben aufs Spiel gesetzt haben.

Heutzutage gibt es mehr Regel und Gesetze, Schiffe muessen genug Rettungsboote fuer alle haben. So etwas kann eigentlich nicht mehr vorkommen.
Doch das Problem liegt, meiner Ansicht nach, daran, dass Werbeslogans mehr "gewicht" haben als nuechterndes Ingenieurwissen... schlimmer noch, sie haben mehr gewicht sogar als jahrelanges Berufswissen oder gar schlichter Vernunft.
Oder liegt es eher daran, dass ueber die Werbung nicht nachgedacht wird?
Oder daran, dass, wenn eine Aussage oft genug wiederholt wird, diese geglaubt wird, ohne nachzudenken?
Und, was damals geschah, kann sich doch jederzeit wiederholen.
Nur weil man nicht ueberlegt...
Qualitaetssichern bedeutet ueberlegen. Haette doch damals geholfen, denke ich.

Sonntag, 4. November 2012

REQB Pruefung Foundation Level - Ein Erfahrungsbericht

Die Pruefung sehr geradeaus, sehr an das Syllabus angelehnt. Die ersten 22 Fragen sehr einfach zu beantworten, "Negationen" sind mir nicht aufgefallen.
Nur selten hatte ich Schwierigkeiten, Fragen zu beantworten. Allerdings bin ich ziemlich suspect der Pruefung gegenueber gewesen, weil ich schon bei der ISTQB FL mir ziemlich sicher war, dass es gut gelaufen war; ich hatte doch auf etwa 95% richtige Antworten in den Mock Exams aus dem Internet, zwar waren die Fragen etwas anders in der wahren Pruefung, doch schwieriger kamen sie mir ueberhaupt nicht vor. Nun hatte ich aber "nur" 2 mehr richtig, als notwendig, und damit eigentlich die Pruefung mit "gerade ausreichend" bestanden. Man kann dazu bemerken, dass ich schon seit gut 12 Jahre bei der Qualitaetssicherung arbeite und vielleicht mehr auf Erfahrung als auf Wissen gesetzt habe. Ausserdem hatte ich schon auch bemerkt, dass die gleiche Frage in verschiedenen Mock Exams teils als falsch teils als richtig bewertet wurde. Nichtdestotrotz bin ich mit dem Ergebnis (meine Leistung) der ISTQB FL eher unzufrieden. Aus dieser Erfahrung heraus habe ich auch die REQB sehr "ordentlich" vorbereitet. Ausserdem gibt es im Internet gar keine Mock Exams fuer REQB und sonst keine Muster, so dass ich ganz und gar auf das Syllabus und anderen theoretischen Informationen mich verlassen musste. Dadurch bedingt habe ich auch die Fragen bei der Pruefung sehr genau gelesen.

Bei der Frage wo ich sehr unsicher war: Welche IEEE Norm gilt fuer die Spezifikation von System Funktionalitaet.
Nur unsicher war ich mir bei der Frage; wenn man dabei ist, einer "Solution Spec" zu schreiben, genauer "detailed high level req", und man hat schon das System definiert, die low-level req. spezifiziert, dokumentiert und aneinander in Relation gebracht u.s.w.; was macht man als Naechstes?
- REQ Analysis
- Solution modellieren
- Solution festlegen

Im letzten Teil der Pruefung jedoch, genauer REQ Analysis (auch "Tools" ganz am Ende mit nur 3 Fragen) ist mir aufgefallen, dass viele, viele Fragen mit Negationen behaftet waren, in der Art:
"Welche Aussage gilt NICHT fuer XY (wenn XZ) ?"
Da sollte man schon etwas genauer die richtige Antwort (die falsche) markieren.

Mehr als Definitionen von SysML und UML sollte man nicht wissen; OK, die Charakteristiken der beiden und die Unterschiede zwischen den beiden sollte man schon wissen.
Eine Frage war wohl; was fuer ein UML Diagramm man waehlen wuerde um die Stationen eines Dokuments in einem Document-Management-System darzustellen.
Das Gleiche ueber Agile Methoden... eine Frage gab es, dabei mussste man schon wissen was ein Backlog ist und was nicht.

Summa summarum: Meines Erachtens nach, wenn man erst das Syllabus durcharbeitet, (spricht auch die Fehler des Syllabus erkennen und beseitigen, dann das Richtige und Wichtige verstehen), dazu erstmals und zusaetzlich die Grundlagen von verwandten Themen wie UML (Modellierung) und Entwicklungsmethoden (Agile Methoden) durchlesen, dann hat man eine gute Basis, die Pruefung zu schaffen.

Hier kann man neine eigene Ueberarbeitung des Syllabus runterladen: Ich hatte die englische Version bearbeitet, die Kommentare jedoch sind auf Deutsch:
http://www.scribd.com/doc/110113815/reqb-syllabus