Verfahrensanweisung gemäß DIN ISO 9001:2000 zur Lenkung der EDV

Hallo Tanja,
wenn ich es richtig gesehen habe ein Visualisierungstool für Prozesse.
Ein Tool kann helfen, Prozesse zu definieren, aber im Bezug auf EDV ist wohl eher die Frage,
möchte die EDV dies überhaupt bzw. hat jemand gemerkt, dass es dort nichts oder wenig gibt?
Grüssle
Felde

Hallo Vivian,
Du hast recht, dass dies alles nicht gar so viel mit Lenkung von Dokumenten im allgemeinen Sinne
hat. Andererseits bringen Dir die schönsten VA nichts, wenn Dir Deine Grundlage fehlt: EDV.
Was bringt Dir ein Backup, wenn keiner weiss, wie er das komplett abgebrannte EDV-Zentrum wieder
aufzubauen hat. Klar, es ist alles möglich, aber in welcher Zeit?
Es gibt unzählige Möglichkeiten, die erst auf den zweiten Blick damit zu tun haben.
Leider machen sich die wenigsten Gedanken darüber.
Wo steht bei Euch, was ein Admin können und tun muss? Wo dokumentiert er?
Software:
SW sollte optimalerweise "top-down" entwickelt werden.
Das heisst erstellen einer Spezifikation, danach Design und erst dann den Code.
Verifiziert wird dann durch Code-Reviews, Modul-Test, Modul-Integration-Tests und Hardware-Software-Integration-Tests.
Danach folgen die Systemtests am Gesamtprodukt.
Um sicher zu gehen, dass auch alles korrekt umgesetzt wurde gibt es Reviews von Spec, Design
und Code. Zusätzlich wird mit Tracebility gearbeitet, die zeigt, ob alle Requirements umge-
setzt worden sind und zusätzlich, ob alle Requirements abgetestet worden sind.
Diesen SW-Entwicklungsablauf wird auch "V-Modell" genannt.
Wir in der Luftfahrt haben SW auf diesem Wege zu erstellen (gem. RTCA DO178B). Je nach Kritikalität
wird dann lediglich der Umfang reduziert.
Die Validation wird durch die Integration erreicht, denn das Produkt sollte ja richtig
funktionieren. Fehler liegen dann entweder bei der Umsetzung oder bei der Spezifikation selbst.
Andere Bereiche betreiben keinen solchen Aufwand.
Hier wird ein Lasten- und Pflichtenheft erstellt und dann losgelegt.
Dokumentation sollte hier auf jeden Fall in Form eines standardisierten Funktions-/Modulkopfes
erfolgen. Dieser muss eine Kurzbeschreibung der Funktion/Moduls, die Übergabeparameter-
Beschreibung, die benutzten globalen Variablen und die Rückgabewerte aufweisen.
Zusätzlich sind die Code-Zeilen mit mehr "Hirnschmalz" zu kommentieren.
Jede Zeile muss nicht sein. Man sollte eben daran denken, dass man den Code in 2-3 Jahren selber
noch verstehen sollte.

Die Zeit, die ich bei der Erstellung des Codes spare, wenn ich nicht dokumentiere, vervielfacht
sich bei den nächsten Modifikationen.
Was auf jeden Fall auch Sinn macht, ist es eine grobe Architektur der SW zu dokumentieren.
Modifikationen werden dadurch schneller, da weniger Einarbeitungszeit nötig sein wird.
Wieder einmal ein paar Gedanken. ;o)
Grüssle
Felde

Hallo,
um solche Dinge einfach und sinnvoll zu lösen sollen Sie einmal unter "www.wissIntra.de" nachlesen. Hier haben wir, für unsere Abläufe eine obtimale Lösung gefunden.
Viel Spaß und Gruß
Tanja

Hallo Felde,
ich danke dir für deinen Überblick. Wir entwickeln gegenwärtig nur in geringem Umfang Software. Die Validierung steht trotzdem an und wird von unserem Kunden erwartet. Ich muss mich demnächst intensiver mit der Thematik auseinandersetzen und muss entsprechende Verfahren definieren.
: Wo steht bei Euch, was ein Admin können und tun muss? Wo dokumentiert er?
Derzeit steht die Aufgabenbeschreibung unseres Admin in der Stellenbeschreibung. Welche Daten er wie zu sichern hat, ist in entsprechenden Arbeitsanweisungen unter der VA "Lenkung der Dokumente und Daten" angesiedelt.
Unsere archivierten Dokumente und Daten würde ich am liebsten auslagern. Wenn es in unserer Firma einen Wasserschaden oder Brandschaden gibt, können wir die Firma schließen. Unser EDV-Bereich ist nicht so groß, den Verlust bekommt man in den Griff - fehlende Dokumentationen sind nicht ersetzbar. Das muss allerdings die GL entscheiden.
Spezielle Dokumentationsvorschriften gibt es für ihn noch nicht. Vor allem die Softwareentwicklung für interne Bedürfnisse ist ein einziges Desaster - wir haben nach Monaten noch keine Lösung. Ich habe versucht, für eine interne Entwicklung endlich ein verbindliches Lastenheft zu schreiben, um unserem Andmin eine vernünftige Arbeitsgrundlage zu geben bzw. das System im Notfall auch extern beauftragen zu können.
Andererseits muss ich auch bei Kauf einer Softwarelösung ein konkretes Lastenheft definieren. Auch der Versuch unserer GL, eine spezielle Softwarelösung zu kaufen bereits desaströs ausgegangen. Eine Validierung hat nie stattgefunden.
Mein Beispiel zeigt, wie existentiell wichtig in der Software-Entwicklung klar definierte und dokumentierte Anforderungen sind.
Vielen Dank
Vivian

Hallo Vivian,
nicht traurig sein, die Softwareentwickler sind nun mal so. ;o)
Am liebsten Ärmel hochkrempeln und loslegen.
"Wie das Ziel aussieht das habe ich im Kopf, aber vielleicht ändert sich das auch noch."
Leider muss man die Software-Entwickler zu Ihrem Glück etwas zwingen.
Dabei erreicht man ein gewisses Verständnis, wenn man folgendes aufzeigt:
1. Die Software soll von jemand anderem in ein paar Jahren modifiziert werden. Geht das?
=> Dokumentiere so, wie Du es gerne vorfinden würdest bei einem anderen Projekt.
(Vergiss aber die kurze Einarbeitungszeit nicht, die Du lediglich bekommst.)
2. Über 70\% der Produktfehler werden in der Entwicklung gemacht.
=> Nimm Dir jetzt etwas mehr Zeit und Du musst Dich später nicht mit Modifikationen und Fehler-
suche herumschlagen.
3. Je nach Produkt sollte man auch die Konsequenzen "meiner" Entwicklungsfehler berücksichtigen.
=> Z.B. Luftfahrt- und Automobilindustrie:
Es sterben Menschen, weil ich mir die Zeit nicht genommen habe.
-> Der Richter wird mir daraufhin unangenehme Fragen stellen, die hoffentlich mit gut
dokumentiereten Antworten aus der Welt geschafft werden.
In Amerika gibt es öffentliche Hearings (Zuschauer und Kameras), wo sich auch
die "kleinen" Mitarbeiter rechtfertigen müssen.
Der Trend geht mehr und mehr in diese Richtung.
Die QS möchte lediglich dazu beitragen, dass niemand solch negative Erfahrungen machen muss.
Schön, wenn nie etwas passiert. Doch wir sind nicht davor gefeit.
Always some thoughts.
Grüssle
Felde

:Wie kann ich Dich erreichen, dann sende ich Dir eine VA zu