You are on page 1of 106

Aula de hoje!

0 Reviso dos principais conceitos sobre os assuntos:


0 Introduo Engenharia de Software 0 Processos de Software 0 Desenvolvimento gil de software

Reviso Aula 1 e 2

O que engenharia de software


Utilizar conhecimento sobre computadores e computao para ajudar a resolver problemas.

Resolvendo problemas
0 A maioria dos problemas grande e, algumas vezes, difcil de se resolver. Sendo assim, devemos comear a investigao analisando o problema, isto , dividindo-o em partes que sejamos capazes de entender e manipular.

Processo de anlise
Problema

Subproblema 1

Subproblema 2 Subproblema 3

Subproblema4

O processo de sntese
Soluo 1 Soluo 2 Soluo 3 Soluo 4

SOLUO

A crise do software
0 A crise do software: assunto tratado no incio da dcada de 70, o qual deu origem engenharia de software; 0 Evoluo do hardware abria possibilidade de desenvolver softwares poderosos, porm no havia ferramental disponvel para isso; 0 Software era feito de maneira emprica e artesanal; 0 Problemas como prazos no cumpridos, gastos mal estimados e softwares que no atendiam os requisitos;

A crise do software
0 Algumas manchetes antigas - a viso do mercado:
0 Inicio da dcada de 80, revista Business week: Software: a

nova mola propulsora; 0 Mais tarde na dcada de 80, revista Fortune: Crescente defasagem no Software; 0 Ainda na dcada de 80, revista Business week: Armadilha do software: automatizar ou no?; 0 Inicio da dcada de 90, Newsweek: Podemos confiar em nossos softwares?

Crise do software se refere a um conjunto de problemas que encontramos no processo de desenvolvimento do software (Pressman);

Principais problemas da rea de Informtica


Frustrao dos Usurios sobre a
grande promessa da Informtica
0 Esperana que pelo menos parte da promessa se cumpra; 0 Frustrao pela pequena parte da promessa j cumprida, em razo de:

0 Erros, falhas e inadequao dos produtos de software


0 Insegurana na utilizao 0 Prazos excessivamente longos 0 Custos altos e constantes

0 Constante necessidade de manutenes

Principais problemas da rea de Informtica


Sensao dos Desenvolvedores
0 Baixa produtividade no desenvolvimento;

0 Baixa qualidade do produto gerado (erros e adequao s

necessidades do usurio);
0 Impossibilidade de cumprir prazos e custos; 0 Dificuldade em treinar os profissionais nas novas tecnologias;

0 Mudanas constantes em TI/SI (insegurana e necessidade

constante de atualizao)

Principais Tipos de Erros


1) Sistemas desenvolvidos corretamente a partir de especificaes erradas ou incompletas;

2) Corte deliberado do escopo do projeto, em razo do estouro do prazo ou da verba do projeto; e

3) Sistemas desenvolvidos incorretamente a partir de especificaes corretas.


Nakajo e Kume (1991)

Mitos do Software
0 Surgiram nos primrdios do desenvolvimento de software. Ao contrrio da mitologia, que oferece lies que valem a pena serem consideradas, os mitos do desenvolvimento de software s propagam desinformao e confuso.

Mitos do Software Mitos Administrativos


Adotados pela gerncia de desenvolvimento de software, como forma de atenuar as presses.
0 J temos todos os manuais e procedimentos para construo de software; isso suficiente. 0 Meu pessoal tem ferramentas de desenvolvimento de software de ltima gerao e computadores novos. 0 Se sofrermos atraso no prazo, basta adicionar mais programadores ao projeto.

Mitos do Software Mitos do Cliente


Clientes acreditam em mitos sobre software, porque a rea de Informtica nada faz para esclarec-los; como resultado temos falsa expectativa e insatisfao.
0 Uma declarao geral dos objetivos suficiente para se comear a escrever programas; os detalhes sero informados/descobertos ao longo do processo. 0 Requisitos de projeto mudam continuamente, mas isso no problema porque o software flexvel.

Mitos do Software Mitos do Profissional


Velhas atitudes dificilmente morrem (quatro dcadas de cultura de programao), onde a programao era vista como uma forma de arte.
0 Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estar completo. 0 Enquanto o programa no estiver pronto, no temos nenhuma maneira de avaliar sua qualidade. 0 O nico produto a ser entregue em um projeto bem sucedido o programa funcionando.

Concluso!
No vamos atender a demanda de software com qualidade, a preo compatvel e num contexto de globalizao e da busca de resultados, desenvolvendo-os de maneira artesanal e emprica. preciso adotar mtodos, tcnicas e ferramentas que permitam a aplicao de princpios cientficos ou, no mnimo, adequados produo eficiente de software.

Software O que ?
So programas de computador e documentao associada. Produtos de software podem ser desenvolvidos para um cliente especfico ou para o mercado em geral.

Atributos essenciais de um bom software


Manutenibilidade

O software deve ser escrito de forma que possa evoluir para atender s necessidades dos clientes. Esse um atributo crtico, porque a mudana de software um requisito inevitvel de um ambiente de negcio em mudana.

Atributos essenciais de um bom software


Confiana e proteo
A confiana do software inclui uma srie de caractersticas como confiabilidade, proteo e segurana. Um software confivel no deve causar prejuzos fsicos ou econmicos no caso de falha de sistema. Usurios maliciosos no devem ser capazes de acessar ou prejudicar o sistema.

10

Atributos essenciais de um bom software


Eficincia
O software no deve desperdiar os recursos do sistema, como memria e ciclos do processador. Portanto, eficincia inclui capacidade de resposta, tempo de processamento, uso de memria etc.

Atributos essenciais de um bom software


Aceitabilidade
O software deve ser aceitvel para o tipo de usurio para o qual foi projetado. Isso significa que deve ser compreensvel, usvel e compatvel com outros sistemas usados por ele.

11

Os papis da equipe de desenvolvimento


Anlise e Definio de Requisitos

ANALISTA PROJETISTA

Projeto do Sistema
Projeto do Programa Implementao do Programa Testes de Unidades Teste de Integrao Teste do Sistema Entrega do Sistema Manuteno

PROGRAMADOR RESPONSVEL POR TESTES

INSTRUTOR

Reviso Aula 3 e 4

12

Modelos em Engenharia de Software

A importncia da modelagem
0 Um modelo : 0 Uma abstrao de um objeto ou fenmeno... 0 ....sob um determinado ponto de vista e ... 0 ...um certo nvel de detalhamento.

SISTEMA
uses CASO DE USO

MODULO

COMPONENTE 1

ATOR

COMPONENTE 2

DIAGRAMA DE CASO DE USO

DIAGRAMA DE COMPONENTE

13

Modelos em Engenharia de Software Princpios da Modelagem


1- A escolha do tipo de modelo a ser criado tem uma profunda influncia sobre como a soluo do problema ser enfocada e construda. 2- Qualquer modelo pode ser expresso em diferentes nveis de preciso.
UML: User Guide - Booch, Rumbaugh, Jacobson.

Modelos em Engenharia de Software Princpios da Modelagem


3- Os melhores modelos so conectados (aderentes) realidade.

4- Um nico modelo no suficiente. Qualquer sistema no trivial melhor enfocado com um pequeno conjunto de modelos semi-independentes.
UML: User Guide - Booch, Rumbaugh, Jacobson.

14

Modelos em Engenharia de Software A utilidade dos modelos


