Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.stsci.edu/~jordan/other/ALSD.html
Дата изменения: Mon Nov 20 23:07:48 2000
Дата индексирования: Tue Oct 2 05:33:31 2012
Кодировка:
Поисковые слова: m17
Akin's Laws of Spacecraft Design
Engineering is done with numbers. Analysis without numbers is only an
opinion.
To design a spacecraft right takes an infinite amount of effort. This is why
it's a good idea to design them to operate when some things are wrong .
Design is an iterative process. The necessary number of iterations is at least one
more than the number you have currently done. This is true at any point in time.
(Miller/Jordan's Law) Three points determine a curve . . . approximately.
At the start of any design effort, the person who most wants to be team
leader is least likely to be capable of it.
In nature, the optimum is almost always in the middle somewhere. Distrust
assertions that the optimum is at an extreme point.
The previous people who did a similar analysis did not have a direct
pipeline to the wisdom of the ages. There is therefore no reason to believe
their analysis over yours. There is especially no reason to present their
analysis as yours.
The fact that an analysis appears in print has no relationship to the
likelihood of its being correct.
When in doubt, document. (Documentation requirements will reach a maximum
shortly after the termination of a program.)
Space is a completely unforgiving environment. If you screw up the
engineering, millions of dollars of equipment is lost or somebody dies (and
there's no partial credit because most of the analysis was right...).
Not having all the information you need is never a satisfactory excuse for
not starting the analysis.
When in doubt, estimate. In an emergency, guess. But be sure to go back and
clean up the mess when the real numbers come along.
Sometimes, the fastest way to get to the end is to throw everything out and
start over.
There is never a single right solution. There are always multiple wrong
ones, though.
Design is based on requirements. There's no justification for designing
something one bit "better" than the requirements dictate.
(Edison's Law) "Better" is the enemy of "good".
The ability to improve a design occurs primarily at the interfaces. This is
also the prime location for screwing it up.
Past experience is excellent for providing a reality check. Too much reality
can doom an otherwise worthwhile design, though.
The odds are greatly against you being immensely smarter than everyone else
in the field. If your analysis says your terminal velocity is twice the
speed of light, the chances are better that you're screwed up than that
you've invented warp drive.
A bad design with a good presentation is doomed eventually. A good design
with a bad presentation is doomed immediately.
(Larrabee's Law) Half of everything you hear in a classroom is crap.
Education is figuring out which half is which.
The schedule you develop will seem like a complete work of fiction up until
the time your customer fires you for not meeting it.
It's called a "Work Breakdown Structure" because the Work remaining will
grow until you have a Breakdown, unless you enforce some Structure on it.
(Bowden's Law) Following a testing failure, it's always possible to refine
the analysis to show that you really had negative margins all along.
Your best design efforts will inevitably wind up being useless in the final
design. Learn to live with the disappointment.
(Mar's Law) Everything is linear if plotted log-log with a fat magic marker.