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
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.
IEC 62304 requires the following processes to be implemented
The software development process must cover - depending on the software safety class - the following activities:
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.
All relevant regulations and standards require a process-oriented approach:
Unfortunately, IEC-60601's PEMS life model is rather misleading and inconsistent. The following chart is more concise.
The development process describes as any other process
The typical activities throughout a development process include
To prove that these activities actually have been performed, manufacturers respectively developers have to plan, document and verify what they do.
For each of these activities manufacturers have to define a set of methods or procedures (set of methods).
|Identify stakeholder requirements||Context methods (as described in ISO 9241)|
|Specify software requirements||Prototyping with mock-up screens|
|Modelling software architecture||UML modeling, implementation of vertical prototypes|
|Software testing||Blackbox test methods e.g. with equivalence classes|
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
You can read the Agile Software Development more here.
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.
The product respectively project specific decisions are documented in a (software) development plan. In this plan they can determine
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.