DOCSLIB.ORG

Software Reengineering & Evolution Schedule Goals What Is a Legacy

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Reengineering & Evolution Schedule Goals What Is a Legacy Schedule 1. Introduction Software Reengineering There are OO legacy systems too ! 2. Reverse Engineering & Evolution How to understand your code 3. Visualization Scalable approach 4. Dynamic Analysis To be really certain 5. Restructuring Serge Demeyer How to Refactor Your Code Stéphane Ducasse 6. Code Duplication Oscar Nierstrasz The most typical problems 7. Software Evolution Learn from the past January 2019 8. Going Agile Continuous Integration 9. Conclusion http://scg.unibe.ch/download/oorp/ © S. Demeyer, S. Ducasse, O. Nierstrasz Software Reengineering and Evolution.2 Goals What is a Legacy System ? We will try to convince you: “legacy” A sum of money, or a specified article, given to another by • Yes, Virginia, there are object-oriented legacy systems too! will; anything handed down by an ancestor or predecessor. • Reverse engineering and reengineering are essential — Oxford English Dictionary activities in the lifecycle of any successful software system. A legacy system is a piece of Typical problems with legacy systems: (And especially OO ones!) software that: • original developers not available • you have inherited, and • outdated development methods used • There is a large set of lightweight tools and techniques to • is valuable to you. • extensive patches and modifications have help you with reengineering. been made • missing or outdated documentation • Despite these tools and techniques, people must do job and they represent the most valuable resource. Þ so, further evolution and development may be prohibitively expensive © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.3 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.4 Software Maintenance - Cost Continuous Development Relative Cost Relative Maintenance Effort of Fixing Mistakes data from [Lien78a] Between 50% and 75% of x 200 17.4% Corrective (fixing reported errors) global effort is spent on “maintenance” ! 60.3% Perfective x 20 (new functionality) x 10 18.2% Adaptive Solution ? (new platforms or OS) • Better requirements engineering? x 5 • Better software methods & tools 4.1% Other (database schemas, CASE-tools, objects, x 1 components, …)? The bulk of the maintenance cost is due to new functionality requirement coding delivery Þ even with better requirements, it is hard to predict new functions design testing © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.5 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.6 Modern Methods & Tools ? Lehman's Laws [Glas98a] quoting empirical study from Sasa Dekleva (1992) A classic study by Lehman and Belady [Lehm85a] identified several “laws” of system change. • Modern methods(*) lead to more reliable software • Modern methods lead to less frequent software repair Continuing change • and ... • A program that is used in a real-world environment must change, or • Modern methods lead to more total maintenance time become progressively less useful in that environment. Contradiction ? No! Increasing complexity • modern methods make it easier to change • As a program evolves, it becomes more complex, and extra resources ... this capacity is used to enhance functionality! are needed to preserve and simplify its structure. (*) process-oriented structured methods, information engineering, data-oriented methods, prototyping, CASE-tools – not OO ! Those laws are still applicable… © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.7 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.8 What about Objects ? What about Components ? Object-oriented legacy systems • = successful OO systems whose architecture and design no longer responds to changing requirements Compared to traditional legacy systems • The symptoms and the source of the problems are the same • The technical details and solutions may differ OO techniques promise better • flexibility, • reusability, Þ they do not come for free • maintainability Components are very brittle … After a while one inevitably resorts to glue :) • … © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.9 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.10 Soccer Field Metaphor How to deal with Legacy ? • Assume 10 lines of code New or changing requirements will gradually degrade original design = 40 tiles of 1 x 1 cm … unless extra development effort is spent to adapt the structure • 12.5 million lines of code » 40 soccer fields New Functionality Hack it in ? Imagine 400 developers concurrently • duplicated code First … moving tiles around on 40 soccer fields • complex conditionals • refactor … • abusive inheritance • restructure • large classes/methods • reengineer A. van Deursen, De software-evolutieparadox Take a loan on your software Investment for the future Intreerede TU Delft, 23 feb 2005 Þ pay back via reengineering Þ paid back during maintenance ©© S. A. Demeyer, Van Deursen S. Ducasse, O. Nierstrasz Reengineering Legacy Systems.11 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.12 Common Symptoms The Reengineering Life-Cycle Lack of Knowledge Process symptoms (0) requirement Requirements • obsolete or no documentation • too long to turn things over to analysis • departure of the original production (2) problem developers or users • need for constant bug fixes (3) problem detection • disappearance of inside • maintenance dependencies resolution knowledge about the system • difficulties separating products Designs • limited understanding of entire Þsimple changes take too long system • people centric (1) model • lightweight Þmissing tests capture Code symptoms • duplicated code • code smells Code Þbig build times (4) program transformation © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.13 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.14 A Map of Reengineering Patterns 2. Reverse Engineering • What and Why Tests: Your Life Insurance • First Contact Detailed Model Capture Migration Strategies ☞ Interview during Demo • Initial Understanding Initial Understanding Detecting Duplicated Code Redistribute First Contact Responsibilities Transform Setting Direction Conditionals to Polymorphism © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.15 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.16 What and Why ? The Reengineering Life-Cycle Definition (0) requirement Reverse Engineering is the process of analysing a subject system Requirements analysis ☞ to identify the system’s components and their interrelationships and ☞ create representations of the system in another form or at a higher level of (2) problem (3) problem abstraction. — Chikofsky & Cross, ’90 detection resolution (0) req. analysis Motivation Designs (1) model capture Understanding other people’s code issues (cfr. newcomers in the team, code reviewing, (1) model • scale original developers left, ...) capture • speed • accuracy • politics Code Generating UML diagrams is NOT reverse engineering ... but it is a valuable support tool (4) program transformation © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.17 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.18 First Contact First Project Plan feasibility assessment Use standard templates, including: System experts (one week time) • project scope Talk with Talk with ☞ see "Setting Direction" end users developers • opportunities Chat with the Interview Talk about it ☞ e.g., skilled maintainers, readable source-code, documentation during Demo Maintainers • risks ☞ e.g., absent test-suites, missing libraries, … ☞ record likelihood (unlikely, possible, likely) Software System Verify what & impact (high, moderate, low) for causing problems you hear Read Read it Compile it • go/no-go decision about it • activities Read All the Code Skim the Do a Mock ☞ fish-eye view in One Hour Documentation Installation © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.19 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.20 Interview during Demo Initial Understanding Problem: What are the typical usage Top down scenarios? Recover design Solution: Ask the user! Speculate about Design • Solution: interview during demo - select several users understand Þ ITERATION - demo puts a user in a positive mindset higher-level model Study the - demo steers the interview Analyze the Exceptional • ... however Persistent Data Entities ☞ Which user ? ☞ Users complain Recover Identify database problems ☞ What should you ask ? Bottom up © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.21 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.22 3. Software Visualization The Reengineering Life-cycle • Introduction (0) requirement ☞ The Reengineering life-cycle Requirements analysis • Examples (2) problem (3) problem • Lightweight Approaches detection ☞ CodeCrawler resolution • Dynamic Analysis Designs (2) problem detection ☞ Key Concept Identification issues ☞ Feature Location (1) model • Tool support • Conclusion capture • Scalability • Efficiency Code (4) program transformation © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.23 © S. Demeyer, S. Ducasse, O. Nierstrasz Object-Oriented Reengineering.24 Visualising Hierarchies Bottom Up Visualisation • Euclidean cones ☞ Pros: All program entities and • More info than 2D relations ☞ Cons: • Lack of depth • Navigation • Hyperbolic trees ☞ Pros: • Good focus • Dynamic ☞ Cons:
Load more

