Uso da curva ABC na Técnica de Análise por Pontos de Função nas Estimativas de Projetos de Software

Transcrição

1 Uso da curva ABC na Técnica de Análise por Pontos de Função nas Estimativas de Projetos de Software Ivanir Costa (USP) Marcelo Schneck de Paula Pessôa (USP) Mauro Spinola (USP) Resumo A estimativa correta do tamanho de um software, tem sido um desafio para as empresas de software desde a década de No final da década de 1970, Allan J Albretch desenvolve a técnica de Análise por Pontos de Função com essa finalidade e a mesma vêm se tornando um padrão internacionalmente aceito, para as estimativas e medidas da área de software. Este trabalho tem como objetivo apresentar uma contribuição na aplicação da técnica de Análise por Pontos de Função que permite seu uso em um nível alto de definição dos requisitos de uma aplicação eliminando a necessidade dos seus detalhamentos. Palavras chave: Estimativas, Pontos de Função, Curva ABC, Use Case Point, Métrica, Técnica. 1. Introdução Quando se consegue estimar as atividades do ciclo de vida de um software, individualmente ou por agrupamentos de atividades, torna-se possível medi-las, compará-las e também fazer análises sobre os resultados reais em relação aos estimados. Como cada medida é efetuada sempre com o mesmo peso e com mesma abordagem é possível comparar os esforços na realização das atividades ou tarefas. A existência de divergências nos valores estimados em relação aos reais, obtidas a partir de análises sobre a produtividade das equipes, do tipo de software e da tecnologia aplicada, permitem o ajuste nos índices ou nos pesos aplicados e com isso melhorar-se tanto a produtividade, como a qualidade, através de ações de melhoria que podem ser realizadas. Conforme Pressmann (2000), a aplicação de métricas padronizadas é a chave fundamental para o êxito destas estimativas, não importando qual métrica seja adotada. Este trabalho tem por objetivo propor uma abordagem simplificada na aplicação da técnica de Análise por Pontos de Função (APF), combinando a curva ABC de Vilfredo Paretto com as complexidades e pesos propostos por Allan J Albretch. Essa abordagem vai permitir que se aplique as estimativas logo no inicio do desenvolvimento de um projeto, pois, com poucas informações os desenvolvedores poderão estimar seus custos baseados em uma métrica estatística e de precisão já comprovada, sem ter que partir para novas técnicas ainda não maduras ou bem testadas. 3. A avaliação da complexidade de softwares A determinação do tamanho e da complexidade dos softwares varia de pessoa para pessoa ou de equipe para equipe. Na maioria das vezes na prática são utilizados valores que refletem experiências das equipes envolvidas, sem o uso de nenhuma métrica mais determinativa, provocando às vezes divergências significativas entre os valores calculados para um projeto de uma equipe para outra. Todavia, é a partir do grau de complexidade estimada de um software a ser desenvolvido que se obtém o número de horas necessárias para o desenvolvimento ou manutenção de um determinado sistema aplicativo. Obtido o número de horas, pode-se determinar o custo de desenvolvimento, multiplicando-se a quantidade horas pelo custo/hora negociado com o cliente. Dessa forma, o faturamento dos serviços num determinado período será aferido em função dos softwares efetivamente entregues ao cliente ENEGEP 2003 ABEPRO 1

