slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, An PowerPoint Presentation
Download Presentation
The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, An

Loading in 2 Seconds...

play fullscreen
1 / 32

The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, An - PowerPoint PPT Presentation


  • 143 Views
  • Uploaded on

The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, Anita Gupta Trondheim, 28th May 2009. Overview. Introduction Company Background Research Design Results and Contributions Lessons Learned and Future Work. Introduction.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, An


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

TheProfile of Software Changes in Reused vs. Non-Reused Industrial Software Systems

Doctoral thesis presentation,

Anita Gupta

Trondheim, 28th May 2009

Anita Gupta 28/05/2009

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

Anita Gupta 28/05/2009

introduction
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.

Anita Gupta 28/05/2009

motivation
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.

Anita Gupta 28/05/2009

research goal
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.

Anita Gupta 28/05/2009

research challenges
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).

Anita Gupta 28/05/2009

research questions
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?

Anita Gupta 28/05/2009

software reuse and component
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].

Anita Gupta 28/05/2009

software changes
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

Anita Gupta 28/05/2009

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

Anita Gupta 28/05/2009

statoilhydro asa background
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.

Anita Gupta 28/05/2009

relation between jef dcf and s a
Relation between JEF, DCF and S&A

Anita Gupta 28/05/2009

characteristics of the systems
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.

Anita Gupta 28/05/2009

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

Anita Gupta 28/05/2009

research design
Research Design
  • Quantitativestudies - 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 methodshas been:
    • Exploiting all available data, wider insight.
    • Triangulation of data/methods.

Anita Gupta 28/05/2009

research overview
Research Overview

Phase 1

Phase 2

Phase 3

C1

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

2008

C1

Case study of

Change Requests

(quantitative/qualitative)

2006-2007

P4

P2

C3

C3

P6

P3

Survey on developers’ views on software reuse

(quantitative/qualitative)

2004-2005

C4

P1

C4

C2

Case study of

Trouble Reports

(quantitative/qualitative)

2006-2007

P3

C3

P5

C4

June 2008

August 2004

Results of study A lead to conducting study B

Paper

Anita Gupta 28/05/2009

Contribution

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

Anita Gupta 28/05/2009

results of rq1
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.

Anita Gupta 28/05/2009

results of rq2
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 ofJEF.
    • 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.

Anita Gupta 28/05/2009

results of rq3
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

Anita Gupta 28/05/2009

slide21

Systematic reuse

  • Lower defect densities of all types of defects, including:
  • assignment
  • checking
  • algorithm
  • data
  • timing
  • interface
  • relationship
  • GUI
  • function

-

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

Lower defect density of the function-type defects

-

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

Back to slide 22

Back to slide 27

Anita Gupta 28/05/2009

summary of the findings
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.

Anita Gupta 28/05/2009

overall discussion of results
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

Anita Gupta 28/05/2009

contributions rq and papers
Contributions, RQ and papers

Anita Gupta 28/05/2009

contributions to sevo project goals
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.

Anita Gupta 28/05/2009

contributions to statoilhydro asa
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.

Anita Gupta 28/05/2009

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

Anita Gupta 28/05/2009

lessons learned 1
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.

Anita Gupta 28/05/2009

lessons learned 2
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.

Anita Gupta 28/05/2009

lessons learned 3
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.

Anita Gupta 28/05/2009

future work
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.

Anita Gupta 28/05/2009

acknowledgements
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.

Anita Gupta 28/05/2009