%last change 1.4.94
%Scope:  This group will focus on topics that are/should be the crux of
%a business plan/model for software reuse implementation.  The group
%will discuss implications of the chosen topics on the
%institutionalization of software reuse into industry, DoD and
%academia.  Topics will include:  incentives, risk management, cultural
%issues, legal/liabilities/copyrights, and economic models.
%
%Goal: o Share current experiences/concerns with software reuse
%        business issues.

%From: huber@Dsd.Paramax.COM (T Huber)
%Here is the write-up (in ASCII) for the Management Issues working group (both
%long version and summary version) for inclusion in the WISR Proceedings.
%I really enjoyed the workshop; it was very beneficial and the knowledge
%gained will be very useful to both myself and my project.  You did a great
%job!!
%Terry Huber
%                                  WISR 93 -- Proceedings Input
%                                Management Issues Working Group
%                                         (LONG VERSION)

%\subsection*{INTRODUCTION}

The Management Issues Group was a diverse group made up of
representatives from the Department of Defense, Defense
Contractors, commercial organizations and universities.  During
initial discussion, the group discussed the differences among the
impacts of reuse on business practices and business decisions on
each of these enterprises.  In particular, the group discussed how
each of these enterprises approach incentives and how customer
involvement is different.

In commercial enterprises, the practice of software reuse is
internal to the developer.  Although a user may indirectly benefit
from an organization developing software using software reuse
processes, (faster time to market, lower product price, etc.), the
process is unknown to them.  This is true due to a ``off-the-shelf''
as opposed to ``made to order'' environment.  The customer is
interested in the final product and the product sold is usually
mass-produced.  On the other hand, in the DoD (and Government)
environments, the developer (contractor) is in a ``make to order''
environment and the Government customer is involved in the process.
The involvement of the Government in this environment includes
control over the software development process.  Commercial
enterprises, as well as Government and DoD organizations are
interested in developing an incentive program for its employees.
However, the Government is also interested in developing an
incentive program for its contractors, which would be tied into the
acquisition process.

The remaining discussion during the group session primarily
focused on the ``commercial'' enterprise.

\subsection*{Approach}

The original intent of the group was to focus on topics that should
be the crux of a business plan/business model for implementing
software reuse and to develop an outline(s) to be used as a tool in
making business decisions.  As we were taking turns defining
``business model,'' we learned about Hewlett Packard's Flexible
Software Factory (FSF) [Navaro93].  We used the FSF model's structure
and concepts for most of our remaining discussion on management
issues.

Two of the main components of the FSF are the Elements and the
Adoption Strategy. The elements, of which there are five, are the
theories and concepts behind a reuse program which address where an
organization is, and where it wants to go with respect to reuse.
The adoption strategy is built on the elements and represents the
implementation of how to get from an initial state to the state of
fully institutionalized software reuse.

The FSF elements are:
\begin{itemize}\itemsep -3pt
 \item Customer and Values Elements
 \item Business System Elements
 \item Structural System Elements
 \item Support System Elements
 \item People System Elements
\end{itemize}

Customer and Values Elements address market stability, market
history, market predictability and the culture of the organization.
Business System Elements represent the support structure within an
organization, for example its purpose, objectives, group norms, and
resource planning.  Structural System Elements are the structures
and processes that are put in place to meet the organization's
objectives, for example a software development process, roles,
organizational boundaries, communication, and problem solving and
decision making processes.  Support System Elements are the
infrastructure that supports the structural system, for example
tools, technologies, funding models, and measurement and feedback
systems.  People System Elements are the human resource structure,
for example staffing, evaluation and reward, and education and
training.

Our approach was to create a few questions about the FSF Elements
and about the Adoption Strategy which would allow us to share our
professional experiences and insights into the problems and
solutions of successful software reuse.

