1

INSTITUTO DE ENSINO SUPERIOR DA GRANDE FLORIANPOLIS

Curso de Cincia da Computao

Campus So Jos

William Melchior Jablonski 32020000013

Estudo da aplicao de prticas geis de teste em uma startup de software

Professor Orientador: Patryck Ramos Martins

SO JOS/SC

2014

2

SUMRIO

1. LISTA DE SIGLAS ......................................................................................................................... 4

2. LISTA DE FIGURAS ...................................................................................................................... 5

3. LISTA DE TABELAS ..................................................................................................................... 7

4. RESUMO ......................................................................................................................................... 8

5. INTRODUO ............................................................................................................................... 9

6. TEMA ............................................................................................................................................. 10

6.1. DELIMITAO DO TEMA .................................................................................................... 10

6.2. PROBLEMATIZAO DO TEMA ........................................................................................ 10

7. HIPTESES ................................................................................................................................. 11

8. METODOLOGIA DE PESQUISA .............................................................................................. 12

9. OBJETIVOS .................................................................................................................................. 13

9.1. OBJETIVO GERAL DA PESQUISA .................................................................................... 13

9.2. OBJETIVOS ESPECFICOS ................................................................................................ 13

10. FUNDAMENTAO TERICA ................................................................................................. 13

10.1. ENGENHARIA DE SOFTWARE ..................................................................................... 13

10.2. QUALIDADE DE SOFTWARE ........................................................................................ 14

10.3. TESTE DE SOFTWARE .................................................................................................. 16

10.3.1. NVEIS DE TESTE DE SOFTWARE ............................................................................. 19

10.3.2. TCNICAS DE TESTES DE SOFTWARE .................................................................... 21

10.3.3. TIPOS/CATEGORIAS DE TESTE DE SOFTWARE ................................................... 22

10.4. IMPACTOS DA FALTA DE QUALIDADE NO SOFTWARE ....................................... 24

10.5. DESENVOLVIMENTO DE SOFTWARE: VISO GERAL .......................................... 24

10.5.1. FASES DO DESENVOLVIMENTO DE SOFTWARE ....................................... 24

10.6. PROCESSOS TRADICIONAIS DE DESENVOLVIMENTO ....................................... 26

10.7. PROCESSOS GEIS DE DESENVOLVIMENTO ....................................................... 26

10.7.1. SCRUM .................................................................................................................... 30

10.7.2. EXTREME PROGRAMMING (XP) ...................................................................... 32

10.7.2.1. VALORES BASE DO EXTREME PROGRAMMING ......................................... 33

10.7.2.2. ATIVIDADES BSICAS DO EXTREME PROGRAMMING ............................. 33

10.7.2.3. CINCO REGRAS DO EXTREME PROGRAMMING ........................................ 35

10.8. TCNICAS GEIS DE TESTE ....................................................................................... 37

10.8.1. TEST DRIVEN DEVELOPMENT (TDD) ............................................................. 37

10.8.1.1. CONCEITO DO TDD ............................................................................................. 37

10.8.1.2. MOCK OBJECT ...................................................................................................... 41

10.8.1.3. VANTAGENS DO TDD .......................................................................................... 41

10.8.1.4. DESVANTAGENS DO TDD .................................................................................. 43

10.8.1.5. FERRAMENTA DE TDD ....................................................................................... 44

3

10.8.2. ACCEPTANCE TEST DRIVEN DEVELOPMENT (ATDD) .............................. 44

10.8.2.1. CONCEITO DO ATDD ........................................................................................... 45

10.8.2.2. FERRAMENTA DE ATDD ..................................................................................... 45

10.8.3. BEHAVIOR DRIVEN DEVELOPMENT (BDD) ................................................... 46

10.8.3.1. HISTRIAS DE USURIO PARA O DESENVOLVIMENTO COM O BDD .. 46

10.8.3.2. CONCEITO DO BDD ............................................................................................. 48

10.8.3.3. MOTIVAO DO BDD .......................................................................................... 49

10.8.3.4. FERRAMENTA PARA BDD .................................................................................. 50

10.9. STARTUP ........................................................................................................................... 51

11. APLICAO DO TRABALHO .............................................................................................. 54

11.1. EXEMPLO DE TDD .................................................................................................... 54

11.2. EXEMPLO DE ATDD ................................................................................................. 60

11.3. EXEMPLO DE BDD ................................................................................................... 64

11.4. APLICAO DE PRTICAS GEIS DE TESTE DESENVOLVIMENTO DE

SOFTWARE EM STARTUP ..................................................................................................... 68

12. ESTUDO DE CASO ............................................................................................................... 70

12.1. PROBLEMATIZAO ...................................................................................................... 70

12.2. ABORDAGEM TCNICA ................................................................................................. 70

12.3. DEFINIO DOS PARAMETROS QUALITATIVOS DOS DADOS .......................... 76

12.4. OBTENO E ANALISE DOS DADOS/INFORMAO ............................................ 80

12.5. RESULTADO DO ESTUDO DE CASO ......................................................................... 88

13. CONSIDERAES FINAIS .................................................................................................. 90

14. TRABALHOS FUTUROS ...................................................................................................... 91

15. BIBLIOGRAFIA ....................................................................................................................... 92

4

1. LISTA DE SIGLAS

ATDD - Acceptance Test Driven Development

BDD - Behavior Driven Development

ROI - Return of Investment

TDD - Test Driven Development

XP - Extreme Programming

CMMI - Capability Maturity Model Integration

RUP - Rational Unified Process

PO - Product Owner

EUA Estados unidos da Amrica

5

2. LISTA DE FIGURAS

Figura 1: Regra 10 de Myers: Custo de correo de defeitos ao decorrer do processo de

desenvolvimento do software. ............................................................................................................. 18

Figura 2: Relao entre nveis, tcnicas e tipos de teste. ..................................................................... 19

Figura 3: Escala dos benefcios com times geis. .................................................................................. 28

Figura 4: Ciclo de vida do Scrum ........................................................................................................... 31

Figura 5: Prticas XP .............................................................................................................................. 34

Figura 6: Relacionamento das prticas do XP. ...................................................................................... 36

Figura 7: Processo de TDD ..................................................................................................................... 40

Figura 8: Exemplo de especificao no JBehave. .................................................................................. 47

Figura 9: Cdigo de exemplo JBehave. .................................................................................................. 47

Figura 10: Processo de BDD .................................................................................................................. 49

Figura 11: Histria exemplificando um relatrio de vendas ................................................................. 50

Figura 12: Classe EstacionamentoTest .................................................................................................. 55

Figura 13: Criao dos mtodos ............................................................................................................ 55

Figura 14: Teste falhando ...................................................................................................................... 56

Figura 15: Criao da classe Estacionamento ....................................................................................... 57

Figura 16: Refatorao da classe Estacionamento ................................................................................ 57

Figura 17: Classe EstacionamentoTest com as Trs regras implementadas. ........................................ 58

Figura 18: Classe Estacionamento com os mtodos implementados. .................................................. 59

Figura 19: JUnit informando que os testes passaram ........................................................................... 59

Figura 20: Criao do projeto ProjetoATDD. ......................................................................................... 60

Figura 21: Criao da classe CalculadoraSimples. ................................................................................. 61

Figura 22: Implementando a classe CalculadoraSimples ...................................................................... 61

Figura 23: Inicializando o framework Fitnesse. ..................................................................................... 62

Figura 24: Servio do Fitnesse ativo. ..................................................................................................... 62

Figura 25: Criando critrio de aceitao. .............................................................................................. 63

Figura 26: Critrio de aceite salvo e visualizao da tabela. ................................................................. 64

Figura 27: Execuo dos testes e feedback do framework. .................................................................. 64

Figura 28: Criao da funcionalidade. ................................................................................................... 65

Figura 29: Escrevendo o cenrio ........................................................................................................... 66

Figura 30: Criao da classe ExecutaTestes.java ................................................................................... 66

Figura 31: Classe falha e a informao e exibida no console ................................................................ 67

Figura 32: Criao da classe steps. ........................................................................................................ 68

Figura 33: Classe executada com sucesso. ............................................................................................ 68

Figura 34: Processo de planejamento da Sprint arquitetado pela equipe............................................ 71

Figura 35: Kambam do antigo processo de desenvolvimento Flexy. .................................................... 73

Figura 36: Antigo processo de desenvolvimento. ................................................................................. 74

Figura 37: Novo processo de desenvolvimento. ................................................................................... 75

Figura 38: Resultado da pesquisa de satisfao aplicada em alguns clientes antes da implantao das

tcnicas geis de teste. ......................................................................................................................... 81

Figura 39: Aumento de 30% do tempo de analise do Product Ower.................................................... 82

Figura 40: Reduo de 30% do tempo de analise do programador para codificao. ......................... 82

Figura 41: Aumento de 20% do tempo codificao da tarefa pelo programador. ............................... 83

Figura 42: Reduo de 50% do tempo execuo de testes da tarefa pelo testador. ........................... 83

Figura 43: Reduo de 50% do tempo execuo de testes da tarefa pelo testador. ........................... 84

Figura 44: Aumento de 40% no numero mdio de defeitos reportados durante o teste de regresso

por Sprint. .............................................................................................................................................. 84

Figura 45: Ganho de 50% na produtividade mdia por Sprint. ............................................................. 85

6

Figura 46: Aumento de 70% na documentao do sistema. ................................................................ 85

Figura 47: Reduo de 60% no tempo de resoluo das tarefas de suporte........................................ 86

Figura 48: Reduo de 50% no numero de tarefas de suporte ao ms. ............................................... 86

Figura 49: Ganho de 200% em produtividade atravs da adoo das tcnicas geis de teste no

perodo de um ms. .............................................................................................................................. 87

