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;
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ê.
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.
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.