Joaquim Oliveira Grupo de Estudos em Processos 25/06/2002 Comparação entre Metodologias de Desenvolvimento.

Slides:



Advertisements
Apresentações semelhantes
Metodologia R/XP.
Advertisements

RUP – Rational Unified Process
Metodologias Ágeis Visão Geral.
Engenharia de Software
XP EXTREME PROGRAMMING
O Processo Praxis 3.0 Processos de Software 25/03/2017
Análise e Projeto de Sistemas I
Adriano Teixeira João Vide Luís Silva Maria Pedroto
Rational Unified Process(RUP)
Valéria Maria Lauande Março/2010
Desenvolvimento ágil: eXtreme Programming vs SCRUM Tiago Rodrigues de Mello CCO-230 – ENGENHARIA DE SOFTWARE / 2010.
RUP Rational Unified Process (Processo Unificado de Desenvolvimento da Rational) 1.
Modelos de processo de software:
Processo Desenvolvimento de Software Tradicional
Comparação e Avaliação de Métodos Ágeis de Software
FDD.
Análise e Gerenciamento de Requisitos com Casos de Uso
Classes e objetos Modelagem
Alunos: Artulanez Souza Iony Melo
Rational Unified Process
Métodos Ágeis Agile Modeling, ou AG
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
RUPinho Qualidade de Software
Técnicas e Projeto de Sistemas
Desafios do desenvolvimento de software
Processos Tradicionais de Desenvolvimento de Software
Visão Geral PRO.NET.
Visão Geral do RUP.
Fundamentos de Engenharia de SW
Avaliação do RUP como processo para desenvolvimento de software
Implantando SCRUM na Simplestec Equipe Tributária
Processos de Desenvolvimento de Software – Parte 2
Engenharia de Software
Raoni de Oliveira Franco
Desenvolvimento Rápido de Aplicação (RAD)
ENGENHARIA DE SOFTWARE
Fase de Concepção (Início, Planejamento)
PAS Características: Elaborado com o propósito de ser utilizado em práticas acadêmicas de desenvolvimento de software. Foi desenvolvido de forma iterativa.
PSBD II Projeto de Sistemas de Banco de Dados II
(Open Unified Process)
Bruno Silva Desenvolvido a partir de
O Processo Unificado (UP)
RUP - Cap. 5 – Processo Iterativo e Incremental
eXtreme Programming Metodologia XP
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Engenharia de Software
Processo de Desenvolvimento de Software – PDS C Construção - PAS
Processos de Software.
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Visão Geral sobre Ciclo de Vida de Software, Processos e RUP
Engenharia de Software
Gestão de projetos de Software GTI-16
SCRUM Metodologia para o Desenvolvimento Ágil de Software Rafael Rodrigues, Rafael Rost.
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TOCANTINS Campus Araguaína Técnicas e Projetos de Sistemas SUBSEQUENTE 1.
Métodos Ágeis e Programação Extrema (XP)
Engenharia de Software
Engenharia de Software
Fase de Concepção (Início, Planejamento)
Análise e Projeto de Sistemas Unified Modeling Language Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores.
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
Robson Godoi Grupo de Estudos em Processos de Desenvolvimento CIN - UFPE Outubro 2002.
Contextualizando XP para Web engineering
Estudo Comparativo Entre Metodologias Ágeis e Tradicionais Aluno: Márcia Seabra Cabral Professor: Augusto Sampaio Disciplina: Tópicos Avançados em Engenharia.
O uso de XP em uma Organização CMM 2 Renata Endriss
EXtreme Programming Eduardo Aranha.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
SCRUM Development Process Universidade Federal de Pernambuco Lenylda Albuquerque
Agile Modeling Júlio Lins – Junho / 22 Agile Alliance Em 2001, reune-se um grupo de representantes das metodologias eXtreme Programming, SCRUM,
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Joaquim Oliveira Grupo de Estudos em Processos 25/06/2002 Comparação entre Metodologias de Desenvolvimento

2 Roteiro  Metodologias Ágeis  eXtreme Programming (XP)  SCRUM  Crystal Clear  Feature Driven Development (FDD)  Agile Modeling  Dynamic System Development Method (DSDM)

3 Roteiro  Metodologias Tradicionais  RUP  OPEN  Catalisys  Comparação

4 eXtreme Programming  Proposta por Kent Beck  Baseia-se em 4 valores...  Comunicação  Feedback  Simplicidade  Coragem ...e 12 práticas  Iterativo e incremental. Iterações de 2 semanas.

5 eXtreme Programming  Prática 1: Jogo do Planejamento  Planejar rapidamente, sem muitos detalhes, o escopo do próximo release, considerando prioridades de negócios, aspectos técnicos, estimativas. Alterar o planejamento sempre que ele se mostrar inadequado  Prática 2: Releases curtos  Colocar um sistema simples em produção rapidamente. Liberar novas versões em ciclos curtos de tempo  Prática 3: Metáfora  Guiar o desenvolvimento através de uma história simples, de entendimento de todos

6 eXtreme Programming  Prática 4: Design Simples  Projetar o mais simples possível.  Prática 5: Teste  Testes unitários automáticos, produzidos durante implementação. Clientes escrevem testes para demonstrar quando os requisitos estão prontos  Prática 6: Refactoring  Reestruturar o sistema sem alterar o seu comportamento para remover duplicação, melhorar comunicação, simplificar ou adicionar funcionalidade

7 eXtreme Programming  Prática 7: Programação em Pares  Toda a produção de código é feita por pares de programadores trabalhando na mesma máquina  Prática 8: Collective Ownership  Todos podem alterar qualquer parte do código a qualquer momento  Prática 9: Integração Contínua  Integrar e construir o sistema várias vezes ao dia, sempre que uma tarefa é completada

8 eXtreme Programming  Prática 10: 40 horas por Semana  Não trabalhar mais que 40hs por semana. Nunca trabalhar horas extra em duas semanas consecutivas  Prática 11: Cliente no local  Usuário real é integrante da equipe, trabalha onde a equipe trabalha e está disponível para responder perguntas a qualquer momento  Prática 12: Padrão de Codificação  Escrever todo o código de acordo com um padrão estabelecido, visando facilitar a comunicação através do código

9 SCRUM  Metodologia em forma de pattern  Características  Iterativa e incremental, com iterações de 1 mês (sprints)  Equipes de 6 a 10 pessoas  Requisitos em constante mudança (ambiente caótico)  Envolvimento do “cliente”  Não estabelece técnicas para o desenvolvimento

10 SCRUM  Fases

11 SCRUM

12 SCRUM  Priorização dos requisitos  Importância para o negócio  Riscos para o projeto  Acompanhamento freqüente das atividades  SCRUM Master  Mediador dos encontros  Acompanhar o progresso da equipe 

13 Feature Driven Development  Proposta por Peter Coad et al.  Baseia-se no conceito de feature  “Pequenas funcionalidades que possuam valor para o usuário”  Iterativa e incremental. Iterações de 2 semanas  Equipes de 16 a 20 pessoas, divididas em sub- equipes

14  Composta de 5 atividades principais  Participação de especialistas do negócio  Esclarecem o contexto do sistema e priorizam as features  Escalável para grandes equipes  Basta ter programadores-chefe suficientes Feature Driven Development Desenvolver um modelo geral Elaborar uma lista de features Planejar por feature Projetar por feature Construir por feature

15 Crystal Clear  “Caçula” de uma família de metodologias, proposta por Alistair Cockburn  Iterativo e incremental, com iterações fixas  Equipes de 3 a 6 pessoas  Sistemas que não sejam críticos  Define papéis e artefatos  “Strong on communication, light on deliverables”

16 Crystal Clear  O cliente deve estar envolvido  Esclarece os requisitos sempre que necessário  Prioriza o que deve ser feito  A equipe participa do planejamento  Requisitos na forma de pequenas descrições  Entregas freqüentes, para se obter feedback  Não especifica técnicas  Gerenciamento dirigido a milestones e riscos  O resto é com a equipe!

17 DSDM  Criado por um consórcio, devido a necessidades da comunidade de RAD  Define O QUE e não COMO  Pode ser usado com RUP, XP, etc...  Iterativo e incremental. Iterações de 2 a 6 semanas  Recursos e tempo fixos, escopo negociável

18 DSDM

19 DSDM  Guiado por 9 princípios 1. O envolvimento ativo do usuário é essencial 2. As equipes DSDM devem estar capacitadas a tomar decisões 3. Foco na entrega freqüente de produtos 4. Adequação aos objetivos do negócio é o principal critério de aceitação 5. O desenvolvimento iterativo e incremental é necessário para uma solução de negócio precisa

20 DSDM  Guiado por 9 princípios 6. Todas as mudanças durante o desenvolvimento são reversíveis 7. Os requisitos são definidos em um alto nível de abstração 8. Testes são executados durante todo o ciclo de vida 9. Colaboração e cooperação entre os stakeholders é essencial

21 Agile Modeling  Modelar de forma simples e eficiente  Complementa outras metodologias de desenvolvimento  Um modelo ágil  É fácil de ser entendido  É simples  Possui precisão e detalhamentos necessários  Agrega valor ao projeto

22 Agile Modeling  Valores: comunicação, feedback, simplicidade, coragem e humildade  Alguns princípios  Assumir simplicidade  “Abraçar” as mudanças  Modelar com um propósito  Melhoria incremental  Obter feedback rápido  Conhecer vários modelos

23 Agile Modeling  Algumas práticas  Participação ativa do usuário  Crie modelos simples, com desenhos simples  Utilize os artefatos corretos  Modele em pequenos incrementos  Modele com outras pessoas  Use ferramentas simples  Use o código para provar que o modelo está certo

24 RUP  Framework para processos  Principais Características  Iterativo e Incremental  Guiado por casos de uso e riscos  Ênfase na arquitetura  As duas dimensões do RUP  Fases  Fluxos ou disciplinas

25 RUP

26 RUP  RUP ágil  Propostas da Rational  RUP para pequenos projetos  Abordagens ágeis para o RUP  O RUP de um homem só  dX, de Robert Martin  Instância de Craig Larman em “Applying UML and Patterns”

27 OPEN  Framework para processos  Desenvolvimento pelo OPEN Consortium  Unificação de várias metodologias: MOSES, SOMA, Firesmith, Synthesis, etc...  Componentes do OPEN Process Framework  Produtos e Produtores  Linguagens  Unidades de Trabalho  Estágios  Guias

28 OPEN

29 OPEN  Produtos: qualquer coisa de valor produzida durante o projeto  Documentação, código, diagramas, etc...  Produtores: algo que cria, mantém ou avalia um produto  Pessoas, equipes, organizações,...  Linguagens: a mídia utilizada para documentar um produto  Linguagem natural, UML, Java, SQL, IDL,...

30 OPEN  Unidades de Trabalho  Atividade  Tarefa  Técnica  Realização da Tarefa (Task performance)  Estágios  Ciclos e Fases  Build, release e deployment

31 OPEN  Ciclos e fases

32 OPEN  Builds, releases e deployments

33 Catalysis  Forte ênfase em componentes e reuso  Usa UML como linguagem de modelagem  Princípios Básicos  Abstração  Precisão  Partes Plugáveis  Minimize a mágica  Uma e somente uma vez  Conceitos de Modelagem  Tipo  Colaboração  Refinamento

34 Catalysis  Níveis de modelagem  Domínio do problema ou do negócio (outside)  Especificação do componente (boundary)  Implementação do componente (inside)  Tipos de modelos  Estáticos: modelam um estado de um objeto, descrito através de um conjunto de atributos  Dinâmicos: modelam as mudanças de estado de um objeto, descritas através de um conjunto de ações e suas pré e pós- condições  Interativos: modelam a comunicação entre objetos

35 Catalysis  Refinamento dos modelos  7 níveis de refinamento  Ênfase em riscos  Iterações curtas  feedback constante  Várias “caminhos” para seguir o processo  Patterns para vários problemas  Catalysis lite

36 Comparação

37 Comparação  Tamanho das Iterações  Envolvimento do usuário  Planejamento preditivo x adaptativo  Riscos técnicos x importância para o negócio  Diferentes níveis de abstração na definição das metodologias  Metodologias tradicionais podem ser encaradas de forma ágil!