Guten Morgen, mich interessiert wie professionelle Entwickler die Elektronik von(Controllergesteuerten) Geräte entwickeln. Ich denke an Geräte wie Waschmaschinen, Gefrierschränke, Kaffeemaschinen, DVD-Player etc. Eben alles was potentiell von einem 8-Bitter gesteuert wird. Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit Pflichtenheft, Struktogramm und Coding... Wie oft ändert sich das Design während einer Eintwicklung? Was passiert bei Erweiterungen? Eben wie das so abläuft .... Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt: Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen oder ich Erweitere das Gerät um einen weiteren Controller der dann Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren Controller zu nehmen ... Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit kommt mit dem Essen) nicht evtl. völlig falsch war ... Gruß Andreas
Auch nicht anders, falls so eine allgemeine Frage überhaupt beantwortet werden kann. Die Fragen sind die gleichen und das ultimativ perfekte Design gibt es nirgendwo, bzw. nur bis zur nächsten Änderung. Wenn genug Geld/Zeit vorhanden ist werden schon mal mehrere Designs beauftragt nur um sich ein Bild zu machen, aber das ist eher die Ausnahme. Equipment Erfahrung und Knowledge sind in einer anderen Dimension, aber so weit ich das überblicken kann, kochen alle mit Wasser. Und Rapid Prototyping nützt wenig da die Designprozesse nicht vom Design abhängen sondern von den Prozessen (Firmenstrukturen). Je größer der Laden ist um so aufwändiger wird das drumherum. Stichworte: Keil, IAR, Hitex, In Circuit Debug, usw
UBoot-Stocki wrote: > Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit > Pflichtenheft, Struktogramm und Coding... Bei uns geht das so, dass zunächst mal der Kunde in die Mangel genommen wird. Was will er genau haben. Das hört sich einfach an, ist aber mitunter einer der schwierigsten Punkte im ganzen Projekt: Aus dem Kunden seine genauen Vorstellungen rauskitzeln und das ganze so in Schriftform giessen, dass er das als Auftrag dann auch unterschreibt. Dabei auf all die kleinen Nebenbedingungen nicht vergessen, die einem später das Leben schwer machen werden und an die zum jetzigen Zeitpunkt keiner denkt (die aber später massiv Geld kosten werden). Wenn dein Kunde sagt: "Ach, das ist ganz einfach, das geht so ..." oder "Das brauchen wir nicht" oder "Das kommt in der Praxis nicht vor", dann diese Aussage im Detail unbedingt festhalten bzw. nachbohren. Gerade dieses "Das kommt nicht vor" stellt sich im Nachhinein oft als Boomerang heraus. Danach setzt sich ein Entwickler hin und überlegt mal in groben Blöcken, wie man die Kundenvorstellungen realisieren kann. Dabei muss er einen Überblick bekommen, was an Input notwendig ist und was als Output vom Programm rauskommen soll. Er überlegt sich, welches UI dafür adequat wäre, wobei er darauf achtet, möglichst vorhandene UI-Elemente wiederverwenden zu können. Wenn das gelingt ist es gut, wenn nichts da ist, kann man sich überlegen ob man die Aufgabenstellung ein wenig in die Richtung treiben kann, so dass irgendwas von der Halde passt. Wenn alle Stricke reißen, muß man was Neues erfinden. Steht das ganze soweit und ist auch der Schritt 'Verarbeitung' in groben Zügen klar, dann gehen wir das mit dem Kunden noch mal durch. Zur Verarbeitung (also: wie du die Logik aufziehst) wird er nicht viel sagen. Erstens vertraut er dir, dass du schon weißt was du tust, zweitens ist es für Durchschnittskunden extrem schwer, eine logische Abfolge von vielen Kommandos mit seinen Vorstellungen zu vergleichen, egal wie du sie ihm präsentierst. Aber zum UI wird er sich äußern und das ist gut so. Das vermeidet zum einen, dass er hinterher sagt "Ich hab mir das aber ganz anders vorgestellt" zum anderen gibt es dir Hinweise, ob du bei der Verarbeitung etwas übersehen hast. Wenn der Kunde zb. auf der Output Seite unbedingt noch einen zusätzlichen Wert angezeigt haben will, dann hast du was übersehen. > Wie oft ändert sich das Design während einer Eintwicklung? Was passiert > bei Erweiterungen? Im Idealfall ändert sich dann nichts mehr. Diesen Idealfall hab ich noch nie erlebt :-) OK. Wenn was rauskommt, dann treffen 2 Welten aufeinander. Hängt natürlich auch davon ab, wann diese Erweiterung notwendig wird. Ist es noch früh genug im Entwicklungsprozess, dann sind Entwickler normalerweise kooperativ, solange das nicht das Gesamtsystem komplett umdreht. Je mehr sich aber die Dead-Line nähert, desto mehr werden Entwickler anfangen zu mauern. Erfahrene Entwickler haben längst gelernt, dass es tödlich ist, 2 oder 3 Wochen vor Abgabe noch irgendwelche großartigen Design-Änderungen zu akzeptieren. Das führt letztendlich immer zu versteckten Fehlern in bereits einwandfrei funktionierenden Programmteilen, die der Kunde dann dir anlasten wird. In so einem Fall gilt die Devise: Die gewünschte Änderung in einen neuen Auftrag verchieben, der nach dem laufenden Auftrag abgehandelt wird und erst beginnt, wenn das bisherige vom Kunden abgenommen wurde. Sonst wartest du nämlich ewig auf dein Geld und Gehälter wollen schliesslich auch bezahlt werden. > Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt: > Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen > oder ich Erweitere das Gerät um einen weiteren Controller der dann > Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren > Controller zu nehmen ... In so einem Fall, wird man versuchen, zu retten was zu retten ist ohne allzu gravierende Änderungen vorzunehmen. Die Variante, die am wenigsten Softwareänderungen verursachen wird, ist es, einen größeren Controller zu nehmen, sofern der kompatibel ist. Ein zusätzlicher Controller bringt eine neue Komponente ins Spiel: Die beiden müssen miteinander kommunizieren können. Und das unter allen Umständen oder Sonderfällen. Wenn dein System nicht von vorne herein auf solche Multitasking Spezialitäten ausgelegt war, dann handelst du dir damit einen neuen Sack Flöhe ein, die mit deinem eigentlichen Problem (neue Funktionalität) erst mal gar nichts zu tun hat, dein Komplettsystem aber trotzdem lahmlegen kann. > Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der > bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit > kommt mit dem Essen) nicht evtl. völlig falsch war ... Kommt immer drauf an, wie gross der Appetit wird. Einem Kunden wirst du natürlich nicht jede gewünschte Änderung abschlagen. Du musst ihn auch etwas bei Laune halten. Aber grundsätzlich lautet die Devise: Sieh zu, dass du zuerst das realisierst, was du ursprünglich mit dem Kunden ausgemacht hast. Erweiterungen bzw. Änderungen kannst du jetzt schon im Softwaredesign berücksichtigen (also etwas Vorarbeit leisten), aber so dass sie der Kunde sieht, wird es erst realisiert, wenn der Folgeauftrag da ist. Grundsätzlich halte ich den Ansatz des 'iterativen Modells' für so schlecht nicht. Für gewerbliche Zwecke kann das zwar mächtig ins Auge gehen, aber für Privat ist das OK. So sammelt man nämlich dann auch Erfahrung, wie man Module aufbaut, so dass der Aufbau nicht vor möglicher Felxibilität untergeht, man sich aber auf der anderen Seite auch nicht eine Weiterentwicklung mutwillig verbaut. Das ist eine Gratwanderung, die mal lernen muss. Ab und an auch mal den Schritt zurück machen und das Gesamtsystem betrachten. Wie könnte man Dinge vereinfachen, wenn man 'in Stein gemeisseltes' Urgestein verändert. Für solche Betrachtungen hab ich schon oft Testprogramm-Systeme gebaut. Einfach nut um zu sehen, wo mich eine Änderung hinführen wird, welche Auswirkungen bestimmte Änderungen haben werden, was sich vereinfacht, was komplizierter wird. Auf die Art sammelt sich dann ein Fundus an erprobten Methoden an.
Karl heinz Buchegger wrote: > Aus dem > Kunden seine genauen Vorstellungen rauskitzeln und das ganze so in > Schriftform giessen, dass er das als Auftrag dann auch unterschreibt. Und falls Nachfragen entstehen, weil etwas vorher nicht hunderprozentig klar war: SCHRIFTLICH, niemals per Telefon. "Ja, aber wenn wir das anders umsetzen ist [abuse hier einsetzen] möglich, wollen Sie das wirklich?" Wen hatte ich zwei Wochen später unfreundlich motzend am Telefon? Bzw wessen Chef?
Dito... Bei uns (und ich denke eigentlich ueberall) ist das schwierigste, genau zu wissen und zu erfahren, was der Kunde genau will. Die weiteren Schritte sind etwas Kunden-, Betriebs- und Designer abhaengig. Mancher Kunde will genau DEN Controller, andere sagen "8 Bit passt doch, Hersteller egal". Hat die Firma vielleicht Vertraege mit Controller-Herstellern, ist klar, was gewaehlt wird. Hat die Firma vielleicht x-Jahre Erfahrung mit einem Controllertyp gesammelt und massiv Design- und Coderessourcen angehaeuft, ist auch klar, was gemacht wird bzw. wo die Prioritaet sitzt. Manche Peripherie laesst sich anhand des Controllers auswaehlen, bei anderen ist es eine reine Kosten- und/oder Glaubensfrage. Es bleibt aber vielfach eine einfache Frage der vorhandenen Ressourcen, warum irgendwas ganz neu machen, wenn es schon fuer einen anderen Controller da ist? Es sei denn natuerlich, der Kunde will es so und bezahlt dafuer :) Wir starten hier normalerweise mit DemoBoards, die auf dem selben Controller aufbauen wie das Projekt spaeter dann auch. Es wird zumeist eines gewaehlt, dass moeglichst viel der spaeteren Peripherie bereits mit dabei hat. Anhand der mitgelieferten Schematics hat der Designer in manchen Punkten dann einen Anhaltspunkt, und die Software Leute koennen parallel auf dem DemoBoard schon arbeiten. Spaeter wird das zusammengefuegt. Das erste Design hat meist einige Schwachstellen und Kinderkrankheiten. Es dauert manchmal 1-2 Tage, bis die Software Leute problemlos ihren Code da reinkriegen. die meisten Redesign-Issues kommen dann auch aus der Software-Schmiede, die diverse kleine Fehler finden. Zusaetzlich ueberpruefen die Hardware Leute ihr Design noch selber, werden sicherlich kleinere Maengel an Footprints und Shapes finden (was ihr Ego nicht unerheblich erschuettert :) ). Das Redesign Spiel geht solange, bis es passt. Gaengig sind eigentlich 2 oder 3 Versionen, bei groesseren Sachen auch mal 4 oder 5. Sollte man aber nicht haeufig machen, kostet nur :)
> Bei uns (und ich denke eigentlich ueberall) ist das schwierigste, genau > zu wissen und zu erfahren, was der Kunde genau will. Leider wissen die meisten Kunden selber nicht so genau, was sie eigentlich wollen...
>Leider wissen die meisten Kunden selber nicht so genau, was sie >eigentlich wollen... Einige Forenbesucher auch nicht...(LED soll blinken...)
Im Prototypen wird erstmal ein Kontroller mit relativ viel Speicher verwendet, damit es da keine Zeitverluste gibt. Fuer die Grossserie (dazu kam es dann aber nicht) wird dann abgespeckt.
UBoot-Stocki wrote: > Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit > Pflichtenheft, Struktogramm und Coding... Pflichtenheft wäre schön, in der Praxis wirds leider selten richtig genutzt. > Wie oft ändert sich das Design während einer Eintwicklung? Zu oft. > Was passiert > bei Erweiterungen? Wenn möglich als extra Projekt einstufen, d.h. neuer Auftrag, neue Entwicklungszeit. > Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt: > Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen > oder ich Erweitere das Gerät um einen weiteren Controller der dann > Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren > Controller zu nehmen ... Oftmals ist ein altes Projekt so vergurkt, daß eine neue CPU nichts bringt. Der Flaschenhals ist nicht die Rechenleistung, sondern der Ablauf. Es wird Rechenzeit an falschen Stellen vergeudet. Ein weitere Controller ist so ziemlich das schlimmste, weil man dann erstmal ein zuverlässiges, echtzeitiges, fehlertolerantes Kommunikationsprotokoll entwickeln muß. Die effektivste Methode ist, nochmal von vorne anzufangen, d.h. ein neuer Programmablaufplan. Klingt erstmal aufwendig, aber man weiß ja schon, wie das alte Projekt funktioniert hat. Und man wundert sich dann, wieviel sich nur durch den neuen Programmablauf alles optimieren läßt. > Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der > bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit > kommt mit dem Essen) nicht evtl. völlig falsch war ... Es reizt jeden Entwickler, beim neuen Projekt sofort den Editor zu öffnen und:
1 | main() |
2 | {
|
3 | ...
|
4 | }
|
zu schreiben. Aber das ist die mit Abstand ineffektivste Methode und dauert am längsten. Der beste Start eines Projekts ist, den PC auszuschalten und Papier und Bleistift zu nehmen. Peter
Juergen wrote: > Im Prototypen wird erstmal ein Kontroller mit relativ viel Speicher > verwendet, damit es da keine Zeitverluste gibt. Und genau dadurch ergeben sich dann erst recht Zeitverluste, weil es den Programmierer zu schludrigem, ungeplanten Programmieren von Spaghetticode verleitet. Das richtige Maß zu finden ist nicht einfach, da hilft eigentlich nur Erfahrung. Viel hilft jedenfalls nicht viel. Wenn ich viel Speicher habe, geht ja auch viel CPU-Leistung für die vielen Zugriffe drauf, d.h. die Leistung sinkt weiter. Ich versuche immer, die Abläufe in möglichst kleine universelle Funktionen zu zerlegen, damit sie schön einfach und übersichtlich sind (Ich habe leider kein Elefantengedächtnis für riesige Codemonster). Und damit sinkt der Speicherverbrauch automatisch mit. Peter
Peter Dannegger wrote: > Die effektivste Methode ist, nochmal von vorne anzufangen, d.h. ein > neuer Programmablaufplan. Stimme zu. Allerdings kriegt ein Kunde meistens einen Herzinfarkt, wenn du ihm das so erzählst :-) Da muß man dann öfter mal psychologisch etwas 'tricksen', ansonsten hängt dir der Kunde dieses Neuschreiben sofort als 'das geht aber auf eure Kappe' an. > Klingt erstmal aufwendig, aber man weiß ja schon, wie das alte Projekt > funktioniert hat. Und vor allen Dingen hat man einen wesentlichen Vorteil: Man hat speziell auf dieser Aufgabenstellung in der Zwischenzeit eine Menge Erfahrung gesammelt, kennt all die kleinen Problemchen und wie man sie, manchmal schlecht als recht, umgangen hat und kann das neue Projekt gleich so aufsetzen, dass diese Problemkreise gar nicht mehr auftreten. Dafür gibts dann zwar neue, aber so ist das Leben. > Der beste Start eines Projekts ist, den PC auszuschalten und Papier > und Bleistift zu nehmen. Das kann man gar nicht oft genug dick unterstreichen.
Der Kunde, oder derwelche, der etwas will, will zuerst mal das Falsche. Da muss er aber selbst herausfinden. Mit etwas glueck kann man die Aenderungen schon vorausahnen, mit etwas glueck den Kunden dahingehend beieinflussen. Denn der Termindruck kommt sowieso, aber von extern. Irgemdwann will/muss der Kunde an genau diese Messe, und muss da schon etwas haben. Das absolute Minimum ist die Gewissheit, dass das Problem geloest ist. Dann laesst sich noch was mit Attrappen erreichen. Und ja, hin und wieder sollte man einen Redesign durchfuehren. Lieber neu anfangen, als weiter mit Effizienz Null rumprfriemeln.
Als reiner Hobbyprogrammierer sehe ich das ziemlich entspannt. Wenn bei Mikrocontrollerprojekten nicht der Weg das Ziel ist, kaufe ich ein fertiges Gerät... >Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen Ein Redesign bei "gewachsenen" Projekte ist nie verkehrt, aber erwarte nicht, daß da plötzlich gigantische Reserven frei werden. Dazu kommt: Du hattest am Anfang des Projektes keine Vorstellung über den Umfang, und hast es heute immer noch nicht. So ist das halt unter uns Hobbiisten (und bei manchem "Profi" auch...). >oder ich Erweitere das Gerät um einen weiteren Controller der dann >Teilaufgaben übernimmt. Vergiß es. Wenn sich die Aufteilung nicht völlig logisch ergibt (d.h. man kann zwei vollwertige Geräte draus machen), wird das viel zu komplex und nicht handelbar. >Eine weitere Option wäre einen größeren Controller zu nehmen ... Yepp. Wie heisst es so schön: Wende niemals Gewalt an, nimm gleich den großen Hammer :-) Ob der Prozessor nun 1,50 oder 3,50 bei Angelika kostet, ist doch völlig egal. Oliver
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.