modelagem de processos de negÓcio aplicado ao processo de desenvolvimento de … · 2016-08-11 ·...

MODELAGEM DE PROCESSOS DE

NEGÓCIO APLICADO AO PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE

Alexandre Roberto dos Passos (PUC-PR) [email protected]

Eduardo Alves Portela Santos (PUC-PR) [email protected]

Marco Antonio Busetti de Paula (PUC-PR) [email protected]

Eduardo de Freitas Rocha Loures (PUC-PR) [email protected]

O mercado de software está a cada dia se aprimorando, trazendo

consigo novas ferramentas e novas formas de se administrar empresas.

Com foco centrado no processo de desenvolvimento de software (PDS),

principalmente no que tange a sua estruttura e ao seu fluxo funcional,

este trabalho busca propor melhorias ao PDS. Para tal, busca-se aqui

explorar o formalismo de “redes de petri” para efetuar a modelagem e

a análise ao PDS.

Palavras-chaves: Processo de desenvolvimento de software; Redes de

petri; Modelagem de processos; Análise de processos.

XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO A integração de cadeias produtivas com a abordagem da manufatura sustentável.

Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008



2

1.1. 2. Introdução

Diante da demanda crescente por sistemas informatizados, o Processo de Desenvolvimento de Software (PDS) tem sido foco de muitos trabalhos no sentido de prover melhorias a tal processo. O objetivo principal desses trabalhos é aumentar a qualidade do produto final, de forma a fornecer as empresas ferramentas de suporte confiáveis e que tragam implicitamente vantagens competitivas frente aos concorrentes. Nesse contexto, as empresas prestadoras de serviço, que desenvolvem e personalizam softwares, estão em constante aprimoramento para atender às necessidades de seus clientes. A busca crescente pela obtenção de vantagem competitiva em seu mercado de atuação acaba direcionando atenção para seus processos internos, os quais, muitas vezes, são defeituosos e precários.

Na literatura, estudos tratam diretamente sobre processo de desenvolvimento de software, buscando gerenciá-lo e melhorá-lo (BEZERRA, 2004). A abordagem de Gestão do Conhecimento é apresentada em Parreiras & Oliveira (2004) como mecanismo para melhorar o PDS. Em Kantorski & Kroth são apresentadas a medição de atividades e o gerenciamento e relacionamento entre workflows como aspectos decisivos na melhoria de processos de desenvolvimento de software. Da mesma forma, ainda em busca por melhorias do PDS, Tamaki & Hirama buscam demonstrar como é possível projetar e implantar melhorias sobre um processo existente, aplicando process patterns. Desse modo, pode-se verificar que esforços vêm sendo dispensados em busca de melhorias.

Por outro lado, ainda existem lacunas que podem ser tratadas de forma a prover melhoria ao PDS. A aplicação de abordagens formais na modelagem do PDS bem como posterior análise, ainda é tema pouco explorado na literatura. Nesse contexto, a abordagem denominada GPN – Gestão de Processos de Negócios – tem sido utilizada como ferramenta fundamental na gestão de processos. Os sistemas de gestão de processos de negócios auxiliam a execução e a manutenção de, como o nome já sugere, processos de negócios. Diversos autores têm utilizado as redes de Petri como modelo formal na abordagem GPN (AALST et al., 1994; PÁDUA et al.,2004). A principal vantagem na utilização deste modelo está no seu fundamento matemático, que resulta numa modelagem e análise confiáveis. A partir deste modelo, é possível extrair a estrutura lógica do processo modelado bem como obter dados quantitativos utilizando a simulação (por exemplo, planejamento de capacidade de um determinado setor).

O presente trabalho tem por objetivo aplicar a abordagem GPN para a modelagem e análise de um PDS de uma empresa real. Esta empresa é fornecedora de sistemas informatizados para a rede hoteleira de distintas regiões do Brasil e do exterior. O problema detectado no PDS da referida empresa diz respeito ao tempo de liberação do produto final. Detectou-se a ausência de monitoramento das diversas atividades do PDS, o que acaba gerando um descontrole de todo o processo. Consequentemente, a empresa está lidando com grandes atrasos na liberação dos softwares produzidos, gerando perda de receita, de contratos e insatisfação dos clientes. Nesse contexto, o presente artigo descreve inicialmente a aplicação da abordagem GPN na modelagem do processo atual, utilizando-se de dados históricos e documentação existente. Em seguida, a partir do modelo construído, informações lógicas e quantitativas são extraídas e estudadas com o apoio de ferramentas computacionais específicas. Estas informações são utilizadas como apoio a tomada de decisão em relação a modificações no PDS, seja sob o ponto de vista de fluxo de atividades como no planejamento da capacidade dos recursos (funcionários).



