View
24
Download
2
Embed Size (px)
Citation preview
Engenharia de Softwares e Gerência de Projetos
Prof. Rudson Kiyoshi Souza Carvalho Anhanguera - 2015
Engenharia de Software - Parte 3
Engenharia de Softwares e Gerência de Projetos.
Processos de Software
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
• 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.
RUP - Rational Unified Process
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
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
WorkflowDisciplinas
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
Workflow de Requisitos
Responsabilidades
Desenvolvimento Ágil
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
Manifesto para o desenvolvimento ágil de software
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.
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.
Resumindo• Envolvimento do cliente
• Entrega Incremental
• Pessoas, não processos
• Aceite as mudanças
• Manter a simplicidade
Ágil = Rápido Ágil = Adaptativo
Scrum
GURUS
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;
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.
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.
Papéis no Scrum
Product Owner
• Define as funcionalidades • Prioriza as funcionalidades • Escolhe as datas de
entregas
• Fornece Feedback • Gerencia os stakeholders • Aceita ou rejeita resultados
The Team
• Define as atividades • Estima o esforço • Desenvolve o produto
• Garante a qualidade • Estão em constante
evolução
Scrum Master
• Remove os impedimentos • Previne as interrupções • Facilitador da equipe • Suporte ao processo
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.
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.
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.
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.
Ciclo de Trabalho Scrum
Estimativa com Planning Poker
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.
Quadro de Atividades
Layout de uma atividade
Atividade
Definição de Pronto
Video Scrum
https://www.youtube.com/watch?v=CAZPC_kXW28
Atividade para Entrega• Explique o processo Scrum apresentado em sala
de aula.