Modelo De TCC Para O Curso De Ciência Da Computação Da UNIVALI

Total Page:16

File Type:pdf, Size:1020Kb

Modelo De TCC Para O Curso De Ciência Da Computação Da UNIVALI UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SISTEMA INTEGRADO PARA GERENCIAMENTO DE TESTES DE SOFTWARE Narcizo Thiago Maniçoba São José, Dezembro de 2015 Orientador: Marcello Thiry, Dr Co-Orientadora: Anita Maria da Rocha Fernandes, Dra Área de Concentração: Engenharia de software Linha de Pesquisa: Qualidade e teste de software Palavras-chave: testes, defeitos, usabilidade Número de páginas: 132 i UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SISTEMA INTEGRADO PARA GERENCIAMENTO DE TESTES DE SOFTWARE Narcizo Thiago Maniçoba São José, Dezembro de 2015 Orientador: Marcello Thiry, Dr Co-Orientadora: Anita Maria da Rocha Fernandes, Dra Área de Concentração: Engenharia de software Linha de Pesquisa: Qualidade e teste de software Palavras-chave: testes, defeitos, usabilidade Número de páginas: 132 RESUMO Os testes são parte fundamental para garantir a qualidade de um software antes que ele seja usado pelo cliente, e documentar os planos de teste e os relatos de defeitos encontrados é tão importante quanto executá-los, pois dessa forma, dentre muitas vantagens, garante-se a padronização dos testes e a disseminação do conhecimento. Considerando as ferramentas para gestão de testes e as ferramentas para gestão de defeitos gratuitos mais utilizados atualmente, percebe-se que não há uma solução integrada e com boa usabilidade (considerando as 10 heurísticas de Nielsen (1993)) para documentar, na mesma ferramenta, os testes que foram executados e os defeitos que foram encontrados durante os testes de software. Além disso, essas ferramentas não empregam conceitos de usabilidade, então a equipe tende a não documentar ou documentar apenas uma parte dos testes e defeitos pois tem que usar, no mínimo, duas ferramentas e a usabilidade não é boa. Diante desses fatos, o objetivo deste trabalho foi desenvolver uma única ferramenta que contemple as funcionalidades essenciais presentes nas ferramentas gratuitas de gestão de testes e nas ferramentas gratuitas de gestão de defeitos disponíveis no mercado utilizando-se conceitos de usabilidade. Com uma ferramenta integrada, acredita-se que o cruzamento dos testes x defeitos fiquem mais evidentes e os dados sejam melhor aproveitados para análise posterior. Tendo uma ferramenta com boa usabilidade, busca-se despertar o interesse na equipe em documentar os testes e defeitos de maneira correta. ii LISTA DE FIGURAS Figura 1. Custo relativo para corrigir um defeito. ................................................................................... 20 Figura 2. Relação do custo da qualidade para prevenir e corrigir defeitos. ............................................ 21 Figura 3. Definição de defeito, erro e falha. ........................................................................................... 22 Figura 4. Causas de defeitos durante o desenvolvimento do software. .................................................. 23 Figura 5. Dimensões dos testes. .............................................................................................................. 25 Figura 6. Modelo V: paralelismo entre as atividades de desenvolvimento e teste de software. ............. 32 Figura 7. Relação entre coisas óbvias e coisas que fazem o usuário pensar. .......................................... 35 Figura 8. Exemplo de elementos aninhados visualmente. ...................................................................... 36 Figura 9. Exemplo de correta aplicação da heurística Visibilidade do Estado do Sistema .................... 37 Figura 10. Exemplo de correta aplicação da heurística Compatibilidade entre Sistema e Mundo Real 37 Figura 11. Exemplo de correta aplicação da heurística Liberdade e Controle do Usuário. .................... 38 Figura 12. Exemplo de violação da heurística Consistência e Padrões. ................................................. 38 Figura 13. Exemplo de violação da heurística Prevenção de Erro. ......................................................... 39 Figura 14. Exemplo de violação da heurística Ênfase no Reconhecimento. .......................................... 40 Figura 15. Exemplo de violação da heurística Flexibilidade e Eficiência no Uso. ................................. 40 Figura 16. Exemplo de violação da heurística Auxílio, Diagnóstico e Recuperação de Erros. .............. 41 Figura 17. Popularidade das ferramentas bug trackers open source. ...................................................... 45 Figura 18. Popularidade das ferramentas bug trackers open source e comerciais. ................................. 46 Figura 19. Comparativo Bloodhound, Bug-A-Boo, BugNET, BugTracker e Bugzilla. ......................... 47 Figura 20. Comparativo Eventum, Flyspray, Fossil, JTrac e Kwok bug tracker. ................................... 48 Figura 21. Comparativo Mantis, oops-easytrack, phpBugTracker, Redmine e Request Tracker. .......... 48 Figura 22. Comparativo Roundup, RTH, Scarab, Trac e WebIssues. .................................................... 49 Figura 23. Comparativo zenTrack. ......................................................................................................... 50 Figura 24. Popularidade das ferramentas de gestão de testes open source. ............................................ 52 Figura 25. Comparativo QATraq, Radi-testdir, RTH e Sitechco. ........................................................... 53 Figura 26. Comparativo Tesly, Test Case Web, Testia Tarantula e Testitool. ....................................... 54 Figura 27. Comparativo TestLink, Testmaster e Testopia. ..................................................................... 54 Figura 28. TestLink: página principal. .................................................................................................... 56 Figura 29. TestLink: links do menu superior representados por ícones pequenos e sem labels. ............ 59 Figura 30. TestLink: campo de pesquisa na barra superior é somente para casos de teste..................... 60 Figura 31. TestLink: botão criar usuário posicionado após a tabela. ...................................................... 61 Figura 32. TestLink: usuário precisa digitar um ID único ao cadastrar um novo projeto. ..................... 62 Figura 33. TestLink: página de pesquisa de requisitos. .......................................................................... 63 Figura 34. TestLink: página de pesquisa de casos de teste. .................................................................... 63 Figura 35. TestLink: página de pesquisa de casos de teste criados por usuário. .................................... 64 Figura 36. TestLink: é necessário clicar no ícone para mostrar as opções da Suíte e Caso de teste. ..... 64 Figura 37. TestLink: é necessário saber o id do caso de teste antes de criar a relação. .......................... 65 Figura 38. Testopia: página de visualização do estado das execuções dos testes. .................................. 66 Figura 39. Testopia: menu com as operações para gestão de defeitos e testes. ...................................... 67 Figura 40. Testopia: é necessário pressionar Enter após digitar o termo de pesquisa no campo. .......... 68 Figura 41. Testia Tarantula: página de execução de casos de teste. ....................................................... 69 Figura 42. Testia Tarantula: página de visualização dos usuários cadastrados. ..................................... 71 Figura 43. Testia Tarantula: página de adição de casos de teste ao plano de teste. ................................ 72 Figura 44. Mantis: página principal. ....................................................................................................... 73 Figura 45. Mantis: formulários não apresentam a opção Cancelar. ........................................................ 75 iii Figura 46. Mantis: permite anexar apenas um arquivo por vez no relato de defeito. ............................. 75 Figura 47. Mantis: ações “Monitorar” e “Marcar como Pegajoso” não são óbvias para o usuário. ..... 75 Figura 48. Mantis: relação entre relatos de defeito obriga o usuário a saber o número do caso. ........... 76 Figura 49. Bugzilla: página de pesquisa de relatos de defeito. ............................................................... 77 Figura 50. Bugzilla: página de seleção de projeto para pesquisa de defeitos. ........................................ 79 Figura 51. Bugzilla: página de seleção do componente do projeto para pesquisa dos defeitos. ............. 80 Figura 52. Bugzilla: permite anexar apenas um arquivo por vez no relato de defeito. ........................... 80 Figura 53. Bugzilla: histórico de modificações do relato de defeito. ..................................................... 81 Figura 54. Bugzilla: títulos das páginas são apresentadas acima do menu superior. .............................. 81 Figura 55. BugNET: Página principal..................................................................................................... 82 Figura 56. BugNET: permite anexar apenas um arquivo por vez no relato de defeito. .......................... 84 Figura 57. Ferramenta proposta: tela de pesquisa de projetos cadastrados. ........................................... 96 Figura 58. Ferramenta proposta: tela de execução dos casos de teste. ................................................... 97 Figura 59. Ferramenta proposta: tela de cadastro de relato de defeito. .................................................
Recommended publications
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01
    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
    [Show full text]
  • Defect Tracking System Project Documentation
    Defect Tracking System Project Documentation Tottering Barr azotise some Faust and gyps his surplices so sweetly! Northrup remains impellent after Sigfried havers nominally or fluorescing any good-byes. Remus orientalize thunderously? So much like automation and project defect tracking documentation but not win any kind of the organization tries to track the list by the beginning development team and let an. The amount of tracking system project defect tracking system! All comments are moderated before publication and desire meet our guidelines. Testing is a lousy part of mature software life cycle, and recent trends in software engineering evidence the importance all this activity all survey the development process. Diving deeper into program language theory is a great way data grow outside a developer. Your comment has been received. Bug reporting by the Web and email. Her homeland of interests are Wireless Networks and Database Management Systems. As projects grow in size and complexity, the limits of an Excel story for tracking issues begin to show which quickly. Thank who for using our services. Ten reports engine is a few lines of system project defect tracking documentation appears every single pane contains the. Defect tracking is responsible system authority is applied for any system software so run system performs well. User interface and learning curve the system user interfaces are more user friendly than others. Switch to fullscreen mode always show business bug attributes at once. Some custom structure for large body usually, evaluating and tracking system project defect documentation related documents, planning with your development organization efficiently and eliminate bad.
    [Show full text]
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ■ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ■ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ■ discordapp.com ▹ Slack ■ slack.com ▹ Riot.im ■ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • Návrh a Implementace Rozšíření Do Systému Phabricator
    Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Lukáš Jagoš Vedoucí práce: Martin Komenda i Poděkování Srdečně chci na tomto místě poděkovat vedoucímu mé diplomové práce RNDr. Martinu Komendovi, Ph.D. za cenné náměty a odborné vedení. Dále chci poděkovat Mgr. Matěji Karolyi za všestrannou po- moc při implementaci praktické části práce a Ing. Mgr. Janu Krejčímu za zpřístupnění testovacího serveru a technickou podporu. iii Shrnutí Diplomová práce se zabývá nástroji pro projektové řízení. V teore- tické části jsou vymezeny pojmy projekt a projektové řízení. Poté jsou představeny vybrané softwarové nástroje pro projektové řízení a je provedeno jejich srovnání. Pozornost je zaměřena na systém Phabrica- tor, který je v práci detailně popsán. V praktické části je navrženo rozšíření Phabricatoru na základě analýzy potřeb a sběru požadavků. Výsledkem je rozšířující modul po- skytující přehledné informace o úkolech z pohledu času a náročnosti, čímž zefektivní jejich plánování a proces týmové spolupráce. iv Klíčová slova projektové řízení, Phabricator, PHP, reportovací modul, SCRUM v Obsah 1 Projektové řízení 3 1.1 Projekt a projektové řízení ..................3 1.2 SW nástroje pro projektové řízení ...............4 1.3 Přehled nástrojů z oblasti řízení projektů ...........6 1.3.1 Phabricator .
    [Show full text]
  • Jira Team Satisfaction Report
    Jira Team Satisfaction Report Alister pricing his shareholders bights bearably, but photoelectric Andros never metricate so ruminantly. Animate and scaldic beneficiaryHaywood often Jarvis coxes dignify some jadedly. prince's-feather helluva or disprizes graspingly. Enured Curtice nictate some mainlanders after Your prospect to unlocking Agile Testing in Jira Xray Blog. The team receive the latter. What the types to manage service desk was reported issues across all cards on jira service management, they can otherwise have? Track or the ticket fields, apply them to fit your production processes set one of the right balance between multiple tags templates. Soon the jira service customer satisfaction report or jira service management can reject merge opsgenie with integrity team members permission to access and bug issue. Your current Info-Tech Research Group subscription does not vehicle access to medicine content. It teams have embraced them explore administrator global email for jira satisfaction surveys to reporter field values are. In jira satisfaction report had us and kanban to reporter field id and quantitative and look at the date, it simpler alternative that we! First in Time Report report Report Builder Whether you are eating in force support or lock desk has Crucial for chemistry success reduce customer satisfaction is. In 2012 I lead a partition to install Atlassian suite of products in a brittle environment. Changepoint Extends Market-Leading Daptiv PPM Solution to. 5 Reasons to seize an Employee Satisfaction Survey. It team satisfaction report bugs to jira alternative for multiple checklists templates that you get access to send customers will only offer a rather with? Customer satisfaction or CSAT is how key performance indicator that tracks how satisfied.
    [Show full text]
  • Application Lifecycle Management Tools Open Source
    Application Lifecycle Management Tools Open Source Posh and tropistic Christofer congees almost despondingly, though Sam humiliating his breastworks recoins. Jorge usually assassinates astringently or disrupt crustily when interterritorial Marko voids streakily and convivially. Irresponsible Vijay unround broadly. With the software changes into three core business reason for anyone using powerful lifecycle tools across public activity management The package includes OSS project management tool Redmine and version. This year open source ALM tuleap httpwwwenaleancomentuleap is altogether good start. ALM tools automate the software development and deployment processes help. Micro Focus Application Lifecycle Management ALM software and solutions. Virtual flavor of the product with its embedded and application software before. Greg Lindhorst Principal Program Manager Thursday January 14 2021. The more List and Open-source Tools View ahead complete list ANT Anypoint Platform. Application Lifecycle Management Tools ALM is the continuous process of. Top 10 Application Lifecycle Management Tools For end Year. A degree to two the limitations of save open-source circuit otherwise inadequate tool. Best Free Application Lifecycle Management Software 2021. Each document type main source code is managed with SubversionSVN with. It is free of tools are the advent of the use after year after going through it connects people meet business outcomes as and open application source tools? Application Lifecycle Management SoftLanding. Top Application Lifecycle Management ALM Toolsets InfoQ. They also have original single proponent of truth providing any relevant. Then view the software projects, open application lifecycle management tools on open source option, and hybrid it can create and. Software lifecycle management SLM is the discipline for managing.
    [Show full text]
  • Github Essentials.Pdf
    [ 1 ] GitHub Essentials Unleash the power of collaborative workflow development using GitHub, one step at a time Achilleas Pipinellis BIRMINGHAM - MUMBAI GitHub Essentials Copyright © 2015 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: September 2015 Production reference: 1280915 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78355-371-6 www.packtpub.com Credits Author Copy Editor Achilleas Pipinellis Trishya Hajare Reviewer Project Coordinator Umesh Ram Sharma Shweta H Birwatkar Commissioning Editor Proofreader Dipika Gaonkar Safis Editng Acquisition Editor Indexer Nikhil Karkal Hemangini Bari Content Development Editor Production Coordinator Sumeet Sawant Nitesh Thakur Technical Editor Cover Work Saurabh Malhotra Nitesh Thakur About the Author Achilleas Pipinellis is an open source enthusiast and tries to get involved in as many projects as possible.
    [Show full text]
  • Analysis and Prediction of Number of Open Bugs Per Day by Using
    International Journal of Research and Scientific Innovation (IJRSI) | Volume V, Issue V, May 2018 | ISSN 2321–2705 Analysis and Prediction of Open Bugs Using Machine Learning Algorithms Sachin A S, Dr. Rajashree Shettar Department of Computer Science and Engineering, R V College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Abstract– There are many fault tracking repositories, some of problem[2]. Atlassian JIRA, Bugzilla, Mantis BT, Trac, them are YouTrack, Bugzilla, MantisBT and Atlassian JIRA. YouTrack etc., are some of the issue tracking systems which Atlassian JIRA repository has been used in this study, as it is are used in the software industries. But most extensively extensively accepted by most of the software companies. This accepted are JIRA and Bugzilla as they provide many features repository contains significant information of many projects. which are helpful for software development like task tracking, Each project has different kinds of issues such as bug(faults) reports, enhancement required to an existing feature, and new issues, bug, features many plugins to integrate with versioning feature of the product and task that needs to be done. This paper systems such as Git, mercury etc., and project management. focuses on analysing the previously raised bug report(history) to Consistently both commercial and open source projects understand the correlation and dependability of the attributes experience many changes to represent new client requirements like number of bugs created per day, their priority, number of days or hours taken to resolve etc., The data is then processed with the consideration of improving existing features, creation into a new format which will comply to machine learning of new features or to fix bugs.
    [Show full text]
  • Project Management Software March 2019
    PROJECT MANAGEMENT SOFTWARE MARCH 2019 Powered by Methodology CONTENTS 3 Introduction 5 Defining Project Management Software 6 FrontRunners (Small Vendors) 8 FrontRunners (Enterprise Vendors) 10 Runners Up 22 Methodology Basics 2 INTRODUCTION his FrontRunners analysis minimum qualifying score of 3.96 Tis a data-driven assessment for Usability and 3.91 for User identifying products in the Project Recommended, while the Small Management software market that Vendor graphic had a minimum offer the best capability and value qualifying score of 4.55 for Usability for small businesses. For a given and 4.38 for User Recommended. market, products are evaluated and given a score for Usability (x-axis) To be considered for the Project and User Recommended (y-axis). Management FrontRunners, a FrontRunners then plots 10-15 product needed a minimum of 20 products each on a Small Vendor user reviews published within 18 and an Enterprise Vendor graphic, months of the evaluation period. based on vendor business size, per Products needed a minimum user category. rating score of 3.0 for both Usability and User Recommended in both In the Project Management the Small and Enterprise graphics. FrontRunners infographic, the Enterprise Vendor graphic had a 3 INTRODUCTION The minimum score cutoff to be included in the FrontRunners graphic varies by category, depending on the range of scores in each category. No product with a score less than 3.0 in either dimension is included in any FrontRunners graphic. For products included, the Usability and User Recommended scores determine their positions on the FrontRunners graphic. 4 DEFINING PROJECT MANAGEMENT SOFTWARE roject management software and document management, as well Phelps organizations manage as at least one of the following: time and deliver projects on time, on tracking, budgeting, and resource budget and within scope.
    [Show full text]
  • The Opendaylight Open Source Project
    UNIVERSIDAD REY JUAN CARLOS Master´ Universitario en Software Libre Curso Academico´ 2014/2015 Proyecto Fin de Master´ The OpenDaylight Open Source Project Autor: Sergio Najib Arroutbi Braojos Tutor: Dr. Gregorio Robles 2 Agradecimientos A mi familia y a mi pareja, por su apoyo incondicional Al equipo de Libresoft de la Universidad Rey Juan Carlos, por su afan´ en ensenar˜ el que´ y el porque´ del Software Libre Dedicatoria Para todos aquellos´ que hacen posible el fenomeno´ del Software Libre 4 (C) 2014 Sergio Najib Arroutbi Braojos. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/ Source files for this document are available at http://github.com/sarroutbi/MFP/opendaylight/ 6 Contents 1 Introduction 19 1.1 Terminology.................................... 19 1.1.1 Open Source Programmable Networking................ 19 1.2 About this document............................... 20 1.2.1 Document structure............................ 20 1.2.2 Scope................................... 21 1.2.3 Methodology............................... 21 2 Goals and Objectives 23 2.1 General Objectives................................ 23 2.2 Subobjectives................................... 23 2.2.1 Acquire competence on OpenDaylight project.............. 23 2.2.2 Analyze OpenDaylight project from an Open Source perspective.... 24 2.2.3 Statistics and measures of the OpenDaylight project.......... 24 3 OpenDaylight: A first view 25 3.1 OpenDaylight Project............................... 25 3.2 SDN........................................ 29 3.2.1 What is SDN?.............................. 29 3.2.2 SDN: Market share and expectations................... 31 3.3 NFV........................................ 34 3.3.1 What is NFV?.............................. 35 3.3.2 SDN/NFV relationship.......................... 36 3.3.3 NFV benefits..............................
    [Show full text]
  • Software Development Process Improvements - Case QPR Software Plc
    Software development process improvements - Case QPR Software Plc Lidia Zalevskaya Master’s Thesis Degree Programme in Information Systems Management 2019 Abstract Date: 2019.11.24 Author(s) Lidia Zalevskaya Degree programme Information Systems Management, Master’s Degree Thesis title Number of pages and appendix pages Software development process improvements - 98 + 26 Case QPR Software Plc Initially this study was planned as an effort to improve on a software development process within an existing team using an existing product code and systems. However, the situation changed and a new team (DevApps team) was established and given a new project, which created an opportunity to build a new type of team, product, process, and tools pipeline from scratch utilizing the improvement ideas. An Action Research framework was adopted as the theoretical approach for the study, while the Scrum methodology served as a framework for the development practices. The study began by summarizing previously identified problems in the software development process at QPR Software Plc and formulating improvement ideas focused on the coding workflow and Scrum practices. These were then tested in practice by the new DevApps scrum team. The research analysis centres on the process of choosing and setting up the new team’s development tools, figuring out ways of working, and implementing several iterations to find the best suitable development process. The most valuable empirical outcomes were the creation of a branching strategy and Git workflow for the DevApps team, the team members’ practical experience of working with Git and with the Azure DevOps developer services. A key outcome was the shift in many verification activities to earlier phases.
    [Show full text]