Você está na página 1de 120

Um novo conceito em Educao

INSTITUTO TOCANTINENSE DE EDUCAO SUPERIOR E PESQUISA LTDA FACULDADE ITOP


Construindo competncias que agregam valor profissional

MBA EM GESTO DA TECNOLOGIA DA INFORMAO

Mdulo: Processo de Desenvolvimento de Software


Prof. Ms. Alessandro C M de Arajo
alessandrcma@gmail.com

FORMAO: GRADUADO EM CINCIA DA COMPUTAO PELA UFG/GO. MESTRE EM CINCIA DA COMPUTAO COM NFASE EM ENGENHARIA DE SOFTWARE PELA UFPE/PE. CERTIFICAES: PMP (PROJECT MANAGEMENT PROFESSIONAL), COBIT, ITIL e SCJP (JAVA PROGRAMMER) ATUAL GERENTE DE PROCESSOS E SISTEMAS DA SECRETRIA DE GESTO E PLANEJAMENTO DO ESTADO DE GOIS.

PROCESSOS DE SOFTWARE
1

INTRODUO

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Bibliografia
2

Engenharia de Software
I. Sommerville, Software Engineering, 6th Edition, Addison Wesley Longman, 2000. R. S. Pressman, Software Engineering: A Practioner's Approach, IE-McGraw-Hill, 4th Edition, 1996. (*)

(*) Disponvel em Portugus

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Importncia do Software
3

Dependncia generalizada da vida moderna em sistemas de computao. O software parte cada vez maior dos custos e do sucesso desses sistemas. Produzir software um atividade inerentemente complexa:
independe de leis fsicas, restries de materiais e processos de manufatura.

Requer mtodos disciplinados de desenvolvimento.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O que um Software?
4

Programas
Arquivos de cdigo

Dados de configurao
Arquivos de instalao e reconstruo

Documentao
Manuais do usurio Manuais do sistema Web sites

Produto da Engenharia de Software

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Qualidade de Software
5

Um Software de Qualidade deve encantar o consumidor, e no apenas funcionar direito e no ter erros. Bill Gates

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Atributos de Qualidade de um Software


6

Dependem da aplicao. Relacionados com o comportamento (execuo) do sistema e a organizao de seus documentos e cdigo fonte. Atributos essenciais:
Manutenibilidade Confiabilidade Eficincia Usabilidade

Outros atributos?
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Qualidade de Software (um exemplo para o Varejo)


7

Correto
A loja no pode deixar de cobrar por produtos comprados pelo consumidor.

Robusto e altamente disponvel


A loja no pode parar de vender.

Eficiente
O consumidor no pode esperar. A empresa quer investir pouco em recursos computacionais (CPU, memria, rede).

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Qualidade de Software (um exemplo para o Varejo)


8

Amigvel e fcil de usar


A empresa quer investir pouco em treinamento.

Altamente extensvel e adaptvel


A empresa tem sempre novos requisitos (para ontem!). A empresa quer o software customizado do seu jeito (interface, teclado, idioma, moeda, etc.).

Reusvel
Vrias empresas precisam usar partes de um mesmo sistema.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Qualidade de Software (um exemplo para o Varejo)


9

Aberto, compatvel, de fcil integrao com outros sistemas


A empresa j tem controle de estoque, fidelizao, etc.

Portvel e independente de plataforma (hw e sw)


A empresa opta por uma determinada plataforma.

Baixo custo de instalao e atualizao


A empresa tem um grande nmero de PDVs.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O que a Engenharia de Software?


10

Uma disciplina de engenharia voltada para todos os aspectos da produo de software de qualidade.
Processos, modelos e metodologias de desenvolvimento Gerncia de projeto Investigao de novos mtodos, ferramentas e teorias

Envolve a escolha seletiva de mtodos e ferramentas adequados para o contexto (restries) do sistema. Abrange desde a especificao inicial do sistema at sua operao e manuteno.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Por que estudar E.S.?


11

Custo com software versus hardware. Desastres no desenvolvimento de software.


Aumento de custo, atraso na entrega Funcionalidade reduzida ou errada, documentao inexistente

Falhas atribudas a software


Therac 25 (excesso de radiao em raio-x) Ariane V (queda de um foguete)

Custo com falha se tornando alto


Financeiro Perda de vida e equipamento

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Causas da Crise de Software


12

Essenciais
Complexidade dos sistemas Dificuldade de formalizao

Acidentais
M qualidade dos mtodos, linguagens, ferramentas, processos, e modelos de ciclo de vida Falta de qualificao tcnica

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Por que estudar E.S.?


13

Um estudo desenvolvido pelo Standish Group identificou que as empresas de software dos Estados Unidos:
Gastaram $81 milhes em projetos de software que foram cancelados em 1995; 31% dos projetos de software estudados foram cancelados antes de estarem concludos; 53% dos projetos de software excedem mais do que 50% a sua estimativa de custo; e, somente 9% dos projetos, em grandes empresas, foram entregues no tempo e oramento.

A manuteno e reutilizao so difceis e custosas. Os problemas so proporcionais a complexidade dos sistemas.


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Por que estudar E. S. ?


14

Neste contexto, estes dados indicam as seguintes concluses:


O desenvolvimento de software ainda imprevisvel; Somente 10% dos projetos de software so entregues com sucesso dentro das estimativas de oramento e custo; O esforo para construir software confivel e de qualidade muito grande; A sociedade depende cada vez mais de software confivel; quando ele falha, podem ocorrer prejuzos; O nvel de software jogado fora e que tem necessidade de retrabalho um indicativo de processo imaturo.

As prticas de construo de software devem ser melhoradas para que se tenha sucesso nos projetos de tecnologia da informao. A preocupao em resolver essas questes tem levado adoo da Engenharia de Software.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Engenharia de Software
15

Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a rea de pesquisa denominada Engenharia de Software. A Engenharia de Software busca organizar esforos no desenvolvimento de ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software. Consiste na aplicao de uma abordagem sistemtica, disciplinada e quantificvel ao desenvolvimento, operao e manuteno de software. A Engenharia de Software pode ser vista em camadas:

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Engenharia de Software
16

Qualidade: permite o desenvolvimento crescente de abordagens mais maduras para a Engenharia de Software Processo: a cola que gruda as camadas de tecnologias e permite um desenvolvimento de software racional e no prazo estimado Mtodos: englobam um conjunto de tarefas que definem como fazer Ferramentas: so os instrumentos apropriados que do suporte automatizado ou semi-automatizado ao processo e aos mtodos
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Engenharia de Software
17

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Engenharia de Software
18

A Engenharia de Software se preocupa com o software enquanto produto. O valor de um produto vem de suas caractersticas. Os requisitos so as caractersticas que definem os critrios de aceitao de um produto. Planejar prazos e custos faz parte da rotina de qualquer ramo da engenharia. Porm, todo plano comporta incertezas.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Engenharia de Software
19

Aps planejar, preciso controlar o projeto de software, o que compreende:


o acompanhamento do progresso dos projetos, comparando-se o planejado com o realizado; a busca de alternativas para contornar problemas surgidos na execuo dos projetos; o re-planejamento dos projetos, quando no possvel manter os planos anteriores dentro de um grau razovel de variao; a renegociao dos compromissos assumidos, envolvendo todas as partes interessadas.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Dificuldades associadas a Engenharia de Software


20

A engenharia de software diferente das outras engenharias. Requer mais disciplina gerencial, e no menos. Na maioria das engenharias, as leis fsicas impem limites claramente visveis ao que pode ser feito. Na engenharia de software, a criatividade limitada pela capacidade humana de entender e dominar a complexidade. Para manter a complexidade sob controle, os gerentes devem exigir planos detalhados, e sistemas de acompanhamento destes planos, com pontos de controle bem definidos.
Em outras palavras, os gerentes podem e devem exigir respostas claras para perguntas simples.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

10

Organizaes e sua Maturidade quanto a E.S.


21

A maturidade de uma organizao em Engenharia de Software mede o grau de competncia, tcnica e gerencial, que esta organizao possui para produzir software de boa qualidade, dentro de prazos e custos razoveis e previsveis. Infelizmente para os profissionais, muitas organizaes que produzem software so imaturas.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Maturidade das Organizaes de Software


22

