System Engineering in the R/D World

Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me
apologize if you don't think should be in your newsgroup. My question
is regarding the value (or importance) of System Engineering practices
in the R/D World. I work for the government and there are about 40
people in my branch. We do a lot of R/D projects as well as projects
for the testing groups. I would like to know from people in the R/D
world how important do you feel System Engineering practices are on
your job? Many of my co-workers say, "oh that's for really big
programs, we don't do that hear". Do you agree? Some believe System
engineering only pertains to the integration of the pieces of the
design. To me that is only part of SE, there's so much more. Without
being long winded, can those who work in the R/D world, could you
please give your opinions of SE in your workplace? Is it important or a
waste of time? What practices do you feel are necessary? Is SE only for
the production people? I appreciate any responses and hope I don't
offend anyone for posting my question. My intention is to gain enough
information to convince my coworkers to use some of the SE practices
I've read about.

thanks,
joe

 

[Dan Hollands]

It would help if you gave your definition of System Engineering

I spent my career in R/D, mostly with small companies, but am not sure what
you mean by "System Eng Practices"

Dan

--

Dan Hollands
1120 S Creek Dr
Webster NY 14580
585-872-2606
QuickScore@USSailing.net
www.QuickScoreRace.com


<jjlindula@hotmail.com> wrote in message
news:1123080462.346149.178820@o13g2000cwo.googlegroups.com...

Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me
apologize if you don't think should be in your newsgroup. My question
is regarding the value (or importance) of System Engineering practices
in the R/D World. I work for the government and there are about 40
people in my branch. We do a lot of R/D projects as well as projects
for the testing groups. I would like to know from people in the R/D
world how important do you feel System Engineering practices are on
your job? Many of my co-workers say, "oh that's for really big
programs, we don't do that hear". Do you agree? Some believe System
engineering only pertains to the integration of the pieces of the
design. To me that is only part of SE, there's so much more. Without
being long winded, can those who work in the R/D world, could you
please give your opinions of SE in your workplace? Is it important or a
waste of time? What practices do you feel are necessary? Is SE only for
the production people? I appreciate any responses and hope I don't
offend anyone for posting my question. My intention is to gain enough
information to convince my coworkers to use some of the SE practices
I've read about.

thanks,
joe

 

[Tim Wescott]

jjlindula@hotmail.com wrote:

Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me
apologize if you don't think should be in your newsgroup. My question
is regarding the value (or importance) of System Engineering practices
in the R/D World. I work for the government and there are about 40
people in my branch. We do a lot of R/D projects as well as projects
for the testing groups. I would like to know from people in the R/D
world how important do you feel System Engineering practices are on
your job? Many of my co-workers say, "oh that's for really big
programs, we don't do that hear". Do you agree? Some believe System
engineering only pertains to the integration of the pieces of the
design. To me that is only part of SE, there's so much more. Without
being long winded, can those who work in the R/D world, could you
please give your opinions of SE in your workplace? Is it important or a
waste of time? What practices do you feel are necessary? Is SE only for
the production people? I appreciate any responses and hope I don't
offend anyone for posting my question. My intention is to gain enough
information to convince my coworkers to use some of the SE practices
I've read about.

thanks,
joe

In the companies where I've worked, and in most other companies, if no

one knew exactly what you did but they knew you were valuable they
called you a "systems engineer". Some of these people ended up either
doing or coordinating the design tradeoffs between hardware, software,
mechanical, etc.; others couldn't engineer their way out of a paper bag,
but were good for dealing with certain esoteric problems that required
large brains.

So you'll have to define "systems engineering practices" for us.

In most places where it needs to be done the design tradeoffs between
disciplines that I'm speaking of tend to be done by the project manager,
or they happen by committee, with electrical, software and mechanical
engineers getting together and hashing things out. If the project
manager is smart and/or if the committee gets together well then this
can make for some very good systems designs. Unfortunately it's a chain
that's weaker than its weakest link, so you have to be careful.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[jjlindula@hotmail.com]

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m still
learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

 

[John Larkin]

On 3 Aug 2005 07:47:42 -0700, jjlindula@hotmail.com wrote:

Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me
apologize if you don't think should be in your newsgroup. My question
is regarding the value (or importance) of System Engineering practices
in the R/D World. I work for the government and there are about 40
people in my branch. We do a lot of R/D projects as well as projects
for the testing groups. I would like to know from people in the R/D
world how important do you feel System Engineering practices are on
your job? Many of my co-workers say, "oh that's for really big
programs, we don't do that hear". Do you agree? Some believe System
engineering only pertains to the integration of the pieces of the
design. To me that is only part of SE, there's so much more. Without
being long winded, can those who work in the R/D world, could you
please give your opinions of SE in your workplace? Is it important or a
waste of time? What practices do you feel are necessary? Is SE only for
the production people? I appreciate any responses and hope I don't
offend anyone for posting my question. My intention is to gain enough
information to convince my coworkers to use some of the SE practices
I've read about.

