Hallo zusammen,
ich bin in einem Unternehmen als QMB tätig, die Messgeräte entwickelt und produziert. Unter anderem wird für die Geräte Embedded Software entwickelt. Eine Prozessbeschreibung für die Softwareentwicklung gibt es, in der die Vorgehensweise beschrieben ist. Allerdings ist das alles auf dem Papier, weil die Inhalte nicht umgesetzt werden (Argument: keine Zeit) und es an Dokumentation fehlt. Die Softwareleute sperren sich gegen Pflichten- und Lastenhefte oder Softwareentwicklungsbücher. Dokumentiert wird, wenn überhaupt, in persönlichen Kladen.
Meine Frage ist, bis wohin bzw. was muss im Bereich der Softwareentwicklung dokumentiert werden? Was ist notwendig und was ist "nice to have"?
Danke und Gruss
Edda

Hallo Edda,
da ich nicht weiss, welche Forderungen für die Entwicklung generell und von Euren Kunden im
speziellen gefordert sind, kann ich nur mit meiner "Brille" einen Kommentar abgeben (Luftfahrtbereich).
Auch in unserem Bereich der Luffahrt versucht die Entwicklung immer wieder "hemdsärmlig" zu
arbeiten, wegen der "nicht vorhandenen Zeit".
Ich (Qualitätsingenieur in derEntwicklung) frage meine "Pappenheimer" dann jedesmal, welche Antworten sie denn dem Richter geben wollen.
Dessen Fragen können sein:
- Haben Sie nach Ihren Firmenprozessen gearbeitet?
- Können Sie dies auch dokumentiert nachweisen?
- Woher wussten Sie wie Sie die Software schreiben sollten (Pflichtenheft / Lastenheft / Entwicklungsstandard)?
- Haben Sie die durchgeführten Änderungen dokumentiert (Versionskontrolle -> Baustände / Sw-Versionen)?
- Warum haben Sie die Änderungen machen dürfen (Changemanagement -> Forderung)?
- Wurden die Änderungen verifiziert (Test)?
- Sind die Verifikationen dokumentiert?
Wird nun aufgrund negativer oder unvollständiger Antworten und Nachweise beim Richter der Eindruck
erweckt, es wurde nicht sauber gearbeitet (Richter ist kein Fachmann), hat der MITARBEITER
schlechte Karten und kann persönlich verantwortlich gemacht werden.
Dies steigert sich natürlich wenn Menschen zu Schaden kommen oder gar getötet werden.
Ich kann mir vorstellen, dass auch in Eurem Bereich durchaus kritische Anwendungsgebiete
existieren können.
Das war ein Aspekt.
Der zweite Aspekt liegt ganz klar im Managementinteresse.
- Firmenimage durch schlechte Produkte (wissen wir was wir tun?)
- Schnellstmögliche Schadensbegrenzung(Woher kam nur der Fehler? In welchen Gerätegenerationen vorhanden ?)
- Tun wir mehr als der Kunde wollte? (zu Hohe Kosten -> Wettbewerb)
- Wie können wir unsere Entwicklung planen und optimieren?
- Wo ist unser Firmen Know-How dokumentiert? (Kladden?) Wie wird es weitergegeben?
und soweiter ...
Zusammengefasst, Du wirst "Entwicklungsarbeit" leisten dürfen, in dem Du das für Euch nötige
Bewusstsein bei Entwicklern und Management förderst.
Auf anderem Weg sehe ich keine Chance einen Vollblutentwickler ("Hacker" -> nett gemeint)
dazu zu bewegen sich zu ändern.
Um auf Deine Frage zurück zu kommen, die notwendige Dokumentation ist für Euren Bereich individuell. Werden obige Fragen positiv beantwortet, steht auch Eure Dokumentation.
Just thoughts.
Grüssle
Felde

Hallo Felde,
danke für Deine Antwort hier - wir werden wohl bei zukünftigen Schulungen auf diesen Text hier verweisen, um die "Was ist Doku?"-Entwickler ein wenig mehr von QM zu überzeugen
Was mich noch interessieren würde: wie ist Deine Meinung zu CMMI/ISO 15504 o. ä.?
Gruß,
Daniel

Hallo Daniel,
bisher haben wir uns nur mit CMMI beschäftigt.
Es hat uns geholfen, die Lücken, die wir schon kannten, aber nicht greifbar (Zahlen-Daten-Fakten)
machen konnten, einzugrenzen. :o)
Mit dieser Einschätzung, die wir selbst gemacht haben (Entwickler + Qualitätsingenieur), können
wir dem Management zeigen, was noch zu tun ist, um den Level zu erreichen, der derzeit als Standard
gilt. Dabei ist keine der schlechten Bewertungen unbegründet gewesen.
Ich denke es ist ein gutes Hilfsmittel um die eigenen Entwicklungsschwächen aufzuzeigen.
Doch wie jedes Werkzeug sollte es nicht überbewertet werden. Der Prozess in der Entwicklung
muss stimmen, dann ist auch CMMI kein Problem.
Just thoughts.
Grüssle
Felde