Also ich kenn das auch nicht als Standard. Standard sind eher ein bis zwei Wochen, teils mehr - soweit ich das von den mir bekannten Softwareentwicklern kenne. Ist aber bei Maschinen etc oft auch der Fall. Leider eben (schon wieder standardmässig) NACH SAT statt vor Pflichten-/Lastenheft. Murphy lässt grüßen... Du sagtest .. das verantwortliche Entwickler 1 bis 2 Tage vor Ort verbringen sollten .. ist aber eben kein Standard .. enorm hohen Aufwand ..
Ciao sagt der JoeamBerg
Das hängt in der Tat stark von der Lösung ab, denn wenn der Entwickler 2 Wochen braucht nur um sich mit den Abläufen vertraut zu machen, zweifelt ein Kunde wohl eher an der Planung des Dienstleisters
und weniger an der Servicequalität. Teuer und aufwendig bleibt beides , daher sind individuelle Einzellösungen in geschlossenen Systemen auch nicht mehr ganz Zeitgemäß.
Hallo,
Ist halt immer auch eine Frage, ein wie helles Kerlchen der Entwickler ist und was er über die Branche und deren Abläufe weiss! Dazu gehört aber auch die jeweilige Fachsprache. Wenn ich mit einem Textilfärber über Farbmetrik rede ist das eine andere Sprache als mit einem Offset-Drucker.Zitat von oberallgeier
Als die SBB auf Computern bei den Ticketschaltern umgestellt hat, haben sie erst einmal 1 oder 2 Schalter in Bern mit Prototypen ausgerüstet, dann haben einige normale SBB-Ticketverkäufer an diesen Schaltern gearbeitet und ihren Senf dazu abgegeben. Anschliessend wurde das ganze System nochmals überarbeitet.
Den unterschied merkt man, wenn man ein Ticket bei der DB und der SBB am Schalter holt. Am DB-Schalter dauert es ewig ...
Ein Problem ist, dass Pflichten-/Lastenheft fast immer von Leuten erstellt werden, welche mit dem Ergebnis nicht selbst arbeiten müssen!
Hinzu kommt noch, dass sie, oft ohne das nötige Fachwissen, mitdenken. Da werden dann Wünsche ausgeschlossen, weil man denkt es sei zu teuer oder man mal von Problemen gehört hat, oft weil das dann später nachgerüstet werden musste.
Ich habe meine Kunden immer angewiesen das Pflichten-/Lastenheft zuerst dreiteilig zu erstellen:
1. Alles was das Produkt können muss.
2. Dinge die hübsch wären, wenn man sie hat.
3. Hyper-Super-Duper Features.
Im nächsten Schritt hat man dann über die Machbarkeit und Kosten der einzelnen Ideen gesprochen und ein definitives Pflichten-/Lastenheft erstellt.
Oft sind da Dinge von 3. in 1. gerutscht, besonders früher, als noch viel Hardware war. Irgendeine zusätzlich LED macht bei der Entwicklung keine zusätzlichen Kosten, ausser den paar Cent für LED und Widerstand. Wenn man aber das Layout des Prototypen neu entflechten muss, ist es ein Kostenpunkt.
Hinzu kam, dass man auch nur die Löcher für einen zusätzlichen Stecker vorgesehen hat, um später Features nachrüsten zu können, auf Grund der Kategorie 3. konnte man abschätzen wohin die Weiterentwicklungen gehen wird.
Grundsätzlich gilt dies auch für Softwarelösungen. Da kann man einen µC wählen, zu welchem es einen pinkompatiblen grossen Bruder gibt. Oft liegt der Unterschied nur in einem Pull Down oder Up Widerstand, was keine zusätzlichen Kosten erzeugt.
Dies gilt aber auch, wenn man die Hardware fertig zukauft. Bei der Evaluation stolpert man meist über viele, fast identische Produkte. Wenn es mit kleinem Aufwand möglich war, habe ich immer versucht, dass man auch andere Module, ohne Aufwand, verbauen kann. Das hat uns öfters "das Leben gerettet", wenn ein Hersteller nicht liefern konnte oder sein Produkt eingestellt hat. Oder aber, wenn neue Anforderungen an ein bestehendes Gerät gestellt wurden.
Ähnliches gilt auch für die Software. Wenn spätere Erweiterungen schon bekannt sind, kann man die Software von Anfang an, entsprechend modularisieren und/oder Software-Schnittstellen vorsehen. Ähnliches gilt z.B. auch für Timer, heutige µCs besitzen meistens jede Menge davon. Einen einfachen periodischen Interrupt kann ich mit jedem von diesen Erzeugen. Aber einzelne Timer können noch spezielle Aufgaben erfüllen, wie z.B. PWM oder Quadraturdekoder. Für eine einfache spätere Erweiterung, belegt man diese speziellen Timer möglichst nicht. Ähnliches gilt auch für die I/O-Pins.
Aber das ist meine Denkweise und die meisten Entwickler denken leider anders.
Ich habe einige meiner Brötchen damit verdient, indem ich Projekte "geerbt" habe. Entweder weil die Entwickler nicht weiter kamen oder weil das Produkt erweitert werden sollte.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Wenn ich nochmal an die Eingangsfrage des TEs erinnern darf:
Es ging darum, was es für Entwickler Neues gibt. Neue Technologien, neue Entwicklungsmöglichkeiten, usw....
Ich bleib noch dabei, aus technischer Sicht wird sich für Entwickler und Ingenieure rein gar nichts bis wenig ändern. Es wird vielleicht ein paar neue Schnittstellen geben. (Auf der Embedded World in Nürnberg vor ein paar Wochen habe ich das LoRa-WAN bewundern dürfen. Funkübertragung für relativ geringe Datenmengen über beachtliche Entfernungen. Letztenendes Module, die über eine schnöde UART-Schnittstelle angesprochen werden.) Aber damit bleibt alles beim alten: Die Firmen, die neue Geräte/Technologien entwickeln, haben das schon seit Jahrzehnten gemacht und tun das weiter hin.
Wo sich eher vielmehr etwas ändern muß, ist die Organisation vieler Firmen, sowie die Zusammenarbeit zwischen den technischen, wirtschaftlichen und organisatorischen Abteilungen. Soweit ich das beurteilen kann liegt da die größte Quelle für Probleme aller Art.
Aufträge werden oft ausgeschrieben, d.h. in der Regel der, der am wenigsten Geld sehen will, kriegt den Job. Nun findet sich immer irgendeine Klitsche, die den größten Teil ungelernte Ahnungslose unterhält und vllt einen "Feignblatt-Meister oder -Ing" beschäftigt, der aber auch nur dort ist weil für irgendwelchen rechtlichen Kram jemand mit Titel gebraucht wird. Solche Buden gibts fast immer.
Momentan bin ich noch für eine Firma tätig (zwar nicht Industrie, aber die gleichen Mechanismen gibts überall) die am Markt einen riesig großen Namen hat, wo aber fast die gesamte Arbeit von Subunternehmen gemacht wird. Die Baustellenleiter sind während der gesamten Bauzeit nicht ein einziges Mal auf der Baustelle gewesen (wie auch, wenn einer Baustellen für drei alleine leiten soll), und kleinere Handwerkerbertriebe sind erstaunt wenn die Leiharbeiter in den Arbeitsklamotten mit dem Logo der superdollen Riesenfirma aus Dortmund zu ihnen kommen um sich grundlegene Werkzeuge auszuleihen.
Die Firma wickelt ihre Projektkalkulation mit einem Werkzeug ab, das definitiv noch aus der Mitte der 90er Jahre stammt, das letzte Update aber von 2016 ist. Über die Mängel dieser Software könnte ich Bücher schreiben, ich sollte in einem fast fertig kalkulierten Angebot die Verkaufssätze ändern. Ein Vorgang, der nur für jede Einzelposition individuell möglich ist. Für so etwas habe ich 20min "Klavier gespielt", diesen Vorgang könnte man aber auch in <10s erledigen wenn die Softwarebude gewußt hätte was sie tat. Der Einsatz solcher Programme wird für mich künftig ein Kriterium bei der Arbeitgeberwahl sein.
Diese Firma hat auch allerhand Zertifikate, für deren Ausstellung irgendein Mitarbeiter vor Jahren mal allerhand Formulare und Vorlagen in Excel erstellt hat. Diese Tabellen gammeln in den Tiefen des Servers rum und kein Mensch weiß davon oder nutzt die Dinger gar. Davon abgesehen nutzt die Firma allerhand Excel-Tabellen, wo das Firmenlogo aus vier Textblöcken mit verschiedenen Schriftarten irgendwie zusammengebastelt wurde. Dort, wo Zeichenketten eingetragen werden sollten, ist ein Riesenhaufen Spalten auf ca. Zeichenbreite zusammengeschrumpft worden. Vollkommen nutzlos, aber die Exceltabelle sieht an dieser Stelle immerhin wie ein Überweisungsschein aus. Dafür keinerlei Formeln, wo der Computer dem Menschen ein wenig Rechenarbeit abnehmen könnte. Die Firma rühmt sich übrigens der ständigen Fort- und Weiterbildung ihrer Mitarbeiter.
Ich habe für diese Firma eine Exceltabelle mit etwas Intelligenz vollgestopft, mir vom Standort-Manager dafür immer Sprüche angehört wie "Programmieren Sie denn noch oder verdienen Sie schon Geld?", bis dann ein Projekt massiv in Schieflage geraten ist. Der Standort-Manager war nur verwundert, daß sein Bauleiter immer aktuellere Zahlen hatte als er (dank meines Excelscripts), zumindest habe ich mir für speziell dieses Script keine dummen Sprüche anhören müssen. Beim nächsten Projekt ging es allerdings wieder los...
Über die Lohnzettel, die wirklich noch von jedem Mitarbeiter handschriftlich ausgefüllt (kostet jeden Mitarbeiter regelmäßig einen kompletten Arbeitstag im Monat-mindestens) und dann aus allen Standorten in Deutschland nach Dortmund gekarrt werden, habe ich mich bestimmt schonmal ausgelassen. Dafür wird jeder Mitarbeiter auf Vollgas gefahren, die "12h/d-Arbeitszeitausnahme" ist da eher die Regel. Die Mitarbeiterfluktuation entsprechend hoch.
Die Firma ist zwar eine Elektrofirma und im Bauwesen und nicht in der Industrie tätig, aber das sollte keine Rolle spielen, denn das sind alles Probleme, deren Ursachen völlig branchenunabhängig sind. Und solange es noch Firmen gibt die sich eine solche Arbeitsweise leisten können, wie auch immer die das schaffen, wird dieses "Industrie 4.0-Gedöns" mir als angehenden Ingenieur eher Alpträume bereiten. Denn sowas:
http://www.n-tv.de/auto/Hacker-ueber...e15575591.html
https://de.wikipedia.org/wiki/Michae...8Journalist%29
brauchen wir nicht noch mehr. Für den Ein oder Anderen, insb. Menschen mit wenig technischer Bildung wie Leute im Marketing- oder Wirtschaftsbereich, mag es ein Unterschied sein ob ich ein Auto oder eine Industrieanlage hacke. Als Technischer ist mir das völlig wurscht, lediglich die Möglichkeiten sind anders.
Dann ist es umso erstaunlicher, dass Du wirklich glaubst es würde sich durch Industrie 4.0 nichts für Entwickler ändern ...
Berechtigungen
Zitieren
Lesezeichen