Dokumentation

Art und Umfang der Qualitätssicherung hängen immer vom Projekt ab. Sinnvollerweise wurde die Qualitätssicherung schon bei der Auftragsvergabe vereinbart, dann gibt es an dieser Stelle nicht mehr viel zu interpretieren.

Abhängig davon was mit der Qualitätssicherung überhaupt erreicht werden soll sind zwei Fälle zu unterscheiden:

Die konstruktive Qualitätssicherung arbeitet vorausschauend und trägt schon während der laufenden Arbeit zur Qualitätssicherung bei. Man kann damit versuchen Risiken für ein Scheitern des Projekts schon im Vorfeld auszuschließen.

Die analytische Qualitätssicherung ist eine messende Qualitätssicherung und misst die Qualität des Projekts oder Produkts zu festgelegten Zeitpunkten. Diese Zeitpunkte sind üblicherweise durch Meilensteine schon im Pflichtenheft vereinbart. Spätestens der Test vor der Abnahme sollte vereinbart sein und als analytische Qualitätssicherung auch dokumentiert werden (z.B. Messprotokolle, Checkliste).

Auf jeden Fall will der Prüfer von der IHK eine Qualitätssicherung sehen, auch wenn der Auftraggeber sie nicht gefordert hat, zumindest soll der Auszubildende daran gedacht haben. Diese Qualitätssicherung muss nachvollziehbar sein, es reicht natürlich nicht aus zu schreiben "ich habe alles ausprobiert und war zufrieden". Wenn Testdaten eingesetzt wurden, sollten diese auch in Art und Umfang erkennbar sein damit nachvollziehbar ist, ob sie den Testzweck erfüllen.

Die Qualitätssicherung sollte ehrlich und angemessen sein, ein- bis zwei Stunden darf man dafür mindestens in das Projekt verplanen. Beim Fachinformatiker Anwendungsentwicklung auch deutlich länger, da es dem Auftraggeber meist nicht möglich ist zu erkennen, welche Maßnahmen der Qualitätssicherung erforderlich und sinnvoll sind.

Jedes Fußballspiel beginnt mit dem Anstoß und jedes Projekt hat auch einen Anfang. Diesen Anfang sollt man klar definieren und er gibt einen guten Startpunkt in der Dokumentation vor.

Ein sogenanntes Kickoff-Meeting hat für fast jedes Projekt stattgefunden, oft ist man sich dessen aber gar nicht so sehr bewusst. Vielleicht war es nur ein kurzes Gespräch in der Pause, vielleicht hat einen der Chef auch zu sich gerufen, aber eins ist sicher: Der Kunde hat hier einen Wunsch geäußert, was er gerne haben möchte.

Dabei werden üblicherweise Notizen angefertigt, denn niemand kann sich alles merken, und hier etwas zu verwechseln oder zu vergessen ist später meist nur noch mit grossen Aufwand (sprich: Kosten) zu korrigieren.

Wenn man vorher weiß, dass ein neuen Projekt angeschoben werden soll, also ein Kickoff-Meeting ansteht, dann sollte man schon mal ein Flipchart bereitstellen wo die Ergebnisse notiert werden können. Das Papier kann man dann später abfotografieren oder zusammenfassen. Alternativ nimmt man ein Notebook mit und schließt es an einen Beamer an, in diesem Fall kann man Programme wie PowerPoint, Visio oder MindManager verwenden (sofern man sie beherrscht).

Schlau ist es an dieser Stelle zu zeigen, was man gelernt hat um ein Brainstorming festzuhalten: Ein Mindmap (mit dem Mindmanager) oder eine erste Use-Case-Analyse (mit einem UML-Tool) sind hier sicher geeignete Werkzeuge. Aber auch ein Lastenheft oder im einfachsten Fall ein paar Anforderungen in einer Notiz sind möglich, vielleicht gabs auch eine E-Mail, die das Projekt ausgelöst hat.

Auf jeden Fall ist es wichtig zu zeigen, wie man an die Wünsche des Kunden gelangt ist! Es muss für die Prüfer nachvollziehbar sein, welche Wünsche zu dem Projekt geführt haben um zu beurteilen, ob daraus vom Prüfling korrekt die richtigen Schritte abgeleitet wurden.

Die Analyse der Wünsche eines Kunden braucht schließlich auch noch Zeit; diese Zeit muss in der Planung wiederzufinden sein und die Kosten dem Projekt zugerechnet werden.