software em desenvolvimento : Software, Métodos Ágeis, Teste. · ... Extreme Programming, ... melhores práticas para o desenvolvimento de um software. ... que rege os princípios

Utilização de Agile e Testes de Software: uma abordagem sobre a melhoria da

produção de software com redução de custos

Using Agile and Software Testing: an approach about to improving software

production with cost reduction

Augusto Nogueira Zadra1

Deivid Edson Andrade Vilela2

Rudger Marcellos Reis Dias Freitas3

Resumo: Este artigo tem como por objetivo fazer um contraponto entre as metodologias ágeis e a importância de se testar um software em desenvolvimento buscando a máxima qualidade e o menor custo, em busca de uma base conceitual e teórica realizou-se a pesquisa do tipo exploratória.

Palavras-chave: Software, Métodos Ágeis, Teste.

Abstract: This article aims to make a counterpoint between agile methodologies and the importance of testing a software in development seeking a maximum quality and lower cost, in search of a conceptual and theoretical basis when there was a research of the exploratory type.

Keywords: Software, Agile Methodology, Test.

1Mestre em Tecnologia da Informação Aplicada à Biologia Computacional. Professor na Faculdade

Infórium de Tecnologia.

2Graduando em sistemas de informação na Faculdade Infórium de Tecnologia..

3Graduando em sistemas de informação na Faculdade Infórium de Tecnologia..

1 INTRODUÇÃO

Historicamente a fabricação de software apresenta alguns percalços: a

qualidade se opõe ao prazo, a burocracia se opõe ao desejo do cliente. Contudo,

espera-se que os desenvolvedores consigam fazer softwares de qualidade com

prazos cada vez menores observando as boas praticas e buscando o menor custo

possível; diante disso, devemos considerar as metodologias ágeis, os modelos de

teste, sem deixar que o orçamento extrapole.

Sabemos que todas as ciências são passíveis de falhas, e o mesmo ocorre

com os sistemas e softwares desenvolvidos pelos programadores. Grandes foram as

evoluções no âmbito da criação de software, mas ainda há muito o que ser

feito.Schach (2009, p. 04) diz que “é fato que os geradores de energia elétrica

falham, porém com uma frequência muito menor que a dos programas de folha de

pagamento. As pontes de vez em quando caem, mas com frequência

consideravelmente menor que os sistemas operacionais”.Schach (2009) lembra

ainda que a OTAN, em 1967, cunhou o termo “Engenharia de Software” equiparando

assim a ato de se construir um software com a construção de um projeto de

engenharia civil, mecânica e etc. Foi com base nessa alegação que em 1976, na

Conferencia de Engenharia de Software da OTAN, realizada em Garmisch na

Alemanha, os conferencistas (Naur, Randell e Buxton) concluíram que a engenharia

de software deveria usar as filosofias e os paradigmas das disciplinas de engenharia

já estabelecidas para resolver o que eles denominaram crise de software. (SCHACH,

2009)

Mesmo com as boas práticas já bem estabelecidas, diversos projetos ainda

são entregues fora dos prazos, com erros, com orçamentos estourados ou até

mesmo são abortados ou, em outras palavras, cancelados, causando, assim, um

grande prejuízo financeiro para as software house.

Para mitigar um problema, um defeito, uma falha, os softwares devem ser

testados. Inicialmente, acreditava-se que os próprios programadores seriam as

pessoas mais indicadas para fazerem essa tarefa, que eram os recursos que

possuíam um conhecimento afundo da matéria, linguagem de programação. Com o

passar do tempo, essa prática caiu em desuso e passou a ser vista como uma má

pratica desenvolvimento, tendo em vista que, ao disponibilizar o produto final para o

cliente, era possível detectar diversas falhas em um software já finalizado.

Bartié(2002, p. 3) lembra que “nos primórdios do desenvolvimento de software, a

atividade de teste era encarada como a simples tarefa de navegar pelo código e

corrigir problemas já conhecidos. Tais tarefas eram realizadas pelos próprios

desenvolvedores, não existindo recursos dedicados a essa atividade”, Bartié (2002,

p. 4) cita ainda que “Em 1957, o conceito Teste de Software conseguiu ampliar seus

valores e se tornou um processo de detecção de erros de software, mas testar ainda

era encarado como uma atividade que ocorria no final do processo de

desenvolvimento.”, com o conceito de engenharia de software é que o teste passou

a ter uma abordagem mais profunda.

Em meados da década de 1980, com o surgimento dos padrões sugeridos por

grandes instituições, como Institute of Eletrical and Eletronics Engineers (IEEE),

American Nacional Standart Institutes (ANST), International Stantards Organization

(ISO) e Compability Maturity Model (CMM) é que o conceito de qualidade de

software foi criado, e os modelos de padrões visavam garantir a qualidade do

produto final, a fim de se mitigar os riscos de futuras falhas, retrabalhos e perdas

financeiras.

Visando a economizar tempo e diminuir custos, empresas de

desenvolvimento de software tendem a ignorar a engenharia de software e seus

processos. Engholm (2013, p. 30) afirma que “...essa ideia é falsa, pois a não

utilização dos métodos adequados no desenvolvimento gera softwares de má

qualidade, que trazem frustação aos usuários, custos adicionais relacionados a

manutenção corretiva e problemas na utilização dos sistema”; cita, ainda, uma

armadilha associada a não utilização da engenharia de software onde é apresentado

um cenário no qual você é precisa dar manutenção em software muito complexo,

qual você não possui nenhuma documentação para consulta, software esse que

você não participou da construção e que um determinado erro precisa ser resolvido

com urgência, Enghom (2013) cita que em média se gasta cerca de 50% dos

esforço profissional para entender o código.

Gomes (2013, p. 68) questiona:

O que é mais barato: descobrir que uma alteração em uma parte do software

criou um defeito em outra através do feedback de um testes de unidade

durante o desenvolvimento e então resolver o problema na mesma hora,

enquanto ainda se está com as regras de negócio em mente; ou descobrir

posteriormente que o defeito existe porque não passou pela qualidade ou,

ainda pior, descobrir que o problema existe apenas quando o software já

estiver em produção?

2 METODOLOGIAS AGILE

Com intuito de desburocratizar os processos que envolviam a construção de

um software o movimento Agile surgiu na década de 90 com o nascimento de

algumas metodologias, tais como Scrum, Extreme Programming, dentre outras

buscando melhorarias no tempo de concepção de um software e consequentemente

uma melhoria nos custos.

Um grande marco se deu em 2001. Gomes (2013) lembra que em 2001

houve uma conferência entre 17 grandes nomes ligados ao desenvolvimento de

software da época, Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn,

Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,

Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber,

Jeff Sutherland e Dave Thomas. A reunião desse grupo teve como intuito discutir as

melhores práticas para o desenvolvimento de um software. Desse encontro se

originou “O Manifesto Ágil, que rege os princípios do desenvolvimento ágil.

O manifesto busca a valorização dosindivíduos e interações mais que os

processos e ferramentas, software em funcionamento mais do que documentação

abrangente, colaboração com o cliente mais que negociação contratual, responder a

mudanças mais que seguir um plano (GOMES, 2013). Com base nesses valores

foramconstituídos os 12 princípios da metodologia ágil:

- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

- Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

- Software funcional é a medida primária de progresso.

- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

- Contínua atenção a excelência técnica e bom design, aumenta a agilidade.

- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

- As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.

- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.(GOMES, 2013, p. 3)

Os métodos ágeis geralmente possuem ciclos curtos devido à imprevisibilidade e,

uma vez que o próprio cliente pode não saber de fato o quer, os ciclos

tambémconhecidos como interações e normalmente duram poucas semanas,

sempre fazendo rodadas de feedbacks visando melhorar o tempo de respostas a

mudanças (GOMES, 2013).

Ao contrário dos métodos tradicionais, o ágil busca fazer com início meio e fim

em cada interação abordando o planejamento, análise, design, codificação, testes e

documentação. Já no método tradicional essas etapas são cumpridas em cascata,

cada uma é finalizada para se dá início a outra.

“O processo cascata costuma ser realizado através de fases de análise de

requisitos, projeto (design), implementação, testes, integração e manutenção, de

forma que uma fase é iniciada somente quando a anterior termina”. (GOMES, 2013,

p. 5)

O termo cascata existe desde 1970, foi criado pelo Wiston W. Royce, o modelo

