Est_gio_Supervisionado_em_SI_II

Prévia do material em texto

LUCAS SAMUEL ASSIS DE PAULA
ANÁLISE COMPARATIVA DE MODELOS DE PROCESSOS DE SOFTWARE
ÁGIL: SCRUM E EXTREME PROGRAMMING (XP)
PARANAVAÍ
2018
LUCAS SAMUEL ASSIS DE PAULA
ANÁLISE COMPARATIVA DE MODELOS DE PROCESSOS DE SOFTWARE
ÁGIL: SCRUM E EXTREME PROGRAMMING (XP)
Trabalho de Conclusão de Curso apresentado
à banca examinadora do curso de Sistemas
de Informação da Universidade Paranaense
- UNIPAR, como exigência parcial para ob-
tenção do grau de Bacharel em Sistemas de
Informação.
UNIVERSIDADE PARANAENSE
CURSO DE SISTEMAS DE INFORMAÇÃO
Orientador: Jaime William Dias
PARANAVAÍ
2018
FOLHA DE APROVAÇÃO 
 
 
 
 
 
 
LUCAS SAMUEL ASSIS DE PAULA 
 
 
 
 
 
 
ANÁLISE COMPARATIVA DE MODELOS DE PROCESSOS DE SOFTWARE 
ÁGIL: SCRUM E EXTREME PROGRAMMING (XP) 
 
 
 
 
 
Trabalho de conclusão aprovado como requisito parcial para a obtenção do grau de Bacharel 
em Sistemas de Informação da Universidade Paranaense – UNIPAR, pela seguinte banca 
examinadora: 
 
 
 
_____________________________________ 
Profa. Ma. Claudete Werner 
Mestre em Ciência da Computação 
 
 
 
_____________________________________ 
Prof. Me. Jaime William Dias 
Mestre em Ciência da Computação 
 
 
 
_____________________________________ 
Prof. Me. Wyllian Fressatti 
Mestre em Sistemas de Computação 
 
 
 
