Software Management Plans

A software management plan (SMP) contains general and technical information about the software project, information on quality assurance, release and public availability as well as legal and ethical aspects that affect the software.

The SMP summarises information that adequately describes and documents the creation, documentation, storage, versioning, licensing, archiving and/or publication of the software created or used in a project. Associated hardware and other necessary resources, as well as other associated software and software libraries, text and data publications must also be described and are a special feature of the SMP.

The purpose of an SMP is initially to support the traceability and, if necessary, the long-term usability of the software (for direct application as well as for further processing) and to facilitate user support in the event of queries. The SMP therefore also serves the purpose of quality assurance (see FAIR4RS Principles).

The SMP can be linked to one or more data management plans (DMP) if the software is used for data generation or processing. SMP and DMP can be summarised as output plans (see Software Sustainability Institute).

The content of a software management plan can vary depending on the project, but generally includes the following sections:

Components of a Software Management Plan at a Glance

Project name, project participants, schedule, financing/sponsor, required hardware, circumstances of development

Function and context of application, code, external components and libraries, target group, use

Documentation for users and administrators/post-programmers (inline or separate) regarding methods, interfaces, versioning (release management), metadata, testing and quality assurance/standards

Archiving and publication of the software, licences / rights of use

Long-term maintenance of the software, support for users

Copyright, dual use, ethics check

Potential re-use of the software, added value for research

Resources (personnel, hardware, software, training) and roles

The Benefits of a Software Management Plan

Advantages of the SMP over DMP

Increased understanding of software development as a collaborative project
Increased product-intrinsic focus of software development

Homogenisation of the Software

Comparability
Reuse of software modules
Dissemination of good coding practices

Added value for research (element)

Traceability
Reusability

Quality assurance

Extends/improves documentation in favour of peer review and subsequent use
Enables early testing of software and hardware components
Compliance with the FAIR4RS Principles

Counselling

Background information
Early detection of vulnerabilities (planned use of proprietary or questionable libraries...)
Cost control

Creating SMPs free of charge

Software management plans can be created in the free DMP tools DMPonline and RDMO using a special templates or question catalogue. There is also a DOCX and Markdown template from the Software Sustainability Institute. A GitHub or GitLab wiki is also suitable for creating an SMP to document planning and implementation in an application.

Research Funders' Requirements for Research Software

Deutsche Forschungsgemeinschaft (DFG)

SMP is not necessary
Code of Conduct Guideline 13 is about creating public access to research results to make the software used available and to comprehensively describe work processes. Self-programmed software is made publicly available with the source code.

European Research Council (ERC)

SMP is not necessary
But software is usually mentioned together with data in the "Information for ERC grantees" (v4.1)

Horizon Europe

SMP is not necessary
Software is not explicitly mentioned in the General Model Grant Agreement (v1.1) hardly mentions it explicitly
but: „the beneficiaries must provide (digital or physical) access to data or other results needed for validation of the conclusions of scientific publications, to the extent that their legitimate interests or constraints are safeguarded“ S. 112

VolkswagenStiftung

SMP is not required
but software is mentioned in the Open Science Policy:
"Software [is] not a 'by-product', but an integral part of research" p. 5
"Open source software must be listed separately in the applicant's CV for the review and decision-making process." p. 6

Bundesministerium für Bildung und Forschung (BMBF)

No dedicated requirements for software

Software Management Plan FAQ

When is an SMP necessary? What project size requires an SMP?

An SMP is not always mandatory or necessary. The requirements of the research sponsor should be checked first. However, depending on the scope of the project, it can be very useful to draw up and continuously maintain a software management plan, e.g. if the software is the primary project output. The classification of the DLR can serve as a guide (see p.7): Application classes 0-1 - no SMP, application classes 2-3 - SMP recommended.

Are there templates for writing software management plans?

Yes, various institutions and communities now offer SMP templates, e.g. RDMO or Elixir. The SMP handout from the Netherlands is also interesting here.

How do you write a realistic SMP and how do you implement an SMP?

An SMP should be formulated as realistically as possible and not make any promises that cannot be kept. A consensus within the project group should therefore be sought. The use of templates is recommended to check relevant topics. As with the DMP, the implementation of the SMP should be accompanied by regular updates in order to make changes visible (SMP as a living document).

Which ticket system is recommended?

The choice of ticket system depends on the scope of the project. There are both stand-alone solutions and integrated ticket systems in larger software packages. With a focus on software development, GitLab and GitHub already offer suitable ticket systems that can be linked to steps in the software development process.

Which versioning system is recommended?

Versioning is advisable when working with software code. Software solutions such as GitLab, GitHub, Codeberg, BitBucket etc. are suitable for versioning. These are often already offered by your own institution or as a federated infrastructure.

Which repository can be used to publish research software?

Depending on the use case, the software can be made openly accessible via GitLab, GitHub, Codeberg, CodeOcean or BitBucket, for example. Data repositories can also be suitable for publishing research software. In some cases, suitable interfaces already exist so that a new release can be automatically published on Zenodo via a GitHub action, for example.