8-BIT Controllerentwicklungen -> Wie machen das Profis ?

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 :)

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.