Diferentes visões dos dados, diferentes medições: Quando um AIE não precisa ser um (e somente um) ALI

No final de 2014, colaborei na elaboração do Guia de Contagem de Pontos de Função do Ministério do Planejamento, Orçamento e Gestão. Um dos tópicos discutidos, foi a integração entre aplicações por meio de Web Services. Dessa colaboração, percebi a oportunidade de esclarecer o tema para um público mais amplo e redigi uma instrução técnica, que publiquei no grupo mantido pelo IFPUG no LinkedIn. Ela descreve o cenário onde duas aplicações interagem. A aplicação destino obtém um único grupo lógico de dados em um passo intermediário em direção ao objetivo do usuário. A aplicação origem: Aceita a solicitação com os … Continue reading

Consultas Flexíveis; Relatórios Dinâmicos

Aside

.

.

Existe uma tela para emissão de um relatório com vários parâmetros para seleção. A geração do relatório será dinâmica, ou seja, os campos exibidos no relatório serão de acordo com os parâmetros informados na tela, por exemplo, para cada combinação de parâmetros podemos ter um relatório diferente; mas ainda assim, apenas uma função será identificada.

 

Vejo um problema sério de nomenclatura do título desta matéria. Ainda assim, ele é pertinente porque “Relatório Dinâmico” é um termo bastante usado; porém, usado com significados diferentes por diferentes pessoas: Não há um padrão universal para o que isso queira dizer.

Esta análise refere-se não ao relatório dinâmico (seja lá o que for isso), mas ao cenário descrito na abertura desta matéria. Por exemplo, soluções de BI apresentam uma conjunto de dados que podem ser manipulados pelo próprio usuário, um caso como esse implica na contagem de uma única função. Mas esse não é o caso aqui.

O critério para identificar diferentes funções em qualquer método de medição do tamanho funcional é haver diferentes requisitos funcionais. A unidade de um requisito funcional para esse propósito é definida em termos de sua abrangência. Apenas um nível de abrangência pode ser padronizado. Esse nível reflete o escopo cujo início é quando o usuário está com todas as condições para começar a tarefa e cujo término é:

  • O limite de sua responsabilidade nos fluxos operacionais em que se insere ou;
  • A dependência por algum evento externo para que possa haver continuidade no fluxo operacional.

É o nível de uma tarefa ou serviço. É impossível padronizar outros níveis mais abrangentes, que agregam várias tarefas ou serviços, ou menos abrangentes, fragmentos que não descrevam por completo todos os passos e regras associados a uma tarefa ou serviço.

.

.

Se considerarmos sempre uma única função em casos como o descrito na abertura deste artigo, então haveria um cenário possível no qual TODOS os relatórios de um sistema são consolidados em uma única função.

 

Entendo que o assunto tratado aqui seja como diretriz de mapear um artefato da implementação ou projeto - a tela com a interface com o usuário ou o(s) programa(s) que a implementam – para o plano dos requisitos funcionais do usuário. Usar a lógica citada para identificar uma função única diverge do princípio de identificar uma função a partir  da perspectiva de uma tarefa ou serviço do usuário e aproxima-se de identificar uma função a um agregado de diferentes tarefas e serviços do usuário; coisa impossível de padronizar e por isso não pode ser utilizado como um componente funcional básico.

O cenário que vejo convergir para a conclusão de contar uma única função seria:

.

.

A partir de um conjunto de critérios de seleção informados pelo usuário, o sistema apresenta o resultado com um conjunto único de dados. É possível ao usuário configurar qual subconjunto desses campos ele deseja apresentar (um requisito não funcional que não afeta a identificação de uma única função).

 

Agora sobre o cenário originalmente descrito, eu avalio que (genericamente como não pode ser diferente nessas circunstâncias):

  1. Há necessidade de várias entrevistas (disciplina de requisitos), não por incompetência, mas porque aquele conjunto de dados está associado a uma tarefa do usuário em específico e deve-se revelar as diferentes necessidades de informação referentes a cada conjunto de dados. Como estão associados a tarefas diferentes, possivelmente há inclusive diferentes usuários associados a cada diferente conjunto de dados.
  2. A descrição dos passos e regras de negócio que se aplicam, desde a informação dos parâmetros desejados até a apresentação daquele conjunto de dados único, é parte da elaboração de uma especificação de requisitos (disciplina de requisitos) que é discutida e validada com o usuário independentemente de outras saídas com outros conjuntos de dados.
  3. A validação dos requisitos (disciplina de requisitos) de cada conjunto único de informações quanto à sua inserção no processo de negócio mais amplo é realizada em separado dos demais.
  4. O plano de iteração na gerência de requisitos (disciplina de requisitos) pode prever que um relatório – mais crítico – esteja disponível em uma primeira iteração enquanto outro – menos crítico – esteja disponível em uma segunda.

A partir de vários conjuntos de requisitos já identificados, elaborados, validados e priorizados, um arquiteto decide agregar vários desses requisitos em um único componente – uma decisão de projeto (design).

Qual o referencial da Análise de Pontos de Função? São as tarefas e serviços do usuário. O correto é investigar se aquele resultado descrito na abertura desse texto corresponde ao cenário que descrevi (itens de 1 a 4) em que cada diferente saída corresponde a um diferente requisito funcional do usuário; como exemplificado no CPM no item Processos Elementares Similares.

Qualquer discussão além disso é usar a APF com o intuito de medir em uma visão do design, porque foi o design que levou a criar uma única unidade agregando diferentes requisitos funcionais do usuário.

Vejo fenômenos similares no próprio trabalho de requisitos no qual diferentes tarefas são “empacotadas” em um único caso de uso ou especificação. Com isso perde-se os benefícios citados nos itens 2 a 4 acima.

Já um cenário como o descrito a seguir:

.

.

Trata-se de consultas com diferentes critérios de filtro, mas uma única saída idêntica em termos de campos. Por exemplo, numa tela de consulta podem existir opções de filtros como pesquisa de empregados por lotação, data de admissão, data de nascimento, dentre outros, em que, quando não for especificado nenhum filtro, serão retornados todos os empregados de uma empresa, ou seja, a seleção dos filtros é opcional. Mas, caso seja selecionado alguns filtros, poderá ser retornado nenhum ou vários empregados.

 

Para esse cenário, entende-se que os itens de dados e arquivos referenciados são os mesmos e o que difere são apenas os registros retornados em função dos parâmetros do filtro.

Nesse caso, considera-se que existe apenas um processo elementar de consulta, que pode ser classificado como CE ou SE.

Estou plenamente de acordo com a análise para esse item. Interpretações diferentes dessas refletem o equivoco do IFPUG na definição da regra de unicidade corrigido a partir da versão 4.3.

A única exceção é se houver especificamente naquela tela diferentes direitos de acesso conforme os critérios de filtro; o que serviria para evidenciar que tratam-se de aplicações em diferentes tarefas do usuário. Coisa muito pouco comum, devo ressaltar.

Integridade Referêncial e Requisitos Funcionais do Usuário

Integridade Referencial Ainda que seja um conceito bastante conhecido, o profissional responsável pela medição do tamanho funcional (Análise de Pontos de Função do IFPUG ou do COSMIC, por exemplo) não necessariamente precisa conhecê-lo. Contudo, muitas vezes esse profissional cujo foco são os Requisitos Funcionais do Usuário (RFU) se vê em situações que precisa interagir com um desenvolvedor e o conhecimento básico sobre o assunto facilita, em muito, a comunicação. Então, vamos buscar algumas referências para integridade referencial. Num banco de dados relacional, quando um registro aponta para o outro, dependente deste, há de se fazer regras para que o registro … Continue reading

Como os Requisitos Afetam a APF: Um estudo de casos – consultas em um calendário

Semana passada, estive envolvido em um diagnóstico na função de desenvolvimento e manutenção de software enquanto estive em São Paulo. Um dos achados nesse trabalho é a visão que muitas pessoas ainda têm (sua cultura) de que as métricas de software em geral (e a Análise de Pontos de Função – APF – em particular) sejam métricas elásticas conforme a conveniência daquele responsável pelo desenvolvimento e manutenção de sistemas. Esse pode ser o caso para aqueles que tenham um conhecimento superficial do método e cujo conhecimento foi aplicado quando o principal uso do método era estimar e não medir como … Continue reading

Como contar grids?

Esses dias no fórum de leitores do livro de APF, percebo uma discussão que serve perfeitamente de exemplo para o que vou discutir neste post: os insumos para a medição usando o método da APF como definido pelo IFPUG ou qualquer outro método de medição funcional. Quando alguém me pergunta, por exemplo, como contar um quadro (implementado por meio de um grid) usando a análise de pontos de função, a resposta mais justa é: Sei lá! Antes de qualquer coisa, temos que ter definidos os objetivos do usuário (não os objetivos do negócio, apesar de por muito tempo eu ter … Continue reading

Feedback do Evento no IIBA SP em 14/09

Pessoal, foi muito positivo o evento do IIBA nesse último 14/09. A sala estava cheia e o debate foi rico. Quem tiver interesse em ver o material de apoio utilizado, ele está disponível em Apresentações. Mas como citei, trata-se de um material de apoio… Das discussões e assuntos que surgiram lá, surgiu muito tema, muito assunto que pretendo inicialmente explorar neste Blog. Você compartilhou: APF in a Nutshell (IIBA)