DOCSLIB.ORG

Konzeption Und Prototypische Implementierung Eines Web-Basierten Dashboards Zur Softwarevisualisierung

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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 Ergebnisse wird das Dashboard konzipiert und prototypisch implementiert. Durch eine Fallstudie anhand von Open-Source- Projekten wird das Dashboard abschließend evaluiert. Schlagwörter: Dashboard, Softwarevisualisierung, jQAssistant, Neo4j, React, D3.js Inhaltsverzeichnis III Inhaltsverzeichnis Abbildungsverzeichnis VI Tabellenverzeichnis VIII Verzeichnis der Listings IX Abkürzungsverzeichnis X 1 Einleitung 1 1.1 Motivation und Problemstellung . .1 1.2 Zielstellung . .2 1.3 Methodisches Vorgehen . .2 2 Grundlagen 4 2.1 Softwarevisualisierung . .4 2.2 jQAssistant . .5 2.3 Neo4j . .5 2.4 Webanwendungen und web-basierte Frameworks . .5 2.5 D3.js . .6 2.6 Dashboards . .7 3 Konzeption 9 3.1 Mission Statement . .9 3.2 Architekturziele . .9 3.3 Kontextabgrenzung . 10 3.3.1 Fachlicher Kontext . 10 3.3.1.1 Literaturrecherche zu typischen Aufgaben von Projektlei- tern . 10 3.3.1.2 Analyse existierender Dashboard-Werkzeuge . 14 3.3.1.3 Use-Case-Diagramm der zu unterstützenden Aufgaben . 19 3.3.1.4 Mockups der Benutzungsschnittstelle . 19 3.3.2 Technischer Kontext . 22 Inhaltsverzeichnis IV 3.4 Randbedingungen . 23 3.4.1 Technische Randbedingungen . 23 3.4.2 Organisatorische Randbedingungen . 24 3.5 Risiken und technische Schulden . 24 3.6 Entwurfsentscheidungen . 24 3.6.1 Auswahl des Neo4j-Treibers . 24 3.6.2 Vergleich existierender Webframeworks . 25 3.6.2.1 Angular . 25 3.6.2.2 Backbone.js . 27 3.6.2.3 Ember.js . 27 3.6.2.4 Vue.js . 27 3.6.2.5 React . 28 3.7 Lösungsstrategie . 29 4 Implementierung 30 4.1 Implementierungskomponenten . 30 4.1.1 CoreUI . 30 4.1.2 Nivo . 31 4.2 Dashboard . 32 4.2.1 Startseite . 32 4.2.2 Einstellungen . 35 4.2.3 Benutzerdefinierte Abfragen . 36 4.2.4 Visualisierungskomponenten . 37 4.2.4.1 Struktur . 38 4.2.4.2 Dateitypen . 39 4.2.4.3 Abhängigkeiten . 40 4.2.4.4 Aktivitäten . 41 4.2.4.5 Wissensverteilung . 44 4.2.4.6 Hotspots . 45 4.2.4.7 Statische Quellcodeanalyse . 47 4.2.4.8 Testabdeckung . 48 4.2.4.9 Erstellung . 49 4.3 Eingesetzte Werkzeuge . 51 4.3.1 Entwicklung und Test . 51 4.3.1.1 Jest . 51 4.3.1.2 Codecov . 52 Inhaltsverzeichnis V 4.3.1.3 Travis CI . 53 4.3.1.4 Prettier . 54 4.3.1.5 Docker . 54 4.3.2 Installation und Wartung . 55 5 Evaluation 57 6 Fazit und Ausblick 60 Anhang XI A jQAssistant-Konzeptregeln . .XI B Dateistruktur . XIII Glossar XVIII Literaturverzeichnis XXIII Selbstständigkeitserklärung XXV Abbildungsverzeichnis VI Abbildungsverzeichnis 1.1 Software-Engineering-Prozesse mit Stakeholdern und Artefakten . .1 2.1 Darstellung von Verkaufsmaßnahmen zur Analyse der Produktleistung nach Kategorie in Form eines Dashboards . .7 3.1 Standpunkt des technischen Leiters innerhalb eines Entwicklerteams . 11 3.2 Use-Case-Diagramm der zu unterstützenden Aufgaben des Dashboards . 19 3.3 Mockup der Startseite des Dashboards . 20 3.4 Mockup für die Darstellung der Hotspots innerhalb des Dashboards . 20 3.5 Mockup für die Darstellung der Autoren des Softwareprojekts innerhalb des Dashboards . 21 3.6 Mockup für die Darstellung der Einstellungsmöglichkeiten des Dashboards 22 3.7 Komponentendiagramm des Dashboards . 23 3.8 Die fünf populärsten web-basierten Frameworks zum Stand der Erstellung der Arbeit . 26 3.9 Die Flux-Architektur . 28 4.1 Startseite des Dashboards . 35 4.2 Einstellungsmöglichkeiten des Dashboards . 36 4.3 Benutzerdefinierte Abfragen des Dashboards . 37 4.4 Struktur-Visualisierungskomponente des Dashboards . 38 4.5 Dateitypen-Visualisierungskomponente des Dashboards . 39 4.6 Abhängigkeiten-Visualisierungskomponente des Dashboards . 40 4.7 Visualisierungskomponenten Commits pro Autor sowie Dateien pro Autor 42 4.8 Visualisierungskomponenten Commitkalender sowie letzte 20 Commits . 43 4.9 Kalenderkomponente zur Filterung der Aktivitäten . 44 4.10 Visualisierungskomponente zur Darstellung der Wissensverteilung . 45 4.11 Hotspots-Visualisierungskomponente des Dashboards . 46 4.12 Visualisierungskomponente für die Darstellung der statischen Quellcodeana- lyse ..................................... 47 4.13 Darstellung der Details der einzelnen Verstöße im Quellcode . 48 4.14 Visualisierungskomponente zur Darstellung der Testabdeckung . 49 4.15 Graphische Darstellung der Testabdeckung des Dashboard-Quellcodes . 53 4.16 Kennzeichnung von Commits mittels Travis CI .............. 54 Abbildungsverzeichnis VII 5.1 Startseite des Dashboards mit den eingelesenen Daten von Spring Petclinic 58 5.2 Startseite des Dashboards mit den eingelesenen Daten von jUnit ..... 59 B.1 Dateistruktur des Dashboards . XVII Tabellenverzeichnis VIII Tabellenverzeichnis 3.1 Typische Aufgaben von technischen Leitern . 12 3.2 Aufgaben der Stakeholder zur Verwendung als Checkliste für Tools . 13 3.3 Analyse des Dashboard-Werkzeugs Teamscale ............... 15 3.4 Analyse des Dashboard-Werkzeugs CodeScene .............. 15 3.5 Analyse des Dashboard-Werkzeugs SonarQube .............. 16 3.6 Analyse des Dashboard-Werkzeugs Structurizr .............. 17 3.7 Analyse des Dashboard-Werkzeugs NDepend ............... 17 3.8 Analyse des Dashboard-Werkzeugs Structure101 ............. 18 3.9 Zusammenfassung der Analyse existierender Dashboard-Werkzeuge . 18 3.10 Gegenüberstellung von Qualitätszielen und passenden Architekturansätzen 29 6.1 Gegenüberstellung der Qualitätsziele und deren jeweiliger Umsetzung . 60 Verzeichnis der Listings IX Verzeichnis der Listings 4.1 Cypher-Abfrage für die Ausgabe der Strukturmetrik . 32 4.2 Cypher-Abfrage für die Ausgabe der Abhängigkeitsmetrik . 33 4.3 Cypher-Abfrage für die Ausgabe der Aktivitätsmetrik . 33 4.4 Cypher-Abfrage für die Ausgabe der Hotspotmetrik . 34 4.5 Cypher-Abfrage für die Ausgabe der statischen Quellcodeanalyse . 34 4.6 Cypher-Abfrage für die Ausgabe der Testabdeckung . 34 4.7 Cypher-Abfrage für die Ausgabe der Struktur mittels geschachtelter Kreise 38 4.8 Cypher-Abfrage für die Analyse der Dateitypen . 39 4.9 Cypher-Abfrage für die Abhängigkeitsanalyse . 40 4.10 Cypher-Abfrage für die Ausgabe der Commits pro Autor . 41 4.11 Cypher-Abfrage für die Ausgabe der geänderten Dateien pro Autor . 41 4.12 Cypher-Abfrage für die Ausgabe der Commits sowie zugehörigen Erstel- lungsdaten . 42 4.13 Cypher-Abfrage für die Ausgabe der letzten 20 Commits . 43 4.14 Cypher-Abfrage für die Analyse der Wissensverteilung . 44 4.15 Cypher-Abfrage für die statische Quellcodeanalyse . 47 4.16 Cypher-Abfrage für die Analyse der Testabdeckung . 48 4.17 Test der Breadcrumb-Komponente des Dashboards . 52 4.18 Dockerfile des Dashboards . 55 4.19 Befehl für die Erstellung des Docker-Images ................ 55 4.20 Befehl für die Installation des Dashboards mittels Docker ......... 55 4.21 Benötigte Befehle für die Aktualisierung des Dashboards . 56 5.1 Dockerfile für die Evaluation des Dashboards am Beispiel von Spring Pet- clinic .................................... 57 5.2 Befehl für die Installation der vorbefüllten Neo4j-Graphdatenbank mittels Docker .................................... 57 A.1 jQAssistant-Konzeptregeln für die Datenvorverarbeitung . .XI Abkürzungsverzeichnis X Abkürzungsverzeichnis API JSON Application Programming Interface [50] JavaScript Object Notation [27] CI LOC Continuous Integration [16] Lines of Code [61] CSS Cascading Style Sheet [6, 30] MVC D3 Model View Controller [26–28] Data Driven Documents [6] MVVM DOM Model View ViewModel [26–28] Document Object Model [6] HTML NPM Hypertext Markup Language [6, 25] Node Package Manager [31, 60, 61] HTTP SVG Hypertext Transfer Protocol [5] Scalable Vector Graphics [6] ISO International Organization for Standar- URL dization [9] Uniform Resource Locator [21, 35] 1 Einleitung 1 1 Einleitung Dieses Kapitel motiviert das Thema der Arbeit und formuliert die entsprechende Problem- stellung. Darüber hinaus beschreibt es die angestrebten Ziele der Arbeit. Abgeschlossen wird das Kapitel mit der Beschreibung des methodischen Vorgehens. 1.1 Motivation und Problemstellung Softwaretechnik (engl. software engineering) hat die zielorientierte Bereitstellung und sys- tematische Verwendung von Prinzipien, Methoden und
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]
  • 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]
  • 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 ©
    [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]