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ß
:
Bearbeitet durch User
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?
Du kannst die Nummern einfach bei Google eingeben, dann wird das richtig rauskommen. Das 1. ist https://www.amazon.de/Patterns-Elements-Reusable-Object-Oriented-Software/dp/0201633612 Das 2. ist https://www.amazon.de/Making-Embedded-Systems-Patterns-Software/dp/1449302149
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ß
Dein zweites Buch „Making Embedded Systems“ habe ich auch gekauft, war Geldverschwendung, fast nur Trivialitäten.
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.
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.