Uma Abordagem para Especificação de Requisitos para Sistemas de Informações Focada em Modelagem de Processos

Transcrição

1 Uma Abordagem para Especificação de Requisitos para Sistemas de Informações Focada em Modelagem de Processos Autoria: Denis Silveira, Pedro O. S. Cruz, Eber Schmitz Resumo: Um elemento essencial para o alinhamento da Tecnologia de Informação (TI) com a estratégia empresarial é que os Sistemas de Informação (SI) suportem adequadamente os processos de negócio da empresa. Isto só pode ser conseguido, se os requisitos dos SI de suporte sejam bem compreendidos pelas equipes de desenvolvimento de sistemas. Os processos de negócio são definidos pelas equipes de modelagem de processos de negócio, usando uma metodologia e linguagem próprias. Como todo processo de extração de conhecimento, esta passagem é tão mais difícil, quanto menos formais forem as respectivas linguagens no caso a de modelagem de processos e especificação de requisitos de SI. Na prática, as duas equipes usam metodologias e linguagens completamente distintas, sem qualquer mecanismo formal de mapeamento resultando em um grande número de imperfeições nos requisitos dos SI de suporte e uma grande quantidade de retrabalho. Este artigo mostra uma proposta para o mapeamento, através de heurísticas, entre os elementos das linguagens de modelagem de processos e de especificação de requisitos de sistema. O método proposto foi implementado como um módulo adicional na ferramenta FASTCASE. Palavras Chaves: Modelagem de Processos, Engenharia de Requisitos, UML, Diagrama de Atividades, Diagrama de Casos de Uso; 1. Introdução Cada vez mais a qualidade e produtividade dos processos organizacionais deixam de ser responsabilidade exclusiva dos dirigentes, passando a comprometer toda a estrutura organizacional, em qualquer nível. Neste contexto, o comprometimento, apresenta-se como uma arma de estratégica organizacional, garantido assim a sobrevivência da empresa. Os programas de melhoria contínua de processos vêm contribuindo de forma gradativa para o aumento da produtividade e ganhos de qualidade, introduzindo aperfeiçoamentos em cada uma das etapas desse processo (Almeida, 1996). No entanto, em algumas situações, é preciso realizar reestruturações eminentes e radicais abrangendo o processo como um todo, e não apenas uma etapa isolada. O foco dessa mudança deve se dirigido, principalmente, aos processos chaves da organização, ou seja, aqueles que contribuem de forma mais direta para a obtenção das metas estratégicas da organização, sejam elas redução de custos, redução no tempo de atendimento, melhoria da qualidade dos produtos ou do atendimento do cliente. A reformulação ampla, profunda e rápida de um processo organizacional, visando atender aos objetivos estratégicos, é chamada de reengenharia de processos (Davenport, 1993). 1