Em organizaes com baixa maturidade de capacitao em software, os processos geralmente so informais. Processos informais existem apenas na cabea de seus praticantes, geralmente so processos individuais. Podem ser parcialmente transferidos para outras pessoas, por transmisso oral e por imitao. Por outro lado, um processo definido tem documentao que detalha todos os seus aspectos importantes: o que feito, quando, por quem, as coisas que usa e as coisas que produz.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

11

O que fazer para atingir a Maturidade


23

Investir na capacitao das pessoas absolutamente necessrio. Entretanto, formar pessoas difcil, caro e demorado. Dos investimentos nos fatores de produo, a escolha por processos pode ser a mais adequada. Processos tambm no fazem milagres por si s, mas a implantao e melhoria dos processos trazem retorno em prazos relativamente curtos.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Maturidade das Organizaes de Software


24

Para tornar uma organizao mais madura e capacitada, realmente preciso melhorar a qualidade dos seus processos. Processos no melhoram simplesmente por estarem de acordo com um padro externo. O critrio de verdadeiro xito dos processos a medida de quanto eles contribuem para que os produtos sejam entregues aos clientes e usurios:
com melhor qualidade; por menor custo; em prazo mais curto.

Ou seja, bons processos devem ajudar a produzir: melhor; mais barato; mais rpido.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

12

Elementos e Atividades da Engenharia de Software


25

Elementos
Modelos do ciclo de vida do software Linguagens Mtodos Ferramentas Processos

Atividades
Modelagem do negcio Elicitao de requisitos Anlise e Projeto Implementao Testes Distribuio Planejamento Gerenciamento Gerncia de Configurao e Mudanas Manuteno

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Processo
26

Feiler & Humphrey


Um conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo.

Jacobson, Booch, Rumbaugh


Define quem est fazendo o qu, quando e como para atingir um certo objetivo.

CMM
Um conjunto de atividades, mtodos, prticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

13

Definio de Processo de Software


27

Procedimentos e mtodos que definem o relacionamento de tarefas.

B A C D

PROCESSO
Pessoas com habilidades, treinamento e motivao
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Ferramentas e Equipamentos

Processo de Software
28

Um processo de software um conjunto estruturado de atividades (ou fases) necessrias para produzir um produto de software
Planejamento Especificao Projeto Implementao Validao Manuteno/Evoluo

Organizado segundo diferentes Modelos de Desenvolvimento


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

14

Modelo de Desenvolvimento
29

Representao abstrata das fases de um processo de software e suas interdependncias Modelos genricos
Cascata (ou Clssico) Iterativo (ou Evolucionrio) Espiral 4GL / Transformao formal Reuso de componentes Sincronizao e estabilizao (software para Internet) Programao extrema

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O Modelo Cascata
30

Especificao

Projeto

Implementao

Validao

Manuteno

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

15

Caractersticas do Modelo Cascata


31

Abordagem sistemtica e seqencial Processo organizado em fases distintas e separadas Baseado nos processo convencionais de engenharia Requer especificao completa e bem entendida Dificulta a introduo de mudanas aps o incio do processo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O Modelo Iterativo Incremental


Atividades Concorrentes
Especificao Verso Inicial
32

Descrio Inicial

Desenvolvimento

Verses Intermedirias

Validao

Verso Final

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

16

Caractersticas do Modelo Iterativo


33

Ciclos de desenvolvimento Fases entrelaadas Especificao evolui junto com o sistema Suporta requisitos parcialmente definidos Prottipo descartvel (Throw-away prototyping)
Jogar fora a primeira verso?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Distribuio das Fases de Desenvolvimento nos Modelos Cascata e Iterativo


34

Modelo Cascata

Modelo Iterativo

Especificao

Projeto

Implementao

Validao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

17

Software Um Investimento de Risco


35

Resultado de projetos de software realizados nos EUA no incio da dcada de 90

Inacabados 30%

Todos baseados no modelo cascata. 53% custaram at 200% acima da estimativa inicial. Estimou-se que $81 bilhes foram Concludos gastos em projetos 70% fracassados s no ano de 1995.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Fonte: Standish Report, 1994

O Que Deu Errado?


36

O modelo cascata fortemente baseado em suposies oriundas dos processos de engenharia convencionais Algumas dessas suposies no foram confirmadas na prtica
Todos os requisitos podem ser precisamente identificados antes do desenvolvimento Os requisitos so estveis O projeto pode ser feito totalmente antes da implementao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

18

Impreciso dos Requisitos


37

Estudo publicado por Capers Jones em 1987, baseado em 6.700 sistemas

% de Req's Problemticos

60 50 40 30 20 10 0 10 100 1000 10000 100000 Tamanho do Projeto em Pontos por Funo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Instabilidade dos Requisitos


38

O mercado muda constantemente As tecnologias mudam inevitavelmente A vontade e objetivos dos usurios mudam imprevisivelmente

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

19

Projeto Completo antes da Implementao?


39

Pergunte a qualquer programador Requisitos so incompletos e instveis Uma especificao completa tem que ser to detalhada quanto o prprio cdigo Desenvolver software uma atividade intrinsecamente difcil
Discover Magazine, 1999: Software caracterizado como a mais complexa mquina que a humanidade j construiu

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O Custo da Mudana
40

Planos estratgicos e racionais de desenvolvimento baseiam-se no custo total do sistema, no apenas nos custos de desenvolvimento
Outros Cdigo

Teste

Projeto Reviso & Manuteno Documentao

Fonte: DP Budget, Vol. 7, No. 12, Dez. Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)1988

20

O Custo da Mudana
41

Um estudo da AT&T indicou que, na mdia,

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

A Voz da Experincia e da Pesquisa


42

Em 1994, o DoD (EUA) parou de contratar projetos baseado no modelo cascata, por causa de fracassos abismais
Eles agora incentivam um modelo iterativo

Virtualmente todos os trabalhos na rea publicados nos ltimos 5 anos defendem a substituio do modelo cascata por um modelo iterativo
The Unified Software Development Process Applying UML and Patterns Software Project Management Succeeding with Objects Object Solutions Surviving Object-oriented Projects
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

21

Usem o Modelo Iterativo!


43

Passos curtos, feedback e refinamento Iterativo, incremental, com intervalos de tempo (ciclos) pr-estabelecidos
Iterao 1 Iterao 2 ...

Anlise

Projeto

Codificao, Teste, Integrao

Anlise

Projeto

Codificao, Teste, Integrao

2 semanas

2 semanas

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Reduo de Riscos
44

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

22

Composio de um Processo de Software


45

Geralmente composto das seguintes disciplinas:


Planejamento e Gerenciamento de Software Requisitos de Software Anlise e Projeto de Software Codificao de Software Depurao e Testes Qualidade e Inspeo

Mas o processo pode ser especifico para uma determinada disciplina.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Planejamento e Gerenciamento
46

O que e como faremos? Quem far o qu? Quanto tempo levaremos? O que poder dar errado (riscos)? O que usaremos? Quanto custar? Como estamos indo? Estamos documentando (tempo, etc.)?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

23

Requisitos
47

Como elicit-los?
O que faremos exatamente?

Documentar preciso ... Como apresentar?


Texto semi-formal + UML

Usar o documento tambm ...


Como fonte para Anlise Como contrato perante o cliente

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Anlise
48

Identificar elementos constituintes do sistema (domnio do problema)


Classes, associaes, etc.

Documentar atravs de modelo abstrato Descrever exatamente O QUE faremos


Mtodos formais (UML + Z)

Investigar propriedades do sistema Comparar com documento de requisitos


Validar sistema

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

24

Projeto
49

Identificar elementos constituintes do sistema (domnio da soluo)


Mdulos, classes, associaes, etc.

Documentar atravs de modelo concreto


Algoritmos e tecnologias existentes, etc.

Descrever exatamente COMO faremos


UML + Comentrios

Comparar com documento de anlise


Verificar sistema

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Codificao
50

Que linguagens usaremos? Que ferramentas usaremos? Como faremos a codificao? Codificar atravs do modelo de projeto Garantir pr e ps-condies e invariantes Integrao ...

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

25

Depurao e Testes
51

Avaliando artefatos de forma incremental


Mtodos, classes, mdulos, requisitos no-funcionais, etc.

