From: Dani Eder (email@example.com)
Date: Thu May 19 2005 - 08:37:19 MDT
> The SIAI approach relies on achieving complete
> understanding of how
> the design works before building it. This means
> specifying global
> behaviour first and breaking that down into
> progressively more local
> behaviour until you have code.
In the aerospace industry in which I work, this is
a part of the methodology we call 'systems
The methodology as a whole is used to make it
possible to do complicated projects like missile
defense or the Space Station.
The breaking down of a complex design into simpler
components is only one part of what you have to do
if you want a reasonable chance of the final design
to do what you want it to.
You start at the top level by describing what it
is you want the thing to do, in some detail. We
call it a requirements document. Then you go through
several levels of breaking the requirements into
smaller sets and assigning them to systems,
subsystems, assemblies, etc. Each time you break
the design into smaller pieces, you now have to
define the interfaces between the pieces, and
maintain traceability up and down the tree of
Once you have broken the system into manageable
pieces, you can then proceed to design the pieces,
build them, and then test that they actually meet
the requirements that were specified at the lowest
level. You assemble and test at progressively
higher levels until finally you test the complete
system as a whole. It is the discipline of
defining the requirements at each level and testing
against those requirements at each level that
constrains the design process. That way the final
product has a reasonably high chance of working
and doing what you wanted it to.
It's not a perfect process. In the initial
requirements for the Space Station (on which I work),
there was a requirement for a 'Snap Freezer' to
freeze specimens that had been generated onboard
the Station for later analysis on the ground. The
requirements as specified were physically impossible
to meet. Even if the freezer was at absolute zero,
the sample wouldn't have cooled fast enough to meet
the written requirement, so the requirement had
to be changed to something possible. So there is
a feedback up and down the tree as the definition
and design is done. But you have to be careful
that any changes to the requirements and design
are propagated through the tree so that (a) the
overall system still does what you wanted it to,
and (b) the pieces will still work together.
The methodology takes a lot of manpower to implement,
but it is the best way we know of to design things
that are too complicated for a single person or
a small team to do.
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:51 MDT