segue um formato conforme Figura 1.

Figura 1 – Desenvolvimento de software em cascata (Waterfall)

Fonte: GOMES, 2013, p.6

Fazendo uma comparação entre os métodos prescritivos e métodos

adaptativos, no qual os adaptativos possuem uma ampla vantagem devido a sua

aderência e flexibilidade, métodos adaptativos possuem melhor adaptação a

projetos distintos. Com comparação temos RUP que possui mais que 120

prescrições enquanto o XP possui 13,Scrum possui somente 9 e o Kanban 3.

“Quanto mais prescritivo um método for, mais específico para um determinado tipo

de contexto ele será” (GOMES, 2013, p.8).

A utilização dos métodos ágeis trazem diversas vantagens, a principal está

relacionada ao valor que é agregado ao cliente com um índice de assertividade

maior e um ganho substancial no quesito tempo. Gomes (2013) cita uma pesquisa

realizada em 2011 pela VersionOne.com, no qual 6.000 pessoas e organizações

foram submetidas. Essa pesquisa teve o intuito de mostra os principais benefícios da

utilização dos métodos ágeis após a mudança do modelo tradicional para o ágil.

Os principais benefícios são:

- Melhor Time-to-market e Maior Retorno sobre o Investimento: Quanto mais cedo

os clientes puderem começar a utilizar o produto, mais rápido receberá o retorno

do valor investido no desenvolvimento do produto, seja através de lucros diretos

gerados pelo produto ou através dos benefícios gerados pela utilização do

produto na organização.

- Maior Satisfação do Cliente e Melhor Gestão de Mudanças de Prioridades: O

planejamento iterativo permite que o cliente facilmente mude suas prioridades

com impacto reduzido na produtividade da equipe porque planeja-se

detalhamento apenas daquilo que está mais próximo de ser feito, evitando

também desperdícios e custos desnecessários. A comunicação constante e a

proximidade com o cliente frequentemente resulta também em um melhor

alinhamento entre os objetivos de TI e com os objetivos de negócio da

organização.

- Melhor Visibilidade dos Projetos: Faz parte da cultura ágil manter as

informações do projeto visíveis e transparentes através de ferramentas como

burndown-charts, e card walls (discutidas posteriormente), com as quais a equipe

e gestão podem acompanhar dia a dia a evolução do projeto em relação às metas

do projeto e das iterações.

- Maior Produtividade: Infelizmente, não há uma forma universalmente aceita de

se medir produtividade de equipes de desenvolvimento de software. Muitos

consideram essa tarefa até impossível ou algo subjetivo demais, mas na pesquisa

supracitada, 75% dos participantes afirmaram ter alcançado melhor produtividade

depois da transição para métodos ágeis.

- Equipes mais Motivadas: Métodos ágeis promovem ritmos sustentáveis de

trabalho, são muitos os casos em que organizações reportaram uma diminuição

significativa nas horas extras e madrugadas trabalhadas depois da transição para

métodos ágeis. A promoção do ritmo sustentável, de uma cultura de qualidade,

de constante comunicação e trabalho em equipe são alguns dos fatores que

contribuem para equipes mais motivadas e satisfeitas com seu ambiente de

trabalho.

- Melhor Disciplina na Engenharia e Melhor Qualidade Interna: A utilização de

práticas ágeis como redução de dívida técnica (melhorar a qualidade interna do

produto), refactoring, desenvolvimento orientado a testes e programação em par,

unido ao mindset de qualidade estimulado de pelos métodos ágeis, contribuem

para a entrega de produtos com melhor mantenabilidade, extensibilidade e com

menos defeitos.

- Processo de Desenvolvimento Simplificado: Os método ágeis são, em regra

geral, menos prescritivos do que os métodos tradicionais, definem menos papéis

e menos artefatos. São mais facilmente compreendidos pela equipe, e oferecem

maior margem para otimização e adaptação para a maior eficiência no contexto

da organização em que está sendo aplicado.

- Redução deRisco: Oplanejamento iterativo e as releases frequentes permitem

que as prioridades do projeto sejam reajustadas constantemente.Métodos ágeis

possibilitam que as incertezas do projeto, no nível dos requisitos, ou no nível

técnico, sejam estimadas e distribuídas de forma inteligente nos releases, para

manter o risco sempre balanceado. Além disso, as entregas em prazos curtos

oferecem maior visibilidade da velocidade do time, oferecendo maior

previsibilidade do prazo necessário para concluir o projeto.

- Redução de Custos: Equipes ágeis são menos propensas a desenvolver

funcionalidades de baixa prioridade ou que se tornaram desnecessárias ao longo

do tempo. Abordagens não ágeis geralmente tendem a cair nesse problema

devido ao grande espaço de tempo entre o levantamento dos requisitos e entrega

do produto. (GOMES, 2013, p. 10)

Principais Métodos Ágeis e seus benefícios

Extreme Programming – XP

O conceito Extreme Programming foi inicialmente divulgado por Kent Beck na

década de 90, esse método busca uma abordagem técnica sobre o desenvolvimento

de um software abordando a codificação, design e testes. Ele é pautado por quatro

atividades chaves Ouvir, Desenhar, Codificar e Testar (TELES, 2006).

Planejamento

O planejamento da metodologia ágil em XP para as empresas desenvolvendo

um software com requisitos disponíveis para que possam ser mudados.

Vai ser baseado na revisão do código fonte, fazendo todos os testes sendo

repetidos em curtos prazos, participações dos usuários finais, integração continua,

planejamento, projeto e sendo projetado novamente quando necessário em qualquer

hora.

O XP é uma das mais conhecidas metodologias de desenvolvimento de

software que seguem os princípios ágeis; foi criado em 1996 tendo a total

colaboração nas boas práticas de programação (TELES, 2006).

As metodologias tradicionais de desenvolvimento foram criadas em um

cenário atual. Anteriormente as limitações tecnológicas e a falta de ferramentas para

a criação de softwares, tinham um custo muito elevado para o seu desenvolvimento

e manutenção. Portanto, era essencial planejar e documentar todo o software para

então implementá-lo (VIANA & DESCHAMPS, 2007).

Para Teles (2006) as boas práticas da XP que as equipes XP teriam um

conjunto de atividades para produzirem softwares. Antes de qualquer coisa teria que

ter confiança nas práticas a serem desenvolvidas para aplica-las em conjunto, pois

aplicadas separadas não trazem os resultados esperados, pois os pontos fracos de

cada prática é protegida pelos pontos fortes das demais práticas.

Em projetos do XP o cliente tem que participar ativamente do processo de

desenvolvimento, seria uma prática que necessita e que acreditamos ter a presença

do cliente para mostrar e facilitar a clara comunicação dos processos com os

desenvolvedores. O cliente sempre presente facilita a total comunicação e quaisquer

dúvidas para que os desenvolvedores sejam sanadas de forma rápida, fazendo com

que o cliente deve possuir a capacidade de responder as perguntas sobre o negócio

e tomar decisões relativas a prioridades no projeto (TELES, 2006).

Realease é uma funcionalidade de uma versão pequena do sistema porém

com recursos completos e importantes ao cliente. A versão é colocada em produção

mais rápida para o cliente usar e usufruir do seu investimento no software e avaliar

dando assim o feedback para os desenvolvedores sobre o release. Representa uma

pequena versão do sistema com todos os recursos completos para o cliente.

A programação em dois ou (programação em par) como costumam dizer, os

desenvolvedores escolhem uma user story em um único computador para que seja

feita a codificação de uma determinada função do sistema. Sempre o desenvolvedor

com menos experiência tem a responsabilidade de assumir o teclado e guiar

ativamente a programação do seu código, enquanto o outro desenvolvedor com

mais experiência examina o código para procurar os erros e defeitos, além de

questionar as decisões e pensar em soluções mais simples para o código (TELES,

2006).

Teles (2006) diz que as vantagens com a programação em par, proporciona a

“ pressão do parceiro” de uma forma bem saudável de manter a disciplina durante

toda a jornada de trabalho e mostrar um desempenho melhor de uma forma de que

um programador ajuda sempre o outro a não deixar passar pelos erros

despercebidos.

O processo de refactoring é um processo de organização do código fonte do

software e melhorar a qualidade interna, melhorando sempre a sua leitura de

diminuir o tempo gasto em manutenção e não prejudicar o seu desempenho ou

