ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr7/workshop/working-groups.txt

Text File | 1995-08-20 | 14KB | 305 lines

----------------------------------------------------------------------
Title: "The Organization" or
       "Software Reuse in a Business Environment

Leader: Kevin Benner, Andersen Consulting

Scope:
We will look at the specific case of a contract software development
company called AC (remarkedly similar to Andersen Consulting) and their
focus on the Utilities Industry.  The general situation is that AC has
developed a customer service package (including billing, invoicing, service
requests, etc.) for several utility companies.  AC has in place an reuse
plan which it is executing.

A case study will be provided which describes
the business environment, current assets, and reuse plan.  This will
be made available to participants before the workshop.  At the workshop, the
working group session will begin with an overview of the business environment.
At this point we will be begin a mediated discussion to uncover additional
information. We will then breakup into a few groups to refine or replace the
existing reuse plan. We will then come back and share our results and
discuss the relative merits of the various plans.  At this point we may
either vote on choosing one or we may merge the best ideas into a new plan.
Ultimately we will have a reuse plan which we are prepared to submit to
various scenarios for analaysis and probably refinement.

Goals:
1. To analyze a specific business case with the intention of
developing a reuse plan for that environment.
2. To evaluate the plan with respect to various scenarios.
3. To highlight how one evolves a reuse plan as the business environment
changes.
4. To describe the reuse plan and its refinements based on the scenarios.


----------------------------------------------------------------------
Title:  Domain Processes and Engineering

Leaders: Sid Bailin, CTA, and
         Scott Henninger, University of Nebraska

