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
- Reuse of software modules
- Dissemination of good coding practices
Added value for research (element)
- Extends/improves documentation in favour of peer review and subsequent use
- Enables early testing of software and hardware components
- Compliance with the FAIR4RS Principles
- 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)
- 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
- 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?
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.
Paper: „Sicherstellung der Reproduzierbarkeit von Forschungsergebnissen durch Bewahrung des Zugriffs auf Forschungssoftware“ (German)
Authors: Dirk von Suchodoletz, Peter Brettschneider, Alexandra Axtmann, Maximilian Heber, Lars Oberländer, Jan Leendertse, Irene Schumm, Olaf Brand, Karstin Schmidt, Livia Gertis, Michael Selzer, Robert Ulrich, Dorothea Iglezakis, Valerie Boda
Year of Publication: 2023
Link to paper