Aula 3 - Engenharia de Software

341 visualizações

Publicada em

Modelo Espiral de Boehm, prototipação em etapas, RUP - Rational Unified Process, Desenvolvimento Ágil, manifesto ágil, Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor, Envolvimento do cliente, Manter a simplicidade, O que é Scrum, Reunião Diária, Retrospectiva da , Planning Poker

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
341
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aula 3 - Engenharia de Software

  1. 1. Engenharia de Softwares e Gerência de Projetos Prof. Rudson Kiyoshi Souza Carvalho Anhanguera - 2015 Engenharia de Software - Parte 3
  2. 2. Engenharia de Softwares e Gerência de Projetos.
  3. 3. Processos de Software
  4. 4. Modelo Espiral de Boehm • O Modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto prototipação em etapas, em um esforço para combinar as vantagens dos conceitos de top- down e bottom-up, acrescentando um novo elemento, a análise de riscos que falta a esses paradigmas. Nota: o modelo em espiral foi definido por Barry Boehm em seu artigo de 1988. Wikipedia
  5. 5. • No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições. • No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou realizar-se simulações do software. • No estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente. • No estágio 4 compreende a revisão das etapas anteriores e o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo.
  6. 6. RUP - Rational Unified Process
  7. 7. Rational Unified Process • O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. Wikipedia
  8. 8. Fases • 1. Concepção: o objetivo desta fase é estabelecer um business case[2] para o sistema. Devem ser identificadas todas as entidades externas (pessoas e sistemas) que irão interagir com o sistema em desenvolvimento e definir essas interações. Essas informações são utilizadas para avaliar a contribuição do novo sistema para o negócio. • 2. Elaboração: os objetivos desta fase são desenvolver um entendimento do domínio do problema, estabelecer um framework[3] de arquitetura para o sistema, desenvolver o plano de projeto e identificar seus principais riscos. Ao final desta fase deve-se ter um modelo de requisitos para o sistema (os casos de uso da UML são especificados), uma descrição de arquitetura e um plano de desenvolvimento do software. • 3. Construção: está fase está essencialmente relacionada ao projeto, programação e teste do sistema. As partes do sistema são desenvolvidas paralelamente e integradas durante esta fase. Ao final deve-se ter um sistema de software em funcionamento e a documentação associada pronta para ser liberada para os usuários. • 4. Transição: nesta fase, faz-se a transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários, com a entrada do sistema em funcionamento no ambiente real. Esta é uma atividade ignorada na maioria dos modelos de processo de software, pois é onerosa e às vezes problemática. Ao final desta fase, deve-se ter um sistema de software documentado, funcionando corretamente em seu ambiente operacional. Sommerville
  9. 9. Workflow Disciplinas
  10. 10. Melhores práticas abordadas • 1. Desenvolver o software iterativamente: planejar os incrementos de software com base nas prioridades do cliente e desenvolver e entregar o mais cedo possível às características de sistema de maior prioridade no processo de desenvolvimento. • 2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e manter acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no sistema antes de aceitá-las. • 3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do sistema com componentes, reduzindo a quantidade de software a ser desenvolvido e, consequentemente, reduzir custos e riscos. • 4. Modelar software visualmente: usar modelos gráficos de UML para apresentar as visões estática e dinâmica do software. • 5. Verificar a qualidade do software: garantir que o software atenda aos padrões de qualidade da organização. • 6. Controlar as mudanças do software: gerenciar as mudanças do software, usando um sistema de gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento de configuração. Sommerville
  11. 11. Workflow de Requisitos
  12. 12. Responsabilidades
  13. 13. Desenvolvimento Ágil
  14. 14. Por que temos de ser ágeis? • As regras de negócios mudam rapidamente • O software tem que ser adaptado para as novas regras • Desenvolvimento e entrega rápida são importantes em mercados competitivos • A entrega rápida pode ser tão (ou mais) desejável que a qualidade
  15. 15. Manifesto para o desenvolvimento ágil de software
  16. 16. Princípios por trás do manifesto ágil 1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. 2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. 3. Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos. 4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. 5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  17. 17. 6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. 7. Software funcional é a medida primária de progresso. 8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. 9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. 10.Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. 11.As melhores arquiteturas, requisitos e designs emergem de times auto- organizáveis. 12.Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
  18. 18. Resumindo • Envolvimento do cliente • Entrega Incremental • Pessoas, não processos • Aceite as mudanças • Manter a simplicidade
  19. 19. Ágil = Rápido Ágil = Adaptativo
  20. 20. Scrum
  21. 21. GURUS
  22. 22. Primeiras Impressões • Não possuí escopo fechado; • A documentação é um monte de post-its; • Jogam baralho durante o trabalho; • É um processo sem gerente de projetos; • Não possuí cronograma; • Precisa de um time muito bom para funcionar; • Não da para estimar, logo é impossível de vender; • Meu cliente nunca vai aceitar isso; • Jamais funcionará em projetos complexos;
  23. 23. O que é Scrum • É um processo iterativo e incremental para desenvolvimento de softwares. • Seu principal objetivo é entregar funcionalidades com o mais alto valor de negócio para o cliente.
  24. 24. O que não é Scrum • Scrum não é uma metodologia de desenvolvimento de software. • Scrum não garantirá a qualidade do seu projeto. • Scrum não fornece um conjunto de templates para gerenciar tarefas, requisitos, estimar ou gerar relatórios.
  25. 25. Papéis no Scrum
  26. 26. Product Owner • Define as funcionalidades • Prioriza as funcionalidades • Escolhe as datas de entregas • Fornece Feedback • Gerencia os stakeholders • Aceita ou rejeita resultados
  27. 27. The Team • Define as atividades • Estima o esforço • Desenvolve o produto • Garante a qualidade • Estão em constante evolução
  28. 28. Scrum Master • Remove os impedimentos • Previne as interrupções • Facilitador da equipe • Suporte ao processo
  29. 29. Planejamento da Sprint (Sprint Planning) • Esta é uma reunião onde o próprio nome já diz tudo, é uma reunião de planejamento. Uma reunião de curta duração que dura entre 3 a 4 horas e que tem como objetivo fazer todo o planejamento da Sprint.
  30. 30. Reunião Diária (Daily Meeting) O Daily Scrum é uma reunião publica, onde todos podem participar mais só membros do time podem fazer comentários e perguntas. A idéia é que seja realizada fora do ambiente da equipe e que seja feita em no máximo 15 minutos. Umas das principais regras a serem cumpridas são as três • O que eu fiz desde a última reunião? Ex.: Comecei a implementar a funcionalidade de login da aplicação. • O que vou fazer até a próxima reunião? Ex.: Vou codificar a validação da senha do usuário do lado cliente. • Quais os problemas que estão impedindo a realização do meu trabalho? Ex.: A minha máquina não liga.
  31. 31. Revisão do Sprint (Spring Review) • Está é uma reunião realizada no último dia da Sprint, para apresentar o que foi feito durante a Sprint, ou seja, apresentar o resultado do trabalho.
  32. 32. Retrospectiva da Sprint (Sprint Retrospective) • Esta é uma reunião formal e fechada, geralmente com timeboxed de 3 horas. Participam o time, o Scrum Master e Product Owner (presença opcional). • Esta reunião tem como objetivo detectar pontos de melhorias.
  33. 33. Ciclo de Trabalho Scrum
  34. 34. Estimativa com Planning Poker
  35. 35. Estimativa com Planning Poker • A técnica Planning Poker foi definida pela primeira vez por James Grenning em 2002, e popularizada por Mike Cohn no livro Agile Estimating and Planning no qual registrou o termo Planning Poker (PP). Cohn (2013) e Grenning (2002) descrevem o PP como uma técnica de estimativa de tamanho voltada para as metodologias ágeis de desenvolvimento de software.
  36. 36. Quadro de Atividades
  37. 37. Layout de uma atividade
  38. 38. Atividade
  39. 39. Definição de Pronto
  40. 40. Video Scrum
  41. 41. https://www.youtube.com/watch?v=CAZPC_kXW28
  42. 42. Atividade para Entrega • Explique o processo Scrum apresentado em sala de aula.

×