BOLETIM INFORMATIVO DA FATTO CONSULTORIA E SISTEMAS - MARÇO DE 2004



EVENTOS E NOTÍCIAS

1. CALENDÁRIO DE CURSOS PARA O PRIMEIRO SEMESTRE

Já está disponível na página principal do site da FATTO o calendário parcial dos cursos já programados para o ano de 2004.

Breve serão acrescentadas novas turmas e novos cursos!

Os cursos já programados são:

- Capacitação em APF: São Paulo, 17 e 18 de maio;
- Preparação para Certificação: São Paulo, 19, 24 e 31 de maio;
- Preparação para Certificação: Vitória, 8, 15 e 22 de maio;

Detalhes em http://www.fattoCS.com.br/.


2. PESQUISA DE LOCAIS DE PROVA PARA O PRÓXIMO EXAME CFPS NO BRASIL

O BFPUG já iniciou a pesquisa para definir as cidades onde ocorrerão os próximos exames de certificação do IFPUG. A data já está definida: 27 de junho. Se você tem interesse na certificação, participe e ajude a levar a prova para mais perto de você.

Para participar da pesquisa acesse: http://www.bfpug.com.br/pesquisacfps/CFPS041.htm.



RECURSOS

1. SOFTWARE DEVELOPMENT PROJECTS IN GOVERNMENT - PERFORMANCE, PRACTICES & PREDICTIONS

Este relatório elaborado pelo ISBSG com o patrocínio do governo do estado da Vitória-Austrália, tem o intuito de ajudar governos em todo o mundo a melhorar seu gerenciamento sobre projetos de software.

Para ler o documento acesse: http://www.asma.org.au/_html2003/docs/Software%20Development%20Projects%20in%20Government.pdf.



PERGUNTA E RESPOSTA

Nesta edição esta seção vem em dose tripla!

P.: O que são Pontos por Caso de Uso (ou Use Case Points)?

R.: Até há alguns anos atrás (início da década de 90) havia a falsa noção de que a APF não era adequada para medir sistemas orientados a objetos. Aqueles que compartilhavam desta noção, na prática desconheciam a APF.

Com a disseminação da construção e projeto de sistemas orientados a objetos, houve também uma mudança na forma de se especificar e modelar os sistemas. A UML e os casos de uso rapidamente tornaram-se padrão na indústria de software.

Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho acadêmico a metodologia dos Pontos por Caso de Uso (baseado na Análise de Pontos de Função) com o intuito de estimar recursos para projetos de software orientados a objeto desenvolvidos utilizando o processo Objectory.

O processo de medição do PCU consiste resumidamente em:

1 - Contar os atores e identificar sua complexidade;
2 - Contar os casos de uso e identificar sua complexidade;
3 - Calcular os PCUs não ajustados;
4 - Determinar o fator de complexidade técnica;
5 - Determinar o fator de complexidade ambiental;
6 - Calcular os PCUs ajustados;

Com o resultado desta medição e sabendo-se a produtividade média da organização para produzir um PCU, pode-se então estimar o esforço total para o projeto.


P.: Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)?

R.: Em primeiro lugar é preciso desmistificar que somente a técnica do PCU é adequada para medir sistemas cujos requisitos foram expressos através de casos de usos. A APF pode ser utilizada normalmente para estes casos como também para medir sistemas cujos requisitos foram escritos utilizando outra abordagem.

A seguir são listados as vantagens da APF sobre o PCU.

1. O PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa por casos de uso. A medição da APF independe da forma como os requisitos do software foram expressos. Esta vantagem da APF foi citada pelo próprio Gustav Karner em seu trabalho original.

2. Não é possível na prática aplicar o PCU na medição de aplicações existentes cuja documentação esteja desatualizada ou sequer exista. A alternativa seria escrever os casos de uso destas aplicações para só então medí-las! Porém isto tornaria a medição inviável devido ao alto custo. Com a APF é possível realizar a medição analisando-se a própria aplicação em uso. A medição de aplicações instaladas pode ser útil na elaboração de contratos de outsourcing de sistemas.

3. Não existe um padrão único para a escrita do caso de uso. Diferentes estilos na escrita dos caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU! A APF não sofre deste problema pois independe da forma como os requisitos são expressos.

4. Devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes há a necessidade de se obter uma estimativa antes da finalização desta etapa. O processo de medição da APF também só pode ser empregado após o levantamento dos requisitos do projeto. Porém existem técnicas estimativas de tamanho em pontos de função que podem ser aplicadas com sucesso antes da análise de requisitos ser concluída.

5. O método do PCU não contempla a medição de projetos de melhoria de software, somente projetos de desenvolvimento. A APF contempla a medição de projetos de desenvolvimento, projetos de melhoria e aplicações. Estes outros tipos de medição cumprem um importante papel em programas de métricas e na contratação do desenvolvimento de software.

6. Não existe um grupo de usuários ou organização responsável pela padronização ou evolução do método PCU; e a bibliografia sobre o assunto é escassa. Para a APF existe o IFPUG que é o responsável por manter o Manual de Práticas de Contagem - o padrão da técnica.

7. O método PCU não é aderente à norma ISO/IEC 14143 que define um modelo para a medição funcional de software. A APF, conforme o manual do IFPUG versão 4.1, está padronizada sob a norma ISO/IEC 20926.

8. Não existe um programa de certificação de profissionais que conheçam a técnica do PCU e saibam aplicá-la de forma adequada. A APF possui o programa de certificação CFPS.

9. O fator ambiental inserido no PCU dificulta sua aplicação em programas de métricas de software e benchmarking entre organizações, pois torna o tamanho de um projeto variável; sem que sua funcionalidade sequer mude. Se um mesmo projeto for entregue a duas equipes distintas a contagem dos pontos por caso de uso deste projeto será também diferente em cada situação. Ou seja, o mesmo projeto tem dois tamanhos!

10. A determinação dos fatores técnico e ambiental do PCU está sujeita a um certo grau de subjetividade que dificulta a consistência da aplicação do método em diferentes organizações. O fator de ajuste da APF também possui o mesmo problema, embora o IFPUG possua diretrizes específicas que ajudam a minimizar este impacto. No entanto o uso do fator de ajuste na APF é opcional e a contagem dos pontos de função não ajustados atualmente é um processo bem objetivo.

Dentre as desvantagens citadas do PCU em relação à APF, algumas podem ser superadas com alguns ajustes simples no método proposto por Karner. Entretanto outras demandariam um esforço substancial de pesquisa.

Embora a APF não seja uma técnica perfeita, pelo exposto pode-se concluir que o PCU não traz nenhum benefício adicional sobre a APF quando esta é aplicada corretamente; principalmente na gerência de projetos de software baseada em casos de uso.


P.: O que é Feature Point?

R.: O método Feature Point foi proposto por Capers Jones em 1986; mesmo ano de fundação do IFPUG e antes da primeira versão do Manual de Práticas de Contagem - publicado em 1988. O objetivo do método era o de medir com maior precisão softwares com grande complexidade algorítmica.

A idéia por trás do método era simples: acrescentar à APF mais uma dimensão além dos dados e transações - os algoritmos. No entanto a falta de uma taxonomia para classificar algoritmos dificultou a aplicação do método. Além disto o próprio conceito de algoritmo deveria ser melhor elaborado. Qual a granularidade que se deve utilizar para identificar o algoritmo?

Em seu livro "Applied Software Measurent" (segunda edição - 1996), Capers Jones ainda destacava que o método era experimental, isto dez anos após a proposta inicial. E até hoje na página da SPR - Software Productivity Research (www.spr.com), empresa fundada por ele, o método também é citado como experimental.

Ainda no livro, o autor também já reconhecia que os conceitos da APF tinham evoluído bastante, permitindo sua utilização também nesses domínios de problemas (softwares com complexidade algorítmica) com razoável sucesso.

Em resumo, embora o método Feature Points ainda seja eventualmente citado em alguns trabalhos acadêmicos, o mercado não aderiu a esta proposta.

________

Este informativo pode ser lido também através do link http://www.fattocs.com.br/bif2004-03.asp


Mantenha-se Atualizado. Assine o Boletim Informativo

Assine nosso boletim (ou atualize o seu cadastro se já for assinante): http://www.fattocs.com.br/cadastro_boletim.asp.

Todas as edições do boletim estão disponíveis em http://www.fattocs.com.br/bif.asp

Ou também podem ser lidas aqui

   Página Inicial   |    Indique o Site   |    EAD   |    Mapa do Site   |    Fale Conosco: fatto@fattocs.com.br


Telefones : Brasília: (61) 4063-7484 / São Paulo: (11) 4063-4658 / Vitória: (27) 3026-6304

Rio de Janeiro: (21) 4063-5311 / Belo Horizonte: (31) 4063-8475 / Recife: (81) 4062-9103

Salvador: (71) 4062-9234 / Porto Alegre: (51) 4063-8129 / Florianópolis (48) 4062-1699

RSS   Twitter   Facebook   Linkedin   Youtube

FATTO Consultoria e Sistemas - Estimativas, Medição e Requisitos de Software.