In general, software isn't manufactured wrong. When the software is created (programmed), defects can be introduced as you described by either faulty implementations or by bad specifications. Faulty implementations are detected by testing the software. Testing takes many forms; unit testing is one of the more basic forms, where individual functions of the underlying programming code is tested to see if it is implemented correctly. This can scale upwards when doing system and integration testing where larger pieces of the software is coupled together to see how it performs as a whole. But simply testing the code at this level doesn't catch everything. Writing a program is rarely about getting it to do what you want it to do, it's mostly about handling all the strange edge-cases and failure scenarios. And this is where most software fail.
To guard against such cases, you can run through audits, simulations, static code analysis and lots of other forms of inspections and testing.
Faulty specifications is a different beast, where you have to rely on documentation. In a perfect world each requirement must be documented to a level describing why the requirement exists, and any input and output that should result from it if applicable. Specifications are developed by multiple people to guard against one person forgetting something, or wrongly interpreting something, but this doesn't catch everything either.
To add another level of protection against software defects, you add multiple instances of the system, and you also have a team create their own version of the systems, preferably on different hardware. You can then divide responsibility of certain subsystems and spread it out among the various computers running the system, adding another level of redundancy as well as to lessen the computational load on each computer, and the risk that any parts of the system interact in unforeseen ways.
The Fast Company had an excellent writeup on the process of writing software for the space shuttle. Although it isn't directly related to neither Airbus or Boeing, it gives an insight into how the process worked and what it resulted in.