Recommended publications
  • D1.1.1 Public State of the Art Document
    D1.1.1 Public state of the art document Programme ITEA3 Challenge Smart Engineering Project number 17038 Project name Visual diagnosis for DevOps software development Project duration 1st October 2018 – 30st June 2022 Project website Project WP WP1 - Pre-studies and requirements Project Task Task 1.1 – Update of state-of-art and state-of-the practice analysis for visualization in software projects in DevOps context Deliverable type X Doc Textual deliverable SW Software deliverable Version V17 Delivered 18/11/2019 Access x Public Abstracts are public Confidential D1.1.1 Public state of the art document Document Contributors Partber Author Role EXPERIS Ester Sancho editor EXPERIS Miriam Moreno writer GRO Paris Avgeriou writer INVENCO Mika Koivuluoma writer OCE Lou Somers writer/reviewer OULU Markus Kelanti writer TAU Kari Systä writer/reviewer TAU Outi Sievi-Korte writer/reviewer TIOBE Paul Jansen writer TIOBE Marvin Wener writer UPC Lidia López writer UPC Xavier Franch writer VINCIT Veli-Pekka Eloranta writer Document History Date Version Editors Status 18/06/2019 ToC EXPERIS Table of Content 10/07/2019 V01 TAU Draft 30/09/2019 V02 OCE/GRO Draft 17/10/2019 V06 TIOBE Draft 22/10/2019 V08 OULU Draft 12/11/2019 V09 VINCIT 1ST Final Draft 20/11/2019 V10 OCE Reviewed version 26/11/2019 V12 UPC/EXPERIS/TAU 2nd Final Draft 10/12/2019 V16 EXPERIS Final Version 16/12/2019 V16.01 TAU Peer Review 18/12/2019 V17 EXPERIS Submission 2 D1.1.1 Public state of the art document Table of Contents Executive Summary ............................................................................................................................. 6 1.
    [Show full text]
  • Linkedin Learning Digital Framework
    Competency Courses Duration Level Course Objective Use ICT-based devices, applications, software and Learn what it takes to break through the clutter and sell in the telecommunications market. In this course, Meridith Elliott Powell helps sales professionals services understand and master the unique challenges and skills required to sell into this ever-changing industry. Meridith acquaints you with the trends and Selling into Industries: Telecommunications 00:33.0 Intermediate changes—including network security and over-the-top (OTT) services—that are currently shaping this industry, as well as what telecommunications clients Use basic productivity software, use email and expect from sales reps. Learn how to use a consultative selling approach to gain a deeper understanding of client needs, create urgency by recognizing and other digital communication solving those needs, and continue to expand your sales relationship after the deal is signed. The Systems Security Certified Practitioner (SSCP) certification is an excellent entry point to a career in IT security. To help you prepare for the SSCP exam, Use digital capture devices such as a camera instructor Mike Chapple has designed a series of courses covering each domain. In this installment, Mike covers the objectives of Networks and SSCP Cert Prep: 6 Networks and Communications Security, Domain 6, which comprises 16% of the questions on the exam. Topics include TCP/IP networking, configuring network security 10:09.0 Intermediate Use subject-specialist ICT devices and Communications Security devices, and identifying the different types of network attacks. Plus, learn how to secure your network with firewall rules, switch and router configuration, and applications confidently network monitoring; protect your telecommunications; and understand the unique features and vulnerabilities of wireless networks.
    [Show full text]
  • Using Already Existing Data to Answer Questions Asked During Software Change
    Using Already Existing Data to Answer Questions Asked During Software Change Daniel Jigin Oscar Gunnesson [email protected] [email protected] June 14, 2018 Master’s thesis work carried out at Praqma, Malmö. Supervisors: Lars Bendix, [email protected] Christian Pendleton, [email protected] Examiner: Boris Magnusson, [email protected] Abstract The software development business is always adapting new technologies while trying to keep up with the market and the importance of having the best-suited tools, people and processes is clear. There is a need to understand what needs there might be, so that the configuration managers can supply developers with the correct support to increase the development efficiency. Studies of how de- velopers spend their time have shown that they spend as much time searching for whom to contact in the organization to get answers to their questions, as they do getting the job done. In traditional software development, configuration managers used to bring a status report about the software to the managers. We have suggested a more modern approach, fit for an agile methodology, where the status of the software is available for any worker at any time. When asking developers how they find answers they say that it is based on gut feeling coming from previous experiences. Providing data will lead to discussions about decisions being data based rather than gut feeling based . We have investigated CodeScene, a tool that utilizes the version control system GIT to analyze which components that have been committed together and analyzing how it can be utilized when performing an impact analysis and how it can provide the technical debt for a software project.
    [Show full text]
  • Enterprise Edition
    Enterprise Edition 1.6.1 February 9, 2017 Contents 1 Getting Started 3 1.1 Configure Your Environment . .3 1.1.1 Install the Supporting Tools . .3 1.1.2 Setup an SSH Key for Git . .3 1.2 Installation . .3 1.2.1 Run CodeScene from the Command Line . .4 1.2.2 Install CodeScene on a Server . .4 1.2.3 Configure additional users . .5 1.3 Run an Analysis . .5 1.3.1 Creating a New Project . .5 1.3.2 Force an Analysis . .8 1.3.3 Run a Retrospective . .8 1.3.4 Find your Way Around . .8 1.4 Ensure you use a Mailmap . 10 1.5 Use a Reverse Proxy for HTTPS Support . 10 1.6 Display A Monitor Dashboard . 10 1.6.1 View the Monitor Dashboard . 10 2 Guides 12 2.1 Technical . 12 2.1.1 Hotspots . 12 2.1.2 Temporal Coupling . 16 2.1.3 Complexity Trends . 21 2.1.4 X-Ray . 26 2.1.5 Code Churn . 33 2.1.6 Code Age . 36 2.2 Architectural . 40 2.2.1 Architectural Analyses . 40 2.3 Social . 45 2.3.1 Social Networks . 45 2.3.2 Knowledge Distribution . 48 2.3.3 Parallel Development and Code Fragmentation . 50 2.3.4 Modus Operandi . 51 2.3.5 Know the possible Biases in the Data . 53 2.4 Project Management . 54 2.4.1 Project Management Analyses . 54 2.4.2 Risk Analysis . 58 3 Configuration 61 3.1 Project Configuration . 61 3.1.1 Specify the Git Repository to Analyze .
    [Show full text]
  • Measuring Architectural Degeneration – in Systems Written in the Interpreted Dynamically Typed Multi- Paradigm Language Python
    Linköping University | Department of Computer and Information Science Master thesis, 30 ECTS | Datateknik 2019 | LIU-IDA/LITH-EX-A--19/059--SE Measuring Architectural Degeneration – In Systems Written in the Interpreted Dynamically Typed Multi- Paradigm Language Python Anton Mo Eriksson & Hampus Dunström Supervisor : Anders Fröberg Examiner : Erik Berglund Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer- ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över- föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till- gängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet än- dras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to down- load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose.
    [Show full text]
  • Insights Into the Technology and Trends Shaping the Future
    TECHNOLOGY RADAR VOL.16 Insights into the technology and trends shaping the future thoughtworks.com/radar #TWTechRadar CONTRIBUTORS The Technology Radar is prepared by the ThoughtWorks Technology Advisory Board, comprised of: Rebecca Parsons (CTO) | Martin Fowler (Chief Scientist) | Badri Janakiraman | Bharani Subramaniam | Camilla Crispim Erik Doernenburg | Evan Bottcher | Fausto de la Torre | Hao Xu | Ian Cartwright James Lewis | Jonny LeRoy | Marco Valtas | Mike Mason | Neal Ford Rachel Laycock | Scott Shaw | Srihari Srinivasan | Zhamak Dehghani WHAT’S NEW? Highlighted themes in this edition: CONVERSATIONAL UI AND platforms. It appears that the “cloud wars” have NATURAL LANGUAGE PROCESSING moved from competing on storage and compute to cognitive capabilities, as witnessed by the willingness watch the video (thght.works/ConUI) to open-source previously differentiating tools such as Kubernetes and Mesos. Conversation—a new way to interact with applications— took the ecosystem by storm with tools such as Siri, All the big players have offerings in this space, along Cortana, and Allo, and then extended into homes with with interesting niche players worth assessing. Although devices such as Amazon Echo and Google Home. we still have reservations about the ethical and privacy implications of these services, we see great promise Building conversational and natural language user in utilizing these powerful tools in novel ways. Our interfaces, while presenting new challenges, has obvious clients are already investigating what new horizons they benefits. The team behind the Echo intentionally may expose by combining commodity cognition with omitted a screen, forcing them to rethink many human- intelligence about their own businesses. machine interactions. DEVELOPER EXPERIENCE AS THE The conversational trend is not just limited to voice; NEW DIFFERENTIATOR as messaging apps have grown to dominate both watch the video (thght.works/DevExp) phones and workplaces, we see conversations with other humans being supplemented by intelligent chatbots.
    [Show full text]
  • Konzeption Und Prototypische Implementierung Eines Web-Basierten Dashboards Zur Softwarevisualisierung
    Universität Leipzig Wirtschaftswissenschaftliche Fakultät Institut für Wirtschaftsinformatik Betreuender Hochschullehrer: Prof. Dr. Ulrich Eisenecker Betreuender Assistent: Dr. Richard Müller Thema Konzeption und prototypische Implementierung eines web-basierten Dashboards zur Softwarevisualisierung Masterarbeit zur Erlangung des akademischen Grades Master of Science – Wirtschaftsinformatik vorgelegt von: Mewes, Tino Leipzig, den 11.10.2018 Abstract Der Schwerpunkt dieser Arbeit liegt auf der Konzeption sowie prototypischen Implemen- tierung eines web-basierten Dashboards zur Softwarevisualisierung. Ziel der Arbeit ist es, ein Dashboard zu entwickeln, welches Informationen eines Softwareprojekts dynamisch aus einer Graphdatenbank visualisiert und Projekteitern aufgabenbezogen zur Entscheidungs- unterstützung darstellt. Derzeit existiert keine Softwarelösung, die diesen Anforderungen vollumfänglich gerecht wird. Es existieren jedoch bereits Bibliotheken und Softwaresyste- me, welche Teilaspekte zu einer möglichen Gesamtlösung beitragen können. Diese können bei der prototypischen Implementierung von Nutzen sein und müssen daher beachtet wer- den. Um die Ziele der Arbeit zu erreichen, werden verschiedene Forschungsmethoden ange- wandt. Es wird eine Literaturrecherche durchgeführt, mit dem Ziel, typische Aufgaben von Projektleitern im Bereich Software Engineering zu identifizieren. Um die vom Dashboard zu unterstützenden Aufgaben ableiten zu können, werden außerdem verschiedene existierende Dashboard-Werkzeuge analysiert. Mithilfe der gewonnenen
    [Show full text]
  • Oskar Wickström August 12, 1990 [email protected] · +46 725 70 49 55 · Wickstrom.Tech Github.Com/Owickstrom · Kommendörsgatan 9B – 21150 Malmö – Sweden
    Oskar Wickström August 12, 1990 [email protected] · +46 725 70 49 55 · wickstrom.tech github.com/owickstrom · Kommendörsgatan 9B – 21150 Malmö – Sweden Prole I am a creative, skilled and motivated software developer with projects. Combined with a strong eye for user interface de- a passion for well designed and simple systems, and functional sign, and experience in cloud deployment and architecture, I programming. With a thorough understanding of system work eciently in large areas of modern technology stacks. design, implementation, automated testing, modern tools, As a fast learner and a socially skilled co-worker, I quickly and the Web, I am comfortable in many settings of software adapt to new challenges, be they technical or not. Qualities Specialities • Broad range of interests and strengths — languages, • Software Architecture and Design tools, and platforms. • Functional Programming • Focused on balancing business needs with elegant design maintainable code, and quality assurance. • Automated Testing • Perceptive, enthusiastic and a very fast learner. • Web Development Experience Symbiont Remote Software Engineer October ’18 – Now Symbiont is the market-leading smart contracts platform for institutional applications of blockchain technology. My role has covered the maintenance and testing of the Assembly platform tooling. Mpowered Remote Tech Lead July ’17 – October ’18 Mpowered provides a suite of SaaS products that simplify B-BBEE compliance for South African companies. In the role of tech lead, I was responsible for the gradual migration and regression testing when moving from Ruby and Rails towards Haskell, including the company’s core calculation engine, and new features in the system. Furthermore, I have worked on a CI and deployment chain using Nix and NixOS, providing a polyglot and fully declarative conguration for the multi-service system.
    [Show full text]
  • Technical Debt Prioritization: State of the Art. a Systematic Literature Review
    Technical Debt Prioritization: State of the Art. A Systematic Literature Review Valentina Lenarduzzia, Terese Beskerb, Davide Taibic, Antonio Martinid, Francesca Arcelli Fontanae aLUT University, Lathi (Finland) bChalmers University of Technology, G¨oteborg (Sweden) cTampere University, Tampere (Finland) dUniversity of Oslo, Oslo (Norway) eUniversity of Milano-Bicocca, Milan (Italy) Abstract Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refac- toring of Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt pri- oritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review of 557 unique pa- pers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies. Results. Different approaches have been proposed for Technical Debt pri- oritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in prac- tice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools. arXiv:1904.12538v2 [cs.SE] 30 Jan 2020 Conclusion. We observed that Technical Debt prioritization research is pre- liminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research Email addresses: [email protected] (Valentina Lenarduzzi), [email protected] (Terese Besker), [email protected] (Davide Taibi), [email protected] (Antonio Martini), [email protected] (Francesca Arcelli Fontana) Preprint submitted to JSS January 31, 2020 conclusive.
    [Show full text]
  • Examination of Tools for Managing Different Dimensions of Technical Debt Dwarak Govind Parthiban1, University of Ottawa
    1 Examination of tools for managing different dimensions of Technical Debt Dwarak Govind Parthiban1, University of Ottawa Abstract With lots of freemium and premium, open and closed source software tools that are available in the market for dealing with different activities of Technical Debt management across different dimensions, identifying the right set of tools for a specific activity and dimension can be time consuming. The new age cloud-first tools can be easier to get onboard, whereas the traditional tools involve a considerable amount of time before letting the users know what it has to offer. Also, since many tools only deal with few dimensions of Technical Debt like Code and Test debts, identifying and choosing the right tool for other dimensions like Design, Architecture, Documentation, and Environment debts can be tiring. We have tried to reduce that tiring process by presenting our findings that could help others who are getting into the field of “Technical Debt in Software Development” and subsequently further into “Technical Debt Management”. I. INTRODUCTION ECHNICAL DEBT (TD) is a term that was coined by Ward Cunningham [1] in the year of 1992. It is a concept in T software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. There are several dimensions of technical debt like code debt, test debt, documentation debt, environment Debt, design Debt, and architecture Debt. As with financial debt, technical debt must be paid back, and is comprised of two parts: principal and interest.
    [Show full text]
  • What Is Selenium Webdriver? Why Is It Used? Selenium Webdriver Is a Web Framework That Permits You to Execute Cross-Browser Tests
    DEPARTMENT OF INFORMATION SCIENCE AND ENGINEERING Study Material for Academic Year 2020-21 (Odd Semester) COURSE NAME : SOFTWARE TESTING AND AUTOMATION COURSE CODE : ISE72 SEMESTER : V111 DepartmentofISE NHCE UNIT-5: Testing Tools: Features of Testing Tools – Guidelines for Selecting Tools – StaticTesting Tools – Dynamic Testing Tools – Advantages and Disadvantages of Testing Tools – When to use Test Tools? Junit, selenium, AutomationScripts practice. Testing Tools: Tools from a software testing context can be defined as a product that supports one or more test activities right from planning, requirements, creating a build, test execution, defect logging and test analysis. Classification of Tools Tools can be classified based on several parameters. They include: The purpose of the tool The Activities that are supported within the tool The Type/level of testing it supports The Kind of licensing (open source, freeware, commercial) The technology used Types ofTools: S.No. Tool Type Used for Used by 1. Test Management Tool Test Managing, scheduling, defect testers logging, tracking and analysis. 2. Configuration For Implementation, execution, All Team management tool tracking changes members 3. Static Analysis Tools Static Testing Developers 4. Test data Preparation Analysis and Design, Test data Testers Tools generation 5. Test Execution Tools Implementation, Execution Testers 6. Test Comparators Comparing expected and actual results All Team members 7. Coverage measurement Provides structural coverage Developers tools 8. Performance Testing Monitoring the performance, response Testers tools time 9. Project planning and For Planning Project Tracking Tools Managers 10. Incident Management For managing the tests Testers Tools Tools Implementation - process Analyse the problem carefully to identify strengths, weaknesses and opportunities The Constraints such as budgets, time and other requirements are noted.
    [Show full text]
  • Technical Debt Tools: a Systematic Mapping Study
    Technical Debt Tools: A Systematic Mapping Study Diego Saraiva a, Jose´ Gameleira Neto b, Uira´ Kulesza c, Guilherme Freitas d, Rodrigo Reboucas e and Roberta Coelho f Department of Informatics and Applied Mathematics, Federal University of Rio Grande do Norte, Natal, Brazil Keywords: Systematic Mapping Study, Technical Debt, Technical Debt Management, Tools. Abstract: Context: The concept of technical debt is a metaphor that contextualizes problems faced during software evo- lution that reflect technical compromises in tasks that are not carried out adequately during their development - they can yield short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Objective: This work investigates the current state of the art of technical debt tools by identifying which activities, functionalities and kind of technical debt are handled by existing tools that support the technical debt management in software projects. Method: A systematic mapping study is performed to identify and analyze available tools for managing technical debt based on a set of five research questions. Results: The work contributes with (i) a systematic mappping of current research on the field, (ii) a highlight of the most referenced tools, their main characteristics, their supported technical debt types and activities, and (iii) a discussion of emerging findings and implications for future research. Conclusions: Our study identified 50 TD tools where 42 of them are new tools, and 8 tools extend an existing one. Most of the tools address technical debt related to code, design, and/or architecture artifacts. Besides, the different TD management activities received different levels of attention.
    [Show full text]