Hallo,
vielleicht ne blöde Frage, aber wie ist das eigentlich im Berufsalltag,
wenn man als Ingenieur z.B etwas programmiert oder berechnet hat, wird
das dann am Ende oder zwischendurch nochmal von jemand anders
kontrolliert? Mal angenommen man schreibt ein Programm für eine SPS.
Gucken dann vorher der Vorgesetze oder irgendwelche Kollegen nochmal
drüber bevor das Programm übertragen wird, falls eine Simulation/Test
nicht möglich sein sollten.
Ich bin selber noch nicht im Berufsleben daher sind mir die genauen
Arbeitsabläufe noch nicht so bekannt.
gruß
Also ganz rein theoretisch ist das so:
Es gibt eine Testabteilung und eine Entwicklungsabteilung. Die
Entwicklung muss dann den Test bestehen. Da wird jedes Modul, die
Baugruppe usw. getestet, vom Feinen zum Groben. Manchmal wird auch eine
externe Zertifizierungsfirma beauftragt.
In der Praxis sieht das anders aus:
Deine SPS hängt an einem Produktivsystem und du bist der Praktikant, der
was frickeln soll. Du wirst an einen verstaubten Windows95-PC gesetzt,
der ohne Passwortschutz etc. da herum steht. Dieser hängt direkt an der
SPS. Auf dem PC, der ohne Virenscanner am Internet hängt, sind viele
Spiele, Pr0n und Keygens drauf. Wenn du einen Fehler machst steht die
Produktion. Das interessiert aber keinen, da so viele Zwischenfälle
auftreten, dass das gar nicht ins Gewicht fällt.
Solltest du etwas versaut haben, dann flüchte lieber nicht heimlich zum
nahegelegenen Notausgang, denn du müsstest erst die ganzen Rümpelkisten
wegschieben, um rauszukommen. Die stehen aber nicht ohne Grund da. Die
Treppe am Notausgang ist kaputt und bricht beim Betreten durch.
So jetzt weist du wie Praxis funktioniert ;)
Das ist etwas überspitzt, aber in der Praxis läuft es oft in diese
Richtung, vor allem wenn bei der IBN noch schnell etwas anzupassen ist.
Und das mit dem Rechner ist nicht sehr weit hergeholt, Stuxnet lässt
grüßen.
Testabteilungen gibt es wenige. Oft geht das neue Produkt direkt von der
Entwicklung zur Fertigung, die ganzen zertifizierten Abläufe stehen auf
dem Papier und das ist bekanntlich geduldig.
Das ist ganz einfach:
Am Anfang wird jede Menge Zeit für Verifikation eingeplant.
Wenn das so pünktlich fertig ist, dass noch Zeit ist, wird noch
getestet, oder irgendwer gebeten, sich das noch mal anzusehen. Der macht
das dann oder auch nicht.
Normalerweise ist keine Zeit mehr, dann geht es so raus und man hofft,
dass es gut geht. Wenn noch Fehler bekannt sind, gibt es Nachtschicht
und dann geht das so raus.
Es gibt auch tolle Tools, die die Tests bei automatisierten Tests
verifizieren. Dann geht es vor allem darum, dass diese Testtools nicht
mehr meckern. Das muss dann nichts damit zu tun haben, ob das läuft,
aber man ist sauber.
Aber grundsätzlich erwartet man natürlich schon von einem Ing., dass der
halbwegs fehlerfrei arbeitet.
Gruss
Axel
Schorsch schrieb:> Häufig dient der Kunde als Tester, manchmal ohne dass er es weiß ;-)
Hat sich schon rumgeprochen. Nur die Dümmsten glauben noch, dass
Neuerungen auch immer Verbesserungen sind.
Das kommt aber auch stark auf den Bereich an.
Wenn du die State-Machine für einen Getränkeautomaten bastelst ist wohl
ziemlich egal wie robust und gut dein Code ist, wenn es funktioniert. Da
wird jede Funktion getestet und das wars. DAnn noch kurze Beschreibung
der Software und fertig.
In stark reglementierten Bereichen ist halt alles strenger. Also
Luftfahrt, Automobil (grad wenn es um sicherheitsrelevante Sachen geht),
Medizin oder Überwachung für Kraftwerke oder sonstiges....
Da hast du normalerweise stark kontrollierte Entwicklungsprozesse. Also
bei Software z.B. Pair-programming oder vorgeschriebene unabhängige
Code-reviews. Die Algorithmen die du programmierst musst du auch
dokumentieren. Diese Dokumente werden auch gereviewed von jemandem der
Ahnung hat und dann vom Vorgesetzten freigegeben. Die ganze Software
wird dann natürlich getestet und die Tests dokumentiert.
Dass du diese Sachen einhälst wird dann auch von Zeit zu Zeit durch
Audits geprüft. Die Prüfer können z.B. von der Auftraggeber-Firma sein.
Das können aber auch Behörden sein, oder Audits die deine Firma selbst
in Auftrag gibt um zu zeigen, dass alles gut läuft (z.B. LGA / TÜV).
Oder interne Audits durch die eigene Firma um Missstände aufzudecken,
bevor es jemand anderes tut.
Grundsätzlich braucht man aber auch da keine Angst vor haben, denn
kleine Fehler können jedem mal passieren und grobe Fehler sollten
(müssen) durch die Reviews und Audits auffallen. Solange du nicht
vorsätzlich Mist baust dreht dir auch keiner nen Strick.
Fazit: Es kommt einfach drauf an ob du einen Kaugummi-Automaten oder ein
Beatmungsgerät programmierst.
PS. Für Elektronik schauts natürlich genauso aus...
Schorsch schrieb:> Häufig dient der Kunde als Tester, manchmal ohne dass er es weiß ;-)
Diese Aussage war positiv gemeint. Manche Kunden tun sich halt schwer
damit, sich Ihrer Anforderungen bewusst zu werden und sie dann auch noch
zu spezifizieren. Wenn Sie dann das fertige Produkt vor sich haben,
wollen Sie dann das ein oder andere plötzlich ganz anders...
Viel einfacher ist es, wenn man Ihnen was vorsetzt, dass Sie
anschauen/ausprobieren können und wo Sie konkret Feedback geben können.
Ich denke, das ist einer der Unterschiede zwischen Wasserfall-Modell und
agiler Softwareentwicklung.
Selbst die besten Programmierer müssen an Ihrem Code Änderungen
vornehmen im Laufe der Zeit. Deswegen gibt es Versionsmanagement. Aber
deswegen kann man den Programmierern nicht vorwerfen, sie würden
grundsätzlich nicht fehlerfrei arbeiten ;-)
