"Software Engineering" as scope limitation?

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I noticed two things about "Software Engineering" in today's scope.

First, pet peeve: coders traditionally didn't design stuff.  Software development is more than "coding" and while there is still code-monkey style of development, experienced programmers tend to have more responsibility than that.

OK, more substantively, we may be talking about system engineering of information technology applications.  Here's what it says in the PbD Foundational Framework document statement of purpose:

"[Provide practical tools] to direct and inform decisions in the design of an information technology, business process, physical space and networked infrastructure to ensure that both privacy and ‘business’ functionality are built in from the outset ... " with "focus on respect for the individual, and a[n] user-centric approach."

Although that has me think of system engineering, not software engineering, it is interesting that a technology primarily applicable to software design methodology, UML, is emphasized.  That's no crime, but it tends to be more inward looking than outward looking, in my experience.  

If the use cases treat the system in context, that might be acceptable.  It is not intrinsic to the tool, only in its appropriate use for higher-level architectural considerations.

I'm not lobbying to remove "software engineering" as some sort of boundary on what is in scope, so long as it is understood what boundary is being created.  Finally, software engineering is about process methodology, not just the technical content.  In that respect, "PBD-SE" is an appropriate designation.

 - Dennis

PS: I was once an user of a Univac computer system.  Is there a place where "user" is pronounced as if not starting with a vowel?