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


  • 141 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

PowerPoint Slideshow about 'The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, An' - lore


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