Aula 4- Engenharia de Software

414 visualizações

Publicada em

Processos de Software, Code and Fix, Infelizmente, podemos encontrar grandes problemas arquitetônicos ao parte da aplicação, pois normalmente muitas empresas não tem
avançar neste processo, geralmente temos que reescrever grande tempo para planejar, mas, sempre tem dinheiro para refazer. Rudson Kiyoshi S. Carvalho
Nuvem de mudanças, XP, FDD, Scrum, TDD, Crystal, Lean, Design, Develop, Test, Release, Ciclo de Vida XP, Stand Up Meeting, Metáforas

Publicada em: Software
  • Seja o primeiro a comentar

Aula 4- Engenharia de Software

  1. 1. Engenharia de Softwares e Gerência de Projetos Prof. Rudson Kiyoshi Souza Carvalho Anhanguera - 2015 Engenharia de Software - Parte 4
  2. 2. Engenharia de Softwares e Gerência de Projetos.
  3. 3. Processos de Software
  4. 4. CODE AND FIX
  5. 5. Code and Fix • A metodologia de desenvolvimento codificar e consertar é a mais frequentemente usada em engenharia de software. Ela começa com pouco ou nenhum planejamento inicial, e imediatamente ao começarmos a desenvolver , começamos a corrigir os problemas à medida que ocorrem, até a conclusão do projeto . • Codificar e consertar é uma escolha tentadora, quando nos deparamos com um cronograma de desenvolvimento apertado, pois necessitamos desenvolver o código imediatamente e obter um resultado instantâneo. • Infelizmente, podemos encontrar grandes problemas arquitetônicos ao avançar neste processo, geralmente temos que reescrever grande parte da aplicação, pois normalmente muitas empresas não tem tempo para planejar, mas, sempre tem dinheiro para refazer. Rudson Kiyoshi Souza Carvalho - 2015
  6. 6. Ainda temos problemas • Código complexo; • Baixa produtividade; • Dificuldade em realizar mudanças; • Documentação defasada, excessiva, incorreta; • Cronograma sempre atrasado; • entre outros…
  7. 7. Manifesto para o desenvolvimento ágil de software
  8. 8. Nuvem de Mudanças Scrum XP TDD FDD Crystal LeanDynamic Systems Development Method Adaptative Software Development Method
  9. 9. Extreme Programming
  10. 10. Extreme Programing - XP Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Wikipedia
  11. 11. Valores • Coragem • Comunicação • Respeito • Simplicidade • Feedback Princípios Básicos • Feedback rápido • Presumir simplicidade • Mudanças incrementais • Abraçar mudanças • Trabalho de alta qualidade.
  12. 12. Ciclo de Vida XP
  13. 13. Jogo de Planejamento
  14. 14. Jogo de Planejamento • Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
  15. 15. Stand Up Meeting
  16. 16. Stand Up Meeting • O dia de trabalho de uma equipe XP sempre começa com um stand up meeting . é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé. • Segundo estudos uma reunião em pé é mais rápida, evita bate- papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples. • A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.
  17. 17. Metáforas
  18. 18. Metáforas • Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.
  19. 19. Programação Pareada
  20. 20. Programação Pareada • Programação Pareada (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
  21. 21. Design Simples
  22. 22. Design Simples • Design Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso.
  23. 23. Propriedade Coletiva
  24. 24. Propriedade Coletiva • Propriedade Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
  25. 25. Time Coeso
  26. 26. Time Coeso • Time Coeso (Whole Team): A equipe de desenvolvimento é formada por pessoas engajadas e de forma multidisciplinar (no sentido de incluir pessoas com cada uma das habilidades necessárias para o projeto).
  27. 27. Integração Continua
  28. 28. Integração Continua • Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de implementação da solução.
  29. 29. Refatoração
  30. 30. Refatoração • Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Re- fabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;
  31. 31. TDD - Test Driven Development
  32. 32. TDD - Test Driven Development • A mecânica da prática é simples: escreva um teste que falha, faça-o passar da maneira mais simples possível e, por fim, refatore o código. Esse ciclo é conhecido como Ciclo Vermelho-Verde-Refatora.
  33. 33. Custo do Conserto
  34. 34. Desenvolvimento Guiado por Funcionalidades
  35. 35. Feature Driven Development FDD
  36. 36. Feature Driven Development • O Desenvolvimento Guiado por Funcionalidades (do inglês, Feature Driven Development; FDD) é uma das seis metodologias ágeis originais do desenvolvimento de software. Lema: ”Resultados frequentes, tangíveis e funcionais".
  37. 37. Kanban
  38. 38. Kanban • Kanban é um palavra em japonês que significa literalmente registro ou placa visível. • Em Administração da produção significa um cartão de sinalização que controla os fluxos de produção ou transportes em uma indústria. O cartão pode ser substituído por outro sistema de sinalização, como luzes, caixas vazias e até locais vazios demarcados.
  39. 39. Video Kanban
  40. 40. Video Extreme Programming
  41. 41. Atividade para Entrega • Explique a metodologia XP apresentada em sala de aula.

×