Medidas de Esforço de Desenvolvimento de Software

Prévia do material em texto

Medidas do Esforço de Desenvolvimento de Software 
Aula 7 
Prof. Horácio Ribeiro 
Na aula anterior iniciamos métodos 
de estimativas do software 
 
 - Avaliações com base estatística 
 - cocomo 
 
 
• Estudo de casos 
Sistema de Manutenção de Clientes 
• Descrição do sistema: 
- Em um sistema de manutenção de clientes um 
usuário (funcionário de empresa) registra as 
entradas, alterações, exclusões e saídas (relatório) 
dos dados relativos a um cliente da empresa no 
sistema. 
- Qualquer usuário da empresa poderá acessar o 
sistema e efetuar o cadastramento. (Não haverá 
controle de acesso no sistema). Será emitido um 
relatório de todos os clientes cadastrados e dos 
dados de um determinado cliente. 
 
 
Estudo de casos com ponto função 
Características do sistema: 
• - O sistema irá permitir o acesso sem restrições para 
qualquer usuário da empresa, não havendo 
portanto, controle de acesso. 
• - Não existe qualquer interface com outros sistemas 
existentes 
• - Deverão ser cadastrados os seguintes dados de um 
cliente: Nome, endereço, Cidade , CEP , Telefone , 
Email e Observações. 
• - O nome do cliente, endereço, cidade, CEP e email 
são obrigatórios e deverão ser sempre informados 
 
Casos de uso identificados 
A tecnologia usada no sistema para manutenção de cliente será 
de implementação em um site (processamento nas nuvens) 
usando a linguagem PHP (com suporte a objetos) envolvendo 3 
camadas : camada de dados , camada de aplicação e 
camada de apresentação. 
Determinar Funções do tipo dado 
O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que 
possui a seguinte estrutura: 
Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas: 
É um grupo lógico de dados identificável pelo usuário ? Sim. 
É mantido por um processo elementar dentro da fronteira da aplicação ? Sim. 
A aplicação possui somente um ALI. 
 
Número de Tipos de Dados (TD) - é um campo único, 
reconhecido pelo usuário, não repetido. (7 tipos de dados ) 
Número de Tipos de Registros (TR) - é um subgrupo de tipo de 
dados, reconhecido pelo usuário, componente de um ALI ou 
AIE (1 Registro Lógico). 
 
Determinar Funções do tipo dado 
ALI e AIE devemos classificar a função de acordo com sua complexidade funcional 
 Tipos de Dados 
Tipos de Registros < 20 20 - 50 > 50 
 1 Baixa Baixa Média 
 2 - 5 Baixa Média Alta 
 > 5 Média Alta Alta 
Tipo de Função Baixa Média Alta 
Arquivo Lógico Interno - 
ALI 
 7 PF 10 PF 15 PF 
Arquivo de Interface 
Externa - AIE 
 5 PF 7 PF 10 PF 
funções do tipo dado para a aplicação é igual a 7 PF 
AIE - Arquivo de interface externa - é um grupo de 
dados logicamente relacionados que é usado pela 
aplicação entretanto sofre manutenção a partir de 
outra aplicação. 
 
A aplicação não tem nenhum AIE. Com contribuição de 
0 PF. 
Determinar AIE 
As funções do tipo transação representam a funcionalidade 
fornecida ao usuário para atender os requisitos da aplicação. São 
classificadas como: 
 
Entradas Externas - EE - Processa as informações e/ou dados 
recebidos de fora da fronteira da aplicação 
Saídas Externas - SE - Envia dados ou informações para fora da 
fronteira da aplicação 
Consultas Externas - CE - Envia dados ou informações de 
controle para fora da fronteira da aplicação. 
 
Determinar as funções do tipo Transação 
Cada função do tipo transação deve ser 
classificada com relação a sua complexidade 
funcional em: 
• Número de Arquivos Referenciados - AR - Um 
ALI lido ou mantido pela função do tipo 
transação ou um AIE lido pela função do tipo 
transação. 
• Número de Tipos de Dado - TD - Um campo 
único, reconhecido pelo usuário, não repetido. 
 
