aula 3 - engenharia de software
TRANSCRIPT
![Page 1: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/1.jpg)
Engenharia de Softwares e Gerência de Projetos
Prof. Rudson Kiyoshi Souza Carvalho Anhanguera - 2015
Engenharia de Software - Parte 3
![Page 2: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/2.jpg)
Engenharia de Softwares e Gerência de Projetos.
![Page 3: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/3.jpg)
Processos de Software
![Page 4: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/4.jpg)
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
![Page 5: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/5.jpg)
![Page 6: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/6.jpg)
• 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.
![Page 7: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/7.jpg)
RUP - Rational Unified Process
![Page 8: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/8.jpg)
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
![Page 9: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/9.jpg)
![Page 10: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/10.jpg)
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
![Page 11: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/11.jpg)
WorkflowDisciplinas
![Page 12: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/12.jpg)
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
![Page 13: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/13.jpg)
![Page 14: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/14.jpg)
Workflow de Requisitos
![Page 15: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/15.jpg)
Responsabilidades
![Page 16: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/16.jpg)
Desenvolvimento Ágil
![Page 17: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/17.jpg)
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
![Page 18: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/18.jpg)
Manifesto para o desenvolvimento ágil de software
![Page 19: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/19.jpg)
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.
![Page 20: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/20.jpg)
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.
![Page 21: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/21.jpg)
Resumindo• Envolvimento do cliente
• Entrega Incremental
• Pessoas, não processos
• Aceite as mudanças
• Manter a simplicidade
![Page 22: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/22.jpg)
Ágil = Rápido Ágil = Adaptativo
![Page 23: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/23.jpg)
Scrum
![Page 24: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/24.jpg)
GURUS
![Page 25: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/25.jpg)
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;
![Page 26: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/26.jpg)
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.
![Page 27: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/27.jpg)
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.
![Page 28: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/28.jpg)
Papéis no Scrum
![Page 29: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/29.jpg)
![Page 30: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/30.jpg)
Product Owner
• Define as funcionalidades • Prioriza as funcionalidades • Escolhe as datas de
entregas
• Fornece Feedback • Gerencia os stakeholders • Aceita ou rejeita resultados
![Page 31: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/31.jpg)
![Page 32: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/32.jpg)
The Team
• Define as atividades • Estima o esforço • Desenvolve o produto
• Garante a qualidade • Estão em constante
evolução
![Page 33: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/33.jpg)
![Page 34: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/34.jpg)
Scrum Master
• Remove os impedimentos • Previne as interrupções • Facilitador da equipe • Suporte ao processo
![Page 35: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/35.jpg)
![Page 36: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/36.jpg)
![Page 37: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/37.jpg)
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.
![Page 38: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/38.jpg)
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.
![Page 39: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/39.jpg)
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.
![Page 40: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/40.jpg)
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.
![Page 41: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/41.jpg)
Ciclo de Trabalho Scrum
![Page 42: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/42.jpg)
![Page 43: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/43.jpg)
Estimativa com Planning Poker
![Page 44: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/44.jpg)
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.
![Page 45: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/45.jpg)
![Page 46: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/46.jpg)
![Page 47: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/47.jpg)
Quadro de Atividades
![Page 48: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/48.jpg)
![Page 49: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/49.jpg)
![Page 50: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/50.jpg)
![Page 51: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/51.jpg)
Layout de uma atividade
![Page 52: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/52.jpg)
Atividade
![Page 53: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/53.jpg)
Definição de Pronto
![Page 54: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/54.jpg)
Video Scrum
![Page 55: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/55.jpg)
https://www.youtube.com/watch?v=CAZPC_kXW28
![Page 56: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/56.jpg)
Atividade para Entrega• Explique o processo Scrum apresentado em sala
de aula.
![Page 57: Aula 3 - Engenharia de Software](https://reader031.vdocuments.pub/reader031/viewer/2022020116/55ad73591a28ab992c8b482b/html5/thumbnails/57.jpg)