Meticulous software development is an essential part of good academic practice. The German Research Foundation's guidelines for safeguarding good research practice therefore also apply to research software. They establish minimum standards and guiding principles. Yet how can they be implemented?

The following table provides an overview of key aspects of the DFG's code that relate to software-specific issues.

Recommendations for Implementation

Research software is an integral part of the research process and in many cases indispensable for the verifiability of research results and data. The software used can itself be part of the results and should then be included in the scientific discourse at an appropriate time and in an appropriate form.

Research software in a broader sense also includes command line inputs. In order to enable complete verifiability of the work processes performed, a command to control software, for example, may be worthy of publication if it contains expert knowledge.

1. Versioning

Software is versioned. When a research result has been produced, the version used is named and archived. The software's state is appropriately identified. Even though software in the research environment is developed in an agile manner and the expectations of it can change within a day, three degrees of maturity can be roughly distinguished from each other. These are shown in the following figure.

2. Documentation

Software must be suitably annotated and, if necessary, documented, even if no publication is planned. Research software must be documented in a way that is comprehensible to the reader. For agile working practice, three levels of comprehensiveness of documentation can be delineated.

3. Publication

An academic publication in a scientific or scholarly journal must provide all information necessary for academic discourse. If research software was used in the preparation of the publication, it should be cited with a version number (if available also by a PID, e.g. DOI). Access to research software should be freely available, taking into account points 1 and 2. For better citation, version-controlled software archives are to be preferred. If free access to the software is not possible in a timely manner, at least the algorithm used in it should be published in its entirety. In such cases, it must be checked whether it is possible to release the software sources within an embargo period. If access to the research software is only possible with restrictions, this must also be explained transparently, stating the reason and, if applicable, the embargo period. A permissible reason is the protection of (intellectual) property, e.g. of valuable components that are not scientific/scholarly in a narrow sense, before publication.

4. Recommendations (Checklist)

• Attend a software quality course.
• Have source code review software ready to use.
• State the purpose of the software succinctly.
• Keep the degree of maturity of the software appropriate to the current approach to quality assurance.
• Make the intention of each function recognisable (for example, through self-explanatory names or comments).
• Choose a permissible licence.

^{_{The preparation of this text was supported by a grant from the German Research Foundation (DFG) within the framework of the Excellence Strategy of the German Federal and State Governments - 2082/1 - 390761711.}}