Aula 3 - Engenharia de Software
0 gostou•669 visualizações
O documento aborda conceitos de engenharia de software e gerenciamento de projetos, destacando o modelo espiral e o processo unificado racional (RUP) como abordagens para o desenvolvimento de software. Também discute o desenvolvimento ágil, enfatizando a importância da flexibilidade em requisitos e a colaboração contínua entre equipes. Por fim, apresenta o funcionamento do Scrum, detalhando papéis, eventos e técnicas como o planning poker para estimativas.
![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](https://image.slidesharecdn.com/apresentacao6-150515232545-lva1-app6891/85/Aula-3-Engenharia-de-Software-10-320.jpg)
Aula 3 - Engenharia de Software
- 1. Engenharia de Softwares e Gerência de Projetos Prof. Rudson Kiyoshi Souza Carvalho Anhanguera - 2015 Engenharia de Software - Parte 3
- 2. Engenharia de Softwares e Gerência de Projetos.
- 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
- 6. • 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.
- 7. RUP - Rational Unified Process
- 8. 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
- 10. 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
- 12. 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
- 17. 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
- 18. Manifesto para o desenvolvimento ágil de software
- 19. 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.
- 20. 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.
- 21. Resumindo • Envolvimento do cliente • Entrega Incremental • Pessoas, não processos • Aceite as mudanças • Manter a simplicidade
- 22. Ágil = Rápido Ágil = Adaptativo
- 23. Scrum
- 24. GURUS
- 25. 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;
- 26. 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.
- 27. 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.
- 28. Papéis no Scrum
- 30. Product Owner • Define as funcionalidades • Prioriza as funcionalidades • Escolhe as datas de entregas • Fornece Feedback • Gerencia os stakeholders • Aceita ou rejeita resultados
- 32. The Team • Define as atividades • Estima o esforço • Desenvolve o produto • Garante a qualidade • Estão em constante evolução
- 34. Scrum Master • Remove os impedimentos • Previne as interrupções • Facilitador da equipe • Suporte ao processo
- 37. 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.
- 38. 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.
- 39. 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.
- 40. 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.
- 44. 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.
- 52. Atividade
- 54. Video Scrum
- 56. Atividade para Entrega • Explique o processo Scrum apresentado em sala de aula.