Business process modeling como ferramenta de auxílio às práticas de engenharia de requisitos ana Carolina Oran Fonseca e Toledo



Baixar 76.84 Kb.
Encontro23.07.2016
Tamanho76.84 Kb.


BUSINESS PROCESS MODELING COMO FERRAMENTA DE AUXÍLIO ÀS PRÁTICAS DE ENGENHARIA DE REQUISITOS

Ana Carolina Oran Fonseca e Toledo

Centro de Informática – Universidade Federal de Pernambuco (UFPE)

Caixa Postal 7851 – 50.732-970 - Recife - PE – Brasil

{acoft@cin.ufpe.br}

Abstract. This paper analyzes the use of Business Process Modeling as a tool to support the practice of requirements engineering. A literature review on Requirements Engineering (RE) and Business Process Management (BPM) was made. This work describes the main concepts, tools and limitations of the requirements engineering, in addition to discussing the differences between Business Process Management System (BPMS) and Business Process Modeling Notation (BPMN). It describes the process of requirements elicitation and analysis using the concepts of BPM tools, such as: BPMS and BPMN. Besides, it compares three case studies and shows the advantages of using BPMN in requirements engineering.

Resumo. Este artigo faz uma análise da utilização de Business Process Modeling como ferramenta de auxílio às práticas de engenharia de requisitos. É realizada uma revisão bibliográfica sobre Engenharia de Requisitos (ER) e Business Process Management (BPM). Apresenta os principais conceitos, ferramentas e limitações da engenharia de requisitos, além de discutir as nuances dos Business Process Management System (BPMS) e Business Process Modeling Notation (BPMN). Descreve o processo de elicitação e análise de requisitos utilizando conceitos de ferramentas do BPM, tais como: BPMS e BPMN. Além disso, compara três estudos de caso, procurando evidenciar as vantagens da utilização do BPMN na engenharia de requisitos.

1. Introdução


Cotidianamente, a informatização vem invadindo as mais diversas áreas da atividade humana, chegando, em muitas situações, a atingir o patamar da necessidade básica. Em função dessa realidade, muitas empresas de desenvolvimento de software estão cada vez mais tendo a responsabilidade de colocar à disposição da sociedade software de qualidade, que não apenas atenda às necessidades de seus usuários, mas que supere as expectativas dos mesmos.

No entanto, mesmo diante desse contexto, muitos softwares ainda continuam sendo desenvolvidos sem uma visão macro do processo a ser automatizado. Esse tipo de conduta leva ao desenvolvimento de um produto muitas vezes pouco aderente à estratégia de negócio da empresa cliente, fazendo com que a relação custo/benefício do software desenvolvido seja pouco atrativa.

Na tentativa de melhorar os efeitos desta situação, tem-se utilizado os conceitos e ferramentas de software, como o Business Process Modeling (BPM), como uma forma de apoiar às práticas de engenharia de requisitos.

Para tanto, este artigo foi estruturado em seções a partir de uma revisão bibliográfica sobre Engenharia de Requisitos, e Business Process Management (BPM) em que contextualiza e forma a base desta pesquisa, apresentando os principais conceitos, ferramentas e limitações da engenharia de requisitos, além de discutir as nuances dos Business Process Management System (BPMS) e Business Process Modeling Notation (BPMN). Descreve-se também o processo de elicitação e análise de requisitos utilizando conceitos de ferramentas do BPM, tais como: BPMS e BPMN.

Concluí-se a pesquisa, apresentando as principais lições aprendidas através da análise dos trabalhos de engenharia de requisitos que utilizaram os conceitos e ferramentas do BPM como auxiliar na elicitação e validações dos requisitos pelos analistas de sistemas e seus clientes ou usuários.

Assim, este artigo se justifica pelo estudo feito sobre a utilização de Business Process Modeling como ferramenta de auxílio às práticas de engenharia de requisitos, e da importância que esse sistema tem na redução do grau de intensidade dos retrabalhos gerados pelos pontos-cegos existentes no levantamento, análise e projeto de sistemas de informação.


2 Engenharia de requisitos


    Nesta seção serão apresentados os conceitos referentes à engenharia de requisitos, bem como seu processo, problemas e soluções propostas por vários pesquisadores.

    1. Conceitos

De acordo com Sommerville (2003), os engenheiros de software acreditam que compreender com exatidão o que o sistema deve fazer, na maioria das vezes, pode ser imensamente complexo, especialmente quando o sistema for novo. Dessa forma, houve a necessidade de desenvolver técnicas para tentar aumentar a precisão e o entendimento das necessidades dos clientes e, principalmente, dos usuários.

Pressman (2002) corrobora com esta visão, afirmando que a engenharia de requisitos surgiu para ajudar os engenheiros de software a compreender melhor o problema que irão trabalhar para resolver. Além disso, explica que tal compreensão é subsidiada por um conjunto de tarefas que levam a um entendimento sobre o impacto do software no negócio do cliente.

De modo complementar, Sommerville (2003) explica que a engenharia de requisitos veio para facilitar o entendimento dos requisitos, que nada mais é que a descrição das funções e das restrições do sistema. Neste sentido, Pfleeger (2004) conceitua requisitos como: as características do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos.

