David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

18
David David Grizzanti Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study

Transcript of David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Page 1: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

David GrizzantiDavid Grizzanti

Evaluating Software Reuse Alternatives: An Industrial Case Study

Page 2: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

IntroductionIntroduction

Software reuse results in: Lower costs Shorter delivery time.

Software reuse factors include the product line approach and the involvement of core assets

Product developers decide whether to acquire these “core assets” or develop their own artifacts

Decisions should be based on collected data from past reuse scenarios

Page 3: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Reuse takes place when an existing artifact is used in the development of a software product.

Two types of reuse: black-box and white-box. Before any reuse can take place, domain analysis must

be conducted. Domain Analysis begins with information gathering and

results in candidates for reuse. Related Work

Using software reuse alternatives Hewlett-Packard (HP) saw a defect reduction of 15% and a 57% increase in productivity.

Reuse ConceptsReuse Concepts

Page 4: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Cost of reuse software can be divided into 3 general categories:

Production Construction:Asset Acquisition CostAsset Development CostProduct Integration, Verification, and Validation Cost

Core-Asset Construction:Asset Acquisition CostAsset Development Cost

Infrastructure Construction:Repository Establishment and Maintenance CostRepository Storage and Cataloging CostDomain Analysis (DA) Cost

Reuse: Costing PoliciesReuse: Costing Policies

Page 5: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

The ModelThe Model

Software construction in the underlying model is described along three axes:

Development Maintenance Reuse

Artifacts have to be stored and cataloged in the core-assest repository before being transferred between software products.

Page 6: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

The ModelThe Model

Mining - Fetching products and copying them into the repository

Acquisition - Copying artifacts from the repository into specific products

There are two types of Assets: Repository Assets – cataloged in core-asset

repository Private Assets – contained within a product and are

available for mining or acquisition.

Page 7: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Elementary OperationsElementary Operations

Transformation Operations: Adaptation for Reuse (AR) New for Reuse (NR) White-Box Reuse (WB) New Development (ND)

Transition Operations: Cataloged Asset Acquisition (CA) Black-Box Reuse (BB) Mining and Cataloging (MC) Copy and Paste (CP) eXternal Acquisition (XA)

Page 8: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Case Study ExampleCase Study Example

Develop two software products Both need a queue structure One in C++, one in Java Previous product implemented

the same structure, except in Ada.

Reverse-engineer the Ada package to an object-oriented class design

Sequence of operations:MC→ AR → CA → WB

A reuse scenario was employed here

To determine the best reuse scenario, compare the relative cost of alternative scenarios

Page 9: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Cost ComponentsCost Components

Operations involve two assets: Source Asset Target Asset

Cost of Transformation OperationsCAR (R,R’) CNR (R’)

CWB (P,P’) CND (P’)

Cost of Transition OperationsCCA (R,P) CCP (P)

CMC (P,R) CXA (R)

CBB (R’,P’)

Page 10: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Applying Cost PoliciesApplying Cost Policies

Costing policy table can easily be adapted to accommodate other cost directives.

Empty – N/A to operation Full – Full cost to operation Part – Partial cost to

operation Costs usually incurred

when activity doesn’t involve resulting artifact

Page 11: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Typical Reuse ScenariosTypical Reuse Scenarios

Pure Development (PD) Target components are developed from scratch

Opportunistic Reuse (OR) Artifacts exist for reuse, but must be searched for

Controlled Reuse (CR) Artifacts are cataloged unchanged then modified for use

Systematic Reuse (SR) Artifacts are mined, cataloged, and modified for future

acquisition

Alternative Systematic Reuse Artifacts are created from scratch and then cataloged

Page 12: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Industrial ExperienceIndustrial Experience

Model was implemented by ISWRIC (Israel SoftWare Reuse Industrial Consortium), a joint project of seven Israeli companies

Three are mainly defense contractors The other four produce customizable commercial

products Six of the companies defined and evaluated reuse

scenarios

Page 13: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Industrial ExperienceIndustrial Experience

Sytematic Reuse Implemented by five companies

Three implemented systematic reuse of reusable assets Two implemented systematic reuse on existing assets

Controlled Reuse Implemented by one company

Reusable assets brought to degree where each product can use these assets for specific needs

Use of this model in Industry has demonstrated its potential benefits to various reuse scenarios

Page 14: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Industrial Experience - TES Case StudyIndustrial Experience - TES Case Study

Tadiran Electronic Systems Ltd., adopted the controlled reuse scenario

Established a reuse repository Allocated resources to each “team” to perform

Adaptation for Reuse Products were identified as candidates for reuse through

Domain Analysis Four of the assets were software modules with

sophisticated hardware elements The other three were generic human-computer interface

modules

Page 15: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

TES Case Study ResultsTES Case Study Results

Cost, in person-hours (bold numbers were actually measured whereas others were estimated)

Except for Asset 5, the implemented scenario achieved the least cover over all alternatives

Asset 5, however shows that systematic reuse would have faired better

Page 16: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Alternative Reuse SavingsAlternative Reuse Savings

Between Systematic and Controlled Reuse, largest saving was 63% (Asset 7), and lowest savings was -28% (Asset 5)

Savings relative to Opportunistic Reuse were between 1-65% and in comparison to Pure Development, it was between 42-81%

Page 17: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

Conclusions and Further WorkConclusions and Further Work

Results based on estimated data are subject to inaccuracies If applied consistently, cumulated data can be analyzed for

better estimates Two major contributions:

Cost model provides a practical tool for developers to test different scenarios

Provides a mechanism to analyze and evaluate scenarios at an organizational level

Other features, such as time-to-market and product quality also improve with reusing software assets

In the future, working to include models for these attributes

Page 18: David Grizzanti Evaluating Software Reuse Alternatives: An Industrial Case Study.

ReferencesReferences

Tomer, Amir; Goldin, Leah; Kuflik, Tsvi; Kimchi, Esther; Schach, Stephen R. "Evaluating Software Reuse Alternatives: A Model and Its Application to an Industrial Case Study." IEEE Transactions on Software Engineering. Volume: 30. Issue: 9. September 2004. pp:601-612

P. Clements and L.M. Northrop, Software Product Lines: Practices and Patterns. Addison-Wesley, 2001.