1 07 September 2004 Parastoo Mohagheghi The Impact of Software Reuse and Incremental Development on the Quality of Large Systems Parastoo Mohagheghi, Dept.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Advertisements

Unit 2. Software Lifecycle
 2004 by SEC Chapter 2 Software Development Process Models.
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Chapter 2 – Software Processes
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Parastoo Mohagheghi- 21 Sept.2004 The Impact of Software Reuse and Incremental Development on the Quality of Large Systems Parastoo Mohagheghi Dept.
1 / 24 CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley,
SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
SE 555 Software Requirements & Specification Requirements Management.
Iterative development and The Unified process
The web application development process Basharat Mahmood, COMSATS Institute of Information Technology, Islamabad, Pakistan. 1.
Software maintenance Managing the processes of system change.
CMMI Course Summary CMMI course Module 9..
“Here’s why you need the new wheels, too…” Shawn and Steve Image from
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
High Impact Global Product Engineering Solutions ® ©2007 Symphony Service Corp. All Rights Reserved. Symphony Services is a registered trademark of Symphony.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Using IBM Rational Unified Process for software maintenance
Chapter 2 The process Process, Methods, and Tools
N By: Md Rezaul Huda Reza n
Preliminary Results from a State- of-the-Practice Survey on Risk Management in Off-The-Shelf Component-Based Development Jingyue Li 23 Nov
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Chapter 6 : Software Metrics
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Experiences with certification of reusable components in the GSN project in Ericsson, Norway Parastoo Mohagheghi and Reidar Conradi Dept. Computer and.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
Enabling Reuse-Based Software Development of Large-Scale Systems IEEE Transactions on Software Engineering, Volume 31, Issue 6, June 2005 Richard W. Selby,
An Introduction to Software Engineering
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Anita Gupta 28/05/2009 The Profile of Software Changes in Reused vs. Non-Reused Industrial Software Systems Doctoral thesis presentation, Anita Gupta.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Evolution in Open Source Software (OSS) SEVO seminar at Simula, 16 March 2006 Software Engineering (SU) group Reidar Conradi, Andreas Røsdal, Jingyue Li.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Experience from Studies of Software Maintenance and Evolution Parastoo Mohagheghi Post doc, NTNU-IDI SEVO Seminar, 16 March 2006.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
1 Practical Experience with Software Evolution in Statoil ASA SEVO Seminar, 16 March 2006 Odd Petter N. Slyngstad and Anita Gupta, Practical Experience.
Software Architecture Architecture represents different things from use cases –Use cases deal primarily with functional properties –Architecture deals.
CS223: Software Engineering Lecture 32: Software Maintenance.
Chapter 8: Maintenance and Software Evolution Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014,
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
CS 389 – Software Engineering Lecture 2 – Part 2 Chapter 2 – Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
ITIL: Service Transition
Overview Software Maintenance and Evolution Definitions
CS4311 Spring 2011 Process Improvement Dr
Chapter 18 Maintaining Information Systems
The Web Application Development Process Models
Software Life Cycle “What happens in the ‘life’ of software”
The Systems Engineering Context
Introduction to Software Engineering
Chapter 2 – Software Processes
Chapter 9 – Software Evolution and Maintenance
Software Engineering I
Software metrics.
Software Process Adaptation
Automated Analysis and Code Generation for Domain-Specific Models
Presentation transcript:

1 07 September 2004 Parastoo Mohagheghi The Impact of Software Reuse and Incremental Development on the Quality of Large Systems Parastoo Mohagheghi, Dept. Computer and Information Science (IDI), University of Science and Technology (NTNU), Trondheim

2 07 September 2004 Parastoo Mohagheghi What is this presentation about? It presents results of a series of empirical studies at Ericsson in Grimstad in It presents results of a series of empirical studies at Ericsson in Grimstad in The studies are performed during a doctoral work in the INCO project and supervised by Prof. Reidar Conradi.The studies are performed during a doctoral work in the INCO project and supervised by Prof. Reidar Conradi. 11 students were involved in different studies, an example of university-industry cooperation.11 students were involved in different studies, an example of university-industry cooperation. For more details, see the PhD thesis at: gheghi-thesis-10jul04-final.pdfFor more details, see the PhD thesis at: gheghi-thesis-10jul04-final.pdf gheghi-thesis-10jul04-final.pdf gheghi-thesis-10jul04-final.pdf

