Sandeep Krishnan, ISU Robyn R. Lutz, ISU & JPL Katerina Goseva-Popstojanova, WVU Dept. of Computer Science, Iowa State University, MSR, May 22, 2011 1.

Slides:



Advertisements
Similar presentations
TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Advertisements

Kapitel 21 Astronomie Autor: Bennett et al. Galaxienentwicklung Kapitel 21 Galaxienentwicklung © Pearson Studium 2010 Folie: 1.
Slide 1 Insert your own content. Slide 2 Insert your own content.
Chapter 27 Software Change.
Chapter 27 Software Change.
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 5 Author: Julia Richards and R. Scott Hawley.
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 4 Author: Julia Richards and R. Scott Hawley.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
Building a Knowledge Management System as a Life Cycle
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
BGP01 An Examination of the Internets BGP Table Behaviour in 2001 Geoff Huston Telstra.
Source of slides: Introduction to Automata Theory, Languages and Computation.
Combining Like Terms. Only combine terms that are exactly the same!! Whats the same mean? –If numbers have a variable, then you can combine only ones.
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Title Subtitle.
Multiplying binomials You will have 20 seconds to answer each of the following multiplication problems. If you get hung up, go to the next problem when.
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
ADDING INTEGERS 1. POS. + POS. = POS. 2. NEG. + NEG. = NEG. 3. POS. + NEG. OR NEG. + POS. SUBTRACT TAKE SIGN OF BIGGER ABSOLUTE VALUE.
MULTIPLICATION EQUATIONS 1. SOLVE FOR X 3. WHAT EVER YOU DO TO ONE SIDE YOU HAVE TO DO TO THE OTHER 2. DIVIDE BY THE NUMBER IN FRONT OF THE VARIABLE.
SUBTRACTING INTEGERS 1. CHANGE THE SUBTRACTION SIGN TO ADDITION
MULT. INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Teacher Name Class / Subject Date A:B: Write an answer here #1 Write your question Here C:D: Write an answer here.
Addition Facts
Making the System Operational
CS4026 Formal Models of Computation Running Haskell Programs – power.
Chapter 12 Analysing quantitative data
Earnings Differences Between Ethnic Groups: Evidence from the LFS * Ken Clark University of Manchester Stephen Drinkwater University of Surrey November.
ZMQS ZMQS
Presented by the Illinois Department of Insurance Andrew Boron, Director November 2012.
Configuration management
Software change management
What Is Cost Control? 1 Controlling Foodservice Costs OH 1-1.
Testing Workflow Purpose
© 2011 TIBCO Software Inc. All Rights Reserved. Confidential and Proprietary. Towards a Model-Based Characterization of Data and Services Integration Paul.
ABC Technology Project
O X Click on Number next to person for a question.
© S Haughton more than 3?
5.9 + = 10 a)3.6 b)4.1 c)5.3 Question 1: Good Answer!! Well Done!! = 10 Question 1:
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
1 Directed Depth First Search Adjacency Lists A: F G B: A H C: A D D: C F E: C D G F: E: G: : H: B: I: H: F A B C G D E H I.
Page 1 October 31, 2000 An Introduction to Large-Scale Software Development Steve Varnau Core HP-UX Operation October 31, 2000.
Twenty Questions Subject: Twenty Questions
Take from Ten First Subtraction Strategy -9 Click on a number below to go directly to that type of subtraction problems
The world leader in serving science TQ ANALYST SOFTWARE Putting your applications on target.
Squares and Square Root WALK. Solve each problem REVIEW:
Software Processes.
1 Lift-off Heights of Turbulent H2/N2 Jet Flames in a Vitiated Co-flow Zhijun WU, Sten H STÅRNER and Robert W BILGER The University of Sydney Dec 2003.
Requirements Analysis Moving to Design b521.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis.
Chapter 11 Software Evolution
Past Tense Probe. Past Tense Probe Past Tense Probe – Practice 1.
This, that, these, those Number your paper from 1-10.
GG Consulting, LLC I-SUITE. Source: TEA SHARS Frequently asked questions 2.
Addition 1’s to 20.
25 seconds left…...
Test B, 100 Subtraction Facts
11 = This is the fact family. You say: 8+3=11 and 3+8=11
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 1,3 Slide 1 Software Engineering Software Engineering.
Determining How Costs Behave
Week 1.
We will resume in: 25 Minutes.
1 Unit 1 Kinematics Chapter 1 Day
O X Click on Number next to person for a question.
How Cells Obtain Energy from Food
Chapter 16: Correlation.
1 Implementing DDIEditor in the Danish Data Archive - Demonstration and gained experience Part of session: Recent Developments in the DDI Implementation.
CHAPTER 4 - DEMAND Chapter Introduction Section 1: What is Demand?
1 The FreeBSD Project: a Replication Case Study of Open Source Development.
Presentation transcript:

Sandeep Krishnan, ISU Robyn R. Lutz, ISU & JPL Katerina Goseva-Popstojanova, WVU Dept. of Computer Science, Iowa State University, MSR, May 22, This research is supported by NSF grants and

Background Product line – A family of products designed to take advantage of their common aspects and predicted variabilities [Weiss and Lai 1999] e.g. Nokia cellphones, HP printers, etc. Products - Commonalities – Shared by all products. e.g. Platform Variabilities – Differentiate the products High-reuse variation – JDT, PDE, Mylyn, Webtools, etc. Low-reuse variation – CDT, Datatools, Java EE tools. Dept. of Computer Science, Iowa State University, MSR, May 22,

Motivation Does reliability improve as a product line evolves? Dept. of Computer Science, Iowa State University, MSR, May 22, PL EvolutionReliability Reliability – Continuity of correct service; measured in terms of post-deployment failures [Avizienis, et al., 2001]

Research Questions Failure trends: Do serious failures decrease over time as the common/high-reuse variation/ low-reuse variation components evolve over releases? Change trends: Does the percentage of new files and/or modifications to the source code decrease across releases for common/ high-reuse variation/ low-reuse variation components? Failure/Change relationships: Does the number of serious failures normalized for source-code changes decrease over time for the common/ high-reuse variation/ low-reuse variation components? Dept. of Computer Science, Iowa State University, MSR, May 22,

Findings Failure trends: Do serious failures decrease over time as the common/high-reuse variation/ low-reuse variation components evolve over releases? Common High-reuse Low-reuse Change trends: Does the percentage of new files and/or modifications to the source code decrease across releases for common/ high-reuse variation/ low-reuse variation components? Common High-reuse Low-reuse Failure/Change relationships: Does the number of serious failures normalized for source-code changes decrease over time for the common/ high-reuse variation/ low-reuse variation components? Common High-reuse Low-reuse Dept. of Computer Science, Iowa State University, MSR, May 22,

Approach Source of failure reports- Failure cateogries – Raw number of severe failures and percentage. Source of change reports – CVS repository of Eclipse. We look at change to existing files measured by KChanges and change via new files [Mockus et al., 2000]. Dept. of Computer Science, Iowa State University, MSR, May 22, BlockerCriticalMajorNormalMinor EuropaGanymedeGalileoHelios BlockerCriticalMajor

Observations Number of severe failures decreases over time as expected Dept. of Computer Science, Iowa State University, MSR, May 22, A. Failure trends – Common components

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Percentage of severe failures tends to stabilize and even increases gradually 1. A. Failure trends – Common components

Observations Number of severe failures show mixed behavior, contrary to our expectations Dept. of Computer Science, Iowa State University, MSR, May 22, B. Failure trends – High-reuse variation components

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Percentage of severe failures tends to stabilize and even increases gradually, contrary to our expectations 1. B. Failure trends – High-reuse variation components

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Number of severe failures do not monotonically decrease; rather show mixed behavior 1. C. Failure trends – Low-reuse variation components

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Percentage of severe failures show mixed behavior and not a decreasing trend 1. C. Failure trends – Low-reuse variation components

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Change trends Common components: Percentage of new files decreases. High-reuse variation components: Percentage of new files tends to remain stable. Low-reuse variation components: Percentage of new files shows decreasing trend. All components show relatively high modification rate.

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Failure/evolution relationship Failures/new-file o Common components: For two subcomponents, release 1 has lower failures/new-file than release 4. o High-reuse variation components: Release 1 always has higher failures/new- file than release 4. o Low-reuse variation components: No specific trend.

Observations Dept. of Computer Science, Iowa State University, MSR, May 22, Failure/evolution relationship Failures/Kchanges o No stable behavior for all components; mixed trends are observed.

Conclusion Common components have fewer severe failures over time and amount of change also decreases. Variation components show no uniform pattern of decrease in failures. Even high-reuse variation components continue to change fairly rapidly. Study suggests there may be no simple answer as to whether reliability tends to improve as product line matures. Further investigation is needed on the relationship between failure and change in software product lines. Dept. of Computer Science, Iowa State University, MSR, May 22,

Dept. of Computer Science, Iowa State University, MSR, May 22,