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

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.

3. Processos de
Software

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

11. Workflow
Disciplinas

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

14. Workflow de
Requisitos

15. Responsabilidades

16. Desenvolvimento
Ágil

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.

41. Ciclo de Trabalho
Scrum

43. Estimativa com
Planning Poker

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.

47. Quadro de Atividades

51. Layout de uma
atividade

52. Atividade

53. Definição de Pronto

54. Video Scrum

55. https://www.youtube.com/watch?v=CAZPC_kXW28

56. Atividade para Entrega
• Explique o processo Scrum apresentado em sala
de aula.