3 07 September 2004 Parastoo Mohagheghi Motivation Systematic software reuse, product family development and incremental development seem be potent technologies to achieve benefits in productivity, quality and maintainability, and to reduce risks of changes.Systematic software reuse, product family development and incremental development seem be potent technologies to achieve benefits in productivity, quality and maintainability, and to reduce risks of changes. Quantifiable benefits, but few empirical studies in industry that can verify these benefits or possible other impacts.

4 07 September 2004 Parastoo Mohagheghi Company background Ericsson has developed two large-scale telecom systems (470 KSLOC or 1000 KSLOC in equivalent C each) that shareEricsson has developed two large-scale telecom systems (470 KSLOC or 1000 KSLOC in equivalent C each) that share –Software architecture, –Components and a component model, –Development environment, –Software process. Systems are developed incrementally, and lots of data is gathered during 5 years on defects, changes, characteristics etc.Systems are developed incrementally, and lots of data is gathered during 5 years on defects, changes, characteristics etc.

5 07 September 2004 Parastoo Mohagheghi Overview of the Ericsson packet- switched core network- GPRS

6 07 September 2004 Parastoo Mohagheghi Evolution of the GSN software architecture and the software process model

7 07 September 2004 Parastoo Mohagheghi The GSN RUP

8 07 September 2004 Parastoo Mohagheghi Research questions RQ1. Why a reuse program is initiated and how is it implemented?RQ1. Why a reuse program is initiated and how is it implemented? RQ2. What is the impact of software reuse, Component-Based Development (CBD) and incremental development on the quality? The impact of development approaches on product quality metrics and on project attributes such as schedule or effort are sought.RQ2. What is the impact of software reuse, Component-Based Development (CBD) and incremental development on the quality? The impact of development approaches on product quality metrics and on project attributes such as schedule or effort are sought. RQ3. How to improve the practice of incremental development of product families in some aspects?RQ3. How to improve the practice of incremental development of product families in some aspects?

9 07 September 2004 Parastoo Mohagheghi Research methods Quantitative studies by exploring (‘data mining’) company databases and assessing hypotheses.Quantitative studies by exploring (‘data mining’) company databases and assessing hypotheses. Quantitative results are discussed with experienced personnel, and combined with qualitative feedbacks and studies of the process and practice to assess validity of the results.Quantitative results are discussed with experienced personnel, and combined with qualitative feedbacks and studies of the process and practice to assess validity of the results. Several case studies, a small survey and an experiment.Several case studies, a small survey and an experiment. Combining results of several studies in the interpretation phase:Combining results of several studies in the interpretation phase: –The impact of introducing reuse or incremental development is widespread. –Taking benefit of all available data, –Confirming results by other studies/data.

10 07 September 2004 Parastoo Mohagheghi Qualitative study of RUP in the context of reuse The approach to initiating a product family was an extractive one.The approach to initiating a product family was an extractive one. Software architecture has evolved to support reuse, while GSN RUP has not been adapted for reuse to the same degree.Software architecture has evolved to support reuse, while GSN RUP has not been adapted for reuse to the same degree. Examples of proposals:Examples of proposals: –“Domain analysis” and “Make vs. Reuse vs. Buy” decisions in the inception phase. –“Update reuse documentation” for reusable components. –“Record reuse experience” in the conclusion phase.

11 07 September 2004 Parastoo Mohagheghi Quantitative study of Trouble Reports (TRs) For defects detected during integration testing, system testing, or later in maintenance.For defects detected during integration testing, system testing, or later in maintenance. For defects detected in previous releases.For defects detected in previous releases. For all types of defects (software, hardware, toolbox, and documentation).For all types of defects (software, hardware, toolbox, and documentation). We have ‘data mined’ databases:We have ‘data mined’ databases: –13000 TRs for several systems and releases were parsed, data was extracted, and inserted in a SQL database by a C# program. –Inconsistencies were resolved -> Data was not analyzed. The company provided us excel sheets on software size (software module level). The company provided us excel sheets on software size (software module level).

12 07 September 2004 Parastoo Mohagheghi Hypotheses: Software Reuse and Quality (Defect-density and Stability) H01 Reused components have the same defect-density as non-reused ones. Rejected Rejected H02 There is no relation between number of defects and component size for all/reused/non-reused components. Not-rejectedNot-rejectedRejected H03 There is no relation between defect- density and component size for all/reused/non-reused components. Not-rejectedNot-rejectedNot-rejected H04 Reused and non-reused components are equally modified. Rejected

