O primeiro projeto de emissão de boletos resultou em uma ferramenta de emissão de boletos de liquidação e renegociação de dívidas comerciais para cliente pessoa física e na cria- ção de uma ontologia de domínio específica para o assunto.
O sucesso do primeiro projeto motivou a matriz do banco a solicitar e patrocinar um novo projeto de emissão de boletos. As agências bancárias e as filiais agora tinham uma ferra- menta que ampliou sua capacidade de negociação, fazendo com que esse processo deixasse de ser um gargalo no relacionamento com os clientes inadimplentes.
O foco do novo projeto eram as empresas de cobrança terceirizadas contratadas pelo banco para cobrar os clientes inadimplentes, chamadas Agências de Cobrança Externas (ACE). O banco não possuía nenhuma ferramenta que permitisse a essas empresas fechar negociações com os clientes, o que fazia com que elas apenas direcionassem o cliente para a agência, o que tornava o processo redundante e burocrático.
Diante deste cenário, foi solicitado um projeto para criação de uma ferramenta de bole- tos nos moldes da que já havia sido desenvolvida, porém para ser utilizada pelas empresas ter- ceirizadas, fora do ambiente organizacional.
A unidade da matriz GESTO foi novamente designada para atuar na gestão do projeto. As filiais formaram novamente a equipe de negócio, devido ao seu papel no negócio e ao co- nhecimento adquirido no primeiro projeto.
Dois funcionários da GESTO foram designados para compor a equipe de TI por possu- írem conhecimentos nas tecnologias que precisariam ser utilizadas para criar um software na Extranet da organização. Nenhum destes empregados havia trabalhado antes com ferramentas de emissão de boletos.
Os usuários finais deste projeto eram as empresas terceirizadas, que utilizam o sistema na Extranet da organização.
A elicitação de requisitos utilizou, durante esse projeto, as seguintes técnicas: entrevista, análise de documentos e reuniões. As entrevistas e reuniões foram feitas pessoalmente quando envolviam pessoas da cidade de Brasília, ou por áudio conferência quando envolviam pessoas de outras cidades. A análise de documentos foi feita a partir das normas para troca de informa- ções entre a Intranet e a Extranet da organização.
Na Figura 28 são mostrados os requisitos coletados na fase de solicitação do projeto.
Figura 28: Segundo cenário – triplas dos requisitos na fase de solicitação do projeto
Fonte: o Autor
A solicitação do projeto é composta apenas pelos requisitos mostrados na Figura 27, porém, graças à ontologia de domínio criada anteriormente, todos os conceitos envolvidos na emissão e tratamento de boletos de liquidação e renegociação de dívidas comerciais para clien- tes do tipo pessoa física puderam ser imediatamente incorporados ao novo projeto. Este fato permitiu que o projeto fosse iniciado quase completo, reduzindo drasticamente o tempo neces- sário para a especificação da nova ferramenta.
A Figura 29 representa a incorporação de conceitos da ontologia de domínio ao novo projeto, após a inclusão das definições dos produtos de software envolvidos no projeto.
Figura 29: Segundo cenário – reutilização de conceitos
Fonte: o Autor
Pode-se notar que foi adicionado ao projeto, no papel de usuário, o stakeholder “Cliente do Banco”. Este pode ser um detalhe pequeno, porém representa um ator fundamental: o usuário final do serviço fornecido através da ferramenta a ser desenvolvida.
O maior esforço necessário neste projeto foi em relação ao uso e comportamento dos produtos fora do ambiente da Intranet, que pode ser totalmente controlado pela organização. Para o restante da especificação, foram feitas apenas pequenas inclusões e alterações nos con- ceitos já presentes na ontologia. A esses conceitos foram adicionadas informações relativas às empresas terceirizadas, como o papel de usuário, e os objetos e atributos necessários para guar- dar seus dados.
Para descrever a utilização da ferramenta pelas empresas terceirizadas, foi necessário apenas criar casos de uso específicos para a emissão de boletos por este tipo de usuário, uma vez que o tratamento que o sistema realiza para estes boletos é o mesmo dos boletos emitidos pela ferramenta já criada no primeiro projeto.
Quadro 6: Avaliação do segundo cenário.
Aspecto Critério Avaliação
Reusabilidade Reutilizou conceitos da ontologia? sim
Propôs automaticamente requisitos a partir da ontologia? sim
Explora as relações e axiomas da ontologia? sim
Rastreabilidade Há ligações explícitas entre requisitos e outros elementos? sim
Há categorização dos requisitos? sim
Um objeto complexo pode ser decomposto em componentes básicos? sim Consistência Há organização hierárquica dos requisitos? sim Permite análise de pares de conceitos entre os diferentes níveis? sim Completude Permite análise de nós sem correspondência? sim Fonte: O Autor
Ao longo do desenvolvimento do projeto, foi possível reaproveitar quase totalmente os conceitos da ontologia de domínio específica criada no primeiro projeto. Assim, a documenta- ção das especificações do sistema foi feita em um tempo bastante reduzido e com a garantida de qualidade do produto, pois os mesmos já foram testados na implementação anterior.
Mesmo tratando-se de sistemas diferentes, um executado na Intranet e outro na Internet, com linguagens e SGBDs diferentes, os artefatos utilizados para ambos os projetos eram prati- camente os mesmos. A utilização da ontologia de domínio para auxiliar a especificação permi- tiu obter a maior parte dos requisitos do projeto de forma automática, faltando apenas completar a documentação com os novos requisitos que abordavam a utilização da ferramenta por parte das empresas terceirizadas.
Neste projeto notou-se que o reaproveitamento dos requisitos por meio da ontologia de domínio diminuiu os impactos da comunicação entre as equipes na qualidade dos requisitos, pois a maioria da especificação já havia sido criada e testada anteriormente. Desta forma pre- veniu-se que conceitos já documentados anteriormente sejam recriados, pois estes teriam que ser novamente testados e poderiam resultar em requisitos incompletos ou conflitantes com ou- tros projetos.
Ao final deste projeto a ontologia de boletos de cobrança estava revisada e ampliada, e passou a unir as especificações de dois sistemas diferentes dentro da ontologia de domínio da organização.
Ajudada pelo fato de estar parcialmente validada, a ferramenta de boletos para as em- presas terceirizadas também foi implantada com sucesso, sendo rapidamente adotada nas roti- nas de cobrança das empresas terceirizadas. As empresas terceirizadas passaram então a ter a possibilidade de fechar uma negociação diretamente com o cliente do banco, ao invés de dire- cioná-lo para uma agência, o que reduziu o fluxo de clientes nas agências e tornou mais fácil e prático o atendimento dos mesmos pelas empresas terceirizadas.