1 Anita Gupta 28/05/2009 The Profile of Software Changes in Reused vs. Non-Reused Industrial...

Anita Gupta 28/05/2009

1

The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems

Doctoral thesis presentation,

Anita Gupta

Trondheim, 28th May 2009


2

Overview

• Introduction

• Company Background

• Research Design

• Results and Contributions

• Lessons Learned and Future Work


3

Introduction

• Main focus: Investigate the relation between software changes and software reuse, and propose reuse guidelines based on these insights.– Trouble reports, change requests and changes in the code.

• Research done in a large Norwegian oil and gas company, StatoilHydro ASA.

• The SEVO project – Software EVOlution in Component-Based Software Engineering project (2004 to 2008) tries to understand

software evolution, focusing on CBSE technology.


4

Motivation

• Software organizations (and researchers) have always been looking for effective strategies to develop quality software quicker and cheaper.

• CBSE (Component-Based Software Engineering) is a potential technology to improve quality and time-to-market.– “the development of software by composing independent,

deployable components” [Sommerville04].

• Our ability to develop and maintain such software is still inadequate.

• Software changes is an important source of information for studying software reuse, evolution and maintenance.


5

Research Goal

• Investigate the advantages/disadvantages of systematic software reuse by analysing software change data (including both defect and non-defect changes).

• Then, based on these insights, propose specific reuse guidelines (as an example of improvements) to StatoilHydro ASA, as well as general recommendations to software practitioners.


6

Research Challenges• Indirect indicators of software quality, especially maintainability

and reliability:– Defect density, CR density and change density not standard

quality measures (RQ1).• Software reuse and its relation to software changes:

– Few empirical studies have done convincing cause-effect analysis between software reuse and reduced defect and change density (RQ1).

• Software evolution and maintenance:– Few studies have compared the change profile of a reused

framework vs. software reusing it (RQ2).• Potential advantages/disadvantages of software reuse:

– Challenges to reuse (and CBSE) are organizational, managerial and technological (RQ3).


7

Research Questions

• RQ1. What is the relation between software changes and software reuse, by comparing the reused framework vs. software reusing it?

• RQ2. How do the reused framework and software reusing it evolve over time?

• RQ3. What improvements can be made towards the actual reuse practice at StatoilHydro ASA?


8

Software Reuse and Component

• Software reuse: “is the systematic practice of developing software from a stock of building blocks..” [Morisio02]. – For instance, program libraries, COTS and OSS

components, or entire software architectures. – A reused component in this study is a component

that is reused in more than one product. – Two distinct activities: development for and with

reuse.• Component: one of the parts that make up a software

[emphasis added] system. May be a hardware/software and subdivided into other components [IEEE90].


9

Software Changes

• Defect changes – Trouble Reports (TRs)– Results in several corrective changes

• Non-defect changes – Change Requests (CRs)– Consists of perfective, adaptive and preventive

changes• Changes in the code

– Resulted from:• Defect Changes• Non-Defect Changes• Others


10

Overview

• Introduction

• Company Background• Research Design• Results and Contributions• Lessons Learned and Future Work


11

StatoilHydro ASA Background

• Oil and gas company with 31000 employees.• Reuse strategy was initiated in 2003.• 100 developers in the IT department, 16 of them working

with JEF, DCF and S&A. • Framework is called the “JEF framework” (20 KNSLOC). • JEF is reused in two applications “as-is”:

– DCF, Digital Cargo Files (25 KNSLOC)– S&A, Shipment & Allocation (64 KNSLOC)– and in other projects

• Data from three releases of JEF, DCF and S&A are analysed.


12

Relation between JEF, DCF and S&A


13

Characteristics of the systems

• Seven components in JEF as a combination of COTS (Commercial-Off-the-Shelf), OSS (Open Source System) components, and in-house built code, initially only in-house built.

• Development technology: Java, J2EE, and SPRING framework (OSS).