2 Os responsáveis por uma iniciativa de reengenharia de processos normalmente encontram várias barreiras na sua execução, sejam elas, de ordem cultural, tecnológica e/ou organizacional (Mouro et. al., 1999). Um dos principais problemas de ordem técnica, na reengenharia, refere-se a escolha da representação dos processos (Abeysingle e Phalp, 1997). As representações disponíveis variam desde de notações formais (matematicamente rigorosas) até notações gráficas (mais acessíveis). Cada um desses tipos de notações tem as suas vantagens e desvantagens. Geralmente, as notações formais podem ser executadas em um computador, com programas para se estudar em detalhes o comportamento dos processos. Contudo, existem problemas tais como: dificuldade de elaboração, que exige pessoas experientes; e na forma de apresentação, que dificulta a validação dos cenários com os usuários. Por outro lado, notações gráficas são excelentes para o levantamento e a apresentação, uma fez que são fáceis de serem assimiladas em um curto espaço de tempo. Porém, são deficientes, se comparada com as notações formais, em relação à simulação de experimento rigoroso. A tarefa de reengenharia de um processo geralmente introduz a necessidade de SI de apoio. No desenvolvimento desses sistemas, é necessário que seus requisitos sejam definidos. A definição de requisitos de SI é uma área bastante conhecida e vem merecendo uma grande atenção da comunidade acadêmica e industrial (Santander e Castro, 2000) (Serrano, 1997). Os requisitos levantamentos na etapa de reengenharia, normalmente, não são suficientes para especificar completamente os SI. Isso ocorre devido o fato da reengenharia está focada no processo como um todo, deixando os detalhamentos do sistema para a etapa de desenvolvimento. É comum que a reengenharia e o desenvolvimento sejam feitas inclusive por equipe distintas, com focos diferenciados, valorizando a necessidade de um mecanismo eficiente de comunicação entre essas etapas. É importante, portanto, a adoção de uma abordagem, devidamente acompanhada de técnicas e ferramentas, que torne mais natural e confiável a passagem da modelagem de negócio para os requisitos dos SI (Use Cases), garantindo a consistência e integração dessas duas etapas fundamentais aplicadas na TI dentro de uma empresa. Este artigo apresenta uma abordagem para o problema apresentado acima apoiada por uma ferramenta que permite tanto a modelagem dos processos de negócio, bem como a integração automática aos requisitos de um sistema de informação. Acreditamos com isso, contribuir para a diminuição do gap existente entre as abordagens de modelagem de processos e requisitos, disponibilizando uma melhora na comunicação entre as equipes envolvidas (Negócios e TI). 2. Modelagem de Processos de Negócio Esta seção apresenta os conceitos da literatura corrente referente aos termos Processos de Negócio, Modelagem de Processos e o Diagrama de Atividades. 2.1 Processos de Negócio Um processo é um conjunto de atividades estruturadas e medidas destinadas a resultar num produto especificado para um determinado cliente/mercado (Gonçalves, 2000). Estas atividades são arranjadas segundo um ciclo de vida, e são realizadas através de procedimentos específicos para cada atividade. Na concepção mais freqüente, processo é qualquer atividade 2

3 ou conjunto de atividades que toma um input, adiciona valor a ele, fornecendo um output a um cliente específico Ele exige uma acentuada ênfase na maneira como o trabalho é realizado na organização, em contraste com a ênfase relacionada com o produto em si, que se centra no que é o produto. Um processo é, portanto, uma ordenação específica das atividades de trabalho no tempo e no espaço, com um começo, um fim, e entradas e saídas claramente identificadas: uma estrutura para a ação. Esse elemento estrutural dos processos é a chave para a obtenção das vantagens da engenharia de processos (Davenport, 1993). Os processos têm características tais como custo, prazos, qualidade de produção, satisfação do cliente, etc. Uma melhora no processo ocorre quando se satisfaz a estratégia definida, se reduz o custo ou se aumenta a satisfação do cliente (Gonçalves, 2000). Os processos são a estrutura pela qual uma organização faz o necessário para produzir valor para os seus clientes. Em conseqüência, uma importante medida do processo é a satisfação do cliente com o produto. Uma empresa competitiva precisa ter uma integração entre todas as áreas funcionais do negócio, valorizando a interdependência entre elas. Atualmente, a competitividade está centrada no custo e na qualidade, valorizando o gerenciamento dos processos. Os três fatos que acarretam essas mudanças, segundo (Macedo e Schmitz, 2001), são: diversificação dos segmentos de mercado; intensificação da competitividade; e mudanças compulsórias de mercado. A combinação desses fatos tem influencia direta nos processos das organizações. Além do fato desses processos terem sido criados para serem estáveis, em detrimento de uma maior flexibilidade, os processos estão ligados à essência do funcionamento da organização, sendo típico da empresa e diferentes de uma organização para outra (Gonçalves, 2000). Sendo assim, exigem soluções personalizadas. 2.2 Modelagem de Processos O principal objetivo da modelagem de processos é representa-los de uma maneira clara e formal em diferentes níveis de abstração (Serrano, 1997). A disponibilidade de modelos elaborados desta forma permite uma análise crítica das atividades existentes para definir melhorias e racionalizações dos processos. A modelagem de processo tem sido desenvolvida como uma tecnologia para descrever processos tais que eles possam ser entendidos e desenvolvidos com maior transparência. Através dessa modelagem é possível planejar, criar procedimentos e documenta-los de forma consistente, possibilitando demonstrar a realidade da empresa e realizar modificações de acordo com situação futura desejável. Os modelos de processo de negócio influenciam diretamente a construção de SI. A descrição formal dos processos de uma organização contribui para a definição do domínio de informação a ser abordado pelo sistema. A partir das descrições funcionais e dos fluxos de informação contidos nos modelos de processo, é possível definir os requisitos a serem atendidos, fazendo com que, dessa forma, a modelagem de processo de negócio seja equivalente às etapas de análise de requisitos da Engenharia de Software (Campos e Santos, 2001). 3

