Gestão de Regras de Negócios

Gestão de Regras de Negócios no Desenvolvimento de Software

Um desafio no desenvolvimento de software sempre foi atender às necessidades dos usuários finais, com maior precisão e rapidez em níveis operacionais e estratégicos da organização. Ainda, a complexidade tem crescido rapidamente em função das fortes demandas por sistemas que exigem integrações com outros sistemas.

Os fatores que exigem maior gerenciamento no desenvolvimento de software estão nas diversas plataformas tecnológicas, multidisciplinaridade demandadas no desenvolvimento de software e profissionais formados em diferentes universidades. Este artigo tem como finalidade a implantação de um modelo de gestão de regras de negócios paralelamente à gestão do desenvolvimento de software, ofertando uma visão transparente aos usuários finais quanto aos processos de seus negócios.

Através deste modelo de gestão de requisitos, é possível efetuar a gestão das regras de negócios com foco na garantia da qualidade e integralidade das implementações destas regras no software, alinhadas aos processos de negócios da organização.

A gestão da informação requer uma disciplina de execução dos procedimentos bem definidos. Existem várias fontes de informações e também inúmeras formas de expressar a mesma informação [1]. E por estes motivos é que softwares nem sempre possuem as funcionalidades de acordo com as regras de negócios da organização patrocinadora do projeto de desenvolvimento.

Através de um modelo de gestão das regras de negócios, desde sua formalização até a validação de aplicabilidade, a proposta está na melhoria da gestão do conhecimento. A partir de problemas evidenciados no processo de desenvolvimento de software e perda de informações, algumas análises estão sendo formalizadas, como base para demonstrar as melhorias que são possibilitadas com o uso deste modelo.

Num formato mais próximo da realidade do usuário e dos procedimentos da empresa na qual a regra é aplicada, esta definição reflete exatamente os passos a serem seguidos para alcançar os resultados esperados pela empresa.

A partir das regras de negócios consistentes às necessidades da empresa, inicia-se o processo de desenvolvimento do software, através das técnicas e metodologias escolhidas para o projeto.

A diferença fundamental em ter a gestão das regras de negócios segregadas da gestão de requisitos está na possibilidade da avaliação do próprio usuário, de que suas regras foram integralmente implementadas no software desenvolvido.

Neste artigo, o modelo da gestão das regras de negócios está complementado com os princípios da transdisciplinaridade entre a comunicação, a colaboração e a agilidade na gestão do conhecimento [2].

Tendo como foco a participação ativa dos envolvidos e responsáveis pela informação que deve estar atualizada; obtendo resultados muito maiores que uma simples somatória dos conhecimentos catalogados.

Metodologia seguida e outras abordagens

Nesta seção, com a finalidade de estruturar o artigo e fornecer os subsídios necessários para a sua construção, será apresentada a metodologia de pesquisa utilizada para seu desenvolvimento. Para finalizar, serão apresentados os estudos mais recentes relacionados ao gerenciamento de regras de negócio no processo de desenvolvimento de software.

Metodologia de Pesquisa

O desenvolvimento do modelo da gestão de regras de negócio foi aplicado com base na organização GAIA que tem como objetivo o desenvolvimento de software. Baseado na metodologia em uso para a avaliação de processos do desenvolvimento de software foi aplicado, neste trabalho, um modelo de avaliação genérico para o desenvolvimento de artigos. Foram seguidas atividades de acordo com as três etapas: Análise Teórica, Desenvolvimento e Avaliação.

Em princípio, os trabalhos pesquisados foram planejados por ano de publicação e assunto relacionados à gestão do conhecimento com foco nas regras de negócios. Especificamente limitados a três anos, a partir de 2010, para os periódicos e livros de autores com histórico em Engenharia de Software e Qualidade no Processo de Desenvolvimento de Software.

Dentre os assuntos relacionados à gestão do conhecimento, com foco no desenvolvimento de software, foram escolhidos a gestão de regra de negócio, gestão da regra de requisitos, avaliação de requisitos implementados e avaliação das regras de negócios atendidas por aplicativos de software. Para melhor compreensão, as atividades executadas foram ilustradas pela Figura 1.

