trabalho 01 - es - grupo 01 - desenvolvimento Ágil de software - test driven development e...
Post on 03-Dec-2015
221 Views
Preview:
DESCRIPTION
TRANSCRIPT
TRABALHO 01 - DESENVOLVIMENTO ÁGIL DE SOFTWARE
TEST DRIVEN DEVELOPMENT E PROGRAMAÇÃO EXTREMA
COM10015 – ENGENHARIA DE SOFTWARE
CIÊNCIA DA COMPUTAÇÃO
GRUPO 03: 2012204288 – EGLE L. FERREIRA
2012204283 – MATHEUS C. OLIVEIRA 2012204278 – MAYCOWN D. O. MIRANDA
2012204286 – PALOMA O. NOBRE 2012204277 – UESLEI O. MACHADO
ALEGRE, 1º SEMESTRE, 2014
SUMÁRIO
1. Introdução ......................................................................................................... 3
2. Manifesto Ágil - Proposta .................................................................................. 4
2.1 Características ............................................................................................ 5
3. Test Driven Development (TDD) ...................................................................... 8
4. Programação Extrema (XP) .............................................................................. 9
4.1 Programação Extrema Industrial .............................................................. 11
4.2 Debates .................................................................................................... 12
5. Referências .................................................................................................... 14
3
1. INTRODUÇÃO
A insatisfação com essas abordagens pesadas
levou um número de desenvolvedores de software na década de
1990 a propor novos métodos ágeis. Estes permitiam que a
equipe de desenvolvimento se concentrasse no software
somente, em vez de em seu projeto e documentação.
Geralmente, os métodos ágeis contam com uma abordagem
iterativa para especificação, desenvolvimento e entrega de
software, e foram criados principalmente para apoiar o
desenvolvimento de aplicações de negócios nas quais os
requisitos de sistema mudam rapidamente durante o processo
de desenvolvimento. Eles destinam-se a entregar um software
de trabalho rapidamente aos clientes, que podem então propor
novos requisitos e alterações a serem incluídos nas iterações
posteriores do sistema. (2007, SOMMERVILLE, pág. 262).
Métodos ágeis se desenvolveram em um esforço para sanar fraquezas
reais e perceptíveis da engenharia de software convencional. É uma adaptação da
engenharia de software, que tem como foco o desenvolvimento ágil.
As atividades metodológicas como: comunicação, planejamento,
modelagem, construção e emprego permanecem, porém mínimas.
Segundo o dicionário Michaelis, “ágil” é sinônimo de leve, flexível e, é
antônimo de pesado, moroso.
Leve em relação a pouca documentação e projeto, devido a isso, os
softwares são desenvolvidos em curtos períodos, medidos em semanas, realizando
pequenas iterações. Ao final de cada iteração um novo incremento do software.
Como dito, tem como objetivo minimizar o risco pelo desenvolvimento do
software e priorizar mais a entrega do produto, o software, ao projeto e análise. O que
pode ser considerado algo negativo, pois documentação é algo importante.
Deste modo são adotados por equipes pequenas em que priorizam a
comunicação face a face, além do próprio cliente fazer parte da equipe, sempre
ajudando na validação e gerenciamento dos requisitos (mas o sucesso disso depende
4
de o cliente estar disposto e capaz de despender tempo com a equipe de
desenvolvimento).
Flexível pois um método ágil deve ser adaptável e receptível as mudanças,
o que ajuda na forma de se administrar a imprevisibilidade.
Agilidade x Custo de mudanças: O custo de mudanças muda de forma não
linear à medida que o desenvolvimento avança. Quando é adotado uma metodologia
de desenvolvimento convencional em que são priorizados análise e projeto, mudanças
podem ser muito custosas, pois podem causar efeitos colaterais inesperados. No
método ágil, como já se está habituado a serem realizadas frequentes mudanças, o
custo final será menor.
2. MANIFESTO ÁGIL - PROPOSTA
“Estamos descobrindo maneiras melhores de desenvolver softwares,
fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,
passamos a valorizar:
◦ Indivíduos e interações mais do que processos e ferramentas.
◦ Software em funcionamento mais do que documentação abrangente.
◦ Colaboração com o cliente mais do que negociação de contratos.
◦ Responder a mudanças mais do que seguir planos.
Ou seja, mesmo havendo itens à direita, valorizamos mais os itens à
esquerda.”
O manifesto possui inúmeros aspectos fascinantes. Ao começarmos a lê-
lo, deparamo-nos logo com a palavra “descobrindo” que poderia passar despercebida,
mas que foi colocada de forma precisa. Mas por que?
Pensado por experientes e reconhecidos desenvolvedores de software, a
palavra “descobrindo” dá ao manifesto a ideia de que os membros não sabem todas
as respostas para o desenvolvimento ágil.
5
Segundo, a frase “fazendo-o nós mesmos”, o que indica que os próprios
membros praticam a utilização dos métodos em seus trabalhos.
Terceiro, os membros da Alliance procuram ajudar, e não somente ditar as
regras. Eles querem ajudar os outros com os métodos ágeis, e melhorar nosso próprio
conhecimento aprendendo a ajuda de todos os desenvolvedores.
Os valores do manifesto possuem um modelo: em cada ponto, o primeiro
item indica uma preferência, enquanto o item seguinte descreve o que é –
consideravelmente importante – de menor prioridade.
A Alliance reconhece o que os processos e ferramentas são importantes,
com um reconhecimento adicional que a interação de indivíduos qualificados são de
maior importância. Similarmente, documentação completa não é necessariamente
ruim, mas o foco primário deve estar no produto final (entregar o software funcionando).
Portanto, todo o time de projeto precisa determinar para si mesmo, qual
documentação é absolutamente essencial.
Contrato de negociação, se pensado em uma licença de projeto interno ou
contrato jurídico externo, não é uma prática ruim, somente insuficiente. Licença de
contratos e projetos podem proporcionar algumas condições no qual as partes podem
trabalhar, mas somente através de colaboração contínua uma equipe de
desenvolvimento pode entender e entregar o que o cliente quer.
Em um mundo turbulento de tecnologia e negócios, seguir um plano à risca
pode resultar em terríveis consequências, mesmo se executado com precisão. Não
importa o quão seguro um projeto é feito, torna-se perigoso se você tem que mudá-lo.
2.1 CARACTERÍSTICAS
Como explicitado anteriormente, reduzir os custos de mudanças ao longo
de todo o processo de software é característica intrínseca dos métodos ágeis.
Como o desenvolvimento deve ser ágil, é difícil e quase impossível definir
ou prever o crescimento futuro do software, e em muitas vezes só é possível coletar
os requisitos após o início do projeto.
6
Como diz Cockburn (2002) “a consciência das ações é uma fraqueza
humana, as metodologias com disciplina elevada são frágeis”. Com isso concluísse
que os modelos de processos devem fornecer um mecanismo que estimule uma
disciplina necessária, nada exagerado.
Pressman (2002, pág. 84) explicita 12 princípios para quem quer ter
agilidade:
1 - A prioridade é satisfazer o cliente com entrega contínua e mais cedo
possível de um software usável. (O software em funcionamento é a principal medida
de progresso).
2 – Acolha bem os pedidos de alterações, mesmo atrasados no
desenvolvimento. (Mudanças de requerimento são sempre bem vindas, mesmo
quando for tarde. E o projeto e construção devem ser inter-conduzidos, ou seja, ser
aplicados em sequência, para que os modelos de projeto sejam aprovados assim que
criados, garantindo a agilidade).
3 – Entregue software em funcionamento frequente, de algumas semanas
para alguns meses, dando preferência a intervalos mais curtos. (Entregar sempre que
possível um versão do software que funcione).
4 – O pessoal comercial e os desenvolvedores devem trabalhar em
conjunto diariamente ao longo de todo projeto. (O cliente tem uma participação maior
no desenvolvimento da aplicação).
5 – Construa projetos em torno de indivíduos motivados. Dê a eles o
ambiente e apoio necessário e confie neles para ter o trabalho feito.
6 – O método mais eficiente e efetivo de transmitir informações para e
dentro de uma equipe é uma conversa aberta, de forma presencial. (Como é
necessário uma rápida comunicação, é importante que a equipe seja pequena).
7 – Software em funcionamento é a principal medida de progresso.
8 – Os processos ágeis promovem desenvolvimento sustentável
7
9 – Atenção contínua para com a excelência técnica e para com bons
projetos aumentar a agilidade.
10 – Simplicidade – a arte de maximizar o volume de trabalho não efetuado
– é essencial. (Deve haver simplicidade para que seja fácil realizar mudanças).
11 – As melhores arquiteturas, requisitos e projetos emergem de equipes
que auto organizam.
12 – A intervalos regulares, a equipe se avalia para ser como torna-se mais
eficiente, então sintoniza e ajusta seu comportamento de acordo.
Já Sommerville (2007, pág. 263), define esses princípios em apenas cinco
pontos:
Envolvimento do cliente Clientes devem ser
profundamente envolvidos no processo de
desenvolvimento. Seu papel é fornecer e
priorizar novos requisitos do sistema e
avaliar as iterações do sistema.
Entrega incremental O software é desenvolvido em
incrementos e o cliente especifica os
requisitos a serem incluídos em cada
incremento.
Pessoas, não processos As habilidades da equipe de
desenvolvimento devem ser reconhecidas
e exploradas. Os membros da equipe
devem desenvolver suas próprias
maneiras de trabalhar sem processos
prescritivos.
Aceite as mudanças Tenham em mente que os
requisitos do sistema vão mudar, por isso
8
(2007, Sommerville, tabela 17.1, pág. 262)
3. TEST DRIVEN DEVELOPMENT (TDD)
A técnica de Desenvolvimento Guiado por Testes (do inglês, Test Driven
Development - TDD), descrito por Beck (2010), consiste em um processo no qual se
desenvolve primeiro os testes, e depois se codifica o mínimo necessário para que seja
possível passar por esses.
Segundo Beck (2010) o TDD visa qualidade e design de código, além de
influenciar diretamente o tempo gasto com o desenvolvimento do projeto, pois tem-se
o encorajamento de um projeto disciplinado, mais objetivo, e com base em melhorar
a qualidade interna do software. Isto com o foco em corrigir os possíveis defeitos, que
seriam detectados por meio da elaboração de testes.
Este método possui diversos benefícios, tais como: melhor entendimento
do negócio do sistema, pois antes de se codificar algo, há a necessidade de entender
bem o problema ou função, e uma solução para tal. Os testes criados são mais
eficientes, pois ao codificar e depois testar cria-se uma tendência inconsciente a
direcionar o foco ao que já foi produzido, o que pode acarretar em mais erros e mais
testes, sendo que o código que deveria passar no teste em questão. Há uma confiança
maior por parte do desenvolvedor segundo (VASCONCELO, et al., 2012), pois o
progresso é feito a pequenos passos, de forma ágil e segura, tendo a garantia que o
software se comporte da forma que se espera.
Quando se usa o TDD, dificilmente ao correção funcionais nos códigos que
foram implementados, pois se executado de forma correta, os possíveis erros já foram
detectados, e solucionados durante a elaboração de testes.
projete o sistema para acomodar essas
mudanças.
Mantenha a simplicidade
Concentre-se na simplicidade
do software que está sendo desenvolvido e
do processo de desenvolvimento. Sempre
que possível, trabalhe ativamente para
eliminar a complexidade do sistema.
9
O processo pode ser descrito pelas seguintes etapas:
Design do projeto funcional;
Criação do teste;
Compilação somente do código que se elaborou o teste;
Execução do teste;
Implementação do método;
Nova execução do teste;
Refatoração.
4. PROGRAMAÇÃO EXTREMA (XP)
Em Programação Extrema (do inglês Extreming Programming) adota-se o
modelo de programação orientada a objetos, como seu modelo de desenvolvimento
preferido, adota um modelo que é por sua vez dividido em quatros subdivisões:
planejamento, projeto, codificações e testes.
A etapa de planejamento como o próprio nome já diz, é uma etapa onde
se planeja o que vai se fazer, logo é a primeira faze da programação extrema, onde
se tem o levantamentos de requisitos junto ao cliente, mas de forma inicial, já que em
programação extrema o levantamento de requisitos é constante em todas etapas, isso
sendo gerenciado a gosto do cliente que por sua vez está presente em todas etapas
do desenvolvimento do software.
Nesta etapa se tem o desenvolvimento de histórias, que são
mecanismos que tem por função descrever as caraterísticas, resultados e a
funcionalidade que o software terá que ter depois de pronto.
As histórias são escritas e colocadas em fichas pelo cliente, ao mesmo
tempo que este atribui um valor a cada história, de forma que estas sejam avaliadas
de acordo com sua importância para o projeto todo, após isto é estimado um período
para produção de cada história, caso o período estimado seja grande pede-se ao
cliente que este subdivida a história, após isto a equipe escolhe a forma que será
desenvolvida a história, se aquelas de maior importância serão implementadas
primeiro ou não.
10
Após se ter a primeira versão do projeto implementada, a equipe calcula
a velocidade do projeto, neste momento é que equipe observa se algum projeto ira
necessitar de um período maior que originalmente, caso isto ocorra, os prazos de
entrega são reformulados, em todo processo o cliente poderá modificar as histórias,
da forma que bem entenda.
O projeto em programação extrema segue a filosofia de sempre ser o
mais simples possível, usa-se muito cartões CRC (classe-responsabilidade-
colaborador) para identificar e orientar as classes orientadas a objetos.
Um ponto importante em programação extrema é que a elaboração do
projeto acontece de forma constante ou seja, tanto antes como durante a produção
do código, de forma que a todo momento o projeto está sendo implementado, na
verdade a codificação guia a equipe no desenvolvimento do projeto.
A codificação não se inicia exatamente após as histórias e o projeto
preliminar estiver pronto, primeiramente se desenvolve um conjunto de testes, para
que depois dos testes terem sido desenvolvidos o desenvolvedor poderá se focar
melhor em no que deve ser implementado para passar nos testes.
Um ponto importante na Programação Extrema é a programação em
duplas, adota-se esta política onde, o código e desenvolvido em duplas, acredita-se
que desta forma se tenha desenvolvimento com menos chances de erro e mais
eficiente, normalmente um dos membros da dupla se concentra na codificação
enquanto, o outro observa e procura possíveis erros.
Conforme a dupla completa o trabalho, este é integrado aos demais
códigos das demais duplas, de forma que não deixe-se a integração por último, para
que assim não ocorra o risco de ter incompatibilidade no final do processo.
Como já foi dito anteriormente a etapa de testes tem seu início anterior
à etapa de codificação, o sistema dinâmico que a programação extrema adota permite
que os testes de integração e validação do sistema podem ocorrer diariamente ou seja
o desenvolvimento do software está em constante teste, isto é um vantagem já que
segundo Wells [Wel99] que afirma que corrigir pequenos problemas em intervalos de
11
poucas horas é muito mais fácil que corrigir grandes problemas próximo ao prazo de
entrega do produto.
Os testes de aceitação são uma modalidade de testes que é
desenvolvida pelos clientes, estes testes tem por objetivo manter o foco do software,
sobre o aspectos que são visíveis ao usuário, já que o objetivo do software é atender
as necessidades do cliente e este muita das vezes não sabe expressar com exatidão
o que quer, sendo assim só testando para ver se o produto atende suas necessidades.
4.1 PROGRAMAÇÃO EXTREMA INDUSTRIAL
A programação extrema industrial é uma variante da programação
extrema tradicional que difere da primeira, pois por sua vez esta emprega métodos
para adotar um maior gerenciamento, por ter um papel mais expandido para clientes
e por ter algumas técnicas mais atualizadas, a programação extrema industrial adota
seis novas práticas que possibilitam que a programação extrema possa ser
implementada em projetos de maior escala em grandes empresas.
Avaliação imediata, esta pratica tem por sua vez o objetivo de verificar
se existe um ambiente propicio ao desenvolvimento de uma programação extrema
industrial, fazer com que a equipe seja composta por um grupo de interessados
apropriados, a organização tenha um programa de qualidade diferenciado, a cultura
organizacional apoie os novos valores de uma equipe ágil e que a comunidade do
projeto, ampliada seja composta de forma correta.
Em programação extrema objetiva-se procurar as pessoas certas para
desenvolver a equipe que desenvolvera o projeto, ou seja pessoas, dispostas,
corajosas, bem treinadas, adaptáveis, e experientes em programação extrema
industrial, por sua vez o conceito de equipe é substituído pelo de comunidade, já que
esta é maior, sendo assim a comunidade funcionara como a equipe, porem a
comunidade por sua vez, será muito mais abrangente em numero e diversidade de
seus membros, como por exemplo tendo a participação de representantes da área
de produção ou categoria de vendas, normalmente estes ficam na periferia do projeto,
mas podem a qualquer momento assumirem posições mais ativas, dentro deste, na
12
programação extrema industrial os membros da comunidade e os mecanismos de
comunicação e coordenação devem estar determinados.
A equipe por meio do mapeamento do projeto determina se este é
justificável além de determinar dentro do contexto como o projeto complementa,
amplia ou substitui projetos ou sistemas já existentes.
Um projeto de programação extrema industrial requer critérios que
possam ser mensuráveis para que possa assim ser medido o progresso do projeto
obtido até então, o gerenciamento orientado a testes determina um mecanismo para
se fazer este gerenciamento.
Em programação extrema industrial há o método de retrospectivas que
faz uma revisão dos itens, eventos e lições aprendidas ao longo do processo de
incremento de software, com objetivo de aprimorar a programação estrema industrial.
Há também um processo de aprendizagem continua, onde objetiva-se
que os membros da equipe tenha um processo de aperfeiçoamento continuo, sendo
incentivados a sempre aprenderem formas, técnicas e métodos que assim possam
produzir um produto sempre com uma qualidade superior ao anterior.
Em suma a programação extrema industrial modifica diversas partes na
programação extrema tradicional, o emparelhamento aumenta o conceito de
programação em duplas, adicionando gerentes e outras partes que na forma
tradicional, ficavam mais na periferia do processo, a programação extrema industrial
modifica os processos para que estes fiquem mais compatíveis com projetos de
abrangência maior.
4.2 DEBATES
Computação é uma área altamente dinâmica, devido a isto todos novos
modelos de processos estimulam a debates interessantes ou debates acalorados, em
programação extrema presenciamos os dois. Stephens e Rosenberg argumentam que
muitas práticas de programação extrema são eficientes, mas já outras foram
subestimadas e outras podem ser problemáticas, os autores dizem que o fato de os
pontos da programação extrema serem codependentes faz com que esta caraterística
seja seu ponto forte em alguns casos e sua fraqueza em outros, já que muitas
13
empresas adotam somente alguns pontos da programação extrema, acaba
enfraquecendo o processo como um todo, já que alguns processos dos quais são
dependentes não são adotados pela empresa, os defensores da programação
extrema dizem que os pontos em que são criticados vão ser sanados gradativamente
ao longo do período que programação extrema ganha maturidade e que alguns pontos
já foram até corrigidos, devido a caraterística de constante mutação que a
programação extrema possui.
Nos pontos que mais são discutidos pelos críticos da extrema
programação tem-se a volatilidade dos requisitos, os críticos argumentam que devido
ao fato de que o cliente se torne um membro ativo da equipe, os requisitos mudam
com muita facilidade, e isto obviamente torna o trabalho, mais dificultoso, os
defensores argumentam que há métodos para evitar mudanças demasiadas nos
requisitos.
Outro problema é o surgimento de necessidades conflitantes de clientes
já que em programação extrema trabalha-se muitas vezes com projetos com muitos
clientes, estes com requisitos diferentes, que eventualmente podem entrar em conflito,
cabe a equipe gerenciar este problema, mas muitas vezes isto está acima de seu
poder.
Ha também o problema de que os requisitos são levantados de forma
informalmente os críticos desta pratica argumentam que necessita-se de um modelo
mais formal, para que assegurar que erros sejam encontrados antes que o sistema
seja construídos, os defensores afirmam que a natureza mutável da programação
extrema faria com que tais modelos ficariam obsoletos.
Por último a ausência de projeto formal em programação extrema faz
com que os críticos argumentem que em sistemas complexos seja necessário
elaboração de um projeto de forma formal para que se assegure que a estrutura geral
do software apresente qualidade e facilidade de manutenção, os defensores da
programação extrema afirmam que a natureza incremental do processo faz com que
ele se mantenha simples, tornando desnecessário a confecção de um projeto mais
elaborado.
14
Deve se deixar claro que todos diferentes processos de software tem
suas falhas, e determinadas situações que são mais adequados, de forma que cabe
a equipe avaliar em qual situação o processo melhor se adapta e quando se deve
modifica-lo para se adaptar melhor ao seu fim.
5. REFERÊNCIAS
COCKBURN, A. Agile Software Development, Addison – Wesley, 2002
BECK, K. TDD Desenvolvimento Guiado por Testes, Bookman, São Paulo, 2010.
EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison Wesley, Greenvile, 2003.
FOWLER, M., et al. Refactoring: Improving the Design of Existing Code, Addison – Wesley, Greenvile, 2000.
PRESSMAN, R. S. Engenharia de Software, McGrawHill, 6ª ed., São Paulo, 2006.
SOMMERVILLE, I. Engenharia de Software, Pearson Education, 8ª ed., São Paulo, 2007.
VASCONCELO, J, L., et al. Um Estudo de Caso sobre o Aumento de Qualidade de
Software em Projetos de Sistemas de Informação que Utilizam Test Driven Development, SBSI, São Paulo, 2012.
WELLS, D. “XPfUnit Test", disponível em: wwwextremeprogramming.org/ rules/ unittests.html, 1999.
top related