Dokumentation in der Softwareentwicklung

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

Hallo, leider treffe ich erst jetzt auf dieses Forum.
Ich bin ein Softwareentwickler in einem Maschinenbau Industrieunternehmen und möchte mal dazu äußern.
Bei uns ist es eher umgekehrt !
Wir würden uns solch ein QS Management wie Ihr es beschreibt wünschen.
Wir haben unsere Entwicklungs-Standards nach Kunden und GMP Standards festgelegt und nieder geschrieben nach dem hier bei uns alle Softwareentwickler arbeiten.

In unserem Handbuch ist alles von A-Z geregelt.
Von der Eingabe/Antrag incl. Formular einer Software- Änderung, Fehlerbeschreibung oder Neuerung bis hin zum Review des Testplans und Freigabe einer Softwareversion.
Alles wird Dokumentiert auf Formblättern und im Source-code nachvollziehbar auch für nicht Fachmänner.

Uns und unseren Kunden gefällt das sehr gut.

Gruß
Stefan