Você está na página 1de 59

Abordagens de Ciclo de Vida de Sistemas de Informação

Agenda

Fatos e Evidências
Modelos de Processos
Modelos de processos evolucionários
Modelos de Processos Ágeis
O Manifesto Ágil
Metodologias e Frameworks Ágeis
Conclusões

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Fatos e Evidências

Abordagens Ciclos de Vida são


Soluções de Gerenciamento de todas
as fases do Desenvolvimento de
Software, cujos processos e atividades
são caracterizadas por metodologias
com enfoques específicos de acordo
com o perfil dos projetos.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Fatos e Evidências

Sim Abordagens
Perfil dos Projetos

Ciclos de Vida

Caos
Não

Não
Metodologias Sim

Originalmente, modelos de processo prescritivos de Ciclo de Vida foram propostos


para trazer ordem ao caos existente na área de desenvolvimento de software.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos
Ter um ciclo de vida de projeto de sistema é importante pelas seguintes
razões:

Definição das
Definição das atividades
atividades aa serem
serem
executadas
executadas em
em um
um projeto.
projeto.
Consistência
Consistência entre
entre muitos
muitos projetos
projetos de
de
desenvolvimento
desenvolvimento da
da mesma
mesma organiza ção.
organização.
Introdu ção de
Introdução de pontos
pontos de
de verificação para
verificação para oo
controle
controle gerencial
gerencial de
de decisões.
decisões.
Facilidades
Facilidades no
no gerenciamento
gerenciamento de
de prazos.
prazos.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de processo Sequencial ou Cascata

O modelo cascata, algumas vezes chamado ciclo


de vida clássico, sugere uma abordagem
sequencial e sistemática para o desenvolvimento
de software, começando com o levantamento de
necessidades por parte do cliente, avançando
pelas fases de planejamento, modelagem,
construção, emprego e culminando no suporte
contínuo do software concluído.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

O Modelo Cascata é o paradigma mais antigo da engenharia de software.


Entretanto, ao longo das últimas três décadas, as críticas a este modelo de processo
fez com que até mesmo seus mais ardentes defensores questionassem sua eficácia
[Han95]. Entre os problemas às vezes encontrados quando se aplica o modelo
cascata, temos:
Projetos reais raramente seguem o fluxo sequencial
que o modelo propõe. Embora o modelo linear possa
conter iterações, ele o faz indiretamente. Como
consequência, mudanças podem provocar confusão à
medida que a equipe de projeto prossegue.
2. Frequentemente, é difícil para o cliente estabelecer
explicitamente todas as necessidades. O
modelo cascata requer isso e tem dificuldade para
adequar a incerteza natural que existe no
início de muitos projetos.
3. O cliente deve ter paciência. Uma versão operacional
do(s) programa(s) não estará disponível
antes de estarmos próximos do final do projeto. Um
erro grave, se não detectado até o programa
operacional ser revisto, pode ser desastroso.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de processo Incremental

O processo projetado para desenvolver o


software de forma incremental se aplica em
várias situações, onde os requisitos iniciais do
software não são razoavelmente bem definidos,
com a necessidade necessidade de rápido
fornecimento de um determinado conjunto de
funcionalidades aos usuários, para somente após
esse fornecimento, refinar e expandir sua
funcionalidade em versões de software
posteriores.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processo Incremental


O Modelo Incremental
aplica seqüências
lineares, de forma
escalonada, à medida
que o tempo vai
avançando. Cada
seqüência linear gera
“incrementais”
(entregáveis/aprovad
os/liberados) do
software de maneira
similar aos
incrementais gerados
por um fluxo de
processos
evolucionários.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processo Evolucionários

Modelos
evolucionários são
iterativos.
Apresentam
características que
possibilitam
desenvolver
versões cada vez
mais completas do
software.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários


Nível de Mudanças

Necessidades do Negócio

Software, assim como todos sistemas complexos, evoluem ao longo do tempo. Conforme
o desenvolvimento do projeto avança, as necessidades de negócio e de produto mudam
freqüentemente, tornando inadequado seguir um planejamento em linha reta até um
produto final.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processo Evolucionários


Tempo exigido pelo
Processo (Interno)

Tempo exigido pelo Mercado


(Pressão Externa)
Prazos apertados, determinados pelo mercado, tornam impossível completar um
produto de software abrangente, porém uma versão limitada tem de ser
introduzida para aliviar e/ou atender às pressões comerciais ou da concorrência.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processo evolucionários


Nível de Mudanças

Tempo
Um conjunto do produto essencial ou das necessidades do sistema está bem
compreendido, entretanto, detalhes de extensões do produto ou do sistema ainda devem
ser definidos. Em situações como essa ou similares, faz-se necessário um modelo de
processo que tenha sido projetado especificamente para desenvolver um produto que
evolua ao longo do tempo.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

Prototipação.
Em geral é melhor abordagem quando o
cliente define uma série de objetivos
gerais para o software, mas não
identifica, detalhadamente, os requisitos
para funções e recursos.

Em outros casos, quando o


desenvolvedor encontra-se inseguro
quanto à eficiência de um algoritmo,
quanto à adaptabilidade de um sistema
operacional ou quanto à forma em que
deva ocorrer a interação
homem/máquina.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

Espiral O modelo espiral de desenvolvimento é


um gerador de modelos de processos
dirigidos a riscos. Possui duas
características principais que o
distinguem:
A primeira consiste em uma
abordagem cíclica voltada para
ampliar, incrementalmente, o grau de
definição e a implementação de um
sistema, enquanto diminui o grau de
risco do mesmo.
A segunda característica consiste em
uma série de pontos âncora de controle
para assegurar o comprometimento de
interessados quanto à busca de
soluções de sistema que sejam
mutuamente satisfatórias e praticáveis.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

O Modelo Concorrente é orientado


Concorrentes a processos. Se aplica a todos os
tipos de desenvolvimento de
software e fornece uma imagem
precisa do estado atual de um
projeto.
Em vez de limitar as atividades,
ações e tarefas da engenharia de
software a uma sequência de
eventos, ela define uma rede de
processos.
Cada atividade, ação ou tarefa na
rede existe simultaneamente com
outras atividades, ações ou
tarefas. Eventos gerados em um
ponto da rede de processos
disparam transições entre
os estados. Muito utilizado em
desenvolvimento para aplicações
WEB.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de processos evolucionários:

Pontos fracos :

Os softwares modernos são


caracterizados por contínuas
modificações, prazos muito
apertados e por uma ênfase na
satisfação do cliente–usuário.
Em muitos casos, o tempo de
colocação de um produto no
mercado é o requisito mais
importante a ser gerenciado. Se o
momento oportuno de entrada no
mercado for perdido, o projeto de
software pode ficar sem sentido.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de processos evolucionários:

Pontos fracos :
Apesar dos inquestionáveis benefícios proporcionados pelos processos de
software evolucionários há alguns riscos:

A prototipação e outros processos


evolucionários mais sofisticados trazem um
problema para o planejamento do projeto
devido ao número incerto de ciclos
necessários para construir o produto.
A maior parte das técnicas de gerenciamento
e de estimativas do projeto baseia-se em
layouts lineares das atividades, o que faz com
que não se abdiquem completamente.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

Pontos fracos :

Em segundo lugar, os processos


de software volucionários não
estabelecem a velocidade máxima
da evolução. Se as evoluções
ocorrerem numa velocidade
excessivamente rápida, sem um
período de acomodação, é certo
que o processo cairá no caos. Por
outro lado, se a velocidade for
muito lenta, então a produtividade
poderia ser afetada...

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

Pontos fracos :

Em terceiro lugar, os processos


de software devem manter seu
Nível de Qualidade

foco mais na flexibilidade e na


extensibilidade do que na alta
qualidade. Essa afirmação soa
assustadora. Entretanto, deve-se
priorizar mais a velocidade de
desenvolvimento do que a
desenvolvimento com zero
defeito.

Flexibilidade e Extensibilidade

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Evolucionários:

Pontos fracos :

Prolongar o desenvolvimento
em busca da alta qualidade
Tempo exigido pelo

pode resultar em entrega


Processo (Interno)

tardia do produto, quando o


nicho de oportunidade já
desapareceu. Essa mudança
de paradigma é imposta pela
concorrência em situações
em que se está à beira do
caos.

Tempo exigido pelo Mercado


(Pressão Externa)

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Outros Modelos de Processos Àgeis


Na história da engenharia de software há
dezenas de metodologias e descrições de
processos, métodos e notações de
modelagem, ferramentas e tecnologias
obsoletas. Cada um atingiu grande
notoriedade e foi então ofuscado por algo
novo e (supostamente) melhor. Com a
introdução de uma ampla gama de modelos
de processos ágeis — todos disputando
por aceitação pela comunidade de
desenvolvimento de software —, o
movimento ágil está seguindo o mesmo
caminho histórico.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis

•Introdução
•Conceitos e definições.
•Fatos e Dados
•O Manifesto Ágil
•Os 12 princípios do Manifesto Ágil
•Metodologias e Frameworks Ágeis
•Conclusão

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis

Os Métodos Ágeis surgiram no final


da década passada e em fevereiro de
2001 um grupo de dezessete
metodologistas formou a Agile
Software Development Alliance
(www.agilealliance.org) e definiram
um manifesto como uma alternativa
aos métodos tradicionais de
desenvolvimento de software.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis


Conceitos e Definições
AA defini ção de
definição de metodologias
metodologias áágeis
geis de
de desenvolvimento
desenvolvimento de de
software
software foifoi criada
criada durante
durante os os anos
anos 90
90 como
como rea ção contra
reação contra os
os
m étodos de
métodos de desenvolvimento
desenvolvimento "pesados",
"pesados", tipificados
tipificados pelo
pelo
modelo
modelo em em cascata.
cascata. Estes
Estes m étodos eram
métodos eram então
então vistos
vistos como
como
burocr áticos ee lentos
burocráticos lentos ee criavam
criavam uma
uma contradi ção em
contradição em rela ção
relação
àà ideia
ideia que
que oo trabalho
trabalho dos
dos engenheiros
engenheiros dede software
software éé eficaz.
eficaz.

Inicialmente,
Inicialmente, as
as metodologias
metodologias áágeis
geis eram
eram denominadas
denominadas como
como
m étodos de
métodos de desenvolvimento
desenvolvimento "leves",
"leves", mas
mas em
em 2001
2001 alguns
alguns
elementos
elementos da
da comunidade
comunidade encontraram -se na
encontraram-se na estância
estância de
de
sky
sky de
de Snowbird
Snowbird ee criaram
criaram oo "The
"The Agile
Agile Manifesto"
Manifesto" no
no qual
qual
adotaram
adotaram oo nome
nome Metodologias
Metodologias ÁÁgeis.
geis.

Este
Este Manifesto
Manifesto foi
foi criado
criado com
com oo intuito
intuito de
de fazer
fazer aa união
união entre
entre
as
as diferentes
diferentes metodologias
metodologias áágeis,
geis, ee éé apresentado
apresentado como
como
sendo
sendo aa definição canônica
definição canônica do
do desenvolvimento
desenvolvimento áágil.gil.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis


Conceitos e Definições
ÁÁgil
gil éé uma
uma nova
nova forma
forma de
de gestão
gestão ee
desenvolvimento
desenvolvimento de de Software
Software que
que usa
usa uma
uma
abordagem
abordagem de de planejamento
planejamento ee execu ção
execução
iterativa
iterativa ee incremental
incremental voltado
voltado para
para processos
processos
emp íricos (complexos,
empíricos (complexos, ca óticos ou
caóticos ou com
com muita
muita
incerteza,
incerteza, temtem mudan
mudançaça ao
ao longo
longo do
do processo,
processo,
não
não sãosão repetitivos
repetitivos ee são
são imprevis íveis).
imprevisíveis).

Divide
Divide oo problema
problema emem produtos
produtos menores
menores ee que
que
visa
visa entregar
entregar software
software funcionando
funcionando
regularmente,
regularmente, visa
visa aa aproxima ção ee maior
aproximação maior
colabora ção do
colaboração do time
time de
de desenvolvimento
desenvolvimento com
com
os
os experts
experts de
de neg ócios
negócios

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis


Conceitos e Definições
Metodologias
Metodologias ÁÁgeis
geis focalizam
focalizam aa
comunica
comunicaçãoção face -to-face, visando
face-to-face, visando redu ção
redução
dos
dos riscos
riscos associados
associados asas incertezas
incertezas dos
dos
projetos,
projetos, ee busca
busca responder
responder as as mudan ças
mudanças
de
de forma
forma mais
mais rrápida
ápida ee natural.
natural.

Orienta -se na
Orienta-se na satisfa ção final
satisfação final dos
dos clientes
clientes
por
por meio
meio da
da ado ção de
adoção de pr áticas de
práticas de gestão
gestão ee
de
de engenharia
engenharia de de software
software comcom foco
foco nos
nos
valores
valores ee princ ípios cujo
princípios cujo objetivo
objetivo maior
maior éé
entregar
entregar oo produto
produto queque oo cliente
cliente realmente
realmente
deseja
deseja ee que
que ser
seráá úútil
til ee com
com qualidade.
qualidade.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis


Projetos de Software
Fatos e Dados
•Apenas 1/3 dos Projetos demandados e
executados, atendem aos requisitos
descritos e demandados pelos clientes e
têm sucesso.

•Apenas 32% dos projetos entregues são


considerados sucesso. 24% são puro
fracasso (cancelados, ou engavetados -
nunca colocados em produção ou utilizados
pelo cliente), 44% são desafiados (sofreram
atrasos, estouraram o budget, não atendem
as necessidades, estão cheios de defeitos).

Apenas 1/3, em média, dos Projetos demandados e executados,


atendem aos requisitos descritos pelos clientes e têm sucesso.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Modelos de Processos Ágeis

Por que ser ágil? Alguns Fatos e dados

Perdade
Perda de confian
confiança docliente
ça do clienteeeem
em
trabalharcom
trabalhar comososdesenvolvedores
desenvolvedoresde de
softwareespec
software específico. Muitasvezes
ífico. Muitas vezesescolhem
escolhem
outraforma
outra formadedeconcep
concepção
ção ououaquisi
aquisição de
ção de
softwareque
software quenão
nãoenvolva
envolvaaa
corresponsabilidadede
corresponsabilidade deconcep
concepção
ção ee
definição.
defini ção.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação
Modelos de Processos Ágeis
Por que ser ágil? Alguns Fatos e dados
Estresse, tensão, acusações jogos de
culpas e repasses de responsabilidades
de ambas as partes quanto da ocorrência
de falhas graves e omissões no produto
de software.

Indefinições de requisitos com time de


Desenvolvedores jogando para o alto
decisões que seriam autônomas seja por
medo de exposição ou capacidade
técnica.

Inversão de valores com entre clientes ou


usuários e técnicos, desconfiança das
equipes de projetos nas lideranças e
Gerentes “Para-raios para receber o
“mea- culpa!” AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

O Manifesto Ágil
Por meio de um processo baseado
na experiência e na observação,
com ciclos constantes de
inspeção e adaptação, a equipe
trabalha sempre num ambiente de
Enfatiza a comunicação, melhoria contínua.
colaboração com o cliente e
atividades que trazem valor
imediato na produção de
software com qualidade.

O manifesto propõe uma


nova abordagem para o O Manifesto Ágil não rejeita os processos e ferramentas, a
desenvolvimento, fazendo-o documentação, a negociação de contratos ou o planejamento,
de forma direta, eliminando mas simplesmente mostra que eles têm importância
gastos com documentação secundária quando comparados com os conceitos chave do
excessiva e burocrática, manifesto.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação
1.Nossa maior prioridade é satisfazer o cliente através da
entrega contínua e adiantada de software com valor agregado.
2.Mudanças nos requisitos são bem-vindas, mesmo

Os 12 princípios do Manifesto Ágil


tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das
mudanças visando vantagem competitiva para o cliente.
3.Entregar frequentemente software funcionando, de poucas
semanas a poucos meses, com preferência à menor escala de
tempo.
4.Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.
5.Construa projetos em torno de indivíduos motivados. Dê a
eles o ambiente e o suporte necessário e confie neles para
fazer o trabalho.
6.O método mais eficiente e eficaz de transmitir informações
para e entre uma equipe de desenvolvimento é através de
conversa face a face.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação
7.Software funcionando é a medida primária de
progresso.
8.Os processos ágeis promovem
desenvolvimento sustentável. Os

Os 12 princípios do Manifesto Ágil


patrocinadores, desenvolvedores e usuários
devem ser capazes de manter um ritmo
constante indefinidamente.
9.Contínua atenção à excelência técnica e bom
design aumenta a agilidade.
10.Simplicidade--a arte de maximizar a
quantidade de trabalho não realizado--é
essencial.
11.As melhores arquiteturas, requisitos e
designs emergem de equipes auto-organizáveis.
12.Em intervalos regulares, a equipe reflete
sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Metodologias e Frameworks Ágeis


“Desenvolvimento ágil" é o termo utilizado por diferentes Metodologias e Frameworks que
desenvolvem software de forma iterativa e incremental. as metodologias ágeis mais comuns
são:
Extreme
Extreme Programming
Programming (XP),
(XP),
Open UP
••Open UP
Lean Development,
••Lean Development,
Feature-Driven Development
••Feature-Driven Development (FDD),
(FDD),
Kanban,
••Kanban,
RUP
••RUP
Scrum
••Scrum
Etc.
••Etc.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

O Manifesto Ágil

Os Conceitos chave do Manifesto Ágil


são:

1 – Foco no Indivíduos e interações com suporte de


invés de processos e ferramentas.

2. Software operante e necessário ao invés de


documentação como efeito demonstração.

3. Colaboração e participação intensa do cliente ao


invés de negociação fria e formal de itens de e
contratos.

4. Respostas rápidas a mudanças ao invés de


planos sofisticados.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Metodologias e Frameworks Ágeis

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

XP Extreme Programming
As boas Práticas de XP incluem:
•The Customer is Always Available (O cliente sempre
Metodologia disponível).
Metodologia baseada
baseada em
em
comportamentos •Metaphor (Uso de metáforas no projeto),
comportamentos ee atitudes
atitudes com
com foco
foco
em
em agilidade
agilidade de
de equipes
equipes ee qualidade
qualidade •Planning Game (mento do jogo) ,
de
de projetos,
projetos, apoiada
apoiada em
em valores
valores como
como •Small Releases (Pequenas versões)
simplicidade,
simplicidade, comunicação,
comunicação, feedback
feedback •Acceptance Tests (Testes de Aceitação)
ee coragem
coragem que
que nos
nos submetem
submetem ao ao •Test First Design (Primeiro os testes)
reconhecimento.
reconhecimento. •Continuous Integration (Integração Contínua)
•Simple Design (Simplicidade de Projeto)
Propicia
Propicia que
que oo projeto
projeto seja
seja executado
executado •Refactoring (Refatoração - melhoria constante do
dentro
dentro do
do prazo
prazo ee do
do orçamento,
orçamento, código)
fazendo
fazendo então
então com
com que
que oo cliente
cliente fique
fique •Pair Programming (Programação em dupla)
satisfeito
satisfeito ee aa equipe
equipe de
de •Move People Around (Rodízio de pessoas)
desenvolvimento
desenvolvimento não não estresse
estresse com
com oo •Collective Code Ownership (Propriedade coletiva - O
projeto.
projeto. código é de todos da equipe)
•Coding Standards (Padronização do código)
•40 Hour Week (Otimizando as jornadas de trabalho)
•Etc. AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Open UP As boas Práticas de Open Up


incluem:
Processo
Processo Unificado
Unificado Aberto
Aberto (Open
(Open Unified
Unified
•O OpenUP é regido por quatro princípios:
Process).
Process). Originalmente
Originalmente chamado
chamado de de BUP
BUP (Basic
(Basic
Unified
Unified Process)
Process) pela
pela IBM
IBM queque em
em 2005
2005 foi
foi liberado
liberado 
para
para aa Fundação
Fundação Eclipse
Eclipse ee •Equilibrar as prioridades concorrentes
renomeado
renomeado parapara OpenUP
OpenUP em 2006. 
em 2006. Aplica
Aplica umauma para
abordagem
abordagem iterativa
iterativa ee incremental
incremental em em um
um ciclo
ciclo dede •maximizar o benefício aos Stakeholders, 
vida
vida estruturado,
estruturado, focando
focando na na natureza
natureza colaborativa
colaborativa
do
do processo
processo de de desenvolvimento
desenvolvimento de de software,
software, aa •Colaborar para alinhar os interesses e
partir
partir de
de um
um conjunto
conjunto compacto
compacto de de atores,
atores, tarefas
tarefas
ee artefatos compartilhar o Entendimento 
artefatos em
em relação
relação ao ao RUP.
RUP.
OO OpenUP
OpenUP pode
pode ser
ser definido
definido como:
como:
◦◦ Compacto
Compacto –– Utiliza
Utiliza apenas
apenas conteúdos
conteúdos •Focar na arquitetura, o mais cedo
fundamentais
fundamentais ee definidos.
definidos. possível, para reduzir o risco e organizar o
◦◦ Completo
Completo –– Abrange
Abrange todastodas as
as fases
fases do
do ciclo
ciclo de de desenvolvimento  Evoluir para
vida
vida do
do desenvolvimento
desenvolvimento de de um
um software.
software. continuamente obter feedback e
◦◦ Extensível
Extensível –– Pode-se
Pode-se utilizá-lo
utilizá-lo da
da forma
forma que
que foifoi
definido
definido mas
mas também
também éé possível
possível adicionar
adicionar novos
novos
conteúdos
conteúdos para
para atender
atender novas
novas características
características do do •Promover melhorias.
projeto.
projeto.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Lean Development As boas Práticas de LD incluem:


AA filosofia
filosofia "Lean
"Lean Thinking"
Thinking" (ou
(ou "Pensamento
"Pensamento
Enxuto")
Enxuto") nasceu
nasceu em em meados
meados dosdos anos
anos 90
90 com
com oo •Elimine Desperdícios
lançamento
lançamento do do best
best seller
seller "The
"The Machine
Machine That
That •2. Inclua a Qualidade no Processo
Changed
Changed the the World
World :: The
The Story
Story ofof Lean
Lean
Production". •3. Crie Conhecimento
Production". Os Os princípios
princípios de
de just-in-time,
just-in-time,
qualidade
qualidade total,
total, teoria
teoria das
das restrições,
restrições, melhoria
melhoria •4. Adie Decisões e
contínua
contínua ee flexibilidade
flexibilidade aplicados
aplicados na na indústria
indústria Comprometimentos
japonesa,
japonesa, maismais precisamente
precisamente na na Toyota
Toyota ee •5. Entregue o quanto antes
conhecidos
conhecidos como como Toyota
Toyota Way
Way inspiraram
inspiraram também
também •6. Respeite as Pessoas e
aa indústria
indústria de de software
software ee fez
fez surgir
surgir aa abordagem
abordagem
do "Empower" a equipe
do Lean
Lean Software
Software Development.
Development. O O processo
processo aplica
aplica
os
os princípios
princípios abordagens
abordagens de de desenvolvimento
desenvolvimento de de •7. Otimize o Todo
software
software ágil.
ágil. AA premisa
premisa assumida
assumida éé que:
que: Acelerar
Acelerar
aa produção
produção do do desenvolvimento
desenvolvimento de de Software
Software éé
geralmente
geralmente uma uma questão
questão dede melhorar
melhorar oo processo
processo
ao
ao invés
invés de
de adicionar
adicionar pessoas.
pessoas. Pare
Pare de
de fazer
fazer
coisas
coisas queque oo cliente
cliente não
não valoriza!
valoriza! Vista
Vista os
os óculos
óculos
do
do cliente!
cliente! ""

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Feature Driven Development


O
O Desenvolvimento
Desenvolvimento orientado
orientado por
por Funcionalidades
Funcionalidades As boas Práticas de FDD incluem:
(do
(do inglês,
inglês, Feature
Feature Driven
Driven Development,
Development, ou ou FDD).
FDD).
Metdologias
Metdologias de de desenvolvimento
desenvolvimento de de software
software que
que • Modelagem Orientada a Objetos do
serviram
serviram dede base
base para
para oo termo
termo “metodologia
“metodologia ágil”.
ágil”. Domínio.
Seus
Seus criadores
criadores participaram
participaram dada redação
redação dodo •- Desenvolvimento por funcionalidade.
Manifesto
Manifesto Ágil
Ágil para
para Desenvolvimento
Desenvolvimento de de Software,
Software, •- Classe proprietária, ou seja, não temos
em
em 2001.
2001. Nessa
Nessa ocasião,
ocasião, oo representante
representante da da FDD
FDD foi
foi propriedade coletiva do código. Cada classe
Jon
Jon Kern,
Kern, que
que trabalhava
trabalhava na na TogetherSoft,
TogetherSoft, tem seu dono.
substituiu
substituiu Peter
Peter Coad.
Coad. OO FDD
FDD não
não éé uma
uma •- Equipes de recursos: destinadas a
metodologia
metodologia de de gerenciamento
gerenciamento de de projetos
projetos de
de desenvolver recursos necessários ao
software.
software. Tem
Tem como
como principal
principal foco
foco cobrir
cobrir os
os projeto, de forma secundária.
processos
processos da da engenharia
engenharia de de software,
software, ee não
não do
do •- Inspeção é realizada constantemente para
gerenciamento.
gerenciamento. EstáEstá mais
mais próximo
próximo do do XP
XP do
do que
que do
do garantir a boa qualidade do código e do
Scrum.
Scrum. O O FDD
FDD éé muitas
muitas vezes
vezes utilizado
utilizado em
em projeto.
conjunto
conjunto com
com oo Scrum
Scrum para
para oo desenvolvimento
desenvolvimento de de •- Gerenciamento de configuração.
software.
software. Enquanto
Enquanto oo primeiro
primeiro fornece
fornece umum processo
processo •- Integração contínua.
de
de trabalho
trabalho para
para oo Scrum
Scrum Team,
Team, oo Scrum
Scrum sese •- Visibilidade de progressos e resultados.
concentra
concentra no no gerenciamento
gerenciamento do do projeto
projeto como
como umum
todo.
todo.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Kanban As boas Práticas de FDD incluem:

• Utilização de quadros físicos com cartões


Método
Método dede desenvolvimento
desenvolvimento de de software
software como ferramentas para tornar o processo visual
com
com fortes
fortes bases
bases emem práticas
práticas Lean,
Lean, e transparente, embora nem todo quadro físico
como
como objetivo
objetivo otimizar
otimizar oo processo
processo de de com cartões utilizado em métodos ágeis pode
desenvolvimento. ser chamado de um sistema Kanban. Muitas
desenvolvimento. Este Este método
método limita
limita oo
vezes estes quadros podem ser apenas controles
trabalho
trabalho em
em progresso,
progresso, apresentando
apresentando aa visuais que permitem ao time acompanhar a
evolução
evolução dede forma
forma visual,
visual, tornando
tornando os os evolução de seu trabalho.
problemas
problemas evidentes
evidentes ee cultivando
cultivando uma uma •Se não houver limite de trabalho em progresso e
cultura
cultura de
de melhoria
melhoria contínua.
contínua. O O processo
processo sinal para puxar mais trabalho, não é um sistema
de
de produção
produção puxada
puxada exige
exige que
que cada
cada Kanban.
operação
operação do do processo
processo sejaseja alimentada
alimentada •entregue.O Kanban pode ser utilizado em
pela
pela demanda
demanda da da etapa
etapa anterior,
anterior, equipes de desenvolvimento de novos produtos,
estabelecendo equipes de suporte, equipes de manutenção e
estabelecendo uma uma ligação
ligação direta
direta entre
entre oo
melhoria de produtos, entre outros. Além disso,
consumo
consumo realreal do
do cliente
cliente ee aa quantidade
quantidade é aplicável a equipes de variados tamanhos,
produzida.
produzida. Dessa
Dessa forma,
forma, um
um item
item muito embora, seja recomendável formar equipes
vendido,
vendido, geraria
geraria aa demanda
demanda para para aa menores, devido à eficiência da comunicação e
fabricação
fabricação dede outro.
outro. diversos outros benefícios destacados pelos
métodos ágeis, como Extreme Programming e
Scrum. AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

RUP
OO IBM
IBM Rational
Rational Unified
Unified Process
Process (RUP)
(RUP) éé um
um
framework
framework dede processo
processo dede engenharia
engenharia dede software
software
que
que fornece
fornece um
um conjunto
conjunto de
de pr áticas testadas
práticas testadas na
na
ind ústria para
indústria para desenvolvimento
desenvolvimento de de software
software ee
gerência
gerência de
de projetos
projetos (Shuja,
(Shuja, 2007).
2007).

Trata -se de
Trata-se de um
um processo
processo propriet ário, desenvolvido
proprietário, desenvolvido
pela
pela Rational
Rational Software,
Software, atualmente
atualmente subsidi ária da
subsidiária da
IBM,
IBM, que
que usa
usa abordagem
abordagem orientada
orientada aa objetos
objetos ee
preconiza
preconiza aa utililiza ção da
utililização da notação UML
notação UML (Unified
(Unified
Modeling
Modeling Language)
Language) parapara documenta
documentação.ção. ÉÉ
organizado
organizado emem disciplinas
disciplinas (workflows)
(workflows) onde
onde são
são
distribu ídas tarefas
distribuídas tarefas ee responsabilidades
responsabilidades ee gerados
gerados
produtos
produtos dede trabalho
trabalho (artefatos).
(artefatos). O
O ciclo
ciclo de
de vida
vida éé
dividido
dividido em
em fases
fases seq üenciais, as
seqüenciais, as quais
quais podem
podem ser
ser
subdivididas
subdivididas em em itera ções.
iterações.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação
RUP
O Rational Unified Process® (também
chamado de processo RUP®) é um processo
de engenharia de software criado por Ivar
Jacobson, Grady Booch e Jim Rumbaugh em
1998.

O RUP evoluiu ao longo dos anos, em


conjunto com a Unified Modeling Language
(UML).

Embora existam livros publicados sobre


essa metodologia, o RUP em si é um produto
comercial, desenvolvido pela Rational
Software, hoje uma subsidiária da IBM.

O RUP oferece uma abordagem baseada em


disciplinas para atribuir tarefas e
responsabilidades dentro de uma
organização de desenvolvimento.
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

RUP
O
O ciclo
ciclo de
de vida
vida de
de software
software do
do RUP
RUP éé dividido
dividido em
em quatro
quatro fases
fases
seq üenciais, cada
seqüenciais, cada uma
uma conclu ída por
concluída por um
um marco
marco principal,
principal, ou
ou
seja,
seja, cada
cada fase
fase éé basicamente
basicamente umum intervalo
intervalo de
de tempo
tempo entre
entre
dois
dois marcos
marcos principais.
principais.

Cada
Cada fase
fase pode
pode ser
ser dividida
dividida em
em um
um nnúmero
úmero planejado
planejado de
de
itera ções. Al
iterações. ém de
Além de ser
ser um
um processo,
processo, oo RUP
RUP éé tratado
tratado como
como
um
um produto,
produto, associado
associado aoao Rational
Rational Method
Method Composer
Composer (RMC),
(RMC),
oo qual
qual éé desenvolvido
desenvolvido ee mantido
mantido pela
pela IBM
IBM Rational.
Rational. Assim
Assim
como
como qualquer
qualquer outra
outra ferramenta
ferramenta de
de software,
software, oo RUP
RUP est á em
está em
constante
constante evolu ção.
evolução.

AA primeira
primeira versão
versão com
com oo nome
nome ““Rational
Rational Unified
Unified Process
Process” ” foi
foi
aa versão
versão 5.0,
5.0, de
de 1998.
1998. AA ela
ela seguiram -se as
seguiram-se as versões
versões 5.55.5 (1999),
(1999),
2000
2000 (2000),
(2000), 2003
2003 (2003)
(2003) ee 7.0
7.0 (2006).
(2006). No
No momento
momento da da
elabora ção deste
elaboração deste artigo,
artigo, aa versão
versão corrente
corrente éé aa 7.0.1.
7.0.1.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

RUP
O RUP, em suas versões iniciais apoiou-se em melhores práticas observadas
na indústria, a saber:

1. Desenvolvimento de software iterativo (melhor


adequação a mudanças).
2. 2.Gerenciamento de requisitos (identificar e
especificar as necessidades do usuário final).
3. 3.Uso de arquitetura baseada em componente
(visando reuso de componentes).
4. 4.Modelagem visual de software (abstração do
modelo de negócio, por meio de UML).
5. 5.Verificação da qualidade do software
(planejamento, projeto e execução de testes).
6. 6.Controle de alteração no software (controle,
rastreamento e monitoração de mudanças).

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Fases da RUP
Fluxos de Processo Críticos
Inicializaç
Inicialização Elaboraç
Elaboração Construç
Construção Implantaç
Implantação

Modelagem de Negócio
Requisitos
Análise e Projeto
Implementação
Testes
Implantação
Fluxos de Suportes Críticos
Gerência de Configuração e Mudanças
Gerência de Projeto
Monitoramento do Ambiente Const. 1..2..n
Iní
Início Elab. 1..2..n Implant. 1..2..n

Interações
AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

RUP - Melhores Práticas • Adaptar o processo (identificar quanto do processo é


necessário ao projeto) ;

• 2. Balancear as prioridades dos investidores


(compreender e priorizar os requisitos conforme as
necessidades de negócios);

• 3. Colaborar através de equipes (comunicação e


ambientes de colaboração);

• 4. Demonstrar valor iterativamente ( feedback inicial e


contínuo, adaptar os planos, gerenciar alterações);

• 5. Elevar o nível de abstração (reduzir a complexidade e a


quantidade de documentação por meio de reutilização de
recursos existentes);

• 6.Focalizar continuamente na qualidade (testes,


integração contínua, automação de testes incremental).

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum
Metodologia
Metodologia áágilgil para
para gestão
gestão ee
planejamento
planejamento de de projetos
projetos dede Scrum
Scrum éé umauma
metodologia
metodologia áágilgil para
para gestão
gestão ee
planejamento
planejamento de de projetos
projetos dede software.
software. No No
Scrum,
Scrum, osos projetos
projetos são
são devidos
devidos emem ciclos
ciclos
(tipicamente
(tipicamente mensais)
mensais) chamados
chamados de de Sprints.
Sprints.
O
O Sprint
Sprint representa
representa umum Time
Time Box
Box dentro
dentro dodo
qual
qual um
um conjunto
conjunto dede atividades
atividades deve
deve serser
executado.
executado. Metodologias
Metodologias áágeis
geis de
de
desenvolvimento
desenvolvimento de de software
software são
são iterativas,
iterativas,
ou
ou seja,
seja, oo trabalho
trabalho éé dividido
dividido emem itera ções,
iterações,
que
que são
são chamadas
chamadas de de Sprints
Sprints nono caso
caso do do
Scrum.
Scrum.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum - Melhores Pr áticas


Práticas

As
As funcionalidades
funcionalidades aa serem
serem implementadas
implementadas
em
em um
um projeto
projeto são
são mantidas
mantidas emem uma
uma lista
lista
que
que éé conhecida
conhecida como
como Product
Product Backlog.
Backlog. NoNo
início
início de
de cada
cada Sprint,
Sprint, faz-se
faz-se um
um Sprint
Sprint
Planning
Planning Meeting,
Meeting, ouou seja,
seja, uma
uma reunião
reunião dede
planejamento
planejamento na na qual
qual oo Product
Product Owner
Owner
prioriza
prioriza os
os itens
itens do
do Product
Product Backlog
Backlog ee aa
equipe
equipe seleciona
seleciona asas atividades
atividades que
que ela
ela será
será
capaz
capaz dede implementar
implementar durante
durante oo Sprint
Sprint que
que
se
se inicia.
inicia. As
As tarefas
tarefas alocadas
alocadas emem um
um Sprint
Sprint
são
são transferidas
transferidas dodo Product
Product Backlog
Backlog para
para oo
Sprint
Sprint Backlog.
Backlog.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum - Melhores Práticas

AA cada
cada dia
dia de
de uma
uma Sprint,
Sprint, aa
equipe
equipe faz
faz uma
uma breve
breve reunião
reunião
(normalmente
(normalmente de de manhã),
manhã),
chamada
chamada DailyDaily Scrum.
Scrum. O O objetivo
objetivo
éé disseminar
disseminar conhecimento
conhecimento sobresobre
oo que
que foi
foi feito
feito no
no dia
dia anterior,
anterior,
identificar
identificar impedimentos
impedimentos ee
priorizar
priorizar oo trabalho
trabalho do
do dia
dia que
que se
se
inicia.
inicia.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum - Melhores Práticas

Ao
Ao final
final de
de um
um Sprint,
Sprint, aa equipe
equipe
apresenta
apresenta as as funcionalidades
funcionalidades
implementadas
implementadas em em uma
uma
sessão
sessão dede “Sprint
“Sprint Review
Review
Meeting”.
Meeting”.
Faz-se
Faz-se uma
uma Sprint
Sprint
retrospectiva
retrospectiva ee aa equipe
equipe parte
parte
para
para oo planejamento
planejamento do do
próximo
próximo Sprint.
Sprint. Assim
Assim
reinicia-se
reinicia-se oo ciclo.
ciclo.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum - Melhores Práticas


Pesquisas
Pesquisas mostram
mostram que
que oo Scrum
Scrum éé de
de longe
longe oo framework
framework
mais
mais utilizado
utilizado por
por ser
ser oo mais
mais simples
simples ee de
de ffácil
ácil ado ção ee
adoção
adapta ção.
adaptação.

Cada
Cada uma
uma dessas
dessas metodologias
metodologias tem
tem aa sua
sua particularidade
particularidade ee
pr áticas sugeridas
práticas sugeridas mas
mas muitas
muitas vezes
vezes oo que
que vemos
vemos hoje
hoje em
em
dia
dia são
são os
os modelos
modelos hhíbridos,
íbridos, que
que são
são na
na verdade
verdade uma
uma
mescla
mescla dessas
dessas metodologias/frameworks
metodologias/frameworks onde onde as
as melhores
melhores
pr áticas de
práticas de cada
cada metodologia
metodologia éé aplicada
aplicada aa um
um processo
processo
customizado.
customizado.

ÉÉ preciso
preciso analisar
analisar aa necessidade
necessidade ee aa maturidade
maturidade da da equipe
equipe
para
para então
então escolher
escolher umum framework
framework ou ou pr áticas áágeis
práticas geis que
que lhe
lhe
traga
traga oo benef ício esperado.
benefício esperado.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Scrum - Melhores Práticas


A cada dia de uma Sprint, a equipe faz
uma breve reunião (normalmente de
manhã), chamada Daily Scrum. O
objetivo é disseminar conhecimento
sobre o que foi feito no dia anterior,
identificar impedimentos e priorizar o
trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta


as funcionalidades implementadas em
uma Sprint Review Meeting. Finalmente,
faz-se uma Sprint Retrospective e a
equipe parte para o planejamento do
próximo Sprint. Assim reinicia-se o ciclo.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusões:

E quanto as Metodologias tradicionais? É a Morte !!!!!


Não,

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusões:
Vantagens (Cliente)

•Foco e maximização do ROI (Retorno do Investimento) e do


Valor de Negócio;
•Entregas do produto + rápida, frequentes e regulares;
•Aceleração do Time-to-market o que se traduz em ganho de
competitividade;
•Maximização do Value-to-Makert;Foco no que é prioritário e
traz mais valor para o usuário, o que se traduz em ganho de
usabilidade;
•Transparência e visibilidade do status do projeto;
•Flexibilidade para mudanças de requisitos e prioridades
além de maior agilidade na tomada de decisões;
•Melhoria da Qualidade do produto final;
•Produtividade;
•Redução dos riscos e das indesejáveis surpresas

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusões:
Vantagens da Organização Provedora (Gestor
e Times) do software

•Escopo e objetivos claros e priorizados;


•Equipes auto-gerenciáveis, maior autonomia,
disciplina e regularidade;
•Maximização do comprometimento;
•Melhoria na comunicação. A comunicação
intensa com o cliente e a gestão de suas
expectativas são parte do processo;
•Inspeção e Adaptação constantes do
processo em busca da melhoria contínua e a
redução dos desperdícios;
•Antecipação dos problemas e maior
agilidade na tomada de ações.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusões:

Dentre
Dentre as
as principais
principais causas
causas de
de falha
falha na
na ado ção de
adoção de uma
uma
metodologia
metodologia áágil
gil estão:
estão:

-- Filosofia
Filosofia ou
ou aa cultura
cultura da
da empresa
empresa que
que conflitam
conflitam com
com
os
os valores
valores ee princ ípios do
princípios do ÁÁgil;
gil;
-- Falta
Falta de
de suporte
suporte gerencial
gerencial para
para apoiar
apoiar as
as mudan ças; ÉÉ
mudanças;
preciso
preciso desejar
desejar as as mudan ças;
mudanças;
Falta de
--Falta de experiência
experiência ou ou treinamento
treinamento insuficiente
insuficiente no
no
novo
novo processo;
processo; ÉÉ preciso
preciso tornar -se capaz
tornar-se capaz dede trabalhar
trabalhar
de
de maneira
maneira áágil;
gil;
Boicote, falta
--Boicote, falta de
de comprometimento
comprometimento da da pr ópria equipe.
própria equipe. ÉÉ
preciso
preciso reconhecer
reconhecer que que hhá
á espa ço para
espaço para melhorias
melhorias ee
desej á-las;
desejá-las;
Aplicar oo áágil
--Aplicar gil requer
requer organiza ção, determina
organização, determinaçãoção ee
disciplina
disciplina com
com Mudan
Mudançaça de
de posturas.
posturas.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusões:

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusão:

Adotar
Adotar uma
uma metodologia
metodologia ágilágil pode
pode trazer
trazer muitos
muitos benefícios,
benefícios,
mas
mas nós
nós costumamos
costumamos dizer
dizer que
que oo ágil
ágil não
não éé aa bala
bala de
de prata,
prata,
ou
ou seja,
seja, apenas
apenas aplicar
aplicar por
por exemplo
exemplo oo SCRUM
SCRUM ou ou algumas
algumas
de
de suas
suas práticas
práticas ágeis
ágeis por
por si
si só
só não
não vai
vai resolver
resolver osos seus
seus
problemas,
problemas, masmas evidenciar
evidenciar suas
suas fraquezas
fraquezas para
para que
que você
você
possa
possa identificar
identificar ee atuar
atuar sobre
sobre elas.
elas. Cabe
Cabe então
então aa equipe
equipe
atuar
atuar de
de forma
forma pró-ativa
pró-ativa ee desejar
desejar asas mudanças
mudanças parapara que
que os
os
benefícios
benefícios que
que oo ágil
ágil pode
pode proporcionar
proporcionar possa
possa valer
valer de
de
verdade.
verdade.

AFs
Abordagens de Ciclo de Vida de Sistemas de Informação

Conclusão. A história tem demonstrado que


esses modelos tradicionais
proporcionaram uma considerável
contribuição quanto à estrutura
utilizável no trabalho de engenharia
de software e forneceram um
roteiro razoavelmente eficaz para
as equipes de desenvolvimento
Entretanto, o trabalho de
engenharia de software e o seu
produto permanecem “à beira do
caos”.
Roger Pressman

AFs