Paula Filho (2001) comenta que a engenharia de requisitos pode ser definida como a disciplina que reúne um conjunto de técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto de software. E as atividades de requisitos abrangem as atividades que visam obter o enunciado completo, claro e preciso dos requisitos de um produto de software.

A engenharia de requisitos para Thayer (1997 apud BELGAMO; MARTINS, 2000), é a primeira etapa dentro de todo o processo da engenharia de software, a qual estuda como coletar, entender, armazenar, verificar e gerenciar os requisitos. Thayer elucida que a principal preocupação na engenharia de requisitos é entender quais são os reais requisitos do sistema, bem como a documentação dos mesmos.

Magela (2006) defende que a engenharia de requisitos é de extrema importância, pois, projetar e construir um programa de computador elegante que resolva o problema errado não serve às necessidades de ninguém. Logo, é importante entender o que o cliente deseja antes de começar a projetar e construir um software.



    1. Processo da engenharia de requisitos

A engenharia de requisitos nada mais é do que um processo para ajudar os engenheiros de software a compreender o que o cliente espera de um sistema. O termo análise de requisitos ou engenharia de requisitos, segundo Stokes (2003 apud DA SILVA; BONIN; PALUDO, 2006), refere-se a uma coleção dos processos de extração, especificação, verificação e validação. Já para Sommerville (2003) a engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições de um sistema. Tal processo é realizado através das tarefas de elicitação, análise e negociação, documentação e validação dos requisitos, conforme Figura 1.



Figura 1 – Fases da engenharia de requisitos

Na Figura 1 são apresentas quatro (4) fases do processo de engenharia de requisitos. Na primeira fase, denominada elicitação de requisitos, os engenheiros de software descobrem através de consultas com o cliente o que ele deseja do sistema. Na segunda fase, denominada análise e negociação de requisitos, os requisitos são analisados e os conflitos resolvidos através de negociação com o cliente. Posteriormente, na terceira fase, produz-se a documentação de requisitos. Por fim, na quarta e última fase, denominada validação de requisitos, realiza-se a checagem da consistência e completude do documento de requisitos.

A partir de uma linguagem mais gerencial, Thayer (1997 apud BELGAMO; MARTINS, 2000) define as fases da engenharia de requisitos como: elicitação, análise, especificação, verificação e gerenciamento. O detalhamento e descrição de cada fase são mostrados no Quadro 1.

Quadro 1 – Fases da engenharia de requisitos

Fases

Descrição

1 Elicitação de requisitos

É o processo pelo o qual clientes e usuários são questionados por um desenvolvedor para falarem “o quê” o software deve fazer (ou seja, os requisitos).

2 Análise de requisitos

É o processo onde são analisadas as necessidades dos clientes e usuários para se chegar na definição dos requisitos de software.

3 Especificação de requisitos

É o processo de criação de um documento no qual estão definidos todos os requisitos analisados.

4 Verificação de requisitos

É o processo que busca assegurar que a especificação de requisitos de software está em concordância com os requisitos elicitados e analisados nas fases anteriores, ou seja, estão de acordo com o desejo do cliente.

5Gerenciamento de requisitos

É o planejamento e controle da atividade de elicitação, especificação, análise e verificação dos requisitos.

Apesar dos autores Stokes (2003 apud DA SILVA; BONIN; PALUDO, 2006) e Sommerville (2003) apresentarem as fases da engenharia de requisitos com quantidades e termos diferentes, a descrição de cada fase leva a crer que todos os autores corroboram com a visão de Thayer (1997 apud BELGAMO; MARTINS, 2000). Destaca-se, entretanto, que o uso inadequado das técnicas, documentos e ferramentas da engenharia de requisitos tem gerado vários problemas, os quais são capazes de afetar a qualidade do produto final de um projeto de software.



    1. Problemas inerentes à engenharia de requisitos

Para Martins (2001) os problemas na elicitação de requisitos podem ser categorizados em três grupos, os quais são: problemas de escopo (o limite do problema não é bem definido), problemas de entendimento (como ambigüidade na especificação dos requisitos, analistas com pouco conhecimento sobre o domínio do problema, dentre outros) e problemas de volatilidade (requisitos que evoluem ao longo do tempo em conseqüência de maior clareza do usuário em relação ao sistema).

Segundo Van Lamsweerde (2000), em função da persistência destes problemas, a engenharia de requisitos atrai muito interesse e investimento. O autor diz que para melhorar a qualidade dos requisitos, este é um dos caminhos para garantir o sucesso dos projetos, porém é um objetivo difícil de alcançar. Nestes termos, Van o autor elenca algumas razões porque o processo de requisitos é tão complexo, dentre quais se pode mencionar o fato do escopo do projeto ser regularmente amplo, variando de um de organizações humanas ou leis físicas para um mundo de artefatos técnicos que devem estar integrados. Além disso, o autor também ressalta que o sistema alvo não é só uma peça de software, mas está embutido em um ambiente que deve ser analisado e considerado.


Em função dessas características que tornam a elicitação dos requisitos um processo tão complexo, Veríssimo (2007) ressalta que aliado ao levantamento de requisitos, deve existir um mapeamento dos processos, pois isto é de vital importância para a melhoria dos resultados obtidos pelo levantamento de requisitos.

Nesta mesma concepção, Takai (2006) defende que o entendimento sobre onde os sistemas serão implantados, quem irá utilizá-los, como serão integrados aos sistemas existentes e o quê irá automatizar é a chave para o sucesso dos sistemas de informações.

De modo complementar, Shishkovo (2002 apud TEIXEIRA; RAMOS; ZARU, 2004) explica que os sistemas de informação são desenvolvidos para apoiar um negócio ou parte dele. Por isso, surgiu a abordagem chamada Business Process Management (BPM), a qual se baseia no levantamento e análise dos processos de negócio ao qual o sistema deve atender antes de se começar o projeto do sistema.

Neste sentido, Teixeira; Ramos; Zaru (2004) afirmam que a modelagem de negócio é uma técnica que veio para auxiliar os analistas, na coleta exata de requisitos de uma empresa, com o objetivo de suprir todas as necessidades da mesma.



    2.4 Business Process Management (BPM)

Enquanto que Garimella (2008) afirma que o Business Process Management (BPM) não é nenhuma novidade, Pereira (2008) defende que o BPM é um conceito relativamente novo. Entretanto, ambos concordam que o BPM vem ganhando cada vez mais espaço no ambiente corporativo, para se tornar mais uma tendência de gestão empresarial e de tecnologia da década.

Business Process Management (BPM), segundo Pereira (2008), refere-se a uma nova forma de gerir os negócios da empresa, por meio de um conjunto de práticas de gerenciamento de processos que os tornam mais eficazes, eficientes e alinhados com as estratégias e a cadeia de valor das organizações. De modo similar, Garimella (2008) conceitua o BPM como um conjunto de métodos, ferramentas e tecnologias usadas para projetar, implementar, analisar, realizar controle operacional e controle de processos de negócio.

Para Furlan (2008), BPM é o enfoque disciplinado para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio, automatizados ou não, para alcançar resultados consistentes e alinhados com os objetivos estratégicos da organização.

Na concepção de Teixeira; Ramos; Zaru (2004) os objetivos da Modelagem de Negócios podem ser resumidos em: a) compreender a estrutura e a dinâmica da organização na qual um sistema de informação será implantado; b) compreender os principais problemas atuais da organização e identificar melhorias potenciais; c) garantir que clientes, usuários e desenvolvedores tenham um entendimento comum sobre a organização; d) apoiar na identificação dos requisitos do sistema que irá apoiar a organização.



2.4.2 Soluções e padrões inerentes ao BPM

Pereira (2008) preconiza que as soluções tecnológicas disponibilizadas pela TI nos últimos anos criaram a base necessária para a efetividade na utilização do BPM. Dentre as diversas soluções, o autor cita as seguintes: Business Process Modeling Notation (BPMN), Business Process Management System (BPMS), Business Process Execution Language (BPEL) e Service Oriented Architecture (SOA).



2.4.2.1 Business Process Modeling Notation (BPMN)

Para Bortolini (2006), BPMN é uma especificação para modelagem visual de processos. O objetivo do BPMN é prover uma interface simples e poderosa que possa ser tanto utilizada por analistas de negócios quanto por analistas de sistemas, funcionando como um contrato entre as partes. Pereira (2008) explica que a simbologia utilizada pelo BPMN permite a especificação dos fluxos num nível de detalhamento próximo da complexidade de um ambiente real. Desta forma, facilita a comunicação entre analistas e usuários, bem como as análises necessárias para a preparação da versão inicial do processo ou melhorias a serem realizadas.

Recker (2008) realizou uma pesquisa de campo para determinar onde e por quem o BPMN está sendo utilizado. A Europa, América do Norte e Oceania, em relação à distribuição geográfica do uso de BMPN, responderam ¾ de todas as respostas. Em torno de 60% dos respondentes trabalham para empresas privadas, e 40% trabalham em organizações de grande porte com mais de 1000 empregados.

Em relação ao objetivo ou ramo de negócio mais utilizado pelo BPMN, Recker (2008) verificou que 51% dos respondentes iniciaram o uso do BPMN para melhorar seu negócio (documentação do processo, melhoria, análise de negócio, comunicação com stakeholders etc.) enquanto que 49% usaram o BPMN para propósitos mais técnicos (simulação de processo, análise de serviços e engenharia relacionada ao fluxo do trabalho).

White (2005) explica que um evento é algo que acontece durante o curso do processo de negócio. Esses eventos afetam o fluxo do processo e geralmente tem um gatilho ou resultado associado. Desta forma, tais eventos podem iniciar-se, interromper ou finalizar o fluxo de um processo.

Por outro lado Bitencourt (2008) divide os símbolos dos eventos intermediários em itens de captura e acionamento. Neste sentido, explica que enquanto, os itens de captura são aqueles responsáveis por aguardar a recepção de uma mensagem, os itens de acionamento são aqueles responsáveis por enviar uma mensagem e continuar o processo.

