ken@reuse.USWEST.COM (Kenny A. Chaffin) (05/11/89)
In a mail message from Chesley Reyburn he asks about the experiences in software reuse at U S WEST. Here are some short hopefully to the point answers. >Are you at liberty to talk about you experiences (did anything >worth telling us about happen)? I not sure of the detail you are looking for but I was not directly involved in the design and coding of the modules. We did produce guidelines for what reusable software assets are and the various flavors(which may or may not be generally relevant) in the IBM MVS/COBOL world. Much of the effort, as you may guess has been in defining and determining what is reusable and how, etc. As it turns out we worked with a particular project and ended up with several versions of the assets(our term for reusable software). The biggest problems seem to be in the area of determining what functionality is appropriate to place into a general purpose asset. Also managing the expectations of the project developers is important. They typically expect all or nothing. > Were you able to develop any recognizable, transferable, >methodology (can you tell us how you did it)? We are still working on establishing a reusable software methodology which works in conjunction with the existing development methodologies. We have developed a preliminary domain analysis methodology (my area of work) which helps in identifying reuse opportunities. We have standards regarding documentation, high-level designs, etc which guide the process but we are still struggling to formalize the entire process. >Have you-all published anything about your experiences (if so, >did you write it up and where)? Currently we have not published but are working up a couple of articles for submission to ACM or IEEE. Ken Chaffin at U S WEST Software Assets group
cmr@analogy.UUCP (Chesley Reyburn) (05/12/89)
In article <229@reuse.USWEST.COM> ken@reuse.USWEST.COM (Kenny A. Chaffin) writes: > >... Much of the effort, as you may guess has >been in defining and determining what is reusable and how, etc. >As it turns out we worked with a particular project and ended up >with several versions of the assets(our term for reusable >software). The biggest problems seem to be in the area of >determining what functionality is appropriate to place into a > >We have developed a preliminary domain >analysis methodology (my area of work) which helps in identifying >reuse opportunities. We have standards regarding documentation, Ken, Thaks for sharing your experiences with us. I am looking forward to reading about them. 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. One thing that I would like to see this group do is to come up with a list of things (functions, data structures, what have you) that we can all agree on as being essential subjects for software components (assets, ICs, etc.). For years I have been tanatalized by the idea of an LS7400 which is a bunch of NAND gates which are made up of transistors, which are made up of... and just how in the hell was I going to do something that definate, that flexible, in software? OOP seems to lead in that direction. People always use sorting or matrix multiplication as examples of software components. What else is there? I am currently working on a schematic capture editor. Things that we use as common functions are graphical operations, textual menu operations and regular expression evaluation. Now that I think of it, these are all things that are supplied by the operating system or grafix libraries. Hmm... Then what we are talking about is maybe extending that analogy into what is sometimes called the 'application' domain. This sounds like our list of things that are software components could start with a unix manual, a GKS manual, an SPSS manual and so on. >... Also managing the expectations of the >project developers is important. They typically expect all or >nothing. 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? regards ============================================================= Chesley Reyburn ...tektronix!ogccse!cvedc!cmr ECAE Software, Prime Computer, Inc. ...sun!cvbnet!cvedc!cmr 14952 NW Greenbrier Parkway ...sequent!cvedc!cmr Beaverton, OR 97006 Phone 503/645-2410 =============================================================
ken@reuse.USWEST.COM (Kenny A. Chaffin) (05/16/89)
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 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<