Modelar uma maneira de analisarmos conceitualmente um problema do mundo real usando modelos.
Quem define um problema, j o resolveu pela metade. Julian Huxley Ns construmos modelos para entender melhor um sistema que ser desenvolvido. Construmos modelos de sistemas complexos porque no conseguimos entend-los tal como so, na sua totalidade.

Modelos em Engenharia de Software A utilidade dos modelos


Modelos so teis para:
0 Compreender o problema sob seus diversos aspectos

(entendimento).
0 Representar o ambiente no qual o sistema dever se inserir. 0 Desenvolver solues para o problema (criatividade +

mtodo + tcnicas + ferramentas).

15

Modelos em Engenharia de Software A utilidade dos modelos


Modelos so teis para:
0 Escolher dentre as possveis solues, a mais adequada. 0 Ensaiar (testar) a soluo escolhida (depurao). 0 Registrar

e comunicar o

projeto

para terceiros

(documentao)

Modelos em Engenharia de Software A utilidade dos modelos


Ateno
0 Modelos so teis para a especificao dos requisitos j

definidos mas no so teis para a determinao desses requisitos.


0 Modelar requer o conhecimento da metodologia de

modelagem a ser empregada (sua simbologia e sintaxe), dos procedimentos para sua aplicao e de ferramentas que automatizam a metodologia (se disponveis).

16

Projetando uma casa de cachorro


Casinha de cachorro: Pode ser construida por uma pessoa. Requer: Modelagem mnima Processo simples Ferramentas simples

Projetando uma casa

Casa: A construo ser mais eficiente (especialistas) e mais rpida se feita por equipe. Requer: Modelagem (planta baixa, eltrica, hidrulica etc.) Processo bem definido Ferramentas poderosas

17

Projetando uma grande obra

Modelando uma casa


Maquete um tipo de prototipagem.

18

Modelos em Engenharia de Software A complexidade dos modelos


A complexidade dos modelos adotados (do processo de
modelagem) depende da complexidade do problema a ser modelado.

Modelos em Engenharia de Software A complexidade dos modelos


A complexidade dos modelos adotados (do processo de modelagem) depende da complexidade do problema a ser modelado.

19

Modelos em Engenharia de Software Modelar x Construir


Uma linguagem de modelagem uma notao grfica que os mtodos usam para expressar projetos. Se restringe criao e ensaio dos modelos; no um mtodo de desenvolvimento do produto de software. A transposio do modelo para o produto ser feita atravs do processo de construo de software. Ex.: UML Unified Modeling Language RUP Rational Unified Process
(ex-Unified Software Development Process).

Modelos em Engenharia de Software


0 Modelo de funo (DFD, Caso de uso, etc). 0 Modelo de dados (MER, Dicionrio de Dados, etc) 0 Modelo comportamental (Diagrama de estados, diagrama de

seqncia, etc).
0 Modelo de objetos (Diagrama de classe, de associao, de generalizao, etc.) 0 Modelo de projeto (PERT/CPM, Diagrama de distribuio, etc.) 0 Modelo para testes (Diagrama Ciclomtico, etc) 0 Modelo de custo (Modelo de Putnam, Modelo ABC, etc)

20

Mtodos em Engenharia de Software A burocracia dos Mtodos


0 Mtodos e Metodologias: at que ponto so teis e a partir de

onde apenas criam formalismo desnecessrio (burocracia) ?


0 Uniformizam o trabalho;

0 Aumenta a produtividade (a mdio prazo);


0 Aumenta a qualidade; 0 Cria sistemas independentes de desenvolvedores; 0 Permite maior controle sobre o projeto.

Modelos de Processo de Software Modelo em Cascata (Waterfall)

21

Ciclos de Vida de Software


0 Existem vrios modelos de ciclo de vida de software (tambm

chamados de Paradigmas da Engenharia de Software), alguns cobrindo apenas as fases do processo que vo da concepo ao desenvolvimento, enquanto outros cobrem concepo, desenvolvimento, implantao e manuteno.
0 So modelos prescritivos porque prescrevem um conjunto de elementos de processo num fluxo de trabalho (seqncia e comunicao entre esses elementos).
PRESCREVER ORDENAR DE MANEIRA EXPLCITA PREVIAMENTE

Processo
0 Processo de software um conjunto de atividades relacionadas que levam produo de um produto de software. 0 Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades fundamentais para a engenharia de software:
0 Especificao de software: funcionalidade e restries ao

funcionamento devem ser definidas.


0 Projeto e implementao de software: o software produzido para

atender s especificaes.
0 Validao de software: garante que o software atenda as demandas

do cliente.
0 Evoluo de software: software deve evoluir atendendo necessidades

de mudanas.

22

Ciclos de Vida de Software Modelo Clssico (Cascata)


0 Modelo Waterfall (cascata):
0 Modelo didtico que divide o ciclo de vida de 5 a 12 fases (cf. o autor).
0 Adequao:
0 Projetos grandes (cobre todas as fases), 0 Os requisitos esto claramente definidos no incio do desenvolvimento 0 Complexidade baixa 0 Riscos tcnicos e de projeto bem entendidos.

Ciclos de Vida de Software Modelo Clssico (Cascata)

23

Ciclos de Vida de Software Modelo Clssico (Cascata)

Ciclos de Vida de Software Modelo Clssico (Cascata)


1) Definio de Requisitos: Foco: 1) No usurio (voz do usurio)

2) No processo
3) Na documentao 4) No sistema antigo (quando existe) Tarefas:

Extrair os requisitos, especificar cada um deles, redigir uma


Definio de Requisitos e valid-los junto ao usurio.

24

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos:

Ferramentas:
No tem. Tcnicas: Psicologia Entrevistas Questionrios Mapeamento de Processos Brainstorming etc.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos:
Atravs de consulta aos usurios e observao do processo, dos documentos em uso e do eventual sistema existente, extrair as funcionalidades necessrias e as metas ou restries a serem atingidas/respeitadas. Requisito: (adj.) O que se requisitou ou requereu. Condio necessria para obteno de certo objetivo. Quesito. Houaiss

25

Ciclos de Vida de Software Modelo Clssico (Cascata)


LEMBRETE: A especificao de requisitos entregue ao usurio deve ser escrita em uma linguagem mais prxima do mundo do usurio;

Ciclos de Vida de Software Modelo Clssico (Cascata)

26

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos: Especificar quais os requisitos e no como eles devero ser realizados (detalhes de implementao). Esse refinamento ser feito na fase de anlise e/ou projeto. Diferena entre:
0 Listar clientes em ordem alfabtica (e)

0 Listar clientes classificados em ordem alfabtica crescente

(Tabela TC_Cliente, campo TC_Nome. Montar viso para a tabela ordenada).

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos: Praticamente todo requisito identificado precisa de uma

especificao.
Especificar: (v.t.d.) Indicar espcie de; explicar detalhadamente; Descrio rigorosa e minuciosa das caractersticas que um material, uma obra ou um servio devero apresentar.

27

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos: Por exemplo: Requisito: O sistema deve aceitar multi-empresas. Especificao: Cada empresa tem CNPJ, endereo e Diretoria prpria. Os clientes so cadastrados para a Holding e no por empresa. O oramento gerado para a Holding. Atualmente existem 4 empresas, mas esse nmero poder chegar a 10 unidades.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos:
0 Gerar um Documento de Especificao, redigido em linguagem inteligvel para o usurio. FINALIDADE: 1. O usurio dever analisar e confirmar se a descrio est correta e se atende suas necessidades e expectativa. 2. Ser usado pelos desenvolvedores, durante o processo de construo do produto e para sua verificao (ESTAMOS
CONSTRUINDO CERTO O PRODUTO).