\begin{itemize}\itemsep -3pt
 \item Questions to answer for each Element:
 \begin{itemize}\itemsep -3pt
    \item What are the impacts of a reuse program on this element?
    \item What are the software engineering methods that impact or help control
          these elements?
 \end{itemize}

 \item Questions to answer for Adoption Strategy:
 \begin{itemize}\itemsep -3pt
    \item What mechanisms do you use to change the elements?
    \item How do you change the behaviors?
 \end{itemize}
\end{itemize}

Though we agreed we would not have time to address it, we felt
another question which needs to be addressed is: How do the
elements interact with each other?

Our discussion and results focused on Customer and Values Elements
and the Structural Elements. We included ideas, thoughts, and
discussions about Reuse Adoption Strategy as they arose. Many of
our concerns were included and answered by Ted Davis using the
Reuse Adoption Guidebook [SPC93]. Of value to our discussion was a
table of critical success factors which is used to set reuse goals
focusing on ``what'' is to be accomplished.  It lists all the
critical success factors in each of four groups: application
development, asset development, management, and process and
technology. We also used the Domain Assessment Profile from the
Reuse Adoption Guidebook. This figure is used to help assess reuse
potential by assessing the degree to which five factors are
exhibited in the organization.
\begin{itemize}\itemsep -3pt
 \item Market Potential
 \item Commonalities and Variables
 \item Standardization in the Domain
 \item Domain Stability and Maturity
 \item Existing Domain Assets
\end{itemize}

\subsection*{Results}

\subsubsection*{Customer and Values Elements}

In discussing aspects of the Customer and Values Elements (which
addresses market stability, market history, market predictability
and culture of the organization), the group separated the
discussion into two groups: (1) short-term benefits under initial
software reuse and (2) long-term benefits under institutionalized
software reuse.  Furthermore, the group defined ``customer'' as
either the end-product user or the software developer.

During the short-term, or when software reuse is being initiated
into an enterprise, the benefits gained by the customer is
dependent upon the availability of reusable assets, the
understanding of the customer, and the product family size.  If
there are no available reusable assets and the product family size
is small, then the product will take much longer to go to market.
If there are no available reusable assets, but the product family
size is large, developing the product suite will be faster, but the
first products will have a longer time to market.  If reusable
assets are available and the customer's needs and wants are
understood, then, the benefits to the customer would be similar to
that of the long-term or institutionalized reuse.

In the long-term, when software reuse is institutionalized, the
benefits to the customer include:
consistency across products, lower product price, lower
service/maintenance costs are lower, the product is available
sooner and a more reliable, higher quality product.

\subsubsection*{Structural System Elements}

In discussing the various aspects of the Structural System
Elements, such as software development process, roles,
organizational boundaries, communication, and problem solving and
decision making processes, several problems or barriers were
raised.  The group identified six problems/barriers.  They are
listed here, with discussion of solution following.
\begin{enumerate}\itemsep -3pt
  \item \underline{Product manager loses control over assets going into}\\