Figura 50: Ganho acumulado em economia financeira atravs da adoo das tcnicas geis de teste

no perodo de um ms. ......................................................................................................................... 87

Figura 51: Ganho acumulado em economia financeira atravs da adoo das tcnicas geis de teste

no perodo de um ano ........................................................................................................................... 88

Figura 52: Resultado da pesquisa de satisfao aplicada em alguns clientes aps da implantao das

tcnicas de testes geis. ........................................................................................................................ 88

7

3. LISTA DE TABELAS

Tabela 1: Treze prticas do XP. ............................................................................................................. 35

Tabela 2: Estrutura da histria em BDD. ............................................................................................... 46

Tabela 3: Ferramentas que sero agregadas ao processo para complementarem a adoo das

tcnicas geis de teste. ......................................................................................................................... 77

Tabela 4: Custo de mo de obra Flexy. ................................................................................................. 77

Tabela 5: Estimativa de tempo e custo direto da adequao ao processo da Flexy. ........................... 78

Tabela 6: Custo de manuteno mensal da arquitetura. ...................................................................... 78

Tabela 7: Cronograma de implantao e avaliao das tcnicas geis de teste. ................................. 79

Tabela 8: Cronograma treinamento de Tcnicas geis de teste. .......................................................... 81

8

4. RESUMO

A presente pesquisa visa apresentar o estudo de caso da aplicao de prticas geis de teste de software como soluo para a reduo de custos do processo de desenvolvimento de software em empresas startup.

Apresenta-se com base nos autores Kent Beck, um entusiasta das metodologias e prticas geis de engenharia de software e Glendford J. Myers referncia no estudo das prticas e benefcios do teste de software.

Atravs desta pesquisa observou-se que a adoo de prticas geis de teste de software vem de encontro a uma cultura preventiva, evitando que os defeitos inseridos no software sejam disponibilizados para o cliente. A adoo auxilia tambm em um ganho de produtividade e qualidade no software assim consequentemente gerando uma melhora na imagem da empresa com os clientes e mercado, um aumento do ndice de documentao do sistema e uma cobertura constante de testes no sistema. Estas prticas necessitam de um ferramental especfico, mudana no processo de desenvolvimento e mudana cultural da equipe. Os resultados obtidos comprovam que a aplicao de tcnicas geis de teste, dentro do processo de desenvolvimento de software, efetivamente vem a trazer aumento da qualidade do produto final, reduo de custos, um melhor entendimento do que o cliente espera receber no final do projeto e aumento da produtividade da equipe.

Palavras chave: Teste gil, Startup, TDD, ATDD, BDD.

9

5. INTRODUO

Com a popularizao da internet e a evoluo tecnolgica, construir software robustos e com qualidade deixou de ser um diferencial e se tornou uma necessidade para que as empresas de software possam se manter no mercado.

O teste de software uma etapa do processo de garantia de software com foco na garantia de qualidade do produto que visa avaliar se o software atende os padres de qualidade especificados. Qualidade de software, segundo autores a conformidade de requisitos funcionais e de desempenho que foram explicitamente declarados, a padres de desenvolvimento claramente documentados, e a caractersticas implcitas que so esperadas de todo software desenvolvido por profissionais.

Os processos de desenvolvimento de software vm se aperfeioando para auxiliar na produo de software que alinhem qualidade e custo sustentvel, com este fim, o mercado vem apresentando ferramentas e prticas no ciclo de vida gil, dois processos se destacam o Scrum1 e o XP.

No caso do XP, se tem um processo focado no desenvolvimento efetivo do software e no tanto na gesto do processo de desenvolvimento do software como o caso do Scrum. Um dos principais diferenciais do XP est nos seus princpios e prticas. Uma das principais prticas que o XP incentiva a adoo do TDD.

Tratando-se do TDD, se prope a busca de uma codificao simples, efetivamente focado na soluo, funcional e de arquitetura objetiva. O TDD apresenta a tcnica de programar os testes como primeiro passo do processo de desenvolvimento, e posteriormente o cdigo para faz-los atender os testes.

Na tcnica XP tambm se incentiva a prtica do desenvolvimento de testes de aceite antes do desenvolvimento, o ATDD, que se prope a ser utilizado como medida de progresso e indicador dos nveis de qualidade do software, ele citado tambm como uma documentao funcional do sistema dando mais segurana aos envolvidos durante o processo de reescrita, correo e evoluo do sistema. Stakeholders2 usam scripts de testes para descrever as necessidades do cliente e os objetivos na forma de testes automatizados e casos de uso.

Com a utilizao do ATDD surgiu necessidade de ampliar a viso dos requisitos de uma forma padronizada e automatizada, surgindo o BDD. O BDD se prope a destacar a linguagem natural e da interao entre todos os envolvidos no processo de desenvolvimento de software. Stakeholders usam sua lngua nativa para descrever as suas necessidades e objetivos na forma de exemplos. Subsequentemente, estes exemplos proporcionam uma base de requisitos que devem ser contemplados pelo desenvolvimento.

Este conjunto de prticas de testes geis aplicados individualmente em empresas de desenvolvimento de software, como por exemplo, startup de software, segundo autores, tendem a reduzir custos de retrabalho, prevenir a disponibilizao de software em produo com erros crticos de negcio e consequentemente aumentar o potencial de sucesso destas empresas, assim chegando ao retorno do investimento de custo de implantao e manuteno.

H diversas definies para o termo startup, mas a que melhor se encaixa neste contexto devido nfase do alto risco do negcio que seu sucesso influencia

1 Scrum segundo Beck (1999) uma mtodogia de desenvolvimento gil.

2 Stakeholders segundo Myers (2004) como so chamados os interessados no processo de software.

william.jablonskiRealcereduzem*

william.jablonskiRealce

william.jablonskiNota.. e..

10

diretamente na sobrevivncia da empresa no mercado e a utilizao de recursos financeiros finitos que startups so pequenas empresas montadas em casa ou em faculdades e que recebem pequenos aportes de capital. Elas exploram reas inovadoras de determinado setor (mais comumente a de tecnologia), possuindo uma acelerao de crescimento muito alta j nos primeiros meses de existncia em virtude de investimentos feitos por fundos de investimento especializados.

Neste sentido este trabalho visa apresentar conceitos e exemplos do campo da engenharia de software, desenvolvimento orientado a testes, desenvolvimento orientado a testes de aceite e desenvolvimento orientado a comportamento, tal como aplicar as praticas geis de teste e avaliar seus resultados em um cenrio real atravs de um estudo de caso na startup de software Flexy negcios digitais. Aps apresentado o mtodo, ser apresentado os resultados obtidos e as consideraes finais.

6. TEMA

Estudo da aplicao de prticas geis de teste no desenvolvimento de software em empresas startup como tcnica de garantia de qualidade na startup de software Flexy negcios digitais.

6.1. DELIMITAO DO TEMA

Aplicam-se a este trabalho conceitos de testes unitrios, desenvolvimento guiado a testes (TDD), desenvolvimento guiado a testes de aceite (ATDD) e desenvolvimento guiado a comportamento (BDD), XP e Java3.

Este trabalho de pesquisa trata do estudo de aplicaes de tcnicas de desenvolvimento orientado a testes em empresas startup de desenvolvimento de software, que limita-se ao estudo de caso da startup Flexy negcios digitais, uma startup de desenvolvimento de software com menos de um ano de mercado e recursos financeiros limitados.

O perodo de estudo de caso da aplicao desta pesquisa ocorrera entre os meses janeiro a dezembro de 2013.

6.2. PROBLEMATIZAO DO TEMA

Com um aumento da competitividade no mercado de tecnologia da informao, produzir software de qualidade tornou-se uma necessidade para que as empresas se mantenham no mercado, conquistem reconhecimento e sucesso em suas solues desenvolvidas para seus respectivos clientes.

Defeitos em software custaram aos EUA 60 bilhes de dlares. O estudo foi realizado em empresas de tamanho e domnio variados. Uma das mais importantes concluses do estudo foi que este elevado custo ocorre no apenas pela enorme quantidade de defeitos, mas tambm pelo elevado tempo que um defeito leva para ser identificado e corrigido (TASSEY, 2002).

Estima-se que 80% do tempo de um desenvolvedor dedicado identificao e correo de defeitos. Mais de 50% dos defeitos4 no so detectados at a fase de homologao, aproximadamente 50% dos defeitos so introduzidos na fase implementao e cerca de 50% do oramento total de um projeto de software

3 Java segundo Deitel (2005) uma linguagem de programao orientada a objetos desenvolvida na dcada de

90. 4 Defeitos segundo Myers (2004) um erro no funcionamento comum de um software ou hardware.

william.jablonskiRiscado

william.jablonskiTexto digitadotal como a disponibilidade..

william.jablonskiRiscado

william.jablonskiTexto digitadoe

11

gasto na aplicao da correo de defeitos inseridos no software (TASSEY, 2002).

Ajudar na reduo de defeitos importante, pois o custo de correo de falhas alto, crescendo exponencialmente com o decorrer do tempo. Citando um exemplo de Viega e McManus (2000) na fase de especificao custa em mdia US$139,00 para ser corrigida, enquanto que na fase de desenvolvimento, custa US$7.000,00 e para descobrir e corrigir uma falha depois da implantao do software custa US$14.000,00.

Segundo a IEEE (2012) caso um desenvolvedor introduza uma falha no

cdigo fonte, e esta no sendo corrigida, se torna um defeito na aplicao, podendo causar um erro em tempo de execuo, como exemplificado posteriormente.