3

O artigo está estruturado da seguinte forma: na seção 2 são apresentados os fundamentos teóricos utilizados no presente trabalho – o PDS, o GPN e as redes de Petri; na seção 3 é apresentada a modelagem do PDS atual utilizando as redes de Petri e análise do modelo obtido; na seção 4 descreve-se a avaliação do cenário atual, extraída a partir das informações levantadas na seção anterior; na seção 5 apresentam-se as principais conclusões do trabalho, suas limitações e as perspectivas de continuidade da abordagem proposta.

3. Fundamentação

Para viabilizar alcançar os objetivos acima propostos, faz-se necessário um embasamento teórico que possibilite esclarecer, mesmo que sucintamente, as principais áreas de interesse deste trabalho. O objetivo desta seção é descrever as ferramentas e abordagens utilizadas no presente trabalho, quais sejam: PDS, o GPN e as redes de Petri.

3.1. Processo de Desenvolvimento de Software (PDS)

O PDS é contemplado pela área de engenharia de software e está consolidado na literatura como sendo composto por três grandes fases: definição, desenvolvimento e manutenção. Estas fases estão contidas em, basicamente, qualquer processo de desenvolvimento de software. Um processo de desenvolvimento de software pode ser caracterizado como um “framework de processos compartilhados” o qual contém um número de “atividades de framework” que são aplicados para todos os projetos de software. As “atividades de framework” são compostas por um número de “conjunto de tarefas” que viabilizam a adaptação das “atividades de framework” a qualquer característica do projeto de software, assim como, aos requisitos provindos do time de projeto. Por fim, estando em paralelo às “atividades de framework”, um grupo de atividades tem por função aprovar o processo (PRESSMAN, 1997). A figura 1 ilustra o framework do PDS.

Figura 1 - Framework de processos de desenvolvimento de software (PRESSMAN,1997)

Sendo parte integrante da engenharia de software, o PDS pode ser caracterizado como um roteiro de elaboração de software, que deve contemplar fases, subfases, produtos externados e pontos de avaliação de qualidade. Neste contexto, processos podem ser definidos para atividades como projeto, desenvolvimento e manutenção de software. Da mesma forma, subprocessos podem ser definidos para estas atividades, como análise de requisitos funcionais, programação e testes (REZENDE, 2002).

Diversos modelos de PDS podem ser encontrados na literatura, sendo os principais (PRESSMAN, 1997): Seqüencial linear: Também conhecido como modelo cascata ou modelo clássico. Basicamente é constituído, seqüencialmente, pelas etapas de análise, design,



4

codificação e teste; Prototipação: Tem como filosofia o desenvolvimento de acordo com os requisitos do cliente. Tão logo esteja pronto, o software é apresentado para o cliente para que o mesmo teste e valide o protótipo. Dessa maneira o software toma forma de maneira iterativa; RAD (Rapid Application Development): Modelo no qual o ciclo de desenvolvimento tem um período de tempo considerado curto. É considerado um modelo seqüencial linear de alta velocidade, onde o período de tempo de seu desenvolvimento pode variar em torno de 90 dias; Evolucionário: Modelo que tende a atender um crescimento no software ao decorrer do tempo, de forma iterativa.

3.2. Gestão de Processos de Negócio

Processo de negócio é um conjunto de atividades relacionadas a um negócio que é realizado em uma seqüência específica com a finalidade de alcançar um objetivo de negócio. As atividades de um processo de negócio são tanto automatizadas como manuais, realizadas com ou sem interação humana, com integração com outras organizações, ou até mesmo um processo de negócio inteiro. Com esta variedade de tipos de atividades, um processo de negócio torna-se complexo, sendo composto de vários processamentos em sistemas informatizados, de preenchimentos de documentos, de atividades realizadas em série ou paralelas, de troca de informações, de trabalhos manuais, além de ser afetado por diferentes regras de negócio (DAYAL et al., 2001).

