[lug] software engineering

[David Morris]

On Thu, Nov 30, 2006 at 12:41:49PM -0700, bgiles at coyotesong.com wrote:
> > On Mon, Nov 13, 2006 at 05:32:43PM -0700, Bear Giles wrote:
> >> The levels where it starts getting difficult?...
> >> they're management, not engineering. Don't get me
> >> wrong, it's usually still people on the engineering
> >> side of the house, but when you're trying to make sure
> >> 14 teams are all working on the same problem that's a
> >> management issue, not something you solve with your
> >> grandfather's slide rule.
> >
> > The concept you're striving for here is Systems
> > Engineering, a field newer than even software
> > engineering.  At least as an official engineering
> > discipline, people have *done* it for quite some time
> > with varying degrees of success.
> 
> It's still a management issue to get the shareholders to
> buy into this need and to keep everyone in sync.
> Otherwise you get individual teams - and their sys
> analysts - doing their own thing anyway since they're sure
> they understand the project better than those other guys
> who only stop by occasionally.

In part, yes.  However, a systems engineer (SE below) who
"only stop by occasionally" has already failed in his
job.  The SE needs to be working just as closely with the
individual teams as the team members work with each other.
If this is not possible, it is an indication that there are
too few SEs on the project.

> The problem, of course, is that we all have ample war
> stories about clueless management that really didn't
> understand the problems and were unwilling to listen to
> the people who did.  Doing what they asked would either be
> impossible or would not solve the larger problem (as we
> understood it).

This is exactly why SE is needed.  The skills needed to
manage a large project have nothing at all to do with the
skills needed to implement the details of a project, which
is what leads to the "clueless management" syndrome.  This
gap which makes the transition from implementation teams to
large-scale management is where systems engineering fits in.
Note this is different from the management structure within
a project, those managers are looking after their team's
interests, not necessarily project details.

I suppose I over-simplified in my original message, the SE
role must go beyond just "why".  The SE coordinates the
diverse "how" answers of each team and provides a high level
view for management.  On a small project, the project
manager can fulfill this role with the right set of skills
because, as you noted, a (small) part of SE is management.
The larger the project, however, the greater the need to
separate the roles.

What is just being realized, I think, is that the size of
the project which can greatly benefit from a dedicated SE
presence is actually fairly small.

--David