1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Softwarefehler in der Raumfahrt: In…

So ist das nun mal mit Technik

  1. Thema

Neues Thema Ansicht wechseln


  1. So ist das nun mal mit Technik

    Autor: yeti 24.11.15 - 13:41

    Und insbesondere mit neuer Technik.

    Da passieren eben Fehler.
    Damals bei Werner von Braun in Peenemünde sind die Raketen auch des öfteren abgestürzt, ganz ohne Softwarefehler.

    Es müssen eben erst Fehler gemacht werden, um daraus lernen zu können!

    Bei den beschriebenen Problemen scheint es mir auch eher um Probleme mit der Regelungstechnik gegangen zu sein, als mit Software im engeren Sinne.



    1 mal bearbeitet, zuletzt am 24.11.15 13:48 durch yeti.

  2. Re: So ist das nun mal mit Technik

    Autor: Hotohori 24.11.15 - 13:49

    Dennoch sind auch Fehler bis zu einem gewissen Masse leicht zu vermeiden, wenn man sich nicht all zu dumm anstellt. Und genau das war eben hier der Fall: dumm angestellt und das bei solch einem teuren Projekt...

    Und das nur weil sie Geld sparen wollten, ich frage mich ob sie mit dem Geld, dass sie da jedes mal in die Luft gesprengt haben, nicht eher mehr ausgegeben haben als wenn sie direkt mehr Geld in die Software Entwicklung gesteckt hätten. ;)

  3. Re: So ist das nun mal mit Technik

    Autor: Epaminaidos 24.11.15 - 13:55

    Hotohori schrieb:
    --------------------------------------------------------------------------------
    > Und das nur weil sie Geld sparen wollten, ich frage mich ob sie mit dem
    > Geld, dass sie da jedes mal in die Luft gesprengt haben, nicht eher mehr
    > ausgegeben haben als wenn sie direkt mehr Geld in die Software Entwicklung
    > gesteckt hätten. ;)

    Es ist halt eine Gratwanderung: Testet man zu viel, wird das ganze Projekt zu teuer. Testet man zu wenig, scheitert das ganze Projekt.
    Der richtige Mittelweg beruht auf Erfahrungswerten. Und bis zu diesen negativen Erfahrungen war die Raumfahrt ja durchaus erfolgreich.
    Die Industrie hat daraus gelernt und die Qualitätsstandards angemessen erhöht. Ist doch eigentlich ein ganz normaler Lernprozess :-)

  4. Re: So ist das nun mal mit Technik

    Autor: Hotohori 24.11.15 - 14:31

    Zumindest in der Raumfahrt war das aber ein sehr teurer Lernprozess. ;)

  5. Re: So ist das nun mal mit Technik

    Autor: tingelchen 24.11.15 - 14:49

    Der gute Wernher von Braun hatte allerdings andere Probleme zu lösen. Nämlich die Frage... wie bekommt man einen langen Zylinder, an dem an einem Ende massig Schub zerrt, überhaupt stabil zum fliegen :)

  6. Re: So ist das nun mal mit Technik

    Autor: derdiedas 24.11.15 - 18:57

    Werner von Braun hat etwas geschaffen für das absolut NULL vorhergehendes Wissen vorhanden war.

    Bei den Fehler die im Artikel beschrieben war, hätte man 1und 1 zusammenzählen können. Wenn Werner von braun so gearbeitet hätte - dann wäre nie was geflogen.

  7. Re: So ist das nun mal mit Technik

    Autor: der_wahre_hannes 25.11.15 - 11:55

    derdiedas schrieb:
    --------------------------------------------------------------------------------
    > Werner von Braun

    Der Mann hieß Wernher.

  8. Re: So ist das nun mal mit Technik

    Autor: theonlyone 25.11.15 - 14:05

    Das Ding mit Fehlern ist eben, wenn sie auftreten, dann ist es vergleichsweiße einfach zu sagen wo der Fehler war.

    Aber wenn die Fehler nicht auftreten (erstmal) ist es wahnsinnig schwer festzumachen das ein Fehler existiert.

    Den letztlich ist es völlig unmöglich bei komplexeren Programmen (oder allgemein) zu sagen das etwas "fehlerfrei" ist. Man kann nur möglichst viel abdecken, aber um allgemein sagen zu können wie etwas unter allen Umständen funktioniert, das geht praktisch nie (Turing Vollständigkeit usw. selten gegeben).

  9. Re: So ist das nun mal mit Technik

    Autor: Ork 25.11.15 - 16:11

    Ja, wenn 400Mio zum Testen billiger sind als das erste go-live zu versemmeln, dann testet man lieber für 400Mio als gar nicht. Oder wenigstens für 200Mio.

  10. Re: So ist das nun mal mit Technik

    Autor: theonlyone 25.11.15 - 16:25

    Ork schrieb:
    --------------------------------------------------------------------------------
    > Ja, wenn 400Mio zum Testen billiger sind als das erste go-live zu
    > versemmeln, dann testet man lieber für 400Mio als gar nicht. Oder
    > wenigstens für 200Mio.

    Die Summe bringt doch nichts, wenn man einfach nicht den Fehler raustestet kannst du da so viel Geld auf einen haufen werfen wie du willst.

    Den Fehler wirst du einfach erst finden, wenn alle Systeme am konkreten Fall eingesetzt werden.

    Den wenn du vorher wüßtest wo der Fehler steckt, würdest du diesen ja lösen und nicht ignorieren.

    Diese trivialen Fehlerchen sind ja genau deshalb drin, weil man TROTZ testen sie nicht gefunden hat.

    Die reine Summe rettet dich nicht und findet auch keine Fehler.

  11. Re: So ist das nun mal mit Technik

    Autor: Anonymer Nutzer 25.11.15 - 18:14

    theonlyone schrieb:
    --------------------------------------------------------------------------------
    >
    > Die Summe bringt doch nichts, wenn man einfach nicht den Fehler raustestet
    > kannst du da so viel Geld auf einen haufen werfen wie du willst.
    >
    > Den Fehler wirst du einfach erst finden, wenn alle Systeme am konkreten
    > Fall eingesetzt werden.
    >
    > Den wenn du vorher wüßtest wo der Fehler steckt, würdest du diesen ja lösen
    > und nicht ignorieren.
    >
    > Diese trivialen Fehlerchen sind ja genau deshalb drin, weil man TROTZ
    > testen sie nicht gefunden hat.
    >
    > Die reine Summe rettet dich nicht und findet auch keine Fehler.

    Wenn man nach der Logik rangeht, dann sollte man also gar kein Geld mehr fürs Testen aufwenden und statt dessen nur noch die Missionen nach "trial and error"
    gestalten? Ich will dir nichts unterstellen, aber das les ich so daraus...
    Also das Geld, was man fürs testen bezahlt, einfach in die Mission pulvern und nach dem 10. Fehlstart merken: Oh, wir haben einen weiteren Bug gefunden?
    Das ist mit Verlaub Unsinn.
    Deine Aussage:
    > Diese trivialen Fehlerchen sind ja genau deshalb drin, weil man TROTZ
    > testen sie nicht gefunden hat.
    ist im Zusammenhang mit dem Artikel falsch, weil, wie aus dem Artikel ersichtlich ist,
    häufig die Qualitätskontrolle geschlampt hat (fehlerhafte Variable nicht entdeckt etc. pp.) und Tests nachlässig bis gar nicht durchgeführt wurden.
    Hier zeigt sich wie aus meiner Erfahrung immer wieder, warum eine Software am Ende nicht das macht, was sie soll:
    Tests wurden aus Mangel an Zeit, Geld oder Engagement des Mitarbeiters nicht ausreichend durchgeführt, meistens werden nicht einmal konkrete Testfälle definiert und durchgespielt, Testumgebungen sind nur unzureichend vorhanden und bilden die Realität nur zum geringst möglichen Teil ab. Klar können sie die Realität nicht zu 100% abdecken, irgendwelche Eventualitäten kann man nie komplett mit steigender Komplexität vorher bedenken, aber meistens wird auch nie annähernd versucht, sie aus den bereits genannten Gründen abzudecken.
    Bsp bei uns, Kunde meldet sich und sagt: Umstellung des Produktivsystems funktioniert nicht, auf dem Testsystem hat es aber geklappt.
    Erste Rückfrage die gestellt wird an den Kunden:
    Was haben Sie denn getestet?
    Antwort vom Kunden: Na wir sind das einmal mit den und den Einstellungen durchgegangen und dann davon ausgegangen, dass das mit den anderen Einstellungen auch klappt.
    Antwort an den Kunden:
    Sehen se, sie haben also nicht getestet!
    Fazit: wäre also vermeidbar gewesen, wenn man sich vorher nen Kopf darüber gemacht hätte, was das Ergebnis sein soll und wie man das testet (ausreichend!).
    Kann man aber auch direkt mit "trial and error" machen, kostet am Ende halt nur deutlich mehr Geld und bedeutet mehr Streß für die Verantwortlichen...

  12. Re: So ist das nun mal mit Technik

    Autor: theonlyone 26.11.15 - 09:52

    sebastian4699 schrieb:
    --------------------------------------------------------------------------------
    > Wenn man nach der Logik rangeht, dann sollte man also gar kein Geld mehr
    > fürs Testen aufwenden und statt dessen nur noch die Missionen nach "trial
    > and error"
    > gestalten? Ich will dir nichts unterstellen, aber das les ich so daraus...

    Das "garnichts" getestet wird ist ja nicht der Fall.

    Die Frage bleibt, was es bringt aber millionen extra ins Testen zu stecken, wenn du einfach nicht das Szenario testest das letztlich in der Mission gefahren wird.

    Den natürlich wurde simuliert und damit getestet, aber nicht mit exakt der Hardware die letztlich in der echten mission benutzt wird.

    Den selten ist in der Software an sich noch ein Fehler, der allein mit der Software zusammen hängt, viel eher im Zusammenspiel.

    Und diese Tests waren eben erfolgreich. Es gab ausgehend von den Tests also keinen Grund anzunehmen das es in der Mission nicht funktioniert.
    Hier dann zu argumentieren man müsse noch aber millionen extra ausgeben und noch weiter zu suchen, obwohl die aktuellen Tests sagen "alles funktioniert" ist eben etwas das man nicht durchbekommt und das in aller Regel auch einfach keinen Sinn macht ; den wann willst du damit den aufhören ? Alle deine Tests sind erfolgreich und du willst trotzdem noch weitere Tests schreiben ? Du kannst einfach NIEMALS alles testen was überhaupt möglich ist, gerade weil du die Fremdsysteme die du benutzt eben nicht vollständig testen kannst, auch die Libs die du benutzt wirst du nicht testen, macht auch keinen Sinn.

    > Also das Geld, was man fürs testen bezahlt, einfach in die Mission pulvern
    > und nach dem 10. Fehlstart merken: Oh, wir haben einen weiteren Bug
    > gefunden?
    > Das ist mit Verlaub Unsinn.
    > Deine Aussage:
    > > Diese trivialen Fehlerchen sind ja genau deshalb drin, weil man TROTZ
    > > testen sie nicht gefunden hat.
    > ist im Zusammenhang mit dem Artikel falsch, weil, wie aus dem Artikel
    > ersichtlich ist,
    > häufig die Qualitätskontrolle geschlampt hat (fehlerhafte Variable nicht
    > entdeckt etc. pp.) und Tests nachlässig bis gar nicht durchgeführt wurden.

    Es wurde ja simuliert und getestet. Bringt dir eben nur nichts wenn einfach die falsche Config eingelesen wird, den dann sind deine Test-Aussagen eben falsch ; nur das zu erkennen ist alles andere als Trivial, da man seine Tests ja nicht grundlegend hinterfragt ob die Ergebnisse korrekt sind ; den sonst sagt der Test ja praktisch garnichts aus.

    > Hier zeigt sich wie aus meiner Erfahrung immer wieder, warum eine Software
    > am Ende nicht das macht, was sie soll:
    > Tests wurden aus Mangel an Zeit, Geld oder Engagement des Mitarbeiters
    > nicht ausreichend durchgeführt, meistens werden nicht einmal konkrete
    > Testfälle definiert und durchgespielt, Testumgebungen sind nur unzureichend
    > vorhanden und bilden die Realität nur zum geringst möglichen Teil ab. Klar
    > können sie die Realität nicht zu 100% abdecken, irgendwelche Eventualitäten
    > kann man nie komplett mit steigender Komplexität vorher bedenken, aber
    > meistens wird auch nie annähernd versucht, sie aus den bereits genannten
    > Gründen abzudecken.

    Tests fangen damit an das deine Software Architektur es hergeben muss das man seine kleinsten Teile unabhängig testen kann ; einfachste Unit Tests eben. Das ist schon etwas das in früheren Jahren nicht gemacht wurde, selbst heute finden sich Szenarien da schalten auch Entwickler die Tests ab, wenn das die Entwicklung behindert. Gut ist das sicherlich nicht, aber unendlich Zeit und Geld hat man eben auch nicht.

    > Bsp bei uns, Kunde meldet sich und sagt: Umstellung des Produktivsystems
    > funktioniert nicht, auf dem Testsystem hat es aber geklappt.
    > Erste Rückfrage die gestellt wird an den Kunden:
    > Was haben Sie denn getestet?
    > Antwort vom Kunden: Na wir sind das einmal mit den und den Einstellungen
    > durchgegangen und dann davon ausgegangen, dass das mit den anderen
    > Einstellungen auch klappt.
    > Antwort an den Kunden:
    > Sehen se, sie haben also nicht getestet!
    > Fazit: wäre also vermeidbar gewesen, wenn man sich vorher nen Kopf darüber
    > gemacht hätte, was das Ergebnis sein soll und wie man das testet
    > (ausreichend!).
    > Kann man aber auch direkt mit "trial and error" machen, kostet am Ende halt
    > nur deutlich mehr Geld und bedeutet mehr Streß für die Verantwortlichen...

    Meine Aussage stimmt also weiterhin und dein beispiel zeigt es doch sehr gut.

    Du kannst "testen" , aber ob du das "richtige" Testest, das weißt du erst wenn es schiefläuft. Solange alle Tests erfolgreich sind, WARUM sollte da jemand auch nur denken das ein Fehler existieren könnte ?

    Das ist ja das trügerische an einer Testabdeckung. Wenn alles grün ist, gehen eben auch alle davon aus das es tut was es soll.
    Eine vollständige Testabdeckung hat man so oder so niemals.

    Knackig wird es eben, wenn etwas aus dem realen System einfach nicht in den Tests enthalten ist, oder eine Hardware die man simuliert, sich dann doch nicht so verhält im Betrieb (einfach weil die Spezifikationen nicht stimmen oder sonstwas).


    Da kann man "hinterher" immer sagen ; "Ja hättet ihr mal mehr getestet" , aber unter welcher Logik den ... Einfach nur Geld auf einen haufen werfen macht deine Software auch nicht besser.


    Tatsächlich sinnvolles Testen macht Sinn , aber das ist auch überraus schwer umzusetzen.

    Am Ende wird es IMMER Fehler geben die man nicht getestet hat, da gibt es garkeinen Weg dran vorbei und allein die Vorstellung das eine Software durch Tests "fehlerfrei" wird ist eben illusorisch.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. FRISTO GETRÄNKEMARKT GmbH, Buchloe
  2. ALDI International Services GmbH & Co. oHG, Dortmund, Duisburg, Mülheim
  3. ABO Wind AG, Wiesbaden
  4. Hottgenroth Software GmbH & Co. KG, Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Anno 2205 Ultimate Edition für 11,99€, Rayman Legends für 4,99€, The Crew 2 - Gold...
  2. 3,50€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Open-Source-Mediaplayer: Die Deutschen werden VLC wohl zerstören
Open-Source-Mediaplayer
"Die Deutschen werden VLC wohl zerstören"

Der VideoLAN-Gründer Jean-Baptiste Kempf spricht im Golem.de Interview über Softwarepatente und die Idee, einen Verkehrskegel als Symbol zu verwenden.
Ein Interview von Martin Wolf

  1. 20 Jahre VLC Die beste freie Software begleitet mich seit meiner Kindheit

Bill Gates: Mit Technik gegen die Klimakatastrophe
Bill Gates
Mit Technik gegen die Klimakatastrophe

Bill Gates' Buch über die Bekämpfung des Klimawandels hat Schwächen, es lohnt sich aber trotzdem, dem Microsoft-Gründer zuzuhören.
Eine Rezension von Hanno Böck

  1. Microsoft-Gründer Bill Gates startet Podcast

IT-Unternehmen: Die richtige Software für ein Projekt finden
IT-Unternehmen
Die richtige Software für ein Projekt finden

Am Beginn vieler Projekte steht die Auswahl der passenden Softwarelösung. Das kann man intuitiv machen oder mit endlosen Pro-und-Contra-Listen, optimal ist beides nicht. Ein Praxisbeispiel mit einem Ticketsystem.
Von Markus Kammermeier

  1. Anzeige Was ITler tun können, wenn sich jobmäßig nichts (mehr) tut
  2. IT-Jobs Lohnt sich ein Master in Informatik überhaupt?
  3. Quereinsteiger Mit dem Master in die IT