3. Quando o produto for entregue, ser usado pelo usurio para validao (ESTAMOS CONSTRUINDO O PRODUTO CERTO).

28

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos:
Caractersticas do Documento de Especificao: 1. Linguagem de domnio do usurio; 2. Preciso; 3. Completo; 4. Consistente; 5. Sem redundncias; 6. Sem ambiguidades.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos: (Doc.de Especificao):
0

Requisitos Funcionais: O que o produto de software deve fazer (funcionalidades). 0 Casos de Uso ou eventos 0 Atividades do Processo 0 Aquisio de informaes 0 Tratamento das informaes 0 Armazenagem das informaes 0 Distribuio das informaes 0 Acionamento de dispositivos

29

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos: (Doc.de Especificao):
0

Requisitos No Funcionais: Metas e restries que o sistema deve atender.


1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Etc.

Confiabilidade Disponibilidade (misso crtica) Segurana Portabilidade Economia Compatibilidade (legados) Flexibilidade Acurcia (preciso) Adequao a Legislao Desempenho Problemas da interface homem-mquina Restries fsicas e operacionais

Ciclos de Vida de Software Modelo Clssico (Cascata)


Definio de Requisitos:
Aplicar os Princpios da Engenharia de Software, especialmente: Abstrao, Decomposio e Generalizao. 0 Abstrao: Fixar-se nos aspectos importantes,

ignorando os detalhes. 0 Decomposio: Dividir em partes para lidar com a complexidade. 0 Generalizao: Buscar caractersticas comuns relegando as caractersticas especficas ( uma forma de abstrao). 0 No usar Formalidade e Flexibilizao.

30

Ciclos de Vida de Software Modelo Clssico (Cascata)

Ciclos de Vida de Software Modelo Clssico (Cascata)


2) Anlise de Requisitos: Foco:
0 Nos objetivos, restries, alternativas e riscos de cada alternativa.

Ferramentas:
0 Metodologias/tcnicas de modelagem e anlise, ferramentas

(editores grficos, CASEs etc).

31

Ciclos de Vida de Software Modelo Clssico (Cascata)


0 Anlise de Requisitos

ou Engenharia de Requisitos:
0 Obter uma compreenso completa dos requisitos de software, atravs de:

Descoberta

Refinamento
Especificao Tcnica Modelagem

Ciclos de Vida de Software Modelo Clssico (Cascata)


Anlise de Requisitos: Definio detalhada do domnio das informaes e do domnio das funcionalidades requeridas para o software.

Modelos de Dados
SISTEMA

Modelos de Funcionalidade

32

Ciclos de Vida de Software Modelo Clssico (Cascata)


Anlise de Requisitos:
0 O desenvolvedor deve definir as estruturas de dados,

conhecendo cada uma delas (tipo, tamanho, volume, consistncias, inter-relao, se disponvel em bases de dados, forma de coleta etc).
0 Tambm deve definir detalhes da funcionalidade (detalhes de

como o sistema deve se comportar, tanto em funcionalidade como em performance, segurana etc.)

Ciclos de Vida de Software Modelo Clssico (Cascata)

33

Ciclos de Vida de Software Modelo Clssico (Cascata)


3) Projeto de Software:

Foco:
0 Nos dados, componentes de software e no produto final de

software (projeto arquitetural do produto de software).

Ferramentas:
0 Metodologias/tcnicas de modelagem e anlise, ferramentas

(editores grficos, ferramentas CASE etc).

Ciclos de Vida de Software Modelo Clssico (Cascata)


ARQUITETURA DE SOFTWARE
SISTEMA

MDULO PRINCIPAL

INFORMAES FUNES

MDULO 01

MDULO 02

MDULO 03

MDULO 04

MDULO 05

MDULO 06

MDULO 04

MDULO 07

MDULO 08

MDULO 10

MDULO 11

MDULO 09

MDULO 09

34

Ciclos de Vida de Software Modelo Clssico (Cascata)


ARQUITETURA DE SOFTWARE
SISTEMA

MDULO PRINCIPAL

INFORMAES FUNES

MDULO 01

MDULO 02

MDULO 03

MDULO 04

MDULO 05

MDULO 06

MDULO 04

MDULO 07

MDULO 08

MDULO 10

MDULO 11

MDULO 09

REUSABILIDADE

MDULO 09

Ciclos de Vida de Software Modelo Clssico (Cascata)


Projeto de Software:
0 Representao das funes do sistema, em uma forma que

possa ser transformada em programas executveis.


0 Decompor o produto de software desejado em partes

(programas, mdulos, componentes etc).


0 Recompor, pensando no produto final (monoltico) e nas

arquiteturas candidatas.

35

Ciclos de Vida de Software Modelo Clssico (Cascata)


Projeto de Software:
0 Criar documento de especificao para cada parte do

produto:
0 O que cada parte deve fazer (entradas, comportamento, sadas),

gerando

uma

especificao

para

buscar

componentes

candidatos (reusabilidade).
0 Definir a relao entre os componentes.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Projeto de Software:
Projeto Preliminar: Transformao dos requisitos numa arquitetura de dados e de funcionalidade. Projeto Detalhado: Refinamento das representaes estruturais, obtendo-se assim representaes detalhada dos algoritmos (nos casos em que for necessrio) e dos dados.

36

Ciclos de Vida de Software Modelo Clssico (Cascata)


Projeto de Software: O projeto de interfaces (IHC) um projeto especfico dentro do ciclo de vida do software. Com a tendncia de prototipao das interfaces para o usurio validar, esse tipo de projeto est se tornando presente tambm na fase de definio de requisitos.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Atividades do Projeto de Software:

37

Ciclos de Vida de Software Modelo Clssico (Cascata)

Ciclos de Vida de Software Modelo Clssico (Cascata)


4) Codificao: Foco:
0 Nos algoritmos e nas linguagens de

programao (sintaxe,

limitaes, funcionalidade disponvel, etc.)

Ferramentas:
0 Linguagens de programao, geradores de cdigo fonte, CASE de

amplo espectro, etc.

38

Ciclos de Vida de Software Modelo Clssico (Cascata)

Ciclos de Vida de Software Modelo Clssico (Cascata)


5) Teste: Foco:
0 Nas especificaes e nas sadas do produto de software.

Ferramentas:
0 Tcnicas de testagem, procedimentos da Qualidade,

procedimentos da instalao, ferramentas de testagem.

39

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste:
0 Testar contra especificaes de requisitos 0 Testar contra padres da instalao 0 Nomenclatura de campos, tabelas 0 Padres de interfaces 0 Padres da qualidade

Teste:

Ciclos de Vida de Software Modelo Clssico (Cascata)


MDULO PRINCIPAL
INFORMAES FUNES

0 Unitrio (cada unidade de software)


SISTEMA

MDULO 01

MDULO 02

MDULO 03

MDULO 04

MDULO 05

MDULO 06

MDULO 04

MDULO 07

MDULO 08

MDULO 10

MDULO 11

MDULO 09

MDULO 09

40

Teste: 0 De Integrao do sistema (todos os componentes, a partir de uma estratgia de aglutinao progressiva).
SISTEMA

Ciclos de Vida de Software Modelo Clssico (Cascata)


MDULO PRINCIPAL
INFORMAES FUNES

MDULO 01

MDULO 02

MDULO 03

MDULO 04

MDULO 05

MDULO 06

MDULO 04

MDULO 07

MDULO 08

MDULO 10

MDULO 11

MDULO 09

MDULO 09

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste:
0 De integrao entre sistemas (sistema gerado, com outros

sistemas com os quais haver troca de informaes).


SISTEMA DE POUPANA

SISTEMA DE CONTA CORRENTE

SISTEMA DE CAIXA ELETRNICO

SISTEMA HOME INTENET BANKING

41

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste
Elementos necessrios:
0 Padres da instalao e Def. Requisitos 0 Ferramentas de teste

0 Planos de teste (Sute de teste)


0 Critrios de teste 0 Critrios de completude (quando parar ?) 0 Gerenciamento dos casos de teste

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste: Execuo de um caso de teste

42

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste: Recomendao IEEE (Computer Dictionary).

0 Falha (Failure)

Resultados incorretos
0 Defeito (Fault)

Instruo ou definio incorreta.


0 Erro (Mistake)

Falha resultante de ao humana Uma falha pode ter como origem um defeito ou um erro.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Teste:
Testes especiais:
0 Performance 0 Segurana

0 Stress etc.

Teste na rea de produo:


0 Teste inicial (alfa)

0 Beta teste

43

Ciclos de Vida de Software Modelo Clssico (Cascata)

Ciclos de Vida de Software Modelo Clssico (Cascata)


6) Manuteno: Foco:
0 Depende do tipo de manuteno (algoritmo, legislao, estrutura

organizacional, processo, tecnologia, etc)

Ferramentas:
0 Linguagens de programao, ferramentas CASE etc.

44

Ciclos de Vida de Software Modelo Clssico (Cascata)


Manuteno:

Fase mais longa do ciclo.


Tipos de manuteno:
0 Corrigir erros remanescentes 0 Adaptar a novas situaes e necessidades 0 Preparar para futuras alteraes

Ciclos de Vida de Software Modelo Clssico (ambientes)

45

Ciclos de Vida de Software Modelo Clssico (Cascata)


7) Implantao:
Transferir da rea de desenvolvimento para a rea de produo.
0 Preparar rea de rede (grupo, usurios, diretrios, direitos)

0 Converso de arquivos ou
0 Gerao dos arquivos (caso Biblioteca) 0 Treinamento dos usurios 0 Integrar tecnologias

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata:
Como todo modelo, tem suas limitaes. 1) Imagina o processo como sendo seqencial e progressivo, onde cada fase estanque, mesmo com as setas indicando retorno a fases anteriores, cada fase vista isoladamente. Tenta manter a linearidade (similar a uma linha de produomanufatura) para manter o processo previsvel e de fcil gerenciamento.

46

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata: 2) A fase de Anlise s se inicia aps obteno dos requisitos, que devem ser:
0 Completos 0 Corretos 0 No ambguos 0 No redundantes 0 Sem detalhes de implementao

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata:
3) No estimula o desenvolvimento conjunto (desenvolvedor e usurio). O trabalho com o usurio est restrito fase de Definio de Requisitos. 4) A entrega do produto s ocorre depois de terminado. Quando o usurio tem a chance de ver se o produto atende suas necessidades e expectativa, ele j est pronto.

47

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata:
5) No prev um Estudo de Viabilidade, que deveria iniciar ao trmino da Definio de Requisitos e, no mximo prolongar-se at o incio da Anlise.

O Estudo de Viabilidade tem como finalidade evitar que


recursos sejam gastos na tentativa de solucionar o problema de maneira errada, alm de verificar se a soluo vivel do ponto de vista econmico.

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata: 6) No menciona o Gerenciamento do Processo de Software, que ocorre simultaneamente construo do produto e altamente influenciado pela complexidade deste ltimo.

48

Ciclos de Vida de Software Modelo Clssico (Cascata)


Falhas do modelo Cascata:

7) No facilita a aplicao da tcnica de Engenharia


Reversa (reconstruo de sistema legados).

Reviso Aula 5 e 6

49

Ciclos de Vida de Software


0 As duas primeiras dcadas da ES foram dominadas pelo paradigma do desenvolvimento linear (engenharia progressiva do produto de software).
0 Em seguida aparecem os modelos evolucionrios (ou

evolutivos) que se baseiam num desenvolvimento de um produto inicial que vai sendo submetido a avaliaes do usurio e sendo simultaneamente refinado atravs de sucessivas verses, at que alcance a funcionalidade desejada.

Ciclos de Vida de Software


0 Assim, atividades de desenvolvimento e de validao so

realizadas paralelamente, com um rpido feedback entre elas.


0 O modelo evolucionrio requer

iteratividade (repetir fases do processo) e interatividade (trabalho conjunto entre


usurio e desenvolvedor).

0 Inicialmente o modelo evolucionrio previa ciclos lineares (paradigma do desenvolvimento linear no modelo

incremental); depois o modelo ganhou a forma de espiral.

50

Ciclos de Vida de Software Mudana de Paradigma


Paradigma Linear puro
Modelo Cascata

Transio: Ciclos lineares

Modelo Incremental (adota as etapas do modelo linear puro, porm com iteratividade e desenvolvimento/teste durante todo o processo)
Modelo Evolutivo (ou exploratrio) Modelo de Prototipao Modelo Espiral Tradicional RAD RUP

Paradigma Evolucionrio

Ciclos de Vida de Software

1) Modelo Incremental

51

Ciclos de Vida de Software Modelo Incremental


0
0

Modelo Incremental
uma adaptao (para melhor) do modelo de desenvolvimento linear, pois trata-se de um arranjo de vrios pequenos ciclos em cascata.
0

A diferena que cada verso do produto de software tem uma nova funcionalidade (incremento), definida no incio do ciclo.

Depois de desenvolvida, cada verso ser entregue ao usurio para testes. Cada verso implementa uma nova funcionalidade (incremento) que acrescida funcionalidade anterior.

Ciclos de Vida de Software Modelo Incremental


Fases do modelo incremental: 1. Identificar (grosso modo) requisitos e conceitos do novo sistema. 2. Desenvolver um projeto do produto (ser o projeto bsico). 3. Construir o produto. A primeira verso bsica e ser o ncleo do produto (funcionalidade bsica).
4. Essa verso entregue para o usurio testar. 5. A partir dessa verso, o usurio vai detectar a prxima funcionalidade necessria no sistema. 6. O ciclo volta para a fase 1, porm o projeto agora ir se restringir

apenas novas funcionalidades (no refaz o que j foi entregue).

52

Ciclos de Vida de Software Modelo Incremental

Ciclos de Vida de Software Modelo Incremental


Problemas:
1. Parte da falsa premissa de que os requisitos iniciais sero

mantidos (primeira verso ou ncleo do produto).


2. Em razo das mudanas de requisitos, o escopo total do

projeto s conhecido aos poucos, portanto as


estimativas de prazo/custo estaro erradas.

53

Ciclos de Vida de Software

2) Modelo Evolutivo

Ciclos de Vida de Software Modelo Evolutivo


0

Modelo Evolutivo ou Desenvolvimento Exploratrio


0

Tem como objetivo promover um desenvolvimento conjunto (desenvolvedor trabalhando junto com o usurio) a fim de descobrir os requisitos de maneira incremental.

Diferente do modelo incremental, esse modelo volta sempre fase de definio de requisitos, num movimento exploratrio de conceitos do produto e necessidades do usurio.

Pode ampliar e/ou modificar as funcionalidades anteriores

54

Ciclos de Vida de Software Modelo Evolutivo (Exploratrio)

Ciclos de Vida de Software

