Uma abordagem em testes de software com XUnit

Transcrição

UNIVERSIDADE COMUNITÁRIA REGIONAL DE CHAPECÓ
CENTRO TECNOLÓGICO
CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA E
QUALIDADE DE SOFTWARE
Extreme Programming: Uma Abordagem em Testes de
Software Utilizando XUnit
Projeto apresentado à Universidade Comunitária
Regional de Chapecó, para avaliação da Monografia,
como parte dos requisitos à obtenção do grau de
especialista em Engenharia e Qualidade de Software.
JOSÉ CARLOS TONIAZZO
Orientador: Elton Luís Minetto
Chapecó (SC), JULHO DE 2007
SUMÁRIO
LISTA DE FIGURAS ________________________________________________III
LISTA DE TABELAS E QUADROS ___________________________________ IV
LISTA DE SIGLAS E ABREVIATURAS ________________________________V
1
PROBLEMATIZAÇÃO ___________________________________________ 7
2
QUESTÕES DE PESQUISA _______________________________________ 8
3
JUSTIFICATIVA_________________________________________________ 9
4
OBJETIVOS____________________________________________________ 10
5
4.1
Geral ______________________________________________________ 10
4.2
Específicos__________________________________________________ 10
ENGENHARIA DE SOFTWARE E METODOLOGIAS DE MODELAGEM
ÁGIL __________________________________________________________ 11
5.1
Princípios da Engenharia de Software Tradicional ________________ 12
5.1.1
5.2
6
Modelos de Processo de Software ______________________________ 13
Modelagem Ágil de Software __________________________________ 19
5.2.1
Princípios Básicos __________________________________________ 21
5.2.2
Valores da Modelagem Ágil __________________________________ 25
5.2.3
Princípios da Modelagem Ágil ________________________________ 26
5.2.4
Modelagem Ágil na Prática ___________________________________ 30
PROGRAMAÇÃO EXTREMA ____________________________________ 35
6.1
Valores DA XP ______________________________________________ 37
6.1.1
Comunicação ______________________________________________ 37
6.1.2
Simplicidade ______________________________________________ 38
6.1.3
Feedback _________________________________________________ 39
6.1.4
Coragem__________________________________________________ 41
6.2
Práticas ____________________________________________________ 43
6.2.1
Mantendo a Proximidade com o Cliente _________________________ 44
6.2.2
Planejando o Software _______________________________________ 45
6.2.3
Semana de 40 horas _________________________________________ 48
ii
6.2.4
Programação em Pares_______________________________________ 49
6.2.5
Código Coletivo ____________________________________________ 51
6.2.6
Padrões de Codificação ______________________________________ 52
6.2.7
Design Simples ____________________________________________ 53
6.2.8
Refatoração _______________________________________________ 55
6.2.9
Integração Contínua _________________________________________ 57
6.2.10
Entregas Freqüentes ________________________________________ 58
6.2.11
Uso de Metáforas __________________________________________ 59
6.2.12
Desenvolver com Base nos Testes_____________________________ 61
6.3
7
Desenvolvendo Software Utilizando Programação Extrema_________ 62
6.3.1
Quando Utilizar ou Não Utilizar a XP___________________________ 64
6.3.2
XP nas Empresas Atualmente _________________________________ 65
TESTES UNITÁRIOS DE SOFTWARE COM XUNIT ________________ 67
7.1
Principios do Teste de Software ________________________________ 68
7.2
Testes de Software e a XP _____________________________________ 73
7.2.1
Testes de Aceitação _________________________________________ 74
7.2.2
Testes Unitários de Software na XP ____________________________ 75
7.3
Framework XUNIT: Aplicando Testes Unitários de Software _______ 78
7.3.1
PHPUnit: Aplicando Testes Unitários de Software em PHP__________ 80
8
PROCEDIMENTOS METODOLÓGICOS __________________________ 84
9
CRONOGRAMA DE AÇÃO ______________________________________ 85
10 ORÇAMENTO__________________________________________________ 86
11 REFERÊNCIAS _________________________________________________ 87
LISTA DE FIGURAS
FIGURA 1: CAMADAS DA ENGENHARIA DE SOFTWARE................................................................... 13
FIGURA 2: FASES DE UM CICLO DE RESOLUÇÃO DE UM PROBLEMA................................................ 14
FIGURA 3: FASES DENTRO DAS FASES DO CICLO ............................................................................ 15
FIGURA 4: MODELO EVOLUCIONÁRIO INCREMENTAL .................................................................... 17
FIGURA 5: MODELO EVOLUCIONÁRIO EM ESPIRAL......................................................................... 18
FIGURA 6: ESBOÇO DE UM DIAGRAMA UML................................................................................. 23
FIGURA 7: DIAGRAMA UML FEITO UTILIZANDO O SOFTWARE MICROSOFT VISIO ....................... 23
FIGURA 8: ESTRUTURA DA MAS.................................................................................................... 25
FIGURA 9: PLANO COMPARATIVO DE MODELOS DE DESENVOLVIMENTO ....................................... 27
FIGURA 10: FORMAS DE COMUNICAÇÃO PROPOSTAS ENTRE DESENVOLVEDORES ......................... 30
FIGURA 11: PRÁTICAS E VALORES QUE DEFINEM A XP ................................................................. 36
FIGURA 12: CICLO DE DESENVOLVIMENTO UTILIZANDO XP ......................................................... 41
FIGURA 13: PRÁTICAS DA XP......................................................................................................... 43
FIGURA 14: EXEMPLO DE RELEASES, ITERAÇÕES E TAREFAS EM UM PROJETO DE OITO MESES ..... 47
FIGURA 15: GRÁFICO DE CUSTOS DAS MUDANÇAS PROPOSTO PELA XP ........................................ 54
FIGURA 16: GRÁFICO COMPARATIVO DA PRODUTIVIDADE DURANTE O DESENVOLVIMENTO ........ 57
FIGURA 17: INTERDEPENDÊNCIA DAS PRÁTICAS DA XP................................................................. 61
FIGURA 18: TESTES DE SOFTWARE AO LONGO DO DESENVOLVIMENTO ........................................ 70
FIGURA 19: PROCESSO DE TESTES PARA ENCONTRAR POSSÍVEIS ERROS NO SISTEMA .................... 71
LISTA DE TABELAS E QUADROS
TABELA 1: ALGUMAS DAS TECNOLOGIAS DE COMUNICAÇÃO PASSÍVEIS DE UTILIZAÇÃO ............. 31
TABELA 2: METODOLOGIAS DE DESENVOLVIMENTO ÁGIL DE SOFTWARE ..................................... 33
TABELA 3: EMPRESAS QUE UTILIZAM XP EM ALGUNS DE SEUS PROJETOS .................................... 66
TABELA 4: FERRAMENTAS PARA TESTES UNITÁRIOS AUTOMATIZADOS ....................................... 79
QUADRO 1: COMPARATIVO ENTRE A MAS E OS MODELOS TRADICIONAIS .................................... 22
QUADRO 2: TEMORES A SEREM SUPERADOS COM USO DA XP ....................................................... 42
QUADRO 3: DOIS ESTILOS DE ESCREVER CÓDIGO FONTE ............................................................... 52
QUADRO 4: USO DO PHPUNIT EM UM TESTE DE CLASSE ............................................................... 82
QUADRO 5: UM TEST SUITE ABRANGENDO UM CONJUNTO DE TESTES ........................................... 83
QUADRO 6: RESULTADO DE TESTES EXECUTADOS VIA LINHA DE COMANDO ................................ 83
QUADRO 7 . CRONOGRAMA DO PROJETO DA MONOGRAFIA (2º TRIMESTRE 2007)........................ 85
QUADRO 8 . CRONOGRAMA DA MONOGRAFIA (2º SEMESTRE 2007) ............................................. 85
LISTA DE SIGLAS E ABREVIATURAS
4GT
Fourth Generation Techniques
ASD
Adaptive Software Development
CMM
Capability Maturity Model
DSDM
Dynamic Systems Development Methods
EUP
Enterprise Unified Process
FDD
Feature Driven Development
HTML
Hyper Text Markup Language
OSS
Open Source Software Development
PHP
Personal Home Page
RAD
Rapid Application Development
RUP
Rational Unified Process
SW-CMM
Software Capability Maturity Model
UML
Unified Modeling Language
VB
Visual Basic
XML
Extensive Markup Language
XP
Extreme Programming
TEMA/ DELIMITAÇÃO
Este trabalho aborda o processo de desenvolvimento de software com o uso de
metodologias ágeis, com ênfase para a Programação Extrema (Extreme Programming – XP).
Além de definir o conceito da Programação Extrema, também são introduzidos os principais
conceitos de engenharia de software tradicional, a fim de verificar onde esta forma de
desenvolvimento pode contribuir para melhorar o processo de construção de software.
Outro ponto relevante a ser considerado, é a aplicação de testes de software na
Programação Extrema. Além de definir os conceitos básicos de teste de software, também será
utilizado o Xunit, ferramenta para efetuar testes unitários a fim de aumentar a produtividade
durante o desenvolvimento. Para verificar o funcionamento e a eficácia dos testes unitários de
software na Programação Extrema, será utilizado o PHPUnit (Xunit aplicado à linguagem de
programação PHP).
Dessa maneira, este trabalho fará uma investigação da possibilidade do uso da
Programação Extrema durante o desenvolvimento de software, principalmente em pequenas e
médias equipes de desenvolvimento.
1
PROBLEMATIZAÇÃO
Atualmente, muitos desenvolvedores de software encontram dificuldades em estipular
um padrão de concepção ideal, que alie agilidade, qualidade do produto final e baixo custo. A
grande maioria tem a consciência da necessidade de adotar uma metodologia que se aproxime
ao máximo da realidade de sua equipe de desenvolvimento, visando obter o melhor custo
benefício no processo de confecção de software, mas encontram dificuldade em estipulá-lo.
Outra questão relevante, diz respeito às formas de desenvolvimento utilizadas
atualmente. Estas não satisfazem plenamente os objetivos expostos acima, ou por tornar o
processo muito demorado, devido a grande quantidade de requisitos a serem preenchidos, ou
por desenvolver um produto sem um padrão estipulado. Isso faz com que o preço do mesmo
aumente em longo prazo, devido a problemas quanto à documentação e falhas de programação.
Assim, como não existe um processo de desenvolvimento unânime, buscar métodos
que apresentem melhores resultados à realidade de cada equipe de desenvolvimento permite um
amadurecimento da engenharia de software. Portanto, é de suma importância analisar as formas
de desenvolvimento existentes, e buscar a que melhor se adapte a realidade de cada empresa.
Sendo assim, a partir do estudo da Programação Extrema, metodologia de
desenvolvimento considerada inovadora, serão verificados fatores como aplicabilidade da
mesma no desenvolvimento, maturidade do processo, e adequação na engenharia de software
tradicional. Para isso, será dada ênfase às premissas desta forma de desenvolvimento,
principalmente no que diz respeito a testes unitários de software utilizando XUnit.
2
QUESTÕES DE PESQUISA
Diante do problema levantado, algumas questões referentes à pesquisa podem ser
consideradas:
a metodologia de Programação Extrema pode ser aplicada de forma efetiva no
processo de desenvolvimento de software?
a modelagem ágil de software permite uma melhor aplicabilidade da Programação
Extrema?
é possível aplicar os conceitos de Programação Extrema em equipes de
desenvolvimento que já desenvolvem software usando a engenharia de software
tradicional?
quais as características necessárias em uma equipe de desenvolvimento para aplicar
com sucesso a Programação Extrema?
os testes unitários de software, caso bem aplicados no desenvolvimento, podem
garantir o sucesso da Programação Extrema?
o processo de testes unitários de software em PHP podem ser feitos com o uso da
ferramenta Xunit?
3
JUSTIFICATIVA
Diante da dificuldade encontrada pela maioria das equipes de desenvolvimento de
software, este trabalho visa abordar uma metodologia que permita melhorar o processo das
mesmas. Através de uma metodologia ágil de desenvolvimento, é possível aprimorar o
desenvolvimento em equipes pequenas e médias, buscando resultados mais satisfatórios, e em
um tempo menor.
Tal abordagem se justifica, visto que o conceito de metodologias ágeis é recente, e
muitas vezes é visto com receio. Isso porque questiona muitos pontos da engenharia de software
tradicional. É claro que seu intuito não é este, mas sim adaptar o desenvolvimento a grupos
menores, introduzindo inicialmente, as principais etapas da confecção de software para garantir
um produto final de qualidade.
Nesse aspecto, este trabalho fará um estudo das metodologias ágeis, detalhando a
Programação Extrema e os processos de testes unitários de software. Isso pois o assunto é novo
e desafiador, mas já conta com adeptos desta forma de desenvolvimento.
Por fim, explanar a Programação Extrema permite que os principais conceitos da
engenharia de software sejam preservados, e possam ser inseridos sutilmente em equipes de
desenvolvimento menores. Dessa forma, evita-se gerar um desconforto de seus membros, ao
mesmo tempo em que se aprimora o processo de desenvolvimento.
4
OBJETIVOS
Os objetivos do presente trabalho dividem-se em geral e específicos, os quais são
mencionados a seguir.
4.1 GERAL
Descrever com detalhes a Programação Extrema, identificando os principais requisitos
para utilizá-la, com ênfase no processo de testes unitários de software.
4.2 ESPECÍFICOS
Diante dos objetivos gerais apresentados acima, obtêm-se os seguintes objetivos
específicos:
•
definir os requisitos para a aplicabilidade da metodologia XP em pequenas e
médias equipes de desenvolvimento;
•
apresentar de forma detalhada, vantagens e desvantagens do uso de metodologias
ágeis de desenvolvimento de software;
•
detalhar uma ferramenta de testes unitários de software capaz de suprir as
necessidades da metodologia XP;
•
validar o framework Xunit, fazendo testes unitários de software em frameworks de
desenvolvimento de aplicações;
•
aplicar testes unitários de software definidos na Programação Extrema na
linguagem de programação PHP.
5
ENGENHARIA DE SOFTWARE E METODOLOGIAS DE MODELAGEM ÁGIL
Haja vista a necessidade do presente trabalho analisar a viabilidade de utilizar a
modelagem ágil de software, neste capítulo será feita a análise desta metodologia. Além disso,
os conceitos de engenharia de software tradicional serão expostos de forma sucinta. Dessa
maneira, com base nas definições apresentadas, o leitor poderá observar os principais pontos
que resultam no uso de uma ou outra.
A engenharia de software, assim como as demais engenharias, visa buscar a melhor
maneira de desenvolver seu produto, com base em um processo definido. Sommerville (2003),
define processo de software como “[...] um conjunto de atividades e resultados associados que
geram um produto de software. Essas atividades são, em sua maioria, executadas por
engenheiros de software” (SOMMERVILLE, 2003, p. 7).
Nesse sentido, ao pensarmos em um produto final, ou seja, o software, devemos ter
claros os envolvidos no processo, bem como a melhor maneira de executa-lo. Pressman (2002),
afirma que:
Software de computadores é o produto que os engenheiros de software
projetam e constroem. Abrangem programas que executam em computadores
de qualquer tamanho e arquitetura, documentos que incluem formas impressas
e virtuais e dados que combinam números e texto, mas também incluem
representações de informação em figuras, em vídeo e em áudio (PRESSMAN,
2002, p. 3).
Outra definição de software que vale apresentar, visto que descreve o mesmo de uma
forma mais abrangente, é a apresentada por Sommerville (2003):
Muita gente associa o termo software aos programas de computador. Na
verdade, essa é uma visão muito restritiva. Software não é apenas o programa
mas também toda a documentação associada e os dados de configuração
necessários para fazer com que esses programas operem corretamente
(SOMMERVILLE, 2003, p. 5).
A partir das definições de processo de software, bem como software, podemos
verificar que para chegar a um produto final de qualidade, devemos buscar seguir as etapas
consideradas fundamentais. Isso somente é possível tendo bem definidas todas as etapas do
processo, que levam a um resultado final de alta qualidade. Com base nisso, podemos imaginar
que construir programas de computador respeitando um processo bem definido, nos leva a um
produto final de sucesso (PRESSMAN, 2002).
12
Vislumbrando chegar a um processo final de qualidade, qual o processo de
desenvolvimento de software utilizaremos para atingir tal meta? Ou então existe uma
metodologia ideal, bem definida, e que leve o desenvolvimento ao sucesso? Essas questões
ainda persistem na engenharia de software. A missão desta, que pode ser dita recente em
comparação a outras engenharias (como por exemplo, a engenharia civil), é identificar a vasta
variedade de linguagens e ambientes os quais um software de computador pode ser criado, e
estipular o melhor processo que resulte no produto final de qualidade.
Desta forma, a partir de uma breve definição dos conceitos abordados na engenharia de
software, serão apresentados os conceitos de modelagem ágil. Além de revisar as premissas do
desenvolvimento de software, será apresentada uma forma alternativa de desenvolvimento,
verificando onde é viável modelar de forma ágil. Assim, baseando-se na metodologia
tradicional, descrita a seguir, e incorporando a mesma à modelagem ágil, será buscada uma
forma de desenvolvimento que traga benefícios ao processo, e conseqüentemente ao produto
final: software de qualidade.
5.1
PRINCÍPIOS DA ENGENHARIA DE SOFTWARE TRADICIONAL
A engenharia de software tem por finalidade desenvolver um programa de computador
com qualidade. Esse produto é oriundo de um processo criativo, onde cada equipe o alcança de
acordo com o amadurecimento e definição exata do caminho a seguir. Em seu livro, Pressman
(2002) cita a definição de engenharia de software proposta por Fritz Bauer, como “[...] a criação
e a utilização de sólidos princípios de engenharia a fim de obter software de maneira
econômica, que seja confiável e que trabalhe eficientemente em máquinas reais” (PRESSMAN,
2002. p. 18).
Assim, podemos perceber que está solidez pode ser alcançada buscando de fato aplicar
os conceitos de engenharia oriundos de outras áreas ao software. Para isso, é necessário que
além de um processo bem definido, métodos e ferramentas sejam estipulados a fim de ostentar a
aplicação da engenharia no desenvolvimento de sistemas. Na Figura 1, temos o que Pressman
(2002) define como as camadas da engenharia de software, e que estipulam as áreas básicas
propostas.
13
Fonte: (PRESSMAN, 2002. p. 19)
Figura 1: Camadas da engenharia de software
Conforme observado, a engenharia de software é baseada no processo, que define um
desenvolvimento consciente e oportuno. A partir disso, temos um método, ou seja, como fazer
as atividades do processo. Por fim, as ferramentas possibilitam a execução dos métodos no
processo de forma automatizada, ou semi-automatizada (PRESSMAN, 2002).
Além disso, o processo de engenharia busca sempre foco na qualidade. Em um cenário
de desenvolvimento ideal, isso garante um produto final de alta qualidade. Porém, devido a
contratempos que ocorrem durante o ciclo de desenvolvimento, ora por processos ou métodos
falhos, ou pelo uso de ferramentas que não atendem plenamente a demanda, a qualidade fica
comprometida. Daí a importância de se ter um processo de engenharia de software bem
definido.
Nesse sentido, a seguir são apresentados os principais modelos de processo de
software, possibilitando ao leitor uma breve introdução das características de cada um.
5.1.1 Modelos de Processo de Software
Com base nos conceitos fundamentais da engenharia de software, algumas formas de
desenvolvimento apresentaram resultados satisfatórios. Dessa maneira, diante de um constante
aperfeiçoamento, as mesmas foram adotadas como modelos para desenvolvimento de
aplicativos. Sommerville (2003) apresenta algumas atividades que, indiferente do processo,
devem ser sempre consideradas:
•
especificar o software: definir as funcionalidades que o software deve contemplar,
bem como suas restrições;
14
•
desenvolvimento do software: produzir o software de forma que suas
funcionalidades sejam contempladas;
•
validação do software: isso garante que o que foi solicitado esteja contemplado no
software;
•
evolução do software: como as necessidades do cliente muda, o software também
deve ser passível de mudança.
Com base nessas diretrizes, percebemos que indiferente do software a ser produzido, é
unânime que o problema seja solucionado de maneira a satisfazer o cliente e a equipe de
desenvolvimento. Dessa forma, na Figura 2, podemos verificar o que Pressman (2002)
considera como sendo o ciclo básico de resolução de problemas, definido em quatro estágios.
Fonte: (PRESSMAN, 2002, p. 25)
Figura 2: Fases de um ciclo de resolução de um problema
Pressman também afirma que este ciclo básico pode perfeitamente se repetir dentro de
cada uma das fases do ciclo. Assim, em cada etapa temos um novo ciclo, a fim de fortalecer o
modelo proposto, como apresentado na Figura 3.
15
Figura 3: Fases dentro das fases do ciclo
Com base nessas definições básicas para um processo de engenharia de software, a
seguir são descritos de forma concisa os principais modelos de processo de software, de acordo
com Pressman (2002):
•
Seqüencial linear: também conhecido como modelo em cascata, é baseado em
uma seqüência de etapas. Inicia na análise, e avança através do projeto,
codificação, teste e manutenção. O processo é iniciado com um levantamento
dos requisitos do software. Posteriormente, tem início o processo, que engloba
os dados, a arquitetura, a interface e os detalhes procedimentais que o software
deve possuir. Finalmente o projeto é codificado, e testado posteriormente.
Como a probabilidade do software sofrer alterações é alta, a manutenção entra
como etapa final desse modelo. Esta forma de desenvolvimento é tradicional e
bastante difundida, porém, “o problema com o modelo em cascata é sua
inflexível divisão do projeto em seus estágios distintos” (SOMMERVILLE,
2003, p. 38). Em suma, é um modelo que restringe o desenvolvimento de
atividades simultaneamente, mas ainda é utilizado visto a maturidade alcançada
ao longo dos anos (é um dos primeiros modelos propostos);
16
•
Prototipagem: o modelo de prototipagem tem como principal característica
elaborar um protótipo do software logo no início do desenvolvimento. Após
um breve levantamento de requisitos, é iniciada a elaboração de um protótipo,
mesmo que inicialmente esteja longe do idealizado pelo cliente. Esse
paradigma é cíclico. Primeiro o cliente é ouvido, após o protótipo é construído
(ou então revisado/aperfeiçoado), e finalmente o cliente testa o protótipo. Feito
isso, o ciclo é novamente executado. A prototipagem apresenta algumas
desvantagens, principalmente devido ao fato do cliente utilizar o protótipo
como um software consolidado, e os desenvolvedores ignorarem requisitos
secundários, pois estão desenvolvendo apenas um protótipo. Apesar disso,
pode ser bem utilizado, desde que no início do desenvolvimento fique bem
claro para desenvolvedores e cliente que o protótipo é um meio de aperfeiçoar
os requisitos para o desenvolvimento do software final;
•
Desenvolvimento rápido: o Desenvolvimento Rápido de Aplicação (Rapid
Application Development – RAD) é um modelo derivado do seqüencial linear,
onde a partir de um correto entendimento dos requisitos, um sistema é
desenvolvido em alta velocidade (por exemplo, 90 dias). O segredo do RAD, é
dividir o problema em partes menores, e trabalhar de forma concorrente
(respeitando é claro as dependências). O RAD inicia o ciclo de
desenvolvimento com a modelagem do negócio, ou seja, como acontece o
fluxo da informação. Após acontece a modelagem dos dados, as informações
são refinadas e separadas em objetos, cada qual com seus atributos. Definidos
os objetos, na modelagem do processo são definidas as regras de negócio. Após
a modelagem, é gerada a aplicação (utilizando técnicas de quarta geração,
apresentada a seguir). Por fim, o software é testado e entregue. RAD é um
modelo que visa o reuso de componentes, bem como exige um grande número
de pessoas para projetos grandes. Quando o sistema não pode ser dividido em
módulos, ou então existirem riscos técnicos grandes, RAD não é aconselhável;
•
Evolucionários: a principal característica dos modelos evolucionários é sua
interatividade. Como os requisitos do software são constantemente alterados, é
necessário que ele evolua. Assim, modelos evolucionários devem possibilitar
17
que cada vez mais o software seja aperfeiçoado. Dos modelos evolucionários,
os que mais se destacam são o incremental e o espiral. No incremental,
conforme observado na Figura 4, o modelo seqüencial linear é combinado à
prototipagem, ou seja, o processo é repetido ao longo do desenvolvimento.
Figura 4: Modelo evolucionário incremental
Após a definição dos requisitos básicos, o que Pressman (2002) chama de
“núcleo do produto”, o desenvolvimento vai sendo incrementado e apresentado
ao cliente até chegar ao produto final. No modelo espiral, temos o software
sendo desenvolvido através de uma série de iterações. Inicialmente as iterações
geram protótipos, e cada vez chegam mais próximas do produto final. Este
modelo é dividido em várias regiões de tarefas, que podem ser observadas na
Figura 5. Podemos verificar que o processo tem início na parte externa do
espiral, e quanto mais se aproxima do centro, mais detalhado é o produto
gerado. Este modelo é considerado ideal para o desenvolvimento de softwares
grandes, e seu sucesso depende da competência no desenvolvimento desde o
começo, pois um erro nas etapas iniciais pode ser repetido ao longo de todo o
ciclo.
18
Figura 5: Modelo evolucionário em espiral
Existe ainda uma variação do modelo espiral, denominada espiral ganha-ganha.
Esse modelo visa aperfeiçoar o processo de comunicação com o cliente, onde
em cada iteração através do espiral, sejam feitas negociações entre
desenvolvedores e clientes a fim de ambas as partes saírem ganhando com o
desenvolvimento.
•
Baseado em componentes: devido a crescente utilização da orientação a
objetos1 para construir software, tornou-se necessário definir um modelo para
essa forma de desenvolvimento. O modelo baseado em componentes é
evolucionário, e utiliza-se de alguns conceitos do modelo espiral. Sua principal
característica é, a partir de componentes previamente desenvolvidos, reutilizalos no processo a fim de agilizar a construção do software. Um sistema é
modelado com base em objetos, atributos (características) de objetos, e classes
de objetos. Para isso, é utilizada a Linguagem Unificada de Modelagem
(Unified Modeling Language – UML). Esse processo garante a reutilização de
1
A orientação a objetos possui uma vasta gama de conceitos. Não é o intuito deste trabalho detalha-los.
19
classes, o que diminui consideravelmente o trabalho de desenvolvimento do
software. Porém, o sucesso desse modelo está relacionado com a qualidade das
classes utilizadas. Caso estas não sejam robustas e maleáveis, podem
influenciar negativamente no resultado final.
•
De quarta geração: esse paradigma, também conhecido como Técnicas de
Quarta Geração (Fourth Generation Techniques – 4GT), é baseada nas atuais
ferramentas de desenvolvimento, as quais permitem ao engenheiro de software,
a partir dos requisitos iniciais, gerar código de máquina automaticamente.
Dessa maneira, o trabalho de desenvolvimento diminui drasticamente. Porém,
o uso apenas do 4GT em projetos maiores, pode gerar um software com baixa
manutenibilidade, sem aceite pleno do cliente, e de difícil adaptação. Dessa
forma, é fundamental que seu uso seja mesclado com outros paradigmas, a fim
de garantir que algumas etapas do desenvolvimento continuem sendo
respeitadas. É claro que o 4GT apresenta vantagens e desvantagens, mas com a
evolução das ferramentas para esse tipo de desenvolvimento, esse paradigma já
faz parte da engenharia de software.
Após apresentar os principais paradigmas de desenvolvimento utilizados na engenharia
de software atualmente, a seguir é apresentado o conceito de modelagem ágil. Através da
introdução deste conceito, apresentando as vantagens do seu uso, será verificada a viabilidade
de aplica-la no processo de desenvolvimento de software.
5.2
MODELAGEM ÁGIL DE SOFTWARE
Ao longo das últimas décadas, inúmeros processos de desenvolvimento de software
surgiram. Com o passar do tempo, ou devido à inflexibilidade das equipes de desenvolvimento,
ou então do preconceito por parte das instituições de renome na engenharia de software,
dificultaram que formas inovadoras de modelagem se firmassem.
Esse cenário começou a mudar nos últimos nos, e uma série de fatores contribuíram
para isso. Primeiramente, as ferramentas e linguagens de desenvolvimento evoluíram
consideravelmente (acompanhando a evolução dos computadores). Isso permitiu com que cada
vez mais aplicativos automatizassem o processo de codificação. Além disso, diante dos prazos
20
cada vez mais reduzidos para o desenvolvimento de software, as empresas se viram obrigadas a
rever o processo utilizado, tendo que adapta-lo à sua realidade. Isso permitiu que novas
maneiras de desenvolvimento fossem utilizadas (AMBLER, 2004).
Outro ponto a considerar, é que o desenvolvimento de software era baseado no modelo
de produção industrial. Isso fazia com que o software resultante muitas vezes fosse de difícil
adaptação, e caso fosse necessário, o processo despendia muito tempo e dinheiro. Com isso, a
forma cética com que os desenvolvedores viam os novos paradigmas de desenvolvimento, aos
poucos foi mudando, e a idéia de desenvolvimento ágil começou a ganhar notoriedade
(ABRAHAMSSON, 2007).
O conceito de Modelagem Ágil de Software (MAS) ganhou força em meados de 1999,
quando Kent Beck apresentou o conceito de Programação Extrema (Extreme Programming –
XP)2. Para Abrahamsson (2002), “[...] o ponto de partida para muitas abordagens de
desenvolvimento ágil aconteceu nesse momento” (ABRAHANSSON, 2002, p. 9, tradução
nossa). Mais tarde, em 2001, foi criada a Aliança Ágil (Agile Alliance)3, um manifesto que
declara os principais valores da modelagem ágil.
Nesse sentido, Ambler (2004), afirma que a MAS não define um processo detalhado,
mas sim apresenta diretrizes para se criar um modelo eficiente, conforme podemos observar:
A modelagem ágil é uma metodologia baseada na prática para modelagem e
documentação eficazes de sistemas baseados em software. É um conjunto de
práticas guiado por princípios e valores para profissionais de software
aplicarem em seu dia a dia [...]. Em outras palavras, não define procedimentos
detalhados sobre como criar um determinado tipo de modelo. Em vez disso,
fornece conselhos sobre como ser um modelador eficiente (AMBLER, 2004,
p. 25).
Assim, busca-se entender os requisitos do software a ser desenvolvido, a fim de
encontrar a melhor forma de desenvolve-lo. Isso permite uma flexibilidade no processo, no qual
etapas são executadas de acordo com a real necessidade da equipe.
2
A Programação Extrema será abordada com mais detalhes no capítulo seis.
3
A Aliança Ágil pode ser consultada em www.agilealliance.org.
21
5.2.1 Princípios Básicos
Desenvolver utilizando a MAS não significa que o produto final será de baixa
qualidade. Segundo Abrahamsson (2002), agilidade significa a qualidade de ser ágil, destreza na
movimentação, atenção e atividade. Dessa maneira, o uso da MAS de forma correta garante um
software de qualidade, bem como permite que as equipes de desenvolvimento adaptem seus
processos a fim de conseguir maior agilidade no processo.
Para permitir uma maior agilidade no processo, a MAS engloba três princípios básicos,
de acordo com Ambler (2004):
•
permitir processo eficaz e leve, onde as melhorias são aplicadas na forma de
desenvolver as práticas de modelagem, e não aplicando paradigma previamente
definido;
•
tornar o processo ágil não significa iniciar imediatamente a codificação. Devese ter um equilíbrio entre o uso de ferramentas computadorizadas, esboços
manuais, e discussões coletivas, a fim de observar a resolução de um problema
sob diversos ângulos;
•
em equipes que já adotam alguma metodologia de desenvolvimento, é
conveniente aplicar os conceitos de MAS progressivamente. Isso permite dar
maior flexibilidade ao processo, sem perder suar características básicas.
Podemos citar, por exemplo, a aplicação da MAS em equipes que adotam o
Processo Unificado da Rational (Rational Unified Process – RUP) ou o
Processo Unificado Corporativo (Enterprise Unified Process – EUP),
ganhando agilidade na maneira de desenvolver sem mudar seu processo de
forma abrupta.
De acordo com Boehm apud Abrahamsson (2002), desenvolver software utilizando
um método pré-definido, fixo, torna o processo inflexível após o design inicial. Nesse ponto é
que a MAS pode ser útil, dando maior liberdade para a alteração das especificações iniciais
(conforme citado anteriormente, um software evolui constantemente, assim como seus
requisitos).
22
Nesse sentido, o Quadro 1 apresenta um comparativo entre a MAS e os modelos
tradicionais de desenvolvimento:
Quadro 1: Comparativo entre a MAS e os modelos tradicionais
Modelos Tradicionais
Métodos Ágeis
Previsibilidade
Adaptabilidade
Controlar Mudanças
Planejamento é contínuo
Burocráticos
Documentação essencial
Excesso de documentação
Mudanças rápidas
Enfatizam os aspectos de engenharia do Enfatizam
desenvolvimento.
os
aspectos
humanos
do
desenvolvimento.
Fonte: (COSTA FILHO, 2007, p. 3)
Podemos observar que a MAS tem seu foco voltado para a equipe de desenvolvimento.
Se for unânime entre os membros que determinada etapa não contribui para o resultado final,
nada impede que esta seja suprimida do processo. Também, caso seja conveniente utilizar
esboços manuais ao invés de ferramentas computadorizadas para modelar o software, isto é
aceitável. Por outro lado, a equipe deve ter maturidade o suficiente para verificar que
determinados procedimentos são essenciais, garantindo que futuramente não dificultem a
adaptação do software.
Para destacar a idéia de agilidade no desenvolvimento, Ambler (2004) apresenta um
exemplo simples. Suponhamos que seja necessário criar um diagrama UML demonstrando uma
relação entre Cliente e Pedido. A Figuras 6 apresenta o diagrama através de um esboço manual,
o que é utilizado em várias equipes de desenvolvimento.
23
Fonte: (AMBLER, 2004, p. 52)
Figura 6: Esboço de um Diagrama UML
A Figura 7 foi criada a partir de uma ferramenta computadorizada para modelagem, e
também mostra com clareza a relação.
Figura 7: Diagrama UML feito utilizando o software Microsoft Visio
Podemos perceber que foram utilizadas duas maneiras diferentes de demonstrar a
relação. Ambas traduzem a relação, portanto, estão corretas, diferindo apenas pelo método
24
utilizado na modelagem. Assim, a equipe de desenvolvimento deve verificar se é vantajoso
fazer a modelagem utilizando um software, ou fazendo um esboço e apresentando a equipe.
Temos a impressão de que o esboço manual é uma alternativa que demanda mais tempo. Mas
se com isso a equipe tiver maior clareza do objetivo da relação (fazendo o esboço
coletivamente), pode-se ganhar tempo no desenvolvimento.
Diante dos pontos apresentados, podemos verificar que a MAS busca encontrar um
meio termo entre os métodos tradicionais, e a crescente demanda por agilidade no
desenvolvimento. É o que Boehm (2002), afirma:
É uma tendência que o desenvolvimento de software seja um pêndulo que
oscile nos extremos. Isso porque na maioria dos casos o que necessitamos é
um equilíbrio entre a disciplina dos métodos e a agilidade [...]. É necessário
saber quanto de planejamento e agilidade é suficiente. Também é fundamental
que risco versus velocidade é outro plano a ser considerado (BOEHM, 2002,
p. 64, tradução nossa).
Assim, devemos ter em mente quais os reais benefícios da MAS, e onde ela pode ser
aplicada com sucesso. Boehm (2002) defende que:
“[...] alguns princípios da modelagem ágil podem ser utilizados com sucesso,
tais como satisfazer o cliente com foco no software, mantendo a equipe
motivada. Porém, existe o risco da equipe não estar coesa, ou não
compreender o objetivo do projeto [...]. Isso torna difícil o controle sob a
mesma, e o uso de SW-CMM facilita o controle da burocracia, principalmente
no controle do risco e na integração da equipe, sem abandonar os princípios de
agilidade” (BOEHM, 2002. p. 68, tradução nossa).
Conforme observado, temos que o uso do Modelo de Maturidade na Capacitação de
Software (Software Maturity Model Capability – SW-CMM), pode ser utilizado junto a MAS.
Para isso, devemos ter claros os valores, princípios e práticas do desenvolvimento ágil. A Figura
8 mostra esta estrutura.
25
Fonte: (ABRAHAMSSON, 2007, p.9)
Figura 8: Estrutura da MAS
5.2.2 Valores da Modelagem Ágil
Para desenvolver utilizando a MAS, é fundamental que se tenha em mente o caminho a
ser seguido. Alguns valores devem ser honrados pelos seus adeptos. Cockburn apud
Abrahamsson (2002), apresenta estes valores:
•
individualidade e interações ao invés de processos e ferramentas: a relação
entre a equipe de desenvolvimento deve sobrepor a relação e os processos
corporativos. Quanto mais próximos estiverem os membros da equipe, mais
focados estarão em atingir os objetivos. Podemos definir isso como espírito de
equipe;
•
trabalhar no software antes de detalhar a documentação: devido a constante
evolução do software, deve-se dar atenção aos testes, e a continuidade do
produto. Isso pois novas versões do produto são exigidas em intervalos de
tempo muito curtos. Assim, é mais importante ter um código conciso, simples,
e avançado tecnologicamente, destinando tempo para a documentação em um
nível mais à frente;
•
colaboração do cliente ao invés de negociação de contrato: é mais importante
manter uma boa relação com o cliente, estreitando laços e firmando parcerias,
26
do que especificar um contrato rígido. Possuir um contrato é importante para
definir o escopo do software, mas como no início, na maioria dos casos, o
cliente ainda não possui uma definição completa do seu produto, estreitar
relações é mais vantajoso. Com isso, os riscos de cancelamento do projeto
tendem a diminuir;
•
responder a mudança ao invés de seguir o plano: a equipe de desenvolvimento
deve ter permissão de efetuar alguns ajustes no software durante o ciclo de
desenvolvimento. Com isso os membros da equipe podem se preparar para
eventuais mudanças, e caso ocorram, podem assimila-las sem muita
dificuldade. Essa flexibilidade faz com que a equipe perceba que têm
importância no projeto, e que suas idéias podem ser acatadas durante o
desenvolvimento. Muitos problemas de relacionamento e insatisfação podem
ser evitados, pois nada é mais frustrante para um membro da equipe, do que ver
suas idéias sendo menosprezadas.
Podemos perceber que os valores da MAS são baseados nos recursos humanos do
projeto. Afinal de contas, é a equipe a grande responsável pelo sucesso ou não do trabalho
realizado.
5.2.3 Princípios da Modelagem Ágil
Após conceituar os valores fundamentais da MAS, é possível verificar quais são seus
principais princípios. Estes princípios são importantes, pois é baseando-se neles que a
modelagem pode atingir o sucesso esperado.
Antes de definir os princípios da MAS, é interessante observar a Figura 9, onde
Abrahamsson (2002) ilustra a aplicação de modelos de desenvolvimento, colocando nos
extremos do plano, desenvolvedores e no outro um contrato de desenvolvimento rígido.
27
Fonte: (ABRAHAMSSON, 2002. p. 19, tradução nossa)
Figura 9: Plano comparativo de modelos de desenvolvimento
Podemos perceber que quando estipulamos um contrato rígido de desenvolvimento, os
modelos tradicionais enfatizam respeitar este contrato. Por outro lado, aos desenvolvedores são
estipuladas limitações que muitas vezes amarram estes ao processo, fazendo-os perder a
motivação. McCauley apud Abrahamsson (2002), entende que é necessário definir com detalhes
o processo a fim de aproximar os desenvolvedores da forma de desenvolvimento definida.
Assim, o uso de um método ágil, bem como dos modelos tradicionais. deve ser feito após
definir os detalhes do processo. Para isso, entender os princípios básicos de como trabalhar
utilizando a MAS, permite aproximar estes extremos.
Ambler (2004), apresenta os princípios básicos da MAS:
•
inicialmente, é fundamental entender que o objetivo principal do processo é um
software de qualidade que atenda os requisitos do cliente. Artefatos e
documentação passam a não ter sentido se o produto final não atinge as
expectativas. A equipe deve ter claro que seu maior objetivo é desenvolver
software, e qualquer atividade que não auxilie no desenvolvimento deve ser
evitada caso não seja justificável;
•
o objetivo secundário é possibilitar o próximo trabalho, e esse trabalho será
uma nova versão do software, ou então, dar suporte a versão atual. Caso o
projeto inicial fracasse, é bem provável que futuramente o problema se repita.
Por isso é fundamental desenvolver uma documentação suficiente para que os
próximos envolvidos no processo dêem continuidade ao desenvolvimento. Por
isso é fundamental a comunicação dentro da equipe de desenvolvimento;
28
•
diminuir a carga de trabalho para agilizar o processo e suportar as mudanças.
Se durante o desenvolvimento existe uma variedade grande de modelos,
aumentará a documentação necessária e também o trabalho para adapta-los as
mudanças. Assim, deve-se ter o discernimento de escolher apenas o essencial.
O autor faz analogia a uma pessoa cruzando um deserto: ela deve levar um
número mínimo de suprimentos, mas caso leve-os em excesso, o peso destes
acabará resultando em seu fracasso;
•
adotar soluções simples, pois elas resolvem o problema e são fáceis de
implementar. Soluções complexas algumas vezes são necessárias, mas na
maioria das vezes são resultados de uma abordagem única, sem a busca por
soluções simplificadas. Se estratégias simples falham, as complexas também,
por isso, primeiramente optar pela simplicidade;
•
encampar mudanças é necessário, pois elas ocorrem, fazem parte do processo
mesmo em fases adiantadas do projeto. Geralmente os requisitos estipulados
pelo cliente mudam ao longo do processo, e os desenvolvedores devem estar
cientes para receber essa mudança com naturalidade. Não é permitido definir
modelos e esperar que estes sirvam em todo ciclo de vida do software. Eles
precisarão ser adaptados aos novos requisitos solicitados;
•
mudar o software incrementalmente ao invés de efetuar grandes mudanças com
menos freqüência. É preferível alterar pequenas partes do sistema
gradualmente, validando seu modelo de acordo com as necessidades do
software. Para isso é fundamental aceitar que nem sempre é possível acertar na
primeira vez. Caso não tenha acertado, corrigir mudanças menores torna-se
mais fácil;
•
modelar o software com um propósito bem definido, caso contrário a
modelagem não se justifica. Antes de detalhar um processo, documentar e
escrever código-fonte, é necessário dar um passo atrás e verificar a real
necessidade deste detalhamento. Para criar um modelo, primeiramente é
necessário estipular quem precisará deste modelo, e qual o principal motivo
para sua criação. Se o modelo for para uma equipe de desenvolvedores, antes é
29
preciso estabelecer a comunicação com os mesmos. O que realmente atende às
suas necessidades? Um modelo extenso e detalhado, ou um modelo resumido?
Esses passos evitam que a modelagem seja inválida, e até ignorados pelos
demais membros da equipe;
•
possuir mais de um modelo, visto que para cada parte do software um modelo
específico é mais adequado. É preferível utilizar diversos modelos de forma
simples para cada parte do software a tentar aplicar modelos complexos que
“representam o sistema como um todo”, mas que na verdade tornam o processo
mais lento. Para isso, é necessário ter o conhecimento das ferramentas
disponíveis, e fazer o melhor uso delas de acordo com cada situação;
•
fazer um trabalho de qualidade, pois modelar de forma ágil não significa
desenvolver de forma desleixada. Um trabalho mal feito gera um software de
difícil manutenção e atualização. Por outro lado, um trabalho de qualidade
facilita a comunicação entre a equipe e dá maior agilidade ao processo;
•
para a MAS, é fundamental que o retorno sobre uma ação atinja o resultado
esperado pela equipe. Além disso, esse retorno deve ser rápido. Isso é
fundamental, pois caso algum modelo foi compreendido de forma errônea, o
mesmo pode ser corrigido imediatamente. Essa questão é interessante pois
muitas vezes excelentes desenvolvedores tem dificuldade em documentar seu
trabalho, ou então especificar modelos. É um problema gera um aumento no
custo do software, por isso a necessidade de um retorno rápido;
•
o retorno dos clientes deve ser maximizado, afinal, é ele que investe tempo e
dinheiro no processo. A equipe deve posicionar-se no lugar do cliente, e
imaginar se realmente investiria na solução que está sendo proposta.
Esses princípios podem trazer benefícios para o desenvolvimento, desde que
respeitados e seguidos. Uma das dificuldades na adoção de metodologias ágeis, é que
desenvolvedores fazem uso apenas de alguns conceitos a fim de justificar o abandono de
algumas etapas. Isso invalida seu uso, pois a MAS não é passível de utilização para reduzir a
morosidade de outro processo sem um planejamento inicial.
30
Para que o conceito de agilidade seja aplicado a outras metodologias, é necessário
observar as dificuldades encontradas no processo. Feito isso, é fundamental utilizar os
princípios básicos da MAS a fim de garantir a sinergia. Com isso, as chances de obter sucesso
aumentam consideravelmente.
5.2.4 Modelagem Ágil na Prática
Conforme observados anteriormente, os valores e princípios fundamentais da MAS são
definidos de forma abstrata. Mostram os conceitos principais dessa metodologia mas não sua
real aplicação. É claro que seu objetivo é definir as práticas a serem adotadas, e não aplica-las.
Dessa forma, para verificar os itens especificados, a seguir são apresentadas as práticas que
permitem o sucesso da modelagem ágil.
Inicialmente, a comunicação entre a equipe deve ocorrer de forma natural. Quanto
mais próximos os integrantes do processo estiverem, melhor será usa fluência. Na Figura 10
podemos observar alguns modos de comunicação e sua efetividade.
Figura 10: Formas de comunicação propostas entre desenvolvedores
As possibilidades de comunicação atualmente são inúmeras. Cabe a equipe de
desenvolvimento chegar a um consenso da que melhor se aplique a sua realidade. Para isso,
31
muitas tecnologias de comunicação são plausíveis de uso, e algumas delas são apresentadas na
Tabela 2.
Tabela 1: Algumas das tecnologias de comunicação passíveis de utilização
TECNOLOGIA
DESCRIÇÃO
Ferramentas de
Ferramenta
modelagem colaborativa
diversos
CASE
que
EXEMPLO(S)
permitem
desenvolvedores
que Cittera (Canyon
trabalhem Blue)(www.canyonblue.com)
simultaneamente em um ou mais modelos
Describe (Embarcadero
com atualizações em tempo real.
Technologies)(www.embarcadero.com)
Ferramentas de escrita
Ferramentas de processamento de texto que NetPerfect (Corel Corporation)
colaborativa
permitem que diversas pessoas produzam um (www.corel.com)
documento
simultaneamente
com
atualizações em tempo real.
Ferramentas de discussão
eletrônico, • A lista da Modelagem Ágil
Ferramentas como correio
grupos de discussão, listas e mensagens (www.agilemodeling.com/feedback.htm
instantâneas, e salas de conversa que )
permitem a transmissão de textos
• IRCPIus (www.ircplus.com)
e outros materiais anexos.
Vídeo pessoal
Uma câmera e software são instalados em LogiTech QuickCam
sua estação de trabalho para permitir (www.logitech.com)
conversa em vídeo entre você e alguém com
uma configuração semelhante.
Ferramentas de controle
Ferramentas
de
software
usadas
para • Microsoft SourceSafe
de versões
checagem, definição e gerenciamento de (www.microsoft.com)
versões de artefatos de projeto.
• Concurrent Versions System (CVS)
(www.cvshome.org)
Ferramentas de reunião
Ferramentas que permitem a comunicação • eRoom (www.eroom.com)
virtual
entre diversas pessoas em locais diferentes.
• Click to Meet (www.cuseeme.com)
32
Independentemente da forma de comunicação escolhida, deve-se ter a habilidade de
verificar se a mesma atende aos requisitos da equipe de desenvolvimento. Com uma boa
comunicação estipulada, a MAS pode ser aplicada com naturalidade.
Outro ponto a ser considerado, é a mudança de cultura dentro da equipe de
desenvolvimento. Não se deve olhar para a MAS como uma metodologia que prega o desuso de
modelos e evita a documentação. Pelo contrário, os modelos devem ser feitos com detalhes,
mas com liberdade de utilizar várias ferramentas, desde um quadro, anotações em folhas de
papel até utilizando ferramentas computadorizadas de modelagem. Um bom modelo gera uma
documentação de qualidade (AMBLER, 2004).
Na aplicação da MAS, alguns equívocos devem ser evitados, entre eles a definição de
requisitos no início do projeto, e seu congelamento ao longo da modelagem. Um requisito não
sofrer alterações, é muito difícil atualmente. Congelar os requisitos, bem como o projeto, faz
com que a equipe construa de forma errônea, ou então, construa certo mas da maneira errada, o
que desperdiça tempo.
Outro problema comum, é considerar a modelagem de dados como a principal etapa da
modelagem. Se você está desenvolvendo um software para atender determinada necessidade do
cliente, a atenção deve girar em torno dessa necessidade. É essa a regra de negócio em que deve
estar focado o desenvolvimento. Além disso, nunca se devem considerar todos os membros da
equipe bons modeladores. Um bom programador necessita ter a humildade de admitir não ter a
habilidade suficiente para modelagem, e também que este é um passo que deve ser respeitado
no desenvolvimento (ABRAHAMSSON, 2002).
Para colocar a MAS na prática, é fundamental que seus conceitos sejam aplicados
respeitando seus valores. Algumas metodologias colocam em prática esses conceitos, e
Abrahamsson (2002) cita as seguintes:
•
Desenvolvimento Dirigido a Aspectos (Feature Driven Development – FDD);
•
Processo Unificado da Rational (Rational Unified Process – RUP);
•
Método de Desenvolvimento de Sistemas Dinâmico (Dynamic Systems
Development Methods – DSDM);
33
•
Desenvolvimento de Software Adaptativo (Adaptive Software Development –
ASD);
•
Desenvolvimento de Software de Código Aberto (Open Source Software
Development – OSS);
•
Programação Extrema (Extreme Programming – XP);
•
Crystal.
As principais características de cada uma destas metodologias são apresentadas na
Tabela 2.
Tabela 2: Metodologias de desenvolvimento ágil de software
Nome da
Pontos Chave
Metodologia
ASD
Cultura
Características especiais
Percalços Identificados
adaptativa, Organizações são vistas ASD engloba mais conceitos e
colaboração e focada no como sistemas adaptativos. culturas do que práticas de software
desenvolvimento iterativo
Cria-se
uma
rede
de
indivíduos interconectados
Crystal
Família de métodos. Os Habilidade para selecionar Poucos
princípios
s~~ao
mesmos,
variando
as de acordo com o tamanho
técnicas,
regras
e e a dificuldade do projeto
métodos
foram
os o método mais adequado especificados. É cedo para estimar
ferramentas
DSDM
Uso de restrição de tempo, Primeiro método real de Enquanto o método está disponível,
times de desenvolvimento desenvolvimento ágil, uso apenas os membros do consórcio
fortes e um consórcio para de prototipagem, e regras têm acesso para editar documentos
manter
o
método
desenvolvimento
de de
usuário
restritas: que definem o método
“embaixador”,
“visionário”
e
“conselheiro”
XP
Desenvolvimento
no
cliente,
com
focado Consecutivas modelagens Enquanto as práticas individuais
times do sistema para melhorar a são aplicadas em muitas situações,
34
pequenos
e
trabalhos performance
diários
FDD
e
reagir menos atenção é dada as práticas de
melhor a mudança
gerência
Processo de cinco etapas, Simplicidade do método, Focado apenas no design e na
com
desenvolvimento design e implementação do implementação. Precisa dar suporte
baseado em componentes sistema por características a outras abordagens
e
orientado
a
objetos. e modelagem de objetos
Iterações curtas
OSS
Desenvolvimento
Vários tipos de licenças e Não é um método por si só, mas
distribuído, geralmente o código
aberto seus princípios habilitam para um
domínio do problema é gratuitamente para todos desenvolvimento
uma competição (contra os interessados
comercial
de
software
software proprietário) do
que para fins comerciais
RUP
Modelo
completo
desenvolvimento
software
ferramentas
de Modelo de negócios e RUP não tem limitações de uso.
de completa
família
incluindo ferramentas de suporte
de
de Falta uma descrição específica de
quando mudanças são necessárias
suporte.
Focado na atribuição de
regras
Fonte: (ABRAHAMSSON, 2002, p. 92, tradução nossa)
No capítulo seguinte será dada ênfase à metodologia XP, seu surgimento, principais
conceitos, e práticas. Com isso, será possível analisar a aplicabilidade de MAS à XP. As
demais metodologias também se baseiam nos princípios de desenvolvimento ágil, mas não
serão abordadas neste trabalho.
6
PROGRAMAÇÃO EXTREMA
Após apresentar os principais conceitos de engenharia de software, bem como de
modelagem ágil, o presente capítulo abordará a Programação Extrema (XP). Com isso, será
possível analisar o desenvolvimento de forma ágil através dessa metodologia, desmistificando
alguns conceitos errôneos sobre o desenvolvimento rápido de software.
De acordo com Teles (2005), o processo de desenvolvimento de software enfrentou
algumas crises desde 1968. Com o passar do tempo, vários autores comentaram sobre essas
crises, apesar de certa ressalva em tocar no assunto. Isso pode ser observado a seguir:
Diversos autores utilizam o termo “crise do software”, embora alguns o façam
com alguma ressalva, como é o caso de Pressman (1997, p.16, tradução nossa)
que considera que “temos uma ‘crise’ que vem nos acompanhando há 30 anos
e essa é uma contradição de termos. [...] O que nós temos de fato é uma
calamidade crônica” (TELES, 2005, p.14).
Em 1994 a empresa americana Standish Group, localizada em Massachusetts,
começou a publicar o Relatório do Caos (Chaos Report), levantamento feito entre empresas de
Tecnologia da Informação (TI) referente à produção de software. Este relatório é utilizado
atualmente para medir a crise do software (TELES, 2005).
No ano 2000, o relatório mostrou que de 280 mil projetos analisados nos Estados
Unidos, 49% estavam comprometidos, 23% fracassaram, e 28% foram bem sucedidos. Se
comparados a 1994, podemos verificar que a situação melhorou, já que 53% dos projetos
estavam comprometidos, 31% fracassaram, e apenas 16% obtiveram sucesso.
Outros dados importantes dizem respeito às funcionalidades do software desenvolvido.
Em um levantamento feito pela mesma instituição no ano de 2002, foi constatado que 45% das
funcionalidades do software nunca são usadas, 19% são usadas raramente, 16% às vezes, 13%
freqüentemente, e apenas 7% são utilizadas sempre. Esse mesmo relatório também comparou
casos de sucesso e fracasso, onde diferenças consideráveis de custo foram observadas,
principalmente relacionadas à forma de desenvolvimento utilizada (JOHNSON apud TELES,
2005).
Diante dessa crise, algumas metodologias de desenvolvimento de software alternativas
começaram a ganhar maior notoriedade. Dentre estas, podemos destacar a metodologia XP,
36
proposta pelo americano Kent Beck a partir de algumas práticas que ele utilizava para
desenvolver com a linguagem de programação Smalltalk.
No ano de 1996, Kent Beck trabalhava como consultor em Smalltalk, principalmente
em questões ligadas ao desempenho dos sistemas. Ele foi chamado para reestruturar o sistema
de folha de pagamentos da empresa do ramo automobilístico Chrysler, que estava sendo
migrado para Smalltalk. Esse momento foi considerado como o nascimento da metodologia XP.
Foi nesse projeto que ele “utilizou pela primeira vez, em conjunto, as práticas que atualmente
formam a estrutura da Extreme Programming” (TELES, 2005, p. 58).
Essas práticas e valores são apresentados na Figura 11, e serão analisados
individualmente a seguir.
Figura 11: Práticas e Valores que definem a XP
A partir da descrição de cada um dos valores, e das principais práticas da XP, será
possível verificar a viabilidade de sua utilização no desenvolvimento de software atualmente.
37
6.1
VALORES DA XP
A metodologia XP é baseada em quatro valores primordiais. Eles servem como
parâmetro para o desenvolvimento, e garantem que ao final do processo os resultados sejam
atingidos. Sem essa base de valores, a tendência é que o desenvolvimento se torne
individualizado, onde cada membro se volta para seus resultados pessoais apenas, conforme
citado por Beck (2004):
Nós teremos êxito quando tivermos um estilo que contempla um conjunto
consistente de valores que servem para necessidades tanto humanas quanto
comerciais: comunicação, simplicidade, feedback e coragem [...].
Precisamos de algum parâmetro para saber se estamos no caminho certo. De
nada adiantaria inventar um novo estilo e desenvolvimento para, no final,
descobrir que não gostamos dele ou que ele não funciona (BECK, 2004, p. 45,
grifo nosso).
A seguir, os valores da metodologia XP são explanados, observando suas principais
características, e quais os fatores que possibilitam o desenvolvimento ágil de software.
6.1.1 Comunicação
A comunicação é fundamental para qualquer atividade realizada em equipe, seja em
qual for a área. No processo de desenvolvimento de software não poderia ser diferente. É
através de uma comunicação ágil que todo o processo se baseia. A definição de Eischen apud
Teles (2005) esclarece este conceito:
Como os sociólogos sabem, comunicação é intrinsecamente difícil, mediada
por códigos que são sempre contextuais, normas, culturas e percepções [...].
De um modo geral, software oferece um exercício de traduzir algoritmos
existentes – na natureza, organizações ou práticas – para a forma digital.
Grande parte deste conhecimento de domínio é tácito, indefinido, não
codificado e desenvolvido ao longo do tempo, freqüentemente sem ser
explícito até mesmo para os indivíduos que participaram do processo. Ainda
mais importante, este conhecimento e as práticas são dinâmicos, evoluindo
constantemente e se transformando (EISCHEN, 2002, p.39 apud TELES,
2005, p. 62).
Nos processos de desenvolvimento tradicional, a comunicação se dá basicamente
através da escrita. Analistas documentam e descrevem o que precisa ser feito, e programadores
executam. Em contrapartida, programadores têm dificuldade em documentar seu trabalho. A
metodologia XP dá ênfase a comunicação, e frisa a importância de faze-la de diversas formas.
38
Segundo Teles (2004), o grande problema da comunicação escrita é sua frieza, visto
que é ausente de emoções. Uma mensagem pode ser repassada com um sentido, e ser recebida
pelo leitor sob seu ponto de vista, que varia de acordo com seu estado emocional. Portanto, o
processo de comunicação deve unir a equipe. Os integrantes devem ter contatos freqüentes,
sempre visando a integridade da equipe.
Nesse sentido, XP utiliza o conceito de treinador (coach), que têm como objetivo
manter a equipe unida, resolver problemas de comunicação, e trazer o cliente o mais próximo
possível do projeto.
Sendo assim, a comunicação deve ser vista como ponto crucial para o sucesso do
projeto. Um programador não comunicar certo problema para que não ser punido, ou mesmo
um gerente reprimir seus subordinados diante de uma dificuldade não são aceitos. Evitar essas
situações garante que a equipe permaneça coesa (BECK, 2004).
Respeitando esse valor primordial da XP, a informação fluirá normalmente entre os
membros do projeto. E essa comunicação permite que as atividades sejam feitas de maneira
simples, o segundo valor da XP.
6.1.2 Simplicidade
Para Beck (2004), quando uma equipe analisa os requisitos de um projeto, seu
treinador deve fazer a seguinte pergunta: qual a maneira mais simples de se realizar essa tarefa?
Isso mostra que a simplicidade é fundamental para o sucesso de um projeto utilizando XP.
Muitos desenvolvedores têm dificuldade em responder esta pergunta. A dificuldade se
dá justamente porque desenvolver com simplicidade não é fácil. A tendência é que um requisito
seja preenchido e complementado, pois o cliente não solicitou determinada funcionalidade que
será importante no futuro. Essa forma de pensar acontece com freqüência durante os projetos, e
cabe ao treinador da equipe lembrar da importância de se pensar de maneira simples.
Simplicidade é importante, pois geralmente o cliente não está ciente de todas as
necessidades do sistema. Muitas vezes ele tem a idéia de que deve pedir tudo de uma vez, antes
que seja tarde. Isso faz com que programadores criem soluções genéricas, que vão facilitar sua
39
vida no futuro. Como isso não acontece, XP adota iterações simples, justamente para aliar o
cliente à equipe de desenvolvimento, e para evitar trabalho dispendioso (TELES, 2005).
Quando um programador busca fazer além do que foi solicitado, ele dá espaço para a
especulação. Ele parte de premissas das quais não está certo, e acaba deixando a simplicidade
de lado, pois sua certeza aumenta a complexidade do projeto e dificulta a comunicação. Isso
acontece durante o processo, ou porque a comunicação falha, ou então pela dificuldade do
programador em aceitar uma solução mais simples proposta por outro membro do time. Mas
para fazer um trabalho simples, humildade é fundamental durante o desenvolvimento, conforme
ilustrado por Beck:
Uma pessoa para quem eu estava prestando consultoria decidiu que
precisávamos de um diálogo de exibição de texto para uso geral [...].
Poderíamos fazer a classe e a interface conhecidas e, quando necessário,
faríamos a interface mais inteligente. Eu não consegui convencer o
programador, e ele gastou dois dias fazendo o código. No terceiro dia, até os
requisitos dele tinham mudado, e ele já não precisava mais daquela parte. Dois
dias-homem foram desperdiçados em um projeto que já estava apertado
(BECK, 2004, p.46).
Assim, XP busca atender apenas o que foi solicitado, esperando um retorno por parte
de quem solicitou. Com isso, busca-se chegar a solução mais simples possível, sem o excesso
de sofisticação que pode atrasar o desenvolvimento, causar problemas futuros, e o que é pior,
não serem aproveitados (ASTELS, 2002).
6.1.3 Feedback
O retorno (feedback) é o terceiro valor da XP. Ele é de fundamental importância, seja
na etapa de codificação, onde o programador deve efetuar testes em cada trecho de código
(testes unitários, abordados no Capítulo 7), seja na comunicação com o cliente, verificando se
os requisitos foram atendidos de forma simples e eficaz. Para Beck (2004), feedback é
inestimável, já que “otimismo é uma doença profissional da programação. Feedback é o
tratamento” (BECK, 2004, p. 47).
A parte mais difícil no desenvolvimento de um sistema é entender de fato seus
requisitos. Isso porque também é difícil para o cliente expressar o que necessita. Portanto, XP se
baseia fortemente em um retorno contínuo, a fim de aproximar os requisitos da solução
40
esperada pelo cliente, evitando erros que no futuro podem comprometer o projeto. Para se ter o
retorno esperado, é necessário simplicidade e comunicação. E isso esse ciclo é aperfeiçoado a
partir de um feedback que sustente as informações do projeto.
A metodologia XP aborda o processo de produção e consumo de uma maneira
diferente das metodologias tradicionais. Ao invés de levantar requisitos, produzir o software, e
finalmente disponibilizá-lo para o cliente em etapas separadas e distintas, XP torna esse
processo mais dinâmico. O software é feito com base nas estórias obtidas na comunicação com
o cliente. A partir delas, os principais pontos do sistema são levantados e produzidos de forma
simples, disponibilizando o sistema para o cliente e esperando o retorno. E assim o ciclo se
repete, buscando convergir os requisitos do cliente com os interpretados pela equipe de
desenvolvimento. A importância do retorno rápido pode ser observada em Teles (2005):
A psicologia do aprendizado ensina que o tempo entre uma ação e o
correspondente feedback é crítico para o aprendizado. Experimentos com
animais mostram que mesmo pequenas diferenças no tempo de feedback
resultam em enormes diferenças de aprendizado. [...] Portanto, um dos
princípios é obter feedback, interpretá-lo, e colocar o que foi aprendido de
volta dentro do sistema o mais rapidamente possível. As pessoas de negócio
aprendem como o sistema pode contribuir da melhor forma e retornam este
aprendizado em dias ou semanas, ao invés de meses ou anos. Os
programadores aprendem como fazer o design, implementar e testar o sistema
da melhor forma possível e retornam este aprendizado em segundos ou
minutos ao invés de dias, semanas ou meses (BECK, 2000, p. 37 apud
TELES, 2005, p. 60).
O sucesso dessa forma de desenvolver se dá a partir do feedback em todas as etapas.
Desde o retorno durante a codificação (através de testes), que geram resultados em horas, ou
dias, até o retorno por parte de envolvidos no projeto, que podem vir após semanas ou até
meses. Para que o processo de aprendizado da equipe seja maior, o retorno deve ser
maximizado (TELES, 2005). O ciclo de desenvolvimento utilizando XP, pode ser observado na
Figura 12.
41
Figura 12: Ciclo de desenvolvimento utilizando XP
A partir de estórias levantadas pelo cliente, são definidos os requisitos a serem
implementados na iteração, e os que ficarão para a(s) próxima(s). O desenvolvimento é baseado
na revisão contínua, e a versão resultante é apresentada para o cliente. Através do seu feedback,
versões atualizadas são feitas até se chegar a uma versão final.
Para que esse ciclo de desenvolvimento funcione de forma correta, é necessário agir
com confiança, sem medo de falhas. Esse é o quarto valor da XP.
6.1.4 Coragem
Devido à XP ser uma metodologia que aborda o desenvolvimento sobre outro aspecto,
desafiando em certos pontos as metodologias tradicionais, ter coragem no projeto é
fundamental. Isso pois muitas vezes é necessário tomar decisões durante o processo que podem
parecer erradas, mas acabam se mostrando valiosas. Um exemplo é analisar determinado código
e decidir se vale à pena continuar no mesmo, ou é necessário fazê-lo novamente, de forma mais
simples e eficaz.
42
Segundo Teles (2005), XP parte do princípio que problemas de fato irão ocorrer, e a
equipe deve estar preparada para superá-los sem traumas. Iterações curtas permitem que a
equipe de desenvolvimento tenha mais coragem em tomar decisões de risco, visto que caso
problemas ocorram, o processo pode ser revisto, bem como o custo do erro para o cliente não é
tão alto.
Um dos mecanismos adotados pela XP para afastar o medo de cometer erros, é o
processo de testes automatizados de software. Essa proteção permite que a partir de testes
incessantes em unidades menores de código, programadores fiquem mais confiantes. É claro
que os testes podem falhar, mas são muito úteis na detecção de eventuais erros que possam vir a
ocorrer no processo (BECK, 2004).
Outro ponto a considerar é o medo que alguns desenvolvedores têm quando engajam
no projeto. Eles temem não se adaptar a equipe, ou então não atender às expectativas. Por isso a
metodologia XP adota a programação em pares. Isso permite que ambos aprendam e evoluam
tecnologicamente, bem como corrijam os erros uns dos outros. Além disso, o processo de
comunicação é fortalecido, e a busca pela simplicidade é feita sob mais de um ponto de vista
(geralmente não notamos nossos próprios erros na codificação).
Com base em Teles (2005), o Quadro 2 apresenta os principais temores que atingem os
desenvolvedores e clientes.
Quadro 2: Temores a serem superados com uso da XP
Temores no Processo de Desenvolvimento de Software
Desenvolvedores
Clientes
Fazer mais do que sabem fazer;
Não obter o que pediram;
Fazer coisas que não têm sentido;
Pedir a Coisa errada;
Ficarem defasados tecnicamente;
Pagar demais por muito pouco;
Receberem responsabilidades sem autoridade;
Jamais ver um plano relevante;
Não receber instruções claras do que deve ser feito;
Não saber o que está acontecendo;
Resolver problemas complicados sem ajuda e
tempo.
Fixarem-se em suas decisões iniciais e não reagir a
mudanças nos negócios.
Fonte: (TELES, 2005, p. 68)
43
Os temores encontrados durante o desenvolvimento são comuns em diversos projetos.
Deve-se utilizar uma metodologia que procure solver, ou então minimizá-los ao máximo a fim
de obter sucesso no projeto. Através da simplicidade e de uma comunicação bem estabelecida, é
possível ter coragem para obter sucesso no projeto. Enfim, é necessário colocar os valores
apresentados em prática.
6.2
PRÁTICAS
A metodologia XP possui uma série de práticas derivadas de seus valores. Essas
práticas definem seu uso, sendo possível desenvolver software de forma ágil e de qualidade. Na
Figura 13 são apresentadas as práticas da XP definidas por seu criador, Kent Beck.
Fonte: (MEDEIROS, 2007)
Figura 13: Práticas da XP
Conforme observado, práticas da XP são aplicadas aos programadores, equipes de
desenvolvimento do projeto e também a nível organizacional. As doze práticas principais da XP
serão descritas a seguir.
44
6.2.1
Mantendo a Proximidade com o Cliente
Um dos paradigmas do desenvolvimento de software tradicional é que o cliente não
precisa, ou até mesmo não deve estar presente durante o processo de desenvolvimento. A
metodologia XP procura acabar com esse paradigma, fazendo com que a presença do cliente
seja de vital importância para o sucesso do projeto. O feedback que o cliente fornece e parte
essencial de uma iteração. É ele quem decide o que é mais importante para cada etapa, e valida
o trabalho realizado (CARDOSO, 2006).
Beck (2004), define essa atividade como on-site costumer, ou seja, o cliente junto à
equipe de desenvolvimento. Por cliente entende-se o usuário do sistema, e não a pessoa que
“comprou” o mesmo. É este cliente que deve estar envolvido com o projeto, corrigindo a equipe
em caso de interpretações equivocadas dos requisitos e propondo melhorias.
É claro que a situação ideal é o cliente sempre estar junto à equipe de
desenvolvimento. Mas muitas vezes isso não é possível. Dessa forma, deve-se buscar uma
proximidade que permita ao cliente continuar fornecendo um feedback rápido, conforme
afirmado por Teles (2005):
Ter especialistas de domínio à disposição o tempo todo significa que o tempo
de feedback entre a solução ser imaginada e depois avaliada é o mais curto
possível, freqüentemente de minutos ou algumas poucas horas. Tal rapidez no
feedback significa que a equipe de desenvolvimento ganha uma compreensão
mais profunda das necessidades e hábitos dos usuários e comete menos erros
quando cria novas idéias [...] (COCKBURN, 2002, p. 179 apud TELES, 2005,
p. 72).
Com o cliente presente, a equipe ganha confiança durante o desenvolvimento. Ao
mesmo tempo, o cliente tem a certeza de que a equipe está realmente disposta a fornecer um
produto de qualidade. Esta proximidade é importante, pois o software é um produto intangível,
e seus custos são oriundos principalmente da prestação de serviços, e não de matéria prima –
por isso que XP não aceita o conceito de fábrica de software (TELES, 2004).
A presença do cliente gera um ambiente que Beck (2004) define como sala de guerra
(war room). O ambiente é compartilhado entre cliente e os desenvolvedores, e permite que o
primeiro observe o processo de desenvolvimento, propondo correções de acordo com a
necessidade. É como conduzir um carro (software) em uma estrada reta (projeto). Se não forem
45
feitas pequenas correções na trajetória do carro, o mesmo tenderá a sair da pista (devido às
irregularidades da mesma). Por outro lado, se movimentos bruscos forem feitos, a viajem será
desagradável, correndo o risco de acontecer um acidente (cancelar o projeto).
Dessa forma, é necessário quebrar o paradigma de que o cliente presente gera
transtornos. Essa é a visão tradicional dos desenvolvedores, que deve ser mudada
gradativamente. Por outro lado, o cliente deve ser conscientizado que para se chegar ao produto
final que ele almeja, suas constantes interações com o projeto são fundamentais. Assim, em
caso de percalços durante o processo, este terá a consciência de que certas mudanças no
planejamento do software são necessárias, e seus custos se justificam.
6.2.2
Planejando o Software
Tomar a decisão do que deve ser implementado em um software é uma das escolhas
mais difíceis a serem feitas por uma equipe de desenvolvimento. Dessa forma, planejar e definir
o que é realmente útil para o cliente é de fundamental importância. Teles (2005), apresenta um
estudo sobre as funcionalidades de um sistema feito pelo Standish Group Internacional:
Tempo é o inimigo de todos os projetos. Visto que o escopo impacta na
duração do projeto, ambos estão associados. Minimizando o escopo, o tempo é
reduzido e portanto as chances de sucesso crescem. A conceito de triagem é
fundamental para o desenvolvimento [...]. As funcionalidades de um sistema
podem ser categorizadas em “tem que ser feita”, “deveria ser feita” e “poderia
ser feita”. Cabe aos membros do projeto assegurar que as funcionalidades que
têm que ser feitas sejam implementadas em primeiro lugar (TELES, 2005, p.
74).
Conforme observado, definir o que é necessário fazer é vital para o sucesso do projeto.
Para isso, XP adota estórias escritas pelos clientes para definir o desenvolvimento. Estórias são
descrições breves de requisitos do sistema escritas em pedaços de papel. Sua escrita deve ser
simples, mas não existem regras pré-definidas (BECK, 2004).
Em um primeiro momento essa atividade pode parecer estranha, mas Teles (2004),
aponta algumas vantagens dessa atividade:
•
no momento em que escreve a estória, o cliente tem a necessidade de pensar
melhor nos requisitos, definindo com maior clareza as funcionalidades
necessárias e sua importância;
46
•
como ele é quem escreve, um vínculo é criado entre cliente e requisito. Isso
cria uma responsabilidade maior pelos seus pedidos;
•
através dos cartões, o cliente percebe que atender cada um de seus requisitos
gera um custo para o projeto. Assim ele procura solicitar os requisitos
fundamentais, e tem a noção do real valor do software;
•
através dos cartões a equipe mostra que o cliente é importante no processo de
desenvolvimento.
Com base nas estórias apresentadas pelo cliente, é possível à equipe de
desenvolvimento estimar o escopo do software e definir prioridades. Essas estimativas podem
ser feitas por comparação, analisando os cartões mais importantes, ou com funcionalidades
semelhantes, ou através de reuniões, onde a possibilidade de acerto é maior (KOCK, 2007).
Essas reuniões permitem que a equipe defina os rumos do projeto, e como XP se
baseia na comunicação honesta entre os envolvidos, a presença do cliente é fundamental.
Planejar sem o cliente pode parecer a melhor escolha, evitando que ele conteste prazos ou
prioridades. Porém, futuramente isso poderá gerar conflito entre as partes. Conscientizar o
cliente dos prazos do projeto deve ser um dos primeiros passos do planejamento.
O planejamento é feito através de realeses, que duram alguns meses, e buscam atender
algumas funcionalidades definidas pelo cliente. Ao final de cada iteração, o software é entregue
para o cliente, aguardando um retorno sobre o mesmo.
Por exemplo, em um projeto de oito meses, divide-se o mesmo em quatro realeses de
dois meses cada. Dentro desse período existe uma série de iterações que duram semanas, cada
uma com tarefas diárias, conforme observado na Figura 14.
47
Figura 14: Exemplo de Releases, Iterações e Tarefas em um projeto de oito meses
Pode-se observar que a partir de um release, uma série de iterações são estipuladas,
nesse caso, quatro iterações de duas semanas. Dentro dessas iterações as também tarefas são
definidas. Definir e manter essa organização permite um melhor planejamento do projeto.
Durante o desenvolvimento podem acontecer dificuldades técnicas na implementação
de estórias definidas pelo cliente. Ele pode considerar determinado requisito importante, mas
este requisito só pode ser implementado após outro, que no seu ponto de vista era menos
importante. Diante disso, os desenvolvedores devem deixar claras as dificuldades técnicas
encontradas, e procurar apresentar o software incrementalmente (BECK, 2004).
Para isso, XP adota um quadro de acompanhamento diário de atividades que rege o
planejamento, pois ele é responsável por “determinar a velocidade da equipe em uma iteração e
a carga de trabalho que cada estória efetivamente consumiu” (TELES, 2005, p. 78). Essa
mensuração de velocidade permite estimar orçamentos a cada iteração, disponibilizando um
número determinado de horas para codificar as estórias. Com isso, é possível convergir para um
sistema desenvolvido dentro do prazo e que atenda as necessidades do cliente, conforme
afirmado por Poppendieck (2003) apud Teles (2005):
Uma boa estratégia para atingir convergência é trabalhar nos itens de mais alta
prioridade primeiro, deixando os menos prioritários irem para baixo na lista de
pendências. Entregando funcionalidades de alta prioridade primeiro, é
provável que você entregue a maior parte do valor de negócio bem antes de
48
toda a lista ser cumprida [...]. Esta abordagem para a gerência do projeto pode
parecer que irá levar a resultados imprevisíveis, mas na prática é exatamente o
oposto que acontece. Uma vez que se estabeleça um histórico de entregas de
software funcionando, é fácil projetar a quantidade de trabalho que será feito
em cada iteração à medida que o projeto avança (POPPENDIECK, 2003, p.
153 apud TELES, 2005, p. 79).
Além disso, XP adota o conceito de reunião em pé (stand up meeting), onde um dia de
trabalho deve ser iniciado através de encontros entre os membros da equipe. Isso permite
revisar o trabalho do dia anterior, identificando dificuldades e progressos, bem como traçar as
metas para o dia a seguir, definindo as estórias que serão abordadas. É claro que não é
necessário que todos estejam em pé, mas isso é aconselhável. O que é fundamental, é que estas
reuniões aconteçam todos os dias.
Através do correto planejamento, é possível estipular com maior clareza o esforço
necessário para desenvolver o projeto. Através de feedbacks constantes por parte do cliente,
bem como da priorização de estórias mais importantes, o software resultante ganhará em
qualidade e não obrigará os desenvolvedores a realizarem um grande número de horas
adicionais a cada semana.
6.2.3 Semana de 40 horas
Conforme visto anteriormente, XP procura definir os intervalos de cada etapa do
projeto. Para atender a estas etapas,
essa metodologia busca um ritmo sustentável de
desenvolvimento. Assim, é importante que os membros da equipe trabalhem oito horas diárias,
cinco dias por semana, e evitem ao máximo fazer mais do que isso. Esta é uma prática da XP
que visa principalmente manter a produtividade de seus membros constante.
Várias empresas procuram obter eficiência máxima de seus empregados. O objetivo é
mantê-los ocupados a maior parte do tempo, e através de trabalho extra, acabar o que ficou por
fazer. Isso gera resultados contrários aos esperados, pois o trabalhador se sente esgotado, e seu
rendimento cai, conforme afirmado por Teles (2005):
Utilização plena não provê nenhum valor para a cadeia de valor como um
todo; de fato, normalmente faz mais mal que bem.[...] Assim como uma
49
rodovia não consegue prover serviços aceitáveis sem alguma folga na sua
capacidade, você provavelmente não estará provendo aos seus clientes o nível
mais elevado de serviço se não tiver alguma folga em sua organização
(TELES, 2005, p. 123).
Teles (2005) ainda faz uma analogia a uma sala de servidores. Caso eles sejam usados
na sua capacidade máxima de processamento, invariavelmente seu desempenho cai, causando
problemas. Então não se deve adotar essa prática no desenvolvimento de software, pois o ser
humano também tende a produzir mais erros quando trabalha muito tempo sob pressão.
Assim, XP procura ao máximo que as horas regulamentares dos envolvidos no projeto
sejam respeitadas. É claro que existe a possibilidade dos mesmos realizarem horas-extras, mas
isso deve partir de um consenso da equipe, e não simplesmente de um desejo do responsável
pelo projeto (TELES, 2005).
Para evitar a necessidade de trabalho extra, o processo de refinamento dos requisitos
deve ser bem executado. Assim, ao notarem-se sinais de cansaço da equipe, é possível
estabelecer as prioridades, dando maior flexibilidade a outras etapas.
6.2.4 Programação em Pares
Outra prática peculiar da XP é a programação em pares (pair programming), na qual
os desenvolvedores não devem trabalhar sozinhos, mas sempre em pares. Isso visa reduzir as
falhas do projeto, pois ambos além de desenvolverem, ficam responsáveis pela inspeção e
revisão de todo o trabalho produzido. Dessa maneira, existe um condutor, que faz a codificação,
e um navegador, que revisa e atua como um estrategista (SILVA, 2005).
Sob o ponto de vista tradicional, duas pessoas trabalharem juntas pode parecer
desperdício de mão de obra e tempo. Mas na XP isso não é verdade, já que ambos trabalham em
equipe a fim de produzir mais resultados em menor tempo. Além disso, é comprovado que na
maioria das vezes o olho tende a ver o que espera ver. Assim, um programador comete erros
que não enxerga, pois seu objetivo é fazer um código irretocável, mas outra pessoa enxerga seus
erros em apenas alguns segundos (TELES, 2005).
50
O fato de uma pessoa estar digitando e a outra não, não significa que apenas uma está
programando. Muito pelo contrário. Teles (2004) afirma que os resultados obtidos em curto
prazo são praticamente iguais para equipes que programam em par ou individualmente. O que
surpreende é que em longo prazo os pares apresentam melhores resultados, seja pelo menor
desgaste dos envolvidos, ou pela qualidade do código, com menos erros.
Para se programar em pares, alguns quesitos devem ser atendidos, conforme afirmado
por Beck (2004):
•
um programador deve pressionar o outro, ou seja, mantê-lo focado no
problema a ser resolvido. Isso é vantajoso pois um programador na despende
muito tempo fazendo atividades pessoais (lendo e-mails, conversando), e
também porque diante de uma situação onde um programador “empaca”, o
outro pode auxiliá-lo;
•
durante o dia os programadores devem fazer um revezamento, garantindo que
os dois trabalhem ora como condutores, ora como navegadores. Isso garante
que ambos se habituem com o código, mas não se sintam donos deste;
•
o conhecimento técnico deve ser disseminado. Isso garante que programadores
iniciantes aprendem sobre o modo de trabalho com os mais experientes, bem
como os experientes aprendam novas tecnologias com programadores mais
novos;
•
um novo programador deve possuir um par, e não deve iniciar na empresa
apenas lendo as informações documentadas previamente. Enquanto a
documentação é estática, um par de trabalho pode integrar um membro a
equipe mais rapidamente;
•
o ambiente deve permitir que duas pessoas ocupem a mesma mesa de forma
confortável. Pouco espaço pode prejudicar o desempenho dos pares;
•
os membros da equipe devem ter humildade e paciência. Humildade para
admitir quando a solução proposta pelo colega é melhor, e paciência para
51
trabalhar em equipe, pois muitas vezes tem-se a impressão de que sozinho faria
as coisas mais rapidamente;
•
evitar o clima de competição, pois isso seria muito prejudicial à programação
em pares, e também para a XP como um todo.
Através da programação em pares, o trabalho de revisão do código acontece
naturalmente, ao longo do trabalho. Assim, ele deixa de ser uma etapa maçante do processo.
Além disso, duas pessoas pensando junto, aumentam a gama de soluções para um determinado
problema.
6.2.5 Código Coletivo
A idéia de código coletivo complementa a prática de programação em pares. Se a
equipe trabalha em duplas, e essas duplas mudam com o passar do projeto, é natural que os
programadores visualizem a grande maioria do código. Dessa forma, todos podem fazer
alterações no código sem serem repreendidos. Tratando o código como propriedade coletiva faz
com que o programador pense duas vezes antes de escrever um código complexo, pois sabe que
ele será usado por todos os membros da equipe, conforme afirmado por Beck (2004):
A propriedade coletiva do código tem a tendência de evitar que códigos
complexos entrem no sistema em primeiro lugar. Se você sabe que outra
pessoa irá olhar para o que você está escrevendo dentro de pouco tempo (em
algumas horas), você irá pensar duas vezes antes de colocar no sistema uma
complexidade que você não conseguirá justificar (BECK, 2004, p. 99).
Assim, desenvolvendo um código simples e robusto, é possível melhorar a qualidade
do software. Além disso, o código coletivo evita que sejam formadas o que Teles (2004) define
como “ilhas de conhecimento”, ou seja, apenas parte da equipe controle determinados trechos
de código. Isso resulta em um desempenho melhor mesmo que algumas pessoas faltem ao
trabalho, ou mesmo saiam da empresa, tornando a troca de integrantes da equipe menos
problemática.
O código coletivo exige coragem por parte dos programadores. É necessário que eles
alterem o código e saibam que o mesmo continuará funcionando. Por isso essa coletividade
depende de outras práticas, como refatoração, desenvolvimento guiado pelos testes, e adoção de
padrões, analisadas a seguir.
52
6.2.6 Padrões de Codificação
O uso de padrões de codificação é fundamental para a metodologia XP. Eles devem ser
adotados rigorosamente para permitir que a comunicação entre a equipe aconteça de forma
natural. A padronização é necessária desde de a escolha de modelos e estórias, até a
programação. É vital para o processo que os programadores padronizem o código, pois só assim
a coletividade pode ser bem aplicada.
O padrão deve ser estipulado no início do projeto, e adotado até seu final, conforme
apresentado por Ambler (2000), apud Teles (2005):
Padrões de código [...] são importantes porque levam a uma maior
consistência dentro do seu código e o código de seus colegas de equipe. Mais
consistência leva a um código mais simples de compreender, o que por sua vez
significa que é mais simples desenvolver e manter (AMBLER, 2000, p.1 apud
TELES, 2005, p. 92).
No Quadro 3, com base em Teles (2004), são apresentadas duas maneiras de escrever
determinado trecho de código, sendo ambas aceitáveis.
Quadro 3: Dois estilos de escrever código fonte
Programador 1: posiciona os colchetes no final da
Programador 2: posiciona os colchetes na linha
declaração do método
posterior à declaração do método
public int soma (int a, int b) {
return a + b.
public int soma (int a, int b)
{
}
return a + b.
}
Fonte: (TELES, 2004, p. 147)
O trecho de código apresentado consta de um método que faz a soma de dois valores
“a” e “b”. A diferença entre os dois programadores, é que um insere os colchetes após a
declaração do método, e outro na linha posterior. A definição de um padrão não diz qual é a
certa, apenas estipula qual será utilizado no projeto a fim de melhorar a comunicação.
53
Para se adotar um padrão, Teles (2004), apresenta algumas regras básicas:
•
utilizar uma identação consistente, com tabulação e posicionamento de chaves,
colchetes e parênteses bem definidos;
•
estipular onde se usar letras maiúsculas e minúsculas, pois programadores de
diferentes linguagens estão acostumados com o tipo de padrão determinado
nesta linguagem;
•
utilizar comentários claros e sucintos, evitando considerações desnecessárias.
Os comentários devem evoluir com o código, e o excesso pode torná-los de
difícil entendimento e manutenção;
•
utilizar nomes convenientes, que sejam capazes de comunicar qual o papel da
variável, classe, etc.
É claro que dificuldades podem surgir, principalmente no início do projeto. Mas os
desenvolvedores devem estar cientes que sua mudança de estilo de programação se faz
necessária para garantir o sucesso do projeto. O padrão adotado não é tão importante, mas sim,
o fato de todos o utilizarem, resultando em um design simples.
6.2.7 Design Simples
Tendo em mente que as práticas da XP se complementam, fazer um design simples
facilita a codificação coletiva, bem como a programação em pares. Através da simplicidade é
possível desenvolver apenas o solicitado, evitando premissas de que é necessário fazer algo pois
o cliente irá utilizar (BECK, 2004).
Uma das premissas em que se baseia o desenvolvimento tradicional, é apresentada por
Teles (2004):
O custo de se corrigir um problema em um software cresce exponencialmente
ao longo do tempo. Um problema que poderia ter custado um dólar para ser
corrigido se tivesse sido encontrado durante a análise pode custar milhares de
dólares para ser resolvido depois que o software já estiver em produção
(TELES, 2004, p. 151).
54
Assim os programadores tendem a analisar todas as variáveis do sistema, levantando
hipóteses sobre tudo que pode ocorrer no desenvolvimento. Mas se uma das principais
constantes de um projeto é a mudança (seja referente aos requisitos, design, tecnologia ou
equipe), Beck (2004) afirma que é necessário estar preparado para quando ela acontecer. Caso
contrário, se criam soluções para problemas que não ocorrem, e não se têm soluções para
problemas que de fato acontecem.
O design deve ser leve, simples, fazendo com que o código seja limpo e proporcione
um modelo mental imediato para quem o analisa. Sua integridade é fundamental para que um
modelo permita implementar necessidades futuras sem aumentar exponencialmente sua
complexidade. Nesse sentido, a XP propõe um gráfico de custo de mudanças com duas curvas,
conforme observado na Figura 15.
Fonte: (TELES, 2005, p. 98)
Figura 15: Gráfico de custos das mudanças proposto pela XP
De acordo com a Figura 15, mudanças críticas se fazem necessárias, e realmente
aumentam o custo. Mas a grande maioria das mudanças não deve aumentar tanto os custos ao
longo do ciclo de vida do software. Segundo Beck (2004), para que o custo de uma mudança
seja reduzido, a XP conta com os seguintes fatores do cenário de desenvolvimento atual:
•
linguagens de programação e bancos de dados melhores;
55
•
novas práticas de programação, como a orientação a objetos;
•
modernos ambientes e ferramentas de desenvolvimento;
•
computadores mais potentes.
Aliado a esses recursos, é necessário possuir uma estratégia que realmente defina um
design simples. Para isso, Teles (2004), aponta alguns passos a serem seguidos:
•
iniciar desenvolvendo testes, os quais permitem validar o que será
desenvolvido a seguir;
•
desenvolva apenas o necessário, e teste de forma incessante. Junte o que foi
feito anteriormente à nova funcionalidade, e rode os testes para garantir que
esteja funcionando;
•
o sistema não deve possuir código duplicado, deve-se optar pelo reuso;
•
trabalhar com o menor número de classes e métodos possível.
Dessa maneire é possível fazer um design simples, visando amenizar ao máximo a
curva de custos ao longo do projeto. Isso garante um produto final de menor custo, e de fácil
manutenção.
6.2.8 Refatoração
A refatoração (refactoring) é um conceito fundamental para garantir o processo de
evolução do software utilizando XP. “É o processo de fazer mudanças em um código existente e
funcional sem alterar seu comportamento externo. Em outras palavras, alterar como ele faz, mas
não o que ele faz. O objetivo é aprimorar a estrutura interna” (ASTELS, 2002, p.15).
O conceito refatoração garante que diante das mudanças necessárias no software, sua
estrutura se fortaleza,e não perca a integridade. Isso é necessário, pois a XP considera o
processo de evolução do sistema como parte integrante do processo, conforme por Poppendieck
(2003):
56
A necessidade de refatoração aparece à medida que a arquitetura evolui,
amadurece e novas funcionalidades são solicitadas pelos usuários. Novas
funcionalidades podem ser adicionadas ao código uma de cada vez, mas
geralmente elas estarão relacionadas umas com as outras e freqüentemente
será melhor adicionar um mecanismo arquitetural para dar suporte ao novo
conjunto de funcionalidades (POPPENDIECK, 2003, p. 141 apud TELES,
2005, p. 110).
Por mais que em determinado momento da refatoração o processo pareça simples, após
algumas iterações, pode-se observar que isso garante um desenvolvimento coeso, evitando ao
máximo o re-trabalho e trechos de código duplicados ou inutilizados. Assim, através de um
código claro, o ritmo de desenvolvimento e o desempenho do sistema podem ser mantidos.
Para garantir um sistema fé fácil entendimento, que concentre toda a regra de negócio
em um lugar bem definido, e que permita mudanças sem grande impacto em sua estrutura,
Teles (2005), apresenta algumas características indispensáveis:
•
simplicidade, pois com design simples o código tende a se tornar mais claro;
•
clareza, permitindo que qualquer membro da equipe tenha a capacidade de dar
suporte ao software;
•
adequação ao uso, visto que é fundamental que o software alcance o propósito
pelo qual foi criado;
•
ausência de repetição, evitando código duplicado em dois ou mais lugares;
•
ausência de funcionalidades extras, pois se a funcionalidade não será útil ao
cliente, mantê-la no código apenas aumenta sua complexidade.
É claro que fazer uso da refatoração pode dar a impressão de que o ritmo do
desenvolvimento pode diminuir. Isso pois primar por um código sempre bem feito demanda
tempo e esforço maiores. Porém, ao deixar a refatoração de lado, erros e duplicação de código
encontrados em uma fase mais adiantada do projeto fazem com que a queda na produção seja
muito maior, conforme ilustrado na Figura 16.
57
Fonte: (TELES, 2005, p. 115)
Figura 16: Gráfico comparativo da produtividade durante o desenvolvimento
Conforme observado na Figura 16, o processo de refatoração inicialmente pode
parecer diminuir a produtividade. Mas ao longo do projeto, percebe-se que seu uso gera um
software coeso, de manutenção mais fácil. Assim, seu uso se justifica, pois “Refatoração não é
desperdício; ao contrário, é um método chave para evitar desperdícios provendo valor de
negócio para os clientes” (POPPENDIECK, 2003, p. 144 apud TELES, 2005, p. 115).
6.2.9 Integração Contínua
A prática da integração contínua é a atividade de unir o trabalho feito por um par de
programadores ao código com o um todo. Ou seja, logo após terminar determinada atividade, o
par deve testar e juntar o código à versão mais recente do código coletivo em produção. Isso
deve ser feito várias vezes ao dias, visando sincronizar as atividades individuais (BECK, 2004).
Essa prática se faz necessária pois é geralmente programadores tendem a individualizar
seu trabalho. Eles buscam cumprir suas metas da forma mais rápida possível, muitas vezes
ignorando a necessidade de diferenciar as mudanças efetuadas por eles das mudanças efetuadas
pela equipe. Esse problema pode gerar código duplicado e inconsistências na integração.
58
Para solucionar esse problema, a metodologia XP faz com que os programadores
descubram os possíveis conflitos o mais cedo possível, mesmo que para isso seja necessário
reduzir o ritmo de desenvolvimento (motivo que leva a prática de programação em pares) para
garantir código de qualidade. Assim, um erro descoberto pelo par é mais fácil de se corrigir do
que vários erros descobertos na entrega do software (TELES, 2005).
Com a integração contínua garante-se que o trabalho a ser integrado é pequeno, pois
essa prática deve ser feita ao final de cada atividade ao longo do dia, conforme defende
Poppendieck (2003):
Builds4 mais freqüentes são melhores; eles fornecem feedback muito mais
rápido. Builds e testes executados durante os builds devem ser automatizados.
Se não forem, o próprio processo de build irá introduzir erros e a quantidade
de trabalho manual tornará proibitiva a execução suficientemente freqüente
dos builds (POPPENDIECK, 2003, p. 35 apud TELES, 2005, p. 117).
Garantindo uma integração consistente, onde cada parte do código é testada
incessantemente a fim de assegurar seu funcionamento, é possível desenvolver um software de
qualidade ao longo das iterações da XP. Isso leva à prática de entregas freqüentes ao cliente a
fim de obter feedback constante.
6.2.10 Entregas Freqüentes
Essa prática visa, através de releases curtos, entregar versões atualizadas do software
ao cliente ao longo do processo de desenvolvimento. Pode-se perceber que a metodologia XP
considera que os requisitos do software podem mudar, assim, a cada iteração, novas
funcionalidades são agregadas ao produto final (BECK, 2004).
Essa prática se faz necessária pois na metodologia XP é fundamental que a equipe
trabalhe junto com o cliente, e para o cliente um projeto de software é um investimento do qual
ele espera retorno. Assim, a equipe também deve ter essa visão, buscando o maior retorno sobre
o investimento do cliente. Esse retorno pode ser um aumento de vendas, maior qualidade no
fornecimento de produtos, redução de custos ou melhoria na qualidade do processo. Assim, a
4
Teles cita um Build como o processo de compilar, montar e empacotar o programa.
59
cada release a equipe deve oferecer novos benefícios ao cliente, esperando seu feedback para
continuar o desenvolvimento (TELES, 2004).
Através disso é possível obter algumas vantagens no processo. A principal delas é o
fato de melhorar o fluxo de caixa do projeto, pois diante de um retorno rápido sobre o
investimento, o cliente tende a compreender melhor onde seu dinheiro está sendo investido.
Além disso, Teles (2004) apresenta as seguintes vantagens:
•
geração de valor: diante de uma nova versão do software, o cliente percebe o
andamento do processo. Novas funcionalidades agregadas permitem que ele
forneça um feedback sobre o software. Esse retorno faz com que a equipe de
desenvolvimento reavalie e direcione o projeto, além de aumentar a confiança
do cliente;
•
gestão de risco: se existe investimento no software, existe um risco associado,
pois o software pode falhar, ou mesmo não atender plenamente às expectativas
do cliente. Com a entrega de uma nova versão, o cliente pode reavaliar suas
necessidades, e medir seus ganhos com o uso do sistema. Assim, com releases
de até dois meses, novas funcionalidades podem ser agregadas, bem como o
risco do projeto pode ser mais bem calculado;
É claro que fazer entregas freqüentes traz benefícios mas também alguns desafios a
serem superados. O fato da equipe não achar possível dividir o software é um deles. Essa visão
de fazer tudo, entregando o produto final de uma única vez deve ser evitada, pois ao mesmo
tempo em que impede várias entregas, vai contra muitas práticas da XP (TELES, 2004).
Para que seja possível visualizar o software em partes, é necessário utilizar uma
abordagem que permita aos desenvolvedores trabalhar em partes separadas do projeto tendo em
mente qual será o resultado final. Para isso, o uso de metáforas é outra prática recomendada pela
XP.
6.2.11 Uso de Metáforas
Essa prática busca utilizar artifícios e comparações que permitam à equipe transmitir a
idéia de modo que todas a entendam. Muitas vezes um membro da equipe tenta explicar
60
determinada atividade, mas não consegue ser entendido. Assim, o trabalho fica comprometido
devido à dificuldade na comunicação. Com o uso de metáforas, é possível repassar a idéia de
modo a esclarecer aos ouvintes o que realmente é necessário executar (BECK, 2004).
Com o uso de metáforas, é possível alinhar o pensamento da equipe, buscando manter
a unidade conceitual do projeto, conforme apresentado por Teles (2005):
[...] a maioria dos sistemas reflete falta de unidade conceitual [...]. Usualmente
isso se origina [...] da separação do design em muitas tarefas feitas por muitas
pessoas. [...] a integridade conceitual é a consideração mais importante do
design de um sistema. É melhor que um sistema omita certas funcionalidades
anômalas e melhoramentos, e refletir um conjunto uniforme de idéias de
design do que ter um sistema que contenha muitas idéias boas, mas
independentes e disjuntas (TELES, 2005, p. 121).
Essa unidade conceitual permite todos os membros da equipe consigam esclarecer o
que cada parte do sistema faz. Isso gera um código mais claro, coeso e de fácil manutenção.
Cada integrante pode explicar o que determinado trecho faz, justificando porque a solução
implementada agrega valor ao produto final. As metáforas permitem disseminar a compreensão
de novas idéias e conceitos (TELES, 2005).
Fazer uso de metáforas permite que a equipe de desenvolvimento abstraia conceitos do
mundo real para o sistema. Isso facilita a divisão do software em partes, aumentando o número
de releases possíveis de serem implementados e entregues ao cliente. Um exemplo claro do uso
de metáforas é a interface gráfica do sistema. É comum em um projeto que seja feito um esboço
das janelas do software. Isso permite aos desenvolvedores criar um modelo mental da interface,
abstraindo as funcionalidades necessárias para o desenvolvimento.
O uso de metáforas leva a um ponto importante da metodologia XP, a adoção de todas
as suas práticas. Esse é um bom artifício para justificá-las, pois cada uma delas possuem pontos
fracos e fortes. Teles (2004), usa a metáfora de um time de futebol. Defensores buscam evitar
gols, enquanto atacantes devem fazê-los. Teoricamente um time apenas de zagueiros não
tomaria gols, e um time só com atacantes faria inúmeros gols. Na prática isso não é verdade,
pois o sucesso do time passa por todos os seus integrantes. Da mesma forma ocorre com a
metodologia XP, seu sucesso é garantido com o uso de todas as suas práticas, conforme
ilustrado na Figura 17.
61
Fonte: (TELES, 2004, p. 166)
Figura 17: Interdependência das práticas da XP
Conforme a Figura 17, todas as práticas da XP se inter-relacionam, de maneira mais
intensa ou não. Assim deve-se ter essa metáfora em mente, de que para a metodologia obter
sucesso, é necessário respeitar essa relação. A seguir é explanada a prática de desenvolver com
base nos testes, fator indispensável no uso de XP.
6.2.12 Desenvolver com Base nos Testes
A prática de desenvolver com base nos testes é muito importante para a metodologia
XP. É através dos testes que se pode garantir releases de qualidade, resultando também em um
produto final de qualidade. O ato de testar é de grande relevância no processo de
desenvolvimento, e sustenta praticamente todas as práticas da XP. Por isso, Beck (2004) afirma
que antes mesmo de escrever algum código, é necessário escrever os testes unitários para
validar esse código.
A realidade das equipes de desenvolvimento destoa dessa prática definida pela XP.
Isso pois testes são uma parte do desenvolvimento que todos te ma consciência de sua
importância mas ninguém quer fazer. É uma tarefa considerada maçante, repetitiva e que atrasa
62
o desenvolvimento. Dessa forma o ato de testar torna-se mera formalidade, executado de forma
superficial e muitas vezes errônea. Esse fator resulta em erros consideráveis em fases adiantadas
do projeto (TELES, 2004).
Um grande problema relativo aos testes é que as equipes o deixam para o final. Assim,
os testes são feitos no software como um todo, sem observar os detalhes de cada componente, e
muitas vezes não são feitos de forma adequada, devido ao prazo apertado para o fim do projeto.
Esses erros na fase de testes podem causar prejuízos enormes, conforme exemplificado por
Teles (2005), no qual um erro no software da sonda Mars Climate Orbiter na forma de medir a
superfície do planeta Marte (misturava pés e metros), causou um prejuízo de 125 milhões de
dólares para o governo americano.
Ao estudar os testes com mais atenção , descobre-se que vários resultados podem ser
obtidos através de trechos de códigos simples. Devido a isso, é fundamental que testes sejam
feitos em cada parte de código para garantir que erros não encontrados resultem em problemas
futuros para o projeto.
Na XP esses testes são chamados de testes unitários, ou seja, “são realizados sobre
cada classe do sistema para verificar se os resultados gerados são corretos” (TELES, 2004, p.
108). Além dos testes unitários, a XP também trabalha com testes de aceitação, que são
executados para verificar a interação entre as funcionalidades do sistema. Os testes de software
serão abordados com maiores detalhes no Capítulo 7.
Após estudar os principais valores e práticas da XP, a seguir será abordado seu uso no
desenvolvimento, apresentando como desenvolver software usando esta metodologia.
6.3
DESENVOLVENDO SOFTWARE UTILIZANDO PROGRAMAÇÃO EXTREMA
Para desenvolver utilizando XP, é fundamental que todas as suas práticas sejam
utilizadas. É claro que uma equipe pode adotar inicialmente apenas algumas práticas, e aos
poucos ir adequando-se à metodologia. Porém, isso não trará os resultados esperados. Um dos
valores da XP é a coragem, valor necessário para seguir as práticas a fim de fazer uso da
metodologia como um todo.
63
Além das práticas e valores apresentados, alguns outros fatores colaboram para o uso
da metodologia, conforme apresentado por Teles (2004):
•
organização do ambiente de trabalho: o ambiente deve ser organizado de
modo a permitir que todos os integrantes da equipe tenham livre acesso,
facilitando o processo de comunicação. As populares baias devem ser evitadas,
pois dificultam o trabalho em par e a comunicação. A sala deve possuir um
mural com todos os cartões de atividades (concluídos, em desenvolvimento, e
previstos), bem como um quadro branco, utilizado para apoiar reuniões e
tomada de decisões. Outro item indispensável é um calendário (de preferência
grande), definindo as atividades diárias, semanais, e as iterações mensais. Por
fim, os membros da equipe devem ter computadores bons, bem como comida
para dar energia a equipe ao mesmo tempo em que proporciona um momento
de socialização;
•
seguir os mandamentos principais: esses mandamentos básicos consistem
em testar antes de codificar, fazer integração de código várias vezes ao dia, não
deixar a refatoração para depois e não complicar durante a codificação;
•
isolar a equipe: todos os envolvidos no processo devem manter-se isolados de
outras equipes ou de pessoas que não contribuem para o processo. Isso é
importante para a equipe manter o foco apenas no cliente e no produto final, ou
seja, o software. Um mesmo membro em mais de um projeto deve ser evitado
ao máximo.
Através de um ambiente agradável, a tendência é que a produtividade da equipe cresça.
Além disso, durante o projeto, a própria equipe deve ter autonomia para ajustar alguns dos
fatores apresentados, criando autonomia e confiança, sentindo-se parte do time. É claro que
desenvolver usando XP nem sempre é possível, pro isso a seguir são apresentados casos onde se
deve utilizá-la ou não.
64
6.3.1 Quando Utilizar ou Não Utilizar a XP
Conforme visto ao longo deste capítulo, a metodologia XP apresenta-se de forma
simples e eficaz. Contudo, aplicá-la em equipes de desenvolvimento que fazem uso de outros
processos não é fácil, e muitas vezes nem é possível. É claro que a grande maioria das
dificuldades não diz respeito a problemas técnicos, mas sim, culturais. Isso porque a quebra de
alguns paradigmas necessita uma conscientização intensa, caso contrário a adaptação da XP não
é possível. Se a equipe não estiver disposta, ou sejam necessários mais que doze
desenvolvedores no projeto, seu uso não é recomendado (BECK, 2004).
Outro ponto importante a considerar é a política da empresa que desenvolve software.
Caso essa empresa siga os princípios de fábrica de software, a metodologia XP não é
aconselhável. Isso pois esse termo denota produção em massa, seguindo o modelo industrial.
Esse modelo visa definir previamente todas as etapas de um processo e executá-las de forma
repetitiva a fim de aumentar a produção. Esse conceito não se aplica a XP, visto que se
aproxima mais do modelo em cascata, com uma série de etapas executadas umas após as outras,
planejando no início e recebendo o feedback apenas no fim do processo (TELES, 2005).
O uso da XP deve ser feito em empresas que primam por processos dinâmicos de
desenvolvimento, baseados na resposta do cliente e no aprendizado contínuo de todos os
integrantes da equipe. Portanto, de acordo com Teles (2004) o uso da XP não é recomendado
nas seguintes situações:
•
contratos de escopo fechado: como XP é um processo flexível, que se adapta
às mudanças do sistema, um escopo fechado tende a dificultar seu uso. Não o
impede, mas o fato do cliente esperar um produto final no prazo, sem
negociação, gera um desconforto entre as partes. Em suma, o cliente não será
parte do time;
•
política de premiações: caso a empresa premie individualmente seus
membros, seja por melhores resultados ou agilidade no término de tarefas, não
se recomenda o uso da XP. Isso pois a metodologia dá ênfase à coletividade, e
prêmios individuais tendem a gerar um clima de competição entre os membros
65
do projeto. As bonificações por resultados alcançados devem ser dadas a
equipe, caso seja feita a adoção da XP;
•
clientes exigem documentação e artefatos detalhados: como XP é baseada
na leveza, agilidade e flexibilidade, seu uso não é recomendado em projetos
onde o cliente quer todo o processo minuciosamente descrito. A XP não
repudia a documentação, apenas a utiliza de forma mais moderada, primando
por software de qualidade;
•
equipe alheia a mudanças: caso a equipe não esteja disposta a mudar,
consciente que esse processo exige coragem, XP não irá funcionar. Antes de
fazer a mudança, é importante observar o comportamento da equipe,
verificando se está ou não susceptível à mudança;
•
desenvolvedores de baixa qualidade: se os membros da equipe responsável
pelo desenvolvimento não forem capacitados, a adoção da XP fica dificultada.
Eles devem ter, além de um bom conhecimento técnico, um perfil profissional
que permita trabalharem em equipe, sem deixar suas vaidades superarem os
objetivos da equipe.
Além dos citados, muitos fatores podem dificultar a aplicabilidade da metodologia XP.
O que se deve ter claro na aplicação, é a conscientização, fazendo com que toda a equipe tenha
coragem para assumir o compromisso de utilizar essa metodologia. Caso isso aconteça, as
chances de empresas utilizarem a XP com sucesso cresce exponencialmente.
6.3.2 XP nas Empresas Atualmente
A utilização da XP já é notória em diversas empresas no mundo. Desde a sua criação e
aplicação na empresa Chrysler, inúmeras empresas ao redor do mundo vêm utilizando XP. Isso
mostra que essa metodologia é madura, e apresenta uma alternativa no desenvolvimento de
software para acompanhar a tendência mundial de desenvolver com agilidade e dinamismo,
com foco principalmente na produção de conhecimento (TELES, 2005).
A Tabela 3 apresenta empresas de renome mundial que fazem uso da metodologia XP
em alguns de seus projetos:
66
Tabela 3: Empresas que utilizam XP em alguns de seus projetos
Empresa
Website
37signals
http://37signals.com
Odeo
http://odeo.com
IBM
http://ibm.com
Interlegis
http://www.interlegis.gov.br
Royal Bank of Scotland
http://www.rbs.co.uk
Google
http://www.google.com
Objective Solutions
http://www.objectivesms.com.br/
Fonte: (CARDOSO, 2004, p. 3)
Conforme observado na Tabela 3, muitas empresas já fazem uso da metodologia XP. É
claro que em projetos grandes seu uso não é recomendado, mas para projetos de pequeno e
médio porte, é perfeitamente cabível.
Além disso, o uso da XP pode ser aliado a algumas metodologias tradicionais de
software, bem como agregar valor à maturidade do processo, dando maior agilidade ao
desenvolvimento. A adaptação da XP aos processos tradicionais, é um importante passo a ser
dado a fim de conscientizar os desenvolvedores de software que desenvolver com agilidade não
acarreta na perda da qualidade.
Para tornar a premissa do desenvolvimento ágil de software válida, é fundamental que
o resultado final seja de qualidade, sem erros. Esses erros podem ser evitados se o
desenvolvimento for feito de maneira correta, dando importância aos testes de software
principalmente nas iterações iniciais do processo. Os testes unitários de software serão
abordados com mais detalhes no capítulo a seguir.
7
TESTES UNITÁRIOS DE SOFTWARE COM XUNIT
Após analisar os principais conceitos da metodologia XP, no presente capítulo serão
vistos os principais conceitos de teste de software, a fim de permitir ao leitor uma visão geral
das técnicas de teste utilizadas atualmente. Após, serão abordados os testes na Programação
Extrema, com ênfase para os testes unitários. Por fim, será analisado o XUnit, framework para
testes unitários do software.
O teste de software é uma atividade presente da engenharia de sistemas durante grande
parte do projeto. Seu objetivo, por mais paradoxal que possa parecer, é encontrar falhas nos
programas desenvolvidos. Isso garante que o produto final tenha qualidade e esteja livre de
erros. Os testes são necessários pois durante a produção de sistemas são grandes as
possibilidades dos desenvolvedores falharem (pois são humanos). Assim, testar é uma forma de
garantir a qualidade do software (PRESSMAN, 2002).
Sommerville (2003) mostra que os testes são executados em duas etapas. Inicialmente
são feitos os testes de componente, onde cada parte do sistema é revisada (geralmente por quem
a desenvolveu) e após acontecem os testes de integração, onde os componentes interagem entre
si. É importante que seja feito um bom planejamento de verificação e validação do software em
desenvolvimento, definindo claramente os responsáveis pelos testes a fim de evitar erros.
Um dos grandes problemas referente à teste de software, é o fato da equipe considerar
essa atividade como secundária. O responsável pelo teste acaba executando este de má vontade,
de forma errônea e ineficiente. Isso pois ao longo do projeto não é dada muita importância aos
testes, estipulando prazos reduzidos, e métodos pré-estabelecidos que não se aplicam a todos os
casos. Devido a isso, é importante buscar uma metodologia de testes adequada, através de uma
equipe treinada e consciente da importância dos testes para o sucesso do projeto (RIOS, 2006).
Assim, a seguir serão apresentados os princípios fundamentais de testes na engenharia
de software tradicional. Dessa maneira, será possível buscar uma forma de testes eficiente que
possa dar suporte ao uso da metodologia XP no processo de desenvolvimento. Isso garante que
sua utilização seja feita de forma consistente e proveitosa, visto a importância dos testes para
esta metodologia.
68
7.1
PRINCIPIOS DO TESTE DE SOFTWARE
Os testes de software visam analisar e validar toda a lógica de funcionamento de um
programa de computador. Através de uma série de operações de entrada e saída, procuram
verificar todos os comportamentos possíveis de um sistema a fim de constatar possíveis falhas.
São executados a fim de encontrar e remover todos os erros que por ventura tenham ocorrido a
fim de entregar um produto final de qualidade. Pressman (2002), apresenta uma situação
peculiar referente aos testes:
Durante as primeiras atividades de engenharia de software, o engenheiro tenta
construir um software a partir de um conceito abstrato até um produto
tangível. Depois vem o teste. O engenheiro cria uma espécie de casos de
testes, que são destinados a ‘demolir’ o software que foi construído. De fato o
teste é um passo do processo de software que poderia ser visto (pelo menos
psicologicamente) como destrutivo ao invés de construtivo (PRESSMAN,
2002, p. 430).
Como a engenharia de software é um processo de construção, o ato de testar e corrigir
os erros cometidos muitas vezes é visto como uma punição devido ao fato do ser humano não
ser perfeito (apesar dos programadores pensarem diferente). Esse fator pode explicar porque
testar torna-se tão cansativo. Porém, para ter clara a importância de executar os testes, Rios
(2006) apresenta os objetivos dessa atividade:
•
é um processo que visa a execução de um programa a fim de encontrar erros;
•
um caso de testes tem sucesso caso tenha boas possibilidades de encontrar um
erro ainda não descoberto;
•
um teste bem-sucedido é aquele que descobre um erro ainda não descoberto.
Dessa maneira, testar não deve ser apenas uma atividade que comprove que o código
está correto. O sucesso dos testes está realmente no fato de encontrar erros, corrigindo-os e
testando novamente. Isso faz com que ao longo do desenvolvimento parâmetros de qualidade
sejam medidos, atribuindo maior ou menor confiabilidade ao software. Para testar de forma
eficiente, Pressman (2002) apresenta alguns princípios:
69
•
os testes devem se relacionar aos requisitos do cliente, pois testar significa
entregar um produto final sem erros;
•
os testes devem ser planejados cuidadosamente antes de sua execução, ou seja,
antes da geração de qualquer código, é necessário planejar e projetar os testes;
•
partir do princípio de que 80% dos erros irão ocorrer em 20% do código. Com
isso os esforços dos testes devem estar voltados para os componentes mais
importantes;
•
os testes devem iniciar nos componentes individuais do sistema, e após
progredir para a verificação e integração de todas as partes previamente
testadas;
•
testes completos são difíceis de serem feitos, haja vista a grande possibilidade
de caminhos a serem seguidos. Deve-se dar maior importância a lógica central
do programa;
•
para ser efetivo, o teste deveria ser feito por terceiros, pois é mais difícil para
quem desenvolveu encontrar erros em seu código.
Esses princípios visam garantir que os testes sejam aplicados de forma correta e eficaz,
sendo executados diversas vezes ao longo do processo de desenvolvimento. Sommerville
(2003) define os seguintes estágios dos testes de software, ilustrados na Figura 18:
•
teste de unidade: cada componente do sistema é testado de forma individual, a
fim de garantir o seu correto funcionamento;
•
teste de módulo: um módulo é um conjunto de componentes que atuam em
conjunto no sistema. O teste de módulo verifica se os componentes estão se
relacionando de maneira correta;
•
teste de subsistema: esse tipo de testa verifica a integração dos módulos do
sistema, procurando principalmente por erros nas interfaces de cada módulo;
70
•
teste de sistema: com os subsistemas testados, é necessário integrar e testar o
sistema como um todo a fim de validar seus requisitos e funcionalidades;
•
teste de aceitação: é o estágio final do procedimento de testes, onde os dados
que o cliente utilizará no sistema são fornecidos para teste. Busca exercitar o
sistema a fim de garantir que os requisitos foram cumpridos.
Fonte: (SOMMERVILLE, 2003, p. 51)
Figura 18: Testes de Software ao longo do desenvolvimento
Conforme observado na Figura 18, a partir dos testes em cada módulo do sistema,
parte-se para os testes de integração desses módulos, verificando sua relação. Por fim, o
software é testado por completo a fim de ser aprovado pelo cliente.
Tendo em mente os princípios básicos de como testar, é necessário observar o quanto é
possível executar os testes em um programa. A testabilidade de um software “é simplesmente a
facilidade com que ele pode ser testado. Como o teste é profundamente difícil, vale a pena saber
o que pode ser feito para facilitá-lo” (PRESSMAN, 2002, p. 432).
De acordo com sua complexidade, a testabilidade de um software pode ser mais fácil
ou complexa. De forma resumida, abaixo são apresentadas algumas características que levam
um software a ser testável, segundo Pressman (2002):
•
operabilidade: quanto melhor funciona, melhor pode ser testado, pois os testes
são executados sem maiores problemas;
71
•
observabilidade: é possível visualizar de forma clara os resultados de cada
teste. Dessa forma é fácil identificar saídas incorretas;
•
controlabilidade: quanto mais for possível controlar o software, mais o teste
pode ser otimizado e automatizado. Dessa forma é possível estruturar os testes
e executá-los da melhor forma possível;
•
decomponibilidade: quanto mais for possível modularizar o sistema, melhor
os testes podem ser feitos, pois podem ser executados de maneira independente
em cada módulo;
•
simplicidade: se o software for simples, mais rapidamente os testes serão
executados, pois a simplicidade facilita a geração de testes;
•
estabilidade: quanto menos alterações forem feitas, menor será o número de
interrupções durante os testes;
•
compreensibilidade: quanto maior for o número de informações referentes ao
programa, mais corretamente os testes serão executados. Para isso, é
fundamental um software compreensível e documentado.
A testabilidade de cada software pode variar, mas é fundamental que seus defeitos
sejam corrigidos. De maneira geral, o processo de detectar e corrigir defeitos no software pode
ser observado na Figura 19.
Fonte: (SOMMERVILLE, 2003, p. 377)
Figura 19: Processo de testes para encontrar possíveis erros no sistema
72
Conforme observado na Figura 19, os testes ocorrem em todas as etapas do
desenvolvimento, e sua realização deve ocorrer a partir de um projeto de testes previamente
estipulado a fim de obter melhores resultados.
De acordo com o software que está em produção, e também da fase de
desenvolvimento,
diferentes tipos de testes se fazem necessários. Diante disso, algumas
técnicas de teste são utilizadas. Estas são apresentadas de forma sucinta a seguir:
•
teste caixa-branca: esse tipo de teste visa verificar erros no código-fonte dos
componentes do software. De acordo com a complexidade do sistema, esse
teste analisa o fluxo de dados, os ciclos e caminhos lógicos, bem como executa
testes de condições. Para utilizar essa técnica, o testador deve fazer casos de
teste que compreendam todas as possibilidades de determinado componente.
Assim é possível diminuir as chances do componente se comportar de maneira
inesperada. Esse tipo de teste é importante pois existe um grande número de
caminhos lógicos na execução do componente, e todos devem se comportar de
maneira adequada. Geralmente esse tipo de teste é de responsabilidade de
quem desenvolveu o componente, e acontece com maior freqüência nos testes
de unidade e de módulo;
•
teste de caminho básico: é um tipo de teste de caixa-branca, onde o testador
deve definir um teste que executem pelo menos uma vez cada funcionalidade
ou comando do programa. Para isso usa-se um grafo de fluxo, que representa o
fluxo de controle do teste. Através dele é possível definir todos os caminhos a
serem testados, e executar os testes seguindo esse fluxograma.
•
teste caixa-preta: também denominado teste comportamental, é um teste
focado nos requisitos funcionais do software. Permite que o testador analise
todas as entradas que de fato irão ser inseridas no uso do software, verificando
como o programa se comporta. É um teste que não analisa os componentes
internos, mas sim compara se os resultados obtidos são iguais aos esperados.
Essa técnica de teste se aplica a todas as fases de teste, desde os testes unitários
até os testes de aceitação. Visa detectar erros de interface, funções ausentes,
erros no acesso aos dados, erros de comportamento, desempenho abaixo do
73
esperado e erros de entrada e saída. Dessa forma é necessário que os testes
sejam projetados para verificar se o programa atende seus requisitos de forma
satisfatória;
•
teste de particionamento de equivalência: técnica de teste de caixa-preta que
busca dividir todas as entradas a serem testadas em classes de dados, buscando
especificar um caso de testes que descubra classes de erros, reduzindo o
número de casos de teste a serem desenvolvidos.
Além das apresentadas, existem ainda outras técnicas de teste, como por exemplo teste
de performance, teste de carga, deste de usabilidade, teste de confiabilidade, teste de
recuperação, teste de ambiente, dentre outros. O uso de cada uma das técnicas deve ser feito de
acordo com as necessidades do software que está sendo testado (RIOS, 2006).
Vale ressaltar que independente do tipo de teste executado, o importante é que estes
atendam a seu princípio básico, “originar um conjunto de testes que tenha a maior probabilidade
de descobrir erros no software” (PRESSMAN, 2002, p.463). Esse objetivo pode ser alcançado
basicamente através das duas categorias fundamentais de teste apresentadas, caixa-branca e
caixa-preta.
Com base nos conceitos fundamentais de teste apresentados, a seção a seguir destaca a
importância dos testes de software na metodologia XP. O objetivo é destacar a importância dos
testes unitários de software, que como visto anteriormente, é um tipo de teste de caixa-branca.
7.2
TESTES DE SOFTWARE E A XP
Conforme apresentado no capítulo 6, a metodologia XP se baseia no desenvolvimento
guiado pelos testes. Mesmo sabendo que é necessário testar para assegurar a qualidade do
software, os desenvolvedores deixam essa etapa em segundo plano. Para evitar esse tipo de
conceito, a XP busca fazer com que os testes façam parte do processo de programação, sendo
considerados parte natural do processo de desenvolvimento. Isso possibilita que de fato os testes
alcancem os resultados esperados.
74
O processo de testes é fundamental para a metodologia XP. Ele induz a equipe a adotar
a prevenção à correção, conforme afirma Teles (2004):
Adotar o desenvolvimento guiado pelos testes é seguir o caminho da
prevenção. Você incorpora alguns hábitos que irão assegurar que o seu
software tenha uma probabilidade menor de contrair uma doença. Além disso,
funciona como um seguro, parecido com o plano de saúde. Ele protege você
caso ocorra uma enfermidade, que pode sempre acontecer, mesmo que você se
previna (TELES, 2004, p. 107).
Pensar dessa maneira é necessário por duas razões: o teste pré-definido expõe o
defeito assim que ele entra no sistema, evitando uma depuração futura, e os erros durante o
desenvolvimento aparecem assim que você faz algo incorreto, pois alterou alguma
funcionalidade previamente testada e funcionando corretamente, sendo necessário corrigir o
problema imediatamente.
Com isso busca-se reduzir ao máximo o tempo dedicado a depuração, guiando-se pelos
testes pré-desenvolvidos. É claro que desenvolver os testes previamente demanda tempo e gera
um custo adicional, mas fazendo analogia a um plano de saúde, este apresenta vantagens
quando doenças aparecem, reduzindo o valor gasto para tratá-las.
O desenvolvimento guiado pelos testes na XP, envolve dois tipos de teste: o teste de
aceitação e o teste de unidade. Estes serão apresentados a seguir.
7.2.1 Testes de Aceitação
Esse tipo de teste visa simular a interação de um usuário com o sistema, verificando se
o software se comporta de maneira adequada. São inseridas uma série de entradas, verificando
se as saídas correspondem ao esperado.
A XP recomenda que o cliente é quem deve executar os testes de aceitação, pois ele é
quem define a estória pra o desenvolvimento a cada iteração. Como muitas vezes o cliente pode
encontrar dificuldades para definir os testes, é aceitável que ele faça isso juntamente com um
desenvolvedor. Mesmo que o cliente não esteja disponível, é importante definir uma pessoa
responsável para os testes que não esteja envolvida diretamente com o código, pois será menos
tendenciosa na execução (BECK, 2004).
75
Como um conjunto de estórias é definido para cada iteração, é importante executar os
testes de aceitação ao final de cada um destes ciclos. Porém, devem ser escritos antes que a
equipe defina as funcionalidades para aquela iteração, definindo os caminhos válidos e
peculiaridades de cada estória. É “absolutamente essencial levantar os testes de aceitação no
primeiro dia da iteração” (TELES, 2004, p. 140).
7.2.2 Testes Unitários de Software na XP
Os testes de unidade devem ser escritos enquanto é feita a codificação do sistema. Na
XP é uma atividade que não é apenas mera formalidade do fim do desenvolvimento de cada
módulo, mas sim parte integrante desde a primeira etapa da codificação até a última. Com isso é
possível garantir uma melhor qualidade no trabalho desenvolvido (TELES, 2004).
De acordo com Beck (2004), é necessário escrever testes de unidade nas seguintes
situações:
•
quando a interface não é clara, tornando-se necessário implementar o teste
antes do método;
•
se a interface não é clara porém complexa, também os testes devem ser escritos
previamente;
•
caso o código escrito possa vir a se comportar de forma anômala, é necessário
um teste que verifique esse tipo de execução;
•
quando um erro é encontrado em um código já escrito, deve-se criar um teste
para detectar esse erro antes de efetuar a correção, visando isolar o problema e
evitar que ele ocorra;
•
antes da refatoração, a fim de prever os possíveis comportamentos durante esse
processo;
Para garantir ao máximo a qualidade e segurança do código, os testes na XP devem ser
feitos de forma automatizada, rodando de maneira correta ao longo do desenvolvimento. Para
isso é preciso conhecer bem o problema que pode ocorrer e definir um tipo de solução para o
76
mesmo. Assim, se o desenvolvedor precisa pensar no teste antes da implementação, ele é
forçado a entender e detalhar melhor o problema. Detendo-se no problema, o processo de
análise é aprofundado, e os testes guiarão o desenvolvimento.
Além disso, pensar em um caso de teste faz com que o programador se preocupe mais
com o design do código. Ao invés dele preocupar-se em apenas fornecer um método que retorne
o necessário, ele passa a codificá-lo da forma mais simples e adequada para quem utilizá-lo.
Assim o design final é funcional e suficientemente simples, ponde em prática o valor da
simplicidade (TELES, 2004).
Para aplicar corretamente os testes de unidade de forma automatizada, o primeiro
passo é definir para cada classe testada, outra com o objetivo exclusivo de testá-la. Além disso,
todas as classes de teste devem ser reunidas em uma, responsável pela execução de todas as
verificações do sistema de acordo com a necessidade de cada desenvolvedor. Assim, testa-se o
sistema como um todo através de classes unitárias de teste, simples e eficazes o suficiente para
evitar erros (BECK, 2004).
Para executar testes automatizados, os desenvolvedores utilizam ferramentas capazes
de facilitar a execução dessa tarefa. Assim, através de uma classe de testes implementada, esta
ferramenta apresenta o comportamento do código, apontando possíveis erros. Uma dessas
ferramentas de testes unitários é o XUnit, que será abordada na seção seguinte.
Um ponto importante a ressaltar, é o desafio de se utilizar testes unitários. Mesmo
tendo consciência da proteção que eles fornecem ao código, olhar para eles isoladamente pode
parecer trabalho perdido. Isso pois os desenvolvedores não dão real importância para os testes, e
preferem perder horas para encontrar um bug a evitá-lo. É necessário ter uma visão geral dessa
metodologia, pois em longo prazo, gera uma maior produtividade. Algumas perguntas quanto
ao uso dessa metodologia são respondidas por Teles (2004):
•
e se os testes rodarem muito lentamente? É necessário verificar se os testes
estão otimizados os suficientes, simplificados se e usam o menor número de
recursos externos, como conexões remotas e banco de dados. Testes lentos
diminuem a velocidade do projeto com um todo, e devem ser evitados;
77
•
o que fazer se não conseguir imaginar testes para uma classe? Essa é uma
dúvida que mostra a existência de alguma especificação errada na classe. Se o
raciocino para sua modelagem foi correto, tende a resultar em um teste para
mesma. Caso seja uma classe muito complexa, deve-se reunir a equipe e expor
a complexidade do teste, encontrando uma forma eficaz de testá-la;
•
como saber se foram feitos todos os testes possíveis? Para isso é necessário
adquirir experiência no processo de testes. Inicialmente, caso encontre algum
erro na integração, significa que testes foram omitidos em alguma unidade do
código, devendo ser feitos. Isso permite aprender com os testes e futuramente
identificá-los previamente;
•
o que fazer se já existe um código escrito sem testes associados a ele? Nesse
caso é necessário observar quais as partes do código que se relacionam com
esse código, e escrever testes que verifiquem as possibilidades de erro no
código e no seu relacionamento no programa. Isso parece tornar o processo de
manutenção mais lento, porém, construindo uma proteção maior no código
corrigido faz com que seu trabalho tenha maior confiabilidade;
•
o que fazer quanto aos testes de interfaces gráficas? Basicamente as interfaces
gráficas são simples de desenvolver. O programador deve ter a preocupação de
testar o modelo referente a cada interface. Quanto a esta, deve-se testar a
navegabilidade entre os itens (caixas de texto, listas, etc), e se os botões
remetem ao procedimento desejado;
•
como escrever testes para classes que acessam banco de dados? Um dos
principais pontos a considerar, é a velocidade do acesso aos dados, pois muitas
classes acessando os dados simultaneamente Pode tornar o teste demorado. O
teste deve abrir uma conexão com o banco, utilizar os dados necessários e
encerrar a conexão logo após, utilizando o menor processamento possível no
banco de dados. Uma boa solução para isso é usar classes objeto-relacionais,
que buscam os dados no banco e transformam em objetos no sistema.
78
De modo geral, qualquer parte do sistema pode ser testada, e ao adotar testes unitários
melhores resultados podem ser obtidos. Caso algumas partes sejam deixadas de lado, as chances
de sucesso são menores.
Com isso, é necessário que se tenha em mente que a XP apóia o desenvolvimento
baseado nos testes em outras práticas, como por exemplo, a programação em par. É necessário
que a equipe de desenvolvimento tenha persistência para que essa metodologia se torne hábito
ao longo dos projetos. Assim como qualquer idéia nova, seu uso depende da aceitação e esforço
de quem utiliza.
7.3
FRAMEWORK XUNIT: APLICANDO TESTES UNITÁRIOS DE SOFTWARE
O XUnit é um framework5 para testes unitários de software de forma automatizada em
sistemas construídos nas mais diversas linguagens. Sua nomenclatura refere-se a linguagem de
programação utilizada nos testes. Ele é composto da letra “X”, que indica para qual linguagem o
framework de testes foi feito, e “unit” vêm do inglês, e significa unidade ou unitário. Como
exemplo de aplicação desse framework, podemos citar o PHPUnit, versão do XUnit para a
linguagem PHP.
O conceito do Xunit foi definido por Kent Beck, o mesmo criador da XP. Surgiu no
início dos anos noventa, quando Beck estava trabalhando com Smalltalk. Foi justamente para
essa linguagem que surgiu a primeira implementação do Xunit, denominada Sunit. Por definição
é um framework de código aberto (open source), o que ajudou muito na sua difusão. Pode-se
definir Xunit como “uma ferramenta de testes unitários para software que pretendia ser um
pacote de programas/ampliações e modelos de teste para ajudar quem desenvolve projetos de
software a criar os seus próprios testes de erros” (BRANDÃO, 2007, p. 4).
5
Framework é um arcabouço é uma estrutura de suporte definida em que um outro projeto de software
pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código,
linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de
software (WIKIPÉDIA, 2007)
79
Como a idéia inicial era uma ferramenta que auxiliasse o processo de testes, esse
conceito se espalhou rapidamente. Versões do Xunit foram disponibilizadas para diversas
plataformas, e algumas delas são apresentadas na Tabela 4.
Tabela 4: Ferramentas para Testes Unitários Automatizados
Ferramenta
Linguagem ou Tecnologia de
Aplicação
Disponível em
CppUnit
C++
cppunit.sourceforge.net
Dunit
Delphi
dunit.sourceforge.net
HttpUnit
HTML
httpunit.sourceforge.net
JSUnit
Java Script
www.edwardh.com/jsunit
JUnit
Java
www.junit.org
NUnit
.Net
.sourceforge.net/projects/nunit
PHPUnit
PHP
phpunit.sourceforge.net
PyUnit
Python
pyunit.sourceforge.net
SUnit
Smalltalk
sunit.sourceforge.net
ServletUnit
Servlet
sourceforge.net/projects/servletunit
VBUnit
Visual Basic
www.vbunit.org
XMLUnit
XML
xmlunit.sourceforge.net
Fonte: (TELES, 2004, p. 306)
Conforme observado na Tabela 4, existem inúmeras implementações do Xunit, e
contemplam uma série de linguagens de programação utilizadas atualmente. Pode-se perceber
que várias linguagens utilizadas para o desenvolvimento atualmente possuem uma versão do
Xunit, como por exemplo Delphi, Java e PHP.
80
O XUnit funciona através de testes que comparam resultados obtidos em determinada
função testada com o retorno esperado por quem está testando. Assim pode-se saber com
facilidade se a implementação foi correta, ou se problemas ocorreram. Isso torna o processo de
teste unitário mais simples, e aumenta a velocidade do processo. Além disso, essa ferramenta
busca certificar o software, visto a importância do desenvolvimento ágil mas sem perder a
qualidade (BRANDÃO, 2007).
Devido a isso é possível afirmar que seu uso é viável no processo de desenvolvimento
de software, sendo possível colocar em prática os testes unitários na XP. No tópico a seguir,
será analisado o PHPUnit, destinado para testes unitários automatizados na linguagem de
programação PHP.
7.3.1 PHPUnit: Aplicando Testes Unitários de Software em PHP
O PHPUnit é um framework para testes unitários automatizados de software na
linguagem de programação PHP. Ele foi desenvolvido com base no JUnit, framework de testes
para a linguagem Java escrito por Kent Beck e Erich Gamma. Atualmente o PHPUnit está na
versão 3.1 e é gratuito, com código aberto (BERGMANN, 2005).
Efetuar testes com PHPUnit é uma nova forma de executar testes em PHP. Ao invés
de testar manualmente cada trecho de código a fim de encontrar falhas, esse framework permite
a realização de uma bateria de testes, rodando-os em trechos de código separadamente,
buscando encontrar e corrigir erros com maior eficiência (por definição, o objetivo do XUnit).
Bergmann (2005), aponta os principais objetivos do PHPUnit:
•
escrever e ler testes de forma simples, permitindo que os desenvolvedores não
se percam nos códigos de teste, e tenham facilidade em criá-los;
•
facilidade e agilidade na execução, visto que os testes são executados diversas
vezes ao longo da codificação;
•
isolamento dos testes, pois um teste não deve afetar outro (ao não ser que o
programador deseje isso);
81
•
combinação de testes; devido à necessidade de juntar testes e efetuá-los
simultaneamente para encontrar erros na interação de trechos de código.
Uma das grandes vantagens do PHPUnit é que os erros são isolados a fim de permitir
uma execução rápida dos testes. Assim é possível um feedback de testes com maior qualidade,
pois um erro encontrado no início da execução não interrompe a verificação. O processo
continua mantendo isolados os códigos onde erros foram encontrados, resultando uma melhor
performance.
Como se espera que os testes sejam refinados, testando todos os aspectos de cada
objeto, a cada falha o PHPUnit gera um relatório da falha, mas continua rodando uma série de
pequenos testes a fim de encontrar todas a falhas no sistema. Seguindo a idéia proposta por
Beck, é fundamental testar e encontrar erros ainda no design do sistema, evitando um design
pobre que pode causar problemas maiores no decorrer do projeto.
Os testes em PHP com PHPUnit devem respeitar duas regras fundamentais,
apresentas por Bergmann (2005):
•
o nome da classe de teste não deve iniciar com a palavra “Test”;
•
os nomes dos métodos de teste devem iniciar sempre com a palavra “test”;
Com base nessas regras, para implementar classes de teste, deve-se seguir os seguintes
passos:
•
criar uma instância da classe de testes pai do PHPUnit chamada “TestCase”;
•
definir um método chamado “test_simpleadd()”;
•
para checar igualdade entre os elementos testados, usar o método
“assertEquals()”, passando no resultado do método, “simpleadd()” e o objeto
esperado ;
•
criar uma instância da classe a ser testada e executar o método
“test_simpleadd()” passando o nome do método no construtor;
82
•
criar uma instância da classe do PHPUnit chamada “TestRunner”;
•
invocar o método “run()” da classe “TestRunner” passando o objeto da classe
a ser testada.
Para ilustrar esse processo, apresentando o uso do PHPUnit, toma-se como exemplo a
seguinte situação: O desenvolvedor criou uma classe chamada “OperacaoMonetaria”, e deseja
testar, entre outras operações, uma soma de valores monetários. A classe de testes a ser feita
com PHPUnit, denominada “OperacaoMonetariaTeste”, é apresentada no Quadro 4.
Quadro 4: Uso do PHPUnit em um teste de classe
1
2
3
4
5
6
7
8
9
10
11
12
class OperacaoMonetariaTeste extends TestCase {
function test_simpleadd() {
$dinheiro1 = new OperacaoMonetaria ( 12, "R$" );
$dinheiro2 = new OperacaoMonetaria ( 14, "R$" );
$esperadao = new OperacaoMonetaria ( 26, "R$" );
$resultado = $dinheiro1->add( $dinheiro2 );
$this->assertEquals( $esperado, $resultado, "Deve estar certo" );
}
};
$test = new OperacaoMonetariaTeste ( "testando simpleAdd" );
$testRunner = new TestRunner();
$testRunner->run( $test );
Fonte: (BERGMANN, 2005, tradução nossa)
Conforme apresentado no Quadro 4, pode-se verificar que na linha 1 é instanciada a
classe “OperacaoMonetariaTeste” de “TestCase” a fim de testar a classe “OperacaoMonetaria”.
Na linha 2 é criado o método “test_simpleadd()”, e nas linhas 3 à 5 são criados os objetos para
teste de adição de valores da classe “OperacaoMonetaria”. Na linha 6 a variável “resultado”
armazena a adição de “dinheiro1” e “dinheiro2”, e na linha 7 é usado o método
“assertEquals()” para verificar se a soma das variáveis resultará no valor esperado. Após a
definição da classe, na linha 12 o teste é executado através do método “run()”, passando como
parâmetro um objeto do tipo “OperacaoMonetariaTeste”, criado na linha 10.
De acordo com a quantidade dos testes, pode-se cria também um conjunto de testes,
denominado Test Suite, que pode rodar junto uma série de testes. Com base no exemplo acima,
um Test Suíte para a classe “OperacaoMonetaria” é apresentado no Quadro 5.
83
Quadro 5: Um Test Suite abrangendo um conjunto de testes
1
2
3
4
5
6
7
$teste1 = new OperacaoMonetariaTeste( "testando simpleAdd 1" );
$teste2 = new OperacaoMonetariaTeste ( "testanto simpleAdd 2" );
$suite = new TestSuite();
$suite->addTest( $teste 1);
$suite->addTest( $teste2 );
$testRunner = new TestRunner();
$testRunner->run( $suite );
Com base no Quadro 5, pode-se verificar que nas linhas 1 e 2 são criadas instâncias da
classe “OperacaoMonetariaTeste”. Na linha 3 é criado um “TestSuite”, adicionando as duas
instâncias de teste criadas nas linhas 4 e 5. Finalmente cria-se um “TestRunner” e executa-se o
mesmo (linhas 6 e 7). Assim é possível executar uma série de testes de uma única vez.
Caso o teste seja executado via linha de comando (prompt do MS-DOS por exemplo),
o resultado da execução dos testes do Quadro 5, casos bem sucedidos, podem ser observados no
Quadro 6.
Quadro 6: Resultado de Testes executados via linha de comando
1
2
3
phpunit OperacaoMonetariaTest
PHPUnit 3.1.4 by Sebastian Bergmann.
..
4
Time: 0 seconds
5
OK (2 tests)
Pode-se observar que na linha 3 aparecem dois pontos, que representam a execução
sem erros dos dois testes executados. O resultado final dos testes está na linha 5.
De acordo com o teste a ser realizado, o PHPUnit permite um conjunto de testes
personalizados. Além disso, ele engloba uma série de funcionalidades que permitem ao
desenvolvedor implementar testes com maior produtividade. Para validar seu uso em PHP, bem
como verificar suas funcionalidades, na monografia serão feitos testes com PHPUnit em
frameworks de desenvolvimento PHP, analisando sua aplicabilidade para consolidar o uso da
metodologia XP.
8
PROCEDIMENTOS METODOLÓGICOS
A presente pesquisa é aplicada ao desenvolvimento de software de maneira eficiente
em pequenas e médias equipes de desenvolvimento. O problema será abordado de forma
qualitativa, buscando a melhor forma de aplicar os conceitos da Programação Extrema nessas
equipes a fim de aprimorar o processo de confecção de software.
Em suma, visa aprofundar o estudo da Programação Extrema, explorando e
explanando seus conceitos, com ênfase nos testes unitários de software. Isso será feito através
da revisão bibliográfica da metodologia, buscando consultar obras renomadas sobre
engenharia de software tradicional, e também as que dizem respeito às metodologias ágeis de
desenvolvimento.
Após explicar os conceitos de Programação Extrema, estes serão aplicados na prática
através do uso do framework XUnit nos testes unitários de software desenvolvidos com
linguagem de programação PHP.
Por fim, será feita uma análise das vantagens do uso de metodologias ágeis de
desenvolvimento de software, bem como um comparativo das formas de desenvolvimento
utilizadas. Dessa maneira, será verificada a possibilidade de pequenas e médias equipes de
desenvolvimento utilizarem a Programação Extrema.
9
CRONOGRAMA DE AÇÃO
Abaixo segue cronograma do projeto de Monografia (Quadro 7) e da Monografia
(Quadro 8).
Quadro 7 . Cronograma do projeto da Monografia (2º trimestre 2007)
Atividades
Abr
Levantamento dos assuntos e delimitação dos temas.
Mai
Jun
Jul
X
X
X
X
X
X
Ago
X
Desenvolvimento do projeto, e início da revisão bibliográfica.
Encontros com o orientador para explanar os principais tópicos a serem
estudados.
Entrega do Projeto da Monografia.
X
Apresentação do Projeto da Monografia.
X
Com o projeto da monografia definido, é possível estipular os prazos da mesma de
forma mais detalhada, conforme apresentado no Quadro 8.
Quadro 8 . Cronograma da Monografia (2º semestre 2007)
Atividades
Jul
Ago
Desenvolvimento da revisão bibliográfica, principalmente sobre
Programação Extrema e Testes de Software
X
X
Estudar os detalhes do framework XUnit
X
X
X
X
X
Instalar o framework XUnit, a linguagem de programação PHP,
e o servidor Apache
Aplicar os conceitos estudados em um caso de teste unitário de
software em frameworks PHP
Escrever sobre os testes aplicados e os resultados obtidos
Entregar a monografia
Set
X
Out
Nov
Dez
X
X
X
X
10 ORÇAMENTO
O projeto visa o estudo da metodologia XP com ênfase em testes de software. Para
isso, fazem-se necessários os seguintes recursos:
•
livros, os quais alguns estão disponíveis na biblioteca da UNOCHAPECÓ, e outros
serão comprados pelo acadêmico;
•
artigos e outros materiais para pesquisa bibliográfica os quais também podem ser
adquiridos na biblioteca da UNOCHAPECÓ ou na Internet (acessada através dos
computadores dos laboratórios de informática da universidade ou de casa);
•
microcomputador com sistema operacional Windows ou LINUX, disponíveis nos
Laboratórios de Computação da UNOCHAPECÓ ou em casa;
•
linguagem PHP, framework de testes PHPUnit e banco de dados MYSQL instalados na
máquina do acadêmico, as quais podem ser obtidas livremente na Internet e configuradas
pelo mesmo;
•
navegador de Internet Mozilla Firefox para aplicação dos testes, o qual pode ser
adquirido também de forma livre.
11 REFERÊNCIAS
ABRAHAMSSON, P. Agile software development: Introduction, status & future. Disponível
em:
<http://www.mit.jyu.fi/opetus/kurssit/jot/2005/kalvot/agile%20sw%20development.pdf>.
Acesso em 22 jun. 2007.
ABRAHAMSSON, P. et all.. Agile software development methods: reviews and analysis.
Espoo:
VTT
Publications,
2002.
Disponível
em:
<http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf>. Acesso em 22 jun. 2007.
AMBLER. Scott W. Modelagem ágil: práticas eficazes para a programação extrema e o
processo unificado. Porto Alegre: Bookman, 2004.
ASTELS, David; MILLER, Granville; NOVAK, Mirosla. Extreme Programming: guia
prático. São Paulo: Campus, 2002.
BECK, Kent. Programação Extrema explicada. São Paulo: Novatec, 2004.
BERGMANN, Sebastian. PHPUnit Pocket Guide. New York: O’Reilly, 2005. Disponível em:
< http://www.phpunit.de/pocket_guide/index.en.php>. Acesso em 15 jul. 2007.
BOEHM, B. Get ready for agile methods, with care. Computer Magazine, Rochester, New
York,
v.
35,
n.
1,
64-69,
jan.
2002.
Disponível
<http://sunset.usc.edu/csse/TECHRPTS/2002/usccse2002-515/usccse2002-515.pdf>.
em:
Acesso
em: 26 jun. 2007.
BRANDÃO Hélder A.; et all.. Xunit como ferramenta auxiliar no desenvolvimento de
software. Disponível em <http://paginas.fe.up.pt/~aaguiar/es/notas_avaliacao_continua.pdf>.
CARDOSO A.; et all.. Programação extrema (XP) X engenharia de software. In: II
CONGRESSO SUL CATARINENSE DE COMPUTAÇÃO, 2006, Criciúma. Trabalhos
Apresentados.
Criciúma:
UNESC,
2006.
Disponível
em:
<http://www.dcc.unesc.net/sulcomp/artigos/Workshop/22004.pdf>. Acesso em: 10 jun. 2007.
CARDOSO, Carlos H. R. Aplicando práticas de Extreme Programming (XP) em equipes SWCMM nível 2. In: VI SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSO DE
Trabalhos Apresentados
88
SOFTWARE, 2004, São Paulo. Trabalhos Apresentados. São Paulo: Centro universitário
SENAC
e
Centro
de
pesquisas
Renato
Archer,
2004.
Disponível
em:
<http://www.simpros.com.br/simpros2004/Apresentacoes_PDF/Artigos/Art_05_Simpros2004.
pdf>. Acesso em 22 jun. 2007.
COCKBURN, A. Writing effective use cases: the crystal collection for software professionals.
Boston: Addison-Wesley, 2002.
COSTA
FILHO,
Edes
G.
Métodos
ágeis.
Disponível
em:
<http://www.dc.ufscar.br/~junia/MetAgEds.pdf>. Acesso em 22 jun. 2007.
DALCIN, Sabrina B ; DIAS, Adriane P ; DORNELLAS, Marcos C. Aplicando testes em XP
com o framework JUnit. Journal of computer Science INFOCOMP, Lavras, v. 5, n. 3, p. 6875, set. 2006. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v5.3/art09.pdf>.
KOCH,
Alan
S.
CMM
and
a
compliant
XP.
Disponível
em:
<http://www.askprocess.com/Articles/CMM-XP.pdf>. Acesso em: 15 jun. 2007.
MEDEIROS, Manoel P. Junit: Implementando testes unitários em Java. Disponível em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=1432>. Acesso em: 10 jul. 2007.
PRESSMAN, Roger S. Engenharia de software. Rio de Janeiro: McGraw-Hill, 2002.
RIOS, Emerson. Análise de riscos em projetos de teste de software. Rio de Janeiro: Alta
Books, 2006.
SILVA, Alexandre F.; KON, Fábio; TORTELI, Cícero. XP south of the equator: an experience
implementing XP in Brazil. In: 6TH INTERNATIONAL CONFERENCE ON EXTREME
PROGRAMMING AND AGILE PROCESSES IN SOFTWARE ENGINEERING, 2005,
Sheffield, Inglaterra. Proceedings. Sheffield, Inglaterra: Sheffield University, 2005. p. 10-18.
Disponível em: <http://www.ime.usp.br/%7Ekon/papers/xp2005.pdf>. Acesso em: 25 jun.
2007.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison-Wesley, 2003.
89
TELES, Vinícius M. Extreme Programming: aprenda como encantar seus usuários
desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec, 2004.
TELES, Vinícius M. Um estudo de caso da adoção das práticas e valores da Extreme
Programming. 2005. 179 f. Dissertação (Mestrado em Informática) – Universidade Federal do
Rio
de
Janeiro
–
UFRJ,
Rio
de
Janeiro,
2005.
Disponível
em:
<www.improveit.com.br/xp/dissertacaoXP.pdf>. Acesso em 20 jun. 2007.
WELLS,
Don.
Extreme
Programming:
a
gentle
introduction.
Disponível
em:
<http://www.extremeprogramming.org>. Acesso em: 14 abr. 2007.
WIKIPÉDIA. Framework. Disponível em: <http://pt.wikipedia.org/wiki/Framework>. Acesso
em 15 jul. 2007.

Uma abordagem em testes de software com XUnit

Transcrição

Documentos relacionados

Modelagem para Tomada de Decisão Financeira - CEFET-MG

Modelo de Fichamento ABNT

Pattern magic. A magia da modelagem

Fado Filmes – Imprensa 1

Programa Balde Cheio vai proporcionar desenvolvimento da bacia

padrão residenciais cub/m²

Resolução de Problemas, Modelagem Matemática e Tecnologias

Rhinoceros e V-Ray - Design de Produtos

Aviso de Licitação Pregão Presencial Nº 002/2016

Aviso de Licitação Pregão Presencial Nº 004/2016 Processo