alterar o comportamento externo. Essa prática é necessária para que possa fazer

alterações e novas inclusões de suas funcionalidades constantes no sistema, isso é

possível com um software de qualidade e bem organizado e de fácil compreensão. A

XP determina que qualquer equipe faça o refactoring em todos os códigos que

sejam pouco legível. Testes garantem a segurança, e, após cada alteração, eles

informam se o código continua produzindo os resultados esperados (TELES, 2006).

Os riscos vão depender da complexidade ou do próprio ambiente de

desenvolvimento, pois alguns riscos são universais que são considerados pela

Engenharia de software. Os riscos vão depender, como, por exemplo: alteração nos

requisitos, significa mudanças não previstas ou atrasos na especificações, que

seriam essenciais não disponíveis no prazo, a documentação completa pois os

clientes exigem a documentação, perda de alguns membros da equipe em períodos

cruciais que pode ocasionar por doenças ou ate mesmo demissões, entrada de

novas pessoas nesse caso a perda de mão-de-obra teria que treinar novas pessoas

e mudanças gerenciais para a organização com prioridades diferentes, e claro

tamanho do sistema bem maior do que o estimado e acarreta em atrasos pois o

tamanho subestimado bem maior que o planejado. (SOMMERVILLE, 2007);

(TELES, 2006).

Baseando-se no que foi estudado até o momento sobre Desenvolvimento

Tradicional e Desenvolvimento Ágil, dando níveis de Alto e Baixo nas questões

levantadas por (SOMMERVILLE, 2007); (TELES, 2006).

Essa prática deve ser utilizada para que alguns usuários possam utilizar o

software e avaliar, pois dessa forma vários tipos de defeitos podem ser detectados

rapidamente, possibilitando à equipe de desenvolvimento saber se está no caminho

certo ou não.

O XP é composto por partes, Teles (2006) fala que as partes são os valores

,estabelecem a forma do desenvolvimento; princípios, guiam o desenvolvimento do

software; atividades, sendo executadas por todo o ciclo do XP; e praticas; utilizada

pelas equipes XP para desenvolver sistemas.

Os valores do XP são compostos por comunicação, simplicidade

retroalimentação e coragem (TELES, 2006).

Várias práticas do XP promovem uma maior comunicação entre os membros

da equipe.Comunicação não limita por procedimentos formais. Deve-se usar o

melhor meio possível, que podendo ser conversas ou reuniões informaise-mail, bate-

papo, telefonemasou até mesmo o próprio código (TELES, 2006).

Preferencialmente a comunicação ágil deve ser simples.XP incentiva ao

extremo as práticas que reduzam a complexidade do sistema. A solução adotada

deve ser sempre a mais simples para que alcance os objetivos esperados.

O usodas tecnologias, algoritmos e técnicas mais simples que permitirão

atender aos requisitos do usuário final.

Várias práticas de XP garantem um rápido feedback sobre várias

etapas/partes do processo.A solução adotada deve ser sempre a mais simples que

alcance os objetivos esperados.

Feedback sobre qualidade do código (testes de unidade, programação em

pares, posse coletiva)sobre estado do desenvolvimento (estórias do usuário-final,

integração contínua, jogo do planejamento). Elementos que possibilitam maior

agilidade possibilitando que erros detectados sejam corrigidos imediatamente,

requisitos e prazos são reavaliados mais cedo e permite estimativas mais precisas

(TELES, 2006).

Testes, integração contínua, programação em pares e outras práticas de XP

aumentam a confiança do programador e ajudam-no a ter coragem para melhorar o

código que está funcionando para torná-lo mais simples possibilitando investir tempo

no desenvolvimento de testes, mexer no design em estágio avançado, pedir ajuda

aos que sabem mais, abandonar processos formais e ter o projeto e a

documentação em forma de código (TELES, 2006).

Para Teles (2006) os princípios XP são:

- Rapid Feedback - (retorno rápido).

- Assume Simplicity - (simplicidade).

- Incremental Change - (mudanças incrementais).

- Embrace Change - (aceitar mudanças).

- Quality work - (trabalho de qualidade).

Rapid Feedback

O retorno entre os desenvolvedores é rápido. Cliente sabe se o produto que

está sendo desenvolvido atende às suas necessidades. Modele um pouco, mostre

ao cliente e então modele novamente. Garante que o seu modelo será preciso

enquanto seu conhecimento do projeto aumenta (TELES, 2006).

Assuma Simplicity (simplicidade)

Deixe o seu modelo tão simples quanto possível e assuma que a solução

mais simples é a melhor. O design do sistema deve ser feito para a iteração

corrente. Não deve ser feito design sobre uma possível necessidade futura (TELES,

2006).

Mudanças Incrementais

O modelo não será feito na primeira tentativa, irá mudar de acordo com o

desenvolvimento do projeto ao seu decorrer. Os problemas será sempre solucionado

com um conjunto de pequenas modificações (TELES, 2006).

Aceite as mudanças

Mudanças no projeto ocorrerão de acordo com o crescimento do

entendimento do mesmo. Aceite as mudanças e tenha coragem para reconstruir

(TELES, 2006).

Trabalho de qualidade

A qualidade do trabalho nunca deve ser comprometida, XP leva a importância

da codificação e do teste antes da programação (TELES, 2006).

Testes de aceitação

Testes de aceitação são elaborados pelos clientes, são testes automáticos, se

rodam com sucesso afuncionalidade foi implementada são repetidos a cada

alteração,se tem a informação de quanto já foi implementado e quanto falta,

(feedback) (TELES, 2016).

Scrum

O Scrum é um processo de desenvolvimento iterativo e incremental para

gerenciamento de projetos e desenvolvimento ágil de software. Apesar de a palavra

não ser um acrônimo, algumas empresas que implementam o processo a soletram

com letras maiúsculas como SCRUM. Isto pode ser devido aos primeiros artigos de

Ken Schwaber, que capitalizava SCRUM no título (GOMES, 2013).

Apesar de Scrum ter sido destinado para gerenciamento de projetos de

software, ele pode ser utilizado em equipes de manutenção de software ou como

uma abordagem geral de gerenciamento de projetos/programas (SABBAGH, 2013).

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de

projetos em empresas de fabricação de automóveis e produtos de consumo,

por Takeuchi e Nonaka em 1986. Eles notaram que projetos usando equipes

pequenas e multidisciplinares (cross-functional) produziram os melhores

resultados, e associaram estas equipes altamente eficazes à formação Scrum

do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland,

John Scumniotales e Jeff McKenna conceberam, documentaram e

implementaram o Scrum, conforme descrito abaixo, na empresa Easel

Corporation em 1993, incorporando os estilos de gerenciamento observados

por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de

Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o

mundo. Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo

de Hirotaka Takeuchi e Ikujiro Nonaka. A função primária do Scrum é ser

utilizado para o gerenciamento de projetos de desenvolvimento de software.

Ele tem sido usado com sucesso para isso, assim como Extreme

Programming e outras metodologias de desenvolvimento. Porém,

teoricamente pode ser aplicado em qualquer contexto no qual um grupo de

pessoas necessitem trabalhar juntas para atingir um objetivo comum, como

iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o

planejamento de um casamento. (FREITAS, 2016, p. 173).

O Scrum pode ser utilizado para gerenciamento de equipes de manutenção

ou abordado para gerir programas, sua metodologia não se aplica apenas aos

projetos de desenvolvimento de software.

Sabbagh (2013)fala que dentre os benefícios do Scrum, podemos incluir:

- Entregas frequentes de retorno ao investimento dos clientes;

- Redução dos riscos dos projetos;

- Maior qualidade no produto gerado;

- Mudanças utilizadas como vantagem competitiva;

- Visibilidade do progresso do projeto;

- Redução dos desperdícios;

- Aumentando a produtividade.

O projeto pode ser entregue desde cedo e partes do produto funcionando, o

Scrum possibilita essa entrega e proporciona o investimento realizado pelos clientes

do projeto, e possibilita o feeedback rápido do produto para que realize as mudanças

necessárias ou inclusões de forma necessária para os clientes.O Scrum possibilita

um curto prazo para introdução do produto no mercado, sendo que cada entrega

representa um produto funcional (SABBAGH, 2013).

Scrum visa à redução dos riscos do projeto ajudado pela colaboração com os

clientes e os demais interessados durante e no decorrer do projeto.Esses riscos são