Utilizando o exemplo de uma loja virtual, caso o boto de finalizar compra esteja com defeitos em uma de suas aes, considerando que as aes deste boto sejam: 1 Efetuar a cobrana do pedido; 2 Salva o pedido para que o lojista possa enviar o produto e 3 enviar o e-mail para o cliente avisando que a compra foi efetuada com sucesso. No cenrio que a ao 2 (salva o pedido para que o lojista possa enviar o produto) esteja com defeito, o pedido cobrado do cliente, mas no disponibilizado para que o lojista possa enviar o produto, ou seja, todos os clientes dessa loja vo pagar pelo produto, mas no iram receb-lo, isso mostra quanto transtorno uma falha no sistema pode causar aos usurios e empreendedores.

Outro exemplo histrico foi o ocorrido na metade do ano de 1962, ocorreu a

primeira tentativa dos seres humanos de explorar outros planetas. O foguete Marier I foi lanado em uma misso para Vnus. O controle terrestre ordenou o abatimento do foguete aps o mesmo desviar da sua rota. Investigaes revelaram que a falta de um simples hfen no programa de computador no foi percebida, causando assim falhas no software. O prejuzo dessa falha ultrapassou 18 milhes de dlares. (TONSIG, 2008). De acordo com o relatrio The Economic Impact Inadequate Infrastructure

for Software Testing estima-se que os custos com defeitos em softwares custem s

empresas americanas um valor prximo de 1% do PIB dos Estados Unidos (TASSEY, 2002).

Em decorrncia do histrico da ocorrncia de tantos problemas notrio que uma pesquisa do IBGE, em seus dados de 2010, exiba que 30% das empresas fecham nos dois primeiros anos de vida (IBGE, 2010).

Para empresas startup de software a qualidade um item primordial j que um erro em produo tem alto custo de correo e pode comprometer a imagem da empresa levando at a falncia. A aplicao de testes geis em startup vem de encontro a reduo custos de manuteno e garantia de qualidade por meio da preveno de erros e execuo contnua de validaes durante o processo de software e um melhor alinhamento entre os requisitos dos stakeholders e a codificao.

7. HIPTESES

A implantao das prticas de teste gil gera um aumento da qualidade dos produtos e servios da empresa avaliada.

A utilizao das prticas de teste gil gera reduo de custos no processo de manuteno do software na empresa avaliada.

Com a aplicao das prticas de teste gil possvel mapear de forma automatizada o atendimento dos requisitos acordados entre os stakeholders.

12

8. METODOLOGIA DE PESQUISA

A metodologia presente neste trabalho apresenta o tipo de pesquisa que ser

adotado, as etapas metodolgicas da pesquisa, um esboo da soluo e as delimitaes da pesquisa.

Esta pesquisa, de acordo com Thomas (2007) classificada como uma pesquisa bibliogrfica devido a abranger a leitura, anlise e interpretao de livros, peridicos, documentos mimeografados ou fotocopiados, mapas, imagens, manuscritos, entre outros. Pode ser classificada tambm como pesquisa exploratria, pois tem por premissa buscar a resoluo de problemas melhorando as prticas por meio da observao, anlise e descries objetivas, atravs de entrevistas com peritos para a padronizao de tcnicas e validao de contedo. A pesquisa descritiva tem por finalidade observar, registrar e analisar os fenmenos sem, entretanto, entrar no mrito de seu contedo.

Conforme dito por Gil (2002), buscando obter uma maior familiaridade, com o ambiente ou fenmeno de estudo, a fim de formular os problemas e hipteses necessrias para anlise, optou-se pelo tipo de pesquisa qualitativa, cuja natureza dos dados definida por Romero e Nascimento (2008) como a mais adequada para dados subjetivos, onde a partir de seus resultados se aprofunda na anlise interpretativa.

Conforme o ponto de vista de sua natureza, este trabalho tende a ser avaliado como uma pesquisa aplicada, pois existe o interesse na aplicao, execuo e resultados prticos dos conhecimentos absorvidos e documentados durante a evoluo do trabalho (GIL, 2008).

O estudo de caso, conforme definido por Gil (2002), o estudo profundo e exaustivo de um ou poucos objetos, de maneira a permitir conhecimento amplo e detalhado do mesmo. Para isso, foi necessrio coletar mtricas do processo de software antes e durante a aplicao das tcnicas .

Os procedimentos metodolgicos para a execuo da pesquisa so:

pesquisa bibliogrfica em livros, teses e artigos relacionados a engenharia de software.

pesquisa sobre processos de desenvolvimento, metodologias e tcnicas de teste gil.

pesquisa sobre test driven development (TDD), ou desenvolvimento dirigido por teste.

pesquisa sobre acceptance test driven development (ATDD), ou desenvolvimento dirigido por aceite.

pesquisa sobre behavior driven development (BDD) ou desenvolvimento dirigido por comportamento.

estudo de caso da aplicao das tcnicas geis de teste na empresa startup Flexy negcios digitais, coleta de mtricas (detalhamento na seo 12.3) e seus resultados.

Portanto, a partir dos resultados, foi possvel comparar os resultados com os da metodologia utilizada anteriormente pela empresa e obter uma anlise qualitativa dos resultados.

13

9. OBJETIVOS

Este item visa apresentar os objetivos gerais e especficos deste trabalho.

9.1. OBJETIVO GERAL DA PESQUISA

Validar os benefcios da adoo das tcnicas de testes geis como Desenvolvimento orientado a teste (TDD), desenvolvimento orientado a teste de aceite (ATDD) e desenvolvimento orientado ao contexto (BDD) atravs do estudo de caso na empresa startup Flexy negcios digitais.

9.2. OBJETIVOS ESPECFICOS

Apresentar os conceito das tcnicas geis de teste TDD, ATDD, BDD.

Aplicar no processo de software da startup Flexy negcios digitais as tcnicas geis apresentadas no decorrer do trabalho de pesquisa.

Avaliar se a implantao das prticas de teste gil gera um aumento da qualidade dos produtos e servios da empresa.

Atestar se a utilizao das prticas de teste gil gera reduo de custos no processo de software e caso aplicado resulta uma maior produtividade.

10. FUNDAMENTAO TERICA

Neste captulo so abordados assuntos que auxiliam o melhor entendimento deste trabalho.

10.1. ENGENHARIA DE SOFTWARE

Segundo Deek (2005) o termo engenharia de software surgiu ao final da dcada de 60, em meio a uma crise no desenvolvimento de software. Nesta poca, o interesse por mtodos padronizados a serem usados no local de trabalho com o intuito de criar aplicaes de qualidade, j havia se tornado um interesse importante para muitas organizaes. Abordagens foram definidas para identificar como a produo de software de qualidade podia ser alcanada nas organizaes, visto que a maioria das aplicaes foram produzidas naquele tempo sob as regras de desenvolvimento da empresa onde nenhuma padronizao verdadeira nem qualidade eficiente eram realmente atingveis para aplicaes de software. De fato, a mistura de novas abordagens e recomendaes, possivelmente s adicionaram maiores complicaes e contriburam ainda mais para crise na indstria de software.

Conforme Deek (2005) ainda nos anos 60, ocorreram duas importantes conferncias onde se originou o termo engenharia de software, realizadas em reconhecimento a esta crise que estava ocorrendo. Foi uma reao a fracassos de projeto, perdas econmicas, atrasos na entrega, mercados competitivos e uma exigncia crescente para funcionalidade, qualidade, e confiabilidade com menor custo possvel.

De acordo com Ieee (1990), o termo engenharia foi usado justamente para associar o "conceito" engenharia ao desenvolvimento de software, em outras palavras ter uma abordagem sistemtica, disciplinada e quantificada ao desenvolvimento, operao e manuteno de software.

Segundo Asee (2000), a engenharia aplicao de princpios matemticos e cientficos, experincia, julgamento e bom senso para trazer coisas que beneficiam as pessoas. A engenharia de software segue este mesmo raciocnio, tendo como

william.jablonskiRiscado

william.jablonskiTexto digitadoAtestar

william.jablonskiNotamanuteno de ..

william.jablonskiNotaAtestar se atravs da aplicao das tcnicas geis de testes possvel gerar uma documentao funcional do sistema.

14

objetivo definir e exercitar processos, mtodos, ferramentas e ambientes para construo de software que satisfaa necessidades de cliente e usurio dentro de prazos e custos previsveis.

A engenharia de software apresenta estratgias de desenvolvimento de software denominadas de modelos de ciclo de vida de desenvolvimento de software ou modelos de processo. Estes modelos, tal como o nome informa, auxiliam o desenvolvimento do incio ao final do projeto.

Conforme Asee (2000), a engenharia de software compreende um conjunto de etapas que envolvem mtodos, ferramentas e procedimentos. Essas etapas muitas vezes so citadas como paradigmas da engenharia de software. Um paradigma de engenharia de software escolhido tendo-se como base a natureza do projeto e da aplicao, os mtodos e ferramentas a serem usados, os controles e os produtos que precisam ser entregues. Neste contexto, dois paradigmas tm sido discutidos e debatidos com maior nfase: ciclo de vida clssico ou cascata e o ciclo de vida gil.

10.2. QUALIDADE DE SOFTWARE

Conforme Juran (1992), qualidade de software uma das reas de conhecimento da engenharia de software que tem como objetivo garantir a qualidade do software atravs de definio de processos dentro do ciclo de desenvolvimento. Embora os modelos aplicados na garantia da qualidade de software atuam com foco no processo, o objetivo mais importante garantir um produto final que atenda s expectativas do cliente.

Segundo Pressman (2006) qualidade a conformidade com os requisitos funcionais e de desempenho previamente declarados, as normas de desenvolvimento documentadas e as caractersticas implcitas que so esperadas de todo software que desenvolvido profissionalmente. A partir desta definio possvel enfatizar trs importantes pontos:

partindo dos requisitos de software pode-se avaliar a qualidade do mesmo, uma vez que a falta de conformidade com os requisitos falta de qualidade;