thanks,
joe

What is "System Engineering" anyhow? If you mean someone who plans
high-level designs without detailed knowledge of the underlying
technology, my company certainly has nobody like that, and my
customers, gigabuck big-science projects and aerospace companies,
don't seem to either, as far as I can tell. The people who do the
highest-level thinking, the grand architectures and the new ideas,
seem to be just the best of the technologists.

John

 

[steve]

I think the bigger the project the more you will need systems
engineers, in smaller projects the typical system tasks (requirements
definition, interface specifications, trade studies, test plans
procedures, spec compliance verification, test equipment integration,
debugging high level field integration problems) usuallly are
integrated into the software/hardware engineers work schedule. If you
tried to force the creation of a systems engineer position is a small
project you probably would need to create unnecessary busy work to keep
him/her employed (forcing the generation of unneeded documents). As
projects get bigger these functions are too much for the
software/hardware engineers to support and the creation of a formalized
system engineering function becomes necessary. The majority of systems
work is customer/production related, so R/D has much less need for
dedicated systems people, just my opinion.

 

[Martin Eisenberg]

Tim Wescott wrote:

In most places where it needs to be done the design tradeoffs
between disciplines that I'm speaking of tend to be done by the
project manager, or they happen by committee, with electrical,
software and mechanical engineers getting together and hashing
things out. If the project manager is smart and/or if the
committee gets together well then this can make for some very
good systems designs. Unfortunately it's a chain that's weaker
than its weakest link, so you have to be careful.

What do you mean by that, "weaker than its weakest link"?

--
Quidquid latine dictum sit, altum viditur.

 

[Frank Bemelman]

<jjlindula@hotmail.com> schreef in bericht
news:1123080462.346149.178820@o13g2000cwo.googlegroups.com...

Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me

This is stuff you want to discuss with Guy Macon. He hangs
around in misc.business.product-dev

And of cource it is 100% waste of time, only invented
by 'managers' to hide their incompetence.

--
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)

 

[Genome]

<jjlindula@hotmail.com> wrote in message
news:1123080462.346149.178820@o13g2000cwo.googlegroups.com...

Hello,

[snip]

thanks,
joe

I think I can gaurantee that when you try to define and analyse it you will
lose it having not found it in the first place.

DNA

 

What?

 

[Tim Wescott]

Martin Eisenberg wrote:

Tim Wescott wrote:


In most places where it needs to be done the design tradeoffs
between disciplines that I'm speaking of tend to be done by the
project manager, or they happen by committee, with electrical,
software and mechanical engineers getting together and hashing
things out. If the project manager is smart and/or if the
committee gets together well then this can make for some very
good systems designs. Unfortunately it's a chain that's weaker
than its weakest link, so you have to be careful.


What do you mean by that, "weaker than its weakest link"?

It's just a cynical observation that the stupidity of a group can be

equal to the sum of the stupidities of the participants.

I have seen this sort of design by committee go both ways, so I
shouldn't be cynical. If the group is aware of the pitfalls and not
afraid of constructively criticizing each other's work then the results
can be superior to what any individual could do by him/herself. If,
however, the group has even a few jealous empire-builders then the
effort tends to collapse upon itself.

Similarly, if an insecure project manager does the systems engineering
then the system design will often be bounded by the project manager's
limitations plus the limitations of the group. If the project manager
isn't afraid of other people in the group knowing more than he then the
system design will be strong everywhere that anyone in the group is
strong; if the team's _really_ good they'll recognize their weaknesses
and either change the design to avoid them or get external help in those
areas.

I've been named "system architect" on more than one project, and I've
always been profoundly grateful to the folks that have caught out my
errors. I always let folks know this, too -- and not just the folks
finding my errors, but their managers as well. At worst the equation
goes like this: I do something stupid, you notice and don't say
anything; we both look bad. Alternately: I do something stupid, you
point it out, we both fix it; we both look good.

The best thing about this attitude is that it is one of the areas where,
with the right PR, ethical behavior and selfish behavior march hand in
hand. When I can say "Ralph found an error in my system design, I did
some analysis and found out that my integrator wasn't nearly deep enough
for the modified filter" then the project wins because an error has been
fixed, Ralph wins because he's gotten credit for finding a problem, I
win because I found a solution, _and_ I win because an embarrassing
problem with my design was found at an early stage instead of in front
of some Major in procurement who really wanted to buy the competitor's
product instead.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[martin griffith]

