A software management plan (SMP) is a document that describes how a specific software project is developed, maintained, and curated. The goal of an SMP is to ensure that the software is usable and maintainable in the long term. An SMP is written by the developers, maintainers, and/or other stakeholders of a software project.

An SMP can help to:

  • Explain why developing new software is necessary. New software should not be developed when it would be more cost-efficient and beneficial for the overall community to contribute to existing software.
  • Make the research software reusable and sustainable. An SMP encourages software developers to think about, for example, technical choices (such as programming language or operating system dependencies); whether the right documentation and metadata are provided (e.g. to allow for reproduction or extension of an analysis); and to ensure that the software is findable and adequately licensed for reuse for an extended period of time.
  • Plan for the necessary resources. Various types of resources exist: financial, human, infrastructure, etc. Whenever reusing, creating or building upon research software in a research project, additional resources might be needed. The questions in an SMP can help to predict which resources will be needed for developing and maintaining the software (e.g., hiring research software engineers, training), for making the software available to others (e.g., infrastructure) and for making and keeping the software accessible over time.
  • Allow for verification of work that went into software implementation. When a project is funded to build software, the funders and the community at large should be able to know if the project’s plans regarding the software have been carried out.

Set of the core requirements for your Software Management Plan (SMP)

  • Purpose. What is the current reason or expected end-use for developing the software?
  • Reliability. The effect of software failure and/or non-maintenance on:
    • Risk of harm to self or others. This includes injury, privacy violation, bias, and inappropriate content.
    • Reputation. For example, to self, institution or other.
    • Research, either your own or of others. This effect could be due to an obvious software failure (“crash”) or a hidden one, for example, returning inconsistent numerical results on different operating systems.
  • Maintenance. The long-term effort needed to maintain the software as long as it might be used as a standalone tool or dependency. This includes maintenance functions that can extend beyond the lifespan of the original development project and includes fixing bugs, dependency management, operating system compatibility, and security issues.

Using these points three typical management plans (low, medium, high) for three software categories can be used. It should be noted that, in practice, each institution/organisation is responsible for defining its own management plans, and as a software evolves, so does the management plan and its level.

Software Management Plans (SMP)

This document aims to support ICAC researchers in the drafting of their Software Management Plans (SMP).

Go

Questions?

For more information and assistance, contact Documentation Centre and Library.

Contact

Source:

Martinez-Ortiz, C., Martinez Lavanchy, P., Sesink, L., Olivier, B. G., Meakin, J., de Jong, M., & Cruz, M. (2022). Practical guide to Software Management Plans (0.10). Zenodo. https://doi.org/10.5281/zenodo.7185371

Last updated: 13/02/2024