Research Software Categories

Depending on its impact on research and its context, research software can be classified into three categories; low and medium impact and mission critical (high impact) software. It is important to note that many exceptions might occur, however the aim of this classification is to guide the user with the basic steps to be taken in order maintain and provide the reproducibility of research software. For further information please check the Practical Guides to Software Management Plans published by The Netherlands eScience Center and the NWO, The Dutch Research Council.

Low impact software

This category primarily includes software that is written as part of a one-off project and/or is not intended to be used beyond a defined period. While good software practices (e.g. version control and user documentation) are important in their development, long-term sustainability and its associated requirements are less relevant.

Software in this category is defined as low impact as it is not intended to be used by others, and has a relatively low influence outside the scope for which it was intended. Its potential for reuse would typically be very limited and potentially it may never be reused.

Examples are:

Software written as part of a course, e.g., used to explain an algorithm or illustrate a numerical method.
Software that is used to create and format a figure for a publication, e.g., created when using a plotting package such as ggplot2 or matplotlib.
Software written as part of a project to automate an administrative or routine process, e.g., monitoring a process or generating document templates.
Software written specifically for an experiment, e.g., a pipeline written for analysis of data and generating experimental results.

Medium impact software

Medium impact software refers to software that has been developed as part of a research project or is the primary output of a research project. In this case the software may have a direct influence on other research and/or software - even if this was not the primary intention when it was written - and long-term sustainability and reliability become more important.

The software may be developed for a single purpose but incorporates functionality that may be of use to others either as a standalone tool or library. As this software is, typically, either published independently or as part of a scientific paper there is the implicit requirement that it should be maintained for a longer period of time.

Examples are:

Software that implements a new or higher performance algorithm and can be applied to different input data, e.g., a protein/nucleotide alignment algorithm such as BLAST.
Simulation software that implements one or more models and/or numerical methods e.g., computational fluid dynamics, chemical interactions, planetary evolution, partial differential equation solvers, numerical integration, etc.

Mission critical software

The defining characteristic of mission critical software is that failure has a direct and negative impact on anything that interacts with it. There is no defined maintenance period associated with this class of software as it must be maintained as long as it is in use.

In addition to its purpose and sustainability, criteria such as software architecture, traceability, development standards and code quality now become very relevant.

An example is:

Software used in production on which an institute, department or instrument depends on for their operation, e.g. software that is used for processing data coming from a telescope.

Contact the DCC for support

Last modified:

10 February 2023 4.03 p.m.