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 Florian,
mein Ziel ist es, die Daten in dem Arbeitsstand zu speichern, der zum Zeitpunkt der Auslieferung an den Kunden aktuell war, bzw. genau den Auslieferungsstand dokumentiert - wichtige Entwicklungsstände werden natürlich auch gesichert.
Mit Daten wird unwahrscheinlich geschlampt. Ich habe auch schon in die Abgründe der Datensicherheit und Datenrichtigkeit geschaut. Dem Datenmüll, der sich vor allem auf lokalen Rechnern tummelt, kommt man kaum bei.
Welche Erfahrungen hast du aus der Altdatenmigration? Unsere Kunden halten uns an, unsere Daten 30 Jahre aufzubewahren und lesbar zu halten. Für bezahlbare Tipps wäre ich dankbar.
Viele Grüße in die Schweiz
Vivian

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 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 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 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