• Software Configuration Management (SCM): Rational ClearQuest and Rational ClearCase tools.


14

Overview

• Introduction• Company Background

• Research Design• Results and Contributions• Lessons Learned and Future Work


15

Research Design• Quantitative studies - exploring company databases

(“data mining”) and assessing research questions/hypotheses.

• Qualitative studies – textual web pages and documents and oral interview/discussions with developers. Combined with quantitative studies.

• Three case studies and a small survey. • Rationale for mixed methods has been:

– Exploiting all available data, wider insight.– Triangulation of data/methods.


16

Research Overview

Case study of Trouble Reports

(quantitative/qualitative)

2006-2007

Case study of Change Requests(quantitative/qualitative)

2006-2007

Case study of change data related to the source code (quantitative/qualitative)

2008

August 2004 June 2008

C1

C2

P3

P3

P5

P6

P4P2

C3

C3

C1

C3

C4

C4

Paper

Contribution

Results of study A lead to conducting study B

Survey on developers’ views on software

reuse

(quantitative/qualitative)

2004-2005

C4P1

Phase 1 Phase 2 Phase 3


17

Overview

• Introduction• Company Background• Research Design

• Results and Contributions• Lessons Learned and Future Work


18

Results of RQ1

• RQ1: What is the relation between software changes and software reuse, by comparing the reused framework vs. software reusing it? – Systematic software reuse policy have helped to reduce the

defect density of the reused software.– Interface-type defects higher for JEF than DCF and S&A. – Function-type defects higher for DCF and S&A:

• Higher time-to-market pressure, unstable requirements and less quality control.

– Cautious to involve changes into JEF.– The dominant change type is perfective changes, i.e.

new/changed requirements and optimizations.


19

Results of RQ2

• RQ2: How do the reused framework and software reusing it evolve over time? – Good initial design and stable requirements have reduced

the change rate of JEF. – Functionality and development practices affected

maintenance mostly for JEF, DCF and S&A. Age and size affected it least.

– Change profile for JEF and DCF were in line with the stage model proposed by [Bennett00], while S&A was different.

– JEF went faster from the stage of extending capabilities to the stage where minor defect repairs are made than DCF.


20

Results of RQ3

• RQ3: What improvements can be made towards the actual reuse practice at StatoilHydro ASA? – Late-coming developers did not know about the existence of

a reuse training programme. – Shared information and experience repository would be

beneficial for software reuse. – Analysis of CRs and TRs to improve current reuse process.– Updated software change reporting scheme, so that more

correct and more complete information is reported:• Precise effort data • Component level information • Development phase information


21

Back to slide 22

Back to slide 27

Systematic reuse

Software maturity curve

Systematic reuse policy, e.g. to provide incentives to prevent and remove defect earlier in the life cycle

Systematic reuse policy, e.g. less changes performed on the reused components

The inherent properties (e.g. complexity, algorithm, size) of the reused software

Systematic reuse policy, e.g. reuse functionality is more likely to be well defined

Systematic reuse policy, e.g. adoption of a domain specific library

Lower defect density of the function-type defects

+/-

-

-

-

-

-

Lower defect densities of all types of defects, including:

• assignment

• checking

• algorithm

• data

• timing

• interface

• relationship

• GUI

• function


22

Summary of the Findings

• Applications reusing JEF:– Faces more unstable requirements, longer time-to-market

pressure, and less quality control.• The reused software, JEF:

– Does not have a lower defect and change density than non-reused software.

– Does not reduce the density of the most severe defects.• Should define and implement a systematic reuse policy. • We have proposed specific reuse guidelines to StatoilHydro ASA,

and general recommendations to software practitioners.


23

Overall Discussion of Results

• Can we indicate that software developed for reuse is likely to be more stable vs. software developed with reuse? – We cannot!

