Você está na página 1de 15

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317533053

Design Science Research em Sistemas de Informação

Article · June 2011

CITATIONS READS
0 114

1 author:

Estrela Cruz
Instituto Politécnico de Viana do Castelo
13 PUBLICATIONS   69 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Derivation of Data-Driven Software Models from Business Process Representations View project

All content following this page was uploaded by Estrela Cruz on 11 June 2017.

The user has requested enhancement of the downloaded file.


Design Science Research em Sistemas de Informação
Estrela Ferreira Cruz
Universidade do Minho
16 de Junho de 2011

Resumo
O aumento da dimensão, complexidade e exigências impostas às orga-
nizações tem impulsionado o aumento do número de organizações que optam
pela gestão do processo de negócio (BPM - Business Process Management), ou
seja, pela modelação, medição e optimização dos seus processos de negócio,
ficando assim mais aptas à implementação das mudanças necessárias. Ide-
almente a análise e a modelação feita a nı́vel do processo de negócio devia
servir de base à modelação das aplicações de software (SW) que suportam o
negócio. Esta seria uma forma de garantir que os requisitos das aplicações
de SW correspondiam às reais necessidades do negócio e que, sempre que o
negócio sofria mudanças, estas eram facilmente propagadas para as aplicações
de SW que lhe dão suporte.
Dentro das metodologias de investigação usadas nesta àrea surgiu, recen-
temente, o método Design Science Research (DSR). Este método foca-se no
desenvolvimento de artefactos que alargam as actuais fronteiras das Tecno-
logias de Informação de forma a melhorar a performance dos negócios e das
organizações.
Neste artigo faz-se um estudo sobre o método DSR, depois de uma breve
abordagem à área do tema em investigação. No final fala-se sobre a estratégia
a usar na investigação, recorrendo ao método DSR.

Palavras chave: Gestão do Processo de Negócio (BPM); Modelação do Pro-


cesso de Negócio; Design Science Research (DSR);

1 Introdução
A crescente globalização dos mercados e o constante aumento da competitividade
entre as organizações, obriga a que as estas se mantenham em constante mudança
de forma a adaptar-se a novas situações. Para que as organizações se consigam
agilizar precisam de se conhecer a si próprias por forma a aumentar a qualidade dos
seu produtos, ou a eficiência dos seus serviços, e assim aumentar os beneficios para
os seus stakeholders1 . Por esse motivo, muitas organizações adoptam uma gestão
do processo de negócio (BPM - Business Process Management).
Um processo de negócio é a combinação do conjunto de actividades, dentro de
uma empresa, com uma estrutura que descreve a sua ordem lógica e dependências,
cujo objectivo é produzir um resultado desejado [Aguilar-Savén2004]. A gestão do
processo de negócio (BPM) dá suporte aos processos de negócios utilizando métodos,
técnicas e software para projectar, aprovar, controlar e analisar processos operaci-
onais envolvendo pessoas, organizações, aplicações, documentos e outras fontes de
informação [ter Hofstede et al.2003].
1 Parte interessada ou interveniente no processo

1
Por outro lado, o BPM e a constante mudança que impõe aos processos de
negócio de uma organização obrigam, também, à constante mudança do software
que suporta esses processos de negócio. De acordo com Mili et al. [Mili et al.2003],
investigadores e profissionais na área de gestão de sistemas de informação há muito
reconhecem que compreender o processo de negócio é a chave para identificar as
necessidades dos utilizadores da aplicação informática que o suporta. Para compre-
ender o que um sistema informático deve fazer, é necessário colocá-lo no contexto
do processo de negócio ao qual ele dá apoio. Idealmente, e num contexto de desen-
volvimento de software baseado em modelos, alguns aspectos do modelo do software
deveriam, então, poder ser derivados de aspectos existentes no modelo de processo
de negócio de uma organização.
O método “Design Science Research”(DSR) é um método de investigação muito
recente, com apenas algums décadas. Este método é normalmente aplicado no
desenho e desenvolvimento de artefactos com o objectivo de resolver problemas es-
pecı́ficos das organizações, dando possibilidade a estas de, directa ou indirectamente,
aumentarem os seus lucros. Assim, uma investigação que usa o método DSR exige
a criação intencional de um artefacto inovador para a resolução de um problema
especı́fico de um determinado domı́nio [Hevner et al.2004]. Para Hevner et al., o
método de DSR é basicamente um processo de resolução de problemas cujo princı́pio
é: “O conhecimento e a compreensão do desenho de um problema e da sua solução
são adquiridos na construção e aplicação de um artefacto”[Hevner et al.2004].
O principal objectivo deste trabalho é, depois de uma explicação sobre o tema
a investigar, fazer um levantamento bibliográfico sobre o método de investigação
DS e justificar a razão pela qual este método é considerado o mais adequado à
investigação em curso.
Assim, a secção seguinte introduz alguns termos e conceitos relacionados com
BPM. Na secção 3 é dada uma visão geral sobre as actuais abordagens à derivação
de requisitos ou de elementos de modelos iniciais de software, a partir de modelos de
processos de negócio, introduzindo-se assim o tema em estudo. Na secção 4 faz-se
uma apresentação do método DSR e justifica-se a razão pela qual se considera este
método de investigação o mais adequado a usar no projecto de doutoramento no
âmbito do Programa Doutoral em Tecnologias e Sistemas de Informação (PDTSI).
Por fim, são apresentadas algumas conclusões e algumas ideias para trabalho futuro.

