5.1.1 Modelo de processo
O processo utilizado nesta pesquisa descreve o fluxo de um sistema de solicitações de de- senvolvimento de software. Esse processo pertence a uma empresa real e contempla desde a descrição do módulo a ser implementado até o seu desenvolvimento e validação. A modelagem do processo segue as características presentes na ferramenta Oracle Workflow.
60
A Figura 12 ilustra o modelo do processo, o qual é composto por um processo principal (main process) e dois sub-processos, um responsável pela execução da solicitação, S:1, e outro pela avaliação da execução solicitada, S:2. A seguir, tanto o processo principal quanto os sub- processos são descritos em função do fluxo das atividades, sem entrar em maiores detalhes com relação à lógica utilizada.
Primeiramente, é verificada a necessidade de gerar a especificação do componente solici- tado. Caso seja necessário, antes de executar o pedido, o solicitante deve especificar o programa a ser desenvolvido. Se o responsável pela implementação do componente constatar que não é possível atender os requisitos solicitados, o sistema envia uma mensagem notificando essa indis- ponibilidade da solicitação. Do contrário, após a implementação do componente, pode existir a necessidade de avaliá-lo. Se não for preciso avaliar o componente, o pedido é registrado como encerrado e as horas de trabalho são totalizadas. Sendo necessário avaliar o componente, o processo pode seguir diferentes caminhos. Se a avaliação for de reprovação, a solicitação é en- viada novamente para o responsável pela execução (implementação), senão, o fluxo do processo termina.
No sub-processo S1, o pedido tem seu status alterado para "em andamento", A5, e a soli- citação é encaminhada para o responsável, A6. Ele pode implementar o componente solicitado (A7), verificar a indisponibilidade de atender os requisitos solicitados (o pedido é registrado como encerrado e as horas de trabalho são totalizadas, A18), ou ainda, inserir o pedido numa lista de espera, A21. Caso o responsável exceda o tempo determinado para a execução da soli- citação, time out, o solicitado e o solicitante recebem um aviso de atraso do pedido (A22, A23 e A24).
No sub-processo S2, primeiramente é verificado se o solicitado é a mesma pessoa que reali- zou a solicitação (A12). Caso positivo, o pedido é encerrado, as horas de trabalho são totalizadas e o solicitado recebe uma avaliação de aprovação do pedido (A15, A16 e A17). Caso contrá- rio, estas tarefas somente serão realizadas se, mediante avaliação (A13), o solicitante validar o pedido. Do contrário, a solicitação é encaminhada novamente para a atividade de execução do pedido (A14).
Cabe salientar que não existem outros detalhes fora os comentados nesta seção sobre o processo ilustrado na Figura 12, o que prejudicou um pouco as atividades subseqüentes do processo de KDD.
Em meio a tantas alternativas de fluxo dentro do processo, deseja-se compreender quais são os fatores que contribuem para o tempo de execução do processo. Assim, formula-se o seguinte objetivo de negócio: Classificar as instâncias desse processo de acordo com o seu tempo de execução, buscando as características que determinam se o processo é terminado a tempo ou atrasa o final de sua execução.
61
5.1.2 Modelo de dados
Os dados utilizados foram disponibilizados em banco de dados Oracle. Essa base, ilustradas nas Figuras 13 e 14, é referente ao modelo de Data Warehouse proposto por Fábio Casati em [33]. Este modelo analítico foi alimentado a partir do modelo de dados dos registros de execuções do Oracle Workflow como parte do estudo de caso desenvolvido em [2].
A base de dados representa um modelo dimensional do tipo constelação, o qual é composto por tabelas fato e dimensão associadas [34]. Nas tabelas do tipo dimensão estão armazenados os dados principais referentes aos processos, atividades, recursos, etc. As tabelas do tipo fato armazenam as instâncias de processos, atividades, dados e serviços, as quais se relacionam com diferentes tabelas dimensão.
Como o objetivo é classificar processos de acordo com o tempo de execução dos mesmos, é necessário verificar se há dados disponíveis para atender esse objetivo. Assim, à medida que as tabelas forem sendo analisadas, serão feitos comentários sobre essa questão.
A definição dos processos disponíveis é armazenada na tabela dimensão PROC_DEFS_D, ilustrada na Figura 13, a qual contém informações como o nome do processo, versão e o grupo ao qual ele pertence.
Figura 13: Dimensões definidas pelo Modelo Analítico. Fonte: [2].
As instâncias dos processos são armazenadas na tabela fato PROC_INST_F (Figura 14). Pode-se observar a presença de informações importantes como o tempo de início e de término do processo, tempo de duração desses processos em dias, horas e minutos e a pessoa responsável pela execução da instância do processo. Ou seja, é possível obter informações temporais para processos, o que é um bom indício de que os dados atendem ao objeto de negócio.
62
Figura 14: Fatos definidos pelo modelo analítico e seus relacionamentos. Fonte: [2].
Os processos podem possuir dados de controle associados a eles. Esses dados de con- trole são definidos na tabela DATA_DEFS_D e suas instâncias são representadas pela tabela PROC_INST_DATA_F (Figura 14). Tais dados de controle também podem influenciar no tempo de execução dos processos.
As definições das atividades são representadas pela tabela NODE_DEFS_D, ilustrada na Fi- gura 13. Cada atividade pertence a uma definição de processo (chave estrangeira PROC_DEF_ID) e possivelmente possui um serviço associado (chave estrangeira SERVICE_DEF_ID). As ati- vidades que não possuem um serviço associado são aquelas atividades de controle de fluxo, por exemplo, a atividade start. As atividades que possuem serviço associado são aquelas que interessam para este trabalho, pois demandam tempo e recursos para sua execução.
Na tabela SERVICE_INST_F estão as instâncias dos serviços. Nessa tabela constam infor- mações tais como: a qual atividade pertence esse serviço, em qual definição e qual instância de processo o serviço é utilizado. Através dessa tabela também é possível saber se o serviço foi executado pelo mesmo recurso pelo qual ele foi programado, além de informar o tempo de execução esperado e o tempo que realmente foi utilizado para execução. Os serviços também possuem informações temporais, o que é bastante relevante para o objetivo de negócio proposto. As atividades também podem conter dados. Esses dados, como, por exemplo, a descrição da tarefa realizada, são definidos na tabela DATA_DEFS_D e suas instâncias são armazenadas na tabela NODE_INST_DATA_F. As tabelas são ilustradas na Figura 14. Os dados referentes às atividades também podem ser úteis para a determinação do tempo de execução dos processos.
63
Os tempos são representados na tabela dimensão TIME_D. Eles podem ser expressos em várias unidades como, por exemplo, dia, semana, mês, ano, horas e minutos. Nota-se que essa tabela tem relacionamento com as tabelas SERVICE_INST_F e PROC_INST_F. Assim, pode- se concluir que as informações temporais sobre instâncias de processos e instâncias de serviços podem ainda ser mais detalhadas através da tabela TIME_D.
A partir do estudo realizado sobre o modelo para análise de processos de negócio, é possível concluir que o mesmo nos disponibiliza dados interessantes para atingir o objetivo de negócio. É verdade que isso não depende somente do modelo, mas sim dos dados com os quais o modelo é carregado.
Terminada essa etapa, a seguir será apresentada a preparação dos dados para a aplicação das técnicas de mineração.