Métricas e Estimativas de Projetos de Software

Métricas e Estimativas de Projetos de Software
Autor: Carla Alessandra Lima Reis (Revisado por Roberto Petry)

Estimativas de Projetos – Carla A. Lima Reis
Objetivos Gerais Abordar o assunto Estimativas de Projeto de software destacando as técnicas, heurísticas e ferramentas necessárias para que o processo de estimativa seja incorporado à gerência de projetos de software. Estimativas de Projetos – Carla A. Lima Reis

Parte I Conceitos Fundamentais sobre Estimativas de Software

Introdução O que é uma Estimativa? “avaliação ou cálculo aproximado de algo; parecer sobre uma pessoa ou situação baseado nas evidências existentes.” (Houaiss) É uma predição sobre quanto tempo um projeto levará ou quanto vai custar (McConnel, 2006) Estimativas de Projetos – Carla A. Lima Reis

Introdução O que não é uma Estimativa? Metas e promessas não são estimativas “Temos que terminar a versão 2 do sistema para a demonstração na feira de tecnologia...” “Temos que concluir esses módulos em 1 de julho para atender as novas leis do governo.” “O custo da próxima versão não pode passar de R$20.000, porque esse é o nosso orçamento aprovado...” Estimativas de Projetos – Carla A. Lima Reis

Introdução Estimar projetos é um dos maiores desafios no desenvolvimento de software. Planejamento e controle adequados não são possíveis sem estimativas confiáveis Em geral, a indústria de software não estima bem seus projetos Estimativas de Projetos – Carla A. Lima Reis

Introdução Relação entre Estimativa e Planejamento
Estimativa é um processo imparcial e analítico, enquanto planejamento é parcial e busca atingir uma meta. Estimativa forma a base para o planejamento. Se as estimativas são diferentes das metas o planejamento deve tratar essa diferença como um risco alto. Existem frequentes problemas de comunicação decorrentes do relacionamento entre Estimativa e Planejamento. Quando lhe pedirem uma estimativa, verifique se é para estimar ou descobrir uma forma de atingir a meta. Estimativas de Projetos – Carla A. Lima Reis

Introdução Toda estimativa é associada a uma probabilidade Não existe estimativa com 100% de probabilidade Probabilidade De sucesso Tempo estimado 90% 24 semanas 75% 22 semanas 50% 20 semanas 10% 18 semanas 0% 16 semanas 12 semanas 10 semanas 8 semanas 6 semanas 4 semanas 2 semanas Estimativas de Projetos – Carla A. Lima Reis

Introdução 500% As estimativas tornam-se cada vez mais precisas à medida em que aumenta o nível de maturidade da organização. Apenas o uso de técnicas de estimativas não garante precisão. Deve haver efetiva gerência de projetos apoiando essa tarefa. 400% 300% 200% 100% 0% 1 2 3 Nível CMM Fonte:”A Correlational study of the CMM and Software Development Performance” (Lawlis, Flowe and Thordahl 1995) Estimativas de Projetos – Carla A. Lima Reis

Introdução Estimativa e Controle de Projetos
Estimar não é uma atividade puramente preditiva “O ato de observar uma coisa já a modifica” (Princípio da Incerteza de Heisenberg) Projetos mudam bastante. Uma vez que produzimos uma estimativa e, com base nisso, fazemos um planejamento para entregar o produto em uma data, então temos que controlar o projeto para que ele atinja a meta. Estimativas de Projetos – Carla A. Lima Reis

Estimativa e Controle de Projetos
Requisitos removidos Equipe desviada para apoiar apresentação em feira Funcionalidade instável removida Equipe não estava pronta no prazo O Projeto Estimativa: 20 pessoas/mês Saída: 20 pessoas/mês Novos requisitos adicionados Equipe foi desviada para atender projeto antigo (manutenção urgente) Equipe com pouca experiência Mais requisitos adicionados Estimativas de Projetos – Carla A. Lima Reis

Gestão de Projetos Visão Planejamento Inicial do Projeto (Re) Planejamento do Projeto Requisitos Acompanhamento do Projeto - resultados parciais x estimado - acompanhamento das atividades - ações corretivas - replanejamento Estimativa de: - tamanho; - esforço; - custo; - prazo; - recursos computacionais; - riscos Análise de resultados (histórico do projeto) - resultados finais (estimado x realizado) - lições aprendidas Estimativas de Projetos – Carla A. Lima Reis

O que é uma Boa estimativa?
Uma boa estimativa provê uma visão suficientemente clara da realidade do projeto para permitir que seu líder tome boas decisões sobre como controlá-lo para atingir as metas (Steve McConnel, 2006) Estimativas de Projetos – Carla A. Lima Reis

Precisão das Estimativas
“Estimativa é a previsão mais otimista com probabilidade não nula de se tornar realidade”(Tom DeMarco, 1982) Sabemos que estimativas precisas são raras, então se vamos errar, devemos errar para mais ou para menos?? Estimativas de Projetos – Carla A. Lima Reis

Por que não superestimar?
Se o projeto for superestimado, o trabalho ocupará todo o tempo disponível(Lei de Parkinson) Se o gerente der 5 dias para o desenvolvedor fazer uma tarefa que pode ser feita em 4, o desenvolvedor vai encontrar alguma coisa pra fazer no dia extra. Se as pessoas têm muito tempo pra fazer uma tarefa, elas irão adiar o início até chegar ao ponto de ter que correr pra terminar no prazo (e provavelmente não terminarão no prazo) Para dar um sentimento de urgência no projeto. Estimativas de Projetos – Carla A. Lima Reis

Por que não subestimar? Prejudica os planos do projeto Escolha de uma equipe menor que a necessária Problemas de integração entre grupos quando um grupo não estiver pronto para integrar sua tarefa com outro Reduz as chances de terminar no prazo Sabendo que tipicamente* as estimativas são de 20 a 30% inferiores ao realizado, subestimar o prazo reduz muito as chances do projeto terminar no prazo. Estimativas de Projetos – Carla A. Lima Reis *(Van Genuchten, 1991)

Por que não subestimar? Tendência a negligência de atividades técnicas importantes Deixando de lado atividades importantes como requisitos e projeto para obter logo o produto, leva a necessidade de refazer tais atividades mais tarde, custando mais caro do que se fizesse bem feito de primeira**. O projeto assim leva muito mais tempo do que se tivesse sido estimado corretamente. Estimativas de Projetos – Carla A. Lima Reis **(Boehm/Turner, 2004/McConnel 2004)

Por que não subestimar? Um projeto no estado “atrasado” traz mais atraso. Mais reuniões são realizadas para discutir como concluir o projeto Reestimativas frequentes são feitas para determinar quando o projeto termina Pedidos de desculpas ao cliente (incluindo reuniões) Preparação de releases falsos para demonstração ao cliente e a eventos Mais discussões sobre quais requisitos devem realmente ser atendidos Conserto de bugs causados por implementações apressadas devido à pressão do prazo. Estimativas de Projetos – Carla A. Lima Reis

O que fazer então? As penalidades de subestimar o projeto são piores que as penalidades de superestimar. Conselho de McConnel: Trate a superestimativa com planejamento e controle. Estimativas de Projetos – Carla A. Lima Reis

Benefícios das estimativas precisas
Melhor visão do estado do projeto é possível rastrear as ocorrências de acordo com o plano Aumento da qualidade Aproximadamente 40% dos erros são causados por stress (Glass 1994) Melhor gerência das outras tarefas do negócio Campanhas de marketing, treinamentos, projeções financeiras, etc. Melhor definição de orçamento Aumento da credibilidade com a equipe de desenvolvimento Detecção antecipada de riscos Diferenças entre as metas e as estimativas Ações corretivas podem ser tomadas mais cedo Estimativas de Projetos – Carla A. Lima Reis

Onde as estimativas erram?

Onde as estimativas erram?
Desenvolvimento de software consiste em tomar muitas decisões A incerteza da estimativa resulta da incerteza da sobre como as decisões serão tomadas Estudo do Cone da Incerteza Estimativas de Projetos – Carla A. Lima Reis

Cone da Incerteza Grau de erro nas estimativas de estimadores experientes 4x 2x 1,5x Variabilidade da estimativa do escopo do projeto (esforço, Custo, funcionalidade) 1,25x 1x 0,8x 0,67x 0,5x 0,25x Concepção Def. do produto aprovada Def. de requisitos completa Projeto de interface completo Projeto detalhado completo Software completo Estimativas de Projetos – Carla A. Lima Reis

Cone da Incerteza Com controle de projetos efetivo o cone pode afinar
4x 2x 1,5x Variabilidade da estimativa do escopo do projeto (esforço, Custo, funcionalidade) 1,25x 1x 0,8x 0,67x 0,5x 0,25x Concepção Def. do produto aprovada Def. de requisitos completa Projeto de interface completo Projeto detalhado completo Software completo Estimativas de Projetos – Carla A. Lima Reis

Cone da Incerteza Como o cone não afina sozinho, sem controle de projetos, as estimativas podem nunca convergir 4x 2x 1,5x Variabilidade da estimativa do escopo do projeto (esforço, Custo, funcionalidade) 1,25x 1x 0,8x 0,67x 0,5x 0,25x Concepção Def. do produto aprovada Def. de requisitos completa Projeto de interface completo Projeto detalhado completo Software completo Estimativas de Projetos – Carla A. Lima Reis

Lições do Cone da Incerteza
Devem ser tomadas decisões que diminuam a variabilidade das estimativas, por exemplo: Definir os requisitos Definir o que não será feito Projetar a interface do usuário Se o produto não estiver bem definido ou se for redefinido depois, o cone ficará mais aberto e a precisão da estimativa será menor. Promessas somente podem ser feitas quando algumas decisões foram tomadas para o cone afinar Estimativas de Projetos – Carla A. Lima Reis

Lições do Cone da Incerteza
Invista mais em gerência de projetos do que em precisão de estimativa se: o desenvolvimento for caótico Falta de def. de requisitos Falta de envolvimento do usuário Projeto mal feito Programação mal feita Equipe inexperiente Falta de planejamento Abandono dos planos sob pressão ... os requisitos forem muito instáveis Estimativas de Projetos – Carla A. Lima Reis

Onde mais as estimativas erram?
Alguns requisitos são omitidos/esquecidos das estimativas, por exemplo: Funcionais: Programa de instalação Conversor de dados Código para interface com outros sistemas Sistema de ajuda ao usuário Não funcionais Interoperabilidade Portabilidade Reusabilidade Segurança usabilidade Estimativas de Projetos – Carla A. Lima Reis

Algumas atividades são omitidas/esquecidas das estimativas, por exemplo: Tarefas de coordenação e reuniões Instalação Criação de dados de teste Atendimento a pedidos de mudança Lidar com subcontratados Ajuste de performance Revisão de documentação técnica ... Estimativas de Projetos – Carla A. Lima Reis

Algumas atividades não relacionadas ao desenvolvimento são omitidas/esquecidas das estimativas, por exemplo: Férias Feriados Doença Treinamentos Resolução de problemas de hardware Encontros/confraternizações da empresa Essas atividades devem ser mais consideradas para projetos maiores Estimativas de Projetos – Carla A. Lima Reis

