Hi mein Arbeitgeber, kleiner Laden, 40 Mitarbeiter, 1 Embedded Software Ingenieur, will ISO9001 zertifiziert werden. Jetzt soll ich ein Software-Entwicklungsprozess aufsetzen. Das ist ja Uferlos und ein enormer Overhead. Reicht da eine vereinfachtes Ding ohne V-Model? Für meine super einfachen Anwendungen macht es gar kein Sinn zb einem V Modell nachzugehen. irgendwelche Tipps?
:
Verschoben durch User
Klaus schrieb: > irgendwelche Tipps? Es kommt nicht auf den Inhalt des Prozesses an. Es kommt darauf an einen Prozess definiert zu haben und zeigen zu können das und wie dieser eingehalten wird. Du kannst also einen maximal einfachen Prozess definieren, schriftlich fixieren und dann (z.B. anhand der von diesem Prozess geforderten Dokumenten) zu zeigen dass er eingehalten wird. Auch bei einem 1 Mann Team braucht es zumindest mal ein Lastenheft und ein Pflichtenheft. Wer erstellt was? Wo wird es abgelegt? Wie siehts mit einem Testreport aus? Wo liegt der? Wie sieht der "Freigabeprozess" aus? Wie kommt deine SW in die Produktion? Das reicht schon so ca. als Prozess aus.
:
Bearbeitet durch User
Dem schließe ich mich an. Im Prinzip geht es darum, einen Prozess zu definieren, der nachweislich eingehalten wird. Das muss kein langwierig erarbeitetes und komplexes Dokument sein. Bei uns in der Firma war z.B. dieser Prozess in einem einfachen Office Dokument als eine Art Ablaufdiagramm dargestellt. Kein großer Text, die Zustände des Diagramm repräsentierten die auszuführenden Aktionen. Daneben waren die Instanzen genannt, die von den jeweiligen Arbeitsschritten betroffen waren.
Du kannst volle Betonklötze giessen und die als Schwimmkörper verkaufen - wenn du dass alles nach DIN ISO 9001 schön dokumentierst und mit dem dazu erforderlichen Blah - Blah versiehst bekommst deine Fa. das Zertifikat und Deine Kunden kaufen Qualität nach DIN ISO 9001;-)
Walter K. schrieb: > Qualität nach DIN ISO 9001 Richtig, denn Qualität bedeutet Reproduzierbarkeit. Wenn dann will ich immer nicht-schwimmfähige Betonklötze kaufen und nicht ab und zu welche die doch hohl oder gar aus Holz sind...
Die Entwicklung selber ist quasi nicht Teil der 9001ff, jedenfalls, wenn ihr für euch entwickelt und nicht z.B. Auftragsarbeiten. Sie zu, dass die Anforderungen irgendwo stehen, dass Änderungen verfolgt werden, ein Repository, etc. Und ein Ausgabeprozess, wo Deine Software archiviert, versioniert, etc. wird. V-Modell taugt nur für die Entwicklung bekannter Dinge, nicht für irgendwas neues, innovatives.
Meide ISO9001 so gut es geht! Es treibt dich nur in den Wahnsinn, der reinste Bürokratie Irrsin und Arbeitsbeschaffungsmaßnahme. Ich würde mir ganz schnell einen neuen Job suchen ;).
Curby23523 N. schrieb: > Meide ISO9001 so gut es geht! Es treibt dich nur in den Wahnsinn, der > reinste Bürokratie Irrsin und Arbeitsbeschaffungsmaßnahme. > > Ich würde mir ganz schnell einen neuen Job suchen ;). Wenn Kunden darauf bestehen hat man keine Wahl. Andere bieten es an und übernehmen den Auftrag dankend. Und wer schon mit so einer Formalie Probleme hat, dem traue ich auch sonst nicht viel zu.
Klaus schrieb: > irgendwelche Tipps? ISO9001 soll sicherstellen, daß ihr ständig dieselbe Qualität abliefert. Bei Software heisst das testen, automatisch testen mit allen Tests die so im Laufe der Zeit anfallen, um sicherstellen zu können, daß ein ein Mal gefixter Fehler nicht erneut auftaucht. Das protokoll "Alle Tests bestanden" ist dann der ISO Nachweis. Es ist für ISO egal, ob die Tests sinnvoll und umfassend sind und ob die Software fehlerfrei ist, aber gegen Lastenheftvorgaben sollte man schon testen. Ihr müsst mindestend 4 Mitarbeiter benennen, nämlich Geschäftsführer, Qualitätsmanager der an Geschäftsleitung berichtet, ISO9000ff Beauftragter der an den Qualitätsmanager berichtet und derjenige dessen Arbeit nach ISO9000ff zu überwachen ist. Eine sinnvolle Organisation spart Arbeit und macht keine Mehrarbeit, lasst euch also keine Organisationsmethoden mit Aufwand aufschwatzen. Ein Repository für Altversionen sollte vorhanden sein, Backups auch. Selbst solche Dinge, wie man Mitarbeitern mitteilt was zu tun ist oder welche Sicherheitsvorschriften es im Betrieb gibt, muss bedenken, wie man das Mitarbeitern erklärt die eventuell die Landessprache nicht verstehen. Notfalls in dem man auf einen Passus in den Einstellungsvoraussetzungen hinweist, daß man die Landessprache beherrschen muss und daher keine Dolmetscher braucht. Da ihr wohl keine Zulieferer (immer dasselbe Teil mehrmals welches dann im Endprodukt steckt - nicht 1 x den Compiler) habt, entfällt das Problem wie die Qualtät von Zulieferprodukten sichergesteltl wird. Kann agiles development ISO9001 erfüllen ? Manche Leute sagen nein, prinzipiell nicht, aber ich denke schon, so lange die Tests erfolgen. Im seriösen Umfeld gilt DO-178, V-Modell XT und IEEE 12207 falls es um den ganzen SW Lifecykle geht. Geht es jedoch in Richtung SIL-Norm wie DIN EN 61508, verlangt sie für sicherheitsgerichtete Funktionen aber die Wasserfall oder V-Modell Methode bei der Entwicklung.
:
Bearbeitet durch User
Michael B. schrieb: > Geht es jedoch in Richtung SIL-Norm wie DIN EN 61508, verlangt sie für > sicherheitsgerichtete Funktionen aber die Wasserfall oder V-Modell > Methode bei der Entwicklung. Das ist richtig, doch sollte man dabei im Hinterkopf haben, dass dabei nur a) einfache, bekannte, bewährte Funktionalitäten verwendet werden dürfen (keine neuen Algorithmen oder Features) b) der Funktionsumfang am Anfang genau festgeschrieben und unabhänderbar sein muss (nämlich genau die aus anderen Gründen geforderte Sicherheitsfunktion) Das steht diametral zu normalen Entwicklungen, wo man einerseits Neues schafft (erstmals dies, verbessert das) und andererseits die Anforderungen sich stetig weiterentwickeln (Wenn man mit dem ersten Entwurf spielt, sieht man, was man eigentlich will). Es wäre daher fahrlässig und törricht (wenngleich weit verbreitet), die von SIL geforderten Mechanismen "weil sie da sind" auch für die eigentliche Entwicklung zu übernehmen. Man gießt damit die Flexibiltät quasi in Beton.
Jan H. schrieb: > Michael B. schrieb: >> Kann agiles development ISO9001 erfüllen ? > > Was könnte dagegen sprechen? Auf dem ersten Blick halt dass man tendenziell weniger mit Agilen Konzepten dokumentiert... Man kann aber trotzdem das richtige dokumentieren und die Normen erfüllen.
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.