🚀 go-pugleaf

Don Dwiggins (dwiggins@atsun.a-t.com) writes:
> OK, I'll pick up the thread with a request for setting the parameters.  It
> seems to me that the interpretation of the terms "analysis" and "design" is
> less than well settled.  Design, for example, can occur in several settings
> and at several levels; it would be useful to distinguish among them, and
> discuss reusability in the different contexts.

If you study software engineering technology, and software engineering
history, several things become apparent:

	- The development part of the software life-cycle is basically
	  a series of transformations. Specifically, if a
	  non-technical (in the software engineering sense) user could
	  interact directly with the computer, without having to
	  actually develop an application, there would be no need for
	  software engineers for many everyday applications. However,
	  users currently have to go through intermediaries (i.e.,
	  software engineers and their managers). The job of these
	  intermediaries is to help formulate, clarify, and translate
	  the users' requests into a form which the computer can
	  understand. This formulation, clarification, and translation
	  process is what we often refer to as the development part of
	  the software life-cycle.

	  Traditionally, (systems, requirements, and/or user) analysis
	  was the first step in this transformation process. The idea
	  was to help both the client and the software engineers
	  better understand the problem to be solved. One of the
	  outputs of the analysis process was a description of the
	  system, _as_ _it_ _would_ _appear_ _to_ _the_ _client_.
	  Equally traditionally, the process which followed analysis
	  was referred to as design. The usual concept was that
	  designers implemented the internal (software) architecture
	  of the system. Designers were supposed to discuss things in
	  terms of modules (e.g., subroutines), and other technical
	  (from the software engineering perspective) issues. Design
	  was traditionally followed by programming (coding).

	- Even in the "good old days" people had trouble
	  differentiating between analysis and design. When did
	  analysis stop? When did design begin? How do I
	  systematically take the output of the analysis process and
	  use it as the input to the design process? Some people began
	  to realize that the boundaries between life-cycle phases
	  really were fuzzy.

	- Some people realized that the development of a software
	  product was more a continuous process than it was a series
	  of discrete steps. Some even realized that the distinction
	  between the analysis, design, coding, and testing phases
	  were purely artificial, and were very often used by
	  management as tools to control a software development
	  effort.

	  If you view a software development effort as a huge
	  monolithic entity, that means that you may have to invest
	  large sums of resources, for an extended period of time,
	  with very little idea of what the final results will be. On
	  the other hand, if you introduce phases into the life-cycle,
	  and specify deliverables for each phase, you have much more
	  control over the overall process. You can make "mid-course
	  adjustments," "go/no go" decisions at the end of each phase,
	  spot trouble earlier, and generally have a much better idea
	  of actual progress. Please note, however, methods,
	  methodologies, deliverables, well-defined phases, and the
	  mere presence of management do not guarantee success.

	- Others have observed that analysis and design, for example,
	  even take place in the maintenance phase of the software
	  life-cycle.

	- There are many different overall approaches to the software
	  life-cycle, e.g., waterfall, spiral, b-model, and
	  recursive/parallel. (In some of my classes, I show people at
	  least six different approaches.) In object-oriented software
	  engineering, a very commonly used approach is
	  recursive/parallel, sometimes referred to as "analyze a
	  little, design a little, implement a little, test a little."
	  Yes, this means that analysis, design, and implementation
	  may take place at many different points during development.

	- Depending on how you view the terms:

		- Analysis and design are precursors to coding, and do
		  not involve coding.

		- Each time a single character of source code is
		  changed you are actually re-designing. (Notice that
		  software maintenance differs from hardware
		  maintenance in this respect. Specifically, hardware
		  maintenance may involve replacing a defective part
		  with an identical part, whereas software maintenance
		  requires the introduction of different parts.)

		- Analysis may involve analysis of a piece of source
		  code with the intent of finding a problem, or
		  suggesting optimizations or extensions.

		- Et cetera ...
 