On Wed, 3 Aug 2005 18:17:55 +0200, in sci.electronics.design "Frank
Bemelman" <f.bemelmanq@xs4all.invalid.nl> wrote:

jjlindula@hotmail.com> schreef in bericht
news:1123080462.346149.178820@o13g2000cwo.googlegroups.com...
Hello, I couldn't find a single newsgroup to post my question, but I
needed a good group of people to post my question to. So let me

This is stuff you want to discuss with Guy Macon. He hangs
around in misc.business.product-dev

And of cource it is 100% waste of time, only invented
by 'managers' to hide their incompetence.
Dont forget that valuable resource

www.dilbert.com


martin

 

[John Larkin]

On 3 Aug 2005 08:41:27 -0700, "jjlindula@hotmail.com"
<jjlindula@hotmail.com> wrote:

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m still
learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

So where does the systems engineer fit into the organization? Who does
he report to, who reports to him, and how much authority does he have?
Does he have to sign off on stuff?

John

 

[Jim Thompson]

On Wed, 03 Aug 2005 10:26:56 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On 3 Aug 2005 08:41:27 -0700, "jjlindula@hotmail.com"
jjlindula@hotmail.com> wrote:

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m still
learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

So where does the systems engineer fit into the organization? Who does
he report to, who reports to him, and how much authority does he have?
Does he have to sign off on stuff?

John

My experience has been that the best systems are architected by a
single person, not by committee.

The EARLY Pentiums were architected by a single person. Need I say
more ?

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Ban]

jjlindula@hotmail.com wrote:

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m
still learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

At least you can get some job when you somehow do plan these things, it
would probably more useful with new people or an unexperienced work group.
Many of the procedures fall now into different peoples responsibility, not
everyone will react delightful when you take his tasks away. For the NASA it
will be more beneficial than for a specialized nice-market company, that has
simply not the money to pay another engineer sitting in his office.
OTOH this is the ideal function for outsourcing to a consultant.
--
ciao Ban
Bordighera, Italy

 

[Harry Dellamano]

"Jim Thompson" <thegreatone@example.com> wrote in message
news:tqv1f19en0pj7rclndiq6r8uvn0mbg3uho@4ax.com...

On Wed, 03 Aug 2005 10:26:56 -0700, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On 3 Aug 2005 08:41:27 -0700, "jjlindula@hotmail.com"
jjlindula@hotmail.com> wrote:

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m still
learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

So where does the systems engineer fit into the organization? Who does
he report to, who reports to him, and how much authority does he have?
Does he have to sign off on stuff?

John

My experience has been that the best systems are architected by a
single person, not by committee.

The EARLY Pentiums were architected by a single person. Need I say
more ?

...Jim Thompson

System engineering is not need if the design group all pee in the same
urinal. Information flow is perfectly terminated with no reflected waves.
Notice I did not say design team, they have leaders that don't comprehend
the task.
Oh, don't get me started!
Harry

 

John,

Hello, I didn't say that one project needs to assign a System Engineer.
I'm only concerned that the individuals or project lead follow System
Engineering practices. What I have seen where I am working, is that the
engineer will get the requirements from the customer, then go off into
his/her cubical, design the widget, and then deliver. Many times the
widget doesn't meet the customer's requirements or a nightmare to
program due to hardware limitations. Many of my co-workers say, we
don't follow SE practices because our designs are small (their
opinion). I'm trying to encourage them that you can apply some of the
principles of SE, for me to achieve this I need to see what people in
the R/D world are doing, are they using SE?

joe

 

[Stan Pawlukiewicz]

jjlindula@hotmail.com wrote:

John,

Hello, I didn't say that one project needs to assign a System Engineer.
I'm only concerned that the individuals or project lead follow System
Engineering practices. What I have seen where I am working, is that the
engineer will get the requirements from the customer, then go off into
his/her cubical, design the widget, and then deliver. Many times the
widget doesn't meet the customer's requirements or a nightmare to
program due to hardware limitations. Many of my co-workers say, we
don't follow SE practices because our designs are small (their
opinion). I'm trying to encourage them that you can apply some of the
principles of SE, for me to achieve this I need to see what people in
the R/D world are doing, are they using SE?

joe

In my experience, folks who do R&D (which can mean differerent things to

different people) tend to be messy desk types who prefer to live that
way. SE tends to put some discipline in the process which can be good.
There are things out there like being able to integrate matlab with
tools like CVS that can help smallish groups.

 

[Fred Marshall]

<jjlindula@hotmail.com> wrote in message
news:1123083687.394543.131660@g49g2000cwa.googlegroups.com...

