Tod durch Softwarefehler

Hoert sich aehnlich an wie ISO-9000. Wenn man sauber dokumentiert, wie man eine Klippe runterfahren soll, das dann auch genau anhand diese Dokumentes tut und unten in einem Feuerball zerschellt, dann ist die Norm erfuellt.

Klar, der auf der Cloud.

Gruß Dieter

Am 29.10.2013 20:48, schrieb Dieter Wiedmann:

Also, nach heutiger Logik, die NSA.

Ja, kommt einem alles ziemlich übel vor.

-ras

Am 29.10.2013 21:03, schrieb horst-d.winzler:

Nee, aber die klaut.

Gruß Dieter

Nun ja, ist eben nur eine Menge von Regeln, die hauptsächlich das Programmieren mit C sicherer machen soll, da es einem die Sprache von Haus aus ziemlich leicht macht Fehler einzubauen.

Andere Sprachen sind aber auch nicht perfekt. Immer wieder nett zu lesen und viel wahres dran:

Ich denke ein Schritt in die richtige Richtung wären schon Sprachen und Tools, mit denen man formal beweisen kann, daß ein Programm eine Spezifikation erfüllt, wie bei Spark ADA. Sowas erhöht bestimmt auch die Wahrscheinlichkeit bessere Programmierer zu bekommen, die vielleicht auch eher Ungereimtheiten in der Spezifikation entdecken, da schlechte Programmierer, die MISRA-C problemlos erfüllen können, sowas erst gar nicht verstehen :-)

Wieso moechte man ISO 9000 implementieren (Grundlagen und Begriffe)? Oder meinst Du ISO 9001:2008?

Wenn man die ISO 9001:2008 nicht begriffen hat dann sollte man auch keinen Mehrwert erwarten. Leider gab und gibt es immer wieder Firmen die meinen ein bisschen Prozesse dokumentieren erfuellt die Norm. Wegen solchen Komplettausfaellen sollte man allerdings nicht die Norm kritisieren. In der letzten Inkarnation von 2008 kommt sie recht pragmatisch daher und eine Firma profitiert durchaus wenn sie sich daran orientiert. Sehr viele Fragestellungen aus der Norm sind durchaus eine Ueberlegung wert sobald man eine gewisse Azahl an Mitarbeitern hat. BTW, Automotive hat sogar noch eine verschaerfte Version, die ISO/TS16949.

Gruss

Fritz

Am 29.10.2013 21:30, schrieb Dieter Wiedmann:

Faktisch sind sie Diebe, die obendrein Vertrauen mißbrauchen. Keine Frage. Da es sich aber um eine US Behörde handelt und die USA nunmal unsere Freunde sind, erweisen sie uns einen Freundschaftsdienst, wenn sie Mutti abhören. Mutti teilt doch ihrem Staatsvolk nicht mit, wenn sie weider mal Lobbyarbeit verrichtet. Also alles im Dienst des Vetrauens.

Also schrieb Hartmut Kraus:

Ich würde auch zu gerne mal die SPS unseres Aufzugs hier in die Finger kriegen - um dann die Logik einzuspielen, die ich damals[tm] im Praktikum während des Studiums programmiert habe. Die war komplett mit Richtungspriorität und Langsamfahrstufe beim "Landen". Unser Lift hier akzeptiert immer nur einen einzigen Ziel-Tastendruck vom inneren Tableau, weitere Tastendrücke werden nicht mehr entgegengenommen. Außerdem ist die Tür-Zu-Steuerung ziemlich dämlich. Nach dem ersten Öffnen wartet die Tür 5 s (oder so), aber sobald die Lichtschranke einmal unterbrochen war, geht die Tür praktisch sofort zu (geschätzte 0,5 s). Wenn da noch einer hinterherkommt, muss er schnell sein...

Ansgar

Joerg schrieb:

ich glaube, das hast Du nicht richtig verstanden. Stefan beschreibt m.E. Situationen, wo Programmierer _wegen der Tools_ Fehler einbauen, auf die sie ohne die Tools nie gekommen wären.

Servus

Oliver

Das war nur als Sammelbegriff gedacht. Habe sowas schonmal mitgemacht.

Es hat schon einen Sinn, aber in zuvielen Firmen wir das so gesehen: "So, jetzt haben wir das Baepperle, lasst uns zurueck zum ueblichen Tagesgeschaeft gehen".

Leider spiegelt sich das nicht in den Pannendaten wieder. Ergo laeuft irgendwas suboptimal.

Was Normung angeht, gab es im Bereich KFZ durchaus brauchbare Erfolge. So brauche ich z.B. selbst fuer unsere inzwischen aelteren Fahrzeuge nur noch ein OBD-II Interface, waehrend Anfang der 90er noch jeder sein eigenes Sueppchen kochte.

