Re: For N. Korean Missile, U.S. Defense Is Hit or Miss
- From: "cliff84373@xxxxxxxxxxx" <cliff84373@xxxxxxxxxxx>
- Date: 29 Jun 2006 09:25:15 -0700
Islander wrote:
cliff84373@xxxxxxxxxxx wrote:
Glenn wrote:One of the things that we have learned in engineering design of both
On Mon, 26 Jun 2006 20:59:44 -0700, cliff84373@xxxxxxxxxxx wrote:
In a previous life, I actually wrote a lot of software (Fortran) before
I switched over to hardware. I used to come home from work and dream up
unlikely scenarios and oddball inputs to test the software with. The
software I wrote in the mid 70's actually had a Y2K check included in
it. If there's one thing most programmers really hate to do, though, its
test their own software or deliberately look for bugs.
There are also interesting problems with hardware that can't be detected
with reliability calculations or testing.
Here's a rather mundane and simplified example. A design engineer
specifies a transistor with a beta of 100, but the circuit actually
requires a transistor with a minimum beta of 115. Now, assume that all
of the first batch of beta-100 transistors purchased just happen to have
a beta greater than or equal to 115, but some of the second batch does
not. That's not an unusual situation, by the way.
Now here's a scary thought. Say that all the lab and field testing is
done with the first batch and the second batch is used in actually
defense deployment. Then North Korea launches a missile at San Francisco
and we fire some interceptors and they miss because of an incompetent
engineer with an attitude and/or incompetent management and/or a
contractor with corporate attitude problem.
Americans would do well to spend less time breaking French wine bottles
and more time putting the spotlight on things that really do threaten
our national security.
Your hardware problem was addressed by worst case analysis, my first job
after school. The software problem was addressed by the waterfall model
of using feedback to the requirements, specifications, design, code, test
specifications, test cases, testing from unit through integration and
finally selected customer sites. We didn't land on and return from the
moon by doing business as you apparently think we did. Unfortunately
these ridged processes have fallen to competitive pressure of throw it
over the wall and fix it if the money dries up.
--
Glenn
In the last job I had, we had a group of college kids come in with the
assignment to review our current project. They only reviewed mechanical
design. So, I was off the hook. I'll be damned, though, if those kids
didn't nail our mechanical designer with some types of problems that I
had been tempted to tell him about for years.
That might be one approach to solving the problems caused by careless,
lackadaisical, design engineers. It has a lot of advantages since the
critique comes from outside and the problem with bruised egos is
minimized.
hardware and software is that it is impossible to adequately specify
systems that are complex. This was a major failing of software
engineering where we built beautifully engineered systems that solved
the wrong problem.
Over the past 20 years or so, we have moved to rapid prototyping and
iterative refinement. The objective is to get a prototype put together
as quickly as possible for testing in an environment as close to reality
as possible and to then iteratively refine the design as we learn its
weaknesses. This was the approach that I used with students in my
former life and we would go through several iterations before converging
on a satisfactory solution.
I remember an engineering business trip to an HP computer facility,
years ago, I was anxious to get as many tips on quality as I could
since HP had such a great reputation with quality (at least at that
time). I asked one of the designers how many prototypes they were
allowed and he said, "two". I was sort of shocked since I thought it
would be more than that. I'm still wondering to this day if he was
pulling my leg.
Speaking of pulling one's leg, I also asked a Compliance Engineer about
EMC, hoping to get some inside emissions control tips. His answer was
that they base their EMC designs on "Maxwell's Equations". I took that
as a none-of-your-business answer since there's a formidable chasm
between the abstract theory and practical implementation with EMC
design.
EMC design, though, is an example, of learning with testing and through
practical experience. In house expertise in this area probably goes
back to decades of experience with some companies. When companies are
blazing new trails, though, like we always were, or with the case of
anti-missle technology, my guess is that quality design depends on
quality management and quality engineers coupled with a lot of testing,
of course.
Unfortunately, companies will often put a product in the market before
this process is completed and the customer pays the price for being the
tester. This is a chronic problem in the computer industry, for example.
This is a major problem for defense systems where the government is
still trying to write the perfect RFP, an impossible ambition, and
alternatively cannot create an effective way to do the testing that is
needed for iterative refinement in real world situations.
.
- Follow-Ups:
- Prev by Date: Re: Pew Research Poll
- Next by Date: Re: Fear and Posing in Baghdad
- Previous by thread: Desalination
- Next by thread: Re: For N. Korean Missile, U.S. Defense Is Hit or Miss
- Index(es):
Relevant Pages
|