a reduzidos no decorrer da produção em ciclos curtos nas entregas das partes

prontas do produto, das partes mais importantes em volta as menos importantes

(SABBAGH, 2013).

A cada ciclo de desenvolvimento tem que possuir a qualidade necessária para

ser entregue para os clientes do projeto. A equipe que trabalha com o Scrum é

responsável pelo trabalho, e possui todas as qualidades necessárias para fazê-los.

As mudanças ocorridas como vantagem são acolhidas como oportunidades e

não como acontecimentos indesejáveis, essas mudanças compreendem a

descoberta dos detalhes do produto, é um processo incremental que ocorre durante

todo o projeto.

O progresso do projeto visa a diversas praticas e artefatos do Scrum para

garantir a visibilidade do progresso do projeto para os participantes envolvidos.

Para reduzir os desperdícios e reduzir evitando por meio da busca da

simplicidade. A equipe que usa Scrum produz e utilize apenas o que é necessário e

suficiente.

Sabbagh (2013) cita algumas regras que ajudam a evitar alguns tipos de

desperdícios.

- Produzir apenas o que os usuários irão utilizar;

- Planejar apenas com nível de detalhes possível;

- Utilizar apenas os artefatos necessários e suficientes.

Uma pesquisa da Standish Group divulgada em 2002, época em que Scrum e

Agilidade eram pouco utilizados, mostra que mais da metade das funcionalidades

solicitadas pelos clientes para o projeto e produzidas nunca ou raramente eram

utilizadas,caracterizando um enorme desperdício.

O desperdício pode ocorre quando define o produto de um alto nível de

detalhes no começo do seu desenvolvimento mesmo que já passaram despendam

em reuniões para levantamento e analise dos requisitos. O desperdício ao se

concentrar em criar e manter apenas o que de fato será utilizado(SABBAGH, 2013).

A documentação além do suficiente e necessário desperdício. Essa

documentação em excesso muda o foco do que realmente é necessário e gera

maior desperdício.

Sabbagh, (2013) diz que o aumento da produtividade e os diversos fatores

que podemos aumentar produtividade com a utilização do Scrum:

- O trabalho em equipe e a autonomia do time na realização desse trabalho;

- A existência de facilitação e de remoção de impedimentos;

- A melhoria continua dos processos de trabalho;

- Um ritmo sustentável de trabalho;

- A maior motivação do time.

O time de um projeto com Scrum é pequeno, de forma que seus membros

possam

interagir e se comunicar durante todo o dia para realizar o trabalho. Trabalhar em

equipe é considerado essencial para o sucesso do projeto.

O time tem autonomia para decidir o quanto é possível de se fazer em um

ciclo e como irá fazê-lo e, assim, ajusta a meta de forma que possa se comprometer

com ela. Os membros do time, então, tornam-se igualmente responsáveis por atingir

essa meta, o que estimula a cooperação entre eles em busca desse objetivo. Assim,

a responsabilidade sobre o trabalho não é individual, mais coletiva(SABBAGH,

2013).

O time que utiliza Scrum está sempre em busca de melhorar a forma de

realizar o trabalho, para tornar mais eficiente. A reunião de sprint retrospective,

sempre realizada ao final de cada ciclo de desenvolvimento, e busca garantir essa

prática (SABBAGH, 2013).

A melhoria contínua promovida pelo time o leva a um aumento progressivo da

sua eficiência na realização do trabalho, o que por sua vez o leva a um aumento

progressivo na sua produtividade.

O ritmo sustentável de trabalho e as praticas de horas-extras forçada do ritmo

de trabalho, utilizado para cumprir o trabalho no prazo determinado, sempre vai

gerar estresse no time que desenvolve o produto e não tardam em derrubar a sua

produtividade e a qualidade do produto gerado.

Cada ciclo de desenvolvimento possui uma duração fixa. De forma similar,

todas as reuniões prescritas pelo Scrum possuem uma duração máxima dentro da

qual

devem ocorrer. São os chamados timeboxes que, quando respeitados com rigor,

auxiliam o time a alcançar esse ritmo constante e sustentável de trabalho.

A motivação do time é ao mesmo tempo consequência dos fatores descritos

anteriormente e causador de um aumento na produtividade. São fatores que

aumentam a motivação, se o time trabalhar em um ambiente que apoie o trabalho, o

que inclui a disposição de todas as ferramentas necessárias para realizar o trabalho

e a organização e confiança de sua gerência(SABBAGH, 2013).

KANBAN

Kanban se difere das outras metodologias ágeis no quesito interação, ele

basicamente não possui interações, seu foco está voltado para cadência, repetições

que ocorrem em intervalos regulares. O Kanban desacopla o planejamento,

priorização, desenvolvimento e entrega, assim cada etapa possui sua própria

cadência. (GOMES, 2013)

O Kanban trabalha com fluxo contínuo não dependendo da finalização do

trabalho planejado para que uma entrega seja realizada, no momento da entrega as

atividades prontas serão entregues e as que ainda não foram concluídas ficaram

para a próxima, sua adaptação é baseada no contexto.

Figura 2 – Fluxo do Kanban

Fonte: GOMES, 2013, p. 16

Baseado no modelo de produção da Toyota (TPS), o Kanban possui uma

ligação direta entre as etapas, onde uma etapa do processo é acionada pela etapa

anterior, “poderíamos dizer que a demanda para se trabalhar em uma nova

funcionalidade seria gerada quando alguma outra fosse entregue” (GOMES, 2013, p.

17).

Segundo Gomes (2013) esse é um método com poucas prescrições, ele

descreve somente três:

- Visualizar o fluxo de trabalho (workflow);

- Limitar o trabalho em progresso;

- Gerenciar e medir o fluxo.

Esse método é altamente adaptativo, pois não possui quase nenhuma

interação tornando-o assim aplicável em qualquer contexto desde que observado as

devidas adequações.

3 TESTES DE SOFTWARE

Falhas ocorrem em qualquer projeto. Somos humanos e estamos suscetíveis

a erros, que podem ocorrer em qualquer etapa do projeto. Mas o quanto antes for

descoberto menor será o prejuízo. Com a tentativa de mitigar as falhas foram

criados vários tipos de testes de software, segundo Pressman (1995, p. 786), “Não é

incomum que uma organização de software gaste 40% do esforço de projeto total

em teste”. O teste tem como seus principais objetivos:

1. A atividade de teste é o processo de executar um programa com intenção de descobrir um erro.

2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.

3. Um teste bem sucedido é aquele que revela um erro ainda não descoberto. (PRESSMAN apud MYERS, 1995, p. 788)

O teste de softwares tem se mostrado uma das formas mais eficaz de se

chegar ao objetivo pretendido, ou seja, entregar o produto final fazendo aquilo que

foi proposto, para Sommerville (2013, p. 144), os teste tem dois objetivos

“Demonstrar ao desenvolvedor e ao cliente que o software atende seus requisitos” e

“Descobrir situações em que o software se comporta de maneira incorreta,

indesejável ou de forma diferente das especificações”.

Pressman(1995) cita dois tipos de testes, os testes caixa branca, no qual se

busca executar cada funcionalidades ao menos uma vez, colocando a prova a lógica

do programa e garantindo assim seu funcionamento. O outro tipo são os testes caixa

preta onde que buscam validar os requisitos funcionais não levando em

consideração o funcionamento interno do programa. Pressman (1995) lembra que o

teste não acaba ao entregar ao finalizar o projeto, a atividade de teste é transferida

para o cliente e que toda vez que o cliente executa o programa um teste é realizado.

Pressman apud Hetzel (1995, p. 830) diz que testes de caixa branca são “testes de

em pequeno porte” e testes de caixa preta são “teste de grande porte”.

Temos que ter em mente que o teste também pode falhar o fato de realizar

testes e não encontrar mais erros não quer dizer que o software está livre de

imperfeições, Pressman lembra que a única coisa que a atividade de teste não pode

fazer é mostrar a ausência de bugs, ele somente evidencia a existência de defeitos.

Bartié (2002) cita que temos testes que garantem a qualidade do processo e

testes que garantem a qualidade do produto. Os testes de verificação ou estáticos

analisam cada fase do desenvolvimento assim é possível definir a qualidade de cada

etapa do processo analisando o conjunto de documentos produzidos. Os testes de

verificação ou dinâmico consiste em aplicar sistematicamente testes durante os