Das hatte ich schon verstanden. Aehnliches kann nach Zertifizierungen geschehen. "Ist ja jetzt so Vorschrift". Da wird schonmal der gesunde Menschenverstand ausgeschaltet, wo man frueher informell ein adhoc Meeting im Flur mit Beschluss am Ende abgehalten haette (was man nach der Cert u.U. nicht mehr darf). Habe ich im oeffentlichen Bereich mitbekommen. "But isn't that wrong?" ... "Yes, probably, but that's what the procedure says".

Joerg schrieb:

Genau das ist doch das Problem. Du redest ja selbst einmal standardisierten und dokumentierten Verfahren das Wort und hier dann dem informellen Meeting im Flur.

Der bisher nur zum Teil gelungene Trick ist doch, Starndardprozeduren hinzubekommen, die am Ende nicht irgendwelchen widersinnnigen Blödsinn fordern (können). Das ist nunmal bei komplexen Systemen mindestens ähnlich komplex, wie die Systeme selbst.

Da müßte man also hinterfragen, was die Flugzeugbauer oder Medizintechniker anders machen als die Autokonstrukteure. Ich vermute es läuft am Ende auf monetäre Aspekte hinaus (was zumindest bei Luxuskarossen reichlich unverständlich wirkt).

Marc

Am 29.10.2013 21:36, schrieb Frank Buss:

So ein Schwachsinn. Nach dem (den) ersten Toten kannst du dann ja argumentieren: "Der muss noch am Leben sein, das kann gar nicht passieren, das ist formal bewiesen!"

Aua. Ein Programmierer, der sowas nicht sieht, ist im falschen Beruf.

Am 30.10.2013 10:29, schrieb Ansgar Strickerschmidt:

Schwache Kür.

Angenommen, im 3. steigen 2 ein. Einer will in den Keller, einer in den

1. Dann ruft einer von außen im Erdgeschoss und einer im 10. Wie muss die Kiste jetzt fahren?

(Das war übrigens zu Zeiten schon gelöst, als an sowas wie Microcontroller noch nicht zu denken war. Ich nehme an., in den Steurungen hat's nur so gerasselt von Relais.)

Informell heisst nicht undokumentiert. Am Ende muss das alles in die Design History, mit Gruenden, warum man die vorige Loesung verworfen hat.

So isses. Bei ISO habe ich jedoch wenig pragmatische Vorgehensweisen gesehen. Natuerlich kann man das machen und sollte es auch. Doch wie es so ist, viele Firmen wollen einfach nur das Baepperle und das so schnell wie es geht. Dabei werden Prozeduren gekliert wie am Fliessband.

Wir sind meist gezwungen, eine audit-faehige Design History zu erstellen. Neuen Ingenieuren, die nicht aus Med oder Aero kommen, muss ich das regelmaessig erklaeren. Dann sind Design Reviews vorgeschrieben, wo bei manchen davon Mitarbeiter etlicher anderer Abteilungen (QC, Produktion, Einkauf, etc.) teilnehmen muessen. Aehnliches gilt fuer das ECO Meeting. In solchen Firmen ist das alles langsam gewachsen, die Leute sind wegen der vielen Agency Pruefungen daran gewoehnt. Prozeduren muessen nicht im Rahmen eines mit der heissen Nadel genaehten Zertifizierungsverfahren erstellt werden, sondern es gibt sie bereits seit Ewigkeiten.

Vieles davon ist im KFZ-Bereich sicher aehnlich, aber die Ergebnisse im Feld deuten nicht darauf hin, dass es dort auch immer viel fruchtet. Fuer mich wirkt das nicht nur bei Luxuskarossen unverstaendlich, denn es kann den Ruf kosten. Wer mit einfachen Wagen einer Firma regelmaessig Pech hatte, wird spaeter kaum dort ein edleres Fahrzeug kaufen. Aversionen und Misstrauen koennen jahrzehntelang anhalten. Z.B. werde ich mein Lebtag keine Autos mehr von Chrysler kaufen. Die waren von der Technologie her anderen echt voraus, aber die Qualitaet und das Engineering war IMHO eher mangelhaft. Lichtmaschine an Alutraeger und solche Scherze, da ist entweder kein gescheites Design Review gelaufen oder man hat dabei nicht richtig aufgepasst.

Komisch. Nach meiner naiven Vorstellung kann man nur von dem profitieren, was einem die Kunden zahlen. Alles andere kostet. Einnahmen

- Kosten = Profit (Natürlich stark vereinfacht.) ;)

Am 30.10.2013 17:39, schrieb Joerg:

Wieso - inwiefern beinträchtigt das die Funktion einer Lichtmaschine?

Die Vibrationen sorgen dafuer, dass der Traeger bricht. Nach Murphy natuerlich nachts, wo man Licht braucht und damit nicht lange auf Batterie weiterfahren kann. Nach dem x-ten Mal habe ich im Keller eine Halterung aus Stahl hingedengelt und es passierte nie mehr. Bei technischen Gegenstaenden sollte es nicht noetig werden, dass der Kaeufer am Design nachbessern muss.