Large Systems Decomposomposition

Large Systems Decomposomposition

[SAHARBAUGH]

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        
-----------