ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr4/proceedings/ascii/nishimoto.ascii

Internet Message Format | 1991-10-31 | 10KB

From [e-mail] Thu Oct 31 20:37:26 1991
Received: from hplms2.hpl.hp.com by gandalf.umcs.maine.edu (5.59/1.34-seg070391)
    id AA00883; Thu, 31 Oct 91 20:02:36 EST
Received: from hplmlg.hpl.hp.com by hplms2.hpl.hp.com with SMTP
    (16.5/15.5+IOS 3.20) id AA10615; Thu, 31 Oct 91 10:38:09 -0800
Received: from localhost by hplmlg.hpl.hp.com with SMTP
    (15.11/15.5+IOS 3.14) id AA23436; Thu, 31 Oct 91 10:39:27 pst
Message-Id: <[e-mail]>
To: [e-mail]
X-Location: 1U, post H13
X-Phone: [phone]
Subject: Alvina's paper
Date: Thu, 31 Oct 91 10:39:25 PST
From: Martin Griss <[e-mail]>
Status: RO

She asked me to send this for here to you, so you can strat the
formating job.

She cant easily send email out of HP.

Martin


------- Forwarded Message

Return-Path: [e-mail]
Received: from hplms1.hpl.hp.com by hplmlg.hpl.hp.com with SMTP
    (15.11/15.5+IOS 3.14) id AA23256; Thu, 31 Oct 91 07:33:44 pst
Return-Path: <[e-mail]>
Received: by hplms1.HPL.HP.COM; Thu, 31 Oct 91 07:32:08 pst
Date:        31 Oct 91 07:14 -0800
Subject:     Reuse Paper
Message-Id:  <[e-mail]>
X-Hpdesk-Priority: 2
X-Hpdesk-System:  261
To: [e-mail]
To: [e-mail]
From: [e-mail]
Received: from ux@hp1900 by hplabs; 31 Oct 91 7:30:49-PST (Thu)

Martin,

This message contains the ASCII verion of my paper.  I have
sent by Federal Express today the following:

* Two formatted copies of my position paper
* IBM-compatible floppy disc with an ASCII version of the file
* Registration fee of $100
* Registration information below

Name:                 Alvina Nishimoto
Name to be on Badge:  Alvina Nishimoto
Affiliation:          Hewlett-Packard Company, Manufacturing
                      Productivity Operation
Address:              5301 Stevens Creek Blvd., M/S 51U/92
                      Santa Clara, CA  95051
Phone:                [phone]
FAX:                  [phone]
EMAIL:                [e-mail]


Thanks,

Alvina



Program of Reuse at Manufacturing Productivity Operation

Alvina Nishimoto

Hewlett-Packard Company
Manufacturing Productivity Operation
5301 Stevens Creek Blvd.  M/S 51U/92
Santa Clara, CA  95051
408-553-3682, [e-mail]


Abstract

This paper describes a program of reuse that began in January 1984 with a new MP

*    How the program was initiated and how our definition of reuse has changed over
*    How the program evolved to include other already existing products
*    Development of the fix process for reuse components
*    Coordination issues between products and the formation of the Shared Component
*    Results of reuse metrics
*    What lessons we learned and suggested areas for improvement

Major emphasis is on what we learned along the way and how our reuse program has

Keywords:  re-engineering for reuse, reuse maintenance process, reuse councils,



Getting Started

In January 1984, Manufacturing Productivity Operation (MPO) launched a fast trac

*    To invent a high-quality software product where there was none before, either

*    To meet all scheduled milestones, the most important being the manufacturing r

*    To increase the productivity of engineers in designing this type of software p

Several members of the project team had worked on the division's flagship produc

supporting this product. We had "cloned" so much of the product, meaning that a

We had many service requests that we classified as "generic", indicating that th

We placed many of the common calls to our tools layer inside of utility subrouti



*** Object: DOS: SEPC0100


Figure 1

The initial impetus behind the development of this reuse code was to avoid dupli

Expansion to Other Products

After the manufacturing release of the product, a couple of the team's members m

Interestingly enough, we found out that using reused code for another product in

*    Training to help people understand when and how to use the reused code.  Unles

*    Code templates to provide engineers with a framework for which to write a tran

*    Reuse code changes to support the new and larger scope of functionality and us

*    An initial investment of six engineering months with ongoing additional effort

*    A new set of responsibilities that required engineers to make ongoing modifica

*    Making reuse a part of the development process. We set up metrics to help meas

    - Improper utility (reuse) usage
    - Redundant code
    - Creation of new utilities (reuse code)
    - Not using an already established utility (reuse code)

