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. STRABAG BRVZ GMBH & CO.KG, Stuttgart
  2. Basler AG, Ahrensburg bei Hamburg
  3. PKF Fasselt Schlage Partnerschaft mbB, Braunschweig
  4. FREICON GmbH & Co. KG, Freiburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. 5€ inkl. FSK-18-Versand
  2. 5€ inkl. FSK-18-Versand
  3. (u. a. 3 Blu-rays für 15€, 2 Neuheiten für 15€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Alienware m15 vs Asus ROG Zephyrus M: Gut gekühlt ist halb gewonnen
Alienware m15 vs Asus ROG Zephyrus M
Gut gekühlt ist halb gewonnen

Wer auf LAN-Partys geht, möchte nicht immer einen Tower schleppen. Ein Gaming-Notebook wie das Alienware m15 und das Asus ROG Zephyrus M tut es auch, oder? Golem.de hat beide ähnlich ausgestatteten Notebooks gegeneinander antreten lassen und festgestellt: Die Kühlung macht den Unterschied.
Ein Test von Oliver Nickel

  1. Alienware m17 Dell packt RTX-Grafikeinheit in sein 17-Zoll-Gaming-Notebook
  2. Interview Alienware "Keiner baut dir einen besseren Gaming-PC als du selbst!"
  3. Dell Alienware M15 wird schlanker und läuft 17 Stunden

Elektromobilität: Der Umweltbonus ist gescheitert
Elektromobilität
Der Umweltbonus ist gescheitert

Trotz eines spürbaren Anstiegs zum Jahresbeginn kann man den Umweltbonus als gescheitert bezeichnen. Bislang wurden weniger als 100.000 Elektroautos gefördert. Wenn der Bonus Ende Juni ausläuft, sind noch immer einige Millionen Euro vorhanden. Die Fraktion der Grünen will stattdessen Anreize über die Kfz-Steuer schaffen.
Eine Analyse von Dirk Kunde

  1. Elektromobilität Nikola Motors kündigt E-Lkw ohne Brennstoffzelle an
  2. SPNV Ceské dráhy will akkubetriebene Elektrotriebzüge testen
  3. Volkswagen Electrify America nutzt Tesla-Powerpacks zur Deckung von Spitzen

Tesla: Kleiner Gewinn, ungewisse Zukunft
Tesla
Kleiner Gewinn, ungewisse Zukunft

Tesla erzielt im vierten Quartal 2018 einen kleinen Gewinn. Doch mit Entlassungen, Schuldenberg, Preisanhebungen beim Laden, Wegfall des Empfehlungsprogramms und zunehmendem Wettbewerb durch andere Hersteller sieht die Zukunft des Elektroauto-Herstellers durchwachsen aus.
Eine Analyse von Dirk Kunde

  1. Tesla Model 3 Tesla macht alle Varianten des Model 3 günstiger
  2. Kundenprotest Tesla senkt Supercharger-Preise wieder
  3. Stromladetankstellen Tesla erhöht Supercharger-Preise drastisch

  1. Wochenrückblick: Kein Download vom Mars, kein Upload ins Netz
    Wochenrückblick
    Kein Download vom Mars, kein Upload ins Netz

    Golem.de-Wochenrückblick EU-Unterhändler bürokratisieren mit Leistungsschutzrecht und Uploadfilter das Internet. Am Mars geht Opportunity in Rente. Zurück auf der Erde fühlen wir uns eingeschnürt.

  2. Streaming: Netflix zahlt in deutsche Filmförderung ein
    Streaming
    Netflix zahlt in deutsche Filmförderung ein

    Netflix beendet den Rechtsstreit und zahlt einen Umsatzanteil an die deutsche Filmförderung. Die Filmabgabe, die neben den Kinos von der Videowirtschaft und dem Fernsehen erhoben wird, sollen nun alle Streaminganbieter zahlen.

  3. Netzbetreiber: Ericsson und Nokia könnten Huawei nicht ersetzen
    Netzbetreiber
    Ericsson und Nokia könnten Huawei nicht ersetzen

    Ein führender europäischer Netzbetreiber fürchtet um seinen 5G-Ausbau, sollte Huawei ausgeschlossen werden. Die beiden europäischen Ausrüster könnten hier nicht so einfach einspringen. Auch die GSMA warnt eindringlich.


  1. 09:02

  2. 19:17

  3. 18:18

  4. 17:45

  5. 16:20

  6. 15:42

  7. 15:06

  8. 14:45