Hello, to be brief SE involves

Here is a quick reaction to the list:

requirements analysis - the system guru's job for the technical things which
can be the whole thing - a marketing / engineering job to trade off feature
cost / benefit. (Sales will want everything tomorrow). I've never seen the
latter really work but it might in concept.

risk managment - what kind of risk? Market risk? Technical risk?
Financial risk? Schedule risk? etc. etc. I've seen engineering risk
analysis presented that included likely cost/schedule impacts and mitigation
actions for the biggies. Only for larger systems. Silly risks are avoided
by good engineering - like not choosing to use weird parts, avoiding tricky
calibration in the design, etc.

controlling your design processes - isn't there a VP Engineering to set
policy? Isn't there a way to communicate what's working and not working?
It must be a really overdone project to need a *person* dedicated to this.

interface control - yeah, on really big, diverse developments. Otherwise a
pari of drawings / specs just need to be coordinated and kept in sync.
(I once worked on a project as a young engineer ... gee maybe I was the
"system engineer" ... I was responsible for an autopilot - which, as you can
imagine, was a major system block / module. The system was being built down
the street by a large aerospace company. I got a call from a fellow who
wanted to better understand one of the components that was used in the
autopilot - so I drove over to discuss it with him. Lo and behold, the guy
had *no* idea about how the component was being used in the autopilot -
none. It was really hard to have a cogent conversation and was really hard
to help him).

supportability - a worthy area of endeavor. Best done by someone who
understands the infrastructure and the end-use needs where the product will
live. Better be done up-front. Suggests the system guru again.

realiability - when the "system" is a single FPGA you are kinda stuck aren't
you? Post-design it's nice to keep track of what's breaking so you might
actually fix something. I can remember a lot of times when a customer would
have a problem and somebody inside our company would say: "oh yeah, I
remember that came up about six months ago" (and nothing had been done).
It's nice to be able to try to decide what to fix and what not to fix before
some system comes crashing down in the middle of a critical situation.
Rarely affordable to have a "person" except in aerospace. Not to say that
you can't design for good or bad reliability .... but a statistician
probably isn't going to have much of an impact in the design choices unless
you're going to spend a whole lot of time in meetings and to hell with the
schedule.

maintainability - how is this different from supportability really?

reproducability - I think you mean produceability. Just part of good
engineering with adequate discussion with the manufacturing folks. Not a
special discipline / position.

peer reviews and technical reviews - part of process. No "person" needed.

test planning - sometimes a specialist can be helpful - particularly in
software. In hardware it requires someone who really knows what's being
tested - as in the system guru or the senior designers?

integration planning - the system guru takes the lead and, unless the guru
does it all alone (which is common) then it's a group activity.

manage a project to control costs, schedule, and performance - AKA the
Project Manager who is best also the lead engineer or some other effective
manager - but not necessarily the system guru. Sometimes there can be staff
support (in aerospace again) but it's not all that helpful to the real
manager / management in my opinion. I always do it myself so the planning
work gets done when it's needed and not just automatically because it's
someone's assignment. "Tracking" to an original plan is a guilt trip except
on very large projects where BCWP, ACWP etc. are used as indicators where
figuring things out otherwise would be difficult. Above all, figuring out
how to get from *today* to the end most efficiently / quickly is useful.
(Presumably there is somebody who can recognize the situation and take
corrective action if there are weak players - without resorting too much to
the "measures").

And you didn't mention "performance measures". I may have had a bad
experience or two but I've never seen a situation where "performance
measures" were anything but mostly mindless obedience exercises. I'm told
that some have great success stories (ala Deming, Juran, Taguchi...) but not
me! This could segue into a discussion of general QC which I'd rather not
get into..... If there were something akin to "system engineering" that
might actually be useful to put some energy into, it could be lurking there.

To make a point:
It is told that a Japanese company licensed the production of an American
engine. They took the original drawings and began production. But they
couldn't build engines with those drawings! Why? Because at that time, the
Japanese built all the parts to exceptional tolerances so there could be
virtually 100% interchangeability. And, because at that time, the Americans
had built the parts to looser tolerances and were willing to do some mixing
and matching of parts, they didn't recognize that the dimensions in the
drawings were "wrong" - that is, a working engine could not be assembled out
of a set of parts that were perfect according to the drawings. I don't know
if the story is true but it's sure interesting.....

Fred

 

Stan,

You hit the nail right on the head. That is what my work environment is
like. No discipline at all. I'm trying to add some process control and
not having much success with the older more experienced engineers. But,
the younger engineers are very excited because following SE practices
allows them to help manage complexity, which is good.

thanks again,
joe