TFA-302 — Software Lifecycle Processes — ISO/IEC/IEEE 12207

← Back to the learning library

Before you begin: Read TFA-301 for standards selection and TFA-106 for configuration control. Bring an example of a change that crossed a hardware or supplier boundary.

Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.

Publication basis: ISO/IEC/IEEE 12207:2026. The examples below are Academy teaching applications, not a clause-by-clause compliance procedure.

Learning objectives

By the end of this module, you should be able to:

Explain the scope and limits of a general software lifecycle framework.
Tailor activities while preserving the evidence needed for project decisions.
Allocate supplier responsibilities and acceptance criteria.
Plan maintenance and retirement alongside initial development.

Lesson 1

1. Establish the lifecycle boundary

ISO/IEC/IEEE 12207:2026 provides a framework covering software acquisition, supply, development, operation, maintenance and disposal. Its scope includes the software portion of firmware. It supports different development approaches and does not prescribe one lifecycle model. This makes it a useful starting point for general firmware projects; it does not replace a governing sector standard or establish product certification.

For a fictional motor controller, define the product boundary before listing activities: bootloader, application, factory programmer, configuration utility and supplier libraries. Record who develops each item, who accepts it and how long it remains supported. A bootloader maintained by another team still belongs in the release compatibility assessment. A factory script that writes protection settings can affect the delivered product even though customers never run it.

Lesson 2

2. Tailor around outcomes and risk

Start with decisions that must be justified: requirements are ready to implement, interfaces are agreed, a build is fit for integration, and a release is acceptable for a defined configuration. For each decision, identify activities, records and competent reviewers. Then decide how the team’s existing backlog, repository and test system will produce that evidence.

Combining records is often sensible. One reviewed change record might contain impact analysis, updated requirements and links to regression results. Removing an activity merely because the team is small is different: its underlying risk may still need treatment. Keep a tailoring record stating what was combined, excluded or adapted, the rationale, the authority and the conditions that would trigger reconsideration. Any formal conformance claim must follow the selected publication’s actual conformance provisions.

Lesson 3

3. Make iteration produce usable baselines

An iteration can produce more than code. Suppose a two-week increment adds a sensor plausibility check. Its baseline should connect the behaviour requirement, interface assumptions, implementation revision, test results and unresolved anomalies. Mark incomplete integration evidence openly rather than describing every successful developer build as releasable.

Use separate criteria for internal integration and field release. A development build may permit diagnostic access and an unfinished recovery path; a customer release may not. Record these distinctions in build identification and access controls. When a requirement changes during an iteration, update the baseline deliberately. Otherwise a test can pass against yesterday’s acceptance criterion while today’s backlog claims the new behaviour is complete.

Lesson 4

4. Control acquisition and supplier handoffs

A purchase order for a binary does not define how the manufacturer can assess or maintain it. Agree deliverables before integration: supported targets, interface behaviour, configuration constraints, version identification, known defects, change notifications and evidence appropriate to the component’s role. Clarify access to source or alternative maintenance arrangements where long-term support depends on them.

For a supplier motor-control library, acceptance should include behaviour on invalid inputs and processor overload, not just nominal speed regulation. Assign ownership for application-level hazards, integration tests and field defect investigation. If the supplier cannot provide a requested record, document the gap and decide whether compensating assessment is credible. Supplier assurance and product acceptance remain distinct decisions.

Lesson 5

5. Define review and release decisions

A release meeting should resolve a concrete question: may this identified firmware run on these identified product variants under these support conditions? Give reviewers a concise evidence index and unresolved-issue assessment. Avoid requiring them to infer compatibility from filenames or chase a dashboard whose contents can change after approval.

Example decision	Evidence to examine	Responsible decision owner
Accept a changed peripheral driver	Interface review, target tests and affected timing analysis	Integration lead
Approve a service release	Build identity, regression results and anomaly disposition	Release authority
Accept a supplier update	Change assessment and product-specific integration evidence	Component owner

The role names are illustrative. Assign real people or controlled organisational roles, and make delegated authority explicit.

Lesson 6

6. Treat maintenance as engineering work

Field reports, component obsolescence and vulnerability disclosures all enter the lifecycle. Triage a report against affected versions, configurations and operating conditions. Preserve enough evidence to reproduce the issue without exposing customer information unnecessarily. A patch that changes only one line can still alter timing, persistent data or recovery behaviour.

For each maintained branch, define its support purpose, permitted changes and regression baseline. When a microcontroller revision changes an erratum workaround, consider both new production and already deployed devices. Record why a fix is or is not backported. Closing a ticket because the newest branch works does not resolve a defect in a supported field population.

Lesson 7

7. Plan retirement and retain the right records

Retirement decisions can affect safety, security and serviceability. A product may outlive its build server, signing certificate or original development team. Establish how final supported images, tools, configuration definitions and relevant evidence will remain recoverable. Test retrieval while people who understand the system are still available.

Define what happens when connected services end, replacement components disappear or security updates stop. The answer might involve a final offline configuration, a service migration or withdrawal from a particular use. Assign responsibility for communicating the change and maintaining any remaining obligations. A lifecycle plan is useful only when these later decisions have owners, resources and a route for updating earlier assumptions.

Decision guide

How much lifecycle control does this change need?

Change	Assessment emphasis	Proportionate record
Diagnostic wording	Confirm no protocol or user-decision impact	Reviewed change and focused regression
Scheduler or peripheral change	Timing, resource contention and affected variants	Impact analysis, design review and target evidence
Supplier binary replacement	Identity, behaviour changes and integration assumptions	Acceptance record and regression rationale
End of support	Field population, residual obligations and recovery options	Approved retirement and communication plan

Worked example

Worked example — maintenance of an industrial motor controller

Problem

A processor supplier announces an erratum affecting a low-power mode. Production boards use two silicon revisions, and service engineers maintain a third firmware branch. The team initially plans to disable sleep and run the usual unit tests.

Engineering approach

The component owner identifies affected board and firmware combinations. Systems engineering reviews power, thermal and restart implications; firmware updates the low-power design; verification measures representative operating transitions on both silicon revisions. The release authority receives a compatibility matrix and a reasoned backport decision for each supported branch. The supplier notice and changed build configuration are retained with the release evidence.

Result

The selected workaround becomes a controlled product change. The record explains which field devices require an update, why some do not, and which measurements support the decision. Passing tests is part of that rationale, rather than the entire lifecycle argument.

Engineering evidence

What should the work produce?

Lifecycle and tailoring record

Names the framework, scope, adapted activities and approval authority.

Responsibility and acceptance matrix

Assigns decisions across firmware, hardware, verification and suppliers.

Release baseline index

Connects product variants to source, tools, binaries and evidence.

Maintenance and retirement plan

Identifies supported branches, retained assets and end-of-support decisions.

Common failure patterns

What goes wrong?

Copying a large process manual without identifying who performs the work.
Calling every iteration a releasable product baseline.
Accepting supplier components without agreed evidence or maintenance arrangements.
Retiring tools before proving that supported releases can still be reconstructed.

Applied exercise · approximately 25 minutes

Tailor the lifecycle for a six-person team

A six-person team maintains a controller with an application, a supplier bootloader and a factory configuration script. It proposes keeping only code reviews and unit-test logs because there is no dedicated quality engineer.

Identify four decisions that need evidence beyond a code review.
Allocate accountable roles without inventing extra headcount.
Propose one combined change record and explain when it is insufficient.

Review a suggested approach

Useful decisions include acceptance of the supplier bootloader, approval of factory-written settings, readiness of a target integration build, and release of a supported field update. Existing team members can hold accountable roles, with appropriate competence and review arrangements. Combining roles does not make conflicting responsibilities disappear.

A change record can link the triggering issue, affected configurations, design rationale, implementation, tests and disposition of anomalies. It is insufficient when it omits a separate supplier acceptance decision, untested hardware effects or an approval required by the applicable safety framework. For this exercise, an adequate result is a small working process with explicit gaps and decisions—not a claim that a particular team structure is automatically compliant.

Completion criteria

Product and tooling boundaries are explicit.
Each decision has a named role and identifiable evidence.
Tailoring simplifies records without concealing missing activities.

This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.

Practical check

Questions for your next design review

Does the lifecycle include production, service and update tooling?
Are tailoring decisions approved and revisited when risk changes?
Can each release decision be reconstructed from stable records?
Are field branches, supplier changes and retirement responsibilities visible?

Key takeaway

A useful lifecycle framework makes engineering decisions, ownership and evidence explicit from acquisition through retirement.

References and further reading

Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.