PARANAVAÍ 
2018 
LUCAS SAMUEL ASSIS DE PAULA
ANÁLISE COMPARATIVA DE MODELOS DE PROCESSOS DE SOFTWARE
ÁGIL: SCRUM E EXTREME PROGRAMMING (XP)
Trabalho de conclusão aprovado como requisito parcial para obtenção de grau de
Bacharel em Sistemas de Informação da Universidade Paranaense – UNIPAR, pela
seguinte banca examinadora:
Prof. Me. Jaime William Dias
Mestre em Ciência da Computação
Profa. Ma. Claudete Werner
Mestre em Ciência da Computação
Prof. Me. Wyllian Fressati
Mestre em Sistemas de Computação
PARANAVAÍ
2018
DEDICATÓRIA
Dedico esse trabalho primeiramente a Deus, por ser essencial na minha vida, autor
do meu destino, meu guia, meu socorro presente na hora da angústia, ao meu pai Leonel,
minha mãe Tainir, minha irmã Thaisa, minha namorada Gabriele e a todos meus amigos
em especial Alex Sousa, Bruno Franco, Guilherme Lopes, Alexandre José e Matheus
Bianchi.
AGRADECIMENTOS
À Instituição pelo ambiente criativo e amigável que proporciona. A Universidade
Unipar pela oportunidade de fazer o curso. A esta universidade, seu corpo docente, direção
e administração.
“O homem se torna muitas vezes o que ele próprio acredita que é. Se insisto em repetir
para mim mesmo que não posso fazer uma determinada coisa, é possível que acabe me
tornando realmente incapaz de fazê-la. Ao contrário, se tenho a convicção de que posso
fazê-la, certamente adquirirei a capacidade de realizá-la, mesmo que não a tenha no
começo."
(Mahatma Gandhi))
RESUMO
O aumento na procura do software e a grande demanda em que as indústrias precisam
projetar, acarretam em problemas relacionados ao processo de desenvolvimento de siste-
mas, tais como: alto custo, alta complexidade, dificuldade de manutenção e uma grande
diferença entre os requisitos solicitados pelos usuários e o produto final entregue. O de-
senvolvimento de um software deve ser feito de acordo com as regras da engenharia de
software, uma possível solução para que o desenvolvimento do mesmo saia de acordo com
o planejado, é utilizar um método de desenvolvimento de software adequado ao negócio,
afim de ganhar em qualidade e poder mensurar de forma mais precisa o tamanho e o
custo do projeto, propiciando uma maior satisfação por parte do cliente e ainda ter a
possibilidade de maximizar o lucro da empresa.
Essa investigação científica explana uma breve descrição sobre a ciência Engenharia de
Software, enfatizando dois modelos de processos ágeis o Scrum e o Extreme Programming,
explicando seus principais conceitos, métodos adotados, análise comparativa entre as me-
todologias e um experimento afim de aferir as mesmas. Como um resultado preliminar,
não existe o melhor modelo de processo de software ágil para o desenvolvimento de pro-
duto computacional. A forma deve ser escolhida de acordo com as necessidades da área de
aplicação da empresa, pois cada um atende uma necessidade diferente, a equipe de desen-
volvimento que escolherá o que se adequará ao processo de desenvolvimento. Mediante o
experimento científico foi possível observar uma evolução no processo de desenvolvimento
de software, no qual 93,8% dos voluntários notaram após a implantação das metodologias
ágeis.
Palavras-chaves: Engenharia de Software, Sofware, Scrum, Extreme Programming
ABSTRACT
The increase in the demand for software and the high demand in which the need to design,
lead to problems related to the process of systems development, such as: high cost, high
complexity, maintenance and a great difference between the requirements requested by
users and the final product delivered. The development of software should be done in
accordance with the rules of software engineering, a possible solution for the development
of the same skirt according to the plan, is to use a method of development of software
suitable for the business, in order to gain in quality and to be able to more precise the
size and cost of the project, providing greater satisfaction for part of the customer and
still have the possibility to maximize the company’s profit.
This scientific research explores a brief description of science, emphasizing two models of
agile processes Scrum and Extreme Programming, explaining its main concepts, methods
adopted, comparative analysis between the methodologies and an experiment in order to
verify them. As a preliminary result, there is no best agile software process model for
computational product development. THE should be chosen according to the needs of
the area of application of the because each one meets a different need, the that will fit
the development process. Through the scientific experiment it was possible to observe an
evolution in the software development process, in which 93.8 % of the volunteers noticed
after the implementation of the agile methodologies.
Key-words: Software Engineering, Software, Scrum, Extreme Programming
LISTA DE ILUSTRAÇÕES
Figura 1 – Representa modelo tecnologia em camadas . . . . . . . . . . . . . . . . 21
Figura 2 – Representa o modelo sequencial linear (Clássico ou Cascata . . . . . . 26
Figura 3 – Representa o modelo de prototipação . . . . . . . . . . . . . . . . . . 27
Figura 4 – Representa o modelo espiral . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 5 – Representa o modelo incremental . . . . . . . . . . . . . . . . . . . . . 29
Figura 6 – Fluxo do Processo Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 7 – Fluxo do Processo XP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 8 – Primeira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 9 – Segunda Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 10 – Terceira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 11 – Quarta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 12 – Experimento - Gráfico 1 - Titulação dos Voluntários . . . . . . . . . . . 46
Figura 13 – Quinta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 14 – Experimento - Gráfico 2 - Utilização da Metodologia Ágil . . . . . . . . 48
Figura 15 – Sexta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 16 – Experimento - Gráfico 3 - Qual é Metodologia Mais Utilizada . . . . . 49
Figura 17 – Sétima Pergunta (Scrum) . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 18 – Experimento - Gráfico 4 - Nível de Conhecimento na Metodologia Scrum 50
Figura 19 – Sétima Pergunta (XP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 20 – Experimento - Gráfico 5 - Nível de Conhecimento na Metodologia XP . 51
Figura 21 – Oitava Pergunta . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 52
Figura 22 – Experimento - Gráfico 6 - Dificuldades Encontradas na Implementação
da Metodologia Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 23 – Nona Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 24 – Experimento - Gráfico 7 - Palavras Chaves Quando se Refere ao De-
senvolvimento Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 25 – Decima Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 26 – Experimento - Gráfico 8 - Evolução no Processo de Desenvolvimento
após Implementação de Metodologia Ágil . . . . . . . . . . . . . . . . 55
Figura 27 – Decima Primeira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 28 – Experimento - Gráfico 9 - Vantagens Alcançadas com a Utilização das
Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 29 – Decima Segunda Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 30 – Experimento - Gráfico 10 - Evolução na Produtividade da Equipe após
Implementação de Metodologia Ágil . . . . . . . . . . . . . . . . . . . 58
Figura 31 – Decima Terceira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 32 – Experimento - Gráfico 11 - Avaliação do Uso da Metodologia Ágil no
Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 33 – Decima Quarta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 34 – Experimento - Gráfico 12 - Identificar se o Processo de Desenvolvimento
é Seguido Corretamente . . . . . . . . . . . . . . . . . . . . . . . . . . 60
LISTA DE TABELAS
Tabela 1 – Experimento - Análise Comparativa . . . . . . . . . . . . . . . . . . . 36
Tabela 2 – Experimento - Lista geral das respostas das questões 1,2,3 e 4 . . . . . 47
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Enunciado do Problema . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . 16
2 O ESTADO DA ARTE . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 SCRUM E XP: Um comparativo no processo de desenvolvi-
mento de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Analise Comparativa das Metodologias Ágeis: Scrum, XP e
FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Análise das Metodologias Ágeis XP e Scrum no Desenvolvi-
mento de um Software de Gerenciamento de Abastecimento . 18
2.4 Métodos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Comparação Entre os Processos dos Métodos Ágeis XP, Scrum
e FDD e ASD em Relação ao Desenvolvimento Iterativo In-
cremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 ENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . 20
3.1 Conceito de Software . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Conceito de Engenharia de Software . . . . . . . . . . . . . . . . 20
3.3 Campos de aplicação do software . . . . . . . . . . . . . . . . . . 21
3.3.1 Software de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Software de aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Software científico/engenharia . . . . . . . . . . . . . . . . . . . . 22
3.3.4 Software embutido . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.5 Software para linha de produtos . . . . . . . . . . . . . . . . . . . 22
3.3.6 Aplicações para a Web/Aplicações Móveis . . . . . . . . . . . . 23
3.3.7 Software de inteligência artificial . . . . . . . . . . . . . . . . . . 23
3.4 Processo de software . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Modelos de processo . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1 Modelos Tradicionais . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1.1 Modelo de Processo Sequencial Linear (Clássico ou Cascata) . . . 26
3.5.1.2 Modelo Protótipo / Prototipação . . . . . . . . . . . . . . . . . . . 27
3.5.1.3 Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1.4 Modelo de Processo Incremental . . . . . . . . . . . . . . . . . . . . 28
3.5.2 Modelos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.2.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 ANALISE COMPARATIVA . . . . . . . . . . . . . . . . . . . . 36
4.1 Comparação Scrum e Extreme Programming (XP) . . . . . . . 36
4.2 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 ENGENHARIA EXPERIMENTAL . . . . . . . . . . . . . . . . 38
5.1 Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Objetivos da Experimentação . . . . . . . . . . . . . . . . . . . . 39
5.3 Tipos de Experimentos . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.3 Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 EXPERIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1 Descrição do contexto e objetivos do experimento . . . . . . . 43
6.2 Resultados do Experimento . . . . . . . . . . . . . . . . . . . . . 43
6.2.1 Caraterização e Nível de Escolaridade do Grupo . . . . . . . . 44
6.2.2 Primeira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.3 Segunda Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.4 Terceira Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.5 Quarta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.6 Identificação de Compreensão e Usabilidade em Modelos de
Processos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.7 Quinta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.8 Sexta Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.9 Sétima Pergunta - Scrum . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.10 Sétima Pergunta - Extreme Programming (XP) . . . . . . . . . 50
6.2.11 Identificação dos Benefícios, Malefícios e Caraterísticas Espe-
cificas Com o Uso das Metodologias Ágeis . . . . . . . . . . . . 51
6.2.12 Oitava Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.13 Nona Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.14 Decima Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.15 Decima Primeira Pergunta . . . . . . . . . . . . . . . . . . . . . . 55
6.2.16 Decima Segunda Pergunta . . . . . . . . . . . . . . . . . . . . . . 57
6.2.17 Decima Terceira Pergunta . . . . . . . . . . . . . . . . . . . . . . 58
6.2.18 Decima Quarta Pergunta . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
14
1 INTRODUÇÃO
Desde os primórdios da humanidade onde o homem passa a viver em sociedade a
população tende a buscar evolução com o objetivo de melhorar a vida em coletividade.
A tecnologia tem um papel fundamental na história da sociedade, desde o princí-
pio esta acompanhouo homem em sua evolução. A tecnologia não se baseia apenas na
informática, esta, inventada pelos primatas auxiliaram na sobrevivência da sociedade da
época fazendo com que o homem se tornasse dependente da sua criação.
Nos dias atuais o homem se tornou completamente dependente da tecnologia, a
mesma evoluiu tomando níveis extremamente altíssimos de desenvolvimento. No meio
de toda tecnologia pode se voltar a atenção para o software, o qual está presente no
cotidiano das pessoas sendo um instrumento indispensável para o ser humano. O software
está presente nas necessidades básicas do cotidiano e nas operações científicas complexas.
Segundo Pressman (2011), Softwares são instruções (programas de com-
putadores) que, quando executadas, fornecem as características, funções
e desempenho desejados; definem-se ainda como uma estrutura de da-
dos que permite aos programas manipular adequadamente a informação
e documentos que descrevem as operações e o uso dos programas.
Os softwares se tornaram gradativamente mais complexos, sendo responsáveis por
atividades que não há margem de erro, sendo assim se faz necessário o estudo da ciência
da engenharia de software.
Segundo Pressman (2011), "Engenharia de software é o estabelecimento e o em-
prego de sólidos princípios de engenharia de modo a obter software de maneira econômica,
que seja confiável e funcione de forma eficiente em máquinas reais".
Dentro da Engenharia de Software há áreas de estudos que auxiliam no processo
de obtenção do mesmo, o modelo de processos de software é uma das áreas principais na
Engenharia de Software também sendo o tema principal desta pesquisa científica.
Segundo Pressman (2011), "processo de software é definido como uma metodo-
logia para atividades ações e tarefas necessárias para desenvolver um software de alta
qualidade".
O modelo de software é o roteiro que deve ser seguido para elaboração do mesmo,
este modelo bem definido, seguindo os padrões da metadologia e as regras da Engenharia
de Software são os passos necessários para alcançar um software de alta qualidade.
Capítulo 1. Introdução 15
1.1 Objetivos
I – Realizar uma breve revisão bibliográfica sobre Engenharia de Software com
ênfase em Modelos de Processos de Software ágil e tradicional;
II - Fazer uma investigação científica sobre Modelos de Processos de Software Ágil:
Scrum e Extreme Programming (XP);
III – Realizar uma análise comparativa entre os modelos de processos levantados
no item II;
IV – Expor um questionário para empresas de desenvolvimento de software sobre
os modelos de processos levantados no item II;
V – Expor um questionário para desenvolvedores de software sobre os modelos de
processos levantados no item II;
VI - Projetar os resultados das avaliações.
1.2 Justificativa
Cada vez mais os setores da economia (primário, secundário e terciá-
rio) tem feito uso (e se tornado dependente) das facilidades providas
pelos avanços e descobertas da tecnologia da informação. Tecnologias de
previsão do tempo e de localização via satélite, por exemplo, são utiliza-
das no campo para aumentar a produtividade da lavoura e a eficiência
de maquinas colheitadeiras. Softwares que gerenciam toda a cadeia de
produção e que controlam máquinas e robôs são cada vez mais comuns
nas fábricas. Sistemas de venda e controle de estoque são diferenciais
estratégicos indispensáveis ao comércio. Diante deste cenário, produzir
e manter software dentro de custos, prazos e critérios de qualidade ade-
quados torna-se requisito obrigatório (PRESSMAN, 2011).
O modelo de processo é de grande relevância no processo de desenvolvimento de
software, com o grande avanço da tecnologia a sociedade atual se tornou dependente
de produtos computacionais que tem por objetivo facilitar o dia a dia. Um software
desenvolvido sem padrões de engenharia, pode se tornar um grande problema para os
seus utilizadores e também para seus desenvolvedores tornando-o de difícil manutenção.
1.3 Enunciado do Problema
O produto computacional no cenário presente tem trazido facilidades à sociedade,
o software propiciou redução de gastos, redução de mão de obra, agilidade, melhora na
tomada de decisões, segurança na informação, automatizações de processos dentre outros
benefícios. Um software desenvolvido sem padrões de engenharia impacta diretamente na
sociedade. O modelo de processos de software é um dos padrões de engenharia, escolher
o processo correto para o desenvolvimento de software é de grande importância. Logo a
Capítulo 1. Introdução 16
análise comparativa de dois modelos de processo de software ágil proporcionará uma visão
mais ampla sobre a importância deste no processo.
1.4 Metodologia
Revisão de literatura: Apresentar referências teóricas de grandes intelectuais da
área de engenharia de software com ênfase em modelos de processos ágil.
Pesquisa de campo: Observar, analisar e coletar dados de empresas de desenvol-
vimento de software através de um questionário referente ao modelos de processos de
software ágil.
Levantamento de dados: Divulgar um questionário com perguntas sobre modelos
de processos de software ágil para desenvolvedores de software.
1.5 Organização do Trabalho
O capítulo 2 demonstrará os trabalhos correlatos, os quais têm estreita relação com
o tema geral deste trabalho, com o objetivo de enriquecer cientificamente a monografia.
O capítulo 3 refere-se a ciência da Engenharia de Software a qual compreende o
conteúdo responsável pela qualidade do produto computacional. Nesse contexto destaca-
se o conceito do software, as suas áreas de aplicação, os processo de software, bem como
as metodologias tradicionais e ágeis.
O capítulo 4 apresentará uma análise comparativa entre as metodologias ágeis
Scrum e Extreme Programming (XP), a mesma foi feita através de critérios de autores
referenciados no capítulo.
O capítulo 5 abordará conceitos de Engenharia Experimental, bem como os ob-
jetivos do experimento para o crescimento científico e os tipos de experimentos mais
utilizados.
O capítulo 6 apresentará os resultados obtidos mediante coleta de dados, através
de um questionário, foi possível aferir sobre a utilização das metodologias ágeis Scrum e
Extreme Programming tanto como seus benefícios, malefícios e caraterísticas específicas
que o grupo obteve sobre as metodologias ágeis.
O capítulo 7 abordará as conclusões que foram obtidas com a realização da mo-
nografia.
O capítulo 8 apresentará as referências bibliográficas que serviram de base para
realização deste trabalho científico.
17
2 O ESTADO DA ARTE
Neste capítulo serão exposto alguns trabalhos correlatos os quais têm estreita
relação com a presente investigação cientifíca.
2.1 SCRUM E XP: Um comparativo no processo de desenvolvimento de software
A revisão bibliográfica produzida por Fernandes (2011), foi realizada em relação
aos conceitos da Engenharia de Software, o presente trabalho apresenta um estudo sobre
diversos métodos tradicionais e duas metodologias ágeis, explicando seus principais con-
ceitos e processos adotados e realizando uma análise comparativa do Scrum e do Extreme
Programming na fase de implementação.
Como resultado da revisão bibliográfica estudos comprovam que é possível com-
binar praticas dessas metodologias ágeis e obter sucesso, Fernandes (2011) destaca que o
uso das metodologias devem ser escolhidas de acordo com o projeto que será implemen-
tado e que ambas as metodologias ágeis estudadas tendem a eliminar antigas práticas
provenientes das metodologias tradicionais.
O trabalho do Fernandes (2011), relaciona-se a este trabalho por ter abordado o
mesmo tema central, no caso, uma analise comparativa de modelos de processo de software
ágil Scrum e Extreme Programming. Assim o que os diferem é que o presente trabalho
tem como objetivo realizar uma análise comparativa de modelos de processos de software
na fase de implementação, com o objetivo de destacar a importância dessa etapa, cuja
revisão do autor é a fase a qual demanda mais tempo no processo e considerada de suma
importância.2.2 Analise Comparativa das Metodologias Ágeis: Scrum, XP e FDD
O artigo científico escrito por Paz, Duarte e Bigao (2017), foi realizado com o
objetivo de avaliar e comparar as similaridades assim como as diferenças nas metodolo-
gias ágeis Extreme Programming (XP), Scrum e Feature Driven Developent (FDD) para
auxiliar na escolha do método que melhor se adapte a realidade do desenvolvedor e sua
equipe. Para alcançar os resultados foi realizada uma pesquisa exploratória, descritiva,
comparativa e qualitativa.
Como resultado do artigo científico o autor não tem a intenção de dizer qual o
melhor método e sim apenas demonstrar através de um estudo científico a comparação
entre os mesmos. Segundo Paz, Duarte e Bigao (2017), as diferenças mais acentuadas
entre as metodologias são as inspeções de código em FDD, além desta possuir um foco
maior em documentação, a XP apresenta a escrita dos testes antes da implementação
Capítulo 2. O Estado da Arte 18
e a programação em pares demonstrando uma ênfase maior com a etapa de testes, no
entanto não existe a preocupação formal em fazer a análise dos riscos, já a Scrum com
suas reuniões diárias e revisões demonstram uma ênfase na agilidade.
O trabalho do Paz, Duarte e Bigao (2017), relaciona-se a este por ter abordado o
mesmo tema central, sendo uma análise comparativa de modelos de processo de software
ágil Scrum e XP. Entretanto, o que os difere é que o presente trabalho tem como objetivo
realizar uma análise comparativa entre três modelos de processos de software, acrescen-
tando outra metodologia na análise comparativa, a Feature Driven Developent (FDD), a
qual destaca e auxilia o desenvolvedor e a sua equipe na escolha do método que mais se
adapta para alcançar os objetivos no projeto.
2.3 Análise das Metodologias Ágeis XP e Scrum no Desenvolvimento de um Software de
Gerenciamento de Abastecimento
O artigo científico escrito por Vidor, Oliveira e Barbosa (2013), buscou analisar
como as metodologias ágeis XP e Scrum podem contribuir para o desenvolvimento de um
software que gerencie o abastecimento. O presente trabalho teve como objetivo específico
descrever a visão dos funcionários da empresa pesquisada sobre a adoção de um novo
método para o desenvolvimento do software. Para alcançar os resultados adotou-se uma
abordagem qualitativa dos dados, com pesquisa descritiva e pesquisa de campo.
O artigo científico demonstrou que os entrevistados tiveram uma boa adaptação
com o método implantado, alcançando assim os objetivos propostos. Os resultados apon-
taram que as metodologias ágeis contribuíram para o aumento do desempenho, produti-
vidade e redução de custo, além de aumentar a confiabilidade do cliente e o empenho dos
profissionais envolvidos no desenvolvimento.
O trabalho do Vidor, Oliveira e Barbosa (2013), relaciona-se a este trabalho por ter
abordado o mesmo tema central, sendo uma análise comparativa de modelos de processo
de software ágil Scrum e XP. Esse trabalho foi escolhido como referência de estudo, pois o
mesmo apresenta um estudo de campo com os funcionários da empresa, responsável pelo
desenvolvimento do software, sobre as metodologias ágeis utilizadas. O trabalho destaca
como os desenvolvedores lidaram com a metodologia implantada e como conseguiram
chegar nos objetivos propostos.
2.4 Métodos Ágeis
A revisão bibliográfica produzida por Libardi e Barbosa (2010) apresenta um es-
tudo sobre as metodologias ágeis de desenvolvimento, o presente trabalho é um breve
estudo das metodologias ágeis em geral e uma especificação detalhada dos papéis, regras
e práticas da metodologia Scrum e XP.
Capítulo 2. O Estado da Arte 19
Os estudos da revisão bibliográfica comprovaram que a metodologia ágil mostra
uma maneira de trabalhar bem organizada e interativa, podendo inclusive contribuir para
um ambiente de trabalho mais amigável, portanto é uma opção para se obter os diferencias
desejados. Ainda segundo Libardi e Barbosa (2010), no que diz respeito a análise compa-
rativa de métodos ágeis, pode-se concluir que há várias semelhanças entre si, entretanto,
algumas particularidades foram notadas pela dupla de programadores, com os user sto-
ries e a escrita dos testes antes da implementação no XP, com reuniões de planejamento
diárias e de revisão no SCRUM.
2.5 Comparação Entre os Processos dos Métodos Ágeis XP, Scrum e FDD e ASD em
Relação ao Desenvolvimento Iterativo Incremental
O artigo científico produzido por Fagundes, Deters e Santos (2008), apresenta uma
comparação entre os processos propostos pelos métodos ágeis XP, Scrum, FDD e ASD,
em que auxilia a equipe de desenvolvimento na escolha do método que melhor se adapta
a suas expectativas.
Como resultado do artigo científico os autores Fagundes, Deters e Santos (2008),
concluem que os métodos ágeis selecionados para fazerem parte deste estudo apresentam
atividades bastantes semelhantes em relação aos seus processos de desenvolvimento. Po-
rém algumas atividades apresentam particularidades, como por exemplo: a programação
em dupla, as user stories escritas pelos clientes e a escrita dos testes antes da implementa-
ção do XP; as reuniões de planejamento diárias e de revisão adotadas são peculiaridades
do Scrum.
O trabalho dos autores Fagundes, Deters e Santos (2008), relaciona- se a este por
ter abordado o mesmo tema central, no qual é feito uma análise comparativa de modelos
de processos de software ágil Scrum e XP. Já o que os difere é que o artigo científico
acrescenta duas metodologias FDD e ASD na análise comparativa, tendo como objetivo
auxiliar a equipe de desenvolvimento no melhor método que se adeque ao projeto.
2.6 Considerações finais
As investigações científicas citadas acima abordaram as diversas áreas da ciência
de Engenharia de Software, tendo como ênfase as metodologias de software ágeis. Através
dos autores citados acima, foi possível proporcionar uma visão atual das metodologias.
Através do estudo nas revisões bibliográficas, foi possível analisar que mesmo as
metodologias de processo de software ágil terem suas peculiaridades e diferenças, todas elas
destacam-se por criar software de qualidade e por eliminar antigas práticas provenientes
das metologias tradicionais.
20
3 ENGENHARIA DE SOFTWARE
Breve revisão bibliográfica sobre Engenharia de Software com ênfase em modelos
de processos de software ágil e tradicional
3.1 Conceito de Software
Segundo Pressman (2011), software consiste em instruções (programas
de computador) que, quando executadas, fornecem características, fun-
ções e desempenho desejados, estrutura de dados que possibilitam aos
programas manipular informações adequadamente e informação descri-
tiva, tanto na forma impressora como na virtual, descrevendo a operação
e o uso dos programas.
Para Sommerville (2011), o software não se trata apenas da parte lógica (programas
de computadores), mas de toda a documentação associada e as configurações necessárias
para que o sistema funcione corretamente.
Segundo Sommerville (2011), o mundo moderno não poderia existir sem o soft-
ware. As infraestruturas, serviços nacionais, manufaturas e distribuições industrias são
totalmente informatizadas e controladas por sistemas computacionais. Os software estão
presentes intensivamente nas várias áreas da sociedade, podendo citar também a área de
entretenimento, desde jogos, cinemas, televisão entre outros.
Conforme analisado, verificou-se o conceito de software e a importância do mesmo
na vida das pessoas. Portanto, o estudo da ciência de Engenharia de Software se torna
essencial para produzir softwares de qualidade. Os conceitos da ciência de Engenharia de
Software serão expostos no tópico a seguir.
3.2 Conceito de Engenharia de Software
Segundo Pressman (2011), "A engenharia de software é uma tecnologia em cama-
das". Conforme apresentado na Figura 1.
De acordo analisado na Figura 1 para que se desenvolva um software de qualidade
é preciso estar fundamentado em um comprometimento organizacional com particulari-
dades. Segundo Pressman (2011), "A pedra fundamentalque sustenta a engenharia de
software é o foco na qualidade".
O alicerce da Engenharia de Software é a camada de processos. Segundo Pressman
(2011), Os processos têm a função de manter as camadas de tecnologia consistentes,
possibilitando o desenvolvimento de forma organizada e dentro da meta. Para que o
software tenha qualidade são aplicados uma série de atividades no desenvolvimento.
Capítulo 3. Engenharia de Software 21
Figura 1 – Representa modelo tecnologia em camadas
Fonte:Pressman (2011, p.39)
Os métodos da Engenharia de Software são uma sequência de atividades e pas-
sos para obter um software de qualidade. A aplicação do mesmo é fundamental nesta
engenharia para atingir a qualidade do produto computacional, sendo este o seu foco
principal.
Segundo Pressman (2011), "a definição de métodos da Engenharia de Software é
uma ampla gama de tarefas, que incluem: comunicação, análise de requisitos, modelagem
de projeto, construção de programa, testes e suporte".
A camada de ferramentas de software fornecem suporte automatizado
ou semiautomizado para o processo e para os métodos. Quando as fer-
ramentas são integradas, de modo que as informações criadas por uma
ferramenta possam ser usadas por outra, é estabelecido um sistema para
o suporte ao desenvolvimento de software, denominado engenharia de
software com auxílio do computador. (PRESSMAN, 2011).
A camada de ferramentas tem o papel de auxiliar no cumprimento da ampla gama
de tarefas na construção de um software, auxiliando as equipes de suporte e desenvolvi-
mento na solução de problemas e obtenção de melhorias. São ferramentas que facilitam o
uso dos conceitos de Engenharia de Software.
3.3 Campos de aplicação do software
O fator mais significante em determinar quais técnicas e métodos de Engenharia de
Software são mais importantes é o tipo de aplicação a ser desenvolvida. Existem variados
tipos de aplicações.
3.3.1 Software de sistema
"Conjunto de programas feito para atender a outros programas"(PRESSMAN,
2011).
Capítulo 3. Engenharia de Software 22
São exemplos de sistemas operacionais (Microsoft Windows e Linux), exemplos de
softwares de sistema (compiladores, editores e utilitários de gerenciamento de arquivos),
IDE’s entre outros.
3.3.2 Software de aplicação
"Programas sob medida que solucionam uma necessidade específica de negócio"(PRESSMAN,
2011) . Esses softwares servem para facilitar as diversas operações no ramo do negócio,
facilitando o cotidiano do usuário.
São exemplos de sistemas desse campo de aplicação: os softwares de gerenciamento
hospitalar, sistemas de gerenciamento de hotelaria, sistemas contábeis entre outros. Pode-
se notar que esse tipo de sistema atende apenas o ramo proposto, não servindo para outros
tipos de negócios.
3.3.3 Software científico/engenharia
"Tem sido caracterizado por algoritmos ’number crunching’ (para processamento
numérico pesado)"(PRESSMAN, 2011). São softwares voltados para processamento de
complexos cálculos numéricos .
Exemplos de áreas onde são aplicados estes softwares: astronomia, biologia, física
e outras áreas científicas.
3.3.4 Software embutido
"Residente num produto ou sistema e utilizado para implementar e controlar carac-
terísticas e funções para o usuário final e para o próprio sistema"(PRESSMAN, 2011). Os
sistemas embarcados servem para controlar as funções do hardware de um equipamento.
São exemplos destes softwares: fornos micro-ondas, roteadores, impressoras entre
outros.
3.3.5 Software para linha de produtos
"Projetado para prover capacidade específica de utilização por muitos clientes
diferentes"(PRESSMAN, 2011). São softwares que fornecem funções genéricas que servem
para diferentes regras de negócio.
Um software de gestão empresarial que possui módulos básicos pode servir vários
nichos de mercado, um dos maiores exemplos que se adequa a essa área de aplicação é o
ERP (Enterprise Resource Program).
Capítulo 3. Engenharia de Software 23
3.3.6 Aplicações para a Web/Aplicações Móveis
"Chamadas de ’WebApps’, essa categoria de software centralizada em redes abarca
uma vasta gama de aplicações"(PRESSMAN, 2011). De acordo com a definição de Pres-
sman, estes são softwares com a finalidade de funcionamento em rede. As aplicações são
utilizadas tanto em navegadores quanto em dispositivos móveis.
São exemplos deste aplicativos: redes sociais, sites de notícias, whatsapp, twitter
entre outros.
3.3.7 Software de inteligência artificial
"Faz uso de algoritmos não numéricos para solucionar problemas complexos que
não são passíveis de computação ou de análise direta"(PRESSMAN, 2011). São softwares
similares a espécie humana exibida por mecanismo ou software, alguns exemplos são: a
robótica, sistemas especialistas, reconhecimento de padrões de imagem e de voz, redes
neurais artificiais, prova de teoremas e jogos.
3.4 Processo de software
Processo é um conjunto de atividades, ações e tarefas realizadas por pessoas, que
tem como objetivo em comum desenvolver um produto computacional e sua documenta-
ção. (PRESSMAN, 2011).
Segundo Jalote (2008), Projeto é um conjunto de atividades, ligadas
por padrões de relacionamento entre ela, pelas quais se as atividades
operarem corretamente e de acordo com os padrões requeridos, o resul-
tado desejado é produzido. O resultado desejado é um software de alta
qualidade e baixo custo. Obviamente , um processo que não aumenta
a produção (não suporta projetos de software grandes) ou não pode
produzir software com boa qualidade não é um processo adequado.
Segundo Pressman (2011), dentro dos projetos existem metodologias (framework)
que são responsáveis por estabelecer o alicerce para um processo de Engenharia de Soft-
ware. O alicerce é estabelecido através de atividades metodológicas aplicáveis a todos os
projetos de software, sendo elas: comunicação, planejamento, modelagem, construção e
entrega.
1. Comunicação: comunicação com os envolvidos na construção do projeto e com
o cliente. A intenção da comunicação é levantar os requisitos para construção de um
software que atenda o cliente com todos os recursos e funções necessárias.
2. Planejamento: a construção de um projeto de software é uma jornada complexa,
sabendo disso cria se um plano de projeto de software que tem por objetivo definir o
trabalho de Engenharia de Software, descrevendo as tarefas técnicas a serem conduzidas,
Capítulo 3. Engenharia de Software 24
os riscos prováveis, os recursos necessários, os produtos resultantes a serem produzidos e
um cronograma de trabalho.
3. Modelagem: cria se um modelo para entender melhor as necessidades do soft-
ware, os aspectos em termos de arquitetura, as caraterísticas do mesmo entre outros. O
objetivo é saber o plano de projeto que deve ser seguido para obtenção do software.
4. Construção: a codificação do projeto de software e testes no produto computa-
cional com a finalidade de revelar erros na codificação.
5. Entrega: o produto computacional é entregue completo ou parcialmente ao cli-
ente, o mesmo avalia o que foi entregue e fornece o feedback, baseado na avaliação.
As atividades de apoio servem para complementar as atividades metodológicas do
processo de Engenharia de Software, o papel das atividades de apoio é ajudar a equipe
de desenvolvimento a gerenciar e controlar o andamento do projeto (PRESSMAN, 2011).
1. Controle e acompanhamento do projeto: gerencia o progresso em relação ao
plano de projeto. Esta atividade tem como objetivo avaliar os resultados parciais do pro-
jeto, tomar medidas necessárias para cumprir o cronograma e resolver eventuais problemas
que podem ocorrer.
2. Administração de riscos: todo projeto está sujeito a falhas desde problemas
técnicos a recursos humanos. O objetivo da avaliação de riscos é criar rotinas que possam
amenizar possíveis problemas durante o projeto.
3. Garantia de qualidade de software: conduz o processo de construção de projeto
de software para se obter um produto de qualidade. As atividades são de verificação do
andamento do projeto e auditoria de qualidade domesmo.
4. Revisões técnicas: avaliam arterfatos de Engenharia de Software. O objetivo é
verificar erros nas atividades do projeto e eliminar antes que se propague para atividades
seguintes.
5. Medição: define e coleta medidas (do processo, do projeto e do produto). O
objetivo é avaliar a medição do andamento dos artefatos de Engenharia de Software e
com isso auxiliar na entrega do produto.
6. Gerenciamento da configuração do software: gerencia os efeitos das mudanças
ao longo do processo de um projeto de software. Qualquer alteração em um escopo de um
projeto deve ser avaliada e julgada verificando as vantagens e desvantagens da mudança.
7. Gerenciamento da capacidade de reutilização: define critérios para reutilização
de artefatos do projeto e estabelece formas para obtenção de componentes reutilizáveis
8. Preparo e produção de artefatos de software: define as atividades necessárias
para criar artefatos como, por exemplo, modelos, documentos, logs, formulários e listas.
Capítulo 3. Engenharia de Software 25
No processo de criação de um software os métodos que serão utilizados para criar artefatos
de qualidade é de suma importância.
Isto é, o projeto de software é muito importante dentro da ciência Engenharia
de Software, pois defini as ações e atividades a serem tomadas pela equipe responsável
pelo desenvolvimento do software com a finalidade de obter um produto de qualidade.
No processo de software utilizam se modelos destes, que são roteiros a serem seguidos na
elaboração de um produto computacional. Cada modelo de processo se encaixa em uma
regra de negócio distinto, os conceitos de modelos de processos serão expostos no tópico
a seguir.
3.5 Modelos de processo
O modelo de processo é o passo necessário para elaboração de um produto com-
putacional. Segundo Sommerville (2011), "modelo de processo de software é uma repre-
sentação simplificada de um processo de software".
Segundo Pressman (2011), "um modelo de processo fornece um guia específico
para o trabalho de Engenharia de Software. Ele define o fluxo de todas as atividades,
ações e tarefas, o grau de iteração, os artefatos e a organização do trabalho a ser feito".
Cada modelo de processo é uma representação de um processo de software para
atender as exigências da obtenção do produto computacional. Ou seja, cada processo de
software se aloca dentro de uma metodologia ou modelo.
O modelo de processo é de grande importância na ciência Engenharia de Software,
contribuindo para obtenção de desenvolvimento de software de qualidade. Pode-se obser-
var dois tipos de abordagens em relação aos modelos de processo: Tradicional e Ágeis, os
quais serão tratados no tópico a seguir.
3.5.1 Modelos Tradicionais
"Concentra-se em estruturar e ordenar o desenvolvimento de software. As ativida-
des e tarefas ocorrem sequencialmente, com diretrizes de progresso definidas"(PRESSMAN,
2011).
Segundo Soares (2004), "as metodologias tradicionais são conhecidas como ori-
entadas a documentação. Possuem como característica principal dividir os processos de
desenvolvimento em fases ou etapas definidas".
Os modelos tradicionais são caracterizados por serem realizados sequencialmente,
isto é, as etapas do desenvolvimento do produto computacional devem ser concluídas
integralmente para que possa migrar para outra tarefa.
Em processos de softwares que possuem requisitos bem definidos e estáveis, a
Capítulo 3. Engenharia de Software 26
utilização do modelo tradicional pode ser aplicada.
Observa-se que o modelo tradicional tem aplicabilidade no desenvolvimento de
software, no tópico a seguir serão explanados os modelos de processos tradicionais mais
conhecidos.
3.5.1.1 Modelo de Processo Sequencial Linear (Clássico ou Cascata)
Segundo Pressman (2011), O modelo cascata, algumas vezes chamado ci-
clo de vida clássico, sugere uma abordagem sequencial e sistemática para
o desenvolvimento de software, começando com o levantamento de ne-
cessidades por parte do cliente, avançando pelas fases do planejamento,
modelagem, construção, emprego e culminando no suporte contínuo do
software concluído. Representado na Figura 2
Figura 2 – Representa o modelo sequencial linear (Clássico ou Cascata
Fonte: Pressman (2011, p. 60)
O modelo cascata é o modelo mais antigo da Engenharia de Software e ainda
possui aplicabilidade na indústria, porém esse processo recebe muitas críticas que geraram
questionamentos sobre a sua eficácia.
Por ser um modelo linear as etapas do processo de software precisam estar bem de-
finidas, no modelo cascata as etapas do desenvolvimento do software devem ser concluídas
integralmente para que possam migrar para outra tarefa. Uma vez feito o levantamento
de requisitos no projeto inicial, não é permitido voltar o fluxo do processo para fazer
alterações.
O produto computacional só pode ser implantado para o cliente quando o software
estiver pronto integralmente, não permitindo uma versão parcial do sistema.
Devido o ritmo acelerado de trabalho e as mudanças constantes nos projetos,
o modelo cascata frequentemente se torna inadequado nestes casos. Entretanto, podem
servir em projetos nos quais os requisitos são fixos e bem definidos e a equipe de desen-
volvimento tem a possibilidade de finalizar uma tarefa integralmente e continuar para a
próxima (PRESSMAN, 2011).
Capítulo 3. Engenharia de Software 27
3.5.1.2 Modelo Protótipo / Prototipação
"Um protótipo é uma versão inicial de um sistema de software, usado para de-
monstrar conceitos, experimentar opções de projeto e descobrir mais sobre o problema e
suas possíveis soluções"(SOMMERVILLE, 2011).
Figura 3 – Representa o modelo de prototipação
Fonte: Sommerville (2011, p. 30)
O modelo de prototipação tem uma grande aplicabilidade para auxiliar usuários
quanto aos requisitos do sistema. Ao avaliar os requisitos junto ao cliente é criado um
projeto rápido que contém os requisitos solicitados pelo cliente. O mesmo avalia o pro-
tótipo e realiza um feedback sobre a avaliação. O ciclo é repetido até todos os requisitos
serem identificados. Não tendo mais requisitos a serem identificados o protótipo poderá
ser transformado no produto final, ou ser iniciado a construção do zero de um produto
final.
"Para reduzir os custos de prototipação e acelerar o cronograma de entrega, pode-
se deixar alguma funcionalidade fora do protótipo"(SOMMERVILLE, 2011). Por se tratar
de um protótipo, o gerenciamento e tratamentos de erros podem ser ignorados, o que pode
ser insuficiente para que o usuário teste um protótipo que atenda os requisitos propostos.
Outro grande problema com a prototipação é que o usuário pode utilizá-lo como
se fosse uma versão final do sistema. Sendo assim tende a solicitar alterações e ajustes no
funcionamento do mesmo para corrigir bugs e problemas de desempenho. Por se tratar de
um protótipo, o gerenciamento e tratamento de erros não foram feitos adequadamente, o
que ocasiona uma contradição entre a equipe de desenvolvimento e o usuário teste.
3.5.1.3 Modelo Espiral
"Modelo espiral é um modelo de processo de software evolucionário que une a
natureza interativa da prototipação com os aspectos sistemáticos e controlados do modelo
cascata"(PRESSMAN, 2011).
Capítulo 3. Engenharia de Software 28
Figura 4 – Representa o modelo espiral
Fonte: Pressman (2011, p. 65)
O modelo espiral se baseia em um ciclo espiral que é executado e interado até a
finalização da versão final do produto. A grande diferença da prototipação é que o modelo
espiral consiste em uma estratégia que tem como objetivo de forma incremental ampliar o
grau de definição e a implementação de um sistema, enquanto diminui os risco do mesmo.
O primeiro circuito em volta da espiral é para determinar os objetivos da interação,
do planejamento e do cronograma que será desenvolvido no processo. A modelagem é o
segundo circuito do modelo espiral, no qual é avaliado os riscos da interação e corrigidos os
problemas. A definição dos riscos depende de um profissional com uma grande capacidade
técnica, um risco não descobertopode causar problemas no andamento do projeto. O
terceiro circuito é definido como a construção do código do produto computacional. A
entrega e o feedback do cliente é feito no quarto circuito em volta do espiral, ao recebê-lo
é planejado tudo que será feito na próxima interação.
3.5.1.4 Modelo de Processo Incremental
"O desenvolvimento incremental é baseado na ideia de desenvolver uma imple-
mentação inicial, é necessário expor a mesma aos comentários dos usuários e conti-
nuar por meio da criação de várias versões até que um sistema adequado seja desen-
volvido"(SOMMERVILLE, 2011).
Cada incremento entregue ao cliente incorpora alguma funcionalidade de valor.
Os incrementos inicias são os que possuem as funcionalidades mais importantes ou ur-
gentes. Quando se entrega ao cliente, o mesmo pode avaliar e verificar se foi apresentado
o requisitado, diante disto, o processo é repetido até a finalização integral do sistema.
(SOMMERVILLE, 2011).
Capítulo 3. Engenharia de Software 29
Figura 5 – Representa o modelo incremental
Fonte: Sommerville (2011, p. 22)
Observa-se que o modelo de processo incremental surgiu como uma evolução do
modelo sequencial linear, afim de fornecer melhores práticas de desenvolvimento de soft-
ware de qualidade e com menor quantidade de tempo. Contudo, as práticas de desenvol-
vimento de software evoluíram, tornando-se o método obsoleto deixando de atender aos
requisitos de velocidade de desenvolvimento. O surgimento da metodologia de processos
ágeis tem como objetivo sanar esse problema. O conceito e exemplo serão expostos no
tópico a seguir.
3.5.2 Modelos Ágeis
Métodos ágeis, universalmente, baseiam-se em uma abordagem incre-
mental para a especificação, o desenvolvimento e a entrega do software.
Eles são mais adequados ao desenvolvimento de aplicativos nos quais os
requisitos de sistema mudam rapidamente durante o processo de desen-
volvimento. Destinam-se a entregar o software rapidamente aos clientes,
em funcionamento, e estes podem, em seguida, propor alterações e novos
requisitos a serem incluıdos nas iterações posteriores do sistema. Tem
como objetivo reduzira burocracia do processo, evitando qualquer tra-
balho de valor duvidoso de longo prazo e qualquer documentação que
provavelmente nunca sera usada (PRESSMAN, 2011).
"As técnicas de metodologias ágeis para desenvolvimento de sistemas são uma
resposta as metodologias tradicionais, também conhecidas como metodologias pesadas
ou orientadas a documentação"(BEEDLE, 2001). Mesmo com a evolução das técnicas,
ferramentas e dos computadores nos últimos anos, ainda era muito difícil entregar um
sistema de software de qualidade dentro dos prazos e custos estimados.
Segundo Sommerville (2011), o surgimento da metodologia ágil se idealizou através
da insatisfação com as abordagens das metodologias tracionais e com abordagens pesadas,
que tem como foco principal as documentações e regulamentações. Os requisitos cada vez
mais complexos e as constantes alterações nos projetos aumentaram o trabalho das equipes
Capítulo 3. Engenharia de Software 30
de desenvolvimento, contudo na década de 1990 foram propostos novos métodos ágeis de
desenvolvimento de software.
A seguir serão apresentados os modelos de processos ágeis utilizados para a com-
paração
3.5.2.1 Scrum
Segundo Schwaber e Sutherland (2013), scrum é um framework estrutu-
ral que está sendo usado para gerenciar o desenvolvimento de produtos
complexos desde o início de 1990. Scrum não é um processo ou uma téc-
nica para construir produtos; em vez disso, é um framework dentro do
qual você pode empregar vários processos ou técnicas. O Scrum deixa
claro a eficácia relativa das práticas de gerenciamento e desenvolvimento
de produtos, de modo que você possa melhorá-las.
Ainda segundo o mesmo autor, o principal objetivo do scrum é o desenvolvimento
de sistemas de software envolvendo uma porção de variáveis técnicas e de ambiente como:
requisitos, tecnologia e recursos, que podem mudar durante o processo. O foco desse
método é encontrar uma maneira dos membros da equipe trabalharem para produzir
o sistema de software de forma flexível e em um ambiente passível de sofrer constante
mudança. O resultado desse trabalho deve ser um sistema de software que será realmente
útil para o contratante.
Conforme apresentado por Schwaber (2004), o scrum é um modelo de desenvolvi-
mento ágil de sistema de software que permite manter o foco na entrega de maior valor de
negócio e no menor tempo possível. Com isso, permite-se a rápida e contínua inspeção do
sistema em produção em intervalos de duas a quatro semanas conhecidos como sprints.
Esse método é dividido sucintamente em três papéis:
a) Product Owner: dono do produto, é o representante de todos os envolvidos no
projeto, é o responsável por listar as prioridades e os requisitos. Juntamente com outros
envolvidos, ele é o responsável por revisar e aprovar as entregas ao final de cada sprint;
b) Scrum Master: é o gerente do projeto, responsável por garantir a aplicação das
práticas e valores do scrum, assim como repassar os ensinamentos do método aos outros
membros do projeto. As suas principais responsabilidades são remover os obstáculos,
conduzir o daily scrum, revisar cada sprint, intermediar a comunicação entre o time e o
product owner, entre outras;
c) Scrum Team: : correspondem aos membros encarregados de realizar as atividades
do projeto. Suas principais atividades são: organizar e gerenciar suas próprias atividades
e geralmente são dedicados integralmente ao projeto.
Segundo Pressman (2011), os princípios do scrum são consistentes com o ma-
nifesto ágil e são usados para orientar as atividades de desenvolvimento dentro de um
Capítulo 3. Engenharia de Software 31
processo que incorpora as seguintes atividades estruturais: requisitos, análise, projeto,
evolução e entrega. Em cada atividade metodológico ocorrem tarefas a serem realizadas
dentro de um padrão de processo chamado sprint.
Backlog: uma lista com prioridades dos requisitos ou funcionalidades do projeto
que fornecem um valor comercial ao cliente.
Sprints: unidades de trabalho solicitadas para atingir um requisito estabelecido do
backlog e que precisa ser ajustando dentro de uma janela de tempo (prazo) tipicamente
30 dias.
Backlog work itens: permite que os membros de uma equipe trabalhem em um
ambiente de curto prazo, porém estável.
Reuniões Scrum: são reuniões curtas, realizadas diariamente pela equipe scrum.
Demos: entrega do incremento de software ao cliente para que a funcionalidade
implementada possa ser demonstrada e avaliada pelo mesmo.
Figura 6 – Fluxo do Processo Scrum
Fonte: Pressman (2011, p. 96)
3.5.2.2 Extreme Programming
De acordo com Beck (2004), Extreme Programming foca no desenvol-
vimento rápido do sistema de software e procura garantir a satisfação
do contratante, além de ainda favorecer o cumprimento das estimativas.
Capítulo 3. Engenharia de Software 32
As práticas, valores e regras desse método proporcionam um ambiente
agradável de desenvolvimento de sistemas. Os princípios chaves e as prá-
ticas que compõem essa metodologia, não possuem nada de novo, quando
analisadas individualmente. Nesse método, essas típicas práticas das me-
todologias ágeis foram reunidas e alinhadas de tal forma que se criasse
uma independência entre elas e, assim, surgiu uma nova metodologia de
desenvolvimento de software. Os quatro valores que estabelecem as ba-
ses para todo trabalho realizado da XP são comunicação, simplicidade,
feedback e coragem.
Segundo Fernandes (2011) as definições são as listadas em seguir.
a) Comunicação: muitos problemas que ocorrem no decorrer do desenvolvimento
do sistema de software podem ser relacionados como falhas de comunicação entre a equipe
de desenvolvimento e o contratante ou entre a própria equipe de desenvolvimento. Um
indivíduo pode deixar de comunicar um fato importante a outra pessoa, um desenvolvedor
pode deixar de levantar uma questão importante à equipe ou ao próprio cliente. O Extreme
programmingmantém o fluxo de comunicação através da utilização de algumas práticas
que não podem ser desenvolvidas sem comunicação;
b) Simplicidade: selecionar a alternativa mais simples que tem a probabilidade de
funcionar. O Extreme programing baseia-se no fato de que é melhor fazer algo mais simples
e alterá-lo conforme as necessidades forem surgindo, do que tentar prever as possíveis
alterações futuras, trazendo uma complexidade que não será necessária no futuro;
c) Feedback: todos os problemas devem ser evidenciados o quanto antes, a fim de
serem corrigidos o mais rápido possível, para que possam ser incorporados de forma rápida
ao sistema de software que está sendo construído. Todas as necessidades são descobertas
o quanto antes;
d) Coragem: para apontar um problema no sistema de software, para simplificar
um código que já foi testado e aprovado, para solicitar ajuda quando for necessário, para
comunicar ao cliente possíveis alterações nos prazos estimados para entrega de versões e
também para realizar alterações no processo de desenvolvimento do sistema.
Junto desses quatro valores, segundo Sommerville (2011) também apresenta-se um
conjunto de regras e práticas constantes de quatro atividades metodologias sendo elas:
planejamento, projeto, codificação e testes.
Planejamento: atividade de levantamento de requisitos que capacita os membros
da equipe XP a entender o ambiente de negócios do software e possibilita ter uma com-
preensão ampla sobre os resultados solicitados.
Projeto: segue rigorosamente o princípio KIS (keep it simple, ou seja, preserve a
simplicidade). É melhor um projeto simples do que uma representação mais complexa. O
projeto oferece um guia de implementação para uma história de acordo com o crescimento
do projeto.
Capítulo 3. Engenharia de Software 33
Codificação: antes da codificação, a abordagem do XP desenvolverá uma série de
testes de unidades que exercitarão cada uma das histórias a serem inclusas na versão (in-
cremento de software). Se o código estiver completo poderá ser testado em unidade, a fim
de promover o feedback para os desenvolvedores. Um conceito importante na codificação
é a programação em par. A XP recomenda que duas pessoas trabalhem juntas para criar
um código para uma história. Isso fornece um mecanismo de resolução de problemas em
tempo real.
Testes: os testes de unidade devem ser criados e implementados usando-se uma me-
todologia que os capacitem de serem automatizados. Toda vez que o código for modificado
o mesmo será testado.
Figura 7 – Fluxo do Processo XP
Fonte: Pressman (2011, p. 88)
Segundo Fernandes (2011) Os papéis e responsabilidades do Extreme Programming
são os descritos a seguir:
a) Gestor: responsável pela tomada de decisões. O objetivo do gestor é manter a
comunicação com a equipe para ajustar as dificuldades ou problemas no projeto, além de
determinar qual a situação atual do mesmo.
b) Consultor: é um colaborador externo a equipe e possui conhecimento técnico
específico necessário ao projeto em questão.
c) Desenvolvedor:codifica programas, aplica testes e mantém o código o mais sim-
ples possível.
d) Cliente: é responsável por escrever as histórias e os testes dos requisitos funcio-
Capítulo 3. Engenharia de Software 34
nais, além de selecionar e validar os requisitos do sistema. É ele o responsável por definir
a prioridade de implementação para cada requisito.
e) Testador: é o pessoa responsável por auxiliar o cliente a escrever os testes dos
requisitos funcionais. Ele também executa os testes dos requisitos periodicamente e co-
munica o resultado dos mesmo para o restante da equipe.
f) Monitor: o monitor é responsável por acompanhar o progresso de cada interação
e é responsável por avaliar se o objetivo é viável de acordo com as limitações de recursos
e tempo. O monitor também é responsável pelas estimativas realizadas pela equipe de
desenvolvimento, além de verificar se alguma mudança pode ser necessária no processo.
g) Treinador: é o elemento responsável por garantir a integridade do processo
extreme programming como um todo.
Segundo Fernandes (2011) As doze práticas do Extreme Programming são as lis-
tadas a seguir
a) Padrão na codificação: os desenvolvedores devem escrever todo o código fonte
alinhado às regras que enfatizam a comunicação durante a codificação. Esse padrão é
definido antes de iniciar o projeto e deve ser seguido por toda a equipe de desenvolvimento.
b) Semanas de quarenta horas: o extreme programming possui uma regra que
limita em quarenta horas o tempo total de trabalho referente a semana e por colaborador.
c) Cliente no mesmo local da equipe: usuário que responde pelo cliente deve
integrar-se a equipe de desenvolvedores, com a finalidade de responder as dúvidas re-
ferentes ao projeto.
d) Integração contínua: são geradas versões internas e o sistema é integrado quantas
vezes forem preciso ao dia, após uma história ser finalizada.
e) Propriedade coletiva: os desenvolvedores da equipe possuem a permissão de
alterar qualquer parte do código fonte do projeto.
f) Programação em pares: dois desenvolvedores codificam o sistema em um mesmo
computador, com o objetivo de solucionar problemas com maior eficiência e aumentar a
qualidade do código fonte.
g) Jogo de planejamento: os desenvolvedores do sistema e o cliente definem juntos
o esforço para implementar as histórias e o tempo das interações.
h) Incrementos curtos: um incremento funcional e simples gerado com duração
máxima de dois meses.
i) Metáfora: nessa prática é elabora uma descrição que permite todos os envolvidos
no projeto explicarem como o sistema funciona.
j) Projeto simples: essa prática admite que o sistema deve ser projetado da forma
Capítulo 3. Engenharia de Software 35
mais simples possível, respeitando as necessidades atuais do mesmo. As complexidades
irrelevantes devem ser removidas quando descobertas.
k) Testes: os testes funcionais são escritos pelo cliente, enquanto que os testes de
unidade são escritos pela equipe do projeto e executados continuamente.
l) Reestruturação: consiste na melhoria contínua do sistema. São realizadas ativida-
des como remoção de códigos fontes duplicados, melhorias na comunicação, simplificações
no processo, aplicando práticas de clean code entre outras.
3.6 Considerações Finais
O capítulo apresentou os conceitos relativos a ciência, Engenharia de Software.
Foram abordados os conceitos de software, conceitos da Engenharia de Software, campos
de aplicação, processos de software e as metodologias de desenvolvimento tradicionais e
ágeis. Mediante o estudo da ciência, Engenharia de Software, pode-se notar a importância
da mesma para alcançar um nível de qualidade no processo de desenvolvimento.
Nesse contexto de desenvolvimento de software, no qual os sistemas estão cada vez
mais presentes na sociedade, e com grandes capacidades de processamento, a utilização
das técnicas da Engenharia de Software proporcionaram maior qualidade nos produtos
computacionais e auxílio para amenizar os problemas referentes ao projeto. Pode-se ob-
servar que a Engenharia de Software auxilia desde a escolha do campo de aplicação do
software quanto aos processos do mesmo que serão definidos junto a metodologia. Com a
utilização desses conceitos, consegue-se desenvolver um produto de qualidade.
No capítulo seguinte serão apresentados uma analise comparativa entre as meto-
dologias ágeis Scrum e Extreme Programming (XP).
36
4 ANALISE COMPARATIVA
Este capítulo apresenta a comparação das duas metodologias ágeis que foram es-
colhidas : Scrum e Extreme Programming (XP) estas foram comparados por meio de
critérios referenciados nos autores Pressman (2011) e Sommerville (2011).
4.1 Comparação Scrum e Extreme Programming (XP)
Na tabela 1 podemos observar uma análise comparativa entre os modelos Scrum
e Extreme Programming (XP).
Conforme apresentado na tabela , o modelo Scrum é o modelo que atende 62,5 %
dos critérios identificados para comparação. O modelo que segue uma metodologia onde
o seu planejamento é realizadode forma interativa entre desenvolvedores e cliente. Todos
os requisitos identificados ao desenvolvimento do software são planejados em um quadro
de tarefas que deverão ser realizadas no tempo de ciclo do desenvolvimento. Todos os dias
são realizadas reuniões, nas quais são discutido o que foi desenvolvido no dia anterior e o
que será desenvolvido no dia seguinte.
O modelo Extreme Programming – XP atende 62,5 % dos critérios identificados
para a comparação. Este modelo segue como metodologia um planejamento interativo
entre desenvolvedores e cliente, também são realizados testes de unidade sempre antes do
desenvolvimento do software, junto com os testes, há também a programação em par, a xp
recomenda que duas pessoas trabalhem juntos na codificação, isso fornece um mecanismo
para resolução de problemas. O modelo tem um conjunto de valores para ser seguido, a
finalidade de trazer bem estar para equipe, sendo um diferencial desse modelo.
Tabela 1 – Experimento - Análise Comparativa
Tabela Análise Comparativa Modelos de Processos Ágeis
Critérios Scrum XP
Conjunto de Valores X
Reuniões Diárias X
Planejamento Interativo X X
Quadro de tarefa X
Programação em Par X
Templo de Ciclo X
Teste Unitário X
Participação do Cliente X X
Fonte: Do autor
Capítulo 4. Analise Comparativa 37
4.2 Considerações Finais
Por meio dos resultados obtidos na análise comparativa entre os modelos de pro-
cessos de software ágeis, conclui-se que os dois resultam em um produto de software de
qualidade, a escolha de um ou de outro irá depender inteiramente de qual se adequará
melhor ao projeto.
Apesar das peculiaridades citadas em ambas as metodologias ágeis estudadas, as
duas tendem a eliminar antigas práticas, provenientes das metodologias tradicionais.
38
5 ENGENHARIA EXPERIMENTAL
O capítulo apresenta uma introdução a Engenharia Experimental, tendo como
finalidade expor os objetivos da experimentação e os tipos mais utilizados.
5.1 Conceito
Travassos, Gurov e Amaral (2002) "experimentação é o centro do processo cientí-
fico, somente experimentos verificam as teorias". Através dos experimentos os elementos
são explorados com a finalidade de formular novas teorias ou corrigir as existentes.
No entendimento do autor as atividades de Engenharia de Experimentação ofe-
recem um modo sistemático, disciplinado, computável e controlado para avaliação da
atividade humana em uma área do conhecimento.
Ao abordar a Engenharia de Software o autor considera tanto como ciência ou
engenharia. A Engenharia de Software está voltada a produção deste, tendo como base
caraterísticas de produção ou engenharia. Em contrapartida os aspectos de definições
e conceitos para a produção de um novo produto e a competição no mercado, exigem
melhoria continua de qualidade, tanto no processo quanto no produto. É neste contexto
que a parte científica da Engenharia de Software se apresenta.
Para proceder a experimentação existem quatro métodos relevantes para condução
do mesmo em engenharia de software, sendo eles: científico, engenharia, experimental e
analítico. As metodologias são necessárias para estabelecerem uma base de engenharia e
ciência na Engenharia de Software, em seguida pode-se verificar a definição dos autores
para cada método.
∙ Travassos, Gurov e Amaral (2002) "Método científico observa o mundo, sugere o
modelo ou a teoria de comportamento, mede e analisa, verifica as hipóteses do
modelo ou da teoria."
∙ Travassos, Gurov e Amaral (2002) "Método de engenharia observa as soluções exis-
tentes, sugere as soluções mais adequadas, desenvolve, mede e analisa, e repete até
que nenhuma melhoria adicional seja possível".
∙ Travassos, Gurov e Amaral (2002) "Método experimental sugere o modelo, desen-
volve o método qualitativo e/ou quantitativo, aplica um experimento, mede e ana-
lisa, avalia o modelo e repete o processo".
Capítulo 5. Engenharia Experimental 39
∙ Travassos, Gurov e Amaral (2002) "Método analítico (ou matemático) sugere uma
teoria formal, desenvolve a teoria, deriva os resultados e se possível, comparar com
as observações empíricas".
Assim sendo, a Engenharia de Software por estabelecer uma base de engenharia e
ciência, utiliza métodos de experimentação, com o objetivo de formular novas teorias ou
corrigir as existentes.
5.2 Objetivos da Experimentação
Segundo Travassos, Gurov e Amaral (2002) "os objetivos relacionados à execu-
ção de experimentos em Engenharia de Software são a caraterização, avaliação, previsão,
controle e melhoria a respeito de produtos, processos, recursos, modelos, teorias entre
outros".
Pode-se notar que Conradi (2001) tem algumas definições de objetivos da experi-
mentação em Engenharia de Software
∙ Observar o fenômeno, encontrar explicação, formular teorias são passos que pesqui-
sadores devem fazer para compreender a informação;
∙ Auxiliar no conhecimento confiável e reduzir incerteza sobre quais teorias são ade-
quadas;
∙ Mediante a experimentação pode-se eliminar abordagens inadequadas e suposições
erradas;
∙ As dúvidas podem ser rejeitadas mais rapidamente com o crescimento dos traba-
lhos científicos e com uma validação empírica, com isso pesquisadores poderão se
concentrar nas abordagens promissoras;
∙ Antecipar as mudanças nas suposições e aplicar experimentos para explorar as con-
sequências dessas mudanças.
Assim sendo, constata-se que os objetivos da experimentação é encontrar as me-
lhores técnicas para serem aplicadas na Engenharia de Software. No tópico a seguir serão
expostos alguns tipos de experimentos conhecidos.
5.3 Tipos de Experimentos
Segundo Conradi (2001) "O tipo de experimento mais apropriado em uma situação
concreta vai depender, por exemplo, dos objetivos do estudo, das propriedades do processo
de softwares usado durante a experimentação, ou dos resultados finais esperados".
Capítulo 5. Engenharia Experimental 40
A classificação dos experimentos está relacionada aos conceitos das estratégias
empíricas, sendo: survey, estudo de caso e experimento.
5.3.1 Survey
Freitas et al. (1998) "A pesquisa survey pode ser descrita como a obtenção de
dados ou informações sobre características, ações ou opiniões de determinado grupo de
pessoas, indicado como representante de uma população alvo, por meio de um instrumento
de pesquisa, normalmente um questionário."
Isto é, o modelo de experimento é utilizado para analisar fatos, hipóteses e teorias
através de determinado grupo. A pesquisa survey tem capacidade de levantar grande
número de variáveis para serem avaliadas, entretanto não oferece controle ou medição das
mesmas, não tendo respostas prontas, apenas dados que expressam a realidade do objeto
de estudo.
Pinsonneault e Kraemer (1993) classificam a pesquisa survey com três propósitos
principais
∙ Explanatória: O objetivo é aferir uma teoria e as relações casuais.
∙ Exploratória: O objetivo é familiarizar com o tópico ou identificar conceitos inicias
sobre ele.
∙ Descritiva: O objetivo é identificar situações, eventos, atitudes ou opiniões de um
determinado grupo.
Em relação ao tempo que os dados são coletados Sampieri (1991) cita que a pes-
quisa pode ser classificada como longitudinal ou cortetransversal.
∙ Longitudinal - a coleta dos dados ocorre durante um percurso de tempo ou em
períodos específicos. O objetivo é estudar as mudanças e evoluções de determinadas
variáveis ou a relação entre elas.
∙ Cortetransversal - a coleta de dados ocorre em apenas um momento, com a finalidade
de analisar e descrever o estado de uma variável em um determinado tempo.
Isto é, a pesquisa de survey é um método que pode ser aplicado em diversos expe-
rimentos, o qual tem como objetivo avaliar uma teoria ou as causas de um determinado
grupo de pessoas. A utilização das técnicas se torna um importante instrumento para a
análise em Engenharia de Software.
Capítulo 5. Engenharia Experimental 41
5.3.2 Estudo de Caso
Segundo Travassos, Gurov e Amaral (2002), "estudo de caso é utilizado para mo-
nitor os projetos, atividades e atribuições. Os estudos de caso visamobservar um atributo
específico e estabelecer o relacionamento entre atributos diferentes."
Para Freitas e Jabbour (2001), o estudo de caso deve ser iniciado com a definição do
objetivo e da abordagem, no qual o autor cita três, sendo estas: as abordagens qualitativas,
quantitativas ou a combinação destas. Definido as abordagens e o objetivo de estudo de
caso é feito a classificação da pesquisa social as quais são dividas em três grupos de
estudos: estudos exploratórios, estudos descritivos e estudos explicativos.
∙ Estudos exploratórios - são estudos que busca descobrir ideias e soluções, para que
tenha uma compreensão melhor do fenômeno de estudo.
∙ Estudos descritivos - são estudos que expõe caraterísticas de determinada população
ou de determino fenômeno de estudo.
∙ Estudo Explicativos - são estudos que buscam explicar a razão dos acontecimentos,
identificar os fatores que contribuem para ocorrência do fenômeno de estudo.
Sabendo a definição dos grupos de estudos da pesquisa, é necessário adotar o tipo
de abordagem mais favorável para atingir os objetivos da investigação. Ao se tratar de
uma investigação descritiva é utilizado uma abordagem de estudo de caso quantitativa,
quando a finalidade é descritiva ou explicativa se utiliza da abordagem qualitativa.
Conforme Freitas e Jabbour (2001), o propósito de um estudo de caso é reunir
informações detalhadas e sistemáticas sobre um fenômeno de estudo.
Para K.Yin (2001), o estudo de caso é apenas uma das muitas maneiras de se fazer
uma pesquisa em ciências sociais.
Portanto, os estudos de caso representam uma estratégia preferida em que o pesqui-
sador tem pouco controle sobre as variáveis, e o foco está em fenômenos que se encontram
em algum contexto da vida real.
5.3.3 Experimento
Segundo Travassos, Gurov e Amaral (2002) "experimento geralmente é realizado
em laboratório e oferece o maior nível de controle".
Ainda segundo o autor, o objetivo dos experimentos é manipular variáveis e manter
outras fixas medindo o efeito do resultado. São utilizados para confirmar teorias, explorar
relacionamentos, avaliar a previsão dos modelos ou validar medidas.
Capítulo 5. Engenharia Experimental 42
De acordo o Travassos, Gurov e Amaral (2002) os experimentos podem ser feitos
invitro sob condições de laboratório ou invivo sob condições normais.
Portanto, por ser um dos conceitos que utilizam um maior nível de controle so-
bre o processo e variáveis, os cientistas têm um melhor resultado e uma pesquisa mais
estruturada e organizada.
5.4 Considerações Finais
Por meio do estudo realizado sobre Engenharia de Experimentação foi possível
analisar a grande relevância que tem esse campo de estudo nas pesquisas científicas.
Uma pesquisa cientifica é formada por hipóteses e teorias. Ao definir uma abordagem de
pesquisa científica os pesquisadores tem a eficácia de formular novas teorias ou corrigir as
existentes. No que tange esse trabalho pode-se destacar as seguintes abordagens, sendo
elas: (1) Método Científico, (2) Método de Engenharia e (3) Método Experimental. A
abordagem sendo definida é preciso escolher o tipo de experimento que mais se adequa a
este trabalho, pode-se destacar três: (1) Survey, (2) Estudo de Caso e (3) Experimento.
Através do estudo foi possível identificar que a abordagem utilizada para a con-
dução desta pesquisa cientifica foi o método experimental, e o tipo de experimento que
mais se enquadra nessa pesquisa é Survey, em que obtém dados ou informações sobre
caraterísticas de um determinado grupo sobre alguns assuntos.
43
6 EXPERIMENTO
Este capítulo descreve o experimento científico que foi desenvolvido com a finali-
dade de realizar uma análise quantitativa e qualitativa sobre as metodologias de software
ágil Scrum e Extreme Programming (XP) propostas nesta monografia. Através da análise
foram obtidos os dados os quais serão expostos no decorrer do capítulo.
6.1 Descrição do contexto e objetivos do experimento
Para a condução do experimento científico foi desenvolvido um questionário e
enviado para desenvolvedores de software, para serem avaliadas as informações sobre os
atributos analisados.
As questões enviadas para os desenvolvedores estão organizadas abaixo:
Para a condução do experimento foram elaboradas quatorze (14) questões relaci-
onadas aos Modelos de Processos Ágeis descrito no capítulo 3.4.3, 3.4.3.1 e 3.4.3.2.
∙ As questões 1,2,3 e 4 avaliam os voluntários que responderão o questionário, para
conhecer as características dos mesmos.
∙ As questões 5,6 e 7 avaliam e compreendem a utilização e o conhecimento dos
voluntários em modelos de processos de software ágil expostos no capítulo 3.4.3,
3.4.3.1 e 3.4.3.2.
∙ As questões 8,9,10,11,12 e 13 buscam identificar os benefícios, malefícios e carate-
rísticas específicas que o grupo obteve com o uso das metodologias.
O questionário foi conduzido através da plataforma Google Forms, que consiste
em uma ferramenta de pesquisa a qual fornece, dentre outros, mecanismos para coletas
das respostas e gráficos estatísticos.
Para o envio do questionário foi utilizada a plataforma Linkedin, com uma mensa-
gem de apresentação padrão, em que as respostas foram recebidas entre os dias 02/10/2018
e 09/10/2018. Os resultados obtidos através do experimento estão expostos no tópico a
seguir.
6.2 Resultados do Experimento
O subcapítulo apresenta os resultados do experimento que foram obtidos através
do questionário enviado aos voluntários.
Capítulo 6. Experimento 44
6.2.1 Caraterização e Nível de Escolaridade do Grupo
Para a realização do experimento foram encaminhadas 112 mensagens via plata-
forma Linkedin.
6.2.2 Primeira Pergunta
A figura 8 representa a primeira pergunta do questionário, o asterisco simboliza o
preenchimento obrigatório.
Figura 8 – Primeira Pergunta
Fonte: Do autor
A pergunta serviu para identificar os voluntários participantes do questionário.
Todos os voluntários foram essenciais para os resultados obtidos na pesquisa.
6.2.3 Segunda Pergunta
A figura 9 representa a segunda pergunta do questionário, o asterisco simboliza o
preenchimento obrigatório.
Figura 9 – Segunda Pergunta
Fonte: Do autor
Esta pergunta serviu para identificar a empresa que o voluntário trabalha.
6.2.4 Terceira Pergunta
A figura 10 representa a terceira pergunta do questionário, o asterisco simboliza o
preenchimento obrigatório.
Identificado a locação profissional, esta pergunta tem como objetivo saber o cargo
ocupado pelo voluntário na empresa.
Capítulo 6. Experimento 45
Figura 10 – Terceira Pergunta
Fonte: Do autor
6.2.5 Quarta Pergunta
A figura 11 representa a quarta pergunta do questionário, o asterisco simboliza o
preenchimento obrigatório.
Figura 11 – Quarta Pergunta
Fonte: Do autor
Esta pergunta tem como objetivo saber o grau de escolaridade dos voluntários da
pesquisa.
Dos 48 avaliados, 12,5% são graduandos, 47,9% são graduados, 35,4% são especia-
listas, 4,2% são mestres. Por se tratar de um questionário proposto para desenvolvedores
de software, em que a formação é designada para o mercado de trabalho, não foram ob-
tidas respostas de mestrandos, doutorandos e doutores que são titulações voltados para
área acadêmica. Estes dados estão dispostos na forma de gráfico na figura 12.
Capítulo 6. Experimento 46
Figura 12 – Experimento - Gráfico 1 - Titulação dos Voluntários
Fonte: Do autor
Nas perguntas de avaliação existe uma descrição referente aos dados obtidos das
respostas dos voluntários. Na tabela 2 pode-se observar de forma geral os dados referentes
as questões 1,2,3 e 4.
Após expostas as respostas das perguntas referentes a avaliação dos voluntários,
serão apresentadas as perguntas específicas pertinentes a utilização e compreensão do
grupo em modelos de processos de software ágeis.
6.2.6 Identificação de Compreensão e Usabilidade em Modelos de Processos Ágeis
6.2.7 Quinta Pergunta
A figura 13 representa a quinta pergunta do questionário, o asterisco simboliza o
preenchimento obrigatório.
Figura 13 – Quinta Pergunta
Fonte: Do autor