2 Gestão do Processo de Negócio


Nesta secção são apresentados alguns conceitos relacionados com a gestão e mode-
lação do processo de negócio.
Para White e Miers, o BPM (Business Process Management) é uma forma de
pensar, uma filosofia de gestão centrada numa melhoria continua dos processos
das organizações [White and Miers2008]. No mesmo sentido, em [ORACLE2011], o
BPM é definido como “um modelo de gestão de melhoria contı́nua, que deve estar
sempre alinhado com os objetivos estratégicos do negócio e, que por este motivo,
acaba por cruzar os diferentes departamentos, áreas e unidades de negócio de toda
uma organização”.
A gestão do processo de negócio inclui métodos, técnicas e ferramentas para
apoio aos processos de negócio, ou seja, o BPM dá suporte aos processos de negócios
utilizando métodos, técnicas e software para projectar, aprovar, controlar e analisar
processos operacionais envolvendo humanos, organizações, aplicações, documentos
e outras fontes de informação [ter Hofstede et al.2003, Ko2009].
Um processo é a especificação de uma ordem das actividades de trabalho ao
longo do tempo e dos lugares, com inı́cio e fim, e inputs e outputs, claramente
identificados[Ko2009]. No contexto de desenvolvimento de software, um processo

2
é a forma como as actividades estão organizadas, geridas, medidas, suportadas e
melhoradas para atingir um objectivo [Estublier2006]. No contexto do negócio, um
processo de negócio é o conjunto de actividades, relacionadas, desenvolvidas pela or-
ganização para a criação dos seus produtos ou serviços [Hammer and Champy2001].
Várias linguagens e ferramentas têm sido sugeridas, e usadas, para a modelação
do processo de negócio, a maioria baseada em linguagens com notações gráficas, tais
como diagrama de fluxo, diagramas de transição de estado, redes de Petri, Unified
Modeling Language (UML), Little-JIL, entre outras. Algumas linguagens foram
criadas de raiz, com o objectivo de modelar o processo de negócio como BPMN ou
BPEL.
Um modelo de processo de negócios é uma descrição abstracta do fluxo de um ou
mais processos de negócios com actividades e recursos necessários. Os recursos po-
dem ser pessoas, equipamentos, aplicações informáticas, etc. [Hammer and Champy2001].
Um modelo é uma vista simplificada da complexa realidade, por isso mode-
lar permite, a quem toma as decisões, filtrar a complexidade do mundo real de
forma que o esforço se direccione apenas para aspectos considerados mais impor-
tantes [Giaglis2001]. Assim, trabalhar com modelos aumenta a compreensão sobre
o negócio e proporciona uma melhor percepção sobre a forma de melhorar o negócio
[Eriksson and Penker2000]. Um modelo de processo pode proporcionar uma com-
preensão detalhada de um processo [Aguilar-Savén2004]. Além disso, a modelação
de processos possibilita uma compreensão comum, a todos os intervenientes, da
análise de um processo de negócio.
Segundo Dorn et al., o foco da pesquisa do modelo do negócio evoluiu ao longo
do tempo. Começou pela criação de taxonomias de modelos de negócio, passou para
a descrição dos elementos dos modelos de negócios até à construção de ontologias
de modelos de negócios [Dorn et al.2009].
Na secção seguinte fala-se da relação entre o BPM e o desenvolvimento de soft-
ware, introduzindo-se assim o tema em estudo.

3 Da modelação do processo de negócio à modela-


ção de software
Desde sempre que os informáticos se depararam com dificuldades no levantamento e
especificação de requisitos. Como consequência disso, os produtos de software mui-
tas vezes não fazem o que é suposto fazer e fazem o que não é suposto [Jalote2008].
Uma das principais razões apontadas para o insucesso das aplicações de software
deve-se à fraca, ou incorrecta, especificação de requisitos. Isto porque, se por um
lado, as empresas criam sistemas informáticos para apoio aos seus negócios, por
outro lado, os engenheiros de software, focados no processo de desenvolvimento,
geralmente começam a definição dos requisitos a partir das necessidades dos utili-
zadores. Pankaj Jalote aponta ainda como razão do insucesso a fraca compreensão
do negócio por parte dos informáticos e a fraca compreensão da linguagem in-
formática pelos donos do negócio, o que dificulta o entendimento entre uns e outros
[Jalote2008].
Mili et al. diz que investigadores e profissionais na área de gestão de sistemas
de informação, há muito reconhecem que, compreender o processo de negócio é a
chave para identificar as necessidade dos utilizadores da aplicação informática que
o suporta. Para compreender o que um sistema informático deve fazer, é necessário
colocá-lo no contexto do processo de negócio ao qual ele dá apoio [Mili et al.2003] .
Tanto os especialistas na área de tecnologia da informação (TI) como os es-
pecialistas de engenharia de negócios concordam que os sistemas bem sucedidos
começam com uma compreensão dos processos de negócio de uma organização

