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.