DOCSLIB.ORG

Insights Into the Technology and Trends Shaping the Future

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. As these platforms improve, they will learn User experience design has been a key differentiator to understand the context and intent of conversations, for technology product companies for many years. Now making interactions more lifelike and therefore more the rapid rise of developer-facing tools and products, compelling. combined with the scarcity of engineering talent, is driving a similar focus on developer experience. The explosion of interest in the marketplace and mainstream media leads to a corresponding rise in Increasingly, organizations evaluate cloud offerings developer interest in this new personal exocortex based on the amount of engineering friction they interaction mode. reduce, treat APIs as products, and spin up teams focused on engineering productivity. At ThoughtWorks, INTELLIGENCE AS A SERVICE we have always obsessed over efficient engineering practices and promoted tools and platforms that make watch the video (thght.works/IntSer) developers’ lives easier, so it excites us to see the industry beginning to adopt this approach. A family of platforms burst onto the scene recently that we call intelligence as a service. These platforms Key techniques include: treating internal infrastructure encompass a wide variety of surprisingly powerful as a product that needs to be compelling enough utilities from voice processing to natural language to compete with external offerings, focusing on self- understanding, image recognition, and deep learning. service, understanding the developer ergonomics of the APIs you produce, containing “legacy in a box”, and Capabilities that would have consumed costly resources committing to ongoing empathetic user research of the a few years ago now appear as open source or SaaS developers using your services. © ThoughtWorks, Inc. All Rights Reserved. TECHNOLOGY RADAR | 3 THE RISE OF PLATFORMS PERVASIVE PYTHON watch the video (thght.works/RiseOTP) watch the video (thght.works/PerPyt) The Radar themes emerge from observations and Python is a language that keeps popping up in conversations during the vetting process; recently, interesting places. Its ease of use as a general while compiling the Radar, we’ve noticed the number programming language, combined with its strong of new entries in the Platforms quadrant. We think foundation in mathematical and scientific computing this is indicative of a broader trend in the software has historically led to its grassroots adoption by the development ecosystem. academic and research communities. More recently, industry trends around AI commoditization and Notable Silicon Valley companies have illustrated applications, combined with the maturity of Python 3, how building a suitable platform can yield significant have helped bring new communities into the benefits. Part of their success comes from finding Python fold. a useful level of encapsulation and capabilities. Increasingly, “platform thinking” appears across the This edition of the Radar features a few Python libraries ecosystem—from advanced capabilities highlighted on that have helped boost the ecosystem, including Scikit- the Radar such as natural language, to infrastructure learn in the machine learning domain; TensorFlow, platforms such as Amazon. Keras, and Airflow for smart data flow graphs; and spaCy which implements natural language processing to Businesses are starting to think about platforms help empower conversationally aware APIs. Increasingly, when exposing select capabilities via product-inspired we see Python bridging the gap between the scientists APIs. Development teams think more in terms of and engineers within organizations, loosening past building platforms for integration and improved prejudice against their favorite tools. developer experience. It seems the industry has finally latched onto a reasonable combination of packaging, Architectural approaches such as microservices and convenience, and usefulness. containers have eased the execution of Python in production environments. Engineers can now deploy One definition that we like is that platforms should and integrate specialized Python code created by expose a self-service API and be easy to configure and scientists through language- and technology-agnostic provision within a team environment—which intersects APIs. This fluidity is a great step toward a consistent nicely with another emerging theme, developer ecosystem between researchers and engineers, experience as the new differentiator. We expect to see in contrast to the de facto practice of translating further refinement in both the definition and capabilities specialized languages such as R to the production of platforms in the near future. environments. © ThoughtWorks, Inc. All Rights Reserved. TECHNOLOGY RADAR | 4 ABOUT THE RADAR ThoughtWorkers are passionate about technology. We value to a wide range of stakeholders, from developers build it, research it, test it, open source it, write about to CTOs. The content is intended as a concise summary. it, and constantly aim to improve it—for everyone. Our mission is to champion software excellence and We encourage you to explore these technologies for revolutionize IT. We create and share the ThoughtWorks more detail. The Radar is graphical in nature, grouping Technology Radar in support of that mission. The items into techniques, tools, platforms, and languages & ThoughtWorks Technology Advisory Board, a group of frameworks. When Radar items could appear in multiple senior technology leaders in ThoughtWorks, creates quadrants, we chose the one that seemed most the Radar. They meet regularly to discuss the global appropriate. We further group these items in four rings technology strategy for ThoughtWorks and the to reflect our current position on them. technology trends that significantly impact our industry. For more background on the Radar, see The Radar captures the output of the Technology thoughtworks.com/radar/faq Advisory Board’s discussions in a format that provides RADAR AT A GLANCE 1 ADOPT 2 TRIAL We feel strongly that Worth pursuing. It is the industry should be important to understand how adopting these items. to build up this capability. We use them when Enterprises should try this appropriate on our technology on a project that projects. can handle the risk. 1 2 3 4 HOLD ASSESS TRIAL ADOPT ADOPT TRIAL ASSESS HOLD 3 ASSESS 4 HOLD Worth exploring with the Proceed with caution. goal of understanding how it will affect your enterprise. 96 108 NEW OR CHANGED Items that are new or have had significant changes since the last Radar are NO CHANGE represented as triangles, while items that have not changed are represented as circles Our Radar is forward looking. To make room for new items, we fade items that haven’t moved recently, which isn’t a reflection on their value but rather our limited Radar real estate. © ThoughtWorks, Inc. All Rights Reserved. TECHNOLOGY RADAR | 5 THE RADAR TECHNIQUES 23 ADOPT 1. Pipelines as code 22 TRIAL 2. APIs as a product 17 3. Decoupling secret management from source code NEW 4. Hosting PII data in the EU 68 21 66 67 5. Legacy in a box NEW 69 6. Lightweight Architecture Decision Records 16 7. Progressive Web Applications NEW 15 8. Prototyping with InVision and Sketch NEW 70 9. Serverless architecture 14 71 20 ASSESS 7 59 10. Client-directed query 13 58 11. Container security scanning 8 57 72 12. Conversationally aware APIs NEW 13. Differential privacy 14. Micro frontends 6 9 73 15. Platform engineering product teams NEW 19 16. Social code analysis NEW 12 17. VR beyond gaming 5 60 61 74 HOLD 18. A single CI instance for all teams 62 19. Anemic REST 11 4 75 20. Big Data envy 21. CI theatre NEW 18 63 76 22. Enterprise-wide integration test environments NEW 3 55 23. Spec-based codegen NEW 10 1 64 56 65 77 PLATFORMS 2 ADOPT HOLD ASSESS TRIAL ADOPT ADOPT TRIAL ASSESS HOLD 24. HSTS 25. Linux Security Modules 32 33 81 89 103 TRIAL 34 26 80 26. Apache Mesos 35 24 78 102 27. Auth0 88 28. AWS Device Farm NEW 79 29. AWS Lambda 36 25 30. OpenTracing NEW 87 101 31. Unity beyond gaming 37 27 100 ASSESS 32. .NET Core 38 28 85 33. Amazon API Gateway 86 99 34. api.ai NEW 39 83 35. Cassandra carefully 29 31 98 36.
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]
  • 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]
  • 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]