Hey, ich wollte von euch wissen wie Ihr an die Programmierung an sich ran geht. Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch vorschweben. Würde mich sehr über praktische Kenntnisse die man im HomeSchooling nicht so sehr lernt freuen :)
Gerüchten zufolge hängt es von vielen Faktoren ab, wie man an eine Sache herangeht. Etwa der Sprache, der Art der Projekte, der übergeordneten Organisation, etc., pp.
Reden wir von einem 10 Zeiler, welcher 100 Mal "Hello world" schreibt ? Den lassen wir erst mal weg. Das Programm hat also erst mal eine Funktionalitaet. Die bildet man erst mal schnell ab. Dann muessen auch Debug Strukturen her, und nachher soll das Ganze auch noch bedienbar sein. Ja nachdem wer etwas zu sagen hat beginnt man anders wo. Wenn die Funktionalitaet eher Trivial ist, also die Bediener hohes Gewicht haben, beginnt man mit der Bedienung und eher nichts hinten dran. Wenn die Wartbarkeit ein Thema ist, schafft man wartbare Strukturen zu Beginn weg. Wenn die Funktionalitaet aufwendig ist, die Bedienung eher einfach, beginnt man mit der Funktinalitaet. Wenn man offene Fragen hat ueber die Verwendete Technologie loest man diese zuerst mit ein paar Testmustern. Wenn der Geldgeber aufsaessig ist, bedient man den zuerst. Der Will immer etwas, dh einen Fortschritt, sehen.
:
Bearbeitet durch User
HauSi schrieb: > ich wollte von euch wissen wie Ihr an die Programmierung an sich ran > geht. Das Hängt immer von der Kultur im Unternehmen ab. Nicht umsonst sagt man "Culture eats strategy for breakfast!" und da Software Entwicklung ein sehr manueller Prozess ist. Hängt das oft von den Menschen, ab welche an den Prozess beteiligt sind. Grundsätzlich gibt es in der Planung der Software zwei Ansätze "Top Down" oder "Bottom Up", welcher für dein Projekt sinnvoll ist, hängt von dem Umfeld, in den du arbeitest ab. Beim Top Down Ansatz planst du das ganze Projekt durch, gerne wird hier UML oder ähnliches verwendet, um Ergebnisse zu produzieren. Der Ansatz wird gerne in großen Firmen genutzt oder in Sektoren wo man Sehr stark mit Safty Requirements zu tun hat. Der Nachteil von dem Ansatz ist, dass man nur sehr spät auf Änderungen reagieren kann, sein es Änderungen am Markt unvorhergesehene Probleme oder ähnliches. Der Auftraggeber bekommt nur selten eine Möglichkeit Steuernd einzugreifen. Der Vorteil die Software ist Gut Beschrieben und Zertifizierungen sind meistens leicht möglich. Beim Bottom Up Ansatz, versucht man in schneller Folge kleine werte zu schaffen, welche sich in einem Lego Prinzip zu einem Komplexen Konstrukt vereint. Diese Strömung wird zum Beispiel im Agilen zelebriert und gerne von Start-ups gelebt. Große Konzerne versuchen das zwar zu Kopieren, scheitern aber oft an ihren internen Prozessen und Silos der Zuständigkeiten. Der Vorteil von einer Bottom Up Entwicklung ist, das relativ schnell Feedback vom Auftraggeber eingesammelt werden kann und man sehr schnell auf eine neue Situation reagieren kann. Der Nachteil ist, dass man leicht technische Schuld aufbaut und es zu einer Situation kommen kann, in der man sein Projekt restrukturieren muss, um weiter zukommen. Man entwickelt also eine ganze Menge Code, der nur eine Zwischenlösung ist.
HauSi schrieb: > Hey, > ich wollte von euch wissen wie Ihr an die Programmierung an sich ran > geht. > > Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr > Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch > vorschweben. Kommt ganz auf das Programm an. Oft (öfter als ich eigentlich zugeben sollte) kommt VHIT-Programmierung (vom Hirn ins Terminal) zum Einsatz. Allerdings muss ich oft Dinge prototypisch ausprobieren, weil es keine klaren Anforderungen, sondern eher Ideen gibt und man dann damit etwas spielen muss. Es ist eben in meinem Fall selten die Entwicklung einer komplett durchspezifierten Software. Das sieht in anderen Bereichen ggf. ganz anders aus.
Ich geh jetzt mal von einem Programm für einen Mikrocontroller aus: - Grundgerüst (Prozessortyp, Treiber und Treiber definitionen) - Wenn ein Display angeschlossen ist oder Status-LEDs diese zum Laufen bringen - Funktionen für die einzelnen Hardwarekomponenten erstellen (Sensoren, Aktoren, ...) - den ganzen Mist im Main vereinen :-D
Losprogrammieren ja, ich weiß, sollte man nicht machen. Ist aber die Essenz der ganzen tollen Projektideen der letzten 20 Jahre. Entweder bist Du noch ein Programmier-Anfänger, dann ist die Programmiererfahrung wichtiger als Konzepte, die Du noch nicht durchblicken kannst. Oder Du bist ein Profi, dann kennst Du die wichtigsten Konzepte und kannst Deine Gedanken besser direkt formal ordnen 1) Ablaufdiagramme (z.B.: Nassi-Sheydermann) Die waren vor den ersten Hochsprachen sinnvoll, da der (Assembler-)Code schlechter zu lesen war, bzw. viele Instruktionen brauchte, die in einem Kästchen oder Pfeil dargestellt werden. Heute ist das Unsinn, die Darstellung in der (bekannten) Programmiersprache, mit Chromacoding, Faltung, Token-Browsing etc. ist deutlich aussagekräftiger. 2) Scrum, XP, ... die sagen praktisch nichts anderes, als relativ schnell einen Prototypen zu bauen und den sukzessive zu erweitern. Es ist einfach wichtig, schnell zu sehen, wie es sich anfühlt. Niemand glaubt heute, dass zu beginn eines Projektes jemand die Anforderungen aufnehmen kann 3) UML, Matlab-Simulink-Stateflow und Co Entweder ist es die Programmierung oder es dient dazu, das Problem mit anderen zu erörtern, die Lösung zu entwickeln. Es ist aber etwas anderes, das Problem zu erarbeiten oder zu Programmieren. Natürlich sollte man das Problem zuerst einmal irgendwie verstehen. Wenn dazu UML gut ist, OK. Bleistiftzeichnungen oder Power-Point, ein Besuch beim Kunden oder ein Video des Prozesse, alles OK. 4) Eine falsch Architektur kann das Projekt gefährden oder teuer machen Ja. Das ist so. Das Problem ist nur, dass man die richtige Architektur meist erst entwerfen kann, wenn man das Problem durchdrungen hat. Und das ist meist erst, wenn man zumindest ein erstes System rund laufen hat. Darum ist hier sogar der Rat: Das erste System direkt für die Tonne kreieren. Das Antipattern ist es, bereits für die ersten Daten und Methoden alle Eventualitäten zu berücksichtigen. Das geht meist (wenn nicht immer) in die Hose. Stattdessen schlank und straight programmieren, und sich nicht scheuen, immer wieder zu refakturieren, sprich: Code auch wegzuschmeißen. Also ja, mach mit Bleistift überlegungen. Und versuche das Problem/die Aufgabe zu verstehen, konkret: Testfälle und deren Kriterien zu formulieren. Und dann leg los, wie es am besten passt.
HauSi schrieb: > Wie plant Ihr euer Programm, plant Ihr es überhaupt? Je innovativer ein Projekt für die Beteiligten ist, desto mehr wird Projektplanung zum Mythos. Planen lässt sich nur, was weitgehend verstanden worden ist. > Schreibt ihr Struktograme, Ablaufpläne, zeichnet Ihr > Klassenhierarchien die euch vorschweben. Das ist ein anderes Thema -- nämlich das Thema "Dokumentation". Ich vertrete die Außenseitermeinung, dass bei kleinen Projekten die Dokumentation relativ gesehen wichtiger wird als bei großen -- die Komplexität sinkt nämlich nicht im selben Maße wie die Zahl der Beteiligten. Bei sehr kleinen Projekten muss jeder Beteiligte eine recht große Komplexität bewältigen; das verführt viel stärker dazu, "einfach zu machen", als wenn man sich immer mit mehreren anderen Kollegen abstimmen muss. In größeren Projekten entsteht einiges an Dokumentation "nebenbei". Konkret: Festgestellte Fehler, gewünschte Änderungen und vorgenommene Modifikationen protokolliere ich kurz in Textform (ASCII-Files); komplizierte Algorithmen bekommen eigene Texte zur Herleitung, Erklärung und Beschreibung. Um die Modularisierung zu veranschaulichen, verwende ich manchmal eine Art Blockschaltbild.
Hi Es kommt immer darauf an, Programm vorgegeben oder eigene Idee. Ich hab mal für absolute Anfänger ein Buch geschrieben und im Netz bei MakerConnect.De kostenlos verfügbar gemacht. https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf Hier wird beschrieben, wie ein Programm Schritt für Schritt entsteht. Das Ergebnis ist ein Visual Basic Programm, welches die Variablen eines Assemblerprogrammes erfaßt, in das entsprechend verwendete Format wandelt und zur Anzeige bringt. Vorausgesetzt, das Assemblerprogramm ist als Listing vorhanden. Man kann auch Trigger setzen und im Programm positionieren, umm einen bestimmten Programmteil zu prüfen. Die zugehörigen Variablen werden dann farblich gekennzeichnet. Nun ja, wenn du dich da mal kurz reinliest, so in etwa kann ein Programm entstehen. Aber das ist nicht zu verallgemeinern. Ich habe jahrelang Maschinen programmiert. Das ist etwas ganz anderes. Oft muß ein Programmabschnitt erst mal analysiert werden, um mit vorhandener und erweiterter Peripherie Funktionsabläufe sicher zu ändern. Manche Änderungen brachten den Bedienern enorme Informationsvielfalt, ohne auch nur einen Cent in neue Peripherie zu stecken. Lediglich vorhandene Systeme wurden zur Visualisierung herangezogen. So haben wir Monitore in EX-Räumen vor die Fenster außerhalb des Raumes gesetzt und die Anzeige auf den Monitoren in einer sehr großen Schrift angezeit. Die Lesbarkeit war sogar für halbblinde wie mich noch aus einer Entfernung von über 10 m ohne Brille gegeben. Was will ich damit sagen, Programmieren ist das eine, beherrschen von verschiedenen Systemen und Programmiersprachen das andere. Eine gute analytische Fähigkeit gepaart mit Kombinationsgabe, und es gibt so gut wie keine Probleme mehr. Na ja, von dem was hier steht trifft auf mich vielleicht 60-70 % zu. Ich mußte dann leider aufhören zu lernen, weil ich beim Staat unkündbar angestellt wurde und erst, wenn ich Platz in einer 3 Liter Dose habe, ist er mich los. Gruß oldmax
Crazy H. schrieb: > Ich geh jetzt mal von einem Programm für einen Mikrocontroller aus: Ich nicht. Allein schon deshalb, weil die Frage in der Rubrik "PC-Programmierung" gepostet wurde.
HauSi schrieb: > Wie plant Ihr euer Programm, plant Ihr es überhaupt? Schreibt ihr > Struktograme, Ablaufpläne, zeichnet Ihr Klassenhierarchien die euch > vorschweben. Als erstes werden die Testszenarien definiert, damit das Programm in jeder Phase der Entwicklung verifiziert werden kann.
Egon D. schrieb: > Planen lässt sich nur, was weitgehend verstanden worden ist. Das ist die zentrale Erkenntnis. Die leider viele nicht verstehen, und sich fragen, warum ein Architekt das 11te Einfamilienhaus so viel genauer hinkriegt als ein softwerker die 11te Automatisierung. Oder den BER.
>Egon D. schrieb: >> Planen lässt sich nur, was weitgehend verstanden worden ist. >Das ist die zentrale Erkenntnis. Die leider viele nicht verstehen, und >sich fragen, warum ein Architekt das 11te Einfamilienhaus so viel >genauer hinkriegt als ein softwerker die 11te Automatisierung. Oder den >BER. Der Wunschtraum der Projektleitung ist aber, dass ein Projekt planbar sein soll. Lustigerweise glauben ja viele an das V-Modell und das damit alles planbar sei .. allerdings gibt es im V-Modell viele verdeckte Schleifen, nicht anderes meinen als: funktioniert's nicht, mach's noch mal besser ...
HauSi schrieb: > Wie plant Ihr euer Programm, plant Ihr es überhaupt? Ja natürlich plant man das. Aber das WIE ist sehr unterschiedlich: Bei manchen Vorhaben arbeite ich zu allererst die Algorithmen und das generelle Procedere aus, bevor ich auch nur eine Zeile Code schreibe. Bei anderen Projekten gehe ich von der anderen Seite heran: da schreibe ich zu allererst die Headerfiles (bei C) oder die Interfaces (bei Pascal), dann die zugehörige Funktionalität. Das ist die Version von ganz unten, also von den Lowlevel-Treibern, die dann auch separat getestet werden können Und bei noch anderen Projekten (für den PC) mache ich zu allererst das grafische UI. Und bei noch anderen Projekten ist die eigentliche Hardware-Entwicklung zu allererst (also was da wie funktionieren soll), dann die gestalterischen Fragen (Gehäuse usw.) und dann erst der ganze Software-Kram. Kurzum: es hängt vom Projekt ab, aber eines ist klar: das "in die Tasten hauen" für den Quellcode kommt ganz zuletzt, wenn es neu ist. Bei anderen Quellen hab ich ein Portfolio an Lösungen angesammelt, die sich ganz einfach bewährt haben und die schlichtweg übernommen werden. Da gibt es allenfalls ne Anpassung. > Schreibt ihr Struktograme, Ablaufpläne, > zeichnet Ihr Klassenhierarchien die euch > vorschweben. So eng sehe ich das nicht. Natürlich macht man gelegentlich so seine Aufzeichnungen, Pläne, Zustandsdiagramme, Skizzen, Ablaufpläne usw., aber das ist nur um die Gedanken klarer zu fassen. Viel wichtiger ist es, Interfaces festzulegen. Also die Schnittstellen zwischen einzelnen Funktionsgruppen - und das exakt und vollständig. Nur damit kriegt man ein Gesamtprojekt so aufgeteilt, daß man es auf mehrere Leute (oder zeitlich versetzt für sich selbst) aufteilen kann. Aber bedenke mal eines: Ich bin einer, der Geräte konzipiert, die sich anschließend auch verkaufen lassen - und nicht bloß ein simpler Programmierer. W.S.
Also zunächst mal werden für die nächsten X Wochen etliche Meetings geplant, damit die ganzen Product Owner und Scrum Master beschäftigt sind. Währenddessen machen die erfahrenen Entwickler ihr Ding. Am Ende setzen sich dann alle zusammen und die Entwickler drehen das fertige Produkt so hin, dass die Product Owner und Scrum Master hinterher glauben gewollt zu haben, was sie bekommen.
Egon D. schrieb: > Je innovativer ein Projekt für die Beteiligten ist, > desto mehr wird Projektplanung zum Mythos. Planen > lässt sich nur, was weitgehend verstanden worden ist. Das gilt aber nur fuer die Zeitplanung. Die technische Planung ist fuer innovative Projekte um so wichtiger und auch aufwendiger. Zumindest wenn man kein Zufallsergebnis will. Fuer Routineaufgaben kommt man eher ohne detaillierte Vorausplanung aus.
Maxe schrieb: > Die technische Planung ist fuer > innovative Projekte um so wichtiger und auch aufwendiger. naja, dass innovative kann man nicht planen. Man kann dann Innovationen umsetzen, wenn man sie verstanden hat. Man kann bei Innovationen höchstens Minimal- oder Maximalprinzip anwenden, also Minimal: das Ziel möglichst schnell und billig irgendwie erreichen (frickeln) oder Maixmal: Ein Budget X zur Verfügung stellen und das verforschen. was schrieb: > Am Ende setzen sich dann alle zusammen und die Entwickler drehen das > fertige Produkt so hin, dass die Product Owner und Scrum Master > hinterher glauben gewollt zu haben, was sie bekommen. Die selbstreflexion hat kein Owner oder Master. Egal, was Du ihnen am Ende andrehst, sie haben das Gefühl, dass sie es mit ihren Projekt-Management-Tools (und den damit geknechteten) quasi nach ihrem Ebenbild erschaffen haben.
A. S. schrieb: > naja, dass innovative kann man nicht planen. Man kann dann Innovationen > umsetzen, wenn man sie verstanden hat Beispiel Corona-App. Da muss man sich schon genau ueberlegen, welche Daten man erfasst/verarbeitet, was zentralisiert auf den Servern liegen soll, welche Projektbeteiligten noetig sind, wie man den Code prueft usw. Bevor auch nur die erste Zeile Code geschrieben war, mussten diese Dinge weitgehend geklaert sein, ja, geplant sein. Beim 20ten Messgeraete-GUI ist das anders. Es muss auch definierte Anforderungen geben, aber vieles ist schon implizit klar.
Christoph M. schrieb: >>Egon D. schrieb: >>> Planen lässt sich nur, was weitgehend verstanden >>> worden ist. > >>Das ist die zentrale Erkenntnis. Die leider viele nicht >>verstehen, und sich fragen, warum ein Architekt das >>11te Einfamilienhaus so viel genauer hinkriegt als ein >> softwerker die 11te Automatisierung. Oder den BER. > > Der Wunschtraum der Projektleitung ist aber, dass ein > Projekt planbar sein soll. Dann soll sich die Projektleitung auf reine Bauprojekte beschränken, auf solche trifft das weitgehend zu -- der BER ist eben die Ausnahme, die die Regel bestätigt... Entwicklungsprojekte bergen halt ein Entwicklungsrisiko in sich. > Lustigerweise glauben ja viele an das V-Modell <hinterhältige_Falle> Was ist denn DAS V-Modell? </hinterhältige_Falle> > und das damit alles planbar sei Vieles aus dem Dunstkreis des V-Modells ist durchaus sinnvoll, aber es gehört halt immer noch Sachverstand dazu, zwischen den weitgehend bekannten Dingen, die TATSÄCHLICH planbar sind, und den neuartigen und unbekannten Dingen zu unterscheiden -- bei letzteren muss erstmal das Kernproblem erkannt, formuliert und dann Wissen aufgebaut werden. > .. allerdings gibt es im V-Modell viele verdeckte > Schleifen, nicht anderes meinen als: funktioniert's > nicht, mach's noch mal besser ... Genau. Solche Modelle sind Stadtpläne -- keine Kochrezepte. Was man tun und in welche Richtung man gehen muss, hängt stark davon ab, wo man gerade steht...
Maxe schrieb: > Egon D. schrieb: >> Je innovativer ein Projekt für die Beteiligten ist, >> desto mehr wird Projektplanung zum Mythos. Planen >> lässt sich nur, was weitgehend verstanden worden ist. > > Das gilt aber nur fuer die Zeitplanung. Die technische > Planung ist fuer innovative Projekte um so wichtiger > und auch aufwendiger. Jein. Ich stimmte Dir zu in der Aussage, dass reichlich geistige Vorarbeit zu leisten ist -- aber ich scheue mich (aufgrund sehr schlechter Erfahrungen), diese geistige Arbeit "Planung" zu nennen: Das Ergebnis der Planung ist ein ausgearbeiteter Plan, und ein Plan ist verbindlich und daher einzuhalten. Genau das funktioniert aber nicht. Ich kenne das so, dass man denkt und diskutiert und macht, und als Ergebnis entsteht eine Landkarte, die einige Bezirke enthält, die man schon ganz gut kennt, und dazwischen auch weisse Flecken zeigt, über die man nix weiss. An dem Punkt lassen sich VORLÄUFIGE Arbeitsschwerpunkte benennen, die man in der nächsten Zeit verfolgt. In der nächsten Runde ist die Lage wieder so ähnlich -- nur, dass die Landkarte jetzt etwas anders aussieht. > Fuer Routineaufgaben kommt man eher ohne detaillierte > Vorausplanung aus. Das hängt SEHR stark von der Art der Routineaufgabe und der Anzahl der Beteiligten ab.
Meine Erfahrung ist dass die wesentliche Kernidee sich in einer hoch abstrakten Scriptsprache wie Python in 100 bis 200 Zeilen Code formulieren lässt. Das hat den Vorteil dass man sich nur auf die eigentliche Funktionalität konzentrieren kann. Änderungen am Code und das auffinden von Fehlern im Algorithmus sind ebenfalls einfacher. Python ist ideal um sehr schnell Prototypen zu erstellen. Danach erfolgt noch einiges an Denkarbeit und es entstehen schon die ersten konkreten Ideen wie so ein Programm strukturiert sein sollte. Danach kann man beginnen das ganze in C++/Rust/C# oder was auch immer zu schreiben. Der Anfang ist dann besonders einfach weil man die Scriptsprache als eine Art Vorlage nutzen kann.
Man kann Python dabei wie eine bunte Knetmasse sehen die kinderleicht zu formen ist. Oder man betrachtet es als Lego :D An so einem Objekt Ideen immer wieder umwerfen und abändern ist besonders leicht und genau das ist am Anfang eines Projektes wichtig da man noch ergründen muss wie es am besten geht. Formen mit Knete oder Lego auszuprobieren ist natürlich einfacher als Metalle in CNC Maschinen zu fräsen. Maut man eine Maschine aus Metall ist man auch weniger dazu geneigt mit neuen Ideen zu experimentieren weil das dann viel Arbeit bedeutet und man komplizierte Vorgänge erneut durchlaufen muss.
Nunyagu schrieb: > Man kann Python dabei wie eine bunte Knetmasse sehen die kinderleicht zu > formen ist. Ja, diese Python-Knete nutze ich auch sehr intensiv. Praktisch alle Teile einer Software, bei denen ich mir anfangs bzgl. der Algorithmik, der Datenstrukturen oder der Implementierung noch unsicher bin, werden erst einmal quick & dirty in Python umgesetzt und dann so lange hin und her gebogen, bis ich überzeugt bin, die optimale Lösung für das jeweilige Teilproblem gefunden zu haben. Auf dem Weg dahin besteht die Möglichkeit, die Software(teil)protoypen und die von ihnen gelieferten Ergebnisse Kollegen vorzustellen und mit ihnen darüber zu diskutieren, was meistens zu weiteren wertvollen Erkenntnissen führt. Das Prototyping erspart einem zwar keine Irrwege, aber diese Irrwege können zeitlich in viel kürzerer Zeit bewältigt werden als bei einer direkten Implementierung in der Zielsprache (hier meist C++). Jeder Irrweg fördert auch das Verständnis des Problems. Deswegen ist es von Vorteil, wenn in gegebener Zeit möglichst viele davon beschritten können. Danach sind zwar nicht alle, aber doch die meisten Unsicherheiten ausgeräumt, was die Erstellung eines detaillierten Projektplans erleichtert, der dann i.Allg. auch sehr viel besser einhaltbar ist als ohne (oder mit nur eingeschränkter) Prototyping-Phase. Die Umsetzung der Python-Prototypen in C++ ist ein weitgehend mechanischer Prozess, da es für die meisten Python-Datentypen und Kontrollstrukturen C++-Äquivalente gibt (C++ hat sich diesbezüglich in den letzten Jahren stark weiterentwickelt). Die Implementierung der nicht prototypisierten Teile verläuft meist ebenfalls ziemlich geradlinig, da bei diesen die Art und Weise der Umsetzung ja schon vorab kaum mit Unsicherheiten behaftet war. Da stellt sich natürlich die Frage, warum man überhaupt noch eine C++-Implementierung macht und nicht gleich das Python-Programm verkauft. Gründe dafür können sein: - Python-Code erleichtert – verglichen mit kompiliertem C++-Code – das Reverse-Engineering, was bei kommerzieller Software ein großer Nachteil ist. - Die Ausführung des Python-Codes ist zu wenig performant. - Der C++-Compiler deckt manchmal Fehler oder Schlampereien auf, die in der Python-Implementierung unentdeckt bleiben. - Auf der Zielplattform ist Python nicht verfügbar. - Firmen- oder Kundenrichtlinien geben (oft ohne nachvollziehbare Begründung) die Implementierung in einer bestimmten Sprache vor.
:
Bearbeitet durch Moderator
A. S. schrieb: > Niemand glaubt heute, dass zu beginn eines Projektes jemand die > Anforderungen aufnehmen kann Naja, könnte man schon. Nämlich genau dann, wenn sowohl auf Kundenseite als auch auf Seiten des Software-Lieferanten Leute sitzen, die wirklich Ahnung von der Sache haben und vernünftig beschreiben können was gebraucht wird. Insbesondere in größeren Firmen hat man aber auf Lieferantenseite Vertriebler oder Projektmanager, die keine Ahnung haben, schon gar nicht von Software. Und auf Kundenseite fehlt diese Ahnung ebenfalls oft, etwa wenn man zwar Software braucht (z.B. um eine Maschine anzusteuern), aber es dort in der Firma niemanden gibt der Software entwickelt. Es könnte allles so toll sein, wenn man einmal mit Profis arbeiten dürfte ;-)
Hi Wem sagst du das? Habe viele Jahre diese Versäumnisse an Anlagen aufgebügelt. Der Hammer war ein Lagerprogramm einer namhaften Firma, welches Bestandslisten nach Fachnummern sortiert ausgegeben hat. Der Grund, der beauftragende Ingenieur hat versäumt, im Pflichtenheft darauf hinzuweisen, das eine Sortierung nach Lagerartikel stattzufinden hat. Es war mein erstes Pascal-Programm, den Lagerbestand aus einer Sicherungsdiskette auszulesen und Sortierung nach Wunsch sowie verschiedene Suchfunktionen zu liefern. Dabei war nicht das Programm das Problem, sondern die eigenartige Ablage der Datensätze. Da ich das mehr oder weniger privat zu Hause gemacht habe, hat es fast 4 Wochen gedauert, bis es fertig war. Als es damals mit den Worten "sowas machen unsere Elektriker" der Firma bei ihrer Preisforderung für ein paar Anpassungen ihrer Software vorgeführt würde, gaben die kleinlaut zu, das natürlich eine Sortierung nach Artikel im Programm vorhanden, aber aufgrund des fehlenden Eintrags im Pflichtenheft nicht freigeschaltet war. Aber das ist schon laaaaange her. Gruß oldmax
Martin V. schrieb: > aber > aufgrund des fehlenden Eintrags im Pflichtenheft nicht freigeschaltet > war. Das mache ich sogar heute noch GENAU SO. Der Grund ist ganz einfach. Die Funktion ist mit wenig Aufwand zu integrieren, wenn man sich von vorne herein darauf einstellt, das sie verlangt wird. Dann wird einfach der Button "ausgeblendet" und das war's. Irgendwann bei den Präsentationen fällt irgend einen ein, das sie die Funktion brauchen. Dann verweise ich auf das Pflichtenheft, den sehr großen Aufwand und je nachdem wie sympathisch mir die Leute sind, und wie sich mich behandelt haben, setzt ich dann ein Nachschlags-Preis fest. Und wenn die auch mal mir ein Fehler verzeihen dann gibt es sie sogar gratis. Ein guter Programmierer sieht immer zu, das er im Voraus denkt und weiß was der Kunde will. Er macht Vorschläge beim Vorab Gespräch. ABER je arroganter der Auftragsgeber rüber kommt, je teurer wird es für ihn. Das sollten die Auftragsgeber sich merken. Ist vermutlich auch der Grund warum die aktuell berühmteste APP 20 Mio. gekostet hat, und jede Menge Bugs hat. ;) Nur ein Rat kann ich jeden Entwickler geben. Lasst euch das Design absegnen. Die Funktionen der Software sind nicht wichtig, aber das sie gut aussieht. Klingt bescheuert, ist aber bei mir 30 Jährige Erfahrung. Besonders bei den Leuten die was zu sagen haben, aber keine Ahnung von der Praxis.
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.