View
224
Download
0
Category
Preview:
DESCRIPTION
Â
Citation preview
Prof. Horacio Ribeiro
Disciplina: PE- medidas do esforço no desenvolvimento de softwareAula 07 estimativas Putnam e métodos voltado para ponto função
(aula 7 ) ESTIMATIVAS – outros modelos e uso de PF
Este modelo é um 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. Foi construído analisando-se grandes projetos.
O esforço em grandes projetos é caracterizado como mostrado na figura abaixo, reproduzida do professor Pressmam.
Esta figura mostra curvas clássicas que foram apresentadas por Lorde Rayleigh e forma compilados por Norden, por este motivo a curva é chamada de curva Rayleigh-Nortem. Esta curva pode é usada para derivar a equação do software que relaciona linhas de código fonte ao tempo e esforço do desenvolvimento:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
Onde Ck é uma constante do estado da tecnologia e reflete restrições que impedem o progresso do programador. Tipicamente pode ser:
CK =2000 em ambiente para desenvolvimento de software (sem metodologia, documentação revisões precárias. Execução batch)
Ck =8000 desenvolvimento de software bom (boa metodologia, documentação, execução interativa
Ck=11000 ambiente ótimo com uso de ferramenta case.
A constante CK pode ser determinada para as condições de uma empresa compilando-se dados históricos de desenvolvimentos passados. Trabalhando-se a equação pode-se chegar à expressão para o desenvolvimento K, onde K é o esforço despendido em pessoas-ano ao longo do ciclo de vida para o desenvolvimento em anos.
Td é o tempo de desenvolvimento em anos. A equação para o esforço de desenvolvimento pode ser relacionada com o custo de desenvolvimento incluindo-se o fator de mão de obra (R$/ano)
L é o numero de linhas.
Estimativas de projetos orientado a objetos (Pressman)O software orientado a objetos deve ter outra abordagem:
1- Desenvolver estimativas usando decomposição de esforço e análise FP que seja aplicável a aplicações convencionais.
2- Desenvolver o diagrama de casos usos com o seu respectivo dicionário e determine a contagem do número de funcionalidades identificadas. Reconhecer que o número de casos e uso podem modificar à medida que se desenvolve o projeto.
3- A partir do modelo de análise determinar o número de classes-chave.Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
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.
Tabela
Tipo de interface MultiplicadorNão IGI 2,0Interface com o usuário baseado em texto 2,25IGI 2,5IGU complexa 3,0
5 – Multiplicar o número total de classes (chave e apoio) 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.
3 b. O tamanho do cenário pode ser estimado em LOC, PF ou alguma outra medida orientada a volume
4.a As estimativas de cada tarefa são somadas para criar uma estimativa de cenário
4.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, a estimativa serve para garantir que o número de cenários a ser incluído no incremento esta de acordo com os recursos disponíveis.
Estimativa usando Caso e USO
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
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. Têm se estudado a aplicação em conjunto da PCU e APF tentando explorar a relação entre elas existente(EDMÉIA,2004)
Estimativas usando ponto função
A estimativa de tamanho de um projeto de software é uma atividade crítica pois tem um impacto tanto na solução técnica apresentada 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.
Uma pesquisa realizada pela Secretaria de Política de Informática – SEPIN, em 2001, indicou que a utilização da APF vem crescendo no Brasil, conforme mostra a tabela 2.1:
Tabela 2.1: Métricas primitivas utilizadas para medir a qualidade dos processos de software.
Categorias Nº de organizações Percentual (%)Linhas de código ( LOC ) 25 5,6
Pontos por função ( Function Point ) 43 9,6Outras métricas 26 5,8
Não utiliza 363 81,4Base 446 100
Fonte: SEPIN , 2005
Considerando que a APF é uma das técnicas funcionais mais antigas, que possui um dos grupos de usuários mais bem estruturados e atuantes e que a partir de 2002 passou a condição de padrão internacional através da norma ISO/IEC 20926. A técnica pode ser considerada como uma das melhores alternativas de medição de tamanho do projeto de software.
APF serve como um instrumento para acompanhar estimativas de custo e recursos requeridos para o desenvolvimento e manutenção de software.
Exemplo de estimativas com APF:
Sistema de Manutenção de Clientes
Descrição do sistema:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
- 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.
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
Lista de ator(es):
Usuário (funcionário da empresa)
Casos de uso identificados
1. Exibir Clientes Cadastrados 2. Efetuar Manutenção de clientes
Diagrama de caso de uso simplificado:
Para determinar um custo “Justo” para o software devem-se realizar estimativas de tamanho, custo, esforço e qualidade de software.
Normalmente as estimativas são feitas com base em um histórico de informações durante o ciclo de desenvolvimento do projeto e que servem de base para a tomada de decisão.
Usando–se Análise de Pontos de Função, que tem sido cada vez mais utilizada para estimativas de tamanho, esforço e prazo, de um sistema de software com base na funcionalidade
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
fornecida ao usuário. Vamos estimar o preço e prazo para desenvolver o sistema de manutenção de clientes.
Suponha que precisamos dar um orçamento para desenvolver o sistema.
Para isto vamos usar APF para:
1. estimativa do tamanho funcional da aplicação2. estimativa do custo e esforço para desenvolvimento
1. Determinar o tamanho funcional do sistema de manutenção
Entidades e funções do processo de manutenção de clientes
1- Usuário (funcionário)
2- Gestão do cadastro de clientes
3- Cadastros
4- Clientes
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.
Para estimar o tamanho será feita uma contagem estimativa segundo o modelo que estudamos nas aulas anteriores - IFPUG.
Vamos usar o processo de contagem conforme preconiza o manual do IFPUG para determinar o número de pontos por função de um projeto de software.
Vamos usar as etapas do processo de contagem da APF conforme a figura abaixo:
A figura etapas da contagem da APF.(gráfico retirado de
http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf )
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
Determinar Funções do tipo dado – etapa 3 da figura
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.
Após identificar os ALI e AIE devemos classificar a função de acordo com sua complexidade funcional. Para alcançar este objetivo devemos determinar:
1. Número de Tipos de Dados (TD) - é um campo único, reconhecido pelo usuário, não repetido.
2. Número de Tipos de Registros (TR) - é um subgrupo de tipo de dados, reconhecido pelo usuário, componente de um ALI ou AIE.
Após determinar as quantidades de tipos de dados e tipos de registros, devemos classificar a complexidade de acordo com a seguinte tabela:
Tipos de DadosTipos de Registros
< 20
20 - 50
> 50
1 Baixa
Baixa
Média
2 - 5
Baixa
Média
Alta
> 5
Média
Alta
Alta
Após determinar a complexidade dos arquivos , devemos calcular sua contribuição conforme a seguinte tabela:
Tipo de Função Baixa Média Alta
Arquivo Lógico Interno - ALI 7 PF 10
PF 15 PF
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
Arquivo de Interface Externa - AIE
5 PF 7 PF 10 PF
Determinação dos ALI
ALI - Arquivo Lógico Interno - é um grupo de dados logicamente relacionados ou de informações de controle identificáveis pelo usuário e mantido dentro das fronteiras da aplicação.
No projeto,o cliente visualiza portanto o conjunto de informação como um registro lógico. A aplicação apresenta então somente 1 Registro Lógico.
Como todos os campos da tabela serão usados pelo usuário, com exceção do CodigoCliente que será atribuição do sistema, a aplicação apresenta 7 tipos de dados (basta contar em clientes:tabela).
Chegamos à conclusão pela tabela ( 1 <--> 7 ) que nossa aplicação possui a definição de complexidade Baixa.
Pela tabela a contribuição será de 7 PF.
O total de pontos por função para as funções do tipo dado para a aplicação é igual a 7 PFDeterminação dos AIE
AIE - Arquivo de interface externa - é um grupo de dados logicamente relacionados que é usado pela aplicação entrtanto sofre manutenção a partir de outra aplicação.
A aplicação não tem nenhum AIE. Com contribuição de 0 PF.
4- Determinar as funções do tipo Transação
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:
1. Entradas Externas - EE - Processa as informações e/ou dados recebidos de fora da fronteira da aplicação
2. Saídas Externas - SE - Envia dados ou informações para fora da fronteira da aplicação 3. Consultas Externas - CE - Envia dados ou informações de controle para fora da fronteira
da aplicação.
Cada função do tipo transação deve ser classificada com relação a sua complexidade funcional em:
1. 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.
2. 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:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
Tipos de Dados
Arquivos Referenciados
< 5 5 - 15 > 15
< 2 Baixa Baixa Média 2 Baixa Média Alta > 2 Média Alta Alta
Tabela de complexidade para Saídas Externas e Consultas Externas:
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
Determinando a quantidade de AR e TD da aplicação
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.
Função Tipo AR TD
Cadastro de Clientes
- Incluir EE 1 7
- Alterar EE 1 7
- Excluir EE 1 7
- Listar SE 1
10 (*)
- Consultar CE
1 8
(*) - além dos campos de dados estamos estimando ou contando os comandos ( botão e mensagem ao usuário)
Após determinar a complexidade das funções de transação podemos calcular sua contribuição de acordo com a tabela abaixo:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
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
Determinando a contribuição em PF para as funções de transação da aplicação
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 )Cálculo do fator de ajuste
O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
1. COMUNICAÇÃO DE DADOS: Quando são utilizados recursos de Comunicação de Dados para o envio ou recebimento de dados e informações de controles utilizados pela aplicação;
2. PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação;
3. PERFORMANCE: Esta característica identifica os objetivos de performance da aplicação, estabelecidos e aprovados pelo usuário, que influenciaram (ou irão influenciar) o desenho, desenvolvimento, implantação e suporte da aplicação;
4. UTILIZAÇÃO DO EQUIPAMENTO: Representa a necessidade de se fazer considerações especiais no desenho dos sistemas para que a configuração do equipamento não sofra degradação;
5. VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela;
6. ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas;
7. EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final;
8. ATUALIZAÇÃO "ON-LINE": Verifica o volume de arquivos lógicos internos que sofrem manutenção "on-line" e o impacto do processo de recuperação de seus dados;
9. PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;
10.REUTILIZAÇÃO DE CÓDIGO: Avalia se a aplicação e seu código foram especificamente projetados e desenvolvidos para serem reutilizados em outras aplicações;
11.FACILIDADES DE IMPLANTAÇÃO: Considera o esforço gasto para o atendimento dos requerimentos de conversão de dados para a implantação da aplicação;
12.FACILIDADE OPERACIONAL: Avalia o desenho da aplicação quanto aos requisitos estabelecidos para inicialização, "backup" e recuperação voltados à minimização da intervenção manual do operador;
13.MÚLTIPLOS LOCAIS: Quando a aplicação for especificamente projetada e desenvolvida para ser instalada em múltiplos locais ou para múltiplas organizações;
14.FACILIDADES DE MUDANÇAS: Quando os requisitos da aplicação prevêem o projeto e desenvolvimento de mecanismos que facilitem mudanças operacionais, tais como: capacidade de emissão de relatórios genéricos, de consultas flexíveis ou de alterações nos dados de controle do negócio (parametrização).
Cada uma destas características possui um nível de influência sobre a aplicação que pode variar em um intervalo de zero a cinco (0 a 5):
0 - Nenhum Influência1 - Influência Mínima2 - Influência Moderada3 - Influência Média4 - Influência Significativa5 - Grande Influência
Após determinar os níveis de influência das 14 características gerais o fator de ajuste é calculado com a seguinte fórmula:
VFA = (Σ NI x 0,01) + 0,65Onde:Σ - é o somatório dos níveis de influência para as 14 característicasNI - NI é nível de influência
Uma equipe de profissionais respondeu e deu nota para os 14 características:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
As notas dadas para os itens foram:
Característica
Influência
Característica
Influência
1 4 8 02 0 9 23 0 10 04 3 11 45 0 12 36 0 13 07 0 14 4 Valor Total =>
20
Chegamos portanto a um nível de influência igual a 20.
Calculando o fator de ajuste pela fórmula VFA = ( ΣNI x 0,01) + 0,65 temos:
VFA = (20 x 00,1 ) + 0,65 = 0,85 O valor do fator de ajuste é igual a 0,85.Portanto o número de pontos de função para o projeto é obtido da seguinte forma:
NPF = PFNA * VFA onde temos NPF = 27 * 0,85 = 22,95
Onde : NPF - número de pontos de função
Finalmente conseguimos obter uma medida para o tamanho da nossa aplicação. O seu tamanho é igual a 22,95 PF.Neste ponto para se fazer a estimativa temos de ter informações de projetos anteriores para basearmos nossa estimativa, por experiências passadas podemos trabalhar por analogia. Já foi considerado os aspectos de complexidade e de característica do software quando colocamos o valor de ajuste..
Quanto mais informações você puder obter melhor será a sua estimativa , ou seja, menos erro ela terá. O prazo correto, como em qualquer projeto, só será obtido com 100% de acerto só será obtido no fim do projeto
O ambiente de desenvolvimento , a experiência da equipe no projeto , os métodos usados no processo de software , etc. todos estes fatores influenciam na medida de estimativa a ser obtida.
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.
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
O esforço em horas pode-se obter pela formula
Esforço Total (horas ) = PF * índice de produtividade e os índices de produtividade podem ser expressos em Horas/PF ou PF/mês .
Para 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.
Com base na informação de 229 horas e sabendo-se o custo da equipe por hora podemos definir o preço
Com base nisto , sabendo o valor pago pela empresa o custo seria de fácil obtenção.
Na próxima aula vamos abordar o uso de dados estatísticos e estabelecimentos de padrões de gestão e estimativa usando PF.
Conclusão: O uso de PF é mais uniforme, e nos leva a resultados mais consistentes. Assim uma boa base de informações em relação ao PF nos leva a resultados mais consistentes. Trabalhar com LOC é muito impreciso, pois depende da linguagem que pode não estar escolhida. Também o fato que esta medida não favorece a boa estruturação de um projeto. Um projeto bem estruturado com 50.000 linhas é prejudicado ao se analisar outro projeto com 60.000 linhas feitas sem método e estruturação.
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Recommended