3) Modelo de Prototipao

55

Ciclos de Vida de Software Prototipao


0

Modelo de Prototipao, tambm chamado de Prottipo

Descartvel, tem como objetivo obter uma melhor definio dos


requisitos do sistema.
0

Diferentemente do Modelo Incremental e do Modelo Evolutivo, que fazem uma explorao para a definio dos requisitos enquanto constroem o produto final, a prototipao

exploratria usa os prottipos apenas para descobrir a


funcionalidade desejada e os riscos implcitos.
0

Depois de definido os requisitos, o prottipo descartado e inicia-se a construo do produto final.

Ciclos de Vida de Software Prototipao


0

Como o prottipo no ser usado como produto final, pode-se (deve-se) omitir aspectos de esttica, performance, segurana etc.
Deve-se trabalhar com ferramentas adequadas rpida gerao de cdigo. O prottipo no precisa conter toda a funcionalidade do produto final; apenas os aspectos sobre os quais havia alto nvel de incerteza, como por exemplo detalhes das entradas ou sadas do sistema, a exatido de um algoritmo ou a correta aplicao de uma nova tecnologia.

0 0

56

Ciclos de Vida de Software Prototipao


0

Vendo o que o prottipo apresenta, o usurio descobre novas necessidades (vendo o que ele tem, descobre o que falta). O desenvolvimento do prottipo comea com uma verso preliminar, aps rpida interao desenvolvedor-usurio. Aps o desenvolvimento do prottipo, dado aos usurios a oportunidade de brincar com ele. Baseado nessa experincia o usurio opina sobre o que est certo, o que est errado, o que est faltando e o que est sobrando.

0 0

Ciclos de Vida de Software Prototipao


0

Aps essa interao, o prottipo modificado e novamente entregue ao usurio para validao. Esse ciclo se repete at que as incertezas sobre os requisitos estejam num nvel mnimo, permitindo assim definir o conjunto de requisitos do produto a ser

desenvolvido.

57

Ciclos de Vida de Software Prototipao


Adotar um ciclo de vida que d conta das atividades seguintes

Ciclos de Vida de Software Prototipao


Problemas:
0

Existe um custo extra, pelo perodo de prototipao, que s se justifica se o nvel de incerteza dos requisitos alto.

O usurio geralmente quer usar o prottipo como produto


(at que o produto seja desenvolvido). Se isto for aceito, aparecero problemas como: fazer pequenas adaptaes, questes de segurana, performance, etc.

58

Ciclos de Vida de Software

4) Modelo Espiral (tradicional)

Ciclos de Vida de Software Modelo Espiral


0 Modelo Espiral (Boehm, 86) d incio a uma nova

tendncia na modelagem, atravs de ciclos repetitivos em espiral.

59

Ciclos de Vida de Software Modelo Espiral


0

No modelo espiral tradicional, existem quatro quadrantes,

onde se executa prioritariamente as seguintes tarefas:

1o quadrante 2o quadrante

Planejar Analisar riscos

3o quadrante
4o quadrante

Construir
Avaliar

Ciclos de Vida de Software Modelo Espiral


0 A espiral inicia de um centro onde o movimento ainda

pouco acentuado (o produto est em sua verso inicial; apenas um cerne do que ser o produto final).
0 Com o passar dos ciclos, o movimento fica maior em

cada quadrante, o que representa bem o fato de que, medida que a espiral cresce, o trabalho e/ou a complexidade do produto de software aumenta.

60

Ciclos de Vida de Software Modelo Espiral


PLANEJAR ANALISAR RISCOS

Prototipao como tcnica

AVALIAR

CONSTRUIR

Ciclos de Vida de Software Modelo Espiral


0

Anlise de Riscos:
0

O modelo espiral trouxe uma nfase Anlise de Riscos no desenvolvimento de software (gerncia segura).

Um risco um problema potencial em um sistema, ou a


probabilidade de ocorrer um evento perigoso ou indesejado em determinado momento ou circunstncia.

Atravs da Anlise de Riscos, podemos escolher caminhos com as melhores chances de sucesso, dentro de prazos razoveis.

61

Ciclos de Vida de Software Modelo Espiral


0

O modelo em espiral preconiza o desenvolvimento de software atravs da avaliao de riscos obtidos atravs de sucessivas prototipagens (e/ou simulaes e benchmarking).
0
0
0

Desvantagem:
Aumento de prazo custos no projeto.
Justificativa para isso:
0 0

Complexidade do projeto Incerteza nos requisitos

Ciclos de Vida de Software Modelo Espiral


0

O modelo mantm as caractersticas positivas de documento associado a fases do ciclo (cascata) com fases sobrepostas (incremental) e uso de prototipao (aproveitando o prottipo para produto final).
Parte da premissa de que a forma de desenvolvimento de software no pode ser completamente determinada de antemo (centro da espiral). Assim, atravs de fases sucessivas e algumas atividades-chave (anlise de risco, prototipao, simulao, validao etc) chegamos a um projeto detalhado de software e a construo

simultnea do produto final.

62

Ciclos de Vida de Software

5) Modelo Espiral Atualizado

Ciclos de Vida de Software Modelo Espiral Atualizado


0

O modelo em espiral tem uma verso atualizada, com as seguintes alteraes:


0

Passou de 4 para 6 quadrantes:


0 0 0 0 0 0

Solicitao do cliente Planejamento Anlise de risco Modelagem Construo, teste, instalao e suporte para o cliente testar Avaliao do cliente

63

Ciclos de Vida de Software Modelo Espiral Atualizado

FASES NOVAS

Ciclos de Vida de Software


6) Modelo Espiral para Desenvolvimento Baseado em Componentes

64

Ciclos de Vida de Software Modelo Espiral e Componentes


0

O desenvolvimento baseado em componentes, uma


consequncia da adoo da Orientao a Objeto.

Disponvel imediatamente 0 Sistemas baseados em componentes COTS (Commercial Off-The-Shelf de prateleira) reusveis em larga escala ou CBS (COTS Based Systems - vide desenvolvimento baseado em COTS e Mtricas COTS)

Ciclos de Vida de Software Modelo Espiral e Componentes


0

Trata-se de uma variao do modelo de desenvolvimento em espiral atualizado, onde as fases 4 e 5 (modelagem e construo-teste-instalao-suporte para teste) tem duas

possveis formas de desenvolvimento:

65

Ciclos de Vida de Software Modelo Espiral e Componentes


MODELO ESPIRAL ATUALIZADO

FASES MODIFICADAS

Ciclos de Vida de Software Modelo Espiral e Componentes


Duas possveis formas de desenvolvimento:
1. Identificar componentes candidatos: 0

Identificar componentes candidatos (produtos de software que tem a funcionalidade requerida) Procurar o componente (bibliotecas, outros projetos, mercado, internet etc)

66

Ciclos de Vida de Software Modelo Espiral e Componentes


2. Obter e disponibilizar componentes:
0

Caso no existam componentes prontos, a fase ser desenvolvida como no modelo espiral adaptado (neste ciclo da espiral), com a construo do componente necessrio.

Se existirem componentes, eles sero recuperados e catalogados na biblioteca do projeto. Em seguida sero aplicados na construo do produto, encerrando essa fase.
O ciclo continua na fase de avaliao do cliente.

Ciclos de Vida de Software Modelo Espiral e Componentes

67

Ciclos de Vida de Software

7) Modelo Espiral WIN-WIN

Ciclos de Vida de Software Modelo Espiral WIN-WIN


O dilogo usurio-desenvolvedor tem caractersticas de negociao:
0 0

O usurio quer a mxima funcionalidade O desenvolvedor deve lembr-lo sobre prazo/custo/performance decorrentes do tamanho do projeto Existem muitas outras situaes de negociao entre interesses do usurio e restries do desenvolvedor

68

Ciclos de Vida de Software Modelo Espiral WIN-WIN


0

A melhor negociao (para a organizao) aquela dirigida para resultados Ganha-Ganha (Win-Win):
0

O cliente ganha por obter um produto que satisfaa a maioria de suas necessidades

E o desenvolvedor pode trabalhar com oramentos e prazos realistas.

Ciclos de Vida de Software Modelo Espiral WIN-WIN


0

O modelo Espiral Win-Win (Boehm, 98) define um conjunto de atividades de negociao que se iniciam a cada ciclo da espiral. Essas atividades so assim definidas:

1. Identificar os interessados* (stakeholders) na prxima rodada de negociaes. 2. Determinar as condies favorveis (de ganho) para esses

interessados.
3. Avaliar riscos e alternativas.
(*) Interessados: pessoas da organizao que tm interesse no sucesso do sistema, ou sero criticadas se ele falhar.

69

Ciclos de Vida de Software Modelo Espiral WIN-WIN


4. Definir qual ser o prximo incremento do sistema

(prximo nvel do produto e do processo).


5. Validar as definies ou apurar incorrees. 6. Revisar as eventuais incorrees e obter

comprometimento.

Ciclos de Vida de Software Modelo Espiral WIN-WIN

70

Ciclos de Vida de Software


8) Modelo RAD Rapid Application Development

Ciclos de Vida de Software Modelo RAD


0

Segue o padro incremental, porm enfatiza um desenvolvimento rpido (geralmente 60 a 90 dias) e a base da Fbrica de Software*. Trata-se de uma adaptao do modelo linear-seqencial (cascata) no qual a velocidade obtida pela aplicao de componentes reutilizveis (COTS), mltiplas equipes especializadas de desenvolvimento (cada um faz apenas o que sabe fazer melhor).

Adequado para casos em que os requisitos e o escopo esto bem definidos.

* Fbrica de Software: ter processos claros e depender mais deles do que das pessoas, de forma a ter resultados mais previsveis. O termo software factory(fbrica de software em ingls) foi empregado pela primeira vez em 1969, pela japonesa Hitachi, mas s comeou a ficar popular no incio dos anos 90. A idia era aplicar conceitos da indstria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos. Fonte: BRANDO, Aline. Texto: O que Fbrica de Software.. Disponvel em: http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1197. Acessado em 12 de maro de 2012.

71

Ciclos de Vida de Software Modelo RAD


Fases:
0
PROJETO: Microsoft Office SUB-PROJETOS: Word, Power Point, Outlok

Inicialmente o projeto dividido em sub-projetos. Todos os sub-projetos que podem iniciar juntos so designados para equipes diferentes. A base da formao das equipes reunir tcnicos especializados em uma atividade ou fase do desenvolvimento de software (modelagem de banco de dados, projeto de IHC, etc.).

Ciclos de Vida de Software Modelo RAD


Cada sub-projeto executar as seguintes fases:
1. 2.

Modelagem de Negcio: Modelar o fluxo da informao fluindo atravs da organizao (negcio). Modelagem de Dados: O fluxo definido no item 1 agora transformado num conjunto de objetos de dados.

3.

Modelagem do Processo: Analisa as transformaes nos objetos de dados, atravs de adio, modificao, excluso ou recuperao de dados, a fim de implementar uma funcionalidade de negcio.

72

Ciclos de Vida de Software Modelo RAD


4.

Gerao da Aplicao: O modelo RAD pressupe o uso de tcnicas L4G e gerao automtica de cdigo, sempre que possvel.
L4G- Linguagens de Quarta Gerao: Linguagens no-procedurais (definem o que e no como)

5. Testar e concluir o desenvolvimento (sincronizar e estabilizar): Em seguida a equipe dissolvida para iniciar outro sub-projeto ou mesmo reintegrar-se em equipes que esto com o trabalho em desenvolvimento.

Ciclos de Vida de Software Modelo RAD


0

Desvantagens:
0

Para grandes projetos, precisa de um nmero maior de pessoas.

O produto tem que ser apto a ser modularizado (subprojetos) e permitir a aplicao de componentes reutilizveis.

No adequado a projetos de alto risco.

73

Ciclos de Vida de Software Modelo RAD


A ltima equipe responsvel pela sincronizao e estabilizao das partes

Ciclos de Vida de Software


9) Modelo RUP RATIONAL UNIFIED PROCESSING

74

Ciclos de Vida de Software Modelo RUP


0

Desenvolvimento de software a partir de um framework genrico, que pode ser especializado para diferentes aplicaes, organizaes, nveis de competncia e tamanho de projetos. Caractersticas:
0 0 0 0 0

Baseado em componentes reutilizveis Usa UML para modelar o produto Dirigido a casos de uso Centrado na arquitetura Iterativo e Incremental

Ciclos de Vida de Software Modelo RUP


0 Recomenda o uso de Casos de Uso (Use Cases) para capturar a

funcionalidade do produto.
0 Um modelo de Casos de Uso formado pelo conjunto de diagramas de

Caso de Uso.
0 Vantagem: est dirigido a cada usurio (ator).
0 A arquitetura de software deve contemplar seus aspectos esttico e

dinmico.

75

Ciclos de Vida de Software Modelo RUP

RUP - Conceitos
FASES Na fase de Concepo, decide-se o que ser desenvolvido.

76

RUP - Conceitos
FASES Na Elaborao faz-se uma anlise de risco, constri-se uma arquitetura executvel, para realizar um teste de viabilidade e outras atividades para garantir o sucesso do projeto.

RUP - Conceitos
FASES Na fase de Construo o produto de software construdo, garantindo que, ao final de cada iterao, teremos um software executvel, para ser liberado aos usurios.

77

RUP - Conceitos
FASES Finalmente, na Transio o produto de software instalado na rea de produo, juntamente com a documentao, o treinamento e suporte para os usurios.

RUP - Conceitos
No desenvolvimento de cada fase, executamos diversos tipos de atividades, chamadas disciplinas.

78

RUP - Conceitos

Em cada iterao, empregamos esforo em algumas ou em todas as disciplinas que constituem o processo de software.

Reviso aulas 7 e 8

79

Modelos geis
Incio
0 Final dos anos 90 presencia o surgimento de diferentes mtodos: 0 Crystal; 0 eXtreme Programming; 0 Scrum;

Os principais envolvidos nesse movimento publicaram o manifesto gil em 2001;

Modelos geis
Princpios do Manifesto gil
0

Quatro valores 0 Indivduos e interaes so mais importantes que processos e ferramentas; 0 Entregar software funcionando em prazos curtos mais importante do que documentao completa e detalhada; 0 Adaptao a mudanas mais importante do que seguir o plano inicial; 0 Colaborao com o cliente mais importante do que negociao de contratos;

80

Modelos geis
Princpios do Manifesto gil
0 Doze princpios:
1. 2. 3. 4.

5.
6.

Maior prioridade satisfazer o cliente atravs da entrega contnua e rpida de software com valor agregado; Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento; Entregar frequentemente o software funcionando, em prazos de poucas semanas a poucos meses; Pessoas relacionadas ao negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho; O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face;

