QM-Forum › Foren › Qualitätsmanagement › Formblätter für Softwareentwicklung
-
AutorBeiträge
-
Hallo,
meine QMB verlangt, dass alle Softwareentwicklungsergebnisse auf Formblättern aufgezeichnet werden (Softwareentwicklung nach 62304, QM nach 13485). Ich benutze nun für die Dokumentation der Softwareentwicklung (Anforderungsspezifikation, Softwaredesignspezifikationen, Risikoanalyse…) ein Werkzeug, was zwar ordentlich aussehende PDFs generiert, aber eben nicht in die von der QMB entworfenen Formblätter unter Word schreibt. Nun gibt es laufend Streit darüber, dass ich nicht die Formblätter genutzt hätte.Die QMB hat auch schon angekündigt, für die Hardwareentwicklungsergebnisse Formblätter entwerfen zu wollen. Ich bin mal gespannt wie wir dann Schaltpläne, Platinenlayouts und Stücklisten mit Word dokumentieren sollen…
Wie werden bei euch Entwicklungsergebnisse QM-gerecht dokumentiert?
Beste Grüße, Unicorn.
Servus,
man kann QM gegen die Praxis machen, Intelligent ist das nicht. Schließlich wird die Information von den Praktikern erzeugt und die Dokumentation muss in deren Workflow passen.
Umgekehrt muss die einmal erzeugte Dokumentation auch verwendbar und auswertbar sein – gerade Programmierer haben hier ihre Schwierigkeiten.
Vielleicht ist ein Workshop eine Idee, wo einmal die Entwickler zeigen, wie sie dokumentieren, und später eine Recherche an einem bereits abgeschlossenen Projekt, an das sich keiner mehr gut erinnert, durchgeführt wird.Ich würde ein Werkzeug evaluiren und nutzen, wie du es beschrieben hast. Im Idealfall übernimmt QM das, und alles ist gut. Die PDFs müssen allerdings eine QM-gerechte Dokumenteninformation (Projekt, Version, Testzweck, etc…) enthalten.
Vorschlag zur Güte: Ihr nutzt das von QM angegebene Formblatt, schreibt drauf ‚Information im Anhang‘ und tackert* die ausgedruckten PDFs dran…
*durchaus wörtlich zu nehmen
–Rainaari
Hallo Rainaari,
vielen Dank für die Rückmeldung.
Der QMB ist durchaus bewusst, wie wir entwickeln und welche Werkzeuge wir verwenden (wollen). Sie ist jedoch der unerschütterlichen Meinung, dass A L L E QM-Aufzeichnungen gleiche Form haben müssen und auf Formblättern durchgeführt werden müssen. So ist es denn auch im QM in unserer VA zur Lenkung der Aufzeichnungen festgeschrieben.Die PDF-Ausgabe des Softwaretools liefert alle erforderlichen Angaben, wie Projektnummer, Projektname, Art der Information, Seitennummerierung (Seite x von y), Revisionsnummer Änderungsverzeichnis und Felder zur Prüfung und Freigabe… Sollte als QM-Aufzeichnung geeignet sein.
Ich würde gerne alle Beteiligten davon überzeugen, dass die Ausgabe aus dem Tool direkt verwendet wird, aber habe keine Idee wie man das anstellt. Das ran-tackern an das FB ist eine interessante Lösung, auch formal korrekt, zumal wir unser QM auf Papier und nicht digital betreiben. Es würde von der QMB aber auch als Affront gegen ihr QMS aufgefasst werden…
Grüße Unicorn
Servus Unicorn,
ich weiss nicht, inwieweit das Thema Wertstromanalyse bei euch präsent ist.
Der Vorgang, die Informationen aus dem Programm in ein Word Dokument zu übertragen, kostet Zeit und birgt die Gefahr von Übertragungsfehlern. Welchen objektiven Nutzen bringen entsprechend einheitliche QM Dokumente?
Ich würde, zunächst zusammen mit dem QMB, die Anforderungen an die Dokumente festlegen – wofür dokumentiert ihr? Tipp: Nicht für die Norm, nicht für den Auditor.
Die ermittelten Szenarien würde ich dann mal mit allen Beteiligten durchspielen. Habt ihr externe Berater? So jemand kann als halbwegs neutraler Moderator dienen, damit persönliche Befindlichkeiten den Prozeß nicht stören.Die VA Lenkung von Aufzeichnungen ist ja auch nicht in Stein gemeisselt, sondern kann angepasst werden. Wir sind iirc seit 13 Jahren zertifiziert und unsere VA hat jetzt die Revision 10…
–Rainaari
Die Überlegung mit dem Nutzen des Übertragens hatte ich auch schon angestellt. Der Begriff „Wertstromanalyse“ ist ein kein Thema, wenn es um das QM geht. Hier scheint jeder Aufwand gerechtfertigt, den die QMB vorgibt. Ich muss versuchen in einem Gespräch mit der Geschäftsführung diese dafür zu sensibilisieren. Mal sehen, ob das klappt.
Ich dokumentiere die Software, um mich später darin wieder zurecht zu finden und um bei vermeintlich kleinen Änderungen den tatsächlichen Aufwand abschätzen zu können… und weiteres. Andererseits ist die Dokumentation und die Art und weise wie programmiert werden soll natürlich auch immer ein Erfordernis der Norm (bei uns der 62304).
Die QMB sieht den Schwerpunkt aber auf „weil die Norm es so verlangt und wir normgerechte Produkte entwickeln und vertreiben wollen“.
Ein externer Berater wäre eine gute Sache , aber wir haben ja unsere (teure) QMB, so dass wir uns nicht noch externe Berater leisten werden.
Unicorn
-
AutorBeiträge
- Sie müssen angemeldet sein, um auf dieses Thema antworten zu können.