Aula_07 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
1
Na aula anterior iniciamos métodos de estimativas do software
 - Avaliações com base estatística
 - cocomo
2
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ística
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ística
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 empresa ou 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:
Quantotempo 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
 
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)
Desenvolver estimativas usando decomposição de esforço e análise FP;
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.
 
Estimativas de 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 tamanhode 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
55
Contactos:
Professor Horacio ribeiro
www.espacodoprofessor.com
Email: profhoracioribeiro@gmail.com
Aula 7
56
L = Ck.K1/3.td4/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/(ck3.td4)