Embed Size (px)
Citation preview
1
Planejamento e Gerenciamento Iterativo de Projetos de Software
Hermano PerrelliCentro de Informática, UFPE
2
Objetivos desta aula 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!
3
Agenda1. Introdução – Motivação e Conceitos
Básicos2. Considerando os Riscos3. Planejamento Iterativo – Planejando as
Fases e Iterações
4
Outros tópicos interessantes… Estimativa de esforço
Técnicas – vantagens e dificuldades• Pontos de casos de uso• Wideband Delphi
Organização da Equipe Características de um time vitorioso Alocação da equipe nas fases
• Sincronização de atividades Atividades, artefatos e responsabilidades no
Fluxo de P&G Implementação de processos iterativos e
incrementais
5
Referências bibliográficas 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.
6
Outras referências 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 DeMarco. 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.
7
1. IntroduçãoMotivação e Conceitos Básicos
8
Objetivos deste módulo Apresentar a motivação para
planejamento e gerenciamento de projetos
Apresentar conceitos básicos Apresentar as características de uma
metodologia iterativa
9
Preocupações do Gerente de TI Melhorar a qualidade do desenvolvimento
de software Principais riscos e incertezas no
desenvolvimento de sistemas
10
O que faz um gerente de projetos? 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
11
Qual é o objetivo do gerente de projetos?
Desenvolver o produto esperado dentro do prazo, custo e nível de
qualidade desejados
12
Algumas estatísticas 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 em grandes empresas: 9% em empresas medianas: 16% em pequenas empresas: 28%
Fonte: Standish Group, 1995.
13
Planejamento e gerenciamento é para torná-lo parte do % de
sucesso!!!
Engenharia de SoftwareFator Humano Estratégias
do Negócio
14
Conceitos Básicos
15
Parkinson’s effect O trabalho se expande de modo a
preencher todo o tempo disponível para executá-lo
Se a equipe sentir que tem tempo disponível vai gastá-lo, contribuindo
para elevar os riscos do projeto!
16
Modelos de ciclo de vida de software Conjunto de fases, atividades, marcos e artefatos
que guiam o desenvolvimento, operação e manutenção de um sistema
Não existem modelos certos ou errados, apenas adequados ou não a uma determinada situação
Ferramenta para planejamento e gerenciamento!
17
Modelos de ciclo de vida de software Força bruta, code and fix, nike-way Cascata Espiral Iterativo …
18
Modelo Cascata Um dos mais antigos, e ainda um dos
mais usados! Várias atividades executadas de forma
sistemática e seqüencialEspec. de Requisitos
Análise e ProjetoImplementação
Integração e testes
Implantação
19
Modelo Cascata 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 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
20
Desenvolvimento cascata atrasa a redução de riscos
Início da integração
100%
Tempo
Prog
ress
o do
pro
jeto
(% c
odifi
cado
)
Deadlineoriginal
Fonte: Software Project Management, Walker Royce
21
Modelo Iterativo Aplicação do modelo cascata iterativamente As iterações iniciais atacam os maiores riscos
ReqA&P
ImpI/T
Imp
Iteração 1
ReqA&P
ImpI/T
Imp
Iteração 2
ReqA&P
ImpI/T
Imp
Iteração 3
TEMPO
22
Desenvolvimento iterativo antecipa a redução de riscos
100%
Tempo
Prog
ress
o do
pro
jeto
(% c
odifi
cado
)
Fonte: Software Project Management, Walker Royce
Ciclo de vida tradicional
Ciclo de vida iterativo
23
Modelo Iterativo 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!
24
Ator Qualquer coisa que interage com o
sistema Definem um papel particular São sempre externos ao sistema Exemplos:
um usuário do sistema outro sistema com o qual o sistema a
ser desenvolvido precisa se comunicar
Cliente
25
Caso de uso 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
ClienteRealizar pedido
26
Um exemplo – casos de uso do Qualiti Internet Banking
Operadora do DOC
Operadora cartao de crédito
Realizar transferencia
Consultar cheques
Solicitar taloes de cheque
Desbloquear taloes de cheque
Efetuar Login
Alterar senha
Consultar saldo
Consultar extrato
Consultar Qualiti CardRealizar DOC
Efetuar pagamento do Qualiti Card
Cliente
27
Cenários Significa um caminho através de um caso
de uso. Uma instância de um caso de uso Exemplo (Sacar dinheiro):
Saque com sucesso Tentativa de saque MAS senha incorreta Tentativa de saque MAS saldo insuficiente
28
Prioridade de casos de uso Essencial para gerenciar os requisitos Pode interferir no planejamento das
iterações A prioridade pode ser:
Essencial Importante Desejável ou Opcional
29
Uma Metodologia Iterativa e Incremental
30
Apenas a linguagem não basta!
+
++
+Metodologia de
desenvolvimento
Modelos, padrões e guias
Linguagem padrão
Ferramentas de apoio
Equipes treinadas
31
É fundamental a definição de quem faz O Que, Quando e Como
O que é uma metodologia? Processo de desenvolvimento Conjunto de métodos e práticas de
desenvolvimento (com orientações nas linguagens, paradigmas, tecnologias e ferramentas utilizadas)
32
Benefícios de uma metodologia 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
Mas… os benefícios não virão de imediato!Qualidade x Produtividade
33
Características da metodologia Inspirada no RUP (Rational Unified Process)
Processo Unificado de desenvolvimento de software• Conjunto de atividades a serem realizadas para produzir
ou evoluir software 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
E o que é o RUP?
34
Características da metodologia O desenvolvimento de sistemas
seguindo a metodologia é: Iterativo e incremental Guiado por casos de uso (use cases) Baseado na arquitetura do sistema Orientado a objetos
35
Iterativo e incrementalReq
A&PImp
I/TImp
Iteração 1
ReqA&P
ImpI/T
Imp
Iteração 2
ReqA&P
ImpI/T
Imp
Iteração 3
TEMPO
36
Iterativo e incremental Em cada iteração:
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!
37
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çõesRequisitos Testes Implantação
Casos de uso são usados durante todo o processo
Análise e Projeto
Implemen-tação
38
Baseado na arquitetura do sistema A arquitetura é prototipada e definida logo nas
primeiras iterações O desenvolvimento consiste em complementar a
arquitetura 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
39
Orientada a objetos Análise e Projeto em UML
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
40
Conceitos chave da metodologia Fases e Iterações Fluxos de Atividades Atividades Artefatos Modelos Guias e Padrões Responsáveis (papéis e perfis, não
pessoas)
41
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
Fases e iterações
42
Fases e iterações O ciclo de vida de um sistema consiste de quatro
fases:
As fases indicam a maturidade do sistema!tempo
Concepção Elaboração Construção Transição
Marcos principais
escopo arquitetura operação release
43
Marcos secundários: releases intermediários
Iteração preliminar
Concepção Elaboração Construção Transição
Iteração arquitet.
Iteração arquitet.
Iteração desenv.
Iteração desenv.
Iteração desenv.
Iteração de transição
Iteração de transição
Fases e iterações Cada fase é dividida em iterações
44
Fluxos de atividades Agrupam atividades correlacionadas Fluxos de atividades de suporte:
Planejamento e gerenciamento Gerência de configuração e mudanças
Fluxos de atividades básicos: Requisitos Análise e projeto Implementação Testes Distribuição
45
Fases, iterações e fluxos de atividades
Concepção Elaboração Construção Transição
IteraçãoPreliminar
Iter.#1
Iter.#2
Iter.#i
Iter.#i+1
Iter.#i+2
Iter.#n
Iter.#n+1
Requisitos.......................................
Análise e Projeto............................
Implementação...............................Testes.............................................Implantação...................................
Planejamento e Gerenciamento.....
Fluxos de Processo
Fluxos de Suporte
Fases
IteraçõesGerência de Configuração e Mudanças
46
Atividades Unidade de trabalho Composta de:
Objetivos Passos Entradas e saídas Responsável Guias e padrões
47
Artefatos Resultantes das atividades Possuem modelos para
indicar como devem ser feitos padronizar os formatos dos documentos
48
Responsáveis Representam perfis ou papéis, não
pessoasGerente do projetoArquitetoAnalistaProgramadorTestador
AnaLeonardoMarconi
Márcia
Rogério
49
Fluxos de atividadesPlanejamento e Gerenciamento
ContratanteAprovarProjeto
IniciarProjeto Atestar Conclusão
do Projeto
Gerente deProjeto
IdentificarRiscos
DesenvolverPlano de Projeto
DesenvolverPlano de Iteração
Executar Plano deIteração
AvaliarIteração
ReavaliarRiscos
FinalizarProjeto
Arquiteto
Priorizar casos de uso
DesenvolverEstudo deViabilidade
50
2. Considerando os Riscos
51
Objetivos desta parte 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
52
“Não se preocupe; eu vou pensar em algo…”, Indiana Jones
53
Gerenciamento de riscos Relaciona-se com a análise de aspectos
desconhecidos do projeto são esses aspectos que podem fazer com que
o projeto fracasse! Risco
fator, elemento, acontecimento, qualquer coisa que, se concretizada, pode interferir no sucesso do projeto
54
Gerenciamento de riscos
Identificação
Análise
Acompanhamento e controle
55
Identificação dos riscos Para levantar os riscos podemos usar:
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: riscos de projeto riscos do negócio riscos técnicos
56
Riscos de projeto Normalmente ameaçam o plano de projeto,
prejudicando o cronograma e/ou custo Estão relacionados ao uso de recursos
organizacionais• financiamento• ambiente de desenvolvimento• processo de desenvolvimento
humanos• equipe• cliente/usuários
tempo• cronograma• escopo
57
Riscos do negócio Normalmente ameaçam a distribuição ou
implantação do produto, prejudicando o retorno do investimento
Muitos são riscos indiretos
58
Riscos técnicos 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
59
Análise dos riscos 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
60
Estratégias para tratar os riscos Evitar
reorganizar o projeto de modo que ele não seja afetado pela concretização do risco
Transferir reorganizar o projeto de modo que outra
pessoa/instituição fique responsável pelo risco Aceitar
decidir conviver com o risco
61
Aceitando riscos 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
62
Acompanhamento e controle dos riscos Definir um responsável por cada risco ou pelo
grupo de riscos do projeto o “pessimista”
Monitorar os indicadores relatórios de status dos riscos
Deixar o “caminho livre” para notícias ruins Revisitar a lista de riscos periodicamente
semanalmente ao final de cada iteração
A gerência de riscos deve ser uma atividade contínua!
63
Os riscos no planejamento das iterações
64
Riscos e casos de uso 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
65
Matriz de Riscos
UC 1 UC 2 UC 3 UC 4
Risco X
Risco Y
Risco Z
66
Riscos e iteraçõesLista de riscos
Planejamento das iterações
Atenuação dos riscos
67
3. Planejamento IterativoPlanejando as Fases e Iterações
68
Objetivos desta parte Responder a perguntas comumente feitas durante o
planejamento de projetos iterativos 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
69
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 padrões de ciclo de vida
70
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
71
Para começar, não esqueça!
Concepção
Elaboração
Transição
Escopo, objetivos
Construção
Arquitetura
Operacionalidade (beta-releases)
Release (produtos)
72
Ciclo de vida incremental O domínio do problema é conhecido,
familiar Os riscos estão bem entendidos e
razoavelmente controlados A equipe é experiente
73
Ciclo de vida evolucionário O domínio do problema é novo ou
desconhecido A equipe é inexperiente
74
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
75
“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
76
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:
• para sistemas complexos ou onde não se tem domínio do problema:
• para sistemas onde se espera maior complexidade/esforço na produção de código:
• para sistemas onde é preciso entregar o produto em uma série de releases incrementais:
Ênfase na Concepção
Ênfase na Construção
Ênfase na Elaboração
Ênfase na Transição
77
Quantidade de iterações 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]
Resumindo…
Em geral, planeja-se de 3 a 10 iterações!Na maioria dos casos temos de 6 a 8 iterações!
78
Duração das iterações Normalmente variam de fase para fase, de
acordo com as características do projeto 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
79
Duração das iterações 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.000 100 1 ano
80
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
81
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
82
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)
83
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
84
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
85
Cronogramas iterativos e incrementais Bem mais complexos que os tradicionais
cronogramas em cascata Normalmente organizados por fases e
iterações
86
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!
87
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 atividades serão as mesmas, mas com
escopos/objetivos diferentes
88
Exemplo – Planejamento do Qualiti Internet Banking (QIB)
89
Características do projeto Prazo total: 16 semanas Equipe de 5 pessoas, experiente no
domínio do problema Equipe relativamente inexperiente no uso
da metodologia Um dos objetivos do projeto é treinar os
desenvolvedores no uso da metodologia Apoio de consultoria externa
Estão previstos 2 releases do produto
90
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
91
Conclusão – Planejamento Iterativo Conheça os riscos Planeje as fases
duração e marcos (milestones) quantidade de iterações
Planeje a primeira iteração em detalhes atividades, recursos, tempo, …
Durante a execução da primeira iteração, planeje a segunda em detalhes
E assim por diante…