> With regard to analysis, I have a question arising from your message.  Early
> on, you say that you've
> 
> 	- conducted research in various aspects of software
> 	  reusability (e.g., domain analysis, ......
> 
> Later, you say
> 
>        This means that domain analysts (i.e., those charged with identifying,
>        documenting, and configuration managing reusable components) must
>        constantly balance the size of a component against its potential for
>        reuse. They must find both the granularities of components, and the
>        mix of components, which will provide the highest return.
> 
> I had the impression that "domain analysis" was the sort of thing that would
> be done for a class of applications intended to run in a common domain, to
> identify common classes of data, algorithms, report types, etc.  Your
> characterization of the task of a "domain analyst" seems to be more like
> that of a database administrator for a component database.  Where am I
> confused?

I suspect it is in your interpretation of the word "component." I have
no problem with "components" being "common classes of data,
algorithms, report types, etc." However, I think we can better define
what we are after in domain analysis.

First, we need some definitions:

	- "An investigation of a specific application area that seeks
	  to identify the operations, objects, and structures that
	  commonly occur in software systems within this area."
			-- Dan McNicholl

	- "Systems analysis states what is done for a specific problem
	  in a domain while domain analysis states what can be done
	  in a range of problems in a domain. ...  A domain
	  analysis is only useful if many similar systems are to
	  be built so that the cost of the domain analysis can be
	  amortized of all the systems.

	  "The key to reusable software is captured in domain analysis
	  in that it stresses the reusability of analysis and design,
	  not code."
			-- Jim Neighbors

	- "A horizontal domain analysis studies a number of different
	  systems across a variety of applications."
			-- Grady Booch

	- "A vertical domain analysis studies a number of systems
	  intended for the same class of applications."
			-- Grady Booch

We can add some more clarifications:

	- Domain analysis is _not_ a software life-cycle activity. It
	  has a beginning, but, usually, never stops. It runs
	  in parallel with the life-cycles of many software products. 

	- Domain analysts must identify reusable items in their
	  application domains, however they will usually be able to
	  classify what they find as:

		- reusable, and highly domain-specific, i.e., these
		  items will have a very low potential for reuse
		  outside of the defined domain. These items are
		  usually in the minority of the items encountered.

		- reusable, and not specific to the defined domain,
		  i.e., these items will have at least some
		  "horizontal reuse potential." These items are
		  usually in the majority of the items encountered.

	- Unfortunately, many people tend to focus on only low-level
	  items (e.g., source code, object code, algorithms, data)
	  during domain analysis. Much larger payoffs are achieved
	  when higher-level items (e.g., plans, standards, design
	  products, analysis products) are also considered.

	- A domain analyst must not only be familiar with the specific
	  domain, he or she must also be familiar with what they are
	  supposed to be looking for (e.g., objects and classes), he
	  or she must have excellent abstraction skills, and he or she
	  must be well-versed in software reusability technology.

	- In functional domain analysis, we are looking for things
	  that fit a functional viewpoint of systems in our domain.
	  That is, we are looking for reusable functions, libraries of
	  functions, and, in general, items which will be useful to
	  those software engineers who have taken a functional
	  decomposition approach to the software life-cycle.

	- In object-oriented domain analysis, we are looking for
	  objects, classes, systems of objects, and, in general, items
	  which will be useful to software engineers taking an
	  object-oriented approach to the software life-cycle.

A domain analyst must do much more than simply point to an item and
say that the item is reusable. There is much more work to be done.
Without going into a full-blown course on domain analysis, some of the
things a domain analyst can be expected to do are:

	- Concisely and precisely define the application domain.

	- Identify a representative sample of applications which span
	  the domain, and use this sample to begin to extract
	  potentially reusable items.

	- Accurately name and document each reusable item. Of course
	  this brings up issues like nomenclature and definitions.

	- Clean up, parameterize, and otherwise refine potentially
	  resuable items.

	- Identify additional reusable items suggested by those
	  already identified.

	- Store and retrieve both the reusable items, and information
	  associated with the items.

	- Develop guidelines for the (re)use of the reusable items.

	- Demonstrate reuse using the reusable items and the
	  guidelines.

	- Interact with all those involved in the software engineering
	  process, e.g., requirements analysts, testers, designers,
	  coders, software quality assurance personnel, managers, and
	  maintenance personnel. The specifics of these interactions
	  are too involved to go into in this short message.

There is much more I could say. (Yes, I do teach a course on the
subject.) But this message is already too long. Thanks for listening.

				-- Ed Berard
				   (301) 353-9652