\underline{his/her product.}

  {\bf Solution:} Structural systems should be put into place that will
               result in managers losing control over system development
               slowly.  Adoption strategies should be incremental which
               have both short term and long term goals.  Allowing
               managers to have some influence over or input into asset
               development could be substituted for control.  Begin with
               low-granularity of reuse, then move towards a higher
               granularity of reuse.

  \item  \underline{Technical staff experiences a loss of independence.}

   {\bf Solution:} All members of the team need to understand the
               business/technical objectives of the product family
               (i.e., both the asset development and product
               development). The technical staff needs to be educated on
               the business objectives for doing software reuse, so that
               they can understand the reasons behind the move to reuse,
               as well as the organization's implementation plans (See
               discussion in \#4 below).

  \item \underline{Structural elements need to support:}(a) The asset life cycle
   and the product life cycle, since they are treated separately; and
   (b) Communications, problem solving and decision making across
   asset and product organizational boundaries must be addressed.

   {\bf Solution:}     (a)  Development of an asset needs to be treated
   similarly as a product.  An asset has a life cycle, just as a
               software product does.  Thus, support must be provided
               for the asset through out its full life cycle, including
               maintenance.  However, training and education is
               important to reach this goal.  Also, asset life cycles
               need to be incorporated into product planning from the
               beginning and tailored to the particular environment.

               (b)  By establishing working groups at all levels of the
               organization, %(Jesus Tirso),
               communications links can be
               established.  Not only do new roles need to be
               introduced, the organizational boundaries may have to
               change (i.e., involve marketing representatives in
               process).  So that organizational boundaries support
               communication, problem solving and decision making across
               an organization, new boundaries need to be established.
               These boundaries should support complete units of work,
               reconciliation of processes between units of work and a
               shared understanding among all personnel involved.
               Structures/Boundaries need to support a single view of
               the end customer and a feed back loop needs to be put in
               place from the system developers to the asset developers.


  \item  \underline{Lack of understanding of the process, system, and}\\
         \underline{planning.}

  {\bf Solution:} The extent and content of understanding for reuse
               processes and organizational objectives must be the same
               for all personnel involved.  First, the organization
               should perform an assessment to get a profile of the
               organization.  This of course should be facilitated by an
               experienced person who is an objective party.  As a
               result of such an assessment, organizational goals can be
               developed and then a baseline against which to measure
               those goals will be in place.

  \item  \underline{Potential productivity loss trying to debug using}\\
         \underline{ components not owned by the product line} (may not\\
         have source code for the
   component, may not be allowed to contact the component developer,
   etc.).

   {\bf Solution:}  Select components that are ``well specified, correct,
               robust and efficient.'' %[Doug Lea]

   \item  \underline{If you are producing and consuming simultaneously,}\\
   how do you trade off between producing a product and generating new assets.

   {\bf Solutions:}  Need measurable goals for reuse cascading at
    all levels of management that support the production
                      and maintenance of assets.  Rewards need to be tied
                      to successful reviews.

               Through re-organization, asset development can be kept
               separately from system/product development, with a
               liaison working as a domain manager.  The domain manager
               would be able to see the goals of both asset development
               and system development.

               A reuse advocate could be inserted in the project and be
               responsible for making sure product engineers understand
               what assets exist and what new assets can be
               developed/generated.
\end{enumerate}


\subsection*{References}
[Navarro93] J. J. Navarro, ``Organization Design-Based Software
       Reuse Adoption Strategy,'' 6th Annual Workshop on Software
       Reuse, Owego, NY, 1993.

[SPC93] Instituting Reuse Practices, A Reuse Adoption
       Guidebook, Software Productivity Consortium Services
       Corporation, available November 15 from (703) 742-7211.