a definio de normas auxilia no modo como o software submetido engenharia, uma vez que as normas so um conjunto de critrios de desenvolvimento. Se esses critrios no so seguidos, existe uma grande possibilidade de no se obter qualidade;

os requisitos implcitos, na maior parte dos casos, no so mencionados, como, por exemplo, o bom desempenho ou a fcil manuteno do sistema, porm so requisitos esperados. Assim, se o software satisfaz os requisitos explcitos, mas no satisfaz os implcitos, a qualidade do software pode ser considerada suspeita.

Uma vez que so satisfeitos tanto os requisitos explcitos (requisitos funcionais do software) quanto os implcitos (requisitos no mencionados, mas essenciais para o software) as chances de se obter um software de qualidade so maiores.

Para Swebok (2004), essa rea o conjunto de atividades relacionadas com garantia de qualidade de software, entre elas as atividades de verificao e validao, onde as particularidades de um modelo de qualidade de software variam para outro modelo, devido a que cada um tem um nmero diferente de nveis hierrquicos e um nmero total de diferentes caractersticas.

15

A medio, utilizada como apoio para avaliar a qualidade de um software ou produto, pode ser realizada a partir de mtricas de qualidade.

Mtricas de qualidade indicam o quanto um software se adapta s exigncias implcitas e explcitas do cliente. Tais mtricas podem ser:

custo da execuo de uma tarefa;

esforo aplicado na realizao de uma tarefa;

grau de satisfao obtido do cliente;

nmero de pessoas necessrio para implementar um caso de uso;

nmero de defeitos reportados por etapa de desenvolvimento;

tamanho do sistema;

intervalo de tempo necessrio para a execuo de devida tarefa.

Para Pressman (2006), com base em um conjunto de regras claramente definidas, mesmo que as mtricas de produto para software no sejam sempre absolutas, elas tornam possvel avaliar de modo sistemtico a qualidade.

Segundo Juran (1992) um software implementado a tempo e de acordo com o oramento, que no apenas satisfaz as exigncias, pode ser dito como um software de qualidade. Um software isento de erros no , necessariamente, um software de qualidade. Mesmo apresentando um programa sem erros, ele pode no satisfazer as necessidades do usurio.

Para Pressman (2006), as necessidades do cliente so expressas nos requisitos explcitos descritos ao analista, e tambm nos implcitos. Dentre os implcitos podem ser citados: ser flexvel, fcil de operar, barato, construdo no prazo, alm de ter que ser mais prtico, mais rpido, porttil, realizar integrao com outros softwares, ter fcil manuseio, ser mais seguro e mais barato em relao ao processo anterior, fosse ele manual ou j informatizado.

A ausncia de funes necessrias para o usurio no pode ser compensada por funes auxiliares genricas no solicitadas, como uma calculadora, um bloco de notas, um layout diferenciado ou qualquer outro aplicativo do gnero.

Pfleeger (2004) afirma que o surgimento da ISO 9126, modelo utilizado como padro mundial para medir a qualidade de software resultado da busca para consolidar todas as inmeras vises de qualidade em um modelo s, firmada no incio da dcada de 1990 pela comunidade da engenharia de software.

So caractersticas de qualidade, segundo a ISO 9126 de 2003:

funcionalidade: a capacidade do software de prover funes que cumpram s necessidades implcitas e explcitas quando o software estiver sendo utilizado sob condies especificadas;

confiabilidade: a capacidade do produto de software de manter um nvel de desempenho especificado, quando usado em condies especificadas;

16

usabilidade: a capacidade do produto de software de ser compreendido, aprendido, usado e de ser atraente ao usurio, quando usado sob especificadas condies;

eficincia: a capacidade do produto de software de apresentar desempenho apropriado, relativo quantidade de recursos usados, sob condies especificadas;

manutenibilidade: a capacidade do produto de software de ser alterado. As alteraes podem ser correes, melhorias ou adaptaes do software ocasionado por mudanas no ambiente e nos seus requisitos ou especificaes funcionais;

portabilidade: Capacidade do produto de software de ser transferido de um ambiente para outro.

Para ser considerado um produto de qualidade, deve atender todas as especificaes acima. O teste de software tem entre outras funes o papel de garantir a funcionalidade do sistema.

10.3. TESTE DE SOFTWARE

De acordo com Magela (2006), so definies de alguns termos importantes sobre o assunto:

erro: Resultado indevido retornado na execuo do software ocasionado por uma ou mais falhas. Viso de verificao.

falha: Quebra da especificao existente no cdigo-fonte de um componente.

defeito: Composto de falhas que gera um resultado incoerente do software. Viso de validao.

necessrio grande investimento logo no inicio do desenvolvimento do software para conseguir qualidade no produto.

Segundo Molinari (2003), o custo total efetivo do gerenciamento de qualidade a soma dos quatro fatores: preveno, inspeo, falha interna e falha externa..

A preveno a ao que visa identificar as falhas antes que eles apaream; A inspeo, porm foca a medio, avaliao e auditoria dos produtos conforme os padres e especificaes. O custo de falhas internas identificado a partir dos testes. O custo de falhas externa so falhas identificadas pelos clientes, que necessitam de correo.

De acordo com Mller et al. (2007), os testes devem fornecer dados que possam auxiliar a tomada de deciso dentro do projeto, para as fases seguintes do desenvolvimento de um software ou at mesmo da sua implantao. Porm, o sucesso de um processo de testes baseia-se em encontrar um defeito e corrigi-lo o mais cedo possvel, assim, os custos de correo sero menores.

O teste de software deve ser uma etapa bem planejada e cuidadosa, para Vasconcelos et al. (2006), parte dos esforos no desenvolvimento do software no sentido de garantir a qualidade do software.

17

Com a inteno de trabalhar conforme o que foi definido e respeitar aos requisitos dos stakeholders, as atividades de validao e verificao compem um processo que inicia com as revises de requisitos, posteriormente tem-se as revises da anlise e do projeto do software e as inspees do cdigo e por fim os testes em si (SOMMERVILLE, 2003).

Segundo Koscianski et al. (2007) a verificao consiste em encontrar possveis problemas de um componente pronto e defeitos, enquanto a validao busca avaliar a conformidade com os requisitos predefinidos na construo do componente.

Para Magela (2006) o erro atrelado a viso formal da especificao e tem a oportunidade de ser invisvel ao usurio final. Poder ter um erro no software, mas no um defeito. Isso no quer dizer que o software no possua um erro. Tem-se assim uma averso matemtica, ou melhor, caso ter um defeito, logo se tem um erro, porem o inverso no.

De acordo com Myers (2004), o objetivo de revelar a presena de erros ou defeitos aps executar o programa com dados de entrada pr-definidos e verificar os resultados obtidos comparando-os com os resultados esperados teste.

Para Herbert (1999), teste de software um composto de operaes de validao e verificao com o intuito de localizar defeitos no processo e no produto de software.

Conforme Villas Boas (2007), a disciplina de teste adquiriu carter formal apenas aps a execuo da primeira conferncia formal em teste de software (na universidade da Carolina do norte, 1972).

De acordo com Swebok (2004), o teste de software representa a ltima reviso do projeto, especificao e codificao, uma etapa crtica da garantia de qualidade de software e segundo o autor, o processo de teste tem que ser executado durante todo o ciclo de vida do projeto do software.

Em torno de 55% de todas as atividades realizadas pelo setor de desenvolvimento de software de uma companhia tem o intuito de corrigir os erros reportados no sistemas j em execuo, o que explica o instituto de engenharia de software (SEI), rgo criado pelo departamento de defesa americano.

Segundo Back (2000), defeitos reportados na etapa de desenvolvimento custam R$ 10,00 cada para serem consertados e defeitos identificados pelos clientes custam US $ 1.000 cada para corrigir. Logo quanto mais cedo do processo de desenvolvimento do software uma falha for reportada, menor vai ser o custo para sua correo.

A rigor, o teste de software que est atrelado a vidas (de controladores de voo por exemplo) tende a custar de trs a cinco vezes a mais que todos os diferentes passos da engenharia de software reunidos. Pressman (2006) complementa expondo que no difcil uma companhia de desenvolvimento de software consumir entre 30 e 40% do custo total do projeto em testes.

Myers (2004) refere que o custo de reparao de defeitos pode subir 10 vezes a cada etapa da elaborao do sistema, conforme a Figura 1.

18

Figura 1: Regra 10 de Myers: Custo de correo de defeitos ao decorrer do processo de desenvolvimento do software.

Fonte: (Myers, 2004)

O teste, dentro de sua funo, pode ser classificado em nveis, objetivos e tcnicas de teste, segundo Swebok (2004). O teste de software, em seu processo mais comum, realizado em trs nveis diferentes durante o processo de manuteno e desenvolvimento de software: nvel unitrio, nvel de integrao e nvel de sistema. Quando o teste tem o objetivo de verificar se o desenvolvimento atende as especificaes funcionais, esses so os testes funcionais. A verificao de requisitos no funcionais como confiabilidade, desempenho, usabilidade, entre outras conhecido como testes no funcionais. E por fim, tcnicas de teste que foram elaboradas com o intuito de localizar o maior nmero de falhas possveis. As tcnicas de teste so classificadas em caixa-branca, caixa-preta e caixa-cinza, caixa-cinza denominada uma combinao entre as outras duas tcnicas. As tcnicas de teste descritas anteriormente sero detalhadas posteriormente.

Dentre as etapas, uma delas a definio da estratgia do teste. Na definio do plano de teste, segundo Crespo (2004), a tcnica compreende a definio dos seguintes itens:

qual o nvel de teste a ser aplicado, ou seja, definir qual fase do desenvolvimento do software o teste ser executado.

que tcnica de teste ser utilizada;

