Software Lifecycle

Software lifecycle means more than software development

A software lifecycle is the connected set of activities used to define, create, verify, release, maintain and retire software. It includes planning, risk management, configuration control, problem resolution and objective evidence as well as design and coding.

For a medical device, software does not succeed merely because it builds or passes unit tests. It must contribute safely and reliably to the intended medical purpose, operate correctly within the complete system, remain controlled after release and support conclusions that reviewers can trace.

MTL-303 — IEC 62304 Software Lifecycle explains the detailed process framework of the standard. This core topic concentrates on how those software activities fit into practical medical-device development.

Start with the medical-device context

Software planning begins before a software requirement is written. The team first needs a stable understanding of the intended purpose, users, patients, use environments, claims, regulatory route and the role software plays in achieving the medical outcome.

• What device function or clinical workflow does the software support?
• Which users interact with it, and what knowledge or training can be assumed?
• Where will it operate: hospital, home, laboratory, mobile platform, cloud environment or a combination?
• What happens if the software is unavailable, delayed, incorrect or misunderstood?
• Which external systems, accessories, networks and data sources are required?
• Which behaviours are safety related, security related or necessary for essential performance?
• Which product claims depend on software-generated data or decisions?

MTL-102 — Intended Purpose, Users and Use Environments establishes these boundary conditions. Software scope that is defined without them tends to grow informally and leaves critical assumptions undocumented.

Define the software system and its boundaries

A connected medical device may contain several different software elements. The organisation should identify what it develops, what it configures, what it acquires and what remains outside its direct control.

Draw the boundary explicitly. Identify interfaces, data ownership, timing assumptions, failure responses, update paths and responsibility for each element. A label such as “the app” is rarely precise enough for requirements, risk analysis or release control.

Plan a proportionate and reviewable lifecycle

The lifecycle plan explains how software will be developed and controlled. It should be proportionate to the device, software safety significance, complexity, novelty, organisation and selected development model.

Agile, iterative and incremental methods can be used. The important point is that increments remain controlled: approved inputs are available at the right time, risks and interfaces are considered, evidence is preserved and the released baseline is known.

Connect software decisions to product risk

Software can initiate a hazardous situation, fail to perform a risk control, present misleading information or prevent another control from operating. These contributions must be analysed as part of the device risk-management process.

MTL-105 — Medical-device Risk Management explains the complete risk process. For software, risk analysis should influence requirements, architecture, segregation, defensive behaviour, verification depth and the handling of unresolved anomalies.

Software safety classification under IEC 62304 is not the same as overall device classification or a simple project risk score. The rationale considers the possible contribution of software failure to hazardous situations and the effect of external risk controls. Record the assumptions and revisit them when the architecture or controls change.

Build a connected requirements hierarchy

Software requirements translate system responsibilities into implementable and verifiable behaviour. They should cover normal operation, boundaries, timing, data, interfaces, faults, recovery, installation, maintenance and relevant risk controls.

MTL-103 — User Needs and Design Inputs explains how needs become controlled inputs. Bidirectional traceability should allow the team to find the implementation and evidence for every software requirement—and explain the source of every implemented requirement.

Use architecture to manage complexity and risk

Architecture describes the major software items, their responsibilities and their interfaces. It should make important design decisions visible before those decisions become distributed across source code.

• Allocate safety-related and risk-control functions deliberately.
• Define data flows, state transitions, timing and resource assumptions.
• Identify external interfaces, protocols and failure behaviour.
• Separate or segregate functions where independence is relied upon.
• Show how the design detects, contains and recovers from faults.
• Identify third-party components and platform dependencies.
• Keep architecture consistent with the implemented and released configuration.

Architecture is not a single diagram prepared for an audit. It is a maintained explanation of how the software fulfils its allocated responsibilities and how critical interactions are controlled.

Make implementation disciplined and reviewable

Implementation practices should reduce defect introduction and make important behaviour understandable. The appropriate rigour depends on safety significance, complexity, technology, team capability and the effectiveness of later detection.

Generated code, low-code platforms and reusable internal libraries do not remove lifecycle responsibility. The team still needs to understand the source, configuration, limitations and evidence appropriate to their contribution.

Verify from units to the complete device

Software verification builds evidence at several levels. Unit evidence finds local defects; integration evidence examines interactions; software-system evidence confirms the assembled software; device-system evidence confirms behaviour with representative hardware, users, data and external systems.

