3. Was ist eine QM-Dokumentation und was muss da rein?

Was ist eine QM-Dokumentation und was muss da rein?

  • E

    Moin!

    Mein Chef kam gerade freudestrahlend ins Büro (böses Omen) und erklärte mir, dass in 3 Wochen QM-Prüfung sei und bis da hin mein Programm dokumentiert sein muss.
    Er braucht:
    - Programm auf CD (kein Problem)
    - Quellcodes ausgedruckt (hä? naja krieg ich schon hin)
    - Eine Dokumentation

    Auf genauere Nachfragen was eine Dokumentation ist, hat er immer wieder gesagt: "Ja, ich brauche eine Dokumentation."
    Ich hab dann gefragt, ob er wohl das Handbuch meint, aber das war es nicht. Auf weitere Nachfragen kam wieder und wieder: "Ja, eine Dokumentation eben."

    Waaaaaaaaah, was ist denn eine Dokumentation? 😕
    Was muss da rein? Hat jemand ein Beispiel für ein kleines Progrämmchen? So Taschenrechner oder so?

    Ich hoffe ihr habt ne Idee. Ich hb nämlich leider bisher nur viel über QM gehört aber die Qualifizierung nie zu Ende mitgemacht. 😞

    0
  • T

    Ich meine, mich dunkel erinnern zu können, dass wir im Studium in die QM Doku schreiben mussten, zu welchen Mitteln wir gegriffen haben, um bestimmte Qualitätsmerkmale in unsere Software zu bekommen.
    Irgendwie gab es da so eine Liste mit Merkmalen, die bei der Erstellung des Lastenhefts begann, über das verwendete Entwicklungsmodell ging und schlussendlich noch solche Dinge wie Reviews und Tests beinhaltete.

    Keine Ahnung, ob Dir das irgendwie weiterhilft.
    😕

    0
  • E

    Es hilft mir insofern weiter, dass meine Befürchtungen dann zutreffen würden. DAS ist nicht in drei Wochen zu schaffen. 😞

    Gibt es noch andere Ideen? Vielleicht welche die nicht in so umfangreiche Arbeit ausarten?

    0
  • T

    estartu schrieb:

    Gibt es noch andere Ideen? Vielleicht welche die nicht in so umfangreiche Arbeit ausarten?

    Dein (offensichtlich etwas verpeilter SCNR) Cheff gibt Dir ja leider keine sehr konkreten Anweisungen, was die QM-Doku beinhalten soll.
    Allgemein gibt es aber Richtlinien, und die beinhalten, wie ich fürchte, schon das, was ich oben erwähnt habe (und leider noch ordentlich viel mehr Zeugs über die gesamte Entwicklungszeitspanne).

    0
  • N

    Hm hab auch keine Ahnung was da genau gewollt ist, aber denke auch, dass du eben dokumentieren solltest welche Schritte du zur Qualitätssicherung durchgeführt fast (QS ist ja ein großer Teil von QM, was fälschlicherweise oft gleichgesetzt wird).
    D.h. ich würde hauptsächlich einfach dokumentieren was du für Tests (Unittests, Integrationstests, Systemtests usw.) durchgeführt hast. Und evtl. noch sonstige Richtlinien / Standards an die du dich gehalten hast.
    Aber ka ob das wirklich das ist, was gewollt ist.

    Sollte in der Zeit aber, ok je nach Größe des Projekts, schon machbar sein (sofern du dir schon vorher mal Gedanken über Tests gemacht hast bzw. auch wirklich getestet hast :D)

    0
  • B

    In den Anweisungen deines Chefs ist, zumindest so, wie du sie wiedergegeben hast, von "QM-Doku" überhaupt nicht die Rede. Eine QM-Prüfung soll wohl heißen, es kommt jemand von extern und prüft euer Qualitätsmanagement. Damit man da was zum Vorzeigen hat sollst du jetzt dein Programm dokumentieren, also grob gesagt das was es tun soll (Spezifikation) und wie es das tut (Entwurf). Da gibts Millionen von Möglichkeiten (UML ist sehr beliebt), am Ende kommt es eigentlich nur darauf an, dass man nicht in den Code gucken muss, um das Programm zu verstehen.
    Wenn du das aber erst für diese ominöse Prüfung erstellen sollst, scheint es bei euch nicht üblich zu sein, dass man sowas macht, richtig? Eine QM-Prüfung, die ihr Geld wert ist, wird sowas erkennen.

    Falls wirklich "QM-Doku" gemeint wäre, müsstest du jetzt aufschreiben, welche Maßnahmen und Prozesse es gibt, um Qualität sicherzustellen. Es scheint aber nicht deine Aufgabe zu sein, dir darüber Gedanken zu machen, deshalb kann es das nicht sein.

    0
  • E

    Bashar schrieb:

    In den Anweisungen deines Chefs ist, zumindest so, wie du sie wiedergegeben hast, von "QM-Doku" überhaupt nicht die Rede. Eine QM-Prüfung soll wohl heißen, es kommt jemand von extern und prüft euer Qualitätsmanagement.

    Genau das heißt es. Die Läden (wo das Programm genutzt wird) wurden letztes Jahr zertifiziert. Ich wurde damals außen vor gelassen um mir die Arbeit zu ersparen.

    Bashar schrieb:

    Damit man da was zum Vorzeigen hat sollst du jetzt dein Programm dokumentieren, also grob gesagt das was es tun soll (Spezifikation) und wie es das tut (Entwurf). Da gibts Millionen von Möglichkeiten (UML ist sehr beliebt), am Ende kommt es eigentlich nur darauf an, dass man nicht in den Code gucken muss, um das Programm zu verstehen.

    Okay, ich hoffe UML ist intuitiv. Ich plane normalerweise auf Zetteln und die fliegen wenns fertig ist in die Tonne. Ergo: Ich habe so gut wie nix.
    Was es tun soll habe ich gaaaaanz früher mal ausgearbeitet aber später leider aufgrund von Zeitmangel nicht mehr an aktuelle Änderungen angepasst. Hat mir der Chef untersagt, er meinte, ich soll mich auf das Programmieren konzentrieren.

    Bashar schrieb:

    Wenn du das aber erst für diese ominöse Prüfung erstellen sollst, scheint es bei euch nicht üblich zu sein, dass man sowas macht, richtig? Eine QM-Prüfung, die ihr Geld wert ist, wird sowas erkennen.

    Nein, weder Dokumentation noch Handbücher sind hier üblich. Ich hab ne kleine Doku am laufen über das eine oder andere - und den Rest im Kopf und im Code.
    Wie schon gesagt, wurde mir alles was nicht direkt coden ist untersagt, weils zu viel Zeit frisst. 🙄

    Bashar schrieb:

    Falls wirklich "QM-Doku" gemeint wäre, müsstest du jetzt aufschreiben, welche Maßnahmen und Prozesse es gibt, um Qualität sicherzustellen. Es scheint aber nicht deine Aufgabe zu sein, dir darüber Gedanken zu machen, deshalb kann es das nicht sein.

    Hm, na ich hoffe mal das Beste. 🙂

    0
  • E

    nep schrieb:

    Hm hab auch keine Ahnung was da genau gewollt ist, aber denke auch, dass du eben dokumentieren solltest welche Schritte du zur Qualitätssicherung durchgeführt fast (QS ist ja ein großer Teil von QM, was fälschlicherweise oft gleichgesetzt wird).
    D.h. ich würde hauptsächlich einfach dokumentieren was du für Tests (Unittests, Integrationstests, Systemtests usw.) durchgeführt hast. Und evtl. noch sonstige Richtlinien / Standards an die du dich gehalten hast.
    Aber ka ob das wirklich das ist, was gewollt ist.

    Wenns das wäre, hätte ich z.B. mit den Tests ein Problem. Klar hab ich getestet. Ohne Ersttest kommt mir nix in die Läden! Aber mit den Fachworten kann ich leider nichts anfangen, da ich mich damit nie genauer beschäftigt habe. Ich probiere aus, ob es das tut, was es soll. Wenn das geht, versuche ich es mit falschen Daten zum Absturz zu bringen. Wenn das nicht klappt, dann gehts an die Läden und die Benutzer dort finden halt das eine oder andere Fehlerchen. Das behebe ich dann, teste wieder und raus...
    Als ersten Schritt habe ich eine Liste meiner Bugfixes seit einem Jahr gedruckt. Aber ob das reicht?

    nep schrieb:

    Sollte in der Zeit aber, ok je nach Größe des Projekts, schon machbar sein (sofern du dir schon vorher mal Gedanken über Tests gemacht hast bzw. auch wirklich getestet hast :D)

    Wie schon oben geschrieben, getestet habe ich aber wie ich daraus nun Doku machen soll ist mir schleierhaft.
    Und das Projekt läuft jetzt gut 5 Jahre.

    0
  • P

    Also die QA und der Auftraggeber haben bei meinen letzten Auftrag soviel an Dokumenten für ein sog. SW DDR (Design Dokumenten Review) verlangten, das es auf keiner Kuhhaut ging.

    In der Forschung produzieren die nur Papier, Papier & Papier. So dass man sich die Frage stellen könnte, ob jemals ein fertiges Produkt herausfällt.

    Zum Bleistift:
    - SRS (SW Requirements Spec)
    - SDD (SW Design Document)
    - incl. SAD (SW Architecture Description)
    - SCD (SW Controlling Document)
    - SBC (SW Budget Controlling)
    - SDP (SW Development Plan)
    - SVP (SW Verification Plan)
    - SCP (SW Configuration Plan - CVS/Build/config/Doku List)
    - SCMD (SW Change Management Document)
    - API DOC (Doxygen)
    - TRT (Test Reports Templates)
    - SW PAP (Product (Quality) Assurance) Plan
    - SW PMP (Project Management Plan)
    - SW Action Item List (bääh)
    - SW FMEA (Failure Mode & Effects Analysis)
    - SRA (SW Reliability Analysis)
    - SFA (SW Feasibility Analysis)
    - SW Risk Management

    und natürlich alles schön verlinkt (Traceability) zu den System, SME (Subject Matter Experts) und UAN (Unterauftragnehmern) Specs in DOORS. War doch klar... 👍

    Die wollten Alles sehen, nur kein Code. Denn wir durften nicht eher anfangen, bis das alles fünffach abgezeichnet wurde und wunderten sich, dass am nächsten Tag bereits alles fertig gecodet und getestet war. 🤡

    Da machst Du gar nichts gegen...

    0
  • E

    Die Läden (wo das Programm genutzt wird) wurden letztes Jahr zertifiziert.

    Also bei einem QM-System gemäß ISO 9001 und evtl. anderen Normen/Regularien gibt es Vorgaben, die einzuhalten sind. Eure Software ist nun eben Bestandteil dieses Systems und muss genau diese Vorgaben erfüllen. Daher muss es zunächst am Interface zwischen euch und dem Kunden eine Spezifikation bezüglich der Software geben. Da sollten auch QM-Anforderungen aufgeführt sein. Solche sind z.B. Nachvollziehbarkeit (also keine späteren Manipulationen von Mess- und Prüfdaten, die man nicht vollständig nachspüren kann), Tests und Ergebnisse, um die Software auf Vollständigkeit und Richtigkeit zu prüfen. Falls die Software zu Prüfzwecken eingesetzt wird, muss diese die Anforderungen der Prüfmittelüberwachung erfüllen etc.

    Normalerweise müssen qualitätsrelevante Daten auch 10 Jahre sicher aufbewahrt werden können. Back-up Procedere und Archivierung muss daher stimmen. Lauter solches Zeug. Ganz schlimm wird es bei GMP.

    0
  • ?

    Moin

    iso9001 heist doch nur das man seine geschäftsprozesse zu dokumentieren hat. und wie die laufen ist dann egal. wen da dann drinsteht, das keine documentation gepflegt wird, dann gibts die auch nicht. wenn ohne spezifikation einfach drauf los entwickelt wird, dann ist das eben so. wenn änderungswünsche auch telefonisch, ohne schrifftliche notitz eingerecht werden können, zwar harstreubend, aber dann ist es so ... aber das sollte alles in einer Management Handbuch stehehn, das auch der belegschaft zugänglich sein sollte, sogar sein muss.

    aber zu deiner überschrift, QM Dokumentation ist für mich die Dokumentation der QS wie die Test Abzulaufen haben (Testplähne), was wie getestet werden soll, wie die Test ergebnisse aussahen, (Test Reports) Welche Fehler gefunden worden sind (BugReports), welche konsequenzen werden z.B. daraus gezogen; was war ursache z.B. 8d-reports (bei software wohl weniger), ..., welche Fehler wurden behoben (BugTracking, CVS, ...), .. die frage ist nur, was ist gefordert,

    somit solltest du noch mal klären was für eine QM prüfung das jetzt genau ist und was da vorzulegen ist. Docu kann nun mal viel sein.

    0. was für ein Aidit, Produkt audit (intern, extern), zetifizierungs audit
    1. welche Norm (ISO9001-xxxx, oder noch hässlicher).
    2. welches sind die für mich / das Projekt relevanten abschnitte der Norm
    3. was muss ich machen, um das was da steht/beschrieben ist zu erfüllen

    Deine änderungshistory ist doch schon mal gut, du hast änderungen, Fehler und erweiterungen dokumentiert. ob die nun nach beschreibung dokumentiert wurden, und ob das überhaupt einer sehen will?

    und da dein Projekt 5 Jahre läuft, die zertifizierung aber erst dieses bzw. letztes jahr lief, kann ja noch nicht alles nach norm gelaufen sein.

    gruss

    0
Anmelden zum Antworten