diversos estágios de desenvolvimento, a verificação valida a estrutura interna e a

fidelidade aos requisitos estabelecidos.

Engholm Jr (2013) lembra que devemos nos prevenir e evitar que erros

ocorram, deve se abordado tanto os teste unitários, avaliando cada componente

isoladamente, ou com testes em conjunto onde é analisado a integração e o correto

funcionamento dos componentes desenvolvidos bem como as interfaces de

comunicação. Engholm Jr (2013, p. 281) diz que devemos elaborar um plano de

teste visando “identificar os métodos de verificação e validação, observando-se os

níveis de testes a serem executados, testes de integração e de desempenho, junto

com os testes de aceitação”.

Os testes são essenciais para garantia da qualidade de um software, quantas

vezes já não nos deparamos com um problema no dia a dia devido à falha de um

programa, seja no trabalho, na faculdade, na espera de um serviço público, se

pararmos para analisar muita gente já passou por situações de estresse devido a

alguma falha de um sistema. “Os Estados Unidos estimam que bugs de software

lhes custam aproximadamente 60 bilhões de dólares por ano” (ANICHE, 2014).

Tipos de Teste

Teste de Caixa Branca

É a técnica no qual o teste será baseado no código fonte do software, se

tratando de hardware cada nó de um circuito pode ser testado. Os componentes

internos são analisados com o intuito de encontrar possíveis falhas. Esse modelo de

teste exige um conhecimento técnico uma vez que a avalição será com base na

codificação e estrutura do software. Para definição do teste e suas métricas

em conta a complexidade, a estrutura e criticidade do software a ser testado.

