3 - Processos Descritivos de Engenharia de Software PDF

Teoria de Engenharia de Software
Processos Descritivos de Ciclo de Vida de Software – Desenvolvimento Ágil
Introdução:
• Introdução
• O Manifesto Ágil – 12 Princípios
• Modelos de Processos- Conceitos e Definições
• Princípios da Abordagem de Métodos Ágeis
• Algumas dificuldades para atender os
Princípios de Métodos Ágeis
• Processos orientados a Planos
• Metodologias e Frameworks Ágeis
• Vídeo
• Estudo de Caso
luther.fernandes@gmail.com AFs
Introdução:
Ambiente de negócios de acirrada competitividade global.
Qualidade, produtividade e repostas rápidas são premissas
mandatórias.
Extrema dependência do Software para as transações de
negócio é fato.
Requisitos iniciais em constantes mudanças
Insistência no uso de modelos clássicos tradicionais geram
produtos de software desatualizados, estresse e custos
ascendentes .
A necessidade de desenvolvimento ágil é uma expectativa já
há algum tempo (Stapleton, 1997; Schwaber e
BEEDELE,2001; BECK 1999, 2000).
Introdução:
A filosofia da Abordagem de Métodos Ágeis no Desenvolvimento propõe...
De Para
• Processos e Ferramentas • Indivíduos e Interações

• Documentação abrangente • Software em execução
• Negociação rígida de Contrato • Colaboração Mútua (Cliente e Provedor).
• Plano rigoroso • Resposta rápida às Mudanças
Introdução:
A definição de metodologias ágeis de desenvolvimento de
software foi criada durante os anos 90 como reação contra os
métodos de desenvolvimento "pesados", tipificados pelo
modelo em cascata. Estes métodos eram então vistos como
burocráticos e lentos e criavam uma contradição em relação
à ideia que o trabalho dos engenheiros de software é eficaz.
Inicialmente, as metodologias ágeis eram denominadas como

métodos de desenvolvimento "leves", mas em 2001 alguns
elementos da comunidade encontraram-se na estância de sky
de Snowbird e criaram o "The Agile Manifesto" no qual
adotaram o nome Metodologias Ágeis.
O Manifesto Ágil foi criado com o intuito de fazer a
união entre as diferentes metodologias ágeis, e é
apresentado como sendo a definição canônica do
desenvolvimento ágil.
Introdução:
Manifesto Ágil.
Métodos Ágeis
utilizam uma
Proposição de abordagem
diversos métodos incremental para a
Ágeis. Focalização especificação,
das equipes no desenvolvimento e a
Formalização, desenvolvimento, entrega do software
Planejamento Menor ênfase em
rigorosos e uso de concepção e
Ferramentas Case documentação
Sistemas grandes,
Equipes dispersas,
demora...
80 90 2000
Anos
O Manifesto Ágil
Este Manifesto foi criado com o intuito de fazer a união entre as Por meio de um processo baseado
diferentes metodologias ágeiságil. 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.
6.O método mais eficiente e eficaz de transmitir informações para
Os 12 princípios do Manifesto Ágil e entre uma equipe de desenvolvimento é através de conversa
1.Nossa maior prioridade é satisfazer o cliente face a face.
através da entrega contínua e adiantada de software 7.Software funcionando é a medida primária de progresso.
com valor agregado.
8.Os processos ágeis promovem desenvolvimento sustentável.
2.Mudanças nos requisitos são bem-vindas, mesmo
tardiamente no desenvolvimento. Processos ágeis Os patrocinadores, desenvolvedores e usuários devem ser
tiram vantagem das capazes de manter um ritmo constante indefinidamente.
mudanças visando vantagem competitiva para o 9.Contínua atenção à excelência técnica e bom design aumenta a
cliente. agilidade.
3.Entregar frequentemente software funcionando, 10.Simplicidade--a arte de maximizar a quantidade de trabalho
de poucas semanas a poucos meses, com não realizado--é essencial.
preferência à menor escala de tempo.
4.Pessoas de negócio e desenvolvedores devem
11.As melhores arquiteturas, requisitos e designs emergem de
trabalhar diariamente em conjunto por todo o equipes autoorganizáveis.
projeto. 12.Em intervalos regulares, a equipe reflete sobre como se tornar
5.Construa projetos em torno de indivíduos mais eficaz e então refina e ajusta seu comportamento de acordo.
motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho.
Modelos de Processos Ágeis
Conceitos e Definições
Ágil é uma nova forma de gestão e
desenvolvimento de Software que usa uma
abordagem de planejamento e execução
iterativa e incremental voltado para
processos empíricos (complexos, caóticos
ou com muita incerteza, tem mudança ao
longo do processo, não são repetitivos e são
imprevisíveis).
Divide o problema em produtos menores e

que visa entregar software funcionando
regularmente, visa a aproximação e maior
colaboração do time de desenvolvimento
com os experts de negócios
Modelos de Processos Ágeis

Conceitos e Definições
Metodologias Ágeis focalizam a comunicação
face-to-face, visando redução dos riscos
associados as incertezas dos projetos, e busca
responder as mudanças de forma mais rápida e
natural.
Orienta-se na satisfação final dos clientes por

meio da adoção de práticas de gestão e de
engenharia de software com foco nos valores e
princípios cujo objetivo maior é entregar o
produto que o cliente realmente deseja e que
será útil e com qualidade.
Princípios da Abordagem de Métodos Ágeis -
Envolvimento do Cliente
“O Cliente deve estar envolvido,

diretamente, com o processo de
desenvolvimento, sendo o seu papel
principal de fornece e avaliar os novos
requisitos para o sistema e suas as
interações” .
Entrega Incremental
“O Software é desenvolvido, priorizando

entregas incrementais, que evoluem com
a participação do cliente, especificando as
novas necessidades de requisitos ” .
Focalização em Pessoas
“As habilidades e competências da equipe de

desenvolvimento devem ser reconhecidas e
exploradas, os membros da equipe deve propor
e desenvolver novas formas de trabalhar sem
amarrações em processos rígidos. O foco é no
resultado esperado ” .

Lidar com Mudanças
“Deve –se ter em perspectiva que os requisitos

tendem a mudar, o sistema deve ser projetado, de
modo a atender à Evolutibilidade e
Manutenabilidade, ou seja, ser capaz de
acomodar as mudanças, sendo essas vistas como
um desafio às competências e habilidades da
equipe e não um problema. ” .
Lidar com Mudanças

“Deve –se ter em perspectiva que os requisitos
tendem a mudar, o sistema deve ser projetado, de
modo a atender à Evolutibilidade e
Manutenabilidade, ou seja, ser capaz de
acomodar as mudanças, sendo essas vistas como
um desafio às competências e habilidades da
equipe e não um problema. ” .
Princípios da Abordagem de Métodos Ágeis - !
Valorizar e manter a Simplicidade
“A simplicidade deve ser a razão do

processo de desenvolvimento do software;
sempre que possível busque a clareza de
modo que se evite criar complexidade para
o sistema. Se não puder ser explicado não
projete e nem implemente” .
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.
Algumas dificuldades para atender os Princípios de Métodos Ágeis
Envolvimento do Cliente
“Omisso” “Sustentável”
Contribuição
Domínio /
Métodos ágeis têm sido muito
bem-sucedidos para alguns tipos
de desenvolvimento de
sistemas, no entanto, na prática,
alguns princípios básicos dos
métodos ágeis são, por vezes, “Ausente” “Expectador ”
são difíceis de se realizar:
Intensidade de
Participação
Clima ruim entre membros da Equipe

“Guerra” “Sustentável”
Conhecimentos
Membros individuais da equipe
Domínio /
podem não ter personalidade
orientada para o cooperação e
envolvimento; qualquer seja o
motivo tais contextos criam
dificuldades para o
compartilhamento de soluções. “Caos” “Bando ”
Cooperação Mútua da Equipe
Conciliar muitas partes interessadas

“Estagnação” “Sustentável”
Capacidade de Solução
“Priorizar as mudanças pode ser
extremamente difícil,
(Equipe)
especialmente em sistemas nos
quais existem muitos
stakeholders. Normalmente,
cada stakeholder dá prioridades
diferentes para mudanças “Caos” “Amontoado ”
diferentes...”
Diversidade de Prioridades
(Stakeholders)
Manter a simplicidade
Capacidade de Solução
“Manter a simplicidade exige um
trabalho extra. Sob a pressão de
cronogramas de entrega, os
membros da
equipe podem não ter tempo
para fazer as simplificações
desejáveis....” “Caos” “Loteria ”
Nível de Simplicidade
Resistência cultural à Mudança

Muitas organizações,
principalmente as grandes
Liderança
empresas, que passaram anos
mudando sua cultura para que os
processos fossem definidos e
seguidos. Resistem em mudar de
um modelo de trabalho em que
“Caos” “à Deriva ”
os processos são informais e
definidos pelas equipes de
desenvolvimento interagem Nível de Mudança
livremente
Processos orientados a Planos:

Projeto que exige muito detalhamento, antes de passar
para a implementação
Impossibilidade de entregas incrementais e evolutivas

Projeto que exigem equipes de desenvolvimento maiores
em diferentes locais e com múltiplas partes interessadas;
Sistemas de vida-longa podem que exigem documentação
rica para suporte à manutenção e uso ao logo do ciclo de
vida. Obs. Se não for atualizada perde a utilidade para a
manutenção do sistema a longo prazo.
Uso de ferramentas de controle num ambiente integrado
implica em necessidade de planejamento e documentação.
Uma equipe com níveis de habilidade relativamente baixos,
pode precisar planejar o uso de melhores pessoas e regras
básicas reduzindo a liberdade deixa-la criar seus meios
próprios.
Abordagens de Método Ágeis – Desenvolvimento Ágil Orientado a Planos

Em uma abordagem dirigida a planos, ocorrem
iterações no âmbito das atividades com
documentos formais, usados para estabelecer a
comunicação entre os estágios do processo.
Os requisitos evoluem e será produzida uma

especificação dos mesmos, como entrada para o
processo de projeto e implementação.
Em uma abordagem ágil, iterações ocorrem em

todas as atividades. Os requisitos e o
projeto são desenvolvidos em conjunto, e não
separadamente.
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 :
Extreme Programming (XP),

•Open UP
•Lean Development,
•Feature-Driven Development (FDD),
•Kanban,
•RUP
•Scrum
•Etc.
Processos Ágeis – Extreme Programming
Extreme Programming (XP) . O nome foi dado por Beck
(2000), pois a abordagem foi desenvolvida para
impulsionar práticas reconhecidamente boas, como o
desenvolvimento iterativo, a níveis extremos'.
Em XP, várias novas versões de um sistema podem ser
desenvolvidas, integradas e testadas em um único dia
por programadores diferentes.
Em Extreme Programming, os requisitos são expressos
como cenários (chamados de histórias do usuário), que
são implementados diretamente como uma série de
tarefas.
Os programadores trabalham em pares e desenvolvem
testes para cada tarefa antes de escreverem o código.
Quando o novo código é integrado ao sistema, todos os
testes devem ser executados com sucesso. Há um curto
intervalo entre os releases do sistema.
1. O desenvolvimento incrementai é sustentado por
meio de pequenos e frequentes releases do sistema. Os
requisitos são baseados em cenários ou em simples
histórias de clientes, usadas como base para decidir a
funcionalidade que deve ser incluída em um incremento
do sistema.
2. O envolvimento do cliente é sustentado por meio do
engajamento contínuo do cliente com a equipe de
desenvolvimento. O representante do cliente participa
do desenvolvimento e é responsável por definir os
testes de aceitação para o sistema.
3. Pessoas — não processos — são sustentadas por meio
de programação em pares, propriedade coletiva do
código do sistema e um processo de desenvolvimento
sustentável que não envolve horas de trabalho
excessivamente longas.
4. As mudanças são aceitas por meio de

releases contínuos para os clientes, do
desenvolvimento test-fírst, da refatoração
para evitar a degeneração do código e
integração contínua de nova funcionalidade.
5. A manutenção da simplicidade é feita por

meio da refatoração constante que melhora a
qualidade do código, bem como por meio de
projetos simples que não antecipam
desnecessariamente futuras mudanças no
sistema.
Processos Ágeis – SCRUM

A abordagem Scrum (SCHWABER, 2004; SCHWABER e BEEDLE,
2001) é um método ágil geral, mas seu foco está no
gerenciamento do desenvolvimento iterativo, ao invés das
abordagens técnicas específicas da engenharia de software ágil.
No Scrum, existem três fases.

1 - Planejamento geral, em que se estabelecem os
objetivos gerais do projeto e da arquitetura do
software.
2 – Ciclos de Sprint, sendo que cada ciclo desenvolve
um incremento do sistema.
3 – A última fase do projeto encerra o projeto, completa
a documentação exigida, como quadros de ajuda do
sistema e manuais do usuário, e avalia as lições
aprendidas com o projeto.
XP Extreme Programming
As boas Práticas de XP incluem:
•The Customer is Always Available (O cliente sempre
disponível).
Metodologia baseada em
comportamentos e atitudes com foco •Metaphor (Uso de metáforas no projeto),
em agilidade de equipes e qualidade •Planning Game (mento do jogo) ,
de projetos, apoiada em valores como •Small Releases (Pequenas versões)
simplicidade, comunicação, feedback •Acceptance Tests (Testes de Aceitação)
e coragem que nos submetem ao •Test First Design (Primeiro os testes)
reconhecimento. •Continuous Integration (Integração Contínua)
•Simple Design (Simplicidade de Projeto)
Propicia que o projeto seja executado •Refactoring (Refatoração - melhoria constante do
dentro do prazo e do orçamento, código)
fazendo então com que o cliente fique •Pair Programming (Programação em dupla)
satisfeito e a equipe de •Move People Around (Rodízio de pessoas)
desenvolvimento não estresse com o •Collective Code Ownership (Propriedade coletiva - O
projeto. código é de todos da equipe)
•Coding Standards (Padronização do código)
•40 Hour Week (Otimizando as jornadas de trabalho)
•Etc.
Open UP As boas Práticas de Open Up

Processo Unificado Aberto (Open Unified Process). Originalmente chamado de
incluem:
BUP (Basic Unified Process) pela IBM que em 2005 foi liberado para a •O OpenUP é regido por quatro
Fundação Eclipse e renomeado para OpenUP em 2006. princípios:
•Equilibrar as prioridades
Aplica uma abordagem iterativa e incremental em um ciclo de vida estruturado, concorrentes para
focando na natureza colaborativa do processo de desenvolvimento de •maximizar o benefício aos
software, a partir de um conjunto compacto de atores, tarefas e artefatos em Stakeholders.
relação ao RUP.
O OpenUP pode ser definido como: •Colaborar para alinhar os interesses

e compartilhar o Entendimento.
◦ Compacto – Utiliza apenas conteúdos fundamentais e definidos.
•Focar na arquitetura, o mais cedo
◦ Completo – Abrange todas as fases do ciclo de vida do desenvolvimento de possível, para reduzir o risco e
um software.
organizar o desenvolvimento Evoluir
para continuamente obter feedback e
◦ Extensível – Pode-se utilizá-lo da forma que foi definido mas também é
possível adicionar novos conteúdos para atender novas características do
projeto. •Promover melhorias.
Lean Development
Lean é uma metodologia originalmente desenvolvida pela Toyota As boas Práticas de LD incluem:
para guiar processos industriais de linha de montagem, atuando
fortemente na eliminação de desperdícios, aumento da •Elimine Desperdícios
velocidade de processos e excelência em qualidade. Lean
•2. Inclua a Qualidade no Processo
Software Development trás os conceitos de Lean para o universo
do desenvolvimento de software, para que através da aplicação •3. Crie Conhecimento
dos mesmos princípios seja possível eliminar desperdícios e •4. Não postergue tomada de
alcançar melhores resultados. decisão e comprometimentos
•5. Entregue-se o quanto antes
A aplicação de Lean Software Development pode ajudar equipes
•6. Respeite as Pessoas e “dê
de desenvolvimento de software a atingirem maior nível de
maturidade em termos de qualidade e velocidade, entendendo e autonomia à equipe
estudando seu processo atual, e trabalhando constantemente na •7. Otimize o Todo
identificação e eliminação de desperdícios. O pensamento Lean
vai além, e oferece também ferramentas para que a equipe crie
um ambiente de trabalho mais produtivo, onde as pessoas se
respeitem e vejam a melhoria contínua como parte fundamental
de seu processo.
Feature Driven Development As boas Práticas de FDD incluem:
O Desenvolvimento orientado por Funcionalidades • Modelagem Orientada a Objetos do

(do inglês, Feature Driven Development, ou FDD). Domínio.
•- Desenvolvimento por funcionalidade.
O FDD não é uma metodologia de gerenciamento de •- Classe proprietária, ou seja, não temos
projetos de software. Tem como principal foco propriedade coletiva do código. Cada classe
cobrir os processos da engenharia de software, e tem seu dono.
não do gerenciamento. •- Equipes de recursos: destinadas a
desenvolver recursos necessários ao
Está mais próximo do XP do que do Scrum. projeto, de forma secundária.
•- Inspeção é realizada constantemente para
O FDD é muitas vezes utilizado em conjunto com o garantir a boa qualidade do código e do
Scrum para o desenvolvimento de software. projeto.
Enquanto o primeiro fornece um processo de •- Gerenciamento de configuração.
trabalho para o Scrum Team, o Scrum se concentra •- Integração contínua.
no gerenciamento do projeto como um todo. •- Visibilidade de progressos e resultados.
Kanban As boas Práticas de Kanban incluem:
• Utilização de quadros físicos com cartões como ferramentas para tornar o processo visual
e transparente, embora nem todo quadro físico com cartões utilizado em métodos ágeis
pode ser chamado de um sistema Kanban.
•Muitas vezes estes quadros podem ser apenas controles visuais que permitem ao time
acompanhar a evolução de seu trabalho.
•Se não houver limite de trabalho em progresso e sinal para puxar mais trabalho, não é um
sistema Kanban.
•entregue.
•O Kanban pode ser utilizado em equipes de desenvolvimento de novos produtos, equipes

de suporte, equipes de manutenção e melhoria de produtos, entre outros.
•Além disso, é aplicável a equipes de variados tamanhos, muito embora, seja recomendável
formar equipes menores, devido à eficiência da comunicação e diversos outros benefícios
destacados pelos métodos ágeis, como Extreme Programming e Scrum.
RUP
O IBM Rational Unified Process (RUP) é um framework de processo
de engenharia de software que fornece um conjunto de práticas
testadas na indústria para desenvolvimento de software e gerência de
projetos (Shuja, 2007).
Trata-se de um processo proprietário, desenvolvido pela Rational

Software, atualmente subsidiária da IBM, que usa abordagem
orientada a objetos e preconiza a utililização da notação UML (Unified
Modeling Language) para documentação.
É organizado em disciplinas (workflows) onde são distribuídas tarefas

e responsabilidades e gerados produtos de trabalho (artefatos). O
ciclo de vida é dividido em fases seqüenciais, as quais podem ser
subdivididas em iterações.
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 RUP
desenvolvimento.
O ciclo de vida de software do RUP é dividido em

quatro fases seqüenciais, cada uma concluída por um
marco principal, ou seja, cada fase é basicamente um
intervalo de tempo entre dois marcos principais.
Cada fase pode ser dividida em um número planejado

de iterações. Além de ser um processo, o RUP é
tratado como um produto, associado ao Rational
Method Composer (RMC), o qual é desenvolvido e
mantido pela IBM Rational. Assim como qualquer outra
ferramenta de software, o RUP está em constante
evolução.
RUP
Fases da RUP
Fluxos de Processo Críticos
Inicialização Elaboração Construção 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ício Elab. 1..2..n Implant. 1..2..n
Interações
• Adaptar o processo (identificar quanto do processo é

necessário ao projeto) ;
RUP - Melhores Práticas
• 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).
Scrum Metodologia ágil para gestão e

planejamento de projetos de Scrum é uma
metodologia ágil para gestão e
planejamento de projetos de software.
No Scrum, os projetos são devidos em

ciclos (tipicamente mensais) chamados de
Sprints. O Sprint representa um Time Box
dentro do qual um conjunto de atividades
deve ser executado.
Metodologias ágeis de desenvolvimento de

software são iterativas, ou seja, o trabalho é
dividido em iterações, que são chamadas de
Sprints no caso do Scrum.
As principais características desse processo são:
1. Sprints são de comprimento fixo, normalmente
duas a quatro semanas. Eles correspondem ao
desenvolvimento
de um release do sistema em XP
2. O ponto de partida para o planejamento é o
backlog do produto, que é a lista do trabalho a ser
feito no
projeto.
3 - Durante a fase de avaliação do sprint, este é
revisto, e as prioridades e os riscos são identificados.
4 – O cliente está intimamente envolvido nesse
processo e, no início de cada Sprint, pode introduzir
novos requisitos
ou tarefas.
5. A fase de seleção envolve todos da equipe do

projeto que trabalham com o cliente para
selecionar os recursos
e a funcionalidade a ser desenvolvida durante o
Sprint.
6. Uma vez que todos estejam de acordo, a

equipe se organiza para desenvolver o software.
Reuniões diárias rápidas, envolvendo todos os
membros da equipe, são realizadas para analisar
os progressos e, se necessário, repriorizar o
trabalho.
Scrum - Melhores Práticas
As funcionalidades a serem implementadas

em um projeto são mantidas em uma lista
que é conhecida como Product Backlog.
No início de cada Sprint, faz-se um Sprint
Planning Meeting, ou seja, uma reunião de
planejamento na qual o Product Owner
prioriza os itens do Product Backlog e a
equipe seleciona as atividades que ela será
capaz de implementar durante o Sprint que
se inicia.
As tarefas alocadas em um Sprint são
transferidas do Product Backlog para o
Sprint Backlog.
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,
P.O
identificar impedimentos e priorizar o
trabalho do dia que se inicia.
Ao final de um Sprint, a
equipe apresenta as
A cada dia de uma Sprint, a equipe faz funcionalidades
uma breve reunião (normalmente de implementadas em uma
manhã), chamada Daily Scrum. O sessão de “Sprint Review
objetivo é disseminar conhecimento Meeting”.
sobre o que foi feito no dia anterior, Faz-se uma Sprint
identificar impedimentos e priorizar o retrospectiva e a equipe
trabalho do dia que se inicia. parte para o planejamento
do próximo Sprint. Assim
reinicia-se o ciclo.
Conclusões:
E quanto as Metodologias tradicionais? É a Morte !!!!!

Nã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
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.
Conclusões:
Estudo de Caso

3 - Processos Descritivos de Engenharia de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

3 - Processos Descritivos de Engenharia de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Teoria de Engenharia de Software

Processos Descritivos de Ciclo de Vida de Software – Desenvolvimento Ágil

• Processos e Ferramentas • Indivíduos e Interações

Inicialmente, as metodologias ágeis eram denominadas como

O manifesto propõe uma

Divide o problema em produtos menores e

Modelos de Processos Ágeis

Orienta-se na satisfação final dos clientes por

Princípios da Abordagem de Métodos Ágeis -

“O Cliente deve estar envolvido,

Princípios da Abordagem de Métodos Ágeis -

“O Software é desenvolvido, priorizando

Princípios da Abordagem de Métodos Ágeis -

“As habilidades e competências da equipe de

Princípios da Abordagem de Métodos Ágeis -

“Deve –se ter em perspectiva que os requisitos

Princípios da Abordagem de Métodos Ágeis -

Lidar com Mudanças

Princípios da Abordagem de Métodos Ágeis - !

Valorizar e manter a Simplicidade

“A simplicidade deve ser a razão do

Os Conceitos chave do Manifesto Ágil

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

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

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

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

Algumas dificuldades para atender os Princípios de Métodos Ágeis

Algumas dificuldades para atender os Princípios de Métodos Ágeis

Clima ruim entre membros da Equipe

Cooperação Mútua da Equipe

Algumas dificuldades para atender os Princípios de Métodos Ágeis

Conciliar muitas partes interessadas

Algumas dificuldades para atender os Princípios de Métodos Ágeis

Algumas dificuldades para atender os Princípios de Métodos Ágeis

Resistência cultural à Mudança

Processos orientados a Planos:

Impossibilidade de entregas incrementais e evolutivas

Abordagens de Método Ágeis – Desenvolvimento Ágil Orientado a Planos

Os requisitos evoluem e será produzida uma

Em uma abordagem ágil, iterações ocorrem em

Extreme Programming (XP),

Processos Ágeis – Extreme Programming

4. As mudanças são aceitas por meio de

5. A manutenção da simplicidade é feita por

Processos Ágeis – SCRUM

No Scrum, existem três fases.

Open UP As boas Práticas de Open Up

O OpenUP pode ser definido como: •Colaborar para alinhar os interesses

Feature Driven Development As boas Práticas de FDD incluem:

O Desenvolvimento orientado por Funcionalidades • Modelagem Orientada a Objetos do

Kanban As boas Práticas de Kanban incluem:

•O Kanban pode ser utilizado em equipes de desenvolvimento de novos produtos, equipes

Trata-se de um processo proprietário, desenvolvido pela Rational

É organizado em disciplinas (workflows) onde são distribuídas tarefas

O Rational Unified Process® (também chamado de

O RUP evoluiu ao longo dos anos, em conjunto com a

Embora existam livros publicados sobre essa

O RUP oferece uma abordagem baseada em disciplinas

O ciclo de vida de software do RUP é dividido em

Cada fase pode ser dividida em um número planejado

• Adaptar o processo (identificar quanto do processo é

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

• 4. Demonstrar valor iterativamente ( feedback inicial e