Semana pas­sada, estive envol­vido em um diag­nós­tico na fun­ção de desen­vol­vi­mento e manu­ten­ção de soft­ware enquanto estive em São Paulo. Um dos acha­dos nesse tra­ba­lho é a visão que mui­tas pes­soas ainda têm (sua cul­tura) de que as métri­cas de soft­ware em geral (e a Aná­lise de Pon­tos de Fun­ção — APF — em par­ti­cu­lar) sejam métri­cas elás­ti­cas con­forme a con­ve­ni­ên­cia daquele res­pon­sá­vel pelo desen­vol­vi­mento e manu­ten­ção de sistemas.

Esse pode ser o caso para aque­les que tenham um conhe­ci­mento super­fi­cial do método e cujo conhe­ci­mento foi apli­cado quando o prin­ci­pal uso do método era esti­mar e não medir como é o caso em nossa atualidade.

O que é elás­tico são os requi­si­tos do usuá­rio!  Neste texto vou explo­rar o assunto com um caso hipo­té­tico de um tipo de sis­tema que tem sido bas­tante uti­li­zado — Calen­dá­rio — por isso, requer menos exer­cí­cio de abs­tra­ção para depre­en­der os requi­si­tos do usuá­rio.  Apro­veito tam­bém para abor­dar um dos pon­tos mais crí­ti­cos na APF que é a deter­mi­na­ção se um cená­rio cons­ti­tui ape­nas uma fun­ção ou várias. Faço isso usando dois cená­rios dife­ren­tes que tem a mesma raiz no domí­nio do problema.

O domí­nio do problema

A demanda que pro­vo­cou o tra­ba­lho de desen­vol­vi­mento do calen­dá­rio esta­be­lece que:

1. O usuá­rio atua em gru­pos de tra­ba­lho e algu­mas de suas agen­das são com­par­ti­lha­das com outras pes­soas nes­ses gru­pos de forma que seus com­pro­mis­sos este­jam dis­po­ní­veis para con­sulta quando da pro­gra­ma­ção de algu­mas des­sas pessoas;
2. O usuá­rio tem subor­di­na­dos que secre­ta­riam suas ati­vi­da­des e para os quais deseja dele­gar o poder de com­par­ti­lhar algu­mas de suas agen­das com outras par­tes. Con­tudo; nem todo subor­di­nado tem essa função;
3. Em deter­mi­na­dos gru­pos de tra­ba­lho, o usuá­rio é subor­di­nado a uma auto­ri­dade com com­pe­tên­cia para (ela) criar com­pro­mis­sos em sua agenda; não em todas as suas agen­das, mas ape­nas naque­las rela­ti­vas aos gru­pos onde ela exerça essa autoridade.

Os requi­si­tos fun­ci­o­nais e das par­tes interessadas

Par­tindo das neces­si­da­des de negó­cio esta­be­le­ci­das no domí­nio do pro­blema, o ana­lista de requi­si­tos rea­liza uma série de ati­vi­da­des de levan­ta­mento junto às par­tes inte­res­sa­das e como resul­tado de sua aná­lise iden­ti­fica (den­tre outros) três requi­si­tos funcionais:

1. Lis­tar agen­das do usuário;
2. Lis­tar agen­das onde o usuá­rio as possa com­par­ti­lhar com outros usuários;
3. Lis­tar agen­das onde o usuá­rio possa criar compromissos.

A par­tir desse ponto vou apre­sen­tar dois cená­rios dife­ren­tes ainda no plano da enge­nha­ria de requi­si­tos e que como con­sequên­cia pro­du­zem con­ta­gem dife­ren­tes… não por­que a métrica seja elás­tica mas por­que o uni­verso de solu­ções para um mesmo pro­blema é.

Cená­rio 01:

Ao apre­sen­tar o resul­tado para as par­tes inte­res­sa­das, o ana­lista pro­põe a con­so­li­da­ção des­ses dife­ren­tes requi­si­tos fun­ci­o­nais pre­li­mi­na­res em um único requi­sito fun­ci­o­nal no qual o usuá­rio esco­lhe­ria um cri­té­rio de sele­ção e, a par­tir desse cri­té­rio, seria apre­sen­tado uma saída única com as dife­ren­tes agen­das. O esboço a seguir ilus­tra as neces­si­da­des de infor­ma­ção discutidas:

Cri­té­rio de Seleção

A par­tir desse esboço se esta­be­le­ceu ape­nas um requi­sito fun­ci­o­nal do usuá­rio (RFU) e foi ela­bo­rada a seguinte especificação:

RFU01 Lis­tar Agendas

Dici­o­ná­rio de Dados (D01)

Fluxo Prin­ci­pal

1. O sis­tema apre­senta o nome do usuá­rio e apre­senta as opções de con­sulta dis­po­ní­veis para cri­té­rios de sele­ção na apre­sen­ta­ção das agendas;
2. O usuá­rio informa os parâ­me­tros para a sele­ção das agen­das a serem apresentadas;
3. O sis­tema obtém as suas agen­das usando a RN01:
4. Sis­tema apre­senta a rela­ção das agen­das obtidas.

Regras de Negócio

RN01– Obter agen­das do usuário

1. Obter as agen­das do usuário;
2. Obter as agen­das com­par­ti­lha­das com o usuá­rio e os res­pec­ti­vos direitos;
3. Con­so­li­dar os dois con­jun­tos de agen­das obti­das nos pas­sos ante­ri­o­res, con­si­de­rando que em suas agen­das o usuá­rio tem ple­nos pode­res; para cada agenda nesse novo con­junto rea­li­zar os pas­sos a seguir:
1. Ava­liar se o usuá­rio deseja ape­nas lis­tar aque­las agen­das em que possa criar even­tos e se esse for o caso, incluir a agenda na lista a ser apresentada;
2. Ava­liar se o usuá­rio deseja ape­nas lis­tar aque­las agen­das que pos­sam ser com­par­ti­lha­das e se esse for o caso, incluir a agenda na lista a ser apre­sen­tada quando a agenda ainda não esti­ver nela presente;
3. Ava­liar se o usuá­rio deseja lis­tar qual­quer agenda e se esse for o caso, incluir a agenda na lista a ser apre­sen­tada quando a agenda ainda não esti­ver nela presente;

Quan­tas fun­ções contar?

Observe que quem quer que use a con­sulta para lis­tar ape­nas as agen­das em que se pode criar even­tos pode tam­bém usar a mesma con­sulta para lis­tar ape­nas as agen­das que pode com­par­ti­lhar ou mesmo para lis­tar todas as agen­das. Isso inde­pen­den­te­mente da tarefa que esteja exe­cu­tando: seja na cri­a­ção de um evento, seja em com­par­ti­lhar uma agenda com outrem.

Ape­nas uma fun­ção será con­ta­bi­li­zada onde, em dife­ren­tes casos de exe­cu­ção é pos­sí­vel haver peque­nas dife­ren­ças em fun­ção de lógi­cas de pro­ces­sa­mento em que:

04. Dados são fil­tra­dos e sele­ci­o­na­dos uti­li­zando deter­mi­na­dos cri­té­rios para com­pa­rar múl­ti­plos con­junto de dados; ou

05. Con­di­ções são ana­li­sa­das para deter­mi­na­ção de qual se aplica.

Cená­rio 02:

Ao apre­sen­tar o resul­tado para as par­tes inte­res­sa­das, o ana­lista de requi­si­tos pro­põe a con­so­li­da­ção des­ses dife­ren­tes requi­si­tos fun­ci­o­nais pre­li­mi­na­res em um único requi­sito fun­ci­o­nal como des­crito no cená­rio ante­rior.  Ao con­trá­rio daquele cená­rio, esse não é o inte­resse dos usuá­rios. Seu inte­resse é que haja uma con­sulta con­forme as dife­ren­tes tare­fas que ele exe­cuta. Por exem­plo, se ele está no âmbito da cri­a­ção de um evento, deseja uma con­sulta ali­nhada a essa tarefa em par­ti­cu­lar; se ele está no âmbito do com­par­ti­lha­mento de uma agenda, deseja uma con­sulta nos mes­mos mol­des; e se está sim­ples­mente sele­ci­o­nando quais agen­das deseja visu­a­li­zar no calen­dá­rio, deseja ver todas as suas agen­das inde­pen­den­te­mente de qual­quer coisa.

Por quê? Por­que é assim que ele tra­ba­lha, é assim que ele orga­niza as tare­fas em dife­ren­tes fun­ções. Ou seja, trata-se de uma con­si­de­ra­ção que está no plano das tare­fas e ser­vi­ços do usuá­rio e não no plano de atri­bu­tos na dimen­são da faci­li­dade de uso.

Como con­sequên­cia daquela aná­lise se pro­duz três dife­ren­tes e inde­pen­den­tes RFUs:

RFU02 Lis­tar Agendas

Esboço RF02

Dici­o­ná­rio de Dados (D02)

Fluxo Prin­ci­pal

1. O sis­tema apre­senta o nome do usuá­rio atu­al­mente usando o sis­tema; obtém as suas agen­das usando a RN02: e apre­senta a rela­ção das agen­das obtidas.

Regras de Negócio

RN02– Obter agen­das do usuário

1. Obter as agen­das do usuário;
2. Obter as agen­das com­par­ti­lha­das com o usuário;
3. Con­so­li­dar os dois con­jun­tos de agen­das obti­das nos pas­sos anteriores;
4. Para cada agenda nesse novo con­junto, incluir a agenda na lista a ser apresentada.;

RFU03 Lis­tar Agen­das para Criar Evento

Esboço RF03

Dici­o­ná­rio de Dados (D02)

Fluxo Prin­ci­pal

1. O sis­tema apre­senta o nome do usuá­rio atu­al­mente usando o sis­tema; obtém as suas agen­das usando a RN03: e apre­senta a rela­ção das agen­das obtidas.

Regras de Negócio

RN03– Obter agen­das do usuá­rio para criar evento

1. Obter as agen­das do usuário;
2. Obter as agen­das com­par­ti­lha­das com o usuá­rio e os res­pec­ti­vos direito;
3. Con­so­li­dar os dois con­jun­tos de agen­das obti­das nos pas­sos ante­ri­o­res, con­si­de­rando que em suas agen­das o usuá­rio tem ple­nos pode­res; para cada agenda nesse novo con­junto rea­li­zar os pas­sos a seguir:
1. Ava­liar se o usuá­rio pode criar even­tos e se esse for o caso, incluir a agenda na lista a ser apresentada;

RFU04 Lis­tar Agen­das para Compartilhar

Esboço RF04

Dici­o­ná­rio de Dados (D02)

Fluxo Prin­ci­pal

1. O sis­tema apre­senta o nome do usuá­rio atu­al­mente usando o sis­tema; obtém as suas agen­das usando a RN04: e apre­senta a rela­ção das agen­das obtidas.

Regras de Negócio

RN04– Obter agen­das do usuá­rio para com­par­ti­lhar evento

1. Obter as agen­das do usuário;
2. Obter as agen­das com­par­ti­lha­das com o usuá­rio e os res­pec­ti­vos direito;
3. Con­so­li­dar os dois con­jun­tos de agen­das obti­das nos pas­sos ante­ri­o­res, con­si­de­rando que em suas agen­das o usuá­rio tem ple­nos pode­res; para cada agenda nesse novo con­junto rea­li­zar os pas­sos a seguir:
1. Ava­liar se o usuá­rio pode com­par­ti­lhar a agenda e se esse for o caso, incluir essa agenda na lista a ser apresentada;

Já parou para se per­gun­tar por­que Con­sulta “Externa”?

Se for­mos com­pa­rar gra­fi­ca­mente esses dois cená­rios pode­ría­mos ter a seguinte repre­sen­ta­ção des­ta­cando que no pri­meiro cená­rio as deci­sões acon­te­cem inter­na­mente à apli­ca­ção em ana­lise; enquanto no segundo cená­rio há dife­ren­tes con­sul­tas exter­nas, cada uma com uma par­ti­cu­la­ri­dade em sua lógica de pro­ces­sa­mento con­forme a tarefa em que se aplica em particular:

CUIDADO!

Chamo a aten­ção que o fun­da­mento para con­tar os três RFUs acima (RFU02, RFU03 e RFU04) é haver dife­ren­tes tare­fas no plano da divi­são do tra­ba­lho pelo usuá­rio. Se em ter­mos de requi­si­tos con­fir­ma­mos o cená­rio 01 (onde há ape­nas um RFU01) e em tempo de aná­lise e pro­jeto (outra dis­ci­plina da Enge­nha­ria de Soft­ware) se esta­be­le­cem três telas dife­ren­tes, ainda assim ape­nas uma fun­ção deve ser contabilizada!