DOCSLIB.ORG

Software Evolution of Legacy Systems a Case Study of Soft-Migration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Evolution of Legacy Systems a Case Study of Soft-Migration Software Evolution of Legacy Systems A Case Study of Soft-migration Andreas Furnweger,¨ Martin Auer and Stefan Biffl Vienna University of Technology, Inst. of Software Technology and Interactive Systems, Vienna, Austria Keywords: Software Evolution, Migration, Legacy Systems. Abstract: Software ages. It does so in relation to surrounding software components: as those are updated and modern- ized, static software becomes evermore outdated relative to them. Such legacy systems are either tried to be kept alive, or they are updated themselves, e.g., by re-factoring or porting—they evolve. Both approaches carry risks as well as maintenance cost profiles. In this paper, we give an overview of software evolution types and drivers; we outline costs and benefits of various evolution approaches; and we present tools and frameworks to facilitate so-called “soft” migration approaches. Finally, we describe a case study of an actual platform migration, along with pitfalls and lessons learned. This paper thus aims to give software practitioners—both resource-allocating managers and choice-weighing engineers—a general framework with which to tackle soft- ware evolution and a specific evolution case study in a frequently-encountered Java-based setup. 1 INTRODUCTION tainability. We look into different aspects of software maintenance and show that the classic meaning of Software development is still a fast-changing environ- maintenance as some final development phase after ment, driven by new and evolving hardware, oper- software delivery is outdated—instead, it is best seen ating systems, frameworks, programming languages, as an ongoing effort. We also discuss program porta- and user interfaces. While this seemingly constant bility with a specific focus on porting source code. drive for modernization offers many benefits, it also We then outline costs and benefits of various requires dealing with legacy software that—while evolution approaches. These approaches are either working—slowly falls out of step with the surround- legacy-based, essentially trying to preserve as much ing components that are being updated—for example, as possible of the existing system, or migration-based, if a certain version of an operating system is no longer where the software is transferred, to various degrees, supported by its vendor. There are various ways to into a new setup. handle such “aging” software: one can try to keep After that, we focus on various methods for “soft” it up and running; to carefully refactor it to various migration approaches—those approaches aim to fa- degrees to make it blend in better; to port its code; cilitate traditional migration methods like porting or to rewrite it from scratch. The main stakeholders in rewriting code via support tools and frameworks. deciding on a course of action are managers, which We especially concentrate on the Java programming must allocate resources to and consider the risks and language and present a specific variant of a soft- maintenance cost profiles of the various options (e.g., migration approach, which is using a Java-based pro- will affordable developers with specific skills still be gram core with several platform-specific branches. available?), as well as software developers, which Finally, we describe a case study of an actual soft should be aware of the long-term implications of their migration of the UML editor UMLet, which is cur- choices (e.g., will a certain programming language be rently available as a Swing-based Java program and around in five years’ time?). an SWT-based Eclipse plugin, and which is ported to a web platform. We analyze some problems we en- To provide some software evolution guidelines, countered, and discuss the benefits and drawbacks of our paper first gives an overview on software evolu- the suggested approach. tion types, covering maintenance, reengineering, and whether to preserve or redesign legacy systems. We address software aging and its connection with main- 413 Fürnweger, A., Auer, M. and Biffl, S. Software Evolution of Legacy Systems - A Case Study of Soft-migration. In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 413-424 ISBN: 978-989-758-187-8 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved ICEIS 2016 - 18th International Conference on Enterprise Information Systems 2 RELATED WORK to (Feathers, 2004), this phase should be accompa- nied by extensive testing to make sure the application (Mens and Demeyer, 2008) give an overview of trends behavior stays the same. (Fowler and Beck, 1999) in software evolution research and address the evo- list useful refactoring patterns, while (Feathers, 2004) lution of other software artifacts like databases, soft- stresses how legacy code can be made testable. ware design, and architectures. A general overview of the related topics of maintenance and legacy software is given by (Bennett and Rajlich, 2000), who also 3 SOFTWARE EVOLUTION identify key problems and potential solution strate- gies. This section outlines relevant disciplines and nomen- Lehman classifies programs in terms of software clature related to software evolution. evolution and also formulates laws of software evo- lution (Lehman, 1980; Lehman et al., 1997), which 3.1 Overview are, however, not considered universally valid (Her- raiz et al., 2013). There are also many exploratory (Lehman et al., 2000) divide the view on software studies that try to analyze and understand software evolution into two disciplines. The scientific dis- evolution based on specific software projects (Jo- cipline investigates the nature of software evolution hari and Kaur, 2011; Businge et al., 2010; Zhang and its properties, while the engineering discipline et al., 2013; Ratzinger et al., 2007; Kim et al., 2011). focuses on the practical aspects like “theories, ab- (Chaikalis and Chatzigeorgiou, 2015) develop a pre- stractions, languages, activities, methods and tools diction model for software evolution and evaluate it required to effectively and reliably evolve a software against several open-source projects. (Benomar et al., system.” (Lehman, 1980) classifies programs based 2015) present a technology to identify software evo- on their relationship to the environment where they lution phases based on commits and releases. are executed. Lehman also formulates the eight laws The related topic of legacy systems is a bit am- of software evolution. Among those laws, two as- biguous, due to differing definitions. It can describe pects are emphasized: continuing change (i.e., with- a system that resists modification (Brodie and Stone- out adaption, software can become progressively less braker, 1995), a system without tests (Feathers, 2004), effective), and increasing complexity (i.e., as software or even all software as soon as it has been written evolves, its complexity tends to increase unless effort (Hunt and Thomas, 1999). A natural question regard- is spent to avoid that). According to (Herraiz et al., ing legacy systems is whether to preserve or redesign 2013), these laws have been proven in many cases, them. As this question is not easy to answer (Schnei- but they are not universally valid. dewind and Ebert, 1998), the pros and cons of reengi- neering or preserving a system are to be compared 3.2 Legacy Systems thoroughly before making a decision (Sneed, 1995). In addition, it is possible to replace a system in stages There are different definitions of what a legacy system to minimize the operational disruption of the system or legacy code is. (Brodie and Stonebraker, 1995) de- (Schneidewind and Ebert, 1998). scribe it as “a system which significantly resists mod- Even though the classic view of maintenance as ification and evolution.” (Feathers, 2004) defines it as the final life-cycle phase of software after delivery is code without tests, while (Hunt and Thomas, 1999) still prevalent, it is a much broader topic, especially state that “All software becomes legacy as soon as it’s for programs which must constantly adapt to a chang- written.” ing environment. There are reports that the total main- tenance costs are at least 40% of the initial develop- Preserve or Redesign Legacy Systems ment costs (Brooks Jr., 1995), 70% of the software budget (Harrison and Cook, 1990), and up to 90% of According to (Schneidewind and Ebert, 1998), the the total costs of the system (Rashid et al., 2009). As question whether to preserve or redesign a legacy sys- these numbers show, the topic of maintenance is cru- tem is not easy to answer. In general, most organiza- cial. (Lientz and Swanson, 1980) categorize mainte- tions do not rush to replace legacy systems, because nance activities into distinct classes. Several authors the successful operation of these systems is vital. But (Sjøberg et al., 2012; Riaz et al., 2009) propose main- they must eventually take some action to update or re- tainability metrics. place their systems, otherwise they will not be able to Finally, when migrating a system, a reengineer- take advantage of new hardware, operating systems, ing phase is almost always necessary. According or applications. 414 Software Evolution of Legacy Systems - A Case Study of Soft-migration An important aspect of this decision is that one spent on maintenance; 75% of software professionals does not have to choose an extreme solution like pre- are involved with maintenance. According to (Cole- serving a system unaltered, or redesigning it from man et al., 1994), HP has between 40 and 50 million
Load more

