Software Life Cycle Processes for Medical Devices

1. Overview on software life cycle processes

The software life cycle covers all activities from the first product idea to deinstallation, respectively decommissioning of the last instance of the product. The software life cycle processes include but are not limited to

  • Software development
  • Software installation and operation
  • Software maintenance
  • Problem resolution
  • Deinstallation / decommissioning

2. Regulatory requirements

As software testing cannot prove the correctness of software, software errors (bugs, usability problems) have to be avoided right from the beginning by following software life cycle processes. All software related regulations such as IEC 62304 and the FDA software validation guidance document demand from medical device manufacturers to follow these life cycle processes. However, they do not enforce a particular life cycle model such as a waterfall model, v-model or an agile development processes.

a) IEC 62304

Life Cycle Processes

IEC 62304 requires the following processes to be implemented

  • Software development
  • Software maintenance
  • Problem resolution
  • Risk management
  • Configuration management

Development Process

The software development process must cover - depending on the software safety class - the following activities:

b) Medical Device Regulation (MDR) and Medical Device Directive (MDD)

The medical devices regulation (MDR) and medical device directive (MDD) require software lifecycle processes:

"For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation."

Manufacturers prove compliance with these requirements by following the IEC 62304.

c) Other regulations

All relevant regulations and standards require a process-oriented approach:

  • The ISO 13485 calls for process-oriented approach, not just in the development.
  • The ISO 14971 describes a risk management process.
  • The IEC 62366 demands, that the usability of medical devices using a "usability-oriented development process" be followed.
  • The IEC 60601-1 obliges manufacturers of programable electrical medical systems (PEMS) to follow a life cycle process. The appendix contains this example that has a lot of similarities with the v-model.
PEMS life cycle model according to IEC 60601-1
Fig. 1: PEMS life cycle model according to IEC 60601-1: software development life cycle in red, system development life cycle in green (Click to enlarge)

Unfortunately, IEC-60601's PEMS life model is rather misleading and inconsistent. The following chart is more concise.

Medical device life cycle model
Fig. 2: Typical life cycle activities throughout software development. This figure can be used as documentation model rather than life cycle model (Click to enlarge)

Development Processes and Process Models

a) What a process defines

The development process describes as any other process

  • who (which role e.g. requirements engineers, programmers, software architects, testers, etc.)
  • transfers: which inputs to which outputs (documents, products, decision, components)
  • in which sequence (e.g. in parallel, sequential)
  • how (i.e. using which methods, procedures and tools)

b) Typical life cycle activities

The typical activities throughout a development process include

  • defining an intended use and making a business case
  • identifying the stakeholder requirements
  • specifying system respectively software requirements and reviewing this "SRS"
  • designing a technical solution e.g. creating a system respectively software architecture including review
  • implementing, developing, programming system respectively software components accordingly following best practices e.g. coding guidelines
  • verifying components e.g. with unit tests or code reviews
  • verifying the integration of components e.g. integration tests
  • verifying the entire system respectively software e.g. software tests
  • validating the entire system respectively software e.g. summative usability evaluation or clinical evaluation

To prove that these activities actually have been performed, manufacturers respectively developers have to plan, document and verify what they do.

c) Methods and procedures

For each of these activities manufacturers have to define a set of methods or procedures (set of methods).


ActivityMethod(s) (Examples)
Identify stakeholder requirements Context methods (as described in ISO 9241)
Specify software requirementsPrototyping with mock-up screens
Modelling software architectureUML modeling, implementation of vertical prototypes
Software testingBlackbox test methods e.g. with equivalence classes

d) Process models

It is up to the manufacturers to define the sequence of these activities and to determine whether these have to be performed in a linear or in an iterative and incremental approach.

Accordingly, most medical device manufacturers follow

  • a waterfall
  • V-model-like 
  • an agile process mode.

You can read the Agile Software Development more here.

Software Development Process Versus Software Development Plan

Manufacturers are free to define life cycle processes specifically for each of their products. For example, they can pick an agile development process to develop one product and define a waterfall model for another.

a) Content of development plan

The product respectively project specific decisions are documented in a (software) development plan. In this plan they can determine

  • the processes to be applied for the specific project
  • the roles and the assignation of specific persons to these roles
  • the methods and procedures
  • the tools
  • the milestones

b) Distribution of content

If the development team has to follow always the same requirements, Johner Institute recommends to shift as many of these requirements into the development process description (SOP) and to keep the development plan rather slim.

However, if the development team, e.g. an engineering service provider, has heterogenous projects then the SOP will be rather generic and require to describe the specific requirements in a project specific development plan. 

However, this figure implies no V-model - even if it looks like it. These activities can also be run through interactively and incrementally. Read more here about agile (software) development.

Note, that you must complete all the activities on the left side with a verification.


Prof. Dr. Christian Johner


A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau