Post on 24-Oct-2015
Engenharia de Software
Ph.D Students Prof. Ms.C. Paulino Wagner Palheta Viana
Manaus, outubro 2013 1
2
IntroduçãoO Dilema da Construção de Software Projetos de software sempre foram marcados por fracassos:
Prazos e orçamentos não cumpridos Expectativas não satisfeitas Retorno muito menor que o esperado Impossível satisfazer ao mesmo tempo custo, prazo, escopo e
qualidadeA Solução ... Construção de software = construção de projetos de engenharia
Receita para o sucesso: Investir muito tempo e recurso em uma fase detalhada de planejamento e design Garantir o sucesso da execução com gerenciamento e processos bem definidos
3
IntroduçãoSerá esta a Solução? Buscar a complexidade, ao invés da simplicidade…
Uma grande solução para nossos problemas ... Ou um grande problema para nossas soluções?
Buscar a documentação escrita, ao invés da comunicação … Gera problemas na qualidade do produto … ou na qualidade do
processo? Desprezar a realimentação durante o desenvolvimento …
Entregar tudo no final, sem ouvir o usuário, e descobrir que … Insistir no erro, sem ter coragem para mudar …
É preciso investir em novas tecnologias … e rever a forma comorealizamos nosso negócio …
4
IntroduçãoO Novo Problema ... Por mais que as metodologias tenham definido processos e
controles, os resultados estão longe dos esperados … Esta receita não funciona para o desenvolvimento de software:
Um software é, pela sua própria natureza, intangível É impossível antever todas as suas funcionalidades As necessidades emergem durante todo o seu desenvolvimento, e vão
amadurecendo até a sua implantação A utilização do software aprimora os seus recursos
Introdução - Paradigma Abordagem tradicional:
Parte de um escopo fechado; Define-se custo e prazo; Manipula-se a qualidade.
Por que não … Ter um prazo predefinido; Ter um custo fixo, definido em
função do prazo; Manter os níveis de qualidade; Manipular o escopo?
5
Por que não … Fazer o mais simples agora, e refinar depois? Mudar quando for necessário? Libertar-se do excesso de documentação?
Clientes pagam por software, não por documentação A Qualidade é que faz a diferença …
6
IntroduçãoO que fazer? Construir o software de forma evolutiva e adptativa
Começar de forma mais simples possível: apenas com o planejamento e design necessários
Resolver as necessidades mais claras e críticas: agregando valor ao produto e entregando algum resultado rapidamente
Objetivo: ter um software em operação o mais rápido possível, paraque ele tenha chance de evoluir.
Investir ao máximo em simplicidade: desta forma, a mudança deixade ser traumática e passa a ser natural
Para colocar essas idéias em prática, é preciso mudar a forma de se negociar e desenvolver software.
Introdução - Vantagens Para o cliente:
Obter um produto inicial com rapidez, resolvendo problemas críticos;
Defini-lo em versões, em função das necessidades reais e mais críticas
Investir em funcionalidade que realmente serão utilizadas
Correr menos risco no investimento
Manter os envolvidos no processo mais confiantes no resultado
Para o desenvolvedor: Satisfazer às necessiddaes
reais do cliente, deixando-o mais motivado para realizar negócios futuros
Ter certeza de que está desenvolvendo o produto correto
Manter a equipe menos desgastada e mais motivada
Correr menos risco na contratação
Obter sucesso nos projetos, trazendo novas oportunidades
7
8
Metodologias ÁgeisManifesto Ágil“Estamos evidenciando maneiras melhores de desenvolver software,
fazendo-o nós mesmo e ajudando outros a fazê-lo.Através desse trabalho, passamos a valorizar:
Indivíduos e interação MAIS QUE processos e ferramentas Software em funcionamento MAIS QUE documentação abrangente Colaboração com o cliente MAIS QUE negociação de contratos Responder a mudanças MAIS QUE seguir um plano
Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.”
9
Metodologias ÁgeisOs 12 Princípios da Agilidade Princípio 1:
A mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor.
Princípio 2: Receba bem as mudanças de requisitos, mesmo em estágios tardios
do desenvolvimento. Processos ágeis devem admitir mudanças que fazem vantagens competitivas para o cliente.
Princípio 3: Libere software frequentemente (em intervalos de 2 semanas até 2
meses), dando preferência para uma escala de tempo mais curta.
10
Metodologias ÁgeisOs 12 Princípios da Agilidade Princípio 4:
Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto.
Princípio 5: Construa projetos com indivíduos motivados, dê a eles o ambiente e
suporte que precisam e confie neles para ter o trabalho realizado. Princípio 6:
O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face.
11
Metodologias ÁgeisOs 12 Princípios da Agilidade Princípio 7:
Software funcionando é a principal medida de progresso de um projeto de software.
Princípio 8: Processos ágeis promovem desenvolvimento sustentado. Assim,
patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.
Princípio 9: A atenção contínua para a excelência técnica e um bom projeto
(design) aprimoram a agilidade.
12
Metodologias ÁgeisOs 12 Princípios da Agilidade Princípio 10:
Simplicidade – a arte de maximar a quantidade de trabalho não feito – é essencial, devendo ser assumida em todos os aspectos do projeto.
Princípio 11: As melhores arquiteturas, requisitos e projetos emergem de equipes
auto-organizadas. Princípio 12:
Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.
13
Agenda LEAN Kanban EXtreme Programming SCRUM Feature Driven Development
14
LEAN Modelo fabril por volta 1948 e 1975 pela Toyota Motor Associado ao conceito de magro, sem desperdício, sem excesso. Otimização do fluxo de produção através do aumento da eficiência
e da produtividade dos trabalhos. Passa em grande parte pela automação de processos e pelo ajuste
“na hora certa” das necessidades de produção o que significa que a produção é controlada pela necessidade. A produção é puxada “pull” em vez de empurrada “push”
15
LEAN Sistema “push”
Generalidade dos mercados rege-se pela oferta A produção é desenvolvida com base histórica na procura e aplicada
para o presente e futuro Push – Desenvolvimento – Produção – Divulgação – Necessidade
Sistema “pull” Baseado na oferta é regido pela necessidade de produção e preparado
para receber os inputs do mercado de procura Apenas se produz o que é requisitado Pull – Necessidade – Divulgação – Desenvolvimento – Produção
16
LEAN Por que o LEAN vem sendo utilizado para desenvolvimento de
software? Setes Princípios:
Eliminar peso Ampliar o aprendizado Decidir o mais tarde possível Entregar o mais cedo possível Fortalecer o time Construir integridade Ver o todo
17
LEAN Práticas do Lean Software:
Vendo resíduos Mapeamento de fluxo de valor Baseado em desenvolvimento Sistema Pull Teoria das filas Motivação Medições
18
Kanban É uma palavra japonesa que significa “sinal visual” ou “cartão” Originada pelo Sistema Toyota de Produção, realizada por
acadêmicos americanos. Manufatura Enxuta (Lean Manufacturing)
É uma técnica usada para implementar o conceito de Sistema Pull A saída de produtos acabados, ao final da linha de montagem, dita o
ritmo da introdução de matéria-prima no sistema Evitando acúmulos de produtos inacabados ao longo da linha Diminuindo a quantidade de Trabalho em Processo (WIP – Work in
Process).
19
Kanban Com menos produtos intermediários temos uma sobrecarga menor
no sistema e podemos nos adaptar melhor e mais rápido às mudanças na demanda dos clientes.
Ao limitar o WIP também diminuímos a multitarefa nociva, principal responsável por atrasos, problemas de qualidade, estresse e insatisfação
Kanban complementa muito bem as abordagens Ágeis, como FDD, Scrum e XP Também pode ser usada com métodos tradicionais
Kanban - Software As 5 propriedades centrais
de uma implementação Kanban: Limitar o Trabalho em Processo; Visualizar o Fluxo de Trabalho Medir o Otimizar o Fluxo Tornar Explícitas as Políticas do
Processo Gerenciar Quantitativamente
As 5 propriedades emergentes esperadas em uma implementação Kanban: Priorizar o Trabalho pelo Custo da
Demora Otimizar o Valor com Classe de
Serviço Espalhar o Risco com a Alocação
de Capacidade Encorajar a Inovação do Processo Usar Modelos para reconhecer
oportunidades de melhoria
20
21
XP – Extreme ProgrammingCaracterísticas: Emprega “ao extremo” boas práticas da engenharia de software É de domínio público, voltado para o desenvolvimento Especialmente adequada para equipes pequenas (2-10 pessoas)
trabalhando em projetos com requisitos imprecisos e instáveis Para projetos grandes: dividir em subprojetos independentes Para projetos longos: quebra em sequencia de mini-projetos auto-
contidos, com duração de 1-3 semanas Descrita por meio de valores, princípios e práticas
22
XP – Extreme ProgrammingBoas Práticas: Rever o código:
O código é desenvolvido por pares de programadores que trabalham juntos em uma mesma máquina, possibilitando rever o código o tempo todo
Testar o código: Todos os testes devem ser automatizados e executados várias vezes
ao dia, com integração contínua Envolver o cliente:
O cliente deverá estar no local de desenvolvimento, fazendo parte da equipe do projeto XP
23
XP – Extreme ProgrammingValores Comunicação:
Fundamental para a compreensão do trabalho a ser feito e entrosamento da equipe
Simplicidade: É preferível fazer algo simples e gastar um pouco mais para alterar, se
necessário, do que fazer algo complicado e não utilizar Realimentação (feedback):
É muito importante ter uma idéia clara sobre a situação atual do sistemas Maior realimentação -> facilidade de comunicação, teste e aprendizado
Coragem Algo que não funcione adequadamente deve ser descartado e refeito, de
forma mais simples
24
XP – Extreme ProgrammingPrincípios básicos Proporcinar a pequenas / médias equipes em ambiente de
desenvolvimento cooperativo, capaz de atingir altos níveis de produtividade e um elevado grau de confiança.
25
XP – Extreme ProgrammingAtividades básicas do desenvolvimento XP: Projetar, codificar, testar e escutar (o cliente e a equipe) Planejamento do desenvolvimento do tipo “just in time”
As práticas estruturam as atividades e seguem os princípios, sustentando os valores definidos
26
XP – Extreme ProgrammingPapéis Programador: projetar, codificar, implementar testes e estimar tarefas Cliente: estabelecer prioridades e escopo, escrever estórias e os testes
funcionais, esclarecer dúvidas dos programadores Testador (tester): apoiar o cliente na escolha e definição de testes
funcionais, assegurar sua execução e relatar problemas identificados Acompanhador (tracker): reportar as métricas do projeto, promover
visibilidade (estimado/realizado) – é a consciência da equipe Técnico (coach): Identificar problemas e resolvê-los para que a equipe
possa trabalhar melhor Não requer conhecimento técnico profundo e assemelha-se a um gerente
de projeto
27
XP – Extreme Programming Ambientes onde XP é inadequado
Cultura da documentação Comprometimento medido por horas extras de trabalho Dificuldade para mudanças Demora para obtenção de realimentação Impossibilidade de realizar testes automáticos Resistência cultural
Principais Críticas Dificuldade de manutenção pela falta de documentação Efetividade da programação em pares: custo x benefício Sucesso dependente da competência das pessoas Dificuldade de se ter o cliente no local Dificuldade de estabelecer contrato com escopo variável Requer colaboração e confiança entre equipe e cliente
28
Scrum É fundamentado na teoria de controle de processos empíricos,
emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
Sustentada por três pilares: Transparência: garante que aspectos do processo que afetam o resultado
devem ser visíveis para aqueles que gerenciam os resultados Inspeção: os diversos aspectos do processo devem ser inspecionados
com uma frequencia suficiente para que variações inaceitáveis no processo possam ser detectadas. Reunião diária, Revisão da Sprint e de Planejamento da Sprint, Retrospectiva
da Sprint. Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou
mais aspectos do processo estão for a dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.
29
Scrum Formado por Times Scrum e seus papéis associados, Eventos com
Duração Fixa (Time-Boxes), Artefatos e Regras.Papéis: ScrumMaster, que é o responsável por garantir que o processo seja
entendido e seguido Product Owner, que é responsável por maximizar o valor do trabalho
que o Time Scrum faz Time, que executa o trabalho propriamente dito.
Eventos com Duração Fixa (Time-Boxes): Reunião de Planejamento da Versão para Entrega, A Sprint, a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Reunião Diária.
30
ScrumArtefatos do Scrum: Backlog do Produto, o Burndown da Versão para
Entrega, o Backlog da Sprint e o Burndown da Sprint
31
Scrum - Ciclo
32
FDD – Feature Driven Development É uma metodologia ágil para gerenciamento e desenvolvimento de
software. Ela combina as melhores práticas do gerenciamento ágil de projetos
com uma abordagem completa para Engenharia de Software orientada por objetos.
Criado em 1997 num grande projeto em Java para o United Overseas Bank em Cingapura por Peter Coad e Jeff de Luca.
33
FDD – Características Resultados úteis a cada duas semanas ou menos Blocos bem pequenos de funcionalidade valorizada pelo cliente,
Features Não existem restrições quanto à complexidade do sistema e tamanho
da equipe Planejamento detalhado e guia para medição Rastreabilidade e relatórios com precisão Monitoramento detalhado dentro do projeto, com resumos de alto nível
para clientes e gerentes, tudo em termos de negócio Fornece uma forma de saber, dentro dos primeiros 10% de um projeto,
se o plano e a estimativa são sólidos
34
FDD – Padrões“ETVX” Entry – Entrada: define e especifica critérios de entrada para as fases
do FDD Task – Tarefa: é composto por uma lista de tarefas a ser realizada a
cada uma das fases Verification – Verificação: especifica tipos de avaliações e inspeções
de projeto e códigos “testes” Exit – Saída: especifica os critérios de saída ou seja os critérios de
“pronto” da fase
35
FDD – Práticas Modelagem dos objetos de domínio Desenvolvendo através de funcionaludades Propriedade individual das classes Equipes de funcionalidades Inspeções Construções regulares Administração de configuração Relatórios de resultados
36
FDD – Papéis Principais
Gerente de projeto, Arquiteto chefe, Gerente de desenvolvimento, Programador chefe, Proprietário de classe, Especialista do domínio
Apoio Gerente do domínio, Gerente de versão, Especialista de Linguagem,
Coordenador de contrução, Ferramenteiro (toolsmith), Administrador de Sistema
Adicionais Testador, Desenvolvedores, Escritor Técnico
37
FDD – Fases A FDD é uma metodologia muito objetiva que possui cinco fases e
essas podem ser divididas em duas etapas: Concepção & Planejamento: Pensar no modelo, criar uma lista de
características e planejar através delas. Essa fase é executada apenas uma vez e dura de uma a duas semanas.
Construção: Desenvolvimento iterativo e incremental durante um período de tempo de no máximo 2 semanas.
Engenharia de Software
Ph.D Students Prof. Ms.C. Paulino Wagner Palheta Viana
Manaus, outubro 2013 38