Recommended publications
  • Software Rejuvenation Model for Cloud Computing Platform
    International Journal of Applied Engineering Research ISSN 0973-4562 Volume 12, Number 19 (2017) pp. 8332-8337 © Research India Publications. http://www.ripublication.com Software Rejuvenation Model for Cloud Computing Platform I M Umesh System Analyst, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0002-7595-5501 Dr. G N Srinivasan Professor, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0003-1059-5952 Matheus Torquato Professor, Federal Institute of Alagoas (IFAL), Campus Arapiraca - AL, Brazil. Orcid Id: 0000-0003-3211-7951 Abstract leading to resource exhaustion. Aging effects are the result of Cloud computing has emerged as one of the most needed error accumulation that leads to resource exhaustion. This technologies that houses software systems and relevant status of softwares makes the system gradually shift from functional entities resulting in complex, multiuser, healthy state to failure prone state. The system performance multitasking and virtualized environments. However, metrics needs to be monitored in order to find the aging reliability of such high performance computing systems patterns while the system is running. The accurate prediction depends both on hardware and software. Virtualization is the of time of aging needs to be forecasted to initiate the technology that many cloud service providers rely on for necessary actions to counter the aging effects. The software efficient management and coordination of the resource pool. aging consequences can be avoided by using the technique The software systems, during operation accumulate errors or called software rejuvenation. garbage leading to software aging which may lead to system Software rejuvenation is the proactive technique proposed to failure and associated consequences.
    [Show full text]
  • The Past, Present, and Future of Software Evolution
    The Past, Present, and Future of Software Evolution Michael W. Godfrey Daniel M. German Software Architecture Group (SWAG) Software Engineering Group School of Computer Science Department of Computer Science University of Waterloo, CANADA University of Victoria, CANADA email: [email protected] email: [email protected] Abstract How does our system compare to that of our competitors? How easy would it be to port to MacOS? Are users still Change is an essential characteristic of software devel- angry about the spyware incident? As new features are de- opment, as software systems must respond to evolving re- vised and deployed, as new runtime platforms are envis- quirements, platforms, and other environmental pressures. aged, as new constraints on quality attributes are requested, In this paper, we discuss the concept of software evolu- so must software systems continually be adapted to their tion from several perspectives. We examine how it relates changing environment. to and differs from software maintenance. We discuss in- This paper explores the notion of software evolution. We sights about software evolution arising from Lehman’s laws start by comparing software evolution to the related idea of software evolution and the staged lifecycle model of Ben- of software maintenance and briefly explore the history of nett and Rajlich. We compare software evolution to other both terms. We discuss two well known research results of kinds of evolution, from science and social sciences, and we software evolution: Lehman’s laws of software evolution examine the forces that shape change. Finally, we discuss and the staged lifecycle model of Bennett and Rajlich. We the changing nature of software in general as it relates to also relate software evolution to biological evolution, and evolution, and we propose open challenges and future di- discuss their commonalities and differences.
    [Show full text]
  • SWARE: a Methodology for Software Aging and Rejuvenation Experiments
    Journal of Information Systems Engineering & Management, 2018, 3(2), 15 ISSN: 2468-4376 SWARE: A Methodology for Software Aging and Rejuvenation Experiments Matheus Torquato 1*, Jean Araujo 2, I. M. Umesh 3, Paulo Maciel 4 1 Federal Institute of Alagoas (IFAL), Campus Arapiraca, Arapiraca, AL, BRAZIL 2 Federal Rural University of Pernambuco (UFRPE), Campus Garanhuns, Garanhuns, PE, BRAZIL 3 Bharathiar University, Coimbatore, INDIA 4 Federal University of Pernambuco (UFPE), Center of Informatics (CIn), Recife, PE, BRAZIL *Corresponding Author: [email protected], [email protected] Citation: Torquato, M., Araujo, J., Umesh, I. M. and Maciel, P. (2018). SWARE: A Methodology for Software Aging and Rejuvenation Experiments. Journal of Information Systems Engineering & Management, 3(2), 15. https://doi.org/10.20897/jisem.201815 Published: April 07, 2018 ABSTRACT Reliability and availability are mandatory requirements for numerous applications. Technical apparatus to study system dependability is essential to support software deployment and maintenance. Software aging is a related issue in this context. Software aging is a cumulative process which leads systems with long-running execution to hangs or failures. Software rejuvenation is used to prevent software aging problems. Software rejuvenation actions comprise system reboot or application restart to bringing software to a stable fresh state. This paper proposes a methodology to conduct software aging and software rejuvenation experiments. The approach has three phases: (i) Stress Phase - stress environment with the accelerated workload to induce bugs activation; (ii) Wait Phase - stop workload submission to observe the system state after workload submission; (iii) Rejuvenation Phase - find the impacts caused by the software rejuvenation.
    [Show full text]
  • Software Evolution Objectives
    Software evolution Objectives To explain why change is inevitable if software systems are to remain useful To discuss software maintenance and maintenance cost factors To describe the processes involved in software evolution To discuss an approach to assessing evolution strategies for legacy systems Topics covered Program evolution dynamics Software maintenance Evolution processes Legacy system evolution Software change Software change is inevitable New requirements emerge when the software is used The business environment changes Errors must be repaired New computers and equipment is added to the system The performance or reliability of the system may have to be improved A key problem for organisations is implementing and managing change to their existing software systems Importance of evolution Organisations have huge investments in their software systems - they are critical business assets To maintain the value of these assets to the business, they must be changed and updated The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software Spiral model of evolution Program evolution dynamics Program evolution dynamics is the study of the processes of system change After major empirical studies, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases Lehman’s laws Law Description Continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. Increasing complexity As an evolving program changes, its structure tends to become more complex.
    [Show full text]
  • Software Design Introduction
    Software Design Introduction Material drawn from [Godfrey96,Parnas86,Parnas94] Software Design (Introduction) © SERG Software Design • How to implement the what. • Requirements Document (RD) is starting point. • Software design is a highly-creative activity. • Good designers are worth their weight in gold! – Highly sought after, head-hunted, well-paid. • Experience alone is not enough: – creativity, “vision”, all-around brilliance required. Software Design (Introduction) © SERG Software Design (Cont’d) • Some consider software design to be a “black art”: – difficult to prescribe how to do it – hard to measure a good design objectively – “I know a good design when I see it.” Software Design (Introduction) © SERG Requirements Engineering: An Overview • Basic goal: To understand the problem as perceived by the user. • Activities of RE are problem oriented. – Focus on what, not how – Don’t cloud the RD with unnecessary detail – Don’t pre-constrain design. • After RE is done, do software design: – solution oriented – how to implement the what Software Design (Introduction) © SERG Requirements Engineering: An Overview • Key to RE is good communication between customer and developers. • Work from Requirements Document as guide. Software Design (Introduction) © SERG Requirements Engineering • Basically, it’s the process of determining and establishing the precise expectations of the customer about the proposed software system. Software Design (Introduction) © SERG The Two Kinds of Requirements • Functional: The precise tasks or functions the system is to perform. – e.g., details of a flight reservation system • Non-functional: Usually, a constraint of some kind on the system or its construction – e.g., expected performance and memory requirements, process model used, implementation language and platform, compatibility with other tools, deadlines, ..
    [Show full text]
  • A Technique for Legacy System Re-Engineering
    International Journal of Management and Applied Science, ISSN: 2394-7926 Volume-2, Issue-12, Special Issue-1, Dec.-2016 INFORMATION SYSTEM INTEGRATION: A TECHNIQUE FOR LEGACY SYSTEM RE-ENGINEERING EMOKPAE OSATOHANMWEN Dept of Computer Engineering, Institute of Opencast Mining and Technology. Agbor Road Benin City, Nigeria. E-mail:[email protected] Abstract - Many organizations are still faced with the problems of converting applications written in legacy compilers such as COBOL, PASCAL ANS FORTRAN etc. into internet compliant applications. This has become necessary because most internet-based applications are written in C++, Java and Ms.Net. The objective of this paper is to show how information system integration can aid in the forward engineering of legacy system. Software re-engineering covers the examination and alteration of legacy system in order to rebuild it according to modem software engineering methods and technologies in a forward engineering process. Information system integration provides a means for both understanding and capturing about the application and its domain and re-developing the system based on change requirement. Information system integration helps to rebuild any legacy by adopting modern software engineering principles, methods and technologies, which allows systems to architecture engineers over the years have devises many modernization techniques. This paper evaluates the use of information system integration as a veritable technique for transformation of legacy system. Keywords - COBOL, PASCAL, FORTRANS, C++,Java Ms.Net etc I. INTRODUCTION streamlining business processes to the software used. There are five levels of integrating information Many organizations are still faced with the problem system, which include data, data management, of converting applications written in Legacy middleware, application and user interface (Bizer, compilers such as COBOL, Pascal and FORTRAN 2003).
    [Show full text]
  • During the Early Days of Computing, Computer Systems Were Designed to Fit a Particular Platform and Were Designed to Address T
    TAGDUR: A Tool for Producing UML Diagrams Through Reengineering of Legacy Systems Richard Millham, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: Introducing TAGDUR, a reengineering tool that first transforms a procedural legacy system into an object-oriented, event-driven system and then models and documents this transformed system through a series of UML diagrams. Keywords: TAGDUR, Reengineering, Program Transformation, UML In this paper, we introduce TAGDUR (Transformation from a sequential-driven, procedural structured to an and Automatic Generation of Documentation in UML event-driven, component-based architecture requires a through Reengineering). TAGDUR is a reengineering tool transformation of the original system to an object-oriented, designed to address the problems frequently found in event-driven system. Object orientation, because it many legacy systems such as lack of documentation and encapsulates methods and their variables into modules, is the need to transform the present structure to a more well-suited to a multi-tiered Web-based architecture modern architecture. TAGDUR first transforms a where pieces of software must be defined in encapsulated procedurally-structured system to an object-oriented, modules with cleanly-defined interfaces. This particular event-driven architecture. Then TAGDUR generates legacy system is procedural-driven and is batch-oriented; documentation of the structure and behavior of this a move to a Web-based architecture requires a real-time, transformed system through a series of UML (Unified event-driven response rather than a procedural invocation. Modeling Language) diagrams. These diagrams include class, deployment, sequence, and activity diagrams. Object orientation promises other advantages as well.
    [Show full text]
  • On the Aging Effects Due to Concurrency Bugs: a Case Study on Mysql
    On the Aging Effects due to Concurrency Bugs: a Case Study on MySQL Antonio Bovenzi∗, Domenico Cotroneo∗, Roberto Pietrantuono∗, Stefano Russo∗y, ∗Dipartimento di Informatica e Sistemistica, Universita´ di Napoli Federico II, Via Claudio 21, 80125, Naples, Italy. yLaboratorio CINI-ITEM “Carlo Savy”, Complesso Universitario Monte Sant’Angelo, Via Cinthia, 80126, Naples, Italy. fantonio.bovenzi, cotroneo, roberto.pietrantuono, [email protected] Abstract—This study investigates software aging effects and fragmentation problems (e.g., file system and physical caused by the activation of concurrency bugs in a well- memory). known database management system (DBMS), namely MySQL. ARBs are difficult to reproduce in a systematic way Experiments with different workloads are performed in order to reproduce the most likely conditions for concurrency bugs during the testing phase, because they require a long time activation. Besides the typical aging effects observed in many to manifest their effects. For these characteristics, they are operational systems (i.e., a gradual degradation over time), considered as a subclass of Mandelbugs [4]. Mandelbugs are results highlight that both available resources and DBMS those software faults that are difficult to isolate, and whose performance (e.g. service rate, service time, and connection activation and/or error propagation are considered “com- latency) can decrease with time in a hard-to-predict way. We observed that, due to the activation of concurrency bug, the plex” because: i) they depend on indirect factors (e.g., timing DBMS enters a degraded state in which: i) the estimation of and/or sequencing of operations or inputs, interactions with Time-To-Failure (TTF) by means of memory depletion trend system-internal environment), and/or ii) there is a time lag analysis is highly inaccurate, and ii) the failure rate does not between the fault activation and the failure manifestation.
    [Show full text]
  • TAGDUR: a Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems
    TAGDUR: A Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems Richard Millham, Jianjun Pu, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: A further introduction of TAGDUR, a documents this transformed system through a reengineering tool that first transforms a series of UML diagrams. This paper focuses on procedural legacy system into an object-oriented, TAGDUR’s generation of sequence, deployment, event-driven system and then models and and component diagrams. Keywords: UML (Unified Modeling Language), Reengineering, WSL This paper is a second installment in a series [4] accommodate a multi-tiered, Web-based that introduces TAGDUR (Transformation and platform. In order to accommodate this Automatic Generation of Documentation in remodeled platform, the original sequential- UML through Reengineering). TAGDUR is a driven, procedurally structured legacy system reengineering tool that transforms a legacy must be transformed to an object-oriented, event- system’s outmoded architecture to a more driven system. Object orientation, because it modern one and then represents this transformed encapsulates variables and procedures into system through a series of UML (Unified modules, is well suited to this new Web Modeling Language) diagrams in order to architecture where pieces of software must be overcome a legacy system’s frequent lack of encapsulated into component modules with documentation. The architectural transformation clearly defined interfaces. A transfer to a Web- is from the legacy system’s original based architecture requires a real-time, event- procedurally-structured to an object-oriented, driven response rather than the legacy system’s event-driven architecture.
    [Show full text]
  • The 2020 Guide to Legacy System Innovation
    The 2020 Guide to Legacy System Innovation Legacy Systems The Keys A New Freedom for 2 APIs 4 6 8 Meet the to Freedom Approach to the Future 21st Century Modernization. The 2020 Guide to Legacy System Innovation Legacy Systems Meet the 21st Century egacy systems running on mainframe computers are at the heart of our economy – and our society. L They are an essential part of our tax systems, our social services, and our public safety. They also run the stock market, our financial institutions, ATMs, transportation systems and utility grids. In fact, we use them all the time and likely don’t even know it. For state and local governments, these legacy systems are a mixed blessing. On the one hand, they have provided extraordinary reliability. They’ve proved themselves with successful track records of 20, 30, or APIs even 40 years. On the other hand, they are rigid, and some would even say fragile, closed and expensive to maintain. Making changes to a legacy system is costly, risky, and prone to failure. Also, legacy systems are by nature siloed systems that keep their data locked inside where it’s safe, but inaccessible. As one senior public sector IT executive put it, “I feel like my data is in jail.” For decades, agencies have been looking for freedom include day-to-day operations, staffing, responding to from legacy systems—a way off of their existing systems. pressure for innovation from elected officials, application Software AG offers a better, stronger alternative: the users and citizens themselves, and complying with Freedom for Legacy solution.
    [Show full text]
  • Using XML to Build Consistency Rules for Distributed Specifications
    Using XML to Build Consistency Rules for Distributed Specifications Andrea Zisman Wolfgang Emmerich Anthony Finkelstein City University University College London Department of Computing Department of Computer Science Northampton Square Gower Street London EC1V 0HB London WC1E 6BT +44 (0)20 74778346 +44 (0)20 76794413 [email protected] {w.emmerich | a.finkelstein}@cs.ucl.ac.uk Inevitably, the heterogeneity of the specifications and the ABSTRACT diversity of stakeholders and development participants results in inconsistencies among the distributed partial The work presented in this paper is part of a large specifications [18]. However as development proceeds programme of research aimed at supporting consistency there is a requirement for consistency. management of distributed documents on the World Wide Web. We describe an approach for specifying consistency Consistency management is a multifaceted and complex rules for distributed partial specifications with overlapping activity that is fundamental to the success of software contents. The approach is based on expressing consistency development. Different approaches have been proposed to rules using XML and XPointer. We present a classification manage consistency [11][17][21][25][28]. This research for different types of consistency rules, related to various has identified a strong need for mechanisms, techniques types of inconsistencies and show how to express these and tools that aid in detecting, identifying and handling consistency rules using our approach. We also briefly inconsistencies among distributed partial specifications. describe a rule editor to support the specification of the consistency rules. We are interested in identifying inconsistencies among partial specifications where the documents in which these Keywords: Inconsistency, consistency rules, XML, specification fragments are represented exhibit Internet- XPointer.
    [Show full text]
  • User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Trepo - Institutional Repository of Tampere University User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions Sayed Tenkanen University of Tampere School of Information Sciences Interactive Technology M.Sc. thesis Supervisor: Professor Roope Raisamo December 2014 ii University of Tampere School of Information Sciences Interactive Technology Sayed Tenkanen: User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions M.Sc. thesis, 48 pages December 2014 Software aging is empirically observed in software systems in a variety of manifestations ranging from slower performance to various failures as reported by users. Unlike hardware aging, where in its lifetime hardware goes through wear and tear resulting in an increased rate of failure after certain stable use conditions, software aging is a result of software bugs. Such bugs are always present in the software but may not make themselves known unless a set of preconditions are met. When activated, software bugs may result in slower performance and contribute to user dissatisfaction. However, the impact of software bugs on PCs and mobile phones is different as their uses are different. A PC is often turned off or rebooted on an average of every seven days, but a mobile device may continue to be used without a reboot for much longer. The prolonged operation period of mobile devices thus opens up opportunities for software bugs to be activated more often compared to PCs. Therefore, software aging in mobile devices, a considerable challenge to the ultimate user experience, is the focus of this thesis.
    [Show full text]