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