Ach herjemine, außgerechnet nach IEC-62304!
Aus Erfahrung kann ich Dir sagen, dass es am Einfachsten ist, wenn Du Software sofort dokumentierst. Zuerst musst Du Dir klar werden, was zu dokumentieren ist. Ich würde mir so eine Art Inhaltsverzeichnis anlegen und dass dann verifizieren, ob alles vollständig ist. Dazu muss man sich mit den einzelnen Anforderungen und Begrifflichkeiten (IEC-62304) auskennen. Dann hätte ich ein Gerüst zur Doku. Außerdem festgehalten werden Ziele, Voraussetzungen, zu erwartende Probleme und Lösungsansätze grob skizziert. Dann würde ich mit der Software loslegen und mich an meinen "Plan" halten. Habe mal eine "einfache" Projektdoku zu einem Mini-Programm gemacht, für die Prüfung damals. Da gab es aber keine so besonderen Anforderungen, das war noch relativ human. Dort habe ich das aber auch so gemacht. Ich habe mit dem INhaltsverzeichn is der Doku angefangen und das dann mit Inhalt gefüllt, nebenbei die Software geschrieben. Dann wenn Module funktionierten, den PAP dazu erstellt und die notwendigen Anmerkungen dazu gemacht. Eine Dokumentation kann man auch hinterher erstellen. Allerdings ist das nicht minder langwierig. Leider! Bei Änderungen wird die Doku immer wieder ergänzt und geändert, das bleibt nicht aus. Aussichtslos ist so eine Doku sicher nicht, wenn man die hnterher erstellt, man muss nur Ausdauer mitbringen. Bei sehr großen Projekten geht das leider gar nicht anders, als die Doku immer nebenbei zu führen. Das ist auch schon wichtig, weil man in einem Software-Unternehmen selten alleine arbeitet, ist eigentlich immer Teamarbeit und dort wird in Englisch dokumentiert und bevor man seinen Programmcode für andere im Team zugänglich macht gehört ein Mindestmaß an Dokumentation sowieso dazu.
Da hast Du was vor...
Sämtliche Begrifflichkeiten aus der Systemprogrammierung zu kennen ist eigentlich obligatorisch, zumindest, dass man die Sachen schon mal gehört hat und die einsortieren kann. Man muss nicht immer alles wissen, man muss nur wissen wo es steht.
Das ist mit modularer Programmierung und objektorientierter Programmierung möglich. Dabei wird nicht im Programmcode des Moduls getestet und dort drin rumgeschrieben, sondern das Modul bleibt immer "rein". Da es eine Schnittstelle hat, kann man dort die Test-Daten reingeben und schauen, was aus dem Modul zurückkommt. Das reicht eigentlich aus. Funktioniert das Modul, nimmt man Kriterien, nach denen bewiesen werden kann, dass es funktioniert, wie es soll. - Dabei das Dokumentieren nicht vergessen! (was ja nun wohl schon passiert ist). Die Dokumentation hilft während der Entwicklung, dass der Code fehlerfrei ist und die Anforderungskriterien erfüllt sind und man die nicht aus dem Auge verliert.Der Unittest dient ja dazu, seine Software zu testen und zu beweisen dass die Funktionalität gegeben ist.
Eigentlich sollte dann daran nichts mehr geändert werden...
MfG
Moppi
PS: Kläre mal die Haftungsfrage, falls sich in Zukunft rausstellen sollte, dass mit der Dokumentation was nicht stimmt oder so ähnlich. Das müsste bei Medizingeräten doch eigentlich fachlich alles 1A in Ordnung sein oder? Mir kam nur so der Gedanke, dass das Eisen vielleicht etwas zu heiß ist.
Zitieren
Zitat von shedepe
Lesezeichen