The (further) development of research software affects different levels of the research process within projects. Research software can, for example, be used or (further) developed as a research method or as part of a research infrastructure, or as an independent research object. For all uses of research software, the DFG’s guiding principles for the development of research software provide practical advice that should be taken into consideration during project planning and addressed when submitting a proposal.

Documentation and software management plans

Subject-specific best-practice examples can provide useful guidance when creating software and its documentation. Depending on the maturity or category of the research software, it may be advisable to set out key steps in the development process in a software management plan, from defining requirements to covering aspects of software evaluation and maintenance. It will often be advisable to do this during the project planning stage.

It is not necessary to submit a software management plan as part of the funding proposal. However, the proposal should indicate and justify the fundamental decisions made regarding the type of software as well as the development process, accessibility and maintenance of the software.

New or further development of research software

The proposal should address the reasons for a decision to develop new research software or further develop existing research software (e.g. the possibilities of or obstacles to using existing software). In addition, the proposal should describe how compliance with subject-specific development standards will be achieved. The personnel required for software development should be explicitly named and their tasks and qualification requirements described.

Version management

For research software that passes through various development stages in the course of a research project, the proposal should address how suitable version management is implemented in order to ensure the traceability of the research process.

Quality assurance in the research and development process

Considerations regarding objectives, milestones, etc., which can indicate project success, and targeted options for certifying the software – including subject-specific certification where available – should be included in the project planning as a further element to underpin sound quality assurance for software development. The project-specific decisions must be outlined in the proposal submission. 

Integration, use, licensing of third-party code and citation practice

When citing research software, in addition to the usual information (“title of the software”, “year”, etc.), it is also necessary to state the “author(s)”, “URL/DOI” and “version number”. The recommendation here is that applicants should draw on the usual professional standards and ensure machine citation.

The use of third-party code, i.e. integration of software packages into the applicant’s own software, etc. must be documented transparently in accordance with the applicable licence terms and in particular with regard to research integrity.

When submitting a proposal, care must be taken to ensure that any rights of use are obtained and that the use of third-party code is cited in accordance with the guidelines of good research practice.

Publications

When publishing research software and software documentation, preference should be given to publication channels that follow the Open Science or FAIR4RS principles, providing there are no legal or other reasons to the contrary. If decisions regarding documentation, licensing and publication models are made during project planning, this should be stated when the proposal is submitted. 

Rights and authorship of research software engineers

Before starting a research project, it must be clarified and, if necessary, contractually regulated with employees, students or external service providers to what extent their development contribution constitutes their own co-authorship and exploitation rights. A distinction should be drawn between development tasks that relate to normal work processes (e.g. installation of modules) and those that constitute an independent scientific achievement (e.g. project contributions in qualification and final theses). The development work done by project staff and third parties should be identified in a suitable manner (e.g. in the software documentation) and their role in the project should be described in the proposal.

Networking and building development and user communities

The (further) development of research software and ensuring its subsequent use is often dependent on close cooperation and the participation of a development and user community. It is therefore advisable to specify in the proposal the extent to which participation in existing national and/or international communities or the establishment of a user or development community is planned as part of the project and which objectives are being pursued.