Dissertação- Sheila Leal Santos - Pós

UNIVERSIDADE FEDERAL DO ABC
CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DISSERTAÇÃO DE MESTRADO
SHEILA LEAL SANTOS
Método para modelagem de processos de negócios na engenharia de
requisitos de software
Santo André
2014
CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DISSERTAÇÃO DE MESTRADO
SHEILA LEAL SANTOS
Método para modelagem de processos de negócios na engenharia de
requisitos de software
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação
em Ciência da Computação da Universidade Federal do ABC –
UFABC – para a obtenção do Título de Mestre em Ciência da
Computação.
Área de concentração: Engenharia de Software
Linha de Pesquisa: Sistemas de Computação
Orientadora: Prof.ª Dr.ª Fabiana Soares Santana
Santo André
2014
DEDICATÓRIA
À minha tia Branca, que partiu tão nova, deixando uma dor
incurável. Tia, te amo muito e sempre vou te amar.
À minha família, meu alicerce. Muito obrigada pelo apoio,
torcida e carinho. Amo vocês.
AGRADECIMENTOS
Primeiramente, agradeço a Deus por ter me dado forças para continuar, pois mesmo eu sendo
imperfeita, falha e pecadora, nunca me abandonou e sempre tem se mostrado ser fiel e justo.
À minha família, minha mãe Izete, meu pai Flaviano Fernandes e minha irmã Cintia pelo
constante apoio e carinho, por acreditarem que eu sou capaz, pelas orações fervorosas nos
momentos mais difíceis e por compreenderem cada momento de ausência. Um agradecimento
especial a minha avó Isbela Norberto Leal, com 94 anos. Obrigada por tudo e desculpe a
minha ausência durante a elaboração deste trabalho. Te amo muito.
Às minhas sobrinhas lindas Renata Santos Rangel e Sophia Santos Rangel. Obrigada meus
amores pelos momentos em que pude brincar com vocês, único meio que encontrava para
esquecer os problemas e as pressões.
À minha orientadora Fabiana Soares Santana, obrigada por acreditar neste trabalho, pela
torcida, pela paciência, conselhos, pela oportunidade, pelo carinho, pelo aprendizado
adquirido durante essa longa caminhada. Muito obrigada!
Ao professor e amigo Jorge Becerra, ao qual serei eternamente grata pelo aprendizado,
oportunidade, experiência adquirida e base para todo aprendizado.
Ao amigo Leonardo Dias pelo aprendizado, por me fazer entender, por todas as cobranças,
por todas as críticas construtivas, as quais eu pude aprender. Muito obrigada!
Ao Silvio Trasmonte, pela oportunidade de colocar a teoria em prática, onde pude aprimorar
os meus conhecimentos e ter um maior entendimento para a realização deste trabalho.
Ao Profº. Drº. Wagner Tanaka Botelho, que esteve presente em um momento de pressão, me
encorajando e me mostrando que eu sou capaz. Muito obrigada!
Ao Profº.Drº Ronaldo Prati, pela dedicação e por estar sempre presente e disposto a resolver
todos os problemas.
À minha amiga, irmã, Tatiana Aparecida, não há palavras nesse mundo que possa expressar
a minha imensa gratidão só me resta agradecer pelo constante apoio, por cada palavra de
carinho. Obrigada por me ajudar a levantar num momento de muita dor. Obrigada por estar
presente no momento em que eu pensei em desistir, mas você me encorajou e me ajudou a
levantar. Muito obrigada!
À amiga Rafaela Godoi, por todas as suas palavras encorajadoras. Estas sempre chegaram na
hora certa para me fortalecer e me encorajar. Muito obrigada!
À minha amiga Silvia Scheunemann Silva, muito obrigada por estar sempre presente, por
cada palavra de consolo e por secar cada lágrima minha.
À amiga Andréia Gusmão, obrigada pelas risadas e pelo constante apoio. Estará sempre
presente no meu coração.
Aos amigos que encontrei durante essa difícil caminhada: Luciano Barros e Cleonice Caro.
Sempre tivemos um ao outro e, quando faltava força para continuar, estávamos ali para uma
palavra de carinho, um gesto de ternura que nos motivava, nos encorajando a seguir. Somos
todos guerreiros!
Aos professores Sueli Loddi, Wilson Vendramel e Rosângela Krong, sem o apoio de vocês
não teria ingressado no programa de Mestrado da UFABC.
A todos que de uma forma direta ou indireta, seja em palavras, seja em ações, contribuíram
para a realização deste trabalho.
FICHA CATALOGRÁFICA
SANTOS, SHEILA LEAL. MÉTODO PARA MODELAGEM DE PROCESSOS DE
NEGÓCIOS NA ENGENHARIA DE REQUISITOS DE SOFTWARE.
S. L. SANTOS, SANTO ANDRÉ, 2014. 106 PÁGINAS.
DISSERTAÇÃO DE MESTRADO - CENTRO DE MATEMÁTICA, COMPUTAÇÃO E
COGNIÇÃO, UNIVERSIDADE FEDERAL DO ABC.
1. INTRODUÇÃO; 2. ARQUITETURA ORIENTADA A SERVIÇOS; 3. TRABALHOS
RELACIONADOS; 4. PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA
ENGENHARIA DE REQUISITOS EM SOA; 5. APLICAÇÃO DO MÉTODO; 6.
CONSIDERAÇÕES FINAIS; 7. REFERÊNCIAS BIBLIOGRÁFICAS.
RESUMO
SANTOS, SHEILA LEAL. Método para modelagem de processos de negócios na engenharia
de requisitos de software. 2014. 105f.
Dissertação de Mestrado – Centro de Matemática, Computação e Cognição – Universidade
Federal do ABC – UFABC, Santo André, São Paulo.
As empresas produtoras de software precisam de métodos eficientes para obter resultados
competitivos. Uma das principais causas dos resultados negativos em projetos de software se
deve às deficiências na engenharia de requisitos de software. A especificação de requisitos
inadequada ou incompleta pode levar à construção de sistemas que não estão em
conformidade com as necessidades dos clientes, resultando no aumento de custos, atrasos nos
cronogramas e realização de atividades desnecessárias. A fim de minimizar os problemas na
especificação de requisitos, as boas práticas de engenharia de software recomendam o
entendimento adequado do ambiente de tecnologia da informação (TI) e das regras de
negócio. O uso de processos de negócio tem sido adotado pela maioria das organizações para
mapear as suas necessidades e alinhar o conhecimento entre as equipes de negócio e de TI.
BPMN (Business Process Modeling Notation, no original em inglês, ou Notação para
Modelagem de Processos de Negócios) é a notação mais comumente adotada pelo mercado
para a modelagem de processos de negócio, com diversas ferramentas disponíveis para o
mapeamento e simulação de processos. Além da preocupação com os processos de negócio,
as organizações têm adotado arquiteturas orientadas a serviços (SOA, Service Oriented
Architectures, no original em inglês) com o intuito de facilitar a integração entre processos e
tecnologia, resultando em soluções mais flexíveis para atender às constantes necessidades de
mudanças e oportunidades de negócio. A união de BPMN e SOA permite o melhor
entendimento dos sistemas através do mapeamento e modelagem dos processos de negócio, a
partir dos quais é possível identificar os serviços que devem ser encapsulados dentro de um
determinado ambiente tecnológico. O resultado é o aumento na produtividade, a melhoria na
qualidade dos sistemas (QoS, Quality of Software, no original em inglês) e a redução de
custos. Este trabalho propõe um método para modelagem de processos na engenharia de
requisitos, incorporando formalmente o uso de processos de negócios na especificação dos
requisitos de software. Um estudo de caso foi desenvolvido para experimentar o método
proposto e mostrar a sua aplicação. Embora experimentos adicionais sejam recomendados, os
resultados do estudo de caso foram promissores e mostram que a análise minuciosa dos
processos de negócios na etapa de especificação de requisitos auxilia no entendimento e na
identificação mais precisa dos requisitos do sistema, melhorando o potencial de sucesso na
produção de software.
Palavras-chave: processos, engenharia de requisitos de software, arquiteturas orientada a
serviços (SOA).
ABSTRACT
SANTOS, SHEILA LEAL. Method for business processes modeling in the software
requirements engineering. 2014. 105 p.
Master´s Thesis - Centro de Matemática, Computação e Cognição, Universidade Federal do
ABC, Santo André, São Paulo.
Producing software companies need effective methods to achieve competitive results. A
major cause of adverse outcomes in software projects is due to deficiencies in the software
requirements engineering. The specification of inadequate or incomplete requirements can
lead to the construction of systems that are not in accordance with customer needs, resulting
in increased costs, schedule delays, and development of unnecessary activities. In order to
minimize the problems in the requirements specification, best practices in software
engineering recommend a proper understanding of the information technology (IT)
environment and of the business rules. The use of business processes has been adopted by
many organizations to map their needs and to align the knowledge among business teams and
IT. BPMN (Business Process Modeling Notation) is the notation most commonly adopted by
the software companies for business processes modeling. Various software tools are available
for processes mapping and simulation. In addition to the concern with business processes,
many organizations are adopting service-oriented architectures (SOA) in order to facilitate
the integration between processes and technology, resulting in more flexible solutions to meet
the ever changing IT needs and the new business opportunities. The union of BPMN and
SOA allows a better understanding of the systems to be developed by mapping and modeling
business processes, from which it is possible to identify the services that should be
encapsulated within a particular technological environment. Results include increased
productivity, improved quality of software (QoS) and cost reduction. This work proposes a
method for including the processes modeling as part of the requirements engineering,
formally incorporating the use of business processes in the software requirements
specification. A case study was developed to experiment the proposed method and to
illustrate its application. Although further experiments are recommended, the results of the
case study are promising and show that a thorough analysis of the business processes as part
of the requirements specification phase helps in understanding and obtaining a more accurate
identification of the system requirements, improving the potential for successful software
production.
Keywords: processes, software requirements engineering, service-oriented architectures
(SOA).
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................. 21
1.1. MOTIVAÇÃO ......................................................................................................... 21
1.2. OBJETIVO .............................................................................................................. 22
1.3. MÉTODO ............................................................................................................... 23
1.4. ABRANGÊNCIA ................................................................................................... 23
1.5. ORGANIZAÇÃO DO TRABALHO ...................................................................... 23
2. MATERIAIS E MÉTODOS..............................................................................................25
2.1. ARQUITETURA ORIENTADA A SERVIÇOS..........................................................25
2.1.1. WEB SERVICES ................................................................................................. 28
2.1.2. PROTOCOLO HTTP ........................................................................................... 29
2.1.3. XML .................................................................................................................... 29
2.1.4. SOAP ................................................................................................................... 30
2.1.5. WSDL .................................................................................................................. 31
2.1.6. UDDI ................................................................................................................... 33
2.2. SOFTWARE COMO SERVIÇO...................................................................................35
2.3. PROCESSO DE REFERÊNCIA DE NEGÓCIO........................................................37
2.4. ENGENHARIA DE REQUISITOS...............................................................................42
2.5. MODELOS DE REQUISITOS......................................................................................45
2.5.1. INTERNATIONAL STANDARD ISO/IEC/IEEE 29148:2011 SYSTEMS AND
SOFTWARE ENGINEERING LIFE CICLE PROCESS REQUIREMENTS
ENGINEERING .............................................................................................................. 45
3. TRABALHOS RELACIONADOS...................................................................................46
3.1. EXTRAÇÃO DE REQUISITOS DE SOFTWARE ..................................................... 46
3.2. ESPECIFICAÇÃO DE CASO DE USO ....................................................................... 47
3.2.1. CONNECTION .................................................................................................... 47
3.2.2. GATEWAY ............................................................................................................ 47
3.2.3. INTERMEDIATE EVENTS ............................................................................... 47
3.2.4. START EVENT E END EVENT ........................................................................ 47
3.2.5. TASKS .................................................................................................................. 47
3.3. ESPECIFICAÇÃO DE ATIVIDADES ........................................................................ 49
3.4. ESPECIFICAÇÃO DE CLASSES ............................................................................... 50
3.5. TRABALHOS RELACIONADOS ............................................................................... 50
4. PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA ENGENHARIA DE
REQUISITOS EM SOA........................................................................................................52
5. APLICAÇÃO DO MÉTODO............................................................................................56
5.1. AS IS ....................................................................................................................... 58
5.1.1. ESTRATÉGIA .................................................................................................... 73
5.1.2. TO BE ................................................................................................................... 73
5.1.3. EXTRAÇÃO DE REQUISITOS .......................................................................... 82
5.1.4. ESPECIFICAÇÃO ............................................................................................... 82
5.1.5. IMPLEMENTAÇÃO DOS PROCESSOS BizAgi Xpress ................................. 85
5.1.6 .IMPLEMENTAÇÃO DOS PROCESSOS JBPM ................................................ 94
6.CONSIDERAÇÕES FINAIS.............................................................................................98
6.1. PRINCIPAIS CONTRIBUIÇÕES DO TRABALHO ............................................. 98
6.2. PUBLICAÇÕES ASSOCIADAS ............................................................................ 98
6.3. CONCLUSÃO ......................................................................................................... 99
6.4. TRABALHOS FUTUROS ...................................................................................... 99
7. REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................100
LISTA DE FIGURAS
1.
MERCADO COMPARATIVO DE ESB EM NIVEL MUNDIAL ........................ 28
2.
SINTAXE DE UMA MENSAGEM SOAP ............................................................ 30
3.
ELEMENTO CORPO RESPOSTA ........................................................................ 31
4.
DOCUMENTOS WSDL ......................................................................................... 31
5.
ESQUEMA REPRESENTANDO OS PASSOS NA UTILIZAÇÃO DE UM
SERVIÇO WEB....................................................................................................................... 32
6.
PROTOCOLOS UTILIZADOS .............................................................................. 33
7.
DIMENSÕES CRÍTICAS DO PROCESSO ........................................................... 37
8.
SUBPROCESSO EMISSÃO DE POLUENTES .................................................... 49
9.
CASO DE USO EMISSÃO DE POLUENTS ........................................................ 49
10.
MÉTODO PROPOSTO .......................................................................................... 53
11.
ESTRUTURA PROPOSTA .................................................................................... 57
12.
ESTRUTURA PROPOSTA BIZAGIXPRESS....................................................... 57
13.
MACRO PROCESSO ............................................................................................. 60
14.
SUBPROCESSODE SERVIÇO ............................................................................. 62
15.
SUBPROCESSO AVALIAÇÃO DO CICLO DE VIDA ....................................... 62
16.
SUBPROCESSO REDUZ ELIMINA RESÍDUOS ................................................ 63
17.
CICLO DE VIDA.................................................................................................... 65
18.
SUBPROCESSO TIPO DE RECURSO ................................................................. 66
19.
EMISSÃO DE POLUENTES ................................................................................. 67
20.
SUBPROCESSO IMPACTO DE PRODUÇÃO .................................................... 68
21.
SUBPROCESSO AVALIAÇÃO DA DISTRIBUIÇÃO ........................................ 70
22.
SUBPROCESSO UTILIZAÇÃO ............................................................................ 71
23.
SUBPROCESSO DISPOSIÇÃO DE RESÍDUO.................................................... 72
24.
MACRO PROCESSO TO BE ................................................................................ 74
25.
SUBPROCESSO PRODUTO TO BE .................................................................... 75
26.
AVALIAÇÃO SIMPLIFICADA TO BE................................................................ 75
27.
REDUZIR ELIMINAR RESÍDUOS TO BE .......................................................... 76
28.
SUBPROCESSO AVALIAÇÃO DO CICLO DE VIDA TO BE........................... 76
29.
SUBPROCESSO TIPO DE RECURSO TO BE ..................................................... 77
30.
SUBPROCESSO EMISSÃO DE POLUENTES TO BE........................................ 77
31.
SUBPROCESSO IMPACTO DE PRODUÇÃO TO BE ........................................ 79
32.
AVALIAÇÃO DA DISTRIBUIÇÃO TO BE ......................................................... 80
33.
SUBPROCESSO UTILIZAÇÃO TO BE ............................................................... 80
34.
SUBPROCESSO DISPOSIÇÃO DE RESÍDUOS TO BE ..................................... 81
35.
SUBPROCESSO PRODUTO ................................................................................. 82
36.
TELA PARA VERIFICAR TRANSPORTE .......................................................... 85
37.
MODELO DE DADOS DO NEGÓCIO ................................................................. 86
38.
ATIVIDADES HABILITADAS PARA CRIAÇÃO DE FORMULÁRIOS .......... 87
39.
CRIAÇÃO DE FORMULÁRIOS ........................................................................... 88
40.
DEFINIÇÃO DE EXPRESSÕES (CONDIÇÕES) ................................................. 88
41.
PARÂMETRO ........................................................................................................ 91
42.
CONSULTA AO BANCO DE DADOS ................................................................. 91
43.
WSDL GERADO AUTOMATICAMENTE .......................................................... 92
44.
PORTAL DOS PROCESSOS ................................................................................ 92
45.
EXECUÇÃO DOS PROCESSOS........................................................................... 93
46.
MEDIÇÃO DOS PROCESSOS .............................................................................. 93
47.
REPRESENTAÇÃO JPDL ..................................................................................... 94
48.
PROCESSOS JBPM - CONSOLE.......................................................................... 96
LISTA DE TABELAS
1.
MÉTODO ADOTADO ........................................................................................... 23
2.
FLUXOS PRINCIPAIS ......................................................................................... 39
3.
OBJETOS DE CONEXÃO ..................................................................................... 39
4.
POOLS E LANES ................................................................................................... 39
5.
ELEMENTOS DOS ARTEFATOS ........................................................................ 40
6.
RESUMO DAS ATIVIDADES BPEL ................................................................... 41
7.
TRANSFORMAÇÃO DA BPMN PARA DIAGRAMA DE CASO DE USO ..... 48
8.
PRINCIPAIS ELEMENTOS DA BPMN E SUAS HEURÍSTICAS ..................... 55
9.
VANTAGENS E DESVANTAGENS BizAgi Xpress .......................................... 96
10.
VANTAGENS E DESVANTAGENS JBPM ......................................................... 96
LISTA DE ABREVIATURAS E SIGLAS
API: Application Programming Interface, no original em inglês, ou Interface de
Programação de Aplicativos.
ASP: Application Service Provider, no original em inglês, ou Provedor de Serviço de
Aplicação.
BPEL: Business Process Execution Language, no original em inglês, ou Linguagem de
Execução de Processos de Negócios.
BPM: Business Process Management, no original em inglês, ou Gerenciamento de Processos
de Negócios.
BPMI: Business Process Management Initiative, no original em inglês, ou Instituição de
Gerenciamento de Processos de Negócios.
BPMN: Business Process Modeling Notation, no original em inglês, ou Notação para
Modelagem de Processos de Negócios.
BPMS: Business Process Modeling Suite, no original em inglês, ou Suite para Modelagem de
Processos de Negócios.
CO: Monóxido de carbono
DS: Design Sustentável
ERP: Enterprise Resource Planning, no original em inglês, ou Planejamento de Recursos
Empresariais.
ESB: Enterprise Service Bus, no original em inglês ou Barramento de Serviços.
FDD: Feature Driven Development, no original em inglês, ou Desenvolvimento Guiado por
Funcionalidades.
HC: Hidrocarboneto
HTML: HyperText Markup Language, no original em inglês ou Linguagem de Marcação de
Hipertexto.
HTTP: Hiper Text Transfer Protocol, no original em inglês ou Protocolo de Transferência de
Hipertexto.
IBM: International Business Machines.
IEEE: Institute of Electrical and Electronic Engineers.
ISEI: International Conference on Ecological Informatics.
JPDL: Process Definition Language, no original em inglês.
N2: Nitrogênio Molecular
NOX: Óxidos de Nitrogênio
RF: Requisitos Funcionais
SAAS: Software as a Service, no original em inglês, ou Software como Serviço.
SEI: Software Engineering Institute, no original em inglês, ou Instituto de Engenharia de
Software.
SMTP: Simple Mail Transfer Protocol, no original em inglês, ou Protocolo de Transferência
de Correio Simples.
SOA: Service-Oriented Architecture, no original em inglês, ou Arquitetura Orientada a
Serviços.
SOAP: Simple Object Access Protocol, no original em inglês, ou Protocolo Simples de
Acesso a Objetos.
TI: Tecnologia da Informação
UDDI: Universal Description Discovery and Integration, no original em inglês, ou
Integração e Descoberta da Descrição Universal.
UFABC: Universidade Federal do ABC.
URL: Uniform Resource Locator, no original em inglês, ou Localizador Uniforme de
Recursos.
OTAN: Organização do Tratado do Atlântico Norte.
XML: Extensible Markup Language, no original em inglês, ou Linguagem de Marcação.
XP: Extreme Programming, no original em inglês, ou Programação Extrema.
W3C: World Wide Web Consortium.
WS: Web Services, no original em inglês, ou Serviço Web.
WSDL: Web Services Description Language, no original em inglês, ou Linguagem para
Descrição de Serviços Web.
1. INTRODUÇÃO
1.1.
MOTIVAÇÃO
As organizações estão inseridas em um ambiente competitivo e precisam de
eficiência e eficácia para a realização dos seus objetivos. As empresas produtoras de software
não são exceção. No entanto, um dos desafios relacionados à engenharia de software está em
como minimizar os erros encontrados no desenvolvimento de software (SOMMERVILLE,
2007). Sabe-se que a grande maioria dos erros deve-se ao não entendimento das necessidades
dos clientes. Não há uma explicação simples para este fenômeno, mas diversos trabalhos
apontam deficiências nos requisitos dos sistemas como uma das principais causas de
fracassos em projetos de software.
Uma pesquisa realizada pelo Standish Group (2013) com 350 companhias e 8.000
projetos indica que apenas 16,2% dos projetos são concluídos com sucesso, 52,7% são
considerados problemáticos, pois não atendem as necessidades dos usuários e têm custos
excessivos, e 31,1% são cancelados antes de serem completados, representando um
desperdício da ordem de US$ 81 bilhões.
A fim de identificar os principais fatores que levam à distribuição apresentada, foi
realizada uma nova pesquisa, onde diversos fatores foram identificados como críticos, a
saber: 1. Falta de especificação de requisitos; 2. Requisitos incompletos; 3. Mudança de
requisitos;
4. Falta de apoio executivo; 5. Tecnologias imaturas; 6. Falta de recursos; 7.
Expectativas irreais; 8. Tecnologias novas; e 9. A comunicação entre o usuário e o
desenvolvedor é muito fraca (STANDISH GROUP apud PFLEEGER, 2004).
Nota-se, portanto, que a falta de habilidade para definir adequadamente os requisitos
de software e para lidar com os clientes e usuários são os principais fatores de falhas no
desenvolvimento de software. Além disso, as falhas na especificação de requisitos podem
resultar na não identificação de requisitos importantes ou na especificação de requisitos com
conteúdo inadequado. Uma especificação de requisitos inadequada ou incompleta pode levar
à produção de sistemas que não atendem às necessidades dos clientes, aumento de custos,
potenciais atrasos no cronograma e realização de atividades duplicadas ou desnecessárias,
entre outros fatores que prejudicam o desenvolvimento de software (JIANG, 2000).
Para minimizar os problemas relacionados com a especificação de requisitos, as
empresas produtoras de software precisam aplicar estratégias de TI (Tecnologia da
Informação) que sejam capazes de alinhar os recursos de hardware, as necessidades do
negócio e as boas práticas de engenharia de software para reduzir os custos e aumentar a
21
produtividade e a qualidade dos produtos gerados. Isso ocorre através do entendimento do
negócio e do ambiente de TI (SOMMERVILLE, 2007).
Dessa forma, diversas empresas têm adotado o uso de processos de negócio com a
finalidade de obter um maior entendimento das suas necessidades e promover o alinhamento
entre a equipe de negócio e a equipe de desenvolvimento de software, proporcionando um
detalhamento adequado das atividades a serem executadas (SANTANA, 2010). Os processos
de negócio permitem uma visão corporativa das soluções de software e apontam claramente
as oportunidades e deficiências do ambiente.
Atrelada ao processo de negócios está a BPMN é a notação mais adotada pelo
mercado para a modelagem de processos de negócio, com diversas ferramentas disponíveis
para o mapeamento e simulação de processos (SANTANA, 2010).
A notação permite
visualizar os detalhes de cada processo e, dependendo da sua complexidade, representá-lo em
subprocessos independentes. Além disso, permite a execução dos processos de negócios
através da construção orientada a serviços. Porém, a arquitetura orientada a serviços não
prevê o uso de processos de negócios para a definição dos requisitos de software.
No entanto, existe uma conexão possível entre as três partes: SOA, BPMN e
especificação de requisitos. Isso ocorre porque, nos sistemas orientados a serviço, a execução
do software é muito similar à execução de um processo (SANTANA, 2009). Em geral, os
serviços são orquestrados em uma linguagem específica chamada BPEL (Business Process
Execution Language, no original em inglês, ou Linguagem para Execução de Processos de
Negócios), que se encarrega de instanciar os serviços de forma ordenada, como definido no
processo. A tradução de BPMN para BPEL pode ser feita de forma automática, pois já
existem diversas ferramentas para isso. Desta forma, existe uma ligação entre SOA e BPMN.
1.2.
OBJETIVO
Este trabalho tem como objetivo propor um método para incorporar os processos de
negócios como ferramenta na engenharia de requisitos.
Para experimentar o método proposto, será considerado um estudo de caso, baseado
na definição dos requisitos de software para o seguinte processo: design sustentável,
aplicando os conhecimentos adquiridos para a construção de processos de negócio usando
BPMN. A partir da análise individual de cada atividade do processo apresentado, serão
identificados os requisitos de software.
Espera-se que os resultados obtidos nesse trabalho possam ajudar na etapa de
especificação de requisitos através da análise minuciosa dos processos de negócios.
22
1.3.
MÉTODO
Com o intuito de atender o objetivo proposto, o método adotado é apresentado na
tabela 1, envolvendo os principais passos para o desenvolvimento deste trabalho.
Principais passos
1º Estudo do domínio
Descrição
Consiste no entendimento do domínio do problema.
2º BPMN
Tem como finalidade realizar o mapeamento e
modelagem do estudo de caso proposto.
3º Ciclo BPM
Aplicar o ciclo BPM no estudo de caso design
sustentável.
4º Método proposto para elaboração da especificação Consiste em propor um método para incorporar
de requisitos.
processos de negócios como ferramenta na engenharia
de requisitos. No entanto, não está no escopo deste
trabalho de dissertação desenvolver o documento de
requisitos.
5º Aplicar o método proposto
Esta etapa visa realizar a aplicação do método
proposto utilizando o estudo de caso design
sustentável.
6º Implementação dos serviços
Consiste em utilizar processos para a implementação
dos serviços.
7º Analisar os resultados obtidos
A análise será realizada através de uma comparação
da BPMN juntamente com o documento de requisitos
proposto pela ISO/IEC/IEEE 29148:2011.
Tabela 1: Método adotado
Fonte: LEAL (2014)
1.4.
ABRANGÊNCIA
O método proposto neste trabalho foi aplicado em um modelo não organizacional,
no entanto, pode ser aplicado em uma organização de pequena, média e grande porte, onde os
requisitos podem ser de duas formas: (1) requisitos claros e completos, mas que mesmo
assim, há necessidade de obter um gerenciamento dos processos de negócios e das possíveis
mudanças que podem ocorrer durante a fase de elicitação. (2) requisitos incompletos, neste
caso o uso do BPM e BPMN justifica-se pela necessidade de entender as necessidades do
cliente, as regras de negócios e os seus processos de negócios onde espera-se uma melhora
nos resultados obtidos na etapa de levantamento de requisitos.
1.5. ORGANIZAÇÃO DO TRABALHO
O capítulo inicial deste trabalho apresenta uma introdução ao problema e os
principais objetivos da proposta de mestrado.
23
O segundo capítulo apresenta os conceitos necessários para o desenvolvimento da
proposta de mestrado, incluindo: (2.1) arquiteturas orientadas a serviço, (2.2) SaaS (Software
as a Service, no original em inglês, ou Software como Serviço), (2.3) processo de referência
de negócio, (2.4) engenharia de requisitos, (2.5) modelo de requisitos e (3) trabalhos
relacionados.
O quarto capítulo apresenta o método deste trabalho. E para finalizar, o quinto
capítulo apresenta a aplicação do método proposto.
24
2.
MATERIAIS E MÉTODOS
Esta seção descreve os principais conceitos necessários para o desenvolvimento
deste trabalho.
2.1. Arquitetura orientada a serviços
Existem diferentes definições para o conceito de serviço e de arquitetura.
(MARZULLO, 2009) e outros estudiosos definem o conceito de serviços como uma
informação necessária ao negócio, no entanto, essa informação será um serviço somente se
for mapeada em atividades.
Uma definição mais precisa para o conceito de serviços é sugerida pelo IEEE que
define serviço como sendo um relacionamento entre um provedor e um consumidor. O
primeiro se compromete a realizar determinadas tarefas e o segundo a utilizar determinados
serviços. Dessa forma, um serviço de TI é uma representação de uma atividade de negócio
que pode ser mapeada por meio de uma entrada, um processamento e uma saída, ou seja,
representa detalhes das tarefas necessárias para executar uma determinada atividade dentro de
um processo existente na organização.
Em contrapartida, uma arquitetura é a estrutura do sistema composto pelos
elementos de software, correspondendo às propriedades visíveis desses elementos assim
como o seu relacionamento.
A partir de uma breve definição de serviços e de arquitetura é possível definir SOA
como uma abordagem para a utilização dos recursos de TI que tem como finalidade apoiar o
negócio da organização. Dentro dessa abordagem podem-se identificar os seguintes
benefícios: separação das responsabilidades, organização lógica, facilidade de uso, integração
de aplicações e flexibilidade (MARZULLO, 2009).
Baseia-se na idéia principal de que um sistema de informação é um conjunto de
serviços facilmente acessíveis que podem ser ligadas de forma dinâmica, com a finalidade de
fornecer a informação desejada melhorando a eficiência da empresa. Esses serviços podem
ser utilizados nos processos mais complexos com a finalidade de realizar os objetivos
estratégicos da empresa, sendo assim, são compostos por elementos que representam papéis
distintos de interação: o consumidor, o prestador e a central de serviço, denominada serviço
de identificação (LIN et al., 2010).
25
Além dos serviços que possuem um dos objetivos da SOA é proporcionar um
ambiente que alinha esses serviços com as metas da empresa. Por meio da modelagem dos
processos é possível identificar os principais processos organizacionais e dependendo da sua
complexidade é possível desmembrá-los em subprocessos de negócios até o nível em que as
atividades são mapeadas.
Atualmente, um dos conceitos que vem sendo difundido é o uso do BPM (Business
Process Management, no original em inglês, ou Gerenciamento de Processos de Negócios) e
SOA, pois têm sido defendidas como iniciativas evolutivas que permitem que as
organizações se tornem mais ágeis, através da flexibilidade. Essas são, porém, iniciativas
distintas. A primeira está relacionada à gestão e estratégia organizacional. A segunda é uma
abordagem de arquitetura para o desenvolvimento de sistemas (ENGELS et al., 2008).
Os seguintes aspectos devem ser considerados para adoção de SOA: (STAL, 2006)
1. Interface e contrato que descrevem os serviços e contratos oferecidos ao cliente;
2. Padrão de comunicação para permitir a integração entre provedores e consumidores de
serviço; 3. Localização; 4. Definição de uma infraestrutura para ativar os serviços.
De acordo com o modelo de referência para Arquitetura Orientada a Serviços
OASIS (MACKENZIE et al., 2006) os principais conceitos do paradigma SOA são:
1. Visibilidade: Ocorre através da descrição do serviço onde contém as informações
necessárias para interagir com o serviço. A descrição do serviço comunica o que está sendo
consumado quando o serviço é invocado e as condições para usar o serviço.
2. Interação: Pode ser viabilizada por meio de troca de mensagens que ocorre através
de uma série de ações de troca de informações e invocações.
3. Efeito: Caracterizado como o retorno de uma informação ou a mudança no estado
de entidade que estão envolvidas numa interação.
A descrição do serviço representa uma das qualidades da SOA, facilitando a
interação e a visibilidade, particularmente quando os participantes estão em domínios
proprietários diferentes. Desta forma, o benefício da SOA está relacionada à facilidade no
gerenciamento do crescimento dos sistemas corporativos de larga escala reduzindo os custos
nas organizações.
Devido a esse crescimento e a diversidade de sistemas diferentes padrões
tecnológicos se destacam ao se tratar da SOA. Consequentemente, a integração desses
padrões nos apresenta um conceito vital: o barramento de serviços (Enterprise Service Bus do
original em inglês, ou Barramento de Serviços).
26
Uma solução ESB fornece uma variedade de benefícios, pois simplifica a tarefa de
conectar a diversidade de sistemas diferentes e melhora a agilidade do negócio fornecendo
integração de aplicativos. Sendo assim, facilita a comunicação entre aplicações construídas
em ambientes de desenvolvimento heterogêneos. (MARECHAUX, 2006). Este possui nove
características básicas. Descritas brevemente a seguir:
1. Invocação: É a capacidade de um ESB para enviar pedidos e receber respostas de
serviços de integração.
2. Roteamento: Tem como finalidade fornecer o destino de uma mensagem durante
o seu transporte.
3. Mediação: Refere-se a todas as transformações ou traduções entre recursos como
protocolo de transporte, o formato da mensagem e o seu conteúdo.
4. Adaptadores: Conectam as interfaces de transação e estrutura de dados e
apresentam uma interface padrão.
5. Segurança: Está relacionada à autenticação e controle de acesso através da
criptografia e a capacidade de decifrar o conteúdo das mensagens.
6. Gestão: Fornece a capacidade de registro da infraestrutura e controle da execução
do processo.
7. Processamento de orquestração: Inclui um mecanismo para executar processos de
negócios descritos com serviços web utilizando BPEL, controlando a descrição do processo,
em seguida, coordena a colaboração dos serviços ligados ao barramento.
8. Processamento de eventos complexos: Um ESB pode incluir mecanismos de
interpretação, correlação e correspondência do evento.
9. Ferramentas de integração: Para o desenvolvimento de ESB ferramentas de
implantação e testes devem estar disponíveis.
Devido aos benefícios e a competitividade muitas empresas têm adotado o uso de
SOA utilizando ESB, conforme mostra uma pesquisa realizada pelo Wintergreen com relação
ao ESB em escala mundial, sendo representada pela figura 1.
27
Figura 1: Mercado comparativo de ESB a nível mundial.
Fonte: (WINTERGREEN).
Ao analisarmos a figura 1 nota-se que de 2006 até 2013 há um crescimento
significativo do ESB no mercado corporativo. Para exemplificar, no ano de 2007 o mercado
mundial de ESB obteve 203,8 milhões de dólares e estima-se 494,4 milhões de dólares em
2013.
A próxima seção trata de descrever esta tecnologia, além de detalhes técnicos
relevantes para a execução deste trabalho de pesquisa.
2.1.1. WEB SERVICES
(MARZULLO, 2009) define um web services como um serviço que é
disponibilizado via Internet. Representa uma lógica de negócio em que um ou mais clientes
enviam requisições e recebem suas respostas. Desta forma, a capacidade de criar soluções
distribuídas e descentralizadas fornece à possibilidade de manter equipes de trabalho em
locais diferentes e operando simultaneamente.
Na literatura são apresentadas diversas definições de web services, no entanto, para
este trabalho vamos utilizar a definição utilizada pelo W3C (World Wide Web Consortium)
que consiste de:
Sistema de software que deve ser projetado para apoiar as interações máquina
a máquina em uma rede;
A interface deve ser descrita em WSDL (Web Service Description Language
do original em inglês, ou Linguagem para Descrever o Serviço Web).
Outros sistemas interagem com um determinado serviço utilizando mensagens
SOAP. As mensagens são trocadas através do protocolo HTTP (Hypertext Transfer Protocol
do original em inglês, ou Protocolo de Transferência de Hipertexto), com XML (Extensible
28
Markup Language, no original em inglês, ou Linguagem de Marcação), em conjunto com
outras tecnologias essenciais.
De uma forma mais simples, um web service é um serviço disponibilizado na
Internet, que utiliza WSDL, UDDI (Universal Description, Discovery and Integration do
original em inglês, ou Integração e Descoberta da Descrição Universal), SOAP (Simple
Object Access Protocol, no original em inglês, ou Protocolo Simples de Acesso a Objetos) e
XML o relacionamento entre esses principais padrões ocorre da seguinte forma: O primeiro
está relacionado com a descrição dos serviços sendo registrado utilizando UDDI, em seguida
utiliza SOAP para troca de mensagens entre as aplicações e finalmente os dados são
transmitidos via XML.
Os padrões básicos empregados no âmbito da tecnologia web são descritos
brevemente nas próximas seções: 2.1.2. Protocolo HTTP, 2.1.3.XML, 2.1.4. SOAP,
2.1.5. WSDL, e 2.1.6. UDDI;
2.1.2. PROTOCOLO HTTP
O protocolo padrão utilizado para transmissão de dados pela internet oferece uma
infraestrutura de comunição simples, permitindo uma ascensão rápida da tecnologia do web
service.
2.1.3. XML
A linguagem de marcação utilizada para armazenamento e transporte de dados. A
W3C define uma especificação rigorosa, onde são definidas as regras de criação de
documentos XML. A aceitação desse modelo está diretamente relacionada à sua
flexibilidade, pois permite a sua aprovação a um conjunto de ferramentas de desenvolvimento
que suportam e manipulam os documentos em XML (W3C-SCHOOL). A seguir algumas
características da XML conforme a W3C:
XML é uma linguagem de marcação parecida com a HTML.
XML tem como finalidade projetar os dados e não para exibi-los.
XML é uma recomendação da W3C.
As principais diferenças entre XML e HTML são:
XML não é uma substituição para HTML;
XML e HTML foram projetados com objetivos diferentes;
29
XML está focada no que é o dado. Em contrapartida, HTML foi projetada para
exibir os dados, ou seja, como estes dados aparecem.
XML foi criado para estruturar, armazenar e transportar a informação.
2.1.4. SOAP
SOAP é um protocolo baseado em XML para troca de mensagens. Em vez de definir
um novo protocolo de transporte, SOAP trabalha com HTTP, SMTP (Simple Mail Transfer
Protocol do original em inglês ou Protocolo de Transferência de Correio Simples)
e
MQSERIES.
De acordo com o W3C SOAP fornece uma forma de comunicação entre diferentes
aplicações com diferentes tecnologias e linguagens de programação. A mensagem SOAP
contém os seguintes elementos:
Um elemento envelope que identifica o documento XML como uma
mensagem SOAP.
Um elemento de cabeçalho.
Um elemento corpo que contém informações referentes à chamada e resposta.
Um elemento fault contendo os erros e informações de status.
A seguir um exemplo desta estrutura representada pela figura 2:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
Message information goes here
<soap:Header></soap:Header> <soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item></m:GetPrice>
<soap:Fault></soap:Fault> </soap:Body> </soap:Envelope>
Figura 2: Sintaxe mensagem SOAP
Fonte: (W3C SCHOOL).
O elemento envelope define o documento XML como uma mensagem SOAP. Além
da estrutura da mensagem, SOAP define um modelo que visa como os destinatários devem
processar as mensagens. A seguir uma breve descrição dos principais elementos
desconsiderando os elementos opcionais abordados no SOAP. A figura 2 mencionada
anteriormente exemplifica como seria uma resposta da requisição. Em contrapartida, a figura
3 ilustra como seria a resposta SOAP:
30
<?xml version="1.0"?> <soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body></soap:Envelope>
Figura 3: Elemento corpo resposta
Fonte: (W3C SCHOOL).
2.1.5. WSDL
A WSDL tem como finalidade obter a descrição de um web services, ou seja, define
o formato da mensagem, tipos de dados, protocolos de transporte que devem ser utilizados
entre o solicitante e o provedor. A figura 4 mostra documentos WSDL representando
aplicações web services.
Figura 4: Documentos WSDL
Fonte: (W3C SCHOOL)
Ao analisar a figura 4 nota-se que a camada de integração introduzida pela estrutura
de web service estabelece um padrão, universalmente reconhecido, permitindo a comunicação
entre essas camadas.
Web Services Description Language: descreve a interface de web services.
Universal Description, Discovery and Integration: define a maneira de
publicar e descobrir informações relacionadas aos web services.
O relacionamento entre protocolos e linguagens pode ser representado pelo esquema
a seguir exemplificado na figura 5.
31
Figura 5: Esquema representando os passos da utilização de um web services.
Fonte: (RIBEIRO, 2008)
Todo o processo pode ser descrito em seis passos:
1. Procura: o usuário realiza uma busca num site UDDI com a finalidade de
satisfazer as suas necessidades.
2. Descrição: o site retorna um ficheiro WSDL com a descrição de cada serviço.
3. Criação de Proxy: Em seguida um Proxy é criado para a realização do serviço
remoto.
4. Criar uma mensagem SOAP: A mensagem SOAP é criada e enviada para a URL
especificada no ficheiro WSDL.
5. Recepção: O receptor SOAP recebe o pedido, trata-o, interpreta-o e envia-o para o
web service.
6. Função: Uma função é executada e posteriormente é entregue o resultado ao
cliente.
O ciclo de vida de um web service compreende quatro estados. Descritos
brevemente a seguir:
1. Publicação: Neste processo o fornecedor do web service conhece a existência do
seu serviço, efetuando o registro do mesmo no repositório;
2. Descoberta: Por meio do qual uma aplicação do cliente conhece a existência de
um web service pesquisando um repositório UDDI;
3. Descrição: Inclui a linguagem padrão de mensagens SOAP;
32
4. Mensagens: Inclui o protocolo padrão de mensagem e extensões para o protocolo
SOAP (RIBEIRO, 2008).
A interação entre o web service acontece por meio de protocolos abertos. Os
protocolos utilizados são: UDDI, WSDL, XML, SOAP e HTTP, conforme a figura 6:
Figura 6: Protocolos utilizados
Fonte: (RIBEIRO, 2008)
O protocolo SOAP permite a interoperabilidade entre as diferentes plataformas. No
entanto, primeiramente as características são explicitadas por meio do WSDL e finalmente o
UDDI é utilizado para armazenamento em repositórios disponíveis na Internet. Descrito na
próxima seção.
2.1.6. UDDI
De acordo com Andrade (2002) o padrão UDDI trata-se de um repositório universal
de registros que contém todas as informações necessárias sobre as empresas que fornecem
serviços. Além disso, define a maneira de publicar e descobrir informações que estejam
relacionadas à web service.
A UDDI utiliza uma base de registros por meio de um formato XML. Essa base
contem três componentes. Descritos a seguir:
1.
Páginas brancas: contêm identificadores relacionados a um provedor de
2.
Páginas amarelas: incluem categorização com base em negócios e serviços;
serviço;
(categorias com base em um padrão).
3.
Páginas verdes: contêm informações específicas relacionadas aos serviços
(ANDRADE, 2002).
33
Esta seção apresentou os principais conceitos e elementos primordiais na arquitetura
orientada a serviços. Devido a sua flexibilidade e agilidade a SOA é capaz de responder
rapidamente as mudanças de acordo com a necessidade do negócio realizando um
alinhamento entre negócios e TI.
34
2.2. SOFTWARE COMO SERVIÇO
Por décadas as organizações utilizavam seu software em sua própria infraestrutura,
sendo responsáveis por todas as atividades a serem executadas. Com a evolução tecnológica
este cenário mudou estando relacionado com a ocorrência do aumento do fluxo de
informação, demandas cada vez maiores por inovações e ganho de competitividade e uma
visão estratégica de alinhamento entre TI e negócio (WU et al., 2012).
Neste novo cenário, está desenvolvendo muito rapidamente um modelo emergente
de comercialização de software, conhecido como SaaS (Software as a Service do original em
inglês ou Software como Serviço). Esse novo modelo, visa separar a propriedade do usuário e
a propriedade do fornecedor. Dessa forma, os clientes que adquirem esse novo modelo
usufruem de uma nova via de acesso a seu negócio e diversos benefícios como: flexibilidade,
redução de tempo, menores custos com licenças de software, redução de custos com
hardware, alta disponibilidade, segurança, manutenção, dados associados com o serviço é
mantido com o serviço. (WU et al., 2012).
Conforme apontado anteriormente SaaS proporciona diversos benefícios e devido a
estes benefícios as empresas estão recorrendo ao uso de SaaS, pois o cliente não precisa
adquirir hardware, licenças e outros requisitos, diminuindo o orçamento de uma implantação.
Com todas essas vantagens um estudo realizado pelo Gartner estima que o modelo
de software como serviço movimente 14,5 bilhões de dólares em todo o mundo, um
crescimento de 17,9% em comparação com o ano passado. Na América do Norte a receita de
software está prevista para totalizar US$ 9,1 bilhões em 2012, acima dos US$ 7,8 bilhões em
2011, apresentando a maior implantação de SaaS em gestão de despesas, finanças, e-mail e
suítes de escritório.
Na Europa Ocidental, a receita SaaS está prevista para ultrapassar US$ 3,2 bilhões
em 2012, acima dos US$ 2,7 bilhões em 2011, totalizando US$ 169,4 acima dos US$ 135,5
milhões do ano passado.
Com relação à Ásia estima-se US$ 934,1 em 2012 acima dos US$ 730,9 em 2011.
No geral, a adoção de SaaS na Ásia está fragmentada, pois é uma combinação de mercados
maduros, como a Austrália, Nova Zelândia, Hong Kong, Cingapura, Coréia do Sul e Taiwan
e os mercados emergentes, incluindo a China, Índia, Malásia, Tailândia, Indonésia, Vietnã e
Filipinas, onde as aplicações voltadas para SaaS financeiro são as mais populares,
especialmente na China e na Índia. O segundo maior uso de SaaS é para funções ERP (do
35
original em inglês Enterprise Resource Planning ou Planejamento de Recursos
Empresariais), tais como gestão de despesas e gestão do desempenho do colaborador.
Apesar da sua disseminação e dos diversos benefícios mencionados anteriormente as
empresas necessitam de prudência ao optarem pelo uso de SaaS, pois há necessidade de um
processo dentro da empresa, principalmente quando há necessidade de integração com outros
aplicativos e sistemas legados.
Analisando os dados obtidos observa-se a relevância do uso de SaaS e ressalta-se a
importância do entendimento do negócio, desta forma faz-se necessário o uso de BPM para
coordenar, compactar e entregar as ofertas de negócios assim como BPMN para a modelagem
dos processos (KAPURUGE, 2011).
Como conclusão deste subcapítulo o modelo SaaS apresenta uma excelente solução
para as empresas de TI que desejam obter um maior controle sobre seus custos e,
consequentemente sobre os lucros possibilitando níveis mais eficientes de controle,
principalmente com relação à forma de negociação do uso dos serviços e como as licenças
são distribuídas.
36
2.3. PROCESSO DE REFERÊNCIA DE NEGÓCIO
A decomposição do domínio é considerada o principal ponto de partida para uma
solução orientada a serviços. O domínio pode ser organizado em um processo de negócio
(HUHNS et al., 2005).
Kellner (1999) enfatiza que um processo é um conjunto de passos ordenados sendo
composto por atividades, ferramentas, métodos que definem o relacionamento entre as tarefas
e práticas que transformam entradas, ou matérias – prima, em produtos. Esta definição é
exemplificada na figura 7.
Figura 7: Dimensões crítica do processo.
Fonte: (adaptado de SEI- Software Engineering Institute, 2003).
A figura 7 mostra que os processos representam conjuntos de atividades
relacionadas
com
pessoas,
treinamento
e
motivação,
ferramentas,
equipamentos,
procedimentos e métodos que definem o relacionamento das tarefas esses estão interligados
para que o objetivo final seja alcançado.
Um processo está diretamente relacionado a um conjunto de atividades, que indicam
o seu início e o seu fim fornecendo informações sobre as atividades, os stakeholders, as
tecnologias e os dados que estão vinculados, isto permite identificar os componentes que
estão relacionados aos processos, recursos utilizados e políticas internas e externas.
Dentro desse contexto, processo de referência consiste no mapeamento detalhado
das informações com relação a um determinado padrão auxiliando na identificação dos
gargalos e proporcionando melhorias nos processos informais adotados (BASS et al., 2003).
37
A modelagem do processo de negócio está sendo aceita em grande escala com o
objetivo de identificar as falhas, atividades duplicadas ou desnecessárias, pessoa sem
capacitação e, além disso, facilita no desenvolvimento sendo uma ferramenta gerencial e de
comunicação que ajuda a melhorar os processos existentes, ou a implantação de uma nova
estrutura, auxiliando a empresa a identificar claramente os pontos fortes e os pontos fracos
(SARA. R; SAVÉN. A, 2003).
Neste trabalho, processo é considerado o principal elemento na engenharia de
requisitos estando agregada a qualidade do processo e do produto, a estrutura organizacional
incluindo pessoas, recursos, tecnologias, procedimentos e os produtos resultantes desses
processos.
Outro conceito que está diretamente relacionado a processos é BPMN. Segundo o
BPMI (Process Management Institute) BPMN fornece às empresas a capacidade de
compreender os seus procedimentos internos de negócios em uma notação compreensível por
todos os stakeholders.
Um dos objetivos da BPMN é criar um mecanismo para o
desenvolvimento dos modelos dos processos com o intuito de obter um maior entendimento.
Para manter a notação padrão foi realizado um acordo entre os fornecedores da ferramenta
para utilizarem a mesma notação, sendo apoiada por muitas das maiores empresas de
software do mundo, como IBM, Microsoft, Oracle e Sybase.
Existem diversas ferramentas disponíveis no mercado para notação de processos de
negócios, entre elas podemos destacar: TIBCO, BizAgi Xpress e ACTIVITI são as mais
utilizadas para modelagem de processos essas ferramentas possuem o BPMS (Business
Process Modeling Suite) que consiste de um pacote de software que serve para automatizar os
processos e as atividades em BPMN. A principal diferença entre uma ferramenta e a outra
está relacionada à simulação, desempenho, avaliação e análise dos processos. Entre as
diversas ferramentas mencionadas anteriormente a ferramenta BizAgi Xpress e JBPM foram
escolhidas para a concepção do processo de referência proposta neste trabalho. Desta forma,
a descrição dos elementos nesta dissertação foi embasada em uma pesquisa bibliográfica,
sobretudo a partir de obras de White (2010) e Reis (2011), no entanto, buscou-se obter maior
ênfase na norma oficial da notação da OMG (2011).
Na BPMN dividiram-se os elementos em: 1. objetos de fluxos, 2. objetos de
conexão, 3. swimlanes e 4. artefatos. Descritos brevemente a seguir:
38
1. Objetos de fluxos: Definem o comportamento do processo de negócio. A tabela 2
apresenta os principais eventos.
Elemento
Descrição
Atividade
Ações que devem ser realizadas em um processo.
Evento
Ocorrem durante o fluxo do processo. Podendo ser: (1) start,
(2) intermediate e (3) end. O primeiro está relacionado ao
início do fluxo no processo. O segundo ocorre durante o
fluxo e o terceiro finaliza um fluxo.
Gateway
Controla a convergência e divergência do fluxo.
Notação
1
2
3
Tabela 2: Fluxos principais
Fonte: (OMG)
2. Objetos de conexão: Conectam objetos de fluxos. Estes são divididos em: 1.
fluxo de sequência, 2. fluxo de mensagem e 3. associação. Conforme ilustra a tabela 3.
Elemento
Descrição
Fluxo de sequência
È utilizado para mostrar a ordem (sequência)
que as atividades serão realizadas em um
processo.
Fluxo de mensagem
Exibi o fluxo de mensagem entre dois ou mais
participantes do processo separado.
Associação
Tem como finalidade associar texto e outros
artefatos
Tabela 3: Objetos de conexão
Fonte: (OMG)
Notação
3. Swimlanes: São entidades que tem como finalidade agrupar elementos pools e
lanes, permitindo particionar um diagrama BPMN de acordo com seus responsáveis. Sendo
assim, permite informar onde serão executadas. A tabela 4 apresenta a notação dos pools e
lanes assim como uma breve descrição.
Elemento
Descrição
Pool
Representa um participante e suas atividades no
processo.
Lanes
È uma subpartição dentro de um pool, sendo
utilizada para separar participantes dentro de
uma mesma organização.
Tabela 4: Pools e Lanes
Fonte: (OMG)
Notação
39
4. Artefatos: Os artefatos são utilizados para fornecer informações adicionais sobre o
processo. Esses são divididos em três grupos: 1.dados, 2. grupo e 3.anotação. Exemplificados
a seguir na tabela 5:
Elemento
Descrição
Dados
Mecanismo que visa mostrar como os dados são
necessários ou produzidos pelas atividades.
Grupo
È utilizado para fins de documentação ou de
análise, mas não afeta o fluxo de sequência.
Anotação
Mecanismo que visa proporcionar informação
adicional para o texto.
Tabela 5: Elementos dos artefatos
Fonte: (OMG)
Notação
Os processos em BPMN facilitam o entendimento e a comunicação entre os
stakeholders. Assim os três subprocessos existentes na BPMN são apresentados a seguir:
1. Processo interno: Este é o tipo de processo mais comum, composto por uma
série de atividades que são realizadas unicamente dentro de uma empresa.
2. Processo abstrato: O processo inclui atividades que são realizadas fora da
empresa, ou seja, não há uma gerência sobre a execução destas atividades.
3. Processo de colaboração: Descrevem processos e as interações entre duas ou
mais entidades de negócios.
Uma das vantagens com relação à BPMN é o desenvolvimento de sistemas baseados
em serviços, pois fornece uma notação gráfica para modelagem de coreografia (descreve as
interações entre duas ou mais entidades empresariais), sendo assim, torna-se fundamental o
uso de BPEL para o desenvolvimento de web services.
Segundo (RIBEIRO, 2008) há dois tipos de combinação possível para web service, à
orquestração e a coreografia. A primeira é mais utilizada em processos de negócios privados,
onde há um processo central, normalmente um web service que controla e coordena todas as
operações, ou seja, somente o web service central controla todas as operações e a ordem de
invocação dos web services envolvidos. Por outro lado, na coreografia não há necessidade de
um web service central, pois todos os web services sabem quais são os web services que
devem interagir e quando deve executar as suas operações.
40
Para um maior entendimento a tabela 6 apresenta as atividades básicas e as
atividades estruturadas da BPEL assim como uma pequena descrição de cada atividade.
Atividade
Básica
<invoke>
<receive>
<reply>
<throw>
<wait>
<empty>
<exit>
Descrição
Chama um serviço externo.
Atividade
Estruturada
Descrição
<if>
Executa uma atividade com base uma
ou mais condições.
Recebe entrada de serviços.
<while>
Executa uma atividade repetidamente
Envia respostas de serviços
<repeatUntil> Executa repetidamente até que a sua
condição seja verdadeira.
Lida com falhas durante o processo de <pick>
Contém ao menos uma mensagem.
execução do processo, sinalizando as
Quando esta atividade é executada
que ocorrem no seu scope.
bloqueia o processo até que a
mensagem seja recebida.
Pausa o fluxo do processo de negócio <flow>
Executa as atividades dentro do seu
durante um determinado período.
scope em paralelo.
Sincroniza atividades concorrentes.
<sequence>
Define
atividades
que
serão
invocadas.
Termina um processo
<scope>
Contexto para um conjunto de
atividades.
Tabela 6: Resumo das atividades BPEL.
Fonte: (RIBEIRO, 2008)
Além de proporcionar a automatização dos processos, BPEL pode ser utilizado de
duas maneiras: dentro da corporação (intranet) e entre as corporações (internet). A primeira
está relacionada com a padronização e integração das aplicações corporativas. A segunda visa
à integração fácil e eficiente entre os parceiros.
Como conclusão deste subcapítulo nota-se a importância do entendimento do
negócio por meio do mapeamento e modelagem dos processos, pois este permite identificar
de uma forma detalhada todas as atividades relacionadas a um processo auxiliando na
engenharia de requisitos. Além disso, foi apresentado um conceito fundamental que está
interligado ao uso da BPMN que é BPEL proporcionando uma automatização dos processos
facilitando o desenvolvimento dos sistemas baseados em web services.
41
2.4. ENGENHARIA DE REQUISITOS
Um requisito é uma característica do sistema ou a descrição do que o sistema é
capaz de realizar, com a finalidade de atingir o seu objetivo, sendo assim, é fundamental para
o bom desenvolvimento de software (PRESSMAN, 2011).
A engenharia de requisitos distingue de uma forma clara e precisa requisitos de
usuários e requisitos de sistema podendo ser definidos da seguinte maneira:
1. Requisitos de usuários: são declarações em uma linguagem natural com
diagramas, de quais serviços são esperados e sob quais restrições deve operar.
2. Requisitos de sistema: Definem detalhadamente, as funções, os serviços e as
restrições operacionais (BOURQUE, 2004).
Além dos requisitos mencionados anteriormente há os requisitos funcionais e não
funcionais descritos a seguir:
Requisitos funcionais: Estão diretamente relacionados à funcionalidade do
software, ou seja, descrevem as funções que o software deve realizar.
Requisitos não funcionais: Consiste nas qualidades específicas que o software
deve ter. Essas qualidades estão de acordo com a norma ISO 9126 que está relacionada à
qualidade do produto de software que propõe atributos de qualidade distribuídos em categoria
A partir de uma breve definição de requisitos é possível definir engenharia de
requisitos como uma abordagem inserida no contexto de engenharia de software onde as
atividades estão diretamente relacionadas à produção de uma descrição minuciosa de um
software a ser construído. No entanto, entender precisamente os requisitos de software e as
necessidades dos clientes tem sido um dos principais desafios na área de engenharia de
software. A engenharia de requisitos auxilia os engenheiros de software a lidar com os
diversos tipos de problema relacionados aos requisitos (PRESSMAN, 2011).
A engenharia de requisitos consiste de sete etapas distintas: 1. Concepção, 2.
Levantamento, 3. Elaboração, 4. Negociação, 5. Especificação, 6. Validação e 7. Gestão.
Descritas brevemente a seguir:
1.
Concepção: Consiste na definição do escopo e da natureza do problema.
2.
Levantamento: Consiste em reuniões com os principais stakeholders com o
objetivo de identificar quais são os principais objetivos do sistema e como este se encaixa nas
necessidades do negócio.
42
O levantamento de requisitos parece uma tarefa fácil, porém é uma tarefa difícil,
pois diversos problemas podem ocorrer durante o levantamento, entre eles, destacam-se:
Problemas de escopo: Este tipo de problema ocorre quando o limite do sistema
não foi informado corretamente ou quando o cliente/usuário fornece detalhes técnicos
supérfluos.
Problemas de entendimento: Ocorre quando o cliente/usuário não tem certeza
da sua necessidade, omite informações que parecem ser "óbvias" e/ou não tem o
conhecimento necessário sobre o domínio do problema.
Problemas de volatilidade: Os engenheiros mudam ao longo do tempo.
3.
Elaboração: As informações obtidas nas etapas realizadas anteriormente são
expandidas e refinadas na etapa de elaboração que está focada nas características e restrições
do software.
4.
Negociação: Conflitos de requisitos podem ocorrer durante todas as etapas
sendo assim, engenheiros de requisitos devem elaborar um documento de negociação que tem
como finalidade minimizar os conflitos entre os stakeholders.
5.
Especificação: A especificação de requisitos pode ser considerada como uma
das principais etapas para a realização deste trabalho. No entanto, apesar da sua importância o
principal objetivo dessa dissertação é fornecer mecanismos para a elaboração do documento
de requisitos. Dessa forma, uma especificação pode ser um documento escrito, um modelo
gráfico ou qualquer combinação desses elementos que permite identificar as restrições e
desempenho que governarão o desenvolvimento.
Existem dois tipos de padrões propostos pela IEEE somente para especificação de
requisitos. São eles:
IEEE STD 830-1998 Recommended Practices for Software Requirements
Specification (Práticas Recomendada para a Especificação de Requisitos de Software). As
práticas recomendadas têm a finalidade de descrever os caminhos para a especificação de
requisitos.
IEEE Guide for the Development os Systems Requirements Specifications
(Guia para o Desenvolvimento de Especificações de Requisitos de Sistema). Este guia provê
orientações para a identificação de requisitos assim como a maneira de organizá-los.
6.
Validação: Esta etapa tem como finalidade verificar se os requisitos
identificados nas etapas anteriores foram declarados de modo não ambíguo, pois os erros em
43
um documento de requisitos podem levar a custos excessivos de retrabalho quando estes são
descobertos na etapa de desenvolvimento (SOMMERVILLE, 2011).
7.
Gestão de requisitos: Devido à mudança de requisitos que ocorrem durante o
projeto há necessidade de gerenciar essas mudanças. A gestão de requisitos proporciona a
identificação, controle e modificação dos requisitos.
Como conclusão desse subcapítulo pode-se notar que a engenharia de requisitos
contém atividades que estão diretamente relacionadas com o entendimento e a produção de
um documento de requisitos.
44
2.5. MODELO DE REQUISITO
Este capítulo apresenta um modelo de engenharia de requisitos estabelecido pela
ISO/IEC. Este modelo foi escolhido pelo fato de ser mais completo para o escopo deste
trabalho.
2.5.1. INTERNATIONAL STANDARD ISO/IEC/IEEE 29148:2011 SYSTEMS AND
SOFTWARE ENGINEERING LIFE CYCLE PROCESSES – REQUIREMENTS
ENGINEERING
Este padrão tem como objetivo apresentar processos e produtos relacionados à
engenharia de requisitos apresentando todo o seu ciclo de vida. No entanto, para atingir o
objetivo deste trabalho será apresentado somente o documento de requisitos. Esse consiste
dos seguintes elementos:
1. Propósito: Apresenta o objetivo do software a ser especificado.
2. Escopo: Define o que o produto deve fazer e descreve a aplicação do software.
3. Funções do produto: Fornece um resumo das funções do software.
4. Características de usuário: Descreve as características dos usuários do produto.
5. Limitações: Fornece uma descrição do que pode limitar o fornecedor.
6. Hipótese e dependência: São os fatores que podem afetar os requisitos no
documento de requisitos.
7. Requisitos específicos: Deve conter todos os requisitos de software devidamente
detalhados para que possa permitir o desenvolvimento de software.
8. Interfaces externas: Deve conter todas as entradas e saídas para o sistema de
software.
9. Requisitos de usabilidade: Define a qualidade de uso dos requisitos.
10. Requisitos de desempenho: Deve conter exigências numéricas do software.
11. Requisito de banco de dados lógico: São os requisitos lógicos para que
posteriormente estes possam ser colocados numa base de dados.
12. Restrições: Deve conter restrições sobre o projeto do sistema.
13. Padrões de conformidade: Deve conter os requisitos derivados de normas.
14. Atributos do sistema de software: Contem os atributos necessários do produto de
software.
15. Verificação: Contem as abordagens de verificação com o objetivo de qualificar o
software.
16. Informações: O documento de requisitos deve fornecer informações adicionais.
45
3. TRABALHOS RELACIONADOS
Neste capítulo serão abordados trabalhos que estejam relacionados ao presente
trabalho. Tais como: (Vieira et., 2012; Dias et.al, 2006; Xavier et. al, 2010; Dijkman, 2002;
Liew, 2004; Rodriguez, 2011 e Okama, 2007).
3.1. EXTRAÇÃO DE REQUISITOS DE SOFTWARE
Como apresentado anteriormente os requisitos de software podem ser funcionais ou
não funcionais. Dessa forma, a abordagem proposta por (Vieira et al., 2012) utiliza a técnica
REMO (Requirements Elicitations oriented by business Process Modeling) para identificar
requisitos e regras de negócios. Essa técnica faz uso de heurísticas para extrair requisitos
funcionais, não funcionais e regras de negócios identificando primeiramente os elementos da
BPMN para posteriormente aplicar à heurística e obter os requisitos.
Outra abordagem proposta por (Dias et al., 2006) apresenta uma técnica para
facilitar na especificação de requisitos. Para atingir esse objetivo apresenta uma ferramenta
que permite a transformação do modelo de negócios em modelo de requisitos. Tal abordagem
é composta por duas etapas: a primeira faz uso de heurística em um processo de aluguel de
carros. Esse processo é representado através do diagrama de atividades. Na segunda etapa o
processo é transformado automaticamente em um diagrama de caso de uso. Para isso o autor
propôs o desenvolvimento de uma ferramenta denominada RAPDIS.
Em (Xavier et al., 2010) é proposto uma extensão para BPMN utilizando RNF.
Nessa nova abordagem denominada BPMNFR utiliza-se catálogos de requisitos de um
framework. Tal método consiste de quatro etapas: 1. modelagem do processo de negócio,
2. inserção de rótulos nas atividades, 3. criação de catálogos de RNF e 4- inserir as
operacionalizações no modelo. Na primeira etapa é realizada a modelagem dos processos de
negócio. A segunda etapa consiste na identificação dos RNF de acordo com o domínio e
relacioná-los de acordo com cada atividade com seus rótulos. Posteriormente, há necessidade
de relacionar os RNF com as operacionalizações para isso utiliza-se o NFR framework.
46
3.2. ESPECIFICAÇÃO DE CASO DE USO
O trabalho proposto por Dijkman (2002) é um dos primeiros a tratar da
transformação da BPMN para caso de uso. Nesse trabalho são apresentados novos conceitos
como papel e passo. O primeiro está relacionado ao ator de uma determinada atividade. Em
contrapartida, o segundo refere-se ao conjunto de atividades que são realizadas. O
mapeamento dos processos é realizado no diagrama de atividades. Dessa forma, são
considerados os seguintes elementos da BPMN:
1. Connection (sequence flow), 2. Gateway (exclusive), 3. Intermediate events, 4. Start event
e end event, 5. Tasks. Descritos brevemente a seguir:
3.2.1. Connection
Na BPMN há diversos tipos de elementos para caracterizar um connection. No
entanto, no trabalho apresentado será analisado o sequence flow que identifica o fluxo de
sequência entre as atividades. Em contrapartida, no diagrama de caso de uso o fluxo de
mensagem é representado pela associação entre atores e casos de uso.
3.2.2. Gateway
A exclusive gateway representa "sim" ou "não" dada uma determinada condição. No
entanto, em diagrama de caso de uso o extend representa um comportamento opcional de um
caso de uso. Dessa forma, é possível realizar uma relação entre a BPMN e o diagrama de
caso de uso.
3.2.3. Intermediate events
São eventos temporais esses podem ocorrer anexados a uma atividade ou no fluxo
do processo. A primeira indica que algo pode ocorrer no decorrer da execução de uma
determinada atividade. A segunda indica que são precedidos por outro elemento da BPMN.
3.2.4. Start event e End event
Em BPMN um evento de início indica onde inicia o processo. Esses podem ser
acionados por diversas causas.
3.2.5. Tasks
Há diversos tipos de elementos na BPMN que caracterizam as atividades. Para
exemplificar há atividades que podem ser executadas por um usuário, atividades sistêmicas e
manuais, sendo assim, há necessidade de identificar o tipo de atividade que será executada.
47
O método apresentado acima apresenta uma relação entre a BPMN e o diagrama de
caso de uso, no entanto, apesar da sua relevância limita-se pelo fato de não representar todas
as atividades da BPMN que devem ser transformadas em caso de uso.
Com base no método proposto acima nesta dissertação será apresentada um método
para transformar BPMN em diagrama de caso de uso. A transformação da BPMN para
diagrama de caso de uso ocorrerá da seguinte maneira:
Cada participante encontrado na BPMN será transformado em ator no diagrama de
caso de uso. Em contrapartida, cada atividade sistêmica encontrada na BPMN será
transformada em caso de uso.
Liew (2004) propõe uma transformação de modelos BPMN para diagrama de casos
de uso. Esse trabalho é uma extensão do trabalho proposto por Dijkman, com a diferença que
a modelagem no trabalho de Dijkman é realizada utilizando diagrama de atividades. Nesta
etapa será exemplificado o diagrama de caso de uso através do subprocesso emissão de
poluentes, pois no estudo de caso proposto há necessidade de mais de um participante.
A tabela 7 exemplifica o método proposto para elaboração do diagrama de caso de
uso do subprocesso emissão de poluentes.
Elemento BPMN
Elemento UML
Lane
Para cada lane identificada no processo substituir por um ator.
Atividade
As atividades devem ser substituídas por um caso de uso.
Evento de Fim
Para cada evento de fim. Deve-se substituir por uma atividade.
Artefatos
Os artefatos que servem de entrada para uma determinada atividade devem ser
transformados em pré-condições na descrição do caso de uso. Em contrapartida, os
artefatos que servem de saída devem ser transformados em pós- condições na descrição do
caso de uso.
Tabela 7: Transformação da BPMN para diagrama de caso de uso
Fonte: (adaptado de Liew, 2004)
Um exemplo da transformação da BPMN para diagrama de caso de uso pode ser
representado nas figuras 8 e 9 a seguir:
48
Figura 8: Subprocesso emissão de poluentes
Fonte: (Leal, 2014)
Figura 9: Caso de uso emissão de poluentes
Fonte: (adaptado de Liew, et al., 2004).
3.3. ESPECIFICAÇÃO DE ATIVIDADE
No trabalho apresentado por Rodriguez (2011) parte de um modelo inicial em
BPMN que posteriormente é modelado em diagrama de atividades que dá origem ao
diagrama de classes e ao diagrama de caso de uso da UML. A transformação realizada entre
uma BPMN e um diagrama de atividades ocorre da seguinte forma: cada participante
modelado em um pool ou lane é transformado em uma partição de atividades. As tarefas são
representadas por uma ação. O fluxo de mensagem corresponde ao fluxo de objeto e os
objetos de dados e os eventos iniciais e finais são representados por datastores, nodo de
início e nodo final respectivamente.
49
3.4. ESPECIFICAÇÃO DE CLASSES
Em OKAMA (2007) é proposto um método para realizar a transformação de BPM
para diagrama de classes. Com o objetivo de verificar o método proposto foi realizado um
estudo de caso de uma reserva de autocarros e um sistema de gestão. O método proposto pelo
autor é divido em quatro etapas. Na primeira etapa é realizada a modelagem inicial dos
processos de negócios conhecida como As is. Na próxima etapa, é realizada a melhoria
desses processos conhecida como To be. Posteriormente, é realizada a simulação de cada
processo com o objetivo de verificar as melhorias e possíveis correções. Finalmente, é feita a
transformação de cada processo em diagrama de classes. Essa transformação está dividida em
quatro etapas. Descritas brevemente a seguir:
1. Cada processo de negócio é associado a uma única classe.
2. Os dados obtidos devem ser tratados como atributos do diagrama de classes.
3. Os elementos devem ser tratados como métodos da classe.
4. Verificar os elementos que são comuns às classes.
3.5. TRABALHOS RELACIONADOS
Os trabalhos apontados anteriormente utilizam os seguintes diagramas: caso de uso,
atividades e classes o seu uso justifica-se pelo fato de serem os diagramas que mais se
aproximam para obter os requisitos. No entanto, apesar da sua proximidade os dois primeiros
trabalhos proposto com Vieira et al., (2012) e Dias et al., (2006) faz uso de heurísticas para
identificação de requisitos e regras de negócios. O primeiro trabalho utiliza a BPMN em
contrapartida o segundo trabalho utiliza o diagrama de atividades. Apesar da sua importância
estes trabalhos não apresentam detalhes com relação a elementos mais complexos da BPMN.
Além disso, seria interessante expandir o uso da ferramenta para outros padrões.
O trabalho proposto por Liew (2004) utiliza BPMN para diagrama de caso de uso,
no entanto, apesar da sua importância é um trabalho limitado, pois faz uso de apenas um
participante no processo. Além disso, o evento de fim da BPMN não é caracterizado no
diagrama de caso de uso.
Os trabalhos mencionados foram citados nesta dissertação pelo fato de se
aproximarem da extração de requisitos, no entanto, a melhoria proposta neste trabalho é o uso
da BPMN para modelagem de processos sendo que a partir dela é possível extrair os
requisitos funcionais, não funcionais, regras de negócios. Além disso, é possível verificar até
50
que ponto a BPMN auxilia na engenharia de requisitos com relação à especificação de
requisitos. O capítulo a seguir apresenta o método proposto.
51
4. PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA
ENGENHARIA DE REQUISITOS EM SOA
A fim de oferecer uma alternativa mais consistente para a engenharia de requisitos
em SOA este trabalho propõe uma solução baseada na aplicação de processos de negócios. O
método faz uma análise dos elementos da BPMN e posteriormente uma comparação com
cada elemento encontrado na ISO/IEC/IEEE 29148:2011 para a especificação de requisitos.
A escolha da BPMN e BPM justifica-se pelo fato de entender precisamente o domínio do
problema, minimizando assim, os erros encontrados na etapa de desenvolvimento, pois está
atrelada a TI, ou seja, permite um melhor alinhamento entre a equipe de negócio e a TI, pois
pode minimizar as falhas encontradas no desenvolvimento. Dessa forma, esta dissertação atua
em duas frentes: utilizar BPMN para proporcionar o alinhamento entre negócio e TI e
analisar até que ponto a BPMN auxilia na especificação de requisitos.
Para experimentar o método proposto foi realizado um estudo de caso denominado
design sustentável extraído do trabalho de Santana, 2012, no entanto, a modelagem dos
processos As is foi adaptado para que pudesse atender o método proposto utilizando a
BPMN.
As etapas apresentadas a seguir foram desenvolvidas após estudos de diversas
referências bibliográficas encontradas na literatura: 1. Entender o domínio do problema, 2.
Entender a estrutura proposta 3. Realizar a modelagem dos processos de negócios As is, 4.
Estratégia organizacional, 5. Realizar a modelagem dos processos de negócios To be, 6.
Identificação dos requisitos e 7. Especificação. A figura 10 exemplifica esse processo.
52
Figura 10: Método proposto
53
1. Entender o domínio do problema:
O primeiro passo fundamental para a
modelagem dos processos de negócios é entender o domínio do problema, ou seja, quais são
as reais necessidades. Dessa forma, é possível ter um maior entendimento de quais processos
de negócios são de fato importantes para atingir objetivos estratégicos.
2. Entender estrutura organizacional: Consiste no entendimento da estrutura
organizacional através do organograma onde é possível verificar os principais papéis da
organização. Além disso, permite identificar os principais stakeholders para que
posteriormente possa ser elaborada a modelagem dos processos de negócios. No entanto,
apesar da sua relevância dificilmente uma estrutura organizacional é documentada. Dessa
forma, torna-se importante a realização da modelagem dos processos de negócios para que
possam permitir o entendimento da estrutura organizacional, assim como os principais
stakeholders. O trabalho proposto nesta dissertação faz uso de um estudo de caso, sendo
assim, para realizar esta etapa foram necessárias pesquisas que pudessem propor
uma
estrutura dentro do escopo deste trabalho.
3. A modelagem dos processos de negócios As is: Essa é iniciada através do As is
(está relacionado com o funcionamento atual da organização) e o To be (realizado após a
modelagem do As is com o intuito de propor melhorias ao processo).
4. Validar a modelagem: Após a etapa de modelagem As is é realizada a validação
dos processos que foram modelados juntamente com os principais stakeholders.
5. Verificar a estratégia: A estratégia tem como finalidade verificar os principais
objetivos e determinar políticas, normas, regras de negócios, para atingir os objetivos.
6. A modelagem dos processos de negócios To be: Esta etapa visa redesenhar o
processo obtido na etapa As is, porém é realizada uma análise com o objetivo de acrescentar
melhorias ao processo modelado. Nesta etapa são identificadas pessoas sem capacitação.
Além disso, atividades duplicadas e/ou desnecessárias são excluídas.
7. Validar modelagem To be: Após a etapa de modelagem To be é realizada a
validação dos processos que foram modelados juntamente com os principais stakeholders.
8. Extração de requisitos funcionais e não funcionais: O método para extração de
requisitos funcionais e não funcionais propostas neste trabalho faz uso da técnica REMO para
extração de requisitos. O primeiro passo consiste na identificação dos elementos da BPMN.
Posteriormente, é feita a aplicação das instruções de cada heurística.
9. Verificar a especificação: Nesta etapa é realizada a comparação da BPMN com a
ISO/IEC/IEEE 29148:2011.
54
10. Realizar implementação: Consiste em implementar os processos de negócios To
be.
A tabela 8 a seguir apresenta os principais elementos da BPMN assim como as suas
heurísticas.
Tabela 8: Principais elementos da BPMN e suas heurísticas
Fonte: (adaptado de VIEIRA, 2012)
55
5. APLICAÇÃO DO MÉTODO
Para avaliar e experimentar o método proposto será apresentado um estudo de caso
denominado design sustentável. A principal motivação para a escolha do estudo de caso
abordando design sustentável justifica-se pelas alterações climáticas o que tem levado ao
estabelecimento de restrições legais e comerciais para o desenvolvimento de produtos e
serviços com a finalidade de aumentar a sustentabilidade.
O SD é uma atividade bastante complexa, pois um dos seus principais desafios é
utilizar conceitos PSS (Product Service Systems) e LCA (Life Cycle Assessment) para avaliar
o impacto causado por um produto sobre o meio ambiente. Dessa forma, torna-se viável o uso
de ferramentas de software que possam fornecer apoio na análise e avaliação de aspectos
quantitativos, no entanto, será necessário recurso de integração e interoperabilidade com
outros sistemas (MANZINI, 2003). Dessa forma, torna-se viável o uso da SOA que tem como
ponto de partida a definição de um processo de referência com o objetivo de fornecer um
entendimento claro das tarefas que devem ser executadas.
O processo de referência design sustentável faz uso do LCA, ou seja, tem como
finalidade analisar, medir e propor melhorias com o intuito de eliminar ou reduzir os
impactos ambientais sem comprometer as necessidades das gerações futuras. Além disso, a
LCA tem como objetivo verificar o ciclo de vida de um determinado produto desde a fase de
extração, aquisição, produção, distribuição e descarte.
O estudo de caso proposto neste trabalho consiste de sete etapas: 1. Entender o
domínio do problema:
Esta etapa foi realizada através de pesquisas que evidenciam a
importância do design sustentável. 2. Entender a estrutura organizacional: A estrutura
organizacional proposta foi realizada através do entendimento do domínio do problema e com
base em pesquisas referente ao assunto, sendo assim, foi possível identificar os principais
participantes do processo. A figura 11 apresenta a estrutura proposta e a figura 12 apresenta a
estrutura proposta utilizando a ferramenta BizAgi Xpress .
56
Figura 11: Estrutura proposta
Fonte: (Leal, 2014)
A figura 11 apresenta a estrutura proposta. Tal estrutura foi realizada de forma
manual.
Figura 12: Estrutura proposta BizAgi Xpress.
Fonte: (Leal, 2014)
Dessa forma, foi possível identificar oito participantes. Descritos brevemente a
seguir:
1. Pesquisador 1: Neste trabalho o participante denominado pesquisador 1 realiza
uma pesquisa e análise do mercado com o objetivo de verificar as principais necessidades.
2. Pesquisador 2: È responsável por planejar e executar a pesquisa de mercado
realizada pelo pesquisador 1.
3. Engenheiro de produção: O engenheiro de produção define a melhor forma de
integrar mão de obra, equipamentos e matéria prima, com o objetivo de fornecer melhor
qualidade e aumentar a produtividade.
4. Ecologista: È responsável por pesquisar e estudar a diminuição dos efeitos da ação
do homem contribuindo significativamente para a compreensão e preservação da
biodiversidade, conduz pesquisas, aplica o conhecimento obtido para solucionar problemas
ambientais.
57
5. Engenheiro ambiental: Responsável por desenvolver tecnologias para proteger o
ambiente dos danos causados pelas atividades humanas. Além disso, tem como função
preservar a qualidade da água, do ar e do solo.
6. Gerente de logística: Responsável pelo armazenamento, compras, distribuição e
entrega de produtos. Além disso, determina o tipo de transporte a ser utilizado (ferroviário,
rodoviário e aeroviário) assim como o cálculo do frete a embalagem que será utilizada.
7. Analista de TI: Responsável por desenvolver as funcionalidades necessárias.
8. Gerente de TI: Responsável por gerenciar as funcionalidades estabelecidas.
Após esta etapa, foi realizada a modelagem do As is e a modelagem To be.
5.1. AS IS
Conforme mencionado anteriormente, o As is corresponde à modelagem atual dos
processos ,ou seja, como estes estão estruturados atualmente. Dessa forma, por meio da
modelagem é possível identificar os principais gargalos, atividades duplicadas, pessoal sem
capacitação. Uma das formas de obtê-lo é por meio de entrevistas com a pessoa responsável
pelo processo, no entanto, torna-se desaconselhável, por considerar a visão de uma única
pessoa. A técnica mais utilizada é realizar uma reunião com todos os stakeholders para
realizar o mapeamento e documentar o processo.
Neste trabalho a modelagem inicial, ou seja, o As is foi retirado do trabalho de
(SANTANA, 2012) , no entanto, mesmo representando o As is houve melhorias nesta etapa.
O orquestrador é considerado o processo principal. Este consiste de cinco subprocessos e sete
atividades. Descritas brevemente a seguir:
1. Demanda de mercado: Informações de mercado com relação ao nível de
necessidade do público alvo quanto a este produto/serviço;
2. Subprocesso serviços: Informações relevantes da matéria prima (referente à sua
extração, origem e transporte) para a produção. No entanto, caso não haja a presença de
matéria prima nociva ou não renovável buscar a substituição;
3. Subprocesso Produtos: Informações relevantes da matéria prima (referente à sua
extração, origem e transporte) para a produção. No entanto, caso não haja a presença de
matéria prima nociva ou não renovável buscar a substituição;
4. Supply Chain Management: Visa realizar um planejamento do gerenciamento da
cadeia de abastecimento com o objetivo de regular os gastos da matéria prima para uma
quantidade mínima necessária;
58
5. Subprocesso simplificação do ciclo de vida: Com base nas informações adquiridas
com relação ao consumo de matéria prima deve-se determinar uma avaliação simplificada do
impacto gerado pela produção;
6. Produção: Aperfeiçoar a produção e diminuir/eliminar os gastos e os desperdícios;
7. Distribuição: Avaliar se o transporte do produto ou serviço é realmente necessário
até chegar ao consumidor;
8. Consumo: Eliminar/reduzir a produção do lixo gerado com as embalagens assim
como o seu gasto;
9. Subprocesso reduzir/eliminar: Após a utilização do produto/serviço há
necessidade de determinar uma destinação final, ou seja, avaliação de reparo para
reutilização, ou se podem ser descartados com ou sem tratamento;
10. Avaliação do ciclo de vida: Avaliação do impacto ambiental;
11. Enviar mensagem: Consiste na verificação da destinação escolhida e caso seja
insatisfatória a mensagem será enviada para mudar o tipo de destinação. A figura 13
exemplifica este processo.
59
Figura 13: Macro processo
Fonte: (adaptado de SANTANA, 2012).
60
Os subprocessos serviço e produtos têm como finalidade realizar a extração do
etanol. Esses subprocessos são formados pelas seguintes atividades:
1.
Matéria prima: Consiste na identificação da matéria prima;
2.
Origem da matéria prima: Essa atividade consiste no estudo da cana de açúcar
produzida no Estado de São Paulo;
3.
Substituição de materiais perigosos: Consiste na análise dos materiais e caso
haja necessidade o material é substituído. O material ácido sulfúrico e ciclo-hexano acabaram
por ser mantidos;
4.
Redução de materiais não renováveis: Nessa atividade os materiais reduzidos
foram: o diesel, substituído pelo bagaço de cana para fornecer energia à usina, fertilizantes,
substituídos pelo uso da torta de filtro;
5.
Redução de matéria prima: O estudo baseia-se em 1 hectare de cana de açúcar,
produção média de 86,7 ton. Neste caso, não ocorrerá à redução da quantidade de matéria
prima a ser utilizada;
6.
Transporte de materiais: È realizado de acordo com a distância a ser entregue o
produto;
O subprocesso simplificação do ciclo de vida consiste na estimativa do ciclo de vida
do Etanol de forma simplificada. Esse subprocesso é composto por quatro atividades.
Descritas brevemente a seguir:
1.
Produção: Consiste na avaliação do método tradicional da produção de cana de
açúcar quando comparado com o método para reduzir o impacto ambiental;
2.
Distribuição: Consiste na estimativa do custo de distribuição do Etanol onde
tem a sua distribuição entre o transporte rodoviário, náutico e ferroviário;
3.
Uso: O Etanol apresenta grande aplicação como combustível automotivo
sendo utilizado em larga escala para o abastecimento de veículos automotores;
4.
Destino: O Etanol apresenta como destino final a atmosfera, porém, após
sofrer a combustão está reação converte o Etanol em dióxido de carbono. Os subprocessos
mencionados anteriormente estão exemplificados nas figuras 14 e 15 a seguir:
61
Figura 14: Subprocesso de serviço
Fonte: (adaptado de SANTANA, 2012).
Figura 15: Subprocesso avaliação do ciclo de vida
Fonte: (adaptado de SANTANA, 2012)
62
Neste caso, para o produto em questão, o Etanol, não será possível o reparo assim
como a recuperação dos seus componentes, sendo assim, é enviado para o descarte, pois
conforme mencionado anteriormente, após o consumo do Etanol esse é convertido em CO2
sendo liberado na atmosfera. A figura 16 exemplifica esse processo.
Figura 16: Subprocesso reduz/elimina resíduos
Fonte: (adaptado de SANTANA, 2012).
O subprocesso avaliação do ciclo de vida tem como finalidade avaliar o impacto
ambiental de todo o ciclo deste produto, ou seja, desde a concepção até o seu destino final.
Esse subprocesso é formado por seis subprocessos e sete atividades. Descritas brevemente a
seguir:
1. Obter de matéria prima: Conforme mencionado anteriormente à matéria prima
utilizada na obtenção do Etanol é a cana de açúcar;
2. Subprocesso tipo de recurso: O tipo de recurso utilizado é renovável;
3. Subprocesso emissão de poluentes: Este subprocesso tem como finalidade
controlar as emissões de poluentes, oriundas do processo de obtenção de matéria prima,
tornando-as aceitáveis (baixa);
4. Transporte: Durante o transporte da cana de açúcar, contida em hectare, estima-se
uma emissão de 14,31 ton de CO2 para a atmosfera;
5. Subprocesso impacto de produção: Este subprocesso avalia o impacto associado à
produção do produto, neste caso, o Etanol, por meio da avaliação de gastos energéticos tendo
como objetivo otimizar o processo;
63
6. Realiza distribuição: Corresponde à distribuição pelo transporte do álcool até os
postos revendedores.
7. Subprocesso avaliação da distribuição: Avalia as atividades que englobam a
distribuição do Etanol.
8. Insumos: Consiste em verificar a combinação de fatores de produção.
9. Subprocesso utilização: Este subprocesso tem como finalidade avaliar se a
utilização do Etanol está sendo utilizado de maneira eficaz no veículo.
10. Subprocesso disposição de resíduos: Conforme mencionado anteriormente o
produto Etanol acaba por se perder na atmosfera quando transformado em CO2, sendo assim,
não pode ser reaproveitado, consertado ou reciclado, portanto, neste caso, este resíduo deve
ser descartado. A figura 17 exemplifica o subprocesso mencionado.
64
Figura 17: Ciclo de vida
Fonte: (adaptado de SANTANA, 2012).
65
O subprocesso tipo de recurso tem como finalidade verificar se o recurso utilizado
pode ser renovável, neste caso, é renovável, sendo assim, a atividade recurso renovável é
configurada como fluxo de mensagem padrão. Conforme exemplifica a figura 18:
Figura 18: Subprocesso tipo de recurso
Fonte: (adaptado de SANTANA, 2012).
Com relação ao subprocesso emissão de poluentes este tem como finalidade
controlar as emissões de poluentes, oriundas do processo de produção da matéria prima,
tornando-as baixas. Esse subprocesso é formado por sete atividades. Descritas brevemente a
seguir:
1. Verifica emissão de poluentes: Esta atividade tem como finalidade definir a
classificação da emissão de poluentes.
2. Baixa: Está relacionada com a taxa de emissão do CO (monóxido de carbono),
HC (Hidrocarbonetos) e NOx (Óxidos de nitrogênio).
3. Média: Está relacionada com a taxa de emissão do CO, HC e NOx.
4. Alta: Está relacionada com a taxa de emissão do CO, HC e NOx.
5. Otimiza processo: Esta atividade é executada caso a quantidade de emissão de
poluentes seja considerada como média ou alta, realizando uma melhoria no processo com o
intuito de minimizar a porcentagem de emissão de poluentes.
6. Substitui matéria prima: Substituição da matéria prima por uma menos poluente.
7. Manter matéria prima: Consiste em deixar a matéria prima já existente.
A figura 19 ilustra este processo:
66
Figura 19: Subprocesso emissão de poluentes
Fonte (adaptado de SANTANA, 2012).
67
O subprocesso impacto de produção avalia à produção do produto, neste caso, o
Etanol, por meio da avaliação de gastos. Este subprocesso é formado por seis atividades.
Descritas brevemente a seguir:
1. Verifica gastos energéticos: O gasto pode ser definido como regular, pois a
energia elétrica consumida na produção do Etanol é obtida por meio da cana de açúcar, sendo
assim, não há necessidade de compra de energia externa.
2. Verifica desgaste de equipamento: Esta atividade tem como finalidade verificar o
desgaste dos equipamentos. Para este caso, a vida útil do equipamento dura 25 anos.
3. Otimiza combustíveis: Verifica a relação custo benefício dos produtos ou
serviços.
4. Verifica emissão de poluentes: Verifica a taxa de emissão de poluentes.
5. Otimiza modernização: Verifica a relação custo benefício dos produtos ou
serviços.
6. Realiza tratamento:
Esta atividade tem como objetivo diminuir o impacto
negativo com relação aos gastos energéticos, desgastes de equipamentos entre outros. A
figura 20 exemplifica este processo.
Figura 20: Subprocesso impacto de produção
Fonte: (adaptado de SANTANA, 2012).
O subprocesso avaliação da distribuição tem como finalidade avaliar as atividades
que englobam a distribuição do Etanol. Este subprocesso é formado por doze atividades.
Descritas a seguir:
68
1. Verifica risco atribuído: Tem como finalidade verificar o risco atribuído. Neste
caso, o produto a ser distribuído apresenta característica inflamável, sendo assim, o risco
atribuído é alto;
2. Transporte especializado: Dada a periculosidade da carga, a mesma necessita de
transporte especializado para não correr risco de vazamentos de carga;
3. Transporte comum: Após a verificação do risco atribuído, a carga pode ser
transportada utilizando um transporte comum.
4. Verifica meio de distribuição: Verifica a distribuição da distância. Neste caso,
uma distância de distribuição adequada seria a de 340 km sendo considerada como perto;
5. Náutico, aéreo, ferroviário: Corresponde ao tipo de distribuição;
6. Ferroviário, rodoviário: Corresponde ao tipo de distribuição;
7. Perda de produto: Consiste em verificar se houve alguma perda do produto.
8. Emissão de poluentes: Esta atividade tem como finalidade verificar a distribuição
da emissão de poluentes;
9. Verifica custo benefício: Esta atividade realiza uma avaliação do custo beneficio
com relação ao tipo de distribuição;
10. Modernização da frota: Corresponde a modernização na frota distribuidora;
11. Substitui meio da distribuição: Apesar da alta de emissão de poluentes e não
modernização da frota a mesma ainda é mantida;
12. Terceiriza distribuição: Tem como objetivo verificar a possibilidade de
terceirizar a distribuição do produto. A figura 21 representa o processo mencionado
anteriormente.
69
Figura 21: Subprocesso avaliação da distribuição
Fonte: (adaptado de SANTANA, 2012).
70
No subprocesso de utilização o uso do Etanol dependerá muito do funcionamento
adequado do veículo, uma vez que o dado apresentado no item "consumo" 1, 97 kg de CO2
por litro de etanol hidratado, sendo assim somente é considerado correto se aplicado em um
automóvel em perfeito funcionamento.
1. Checar funcionamento: Verifica se o funcionamento do veículo está adequado.
2. Realizar manutenção preventiva: Esta atividade é realizada com o objetivo de
reduzir ou impedir falhas no desempenho de equipamentos.
3. Realizar manutenção corretiva: Esta atividade é realizada com o objetivo de
restabelecer o pleno funcionamento do equipamento.
4. Verificar gastos emissão: Liberação de gases por um motor.
5. Verificar resíduos: Realiza uma análise para verificar se o resíduo é regular ou se
este necessita de tratamento.
6. Realizar tratamento: Os gases tóxicos monóxido de carbono (CO), monóxido de
nitrogênio (NOx) e partículas de hidrocarboneto (HC), passam por uma espécie de tratamento
graças ao uso dos catalisadores automotivos que convertem esses gases tóxicos em nitrogênio
molecular (N2), vapor de água e (H2O) e dióxido de carbono (CO2). Conforme ilustra a
figura 22.
Figura 22: Subprocesso utilização
Fonte: (adaptado de SANTANA, 2012).
Com relação ao subprocesso disposição de resíduos infelizmente, como o produto
(Etanol) acaba por se perder na atmosfera, quando convertido em CO2, uma vez utilizado o
mesmo não pode ser reaproveitado, consertado ou reciclado, portanto, para este caso este
resíduo é diretamente descartado. Conforme ilustra a figura 23.
71
Figura 23: Subprocesso disposição de resíduo
Fonte: (adaptado de SANTANA, 2012).
72
5.1.1. ESTRATÉGIA
A estratégia deve ser bem definida e alinhada com os objetivos. Dessa forma, após
iniciar a modelagem As is é preciso analisar criticamente as possíveis mudanças a serem
realizadas, ou seja, se tais mudanças irão gerar valor para o negócio e contribuir para
alcançar as metas e apenas após esta etapa é possível propor melhorias que consiste na
remodelagem dos processos. Esses processos modelados devem auxiliar as organizações a
realizar o plano tático e o plano estratégico.
Para esta etapa foi definido como meta automatizar o processo design sustentável
com o objetivo de auxiliar nas atividades a serem desenvolvidas proporcionando um melhor
acompanhamento destas atividades durante a concepção de um produto.
5.1.2. TO BE
Analisando o processo As is foi possível verificar que neste processo não há
participantes para executarem as atividades mapeadas foi verificado também a ocorrência de
atividades duplicadas e/ou desnecessárias. Além disso, não é possível verificar se a atividade
a ser executada é manual, sistêmica ou se será realizada por um usuário. Dessa forma, foi
proposta a modelagem To be que corresponde as possíveis melhorias que podem ser
realizadas após a modelagem do funcionamento atual da empresa, ou seja, o As is. No
processo de referência utilizado, estas melhorias estão relacionadas a atividades duplicadas,
atividades desnecessárias e identificação de participantes. A seguir serão apresentados os
processos To be. No processo principal denominado orquestrador, ou macro processo pode-se
notar que os subprocessos serviços e produtos foram mapeados em um único subprocesso,
pois ambos os subprocessos possuem as mesmas atividades. As atividades: realiza produção,
realiza distribuição e consumo apresentado no As is foram eliminadas no To be pelo fato de
pertencerem ao subprocesso avaliação simplificada. A figura 24 apresenta a melhoria
proposta.
73
Figura 24: Macro processo to be
74
No subprocesso produto foram acrescentados dois departamentos: Logística e
Engenharia de produção assim como os seus dois principais participantes: Engenheiro de
produção e gerente de logística. Além disso, foi incluído o artefato informação do território
nacional que consiste dos dados sobre a produção de açúcar e a produção do etanol. A figura
25 exemplifica este processo.
Figura 25: Subprocesso produto to be
Fonte: (Leal, 2014)
No subprocesso avaliação simplificada foram incluídos dois departamentos:
1. Engenharia de produção e 2. Logística. Além disso, foi incluído um artefato denominado
estimativa de custo de distribuição que consiste de uma planilha em Excel que contém todas
as estimativas de custo de distribuição. A figura 26 exemplifica este processo.
Figura 26: Avaliação simplificada to be
Fonte: (Leal, 2014)
75
No subprocesso reduz/elimina resíduos a melhoria proposta foi o acréscimo do
subprocesso avaliação simplificada, tendo em vista que as atividades retorna distribuição e
retorna produção proposta no As is fazem parte do subprocesso avaliação simplificada. A
figura 27 apresenta este processo.
Figura 27: Reduzir/eliminar resíduos to be
Fonte: (Leal, 2014)
No subprocesso avaliação do ciclo de vida foram incluídos três departamentos:
1. Engenharia ambiental, 2. Engenharia de produção e 3.
TI. A figura 28 ilustra este
processo.
Figura 28: Subprocesso avaliação do ciclo de vida to be
Fonte: (Leal, 2014)
76
A melhoria proposta no subprocesso tipo de recurso consiste na inclusão de dois
departamentos: engenharia ambiental e engenharia de produção. Ressalta-se que todas as
atividades neste processo são realizadas pelo usuário. A figura 29 exemplifica esse processo.
Figura 29: Subprocesso tipo de recurso to be
Fonte: (Leal, 2014)
No subprocesso emissão de poluentes foi incluído dois departamentos: engenharia
de produção e engenharia ambiental assim como os seus participantes. Outra melhoria
realizada no subprocesso é a inclusão do artefato denominado análise. Este é adquirido após a
execução da atividade "analisa emissão de poluentes". Conforme demonstra a figura 30.
Figura 30: Subprocesso emissão de poluentes to be
Fonte: (Leal, 2014)
77
A melhoria proposta no subprocesso impacto de produção foi à inclusão de dois
departamentos: engenharia de produção e engenharia ambiental. A figura 31 ilustra este
processo.
78
Figura 31: Subprocesso impacto de produção to be
Fonte: (Leal, 2014)
79
O subprocesso avaliação da distribuição teve como principal melhoria a eliminação
de atividades desnecessárias e a inclusão de departamentos. Além disso, foi possível
identificar uma atividade sistêmica e um artefato denominado análise. A figura 32 ilustra a
melhoria proposta.
Figura 32: Avaliação da distribuição to be
Fonte: (Leal, 2014)
No subprocesso utilização a melhoria proposta foi à inclusão dos três departamentos.
Conforme mostra a figura 33.
Figura 33: Subprocesso utilização to be
Fonte: (Leal, 2014)
A melhoria proposta no subprocesso disposição/resíduos é a eliminação de
atividades duplicadas. Além disso, foram incluídos os departamentos. Conforme ilustra a
figura 34.
80
Figura 34: Subprocesso disposição/resíduos to be
Fonte: (Leal, 2014)
81
5.1.3. EXTRAÇÃO DE REQUISITOS
Essa etapa consiste na identificação dos principais requisitos funcionais, não
funcionais e regras de negócios extraídos do estudo de caso proposto.
A extração de requisitos proposta neste trabalho faz uso do trabalho de (VIEIRA,
2011). Dessa forma, é possível identificar os requisitos funcionais, não funcionais e regras de
negócios: A seguir um exemplo que ilustra o método proposto representado pela figura 35.
Figura 35: Subprocesso produto
Fonte: (Leal, 2014)
RF 01: O sistema deve fornecer dados relacionados ao território nacional.
RF 02: O sistema deve permitir o cadastro, alteração e exclusão de dados.
RNF 01: O sistema deve ser de fácil acessibilidade.
RN 01: Deve-se sempre optar pela melhor distância, ou seja, a distância mais
econômica. Neste caso, o sistema deve considerar uma distância de 340 km como perto.
5.1.4. ESPECIFICAÇÃO
Esta etapa tem como objetivo propor um método para auxiliar na elaboração do
documento de especificação de requisitos com o intuito de analisar até que ponto a BPMN
está aderente à norma ISO/IEC/IEEE 29148:2011, que trata da engenharia de requisitos.
1. Propósito: De acordo com (CASTRO, 2010) há uma correspondência entre os
objetivos e os elementos da BPMN. No modelo proposto pelo autor o objetivo é alcançado
através
de
metas
e
submetas
utilizando
operadores
lógicos.
82
2. Escopo: A notação BPMN auxilia na definição do escopo do projeto. Segundo
(GARCIA et al., 2011) é possível desmembrar cada atividade e verificar quais recursos são
necessários para realizá-la. Além disso, torna-se possível relacionar cada atividade com os
seus principais stakeholders determinando o prazo para a execução de cada atividade.
3. Funções do produto: Conforme demonstrado no subcapitulo 3.1 com a BPMN é
possível extrair os requisitos funcionais e não funcionais e posteriormente é possível realizar
diagramas da UML, como por exemplo, diagramas de caso de uso, diagrama de atividades,
diagrama de classes. Dessa forma, é possível ter uma visão sistêmica e identificar suas
possíveis funções.
4. Característica de usuário: Não foi encontrado indícios na literatura que a BPMN
auxilia na descrição das características do usuário. No entanto, pode-se afirmar por meio do
trabalho realizado nesta dissertação que através de técnicas de levantamento que auxiliam na
modelagem dos processos é possível identificar os principais participantes do processo. Dessa
forma, obtém as características relevantes de cada usuário.
5. Limitações: Não foi encontrado na literatura indícios de que a BPMN possa
auxiliar na identificação de possíveis limitações. No entanto, pode- se afirmar por meio do
trabalho realizado nesta dissertação que é possível identificar fatores que podem limitar
possíveis melhorias no mapeamento como por exemplo regras de negócios.
6. Hipótese e dependência: Não foi encontrado na literatura indícios de que a BPMN
possa auxiliar na identificação de hipóteses e dependência.
7. Requisitos: Diversas pesquisas apontam a identificação dos requisitos funcionais
por meio da BPMN e, posteriormente, faz uso do diagrama de caso de uso (TANUSKA,
2011) (NAWROCKI et al., 2006).
8. Interfaces: A BPMN fornece o uso de interface, pois na modelagem de processos
de negócios é possível identificar claramente as atividades de serviço. Dessa forma, é
possível executar um web services dentro do processo (OHNISHI et al., 2007)
9. Requisitos de usabilidade: Não foi encontrado na literatura trabalhos que estejam
relacionados com o uso da BPMN que possa auxiliar nos requisitos de usabilidade. No
entanto, o trabalho proposto por (DEMIRORS, 2005) faz uso das seguintes categorias de
qualidade: funcionalidade, confiabilidade e manutenabilidade. Além disso, o trabalho
apresenta as subcategorias: métricas, operabilidade das métricas, métricas de atratividade,
entre outras propostas na ISO 9126. O objetivo é utilizar a ISO 9126 para medir a qualidade
dos processos de negócios.
83
10. Requisitos de desempenho: Os requisitos de qualidade são importantes, pois tem
como objetivo fornecer a garantia para o desempenho do serviço, assim como garantir a
satisfação do cliente. No entanto, apesar da sua importância capturar requisitos não
funcionais utilizando a BPMN torna-se algo trivial e complexo. Dessa forma, propôs capturar
os requisitos de custo, tempo e confiabilidade utilizando BPMN.
Para adquirir os requisitos mencionados anteriormente é considerado o tempo
máximo de transferência de dados, tempo necessário para completar um determinado pedido,
número de solicitações atendidas (SAEEDI, 2010).
11. Restrições: A BPMN por meio da regra de negócio fornece mecanismo para
identificar possíveis restrições, operações e definições que podem impactar o projeto.
12. Padrões de conformidade: O método proposto por (SCHLEICHER, 2010) faz
uso da BPMN para identificar padrões de conformidade. Este método consiste na
identificação dos papéis que devem estar envolvimentos no ambiente. No estudo de caso
proposto pelo autor foi possível identificar: Proprietário do processo (responsável pela
criação e modificação dos processos), Process Designer (responsável pela verificação do
escopo juntamente com regras de conformidade), Especialista em conformidade (possui o
conhecimento necessário para aplicar normas de conformidade que deve ser aplicada no
processo).
13. Atributos do sistema de software: Não foi encontrado na literatura indícios de
que a BPMN possa auxiliar na identificação de atributos do sistema de software (atividade
sistêmica), no entanto, por meio do trabalho proposto pode-se afirmar que é possível
identificá-los por meio de levantamento de requisitos e mapeamento de processos.
14. Verificação: Não foi encontrado na literatura trabalhos que estejam relacionados
com o uso da BPMN que possa auxiliar na verificação, no entanto, pode-se afirmar que o uso
da BPM garante a qualidade dos processos estando atrelada com a qualidade do software.
15. Informações: A BPMN contém um elemento denominado anotação que permite
fornecer informações adicionais.
16. Definições, siglas e abreviaturas: Embora seja considerada uma informação
adicional no documento de especificação a BPMN não auxilia na identificação de definições,
siglas e abreviaturas.
Além dos itens encontrados no documento de requisitos apresentado anteriormente
as definições, siglas e abreviaturas podem fazer parte do documento de requisitos, no entanto,
a BPMN não tem mecanismo que possa auxiliar na sua identificação. Em contrapartida, a
84
criação de protótipos pode ser considerada como uma informação adicional que agrega valor
no documento de requisitos.
No trabalho realizado por (DONALDSON, 2005) o autor utiliza diagrama de
atividades para realizar o protótipo de telas, no entanto, é possível estender o método
proposto para BPMN, pois conforme demonstrado no subcapítulo 4.2 o diagrama de
atividades pode ser transformado em BPMN. Desta forma, a BPMN auxilia na prototipação
de telas que serve como modelo para uma apresentação de como será o sistema assim como
as principais funcionalidades.
Um exemplo prático extraído do subprocesso "produto" está relacionado à atividade
"realiza transporte". Nesta atividade o sistema teria como uma das telas a figura 36.
Figura 36: Tela para verificar transporte
Fonte: (Leal, 2014)
5.1.5. IMPLEMENTAÇÃO DOS PROCESSOS BizAgi Xpress
Esta etapa apresenta a implementação do processo design sustentável. Inicialmente
foi realizada uma pesquisa sobre as principais ferramentas de mapeamento e modelagem de
processos, sendo elas: BizAgi Xpress, Tibco, Bonita, Activiti e Aris. Após uma análise
detalhada de cada ferramenta foi possível escolher a ferramenta BizAgi Xpress e JBPM
sendo uma proprietária e a outra open source o uso das duas ferramentas justifica-se pelo fato
de apresentar a diferença entre as ferramentas e para demonstrar que apesar das diferenças
ambas possuem as mesmas funcionalidades, no entanto, uma com baixo grau de
complexidade e a outra com um alto grau de complexidade.
85
A identificação dos serviços é considerada o primeiro passo para o desenvolvimento
da arquitetura orientada a serviços, dessa forma, torna-se fundamental ter o processo de
negócio como ponto de partida (INAGANTI, 2007). Após a identificação dos principais
processos de negócios há necessidade de identificar as funcionalidades oferecidas pelos
aplicativos e expor como serviço.
A terceira etapa consiste em relacionar os serviços às atividades existentes.
Para realizar a implementação dos processos e dos serviços foi necessário seguir as
sete etapas disponibilizadas pela ferramenta, sendo estas: 1. a modelagem dos processos,
2. model data, ou seja, modelar as possíveis entidades que podem descrever o negócio,
3. criar formulário para as atividades, 4. definir as possíveis regras de negócios e as ações de
cada atividade e caminhos alternativos, 5. definir participantes para cada atividade do
processo, 6. verificar as possíveis interfaces e 7. realizar o deployment dos processos de
acordo com o ambiente, podendo ser: ambiente de desenvolvimento, ambiente de teste e
ambiente de produção. A figura 37 exemplifica o modelo de dados extraído do processo de
referência.
Figura 37: Modelo de dados do negócio
Fonte: (Leal, 2014)
86
Analisando a figura 37 contém três tipos de entidades: 1. entidade master
(caracterizada com a cor azul) corresponde a atividades que estão ligadas ao negócio do
processo que está sendo automatizado, 2.entidade do tipo system (caracterizado com a cor
cinza): entidade do metamodelo do BizAgi Xpress que pode ser relacionada com o modelo
do negócio. Neste caso, indica que a entidade design sustentável está associada a um usuário
que a solicita e o usuário está na tabela WFuser e 3. entidade do tipo parâmetro: representam
campos que pode ter mais de uma opção, permitindo realizar inclusão, alteração e exclusão
lógica dos valores da entidade.
A próxima etapa tem como finalidade criar formulário para as atividades do
processo. As figuras 38 e 39 exemplificam esta etapa.
Figura 38: Atividades habilitadas para criação de formulários
Fonte: (Leal, 2014)
Ao analisar a figura 38 nota-se que apenas com atividades de usuário é possível criar
um formulário. Dessa forma, a atividade do tipo serviço não está habilitada. A figura 39
ilustra a criação do formulário. Este é extraído com base nos campos que foram criados na
tabela.
87
Figura 39: Criação do formulário
Fonte: (Leal, 2014)
A próxima etapa consiste na definição das possíveis regras de negócio que podem
impactar o processo. Para esta etapa inicialmente há necessidade de definir as expressões que
determinam os caminhos alternativos no processo, ou seja, os gateways. A figura 40
exemplifica esta etapa.
Figura 40: Definição de expressões/condições
Fonte: (Leal, 2014)
Posteriormente há necessidade de definir os participantes que irão executar cada
atividade. Para atingir o objetivo proposto foram definidas posições organizacionais de
acordo com a estrutura ilustrada na figura 11.
A etapa seis tem como finalidade realizar a configuração das atividades que foram
definidas como atividades sistêmicas. No estudo de caso proposto foi definido que a atividade
88
"origem matéria prima" necessita de informação referente ao território nacional que para este
estudo de caso foi utilizado o estado de São Paulo.
O objetivo principal desta etapa é criar um web services que possa acessar um banco
de dados e retornar os seus valores, sendo assim, primeiramente foi definido um banco de
dados com as informações necessárias. A ferramenta da Microsoft SQL Server Management
Studio Express 2008 foi utilizada para a criação do banco de dados. Dessa forma, foi criado
um banco de dados denominado "dados produção". Além disso, foram criadas sete tabelas:
1. dados produção, 2. exportação anual açúcar origem, 3. exportação anual de etanol por local
de embarque, 4. exportação anual etanol, 5. exportação açúcar origem, 6. exportação anual
açúcar local de embarque; e 7. preço médio pago cana de açúcar.
O web services utilizado foi desenvolvido utilizando a ferramenta Web Developer
2005 Express Edition. Esta ferramenta contém como padrão as pastas App_Code (para o web
services) e App_Data (contém os arquivos service.asmx e web.config).
A seguir é exemplificado o arquivo service.vb:
Imports System.Data.SqlClient
Imports System.Web.Services
<System.Web.Services.WebService(Namespace:="http://tempuri.org/wstreinament
o/Service1")> _
Public Class Service1
Inherits System.Web.Services.WebService
//Informa que o método deve ser exposto como um web services
<WebMethod(Description:="Consulta banco de dados e retorna DataSet")> _
Function RetornaDataSetResult(ByVal strQuery As String) As Data.DataSet
Dim
Dim
Dim
Dim
conn As New SqlConnection
cmd As New SqlCommand
da As New SqlDataAdapter
tabela As New Data.DataSet
//Obtem a string de conexão definida no arquivo web.config
conn.ConnectionString =
"Data Source=localHost;UserID=TESTE;Password=290787;InitialCatalog=
DADOSPRODUCAO,EXPORTAÇÃO_ANUAL_ACUCAR_LOCAL_EMBARQUE,
EXPORTACAO_ANUAL_ACUCAR_ORIGEM,EXPORTACAOANUALETANOL,EXPORTACAOANUALETANOL,
PRECO_MEDIO_PAGO,CANA_ACUCAR"
cmd.Connection = conn
cmd.CommandText = strQuery
da.SelectCommand = cmd
da.Fill(tabela)
conn.Dispose()
cmd.Dispose()
da.Dispose()
89
//Retorna os dados
Return tabela
End Function
End Class
A seguir o arquivo padrão web.config criado no web developer com as seguintes
alterações para conexão.
<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="localhost.Service"
value="http://localhost:58003/WebSite5/Service.asmx"/>
</appSettings>
<connectionStrings>
<add name="conexaoTESTE" connectionString="Data
Source=.\SQLEXPRESS;Initial
Catalog=DADOSPRODUCAO,EXPORTAÇÃO_ANUAL_ACUCAR_LOCAL_EMBARQUE,
EXPORTACAO_ANUAL_ACUCAR_ORIGEM,EXPORTACAOANUALETANOL,EXPORTACAOANUALETANOL,
PRECO_MEDIO_PAGO,CANA_ACUCAR;Integrated Security=True"
providerName="System.Data.SqlClient"/>
</connectionStrings>
<system.web>
<compilation debug="true" strict="false" explicit="true"/>
<pages>
<namespaces>
<clear/>
<add namespace="System"/>
<add namespace="System.Collections"/>
<add namespace="System.Collections.Specialized"/>
<add namespace="System.Configuration"/>
<add namespace="System.Text"/>
<add namespace="System.Text.RegularExpressions"/>
<add namespace="System.Web"/>
<add namespace="System.Web.Caching"/>
<add namespace="System.Web.SessionState"/>
<add namespace="System.Web.Security"/>
<add namespace="System.Web.Profile"/>
<add namespace="System.Web.UI"/>
<add namespace="System.Web.UI.WebControls"/>
<add namespace="System.Web.UI.WebControls.WebParts"/>
<add namespace="System.Web.UI.HtmlControls"/>
</namespaces>
</pages>
<authentication mode="Windows"/>
</system.web>
</configuration>
Ao
analisar
o
RetornaDataSetResult
código
do
arquivo
service.vb
nota-se
que
o
método
recebe como parâmetro um comando em sql e posteriormente,
consulta o banco de dados denominado DADOSPRODUÇÃO e retorna os seus dados. A
figura 41 ilustra essa etapa:
90
Figura 41: Parâmetro
Fonte: (Leal, 2014)
A figura 42 a seguir exemplifica a chamada do web service. Em contrapartida, a
figura 43 ilustra o wsdl gerado.
Figura 42: Consulta ao Banco de dados
Fonte: (Leal, 2014)
91
Figura 43: WSDL gerado automaticamente
Fonte: (Leal, 2014)
A etapa final corresponde a realizar o "deploy" dos processos em um dos ambientes:
desenvolvimento, teste ou produção. A figura 44 ilustra o work portal para execução dos
processos.
Figura 44: Portal dos processos
Fonte: (Leal, 2014)
Analisando a figura 44 nota-se que inicialmente não há nenhum processo sendo
executado. Em contrapartida, a figura 45 apresenta a execução do processo design
sustentável.
92
Figura 45: Execução dos processos
Fonte: (Leal, 2014)
A figura 46 apresenta a seguir ilustra a duração e o estado dos processos.
Figura 46: Medição dos processos
Fonte: (Leal, 2014)
93
5.1.6. IMPLEMENTAÇÃO DOS PROCESSOS JBPM
Esta seção apresenta a implementação dos processos utilizando uma ferramenta open
source. Para atingir o objetivo proposto foram utilizadas as seguintes ferramentas:
JBPM 3.2
JBOSS by Red Hat 3.1.0
Eclipse 3.6.1
A implementação dos serviços é formada pelas seguintes etapas:
1. Modelar os processos utilizando a ferramenta BizAgi Xpress.
2. Implementar os processos utilizando as ferramentas JBOSS e JBPM. Esta etapa é
realizada somente após a modelagem dos processos, sendo assim, é caracterizado como a
parte técnica. A linguagem JPDL (Language Definition Process) está diretamente relacionada
ao gestor do workflow JBPM. Paralelamente à representação do WS-BPEL, baseado em
XML, a JPDL consiste de uma interação gráfica baseada em fluxogramas. A figura 47
exemplifica essa representação.
Figura 47: Representação JPDL
Fonte: (Leal, 2014)
Em contrapartida, o JBPM refere-se a uma forma flexível do BPM Suite. JBPM é
escrito em Java e distribuído sob licença Apache.
94
1.
Após o teste de conexão, o deploy dos processos é realizado utilizando o
seguinte endereço local: http://localhost: 8080/jbpm-console. Para realizar a implementação
dos processos foram utilizados os seguintes elementos do JBPM:
a) Start: Corresponde ao estado inicial do processo. Um processo sem um estado de
início é válido, porém não é executado.
b) End: Está relacionado ao estado final do processo. Um processo sem um estado
de fim é válido, porém não é executado.
c) Event: È um evento nó onde pode ser colocado as ações (actions).
d) Actions: São referidas em eventos e transições. São obrigatoriamente
identificadas com um nome.
e) Task: Representam as tarefas que são executas no processo.
f) Swinlanes: Está relacionada aos papéis no processo, sendo assim, são utilizadas
para realizar a atribuição das tarefas.
Na BPMN é possível identificar os participantes de um processo utilizando pool e/ou
lanes, no entanto, no JBPM para representar os participantes definido na modelagem foi
necessário criar as seguintes classes:
1. EscolherPersonagem: Classe utilizada para atribuir atividades específicas para um
usuário no processo, ou seja, define um grupo e o usuário escolhido deste grupo para receber
as atividades.
2. Integrar SubProcesso: Atribui a decisão tomada à variável IntegrarSubProcesso.
Os processos de negócios podem ser gerenciados por meio de um web console onde
é possível realizar o gerenciamento das instâncias de um processo, gerenciamento de tarefas e
reportagem. O primeiro está relacionado à capacidade de iniciar novas instâncias de um
determinado processo. O segundo tem como finalidade obter uma lista de todas as tarefas e o
terceiro realiza uma visão geral do estado da sua aplicação, ou seja, os indicadores de
desempenho (KPIs). A figura 48 exemplifica esse processo.
95
Figura 48: Processos JBPM-console
(Leal, 2014)
Analisando a implementação dos processos utilizando a ferramenta BizAgi Xpress e
a ferramenta JBPM é possível identificar as vantagens e as desvantagens de cada ferramenta,
sendo descritas brevemente a seguir:
Vantagens BizAgi Xpress
Desvantagens BizAgi Xpress
Acompanhamento gráfico e online por meio do
portal web.
Ferramenta proprietária.
Regras de negócios são definidas de forma gráfica.
Automatiza os processos de forma ágil.
Indicadores de desempenho de processos.
Tabela 9: As vantagens e as desvantagens da ferramenta BizAgi Xpress
Fonte:(Leal, 2014)
A tabela 10 a seguir apresenta as principais vantagens e desvantagens da
ferramenta JBPM.
Vantagens Jbpm
Desvantagens Jbpm
Console de gerenciamento que permite o
monitoramento dos processos em todo o seu ciclo de
vida.
Não é interoperável com outras plataformas.
Instalação com maior grau de complexidade.
Lógica de negócio complexo pode ser realizada
através de regras de negócios e processamento de
eventos complexos.
Conhecimento em implementação.
Apesar de existirem ferramentas de suporte desta
linguagem, pode-se considerar o desenvolvimento
complexo quando comparado com a ferramenta
BizAgi Xpress.
Tabela 10: As vantagens e desvantagens da ferramenta JBPM
Fonte: (Leal, 2014)
96
Conforme mencionado anteriormente com base na implementação dos processos por
meio das ferramentas utilizadas foi possível apontar as vantagens e desvantagens de cada
ferramenta. Dessa forma, pode-se concluir que a ferramenta BizAgi Xpress apresentou um
melhor desempenho, pois permite uma maior flexibilidade a possíveis mudanças que podem
ocorrer durante o processo. Além disso, é de fácil utilização e possui uma interface amigável.
97
6. CONSIDERAÇÕES FINAIS
As considerações finais apresentam as contribuições deste trabalho de pesquisa,
publicações associadas e possíveis trabalhos futuros sobre o tema abordado.
6.1. PRINCIPAIS CONTRIBUIÇÕES DESTE TRABALHO
A aplicação de processos de referência de negócio na engenharia de requisitos
permite obter um maior entendimento das necessidades do cliente, o que auxilia na
identificação mais precisa dos requisitos do sistema. Além disso, permite a disponibilização
dos dados através de serviços web.
Apesar de existirem diversos modelos de desenvolvimento de software, a visão por
processos proposta enfatiza o entendimento do negócio. A partir dela, é possível obter um
detalhamento das atividades a serem executadas, o que é essencial para a identificação dos
requisitos. A visão por processos também permite um melhor alinhamento entre negócios e
tecnologia. Portanto, a proposta de um processo de referência de negócio para a especificação
de requisitos traz uma contribuição efetiva para a problemática apresentada.
6.2. PUBLICAÇÕES ASSOCIADAS
As atividades relacionadas com o desenvolvimento deste trabalho permitiram a
publicação de um artigo completo em periódico internacional e um resumo em conferência
internacional. Os dois trabalhos científicos estão apresentados a seguir.
SANTANA, F.S.; COSTA, A.H.R.; TRUZZI. F.; SANTOS, S.L.; FRANCOY, T.M.;
SARAIVA, A.M.; A REFERENCE PROCESS FOR AUTOMATING BEE SPECIES
IDENTIFICATION BASED ON WING IMAGES AND DIGITAL IMAGE
PROCESSING. ECOLOGICAL INFORMATICS JOURNAL. Disponível em:
http://www.sciencedirect.com/science/article/pii/S1574954113001222.
SANTANA, FS.; LEAL,S,S.; COSTA,A.H.R.; SARAIVA,A.M.; A REFERENCE
PROCESS FOR BEE CLASSIFICATION BASED ON WING IMAGES. ISEI 2012 –
8th International Conference on Ecological Informatics Informing decisions on
biodiversity and natural resources conservation. Brasília, 3-7 December, 2012.
Resumo disponível na web.
98
6.3. CONCLUSÃO
A pesquisa bibliográfica realizada e o estudo de caso desenvolvido nesse trabalho
mostraram a importância da identificação correta dos requisitos para a produção de software.
No entanto, ainda é elevada a taxa de projetos de software que não foram concluídos com
sucesso em função de requisitos que não foram identificados, requisitos incompletos e
requisitos inconsistentes. Para minimizar o problema, foi proposto um método onde o uso de
processos de negócios foi adotado como ferramenta para a correta obtenção dos requisitos de
software.
O uso do método proposto permite o alinhamento entre os sistemas desenvolvidos e
os processos de negócio de uma empresa, o que pode simplificar a gestão de mudanças e a
rastreabilidade de requisitos. Muitas mudanças podem ser definidas, formalizadas e validadas
pelo próprio processo, enquanto a rastreabilidade de requisitos passa a estar presente em todo
o processo de desenvolvimento.
Finalmente, o mapeamento de processos de negócio em BPMN de acordo com o
método proposto cobre pelo menos 62% do que é exigido na norma ISO/IEC/IEEE
29148:2011, que trata da engenharia de requisitos de software. Portanto, é viável a adoção de
uma abordagem para a engenharia de requisitos onde os processos de negócio sejam os
elementos centrais.
6.4. TRABALHOS FUTUROS
As contribuições do método proposto para a engenharia de requisitos são suficientes
para motivar a continuidade de novos estudos. Os estudos podem envolver tanto a avaliação
mais detalhada do método através da realização de novos estudos de caso ou a incorporação
de outros aspectos relevantes da norma ISO/IEC/IEEE 29148:2011. Também é possível
avaliar a extensão desta proposta para sistemas não baseados em SOA. Portanto, existe um
campo fértil para o desenvolvimento de novos projetos de pesquisa a partir do método
proposto, o que reforça a sua importância e as contribuições deste trabalho.
99
7. REFERÊNCIAS BIBLIOGRÁFICAS
(ANDRADE,
R,
2002).
Universal
Description,
Discovery
and
Integration.
(http://www.inf.ufsc.br/~andrade/mobilidade/UDDI.pdf ). Último acesso em 14 de junho de
2013.
(BASS, L.; CLEMENTS, P.; KAZMAN, R, 2013) Software architecture in practice. 3º
edição. pp. 640. ISBN: 978-0321815736.
(BECERRA J.L.R; SIQUEIRA , F.L; BARBARÁN, G.C, 2010). A software factory for
education in software engineering - 21st Conference on software Engineering Education and
Training- disponível em IEEE. Ùltimo acesso em 17 de junho.
(DEMIRORS, O.; GENCEL.C, 2004) A comparison of size estimation techniques applied
early in the life cycle. pp. 184-194. Vol. 3281.Berlin/Heidelberg: Springer. ISSN: 0302-9743.
(DIAS, F.; MORGADO, G.; OSCAR, P.; SILVEIRA, D, 2008). Uma abordagem para a
transformação
<
automática
do
modelo
de
negócio
em
modelo
de
requisitos.
http://wer.inf.puc-rio.br/WERpapers/pdf_counter.lua?wer=WER06&file_name=dias.pdf>
Ùltimo acesso em 27 de abril de 2014.
(DIJKMAN, R,M.; JOOSTE, S.M.M.;,2002). Deriving use case diagrams from business
process models. < http://doc.utwente.nl/37995/>. Ùltimo acesso em 27 de abril de 2014.
(DONALDSON, A.; WILLIAMSON, A., 2005). Pen based input of UML activity diagrams
for business process modeling < http://www.doc.ic.ac.uk/~afd/papers/pdfs/2005/HCI.pdf>
Workshop on improving and assessing pen based input techniques. Ùltimo acesso em 27 de
abril de 2014.
(ENGELS, G.; GULDALI, B.; SOLTENBORN, C.; WEHRHEIM, H., 2008) Assuring
consistency of business process models and web services using visual contracts. pp. 115.ISSN: 0302-9743.
(FERNANDÉZ, H; GONZÁLEZ, E.P; DÍAZ, V.G; BUSTELO, C.P, MARTÍNEZ, O.S;
LOVELLE, J.M.C) SBPMN An easier business process modeling notation for business users.
Computer Standards & Interfaces. pp. 18-28.Vol.32.Elsevier 10.1016-j.csi.2009.04.006
(GLINZ, M, 2010) Problems and deficiencies of UML as a requirements specifications
language. International workshop on software specification and design. pp.11. ISBN:0-76950884-7 .
100
(HEREDIA, L. R, 2012) Transformação de modelos de processos de negócios em BPMN
para modelos de sistemas utilizando casos de uso da UML. Disponível em:
<http://tede.pucrs.br/tde_busca/arquivo.php?codArquivo=4157 > Ùltimo acesso em 27 de
abril de 2014.
(HUHNS, M.; SINGH, M., 2005). Service oriented computing: key concepts and principles
pp.75-81.IEEE Computer Society ISSN: 1089-7801.
(HUZAR, Z.; KUZNIARZ, L.; REGGIO, G.; SOURROUILLE, J.L, 2005) Consistency
problems in UML based software development. pp.1-12. ISBN: 10-1007-978-3-540-31797-51, 2005.
(IEEE 830,1998) Recommended practice for software requirements specifications. IEEE
Computer society. pp. 1-40. ISBN: 978-07381-0448-5.New York, 1998.
(IEEE, 1998) Guide for developing systems requirements specifications: IEEE Std 1233.
ISBN: 0-7381-0421-3.pp.1-10.New York.
(INAGANTI, S; BEHARA, G.K., 2007) Service identification: BPM and SOA handshake.
Disponível
em:
<http://w.bptrends.com/publicationfiles/THREE%2003-07-ART-
BPMandSOAHandshake-InagantiBehara-Final.pdf> Ùltimo acesso em 27 de abril de 2014.
(ISO-IEC: 29148, 2011). International standard ISO/IEC/IEEE 29148:2011, Systems and
software engineering life cycle processes- requirements engineering. pp.83
(JIANG, J.; KLEIN, G., 2000) Software development risks to project effectiveness. ISSN:
1641212. pp1-8.
(KAMOUN, F. s.d). A roadmap towards the convergence of business process management
and service oriented architecture. pp. 1-8. ACM Digital Library.
(KAPURUGE, M; COLMAN, ALAN; HAN, J, 2011). Defining customizable business
processes without compromising the maintainability in multi-tenant SaaS applications. IEEE
4th International Conference on Cloud Computing. ISBN: 978-0-7695-4460-1. IEEE
Computer Society.
(KELLNER, M.I.; MADACHY, R.J.; RAFFO, M.D, 1999) Software process simulation
modeling: why? What? How?. 0164-1212
(KORHERR,B.; LIST,B, 2002) Aligning business process and software connecting the UML
2 profile for event driven process chains with use cases and components
101
< http://www.wit.at/people/korherr/publications/caise_forum2006.pdf>.Ùltimo acesso em 27
de abril de 2014.
(LANGE, C; CHAUDRON, M; MUSKENS, J., 2006) In practice: UML software
architecture and design description, 2006. IEEE Software. Vol.23.pp 40-46. ISSN: 07407459)
(LAWRENCE, S; PFLEEGER, 2004) Engenharia de software: Teoria e prática. 2ª .edição.
São Paulo. Prentice Hall. pág. 112. ISBN: 8587918314.
(LIEW, P; KONTOGIANNIS, K; TONG. T, 2004) A framework for business model driven
development. International workshop on software technology and engineering practice. pp. 8.
ISBN: 0-7695-2293-9.
(LIN, K. J.; ZHANG.J.; ZHI, Y.; XU.B, 2010) The design and implementation of service
process reconfiguration with end to end QoS constraints in SOA. pp1-12. ISSN: 18632394
(MACKENZIE, C.M.; LASKEY, K.; MCCABE, F.; BROWN, P.F.; HAMILTON; METZ .
Oasis reference model for service oriented architecture 1.0. 2006. (https://www.oasisopen.org/committees/download.php/19679/) Ùltimo acesso em 05 de julho de 2013.
(MARECHAUX, J.L, 2006) Combining Service Oriented Architecture and Event Driven
Architecture Using an Enterprise Service Bus.
(www-128.ibm.com/developerworks/webservices/library/ws-soa-eda-esb/). Ùltimo acesso
em: 13 de junho de 2013
(MARZULLO, F.P, 2009) SOA na prática: inovando seu negócio por meio de soluções
orientadas a serviços. São Paulo: Novatec Editora. ISBN: 978-85-7522-201-0. 390 pp.
(MAZINI, E; VEZZOLI, C, 2003) A strategic design approach to develop product service
systems examples taken from the environment friendly innovation. Italian prize. Journal of
Cleanner Production 11, 851-857.
(MENGE, F, 2007) Enterprise Service Bus. Free and Open Source Software Conference.
(https://programm.froscon.org/2007/attachments/15falko_menge__enterpise_service_bus.pdf
)
Último acesso em: 13 de junho de 2013.
(NAWROCKI, J; NEDZA, T; OCHODEK, M; OLEK, L, 2006) Describing business process
with use cases. Ùltimo acesso em 26 de junho de 2014.
(OHNISHI, H.; YAMATO,Y.; KANEKI, T.; MORIYA, T.; HIRANO, M.; SUNAGA, H.,
2007) Service delivery platform for telecom enterprise internet combined services. pp. 108112.ISBN: 978-1-4244-1043.
102
(OKAMA,T.; HIRABAYASHI, S.; KAMINISHI, T.; KOIZUMI, H.; SAWAMOTO,J) A
method of linking business process modeling with information system design using UML and
its evaluation by prototyping . In Asia Pacific service computing conference 2nd IEEE, 2007,
pp.458-465. ISBN: 0-7695-3051-6.
(OLIVEIRA F; PAULO, R.S, 2005). Automação da avaliação da maturidade de processos
baseados no método SCAMPI. Disponível em http://www.cin.ufpe.br/~tg/2005-1/prsof.pdf.
Último acesso em 16 de junho.
(OMG).
Available
Specification.
Business
Process
Modeling
Notation,
v.
2.1.
(http://www.bpmn.org). Último acesso em: 16 de junho.
(PATTERSON, D., FOX, A. 2012). Engineering long lasting software: an agile approach
using SaaS and cloud computing. Beta Edition. Acesso Kindle. 2008. Conference on
conceptual modeling. Ùltimo acesso em 27 de abril de 2014.
(PFLEEGER, L.S, 2004) Engenharia de software: teoria e prática. 2º edição. ISBN:
8587918311.
(PRESSMAN, R.; 2011) Engenharia de software: uma abordagem profissional. pp. 780. 7º
edição. Editora McGraw- Hill. ISBN: 9788563308337.
(REIS,
G.)
Modelagem
de
processos:
use
case
e
ferramentas
BPM.
2011
(http://www.portalbpm.com.br/servlet/leartigo? qual=/WEB INF/artigos/digital). Último
acesso em 10 de fevereiro.
(RIBEIRO, J.L.V, 2008) Orquestração e composição de serviços web usando BPEL.
<http://ria.ua.pt/bitstream/10773/2001/1/2009000838.pdf>. Último acesso em: 13 de junho de
2013.
(RODRIGUEZ, A.; FERNÁNDEZ, E.; PIATTINI, M, 2007) Towards CIM
to PIM
transformation: from secure business defined in BPMN to use cases. Springer. LNCS 4714,
pp. 408-415. ISBN: 978-3-540-75182-3, 2007)
(SAEEDI, K.; ZHAO, L.; SAMPAIO, P.R.F., 2010) Extending BPMN for supporting
customer – facing service quality requirements. IEEE. pp. 616-623. ISBN: 978-0-7695-41280, Computer Society, 2010
(SANTANA, 2010) Uma infraestrutura orientada a serviços para modelagem de nicho
ecológico<http://www.teses.usp.br/teses/disponiveis/3/3141/tde-13072009-165044/ptbr.php>. Último acesso em: 27 de abril de 2014.
103
(SANTANA, 2010) A reference process to design information systems for sustainable design
based on lca, pss, social and economic aspects. Springer. pp. 269-280. ISBN: 978-3-64215479-9, 2010.
(SARA, R.; SAVÉN, A, 2003) Business process modelling: review and framework. Elsevier.
International journal of production economics. Science direct.0925-5273-03.pp. 129-149. Vol
90, 2003.
(SCHLEICHER, D.; SCHUMM, D.; ANSTETT, T.; LEYMANN, F.; STRAUCH, S, 2010)
Essential aspects of compliance management with focus on business process automation
<http://subs.emis.de/LNI/Proceedings/Proceedings177/131.pdf> Ùltimo acesso em 27 de
abril de 2014.
(SEI,
2003).
Software
Engineering
Institute.
As
três
dimensões
do
processo.
(http://www.sei.cmu.edu/library/abstracts/whitepapers/upload/CMMIDEV-1-2
Portuguese.pdf) . Último acesso em: 16 de junho 2011.
(SOMMERVILLE, I, 2011). Engenharia de software. 9ª edição. São Paulo: Pearson Addison
Wesley. pp. 79-111. ISBN: 978-0137035151
(STAL, M. 2002). Web services: beyond component based computing. Communication of
the ACM. Outubro. Vol.45. No. 10
(TANUSKA, P.; SKRIPCAK, T., 2011). The proposal of functional user requirement
generation. IEEE. ISBN: 978-1-61284-2-11. pp. 39-42, 2011.
(VIEIRA, S.R.C.; VIANA, D.; NASCIMENTO, R.; CONTE, T, 2012) Evaluating a
technique for requirements extraction from business process diagrams through empirical
studies. IEEE.pp.1-10. ISBN: 978-1-4673-0793-2-12, 2012.
(XAVIER, L.; ALENCAR, F.; CASTRO, J.; PIMENTEL, J., 2010) Integração de requisitos
não
funcionais
a
processos
de
negócio:
integrando
BPMN
e
NFR,
2010
< http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/Trabalho?id=13993> . Ùltimo acesso em 27
de abril de 2014.
(WHITE, D.MIERS, 2008). BPMN modeling and reference guide, future strategies.
(http://books.google.com.br). ISBN 10: 0-9777527-0 ISBN13: 978-0- 9777527-2-0.
(WHITE, S. A). Introduction to BPMN. IBM Press. (http://www.omg.org). Ùltimo acesso em
16 de junho.
(WINTERGREEN
RESEARCH)
(http://wintergreenresearch.com/blog/?tag=soa-esb).
Ùltimo acesso em 04 de julho de 2013.
104
(WU, L.; KUMAR, S.; BUYYA, R, 2012) SLA based admission control for a software as a
service provider in cloud computing environments. pp. 1-20. ISSN: 0022-0000.
(W3C Brasil- World Wide Web Consortium Escritório Brasil) Disponível em:
http://www.w3c.br/Home/WebHome. Último acesso em 18 de maio de 2014.
105