4 A modelagem de processos de uma empresa possibilitará o desenvolvimento de SI mais robustos e consistentes, uma vez que toda a realidade da empresa será levantada e as verdadeiras necessidades do negócio conhecidas, organizadas e registradas através dos modelos. Na execução de um processo, suas atividades interagem com diversas pessoas, que podem desempenhar diferentes papéis. Cada atividade gera um conjunto de produtos e utiliza recursos. Segundo (Gonçalves, 2000) os processos podem ser classificados segundo sua natureza em: negócio (ou de cliente): são aqueles que caracterizam a atuação da empresa e que são suportados por outros processos internos, resultando no produto ou serviço que é recebido por um cliente externo; organizacionais: são centralizados na organização em busca de seu desempenho geral, garantindo o suporte adequado aos processos de negócio; e gerenciais: são focados no gerenciamento, e incluem as ações de medição e ajuste do desempenho da organização. Atividades podem ser tanto decompostas em subatividades como agrupadas em macroatividades. O nível de detalhe escolhido deve ser aquele mais adequado para a análise que se pretende realizar. Conforme definidos acima, processos e atividades possuem a mesma semântica. A nossa abordagem segue a natureza apresentada em (Gonçalves, 2000) e representa processos e atividades como a mesma abstração (atividade), desta forma, aceitando tanto agrupamentos como decomposições. A modelagem de processos envolve diversos elementos, dos quais destacamos os principais abaixo: processos: são coleções de atividades; atividades: são as tarefas (trabalhos) a serem realizados. Uma atividade requer recursos para realizar um script; artefatos: são produtos produzidos ou consumidos por atividades durante a sua realização; recursos: representam tudo que é necessário para a execução da atividade. Um recurso humano, especificamente, desempenha um papel na execução das atividades do processo; transição: é o encadeamento entre duas atividades; e desvio: é um condicional para a transição entre duas ou mais atividades. 2.3 Diagrama de Atividade O Diagrama de Atividades definido na UML (Unified Modeling Language) (Booch et al., 1999) foi escolhido para a modelagem de processos. A UML é uma linguagem de modelagem visual de grande poder de expressão, adotada pela OMG (Object Management Group - organização formada pela maioria das empresas de software no mundo, e que trata da padronização das técnicas orientadas a objeto). 4

5 O Diagrama de Atividades ilustra a seqüência de tarefas, manuais ou automatizadas, necessárias à execução de um processo (Booch et al., 1999). Entre as suas características, destaca-se a possibilidade de representação de atividades paralelas, diferenciando-o de um mero fluxograma. Neste diagrama, as atividades são situadas em raias de responsabilidade, representativas dos locais onde elas são executadas. Nestes locais existem recursos que interagem com as atividades durante sua realização. Estes insumos (recursos e produtos) são representados no diagrama na forma de objetos relacionados às atividades. Dentro da abordagem desse diagrama encontra-se disponíveis os seguintes artefatos: atividade, subatividades, transições, condicionais, caminho concorrente, raias de responsabilidade, recursos (insumos e produtos) e sinais de input e output, conforme apresentado em (Booch et al., 1999). Sendo assim, o diagrama de atividade se comporta de forma aderente a modelagem de processos, disponibilizando as seguintes características: Toda atividade se enquadra em uma de três categorias: negócio, organizacional ou gerencial; Toda atividade pode ser decomposta em subatividades; Toda subatividade é parte de uma superatividade; As atividades são realizadas segundo uma ordem específica, onde cada atividade só pode ser executada quando sua predecessora tiver terminado; A ordem da execução das atividades pode ser alterada por um desvio. Um desvio é uma transição de entrada única, e várias transições de saída, sujeita ao resultado de uma condição (chamada de condição de desvio) verdadeira; e Duas ou mais atividades de um processo podem ser executadas simultaneamente. Um mecanismo de sincronização deve ser introduzido quando uma atividade depende de duas ou mais atividades concorrentes. 3. Especificação de Requisitos de Sistemas A especificação de requisitos de SI é uma área multidisciplinar que vem despertando cada vez mais a atenção dos pesquisadores. O objetivo da especificação de requisitos funcionais é descrever as necessidades de um sistema de informação (Schmitz e Silveira, 2000). Raramente no desenvolvimento de um sistema de informação se tem a visão global em que o sistema será inserido. Geralmente, o que se tem, são intenções e desejos de facilitar a execução das atividades em um ambiente organizacional. No levantamento de requisitos são identificadas as necessidades junto ao usuário, procurando obter o que o mesmo deseja e espera do sistema. Muitos dos problemas associados com o desenvolvimento de SI podem se originar nesta fase (Santander e Castro, 2000), pois detectar o que realmente é relevante para o usuário levando em consideração os objetivos organizacionais, não é uma tarefa trivial. Vários são os motivos para que isto ocorra, entre os quais o fato de serem poucas as ferramentas que dão suporte a esta fase do ciclo de desenvolvimento de um sistema (Serrano, 5

6 1997). Podemos apontar algumas carências das técnicas, principalmente no que diz respeito a inclusão de aspectos inerentes ao ambiente organizacional no qual o software está inserido. Portanto, a construção de modelos de processo de negócio pode auxiliar na especificação dos requisitos de um sistema de informação. O diagrama de Use Cases, também, definido na UML (Booch et al., 1999), descreve o negócio e seu ambiente. O negócio é composto por todos os processos importantes de uma organização. O ambiente é caracterizado pelos clientes, parceiros e fornecedores que tomam parte no processo. Nos diagramas de Use Cases, os processos são modelados como use cases, enquanto o ambiente é modelado usando a figura do ator, que representa qualquer elemento externo que interage com o sistema. Segundo (Schmitz e Silveira, 2000), o processo de construção de um diagrama de Use Case inicia com a descoberta dos atores e prossegue com a identificação dos Use Cases associados com estes atores. Isso ocorre porque cada ator requer do sistema alguma funcionalidade e os passos necessários para obter estas funcionalidades são descritos em Use Cases. O segundo passo consiste em definir os caminhos básicos e posteriormente os caminhos alternativos para cada um dos Use Cases. O terceiro passo envolve revisar as descrições comportamentais a fim de encontrar os relacionamentos (include, extend e generalization) entre os use cases. Figura 1: Layout do Diagrama de Use Cases 4. Geração dos Requisitos a partir do Modelo de Processo Nesta seção apresentamos algumas diretrizes que auxiliam o trabalho da equipe de TI no desenvolvimento dos Use Cases a partir dos Diagrama de Atividades elaborados na modelagem dos processos. A seção 4.1 apresenta uma visão geral do método. As seções 4.2, 4.3 e 4.4 descrevem, respectivamente, as heurísticas para descoberta dos atores, e identificação dos Use Cases e diagramação. 4.1 Visão Geral do Método A geração do diagrama de Use Cases é realizada a partir da aplicação das heurísticas para a extração dos atores e dos Use Cases sobre o diagrama de atividades. As atividades, assim com as suas definições, e os seus relacionamentos são analisados em duas etapas, uma para identificação dos atores e outra para identificação dos Use Cases. Uma vez identificados os atores e os Use Cases são aplicadas as heurísticas para a diagramação dos elementos extraídos no formato do diagrama de Use Cases. 6

