Slide von der diesjährigen FPGA Conference: 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der FPGA-Entwicklungen liegen hinter dem Zeitplan. Bei aller selbstkritischen Betrachtung, zeigt es IMHO eher das Planungen/Aufwandsabschätzungen sehr unrealistisch sind und bug-freiheit nicht unbedingt ein Kriterium für den Erfolg ist. (Die Angabenwurden zum Anfang eines Vortrages über "Debug/Verification FPGA - Lint" gemacht.)
Angehängte Dateien:
-
AllBuggy.jpg
71 KB
Außerdem sind 100% aller Statistiken, die ich nicht selbst erstellt habe, entweder gefälscht oder frei erfunden.
Bradward B. schrieb: > zeigt es IMHO eher das Planungen/Aufwandsabschätzungen sehr > unrealistisch sind Na ja, das Ergebnis von Scrum halt. Vorher keine Ahnung und dann nachreichen, dazuwünschen, dranflicken. Wenn vorher klar beschrieben wäre, was implementiert werden soll, dann wurde man auch ein Ergebnis in den Händen halten. Früher gab es den Begriff der "eleganten Lösung": Die war dann gegeben, wenn mit minimalem Zeit- und Kostenaufwand die bestmögliche Lösung erzielt wurde. Bei den heutigen Schlipsträgern und Anzugständern ist genau das aber nicht erwünscht, kostet es doch Monate satten Gehalts, wenn ein Problem vorzeitig und womöglich zur Zufriedenheit des Auftraggebers gelöst wird. Unser Land lebt mittlerweile davon, Probleme zu züchten und zu verwalten, anstatt sie erfolgreich zu lösen.
Jaha, früher war alles besser. Da haben wir monatelang Pflichtenhefte erstellt, dann Architekturdokumente geschrieben, darausndann Grob- und Feinspezifikationen abgeleitet. Nach 2 Jahren wussten wir dann ganz genau, dass wir noch 1 Jahr für die Implementierung und ein weiteres für alle Compliance-Tests brauchen würden. Und waren dann auch fast pünktlich. Nach weiteren 2 Jahren war das Produkt dann auch so, wie es der Kunde wirklich haben wollte. Heute sind wir nach einem halben Jahr mit einem MVP auf dem Markt und nach 2 Jahren ist das Produkt etabliert. V-Modell vs Agile halt.
:
Bearbeitet durch User
Bradward B. schrieb: > Slide von der diesjährigen FPGA Conference: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Was soll ich mit so einer Aussage/Zahl jetzt anfangen? Ein Marketing-Aufknuepfer fuer eine statische Analyse-Methode? Ansonsten ist das Phaenomen relativ allgemeingueltig auf Software anwendbar, ob V-Modell oder agil spielt vermutlich nicht mal mehr gross die Rolle, es wird halt einfach nicht ausreichend getestet, oder noch besser, der Kunde streicht diese rund 50% an im Projekt allozierter Zeit fuer Testphase weg, damit's weniger kostet. Dazu kommt halt auch noch, dass die HDL-Verifikationsmethoden modernen Testansaetzen 20 Jahre hinterherhinken. Gottseidank gibt es immer noch Firmen, die klassische Meilensteine abfruehstuecken und die Grenzen zwischen Prototyp und Produkt ganz klar definieren. Aber wehe, es rueckt da die naechste Generation ins Management vor...
Bradward B. schrieb: > Slide von der diesjährigen FPGA Conference: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Das heißt dass 16% der Impementierungen fehlerfrei sind und 30% der Projekte innerhalb des Zeitplans angeschlossen werden? Von solchen Zahlen kann man hier in der Firma nur träumen. Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung findet man den einen oder anderen Bug.
:
Bearbeitet durch User
> Was soll ich mit so einer Aussage/Zahl jetzt anfangen? Die zeigen halt wie gut und zuverlaessig FPGA sind weil 99% aller Anwendungen mit Microcontrollern bei der Auslieferung noch Bugs enthalten. Da sind FPGAs schonmal deutlich besser. :-D > Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung > findet man den einen oder anderen Bug. Yep! Aber da braucht man sich gar nicht an die eigene Nase packen. Ich brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER Bugs. Der Welt war noch okay als es nur maskenprogrammierte Controller gab. Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie SEHR genau ueber Fehler nachgedacht haben. Heute: Oh koennte ein Bug drin sein? Egal, naechste Firmware... Vanye
Vanye R. schrieb: > Der Welt war noch okay als es nur maskenprogrammierte Controller gab. > Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie > SEHR genau ueber Fehler nachgedacht haben. Vielleicht auch weil in diese Controller auch einfach nur sehr simple Programme rein passten? So eine heutige Megabytes große Firmware mit Frameworks, RTOS, Protokollstacks hat einfach viel mehr Möglichkeiten für Fehler, gerade auch wenn diese externen Komponenten proprietär sind und man sie nicht prüfen/reparieren kann. Vanye R. schrieb: > Ich brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes > Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER > Bugs. Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch wirklich nicht der Spezifikation entsprechen?
> Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät > (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch > wirklich nicht der Spezifikation entsprechen? ABS nutzt man ja wenig, aber jetzt wo du es sagst, ich hab mich letztes bei Regen mal um 360Grad gedreht wegen Aquaplaning, (mir ist aber nix passiert) da hat das System wohl verwirrende Info vom Drehratensensor bekommen und auch die Raeder werden sich mal kurz rueckwaerts gedreht haben und ABS und DSC haben sich bis zum naechsten Motorstart abgeschaltet. Aber sowas mach ich natuerlich nicht jeden Tag. Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber einen Hebel einschalten und er macht dann was er soll, also die Scheiben wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit es wieder geht. Vanye
Vanye R. schrieb: > da hat das System wohl verwirrende Info vom Drehratensensor bekommen Na dann ist es aber kein Software Bug. Vanye R. schrieb: > Aber mein Regensensor hat einen lustig Bug Na das ist aber eine Komfort Funktion
Na, warum heißen die wohl field programmable gate array und nicht factory programmable gate array? „Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten Release beheben.“
Da kann man natuerlich nicht widersprechen. :-D Vanye
Philip S. schrieb: > Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten > Release beheben.“ Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert wurden, nur um den vertraglichen Termin einzuhalten. Die ersten Nachfragen kamen aber erst ein Vierteljahr später, solange hat sich der Kunde nicht um seine Lieferung gekümmert....
> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert > wurden, nur um den vertraglichen Termin einzuhalten. Haha, bei sowas war ich auch mal dabei. (nicht in meiner aktuellen Firma) > Die ersten Nachfragen kamen aber erst ein Vierteljahr später In meinem Fall war der Kunde darüber informiert und wollte das auch so, wegen seltsamer Budget-Regelungen beim Staat...
Niklas G. schrieb: > Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät > (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch > wirklich nicht der Spezifikation entsprechen? Ein paar hundert. Kommt halt drauf an, wo man arbeitet.
Michael B. schrieb: > Ein paar hundert. > > Kommt halt drauf an, wo man arbeitet. In Laberstadt können das leicht auch ein paar Tausend werden.
Bradward B. schrieb: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen maturity states aller FPGA-Designs, die so umherschwirren? Abgesehen davon stimme ich dem generellen Tenor der Aussage zu und liefere eine Begründung für die häufigen Zeitüberzüge: Die meisten Planer in dem Bereich sind Projektleiter, die selber nur kurz in dem Thema selber aktiv waren, oft ein fachfremdes Studium hatten, sich das selber beigebracht haben und die Details gnadenlos unterschätzen. Das kennt man. Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen können) oder doch eher in den Konzepten und der Zusammenarbeit mit anderen Komponenten? Da heute viel SW obendrauf kommt und hier komplexere Handlungsabläufe eine Rolle spielen, kommt es da auf einen guten (Echzeit-)Systementwurf an. Den können aber viele nicht, weil sie das nie erlernt haben, da "selber reingearbeitet". Das wird auch nicht an allen Unis gemacht. Als Folge liefert da jeder Insellösungen und es bedarf sehr aufwändiger Verifikationen um Probleme zu finden. Oft genug sind die Leute auch nicht in der Lage, die Fälle zu antizipieren und zu modellieren. Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten der FPGA-Systemplaner.
:
Bearbeitet durch User
Fehlerfreie Softwareprojekte gibt es praktisch nicht. Und was den Zeitplan angeht, ist es in der Regel so, daß er anfangs auf zahlreichen unklaren Annahmen beruht, die im Laufe des Projektes geändert werden. Oft werden zwischendurch auch die Anforderungen geändert. Ein gerissener Zeitplan ist selten ein Indiz für mangelhafte Umsetzung, sondern für falsche Einschätzung im Vorfeld.
:
Bearbeitet durch User
>> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert >> wurden, nur um den vertraglichen Termin einzuhalten. >> Die ersten Nachfragen kamen aber erst ein Vierteljahr später > > In meinem Fall war der Kunde darüber informiert und wollte das auch so, > wegen seltsamer Budget-Regelungen beim Staat... Hm, vielleicht weil manche Projekte über den "Geldmittelabfluss" gesteuert überwacht werden. Da ist irgendwann mal vereinbart wurdendas jedes Quartal xy Mio überwiesen werden und Nachweis über deen Verbrauch (Stundenabrechnung) zu erbringen ist. Wird das Budget nicht über den Mittelabluss wie gaplant entlerrt sorgt man sich über Terminverschiebung ... Terminplanung ist IMHO mehr Werkzeug als leistungs-kennziffer ... die Softwareabteilung muss halt in der Lage sein zeitnah das von der Hardware-abteilung zugeliefrete FPGA-Board zu übernehmen resp. an den µC etc darauf/daran weiterzuentwickeln. Und nicht, das die HW-Abteilung grad mit Produktion und Inbetriebnahme fertig zu sein hat, wenn die SW und andere folgenden Gewerke grad Zeit dafür haben könnten. Liefer-Termine sind IMHO besser als "IST-Wert" denn als "SOLL-Wert" anzusehen.
:
Bearbeitet durch User
J. S. schrieb: > Bradward B. schrieb: >> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der >> FPGA-Entwicklungen liegen hinter dem Zeitplan. > > Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen > maturity states aller FPGA-Designs, die so umherschwirren? Die stammen wohl von sehr geduldigen Papier; Unis und staatlich nahe Unternehmen erzeugen sowas immer mal wieder, wobei viel Statistik noch aus der Ära stammt in der man die "Softwarekrise" thematisierte, also vor etlichen Jahrzehnten. > Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In > der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen > können) oder doch eher in den Konzepten und der Zusammenarbeit mit > anderen Komponenten? ... > Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da > fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten > der FPGA-Systemplaner. Ja, eigentlich sind andere Kriterien im Fokus zu halten: Testabdeckung, Systemkomplexität, Fehlertoleranz Manche Projektleiter gehen davon aus das man fehler "heraustesten" kann, also egal wie "shitty" Spec und Architectur ist, lang genug getestet kriegt man schon Kundenzufriedenheit rein. Andere dagegen setzen eher auf einfache Systeme bei denen nicht viel schief laufen kann und legen die "Architektur" soaus, das im "Brandfall" nicht viel passiert resp. man sich in Sicherheit bringen kann. Beispielsweise "reset" - der Bediener muss in der Lage sein, bei Fehlverhalten der Maschine zügig neu anfangen zu können resp. die Maschine in einen Zustand zu versetzten in der diese auf Benutzereingaben reagiert.
Ich habe mittlerweile einiges an (Software)-projekten begleitet und die größte Gefahr für Terminverzug und Bugs war meistens die Selbstüberschätzung und Verbohrtheit von Entwicklern. Da wird gemauert und Projektpläne werden sabotiert weil man der Meinung ist man wüsste besser was wie und warum implementiert werden soll. Da werden die eigenen Aufwände völlig unrealistisch eingeschätzt und falsche Rückmeldungen an die Projektleitung gegeben. Da werden vorhandene Lösungen ignoriert und einfach weggeschmissen weil einem irgendwas nicht passt oder weil es jemand anderes implementiert hat. Alles schon gehabt, auch ich selber. Manche lernen und werden erwachsen, manche ändern sich nie. Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß.
Richard W. schrieb: > Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß Vor allem, wenn man, so wie du, nicht die leiseste Ahnung von Programmieren hat. Die korrekte Antwort, wenn man einen Programmierer fragt, wie lange es dauert, den Fehler zu beheben oder das feature zu implementieren, lautet nämlich 'keine Ahnung, weisst du wir lange die Suche nach der Nadel im Heuhaufen dauert'. Aber so was akzeptieren die dümmsten der dummen Projektleiter ja nicht, also bekommen sie irgendeine Zahl genannt, UND ZWAR MEIST EINE ZU NIEDRIGE, man will den Projektleiter ja nicht verärgern. Und an statt dass der Projektleiter aus Erfahrung die Zeit mit 10 multipliziert (90% schafft man in 10% der Zeit aber die letzten 10% brauchen 90% der Zeit), addiert er optimistisch 5+5+5=10, man muss halt bloss die Peitsche stärker schwingen. Richard W. schrieb: > gemauert und Projektpläne werden sabotiert weil man der Meinung ist man > wüsste besser was wie und warum implementiert werden soll Sie wissen es besser. Dein Projektplan ist das Dumme. Fremder code ist meist so schwer zu verstehen, dass es 10 x länger dauert ihn einzusetzen, als neu zu schreiben. Allerdings nur für die ersten 90% (siehe oben). Die restlichen 10% dauern dann eben wieder, aber da jeder Projektleiter so geil ist gleich Ergebnisse zu sehen, fährt man mit abgelieferten 90% besser. Du bist wirklich ein Paradebeispiel dafür, was in der Softwareentwicklung falsch läuft.
So sehen Bilder aus, die von russischen Spionen kommen, die schnell im Vorbeilaufen noch eben rasch einen Schnappschuss...
Auch wenn das Niveau oben wieder ins unterguertelige absinkt: Lasst die designierten Projektleiter halt einfach das Testen, aber nicht die Vorgabe eines Zeitplans uebernehmen. Dann sind sie immerhin verstaendige Projektleiter. Ein guter Projektleiter wiederum nimmt Ruecksicht auf die Belange aelterer Entwicklerkollegen, die mit modernen Softwaremethoden nicht klarkommen und holt sich notfalls ein paar Human Interfaces dazu, die zwischen retro und Industrie 4.0 die Bruecken schlagen und ab und an eine Runde Eis spendieren. NB: Ich hatte eine Weile lang den Spass, als externer Feuerwehrmann solche kraenkelnden Projekte zum Abschluss zu bringen, damit keine dicken Konventionalstrafen eines riesigen A-Konzerns faellig wurden. Wirklich, viele Probleme loesen sich mit einer Runde Eis, und damit, dass bestehende Hierarchien/Blockaden durch die Externen umgangen werden koennen. Alles andere ist einfach nur polemisches Gelaber aus dem Frustrationsbuero/Besserwisseretage, mit Verlaub. Viel mehr wuerde mich interessieren, wer noch ausgiebig statische Code-Analyse a la lint in der HDL benutzt, reicht jetzt aber auch wieder mit der Trollwiese.
Vanye R. schrieb: > Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber > einen Hebel einschalten und er macht dann was er soll, also die Scheiben > wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man > muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit > es wieder geht. VW, oder? Meiner macht das auch.
Martin S. schrieb: > Human Interfaces dazu, die zwischen retro und Industrie 4.0 die Bruecken > schlagen Sowas wie RFC 1149?
> VW, oder? Meiner macht das auch.
Noe, BMW. Aber vielleicht kommt ja beides von Bosch oder so...
Vanye
Mein alter Citroen, den ich kürzlich nach 16 Jahren verkauft habe, hatte das selbe Feature mit dem Regensensor. In der Werkstatt hatte mir einmal jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt, wenn plötzlich unerwartet der Scheibenwischer anspringt...
Vancouver schrieb: > In der Werkstatt hatte mir einmal > jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt, Vielleicht um den Fahrer vor Regressansprüchen von AnDerAmpelUngewolltScheibenPutzern zu schützen, wie man sie in manchen Ländern sieht?
Bei meinem VW (BJ 2016) funktioniert der Regensensor immer, der wird nur in der Waschanlage ausgeschaltet. Er hat aber einen anderen lustigen Bug: Um von Stellung "P" des Automatikgetriebes wegezuschalten, muss man auf der Bremse stehen. Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd aus wenn man Gas gibt und nicht vom Fleck kommt. Nochmaliges Bremsenbetätigen hilft dann.
Klaus schrieb: > Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt > das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd > aus wenn man Gas gibt und nicht vom Fleck kommt. > Nochmaliges Bremsenbetätigen hilft dann. ... und löst beim Hintermann Panik aus ;)
Markus F. schrieb: > und löst beim Hintermann Panik aus Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die Bremse betätigt?
Nemopuk schrieb: > Markus F. schrieb: >> und löst beim Hintermann Panik aus > > Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die > Bremse betätigt? Auf dem Parkplatz stehend nicht. Aber durch die Waschanlage geht man ja normalerweise auf N und muß am Ende erst auf die Bremse, um nach D zu kommen und loszufahren. Das kann durchaus den Hintermann etwas überraschen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.