Na primeira etapa, são executadas duas macro atividades, sendo a Fundamentação Teórica (1), relacionados à pesquisa em artigos publicados. Esta tem como origem a busca em base de dados para referências e estudos desenvolvidos no segmento de desenvolvimento de software e gestão de regras de negócios.

Em consequência da pesquisa, é elaborada a tabela comparativa dos principais artigos que trataram de forma explícita os assuntos.

A etapa intermediária, de Desenvolvimento (2), que também contempla a consolidação do modelo de gestão da regra de negócios, são cumpridas com quatro macro atividades: Elaboração do modelo de gestão da regra de negócio e Consolidação do modelo de Gestão da Regra de Negócio; sendo que as atividades Estabelece critério de avaliação e Aplicação do modelo são compartilhadas com a etapa de Avaliação.

Na elaboração do modelo, foram adequadas à abordagem proposta, as definições identificadas em trabalhos anteriores. Tendo como o principal diferencial, [3] a segregação das Regras de Negócios dos Requisitos de Software, para que tenha uma validação [4] de que o software estará contribuindo efetivamente aos negócios da organização.

Para obter uma validação completa e conclusiva, um dos métodos de elaboração do questionário inclui a colaboração dos membros da equipe que participaram neste estudo, de modo a exatidão das informações prestadas é associada ao comprometimento dos participantes.

Os critérios de avaliação e a aplicação do modelo contemplam concomitantemente nas etapas de Desenvolvimento e de Avaliação (3), mantendo a objetividade da execução e da avaliação.

Na etapa 3, a macro atividade Avaliação do Resultado teve como finalidade analisar cada resposta do questionário, através da tabulação com a indicação de uso satisfatório do modelo de gestão. As respostas são obtidas através da macro atividade de Aplicação do questionário de avaliação.

Trabalhos Relacionados

A linha mestre para elaborar o quadro comparativo foi transitar pelos diversos níveis da organização. Desde o nível estratégico, de responsabilidade da alta administração, até o de validação das regras no software desenvolvido. Obviamente, consultando as premissas da gestão do conhecimento, do processo de gestão das regras de negócios e do impacto no desenvolvimento de software.

O ponto inicial de qualquer atividade relacionada à gestão do conhecimento está na explicitação, padronização e gerenciamento do conhecimento, enfatizado por [4]. Complementado pelo armazenamento destes conhecimentos em separado quando se trata de regras de negócios e requisitos de sistemas.

Com o foco em sistemas de informações, é necessária a descrição das regras de negócios em modelos de testes. Este modelo tem grande influência na validação das regras implementadas nos softwares, aumentando a sua qualidade.

Complementando a mesma linha de validação [1] defende a melhoria da qualidade dos requisitos de usuários, tendo em vista que ele recomenda a separação dos requisitos de sistemas dos requisitos de usuários.

Um fator importante na gestão das regras de negócio está na dependência destas com o processo de negócios da organização. O relacionamento entre as regras e os processos de negócios proporciona mudanças rápidas das regras quando existir alterações da estratégia da organização.

A alta administração tem fundamental contribuição na gestão das regras de negócios, em função do comprometimento com as metas da organização. Através da incorporação com a política organizacional, as regras de negócios conduzem a alcançar as metas desejadas.

Na Tabela 1 é possível identificar a extensão em que a gestão das regras de negócios percorre para obter a eficiência e eficácia desta gestão nas organizações de desenvolvimento de software.

E também verifica-se que os itens pesquisados refletem a realidade de organizações que possuem o conhecimento como um de seus ativos organizacionais. Na qual, com a aplicação dessas propostas percebem o benefício da utilização da gestão das regras de negócios como fonte de qualidade em software e o domínio destas regras ao longo da vida da organização.

Tabela 1. Comparativo em publicações sobre a GRN.

Outros trabalhos

Agora, para poder validar o estudo realizado, foi construída uma revisão de literatura com as principais vertentes desse trabalho. Nesse processo de revisão, foram abordados os trabalhos mais recentes (últimos cinco anos), que foram publicados em bases de dados de alta qualidade e de alta confiabilidade, tais como, Scopus, ACM Library, IEEE Xplore, Science Direct, entre outras. Tendo como finalidade expressar o verdadeiro estado da arte das seguintes estruturas fundamentais para esse trabalho: Regra de Negócio, Levantamento de Requisitos e Gestão do Conhecimento.

Regra de Negócio

Uma definição clara de regra de negócio foi descrita por [2] cujo entendimento é ter a descrição atômica, na qual não poderá ser subdividida em partes; e deve afirmar, ou influenciar ou controlar o comportamento dos negócios de uma organização. Dentre inúmeras características da regra de negócio, o mesmo autor cita algumas fundamentais:

• Para tornar os processos de negócios com mais flexibilidade as regras devem ser armazenadas separadamente de fácil recuperação;
• Deve prever que as regras de negócio evoluem ou se modificam independente do modelo de processos de negócios;
• É comum que as regras de negócios se alteram com maior frequência do que os processos de negócios;
• Estando armazenado em separadas, num só repositório, as regras de negócio podem ser reutilizadas em vários processos de negócio;
• A descrição padronizada facilita o entendimento e reutilização da regra de negócio em outro contexto.

Em uma regra de negócio, a descrição deve ter clareza para que a implementação desta regra tenha sucesso nos resultados esperados pelo cliente [3], assegurando uma descrição e entendimento de cada regra.

Também deve existir uma sequência lógica de aplicação das mesmas. Através desta sequência é que o sistema poderá ser desenvolvido com garantia de sucesso na implementação.

Para cada conjunto de regras, exemplificado em um cenário de uma transportadora de mercadorias, conforme Tabela 2, existe uma sequência lógica e ao mesmo tempo cada regra representa a sua individualidade.

Tabela 2. Definição de regra de negócios (exemplos).

A linguagem descrita é estabelecida conforme entendimento dos profissionais da área operacional da organização que abrigam as regras de negócios.

A partir do momento em que as regras estão entendidas, é possível iniciar o design do software, de acordo com o cronograma previsto para sua execução.

Em muitas situações, estas regras podem ser reescritas de acordo com os procedimentos definidos na Gestão de Requisitos da organização. Sendo que os textos poderão ser alterados, porém o conteúdo do ponto de vista semântico jamais poderá ser alterado.

Inclusive, esse é um dos pontos críticos que podem levar ao fracasso no desenho e, consequentemente, o desenvolvimento e a entrega do software.

Levantamento de Requisitos

Antes de iniciar um estudo sobre o levantamento de requisitos, para um melhor entendimento, se faz necessário um processo de explicitação dos seus significados iniciando com a definição de um requisito, que pode ser compreendido como uma condição necessária para a obtenção de um determinado objetivo.

No entorno desse artigo, adotaremos a definição de um requisito no âmbito de um sistema de software, que pode ser compreendido como a descrição das funções e restrições que o produto a ser desenvolvido deve possuir.

Com esses termos bem definidos, o próximo passo é explorar os conceitos referentes ao levantamento de requisitos. Que de acordo com [5] é a fase primordial no processo de desenvolvimento de software em que ocorre uma pesquisa de mercado (junto ao cliente) para de forma simples e completa, encontrar, organizar e rastrear as diversas funcionalidades que o sistema deve obter.

Continuando com [5] e acrescentando ideias de [6] o levantamento de requisitos pode ser definido como um conjunto de métodos e técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto para sistemas de informática. Esse processo é longo, moroso e com intensa captura, combinação e disseminação do conhecimento.

É nesse processo que todos os envolvidos no projeto, devem trocar informações sobre o contexto e as atividades que serão executadas pelo software durante o seu desenvolvimento. Durante, a sua descrição, essa atividade parece um tanto quanto simplória, no entanto, realizar um bom levantamento de requisitos é um grande desafio.

Durante a sua elaboração, diferentes pontos de vistas e expectativas divergentes entre, desenvolvedores, usuários e clientes, tornam essa tarefa difícil e conflituosa. Fato este que já se inicia com o cliente, tendo em vista, que em inúmeros casos, o cliente não está completamente certo das suas reais necessidades.

Portanto, tudo isso fez e faz da fase de especificação de requisitos uma atividade complexa e de alto risco para empresa, influenciando diretamente no sucesso do projeto.

A maioria dos problemas encontrados nessa fase representam cerca de 55% dos empecilhos em sistemas computacionais. 82% do esforço dedicado à correção de erros está relacionada a essa fase.

Com tais dados em evidência, pode-se novamente reafirmar que os requisitos são a base de todo projeto, caracterizando de forma real o que os clientes necessitam para usar ou modificar um sistema, e como este deve funcionar.

Interessante abordar também que esta constatação não se torna verídica apenas no desenvolvimento de software, não obstante também para qualquer processo que envolva a confecção de novos artefatos. Tudo isso demonstra que para chegar a requisitos que realmente contemplem o sistema pretendido, é necessário que esses sejam devidamente explicitados.

Dentre as atividades que fazem parte desse contexto, pode-se citar o domínio da regra de negócio, captura e classificação de requisitos, estabelecimento de prioridades, resolução de conflitos, verificação de inconsistências e ambiguidade, e finalmente, a negociação dos requisitos do sistema.

Para auxiliar na execução dessas atividades, alguns métodos podem ser utilizados.

Um dos métodos mais conhecidos e utilizados para especificação de sistemas é o JAD (Joint Application Development). A principal funcionalidade do JAD é a descrição de uma variedade de métodos para conduzir workshops entre clientes e desenvolvedores, fazendo com que esses trabalhem juntos nas fases de desenvolvimento, principalmente durante a especificação dos requisitos.

Um segundo método bastante utilizado são os pontos de vistas orientados à técnica. Um exemplo bastante clássico desse método é o VORD (Viewpoint Oriented Requirements Definition), em que são definidos e estruturados diferentes pontos de vista ficando a cargo do analista a integração dos requisitos. Por fim, todos esses métodos, técnicas e definições demonstram que o levantamento de requisitos é uma parte essencial e funcional durante o processo de desenvolvimento de software.

Gestão do Conhecimento

Continuando na mesma linha de investigação e arguição dos termos cruciais para a execução desse projeto, o próximo passo é definir e esmiuçar ao máximo o significado da gestão do conhecimento, principalmente referente ao contexto da regra de negócio.

Vale definir, inicialmente, o que seria a gestão, que pode ser entendida como um processo de coordenar tarefas, atividades e projetos de maneira que sejam desempenhados de forma eficaz e eficiente, sempre tendo em vista o objetivo de gerenciar o conhecimento.

O conhecimento, dentro desse contexto, assume duas formas principais, o Tácito e o Explícito. O primeiro refere-se ao conhecimento que está armazenado na cabeça das pessoas, sendo pertencente somente ao indivíduo que o detém. E o segundo, explícito, refere-se ao conhecimento estruturado, inerente ao indivíduo, sendo pertence a sua organização mantedora.

A principal funcionalidade da gestão do conhecimento se refere a realizar a transformação do conhecimento tácito para explícito. Processo esse, em que, o conhecimento deixa de ser um bem apenas pertencente ao indivíduo, e se torna, de forma estrutura, um ativo a todos os métodos que desejarem utiliza-lo.

Alguns autores colocam algumas definições interessantes sobre gestão do conhecimento, que é uma abordagem da empresa em busca de pontos, onde o conhecimento venha a trazer uma vantagem competitiva. Ela pode ser vista como um amplo processo de criação, uso e disseminação do conhecimento dentro de toda e qualquer organização que possua o conhecimento como um de seus ativos capitais.

A gestão do conhecimento pode assumir diferentes definições e denominações, no entanto, mesmo que ora dispares, todas as formas de expressar seu significado possuem no final ao menos um aspecto de similaridade em seus sentidos.

Outra definição bastante interessante é a que coloca a gestão do conhecimento como uma estratégia que busca transformar bens intelectuais da organização - informações registradas e o talento de todos os seus usuários - em uma maior produtividade. Ela procura apresentar novos valores dentro da organização e proporcionar de uma forma geral um aumento final na sua capacidade de produtividade.

Por conseguinte, a gestão do conhecimento pode ser compreendida como uma ferramenta gerencial de administração, planejamento e controle do conhecimento modelando parte do conhecimento que existe na cabeça das pessoas em regras de negócio, tornando-as visíveis à toda organização de uma forma simples e de fácil acesso, executando assim a principal funcionalidade da gestão do conhecimento .

Modelo da Gestão de Regras de Negócios

O processo de software é compreendido como sendo um ciclo de atividades que se inicia na definição dos requisitos de software até a entrega do produto desenvolvido. Sendo que neste ciclo está compreendido também o planejamento do desenvolvimento dos requisitos de software, a codificação e teste do software, implantação da aplicação com os requisitos de software.

O modelo proposto por este artigo, conforme Figura 2, além deste ciclo do processo de software, fica prevista a gestão das regras de negócios, antes da definição dos requisitos de software.

Da mesma forma, esta gestão também está compreendida num ciclo de atividades que contempla inicialmente a identificação das necessidades e oportunidades de negócios, até a implantação destas regras na rotina das atividades operacionais da organização. Um conjunto de atividades fica elencado a seguir:

• Identificar necessidade ou oportunidade de negócio – basicamente, a origem de uma regra de negócio tem como fonte novas necessidades para resolver um problema existente por falha no processo; ou por uma nova oportunidade no mercado que proporcionará divisas ou novos lucros para a organização;
• Analisar regras de negócio existentes – a nova regra de negócio, também considerada como regra candidata, deve ser avaliada quanto a sua aplicação como sendo única antes de ser detalhada em definitivo;
• Especificar regra de negócio candidata – a descrição da regra deve ter as características essenciais para o entendimento [4] para ter a compreensão suficiente para que seja aplicada corretamente, sem ambiguidade e ter a precisão nos resultados esperados;
• Aprovar regras de negócios candidatas – quando a regra de negócio está alinhada à estratégia da organização e à estratégia de negócios, com resultados mensuráveis, deve ser aprovada;
• Adequar a especificação da regra de negócio – caso não tenha aprovação da regra, esta deve ser adequada para ter o mínimo dos quesitos necessários para ser aprovada, para tanto se necessita da adequação da especificação;
• Gestão das regras de negócios – este é um processo inteiramente destinado à manutenção da regra desde a sua especificação até a desativação. Toda regra pode sofrer alterações ao longo de um período para se adequar às novas realidades em que a organização está submetida, assim requerendo uma manutenção constante;
• Validar regra de negócio no software – o software que atende às regras de negócio devem ter estas regras validadas pelo resultado almejado, pela fidelidade à regra aprovada para uso na organização;
• Processo de Desenvolvimento de Software – este é um processo conhecido pelas atividades de planejamento, levantamento de requisitos até a entrega efetiva do produto de software. Conforme descrito por [1], as atividades previstas no processo deve ter como objetivo a qualidade final do software.

Considerando que a gestão do conhecimento é um processo único e delimitado pelo seu domínio, em função da natureza, objetivo e responsabilidade; se torna perceptível a separação o controle das necessidades de negócios e dos requisitos de softwares.

Outro fator está relacionado à evolução das necessidades de negócios que têm velocidades e amplitudes diferentes dos requisitos de softwares.

Ao iniciar o desenvolvimento de software, o objetivo principal é atender às necessidades dos usuários finais através dos requisitos do sistema. Na organização, as atividades são executadas seguindo um modelo de processo que analisa os requisitos e projeta uma arquitetura do software para atender aos requisitos analisados.

Efetivamente, mecanizando os processos, tratando os dados de entradas e formatando as informações resultantes, até que o processo reflita as definições das regras de negócios.

De modo geral, as regras de negócio definem as condições em que um processo é realizado ou as novas condições após a conclusão de um processo. A grande vantagem em separar a regra de negócio do requisito de software está na validação do sistema com a lógica do negócio. Uma vez que a regra de negócio passa a ser um processamento, descrito por um requisito de software, esta deve validada.

O principal objetivo deste artigo foi modelar um processo de gerenciamento de regras de negócios possível de ser utilizado numa organização em que estas regras são utilizadas somente como insumo para o desenvolvimento de software. Foi escolhido o GAIA para aplicar o modelo proposto neste artigo, com o objetivo de aumentar a qualidade dos produtos desenvolvidos.

Este modelo será aplicado em ambiente especificamente de desenvolvimento de software, dando como foco principal o gerenciamento da regra de negócio por uma equipe que conhece o gerenciamento de requisitos de software. Com a nova visão para regra de negócio as pessoas estarão comprometidas também com os objetivos estratégicos da organização.

Atualmente o GAIA contempla um modelo de desenvolvimento com o ciclo de vida caracterizado pelo processo de software, no qual a gestão de requisito prioriza os requisitos de sistemas. Com o novo modelo passará a executar atividades de gestão das regras de negócios que contempla maiores esforços na manutenção dos requisitos de usuários com objetivos estratégicos da organização.

Cada projeto desenvolvido pelo GAIA passará por um critério mais efetivo na escolha da funcionalidade a ser desenvolvida juntamente com as regras priorizadas pela organização. Como podemos observar na Figura 3, as atividades de desenvolvimento de software estão representadas pelo fluxo em amarelo, enquanto que no fluxo azul ficam demonstradas as atividades da manutenção das regras de negócios.

O modelo tem como objetivo aumentar a qualidade do software desenvolvido, desde a sua concepção, projeto, desenvolvimento, entrega e resultados de sua aplicabilidade. No fluxo tradicional da gestão de requisitos e sua implementação, o objetivo é atender as definições descritas nestes requisitos funcionais e não-funcionais.

Enquanto que com a implementação do fluxo acrescido da gestão de regras de negócios, o comprometimento fica ampliado aos resultados que o software deve proporcionar à organização patrocinadora do projeto.

Links Úteis

• JWT: Web services seguros em Java:
  Aprenda a programar web services RESTful seguros utilizando JWT (JSON Web Tokens). Para isso tomaremos como base uma Web API que já fornece um CRUD de marcas e produtos, mas que ainda não provê nenhum mecanismo de segurança, nenhum controle de autenticação e autorização.
• Django REST Framework: Criando uma API RESTful 1:N:
  Veremos neste curso como implementar o relacionamento 1:N entre três entidades (Vaga, Empresa e Requisito) utilizando APIs com o Django REST framework.

Saiba mais sobre Desenvolvimento de Software ;)

• Gestão de Projeto:
  Neste guia você encontrará o conteúdo que precisa para saber como gerenciar projetos de software. Confira abaixo a sequência de posts que te guiarão do básico ao avançado em Gestão de Projetos.
• Requisitos, Modelagem e UML:
  Neste guia você encontrará o conteúdo que precisa para saber como elicitar requisitos, gerenciá-los e modelar o software com as principais técnicas do mercado. Abaixo, confira os posts que te auxiliarão ao longo desse aprendizado.
• Modelagem de Processos de Negócio:
  Neste guia de consulta você encontrará diversos conteúdos que podem ser usados ao longo dos seus estudos sobre a Modelagem de Processos de Negócios, explorando técnicas e ferramentas relacionadas a essa atividade.

Referências

• 1. I. Sommerville, Engenharia de Software. 9ª edição. Editora Pearson do Brasil, 2011.
• 2. Sujithra S. and Chandrashekar R., “Externalizing business rules from business processes for model based testing”, International Conference on Industrial Technology, 2012, pp. 312-318.
• 3. Wan-Kadir, WMN; Pericles Loucopoulos; “Relating evolving business rules to software design”, 2012, pp. 367-382.
• 4. P. Tosanguan, T. Suwannasart, “An Approach for Defining Rules as Functions in Rule-Based Rule-Based Software Development”, International Conference on Digital Information Management, 2012, pp. 30-34.
• 5. Wen B., Z. Luo, P. Liang “Distributed and Collaborative Requirements Elicitation based on Social Intelligence”, Ninth Web Information Systems and Applications Conference, 2012, pp. 127-130.
• 6. D. P. A. Junior and R. Campos “Definição de requisitos de software baseada numa arquitetura de modelagem de negócios”. Prod. Vol. 18 nº1, São Paulo. ISSN 0103-6513, 2008.