Druckbare Version
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.Zitat:
.. Du sagtest .. das verantwortliche Entwickler 1 bis 2 Tage vor Ort verbringen sollten .. ist aber eben kein Standard .. enorm hohen Aufwand ..
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äß.
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 ...Zitat:
Zitat von White_Fox
Man kann es ja so formulieren: Für die Entwickler ist es normal, dass sich die Dinge ändern. Insoweit ändert sich nichts. ;)
Für vernetzte Anwendungen wird das natürlich schon zur Herausforderung. Die langen Laufzeiten industrieller Anwendungen führen dazu, dass man die verwendeten Technologien mit Sorgfalt wählen muss. Wir haben Kunden, die unsere Industrie-PC Anwendungen über 10 bis 15 Jahre ohne Update betreiben. Nicht weil wir keine kompatiblen Updates anbieten würden, sondern weil sie das grundsätzlich nicht tun.
Mit dem Wissen Anwendungen eventuell so lange betreuen zu müssen, wird man aus Erfahrung natürlich recht konservativ in der Technologieauswahl. Aber wer weiß schon, ob Dinge die gerade hipp sind, z.B. Node.js, in zwölf Jahren auch noch so verbreitet sind.
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:
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)
Und ob das eine Herausforderung wird, auch die Frage der Zuständigkeit lässt sich heute noch garnicht so leicht klären.
Denn nach Inbetriebnahme einer komplett digitalisierten Anlage wird auch nicht unbedingt immer
ein IT oder Sicherheitsexperte zum Händchen halten vor Ort sein.
Und wehe die Module für die Du nicht unbedingt verantwortlich bist machen dann mal Probleme, sei es vor Ort
oder per Fernwartung, dann fängt der Spass und Fehlersuche ohne die Anlage samt IT Integration zu kennen erst richtig an.
Die Kunden IT wird in Zukunft aber so oder so eine deutlich wichtigere Rolle einnehmen müssen als heute,
und der Aussendienst wird neben dem Ingenieur auch IT Experten im Team haben, ganz ohne geht es nicht wirklich.
Hallo,
Es ändert sich, wie schon geschrieben, nichts grundsätzlich für einen Entwickler.Zitat:
Zitat von SPSAmeise
Wo sich etwas ändern muss, ist in den Ebenen über dem Entwickler!
Bei MS, in der Zeit als es von MS noch gar keine Updates gab, war es so, dass Billy der Überzeugung war, dass nur ganz junge Entwickler neue Ideen haben. Also wurden die meisten direkt ab UNI, oder sogar vor dem Abschluss, bei MS eingestellt.
Weiterhin hat Billy das Datum für die Veröffentlichung z.B. einer neuen Windows-Version festgelegt und dieser Termin musste eingehalten werden. Dabei war es egal ob der Entwickler noch eine Bugliste mit 100ten bekannten Bugs hatte oder nicht. Das Din musste zum Termin raus!
Vieles waren ganz doofe Anfänger-Fehler!
z.B. SASSER. Das Problem lag in der Automatisierungs-Schnittstelle. Per Definition wurden nur Meldungen mit maximal 4kB Grösse verwendet. Also nahm man das Datenpaket von der Ethernet-Schnittstelle und kopierte es in einen 4kB Buffer. Dabei wurde aber vergessen, dass Ethernet Pakete bis zu 64kB übertragen kann und hat die Paketgrösse von der Ethernet-Schnittstelle übernommen, aber nicht auf 4kB geprüft! Somit konnte man rund 60kB hinter den Buffer mit eigenen Daten, bzw. Code, überschreiben. Da diese Schnittstelle natürlich standardmässig freigeschaltet war, genügte es, Windows zu installieren und den PC mit dem Netzwerk zu verbinden.
Durch SASSER kam wenigstens MS so weit unter Druck, dass seither regelmässig Updates von MS ausgeliefert werden. Vorher war die Antwort auf Bugmeldungen: "Kaufen sie die neueste Version!". Wobei nicht garantiert wurde, dass der Bug da behoben ist.
Bei Win-95 gab es 5 verschiedene Versionen (95, 95A bis 95C, 95B gab es in zwei Versionen). Allerdings wurde dies nicht nach Aussen wirklich kommuniziert, kaufen konnte man nur Windows-95, was in der Schachtel war, war nicht wirklich ersichtlich.
Der Active-Desktop war auch so eine "geniale Idee". Dabei hat man über den ganzen Desktop noch eine HTML-Schicht gelegt, war eigentlich ein durchsichtiges Fenster des IE. Um Dinge automatisieren zu können, hat man dann HTML einfach erweitert, sodass man auch vollen Zugriff auf die Festplatten hatte und Programme starten konnte. Leider war das dann ALLES auch über Web-Seiten möglich!
Ähnliches geschah auch mit dem lizensierten Java. Die MS-Variante wurde so erweitert, bis die Sicherheit ganz im Keller war und MS die Lizenz verloren hat.
Windows NT sollte der damals sicherste Kernel werden, dazu hat man einen Entwickler von auswärts geholt. Eigentlich wurde dieses Ziel auch erreicht, bis dann die MS-Programmierer direkte Zugriffe auf den Kernel gemacht haben und somit die Sicherheit umgangen wurde. Der extra geholte Entwickler warf daraufhin das Handtuch und verliess MS.
Das Problem ist, dass heute die Entwicklung nichts kosten darf.
Also macht das möglichst ein Praktikant, welcher keine Ahnung hat. Und wenn es in etwa das macht, was es soll, wird es freigegeben. Irgendwelche Tests würden zusätzliche Kosten verursachen und vor allem Zeit beanspruchen. So kommt es halt, dass der ganze PC bei einem Tippfehler abstürzt.
Stichwort: Bananaware, das Produkt reift beim Kunden.
Vor allem die Amis schaffen es bis heute nicht, mit Umlauten umzugehen. Teilweise klemmt es schon auf der Webseite. Teilweise stimmt alles auf der Webseite, aber wenn ich Post oder eMail bekomme ...
(Zum Glück habe ich nur einen Umlaut im Nachnamen)
Die Jeep-Geschichte funktionierte über die Bluetooth-Schnittstelle der Reifensensoren. Für mich ist das ein Anfängerfehler im Konzept, wenn man über diese Schnittstelle vollen Zugriff auf den CAN-Bus und somit auf alles im Fahrzeug erhält. Ein kleines Filter, welches nur die bekannten Meldungen der Reifensensoren weiterleitet, hätte da genügt! Im Prinzip kann ein defekter Reifensensor, welcher zufällige Daten versendet, die ganze Kiste lahmlegen oder auch Vollgas geben!
Jeder Entwickler macht seine Fehler, das ist normal. Viele dieser Fehler macht man aber nur einmal im Berufsleben, dann weiss man es, das nennt man Erfahrung. Ein weiterer Punkt ist noch, ob so ein Fehler in die Produktion geht oder schon vorher, z.B. durch Tests, erkannt wird.
Für einen guten Entwickler ändert sich nichts grundlegendes!
Manche müssen lernen, nicht nur an Funktion ihres Produkts zu denken, sondern auch ein Augenmerk auf das Fehlverhalten zu werfen.
Zudem muss er Zeit für Tests einplanen.
Grundsätzlich müssen die Prozesse dahin geändert werden, dass, nicht nur auf dem Papier, mehr getestet und geprüft wird und man sich nicht einfach auf die Anderen verlässt.
Meine Erfahrung mit ISO 900x war anfänglich, dass die Qualität schlechter wurde, obwohl ISO eigentlich eine Verbesserung bringen sollte.
Aus meiner Sicht war hier das Problem, dass beim Hersteller eine Ausgangs- und beim Empfänger eine Eingangskontrolle vorgeschrieben wurde. Da dachte sich jeder, dass er sich das sparen kann, weil ja der Andere schon kontrolliert, schlussendlich wurde dann gar nicht kontrolliert :-(
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo,
Das kenne ich auch so!Zitat:
Zitat von Mxt
In den 80/90er Jahren, wollten einige Auftraggeber, dass ich fertige Interface-Steckkarten verwende. Da war dann das Problem, dass wenn der PC ausgefallen ist, die neuen keine ISA oder EISA Steckplätze mehr hatten. Kompatible Steckkarten, mit den neuen Bussen, gab es dann auch nicht mehr. Also musste man die Software komplett neu erstellen und die Kostenersparnis war dahin ...
Selbst entwickelte Hardware konnte man reparieren.
Später habe ich dann eigene Hardware nur noch über serielle Schnittstellen an den PC angebunden, dieses Konzept funktioniert heute noch :-)
Das mit den Updates ist auch immer so eine Sache.
Wenn es keine grundlegenden Fehler gibt und keine benötigten neuen Funktionen geboten werden, macht ein Update keine Not.
Ich habe das bei Freunden erlebt, welche immer der neuesten Version nachgerannt sind!
Die waren eigentlich immer nur am lernen und sind laufend über neue Bugs gestolpert und kamen somit gar nie richtig dazu produktiv zu arbeiten.
Wenn man länger mit einer Version arbeitet, kennt man auch die Bugs und wie man sie umgehen kann, erlebt also weniger Überraschungen, welche einem beim Arbeiten unerwartet aufhalten.
MfG Peter(TOO)
Von welchen Entwicklern reden wir denn jetzt?
Die meisten sind spezialisiert auf Web, Datenbanken oder sonst irgendwas.
Es gibt aber nur wenige, die sich mit komplexen Backends und Security Layern und IoT Architektur auskennen.
Von DLTS Layern auf Bankenniveau mal ganz zu schweigen.
Hallo,
Leider ist das vor allem in KMUs oft so. Da ist einer aus dem Büro, welcher zu Hause hobbymässig ein bisschen programmieren kann, für die IT zuständig.Zitat:
Zitat von SPSAmeise
Zur Katastrophe wird es aber erst, wenn z.B. der Server explodiert und keine aktuellen Backups vorhanden sind ....
Bei Fremdmodulen ist das erste Problem, dass jeder die Schuld einem anderen zuschiebt, was der Problemlösung nicht dient!
Die IT-Experten im Aussenteam, sind auch nicht wirklich die Lösung. Wenn da mehrere Köche im Kunden-Netzwerk rumfummeln, funktioniert dieses auch nie wirklich!
Funktionieren kann es nur, wenn der Kunde EINEN Fachmann für die IT hat, welcher aber auch alles dokumentiert.
Wenn ich mein Gerät an ein Firmennetzwerk anbinden will, muss ich wissen wie dieses Netzwerk aufgebaut und geschützt ist. Nur mit dem Einstecken des RJ-45 ist es nicht getan. Bei einem gut geschützten Netzwerk muss man sich auch ins richtige Netzsegment hängen und Protokolle und Routen freischalten.
Dazu brauche ich jemanden, der sich mit dem konkreten Netzwerk(-Konzept) auskennt oder eine detaillierte aktuelle Dokumentation.
Hier wird sich noch einiges bewegen müssen!
Das ist auch der grundsätzliche Unterschied ob ein Konzept auf eine White- oder Black-List basiert.
Die Black-List ist einfach zu Handhaben, hinkt aber einer Bedrohung immer hinterher, bzw. kommt oft zu spät!
Eine White-List bietet maximale Sicherheit, macht aber Arbeit und Plug and Play ist auch nicht!
Leider hat die Werbung, besonders mit "Plug and Play" die Denkweise der meisten versaut.
Und die meisten PC-Zeitschriften legen mit ihren Produkt-Bewertungen noch nach. Wenn "Plug and Play" nicht funktioniert, dann gibt es schlechte Bewertungen.
Jeder der sich mit der Technik auskennt weiss aber, dass "Plug and Play" nur funktioniert, wenn alle Scheunentore Sperrangel weit offen sind :-(
Wie sag ich's meinem Kunden ?????
MfG Peter(TOO)