3
[Aguilar-Savén2004]. Aliás, do ponto de vista de sistemas de informação (SI), uma
das vertentes mais úteis do BPM é o uso dos resultados da análise do processo de
negócio para o desenvolvimento de software. Neste uso, podemos referir-nos ao uso
dos resultados da análise para especificação de requisitos de uma aplicação de soft-
ware; para a obtenção das classes de uma aplicação ou até a obtenção do esquema
da base de dados, através da geração do diagrama de entidades e relacionamentos
(DER).
Giaglis afirma que, embora os benefı́cios do alinhamento do desenho de pro-
cessos de negócios com o desenho de seus sistemas de informação seja apreciado
em teoria, tais estratégias integradas de design raramente têm sido postas em
prática [Giaglis2001]. Tradicionalmente os analistas de negócios e profissionais de
sistemas de informação executam papéis distintos dentro das organizações, cada
um equipado com as suas próprias ferramentas, técnicas, capacidades e até mesmo
diferente terminologia [Giaglis2001].
Dorn et al. afirmam que uma das mais-valias do BPM é o facto de usar uma lin-
guagem compreendida por todos os intervenientes do processo, e consequentemente
conseguir resultados mais próximos da realidade [Dorn et al.2009]. Uma vez que o
BPM já faz um levantamento dos processos do negócio, usando para isso reuniões
com os stakeholders, onde se usa uma linguagem e uma notação compreendida por
todos, porque não usar a informação obtida durante esse processo como base para
o desenvolvimento de sistemas informáticos de apoio a esses negócios?
Vários estudos, como [Castro et al.2000, Martinez et al.2003, Goldsmith2004,
Liang et al.2008, Dorn et al.2009], aproximam as duas áreas, quer usando notações
usualmente usadas numa, na outra, quer através de construção de ligações (ou
pontes) entre elas.
O tema em estudo direcciona-se nesse sentido. Mais concretamente, pretende, a
partir da análise feita a nı́vel da gestão do processo de negócio extrair informação
de forma a definir o esquema da base de dados da aplicação de software que dará
suporte ao negócio.
Na secção seguinte fala-se sobre o método de investigação que vai ser usado na
investigação que agora se inicia como projecto no âmbito do PDTSI, o método de
investigação em desenho de ciência (Design Science Research).

4 DSR em Sistemas de Informação


Nesta secção são apresentados alguns conceitos relacionados com o método de inves-
tigação Desenho de Ciência (Design Science Research), e apontam-se algumas razões
que levam à crescente procura deste método de investigação na área de Sistemas de
Informação (SI).
Existe um grande número de métodos de investigação, alguns mais adequados
a umas áreas outros mais adequados para outras, no entanto, como é referido por
Avison et al., a abordagem mais adequada depende do tema de investigação e das
questões de investigação abordadas [Avison et al.1999]. Na área de Sistemas de In-
formação, as investigações têm, muitas vezes, um carácter prático, onde é frequente
a aplicação de teorias tradicionalmente usadas noutras áreas como economia, gestão,
ciências da computação para resolver problemas que intersectam as Tecnologias de
Informação (TI) e as organizações [Peffers et al.2006].
Avison et al. concluem que, em sistemas de informação, as abordagens de inves-
tigação qualitativas estão a ganhar aceitação. Dentro destas abordagens incluem-se
métodos como casos de estudo (case Studie), prova de conceito (proof of concept),
investigação-acção (Action-research) e investigação desenho de ciência (design sci-
ence research). Isto não significa que a pesquisa quantitativa como análise estatı́stica
(survey) e experiências laboratoriais não possam ser usadas, mas actualmente as

4
duas abordagens são igualmente apropriadas [Avison et al.1999].
O método de DSR teve as suas origens na engenharia, e noutras ciências aplica-
das [Venable2006]. Este método de investigação é uma actividade criativa e inova-
dora de resolver problemas cujo principal produto é a criação de novas tecnologias
[Venable2006]. Vaishnavi and Kuechler Jr. apelidam o método de “investigações
de melhoramento - improvement research”, para salientar o facto deste método se
centrar na resolução de problemas ou no melhoramento do desempenho de soluções.
Da mesma forma, Hevner et al. afirma que no método de investigação DS deve
abordar problemas importantes e com relevância [Hevner et al.2004]. Assim, a DSR
destina-se a resolver problemas, nunca resolvidos anteriormente, de uma forma única
e inovadora, ou a resolver problemas já resolvidos anteriormente, mas de uma forma
mais eficiente e eficaz que as já existentes [Hevner et al.2010].
O método de investigação DS está direccionado para investigar problemas con-
siderados como “fracos”. Estes problemas são caracterizados por terem uma, ou
mais, das seguintes caracterı́sticas[Hevner et al.2010]:
• Requisitos instáveis e restrições baseadas em ambientes não bem-definidos.
• Interacções complexas entre os subcomponentes do problema e sua solução.

• Flexibilidade, ou seja, capacidade de suportar alterações ao processo de dese-


nho, bem como ao desenho do artefacto.
• Uma dependência crı́tica sobre as capacidades cognitivas humanas (por exem-
plo, criatividade) para a produção de soluções eficazes.

• Uma dependência crı́tica sobre habilidades sociais (por exemplo, trabalho em


equipa) para a produção de soluções eficazes.
Na disciplina de Sistemas de Informação desenhar é fundamental. Os profissio-
nais de SI estão normalmente empenhados no desenho e implementação de artefactos
de Tecnologias de Informação que melhorem a performance dos negócios da orga-
nização, que se podem repercutir em ganhos económicos [March and Storey2008].
Assim, neste tipo de investigações desenvolvem-se artefactos de TI que alargam os
limites conhecidos das TI, abordando problemas importantes que até então ninguém
tinha pensado informatizar [Hevner et al.2004, March and Storey2008].
A tecnologia é prática e útil, podendo mesmo ser definida como “implementação
prática da inteligência”[March and Smith1995]. A tecnologia inclui ferramentas,
técnicas, materiais e fontes de energia que os humanos desenvolvem para atingi-
rem os seus objectivos. As tecnologias são desenvolvidas para resolver problemas
especı́ficos ou para colocar em prática conhecimento através de experiências. As Te-
cnologias de Informação são tecnologias usadas para obter e processar informação
de suporte aos propósitos humanos [March and Smith1995].
O método de investigação DSR é orientado á tecnologia, isto é, está orientado
para a elaboração de artefactos para a alcançar determinados objectivos e assim ser-
vir o ser humano [March and Smith1995]. Um artefacto de TI é criado para permitir
uma representação, uma análise, uma compreensão e desenvolvimento de sistemas
de informação de sucesso dentro de uma organização [March and Storey2008].