Modelos geis
Princpios do Manifesto gil
0 Doze princpios (continuao):
Software funcionando a principal medida de progresso; 8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente; 9. Contnua ateno excelncia tcnica e bom design aumentam a agilidade; 10. Simplicidade essencial; 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis; 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo
7.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de acordo

81

Modelos geis
Caractersticas

nfase na melhora da usabilidade atravs de incrementos curtos, os quais tem como foco as prioridades do cliente; 0 Objetivo chave melhorar a usabilidade dos produtos;
0

Modelos geis
Aplicao
0 Projetos pequenos ou mdios. Pois para projetos grandes a falta de gerncia de mudanas traz alto custo nos projetos.; 0 Equipes pequenas ou mdias; 0 Requisitos dinmicos ou em constante mudana; 0 Necessidade de desenvolver software de forma mais rpida;

82

XP Extreme Programming
Caractersticas Bsicas
0 Caractersticas:
0 Feedbacks contnuos e concretos em ciclos curtos; 0 Abordar planejamento incremental; 0 Flexibilidade na implementao de funcionalidade. 0 Confiar em programadores e clientes para monitorar o

progresso do desenvolvimento. programadores.

0 Acreditar na comunicao oral e na colaborao dos 0 Confiar no processo de evoluo do projeto.

XP Extreme Programming
Os quatro valores
0

Comunicao: Alguns problemas nos projetos de desenvolvimento Simplicidade: Em relao ao processo e codificao, XP prope o

ocorrem porque fatos importantes no so comunicados no momento certo. principio de fazer um produto simples que funcione, ao invs de fazer um produto muito complicado sem possibilidade de uso no futuro.

0
0

Feedback: Feedback concreto e frequente do cliente, do time e dos


trs primeiros valores.

usurios finais oferece maior possibilidade de dirigir melhor o esforo.

Coragem: Este valor somente tem peso se estiver combinado com os

Coragem: preciso ter coragem para manter a simplicidade do sistema deixando para depois as decises e finalmente necessrio coragem para confiar no feedback permanente durante o processo de desenvolvimento ao invs de tentar adivinhar tudo com antecedncia.

83

Fases do processo
Resumo

Fases do processo
Explorao
0 Levantamento de requisitos e estudo de arquitetura; 0 Cliente escreve os cartes de estrias; 0 Programadores estudam e testam tecnologias para construir arquitetura do sistema;

Casos de uso simplificados

84

Fases do processo
Planejamento do release
0 Objetivo desta fase levantar escopos e prazos para o

release; 0 Execuo do jogo de planejamento; 0 Cliente classifica estrias em nveis de prioridade; 0 Programadores indicam velocidade estimada para cada estria; 0 Escopo e prazos para release so determinados;

Fases do processo
Planejamento da iterao
0 Programadores escrevem tarefas para estrias; 0 Tarefas tambm podem incluir atividades no relacionadas diretamente a estrias; 0 Cada programador escolhe algumas tarefas; 0 Estima-se nmero de horas necessrio para tarefa; 0 Estima-se fator de carga; 0 Calcular prazos segundo estimativas anteriores;

85

Fases do processo
Desenvolvimento da iterao
0 Programador escreve testes de unidade que orientaro a codificao de sua tarefa; 0 Programador escolhe parceiro para codificao da tarefa; 0 Codificao em pares; 0 Aplicao de testes de unidade para verificao das tarefas e das estrias; 0 Aplicao de testes funcionais;

Fases do processo
Resumo

86

Fases do processo
Entrega do release
0 Execuo de testes funcionais que retratam sistema de ponta a ponta; 0 Aprovao do release; 0 Implantao do release; 0 Produo: 0 Refinamento de performance;

Fases do processo
Resumo

87

Fases do processo
Manuteno
0 Estado normal de um projeto que utiliza XP; 0 Refactorings (Refatorao); 0 Adoo de novas tecnologias; 0 Incluso de estrias; 0 Trabalhar em sistemas que j esto em produo mais lento e merece mais ateno;
Refactoring um processo de reorganizao da estrutura interna do software, sem alterar o seu comportamento externo. um modo disciplinado de reorganizar cdigo, facilitando posterior depurao, eliminando cdigo presumvel de introduzir erros.

Prticas
Resumo

88

Prticas
Jogo do planejamento

0 O jogo de planejamento enfatiza: 0 As regras de negcio (cliente) 0 Consideraes tcnicas (equipe tcnica); 0 Definio do escopo de cada iterao; 0 A nfase est em guiar o projeto; 0 Construo dos cartes de estrias e dos cartes de tarefas;

Prticas
Pequenas verses
0 Criar verses pequenas do software, contendo poucas funcionalidades novas; 0 Receber feedback rapidamente; 0 No investir demais em algo incorreto, ou pior, que se revele no necessrio e no valorizado pelos usurios.

89

Prticas
Metforas
0 O objetivo abstrair os conceitos do mundo real; 0 Estabelecer um vocabulrio apropriado para o projeto; 0 Manter todos os desenvolvedores em sintonia com o projeto; 0 Auxilia a definir nomes a objetos ou classes;

Prticas
Projeto simples
0 O objetivo criar a soluo mais simples possvel, que seja suficiente para implementar as funcionalidades de cada iterao; 0 o oposto da ideia de projetar para o futuro. O objetivo concentrar os esforos da equipe naquilo que se tem certeza absoluta de que ser necessrio hoje;

90

Prticas
Testes
0 XP tem a preocupao em criar softwares saudveis, que funcionem corretamente e permaneam assim ao longo do tempo, medida que recebem novas funcionalidades e alteraes; 0 Os programadores devem primeiramente descrever os testes de unidade e o cliente descrever os testes funcionais, de forma que a confiana na funcionalidade possa se tornar parte do programa desenvolvido;

Prticas
Testes Testes de Unidade:
0 So considerados elementos chaves em XP, pois so criados antes do cdigo e armazenados em um repositrio junto ao cdigo que ser testado. 0 Um fator importante para a utilizao dos testes de unidade a economia;

91

Prticas
Testes
Testes Funcionais: 0 Constituem a primeira indicao que as estrias dos clientes so vlidas; 0 Normalmente, so escritos pelos clientes ou usurios finais atravs dos cartes de estria com suporte de um membro do time responsvel por testar o sistema. 0 Testes funcionais tambm so usados como testes de validao, anteriores liberao de uma verso do sistema.

Prticas
Refatorao
0 o processo de melhorar o projeto de um cdigo que j est funcionando. 0 Deve-se refatorar onde for possvel e sempre que possvel. 0 Reescrever o cdigo atual, parte por parte, fazendo com que ele fique cada vez mais manutenvel. 0 Tais alteraes no mudam o comportamento das funcionalidades, apenas melhoram a estrutura do cdigo. 0 Os testes de unidade oferecem segurana para o que o que j estava funcionando continue funcionando.

92

Prticas
Programao em pares
0 Custos: H na literatura estudos mostrando que a diminuio na
produtividade acompanhada por uma diminuio na quantidade de erros e falhas, levando a uma diminuio significativa no tempo de descobrimento e correo das falhas, de forma a compensar a diminuio de produtividade na fase de codificao.

0 O motorista e navegador: Dessa forma, enquanto o motorista

codifica uma determinada tarefa, o navegador deve estar sempre pensando em estratgias e sugestes de codificao, assim como deve estar a todo o momento acompanhando o que o que est sendo digitado, alertando para possveis erros, assim como para codificaes fora do padro.

