Themen

Werkzeuge sind keine Lösungen

Essentielle Eigenschaften

Arten von Werkzeugen

Beispiele konkreter Werkzeuge

Folien

PDF

Glossar

PDF

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

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?

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, 2020Thomas, David; Hunt, Andrew (2020): The Pragmatic Programmer, Addison-Wesley, Boston] 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 [Brooks, 1987Brooks, Jr., Frederick P. (1987): No Silver Bullet Essence and Accidents of Software Engineering, Computer 20:10-19] 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, 1995Brooks, Frederick P. (1995): The Mythical Man Month, Addison Wesley Longman, Boston].

Zu Laborbüchern allgemein und ihrer sinnvollen Verwendung vgl. [Kanare, 1985Kanare, Howard M. (1985): Writing the Laboratory Notebook, American Chemical Society, Washington, D.C.], allgemein zum wissenschaftlichen Schreiben und Dokumentieren [Ebel, 2004Ebel, Hans F.; Bliefert, Claus; Russey, William E. (2004): The Art of Scientific Writing, Wiley-VCH, Weinheim, Shankar, 2007Shankar, Kalpana (2007): Order from chaos: The poetics and pragmatics of scientific recordkeeping, J. Am. Soc. Inf. Sci. Technol. 58:1457-1466].

Eine sehr gute Einführung in die Inhalte eines Datenmanagementplans und die Bedeutung eines geplanten Vorgehens in der Wissenschaft liefert Briney [Briney, 2015Briney, Kristin (2015): Data Management for Researchers: Organize, Maintain and Share your Data for Research Success, Pelagic Publishing, Exeter, UK]. 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) [Martinez-Ortiz, 2023Martinez-Ortiz, Carlos; Martinez Lavanchy, Paula; Sesink, Laurents; Olivier, Brett G.; Meakin, James; de Jong, Maaike; Cruz, Maria (2023): Practical guide to Software Management Plans]. Ansonsten ist der Softwaremanagementplan im Wesentlichen eine Neuerfindung der seit Jahrzehnten in der Softwareentwicklung existierenden und hinreichend dokumentierten Erkenntnisse [Brooks, 1987Brooks, Jr., Frederick P. (1987): No Silver Bullet Essence and Accidents of Software Engineering, Computer 20:10-19, Brooks, 1995Brooks, Frederick P. (1995): The Mythical Man Month, Addison Wesley Longman, Boston, Jacobson, 1992Jacobson, Ivar (1992): Object-Oriented Software Engineering, ACM Press, Addison-Wesley, Wokingham, Sommerville, 2018Sommerville, Ian (2018): Software Engineering, Pearson, Hallbergmoos, Krypczyk, 2018Krypczyk, Veikko; Bochkor, Olean (2018): Handbuch für Softwareentwickler, Rheinwerk Verlag, Bonn] und auch dort eine Anpassung allgemeiner Projektmanagement-Werkzeuge.

• Briney, Kristin (2015): Data Management for Researchers: Organize, Maintain and Share your Data for Research Success, Pelagic Publishing, Exeter, UK
• Brooks, Jr., Frederick P. (1987): No Silver Bullet Essence and Accidents of Software Engineering, Computer 20:10-19
• Brooks, Frederick P. (1995): The Mythical Man Month, Addison Wesley Longman, Boston
• Ebel, Hans F.; Bliefert, Claus; Russey, William E. (2004): The Art of Scientific Writing, Wiley-VCH, Weinheim
• Jacobson, Ivar (1992): Object-Oriented Software Engineering, ACM Press, Addison-Wesley, Wokingham
• Kanare, Howard M. (1985): Writing the Laboratory Notebook, American Chemical Society, Washington, D.C.
• Krypczyk, Veikko; Bochkor, Olean (2018): Handbuch für Softwareentwickler, Rheinwerk Verlag, Bonn
• Martinez-Ortiz, Carlos; Martinez Lavanchy, Paula; Sesink, Laurents; Olivier, Brett G.; Meakin, James; de Jong, Maaike; Cruz, Maria (2023): Practical guide to Software Management Plans
• Shankar, Kalpana (2007): Order from chaos: The poetics and pragmatics of scientific recordkeeping, J. Am. Soc. Inf. Sci. Technol. 58:1457-1466
• Sommerville, Ian (2018): Software Engineering, Pearson, Hallbergmoos
• Thomas, David; Hunt, Andrew (2020): The Pragmatic Programmer, Addison-Wesley, Boston