SlideShare uma empresa Scribd logo
1 de 32
Metodologias de Desenvolvimento
de Software Integradas
Frank Coelho
Especialista em desenvolvimento
de software.
Solução organizacional para otimização de processos
de desenvolvimento de software,
visando o desenvolvimento com qualidade
com foco na entrega.
Tecnologias
• Linux
• Apache
• MySQL
• PHP
• C#
• VB.NET
• SharePoint
• Project
Server
• Exchange
Server
• Windows
Server
• JBossApp
Server
• Oracle
Weblogic
• Hibernate
• Spring
Framework
• Struts
Framework
• Oracle
• PostgreSQL
• IBM DB2
• MySQL
Java DatabaseMicrosoft .
NET
LAMP
Tópicos abordados
* Problemas comuns em projetos de desenvolvimento de
software.
* O que é uma metodologia?
* Metodologias para desenvolvimento de software.
Problemas comuns em projetos de
desenvolvimento de software.
Falhas de Comunicação
Estatísticas
Motivos
• Consomem mais recursos que o orçado;
• Consomem mais tempo que o estimado;
• Não entregam o que foi combinado;
(+) 500 mil projetos (pequeno -
grande porte) de software nos Brasil.
Para resolver esses problemas, seguimos uma
metodologia.
O que é uma Metodologia?
Padrões
Comunicação
Objetivo comum
Aproveitamento recursos
Metodologia
Equipe
Metodologias para Desenvolvimento
de Software
• Metodologia tradicional: PDI-SW (Processo de
Desenvolvimento Iterativo de Software)
• Metodologia ágil: SCRUM
SCRUM
• Metodologia de desenvolvimento ágil nascida em empresas de
fabricação de carros em 1986 (Takeuchi e Nonaka).
• Jeff Sutherland, John Scumniotales, e Jeff McKenna –
documentaram e implementaram - Easel Corporation em 1993.
• Tipo de formação do Rugby.
• Passou a ser utilizado no mundo a partir de 1995.
• Aborda uma filosofia de gerenciamento com foco no resultado.
Sprint
•Cada sprint é uma iteração que segue um ciclo e entrega incremento
de software pronto.
•Um backlog é conjunto de requisitos, priorizado pelo Product Owner
(responsável pelo ROI “retorno sobre investimento” e por conhecer as
necessidades do cliente);
•Há entrega de conjunto fixo de itens do backlog em série de interações
curtas ou sprints;
•Breve reunião diária, ou daily scrum, em que cada participante fala
sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o
impede de seguir avançando (também chamado de Standup Meeting ou
Daily Meeting, já que os membros da equipe geralmente ficam em pé
para não prolongar a reunião).
•Breve sessão de planejamento, na qual os itens do backlog para uma
sprint (iteração) são definidos;
•Retrospectiva, na qual todos os membros da equipe refletem sobre a
sprint passada.
BACKLOG
Planejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e
a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner
mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser
repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do
produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A
Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser
implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam
o backlog do sprint.
Product Backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product
Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente.
O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão
deste.
Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas
que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint
Backlog é uma representação em tempo real do trabalho que o Development Team planeja
concluir na sprint corrente, e ele pertence unicamente ao Development Team.
Burndown Chart
O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não
ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo
Y os dias que representam o tamanho do Sprint.
Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do
Scrum - são os que produzem o produto (objetivo do projeto).
Product Owner (dono do produto)
O Product Owner representa a voz do cliente e é responsável por garantir que a equipe
agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias
tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum
devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de
desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.
Equipe (Development Team)
A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9
pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar,
desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe
seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma
de projeto ou gestão de equipe.
Scrum Master
Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à
capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o
líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração.
O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum
Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do
Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também
tem sido referido como um líder-servo para reforçar essa dupla perspectiva.
Papéis principais
Obrigado!
Proposta.
• Usar os pilares fundamentais do RUP e seus conceitos e
métodos, unificado com as melhores praticas do CMMI.
Definição de processo organizacional sobre a gestão do
SCRUM.
• Utilizar aspectos básicos definindo um mínimo de
documentação inicial tanto quanto necessário.
• Foco na entrega com garantia de qualidade.
• Reuso de artefatos e funcionalidades (Frameworks)
• Formar muito mais que um time, um grupo de pessoas
com os mesmos objetivos e que acreditem no negocio.
Pilares do RUP
Gráfico de esforço nas fases
Concepção Esta fase do RUP abrange as tarefas de comunicação
com o cliente e planejamento. É feito um plano de projeto avaliando os
possíveis riscos, as estimativas de custo e prazos, estabelecendo as
prioridades, levantamento dos requisitos do sistema e preliminarmente
analisá-lo. Assim, haverá uma anuência das partes interessadas na
definição do escopo do projeto, onde são examinados os objetivos
para se decidir sobre a continuidade do desenvolvimento.
Elaboração Abrange a Modelagem do modelo genérico do processo.
O objetivo desta fase é analisar de forma mais detalhada a análise do
domínio do problema, revisando os riscos que o projeto pode sofrer e a
arquitetura do projeto começa a ter sua forma básica. Indagações
como “O plano do projeto é confiável?”, “Os custos são admissíveis?”
são esclarecidas nesta etapa.
Fase de Construção: Desenvolve ou Adquire os componentes de
Software. O principal objetivo desta fase é a construção do sistema de
software, com foco no desenvolvimento de componentes e outros
recursos do sistema. É na fase de Construção que a maior parte de
codificação ocorre.
Fase de Transição: Abrange a entrega do software ao usuário e a fase
de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o
disponível e compreendido pelo usuário final. As atividades desta fase
incluem o treinamento dos usuários finais e também a realização de
testes da versão beta do sistema visando garantir que o mesmo possua
o nível adequado de qualidade.
Fase de Concepção
• Finalidade
– Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos
• Atividades
– Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das
principais etapas
– Delimitar o escopo do projeto
– Identificar os atores que interagem com o sistema
– Identificar as interações dos atores com o sistema (casos de uso)
• Resultados (artefatos)
– Documento de visão: visão geral dos requisitos, características e restrições essenciais do
projeto.
– Modelo inicial de casos de uso (10%-20%).
– Glossário do projeto (opcionalmente um modelo de domínio).
– Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico
financeiro.
– Avaliação inicial de riscos.
– Plano de projeto, com fases e interações.
– Modelo de negócios, se necessário.
– Um ou vários protótipos.
• Critérios de Satisfação
– Concordância quanto à definição de escopo e estimativas de custo e cronograma.
– Compreensão dos requisitos funcionais.
– Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de
desenvolvimento.
– Profundidade e amplitude dos protótipos desenvolvidos.
– Custos planejados versus realizados.
Fase de Elaboração
• Finalidade
– eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente
e consistente da solução
• Atividades
– Construir protótipos executáveis, em uma ou mais interações
– Atacar os casos de uso críticos, que expõe os maiores riscos técnicos
– Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios,
demonstrar para investidores, clientes e usuários
• Resultados (artefatos)
– Modelo de casos de uso (80% ou mais).
– Requisitos não funcionais
– Descrição da arquitetura do software
– Protótipos arquiteturais executáveis
– Revisão da visão de negócios e lista de riscos
– Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação
– Plano de processo de desenvolvimento
– Manual de usuário preliminar
• Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto)
– A visão do produto é estável?
– A arquitetura é estável?
– A demonstração executável mostrou que os elementos de maior risco foram abordados
satisfatoriamente?
– O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e
coerente?
– Todos os interessados concordam quando à coerência entre visão, plano e arquitetura?
– Os custos planejados e executados estão aceitáveis?
Fase de Construção
• Finalidade
– Desenvolver todos os componentes e características não resolvidas nas fases
anteriores, testando-as e integrando-as na forma de um produto.
• Atividades
– Diversas
• Resultados (artefatos)
– O produto, descrito e integrado nas plataformas adequadas
• Critérios de Satisfação
– A release do produto é suficientemente estável e amadurecida para ser entregue ao
usuário?
– Todos os envolvidos e interessados estão preparados para a fase de transição?
– O consumo de recursos é ainda aceitável?
Fase de Transição
• Finalidade
– Realizar a transição do produto para a comunidade de usuários
• Atividades
– “beta teste”
– Operações paralelas com sistema legado
– Conversão de bases de dados
– Treinamento de usuários a mantenedores
– Roll-out para setores de marketing, distribuição e vendas
• Resultados (artefatos)
– Em conformidade com atividades
• Critérios de Satisfação
– O usuário ainda está satisfeito?
– Os custos de manutenção ainda são aceitáveis?
Ferramentas de gerenciamento do ciclo de
vida e produção
• Visual Studio
• Arquitetura
• Dados
• Testes
• TFS
• Versionamento
• Tarefas
• Sprints
• Backlogs
• Project
• Cronograma
• Tarefas
• Custos
• Studio manager SQL
• Modelo de dados
Perfil do time técnico
• Gerente de Projetos
• Arquiteto de Software
• Analista de requisitos
• Analista de sistema
• Desenvolvedores
• Analista de Testes
• Documentador
Fluxo de trabalho
Descrição para as fases
CMMI
• CMMI é uma família de conjuntos de melhores práticas para apoiar a
melhoria de desenvolvimento, serviços e aquisição.
• Implementar um modelo baseado nas melhores praticas, levando em
conta o cenário especifico e atual da empresa, voltado para melhoria
continua e crescimento do grau de maturidade do ciclo de vida da
construção de software.
• Processo continuo visando o alcance dos resultados esperados.
• Trabalhar nos detalhes no intuito de evitar esforço desnecessário.
• União das dimensões de construção do CMMI:
• Pessoas
• Ferramentas
• Procedimentos
O que esperar.
• Não existe retorno a curto prazo.
• Certificação CMMI
• Certificação ISO
• Controle absoluto de projetos e custos
• Baixo Custo de manutenção
• Produtos robustos e escaláveis
• Melhoria estratégica de posição no mercado
• Gerencia de configuração consolidada
• Lucros maiores
• Ser um caso de sucesso
• Atingir a EXCELENCIA
Fazer a coisa certa é uma escolha que deve ser mantida, que exige
esforço e comprometimento e o retorno só é visto depois.
Obstáculos são apenas grandes oportunidades de sermos melhores...
Homens comuns contam histórias, homens extraordinários fazem a
história...
Referências
• http://www.infoq.com/presentations/The-Roots-of-Scrum
• http://pt.wikipedia.org/wiki/Scrum
• http://www.agilealliance.org/system/article/file/888/file.pdf
• http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase
_de_Concep.C3.A7.C3.A3o
• http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI-
DEV

Mais conteúdo relacionado

Mais procurados

Como para Mapear Processos (Sistema de Gestão Integrada)
Como para Mapear Processos (Sistema de Gestão Integrada)Como para Mapear Processos (Sistema de Gestão Integrada)
Como para Mapear Processos (Sistema de Gestão Integrada)Rogério Souza
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de softwareAlex Camargo
 
Design Thinking - Metodologia para Inovação
Design Thinking - Metodologia para InovaçãoDesign Thinking - Metodologia para Inovação
Design Thinking - Metodologia para InovaçãoPaulo Oliveira
 
Gestão ágil de projetos com Scrum
Gestão ágil de projetos com ScrumGestão ágil de projetos com Scrum
Gestão ágil de projetos com ScrumBlog Eu na TI
 
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.Jeanne Louize Emygdio
 
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...HELENO FAVACHO
 
Apresentação sobre Gestão da Inovação e da Criatividade
Apresentação sobre Gestão da Inovação e da CriatividadeApresentação sobre Gestão da Inovação e da Criatividade
Apresentação sobre Gestão da Inovação e da CriatividadeLevi Tancredo
 
PPT - Ação corretiva e não conformidade.pptx
PPT - Ação corretiva e não conformidade.pptxPPT - Ação corretiva e não conformidade.pptx
PPT - Ação corretiva e não conformidade.pptxYthia Karla
 
Manual de Gestão de Riscos
Manual de Gestão de RiscosManual de Gestão de Riscos
Manual de Gestão de Riscosfabiocdaraujo
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Elmano Cavalcanti
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de RequisitosPaulo Furtado
 

Mais procurados (20)

Como para Mapear Processos (Sistema de Gestão Integrada)
Como para Mapear Processos (Sistema de Gestão Integrada)Como para Mapear Processos (Sistema de Gestão Integrada)
Como para Mapear Processos (Sistema de Gestão Integrada)
 
Dor e DoD
Dor e DoDDor e DoD
Dor e DoD
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
Design Thinking - Metodologia para Inovação
Design Thinking - Metodologia para InovaçãoDesign Thinking - Metodologia para Inovação
Design Thinking - Metodologia para Inovação
 
Gestão ágil de projetos com Scrum
Gestão ágil de projetos com ScrumGestão ágil de projetos com Scrum
Gestão ágil de projetos com Scrum
 
KPI\'s
KPI\'sKPI\'s
KPI\'s
 
Design thinking
Design thinkingDesign thinking
Design thinking
 
Gerenciamento das Comunicações do Projeto
Gerenciamento das Comunicações do ProjetoGerenciamento das Comunicações do Projeto
Gerenciamento das Comunicações do Projeto
 
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.
Apresentação do TCC de Produção de Software Livre realizada na UFLA em 2007.
 
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...
Estratégia e intervenção em marketing digital o caso empresarial doce sabor p...
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
Apresentação sobre Gestão da Inovação e da Criatividade
Apresentação sobre Gestão da Inovação e da CriatividadeApresentação sobre Gestão da Inovação e da Criatividade
Apresentação sobre Gestão da Inovação e da Criatividade
 
Metodologia SCRUM
Metodologia SCRUMMetodologia SCRUM
Metodologia SCRUM
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
PPT - Ação corretiva e não conformidade.pptx
PPT - Ação corretiva e não conformidade.pptxPPT - Ação corretiva e não conformidade.pptx
PPT - Ação corretiva e não conformidade.pptx
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Manual de Gestão de Riscos
Manual de Gestão de RiscosManual de Gestão de Riscos
Manual de Gestão de Riscos
 
Balanced Scorecard
Balanced ScorecardBalanced Scorecard
Balanced Scorecard
 
Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)Teste de software - aula 01 (motivação)
Teste de software - aula 01 (motivação)
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
 

Destaque

3.1 orientação objetos
3.1  orientação objetos3.1  orientação objetos
3.1 orientação objetosFrank Coelho
 
Bail bond company santee, ca
Bail bond company santee, caBail bond company santee, ca
Bail bond company santee, caaffordably123
 
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...Dan Griggs
 
Film distributor
Film distributorFilm distributor
Film distributorpaddymooney
 
Teoría e ingeniería de la vida pública
Teoría e ingeniería de la vida públicaTeoría e ingeniería de la vida pública
Teoría e ingeniería de la vida públicaJesús Hernández
 
Resume1.docx (1)
Resume1.docx (1)Resume1.docx (1)
Resume1.docx (1)Ti'Fani Law
 
6 things the founding fathers knew about pr and marketing (and you should too)
6 things the founding fathers knew about pr and marketing (and you should too)6 things the founding fathers knew about pr and marketing (and you should too)
6 things the founding fathers knew about pr and marketing (and you should too)Dan Griggs
 
Abdominal MINICOURSE 11_XZZ
Abdominal MINICOURSE 11_XZZAbdominal MINICOURSE 11_XZZ
Abdominal MINICOURSE 11_XZZAnna McCormick
 