Um processo de negócio é atualmente visto como um ativo significativo de uma organização, quanto mais organizados são os processos de uma organização maior é considerado o seu grau de maturidade. As organizações estão trabalhando cada vez mais de forma cooperativa para alcançar seus objetivos de negócio por meio da realização de processos de negócio inter-organizacionais, normalmente usando um paradigma de sub-contratação de serviços. O dinamismo existente no mercado requer que companhias ajam rapidamente para não perder parcerias ou oportunidades.

Nesse contexto, os sistemas de gestão de processos de negócios (GPN) auxiliam a execução e a manutenção dos processos de negócios. Os elementos centrais de um GPN são as tarefas do processo de negócio, o fluxo de controle ou ordem na qual as tarefas devem ser executadas, os dados ou documentos que são entrada/saída dessas tarefas, as funções ou papéis dos responsáveis pelas tarefas, e as ligações entre essas funções e os funcionários/sistemas. A implantação e manutenção de sistemas GPN envolvem quatro fases: modelagem, configuração, execução e análise, conforme ilustrado na Figura 2.

Figura 2 - Ciclo de vida de um sistema GPN

Na modelagem, os modelos das tarefas, fluxos de controle, papéis e dados de entrada/saída são definidos. A configuração consiste em implementar num sistema GPN os modelos definidos durante a modelagem. Por exemplo, nesta fase são estabelecidas as ligações entre os papéis e os funcionários/sistemas da empresa. A nova configuração entra efetivamente em operação durante a fase de execução. Esta fase gera os dados de execução que são utilizados



5

durante a fase de análise. A análise fornece feedback sobre diferentes características dos processos de negócio. Por exemplo, pode-se analisar esses processos para detectar os fluxos mais freqüentes e os pontos de gargalo no sistema.

No presente trabalho, serão tratadas as fases de modelagem e análise do processo de negócio em questão (no caso, o PDS).

3.3. Redes de Petri

O principal objetivo de um sistema de gerenciamento de workflow é o suporte para a definição, execução, registro e controle de processos. Devido ao processo ser o fator dominante em gerenciamento de workflows, é importante usar um framework para modelagem e análise de processos e seus fluxos de atividades. Neste artigo nós usaremos um framework baseado em redes de Petri (para referências, ver Murata (1989)). Redes de Petri são técnicas de modelagem de processos bem fundamentadas. A rede de Petri clássica foi inventada por Carl Adam Petri nos anos sessenta. Redes de Petri têm sido usadas para modelar e analisar vários tipos de processos, como aplicações com protocolos, dispositivos físicos, sistemas incorporados de manufatura flexível, interação com usuários e processos de negócios (AALST, 1998). De acordo com Aalst (1998), existem várias razões para a adoção de redes de Petri na modelagem de workflows:

a) Semântica formal – Um processo de workflow especificado em termos de redes de Petri tem uma definição limpa e precisa, porque a semântica de uma rede de Petri clássica e suas derivadas (cor, tempo, hierarquia) foram formalmente definidas;

b) Natureza gráfica – Rede de Petri é uma linguagem gráfica. Como resultado, redes de Petri são intuitivas e fáceis de aprender. A natureza gráfica também suporta a comunicação com usuários finais;

c) Expressividade – Redes de Petri suportam todas as primitivas necessárias para modelar um fluxo de processos de trabalho. Todos os construtores de rotinas presentes nos dias atuais para sistemas de gerenciamento de fluxos de trabalho podem ser modelados. Mais ainda, o fato de que estados são representados explicitamente, sugerem para a modelagem de casos especiais e opções implícitas;

d) Propriedades – Nas últimas três décadas muitas pessoas têm investigado as propriedades básicas de redes de Petri. As fortes fundamentações matemáticas apontam que estas propriedades são racionáveis. Como resultado, pode-se encontrar várias referências de conhecimento, na forma de livros e artigos, que tratam desta técnica de modelagem;

e) Análise – Redes de Petri são marcadas pela avaliação de muitas técnicas de análise. Claramente, isto é um grande benefício que favorece o uso das redes de Petri para modelagem de workflow. Estas técnicas podem ser usadas para comprovar propriedades (propriedades de vivacidade, invariância, travamento, etc.) e para calcular medidas de performance (tempo de resposta, tempo de espera, taxas de ocupação, etc.). Deste modo é possível avaliar workflows alternativos usando ferramentas de análise padrões baseadas em redes de Petri;

f) Independência de fornecedor – Redes de Petri proporcionam um framework de ferramentas independentes para modelagem e analise de processos. Redes de Petri não são baseadas em um pacote de software de um fornecedor específico e não cessam sua



6

existência se uma nova versão é lançada ou quando um fornecedor supera outro fornecedor.

4. Modelagem do PDS Atual

Para tratarmos da modelagem e da análise sobre o cenário atual da empresa, faremos inicialmente o levantamento informacional dos dados, para na seqüência efetuarmos a modelagem, a análise e a avaliação sobre o cenário atual.

O levantamento informacional (tópico 3.1) buscará relatar como a empresa está estruturada em relação a seus recursos e suas atividades no PDS.

Um fluxo de atividades, e suas dependências, são apresentados no tópico 3.2, para possibilitar efetuar a modelagem no tópico 3.3.

No tópico de modelagem (tópico 3.3), o software Income é utilizado para efetuar a modelagem. Neste tópico a modelagem é realizada buscando demonstrar duas visões, uma geral, sobre o PDS, e outra refinada, detalhando as atividades do PDS.

Buscando validar a modelagem do tópico 3.3, é apresentado um tópico de análise qualitativa (tópico 3.4), que busca validar a estrutura dos modelos desenvolvidos no software Income, de acordo com certas propriedades de redes de petri.

4.1. Processo Informacional

Sediada em Chapecó/SC, a empresa Desbravador Automação Hoteleira desenvolve software para o setor hoteleiro, atendendo a mais de mil hotéis na América Latina (Brasil, Argentina, Paraguai, Uruguai e Bolívia), nos Estados Unidos e em Portugal.

Buscando entender como a informação é tratada pelo processo de desenvolvimento de software, contido na empresa Desbravador, buscou-se elencar quais são as atividades principais, através de setores, assim como suas inter-relações.

Deste modo, faz-se necessário analisar primeiramente o elemento de estudo, ou seja, as tarefas. As tarefas são os elementos a serem tratados pelo fluxo de atividades através de recursos, os quais são apresentados na seqüência, como sendo recursos humanos e recursos setores.

Tarefas são tratadas neste trabalho como elemento principal a ser analisado no decorrer do processo de desenvolvimento de software.

Por ter natureza abrangente e certas especificidades, ou seja, por tratar de diferentes níveis de complexidade para sua implementação no processo de desenvolvimento de software, as tarefas têm distintas classificações na empresa. A tabela a seguir demonstra como as tarefas são classificadas.

Classificação Opções

Congelada Sim

Não

Tipo Correção

Alteração

Implementação

Severidade

Assunto crítico

Assunto importante

Assunto de menor importância

Pedido de mudança de aplicação



7

Prioridade

Urgente

Alta

Normal

Baixa

Complexidade Alta

Normal

Baixa

Tabela 1 - Classificação das tarefas

A classificação da prioridade passa a ser irrelevante quando se tratando de tarefas que estejam com a classificação Congelada com valor de Sim.

A classificação de “Congelada” indica que a tarefa deve ser implementada (desenvolvida pelo setor de programação) em uma versão anterior (última versão liberada) à versão atual. Dessa forma, a tarefa será implementada duas vezes, sendo uma na última versão liberada (denominada de congelada) e outra na versão atual.

O “Tipo” caracteriza um indicador da origem da tarefa. Assim sendo, se a tarefa tem origem em uma requisição do cliente, e a mesma é oriunda de uma tarefa anterior, que saiu com defeito, a mesma passa a ser considerada como “Correção”. Se uma tarefa tem origem em uma requisição do cliente, sendo que a mesma não é um defeito do sistema, e tal requisição sugere para que o software se comporte com distinção em certas circunstâncias, então a tarefa passa a ser do tipo “Alteração”. No entanto, se uma requisição provinda do cliente diz respeito a um novo recurso, que até então não era contemplada pelo software, a tarefa é considerada como sendo do tipo “Implementação”.

A classificação de “Severidade” tem intuito de especificar um grau de importância para as tarefas.

A classificação de “Prioridade” objetiva indicar qual tarefa deve ser desenvolvida com maior ou menor urgência.

A “Complexidade” indica o nível de esforço que deve ser dispensado para desenvolver tal tarefa.

Para tratar as tarefas, no escopo do PDS, a empresa tem diversos recursos, principalmente, em forma de setores e de pessoas.

Abaixo são apresentados, tabularmente, os setores, e sua respectiva quantidade de pessoas, que estão incluídos no processo.

Setor/Atividade Pessoas Projetos 5

Programação 11

Testes 5

Suporte 8

Total 29

Tabela 2 - Setores pertencentes ao processo

Deste modo, pode-se verificar que os recursos setores são compostos de recursos internos, denominados pessoas.

Pode-se ainda caracterizar, conforme sugere Pancerz & Suraj (2003), que os setores realizam atividades de forma generalizada e as pessoas refinam estas atividades.



8

Neste contexto identificam-se dois níveis de fluxo para o processo de desenvolvimento de software. O primeiro nível é identificado pelo fluxo de atividades decorrente dos setores, nível este que pode ser considerado como nível generalizado, ou abrangente. O outro nível é um refinamento dos setores, que tende a demonstrar o processo em um nível mais detalhado, através das atividades das pessoas que compõem os setores.

Para dar seguimento ao trabalho, assim como, facilitar o entendimento dos dados acima coletados, será apresentado na seqüência como está estruturada a empresa com relação ao fluxo de atividades entre os recursos setores e humanos.

4.2. Fluxo de Atividades

Para possibilitar um melhor entendimento de como o processo de desenvolvimento de software da empresa está estruturado, faz-se necessário entender quais são os possíveis caminhos que uma tarefa pode percorrer na evolução do processo.

Para permitir um melhor entendimento sobre as atividades e suas dependências, foi coletado um organograma em forma de fluxo, que nos permite visualizar a ordem de execução das atividades, como segue:

Figura 3 - Organograma de atividades da empresa Desbravador

No organograma de atividades, a vida útil de uma tarefa, no processo de desenvolvimento de software, é composta por três procedimentos distintos:

a) Criação: Procedimento no qual a tarefa é efetivada no processo;

b) Processamento: Na etapa de processamento a tarefa estará sendo trabalhada pelos recursos setores e humanos;

c) Finalização: Neste procedimento a tarefa é dada por concluída, findando o ciclo do processo de desenvolvimento de software na empresa.



9

Uma tarefa pode ter origem, sendo criada, por qualquer atividade de qualquer recurso humano ou setor. Uma vez criada esta pode permanecer até sua finalização em poder do recurso criador, caso o recurso criador seja pertencente ao setor de testes ou de suporte, mas também pode ser transferida indefinidamente entre os demais recursos para o processamento da tarefa.

Para validar ou cancelar, finalizando uma tarefa, somente os setores de testes e de suporte podem fazê-lo. Para liberar uma tarefa para o cliente, mesmo que esta esteja plenamente validada pelo setor de testes, esta deve aguardar a liberação geral que foi previamente estipulada. As liberações gerais são previamente estipuladas com um intervalo de três a cinco meses, onde são reunidas todas as tarefas desenvolvidas e dessa forma é gerada uma nova versão do software Desbravador. Existe a possibilidade de uma tarefa ser desenvolvida em uma versão anterior, onde esta é definida com status de congelada. Neste caso a liberação é realizada em um intervalo que varia de um a quatro dias após ser validada pelo setor de testes.

A empresa procura, na maioria dos casos, buscar um caminho ordenado para a tarefa. Este caminho está assim estruturado:

a) Criação da tarefa pelo setor de projetos ou suporte;

b) Envio da tarefa para o setor de programação;

c) Envio da tarefa para o setor de testes;

d) Finalização da tarefa pelo testes e liberação para implantação no cliente.

Durante este caminho ordenado podem ocorrer desvios da tarefa, para que a mesma possa ter maiores esclarecimentos. Desse modo, uma tarefa que foi criada na etapa 1 pode ser transferida para a etapa 2. Na etapa 2 a tarefa pode ser devolvida para a etapa 1, para obter esclarecimentos, assim como, pode ser transferida para a etapa 3 ou 4. Da etapa 3, pode ser transferida para a etapa 2 ou para a 4. Nos casos em que a tarefa for enviada para a etapa 4, a mesma pode estar sendo negada ou implementada, sendo que, se estiver implementada, esta deve estar testada e validada.

Assim sendo, verifica-se que existem certas dependências entre as atividades, de modo que algumas atividades só ocorrerão se outras lhe derem seqüência.

Na seqüência, no tópico de modelagem, estas dependências serão representadas graficamente, de forma a esclarecer e organizar como as atividades são executadas no PDS.

4.3. Modelagem