Scope:
This working group will attempt to uncover and analyze some of the key
"scenes" in the drama of domain engineering. If the spirit of the
group is conducive, we might actually adopt the metaphors of theatrical
criticism to formulate our work: who the main characters are, what
the conflicts are that drive the story forward, how the dramatic tension
is resolved, etc. (there is quite a bit of precedent for this approach,
e.g., R. Schank's book Tell me a Story, B. Laurel's book Computers as
Theater, T. Nelson's theory of virtuality).  We will try to
steer clear of conventional process definition, in the belief that that
level of analysis tends to bypass the key underlying difficulties/
opportunities.  By focusing on a specific problem context of a
hypothesized sample organization and software development requirements,
we will avoid trying to formulate a general theory -- trying,
instead, to discover useful deep insights about the DE process,
however incomplete.

Goals:
1. Identify recognizable (productive or non-productive) activity
patterns that arise in DA
2. Identify key obstacles to selling, planning, enacting, and
utilizing a DA, formulated in terms of these activity patterns
3. Identify approaches to overcoming the obstacles


----------------------------------------------------------------------
Title: "Reuse of Processes"

Leader: Bill Frakes, Virginia Tech

Scope:
This group will discuss software process reuse and
reusability, specifically how to pragmatically and systematically standardize
and replicate project-specific processes in an industrial software environment.
Our working hypothesis is that by using domain engineering techniques, software
reuse principles, process architecture research, and process modeling
mechanisms, project-specific processes can be abstracted into reusable
components that can be  used by process engineers.

Items for discussion will include:

   - a notation for recording reusable processes,

   - definition of processes in an industrial environment,

   - creation of a repository of these reusable processes,

   - evaluation studies of software process reuse.

Goals:
To clarify the above points, and provide a basis for further work.


----------------------------------------------------------------------
Title: Domain Modeling Representation Strategies:
       Towards a Comparative Framework

Leader: Mark Simos - Organon Motives, Inc.
      (co-leader(s) to be recruited/drafted at the event)

Scope:
Within the reuse community, the quest for a "domain analysis of
domain analysis" remains something of a cross between the Holy Grail
and a solution of the NP-completeness problem. This working group
will focus on the much narrower problem of establishing a workable
comparative framework for domain modeling representation strategies.

To make the group experience both tractable and fun, we propose
treating the exercise as a chance to discover and practice our domain
modeling skills in collaborative learning work.  For example, the
proposed scope assumes that representation issues can be usefully dealt
with separately from domain engineering process issues. Testing this
hypothesis will require us to negotiate boundary issues, explore
alternative framework structures, etc., all skills inherent in domain
modeling itself. If possible, we will experiment with the framework by
"running it" on a scenario adopted from one of the other working
groups.

Goals:
1. Our own enriched experience of domain modeling, focusing
on a part of the domain engineering discipline itself as a subject area.
Since this kind of "meta-domain" may be less satisfying for some
participants, we may also choose to work with a more concrete real
world example or hypothetical scenario to ground our discussion of
alternative representations (but not to attempt to enact a full domain
analysis).
2. A draft comparative framework as a starting point for ongoing
revision and evolution.  The framework would ideally include both
a feature model for the representations themselves and a decision
support model to aid in matching particular
representation strategies to different application contexts.

Preparation (if possible):
If possible, come prepared with any or all of the following:
1. An example or case study of a representation style or strategy
selected for a given domain modeling task. Can you articulate the
process by which the representation strategy was selected, the rationale
for its selection, ways in which the representation had to be modified
or adapted to suit the needs of the domain modeling task? What was
the outcome of the representation's adoption for the task?
2. An "advocacy position" for a particular representation
strategy. What aspects address requirements specific to domain
modeling? What are its advantages and limitations?
3. Any other contributions to the framework that will
(hopefully) emerge from our collective modeling: selection criteria,
differentiating features, implicit assumptions in the framework, etc.


----------------------------------------------------------------------
Title: Micro-Architecture of Software Components

Leaders: Joe Hollingsworth, Indiana University, and
         Bruce W. Weide - Ohio State University

Scope:
This group will focus on the details of both the structure and the
behavior of software component interfaces and on the implementations of
individual components, sets of components, and how they compose
and "interoperate" with each other.  The group will also consider
issues such as  certification, plug-compatibility, programinning language
features, and performance.

Goals:
1. Discuss (and hopefully establish) why software architecture should
be split into two sub-areas: micro-architecture and macro-architecture.
2. Discuss some existing practical experiences related to
micro-architecture issues.
3. Share ideas, agreeing to disagree.


----------------------------------------------------------------------
Title: The Need For Good Mental Models of Software Subsystems

Leaders:  Steve Edwards and Larry Latour

Scope:
People form internal mental models of the things they interact with in
order to understand those interactions. Unfortunately, programmers
tend to design "behaviorally rigid" software that solves the
particular problem at hand, and this approach hinders their ability
to "see" analogous problem solutions.  Conventional programming
languages do little to help these programmers develop good mental
models of their systems.  This is turn, is an impediment to helping
these same programmers overcome the behavioral rigidness of their designs.

In this working group we explore (1) the methods by which humans develop
good mental models of generic software subsystems, and (2) how
existing programming languages support/hinder these efforts.

Goals:
1. To make clear the definition and usefulness of "mental model".
2. To develop examples of how such mental models are developed and
how they contribute to reusability.
3. To factor both formal methods and human factors into the
development of mental models - "Formal methods help to represent
subsystems precisely, but it is humans that develop mental models
to understand these same subsystems."


----------------------------------------------------------------------
Title:  "Systematic OO Reuse - A Tale Of Two Cultures"
Leader(s) : Martin L. Griss, HP Laboratories, and
  a co-conspirator/co-leader to be named (Martin will also
  act as envoy to the case-study group)

Scope:
Many software organizations adopt object technology (OT), hoping for
substantial reuse, yet do little to develop specific reuse-enhancing plans or
use known and emerging methods of systematic reuse (such as CFRP-based
process, Creator/Utilizer organizations, Domain Engineering methods, system
and component generators). While acknowledging that reuse is a balanced
People, Process and Technology issue, most OO researchers focus on purely
technical issues - frameworks and patterns seem most popular now, and business
objects are coming on strong. OO companies seem to focus only on selling
training on the latest methodology, and tools to support it, or low level
libraries.

This problem is in part fueled by two communities that rarely meet each other
or read each others literature, in part because of historically different
foci (software engineering in the large vs. rapid development in the small).
There is little general software engineering education in most CS programs,
and specifically almost no reuse engineering in most computer science
programs, while many do (try) to teach OO methods.  But it is time for these
two cultures to work much more closely together.

There are many TECHNICAL issues: For example, how should Domain Engineering
and OOA/OOD relate - do we "reuse adapt" a conventional OO method, or do we
take pieces of an OO method and use it within some DA method (e.g,
FODA->JODA)? How and where do system generators and domain-specific (non-OO?)
languages fit within an OO design and implementation approach? Which DA/DE
methods work best with OO? Which reuse tools should be used? How do 3C and DFR
guidelines get injected. How do Patterns and Use-cases relate? How does a
repository of models, patterns and components get used in an OO based DWR?

There are many PROCESS and PEOPLE issues, ranging from education, management,
to staging incremental/iterative development, to using OO metrics to
guide the evolution of a repository, components and systems, to organization
of Creator/Utilizer group (or reuse teams). How should BPR and OO-BPR be used
to design reuse organizations and processes. How does this relate to OO reuse
support tools development and business object management?

We will collect, tabulate and discuss the most important of these issues.

Goals:
1. Collect information/examples of specific attempts to combine
some systematic reuse techniques with OO methods and technology
(e.g., REBOOT, EDLC,  ...)
2. Tabulate OO-specific issues that need changes or cause difficulties
with OO methods or Reuse Techniques
3. Develop a short list of recommendations and questions for other
working groups to consider, and actively infiltrate/lobby with those
groups to solicit feedback on the list
4. Suggest directions of education, practice and research that
integrate the best of both, or that would lead to an acceleration
of integration of best practice.

Process:
1. We will use a "Bruce Anderson" model of rapid merge small group
writing and merging, with short presentations, to synthesize our
knowledge
2. As appropriate we will allow short presentations by attendees
3. We will periodically send out "envoys" to other working groups
to convey interim results, surface issues

Preparation:
Think about topic and issues, bring "short lists", copies of references,
material to show

References:
1. Adele Goldberg & Kenny Rubin's new book "Succeeding with Objects"
(has a lot of reuse organization & process discussion)
2. The REBOOT book - Software Reuse, a Holistic Approach - Edited by EA
Karlsson.
3. My Object Magazine columns on software reuse, Feb 95, May 95, etc.


----------------------------------------------------------------------
Title: Barriers to "Institutionalizing" Reuse Using Current Tools
and Environments

Group Leaders:
Margaret (Maggie) J. Davis, Boeing Defense and Space Group
Rebecca Joos, Motorola

Scope:
This group will focus its attention on the barriers to using current
tools and environments for reuse.  Included in our explorations will
be the  issues of how to fit with other CASE tools, how to integrate
with existing processes, and how to support the reuse
of processes.  Overlaps with the other working groups will be a
critical part of our study. The work will start with the reuse tools
survey developed by Rebecca's WISR '93 reuse tools and environments working
group. In addition, it will draw from the experiences of the group
leaders and the other participants in their respective institutions.

Goals:
1. To develop a list of barriers to the use of current tools and environments
for reuse.
2. To consider the impact of current tools and environments on each of the
other working groups.
3. To develop a framework for thinking about how current tools
and environments can optimally support the reuse process.
----------------------------------------------------------------------