%                           WISR 93 - Management Issues Working Group
%                                        Proceedings Input
%                                            (SUMMARY)
%
%The Management Issues Group was a diverse group made up of
%representatives from the Department of Defense, Defense
%Contractors, commercial organizations and universities.  During
%initial discussions, the group concluded that there are many
%differences among the impacts of reuse on business practices and
%business decisions on each of these enterprises, and thus
%concentrated on one area: the commercial enterprise.
%
%The original intent of the group was to focus on topics that should
%be the crux of a business plan/business model for implementing
%software reuse and to develop an outline(s) to be used as a tool in
%making business decisions.  As we were taking turns defining
%``business model,'' we learned about Hewlett Packard's Flexible
%Software Factory (FSF) (Na93).  We used the FSF model's structure
%and concepts for most of our remaining discussion on management
%issues.
%
%Two of the main components of the FSF are the Elements and the
%Adoption Strategy. The elements, of which there are five, are the
%theories and concepts behind a reuse program which address where an
%organization is, and where it wants to go with respect to reuse.
%The adoption strategy is built on the elements and represents the
%implementation of how to get from an initial state to the state of
%fully institutionalized software reuse.  The FSF elements are:
%Customer and Values Elements, Business System Elements, Structural
%System Elements, Support System Elements and People System
%Elements.
%
%Our discussion and results focused on Customer and Values Elements
%and the Structural Elements. We included ideas, thoughts, and
%discussions about Reuse Adoption Strategy as they arose. Many of
%our concerns were included and answered by Ted Davis using the
%Reuse Adoption Guidebook (SPC93).
%
%Customer and Values Elements address market stability, market
%history, market predictability and the culture of the
%organizations.  Structural System Elements are the structures and
%processes that are put in place to meet the organization's
%objectives, for example a software development process, roles,
%organizational boundaries, communication, and problem solving and
%decision making processes.
%
%In discussing aspects of the Customer and Values Elements (which
%addresses market stability, market history, market predictability
%and culture of the organization), the group separated the
%discussion into two groups: (1) short-term benefits under initial
%software reuse and (2) long-term benefits under institutionalized
%software reuse.
%
%During the short-term, or when software reuse is being initiated
%into an enterprise, the benefits gained by the customer is
%dependent upon the availability of reusable assets, the
%understanding of the customer, and the product family size.  In the
%long-term, when software reuse is institutionalized, the benefits
%to the customer include: consistency across products, lower product
%price, lower service/maintenance costs are lower, the product is
%available sooner and a more reliable, higher quality product.
%
%In discussing the various aspects of the Structural System
%Elements, such as software development process, roles,
%organizational boundaries, communication, and problem solving and
%decision making processes, several problems or barriers were
%raised.  The group identified six problems/barriers.  They are
%listed here, with the discussion of the solutions following.
%
%(1)  Product manager loses control over assets going into his/her
%product.
%       Solution:
%               Substitute some influence over asset development
%               Make changes incrementally
%               Include both short term and long term goals
%               Incremental adoption
%
%(2)  Technical staff experiences a loss of independence
%       Solution:
%               New challenges available via new roles
%               All team members need to understand business and
%               technical objectives of the product family (i.e., both
%               the asset development and product development).
%               Educate technical staff on business reuse objectives and
%               reuse implementation goals
%
%(3)  Structural elements need to support: (a) The asset life cycle
%and the product life cycle, since they are treated separately; and
%(b) Communications, problem solving and decision making across
%asset and product organizational boundaries must be addressed
%       Solution:
%       (a)
%               Treat development of an asset similarly to that of a
%               product; provide life cycle support for the asset,
%               including maintenance
%               Asset life cycles need to be incorporated into product
%               planning from start
%               Tailor asset life cycle to the particular environment
%       (b)
%               Establishing working groups at all levels of the
%               organization
%               Introduce new roles
%               Establish new organizational boundaries (new player may
%               be added: e.g., marketing representatives
%               Organizational boundaries may change
%               Structures/Boundaries support a single view of the
%               customer and feed back to asset developers
%
%(4)  Lack of understanding of the process, system, and planning
%       Solution:
%               Conduct objective assessment of organization
%               Develop organizational goals
%               Measure goals against baseline
%
%(5)  Potential productivity loss trying to debug using components
%not owned by the product line (may not have source code for the
%component, may not be allowed to contact the component developer,
%etc.)
%       Solution:
%               Select components that are ``well specified, correct,
%               robust and efficient.'' [Doug Lea]
%
%(6)  If you are producing and consuming simultaneously, how do you
%trade off between producing a product and generating new assets.
%       Solutions:
%               Need measurable reuse goals at all organizational levels
%               Goals should support the production and maintenance of
%               assets.
%               Tie rewards to successful reviews
%               Asset development can be kept separately from system
%               development if new roles of liaison (domain manager) is
%               established
%               Establish a reuse advocate/asset expert on system
%               development team
%
%REFERENCES
%
%     \item     (Na93) J. J. Navarro, ``Organization Design-Based Software
%       Reuse Adoption Strategy,'' 6th Annual Workshop on Software
%       Reuse, Owego, NY, 1993.
%
%     \item     (SPC93) Instituting Reuse Practices, A Reuse Adoption
%       Guidebook, Software Productivity Consortium Services
%       Corporation, available November 15 from (703) 742-7211.