MTL-106 — Verification and Validation explains evidence strategy, configuration, protocols, anomalies and representative validation across the complete device.

Control third-party and previously developed software

Operating systems, libraries, drivers, databases, cloud services and open-source components can shorten development, but they introduce dependencies the manufacturer did not fully design or verify.

• Identify each component, supplier, version, licence and intended role.
• Evaluate suitability, known limitations and available evidence.
• Analyse how failure could contribute to hazardous situations.
• Define compensating controls when component evidence is limited.
• Record known anomalies and assess their relevance to the device.
• Control upgrades, patches, build dependencies and configuration.
• Monitor information that may change the component’s acceptability after release.

A component inventory is useful only when it remains connected to architecture, risk, configuration and maintenance decisions.

Release a known and reproducible configuration

Software release is a controlled decision that the specified version has met its completion criteria and is suitable for its intended next use. The record should identify exactly what was released and the evidence supporting that decision.

• Unique software and build identifiers.
• Controlled source, dependencies, compiler, build scripts and configuration.
• Completed planned verification and justified residual anomalies.
• Updated risk, traceability and change records.
• Installation, upgrade, rollback and compatibility information.
• Release notes and known limitations appropriate to recipients.
• Approval and secure retention of the released baseline.

A build stored on a developer’s computer is not a controlled release. The organisation should be able to reproduce or otherwise authenticate the delivered configuration and relate field reports to the exact version in use.

Maintenance is development with additional responsibilities

After release, software problems, support requests, platform changes, vulnerabilities, supplier updates and product improvements enter a controlled maintenance process. Each proposed change needs impact analysis before implementation.

Problem resolution records should preserve the original observation, investigation, cause, decision, correction and verification. Closing a ticket is not the same as demonstrating that the product issue is resolved.

Cybersecurity is connected—but deserves its own lifecycle

Software lifecycle controls provide foundations for cybersecurity: known assets, controlled requirements, architecture, component management, verification, configuration and maintenance. Cybersecurity adds threat modelling, security risk, secure design, vulnerability testing, coordinated disclosure, security updates and monitoring of a changing threat environment.

These activities should share interfaces and evidence, but safety risk and security risk should not be treated as interchangeable. MTL-108 — Medical-device Cybersecurity addresses the security lifecycle in detail, including its relationship with safety, privacy and post-market vulnerability management.

Retain control when work, tools or platforms are external

Outsourcing development does not outsource manufacturer accountability. Define deliverables, lifecycle responsibilities, review rights, configuration access, anomaly reporting, maintenance support and evidence expectations before work begins.

Development and test tools also need proportionate assurance. Consider what the tool does, how an error could affect the product or evidence, whether the error would be detected and what controls are already present. The response may range from basic configuration control to formal tool validation.

Contracts matter, but technical oversight matters more. The manufacturer needs sufficient internal competence to understand decisions, challenge evidence and support the software throughout the device lifetime.

Worked example: a connected injection device

A connected injection device contains embedded control software, a patient mobile application and a cloud service used by clinicians. The system team allocates dose delivery, feedback, records and connectivity responsibilities before the software teams define their detailed requirements.

A late change to the communication protocol affects more than code. The impact analysis considers requirements, architecture, timing, battery consumption, error handling, cybersecurity, mobile compatibility, risk controls, regression and the field-update approach.

Common failure patterns

Practical software-lifecycle checklist

• The role of every software element in the medical device is defined.
• Software boundaries, interfaces, platforms and external dependencies are known.
• A proportionate lifecycle plan defines activities, responsibilities, outputs and completion criteria.
• Software safety classification and its rationale are documented and maintained.
• Requirements trace to system needs, risk controls, architecture, implementation and evidence.
• Architecture addresses critical interactions, fault responses and segregation assumptions.
• Implementation practices and reviews are defined in proportion to risk and complexity.
• Verification covers units, integration, software-system and device-system behaviour.
• Third-party components, versions, anomalies and dependencies remain controlled.
• Builds and releases are identifiable, reproducible and approved.
• Problems and changes receive impact analysis, regression and risk review.
• Maintenance, field updates and retirement are planned before release.
• Cybersecurity activities are connected to—but not hidden inside—the software lifecycle.