Software Management Plans
Why write a Software Management Plan?
Research software can take many guises. It can be a 50 line bash shell script for manipulating and filtering files, a collection of 100 line R scripts for running a bioinformatics analysis, 10,000 lines of Java for medical image analysis or 100,000 lines of Fortran for computational fluid dynamics. It may be written in scripting languages such as Unix shell, Python, R or MATLAB or in "traditional" programming languages such as C, C++, Fortran or Java. But, whatever guise it takes, research software is an integral part of the modern research ecosystem.
When developing research software, it is easy to focus only on goals and activities such as collaborating with other researchers, writing papers, attending conferences and applying for funding. Together, the demands of daily research practice can all conspire to prevent proper planning for the development of research software.
A Software Management Plan (SMP) can help you to define a set of structures and goals to understand your research software including what you are going to develop; who the software is for (even if it is just for yourself); how you will deliver your software to its intended users; how it will help them; and how you will assess whether it has helped them, and contributed to research, in the ways that you intended. An SMP also helps you to understand how you can support those who wish to, or do, use your research software; how your software relates to other artefacts in your research ecosystem; and how you will ensure that your software remains available beyond the lifetime of your current project.
Though an SMP can be of most benefit when starting a project to develop research software, there are benefits to adopting one on a project that is already underway. An SMP provides a way to draw together and summarise research software-related aspects that have already been decided and doing so can reveal additional aspects or options that weren't considered, or weren't applicable, when the project began.
Write a Software Management Plan
We have written a checklist to help you write an SMP. It consists of sections that cover the key elements that an SMP should include. Within each section questions are posed to help you to complete that section. Complementary guidance and links to other resources are also provided. Not all questions are relevant to all projects and the extent to which a specific question can be answered may depend both upon the nature of your research software and its current state of development. Consider your SMP as a living document, to be reviewed and revised as the development of your research software progresses.
The checklist, and templates in Markdown, Microsoft Word, and OpenOffice/Libre office formats, is available within Zenodo:
The Software Sustainability Institute. (2018). Checklist for a Software Management Plan. v1.0. doi:
The Markdown template can be shared within a source code repository or pasted into a Markdown-compliant issue tracker (as provided by GitHub, GitLab and BitBucket, for example).
Use of our checklist
The Software Sustainability Institute provides this checklist on an "as-is" basis. It makes no warranties regarding any information provided within and disclaims liability for damages resulting from using this information. You are solely responsible for determining the appropriateness of any advice and guidance provided and assume any risks associated with your use of this advice and guidance.
SMPs and our Software Evaluation Service
Complementing our checklist for SMPs is our online sustainability evaluation service (SES). The SES is an online questionnaire which gives you the opportunity to review both the state of your research software itself, and the processes by which you are developing it. The SES provides one means by which you can assess how well you are implemnting your SMP in practice.
Version 0.2 was the same as version 0.1, below, but with changes to its presentation, and complemented by Markdown, Microsoft Word and Libre/Open Office templates.
Version 0.1 consisted of a short "minimal" software management plan (which now forms the core of 1.0) plus a 20+ page "full" software management plan. This proved to be somewhat verbose and intimidating to researchers, issues which motivated the production of the leaner version 1.0.
Though version 0.1 is now deprecated, support for writing version 0.1 is available within DMPonline, a flexible web-based tool provided by the Digital Curation Centre to help researchers create personalised Data Management Plans:
- Sign up to DMPonline.
- When you have an account, log in.
- Click the Create plan button or the Create plans menu bar button
- For "What research project are you planning?", enter a name for your project.
- For "Select the primary research organisation", enter "Software Sustainability Institute"
- For "Select the primary funding organisation", check the box "No funder associated with this plan or my funder is not listed".
- For "Which DMP template would you like to use", you have two choices:
- A minimal Software Management Plan: A minimal, or outline, plan to encourage you to think about what you are going to write, who is it for (even if this is just you), how will you get it to them, how will it help them, and how you will assess whether it has helped them or not. This plan can be used when you are starting a project or help you write proposals for funding, for example.
- A full Software Management Plan: A full, or detailed, plan which complements the minimal plan. The first section of the full plan - About your software - has the same questions, advice and guidance as the minimal plan.
- Click Create Plan
- You can now complete your plan. See DMPonline's Help page for information on how you can edit, share and export your plan.
Get in touch, help and support
You can provide feedack, suggestions and ask for help with using DMPonline for software management plans in two ways.
Either, e-mail us at firstname.lastname@example.org.
- Sign in to GitHub. If you don't have an account, then Sign up.
- Create a new issue describing your problem or feedback or suggestion.
This checklist has its origins in Chue Hong, Neil (2014) Writing and using a software management plan, The Software Sustainability Institute, 2014. The following people offered valuable advice and guidance which contributed to both the content and form of this checklist - Mario Antonioletti, The Software Sustainability Institute; Neil Chue Hong, The Software Sustainability Institute; Peter Cock, The James Hutton Institute; Steve Crouch, The Software Sustainability Institute; Robert Davey, The Genome Analysis Centre; Carole Goble, The Software Sustainability Institute; Catherine Jones, STFC; Sarah Jones, The Digital Curation Centre; Katrin Leinweber, Technische Informationsbibliothek; Mark Plumbley, Centre for Vision, Speech and Signal Processing, University of Surrey; Chris Rawlings, Rothamsted Research; Marta Ribeiro, The Digital Curation Centre; John Robinson, The Software Sustainability Institute; Shoaib Sufi, The Software Sustainability Institute.