Subjetividade Excesso de parâmetros subjetivos solicitados pelos modelos de estimativas Estimativas informais (chutes) Melhor não dar nenhuma estimativa informal E se o chefe insistir em uma estimativa na hora??? Estimativas de Projetos – Carla A. Lima Reis

O que influencia a estimativa de um software?

O que mais influencia na estimativa?
Tamanho do Software Tipo de Software sendo desenvolvido Fatores humanos Linguagem de programação Outros fatores Estimativas de Projetos – Carla A. Lima Reis

1-Tamanho do software O custo e esforço de um projeto são proporcionais ao seu tamanho Não se pode estimar um software sem saber seu tamanho Toda mudança no projeto deve ser contabilizada no tamanho Métricas de tamanho: Linhas de código (LOC) Pontos por função Pontos por caso de uso Quantidade de telas Quantidade de classes Quantidade de métodos por classe Média de Linhas de código por método Estimativas de Projetos – Carla A. Lima Reis

1-Tamanho do software “Deseconomia” de escala Se o sistema A é 10 vezes maior que o sistema B, isso não significa que o seu esforço será apenas 10 vezes maior que o de B. Projetos maiores requerem coordenação de grupos maiores de pessoas, o que requer mais comunicação O esforço do projeto aumenta exponencialmente com o tamanho do projeto por causa dos caminhos de comunicação Estimativas de Projetos – Carla A. Lima Reis

1-Tamanho do software Caminhos de comunicação entre pessoas
Estimativas de Projetos – Carla A. Lima Reis

“Deseconomia” de escala para projetos típicos
Crescimento típico Crescimento linear Esforço (pessoas;mês) Tamanho do projeto (LOC) Estimativas de Projetos – Carla A. Lima Reis Fonte- Boehm, 2000

Como calcular “Deseconomia” de escala
Use ferramentas de estimativas para conhecer o impacto da deseconomia de escala Se o projeto estimado for do mesmo tamanho dos anteriores, o novo pode ser estimado em função do primeiro Estimativas de Projetos – Carla A. Lima Reis

2-Tipo de Software As taxas de produtividade variam muito em função do tipo de software. LOC/Pessoa Mês (mín-máx) Tipo de software 10KLOC 100KLOC 250KLOC Aviação 20-300 20-200 Sistemas de informação Sistemas Web Sistemas de tempo real telecomunicações 50-600 40-500 Estimativas de Projetos – Carla A. Lima Reis Fonte: McConnell 2006

2-Tipo de Software Como estimar levando isso em consideração?
Usar modelos de estimativas como o COCOMO II, que já incorpora esses ajustes; Use dados históricos da sua empresa Proposto por Barry Boehm para estimativas Estimativas de Projetos – Carla A. Lima Reis Fonte: McConnell 2006

3-Fatores Humanos Exemplo: pouca habilidade em análise de requisitos vai demandar até 42% a mais de esforço no projeto De acordo com o modelo COCOMO II: Melhor caso Pior caso -29% 42% habilidade Análise de requisitos -24% 34% habilidade programação -19% 29% Rotatividade de pessoas -19% 22% Experiência na aplicação (negócio) -16% 20% Experiência na linguagem e ferramentas -15% 19% Experiência na plataforma adotada -14% 11% Coesão da equipe Estimativas de Projetos – Carla A. Lima Reis

3-Fatores Humanos Implicação: Não é possível estimar precisamente o projeto sem conhecer quem vai trabalhar nele. Estimativas de Projetos – Carla A. Lima Reis

4-Linguagem de Programação
A experiência da equipe com a linguagem e ferramentas pode impactar em quase 40% Algumas linguagens geram mais funcionalidade por linha que outras Funcionalidade da ferramenta de apoio a programação (a escolha da linguagem determina a escolha da ferramenta) Trabalhar com linguagens interpretadas tende a ser mais produtivo (fator 2). Estimativas de Projetos – Carla A. Lima Reis

5- Outros fatores que influenciam (Fatores do COCOMO)
Complexidade do produto Capacidade de análise de requisitos Capacidade de programação Restrições de tempo Rotatividade de pessoal Desenvolvimento descentralizado Confiabilidade requerida do software Quantidade de documentação requerida Experiência da equipe no negócio Uso de ferramentas de apoio Volatilidade da plataforma Restrições de armazenamento Maturidade do processo Experiência com as ferramentas Tamanho do banco de dados Resolução de riscos Desenvolvimento para reutilização ... Estimativas de Projetos – Carla A. Lima Reis

Parte II Técnicas de Estimativas

Por que medir? “Não se consegue controlar o que não se consegue medir". (Tom DeMarco) “Medir é fundamental em qualquer disciplina da engenharia, e a engenharia de software não é uma exceção”. (Tom DeMarco) Estimativas de Projetos – Carla A. Lima Reis

Métricas de Software Uso de métricas de software No Planejamento Informações das medições de projetos anteriores poderão ser utilizadas na estimativa do novo projeto. Durante o desenvolvimento Medições são coletadas e analisadas em relação às estimativas propostas inicialmente Ao término do desenvolvimento Medições são coletadas e analisadas (métricas do produto) Taxa média de defeitos, custos, etc. Estimativas de Projetos – Carla A. Lima Reis

Métricas x Estimativas
Aplicação Entregue Projeto Detalhado Planejamento Requisitos Estimativa Inicial Estimativas Intermediárias Software Implantado Real Estimativas de Projetos – Carla A. Lima Reis

Métricas x Estimativas
Aplicativo Entregue Projeto Funcional Projeto Detalhado Requisitos 100 PFs 120 PFs 130 PFs 135 PFs Tela de entrada do código do estado alterada (3 PFs) Acrescentada interface arquivo N&A (10 PFs) Consulta N&A e ao código do estado acrescentadas (7 PFs) Nova tabela legal acrescentada (10 PFs) Relatório resumo incluído (5 PFs) Impacto Esforço Cronograma Custo + 1 mês + 2 semanas + $5000 + 0.5 meses + $2500 meses + 2.5 dias + $1250 Estimativas de Projetos – Carla A. Lima Reis

Benefícios de manter métricas (dados históricos)
Principal: aumenta a precisão das estimativas Ajuste das influências no projeto Evita subjetividade e otimismo infundado “produtividade não varia muito de projeto para projeto” (Putnam) Evita que discussões políticas afetem a estimativa métricas Estimativas de Projetos – Carla A. Lima Reis

Quais métricas coletar?
Tamanho Linhas de código, pontos por função, páginas web, tabelas de BD, classes, métodos Esforço Pessoas/mês, pessoas/hora Tempo Meses, dias, horas, semanas Defeitos Defeitos em código, em documentação, em especificação Estimativas de Projetos – Carla A. Lima Reis

Questões que influenciam métricas de tamanho:
Você conta todo o código fonte ou somente o código do produto final? (código de teste é contado?) Como é contado o código reutilizado? Como é contado o código open-source? ... Estimativas de Projetos – Carla A. Lima Reis

Questões que influenciam o esforço
Você conta tempo em horas, dias ou outra unidade? Quantas horas por dia são contadas? 8 horas ou somente as horas dedicadas ao projeto? Você conta feriados, treinamentos e férias? Você conta trabalho extra? Como se conta o tempo dividido em múltiplos projetos? Como contar o tempo que se gasta trabalhando em versões anteriores do mesmo software? Estimativas de Projetos – Carla A. Lima Reis

Questões de calendário
Quando o projeto inicia? Quando tem aprovação de orçamento? Ou quando começam as discussões sobre o mesmo? Quando o projeto termina? Quando é entregue para o usuário? Estimativas de Projetos – Carla A. Lima Reis

Questões sobre métricas de defeitos
Você conta todos os pedidos de mudança como defeitos? Múltiplas reclamações do mesmo defeito contam como um defeito ou vários? Você contabiliza defeitos detectados pelos desenvolvedores ou somente os defeitos apresentados pelos testadores? Você conta defeitos nos requisitos e projetos? São contados defeitos reportados pelo usuário Estimativas de Projetos – Carla A. Lima Reis

Lições sobre coleta de métricas
O gerente deve ter certeza que compreende o que está sendo coletado e que os dados coletados são consistentes A coleta de dados deve ser feita periodicamente durante execução do projeto Métricas do próprio projeto podem ser usadas para refinar as estimativas do restante do projeto ou de outros projetos Se você não tem dados históricos, comece a coletar agora mesmo! Estimativas de Projetos – Carla A. Lima Reis

Exemplo de coleta Projeto LOC Esforço (pessoas mês) $ (000) Pág. Doc. Erros (antes da entrega) Defeitos (depois da entrega) Pessoas Alfa 12.100 24 168 365 134 29 3 Beta 27.700 62 440 1.224 321 86 5 Gama 20.200 43 314 1.050 256 64 6 Estimativas de Projetos – Carla A. Lima Reis

Principais técnicas de estimativas

Principais abordagens para estimar software
Julgamento individual de especialista Decomposição e recomposição Estimativa por analogia Estimativa Proxy-Based Julgamento em grupos Estimativas de Projetos – Carla A. Lima Reis

Julgamento de especialista
O que é? Mais comum forma de estimativa Não necessariamente é informal ou intuitivo Quando? Pode ser usada do início ao fim do processo Para que? Melhor usada em estimativa bottom-up Por que? Quem tem mais experiência em uma atividade pode estimar com mais precisão Como? Deve ser solicitado o melhor e o pior caso da estimativa Estimativas de Projetos – Carla A. Lima Reis

O caso estimado pode ser calculado com fórmula PERT* Caso esperado = [Melhor caso + 4* caso_mais_provável) + pior caso] / 6 Funcionalidade Melhor caso (dias) Mais provável (dias) Pior caso (dias) Esperado (estimativa em dias) Func. 1 1,25 1,5 2,0 1,54 Func. 2 1,75 2,5 1,83 ... Total 10,5 13,25 18,25 13,62 *Program Evaluation and Review Technique Estimativas de Projetos – Carla A. Lima Reis

Importante: Compare seus resultados atuais com os estimados para aperfeiçoar as estimativas individuais Estimativas de Projetos – Carla A. Lima Reis

Decomposição/Recomposição
Decomposição: separar uma estimativa em pedaços, estimar cada parte individualmente e depois recompor a estimativa Também conhecida como bottom-up Estimar o esforço de um projeto inteiro é diferente de estimar o esforço para cada funcionalidade do mesmo. Quando se estima partes de um projeto, algumas estimativas erram para mais, outras para menos, e por isso em algum grau os erros são cancelados, melhorando a precisão da estimativa geral. Estimativas de Projetos – Carla A. Lima Reis

