14: Werkzeuge

Themen: Werkzeuge sind keine Lösungen; Essentielle Eigenschaften; Arten von Werkzeugen; Beispiele konkreter Werkzeuge
Folien: PDF
Glossar: PDF

Zentrale Aspekte

Werkzeuge nicht mit Lösungen verwechseln!
Lösungen erfordern den kompetenten Einsatz von Werkzeugen.
Werkzeuge reduzieren nicht die intrinische Komplexität.
Sie erleichtern bestenfalls den Umgang mit komplexen Abläufen.
Entscheidend ist zu verstehen, was ich erreichen möchte.
Die Umsetzung ist ein zweitrangiger technischer Aspekt.
Werkzeuge sollten mindestens plattformunabhängig, robust,
langfristig verfügbar, dezentral, modular und bewährt sein.
Grundausstattung ist ein Satz allgemeiner(er) Werkzeuge,
die je nach Bedarf passend ergänzt und erweitert werden.

Fragen zur Vertiefung und Wiederholung

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, werden aber nicht separat in der Vorlesung besprochen.

Warum sind Werkzeuge keine Lösung? Was braucht es, damit Werkzeuge zu Lösungen werden können?
Was ist der Unterschied zwischen einem Schema und einem Format? Warum ist diese Unterscheidung wichtig?
Wie unterscheiden sich Standards von Konventionen? Wer spielt eine größere Rolle für das individuelle Forschungsdatenmanagement?
Anhand welcher Kriterien lässt sich überprüfen, ob ein (Software-)Werkzeug aktiv gewartet wird?

Weiterführende Literatur

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Die Parallele zu Werkzeugen aus dem Handwerk wird treffend von Thomas und Hunt {[thomas-d-2020]} gezogen. Auch wenn sie auf Softwareentwicklung fokussieren, sind ihre Ausführungen allgemein(er) gültig. Der Essay „No Silver Bullet–Essence and Accidents in Software Engineering“ von Fred Brooks {[broo-comp-20-4-10]} bezieht sich (schon aus Brooks' eigener Erfahrung) auf die Softwareentwicklung (allerdings in großem Maßstab), enthält aber einige ausformulierte „Wahrheiten“, die sich letztlich auf jede Form des Projektmanagements anwenden lassen, und damit auch auf die Wissenschaft und Forschung und das Forschungsdatenmanagement. Ebenso lesenswert ist sein Buch „The Mythical Man Month“, das den größeren Kontext des Projektmanagements liefert {[brooks-fp-1995]}.

Zu Laborbüchern allgemein und ihrer sinnvollen Verwendung vgl. {[kanare-hm-1985]}, allgemein zum wissenschaftlichen Schreiben und Dokumentieren {[ebel-hf-2004,shan-jasist-58-1457]}.

Eine sehr gute Einführung in die Inhalte eines Datenmanagementplans und die Bedeutung eines geplanten Vorgehens in der Wissenschaft liefert Briney {[briney-k-2015]}. Eine pragmatische und aufgrund ihrer Zugänglichkeit für Forschende brauchbare, knapp gefasste Einführung in Softwaremanagementpläne kommt von der niederländischen Wissenschaftsorganisation (NWO) {[mart-zenodo-7589725]}. Ansonsten ist der Softwaremanagementplan im Wesentlichen eine Neuerfindung der seit Jahrzehnten in der Softwareentwicklung existierenden und hinreichend dokumentierten Erkenntnisse {[broo-comp-20-4-10,brooks-fp-1995,jacobson-i-1992,sommerville-i-2018,krypczyk-v-2018]} und auch dort eine Anpassung allgemeiner Projektmanagement-Werkzeuge.