Um exemplo seria definir uma função f(

programa, na sua especificação essa função não poderia aceitar valores negativos,

no teste seria inserido um valor negativo para descobrir se o tratamento de exceções

está funcionando conforme o esperado.

Teste de Caminho Básico

Método proposto por Thomas McCabe baseado na teoria de grafos. O teste

consiste em fazer com que o fluxo do programa passe por um número mínimo de

caminhos entre a entrada e a saída do programa, visa percorrer cada instrução do

programa ao menos uma vez

Para a representação do teste de caminho básico precisamos definir uma

notação para sua representação denominada grafo de fluxo (

grafo de fluxo representa a logica utilizada, na figura 3

ou mais instruções programada

Listagem 1 - Representação do có

/*1*/ import javax.swing.JOptionPane;

/*1*/ public class PotencialTeste {

codificação e estrutura do software. Para definição do teste e suas métricas


Um exemplo seria definir uma função f() qualquer em um determinado



está funcionando conforme o esperado.




programa ao menos uma vez.


notação para sua representação denominada grafo de fluxo (PRESSMAN, 1995

a logica utilizada, na figura 3 cada circulo representa uma

rogramada ou de código fonte sem ramificação.

Figura 3 - Representação de Grafos

Fonte: PRESSMAN, 1995, p.795

Representação do código fonte de cálculo potencial

/*1*/ import javax.swing.JOptionPane;

PotencialTeste {

codificação e estrutura do software. Para definição do teste e suas métricas, leva-se


) qualquer em um determinado







PRESSMAN, 1995). O

cada circulo representa uma

/*1*/ public static void main( String args[] )

/*1*/ {

/*1*/ String PrimeiroNumero,SegundoNumero;

/*1*/ float Base, Expoente,Resultado, Potencial;

/*1*/ PrimeiroNumero = JOptionPane.showInputDialog( "Entra com a

base:" );

/*1*/ SegundoNumero = JOptionPane.showInputDialog( "Entra com o

expoente:" );

/*1*/ Base = Integer.parseInt( PrimeiroNumero );

/*1*/ Expoente = Integer.parseInt( SegundoNumero );

/*1*/ if (Expoente < 0 ){

/*2*/ Potencial=0-Expoente;

/*3*/ }

/*3*/ else {

/*3*/ Potencial=Expoente;

/*4*/ }

/*4*/ Resultado=1;

/*4*/ while (Potencial !=0 ){

/*5*/ Resultado = Resultado * Base;

/*5*/ Potencial=Potencial-1;

/*5*/ }

/*6*/ if (Expoente<0 && Base !=0){

/*7*/ Resultado=1/Resultado;

/*8*/ }

/*8*/ else{

/*8*/ if(Base ==0){

/*9*/ JOptionPane.showMessageDialog( null, "A potencia é

um valor finito " );}

/*10*/ }

/*10*/ JOptionPane.showMessageDialog( null, "A potencia é " +

Resultado, "Resultado", JOptionPane.PLAIN_MESSAGE );

/*10*/ System.exit( 0 );

/*10*/ }

/*10*/ }

Fonte: DEVMEDIA Site: http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-

branca/15610

Figura 4 - Representação do grafo de fluxo da listagem 1

Fonte: DEVMEDIA4

4 Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-

branca/15610> Acesso em 12 mar. 2017.

Caminho independente de programa

São caminhos ao longo do código fonte que executa um novo comando e no

grafo de fluxo é uma nova área que não exercida anteriormente (PRESSMAN,

1995).

É possível calcular um valor para os atributos do software e de complexidade

ciclomática (V(G)) para o grafo de fluxo (BURNSTEIN, 2003).

V(G) é o calculo de complexidade referentea estruturação do código fonte, é o

número de caminhos independentes possíveis e o numero mínimo de caminhos que

pode ser testado, garantindo que o código não possua defeitos (MCCABE, 2010).

Conforme Pressman (1995) a V(G) são calculadas de três formas:

- Primeira forma - Pelos números de regiões do grafo de fluxo.

- Segunda forma - V(G)= E – N + 2.

Onde:

V(G) = e a complexidade ciclomática.

G = representa o grafo de fluxo.

E = representa a quantidade de arestas no grafo.

N = representa a quantidade de ramos no grafo.

- Terceira forma - V(G)= P + 1.

Onde:

V(G) = e a complexidade ciclomática.

G = representa o grafo de fluxo.

P = representa a quantidade de ramos predicativos.

Com os grafos de fluxo representados na Figura 4 serão exemplificados os

valores dos V(G) da seguinte formas:

1. Cinco regiões.

2. V(G) = 13 arestas – 10 ramos + 2 = 5.

3. V(G) = 4 ramos predicativos + 1 = 5.

Por estas formulas calculada chegamos que o grafo de fluxo usado tem cinco

caminhos diferentes para testar o código fonte por completo. Tais como:

- Caminho 1: 1-2-4-5-4-6-7-10.

- Caminho 2: 1-2-4-5-4-6-8-9-10.

- Caminho 3: 1-3-4-6-8-10.

- Caminho 4: 1-3-4-5-4-6-8-10.

- Caminho 5: 1-3-4-5-4-6-8-9-10.

Usando uma estrutura de dados é possível executar todos os caminhos

possíveisno grafo de fluxo de forma automática, para issoéusada uma estrutura de

dados. Usamos uma matriz quadrada onde seu tamanho é igual à quantidade de

ramos encontrados no grafo de fluxo, no qual cada uma das linhas e colunas da

matriz é correspondente às quantidades de ramos (PRESSMAN, 1995).

A Figura 5 representa a utilização da matriz de grafos para um grafo de fluxo

qualquer.

Figura 5 - Representação da matriz de grafos

Fonte: PRESSMAN, 1995, p. 875

Para exemplificar a utilização dos grafos, descreveremos a na figura 6 a

estrutura de controle de um programa e sua lógica.

Figura 6 - Estrutura de controle de um programa e sua lógica

Fonte: DEVMEDIA5

Teste de estrutura de controle

O teste de estrutura do de controle é um conjunto de testes lógicos que

servem como complemento ao teste de caminho básico levando em consideração as

condições lógicas do sistema, busca melhorar a qualidade do teste de caixa branca

(PRESSMAN, 1995).

Teste de condição

Estes tipos de teste busca encontrar erros nas condições booleana simples,

composta ou uma expressão relacional, onde o teste examina os lados positivos ou

falsos da condição booleana. Se uma condição estiver incorreta então é certo um

5Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-


dos componentes que a compões está incorreto. Segundo Pressman(1995), há

erros em uma condição das seguintes formas:

- Erros de operador booleano.

- Erros de variável booleana.

- Erros de parêntese booleano.

- Erros de operador relacional.

- Erros de expressão aritmética.

Teste de fluxo de dados

O teste de fluxo de dados percorre o programa de acordo com a localização

das definições e os usos das variáveis no programa. Esse teste busca verificar a

relação entre as instruções de acordo com as definições de usos de variáveis. Ao

percorrer determinas dos caminhos do código é possível verificar se todas as

atribuições de uma determinada variável estão funcionando (PRESSMAN, 1995).

Para demonstrar o fluxo de dados de cada comando do código fonte é

representada por números.

Categorias do fluxo de dados:

- Bloco básico ou ramos;

- Todos os usos;

- Todos usos computacionais (c-uso);

- Todos usos predicativos (p-uso);

- Caminho livre de def (Todos-du-Caminhos).

A figura 6 mostra como usar o teste de fluxo de dados no grafo de fluxo.

Figura 6 – Teste de fluxo de dados

Fonte: DEVMEDIA6

Teste de Caixa Preta

A nomenclatura se dá devido ao fato de se fazer necessário conhecer a

estrutura interna do software para se realizar o teste de caixa preta.

O teste de caixa preta visa testar as funcionalidades do software, testam-se

os requisitos funcionais. Para Pressman (1995), esse teste é uma complementação

do teste de caixa branca. Não devemos abordar o teste caixa preta como uma forma

de dispensar a aplicação de teste de caixa branca.

Pressman(1995) cita que os testes de caixa preta geralmente são aplicados

em um estágio mais avançado do desenvolvimento do programa, visando descobrir

erros tais como:

6Disponivel em: < http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-


- Funções incorretas ou ausentes;

- Erros de Interface;

- Erros nas estruturas de dados ou no acesso ao banco de dados externos;

- Erros de desempenho;

- Erros de inicialização de termino.

Particionamento de Equivalência

Esse teste cria classe de dados para testar as condições de inputs no

programa, o particionamento de equivalência procura definir o caso de teste que

descubra a classe de erro, cada classe deve testar ao menos uma das faixas de

opções dentre as possíveis. Segundo Pressman (1995, p. 817), “uma classe de

equivalência representa um conjunto de estados válidos ou inválidos para condições

de entrada”.

Como exemplo podemos citar um programa no qual as regras de cadastro de

usuários prevê que o usuário seja o e-mail da pessoa e que a senha tenha no

mínimo seis dígitos e seja alfanumérico. Para a situação exemplificada deveremos

ter ao menos três classes de equivalência uma atendendo a especificação de

usuário, outra atendendo a especificação da senha e uma terceira que não atenda

nenhuma das duas especificações, dessa forma exercitaria ao menos uma cada

entrada de dados tanto com dados válidos quanto com dados inválidos.

Teste de Sistema de Tempo Real

Os testes de sistema de tempo real consistem em testar cada tarefa

independentemente, levando em consideração os testes de caixa preta e de caixa

branca, buscando revelar erros de lógica e de função. Para complementar as tarefas

testadas, é preciso testar o comportamento do sistema de tempo real, levando em

consideração eventos externos como interrupções de usuários. Após isolarmos erros

de tarefas individuais e comportamentais observa-se as tarefas assíncronas ou

intertarefas, onde são analisadas as comunicações e o tempo gasto entre elas

(PRESSMAN, 1995).

Teste de Unidade

O teste de unidade se dá na menor parte de um programa, tendo essa seu

funcionamento independente das demais partes que compõe o software com um

todo. “Um teste de unidade não se preocupa com todo o sistema; ele está

interessado apenas em saber se uma pequena parte do sistema funciona” (ANICHE,

2014, p. 5). Se considerarmos um sistema orientado a objeto seria uma classe.

Teste Ponta a Ponta

São testes que buscam testar o software de uma forma mais ampla,

representando o contexto completo de uma interação do usuário ou caso de uso,

são baseados na regra de negócio, podem ser realizados manualmente ou

automatizados. (GOMES, 2013)

Esse teste geralmente é o teste final, quando a aplicação está por ser

liberada, são testes mais complexos e visam a garantir que a funcionalidade

desenvolvida está em ordem com o especificado.

Teste de Integração

Cada nova artefato criado deverá ser testado quando for adicionada aquilo

que já foi entregado, segundo Scharch (2009) deve-se avaliar se após a introdução

do novo artefato de código não causou nenhum prejuízo após ser integrado ao

código fonte.

Teste do Produto

Para Scharch (2009) o teste de produto acontece após o processo de

integração estiver completo, devendo assim haver um teste do produto como um

todo, quando os testes de produto tiverem sido completados, após os testes de

robustez onde sãoanalisados os picos de tensões como, por exemplo, um grande

número de acessos simultâneos ao sistema, teste de volumes onde é verificado a

upload de grandes arquivos, podemos partir para a etapa de teste de versão com a

disponibilização de releases alfa e beta para possíveis compradores a fim de obter

feedbacks observando se não há falhas individuais.

Teste de Desempenho

Esse teste visa verificar se o tempo de resposta do software está aceitável

conforme especificado no requisito de desempenho. Pressman (1995, p. 865)

lembra que o teste de desempenho pode ser realizado durante todo o processo de

criação do software podendo até mesmo ser aplicado em nível de unidades, “o

desempenho de um módulo individual pode ser avaliado quando são realizados os

testes de caixa branca”. Mas é quando o software está com todos os seus

elementos de sistemas integrados é que podemos verificar o desempenho real de

um sistema.

Teste de Stress

O teste de stress visa confrontar o sistema com situações anormais,

buscando ver até que ponto o software chegará sem falhas. Para Pressman (1995) o

analista ao executar esse teste tenta destruir o programa, causando-lhe ou

condicionando-o a situações extremas e severas, seja quantidade, frequência ou

volume anormais. Ele cita como exemplo o aumento do índice de entrada de dados

para ver como o software responderia com essa taxa aumentada de inputs.

3.1.16 Teste de Segurança

Para Pressman (1995), os motivos para um software ser invadido são

diversos, passando de hackers que tentam invadir um sistema por esporte;

empregado que desejam se vingar da empresa; indivíduos desonestos ou

criminosos que tentam obter alguma vantagem ilícita.

O teste de segurança busca minimizar a vulnerabilidade do software

verificando se todos os mecanismos de proteção estão funcionando corretamente. O

analista desempenha o papel de uma pessoa que deseja invadir o sistema, para

Pressman (1995) qualquer coisa vale, desde tentativa de adquirir senhas via

contatos externos, tentativas de burlar ou ultrapassar o mecanismo de defesa, até

mesmo tentativa derrubar o sistema deixando-o indisponível. Todo sistema pode ser

invadido, o papel do projetista é fazer com que o tempo e o custo de invasão não

vala a pena.

Ferramentas de Teste Automatizadas

Os prazos para entrega dos projetos estão cada vez mais apertados e muitas

vezes os gestores dos projetos não testam seus softwares devido ao seu

cronograma apertado, Pressman (1995) diz que frequentemente os testes são

responsáveis por 40% de todo esforço gasto em um projeto de desenvolvimento de

software. Devido ao grande esforço e falta de tempo começou-se a adotar

ferramentas de teste automatizadas, essa ferramenta são software capazes de

simular ações e computar resultados sobre teste que seriam feitos pelo recurso

humano.

Categoria de ferramentas de teste:

Analisadores estáticos. Esses sistemas de análise de programa suportam a “comprovação” de afirmações estáticas – afirmações fracas sobre a estrutura e o formato de um programa.

Auditores de código. Esses filtros de propósito especial são usados para verificar a qualidade do software, afim de garantir que ele atenda os padrões mínimos de codificação.

Processadores de asserção. Esse sistema pré-processadores/ pós-processadores são empregados para dizer se as afirmações fornecidas pelo programador, denominadas asserções, sobre o comportamento de um programa são de fato cumpridas durante as execuções reais do programa.

Geradores de arquivo de teste. Esses processadores geram, e preenchem com valores previamente determinados, arquivos de entrada típicos para programas que estão em teste.

Geradores de dados de teste. Esses sistemas de análise automatizados auxiliam o usuário a selecionar dados de teste que fazem um programa comporta-se de uma forma particular.

Verificadores de teste. Essas ferramentas medem a cobertura interna dos testes, frequentemente expressa em termos que estão relacionados à estrutura de controle do objeto de teste, relatam valor da cobertura ao especialista em garantia da qualidade.

Bancada de teste (Test Harnesses). Essa classe de ferramenta apoia o processamento de teste, tornando-o quase indolor, para (1) instalar um programa candidato num ambiente de teste; (2) alimenta-lo com dados de entrada; (3) com o uso de stubs o comportamento de módulos subsidiários (subordinados).

Comparadores de saída. Esta ferramenta torna possível a comparação de um conjunto de saídas de u programa com outro conjunto (previamente arquivado) para determinar diferenças entre eles. (PRESSMAN apud MILLER 1995, p. 827).

Pressman (1995) apostava que os teste automatizados seriam cada vez mais

utilizados e comuns, ele dizia que as gerações de testes automatizados

descendentes das primeiras gerações provocariam mudanças radicais na maneira

pela qual testamos softwares melhorando a confiabilidade.

“Testes automatizados são fundamentais para um desenvolvimento de

qualidade, e é obrigação de todo desenvolvedor escrevê-los. Sua existência traz

diversos benefícios para o software, como o aumento da qualidade e a diminuição

de bugs em produção.” (ANICHE, 2014, p. 16).

Test-Driven Development (TDD)

O conceito do Test-Driven Developmento ou TDD é bem simples, a ideia é

escrever o teste antes do código, é começar a implementação pelo teste. Ao

começar pelo teste a codificação tende a ficar mais simples e com maior qualidade.

O primeiro teste irá falhar, pois não há nada codificado ainda, com base na falha se

faz a implementação mais básica possível para resolver o problema, feito isso o

teste irá passar, por fim é só refatorar o código quando necessário.

O TDD ficou popular após a publicação do livro TDD: By Exemplo do Kent

Beck, em 2002, onde o assunto foi abordado e amplamente discutido. O TDD possui

um ciclo conhecido como verde-vermelho-refatora no qual a cor vermelha representa

o teste falhando, a cor verde representa o teste sendo aceito, por fim, refatoramos

para lapidarmos o código já implementado (ANICHE, 2014).

Figura 7 – Representação do Ciclo TDD

Fonte: ANICHE, 2014, p. 25

Algumas vantagens de se utilizar o método TDD no processo de

desenvolvimento de um software:

- Foco no teste e não na implementação. Ao começar pelo teste, o programador consegue pensar somente no que a classe deve fazer, e esquece por um momento da implementação. Isso o ajuda a pensar em melhores cenários de teste para a classe sob desenvolvimento. - Código nasce testado. Se o programador pratica o ciclo corretamente, isso então implica em que todo o código de produção escrito possui ao menos um teste de unidade verificando que ele funciona corretamente. - Simplicidade. Ao buscar pelo código mais simples constantemente, o desenvolvedor acaba por fugir de soluções complexas, comuns em todos os sistemas. O praticante de TDD escreve código que apenas resolve os problemas que estão representados por um teste de unidade. Quantas vezes o desenvolvedor não escreve código desnecessariamente complexo? - Melhor reflexão sobre o design da classe. No cenário tradicional, muitas vezes a falta de coesão ou o excesso de acoplamento é causadomuitas vezes pelo - Desenvolvedor que só pensa na implementação e acaba esquecendo como a classe vai funcionar perante o todo. Ao começar pelo teste, o desenvolvedor pensa sobre como sua classe deverá se comportar perante as outras classes do sistema. O teste atua como o primeiro cliente da classe que está sendo escrita. Nele, o desenvolvedor toma decisões como o nome da classe, os seusmétodos, parâmetros, tipos de retorno, e etc. No fim, todas elas são decisões de design e, quando o desenvolvedor consegue observar com atenção o código do teste, seu design de classes pode crescer muito em qualidade. (ANICHE, 2014, p.26)

O TDD melhora a qualidade do feedback, pois os feedbacks são recebidos

com uma frequência muito maior que na abordagem tradicional onde o teste ocorre

após a finalização de uma etapa do projeto (ANICHE, 2014). Na Figura xx vemos a

comparação entre a abordagem tradicional e o TDD.

Figura 8 – Comparação do time de feedbacks

Fonte: ANICHE, 2014, p. 27

Na engenharia de software não devemos usar as palavras “nunca” e

“sempre”, o mais usual é usarmos a palavra “depende”. Com o TDD não é diferente,

a ideia é usá-lo quando se há a necessidade de receber feedbacks constantes, o

difícil é definir quais são esses momentos.

Figura 9 – Pirâmide de Mike Cohn

Fonte: GOMES, 2013, p.69

A pirâmide de teste criada por Mike Cohn, Figura 9, defende diferentes tipos

de testes além de indicar proporções diferentes para cada tipo. Os teste de unidade

são menores, mais fáceis de serem implementados e mais rápidos de serem

aplicados, eles são a base da pirâmide e é o teste com maior aplicabilidade.

Os testes de integração/API, também são realizados na aplicação sem

interface de usuário, combinam diferentes componentes que trabalham em conjunto

que realizam uma determinada tarefa no sistema, eles são mais completos.

No topo da pirâmide temos os testes de ponta a ponta ou teste de aceitação,

são testes mais complexo e demandam mais esforço para serem implementados,

são mais caros, são mais lentos de serem executados, porem testam a aplicação

desde sua interface. (GOMES, 2013).

4 ANÁLISE DE CUSTO

O custo de manutenção dos softwares é um problema conhecido desde os

primórdios da programação, todo o retrabalho é visto como desperdício, e em se

tratando de construção de um software quanto mais avançado está o projeto maior é

o custo de sua manutenção.

Pressman (1995) compara o software a um “iceberg”, quando se espera que o

problema seja somente o ponto que se vê na superfície na verdade há uma grande

chance dos problemas e custos potenciais serem elevados devido ao que não

vemos sob a superfície. Pressman estimava que a manutenção do software pudesse

ultrapassar 70% de todo o esforço alocado no desenvolvimento de um software.

Historicamente o custo de manutenção de software cresceu com o passar dos

anos, para Pressman (1995) o custo aumentou significativamente entre os anos de

1970 e 1980 passando de um custo estimado em 35% para 60%. Esse era um fator

preocupante, pois se a engenharia de software não encontrasse uma forma de

diminuir o retrabalho os custos com manutenção ultrapassariam os 80% de todo o

esforço inviabilizando muitos projetos ou aumentando absurdamente seu custo.

Na década de 80, Berry Boehm publicou um livro onde era retratado todo o

custo exponencial da mudança em comparação com a fase do projeto, nesta

publicação ele mostrou que ao longo do tempo o custo de correções ou mudanças

sobe significativamente. Sua análise foi baseada nas fases de análise de requisitos

para arquitetura, design, codificação, testes e implantação. Em resumo um erro

corrigido na fase inicial do projeto, na definição dos requisitos, ele possuirá um custo

mínimo, quase insignificante. Mas se o mesmo erro é deixado para ser corrigido

após a conclusão do projeto o mesmo pode chegar a ter um custo 100 vezes maior

conforme podemos ver na figura 10.

Figura 10 - Gráfico de Boehm

Fonte: BOEHM, 1981, p.125

A figura 11 nos mostra a evolução dos custos de mudanças ao longo do

processo de construção de um software podendo na manutenção chegarmos a um

custo de manutenção 200 vezes maior que na faze de levantamento de requisitos, a

proporção pode variar de acordo com o tamanho do projeto, em geral projetos

maiores tendem a ter um custo de manutenção maior que projetos menores.

Figura 11 - Custo da Mudança do Escopo

Fonte: Site Projetos e TI 7

Mecconel (2004) diz que o ideal é encontrarmos o erro antes dele ser

implementado, essa fase se equipara ao levantamento de requisitos. Quanto maior

for o tempo em que o erro persistir no sistema, maior será a possibilidade dele

causar um dano futuro com um custo de correção mais elevado. Macconel (2004)

exemplificou a estimativa de custo com uma tabela e dados referente à mudança de

escopo de acordo com a fase similar a tabela 01.

Tabela 1 – Custo x Fase

Fonte: MACCONEL, 2004, p.7

7Disponível em: <http://projetoseti.com.br/monitoramento-e-controle-controlar-o-escopo> Acessado

em 15 jun. 2017

Fase de detecção

Fase de introdução Requisitos Arquitetura Construção Teste Conclusão

Requisitos 1 3 5-10 10 10-100

Arquitetura --- 1 10 15 25-100

Construção --- --- 1 10 10-25

Figura 12 - Evolução do custo de acordo com a fase

Fonte: MACCONNEL,2004, p.8

O sucesso de um projeto depende, dentre vários fatores, de uma

comunicação acertada, capaz de garantir que os departamentos envolvidos estejam

em consonância com todos os requisitos, parâmetros, notas, desvios e observações

consideradas.

O PMBOK (2014)fala que as fases do projeto é de acordo com a função de

sua natureza, pode variar de quatro a nove fases características.

Fase de iniciação: A fase inicial do projeto, quando uma determinada

necessidade é identificada, monitorada e transformada em um problema a ser

resolvido. O objetivo do projeto é definido, documentos confeccionados e estratégias

melhores selecionadas.

Fase de Planejamento: é a fase responsável por detalhar tudo aquilo que será

realizado pelo projeto, incluindo cronograma, interdependência entre atividades,

alocação de recursos, analise de custos. Nessa fase, os planos de escopo, custo,

qualidade, recursos humanos, comunicação, risco e aquisição são envolvidos.

Fase de Execução: é a fase que materializa tudo aquilo que foi planejado

anteriormente.

Grande parte do orçamento do esforço do projeto é consumindo nessa fase.

Fase de Monitoramento e Controle: É a fase que acontece paralelamente às

demais fases do projeto. Tem como objetivo acompanhar e controlar aquilo que está

sendo realizado pelo projeto. O objetivo do controle é comparar o status atual do

projeto com o status previsto pelo planejamento.

Fase de Encerramento: É a fase quando a execução dos trabalhos é avaliada

através de uma auditoria interna ou externa, os documentos do projeto são

encerrados e todas as falhas ocorridas são discutidas, conhecida também como fase

de aprendizado.

Principais motivos que levam a mudanças no escopo de serviço

Para verificar as dez práticas que mais influenciam os resultados levando em

consideração os custos Xavier (2013) fez uma pesquisa e obteve o seguinte

resultado:

1. O Aceite final foi formalizado.

2. Foi realizada uma reunião de partida (kick-off).

3. Os processos de aquisição dos itens críticos constaram da EAP /

Cronograma.

4. O gerente do projeto tinha conhecimento técnico acerca do escopo.

5. O nível de detalhamento das atividades do cronograma foi condizente com o

nível de controle requerido para o projeto.

6. Foi elaborado o Plano do projeto.

7. O método do nivelamento de recursos foi utilizado para o desenvolvimento do

cronograma

8. Foi utilizado um procedimento formal para solicitação, análise e aprovação ou

não das alterações do projeto.

9. O gerente do projeto propiciou a capacitação dos recursos humanos do

projeto para as atividades a eles alocadas.

10. A organização padronizou o software que devia ser utilizado para o

gerenciamento de Projetos.

5 CONCLUSÃO

Com base no referencial teórico apresentado, pudemos observar que a

maneira mais eficaz, independentemente da metodologia utilizada, ágil ou

tradicional, para se minimizar os custos de concepção de software é fazendo os

testes. A ideia de que testes possuem custo muito elevado “cai por terra” quando se

comparado ao custo do retrabalho em determinadas etapas do projeto, isso sem

levar em consideração que ao fazer uma atualização em determinada parte do

código pode-se vir a gerar erros em outra parte que estava funcionando

perfeitamente.

Com a adoção de novos métodos, novas tecnologias e até mesmo com a

mudança de cultura é possível se produzir mais, com mais qualidade e com redução

de custo. O TDD apresenta uma metodologia no qual todo artefato gerado, toda

nova classe ou atributo, já saem testadas da etapa de desenvolvimento e garante

que se caso um erro seja encontrado o mesmo será corrigido nas primeiras etapas

do desenvolvimento.

Conforme se argumenta nesta revisão bibliográfica, os autores demonstram

que a utilização dos métodos ágeis apresentam importantes ganhos na

implementação de produtos de software. No entanto, uma das premissas do texto

apresentado no manifesto conforme se verifica no capitulo 2, que a recomendação é

ser menos burocrático no processo de construção.

A parte de testes de softwares por si só já é burocrática e apresenta uma

série de técnicas e processos, e poderíamos entender esta execução de etapas

como perda dos ganhos que a metodologia ágil nos dá. Em contrapartida,

analisando a questão dos custos, identificamos que efetivamente termos uma etapa

de teste que permeia todas as etapas da construção do produto de software pode

economizar recursos financeiros consideráveis além de garantir certa qualidade ao

produto de software implementado.

Contudo, não devemos nos preocupar em testar somente devido aos custos

de retrabalho, a qualidade do software também é um ponto relevante, conforme se

apresentou neste trabalho, falhas graves em projetos de software já ocasionaram

prejuízos milionários e até mesmo custaram vidas.

O ideal é fazer o certo de primeira, mas no vivemos em uma utopia, sendo

assim devemos agregar as boas práticas mesclando o que há de melhor em cada

metodologia, implantando a cultura de teste no ambiente de desenvolvimento, dessa

forma conseguiremos alcançar o mínimo de erro e evitar problemas para quem

conta com o software operando em perfeitas condições.

Finalizando esta conclusão entendemos que como as metodologias ágeis

auxiliam bastante no ganho de produtividade da produção do software e a etapa de

testes garante a qualidade e evita retrabalho gerando custos muito altos, a sugestão

é mesclar as duas técnicas para se alcançar um objetivo maior que é a satisfação

dos clientes.

REFERÊNCIAS

ANICHE, Maurício. Test-Driven Development: Teste e Design no mundo real. São Paulo: Casa do Código, 2014.

BARTIE, Alexandre. Garantia de Qualidade de Software. 5. ed. Rio de Janeiro: Campus, 2002.

BOEHM, Barry W. Software Engineering Economics. NY: Prentice Hall, 1981.

BURNSTEIN, I. Practical Software Testing: a process-oriented approach. New York: Springer, 2003.

DEVMEDIA. Uma visão da técnica de teste de caixa branca. Disponível em <http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-branca/15610> Acessado em: 12 mar. 2017.

ENGHOLM Jr, Helio. Engenharia de Software na Pratica. São Paulo: Novatec, 2013.

FREITAS, Carlos A..40 + 16 Ferramentas e Técnicas de Gerenciamento. 6. ed.RJ: Brasport Livros e Multmidia

GOMES,André Faria. Agile, Desenvolvimento de software com entregas frequentes e foco no valor do negócio. São Paulo: Casa do Código, 2013.

KNIBERG, Henrik. Extreme Programming. Dispon[ivel em: <http://www.crisp.se/henrik.kniberg> Acessado em 17 mar. 2017.

MCCABE, T. Glossary of Terms. Disponível em <http://www.mccabe.com/iq_research_iqgloss.htm >. Acesso em: 14 abr. 2017.

MCCONNELL, Steve. Code Complete. 2. ed. Washington: Microsoft Press, 2004.

PROJETOS E TI. Monitoramento e Controle: Controlar O Escopo. Disponivel em: http://formatacaoabnt.blogspot.com.br/2011/10/referencias.html Acessado em: 15 jun. 2017.

PROJECT MANAGEMENT INSTITUTE. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos – Guia PMBOK®. 3. ed.Curitiba: Editora Project Management, 2004.

PRESSMAN, Roger S. Engenharia de Software. 3. ed. São Paulo: Pearson Education do Brasil, 1995.

SABBAGH, Rafael. Scrum - Gestao Agil Para Projetos De Sucesso. Sao Paulo: casa do Código, 2013.

SCHACH, Stephen R. Engenharia de Software: Os Paradigma Clássicos Orientação a Objetos. 7. ed. Porto Alegre: AMGH Editora Ltda, 2009.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Education do Brasil, 2013.

TELES, Vinícius M.. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec, 2006.

VIANA, Leonardo. M; DESCHAMPS, Alexandro. XP – Extreme Programming. Disponível em:<http://www.apicesoft.com/commom/articles/Apice> Acessado em: 16 abr. 2017.

XAVIER, Carlos Magno. Práticas de Sucesso no Gerenciamento de Projetos. Disponível em: <http://pmkb.com.br/artigo/praticas-de-sucesso-no-gerenciamento-de-projetos/> Acesso em: 21 jun. 2017.

Documents

software em desenvolvimento : Software, Métodos Ágeis, Teste. · ... Extreme Programming, ... melhores práticas para o desenvolvimento de um software. ... que rege os princípios