The IEEE is trying to codify software engineering practices into the Software Engineering Body of Knowledge (SWEBOK). Martin Fowler glanced at it a few months ago, and he's not too fond of it:
So how flawed is the Swebok? This is a busy month for me, so I haven't had time to dig into it in any detail. Just reading a few sections is enough to raise a few red flags, and certainly to confirm the view that Swebok puts undue emphasis on plan-driven development, to a degree that rules out agile approaches.Yep. We're in a young field. We're still finding our way around in the dark.[...]
The process section relied heavily on the notions of measurement based control, which is seriously flawed since I've observed that measuring productivity is impossible. It's clearly strongly based on Scientific Management principles, and as such utterly ignores the role of people and human interaction issues in process. Again since Individuals and Interactions trump Process, this is a huge hole in the body of knowledge.
The requirements section concentrates on producing a comprehensive System Requirements Specification prior to commencing development - again very much waterfall thinking. (Interestingly it shows a spiral model picture - but only for producing the requirements document!) There's no sense of exploring cost trade-offs in requirements - in my view a vital element of any requirements work.