Após determinar a quantidade de AR e TD da aplicação podemos definir 
a sua complexidade de acordo com as seguintes tabelas: 
 
Tabela de complexidade para Entradas Externas: 
 Tipos de Dados 
Arquivos 
Referenciados 
 < 5 5 - 15 > 15 
 < 2 Baixa Baixa Média 
 2 Baixa Média Alta 
 > 2 Média Alta Alta 
 Tipos de Dados 
Arquivos 
Referenciados 
 < 6 6 - 19 > 19 
 < 2 Baixa Baixa Média 
 2 - 3 Baixa Média Alta 
 > 3 Média Alta Alta 
Função Tipo AR TD 
Cadastro de Clientes 
 - Incluir EE 1 7 
 - Alterar EE 1 7 
 - Excluir EE 1 7 
 - Listar SE 1 7 
 - Consultar CE 1 8 
Vamos criar uma tabela para indicar as funções do tipo 
transação identificada e para cada uma delas a quantidade 
de AR e TD. 
(listar = 10 td SE - além dos campos de dados estamos estimando ou 
contando os comandos botão e mensagem ao usuário) (se não contar não fará 
diferença) 
Após determinar a complexidade das funções de 
transação podemos calcular sua contribuição de 
acordo com a tabela abaixo: 
Tipo de Função Baixa Média Alta 
Entrada Externa - EE 3 PF 4 PF 6 PF 
Saída Externa - SE 4 PF 5 PF 7 PF 
Consulta Externa - CE 3 PF 4 PF 6 PF 
Abaixo temos a tabela que exibe as funções 
do tipo Transação para a aplicação 
manutenção de clientes. 
Função Tipo Complexidade PF 
Cadastro de Clientes 
 - Incluir EE Baixa 3 
 - Alterar EE Baixa 3 
 - Excluir EE Baixa 3 
 - Listar SE Baixa 4 
 - Consultar CE Baixa 3 
Total dos Pontos de função para as funções de tipo 
transação da aplicação: 16 PF 
O total geral dos pontos de função não ajustados para a 
aplicação é de 23 PF ( 16 + 7 ) 
16 PF 
Abaixo temos a tabela que exibe as funções 
do tipo Transação para a aplicação 
manutenção de clientes. 
Função Tipo Complexidade PF 
Cadastro de Clientes 
 - Incluir EE Baixa 3 
 - Alterar EE Baixa 3 
 - Excluir EE Baixa 3 
 - Listar SE Baixa 4 
 - Consultar CE Baixa 3 
Total dos Pontos de função para as funções de tipo 
transação da aplicação: 16 PF 
O total geral dos pontos de função não ajustados para a 
aplicação é de 23 PF ( 16 + 7 ) 
16 PF 
Cálculo do fator de ajuste 
O valor do fator de ajuste (VFA) é 
baseado em 14 características gerais de 
sistema listadas abaixo: 
Característic
a 
Influência Característica Influência 
1 4 8 0 
2 0 9 2 
3 0 10 0 
4 3 11 4 
5 0 12 3 
6 0 13 0 
7 0 14 4 
 Valor Total => 20 
Uma equipe de profissionais respondeu e deu nota para os 14 características: 
As notas dadas para os itens foram: 
VFA = (20 x 00,1 ) + 0,65 = 0,85 
 
O valor do fator de ajuste é igual a 0,85. 
Cálculo do fator de ajuste 
O valor do fator de ajuste (VFA) é 
baseado em 14 características gerais de 
sistema listadas abaixo: 
Característic
a 
Influência Característica Influência 
1 4 8 0 
2 0 9 2 
3 0 10 0 
4 3 11 4 
5 0 12 3 
6 0 13 0 
7 0 14 4 
 Valor Total => 20 
Uma equipe de profissionais respondeu e deu nota para os 14 características: 
As notas dadas para os itens foram: 
VFA = (20 x 00,1 ) + 0,65 = 0,85 
 
O valor do fator de ajuste é igual a 0,85. 
Como estamos usando as regras do manual de 
contagem, que também são usadas por outras 
empresas. 
 
Isto nos facilita, pois se não tivermos uma base 
histórica podemos buscar informações em outras 
empresas a fim de subsidiar sua estimativa. 
 
Na nossa empresa O esforço em horas é obtido 
pela formula (já por indicadores estatísticos) 
 
Esforço Total (horas ) = PF * índice de 
produtividade 
(os índices de produtividade podem ser expressos 
em Horas/PF ou PF/mês ). 
• A aplicação em questão que possui 22,95 PF , se 
o índice de produtividade da empresaou equipe 
for de 10 horas/PF o esforço demando seria 
algo em torno de 229,5 horas. 
• Assim o projeto demandará 229 horas para ser 
desenvolvido (considerado apertado). 
• Com base na informação de 229 horas e 
sabendo-se o custo da equipe por hora 
podemos definir o preço 
 
Nesta aula: 
 
•Outra formas de estimativa em 
modelos dinâmicos; 
•Estimativas Putnam; 
•Outros métodos voltado para 
ponto função; 
•Estimativas com métodos ágeis 
Categorias Nº de organizações Percentual(%) 
Linhas de código ( LOC ) 25 5,6 
Pontos por função ( Function Point ) 43 9,6 
Outras métricas 26 5,8 
Não utiliza 363 81,4 
Base 446 100 
Considerando a pesquisa realizada pela Secretaria de Política de Informática – 
SEPIN , em 2001, cujo resultado é apresentado na tabela 
Importância do assunto 
23 
Estimar software 
• O planejador deve estimar três coisas antes do início 
do projeto: 
– Quanto tempo durará 
– Quanto esforço será exigido 
– Quantas pessoas estarão envolvidas 
• E também: 
– Recursos de hardware e recursos de software necessários 
24 
Técnicas 
• Técnicas para desenvolver estimativas envolvem: 
– decomposição 
– modelagem empírica 
– ferramentas automatizadas 
25 
técnicas 
• Técnicas empíricas usam expressões derivadas de 
dados históricos, para o esforço e o tempo, com o 
objetivo de prognosticar essas quantidades para o 
projeto. 
• Ferramentas automatizadas implementam um 
modelo empírico específico. 
• Estimativas de projeto precisas geralmente fazem 
uso de pelo menos duas técnicas diferentes de 
estimativas vistas. 
 
26 
Estimativas de Projetos 
de Software 
 Estimativas de recursos, custos e programação 
de atividades exigem: 
• conhecimento. 
• Acesso a boas informações históricas. 
• Coragem para se comprometer com as medidas 
quantitativas. 
27 
Estimativas de Projetos de 
Software 
 Estimativas => carregam riscos inerentes 
 Fatores que aumentam os riscos: 
Tamanho do projeto 
Complexidade baseada 
nos esforços passados 
Desestruturação do projeto 
Domínio de baixo risco 
28 
Estimativas 
Estimativas de Pontos por Função (PF) 
 
• variáveis de estimativa - usadas para 
“classificar por tamanho” cada elemento do 
software. 
 
• Como métricas de “base line”- coletadas a 
partir de dados históricos e usadas em 
conjunto com variáveis de estimativa para que 
se desenvolva projeções de custo e de esforço 
29 
Estimativas 
 Método de estimativa do Esforço 
Passos (visão - PMI): 
• Delineamento das funções do software 
• Listagem das tarefas a serem executadas para cada 
função (análise, projeto, codificação e testes) 
• Esforço estimado para cada tarefa em cada função 
(pessoa-mês) 
• Taxas de mão de obra aplicadas em cada uma das 
tarefas 
• Cálculo de custo e o esforço de cada função 
 (e tarefa de engenharia de software) 
30 
Estimativas de Projeto de 
Software 
Modelos Empíricos de Estimativa 
Fórmulas construídas empiricamente para fornecer 
informações de planejamento de projeto. 
• Dados Empíricos - resultam de uma amostra limitada 
de projetos. 
• Modelos de software - não são apropriados para 
todas as classes de software 
• Devem ser usados criteriosamente 
 (usar mais de um método de avaliação) 
 
31 
Estimativas de Projeto de Software: 
Modelos de Recursos 
Modelos de Recursos 
 são formados por uma ou mais equações 
empíricas que fornecem informações 
sobre: 
• Esforço (pessoa-mês) 
• Duração do projeto (meses cronológicos), 
etc. 
• Alguns trabalham por fase do projeto 
32 
Estimativas de Projeto de Software: 
 Modelos de Recursos 
 Existem quatro classes de modelos de 
recursos (Basili) 
• Modelos estáticos de variáveis simples. 
• Modelos estáticos de múltiplas variáveis 
• Modelos dinâmicos de múltiplas variáveis 
• Modelos teóricos 
33 
Estimativas de Projeto de Software: 
 Modelos Estáticos de Variáveis simples 
 Recurso = C1 X (características Estimadas) 
 Recurso: 
– esforço 
– duração do projeto 
– tamanho da equipe 
– páginas (linhas) de documentação 
C2 
34 
Estimativas de Projeto de Software: 
 
Modelos Estáticos de Variáveis simples 
 Recurso = C1 X (características Estimadas) 
 Características Estimadas 
– linhas de código fonte (LOC)...PF 
– esforço (se estimado) 
 C1 e C2 - constantes derivadas de dados compilados 
de projetos passados. 
 
Exemplo: COCOMO (Constructive Cost Model) 
C2 
35 
Estimativas de Projeto de Software: 
 
Modelos Estáticos de Múltiplas Variáveis 
Recurso = C11e1 + C21e2 + ... 
Onde e1, e2, e3 ... São características do software 
Exemplo: 
 C (homem mês) = 0,12*paginas +23,2*linhas +... 
 
36 
Estimativas de Projeto de Software: 
 Modelos Dinâmicos de Múltiplas Variáveis 
• projetam os requisitos de recursos como 
uma função do tempo 
• recursos são definidos atribuindo-se uma 
porcentagem de esforço a cada passo do 
processo de software (desenvolvimento) 
 
O esforço distribuido, em grandes 
 projetos, é mostrado na figura abaixo, reproduzida 
do professor Pressmam. 
 
modelo dinâmico de múltiplas variáveis 
que pressupõem a distribuição do esforço 
ao longo da existência de um projeto de 
desenvolvimento 
Estimativas de Projeto de Software: 
 
39 
Estimativas de Projeto de Software: 
 
Modelos Teóricos 
• abordam teoricamente modelos dinâmicos de 
múltiplas variáveis 
• Examina o software de forma minuciosa (ex. 
Números de operandos e operadores - modelo de 
estimativa de Putnam) 
 
 
 
 
método de Putnam que considera múltiplas 
variáveis e o ciclo de desenvolvimento do 
projeto 
Estimativas de Projeto de Software: 
 
Curva de Rayleigh-Putnam 
Com base em análise estatística Putnam 
relacionou o comportamento prazo e 
esforço com distribuição de Rayleight 
42 
Estimativas de Projeto de Software: 
Modelo de Putnam 
Equação de Software 
 
 
 
L = Ck.K
1/3
.td
4/3
, onde
L = linha de código
Ck = constante de estado de tecnologia
 Ck = 2.000 –ambiente de desenvolvimento pobre
 Ck = 8.000 – métodos em prática, documentação e revisões
adequada
 Ck = 11.000 – ambiente ótimo (ferramentas e técnicas
automatizadas)
K = esforço (pessoa – ano)
Td = tempo de desenvolvimento (anos)
Novo arranjo: Esforço – K = L3/(ck
3
.td
4
)
Curva de Rayleigh-Putnam 
Os pontos destacados 
representam a quantidade 
de recursos 
 recursos = f( esforço, prazo) 
Curva de Rayleigh-Putnam 
Mesmo com as mudanças de 
tecnologias o gráfico mostra que 
existe uma região que é impossível a 
entrega no prazo 
Estimativas de projetos 
orientado a objetos (Pressman) 
 
O software orientado a objetos deve ter outra abordagem 
 (6 passos) 
 
1.Desenvolver estimativas usando decomposição de esforço e 
análise FP; 
 
2.Desenvolver o diagrama de casos usos com o seu respectivo 
dicionário, e determinar a contagem de PF. 
 - Reconhecer que o número de casos e uso podem modificar à 
medida que se desenvolve o projeto. 
 
3.A partir do modelo determinar o número de classes. 
Tipo de interface Multiplicador 
Não IGI 2,0 
Interface com o usuário baseado em texto 2,25 
IGI 2,5 
IGU complexa 3,0 
Estimativas de projetos 
orientado a objetos (Pressman) 
 
4 .Categorizar o tipo de interface para aplicação 
para as classes de apoio. 
 Multiplicar o número de classes chaves pelo 
multiplicador para obter uma estimativa para 
o número de classes de apoio. 
 
 
 
 
Estimativasde projetos 
orientado a objetos (Pressman) 
 
 
 
5.Multiplicar o número total de classes pelo número médio de 
unidades de trabalho por classes. 
 Autores como Lorenz sugerem entre 15 a 29 pessoas dia 
por classe 
 
6.Fazer a verificação cruzada em estimativas baseadas em 
classes multiplicando o número médio de unidades por 
caso e uso 
Estimativas com métodos ágeis 
 
Um projeto usando um processo de desenvolvimento 
ágil e feito como um conjunto de cenários de usuários. 
 
 É possível desenvolver uma estimativa com razoável 
significado com os seguintes passos: 
 
1.Cada cenário de usuário é considerado 
separadamente para a estimativa. 
2.O cenário é composto de um conjunto de funções e 
tarefas de engenharia. de software. 
3 a.Cada tarefa é estimada separadamente. 
 b.O tamanho do cenário pode ser estimado em LOC, 
PF ou alguma outra medida orientada a volume 
Estimativas com métodos ágeis 
 
4.a - As estimativas de cada tarefa são somadas 
para criar uma estimativa de cenário 
 b - O volume de esforço é estimado para o 
cenário criado e depois é quantificado para o 
esforço necessário, a partir de dados históricos 
referentes a outros projetos 
5.As estimativas de esforço para todos os cenários 
que devem implementar um incremento de 
software são somadas para definir a estimativa 
para o incremento. 
 Normalmente a duração do desenvolvimento de 
um incremento é da ordem de 3-6 semanas. 
Estimativa usando Caso e USO 
 
• PCU – Pontos por Caso de Uso – Foram criados por 
Gustav Karner em 1993 como uma adaptação 
específica dos Pontos de Função para medir o tamanho 
de projetos de software orientados a objeto. 
• Explora o modelo e descrição do caso de uso, 
substituindo algumas características técnicas proposta 
pelos Pontos de Função. 
• É um método simples e de fácil utilização, entretanto, 
mas ainda esta em fase de pesquisas e não existem 
regras de contagem padronizadas 
conclusões 
-Não existe um modelo único. 
-Deve-se desenvolver o modelo mais 
adequado a empresa 
-Deve-se fazer sua carta gráficas. 
-O modelo deve ser periodicamente revisto 
-Deve-se validar por mais de um método 
-É um aspecto estratégico para a empresa 
conclusões 
• Cuidado com indicadores de mercado 
 deve-se conhecer particularidades da coleta, 
forma de desenvolvimento, ferramentas...) 
conclusão 
• A estimativa de tamanho de um projeto de 
software é uma atividade crítica pois tem um 
impacto tanto na solução técnica a ser 
adotada como no gerenciamento do projeto 
de software devendo ser efetuada não 
somente no início do projeto mas durante o 
ciclo de vida do projeto. 
 
Próxima aula 
• a usar as estimativas e ponto função como 
instrumento de gestão. 
• Vamos aprender a dimensionar receita e 
custos a partir de ponto função. 
• Vamos aprender a utilizar estes valores se 
distribuem, no processo de desenvolvimento, 
na gestão do projeto e da empresa 
• Definir métricas que sirvam de parâmetros 
para a gestão 
• Até a próxima aula 
 
 
 
• Contactos: 
• Professor Horacio ribeiro 
 
• www.espacodoprofessor.com 
 
• Email: profhoracioribeiro@gmail.com 
 
• Aula 7