• The lower defect density, CR density and change density for JEF over its releases:– Software maturity curve, progressively in lower layers.– Software reuse policy.– The inherent properties (e.g. complexity, algorithm, size) of

JEF; is a generic framework, and has less business logic than DCF and S&A. Figure


24

Contributions, RQ and papersContribution Paper

C1. Differences/similarities of the change profile for the reused framework vs. software reusing it. (RQ1)

P2, P4, P6

C2. Differences/similarities of the defect profile for the reused framework vs. software reusing it. (RQ1)

P5

C3. Description of the software change lifecycle for the reused framework vs. software reusing it. (RQ2)

P3, P6

C4. Identification of possible software reuse improvements. (RQ3)

P1, P5, P6


25

Contributions to SEVO project goals

• G1. Better understanding of software evolution, focusing on CBSE technology. Better understanding of software maintenance and reuse benefits and challenges. Contributions C1, C2 and C3.

• G2. Better methods to predict the risks, costs and profile of software evolution in CBSE. Improvements towards software reuse. Feedback given to StatoilHydro ASA. Contribution C4.

• G3. Contributing to a national competence based around these themes, and G4. Disseminating and exchanging the knowledge gained. Results published at international/national conferences and workshops. Masters’ students involved. Contributions C1-C4.


26

Contributions to StatoilHydro ASA• Upgrade defect and change reporting: To include effort data,

and affected software components.

• Improved configuration management: Rational ClearQuest and Rational ClearCase should be better integrated.

• Improvements related to the O&S Masterplan (specific to StatoilHydro ASA): – Specific recommendations towards reuse, and at one place.– Define the terms: quality, time and cost. – The Masterplan should be more precise and to the point. – The organizational regulations should be less strict and more

visible for the users in the company.


27

Overview

• Introduction• Company Background• Research Design• Results and Contributions

• Lessons Learned and Future Work


28

Lessons Learned (1)

• Software reuse: Recommendations to Researchers– Diverse factors influence the relation between

software reuse and (lower) defect density. Figure– Must consider functionalities and software

development practices. – Defect and change request density correlate

significantly with reliability [Li03], but does not represent causality.


29

Lessons Learned (2)

• Software reuse: Recommendations to StatoilHydro ASA practitioners– Improve their way of reporting software changes. – Careful quality control or testing of reused

software to reduce the possible interface defects.– Staff who understand the reused software must be

retained in the organization for a while after initial development of legacy code.


30

Lessons Learned (3)

• Software reuse: Recommendations to Software Practitioners in General– Define and implement a systematic reuse policy to

reduce the defect density of reused software.– GQM feedback – improve precision of data collection

in the short run.– Changes to the development process should be

suggested in the long run. – Recording of available information and simple

analysis.


31

Future Work

– Revising last paper (submitted to IST journal): Added complexity measures, and the new results indicate that JEF has a lower change density than both DCF and S&A.

– Estimate software reliability by defect and change density. – Further studies on software evolution and maintenance. – Test processes for reused vs. non-reused software. – Effort distribution related to removing the causes of the most

costly defects. – Amount of COTS or OSS used in the software projects, and

integration problems. – StatoilHydro ASA’s reuse practices. – Aspects of software components that make them more or

less fit for reuse.– Agile development methods vs. waterfall models.


32

Acknowledgements

• Thanks to SEVO (contract number 159916/V30), and NTNU for financial support.

• Thanks to my supervisor, Prof. Reidar Conradi and colleagues at SEVO and IDI, Dr. Jingyue Li, Odd Petter Slyngstad and Dr. Daniela Cruzes.

• Thanks to StatoilHydro ASA, Harald Rønneberg and Einar Landre, for the permission to perform studies and to publish the results.

Date post:	13-Dec-2015
Category:	Documents
Upload:	reynard-gordon
View:	217 times
Download:	0 times

1 Anita Gupta 28/05/2009 The Profile of Software Changes in Reused vs. Non-Reused Industrial...

Documents