Avaliando pela especificao (teste da caixa preta) ou pelo cdigo (teste da caixa branca)? Comparar com documentos anteriores Documentando erros e calculando produtividade e qualidade

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Qualidade e Inspeo
52

Quo bom foi o desenvolvimento? Qual a quantidade de erros encontrados? Qual a produtividade da equipe? Esquecemos de verificar algum aspecto do sistema? Os documentos esto atualizados?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

26

Processo de Software
53

Premissa para gerenciamento do Processo de Software


A qualidade de um sistema de software altamente influenciada pela qualidade do processo utilizado no seu desenvolvimento e manuteno. Essa premissa implica no foco tanto no processo quanto no produto.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Porque o Processo de Software o foco correto ?


54

Dirigindo o foco somente no produto, deixa-se de lado:


assuntos relacionados com a escalabilidade; conhecimento de como fazer isso melhor

Dirigindo o foco no processo prev-se:


repetio de resultados; tendncias futuras do projeto; caractersticas do produto

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

27

Um Processo Imaturo
55

Ad hoc;
processo improvisado por profissionais e gerncias.

No rigorosamente seguido e o cumprimento no controlado. Altamente dependente dos profissionais atuais. Baixa viso do progresso e da qualidade. A funcionalidade e a qualidade do produto podem ficar comprometidas para que prazos sejam cumpridos. Arriscado do ponto de vista do uso de nova tecnologia. Custos de manuteno excessivos. Qualidade difcil de se prever.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Anatomia do Caos
56

A maioria das organizaes de software esto apagando incndios


o fogo est sob controle constantemente reagindo (e no agindo pr-ativamente) no h tempo para melhoria os bombeiros se queimam as cinzas podem voltar a se incendiar mais tarde sua nica forma de controle - preveno de incndio

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

28

Um Processo maduro
57

Coerente com as linhas de ao, o trabalho efetivamente concludo. Definido, documentado e melhorando constantemente:
compreendido utilizado vivo e ativo

Com o apoio visvel da alta administrao e outras gerncias. Bem controlado - fidelidade ao processo objeto de auditoria e de controle. So utilizadas medies do produto e do processo. Uso disciplinado da tecnologia.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Processo institucionalizado
58

Essa a maneira como fazemos as coisas aqui.


Construindo uma infra-estrutura que possui processos eficazes, utilizveis e consistentemente aplicados em toda organizao. A cultura organizacional deve transmitir o processo. A alta administrao deve cuidar da educao cultural. Se ningum se importa, todos se esquecem. Cultura transmitida com modelos na vida real e recompensas. Processos institucionalizados permanecem, mesmo depois que as pessoas que originalmente os definiram, deixam a organizao.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

29

Quais so os benefcios de um processo maduro ?


59

Cerca de 85% dos problemas so causados pelo sistema, no pelas pessoas. As pessoas desenvolvem mais suas potencialidades e so mais eficientes dentro da organizao. Atravs da definio, medio e controle do processo, melhorias tm mais sucesso e so mantidas ao longo do tempo. H uma crescente introduo bem sucedida de tecnologias, tcnicas e ferramentas.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Exerccio
60

Juntem-se em grupos e em relao a empresa em que vocs trabalham (pode ser uma empresa de qualquer rea) identifiquem:
Um processo considerado imaturo; descreva porque o consideram o processo imaturo.
Descrevam o que acreditam que deve ser feito para esse processo se transformar em maduro.

Um processo considerado maduro; descrevam porque o consideram maduro.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

30

Muitos Processos
61

No parece haver consenso sobre um formalismo ideal. Terminologias distintas


Fase (Fusion) Workflow (RUP) Disciplina (RUP) Atividade (conceito diferente no OPEN e no RUP)

Mas h um esforo de padronizao (SPEM OMG).

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Processos de Software
62

Processos tradicionais (pesados)


RUP OPEN Catalysis

Processos geis (leves)


XP Agile modeling Crystal SCRUM

Processos entre os tradicionais e os agis


ICONIX

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

31

Processos de Software
63

Consenso em torno de
Iteratividade Participao de usurios Flexibilidade de configurao para projetos especficos Comunicao entre membros da equipe

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Processos de Software
64

Divergncias
Detalhamento de atividades a serem seguidas Ordem de execuo das atividades

Arquitetura robusta (RUP) Arquitetura para o contexto da iterao atual (agile modeling)
Rigor na atribuio de tarefas a responsveis

workers (RUP) alocao sob demanda e interesse (XP)


Artefatos (documentao) gerados Grau de automao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

32

Exemplos de processos
65

A polmica ...
Se a tendncia ter processos leves, afinal o desenvolvimento de software Arte+Sociologia+Psicologia+... ou Lgica+Modelos+Engenharia+...??? E todo o esforo de consolidao da Engenharia de Software como uma cincia exata???

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Desafios
66

Organizaes oferecem forte resistncia implantao (ou modificao) de processos.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

33

ISO/IEC 12207
67

Publicada em 1 de agosto de 1995 e revista em 2002, foi o primeiro padro internacional com o objetivo de prover um conjunto abrangente de processos de ciclo de vida, atividades e tarefas de produtos e servios de software Objetivo
Estabelecer uma estrutura comum para os processos de ciclo de vida de software

Prov uma arquitetura de processo de software comum para a aquisio, fornecimento, desenvolvimento, operao e manuteno de software Prov processos, atividades e tarefas de apoio e organizacionais para a gerncia e melhoria dos processos
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

ISO/IEC 12207
68

Qualquer organizao que exija o cumprimento desta Norma como uma condio de negcio, responsvel por especificar e disponibilizar o conjunto mnimo de processos, atividades e tarefas requeridos, que constitui a conformidade dos fornecedores a esta Norma. Descreve a arquitetura dos processos de ciclo de vida de software, mas no especifica os detalhes de como implementar ou executar as atividades e tarefas includas nos processos No pretende prescrever o nome, formato ou contedo explcito da documentao a ser produzida, podendo requerer o desenvolvimento de documentos de mesma categoria ou tipo, por exemplo, diferentes planos
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

34

ISO/IEC TR 15504
69

ISO/IEC TR 15504 Information technology Software process assessment o padro internacional para avaliao de processos de software Desenvolvido no contexto do projeto SPICE
Mais de 3000 avaliaes j foram feitas em todo o mundo

Fornece um framework para a avaliao de processos de software

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

ISO/IEC TR 15504
70

A ISO/IEC TR 15504 prov uma abordagem estruturada para avaliao de processos de software com os seguintes objetivos:
Permitir o entendimento, por uma organizao, do estado dos seus processos, visando estabelecer melhorias Determinar a adequao dos processos de uma organizao para atender a um requisito particular ou classe de requisitos Determinar a adequao de processos da organizao para um contrato

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

35

Algumas referncias
71

Process-Centered Software Engineering Environments. P. K. Garg & M. Jazayeri. IEEE Computer Society Press The OPEN Process Specification. I. Graham, B. HendersonSellers & H. Younessi The Unified Software Development Process. I, Jacobson, G. Booch & J. Rumbaugh http://www.rational.com/products/rup/ http://www.catalysis.org/ http://www.extremeprogramming.org/ http://www.agilemodeling.com/ http://www.crystalmethodologies.org/

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

36

PROCESSOS DE SOFTWARE
1

INTRODUO AO RUP
(RATIONAL UNIFIED PROCESS)

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Introduo
2

Processo - conjunto completo de atividades necessrias para transformar os requisitos do usurio num conjunto consistente de artefatos de software
[Jacobson 1999].

Define quem faz o qu, onde e quando para atingir um objetivo. A presena de um processo bem definido e bem gerido um aspeto determinante de diferenciao entre projetos produtivos e projetos mal-sucedidos.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Definio
3

Metodologia - Metodologia de desenvolvimento de software que iterativo, centrado em uma arquitetura e guiado por casos de uso. Processo - Um processo de Engenharia de Software bem definido e bem estruturado. Produto - Um produto que fornece um framework de processo configurvel para a Engenharia de Software.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Objetivo
4

Aumentar a produtividade da equipe, fornecendo acesso fcil a uma base de dados com guidelines, templates e ferramentas. Assegurar a produo de um software de alta qualidade que atende as necessidades do usurio final.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP (site WEB [Rational, 2000])


5

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O que o RUP?
6

Conjunto de atividades
bem definidas com responsveis com artefatos de entrada e sada com dependncias entre as mesmas e ordem de execuo com modelo de ciclo de vida com descrio sistemtica de como devem ser realizadas com guias (de ferramentas ou no), com templates utilizando diagramas de UML

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Princpios Essenciais
7

Define uma arquitetura executvel no incio. Acomoda mudanas desde o incio. Ataca os maiores riscos primeiro. Garante entregas significativas ao cliente. Mantem o foco em software executvel. Visa Construir sistemas a partir de componentes. Trabalho em equipe requerido. Faz da qualidade um modo de vida, no um alvo.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP Best Practices


8

Desenvolvimento Iterativo e Incremental aumenta o entendimento do problema atravs de refinamento sucessivos, atenuando os riscos do projeto. Gerenciamento dos Requisitos descreve como elicitar, organizar e documentar a funcionalidade necessria e as limitaes. Utilizao de Use Cases e Cenrios. Uso de arquitetura baseada em componentes descreve como projetar uma arquitetura que flexvel, suporta mudanas, intuitivamente entendvel e promove o reuso.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP Best Practices


9

Modelagem visual ajuda a comunicar diferentes aspectos do software. Ajuda a capturar a estrutura e comportamento da arquitetura e dos componentes. Verificao da Qualidade ajuda a planejar, projetar, implementar, executar e medir (confiabilidade, funcionalidade, performance do aplicativo e do sistema). Controle de Mudanas descreve como controlar, rastrear e monitorar mudanas para permitir o desenvolvimento iterativo.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Paradigmas do RUP
10

O desenvolvimento de sistemas seguindo o RUP


Iterativo e incremental Guiado por casos de uso (use cases) Centrado na arquitetura do sistema

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP iterativo e incremental


11

O ciclo de vida de um sistema consiste de quatro fases:

concepo tempo

elaborao

construo

transio

Concepo (define o escopo do projeto) Elaborao (detalha os requisitos e a arquitetura) Construo (desenvolve o sistema) Transio (implanta o sistema)
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP iterativo e incremental


12

Cada fase dividida em iteraes:

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP iterativo e incremental


13

Cada iterao
planejada realiza uma seqncia de atividades (de elicitao de requisitos, anlise e projeto, implementao, etc.) distintas geralmente resulta em uma verso executvel do sistema avaliada segundo critrios de sucesso previamente definidos

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP iterativo e incremental


14

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP iterativo e incremental


15

Vantagens do mtodo iterativo:


Acomoda mudanas nos requisitos. Integrao contnua. Riscos so descobertos mais cedo. Reuso facilitado. Defeitos podem ser encontrados e corrigidos mais cedo. O time aprende durante o desenvolvimento. O processo de desenvolvimento pode ser melhorado durante o desenvolvimento.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP guiado por casos de uso


16

Os casos de uso no servem apenas para definir os requisitos do sistema Vrias atividades do RUP so guiadas pelos casos de uso: planejamento das iteraes criao e validao do modelo de projeto planejamento da integrao do sistema definio dos casos de teste

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP centrado na arquitetura do sistema


17

Arquitetura
viso geral do sistema em termos dos seus subsistemas e como estes se relacionam

A arquitetura prototipada e definida logo nas primeiras iteraes O desenvolvimento consiste em complementar a arquitetura A arquitetura serve para definir a organizao da equipe de desenvolvimento e para identificar as oportunidades de reuso
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP centrado na arquitetura do sistema


18

A arquitetura a organizao fundamental do sistema como um todo, incluindo elementos estticos e dinmicos e sua interao. Consequncias:
Possibilita o entendimento da viso geral; Organiza o esforo de desenvolvimento; Facilita as possibilidades de reuso; Facilita a evoluo do sistema; Dirige a seleo de casos de uso relevantes.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O RUP centrado na arquitetura do sistema


19

Idealmente, tem-se 5 vises da arquitetura


Logical View
Analysts/ Designers Structure End-user Functionality

Implementation View
Programmers Software management

System integrators Performance Scalability Throughput

Process View

Deployment System Engineering View


System topology Delivery,installation Communication

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Processo
20

Modelado usado o SPEM (Software Process Engineering Metamode). Possui duas estruturas (dimenses).
Dinmica (Tempo) ciclos, fases, interaes e marcos.
dimenso horizontal que representa o tempo do processo. Mostra como o processo, expresso em termos de ciclos, fases, iteraes e marcos, desenvolve-se ao longo do ciclo de vida de um projeto.

Esttica atividades, disciplinas, artefatos e papis.


dimenso vertical que descreve como os elementos do processo (atividades, disciplinas, artefatos e papis) so logicamente agrupados em temas (disciplinas ou fluxos).

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

10

RUP - Processo
21

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Processo
22

Estrutura dinmica
1. 2. 3. 4. Concepo Elaborao Construo Transio

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

11

RUP - Processo
23

O propsito das fases no particionar as atividades por tipo (anlise, codificao, etc) e sim executar o suficiente de cada disciplina para atingir os objetivos da fase no momento que os marco so atingidos. Os marcos principais do RUP no so expressos em termos de completar certos artefatos ou documentos, mas principalmente em termos de mitigao de riscos e completude do produto.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Processo
24

Milestones

Os riscos foram atenuados? O projeto e vivel?

Os riscos logsticos foram atenuados? O sistema usvel? Podemos entregar uma verso beta? Podemos entregar um produto robusto, confivel e completo?

Os riscos tcnicos foram atenuados? Existe um planejamento detalhado?


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

12

Concepo - Lifecycle Objective (LCO)


25
Entender o que ser construdo; Identificar funcionalidades-chave do sistema; Determinar pelo menos uma soluo possvel; Entender o cronograma, custos e riscos do projeto; Decidir qual processo e ferramentas seguir. objetivos:
Requisitos capturados e bem entendidos Acordar que estimativas de custos, cronograma, riscos e prioridades esto OK

Resultados (artefatos)
Documento de viso: viso geral dos requisitos, caractersticas e restries essenciais do projeto. Modelo inicial de casos de uso (10%-20%). Glossrio do projeto (opcionalmente um modelo de domnio). Definio de objetivos e viabilidade do projeto includo contexto, critrios de sucesso, projeo de ROI, e prognstico financeiro. Avaliao inicial de riscos. Plano de projeto, com fases e interaes. Modelo de negcios, se necessrio. Um ou vrios prottipos.

Critrios de Satisfao
Concordncia quanto definio de escopo e estimativas de custo e cronograma. Compreenso dos requisitos funcionais. Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento. Profundidade e amplitude dos prottipos desenvolvidos. Custos planejados versus realizados.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Elaborao - Lifecycle Architecture (LCA)


26
Definir um plano detalhado para a construo Ter um entendimento detalhado dos requisitos; Desenhar, implementar e validar a arquitetura; Mitigar riscos essenciais e produzir um plano mais refinado; objetivos:
Viso e Requisitos esto estveis Arquitetura est estvel Maiores riscos j foram tratados

Resultados (artefatos)
Modelo de casos de uso (80% ou mais). Requisitos no funcionais Descrio da arquitetura do software Prottipos arquiteturais executveis Reviso da viso de negcios e lista de riscos Plano detalhado de desenvolvimento do projeto, com interaes e critrios de avaliao

Critrios de Satisfao (para suporte deciso sobre continuar ou no com o projeto)


A viso do produto estvel? A arquitetura estvel? A demonstrao executvel mostrou que os elementos de maior risco foram abordados satisfatoriamente? O plano de desenvolvimento est suficientemente detalhado e preciso? O plano consistente e coerente? Todos os interessados concordam quando coerncia entre viso, plano e arquitetura? Os custos planejados e executados esto aceitveis?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

13

Construo - Initial Operational Capability (IOC)


27

Construir a primeira verso funcional do produto. Minimizar custos de desenvolvimento e atingir certo grau de paralelismo para melhorar o desempenho no projeto Objetivos:
O produto pode ser colocado em produo Todos esto prontos para coloc-lo em produo

Resultados (artefatos)
O produto, codificado e integrado nas plataformas adequadas

Critrios de Satisfao
A release do produto suficientemente estvel e amadurecida para ser entregue ao usurio? Todos os envolvidos e interessados esto preparados para a fase de transio? O consumo de recursos ainda aceitvel?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Transio - Product Release (PR)


