Engenharia de Software

Ph.D Students Prof. Ms.C. Paulino Wagner Palheta Viana Manaus, outubro 2013
1

Introduo
O Dilema da Construo de Software Projetos de software sempre foram marcados por fracassos:
Prazos e oramentos no cumpridos Expectativas no satisfeitas Retorno muito menor que o esperado Impossvel satisfazer ao mesmo tempo custo, prazo, escopo e qualidade

A Soluo ... Construo de software = construo 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 execuo com gerenciamento e processos bem definidos

Introduo
Ser esta a Soluo? Buscar a complexidade, ao invs da simplicidade

Uma grande soluo para nossos problemas ... Ou um grande problema para nossas solues? Gera problemas na qualidade do produto ou na qualidade do processo? Entregar tudo no final, sem ouvir o usurio, e descobrir que preciso investir em novas tecnologias e rever a forma como realizamos nosso negcio

Buscar a documentao escrita, ao invs da comunicao

Desprezar a realimentao durante o desenvolvimento

Insistir no erro, sem ter coragem para mudar

Introduo
O Novo Problema ... Por mais que as metodologias tenham definido processos e controles, os resultados esto longe dos esperados Esta receita no funciona para o desenvolvimento de software:
Um software , pela sua prpria natureza, intangvel impossvel antever todas as suas funcionalidades As necessidades emergem durante todo o seu desenvolvimento, e vo amadurecendo at a sua implantao A utilizao do software aprimora os seus recursos

Introduo - Paradigma

Abordagem tradicional:
Parte de um escopo fechado; Define-se custo e prazo; Manipula-se a qualidade.

Por que no
Ter um prazo predefinido; Ter um custo fixo, definido em funo do prazo; Manter os nveis de qualidade; Manipular o escopo?

Por que no Fazer o mais simples agora, e refinar depois? Mudar quando for necessrio? Libertar-se do excesso de documentao?
Clientes pagam por software, no por documentao A Qualidade que faz a diferena

Introduo
O que fazer? Construir o software de forma evolutiva e adptativa
Comear de forma mais simples possvel: apenas com o planejamento e design necessrios Resolver as necessidades mais claras e crticas: agregando valor ao produto e entregando algum resultado rapidamente Objetivo: ter um software em operao o mais rpido possvel, para que ele tenha chance de evoluir. Investir ao mximo em simplicidade: desta forma, a mudana deixa de ser traumtica e passa a ser natural

Para colocar essas idias em prtica, preciso mudar a forma de se negociar e desenvolver software.
6

Introduo - Vantagens

Para o cliente:

Para o desenvolvedor:

Obter um produto inicial com rapidez, resolvendo problemas crticos; Defini-lo em verses, em funo das necessidades reais e mais crticas Investir em funcionalidade que realmente sero utilizadas Correr menos risco no investimento Manter os envolvidos no processo mais confiantes no resultado

Satisfazer s necessiddaes reais do cliente, deixando-o mais motivado para realizar negcios futuros Ter certeza de que est desenvolvendo o produto correto Manter a equipe menos desgastada e mais motivada Correr menos risco na contratao Obter sucesso nos projetos, trazendo novas oportunidades
7

Metodologias geis
Manifesto gil Estamos evidenciando maneiras melhores de desenvolver software, fazendo-o ns mesmo e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar:
Indivduos e interao MAIS QUE processos e ferramentas Software em funcionamento MAIS QUE documentao abrangente Colaborao com o cliente MAIS QUE negociao de contratos Responder a mudanas MAIS QUE seguir um plano

Ou seja, mesmo tendo valor os itens direita, valorizamos mais os itens esquerda.

Metodologias geis
Os 12 Princpios da Agilidade Princpio 1:

A mais alta prioridade a satisfao do cliente, por meio da liberao mais rpida e contnua de software de valor. Receba bem as mudanas de requisitos, mesmo em estgios tardios do desenvolvimento. Processos geis devem admitir mudanas que fazem vantagens competitivas para o cliente. Libere software frequentemente (em intervalos de 2 semanas at 2 meses), dando preferncia para uma escala de tempo mais curta.

Princpio 2:

Princpio 3:

Metodologias geis
Os 12 Princpios da Agilidade Princpio 4:

Mantenha pessoas ligadas ao negcio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto. Construa projetos com indivduos motivados, d a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado. O mtodo mais eficiente e efetivo para repassar informao entre uma equipe de desenvolvimento pela comunicao face-a-face.

Princpio 5:

Princpio 6:

10

Metodologias geis
Os 12 Princpios da Agilidade Princpio 7:

Software funcionando a principal medida de progresso de um projeto de software. Processos geis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usurios devem ser capazes de manter conversao pacfica indefinidamente. A ateno contnua para a excelncia tcnica e um bom projeto (design) aprimoram a agilidade.

Princpio 8:

Princpio 9:

11

Metodologias geis
Os 12 Princpios da Agilidade Princpio 10:

Simplicidade a arte de maximar a quantidade de trabalho no feito essencial, devendo ser assumida em todos os aspectos do projeto. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e ento refinarem e ajustarem seu comportamento de acordo.

Princpio 11:

Princpio 12:

12

Agenda

LEAN Kanban EXtreme Programming SCRUM Feature Driven Development

13

LEAN

Modelo fabril por volta 1948 e 1975 pela Toyota Motor Associado ao conceito de magro, sem desperdcio, sem excesso. Otimizao do fluxo de produo atravs do aumento da eficincia e da produtividade dos trabalhos. Passa em grande parte pela automao de processos e pelo ajuste na hora certa das necessidades de produo
o que significa que a produo controlada pela necessidade. A produo puxada pull em vez de empurrada push

14

LEAN

Sistema push
Generalidade dos mercados rege-se pela oferta A produo desenvolvida com base histrica na procura e aplicada para o presente e futuro Push Desenvolvimento Produo Divulgao Necessidade

Sistema pull
Baseado na oferta regido pela necessidade de produo e preparado para receber os inputs do mercado de procura Apenas se produz o que requisitado Pull Necessidade Divulgao Desenvolvimento Produo

15

LEAN

Por que o LEAN vem sendo utilizado para desenvolvimento de software? Setes Princpios:

Eliminar peso Ampliar o aprendizado Decidir o mais tarde possvel Entregar o mais cedo possvel Fortalecer o time Construir integridade Ver o todo

16

LEAN

Prticas do Lean Software:

Vendo resduos Mapeamento de fluxo de valor Baseado em desenvolvimento Sistema Pull Teoria das filas Motivao Medies

17

Kanban

uma palavra japonesa que significa sinal visual ou carto Originada pelo Sistema Toyota de Produo, realizada por acadmicos americanos.

Manufatura Enxuta (Lean Manufacturing)

uma tcnica usada para implementar o conceito de Sistema Pull

A sada de produtos acabados, ao final da linha de montagem, dita o ritmo da introduo de matria-prima no sistema Evitando acmulos de produtos inacabados ao longo da linha Diminuindo a quantidade de Trabalho em Processo (WIP Work in Process).

18

Kanban

Com menos produtos intermedirios temos uma sobrecarga menor no sistema e podemos nos adaptar melhor e mais rpido s mudanas na demanda dos clientes. Ao limitar o WIP tambm diminumos a multitarefa nociva, principal responsvel por atrasos, problemas de qualidade, estresse e insatisfao Kanban complementa muito bem as abordagens geis, como FDD, Scrum e XP

Tambm pode ser usada com mtodos tradicionais

19

Kanban - Software

As 5 propriedades centrais de uma implementao Kanban:

Limitar o Trabalho em Processo; Visualizar o Fluxo de Trabalho Medir o Otimizar o Fluxo Tornar Explcitas as Polticas do Processo Gerenciar Quantitativamente

As 5 propriedades emergentes esperadas em uma implementao Kanban:

Priorizar o Trabalho pelo Custo da Demora Otimizar o Valor com Classe de Servio Espalhar o Risco com a Alocao de Capacidade Encorajar a Inovao do Processo Usar Modelos para reconhecer oportunidades de melhoria

20

XP Extreme Programming
Caractersticas: Emprega ao extremo boas prticas da engenharia de software de domnio pblico, voltado para o desenvolvimento Especialmente adequada para equipes pequenas (2-10 pessoas) trabalhando em projetos com requisitos imprecisos e instveis
Para projetos grandes: dividir em subprojetos independentes Para projetos longos: quebra em sequencia de mini-projetos autocontidos, com durao de 1-3 semanas

Descrita por meio de valores, princpios e prticas

21

XP Extreme Programming
Boas Prticas: Rever o cdigo:

O cdigo desenvolvido por pares de programadores que trabalham juntos em uma mesma mquina, possibilitando rever o cdigo o tempo todo Todos os testes devem ser automatizados e executados vrias vezes ao dia, com integrao contnua O cliente dever estar no local de desenvolvimento, fazendo parte da equipe do projeto XP

Testar o cdigo:

Envolver o cliente:

22

XP Extreme Programming
Valores Comunicao:

Fundamental para a compreenso do trabalho a ser feito e entrosamento da equipe prefervel fazer algo simples e gastar um pouco mais para alterar, se necessrio, do que fazer algo complicado e no utilizar

Simplicidade:

Realimentao (feedback):
muito importante ter uma idia clara sobre a situao atual do sistemas Maior realimentao -> facilidade de comunicao, teste e aprendizado

Coragem

Algo que no funcione adequadamente deve ser descartado e refeito, de forma mais simples
23

XP Extreme Programming
Princpios bsicos Proporcinar a pequenas / mdias equipes em ambiente de desenvolvimento cooperativo, capaz de atingir altos nveis de produtividade e um elevado grau de confiana.

24

