ist sie Standard? Muss ich sie beim Programmierer explizit fordern, oder ist eine Prüfung auf plausibilität selbstverständlich? Grund der Frage ist, dass wir einen Entwickler haben, dem so ziemlich alles 'am Arsch vorbei geht'. Einige Beispiele: - Er lässt es zu, dass sich ein einzig verfügbarer 'Admin' die Rechte wegnimmt, und dann keinen Zugriff mehr auf die Steuerung hat. - Die in dem System verbauten Temperatursensoren kann man justieren, egal ob sie nicht angeschlossen sind, oder einen Kurzschluss haben, die Steuerung zeigt dann statisch den Wert an, der bei der Justierung eingegeben wurde. Wird so die Heizung eingeschlatet (Sollwert höher als der 'Messwert'), brennt ihre Übertemperatursicherung durch. - Die Drehzahlregelung dreht voll auf wenn der Drehgeber keine Signale liefert, Motoren laufen dann mit max. Drehzahl. - Bei Firmwareupdate prüft er nur, ob die Daten richtig im µC angekommen sind, und nicht, ob dieser die Daten auch korrekt im Flash gespeichert hat. Ist dies alles jetzt des Programmierers Fehler, oder kann er sagen, dass davon nichts in einem Pflichten- oder Lastenheft stand. Für mich wäre eine solche Kontrolle selbstverständlich, habe das während meiner Auabildung, bei der Programmierung einer SPS, auch immer so gut wie möglich umgesetzt. Was denkt Ihr dazu? michel
Nabend, Michel schrieb: > Ist dies alles jetzt des Programmierers Fehler, oder kann er sagen, dass > davon nichts in einem Pflichten- oder Lastenheft stand. kommt auf die Anwendung an. Bastelei oder Kommerziell. Bei letzerem steht sein Arbeitgeber (kann er auch selbst sein) mit einem Bein im Knast. Regressforderungen wegen Produktionsausfall, durch mangelnde Sorgfalt bei der Umsetzung (Entwicklung), sind nicht zu unterschätzen. MfG
Hallo Joachim, der Entwickler ist selbstständig, und es ist kommerziell. Aufgrund seiner 'Qualität' bekommt er schon keine neuen Projekte mehr, und die, die er noch hat, werden durch Neuentwicklungen ersetzt werden. Das dauert aber noch einige Zeit. Wir haben Ihn schon mehrfach aufgefordert sich etwas einfallen zu lassen, aber das hätten wir uns sparen können, da kann man auch ne Kuh ins Horn petzen. michel
Michel schrieb: > Ist dies alles jetzt des Programmierers Fehler, oder kann er sagen, dass > davon nichts in einem Pflichten- oder Lastenheft stand. Ein Pflichtenheft sollte alle wichtigen Anforderungen beinhalten. Wenn etwas Wichtiges nicht drin steht, ist das schlecht. Dann kann man es sich ja ganz sparen. Es reicht ja schon eine ganz formale Nennung: "Eine Fehlererkennung und Behandlung ist zu implementieren". Wenn dann Unklarheiten zum Umfang bestehen, dann muß er eben fragen, ob man was weglassen kann. Man muß ihn sozusagen mit dem Pflichtenheft in die Pflicht nehmen. Peter
Wenn es die Anforderungen nicht gab (Pflichtenheft), kann man eigentlich keinen direkten Vorwurf machen. Sicher, über manche Sachen sollte er sich auch selbst Gedanken machen - aber das kann auch in die Hose gehen. Er kann sich ja was ganz anderes dabei denken, als du jetzt meinst, wie es logisch wäre. Es gibt nur wenige Möglichkeiten, solch ein Dilemma zu lösen: 1. komplettes Pflichtenheft (ist mir in der Praxis noch nie begegnet, vielleicht gibt es das in der Luft/Raumfahrt. Falls es das gibt, steckt eine gigantische Arbeit darin, mehr als die zu entwickelnde Software selbst) 2. ein unabhängiger Dritter prüft die Sache, völlig unvoreingenommen. Widersprüche, wenig sinnvolles Verhalten wird ausgemerzt (dabei auch direkt ins Pflichtenheft übernommen) 3. miteinander reden, wenn irgendwas nicht ganz klar ist und/oder Entscheidungsspielraum vorhanden ist Bei mir ist eine Softwareentwicklung eigentlich immer ein rantasten an das Endprodukt. Die Auftraggeber haben oft nur eine grobe Vorstellung, an die 1000 kleinen Dinge denkt erstmal keiner -> alles ist im Fluss.
Formal gesehen sollte sowas im Pflichtenheft drinnenstehen. Allerdings kommts IMO in der Realität auch auf die Einbindung der externen Entwicklung an. Wenn das nur einer ist und der auch noch quasi vor-ort und nicht in Indien sitzt, hat das ja wohl auch den Grund, den formalen Teil zugunsten einer effizienten Arbeitsweise zurückzufahren. Jegliche Unklarheiten oder Fragen könnten ja dann schnell per Telefon/Email gelöst werden. Dazu gehört natürlich auch ein bisschen das Mitdenken... Wenn das nicht passiert, kann man den Job auch gleich nach Indien geben ;)
Formal muss das natürlich im Pflichtenheft drinstehen. Denn dass ein Motor bei fehlenden Drehgebersignalen stehenbleiben soll, ist ja keineswegs selbstverständlich, man könnte ja auch einen anderen "sicheren" Zustand wollen. Andererseits muss sich natürlich jeder Entwickler, das daraufhin nicht wenigstens mal nachfragt, fragen lassen müssen, was ihn von einem beliebigen Auftragsentwickler in Indien unterscheidet und warum man ihm mehr Geld zahlen soll. Gruss Axel
> Wenn es die Anforderungen nicht gab (Pflichtenheft), kann > man eigentlich keinen direkten Vorwurf machen. Naja, gewisse Dinge sollten als Selbstverständlichkeit angesehen werden, à la "good engineering practices", oder einfach Ingenieurshandwerk. Aber das ist bei Softwareentwicklung ein Minenfeld ...
Ist nicht die ganze Softwareentwicklung ein Mineneld? Macht der Programmierer z.B. eine Drehzalkontrolle rein und setzt wegen fehlender Vorgaben die Grenzen falsch, dann hatte er Arbeit und zudem noch den Ärger mit den falschen Abschaltungen. Tut er es nicht, hat er nur den Ärger...
In vielen Firmen ist es heutzutage leider sogar gefordert, den Fokus auf die Termine zu legen und nicht auf die Qualität, so wie das früher der Fall war. Also lieber einen Monat früher fertig sein als alle Eventualitäten zu testen und Fehler zu korrigieren. Das scheint also so im Trend zu sein und Dein Kollege macht es so gesehen richtig. Persönlich teile ich aber auch Deine Meinung, dass der Programmieren ein wenig mitdenken sollte und gewisse Dinge abfangen die "gefährlich" sind. Aber wen interessiert schon unsere Meinung...
Hängt natürlich etwas von Kundschaft und Unternehmensziel ab. Wenn man gut damit leben kann, einen Kunden nie wiederzusehen, es sei denn vor Gericht, dann ist eine Vorgehensweise "Dienst nach Vorschrift" der richtige Ansatz. Ein gewisser "Schlupf" zur Wahrung möglicher teurer Folgeaufträge ist freilich gängige Praxis. Aber man sollte es dabei nicht übertreiben.
> und gewisse Dinge abfangen die "gefährlich" sind.
Soweit würde ich noch gar nicht gehen, dass da schon Arbeit reingesteckt
wird, ohne genau zu wissen, ob das überhaupt ein reales Problem ist.
Aber Nachfragen sollte man schon, es kann ja auch durchaus Fälle geben,
an die der Auftraggeber auch noch nicht gedacht hat und die evtl. ein
etwas grösseres Redesign nötig machen...
das kommt meiner Meinung nach von der Entkopplung der Entwicklung von der Praxis. Der Praktiker, der an der Maschine steht weiß, es kommt zu Ausfällen und dann muss die Maschine irgendwie reagieren. Der Softwareentwickler entwickelt mMn quasi eine Black Box ... irgendwas geht rein, irgendwas geht raus. Es ist auch nicht seine Aufgabe alle Eventualitäten nachzufragen, das ist Aufgabe des Auftraggebers zu beschreiben welche Fehlerfälle wie behandelt werden müssen. Hinterher kommen und dies und jenes muss so oder anders laufen ist immer schön. Kenn das auch, vage Funktionsbeschreibung ewiges herumklabustern an irgendwelchen Nebenkriegsschauplätzen und dann huch, in zwei Wochen ist Deadline, jetzt aber schnell und perfekt. Hinterher stellt sich der Kunde hin ... und das haben sie nicht berücksichtigt und das der Sensor ausfallen kann, dass müssen sie sich doch denken und das das Ventil dann auf statt zu gehen muss ist ja wohl logisch und überhaupt, warum wurde die Funktion über die wir überhaupt nicht gesprochen haben von Ihnen nicht einfach als Feature implementiert ohne Aufpreis versteht sich, wenn wir die nicht brauchten hätten wir die immernoch rauswerfen können. Hab grad sowas bei Hardwareentwicklung ... hab schon Reserven eindesignt, extra Schaltausgänge, extra AD-Eingangänge, extra Digitalausgänge, jetzt ist Deadline, alle Reserven sind im Einsatz und der Kunde hätt gern noch mehr dazu, obwohl die nie gefordert waren, aber huch, da könnten wir ja auch noch x und y und z dazuhängen .... grrrrr
Beispiel Auto - Tempomat: musste da explizit darauf hingewiesen werden, dass eine 'plausieble Geschwindigkeit' ermittelt wird bevor er diese konstant hält? Betätigung der Bremse o. Kupplung --> Tempomat = Aus, keine Signale vom 'Tachogenerator' = Tempomat Aus, oder gar nicht erst An???? Haha, ich bin von diesem Entwickler mittlerweile so dermaßen überzeugt, dass es Ihm schwer fallen wird mich zu enttäuschen. Er hat mir mal erzählt, dass er 'ne neue Steuerung mit nem ARM' machen will, als ich fragte: 'warum nicht eine mit zwei Beinen?' hat's ne Weile gedauert, und er lachte (tolles Wortspiel? - oder hab ich ihn damit zu arg getroffen?). Befürchte, dass das Ganze mit einer gewissen Anspruchslosigkeit zu tun hat, die mit meinem Denken auf Konfrontationskurs liegt. Hinweise werden dementiert, und Ideen als Bestandslos gewertet. Der (unser) Entwickler braucht wohl keinen Kunden, das was Er macht ist gut, und wenn wir damit nicht zufrieden sind, suchen wir nen anderen..... Ihm ist dies wohl egal.
Was ist eigentlich dein Problem? Bist du verheiratet mit dem Entwickler, dass du da derart viel Emotion reinbringst? Michael B. schrieb: > musste da explizit darauf hingewiesen werden Wenn man etwas fordert (gerade im Sicherheitskritischem Bereich) dann gehört das in die Anforderungen, fertig! Man verlässt sich bei so was doch nicht darauf das doch "schon klar ist" was da passieren soll, und wenn ja dann ist das ein Versäumnis des Auftraggebers.
Läubi .. schrieb: > Was ist eigentlich dein Problem? Bist du verheiratet mit dem Entwickler, > dass du da derart viel Emotion reinbringst? äääh? Nun gut, meine Ansprüche und Erwartungen sind zu hoch, hab ich mal wieder vergessen. Probier demnächst mal Mittelmäßigkeit und Ignoranz zu üben. Gut braucht eh nix sein, es muss halt nur so irgendwie funktionieren. Werd aber mal nachschauen was in den Anforderungen steht.
Michel C. schrieb: > Läubi .. schrieb: >> Was ist eigentlich dein Problem? Bist du verheiratet mit dem Entwickler, >> dass du da derart viel Emotion reinbringst? > äääh? > Nun gut, meine Ansprüche und Erwartungen sind zu hoch, hab ich mal > wieder vergessen. Das ist ja nicht das Problem. Aber wenn ihr ihm ohnehin keine Aufträge mehr zuschanzt, dann bist du ihn ja sowieso bald los.
Läubi .. schrieb: > Wenn man etwas fordert (gerade im Sicherheitskritischem Bereich) dann > gehört das in die Anforderungen Bzw. umgekehrt, was nicht in der Liste steht, kann auch nicht abgehakt werden. Wenn eh jeder alles im Kopf hätte, bräuchten z.B. Piloten ja keine Checklisten. Würdest Du mit einem Piloten fliegen, der keine Checkliste abarbeitet? Der Entwickler hat in erster Linie das abzuarbeiten, was als Anforderung dokumentiert ist. Läuft eine Entwicklung nur auf Zuruf, dann läuft gewaltig was schief. Peter
Eigentlich müßte man diesem Entwickler doch dankbar sein. Er deckt ja damit die Mängel auf, die bei der Erstellung der Spezifikation immer noch bestehen. Peter
Peter Dannegger schrieb: > Eigentlich müßte man diesem Entwickler doch dankbar sein. > Er deckt ja damit die Mängel auf, die bei der Erstellung der > Spezifikation immer noch bestehen. > > Peter Ok Peter, von der Warte gesehen... Er deckt die Mängel aber nicht direkt auf, sondern nur mit Hilfe der Querulanten, die sich nicht mit dem Ergebnis zufrieden stellen lassen. Ihm selbst hilft das nur wenig, da er nicht auf das Feedback eingeht. Uns hilft es sehr, sollten wir da geschlampt haben, Anforderungen beim nächsten Projekt besser zu formulieren. DANKE lieber Entwickler. 90% der Beteiligten sind solche Sachen egal, die machen Dienst nach Vorschrift, gehen den Weg des geringsten Widerstads, und bewirken keinen Fortschritt. Ich rege mich da halt gerne auf, und suche nach Ursache & Lösung. @ Pflichtenheft und sonst nix Unterstützer: werde es auch mal versuchen, gebe dann zwar meine Ideale auf, werde aber mit Sicherheit eine leichtere Zeit a.d. Arbeit haben, nur tun - nicht denken, nix erwarten. Muss Euch da Recht geben. Bekomme beim Autokauf ja auch keine Extras für umme. Nebenbei... Ich soll ne neue klassische Steuerung für ein Gerät mit Drehstrommotor basteln (u.a. Stern-Dreieck), Kunde will nur wenig Geld ausgeben, und hat nichts von Sicherheit gesagt. Umsetzung wird zwar nicht gut, aber billig: u.a. Schütze ohne Hilfskontakte -> somit keine Verriegelung möglich. Wenn's mal knallt, weil ein Schütz klebt, kassiere ich halt noch mal, für nen neuen Plan, das Material, und meine Arbeitszeit. is doch nicht verboten.... oder ;-)
Michel Cheron schrieb: > Uns hilft es sehr, sollten wir da geschlampt haben, Anforderungen beim > nächsten Projekt besser zu formulieren. DANKE lieber Entwickler. Schreibt in die nächste Aufgabe ein paar 'Standardsätze' rein, die darauf hinauslaufen, dass solche Sachen selbstverständlich sind. Eben auch mal was mit Plausibilitätskontrolle der Eingangswerte, Erkennen und Behandeln von Fehlersituationen. Immer schön schwammig bleiben und nicht konkret sagen, welche Werte, welche Standardaktionen, welche Fehleraktionen. Nur, das sie behandelt werden müssen und das nichts schlimmes passieren darf. Dann was passiert dann: Kommt es beim Kunden zu einer Fehlersituation, dann darf er das auf eigene Kappe, und was ganz wichtig ist: auf eigenes Geld, korrigieren. Dann hört sich das ganz schnell auf, wenn er 2 Tage nachbessern darf, die er nicht bezahlt bekommt. Das macht er ein, zwei mal, und irgendwann beginnt dann der Umdenkprozess, so dass man bei den ersten Besprechungen nicht nur die Standardfunkionalität betrachtet, sondern noch eine Stunde hinten nach einschiebt, in der man sich überlegt: und was kann da jetzt alles schief gehen. Das man mal was vergisst, brauchen wir nicht diskutieren. Natürlich tut man das. Und natürlich übersieht man auch mal was. Die Frage ist nur: wie naheliegend wäre die Betrachtung dieser Fehlersituation eigentlich gewesen. Und wenn er das nicht lernen will, das sich ein Profi auch um solche Dinge Gedanken machen MUSS, dann gehts nur übers Geld. Denn beim Geld hört sich jede Freundschaft auf. Von einem Profi erwarte ich, dass er State-of-the-art arbeitet. Und dazu gehört selbstverständlich auch Fehlerbehandlung.
Auch eine Fehlerbehandlung kann man nicht einfach ohne Auftrag hinzufügen. Es muß ja geklärt werden, wie bei welchem Fehler zu reagieren ist (Retry, Ignore, Anzeige, Tonsignal, Speichern, Neustart, Abschalten usw.). Es bleibt natürlich oft nur ein Wunschdenken, eine ausreichende Spezifikation zu erhalten. Wenn der Kunde dazu nicht bereit oder in der Lage ist, dann muß man eben zusätzliche Entwicklungszeit in Rechnung stellen, um eine wischi-waschi Spezifikation in eine verwendbare und belastbare überzuführen. Und die muß dann der Kunde unterschreiben, ehe man mit der Entwicklung beginnt. Den Idealzustand, daß nach Erhalt der Spezifikation das Gerät entwickelt werden kann, ohne erneuten Kundenkontakt, wird man nur selten erreichen. Aber das ist kein Grund, es nicht wenigstens zu versuchen, diesen anzunähern. Peter
> Auch eine Fehlerbehandlung kann man nicht einfach ohne Auftrag > hinzufügen. Es muß ja geklärt werden, wie bei welchem Fehler zu > reagieren ist (Retry, Ignore, Anzeige, Tonsignal, Speichern, Neustart, > Abschalten usw.). Yep. Allerdings denken die wenigsten Kunden bei den Gesprächen an solche Sachen. Die interessiert vorrangig normalerweise nur die einwandfreie Funktion im Nicht-Störfall. Daher muss man als Entwickler selber soweit sein, daran zu denken und im Zweifelsfall nachzufragen. Und es ist mir mehr als einmal passiert, dass ich mit solchen Nachfragen in der Firma des Kunden etwas losgetreten habe. Der Mann, mit dem man sich unterhält sagt: "Dieses Problem kommt bei uns nicht vor". Aus Erfahrung weißt du als Entwickler "Oha, 'kommt bei uns nicht vor' ist ein Alarmsignal - nachbohren". Dann bohrst du und bohrst, bis es dem Mann zu blöd wird "Fragen wir halt sicherheitshalber mal in der Werkstatt nach". Dann lässt er den Mann von der Maschine antanzen ... selbe Frage ... und der erzählt dann plötzlich ganz was anderes :-) Langer Rede kurzer Sinn: Als SW-Entwickler musst du mitdenken. Und du musst auch für den Kunden mitdenken. Alles andere führt unweigerlich ins Fiasko. Und sei es nur, das hinterher gestritten wird, wer worauf vergessen hat und vor allen Dingen: Wer zahlt jetzt die Korrektur?
Karl Heinz Buchegger schrieb: > Schreibt in die nächste Aufgabe ein paar 'Standardsätze' rein, die > darauf hinauslaufen, dass solche Sachen selbstverständlich sind. Eben > auch mal was mit Plausibilitätskontrolle der Eingangswerte, Erkennen und > Behandeln von Fehlersituationen. was soll das bewirken? > Immer schön schwammig bleiben und nicht > konkret sagen, welche Werte, welche Standardaktionen, welche > Fehleraktionen. Nur, das sie behandelt werden müssen und das nichts > schlimmes passieren darf. Bs hierhin dacht eich das soll Ironie sein, aber irgendwie passt der Rest des Beitrags nicht dazu. Wie soll man sowas denn implementieren, wenn die Werte nicht spezifiziert werden. Solche Anforderungen würde ich solange mit "to be clarified" oder "not testable" zurückgehen lassen, bis sie testbar beschrieben sind.
Vlad Tepesch schrieb: > Wie soll man sowas denn implementieren, wenn die Werte nicht > spezifiziert werden. Solche Anforderungen würde ich solange mit "to be > clarified" oder "not testable" zurückgehen lassen, bis sie testbar > beschrieben sind. Du hast erkannt, worauf das ganze hinausläuft! (Auch wenn du es nicht gemerkt hast). Genau darum geht es, dass du den Typen zwingst "die Spezifikation zu durchdenken und die Anforderungen zu überdenken und im Zweifel auch mal zurückgehen zu lassen", solange bis er begriffen hat, dass er mit seiner Minimallösung (hinter mir die Sintflut) allen, inklusive sich selbst, nichts gutes tut. Entweder er lernt das oder es kostet ihn #sein# Geld. Es wird immer wieder vorkommen, dass irgendwas nicht in den Pflichten/Lastenheften steht. Da muss man dann als Entwickler soweit sein, dass man auch mal beim Auftraggeber anruft und sagt: "OK, ich hab jetzt die Motorregelung soweit fertig. Was soll eigentlich passieren, wenn der Sensor ausfällt? Welchen Wert liefert er dann und was machen wir mit der Regelung?". Klar im Idealfall steht das so in den Papieren drinnen. Und wenn nicht, dann kann es nicht sein, dass ein Profi (also jemand, der seine Brötchen mit SW-Entw. verdient) da einfach stillschweigend nichts tut, sondern er muss das mit dem Auftraggeber abklären. Und zwar von sich aus.
Vlad Tepesch schrieb: > Wie soll man sowas denn implementieren, wenn die Werte nicht > spezifiziert werden. Macht er die Harware selbst, muss er z.B. Opamps und Sensoren den Anforderungen entsprechend auswählen und dimensionieren, damit weiß er auch, wann was zu erwarten ist (Kennlinie / Messbereich i.e. 12 bis 65Grad), und kann dies in der SW berücksichtigen. Sollwerte werden begrenzt (i.e. 25.0 - 45.0 Grad), Justierungen nur in einem bestimmten Bereich zugelassen (in dem von mir angesprochenen Fall aber nur im Bezug auf den eingebbaren Referenzwert), dann ist es doch mit Sicherheit kein Problem festzustellen, daß einer der Sensoren außerhalb des erwarteten Bereichs liegt, weil nicht angeschlossen oder defekt? Spezifiziert ist genug?
Michel Cheron schrieb: > Spezifiziert ist genug? Spezifiziert ist nie genug! Aber die Idee des "Steht alles in der Spec" ist genauso eine Illusion, wie die Illusion eines fehlerfreien Programms :-) Und wer das nicht begreift und statt dessen mit der sprichwörtlichen Beamtenmentalität an den Job herangeht, ist im falschen Job gelandet. (meine persönliche Sicht der Dinge)
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.