Exemplo de estimativa sem e com Decomposição
Funcio-nalidade (Esforço) Pessoas/Semana Func 1 1.5 Func 2 4,5 Func 3 3 Func 4 1 Func 5 4 Func 6 6 Func 7 2 Func 8 Func 9 Func 10 Total 27 Esforço real Erro 3 -1,5 2,5 2 1,5 4,5 -0,5 -1,0 0,5 3,5 -2,0 29 -2 Procurando Informações sobre Projetos similares: Total de 22 pessoas/semana Pedindo à equipe Para estimar esforço para cada Funcionalidade: Erro sem decomposição =24%, com decomp. = 7% Estimativas de Projetos – Carla A. Lima Reis

Decomposição/Recomposição
O uso de estimativa por decomposição deve aumentar junto com o progresso do projeto No início: funcionalidades gerais Depois: requisitos detalhados Finalmente: atividades do desenvolvedor Estruturar o projeto em atividades (processo) ajuda a estimar por decomposição (pode ser usada do início ao meio do projeto) Cuidado com estimativas de melhor caso de desenvolvedores! Eles tendem a ser otimistas! Estimativas de Projetos – Carla A. Lima Reis

Estimativa por analogia
Comparar um projeto novo com outro anterior Obter detalhes sobre tamanho, esforço e custo, juntamente com a decomposição de atividades Comparar o tamanho do novo parte a parte com o antigo Construir a estimativa de tamanho do novo como um percentual do antigo Estimar o esforço baseado no tamanho do novo, que já foi comparado com o antigo Checar consistências Estimativas de Projetos – Carla A. Lima Reis

Exemplo de estimativa por analogia (Obtendo detalhes e comparando)
Sistema A 1 BD 10 tabelas Interface 14 páginas web Gráficos e relatórios 10 gráficos + 8 relatórios Classes 15 Regras de negócio ?? Sistema A BD 5000LOC Interface 14KLOC Gráficos e relatórios 9KLOC Classes 4,5kloc Regras de negócio 11kloc Total 43,5KLOC 2 comparando Sistema B (novo) BD 14 tabelas Interface 19 páginas web Gráficos e relatórios 14 gráficos + 16 relatórios Classes 15 Regras de negócio ?? Estimativas de Projetos – Carla A. Lima Reis

Exemplo de estimativa por analogia (cont.)
3 Subsistema Tamanho do A Fator de multiplicação Tamanho estimado do B BD 5KLOC 1,4 7kloc Interface 14KLOC 19,6kloc Gráficos e relatórios 9KLOC 1,7 15,3kloc Classes 4,5kloc 1,0 Regras de negócio 11kloc 1,5 16,5kloc Total 43,5KLOC - 62,9kloc Estimativas de Projetos – Carla A. Lima Reis

Calculando esforço do novo projeto 4 esforço Tamanho do projeto B (novo) 62,9KLOC Tamanho do projeto A ÷ 43,5KLOC razão =1,45 Esforço do A X 30 pessoas/mês Esforço do B (novo) = 44 pessoas/mês Estimativas de Projetos – Carla A. Lima Reis

5 checando A consistência da estimativa pode ser influenciada por: Grande diferença de tamanho de um projeto para outro Diferença de tecnologias (ex: proj A em C++ e projeto B em Java) Diferenças grandes nos membros da equipe (para projetos pequenos) e nas habilidades da equipe (para projetos grandes) Diferença no tipo de aplicação (sistema de intranet versus sistema crítico embarcado) Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy-Based
Usadas no início do processo (ou início de iterações) Um bom estimador não faz estimativas precisas na parte mais ampla do cone da incerteza, mas precisa fazer alguma O cliente diz: “Como vou dizer se quero ou não esse requisito se você não sabe me dizer quanto ele custa?” Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy-Based
São úteis para criar estimativas do projeto como um todo ou de uma iteração completa. Não servem para estimativas tarefa a tarefa ou por features (características) detalhadas Consistem em identificar um proxy que esteja relacionado com o que se quer estimar e que seja mais fácil de estimar ou contar. Por exemplo, para estimar o número de casos de teste, pode-se correlacionar com o número de requisitos. Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy-Based Fuzzy Logic
Para estimativa de projeto em LOC Cada feature (característica) é classificada em: muito pequena, pequena, média, grande e muito grande. Depende de dados históricos calibrados da organização Dados históricos guardam quantas LOC em média uma feature de cada tipo precisa. Por exemplo: Tamanho da feature Média de LOC No. De features LOC estimado Muito pequenas 127 22 2794 Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy-Based Fuzzy Logic
Recomendações: Todas as features devem ser classificadas precisamente Os critérios para o tamanho da feature devem ser bem documentados e consistentes Não deve ser usado para saber tamanho de cada feature, apenas uma média do total. O método pode ser estendido para estimar esforço usando o mesmo raciocínio Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy-Based Componentes Padrão
Útil para estimar tamanho quando se desenvolve sistemas de arquitetura similar Como a estimativa é realizada: São identificados elementos relevantes para contagem em sistemas anteriores. Páginas web dinâmicas, páginas web estáticas, tabelas de BD, regras de negócio, gráficos, telas, diálogos, relatórios, etc. Apenas a média de LOC para cada componente desse tipo é computada Estimativas de Projetos – Carla A. Lima Reis

Exemplo de dados históricos: Componentes padrão Média de LOC por componente Páginas web dinâmicas 487 Páginas web estáticas 58 Tabelas de banco de dados 2437 Regras de negócio 8327 Estimativas de Projetos – Carla A. Lima Reis

Uso da fórmula PERT Caso esperado = [Melhor caso + 4* caso_mais_provável) + pior caso] / 6 Exemplo de Estimativa: Componente padrão LOC médio por componente Mínimo possível Mais provável Máximo possível Número estimado LOC estimado Página web dinâmica 487 11 25 50 26,8 13052 Pág. Web estática 58 20 35 40 33,3 1931 Tabelas de BD 2437 12 15 15,3 37286 Relatórios 288 8 12,7 3658 Regras de negócio 8327 - 1 Total 64254 Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy Based Story Points
Pode ser usada para estimar a cada iteração Para cada story (feature ou requisito) é dado um valor que represente seu tamanho (1, 2, 4, 8, 16) – apenas uma escala Após iteração 1: Story 1 2 Story 2 1 Story 3 4 27 story points desenvolvidos 12 pessoas/semana de esforço já realizado 3 semanas se passaram Calibragem: Esforço = 27 sp ÷ 12 pessoas/sem. = 2,25 story points/ pessoa_semana Cronograma = 27 ÷ 3(semanas) = 9 story points/semana Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy Based Story Points
Fazendo estimativa preliminar do projeto baseado na iteração 1 e sabendo que o projeto/próxima iteração tem 180 story points: Esforço = 180 sp ÷ 2,25story_points/pessoas_sem. = 80 pessoas_semana Cronograma = 180 ÷ 9 story points/semana = 20 semanas Estimativas de Projetos – Carla A. Lima Reis

Estimativa Proxy Based Tamanho de camiseta (T-Shirt sizing)
Usado para decidir quais features serão contratadas no início do projeto Os desenvolvedores classificam o tamanho das features necessárias como P, M, G, XG. Em paralelo, o cliente classifica o valor daquela feature usando a mesma escala. feature Valor para o negócio/cliente Custo de desenvolvimento Feature 1 G P Feature 2 Feature 3 Permite que o cliente decida não contratar feature 2 Estimativas de Projetos – Carla A. Lima Reis

Julgamento em grupos Técnica usada no início do projeto Dois tipos Revisões de grupo (não estruturada) Wideband Delphi (estruturada) Estimativas de Projetos – Carla A. Lima Reis

Julgamento em grupos Revisões de Grupo
Cada membro do grupo estima separadamente partes do projeto O grupo se reúne para discutir as estimativas, não somente para calcular sua média Deve-se chegar a um consenso aceito pelo grupo todo Dicas: 3 a 5 especialistas é suficiente Cada especialista deve ter formação ou cargo diferentes ou usar diferentes técnicas de estimativa Estimativas de Projetos – Carla A. Lima Reis

Julgamento em grupos Wideband Delphi (estruturado)
O coordenador apresenta a cada integrante a especificação do software e um formulário de estimativa Estimadores preparam suas estimativas separadamente As estimativas são discutidas em uma reunião Estimadores entregam suas estimativas anônimas para o coordenador O coordenador resume as estimativas média x x x x x x 5 10 15 20 Estimativas de Projetos – Carla A. Lima Reis

Exemplo de Resumo Estimativas de Projetos – Carla A. Lima Reis

O coordenador pede que os estimadores discutam as diferenças Estimadores votam anonimamente sobre aceitar ou não a média(se alguém disser não, voltar para passo 3) A estimativa final é o caso esperado ou um intervalo a partir da discussão Estimativas de Projetos – Carla A. Lima Reis

Dicas: Não é útil para atividades detalhadas É útil para estimar trabalhos em áreas novas, novas tecnologias ou novos tipos de software É útil na parte mais larga do cone da incerteza 0,25x 0,5x 0,67x 0,8x 1x 1,25x 1,5x 2x 4x Concepção aprovada produto Def. do completa requisitos Def. de completo Projeto de interface Projeto detalhado Software Estimativas de Projetos – Carla A. Lima Reis

O processo de Estimativa de Software

Processo de Estimativa de Software
Coletar requisitos iniciais Estimar tamanho Estimar esforço Produzir o cronograma Estimar os custos Aprovar estimativas Desenvolver o produto Re-estimar quando necessário Estimativas aprovadas Tamanho, esforço, etc. atuais Analisar o processo de estimativa Custos Recursos disponíveis Dados históricos Processo de Estimativa de Software Estimativas de Projetos – Carla A. Lima Reis

Linhas de código (LOC) Pontos por função Pontos por caso de uso ...
Estimativa de tamanho Linhas de código (LOC) Pontos por função Pontos por caso de uso ...

Medidas de tamanho Requisitos Use Cases Pontos por função Páginas web Componentes de interface (janelas, formulários, relatórios,...) Tabelas de BD Classes Funções/Métodos Linhas de código (LOC) Estimativas de Projetos – Carla A. Lima Reis

Linhas de Código (LOC) Vantagens LOC é um item de todos os artefatos e projetos de software Pode ser facilmente contado Muitos dados históricos já existem em LOC em várias empresas Permite comparação entre projetos A maioria das ferramentas de estimativas se baseia em LOC Estimativas de Projetos – Carla A. Lima Reis

Linhas de Código (LOC) Desvantagens: Dependência da linguagem de programação adotada Dificuldades de utilização em atribuição de tarefa individual pois produtividade é diferente entre pessoas Projetos que requerem maior complexidade podem ter a precisão da estimativa prejudicada. Não parece natural contar LOC para estimar atividades de requisitos, projeto e outras que ocorrem antes da implementação Projetos que utilizam várias linguagens são prejudicados Por exemplo: como medir projetos envolvendo SQL e Java? Seu uso na estimativa requer detalhes que são difíceis de se alcançar Isto é, o planejamento deve estimar o LOC a ser produzido muito antes que a análise e projeto tenham sido completados Estimativas de Projetos – Carla A. Lima Reis

Linhas de Código (LOC) Problema: qual o critério para medir? Empresa deve definir critério consistente public static void main(String [] args) { try { ident_usuario = desenho.login(i, p, u); } /* endtry */ catch(Exception e) { e.printStackTrace(); } /* endcatch */ } public static void main(String [] args) { try {ident_usuario = desenho.login(i, p, u);} catch(Exception e) {e.printStackTrace(); }}} Estimativas de Projetos – Carla A. Lima Reis

Pontos por Função Métrica orientada a função Medida do tamanho do software através da quantificação da funcionalidade oferecida aos usuários Somente componentes solicitados e visíveis ao usuário são considerados para dimensionar a aplicação Baseado nas informações do projeto de alto nível do sistema Independente da tecnologia utilizada para implementação Estimativas de Projetos – Carla A. Lima Reis

Pontos por Função Pergunta: Uma aplicação desenvolvida em C++ utilizando análise e projeto estruturado foi dimensionada em 1300 PF. Quantos PF terá a mesma aplicação desenvolvida em VB 6.0 com banco de dados Oracle e utilizando processo unificado? Por que? Estimativas de Projetos – Carla A. Lima Reis

Ponto por Caso de Uso É uma métrica orientada a função também Base na constatação: medida com PF exige experts Em sistemas orientados a objetos os casos de uso são a base do processo e são definidos desde o início do processo Efetua pagamento Pagto com Cartão de crédito Pagto com Débito em Conta Usuário Estimativas de Projetos – Carla A. Lima Reis

Estimativa de esforço

Como calcular o esforço?
Saiba: a Produtividade esperada Como? Tabela de produtividade padrão (ver tabela) Dados históricos Em que formato? HH/PF (homem_hora/ponto por função) HH/KLOC (homem_hora/ linhas de código) Obs: o denominador deve ser o mesmo usado para medir o tamanho. o tamanho do projeto (em PF ou KLOC ou outro) quantas horas por dia devem ser contadas (se o esforço for estimado em dias Fórmula: Esforço (homem/hora) = produtividade da equipe * Tamanho Estimativas de Projetos – Carla A. Lima Reis

Tabela de Produtividade

Exemplo de cálculo de esforço
Supondo: Tamanho = 87 pontos por função produtividade baixa (13,2HH/PF) Esforço (HH) = 87 * 13,2 = 1149 pessoas_horas Esforço(HD) = 87 * 13,2 /8 = 143 homens_dias Estimativas de Projetos – Carla A. Lima Reis

Estimativa de Prazo

Método para Estimativa de Prazo
- Estimativa de Esforço - Tamanho da Equipe - Consideração: 6 horas de trabalho/ dia Prazo (em dias) = Esforço (horas) /(Tam. equipe * 6) Estimativas de Projetos – Carla A. Lima Reis

Exemplo de Estimativa de Prazo
Exemplo: sistema com 87 pontos por função Com esforço calculado de 1149 HH Equipe: 1 analista e 1 programador (2 profissionais) horas por dia: 6 horas /dia Prazo = /(2 * 6) = 96 dias úteis (aproximadamente 4,4 meses) (Considerando 22 dias úteis por mês) Estimativas de Projetos – Carla A. Lima Reis

Evitando a Região Impossível
Observações: 1) Td é o tempo ótimo de desenvolvimento. 2) To é o tempo que acarreta o menor custo. 3) To = 2 Td. 4) É impossível terminar em menos que 0,75 * Td. Estimativas de Projetos – Carla A. Lima Reis

Estimando Prazos e Recursos a partir do Volume Usando a Aproximação de Capers Jones Td (meses) = V ** t, Onde: 1) Td é o tempo ótimo de desenvolvimento, em meses. 2) V é o volume em Pontos de Função. 3) t é um expoente que depende do ambiente computacional considerado. Estimativas de Projetos – Carla A. Lima Reis

Estimando Prazos partir do Volume Usando a Aproximação de Capers Jones 87 Região Impossível: 0 - 3,1 meses Td (meses) = V ** t, 4,2 meses Estimativas de Projetos – Carla A. Lima Reis

Estimativa dos custos

Exemplo de estimativa de custos
fixo Calc. automático Estimativas de Projetos – Carla A. Lima Reis

Decomposição do Ponto por função por atividade do ciclo de vida – esforço (fonte: Serpro)* Subprocessos % de distribuição Análise de requisitos 20% Análise e projeto 30% Implementação e teste 40% Disponibilização 10% Atividades % de distribuição Levantamento de dados 10% Projeto lógico 20% Projeto físico 25% Construção e testes 35% implantação Obs: pode servir para efeito de remuneração de sub-contratação Estimativas de Projetos – Carla A. Lima Reis *( Publicado em Vazquez et al, 2003)

Exemplo de estimativa de custos

Parte III Detalhamento Pontos por função e pontos por caso de uso

Estimativa de Tamanho Análise de Pontos por função

Pontos por função É uma medida de dimensionamento de software através da funcionalidade implementada em um sistema, sob o ponto de vista do usuário. Uma Visão do Usuário representa uma descrição formal das necessidades do negócio do usuário na linguagem do usuário. Proposto por (Albrecht 1979) Estimativas de Projetos – Carla A. Lima Reis

Objetivos da APF Medir o software através da quantificação da funcionalidade solicitada e adquirida pelo cliente, tendo como base primária o projeto lógico Medir o desenvolvimento e manutenção de software independentemente da tecnologia utilizada na implementação Medir o desenvolvimento e manutenção de software consistentemente em todos os projetos e organizações Estimativas de Projetos – Carla A. Lima Reis

Paradoxo clássico de produtividade
Linhas de Código Pontos de Função 25 25 Esforço Total (meses) 25 15 Custo Total $ $75.000 Custo por Linha de Código $12,50 $25,00 Linhas por Pessoa-mês PFs por Pessoa-mês 1,2 2 Custo por PF $5.000 $3.000 Estimativas de Projetos – Carla A. Lima Reis

Arquivos de Referência
Análise de PF Requisitos da aplicação são examinados para determinar a quantidade e complexidade das entradas, saídas, cálculos e bancos de dados necessários (características do sw) A partir de uma tabela de valores pré-definida, pontos são determinados para os valores das características do software. Telas Relatórios Arquivos Mestres Tamanho Arquivos de Referência Sinais Arquivos de Controle Estimativas de Projetos – Carla A. Lima Reis

Visão Geral de APF Estimativas de Projetos – Carla A. Lima Reis

Procedimento de Contagem
Contagem de PF Procedimento de Contagem Contar Funções de Dados Identificar Escopo de Contagem e Fronteira da Aplicação Determinar os PF Não Ajustados Determinar Tipo de Contagem Contar Funções Transacionais Calcular os PF Ajustados Determinar o Fator de Ajuste Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Determinar Tipo de Contagem TIPOS DE CÁLCULO DE PONTOS DE FUNÇÃO Contagem de PF de Projetos de Desenvolvimento - PF associados com a instalação inicial de um software novo Contagem de PF de Projetos de Manutenção - PF associados com a melhoria de um software já existente (inclui funcionalidade que é adicionada, modificada ou excluída) Contagem de PF de Aplicações - PF associados com uma aplicação instalada - Funcionalidade da aplicação no ponto de vista do usuário Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Determinar Tipo de Contagem TIPOS DE CÁLCULO DE PONTOS DE FUNÇÃO Estimativas de Projetos – Carla A. Lima Reis

A fronteira da aplicação indica o limite entre
Contagem de PF Identificar Escopo de Contagem e Fronteira da Aplicação A fronteira da aplicação indica o limite entre o software sendo medido e o usuário. Define o que é externo para a aplicação É a interface conceitual entre a aplicação “Interna” e o mundo do usuário “externo” Ponto de vista do usuário Baseada na funcionalidade do negócio, Não na implementação tecnológica Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Outras Aplicações Identificar Escopo de Contagem e Fronteira da Aplicação Interno APLICAÇÃO Usuário Estimativas de Projetos – Carla A. Lima Reis

Identificar Funções de Dados
Contagem de PF Contar Funções de Dados Identificar Funções de Dados Arquivos Lógicos Internos Funções de Dados Arquivos de Interface Externa Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções de Dados Funções de Dados Representam a funcionalidade fornecida para o usuário relativa aos requisitos de dados Internos (Arquivos Lógicos Internos) e Externos (Arquivos de Interface Externa) a Aplicação. Arquivo refere-se a um grupo de dados logicamente relacionados e não na implementação física deste grupo de dados. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos Lógicos Internos Contar Funções de Dados Definição São grupos de dados ou informações de controle especificados pelo usuário logicamente relacionados, cuja manutenção é efetuada dentro da fronteira da aplicação. Objetivo Principal Armazenar dados mantidos através de um ou mais processos elementares da aplicação sendo contada. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos Lógicos Internos Contar Funções de Dados Exemplos: Tabelas que armazenam dados mantidos pela aplicação; Arquivos de configuração mantidos pela aplicação; Arquivos de segurança de acesso (senha) mantidos pela aplicação; Arquivos de help, desde que mantidos pela aplicação; Arquivos de mensagens de erro mantidos pela aplicação; Dados de Histórico mantidos separadamente dentro da aplicação; Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos Lógicos Internos Contar Funções de Dados Não Exemplo: Arquivos Temporários ou várias Interações do mesmo arquivo Arquivos de Trabalho Arquivos de Sort (Classificação) Arquivos de View Arquivos de Índices Arquivos introduzidos devido a tecnologia Dados de Backup mantidos para Backup corporativo Arquivos mantidos por outra aplicação e somente referenciados Arquivos de relacionamentos, a menos que contenham atributos próprios mantidos separadamente Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos de Interface Externa Contar Funções de Dados Definição São grupos de dados ou informações de controle especificados pelo usuário logicamente relacionados, cuja manutenção é efetuada dentro da fronteira de outra aplicação Objetivo Principal Armazenar dados referenciados através de um ou mais processos elementares da aplicação sendo contada. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos de Interface Externa Contar Funções de Dados AIE - Exemplo: Dados de referência externa utilizados pela aplicação; Arquivos de help mantidos fora da aplicação; Arquivos de mensagens de erro mantidos fora da aplicação; Dados de password mantidos fora da aplicação Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Arquivos de Interface Externa Contar Funções de Dados AIE – Não Exemplo: Arquivos de movimento recebidos de outra aplicação para manter um ALI. Dados mantidos pela aplicação e utilizados por outra aplicação Dados formatados e processados para uso de outras aplicações Estimativas de Projetos – Carla A. Lima Reis

Classificar Funções de Dados
Contagem de PF Contar Funções de Dados Classificar Funções de Dados Classificação das Funções - de acordo com o número de Registros Lógicos e Itens de Dados: Simples Média Complexa Estimativas de Projetos – Carla A. Lima Reis

TABELA DE COMPLEXIDADE
Contagem de PF Contar Funções de Dados TABELA DE COMPLEXIDADE Estimativas de Projetos – Carla A. Lima Reis

Pontuação das Funções de Dados
Contagem de PF Pontuação das Funções de Dados Contar Funções de Dados SIMPLES MÉDIO COMPLEXO 7 PF 10 PF 15 PF PONTUAÇÃO DOS ARQUIVOS LÓGICOS INTERNOS SIMPLES MÉDIO COMPLEXO 5 PF 7 PF 10 PF PONTUAÇÃO DOS ARQUIVOS DE INTERFACE EXTERNA Estimativas de Projetos – Carla A. Lima Reis

Identificar Funções Transacionais
Contagem de PF Contar Funções Transacionais Identificar Funções Transacionais Entrada Externa Funções Transacionais Saída Externa Consulta Externa Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais Entradas Externas Definição Uma Entrada Externa é um processo elementar que processa dados ou informações de controle que vem do lado de fora da fronteira da aplicação. Objetivo Principal Manter um ou mais Arquivos Lógicos Internos e/ou alterar o comportamento do sistema. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais Entradas Externas EE - Exemplo: Transações que recebem dados externos para manutenção de ALI; Janela que permite adicionar, excluir e alterar registros em ALI. Nesse caso são três EE’s. Processamento em lotes de atualização de base cadastrais a partir de arquivos de movimento. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais Entradas Externas EE – Não Exemplo: Tela de filtro de relatórios e consultas; Menus; Telas de Login. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Saídas Externas Contar Funções Transacionais Definição Uma Saída Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Objetivo Principal Apresentar informação para um usuário através de processamento lógico adicional a recuperação de dados ou informação de controle. O processamento lógico deve conter no mínimo uma fórmula matemática ou cálculo, ou criar dados derivados. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Saídas Externas Contar Funções Transacionais SE - Exemplo: Relatórios com totalizações; Relatórios que também atualizam arquivos Consultas com apresentação de cálculos ou dados derivados Arquivo de movimento gerados para outra aplicação. Informações Gráficas. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Saídas Externas Contar Funções Transacionais SE – Não Exemplo: Telas de help; Consultas e relatórios sem totalizações e que não atualizam arquivos. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais Saídas Externas Observação Uma Saída Externa PODE também manter um ou mais Arquivos Lógicos Internos e/ou alterar o comportamento do sistema. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Consultas Externas Contar Funções Transacionais Definição Consulta Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. Objetivo Principal Apresentar informação para o usuário através da recuperação de dados ou informação de controle de um ALI ou AIE. O processamento Lógico NÃO contém fórmulas matemáticas ou cálculos, NÃO cria dados derivados. Além disso, NÃO mantém Arquivos Lógicos Internos durante o processamento, nem altera o comportamento do sistema. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Consultas Externas Contar Funções Transacionais CE - Exemplo: Telas de help; Telas de logon; Menu gerado dinamicamente com base em configuração da aplicação. CE – Não Exemplo: Menus estáticos; Relatórios e consultas com totalizações ou dados derivados. Estimativas de Projetos – Carla A. Lima Reis

Classificar Funções Transacionais
Contagem de PF Contar Funções Transacionais Classificar Funções Transacionais Classificação das Funções - de acordo com o número Arquivos Referenciados e Itens de Dados: Simples Média Complexa Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais EXEMPLO: ENTRADA EXTERNA FALE CONOSCO Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais EXEMPLO: CONSULTA EXTERNA Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Contar Funções Transacionais EXEMPLO: SAÍDA EXTERNA Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF EXEMPLO: CONSULTA EXTERNA SAÍDA EXTERNA Contar Funções Transacionais Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Entradas Externas Contar Funções Transacionais TABELA DE COMPLEXIDADE 1 a 4 5 a 15 16 ou mais itens de dados itens de dados itens de dados referenciados referenciados referenciados 1 arquivo SIMPLES SIMPLES MÉDIA referenciado 2 arquivos SIMPLES MÉDIA COMPLEXA referenciados 3 ou mais arquivos MÉDIA COMPLEXA COMPLEXA referenciados Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Saídas Externas Contar Funções Transacionais TABELA DE COMPLEXIDADE Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Consultas Externas Contar Funções Transacionais TABELA DE COMPLEXIDADE Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Pontuação das Funções Transacionais Contar Funções Transacionais SIMPLES MÉDIO COMPLEXO 3 PF 4 PF 6 PF Entradas Externas SIMPLES MÉDIO COMPLEXO 4 PF 5 PF 7 PF Saídas Externas SIMPLES MÉDIO COMPLEXO 3 PF 4 PF 6 PF Consultas Externas Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Tabela de Cálculo Determinar os PF Não Ajustados TIPO DE COMPLEXIDADE TOTAL TOTAL FUNÇÃO FUNCIONAL COMPLEX. TIPO FUNÇÃO ARQUIVO LÓGICO INTERNO SIMPLES X = MÉDIA X 10 = COMPLEXA X 15 = ARQUIVO DE INTERFACE EXTERNA SIMPLES X = MÉDIA X = COMPLEXA X 10 = SIMPLES X = ENTRADA EXTERNA MÉDIA X = COMPLEXA X = SIMPLES X = SAÍDA EXTERNA MÉDIA X = COMPLEXA X = SIMPLES X = CONSULTA EXTERNA MÉDIA X = COMPLEXA X = * * * TOTAL DE PONTOS DE FUNÇÃO NÃO - AJUSTADOS = Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Determinar o Fator de Ajuste Características Gerais dos Sistemas 8. Atualização “on-line” 9. Processamento Complexo 10. Reutilização de Código 11. Facilidade de Implantação 12. Facilidade Operacional 13. Múltiplos Locais 14. Facilidade de Mudanças 1. Comunicação de Dados 2. Processamento Distribuído 3. Performance 4. Utilização do Equipamento 5. Volume de Transações 6. Entrada de dados “on-line” 7. Eficiência do Usuário Final Atribui-se um peso de 0 a 5 para cada característica: 0- Nenhuma Influência Influência Média 1- Influência Mínima Influência Significativa 2- Influência Moderada Grande Influência Estimativas de Projetos – Carla A. Lima Reis

Comunicação de Dados 0 - O processamento da aplicação é puramente batch ou executado em um PC isolado. 1 - A aplicação é batch mas tem entrada de dados remota OU impressão remota. 2 - A aplicação é batch mas tem entrada de dados remota E impressão remota. 3 - Captura de Dados on-line via terminal de vídeo ou via um processador front-end , para alimentar processos batch ou Sistemas de Consultas 4 - Mais de um front-end, mas a aplicação suporta apenas um tipo de protocolo de comunicação. 5 - Mais de um front-end, mas a aplicação suporta mais de um tipo de protocolo de comunicação. Estimativas de Projetos – Carla A. Lima Reis

Processamento Distribuído 0 - A aplicação não efetua na transferência de dados ou processamento entre as CPUs da instalação. 1 - A aplicação prepara dados para o usuário final processar em outra CPU da instalação utilizando-se de software genérico (planilhas, editores de texto, banco de dados) 2 - Os dados são preparados para transferência, transferidos e processados em uma outra CPU da instalação. (Transferência de Arquivos) 3 - Processamento distribuído e transferência de dados on-line apenas em uma direção. (Processa numa CPU e transfere para outra CPU) 4 - Processamento distribuído e transferência de dados on-line em ambas direções.(Processamento cooperativo) 5 - A aplicação decide dinamicamente qual a CPU mais apropriada para executar a função. Estimativas de Projetos – Carla A. Lima Reis

Atualização de Dados On-Line 0 - Nenhuma atualização. 1 - Atualização on-line de 1 a 3 Arquivos de Controle. O volume de atualizações é baixo, e a recuperação de dados é fácil. 2 - Atualização on-line de 4 ou mais arquivos de controle. O volume de atualizações é baixo , e a recuperação de dados é fácil. 3 - Atualização on-line da maioria dos Arquivos Lógico Internos. 4 - Além dos itens anteriores, a proteção contra perda de dados é essencial, e foi especificamente projetada e codificada no sistema. 5 - Além dos itens anteriores, altos volumes de dados trazem considerações sobre custo para o processo de recuperação. Exigem procedimentos de recuperação totalmente automatizados, com a mínima intervenção do operador Estimativas de Projetos – Carla A. Lima Reis

Entrada de Dados On-Line 0 - Todas as transações são processadas em batch. 1 - 1% a 7% das transações são entradas dados interativas. 2 - 8% a 15% das transações são entradas de dados interativas. 3 - 16% a 23 % das transações são entradas de dados interativas. 4 - 24% a 30% das transações são entradas de dados interativas. 5 - Mais de 30% das transações são entradas de dados interativas Estimativas de Projetos – Carla A. Lima Reis

Volume de Transações 0 - Nenhum período de pico de transações é esperado. 1 - Picos de transações mensais, quadrimestrais, sazonais e anuais são esperados. 2 - Picos semanais de transações são esperados. 3 - Picos diários de transações são esperados. 4 - Altos volumes de transações foram fixados pelo usuário para a aplicação, o que força a execução de tarefas de análise de performance na fase de projeto da aplicação. 5 - Além das considerações acima, requer o uso de ferramentas de análise de performance nas fases de projeto, desenvolvimento e/ou implantação. Estimativas de Projetos – Carla A. Lima Reis

Eficiência do Usuário Final As funções “on-line” fornecidas enfatizam um projeto da aplicação voltado para a eficiência do usuário. Incluindo o seguinte: Navegação por Menus Documentação e/ou Help On-line Movimento automático do cursor Movimento da Tela (Scroll) vertical e horizontal Impressão remota (via transações on-line) Teclas de Função pré-definidas Seleção de dados na tela via movimentação do cursor Estimativas de Projetos – Carla A. Lima Reis

Eficiência do Usuário Final Submissão de jobs para execução em batch a partir de transações on-line Uso intensivo de vídeo reverso, brilho intensificado, sublinhado, cores e outros recursos de vídeo Cópia física da documentação do usuário de transações on-line Interface para mouse Pop-up Windows O mínimo possível de telas para executar as funções do negócio Fácil navegação entre telas (por ex:,através de teclas de função) Suporte bilíngüe Suporte multilinge Estimativas de Projetos – Carla A. Lima Reis

Eficiência do Usuário Final 0 - A aplicação não apresenta nenhum dos itens acima. 1 - Apresenta de 1 a 3 dos itens acima. 2 - Apresenta de 4 a 5 dos itens acima. 3 - Apresenta 6 ou mais itens acima, mas não há nenhum requerimento do usuário relacionado à eficiência. 4 - Apresenta 6 ou mais itens acima, e os requerimentos estabelecidos para eficiência do usuário são rigorosos o suficiente para que a fase de projeto da aplicação inclua fatores para minimizar a digitação, maximizar uso de defaults, templates etc. 5 - Apresenta 6 ou mais itens acima, e os requerimentos estabelecidos para eficiência do usuário são rigorosos o suficiente para que seja necessário o uso de ferramentas e processos especiais para demostrar que os objetivos de eficiência foram alcançados. Estimativas de Projetos – Carla A. Lima Reis

Processamento Complexo O processamento complexo é uma característica da aplicação, podendo ser dividido nas seguintes categorias: Processamento especial de auditoria e/ou processamento especial de segurança. Processamento lógico extensivo. Processamento matemático extensivo. Grande quantidade de processamento de exceções, resultando em transações incompletas que necessitam de reprocessamento, por exemplo, transações ATM incompletas causadas por interrupções de comunicação, valores de dados perdidos ou falha de edição. Processamento complexo para manipular múltiplas possibilidades de entrada/saída, por exemplo, multimidia e independência de dispositivos. Estimativas de Projetos – Carla A. Lima Reis

Processamento Complexo Classificar o Nível de Influência de acordo com a tabela abaixo: 0 - Não apresenta nenhum dos itens acima. 1 - Apresenta um dos itens acima. 2 - Apresenta dois dos itens acima. 3 - Apresenta três dos itens acima. 4 - Apresenta quatro dos itens acima. 5 - Apresenta todos dos itens acima. Estimativas de Projetos – Carla A. Lima Reis

Facilidade de Implantação 0 - Nenhuma consideração especial foi feita pelo usuário, e nenhum procedimento especial foi requerido para a implantação. 1 - Nenhuma consideração especial foi feita pelo usuário, mas um procedimento especial foi requerido para a implantação. 2 - Requerimentos de implantação e conversão de dados foram fixados pelo usuário, e roteiros de implantação e conversão de dados foram preparados e testados. O impacto da conversão de dados no projeto não é considerado importante. 3 - Requerimentos de implantação e conversão de dados foram fixados pelo usuário, e roteiros de implantação e conversão de dados foram preparados e testados. O impacto da conversão da dados no projeto é considerado importante. 4 - Além do descrito no item (2), ferramentas automatizadas de implantação e conversão de dados foram fornecidas e testadas. 5 - Além do descrito no item (3), ferramentas automatizadas de implantação e conversão de dados foram fornecidas e testadas Estimativas de Projetos – Carla A. Lima Reis

Múltiplos Locais 0 - Nenhuma solicitação do usuário para considerar a necessidade de instalar a aplicação em mais de um local. 1 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar somente em ambientes idênticos de hardware e software. 2 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar somente em ambientes similares de hardware e software. 3 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar inclusive em ambientes diferentes de hardware e/ou software. 4 - Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos locais, e a aplicação atende aos itens (1) e (2). 5 - Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos locais, e a aplicação atende ao item (3). Estimativas de Projetos – Carla A. Lima Reis

Facilidade de Mudanças 0 - Nenhum requerimento especial foi solicitado pelo usuário para projetar a aplicação, visando minimizar ou facilitar mudanças. 1-5 - Selecionar quais dos seguintes itens se aplicam à aplicação. É fornecido recurso de consulta/relatórios flexível capaz de manipular solicitações simples de consulta (contar como um item). É fornecido recurso de consulta/relatórios flexível capaz de manipular solicitações de consulta média complexidade (contar como dois itens). É fornecido recurso de consulta/relatórios flexível capaz de manipular solicitações complexas de consulta (contar como três itens). Dados de controle são mantidos em tabelas que são atualizadas pelo usuário através de processos on-line e interativos, mas as alterações só são efetivadas no próximo dia útil. Dados de controle são mantidos em tabelas que podem ser atualizadas pelo usuário através de processos on-line e interativos, e as alterações só são efetivadas imediatamente (contar como dois itens). Estimativas de Projetos – Carla A. Lima Reis

Facilidade Operacional 0 - Nenhuma consideração especial sobre facilidade operacional, além dos procedimentos normais de backup, foi feita pelo usuário. Selecionar os seguintes itens que se aplicam à aplicação. Cada item selecionado possui o valor um. Procedimentos eficientes de inicialização, backup e recuperação foram preparados, mas a intervenção do operador é necessária. Procedimentos eficientes de inicialização, backup e recuperação foram preparados, mas nenhuma intervenção do operador é necessária (contar como dois itens). A aplicação minimiza a operação de montagem de fitas magnéticas A aplicação minimiza a necessidade de manuseio de formulários. 5 - A aplicação foi projetada para não precisar de intervenção do operador no seu funcionamento normal. Apenas a inicialização e parada do sistema ficam a cargo do operador. A recuperação automática de erros é uma característica da aplicação. Estimativas de Projetos – Carla A. Lima Reis

Performance 0 - Nenhuma exigência especial de performance foi fixada pelo usuário. 1 - Requerimentos de performance foram estabelecidos e revisados, mas nenhuma ação especial foi necessária. 2 - O tempo de resposta é crítico durante as horas de pico. Nenhuma consideração especial para utilização de CPU foi requerida.O intervalo de tempo limite do processamento é sempre p/ o próximo dia útil. 3 - O tempo de resposta é crítico durante todo o horário de utilização . Não foi necessário nenhum procedimento especial para utilização de CPU. Os requerimentos de prazo de processamento com outros sistemas são limitantes. 4 - Os requerimentos de performance estabelecidos pelo usuário são rigorosos o bastante para requerer tarefas de análise de performance na fase de análise e desenho da aplicação. 5 - Além do descrito no item 4, ferramentas de análise de performance foram usadas nas fases de desenho, desenvolvimento e/ou implementação a fim de proporcionar a performance estabelecida pelo usuário. Estimativas de Projetos – Carla A. Lima Reis

Utilização do Equipamento 0 - Não há restrições operacionais explícitas ou implícitas. 1 - Existem restrições operacionais, mas são menos restritivas do que aplicações típicas. Nenhum esforço extra é necessário para suplantar as restrições. 2 - Algumas considerações sobre tempo e segurança são necessárias. 3 - Necessidades especiais de processador para uma parte específica da aplicação. 4 - Restrições operacionais estabelecidas requerem atenção especial a nível de processador central ou processador dedicado para executar a aplicação. 5 - Além do descrito acima, existem sobrecargas a nível das unidades de processamento (CPUs) distribuídas da instalação. Estimativas de Projetos – Carla A. Lima Reis

Reutilização de Código 0 - Não apresenta código reutilizável. 1 - O código reutilizável é usado somente dentro da própria aplicação. 2 - Menos de 10% da aplicação foi feita, levando-se em conta a sua utilização por outras aplicações. 3 - 10% ou mais da aplicação foi feita, levando-se em conta a sua utilização por outras aplicações. 4 - A aplicação foi projetada e documentada para facilitar a reutilização de código, e a aplicação é customizada pelo usuário a nível de código fonte. 5 - A aplicação foi projetada e documentada para facilitar a reutilização de código. Sua customização (parâmetros ) pode ser atualizada pelo usuário. Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Determinar o Fator de Ajuste Cálculo do Fator de Ajuste Nível de Influência Total (NIT) NIT =  NI Características Gerais do Sistema FATOR DE AJUSTE (FA) FA = ( NIT * 0,01 ) + 0,65 Estimativas de Projetos – Carla A. Lima Reis

Contagem de PF Calcular os PF Ajustados Cálculo de PFs Ajustados - Cálculo de PF de um Projeto de Desenvolvimento PF_DESENVOLVIMENTO = PF_NÃO_AJUSTADO * FATOR_AJUSTE - Cálculo de PF de um Projeto de Manutenção PF_MANUTENÇÃO = ((PF_INCLUÍDO + PF_ALTERADO)* FA_ATUAL) + (PF_EXCLUÍDO*FA_ANTERIOR) Estimativas de Projetos – Carla A. Lima Reis

Exemplo Trabalhador Gerente Efetuar Logon Registrar Acompanhar
Presença Registrar Presença Emitir Relatório de Presença <<extend>> Registrar Justificativa Estimativas de Projetos – Carla A. Lima Reis

Exemplo Modelo de Classes: Modelo ER:
Pertencente ao sistema “Controle de Segurança” Modelo ER: Estimativas de Projetos – Carla A. Lima Reis

Exemplo Determinação das Funções Tipo Dados: Pessoa (AIE) Campos: matricula, nome, senha e tipo (gerente/trabahador). Obs: Esse arquivo pode ter outros campos, mas conta-se só os que são usados no sistema de ponto Registros: 1 (o próprio) Ponto (ALI) Campos: matricula, data, horário entrada, horário saída. Justificativa (ALI) Campos: matricula, data, justificativa. Estimativas de Projetos – Carla A. Lima Reis

Determinação das Funções Tipo Transação: Exemplo Logon (SE) – Saída externa por ter senha criptografada Campos: matrícula, senha, mensagens, comando (ex: botão ok). Arquivo Referenciado: Pessoa. Registro de Ponto (EE) Campos: Indicador de entrada ou saída, mensagens, comando. Arquivo Referenciado: Ponto. Consulta Ponto Diário (CE) Campos: data do ponto, horário entrada, horário saída, mensagens, comando. Ponto com Justificativa (EE) Campos: Indicador de entrada ou saída , horário, justificativa, mensagens, comando. Arquivo Referenciado: Ponto, Justificativa. Estimativas de Projetos – Carla A. Lima Reis

Exemplo Determinação das Funções Tipo Transação (cont.): Exclusão de Ponto (EE) Campos: mensagens, comando. Arquivo Referenciado: Ponto, Justificativa. Alteração de Ponto (EE) Campos: Horário Anterior, Horário Novo, mensagens, comando. Acompanhar Presença (SE) Campos: data inicial, data final, total de horas do período, nome do trabalhador, data do ponto, horário do ponto, indicador de entrada ou saída, justificativa, mensagens, comando. Arquivo Referenciado: Ponto, Justificativa, Pessoa. Emitir Relatório de Presença (SE) Campos: data inicial, data final, matrícula, nome, total de horas do trabalhador, nº de justificativas, total de horas geral,mensagens, comando. Arquivo Referenciado: Ponto, Justificativa, Pessoa Estimativas de Projetos – Carla A. Lima Reis

Função Tipo TD AR/TR Complexidade Contribuiçao Pessoa AIE 4 1 Baixa 5 Ponto ALI 7 Justificativa 3 Logon SE Consulta Ponto diário CE Registro de Ponto EE Ponto com Justificativa 2 Média Ponto - Exclusão Ponto - Alteração Acompanhar Presença 10 Emitir Relatório de Presença 9 50 Exemplo Estimativas de Projetos – Carla A. Lima Reis

Exemplo Considerando FA = 0,9 PF = 50 * 0,9 = 45 Estimativas de Projetos – Carla A. Lima Reis

7 10 15 5 7 10 3 4 6 3 4 6 4 5 7 Resumo da Contribuição Funcional
Estimativas de Tamanho Resumo da Contribuição Funcional FUNÇÃO SIMPLES MÉDIA COMPLEXA Arquivo Lógico Interno 7 10 15 Arquivo de Interface Externa 5 7 10 3 4 6 Entrada Externa 3 4 6 Consulta Externa 4 5 7 Saída Externa Estimativas de Projetos – Carla A. Lima Reis

Segundo o Modelo de Dados e Interfaces:
Contagem Indicativa - NESMA Segundo o Modelo de Dados e Interfaces: Utilizaremos a “Contagem Indicativa” (NESMA) A técnica assume que cada arquivo lógico (10 ptos.) terá: inclusão, alteração e exclusão (3 x 4 = 12 ptos.) 1 relatório (5 ptos.) 2 consultas (2 x 4 = 8 ptos.) Estimativas de Projetos – Carla A. Lima Reis

Contagem Indicativa - NESMA Fórmula 1 (sem Interfaces): PF = Qtd Arquivos Lógicos * 35 Considerando que as Interfaces (7 ptos.) tenham: 2 consultas (2 x 4 = 8 ptos.) Fórmula 2 (completa): PF = (Qtd. Arq. Lógicos * 35) + (Qtd. Interfaces * 15) Estimativas de Projetos – Carla A. Lima Reis

EXEMPLO: SISTEMA COM 3 ARQUIVOS INTERNOS
Contagem Indicativa - NESMA EXEMPLO: SISTEMA COM 3 ARQUIVOS INTERNOS PF = Nº de ALIs x 35 + Nº de AIEs x 15 PF = 3 x x15 = 105 TOTAL DE PONTOS DE FUNÇÃO NÃO-AJUSTADOS = 105 Para simplificar, supondo FATOR DE AJUSTE = 1, TEMOS: PONTOS DE FUNÇÃO AJUSTADOS = 105 *1 = 105 Estimativas de Projetos – Carla A. Lima Reis

Considerações sobre pontos por função
Desafios O aplicador deve ser treinado Deve existir uma baseline Baseline: linha básica com resultados históricos contextualizados do desempenho da organização de desenvolvimento de software avaliada Ex: produtividade Estimativas de Projetos – Carla A. Lima Reis

Pontos de Função: razões para sucesso Em 1986: Int’l Function Point Users Group (IFPUG) Em 2002: Norma ISO 20926 Muitas organizações investiram no levantamento e armazenamento de grande quantidade de dados sobre projetos envolvendo PFs Nenhuma outra métrica alcançou o mesmo nível de utilização Estimativas de Projetos – Carla A. Lima Reis

O que se pode obter com PF? Métricas de Produtividade Produtividade = tempo gasto trabalhando / PFs Exemplo: 900 hs / 400 PFs = 2,25 hs de trabalho/ponto de função Estimativas de Esforço/Duração Cálculo do esforço em PFs Tempo = produtividade x esforço Custo Custo / Ponto de Função Defeitos Defeitos / Ponto de Função Estimativas de Projetos – Carla A. Lima Reis

Relação entre LOC e PF (aproximada) Linguagem de Programação LOC/FP (média) Linguagem de máquina 320 C 128 COBOL 106 FORTRAN Pascal 90 C++ 64 Ada95 53 Visual Basic 32 Java 22 SmallTalk PowerBuilder 16 SQL 12 Estimativas de Projetos – Carla A. Lima Reis

Estimativa de tamanho Pontos por caso de uso

Pontos por Caso de Uso Criados por Gustav Karner em 1993 como uma adaptação específica de PFs Ponto de partida: diagramas de caso de uso Base na constatação: medida com PF exige experts Efetua pagamento Pagto com Cartão de crédito Pagto com Débito em Conta Usuário Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso As contagens de UCP podem variar Entre organizações e indivíduos Em razão dos diferentes estilos de casos de uso O sucesso depende de um estilo comum para especificação de casos de uso não existem padrões para construção de casos de uso Não há como garantir que UCP estão medindo a mesma coisa se os critérios para construção de casos de uso forem diferentes Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso O processo Ponderando Atores Ponderando Casos de Uso Ponderando Fatores Técnicos Ponderando Fatores de Equipe e do Ambiente Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando atores (1) Simples – originam programas simples de interface (carga) com outros sistemas ou cadastros simples. Exemplo: um ator “Sistema de Faturamento”, que será acessado pelo caso de uso “Repor Estoque” apenas para realizar uma consulta no cadastro de notas fiscais, exibindo os itens faturados e respectivas quantidades. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando atores (2) Médio – são programas de interface com outros sistemas que envolvem a recepção, interpretação, tratamento e envio de informações e interfaces interativas (transações interativas médias); ou existe uma pessoa interagindo através de um terminal com interface não gráfica. Exemplo: um ator “Sistema de Faturamento”, que será acessado pelo caso de uso “Repor Estoque”, realizando consulta no cadastro de notas fiscais para exibir os itens faturados e respectivas quantidades. Envolve também consulta ao estoque mínimo de cada produto listado, e apontamento dos itens que necessitam ter pedido de compra por atingir estoque mínimo. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Atores (3) Complexo – interfaces gráficas com alta interatividade com o usuário. Exemplo: um ator “Sistema de Faturamento”, que será acessado pelo caso de uso “Repor Estoque”, realizando consulta no cadastro de notas fiscais para exibir os itens faturados e respectivas quantidades. Envolve também consulta ao estoque mínimo de cada produto listado, gerando um pedido de compra automático para os itens que atingiram o estoque mínimo, com posterior envio de solicitação de aprovação pelo responsável. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Atores (4) Totalizando as informações Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Casos de Uso (1) Complexidade do Caso de Uso está diretamente relacionado com o negócio e a implementação esperada do Caso de Uso. Classificação: simples, médio e complexo. Não devem ser considerados Casos de Uso resultados de “include” e “extend” (razão não muito clara) A base para a ponderação dos Casos de Uso deve ser o número de transações em um Caso de Uso, incluindo aquelas definidas nos caminhos alternativos. Exemplo: uma transação para um sistema de faturamento envolve a inclusão da nota fiscal e dos itens da nota fiscal: ou são incluídos registros em ambas as entidades de dados, ou não há inclusão. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Casos de Uso (2) Alternativa para determinar a complexidade do caso de uso: Número de Classes Envolvidas Tipo de Caso de Uso Número de Classes Simples Menos que 5 Médio 5 a 10 Complexo Mais do que 10 Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Casos de Uso (3) Totalizando Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Fatores Técnicos Estimativas de Projetos – Carla A. Lima Reis

Pontos por caso de uso Ponderando fatores técnicos
T1 – Sistemas Distribuídos: avaliar se o desenvolvimento em questão será distribuído e requer alta interação para a consolidação ou replicação de informações. Sistemas distribuídos podem ter esforço extra, por exemplo, para determinar e tratar chaves de distribuição do banco de dados, “espelhamento” de entidades para segurança, estratégias de distribuição, etc. Por exemplo, nota 1 – porque não se planeja distribuir o primeiro release. T2 – Tempo de resposta/desempenho: ponderar a criticidade do tempo de resposta e requisitos de desempenho para o desenvolvimento em questão. Pode demandar tempo, por exemplo, para realização de testes/ensaios durante as primeiras iterações, que podem acarretar desnormalizações do banco de dados, alteração de rotinas, etc. Por exemplo, nota 3 – porque a velocidade será limitada pela entrada de dados humana. T3 – Eficiência (on-line): ponderar a necessidade da eficiência das telas on-line. Avalia a expectativa do usuário final em relação à interface a ser criada para o desenvolvimento em questão. Por exemplo, nota 5 – porque necessita de muita eficiência. T4 – Processamento interno complexo: avaliar se o processamento interno do desenvolvimento em questão é complexo ou mais trivial, por exemplo, cálculos, regras de consistências, lógica de decisão, análise de informações. Processamentos complexos demandam profissionais mais treinados/experientes e podem aumentar o esforço necessário para realização dos testes. Por exemplo, nota 1 – porque o processamento interno é trivial. T5 – Código deve ser reutilizável: avaliar reusabilidade de rotinas ou serviços. Caso positivo, serão necessários esforços extras para garantir alta coesão e baixo acoplamento, além da necessidade de profissionais mais treinados/experientes. Por exemplo, nota 1 – seria interessante, mas houve avaliação tardia. T6 – Facilidade de instalação: avaliar como será realizada a instalação do produto, uma vez construído. Pode demandar esforço extra para criação de dispositivos de instalação amigáveis, sendo replicado em várias instalações, ou o software deverá ser instalado sem apoio técnico local. Por exemplo, nota 5 – porque precisa ser de fácil instalação para pessoas sem conhecimento técnico de TI. Estimativas de Projetos – Carla A. Lima Reis

Pontos por caso de uso Ponderando fatores técnicos
T7 – Usabilidade: avaliar facilidade de uso. Caso sejam necessárias facilidades de uso por profissionais não técnicos, pode necessitar esforço relativo a estudos de ergonomia. Por exemplo, nota 5 – porque precisa ser de fácil utilização por pessoas sem conhecimento técnico de TI. T8 – Portabilidade: avaliar grau de relevância para troca de plataformas, pois pode impedir a utilização de padrões que simplificam codificação e aumentam produtividade, além de eventualmente provocarem problemas de performance, acarretando esforço extra. Um exemplo seria a necessidade de utilização do padrão ANSI para SQL, impedindo uso de dialetos SQL. Por exemplo, nota 1 – porque inicialmente não é necessário. T9 – Facilidade de manutenção: o código deve ser gerado com clareza, estruturação, parametrização e documentação, permitindo um alto índice de manutenções evolutivas. Por exemplo, nota 3 – porque requer uma facilidade de manutenção relativa, uma vez que não é esperado um volume evolutivo grande, ou produto tem ciclo de vida relativamente curto. T10 – Acessos simultâneos: avaliar se haverá muitos acessos simultâneos a bases de dados ou serviços de aplicação; neste caso, envolve esforço extra para projetar, desenvolver e testar transações concorrentes. Note que sistemas multi-usuários devem ser avaliados neste quesito. Por exemplo, nota 5 – porque a aplicação não tem acesso concorrente, mas é multi-usuário. T11 – Aspectos especiais de segurança: avaliar se será necessário algum tratamento extra de segurança ou se será apenas o habitual. Pode acarretar esforço extra para projetar, desenvolver e testar os aspectos especiais de segurança, como controle de accesso, segregação de uso de comandos, controle de visibilidade de informações, etc. Por exemplo, nota 3 – porque requer grau de segurança padrão. T12 – Acesso direto para terceiros: avaliar se será necessário, por exemplo, acesso por clientes. Em caso afirmativo, considerar bastante relevante, pois pode envolver aspectos de ergonomia – neste caso, seria um complemento ao item T7. Por exemplo, nota 5 – porque precisa ser acessado pelos clientes. T13 – Facilidades especiais de treinamento: avaliar como será realizado o treinamento dos usuários do produto, pois pode demandar esforço extra para geração de material de treinamento diferenciado. Por exemplo, nota 1 – porque a aplicação é simples demais. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Fatores de Equipe e do Ambiente Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Fatores de Equipe e do Ambiente
F1 – Familiaridade com o processo: indica se a equipe do projeto conhece e já utiliza o Processo de desenvolvimento de software. Por exemplo, nota 1 – porque a maior parte da equipe do projeto não é familiar com o processo definido. F2 – Experiência na Aplicação: indica se a equipe do projeto conhece a aplicação do desenvolvimento em questão. Por exemplo, nota 1 – porque a maior parte da equipe é de programadores juniores. F3 – Experiência na Técnica Estruturada ou OO: indica se a equipe do projeto conhece a técnica que será utilizada no desenvolvimento. Por exemplo, nota 1 – porque a maior parte da equipe é de analistas juniores, que não têm experiência prática com Orientação a Objetos. F4 – Experiência do Líder de Projeto em gestão: indica a experiência que o líder para o projeto em questão possui. Por exemplo, nota 5 – porque o José da Silva (líder do projeto) tem muitos projetos de sucesso que liderou no passado. F5 – Motivação: indica se a equipe do projeto tem motivação para trabalhar no projeto em questão. Por exemplo, nota 5 – porque a equipe do projeto ficou bastante empolgada com a importância do projeto para os clientes. F6 – Requisitos estáveis: indica a probabilidade de os requisitos serem estáveis. Por exemplo, nota 5 – porque não são esperadas mudanças para o projeto em questão. F7 – Trabalhadores com dedicação parcial: indica se haverá trabalhadores em período não integral. Para este quesito, nota (1) indica pouco ou nenhum colaborador de período não integral. Por exemplo, nota 1 – porque todos os trabalhadores estão alocados “full-time” ao projeto. F8 – Dificuldade da Linguagem de Programação: indica a dificuldade da linguagem de programação que será utilizada pelo projeto em questão. Para este quesito, (1) indicará que a linguagem é de pouca complexidade e/ou que a equipe de projeto tem domínio completo sobre a mesma. Por exemplo, nota 2 – porque o projeto será codificado utilizando MS Visual Basic – a linguagem padrão da Organização. Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Fator de esforço Estimativas de Projetos – Carla A. Lima Reis

Pontos por Caso de Uso Ponderando Fator de esforço A produtividade (horas-homem por ponto de caso de uso) é dada em função da soma dos fatores com valor “alto”. Considerando: Quantidade de fatores F1 a F6 com nota menor que 3 = Q1 e Quantidade de fatores F7 a F8 com nota maior que 3 = Q2, Quando: Q1 + Q2 <= 2, o valor sugerido é de 20 HH/PCUA; 3 <= Q1 + Q2 <= 4, o valor sugerido é de 28 HH/PCUA; Q1 + Q2 >= 5, a planilha exibe o Fator HH = 0, indicando que os riscos do projeto estarão “acima do gerenciável”; neste caso, sugere-se ao gerente que as características do projeto sejam revistas em razão do alto risco O número obtido em HH ou HD representa o valor total estimado para o esforço a ser demandado pelo projeto. Para saber o tempo dedicado a cada fase é importante ter uma idéia da distribuição percentual de esforço ao longo das fases do processo. Estimativas de Projetos – Carla A. Lima Reis

Exemplo de aplicação da técnica Pontos por caso de uso

Exemplo de aplicação Pontos por caso de uso
Os atores: Cliente e o Mídia – complexos, pois são atores que interagem fortemente com o sistema e com o uso de Interfaces Gráficas dinâmicas Checking de Mídia, Atendimento e Veículos – são atores de complexidade média, pois demandam interações com as GUI´s Os sistemas FATURAMENTO/ AUDIÊNCIA / ALCANCE&FREQUENCIA / PLANVIEW são atores do tipo integração com outros sistemas que exigem programas de complexidade média para a sua integração Os sistemas da PREÇO exige um programa simples de carga, logo é um ator do tipo simples Estimativas de Projetos – Carla A. Lima Reis

Quanto aos Casos de Uso classificamos: Ranking, Geração do Plano de Mídia e Geração de PI – como Casos de Uso complexos do ponto de vista de negócio Geração da Recomendação, geração das planilhas, obtenção das AP´s , a geração do faturamento e a Confirmação da Veiculação são Ucases de complexidade de negócio médias A Análise das Planilhas e a Avaliação das planilhas são Casos de Uso de complexidade simples Estimativas de Projetos – Carla A. Lima Reis

139 139 Estimativas de Projetos – Carla A. Lima Reis

Recomendações finais

Estilos de apresentação de estimativas
Comunicando suposições Expressando incerteza Usando intervalos Estimativas de Projetos – Carla A. Lima Reis

Estilos de apresentação de estimativas Comunicando suposições
Documentar as suposições do projeto: Requisitos Não requisitos Necessidade de maior elaboração em alguns requisitos Disponibilidade de recursos (pessoas) Dependência do trabalho de terceiros Principais itens desconhecidos Influências da estimativa Quão boa é a estimativa Para que ela pode ser usada Estimativas de Projetos – Carla A. Lima Reis

Estilos de apresentação de estimativas Comunicando suposições (exemplo) Estimativa do Projeto X A estimativa de cronograma geral é de 6 meses, com 25% de precisão. Esta estimativa pode ser usada como base para o orçamento, porém não para fazer promessas fora da organização. A estimativa foi baseada nas seguintes suposições: Os três principais líderes técnicos estarão alocados 100% ao projeto a partir de 15 de março. Toda a equipe de desenvolvimento e teste estará alocada para o projeto a partir de 15 de abril de 2006. O subsistema de formatação dos gráficos será sub-contratado e recebido com qualidade adequada em 01 de agosto. Não serão requisitadas alterações nas regras do negócio. O tamanho da integração requerida com o sistema A é desconhecido. Esta estimativa alocou 250 pessoas-hora para esse serviço. Se for necessário mais do que isso a estimativa do projeto como um todo será alterada. Não mais que 5 novos relatórios serão requeridos pelo cliente; Novas ferramentas de desenvolvimento a serem utilizadas nesse projeto melhorarão a produtividade da equipe em 20% ou mais, comparado com outros projetos anteriores; A equipe terá menos dias sem trabalho por doença em média porque a maior parte do projeto ocorre no verão. Após as datas de disponibilidade citadas nos itens 1 e 2, a equipe não será re-solicitada para atender versões anteriores do software O projeto irá reutilizar pelo menos 80% do código de BD da versão 2.0 sem modificações. Em caso de mudanças nessas suposições, a estimativa será revisada. Estimativas de Projetos – Carla A. Lima Reis

Estilos de apresentação de estimativas Expressando incerteza
Usar quantificadores + e – 6 meses ± 2meses R$ ,00, + R$ ,00, -R$ ,00 Incluir o desvio padrão nos quantificadores Estimativas de Projetos – Carla A. Lima Reis

Quantificando riscos (apenas os principais) Combina quantificadores ± com as suposições Estimativa: 6 meses, + 5 meses, - 1 mês Impacto Descrição do risco +1,5 mês A versão precisa de mais 20% de requisitos comparada a versão anterior +1 mês Subsistema de formatação de gráfico entregue com atraso + 1 mês Novas ferramentas de desenvolvimento não funcionam conforme previsto Não é possível reutilizar 80% do BD da versão anterior +0,5 mês Taxa de doença da equipe não é menor conforme suposição -0,5 mês Todos os desenvolvedores alocados em 1 de abril Novas ferramentas de desenvolvimento funcionam melhor que o esperado Estimativas de Projetos – Carla A. Lima Reis

Fatores de confiança Qual a chance de terminar em uma data? Evitar usar 90% de confiança ou mais Data de entrega Probabilidade de entregar até essa data 15 de janeiro 20% 01 de março 50% 01 de novembro 80% Estimativas de Projetos – Carla A. Lima Reis

Fatores de confiança Melhorando a visualização Estimativas de Projetos – Carla A. Lima Reis

Como defender suas estimativas?
Problema: Equipe técnica tende a ser introvertida Negociação ocorre entre técnico e executivos Influências políticas Esteja ciente das influências externas da meta. Deixe claro que compreende essa importância O que se pode negociar? Não se negocia estimativa. É possível negociar promessas relacionadas à estimativa. Estimativas de Projetos – Carla A. Lima Reis

Exemplo de negociação: Técnico: “Nossa estimativa é de 5 a 7 meses. Estamos no início do cone da incerteza, então ainda podemos melhorar essa estimativa enquanto trabalhamos Executivo: O intervalo de 5 a 7 meses é muito grande. Por que não usamos a estimativa de 5 meses? Técnico: “É importante distinguir entre estimativa e promessa. A estimativa eu não posso mudar, porque foi resultado de análise e vários cálculos. Mas eu posso fazer com que minha equipe prometa terminar em 5 meses se concordarmos em levar em consideração esse risco.” Executivo: “Não entendi. Qual a diferença?” Técnico: “o intervalo de 5 a 7 meses inclui um desvio padrão de 50/50 de uma estimativa de 6 meses. Significa que temos 84% de chance de terminar em 7 meses. E apenas 16% de chance de terminar em 5 meses.” Executivo: “Nós precisamos de mais de 50% de chance na data a prometer, porém 84% é muito conservador. Qual data seria seria 75% provável? Técnico: mais ou menos 6,5 meses. Executivo: “Então vamos prometer esse prazo!” Estimativas de Projetos – Carla A. Lima Reis

Trate as discussões sobre estimativas como resolução de problemas e não negociação....Todos ganham ou todos perdem. (McConnel, 2006) Ataque o problema, não as pessoas. Negocie a quantidade de funcionalidades se a meta for rígida. Estimativas de Projetos – Carla A. Lima Reis

Dicas e opções Mova algumas funcionalidades para a versao 2 Use abordagem iterativa e faça primeiro as principais funcionalidades Corte os requisitos mais caros Use o método do tamanho da camiseta para tratar os requisitos mais importantes Adicione mais desenvolvedores e testadores somente no início do projeto Adicione pessoal administrativo Aumente o nível de envolvimento do usuário Aloque recursos 100% para o projeto Calibre a produtividade da equipe em uma ou duas iterações e então faça promessas baseado nisso Estimativas de Projetos – Carla A. Lima Reis

Insista em usar critérios objetivos Promessas Estimativas Metas! estimador Cliente/executivo não técnico Estimativas de Projetos – Carla A. Lima Reis

Sites relacionados Estimativas de Projetos – Carla A. Lima Reis

Referências Center for Software Engineering ( Barry Boehm): ttp://sunset.usc.edu/research/COCOMOII/ Boehm, Barry, et al. Software Cost Estimation with Cocomo II. Addison Wesley, 2000. Project Management Institute: Jones, C. Patterns of large software systems: failure and success Computer, Vol.28, Iss.3, Mar 1995; Pages: 86-87 Jones, Capers. Applied Software Measurement. McGraw-Hill. 2nd Edition, 1996. Robert N. Charette. Why Software Fails. IEEE Spectrum (Set/2005). Stellman, A.; Greene, J. Applied Software Project Management. O’Reilly Vazquez, C. E.; Simões, G.; Albert, R. Análise de Pontos por função: Medição, Estimativas e Gerenciamento de Projetos de Software. 2ª edição Ed. Erica, 2003. Florac, W.; Carleton, A. Measuring the Software Process. Addison Wesley, 1999. McConnel, Steve. Software Estimation: Desmystifying the Black Art. Microsoft Press, 2006. Software Project Estimation by Kathleen Peters, Software Productivity Center Inc., 1999 Humphrey, Watts. A Discipline for Software Engineering. Addison Wesley, 1995. Software Productivity Center Inc. (SPC), Estimativas de Projetos – Carla A. Lima Reis

Métricas e Estimativas de Projetos de Software

Apresentações semelhantes

Apresentação em tema: "Métricas e Estimativas de Projetos de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Métricas e Estimativas de Projetos de Software

Apresentações semelhantes

Apresentação em tema: "Métricas e Estimativas de Projetos de Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback