2. RESULTADO DO SORTEIO DO LIVRO ANÁLISE DE PONTOS DE FUNÇÃO
O sorteado desta vez foi Roberto Carlos da Silva de São Lourenço-MG. O próximo sorteio será no
dia 10 de abril. Para quem ainda não se cadastrou e deseja concorrer, acesse
http://www.fattocs.com.br/sorteio.asp.
P.: Quais atividades são compreendidas na estimativa de esforço (usando pontos de
função) de um projeto de software?
R.: Basicamente todas as atividades que possuem relação direta com a construção e
entrega dos requisitos funcionais: levantamento e especificação
de requisitos, análise, projeto, modelagem, gerência do projeto, codificação,
testes, apoio à homologação do usuário, implantação e transferência de conhecimento
do serviço executado. Sendo que vários artefatos podem ser produzidos nestas
atividades, como: código fonte, diagramas, modelos, casos de uso, manuais,
planos, atas, etc.
Por complemento ao parágrafo anterior, quaisquer atividades não diretamente relacionadas aos
requisitos funcionais do projeto de desenvolvimento/manutenção do software não estão no escopo da estimativa por PF.
Exemplos: treinamento de usuários, acompanhamento do sistema em produção, administração do
banco de dados, atendimento de dúvidas ou reclamações de usuários, atividades de suporte a infra-estrutura tecnológica, etc.
É possível também realizar a estimativa para apenas algumas atividades
específicas do projeto. Para isto é necessário conhecer a distribuição (%) de
esforço que cada fase costuma consumir do projeto todo. Conhecendo esta relação,
estima-se o esforço total do projeto e aplica-se o percentual de cada fase
desejada para se saber o esforço estimado para aquelas atividades.
PRÁTICAS DE CONTAGEM - CONVERSÃO DE DADOS
Conceito
========
São funções construídas e entregues pelo projeto (de desenvolvimento ou melhoria) para serem usadas no momento da instalação do projeto para converter dados ou fornecer outros requisitos de conversão especificados pelo usuário, como relatórios de verificação da conversão. A característica destas funções é que elas são descartadas após o seu uso, não fazendo parte das funções da aplicação após sua instalação. Quando o sistema entra em operação, essas funções não são mais necessárias.
Esta é uma situação muito comum na implantação de sistemas novos que substituirão sistemas legados. Ou na implantação de uma nova versão do sistema que necessitará converter dados da versão anterior. É importante não confundir este termo “conversão de dados” usado pelo IFPUG com conversões (ou importações) de dados rotineiras (diárias, semanais, etc). Neste caso essas funções fazem parte da própria aplicação e devem ser contadas normalmente.
Abordagem
=========
A finalidade do IFPUG ao destacar estas funções de “conversão de dados” é para reforçar de que estas devem fazer parte do escopo da contagem do projeto como quaisquer outras funções. A exceção é quando a conversão de dados é efetuada manualmente pelo desenvolvedor. Neste caso não há funcionalidade sendo entregue pelo projeto, então nada deve ser medido.
Porém, para evitar que surjam funções de conversão de dados de maneira artificial no projeto, cabe ao Cliente avaliar se deseja que estas funções sejam entregues pelo projeto com o mesmo nível de qualidade das outras funções do projeto. Ou seja, se é interessante que estas funções sejam documentadas, especificadas e testadas com o mesmo rigor das demais. Se for o caso, elas farão parte do escopo do projeto e também da contagem de PF.
Em geral as funções de conversão de dados são entradas externas; pois a principal intenção destes processos é receber dados de fora da fronteira da aplicação e atualizar dados (arquivos lógicos internos). Pode haver outras transações de conversão de dados, como consultas e relatórios, que também serão usados somente no momento da instalação. A complexidade dessas entradas externas é dada pelo número de campos recebidos e pela quantidade de arquivos lógicos acessados/gravados. Cuidado para não se contar uma única entrada externa como representante de todos os requisitos de conversão de dados. Grupos de dados distintos podem ter requisitos distintos para a conversão. Por exemplo, para converter dados de Pedido algumas regras de negócio deverão ser atendidas. Para converter dados de Cliente, outras regras de negócio estarão presentes. Esta consideração é válida mesmo que na implementação tudo seja feito por um único programa. O que prevalece é a visão lógica e não a de implementação.
Outra consideração importante é que os dados dos sistemas legados que serão convertidos para a nova aplicação não devem ser contados como ALI ou AIE pelo projeto, pois não representam requisitos de armazenamento da nova aplicação. São arquivos usados somente para atualização e depois descartados. Conseqüentemente também não serão considerados arquivos referenciados das transações de conversão.