ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ascii/stump2.ascii

Text File | 1993-10-19 | 15KB | 307 lines

  Experiences  in  Introducing  and  Measuring  Software  Reuse


                at  IBM  Endicott  Programming  Laboratory



                                              Patricia Stump



                            IBM Endicott Programming Laboratory

                                          Dept.  G95/16-4D10

                                         17C & Glendale Drive

                                          Endicott, NY 13760

                                           Tel:  [phone]

                               Email:  [e-mail]



                                               Jim Gesacion



                            IBM Endicott Programming Laboratory

                                          Dept.  G85/17-3R16

                                         17C & Glendale Drive

                                          Endicott, NY 13760

                                           Tel:  [phone]



                                                  Abstract


    This position paper describes approaches to introducing software reuse as an ingrained part
of software development for the Virtual Machine / Enterprise Systems Architecture (VM/ESA)
operating system and related products at the Endicott Programming Laboratory (EPL). We
discuss the major inhibitors and how to overcome them. Our approach is to motivate software
developers to participate without making large investments in time and effort,and to measure
reuse in a simple, useful, and comprehensive way.


Keywords: Reuse experiences, reuse program introduction, reuse measurements


Workshop Goals: Learn and exchange information on reuse methods and experiences.


Working Groups: Reuse process models, Reuse and OOmethods, Reuse and formal methods,
Useful and collectible metrics, Reusable component certification



                                                  Stump- 1


1      Background



The authors have been active in the Endicott Programming Laboratory's Reuse Advisory Board
formed in 1990. Patty Stump has been the IBM Endicott site Reuse Champion since 1991,leading
the Reuse Board in several approaches to intro duce Software Reuse.  She's been involved in reuse
education, tool evaluation and selection, measurements, lo cal success stories, combining reuse im-
provement with quality improvement goals and measurements, and exchanging experiences with
other  IBM Reuse  site  Champions.  Jim  Gesacion  has  been  involved  as  a  Reuse  Board  manage-
ment representative since 1992 and haslead work groups to define criteria for reusable component
candidates,  to  upgrade  the  EPL's  Reuse  Incentives  Program,  and  Reuse  advertising,  as  well  as
advocating software reuse among the EPL management team.



2      Position



Getting a new tool or process, such as software reuse, successfully intro duced,supp orted, and  in-
grained in an existing team of technical people and its processes is difficult[1]. Since new software is
where reuse investments are usually justified, an environment of legacy code development presents
an even greater challenge for the introduction ofsoftware reuse[2 ]. The bulk of the EPL's VM/ESA
product consists of very procedure-oriented, tightly-coupled subsystems and modules of low cohe-
sion (EVB87), often written in Assembler programming language. When new function is created
for the VM/ESA product, it must blend with old product technology,  making the exploitation of
new development technologies very limited.  At the same time, to remain competitive,  the EPL
must invest in new technologies that promise productivity and quality improvements. The EPL has
learned that it can demonstrate significant quality improvement by removing errors from a product
in the field.  However, in order to deliver new functionto that product and maintain equivalent
low error rates, new development technologies must be employed.  Software reuse is a technology
which allows the creation of more and more new function with less and less error introduction. The
EPL combines scavenging of existing product code with the examination of new product function
to identify all reuse opportunities.



2.1     What Seems to be Working; Identifying Informal Reuse



Spending time and effort to closely analyze the full collection of existing reusable co de inthe legacy
operating system, for example macros, module entry points and subroutines in any language, and to
then document and measure them provides many benefits. It addresses the common problem of not
having a robust repository of reusable parts for developers to use, as software reuse is introduced.
If many parts are not available, willing participants in the introduction of software reuse haveonly
one choice, to create new reusable parts. This often implies an investment larger than just writing
new code[3 , 4], an investment which is very difficult to justify.  This "seeding" of existing parts
creates  a  library  of  parts  of  unknown  certification  level  [5 ], i.e.  the  desired  or  required  level  of
documentation,  quality,  testing,  legal  information  required  of  reusable  parts  by  the  local  Reuse
Board may or may not be met. These parts may be narrow in scope, and may not justify claims
in productivity improvements, since reusers may know anduse them anyway.  But with respect
to quality, existing parts havereal customer-world history and data that can be used to identify
and record known quality information of parts forreusers of those parts.  This level of quality is
difficult to achieve through extensiveinternal testing and quality verification of new code.  What



                                                         Stump- 2


this repository of existing parts also provides to software developers is access to the new tools and
new processes of software reuse, through the familiarity of software parts they have worked with
for  years.  By  making  change  as  effortless  as  possible, people  can  adopt  new  habits  of  software
reuse, i.e. looking for parts to use on a new project, "owning" a reusable part, and understanding
documentation,  quality,  and test requirements of a reusable part.  These habits will be required
and  will  reap  larger  benefits  as  more  formal  and  broader  domain  reuse is  employed.  As  people
understand through personal experience, the value, the tools, the requirements of goo dreusability,
they will more naturally be lead to create software that is more reusable and less domain-specific
when possible.


Scavenging of reusable components from existing software can be accomplished in many ways[6, 7 ],
and is likely more cost-effective than building new ones in an environment where the amount of ex-
isting legacy code that is maintained and enhanced far outweighs the amount of new code produced
for the same software product. The EPL uses a set of reuse characteristics when manually scanning
through existing code and when working with developers to identify reusable parts.  This initial
repository  is  further  refined  by  examining  encapsulation,  domain breadth,  frequency  of  current
reuse, and known quality. Though only a subset of parts may be selected to make improvements
based on these criteria and resource availability factors, all items remain on the list to be searched
for by reusers.  Once the repository of existing reusable parts is created, it becomes a repository
of opportunity for quality improvement, reusability improvement, and certification of the reusable
part.  Domain experts and reuse experts can decide which parts need which work.  For example,
some parts may easily meet certification criteria once the quality history is checked. In other cases
the  documentation  may  need  to  be  improved, and  often,  testing  information  needs  to  be  found
and recorded.  With ato ol to track which criteria are met and which aren't, it becomes easier to
share the "costs" of certification, both among people and over time.  A module owner, or one of
the reusers, or a Reuse Board representative, or anyone could help with what they can afford to do
in meeting certification criteria for a reusable part. Instead of requiring an author to do all these
"extras" for some new reusable component and requiring them to fit it inwith their development
schedule now, it can be added to the repository, and mature to certification as it gets reused, or as
time permits. We see this approach as an evolution of parts to thecertified level, and an evolution
of the organization to the broad employment of software reuse technology.



2.2     What we Measure



Measurements are most effective when they measurethe b ehavior that is being encouraged.  The
behavior the EPL Reuse Board wishes to encourage is the practice of reuse to attain quality and
productivity  improvements.  Therefore,  many  types  of  reusable  parts  are  measured,  from  as-is
parts, to thoroughly proven "certified" parts.  The simplest measurement is the number of parts in
the repository, and how many certification criteria need to be met by the uncertified parts.  This
measurement is presented to teams, organizations of teams, and management.


The EPL measures quality inour pro cess and pro ducts quite extensively. Reuse measurements need
to reflect reuse's contribution to a product's quality improvement.  The EPL uses IBM corporate
reuse measurements[8].  The Reused Source Instructions (RSI) measurement and its derivatives, the
Reuse Percentage, Reuse Cost Avoidance, andReuse Value Added are oriented toward measuring
the combined value of quality and pro ductivity improvements. Productivity gains cannot be claimed
for all uses of a high-quality reusable part because people will naturally use itover and over and
teams will naturally share it.  However, each instance of a certified reusable part in the product,
from a quality-only perspective, representsa unique contribution to the quality of the product. If a



                                                         Stump- 3


developer chooses to use a "certified" routine over an as-is routine, there is a different quality result
in the product. There are potential services costs avoided each and every timethe certified part is
used. The "used instructions" (UI) (PH93) is used with an RSI which is based on total number of
instances. This reuse measurement complements the existing collection of defect-oriented pro duct
quality measurements used in the EPL by showing the total amount of certified product code at
its lower error rate, and its effect onthe pro duct's overall error rates and quality. These RSI-based
measurements are presented to product owners, project leaders, and management on a quarterly
basis, or when product development cycles produce new results.


To encourage teams to create certifiedreusable parts when possible, s and to improve the quality
of as-is reusable parts, the Reuse Percentage measurement is used to set and track team goals.


To be able to explain reuse in terms familiar to pro duct developers,  additonal categories of reuse
are measured, including code ported from one platform to another and co de imported from external
sources. So that everyone understands the "best" kind of reuse they can do, these reuse categories
are  further  refined  into  the  least  desirable  and  most desirable  based  on  two  criteria, productiv-
ity improvement and quality improvement.  This matrix helps encourage reusers to focus on the
underlying requirements of "better" categories of reuse.  "Best",  in this case,  would be a reuser
modifying  the  reusable  part  as  little  as  possible  (ideally  none), a  reuser  relying  on  the  original
owner to maintain a single copy of thereusable part,  and the reuser knowing and being able to
prove the quality of the reusable part. This "best" reuse, when practiced, will result in the highest
quality improvement and simultaneously the highest productivity improvement.



2.3     Comparison



There are many reports on reuse experiences available.  Most describe experiences in an environment
of application development or systems programmed with languages that better lend themselves to
reuse, such as Ada, C, and C++. We've found none that describe a reuse program that is introduced
for low-cost and that continues to evolve to more mature forms of reuse.


Although our measurement methods are based on existing measurement methods, ours have been
refined to focus on quality improvement,  and haveb een expanded up on in an effort to focus on
the education, and on the progress of getting reuse momentum going in a development team at the
same time that the measurements are used to explain the financial costs and benefits.



2.4     References



References



[1]  B.Bouldin, Agents of Change: Managing the Introduction of Automated Tools. Yourdon Press,
     1991.


[2]  J.  Doll  and P.  Stump,  "VM Quality  Improvement  Through  Software  Reuse  at  the  Endicott
     Programming Lab," Tech. Rep. TR 01.C173, International Business Machines, November 1991.


[3]  B. Barnes, T.Durek, G. Gaffney, and A. Pyster, "Cost Models for Software Reuse," in Pro-
     ceedings of the Tenth Minnowbrook Workshop, July 1987.


[4]  T. Bollinger and S. Pfleeger, "The Economics of Reuse: Issues and Alternatives," in Proceedings
     of the EighthAnnual National Conference on Ada Technology, March 1990.


                                                         Stump- 4


[5]  R. T. S. Center, "IBM Reuse Methodology:  Qualification Standards," Tech. Rep. Z325-0683,
     International Business Machines, 1992.


[6]  G. Caldiera and V. Basili, "Identifying and Qualifying Reusable Software Components," IEEE
     Computer, February 1991.


[7]  G.  Mayobre,  "Using  Code  Reusability  Analysis  to  Identify  Reusable  Components  from  the
     Software Related to an Application Domain," in Proceedings of the Fourth Annual Workshop
     on Software Reuse, November 1991.


[8]  J. Poulin and W. Hayes, "IBM Reuse Methodology:  Measurement Standards," tech. rep., In-
     ternational Business Machines, 1992, July.



3      Biography



Patty Stump is a staff programmer at IBM's Endicott ProgrammingLab oratory, Endicott, New
York. After numerous software development projects as a developer, her currentprimary respon-
sibility is to coordinate the Endicott Reuse Advisory Board's efforts tointroduce formal software
reuse  into  the  software  product  development  process  for  EPL-produced  products.  Her  interests
include software developmentpro cess models, quality improvement, and systems science. She is a
member of the IBM Corporate Reuse Council, the 100X Quality Improvement team in Endicott,
and IEEE Computer Society.  She received her Bachelor's degree from East Stroudsburg University,
Pennsylvania, and her Master's degree from StateUniversity of New York and Binghamton, New
York.


James Gesacion is a first line development manager at IBM's Endicott Programming Laboratory,
Endicott, New York.  He is currently responsible for development of Client/Server products.  His
software reuse responsibilities include serving on the Endicott Reuse Advisory Board, and providing
management support and focus. His interests include achieving Six Sigma Quality in products and
processes. He received his Bachelor's Degree from Youngstown State University, Ohio.



                                                         Stump- 5