Quanto aos demais padrões existentes, Bortolini (2006) advoga que o BPMN parece ser a única unanimidade: “é apoiado por todos os grandes players e não possui nenhuma outra especificação concorrente”. Além disso, destaca que na prática, o BPMN consiste em uma série de padrões de representação gráfica e de lógica no desenho de processos. Por isso, existem diversas ferramentas de desenhos de fluxos, conhecidos como BPMS, que incorporaram o padrão BPMN e, devido a sua simplicidade, tem todas as condições de no futuro ser utilizado pelos usuários finais.

2.4.2.2Business Process Management System (BPMS)

Quanto ao Business Process Management System (BPMS), Oliveira (2007) destaca que nos dois últimos anos, uma proposta que vem ganhando força é o desenvolvimento de sistemas de informação segundo uma metodologia de desenho e implementação, fundamentada no conceito de processos. Estes sistemas altamente flexíveis estão sendo chamados de BPMS, por criarem o arcabouço de TI necessário para suportar a aplicação do conceito de BPM na organização.

De acordo com Pereira (2008), o BPMS é uma categoria de software usada para apoiar a implantação e a execução dos processos sob a ótica do BPM. O BPMS permite realizar o mapeamento dos processos ponta-a-ponta, desenho dos fluxos e formulários eletrônicos, definição de regras de negócio, monitoramento em tempo real das atividades por meio de métricas preestabelecidas e alertas para a gestão. BPMS pode ser implantado numa organização, interagindo com aplicações (software) existentes ou independentes destas.

Segundo Sancovschi (1999, apud OLIVEIRA, 2007), a fase do BPMS corresponderia à terceira onda do BPM. Para ele a primeira seria a Administração Científica, no qual os processos eram implícitos nas práticas de trabalho e não eram automatizados. A segunda seria a reengenharia, em que os processos eram melhorados manualmente e posteriormente automatizados. A terceira fase seria o uso de BPMS, os quais permitem realizar simulações e prospecções do processo de negócio, seja ele o processo atual (AS-IS) ou o processo proposto (TO-BE). Nesta última fase, os processos são o foco centrais do desenvolvimento dos novos sistemas, permitindo que as organizações se tornem mais ágeis e possam ser continuamente otimizadas.

No intuito de apresentar os principais aplicativos (BPMS) utilizados, Recker (2008) realizou uma pesquisa com 590 usuários de BPM distribuídos pelo mundo todo, e compilou uma lista com as suas respectivas freqüências.

A diferença entre a freqüência do primeiro lugar – Microsoft Visio (18,2%) – para o segundo lugar – itp-Commerce Process Modeler (7,8%) – é substancial. Entretanto, Recker (2008) ressalta que o Microsoft Visio não é uma ferramenta BPMS, pois é um ótimo editor gráfico, mas não possui todas as funcionalidades requeridas para ser um BPMS completo. Neste caso, Recker (2008) postula que existem outras opções disponíveis, como é o caso da solução do Itp-Commerce que é um plug-in capaz de estender a capacidade de modelagem do Microsoft Visio com uma máquina de simulação baseada no BPMN, atributos adicionais e opções de análises.

Por fim, Recker (2008) destaca que os fornecedores SparxSystems, Telelogic, Intalio, IDS Scheer and Casewise oferecem soluções BPM que vão muito além das simples capacidades de modelagem de processos.

Pereira (2007) explicita que na visão de Ghalimi, CEO da Intalio, um BPMS completo teria os seguintes módulos ou funcionalidades mínimas para um produto poder se classificar como BPMS: 1 Ferramenta de modelagem e desenho do processo; 2 Engenho de execução do processo; 3 Orquestração de web services; 4 Interface de workflow para usuários.

Para ter um produto mais completo, seria necessário: 5 Suporte para regras de negócio complexas; 6 Business Activity Monitoring (BAM); 7 Controle de versão dos documentos anexados a instâncias do processo.

E para um produto completo, seria acrescentado: 8 Enterprise Service Bus (ESB); 9 Repositório de metadados; 10 Uma suite de business intelligence.

No que tange às ferramentas consideradas BPMS, De La Vara; Sanches (2008); Oliveira (2007) apontam as principais ferramentas, demonstrando os pontos fortes e pontos fracos de cada uma. Por fim destacam as ferramentas ARIS e B-SCP como as mais adequadas para o uso de BPM.

3. ESTADO DA ARTE DO BPM NA ENGENHARIA DE REQUISITOS


A engenharia de requisitos pode ser dividida em cinco partes: elicitação de requisitos; análise de requisitos; especificação de requisitos; verificação de requisitos e gerenciamento de requisitos. Porém, alguns autores (MAGELA, 2006; TAKAI, 2006) defendem a aplicação da análise de negócio antes da elicitação e análise de requisitos, pois tal prática visa garantir o alinhamento do software a ser desenvolvido com as estratégicas e metas do negócio da organização cliente.