de que critrio de teste ser aplicado;

qual tipo de teste vai ser exercitado no software.

A Figura 2 demonstra graficamente a conexo presente entre as tcnicas de teste, os nveis de teste, os critrios de teste e os tipos de teste que tem a oportunidade de serem utilizados ao se escolher uma estratgia de teste conforme os padres de qualidade pr-definidos ao produto. (CRESPO 2004).

19

Figura 2: Relao entre nveis, tcnicas e tipos de teste.

Fonte: (CRESPO, 2004)

A Figura 2 representa as trs perguntas chaves no processo do teste de software em seus relativos tipos, tcnicas e nveis de testes em que tem a oportunidade de serem utilizados.

10.3.1. NVEIS DE TESTE DE SOFTWARE

De acordo com Villas Boas (2007), o esforo do teste no meio de um plano de sistema pode ser categorizado em quatro nveis de trabalho, decorrido do alvo que est sendo testado:

Segundo Villas Boas (2007), o teste unitrio, ou teste de unidade, o primrio e mais bsico teste em que um sistema resultado de projeto pode passar. Tem-se que memorizar que unidade, neste contexto, compreendido como o elemento indivisvel de cdigo que est na incumbncia de um nico programador e fragmentado em duas etapas. A primeira foca-se em depurar no seu contexto lxico-sinttico a unidade (como exemplo, aplicado a compiladores), nesta etapa, a aplicao de check-list (listas de verificao) e inspeo visual do cdigo do mesmo modo conduz a bons resultados. Logo a segunda possui o objetivo de averiguar a lgica de unidade. Nesse momento, a ideia exercitar os comandos iterativos, a manipulao das estruturas de dados, os comandos condicionais, as interfaces e verificar a sequencia de controle.

Como as unidade so validadas individualmente, para Delamaro et al. (2007), de acordo com a implementao das unidades o teste de unidade tem a disponibilidade de ser aplicado pelo desenvolvedor, no tendo a exigncia de ter o sistema pronto.

Conforme Delamaro et al. (2007), o teste Integrado (ou teste de integrao) deve ser executado aps os testes de unidades de forma individual, o realce dado na concepo da estrutura do sistema. Conforme os diferentes componentes do

20

software so postos para operar em conjunto, necessrio verificar se a comunicao entre elas no leva a erros e trabalha de maneira correta.

Koscianski et al. (2007), referindo-se a integrao de componentes, afirma que h duas abordagens predominantes no desenvolvimento de software, o bottom-up e o top-down.

Em bottom-up, o sistema desenvolvido com base em rotinas bsicas que trabalham para rotinas com mais alto nvel. Como exemplo, uma verificao se o CPF valido, essa rotina tem a disponibilidade de ser chamada em varias etapas da execuo do programa. Logo ser codificada antecipadamente. No modelo top-down, executa-se uma abordagem inversa, o programador trabalha supondo que o cdigo de baixo nvel esteja pronto. Dessa forma, podem-se implementar chamadas de verificao do CPF, mesmo tendo conhecimento que ainda no existe. No seu lugar, pode ter um stub, ou rotina fantasma", que meramente sempre retorna um valor efetivo afirma Koscianski et al. (2007).

Segundo VILLAS BOAS (2007), o teste efetuado com o software completo anteriormente que ele fique disponibilizado ao cliente o teste de sistema. Este teste tem o intuito de assegurar que as necessidades do cliente (pr definidos na especificao dos requisitos do software) foram codificados. No teste, as interfaces externas so validadas e evidencia-se que o software atendeu os requisitos funcionais e no funcionais especificados.

Delamaro et al. (2007) descreve que o teste de sistema tem como objetivo validar se as necessidades descritas nos documentos de requisitos foram implementadas corretamente. Caractersticas de completude, coerncia e correo devem ser analisados to quanto requisitos no funcionais como por exemplo performance, segurana e robustez. Um grande numero de empresas utilizam da ttica de estabelecer um grupo de pessoas separado com o intuito de realizar os testes nos sistemas.

De acordo com Koscianski et al. (2007), o teste de aceitao realizado com o intuito de analisar a qualidade externa do produto e, na medida do possvel tambm a qualidade em uso. Desta forma, s pode ser executado se o software est finalizado e aguardando a implantao. Claramente, um teste com grande relacionamento ao cliente, o mesmo colabora no planejamento e execuo destas atividade.

Vasconcelos et al. (2006) categoriza os testes de aceitao em duas categorias:

testes alfa: So testes que so executados por um cliente, normalmente dentro da rea de desenvolvimento, neste teste se percebe e toma-se nota dos erros e problemas percebidos e reportados.

testes beta: executado por clientes em potencial dentro do prprio ambiente do cliente no possuindo o acompanhamento do desenvolvedor. O cliente por si s comunica os problemas reportados ao desenvolvedor em seguida.

Segundo Delamaro et al. (2007) h tambm o quinto nvel de teste, o teste de regresso. Ainda segundo o autor, tal tipo nunca realizado durante a aplicao da metodologia padro de desenvolvimento, mas sim na manuteno do software. Em qualquer alterao executada no sistema, posteriormente a sua liberao, tem-se o risco de outros defeitos sejam inseridos. Devido a este motivo, se faz necessrio, posteriormente a manuteno, executar testes que comprovem que as alteraes

21

executadas esto conformes, ou seja, os novos requisitos inseridos (caso for o cenrio) operam conforme o desejado e que os requisitos previamente testados continuam funcionais.

10.3.2. TCNICAS DE TESTES DE SOFTWARE

Segundo Peters e Pedrycz (2001), o teste de software abrange diversas estratgias/tcnicas/abordagens de teste, tal como o teste dinmico, o teste esttico, o teste de caixa preta e o teste de caixa branca, que vai ser explicado a seguir.

Tosetto (2004) esclarece que o teste esttico, conhecido tambm como reviso de software, j que no envolve a execuo em si do programa. As tcnicas de teste esttico se baseiam em inspeo visual, ou seja, na leitura em si do cdigo dos programas por um grupo de indivduos com o intuito de encontrar erros. O custo de correo dos erros reportados neste mtodo aparenta ser de menor custo devido que a origem precisa do erro localizada antecipadamente, enquanto que os testes dinmicos localizam apenas os sintomas dos erros. O autor ainda afirma que estes mtodos no so eficazes na deteco de erros de anlise de requisitos ou modelagem do sistema, relata tambm que alguns autores no consideram que as atividades estticas sejam atividades do teste de software, mas sim que seja uma reviso tcnica formal.

Alguns exemplos clssicos das tcnicas do teste esttico podem ser as inspees de cdigo, o percorrimento e as avaliaes em pares conhecidas tambm como peer-reviews (MYERS, 2004).

O teste dinmico tambm chamado anlise dinmica necessita que o software seja realizado com dados de teste. Este teste se apoia na utilizao de dados inseridos no programa. Estes dados podem ser apenas uma bsica instruo de entrada e sada para monitorar valores de variveis em tempo de execuo do programa ou podem executar os mdulos de anlise que analisam o nmero de vezes em que os elementos do sistema so processados (PETERS E PEDRYCZ, 2001).

Tcnicas dinmicas so utilizadas para localizar defeitos e averiguar a qualidade do software (BURNSTEIN, 2003). As principais tcnicas de testes dinmicos so o teste de caixapreta, tambm conhecido como testes funcionais, que conforme Villas Boas (2007), executado acompanhando o software apenas atravs de suas telas, assim, testando efetivamente as sua funcionalidade. Os erros reportados nesta tcnica, segundo o autor, pertencem s seguintes categorias: erros de interface, funes incorretas, erros na estrutura de dados ou se for o caso de acesso a dados externos (tal como dados armazenados em um banco de dados), erros de inicializao ou finalizao e erros de desempenho.

Uma tcnica exposta por Pressman (2006) neste tipo de teste o particionamento de equivalncia, que nada mais que um mtodo de teste caixa-preta em que divide-se o domnio de entrada de um programa em classes de dados a partir do qual os casos de teste podem ser derivados para se ter um menor nmero de cenrios de teste possveis. Uma classe de equivalncia interpreta um aglomerado de dados vlidos ou invlidos para condies de entrada. Normalmente, uma condio de entrada um dado especfico, uma srie de valores, um conjunto de valores relacionados, ou uma condio booleana, essa condio de entrada demonstrariam a classe toda (PRESSMAN, 2006). A anlise do valor limite que um adicional ao critrio de particionamento de classes de equivalncia, necessita que o testador utilizem valores prximos s bordas, assim os limites superior e inferior vo ser cobertos pelos cenrios de teste (BURNSTEIN, 2003). O grafo de causa-efeito

22

ou tabela de deciso uma tcnica que tem a oportunidade de ser usada para combinar as condies de entrada e assim ter um conjunto mais eficaz de cenrios de teste que deste modo podem encontrar inconsistncias na especificao do sistema. Contudo, a especificao tem que ser transformada em um grfico que se seja similar a um circuito de lgica digital. Este grfico ser convertido em uma tabela de deciso em que quem ir executar os testes possa utilizar l para elaborar seus casos de teste (BURNSTEIN, 2003).

Teste estrutural ou teste de caixa-branca uma tcnica em que se permite analisar a estrutura interna do sistema, isto , analisar a lgica do programa e ocasionalmente, erros na codificao do mesmo (MYERS, 2004).

Pressman (2006) descreve que empregando mtodos de teste caixa-branca, o engenheiro de software tende a construir casos de teste que asseguram que todos os caminhos independentes dos mdulo foram exercitados pelo menos uma vez, foi exercitado todas as decises lgicas em seus lados falsos e verdadeiros, executa se todos os ciclos em seus limites e no interior de seus intervalos operacionais assim como exercite se as estruturas dos dados de forma internas para assim garantir sua validade e efetividade.