XP Extreme Programming
Atividades bsicas do desenvolvimento XP: Projetar, codificar, testar e escutar (o cliente e a equipe) Planejamento do desenvolvimento do tipo just in time

As prticas estruturam as atividades e seguem os princpios, sustentando os valores definidos

25

XP Extreme Programming
Papis Programador: projetar, codificar, implementar testes e estimar tarefas Cliente: estabelecer prioridades e escopo, escrever estrias e os testes funcionais, esclarecer dvidas dos programadores Testador (tester): apoiar o cliente na escolha e definio de testes funcionais, assegurar sua execuo e relatar problemas identificados Acompanhador (tracker): reportar as mtricas do projeto, promover visibilidade (estimado/realizado) a conscincia da equipe Tcnico (coach): Identificar problemas e resolv-los para que a equipe possa trabalhar melhor

No requer conhecimento tcnico profundo e assemelha-se a um gerente de projeto

26

XP Extreme Programming

Ambientes onde XP inadequado

Cultura da documentao Comprometimento medido por horas extras de trabalho Dificuldade para mudanas Demora para obteno de realimentao Impossibilidade de realizar testes automticos Resistncia cultural Dificuldade de manuteno pela falta de documentao Efetividade da programao em pares: custo x benefcio Sucesso dependente da competncia das pessoas Dificuldade de se ter o cliente no local Dificuldade de estabelecer contrato com escopo varivel Requer colaborao e confiana entre equipe e cliente
27

Principais Crticas

Scrum

fundamentado na teoria de controle de processos empricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Sustentada por trs pilares:
Transparncia: garante que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados Inspeo: os diversos aspectos do processo devem ser inspecionados com uma frequencia suficiente para que variaes inaceitveis no processo possam ser detectadas.

Reunio diria, Reviso da Sprint e de Planejamento da Sprint, Retrospectiva da Sprint.

Adaptao: Se o inspetor determinar, a partir da inspeo, que um ou mais aspectos do processo esto for a dos limites aceitveis e que o produto resultante ser inaceitvel, ele dever ajustar o processo ou o material sendo processado.
28

Scrum
Formado por Times Scrum e seus papis associados, Eventos com Durao Fixa (Time-Boxes), Artefatos e Regras. Papis: ScrumMaster, que o responsvel por garantir que o processo seja entendido e seguido Product Owner, que responsvel por maximizar o valor do trabalho que o Time Scrum faz Time, que executa o trabalho propriamente dito.

Eventos com Durao Fixa (Time-Boxes): Reunio de Planejamento da Verso para Entrega, A Sprint, a Reunio de Planejamento da Sprint, a Reviso da Sprint, a Retrospectiva da Sprint e a Reunio Diria.
29

Scrum
Artefatos do Scrum: Backlog do Produto, o Burndown da Verso para Entrega, o Backlog da Sprint e o Burndown da Sprint

30

Scrum - Ciclo

31

FDD Feature Driven Development

uma metodologia gil para gerenciamento e desenvolvimento de software. Ela combina as melhores prticas 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.

32

FDD Caractersticas

Resultados teis a cada duas semanas ou menos Blocos bem pequenos de funcionalidade valorizada pelo cliente, Features No existem restries quanto complexidade do sistema e tamanho da equipe Planejamento detalhado e guia para medio Rastreabilidade e relatrios com preciso Monitoramento detalhado dentro do projeto, com resumos de alto nvel para clientes e gerentes, tudo em termos de negcio Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa so slidos

33

FDD Padres
ETVX Entry Entrada: define e especifica critrios de entrada para as fases do FDD Task Tarefa: composto por uma lista de tarefas a ser realizada a cada uma das fases Verification Verificao: especifica tipos de avaliaes e inspees de projeto e cdigos testes Exit Sada: especifica os critrios de sada ou seja os critrios de pronto da fase

34

FDD Prticas

Modelagem dos objetos de domnio Desenvolvendo atravs de funcionaludades Propriedade individual das classes Equipes de funcionalidades Inspees Construes regulares Administrao de configurao Relatrios de resultados

35

FDD Papis

Principais

Gerente de projeto, Arquiteto chefe, Gerente de desenvolvimento, Programador chefe, Proprietrio de classe, Especialista do domnio Gerente do domnio, Gerente de verso, Especialista de Linguagem, Coordenador de contruo, Ferramenteiro (toolsmith), Administrador de Sistema Testador, Desenvolvedores, Escritor Tcnico

Apoio

Adicionais

36

FDD Fases

A FDD uma metodologia muito objetiva que possui cinco fases e essas podem ser divididas em duas etapas:
Concepo & Planejamento: Pensar no modelo, criar uma lista de caractersticas e planejar atravs delas. Essa fase executada apenas uma vez e dura de uma a duas semanas. Construo: Desenvolvimento iterativo e incremental durante um perodo de tempo de no mximo 2 semanas.

37

Engenharia de Software

Ph.D Students Prof. Ms.C. Paulino Wagner Palheta Viana Manaus, outubro 2013
38