Métricas para Software Análise de Ponto de Função

Métricas para Software Análise de Ponto de Função
Qualidade em Engenharia de Software Especialização em Tecnologia da Informação

Análise de Ponto de Função
Mantido pela ( No Brasil

Objetivo de uma Métrica para software
Estabelecer um tamanho para o produto de software, de forma que, seja possível gerenciar aspectos como custos, tempo, produtividade, qualidade, etc. É requisito básico para um efetivo planejamento de um projeto de software. “Não se pode controlar aquilo que não se consegue medir.”

Metodologia para Contagem de Pontos de Função descrita no “Counting Practices Manual” versão 1.4 (CPM4.1), publicado pela IFPUG É um método padrão para definir um “tamanho” para um software, em Pontos de Função

É apoiada na funcionalidade implementada pelo software, sob o ponto de vista do usuário É uma métrica “A priori ”, ou seja, pode ser aplicada antes que o produto seja desenvolvido Também pode ser utilizada sobre software já implementado

Não depende da implementação (linguagem, compilador, banco de dados, etc.) Foi criada por Allan J. Albrecht, engenheiro de software da IBM em 1974.

Tamanho de um Software Qual o tamanho de um P.F.?
Quantas linhas de código tem um P.F.? Quanto custa um P.F? Quanto tempo é necessário para implementar um P.F?

Tamanho de um Software Atualmente os Contratos para Desenvolvimento de Software são Baseados em Medidas – a maioria em P.F. Valores podem ser revistos (tanto para mais quanto para menos) em função do tamanho previsto para o software em relação ao tamanho real do software entregue ao cliente

Tamanho de um Software

Dados Históricos Não basta ter um “tamanho” de software, é necessário saber converter este tamanho em número reais O software X tem tamanho = 150 PF E daí? É precisa conhecer projetos passados para determinar o custo de um 1 PF, o tempo de desenvolvimento de 1 PF...

Exemplo de Planejamento de Software
Métricas na Prática – Informática é um negócio

Dados Históricos Uma empresa interessada em aplicar métricas deve manter de cada projeto os seguintes dados, além do tamanho do projeto: Quanto custou todo o projeto Quanto tempo consumiu todo o projeto Quanto tempo consumiu cada fase do processo de engenharia de software Quanto custou cada fase do processo de engenharia de software Qual a equipe e custos foram considerados nos cálculos

Contagem de Pontos de Função
Contar Funções de Dados Procedimento Calcular PF não Ajustado Determinar Tipo de Contagem Identificar Escopo Contar Funções Transacionais Determinar Fator Ajuste Calcular PF Ajustado

Contagem das Funções de Dados
Para cada tabela (ou entidade do DER) deve ser determinada sua complexidade Para calcular a complexidade é necessário determinar número de itens de dados: campos com valores atômicos e únicos. Chaves estrangeiras são contadas como um item de dados número de registros lógicos: atributos multivalorados – DER; ou a tabela criada em decorrência de um atributo multivalorado)

Tabela para Determinar a Complexidade das Funções de Dados Número de Registros Lógicos Número de Itens de Dados De 1 a 19 De 20 a 50 51 ou mais Apenas 1 Simples Média De 2 a 5 Complexa 6 ou mais

Exemplo Tipo Endereço Nome Cliente Telefones Cód Número Item de Dados: 5 (são os atributos atômicos) Registros Lógicos: 2 (são as tabelas físicas que serão geradas) Complexidade: Simples

Cada Arquivo deve ser classificado como sendo: ALI – Arquivo Lógico Interno: são arquivos mantidos pelo sistema AIE – Arquivo de Interface Externa: são arquivos mantidos por um outro sistema ou organização mas que são acessados pelo software que está sendo avaliado

Considerações Importantes para Contagem dos Dados
Os chamados “Dados de Código” ou “Metadados” não devem ser contados. Dados de código não especificados pelos usuários, mas sim pelo desenvolvedor para solucionar problemas de projeto. São exemplos de dados de código: Uma tabela com os estados federativos, utilizada para evitar codificação redundante Uma tabela com os dados da empresa (nome, logomarca, etc) onde o sistema está instalado – também chamados de dados de uma ocorrência