We also measured the NCSS (non-commented source statements) for the reuse code v

Despite the fact that MPO cancelled this project to rewrite MM/3000, we took thi

Figure 3 shows distribution of the code for this enhancement to Materials Manage



*** Object: DOS: SEPC0400


Figure 2



*** Object: DOS: SEPC0500


Figure 3


Fix Process for Reuse

The fix process for supporting a reuse product could be characterized by the fol

*    Although reuse code tends to create smaller code units allowing for smaller de

*    With more code components, it was sometimes difficult to identify a component

*    Initially, when new products added the reuse code, there were many changes in

    Because of the testing effort involved with these utilities, we often got to a

    In some cases where the rework effort was too large, we replaced a piece of reu

*    As more products began to use the reuse code, we found that it became necessar

    An example of this was a utility that displayed information on whether a datase

*    As the number of transactions and programs using reuse code grew, the testing

    We, in the beginning, felt that we needed to test each affected transaction or


Reuse Inspection and Metrics Analysis

Encouraging the use of reuse code was included as an important part of our inspe

*    Design Change
    - Work-in-process utilities that should be considered

*    Enhancement
    - Logic that should be made into a NEW application or architecture utility

*    Utility Usage
    - Defects in the parameter list
    - Defects in initialization of the parameter list
    - Incorrect usage of a utility
    - Not using an established utility



Figures 4 and 5 show examples of the utility usage category for mini-releases re

We also track service requests from our customers that occur in reuse code and h



*** Object: DOS: NC540000


Figure 4



*** Object: DOS: CDEFCAT0


Figure 5


Current Situation

MPO today has the following number of shared components:

- -    Shared (include files rather than callable routines)           9
- -    Utilities (callable routines)                                     200
- -    Internal documentation for shared code and utilities        209
- -    Data dictionary elements (approximation only)                 40
- -    Shared messages                            210
- -    Testing tools (created by MPO)                                 16

We have shared and reuse code broken down as follows:
- -    Shared (include files rather than callable routines)     16,100 NCSS
- -    Utilities (callable routines)                               24,900 NCSS
- -    Generated                                28,300 NCSS

In addition to the above code, we have a tools layer of reuse code (not included

As more and more products began to use the reuse code, coordination issues began

As this situation became more critical, we organized a group called the "Shared

*    Continue to evolve a process that allows for different groups to work on share

*    Communicate changes for shared components and proactively assess the impact to

*    Foster a process that allows us to continually add to our library of shared co

Some of the strategies to address these objectives include:

*    Definition of the shared component process that include:

    -    Update process
        Process for informing people impacted by the change and how to go about the im

    -    Checkout/checkin procedures
        How to checkout and checkin components, what tags should be used, and how the

- -    Synchronization process
        Process for the creation of multiple versions of a shared component and how th

- -    Release account management
        How the latest version of shared components are distributed to various product

- -    Testing strategy
        What type of testing should be done and what should be considered when testing

*    Regular update to discuss future additions and changes to shared components to

*    Regular communication of changes to shared components during critical periods,

*    Regular communication of distribution processes to ensure that each applicatio

*    Regular communication of new components to ensure that there is a minimum of d



Benefits of the Reuse Program

*    Quality

    Reused code has much better quality than unique code. We have found that reused

    Relying on many shared utility procedures eliminates the risk of errors caused

*    Consistency and Standardization

    Perhaps the best benefit results from the consistency and standardization that

    Eliminating code duplication not only reduces overall code length, but also red

*    Productivity

    Code maintenance and product enhancement are made simpler since a correction or

    Some reuse code can be used by similar software systems, saving time and effort


Conclusions

*    Initial Investment

    There is some initial investment that must be done with any reuse program. At M

*    Coordination Effort

    As more and more products use the reuse code, the coordination effort between t

*    Long term versus short term productivity

    A reuse program requires both an initial investment and an ongoing investment a

The following summarizes the key benefits and the prerequisites to success:

Benefits                                      Prerequisites to Success
High quality                                  High initial investment
Consistency and standardization           Detailed planning
Productivity                                   High coordination between engineering team
Reduced support costs                     Source code management system
                        Testing strategy
                        Documentation of reuse routines
                        Defined maintenance process
                        Measurement system that supports reuse
Acknowledgments

Thanks to Nancy Federman and Raj Bhargava for their support of the initial reuse


References

Bhargava, Raj K.; Lombardi, Teri L.; Nishimoto, Alvina Y.; and Passell, Robert A



------- End of Forwarded Message