Engenharia de Software
Haroldo Amaral ([email protected])
Aula 06 – Planejamento de Projetos
Visão Geral
Processo de Planejamento
Plano de Projeto
Marcos e Produtos
Cronograma de Projeto
Estimativas de Custo
Visão Geral
Inicie com uma declaração explícita do trabalho a ser feito e verifique se corresponde ao que o cliente espera
Em projetos médios e grandes,
criam-se subprojetos menores e os estima separadamente
Baseie suas estimativas em dados
históricos de projetos semelhantes
Visão Geral
Registre suas estimativas para
comparar com os resultados reais no final do projeto
Planejamento continua durante o desenvolvimento e manutenção
Planejamento inicial não é suficiente
Planejamento detalhado só ocorre
Visão Geral
Visão Geral
Uma das mais recentes é a baseada em casos de uso
Há várias técnicas para estimar o esforço (tamanho) exigido no desenvolvimento de
um produto de software
Visão Geral
Planejamento acontece em três estágios do ciclo de vida de um
projeto:
• Proposta
• Fase inicial do projeto
• Por todo o desenvolvimento
do projeto
Visão Geral
Na proposta, a intenção é criar um contrato entre cliente e empresa desenvolvedora
Para tal, um plano deverá ser definido para:
Investigar se temos os recursos necessários
Definir o preço a ser cobrado
O planejamento é especulativo, uma vez que não temos uma definição precisa dos
requisitos
Baseado numa descrição de alto nível das funcionalidades
Porém, ele deve ser “confiável”
Visão Geral
Para a definição do preço, estimativas, através de técnicas, devem ser consideradas
Qual o “esforço” necessário para executar cada atividade do projeto?
A partir disso, calcular o custo total das atividades
Estimativa de custos não é uma tarefa simples de ser executada, pois envolve vários fatores,
devendo-se ter em mente custo + lucro
Parâmetros:
Custos de esforços
Custos de hardware e software, incluindo manutenção
Custos viagens e treinamentos
Visão Geral
Custos de esforços
Custo do trabalho das pessoas envolvidas por mês
Envolvem, também:
Custos de subsistência, aquecimento e iluminação no espaço de escritório
Custos de pessoal de apoio como contadores,
administradores, gerentes de sistema, faxineiros, técnicos
Custos de operações de infra-estrutura de comunicação
Custos de instalações centrais
Custos de seguridade social e benefícios
Embora as informações sejam limitadas, deve-se fornecer uma boa estimativa
Para efeitos de contingência, caso as estimativas sejam
Visão Geral
Custos de hardware são relativamente
baratos, porém os de software podem ser significativamente mais caros
Custos de viagem são necessários quando o projeto é desenvolvido em diversos lugares
Podem ser reduzidos, através do uso de sistemas
de conferência eletrônica
Visão Geral
Entretanto, a atribuição de preço de software pode levar em conta considerações mais amplas
Questões organizacionais, econômicas, políticas e de negócios
Portanto, pode não haver um relacionamento
simples entre o preço do software e os custos de desenvolvimento
Por essas questões, a atribuição de preço de projeto deve envolver a gerência sênior (os que tomas
decisões estratégicas), bem como os gerentes de
Visão Geral
Fator Descrição
Oportunidades de negócio
Uma organização de desenvolvimento pode cotar um preço baixo porque deseja entrar no mercado
Incerteza de
estimativa de custo
Se a empresa está insegura na sua estimativa de custo, ela pode aumentar o preço com lucro bem acima do normal e alguma contingência
Termos contratuais Um cliente pode permitir que o desenvolvedor
mantenha a propriedade sobre os códigos-fontes e reusá-los em outros projetos
Volatilidade de requisitos
Se os requisitos vão mudar, uma organização pode diminuir seu preço para ganhar um contrato. Depois disso, pode ser cobrado um valor mais alto
Saúde financeira Desenvolvedores com dificuldades financeiras podem
diminuir seus preços para ganhar um contrato,
Visão Geral
Uma vez que o contrato seja firmado, o plano de projeto deverá ser refinado, a fim de se obter um plano da fase inicial do projeto
Nesse estágio, os requisitos são mais bem conhecidos, embora possa não haver uma especificação completa
O plano deverá ser usado para tomar decisões, durante todo o desenvolvimento do projeto
O plano deve também definir mecanismos de monitoramento do projeto para:
Verificar o progresso real do projeto, comparando com as estimativas iniciais
Atualizar estimativas de custo e de prazo, e rever os
Visão Geral
O Plano de Projeto
sempre evolui
O Processo de Planejamento
O gerenciamento eficiente depende de um
planejamento minucioso do progresso do projeto
Os gerentes devem prever os problemas que podem ocorrer e preparar soluções
Um plano preparado no início do projeto deve ser usado como guia
Esse plano inicial deve ser o melhor possível em face das informações disponíveis
As metas da empresa constituem um importante fator que deve ser considerado na formulação do plano de projeto
À medida que essa metas mudam, as metas do projeto também mudam
O plano deve evoluir à medida que o projeto progride e
O Processo de Planejamento
O planejamento é um
PROCESSO iterativo e concluído apenas quando o projeto é
finalizado. À medida que as informações se tornam
disponíveis, o plano vai sendo
revisado regularmente
O Processo de Planejamento
No início, devem ser avaliadas restrições que afetam o projeto
• Data de entrega, pessoal disponível, orçamento geral, ...
Juntamente, devem ser estimados os parâmetros do projeto
• Estrutura, tamanho e distribuição de funções
Em seguida, definição dos marcos de
progresso e os produtos a serem entregues
O Processo de Planejamento
O processo, então,
entra num loop
O Processo de Planejamento
Um cronograma é elaborado e as atividades definidas são iniciadas ou liberadas para prosseguimento
Depois de algum tempo (duas ou três semanas), deve ser examinado o progresso e anotar as discrepâncias em relação ao cronograma
Devido às estimativas iniciais dos parâmetros do projeto serem experimentais, sempre será
necessário modificar o plano original
O Processo de Planejamento
À medida que as informações se tornam disponíveis, as hipóteses originais e o cronograma do projeto devem ser revisadas
Se o projeto estiver atrasado, pode ser necessário
renegociar as restrições e os produtos a serem entregues com o cliente
Se essa renegociação não for bem sucedida e o cronograma não puder ser cumprido, uma revisão técnica pode ser
considerada
• O objetivo dessa revisão é encontrar uma abordagem alternativa que
se limite às restrições do projeto e cumpra o cronograma
Defina as restrições do projeto
Faça a avaliação inicial dos parâmetros do projeto
Defina os marcos do projeto e os produtos a serem entregues while projeto não for concluído ou cancelado loop
Elabore um cronograma do projeto
Inicie as atividades de acordo com o cronograma Aguarde (por um período)
Examine o progresso do projeto
Revise as estimativas de parâmetros do projeto Atualize o cronograma do projeto
Renegocie as restrições do projeto e os produtos a serem entregues if (surgirem problemas) then
Inicie revisão técnica e possível nova revisão end if
end loop
Defina as restrições do projeto
Faça a avaliação inicial dos parâmetros do projeto
Defina os marcos do projeto e os produtos a serem entregues while projeto não for concluído ou cancelado loop
Elabore um cronograma do projeto
Inicie as atividades de acordo com o cronograma Aguarde (por um período)
Examine o progresso do projeto
Revise as estimativas de parâmetros do projeto Atualize o cronograma do projeto
Renegocie as restrições do projeto e os produtos a serem entregues if (surgirem problemas) then
Inicie revisão técnica e possível nova revisão end if
end loop
O Processo de Planejamento
O Processo de Planejamento
Para executar o
planejamento de um
projeto de software, o que precisamos
construir?
O Plano de Projeto
Documento que define o trabalho que e como deve ser feito
Estabelece os recursos disponíveis para o projeto, a estrutura analítica do projeto e um cronograma para realizar o trabalho
Serve de benchmark para comparar com projetos anteriores, quando documentado apropriadamente
Pode ser único, incluindo diferentes tipos de
planos, ou fazer referências a planos separados
O Plano de Projeto
Plano Descrição
Plano de Qualidade Descreve os procedimentos e os padrões de qualidade usados no projeto
Plano de Validação Descreve a abordagem, os recursos e o cronograma usados para a validação do sistema
Plano de Gerenciamento de Configuração
Descreve os procedimentos e as estruturas de gerenciamento de configuração a serem usados
Plano de Manutenção Prevê os requisitos de manutenção do
sistema, os custos de manutenção e os
esforços necessários
O Plano de Projeto
Para o desenvolvimento do plano, devemos
considerar:
• Recursos
• Tarefas
O Plano de Projeto
Recursos Tarefas
Pessoas
Ricardo, Larissa, João, Márcia e Alberto (com Especialidades)
Software
JBuilder, .NET
(quantidade e versões)
Hardware
Laptop, PC, PDA
Entrevistar cliente CL
Fazer uma Reunião
Projetar a GUI G i
Criar o relatório R
Atualizar o site
Testar método M da classe C
...
O Plano de Projeto
E como um plano de projeto é
estruturado?
O Plano de Projeto
1. Introdução Descreve brevemente os objetivos do projeto e estabelece as
restrições (orçamento, prazo, ...) que afetam o gerenciamento do projeto
2. Organização do projeto Descreve o modo como a equipe de desenvolvimento está organizada, as pessoas envolvidas e seus papéis na equipe
3. Análise de riscos Descreve os possíveis
riscos do projeto, a probabilidade da
O Plano de Projeto
4. Requisitos de recursos de hardware e software Especificam o hardware e software de apoio necessários para realizar o desenvolvimento
5. Estrutura analítica Estabelece a estrutura analítica do projeto em atividades e identifica os marcos e os produtos a serem entregues com cada atividade
6. Cronograma de projeto Apresenta as dependências entre as atividades, o prazo estimado necessário para
atingir cada marco e a alocação de pessoas nas atividades
7. Mecanismos de monitoração e elaboração de
relatórios Definem os relatórios de gerenciamento que
devem ser produzidos, quando eles devem ser produzidos
e os mecanismos de monitoração de projeto usados
Marcos e Produtos
Os gerentes precisam de informações para realizar seu trabalho
Como o software é intangível, essas
informações podem ser fornecidas, por
exemplo, como relatórios e documentos que descrevam o estado do software
Sem essas informações, é impossível avaliar o
progresso do trabalho e, conseqüentemente,
as estimativas de custos e cronograma não
Marcos e Produtos
Para tal, deve-se estabelecer uma série de MARCOS (MILESTONES)
Um marco é um ponto final de uma atividade do processo de software e deve representar o fim de um estágio lógico e
distinto do projeto
Marcos indefinidos, como “Codificação 80% concluída”, que não podem ser verificados, são inúteis para o
gerenciamento do projeto
Não se pode verificar se esse estado foi alcançado, pois a quantidade de código que ainda precisa ser desenvolvida é incerta
Para cada marco, deve existir uma saída formal, como um relatório, que possa ser apresentado à gerência
Os relatórios de marcos não precisam ser extensos
Podem ser relatórios simples e breves sobre o que foi concluído
Marcos e Produtos
Um PRODUTO (DELIVERABLES) é um resultado de projeto entregue ao cliente
Geralmente, é disponibilizado no fim de alguma fase importante do projeto, como especificação ou projeto
Os produtos são geralmente marcos
Porém, marcos não precisam ser, necessariamente, produtos
Os marcos podem ser resultados internos do projeto
usados pelo gerente para verificar o progresso do
O Cronograma do Projeto
Tarefa difícil e complexa, onde tempo e recursos necessários são estimados para concluir as
atividades
As atividades são organizadas numa seqüência coerente
Para projetos similares, a experiência serve como base para as estimativas
Devido a imprevistos, os cronogramas devem ser continuamente atualizados à medida que mais informações sobre o progresso se tornem
disponíveis
O Cronograma do Projeto
O desenvolvimento do cronograma envolve a
divisão do trabalho total em atividades separadas e a avaliação do tempo necessário para completar essas atividades
Algumas atividades podem ser executadas simultaneamente
As atividades paralelas devem ser coordenadas e o trabalho deve ser organizado para a distribuição de esforços otimizada
Atrasos na conclusão de tarefas críticas podem
O Cronograma do Projeto
O processo:
O Cronograma de Projeto
As atividades de projeto devem durar, pelo menos, uma semana
Uma subdivisão mais detalhada significa que uma quantidade desproporcional de tempo deve ser despendida na estimativa e na revisão de
diagramas
É útil também estabelecer uma quantidade máxima de tempo para qualquer atividade (8 a 10 semanas)
Se levar mais tempo que isso, deverá ser
O Cronograma de Projeto
No planejamento de um cronograma:
Não se deve considerar que todo estágio do projeto estará livre de problemas
Pessoas ficam doentes, saem do projeto, ...
Hardware pode apresentar defeitos
Software e hardware de apoio podem atrasar na entrega
Se o projeto for novo e tecnicamente avançado, certas partes podem se tornar mais difíceis e tomar mais
tempo
Deve-se considerar os recursos necessários para completar cada tarefa
Pessoas
Espaço em disco no servidor
O Cronograma de Projeto
Cronogramas de projeto podem ser representados por diagramas que apresentam:
A estrutura analítica do projeto
As dependências de atividades
As alocações de pessoal
Ferramentas de gerenciamento de projetos, como o Microsoft Project (
http://www.microsoft.com/project/) e o
OpenProj (http://openproj.org/), podem ser
O Cronograma de Projeto
01/03/2011 Engenharia de Software
41
DIAGRAMAS DE BARRAS e REDES DE
ATIVIDADES são notações gráficas usadas para ilustrar o cronograma do projeto
Os diagramas de barra mostram quem é
responsável por cada atividade e quando as atividades estão programadas para serem iniciadas e finalizadas
As redes de atividades mostram dependências entre as diferentes atividades que constituem um projeto
Eles podem ser gerados automaticamente,
usando uma ferramenta de gerenciamento de
O Cronograma de Projeto
Exemplo:
Tarefa Duração (dias) Dependências
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1(M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
O Cronograma de Projeto
Exemplo:
A Tabela anterior mostra um conjunto de atividades, suas durações e
interdependências
Em face das dependências e das durações estimadas das atividades, um diagrama de atividades pode ser gerado
Esse diagrama mostrará:
Quais atividades podem ser realizadas simultaneamente
Quais atividades devem ser executadas em
seqüência devido a dependências de atividades
O Cronograma de Projeto
Exemplo:
Por convenção, nesse diagrama:
As atividades são representadas por retângulos
Os marcos e os produtos a serem entregues são representados por retângulos de cantos
arredondados
As datas desse diagrama mostram a data de início
da atividade
O Cronograma de Projeto
Exemplo:
start
T2
M3 T6
Finish T10
T5 M7 T7
T4 M2
M5
T8 4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99 15 days 11/8/99
25 days 10 days 20 days
5 days 25/7/99
15 days
25/7/99
18/7/99 10 days
T1
M1 T3
T9
M6
T11
M8
T12 M4
O Cronograma de Projeto
Exemplo:
Na ferramenta de gerenciamento usada para produzir esse diagrama, todas as atividades devem terminar em marcos
Uma atividade pode ser iniciada quando seu marco precedente (que pode depender de várias atividades) for atingido
Antes de passar de um marco para outro,
todos os caminhos que levam a ele precisam estar completos
No exemplo, quando as atividades T3 e T6 forem
terminadas, a atividade T9 pode começar
O Cronograma de Projeto
Exemplo:
01/03/2011 Engenharia de Software
47
O tempo mínimo necessário para terminar o projeto pode ser estimado considerando-se o caminho mais longo (caminho principal) no gráfico de atividades
No caso do exemplo, isso corresponde a 11 semanas de tempo decorrido (ou 55 dias trabalhados)
Para o exemplo, na figura da rede de atividades, o caminho principal é mostrado como uma
seqüência de caixas tracejadas
O caminho principal é a seqüência de
atividades dependentes que define o tempo necessário para concluir o projeto
O cronograma geral do projeto depende do
O Cronograma de Projeto
Exemplo:
Atrasos no término de qualquer atividade causa atrasos no projeto, uma vez que as atividades seguintes não podem ser iniciadas até que a atividade em atraso tenha sido terminada
Atrasos nas atividades que não estão no caminho principal não causam necessariamente atraso geral no cronograma
Desde que esses atrasos não estendam as atividades, de modo que o tempo total para as suas execuções não excedam o tempo do caminho principal, o cronograma do projeto não será afetado
Por exemplo, se T8 estiver atrasada por duas semanas, ela não irá afetar a data final do projeto, pois não está no caminho
principal
O Cronograma de Projeto
Inevitavelmente, os cronogramas iniciais de projeto são incorretos
À medida que o tempo avança, as estimativas devem ser comparadas com o tempo real
decorrido
Essa comparação pode ser usada como base para revisão de cronograma para as partes posteriores do projeto
Quando os valores reais são conhecidos, o diagrama de atividades deve ser revisado
As atividades posteriores poderão, depois, ser
reorganizadas para reduzir a extensão do
O Cronograma de Projeto
Uma forma complementar para representação das informações de cronograma de projeto é feita através de um diagrama de barras (ou diagrama de Grantt)
Esse diagrama mostra um calendário de projeto e as datas de início e fim das
atividades
Ao ser lido da esquerda para a direita, o
O Cronograma de Projeto
Exemplo:
O Cronograma de Projeto
Exemplo:
Algumas das atividades mostradas no
diagrama de barras são seguidas por uma barra sombreada, cujo comprimento é
calculado pela ferramenta de cronograma
Essa barra sombreada demonstra a flexibilidade de data de término das atividades
Se uma atividade não for concluída em tempo, o caminho principal não será afetado até o fim do período indicado pela barra sombreada
As atividades no caminho principal não têm
O Cronograma de Projeto
Além de considerar os cronogramas, os gerentes de projeto também precisam considerar a alocação de pessoas às atividades do projeto
As pessoas não precisam estar designadas a um projeto durante todo o tempo
Essa alocação pode também ser a entrada
para as ferramentas de gerenciamento e para
um diagrama de barras que mostre quando o
pessoal é designado ao projeto
O Cronograma de Projeto
Exemplo:
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4
T8 T11
T12 T1
T3
T9 T2
T6 T10
T7
T5 Fred
Jane
Anne
Mary
Jim
Estimativas de Custo
A estimativa envolve respostas às seguintes questões:
• Quanto esforço será necessário para completar cada atividade?
• Quanto tempo será necessário para completar cada atividade?
• Qual será o custo total de cada
unidade?
Estimativas de Custo
As estimativas de custo e prazo são, normalmente, realizadas em conjunto
Como vimos, os custos de desenvolvimento são primariamente os custos de esforço
O cálculo do esforço é usado para ambas as estimativas, de custo e de cronograma
Contudo, é possível fazer uma estimativa de custo antes que os cronogramas detalhados sejam elaborados
Essas estimativas iniciais podem ser usadas
para estabelecer um orçamento para o projeto
Estimativas de Custo
As estimativas de produtividade são baseadas em medições de atributos de software e em divisão desses atributos pelo esforço total necessário para o seu desenvolvimento
Duas métricas:
Relacionadas ao tamanho Associadas ao
tamanho de algum resultado de uma atividade
Linhas de código-fonte, ou número de instruções ou número de páginas de documentação
Relacionadas a funções Associadas à funcionalidade geral do sistema
Pontos de função e pontos de objeto
Estimativas por Pontos de Casos de Uso
A técnica de análise de dimensão por Casos de Uso foi criada para permitir a possibilidade de estimar o
tamanho do sistema ainda na fase de levantamento dos Casos de Uso
Sistemas Orientados a Objetos usam diagramas de Casos de Uso para descrever suas funcionalidades de
acordo com a forma de utilização por parte dos
usuários
Estimativas por Pontos de Casos de Uso
Baseada em dois métodos:
• Mecanismo de Pontos de Função (PF)
• Metodologia conhecida
como Mk II – uma adaptação
Estimativas por Pontos de Casos de Uso
Trata de estimar o tamanho de um sistema de acordo com:
• O modo como os usuários o utilizarão
• A complexidade de ações solicitadas por cada tipo de usuário
• Uma análise em alto nível dos
Estimativas por Pontos de Casos de Uso
Uma vez levantados os Casos de Uso
“principais” do sistema, é possível estimar- se o tamanho do software como um todo
Baseada num conjunto simples de métricas
e modificadores
Estimativa por Pontos de Casos de Uso
Então, que Casos de Uso utilizar?
Preocupação em medir somente Casos de Uso no nível do sistema (funcionais), onde seja possível diferenciar transações e interações com o usuário
Casos de Uso de nível muito alto – modelagem do negócio do sistema – e de nível muito baixo – interações do usuário com a interface do sistema – não são adequados para a
O grau de detalhe dos Casos de Uso analisados influencia diretamente
na qualidade final da medição
O grau de detalhe dos Casos de Uso analisados influencia diretamente
na qualidade final da medição
Estimativa por Pontos de Casos de Uso
Então, na maioria dos casos, cabe aos analistas decidir a “granularidade” ideal dos Casos de
Uso utilizados para a medição
A inexatidão na escolha dos Casos de Uso é a principal falha metodologia A inexatidão na escolha dos Casos de
Uso é a principal falha metodologia
O Método de Cálculo
1º ma iste o S s d re Ato os so d Pe o ndo cula Cal •
2º so e U s d Caso os so d Pe o ndo cula Cal •
3º juste e A s d tore Fa cos ndo écni s T cula ore Fat Cal • •
Fat • ore
s A mb
ient ais
4º ma iste S do rte Po o ndo cula Cal •
O Método de Cálculo
Calculando o Peso dos Atores do Sistema
Consiste em classificar os Atores envolvidos em cada Caso de Uso, de forma a obter um somatório de pontos não-ajustado
O peso total dos atores do sistema (UAW – Unadjusted Actor Weight) é calculado pela
soma dos produtos do número de atores
de cada tipo pelo respectivo peso
O Método de Cálculo
Calculando o Peso dos Atores do Sistema
Tipo de Ator Peso Descrição
Ator Simples 1 Outro sistema acessado através de uma API de programação
Ator Médio 2 Outro sistema interagindo através de um protocolo de comunicação, como TCP/IP ou FTP
Ator
Complexo
3 Um usuário interagindo através de
uma interface gráfica ( stand-alone
O Método de Cálculo
Calculando o Peso dos Atores do Sistema
Por exemplo:
Para um sistema projetado para dois tipos de
usuários (gerente e usuário comum) e que fosse acessado por outro sistema usando um protocolo de comunicação, qual seria o valor UAW?
8 (2 atores – gerente e usuário comum – de nível
“complexo” e 1 ator – sistema acessando via protocolo
de comunicação – de nível “médio”)
O Método de Cálculo
Calculando o Peso dos Casos de Uso – 1ª Forma
Uma vez calculado o peso dos Atores, parte-se para o cálculo inicial do peso bruto dos Casos de Uso (UUCW – Unadjusted Use Case Weight)
Para efeitos de cálculo, os casos de uso são divididos em três níveis de complexidade, de acordo com o número de transações
envolvidas em seu processamento
Entende-se por transação como uma série de
processos que devem ser garantidamente
O Método de Cálculo
Calculando o Peso dos Casos de Uso – 1ª Forma
O cálculo do UUCW é realizado como no cálculo de peso dos atores
Somam-se os produtos da quantidade de casos de uso classificados em cada tipo pelo peso nominal do tipo em questão
Tipo de Caso de Uso
No de Transações Peso
Simples Até 3 1
Médio De 4 a 7 2
Complexo 7 ou mais 3
O Método de Cálculo
Calculando o Peso dos Casos de Uso – 2ª Forma
Uma segunda forma de se calcular o peso dos casos de uso do sistema é levar em
consideração o número de classes envolvidas no processo
O cálculo é realizado da mesma forma que na
abordagem anterior, podendo ser aplicado quando já for possível antever as entidades envolvidas
num dado processo Tipo de Caso de Uso
No de Entidades Peso
Simples 5 ou menos 1
Médio De 5 a 10 2
O Método de Cálculo
Peso Total Não-Ajustado
Considerando o UAW e o UUCW calculados anteriormente, o peso total não ajustado (UUCP – Unajusted Use Case Points) é
calculado pelo somatório entre os pesos de atores e casos de uso
UUCP = UAW +
UUCW
O Método de Cálculo
Calculando Fatores de Ajuste
O método de ajuste é constituído de duas partes:
Um cálculo de FATORES TÉCNICOS, cobrindo uma série de requisitos funcionais do sistema
Um cálculo de FATORES AMBIENTAIS, requisitos não funcionais associados ao processo de
desenvolvimento, como:
Experiência da equipe, motivação, estabilidade do projeto, dentre outros
Esses dois fatores geram multiplicadores
distintos, que devem ser aplicados ao peso
O Método de Cálculo
Calculando Fatores de Ajuste
Os dois modificadores utilizam-se de um mesmo mecanismo de pesos
Para cada requisito listado, deve-se atribuir um valor que determina a influência do requisito no sistema, variando de 0 a 5
Valor 0 indica nenhuma influência
Valor 3 indica influência moderada
Valor 5 indica forte influência
O Método de Cálculo
Calculando Fatores Técnicos de Ajuste
Fator Requisito Peso
T1 Sistema distribuído 2
T2 Tempo de Resposta 2
T3 Eficiência 1
T4 Processamento complexo 1
T5 Código reusável 1
T6 Facilidade de instalação 0.5
T7 Facilidade de uso 0.5
T8 Portabilidade 2
T9 Facilidade de mudança 1
T10 Concorrência 1
T11 Recursos de segurança 1
Para calcular o fator de
complexidade técnica do sistema
(TCF – Technical Complexity
Factor), usamos a
seguinte tabela:
O Método de Cálculo
Calculando Fatores Técnicos de Ajuste
O cálculo do TCF é feito pela seguinte fórmula:
O valor TFator é obtido pelo somatório dos níveis de influência atribuídos a cada fator multiplicados pelo seu peso correspondente
TCF = 0.6 + (0.01 * TFator)
O Método de Cálculo
Calculando Fatores Ambientais de Ajuste
Para calcular o fator ambiental do
sistema (EF – Environment Factor), usamos a
seguinte tabela:
Fator Descrição Peso
E1 Familiaridade com RUP ou outro processo formal
1.5 E2 Experiência com a aplicação
em desenvolvimento
0.5 E3 Experiência em Orientação a
Objetos
1 E4 Presença de analista
experiente
0.5
E5 Motivação 1
E6 Requisitos estáveis 2
E7 Desenvolvedores em meio- expediente
-1
O Método de Cálculo
Calculando Fatores Ambientais de Ajuste
No caso dos Fatores Ambientais, o nível de influência indica o nível de disponibilidade de cada recurso no decorrer do projeto
Dessa forma, determinar que um dado fator possui nível de influência alto significa dizer que esse fator está presente no projeto como um todo e influencia seu desenvolvimento
Da mesma forma, atribuir um valor de influência zero a um fator indica que o mesmo não está presente no processo de desenvolvimento
Por exemplo, um grau de influência 0 atribuído ao fator E3 indica uma equipe com total desconhecimento de OO,
enquanto que o grau 5 indica a disponibilidade de uma
equipe experiente nesse paradigma
O Método de Cálculo
Calculando Fatores Ambientais de Ajuste
O cálculo do TCF é feito pela seguinte fórmula:
O valor EFator é dado pela soma dos produtos entre o peso de cada fator e seu grau de
influência atribuído
EF = 1.4 + (-0.03 * EFator)
O Método de Cálculo
Calculando o Porte do Sistema
Finalmente, podemos calcular o valor total do sistema em Pontos de Caso de Uso (UCP – Use Case Points) pela seguinte fórmula:
UCP = UUCP * TCF * EF
O Método de Cálculo
Considerações
Podemos estimar o tempo necessário para o
desenvolvimento do projeto calculando-se uma média de 20 pessoas-horas de trabalho por Ponto de Caso de Uso
Porém, experiências demonstram uma variação entre 15 e 30 pessoas-horas por ponto
Um refinamento desta técnica sugere que a presença de certos atributos influencia diretamente a média de
pessoas-horas por ponto calculado, usando a seguinte lógica:
Conta-se a quantidade de fatores técnicos entre T1 e T6 que receberam nível de influência maior que 3
Soma-se o valor obtido à quantidade de fatores ambientais
entre E7 e E8 que receberam valor de influência menor que 3
O Método de Cálculo
Considerações
O somatório indica a quantidade sugerida de pessoas-horas por ponto de caso de uso a ser adotada no projeto, sendo a média sugerida de:
20 pessoas-horas por ponto para um resultado de 2 ou menor
28 pessoas-horas por ponto caso o somatório resulte em 3 ou 4
36 pessoas-horas por ponto para valores maiores que 4
Nessa caso, sugere-se que o projeto seja revisto
Talvez, haja a necessidade de treinamento de pessoal, adequação de tecnologia ou revisão de requisitos, para
garantir um melhor aproveitamento de recursos e redução no
cronograma previsto
O Método de Cálculo
Ferramentas
EEDS-PCU
Estimativa de Esforços de Desenvolvimento de Software baseados em Pontos de Casos de Uso
Além da estimativa de esforços, calcula a estimativa de custo
Desenvolvida pelo ITA (Instituto Tecnológico da Aeronáutica)
Não encontrada para download
Estimate Construx
Não avaliada em relação a estimativa de custos
Complexa pela grande quantidade de recursos
Em inglês
Disponível para download com licença limitada
http://www.construx.org/Page.aspx?nid=68
Planilha de Esforço baseado em Pontos de Casos de Uso