28

Realizar testes beta para validar expectativas dos usurios; Treinar usurios e demais envolvidos visando sua independncia. Preparar ambiente e converter banco de dados; Preparar empacotamento e distribuio; Obter lies aprendidas Objetivos:
O usurio est satisfeito O que foi gasto perante o planejado est aceitvel

Resultados (artefatos)
Em conformidade com atividades

Critrios de Satisfao
O usurio ainda est satisfeito? Os custos de manuteno ainda so aceitveis?
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

14

RUP - Processo
29

Estrutura esttica
1. Papis (Quem) define responsabilidades e competncias; 2. Atividades (Como) gerar artefatos; 3. Artefatos (O qu) informaes que so criadas, modificadas ou usadas no processo; 4. Fluxo de Atividades (Quando) descreve uma seqncia de atividades e mostra a interao entre os papis (roles);

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Processo
30

Elementos adicionais
Guidelines;
Orienta sobre como desempenhar uma atividade ou construir um artefato

Templates;
Prottipo ou modelo de artefato

Tool mentors;
Orienta sobre como usar uma ferramenta para construir um artefato

Concepts; Roadmaps; Checkpoints


Auxilia na verificao da qualidade de um artefato
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

15

RUP - Processo
31

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Alguns exemplos de Papis


32

Analistas
System Analyst Business Designer Business-Model Reviewer Business-Process Analyst

Gerentes
Process Engineer Project Manager Change Control Manager Configuration Manager Deployment Manager Project Reviewer Test Manager

Desenvolvedores
Capsule Designer Code Reviewer Database Designer Implementer Integrator Software Architect Architecture Reviewer Design Reviewer

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

16

Principais Artefatos [Rational, 2000]


33

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Exemplos de Atividades
34

Papel: Analista de Sistemas


Elicitar necessidades de stakeholders Capturar vocabulrio Desenvolver Plano de Gesto de Requisitos Desenvolver guias de construo de casos de uso Encontrar atores e casos de uso Desenvolver Viso Gerenciar (rastrear) dependncias Estruturar modelo de casos de uso

Papel : Implementador
Implementar componentes Implementar teste de componentes e subsistemas Executar testes unitrios Corrigir defeitos Desenvolver artefatos de instalao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

17

Exemplo de Workflow (Requisitos [Rational, 2002])


35

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Tamanho do RUP [Rational, 2000]


36

4 Fases 9 Disciplinas 33 Papis 97 Artefatos + de 120 Atividades 14 Guias de Trabalho Templates para quase todos os artefatos 17 Tool Mentors

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

18

RUP - Processo
37

Disciplinas agrupa todos os elementos do processo;


1. 2. 3. 4. 5. 6. 7. 8. 9. Modelagem de Negcio; Requisitos; Anlise e Projeto; Implementao; Teste; Implantao; Gerenciamento de Projeto; Gerenciamento de Configurao; Ambiente;

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Modelagem de negcio
38

Objetivos
Entender a estrutura e a dinmica da organizao na qual o sistema deve ser implantado. Entender os problemas atuais e identificar melhorias potenciais. Garantir um entendimento comum entre clientes, usurios e desenvolvedores. Derivar os requisitos de sistemas necessrios.

RUP

19

Modelagem de negcio
39

Principais papis:
Analista de negcio Desenhista de processo de negcio Stakeholders Revisores

Principais artefatos:
Documento de viso de negcios Modelo de casos de uso de negcio Especificao suplementar de negcio Glossrio de negcio
RUP

Requisitos
40

Objetivos
Estabelecer e manter acordo entre stakeholders sobre o que o sistema deve fazer Prover aos desenvolvedores um melhor entendimento dos requisitos do sistema Definir as fronteiras do sistema Prover a base para planejamento do contedo tcnico das iteraes Prover a base para estimativas de durao e custo

RUP

20

Requisitos
41

Principais papis :
Analista de sistemas Especificador de casos de uso Projetista de interfaces com usurio

Principais artefatos:
Glossrio Casos de uso Detalhamento dos casos de uso Prottipos de interface com usurio

RUP

Anlise e desenho
42

Objetivos
Traduzir os requisitos em uma especificao que descreva como implementar o sistema Selecionar a melhor estratgia de implementao Estabelecer uma arquitetura robusta para a aplicao

RUP

21

Anlise e desenho
43

Principais papis :
Arquiteto Projetista Projetista de banco de dados Revisor

Principais artefatos:
Modelo de anlise Modelo de projeto Documento de arquitetura de software
RUP

Implementao
44

Objetivos
Definir a organizao do cdigo em termos de subsistemas e camadas Implementar classes, objetos e componentes Testar unidades criadas Integrar em um ambiente executvel os resultados produzidos individualmente

RUP

22

Implementao
45

Principais papis :
Implementador Integrador de sistemas Arquiteto Revisor de cdigo

Principais artefatos:
Implementao de subsistema Componente Plano de integrao
RUP

Testes
46

Objetivos
Verificar a interao dos atores com cada componente. Verificar a integrao entre os componentes. Verificar a implementao correta de todos os requisitos. Identificar e garantir que todos os defeitos descobertos sejam tratados.

RUP

23

Testes
47

Principais papis :
Projetista de testes Testador

Principais artefatos:
Plano de testes Casos de testes Resultados dos testes Modelo de carga Defeitos gerados
RUP

Implantao
48

Objetivos
Testar o software no ambiente final (produo). Empacotar o software para implantao. Distribuir o software. Instalar o software. Treinar os usurios finais. Migrar o software existente (se for o caso) e converter sua base de dados

RUP

24

Implantao
49

Principais papis:
Gerente de implantao Gerente de projetos Redator Implementador

Principais artefatos:
Software executvel. Artefatos de instalao: scripts, ferramentas, arquivos, guias, etc. Notas de release. Material de apoio e treinamento.

RUP

Gerenciamento de projetos
50

Objetivos
Prover uma estrutura para gerenciar projetos de desenvolvimento. Prover diretrizes prticas para planejar, executar, apoiar e monitorar projetos. Prover uma estrutura para gerenciar riscos.

RUP

25

Gerenciamento de projetos
51

Principais papis:
Gerente de projetos

Principais artefatos:
Plano do projeto Plano da iterao Cronograma Avaliao da iterao

RUP

Gerenciamento de Projeto
52

A abordagem iterativa e incremental estabelece dois tipos de planejamento:


Alto-nvel (coarse-grain): contido no plano de projeto, que aborda as fases, iteraes, seus objetivos e informaes gerais. H um plano por projeto. Baixo-nvel (fine-grain): contido em planos de iterao, que traz as atividades e recursos individuais. H um plano por iterao.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

26

Plano de Projeto
53

Gerentes de nveis superiores e stakeholders raramente se interessam por detalhes sobre quem est fazendo o que e quando. O foco gerencial est no produto final, datas de liberao, marcos significativos Decises importantes devem ser tomadas pelo gerente, no sentido de avaliar o progresso geral do projeto e solucionar problemas. O plano de projeto um plano de alto nvel, que atua como um envelope para os planos detalhados de cada iterao.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Plano de Iterao
54

Plano detalhado e com tempo bem definido, com um intervalo de tempo suficientemente pequeno para prover a equipe de um tipo de detalhamento com o qual ela est acostumada. Deve definir tarefas e alocao de cada membro da equipe. Em alguns projetos, o plano de iterao corresponde a uma simples lista de tarefas por fazer.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

27

Gerenciamento de Projetos
55

Duraes tpicas de projetos:


De 6 semanas a 54 meses.

Duraes tpicas de uma iterao:


De 2 semanas a 6 meses.

Quantidade tpica de iteraes por projeto:


De 3 a 9 iteraes.

Quantidade de artefatos definidos:


Aproximadamente 100.

Quantidade de papis definidos:


Aproximadamente 30.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Gerenciamento de Projetos
56

Esforo Programao

Iniciao ~5 % 10 %

Elaborao 20 % 30 %

Construo 65 % 50 %

Transio 10% 10%

Iteraes por fase Tamanho do Durao do Durao por Concepo Elaborao Construo Transio projeto (pessoas) projeto (m) iterao (s) 3 4 2-3 1 1 3 1 10 8 4 1 2 3 2 80 20 7-8 2 3 4 2
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

28

Gerenciamento de configurao e mudanas


57

Objetivos
Rastrear e manter a integridade do projeto. Habilitar membros da equipe a identificar e localizar artefatos, selecionar a verso adequada e avaliar o histrico do artefato. Acompanhar a evoluo do projeto.

RUP

Gerenciamento de configurao e mudanas


58

Principais papis :
Gerente de configurao Gerente de controle de mudanas Integrador Arquiteto

Principais artefatos:
Plano de gerenciamento de configuraes Requisies de mudana Mtricas e relatrios de status

RUP

29

Ambiente
59

Objetivos
Seleo e aquisio de ferramentas Configurao e personalizao de ferramentas Configurao de processos Melhoria dos processos Prover servios de apoio: infra-estrutura, administrao de contas, backup, etc.

RUP

Ambiente
60

Principais papis:
Analista de processos de negcio Analista de sistemas Projetista de interfaces com usurio Arquiteto Redator Administrador do sistema Especialista em ferramentas

Principais artefatos:
Diretrizes gerais
RUP

30

RUP - Comparao
61

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP - Comparao
62

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

31

RUP - Comparao
63

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

RUP Process Killers


64

Prticas impraticveis que podem acabar com a utilizao do RUP:


Be mysterious Conduct the Spanish Inquisition Promote process from the "bottom up
O processo deve ser promovido pela alta administrao

Implement process from the top down


A implementao deve ter o foco na camada tcnica

Focus only on artifacts

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

32

Referncias
65

KRUCHTEN, Philippe, The Rational Unified Process An Introdution, 2a ed., Adisson Wesley, 2000. KROLL, Per, KRUCHTEN, Philippe, The Rational Unified Process Made Easy, Adisson Wesley, 2003. http://www.wthreex.com/rup Rational Unified Process: Best Practices for Software Development Teams - A Rational Software Corporation White Paper Rational Unified Process Made Easy: A Practitioner's Guide to the RUP Per Kroll, Philippe Kruchten; Top five RUP implementation process killers - Barclay Brown The Spirit of RUP Per Kroll, The rational Edge

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

33

03/10/2011

PROCESSOS DE SOFTWARE
1

XP
EXTREME PROGRAMMING

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

XP - FILOSOFIA
2

...para mudar seu destino, voc precisa primeiro mudar sua atitude... Kent Beck
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Metodologias geis
3

Cenrio encontrado Possvel soluo Movimentos iniciais Manifesto gil Um estudo comparativo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Cenrio encontrado
4

Metodologias pesadas:
Supem que possvel prever o futuro; Pouca interao com os clientes; nfase em burocracias (documentos, formulrios, processos, controles rgidos, etc.); Avaliao do progresso baseado na evoluo da burocracia e no do cdigo;

Com software
Quantidade de erros; Falta de flexibilidade; Alto custo inicial;
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Possvel soluo
5

Melhores prticas:
Padres de Projeto (reutilizao de idias); Componentes (reutilizao de cdigo); Requisitos mutveis; Atividade que apresente baixo custo; Equipes pequenas; Datas de entrega curtas; Desenvolvimento rpido;

Metodologia indicada nesse cenrio:


Metodologia gil
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Movimentos iniciais
6

Movimento iniciado por programadores experientes e consultores em desenvolvimento de software; Questionam e se ope a uma srie de mitos/prticas adotadas em abordagens tradicionais de Engenharia de Software e Gerncia de Projetos; Manifesto gil:
Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Manifesto gil
8

Estamos evidenciando maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a entender que: Indivduos e interaes so mais importantes que processos e ferramentas. Software funcionando mais importante do que documentao completa e detalhada. Colaborao com o cliente mais importante do que negociao de contratos. Adaptao a mudanas mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens direita, valorizamos mais os itens esquerda.

http://www.agilemanifesto.org/

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Metodologias geis - Comparativo


9

Metodologias geis tm sido apontadas como uma alternativa s abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas tambm como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situaes em que os requisitos do sistema so estveis e requisitos futuros so previsveis. Entretanto, em projetos em que h muitas mudanas, em que os requisitos so passveis de alteraes, onde refazer partes do cdigo no uma atividade que apresenta alto custo, as equipes so pequenas, as datas de entrega do software so curtas e o desenvolvimento rpido fundamental, no pode haver requisitos estticos, necessitando ento de metodologias geis.
Michel dos Santos Soares

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

O surgimento do XP
10

Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software
Identificou o que tornava simples e o que dificultava o desenvolvimento de software

Em Maro de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - eXtreme Programming

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

O que eXtreme Programming?


11

Trata-se de uma metodologia gil para equipes pequenas e mdias desenvolvendo software com requisitos vagos e em constante mudana

Kent Beck

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Uma pergunta
12

Como voc programaria se tivesse tempo suficiente?


Kent Beck

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Possveis respostas
13

Mais testes? Mais projeto e arquitetura? Menos pessoas? Mais qualidade?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Programando ao Extremo
14

Levar todas as boas prticas ao Extremo


Se testar bom, vamos testar toda hora!! Se projetar bom, vamos fazer disso parte do trabalho dirio de cada pessoa! Se integrar bom, vamos integrar a maior quantidade de vezes possvel! Se iteraes curtas bom, vamos deixar as iteraes realmente curtas!

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

XP
15

O XP uma metodologia rigorosa e disciplinada que requer o cumprimento de suas prticas para o sucesso na adoo. O XP pode ser usado com CMM e UPs. A preocupao no com qualidade (que deve natural) e sim com a sade do sistema (segundo Kent Beck).

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

XP inclui...5 Valores Principais


16

Respeito

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

XP inclui... Comunicao
17

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Comunicao
18

Solues de problemas normalmente j so conhecidas... O problema a soluo chegar a quem precisa Comunicao face a face a maneira mais rpida de espalhar conhecimento Preferir
Chat a e-mail Telefone a chat Conversa pessoal a telefone

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

XP inclui...Coragem
19

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Coragem
20

Indicar problemas no projeto Parar quando est cansado !!! Pedir ajuda quando necessrio Simplificar cdigo que j est funcionando Seguir o XP como ele
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

10

03/10/2011

XP inclui...Feedback
21

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Feedback
22

Cliente participando do desenvolvimento Oportunidades e problemas so evidenciados o mais cedo possvel Testes fornecem feedback sobre sistema

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

11

03/10/2011

XP inclui...Simplicidade
23

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Simplicidade
24

Regra geral: Pensar sempre no que pode ser feito para simplificar o que j est funcionando; Simplicidade normalmente gera mais valor satisfatrio; Fazer o mnimo necessrio para funcionar;
(cuidado com esse conceito!!!)

mais barato adaptar depois caso no esteja funcionando; O projeto deve ser simplificado continuamente.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

12

03/10/2011

XP inclui...Respeito
25

Respeito

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Respeito
Conceito psicolgico introduzido pela mulher do Kent !

26

Coragem, Feedback ,Simplicidade, Comunicao... Respeito necessrio para tirar o mximo desses valores Respeito pelo prximo
Feedback, Comunicao

Respeito por si mesmo


Coragem, Simplicidade

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

13

03/10/2011

Caractersticas Comuns dos Mtodos geis


27

Coloca o foco
Na entrega freqente de sub-verses do software [funcionando] para o cliente. Nos seres humanos que desenvolvem o software.

Retira o foco de
Processos rgidos e burocratizados. Documentaes e contratos detalhados. Ferramentas que so usadas pelos seres humanos.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Papis no XP
28

Big Boss / Xp Manager Deve fazer:


Agendar reunies; Escrever atas ; Manter o XP Tracker informado dos acontecimentos das reunies

No deve fazer:
Deixar que problemas externos interfiram no desenvolvimento Dizer quando as coisas devem acontecer Dizer s pessoas o que fazer Cobrar das pessoas

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

14

03/10/2011

Papis no XP
29

Xp Gold Owner
O proprietrio do ouro - O CLIENTE) quem paga pelo sistema, geralmente o dono da empresa.

Xp Goal Donor
Deve fazer:
Escrever User Stories Definir prioridades Definir testes de aceitao Validar testes de aceitao Esclarecer dvidas

No deve fazer:
Implementar cdigo

Definir quanto tempo uma tarefa leva para ser feita

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Papis no XP
Xp Coach Responsvel pela negociao com o cliente quanto ao escopo Responsvel pela coordenao do Planning Game.
30 Coordenador

Xp Tracker Deve fazer:


Coletar mtricas Manter todos informados do que est acontecendo Definir testes de aceitao Tomar atitudes diante de problemas Sugerir sesses de CRC (Class, Responsabilities , Collaboration)

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

15

03/10/2011

Papis no XP
31

Programador (Driver/Partner) Deve fazer:


Estimar prazos de User Stories Implementar cdigo de produo Trabalhar em par Fazer refactoring Corrigir bugs

No deve fazer:
Criar/Alterar novas funcionalidades Escrever testes de aceitao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Papis no XP
32

Alguns papis podem ser combinados numa s pessoa

Xp Manager + Xp Tracker
Alguns papis no podem ser combinados numa s pessoa

Xp Programmer + Xp Tracker Xp Customer+ Xp Programmer Xp Coach + Xp Tracker


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

16

03/10/2011

Boas Prticas
33
A criao de testes leva em conta no o tempo ganho com a criao dos mesmos antes da codificao, mas conhecer previamente as possveis falhas do seu sistema.

Test First Design

Refactoring Stand-up Meeting Continuous Integration

A reconstruo baseia-se na remoo de redundncia, eliminao de funcionalidades inteis, e reconstruo de projetos obsoletos. Reunies rpidas e dirias com a equipe

Os diversos mdulos do software so integrados diversas vezes por dia e todos os testes unitrios so executados. O cdigo no passa at obter sucesso em 100% dos testes unitrios.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Boas Prticas
34
Todo cdigo de produo desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor.

Pair Programming Move People Around Collective Code Ownership Coding Standards

As duplas de programao so revezadas em mdia a cada 2h.


E equipe como um todo responsvel por cada arquivo de cdigo. No preciso pedir autorizao para alterar qualquer arquivo.

Todo cdigo desenvolvido seguindo um padro.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

17

03/10/2011

Boas Prticas
35 O cliente est sempre disponvel para resolver dvidas, alterar o escopo de uma iterao e definir prioridades.
O software entregue em pequenas verses para que o cliente possa obter o seu ganho o mais cedo possvel e para minimizar riscos.

The Customer is Always Available

Small Release

Simple Design

O cdigo est, a qualquer momento, na forma mais simples que passe todos os testes.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Boas Prticas
36
Cada programador trabalha 40 horas por semana. Se o horrio for flexvel, deve-se respeitar o horrio do par naquele perodo, seno enquanto um trabalha o outro vai pra casa .

40-Hour Week

On-Site Customer

Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas

Acceptance Tests
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

So definidos pelo usurio e so os critrios de aceitao do software.

18

03/10/2011

Chegou a hora...
37

Como funciona o fluxo de utilizao do XP ?


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Fluxo de XP (site oficial)


38

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

19

03/10/2011

Escopo !!! 39

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

40

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

20

03/10/2011

User Stories X Use Case


41

Um Use Case define um conjunto de cenrios que descreve o comportamento do sistema em termos de seqncias de aes gerando o mapa para a realizao de um requisito ou necessidade do cliente. As User Stories so usadas para criar estimativas de tempo para a reunio de Release Planning. Elas tambm so usadas no lugar de um documento enorme descrevendo os requisitos. (e so enviadas ao Acceptance Test)

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

User Stories
42

As User Stories so escritas como coisas que o sistema precisa fazer para eles. Elas so similares aos cenrios de uso, exceto que elas no esto limitadas a descrever uma interface com o usurio. O formato delas de cerca de trs sentenas de texto escrito pelo cliente, na terminologia do cliente, sem uma sintaxe especfica.(seno, crie o texto em entrevista e o valide junto ao cliente!!!) As User Stories tambm conduzem a criao dos Acceptance Test. Um ou mais testes de aceitao automatizados devem ser criados para verificar se as User Stories foram corretamente implementadas.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

21

03/10/2011

43

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Fluxo de XP (site oficial)


44

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

22

03/10/2011

Planejar ar iteraes
45

Divida o projeto em etapas de 1 ou 2 semanas; Considere prazos fixos e escolha um dia da semana para integraes e entregas; (segunda ou sextafeira); Planeje reunies dirias para acompanhar a evoluo do projeto (stand-up, meeting matinal); As iteraes sero a unidade de referencia para utilizar as mtricas; Entre no jogo para entregar um\ou produto a cada iterao.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Exemplo de uma iterao em XP


46

Sadf Planejar Iterao


Detalhar Estrias(Criar Tarefas) Descrever Prioridades Estimar Tarefas
Estimar por Comparao

Estimar por Intuio Spike Soluctions

Distribuir Estrias

Construir Testes de Aceitao Programar


Fazer Teste Unitrio Implementar

Stand-up meetings Executar Testes de Aceitao Disponibilizar Iterao

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

23

03/10/2011

Fluxo de XP (site oficial)


47

posse coletiva do cdigo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Testes, testes e mais testes...


48

O teste de aceitao composto por trs partes: Cenrio: o nmero mnimo de coisas que devemos fazer antes que possamos executar o teste. Operao: o teste em si. Verificao: a ps-condio, aquilo que verdadeiro aps o teste estar concludo.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

24

03/10/2011

Fluxo de XP (site oficial)


49

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

XP no contexto CMM
50

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

25

03/10/2011

Artefatos XP x RUP
51

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Empresas Brasileiras usando XP


52

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

26

03/10/2011

Xplanner
53

http://www.xplanner.org Ferramenta que permite o planejamento e acompanhamento de equipes de desenvolvimento XP.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Ferramenta Xplanner - Tela da estria


54

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

27

03/10/2011

Ferramenta Xplanner - Tela da iterao


55

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Quando no se deve usar XP


56

Possveis barreiras para o sucesso de um projeto XP


Cultura: Quando a empresa possui uma cultura fortemente tradicional com nfase em muita documentao, modelagem, etc. Tamanho da equipe: Beck considera que a equipe deve ser pequena (at 12 pessoas). Espao fsico: O local de trabalho deve servir para aproximar a equipe e facilitar a comunicao. Cliente: Em XP o cliente ou algum que o represente deve trabalhar junto equipe.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

28

03/10/2011

Referncias
57

www.xispe.com.br www.extremeprogramming.org www.xprogramming.com www.agilealliance.org www.cin.ufpe.br/~xprecife Extreme Programming Explained Second Edition, Kent Beck - 2004

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

29

03/10/2011

PROCESSOS DE SOFTWARE
1

SCRUM

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Perdendo no revezamento...
2

O estilo de corrida de revezamento aplicado ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade e flexibilidade mximas. Ao invs disto, um estilo holstico, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor s atuais necessidades competitivas.
Adequado de The New New Product Development Game, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986.

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Scrum em 100 palavras


3

Scrum um processo gil que permite manter o foco na entrega do maior valor de negcio, no menor tempo possvel. Isto permite a rpida e contnua inspeo do software em produo (em intervalos de duas a quatro semanas). As necessidades do negcio que determinam as prioridades do desenvolvimento de um sistema.
As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade.

Entre cada duas a quatro semanas todos podem ver o real software em produo, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um Sprint.
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Origens do Scrum
4

Jeff Sutherland
Uso inicial do scrum na Easel em 1993 IDX e mais de 500 pessoas usando scrum

Ken Schwaber
ADM Apresentao na OOPSLA 96 com Sutherland Trs livros sobre Scrum

Mike Beedle
Padres para o Scrum na PLOPD4

Ken Schwaber and Mike Cohn


Fundaram a Scrum Alliance em 2002, inicialmente junto com a Agile Alliance
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Origens do Scrum
5

The Mythical Man Month by Frederick Brooks, 1975.


Quando um projeto est atrasado, adicionar pessoas ao projeto servir apenas para atras-lo ainda mais. Devemos considerar o tempo que perdemos em gesto e comunicao quando temos pessoas demais trabalhando em um projeto. Ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobr-lo. O programador precisa de "tempo para pensar" alm do "tempo para programar

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Quem usa o Scrum?


6

Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit

Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Scrum tem sido usado para:


7

