Hallo, mich würde mal interessieren, wie man vorgeht, wenn man ein großes Programm erstellen möchte, das bestimmt an der ein oder anderen Stelle auch komplexe Vorgänge in sich hat. Als Beispiel würde ich hier mal sowas in der Größenordnung von MS-Word oder Open Office Writer zugrunde legen. Mal abgesehen davon, ob die Menpower von einem alleine ausreicht, um das alles umzusetzen, würde mich interessieren, wie die einzelnen Schritte aussehen, um am Ende einen Plan zu haben, den man "häppchenweise" abarbeiten kann... Gerade auch die Umsetzung selbst interessiert mich sehr (auch die Reihenfolge, wenn was zu tun ist): z.B. in der Anwendung verwendete Objekte herausfinden, Interfaces definieren, Klassen implementieren etc... Vielen Dank für jeden Hinweis! Gruß Peter
Zerscheibeln und dann Top-Town. Ein Office Packet ist dann nicht etwas das Ende der Komplexitaet. Die Steuerung einer Gepaeck- oder Packetsortieranlage ist dann was anderes.
Fuenf Tassen schrieb: > Zerscheibeln und dann Top-Town. > Ein Office Packet ist dann nicht etwas das Ende der Komplexitaet. Die > Steuerung einer Gepaeck- oder Packetsortieranlage ist dann was anderes. bei richtig großen sachen oder steuerungen arbeitet man eh auf basis von modelgetriebenen entwürfen..da zeichnet man eigtl. nur noch statt zu coden ala. simulink
> wie die einzelnen Schritte aussehen, um am Ende einen Plan zu haben, > den man "häppchenweise" abarbeiten kann... Papier. Unmengen von Papier Arbeitsabläufe festlegen, was kann der Benutzer wie machen, wie geht er vor. GUI skizzieren, wie könnte das aussehen. Wie hängen die einzelnen Datenstrukturen zusammen, welche Daten brauchen wir überhaupt. Und noch mehr Papier. Andere drüber schauen lassen. Sind die Bedienungsabläufe konsistent. Gibt es sowas wie eine 'GUI-Sprache' im Programm. Sind (für den Benutzer) gleiche Abläufe auch im Programm mit der gleichen Logik erledigbar. erste Vorstudien. Taugt die Datenstruktur etwas? noch mehr Papier. typische Aufgabenstellungen annehmen. Wie bilden sich die in der Datenstruktur ab? Ist das sinnvoll? Auf dem Papier mal die Aufgabenstellungen durchspielen. Notizen machen über Dinge, die nicht offensichtlich sind, wie zb Nebenbedingungen. Ist klar, welche Algorithmen zum Einsatz kommen werden. Gibt es die überhaupt, oder müssen die erst erfunden werden? Kriegen wir die unbekannten Algos unter kontrolle, oder hab ich da eher Bauchweh. Wenn Bauchweh - gibt es einen Plan B? Können kompliziertere Algorithmen, mit denen noch keine Erfahrung vorliegen, vorab mal getestet werden? Wo sind seine Stärken, wo die Schwächen? Wo sind die Grenzen? Wie ist das Laufzeitverhalten? noch mehr Papier Was ist mit Subsystemen? Können welche abgesplittet werden? (zb Fileveraltung, zb Druckmanager, zb Drucklayouts, Geometrie-Maschinerie, ...) Was müssen die können? Welches sind die Anforderungen? Lässt sich das alles noch feiner aufsplitten? und wieder ist Papier gefragt. Skizzen machen. Zusammenhänge visualisieren. 'Entwickeln' einer 'Sprache' für im Programm zu verwendende Begriffe. Sicher stellen, dass alle Entwickler über diese Nomenklatur bescheid wissen. Am besten werden sie in diesem Prozess eingebunden, dann identifizieren sie sich auch damit, und alle benutzen dann im Programm die gleichen Ausdrücke. noch mehr Papier darüber schlafen, dann den Haufen Papier noch mal gemeinsam durchsehen. An welchen Ecken hat man noch Bauchweh, was ist noch nicht zumindest soweit klar, dass man eine ungefähre Vorstellung davon hat, wie das dann aussehen wird. Alles im Kopf noch mal durchgehen. Die typischen Benutzerabläufe sollten keine Probleme mehr machen. Was ist mit eher esoterischen Benutzer-Problemstellungen? Sind die machbar? Wie macht er die? Wenns nicht geht, wie müsste man das System ändern? Lohnt sich das? Eventuell noch mal ein paar Schritte zurück und nachsehen, wo man eingreifen könnte/möchte. Wenn dann niemandem mehr was zu dem Thema einfällt, dann gehts mit dem handwerklichen Teil los. Der wichtigste Grundsatz: In Schritten arbeiten. Kein Mensch kann komplexe Systeme in ihrer Gesamtheit überblicken. Daher ist es wichtig, dass man getestete Subsysteme hat. Früh mit Tests anfangen. Was testbar ist, wird auch getestet. Und wenn man sich extra dafür einen Fake ins Programm baut, der dann später wieder rausfliegt. Und egal wie gut du dich auf ein Projekt vorbereitet hast, 2 Monate später tauchen die ersten Überraschungen auf. Da muss man durch. Am Anfang hat man schnell erste Erfolge. Dann fängt es irgendwann an zäh zu laufen und man merkt, wo die Dinge nicht gut zusammenpassen. Nicht zu lange zögern, wenn du's jetzt nicht in vernünftige Bahnen lenken kannst .... einfacher wirds nicht mehr, wenn dann die ersten Anwender mit der Software arbeiten. Zum jetzigen Zeitpunkt hast du noch den Luxus, keine Kompromisse eingehen zu müssen. Ein 3/4 Jahr später siehts dann schon anders aus.
Hallo Karl Heinz Buchegger, danke für die ausführliche Antwort. Das klingt alles sehr gut. > "Wenn dann niemandem mehr was zu dem Thema einfällt, dann gehts mit dem > handwerklichen Teil los." Gerade der Handwerkliche Teil würde mich auch noch sehr interessieren. Du scheinst ja schon Erfahrungen mit größeren Projekten gemacht zu haben. Würde mich sehr freuen, wenn Du darüber auch noch ein paar Zeilen schreiben könntest. Ich hab zwar auch schon an - für mich - größeren Projekten mitgearbeitet. Habe aber nach den Projekten ständig das Gefühl, dass man was besser machen kann. Hier von anderen zu lernen interessiert mich sehr. Viele Grüße, Peter
Peter schrieb: > Projekten mitgearbeitet. Habe aber nach den Projekten ständig das > Gefühl, dass man was besser machen kann. Das kann man immer! Das ist wie beim Hausbau. Im Grund müsste man das erste Haus abreissen und mit der gemachten Erfahrung ein zweites mal anfangen. Das man sein Handwerkszeug, die Programmiersprache, beherrschen muss, sollte klar sein. Mit wackligen Sprachkentnissen in ein großes Projekt zu gehen, ist ein Himmelfahrtskommando. Viel lesen. Anderer Leute Code studieren. Dabei auch ruhig kritisch sein. Was gefällt mir an dem Code, wie ist er aufgebaut, was finde ich weniger gut, wo sind potentielle Fallen, etc. Gerade aus der Analyse von fremdem Code kann man unendlich viel lernen. Auch ruhig mal Konkurrenzprodukte unter die Lupe nehmen: wie konsistent ist das Benutzerinterface, wie ist es durchgezogen, wo ist die Bedienung holprig. Wenns OOP ist, dann hat man ja mit dem ganzen Papierkram schon mehr oder weniger einen ersten Satz Klassen geschaffen. Die fallen da mehr oder weniger raus. Meist wird man noch ein wenig feiner granulieren, aber im Grossen und Ganzen sollte das schon brauchbar sein. Vieles aus dem Papierkram, kann unmittelbar zu ersten Kommentaren in den Klassen werden. Welche Aufgabe hat die Klasse, zu welchem Subsystem gehört sie, wie arbeitet sie, etc. OOP ernst nehmen! Datenkapselung ernst nehmen! Gerade letzters ist dein Fuss in der Tür, wenn man Einzelteile im Nachhinein austauschen muss ohne das Gesamtsystem zu gefährden. Bei jeder Funktion immer fragen: welche Klasse ist dafür zuständig. Da ist ein wenig "Beamtendenken" gefragt - weiterleiten an den zuständigen Sachbearbei .. äh ... Klasse. Übersichtllichen Code preferieren. Wenn das Konzept stimmt, wird das Programm von alleine eine akzeptable geschwindigkeit haben. Gerade die 'cleveren Hacks' sind etwas, was man in einem großen Projekt überhaupt nicht brauchen kann. Daran denken: die Software muss die nächsten 10 Jahre gewartet werden können. Es ist wichtig, dass man auch in 10 Jahren eine Codestelle noch schnell erfassen kann. Gedankengänge gehören als Kommentarblöcke in den Code! Doku geht im Lauf der Zeit verloren oder wird nicht aktualisiert. Bei Kommentaren hat man zwar das gleiche Problem, durch die Nähe zum Code ist es aber wahrscheinlicher, dass sie bei Änderungen nachgezogen werden. Eine vernünftige und durchgängige Nomenklatur ist wichtig! Je mehr Programmierer beteiligt sind, umso wichtiger ist sie. UML Tools: kann ich wenig dazu sagen. Hab ich selber noch nie im Einsatz gehabt. Meine Erfahrung mit Leuten, die das benutzt haben ist aber eher: sie verbringen wahsinnig viel Zeit damit, dass die Diagramme schön aussehen. Was ich mit Papier und Bleistift schnell skizzieren kann dauert mit den Tools 5 mal so lange. Das aller, aller, allerwichtigste ist aber nach wie vor: Man muss seine Hausaufgaben im Vorfeld gemacht haben! Wenn die erste Zeile echter Code geschrieben wird, muss das Gesamtkonzept stehen, muss soweit konsistent sein und muss durchdacht worden sein, ob es auch die Anforderungen erfüllt. Ohne diese Vorarbeit geht ein großes Projekt in die Hose. In der Softwareentwicklung haben wir ein Problem: Im Grunde ist jedes Programm eine neue Erfindung, die so vorher noch nicht realisiert wurde. Baue ich Häuser, dann gibt es Erfahrungen aus den letzten 50 Hausprojekten. Baue ich Brücken, dann gibt es Erfahrungen von früher, worauf man bei einer Hängebrücke achten muss. Aber Programme sind immer Neuland. Dieses Programm, an dem du arbeitest, hat vor dir noch nie jemand gemacht. Ob die Einzelteile dann auch wirklich so zusammenpassen, wie du dir das am Papier ausgedacht hast, siehst du erst, wenn die Einzelteile implementiert sind.
>noch mehr Papier
damit ist "virtuelles Papier" gemeint, oder ;-)
kennt jemand zufällig eine gute (günstige) Software die einem bei der
Projektplanung hilft (mehr in Richtung Multiuserfähiges
Pflichten-/Lastenheft aber nicht GANTT mäßig oder GAR UML..)
???
Robert L. schrieb: >>noch mehr Papier > > damit ist "virtuelles Papier" gemeint, oder ;-) Wie du willst. Bei mir/uns meistens reales. Es geht einfach am schnellsten damit zu arbeiten :-) Papier und Bleistift ist beim Skizzieren jeder Software haushoch überlegen.
>Bei mir/uns meistens reales. ja, aber um das geht es hier ja nicht (ihr macht ja keine Projekte in dem Umfang ala "word/open office" ;-) >Papier und Bleistift ist beim Skizzieren jeder Software haushoch >überlegen. so pauschal sowieso ein schmarn.. das geht vielleicht für kurze besprechungen, einzelner Punkte, oder grober übersichten usw. alles was etwas umfangreicher wir, und mehrere daran arbeiten (die auch mal auf Urlaub sind usw.) echtes Papier ist immer schlecht.. einfachstes Beispiel ist ja schon das sortieren/suchen/gruppieren nach unterschiedlichen Kriterien
Robert L. schrieb: > echtes Papier ist immer schlecht.. Na ja, kann man genausowenig pauschal stehen lassen. Alles Elektronisch führt dann dazu, daß ein Teil in Excel, einer in Word und die Teile vom Vertrieb dann als Powerpoint Präsentationen (incl. Witzchen) einfach in den Topf geschmissen werden. Heraus kommen dann ein halbes Gygabyte heterogene Informationen mit jeweils 20 Versionen und vielen bunten Kommentarblasen, die sich auch noch widersprechen. Ein Papier wird meiner Erfahrung nach gründlicher gelesen, besser verstanden und gibt es in weniger unterschiedlichen Versionen. Was hier vergessen wurde ist ein effizientes Projektmanagement. Frühe Planung was wann gemacht wird, Milestones, wenn die nicht eingehalten werden rechtzeitiges umplanen. Und reden reden reden. Die größten Probleme habe ich erlebt wenn die Leute nicht genug miteinander geredet haben, reden nicht schwätzen! Jeden Tag ein KURZes!!! Meeting in den Gruppen und dann die Gruppenleiter: Wo stehe ich, wer hat Probleme, wo gibt es zusätzlichen Klärungsbedarf. Die Schwätzer die jedes Problem gleich ausbreiten und die Lösung diskutieren wollen abwürgen, das ist dann in zu vereinbarenden Einzelgesprächen der tatsächlich Beteiligten zu tun. Dazu gehört auch daß möglichst alle ehrlich sagen wenn es Probleme gibt und die Zeit nicht reicht. Das ist das nächste große Problem, jeder (Gruppe) versucht erst mal alles kleinzureden, nicht als Versager dazustehen, besser zu sein wie die andere Abteilung. Da gilt wieder kleine Gruppe die sich kennt und mag ist viel besser wie Abteilungen mit Machtkämpfen. .... unendlich to be continued.
Nachtrag. Und nicht nur sein eigenes Problem sehen, sondern über den tellerrand schauen. Was machen die Kollegen an meinen Schnittstellen, wie sieht deren Arbeit aus, versuchen die nächste drüberliegende Komplexitätsebene zu verstehen, damit ich weiß daß mein Teil da auch reinpasst.
Ich kann aus eigener Erfahrung als Mit-Entwickler einer "großen Software" nur sagen, das Dokumentation ein riesen Problem ist. Es wird immer vernachläßigt wenn da keiner einen Daumen drauf hällt. Hinzu kommt auch, das es mitunter problematisch ist, wenn sich trotz sorgfältiger Vorplanung beim Initialdesign Anforderungen grundlegend ändern im Laufe der Jahre (in meinem Fall ca. 15 Jahre Softwarealter). Problematisc in dem Zusammenhang kann auch sein, das ein Kunde selten bereit ist, für "Softwarewartung" (also z.B. internes Redesign) Geld in die Hand zu nehmen, wenn sich für Ihn direkt nichts ändert. Aus sicht des Kunden auf den ersten Blick nachvollziehbar, auf den zweiten nicht mehr, aber nunja - so ist die Welt ;) Produktivitätsverringernd ist auch immer "Abteilungsdenken" welches zu einer Art Konkurenzdenken ausarten kann. Dem muss sehr früh sehr energisch entgegen gewirkt werden. Ansonsten wurde schon recht viel sinnvolles dazu geschrieben.... Ob nun Papier oder elektronisch... wir verwenden z.B. ein WiKi für technische und fachliche Beschreibungen da sich das als am unkompliziertesten dargestellt hat. Aber - die Wahl des Tools ist zweitrangig. Wenn etwas nicht funktioniert im Prozess (z.B. dokumentieren), ändert die Wahl des Tools nur selten was.
> z.B. in der Anwendung verwendete Objekte herausfinden, Interfaces > definieren, Klassen implementieren etc... Klingt schon mal wie der vollkommen falsche Ansatz. Du musst erst mal überlegen, wo das PROBLEM deiner Anwendung steckt. Bei Wordprocessing ist die zentrale Funktion das Ändern von Text. Diese Funktion muß rückgängig (undo) gemacht werden können. Also solltest du JEDE Änderung am Text durch EIN Interface pressen. Dabei können mehrere Sachen geändert werden: "Text von Position bis Position wird durch neuen Text und/oder Formatierung xyz ersetzt" ist deine zentrale Funktion. Diese hat Auswirkungen auf die gespeichtern Text (passende Datenstruktur für eine effiziente Einarbeitung der Änderung nötig) und die Anzeige, und es gibt eventuell mehrere Anzeigestellen (panes). Eine Operation auf dem Text muß also ein Update der Anzeige triggern, dabei sollte nur das neu gezeichnet werden, was sich verändert hat, und nicht jedesmal der Text vom Anfang an umgebrochen werden müssen. Also ist ein schneller Zugriff auf den Text notwendig, ein gutes Programm kann dir Seite 625 vom Dokument anzeigen, ohne Seiten 1-600 überhaupt aus der Datei gelesen zu haben. Die Schwierigkeiten eines Programms liegen da eher in Situationen wie "in der Fusszeile wird die Gesamtzahl der Seiten angezeigt, durch eine Änderung werden aus 99 nun 100 Seiten, dadurch wird die Fusszeile länger und muss in 2 Zeilen umgebrochen werden. Damit verringert sich der Platz auf der Seite und das Dokument wird 120 statt 100 Seiten lang". So kann das Einfügen eines Zeichens auf der letzten Seite tatsächlich zu einem rebreak des gesamten Dokuments ab Seite 1 führen, den manche Software qua Design umgeht: Entweder gibt es gar keine edierbare Seitenlayoutdarstellung, oder der Fussbereich hat feste Höhe und überlagert ggf. den Text, oder es gibt keine einfügbare Variable für die Gesamtanzahl der Seiten. Wenn du die Schwierigkeiten des Programm alle richtig verstanden hast und richtig behandelt hast, ist der Rest Kinderkacke. Glaubst du, daß die Schwierigkeiten erst ganz zum Schluss mit einem Arbeitskommitee gelöst werden, weil du sie heute noch gar nicht verstehst, aber du baust schon mal 90% des Programms fertig, um die letzten 10% können sich deine Nachfolger kümmern, ist da Projekt zum Scheitern verurteilt.
Udo Schmitt schrieb: > Na ja, kann man genausowenig pauschal stehen lassen. das war auch (absichtlich) provokativ "pauschal" ;-) > Alles Elektronisch führt dann dazu, daß ein Teil in Excel, einer in Word > und die Teile vom Vertrieb dann als Powerpoint Präsentationen (incl. > Witzchen) einfach in den Topf geschmissen werden. > Heraus kommen dann ein halbes Gygabyte heterogene Informationen genau deshalb hab ich weiter oben gefragt, ob jemand zufällig software dafür kenn, oder besser: selber verwendet, dass das eben nicht passiert..
Robert L. schrieb: >>Bei mir/uns meistens reales. > > ja, aber um das geht es hier ja nicht (ihr macht ja keine Projekte in > dem Umfang ala "word/open office" ;-) Ähm. Word ist im Vergleich zu den Projekten in denen ich (und viele andere hier) involviert sind, Kinderkram. Textverarebeitung fällt und steht mit einer guten Datenstruktur, so dass man auf die Texteinzelteile schnell zugreifen kann ohne sich den Speicher zuzumüllen. Wie das gemacht werden kann, ist seit vielen Jahren bekannt. Das kann man alles nachlesen und daraus lernen. Der Rest ist dann Handwerk. In unseren Projekten geht es oft (meistens) zusätzlich auch noch darum, dass du dich auch erst mal in die Problemdomäne einarbeiten musst. Wenn du ein Programm schreibst, welches die Unterkonstruktion für den Trockenbau berechnet, dann musst du selbst erst mal zum Experten für Trockenbau werden. Kommt 3 Jahre später dann dazu, dass auf die Gipskarton-Platten auch noch Fliesen verlegt werden sollen, dann bleibt dir nichts anderes übrig als erst mal die Regeln des Fliesenlegens zu behirnen. Parkettverlegung, Vorhänge aufhängen, Fenster in Wände einbauen, Wintergärten, Rohrverlegung, ..... Überall musst du erst mal die Regeln und die Besonderheiten deiner Problemdomäne lernen. Und zwar nicht nur die 08/15 Sachen, sonder auch die, bei denen dein Gesprächspartner in seiner Firma erst mal rumtelefonieren muss, weil er selber die Details auch nicht weiß. Und wenn dein Gegenüber sagt "Das kommt bei uns nicht vor", dann weißt du, dass du gerade den ersten Punkt gefunden hast, über den bei der End-Abnahme diskutiert wird. >> Papier und Bleistift ist beim Skizzieren jeder Software haushoch >> überlegen. > das geht vielleicht für kurze besprechungen, einzelner Punkte, oder > grober übersichten usw. Welchen Teil von "ist beim Skizzieren" hast du nicht verstanden. Das man das dann natürlich noch mal in elektronischer Form rein schreiben und archivieren kann/soll/muss, sollte auch klar sein. Was Udo und Oliver da noch hinzugefügt haben, ist alles nachvollziehbar und hat wohl jeder schon erlebt.
Robert L. schrieb: >> Alles Elektronisch führt dann dazu, daß ein Teil in Excel, einer in Word >> und die Teile vom Vertrieb dann als Powerpoint Präsentationen (incl. >> Witzchen) einfach in den Topf geschmissen werden. >> Heraus kommen dann ein halbes Gygabyte heterogene Informationen > > > genau deshalb hab ich weiter oben gefragt, ob jemand zufällig software > dafür kenn, oder besser: selber verwendet, dass das eben nicht > passiert.. Diese Heterogenität sehe ich eigentlich gar nicht mal so sehr als das Hauptproblem an. Das kann man bekämpfen, muss man aber nicht. Letzten Endes ist es ein Kampf gegen Windmühlen. Das eigentliche Problem bei derartiger Doku hat Oliver angesprochen. Nach ein paar Monaten/Jahren hat die damals produzierte Doku meist nur noch wenig mit dem realen Programm zu tun. Warum? Weil es meistens keine Einzelperson gibt, die dafür zuständig ist, die Doku nachzuziehen. Ist einfach ein Kostenfaktor, den sich die Zuständigen gerne einsparen.
Hinzu kommt bei Doku auch noch, das es ein Problem ist, wenn mehrere Leute mit äußerst unterschiedlichen didaktischen Fertigkeiten eine Doku schreiben. Zumal von der Natur der Sache deren Hauptaugenmerk das entwickeln ist, und die Doku so "beilaeufig" "abfaellt". Generell wird Doku auch gerne als B oder C-Prio betrachtet was man sobald es zeitkritisch wird gerne auch mal wegfallen lässt.... immer eine Krux das Thema. Einen didaktisch guten aber auch technisch versierten "Dokumentierer" zu finden ist sehr schwer und dann wird er wie du ja auch schon schreibst nur seltenst bezahlt. Auch muss er je nach Tiefe der Doku auch enormes Wissen über die Software haben....
Oliver Lehmann schrieb: > Hinzu kommt bei Doku auch noch, das es ein Problem ist, wenn mehrere > Leute mit äußerst unterschiedlichen didaktischen Fertigkeiten eine Doku > schreiben. Zumal von der Natur der Sache deren Hauptaugenmerk das > entwickeln ist, und die Doku so "beilaeufig" "abfaellt". :-) Warum bloss kommt mir das alles so bekannt vor.
Wobei man aber auch sagen muss, dass bei den wirklich großen, zum Teil dann auch sicherheitsrelevanten Anwendungen (Kernkraftwerk, Flugzeuge, Raumfahrt, Banken, Versicherungen, etc.), dann schon andere Massstäbe und Techniken angelegt werden. Allerdings steckt da auch mehr Geld dahinter. Aber natürlich gilt auch da: Vorbereitung ist das halbe Leben. Wer da mit der Maxime reingeht "Am Vormittag lass ich mir das erklären und am Nachmittag fang ich zu coden an", der hat schon verloren.
Oliver Lehmann schrieb: > Einen didaktisch guten aber auch technisch versierten > "Dokumentierer" zu finden ist sehr schwer und dann wird er wie du ja > auch schon schreibst nur seltenst bezahlt. Auch muss er je nach Tiefe > der Doku auch enormes Wissen über die Software haben.... :-) Genau, kommt mir sehr bekannt vor. Also wird meistens zumindest die Rohversion der Doku vom Entwickler gemacht. (Und das ist ja oft deren Lieblingsbeschäftigung :-)) Das Schlimme bei uns ist dann daß das zentral "überarbeitet" und in mehrere Sprachen übersetzt wird. Da wird dann aus einer "und Verknüpfung zweier Parameter" ganz schnell ein "beide Parameter ..." Prima! Ich bin inzwischen so weit, daß ich die von mir abgegebene Doku komplett archiviere und bei Problemen/Verständnis zur Doku erst mal meine ursprüngliche mit der offiziellen Version vergleiche. Na ja wenns einfach wäre wäre die Hälfte von uns arbeitslos :-)
Fuenf Tassen schrieb: > Zerscheibeln und dann Top-Town. diese simplifierte Vorgehensweise ist nicht mehr ädequat. Man muss vielmehr "buttom up" like Themen wie vur Verfügung stehende Bibliotheken, Methoden und Datenstrukturen berücksichtigen. Bei embedded Systemem kommt noch die HW hinzu! (Treiber, SOPC und Schnittstellen). Die funktionellen Anforderungen gehen nach unten, die Strukturellen nach oben und man muss sie auf jeder Ebene in Einklang bringen. nur TOP down geht dann, wenn es reine SW ist wo man unten alle Freiheitsgrade hat.
Hallo, vielen Dank an alle. Mir kommen auch einige Dinge bekannt vor. Ich kann nur sagen, dass mir eure Zeilen wirklich die Augen geöffnet haben. Ich hoffe sie fallen nicht bald wieder zu. Also danke nochmal für die Konstruktivität :-) Gruß, Peter
Ich arbeite im Bereich Hardwaredesign und implementiere diese mit VHDL. Alles hier gesagte kann man auch auf Hardwaredesign anwenden. Auch die Anforderungen und Probleme sind die gleichen. Endlich mal ein interesanter und informativer Thread. Davon sollte es hier viel mehr geben.
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.