Prticas
Programao em pares
0 Benefcios: 0 Todas as decises envolvem duas pessoas; 0 H no mnimo duas pessoas responsveis pelo cdigo; 0 Troca de conhecimento; 0 Todo o cdigo revisado; 0 Cdigos mais simples e dentro dos padres; 0 Reduo do nmero de erros;

93

Prticas
Propriedade coletiva
0 Qualquer um pode mudar qualquer parte do cdigo; 0 Prtica que causa certo impacto e resistncia; 0 Todo cdigo alterado deve ser testado; 0 Todos so responsveis pelo cdigo;

Prticas
Integrao contnua
0 Quanto maior o perodo entre as integraes mais problemas surgiro; 0 Deve-se atualizar o repositrio em curtos intervalos de tempo ou a cada nova funcionalidade significante; 0 Testes realizados de forma automtica para permitir que erros sejam detectados, isolados e corrigidos prontamente;

94

Prticas
Semana de 40 horas

0 Horas trabalhadas no so diretamente proporcionais a produtividade; 0 Horas extras eventuais ou em um determinado perodo so tolerveis; 0 Necessidade constante indica falhas no plano de projeto e na estimao dos prazos;

Prticas
Cliente presente
0 O cliente parte da equipe de desenvolvimento; 0 Fundamental para facilitar o processo de feedback; 0 Na impossibilidade do cliente deve existir um proxy dentro da equipe, ou seja, um canal de comunicao;

95

Prticas
Padres de codificao
0 Dar ao cdigo um estilo consistente independente do autor; 0 Facilitar o entendimento entre do cdigo por todos que participam do projeto; 0 Pode-se seguir padres definidos por grandes empresas, porm todos devem estar de acordo;

Papis
Programador
0 Estimar prazos para estrias; 0 Construir cartes de tarefas; 0 Construir testes de unidade; 0 Implementar cdigo; 0 Realizar refatorao (refactoring);

96

Papis
Cliente
0 Escrever cartes de estria; 0 Definir escopos; 0 Trabalhar nos testes funcionais;

Papis
Testador
0 Trabalhar com cliente nos testes funcionais;

97

Papis
Supervisor
0 Coletar mtricas do projeto de duas a trs vezes por semana; 0 Tomar atitudes para que o projeto no entre em caminhos errados;

Papis
Treinador
0 Garantir que projeto seja extremo; 0 Ajudar no que for necessrio; 0 Manter a viso do projeto;

98

Papis
Gerente
0 Agendar reunies de planejamento; 0 Garantir fluncia das reunies; 0 Fazer ata das reunies; 0 Manter supervisor informado das decises das reunies; 0 Buscar recursos;

XP
Aspectos positivos
0 Boas ideias: 0 Viso centrada no comportamento dos envolvidos; 0 nfase na participao ativa do cliente; 0 nfase na comunicao dentro da equipe; 0 Acompanhamento mais prximo alimentado pelos feedbacks; 0 Anlise e projeto so simples; 0 Testes frequentes e intensivos;

99

XP
Aspectos negativos
0 A falta de uma fase de planejamento mais profunda dificulta a definio de contratos que envolvam custos e prazos;

0 XP difcil de ser aplicado: 0 Prticas excessivamente relacionadas; 0 Ausncia de um projeto mais detalhado: 0 Necessidade de mais refactorings no futuro; 0 Ausncia de ligao mais forte entre projeto e cdigo; 0 Foco no cdigo perigoso para softwares extensos;

Scrum
Caractersticas
0 Processo gil que visa permitir a entrega de pores prontas do software com frequncia quinzenal ou mensal; 0 O cliente determina as prioridades; 0 A equipe se auto organiza para atender estas prioridades da melhor forma; 0 Foi criado como um processo de desenvolvimento de produtos, no direcionado especificamente a desenvolvimento de software; 0 O termo scrum vem do rugby. Denota a unio da equipe que se move em conjunto em direo ao objetivo;

100

Scrum
Caractersticas
0 Equipes auto organizadas; 0 Requisitos so reunidos em uma lista conhecida como backlog do produto (Um backlog uma lista de itens priorizados); 0 Scrum no prescreve prticas de engenharia de software;

Scrum
Caractersticas
24h

30 dias

Backlog do produto

Backlog do sprint

Sprint

Entrega do incremento de software

101

Scrum
Sprints
0 O progresso dos projetos que utilizam Scrum dado por meio de sprints;

0 Cada sprint dura de 2 a 4 semanas; 0 A durao dos diferentes sprints deve ser parecida, com o objetivo de imprimir ritmo equipe; 0 Durante um sprint o produto analisado, projetado, desenvolvido e testado; 0 Durante um sprint no podem ocorrer mudanas;

Scrum
Papis
0 Scrum master 0 Representa a gerncia do projeto; 0 Responsvel por garantir que os princpios do Scrum esto sendo seguidos; 0 Remove impedimentos; 0 Garante que o time est produzindo o mximo; 0 Garante colaborao entre todos os envolvidos no projeto; 0 Protege a equipe de interferncias exteriores;

102

Scrum
Papis
0 Time: 0 De 5 a 10 pessoas; 0 Tem pessoas com diferentes perfis: programadores, testadores, etc. 0 Membros devem estar presentes full-time; 0 As equipes so auto organizadas; 0 Trocas na equipe devem ser evitadas ao mximo durante os sprints;

Scrum
Reunies
0 Planejamento do Sprint : 0 O time seleciona um grupo de itens do backlog do produto que eles acreditam ser possvel completar dentro de um sprint;
0 Lembrar que no backlog do produto os itens possuem prioridades
Lista do trabalho a ser feito no projeto

definidas;

0 Criao do sprint backlog realizada pelo time. Eles estimam a durao de cada tarefa;

103

Scrum
Reunies
0 Scrum Dirio
0 Reunies dirias)

0 So realizadas em p; 0 Duram no mximo 15 minutos; 0 Ajudam a evitar reunies desnecessrias; 0 Todo mundo bem vindo, mas apenas time,

scrum master e proprietrio do produto (product owner) podem falar; 0 Trs perguntas so respondidas e cada membro do time se compromete com os outros: 0 O que voc fez ontem? 0 O que voc vai fazer hoje? 0 Est tudo OK?

Scrum Reunies
0 Reviso do Sprint : 0 Time apresenta o que foi desenvolvido durante o sprint; 0 Trabalhos incompletos no so apresentados; 0 Normalmente envolve uma demonstrao das novas funcionalidades ou modificaes na arquitetura do sistema; 0 uma apresentao informal e no deve levar mais que duas horas para ser preparada; 0 Toda a equipe participa;

104

Scrum Reunies
0 Retrospectiva do Sprint: 0 Reunio realizada depois do Sprint; 0 Dura de 15 a 30 minutos, em mdia; 0 Analisa o que est dando certo e o que no est dando certo; 0 Todo mundo participa:
0 Time; 0 Scrum master; 0 Proprietrio do produto (product owner); 0 Outros clientes e usurios finais;

Scrum Artefatos
0 Backlog do produto: 0 Conjunto de requisitos do software; 0 mantido pelo product owner; 0 Pode ser alterado desde que o item em questo no esteja presente no sprint atual; 0 Cada item do backlog do produto tem um valor especifico (prioridade) para o cliente;

105

Scrum Artefatos
0 Sprint backlog: 0 a parte do backlog do produto que vai ser trabalhada no prximo sprint; 0 Inclui uma interpretao que traduz os itens do backlog do produto em tarefas de desenvolvimento; 0 Cada membro da equipe escolhe o seu item; 0 Atualizao diria da estimativa de trabalho restante;

106

You might also like