4.1 Resultados produzidos em DSR


As investigações que usam o método DSR, em sistemas de informação, produzem
basicamente quatro tipos de artefactos de TI: Construtores; modelos; métodos e ins-
tanciações[Hevner and March2003, Vaishnavi and Jr.2008, March and Storey2008,
March and Smith1995].

5
• Construtores - um construtor é um conjunto de vocabulário e sı́mbolos usado
para definir o problema e para especificar a solução. Este conjunto permite a
definição de uma linguagem que pode ser usada para partilhar o conhecimento
dentro da área [March and Smith1995]. A definição da linguagem tem um
forte impacto na forma como as tarefas e os problemas são concebidos.
Os construtores surgem na concepção no problema e podem ser refinados ao
longo de todo o ciclo de desenho.
• Modelos - um modelo é um conjunto de proposições que expressam o rela-
cionamento entre os construtores [March and Smith1995]. Um modelo é uma
representação do mundo real. Como afirma G. Giaglis, modelar permite fil-
trar a complexidade do mundo real para que o esforço se direccione apenas
para aspectos considerados mais importantes ou com uma maior relevância
[Giaglis2001].
Um modelo deve ser capaz de capturar a estrutura da realidade para que a
sua representação seja útil [Peffers et al.2006]. Assim, os modelos ajudam a
compreender o problema e a relacionar o problema com a solução.

• Métodos - um método é o conjunto de passos usados para executar uma tarefa


[March and Smith1995]. Hevner et al. define método como um processo que
nos fornece um guia para a resolução do problema [Hevner et al.2004].
Um método é baseado nos construtores e nos modelos anteriormente definidos.
Um método pode estar ligado a um modelo especı́fico onde os passos consti-
tuem pontos de entrada no modelo, ou pode ser usado para transformar (ou
traduzir) um modelo noutro. Os métodos podem ser formais, recorrendo ao
uso de métodos matemáticos ou algoritmos, ou informais, recorrendo a abor-
dagens que são descritas textualmente. A necessidade de usar determinados
métodos pode influenciar a definição dos construtores e modelos desenvolvi-
dos.

• Instanciações - uma instanciação é a operacionalização dos construtores, mo-


delos e métodos de um sistema [Vaishnavi and Jr.2008]. É a “realização”do
artefacto no seu ambiente, ou seja, é a colocação em prática do artefacto.
Uma instanciação envolve uma articulação completa da linguagem, modelos
e métodos que incorpora [March and Smith1995], por isso, uma instanciação
pode demonstrar a viabilidade e a eficácia dos modelos e métodos envolvi-
dos. As instanciações fornecem artefactos realmente a trabalhar cujo seu uso,
estudo, e melhoria, pode impulsionar novas ideias e progressos na área.

Os artefactos são, muitas vezes, construı́dos sobe a forma de protótipo.

Figura 1: Resultados produzidos pela DSR (extraı́do de [Venable2006,


Vaishnavi and Jr.2008] )

6
Os resultados produzidos por uma DSR e o relacionamento entre estes, encontram-
se representados na figura 1. Como se pode ver na figura 1 , existe um quinto
possı́vel resultado deste tipo de investigação - a criação de teorias, ou melhora-
mento de teorias já existentes - como sugerem [Venable2006, Vaishnavi and Jr.2008,
Kuechler and Vaishnavi2008, March and Smith1995].
Os autores apontam três razões principais para o facto:

• A construção metodológica de um artefacto pode ser objecto de teorização


[Kuechler and Vaishnavi2008],por exemplo, como construir software mais sus-
tentável;
• A fase de construção pode ser uma prova experimental do método.
• O artefacto pode expor o relacionamento entre os seus elementos. Esses re-
lacionamentos permitem certos comportamentos e restringem outros. Assim,
como sustenta [Kuechler and Vaishnavi2008], a construção e avaliação do ar-
tefacto permite um melhor conhecimento dos elementos e uma melhor com-
preensão dos seus relacionamentos, isto pode comprovar ou falsear teorias
anteriormente elaboradas sobre o assunto.

O artefacto em si deve ser rigorosamente definido, formalmente representado,


coerente e internamente consistente [Hevner et al.2004]. Além disso, o artefacto
deve ser inovador e útil para a resolução do problema por isso a sua avaliação é
essencial[Hevner et al.2004].

4.2 Construção e Avaliação


Para Hevner et al., o método de investigação DS encaminha a investigação através
da construção e avaliação de artefactos desenhados e construı́dos para ir ao en-
contro das necessidades do negócio [Hevner et al.2004]. Nos artigos [Venable2006,
Peffers et al.2006, March and Smith1995], os autores são da opinião de que as inves-
tigações em DS são essencialmente paradigmas do tipo problema-resolução. Neste
tipo de investigações existem duas actividades que merecem especial atenção, no-
meadamente construir e avaliar:

• Construir - refere-se ao desenho e construção do artefacto. O artefacto é


construı́do para executar uma tarefa especı́fica. A sua construção demonstra
que o artefacto é fazı́vel. Depois de construı́do, o artefacto pode tornar-se num
objecto de estudo. Definem-se construtores, modelos, métodos e instanciações,
sendo que cada um é uma tecnologia que, uma vez construı́da, pode e deve
ser avaliada cientificamente [March and Smith1995].
• Avaliar - refere-se à definição de critérios e métricas de avaliação e à ava-
liação do desempenho do artefacto no que diz respeito a esses critérios. As
métricas definem o que é que tentamos realizar ou aperfeiçoar. Uma falha das
métricas pode levar a uma falha na medição da performance do artefacto e
consequentemente a um mau julgamento [March and Smith1995]. Além dos
critérios e métricas de avaliação é necessário assegurar um ambiente adequado
à avaliação. No ambiente podem-se incluir todas as infra-estruturas técnicas
e dados necessários à avaliação. Por fim, é necessário, identificar as situações,
e ambientes, em que o artefacto funciona, em que situações não funciona, e
é necessário identificar como e porquê isso acontece. Isto leva a um conheci-
mento mais profundo e pormenorizado do artefacto e pode levar à criação de
novas ideias de alterações ao artefacto.

7
Um Artefacto de Tecnologias de Informação pode ser avaliado em termos
de funcionalidade, integridade, consistência, precisão, desempenho, confiabi-
lidade, usabilidade, o ajuste com os requisitos da organização, entre outros
atributos de qualidade relevantes [Hevner et al.2004]. Em DSR são usados
essencialmente métodos matemáticos e computacionais para avaliação dos ar-
tefactos [Hevner et al.2004].

Figura 2: O ciclo Construir-Avaliar do artefacto

Como se pode ver na figura 2, as actividades Construir-Avaliar formam um


processo iterativo. Por um lado o teste/avaliação do artefacto pode motivar, ou
sugerir, alterações ao seu desenho e construção. Por outro lado, sempre que o dese-
nho ou construção do artefacto sofre alterações, o artefacto deve ser reavaliado para
determinar os progressos existentes. Existem progressos quando uma tecnologia é
substituı́da por outra mais eficiente [March and Smith1995].
O ciclo Construir-Avaliar do artefacto usualmente ocorre várias vezes durante
a investigação. Ao longo das várias iterações, podem ser identificadas fraquezas
no artefacto e necessidades de refinamento e reavaliação. O desenvolvimento das
várias iterações encaminham a investigação para ir ao encontro das necessidades do
negócio [Hevner et al.2004].
A construção do artefacto está completa quando este satisfaz os requisitos e
restrições do problema que este pretende resolver. No entanto, por vezes, redefinir
e reavaliar pode ser proposto para trabalho futuro [Hevner et al.2004].

4.3 Desenvolvimento da metodologia


Hevner et al. propõem um conjunto de 7 linhas gerais a seguir numa investigação
quando se usa o método de DSR [Hevner et al.2004]. Jonh Venable, Vaishnavi and
William Jr. propõem cinco etapas para o desenvolvimento de uma investigação que
usa o método de DSR: Identificação do Problema; Sugestão; Desenvolvimento; ava-
liação e conclusão [Venable2006, Vaishnavi and Jr.2008, Kuechler and Vaishnavi2008].
Ken Peffers et al., com base em vários artigos lidos, entre os quais os citados
anteriormente, identificam pontos comuns no que diz respeito às etapas de desenvol-
vimento de uma investigação que usa o método DSR [Peffers et al.2006]. Baseados
nestes pontos comuns, definem um modelo do processo para desenvolver e avaliar
uma investigação, em Sistemas de Informação, que usa o método de DSR. O pro-
cesso é constituı́do por seis actividades: identificação do problema e motivação;
definição dos objectivos para a solução; desenho e desenvolvimento; demonstração;
avaliação e comunicação:

8
1. Identificação do problema e motivação - Nesta etapa define-se o proble-
ma especı́fico de investigação. A definição do problema vai ser usada para o
desenvolvimento de artefactos que podem ajudar a chegar à solução. Nesta
fase é necessário justificar o valor da solução [Peffers et al.2006] e a sua re-
levância para a área em questão. Para isso é necessário um bom conhecimento
sobre o estado da arte na área do problema e da importância ou relevância
da solução.
O objectivo das investigações, em Sistemas de Informação, na grande mai-
oria das vezes, é ganhar conhecimento e compreensão que possibilite o de-
senvolvimento e implementação de soluções baseadas em tecnologias para re-
solver problemas importantes para os negócios, não resolvidos anteriormente
[Hevner et al.2004]. Em DS este objectivo é conseguido através da criação de
artefactos.
Para Hevner et al., na área dos negócios, um problema de investigação re-
levante deve abordar os problemas que envolvem interacção entre pessoas,
organizações e tecnologia da informação [Hevner et al.2004].
2. Definição dos objectivos para a solução - depois de conhecer o problema
e depois do levantamento do estado da arte estar concluı́do, devem-se definir
os objectivos para a solução. Os objectivos podem ser quantitativos ou qua-
litativos. Se forem quantitativos, a solução proposta deve ser melhor que as
já existentes. Se forem qualitativos, a solução deve descrever a forma como o
novo artefacto suporta a solução do problema. Nesta fase, além de conhecer
o estado da arte, é necessário conhecer outras soluções, caso existam, e qual
a sua eficácia para servir de termo de comparação.
3. Desenho e desenvolvimento - nesta etapa, como o próprio nome indica,
desenham-se e constroem-se o(s) artefacto(s). Conceptualmente um artefacto
pode ser qualquer objecto desenhado para o qual a investigação contribui para
o seu desenvolvimento. Podem ser modelos, métodos ou novas propriedades
técnicas [Peffers et al.2006]. Esta actividade inclui a construção do artefacto
desde a definição das suas funcionalidades e arquitectura, até ao seu desenho
e desenvolvimento.
4. Demonstração - nesta fase faz-se a demonstração do uso do artefacto para
resolver uma, ou mais, instanciações do problema. A demonstração pode en-
volver experiências, simulações, aplicações em casos de estudo, etc. Nesta fase
é necessário saber como usar o artefacto para resolver o problema especificado.
Para que a demonstração tenha valor é necessária a criação de um ambiente
apropriado e bem definido. A demonstração pode servir, se correr bem, como
prova de que a ideia funciona.

