Nach meiner (möglicherweise veralteten Ansicht) benötigt man für eine Programmentwicklung eine Zerlegung der Aufgabenstellung nach dem Top-Down-Prinzip, d.h. (nach meiner Auffassung), dass man eine komplexe Aufgabenstellung in immmer simpler zu lösende EInzelprobleme auflöst ... bis "nix mehr geht". Eine gewisse (entfernte) Ähnlichkeit bezüglich der Motivation zur Herbeiführung der ersten drei Normalformen für relationale Datenbanken sei möglicherweise gegeben. Oder gibts da inzwschen etwas vollkommen Neues und ich bin völlig aus der Zeit gefallen? Macht man Problemanalysen heute noch so? (*** Fortsetzung folgt)
:
Bearbeitet durch User
Kp, da wo ich arbeite fummelt einfach jeder etwas dazu. Irgendwann kommt was raus aber was ich weiß es selber oft nicht. Das Gehalt kommt aber pünktlich
Frank E. schrieb: > Nach meiner (möglicherweise veralteten Ansicht) benötigt man für eine > Programmentwicklung eine Zerlegung der Aufgabenstellung nach dem > Top-Down-Prinzip, d.h. (nach meiner Auffassung), dass man eine komplexe > Aufgabenstellung in immmer simpler zu lösende EInzelprobleme auflöst ... > bis "nix mehr geht". Kann man natürlich so machen, nur kommt es nicht unbedingt selten vor, dass es komplexe Abhängigkeiten zwischen den einzelnen "Einzelproblemen" gibt, so dass diese nicht jeweils für sich alleine betrachtet werden können. > Oder gibts da inzwschen etwas vollkommen Neues und ich bin völlig aus > der Zeit gefallen? Macht man Problemanalysen heute noch so? Agile, was man irgendwie als Bottom-Up ansehen kann.
Frank E. schrieb: > Macht man Problemanalysen heute noch so? Der Name "top-down approach" heisst schon seit Ewigkeiten so, weil es auch mindestens genausolange einen anderen systematischen Ansatz in gegenteiliger Richtung gibt.
Walter T. schrieb: > Frank E. schrieb: >> Macht man Problemanalysen heute noch so? > > Der Name "top-down approach" heisst schon seit Ewigkeiten so, weil es > auch mindestens genausolange einen anderen systematischen Ansatz in > gegenteiliger Richtung gibt. Der aber in der Regel in der Programmierung(!) bislang, wenn überhaupt nur für schnelle Frickellösungen genutzt wurde.
Frank E. schrieb: > Nach meiner (möglicherweise veralteten Ansicht) benötigt > man für eine Programmentwicklung eine Zerlegung der > Aufgabenstellung nach dem Top-Down-Prinzip, d.h. (nach > meiner Auffassung), dass man eine komplexe Aufgabenstellung > in immmer simpler zu lösende EInzelprobleme auflöst ... > bis "nix mehr geht". Jein... Zerlegung komplexer Aufgaben in einfachere Teilaufgaben ist grundsätzlich zweckmäßig, ABER: 1. Diese Zerlegung muss nicht zwingend nach dem Top-Down- Prinzip erfolgen (es wäre nämlich zu klären, was das in der Praxis überhaupt heißen soll), und 2. ist eine "Zerlegung einer komplexen Aufgabenstellung" nicht deckungsgleich mit einer "Problemanalyse". Mein kindlicher Glaube an die Allmacht des "Top-Down- Entwurfes" ist vielleicht der dümmste und folgenreichste Fehler, den ich im Leben überhaupt gemacht habe... > Eine gewisse (entfernte) Ähnlichkeit bezüglich der > Motivation zur Herbeiführung der ersten drei Normalformen > für relationale Datenbanken sei möglicherweise gegeben. Die Idee ist nicht schlecht -- aber nicht zu Ende gedacht: Die Normalformen sind keine Zauberformeln, die man auf das Problem in der Anwendungsdomäne anwendet, und dann fällt einem die fertige Implementierung in den Schoß. Die Normalformen sind Prüfbedingungen, die auf das Daten- modell angewendet werden, um dessen Tauglichkeit zu beurteilen. Die Arbeit besteht darin, das Datenmodell aufzustellen! > Oder gibts da inzwschen etwas vollkommen Neues und > ich bin völlig aus der Zeit gefallen? Macht man > Problemanalysen heute noch so? Wie "so"?
Tim T. schrieb: > Walter T. schrieb: >> Frank E. schrieb: >>> Macht man Problemanalysen heute noch so? >> >> Der Name "top-down approach" heisst schon seit Ewigkeiten >> so, weil es auch mindestens genausolange einen anderen >> systematischen Ansatz in gegenteiliger Richtung gibt. > > Der aber in der Regel in der Programmierung(!) bislang, > wenn überhaupt nur für schnelle Frickellösungen genutzt > wurde. Das sind ja auch nur -- vorsichtig geschätzt -- 90% der innovativen und kommerziell erfolgreichen Softwareprodukte...
Grummler schrieb: > Das sind ja auch nur -- vorsichtig geschätzt -- 90% der > innovativen und kommerziell erfolgreichen Softwareprodukte... YMMD :-)
Ich hab in der Diskussion mit "top-down" als ersten Schritt zur Analyse angefangen. Der Begriff "bottom-up" ist mir durchaus geläufig, aber eher nicht als Gegesatz zu top-down, sondern als Methode für die "Synthese", ergo das Coding vom Einfachen zum Komplexen. Warum hab ich das Thema überhaupt angefangen? Wir haben in der Firma immer mal wieder Praktikanten für 6 Monate, die nach 2 Jahren Unterricht bei einem Bildungsträger zu IHK-geprüften Anwendungsentwickler/innen werden wollen. Alle sind lieb, nett, freundlich und nicht wirklich blöd, aber einen wirklichen "Freak", der für das Programmieren förmlich "brennt" hatten wir bisher nur einmal. Was nahezu allen fehlt, ist bereits die Fähigkeit, ein (aus meiner Sicht) simples Problem zu analysieren. Also dieses Schritt für Schritt in einzeln überschaubare Teilprobleme zu zerlegen und dann ... irgendwann mal Code zu schreiben, der die Lösung umsetzt. Hier mal ein Beispiel:
1 | In einer Datenbanktabelle sind Dateipfade (mit Dateiname u. -Typ) hinterlegt. Alle TIF-Dateien, deren Name eine bestimmte vorgegeben Struktur aufweist (z.B. beginnt mit einem "Y", gefolgt von vier Ziffern), sind in einen Ordner auf ein extrenes Volume zu verschieben, dessen Name das Erstellungsdatum der Datei als Prefix enthält. Der Datenbankeintrag ist danach entsprechend anzupassen und in einem zusätzlichen Feld ein Marker für "Export" von False auf True zu setzen. |
Dass einem die Lösung hierfür (und als Anfänger) nicht in 3 Minuten fix und fertig einfällt, ist nachvollziehbar. Aber stundenlang vor der Aufgabe zu hocken und nicht zu wissen, wie man überhaupt anfängt, doch wohl eher nicht. Langer Rede kurzer Sinn: Gibts für den Einstieg in diese Art der "Problemanalyse" eigentlich gute, mögl. deutsche, Literatur? Ich selbst kann mich nach ca. 30 Jahren Praxis nicht wirklich erinnern, wo ich DAS gelesen hätte, inzwischen ist es einfach Intuition und Erfahrung. Aber soviel Zeit haben die Praktikanten logischerweise nicht.
Grummler schrieb: >> Der aber in der Regel in der Programmierung(!) bislang, >> wenn überhaupt nur für schnelle Frickellösungen genutzt >> wurde. > > Das sind ja auch nur -- vorsichtig geschätzt -- 90% der > innovativen und kommerziell erfolgreichen Softwareprodukte... In Deutschland macht man Top-Down-Superanalysen während der Ami schon so einiges hingefrickelt hat (MS, Apple, Google ...). Aber wenn dann die Analyse fertig ist, dann kommt das ganz große Ding Supersoftware, das die Welt verändert und den Bedürfnissen der Menschheit von 1985 gerecht wird. Dann gucken die Amis doof.
Jetzt sind wir der Sache schon näher, deine eigentliche Diskussion zielt darauf ab, sich über unfähige Praktikanten zu echauffieren. Ist auch nicht verwunderlich, die erste Klasse geht an die Technische Universität, die zweite an die Fachhochschule und die dritte macht eine Ausbildung. Tendenziell gibt es mehr Drittklassige an den Technischen Universitäten als umgekehrt. Und schlussendlich hast du durch unsere gesellschaftlichen Umwerfungen mit jungen Leuten zu tun, die im Bergwerk in Bottrop besser aufgehoben wären. Aber bitte tu deinem Chef den Gefallen und sorge dafür, dass das "Wissen gleichmäßiger verteilt wird".
Aristoteles schrieb: > Jetzt sind wir der Sache schon näher, deine eigentliche Diskussion zielt > darauf ab, sich über unfähige Praktikanten zu echauffieren. Damit kann man die eigene Unfähigkeit halt gut übertünchen. Alles was der Deutsche Softwareingenieur hervorgebracht hat ist SAP. Eine Glanzleistung der Boomer!
Frank E. schrieb: > Was nahezu allen fehlt, ist bereits die Fähigkeit, ein (aus meiner > Sicht) simples Problem zu analysieren. Also dieses Schritt für Schritt > in einzeln überschaubare Teilprobleme zu zerlegen und dann ... > irgendwann mal Code zu schreiben, der die Lösung umsetzt. Ist auch nicht jedem gegeben: Es soll Leute geben, die es mit Logik nicht so richtig haben und koennen sogar ein wichtiger Bestandteil der Bevoelkerung darstellen (die Bewohner der B-Ark). Warum dann jemand in einen MINT-Bereich geht: Keine Ahnung. Gruesse Th.
Thomas W. schrieb: > Ein wenig Selbstkritik waere auch bei Dir angesagt, Du kommst mit Fragen > an die schon zeigen, dass Du z.B. C++ nicht Dein Forte ist. > Gruesse > Th. Och, das halte ich gut aus. Nicht jeden sytaktischen Kunstgriff in C++ routiniert zu kennen, spielt m.E. auf einem anderen Level, als Aufgabenstellungen ganz allgemein zu analysieren. Lasst uns beim Thema bleiben. Schon garnicht will ich mich "echhauffieren", ich suche nach einer Lösung. Ich würde den Praktikanten ja gerne mit passender Literatur helfen und nicht immer nur sagen müssen: "Das macht man halt so, dafür brauchts Gefühl ...". Das verfängt einmal, zweimal mit bewundernden Blicken, nütz ihnen aber am Ende nicht ...
"Weniger schlecht programmieren" von Passig und Jander passt für Programmieranfänger ungefähr in diese Lücke. Ansonsten muss man sich damit abfinden, das Studenten heute erst Mitte 20 ihre ersten eigenen Erfahrungen sammeln dürfen. Mit viel Glück haben sie das Praktikum selbst organisiert - aber ich habe auch schon mit Eltern telefoniert.
:
Bearbeitet durch User
Frank E. schrieb: > Wir haben in der Firma > immer mal wieder Praktikanten für 6 Monate, die nach 2 Jahren Unterricht > bei einem Bildungsträger zu IHK-geprüften Anwendungsentwickler/innen > werden wollen. Also Umschulung zum Fachinformatiker für Anwendungsentwicklung? > Was nahezu allen fehlt, ist bereits die Fähigkeit, ein (aus meiner > Sicht) simples Problem zu analysieren. Was glaubst du warum die einen IHK-Schein über einen "Bildungsträger" machen? Ok, rhetorische Frage. Die Antwort ist, dass es nicht zu mehr gereicht hat. Warum auch immer, von dumm wie Bohnenstroh, fehlgeleiteter "Gamer" bis schwerer Schicksalsschlag ist alles möglich. Wer Denker haben will nimmt keine Handwerker. > Langer Rede kurzer Sinn: Gibts für den Einstieg in diese Art der > "Problemanalyse" eigentlich gute, mögl. deutsche, Literatur? Vielleicht. Aber erst mal musst du wissen wo sie stehen. Das heißt, sieh dir ihr Ausbildungsmaterial an und versuche abzuschätzen was sie an Handwerkszeug haben. Dieses "man muss die Leute dort abholen wo sie stehen" Blablabla. Ich glaube nämlich nicht, dass denen ein schönes deutsches, akademisches Informatik-Lehrbuch irgendwie hilft. Denn vermutlich fehlen dafür fundamentale Dinge. Divide et impera ist ja keine IT-spezifische Technik. Für die ersten Schritte braucht man mehr Textverständnis (aus dem Deutschunterricht in der Schule) als IT-Kenntnisse. Wenn du trotzdem mit Büchern kommen möchtest, ich kann nur ein paar sehr alte Schinken, noch dazu in Englisch, vorschlagen. Der Erfinder der Strukturierten Analyse: Tom Demarco: Structured Analysis and System Specification Allerdings mittlerweile einiges an geistiger Transferleistung nötig um Erkenntnisse für die aktuelle IT-Welt raus zu ziehen. Gause, Weinberg: Exploring Requirements: Quality Before Design und Gause, Weinberg: Are Your Lights On? How to Figure Out What the Problem Really is Gilb: Principles Of Software Engineering Management Von Gilb gab es Jahrzehnte später noch mal einen Aufguss der das Ganze unter neuem Namen mit pompös erweitertem Inhalt. Ist so na ja ... Im Prinzip auch interessant, aber mit einer eingeschränkten Sichtweise, ist die alte Literatur aus den Anfängen von OO. Rumbaugh, Booch, Coleman, etc. Die haben gerne weiter ausgeholt und Problemanalyse für OO-Modellierung mit beschrieben.
:
Bearbeitet durch User
Frank E. schrieb: > Langer Rede kurzer Sinn: Gibts für den Einstieg in diese Art der > "Problemanalyse" Nach meinem Verständnis ist bei der von dir geschilderten Aufgabe die "Problemanalyse" schon lange zuvor abgeschlossen worden und hat zu dieser konkreten Anforderung geführt, die es jetzt stupide umzusetzen gilt.
Irgend W. schrieb: > Frank E. schrieb: >> Langer Rede kurzer Sinn: Gibts für den Einstieg in diese Art der >> "Problemanalyse" > > Nach meinem Verständnis ist bei der von dir geschilderten Aufgabe die > "Problemanalyse" schon lange zuvor abgeschlossen worden und hat zu > dieser konkreten Anforderung geführt, die es jetzt stupide umzusetzen > gilt. Das sehe ich im Momet nicht so. Die Aufgabenstellung ist natürlich bewusst so formuliert, um das Denken in eine bestimmte Richtung zu lenken. Wenn jemand eine völlig eigene Lösung hat, wäre mir das auch egal, hauptsache es funktioniert zuverlässig und der Aufwand ist nicht abartig größer. Ich würde "ganz konventionell" als erste Schritte für einen Lösungsvorschlag sowas in der Art erwarten: 1. Datenbankfeld in eine Variable kopieren 2. systemtypischen Pfad-Delimiter abfragen (Win , Mac , Lnx ...) 3. Anzahl der Delimiter im Pfad ermitteln 4. letztes Element ist Dateiname 5. prüfen, ob Dateityp TIF ist 6. wenn ja dann ... usw.
Walter T. schrieb: > "Weniger schlecht programmieren" von Passig und Jander passt für > Programmieranfänger ungefähr in diese Lücke. > > Ansonsten muss man sich damit abfinden, das Studenten heute erst Mitte > 20 ihre ersten eigenen Erfahrungen sammeln dürfen. Mit viel Glück haben > sie das Praktikum selbst organisiert - aber ich habe auch schon mit > Eltern telefoniert. Hab ich mal als EBook besorgt, schau' ich mir an. Danke für den Tip.
Hannes J. schrieb: > Gause, Weinberg: Are Your Lights On? How to Figure Out What the Problem > Really is Ich habe es gerade mal gelesen. Gut geschrieben und auch recht unterhaltsam, aber dafür, es einem Auzubi o.Ä. in die Hand zu drücken deutlich zu philosophisch und wenig pragmatisch.
:
Bearbeitet durch User
Hannes J. schrieb: > Wer Denker haben will nimmt keine Handwerker. ...und wer weder dies noch das braucht, stellt Dich ein. Hannes J. schrieb: > Dieses "man muss die Leute dort abholen wo sie > stehen" Das ist die Grundvoraussetzung für eine Arbeit als Taxifahrer!
Irgend W. schrieb: > Frank E. schrieb: >> Langer Rede kurzer Sinn: Gibts für den Einstieg in diese >> Art der "Problemanalyse" > > Nach meinem Verständnis ist bei der von dir geschilderten > Aufgabe die "Problemanalyse" schon lange zuvor abgeschlossen > worden und hat zu dieser konkreten Anforderung geführt, die > es jetzt stupide umzusetzen gilt. Ich hätte es nicht besser formulieren können.
Interessant wie man von solchen Kinkerlitzechen um die es eigenltich geht mit top-down im urpost ankommt. Da sitzt doch das Problem in der Vorgesetztenabteilung, die Praktikanten haben mit dem Laden die Arschkarte gezogen.
Das meiste Gesagte ist irgendwo richtig, ich möchte trotzdem eine Lanze für "bottom up" brechen. Top-Down ist gut für reproduzierbare Standardaufgaben, wird aber wenig Innovatives schaffen, da man Probleme damit auf Standardlösungen abbildet. Nehmen wir an, ich möchte Waffensysteme gegen Flugzeugträger bauen. Ich könnte ein Heer von Beratern mit der Problemanalyse beschäftigen. Das kostet Millionen, endet mit der Aussage "man braucht Hyperschallwaffen" und führt zu nichts - wenn man sie nicht hat und der Stand der Technik das nicht hergibt. Hat man dagegen Wissenschaftler auf Triebwerkstechnik und Materialforschung angesetzt, dann ergeben sich Hyperschallwaffen ziemlich schnell daraus, ihr Einsatzgebiet ist eher ein Lowbrainer. Ok, wahrscheinlich müsste man beides kombinieren, damit man weiß, wo sich bottom-up lohnt. Würde man alle Probleme auf relationale Datenbanken auf einem Server runterbrechen, käme man nie in die Richtung von In-Memory-Datenbanken, Datalakes, Cloud-Computing etc
Frank E. schrieb: > Irgend W. schrieb: > >> Nach meinem Verständnis ist bei der von dir geschilderten >> Aufgabe die "Problemanalyse" schon lange zuvor abgeschlossen >> worden und hat zu dieser konkreten Anforderung geführt, die >> es jetzt stupide umzusetzen gilt. > > Das sehe ich im Momet nicht so. Wieso nicht? Lass' uns mal beim Begrifflichen bleiben: Eine "Aufgabe" ist für mich etwas, das mir/Dir jemand "aufgegeben" hat. Ein Auftrag also. "Machense mal eben schnell..." Die Aufgabe kann ein normaler Auftrag sein und bleiben, den man halt abarbeitet, sie kann sich aber auch als Problem erweisen -- wenn man nämlich an irgend einem Punkt feststellt, dass man keine Ahnung hat, wie man zum Ergebis kommen kann. Der Begriff "Problem" ist in meinem Universum orthogonal dazu. Ein Problem ist eine Fragestellung mit Wissensdefizit -- also eine Frage, bei der der Fragesteller weiss (oder wenigstens ahnt), dass ihm Teilschritte fehlen, die zur vollständigen und korrekten Beantwortung notwendig sind. > Die Aufgabenstellung ist natürlich bewusst so formuliert, Du sagst es: "Aufgabenstellung". Das, was Du formuliert hast, ist m.E. eine Skizze eines Algorithmus. Ein Problem kann ich da nicht erkennen.
Frank E. schrieb: > Langer Rede kurzer Sinn: Gibts für den Einstieg in diese Art der > "Problemanalyse" eigentlich gute, mögl. deutsche, Literatur? Schaue Dir einmal https://www.deinprogramm.de/ bzw. das Buch dazu https://www.deinprogramm.de/sdp/ an. Es nutzt als Programmiersprache scheme bzw racket. Wahrscheinlich verwendet ihr in der Firma etwas anderes, aber für die Grundlagen ist es evtl. hilfreich. "DeinProgramm ist ein Projekt zur Anfängerausbildung im Programmieren, das seit 1999 an der Universität Tübingen und anderswo entwickelt wird. Die entstandenen didaktischen Konzepte, Software und Materialien wurden in zahlreichen Anfängerausbildungen erprobt und kontinuierlich verbessert." "Schreibe Dein Programm! ist eine Einführung in die Entwicklung von Programmen und die dazugehörigen Grundlagen. Im Zentrum stehen Konstruktionsanleitungen, welche die systematische Konstruktion von Programmen fördern, sowie Techniken zur Abstraktion, welche die Umsetzung der Konstruktionsanleitungen ermöglichen. In der Betonung systematischer Konstruktion unterscheidet sich dieses Buch drastisch von den meisten anderen Einführungen in die Programmierung."
Beitrag #7239088 wurde von einem Moderator gelöscht.
Das Problem ist, es kann nicht jeder programmieren, egal was allgemein dazu gesagt wird. Manche Menschen sind einfach nicht zum strukturierten Denken fähig und dazu kommt, vor allem in den letzten Jahren, praktisch keinerlei Durchhaltevermögen. Wir produzieren praktisch seit Jahren schon menschlichen Ausschuss, der zu rein gar nichts in der Lage ist und letztlich als Konsumzombie derer enden wird, die nicht permanent alles dafür getan haben, dass Fleiß, Denkvermögen und Leistungswille etwas abartiges sind.
Beitrag #7239125 wurde von einem Moderator gelöscht.
Beitrag #7239138 wurde von einem Moderator gelöscht.
Topdown bildet auf Standard Komponenten ab. Muessen zB Daten gespeichert werden, bedetet das fuer viele Leute einfach eine Datenbank, auch wenn jeder Eintrag nur einmal vorkommt, und ein File geeigneter waere.
Beitrag #7240191 wurde von einem Moderator gelöscht.
Beitrag #7240504 wurde von einem Moderator gelöscht.
Tim T. schrieb: > Das Problem ist, es kann nicht jeder programmieren, > egal was allgemein dazu gesagt wird. Ein weiteres Problem ist, dass die Schnittmenge derer, die gut programmieren können, mit denen, die gut erklären können, nahezu leer ist. > Manche Menschen sind einfach nicht zum strukturierten > Denken fähig Andere wiederum sind unfähig, sich in die Erfahrungswelt ihres Gegenübers hineinzuversetzen und sich so auszudrücken, dass sie von ihm verstanden werden... > und dazu kommt, vor allem in den letzten Jahren, praktisch > keinerlei Durchhaltevermögen. Wir produzieren praktisch > seit Jahren schon menschlichen Ausschuss, Lass' es mich so ausdrücken: Jeder Couchpotato ist mir lieber als ein egomanischer Soziopath, der andere als "menschlichen Ausschuss" bezeichnet...
Grummler schrieb: > Tim T. schrieb: > >> Das Problem ist, es kann nicht jeder programmieren, >> egal was allgemein dazu gesagt wird. > > Ein weiteres Problem ist, dass die Schnittmenge derer, > die gut programmieren können, mit denen, die gut erklären > können, nahezu leer ist. Kann durchaus sein. >> Manche Menschen sind einfach nicht zum strukturierten >> Denken fähig > > Andere wiederum sind unfähig, sich in die Erfahrungswelt > ihres Gegenübers hineinzuversetzen und sich so auszudrücken, > dass sie von ihm verstanden werden... Auch das ist möglich, ändert nur nichts am Problem mit den Deppen oder muss mittlerweile jeder gepampert werden und hat automatisch das Anrecht auf beliebig viel Aufmerksamkeit, damit auch er es irgendwann rafft? >> und dazu kommt, vor allem in den letzten Jahren, praktisch >> keinerlei Durchhaltevermögen. Wir produzieren praktisch >> seit Jahren schon menschlichen Ausschuss, > > Lass' es mich so ausdrücken: Jeder Couchpotato ist mir lieber > als ein egomanischer Soziopath, der andere als "menschlichen > Ausschuss" bezeichnet... Lass es mich so ausdrücken: Das ist mir wirklich vollkommen egal (was dich aber eigentlich nicht überraschen sollte).
Hi, ich bin zwar hardware mäßig unterwegs, habe in meinen Projekten viele Berührungspunkte mit den Softwareentwicklern. Wir haben hier einiges in Richtung V-Modell und auch agile gemacht. Auch Fluktuation der Softwareentwickler (eher Prioritäten Verschiebung innerhalb der Firma). Grundsätzlich wird bei uns ein Anforderungsmanagement geführt und eine System- und Softwarearchitektur erstellt und gepflegt. Das Ganze kann man übertreiben (sowohl mit den Tools wie auch in der Tiefe), aber bewährt hat sich ein Architekturbeschreibung in Confluence mittels einfachen Diagrammen und darin enthaltenden Links zu ggf. Erklärenden Beiträgen. Im Anforderungsmanagement haben wir eine Tracebility auf die Systemtests. Beide haben eindeutige IDs und diese sind dann beispielsweise im Quellcode vermerkt. Selbstverständlich wird der Code eingecheckt und in Jenkins kompiliert. Unsere Erfahrung ist, dass diese Kombi ein guter Kompromiss ist und neue Kollegen oder Springer relativ schnell ausreichende systemkenntnisse erlangen. Der Rest ist dann auch fachliches Können. Es gibt aber in einem anderen Fachbereich auch Frameworks die schon etliche Jahrzehnte auf dem Buckel haben und schon gut abgehängt sind. Da hat kaum noch einer einen 100% Durchblick und hier fehlt ein vollständiges Anforderungsmanagement und eine system-Architektur. Die Kollegen sind daher teilweise echt am fluchen und von heute auf morgen kann das keiner geradeziehen (und die Mittel dazu sind auch nicht immer gegeben) Viele Grüße
Mancher hier hängt das Problem "viel zu hoch". Die Frage ist doch ganz praktisch: Was mache ich mit einem Praktikanten/Praktikantin, der/die z.B. bei der weiter oben genannten Aufgabe (Dateien erkennen und verschieben) einfach nicht wissen, wie sie anfangen sollen? Sich empören oder Standpauken halten - damit ist niemandem geholfen. Den bis dato erfolgten Unterricht zu wiederholen, geht über meine Kraft. Die Leute einfach als "zu blöd" rauszuschmeissen geht gegen meine soziale Ader ... ?
Tim T. schrieb: > Grummler schrieb: > >>> Manche Menschen sind einfach nicht zum strukturierten >>> Denken fähig >> >> Andere wiederum sind unfähig, sich in die Erfahrungswelt >> ihres Gegenübers hineinzuversetzen und sich so auszudrücken, >> dass sie von ihm verstanden werden... > > Auch das ist möglich, ändert nur nichts am Problem mit den > Deppen Du hast eine seltsame Logik. Wenn Du mit den Dir anvertrauten Praktikanten oder Lehrlingen mit derselben Verachtung und derselben Gossensprache sprichst, die Du hier an den Tag legst, dann verstehe ich mühelos, wieso deren Verhalten nicht ganz Deinen Wünschen entspricht... > oder muss mittlerweile jeder gepampert werden und hat > automatisch das Anrecht auf beliebig viel Aufmerksamkeit, > damit auch er es irgendwann rafft? Machst Du gerade einen Sorgerechtsstreit durch -- oder wieso kannst Du nicht über andere Leute schreiben, ohne in jeden Satz drei Diffamierungen einzubauen? Davon aber abgesehen: Wenn man zur Bildung von Leuten beitragen will, muss man die Leute natürlich dort abholen, wo sie im Moment sind. Das ist eine Binsenweisheit -- und auch völlig unabhängig davon, ob man das gut findet, oder ob man diese Leute leiden kann. Wenn man dazu nicht Willens oder in der Lage ist, dann ist man für die Ausbildung von Leuten schlicht nicht geeignet. Dass man trotzdem nur einen (mehr oder weniger großen) Teil der Betreffenden erreicht, ist eine ganz andere Sache. >>> und dazu kommt, vor allem in den letzten Jahren, praktisch >>> keinerlei Durchhaltevermögen. Wir produzieren praktisch >>> seit Jahren schon menschlichen Ausschuss, >> >> Lass' es mich so ausdrücken: Jeder Couchpotato ist mir lieber >> als ein egomanischer Soziopath, der andere als "menschlichen >> Ausschuss" bezeichnet... > > Lass es mich so ausdrücken: Das ist mir wirklich vollkommen > egal (was dich aber eigentlich nicht überraschen sollte). Sehr gut erkannt: Es überrascht mich nicht. Was mein Bild von Dir mit Deiner Meinung über Auszubildende zu tun hat, bleibt dem Leser als Übungsaufgabe überlassen.
Frank E. schrieb: > Die Frage ist doch ganz praktisch: Was mache ich mit einem > Praktikanten/Praktikantin, der/die z.B. bei der weiter oben > genannten Aufgabe (Dateien erkennen und verschieben) einfach > nicht wissen, wie sie anfangen sollen? > > Sich empören oder Standpauken halten - damit ist niemandem > geholfen. Den bis dato erfolgten Unterricht zu wiederholen, > geht über meine Kraft. Die Leute einfach als "zu blöd" > rauszuschmeissen geht gegen meine soziale Ader ... ? Naja, vor der Therapie kommst stets die Diagnose. Daher meine Frage: Wieso bist Du für Praktikant(inn)en verantwortlich, wenn Du ganz offensichtlich keinerlei Ahnung von deren Kenntnissen und Fähigkeiten hast?
Hallo Tim .t. Tim T. schrieb: >> Der Name "top-down approach" heisst schon seit Ewigkeiten so, weil es >> auch mindestens genausolange einen anderen systematischen Ansatz in >> gegenteiliger Richtung gibt. > > Der aber in der Regel in der Programmierung(!) bislang, wenn überhaupt > nur für schnelle Frickellösungen genutzt wurde. Tatsächlich ist Programmieren (wie jede andere Entwicklung auch) ein rekursiver, iterativer Prozess. Man hat eine theoretische Idee, macht danach etwas (top down) und stellt fest, dass es nicht funktioniert und analysiert und biegt es so hin, dass es funktioniert (bottom up). Mit den gewonnenen Erkenntnissen hat man jetzt bessere Ideen, und setzt diese um (top down), und muss diese dann wieder durch Analyse und Nachbessern an die Realität anpassen (bottom up). Und so geht das ganze mit ständiger Abwechslung zwischen top down und bottom up einer permanenten Verbesserung entgegen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Und so geht das ganze mit ständiger Abwechslung zwischen top down und > bottom up einer permanenten Verbesserung entgegen. ;O) Nebenbei trainiert das ständige Auf und Ab die Oberschenkelmuskulatur.
Frank E. schrieb: > Die Frage ist doch ganz praktisch: Was mache ich mit einem > Praktikanten/Praktikantin, der/die z.B. bei der weiter oben genannten > Aufgabe (Dateien erkennen und verschieben) einfach nicht wissen, wie sie > anfangen sollen? > > Sich empören oder Standpauken halten - damit ist niemandem geholfen. > Den bis dato erfolgten Unterricht zu wiederholen, geht über meine Kraft. > Die Leute einfach als "zu blöd" rauszuschmeissen geht gegen meine > soziale Ader ... ? Das hoert sich ganz bloed an: Froh sein, dass der Mann/Frau bald wieder weg geht. Du bist (offensichtlich) nicht der Lehrer der mit unendlicher Geduld und Empathie ausgestattet ist. Und manchmal kann man nichts machen (ich hatte auf einem Markt mal ein junges Maedchen mit einer massiven Dyskalkulie. Es ging soweit: 1 Broetchen kostet 20Cent, 5 Broetchen kosten wieviel?) Bei diesem Beispiel der Dyskalkulie war es offensichtlich, dass es mit Uebungen oder intellektuelles Durchdringen keine Chance gibt (sehr nettes freundliches Maedchen, 20 Jahre jung, normale Gespraeche waren einwandfrei moeglich, aber wenn es um Zahlen ging war es zu Ende). Wie ich schon vorher schrub: Nicht jedem ist es gegeben logische Schluesse zu tun. Der/die Betroffene muss sich dann etwas Neues suchen. Koennte z.B. Politiker werden. Deine Aufgabe waere jetzt, einen neuen Praktikanten zu suchen und dem Aktuellen freundlich, aber bestimmt klar zu machen dass MINT wohl nicht ihr/sein Ding ist. Eigentlich haette das schon laengst in der Schule erkannt wurden sein und vielleicht mit "Foerderstunden" oder "Nachhilfe" bei Kindern (Kinder koennen fast alles lernen) korrigiert werden sein. +1 das Du Dir ueberhaupt noch die Muehe gibst Jugendliche auszubilden, Frust und Kosten hat schon viele Firmen das Ausbilden vergaellt. Gruesse Th.
Hallo Thomas W. Thomas W. schrieb: > Bei diesem Beispiel der Dyskalkulie war es offensichtlich, dass es mit > Uebungen oder intellektuelles Durchdringen keine Chance gibt (sehr > nettes freundliches Maedchen, 20 Jahre jung, normale Gespraeche waren > einwandfrei moeglich, aber wenn es um Zahlen ging war es zu Ende). Solche Fälle von speziellem Unvermögen sind wesentlich häufiger als man denkt, allerdings sind sie selten so plakativ. Leider bestimmen in einer Leistungsgesellschaft unsere Unfähigkeiten wesentlich mehr als unsere Fähigkeiten unser Schicksal. > > Wie ich schon vorher schrub: Nicht jedem ist es gegeben logische > Schluesse zu tun. Der/die Betroffene muss sich dann etwas Neues suchen. > Koennte z.B. Politiker werden. 1) Dyskalkulie hat nichts mit einer Unfähigkeit zu logischem Denken zu tun. 2) Politiker ist ein wesentlich anspruchsvollerer Job als Du meinst. So anspruchsvoll, das eigentlich jeder der sich damit versucht, schnell an seine Grenzen stößt. Darum ist ja auch so wichtig, Härtefälle abwählen zu können, was in Autokratien leider nicht geht. > Deine Aufgabe waere jetzt, einen neuen Praktikanten zu suchen und dem > Aktuellen freundlich, aber bestimmt klar zu machen dass MINT wohl nicht > ihr/sein Ding ist. Solange Du keine konkrete sinnvolle Alternative aufzeigen kannst, wird jeder Job nicht passend sein. > Eigentlich haette das schon laengst in der Schule erkannt wurden sein > und vielleicht mit "Foerderstunden" oder "Nachhilfe" bei Kindern (Kinder > koennen fast alles lernen) korrigiert werden sein. Nein. Korrigieren kann man das selten, bestenfalls lindern. Ob das gelinderte Problem dann irgendwo in einem anderen Job noch störend ist, hängt am Einzelfall. > +1 das Du Dir ueberhaupt noch die Muehe gibst Jugendliche auszubilden, > Frust und Kosten hat schon viele Firmen das Ausbilden vergaellt. Umgekehrt genauso. Was man unter Mühen gelernt hat, hat man auch gelernt zu hassen. Siehe auch: Beitrag "Re: Fachkräftemangel - Woher kommen die Widersprüche?" Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
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.