13 07 September 2004 Parastoo Mohagheghi H1: Reuse and defect-Density, Release 3 and blocks Defect-density of blocksMeanMedianVariance #TRs/KLOC, Reused #TRs/KLOC, Non-Reused #TRs/MKLOC, Reused #TRs/MKLOC, Non-Reused Reused components have lower defect density.Reused components have lower defect density. Reused components have proportionally more defects with Severity A (highest severity).Reused components have proportionally more defects with Severity A (highest severity). Reused components have proportionally less defectsReused components have proportionally less defects after delivery.

14 07 September 2004 Parastoo Mohagheghi H2: Size vs. the number of Defects

15 07 September 2004 Parastoo Mohagheghi H3: Size vs. Defect-Density

16 07 September 2004 Parastoo Mohagheghi Discussion Reuse benefits: Reused components are less defect-prone and more stable.Reuse benefits: Reused components are less defect-prone and more stable. Why? Reused components are designed more thoroughly, and changed with care.Why? Reused components are designed more thoroughly, and changed with care. –Confounding factors (conclusion validity): Programming language. Not applicable.Programming language. Not applicable. Type of functionality. Not applicable for stability, but may be for defect-density.Type of functionality. Not applicable for stability, but may be for defect-density. Developers’ experience: Not applicable.Developers’ experience: Not applicable. Internal validity: Missing data, but not systematic.Internal validity: Missing data, but not systematic. Construct validity: Are defect-density and stability indicators of quality?Construct validity: Are defect-density and stability indicators of quality? External validity: At least inside the company for similar systems, or in the domain.External validity: At least inside the company for similar systems, or in the domain.

17 07 September 2004 Parastoo Mohagheghi Contributions Research:Research: –Empirical verification of reuse benefits. No other studies on large industrial systems. –Combined with other studies in the company to assess development approaches and identifying metrics. Company:Company: –Evaluating the trouble reporting system. –Evaluating the measurement program: Granularity of component definition and data for incremental development. –Identifying defect-prone and unstable components.

18 07 September 2004 Parastoo Mohagheghi Software evolution and incremental development With incremental development, software changes:With incremental development, software changes: –during each release (development) –between successive releases (evolution) –and after delivery (maintenance). Some changes are pre-planned (incremental development) and some are not (iterative improvement, adaptive changes etc.).Some changes are pre-planned (incremental development) and some are not (iterative improvement, adaptive changes etc.). The IEEE Standard 1219 on software maintenance defines software maintenance as “The modification of a software product after delivery to correct faults (i.e. corrective), to improve performance or other attributes (i.e. perfective/preventive), or to adapt the product to a modified environment (adaptive)”.The IEEE Standard 1219 on software maintenance defines software maintenance as “The modification of a software product after delivery to correct faults (i.e. corrective), to improve performance or other attributes (i.e. perfective/preventive), or to adapt the product to a modified environment (adaptive)”.

19 07 September 2004 Parastoo Mohagheghi Quantitative study of Change Requests (CRs) Ericsson defines requirements for each release in an ARS (Application Requirement Specification).Ericsson defines requirements for each release in an ARS (Application Requirement Specification). Changes to ARS or previous deliveries (releases) are handled by issuing Change Requests (CRs).Changes to ARS or previous deliveries (releases) are handled by issuing Change Requests (CRs). –CRs handle coarse-grained changes to add/delete functionality, improve performance or improve design. –CRs cover changes during developing each release as well as between releases (in addition to new requirements stated in the ARS). How this data can be used in our research?How this data can be used in our research? –169 CRs for 4 releases of one system were analyzed. –Exploratory study: Origin (internal vs. external), acceptance rate and classes of changes are studied.

20 07 September 2004 Parastoo Mohagheghi Origin of CRs Perfective/FunctionalPerfective/ Quality Attributes (QA) AdaptivePreventive Other (cost) No CRs have indicated two reasons. Most perfective CRs are to improve QA (also preventive CRs improve quality). 23 of 169 CRs are issued because of customer demands. These and adaptive CRs have external origin (34% of all CRs).

21 07 September 2004 Parastoo Mohagheghi Acceptance Rate over Releases Acceptance rate is increasing (59% in total); i.e. the product is getting more change-prone.

22 07 September 2004 Parastoo Mohagheghi Conclusions Most changes originate from the project organization itself in order to improve quality and enhance functionality. The share of the first group is higher.Most changes originate from the project organization itself in order to improve quality and enhance functionality. The share of the first group is higher. The practice indicates that the iterative realization and improvement of quality attributes has great impact on the evolution of the products.The practice indicates that the iterative realization and improvement of quality attributes has great impact on the evolution of the products. We could not observe any significant difference between reused and non-reused components in the number of CRs per KLOC.We could not observe any significant difference between reused and non-reused components in the number of CRs per KLOC.