5. Avaliação - nesta fase verifica-se, observando ou medindo, se realmente o


artefacto suporta a solução para o problema. Esta actividade envolve a com-
paração dos objectivos definidos com os resultados produzidos pelo artefacto
na demonstração. Nesta fase é necessário conhecer as técnicas de análise e
métricas relevantes. Dependendo do problema, a avaliação pode tomar várias
formas: pode envolver a comparação das funcionalidades do artefacto com os
objectivos da solução enumerados na actividade 2; pode medir quantitativa-
mente a performance do artefacto através de simulações ou de medidas de
tempo de resposta, por exemplo.
No final desta actividade, dependendo dos resultados da avaliação, o inves-
tigador pode decidir retroceder à actividade 3 (desenho e desenvolvimento)
e tentar melhorar o artefacto, retroceder para a actividade 2 e redefinir os

9
objectivos da solução ou prosseguir para a actividade seguinte e deixar as
possı́veis melhorias para trabalho futuro.
6. Comunicação e difusão do resultado - por fim, é necessário comunicar e
divulgar o problema e a sua relevância, os artefactos e a sua utilidade e os
resultados obtidos a outros investigadores e profissionais da área. Os trabalhos
devem ser publicados, de preferência, em revistas ou conferências da área de
investigação.
A comunicação deve ter em atenção o público a que se destina. Isto porque
os resultados de uma investigação na área de Sistemas de Informação, tanto
podem ser apresentados a públicos orientados à tecnologia como a públicos
orientados à gestão [Hevner et al.2004]. O público orientado à tecnologia vai
precisar de saber detalhes sobre a construção do artefacto, por isso, pode ser
necessário descrever o artefacto com algum detalhe, bem como o desenho e o
processo de construção do artefacto. Para o público orientado à gestão é ne-
cessário detalhe suficiente sobre os conhecimentos necessários para a aplicação
e avaliação do artefacto. Neste caso a ênfase não deve ser dada à parte técnica,
mas deve ser dada à importância do problema e à solução obtida, usando o
artefacto .
Como retorno das apreciações das comunicações efectuadas pode, por vezes,
ser necessário redefinir os objectivos da solução, voltando à actividade 2, ou
ainda reconstruir o artefacto, regressando à actividade 3.

Na figura 3 estão representadas as actividades executadas durante o processo de


investigação DSR.

Figura 3: Actividades do método de investigação DSR (adaptado de


[Peffers et al.2006])

As actividades do processo podem ser executadas em sequência, ou seja pela


ordem apresentada, de 1 à 6, ou podem seguir uma ordem diferente em que algu-
mas das actividade podem, inclusivamente, ser executadas várias vezes. Tal como
vimos anteriormente, da actividade 5 (avaliação) ou 6 (comunicação) a investigação
pode ser induzida a retroceder para as actividades 2 (definição dos objectivos) ou
3 (desenho e implementação).
Na secção seguinte fala-se da estratégia de investigação que se pensa adoptar
na investigação a desenvolver no âmbito do Programa Doutoral em Tecnologias e
Sistemas de Informação.

5 Estratégia de investigação a usar


O tema em estudo no âmbito do projecto de doutoramento pretende contribuir para
estreitar o fosso entre a modelação do processo de negócio e o desenvolvimento de

10
software de suporte ao negócio, mais concretamente, pretende obter o desenho da
base de dados a partir do modelo de processo de negócio. Para conseguir isso, ir-se-á
seguir as etapas enumeradas em baixo:

• Fazer o levantamento do estado da arte de abordagens de modelação do


negócio existentes;
• Estudo comparativo entre as abordagens existentes que visam fazer a ponte
entre o modelo de negócio e modelos de software.

Com base nos resultados do levantamento do estado da arte, serão identifica-


das as limitações das abordagens existentes e serão investigadas possı́veis melhorias
ou novas abordagens para resolver essas limitações. Até à data, e uma vez que o
estudo do estado da arte se encontra em andamento, não foi encontrada nenhuma
abordagem que defina o desenho da base de dados a partir da modelação do pro-
cesso de negócio, mas existem abordagens que visam a passagem da modelação do
processo de negócio para outros modelos de software como por exemplo os estudos
descritos em [Goldsmith2004, Castro et al.2000, Liang et al.2008, Dorn et al.2009,
Martinez et al.2003].
Em seguida, e tendo por base as actividades seguidas pelo método de inves-
tigação DSR, executar-se-ão os seguintes passos.

