1 may be true at some companies, but it’s by far not the case for the great majority of software companies. Furthermore, while it’s nice if managers are broadly

1 may be true at some companies, but it’s by far not the case for the great majority of software companies. Furthermore, while it’s nice if managers are broadly familiar with software engineering, it doesn’t bring any benefits for them to code or ship software. On the contrary, they’re more likely to annoy the actual people doing those tasks. And while the hype for 2 may have died down, it did so because OOP became the mainstream. Which means that more documentation not less is needed. 3 is not related to UML. UML is a design and documentation language, it’s not pertinent to mitigating defects. 4 is also inapplicable. UML is once again not a QA technique. 5 is also inapplicable for the same reasons as above. Honestly it looks like you listed more or less five random things which changed since UML’s heyday…