🚀 go-pugleaf

In article <699@oliver.analogy.UUCP> cmr@oliver.UUCP (Chesley Reyburn) writes:
>
>What I was particularly looking for was information about what
>you are calling asset domain analysis. What wound up being called
>assets and what was left as implementation specific? I think that
>information like this could be important to our discussions.
  The process we are using for Asset Domain Analysis is loosely based
on work from Ruben Prieto-Diaz formerly with GTE, work by Jim Neighbors,
and Mark A. Simos. We did an analysis and selected and synthesized parts 
of all the work going on and adapted it to our perspectives. The method-
ology itself is a lot like Systems Analysis, but with a wider focus. We 
specifically look for areas and items which span application areas within
the company.
	The other starting point for the analysis is with our business
and architectural direction. Primarily seperation of functionality within
applications. Most large software houses and companies are working in that
direction, that is to seperate the user interface from the application and
to seperate the application from the data. Sounds easy but as you may know
it's not. 
	Based on this we have three major technology domains - User, Appli-
cation, and Data. We try then to identify functional components which fit
into these areas and cross application areas. As you may imagine a lot of
this is seat of the pants evaluation based on application area experts. 
>
>I am interested in what you mean by managing developer's expectations.
>Was there anything specific about this or was it just another case
>of the recipe that is going to save the world not working?
>
	By managing expectations (another of those buzz terms)
I mean that many developers when exposed to software reuse and the 
concepts we have developed expect to be handed their application programs
on a silver platter and just being able to select what they want when
actually there is a significant amount of work (actually additional work in
a way) that they must do to integrate existing assets into their programs.
They must understand the reusable component and its interfaces along with
its limitations. One of our project managers has characterized it as
going through three phases:
	1. OH WOW this is wonderful! You can do anything with reuse.
	2. It doesnt do what WE need, we cant use it.
	3. Reality. Some places this is great others we work around.

	It is important that developers understand the realities of
reusable components or this technology will follow the same curve as
4GLs and AI has.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Kenny A. Chaffin                           ...uswat!reuse!ken
U S WEST Advanced Technologies                (303) 930-5356
6200 South Quebec
Denver, CO 80231
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<