2 ou usuário 4. Técnicas de medição de software Conforme Fernandes (1995), na disciplina de Engenharia de Software, as medidas são denominadas de métricas, que podem ser definidas como métodos de determinar, quantitativamente, a extensão em que o projeto, o processo e o produto de software têm certos atributos. Isto inclui a fórmula para determinar o valor da métrica como também sua forma de apresentação e as diretrizes de utilização e interpretação dos resultados obtidos no contexto do ambiente de desenvolvimento de software, de acordo com o IFPUG (2003). Em uma organização que se dedica ao desenvolvimento, seja como atividade-fim, seja como de suporte para uma empresa, há vários objetivos que se busca atingir, dependendo do estágio de maturidade em que se encontram essas atividades. Alguns dos objetivos definidos pela Engenharia de Software se enquadram na seguinte relação, de acordo com Feigenbaum (1986): a) Melhorar a qualidade do planejamento do projeto, b) Aumentar a satisfação dos usuários e clientes do software, c) Aumentar a produtividade e qualidade do desenvolvimento, e d) Aperfeiçoar continuamente os métodos de gestão de projeto. As métricas devem ser objetivas, visando reduzir ou minimizar a influência do julgamento pessoal na coleta, cálculo e análise dos resultados, bem como devem ser selecionadas para proporcionar informações que possibilitem avaliar acertos de decisões e ações realizadas no passado, evidenciar a ocorrência de eventos presentes que subsidiem decisões tempestivas, bem como prever a possibilidade de ocorrência de eventos futuros. Dentre os tipos de medições, o presente trabalho particularmente foca a análise daquelas de natureza preditiva, já que se tratam de estimativas necessárias ao processo de planejamento de um projeto, onde se tem que efetuar medições que vão subsidiar a gestão do processo de desenvolvimento de software, sendo que as principais são: a) Estimativa do tamanho do software, b) Estimativa do prazo do projeto, c) Estimativa do esforço do projeto, e d) Estimativa do custo para o projeto. Dentro das técnicas disponíveis, vamos destacar a FPA, apresentada em Braga (1995), e a UCP, apresentada em Karner (1993), já que elas atuam nas fases de entendimento e mapeamento dos requisitos de um futuro software e tambem são independentes da tecnologia aplicada. 4.1 FPA (Function Point Analysis) - A técnica de Análise por Pontos de Função A APF (Análise por Pontos de Função) é uma técnica estruturada de classificação de elementos ou componentes de um sistema. Ela é um método que foi inicialmente desenvolvido por Allan J. Albrecht na década de 1970, para dividir um sistema em pequenos componentes, permitindo que ele possa ser mais bem entendido e analisado, fornecendo uma técnica estruturada para resolver problemas, (IFPUG, 2003). Na técnica APF os sistemas ou futuros sistemas são divididos em cinco grandes classes de características gerais, denominadas de Funções. Elas são classificadas em: Funções Transacionais São três classes de componentes que atuam através de transações: Entradas Externas, Saídas Externas e Consultas Externas e Funções de Informações Lógicas (ou funções de dados) São as outras duas classes que atuam nos dados armazenados que são combinados para gerar as informações lógicas., (Trindade, 1999) Objetivos da Análise por Pontos de Função (APF) A proposta dos Pontos de Função é medir um sistema aplicativo sob a perspectiva de sua funcionalidade independentemente da tecnologia que será usada na sua implementação. Para a técnica APF o numero de pontos de função independe da linguagem usada, dos métodos de ENEGEP 2003 ABEPRO 2

3 desenvolvimento aplicados ou da plataforma de hardware que receberá o sistema. A única variável é a quantidade de esforço necessário para executar um conjunto de pontos de função. A técnica pode ser usada para determinar se uma ferramenta, uma linguagem ou um ambiente é mais produtivo comparado com outros dentro de uma organização. Ex: Qual o esforço em pontos de função seria necessário para desenvolver um programa em Cobol e para desenvolvê-lo em Java? Este é um ponto crítico e de grande valor para a aplicação da técnica APF. Os pontos de função podem ser calculados em diversos pontos do ciclo de desenvolvimento de um sistema, permitindo que os valores sejam comparados e avaliados, dando margens a novas negociações com os clientes e ajustes nos cálculos de novos sistemas. Este é um ótimo mecanismo de melhoria de processo. As medidas podem ser efetuadas ao fim do levantamento dos requisitos, da análise, do design, da codificação e dos testes de aceite pelos clientes. Estes valores irão formando uma base histórica de medidas que permitirão ajustes nos índices de produtividade das equipes, bem como, uma melhor avaliação das funções para os próximos sistemas, (Costa, 1999) Problemas no uso da técnica APF Quando em uso em um estágio de alto nível de abstração, a técnica APF exige pessoal experiente e bem treinado, senão corre-se o risco de se obter medidas incorretas que levarão a problemas sérios com relação ao tamanho do sistema e daí nos prazos, recursos e custos associados. A técnica APF como foi desenvolvida originalmente exige um certo nível de detalhamento e conhecimento das 5 funcionalidades. Telas de entrada e saída, layouts de relatórios, layouts das interfaces, definição dos arquivos de armazenamento são todos necessários na aplicação da APF Os cinco componentes da APF Como um sistema aplicativo interage com outros aplicativos da empresa, um desenvolvedor precisa mapear as fronteiras do seu aplicativo para que ele possa ser medido através da classificação de seus componentes. Este mapa deve ser desenhado de acordo com o ponto de vista dos usuários. Este mapa deve mostrar as fronteiras entre o projeto sendo medido e as aplicações externas envolvidas ou o domínio do usuário. Uma vez, as fronteiras definidas, os componentes podem ser classificados, ranqueados e medidos. A figura 1 mostra sintéticamente uma visão dos cinco componentes envolvidos na técnica APF, durante as medidas de tamanho de um sistema aplicativo. Figura 1 - Funcionalidade vista segundo a perspectiva do usuário ENEGEP 2003 ABEPRO 3

4 Para cada componente de entrada, saída, consulta, interface e arquivamento é montada uma tabela de complexidade e de pontos conforme mostradas e detalhadas nas referências bibliográficas do artigo. As complexidades dos componentes são determinadas dependente do tipo de componente ou função que está sendo analisada, e a partir delas a soma dos pontos de função de um sistema aplicativo é calculada e a atividade é denominada de cálculo de pontos de função não ajustados, (IFPUG, 2003). Após a identificação dos componentes ou funções do sistema aplicativo, eles devem ser classificados conforme seus níveis de complexidade, se baixa, média ou alta. Uma vez que as funções estejam classificadas conforme sua complexidade, deve-se utilizar a tabela de peso da complexidade pertencente a técnica para obter-se a transformação da complexidade e pesos em número de pontos de função. 5. A técnica de estimativa de tamanho de projetos de software Pontos de Caso de Uso (Use Case Points) Alguns autores afirmam que apesar do bom resultado decorrente da aplicação da técnica de Pontos de Função nesses últimos anos, ela exige a aplicação de um método complexo, que se baseia em tabelas e fórmulas de cálculos de ajuste para se chegar ao tamanho e ao custo de um software especifico, (Karner, 1993). O principal problema apontado no uso da APF, é que ela baseia-se na análise dos requisitos que o sistema aplicativo irá incorporar para determinar seu tamanho, porém faz-se necessário um nível de detalhamento muito alto que na maioria dos casos, só é perfeitamente estimável depois de realizado todo o levantamento e detalhamento dos requisitos e terminada a construção dos primeiros protótipos. Porém, os clientes logo no inicio da negociação exigem que seja dado o prazo e o custo do aplicativo, para que seja efetuado o contrato de desenvolvimento. Para tentar resolver esse problema Karner (1993), da Rational, propõe uma nova técnica de estimativa por UCP (Use Case Points), que parte do diagrama Use Case que descreve as funcionalidades do sistema de acordo com a forma de utilização do aplicativo pelos usuários. Dessa forma a estimativa pode ser realizada logo no inicio dos trabalhos, durante o mapeamento dos requisitos dos clientes ou usuários. 5.1 Método de cálculo usando UCP para estimativas de software De acordo com Karner (1993), uma vez que os casos de uso principais do aplicativo sejam levantados, é possível estimar-se o tamanho do software como um todo baseando-se em um conjunto simples de métricas e modificadores, similar à técnica de Pontos de Função. O principal problema apontado para o método é o nível de detalhamento dos Casos de Uso, pois, na maioria das vezes, caberá aos analistas decidir a granularidade ideal dos UCP utilizados para a medição. 5.2 Passos da técnica de medição UCP Classificar os atores envolvidos em cada Caso de Uso. A classificação dos atores de um Caso de Uso permitirá calcular-se um somatório de pontos não-ajustados, conforme mostra a tabela abaixo. Tipo de ator Peso Descrição Simples 1 Quando o ator representa um sistema externo que é acessado através de uma API de programação ou outro acesso direto e local Médio 2 Quando o ator representa um sistema externo, que reside em outro local, e é acessado através de protocolo de comunicação tipo TCP/IP Complexo 3 Quando o ator representa um usuário que interage com o sistema através de uma interface gráfica cliente-servidor ou WEB Tabela 1 Peso de atores ENEGEP 2003 ABEPRO 4

5 O peso total dos atores do sistema UAW (Unadjusted Actor Weight) é calculado pela soma dos produtos do numero dos atores de cada tipo pelo respectivo peso. Calcular o valor inicial do peso bruto dos Casos de Uso denominado UUCW (Unadjusted Use Case Weight) através da divisão dos Casos de Uso em três níveis de complexidade, de acordo com o número de transações envolvidas em seu processamento. Tipo de UCP Numero de Transações Peso Simples Até 3 1 Médio 4 a 7 2 Complexo 7 ou mais 3 Tabela 2 Peso de UCPs por numero de transações Outra forma de calcular o peso bruto dos Casos de Uso é levar em consideração o numero de classes envolvidas no processo e deve ser aplicado quando já for possível antever as entidades envolvidas em um dado processo. Tipo de UCP Numero de Entidades (Classes de Objetos) Peso Simples 5 ou menos 1 Médio 5 a 10 2 Complexo Mais de 10 3 Tabela 3 Peso de UCPs por numero de Entidades A terceira forma utiliza uma regra de comparação simples. A regra é aplicada a cada UCP do sistema e os valores são somados para se obter a UUCW total. É uma fórmula mais rápida e menos precisas que as duas anteriores. Se o Caso de Uso for considerado simples, isto é, conter uma interface simples com o usuário e utilizar apenas uma entidade em um banco de dados, o caso de uso é considerado simples e tem peso 5. Se o Caso de Uso envolve uma interface mais trabalhada e utiliza-se de duas ou mais entidades de banco de dados, o caso de uso é considerado médio e tem peso 10. Se o Caso de Uso envolver três ou mais entidades em um banco de dados e contiver uma interface complexa, o caso de uso recebe um peso de 15. O peso total não ajustado é calculado pela soma entre os pesos de atores e casos de usos: UUCP = UAW + UUCW Calcular os fatores de ajuste de forma similar ao da técnica de Pontos de Função. Inicialmente é feito um cálculo de fatores técnicos, cobrindo uma série de requisitos funcionais do aplicativo e um cálculo de fatores de ambiente que são os requisitos não funcionais associados ao processo de desenvolvimento. Estes dois fatores geram multiplicadores distintos, que devem ser aplicados ao UUCP do aplicativo. Para calcular o fator de complexidade técnica do aplicativo TCF (Technical Complexity Factor), utiliza-se a tabela 3 e aplicando-se a seguinte fórmula: TCF = (0.01 x TFactor), sendo que o valor do TFactor é obtido pela soma dos níveis de influencia atribuídos a cada fator multiplicados pelo seu peso correspondente. Para calcular os fatores ambientais previstos pela técnica UCP, o nível de influência indica o nível de disponibilidade de cada recurso no decorrer do projeto. A fórmula para calcular os fatores ambientais EF é a seguinte: EF = (-0.03 x EFactor) onde o valor de EFactor é dado pela soma dos produtos entre o peso de cada fator (E1 a E8) e seu grau de influência atribuído. Os fatores ambientais tendem ENEGEP 2003 ABEPRO 5

6 a diminuir o valor em UCP do aplicativo, pois eles refletem o ganho de velocidade proporcionado ao aplicativo no seu desenvolvimento. Fator Descrição Peso E1 Familiaridade com um processo formal de desenvolvimento 1.5 E2 Experiência com a aplicação em desenvolvimento 0.5 E3 Experiência em OO 1 E4 Presença de analista esxperiente na equipe do projeto 0.5 E5 Motivação da equipe envolvida 1 E6 Requisitos estáveis 2 E7 Desenvolvedores em meio expediente -1 E8 Linguagem de programação difícil 2 Tabela 4 Pesos de fatores ambientais Finalmente, podemos agora calcular o porte do aplicativo em UCP usando a seguinte fórmula: UCP = UUCP x TCF x EF Ainda segundo Karner, pode-se estimar o tempo necessário para o desenvolvimento do projeto calculando-se uma média de 20 horas de trabalho por UCP, sendo que as experiências demonstram uma variação entre 15 horas a 30 horas por Ponto. 6. A aplicação da Curva ABC na técnica de Análise por Pontos de Função Os princípios envolvidos na classificação ABC ou curva ABC é atribuído a Vilfredo Paretto, um italiano, que em 1897 executou um estudo sobre a distribuição de renda na Itália. Através desse estudo, ele percebeu que a distribuição de riqueza não se dava de maneira uniforme, havendo grande concentração de riqueza ( 80% ) nas mãos de uma pequena parcela da população ( 20% ). A partir de então, tal princípio de análise tem sido estendido a outras áreas e atividades tais como a industrial e a comercial, sendo mais amplamente aplicado a partir da segunda metade do século vinte. Sua utilização como uma ferramenta gerencial na administração de estoques, na definição de políticas de vendas, no planejamento da logística de distribuição de produtos, na programação da produção e numa série de problemas usuais de empresas, de características industriais, comerciais ou de prestação de serviços têm-se mostrado de relevância significativa. 6.1 A Técnica ABC (curva ABC) Para apresentar a técnica ABC vamos usar como exemplo uma análise clássica que é aplicada em itens de estoque: Esta análise clássica consiste da separação dos itens de estoque em três grupos de acordo com o valor de demanda em um certo período, por exemplo, anual, em se tratando de produtos acabados, ou valor de consumo anual quando se tratarem de produtos em processo ou matérias-primas e insumos. O valor de consumo anual ou valor de demanda anual é determinado multiplicando-se o preço ou custo unitário de cada item pelo seu consumo ou por sua demanda anual. A análise dos valores obtidos dará um resultado típico de classificação ABC, já que surgirão grupos que podem ser divididos em três classes: Classe A: Itens que possuem alto valor de demanda ou consumo anual, Classe B: Itens que possuem um valor de demanda ou consumo anual médio ou intermediário, e Classe C: Itens que possuem um valor baixo de demanda ou consumo anual. ENEGEP 2003 ABEPRO 6

7 Figura 2 Agrupamento de itens de estoque de acordo com a curva ABC Esta classificação ABC de itens de estoque tida como típica apresenta uma configuração na qual 20% dos itens são considerados A e que correspondem por 65% do valor de demanda ou consumo anual. Os itens B representam 30% do total de número de itens e 25% do valor de demanda ou consumo anual. Tem-se ainda que os restantes 50% dos itens e 10% do valor de consumo anual serão considerados de classe C. Mesmo sabendo-se que esses percentuais de classificação variam de empresa para empresa, é importante observar que o princípio da curva ABC no qual uma pequena percentagem de itens é responsável por uma grande percentagem do valor de demanda ou consumo anual, normalmente ocorre em qualquer uma delas. Uma análise ABC deve obrigatoriamente refletir a dificuldade de controle de um item e o impacto deste item sobre os custos e a rentabilidade, o que de certa maneira pode variar de empresa para empresa. Deve-se ter em mente ainda que, apesar da análise ABC ser usualmente ilustrada através do valor de consumo anual, este é apenas um dos muitos critérios que pode afetar a classificação de um item. É inegável a utilidade da aplicação do princípio ABC aos mais variados tipos de análise onde busca-se priorizar o estabelecimento do que é mais ou menos importante num extenso universo de situações e, por conseqüência, estabelecer-se o que merece mais ou menos atenção por parte da administração. 7. Proposta do uso da curva ABC na técnica de Pontos de Função O que se nota na técnica UCP é que ela é mais empírica do que a proposta da técnica de Pontos de Função, já que a classificação dos Casos de Uso e a obtenção de seus pesos dependem fundamentalmente do nível de detalhamento ou do conhecimento que se tem das funcionalidades executadas pelo aplicativo. Por outro lado nota-se que os 5 componentes ou funções da técnica de Pontos de Função foram classificadas por Albrecth como de baixa, média e alta complexidade. Para cada uma delas ele através de estatísticas em centenas de projetos atribui pesos que representam as complexidades de processamento dependente de dados e registros lógicos manipulados. Aplicando-se a curva ABC de Paretto para os 5 componentes ou funções de entrada externa, saída externa, consulta externa, arquivos de interface externa e arquivos lógicos internos obtidos a partir de uma análise dos requisitos e usando-se os mesmos valores encontrados nas estatísticas de Paretto teremos o total de pontos de função (TPF) do aplicativo em estudo. Onde TPF é o total de pontos de função brutos do aplicativo. Para se encontrar o número de pontos de função ajustado deve-se aplicar as mesmas regras da técnica APF proposta originalmente por Albrecht. A partir do número de pontos de função ajustados e de uma base histórica da produtividade da equipe de desenvolvimento de software pode-se chegar ao tamanho do aplicativo, ao prazo ENEGEP 2003 ABEPRO 7

8 ótimo e a distribuição dos recursos de desenvolvimento ao longo do processo e finalmente o custo do projeto. Figura 3 Distribuição dos componentes de entrada de diversos aplicativos medidos 8. Conclusão Fernandes (1995), sugere um modelo de medições, visando definir as estimativas de tempo, qualidade, recursos, prazo, confiabilidade, de forma que o desenvolvimento do software, assim como a gestão do produto, possa ser gerenciada. Qualquer que seja o método proposto para a estimativa de horas de desenvolvimento de software, sempre haverá uma dependência de vários fatores: Ambiente de programação envolvida (linguagens de terceira ou Quarta geração), experiência da equipe envolvida, disponibilidade de máquina para o desenvolvimento e testes, utilização de ferramental adequado (utilitários, geradores de massa de teste, ferramentas CASE, geradores de banco de dados, bibliotecas de reusabilidade, uso de objetos, uso de padrões), etc. A aplicação de um método para a medição de programas, que seja simples, padronizado e de uso corrente no mercado, é fundamental para a resolução do maior problema encontrado na contratação e gestão dos trabalhos das empresas de software. Como em diversos casos reais tem-se obtido uma divergência em torno de 10% entre os prazos obtidos pela APF com curva ABC e pela UCP e como a técnica de pontos de função nos dá uma certeza mais confiável devido aos vários anos de uso e a sua comprovação na prática. Somente aplicando métodos baseados em métricas já conhecidos e praticados com resultados conhecidos é que se permitirá às empresas acumularem experiências no ajuste de seus índices de produtividade e a partir dai obterem os valores corretos para a sua realidade, (Longstreet, 2003). Referências BRAGA, A. (1995) - Análise por Pontos de Função. RJ, IBPI Press. FEIGENBAUM, A. V. (1986) - Total quality control. 3. ed. New York, cgraw Hill. FERNANDES, A. A. (1995) - Gerência de Software através de métricas, São Paulo, Editora Atlas. IFPUG. (2003) - Functions Points couting practise manual, Release 4, Westerville, Ohio. PRESSMAN, R. S. (2000) - Software Engineering, A practitioner`s Approach. London, McGraw-Hill. TRINDADE, A. L. P. (1999) - Métricas para orçamento e planejamento da produção de software, Dissertação apresentada à Escola Politécnica da USP para obtenção de Mestre em Engenharia. São Paulo. KARNER, G. (1993) EUA. LONGSTREET, D. (2003) Use Cases e Function Points. ENEGEP 2003 ABEPRO 8