Ladies Knits Collection
Ladies Knits CollectionLadies Knits Collection
Ladies Knits CollectionNadeem Ali
 
German Telecoms Market Q1/2016
German Telecoms Market Q1/2016German Telecoms Market Q1/2016
German Telecoms Market Q1/2016DSP-Partners
 

Destaque (13)

3.1 orientação objetos
3.1  orientação objetos3.1  orientação objetos
3.1 orientação objetos
 
Bail bond company santee, ca
Bail bond company santee, caBail bond company santee, ca
Bail bond company santee, ca
 
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...
6 Things the Founding Fathers Knew About PR and Marketing (and you should kno...
 
Film distributor
Film distributorFilm distributor
Film distributor
 
Tarea 2
Tarea 2Tarea 2
Tarea 2
 
Teoría e ingeniería de la vida pública
Teoría e ingeniería de la vida públicaTeoría e ingeniería de la vida pública
Teoría e ingeniería de la vida pública
 
Resume1.docx (1)
Resume1.docx (1)Resume1.docx (1)
Resume1.docx (1)
 
6 things the founding fathers knew about pr and marketing (and you should too)
6 things the founding fathers knew about pr and marketing (and you should too)6 things the founding fathers knew about pr and marketing (and you should too)
6 things the founding fathers knew about pr and marketing (and you should too)
 
Abdominal MINICOURSE 11_XZZ
Abdominal MINICOURSE 11_XZZAbdominal MINICOURSE 11_XZZ
Abdominal MINICOURSE 11_XZZ
 
CJB_Resume2016r1
CJB_Resume2016r1CJB_Resume2016r1
CJB_Resume2016r1
 
Ladies Knits Collection
Ladies Knits CollectionLadies Knits Collection
Ladies Knits Collection
 
German Telecoms Market Q1/2016
German Telecoms Market Q1/2016German Telecoms Market Q1/2016
German Telecoms Market Q1/2016
 
GIÁO ÁN TIN HỌC 10- BÀI 19
GIÁO ÁN TIN HỌC 10- BÀI 19GIÁO ÁN TIN HỌC 10- BÀI 19
GIÁO ÁN TIN HỌC 10- BÀI 19
 

Semelhante a 1- Apresentacao Metodologia RCP

Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixCris Fidelix
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMLucas Vinícius
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilIsrael Santiago
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumThiago Barros, PSM
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de bananaejedelmal
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisDaniela Brauner
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To ScrumJuan Bernabó
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slideshoraciosila
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010Facuuldade Norte Sul
 

Semelhante a 1- Apresentacao Metodologia RCP (20)

Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Método Ágil Scrum
Método Ágil ScrumMétodo Ágil Scrum
Método Ágil Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Scrum
ScrumScrum
Scrum
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento Ágil
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de banana
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias Ágeis
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
Lista de Práticas Ágeis
Lista de Práticas ÁgeisLista de Práticas Ágeis
Lista de Práticas Ágeis
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Visao geraldorup 20slides
Visao geraldorup 20slidesVisao geraldorup 20slides
Visao geraldorup 20slides
 
Artigo23
Artigo23Artigo23
Artigo23
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
C:\Documents And Settings\Juliana\Desktop\Palestra 19 03 2010
 

1- Apresentacao Metodologia RCP

  • 1. Metodologias de Desenvolvimento de Software Integradas Frank Coelho Especialista em desenvolvimento de software. Solução organizacional para otimização de processos de desenvolvimento de software, visando o desenvolvimento com qualidade com foco na entrega.
  • 2.
  • 3. Tecnologias • Linux • Apache • MySQL • PHP • C# • VB.NET • SharePoint • Project Server • Exchange Server • Windows Server • JBossApp Server • Oracle Weblogic • Hibernate • Spring Framework • Struts Framework • Oracle • PostgreSQL • IBM DB2 • MySQL Java DatabaseMicrosoft . NET LAMP
  • 4. Tópicos abordados * Problemas comuns em projetos de desenvolvimento de software. * O que é uma metodologia? * Metodologias para desenvolvimento de software.
  • 5. Problemas comuns em projetos de desenvolvimento de software.
  • 7. Estatísticas Motivos • Consomem mais recursos que o orçado; • Consomem mais tempo que o estimado; • Não entregam o que foi combinado; (+) 500 mil projetos (pequeno - grande porte) de software nos Brasil.
  • 8. Para resolver esses problemas, seguimos uma metodologia.
  • 9. O que é uma Metodologia? Padrões Comunicação Objetivo comum Aproveitamento recursos Metodologia Equipe
  • 10. Metodologias para Desenvolvimento de Software • Metodologia tradicional: PDI-SW (Processo de Desenvolvimento Iterativo de Software) • Metodologia ágil: SCRUM
  • 11. SCRUM • Metodologia de desenvolvimento ágil nascida em empresas de fabricação de carros em 1986 (Takeuchi e Nonaka). • Jeff Sutherland, John Scumniotales, e Jeff McKenna – documentaram e implementaram - Easel Corporation em 1993. • Tipo de formação do Rugby. • Passou a ser utilizado no mundo a partir de 1995. • Aborda uma filosofia de gerenciamento com foco no resultado.
  • 12.
  • 13. Sprint •Cada sprint é uma iteração que segue um ciclo e entrega incremento de software pronto. •Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI “retorno sobre investimento” e por conhecer as necessidades do cliente); •Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints; •Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente ficam em pé para não prolongar a reunião). •Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos; •Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.
  • 14. BACKLOG Planejamento de sprint (Sprint Planning): Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint. Product Backlog Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste. Sprint Backlog O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar tais itens selecionados. O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeja concluir na sprint corrente, e ele pertence unicamente ao Development Team. Burndown Chart O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.
  • 15. Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum - são os que produzem o produto (objetivo do projeto). Product Owner (dono do produto) O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster. Equipe (Development Team) A equipe é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe. Scrum Master Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva. Papéis principais
  • 16. Obrigado! Proposta. • Usar os pilares fundamentais do RUP e seus conceitos e métodos, unificado com as melhores praticas do CMMI. Definição de processo organizacional sobre a gestão do SCRUM. • Utilizar aspectos básicos definindo um mínimo de documentação inicial tanto quanto necessário. • Foco na entrega com garantia de qualidade. • Reuso de artefatos e funcionalidades (Frameworks) • Formar muito mais que um time, um grupo de pessoas com os mesmos objetivos e que acreditem no negocio.
  • 18. Gráfico de esforço nas fases
  • 19. Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento. Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa. Fase de Construção: Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.
  • 20. Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.
  • 21. Fase de Concepção • Finalidade – Definir objetivos e viabilidade do projeto (o ideia do projeto) e o escopo de vários aspectos • Atividades – Definir: critérios de sucesso de projeto, riscos, recursos necessários e data de realização das principais etapas – Delimitar o escopo do projeto – Identificar os atores que interagem com o sistema – Identificar as interações dos atores com o sistema (casos de uso) • Resultados (artefatos) – Documento de visão: visão geral dos requisitos, características e restrições essenciais do projeto. – Modelo inicial de casos de uso (10%-20%). – Glossário do projeto (opcionalmente um modelo de domínio). – Definição de objetivos e viabilidade do projeto incluído contexto, critérios de sucesso e prognóstico financeiro. – Avaliação inicial de riscos. – Plano de projeto, com fases e interações. – Modelo de negócios, se necessário. – Um ou vários protótipos. • Critérios de Satisfação – Concordância quanto à definição de escopo e estimativas de custo e cronograma. – Compreensão dos requisitos funcionais. – Credibilidade das estimativas de custo, cronograma, prioridades, riscos, e processo de desenvolvimento. – Profundidade e amplitude dos protótipos desenvolvidos. – Custos planejados versus realizados.
  • 22. Fase de Elaboração • Finalidade – eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução • Atividades – Construir protótipos executáveis, em uma ou mais interações – Atacar os casos de uso críticos, que expõe os maiores riscos técnicos – Construir protótipos evolucionários ou descartáveis, com objetivo de analisar custos-benefícios, demonstrar para investidores, clientes e usuários • Resultados (artefatos) – Modelo de casos de uso (80% ou mais). – Requisitos não funcionais – Descrição da arquitetura do software – Protótipos arquiteturais executáveis – Revisão da visão de negócios e lista de riscos – Plano detalhado de desenvolvimento do projeto, com interações e critérios de avaliação – Plano de processo de desenvolvimento – Manual de usuário preliminar • Critérios de Satisfação (para suporte à decisão sobre continuar ou não com o projeto) – A visão do produto é estável? – A arquitetura é estável? – A demonstração executável mostrou que os elementos de maior risco foram abordados satisfatoriamente? – O plano de desenvolvimento está suficientemente detalhado e preciso? O plano é consistente e coerente? – Todos os interessados concordam quando à coerência entre visão, plano e arquitetura? – Os custos planejados e executados estão aceitáveis?
  • 23. Fase de Construção • Finalidade – Desenvolver todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto. • Atividades – Diversas • Resultados (artefatos) – O produto, descrito e integrado nas plataformas adequadas • Critérios de Satisfação – A release do produto é suficientemente estável e amadurecida para ser entregue ao usuário? – Todos os envolvidos e interessados estão preparados para a fase de transição? – O consumo de recursos é ainda aceitável?
  • 24. Fase de Transição • Finalidade – Realizar a transição do produto para a comunidade de usuários • Atividades – “beta teste” – Operações paralelas com sistema legado – Conversão de bases de dados – Treinamento de usuários a mantenedores – Roll-out para setores de marketing, distribuição e vendas • Resultados (artefatos) – Em conformidade com atividades • Critérios de Satisfação – O usuário ainda está satisfeito? – Os custos de manutenção ainda são aceitáveis?
  • 25. Ferramentas de gerenciamento do ciclo de vida e produção • Visual Studio • Arquitetura • Dados • Testes • TFS • Versionamento • Tarefas • Sprints • Backlogs • Project • Cronograma • Tarefas • Custos • Studio manager SQL • Modelo de dados
  • 26. Perfil do time técnico • Gerente de Projetos • Arquiteto de Software • Analista de requisitos • Analista de sistema • Desenvolvedores • Analista de Testes • Documentador
  • 29. CMMI • CMMI é uma família de conjuntos de melhores práticas para apoiar a melhoria de desenvolvimento, serviços e aquisição. • Implementar um modelo baseado nas melhores praticas, levando em conta o cenário especifico e atual da empresa, voltado para melhoria continua e crescimento do grau de maturidade do ciclo de vida da construção de software. • Processo continuo visando o alcance dos resultados esperados. • Trabalhar nos detalhes no intuito de evitar esforço desnecessário. • União das dimensões de construção do CMMI: • Pessoas • Ferramentas • Procedimentos
  • 30.
  • 31. O que esperar. • Não existe retorno a curto prazo. • Certificação CMMI • Certificação ISO • Controle absoluto de projetos e custos • Baixo Custo de manutenção • Produtos robustos e escaláveis • Melhoria estratégica de posição no mercado • Gerencia de configuração consolidada • Lucros maiores • Ser um caso de sucesso • Atingir a EXCELENCIA Fazer a coisa certa é uma escolha que deve ser mantida, que exige esforço e comprometimento e o retorno só é visto depois. Obstáculos são apenas grandes oportunidades de sermos melhores... Homens comuns contam histórias, homens extraordinários fazem a história...
  • 32. Referências • http://www.infoq.com/presentations/The-Roots-of-Scrum • http://pt.wikipedia.org/wiki/Scrum • http://www.agilealliance.org/system/article/file/888/file.pdf • http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Fase _de_Concep.C3.A7.C3.A3o • http://www.cmmi.de/#el=CMMI-DEV/0/HEAD/folder/folder.CMMI- DEV