You make a good point regarding software engineering having no stable body of knowledge (apart from project management - The Mythical Man-Month?). I agree that analogies are shit, unfortunately the practice of using them to explain things is easy to pick up and hard to lose. Have you read "The cruelty of really teaching computer science" by Dijkstra? A lot of what you have said reminds me of that essay (regarding analogies). Program derivation sounds interesting, though. I'm tempted to say that that would count as "Software Engineering". Do you know anything about this?
Analogies aren't necessarily shit, you just need to keep in mind how deep (or shallow) they are. "Software engineering" is a very shallow analogy. You can use it to give laymen an idea what it is you do, but you don't want to believe it too much yourself. The predicate transformer stuff Dijkstra advocated was beautiful. Pick up a copy of David Gries's The Science of Programming if you can find it. Formal methods aren't worthwhile for programs that aren't really high risk though. Even in mathematics you only get that formal for important and hard theorems. Dijkstra was great, but he was still a product of his time, and Dijkstra's time was still a little too in love with formalism because of all the exciting stuff happening in mathematical logic in the first half of the century. By all means prove your space shuttle control system and pacemaker correct, but trivial CRUD forms are fine if they're legible and have some tests.