São exemplos de dados de código: Tabelas com dados que raramente mudam. Como tabelas com unidades de medida, ou tabelas com intervalos de valores válidos – domínio de valores. Tabelas com valores default para outros campos da aplicação. Entidades que existem somente para implementar relacionamentos N:M não devem ser contadas como 1 AL, mas sim como tipos de registros (ou registros lógicos) – não fazem parte de uma visão funcional, mas sim de uma visão implementacional

Entidades como Venda e Itens da Venda devem ser contadas como um único ALI – isto também em conseqüência da visão funcional Quando há uma relacionamento 1:1 entre duas entidades que se complementam, as mesmas devem ser contadas como um único AL e um único tipo de registro Quando há o conceito de herança para os dados, a dados genéricos e os específicos devem ser contados como um único AL, contudo, cada “classe” deverá ser contada como um tipo de registro

Entidades associativas (geralmente que implementam relacionamentos N:M) serão contadas como 1 AL somente se sua existência independe dos dados das entidades que estão sendo vinculadas Exemplo: Funcionário <-> Serviços <-> Departamentos Mesmo que um funcionário ou um departamento seja excluído o serviço deverá ser mantido – logo o mesmo é contado como 1 AL

Prática – SVInternet Determinar o tamanho das funções de dados do SVInternet Cada grupo deverá realizar a contagem das funções dos dados do SVInternet Os resultados dos grupos serão confrontados O resultado final será utilizado para o estabelecimento de um plano de desenvolvimento do sistema

Contagem das Funções Transacionais
São considerados três tipos básicos de Funções Transacionais Cadastros – chamados de Entradas Externas Consultas sem a realização de cálculos – chamadas de Consultas Externas Consultas com a realização de cálculos – chamadas de Saídas Externas

São exemplos de Entradas Externas (EE) Cadastros ou transações que recebam dados externos utilizados na manutenção de ALI; Janelas que permitam adicionar, excluir e alterar registros em arquivos. Nesse caso contribuem com três Entradas Externas; Processamento com lotes de atualização de bases cadastrais a partir de arquivos de movimentos.

Não são exemplos de Entradas Externas (EE) Telas de filtros de relatórios e consultas; Menus; Telas de Login.

São exemplos de Saídas Externas (SE) Relatórios com totalização de dados; Relatórios que atualizem arquivos; Consultas com apresentação de dados derivados ou cálculos; Arquivo de movimento gerado para outra aplicação; Informações em formato gráfico.

Não são exemplos de Saídas Externas (SE) Telas de Help; Drop-downs; Consultas simples que simplesmente recuperam e apresentam dados.

São exemplos de Consultas Externas (CE) Telas de Help; Telas de Logon; Menus e Drop-Downs gerados dinamicamente a partir de dados de um aquivo.

Considerações Importantes para a Contagem das Funções Transacionais
É preciso compreender bem o conceito de Processo Elementar – caso contrário vários processos transacionais podem ser contados como um único, implicando em um cálculo errôneo. Processo Elementar é a menor unidade de atividade significativa para o usuário final.

Regras para determinar o número de Processos Elementares(PE): A lógica de processamento é diferente da executada por outros processos elementares da aplicação – então conta-se dois PE’s (Dois relatórios se diferenciam somente pela ordenação dos dados – então ambos devem ser contados como um PE); O conjunto de tipos de dados identificado é diferente do identificado em outros PE – então conta-se dois PE’s; Os ALI e AIE referenciados são diferentes dos arquivos referenciados por outros processos elementares da aplicação.

Por exemplo um cadastro de clientes que permita a inclusão, a alteração e a exclusão de dados do cliente deverá ser contado com três Entradas Externas diferentes – isto porque cada funcionalidade desta possui um processamento elementar diferente (lógica de execução)

Para calcular a complexidade de uma Entrada, Saída ou Externa deve-se determinar: O número de Arquivos Referenciados: arquivos lidos ou gravados durante a execução do cadastro O número de Itens de Dados: deve ser contado como item de dado todo campo de dados, toda mensagem emitida pelo cadastro e toda operação executada pelo cadastro

Regras para Contar o Número de Arquivos Referenciados
Regras válidas para se contar os AR: Conte um AR para cada ALI mantido; Conte apenas um AR para cada ALI lido e mantido pela função; Conte um AR para cada ALI ou AIE lido durante o processamento. Obs: As duas primeiras regras supracitadas não se aplicam para as consultas externas

Regras para Contar o Tipos de Dados (TD)
Regras de Contagem de Tipos de Dados: Conte um TD para cada campo, não repetido e reconhecido pelo usuário, que entra ou saí pela fronteira da aplicação; Se um campo tanto entra como saí da fronteira da aplicação, deve ser contado uma única vez (Um campo de uma tela de filtro de relatório por exemplo); Campos que são recuperados ou derivados e armazenados em ALI, mas que não ultrapassam a fronteira da aplicação não devem ser contados (Um código gerado automaticamente para um registro e que não é apresentado ao usuário, por exemplo);

Regras de Contagem de Tipos de Dados: Conte um único TD para uma mensagem enviada para fora da fronteira da aplicação – seja esta mensagem de erro, de confirmação ou de verificação (Por exemplo, se um cadastro existem mensagens para alertar sobre a falta de dados ou ainda a inconsistência de dados, conte apenas um TD para ambas); Conte um único TD para a capacidade de especificar uma ação a ser tomada – mesmo que haja múltiplas formas de acionar esta ação (Por exemplo, para se gravar um registro pode-se clicar no botão salvar ou pressionar a tecla <CTRL> + <s>, mesmo assim deve-se contar somente um TD);

Regras de Contagem de Tipos de Dados: Não conte itens literais como TD (Por exemplo, Títulos de cadastros, títulos de relatórios, cabeçalhos de colunas, nomes de campos); Não conte variáveis de paginação ou campos automáticos gerados pelo sistema (Número da páginas de relatórios, campos de data e hora, campos de paginação como barra de rolagens).

Tabela para Determinar Complexidade da Entrada Externa Número de Arquivos Referenciados Número de Itens de Dados De 1 a 4 De 5 a 15 16 ou mais 0 ou 1 Simples Média 2 Complexa 3 ou mais

Tabela para Determinar a Complexidade das Consultas e Saídas Externas Número de Arquivos Referenciados Número de Itens de Dados De 1 a 5 De 6 a 19 20 ou mais 0 ou 1 Simples Média 2 ou 3 Complexa 4 ou mais

Cálculo do Tamanho do Software Não Ajustado
Para determinar o tamanho não ajustado do software existe uma tabela padrão Antes de lançar os dados da tabela padrão é necessário: Classificar os arquivos como ALI ou AIE Classificar os relatórios como Consultas Externas ou Saídas Externas

Tamanho Não Ajustado Complexidade Total de Pontos
Tipos de Função Complexidade Total de Pontos Arquivos Lógicos Internos 6 simples x 7 = média x 10 = complexas x 15 = 42 p.f Arquivos de Interface Externa simples x 5 = média x 7 = complexas x 10 = 0 .pf. Entrada Externa simples x 3 = média x 4 = complexas x 6 = Consulta Externa Saída Externa simples x 4 = média x 5 = complexas x 7 = Total Final:

Cálculo do Nível de Influência Total - NIT
Ao se determinar o tamanho de um software deve ser considerado a tecnologia que será utilizada, os métodos de desenvolvimento, etc; Um DER e um protótipo são independentes de tecnologia; É necessário ajustar o tamanho do software, considerando fatores técnicos e externos variados; Até o presente momento toda a contagem se baseou nas funcionalidades da aplicação.

Cálculo do Nível de Influência Total (NIT)
O NIT é calculado através da soma das notas fornecidas para 14 itens previamente definidos Para cada item deve ser dada uma nota de 0 à 5 (0 – representa nenhuma influência; 5 – representa forte influência) O NIT geralmente é definido para previamente para um determinado software, em caso de uma concorrência

Exemplo de um Item de Influência no Tamanho do Sistema Processamento Distribuído = 5 (O sistema deverá operar de forma distribuída) A interpretação de cada Característica Geral de Sistema (CGS) é um processo complexo, que muitas vezes, depende de aspectos empíricos.

Características Gerais de Sistemas de Acordo com IFPUG
1. Comunicação de Dados – determina se as aplicações são processadas em batch ou on-line Aplicações atuais geralmente pontuam com 4 neste item – nunca menos de 2 Aplicações Cliente-Servidor com duas camadas geralmente possuem pontuação 4 Aplicações de tempo real, com servidores de aplicação e middlewares pontuarão com 5.

2. Processamento Distribuído – descreve em que nível a aplicação transfere dados entre seus componentes Uma aplicação desktop isolada (aplicação e BD na mesma máquina) irá pontuar com 0 Um sistema com N camadas pontuará com 4 Para pontuar com 5 o sistema deverá ter componentes sendo executados em vários servidores

3. Performance – descreve o nível em que o tempo de resposta e taxa de transações influenciam o desenvolvimento da aplicação Uma aplicação bancária cujo tempo de resposta deve ser praticamente instantâneo pontuará com 5; Tempo de resposta são críticos durante os momentos de pico. Não foi necessário um projeto especial para uso da CPU. Pontuação igual a 3.

4. Configuração Altamente Utilizada – descreve o nível em que restrições de recursos computacionais influenciam no desenvolvimento da aplicação Em geral, a grande maioria dos sistemas pontuaria com 0 ou 1; Aplicações científicas ou de engenharia com grandes exigências de processamento pontuariam de 3 a 5.

5. Volume de Transações – descreve o nível em que o alto volume de transações influenciam no desenvolvimento da aplicação Tem forte relação com CGS 3 – Performance; Um e-commerce com altos picos de acesso em conseqüência de promoções rápidas podem ser pontuados com 5.

6. Entrada de Dados On-line – descreve o nível em que são efetuadas entradas de dados on-line (interativas) Aplicações com mais de 30% das entradas sendo realizadas de forma on-line são pontuadas com 5; Atualmente a maioria absoluta das aplicações pontuam com 5 nesta CGS.

7. Eficiência do Usuário Final – descreve o nível em que fatores humanos e facilidade de uso influenciam o desenvolvimento A pontuação para esta CGS é definida de acordo com uma tabela de itens a serem respondidos; Aplicações tipicamente Windows e Web pontuarão de 3 a 5.

8. Processamento Complexo – descreve o nível em que o processamento lógico ou matemático influenciam o desenvolvimento Aplicações comerciais e de gestão geralmente possuem uma baixa pontuação para esta CGS – de 0 a 2 pontos.

10. Reusabilidade – a aplicação e seu código foi especialmente projetados, desenvolvidos e suportados para serem utilizados em outras aplicações Aplicações muito bem projetadas, com design patterns e alta-reutilização podem receber pontuação de 4 a 5.

11. Facilidade de Instalação – descrevem em que nível a conversão de ambientes preexistentes influenciam o desenvolvimento Projetos que irão substituir aplicações existentes tendem a ter uma pontuação elevada nesta CGS – de 3 a 5 pontos – dependendo do facilidade e automação deste processo de substituição

12. Facilidade de Operação – descrevem em que nível a aplicação atende a alguns aspectos operacionais, como: inicialização, segurança e recuperação Aplicações em que não há a necessidade de um operador, pois o usuário consegue facilmente realizar todos os tipos de operações possuem pontuação 5 para esta CGS.

13. Múltiplos Locais – a aplicação foi especialmente projetada para ser instalada e atender múltiplos locais para múltiplas organizações Aplicações projetadas para operar em diferentes plataformas (hardware e software) devem ter pontuação igual ou acima de 3.

14. Modificação Facilitada – descreve em que nível a aplicação foi projetada para facilitar sua manutenção e evolução O número de consultas flexíveis (com parâmetros e condições de busca definidas pelo usuário) e a quantidade de dados de configuração mantidos de forma on-line determinam esta CGS.

Com NIT deve ser calculado o Valor Fator de Ajuste (FA) do tamanho do software FA = (NIT * 0,01) + 0,65 Para um NIT = 45 temos o FA = 1,1 O FA pode alterar o tamanho do software não ajustado em +-35%

Cálculo do Tamanho Ajustado de uma Aplicação
Tamanho Ajustado = Tamanho Não Ajustado * FA Existem fórmulas especiais para Projetos de Desenvolvimento e para Projetos de Manutenção (ou melhoria) de Software; Estas fórmulas consideram pontos de função de funcionalidades alteradas, excluídas, adicionadas e preservadas.

Realizando as Primeiras Estimativas
Custo por PF = R$ 590,00 Tempo médio por PF = 10 H/H (horas-homem)

Fim...

Métricas para Software Análise de Ponto de Função

Apresentações semelhantes

Apresentação em tema: "Métricas para Software Análise de Ponto de Função"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Métricas para Software Análise de Ponto de Função

Apresentações semelhantes

Apresentação em tema: "Métricas para Software Análise de Ponto de Função"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback