Guten Tag,
Heute ist Samstag, also es ist kein Trollthread.
Ich suche Literatur, wie man von Beginn an Embedded Systems (8/16/32 Bit
µC) Projekte zuvor plant.
Anforderungsanalyse, Planung und Umsetzung.
Mir ist zumindest aufgefallen, dass ich bei der Umsetzung kein
Grundgerüst an Werkzeugen habe, wie ich in Embedded Projekte souverän
angehe, außer UML.
(oder beobachte bei Kollegen die quasi mit dem Kopf durch die Wand ohne
Planung starten).
Ich möchte, bevor ich überhaupt eine IDE starte und die ersten Zeilen
Codes eintippe, die Firmwarearchitektur bzw. Planung vorher möglichst
vollständig abgeschlossen ist.
Sind diese Bücher dazu geeignet?
978-0201633610
978-1449302146
Ich tendiere eher zum zweitem Buch.
Wenn ihr deutsche Literatur kennt, gerne her damit :D
Hi
bist Du Student? Sollst Du wissen, wie man sowas "theoretisch" angeht?
Oder arbeitest Du schon in einer Fa, die einschlägige Projekte
bearbeitet, und bist ein Newbi?
In den Firmen, in denen ich gearbeeite habe, hat man halt angefangen,
alte Muster, alte projektvorlagen, damits schneller geht, meist wusste
keiner irgendwelche Details, hat sich erst so im Laufe des Projektes so
ergeben...
Entwickler schreibt Lastenheft auf der basis von Meetings, wenn alles
gelaufen ist und Projekt fertig wird Pflichtenheft erstellt.... :-)
Gruß
Franko P. schrieb:> Hi> bist Du Student? Sollst Du wissen, wie man sowas "theoretisch" angeht?> Oder arbeitest Du schon in einer Fa, die einschlägige Projekte> bearbeitet, und bist ein Newbi?
Das zweite.
Franko P. schrieb:> In den Firmen, in denen ich gearbeeite habe, hat man halt angefangen,> alte Muster, alte projektvorlagen, damits schneller geht, meist wusste> keiner irgendwelche Details, hat sich erst so im Laufe des Projektes so> ergeben...
Das mag zwar sein, dennoch würde ich gerne etwas Werkzeug aneignen
wollen, wie man es "richtig" machen würde oder sollte.
Mir fehlt dies, damit ich darauf im Notfall zurückgreifen kann und ich
gut vorbereitet bin.
Teddy schrieb:> Sind diese Bücher dazu geeignet?> 978-0201633610>> 978-1449302146
Entschuldigung, diese Nummer habe ich grade nicht im Kopf, wie lauten
die Titel?
Teddy schrieb:> Das mag zwar sein, dennoch würde ich gerne etwas Werkzeug aneignen> wollen, wie man es "richtig" machen würde oder sollte.> Mir fehlt dies, damit ich darauf im Notfall zurückgreifen kann und ich> gut vorbereitet bin.
Dafür brauchst Du evtl Literatur, die sich eher allgemien mit
Projektmanagement beschäftigt. Deine von dir angegebene 2.Literatur ist
möglicherweise sehr speziell. Allerdings haben Firmen meist noch ihre
eigene Strategie, wie sie Projekte bewältigen. Projektmanagement ist
auch nicht statisch, man könnte sagen, sie ist der Mode unterworfen. Da
gibts immer wieder neue Ansätze. Wenn Du in einer anständigen Firma
arbeitest, sollte dich deine Firma auf eine passende Schulung schicken.
Meist scheitern externe Ansätze von Hochschulen und/oder Literatur, da
sie nicht entsprechend angewendt wird.
Gruß
Hi Teddy,
wenn Du des Englischen mächtig sein soltest, schau einfach auf der
Web-Site v. Jack Ganssle.
http://www.ganssle.com/bkreviews.htm
Hat mir schon ein paar mal geholfen. :-)
Franko P. schrieb:> Teddy schrieb:>> Das mag zwar sein, dennoch würde ich gerne etwas Werkzeug aneignen>> wollen, wie man es "richtig" machen würde oder sollte.>> Mir fehlt dies, damit ich darauf im Notfall zurückgreifen kann und ich>> gut vorbereitet bin.>> Dafür brauchst Du evtl Literatur, die sich eher allgemien mit> Projektmanagement beschäftigt. Deine von dir angegebene 2.Literatur ist> möglicherweise sehr speziell. Allerdings haben Firmen meist noch ihre> eigene Strategie, wie sie Projekte bewältigen. Projektmanagement ist> auch nicht statisch, man könnte sagen, sie ist der Mode unterworfen. Da> gibts immer wieder neue Ansätze. Wenn Du in einer anständigen Firma> arbeitest, sollte dich deine Firma auf eine passende Schulung schicken.> Meist scheitern externe Ansätze von Hochschulen und/oder Literatur, da> sie nicht entsprechend angewendt wird.> Gruß
In der Kindle Variante hat man die Möglichkeit einige Seiten zu lesen.
Mir hat zumindest Kapitel 2 sehr angetan, da aufgezeigt wird, wie man
grundsätzlich an ein Projekt rangehen kann, wenn ein Schaltplan gegeben
ist.
Das ist eigentlich die Richtung, wonach ich suche.
Teddy schrieb:> Ich suche Literatur, wie man von Beginn an Embedded Systems (8/16/32 Bit> µC) Projekte zuvor plant.
Zumindest für die Hardware-hälfte (Software interessiert mich eher
weniger)
gibt es das:
ISBN: 978-1-85617-624-8
ISBN: 978-1-85617-605-7
ISBN: 978-3-486-71840-9
software-lastiger ist:
ISBN: 978-0-387-29237-3
ISBN: 978-3-86490-562-9
wie an letzterem bereits angedeudet gibt es eigentlich kein Gesamtwerk
für alle Aspekte des Designs, sondern für die eizelnenen Elemente. Man
sollte sich also noch ein gutes Test-Buch zulegen, weil erst der Test
zeigt wie brauchbar die Architektur in der Praxis ist.
ISBN: 978-3-89864-638-3
Teddy schrieb:> Ich möchte, bevor ich überhaupt eine IDE starte und die ersten Zeilen> Codes eintippe, die Firmwarearchitektur bzw. Planung vorher möglichst> vollständig abgeschlossen ist.
Das ist Quatsch.
Das wäre so, als hätte ein Konstrukteur sein Design schon fertig, bevor
er ans CAD geht. Oder der Autor sein Buch, bevor er sich Notizen macht
Wenn der Schaltplan nicht von dir kommt, dann solltest Du die IDE schon
lange auf haben, um die ganzen vorgesehenen Features Mal zu probieren.
Papier und Bleistift vor dem Programmieren war zur Lochkartenzeit.
Und Systementwurf etc. beinhaltet HW. Die sollte nicht gänzlich
unbekannt sein.
Teddy schrieb:> In der Kindle Variante hat man die Möglichkeit einige Seiten zu lesen.> Mir hat zumindest Kapitel 2 sehr angetan, da aufgezeigt wird, wie man> grundsätzlich an ein Projekt rangehen kann, wenn ein Schaltplan gegeben> ist.> Das ist eigentlich die Richtung, wonach ich suche.
Tja, und warum hat's dann der Arbeitgeber noch nicht gekauft? Am besten
als Buch, damit auch andere Mitarbeiten was von haben. Das Du Dir Wissen
zu dem aneignest was Du tust, ist doch im Interesse des Arbeitgebers und
dazu ist ein Buch für 25€ eine lächerlich geringe Ausgabe für im
weitesten Sinne Weiterbildung. Zumindest um Dimensionen billiger als
eine Fortbildung zum Thema außer Haus. Ich habe bisher noch mit keiner
Firma zu tun gehabt, wo das Kaufen von Büchern, gerne auch mehrere zum
Thema, ein Problem gewesen wäre.
Mfg
> Entwickler schreibt Lastenheft auf der basis von Meetings, wenn alles> gelaufen ist und Projekt fertig wird Pflichtenheft erstellt.... :-)
Lasst euch nicht verarschen! Heute steht das alles in Datenbanken die
automatisch den Text fuer den Entwickler zum abnicken generieren und am
ende immer ein Fenster aufmachen: Sie haben 3min fuer 385 Eintraege
gebraucht!
Bei einem neuen Projekt kopiert dann der Systemanalytiker einfach 90%
vom letzten Projekt und jeder wundert sich warum da so komische
Anforderungen drin stehen die gar nicht zum Projekt passen. Jedenfalls
wenn er ueber die 385Punkte innerhalb 3min intensiv nachgedacht hat.
Olaf .-)
@Olaf: Bei uns lief das so, wie ich geschrieben habe. Aber da hat eben
jede Firma so ihre Eigenheiten. Bei uns gabs auch eine
Entwicklungsrichtlinie, nur dass nach der meist nicht gearbeitet werdn
konnte, weil notwendige Daten fehlten. Also haben Vertrieb und Marketing
ein Pamphlet estellt, was sie gerne hätten und in Meeting wurde das dann
zerlegt.... Bei uns wurden aber auch Maschinen entwickelt und keine
"Embedded Systems", die wurden dann allenfalls eingebaut.
Gruß
Gut fand ich dagegen „Modellbasierte Softwareentwicklung für
eingebettete Systeme verstehen und anwenden“ auch wenn ich wegen
Widerständen davon wenig in der Praxis umsetzen konnte.
Blechbieger schrieb:> Gut fand ich dagegen „Modellbasierte Softwareentwicklung für> eingebettete Systeme verstehen und anwenden“
Du meinst:
ISBN: 978-3864905247 ??? Das ist wie auch einige meiner Empfehlungen
aus dem dpunkt-Verlag, da sollte man sich mal das Verlagsprogramm zu
Computing anschauen:
https://www.assets.dpunkt.de/kataloge/ComputingFlyer.pdf> auch wenn ich wegen> Widerständen davon wenig in der Praxis umsetzen konnte.
Weniger "nach Erlaubnis fragen", mehr "einfach machen und die Ergebnisse
für sich sprechen lassen". Nach dieser Prämisse entwickeln viele
Freiberufler.
> @Olaf: Bei uns lief das so, wie ich geschrieben habe.
Ich meinte mein "lasst euch nicht verarschen" auch eher ironisch und
keinesfalls boese, um das mal klar zu stellen.
Ich finde es jedenfalls faszinierend das es in den grossen Firmen
UNGLAUBLICH grosse Mengen an Vorschriften gibt. Betrachtet man die
einzeln sind die alle irgendwie sinnvoll. In Summe sind sie totaler
Bullshit der dafuer sorgt das extrem ineffizent bis garnicht gearbeitet
werden kann. Also muss man sowas entweder kreativ ignorieren....
> Weniger "nach Erlaubnis fragen", mehr "einfach machen und die Ergebnisse> für sich sprechen lassen". Nach dieser Prämisse entwickeln viele> Freiberufler.
...oder Sachen an Externe rausgeben.
Olaf
Teddy schrieb:> wie man grundsätzlich an ein Projekt rangehen kann,> wenn ein Schaltplan gegeben ist.
Was ist denn eigentlich Deine Aufgabe?
Wenn der Schaltplan gegeben ist, dann sind die meisten Dinge ja
gelaufen. Denn irgendwer hat den ja gezeichnet und dafür Anforderungen
an das endgültige Produkt gehabt.
Wenn Du also "nur" SW machst (und keine Geräte/Systeme/embedded Devices
entwickelst), dann solltest Du Deine Aufgabe in etwa umreißen.
Es ist ein Unterschied, ob Du kleinen Geräten wie Temperaturloggern
Leben einhauchst oder Prozessautomation betreibst. Und selbst für reine
Programmierung kleiner Projekte (mit << 100.000 Zeilen Code) gibt es
verschiedenste Themen, wovon die meisten nur mit wenigen Kontakt haben.
Ganz generell kann ich zur Programmierung 2 Klassiker empfehlen,
"Writing Solid Code" und
"Code Complete"
Sobald es aber um C++ geht, tun sich da je nach Spezialisierung wieder
verschiedenste Welten auf.
Die ganzen Bücher wie man 3 Bytes spart oder Megabyte große Listen
durchsucht (z.B. Algorithm in C), sind nur für die Interessant, die
solche Problem auch haben. Ähnlich komplexe OOP-Pattern oder Funktionale
Strategien.
Viele Bücher zu Architekturen verstehst Du erst richtig, wenn Du mit
mehreren Arbeitest und erste Erfahrung hast.
Das wichtigste ist daher eher, vorhandenen Code zu lesen, erste
Erfahrungen damit zu sammeln, also die Schwierigkeiten mit diesen
Paradigmen kennen zu lernen. Und dann sich nach guten SW-Pattern
umsehen, die diese Schwierigkeiten umgehen. Denn dann kommt der
schwierigste Part: Entweder seine Kollegen sanft mitzunehmen oder
erstmal alleine zu sein.
C. A. Rotwang schrieb:> Weniger "nach Erlaubnis fragen", mehr "einfach machen und die Ergebnisse> für sich sprechen lassen". Nach dieser Prämisse entwickeln viele> Freiberufler.
Ich habe schon einiges erfolgreich „einfach gemacht“, z.B. CI
eingeführt, aber da ich weder Freiberufler noch Einzelkämpfer bin gibt
es Grenzen wie weit ich gehen kann. Da gute Tools für modellbasierte
Entwicklung Geld kosten und ich die Budgetverantwortlichen noch nicht
überzeugen konnte ist da die Grenze erreicht.
