Planejamento Iterativo



Documentos relacionados
Processo Unificado (RUP)

A Disciplina Gerência de Projetos

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Engenharia de Software I

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

Especialização em Engenharia de Software e Banco de Dados

Pós Graduação Engenharia de Software

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

O modelo unificado de processo. O Rational Unified Process, RUP.

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

Professor: Curso: Disciplina:

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

Engenharia de Software

ENG1000 Introdução à Engenharia

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

Princípios da Engenharia de Software Aula 02. Prof.: Franklin M. Correia

Gestão de Projetos. Introdução ao PMBOK. Hermano Perrelli de Moura

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

Processos de Desenvolvimento de Software

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Notas de Aula 02: Processos de Desenvolvimento de Software

Governança de TI. ITIL v.2&3. parte 1

Tópicos Especiais em Engenharia de Software

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini prof.andre.luis.belini@gmail.com /

Sistemas de Informação I

Introdução ao OpenUP (Open Unified Process)

Durante o desenvolvimento e execução de um projeto, ele passa por diversas fases, a esse conjunto de fases se denomina ciclo de vida.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira

Programa do Módulo 2. Processo Unificado: Visão Geral

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida

ATO Nº 91/2015/GP/TRT 19ª, DE 1º DE JUNHO DE 2015

Processo de Desenvolvimento Unificado

Prof. Dr. Carlos Eduardo Sanches da Silva Prof. Dr. Carlos Henrique Pereira Mello EPR 707 EPR 707 ENGENHARIA DO PRODUTO

Desafio Profissional PÓS-GRADUAÇÃO Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

NORMA ISO/IEC Isac Aguiar isacaguiar.com.br

Tecnologias Atuais de. Desenvolvimento de Software

Processos de gerenciamento de projetos em um projeto

Políticas de Qualidade em TI

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

Modelos do Design de Software

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Planejamento e Gerenciamento Iterativo de Projetos de Software

Engenharia de Negócios. Gestão de Sistemas Complexos. Planejamento Time Box

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

Gerenciamento de Riscos do Projeto Eventos Adversos

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

Jonas de Souza H2W SYSTEMS

PMONow! Serviço de Implantação de um Escritório de Projetos

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Fundamentos de Teste de Software

Gerência de Projetos

Modelos de processos de desenvolvimento de software

Engenharia de Software II

Disciplina: Administração de Departamento de TI. Professor: Aldo Rocha. Aula III - 25/08/2011

Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR

Processos de Software

Engenharia de Software Processo de Desenvolvimento de Software

CEAHS CEAHS. Grupo Disciplinas presenciais Créditos Mercado da Saúde Ética e aspectos jurídicos 1

Processos de Desenvolvimento de Software. Ricardo Argenton Ramos UNIVASF Engenharia de Software I Aula 3

Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares

RiskFree Uma ferramenta de apoio à gerência de riscos em projetos de software

ENGENHARIA DE SOFTWARE I

ADMINISTRAÇÃO DE SISTEMAS DE INFORMAÇÃO (AULA 03)

Engenharia de Software

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Universidade Paulista

Fatores Críticos de Sucesso em GP

Ciclo de Vida de um Projeto

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

Processos de Design de IHC (Parte II)

Gerenciamento de Projetos Modulo III Grupo de Processos

RUP Rational Unified Process

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Roteiro SENAC. Análise de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos

Gerenciamento de Projetos no Marketing Desenvolvimento de Novos Produtos

Universidade Federal de Goiás UFG Campus Catalão CAC Departamento de Engenharia de Produção. Sistemas ERP. PCP 3 - Professor Muris Lage Junior

GARANTIA DA QUALIDADE DE SOFTWARE

Metodologia e Gerenciamento do Projeto na Fábrica de Software

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

Qualidade de Software. Anderson Belgamo

W Projeto. Gerenciamento. Construindo a WBS e gerando o Cronograma. Autor: Antonio Augusto Camargos, PMP 1/12

MASTER IN PROJECT MANAGEMENT

Transcrição:

Planejamento Iterativo Planejando as Fases e Iterações Hermano Perrelli hermano@cin.ufpe.br 1

Revisando Processo iterativo Req A&P Imp I/T Imp Req A&P Imp I/T Imp Req A&P Imp I/T Imp Iteração 1 Iteração 2 Iteração 3 TEMPO 2

Revisando Fases e iterações Concepção Elaboração Construção Transição Estabelecer o escopo e viabilidade econômica do projeto Eliminar principais riscos e definir arquitetura estável Desenvolver o produto até que ele esteja pronto para beta testes Entrar no ambiente do usuário 3

Revisando Fases e iterações O ciclo de vida de um sistema consiste de quatro fases: Concepção Elaboração Construção Transição Marcos principais escopo arquitetura operação release tempo As fases indicam a maturidade do sistema! 4

Revisando Fases, iterações e fluxos de atividades Fluxos Principais Fases Concepção Elaboração Construção Transição Modelagem de Negócio... Requisitos... Análise e Projeto... Implementação... Testes... Implantação... Fluxos de Apoio Gerência de Configuração... Planejamento e Gerenciamento... Inicial Iterações 5

Objetivos desta aula Apresentar padrões do ciclo de vida de projetos iterativos Discutir a estrutura de cronogramas iterativos e incrementais Responder a perguntas comumente feitas durante o planejamento de projetos iterativos Como definir a quantidade e duração das iterações? O quanto realizar de cada fluxo de atividades em cada fase/iteração? Como sincronizar o trabalho da equipe? Não é possível obter mais paralelismo e produtividade? O cliente não topa esta estória de artefatos incrementais! Não quer revisar os requisitos diversas vezes, só enxerga retrabalho, acha que estamos perdendo seu tempo Que fazer? 6

Agenda Padrões de ciclo de vida Cronogramas iterativos e incrementais Quantidade e duração das iterações Estratégias para as iterações Sincronização do trabalho Comunicação com o cliente/usuário Resumindo... 7

Padrões de ciclo de vida Ferramenta para auxiliar no planejamento das fases Dependem das características do projeto Exemplos: Incremental Entrega incremental Evolucionário Híbridos 8

Para começar, não esqueça! Concepção Escopo, objetivos Elaboração Arquitetura Construção Operacionalidade (beta-releases) Transição Release (produtos) 9

Ciclo de vida incremental O domínio do problema é conhecido, familiar Os riscos estão bem entendidos e razoavelmente controlados A equipe é experiente C E B B B B T T Determinar as necessidades dos usuários, definir os requisitos e desenvolver o sistema como uma seqüência de builds, cada um acrescentando mais funcionalidades, até completar o produto. 10

Ciclo de vida evolucionário O domínio do problema é novo ou desconhecido A equipe é inexperiente C E E E E B T T 11

Entrega incremental O domínio do problema é conhecido, familiar Os requisitos e a arquitetura podem ser estabilizados bem cedo, durante o desenvolvimento (não existe muita novidade no sistema) A equipe é experiente É preciso liberar Releases incrementais do produto C E B T T T T T Bastante útil para produtos já conhecidos que, para ganhar mercado, precisam liberar certas funcionalidades em um curto espaço de tempo. 12

Grande Projeto Um pequeno conjunto de funcionalidades vai ser adicionado a um produto já estável As novas funcionalidades são bem conhecidas e entendidas A equipe é experiente, tanto no domínio do problema quanto no produto já existente C E B T T O ciclo de vida Cascata pode ser visto como um caso particular deste, onde existe apenas uma única e looooonga iteração na Construção. 13

Estratégias Híbridas Na prática, poucos projetos seguem apenas uma dessas estratégias de ciclo de vida A regra geral é: para sistemas onde existe alto risco associado ao negócio do desenvolvimento: Ênfase na Concepção para sistemas complexos ou onde não se tem domínio do problema: Ênfase na Elaboração para sistemas onde se espera maior complexidade/esforço na produção de código: Ênfase na Construção para sistemas onde é preciso entregar o produto em uma série de releases incrementais: Ênfase na Transição 14

Cronogramas iterativos e incrementais Bem mais complexos que os tradicionais cronogramas em cascata Normalmente organizados por fases e iterações 15

Cronogramas iterativos e incrementais Concepção Iteração 1 atividade X atividade Y atividade Z Elaboração Iteração 2 Iteração 3 Construção Iteração 4 Iteração 5 Iteração 6 Transição Iteração 7 O cronograma não é feito todo de uma vez! Lembre-se: o processo é iterativo! 16

Cronogramas iterativos e incrementais Concepção Iteração 1 atividade A atividade B atividade C Elaboração Iteração 2 atividade D atividade B atividade E Iteração 3 Construção Iteração 4 Iteração 5 Iteração 6 Transição Iteração 7 Devido a natureza do processo, várias atividades vão ficar repetidas As As atividades atividadesserão serãoas as mesmas, mesmas, mas mascom escopos/objetivos diferentes diferentes 17

Cronogramas iterativos e incrementais A maneira de organizar as atividades no cronograma pode variar bastante Nível de detalhes por atividade x por passos das atividades por artefatos Agrupamento por fluxo de atividades x por casos de uso Granularidade casos de uso x cenários 18

19

Algumas perguntas comuns 20

Como definir a quantidade e duração das iterações? Iterar é bom, mas acrescenta certo overhead! planejamento avaliação sincronização de atividades A agilidade para iterar depende basicamente de: tamanho da equipe experiência com o processo A complexidade e conhecimento do produto também pesam estratégias de ciclo de vida 21

Duração das iterações Alguns dados da Rational: Linhas de código 10.000 50.000 500.000 1.000.000 Equipe 5 15 45 100 Duração de 1 iteração 1 semana 1 mês 6 meses 1 ano 22

Duração das iterações Iterações pequenas (menores que um mês) planejar bem o escopo típicas da Construção com pouca adição de funcionalidades com pouca/nenhuma atividade formal de análise e projeto Iterações grandes (maiores que seis meses) adicionar marcos (milestones) intermediários o foco da iteração está claro?! considerar a possibilidade de reduzir o escopo da iteração (e reduzir a sua duração) As As iterações iteraçõesnão nãoprecisam precisamter ter todas todaso mesmo mesmotamanho! Exceto Excetodentro dentroda da mesma mesmafase! 23

Quantidade de iterações Projetos simples normalmente têm uma iteração por fase Projetos mais complexos, no seu primeiro ciclo de desenvolvimento normalmente apresentam: 1 iteração na Concepção 2 iterações na Elaboração 2 iterações na Construção 1 iteração na Transição Projetos grandes, em domínios desconhecidos, envolvendo novas tecnologias e muitos riscos: 2 iteração na Concepção 3 iterações na Elaboração 3 iterações na Construção 2 iteração na Transição 24

Quantidade de iterações Resumindo Projetos simples: 3/4 iterações [0/1, 1, 1, 1] Projetos típicos: 6 iterações [1, 2, 2, 1] Projetos grandes: 10 iterações [2, 3, 3, 2] Em Emgeral, planeja-se planeja-se de de 3 a 10 10 iterações! iterações! Na Na maioria maioriados dos casos casostemos temosde de 6 a 8 iterações! iterações! 25

O quanto realizar de cada fluxo de atividades em cada fase/iteração? Desenvolvimento em Cascata Requisitos A&P Implemen. Testes Implantação 26

O quanto realizar de cada fluxo de atividades em cada fase/iteração? Desenvolvimento iterativo e incremental Requisitos A&P Implemen. Testes Implantação Requisitos A&P Implemen. Testes Implantação Requisitos A&P Implemen. Testes Implantação Requisitos A&P Implemen. Testes Implantação 27

Fluxos de atividades e fases Em geral: Requisitos concentração na: Concepção e Elaboração Análise e projeto concentração na: Elaboração Implementação concentração na: Construção Testes concentração na: Construção Distribuição concentração na: Transição 28

Esforço dos fluxos de atividades por fase Inception Elaboration Construction Transition Management Requirements Design Implementation Test Deployment Environment Fonte: Software Project Management, Walker Royce 29

Completude dos artefatos por fase Inception Elaboration Construction Transition Requirements Design Implementation Deployment Requirements Design Implementation Deployment Requirements Design Implementation Deployment Requirements Design Implementation Deployment Management Management Management Management Fonte: Software Project Management, Walker Royce 30

O quanto realizar de cada fluxo de atividades em cada fase/iteração? De maneira geral, em cada iteração um subconjunto do trabalho total é realizado levantado/especificado analisado e projetado implementado testado preparado para a distribuição/distribuído Como escolher esse subconjunto? conhecimento da equipe no domínio do problema e arquitetura a ser adotada necessidade de liberação de releases/ deadline restrito 31

Estratégias para as iterações Larga e superficial Todo o domínio do problema é analisado, mas sem muitos detalhes Casos de uso: todos são definidos e a maioria é detalhada Arquitetura: definida amplamente todas as interfaces, serviços, etc. Muito pouca implementação até a Construção, onde fica o maior número de iterações Estreita e profunda Um pedacinho do domínio é analisdo em detalhes Os casos de uso relacionados com este pedacinho são detalhados A arquitetura necessária para suportar esse pedacinho é definida Esse pedacinho é implementado, testado e possivelmente implantado Híbrida Híbrida 32

Larga e superficial Apropriada quando: o time é inexperiente no domínio do problema ou nas tecnologias que serão usadas a arquitetura é inédita, ou é um requisito chave para as funcionalidades do sistema Possíveis problemas: analysis paralysis falta de credibilidade e confiança da equipe riscos técnicos não expostos devido a falta de detalhes (visão apenas de alto nível) 33

Estreita e profunda Apropriada quando: precisa-se de resultados muito rápido (para obter suporte, provar viabilidade ou eliminar certos riscos) os requisitos estão continuamente evoluindo o deadline é obrigatório existe alta reusabilidade Possíveis problemas: dificuldades de integração desenvolvimento de software integrado verticalmente, mas incompatível horizontalmente muito retrabalho devido a falta de uma visão geral do problema 34

Estatégia híbrida Na Concepção: larga e superficial para obter bom entendimento do escopo estreita e profunda para verificar a viabilidade de alguma tecnologia construção de um protótipo Na Elaboração: na maior parte do tempo, larga e superficial, para garantir que a arquitetura cobre todas as necessidades estreita e profunda em alguns pontos para atacar riscos específicos Na Construção: estreita e profunda, para implementar as funcionalidades do sistema, com alto grau de paralelismo e incrementalmente Na Transição: completar o que falta, de acordo com o feedback do usuário e bugs encontrados 35

Como sincronizar o trabalho? Como obter maior paralelismo e produtividade? O que os meus analistas vão fazer enquanto os programadores implementam? Alguma sobreposição de atividades sempre vai existir O planejamento da próxima iteração vai se iniciar da metade para o final da iteração corrente Muita sobreposição leva a problemas! comprometimento das pessoas com os objetivos da iteração falta de suporte para o trabalho que foi antecipado não aproveitamento das lições aprendidas durante as iterações Alternativas: aplicar a estratégia larga e superficial alocar os recursos para outras atividades planejamento e projeto de testes elaboração da documentação do usuário estimular a versatilidade dos profissionais 36

Como trabalhar com um cliente / usuário que não acredita no processo? O cliente não topa esta estória de artefatos incrementais! Não quer revisar os requisitos diversas vezes, só enxerga retrabalho, acha que estamos perdendo seu tempo Que fazer? Deixe as intenções e planos bem visíveis Um bom acompanhamento é essencial! Ofereça feedback concreto protótipos, componentes, versões alfa do sistema Proteja a equipe atue como filtro! Revise os artefatos em pontos apropriados Requisitos: no final da Concepção ou +- em 1/3 da Elaboração Arquitetura: no final da Elaboração Projeto: +- em 1/3 da Construção 37

Planejamento iterativo Conheça os riscos Planeje as fases duração e marcos (milestones) quantidade de iterações Planeje a primeiraiteração em detalhes atividades, recursos, tempo, Durante a execução da primeira iteração, planeje a segunda em detalhes E assim por diante 38

Exercício: Planejamento das Fases e Iterações Detalhar/ajustar o planejamento do seu projeto, definindo: a duração de cada fase o número de iterações de cada fase que estratégia será seguida para realizar as iterações a duração de cada iteração Registre o que for assumido como pressuposto para suas decisões! 39

Créditos Qualiti Software Processes www.qualiti.com Pela primeira versão destes slides 40