Apesar de existir o padrão de modelagem de negócio BPMN, e diversos sistemas que suportam tal modelagem, muitos analistas de negócio e analistas de sistemas estão buscando diferenciais competitivos na forma como tais recursos são utilizados.



    1. Engenharia de requisitos suportada por uma abordagem baseada em metas

A primeira forma de elicitação foi desenvolvida por González e Díaz (2007), a qual é baseada na idéia que a estratégia do negócio deve direcionar as decisões da organização e, consequentemente as decisões sobre a infra-estrutura de tecnologia da informação (TI). Assim, a fase de elicitação possui três etapas subseqüentes: modelagem da estratégia do negócio (business strategy modeling), modelagem da infra-estrutura do negócio (business infrastructure modeling) e infra-estrutura de TI (IT infrastructure).

González e Dias (2007) destacam que inicialmente a estratégia do negócio é definida com base na missão da empresa, e as metas estratégicas que a suportam. Depois, a infra-estrutura de negócio é representada através dos seguintes modelos: mapa do processo, modelo dos papéis, modelo dos recursos e processo do negócio. Finalmente, as metas do processo de negócio são extraídas e analisadas, o sistema de metas é definido e os requisitos são derivados deles. A saída desta fase é um conjunto de casos de uso que o sistema deverá atender para alcançar as necessidades operacionais da empresa.

Nesta abordagem, a primeira etapa do processo de elicitação de requisitos refere-se à modelagem da estratégia do negócio.

Uma vez identificados os processos, o próximo passo será detalhá-los, utilizando o BPMN e o padrão conhecido como swin lanes. O BPMN fornece um padrão adequado para preencher as lacunas existentes entre o modelo de negócio e sua implementação.

A partir da definição do modelo do processo e modelo dos recursos, iniciam-se as etapas necessárias para chegar até os diagramas de caso de uso.

Para conseguir elicitar os requisitos (casos de uso) se fazem necessário elaborar os seguintes modelos: árvore das metas do processo do negócio, etiquetar cada meta, metas do sistema de informação e, por fim, o diagrama de caso de uso.

González e Díaz (2007) ressaltam que o conceito de alinhamento com as metas da empresa está sendo largamente utilizado na engenharia de requisitos. Explicam ainda que, uma meta é um objetivo ou um estado que deve ser alcançado e sua definição faz referência a um conjunto de propriedades que devem ser garantidas.

Depois de elaborar a árvore das metas do processo do negócio, o próximo passo é etiquetar as metas (processos) com as seguintes definições: “A” quando o sistema suporta a meta ou tarefa e, portanto, pode ser automatizado. As etiquetas “C” indicam que uma atividade realizada pelo próprio sistema, sem a intervenção do usuário. As etiquetas “M” indicam que tal tarefa deverá ser realizada manualmente pelo usuário, ou seja, não pode ser automatizada. Se um processo já foi etiquetado com “C”, suas atividades ou subprocessos poderão ser etiquetados com “IS” que indica que serão realizados pelo sistema automaticamente.

Neste processo não será mais necessária uma secretária, pois todas as atividades realizadas por ela – “creating temporary packing list”, “creating definitive packing list”, “select order”, “prioritize delivery note” – foram etiquetadas como “C – Ceased Goal” e, portanto, serão realizadas automaticamente pelo sistema a ser desenvolvido.

Com base na árvore das metas do processo do negócio etiquetada é possível determinar os casos de uso do sistema. A análise dos processos e tarefas determinará os atores dos casos de uso. Por exemplo, se um caso de uso foi derivado de uma tarefa etiquetada como “IS”, então um ator “clock” – neste caso significa o próprio sistema – será responsável por executar tal tarefa, a qual requer uma periodicidade exata que pode ser no momento da solicitação ou de 1 em 1 hora etc. Então, de acordo com a análise e cada tarefa, o analista determinará o restante dos atores do sistema.

Como foi mostrado nesta seção, o modelo de requisitos derivou dos modelos da organização traduzidos em metas e processos estratégicos. A elicitação dos requisitos utilizou o BPM para auxiliar em sua realização e tentar aumentar a precisão desta etapa. Neste sentido, González e Díaz (2007) defendem que as preocupações da empresa devem ser levadas em consideração e a engenharia de requisitos deve possuir novas formas de elicitação.


    1. Engenharia de requisitos suportada por uma abordagem de reengenharia de processo

Oliveira (2007) apresenta uma metodologia de elicitação de requisitos que mescla o método RUP com a metodologia ARIS. Além disso, utiliza as ferramentas de melhoria de processos MASP e 5W1H.

A metodologia sugerida possui três etapas macro, onde preliminarmente deverá ser realizado um trabalho de conscientização com todos os envolvidos para, logo em seguida, serem levantadas às informações para a definição do processo atual através de entrevistas, análise documental e observação direta. Por fim, deve ser realizado um trabalho de análise crítica no processo levantado para geração de uma proposta de melhoria.

A metodologia segue a abordagem top-down, iniciando no levantamento dos processos macros (competências da organização e seus núcleos de produtos) para elaboração de uma modelagem mais detalhada, sendo esta validada pelos usuários-chaves do processo.

A primeira fase retrata a preparação do ambiente. Nesta fase o analista de negócio deve escolher ou definir o patrocinador (sponsor), informar todos os envolvidos (stakeholders), definir as metas e o sistema. Oliveira (2007) apresenta outras questões que devem ser determinadas nesta fase: local de realização das entrevistas, sala dos analistas da modelagem de negócio (infra-estrutura, software, hardware etc.), número de pessoas entrevistas por vez e o número de entrevistadores.

A segunda fase consiste na descrição ou modelagem do processo de negócio no seu status quo. Para realizar esta fase com sucesso, Oliveira (2007) sugere a realização das seguintes etapas: Identificar e detalhar os processos As-Is, descrever os processos As-Is identificados, revisar artefatos As-Is gerados e por fim homologar artefatos As-Is revisados.

O resultado final da fase de descrição ou modelagem do processo de negócio é apresentado nas Figuras 2 e 3 segundo Oliveira (2007).





Figura 2 – Fluxo Macro de Realizar e Controlar no Laboratório Elétrica As-Is



Figura 3 – Sub-fluxo do processo Realizar e Controlar no Laboratório Elétrica As-Is

Uma vez definido o processo da organização (AS-IS), a próxima etapa consiste em identificar os pontos a serem otimizados, elaborando um novo processo, chamado de TO-BE. Este trabalho é conhecido como reegenharia do processo, o qual possui 04 etapas mostradas na Figura 4 conforme Oliveira (2007).





Figura 4 – Fluxo de Atividades do Processo Aperfeiçoar Processo de Negócio To-Be

A primeira etapa consiste na identificação e detalhamento dos processos a serem otimizados (TO-BE). Esta etapa tem como objetivo orientar a organização na decisão a respeito da melhor abordagem a ser seguida a partir da identificação dos processos na etapa As-Is.

Oliveira (2007) defende que o ponto chave quanto à decisão da abordagem é a identificação de passos ou aspectos chaves que afetem a cadeia de valor como um todo. A identificação desses passos ou aspectos pode ser feita através do entendimento dos processos na etapa As-Is e seus relacionamentos.

Além disso, para suportar a identificação dos processos a serem melhorados, realiza-se um estudo de recursos. Este estudo é necessário para que se possa analisar o percentual de utilização dos profissionais e dos recursos envolvidos no processo, de acordo com o tempo gasto em suas atividades. Pode-se, com isso, avaliar a possibilidade de remanejamento de atividades de um profissional que se encontra sobrecarregado ou redimensionar os tempos de cada atividade dentro do processo.

A próxima análise a ser realizada é sobre o tempo médio das atividades envolvidas no processo. A simulação representa a realização de atividades calculando o tempo necessário para sua realização. Para simular a execução de uma atividade, é necessário realizar uma previsão de quanto tempo o desenvolvedor leva, em média, para realizá-la. O Quadro 2 apresenta os resultados desta simulação segundo Oliveira (2007).

Quadro 2 – Tempo médio de cada atividade

As informações necessárias para os cálculos dos resultados contidos no Quadro 2 foram obtidas através das entrevistas com os profissionais da parte técnica e gerencial do processo e da coleta de dados históricos nos registros de recebimento de equipamentos e Aquisição de Materiais e Serviços (AMS) através do sistema em Lotus Notes.

Através do Quadro 2, pode-se perceber que as atividades mais longas do processo são a “21 – Aprovar Solicitação de Compras”, seguida pela atividade de “09 – Elaboração de Máscaras do Relatório de Calibração”. A primeira requer mais tempo porque trata da atividade de negociação da compra do serviço junto ao laboratório credenciado para a realização da calibração dos equipamentos padrão do Laboratório.

A próxima análise é o estudo dos gargalos do processo. Com base nesta abordagem, Oliveira (2007) identificou que o processo de aprovação da solicitação de compra é fundamental para que sejam observadas informações como: quantidade a ser comprada, descrição do material, valor estimado da compra, fornecedor escolhido, análise da proposta enviada pelo fornecedor.

Sem esse processo de aprovação, o documento ficará aguardando até a diretoria executiva manifestar a sua decisão, se este permanecer no mesmo estado sem ser aprovado, ocasionará no atraso do processo e este não poderá ser concluído, inviabilizando assim a realização das atividades do laboratório.

Nesta etapa, se identifica aspectos como: gargalos em determinados passos, redundâncias entre processos, ociosidade na execução de determinadas atividades, qualidade e objetividade do fluxo de atividades dentre outros elementos capazes de afetar a performance do modelo do processo na atual organização em que foram mapeados na etapa As-Is. O objetivo desse mapeamento é de direcionar a abordagem mais adequada para as necessidades da organização.

Após a identificação e detalhamento dos processos que apresentam algum tipo de problema relacionado ao alcance das metas e estratégias da organização, realiza-se a reengenharia. Oliveira (2007) destaca que um aspecto importante que não deve ser deixado de lado é não se perder a essência do negócio durante o processo de reestruturação. Em outras palavras, o que deve ocorrer em um determinado processo não deve ser esquecido nem alterado, mesmo que, por exemplo, pessoas e recursos passem por algumas modificações, pois a essência do negócio não pode ser perdida.

Depois da elaboração do novo processo, TO-BE, os analistas seguem para a realização das seguintes etapas: revisar artefatos TO-BE gerados e homologar artefatos TO-BE revisados. Assim, após o aceite da reengenharia do processo, identificam-se os casos de uso e os atores do sistema, finalizando assim, a fase de elicitação de requisitos.



    1. Uma comparação entre o BPMN dos processos de engenharia de requisitos

O trabalho de Santos (2007) estabelece uma comparação entre o BPMN dos processos da engenharia de requisitos sugeridos pelo IEEE e da engenharia de requisitos empresarial. O autor acredita que a inexistência ou inobservância de atividades fundamentais de Engenharia de Requisitos em um projeto em relação às recomendações propostas pelo IEEE Std 1220, mostra fragilidades e riscos que podem ocasionar prejuízos técnicos e financeiros a um projeto e a organização.

Desta forma, Santos (2007) compara os BPDs (Business Process Diagram) derivados do proposto pelo IEEE Std 1220, e os BPDs derivados do modelo de negócios da Empresa, para analisar a inexistência ou inobservância de atividades.

Santos (2007) em relação às atividades, afirma que não foi observada nenhuma evidência de sua existência na fase de Análise de Requisitos.

Observou-se que sete processos são inexistentes ou não observados. São eles: 1. Definir medidas de efetividade; 2. Definir limites do sistema; 3. Definir utilização do ambiente; 4. Definir modo de operação; 5. Definir medidas técnicas de performance; 6. Definir características de design; 7. Definir fatores humanos.

Segundo Santos (2007), os processos destacados foram divididos em dois subgrupos para facilitar a análise: Subgrupo dos processos não observados na fase de análise de requisitos e subgrupo dos processos não existentes dentro do processo de Engenharia de Sistemas da Empresa.

Com o auxílio do padrão BPMN, foi possível realizar uma comparação entre o BPMN dos processos da engenharia de requisitos sugeridos pelo IEEE e da engenharia de requisitos empresarial. Através da análise do Business Process Diagram identificou-se a inexistência de algumas atividades na Análise de Requisitos da Organização, em relação às atividades propostas pelo padrão IEEE STD 1220.



    1. Comparação

O primeiro trabalho analisado foi o de González e Diaz (2007), o qual realizou a fase de elicitação de requisitos em três etapas subseqüentes: modelagem da estratégia do negócio (business strategy modeling), modelagem da infra-estrutura do negócio (business infrastructure modeling) e infra-estrutura de TI (IT infrastructure). Para determinar o processo TO-BE, González e Diaz (2007) realizam uma análise baseada no etiquetamento de cada processo e tarefa, os quais serão substituídos por processos automatizados ou eliminados devido ao término de sua necessidade.

O segundo trabalho analisado foi o de Oliveira (2007), o qual apresenta uma metodologia de elicitação de requisitos que mescla o método RUP com a metodologia ARIS, subsidiados pelas ferramentas de melhoria de processos MASP e 5W1H. Neste trabalho o analista se vale de ferramentas da qualidade para elaborar uma reengenharia no processo, desenvolvendo um novo modelo do processo de negócio ora analisado chamado TO-BE.

O terceiro trabalho analisado foi o de Santos (2007), o qual a partir do uso do padrão BPMN, conseguiu realizar uma análise comparativa entre a análise de requisitos propostas pelo IEEE Std 1220 e os processos organizacionais.

Como foi mostrado nas seções 3.1, 3.2 e 3.3, todos os trabalhos analisados utilizaram a notação BPMN, como ferramenta de auxílio na modelagem e análise de processos de negócio.


4 Conclusão


Este trabalho comprova através dos autores citados e diante de seus respectivos trabalhos, que os conceitos e ferramentas do Business Process Modeling (BPMl) são capazes de auxiliar os analistas de sistemas e seus clientes ou usuários nas práticas da engenharia de requisitos, especialmente, na elicitação e avaliação dos requisitos ou processos a serem automatizados.

Destaca-se que os trabalhos analisados não utilizaram a linguagem BPMl em todo o ciclo de vida da engenharia de requisitos, limitando-se apenas as fases de elicitação e avaliação dos requisitos. Assim, não é possível verificar se tal linguagem é capaz de gerar benefício em todas as fases da engenharia de requisitos. Neste sentido, recomenda-se a realização de outros estudos para verificar os efeitos gerados pela adoção do BPMl nas demais fases da engenharia de requisitos.

Existem muitas ferramentas (aplicativos, software) no mercado que se passa por Business Process Management System (BPMS), mas na prática não passam de ferramentas de modelagem incapazes de atender a todos os requisitos necessários para serem consideradas BPMS. Segundo os autores, a ferramenta que mais se aproxima desta meta é o ARIS.

Por fim, ressalta-se a necessidade de gerar mais pesquisas relacionadas ao uso do BPM como suporte às práticas de engenharia de requisitos, pois a utilização do BPM pode gerar a mitigação dos problemas de escopo, entendimento e volatilidade dos requisitos dos processos a serem automatizados. Além disso, o BPM permite visualizar o papel do sistema no atendimento da estratégia do processo da organização. Assim, o gerente do projeto junto ao cliente, pode priorizar a automatização de um processo em detrimento de outro, desde que este faça parte do caminho crítico da cadeia de valores do processo organizacional.


Referência


Belgamo, A.; Martins, L. E. G. Um Estudo Comparativo sobre as Principais Técnicas de Elicitação de Requisitos do Software. In: Congresso de iniciação científica, 8.,2000. Anais. UNIMEP/CNPq. Disponível em: Acesso em: 01 jul. 2008.

Bitencout, Mauricio. Modelagem de Processos. ABPMP Brasil. 2008. Apresentação pública via internet. Disponível em< www.abpm.org. Acesso em: 13 jul. 2008.

Bortolini, Rafael. Padronizando Processos: BPMN, BPML, XPDL e BPEL. Baguete Tecnologia e informação em um só lugar. 2006. Disponível em: Acesso em: 16 maio 2008.

Da Silva, Sonia Maria Antunes; Bonin, Marcos Rodrigo; Paludo, Marco Antonio. Levantamento de Requisitos Segundo o Método Volere. RNTI-Revista Negócios e Tecnologia da Informação, v.1, n. 1, 2006.

De La Vara, Jose Luis; Sánchez, J. Improving Requirements Analysis trough Business Process Modelling: a participative approach. In: International conference business information systems, 11. 2008, Innsbruck,Austria. Proceedings... Innsbruck, Austria, 2008. Disponível em: . Acesso em: 04 jul. 2008.

Furlan, José Davi. BPM Conceitos Fundamentais. VP ABPMP Brasil. [s.l.: s.n.], 2008.

González, Jose Luis de la Vara; Díaz, Juan Sánchez. Business process-driven requirements engineering: a goal-based approach8th Workshop on Business Process Modeling, Development, and Support (BPMDS'07), 11-15 June 2007, Trondheim, Norway,2007. Disponível em: http://lamswww.epfl.ch/conference/bpmds07/program/Gonzalez_23.pdf. Acessado em 04/07/2008.

Magela, Rogério. Engenharia de Software Aplicada. Rio de Janeiro: Alta Books, 2006.

Martins, Luiz Eduardo Galvão. Uma Metodologia de Elicitação de Requisitos de Software Baseada na Teoria da Atividade. Tese apresentada à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas, como parte dos requisitos exigidos para obtenção do título de Doutor em Engenharia Elétrica. Campina, São Paulo, 2001. Disponível em:< http://libdigi.unicamp.br/document/?view=vtls000232385> Acesso em 02 jul. 2008.

Oliveira. Dione Cardoso. Modelagem de processo de negócio como ferramenta de reestruturação organizacional aplicada em uma fundação de pesquisa. 126 f. Dissertação em Engenharia de produção- Universidade Federal do Amazonas, Manaus, 2007.

Paula Filho, W.P., “Engenharia de Software: Fundamentos, Métodos e Padrões.” Rio de Janeiro: LTC. Editora, 2001.

Pereira, Helio. 10 itens para um perfeito BPMS. BPMS Brasil. 2007. Disponível em: Acessado em: 10 jul. 2008.

Pereira, Otoni Cunha. Desafio 21, a coluna da rede de gesta, Por Que Usar BPM?. Desafio 21, a coluna da rede de gestão. ano9, n.499. 27 abr. 2008. Disponível em: Acesso em 02 jul. 2008.

Pfleeger, Shari Lawrence. Engenharia de Software: teoria e prática. São Paulo: Prentice Hall, 2004.

Pressman, R.S. Engenharia de Software. 5.ed. [s.l.]: MacGraw-Hill, 2002.

Recker, Jan. BPMN Modeling – Who, Where, How and Why. BPTrends, 2008. Disponível em: Acesso em: 30 jul.2008.

Santos, Michele Ribeiro. Estudo comparativo dos processos utilizados na engenharia de requisitos. 55 f. Monografia submetida à Escola Politécnica para obtenção do grau de especialista em tecnologia da informação Universidade de São Paulo, São Paulo, 2007.

Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Addison Wesley, 2003.

Takai, Osvaldo Kotaro. Análise e projeto de sistema I. São Paulo: Centro Universitário Claretiano de Batatais, 2006.

Teixeira, Alan Santana; Ramos, Victor; Zaru, Makuxe. Uma Visão do Desenvolvimento de Software a partir da Modelagem de Negócio. Monografia apresentada para a obtenção de Titulo de Graduação em Bacharelado em Ciência da Computação. Unama - Belém / PA, 2004.

Van Lamsweerde, A., Requirements engineering in the year 00: a research perspective, in 'International Conference on Software Engineering', Departamento de engenharia de informática. Universidade Catolica de Louvain pp. 5-19, 2000.

Verissímo, Ricardo. Levantar requisitos e mapear processos. 2007. Disponível em:



Acesso em: 01 jul. 2008.

White, Stephan. A. BPMN Fundamentals. Burlingame: OMG, 2005.


Compartilhe com seus amigos:


©principo.org 2019
enviar mensagem

    Página principal