Uma Simplificação da Técnica Análise de Pontos … através do método simplificado ficaram...

Uma Simplificação da Técnica Análise de Pontos de FunçãoPara Estimar Tamanho de Aplicativos Web

Edilson José Davoglio Cândido1∗, Rosely Sanches1

1LABES - Laboratório de Engenharia de SoftwareInstituto de Ciências Matemáticas e de Computação

Universidade de São PauloAv. do Trabalhador São Carlense, 400 - CentroCaixa Postal 668 – 13560-970 São Carlos, SP

[email protected], [email protected]

Abstract. Software size estimation is a key factor to determine the amount oftime and effort needed to develop software systems, and the web applicationsare no exception. In this paper a simplified way of the IFPUG (InternationalFunction Point Users Group) function points, based on the simplification ideassuggested by NESMA (Netherlands Software Metrics Association) to estimatesize of management information systems, and the requirements of a tool to sup-port the counting and determine the team productivity are presented. In an em-pirical study, twenty web applications were analyzed. The estimates using thesimplified method were close to the ones using the IFPUG method. Based onthe results, it was possible to establish a simplified method to estimate the sizeof web applications according to the development characteristics of the studiedcompany.

Resumo.A estimativa de tamanho de software é fundamental para determi-nar as estimativas de esforço e tempo de desenvolvimento necessários à cons-trução de um software, e os aplicativos desenvolvidos para web não são umaexceção a essa premissa. Neste trabalho é apresentada uma simplificação dacontagem de pontos de função promovida pelo IFPUG (International FunctionPoint Users Group) utilizando como princípio as idéias de simplificação su-geridas pela NESMA (Netherlands Software Metrics Association) para estimarsistemas de informação, além dos requisitos de uma ferramenta para apoiaro processo de contagem dos pontos de função e determinar a produtividade.Em um estudo empírico foram analisadas vinte aplicações web e as estimativasobtidas através do método simplificado ficaram bastante próximas das obtidascom o método do IFPUG. Isso permitiu estabelecer um método de estimativa detamanho simplificado para aplicativos web, levando em consideração as carac-terísticas de desenvolvimento da empresa estudada.

1. Introdução

Para que as empresas de desenvolvimento de software construam aplicativos em tempohábil e com qualidade, é necessário que elas possuam uma gestão efetiva de seus pro-cessos de software [Humphrey, 1989]. O gerenciamento do processo de software en-volve quantificar e qualificar os projetos, produtos, processos e recursos de software[Fenton, 1997].

∗Este trabalho contou com o apoio financeiro do CNPQ.

IV SBQS - IV Concurso de Teses e Dissertações em Qualidade de Software

Sob a ótica do projeto, é amplamente aceito que as estimativas de tamanhode software são fundamentais para a determinação dos custos do projeto de software[Jones, 1998], [Lai, 2003], [Hastings, 2001], [Briand, 2002] (no sentido de esforço etempo de desenvolvimento necessários a construção de um software). Padrões de mo-delos de referência para qualidade do processo de software, tais como o SW CMMI, aNorma 15504 e a Norma ISO 12207, relatam a importância da elaboração de estimati-vas de tamanho de software como uma das atividades de planejamento do projeto. Osaplicativos web não são uma exceção a essas premissas.

Entretanto, segundo pesquisa do Ministério da Ciência e Tecnologia, no Brasil,apenas cerca de 29% das empresas realizam estimativas de tamanho de software[MCTtab40, 2001]. Apesar de não haver uma pesquisa para o quadro das empresasque desenvolvem exclusivamente aplicativos web, a análise do número citado em con-junto com o fato de que 45% das empresas pesquisadas desenvolvem aplicativos web[MCTtab01, 2001] indica que essas empresas se coloquem em situação parecida.

O estudo de um método de estimativa de tamanho de software simplificado paraaplicativos web poderia colaborar para a mudança desse quadro. Assim, o objetivo destetrabalho é apresentar um método simples e de fácil execução, mas também consistente ecapaz de colaborar para a realização de estimativas de tamanho de software confiáveis,incentivando a utilização das estimativas de tamanho e conseqüentemente, colaborandopara a obtenção de qualidade nos processos de desenvolvimento de software.

O método foi abstraído através de um estudo de caso utilizando dados de vinteaplicativos web desenvolvidos pela empresa Linkway [Linkway, 2005], que tem comoprincipal atividade o desenvolvimento de aplicativos web. O método baseia-se na con-tagem de pontos de função do IFPUG e nas idéias de simplificação utilizadas pelaNESMA para elaborar fórmulas simplificadas de estimativa de tamanho de sistemas deinformação administrativos (MIS -Management Information Systems).

Outras empresas que possuam características de desenvolvimento semelhantes asda empresa estudada podem verificar a utilidade do método para o seu ambiente de de-senvolvimento ou basear-se no mesmo para elaborar seus próprios métodos.

O restante do artigo é organizado como segue. Na seção 2 é apresentada umabreve descrição das estimativas de tamanho de software. Na seção 3 descreve-se comoo método simplificado e os resultados foram obtidos. Na seção 4, a modelagem de umaferramenta para apoiar o processo é descrita. Finalmente, na seção 5, as conclusões etrabalhos futuros são apresentados.

2. Estimativa de Tamanho de Software

A estimativa de tamanho de software é considerada uma tarefa fundamental do gerenci-amento de software. A partir dela, é possível predizer as estimativas de esforço e tempode desenvolvimento, que auxiliam nas tomadas de decisões durante o processo de de-senvolvimento do software [Agarval, 2001], [Dolado, 2000]. As estimativas baseadas emlinhas de código (LOC -Lines Of Code) ou nas funcionalidades que o software apresentasão duas medidas bastante utilizadas para determinar o tamanho de um software.

As linhas de código são medidas diretas que podem ser facilmente contadas emanipuladas, uma vez que o software tenha sido desenvolvido [Pressman, 2001]. Há umagrande variedade de formas para se calcular as linhas de código. Jones [Jones, 1998]sugere onze possíveis variações para a contagem das linhas de código de um programa.Fenton et al. [Fenton, 1997] apresentam algumas variações e as implicações que elaspodem causar. Ainda segundo Fenton et al., a definição mais aceita para se contar as


LOC é a daHewlett-Packard, na qual cada programa é considerado uma lista simples dearquivos, e os comentários e linhas em branco são removidos.

Há muita discussão em relação à utilização de LOC para estimativas de tamanhode software. As críticas baseiam-se na argumentação de que as linhas de código sãodependentes da linguagem de programação e que seu uso na estimativa requer um nívelde detalhes que pode ser difícil de alcançar antes que a análise e o projeto tenham sidocompletados [Jones, 1986], [Briand, 2002].

Por sua vez, as estimativas de tamanho baseadas na funcionalidade definem ele-mentos que podem ser contados previamente, refletindo as características funcionais apre-sentadas pelo software. Os conceitos desse tipo de contagem foram propostos por Al-brecht em 1979 [Albrecht, 1979]. Desde então, eles vêm sendo refinados, principalmentedepois da criação de organizações voltadas exclusivamente para o desenvolvimento datécnica [IFPUG, 2005], [NESMA, 2005].

No último ano, quatro métodos de estimativa de tamanho de software (IFPUG,NESMA, MarkII, COSMIC-Full Function Points) foram aprovados como padrão ISOpara medição de tamanho funcional, sob a denominação de ISO\IEC 20926:2003(IFPUG), ISO\IEC 24570:2003 (NESMA), ISO\IEC 20968:2003 (MarkII), e ISO\IEC19761:2003 (COSMIC-FFP).

2.1. Pontos de Função Segundo o IFPUG

O IFPUG [IFPUG, 2005] é uma organização fundada em 1986, sem fins lucrativos, quepromove a utilização da técnica análise de pontos de função para estimar tamanho desoftware. Ela mantém um manual de práticas de contagem, o CPM (Counting PracticesManual), atualmente na versão 4.2 [IFPUG, 2004], cujo intuito é a padronização do pro-cesso de contagem.

O procedimento de contagem dos pontos função elaborado pelo IFPUG, descritono manual de práticas de contagem, possui sete etapas, que podem ser visualizadas nafigura 1.

Figura 1: Fluxograma do Procedimento de Contagem dos Pontos de Função[IFPUG, 2004]

A seguir, são descritas, de forma resumida, cada uma das etapas.

1) Determinar o tipo de Contagem: Projeto de Desenvolvimento, Projeto deManutenção ou Aplicação.


2) Identificar o Escopo de Contagem e a Fronteira da Aplicação: O escopo decontagem define as funcionalidades que serão incluídas em uma determinada contagem.Já a fronteira da aplicação indica o limite lógico entre o usuário e a aplicação que estásendo medida, identificando as funções internas e externas a ela.

3) Contar as Funções de Dados: As funções de dados representam as funcionali-dades fornecidas pelo sistema ao usuário, para atender suas necessidades de dados. Essasfunções podem ser classificadas em Arquivos Lógicos Internos (ALIs) ou Arquivos deInterface Externa (AIEs). Após identificar os ALIs e AIEs, é preciso determinar a com-plexidade de cada um deles através da identificação e contagem dos DETs1 (data elementtype) e RETs (record element type). Um DET é um campo único, não repetido, e reco-nhecido pelo usuário. Um RET é um subgrupo de DETs, reconhecido pelo usuário e quefaz parte de um ALI ou AIE.

4) Contar as Funções Transacionais: As funções transacionais representam as fun-cionalidades de processamento de dados fornecidas pela aplicação ao usuário. Elas sãoclassificadas em Entradas Externas (EEs), Saídas Externas (SEs) ou Consultas Externas(CEs). A complexidade das funções transacionais baseia-se na identificação e contagemdos DETs e FTRs (file type referenced) de cada uma delas. Um FTR é um ALI lido oumantido pela função transacional, ou um AIE lido pela função transacional. Cada funçãotransacional possui regras específicas para a identificação dos FTRs.

5) Determinar os Pontos de Função Não Ajustados: Uma vez identificadas e clas-sificadas as funções de dados (ALIs e AIEs) e transacionais (EEs, SEs, CEs), basta somartodas as complexidades funcionais convertidas em pontos de função para obter os pontosde função não ajustados.

6) Determinar o Fator de Ajuste: O fator de ajuste é responsável por ajustar acontagem dos pontos de função não ajustados, produzindo uma variação na contagem demais ou menos 35 %. Ele é baseado nas 14 Características Gerais dos Sistemas (CGS),responsáveis por avaliar as funcionalidades que afetam a aplicação de uma maneira geral.

7) Calcular os Pontos de Função Ajustados: A última etapa do procedimento decontagem dos pontos de função inclui as fórmulas para o cálculo dos três tipos de con-tagem: projeto de desenvolvimento, projeto de manutenção ou aplicação.

As pesquisas baseadas nos pontos de função promovidos pelo IFPUG envolvemcríticas e descréditos em relação à técnica, argumentações sobre sua utilidade, tentativasde simplificação e criação de métodos específicos para uma determinada tecnologia dedesenvolvimento de software.

Kitchenham [Kitchenham, 1997] diz que os pontos de função não são as medidassimples e sem dificuldades que as pessoas imaginam que elas sejam. Kitchenham apontacomo um dos problemas a transformação das complexidades simples, média ou alta emnúmeros, não sendo possível definir diferenças entre os valores, ou seja, dizer que 4 é odobro da quantidade do valor 2. Outro ponto relaciona-se com o fator de ajuste, baseadoem uma avaliação subjetiva de quatorze características. Segundo a pesquisadora, não háevidências de que elas melhorem qualquer modelo de previsão de tamanho de softwareenvolvendo os pontos de função.

As análises de Lokan [Lokan, 2000] ratificam os argumentos de Kitchenham[Kitchenham, 1997]. Ele conclui, através de um estudo empírico, que as CGS (Carac-terísticas Gerais dos Sistemas) não devem ser utilizadas para determinar o fator de ajustepelo fato de existirem muitas dúvidas sobre a forma como são determinadas.

1as regras de identificação e contagem dos DETs, RETs, e FTRs não são apresentadas neste artigo. Paratal, deve-se consultar [IFPUG, 2004].


A resposta às críticas foi dada por Furey [Furey, 1997] em um artigo no qual eleaponta razões para a utilização da técnica. Os pontos de função são perfeitos? Não.Eles são uma métrica útil? Na opinião de Furey, sim. Segundo ele, os pontos de funçãosão consistentes, independentes de tecnologia, repetíveis e ajudam a normalizar os dados,permitindo comparações.

Outro fato citado por Furey [Furey, 1997] é que, às vezes, as pessoas colocamênfase demais em uma métrica para fazer tudo, para ser chamada de "bala de prata".Deve-se lembrar que os pontos de função são bons para estimar a funcionalidade dossistemas. Quando utilizados com outras métricas são uma poderosa ferramenta para agerência do desenvolvimento de software.

A própria Kitchenham [Kitchenham, 1997] comenta que na maioria dos casos,se os pontos de função forem utilizados com cuidado em uma organização específica,provavelmente serão encontrados poucos problemas. E que seria um erro rejeitar os pon-tos e voltar às problemáticas linhas de código. Entretanto, ela destaca a necessidade deum refinamento da técnica.

A aprovação da técnica promovida pelo IFPUG como um padrão ISO reforça asua utilidade. Todavia, o padrão considera os procedimentos elaborados pela técnica atéa determinação dos pontos de função não ajustados. A utilização das CGS tornou-se op-cional a partir de 2002 como uma pré-condição para que a técnica se tornasse um padrãoISO. As CGS ainda são um dos pontos mais criticados da técnica devido à variação na in-terpretação das CGS, bem como a constatação de que algumas delas estão desatualizadas.Devido a isso, este estudo não considera as CGS. As análises e propostas baseiam-se nospontos de função não ajustados.

2.2. Pontos de Função Segundo a NESMA

A NESMA [NESMA, 2005] foi fundada em 1989 e é o maior grupo de usuários da técnicaanálise de pontos de função na Europa. A organização mantém seu próprio manual depráticas e contagem, atualmente na versão 2.0. Ela tem como objetivos coletar, manter edesenvolver conhecimento relacionado com a técnica de pontos de função, promover umapadronização do método e aumentar a sua utilização.

A NESMA reconhece três tipos de contagem de pontos de função: Detalhada,Estimada e Indicativa. A contagem detalhada é similar à utilizada pelo IFPUG. Segundoo próprio IFPUG, elas são similares em 95 % [IFPUG, 2005].

A diferença entre a contagem detalhada e a contagem estimada, é que, na con-tagem estimada, a complexidade das funções é determinada por um valor pré-definido.Após a identificação de todos os tipos de funções (de dados e transacionais), os ALIs eAIEs são sempre classificados como de complexidade baixa, e as EEs, SEs e CEs sãosempre consideradas como de complexidade média.

Já a contagem indicativa é baseada somente no número de funções de dados (ALIse AIEs), calculando o número de pontos de função não ajustados da seguinte forma:

Indicativa = (35 ∗ NroALIs) + (15 ∗ NroAIEs)

Nessa fórmula, é assumido que existem três entradas externas (para incluir, alterare excluir informações do ALI), duas saídas externas e uma consulta para cada ALI; umasaída externa e uma consulta externa para cada AIE.

Os números 35 e 15 são obtidos considerando-se as funções transacionais comode complexidade média e as funções de dados como de complexidade baixa. Além disso,


são assumidos dois pontos de função a mais para os arquivos lógicos, e um ponto defunção a mais para os arquivos de interface externa. Esses pontos de função assumidossão, segundo a NESMA, uma forma de ajustar a contagem.

2.3. Mark II

O MarkII ou Mk II foi criado por Charles Symons na década de 80, inspirado na propostade Albrecht. O método foi desenvolvido pela consultoria KPMG entre 1985 e 1986 comoum método proprietário, tornando-se de domínio público posteriormente. Atualmente, aorganização responsável por manter o padrão da técnica é a UKSMA (United KingdomSoftware Metrics Association).

O método MkII é aplicado nos países do Reino Unido e apresenta algumas dife-renças quando comparado com o do IFPUG. O MkII considera todos os requisitos comotransações lógicas, constituídas de uma entrada, algum tipo de processamento e um com-ponente de saída. Além disso o método produz estimativas muito maiores do que as doIFPUG quando grandes projetos são contados [Symons, 1999].

2.4. COSMIC-FFP

O COSMIC (Common Software Measurement International Consortium) foi criado noano de 1998 com o objetivo de desenvolver um novo método de medição funcional detamanho de software. O grupo revisou métodos de estimativas de tamanho de softwarejá existentes (IFPUG, MarkII, NESMA) e tentou se basear nas melhores característicasdeles para criar um novo método.

Esse novo método foi publicado em Novembro de 1999 como a versão 2.0 doCOSMIC-FFP (COSMICFull Function Points) [Cosmic-FFP, 2001]. O COSMIC-FFP édesenvolvido para ser aplicado em sistemas de informação e aplicações de tempo real.

3. Método Simplificado

O método foi abstraído através de um estudo de caso reunindo vinte aplicativos, realizadoem uma pequena empresa cuja principal atividade é o desenvolvimento de aplicativosweb. O método baseia-se na contagem de pontos de função do IFPUG e nas idéias desimplificação utilizadas pela NESMA para elaborar fórmulas simplificadas de estimativade tamanho de sistemas de informação administrativos (MIS -Management InformationSystems).

A condução do estudo de caso baseou-se nas seguintes etapas:

1) Contagem dos pontos de função de cada um dos aplicativos utilizando o métodoelaborado pelo IFPUG: A contagem dos pontos de função de cada uma das vinte apli-cações utilizando-se o método do IFPUG foi determinada com base na análise de requisi-tos dos aplicativos, nos aplicativos em si e também com o auxílio de um dos profissionaisda empresa.

A contagem dos pontos de função de cada uma das aplicações segundo o métodoelaborado pelo IFPUG apresentou os resultados mostrados na figura 2.

2) Análise das planilhas contendo a contagem dos pontos de função segundo ométodo do IFPUG: A análise mostrou que havia um predomínio de funções com com-plexidade funcional baixa e média. Isso motivou a tentativa de elaborar um método sim-plificado baseado em valores fixos para as complexidades dos ALIs, AIEs, EEs, SEs eCEs.


Figura 2: Contagem dos Pontos de Função Segundo o IFPUG

O método simplificado foi construído através de dois passos. No primeiro passoanalisou-se como deveriam ser fixadas as complexidades das funções de dados (ALIs eAIEs). A análise dessas funções mostrou que elas apresentavam complexidade funcionalbaixa. Portanto, para a elaboração do método simplificado, a complexidade funcional dosALIs e AIEs foi fixada como baixa.

O segundo passo foi analisar como deveriam ser fixadas as complexidades fun-cionais das funções transacionais (EEs, SEs, CEs). A análise mostrou que havia um pre-domínio da complexidade funcional baixa, mas que havia também várias funções comcomplexidade funcional média. Dessa forma, a solução encontrada foi determinar onúmero de pontos de função para cada uma das possíveis combinações das complexi-dades funcionais e analisar qual delas apresentava o melhor resultado.

As combinações foram criadas identificando cada entrada externa pela letraE,cada saída externa pela letraS e cada consulta externa pela letraC. Além disso, as com-plexidades funcionais foram identificadas pelas letrasb para baixa,m para média eapara alta. Foram excluídas dessa análise as combinações que possuíam mais de umafunção como de complexidade funcional alta, e aquelas que não possuíam ao menos umafunção com complexidade funcional baixa, pois essas combinações apresentavam resul-tados muito distantes dos encontrados pelo método do IFPUG.

Na tabela 1 são apresentados os pontos de função encontrados para cada uma dascombinações, analisando os vinte aplicativos.

Análises estatísticas foram realizadas com os dados das contagens no intuito dedeterminar qual das combinações apresentava os resultados mais próximos daqueles en-contrados pelo método do IFPUG. O software estatístico MiniTab versão 14 foi utilizadopara apoiar a execução dessas análises.

O primeiro teste realizado foi o de análise de variância (ANOVA -ANalysis OfVAriance). Com esse teste, foi verificado se havia diferença entre empregar uma ou outracombinação para estimar os pontos de função de forma simplificada. Caso não houvessediferença, o resultado encontrado seria sempre o mesmo, independente da combinaçãoutilizada e portanto, qualquer uma das combinações poderia ser utilizada.

O resultado do teste ANOVA é mostrado na tabela 2. Ele indicou que havia dife-


Tabela 1: Análise das Combinações das Complexidades Funcionais1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

IFPUG 350 157 188 283 282 69 192 101 89 238 168 265 111 248 131 274 240 251 206 163E=b;S=b;C=b 324 154 183 283 258 69 185 97 85 230 166 257 107 227 131 267 235 232 186 163E=b;S=m;C=b 336 157 187 288 262 72 192 102 88 232 168 260 110 236 133 268 238 243 194 164E=b;S=a;C=b 360 163 195 298 270 78 206 112 94 236 172 266 116 254 137 270 244 265 210 166E=b;S=a;C=m 391 179 215 332 298 84 226 118 102 259 188 294 125 274 153 305 272 284 227 186E=b;S=b;C=m 355 170 203 317 286 75 205 103 93 253 182 285 116 247 147 302 263 251 203 183E=b;S=m;C=m 367 173 207 322 290 78 212 108 96 255 184 288 119 256 149 303 266 262 211 184E=a;S=b;C=m 439 215 254 401 355 93 235 127 114 331 236 369 149 310 180 383 332 314 257 228E=a;S=b;C=b 408 199 234 367 327 87 221 121 106 308 220 341 140 290 164 348 304 295 240 208E=a;S=m;C=b 420 202 238 372 359 90 228 126 109 310 222 344 143 299 166 349 307 306 248 209E=m;S=m;C=b 366 172 204 316 313 78 208 110 95 258 186 288 121 257 144 295 261 264 212 179E=m;S=a;C=b 388 178 212 326 321 84 222 120 101 262 190 294 127 275 148 297 267 286 228 181E=b;S=m;C=a 429 205 247 390 346 90 252 120 112 301 216 344 137 296 181 373 322 300 245 224E=b;S=b;C=a 417 202 243 385 342 87 245 115 109 299 214 341 134 287 179 372 319 289 237 223E=m;S=b;C=a 445 217 260 413 365 93 261 123 116 325 232 369 145 308 190 399 342 310 255 238E=m;S=b;C=b 352 169 200 311 281 75 201 105 92 256 184 285 118 248 142 294 258 253 204 178E=m;S=b;C=m 383 185 220 345 309 81 221 111 100 279 200 313 127 268 158 329 286 272 221 198

rença significativa entre as combinações (p-valor é próximo de zero), permitindo classi-ficar as combinações de modo a determinar qual delas apresentava a contagem de pontosde função mais próxima da obtida pelo método do IFPUG.

Tabela 2: One-way ANOVAGraus de Soma dos Quadrado F p-valorLiberdade Quadrados Médio

fator 15 3,71357 0,24757 104,70 0,000Erro 304 0,71884 0,00236Total 319 4,43241

Essa classificação foi realizada com o teste de múltiplas comparações como melhor, de Hsu (Hsu’s MCB -Multiple Comparisons with the Best) [Hsu, 1984],[Hsu, 1996], capaz de determinar qual das combinações é a melhor. Como o objetivoé encontrar aquela que apresenta o menor erro, deve-se utilizar o método com a opção’Smallest is best’(o método que apresenta o menor erro é o melhor) no MiniTab.

Com essa configuração, o método Hsu’s MCB determina a melhor combinaçãoprocurando qual delas apresenta um intervalo de confiança que contenha o número zero.Na figura 3 o resultado do teste Hsu’s MCB é apresentado.

Figura 3: Gráfico Hsu’s MCB

Entre as combinações analisadas, quatro foram identificadas como as melho-res: (E=b;S=b;C=b), (E=b;S=m;C=b), (E=b;S=a;C=b) e (E=m;S=b;C=b), indicadas pe-los números 1), 2), 3) e 15), respectivamente. Portanto, estatisticamente, as combinações


(E=b;S=b;C=b), (E=b;S=m;C=b), (E=b;S=a;C=b) e (E=m;S=b;C=b) são as melhores epodem ser utilizadas como uma forma simplificada do método elaborado pelo IFPUG.

Após a identificação das melhores combinações, dentro do conjunto analisado,elaborou-se o ajuste para cada uma delas através da análise de regressão. O ajuste permiteque futuras contagens apresentem um resultado próximo do ideal, o qual seria obtido casoo método do IFPUG fosse aplicado.

O ajuste que deve ser utilizado para cada uma das combinações é exibido natabela 3. Na figura 4 é apresentado o gráfico de dispersão para uma das combinações,(E=b;S=b;C=b).

Tabela 3: Ajuste para as Combinações

Combinação Ajuste1) E=b;S=b;C=b PF = (valor - 6,102)/0,92782) E=b;S=m;C=b PF = (valor - 6,905)/0,94663) E=b;S=a;C=b PF = (valor - 8,511)/0,984015) E=m;S=b;C=b PF = (valor - 6,256)/1,019

Figura 4: Gráfico de Dispersão (E=b;S=b;C=b)

Portanto, uma vez contados os pontos de função utilizando-se uma das combi-nações apresentadas na tabela 3, deve-se subtrair uma constante do número encontrado(valor) e, em seguida, dividir o resultado por outra constante.

Nas figuras 5 e 6, gráficos mostram os pontos de função obtidos por essas combi-nações em comparação com a contagem do IFPUG. Na figura 5 são exibidas as contagensdos dez primeiros aplicativos e na figura 6 as contagens dos outros dez.

Os resultados observados nos gráficos (figuras 5 e 6) comprovam a possibilidadede utilização dessas combinações para estabelecer a contagem dos pontos de função deum aplicativo de forma simplificada.

3.1. Refinamento do Método Simplificado

Após as análises que determinaram os quatro possíveis métodos de simplificação, osaplicativos foram analisados novamente na tentativa de identificar alguma característica


Figura 5: Total de Pontos de Função (aplicações 1 a 10)

Figura 6: Total de Pontos de Função (aplicações 11 a 20)


que colaborasse para refinar a análise anterior. Assim, comparando os requisitos dosaplicativos, foi possível dividi-los em dois grupos, de acordo com as funcionalidades quenormalmente são implementadas quando cada aplicativo é desenvolvido.

O grupo 1 possui funcionalidades como a criação de enquetes para o usuário,gerenciamento de usuários e notícias e geração de relatórios. Já o grupo 2 possui, além dasfuncionalidades presentes nas aplicações do grupo 1, gerenciamento de produtos, carrinhode compras, formas de pagamento. A maneira como cada aplicativo de um determinadogrupo é construído é bastante semelhante. Isso induziu à verificação do comportamentode cada um dos grupos em separado.

Os passos realizados para a análise do comportamento dos grupos em separadosão idênticos aos utilizados para a análise de todos os aplicativos, exibida anteriormente.Portanto, primeiro o teste ANOVA é realizado, e caso as combinações sejam diferentes, oteste Hsu´s MCB é realizado. Em seguida, os ajustes são encontrados através da análisede regressão.

O teste ANOVA mostrou que havia diferenças tanto entre as combinações dogrupo 1 quanto entre as do grupo 2. O resultado do teste ANOVA permitiu a realiza-ção do teste Hsu’s MCB. O teste Hsu´s MCB indicou as combinações (E=b;S=b;C=b),(E=b;S=m;C=b) e (E=b; S=a;C=b) como as melhores para o grupo 1, e as combinações(E=b;S=a;C=b), (E=b;S=b;C=m), (E=b;S=m;C=m) e (E=m;S=b;C=b) como as melhorespara o grupo 2.

Estatisticamente, não há como afirmar que qualquer uma das três combinaçõesescolhidas como melhor solução para as aplicações do grupo 1 é melhor que as outrasduas. Para as quatro combinações do grupo 2 o raciocínio é o mesmo.

Dessa forma, foi escolhida de forma arbitrária a combinação (E=b;S=m;C=b), ouseja, mantendo os ALIs, AIEs, EEs e CEs como de complexidade baixa e as SEs comode complexidade média, para determinar os pontos de função dos aplicativos do grupo 1,e a combinação (E=b;S=b;C=m), ou seja, mantendo os ALIs, AIEs, EEs e SEs como decomplexidade baixa e as CEs como de complexidade média, para determinar os pontosde função dos aplicativos do grupo 2. Ainda é necessário observar o ajuste que deve serutilizado para cada uma das combinações.

Portanto, uma vez identificados os ALIs, AIEs, EEs, SES e CEs de um aplicativopertencente a um dos dois grupos, utiliza-se uma das combinações apresentadas na tabela4 para contar os pontos de função de forma simplificada.

Tabela 4: Método SimplificadoTipo de Arquivo Lógico Arquivo de Entrada Saída ConsultaFunção Interno Interface Externa Externa Externa Externa

ComplexidadeGrupo 1 baixa baixa baixa média baixaAjuste

Grupo 1 PF = (valor - 2,796)/0,9805

ComplexidadeGrupo 2 baixa baixa baixa baixa médiaAjuste

Grupo 2 PF = (valor + 14,76)/1,059

Na figura 7 é apresentada uma comparação entre o resultado da contagem uti-lizando essas combinações e o método do IFPUG.


Figura 7: Método do IFPUG x Método Simplificado

4. Apoio Automatizado

A ferramenta tem como finalidades determinar a produtividade dos funcionários na cons-trução dos aplicativos e contar os pontos de função utilizando o método simplificado. Apartir da produção de um histórico de produtividade, a contagem dos pontos de função,aliada a esse histórico, será capaz de permitir uma estimativa da previsão do tempo dedesenvolvimento necessário para cada um dos novos aplicativos.

A ferramenta é constituída por dois módulos. O módulo 1 implementa o gerenci-amento das atividades e projetos, obtendo e armazenando informações sobre cada um de-les. Esse módulo deve também garantir o controle das horas utilizadas pelos funcionáriosno desenvolvimento de cada aplicativo, funcionando como um sistema de contabilizaçãode tempo (time tracking).

O módulo 1 possuirá as seguintes funcionalidades:

- gerenciamento do acesso dos usuários.- criação de projetos e atividades.- gerenciamento de atividades.- armazenamento de horas utilizadas para o desenvolvimento de cada atividade do

projeto.- apresentação da produtividade dos funcionários.- envio de dados para o segundo módulo.

Já o módulo 2 é constituído por um software instalado em dispositivos móveis.Esse módulo é responsável por determinar a contagem dos pontos de função através da uti-lização do método simplificado, apresentado neste trabalho, e estimar o tempo necessáriopara o desenvolvimento de um aplicativo baseando-se no histórico de produtividade de-terminado pelo módulo 1. A idéia é permitir a possibilidade de se elaborar uma estimativado tempo necessário à construção do aplicativo durante as reuniões com o cliente.

Sempre que um projeto é encerrado, o módulo 1 atualiza o histórico de produ-tividade da equipe e envia essas informações para o módulo 2. Com essas informações,identificados os requisitos de um novo aplicativo, será possível apontar com maior pre-cisão o tempo estimado para o desenvolvimento de tal aplicativo. Uma visão geral daestrutura da ferramenta é apresentada na figura 8.


Figura 8: Visão Geral da Ferramenta

No diagrama de classes, há uma generalização representada pelas classes Usuário,Programador, Vendedor, e Gerente, na qual a classe Usuário é o elemento geral. Cadausuário pode realizar várias atividades, as quais são registradas pela classe Registro deAtividade. Uma outra função dessa classe é flexibilizar a realização de atividades, per-mitindo que um programador realize uma atividade não alocada a ele pelo gerente. Asatividades que o gerente aloca a um determinado usuário e que necessariamente devemser efetuadas por ele, são gerenciadas pela classe Ordem.

Figura 9: Diagrama de Classes

5. Conclusões e Trabalhos Futuros

A grande vantagem da utilização do método simplificado é o fato de, identificados osALIs, AIEs, EEs, SEs e CEs, a complexidade já está definida automaticamente, facili-tando o processo de estimativa do tamanho do software.


Entretanto, deve-se enfatizar que os resultados apresentados não podem ser gene-ralizados para qualquer outra empresa que desenvolve aplicativos web. Apesar disso, omodelo de elaboração do método simplificado pode ser utilizado para criar um métodoque seja específico para as características de desevolvimento de outras empresas.

Vale ressaltar também que um importante resultado deste trabalho foi alcançadocom a publicação dos resultados parciais na conferência LA-Web & WebMedia 2004[Cândido and Sanches, 2004].

A partir dos resultados deste trabalho, as seguintes linhas de pesquisa podem sersugeridas:

1) Apesar da não generalização do método simplificado para qualquer empresa de de-senvolvimento de aplicativos web, há a intenção de verificar a validade do métodoem outras organizações;

2) Analisar a necessidade da elaboração de Características Gerais dos Sistemas es-pecíficas para o ambiente de desenvolvimento web.

3) Implementar a ferramenta cujos requisitos foram apresentados neste trabalho.

Referências

Agarval (2001). Estimating software projects.Software Engineering Notes, vol. 26(nro4):60–67.

Albrecht (1979). Measuring application development productivity.Proc. IBM Applica-tions Development Symposium, pages 83–92.

Briand (2002). Software resource estimation.Encyclopedia of Software Engineering, vol.2(nro P-Z):1160–1196.

Cândido, E. and Sanches, R. (2004). Estimating the size of web applications by using asimplified function point analysis method.LA-Web/WebMedia 2004 Joint Conference,Proceedings of IEEE, pages 98–105.

Cosmic-FFP (2001).MeasurementManual. Cosmic, 2.1 edition.

Dolado (2000). A validation of the component-based method for software size estimation.IEEE Trans. Software Eng., vol. 26(nro 10):1006–1021.

Fenton (1997).Software Metrics: A Rigorous and Pratical Approach. PWS, 2 edition.

Furey (1997). Why we should use function points.IEEE Software, pages 28–29.

Hastings (2001). A vector-based approach to software size measurement and effort esti-mation. IEEE Trans. Software Eng., vol. 27(nro 4):337–350.

Hsu (1984). Constrained two-sided simultaneous confidence intervals for multiple com-parisons with the best.Annals of Statistics, vol. 12:1136–1144.

Hsu (1996).Multiple Comparisons, Theory and methods. Chapman e Hall.

Humphrey (1989).Managing the Software Process. Addison-Wesley.

IFPUG (2004).IFPUG Manual. IFPUG, 4.2 edition.

IFPUG (2005). International function point users group. Disponível emhttp://www.ifpug.org, último acesso em Março de 2005.

Jones (1986).Programming Productivity. McGraw-Hill.

Jones (1998).Estimating Software Costs. McGraw-Hill.


Kitchenham (1997). The problem with function points.IEEE Software, pages 29–31.

Lai (2003). A model for estimating the size of a formal communication protocol specifi-cation and its implementation.IEEE Trans. Software Eng., vol. 29(nro 1):46–62.

Linkway (2005). Linkway.Dísponivel em http://www.linkway.com.br, Último acesso emMarço de 2005.

Lokan (2000). An empirical analysis of function point adjustment factors.Information &Software Technology, vol. 42(nro 9).

MCTtab01 (2001). Qualidade e produtividade no setor de software.Disponível emhttp://www.mct.gov.br/Temas/info/Dsi/Quali2001/ Public2001.htm, Tabela 01 - Ativi-dades das Organizações no Tratamento de Software.

MCTtab40 (2001). Qualidade e produtividade no setor de software.Disponível emhttp://www.mct.gov.br/Temas/info/Dsi/Quali2001/ Public2001.htm, Tabela 40 - Práti-cas de Engenharia de Software Adotadas no Desenvolvimento e Manutenção de Soft-ware.

NESMA (2005). Netherlands software metrics association.Disponível emhttp://www.nesma.org/english/index.htm, último acesso em Março de 2005.

Pressman (2001).Engenharia de Software. McGraw-Hill, 5 edition.

Symons (1999). Conversion between ifpug 4.0 and mkii function points.Software Mea-surement Services.


Uma Simplificação da Técnica Análise de Pontos … através do método simplificado ficaram...

Documents

Transcript of Uma Simplificação da Técnica Análise de Pontos … através do método simplificado ficaram...