Com base no levantamento informacional e no fluxo de atividades acima apresentados, pode-se modelar, no software Income, os setores e suas atividades, tanto de forma geral quanto de forma refinada (específica por atividade), como segue.

Na modelagem geral do PDS, abaixo apresentada (Modelagem do processo de desenvolvimento de software), pode-se perceber que uma tarefa, após uma requisição inicial provinda do cliente, pode ter duas origens. Uma tem origem pelo setor de Projetos e a outra pelo setor de Suporte. Observa-se também que, após ser criada, a mesma pode ser rejeitada, sendo finalizada na seqüência, ou pode ser transferida para o setor de programação, para que este desenvolva a tarefa. Após ser processada pelo setor de programação, a tarefa pode ser transferida como devolução, para os setores de suporte ou de projetos, ou pode transferir para o setor de testes, que terá função de validar o trabalho efetuado pela equipe de programação.



10

Neste último setor, após ser efetuada as devidas validações, a tarefa pode ser devolvida para o setor de programação, para possíveis ajustes, ou pode ser finalizada.

Figura 4 - Modelagem do processo de desenvolvimento de software

Para facilitar a visualização, as atividades, do processo modelado acima na modelagem do PDS, serão refinados em modelos separados, considerando os recursos humanos e suas principais atividades.

Abaixo os modelos refinados, das atividades dos recursos setores, são demonstrados na seguinte ordem: Suporte, Projetos, Desenvolvimento e Testes.

O primeiro modelo a ser demonstrado, como modelo de refinamento de atividades dos recursos setores, ilustra as atividades dos recursos humanos do setor suporte. O modelo demonstra que chegando ao setor de suporte, a tarefa fica inicialmente em espera, até que algum recurso humano, disponível no setor, efetue a análise sobre os dados presentes na tarefa e dê seguimento à mesma. Após analisar a tarefa, o recurso humano encarregado pela tarefa pode rejeitá-la, registrando os motivos para tal, ou aceitá-la, registrando mais especificações na tarefa para que as mesmas possam ser avaliadas pelos setores que a tarefa passar. Ao dar seqüência à tarefa, rejeitando ou transferindo para o setor de programação, o recurso humano que a estava manipulando torna-se disponível para analisar outra tarefa.



11

Figura 5 - Modelagem refinada da atividade Suporte

Da mesma forma, a modelagem de refinamento para a atividade do recurso projetos tem início com a tarefa em modo de espera, para ser avaliada por um recurso humano que esteja disponível no setor de projetos. Tão logo um recurso humano esteja liberado para analisar a tarefa, este o faz e pode rejeitá-la ou transferi-la para o setor de programação. Após liberar a tarefa o recurso humano fica disponível para analisar outra tarefa no setor de projetos.

Figura 6 - Modelagem refinada da atividade Projetos

Em ambos os modelos refinados acima (Modelagem do setor Suporte e Projetos), ao rejeitar uma tarefa, esta se torna inativa, saindo do processo de desenvolvimento de software.

Tendo seqüência para o setor de programação, a tarefa pode ter destino diretamente para um programador (recurso humano do setor de programação) ou seguir sua rota específica de processamento ficando em espera, até que o supervisor analise os dados que a acompanhem. Após analisar a tarefa, o supervisor pode dar seqüência à mesma devolvendo para o setor de projetos ou de suporte, para coletar mais informações sobre a mesma, assim como, pode também transferi-la para um programador que tenha disponibilidade para processá-la. Também o programador, caso ache conveniente, pode devolver a tarefa, que esteja em seu poder, para o setor de projetos ou de suporte, para aquisição de mais especificidades. Caso o programador tenha todas as informações necessárias para processar favoravelmente a tarefa, o mesmo o faz e prossegue transferindo a tarefa para o setor de testes.

Dando seqüência ao fluxo de atividades do processo de desenvolvimento de software, o setor de testes pode validar a tarefa, finalizando-a, ou devolve-la para o setor de programação, para que este reveja a tarefa em questão.



12

Figura 7 - Modelagem refinada da atividade Programação

Igualmente aos demais setores, ao ter entrada no setor de testes, a tarefa fica aguardando um recurso humano dos testes ficar disponível para começar a ser processada. Tão logo um recurso humano esteja liberado, a tarefa passa então para o processo de teste, sendo na seqüência finalizada ou devolvida para o setor de programação. Ao liberar a tarefa, o recurso humano fica a disposição para tratar outra tarefa.

Figura 8 - Modelagem refinada da atividade Testes

Deste modo, pôde-se visualizar que um processo de desenvolvimento de software pode ser modelado, pela ferramenta de redes de petri, em distintos níveis de refinamento.

Neste tópico foi apresentada a modelagem de um processo de desenvolvimento de software, onde suas principais atividades, representadas por setores, foram refinadas.



13

4.4. Análise Qualitativa do Cenário Atual

Com base nos modelos descritos anteriormente, o foco pode ser concentrado na análise para poder averiguar a estrutura de forma qualitativa.

Na análise qualitativa buscaremos analisar se os modelos estão corretos em sua estrutura, observando possíveis problemas que possam estar, ou na modelagem, ou no próprio processo de desenvolvimento de software da empresa. Assim sendo, aspectos relativos à vivacidade e a limitação da rede se fazem importantes nessa análise.

A modelagem do processo de desenvolvimento de software caracteriza-se como não tendo atividades desnecessárias nem mortas, sendo que por não ter ocorrência de deadlocks, nem de livelocks, tal modelo pode ser considerado como vivo (livre de bloqueios).

Avalia-se que para cada ficha que tiver entrada no processo, somente uma ficha sairá no final, sendo que quando a ficha chegar ao final, os demais lugares estarão limpos, sem ocorrência de fichas remanescentes. Verifica-se também que todas as atividades do modelo transportam a ficha do lugar de entrada para um lugar de saída. Pode-se considerar então que o modelo é fortemente modelado (soundness).

Na análise das modelagens refinadas considera-se, para todos os modelos refinados das atividades da modelagem do processo de desenvolvimento de software, que suas características qualitativas são equivalentes.

Caracterizam-se, dessa forma, como não tendo atividades desnecessárias nem mortas, sendo que por não ter ocorrência de deadlocks, nem de livelocks, tais modelos refinados podem ser classificados como vivos (livre de bloqueios).

Verifica-se que para cada ficha que tiver entrada na atividade refinada, somente uma ficha sairá no final, sendo que quando a ficha chegar ao final, os demais lugares estarão limpos, sem ocorrência de fichas remanescentes. Observa-se também que todas as atividades dos refinamentos transportam a ficha do lugar de entrada para um lugar de saída. Pode-se considerar então que o modelo é fortemente modelado (soundness).

5. Avaliação do Cenário Atual

Tendo visto os dados coletados, no estudo realizado na empresa Desbravador, pode-se realizar uma avaliação visando aprimorar o PDS.

Num primeiro momento realizar-se-á um comparativo visando classificar o processo de desenvolvimento de software real da empresa com a literatura abordada nos fundamentos deste trabalho. Neste contexto, observa-se, segundo a classificação apresentada anteriormente na tabela de “Classificação das tarefas”, que as tarefas atendidas pela empresa em seu processo podem ser do tipo: Correção, Alteração e Implementação.

Com tais tipos de classificação sendo tratadas pelo processo de desenvolvimento de software, pode-se também verificar a natureza para cada tipo de classificação, sendo:

a) Correção: Tem origem em uma requisição do cliente, sendo que a mesma é oriunda de uma tarefa anterior, que saiu com defeito;

b) Alteração: Tem origem em uma requisição do cliente, sendo que a mesma não é um defeito do sistema, e tal requisição sugere para que o software se comporte com distinção em certas circunstâncias;



14

c) Implementação: Provinda de uma requisição do cliente que diz respeito a um novo recurso, que até então não era contemplada pelo software.

Através destas classificações, observa-se que o software da empresa está constantemente evoluindo, tanto corretiva (Correções em geral) quanto evolutivamente (Alterações e Implementações em geral). Caracteriza-se então que o software tem um processo evolutivo cíclico.

Nesse sentido, pode-se verificar, segundo a bibliografia de Pressman (1997), que o processo real da empresa se equipara ao modelo evolucionário incremental dos modelos de processos de desenvolvimento de software. Tal modelo pode ser assim equiparado porque após passar pelo processo de desenvolvimento da empresa, um incremento à versão é gerado através da liberação.

Não obstante a tal classificação como evolucionário incremental, faz-se necessário avaliar este processo de forma a verificar possíveis falhas no mesmo.

Dessa forma, efetuando um comparativo que visa cruzar as classificações das tarefas com as redes de petri modeladas sobre o PDS da empresa, observa-se que não existe nenhum tratamento diferenciado para as tarefas que são classificadas distintamente. Assim sendo, verifica-se que uma tarefa com uma dada configuração específica não está sendo distintamente processada sobre o PDS demonstrado na modelagem geral nem nas modelagens refinadas das atividades.

A falta de um tratamento diferenciado, em tais modelos, acaba por acarretar na performance do processo como um todo, ou seja, tarefas que poderiam ser processadas com maior agilidade, ou poderiam ser retardadas no processo, acabam sendo processadas sem distinção.

A qualidade do serviço acaba por ser impactada igualmente, pois as solicitações que poderiam ser atendidas com maior urgência acabam por não ter esse diferencial.

Desta forma, podemos verificar que a falta de tratamento para as tarefas com distintas classificações pode ser considerada como um problema na estrutura funcional das atividades.

Assim sendo, verificamos que apesar de estar parcialmente controlado e estruturado, o PDS da empresa Desbravador contém gargalos que podem fazer a diferença na performance do processo como um todo.

6. Conclusão

Observamos neste trabalho que, efetuando um estudo sobre um processo de desenvolvimento de software de uma empresa real, o formalismo de redes de petri pôde ser utilizado para modelar de forma geral e refinada o PDS. Dessa forma, ao efetuarmos a modelagem e a análise sobre o processo, foi possível avaliar o cenário atual da empresa analisada.

Aspectos relacionados à falta de tratamento diferenciado às tarefas com distintas classificações foram relacionadas como sendo possíveis problemas ao PDS, impactando na performance e na qualidade do PDS.

Apesar de este trabalho estar centrado na modelagem e na análise qualitativa de processos de desenvolvimento de software, este pode ser estendido, futuramente, para análises quantitativas e para proposições de melhorias.



15

Outros aspectos, que podem ser alvos de trabalhos futuros, dizem respeito a aspectos gerenciais que interligam o PDS com questões financeiras e/ou estratégicas, através de visões empresariais.

Referências

AALST, W. M. P. V. D.; HEE, K. M. V. & HOUBEN. G. J.; Modelling and Analysing

Workflow using a Petri-net based approach. Proceedings of Second Workshop on Computer Supported Cooperative Work, Petri nets related formalisms. p. 31-50, 1994.

AALST, W. M. P. The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers; Vol. 8, p. 21-66, 1998.

BEZERRA, C. A. A qualidade do processo de desenvolvimento de software a partir da

gestão de projetos: um estudo de caso. Sociedade Brasileira de Computação. 2004.

DAYAL, U; HSU, M & LADIN, R. Business Process Coordination: State of the Art, Trends

and Open Issues, Proceedings of VLBD. Roma, 2001.

KANTORSKI, G. Z. & KROTH, M. L. Controle de Métricas no Processo de

Desenvolvimento de Software através de uma Ferramenta de Workflow. I Workshop de Computação - WORKCOMP-SUL, 2004, Florianópolis. Anais do I WORKCOMP-SUL, 2004.

MURATA, T. Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE: Vol. 77, n. 4, 1989.

PÁDUA, S. I. D.; SILVA, A. R. Y.; PORTO, A. J. V. & INAMUSO, R. Y. O Potencial

das Redes de Petri em Modelagem e Análise de Processos de Negócio. Gestão e Produção: Vol. 11. p.109-119. 2004.

PANCERZ, K & SURAJ, Z. Synthesis of Petri Net Models: A Rough Set Approach. Fundamenta Informaticae; Vol. 55 Issue 2, p149, 17p, 2003.

PARREIRAS, F. S. & OLIVEIRA, G. S. Análise comparativa de processos de

desenvolvimento de software sob a luz da gestão do conhecimento: um estudo de caso de

empresas mineiras. SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE. 2004, Brasília. Anais. Acessado em <http://www.fernando.Parreiras. com.br/publicacoes/WGC_Parreiras04.pdf>.

PRESSMAN, R. S. Software Engeneering, A Practitioner’s Approach – Fourth ed. The McGraw-Hill Companies. 1997.

REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 2ª ed. Rio de Janeiro: Brasport. 2002.

TAMAKI, P. A. O. & HIRAMA, K. Melhoria de Processos de Desenvolvimento de

Software Aplicando Process Patterns. InfoComp: Journal of Computer Science. Vol. 6, n. 1, 2007.

modelagem de processos de negÓcio aplicado ao processo de desenvolvimento de … · 2016-08-11 ·...

Documents