The short answer
You've been tricked into asking the wrong question by a process that is not designed to actually provide you any guidance your day-to-day tasks. See the pithy Q&A on the Programmers site for a pragmatic take on this:
The "correct" (but probably useless) answer
You "follow" ISO 12207 by using the vocabulary it defines, and identifying which parts of your process map to that vocabulary. That is all.
From the ISO/IEC 12207 article on Wikipedia:
The standard has the main objective of supplying a common structure so
that the buyers, suppliers, developers, maintainers, operators,
managers and technicians involved with the software development use a
common language. This common language is established in the form of
well defined processes. (emphasis added)
To be clear, ISO 12207 never tells you how to do anything; it is completely silent on implementation details. It's just a big glossary, combined with an ideal process map. Here's a quote from a short 2002 paper on integrating ISO 12207 with the Rational Unified Process (RUP), titled "How the Rational Unified Process Supports ISO 12207":
These classes [of processes] can be organized in views, and decomposed
into activities, themselves decomposed in[to] tasks. ISO 12207 stops,
however, at the level of activities and it only occasionally mentions
specific tasks, although never in a mandatory fashion.
So, if you're performing "Module Testing" during the "Software Development" phase, congratulations: you're following ISO 12207! That's true even if you define "Module Testing" to mean flicking jelly beans at your keyboard, and "Software Development" to mean coming into the office and browsing Pinterest all day.
A slightly more useful answer
There are practical ways to approach this, if its really necessary. Here's a few I can think of. All of these have had some non-zero value for me on one or projects:
- Static analysis (as you already mentioned)
- Code inspections (peer reviews)
- Architecture reviews: comparing modules to block/UML diagrams, for example
- Inspection of the dependency injections or plugins, like Spring framework artifacts, for example
- Bill of Materials (BoM) verification: checksums, file manifests, third-party libraries, etc. Worse than useless if not automated.
And a couple that I've had to do, but never really seen any value from:
- Requirements mapping: tracking which functions or tests cover which written requirement(s)
- Functional hand-offs: formal release of build/package artifacts to QA, a.k.a. "throw it over the wall and run"