Software comercial Desenvolvimento interno Desenvolvimento contratado (terceirizao) Projetos de preo fixo Aplicaes Financeiras Aplicaes certificadas pela isso 9001 Sistemas embarcados Sistemas disponveis 24x7 Desenvolvimento por hackers solitrios

Video games Sistemas para suporte vida Sistemas para controle de satlites Websites Software para handhelds Telefones celulares Aplicaes para redes Aplicaes de ISV (Independent Software Vendors) Algumas das maiores aplicaes em produo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Caractersticas
8

Equipes que se auto-organizam O produto evolui em uma srie de Sprints mensais Os requerimentos so listados em um Product Backlog No h prtica de engenharia prescrita (o Scrum adequa-se a todas) Usa regras generativas na criao de um ambiente gil para a entrega de projetos uma das metodologias geis
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Manifesto gil - Valores


9

Indivduos e interaes Software que funciona Colaborao do cliente Resposta mudanas


ao invs de

Processos e ferramentas Documentao abrangente Negociao de contrato Seguir um plano

www.agilemanifesto.org
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Em resumo...
10

Imagem disponvel em: www.mountangoatsoftware.com/scrum


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Sprints
11

Projetos Scrum progridem em uma srie de sprints


Similar s iteraes do XP ou mesmo do RUP

Ocorre em um perodo de duas a quatro semanas Um perodo constante leva a um melhor ritmo O produto projetado, codificado e testado durante o sprint

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Desenvolvimento seqencial versus paralelo


12
Requerimentos Projeto Cdigo Teste

Ao invs de completar uma coisa por vez... ... equipes Scrum fazem um pouco de cada coisa, todo o tempo.

Fonte: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 1986. Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Nenhuma mudana durante o Sprint


13

Change

Planeje a durao dos sprints de acordo com o mximo tempo com o qual voc pode se comprometer a deixar as mudanas fora deles (um ms ou menos)
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Scrum Framework
Papis
14

Dono do produto ScrumMaster Equipe

Cerimnia

Planejamento Reviso Retrospectiva Reunio diria


Artefatos

Product backlog Sprint backlog Burndown charts


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Dono do produto
15

Define as funcionalidades do produto Decide datas de lanamento e contedo Responsvel pela rentabilidade (ROI) Prioriza funcionalidades de acordo com o valor de mercado Ajusta funcionalidades e prioridades Aceita ou rejeita o resultado dos trabalhos

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

ScrumMaster
16

Representa a gerncia para o projeto Responsvel pela aplicao dos valores e prticas do Scrum Remove obstculos Garante a plena funcionalidade e produtividade da equipe Garante a colaborao entre os diversos papis e funes Escudo para interferncias externas
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Equipe
17

Entre 5 e 9 pessoas Multi-funcional


Programadores, testadores, desenvolvedores de interfaces, etc.

Tempo integral
Raras excees (Ex.: Administrador de Base de Dados)

Auto-organizvel
Idealmente, sem ttulos, ainda que possvel

Trocas s na mudana de Sprints

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Scrum Framework
Papis
18

Dono do produto ScrumMaster Equipe

Cerimnia

Planejamento Reviso Retrospectiva Reunio diria


Artefatos

Product backlog Sprint backlog Burndown charts


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

03/10/2011

Planejamento do Sprint
Capacidades da equipe

Planejamento 19
Priorizao

Product backlog

Anlise e avaliao do product backlog Objetivo do sprint

Objetivo

Condies de negcio

Plano

Produto atual

Tecnologia

Decidir como chegar ao objetivo (projeto) Cria tarefas do sprint backlog a partir dos itens do product backlog (user stories / funcionalidades) Horas no sprint backlog

Sprint backlog

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Planejamento do Sprint
20

A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir O Sprint Backlog criado
Tarefas identificadas e estimadas (1 a 16 horas) De forma colaborativa, no apenas feito pelo ScrumMaster

Planejamento de alto nvel considerado

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

10

03/10/2011

Planejamento do Sprint
21

Quero que os usurios do portal possam planejar suas frias, escolhendo itinerrios online.

Modelagem (8 horas) Codificar interface (4) Escrever textos (4) Codificar a classe foo (6) Atualizar testes de performance (4)

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Scrum dirio
22

Parmetros
Dirio 15 minutos

Todos em p! No para a soluo de problemas


Todo mundo convidado Apenas os membros da equipe, ScrumMaster, dono do produto podem falar

Ajuda a evitar reunies adicionais desnecessrias


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

11

03/10/2011

Trs questes, para todos


23

1
O que fizeste ontem?

2
O que vais fazer hoje?

3
H algum obstculo?

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Trs questes, para todos


24

As respostas no so um relatrio para o ScrumMaster Elas so COMPROMISSOS perante os pares

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

12

03/10/2011

Reviso do Sprint
25

Equipe apresenta os resultados obtidos durante o Sprint Tipicamente, demonstrao de novas funcionalidades ou sua arquitetura Informal
2 horas de preparao Sem slides

Todo o time participa O mundo convidado

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Retrospectiva do Sprint
26

Periodicamente, observe o que funciona e o que no funciona Tipicamente de 15 a 30 minutos Feita aps cada Sprint Toda a equipe participa
ScrumMaster Dono do produto Membros da equipe Clientes e outros

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

13

03/10/2011

Inicia, Pra, Continua


27

A equipe discute o que gostaria de:

Iniciar a fazer Parar de fazer


Esta uma das vrias maneiras de se conduzir uma retrospectiva do Sprint

Continuar fazendo

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Scrum Framework
Papis
28

Dono do produto ScrumMaster Equipe

Cerimnia

Planejamento Reviso Retrospectiva Reunio diria


Artefatos

Product backlog Sprint backlog Burndown charts


Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

14

03/10/2011

Product Backlog
29

Os requerimentos Uma lista de todo o trabalho desejado no projeto Idealmente, na forma em que cada item tenha seu peso de acordo com a vontade do cliente ou usurios Priorizado pelo dono do produto Repriorizado no incio de cada Sprint

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Exemplo de Product Backlog


30

Item do Backlog
Permitir que o usurio faa uma reserva Permitir que o usurio cancele a reserva Permitir a troca de datas da reserva Permitir que empregadod do hotel gerem relatrios de lucratividade Melhorar manipulao de erros ... ...
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Estimativa
3 5 3 8 8 30 50

15

03/10/2011

O objetivo do Sprint
31

Breve declarao que ilustre o foco do trabalho Cincias da vida durante o Sprint
Base de Dados
Funcionalidades para estudos genticos da populao

Fazer com que a aplicao rode no SAL Server alm do PostgreSQL Servios financeiros Criar suporte para indicadores de desempenho em tempo real

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Gerenciando o Sprint Backlog


32

Cada indivduo escolhe o trabalho que far


Trabalhos nunca so atribudos

Atualizao diria da estimativa do trabalho restante Qualquer membro da equipe pode adicionar, apagar ou mudar tarefas O trabalho aparece a partir do Sprint Se uma tarefa no clara, defina-a como um item com uma quantidade maior de tempo e subdivida-a depois Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

16

03/10/2011

Sprint Backlog
33

Tarefas
Codificar interface de usurio Codificar regra de negcio Testar Escrever help online Escrever a classe foo Adicionar log de erros

Seg Ter Qua Qui Sex


8 16 8 12 8 8 8 8 8 4 8 4 12 16 8 10 16 4 11 8

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Burndown Chart
34

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Horas

17

03/10/2011

50 40 Horas 30 20 10 0 Seg Ter Qua Qui Sex

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br) 35

Escalabilidade
36

Equipe de 7 2 pessoas
Escalabilidade atravs de equipes de equipes

Fatores de escala
Tipo de aplicao Tamanho da equipe Disperso da equipe Durao do projeto

Scrum usado em projetos envolvendo mais de 500 pessoas

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

18

03/10/2011

Scrum de Scrums
37

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Tipos de Scrum Distribudo


38

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

19

03/10/2011

SCRUM versus XP
39

Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

Referncias
40

www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Agile Project Management with Scrum by Ken Schwaber Scrum and the Enterprise by Ken Schwaber
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

20

03/10/2011

Dicas de Leitura
41

Agile and Iterative Development: A Managers Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Artigos semanais em www.scrumalliance.org
Copyright by Alessandro Cruvinel Machado de Arajo (alessandrocma@terra.com.br)

21