From: SAHARBAUGH@ROO.FIT.EDU
Subject: Large Systems Decomposomposition
Date: Fri, 13 Sep 1991 08:26 EDT [thread overview]
Message-ID: <9109131228.AA21838@ajpo.sei.cmu.edu> (raw)
David Weller writes:
-I'm looking for folks that have some experience with breaking down
-a huge system into "less-huger" components (large units). The
-reason I ask is this: Many of our employees (of a nameless company for
-obvious reasons) are confused about the deluge of OOA materials
I have such experience and I have often encountered confused
employees (often I am one of them).
I have a two step drill that has never let me down.
1. Understand the customer's requirements
2. Divide and Conquer (some call it partitioning)
Repeat steps 1 and 2 until time or money are exhausted (you will
never be "done")
In step 1 do such things as read the contract or request for
proposal or whatever the customer has provided to express their
desires. Obtain and read the referenced documents recursively. Talk to
the customer, read books, papers etc. to obtain maximum "Domain
Knowledge". ( I refer to the " U word", Understand the customer's problem)
Regarding partitioning (which is David's original concern) study
the documents and extract all of the partitioning requirements before
beginning to partition. These might include: Staged Operational
Capability, Security, Testability, Functionality, Logistic Support,
Reliability, Maintainability, Portability, Cost, Schedule,
Transportability,
Interoperability, Quality, User skill level etc. etc.
Now list all of your design freedom, i.e.:, what choices can you
make that are not dictated by requirements.
Now consider alternate architectures (if you have that freedom)
and begin recursively partitioning and allocating the above mentioned
requirements to architectural elements along with requirements you
self-impose (derived requirements) due to the design decisions you
have made.
You WILL encounter conflicts. Design choices will often conflict
with at least one requirement. You must do tradeoff analyses. You
must make tough decisions with which someone will disagree.
Its a rotten job - and I love it!
Oh yes, I almost forgot; Where you have the design freedom to do
so, you can make an object oriented model of certain things. I find that
an object oriented model is usually applicable and useful inside an
information processing architectural element. I have NEVER
encountered a systems customer who spoke of objects. They speak of
functions, cost, return on investment, ease of use etc., just as I do when
I consider buying a system (don't you?)
David goes on to say:
-My inclination is simply to not get hung up on object-orientedness
-and encourage our staff to focus on specifying the "Real-World"
-things and what they are expected to do (in relationship to each other
-if necessary). I want them to defer the "meaty" stuff of OOA to a later
-phase, preferably the smallest pieces of this initial analysis,
Right-on David, Trust your instincts
sam harbaugh saharbaugh@ROO.FIT.EDU
-----------
reply other threads:[~1991-09-13 12:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox