Prof. Horacio Ribeiro
Disciplina: PE- medidas do esforço no desenvolvimento de software Aula 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 RayleighNortem. 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 incluindose 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 aplicável a aplicações convencionais.
que seja
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. Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro
3- A partir do modelo de análise determinar o número de classes-chave. 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 Não IGI Interface com o usuário baseado em texto IGI IGU complexa
Multiplicador 2,0 2,25 2,5 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 Linhas de código ( LOC ) Pontos por função ( Function Point ) Outras métricas Não utiliza Base
Nº de organizações 25 43 26 363 446
Percentual (%) 5,6 9,6 5,8 81,4 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: - 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
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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 fornecida ao usuário. Vamos estimar o preço e prazo para desenvolver o sistema de manutenção de clientes.
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro Suponha que precisamos dar um orçamento para desenvolver o sistema. Para isto vamos usar APF para: 1. estimativa do tamanho funcional da aplicação 2. 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 Dados Tipos 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
Arquivo Lógico Interno - ALI
7 PF
Arquivo de Interface Externa - AIE
5 PF
Média
Alta
10
15 PF
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.
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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
PF Determinaçã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:
Tipos de Dados Arquivos Referenciados <2
<5
5 - 15
> 15
Baixa
Baixa
Média
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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
- Alterar
EE
- Excluir
EE
- Listar
SE
Consultar
CE
7
1
7
1
7
1
10 1
(*) 8
1
(*) - 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: 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
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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
- Incluir
EE
Baixa
3
- Alterar
EE
Baixa
3
- Excluir
EE
Baixa
3
- Listar
SE
Baixa
4
CE
Baixa
3
Cadastro de Clientes
Consultar
Total dos Pontos de função para as O total geral dos
funções de tipo transação da aplicação: 16 PF
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:
1. COMUNICAÇÃO DE DADOS: Quando são utilizados recursos de Comunicação de Dados 2. 3. 4. 5. 6. 7. 8. 9.
para o envio ou recebimento de dados e informações de controles utilizados pela aplicação; PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação; 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; 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; VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela; ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas; EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final; 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; PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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 1 2 3 4 5
-
Nenhum Influência Influência Mínima Influência Moderada Influência Média Influência Significativa 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,65 Onde:
Σ - é o somatório dos níveis de influência para as 14 características NI - NI é nível de influência
Uma equipe de profissionais respondeu e deu nota para os 14 características: As notas dadas para os itens foram: 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
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:
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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. 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
Texto experimental: e-mail pelo site WWW.espacodoprofessor.com
Prof. Horacio Ribeiro 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