Planejamento e Gerenciamento Iterativo de Projetos de Software

Planejamento e Gerenciamento Iterativo de Projetos de Software Hermano Perrelli Centro de Informática, UFPE hermano@cin. ufpe. br 1

Objetivos desta aula n n n Discutir uma metodologia de desenvolvimento iterativa e incremental Apresentar atividades de planejamento de projetos de software na ótica de um processo iterativo e incremental Elucidar dúvidas comuns relacionadas ao planejamento de projetos iterativos e incrementais E trocar experiências! 2

Agenda 1. 2. 3. Introdução – Motivação e Conceitos Básicos Considerando os Riscos Planejamento Iterativo – Planejando as Fases e Iterações 3

Outros tópicos interessantes… n Estimativa de esforço n Técnicas – vantagens e dificuldades • Pontos de casos de uso • Wideband Delphi n Organização da Equipe n n Características de um time vitorioso Alocação da equipe nas fases • Sincronização de atividades n n Atividades, artefatos e responsabilidades no Fluxo de P&G Implementação de processos iterativos e incrementais 4

Referências bibliográficas n n n The Unified Software Development Process. Ivar Jacobson, Grady Booch e James Rumbaugh. Addison. Wesley, 1998. Software Project Management: A Unified Framework. Walker Royce. Addison-Wesley, 1998. Object-Oriented Project Management with UML. Murray Cantor. Wiley, 1998. Managing Risk: Methods for Software Systems Development. Elaine M. Hall. Addison-Wesley, 1998. Object Solutions: Managing the Object-Oriented Project (Addison-Wesley Object Technology Series). Grady Booch. Addison-Wesley, 1999. 5

Outras referências n n n COCOMO 2: sunset. usc. edu/research/cocomosuite. Center for Software Engineering. Última visita em 8 de outubro de 2001. Software Engineering Economics. Barry Boehm. Prentice-Hall, 1981. The Deadline: A Novel About Project Management. Tom De. Marco. Dorset House, 1997. Applying Use Cases: A Practical Guide. Geri Schneider, Jason P. Winters, Ivar Jacobson. Addison-Wesley, 1998. Rational web site: www. rational. com. 6

1. Introdução Motivação e Conceitos Básicos 7

Objetivos deste módulo n n n Apresentar a motivação para planejamento e gerenciamento de projetos Apresentar conceitos básicos Apresentar as características de uma metodologia iterativa 8

Preocupações do Gerente de TI n n Melhorar a qualidade do desenvolvimento de software Principais riscos e incertezas no desenvolvimento de sistemas 9

O que faz um gerente de projetos? n n n n Aloca recursos Define prioridades Coordena as interações com clientes e usuários Procura manter a equipe de projeto focada na meta do projeto Resolve conflitos Gerencia riscos Estabelece um conjunto de práticas para assegurar a qualidade dos artefatos do projeto 10

Qual é o objetivo do gerente de projetos? Desenvolver o produto esperado dentro do prazo, custo e nível de qualidade desejados 11

Algumas estatísticas n n n 31% dos projetos são abortados 53% dos projetos extrapolam o prazo em mais de 50% % de projetos que são finalizados dentro do prazo e custo esperados n em grandes empresas: 9% n em empresas medianas: 16% em pequenas empresas: 28% n Fonte: Standish Group, 1995. 12

Planejamento e gerenciamento é para torná-lo parte do % de sucesso!!! Fator Humano Engenharia de Software Estratégias do Negócio 13

Conceitos Básicos 14

Parkinson’s effect n O trabalho se expande de modo a preencher todo o tempo disponível para executá-lo Se a equipe sentir que tempo disponível vai gastá-lo, contribuindo para elevar os riscos do projeto! 15

Modelos de ciclo de vida de software n Conjunto de fases, atividades, marcos e artefatos que guiam o desenvolvimento, operação e manutenção de um sistema Ferramenta para planejamento e gerenciamento! n Não existem modelos certos ou errados, apenas adequados ou não a uma determinada situação 16

Modelos de ciclo de vida de software n n n Força bruta, code and fix, nike-way Cascata Espiral Iterativo … 17

Modelo Cascata n n Um dos mais antigos, e ainda um dos mais usados! Várias atividades executadas de forma sistemática e seqüencial Espec. de Requisitos Análise e Projeto Implementação Integração e testes Implantação 18

Modelo Cascata n n n Fixa pontos específicos para a entrega de artefatos É simples e fácil de aplicar, facilitando o planejamento Na prática, existe uma interação entre as atividades e cada atividade pode levar a modificações nas anteriores n na maioria dos casos existe interação e superposição! Pressupõe que os requisitos ficarão estáveis Atrasa a redução de riscos 19

Desenvolvimento cascata atrasa a redução de riscos Início da integração Progresso do projeto (% codificado) 100% Deadline original Tempo Fonte: Software Project Management, Walker Royce 20

Modelo Iterativo n n Aplicação do modelo cascata iterativamente As iterações iniciais atacam os maiores riscos Req A&P Imp I/T Imp Iteração 1 Imp Iteração 2 TEMPO I/T Imp Iteração 3 21

Desenvolvimento iterativo antecipa a redução de riscos Ciclo de vida iterativo Progresso do projeto (% codificado) 100% Ciclo de vida tradicional Tempo Fonte: Software Project Management, Walker Royce 22

Modelo Iterativo n n n Testes e integração são realizados desde o início, de forma contínua Riscos críticos são resolvidos antes que grandes investimentos sejam realizados Permite feedback dos usuários desde cedo Pequenos objetivos, foco em curto-prazo Progresso é medido de forma mais concreta Implementações parciais podem ser implantadas Utiliza as vantagens do modelo cascata, sem atrasar a resolução de riscos! 23

Ator n n Cliente Qualquer coisa que interage com o sistema Definem um papel particular São sempre externos ao sistema Exemplos: n n um usuário do sistema outro sistema com o qual o sistema a ser desenvolvido precisa se comunicar 24

Caso de uso n n n Cliente Realizar pedido Seqüência de ações que incorpora uma funcionalidade específica do sistema, fornecendo um resultado de valor para algum ator. Forma específica de uso do sistema através da execução de alguma de suas funcionalidades. Conjunto de cenários que capturam requisitos funcionais do sistema Mostram apenas o que o sistema faz, e não como Capturam o comportamento pretendido para um sistema, sem a necessidade de especificar como esse comportamento será implementado 25

Um exemplo – casos de uso do Qualiti Internet Banking 26

Cenários n n n Significa um caminho através de um caso de uso. Uma instância de um caso de uso Exemplo (Sacar dinheiro): n n n Saque com sucesso Tentativa de saque MAS senha incorreta Tentativa de saque MAS saldo insuficiente 27

Prioridade de casos de uso n n n Essencial para gerenciar os requisitos Pode interferir no planejamento das iterações A prioridade pode ser: n n n Essencial Importante Desejável ou Opcional 28

Uma Metodologia Iterativa e Incremental 29

Apenas a linguagem não basta! + Linguagem padrão + Modelos, padrões e guias Metodologia de desenvolvimento + Ferramentas de apoio + Equipes treinadas 30

O que é uma metodologia? n n Processo de desenvolvimento Conjunto de métodos e práticas de desenvolvimento (com orientações nas linguagens, paradigmas, tecnologias e ferramentas utilizadas) É fundamental a definição de quem faz O Que, Quando e Como 31

Benefícios de uma metodologia n n n Qualidade de software Produtividade no desenvolvimento, operação e manutenção de software Permitir ao profissional controle sobre o desenvolvimento dentro de custos, prazos e níveis de qualidade desejados Permitir ao profissional estimar custos e prazos com maior precisão Qualidade x Produtividade Mas… os benefícios não virão de imediato! 32

Características da metodologia n Inspirada no RUP (Rational Unified Process) E o que é o RUP? n Processo Unificado de desenvolvimento de software • Conjunto de atividades a serem realizadas para produzir ou evoluir software n n Baseado em boas práticas de desenvolvimento Framework para processos • Para usar o RUP é preciso instanciá-lo e definir padrões e guias específicos para a realidade de cada empresa/projeto 33

Características da metodologia n O desenvolvimento de sistemas seguindo a metodologia é: Iterativo e incremental n Guiado por casos de uso (use cases) n Baseado na arquitetura do sistema n Orientado a objetos n 34

Iterativo e incremental Req A&P Imp I/T Imp Iteração 1 Imp Iteração 2 I/T Imp Iteração 3 TEMPO 35

Iterativo e incremental n Em cada iteração: n n n são identificados e especificados os casos de uso mais relevantes é feita a análise e projeto dos casos de uso, usando-se a arquitetura como guia são implementados componentes que realizam o que foi projetado verifica-se se os componentes satisfazem os casos de uso escolhidos A escolha dos casos de uso é baseada em uma análise dos riscos envolvidos no projeto Os casos de uso que apresentam os maiores riscos devem ser realizados primeiro, para resolver os riscos o quanto antes! 36

Guiado por casos de uso (use cases) • Casos de uso são usados para especificar requisitos • Durante a análise, projeto e implementação os casos de uso são “realizados” • Durante os testes, verifica-se se o sistema realiza o que está descrito no Modelo de Casos de Uso • Casos de uso são usados no planejamento e acompanhamento das iterações Requisitos Análise e Projeto Implementação Testes Implantação Casos de uso são usados durante todo o processo 37

Baseado na arquitetura do sistema n n A arquitetura é prototipada e definida logo nas primeiras iterações O desenvolvimento consiste em complementar a arquitetura n n n A arquitetura guia o projeto e implementação das diversas partes do sistema A arquitetura serve para organizar o desenvolvimento, estruturar a solução e identificar oportunidades de reuso Os casos de uso dizem o que deve ser feito e a arquitetura descreve como 38

Orientada a objetos n Análise e Projeto em UML n n n UML é uma linguagem usada para especificar, modelar e documentar os artefatos de um sistema É um padrão da OMG e têm se tornado o padrão empresarial para modelagem OO Implementação em Java ou alguma outra linguagem de programação OO 39

Conceitos chave da metodologia n n n n Fases e Iterações Fluxos de Atividades Artefatos Modelos Guias e Padrões Responsáveis (papéis e perfis, não pessoas) 40

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 41

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

Fases e iterações n Cada fase é dividida em iterações Concepção Iteração preliminar Elaboração Iteração arquitet. Construção Iteração desenv. Transição Iteração de transição Marcos secundários: releases intermediários 43

Fluxos de atividades n n Agrupam atividades correlacionadas Fluxos de atividades de suporte: n n n Planejamento e gerenciamento Gerência de configuração e mudanças Fluxos de atividades básicos: n n n Requisitos Análise e projeto Implementação Testes Distribuição 44

Fases, iterações e fluxos de atividades Fluxos de Processo Fases Concepção Elaboração Iteração Preliminar Iter. #1 Construção Transição Requisitos. . . . . Análise e Projeto. . . . Implementação. . . . Testes. . . Implantação. . . . . Fluxos de Suporte Planejamento e Gerenciamento. . . Gerência de Configuração e Mudanças Iter. #2 Iter. #i+1 Iter. #i+2 Iter. #n+1 Iterações 45

Atividades n n Unidade de trabalho Composta de: n n n Objetivos Passos Entradas e saídas Responsável Guias e padrões 46

Artefatos n n Resultantes das atividades Possuem modelos para n n indicar como devem ser feitos padronizar os formatos documentos 47

Responsáveis n Representam perfis ou papéis, não pessoas Ana Gerente do projeto Leonardo Arquiteto Marconi Analista Márcia Programador Rogério Testador 48

Fluxos de atividades Planejamento e Gerenciamento Contratante Desenvolver Estudo de Viabilidade Iniciar Projeto Aprovar Projeto Identificar Riscos Desenvolver Plano de Projeto Gerente de Projeto Arquiteto Atestar Conclusão do Projeto Executar Plano de Iteração Desenvolver Plano de Iteração Avaliar Iteração Finalizar Projeto Reavaliar Riscos Prioriza r casos de uso 49

2. Considerando os Riscos 50

Objetivos desta parte n n n Introduzir conceitos básicos relacionados ao gerenciamento de riscos Discutir o levantamento, análise e tratamento de riscos Exercitar o planejamento de iterações de acordo com os riscos do projeto 51

“Não se preocupe; eu vou pensar em algo…”, Indiana Jones 52

Gerenciamento de riscos n Relaciona-se com a análise de aspectos desconhecidos do projeto n n são esses aspectos que podem fazer com que o projeto fracasse! Risco n fator, elemento, acontecimento, qualquer coisa que, se concretizada, pode interferir no sucesso do projeto 53

Gerenciamento de riscos Identificação Análise Acompanhamento e controle 54

Identificação dos riscos n Para levantar os riscos podemos usar: n n n o conhecimento do negócio estudo de viabilidade, documento de requisitos e plano do projeto brainstormings checklists Os riscos podem ser classificados de acordo com sua natureza em: n n n riscos de projeto riscos do negócio riscos técnicos 55

Riscos de projeto n n Normalmente ameaçam o plano de projeto, prejudicando o cronograma e/ou custo Estão relacionados ao uso de recursos n organizacionais • financiamento • ambiente de desenvolvimento • processo de desenvolvimento n humanos • equipe • cliente/usuários n tempo • cronograma • escopo 56

Riscos do negócio n n Normalmente ameaçam a distribuição ou implantação do produto, prejudicando o retorno do investimento Muitos são riscos indiretos 57

Riscos técnicos n n Normalmente ameaçam a qualidade do produto, prejudicando o tempo de conclusão do projeto São relacionados ao uso da tecnologia necessária para implementar o sistema 58

Análise dos riscos n n Encontrados os riscos, é preciso decidir o que fazer com eles… Para tanto, vamos considerar a magnitude ou prioridade do risco e criar a lista dos “ 10 mais” Magnitude = probabilidade * impacto 59

Estratégias para tratar os riscos n Evitar n n Transferir n n reorganizar o projeto de modo que ele não seja afetado pela concretização do risco reorganizar o projeto de modo que outra pessoa/instituição fique responsável pelo risco Aceitar n decidir conviver com o risco 60

Aceitando riscos n n Determinar um Plano de contingência (Plano B) Estabelecer ações para mitigar ou atenuar o risco • Muitas vezes, resume-se a uma melhor investigação de algum ponto específico. Por exemplo: Risco: o protocolo escolhido para comunicação com o servidor pode não atender aos requisitos de desempenho do sistema Ação: implementar a comunicação com o servidor e testar o seu desempenho 61

Acompanhamento e controle dos riscos n Definir um responsável por cada risco ou pelo grupo de riscos do projeto n n Monitorar os indicadores n n n o “pessimista” relatórios de status dos riscos Deixar o “caminho livre” para notícias ruins Revisitar a lista de riscos periodicamente n n semanalmente ao final de cada iteração A gerência de riscos deve ser uma atividade contínua! 62

Os riscos no planejamento das iterações 63

Riscos e casos de uso n n A realização dos casos de uso é usada para eliminar riscos Para facilitar a visualização do relacionamento entre casos de uso e riscos, pode-se usar uma matriz de riscos 64

Matriz de Riscos UC 1 UC 2 Risco X Risco Y Risco Z UC 3 UC 4 65

Riscos e iterações Lista de riscos Planejamento das iterações Atenuação dos riscos 66

3. Planejamento Iterativo Planejando as Fases e Iterações 67

Objetivos desta parte n Responder a perguntas comumente feitas durante o planejamento de projetos iterativos n n n Como definir a quantidade e duração das iterações em cada fase do projeto? O quanto realizar de cada fluxo de atividades em cada fase/iteração? Apresentar padrões do ciclo de vida e estratégias para o planejamento das atividades de projetos iterativos e incrementais Conhecer a estrutura de cronogramas iterativos e incrementais Discutir um exemplo de planejamento de projeto iterativo e incremental 68

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

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

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

Ciclo de vida incremental n n n O domínio do problema é conhecido, familiar Os riscos estão bem entendidos e razoavelmente controlados A equipe é experiente 72

Ciclo de vida evolucionário n n O domínio do problema é novo ou desconhecido A equipe é inexperiente 73

Entrega incremental n n 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 74

“Grande Projeto” n n n 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 75

Estratégias Híbridas n n 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 76

Quantidade de iterações n 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] n Resumindo… n n Em geral, planeja-se de 3 a 10 iterações! Na maioria dos casos temos de 6 a 8 iterações! 77

Duração das iterações n Normalmente variam de fase para fase, de acordo com as características do projeto n n n Iterações pequenas são típicas da Construção, com pouca ou nenhuma atividade formal de análise e projeto Iterações grandes demandam marcos (milestones) intermediários O tamanho da equipe e sua experiência com o processo é um dos fatores determinantes 78

Duração das iterações n Alguns dados da Rational: Linhas de código Equipe Duração de 1 iteração 10. 000 5 1 semana 50. 000 15 1 mês 500. 000 45 6 meses 1. 000 100 1 ano 79

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

Estratégias para as iterações n Larga e superficial n n n 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 n n 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 81

Larga e superficial n Apropriada quando: n n n 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: n n n 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) 82

Estreita e profunda n Apropriada quando: n n n 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: n dificuldades de integração • desenvolvimento de software integrado “verticalmente”, mas incompatível “horizontalmente” n muito retrabalho devido a falta de uma visão geral do problema 83

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 84

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

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

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

Exemplo – Planejamento do Qualiti Internet Banking (QIB) 88

Características do projeto n n n Prazo total: 16 semanas Equipe de 5 pessoas, experiente no domínio do problema Equipe relativamente inexperiente no uso da metodologia n n n Um dos objetivos do projeto é treinar os desenvolvedores no uso da metodologia Apoio de consultoria externa Estão previstos 2 releases do produto 89

Planejamento do projeto • Concepção • Iteração preliminar de 2 semanas, larga e superficial, para “iniciar o projeto” • Elaboração • 1 iteração, de 5 semanas, para eliminar os principais riscos • Estratégia híbrida: larga e superficial para modelar a arquitetura e estreita e profunda para eliminar o risco de alguns cenários • Construção • 2 iterações de 2 semanas cada, estreitas e profundas, para produzir a versao beta do sistema • Transição • 1 iteração de 2 semanas para finalizar a primeira versão do sistema, com parte das funcionalidades previstas • 1 iteração de 3 semanas para incorporar as funcionalidades restantes e lançar a versão completa do QIB 90

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