← Blog · 22 Mar 2018 · 10 min de leitura

Como otimizar seu fluxo de trabalho, aumentando suas entregas e reduzindo custos, por meio de simulação de processos

Otimização de processo de desenvolvimento de software: Uma abordagem utilizando BPMN, simulação por eventos discretos e programação não linear

Resumo - O presente artigo visa demonstrar como a modelagem BPMN 2.0 e a simulação por eventos discretos podem auxiliar aos gestores de processos e qualidade de software a tomar decisão sobre qual o melhor processo e recursos poderão ser usados para o desenvolvimento de um software. Por meio de análise de cenários (what if) e otimização não linear será possível avaliar qual o ponto ótimo de utilização dos recursos disponíveis, ou seja, identificar qual cenário de uso de um processo tem o custo menor e com maior entrega de funcionalidades para o cliente. Foi usado uma versão com um nível de detalhe mais macro, de um processo típico de desenvolvimento de software, porém com dados reais de execução de cada uma das atividades do processo listadas. Isto se justifica pelo objetivo central do artigo se concentrar em demonstrar as técnicas de simulação e otimização para tomada de decisão para a melhoria de processos e não o processo em si e sua aplicabilidade

Quer saber como melhorar seu processo por meio de uma abordagem Kanban? Venha participar do Workshop Lean-Kanban Fundamentals !

INTRODUÇÃO

O modelo reflete o processo de uma célula de desenvolvimento de software de uma empresa bastante conceituada no Brasil nos ramos em que atua. Aplicou-se as técnicas de redesenho de processo e de melhoria contínua para avaliar o processo de desenvolvimento de software (PDS) atual (AS IS) e propor a melhoria do processo (TO BE). Por meio da simulação por eventos discretos, ou seja, uma simulação que trata uma sequência atômica de eventos e que faz uso de comportamentos estocásticos tendo por foco a otimização operacional, foi possível simular cenários de melhoria do processo. A fim de decidir qual a melhor configuração a ser utilizada, com os cenários produzidos pela simulação, é demonstrada no artigo como fazer uso de técnicas de otimização não linear utilizando a ferramenta Solver do pacote MS-EXCELL. Por meio desta ferramenta, é possível avaliar qual o melhor cenário de otimização de processo que pode ser aplicado diante de um panorama de recursos financeiros limitados, buscando maximizar qualidade da entrega, menor custo de execução do processo e maior valor agregado entregue ao cliente.

2. DESENVOLVIMENTO

A metodologia utilizada está descrita nos itens abaixo:

Desenhar o processo atual (AS IS)
Avaliar os tempos de processamento de cada atividade do processo atual
Realizar a simulação do processo com alguns cenários de utilização
Avaliar os pontos de possíveis melhorias no processo atual
Desenhar o novo processo com as melhorias identificadas
Realizar a simulação do processo com alguns cenários de utilização
Aplicar as técnicas de otimização, por meio do Solver do pacote MS-EXCELL a fim de identificar qual a configuração ótima do processo.

O processo atual em execução e que é o alvo da melhoria a ser aplicada está exposto na fig. 01 a serguir. Se trata de um processo típico de desenvolvimento de software com as atividades: listar requisitos, especificação de requisitos, análise dos requisitos, prototipação, construção, homologação e validação final.

A atividade listar requisitos é realizada pelo Analista de Negócios (AN) e consiste em gerar uma lista de itens a serem realizados pelo requisito que será desenvolvido. Esta lista representa o que será construído. A especificação de requisitos é feita pelo Analista de Sistemas (AS). O artefato gerado será um documento detalhado de como o requisito listado deverá ser construído. Em seguida o AS irá fazer a análise do requisito, ou seja, fazer o projeto físico do requisito que consiste em criar as classes de negócio e de dados, com suas validações intrínsecas, bem como outros itens relativos ao projeto que se fizerem necessários. Logo após esta atividade inicia-se a prototipação do requisito pelo Prototipador (PP) (ou desinger). Este protótipo servirá de base para a validação do AN. Esta validação não está descrita neste processo AS IS pois se trata de um item a ser executado na atividade de prototipação. Após finalizar a prototipação começa-se a codificação do requisito pelo Desenvolvedor (DSV), onde será feita a criação de código executável para a funcionalidade a ser entregue. Feita a codificação, os testes serão realizados pela equipe de homologação, constituída de Analistas de Testes (AT). Os testes consistem em criar os cenários de testes do requisito, projetar e especificar os testes (roteiro e massa de teste), executar os testes progressivos (testes manuais), realizar a automação do teste e executar regressivos (automatizados). Caso ocorra defeitos nos testes, os defeitos serão registrados e enviados para correção, que após corrigidos serão retestados (teste manual). Após o reteste pelo AT, a funcionalidade vai para a validação final realizada pelo AN, que pode ou não encontrar defeitos. Ao terminar a validação o processo é finalizado com a funcionalidade construída.

fig_01 Fig. 1. Modelo PDS-AS IS

Os tempos de cada atividade do processo atual (AS IS) estão descritos na tabela abaixo. Foram coletados os dados de média, desvio padrão, tempo mínimo e tempo máximo, de cada atividade do processo. Os dados coletados têm origem nos registros diários e individuais dos tempos gastos nas atividades executadas pela equipe pertencente à célula de desenvolvimento de software, sobre a qual está sendo avaliado o processo. Serão exibidos neste artigo, somente os dados médios de utilização dos recursos, que foram considerados como sendo os de maior relevância para a tomada de decisão.

Tabela 1

Tempos (em horas) das atividades do processo – PDS AS IS

Atividade	Média	Desvio	Min.	Max
Início do processo Listar requisitos Especificar requisitos Analisar requisitos Protótipar Codificar Executar testes funcionais Corrigir defeitos Reteste Validar entrega	1,06 1,12 11.39 2,11 1,06 11,73 5,28 0,28 1 2,13	0 0,54 6,98 1,26 0,63 6,97 3,14 0,17 0 1,27	0 0,27 4,25 1,14 0,57 6,33 1,78 0,19 0 1,15	0 2,12 31,6 9,12 4,56 50,64 22,8 1,12 0 9,19

Após a realização da coleta dos dados do processo atual (AS IS), foi feita a realização da simulação do processo, com a produção de 12 cenários, sendo 50 replicações de cada cenário. Cada replicação foi configurada para ser simulada a execução do modelo em um período de 30 dias, de segunda-feira a sexta-feira, por 7 horas/dia. Nestes cenários foram coletados o tempo médio de execução de cada atividade do processo, desvio padrão, tempo mínimo e máximo, funcionalidades entregues, funcionalidades que falharam, tempo médio de utilização dos recursos e o custo de execução de cada atividade do processo.

Na tabela 2 abaixo estão demonstrados o percentual de utilização de cada recurso em cada um dos 12 cenários simulados do modelo PDS – AS IS. Nota-se nos resultados simulados as variações de percentual de uso dos recursos gerada pelas simulações realizadas. Estes valores representam a média aritmética das 50 replicações realizadas para cada um dos cenários.

Tabela 2

Utilização média dos recursos por cenário – PDS AS IS

Cenário	AN	AS	AT	DEV	PP
1 2 3 4 5 6 7 8 9 10 11 12	17,60% 99,68% 83,48% 80,74% 80,63% 83,37% 84,90% 82,34% 83,59% 91,29% 91,21% 86,39%	99,86% 29,69% 32,69% 33,01% 32,96% 32,96% 35,92% 35,81% 35,81% 26,33% 26,27% 35,81%	3,92% 43,78% 46,19% 57,67% 28,83% 28,76% 32,27% 27,11% 33,59% 31,40% 30,92% 33,59%	8,1% 96,50% 84,33% 84,37% 81,96% 97,74% 82,91% 82,27% 86,19% 64,23% 91,04% 88,56%	0,72% 14,75% 16,38% 16,41% 16,38% 16,38% 18,30% 17,81% 17,81% 13,05% 13,04% 17,81%

O modelo PDS TO BE está descrito abaixo na figura 2. As alterações realizadas se deram na etapa de especificação. A atividade de especificação de requisitos passará a ser feita pelo AN. Na versão AS-IS do processo o AN fazia somente a listagem das regras e todo o detalhamento era feito por um AS. Uma segunda mudança a ser feita é a revisão por pares para que seja aumentada a qualidade da entrega do desenvolvimento para a equipe de testes.

No processo AS-IS a fase de testes funcionais estava direcionada para o AN. Depois da execução da validação o AN teria que gerar uma documentação para que os testes fossem automatizados. Na versão TO-BE a etapa de testes funcionais foi transferida para os AT, que de posse da documentação da especificação de requisitos, teria um material melhor para a criação dos testes e a sua posterior automação, diminuindo assim o tempo de validação do AN. Um segundo objetivo é utilizar de forma mais efetiva e com maior taxa de ocupação o AT, que é um recurso com custo menor do que o NA. Com um tempo maior disponível o AN poderia se dedicar com maior foco na criação das especificações de regras de negócio. Este maior detalhamento também favorece a equipe de construção pois terá maior e melhor insumo para desenvolver a aplicação.

Houve também uma mudança quanto ao uso do recurso PP. No PDS-AS IS toda funcionalidade passava pelo PP para ser criado o protótipo. No PDS-TO BE somente 10% das funcionalidades irão ter protótipo criado, uma vez que 90% das funcionalidades são do tipo web services ou rotinas de processamento batch, que não necessitam de ter protótipo implementado.

fig_02

Fig. 2. Modelo PDS-TO BE

A tabela a seguir mostra os valores médios de utilização dos recursos coletados dos 12 cenários de simulação realizados, com 50 replicações cada. Os dados de calendário de simulação foram os mesmos utilizados na simulação do processo AS IS.

Tabela 3

Utilização média dos recursos por cenário – PDS TO BE

Cenário	AN	AS	AT	DEV	PP
1 2 3 4 5 6 7 8 9 10 11 12	100,00% 99,90% 79,68% 80,82% 80,82% 80,25% 82,35% 78,48% 79,73% 90,59% 89,51% 83,31%	46,23% 32,02% 33,01% 33,01% 33,01% 33,01% 34,32% 35,83% 35,83% 27,72% 27,53% 35,83%	43,93% 44,32% 46,48% 57,80% 28,92% 27,18% 36,29% 27,23% 33,71% 32,90% 32,34% 33,71%	98,34% 98,35% 84,57% 84,48% 82,19% 82,26% 81,21% 82,51% 86,43% 67,38% 95,42% 88,81%	9,82% 9,62% 3,32% 3,32% 3,32% 3,32% 3,32% 3,61% 3,61% 2,80% 2,77% 3,61%

Nos gráficos a segui pode-se perceber que o custo médio dos cenários de simulação do modelo PDS-TO BE é cerca de 19,67% menor que o custo do processo PDS – AS IS. Também o modelo PDS- TO BE mostra-se com um desvio padrão cerca de 67% menor e o coeficiente de variação num valor menor que 10%, que mostra que nível de variação do processo é significativamente menor que no modelo PDS – AS IS. No modelo de simulação foi utilizado a variável de custo fixo por recurso, para obter desta maneira uma referência financeira do custo da atividade realizada em função do recurso associado.

fig_03

Fig. 3. Custos dos Processos

Foram simulados 24 cenários de uso do processo, sendo 12 cenários no modelo PDSS – AS IS e 12 cenários no modelo PDS – TO BE. A fim de se identificar qual o cenário ótimo de utilização dentro dos recursos financeiros disponíveis e quantidade de entregas realizadas, foi utilizado os recursos de otimização disponíveis no pacote MS EXCEL, chamado Solver. Por meio do Solver, com as restrições abaixo, identificou-se qual o cenário ótimo para cada restrição.

Ao aplicar as restrições de minimização de custo de processo, ou seja, o processo não poderia ter um custo maior do que a restrição imposta, o cenário escolhido foi o TO BE – CN 04. O limite mínimo de custo imposto foi de R$ 7.000,00 e limite mínimo de entregas de funcionalidades foi de 60.

Para uma outra simulação de cenário de otimização onde o objetivo principal foi maximizar as entregas, tendo o mesmo limite máximo de custo de processo imposto de R$ 7.000,000, o cenário escolhido foi o TO BE – CN 10.

A execução da otimização do modelo com apenas duas restrições, se mostrou viável tanto pelo método GRG Nonlinear, quanto pelo método Simplex. No método GRG Nonlinear foram gastos 0,984 segundos e pelo método Simplex foram gastos 0,078 segundos para se chegar a uma solução viável. Em ambos os métodos a solução encontrada foi igual. No gráfico da fig. 4 podemos observar a superfície de soluções ótimas disponíveis para os cenários simulados.

fig_04

Fig. 4. Projeção do Custo do Processo x Entregas Realizadas x Média de utilização dos recursos

3. OBSERVAÇÕES FINAIS

O uso das técnicas de redesenho e melhoria de processos, por meio da metodologia BPMN, bem como a simulação dos processos utilizando eventos discretos se mostrou muito importante e com um arcabouço muito poderoso para tomada de decisão.

Os benefícios da simulação de processos e otimização não linear, quando utilizados em conjunto, fortalecem ainda mais a tomada de decisão para a melhoria de processos.

Ao se fazer uso dos instrumentos de simulação foi possível perceber que os cenários de uso do modelo PDS – TO BE são significativamente mais econômicos que os cenários de simulação do modelo PDS – AS IS. Se não fosse possível utilizar os métodos de simulação e otimização, seria excessivamente caro e inviável avaliar cada cenário proposto e dificultaria ainda mais a tomada de decisão por parte dos gestores.

Outras análises podem ser feitas a partir dos modelos propostos. Por exemplo pode-se avaliar mudanças que irão impactar na qualidade entregue das funcionalidades, níveis de retrabalho devido a defeitos e automação de atividades que são realizadas manualmente. Outra análise a ser realizada é o detalhamento de subprocessos envolvidos ou ainda um maior detalhamento dos custos de execução das atividades.

Referências

BRAGA, Gustavo Simões. Inovação e gestão de processos de negócios (BPM): uma metodologia adaptada para pequenas empresas. 2015. 169 f. Dissertação (Mestrado em Administração). Universidade Federal do Paraná, Curitiba, 2015.

FREITAS FILHO, PAULO JOSÉ DE. Introdução à modelagem e simulação de sistemas: com aplicações em Arena. 2. ed. Florianópolis: Visual Books,2008.

HARMON, P. Business Process Change: A Business Process Management Guide for Managers and Professionals. 3ª. ed. Elsevier Inc: [s.n.], 2014

HILLIER, Frederick S.; LIEBERMAN, Gerald J. Introdução à pesquisa operacional. McGraw Hill, 2010.

MAMEDE, A. Transformação de processos de negócios. 5º ABPMP BPM Meet Up Belo Horizonte/MG, 2015.