Hallo, ich arbeite als Werkstudent in einem kleinen Unternehmen. Demnächst steht eine Neuzertifizierung an und ich wurde damit Beauftragt die Softwareverifizierung und Validierung einer Produktionsanlage durchzuführen und zu dokumentieren. Der Haken an der Sache ist, dass während der Entwicklung keinerlei Doku gemacht wurde und einfach drauflos programmiert wurde (Entwickler nicht mehr in der Firma). Jetzt da die Anlage doch produktiv eingesetzt wird muss alles nachträglich gemacht werden. Ich habe mich jetzt dabei am V-Modell orientiert und Anhand des Lasten und Plichtenheftes Anforderungen erstellt. Ablaufpläne und Schnittstellenbeschreibungen für die Entwurfsphase erstellt. Dazu muss ich sagen, dass ich das ganze recht grob gehalten habe, da ich mangels Zeit nicht den vollständigen Quelltext verstehen und detailliert beschreiben kann. Die Testphase versuche ich mittels Blackboxtests zu füllen. Dort teste ich nun. Z.B. füllt die Anlage richtig auf? Relaiseausgänge IST /SOLL usw. Für die Validierung habe ich zusätzlich zu einem Abnahmetest, die Prozessfähigkeit errechnet. Was sagen die erfahrenen Leute hier dazu und wo sollte auf jeden fall noch nachbessern? Wie muss ich mir so ein Auditing vorstellen wie weit geht so ein TÜV-Prüfer in die Materie rein?
Patrick K. schrieb: > Wie muss ich mir so ein Auditing vorstellen wie weit geht so ein > TÜV-Prüfer in die Materie rein? a) Was soll geprüft werden? b) Was wurde schon geprüft? c) Patrick K. schrieb: > Jetzt > da die Anlage doch produktiv eingesetzt wird muss alles nachträglich > gemacht werden. Sowas ist ein Saftladen. d) Nach welcher, Norm bzw. welche Zertifizierung macht der TÜV genau was wird geprüft? e) Was sagt dein QM-Heini? f) mach ne Aufgabenlist und lass die dienen Auftraggeber gegensehen! g) Du bist Werkstudent, und sollst sowas durchführen? Da ist es auch egal was rauskommt!
>Du bist Werkstudent, und sollst sowas durchführen? Da ist es auch egal >was rauskommt! Was ist den das für eine Einstellung ?
tja schrieb: > Was ist den das für eine Einstellung ? Gleiche Einstellung wie der TO beschreibt: Patrick K. schrieb: > dass > während der Entwicklung keinerlei Doku gemacht wurde und einfach > drauflos programmiert wurde (Entwickler nicht mehr in der Firma). Was willste in so einer Firma anderes erwarten?
Wäre mir auch zu blöd, den Mist der anderen wieder gerade zu biegen - als Werksstudent auch noch. Außer die Bezahlung ist entsprechend .. ;)
Als Werkstudent hat man auch weder das Wissen, noch die Erfahrung. Macht eben so gut es geht.
Patrick K. schrieb: > Was sagen die erfahrenen Leute hier dazu und wo sollte auf jeden fall > noch nachbessern? > Wie muss ich mir so ein Auditing vorstellen wie weit geht so ein > TÜV-Prüfer in die Materie rein? Viel Spaß! Wer den TÜV einmal ranlässt, wird ihn so schnell nicht wieder los. Bevor die dir etwas abzeichnen, müssen meist alle Details auf den Tisch, anständige Doku und ein fettes Budget - billig ist so etwas selten.
Viktor N. schrieb: > Als Werkstudent hat man auch weder das Wissen, noch die Erfahrung. Macht > eben so gut es geht. Richtig.
Nach all dem was ich bislang gehört habe macht der TÜV nicht wirklich was Sinnvolles. Das ihr schon mal das V-Modell ignoriert ist schon mal löblich. Softwarequalität kommt nicht von so was. Softwarequalität kommt durch qualifizierte Mitarbeiter.
Christian Berger schrieb: > Nach all dem was ich bislang gehört habe macht der TÜV nicht wirklich > was Sinnvolles. > > Das ihr schon mal das V-Modell ignoriert ist schon mal löblich. > Softwarequalität kommt nicht von so was. Softwarequalität kommt durch > qualifizierte Mitarbeiter. Ob der TÜV nun etwas Sinnvolles macht oder nicht, wenn du ihn ins Haus holst und z.B. nach IEC61508 arbeiten musst, dann schaut der TÜV der sehr wohl sehr genau auf die Finger. So mir nichts dir nichts geben die dir kein Zertifikat oder was auch immer. Bei sicherheitsrelevanten Anlagen haftet der TÜV mit, und bevor er da sein OK gibt, geht einige Zeit ins Land. Unabhängig davon möchte ich mal sehen, wie deine Software aussieht, wenn mal 12 Leute an einem grösseren Projekt arbeiten - da ist Organisation und gute Dokumentation mehr als hilfreich.
Ansich ist das Ganze eine Rezertifizierung des QM-Systems (EN ISO 9001). Das heißt der ganze Laden wird mal wieder unter die Lupe genommen. Die Anlage mit der ich mich hier beschäftige ist eine Produktionsanlage in unserer Firma (also für keinen Kunden) und soll das CE-Zeichen bekommen. Unser QM-Beauftragter hat mir halt nur grobe Formblätter gegeben bzw Verfahrensanleitungen. Diese sind aber für eine nachträgliche Dokumentation nicht sehr nützlich. Die Risikoanalyse muss ich nur um meinen Teil erweitern, den Rest macht unser Betriebstechniker.
Christian Berger schrieb: > Das ihr schon mal das V-Modell ignoriert ist schon mal löblich. > > Softwarequalität kommt nicht von so was. Softwarequalität kommt durch > > qualifizierte Mitarbeiter. Das musst Du mir jetzt mal erklären. Und ja, der Nick ist Programm. Übrigens beschreibt das V-Modell die alltägliche Arbeit der Software-Entwickler, auch der kleinen Krauter (die aber meistens wegen des Aufwandes 'in Anlehnung' werkeln). Und der TO hat nichts von 'ignorieren' gesagt.
Naja, so weit wie ich bislang das V-Modell verstanden habe, und ich kann das natürlich missverstanden haben, geht es darum, eine Spezifikation quasi Top-Down immer weiter aufzudrößeln um dann daraus Code zu machen bei dem man dann, im Idealfall, beweisen kann, dass er genau der Spezifikation entspricht. Tut er das so ist alles OK, tut er das nicht, so ist das Programm fehlerhaft. In der Theorie hört sich das toll an. In der Praxis ist aber das Problem, dass wenn man eine korrekte Spezifikation erarbeiten kann, man dass auch korrekt in Code umsetzen kann. Die Schwierigkeit liegt in der Spezifikation, und da häufig auch schon in den ersten Schritten. Die Umsetzung in Code ist, wenn sinnvolle Werkzeuge verwendet werden, trivial. So weit wie ich das V-Modell verstanden habe löst es ein Problem das nicht existiert und ignoriert die realen Probleme. Wenn Die Leute keine Ahnung haben wie man Softwareprobleme löst hilft ihnen das V-Modell auch nicht weiter. Haben sie Ahnung wie man Softwareprobleme löst brauchen sie das V-Modell auch nicht mehr. Wie schon gesagt, es kann auch sein, dass ich das V-Modell völlig falsch verstanden habe. Übrigens das V-Modell existiert außerhalb Deutschlands praktisch nicht, trotzdem ist Deutschland jetzt nicht unbedingt für seine Softwarequalität berühmt.
@Prüfer (Firmen intern oder evtl sogar beim TÜV?): Stell ich mir den Ablauf so in etwa richtig vor, wenn der Auditor die Entwicklungsakte durchgeht, sich die Verfahrensanweisungen und den Aufbau anguckt und dann prüft ob Schritte bzw Dokumente fehlen und danach die einzelnen Dokumente durchgeht und detailliert nachprüft?
Christian Berger schrieb: > Wie schon gesagt, es kann auch sein, dass ich das V-Modell völlig falsch > verstanden habe. Sieht so aus, denn es gibt einzig den groben Ablauf der Erstellung wider, und nicht das konkrete Vorgehen jedes einzelnen Schrittes. Dieses Modell macht sicher Sinn, dazu muss es nicht erst aus Amiland kommen. > Übrigens das V-Modell existiert außerhalb Deutschlands praktisch nicht, > trotzdem ist Deutschland jetzt nicht unbedingt für seine > Softwarequalität berühmt. Komisch, wenn du selbst nicht sicher bist, es richtig verstanden zu haben, wie du dann solche Aussagen machen kannst?!?! Frage mich, WER denn für seine überragende Softwarequalität pauschal SO berühmt sein soll - Microsoft vielleicht??? Fehler sind in jeder Software enthalten, aber im Automotive hat und setzt Deutschland sicher weltweit Standards, entgegen dem Mist, den man so in manchen Nachrichtenmagazinen liest, wo 08/15-Journalisten meinen ihr Bestes geben zu müssen. Die Fagan inspections haben nebenbei bemerkt ebenfalls schon Modelle zur Softwareentwicklung beinhaltet, das V-Modell ist sicher das bessere. Erst lernen, denn labern. Amen
Spargelpippi schrieb: > Fehler sind in jeder Software enthalten, aber im Automotive hat und > setzt Deutschland sicher weltweit Standards, entgegen dem Mist, den man > so in manchen Nachrichtenmagazinen liest, wo 08/15-Journalisten meinen > ihr Bestes geben zu müssen. Bei Automotive kann ich jetzt nichts sagen. Im Bereich der Automatisierungstechnik haben wir aber nichts, das auch nur ansatzweise erträglich ist. Die Spitze des Eisberges war sogar ein Heizungshersteller der das Passwort von der Heizung zum Client übertragen hat (über das Internet) damit er der Client überprüft. http://www.heise.de/security/meldung/Vaillant-Heizungen-mit-Sicherheits-Leck-1840919.html Wir sind tatsächlich in einem Bereich der Software relevant vertreten, und das ist bei der Freien Software (frei wie die Rede, nicht das Bier). Und da arbeitet niemand nach irgendwelchen V-Modellen. Mit fällt übrigens gerade auf, dass wir hier sehr weit abschweifen.
Christian Berger schrieb: > Bei Automotive kann ich jetzt nichts sagen. Im Bereich der > Automatisierungstechnik haben wir aber nichts, das auch nur ansatzweise > erträglich ist. Die Spitze des Eisberges war sogar ein > Heizungshersteller der das Passwort von der Heizung zum Client > übertragen hat (über das Internet) damit er der Client überprüft. > http://www.heise.de/security/meldung/Vaillant-Heiz... Wieder so eine Pauschalbehauptung, wo der Einzelfall sicher KEIN Beleg für den allgemeinen ist, schon gar nicht, wenn es um Heizungen geht. Auch nicht, wenn's mal im Heise-Verlag erschienen ist. Dort, wo z.B. die IEC61508 mit ihren SIL-Leveln zum Einsatz kommt, wird mit Sicherheit auch im Automatisierungsbereich ein hohes Maß an Softwarequalität gefordert, und da kenne ich mich aus. Die Vaillant-Heizung zu pauschalisieren ist da sicher völlig falsch. Christian Berger schrieb: > Wir sind tatsächlich in einem Bereich der Software relevant vertreten, > und das ist bei der Freien Software (frei wie die Rede, nicht das Bier). > Und da arbeitet niemand nach irgendwelchen V-Modellen. Erstens ist das Quatsch, und zweitens auch. Der Kreis der Open Source ist viel zu groß, um mit Sicherheit behaupten zu können, dass dort nirgends mit Modellen wie auch dem V-Modell gearbeitet wird. Arbeite selbst in diesem Bereich. In fast allen elektronischen Geräten sind heute Mikrocontroller enthalten, für die nun einmal Software geschrieben werden muss, auch wenn man diese nicht so direkt wie auf einem PC erkennt. Ist Sicherheit ein Thema, dann kommt schnell die Forderung nach dem TÜV-Siegel, und der kommt dann so ziemlich immer mit Normen, die erfüllt werden müssen. Ob in der Rüstung, im Automotive oder Nuklearkraftwerk, stellt Deutschland mit Sicherheit hohe Anforderungen an Qualität - weiß halt nicht jeder, weil man eben keine Kacheln hin- und herschubst, die einem im TV als ganz toll verkauft werden, obwohl's der letzte Schrott ist. Christian Berger schrieb: > Mit fällt übrigens gerade auf, dass wir hier sehr weit abschweifen. Dann bleibt doch beim Thema. Deine Aussage zum V-Modell zeigt jedenfalls, dass du eben wenig zum Thema weisst. Ein TÜV-Audit kenne ich jedenfalls aus der Praxis, und da wird Einiges gefordert.
Patrick K. schrieb: > Ansich ist das Ganze eine Rezertifizierung des QM-Systems (EN ISO 9001). > Das heißt der ganze Laden wird mal wieder unter die Lupe genommen. Die > Anlage mit der ich mich hier beschäftige ist eine Produktionsanlage in > unserer Firma (also für keinen Kunden) und soll das CE-Zeichen bekommen. Dann wird der TÜV-Auditor auch kein Software-Experte sein, sondern eher jemand mit Produktionshintergrund. Das Stichwort "V-Modell" wird den meisten Auditoren im Rahmen des Audits genügen. Relevant ist dabei das Kapitel 7.5 der ISO, insbesondere 7.5.2. CE-Kennzeichnung und Risikoanalyse für die Produktionsmittel sind im Rahmen eines 9001-Audits nur Randthemen (nur in 5.1 sind die gesetzlichen Anforderungen allgemein erwähnt, in den anderen Kapiteln sind sie immer auf das Produkt bezogen. Beachte insb. Kap. 0.1 - der Norm). Anders ist es natürlich, wenn die Software der Anlage auch zur Dokumentation der Produktprüfungen dient. Dann gelten für die Anlage auch die Anforderungen des Kap. 7.6. In gleicher Weise gelten andere Anforderungen, wenn die Software Daten zur Rückverfolgbarkeit, mit Kunden vereinbarte Daten etc. verwaltet.
Also hier im Medizintechnikbereich wird ziemlich konservativ Software entwickelt, nix mit schnell mal hinfrickeln und es landet auch nix im VCS ohne 4-eye review. Auch wenns etwas bürokratisch ist, ist es eigentlich ganz angenehm so zu arbeiten. Doku ist reichlich vorhanden, die Codequalität allgemein hoch (abgesehen von den Chinesenfrontends die man hin und wieder grade ziehen muss). An dem aktuellen Ding sitzen insgesamt über 100 Entwickler. Aber dank der hohen Qualität konnte man sich echt schnell einarbeiten.
Bist du Informatiker (Uni)? Hattest du einen Schwerpunkt in Puncto Medizintechnik? Ich studiere zurzeit Informatik und der Gesundheitsbereich interessiert mich schon. Ich studiere allerdings keine Medizininformatik (o.ä.), sondern ganz allgemein Informatik. Im Master kann man einen "Gesundheitsschwerpunkt" setzen, mehr aber nicht.
Spargelpippi schrieb: > Bei sicherheitsrelevanten Anlagen haftet der TÜV mit Nein, der TÜV haftet nur mit seinem Ruf. Aber in jedem anderen Aspekt sind ausschließlich Hersteller/Inverkehrbringer "dran". Niemals der TÜV.
D. I. schrieb: > Also hier im Medizintechnikbereich wird ziemlich konservativ Software > entwickelt, nix mit schnell mal hinfrickeln So interessehalber, mit welchen Normen arbeitet ihr denn? Gibts schon eine C-Norm oder ähnliches für den Medizinbereich, die auf der 61508-Schiene aufsetzt, oder habt ihr ganz eigene Normen?
Spargelpippi schrieb: > Bei sicherheitsrelevanten Anlagen haftet der TÜV mit, und bevor er da > sein OK gibt, geht einige Zeit ins Land. Also, der TÜV oder andere Sachverständig haften nicht! Das ist ein "Mythos" welcher anscheinend nicht auszurotten ist! Die prüfen nach besten Wissen und Gewissen. Sind aber keine technische "Rückversicherung". Da haftet der Planer und Konstrukteur strafrechtlich immer! Die Firma ist da höchsten beim Bußgeld beteiligt!
Fräge schrieb: > Ich studiere zurzeit Informatik und der Gesundheitsbereich interessiert > mich schon. Biste im Bac. noch, dann schau ob für dich ned auch ein Weiterbildungsmaster (die nennen sich "Nicht-Konsekutiv") finden läßt.
Fräge schrieb: > Bist du Informatiker (Uni)? Ja Fräge schrieb: > Hattest du einen Schwerpunkt in Puncto Medizintechnik? Nein Stefan Rand schrieb: > So interessehalber, mit welchen Normen arbeitet ihr denn? Gibts schon > eine C-Norm oder ähnliches für den Medizinbereich, die auf der > 61508-Schiene aufsetzt, oder habt ihr ganz eigene Normen? Ich kann sie dir gerade nicht benennen, da ich selbst noch frisch hinter den Ohren bin in dem Metier. Es sind jedenfalls ein paar. Mindestens eine 4stellige und zwei 5stellige Ziffern :)
Spargelpippi schrieb: > Dort, wo z.B. die IEC61508 mit ihren SIL-Leveln zum Einsatz kommt, wird > mit Sicherheit auch im Automatisierungsbereich ein hohes Maß an > Softwarequalität gefordert, und da kenne ich mich aus. Die > Vaillant-Heizung zu pauschalisieren ist da sicher völlig falsch. OK, was ist mit Siemens SPSen. Die Steuerungssoftware war mal gegen den LNK/PIF Bug anfällig, der eigentlich jedem auffallen hätte müssen, der sich intensiver mit Windows beschäftigt hat. Die Software hat übrigens auch noch einen SQL-Server drin, mit Standardpasswort, etc.
Christian Berger schrieb: > OK, was ist mit Siemens SPSen. Die Steuerungssoftware war mal gegen den > LNK/PIF Bug anfällig Du meinst nicht die "Steuerungssoftware", also Software auf der Steuerung, sondern das Programmier- und Parametriertool namens Step7, nehme ich an?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.