1. Nesta primeira etapa ir-se-á:


• Identificar a questão de investigação e definir o problema: Neste momento
existem várias propostas para a questão de investigação. Embora ainda
sujeita a alterações, penso que a que melhor se adapta é a seguinte:
“Como obter o desenho da base de dados das ferramentas de suporte ao
negócio a partir do modelo de negócio?”.
• Justificar a relevância do problema e motivações para encontrar uma
solução: a motivação inicial encontra-se descrita na secção 3. Após o
levantamento do estado da arte a motivação deverá ser aprofundada.
2. Definir objectivos de uma possı́vel solução: o principal objectivo é desenvolver
um artefacto que a partir no modelo de negócio, numa determinada linguagem,
gere o desenho da base de dados. A linguagem do modelação de negócio a
usar pensasse que poderá ser BPMN, XPDL e BPEL. O objectivo principal
deve, no entanto, numa fase próxima, ser detalhado em objectivos mais curtos
e simples de definir, avaliar e executar.
3. Esta etapa envolverá:
• A definição da linguagem: definir o vocabulário e sı́mbolos a usar. Para
isso é necessário identificar os modelos e linguagens já existentes que
vão ser envolvidos na investigação, por exemplo BPMN, XPDL, DER. É
necessário, no entanto, verificar se vocabulário e sı́mbolos já existentes
são suficientes, se não for, a solução poderá passar por criar uma extensão
às linguagens já existentes.
• Desenhar e desenvolver um artefacto (um protótipo).
4. Usar o artefacto criado para demonstração de que a solução é possı́vel. Para
isso é necessário criar um ambiente controlado de forma a compreender os
resultados obtidos e reconhecer focos de possı́veis melhorias.
5. Em seguida, o artefacto será usado e avaliado em exemplos práticos que aju-
dem a sua própria melhoria e refinamento. Á medida que o artefacto vai sendo
melhorado, a dimensão e diversidade dos casos de estudo pode ser aumentada.

11
6. Por fim comunicar: tenciono ir comunicando os resultados ao longo de todo
o processo de investigação e não apenas no final para assim, receber opiniões
dos revisores, que são especialistas na área, e desta forma poder fazer evoluir
a minha investigação o sentido correcto.
Como a investigação a ser desenvolvida no projecto de doutoramento engloba
duas áreas, a área da gestão dos processos de negócios e a área de modelação de
base de dados, é necessário ter especial atenção na fase de comunicação porque
esta pode ser direccionada a público orientado à gestão e público orientado à
tecnologia.

6 Conclusão
Neste artigo faz-se um estudo sobre o método de DSR (Design Science Research).
Este método de investigação foca-se no desenvolvimento de artefactos que esten-
dem os limites actuais das Tecnologias de Informação de forma a impulsionar uma
melhoria da performance dos negócios e das organizações.
A utilidade, qualidade e eficácia dos artefactos criados deve ser rigorosamente
demonstrada e avaliada. A avaliação de um artefacto em TI requer a definição de
métricas e a criação de um ambiente e dados apropriados. O método DSR, através
da iteração Construir-avaliar dos artefactos, guia a investigação para ir ao encontro
das necessidades de negócio.
O objectivo do método DSR é construir algo de útil. Como resultado das DSR
podem ser produzidos modelos, métodos, novas linguagens ou novas propriedades
técnicas. Alguns autores salientam a forte contribuição que os artefactos produzidos
em DSR dão para a criação ou melhoria de novas teorias.
O tema em estudo, visa obter o desenho da base de dados, das aplicações de
suporte ao negócio das organizações, a partir da modelação do processo de negócio
destas.
A gestão dos processos de negócio e consequentemente a sua modelação tem
sofrido um forte aumento de relevância nas organizações. Não apenas devido ao
aumento da complexidade dos negócios e organizações, mas também devido às
constantes alterações internas a que organizações estão sujeitas para fazer frente
a novos desafios e novas oportunidades de negócio. O levantamento dos processos
de negócio em organizações permite uma optimização dos processos de produção ou
de fornecimento de serviços e uma agilização de toda a organização. Esse aumento
da relevância do BPM nas organizações tem sido acompanhado pelo aumento do
número de teorias, processos de modelação, linguagens de modelação e aplicações
de software de suporte na área de BPM.
As alterações constantes a que as organizações estão sujeitas implicam, muitas
vezes, alterações aos sistemas de informação que suportam o negócio destas. Se
os processos de negócio já estão especificados e modelados, porque não usar essa
informação para servir de base à definição dos requisitos de software das aplicações
de suporte ao negócio, nomeadamente à definição da base de dados?
Das várias opiniões citadas na secção 3 deste artigo, podemos concluir que todos
estão de acordo que a modelação do processo de negócio deve servir de base ao
desenvolvimento de aplicações informáticas de suporte ao negócio, no entanto esta
realidade ainda está aquém do desejado. Por outro lado, como diz Vaz Velho, a
informação a guardar na base de dados é, uma grande maioria das vezes, a parte
mais importantes das aplicações informáticas, sendo fundamental ao desempenho
das organizações. No entanto, as bases de dados são, quase sempre, definidas como
suporte aos requisitos[Velho2004]. Estas opiniões encaminham-nos para o tema de
investigação proposto: “Da modelação do processo de negócio para a definição da
base de dados”.

12
Como trabalho futuro ir-se-á investigar melhor as caracterı́sticas de cada aborda-
gem de modelação do processo de negócio, em especial as caracterı́sticas do modelo
do processo de negócio que conduzam à obtenção do esquema da base de dados do
software de suporte ao negócio.

Referências
[Aguilar-Savén2004] Aguilar-Savén, R. S. (2004). Business process modelling: Re-
view and framework. International Journal of Production Economics, 90(2):129
– 149. Production Planning and Control.
[Avison et al.1999] Avison, D., Lau, F., Myers, M., and Nielsen, P. A. (1999). Ac-
tion research. COMMUNICATIONS OF THE ACM, 42.
[Castro et al.2000] Castro, J., Alencar, F., and Cysneiros, G. (2000). Closing the
gap between organizational requirements and object oriented modeling. Journal
of the Brazilian Computer Society, 7.
[Dorn et al.2009] Dorn, J., Grün, C., Werthner, H., and Zapletal, M. (2009). From
business to software: a B2B survey. Information Systems and E-Business Mana-
gement, 7:123–142. 10.1007/s10257-008-0082-4.
[Eriksson and Penker2000] Eriksson, H.-E. and Penker, M. (2000). Business mode-
ling with UML. Technical report, Open Training.

[Estublier2006] Estublier, J. (2006). Software are processes too. In Li, M., Boehm,
B., and Osterweil, L., editors, Unifying the Software Process Spectrum, volume
3840 of Lecture Notes in Computer Science, pages 25–34. Springer Berlin / Hei-
delberg.
[Giaglis2001] Giaglis, G. M. (2001). A taxonomy of business process modeling
and information systems modeling techniques. International Journal of Flexible
Manufacturing Systems, 13:209–228.
[Goldsmith2004] Goldsmith, R. F. (2004). Discovering real business requirements
for software project success. TLFeBOOK.
[Hammer and Champy2001] Hammer, M. and Champy, J. (2001). Reengineering
the corporation: a manifesto for business revolution. Harper Business.
[Hevner et al.2010] Hevner, A., Chatterjee, S., Hevner, A., and Chatterjee, S.
(2010). Design science research in information systems. In Design Research
in Information Systems, volume 22 of Integrated Series in Information Systems,
pages 9–22. Springer US.

[Hevner and March2003] Hevner, A. and March, S. (2003). The information sys-
tems research cycle. Computer, 36(11):111 – 113.
[Hevner et al.2004] Hevner, A. R., March, S. T., Jinsoo, P., and Ram, S. (2004).
Design science in information systems research. MIS Quarterly, 28(1):75 – 105.

[Jalote2008] Jalote, P. (2008). A concise Introduction to Software Engineering.


Springer.
[Ko2009] Ko, R. K. L. (2009). A computer scientist’s introductory guide to business
process management (bpm). Crossroads, 15:4:11–4:18.

13
[Kuechler and Vaishnavi2008] Kuechler, B. and Vaishnavi, V. (2008). On theory
development in design science research: anatomy of a research project. European
Journal of Information Systems, 17:489–504.
[Liang et al.2008] Liang, Y., Tian, J., Hu, S., Song, Y., and Zhang, Y. (2008).
A template-based approach for automatic mapping between business process
and BPEL process. Wuhan University Journal of Natural Sciences, 13:445–449.
10.1007/s11859-008-0413-9.
[March and Smith1995] March, S. T. and Smith, G. F. (1995). Design and natural
science research on information technology. Decision Support Systems, 15(4):251
– 266.
[March and Storey2008] March, S. T. and Storey, V. C. (2008). Design science in
the information systems discipline: An introduction to the special issue on design
science research. In Design Science in the Information Systems, volume 32, pages
725–730. MIS Quarterly.
[Martinez et al.2003] Martinez, A., Castro, J., Pastor, O., and Estrada, H. (2003).
Closing the gap between organizational modeling and information system mode-
ling. Paper presented at the WER03-VI.
[Mili et al.2003] Mili, H., Jaoude, G. B., Éric Lefebvre, Tremblay, G., and Petrenko,
A. (2003). Business process modeling languages: Sorting through the alphabet
soup. In OOF 22 NO. IST-FP6-508794 (PROTOCURE II) September.

[ORACLE2011] ORACLE (2011). http://blogs.oracle.com/bpmbrasil/bpm/. Web


site. Accessed January 27, 2011.
[Peffers et al.2006] Peffers, K., Tuunanen, T., Gengler, C. E., Rossi, M., Hui, W.,
Virtanen, V., and Bragge, J. (2006). The design science research process: A
model for producing and presenting information systems research.

[ter Hofstede et al.2003] ter Hofstede, A., van der Aalst, W., and Weske, M. (2003).
Business process management: A survey. In Weske, M., editor, Business Process
Management, volume 2678 of Lecture Notes in Computer Science, pages 1–12.
Springer Berlin / Heidelberg.
[Vaishnavi and Jr.2008] Vaishnavi, V. K. and Jr., W. K. (2008). Design Science
Research Methods and Patterns Innovating Information and Communication Te-
chnology. Auerbach Publications.
[Velho2004] Velho, A. V. (2004). Arquitectura de Empresa. CentroAtlantico.pt.
[Venable2006] Venable, J. R. (2006). The role of theory and theorising in design
science research. First International Conference on Design Science Research in
Information Systems and Technology, Claremont, California., 1:1–18.
[White and Miers2008] White, S. A. and Miers, D. (2008). BPMN Modeling and
Reference Guide. Future Strategies Inc.

View publication stats


14

Você também pode gostar