Abo
  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.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ENERCON GmbH, Aurich
  2. BWI GmbH, Nürnberg, München, deutschlandweit
  3. HYDAC INTERNATIONAL GmbH, Großbeeren
  4. Ruhrverband, Essen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 319,90€ (Bestpreis!)
  2. (aktuell u. a.Transcend 256-GB-SSD 41,49€, Chieftec 550/600W Netzteile ab 42,90€)
  3. 229,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energie: Warum Japan auf Wasserstoff setzt
Energie
Warum Japan auf Wasserstoff setzt

Saubere Luft und Unabhängigkeit von Ölimporten: Mit der Umstellung der Wirtschaft auf den Energieträger Wasserstoff will die japanische Regierung gleich zwei große politische Probleme lösen. Das Konzept erscheint attraktiv, hat aber auch entscheidende Nachteile.
Eine Analyse von Werner Pluta


    Cascade Lake AP/SP: Das können Intels Xeon-CPUs mit 56 Kernen
    Cascade Lake AP/SP
    Das können Intels Xeon-CPUs mit 56 Kernen

    Während AMD seine Epyc-Chips mit 64 Cores erst im Sommer 2019 veröffentlichen wird, legt Intel mit den Cascade Lake mit 56 Kernen vor: Die haben mehr Bandbreite, neue Instruktionen für doppelt so schnelle KI-Berechnungen und können persistenten Speicher ansprechen.
    Von Marc Sauter

    1. Cascade Lake Intel legt Taktraten der Xeon SP v2 offen
    2. Optane DC Persistent Memory So funktioniert Intels nicht-flüchtiger Speicher
    3. Cascade Lake AP Intel zeigt 48-Kern-CPU für Server

    Mobile-Games-Auslese: Rollenspiel-Frühling mit leichten Schusswechseln
    Mobile-Games-Auslese
    Rollenspiel-Frühling mit leichten Schusswechseln

    Action im Stil von Overwatch bietet Frag Pro Shooter, dazu kommt Retro-Arcade-Spaß mit Cure Hunters und eine gelungene Umsetzung des Brettspiels Die Burgen von Burgund: Neue Mobile Games sorgen für viel Abwechslung.
    Von Rainer Sigl

    1. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS
    2. Indiegames Stardew Valley kommt auf Android
    3. Mobile-Games-Auslese Die Evolution als Smartphone-Strategiespiel

    1. Lokaler Netzbetreiber: Inexio baut Glasfaser, auch wenn es sich nicht lohnt
      Lokaler Netzbetreiber
      Inexio baut Glasfaser, auch wenn es sich nicht lohnt

      Der Glasfaser-Ausbau bis an die Straßenecke kostet 2.000 Euro pro Kunde, bis ins Haus sind rund 5.000 Euro fällig. Dennoch setzt Inexio verstärkt auf FTTH, auch wenn sich dem Kunden dafür nicht viel mehr berechnen lässt.

    2. Volkswagen: 5G bietet flexible Software-Betankung in der Produktion
      Volkswagen
      5G bietet flexible Software-Betankung in der Produktion

      Volkswagen will mit 5G in der Produktion flexibel große Datenmenge in die Fahrzeuge einspielen. Campusnetze könnten auch zusammen mit Netzbetreibern laufen.

    3. Amazon vs. Google: Youtube kommt auf Fire TV, Prime Video auf Chromecast
      Amazon vs. Google
      Youtube kommt auf Fire TV, Prime Video auf Chromecast

      Fire-TV-Geräte erhalten erstmals eine offizielle Youtube-App von Google. Dafür integriert Amazon eine Chromecast-Unterstützung in die Prime-Video-App. Andere Streitpunkte zwischen Amazon und Google bleiben hingegen bestehen.


    1. 19:10

    2. 18:20

    3. 17:59

    4. 16:31

    5. 15:32

    6. 14:56

    7. 14:41

    8. 13:20