10.3.3. TIPOS/CATEGORIAS DE TESTE DE SOFTWARE

De acordo com Peters e Witold (2001), considerando a variedade do teste de software existente, benfico levar em considerao os tipos de testes, conforme se tornam pronto a um projetista. Tal da mesma forma ir ajudar a reconhecer a cobertura em um determinado teste e explicar as vantagens e desvantagens, tal como auxiliar o desenvolvedor a entender as suas limitaes.

Os tipos de teste amplamente difundidos so testes funcionais e testes no funcionais. Conforme Myers (2004) os testes funcionais so um processo de experimentao com o intuito de localizar desconformidades entre as especificaes externas que nada mais que precisas descries do funcionamento do sistema no ponto de vista do usurio final e o sistema em si. A etapa de testes no funcionais exclusivamente aplicada para o fim de deteco de defeitos externos na interface de hardware e software (BURNSTEIN, 2003).

Conforme Magela (2006) apenas o teste funcional no fornece a garantia primordial para que o software entre na produo, por causa disso se faz necessrio conjuntamente o teste no funcional.

Um dos teste no funcional categorizado como usabilidade que de acordo com Ferreira (2002) relativo eficincia e eficcia da interface frente ao usurio e na reao deste usurio frente a interface.

Myers (2004) traa motivos de porque a usabilidade deve receber testes:

- Cada interface de usurio foi construda com foco aos objetivos do usurio final?

- Os retornos do sistema so de fcil entendimento e com uma linguagem simples e objetiva, no de computador?

- As mensagens de advertncia apresentadas pelo sistema so diretas e de fcil entendimento?

- Todas as interfaces seguem o mesmo padro visual?

- Onde a exatido fundamental, como por exemplo um sistema bancrio, apresentado todos os dados suficiente de entrada?

23

- O sistema apresenta um design simples e objetivo, apresentando ao usurio somente as funes que ele ira usar naquele momento?

- O sistema fcil de usar? No cenrio de o usurio necessitar navegar por varias telas, fica claro este caminho para ele, o sistema apresenta est informao de um modo simples e visual ao usurio?

Em teste de volume, conforme Myers (2004), o sistema sujeitado a um grande volumes de dados.

Magela (2006) complementa informando que o teste de volume afere a capacidade do sistema de comportar uma grande massa de dados sem se preocupar com o tempo, em que executado o teste de carga.

No teste de ambiente validado o atendimento aos requisitos necessrios de ambiente. Restries como temperatura do lugar, interferncia ou umidade, entre outros itens tem que ser validadas e verificadas (MAGELA, 2006).

Testes de segurana asseguram o sigilo de informaes tal como a proteo dos dados para a defesa de acessos indevidos de terceiros. O nvel de segurana aplicado depende diretamente dos riscos associados ao negcio. A garantia de sigilo das informaes planejada com o intuito de proteger os recursos da organizao. Diversas informaes, caso reveladas ou manipuladas, podem comprometer o negcio da empresa ou at elevar a vantagem competitiva de seus concorrentes (BASTOS et al., 2007).

Em dias atuais, com o advento da internet, segurana adicional deve ser fornecida. Entretanto, itens como proxy, entre outros no referem-se ao software e sim dados da empresa. Logo, se faz responsabilidade da empresa operar na popular zona segura, e no no sistema em processo de evoluo (MAGELA, 2006).

Teste de desempenho ou conhecido tambm como teste de performance, estruturado com o intuito de aferir o desempenho do sistema em tempo de execuo dentro de seu contexto de integrao. O mesmo ocorre a durante todas as etapas do processo de teste. Referido ao nvel de teste de unidade, o desempenho de um mdulo separado tende a ser aferido quando os testes caixa-branca so executados (SWEBOK, 2004).

Referente a instalao, diversos tipos de sistemas de software possuem procedimentos de instalao complexos. Validar as etapas de instalao e configurao uma etapa relevante do processo do teste de sistema. Essa etapa primordial num sistema com instalao automatizada. O mau funcionamento da etapa de instalao automtica do sistema arrisca barrar que o usurio consiga instalar a aplicao e utiliza-la. A experincia inicial do usurio com o sistema se iniciar j no processo de instalao do mesmo. Caso nessa etapa ocorra algum erro pode acarretar que o usurio ou cliente perca a confiana no produto (MYERS, 2004).

Ao que se refere recuperao, definido por Magela (2006) extremante necessrio analisar o tempo necessrio de recuperao do software quando um de seus recursos falham com o intuito de sempre garantir que o sistema seja auto suficiente em seu processo de recuperao. Ainda segundo o autor, este requisito se faz somente em cenrio especficos devido ao seu auto custo de mapeamento de cenrios possveis e elaborao de solues sistemticas.

Atravs do teste de software possvel validar e garantir a qualidade do software.

24

10.4. IMPACTOS DA FALTA DE QUALIDADE NO SOFTWARE

A reduo da quantidade de defeitos em software colabora fortemente para a diminuio do custo de manuteno, dado que o custo de correo aumenta exponencialmente de acordo com a fase em que encontrada a falha, e com o tempo decorrido desde a incluso do defeito no software. De acordo com Viega e McManus (2000), uma falha encontrada na fase de especificao custa em mdia US$139,00 para ser corrigida, enquanto que na fase de desenvolvimento, custa US$7.000, e para descobrir e corrigir uma falha depois da implantao do software custa cerca US$14.000.

10.5. DESENVOLVIMENTO DE SOFTWARE: VISO GERAL

Durante a dcada de 70, os empreendimentos de desenvolvimento de software eram marcados por problemas comuns como execuo desorganizada, desestruturada e sem planejamento adequado entregues fora do prazo estipulado, que acabava por gerar produtos de m qualidade, sem documentao e sem correspondncia entre o tempo e o esforo orados e a real necessidade. Projetos como esses no satisfaziam as necessidades do cliente, desperdiavam recursos da empresa e elevavam os custos do projeto, que no seriam compensados para o cliente. Pressman (2006) se refere a essa poca como A crise do software.

Nesse cenrio, segundo Pressman (2006) ficou evidente a necessidade de estruturar os processos de desenvolvimento de software, de forma planejada e padronizada. A inteno que as necessidades fossem atendidas, e os custos com a informatizao dos processos de informao se tornassem economicamente viveis.

Pressman (2006) cita que para realizar essa padronizao, foram criadas metodologias de desenvolvimento comeando pelas metodologias de desenvolvimento linear, conhecidas inicialmente por modelo em cascata, at os atuais processos geis de desenvolvimento, que dividem o processo de desenvolvimento em diferentes fases ou etapas pr-definidas. As metodologias aplicadas devem se adequar s caractersticas da organizao em que so aplicadas, e ao ambiente que essa organizao implementa para o desenvolvimento de software. Tambm devem estar alinhadas com o paradigma de desenvolvimento5 e ao tipo de plataforma para a qual o software deve ser desenvolvido. As caractersticas dos projetos (tempo que pode ser utilizado, e as reais necessidades dos interessados) devem ditar os custos e os prazos para o planejamento.

Mesmo com o desenvolvimento das tcnicas avanadas e padres consolidados nos processos de desenvolvimento de software, caracterstica marcantes da crise do software perduram at hoje, em projetos que sofrem ainda com atrasos, erros de estimativas de custo e tempo e imprevisibilidade.

Segundo Somerville (2003) o processo de desenvolvimento de software pode ser divido em fases.

10.5.1. FASES DO DESENVOLVIMENTO DE SOFTWARE

Conforme Somerville (2003), em uma viso mais abrangente do processo de desenvolvimento de software, independentemente da rea de aplicao, tamanho ou complexidade do projeto, possvel identificar trs fases genricas: definio, desenvolvimento e manuteno.

5 De acordo com Scott (2006), um paradigma de desenvolvimento fornece e determina a viso que o

programador possui sobre a estruturao e execuo do programa.

25

Somerville (2003) cita que na fase de definio o objetivo identificar as funcionalidades, restries, validaes, interfaces e os requisitos principais que o projeto precisa atender. essencial a interao com o cliente para validar as definies coletadas ou construdas em conjunto com ele, para garantir que os requisitos essenciais sejam atendidos no decorrer do projeto.

Independentemente dos mtodos utilizados, ou o paradigma aplicado, essa fase composta por trs subtarefas principais: a engenharia de sistemas, que a compreenso e definio dos objetivos do sistema, o planejamento do projeto, que pretende determinar os custos, o tempo, o esforo e os recursos necessrios para concluir o projeto, e a anlise dos requisitos, que o levantamento, compreenso e detalhamento dos requisitos (necessidades) que devem ser atendidos para que o software possa ser considerado de qualidade.

Na fase de desenvolvimento, Somerville (2003) descreve que nessa fase, o objetivo transformar o planejamento e detalhamento do projeto de software em cdigo funcional. Em qualquer que seja a linguagem de programao, as tcnicas e mtodos utilizados, tarefas bsicas devem ser executadas, como a criao do projeto de software, que define o qu e como o software ser desenvolvido, e a gerao do cdigo, que a traduo do que foi especificado em linguagem de programao.

Diversos autores incorporam tambm nessa etapa a fase de testes, como parte das tarefas bsicas. Independente da classificao, essa fase no pode deixar de existir nos projetos de software, dado que nela que so localizadas as no conformidades entre o produto e o que foi especificado na fase de definio. Essas no conformidades podem ser referenciadas como a diminuio da qualidade final do produto, e o no atendimento s exigncias e padres do cliente.

Segundo Somerville (2003), na fase de manuteno que o produto est em funcionamento aplicado em seu contexto. Nessa fase, se analisa todo o produto, com foco na identificao das modificaes necessrias. Essas modificaes podem ser correes de erros, adaptaes s mudanas no contexto ou na necessidade, ou mesmo novas funcionalidades. Essas modificaes caracterizam a evoluo do produto de software.

A fase de manuteno engloba algumas atividades das fases anteriores, com o diferencial de se aplicar a um produto de software existente e em funcionamento.

Somerville (2003) classifica as modificaes que ocorrem na fase de manuteno em quatro tipos:

manuteno corretiva: Correo de defeitos inseridos no produto de software durante uma das fases de desenvolvimento.

manuteno adaptativa: Modificao que visa adaptar o produto de software a uma mudana no contexto em que o mesmo est inserido, mas que no fazem parte de seu escopo, como uma atualizao de software externo, ou uma alterao em uma norma ou legislao qual o software est submisso.

manuteno perfectiva: Insero de novas funcionalidades no produto de software, com o objetivo de torn-lo mais completo. Essas funcionalidades no faziam parte do escopo inicial do produto, e so consideradas como melhorias.

manuteno preventiva: Modificaes que visam preparar o software para que o impacto de mudanas no seja to crtico. Partindo da noo de que mudanas no

26

ambiente, na demanda ou at nos requisitos do software iro acontecer. Essas funcionalidades tambm podem ser referenciadas como reengenharia de software.

Segundo Pressman (2006) as metodologias de desenvolvimento so basicamente divididas em dois grupos, metodologias de desenvolvimento linear, conhecidas inicialmente por modelo em cascata e processos geis de desenvolvimento, que dividem o processo de desenvolvimento em diferentes fases ou etapas pr-definidas.

10.6. PROCESSOS TRADICIONAIS DE DESENVOLVIMENTO

No incio do amadurecimento dos processos de desenvolvimento de software, foram mantidos alguns conceitos tpicos da rea da engenharia, que foram teis na sistematizao dos processos, e com o passar do tempo contriburam para o surgimento da denominao engenharia de software.

Conforme Bauer (1969) Engenharia de software criao e utilizao de slidos princpios da engenharia a fim de obter software de maneira econmica, que seja confivel para trabalhar eficientemente em mquinas reais. Engenharia o conjunto das atividades de anlise, projeto, desenvolvimento, verificao e gerenciamento dos elementos tcnicos.

De acordo com Pressman (2006), a engenharia de software se divide em camadas, todas focadas na qualidade final do produto. Para se atingir essa qualidade, o processo de desenvolvimento deve ser aperfeioado atravs da criao de documentao, artefatos e marcos capazes de representar os elementos que envolvem o desenvolvimento de um produto de software.

Com esse intuito, foram criados mtodos e ferramentas de engenharia de software. Os mtodos abrangem as atividades de anlise de requisitos, planejamento, controle, desenvolvimento, testes e manuteno de software. As ferramentas fornecem o apoio automatizados para a execuo desses mtodos.

10.7. PROCESSOS GEIS DE DESENVOLVIMENTO

Desenvolvimento gil de software conforme Steffen (2012) um processo de desenvolvimento de software que usa uma abordagem de planejamento e execuo iterativa e incremental no qual divide as tarefas em outras tarefas menores e tem foco em entregar o software em estado funcional, da nfase na aproximao e maior colaborao do time de desenvolvimento com os especialistas de negcio e, ou, cliente.

Segundo Steffen (2012), basicamente o principal objetivo de desenvolvimento gil entregar um produto de qualidade dentro das reais necessidades do cliente.

Conforme Highsmith (2004) agilidade em tecnologia da informao a habilidade de criar e responder a mudanas, buscando a obteno de lucro em um ambiente de negcio turbulento. O autor ainda enfatiza que a ausncia de estrutura ou estabilidade pode levar ao caos, mas que a estrutura em demasia gera rigidez. A flexibilidade dos processos geis vem em busca de diminuir est rigidez.

Segundo Steffen (2012) por intermdio do mtodo gil pode-se atingir uma srie de benefcios para os clientes, estes benefcios podem ser:

foco e maximizao do ROI, ou retorno do investimento, tal como do valor de negcio;

27

entregas do produto mais rpida, frequentes e regulares;

acelerao do tempo de entrada no mercado o que se traduz em ganho de competitividade;

maximizao do valor agregado ao mercado. Foco no que prioridade e agrega maior valor para o usurio, o que se traduz em ganho de usabilidade;

transparncia e visibilidade do andamento da execuo do projeto;

flexibilidade para alterao de requisitos e prioridades tal como maior rapidez na tomada de decises;

aumento da qualidade do produto final;

produtividade;

reduo dos riscos e das indesejveis surpresas.

Complementarmente Steffen (2012) afirma que o mtodo gil pode tambm atingir uma serie de vantagens para os gestores e para a equipe, como:

escopo e objetivos claros e priorizados;

equipes auto gerenciveis, maior autonomia, disciplina e regularidade;

maximizao do comprometimento;

melhoria na comunicao. A comunicao intensa com o cliente e a gesto de suas expectativas parte do processo;

analise e adequao constante do processo com o intuito da busca na melhoria contnua e reduo de desperdcios;

antecipao dos problemas e maior agilidade na tomada de aes.

Steffen (2012) ainda cita uma pesquisa realizada mostrando uma escala dos benefcios mais obtidos atravs do uso de times geis, o resultado da pesquisa apresentado na Figura 3.

28

Figura 3: Escala dos benefcios com times geis.

Fonte: (STEFFEN, 2012).

Percebe-se que os maiores ganhos identificados na utilizao de times geis conforme a Figura 3 a produo de software funcional acompanhado do acompanhamento efetivo dos interessados, assim diminuindo a diferena entre a expectativa do cliente e o que est sendo entregue pela equipe.

Com o surgimento do processo de desenvolvimento gil de software foi criado tambm o manifesto gil que que um documento que rene os princpios e prticas desta metodologia de desenvolvimento.

Conforme Beck (2001) "Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o ns mesmos e ajudando outros a fazerem o mesmo. Com este trabalho, passa-se a valorizar:

indivduos e interaes mais que processos e ferramentas.

software em funcionamento mais que documentao abrangente.

colaborao com o cliente mais que negociao de contratos.

responder a mudanas mais que seguir um plano.

Explanando um pouco mais sobre os princpios, Beck (2001) cita que referente ao primeiro certo que o nvel dos profissionais envolvidos no projeto afeta diretamente a qualidade do produto e o bom desempenho da equipe no projeto, no entanto, ter os melhores profissionais no garantia de sucesso no projeto, pois o resultado dos mesmos depende diretamente do processo. Mais importante que as ferramentas e o meio onde se vai trabalhar so a qualidade e o grau de interao da equipe.

29

Referente ao segundo princpio, Beck (2001) cita que a documentao de um projeto extremamente necessria para o sucesso do projeto, j que o cdigo no o melhor meio de comunicao, uma boa documentao se faz necessria na tomada de decises, porem necessrio tomar muito cuidado, pois em excesso de documentao pior do que a falta dela. Para nada serve uma enxuta documentao se ela no se mantm atualizada e em sincronia com o que est sendo desenvolvido e especificado. Segundo o Manifesto Nenhum documento gerado a no ser que seja necessrio e significante, ou seja, deve-se documentar somente o importante e necessrio.

Referente ao item trs do manifesto, Beck (2001) cita que necessrio que exista sempre um acompanhamento do cliente para garantir que o software esteja sendo desenvolvido de maneira que atenda as suas necessidades, contratos que determinam requisitos, prazos e custo de um projeto so, fundamentalmente, falhos. Isso acontece devido, pois no decorrer do desenvolvimento alguns requisitos tornam-se menos importantes ou dispensveis enquanto surge a necessidade de se adicionar outros no previstos em contrato ou especificao. Logo o melhor determinar como acontecer a comunicao e o relacionamento do cliente com a equipe de desenvolvimento.

Ao tratar-se do quarto e ltimo manifesto, Beck (2001) cita que deve-se assumir que mudanas de especificao sempre vo ocorrer em todos os projetos, e possvel afirmar, que melhor ser o projeto que mais se adaptar a estas mudanas. Quanto menor for o tempo para equipe responder mudana maior ser a chance de sucesso do projeto, este um fator fundamental, no deve-se afirmar que os planos no devem ser traados, mas sim que no possvel prever o futuro, logo este planejamento no deve ser de longo prazo.

Juntamente com o manifesto surgiram os doze princpios do gil, que formam mais um pilar deste processo. Conforme Beck (2001) os princpios so:

nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado;

mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente;

entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo;

desenvolvedores e pessoas de negcio tem a obrigao de trabalhar diariamente em equipe por todo o projeto;

construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho;

o mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa;

software funcionando a medida primria de progresso;

os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente;

apropriado design e ateno contnua em excelncia tcnica aumenta a agilidade;

william.jablonskiRiscado

30

simplicidade, a arte de maximizar a quantidade de trabalho no realizado, essencial;

a melhores arquiteturas, requisitos e designs emergem de equipes auto organizveis;

de tempos em tempos, a equipe analisa sobre como se tornar mais eficiente e ento adqua seu comportamento em conformidade com o propsito.

Bissi (2007) afirma que uma das metodologias geis mais utilizadas o Scrum.

10.7.1. SCRUM

Conforme Bissi (2007) O Scrum assume-se como uma metodologia extremamente gil e flexvel, que tem por objetivo definir um processo de desenvolvimento interativo e incremental podendo ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa..

De acordo com Gonalves (2008) o Scrum se tratando de uma metodologia gil no s de desenvolvimento, mas tambm de gerenciamento de projetos. O Scrum foi criado por Ken Schwaber e Jeff Sutherland, ele tem como objetivo introduzir um processo de desenvolvimento com ciclos iterativo e incremental, possibilitando ser usada na gesto de qualquer atividade. Como base o desenvolvimento do Scrum centraliza-se na equipe com ciclos de iterao pequenos. Complementarmente Gonalves (2008), afirma que Scrum a metodologia de desenvolvimento gil de software no qual vem conquistando a cada dia mais adeptos no mercado.

Segundo Maral (2007) o Scrum compreendido da seguinte maneira:

O Scrum um mtodo que aceita que o desenvolvimento de software inesperado e realiza a abstrao, e adequado a mbitos volteis. O Scrum se destaca nos mtodos geis devido grande importncia dada ao gerenciamento do projeto. Envolve prticas de controle e feedback, em reunies dirias e rpidas com toda a equipe, com objetivo corrigir e identificar os impedimentos no processo de desenvolvimento. (MARAL, 2007).

Segundo Gonalves (2008), o Scrum alinha um conjunto de regras e tcnicas de gerenciamento que possibilitam garantir resultados positivos nos projetos, focado para atividades em equipe e avano na comunicabilidade, possibilitando que cada integrante da equipe desenvolva o melhor.

De acordo com Bossi (2003), a nomenclatura inerente utilizada na metodologia Scrum possui os seguintes significados:

product Backlog: Relao de todas as funcionalidades que deveram ser desenvolvidas no decorrer do projeto completo.

scrum Team: Equipe de desenvolvimento de um Sprint.

scrum Master: Personagem da equipe responsvel pela gesto do projeto. Esse personagem embora seja gestor, no tem autoridade sobre os demais integrantes da equipe.

product Owner (PO): Proprietrio do produto.

sprint: Tempo no ser maior que 30 dias, onde somente algumas funcionalidades do projeto so desenvolvidas.

31

sprint Planning Meeting: Reunio de planejamento.

sprint Review Meeting: Reunio de reviso.

sprint Backlog: Atividade desenvolvida em um Sprint de forma a produzir um produto ou resultado que dever ser mostrado ao cliente.

dayling Scrum: Reunio diria.

Segundo Pereira (2007) o Scrum um processo imprevisvel, no descreve como agir em todos os momentos, usado para projetos com alto nvel e complexidade, onde invivel saber o que poder acontecer, usando um framework que permite definir boas prticas para gesto de projetos. Ainda segundo Pereira (2007) o Scrum se baseia em quatro atividades bsicas, que so:

planejamento: Estabelece uma perspectiva do projeto, assegurando benefcios para sua realizao.

stagging: Baseado em estimar o tamanho do projeto elaborando itens para o Product Backlog.

desenvolvimento: Fundamenta-se na execuo de vrios Sprints para o desenvolvimento da propagao de funcionalidade do produto.

releasing: Fundamenta-se na ao da entrega final ao cliente.

A Figura 4 apresenta de maneira simples o ciclo do Scrum.

Figura 4: Ciclo de vida do Scrum

Fonte: (PEREIRA, 2007).

De acordo com Pereira (2007), existe no Scrum uma diviso em trs grupos: o Product Owner, o Scrum Master e o Scrum Team, cada grupo possui atividades particulares porem todos esto envolvidos atuando mutuamente entre si.

O Product Owner (PO) representar os interesses de todos envolvidos no projeto, o PO no necessita ter um conhecimento absoluto sobre a metodologia Scrum, porm precisa compreender bem a atividade que ser desenvolvida.

32

necessrio estar sempre acessvel para a equipe, sobretudo no perodo de reunies de planejamento (Sprint Planning), e nas reunies de reviso (Sprint Review), com a inteno de priorizar as atividades que sero feitas no Sprint.

O Product Owner (PO) tambm tem a responsabilidade de fragmentar as atividades em partes menores e preservar o Product Backlog em ordem, tambm so tarefas do PO:

responsvel pelo retorno financeiro do produto.

pode mudar os requisitos e prioridades a cada Sprint.

detalhar os requisitos do produto, definir a entrega da release e o que deve conter nela.

decidir quais requisitos possuem maior importncia conforme o valor de mercado que possuem.

aceita ou rejeita o concluso de cada Sprint.

O Scrum Master segundo Magnos (2008) tem um papel muito importante no Scrum, este papel ocupado por uma pessoa que trabalha especificamente com a equipe de desenvolvimento. O Scrum Master o responsvel por assegurar a execuo dos procedimentos do Scrum no projeto, a equipe deve compreender que esta pessoa tem entendimento pleno sobre o processo de Scrum e que seu trabalho remover qualquer impedimento na utilizao das prticas do Scrum.

Segundo SOARES (2004), o mais conhecido entre os mtodos geis o Extreme Programing.

10.7.2. EXTREME PROGRAMMING (XP)

Conforme Wells (2012) Ward Cunningham e Kent Beck juntaram-se em 1996 para resolver a necessidade de uma metodologia para desenvolvimento de software com abordagem mais simples, eficiente e direta. Com isso surgiu o Extreme Programming (XP).

Beck (1999) define o Extreme Programming como: uma metodologia gil para equipes pequenas e mdias que desenvolvem software baseado em histrias de usurios e requisitos que se modificam rapidamente. Como o Scrum, o Extreme Programming em relao s metodologias tradicionais possui caractersticas como abordagem iterativa incremental, valorizao da comunicao face a face e constante feedback6.

Segundo Beck (1999) O XP uma abordagem disciplinada e deliberada para o desenvolvimento de software, e vem sendo mais adotada a cada dia, ele afirma tambm que o XP est tomando espao que antes pertencia a outras metodologias, metodologias tradicionais, como por exemplo, o RUP Rational Unified Process7 e o CMMI8.

6 Feedback, segundo FIORELLI (2007), um processo de ajuda para mudanas de comportamento,

comunicao a uma pessoa, ou grupo, no sentido de fornecer-lhe informaes sobre como sua atuao est afetando outras pessoas. 7 Segundo Kroll (2003) o RUP, abreviao de Rational Unified Process, um processo proprietrio de

Engenharia de software criado pela Rational Software Corporation que fornecendo tcnicas a serem seguidas

33

Conforme Beck (1999) o XP fortemente baseado em seus valores.

10.7.2.1. VALORES BASE DO EXTREME PROGRAMMING

O XP, como outras metodologias geis, tem foco na garantia da satisfao do cliente, ele estima que o desenvolvimento do projeto ocorra de forma gil para garantir o cumprimento das estimativas deste. Conforme Beck (1999) quem utiliza devem seguir basicamente quatro valores que sero explicados a seguir, estes so:

comunicao;

simplicidade;

feedback;

coragem.

Sobre comunicao, Beck (1999) ensina que o princpio da comunicao busca em ter o melhor relacionamento possvel entre o cliente e desenvolvedores. Beck (1999) mostra que isto deve ser feito de maneira direta, pessoal, sendo mais explicito, ou seja, devem-se evitar contatos no diretos como telefone, e-mails, entre outros. Conforme ele, isto se aplica tanto para o relacionamento quanto a clientes externos bem como clientes internos, como gerentes e diretores. O valor da simplicidade busca criar cdigos simples, ou seja, sem desenvolvimento desnecessrio, um software com o menor nmero possvel de classes e mtodos. (Beck, 1999)

O feedback constante auxilia os programadores a terem informaes atualizadas, seja do cliente ou do prprio cdigo. Testes contnuos buscam apontar erros tanto no mdulo que est sendo desenvolvido como outros mdulos que j esto no software. Com as constantes entregas do software para o cliente disponibilizado em um ambiente similar ao de produo estas novas verses para o cliente homologar e acompanhar a evoluo, assim possvel ele solicitar melhorias a serem feitas e novas funcionalidades. Neste ambiente integrado os erros so identificados rapidamente pelos testes contnuos e corrigidos. Com o acompanhamento constante do cliente o produto final tende a sempre atender suas expectativas (Beck, 1999).

Referente coragem, para o XP, possuir coragem para adotar os trs valores extremamente importante. Pois nem todos tm facilidade em se comunicar, ou atitude para simplificar o cdigo sempre que ter oportunidade, ou at estar pronto para dar e receber feedback.

10.7.2.2. ATIVIDADES BSICAS DO EXTREME PROGRAMMING

Para Beck (1999): Voc codifica porque se voc no codificar voc no ter nada. Voc testa porque se voc no testar voc no saber quando voc terminou de codificar. Voc ouve porque se voc no ouvir voc no saber o que codificar ou o que testar. E voc projeta para que voc possa codificar, testar e ouvir indefinitivamente.

pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. 8 Conforme o SEI (2010), CMMI um modelo de referncia baseado nas melhores prticas para

desenvolvimento e manuteno de produtos, ele procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

34

Beck (1999) diz que o XP feito de quatro bsicas atividades:

codificar: Codificar escrever o cdigo efetivamente.

testar: Para todo trecho de cdigo, deve haver um trecho de teste unitrio correspondente.

ouvir: Ouvir sempre o que o cliente tem a dizer, o que ele tem a mostrar e aprender com ele sobre o seu negcio.

projetar: Criar uma estrutura que organiza a lgica de modo a diminuir a complexidade do cdigo.

Conforme JEFFRIES (2012) estas quatro atividades so distribudas em treze prticas conforme apresenta a Figura 5:

Figura 5: Prticas XP

Fonte: (JEFFRIES, 2012).

Conforme Jeffries (2012) as treze prticas podem ser descritas conforme apresentado na tabela 1.

Jogo do planejamento Estime as tarefas, defina e priorize o escopo da verso atual seguinte, se tiver algum problema, refaa o planejamento.

Pequenas Verses Busque um prazo de entrega de uma a duas semanas para cada nova entrega de verso do software e trabalhando com a avaliao do cliente para evitar surpresas nas entregas das verses.

Metforas Escreva historia com a necessidade do cliente e uma descrio breve