CIÊNCIA DA COMPUTAÇÃO - FCG
Qualidade de Software
Aula 08: Metodologias Ágeis
(Adaptação do capítulo 10 de Koscianski & Soares, 2006)
Prof.º Msc. Sidney Roberto de Sousa
Ciência da Computação - FCG 2
Metodologias de desenvolvimento de software
Nas últimas décadas, várias metodologias foram criadas a fim de sistematizar o desenvolvimento de software
Tais metodologias podem ser divididas em: Tradicionais: ênfase na documentação de cada
passo do desenvolvimento do software Ágeis: paradigma mais recente de engenharia de
software, o qual promete melhorias de produtividade e qualidade
Ciência da Computação - FCG 3
Especificação: definição das funcionalidades e demais características do produto
Projeto e Implementação: produção do software de acordo com as especificações. Propõe-se modelos os quais serão implementados em alguma linguagem de programação
Validação:revisão e testes quem visam a garantia de cumprimento dos requisitos
Evolução: manutenção ou criação de novas funcionalidade a fim de adaptar o software a novas necessidades do cliente
Atividades comuns a metodologias
Ciência da Computação - FCG 4
Metodologias Tradicionais
Consideradas por muitos com ”pesadas” ou ”orientadas a documentação”
Surgiram em um contexto de desenvolvimento de software muito diferente do atual → baseado em mainframes e terminais burros
Em tal época, o custo de manutenção era muito caro → dificuldade de acesso a computadores e a escassez de ferramentas de apoio ao desenvolvimento de software
Assim, todo o software era planejado e documentado antes de ser implementado
Ciência da Computação - FCG 5
Modelo Cascata
Também conhecido como modelo clássico, é considerada a principal metodologia tradicional
Estabele uma sequência de etapas Após o término de cada etapa é criada uma
documentação que deve ser aprovada para que a próxima etapa possa ser iniciada
Ciência da Computação - FCG 6
Modelo Cascata
Ciência da Computação - FCG 7
Modelo Cascata
Divide o projeto em fases de forma inflexível Ex.: após a fase de desenvolvimento não são
previstas mudanças de requisitos O modelo espiral permite o retorno a etapas
anteriores, porém não dá suporte à execução de etapas de forma paralela
Este paralelismo é necessário em alguns tipos de projeto → ex.: desenvolvimento de módulos concorrentes
Ciência da Computação - FCG 8
Modelo Cascata
Assim, o modelo cascata é recomendável em projetos com requisitos estáveis → Isto existe?
Ciência da Computação - FCG 9
Custo de modificação no Modelo Cascata
Ciência da Computação - FCG 10
Modelo Cascata
O modelo cascata dominou a forma de se desenvolver software até o inícios dos anos 90
Tal dominância ocorreu mesmo sob advertência de pesquisadores de engenharia de software e o relato negativo de desenvolvedores de software
Autores como Brooks (Brooks, 1986) demonstraram como a idéia de se especificar um software por inteiro antecipadamente pode ter riscos sérios
Ciência da Computação - FCG 11
Experiências da indústria
Dados de 1994 usando como base 8380 projetos mostram que apenas 16,2% destes foram entregues respeitando prazos, custos e requisitos
Cerca de 31% foram cancelados antes de seu término e 52,7% foram entregues → com prazos e custos maiores OU com diminuição de requisitos
Causa? Pressão sobre desenvolvedores → quadruplica o número de erros!
Modelo cascata → dificuldades em alterar requisitos
Ciência da Computação - FCG 12
Experiências da indústria
No fim da década de 90, pesquisas mostraram resultados mais ”animadores”
15% dos projetos terminaram sem mostrar resultados
66% dos projetos não atenderam as necessidades dos usuários
Média de atrasos caiu para 63%
Projetos custaram em média 45% a mais que o planejado
28% dos projetos cumpriram o planejado → porém, a maioria destes projetos foram superestimados – exageros de até 150%
Ciência da Computação - FCG 13
Experiências da indústria
Dentre os motivos da melhoria, o principal foi o uso de ferramentas CASE no processo de modelagem e implementação
As ferramentas de gestão de requisitos também foram responsáveis pela melhoria
Por fim, também ajudou a melhoria da qualidade dos processos de desenvolvimento
As pesquisas do final dos anos 90 recomendaram o desenvolvimento de software baseado em modelos incrementais → evitar falhas
Ciência da Computação - FCG 14
Métodos ágeis
Adequados para situações em que a mudança de requisitos é frequente
Um método ágil aceita a mudança ao invés de tentar prever o futuro
O termo se tornou comum em 2001, quando 17 especialistas em processos de desenvolvimento de software – representando as metodologias XP, Scrum, DSDM, Crystal, entre outros, estabeleceram os princípios comuns compartilhados por todos estes métodos
Criou-se assim a Aliança Ágil e o Manifesto Ágil
Ciência da Computação - FCG 15
Métodos ágeis
Ciência da Computação - FCG 16
Métodos ágeis
O Manifesto Ágil não rejeita processos e ferramentas, documentação, negociação de contratos ou planejamento
Porém, ele mostra que estes tem menos importância que os indivíduos, o software executável, a colaboração dos clientes e as respostas rápidas às mudanças
Aproximação da forma como pequenas e médias empresas trabalham e respondem às mudanças
Ciência da Computação - FCG 17
Conceitos-chave do Manifesto Ágil
Indivíduos e interações ao invés de processos e ferramentas
Software executável ao invés de documentação Colaboração com o cliente ao invés de
negociações de contratos Respostas rápidas a mudanças ao invés de
seguir planos
Ciência da Computação - FCG 18
Extreme Programming (XP)
Método ágil para equipes pequenas/médias que desenvolvem software baseado em requisitos vagos e rapidamente mutáveis
Principais diferenças entre a XP e as metodologias clássicas:
Feedback contínuo Abordagem incremental Encorajamento da comunicação interpessoal
Ciência da Computação - FCG 19
Extreme Programming (XP)
As práticas da XP podem ser ”chocantes” à primeira vista → ou mesmo não fazer sentido, se observadas de forma isolada
Porém, a sintonia do seu conjunto que faz com que a metodologia seja sucessiva
A XP enfatiza o desenvolvimento rápido do projeto, a garantia de satisfação do cliente e o cumprimento das estimativas
Suas práticas/valores oferecem um ambiente agradável de desenvolvimento de software aos seus seguidores → conduzindo-os por quatro valores: comunicação, simplicidade, feedback e coragem
Ciência da Computação - FCG 20
XP - Comunicação
Manter o melhor relacionamento possível entre clientes e desenvolvedores
Prefere-se conversas pessoais ao invés de outros meios de comunicação
A comunicação entre desenvolvedores e gerente de projeto também é encorajada
Ciência da Computação - FCG 21
XP - Simplicidade
Permitir a criação de código enxuto, que não deve possuir funções desnecessárias
Código simples → implementar o software com o menor número possível de componentes como classes e métodos
Preocupação com requisitos atuais, evitando-se adicionar funcionalidades que não são úteis no momento → escopo bem definido
XP aposta na implementação rápida de um produto simples → espera-se que alterações e evoluções futuras custarão menos do que criar desde o início um software grande e complexo
Ciência da Computação - FCG 22
XP – Feedback constante
Programador deve ter informações constantes sobre o código e o cliente
A informação sobre o código é obtida por testes constantes → indicação de erros unitários e de integração
O cliente obtem frequentemente incrementos de software funcionais para que posso avaliá-los
Com isto, o cliente tem subsídios para sugerir novas características e informação aos desenvolvedores
Não-conformidades são identificadas rapidamente e corrigidas em novas versões/incrementos
O produto tende a estar de acordo com as reais expectativas do cliente
Ciência da Computação - FCG 23
XP - Coragem
Necessária para implantar os três valores anteriores
Nem todas as pessoas tem facilidade de comunicação e têm bom relacionamento
A coragem também é necessária para experimentar a simplificidade no software implementado
Por fim, é preciso coragem para ouvir o feedback do cliente!
Ciência da Computação - FCG 24
Práticas da XP
A XP baseia-se em 12 práticas Não exige-se a implementação simultânea de
todas as práticas → recomenda-se que sejam aplicadas gradativamente
Algumas práticas não são inovadores → na verdade, são usadas há anos na indústria de software
Ciência da Computação - FCG 25
Prática 1 - Planejamento
Decidir o que é necessário fazer o que pode ser adiado no projeto
A XP baseia-se em requisitos atuais reais para desenvolvimento de software → não em possíveis requisitos futuros
Procura-se evitar problemas de relacionamento entre a área de negócios e a de desenvolvimento → ambas devem cooperar para o sucesso e cada uma deve focar partes específicas do projeto
Área de negócios → escopo, composição das versões e as datas de entrega
Desenvolvedores → estimativas de prazo, processo de desenvolvimento e cronograma detalhado
Ciência da Computação - FCG 26
Prática 2 – Entregas frequentes
Construir software simples e atualizado à medida que novos requisitos surgem
Cada incremento deve ser o mais compacto possível → apenas os requisitos mais valiosos
Incrementos devem ser entregues a cada mês ou no máximo a cada dois meses → feedback mais rápido do cliente
Evita-se surpresas → grandes modificações
Torna as avaliações mais precisas e aumenta a chance da concordância do software com as necessidades do cliente
Ciência da Computação - FCG 27
Prática 3 - Metáfora
Descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o seu
desenvolvimento
Ciência da Computação - FCG 28
Prática 4 – Projeto simples
O software deve ser o mais simples possível e satisfazer os requisitos atuais
Possíveis requisitos futuros só são adicionados ao projeto quando sua implementação é realmente necessária → K.I.S.S.
Oposto ao raciocínio ”implemente para hoje e projete para amanhã”
Ciência da Computação - FCG 29
Prática 5 - Testes
Foco na validação do projeto durante todo o processo de desenvolvimento
Os desenvolvedores implementam o software cirando primeiramente os casos de testes → TDD
Ciência da Computação - FCG 30
Prática 6 – Programação em pares
Implementação de software feita em dupla → 2 devs em um único computador
Um dev implementa; o outro revisa continuamento o trabalho feito → procura-se identificar erros sintáticos e semânticos, além de planejar refatorações
Estes dois papéis devem ser trocados continuamente
Desenvolvedores aprendem juntos
Maior possibilidade de corretude de código
Possibilidade de revisões já na fase de implementação
Ciência da Computação - FCG 31
Prática 7 - Refatoração
Foco no aperfeiçoamento do projeto do software
Presente em todo o desenvolvimento Deve ser feita sempre que possível A idéia é simplificar código sem que haja perda
de funcionalidades
Ciência da Computação - FCG 32
Prática 8 – Propriedade coletiva
O código é de todos os membros da equipe!
Qualquem membro pode agregar valor ao código → mesmo que não o tenha desenvolvido (desde que realize os testes necessários)
Todos são responsáveis pelo software inteiro!
Caso um membro da equipe deixe o projeto (momentânea ou definitivamente) antes de sua conclusão, a equipe ainda é capaz de continuar o projeto com poucas dificuldades
Menor dependência de heróis individuais
Ciência da Computação - FCG 33
Prática 9 – Integração contínua
O código (testado) produzido por uma equipe deve ser integrado ao sistema, o qual também deve ser testado
O software é construído e verificado continuamente
Maior facilidade de isolar erros e suas causas Recomenda-se utilizar uma única máquina de
integração, o qual pode ser acessado livremente por toda a equipe
Ciência da Computação - FCG 34
Prática 10 – Trabalho semanal de 40 horas
Horas extras não devem se tornar um costume
Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema no projeto!
Tal problema não deve ser resolvido com mais horas de trabalho → e sim com planejamento
Focos na pessoas → não em processos e planejamentos
Alteração dos planos Vs. Sobrecarga de pessoal
Ciência da Computação - FCG 35
Prática 11 – Cliente presente
O cliente DEVE participar durante todo o projeto O cliente DEVE estar sempre disponível para
sanar todas as dúvidas sobre requisitos Evita atrasos e implementações errôneas O cliente pode ser mantido como parte
integrande da equipe do desenvolvimento → ex.: escrevendo história de usuário
Pergunta: o que são histórias de usuário? (BDD)
Ciência da Computação - FCG 36
Prática 12 – Código padrão
Regras de escrita → estilo, formato de comentários, nomenclatura de variáveis, etc.
Favorece o trabalho em equipe e a propriedade coletiva do código
Ciência da Computação - FCG 37
Planejamento na XP
O cliente participa ativamente no processo de desenvolvimento → pode até fazer parte da equipe de desenvolvimento
Esclarecimento de dúvidas facilitado → uso de histórias
Cada tarefa/requisito é descrito como uma história → possivelmente, pelo cliente
As história são distribuídas aos desenvolvedores, os quais se encarregam de implementar as funcionalidades descritas
Ciência da Computação - FCG 38
Scrum
… na próxima aula! ;)
Ciência da Computação - FCG 39
Conclusões – Métodos ágeis
Pesquisas mostram que projetos utilizando métodos ágeis obtiveram melhores resultados em termos de cumprimento de prazos, custos e padrões de qualidade
Cada vez mais projetos/equipes maiores tem utilizado métodos ágeis
Outras pesquisas mostraram que o uso adequado de XP pode ajudar organizações alcançarem os níveis CMM 2 e 3 → Boeing, por exemplo, alcançou o nível CMM 5 sem muitas alterações após adotar o XP
Ciência da Computação - FCG 40
Conclusões – Vantagens da XP
XP é ideal a projetos em que os stakeholders não sabem exatamente o que desejam
O feedback contínuo permite a rápida adaptação do produto
Entregas frequentes do software executável e funcional → diminuir a ansiedade do cliente e obter o seu feedback a respeito do trabalho realizado
Integração e testes contínuos → melhoria e garantia de qualidade
Ciência da Computação - FCG 41
Conclusões – Algumas desvantagens da XP
Muitos acreditam que seja a volta do processo caótico de desenvolvimento de software → ”codifica-remenda”
O uso errôneo da XP pode ”mascarar” práticas positivas de desenvolvimento → ex., análise de problemas utilizando diagramas
Alguns clientes podem não gostar da informalidade no levantamento de requisitos
Além disso, alguns clientes podem enxergar a refatoração como amadorismo ou mesmo incompetência
Ciência da Computação - FCG 42
Bibliografia
KOSCIANSKI, A., SOARES, M. S. Qualidade de Software. Segunda edição. Editora Novatec. São Paulo, 2006.
BROOKS, F. P. No Silver Bullet – Essence and Accident in Software Engineering. Proceedings of IFIP Tenth World Computing Conference, H.-J. Kugler, ed., Elsevier Science B. V., Amsterdam, NL (1986) pp. 1069-1076.
Top Related