23 07 September 2004 Parastoo Mohagheghi Conclusions (continued) Most CRs are accepted and the acceptance rate can have impact on the project plans in terms of decreasing planning precision (observed). Incremental development opens for (more) changes.Most CRs are accepted and the acceptance rate can have impact on the project plans in terms of decreasing planning precision (observed). Incremental development opens for (more) changes. Most CRs are issued pre-delivery, and especially in the short time right after requirement baseline. The organization possibly takes the decision to baseline requirements too early.Most CRs are issued pre-delivery, and especially in the short time right after requirement baseline. The organization possibly takes the decision to baseline requirements too early.

24 07 September 2004 Parastoo Mohagheghi Overview of all studies

25 07 September 2004 Parastoo Mohagheghi Impact of dev. approaches and context Reuse Incr. dev. CBD Large systems Software evolution Change rate Earlier rel. not evolved Granularity Improved incr. Long-lived Effort estimation ROI? Software from a previous rel., Incr. changes in requirements, Large CM No data for components Large CM and testing effort Metricsyesyesyes Different granularity

26 07 September 2004 Parastoo Mohagheghi Mining industrial databases Top-down theory search integrated with bottom-up data exploring.

27 07 September 2004 Parastoo Mohagheghi Assessing development approaches Development approaches should be seen as coherent systems of practices, be chosen depending on the attribute that should be optimized and may trade-off for other practices [IEEE software, MacCormack, 2003 ]

28 07 September 2004 Parastoo Mohagheghi Main Contributions Empirical verification of reuse benefits.Empirical verification of reuse benefits. Increased understanding of the origin and type of changes in each release and between releases.Increased understanding of the origin and type of changes in each release and between releases. Identifying metrics for a combination of reuse and incremental development.Identifying metrics for a combination of reuse and incremental development. A data mining method for exploring industrial databases.A data mining method for exploring industrial databases. An effort estimation method for incremental development.An effort estimation method for incremental development.

29 07 September 2004 Parastoo Mohagheghi Discussion Studies are performed in a real context.Studies are performed in a real context. –Context-independent knowledge is rare in SE and generalization is difficult. Studies combine different methods and data (triangulation).Studies combine different methods and data (triangulation). –Integration of the results is a challenge: physical and conceptual integration challenges. Incremental development is combined with reuse of software in multiple products and CBD.Incremental development is combined with reuse of software in multiple products and CBD. –All aspects of software development need adaptation; e.g. estimation method, software process model, data collection routines etc.

30 07 September 2004 Parastoo Mohagheghi Discussion (continued) Own experience and access to internal dataOwn experience and access to internal data –Confidentiality of some results and other ethical issues should be respected. Some studies are evaluation of others’ observations or methods in a new context (e.g. estimation method, reuse benefits or distribution of maintenance categories), while others contain new observations and methods.Some studies are evaluation of others’ observations or methods in a new context (e.g. estimation method, reuse benefits or distribution of maintenance categories), while others contain new observations and methods. Being exposed to organizational changes leaded to an emerging research design and changes in plans.Being exposed to organizational changes leaded to an emerging research design and changes in plans. Working in the field needs flexibility and a suitably time- frame.Working in the field needs flexibility and a suitably time- frame.

31 07 September 2004 Parastoo Mohagheghi Why such studies are important for industry? Methods should be tested for development in large.Methods should be tested for development in large. Companies are increasingly using mainstream methods, tools and programming languages.Companies are increasingly using mainstream methods, tools and programming languages. The studies analyzed data that was hardly studied before: evaluation of data collection routines and metrics for the company, in addition to concrete results.The studies analyzed data that was hardly studied before: evaluation of data collection routines and metrics for the company, in addition to concrete results.

32 07 September 2004 Parastoo Mohagheghi Acknowledgements Thanks to INCO, Simula and NTNU for financial support.Thanks to INCO, Simula and NTNU for financial support. Thanks to my supervisor, Prof. Reidar Conradi, and colleagues at INCO and IDI.Thanks to my supervisor, Prof. Reidar Conradi, and colleagues at INCO and IDI. Thanks to Ericsson for the permission to perform studies and to publish the results.Thanks to Ericsson for the permission to perform studies and to publish the results. Thanks to the SPIKE seminar and the audience.Thanks to the SPIKE seminar and the audience.