Embed Size (px)
Citation preview
UNIVERSIDADE ESTADUAL DE MARINGÁ
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ELDER ELISANDRO SCHEMBERGER
MoRE-GSD – Uma abordagem para elicitação e análise de requisitos a partir
das regras de negócio no contexto de desenvolvimento distribuído de software
Maringá
2013
ELDER ELISANDRO SCHEMBERGER
MoRE-GSD – Uma abordagem para elicitação e análise de requisitos a partir
das regras de negócio no contexto de desenvolvimento distribuído de software
Dissertação apresentada ao Programa de
Pós-Graduação em Ciência da Computação do
Departamento de Informática, Centro de
Tecnologia da Universidade Estadual de Maringá,
como requisito parcial para obtenção do título de
Mestre em Ciência da Computação.
Orientadora: Profa. Dra. Elisa Hatsue Moriya
Huzita.
Maringá
2013
Dados Internacionais de Catalogação na Publicação (CIP)
(Biblioteca Central - UEM, Maringá, PR, Brasil)
Schemberger, Elder Elisandro
S323m MoRE-GSD : uma abordagem para elicitação e
análise de requisitos a partir das regras de negócio
no contexto de desenvolvimento distribuído de
software / Elder Elisandro Schemberger. -- Maringá,
2013.
141 f. : il. color., figs., tabs.
Orientadora: Prof.ª Dr.ª Elisa Hatsue Moriya
Huzita.
Dissertação (mestrado) - Universidade Estadual de
Maringá, Centro de Tecnologia, Departamento de
Informática, Programa de Pós-Graduação em Ciência da
Computação, 2013.
1. Desenvolvimento Distribuído de Software (DDS).
2. Elicitação e análise de requisitos. 3. Modelagem
de processos de negócio. I. Huzita, Elisa Hatsue
Moriya, orient. II. Universidade Estadual de
Maringá. Centro de Tecnologia. Departamento de
Informática. Programa de Pós-Graduação em Ciência da
Computação. III. Título.
CDD 22.ed. 004.21
AMMA-00932
AGRADECIMENTOS
Em primeiro lugar, a Deus, autor e consumador de minha fé, por ter me amparado a cada dia.
Reconheço que sem Ele, não teria capacidade para trilhar caminhos tão longos e vitoriosos.
A meus pais, Mercedes e Valmir Schemberger, que são motivo de inspiração e
orgulho, pelo incondicional apoio em tudo, pois ainda que passando por momentos difíceis,
nunca deixam de pensar um só minuto no bem de seus filhos. Amo vocês incondicionalmente.
Dedico este trabalho especialmente a vocês!
À minha linda esposa Josianne, por tudo que representa para mim. Obrigado por ser,
antes de tudo, minha melhor amiga, e compartilhar comigo a mais de 6 anos, tantos anseios e
sonhos, mas também tristezas e frustações. Não chegaria até aqui sem você por perto. A
melhor parte de mim, com certeza, é você. Te amo.
À minha filha Sofia, cujo download só finalizará em meados de Abril, mas já é amada
por todos, e mudou totalmente a vida de quem está tão ansiosamente esperando por sua
chegada, inclusive eu.
Aos meus amigos de Cascavel (sem citar nomes, pois certamente esqueceria alguém!
Parei de listar e retirei os nomes quando passaram de 40). Muito obrigado pela compreensão
de tantas vezes que disse não para um happy hour, por estar ausente em diversos momentos
importantes. Alguns desafios exigem de nós a abstinência de muita coisa, mas são
temporários, ao contrário de nossa amizade.
À minha admirável orientadora, Dra. Elisa Hatsue Moriya Huzita, por sua paciência,
compartilhamento de conhecimento, incentivo, e puxadas de orelha. Obrigado por acreditar
em mim. Aprendi contigo a ser um professor melhor, um orientador melhor, a dividir melhor
o que detenho! Carregarei comigo estas lições.
A meus colegas de mestrado Sidgley, Alan, Antonio e Kenzo, pela parceria desde o
início, principalmente nas desgastantes viagens. Aos colegas do LDDS, pela mútua
colaboração sempre. A todos os demais colegas das turmas ingressantes em 2010 e 2011.
Alguns se tornaram ótimos amigos, frutos colhidos também deste período de Mestrado.
A todos os professores do DIN-UEM.
A Inês, secretária do DIN-UEM, pela disposição de sempre ajudar em tudo,
executando tarefas muitas vezes além do seu escopo.
Aos professores Dra. Tania Tait e Dr. Victor Santander por aceitarem fazer parte da
minha banca, como avaliadores e, pela notória contribuição que trouxeram a este trabalho.
Por fim, à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES),
que financiou parte do estudo por meio do Programa Nacional de Cooperação Acadêmica
(PROCAD).
MoRE-GSD – Uma abordagem para elicitação e análise de requisitos a partir
das regras de negócio no contexto de desenvolvimento distribuído de software
RESUMO
O Desenvolvimento Distribuído de Software (DDS) é uma estratégia de desenvolvimento que
atende às necessidades da globalização no que tange a produtividade, mão de obra qualificada
disponível, desenvolvimento 24 horas por dia e, consequentemente, redução de custos. No
entanto, o DDS acrescentou novos elementos ao processo de desenvolvimento, tais como a
distância temporal, dispersão geográfica e diferenças socioculturais, que amplificaram os
desafios do desenvolvimento de software e, sobretudo, acrescentaram novas exigências aos
processos de comunicação, coordenação e controle dos projetos desenvolvidos. Outra grande
área que merece atenção especial é a Elicitação e Análise de Requisitos (EAR), haja vista sua
grande importância para o sucesso de um produto de software. É fato que, se esta etapa for
mal executada, gera retrabalho, aumento do custo do projeto, maximiza a probabilidade de
fornecer um produto com excesso ou falta de funcionalidades que atendam às necessidades do
cliente, ou ainda levar um projeto ao fracasso. Para diminuir ambiguidades e melhorar o nível
de assertividade na EAR, é crescente o uso de técnicas de modelagem de processos de
negócio com o objetivo de auxiliar o processo de EAR. Este trabalho apresenta uma
abordagem para guiar a EAR, apoiada pela modelagem das regras de negócio, no contexto de
DDS, por equipes que atuam, principalmente, no modelo Offshoring. Com isso, buscou-se
minimizar alguns desafios que o DDS apresenta, principalmente no que se refere a
organização e a comunicação entre equipes que realizam a EAR de um mesmo projeto,
melhorando o aproveitamento dos requisitos identificados com a redução de possíveis
ambiguidades, bem como diminuindo o tempo investindo, uma vez que o acesso à mão de
obra qualificada e o desenvolvimento 24 horas por dia podem ser facilitados com o uso de
uma abordagem específica. Como avaliação da abordagem, foi realizado um estudo de
viabilidade, que seguiu os princípios da engenharia experimental, aplicando-a em um projeto
real de EAR em DDS. Os profissionais participantes do estudo foram caracterizados e, após o
uso da abordagem, dados foram coletados a fim de verificar a percepção destes profissionais
quanto à utilidade e a facilidade de uso da abordagem proposta.
Palavras-chave: Desenvolvimento Distribuído de Software. Elicitação e Análise de
Requisitos. Modelagem de Processos de Negócio.
MoRE-GSD - An appro ach to elicitation and requirements analysis from the
business rules in context of global software development.
ABSTRACT
The Global Software Development (GSD) is a development strategy that meets the needs of
globalization related to productivity, skilled labor available, developing 24 hours a day and
thus reducing costs. However, GSD added new elements to the development process, such as
the temporal distance, geographic dispersion and sociocultural differences, which amplified
the challenges of software development. Therefore, demands on communication processes,
coordination and control of the developed projects grew. Another major area that deserves
special attention is the elicitation and analysis of requirements (EAR), due to its importance
for the success of a software product. It is a fact that if this step is performed poorly generates
rework, increases project cost, maximizes the probability of resulting in a product with excess
or lack of features that meet customer needs, or even take an entire project to failure. In order
to reduce ambiguities and improve the level of assertiveness in the EAR, is increasing the use
of techniques for modeling business processes in order to assist the EAR process. This
dissertation presents an approach to guide the EAR, supported by modeling of business rules
in the context of GSD, for teams working mainly in Offshoring model. Thus, the idea is to
reduce some of the challenges that the GSD presents, especially with regard to the
organization and communication between teams that perform the activity of EAR in a single
project. It is also intended to increase the use of the requirements identified by reduction of
possible ambiguities, as well as reducing the time invested since access to skilled labor and
24 hour development can be facilitated with the use of a specific approach. A feasibility study
was conducted, to assess the approach. It was performed by following the principles of
experimental engineering, applying the proposed approach in a real project with teams
considering GSD context. The professionals participating in the study were characterized
and, after using the approach, data were collected to verify their awareness about the
usefulness and usability of the proposed approach.
Keywords: Global Software Development. Elicitation and Requirements Analysis. Modeling
Business Processes.
LISTA DE FIGURAS
Figura 1.1. Sequenciamento das etapas da pesquisa... ............................................................. 17
Figura 2.1. Modelos de Negócio em DDS ............................................................................... 23
Figura 2.2. Desafios em DDS e suas correlações ..................................................................... 25
Figura 2.3. Desafios da ER nos ambientes de DDS ................................................................. 26
Figura 3.1. Etapas do processo de pesquisa.............................................................................. 38
Figura 3.2. Atividades executadas em cada fase da etapa de execução ................................... 42
Figura 4.1. Esquematização do Capítulo 4.1. ........................................................................... 50
Figura 4.2. Visão funcional versus visão processual.. .............................................................. 51
Figura 4.3. Modelagem de um SI utilizando orientação por processos.. .................................. 55
Figura 4.4. Estrutura de modelagem CIMOSA. ....................................................................... 57
Figura 4.5. Elementos básicos da Rede de Petri ....................................................................... 61
Figura 4.6. Diagrama de atividades e estereótipos de processos de negócio............................ 69
Figura 5.1. Arcabouço da abordagem MoRE-GSD .................................................................. 79
Figura 5.2. Visão geral da abordagem MoRE-GSD ................................................................. 82
Figura 5.3. Ilustração após as diretivas 1 e 2 do Passo 2 da abordagem MoRE-GSD ............. 87
Figura 6.1. Etapas do experimento da abordagem MoRE-GSD............................................... 94
Figura 6.2. Respostas relacionadas à percepção de Utilidade da MoRE-GSD ...................... 107
Figura 6.3. Respostas relacionadas à percepção de Facilidade de Uso da MoRE-GSD ........ 110
Figura 6.4. Respostas relacionadas ao follow-the-Sun ........................................................... 112
Figura 6.5. Respostas relacionadas à questão de artefatos e organização .............................. 112
Figura 6.6. Respostas relacionadas à questão de artefatos e comunicação ............................ 113
Figura 6.7. Aproveitamento dos requisitos ............................................................................. 114
Figura 6.8. Adoção da MoRE-GSD........................................................................................ 115
LISTA DE TABELAS
Tabela 2.1. Resumo da análise das abordagens descritas ......................................................... 34
Tabela 3.1. Itens do plano do levantamento exploratório......................................................... 39
Tabela 3.2. Descrição dos participantes da pesquisa ................................................................ 41
Tabela 3.3. Resumo da fase de coleta de dados........................................................................ 43
Tabela 3.4. Descrição dos tópicos de análise por empresa ....................................................... 45
Tabela 3.5. Confirmação das proposições do Plano de Estudo ................................................ 47
Tabela 4.1. Elementos do BPMN ............................................................................................. 63
Tabela 4.2. Gateways do BPMN .............................................................................................. 64
Tabela 4.3. Eventos do BPMN ................................................................................................. 65
Tabela 4.4. Classificação de regras de negócio........................................................................ 71
Tabela 5.1. Diretrizes do Passo 1 da abordagem MoRE-GSD................................................. 85
Tabela 5.2. Diretrizes do Passo 2 da abordagem MoRE-GSD ................................................. 87
Tabela 5.3. Diretriz para o nível de detalhamento das regras de negócio ................................ 89
Tabela 5.4. Diretrizes para modelagem processos de negócios da abordagem MoRE-GSD ...90
Tabela 5.5. Diretrizes para representação dos requisitos de sistema ........................................ 92
Tabela 6.1. Descrição das empresas participantes do experimento. ......................................... 99
Tabela 6.2. Caracterização dos participantes do experimento. ............................................... 100
Tabela 6.3. Escala de mensuração das respostas do Questionário Q03 ................................. 104
Tabela 6.4. Resultados obtidos para as variáveis dependentes (A) a (G) - Utilidade. ........... 105
Tabela 6.5. Resultados obtidos para as variáveis dependentes (H) a (N) - Facilidade de
Uso..........................................................................................................................................108
Tabela 6.6. Análise descritiva - Utilidade .............................................................................. 110
Tabela 6.7. Análise descritiva - Facilidade de Uso. ................................................................109
LISTA DE ABREVIATURAS E SIGLAS
ARIS Architecture for Integrated Systems
BPMN Business Process Modeling Notation
BRD Business Requirement Document
CIMOSA Computer Integrated Manufacturing Open System Architecture
DDS Desenvolvimento Distribuído de Software
EAR Elicitação e Análise de Requisitos
EPN Engenharia de Processos de Negócio
ER Engenharia de Requisitos
GSD Global Software Development
IDEF Integration Definition Methods
MoRE-GSD
Modeling Business Process for Requirements Elicitation in Global
Software Development
MPN Modelagem de Processos de Negócio
PROCAD Programa Nacional de Cooperação Acadêmica
RdP Redes de Petri
RN Regras de Negócio
SI Sistemas de Informação
UML Unified Modeling Language
UP Unified Process
SUMÁRIO
Introdução ............................................................................................................................... 13
1.1. Motivação Para o Trabalho ....................................................................................... 14
1.2. Objetivos ...................................................................................................................... 15
1.3. Método de Pesquisa .................................................................................................... 16
1.4. Etapas da Pesquisa e Estrutura do Documento ....................................................... 16
Revisão Bibliográfica .............................................................................................................. 19
2.1. Considerações Iniciais ................................................................................................ 19
2.2. Engenharia de Processos de Negócios (EPN) ........................................................... 19
2.2.1. Regras de Negócios ............................................................................................... 20
2.3. Engenharia de Requisitos (ER) ................................................................................. 21
2.3.1. Processos da Engenharia de Requisitos ................................................................. 22
2.4. Desenvolvimento Distribuído de Software (DDS) .................................................... 22
2.4.1. Desafios do Desenvolvimento Distribuído de Software ........................................ 24
2.5. Engenharia de Requisitos em DDS ........................................................................... 25
2.6. Trabalhos Relacionados ............................................................................................. 27
2.6.1. Descrição das Abordagens Relacionadas .............................................................. 27
2.6.2. Análise das Abordagens Descritas......................................................................... 30
2.6.2.1. Adoção da Modelagem de Processos .................................................................... 30
2.6.2.2. Emprego de ferramentas para a modelagem dos processos de negócios ............... 31
2.6.2.3. Nível de detalhamento dos processos de negócio.................................................. 31
2.6.2.4. Abordagem do Conceito de Regras de Negócio .................................................... 32
2.6.2.5. Emprego de métodos, técnicas, notações ou ferramentas para a representação dos
requisitos de sistema ................................................................................................................. 33
2.7. Considerações Finais .................................................................................................. 35
Características da EAR na Indústria ................................................................................... 36
3.1. Considerações Iniciais ................................................................................................ 36
3.2. O Projeto de Pesquisa ................................................................................................ 37
3.3. Metodologia do Projeto de Pesquisa ......................................................................... 37
3.4. Planejamento ............................................................................................................... 38
3.5. Execução ...................................................................................................................... 39
3.5.1. Coleta de Dados.................................................................................................... 42
3.5.2. Análise Preliminar da Coleta de Dados ............................................................. 44
3.5.3. Confiabilidade e Análise dos Dados ................................................................... 44
3.6. Considerações finais ................................................................................................... 47
Modelagem de Processos de Negócio .................................................................................... 49
4.1. Considerações Iniciais ................................................................................................ 49
4.2. Princípios da Modelagem de Processos de Negócio ................................................. 50
4.2.1. Níveis de Detalhamento ......................................................................................... 52
4.2.2. Metodologias de Modelagem ................................................................................ 53
4.2.2.1. ARIS (Architecture for Integrated Systems).......................................................... 54
4.2.2.2. CIMOSA (Computer Integrated Manufacturing Open System Architecture) ....... 56
4.2.2.2.1. Estrutura da Modelagem CIMOSA ....................................................................... 56
4.2.2.3. IDEF (Integration Definition Methods) ................................................................. 58
4.2.2.4. Redes de Petri ........................................................................................................ 60
4.2.2.5. BPMN (Business Process Modeling Notation) ..................................................... 61
4.2.2.5.1. Elementos do BPMN ............................................................................................. 62
4.2.2.5.2. Filtros de decisão BPMN (gateways) .................................................................... 63
4.2.2.5.3. Eventos em BPMN ................................................................................................ 64
4.2.2.6. Modelagem de Processos de Negócio com UML ................................................. 65
4.3. Regras de Negócio ....................................................................................................... 69
4.3.1. Modelagem de Regras de Negócio ........................................................................ 72
4.4. Considerações Finais .................................................................................................. 74
MoRE-GSD – A Abordagem Proposta ................................................................................. 76
5.1. Considerações Iniciais ................................................................................................ 76
5.2. Arcabouço da Abordagem MoRE-GSD ................................................................... 78
5.3. Detalhamento da Abordagem MoRE-GSD .............................................................. 80
5.3.1. Aplicação do Conceito de Processos de Negócios – Passo 1 ................................ 83
5.3.2. Documentação das Regras de Negócios – Passo 2 ................................................ 85
5.3.2.1. Nível de Detalhamento dos Processos de Negócio ............................................... 87
5.3.3. Modelagem dos Processos de Negócios – Passo 3 ................................................ 89
5.3.4. Representação dos Requisitos de Sistema – Passo 4 ............................................. 90
5.4. Considerações Finais .................................................................................................. 91
Estudo de Viabilidade ........................................................................................................... 93
6.1. Considerações Iniciais ................................................................................................ 93
6.2. Definição dos Objetivos .............................................................................................. 94
6.2.1. Objetivo Global ..................................................................................................... 94
6.2.2. Objetivo da Medição.............................................................................................. 94
6.2.3. Objetivo do Estudo ................................................................................................ 95
6.2.4. Questões de Estudo ................................................................................................ 95
6.3. Planejamento ............................................................................................................... 95
6.3.1. Definição das hipóteses ......................................................................................... 95
6.3.2. Seleção do Contexto e dos Participantes ............................................................... 96
6.3.3. Projeto do Estudo e Instrumentação ...................................................................... 99
6.3.4. Validade do Experimento ...................................................................................... 99
6.3.4.1. Validade Interna................................................................................................... 100
6.3.4.2. Validade Externa ................................................................................................. 100
6.3.4.3. Validade Construtiva ........................................................................................... 100
6.3.4.4. Validade Conclusiva ............................................................................................ 100
6.4. Execução do Experimento ....................................................................................... 101
6.4.1. Resultados Obtidos .............................................................................................. 102
6.5. Análise e Interpretação do Experimento ................................................................ 104
6.5.1. Validação dos Dados ........................................................................................... 104
6.5.2. Estatística Descritiva – Utilidade......................................................................... 105
6.5.3. Estatística Descritiva – Facilidade de Uso........................................................... 108
6.5.4. Análise Comparativa ........................................................................................... 110
6.5.5. Verificação das Hipóteses.................................................................................... 114
6.6. Considerações Finais ................................................................................................ 114
Conclusões ............................................................................................................................ 116
7.1. Dificuldades e Limitações ........................................................................................ 118
7.2. Contribuições ............................................................................................................ 118
7.3. Trabalhos Futuros .................................................................................................... 119
Referências ............................................................................................................................ 120
Apêndice A ............................................................................................................................ 127
Apêndice B ............................................................................................................................ 129
Apêndice C ............................................................................................................................ 130
Apêndice D ............................................................................................................................ 131
Apêndice E ............................................................................................................................ 134
Apêndice F ............................................................................................................................. 135
Apêndice G ............................................................................................................................ 139
13
Introdução
Em busca de equipe qualificada, conquista de novos mercados, maior competitividade e,
principalmente, de redução de custos, organizações que trabalham com desenvolvimento de
software têm espalhado seus projetos, formando equipes que se localizam geograficamente
distribuídas (Sangwan et al., 2006; Sengupta et al., 2006; Herbsleb, 2007). O número de
empresas que estão distribuindo seus processos de desenvolvimento de software ao redor do
mundo é cada vez mais significativo (Prikladnicki e Audy, 2004).
Embora esta configuração traga muitos benefícios, carrega consigo vários desafios
relacionados a fatores técnicos (problemas de conectividade em rede e diferenças entre
ambientes de desenvolvimento e teste) e a fatores não técnicos (confiança, comunicação,
conflitos, diferenças culturais, entre outros) (Damian e Zowghi, 2002; Herbsleb et al. 2000).
Inerente às questões técnicas do desenvolvimento de software, tanto local quanto
distribuído, um dos pontos que gera grandes discussões, tanto na academia quanto na
indústria, é a complexidade das atividades de Elicitação e Análise de Requisitos (EAR) que,
quando realizada com equipes locais já apresenta desafios. Ao considerar a dispersão
geográfica destas equipes, tais desafios aumentam significativamente.
Neste contexto, uma área que há algum tempo tem ganhado destaque, e que cada vez
mais é associada ao desenvolvimento de software, principalmente à etapa de EAR, é a
Engenharia de Processos de Negócio (EPN). Dentre os objetivos desta área é possível
destacar: (i) a uniformização do entendimento de como ocorre o trabalho em uma
organização; (ii) a viabilidade para tornar explícito o conhecimento acerca dos processos, a
1
Capítulo
14
execução de simulações para apoiar a tomada de decisão, entre outras (Grover e Kettinger,
2000). Tais objetivos notoriamente auxiliam a elicitação e análise dos requisitos funcionais de
um software. Portanto, torna-se interessante associar técnicas da EPN nesta etapa da
Engenharia de Requisitos (ER), principalmente, ao considerar o contexto de desenvolvimento
de software que ocorre de maneira distribuída.
1.1. Motivação Para o Trabalho
Na literatura corrente existem algumas propostas (Proforma, 1998; Rational, 2000; Eriksson e
Penker, 2000; Santander e Castro, 2000; Tyndale-Biscoe, 2002; Silveira et. al., 2002; Cruz,
2004; Knight, 2004; Vicente, 2004; Villanueva, 2005; Dias et al., 2006; Azevedo Junior e
Campos, 2008; Viera et al., 2012) para integrar técnicas da EPN com a Elicitação e Análise
de Requisitos (etapa da ER), mas que apresentam conflitos entre si, pecando em aspectos
determinantes, e desprezando outros mais recentes, como: a adoção do conceito e a utilização
de ferramentas para a modelagem de processos de negócio; fazer uso do conceito de regras de
negócio e direcionar o nível de detalhamento destas; usar métodos, técnicas e notações
associados às ferramentas para representar os requisitos de sistema, entre outros que serão
descritos ao longo dos Capítulos 2 e 3.
Ao ser considerado um cenário de equipes desenvolvendo software geograficamente
distribuídas, não foram encontrados na literatura, até o momento, propostas que associem
técnicas da EPN à Elicitação e Análise de Requisitos.
Aliado a isso, há na indústria de software uma grande necessidade abordagens que
contemplem estes cenários somados, principalmente pelo crescimento do DDS. As empresas
propõem estratégias particulares embasadas apenas no conhecimento empírico de seus
colaboradores, e que apresentam muitos gaps, haja vista que a evolução destas técnicas é
motivada apenas pela necessidade, sem qualquer embasamento teórico-científico. Isso foi
constatado ao longo deste trabalho e é descrito no Capítulo 3 e, também, citado em outros
pontos do texto.
Motivado pelos desafios da etapa de EAR associada ao Desenvolvimento Distribuído
de Software – DDS, é importante que se busque por uma estratégia para guiar a elicitação e
análise de requisitos por equipes geograficamente distribuídas, fazendo uso da Modelagem de
Processos de Negócio.
15
1.2. Objetivos
O objetivo geral desta dissertação é propor uma abordagem para guiar a Elicitação e Análise
de Requisitos, a partir de princípios da Engenharia de Processos de Negócio para equipes que
trabalham com Desenvolvimento Distribuído de Software.
Com isto, buscar-se-á oferecer apoio ao desenvolvimento distribuído de software,
melhorando a comunicação entre equipes que realizam a EAR a fim de reduzir a ambiguidade
nos artefatos gerados nesta etapa, e aumentar os benefícios inerentes ao DDS.
Para tal, é possível listar como objetivos específicos:
Estudo sobre as áreas de engenharia de processos de negócio, engenharia de
requisitos, e desenvolvimento distribuído de software;
Estudo direcionado para regras de negócio (no contexto de EPN), elicitação e
análise de requisitos (no contexto de ER), e particularidades associadas ao
contexto de DDS;
Análise de trabalhos correlatos que abordam o contexto de EPN e ER a fim de
mapear de maneira comparativa pontos cobertos e não cobertos pelos mesmos;
Realização de visitas a empresas desenvolvedoras de software que atuam com o
modelo de desenvolvimento distribuído, para coletar características presentes na
fase de EAR dos projetos destas empresas;
Descrever uma abordagem para guiar a EAR com o apoio da modelagem de
processos de negócio para equipes que trabalham com desenvolvimento
distribuído de software;
Aplicação dessa abordagem em um cenário de desenvolvimento distribuído de
software real a fim de aferir sua viabilidade e visualizar melhorias.
Deste modo, este trabalho visa contribuir com a área de Engenharia de Software –
notadamente com as atividades de EAR, explorando algumas práticas e técnicas de
Engenharia de Processo de Negócio – principalmente a modelagem de processos de negócios,
de forma a promover um melhor alinhamento dos Sistemas de Informações (SIs) com as
estratégias do negócio quando é considerado o contexto de Desenvolvimento Distribuído de
Software.
16
1.3. Método de Pesquisa
A realização desta pesquisa engloba diferentes áreas do conhecimento. A detecção da lacuna
motivadora surgiu da revisão bibliográfica somada às experiências ex-post facto (a partir de
fatos passados). Neste âmbito, a revisão bibliográfica também proporcionou: (i) obter os
conhecimentos necessários para identificação de modelos de negócio que se fazem presentes
na literatura da engenharia de requisitos, (ii) alinhar estes modelos ao contexto de DDS, e (iii)
criar as hipóteses características do modelo proposto, que agrupa Regras de Negócio,
Engenharia de Requisitos e DDS.
As experiências ex-post facto oportunizaram definir os campos de maior significância
de aplicação e características associadas ao desenvolvimento deste trabalho, haja vista a
necessidade de soluções neste contexto requeridas por pequenas e grandes empresas
produtoras de software, e também, ao gap identificado na literatura especializada, conforme
descrito no Capítulo 3.
Neste texto, são apresentadas características de uma pesquisa descritiva, na análise das
técnicas e disciplinas envolvidas, e também exploratórias, na busca de uma estratégia de
apoio à definição de requisitos de sistema em um ambiente de DDS a partir das regras de
negócio.
Essa junção objetiva desenvolver, esclarecer e modificar conceitos e ideias, tendo em
vista, a formulação de problemas mais precisos ou hipóteses melhor direcionadas para estudos
posteriores (Gil, 1999).
É possível classificar o procedimento adotado como pesquisa-ação – que é
caracterizada pela base empírica em que é concebida e realizada em estreita associação com
uma ação ou com a resolução de um problema coletivo, e na qual os pesquisadores e
participantes representativos da situação ou do problema estão envolvidos de modo
cooperativo ou participativo (Thiollent, 1997).
1.4. Etapas da Pesquisa e Estrutura do Documento
A pesquisa está vinculada a projeto de pesquisa desenvolvido pelo grupo de estudos em
desenvolvimento de distribuído de software da Universidade Estadual da UEM e está
estruturada conforme a Figura 1.1 ilustra:
17
Figura 1.1. Sequenciamento das etapas da pesquisa.
Os capítulos deste texto estão estruturados da seguinte forma:
No Capítulo 2 é apresentada uma revisão bibliográfica que contempla os temas
EPN, EAR e DDS. São também apresentados bem como analisados alguns
trabalhos correlatos;
O Capítulo 3 descreve a Elicitação e Análise de Requisitos na indústria, a fim
de caracterizar e melhor direcionar a abordagem proposta no Capítulo 5;
O Capítulo 4 é dedicado exclusivamente à modelagem de processos de
negócio, destacando técnicas e conceitos inerentes a esse tema;
No Capítulo 5 é apresentada a abordagem, que propõe guiar a elicitação e
análise de requisitos por equipes que atuam com desenvolvimento distribuído
de software, fazendo uso da modelagem dos processos de negócio;
Um estudo experimental para a abordagem proposta é apresentado no Capítulo
6, o qual analisa a viabilidade de seu uso em empresas que desenvolvem
software de maneira distribuída;
Engenharia de Processos de Negócios / Modelagem de Processos de Negócios
Engenharia de Requisitos / Elicitação e Análise de
Requisitos
Desenvolvimento Distribuído de Software (DDS)
Revisão Bibliográfica
Identificação e Análise de técnicas da EPN (principalmente de modelagem
de processos de negócios)
Identificação e Análise dos desafios da Elicitação e Análise de Requisitos,
segundo a literatura especializada
Elaboração de uma abordagem para elicitação e análise de requisitos apoiado pela modelagem de processos de negócios em ambientes de DDS
Aplicação da abordagem na indústria a fim de avaliá-la
Análise dos resultados obtidos, e escrita da dissertação.
Identificação dos desafios para Elicitação e Análise de Requisitos nas empresas que trabalham com desenvolvimento distribuído de software
18
E, por fim, no Capítulo 7 são descritas as considerações finais deste trabalho,
realizando um fechamento do assunto abordado bem como apresentado
sugestões para trabalhos futuros.
19
Revisão Bibliográfica
2.1. Considerações Iniciais
A concepção de uma abordagem que permita que a EAR em ambientes de DDS possa ser
realizada com o apoio da modelagem das regras de negócio necessita de fundamentação
sólida e baseada em estudos tangentes e correlatos a esta temática.
Deste modo, este capítulo contempla conceitos que subsidiam o desenvolvimento da
dissertação, relacionados à:
Engenharia de Processos de Negócios – Modelagem de Processo e Regras de
Negócios;
Engenharia de Requisitos – Elicitação e Análise de Requisitos;
Desenvolvimento Distribuído de Software
As seções seguintes abordam individualmente cada um destes temas.
2.2. Engenharia de Processos de Negócios (EPN)
Segundo Cameira e Caulliraux (2000), a EPN pode ser definida como sendo uma “técnica
utilizada quando se deseja entender ou mapear como parte de uma organização, uma
organização, ou ainda um conjunto de organizações operam, como são realizados os
processos, como a informação flui através desses processos, suas interfaces, quais recursos
são utilizados, quem realiza as diversas atividades, para permitir entender as cadeias de valor
existentes.”
2
Capítulo
20
Dentre os objetivos da EPN, destacam-se (Grover e Kettinger, 2000):
Uniformizar o entendimento da forma como ocorre o trabalho;
Analisar e promover a melhoria do fluxo informacional;
Tornar explícito o conhecimento acerca dos processos;
Gerar simulações para apoiar a tomada de decisão;
Promover a gestão organizacional.
Para Santos (2002), a EPN tem sua importância justificada em algumas tendências, a
saber: (i) interfuncionalidade dos processos, devido à diversidade e multiplicidade de
conhecimentos aplicados na execução organizacional; (ii) personalização que requer
customizações agregando complexidade aos processos; (iii) necessidade de redução dos ciclos
de vida dos produtos e serviços, haja vista o aumento da inovação organizacional; (iv)
incentivo à competição globalizada com produtos e serviços, gerados pelos processos,
distribuídos em diferentes áreas geográficas e adequados às necessidades dos clientes; (v)
integração das cadeias de suprimentos, gerando maior flexibilidade e integração dos
processos, e; (vi) valorização dos profissionais do conhecimento, que com sua capacidade de
aprendizado e acúmulo de experiências se mostra fundamental num ambiente de maior
complexidade.
Deste modo, a EPN, ao realizar o mapeamento dos processos de negócio, possibilita o
entendimento de como se comportam os fluxos de atividades e informações no ambiente
organizacional (Santos, 2002).
2.2.1. Regras de Negócios
No domínio de um negócio, todas as decisões tomadas são baseadas em fatos. Para que tais
decisões sejam adequadas, é necessário que as regras que guiam o negócio sigam também
uma lógica correta. Assim, a tomada de decisão correta está diretamente relacionada a regras
consistentes e qualificadas, bem como à disponibilidade das informações aos tomadores de
decisão e aos Sistemas de Informação (SI) envolvidos. Essas regras e fatos são conhecidos
como regras de negócio (Von Halle, 2002).
Deste modo, as regras de negócio podem controlar ou influenciar a execução dos
processos de negócio e sua estrutura de recursos, restringindo ou condicionando a execução
de certas atividades, buscando a aderência aos objetivos organizacionais (Bubenko et al.,
2001).
21
Para Gottesdiener (1997), as regras de negócio promovem a verdadeira integração
entre as pessoas do negócio e a tecnologia, pois posicionam os membros da organização como
elementos centrais das atividades de software. Deste modo, é possível perceber a relação
estreita entre regras de negócio e SI. O entendimento de regras de negócio é uma forma
efetiva de descobrir os requisitos principais dos SI, promovendo iniciativas que tentam
aproximar a abordagem do negócio, representada pelos seus processos, do processo de
desenvolvimento de sistemas, que se inicia com a etapa de elicitação de requisitos.
2.3. Engenharia de Requisitos (ER)
Para um projeto de software ser considerado de sucesso, é preciso que ele realize, de fato, as
tarefas para as quais foi proposto. Para tal, a identificação precisa e detalhada de seu escopo é
essencial (Sommerville, 2007).
O entendimento dos propósitos do software, do ambiente onde será inserido e do
negócio da empresa são fatores importantes para auxiliar na análise e documentação das
necessidades dos stakeholders. Estas necessidades são convertidas em requisitos de software
que descrevem como o sistema deve se comportar, contendo informações do domínio da
aplicação, restrições de operações e especificações de propriedades do sistema (Kotonya e
Sommerville, 1998).
Para Sommerville (2007), requisitos de software são, frequentemente, classificados em
Requisitos Funcionais – que descrevem as funções do sistema e como ele deve reagir a
determinadas entradas; Requisitos Não-Funcionais – que descrevem restrições (de tempo, de
confiabilidade, etc.) sobre funções que o sistema fornece; e Requisitos de Domínio – que
descrevem características do domínio da aplicação, podendo ser requisitos funcionais ou não
funcionais.
O processo de descobrir, analisar, documentar e verificar essas funções e restrições é
chamado de Engenharia de Requisitos (Sommerville, 2007). Este processo inclui atividades
para identificar, descrever e manter um conjunto de requisitos de um sistema. A ER fornece
mecanismos apropriados para entender o que o cliente deseja, analisar as necessidades,
verificar possibilidades, negociar uma solução e especificar uma solução entendível, validar
esta especificação e gerenciar os requisitos conforme eles se transformam em um software
(Pressman, 2006).
22
2.3.1. Processos da Engenharia de Requisitos
No contexto da Engenharia de Requisitos (ER), é possível desenvolver um processo próprio
ou ainda adaptar processos existentes, a fim de melhor adequá-los ao contexto exigido. As
propostas de processos em ER são muitas e variadas, todavia, a literatura é quase unânime em
dividir nas etapas de (i) estudo da viabilidade; (ii) elicitação e análise dos requisitos; (iii)
especificação e (iv) validação de requisitos.
Destas etapas, destaca-se neste ínterim a “elicitação e análise de requisitos”, que
corresponde à identificação das expectativas e necessidades dos stakeholders em relação ao
software que será desenvolvido (Sommerville, 2007). Segundo Kotonya e Sommerville
(1998), os requisitos podem ser obtidos por meio de consultas a clientes e/ou usuários,
documentos do sistema, conhecimento do domínio e estudos de mercado.
Por ser uma área de grande relevância para o sucesso do desenvolvimento de um
software, a ER frequentemente apresenta vários desafios relacionados, por exemplo, à
possibilidade de uma grande quantidade de stakeholders envolvidos, e que podem possuir
objetivos e perspectivas conflitantes sobre o sistema, não explicitam claramente seus desejos
por não saberem o que querem, ou mesmo por dificuldades de expressar de maneira precisa
suas necessidades (Sommerville, 2007).
Há também dificuldades em identificar os stakeholders e seus graus de envolvimento
no projeto, as comunicações entre os envolvidos podem não fluir claramente, requisitos
podem ser esquecidos ou mal interpretados, as diferenças culturais podem levar a
desentendimentos, entre várias outras (Audy e Prikladnicki, 2007).
2.4. Desenvolvimento Distribuído de Software (DDS)
No atual contexto, os Sistemas de Informação (SI) desempenham um importante papel dentro
das organizações, auxiliando-as a atingir seus objetivos operacionais e estratégicos.
A crescente globalização do ambiente de negócios e da economia, adicionada ao
avanço tecnológico, alta competitividade, aumento do tamanho e número de equipes,
dificuldade em reunir especialistas e aumento da complexidade das aplicações desenvolvidas
têm afetado o mercado de software. Estes aspectos, unidos à ideia da terceirização a fim de
buscar vantagem competitiva, motivaram diversas organizações a optarem por distribuir
geograficamente o processo de desenvolvimento de software, caracterizando deste modo o
DDS (Huzita et al. 2008; Audy e Prikladnicki, 2007).
23
Segundo Carmel (1999), vários são os fatores que contribuíram para acelerar o
surgimento do DDS, entre eles destacam-se:
Produção 24 horas por dia (follow-the-sun);
Necessidade de recursos globais para serem utilizados a qualquer momento e
de redução de custos;
Proximidade ao usuário final.
A distribuição em DDS pode assumir configurações, de acordo com a distância entre
as equipes e as organizações envolvidas no projeto. Com relação à distribuição geográfica das
equipes envolvidas em um projeto, quando se localizam em mais de um país denomina-se
distribuição offshore, se todas se encontram no mesmo país tem-se a distribuição onshore.
Considerando a relação estabelecida entre as empresas tem-se o outsourcing, cenário em que a
empresa delega o controle sobre as atividades para uma empresa externa à quem contratou o
serviço (terceirização), e o insourcing, em que as empresas criam os seus próprios centros de
desenvolvimento de software em locais separados geograficamente (Audy e Prikladnicki,
2007).
É possível combinar estas configurações, gerando deste modo quatro modelos de
negócios em DDS: (i) Onshore Insourcing (ii) Onshore Outsourcing; (iii) Offshore
Outsourcing; e (iv) Offshore Insourcing (Prikladnicki e Audy, 2004). A Figura 2.1 ilustra estas
configurações.
Relação
entre as
empresas
Terceirizar
Outsource
“Comprar”
Onshore Outsourcing
ou
Outsourcing
Offshore Outsourcing
Ou
Offshoring
Departamento ou
subsidiária
Insource
“Desenvolver”
Onshore Insourcing
Ou
Demanda doméstica
interna
Offshore Insourcing
Ou
Captive / Internal
Offshloring
Onshore / Mesmo País Offshore / Outro País
Localização Geográfica
Figura 2.1. Modelos de Negócio em DDS (Audy e Prikladnicki, 2007).
Segundo Begel e Nagappan (2008), alguns fatores estão diretamente ligados à
aceleração do DDS, como: redução de custos; acesso facilitado à mão de obra e recursos;
avanços na infraestrutura (Internet e desenvolvimento/integração de ferramentas); novos
24
mercados; rápida formação de equipes virtuais; e, melhoria do time-to-market, com o uso do
desenvolvimento “em torno do Sol” – Follow the Sun.
A subseção seguinte descreve alguns dos desafios inerentes ao DDS.
2.4.1. Desafios do Desenvolvimento Distribuído de Software
Para Damian e Zowghi (2002) e Herbsleb et al. (2000), times distribuídos enfrentam desafios
relacionados a fatores técnicos e não técnicos. Os fatores técnicos referem-se a problemas de
conectividade em rede e às diferenças entre os ambientes de desenvolvimento e teste. Já aos
fatores não técnicos têm-se associadas as questões de confiança, comunicação, conflitos e
diferenças culturais.
O DDS acrescentou novos fatores ao processo de desenvolver software, tais como,
distância temporal, dispersão geográfica, diferenças socioculturais, entre outros. Estes fatores
ampliaram alguns dos desafios já existentes na área de Engenharia de Software e adicionaram
novas demandas que desafiam os processos de comunicação, coordenação e controle dos
projetos (Damian et al., 2006).
Os principais desafios encontrados em DDS, de acordo com Herbsleb (2007) e
Damian e Zowgui (2002) relacionam-se às diferenças culturais, dispersões geográficas,
coordenação e controle, comunicação e espírito de equipe. As diferenças culturais,
geralmente, acentuam os problemas de comunicação, e podem levar a estágios de frustração,
descontentamento e até mesmo desentendimento entre as equipes.
Holmstrom et al. (2006), ressaltam que a cultura pode ter um efeito determinante na
forma como as pessoas interpretam determinadas situações, e como elas reagem à estas
situações. As diferenças culturais envolvem a cultura organizacional, cultura nacional, idioma,
política, motivação individual e a ética no trabalho das equipes distribuídas (Carmel, 1999).
A Figura 2.2 apresenta os desafios do DDS e suas correlações.
25
Figura 2.2. Desafios em DDS e suas correlações (Clerc et al. 2007).
As linhas tracejadas da Figura 3 indicam os desafios ampliados por outros desafios, e
as linhas contínuas apontam para os problemas decorrentes em função desta ampliação (Clerc
et al., 2007).
2.5. Engenharia de Requisitos em DDS
Dada a natureza colaborativa e interativa da ER, ela é particularmente afetada quando
realizada por equipes distribuídas.
Entre as questões afetas pode-se citar: dificuldades de comunicação, utilização de
processos inadequados no desenvolvimento de software, uso de técnicas diferentes por
equipes que trabalham em um mesmo projeto, incompatibilidade de ambientes de trabalho,
interesses conflitantes, falta de conhecimento do contexto do projeto, entre outros, impactam
negativamente na especificação dos requisitos, bem como, no gerenciamento dos mesmos
(Herbsleb, 2007).
A Figura 2.3 ilustra como os problemas do DDS impactam na ER:
26
Figura 2.3. Desafios da ER nos ambientes de DDS (Damian e Zowghi, 2002).
Ebling (2009) também destaca estes desafios e salienta alguns agravantes para este
contexto:
Comunicação: A comunicação sobre requisitos nos ambientes de DDS é
desafiadora devido às diferenças culturais, temporais e de linguagem entre as
equipes. A dispersão geográfica dos envolvidos introduz diferentes fusos-
horários e dificulta a comunicação síncrona e assíncrona, causando delay no
processo de desenvolvimento (Damian e Zowghi, 2002; Herbsleb, 2007).
Falta de entendimento comum: Em ambientes de DDS, as dificuldades de
obter entendimento comum dos requisitos são ampliadas (Herbsleb, 2007).
Muito tempo é gasto nesta etapa e a incompreensão dos requisitos somente é
percebida durante as fases de integração do software, quando as alterações são
mais custosas (Sengupta et al., 2006).
Falta de colaboração: A abordagem de DDS acentua os desafios relacionados
à colaboração dos stakeholders. Isto geralmente ocorre devido às diferenças
culturais, de idioma, de processos organizacionais e a dispersão física das
equipes (Damian e Zowghi, 2002; Bhat et al., 2006).
Dificuldades no Gerenciamento de Mudanças: O Gerenciamento de
mudanças dos requisitos é bastante afetado nos ambientes distribuídos,
especialmente quando não existem políticas empresariais bem definidas para
esta área (Sengupta et al., 2006; Bhat, 2006). Damian e Zowghi (2002)
argumenta que a distância entre aqueles que originam as mudanças nos
27
requisitos e aqueles que decidem sobre a implementação destas alterações,
dificulta a definição de um processo rigoroso.
Falta de técnicas e ferramentas específicas: Devido à falta de ferramentas
que apoiem a definição dos requisitos, se torna difícil identificar informações
sobre eles (Sengupta et al., 2006). É interessante desenvolver ou alterar
técnicas existentes para apoiar as tarefas de ER nos ambientes distribuídos
(Cheng, 2007).
Os pontos acima relacionados deixam evidente a necessidade da implementação de
abordagens e estratégias no que tange a associação de técnicas da EPN com a ER. Quando o
cenário é um ambiente de DDS, a necessidade dessa implementação é ainda mais notória, haja
vista os desafios que ambientes com esta característica carregam consigo.
2.6. Trabalhos Relacionados
Esta seção apresenta quatro trabalhos relacionados com a temática da presente pesquisa, que
constituem uma base literária empírica para a elaboração da abordagem proposta que
contempla a elicitação e análise de requisitos a partir da modelagem de processos de negócios
em um ambiente de DDS.
Cabe destacar que os quatro trabalhos aqui detalhados propõem abordagens de
elicitação de requisitos a partir do entendimento e modelagem do conjunto de atividades de
negócio, porém nenhum contempla o contexto de DDS – associação não encontrada até o
momento na literatura.
2.6.1. Descrição das Abordagens Relacionadas
Cruz (2004) desenvolveu um método de identificação de requisitos de sistemas a partir dos
processos de negócio, no qual a questão central é a fragilidade dos SI, que, muitas vezes, se
mostram incompletos devido à ausência de funcionalidades fundamentais ao processo de
negócio e/ou existência de outras funcionalidades muitas vezes consideradas desnecessárias.
Outra questão tratada por Cruz (2004) é a necessidade da ampliação dos mecanismos para
garantir a rastreabilidade dos requisitos funcionais em suas relações com os elementos dos
processos de negócio.
Para alinhar estas questões, Cruz (2004) propôs um método baseado em heurísticas –
que se originaram de experimentos junto com a identificação de regras presentes na literatura
28
que aborda a modelagem de processos e de requisitos, para identificação de requisitos
funcionais de SI a partir do entendimento dos processos de negócio. Assim, a abordagem da
solução proposta por este autor usa como base o entendimento das atividades do negócio
sequenciadas lógica e temporalmente, bem como as relações dessas atividades com os SI.
Na percepção de Knight (2004), um modelo de negócio é aquele que permite melhor
visualização “do que são seus processos, como são executados, quais são suas metas, como
cada processo auxilia em alcançá-las, quais são suas unidades organizacionais, quem são os
envolvidos em cada atividade, quais as localidades por entre as quais a organização está
distribuída e quais os eventos que deflagram seus processos e atividades”. Nesse contexto, a
abordagem da solução proposta por Knight (2004) usa como base a modelagem
organizacional, incluindo os processos de negócio, para a construção dos requisitos. A autora
desenvolve uma sistemática que utiliza o modelo de negócio como um instrumento para
entendimento do mesmo e descoberta dos principais requisitos. Este modelo de negócio é
formado por um conjunto de outros modelos que representam conceitos do negócio. O
método contempla as atividades de análise do problema, elicitação dos requisitos de negócio e
requisitos de usuário.
Dias et al., (2006) apresentam uma abordagem para a transformação automática do
modelo de negócio em modelo de requisitos. Esta abordagem tem como questão de pesquisa a
dificuldade e o insucesso da atividade de modelagem e implementação de SI. Esse insucesso é
demonstrado pela frequência com que as organizações se mostram insatisfeitas com a
qualidade dos seus sistemas.
Na tentativa de minimizar o problema identificado, Dias et al. (2006) apresentam uma
abordagem composta de uma técnica apropriada para tornar mais confiável e natural a
transformação do entendimento do negócio, por meio de suas atividades, em requisitos de
sistema nos projetos de desenvolvimento de SI. Assim, a abordagem aplica o conceito de
processos de negócio definido como um conjunto de atividades estruturadas para geração de
um produto que pode ser um bem ou um serviço. Juntamente com os processos são agregados
ao modelo de negócio elementos como regras de negócio, objetivos e recursos.
Na proposta é utilizado o Diagrama de Atividades da UML para representar os
processos e o Português Estruturado para representar as regras de negócio, por considerarem
esses dois objetos essenciais para a definição de requisitos no processo de desenvolvimento
de sistemas.
Já para definir o modelo de requisitos, Dias et al., (2006) definem o domínio do
problema e as funcionalidades que se espera do sistema. Esse modelo de requisitos é
29
representado por meio do diagrama de classes, que descreve as classes que formam a estrutura
do sistema e as suas relações. E, por meio do diagrama de casos de uso, é representado o
conjunto de funções executadas pelo sistema ao interagir com os atores.
A transformação do modelo de negócio em modelo de requisitos ocorre em duas
etapas: (i) Transformação da definição dos termos em classes – após a definição dos termos
do negócio, faz-se o mapeamento de alguns destes termos em classes de domínio que
compõem o diagrama de classes, onde o critério aplicado para selecionar os termos das
classes é o relacionamento dos atributos; e (ii) Transformação dos processos em casos de uso
– aplicam-se conjuntos de heurísticas ao modelo de processo, e esse modelo é representado
em diagrama de atividades da UML, sendo responsável pela obtenção do respectivo modelo
de requisitos funcionais.
Em um quarto trabalho relacionado, de Azevedo Junior e Campos (2008), a questão
central é a falta de integração entre dois domínios: do negócio e dos sistemas (sendo este
último o responsável pelo suporte e apoio à execução dos processos no primeiro). A
abordagem da solução, além de buscar o entendimento das atividades de negócio
sequenciadas lógica e temporalmente, também usa a técnica de construção de arquiteturas de
negócio proposta por Eriksson e Penker (2000).
A proposta de Azevedo Junior e Campos (2008) busca justamente aplicar a técnica de
Eriksson e Penker (2000) ao UP (Unified Process – Processo Unificado) por meio da criação
de workflows completos para a modelagem de negócio (inexistente na versão original do UP).
As demais fases do UP, a princípio, permanecem inalteradas.
Por fim, estes autores apresentam um projeto piloto de desenvolvimento de sistema em
determinada empresa no qual foi notória uma vantagem da abordagem proposta em relação à
metodologia puramente baseada no UP nos seguintes aspectos: melhor identificação dos
requisitos e artefatos no projeto do sistema (objetivos do negócio, atividades, classes de
objetos e necessidades de informatização do processo de expedição) que não seriam, ou não
seriam tão facilmente, identificados com a metodologia UP original.
As atividades propostas na metodologia de Azevedo Junior e Campos (2008) podem
ser aplicadas em qualquer outra metodologia de desenvolvimento de sistemas que tenha como
fundamento os princípios estabelecidos no UP.
30
2.6.2. Análise das Abordagens Descritas
Para efetuar a análise das abordagens descritas, foram adotados critérios embasados na
literatura da Engenharia de Processos de Negócios, em associação com a literatura de
Engenharia de Software, em especial a Engenharia de Requisitos (abordados do presente
capítulo), e também coletados por meio de experiência in loco em fábricas de software (vide
Capítulo 3). Deste modo, os critérios definidos foram:
Adoção da técnica de modelagem de processos;
Emprego de ferramentas apropriadas para a modelagem dos processos de
negócios;
Nível de detalhamento dos processos de negócio;
Uso do conceito de regras de negócio;
Emprego de métodos, técnicas, notações ou ferramentas para a representação
dos requisitos de sistema.
As subseções seguintes descrevem cada um destes critérios.
2.6.2.1. Adoção da Modelagem de Processos
A modelagem de processos compreende o entendimento da estrutura organizacional, das
regras de negócio que afetam a operação, dos objetivos, das atividades e responsabilidades
dos envolvidos, bem como dos dados manipulados (Nuseibeh e Eeasterbrook, 2000). A
modelagem de processos tem lugar central nos instrumentos da Engenharia de Processos de
Negócios, tornando-se essencial como mecanismo de integração e coordenação em
organizações (Santos, 2002). Com esses modelos torna-se possível capturar as diversas
características do negócio, simplificando a visão real e bem mais complexa do negócio,
conforme explicam Bubenko et al. (2001).
Dada a importância de modelar os processos de negócio, percebe-se que as quatro
abordagens descritas adotam a modelagem de processos como técnica de desenvolvimento de
modelos, mas que são diferentes entre si no que se refere à metodologia e à ferramenta
adotadas para tal. Também não são claras em justificar a escolha da metodologia/ferramenta.
Modelar os processos de negócio, no contexto da abordagem proposta neste trabalho é
essencial, dados os riscos que a atividade de modelar sistemas de informação compreende
(Carvalho, 2009), riscos estes que são maximizados pelas características inerentes ao DDS
(Audy e Prikladnicki, 2007).
31
2.6.2.2. Emprego de ferramentas para a modelagem dos processos de
negócios
Há diversas ferramentas de modelagem de processos existentes no mercado e até mesmo
reconhecidas pela comunidade científica. Segundo Santos (2002), o uso de ferramentas de
modelagem de processos é importante por se tratar de um instrumento aplicável às ações de
EPN, principalmente, em situações de grande complexidade.
Essas ferramentas geralmente automatizam, sistematizam e controlam a criação dos
modelos durante a modelagem de processos (Santos, 2002). Algumas delas podem, inclusive,
embutir metodologias de modelagem de processos específicas (Carvalho, 2009).
As propostas de Cruz (2004) e Dias et al., (2006), além do método em si, também
apresentam em suas abordagens ferramentas que operacionalizam os métodos desenvolvidos.
As respectivas ferramentas são: Metastorm ProVision® BPA1, Rational Suite AnalystStudio
2,
HPReq3 e RAPDIS
3.
Os modelos de processos de negócio previstos nessas abordagens são construídos e
mantidos por essas ferramentas que acabam embutindo etapas, modelos e elementos previstos
nos métodos criados. As duas outras abordagens, Knight (2004) e Azevedo Junior e Campos
(2008), não consideram este critério, embora seja notória sua importância (Carvalho, 2009).
É necessário um levantamento e posterior comparativo a fim de ser possível escolher
de modo embasado e justificado qual a metodologia/ferramenta mais adequada para este fim,
e neste ínterim, considerar as características do desenvolvimento de software por equipes
distribuídas. Essa atividade é descrita no Capítulo 4.
2.6.2.3. Nível de detalhamento dos processos de negócio
A visão processual, ao se materializar em modelos de processos, deve seguir princípios de
modelagem, e estar em um nível de agregação que seja adequado ao contexto abordado
(Carvalho, 2009). Para isso, é preciso estabelecer diretrizes que guiem na definição dos níveis
de detalhamento dos processos.
Dias et al. (2006), embora não explicitem diretrizes diretas para a definição dos níveis
de detalhamento dos processos, e Cruz (2004) (que as explicita), citam em seus trabalhos o
emprego de regras para organização da topologia dos diagramas gerados na modelagem. No
1 http://www.metastorm.com
2 http://www.ibm.com
3 http://geti.dcc.ufrj.br
32
entanto, essas regras não se mostram suficientes para auxiliar na tarefa de definir os níveis de
detalhamento dos processos, segundo o estudo de Carvalho (2009), que as aplicou.
As propostas de Knight (2004) e Azevedo Junior e Campos (2008) não detalham
diretrizes para apoiar a definição dos níveis de detalhamento dos processos e nem ao menos
mencionam a importância de se atentar para tal questão, mesmo isso sendo fundamental
quando se deseja desenvolver um software de tal maneira que as ambiguidades e outros riscos
inerentes do processo de EAR sejam minimizados (Carvalho, 2009). Isso, como em outras
situações supra descritas, é também ampliado ao considerar um ambiente de DDS (Audy e
Prikladnicki, 2007).
2.6.2.4. Abordagem do Conceito de Regras de Negócio
Regras de negócio são importantes para a elicitação de requisitos, pois além da influência
direta no negócio, estas têm estreita relação com os sistemas de informação (Dias et al., 2006;
Sommerville, 2007; Carvalho, 2009).
Isso é notório, pois as regras servem de orientação, influenciando o comportamento
dos membros de uma organização, controlando/influenciando a execução dos processos de
negócio e sua estrutura de recursos, restringindo/condicionando a execução de atividades e
dos SI que as contemplam (Carvalho, 2009).
Isto posto, identificar, representar, gerenciar e usar as regras de negócio como fonte de
informações na elicitação de requisitos de um sistema torna-se importante para gerar software
mais aderente às reais necessidades do negócio (IIBA, 2011).
A abordagem apresentada em Azevedo Junior e Campos (2008) não se refere ao
conceito de regra de negócio, nem expressa como esse conceito é considerado no
mapeamento dos processos de negócio e na posterior geração dos requisitos de sistema.
Knight (2004) também não aborda as regras de negócio em seu método, mas cita a
existência de restrições que devem ser relacionadas às funcionalidades do sistema, sem
relacionar essas restrições com o conceito de regras de negócio.
Na proposta de Cruz (2004), embora haja a definição das regras de negócio, o autor
não expõe com clareza a forma como elas devem ser identificadas no levantamento dos
processos de negócio e nem como se relacionam com os requisitos de sistema. Assim, não
fica claro no método como as regras de negócio impactam nos requisitos e nem como esses as
atendem. Além disso, o autor coloca como encaminhamento de futuras pesquisas a geração do
diagrama de classes do domínio do processo a partir do diagrama de atividades, que
33
representa o processo de negócio, envolvendo, assim, a identificação das regras de negócio,
não detalhando de que maneira isso poderia ser feito.
Para finalizar, Dias et al., (2006) abordam em sua proposta, as regras de negócio e,
ainda, afirmam que essas juntamente com os processos de negócio, sob o ponto de vista do
desenvolvimento de sistemas de informação, correspondem aos aspectos mais importantes do
negócio. Afirmam também que é a partir dos processos e das regras que os requisitos de
sistema são definidos, permitindo assim, que o novo sistema de informação apoie as
operações do negócio em questão. Para representar é usado o diagrama de atividades da UML
e para descrever as regras de negócio é empregado um subconjunto da língua portuguesa
(Português Estruturado). Esta última abordagem é a que se mostra mais adequada.
Nota-se, baseado na análise dos trabalhos correlatos e contextualizado com os desafios
de DDS, que fazer uso do conceito de regras de negócio é fundamental quando se trata de
equipes geograficamente distribuídas, haja vista que a comunicação é um dos maiores
desafios nesta configuração de desenvolvimento de software que pode gerar ambiguidade e
falta de clareza na EAR. Portanto, fazer uso das regras de negócio pode alavancar,
consideravelmente, a questão da comunicação entre equipes de desenvolvimento, haja vista
que estas estão, normalmente dispersas geograficamente (Carvalho, 2009).
2.6.2.5. Emprego de métodos, técnicas, notações ou ferramentas para a
representação dos requisitos de sistema
A documentação dos requisitos de sistema ao final da fase de EAR é importante para
manutenção da rastreabilidade das informações e utilização das mesmas nas demais etapas do
ciclo de vida do software (Sommerville, 2007).
Atualmente existem inúmeras técnicas, notações e linguagens encontradas na literatura
e conhecidas no mercado de software que podem ser empregadas com a função de
documentar e gerenciar os requisitos de sistema. Dos trabalhos analisados, três empregam a
UML neste quesito. Apenas Knight (2004) não emprega notação específica para documentar
os requisitos de sistema, apenas descreve o produto final do seu método em um Documento
de Requisitos de Software.
Portanto, é interessante que haja um padrão para representar os requisitos do sistema.
Se for UML, é preciso analisar e justificar quais diagramas podem/devem ser usados. Se for o
documento de requisitos, este precisa ter um formato pré-definido a fim de padronizar sua
estrutura para que todos os stakeholders a sigam, principalmente ao considerar um ambiente
34
de DDS. Uma terceira alternativa seria usar alguns diagramas da UML e, ainda, um
documento de requisitos pré-estruturado para minimizar os riscos relacionados à comunicação
em equipes de DDS.
Assim, para uma melhor visualização dos trabalhos apresentados na presente seção,
apresenta-se a Tabela 2.1 seguida de um detalhamento, a fim de identificar os pontos que
farão parte da abordagem proposta na presente dissertação.
Tabela 2.1. Resumo da Análise das Abordagens Descritas.
Critério 1 Critério 2 Critério 3 Critério 4 Critério 5 Total de Critérios
Atendidos
Abordagem 1 ■ ■ ■ ■ 4
Abordagem 2 ■ ■ 2
Abordagem 3 ■ ■ ■ ■ ■ 5
Abordagem 4 ■ ■ 2 Total de Abordagens que
atenderam ao critério 4 2 2 2 3
Na Tabela 2.1, as abordagens de 1 (um) a 4 (quatro) são, respectivamente: (i) Cruz
(2004); (ii) Knight (2004); (iii) Dias et al., (2006); e (iv) Azevedo Junior e Campos (2008). Já
os critérios, de 1 (um) a 5 (cinco) são, respectivamente: (i) Adoção ou não da modelagem de
processos; (ii) Emprego de ferramentas para a modelagem dos processos de negócios; (iii)
Nível de detalhamento dos processos de negócio; (iv) Abordagem do conceito de regras de
negócio; e (v) Emprego de métodos, técnicas, notações ou ferramentas para a representação
dos requisitos de sistema, conforme descritos na Subseção 2.6.2.
É possível notar que, dos critérios analisados, apenas o Critério 1 é cumprido por todas
as abordagens, enquanto que apenas a Abordagem 3 cumpre os 5 critérios expostos à
avaliação. Deste modo, seria ela então a abordagem mais próxima da linha temática deste
trabalho, porém é importante destacar que ela, como todas as demais, não contemplam o
contexto de desenvolvimento distribuído de software (DDS).
As abordagens que menos cumprem os critérios estabelecidos neste ínterim, embora
apresentem grande contribuição para a ciência e para a indústria, são as propostas de Knight
(2004) e Azevedo Junior e Campos (2008).
A abordagem proposta por Cruz (2004) – na Tabela 2.1 chamada de “Abordagem 1”,
não cumpre apenas o Critério 4, que se refere a considerar o conceito de regras de negócio,
conceito este de grande importância a ser levado em consideração no contexto do
desenvolvimento de software (Carvalho, 2009), além de não considerar um ambiente de DDS.
35
2.7. Considerações Finais
A etapa de elicitação e análise de requisitos possui grandes desafios, e alguns destes podem
ser minimizados ou até superados, principalmente no que tange a ambiguidade e clareza, se
for adotada alguma abordagem de modelagem de processos de negócio (Carvalho, 2009). Ao
se considerar um ambiente de DDS, essa abordagem faz-se ainda mais necessária, haja vista
que os desafios nestes ambientes são maximizados, e não foram encontradas até o momento
na literatura, referências neste contexto.
Neste capítulo foram apresentados os elementos que fundamentam o arcabouço de
uma abordagem de EAR a partir da modelagem das regras de negócio. Foi, também,
apresentado o contexto, características e desafios do DDS. O capítulo também descreveu
quatro trabalhos que tangenciam a linha temática aqui abordada.
O Capítulo 3 apresenta um relato de características do processo de EAR coletadas por
meio de vivência in loco em empresas com equipes distribuídas desenvolvendo Software.
36
Características da EAR na Indústria
3.1. Considerações Iniciais
No processo de desenvolvimento de software, uma questão que gera grandes discussões, tanto
na academia quanto na indústria, é o debate de temas relacionados à complexidade das
atividades de elicitação e análise de requisitos, que quando realizadas com equipes locais já
apresenta desafios, os quais aumentam, significativamente, quando ocorre a dispersão
geográfica destas equipes.
O desenvolvimento de software para qualquer contexto é caracterizado por uma série
de incertezas e desafios que vão desde a concepção do produto até sua entrega e utilização
pelos usuários finais.
Entretanto, é de senso comum que erros, omissões e/ou ambiguidades ocorridas nas
fases iniciais estendem-se por todo o do processo de desenvolvimento, gerando retrabalho,
dado o efeito-cascata decorrido, o que afeta diretamente custos e prazos (Sommerville, 2007;
Pressman, 2006). Isso torna a etapa de elicitação e análise de requisitos uma das mais
importantes e desafiadoras do processo como um todo. Propor abordagens neste contexto
pode exigir pesquisas sistemáticas e multidisciplinares.
Diante deste cenário, fez-se necessário uma pesquisa de campo com o objetivo de
identificar e ratificar evidências na indústria que comprovassem os relatos e estudos literários
descritos.
Este capítulo tem por objetivo descrever uma pesquisa de campo aplicada na indústria
de desenvolvimento de software (principalmente DDS, mas também desenvolvimento local a
3
Capítulo
37
fim de não perder características deste modelo), cujo propósito foi caracterizar (identificar e
ratificar inconsistências) a etapa de EAR sob o ponto de vista de profissionais envolvidos
nesta etapa a partir dos desafios identificados na literatura especializada.
3.2. O Projeto de Pesquisa
A pesquisa determinou uma investigação em retrospecto da elicitação e análise de requisitos
de software auxiliada pela engenharia de processos de negócios, preferencialmente em
ambientes de desenvolvimento distribuído. O relato tem por objetivo analisar a organização,
os colaboradores, os produtos e os processos com o propósito de explorar e caracterizar a
forma de gerenciamento com respeito a riscos e desafios do ponto de vista de profissionais
que atuam diretamente neste âmbito, como analistas de negócios, gerentes de projetos, entre
outros.
O levantamento de dados foi diretamente apoiado pela CAPES por meio do Projeto
PROCAD – Programa Nacional de Cooperação Acadêmica, e foi realizado em 03 (três)
empresas brasileiras, uma situada no Estado do Paraná (PR) e duas no Estado do Rio Grande
do Sul (RS), e que desenvolvem software para os mais diversos domínios.
Para não expor as empresas e preservar a privacidade dos colaboradores, os nomes das
empresas foram referenciados neste trabalho, como também nos relatórios da pesquisa, como
“Empresa E1” (RS), “Empresa E2” (RS) e “Empresa E3” (PR) e os colaboradores por meio
do cargo ou função exercida.
3.3. Metodologia do Projeto de Pesquisa
Na literatura, há um número grande de metodologias de projeto de pesquisa. Por esta razão,
alguns fatores devem ser avaliados para a escolha da técnica a ser aplicada em determinado
contexto. Portanto, na pesquisa em questão realizou-se um estudo precedendo o planejamento
com a finalidade de definir as etapas de pesquisa e identificar as técnicas apropriadas.
As etapas da pesquisa foram elaboradas com base nos trabalhos de Yin (2005) e Mafra
e Travassos (2006), e são compostas das etapas de planejamento, execução, análise e
interpretação dos dados, e por fim, a apresentação dos resultados, conforme ilustra a Figura
3.1.
38
Figura 3.1. Etapas do processo de pesquisa.
É fundamental que antes de descrever o planejamento, os objetivos da pesquisa
estejam definidos. O objetivo principal desta pesquisa foi realizar um levantamento
exploratório em empresas que desenvolvem software, preferencialmente de maneira
distribuída, com o propósito de detectar características e problemas relacionados à elicitação e
análise de requisitos de software. Deste contexto, derivaram-se os seguintes objetivos
específicos:
Conhecer a estrutura organizacional da empresa;
Conhecer a metodologia de elicitação e análise de requisitos adotados na
empresa;
Identificar os problemas sob a ótica de analistas de sistemas, analistas de
negócio e gerentes de projetos;
Analisar os artefatos gerados na fase de elicitação e análise de requisitos;
Relacionar o levantamento de dados com o tema em questão.
3.4. Planejamento
Na etapa de planejamento, o projeto de pesquisa e a seleção dos instrumentos do estudo são
definidos (Mafra e Travassos, 2006; Yin; 2005). As questões primárias e secundárias que
direcionam o pesquisador no campo e as proposições que auxiliam na análise e confiabilidade
dos dados, em confronto com as questões de pesquisa, são especificadas. As unidades de
análise, as fontes de evidência e os protocolos de coleta de dados também são formalizados no
planejamento do projeto de pesquisa.
A elaboração do projeto e a seleção dos instrumentos exigiram um estudo para
identificar e conhecer como planejar um estudo dessa natureza. Yin (2005) apresenta dois
possíveis problemas na etapa de planejamento de uma pesquisa de campo: a falta de rigor da
pesquisa em relação às evidências, e as visões tendenciosas aliadas à insuficiência de
evidências para triangular e confirmar resultados.
Como resultado desta etapa elaborou-se um documento denominado plano do
levantamento exploratório. A Tabela 3.1 apresenta os principais itens constantes deste plano.
Resultados Análise e
Interpretação Execução Planejamento
39
Tabela 3.1. Itens do plano do levantamento exploratório
Itens Descrição
Questões de
estudo
1. Quais são as características e problemas encontrados na elicitação e análise de
requisitos de software?
2. Quais as características na elicitação e análise de requisitos quando não há
conhecimento documentado dos processos do cliente?
3. Quais os desafios específicos encontrados quando o contexto é o desenvolvimento
distribuído de software?
4. Há adoção de alguma prática (modelo ou metodologia) que pode mitigar ou
eliminar esses desafios?
Hipótese nula Elicitar e analisar requisitos ocorre da mesma forma independente do contexto da
empresa e do modelo de negócios.
Proposições
Os desafios do DDS influenciam diretamente na forma da elicitação e análise de
requisitos.
Ter as regras de negócio do cliente modeladas ajuda, significativamente, na
elicitação e análise de requisitos.
Os desafios de EAR em ambientes de DDS são reduzidos ao utilizar técnicas de
modelagem de processos de negócio.
Unidades de
análise
Organização
Produto
Indivíduo
Processo
Fontes de
coleta de
dados
Artefatos (organização, produto, processo, indivíduo)
Observação direta (organização, indivíduo)
Entrevista semiestruturada (produto, indivíduo, processo)
Itens de coleta
Estrutura organizacional
Cultura organizacional
Escopo dos produtos
Indicadores de produtividade
Comunicação entre os membros da equipe
Conhecimento dos membros da equipe sobre elicitação e análise de requisitos
Processo de desenvolvimento
Mapeamento dos processos
Modelo ou metodologia para elicitação e análise de requisito
Aderência da modelagem das regras de negócio do cliente à elicitação e análise de
requisitos
3.5. Execução
A execução do plano do levantamento exploratório apresentado na Seção 3.4 ocorreu entre os
meses de Junho e Julho de 2011. Obstáculos e restrições foram encontrados durante a
execução do plano, exigindo a elaboração de alternativas para manter o alinhamento com o
objetivo da pesquisa e minimizar os problemas descritos por Yin (2005) na fase de
planejamento.
Para alcançar o resultado esperado (confirmar ou negar as proposições de pesquisa)
foram planejadas 04 (quatro) fases para esta etapa (Yin, 2005; Mafra e Travassos, 2006):
40
Preparação: Seleção dos participantes e preparação dos documentos, técnicas e
instrumentos de coleta de dados a partir das questões definidas na etapa de
planejamento.
Coleta: Aplicação dos documentos e técnicas da fase de preparação.
Análise preliminar: Organização e compreensão dos dados coletados para
aplicação da técnica de confiabilidade.
Confiabilidade: Aplicação de técnicas para ratificar os dados obtidos dos itens
de coleta de dados da etapa de planejamento.
Na fase de preparação ocorreram os obstáculos e as restrições que impactaram na
execução do estudo. Dentre eles estão:
Tamanho da amostra: Limitação do número de participantes na pesquisa.
Poucos colaboradores foram liberados para interromper suas atividades e
contribuir com o estudo.
Seleção dos participantes: Seleção por conveniência dos colaboradores devido
a fatores organizacionais e disponibilidade.
Restrição das fontes de coleta de dados: Acesso a fontes de pesquisa tais como
documentos específicos e observações detalhadas foram restritos visando a
privacidade dos colaboradores e da empresa.
Validação dos dados: A ausência de diferentes pontos de vista e fontes de
evidência impossibilitou a aplicação de técnicas mais eficientes tais como
validação e confiabilidade dos dados. Deste modo, não foi possível triangular
os dados.
Estes obstáculos e/ou restrições relacionados são ameaças em estudos dessa natureza,
contudo é difícil ou inviável elaborar ações a fim de minimizar estes na etapa de
planejamento. Em situações que o pesquisador conhece os colaboradores da empresa e possui
acesso antecipado para preparar o plano com maior precisão, é aconselhado que sejam
previstas e elaboradas ações de alinhamento nesse sentido.
O acesso a um número reduzido de colaboradores nas empresas prejudicou a seleção
adequada dos participantes (tamanho da amostra), impossibilitando a participação de mais
pessoas com cargos e funções distintas, bem como a triangulação de dados na fase de coleta.
No entanto, um fator positivo foi o nível dos participantes na estrutura organizacional, que
estavam em nível de tomadas de decisões (nível estratégico) e com conhecimento contextual
41
maior. A Tabela 3.2 apresenta uma breve descrição dos participantes das empresas “Empresa
E1”, “Empresa E2” e “Empresa E3”.
Tabela 3.2. Descrição dos participantes da pesquisa
Empresa Descrição
Empresa E1 Gerente de Projetos com certificação PMP; Gerente de Tecnologia com formação na área de
TI e 8 anos de experiência neste segmento, sendo 1 ano nos EUA; e Analista de Negócios
com larga experiência em pequenos e médios projetos, com certificação SCRUM.
Empresa E2 Gerente de Projetos com experiência de 6 anos em metodologias ágeis, principalmente
SCRUM e XP; e Analista de Negócios com 8 anos de experiência aliada a certificações na
área.
Empresa E3 Bacharel em Ciência da Computação e especialista em desenvolvimento de software, com 7
anos de experiência em modelagem de processos de negócios de clientes e em gestão de
pessoas. Atualmente atua como Gerente de Projetos e Produtos.
Entre os 03 (três) instrumentos de coleta de dados previstos na etapa de planejamento
(artefatos, observação direta e entrevista), apenas 01 (um) foi aplicado efetivamente – a
entrevista, enquanto os outros dois ocorreram de modo parcial. Este fato decorreu das
restrições impostas pelas empresas preocupadas em garantir a confidencialidade dos dados
estratégicos e a privacidade dos colaboradores.
Os instrumentos de coleta de dados por meio de entrevistas in-loco e acesso a dados
públicos a partir de registros em arquivos (site da empresa) ocorreram na fase de coleta dos
dados. A leitura e validação dos relatórios individuais por empresa foram aplicadas na fase de
confiabilidade dos dados para garantir a consistência da entrevista in-loco. É importante
ressaltar que a preparação da execução do plano foi analisada e customizada para cada
empresa. Para organizar os dados coletados e facilitar a aplicação da técnica de confiabilidade
realizou-se uma análise preliminar.
A Figura 3.2 apresenta as atividades e técnicas utilizadas durante as fases da etapa de
execução.
42
Figura 3.2. Atividades executadas em cada fase da etapa de execução.
Nas três empresas o contato inicial foi via e-mail para agendamento, e o contato
pessoal ocorreu sempre nos dias e horários marcados, sem atrasos ou adiamentos.
3.5.1. Coleta de Dados
O processo de coleta de dados incorporou entrevistas semiestruturadas e revisão de registros
em arquivos.
A entrevista semiestruturada é a elaboração e aplicação de perguntas que envolvem as
questões primárias e secundárias definidas na etapa de planejamento e a formulação de outras
perguntas inerentes ao contexto e às circunstâncias da entrevista (Martins, 2006; Yin, 2005). A
revisão de registros em arquivos envolve a identificação e extração de dados contidos em
meios físicos ou digitais.
Na empresa “Empresa E1”, os dados foram coletados por meio de uma única fonte de
evidência: entrevista. As entrevistas foram realizadas em dias e horários distintos, sendo todas
elas entre 01 e 31 de Julho de 2011. Com exceção da entrevista com o Gerente de Tecnologia
que teve duração de 2 horas, as demais duraram em média 45 minutos. Essa fonte de
evidência possibilitou a coleta de dados sobre a organização, os produtos, os indivíduos e os
processos. O formato de trabalho da empresa não permitiu fazer uso de outras fontes de
evidência.
43
Na “Empresa E2”, as entrevistas foram realizadas com duas pessoas que ocupam
cargos distintos, sendo eles: Gerente de Projetos e Analista de Negócios. Tais entrevistas
ocorreram em dias e horários distintos, sendo ambas entre 01 e 31 de Julho de 2011. As
entrevistas tiveram duração de aproximadamente 30 minutos com o Gerente de Projetos e 50
minutos com a Analista de Negócios. Essa fonte de evidência possibilitou a coleta de dados
sobre a organização, os produtos, os indivíduos e os processos. O registro em arquivo ocorreu
entre os dias 01 e 31 de Julho de 2011 a partir de dados públicos apresentado pela “Empresa
E2” em sua página da Internet. Essa fonte de evidência possibilitou a coleta de dados sobre os
produtos de mercado e clientes da empresa. A observação ocorreu nos mesmos dias das
entrevistas e tiveram duração aproximada de 30 minutos cada. Esta fonte de evidência
possibilitou observar a atuação dos profissionais analistas de negócios e de que forma o
histórico das estórias evolui (concepção – validação – implementação – testes).
Na “Empresa E3”, a entrevista foi realizada com uma pessoa que ocupa o cargo de
Gerente de Projetos e Produtos no dia 09 de Junho de 2011, e teve duração de
aproximadamente 80 minutos. Essa fonte de evidência possibilitou a coleta de dados sobre a
organização e os processos da “Empresa E3”. O registro em arquivo ocorreu em 10 de Junho
a partir de dados públicos apresentados pela “Empresa E3” em sua página da Internet. Essa
fonte de evidência possibilitou a coleta de dados sobre os produtos de mercado e clientes da
empresa. O formato de trabalho da empresa possibilitou estas duas fontes de evidência.
A Tabela 3 apresenta, em suma, a etapa de coleta de dados.
Tabela 3.3. Resumo da fase de coleta de dados
Empresa Local Data Duração Unidades de análise Instrumentos
Empresa E1 Porto Alegre
(RS) 07/2011
120 min
45 min
45min
Organização, indivíduos
e processos
Entrevista semi-
estruturada
Empresa E2 Porto Alegre
(RS) 07/2011
30 min
50 min
Organização, indivíduos
e processos.
Entrevista semi-
estruturada, registro em
arquivos e observação
Empresa E3 Cascavel
(PR) 06/2011 80 min
Organização e
processos.
Entrevista semi-
estruturada
Durante as entrevistas in-loco buscou-se imbricar as questões sobre os itens de coleta
apresentados no plano do levantamento exploratório (Anexo A). No Anexo B estão os
relatórios das entrevistas individuais por empresa.
44
3.5.2. Análise Preliminar da Coleta de Dados
Os dados obtidos por meio de entrevista, observação e registro em arquivos foram
organizados e sintetizados em tópicos para facilitar a compreensão e a padronização dos
resultados dos itens de coleta. Os tópicos definidos foram:
Estrutura organizacional
Metodologia/técnicas utilizadas para elicitação e análise de requisitos
Modelagem dos processos de negócios dos clientes
Desafios específicos da elicitação e análise de requisitos no contexto de
desenvolvimento distribuído de software
Cada tópico expressa um grupo de características encontradas na pesquisa de campo
que podem colacionar a forma de condução dos projetos com o propósito de confirmar ou
negar as proposições de pesquisa.
3.5.3. Confiabilidade e Análise dos Dados
A confiabilidade dos dados foi obtida por meio da técnica de convalidação (equivalência).
Segundo Martins (2006), essa técnica é confiável se a correlação entre os resultados coletados
não sofrem mudanças consideráveis (correlação fortemente positiva).
Nesta fase, os dados obtidos pelos instrumentos de entrevista, registro em arquivo e
observação foram relatados e enviados, propositalmente, entre 15 e 25 dias depois para os
respondentes que sinalizaram quanto à fidelidade dos mesmos. Este prazo deu-se para mitigar
o impacto de replicação de resposta dos participantes por conveniência.
Outras técnicas estudadas, tais como questionários, teste e reteste, coeficientes alfa de
Cronbach e KR-20 e split-half, foram desconsideradas devido aos obstáculos da fase de
preparação e à natureza do estudo.
Procurando sintetizar os dados coletados e confirmados na etapa de execução foi
construído uma estrutura tabular que descreve cada tópico da análise preliminar para as
respectivas empresas estudadas. O resultado é apresentado na Tabela 3.4.
45
Tabela 3.4. Descrição dos tópicos de análise por empresa
Tópicos Empresa E1 Empresa E2 Empresa E3
Estrutura organizacional
A estrutura organizacional da empresa é
fortemente hierarquizada e com gestão
distribuída entre vários gerentes de etapas
específicas, todos respondendo a um gerente
de projetos. O gerente de projetos é
responsável pela viabilidade e
acompanhamento dos novos projetos
enquanto os gerentes de área são
responsáveis pelos segmentos operacionais
da empresa, tais como, de elicitação e análise
de requisitos, de desenvolvimento, de testes e
de tecnologia. O gerente de projetos,
hierarquicamente, está acima dos gerentes de
áreas.. Decisões que afetem mais de uma
equipe são tomadas em conjunto pelo corpo
de gestores. Geralmente o gestor de uma área
participa como ouvinte das tomadas de
decisões finais da área que o antecede no
processo de desenvolvimento. O número de
recursos humanos em todo processo de
desenvolvimento e manutenção dos produtos
da empresa é considerado alto, haja vista que
a maioria dos projetos é de médio e grande
porte.
A estrutura organizacional da empresa é
fracamente hierarquizada haja vista que
trabalha com times auto gerenciáveis.
Um pouco acima do time está o gerente de
projetos (que coordena vários projetos
simultaneamente).
No âmbito operacional há poucos membros
em cada time, e cada um com seus papéis
bem definidos, dando a impressão que não há
diferenças hierárquicas – fato marcante
quando se faz uso de métodos ágeis para
gerenciamento e desenvolvimento.
A estrutura organizacional da empresa é
hierarquizada e com gestão limitada por um
corpo de gestores composto por 01 (um)
gerente de projetos e 06 (seis) gerentes de
área. O gerente de projetos é responsável pela
viabilidade e acompanhamento dos novos
projetos enquanto os gerentes de área são
responsáveis pelos segmentos operacionais
da empresa, tais como: desenvolvimento,
testes, comercial e financeiro.
Tanto o gerente de projetos quanto o gerente
de área estão no mesmo nível hierárquico e
possuem responsabilidades sobre equipes
semi-dinâmicas. Decisões que afetem mais
de uma equipe são tomadas em conjunto pelo
corpo de gestores. O número de recursos
humanos em todo processo de
desenvolvimento e manutenção dos produtos
da empresa envolve aproximadamente 25
(vinte e cinco) colaboradores distribuídos em
equipes menos, geralmente entre 6 e 9
pessoas, sob a gestão dos gerentes.
Metodologia/técnicas
utilizadas para elicitação
e análise de requisitos
&
Modelagem dos
processos de negócios
dos clientes
Há um time treinado especificamente para ter
o contato com o cliente. Os integrantes destes
times são conhecedores de processos de
negócios comuns à maioria dos sistemas de
informação de propósito geral (rotinas
financeiras, rotinas contábeis, etc.). Desde a
fase inicial de um novo software, gera-se
bastante documentação em um formato
padronizado (basicamente inglês
estruturado). É adotado o formato de
documentos conhecido como BRD (Business
Requirement Document) – padrão disponível
Toda elicitação e análise de requisitos é
baseada em estórias escritas/validadas pelo
cliente com o acompanhamento técnico do
analista de negócios. Não há modelagem
gráfica alguma, o que também foi apontado
como possível causa de alguns defeitos em
softwares, justamente por conta de que a
validação das estórias é apenas subjetiva e
baseada apenas em um texto de poucas linhas
e semiestruturado, o que pode gerar
ambiguidade dependendo da experiência dos
membros que compõe o time, fato que obriga
As pessoas que executam tarefas relativas à
análise de negócios compõem um time fixo
com esta finalidade, uma vez que também
precisam conhecer o produto da empresa
(que segue a linha de CRMs) a fim de elicitar
e analisar os novos requisitos e a
compatibilidade destes com o que já existe
no produto da empresa. Como geralmente o
que ocorre são pequenas personalizações, a
empresa usa modelagem gráfica para tal – já
usou apenas workflows e atualmente vem
usando BPMN, o que acaba por gerar os
46
na Internet e usado por várias empresas. Este
formato de documento é adaptado às
necessidades do projeto. Já houve
experiências do uso de modelagem gráfica
usando BPMN, mas esta não substituiu em
algum momento a descrição textual. Um
ponto negativo foi que poucos integrantes de
outras partes do processo de
desenvolvimento conheciam a notação
gráfica utilizada, limitando um maior uso da
mesma.
a empresa a ter sempre profissionais de alta
qualidade e com certa experiência. Muitas
vezes estes profissionais são alcançadas
apenas de forma distribuída geograficamente.
requisitos funcionais da parte a ser
personalizada do software. Junto com a
notação são inseridas legendas com pouco
texto detalhando aquela possível
dúvida/ambiguidade.
Desafios específicos da
elicitação e análise de
requisitos no contexto de
desenvolvimento
distribuído de software
Um dos desafios apontados como decisivo
foi a possível ambiguidade que pode ser
gerada na documentação realizada, pois
podem existir conflitos de cultura tanto
pessoal quanto técnica, ou seja, o que está
claro para o cliente e para o time que faz a
elicitação e análise de requisitos, pode
parecer ser outra coisa para o time que
desenvolve e/ou o time que testa o novo
produto (que pertence à mesma empresa, mas
geralmente está em outro país - Offshore
Insourcing). A possível causa deste problema
se dá por que os documentos usam apenas
um texto estruturado. Outro desafio
determinante foi que, como esta empresa tem
times de desenvolvimento em pelo menos 4
pontos do mundo, onde os extremos do fuso
horário chegam à diferença de 7 horas, há
desafios na comunicação visando a
continuidade quando uma equipe está
finalizando o dia e outra iniciando. A
documentação neste ponto é também apenas
escrita.
As estórias são escritas e validadas pelos
analistas de negócios juntamente com os
clientes, e sempre são curtas e objetivas
(seguindo os princípios ágeis), o que por
vezes gera inconsistência e/ou não
completeza das informações para um
requisito. Isso, não raras as vezes, gera algum
atraso, pois é necessário reunir-se novamente
com o cliente e o analista de negócios a fim
de diminuir/eliminar as incertezas
decorrentes.
Não é possível fazer apontamentos neste
quesito para a empresa E3, pois atualmente
ela não atua com DDS, mas tem perspectivas
de trabalhar com terceirização de código
dentro do Brasil (Onshore Outsourcing) em
meados de 2013.
47
Ao analisar a Tabela 3.4, é possível julgar as proposições do plano do estudo em
verdadeiras ou falsas, atribuindo respectivamente os valores “SIM” ou “NÃO”. Em cada linha da
Tabela 3.5 é apresentada uma proposição juntamente com o resultado do seu efeito, baseado na
pesquisa de campo realizada nas empresas desenvolvedores de software.
Tabela 3.5. Confirmação das proposições do Plano de Estudo (Tabela 3.1)
Hipótese Nula Avaliação [SIM] [NÃO]
Elicitar e analisar requisitos ocorrem da mesma forma independente do contexto
da empresa e do modelo de negócios. NÃO
Proposições Avaliação [SIM] [NÃO] Os desafios do DDS influenciam diretamente no formato da elicitação e análise
de requisitos. SIM
Ter as regras de negócio do cliente modeladas ajuda significativamente na
elicitação e análise de requisitos. SIM
Os desafios de EAR em ambientes de DDS são reduzidos ao utilizar técnicas de
modelagem de processos de negócio. SIM
Ao analisar a Tabela 3.5 derivada da análise dos dados colhidos in loco, nota-se que a
hipótese nula – “Elicitar e analisar requisitos ocorrem da mesma forma independente do contexto
da empresa e do modelo de negócios”, foi refutada, confirmando que essa etapa do processo de
desenvolvimento de software requer atenção especial, seja para o desenvolvimento local, seja
distribuído, haja vista que a assertiva não limitou-se a um ou outro.
As 3 (três) proposições do plano de estudo, a saber: (i) Os desafios do DDS influenciam
diretamente no formato da elicitação e análise de requisitos; (ii) Ter as regras de negócio do
cliente modeladas ajuda na elicitação e análise de requisitos; e (iii) Os desafios de EAR em
ambientes de DDS são reduzidos ao utilizar técnicas de modelagem de processos de negócio,
foram descritas como “SIM”, sendo confirmadas após a análise dos resultados do projeto de
pesquisa realizado nas empresas. Esse resultado ratifica o que a literatura expõe e, novamente,
justifica a abordagem proposta no Capítulo 5.
3.6. Considerações finais
A etapa de EAR é de grande importância no desenvolvimento de software, haja vista que erros,
ambiguidades e similares nesta fase, implicam em consequências drásticas nas etapas seguintes,
afetando diretamente custos, prazos, satisfação do cliente, entre outros (Sommerville, 2007).
Por meio dos resultados obtidos da pesquisa in-loco em empresas desenvolvedoras de
software, ficou ratificado o que a literatura apresenta de forma acadêmica. Foi notória, neste
48
ínterim, a necessidade que os profissionais envolvidos têm de métodos, técnicas e ferramentas
para etapas específicas do processo de desenvolvimento de software.
O Capítulo 4 apresenta como tema central a modelagem de processos de negócio,
abordando desde princípios, metodologias de modelagem, regras de negócios e conceitos
correlatos que fundamentam a abordagem descrita no Capítulo 5.
49
Modelagem de Processos de Negócio
4.1. Considerações Iniciais
A modelagem de processos de negócios, além de seguir princípios e critérios para escolha dos
níveis de detalhamento, pode também ser executada por diferentes métodos. Estes métodos
tentam garantir a existência de uma linguagem comum e estruturada. Mayer (1995) afirma que
um método corresponde à disciplina ou prática organizada com um propósito único.
Os conceitos abordados neste capítulo se fazem importantes por permitirem a
compreensão de questões da EPN relacionadas direta ou indiretamente ao contexto desta
dissertação, de modo que o objetivo central desse capítulo é fornecer ao leitor um alicerce
conceitual sobre temas da EPN com vistas a subsidiar a estratégia proposta no Capítulo 5.
A Figura 4.1 esquematiza a organização deste capítulo.
4
Capítulo
50
Figura 4.1. Esquematização do Capítulo 4.1.
4.2. Princípios da Modelagem de Processos de Negócio
Modelar processos compreende entender a estrutura organizacional, as regras de negócio que
atuam no contexto, os objetivos, as atividades e responsabilidades das pessoas envolvidas, bem
como os dados manipulados (Nuseibeh e Easterbrook, 2000). A modelagem de processo tem
lugar central nos instrumentos da Engenharia de Processos (Santos, 2002), e é essencial para
promover a integração e a coordenação nas organizações (Vernadat, 1996).
O objetivo da modelagem de processos é desenvolver os modelos que capturem as
diversas características no negócio, podendo por vezes simplificar a representação de uma
realidade mais complexa omitindo detalhes irrelevantes para a análise desejada (Bubenko et al,
2001).
Santos (2002) afirma que são objetivos da modelagem de processos a representação de
maneira uniforme da empresa; o fornecimento de suporte ao projeto de novas áreas
organizacionais; e a elaboração de modelo para controle e monitoramento das operações da
empresa. Alguns benefícios que a modelagem pode trazer:
Implantação da cultura e compartilhamento de uma visão única transmitida por
toda a organização utilizando-se de linguagem padrão – os modelos utilizados;
EPN Considerações
Iniciais
Princípios da
Modelagem de PN
Níveis de Agregação
Metodologias de
Modelagem
ARIS
CIMOSA
IDEF
Redes de Petri
BPMN
UML
Regras de Negócio
Modelagem de RN
51
Uso/explicitação do conhecimento e da experiência organizacional, visando a
construção da memória da empresa, tornando-se, assim, um ativo organizacional;
Suporte à tomada de decisão, devido à melhoria e controle organizacional.
Com a modelagem de processos é possível gerar uma visão processual em detrimento da
funcional. A visão processual facilita, segundo Cameira e Caulliraux (2000), mesmo que de
modo indireto, a quebra de barreiras funcionais, permitindo o tratamento processual dos fluxos
de informação.
Esse ponto de vista da organização promove o encadeamento das funções organizacionais
e a ligação das atividades em nível de processo entre as várias áreas da empresa. Além disso,
promove o entendimento dos fluxos transversais de informação, ao se desenvolver processos de
reengenharia (Davenport, 1994; Davenport e Prusak, 1998), melhoria contínua (Shingo, 1996) ou
construção de novos negócios, e torna-se importante para projetos de sistemas de informação.
A Figura 4.2 confronta a lógica processual com a visão funcional tradicional, na qual a
lógica processual é modelada seguindo o fluxo horizontal.
Figura 4.2. Visão funcional versus visão processual (Antunes et al., 1998).
A atividade de modelar processos deve seguir alguns princípios que, segundo Santos
(2002), são essenciais para um bom resultado das ações relacionadas à criação de modelos. Um
primeiro conjunto de princípios foi proposto por Rosemann (apud Scheer, 1998; Aalst et al.,
2000), a saber:
Aderência: Princípio que guia o entendimento sobre a proximidade do modelo à
estrutura e ao funcionamento da realidade modelada;
52
Relevância ou suficiência: Cada objeto representado no modelo deve ter um
propósito de forma que um modelo não contenha mais informações do que o
necessário;
Custo/benefício: Análise da quantidade de trabalho necessária para criar o
modelo versus utilidade do mesmo versus quanto tempo o modelo será usado;
Clareza: Princípio considerado de grande importância em função da própria
definição de modelo capaz de ser entendido e usado pelos usuários (Pidd, 1999);
Comparabilidade: Princípio que direciona a comparação entre diferentes
processos; e
Estruturação sistemática: Princípio relacionado à capacidade de integrar
modelos, representando diversos aspectos da realidade e à capacidade desses
modelos se estruturarem metodologicamente.
Para Pidd (1999) há outros princípios de modelagem importantes: modelagem simples;
pensamento complicado; uso de parcimônia, estratégia incremental (iniciando com pouco e
acrescentando); uso da divisão e conquista; uso de metáforas, analogias e similaridades e pouco
apego aos dados.
Vernadat (1996) lista como princípios de modelagem a separação de focos para reduzir a
complexidade; decomposição funcional e modularidade; generalidades do modelo; re-
usabilidade; separação do comportamento e funcionalidade; desacoplamento entre processos e
recursos; conformidade; visualização do modelo; simplicidade versus adequação; gestão da
complexidade; rigor na representação e separação de dados e controle. Esses princípios se
mostram importantes para auxiliar o alcance dos objetivos pretendidos pelos processos no
escopo de aplicações da EPN.
Ao se tratar da aplicação dos processos de negócio em um projeto de software, a adoção
do conjunto de princípios de Rosemann (apud Scheer, 1998; Aalst et al., 2000) se mostra
importante, pois estes visam garantir a construção de modelos de processo adequados a esse tipo
de aplicação.
4.2.1. Níveis de Detalhamento
Além de seguir princípios de modelagem, a visão processual, ao se materializar em modelos de
processos, deve ter um nível de agregação adequado. Para Cameira e Caulliraux (2000) essa
questão gera infindáveis discussões, principalmente por não haver consenso para regras exatas.
53
Entretanto, segundo os autores, é possível adotar diretrizes que facilitam a identificação
do nível de agregação que se deve chegar, mas que sempre são permeadas pelo bom senso e
experiência de quem conduz a modelagem.
Segundo Cameira e Caulliraux (2000), o processo deve descrever claramente o fluxo de
informação (e materiais/documentos associados); um processo não deve ser desagregado demais,
mesmo que se deseje entender rápida e globalmente como são os macroprocessos de uma
organização.
O mesmo raciocínio se aplica ao se considerar que o maior leque de problemas ou de
ganhos operacionais está, provavelmente, alocado nos processos operacionais, que não
necessariamente aparecem em modelagens agregadas ou em descrições de fluxos em nível
macro.
4.2.2. Metodologias de Modelagem
O’Neill (1999) afirma que, na literatura especializada, a maioria dos autores refere-se a um
conjunto de técnicas (métodos e ferramentas) diferenciadas para a modelagem de processos de
negócio. A escolha da(s) técnica(s) está ligada à natureza do processo em estudo, sendo comum à
adoção de apenas uma técnica de diagramação.
Dentre os métodos que oferecem apoio às ações de modelagem de processos, serão
abordados com mais detalhes os seguintes:
ARIS (Architecture for Integrated Systems) – Arquitetura para Sistemas
Integrados;
CIMOSA (Computer Integrated Manufacturing Open System Architecture) –
Arquitetura Aberta de Sistemas CIM;
IDEF (Integration Definition Methods) – Métodos Integrados de Definição;
Redes de Petri;
Notação de Modelagem de Processos de Negócio – BPMN (Business Process
Modeling Notation).
Modelagem de Processos de Negócio com UML.
Esses métodos foram selecionados por fornecerem suporte à modelagem de processos
principalmente quando o objetivo é a aplicação desses processos em projeto de sistemas de
informação. As subseções seguintes os descrevem.
54
4.2.2.1. ARIS (Architecture for Integrated Systems)
Desenvolvida no período de 1992 a 1994 na Alemanha, ARIS é um framework de modelagem
que enfatiza os aspectos organizacionais e de engenharia de software da empresa (Vernadat,
1996).
A arquitetura do ARIS é fundamentada na utilização de uma grande variedade de
modelos e objetos através dos quais os processos de negócio são representados e analisados por
meio da ferramenta ARIS Toolset, e se baseia na integração dos processos de negócios com uma
divisão em visões que possibilitam a representação das partes que, juntas, compõem o todo
(Scheer, 1998).
Scheer (1998) define quatro visões, contendo cada uma delas três níveis de modelagem:
Definição dos Requisitos, Projeto e Implementação. Estas visões são:
Visão Funcional: Conjunto de modelos que definem, hierarquicamente, todas as
funções da empresa iniciando-as pelas macro e decompondo-as até o nível de
detalhe que permite especificar funções de implementação específicas dentro de
aplicativos de software;
Visão dos Dados: Modelo de dados, partindo das definições das informações
mais complexas (relatórios ou conjunto de informações) para a elaboração do
modelo de dados e seus relacionamentos, gerando posteriormente a definição de
esquemas da base de dados;
Visão Organizacional: Especifica e detalha a estrutura organizacional da
empresa desde a definição das divisões e unidades de negócios, a estrutura de
cargos e seus ocupantes, até a estrutura física com os equipamentos, dando ênfase
no que tange à infra estrutura na medida em que há métodos específicos para a
modelagem da rede de computadores da empresa;
Visão de Controle: Relaciona as três visões acima citadas. Nesta visão há
métodos de modelagem específicos para definir a relação entre as demais
(funções, dados e organização).
Este framework conta também com os seguintes modelos: Cadeia de Valor Agregado –
VAC; Diagrama de Objetivos – DO; Árvore de Funções – FT; Organograma – ORG; Diagrama
de Entidades e Relacionamentos – ERM; Estrutura de Conhecimento – KSD; Diagrama de
Função – FAD; e Cadeia de Processos orientada por eventos – EPC, sendo este último o mais
importante para representar a visão processual.
55
Cada um destes modelos tem objetivos específicos, mas são utilizados de forma inter-
relacionada (Santos, 2002). A Figura 4.3 ilustra como os modelos disponíveis na ARIS estão
distribuídos nas visões e os três níveis (Definição de Requisitos, Projeto e Especificação e, por
fim, Implementação) existentes para cada visão, que conforme prevê a arquitetura ARIS4,
possibilita a projeção de sistemas de informação orientados pela estratégia e, principalmente,
pelos processos.
Figura 4.3. Modelagem de um SI utilizando orientação por processos com ARIS (Sheer, 2000).
Conforme a Figura 4.3, a visão funcional permite, por meio de seus modelos, a
identificação das funções associadas aos objetivos e de suas hierarquias, tornando-se possível
visualizar quais funcionalidades devem ser executadas para o alcance dos objetivos desejados.
A visão de dados associada aos modelos promove a modelagem semântica dos dados,
permitindo realizar a especificação das aplicações que apoiam as funções, processos e objetivos.
4 ARIS prevê, por meio da integração das visões e dos seus modelos, que a modelagem de processos seja utilizada
para apoiar as fases de: pré-implantação, implantação e pós-implantação de Sistemas Integrados de Gestão (SIGs),
permitindo identificar e configurar componentes do sistema com os modelos (SANTOS et al., 2002).
56
A visão de organização, por sua vez, permite a modelagem e a análise da estrutura
organizacional, contribuindo com a análise dos processos de negócio, já que mostra a divisão de
trabalho, bem como a hierarquia de responsabilidades e a coordenação.
A visão de processos (ou controle) tem como responsabilidade a integração das demais
visões, por meio do emprego do modelo de processos que representa o aspecto dinâmico e
comportamental da organização.
Por fim, a saída é responsável pela representação dos produtos ou serviços e suas
relações.
4.2.2.2. CIMOSA (Computer Integrated Manufacturing Open System
Architecture)
Elaborada e documentada por um consórcio de empresas chamado AMICE durante os anos 1986
e 1994, compreende tanto a modelagem propriamente dita como a metodologia de implantação
CIM (Computer Intergraded Manufacturing). CIMOSA consiste em uma arquitetura/framework
composta de uma definição geral do escopo e implantação CIM, guias para a implantação, e a
definição de termos e padrões para modelagem e implantação, e objetiva ajudar as organizações
a gerenciar mudanças e integrar suas facilidades e operações visando alcançar preço, qualidade e
tempo de entrega competitivos (Vernadat, 1996; Vicente, 2004, CIMOSA, 2012).
CIMOSA tem como princípios ser uma estrutura de modelagem popular com suporte
para todas as fases do ciclo de vida dos sistemas CIM, desde a definição de requisitos, passando
pela fase de especificação e de descrição da implementação, chegando até a execução das
atividades diárias de operação da organização. O cerne desta metodologia é baseado em uma
abordagem de modelagem dirigida por eventos e baseada em processos, com o objetivo de
representar aspectos essenciais em um modelo de negócio. Os aspectos abordados pela CIMOSA
são: funcionais, comportamentais, recursos, informações e a organização (Santos, 2002).
4.2.2.2.1. Estrutura da Modelagem CIMOSA
A arquitetura/framework CIMOSA é composta por três componentes principais (também
conhecida como Cubo CIMOSA): uma estrutura para a modelagem do domínio, uma
infraestrutura de integração do projeto e um ciclo de vida associado à modelagem realizada
(Vernadat, 1996). A Figura 4.4 ilustra essa estrutura de três camadas:
57
Figura 4.4. Estrutura de Modelagem CIMOSA (adaptado de Kosanke, 1995).
Conforme a Figura 4.4 ilustra, a modelagem baseia-se em três camadas (Vernadat, 1996;
Santos, 2002; Vicente, 2004; Kosanke, 1995; CIMOSA, 2012):
Derivação de Modelos – responsável por direcionar a modelagem de processos de
negócios de acordo com os níveis de modelagem necessários;
Particularização – Consiste de duas partes: (i) uma arquitetura de referência –
usada para auxiliar usuários de negócios no processo de construção de sua
arquitetura particular; e (ii) uma arquitetura particular – conjunto de modelos
documentando o ambiente CIM do usuário, da análise de requisitos à sua
implementação; e
Geração de Visões – Aborda a modelagem de processos de negócios de
manufatura sob diferentes visões.
O princípio de Derivação de Modelos sugere que a modelagem de um negócio seja
realizada com três fases sucessivas (iterações entre essas fases são permitidas, se necessárias)
(Vernadat, 1996; CIMOSA, 2012):
a) Definição de requisitos: Expressar as necessidades do negócio na visão dos
usuários;
b) Especificação de Projeto: Construir um modelo formal, conceitual e executável
do sistema de informação que a empresa necessita;
c) Descrição da Implementação: Documentar detalhes e mudanças na
implementação, recursos instalados, e mecanismos de gerenciamento de exceções.
58
O princípio de Geração de Visões contempla os aspectos considerados na análise de um
negócio/empresa. Conforme Vicente (2004) e CIMOSA (2012), são definidas quatro visões
básicas:
a) Visão de função: Representa a funcionalidade e comportamento da
empresa/negócio (eventos, atividades e processos) incluindo aspectos temporais e
de gerência de exceções;
b) Visão de informação: Representa os objetos da empresa e seus elementos de
informação;
c) Visão de recursos: Representa os meios da empresa e seu formato de
gerenciamento;
d) Visão de organização: Representa os níveis organizacionais, autoridades e
responsabilidades.
A arquitetura CIMOSA, apesar de se mostrar interessante, é bastante dependente de
ferramentas específicas, dada sua elevada complexidade e, para que seja possível implementar
tais ferramentas, se faz necessária uma clara interpretação das quatro visões em detalhes,
garantindo eficácia à ferramenta.
4.2.2.3. IDEF (Integration Definition Methods)
A metodologia IDEF (Integration Definition Methods) foi criada no início dos anos 70, como
parte ICAM (Integrated Computer Aided Manufacturing) e oferece apoio a uma abordagem para
prover métodos que apoiem a integração empresarial ou organizacional (Mayer, 1995; Vernadat,
1996).
Inicialmente, a metodologia IDEF foi projetada para engenharia de sistemas, mas com o
passar dos anos, foi agregando novos métodos relacionados a diversos aspectos organizacionais
que não somente sistemas de informações.
O resultado dessa evolução separou a IDEF em vários métodos. Um método IDEF
consiste de um conjunto de atividades hierárquicas, na qual cada atividade de nível inferior
representa uma função que deve ser executada para realizar a atividade de nível superior.
Adicionalmente, um conjunto de entidades (entrada, saída, controle e recursos) representa
o fluxo de comunicação entre as atividades do processo (Mayer, 1995). Alguns exemplos são: (i)
IDEF0: Relacionado à modelagem funcional; (ii) IDEF1: Para modelagem de informações; (iii)
IDEF2: Desenvolvido para suporte a simulações; (iv) IDEF3: Para descrição e captura de
59
processos; (v) IDEF4: Método para modelagem orientada a objetos; e (vi) IDEF5: Para descrição
de ontologias.
Há alguns métodos que estão parcialmente desenvolvidos como o IDEF9, que aborda
identificação de restrições nos processos; o IDEF8, que trata do projeto de sistemas para
interação humana; o IDEF14, que contempla projeto de redes. Novos sub-métodos ainda devem
ser desenvolvidos, para auditoria de sistemas de informação (IDEF7), para modelagem de
artefatos de informação (IDEF10) e o IDEF12, que objetiva projetos organizacionais (Vernadat,
1996; Grover, 2000; Vicente, 2004; Carvalho, 2009).
Entre os métodos propostos pela metodologia IDEF, é possível destacar o IDEF3, que
está diretamente relacionado à modelagem de processos. Este método é composto por dois
modelos denominados de Fluxo de Processo (Process Flow) e Rede de Transição de Estado de
Objeto (Object State Transition Network (OSTN)), nos quais a aquisição do conhecimento
associado às atividades é conseguida por meio da captura direta de eventos ou atividades
existentes no mundo real.
O primeiro modelo, Fluxo de Processo, tem como objetivo descrever “como as coisas são
feitas” dentro da organização ou em um determinado processo de produção. O segundo modelo,
Rede de Transição de Estado de Objeto, descreve os eventos e condições pelos quais um objeto
passa em um determinado processo. É importante ressaltar que ambos os modelos possuem
unidades de informação e podem, portanto, serem usados na descrição de sistemas de informação
(Grover, 2000; Vernadat,1996; Santos, 2002).
Um conceito importante utilizado na organização básica de uma descrição e captura de
processo por meio de IDEF3 é o conceito de cenário, que pode ser interpretado como uma
atividade ou situação recorrente, um conjunto de situações que descrevem os problemas típicos
enfrentados por uma organização ou o contexto em que um determinado processo se inicia ou
evolui. Os cenários estabelecem o núcleo de atividade e as fronteiras de uma descrição de um
processo. A sua denominação toma sempre a forma de frases imperativas (Santos, 2002).
Descrever processos por meio do método IDEF3 baseia-se no pressuposto de existirem
dois tipos de abordagem ou estratégias para a captura e descrição de processos (Grover, 2000):
Process Schematics: Dimensão na qual o conhecimento intrínseco do processo é o
objeto central da abordagem de captura, juntamente com os vários tipos de
relações associadas entre eles temporais e lógicas, no contexto de um cenário.
Objet Schematics: Dimensão que organiza os processos utilizando como foco os
objetos e as transições de estados associados a eles em um único cenário ou no
alinhamento de cenários.
60
Em suma, IDEF3 apresenta-se como uma boa metodologia para a captura e descrição de
processos, que permite organizar, de forma conveniente, toda a informação e fluxo associados a
um sistema, embora, como sistema de captura e descrição, permita certa flexibilidade e
tolerância na forma como estas são efetuadas.
4.2.2.4. Redes de Petri
É um formalismo gráfico para especificação de processos. Foi formulado em 1963 pelo professor
Carl Petri, de onde herdou o nome (Reisig, 1985).
Uma rede de Petri é formada por um conjunto de lugares, um conjunto de transições e um
conjunto de conexões interligando locais e transições. Na modelagem de processos de negócio
usando Redes de Petri, cada local representa um estado particular de um objeto, uma transição
entre locais representa uma operação que pode ser executada por um objeto, os símbolos
representam as mensagens que podem ser trocadas entre os objetos e os arcos de conexão
identificam se um objeto é a origem ou o destino de uma mensagem (Bal, 1998; Ghezi, Jazaieir e
Mandrioli, 1991; Reisig, 1985).
Este método de representação gráfica, segundo Vernadat (1996), é muito popular e tem
grande potencial na representação e análise de sistemas que exibem características como
paralelismo, sincronização, não determinismo e compartilhamento de recursos.
Segundo Pádua (2004), as redes Petri são importantes para o estudo de sistemas por
permitir tanto a representação matemática quanto a análise dos modelos, fornecendo informações
úteis sobre a estrutura e o comportamento dinâmico dos sistemas modelados. Deste modo, esse
formalismo pode ser aplicado em diferentes áreas (sistemas de manufatura, desenvolvimento de
software, sistemas administrativos, etc.).
O método, por combinar representatividade com formalismo semântico, permite a
realização de análises. A forma gráfica do método aborda dois objetos principais: locais ou
lugares (em formato de círculos) e transições (em formato de barras verticais), que são
interconectados por setas (Carvalho, 2009). A Figura 4.5 representa os elementos básicos das
Redes de Petri.
61
Figura 4.5. Elementos básicos da Rede Petri (Pádua, 2004)
O primeiro objeto representa os estados e o segundo as atividades que são desenvolvidas
(Santos, 2002). A transição é um componente ativo que correspondente a alguma ação realizada
dentro do sistema. O lugar é um componente passivo e relacionado a variáveis de estado do
sistema. A execução de ações encontra-se associada a pré-condições ou a condições afetas às
variáveis de estado do sistema. Isto é, tem-se uma relação entre locais e transições,
possibilitando, assim, a realização de certas ações. De maneira semelhante, após a realização de
uma ação, as informações de alguns locais (pós-condições) ficam alteradas.
4.2.2.5. BPMN (Business Process Modeling Notation)
BPMN (Business Process Modeling Notation) é um padrão de notação para modelagem de
processos de negócio desenvolvido pelo The Business Process Management Initiative5 (BPMI),
em Maio de 2004.
Segundo Braconi e Oliveira (2010), BPMN pode ser definido como:
Business Process Modeling Notation (BPMN) é um padrão
desenvolvido visando oferecer uma notação mais
facilmente compreendida e usada por todos os envolvidos
nos processos de negócios, dos estrategistas e analistas de
negócio (que criam versões iniciais dos processos) aos
técnicos responsáveis pela seleção e implementação das
tecnologias que apoiarão o gerenciamento e monitoramento
desses processos. (Braconi e Oliveira, 2010).
O objetivo do BPMN é prover uma notação compreensível por todos os envolvidos no
negócio, desde analistas de negócio, responsáveis por criar processos, até desenvolvedores
técnicos, responsáveis pela implementação da tecnologia que executará estes processos,
passando por todos os gestores envolvidos com tais processos. Além disso, o BPMN também é
apoiado por um modelo interno que possibilita a geração de código executável, criando deste
5 http://www.bpmi.org
62
modo, segundo o BPMI, uma forma padronizada de cobrir a lacuna entre os processos de
negócio e a implementação dos mesmos.
O diagrama de processos de negócio (BPD – Business Process Diagram) é o modelo em
BPMN que representa as operações dos processos de negócio por meio de suas atividades e de
seus pontos de controle (que controlam a performance das atividades). Assim, o BPD permite a
representação gráfica dos elementos dos processos, facilitando e simplificando o
desenvolvimento do modelo do processo de negócio utilizando-se de elementos distintos e com
significado próprio (Braconi e Oliveira, 2010).
A próxima subseção detalha os elementos da BPMN.
4.2.2.5.1. Elementos do BPMN
Segundo Braconi e Oliveira (2010), a notação BPMN possui quatro principais elementos:
atividades, eventos, gateways (símbolos que expressam um momento de decisão) e conectores.
A partir destes quatro elementos é possível construir desde modelos simples até de
grande complexidade, capazes de expressar um processo de maneira bastante detalhada
proporcionando fácil entendimento deste processo (White, 2004).
Segundo Braconi e Oliveira (2010), os gerentes de projetos, de um modo geral,
conseguem lidar bem com a visualização de processos modelados com o uso de fluxogramas
simples, mas é necessário estudos a fim de compreender o modo com que as organizações
trabalham para definir um modelo de fluxograma simples e compreensível para qualquer grau de
conhecimento. Esse cenário cria uma lacuna técnica entre os dois ambientes, entre o formato
inicial do projeto do processo e o formato das linguagens que executarão esses processos – que
neste ínterim podem ser lidos como elicitação e análise de requisitos e implementação dos
requisitos elicitados.
Nesta linha, Braconi e Oliveira (2010) afirmam que a notação BPMN promove um
mecanismo de visualização padrão para processos de negócios definidos em uma linguagem de
execução “adequada”, preenchendo de maneira eficiente a lacuna entre o planejamento,
modelagem e execução. A Tabela 4.1 apresenta os principais elementos do BPMN, com suas
respectivas descrições e representação gráfica.
De acordo com Braconi e Oliveira (2010), um dos objetivos do BPMN é criar uma
estrutura simples para o desenvolvimento dos modelos de processos de negócios que possa
garantir uma modelagem processual, mesmo que esta tenha um alto grau de complexidade. Os
elementos apresentados na Tabela 4.1 são fundamentais para a construção de um eficiente
63
BPMN. Destes elementos destacam-se ainda os gateways e os eventos, descritos nas próximas
subseções.
Tabela 4.1. Elementos do BPMN (adaptado de Braconi e Oliveira 2010 e White, 2004).
Elemento Descrição Notação
Evento
É o que acontece durante o processo. Os
eventos afetam o fluxo do processo e têm
geralmente uma causa ou um impacto. Existem
três tipos de eventos: início, intermediário e
fim.
Atividade É um termo genérico para um trabalho
executado.
Subprocesso É uma atividade composta por uma série de
outras atividades que formam um novo fluxo.
+
Gateway
É utilizado para controlar a decisão e/ou
junção da sequência de um fluxo. Assim,
determinará decisões tradicionais, unirá ou
dividirá trajetos.
Fluxo de
Sequência Usado para demonstrar a sequência em que as
atividades serão executadas.
Fluxo de
mensagem
Usado para demonstrar o fluxo de mensagens
entre dois participantes diferentes que enviam
e recebem mensagens (tarefas, e-mail,
ligações, etc.).
Associação
Usada para associar dados, textos e outros
artefatos com o objeto do fluxo. As
associações são usadas para demonstrar as
entradas e saídas do processo.
Raia É um representante em um processo (ator).
4.2.2.5.2. Filtros de decisão BPMN (gateways)
Segundo Braconi e Oliveira (2010), gateways são elementos de modelagem utilizados para
controlar como a sequência do fluxo interage dentro de um processo ao convergir e divergir.
64
A Tabela 4.2 apresenta os gateways do BPMN, seguidos de sua descrição.
Tabela 4.2. Gateways do BPMN (adaptado de Braconi e Oliveira 2010 e White, 2004).
Gateway Descrição
Decisão
Alternativas baseadas em expressões condicionadas
sobre dados. Apenas uma alternativa é escolhida (sim
ou não).
Bifurcação
Utilizado para Bifurcar (divisão em um ou vários
caminhos paralelos) ou para Sincronizar (combinação
de vários caminhos em um único).
Eventos
Alternativas baseadas em eventos (apenas uma é
escolhida).
OR
Alternativas baseadas em expressões condicionadas.
Ao menos um caminho deve ser verdadeiro.
Os gateways podem separar e/ou juntar o fluxo. Deste modo, são utilizados para controlar
o local no qual o fluxo necessita desse controle baseado em uma decisão lógica.
4.2.2.5.3. Eventos em BPMN
De acordo com Braconi e Oliveira (2010), um evento é algo que ocorre durante um processo de
negócio. Esses eventos afetam o fluxo do processo e têm normalmente algo que os dispara ou
apresentam o resultado de algo. Há três tipos de eventos, ilustrados na tabela 4.3. Cada um deles
mostra como eles afetam o fluxo: os de início, os intermediários e os de fim, os quais são
definidos, segundo White (2004), da seguinte maneira:
Eventos de início: Indica por onde o fluxo vai começar. Esse elemento influência
no processo, pois a partir dele o fluxo se inicia e é preciso executar uma
atividade/ação. É representado por um círculo com a borda fina.
Eventos intermediários: Ocorre entre os eventos de início e de fim. Os
elementos intermediários influenciam o processo, mas não iniciam um novo
processo ou o terminam. A partir dele é dado continuidade em um processo que já
65
era executado, porém era necessário aguardar outra atividade ou qualquer outra
situação. O elemento usado para representá-los é um círculo com a borda dupla.
Eventos de fim: Indica onde o processo vai terminar, que normalmente têm um
resultado representado no centro do círculo. O elemento para esse evento é um
círculo com a borda grossa.
Tabela 4.3. Eventos do BPMN (adaptado de Braconi e Oliveira 2010 e White, 2004).
Eventos
iniciais
Eventos
Intermediários
Eventos
Finais Descrição
Mensagem de
início
Mensagem
Mensagem
de fim
Uma mensagem chega de um ator e dispara o
início do processo, ou continua o processo,
no caso de um evento intermediário. Uma
mensagem de fim indica uma mensagem
gerada no fim de um processo.
Marcador de
início
Marcador
Um
marcador
não pode ser
um evento
de fim.
Um tempo específico ou um ciclo (por
exemplo, toda segunda-feira às 13 horas)
pode reiniciar um processo ou continuá-lo,
no caso de um evento intermediário.
Regra de início
Regra
Uma regra
não pode ser
um evento
de fim.
Dispara quando as condições de uma regra se
tornam uma verdade.
Início múltiplo
Múltiplo
Fim múltiplo
Para iniciar múltiplos eventos, há vários
modos de iniciar um processo, ou continuá-
lo, no caso de evento intermediário. Apenas
um deles é requerido. Os atributos do evento
definem que tipo de disparo se aplica. No
caso de fim múltiplo, há várias
consequências de fim de processo (por
exemplo, múltiplas mensagens enviadas).
Um evento de
erro ou
exceção não
pode ser um
evento de
início.
Erro ou exceção
Fim do erro
ou da
exceção
Uma exceção de fim de evento informa ao
motor do processo que um chamado de erro
deverá ser gerado. Esse erro será pego por
uma exceção evento intermediário.
4.2.2.6. Modelagem de Processos de Negócio com UML
A Unified Modeling Language (UML) é uma linguagem para especificar, visualizar, construir, e
documentar artefatos de software, bem como para modelagem de negócio e de outros sistemas
66
além de software. Compreende uma coleção de boas práticas de engenharia que tem obtido
sucesso na modelagem de sistemas complexos e de grande escala (OMG, 2012).
Algumas outras definições se destacam:
UML é uma linguagem para a visualização, especificação, construção e
documentação de artefatos que fazem parte do processo de elaboração da estrutura
de projetos de sistemas complexos de software (Booch et al., 2000).
Segundo Bezerra (2002), é possível definir a UML como uma linguagem de
modelagem visual com um conjunto de notações e semântica correspondente para
representar visualmente uma ou mais perspectivas de um sistema.
Para Larman (2000) a UML é uma notação para modelagem de sistemas, usando
conceitos orientados a objeto.
Independente da definição adotada pode-se afirmar que a UML é uma linguagem de
modelagem. E, como qualquer linguagem, apresenta dicionário e regras próprias que orientam a
criação e a leitura de modelos bem formatados.
Entretanto, dado o fato de que a UML não é um método, ela por si só não associa e não
relaciona seus modelos com uma metodologia/processo de desenvolvimento de software, não
indicando quais modelos devem ser criados e nem quando criá-los dentro de um projeto de
desenvolvimento. A criação dos modelos depende da metodologia adotada, que deve também
apresentar os passos do processo de desenvolvimento, quais artefatos serão produzidos, quem
estará envolvido e demais características.
Conforme a OMG (OMG, 2012), a UML, além de ser uma linguagem utilizada para
modelagem de software, também pode ser utilizada para modelagem de negócio. Os diagramas
que podem ser utilizados neste contexto são:
Diagrama de Casos de Uso: Caso de uso é um conjunto de cenários que
descrevem interações entre usuários e sistemas (Booch et al., 2000). Tais cenários
representam situações vivenciadas por usuários do sistema (considerando
caminhos alternativos caso haja erros/imprevistos no processo de interação). Este
tipo de diagrama apresenta alguns conceitos de modelagem de negócio como a
interação entre atores e casos de uso, que podem ser representados por unidades
organizacionais, os sistemas e as metas de processos que podem estar associadas à
execução de um caso de uso ou um conjunto de casos de uso. Ao considerar
Casos de Uso para modelagem de negócio, o sistema com o qual os usuários
interagem, passa a ser o próprio negócio. Deste modo, tem-se então os casos de
67
uso de negócio, que representam os processos de negócio que definem a interação
entre entidades (atores do negócio). Logo, um diagrama de caso de uso de negócio
representa, visualmente, a interação entre os principais serviços (casos de uso de
negócio) que o negócio fornece e aqueles (atores do negócio) que utilizam esses
serviços (Rational, 2001).
Diagramas de Atividades: Dos diagramas UML, o de atividades é o que mais
adere aos modelos tradicionais de modelagem de processos de negócio como, por
exemplo, o IDEF3. Esse tipo de diagrama, inicialmente concebido com o intuito
de modelar o fluxo de trabalho relacionado ao comportamento de um sistema,
também pode ser utilizado para modelagem de processos de negócio podendo ser
denominado de diagrama de atividades de negócio. Ele permite modelar o fluxo
de trabalho considerando situações de sincronia e decisão, permite relacionar
papéis e unidades organizacionais responsáveis pela execução das atividades do
processo e, também, pode mostrar, por meio de extensões da UML, os
comportamentos e relacionamentos entre as entidades de negócio e as atividades
em execução (Rational, 2001).
Diagrama de Classes: Os diagramas de classes e de objetos apresentam os
relacionamentos entre classes e consequentemente objetos que estruturam um
sistema. Porém, sob o ponto de vista de modelagem de negócio, as entidades de
negócio também podem ser representadas como classes e objetos, o que faz com
que estes diagramas sejam viáveis na aplicação de parte dos conceitos
relacionados à modelagem de negócio. Isso pode ser exemplificado como, por
exemplo, a modelagem de estruturas organizacionais apresentando os
relacionamentos entre as unidades organizacionais num organograma, a
modelagem dos relacionamentos entre unidades organizacionais e demais
entidades de negócio utilizadas como recursos para execução dos processos de
negócio e a modelagem dos relacionamentos entre os próprios recursos (Rational,
2001; Larman, 2000).
Para que estes diagramas possam ser usados com maior precisão e representatividade
para modelar processos de negócio, a OMG publicou em 1997 um documento, que descreve os
mecanismos de extensão para a modelagem de negócios utilizando a UML, intitulado “UML
extension for business modeling”. Entretanto, este documento não descreve completamente os
novos conceitos e notações para a modelagem de negócio, apenas expondo os chamados
estereótipos que adaptam o uso da UML. No entanto, algumas mudanças e inovações podem ser
68
observadas na UML versão 2.0, principalmente no que se refere à modelagem de processos de
negócios e aos mecanismos de extensão da UML (Azevedo Junior e Campos, 2008).
Eriksson e Penker (2000), reconhecendo as diferenças que envolvem a modelagem de
negócio e a modelagem de software (diferenças que incluem recursos, regras e objetivos),
definiram um conjunto de extensões da UML para que a linguagem pudesse representar, por
meio de novos ícones (estereótipos, valores atribuídos e extensões), os principais elementos
relacionados à execução e modelagem de negócio. Vicente (2004) afirma que mesmo com esses
estereótipos, ainda existem limitações com relação à representação de alguns conceitos
relacionados à modelagem de processos de negócio.
Em sua abordagem, Eriksson e Penker (2000) consideram o diagrama de atividades como
o principal modelo de representação de modelagem de negócio, pois esta categoria de diagramas
consegue representar diversos aspectos de negócio como, por exemplo, paralelismo de execução
entre atividades, recursos usados, consumidos e produzidos por uma atividade, identificação de
responsabilidades por atividades, relacionamentos e dependências entre atividades, entre outros.
Deste modo, os autores criaram um diagrama para representar por meio de um símbolo de
processo, estereotipado do elemento atividade do diagrama de atividades, as extensões para
modelagem de negócio de acordo com a sintaxe da UML. A Figura 4.6 ilustra esse estereótipo.
Figura 4.6. Diagrama de Atividades e Estereótipos de Processos de Negócio (Adaptado de
Eriksson e Penker, 2000)
Nessa abordagem, os autores também propõem quatro vistas de negócio, que buscam
diminuir a complexidade de entendimento do negócio: (i) Vista de visão do negócio; (ii) Vista de
Processos de Negócio; (iii) Vista de Estrutura do Negócio; e (iv) Vista de Comportamento do
Negócio (Eriksson e Penker, 2000).
69
Outra proposta de extensão da UML para modelagem do negócio é a de Marshall (2000),
que sugere um metamodelo para identificação e descrição de conceitos que delineiam os
sistemas usando a UML. A proposta tem como base quatro elementos principais: propósito,
entidade, processo e organização.
A abordagem da OMG, a de Marshall (2000) e a de Eriksson-Penker (2000) são
exemplos de extensões com objetivos de modelagem de processos de negócio.
4.3. Regras de Negócio
Não há uma definição padrão na literatura para o conceito de regra de negócio, sendo que cada
autor difunde sua taxonomia para classificação, bem como algumas abordagens existentes para a
representação estruturada e padronizada dessas regras. De todo modo, o entendimento desse
contexto torna-se importante, dentre outros motivos, pelas frequentes tentativas de aproximação
entre os processos de negócio com as regras, e de ambos com os requisitos de sistemas de
informação.
No ambiente do negócio, no qual os requisitos do sistema de informação são elicitados,
todas as decisões tomadas são baseadas em fatos e, para que estas decisões sejam corretas, é
necessário que as regras que norteiam o negócio também sigam determinada lógica. Deste modo,
a tomada de decisão correta está diretamente relacionada a regras consistentes, bem como à
disponibilidade das informações aos tomadores de decisão e aos sistemas de informação
envolvidos. Essas regras e fatos são conhecidos como regras de negócio (von Halle, 2002).
Segundo Von Halle (2002), quando tomadores de decisão e sistemas de informação têm
acesso às regras de negócio apropriadas nos momentos oportunos, as decisões são tomadas com
base em informações concretas, reduzindo a possibilidade de erros. Assim sendo, as regras de
negócio podem controlar ou influenciar a execução dos processos de negócio e sua estrutura de
recursos, restringindo ou condicionando a execução de certas atividades (Eriksson e Penker,
2000), buscando aderência aos objetivos organizacionais (Bubenko et al., 2001).
Do mesmo modo que as regras de negócios têm influência direta no negócio, também
têm estreita relação com sistemas de informação (Diaz et. al. 1998). Segundo esses autores,
como resultado, esses sistemas precisam ser constantemente alterados, renovados e adaptados
para garantirem aderência às necessidades do negócio – fato que invariavelmente afeta a
elicitação e análise de requisitos do sistema de informação.
Dada essa estreita relação das regras de negócio com sistemas de informação, é possível
afirmar que o termo regra de negócio remete às regras/políticas do negócio que guiam as
70
atividades do mesmo (von Halle, 2002). Segundo essa autora, são exemplos de regras de
negócio:
Um empregado com cinco anos de empresa tem direito a quatro semanas de férias
pagas;
Um empregado com menos de quatro anos de empresa tem direito a três semanas
de férias pagas;
Um empregado com menos de seis meses de empresa não tem direito a férias
remuneradas;
São encontradas também outras definições para o termo regra de negócio na literatura.
Bell (1990) define regras de negócio como declarações que apresentam a maneira como o
negócio está sendo feito, além das diretrizes e restrições com respeito a estados e processos em
uma organização, ao passo que Ross e Lam (2000) afirmam que regra de negócio é uma parte
atômica da lógica de negócio reutilizável, especificada declarativamente. Outra definição é a
descrita por BRG (2000), o qual afirma que regra de negócio é um enunciado que define ou
restringe algum aspecto do negócio, ou seja, expressa, controla ou influencia o comportamento
do negócio, definição bastante apropriada quando realizada a analogia com requisitos de um
sistema de informação.
A perspectiva de regra de negócio foca no “modo de agir” de uma organização. As
regras, ou a ausência delas, representam os graus de liberdade que a organização admite para as
suas partes constituintes (von Halle, 2002). Esse “modo de agir” está relacionado diretamente
aos requisitos de um sistema de informação.
As regras de negócio, além de inúmeras definições, também recebem diferentes
classificações, sem haver uma que seja unânime. O esquema de classificação das regras de
negócio se torna útil dependendo do propósito da aplicação (von Halle, 2002). As propostas de
classificação das regras de negócio, segundo von Halle (2002), podem ser resumidas conforme a
Tabela 4.4.
Tabela 4.4. Classificação de Regras de Negócios (adaptado de von Halle,2002)
Fonte Esquema de Classificação da Regra de Negócio
Business
Rules
Group
HAY e
HEALY
(2000)
Derivação: Um enunciado sobre um conhecimento que é derivado de outro
conhecimento do negócio
Cálculo matemático
Inferência
Assertiva estrutural: um conceito definido ou um enunciado sobre um fato que
expressa algum aspecto da estrutura da empresa. Isso traz implícitos termos e fatos.
Termos
71
Fatos
Assertivas de ação: um enunciado de restrição ou condição que limita ou controla as
ações de uma organização
Autorização
Condição
Restrição de integridade
Ross
(2003)
Fatos
Termos
Regras
Restrições
Derivações
Inferências
Tempo
Sequência
Heurísticas
General
Data
Analysis
Rule
Types
Atributo das regras:
Unicidade
Otimização (nulo)
Checagem de valor
Computações
Inferências
Limitações multi-entidade-atributo
Regras de relacionamento:
Cardinalidade
Otimização
Referencial de integridade
Contas de cardinalidade
C. J. Date
(a)
Restrição
Estado da restrição
Transição da restrição
Estímulo/resposta
Derivação
Computação
Inferência
C. J. Date
(b)
Chris Date posteriormente propôs outro esquema para restrições que é baseado na
sua própria estrutura de dados:
Restrições de domínio
Restrições de coluna
Tabela de restrições (restrições em uma tabela)
Restrições de base de dados (restrições entre duas ou mais tabelas)
Versata
Regras de integridade de referência
Derivações (atributos computacionais)
Validação (atributos obrigatórios/valores opcionais, min, max)
Restrição (restrições atributo-a-atributo em uma entidade?)
Ação/evento
Regras de apresentação
Usoft
Regras de restrição: restrições do negócio afetas a informação a ser
armazenada, que não é permitida;
Regras de comportamento: como o sistema se comporta em determinadas
situações, o que o sistema deve fazer automaticamente;
Regras dedutivas: como a informação deve ser derivada e calculada;
Regras de apresentação: como os sistemas se apresentam ao usuário, como
72
trabalha e como suas tarefas estão organizadas;
Regras de instrução: como os usuários operam os sistemas em certas situações.
Classificar regras de negócio é interessante para explicar um conjunto de regras de
negócio a ser obtido, simplificar e guiar efetivamente o processo de descoberta de regras. Por
fim, a classificação permite ainda habilitar as pessoas da organização a expressarem cada tipo de
regra de negócio a sua maneira, garantindo clareza no entendimento (von Halle, 2002).
Para Gottesdiener (1997), as regras de negócio promovem a integração entre as pessoas
do negócio e a tecnologia, pois posicionam os membros da organização com elementos centrais
da atividade de software, ponto em que, de acordo com a literatura especializada aliada a
indústria contempla um grande gap no desenvolvimento de software, o que possibilita visualizar
a estreita relação entre regras de negócio e sistemas de informação.
Seguindo nessa linha, Gottesdiener (1997) afirma que a descoberta de regras de negócio é
uma forma efetiva de descobrir os requisitos principais dos sistemas de informação, o que
promove iniciativas que tentam aproximar a abordagem do negócio, representada por seus
processos, do processo de desenvolvimento de sistemas, que se inicia com a tarefa de elicitação
de requisitos.
Assim, a grande sinergia entre as regras de negócio e os sistemas de informação se torna
importante para a efetividade operacional e competitividade de mercado, pois o entendimento do
negócio e seu gerenciamento envolvem diretamente as regras de negócio e as aplicações que as
suportam (Shao e Pound, 1999).
Entretanto, para elicitar e analisar requisitos de sistemas de informação adequados às
regras de negócio é preciso conhecê-las, padronizá-las e documentá-las. Para tal, há alguns
métodos de modelagem de regras de negócio, que são abordados na próxima subseção.
4.3.1. Modelagem de Regras de Negócio
Nas duas últimas décadas, estudos propondo uma padronização da representação das regras de
negócio aumentaram de maneira considerável e, consequentemente, surgiram frameworks e
métodos centrados na modelagem de regras de negócio (Zaniolo, 1997; Ross, 1997;
Gottesdiener, 1999), bem como ferramentas de gerenciamento de regras de negócio e aplicativos
para suporte a ambientes de desenvolvimento, tais como: Blaze Advisor Builder6, BRS
RuleTrack7, Haley Technologies
8, ILOG Rules
9, Usoft Developer
10 ou Visual Rule Studio
11.
6 Disponível em http://discuss.fico.com.
7 Disponível em http://business.highbeam.com
8 Disponível em http://www.manta.com
73
Kardasis e Loucopoulos (2005) apresentam, de forma avaliativa, algumas abordagens
desenvolvidas para a representação das regras de negócio.
Estes autores descrevem a BROCOM (Business Rule Oriented Conceptual Modeling –
Modelagem Conceitual Orientada a Regra de Negócio). A BROCOM é uma linguagem
estruturada, em inglês, e serve para representar regras de negócio com grande expressividade.
Kardasis e Loucopoulos (2005) afirmam ainda que a lógica existente na BROCOM por trás das
regras de negócio não é completamente endereçada e que, embora, nessa linguagem, seja
proposto o desenvolvimento de vários modelos, eles não têm definições e descrições claras. Os
autores também afirmam que a linguagem BROCOM mostra-se suficiente ao ser empregada na
fase de análise dos sistemas de informação, mas insuficiente quando empregada na passagem
dessa fase para as de projeto e implementação de Sistemas de Informação, tornando-a limitada.
Outra proposta descrita e avaliada por Kardasis e Loucopoulos (2005) é a de Rosca et. al.
(apud Kardasis e Loucopoulos, 2005) que utiliza a abordagem DSS (Decision Support System –
Sistema de Apoio à Decisão). Nessa abordagem o objetivo central é a representação da lógica
das regras de negócio, na qual foi adotado o paradigma ECA (Event-Condition-Action – Evento-
Condição-Ação) para estruturar as expressões das regras e relacionar essas expressões ao modelo
do negócio.
Hay e Healy (2000) propõem outra abordagem para a representação das regras de
negócio, na qual os autores identificam os termos e fatos em linguagem natural, gerando alto
grau de expressividade. Essa abordagem também usa meta-modelo para descrever as relações
entre os termos e fatos de maneira bem detalhada. Do ponto de vista de Kardasis e Loucopoulos
(2005), os modelos de regras de negócio gerados pela abordagem são altamente controláveis,
formais e consistentes com os modelos de informação da organização. Porém, a abordagem
apresenta um ponto indesejável na concepção dos autores: o fato de não haver distinção entre os
conceitos processuais e os informacionais.
Outra abordagem para representação e esquematização das regras de negócio é a de
Zaniolo et. al. (apud Kardasis e Loucopoulos, 2005) que propõe abranger todos os estágios do
ciclo de vida de desenvolvimento de SI’s, fundamentando-se na manutenção do formalismo e da
consistência com os modelos de negócio. Entretanto, na visão de Kardasis e Loucopoulos
(2005), essa proposta apresenta pontos fracos, entre eles a dificuldade de entendimento das
9 Disponível em http://www.ilog.com
10 Disponível em http://www.usoft.com
11 Disponível em http://visual-rule-studio.software.informer.com/
74
regras de negócio pelos profissionais da organização, além da limitação na escolha da tecnologia
empregada no desenvolvimento do SI.
Seguindo nessa linha, Ross (apud Kardasis e Loucopoulos, 2005) desenvolveu um
método que se propõe a ser uma das abordagens mais completas. Na análise de Kardasis e
Loucopoulos (2005), a proposta do autor é formal, aderente aos modelos de dados de uma
organização, oferece suficiência enquanto guia metodológico e permite o gerenciamento das
regras por meio de um meta-modelo previsto na abordagem. Esse método é um dos poucos a
adotar a notação gráfica para expressar as regras, no entanto, segundo a visão avaliativa, em
alguns momentos a complexidade dos modelos traz dificuldades de entendimento das regras de
negócio para os membros da organização.
Por fim, é possível citar a OCL (Object Constraint Language – Linguagem de Restrição
de Objeto), que foi proposta por Eriksson e Penker (apud Kardasis e Loucopoulos, 2005) para
representar regras de negócio em aderência a diagramas da UML juntamente com o projeto de
sistemas Orientados a Objetos (OO). Essa abordagem não possui meta-modelo e sua estrutura
permite alocação das regras às classes, atributos, associações e operações do diagrama de classes
da UML. Para Kardasis e Loucopoulos (2005), a OCL tem um formalismo que torna a
linguagem difícil de ser entendida e usada. Além disso, ela não prevê orientações metodológicas
para a coleta das regras de negócio.
Deste modo, nota-se que há diferentes métodos de representação das regras de negócio,
cada qual com suas vantagens e desvantagens, de acordo com o caso em que está sendo aplicado
Contudo, cabe ressaltar a importância de identificação e de documentação das regras de negócio,
bem como de suas relações com outras regras e com os próprios processos de negócio seja por
meio de linguagem natural ou ainda de métodos apropriados.
4.4. Considerações Finais
A este capítulo coube a explanação de conceitos da EPN, focando aqueles inerentes e
diretamente relacionados ao objeto de pesquisa deste trabalho (elicitação e análise de requisitos
de sistemas de informação em equipes geograficamente distribuídas).
Em um primeiro momento foi descrita a de EPN, seguindo com a definição do conceito
de processos de negócio e dos elementos associados. Com o foco na aplicação dos processos em
projetos de elicitação e análise de requisitos outros temas da EPN também foram descritos.
Em um segundo momento foi também abordada a modelagem de processos de negócios.
Neste ínterim, foram tratados os benefícios da visão processual, a importância de orientações
75
para definição do nível de detalhamento dos processos e os princípios de modelagem de
processos na visão e proposta de alguns autores. Em seguida foram apresentadas algumas
metodologias de modelagem de processos (ARIS, CIMOSA, IDEF, Rede Petri, BPMN e UML)
e, foram, também, citadas algumas ferramentas que oferecem apoio a essa tarefa de modelagem.
É necessário ressaltar que há outros métodos que por vezes são aplicados para
modelagem do negócio, que mesmo não sendo descritos nesse trabalho, podem ser citados, a
saber: CEN ENV 40003, Fluxograma, ISO Reference Model, OOA (Object Oriented Analysis –
Análise Orientada a Objeto) e o SADT (Structured Analysis and Design Technique – Técnica de
Projeto e Análise Estruturada).
Por fim, o conceito de regra de negócio foi apresentado, juntamente com suas taxonomias
e métodos de representação, descrevendo, na sequencia, uma abordagem avaliativa para algumas
propostas para modelagem de regras de negócios.
Deste modo, com base na revisão da literatura no contexto da EPN realizada nesse
capítulo e relacionados ao objeto da pesquisa, objetivou-se definir alguns critérios de avaliação
das abordagens e métodos que apoiarão a proposta deste trabalho, descrita no Capítulo 5.
.
76
MoRE-GSD – A Abordagem Proposta
5.1. Considerações Iniciais
Uma maneira de obter qualidade de um Sistema de Informação é, ao iniciar seu
desenvolvimento, ter o claro entendimento do domínio do negócio que vai ser automatizado,
considerando desta forma os processos de negócio como fonte relevante para a elicitação e
análise de requisitos (Demirors et. al., 2003). De acordo com Xavier et. al. (2010) a comunidade
de engenharia de requisitos tem reconhecido a importância do uso de conceitos de processos de
negócios para orientar a elicitação de requisitos, e complementam ainda que utilizar a abordagem
orientada a processos permite uma melhor compreensão da organização, melhorando o
entendimento das reais necessidades de sistemas para apoiar os processos de negócios.
Segundo Andrade et. al. (2004), fazer uso da modelagem de processos de negócios
agrega benefícios para o desenvolvimento de software, tais como: (i) os requisitos passam a
refletir as necessidades do negócio; (ii) baixo número de redundâncias de requisitos e (iii) o
desenvolvimento do software passa a ser guiado pela necessidade do negócio.
Segundo Monsalve et. al. (2011), o desenvolvimento de software é dependente da
qualidade das atividades que envolvem a elicitação de requisitos, e não adotar a modelagem de
processos de negócios como subsídio para construir um sistema de informação pode gerar
algumas consequências indesejáveis como, por exemplo: (i) requisitos incompletos em relação às
necessidades do negócio; (ii) retrabalho e (iii) conduzir o projeto ao fracasso.
Na literatura, conforme apresentado na Seção 2.6, há propostas para integrar técnicas da
Engenharia de Processos de Negócios (EPN) com a etapa de Elicitação e Análise de Requisitos
5
Capítulo
77
(EAR), mas que apresentam conflitos entre si, pecando em aspectos determinantes, e
desconsideram outros mais atuais, conforme constatado na investigação literária e na pesquisa de
campo realizadas no contexto deste trabalho, e apresentadas nos Capítulos 3 e 4.
Somado a isso, não são encontradas, na literatura, propostas envolvendo EPN, EAR e que
contemple também um cenário de equipes, geograficamente distribuídas, desenvolvendo
software. Em empresas desenvolvedoras de software que atuam com DDS, tem se notado que
cada qual geralmente atua adaptando seu(s) processo(s) de desenvolvimento conforme a
demanda de necessidades, “criando” desta forma “metodologias particulares de
desenvolvimento” de acordo com o conhecimento empírico dos profissionais envolvidos. Isso foi
constatado na prática, apoiado pelo Projeto PROCAD12
, quando da visita in loco em empresas,
conforme descrito no Capítulo 3.
Com o intuito de maximizar benefícios de DDS, é desejável que as atividades de
desenvolvimento de um projeto, incluindo a EAR, possam ser realizadas 24 horas por dia –
característica conhecida em DDS como follow-the-Sun.
Motivado pelos desafios da EPN e etapas da EAR, encontrados na literatura e na
indústria, somados ao contexto DDS, encontrado especialmente na indústria, a proposta descrita
neste capítulo apresenta uma abordagem para apoiar a elicitação e análise de requisitos a partir
das regras de negócio (etapa da EPN) para equipes que trabalham com desenvolvimento
distribuído de software.
A MoRE-GSD (Modeling Business Process for Requirements Elicitation in Global
Software Development) é uma abordagem que tem como base os conceitos abordados no
Capítulo 2, os quais explicitam vários gaps em pontos específicos da etapa de EAR. Estes são
aliados a não completude descrita nos trabalhos relacionados e, ainda, somados às características
levantadas em visitas in loco em empresas de desenvolvimento de software (conforme descrito
no Capítulo 3).
Deste modo, esta abordagem apresenta uma proposta de solução para a elicitação e
análise de requisitos apoiada na modelagem de processo de negócio quando as equipes
encontram-se geograficamente distribuídas, principalmente as atuantes no modelo Offshoring.
As subseções seguintes detalham a abordagem proposta.
12
PROCAD é o Programa Nacional de Cooperação Acadêmica. Neste caso, as instituições envolvidas foram
ICMC/USP, UEM e PUC/RS, e o projeto tinha por título: Integrando e aprimorando atividades de pesquisa,
ensino/treinamento e transferência tecnológica em tese e validação de software.
78
5.2. Arcabouço da Abordagem MoRE-GSD
O estudo de abordagens propostas no contexto de Engenharia de Processos de Negócios e
Engenharia de Requisitos de Software aliado às informações coletadas junto a empresas
desenvolvedoras de softwares com equipes distribuídas fornecem um alicerce para a abordagem
proposta neste trabalho.
Algumas abordagens propostas para elicitação e análise de requisitos consideram os
modelos de processos de negócios como primeiro passo para desenvolver um produto de
software (de la Vara, 2008). Entretanto, além das funcionalidades, faz-se necessário identificar os
demais requisitos e regras de negócio que refletem as reais necessidades para automatizar os
processos (Carvalho, 2009), além da inserção de características correlatas ao desenvolvimento
distribuído de software.
Dados estes desafios e necessidades, a MoRE-GSD (Modeling Business Process for
Requirements Elicitation in Global Software Development), consiste em formalizar, por meio de
passos e diretrizes, uma abordagem para que a elicitação e análise de requisitos apoiada pela
modelagem de processos de negócios possa ser realizada por equipes distribuídas, usufruindo
dos benefícios que o DDS oferece, atuando principalmente no modelo de Offshoring.
A Figura 5.1 ilustra os itens chave que servem de arcabouço para a abordagem MoRE-
GSD considerando-se o contexto descrito.
Figura 5.1. Arcabouço da Abordagem MoRE-GSD.
Modelagem dos Processos de Negócio para
apoiar a EAR em equipes de DDS Uso de ferramenta (única
para as equipes distribuídas) para
automatizar a modelagem;
Uso do conceito de regras de negócios;
Definição de diretrizes para o nível de
detalhamento das regras de negócio;
Definição de Processo de Negócio e de seus
elementos
Definição de Diretrizes de padronização dos
modelos de processos;
79
A Revisão Bibliográfica aliada aos trabalhos relacionados; Pesquisa de campo em
empresas que trabalham com um modelo de negócios similar ao abordado nesta dissertação por
meio do projeto PROCAD, e; Estudo de técnicas e ferramentas para modelagem de processos de
negócios, capítulos 2, 3 e 4, respectivamente, contribuíram para compreender os aspectos que o
processo de elicitação e análise de requisitos realizada por equipes distribuídas devem apoiar,
embasando deste modo a abordagem MoRE-GSD.
Definir e fazer uso do conceito de Processos de Negócio no que se refere ao fluxo lógico
das informações, alicerçado no arcabouço conceitual da EPN é importante, haja vista que são
estes processos os responsáveis pelo fornecimento da visão processual de um negócio, item que
reflete diretamente para que os requisitos de software sejam obtidos (Erikson e Penker, 2000;
Cruz, 2004; Carvalho, 2009).
Subsidiam também a abordagem MoRE-GSD aspectos como a padronização na
modelagem dos processos, usando, para tal, princípios consistentes segundo as diretivas a serem
descritas na Subseção 5.3 do arcabouço conceitual da EPN (Carvalho, 2009), ponto fundamental
ao se trabalhar com equipes geograficamente distribuídas, devido aos desafios que este modelo
de desenvolvimento apresenta.
Além disso, atentar para a padronização na modelagem possibilita o desenvolvimento de
modelos que capturam as diversas características do negócio, principalmente, no que se diz
respeito ao fluxo de informações, executores, regras de negócio e recursos, viabilizando também
outras ações da EPN (como reengenharia, análises e reestruturações organizacionais, etc.) (Cruz,
2004; Vicente, 2004).
De acordo com a revisão bibliográfica e visitas in loco às empresas, foi notória também a
necessidade da operacionalização da tarefa de modelagem dos processos por meio de uma
técnica/ferramenta computacional.
O Capítulo 4 descreveu algumas destas técnicas/ferramentas a fim de guiar na escolha de
uma que aderisse à abordagem MoRE-GSD atentando principalmente para a dispersão
geográfica das equipes, critério que justifica o uso de uma ferramenta única para todos os times
que realizam desde a EAR até a implementação e testes do software que vai ser desenvolvido.
Neste contexto, optou-se, em detrimento das demais, a técnica BPMN, por atender aos itens
descritos como necessários, possuir representação gráfica com possibilidade de detalhamento
textual em pontos chave da modelagem e, também, por ser de uso e acesso a treinamentos
facilitados, tornando viável seu uso por equipes geograficamente distribuídas.
A prática de modelar os processos aliada a uma ferramenta deve considerar a elaboração
de diretrizes que guiem na determinação dos níveis de detalhamento dos processos necessários à
80
tarefa de elicitação de requisitos de sistema. Embora não haja regras exatas, estabelecer tais
diretrizes é fundamental para descrever claramente o fluxo de informação (e os artefatos
gerados), bem como detectar os problemas ou informações relevantes para a definição dos
requisitos de sistema (Vicente, 2004; Carvalho, 2009). Com as diretrizes torna-se possível ainda
estabelecer correlações entre as atividades dos processos e as funcionalidades identificadas para
os sistemas gerando correspondências entre requisitos de negócio e de sistemas.
No entanto, é notório que não basta definir como essas regras são identificadas, mas é
preciso também estabelecer critérios que orientem o procedimento de transformação dessas
regras em requisitos de sistema ou indiquem como essas informações contribuem para a
construção desses requisitos, favorecendo a elicitação e análise de requisitos realizada por
equipes geograficamente distribuídas.
Deve-se também observar que, ao se trabalhar com equipes geograficamente distribuídas,
um dos maiores desafios é a comunicação dentro da equipe e, principalmente, entre equipes
(Prikladnicki e Audy, 2006; Aranda et. al., 2008). Devido a tal característica, é necessário que
seja definido um idioma padrão para comunicação.
A abordagem MoRE-GSD gera artefatos em seus passos, e é necessário que toda
documentação esteja em um idioma padrão, para que, desde o início da modelagem até a
concepção final do sistema de informação proposto, haja um fluxo contínuo das informações
documentadas.
Sugere-se que a definição do idioma considere: (i) o idioma dos responsáveis pela
concepção de um projeto novo; (ii) problemas de interpretação quando o idioma definido é
diferente entre equipes; e (iii) a necessidade de validação dos requisitos pelos clientes.
Normalmente, quando os stakeholders não possuem o mesmo idioma nativo, a língua
inglesa é escolhida para interações e geração de artefatos (Aranda et. al., 2008). Portanto, o
idioma definido para a abordagem MoRE-GSD é o inglês.
A seção seguinte detalha a estrutura da abordagem MoRE-GSD, após a exposição do
arcabouço necessário para que a mesma seja implementada.
5.3. Detalhamento da Abordagem MoRE-GSD
A modelagem dos processos de negócio deve ser sistematizada por uma abordagem preparada
para tal e não por metodologias originalmente concebidas para a modelagem de sistemas
(Vicente, 2004; Carvalho, 2009) – fato descrito pela literatura especializada e confirmada por
meio de experiência na indústria de software (conforme apresentado no Capítulo 3).
81
Quando a EAR em ambientes distribuídos é baseada na modelagem de processos de
negócio, notoriamente ela pode ser facilitada. Deste modo, a abordagem MoRE-GSD consiste
em uma sequencia de passos, nos quais para cada um deles, há diretrizes específicas que guiam a
execução da EAR, apoiadas pela modelagem dos processos de negócios, para equipes
geograficamente distribuídas atuando, principalmente, no modelo de negócios Offshoring.
A Figura 5.2 ilustra o processo no qual a MoRE-GSD está inclusa, desde a concepção do
projeto entre Cliente e Gerente de Projeto até a fase de implementação dos requisitos elicitados,
passando pela etapa de EAR – que ocorre de maneira distribuída. O quadro tracejado central na
figura destaca esse contexto da atuação da MoRE-GSD.
Figura 5.2. Visão Geral da Abordagem MoRE-GSD.
Em um primeiro momento, Cliente e Gerente de Projetos alinham o que deverá ser
desenvolvido na linguagem do cliente. A nomenclatura de Gerente de Projetos neste ponto é
sugestiva, haja vista que muitas vezes quem realiza essa atividade é chamado de Analista de
Negócios.
Finalizada essa primeira etapa, de modo que as atividades do software proposto estão
identificadas, é possível distribuir para duas ou mais equipes as atividades (características ou
necessidades do sistema) que cada equipe deverá modelar a fim de realizar a EAR, fazendo uso
da abordagem MoRE-GSD, a fim de que ao final do processo os requisitos funcionais de um
software tenham sido elicitados. Após a distribuição das atividades, a MoRE-GSD deve ser
utilizada por cada equipe, de acordo com seus passos e diretrizes, a fim de que os requisitos de
software possam ser elicitados de maneira padronizada e com qualidade. Deste modo, na
Implementação: Centralizada ou
Distribuída
Descrição Inicial do Projeto Cliente – Gerente de Projeto
Atividade Centralizada
Atividades Distribuídas
...
Modelagem por equipes distribuídas seguindo os passos
e diretrizes da MoRE-GSD
...
EAR de um mesmo projeto obtida de
maneira distribuída
82
distribuição e possibilidade de continuidade de atividades da EAR fica notória a característica de
DDS conhecida por follow-the-sun, diminuindo o tempo de trabalho nesta etapa, por exemplo.
A EAR, quando realizada conforme sequência da abordagem MoRE-GSD, pode ser
disponibilizada, preferencialmente ao final de um passo completo, para outra equipe para ser
continuada por essa equipe. A equipe que recebe os artefatos de outra, pode continuar o processo
de EAR a partir do ponto em que a equipe anterior parou, usando para compartilhar estes
artefatos, meios eletrônicos (e-mail, repositório de compartilhamento ou software de controle de
versão de documentos, por exemplo), uma vez que estão geograficamente distantes.
Estes fatores favorecem as vantagens do DDS, como a produção 24 horas por dia e a
terceirização, sempre objetivando que a qualidade seja preservada – uma vez que há
padronização no processo, facilitando o acesso a mão de obra qualificada, por exemplo.
Aplicada a abordagem MoRE-GSD às atividades inicialmente recebidas por cada equipe,
e concluindo a atividade de EAR, as demais fases do desenvolvimento poderão voltar a ser
centralizadas, ou continuar sendo distribuídas, já estando fora do escopo do presente trabalho.
A padronização da MoRE-GSD faz com que, mesmo a elicitação acontecendo por
equipes geograficamente distribuídas, os artefatos gerados sejam padronizados para todos os
requisitos. Pode ser possível, inclusive, que haja troca de papéis desempenhados pelos membros
entre as equipes que realizam a EAR, mas como há a modelagem gerando a formalização dos
requisitos, não há prejuízo ou perda de informação.
A MoRE-GSD é estruturada em passos, cada qual com suas respectivas diretivas de
aplicação. A nomenclatura adotada é S (de Step) seguido do número do passo, concatenada com
a letra G (de Guideline) e o número da diretriz. Por exemplo, para o Passo 1 e Diretrizes 1, 2 e 3,
a nomenclatura descrita é apresentada, respectivamente, da seguinte forma: S1G1, S1G2 e S1G3.
A cada passo artefatos são gerados, e servem como entrada para a diretriz/passo seguinte.
Cada artefato gerado deve ser documentado no BRD (Business Requirement Document), seja de
forma textual (em inglês) e/ou com inserção de figuras que auxiliem no processo. Cada passo
representa uma seção do BRD e, nestas seções, as diretrizes são descritas obedecendo a
sequencia proposta pela abordagem MoRE-GSD.
Para que a abordagem MoRE-GSD tenha efetividade, os passos descritos nas subseções
seguintes devem ser seguidos na ordem em que são apresentados.
83
5.3.1. Aplicação do Conceito de Processos de Negócios –
Passo 1
No cenário em que se encontra a abordagem MoRE-GSD, desenvolvimento distribuído de
software, o primeiro passo para que sejam gerados requisitos de software é que todas as equipes
empreguem o conceito de modelagem de processos de negócios, segundo direciona a EPN.
Neste contexto, a MoRE-GSD adota a definição de Processos de Negócio descrita por
Santos (2007), por se tratar de uma definição bastante completa e baseada em uma extensa
revisão bibliográfica:
“Processo de Negócio é uma estruturação-coordenação-
disposição lógico-temporal de ações e recursos com o
objetivo de gerar um ou mais resultados para a organização.
Os processos podem estar em diferentes níveis de abstração
ou detalhamento, relacionados às atividades gerenciais,
finalísticas ou de apoio. Se forem finalísticos, os resultados
gerados são produto(s)/serviço(s), se forem gerenciais
promovem o funcionamento da organização e seus
processos, e se forem de suporte prestam apoio aos demais
processos da organização. Podem possuir um responsável
por seu desempenho global e responsáveis locais
direcionados aos andamento de suas partes-constituintes e,
comumente, são transversais a forma por meio da qual a
organização se estruturou (por função, por produto, por
eixo geográfico etc.). Processos estão intrinsecamente
relacionados aos fluxos de objetos na organização, sejam
estes objetos materiais, informações, capital, conhecimento,
ideias ou qualquer outro objeto que demande coordenação
de seu fluxo. Aos processos cabe o desenvolvimento ou
desenrolar dos fluxos de objetos enquanto às funções ou
unidades organizacionais cabe a concentração de
conhecimentos por semelhança. Os processos são objetos
de controle e melhoria, mas também permitem que a
organização os utilize como base de registro do
aprendizado sobre como atua, atuou ou atuará em seu
ambiente ou contexto organizacional. Os processos são a
organização em movimento, são, também, uma estruturação
para ação: para a geração e entrega de valor” (Santos,
2007).
Há outros conceitos relacionados a processos de negócio que são úteis na concepção da
abordagem MoRE-GSD. Eriksson e Penker (2000) definem alguns desses conceitos quando
mencionam também atributos de descrição e de medição.
Atributos de descrição, segundo os autores, se relacionam com a descrição textual ou
gráfica do processo, demonstrando como o processo é executado e quais são os insumos
(recursos de entrada processados e consumidos pelo processo) e os produtos (recursos de saída).
O atributo de medição está relacionado diretamente às métricas (indicadores) do processo, que
consideram fatores de tempo, custo e qualidade. O nível de detalhamento dos processos
84
(processos desdobrados em subprocessos) também é um aspecto importante, e será abordado no
Passo 2.
Deste modo, é possível afirmar que processos são formados por uma ou mais atividades
executadas por trabalhadores ou sistemas, regidos por regras de negócio, iniciados a partir de
eventos externos ou internos da organização e finalizados por algum tipo de evento que indica o
alcance do seu objetivo.
Assim, os objetivos do negócio definem os propósitos gerais que um negócio pretende
alcançar, podendo ser particionados em sub-objetivos agrupados, por exemplo, por áreas
funcionais do negócio. Assim, todo processo deve estar associado direta ou indiretamente a pelo
menos um objetivo estratégico, fato que guia o primeiro passo da abordagem aqui proposta.
Seguindo essa descrição, é possível apontar os principais conceitos relacionados a
Processos de Negócio, os quais cada equipe distribuída tem que considerar antes mesmo de
iniciar a modelagem dos mesmos. Cada equipe deve seguir todas as diretivas. Baseado nestes
apontamentos, as diretrizes do Passo 1 da MoRE-GSD, conforme a Tabela 5.1, são:
Tabela 5.1. Diretrizes do Passo 1 da Abordagem MoRE-GSD.
S1G1
Cada atividade recebida do Gerente de Projetos pela equipe que vai iniciar a EAR
deve ser relativa a uma única ação. Caso uma atividade tenha detalhamento em
subatividades, considere apenas as subatividades representadas no mesmo contexto
principal. Para as outras, devem ser geradas novas atividades. Por “contexto
principal” entende-se como sendo as subatividades necessárias para que uma
atividade possa ser iniciada e finalizada.
S1G2
Verificar, para cada atividade, se ela pode se tornar uma ação do software de modo
a separar as entradas de um processo em funcionais (por exemplo, lançar novo
produto) e não funcionais (por exemplo, deseja-se rapidez no lançamento).
Interessarão aqui apenas as funcionais;
S1G3 Verificar se as atividades selecionadas possuem apenas uma única entrada de dados.
Caso seja identificada mais de uma, deve-se retornar a S1G1.
S1G4
Verificar se as saídas de uma atividade correspondem ao resultado do processo,
ponto de partida para o Passo 2. Caso não correspondam, deve-se retornar a S1G1 e
verificar se esta não é subatividade de uma atividade.
S1G5
Identificar qual equipe está realizando a elicitação e análise de requisitos de cada
processo. Essa identificação pode ser realizada com um nome para a Equipe (nome
do País e Cidade, por exemplo).
S1G6
Associar um número inteiro que serve como identificador para o processo definido,
a fim de proporcionar a rastreabilidade do processo. Pode ser gerado um número
sequencial, de maneira manual.
É notório que os processos de negócio, no contexto da EPN, são importantes para garantir
uma melhor compreensão da organização como um todo e, consequentemente, do software que
será desenvolvido para sua automatização. Esses processos, ao serem mapeados conforme as
diretivas da Tabela 5.1, geram um artefato chamado Modelos de Processos, cujas finalidades
85
básicas são: representação, análise e melhoria da forma que o trabalho é realizado nas
organizações, orientado para produtos, clientes e mercados conforme indicado por SANTOS et
al. (2002).
No Passo 1, por meio de suas diretrizes, há artefatos de entrada e saída, e todos devem
estar descritos no Business Requirement Document – BRD, na primeira seção deste documento –
por ser tratar do Passo 1 da abordagem MoRE-GSD.
5.3.2. Documentação das Regras de Negócios – Passo 2
O Passo 2, da abordagem MoRE-GSD, concentra-se na aplicação do conceito de Regras de
Negócio, referindo-se às afirmações que definem ou limitam alguns aspectos do negócio.
São as Regras de Negócio que determinam como o negócio deve se comportar, como os
processos de negócio devem ser executados e como os recursos utilizados são estruturados e
relacionados entre si. As regras são definidas a partir de leis externas ou internamente ao
negócio, buscando alcançar os objetivos. A representação das regras pode variar desde a forma
textual até a gráfica (Eriksson e Penker, 2000).
O uso desse conceito torna-se importante para a elicitação e análise de requisitos, pois
além da influência direta no negócio, as regras de negócio também têm estreita relação com os
sistemas de informação, principalmente em ambientes de rápidas e constantes mudanças (Diaz
et. al., 1998), característica presente no contexto de DDS, e na proposta desta dissertação, na
qual cada equipe faz a EAR de parte de um mesmo projeto, ou ainda, uma equipe inicia a EAR,
mas é outra que as conclui, com o apoio da MoRE-GSD.
Essa estreita relação se dá porque as regras servem como orientação, influenciando o
comportamento coletivo dos membros de uma organização, controlando ou influenciando a
execução dos processos de negócio e sua estrutura de recursos, restringindo ou condicionando a
execução de certas atividades e dos sistemas de informação que as suportam.
Deste modo, representar as regras de negócio como fonte de informações de requisitos de
um software é fundamental para que a etapa de elicitação e análise dos requisitos seja mais
aderente às reais necessidades do negócio. Isso é enfatizado ao considerar um ambiente de
desenvolvimento distribuído de software, no qual possíveis ambiguidades podem se tornar
pontos de divergência entre equipes distribuídas, ou deixar de corresponder aos pontos
levantados pelo cliente, fato que ficou comprovado com visitas in loco a empresas que atuam
com DDS.
86
Portanto, o objetivo deste passo é fazer uso de regras de negócio a fim de diminuir
possíveis ambiguidades facilitando a comunicação entre as equipes geograficamente distribuídas,
direcionando as equipes distribuídas por meio das diretivas a realizarem o processo de modo
padronizado, proporcionando que os benefícios de DDS descritos no Capítulo 2 sejam
alcançados. A Tabela 5.2 apresenta as primeiras diretivas do Passo 2 da abordagem MoRE-GSD.
Tabela 5.2. Diretrizes do Passo 2 da Abordagem MoRE-GSD.
S2G1
Deve-se associar cada regra de negócio gerada no Passo 2 a um processo gerado ao
final do Passo 1. Isso é feito associando o identificador (número inteiro) gerado em
S1G6, com um identificador (número inteiro) nesta diretriz.
S2G2
Cria-se uma estória de cada processo, na visão do cliente, em texto estruturado,
seguindo as seguintes cláusulas:
i. WHO?
ii. WHAT?
iii. WHY?
S2G3
Por meio da cláusula WHAT, deve-se separar o que indica ser requisito funcional
(necessário no software como funcionalidade) e o que indica ser requisito não
funcional (característica da funcionalidade), e comparar com a separação obtida em
S1G2. Se não houver divergências, segue-se para S2G4. Se houver divergências,
retorna-se para S1G2.
S2G4 Documentar no BRD o que foi indicado como possível funcionalidade do software,
e o que foi indicado como possível requisito não funcional.
A abordagem MoRE-GSD propõe documentar as regras de negócio no formato de
estórias, em um padrão de linguagem estruturada, e escrita no idioma inglês.
A representação das regras de negócio proposta em MoRE-GSD emprega linguagem
natural, e mantem uma representação consistente, conforme indicado em S2G2, que minimiza
possíveis ambiguidades, item de grande relevância no DDS, sendo todas registradas no BRD. É
possível exemplificar o Passo 2, Diretivas 1 e 2, conforme a Figura 5.3.
.
Equipe: Brasil
ID: Regra de Negócio 1 – Processo de Negócio1
WHO? I, as a customer
WHAT? I need an interface for payment by credit card that is intuitive and
easy to use
WHY? In order to facilitate my payments
.
Figura 5.3. Ilustração após as Diretivas 1 e 2 do Passo 2 da Abordagem MoRE-GSD.
A partir do exemplo descrito na Figura 5.3, o ID no cabeçalho da estória associa essa
regra de negócio (Regra de Negócio 1) a uma equipe (Equipe: Brasil) e a um processo de
87
negócio de S1G6, o que direciona o rastreamento e gerenciamento dos artefatos gerados em toda
abordagem MoRE-GSD.
A expressão contida na cláusula WHO (S2G2) indica quem é o solicitante daquela regra
de negócio, que pode ser, por exemplo, o cliente, um desenvolvedor, um sistema que fará parte
de uma integração ou ainda outro. Essa cláusula direciona para quem é o ator do processo de
negócio associado à regra detalhada.
A expressão contida na cláusula WHAT direciona a separação do que é requisito
funcional e o que é requisito não funcional (Diretiva S2G3). Neste exemplo é possível separar o
que é requisito funcional – “I need an interface for payment by credit card” (Preciso de uma
interface de pagamento por cartão de crédito), do que é requisito não funcional, condizente com
a parte final da expressão – “that is intuitive and easy to use” – que seja intuitiva e fácil de usar.
Finalizando, a cláusula WHY justifica a existência dessa estória, minimizando possíveis
ambiguidades, bem como vem possibilitar o futuro rastreamento dos requisitos, identificando
prováveis dependências que possam existir durante a implementação dos requisitos elicitados.
5.3.2.1. Nível de Detalhamento dos Processos de Negócio
Ainda no Passo 2, a visão processual, ao se materializar em modelos de processos de negócio
com suas respectivas regras de negócio, deve estar em um nível de detalhamento adequado. Para
Cameira e Caulliraux (2000) essa questão é pauta para discussões sem fim, principalmente por
ser impossível chegar a regras exatas neste ponto. Estes autores afirmam ainda que o nível de
detalhamento é uma variável fuzzy não existindo uma regra exata em sua definição
Vicente (2004) afirma que mesmo dentro de um escopo definido podem existir níveis de
detalhamento diferentes, pois as pessoas, que são entrevistadas ou que executam a modelagem
dos processos de negócio, podem apresentar níveis de conhecimento e de experiência diferentes
refletindo no nível de agregação dos modelos.
Cameira e Caulliraux (2000) afirmam que um processo deve descrever claramente o
fluxo de informação (e seus artefatos). Estes autores descrevem também que um processo não
deve ser superficial demais, mesmo que o objetivo seja apenas entender superficialmente como
são os macroprocessos de uma organização. Consideram também que o mesmo raciocínio se
aplica em situações, dependendo das características do negócio, que a maior parte dos problemas
provavelmente está lotada nos processos operacionais, que não necessariamente aparecem em
modelagens agregadas ou em descrições de fluxos ainda em nível macro.
88
Fazendo uso das afirmações de Cameira e Caulliraux (2000), essa etapa da abordagem
MoRE-GSD foi também discutida com profissionais quando das visitas às empresas, conforme
relatado no Capítulo 3. Pode-se notar que as estratégias seguidas pelas empresas visitadas
sempre dependem do conhecimento empírico da empresa/dos profissionais envolvidos, não
havendo um padrão para tal.
Assim, adotar um padrão nesse ponto da EAR se faz necessário, principalmente ao
considerar o DDS, uma vez que em cada polo de desenvolvimento podem existir profissionais
com cultura, conhecimento e demais características sociais e técnicas diferentes, ou até bastante
divergentes.
A fim de padronizar o nível de detalhamento dos processos de negócios e de suas regras
de negócio associadas, a abordagem MoRE-GSD propõe, ainda no Passo 2, a diretriz 5, que é
apresentada na Tabela 5.4.
Tabela 5.3. Diretriz Para o Nível de Detalhamento das Regras de Negócio.
S2G5
A cláusula WHAT de S2G2 deve ter apenas uma oração – sujeito
simples/composto, associado a um único verbo.
Caso tenha mais de uma oração na cláusula WHAT, a regra de negócio deve ser
dividida em duas ou mais estórias (Retornando para S2G1), até que tenha apenas
uma oração associada.
Quando tiver apenas uma oração, o nível de detalhamento está satisfatório.
No exemplo utilizado na Figura 5.3, a cláusula WHY está com a sentença “in order to
facilitate my payments” (com o objetivo de facilitar meus pagamentos). Se aqui houvesse mais
de um verbo associado ao sujeito (neste caso há somente o verbo facilitar), essa estória deveria
ser detalhada em duas ou mais estórias, a fim de minimizar ao máximo a ambiguidade e a futura
modelagem deste processo de negócio.
Por exemplo, se a sentença neste ponto fosse “com o objetivo de facilitar e prover uma
nova forma para meus pagamentos”. Neste caso, uma estória descrita estaria associada ao verbo
“facilitar” e outra ao verbo “prover” uma nova forma de pagamento.
Entretanto, conforme afirmado na literatura e comprovado na indústria, não se deve
desconsiderar o conhecimento empírico de cada equipe ao solicitar um maior detalhamento de
cada processo de negócio.
Ao finalizar S2G5, devem-se documentar na Seção 2 do BRD, os artefatos gerados neste
passo.
89
5.3.3. Modelagem dos Processos de Negócios – Passo 3
O objetivo da modelagem de processos é desenvolver os modelos que capturem as diversas
características no negócio, simplificando a representação de uma realidade mais complexa por
meio da omissão de detalhes irrelevantes para a análise desejada, de modo a facilitar o
entendimento dos envolvidos e afetados por determinado processo (Bubenko et al., 2001).
Com a modelagem dos processos é possível gerar uma visão processual em detrimento da
funcional. A primeira visão facilita indiretamente, segundo Cameira e Caulliraux (2000), quebrar
barreiras funcionais, permitindo o tratamento processual dos fluxos de informação.
Deste modo, se faz necessário que haja um fluxo contínuo e ininterrupto dos processos e
regras de negócio na abordagem MoRE-GSD, haja vista que é fato, segundo Sommerville
(2007), que a correta elicitação e análise dos requisitos de um software são a base do sucesso de
um projeto de software. Assim, espera-se que os processos de negócio modelados não estejam
limitados ao provimento de informações para o desenvolvimento de sistemas de informação, mas
que também possam auxiliar em outras análises e aplicações da EPN.
A abordagem MoRE-GSD tem como diretrizes para a modelagem dos processos de
negócio as apresentadas na Tabela 5.4.
Tabela 5.4. Diretrizes para Modelagem de Processos de Negócios da Abordagem MoRE-GSD.
S3G1
A técnica padrão para modelagem dos processos de negócio entre as equipes
distribuídas é BPMN. A ferramenta para automatizar a modelagem é de livre
escolha, de acordo com a preferencia de cada profissional (o artefato gerado é o
mesmo);
S3G2 Deve-se associar de maneira explícita cada processo modelado às suas respectivas
regras de negócio em S2G1;
S3G3 Cada objeto representado no modelo deve ter um propósito. Deste modo, um
modelo não deve conter mais informações do que o necessário;
S3G4 Os elementos gráficos gerados pela modelagem BPMN devem estar relacionados às
regras de negócio em S2G4, havendo um processo com início e fim para cada regra;
S3G5
Caso exista necessidade de representar uma interrupção temporal, por dependência
de outras estórias ou outro motivo qualquer, uma atividade passiva deverá ser
representada por meio de um estado no modelo BPMN.
A diretriz S3G1 direciona para o uso de BPMN (entre as descritas no Capítulo 4) como
técnica padrão de modelagem dos processos de negócio. Por meio de visitas, houve a
constatação do crescente uso desta técnica nas empresas desenvolvedoras de software. Na
maioria delas, segundo profissionais destas empresas, a técnica BPMN tem sido satisfatória,
dada sua gama de elementos gráficos, quantidade de ferramentas que a automatizam, fácil acesso
90
a treinamentos e crescente número de profissionais que fazem uso da mesma, ratificando o que é
descrito na literatura relativa ao tema.
Novamente há a associação do artefato gerado no passo atual com o do passo anterior, o
que ocorre em S3G2. Cada modelo gerado deve ter um propósito único, tornando este artefato
intuitivo e fácil de compreender, minimizando ambiguidades e outros problemas de comunicação
entre membros de uma mesma equipe, e entre equipes distribuídas que desenvolvem o mesmo
projeto, não trazendo prejuízos à continuidade constante do projeto por equipes em diferentes
locais do mundo.
Ao final desse passo há então a modelagem gráfica com a técnica BPMN associada a
cada processo de negócio, contemplando as regras de negócio do mesmo. Essa modelagem é
também inserida no BRD, na seção 3 – haja vista que o passo atual é o terceiro.
5.3.4. Representação dos Requisitos de Sistema – Passo 4
A representação formal dos requisitos de sistema ao final da fase de elicitação de requisitos
torna-se importante para manutenção da rastreabilidade das informações e utilização das mesmas
nas demais etapas do ciclo de vida do software.
Existem inúmeras técnicas, notações e linguagens encontradas na literatura e conhecidas
na indústria que podem ser empregadas com a função de documentar e gerenciar os requisitos de
sistema. No entanto, segundo Vicente (2004), a UML é uma das linguagens mais utilizadas,
dentre outros motivos por ser gráfica, e que especifica, constrói e documenta os artefatos de
sistemas. Além disso, a UML representa uma coleção das melhores práticas que vem sendo
aprimorada e aprovada tanto pela comunidade científica quanto pela indústria.
Após a execução dos 3 passos iniciais, a abordagem MoRE-GSD propõe no Passo 4, a
representação dos requisitos de sistema. Esta representação segue as diretrizes explicitadas na
Tabela 5.5.
Tabela 5.5. Diretrizes Para Representação dos Requisitos de Sistema.
S4G1
Gerar os Casos de Uso Simplificados (leia-se: Casos de Uso adaptados para a
MoRE-GSD), segundo:
Em S2G2, quem estava na clausula WHO, representa um ator do Caso de Uso;
O que foi separado como requisito funcional na clausula WHAT de S2G2 torna-
se caso de uso;
S4G2 Associar cada Caso de Uso Simplificado a uma raia na modelagem BPMN realizada
do processo de negócio, e a estória escrita.
S4G3 Cada caso de uso é relacionado a uma única atividade do processo de negócio,
seguindo a diretriz S2G5, que trata do nível de detalhamento dos processos de
91
negócio.
S4G4
Finalização do BRD, que deve conter, além das indicações já descritas nos passos
anteriores:
Descrição do negócio a ser modelado;
Enumeração dos processos e atividades considerados no desenvolvimento do
sistema;
Listagem das necessidades de negócio existentes em cada processo;
Relação das funcionalidades e restrições do sistema;
No contexto da abordagem MoRE-GSD, a modelagem obtida pela técnica BPMN
descreve, graficamente, os passos do processo que tornaram-se um caso de uso, ao passo que as
estórias minimizam, consideravelmente, as ambiguidades que poderiam vir a existir em cada
funcionalidade, fazendo com que a EAR possa ser compartilhada entre equipes antes de chegar a
sua representação final, fazendo uso dos benefícios do DDS, especialmente o follow-the-sun.
Deve-se observar que a forma de documentar os requisitos deve subsidiar o entendimento
e o aproveitamento destes requisitos nas demais etapas do ciclo de vida de software, de forma a
garantir a rastreabilidade e a gestão dos mesmos, fato que a abordagem MoRE-GSD contempla.
Ao final, o BRD contem todos os artefatos gerados pelos quatro passos e suas diretrizes.
Esse BRD pode ser compartilhado entre equipes distribuídas enquanto se está em fase de EAR,
pois com as diretrizes uma equipe pode continuar o trabalho iniciado por outra, haja vista que há
uma sequência lógica de passos e diretrizes.
É também viável que outra equipe qualquer implemente os requisitos que passaram pela
EAR guiados pela abordagem MoRE-GSD, sem a presença da equipe que realizou a EAR, pois
os artefatos gerados se complementam em detalhamento, reduzindo ambiguidades e possíveis
dúvidas que fatalmente teriam em um ambiente de desenvolvimento distribuído de software.
5.4. Considerações Finais
Dada a necessidade de uma abordagem que contemplasse EAR, EPN e DDS, este capítulo
apresentou a abordagem MoRE-GSD, buscando apoio adequado à etapa de EAR, fazendo uso de
práticas da EPN em DDS, principalmente com o objetivo de que os benefícios inerentes ao DDS
sejam obtidos.
Esta abordagem objetiva guiar, por meio de passos e diretrizes, a elicitação e análise de
requisitos, de modo que a descrição até a representação dos requisitos possam ocorrer de forma
padronizada, proporcionando a realização e compartilhamento de toda a etapa de EAR por
equipes geograficamente distribuídas. As etapas anteriores e posteriores à EAR não são tratadas
pela MoRE-GSD.
92
Deste modo, as vantagens inerentes ao DDS, como o follow-the-Sun, a utilização de
recursos globais a qualquer momento, redução de custos com possíveis terceirizações, entre
outras, sejam possíveis também na etapa de elicitação e análise de requisitos.
93
Estudo de Viabilidade
6.1. Considerações Iniciais
Este capítulo apresenta um estudo experimental de viabilidade da abordagem MoRE-GSD, e tem
como objetivo coletar evidências, pontos fortes e fracos sobre a abordagem proposta (Travassos,
2002).
A característica central deste estudo de viabilidade é coletar os dados baseando-se em
uma pré-estrutura que guia o experimento (Mafra e Travassos, 2006), com o objetivo de aferir a
viabilidade do uso em grande escala da abordagem MoRE-GSD pela indústria que trabalha com
desenvolvimento distribuído de software, bem como referenciar, academicamente, trabalhos
futuros que sigam a linha proposta neste documento.
O objetivo não é encontrar uma resposta definitiva, e sim construir um corpo de
conhecimento que aborda a plausibilidade da continuidade do estudo, gerar novas hipóteses
sobre a abordagem e sua utilidade.
Para que esse experimento seja efetivo, e de acordo com os paradigmas da pesquisa
experimental, este capítulo foi direcionado de acordo com a análise qualitativa que evidencia a
observação natural, com análise subjetiva e orientada a descoberta (Travassos, 2002).
Deste modo, pelas características da aplicação deste estudo de viabilidade, é possível
classificá-lo como Estudo Experimental – direcionado por questões e hipóteses (Travassos,
6
Capítulo
94
2002), com caracterização e possibilidade de controle da amostra utilizada de modo direto,
preciso e sistemático (Yin, 2005).
Pode-se justificar pelo não uso de uma estrutura de Estudo de Caso, pois, conforme
afirmam Yin (2005) e Travassos (2002), estudo de caso é a técnica escolhida quando o objetivo é
examinar estudos contemporâneos, mas nestes não se podem manipular comportamentos
relevantes, além de exigir que haja observação direta e uma série sistemática de entrevistas,
pontos não possíveis de serem realizados no contexto deste estudo.
As etapas deste estudo experimental, em sequência, estão conforme a Figura 6.1.
Figura 6.1. Etapas do Experimento (Mafra e Travassos, 2006).
6.2. Definição dos Objetivos
Essa fase inicial objetiva a definição das metas do estudo experimental (Travassos, 2002), que
estão de acordo com o protocolo a ser definido na sequência. Neste âmbito, tal estudo pode ser
caracterizado como multi-teste, pois há um único objeto de estudo e mais de um participante por
objeto (Mafra e Travassos, 2006).
Esta seção apresenta os objetivos deste estudo experimental de viabilidade da abordagem
MoRE-GSD sobre as perspectivas global, a relacionada à medição e, por fim, a do estudo.
6.2.1. Objetivo Global
O objetivo global deste estudo é caracterizar a viabilidade da abordagem MoRE-GSD para sua
efetiva utilização, colaborando com o desenvolvimento científico da Engenharia de Software, e
servindo de apoio para a elicitação e análise de requisitos, em particular, na indústria por equipes
geograficamente distribuídas.
6.2.2. Objetivo da Medição
O objetivo da medição, do presente estudo, é investigar e caracterizar a abordagem MoRE-GSD
com relação à sua viabilidade para guiar a EAR no contexto de desenvolvimento distribuído de
software.
Análise e
Interpretação Execução
Planejamento Definição dos
Objetivos
95
6.2.3. Objetivo do Estudo
O objetivo do estudo visa garantir que os aspectos importantes do estudo experimental sejam
definidos antes do planejamento e da execução, e indica que este será efetivamente realizado
(Travassos, 2002).
O objetivo deste estudo foi elaborado segundo os princípios do paradigma GQM – Goal
Question Metric (Basili e Rombach, 1988), e são:
Analisar a abordagem MoRE-GSD para equipes geograficamente distribuídas
com o propósito de caracterizar
com respeito a à viabilidade dos passos, diretrizes e artefatos definidos pela abordagem
do ponto de vista do pesquisador
no contexto de profissionais que atuam com desenvolvimento distribuído de software.
6.2.4. Questões de Estudo
As questões definidas para este estudo são:
Q1: Os passos e diretrizes da abordagem MoRE-GSD apoiam a elicitação e
análise de requisitos no desenvolvimento distribuído de software?
o Métrica: A lista de passos e diretrizes propostos na abordagem.
Q2: Os artefatos gerados na abordagem MoRE-GSD não apoiam o
desenvolvimento distribuído de software, servindo como meio de comunicação
entre as equipes de desenvolvimento?
o Métrica: A lista de artefatos especificados pela abordagem.
6.3. Planejamento
Esta etapa é responsável por preparar como o estudo será conduzido, e é composta pelas
seguintes fases: definição das hipóteses, seleção do contexto e dos participantes, projeto do
estudo e instrumentação, e validade do experimento (Mafra e Travassos, 2006).
6.3.1. Definição das hipóteses
Uma hipótese é uma teoria ou suposição que pode explicar um determinado comportamento de
interesse da pesquisa (Mafra e Travassos, 2006).
As hipóteses definidas para esse estudo são:
96
H0: A abordagem MoRE-GSD não guia a elicitação e análise de requisitos de um
projeto por equipes geograficamente distribuídas.
H1: A abordagem MoRE-GSD guia a elicitação e análise de requisitos de um
projeto por equipes geograficamente distribuídas.
6.3.2. Seleção do Contexto e dos Participantes
A seleção do contexto e dos participantes está diretamente ligada à possibilidade de
generalização dos resultados da abordagem MoRE-GSD por meio do estudo experimental. Esse
direcionamento sugere que a amostra seja da melhor maneira representativa da população não
em quantidade, mas em qualidade, que se almeja alcançar, para a qual se quer generalizar os
resultados (Mafra e Travassos, 2006). Assim, este estudo tem como contexto, empresas que
atuam no modelo Offshoring de desenvolvimento distribuído de software.
A condução deste estudo se deu em ambiente empresarial, por meio de questionários
enviados eletronicamente a profissionais que realizam a EAR no modelo Offshoring, antes e
após o uso da abordagem MoRE-GSD, em um projeto real.
Por serem profissionais e realizaram a EAR com o uso da abordagem proposta, pode-se
afirmar que a seleção dos participantes da amostra não ocorreu de forma aleatória, sendo a
amostragem obtida por conveniência, segundo classifica Travassos (2002). O projeto envolveu
três empresas localizadas em países diferentes, mas que atuam frequentemente em projetos
únicos.
Segundo Shull et. al. (2001), o mais adequado para estudos de viabilidade é conduzi-los
em ambientes acadêmicos, haja vista que a proposta passa por um primeiro teste antes de seu uso
na indústria.
Entretanto, a aplicação deste estudo na indústria contribui significativamente para uma
validação mais fiel da abordagem MoRE-GSD, pois os desafios da EAR no DDS vivenciados na
prática por estes profissionais podem contribuir com uma visão mais abrangente na validação e
direcionamento da evolução da abordagem MoRE-GSD.
A caracterização das empresas foi obtida por meio do questionário Q01 (Apêndice B) e
pesquisas na Internet, em seus respectivos portais. As empresas estão identificadas como E1, E2
e E3 a fim de preservá-las. Deve-se destacar que as empresas que participaram da aplicação do
estudo concordaram com o termo de consentimento CT01 disponibilizado às mesmas (Exemplo
do CT01: Apêndice A).
97
A Tabela 6.1 caracteriza as três empresas que participaram do experimento e, de maneira
geral, seus colaboradores, conforme o Questionário Q01.
Tabela 6.1. Descrição das empresas participantes do experimento.
Empresa Descrição
E1
Localizada no Brasil, no estado do Paraná, foi fundada em 2006, e trabalha desde
2008 com Offshoring. É especializada no desenvolvimento de aplicações Web com
Ruby on Rails e PHP, e desenvolvimento para dispositivos móveis (tanto Android
quanto iOS). Trabalha também com estruturas de código aberto, como PHP Trax,
Symfony, Zend e Joomla. Atualmente conta com oito colaboradores, dos quais três
atuam com Elicitação e Análise de Requisitos, e os mesmos três atuam também
com Modelagem de Processos de Negócios.
E2
Localizada nos Estados Unidos, no estado da Califórnia, foi fundada em 2000. Atua
com desenvolvimento de software para Web e dispositivos móveis focando
pequenos e médios negócios, principalmente start-ups, em um modelo de troca:
automatiza o empreendimento do cliente e obtém lucro a partir do lucro deste
cliente (ganha uma porcentagem do que o cliente ganhar). Desenvolve em parceria
com empresas terceirizadas (dentro e fora dos EUA) desde sua fundação. Tem
aproximadamente cinquenta colaboradores, sendo que a maioria atua como
vendedores de projetos e aliciamento de potenciais clientes. Em média, de sete a
dez colaboradores trabalham com Elicitação e Análise de Requisitos e também com
desenvolvimento dos sistemas. Aproximadamente trinta colaboradores atuam com
Modelagem de Processos de Negócios (incluindo todos os que atuam com
Elicitação e Análise de Requisitos e desenvolvimento – requisito para contratação,
tanto de colaboradores, quanto de empresas parceiras para desenvolvimento).
E3
Localizada nos Estados Unidos, no estado da Flórida, foi fundada em 2006. Faz
parte de um grupo de quatro empresas, que se caracteriza como “fornecedor de
serviço completo de entretenimento digital e produção de conteúdo”. A empresa do
grupo participante deste experimento atua principalmente com desenvolvimento de
layouts gráficos para sistemas Web e em dispositivos móveis desenvolvidos por
outras empresas (seja elas do mesmo grupo ou terceirizadas). Atualmente, conta
com vinte e quatro colaboradores, subdivididos em três times de desenvolvimento.
O time que participou deste experimento é composto por seis colaboradores, dos
quais apenas um atua com Elicitação e Análise de Requisitos. Nenhum colaborador
do time havia atuado anteriormente com modelagem de processos de negócio.
Nas três empresas, os participantes deste estudo foram colaboradores que atuam com
elicitação e análise de requisitos de maneira direta (realizando a EAR) ou indireta (usando a
EAR para implementar ou testar o que fora desenvolvido).
A caracterização dos participantes que fizeram uso da abordagem MoRE-GSD e
retornaram o Questionário Q02 (Apêndice C) respondido totalizou um montante de 11
colaboradores. Foram enviados 15 questionários, totalizando aproximadamente 74% de retorno.
A Tabela 6.2 descreve estes 11 participantes de acordo com as variáveis independentes
do Questionário Q02, destacando sua formação (Questão 1), experiência em desenvolvimento de
software (Questão 2), experiência em desenvolvimento distribuído de software (Questão 3),
experiência em modelagem de processos de negócio (Questão 4), e experiência em elicitação e
98
análise de requisitos (Questão 5). A descrição está organizada por questão respondida, destacada
em negrito.
Tabela 6.2. Caracterização dos participantes do experimento.
Empresa Participante Descrição
E1
Participante 1 1. Pós-Graduação Completa – lato sensu; 2. Sim, 3 anos; 3. Sim, 3
anos; 4. Não; 5. Não.
Participante 2 1. Superior Incompleto; 2. Sim, 4 anos; 3. Sim, 2 anos; 4. Sim, 2 anos
e 6 meses; 5. Sim, 4 anos.
Participante 3 1. Superior Incompleto; 2. Sim, 3 anos; 3. Sim, 2 anos; 4. Sim, 1 ano;
5. Sim, 1 ano.
Participante 4 1. Superior Completo; 2. Sim, 11 anos; 3. Sim, 5 anos; 4. Sim, 4 anos;
5. Sim, 3 anos e 6 meses.
E2
Participante 1 1. Pós-Graduação Incompleta – stricto sensu; 2. Sim, 10 anos; 3. Sim,
6 anos; 4. Sim, 6 anos; 5. Sim, 10 anos.
Participante 2 1. Superior Incompleto; 2. Sim, 3 anos; 3. Sim, 1 ano; 4. Sim, 1 ano;
5. Sim, 3 anos.
Participante 3 1. Pós-Graduação Completa – lato sensu; 2. Sim, 5 anos e 6 meses;
3. Sim, 4 anos; 4. Sim, 2 anos e 6 meses; 5. Sim, 5 anos.
Participante 4 1. Superior Incompleto; 2. Sim, 2 anos e 6 meses; 3. Sim, 2 anos; 4.
Sim, 2 anos; 5. Sim, 2 anos.
Participante 5 1. Superior Completo; 2. Sim, 7 anos; 3. Sim, 6 anos e 6 meses; 4.
Sim, 4 anos; 5. Sim, 6 anos e 6 meses.
E3
Participante 1 1. Superior Incompleto; 2. Sim, 2 anos e 6 meses; 3. Sim, 2 anos e 6
meses; 4. Não; 5. Não.
Participante 2 1. Superior Incompleto; 2. Sim, 8 anos; 3. Sim, 2 anos; 4. Não; 5. Sim,
6 anos.
Ao analisar a Tabela 6.2 pode-se destacar que 54% dos colaboradores respondentes não
possuem ensino superior completo, enquanto apenas dois deles, o que soma aproximadamente
18%, possuem pós-graduação completa.
Nota-se, também, que a média de tempo de experiência em desenvolvimento de software
é de aproximadamente 5,5 anos, média que diminui quando se trata especificamente de DDS,
sendo de aproximadamente 3,3 anos.
É importante destacar que, na questão de modelagem de processos de negócio, a
experiência média dos respondentes é de aproximadamente 2,1 anos, mesmo havendo um
colaborador que possui 6 anos de experiência neste quesito.
Já a média de experiência na EAR é mais elevada, sendo de aproximadamente 3,8 anos,
havendo apenas um colaborador sem qualquer experiência específica neste quesito. Entretanto,
este profissional não gera dados discrepantes, haja vista que atua com DDS, e fez o uso
normalmente da MoRE-GSD.
99
6.3.3. Projeto do Estudo e Instrumentação
Conforme já destacado, este estudo caracteriza-se como um experimento, e visa coletar dados a
partir do uso da abordagem MoRE-GSD por profissionais das três empresas descritas na Tabela
6.2.
Os colaboradores das três empresas caracterizados na Tabela 6.2 também responderam ao
questionário do estudo de viabilidade, denominado Questionário Q03 (Apêndice D), subdividido
em partes de interesses particulares, contendo 14 questões, dentro de uma escala de mensuração,
conforme a Tabela 6.3 apresenta.
Tabela 6.3. Escala de mensuração das respostas do Questionário Q03
Valor [1] [2] [3] [4] [5]
Resposta à
questão:
Sim, em
todas as
vezes;
Sim, na
maioria
das vezes;
Não, em
boa parte
das vezes;
Não, em
nenhuma
das vezes;
Sem
Resposta
Não foi utilizada uma escala com um número impar de opções opinativas (cinco, por
exemplo) a fim de não conter um valor intermediário que direcionasse para a neutralidade, pois,
segundo Laitenberger e Dreyer (1998), a opção de um valor neutro não fornece informações
sobre a direção para qual o participante está inclinado (concordância ou discordância). Deste
modo, a escala das variáveis varia de [1] a [4].
Entretanto, para eliminar as respostas não conformes (outliers13
) geradas por dúvidas,
desconhecimento ou interpretação dúbia foi incluído o item [5] que descarta a questão a título de
análise descritiva para obter um valor mais representativo ao final da coleta de dados.
6.3.4. Validade do Experimento
Um ponto fundamental com relação aos resultados de um estudo experimental é identificar o
quão válidos eles são, pois estes resultados devem ser generalizados. Esta fase do experimento
deve ser considerada na fase de planejamento (Travassos, 2002).
Ainda, segundo Travassos (2002), há quatro tipos de validade: interna, externa,
construtiva e conclusiva, as quais são descritas nas subseções a seguir.
13
Outlier é um resultado atípico que apresenta um grande afastamento dos demais valores. São ameaças em
pesquisas e estudos experimentais.
100
6.3.4.1. Validade Interna
A validade interna refere-se ao tratamento-resultado e seus riscos estão relacionados aos
participantes, que podem ficar cansados ou desanimados, o que pode afetar os resultados
negativamente. Assim, reforça-se a necessidade de uma instrumentação, preparada
adequadamente, para evitar maus entendimentos (Travassos, 2002).
Neste experimento, os participantes foram selecionados com base no conhecimento e
experiência em desenvolvimento distribuído de software. A validade interna é dependente do
número de participantes, quanto maior o número de participantes melhor será a validade interna.
6.3.4.2. Validade Externa
A validade externa é relacionada às condições que limitam a habilidade de generalizar os
resultados. Essa validade é dependente da capacidade do estudo em refletir o mesmo
comportamento em outros grupos de participantes e profissionais da indústria, ou seja, em outros
grupos além daquele em que o estudo foi aplicado (Travassos, 2002).
Os dados do perfil dos indivíduos podem ser analisados para avaliar o nível de
experiência e conhecimento em elicitação e análise de requisitos, em modelagem de processos de
negócio, e em desenvolvimento distribuído de software, realizado neste experimento pelo
Questionário Q02. De acordo com esta caracterização, pode-se afirmar o quão generalizável é a
abordagem proposta.
6.3.4.3. Validade Construtiva
A validade construtiva considera os relacionamentos entre a teoria e a observação, ou seja, se o
tratamento reflete bem a causa e o resultado reflete bem o efeito. Os problemas a serem
considerados referem-se ao fato dos participantes se basearem nas hipóteses e na expectativa do
pesquisador (Travassos, 2002). Este tipo de validade não se faz muito adequado para o presente
experimento, dadas suas características.
6.3.4.4. Validade Conclusiva
A validade conclusiva se relaciona à habilidade de chegar a uma conclusão correta a
respeito dos relacionamentos entre o tratamento e os resultados do experimento. A validade
conclusiva mensura a relação entre o tratamento e o resultado, determinando a capacidade do
101
estudo em gerar alguma conclusão. A obtenção de boas conclusões será permitida por meio de
uma boa definição das variáveis independentes e dependentes juntamente com as analises
descritivas adequadas (Travassos, 2002).
Este foi o tipo de validação buscada para o experimento em questão, pois, a partir da
análise do perfil de conhecimento dos participantes sobre área de elicitação e análise de
requisitos, modelagem de processos de negócio e desenvolvimento distribuído de software, os
dados coletados podem ser assumidos como confiáveis ou não confiáveis.
6.4. Execução do Experimento
Segundo Mafra e Travassos (2006), a execução é a etapa na qual os participantes do experimento
realizam suas tarefas proporcionando a coleta de dados.
Para a execução deste estudo, foi redigido um roteiro em formato de memorial descritivo
(Apêndice F) explanando a abordagem MoRE-GSD, e enviado juntamente com um questionário
do perfil do entrevistado (Questionário Q02).
O projeto em que as empresas E1, E2 e E3 realizaram a EAR com o apoio da MoRE-
GSD, teve como objetivo desenvolver um aplicativo para realizar Forex14
de valores arrecadados
entre os jogadores que compram fichas em dinheiro real, a partir de um site já bastante utilizado
de Poker. O objetivo final é que, a partir da nova funcionalidade integrada ao site de Poker, seja
possível alcançar outros mercados além dos EUA e, ao mesmo tempo, cativar os atuais jogadores
de Poker cadastrados no site a fazerem uso deste aplicativo de Forex. Isso trará um ganho extra
ao site e aos próprios jogadores. Uma das necessidades básicas foi que o aplicativo tivesse
autenticação integrada ao login e password do Facebook do usuário.
Todo o site foi desenvolvido na linguagem Ruby com o framework Ruby on Rails (RoR).
Para evitar possíveis incompatibilidades técnicas, o cliente solicitou que o aplicativo de Forex
também fosse desenvolvido em RoR.
O aplicativo requereu interface Web para os usuários que acessam o jogo pelo site, e
também a disponibilização para usuários de gadgets da Apple (principalmente iPhone e iPad). A
EAR foi distribuída entre estas 3 empresas. Para a implementação, um grupo de requisitos foi
alocado a cada empresa, de acordo com a especialidade de cada uma.
Em diversos projetos anteriores estas 3 empresas já foram parceiras para realização da
EAR, pois para que cada qual desenvolva seus requisitos, é necessário ter conhecimento dos
14
Forex vem de Foreign Exchange, e significa Mercado de Câmbio. É um mercado financeiro descentralizado
destinado a transações de câmbio, sendo um dos maiores mercados do mundo.
102
requisitos das outras equipes a fim de desenvolver um software melhor alinhado. Esta condição
facilitou a aplicação de um questionário comparativo, que será descrito na subseção 6.5.4.
Após o uso da abordagem MoRE-GSD no projeto, foi então enviado o questionário de
viabilidade (Questionário Q03, disponível no Apêndice D) para os colaboradores das empresas
E1, E2 e E3, retornaram, em média, dois dias após o término do uso da abordagem MoRE-GSD
pelos mesmos.
6.4.1. Resultados Obtidos
A partir da aplicação e retorno dos questionários, foi possível documentar os dados que os
participantes apontaram acerca da abordagem MoRE-GSD.
Os dados nas linhas das Tabelas 6.5 e 6.6 apontam a resposta associada a uma empresa
(E1, E2 ou E3) e a um participante desta empresa (P1, P2, etc.), conforme os dados coletados.
O Questionário Q03, que trata das variáveis dependentes, foi subdividido em duas partes.
A primeira, contem sete questões relativas à Utilidade, enquanto a segunda, contendo também
sete questões, trata da percepção dos colaboradores quanto à Facilidade de Uso da abordagem
MoRE-GSD.
A escala de mensuração, definida na fase de Planejamento deste estudo para as questões
abaixo listadas, segue o padrão apresentado na Tabela 6.3. Quanto ao tema Utilidade, foram
apresentadas as seguintes questões:
(A) O conjunto de passos e diretrizes guiou a elicitação e análise de requisitos no
ambiente distribuído?
(B) A continuidade da elicitação e análise de requisitos por uma equipe iniciada
por outra equipe foi possível?
(C) As estórias contribuíram para diminuir possíveis ambiguidades de uma
atividade?
(D) Os elementos gráficos do BPMN relacionados às regras de negócio
melhoraram o nível de detalhamento requerido para a elicitação e análise dos
requisitos?
(E) As cláusulas WHO, WHAT e WHY foram claras em sua definição no passo
em que foram aplicadas?
(F) O conjunto de passos e diretrizes atende às necessidades de organização e
comunicação que o desenvolvimento distribuído de software requer?
103
(G) Conjunto de artefatos atende às necessidades de organização e comunicação
que o desenvolvimento distribuído de software requer?
A Tabela 6.4 apresenta os dados obtidos de retorno para as questões (A) a (G), relativos
à utilidade da abordagem MoRE-GSD.
Tabela 6.4. Resultados obtidos para as variáveis dependentes (A) a (G) – Utilidade
Empresa/Participante (A) (B) (C) (D) (E) (F) (G)
E1/P1 1 1 2 3 1 1 1
E1/P2 1 1 1 1 1 1 1
E1/P3 1 2 2 1 2 1 2
E1/P4 1 1 2 1 1 1 1
E2/P1 2 1 3 2 2 1 1
E2/P2 1 2 1 1 1 1 1
E2/P3 2 2 2 2 2 2 1
E2/P4 1 1 2 2 2 1 2
E2/P5 1 1 1 1 1 1 1
E3/P1 1 1 2 5 2 1 1
E3/P2 1 1 1 3 2 2 1
A segunda parte dos dados, relativos às variáveis dependentes, trata da percepção dos
usuários da abordagem MoRE-GSD quanto à Facilidade de Uso da mesma. Foram elencadas as
seguintes questões quanto a esse tema:
(H) A nomenclatura comum a todas as equipes possibilitou entender a
dependência das atividades e artefatos?
(I) O modo de identificar as equipes possibilitou saber quem desenvolveu qual
artefato?
(J) O modo de identificar passos e diretrizes possibilitou acompanhar a sequência
da abordagem?
(K) Seguir os passos e diretrizes foi fácil?
(L) O uso da técnica BPMN foi acessível a todos?
(M) Os passos e diretrizes foram descritos de forma clara e compreensível?
(N) Foi fácil lembrar os passos e diretrizes durante o uso da abordagem MoRE-
GSD?
A Tabela 6.5 apresenta, de forma estruturada, os dados obtidos para as questões (H) a
(N), relativos à Facilidade de Uso da abordagem MoRE-GSD.
104
Tabela 6.5. Resultados obtidos para as variáveis dependentes (H) a (N) – Facilidade de Uso
Empresa/Participante (H) (I) (J) (K) (L) (M) (N)
E1/P1 2 1 1 2 3 1 3
E1/P2 1 1 1 1 1 1 2
E1/P3 1 1 1 2 1 2 1
E1/P4 1 1 1 1 1 1 3
E2/P1 1 1 1 2 2 1 2
E2/P2 1 1 1 2 2 1 2
E2/P3 2 2 2 2 2 1 2
E2/P4 1 1 2 2 2 1 2
E2/P5 1 1 1 1 1 1 3
E3/P1 2 1 2 2 5 2 3
E1/P2 1 1 1 2 3 1 2
A seção seguinte apresenta a análise e interpretação do experimento aplicado às
empresas.
6.5. Análise e Interpretação do Experimento
Esta etapa refere-se à análise descritiva dos resultados tabulados dos grupos de informações, e
divide-se em cinco etapas: Validação dos Dados, Estatística Descritiva – Utilidade, Estatística
Descritiva – Facilidade de Uso, Análise Comparativa e Verificação das Hipóteses.
As subseções seguintes descrevem estas etapas.
6.5.1. Validação dos Dados
Neste estudo, diretamente, 11 profissionais fizeram parte como respondentes, de três empresas
distintas, sendo uma localizada no Estado do Paraná (Brasil), outra no Estado da Califórnia
(EUA), e uma terceira, no estado da Flórida (EUA).
As três empresas foram parceiras em um mesmo projeto real, caracterizando o modelo
Offshoring. Os participantes deste estudo são profissionais destas três empresas, e fizeram uso da
abordagem MoRE-GSD na fase de Elicitação e Análise de Requisitos do projeto desenvolvido na
parceria das três empresas.
Foram respondidos pelos profissionais os seguintes questionários: Caracterização do
Participante, Viabilidade da Abordagem MoRE-GSD e, após a finalização total do projeto, estes
também responderam ao questionário Análise Comparativa (Apêndice E). Não foram
encontrados outliers nas respostas dos questionários.
105
O questionário Análise Comparativa teve como objetivo aferir, de forma qualitativa, se
houve ou não ganho, melhoria ou otimização da EAR apoiada pela modelagem de processos de
negócio no ambiente de DDS com a MoRE-GSD ao ser comparada sem a utilização da mesma.
6.5.2. Estatística Descritiva – Utilidade
Esta análise buscou identificar se a MoRE-GSD, ao ser aplicada por profissionais em um projeto
real, mostrou-se útil para o que foi proposta. Os dados foram colhidos por meio de questionários
junto aos profissionais que fizeram uso da mesma.
A Figura 6.2 apresenta, quantitativamente, as respostas obtidas para o contexto de
Utilidade da MoRE-GSD.
106
Figura 6.2. Respostas relacionadas à percepção de Utilidade da MoRE-GSD.
A tabulação e apresentação de dados são fundamentais ao bom julgamento estatístico,
uma vez que permitem focar em características relevantes a serem utilizadas na solução de
problemas.
107
Desse modo, as medidas de tendência central, neste caso, mediana e moda – já que os
valores estão em escala ordinal, organizam a amostra destacando os acontecimentos
(Montgomery e Runger, 2009).
A mediana divide os dados em duas partes iguais. Se o número de observações for par, a
mediana estará na metade da distância entre os dois valores centrais. Se o número de
observações for ímpar, a mediana será o valor central. A moda é o valor da observação que
ocorre com mais frequência (Montgomery e Runger, 2009).
A Tabela 6.6 apresenta a estatística descritiva (mediana e a moda) dos dados coletados
referentes às questões A à G (Utilidade da abordagem MoRE-GSD).
Tabela 6.6. Análise Descritiva – Utilidade
Questões (A) (B) (C) (D) (E) (F) (G)
Mediana 1,18 1,27 1,72 1,54 1,54 1,18 1,27
Moda 1 1 2 1 2 1 1
Ao analisar a Tabela 6.6, nota-se que para as questões A, B, F e G, os resultados para a
Mediana se mantiveram na casa de 1, enquanto para a Moda, sempre foi de 1, relativo à resposta
“Sim, em todas as vezes”.
Com base nestes dados, é possível inferir que: (A) O conjunto de passos e diretrizes
guiou a elicitação e análise de requisitos no ambiente distribuído – mostrando que a abordagem
MoRE-GSD se apresentou completa para o contexto em que se propôs; (B) A continuidade da
elicitação e análise de requisitos por uma equipe iniciada por outra equipe foi possível –
apresentando que o objetivo inicial, de realizar a EAR de modo distribuído, foi eficiente; (F) O
conjunto de passos e diretrizes atende às necessidades de organização e comunicação que o
desenvolvimento distribuído de software requer – apenas corroborando as duas questões
anteriores, mostrando que a MoRE-GSD contribui de fato para o DDS, na etapa de EAR; e (G)
Conjunto de artefatos atende às necessidades de organização e comunicação que o
desenvolvimento distribuído de software requer.
Também pode ser observado que, na Tabela 6.6, a questão (D) – que faz referencia aos
elementos gráficos do BPMN relacionados às regras de negócio, melhorarem o nível de
detalhamento requerido para a EAR – obteve mediana 1,54. Pode-se concluir que este resultado
deve-se aos 3 profissionais que não conheciam BPMN, fato que levou estes a aprenderem a
técnica durante a aplicação da MoRE-GSD, não obtendo um melhor aproveitamento em um
108
primeiro momento. Entretanto, pode-se afirmar que este critério foi essencial e bem aceito entre
os profissionais, haja vista que o valor mais repetido (moda) foi 1.
Finalizando, as questões (C) e (E) obtiveram como moda o valor 2.
Para a Questão (C) – que fez referência às estórias contribuírem para reduzir possíveis
ambiguidades de uma atividade – pode-se concluir que, na maioria dos casos, as estórias
contribuíram, mas não foram essenciais sempre. Isto pode ser atribuído à simplicidade e
eficiência da modelagem dos processos de negócio com a técnica BPMN.
A questão (E) – que tratou da clareza na definição das cláusulas WHO, WHAT e WHY –
fundamental na abordagem MoRE-GSD por tratarem-se da transformação de uma atividade em
requisitos, podem ser melhor descritas, para que o valor da moda seja 1, embora a mediana tenha
ficado na casa de 1,5.
6.5.3. Estatística Descritiva – Facilidade de Uso
De modo similar à seção anterior, esta análise buscou identificar se a MoRE-GSD, ao ser
aplicada por profissionais em um projeto real, apresentou-se de maneira fácil de ser utilizada por
estes profissionais para o que foi proposta.
Os dados para esse critério também foram colhidos por meio de questionários junto aos
profissionais que fizeram uso da abordagem proposta, e as respostas obtidas quanto ao critério
Facilidade de Uso estão representadas na Figura 6.3.
109
Figura 6.3. Respostas relacionadas à percepção de Facilidade de Uso da MoRE-GSD.
De modo análogo à análise da subseção 6.5.2, estes dados foram tabulados e estão
descritos na Tabela 6.7, que apresenta a estatística descritiva (mediana e a moda) dos dados
coletados referentes às questões H à N (Facilidade de Uso da abordagem MoRE-GSD).
Tabela 6.7. Análise Descritiva – Facilidade de Uso
Questões (H) (I) (J) (K) (L) (M) (N)
Mediana 1,27 1,09 1,27 1,72 1,63 1,18 2,27
Moda 1 1 1 2 1 1 2
110
Analisando a Tabela 6.7, é possível notar que para as questões (H), (I), (J), (L) e (M) a
moda sempre foi 1, enquanto a mediana variou entre 1,09 e 1,63, para os itens (I) e (L),
respectivamente. Portanto, para todas estas, questões pode-se afirmar que não houve dificuldades
quanto ao uso da abordagem MoRE-GSD.
A questão (K), que tratou da facilidade de seguir os passos e diretrizes, e a questão (N),
que perguntou se foi fácil lembrar os passos e diretrizes durante o uso da abordagem MoRE-
GSD, obtiveram mediana próxima de 2 e moda exatamente o valor 2. Estas duas questões estão
ligadas entre si, e tratam do formato em que os passos e diretrizes estão descritos.
Neste ponto, pode-se concluir que isso ocorreu por ser uma abordagem apresentada aos
usuários por meio de um memorial descritivo, e não existir ainda um software que automatize a
MoRE-GSD. Essa questão abre como precedente e direcionamento para trabalhos futuros, a
replicação do experimento com as mesmas equipes, que agora já treinadas, podem obter um
resultado melhor.
Portanto, com base nestes dados, é possível concluir que a abordagem MoRE-GSD é de
fácil uso entre profissionais que realizam a EAR em ambientes distribuídos de desenvolvimento.
6.5.4. Análise Comparativa
Após a finalização do projeto em que a MoRE-GSD foi utilizada na fase de EAR pelas três
empresas participantes do experimento, foi enviado o Questionário Q04 (Apêndice E) aos 11
colaboradores que fizeram uso da abordagem e que responderam ao Questionário Q03.
O Questionário Q04 teve como objetivo identificar junto a estes colaboradores as
diferenças notadas no projeto em que fizeram uso da MoRE-GSD para outros projetos já
desenvolvidos em Offshoring. Obteve-se de retorno 100% dos Questionários Q04 enviados.
Com o propósito de realizar uma análise quantitativa, neste momento não estão
associadas respostas com colaboradores, uma vez que o objetivo é que a MoRE-GSD possa ser
utilizada por profissionais de quaisquer titulação ou tempo de experiência.
As três primeiras questões disponibilizaram como resposta, três opções: Sim; Não; e Sem
Resposta – esta última dando a liberdade de ser usada quando o colaborador não tivesse
segurança de optar por Sim ou por Não.
Os resultados inerentes à primeira questão estão expressos na Figura 6.4.
111
Figura 6.4. Respostas relacionadas ao follow-the-sun.
A questão: “No projeto que foi utilizada a MoRE-GSD, notou-se o follow-the-Sun na
EAR tornando sua execução de certa forma mais rápida?”, obteve 73% de respostas Sim e 9% de
respostas Não (e ainda 18% que marcaram a opção “Sem resposta”). As respostas negativas
podem ser relacionadas a pontos específicos da MoRE-GSD em que os colaboradores não
tinham experiência, a técnica BPMN, por exemplo. Estes dados evidenciam que, em equipes que
atuam com DDS fazendo uso da MoRE-GSD, o tempo da EAR é reduzido.
Os resultados da questão: “Com os artefatos gerados no uso da abordagem MoRE-GSD, a
EAR foi melhor organizada em termos de comunicação?”, estão expressos na Figura 6.5.
Figura 6.5. Respostas relacionadas à questão de Artefatos e Organização.
112
Nesta questão não houve respostas negativas. Se considerar como outliers os 9% que
marcaram a opção Sem Resposta, conclui-se que todos os colaboradores concordam que os
artefatos da abordagem MoRE-GSD proporcionaram uma melhor organização do processo de
EAR, o que pode melhorar a rastreabilidade de requisitos e a atribuição de responsabilidades,
entre equipes distribuídas.
A Figura 6.6 ilustra a distribuição das respostas relativas a questão: “Os artefatos da
abordagem MoRE-GSD proporcionaram segurança para a comunicação fluir bem entre as
equipes?”.
Figura 6.6. Respostas relacionadas à questão de Artefatos e Comunicação.
Como mostra o gráfico da Figura 6.6, esta questão obteve 100% de respostas positivas,
não deixando margens para arguições contra a notória melhoria na comunicação quando da
geração e compartilhamento de artefatos da abordagem MoRE-GSD.
A quarta questão do Questionário Q04 indagou os colaboradores quanto à porcentagem
de aproveitamento dos requisitos que foram elicitados com apoio da MoRE-GSD. A Figura 6.7
apresenta os resultados.
113
Figura 6.7. Aproveitamento dos requisitos.
Nota-se que há um espalhamento em três opções de respostas, não havendo unanimidade
neste quesito. Isso pode ser atribuído a atividade de implementação também ser distribuída, e
cada colaborador que respondeu ao questionário, esteve responsável por um conjunto diferente
de requisitos, resultando em um aproveitamento diferente.
É notório também que 55% das respostas se mantiveram no intervalo compreendido entre
70% e 85% de aproveitamento, algo que demonstra que o formato da documentação, definição
do nível das regras de negócio e demais diretrizes da abordagem MoRE-GSD estiveram em um
nível de aproveitamento bom.
O valor de 27% do aproveitamento dos requisitos que estiveram no intervalo de 35% a
70% de aproveitamento pode ser considerado expressivo, pois essa é uma faixa que aponta para
a geração de retrabalho, aumento do tempo e do custo de um projeto. Para tal, melhorias
precisam ser realizadas na abordagem MoRE-GSD.
Uma destas melhorias apontadas na questão final do questionário (questão aberta) foi a
implementação de uma ferramenta que automatize a abordagem, a fim de que o trabalho seja
minimizado, menos manual e mais intuitivo, pois são várias diretivas a serem seguidas.
Por fim, os colaboradores foram questionados se adotariam a abordagem MoRE-GSD em
suas empresas, com as opções de resposta: “Sim, no formato em que ela se encontra”; “Sim, mas
ela precisa de melhorias”; e “Não adotaria”. A Figura 6.8 ilustra as respostas obtidas.
114
Figura 6.8. Adoção da MoRE-GSD
Notou-se com as respostas que 100% dos profissionais que fizeram uso da abordagem
adotariam a MoRE-GSD como metodologia para realização da EAR de modo distribuído em
suas empresas e empresas parceiras, mesmo sendo 55% destes profissionais favoráveis a
melhorias na abordagem. Novamente destaca-se que grande maioria das melhorias sugeridas
estão no sentido de automatizar a abordagem.
6.5.5. Verificação das Hipóteses
De acordo com os resultados explicitados nas subseções anteriores, que estão embasados nos
dados colhidos por meio de questionários aplicados aos profissionais que fizeram uso da MoRE-
GSD em um projeto real, rejeita-se H0 em prol de H1, ou seja, prova-se pelo percentual
demonstrado com relação à utilidade e facilidade de uso, e ainda pelo estudo comparativo de um
projeto fazendo uso para outros que não usaram, que a abordagem MoRE-GSD é capaz de guiar
EAR de um projeto por equipes que realizam esta etapa estando geograficamente distribuídas.
6.6. Considerações Finais
O objetivo deste estudo de viabilidade não foi o de encontrar uma resposta definitiva como
validação da MoRE-GSD, e sim construir um corpo de conhecimento abordando a plausibilidade
da continuidade de aprimoramento da abordagem proposta, de modo a poder melhorá-la a fim de
utilizá-la em larga escala na indústria de software, bem como prosseguir sua evolução
academicamente.
115
Como a amostra do estudo foi relativamente pequena, em termos quantitativos, podem-se
associar os seguintes problemas relacionados ao estudo experimental: (1) a ausência de dados
para que testes estatísticos mais eficientes fossem aplicados – teste com distribuição normal ou
não normal; (2) o nível de conhecimento dos participantes foi bastante variável, houve
diversidade dos perfis associados, o que pode induzir respostas discrepantes entre si; e (3) o
desconhecimento da técnica BPMN por dois dos participantes pode ter, de alguma forma,
influenciado no resultado do experimento, mas de maneira sutil, uma vez que esta era apenas
uma etapa da abordagem proposta.
O Capítulo 7 apresenta as conclusões finais deste trabalho.
116
Conclusões
A crescente busca por maior competitividade, e todos os quesitos inerentes a ela, tem levado
cada vez mais as empresas a adotarem o Desenvolvimento Distribuído de Software.
Tentando fazer uso dos benefícios que o DDS traz consigo, empresas têm, a todo tempo,
atravessado fronteiras, formando um mercado global. O desenvolvimento distribuído pode,
também, ser motivado por questões de qualidade, gerenciamento do controle de produção,
domínio de tecnologias empregadas, redução da necessidade de contratações imediatas ou, ainda,
para transferir conhecimento a uma filial.
Essa mudança de paradigma tem causado impacto direto no marketing, na distribuição e
na forma de concepção, de produção, de projeto, de teste e de entrega do software aos clientes
(Sangwan et al., 2006). Segundo Damian e Lanubile (2004), para minimizar esses efeitos e
alcançar níveis mais elevados de produtividade são necessárias novas tecnologias, processos e
métodos compatíveis com as características particulares da abordagem de desenvolvimento
distribuído.
Diante deste cenário, o objetivo deste trabalho foi o de apresentar uma abordagem para
guiar a fase de Elicitação e Análise de Requisitos para equipes que atuam de maneira distribuída,
principalmente no modelo de negócios Offshoring, apoiada pela modelagem dos processos de
negócios.
A abordagem foi desenvolvida com o intuito de apoiar os processos relativos à EAR,
guiando sua execução por passos e diretrizes, a fim de que esta etapa obtenha sucesso ao ser
7
Capítulo
117
realizada de modo distribuído.
Um dos maiores desafios em DDS é a organização dos artefatos e a comunicação entre
equipes, pontos cruciais para que haja uma melhor execução e maior qualidade no trabalho
realizado. A abordagem MoRE-GSD buscou detalhar, por meio de passos e diretrizes, como isso
pode ser realizado e, desta forma, oferecer apoio necessário aos desenvolvedores.
Os profissionais que participaram do estudo de viabilidade, já haviam realizado EAR de
outros projetos de modo distribuído. Porém, sem o uso da abordagem, sempre se fazia necessária
uma comunicação síncrona (comunicador Web ou telefônico) entre, pelo menos, duas equipes
concomitantemente. Isto muitas vezes gerava problemas de sincronização dos trabalhos que
estavam sendo executados.
No entanto, eles puderam constatar que no projeto em que foi usada a abordagem MoRE-
GSD, houve um sequenciamento, uma continuidade na execução de atividades mesmo sem que
fosse estabelecida alguma comunicação síncrona. Esta continuidade tornou-se possível, pois os
membros das equipes tiveram acesso ao BRD parcial, no qual havia a documentação de o que já
havia sido realizado e o que estava pendente.
Portanto, percebe-se um ganho em termos de comunicação e, também, que a continuação
da execução de trabalhos foi facilitada, o que proporciona, pelo menos, as seguintes vantagens
em DDS: facilitar a comunicação e o desenvolvimento follow-de-Sun.
Durante a realização do estudo de viabilidade, tornou-se notória que a concepção da
abordagem está bem centrada no objetivo final, uma vez que o projeto em que abordagem
proposta foi utilizada foi realizado e entregue ao cliente com sucesso.
Ao acompanhar o uso da abordagem MoRE-GSD, pode-se notar que os profissionais que
a estavam usando, mostraram-se satisfeitos e empolgados ao perceberem que ela criou um
processo direcionado e documentado. No entanto, sabe-se também que alguns pontos da MoRE-
GSD podem e devem ser melhorados, ou até adaptados.
Deste modo, pode-se também concluir que estes apontamentos direcionam para a
contribuição acadêmica de que a abordagem proposta contempla, tanto como base para trabalhos
que venham seguir essa linha, bem como outros novos trabalhos que usarão esta como um
arcabouço conceitual.
Para possibilitar a existência de novos experimentos, sejam eles realizados na academia,
ou que empresas usem a MoRE-GSD, está disponibilizado no Apêndice G, um template
exemplificando o BRD, com suas seções, que são os passos da abordagem. É importante
ressaltar que este é uma sugestão de modelo, pois como ainda não há uma ferramenta
implementada para automatizar a abordagem, eventualmente, o BRD pode demandar por
118
adaptações em sua estrutura conforme melhor convir para os envolvidos.
7.1. Dificuldades e Limitações
Dentre as dificuldades e limitações encontradas durante a realização desta dissertação, pode-se
citar como principal que, no âmbito regional, há dificuldade em encontrar empresas que utilizem
essa configuração de desenvolvimento de software e estejam disponíveis a colaborar de modo
ativo no experimento.
Deste modo, não foi possível realizar a validação com uma amostra maior e mais
diversificada de profissionais. Seria interessante também que a validação pudesse ser em mais de
um projeto, para que os resultados colhidos pudessem ser comparados.
Há também, como dificuldades e limitações encontradas, a resistência das empresas em
disponibilizarem-se como laboratório de um estudo experimental. Estas dificuldades vão desde
expor seus projetos à pessoas de fora do seu quadro de colaboradores, até a necessidade de sair
do processo padrão de trabalho para testar um processo novo, em fase experimental.
7.2. Contribuições
Este trabalho tem suas principais contribuições associadas à lacuna existente ao não serem
encontradas, até o momento, propostas que integrem a EAR com a EPN, considerando o DDS.
Neste âmbito, pode-se citar como contribuições deste trabalho:
A caracterização da EAR na indústria de software que atua com
Desenvolvimento Distribuído de Software;
A indicação de ferramentas e técnicas específicas para modelagem de processos
de negócio;
A definição de uma abordagem estruturada por passos e diretrizes, guiando a
execução formal da Elicitação e Análise de Requisitos apoiada pela modelagem
de processos de negócio, oferecendo a todos os envolvidos, artefatos
padronizados que possibilitam a compreensão e identificação de atividades
executadas. Esta abordagem contribui com o DDS em alguns pontos:
o Proporcionar a minimização de tempo na etapa de EAR com o “follow-the-
Sun”;
o Integrar a EAR no DDS com a EPN, a fim de minimizar ambiguidades
geradas inter e entre equipes na fase de Elicitação e Análise de Requisitos;
119
o Acesso à mão de obra qualificada sem perda de qualidade nos processos de
negócio no domínio do cliente;
o Padronização do formato de comunicação entre equipes que atuam em DDS,
especialmente no modelo Offshoring – modelo que contempla países
diferentes e empresas terceirizadas;
Provimento de um arcabouço para futuras pesquisas apoiadas na abordagem
proposta e no material organizado, que envolvem tanto a EAR quanto as outras
etapas do desenvolvimento de software, a Modelagem de Processos de Negócio, e
ainda o DDS;
7.3. Trabalhos Futuros
Com base nas limitações apresentadas e para dar continuidade nas atividades realizadas neste
trabalho, foram identificadas algumas sugestões de trabalhos futuros, os quais estão além do
escopo desta dissertação:
Replicar o estudo de viabilidade para ampliar a aquisição de conhecimento
sobre a aplicação do processo, a credibilidade e o índice de confiabilidade do
mesmo;
Refinar a abordagem proposta por meio da condução de um estudo pautado na
engenharia experimental voltado para a academia, a fim de obter um retorno
direto dessa comunidade com indicativos de melhorias;
Definir métricas para avaliar a produtividade, a comunicação e a qualidade dos
artefatos gerados na abordagem MoRE-GSD;
Estender a MoRE-GSD para contemplar outros elementos de representação
de requisitos, como Diagramas de Classe, a fim de que os usuários possam optar
por qual diagrama utilizar;
Estender a MoRE-GSD para a validação dos requisitos, fazendo uso de
técnicas específicas, com um passo e diretrizes específicas para tal;
O desenvolvimento de uma ferramenta para automatizar a abordagem proposta,
a fim de difundir e melhorar seu uso.
120
Referências
AALST, W.; DESEL, J.; OBERWEIS, A. Business Process Management: models, techniques
and empirical studies. Berlin: Springer, 2000.
ANDRADE, A.; RIBEIRO, A.; BORGES, E.; NEVES, W. Um estudo de aplicação de
modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema. In:
Proceedings VI SIMPROS – Simpósio Internacional de Melhoria de Processos de Software, São
Paulo. pp. 177-188, 2004.
ANTUNES, J.; CAULLIRAUX, H.; NEVES, M. Organização por Processos. SAP Universe,
São Paulo, 1998.
ARANDA, G.; CECHICH, A.; VIZCAINO, A.; PIATTINI, M.; CASTRO-SCHEZ, J.
Cognitive-based rules as a means to select suitable groupware tools. In: Proceedings of the 5th
IEEE International Conference on Cognitive Informatics, Pekin, China. pp.418-423, 2006
AUDY, J.; PRIKLADNICKI, R. Desenvolvimento Distribuído de Software: Desenvolvimento de
Software com Equipes Distribuídas. Porto Alegre: Série Campus-SBC: Campus-Elsevier, 2007.
AZEVEDO JUNIOR, D.; CAMPOS, R. Definição de Requisitos de Software Baseada numa
Arquitetura de Modelagem de Negócios. Revista Produção, v. 18, n. 1, pp. 26-46, 2008
Bal, J., Process analysis tools for process improvement. The TQM Magazine, 1998.
BASILI, V.; ROMBACH, H.; The TAME Project: Towards Improvement-Oriented Software
Environments. In: Proceedings of the IEEE Transactions on Software Engineering, vol.14, pp.
758-773, 1988.
BEGEL, A.; NAGAPPAN, N. Global Software Development: Who does it? In: Proceedings of
the IEEE International Conference on Global Software Engineering (ICGSE 2008), pp. 33-39.
Bangalore, India, 2008.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Campus,
1ª ed., 2002.
121
BELL, J. Re-Engineering Case Study – analysis of business rules and recommendations for
treatment of rules in a relational database environment. Bellevue Golden: US West Information
Technologies Group, 1990.
BHAT, J.; GUPTA, M.; MURTHY, S. Overcoming Requirements Engineering Challenges:
Lessons from Offshore Outsourcing. Proceedings of the IEEE Software, v. 23, n. 5, Set/Out, pp.
38 – 44, 2006
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. Rio de Janeiro:
Campus, 2000.
BRACONI, J; OLIVEIRA, S. Análise e Modelagem de Processos de Negócio – Foco na
Notação BPMN. 1. ed.. São Paulo – SP: Editora Atlas, 2010.
BUBENKO, J.; PERSSON, A.; STIRNA, J. EKD User Guide. Stockholm, Royal Institute of
Technology (KTH), 2001.
CAMEIRA, R.; CAULLIRAUX, H. Engenharia de Processos de Negócios: considerações
metodológicas com vistas à análise e integração de processos. In Proceedings of the 3º Simpósio
de Administração da Produção, Logística e Operações Internacionais. Anais Eletrônicos. São
Paulo: FGV, 2000.
CARMEL, E. Global Software Teams - Collaborating Across Borders and Time Zones. Prentice
Hall, 1999.
CARVALHO, E. Engenharia de Processos de Negócios e a Engenharia de Requisitos: Análise e
Comparações de Abordagens e Métodos de Elicitação de Requisitos de Sistema Orientada por
Processos de Negócio. Dissertação de Mestrado (Mestrado em Engenharia da Produção).
COPPE/UFRJ, 2009.
CHENG, B.; ATLEE, J. Research Directions in Requirements Engineering. In Proceedings of the
29th International Conference on Software Engineering, Washington, Estados Unidos, pp. 285-
303, 2007
CIMOSA. Enterprise Engineering and Integration. 2012. Disponível em:
<http://www.cimosa.de/ >. Acessado em 22/04/2012.
CLERC, V.; LAGO, P.; VLIET, H. Global software development: Are architectural rules the
answer? In Proceedings of the 2nd International Conference on Global Software Engineering,
IEEE Computer Society, pp. 94-104. Germany, 2007.
CRUZ, P. Heurísticas para Identificação de Requisitos de Sistemas de Informações a partir de
Modelos de Processos. Dissertação (Mestrado em Informática). Núcleo de Computação
Eletrônica (NCE), Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2004.
DAMIAN, D.; LANUBILE, F.; MALLARDO, T. The role of asynchronous discussions in
increasing the effectiveness of remote synchronous requirements negotiations. In Proceedings of
the 28th International Conference on Software Engineering, Xangai, China, pp. 917-920, 2006.
122
DAMIAN, D.; ZOWGHI, D. The impact of stakeholders geographical distribution on managing
requirements in a multi-site organization. In Proceedings of the IEEE Joint International
Conference on Requirements Engineering, California, Estados Unidos, pp. 319- 328, 2002
DAVENPORT, T. Reengenharia de Processos. Rio de Janeiro: Campus, 1994.
DAVENPORT, T.; PRUSAK, L. Conhecimento Empresarial. Rio de Janeiro: Campus, 1998.
De La VARA, J.; SÁNCHEZ, J.; PASTOR, O. Business Process Modelling and Purpose Analysis
for Requirements Analysis of Information Systems. In Proceedings of the CAiSE - 20th
International Conference on Advanced Information Systems Engineering. pp. 213 – 227., 2008.
DEMIRORS, O.; GENCEL, C.; TARHAN, A. Utilizing Business Process Models for
Requirements Elicitation. In Proceedings of the 29th Euromicro Conference. Proceedings. pp.
409-412. Turquia: IEEE Computer Society Press, 2003.
DIAS, F.; MORGADO, G.; OSCAR, P.; SILVEIRA, D.; ALENCAR, A.; LIMA, P.; SCHMITZ,
E. Uma Abordagem para a Transformação Automática do Modelo de Negócio em Modelo de
Requisitos. In Proceedings of the Workshop em Engenharia de Requisitos (WER06). Anais
Eletrônicos. Rio de Janeiro: PUC-Rio. pp. 51-60, 2006.
DIAZ, O.; ITURRIOZ, J.; PIATTINI, M.G. Promoting Business Policies in Objectoriented
Methods. The Journal of Systems and Software, v. 41, pp. 105-115, 1998.
EBLING, T. mRED – Um Método Para A Engenharia De Requisitos Em Ambientes De
Desenvolvimento Distribuído De Software. Dissertação de Mestrado (Mestrado em Ciência da
Computação). Pontifícia Universidade Católica – Rio Grande do Sul (PUCRS). Porto Alegre,
2009.
ERIKSSON, H.; PENKER, M. Business Modeling with UML: business patterns at work. New
York: Wiley Publishers, 2000.
Ghezzi C.; Jazayeri M.; Mandrioli D. Fundamentals of Software Engineering. Prentice-Hall
International Editions, ISBN 0-13-818204-3, 1991.
GIL, A. C. Métodos e Técnicas de Pesquisa Social. São Paulo: Atlas, 1999.
GOTTESDIENER, E. Business Rules Show Power, Promise. Application Development Trends,
v. 4, n.3, 1997.
GROVER, V.; KETTINGER W.R. Process think: winning perspectives for business change in
the information age. Inglaterra: Idea Group, 2000.
HAY, D.; HEALY, K. Defining Business Rules: what are they really? Technical Report Rev
1.3,The Business Rules Group, 2000.
HERBSLEB, J. Global Software Engineering: The Future of Socio-technical Coordination. In
Proceedings of the 29th International Conference on Software Engineering, Mineápolis, Estados
Unidos, pp. 188-198, 2007.
123
HERBSLEB, J.; MOCKUS, A.; FINHOLT, T.; GRINTER, R. Distance, dependencies, and delay
in a global collaboration. In Proceedings of the 2000 ACM Conference on Computer Supported
Cooperative Work (CSCW ’00), USA. pp.209, 2000.
HOLMSTROM, H.; CONCHUIR, E. O.; AGERFALK, P. J.; FITZGERALD, B. Global software
development challenges: A case study on temporal, geographical and socio-cultural distance.In
Proceedings of the IEEE – International conference on Global Software Engineering
Proceedings, Washington, DC, USA: IEEE Computer Society. pp. 3–11, 2006.
HUZITA, E.; SILVA, C.; WIESE, I.; TAIT, T.; QUINAIA, M.; SCHIAVONE, F. Um conjunto de
soluções para apoiar o desenvolvimento distribuído de software. In Proceedings of the II
Workshop de Desenvolvimento Distribuído de Software, Campinas, SP. pp. 101 – 110, 2008.
IIBA – International Institute of Business Analysis. Business Analysis Body of Knowledge –
BABOK®, 2011.
KARDASIS P.; LOUCOPOULOS, P. A Roadmap for the Elicitation of Business Rules
in Information Systems Projects. Business Process Management Journal, v. 11, n. 4, pp.316–
348, 2005.
KNIGHT, D. Elicitação de Requisitos de Software a partir do Modelo de Negócio. Dissertação
(Mestrado em Informática). Núcleo de Computação Eletrônica (NCE), Universidade Federal do
Rio de Janeiro. Rio de Janeiro, 2004.
KOSANKE, K. CIMOSA – Overview and Status. Computers in Industry - Vol. 21, Nr. 2, 1995.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: processes and techniques. New
York: John Wiley & Sons, 1998.
LARMAN, C. Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a
Objeto. Porto Alegre: Bookman, 2000.
MAFRA, S. N.; TRAVASSOS, G. H. Estudos Primários e Secundários apoiando a busca por
Evidência na Engenharia de Software. Rio de Janeiro: Programa de Engenharia de Sistemas e
Computação. RT-ES 687/06, 2006.
MARSHALL, C. Enterprise Modeling with UML. Reading (MA): Addison-Wesley, 2000.
MARTINS, G. A. Sobre confiabilidade e validade. Revista Brasileira de Gestão de Negócios.
São Paulo, v. 8, n. 20, p. 1-12, 2006.
MAYER, R. Information Integration for Concurrent Engineering (IICE). Technical Report.
Armstrong Laboratory Logistics Research Division Wright-Patterson Air Force Base, Ohio
(EUA), 1995. Disponível em: <http://www.idef.com/pdf/Idef3_fn.pdf >. Acesso em: 14/01/2012.
MONSALVE, C.; APRIL, A.; ABRAN, A. Requirements Elicitation Using BPM Notations:
Focusing on the Strategic Level Representation. In Proceedings of the 10th
International
Conference on Applied Computer and Applied Computational Science (ACACOS), 2011, Venice,
Italy, pp. 235-241., 2011.
124
MONTGOMERY, D. C.; RUNGER, G. C. Estatística aplicada e probabilidade para
engenheiros. 4 ed. Norwell, MA, USA: LTC, 2009.
NUSEIBEH, B.; EASTERBROOK, S. Requirements Engineering: A Roadmap. In Proceedings
of the Conference on The Future of Software Engineering, Limerick, Irlanda, pp. 35 - 46, 2000.
O’NEILL, P., Business Process Reengineering: A review of recent literature. Technovation,
1999.
OMG – Object Management Group. Guide Version 1.0.1., 2003. Disponível em:
<http://www.omg.org/docs/omg/03-06-01.pdf>. Acesso em 07/02/2012.
PÁDUA, S. I. D. O potencial das redes de Petri em modelagem e análise de processos de
negócios. Revista Gestão e Produção, São Carlos, v. 11, p. 1-11, 2004.
PIDD, M. Just Modeling Through: a rough guide to modeling. Lancaster (UK): Department of
Management Science - The Management School – Lancaster University, 1999.
PRESSMAN R. Engenharia de Software. 6ª edição. São Paulo, Editora McGraw-Hill, 2006.
PRIKLADNICKI, R.; AUDY, J.. MuNDDoS: Um Modelo de Referência para Desenvolvimento
Distribuído de Software. In Proceedings of the 18 SBES - Simpósio Brasileiro de Engenharia de
Software, 2004, Brasília, 2004.
PRIKLADNICKI, R.; AUDY, J. L.N. Uma Análise Comparativa de práticas de Desenvolvimento
Distribuído de Software no Brasil e no exterior. In Proceedings of the XX Simpósio Brasileiro de
Engenharia de Software, Florianópolis, Brasil, 2006, pp. 255-270, 2006.
PROFORMA. Integrating Business Processes, Workflows and Object Models via Use Cases.
White Paper. 1998. Disponível em:
<http://www.proformacorp.com/downloads/whitepapers.asp>. Acesso em: 14/03/2011.
RATIONAL. Business Modeling with the UML and Rational Suite Analyst Studio. White Paper.
2000. Disponível em: <http://www-01.ibm.com/software/rational/>. Acesso em: 15/03/2011.
RATIONAL Business Modeling with UML and Rational Suite AnalystStudio. White paper, 2001.
Disponível em: <http://www.rational.com > Acesso em: 22/04/2011.
REISIG, W. Petri nets: an introduction. Springer-Verlag, Berlin, 1985.
ROSS, R.G. The Business Rule Book: classifying, defining and modeling rules. Texas: Data Base
Newsletter, 1997.
ROSS, R.; LAM, G. The BRS Business Rule Methodology, Business Rule Solutions, 2000.
SANGWAN, R.; BASS, M.; MULLICK, N.; PAULISH, D. J.; KAZMEIER, J. Global Software
Development Handbook. Boston: Auerbach Series on Applied Software Engineering Series,
2006.
125
SANTANDER, V. F. A., CASTRO, J. F. B. Desenvolvendo Use Cases a partir de Modelagem
Organizacional. In Proceedings of the Workshop em Engenharia de Requisitos (WER06). Anais.
pp. 158-180. Rio de Janeiro: PUC-Rio, 2000. Disponível em: <http://wer.inf.puc-
rio.br/WERpapers/artigos/artigos_WER00/santander.pdf>. Acesso em: 17/03/2011.
SANTOS, R. Engenharia de Processos: análise do referencial teórico-conceitual, instrumentos,
aplicações e casos. Dissertação (Mestrado em Engenharia de Produção) COPPE, Universidade
Federal do Rio de Janeiro, Rio de Janeiro, 2002.
SANTOS, R.; CAMEIRA, R. Engenharia de Processos de Negócios: aplicações e metodologias.
In Proceedings of the XXII Encontro Nacional de Engenharia de Produção (ENEGEP). Anais
Eletrônicos. Curitiba: ABEPRO, 2002.
SANTOS, R. P. C. As Tarefas para Gestão de Processos. Tese (Doutorado em Engenharia de
Produção). COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2007.
SCHEER, W. ARIS Business Process Frameworks, 2 ed. Berlin: Springer Verlag, 1998.
SENGUPTA, B.; SINHA, V.; CHANDRA, S. A Research Agenda for Distributed Software
Development. In Proceedings of the 28th International Conference on Software Engineering,
Xangai, Chin. pp. 731-740, 2006.
SHAO, J., POUND, C. J. Extracting Business Rules from Information Systems. BT Technology
Journal, v.17, n.4, pp.179-186, 1999.
SHINGO, S. O Sistema Toyota de Produção. Porto Alegre: Bookman, 1996.
SILVEIRA, D. S.; CRUZ, P. O.; SCHMITZ, E. A. Heurísticas para Extração dos Casos de Uso
de Negócio a Partir da Modelagem de Processos. In: XI Congresso Latino Ibero-Americano de
Investigación de Operaciones (CLAIO 2002). Concepción (Chile), 2002.
SOMMERVILLE, I. Engenharia de Software. Reading (MA): Addison-Wesley, 2007.
THIOLLENT, M. Pesquisa-Ação nas Organizações. Ed. Atlas. São Paulo, 1997.
TRAVASSOS, G. H. Introdução à engenharia de software experimental. Relatório Técnico ES-
590/02, Programa de Engenharia de Sistemas e Computação, COPPE/UFRJ, 2002.
TYNDALE-BISCOE, S. Business Modelling for Component Systems with UML. In
Proceedings of the Sixth International Enterprise Distributed Object Computing Conference.
Lausanne (Switzerland): EPFL, 17-20 sep. 2002. Disponível em:
<http://www.opengroup.org/combine/information/EDOC_Paper.pdf>. Acesso em: 15/03/2011.
VERNADAT, F. B. Enterprise Modeling and Integration: principles and applications. 1 ed.
London: Chapman & Hall, 1996
VICENTE, L. S. S. Modelagem de Processos e Linguagem de Modelagem Unificada: uma
análise crítica. Dissertação (Mestrado em Engenharia de Produção) COPPE, Universidade
Federal do Rio de Janeiro, Rio de Janeiro, 2004.
126
VIEIRA, S. ; SANTOS, D. V. ; NASCIMENTO, R. P. C. ; CONTE, T. U. . Avaliando uma
Técnica para Extrair Requisitos a partir de Diagramas de Processos de Negócios através de
Estudos Experimentais. In Proceedings of the XXXVIII Conferencia Latinoamericana en
Informática (CLEI 2012,. Anais do XXXVIII Conferencia Latinoamericana en Informática,
Medellin, 2012.
VILLANUEVA, I. Elicitación de Requisitos en Sistemas de Gestión Orientados a Procesos. In
Proceedings of the VIII Workshop on Requirements Engineering (WER05). pp. 144-157. Porto:
Universidade do Porto, 2005.
VON HALLE, B. Business Rules Applied. New York: John Wiley & Sons, 2002.
XAVIER, L.; ALENCAR, F.; CASTRO, J.; PIMENTEL, J. Integração de Requisitos
Não-Funcionais a Processos de Negócio: Integrando BPMN e NFR, In Proceedings of the 13th
Workshop em Engenharia de Requisitos (WER), Cuenca, Ecuador, pp. 29-40, 2010.
ZANIOLO, C. et al. Advanced Database Systems, San Francisco: Morgan Kaufmann Publishers,
1997.
WHITE, S. A. Introduction to BPMN. IBM Corporation, 2004. Disponível em
<http://www.bpmn.org>. Acesso em 17/09/2012.
YIN, R. K. Estudo de Caso: Planejamento e Métodos. 3. ed., Porto Alegre, Bookman, 2005.
127
Apêndice A
Termo de Consentimento – CT01
EXPERIMENTO: Este estudo experimental visa avaliar a abordagem MoRE-GSD, cujo
propósito é apoiar a elicitação e análise de requisitos para equipes que atuam com o
desenvolvimento distribuído de software.
IDADE: Declaro ter mais de 18 anos e concordo em participar de um estudo experimental
conduzido por Elder Elisandro Schemberger, aluno regular do programa de Mestrado em Ciência
da Computação, na Universidade Estadual de Maringá.
PROCEDIMENTO: Este estudo experimental compreende o entendimento da abordagem
MoRE-GSD por meio de um memorial descritivo, seguido do uso da abordagem e
preenchimento de questionário sobre a percepção da mesma. Entendo que, após a finalização do
experimento, os questionários que respondi serão estudados e analisados visando entender, sob
os pontos de vista estudados, a utilidade e facilidade de uso da abordagem proposta.
CONFIDENCIALIDADE: Todas as informações obtidas neste estudo experimental são
confidenciais. Assim, meu nome não será divulgado a terceiros ou citado em documentos, tais
como a própria dissertação, publicações ou quaisquer outros. Da mesma forma, me comprometo
a não comunicar os meus resultados enquanto o experimento não terminar e os resultados gerais
não forem publicados para uso da comunidade. Também me comprometo em manter sigilo das
técnicas, documentos e demais informações que fizerem parte desse experimento.
BENEFÍCIOS E LIBERDADE DE DESISTÊNCIA: Entendo que os benefícios que receberei
deste estudo são limitados ao conhecimento e validação da abordagem MoRE-GSD. Apenas
após sua publicação formal poderei fazer uso de parte, ou de toda a abordagem de modo
explícito. Entendo que sou livre para realizar perguntas a qualquer momento, ou solicitar que
qualquer informação relacionada à minha pessoa não seja incluída nesse estudo experimental.
Entendo que participo por livre e espontânea vontade com o intuito de contribuir para o avanço
da Engenharia de Software, tanto no contexto acadêmico quanto na indústria.
128
PESQUISADOR RESPONSÁVEL
Elder Elisandro Schemberger.
Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá.
PROFESSOR RESPONSÁVEL
Profa. Dra. Elisa Hatsue Moriya Huzita (Universidade Estadual de Maringá).
Nome:
e-mail:
Empresa:
Assinatura
Data:
129
Apêndice B
Caracterização da Empresa Participante
Questionário Q01
1. Nome da Empresa:
2. País de Localização da Empresa:
Brasil EUA Outro(s) – Qual(is)? [______________________________________]
3. Tempo de Existência da Empresa:
[__________] anos e [__________] meses.
4. Nicho(s) de Atuação da Empresa:
5. Número Total de Funcionários da Empresa:
[__________] funcionários.
6. Quantidade de Funcionários que Atuam com Elicitação e Análise de Requisitos:
[__________] funcionários.
7. Quantidade de Funcionários que Atuam com Modelagem de Processos de Negócios:
[__________] funcionários.
130
Apêndice C
Caracterização dos Participantes
Questionário Q02
1. Formação
Informe o maior grau de escolaridade.
Superior Incompleto
Superior Completo
Pós-Graduação Incompleta – lato sensu (Especialização, MBA)
Pós-Graduação Completa – lato sensu (Especialização, MBA)
Pós-Graduação Incompleta – stricto sensu (Mestrado, Doutorado)
Pós-Graduação Completa – stricto sensu (Mestrado, Doutorado)
2. Possui experiência profissional em desenvolvimento de software? Não
Sim Tempo: [___________] anos e [__________] meses
3. Possui experiência profissional em desenvolvimento distribuído de software? Não
Sim Tempo: [___________] anos e [__________] meses
4. Possui experiência em modelagem de processos de negócios? Não
Sim Tempo: [___________] anos e [__________] meses
5. Possui experiência profissional na etapa de elicitação e análise de requisitos de
software? Não
Sim Tempo: [___________] anos e [__________] meses
131
Apêndice D
Viabilidade da Abordagem MoRE-GSD
Questionário Q03
1ª Parte – Utilidade da MoRE-GSD
1. O conjunto de passos e diretrizes guiou a elicitação e análise de requisitos no ambiente
distribuído?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
2. A continuidade da elicitação e análise de requisitos por uma equipe iniciada por outra
equipe foi possível?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
3. As estórias contribuíram para diminuir possíveis ambiguidades de uma atividade?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
132
4. Os elementos gráficos do BPMN relacionados às regras de negócio melhoraram o nível
de detalhamento requerido para a elicitação e análise dos requisitos?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
5. As cláusulas WHO, WHAT e WHY foram claras em sua definição no passo em que
foram aplicadas?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
6. O conjunto de passos e diretrizes atende às necessidades de organização e comunicação
que o desenvolvimento distribuído de software requer?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
7. Conjunto de artefatos atende às necessidades de organização e comunicação que o
desenvolvimento distribuído de software requer?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
2ª Parte – Facilidade de Uso da MoRE-GSD
8. A nomenclatura comum a todas as equipes possibilitou entender a dependência das
atividades e artefatos?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
9. O modo de identificar as equipes possibilitou saber quem desenvolveu qual artefato?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
133
10. O modo de identificar passos e diretrizes possibilitou acompanhar a sequência da
abordagem?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
11. Seguir os passos e diretrizes foi fácil?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
12. O uso da técnica BPMN foi acessível a todos?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
13. Os passos e diretrizes foram descritos de fora clara e compreensível?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
14. Foi fácil lembrar os passos e diretrizes durante o uso da abordagem MoRE-GSD?
Sim, em todas as vezes.
Sim, na maioria das vezes.
Não, em boa parte das vezes.
Não, em nenhuma das vezes.
Sem Resposta.
134
Apêndice E
Análise Comparativa
Questionário Q04
1. Comparando a EAR realizada com e sem o uso da abordagem MoRE-GSD em outros
projetos Offshoring, responda as questões abaixo.
a) No projeto que foi utilizada a MoRE-GSD, notou-se o follow-the-Sun na EAR tornando
sua execução de certa forma mais rápida?
Sim.
Não.
Sem Resposta.
b) Com os artefatos gerados no uso da abordagem MoRE-GSD, a EAR foi melhor
organizada em termos de comunicação?
Sim.
Não.
Sem Resposta.
c) Os artefatos da abordagem MoRE-GSD proporcionaram segurança para a comunicação
fluir bem entre as equipes?
Sim.
Não.
Sem Resposta.
d) Qual foi o aproveitamento dos requisitos elicitados com o uso da MoRE-GSD para
implementação?
0% a 35%
35% a 70%
70% a 85%
85% a 100%
e) Você adotaria a abordagem MoRE-GSD em sua empresa para projetos DDS?
Sim, do formato que ela se encontra.
Sim, mas ela precisa de melhorias.
Não adotaria.
f) Deixe sua sugestão de melhorias para a abordagem MoRE-GSD.
135
Apêndice F
Memorial Descritivo – Abordagem MoRE-GSD
Estudo de Viabilidade
MoRE-GSD – Uma Abordagem para Elicitação e Análise de Requisitos a Partir das Regras de Negócio no Contexto de DDS
Dissertação de Mestrado
Elder Elisandro Schemberger
Objetivo do estudo
Analisar a viabilidade da abordagem MoRE-GSD, abordagem proposta para oferecer apoio à
Elicitação e Análise de Requisitos com o uso da Modelagem de Processos de Negócio para
equipes que trabalham com o Desenvolvimento Distribuído de Software, com o propósito de
adquirir conhecimento sobre a aplicação da mesma.
A abordagem proposta
Com base em uma revisão de literatura e visitas a empresas que atuam com desenvolvimento
distribuído de software (DDS), foi possível evidenciar que há algumas lacunas no DDS no que se
refere ao processo de elicitação e análise de requisitos (EAR). Desse modo, foram definidos
passos e diretrizes, com artefatos, para que a etapa de EAR possa ser executada de modo
eficiente e eficaz. A essa abordagem deu-se o nome de MoRE-GSD, sigla para Modeling
Business Process for Requirements Elicitation in Global Software Development.
Ponto de atuação
A MoRE-GSD direciona as equipes geograficamente distribuídas, por meio de passos e
diretrizes, na realização da EAR de modo integrado e contínuo entre estas equipes. Trata apenas
da EAR, não sendo tratada a negociação inicial com o cliente, nem a metodologia da posterior
implementação. As equipes não tem contato com o cliente, e sim apenas com o Gerente de
Projeto/Analista de Negócio que realizou a descrição das atividades com o cliente. Este Gerente
136
de Projeto/Analista de Negócio repassa/distribui as atividades entre as equipes e então inicia-se o
uso da abordagem MoRE-GSD por todas equipes envolvidas.
Artefatos gerados
Ao final do uso da MoRE-GSD estará disponível o BRD (Business Requirement Document),
contendo toda descrição passo a passo da abordagem. Todo o conteúdo deste documento
(incluindo a modelagem de processos de negócio) deve estar em inglês.
Passos e Diretrizes
A MoRE-GSD é estruturada em passos, cada qual com suas respectivas diretrizes de aplicação.
A nomenclatura adotada é S (de Step) seguido do número do passo, concatenada com a letra G
(de Guideline) e o número da diretriz. A cada passo artefatos são gerados, e servem como
entrada para a diretriz/passo seguinte. Cada artefato gerado deve ser inserido no BRD (Business
Requirement Document), seja de forma textual (em inglês) ou com inserção de figura. Cada
passo representa uma seção do BRD, e nestas seções devem estar documentados a sequencia
após cada diretriz executada. Para que a abordagem MoRE-GSD tenha efetividade, os passos
abaixo devem ser executados na ordem em que são apresentados.
Passo 1 – Aplicação do Conceito de Processos de Negócios
S1G1
Cada atividade recebida do Gerente de Projetos deve ser relativa a uma única ação.
Caso uma atividade tenha detalhamento em subatividades, considere apenas as
subatividades representadas no mesmo contexto principal. Para as outras, devem ser
geradas novas atividades. A “contexto principal” entende-se como sendo as
subatividades necessárias para que uma atividade possa ser iniciada e finalizada.
S1G2
Para cada atividade deve-se verificar se ela pode se tornar uma ação do software de
modo a separar as entradas de um processo em funcionais (por exemplo, lançar
novo produto) e não funcionais (por exemplo, deseja-se rapidez no lançamento).
Interessarão, neste ínterim, apenas as funcionais;
S1G3 Deve-se verificar se as atividades selecionadas possuem apenas uma única entrada
de dados. Caso seja identificada mais de uma, deve-se retornar a S1G1.
S1G4
Deve-se verificar se as saídas correspondem ao resultado do processo, sendo um
ponto de partida para o Passo 2 da MoRE-GSD. Caso não sejam, deve-se voltar a
S1G1 e verificar se esta não é subatividade de uma atividade.
S1G5 Deve-se identificar qual equipe está realizando a elicitação e análise de requisitos de
cada processo. Essa identificação pode ser realizada com um nome para a Equipe.
S1G6
É gerado um número inteiro que serve como identificador para o processo definido,
a fim de associar tal processo aos demais artefatos gerados. Pode ser gerado um
número sequencial, de maneira manual.
Passo 2 – Documentação e Nível de Detalhamento das Regras de Negócios
S2G1
Deve-se associar cada regra de negócio gerada no Passo 2 a um processo gerado ao
final do Passo 1. Isso é feito associando o identificador (número inteiro) gerado em
S1G6, com um identificador (número inteiro) nesta diretriz.
S2G2
Cria-se uma estória de cada processo, na visão do cliente, em texto estruturado,
seguindo as seguintes cláusulas:
iv. WHO?
137
v. WHAT?
vi. WHY?
S2G3
Por meio da cláusula WHAT, deve-se separar o que indica ser requisito funcional
(necessário no software como funcionalidade) e o que indica ser requisito não
funcional (característica da funcionalidade), e comparar com a separação obtida em
S1G2. Se não houver divergências, segue-se para S2G4. Se houver divergências,
retorna-se para S1G2.
S2G4 Documentar no BRD o que foi indicado como possível funcionalidade do software,
e o que foi indicado como possível requisito não funcional.
S2G5
A cláusula WHAT de S2G2 deve ter apenas uma oração – sujeito
simples/composto, associado a um único verbo.
Caso tenha mais de uma oração na cláusula WHAT, a regra de negócio deve ser
dividida em duas ou mais estórias (Retornando para S2G1), até que tenha apenas
uma oração associada.
Quando tiver apenas uma oração, o nível de detalhamento está satisfatório.
Passo 3 – Modelagem dos Processos de Negócios
S3G1
A técnica padrão para modelagem dos processos de negócio entre as equipes
distribuídas é BPMN. A ferramenta para automatizar a modelagem é de livre
escolha, de acordo com a preferencia de cada profissional (o artefato gerado é o
mesmo);
S3G2 Deve-se associar de maneira explícita cada processo modelado às suas respectivas
regras de negócio em S2G1;
S3G3
Cada objeto representado no modelo deve ter um propósito. Deste modo, um
modelo não deve conter mais informações do que o necessário (Novamente entra a
experiência de cada equipe, para definir o que é ou não relevante);
S3G4 Os elementos gráficos gerados pela modelagem BPMN devem estar relacionados às
regras de negócio em S2G4, havendo um processo com início e fim para cada regra;
S3G5
Caso exista necessidade e representar uma interrupção temporal, por dependência de
outras estórias ou outro motivo qualquer, uma atividade passiva deverá ser
representada por meio de um estado no modelo BPMN.
Passo 4 – Representação dos Requisitos de Sistema
S4G1
Geração dos Casos de Uso Simplificado (leia-se: Casos de Uso adaptados para a
MoRE-GSD), segundo:
Em S2G2, quem estava na clausula WHO, representa um ator do Caso de Uso;
O que foi separado como requisito funcional na clausula WHAT de S2G2
torna-se funcionalidade;
S4G2 Deve-se associar cada Caso de Uso Simplificado a uma raia na modelagem BPMN
realizada do processo de negócio, e a estória escrita.
S4G3
Cada caso de uso é relacionado a uma única atividade do processo de negócio,
seguindo a diretriz S2G5, que trata do nível de detalhamento dos processos de
negócio.
S4G4
Conclusão do BRD, que deve conter ao final, além das indicações já descritas nos
passos anteriores, todas escritas em inglês:
Descrição do negócio a ser modelado;
Enumeração dos processos e atividades considerados no desenvolvimento do
sistema;
Listagem das necessidades de negócio existentes em cada processo;
Relação das funcionalidades e restrições do sistema;
138
Concluindo
Executados os passos com suas diretrizes (que serão realizados em sequencia), a EAR estará
realizada de modo padronizado. A MoRE-GSD proporciona a realização contínua da EAR pelas
equipes distribuídas, haja vista que trabalha de forma organizada e documentada,
proporcionando ao projeto os benefícios que o desenvolvimento distribuído de software traz.
139
Apêndice G
Template – BRD
Project: Project Name
Client: Client Name
Business to be modeled: summary description
Teams: Team Name and Country
Section 1
Date: MM/DD/AAAA
Time: HH:MM
Team: Team Name
Team leader: Name
Activity 1
Team: Brazil
ID:001
Guideline Status
S1G1 Detailing the execution
S1G2 Detailing the execution
S1G3 Detailing the execution
S1G4 Detailing the execution
Status [______________________________________________________________________]
140
Section 2
Date: MM/DD/AAAA
Time: HH:MM
Team: Team Name
Team leader: Name
Team: Brazil
ID:001
Business Process: 001
Guideline Status
S2G2
- WHO:
- WHAT:
- WHY:
S2G3 Detailing the execution
S2G4 Detailing the execution
S2G5 Satisfactory level of detail: Yes [ ] No [ ]
Status [______________________________________________________________________]
Section 3
Date: MM/DD/AAAA
Time: HH:MM
Team: Team Name
Team leader: Name
Team: Brazil
ID:001
Business Process: 001
Guideline Status
S3G2 Associate the modeled process to business rules
S3G3 Guideline ok? Yes [ ] No [ ]
S3G4 Guideline ok? Yes [ ] No [ ]
S3G5 Guideline ok? Yes [ ] No [ ]
Status [______________________________________________________________________]
141
Section 4
Date: MM/DD/AAAA
Time: HH:MM
Team: Team Name
Team leader: Name
Team: Brazil
ID:001
Business Process: 001
Guideline Status
S4G1
Attaching diagram Use Case
WHO (S2G2): Actor
WHAT (S2G2): Use Case
S4G2 Guideline ok? Yes [ ] No [ ]
S4G3 Guideline ok? Yes [ ] No [ ]
Status [______________________________________________________________________]
Closing BRD
List of features (S4G1) and restrictions (WHY:S2G2).