7 Figura 2: Esquema para Geração 4.2 Descoberta de Atores Na elaboração do diagrama de Use Case identificamos inicialmente os elementos externos ao sistema que interagem com o mesmo, denominado-os atores. Na modelagem de processo os atores não são representados explicitamente, porém estes fazem parte do processo sendo representados implicitamente. Apresentarem a seguir as heurísticas utilizadas para identificação no diagrama de atividade de atores em potencias. Heurísticas para Identificação dos Atores: 1º. Conforme dito anteriormente, as atividades suportam um detalhamento em sub-atividades. Sendo assim, os conjuntos de heurísticas devem considerar somente os diagramas que contemplam as atividades mais detalhadas, desprezando as superatividades. Isso se deve ao fato da superatividade de uma modelagem de negócio já estarem representadas nas suas sub-atividades; 2º. Um processo, independente de sua natureza, e concebido para o atendimento de algum elemento externo. Nos processos de negócio este elemento é o cliente, nos organizacionais é alguma parte da estrutura organizacional e nos gerenciais é algum elemento de controle. De alguma forma, sempre existirá algo ou alguém para os quais os processos realizam alguma tarefa, sendo identificado como um ator em potencial; 3º. O diagrama de atividade apresenta como um dos seus artefatos o conceito de raia de responsabilidade, caracterizado os responsáveis pela execução das atividades nela contida. Os elementos responsáveis que interagem com as atividades são caracterizados como atores em potencias, sendo que quando a interação não for relevante dentro do contexto em analise, este deverá ser desprezado pelo projetista; 4º. Na modelagem do diagrama de atividade, existem projetistas que representam como recurso os executores envolvidos no processo. Desta forma, os responsáveis identificados na heurística anterior, também serão representados como recursos. Sendo assim, caberá ao projetista a identificação e escolha dos recursos semanticamente iguais levantado pela ocorrência da heurística anterior com essa; e 7

8 5º. Os sinais (input/output) representados no diagrama de atividade, têm intrínseco um emissor/receptor, sendo representados como atores interagindo com o Use Case derivado da atividade. 6º. Atores identificados nas heurísticas 2 a 5 nomeados identicamente serão unificados. 4.3 Identificação dos Use Cases Conforme definido em (Booch et al., 1999), um Use Case representa uma seqüência de ações que um ou mais atores realizam num sistema de modo a obterem um resultado particular. A representação gráfica de um diagrama de Use Case viabiliza diversas abstrações, isso significa que projetistas diferentes podem diagramar corretamente o mesmo processo de forma diferente. As heurísticas apresentadas abaixo produzem uma primeira representação, pautada na correlação direta com o diagrama de atividades utilizado na modelagem do processo. 8

9 Heurísticas para Identificação dos Use Cases: 7º. Atividades serão representadas na forma de Use Case, sendo que as representativas de estados (que não realizam trabalho), não serão representadas; 8º. Atividades seqüenciais, sem desvios, de uma mesma raia de responsabilidade são representadas como um Use Case; 9º. Atividades concorrentes que são sincronizadas em um determinado ponto dando continuidade ao fluxo de trabalho, em uma atividade subseqüente, caracteriza a seguinte representação: as atividades concorrentes e subseqüentes darão origem a Use Cases distintos. Existindo, ainda, um relacionamento na forma include entre os Use Cases originados das atividades concorrentes e o Use Case originado da atividade subseqüente; e 10º. Atividades idênticas pertencentes a superatividade e/ou processos distintos, serão representados como um único Use Case, interagindo na forma include; 11º. Atividades executadas após desvios condicionais distintos que finalizam são representadas como um único Use Case, interagindo na forma include; 12º. Atividades executadas após desvios condicionais distintos que se unificam dando continuidade ao fluxo de trabalho, serão representados como um único Use Case, interagindo na forma extend; 13º. Quando da existência de interação entre Use Case (include ou extend), os atores identificados irão se relacionar apenas com o Use Case principal. 4.4 Diagramação dos Use Cases Com o objetivo de automatizar o método apresentado em uma ferramenta CASE (Computer Aided Software Engineering), se faz necessário a definição de heurísticas que viabilizem uma diagramação preliminar. Heurísticas para Diagramação dos Use Cases: 14º. O espaço destinado para diagramação deve ser dividido em três áreas virtuais verticais (não representadas no diagrama), que serão referenciadas como "a", "b" e "c"; 15º. O ator encontrado na segunda heurística deve ser desenhado na área "a", visto que este sempre existirá e deverá se relacionar com todos os Use Cases que são oriundos das atividades de negócio; 16º. Os atores encontrados na terceira heurística deverão ser desenhados na área "c" e se relacionarão com todos os Use Cases oriundos das atividades da mesma raia de responsabilidade; 17º. Os atores encontrados na quarta heurística deverão, também, ser desenhados na área "c" e se relacionarão com todos os Use Cases oriundos das atividades com as quais o recurso se relaciona; 9

10 18º. Os atores encontrados na quinta heurística deverão, também, ser desenhados na área "c" e se relacionarão com todos os Use Cases oriundos das atividades com as quais os sinais se relacionam; e 19º. Os Use Cases identificados serão desenhados na área "b" obedecendo a seqüência do fluxo de trabalho; 20º. Os Use Cases identificados serão desenhados na área "b" obedecendo a seqüência do fluxo de trabalho; 5. Estudo de Caso Com a finalidade de exemplificar, mostrando a aplicação das heurísticas apresentadas, utilizaremos o detalhamento do processo de contratação de um novo seguro de automóveis. As heurísticas, assim como os modelos, foram implementados, como uma extensão, na ferramenta FASECASE (Silveira, 1999). O FASTCASE (Silveira, 1999) é uma ferramenta CASE aderente com a UML (Booch et al., 1999), disponibilizando vários modelos utilizado modelagem do desenvolvimento de SI como apresentado em (Schmitz e Silveira, 2001). Figura 3: Esquema Arquitetural da Ferramenta FASTCASE 5.1 Descrição textual do Processo Como estudo de caso, escolhemos um processo de amplo conhecimento: Contratação de Seguro de Automóvel. No exemplo apresentado representamos a contratação de um seguro novo, não abrangendo o processo de renovação. Enfatizamos, assim, as principais atividades em detrimento das peculiaridades de uma seguradora real, sendo apresentado abaixo uma descrição sucinta. Neste processo de negócio o mercado caracteriza o cliente como o segurado. A contratação de um seguro de automóvel inicia-se com a vontade do segurado, que neste momento ainda é um proponente, em fazer o seguro. Este deve procurar um corretor, que será seu representante legal junto à seguradora, e informar as características do automóvel (marca, modelo, ano etc) e do seguro (coberturas, importâncias seguradas etc). O corretor identifica 10

11 assim o risco e, conforme orientações prévias de comercialização do seguro fornecidas pela seguradora, verifica se este é segurável ou não. Caso o risco não veja segurável o processo é terminado. Sendo o risco segurável, o corretor calcula o prêmio do seguro (valor a ser pago pelo segurado pelo serviço), também definido previamente pela seguradora. Este cálculo poderá ser feito de forma manual, através de planilha de cálculo, ou de forma automatizada, através de um aplicativo disponibilizado pela seguradora. O cálculo resultante será fornecido ao segurado para avaliação. O segurado poderá recusar o cálculo, terminando o processo, ou aceitá-lo, dando continuidade à contratação. Com o aceite do segurado em relação ao custo do seguro, o corretor formaliza-o confeccionando a proposta e encaminhando para a seguradora, onde ao chegar será protocolada. Neste momento será solicitado ao segurado um vistoria do automóvel em um determinado prazo, que deverá ser feita em qualquer das inspetorias credenciadas, normalmente terceirizadas. Conforme sua disponibilidade, o segurado, ou um designado, comparasse em uma inspetoria e apresenta a solicitação de vistoria e o automóvel. O inspetor procede então a vistoria, conforme determinado previamente pela seguradora, e preenche o laudo de inspeção que é encaminhado a seguradora. Ao chegar na seguradora o laudo de inspeção será protocolado. As propostas e os laudos protocolados na seguradora ficarão aguardando a analise técnica do risco. Essa atividade deverá ser realizada num prazo máximo de 15 dias. Neste prazo as proposta com os respectivos laudos serão analisados quanto às características de risco, podendo ser recusadas, finalizando o processo. Caso o prazo de 15 dias tenha sido decorrido, as proposta serão aceitas automaticamente. As propostas que forem aceitas terão a contratação formalizada com a emissão da apólice, que vem acompanhada das condições gerais do seguro e do instrumento de cobrança (carne, ordem de débito em conta etc). Os produtos emitidos (apólices, condições gerais e cobranças) serão encaminhados ao corretor, que encerra o processo formalizando junto ao segurado. 5.2 Modelo de Negócio da Contratação de Seguro O fato da UML (Booch et al., 1999) não ser uma metodologia, e sim uma linguagem padronizada, faz com que não tenha regras estabelecidas para a construção dos seus modelos. Sendo assim, qualquer modelo construído está condicionado ao nível de abstração do projetista. A seguir apresentamos os modelos de negócio referente ao processo descrito na seção anterior, utilizando os recursos disponíveis no diagrama de atividades em conformidade com os axiomas apresentados na seção 2.2 Modelagem de Processos. O primeiro diagrama representa uma visão macro do processo de negócio (figura 4), utilizando o conceito de superatividades. No segundo, apresentamos em o nível mais detalhado, utilizando-se de sub-atividades. 11

12 Figura 4: Modelo de Negócio Visão Macro 12

13 Figura 5: Modelo de Negócio Visão Detalhada 13

14 5.3 Aplicação das Heurísticas Com a finalidade de demonstrar as heurísticas propostas na seção anterior, discutiremos a aplicabilidade das mesmas ao estudo de caso descrito, analisando-as individualmente. a. A figura 5 apresenta claramente o detalhamento do processo. Sendo assim, a base para a aplicação das demais heurísticas; b. A descrição do processo define como cliente, o segurado, logo o mesmo será um ator e segundo a heurística 15 representado na área "a"; c. Existem três raias de responsabilidade: Corretora, Inspetoria e Seguradora. Sendo representados como atores na área "c" (heurística 16); d. Existem sinais (input e output) para "Solicitação Inspeção". Segundo a descrição estes sinais têm como receptor e emissor o segurado. Assim o segurado será um ator como afirmando na heurística 5; e. As aplicações das heurísticas 2 e 5 evidenciam o Segurado como ator, sendo assim heurística 6 as unificam em um único ator; f. A atividade "Aguardando Análise" representa um estado de espera, sendo a única a não ser representada na forma de Use Case; g. As atividades "Protocolar Proposta" e "Protocolar Laudo" são concorrentes e darão origem a dois Use Cases distintos relacionados na forma include com o Use Case "Analisar Risco"; h. As atividades "Calcular Seguro" e "Preenchimento Proposta" são executadas após desvios condicionais, onde as alternativas podem finalizar o processo. Desta forma, elas quando transformadas em Use Cases serão relacionados na forma include com o Use Case "Identificar Risco"; i. A atividade "Analisar Risco" é executada após um desvio condicional, que é unificada dando continuidade ao fluxo de trabalho, com a atividade "Emitir Apólice". Sendo assim, conforme a heurística 12, foi representada com o relacionamento extend com o Use Case "Emitir Apólice"; j. Os Use Cases "Identificar Risco", "Formalizar Seguro", "Inspecionar Veículo" e "Emitir Apólice" foram identificados como atividades de negócio, dessa forma somente eles foram relacionados com o ator Segurado, descoberto pela heurística 2; e k. O Diagrama de Use Cases foi dividido em três áreas virtuais verticais, sendo que o ator Segurado fica na primeira área, os Use Cases na segunda e os atores Corretora, Inspetoria e Seguradora na terceira. 5.4 Modelo de Requisitos Gerado Uma vez elaborado o modelo de negócio, nesta seção apresentamos o Diagrama de Use Cases, gerado pela ferramenta FASTCASE (Silveira, 1999) a partir das heurísticas estabelecidas. 14

15 Figura 6: Modelo de Requisitos Diagrama de Use Case 7. Conclusões Este artigo apresentou como contribuição importante uma proposta para mapeamento, através de heurísticas, entre os elementos das linguagens de modelagem de processos e de especificação de requisitos de sistema. Este fato diminui as inconsistências entre os modelos e, desta forma, contribuindo para produção de SI que suportem de maneira mais eficaz os processos de negócio da empresa. O método proposto foi implementado como um módulo adicional na ferramenta FASTCASE. A aplicação das heurísticas ao estudo de caso nos permite tirar algumas conclusões sobre o método. O maior ponto positivo é que a aplicação das heurísticas permite gerar uma versão preliminar da especificação de um SI coerente com o modelo de processo. Por outro lado, também notamos que o modelo gerado obrigatoriamente deve passar por uma revisão dos projetistas visando eliminar incorreções tais como nomenclatura, interações entre atores e use cases. No momento, estamos trabalhando em uma versão aprimorada do método, visando incluir: (1) as definições dos use cases a partir das pré e pós-condições encontradas no 15

16 diagrama de atividades e (2) a definição do modelo estático de informação (modelo de classes). Bibliografia (Abeysinghe e Phalp, 1997) (Almeida, 1996) (Booch et. al., 1999) (Campos e Santos, 2001) (Davenport, 1993) (Gonçalves, 2000) (Mouro et. al., 1999) (Macedo e Schmitz, 2001) (Santander e Castro, 2000) (Serrano, 1997) (Schmitz e Silveira, 2001) (Silveira, 1999) Abeysinghe, G., Phalp, K., Combining Process Modeling Methods, Information and Software Technology 39, 1997; Almeida, A. E. L., Tecnologia da Informação e Melhoria de Processos: O Foco no Desempenho Empresarial, Dissertação de Mestrado, PUC-Campinas, 1996; Booch et. al., Unified Modeling Language Notation Guide, Addison Wesley, 1997; Campos, R. e Santos, L. R., Modelagem de Processos e Definição de Requisitos para Sistemas de Informações para Previsão de Demanda, XXV ENANPAD. 2001; Davenport, T. H., Process Innovation, Harvard Business School Press, Boston, 1993; Gonçalves, J. E. L., As Empresas são Grandes Coleções de Processos, RAE - Revista de Administração de Empresas, Jan/Mar, V.40, n.1, 2000; Mouro, E. Z., Borges, M. R. S., Garcez, C. R., Reengenharia de Processos de Negócio Participativa, Relatório Técnico, IME Instituto Militar de Engenharia, 1999; Macedo, R. S. e Schmitz, E. A., Ferramentas de Modelagem de Processo: Uma Avaliação, XXXIII Simpósio Brasileiro de Pesquisa Operacional, 2001; Santander, V. F. A., Desenvolvendo Use Cases a partir de Modelagem Organizacional, III Workshop de Engenharia de Requisitos, 2000; Serrano, M. A. B., Análise de Negócio Aplicada à Modelagem de Meta Ambientes Automatizados, Tese de Doutorado, PUC-Rio, 1997; Schmitz, E. A. e Silveira, D. S., Desenvolvimento de Software Orientado a Objetos, Editora Brasport, 2001; Silveira, D. S., FASTCASE: Uma Ferramenta CASE para Desenvolvimento Visual de Sistemas Orientado a objetos, Dissertação de Mestrado, Instituto de Matemática NCE/UFRJ, 1999; 16