Machine Translated by Google
Metodologia de Ciência de Design Suave
Ricardo Baskerville Jan Pries-Heje
Universidade Estadual da Geórgia Roskilde Departamento
Departamento CIS da Universidade de Com.,
Caixa Postal 4015 Bus. & IT
Atlanta GA 30302 Universitetsvej
EUA 1 4000
+1 404 413-7362 Roskilde Dinamarca +45 72 18 50 00
baskerville@acm.org janph@ruc.dk
Abstrato
Este artigo propõe e avalia uma abordagem de sistemas flexíveis para design
de pesquisa científica. A Soft Design Science fornece uma abordagem para o
desenvolvimento de novas formas de melhorar as organizações humanas,
especialmente com consideração aos aspectos sociais, por meio das atividades
de design, desenvolvimento, instanciação, avaliação e evolução de um artefato
tecnológico. A abordagem Soft Design Science funde o processo comum de
pesquisa em design science (design, construção de artefato, avaliação) junto
com a metodologia iterativa de sistemas soft. O processo de avaliação do
artefato design-build é iterado até que os requisitos específicos sejam
atendidos. Os requisitos generalizados são ajustados à medida que o processo
continua a manter o alinhamento com os requisitos específicos. No final, o
artefato representa uma solução geral para uma classe de problemas mostrados
para operar em uma instância dessa classe de problemas. A metodologia
proposta é avaliada por uma análise de como ela difere de, e poderia ter
informado e melhorado, um estudo de design science publicado, que usou um
método de pesquisa-ação orientado para o design.
Categorias e descritores de assunto A.0,
Am, Hm (sistemas de informação diversos)
Termos gerais
Gestão, Projeto
Palavras-chave
Metodologia de Pesquisa, Soft Design Science, Design Science
Pesquisa, Metodologia de Sistemas Soft, Pesquisa-Ação
1. INTRODUÇÃO
Design Science Research (DSR) é usado para desenvolver novas tecnologias
para resolver problemas. Tais problemas e soluções são muitas vezes de
natureza sócio-técnica, o que cria problemas para DSR na obtenção de
compreensão do problema, identificação de soluções sistemicamente
apropriadas e na avaliação eficaz de soluções novas e inovadoras. Baskerville
et al [1] propuseram o desenvolvimento de uma abordagem mais suave para
DSR para abordar essas questões.
Este artigo propõe e avalia uma abordagem soft para design de pesquisa
científica (Soft DSR), que combina aspectos da Soft Systems Methodology
(SSM) [2-4] com DSR. Soft Design Science fornece uma abordagem para o
desenvolvimento de novas formas de melhorar as organizações humanas,
especialmente com a consideração de
A permissão para fazer cópias digitais ou impressas de todo ou parte deste
trabalho para uso pessoal ou em sala de aula é concedida sem taxa, desde que
as cópias não sejam feitas ou distribuídas com fins lucrativos ou vantagens
comerciais e que as cópias contenham este aviso e a citação completa na primeira
página . Para copiar de outra forma, ou republicar, postar em servidores ou
redistribuir para listas, requer permissão específica prévia e/ou uma taxa.
DESRIST '09, 7 a 8 de maio de 2009, Malvern, Pa, EUA.
Copyright 2009 ACM 978-1-60558-408-9/09/05…$5,00.
John Venable
Universidade de Tecnologia Curtin
Escola de Sistemas de Informação
Caixa GPO U1987
Perth WA 6845
Austrália
+61 8 9266 7054
j.venable@curtin.edu.au
aspectos sociais, através das atividades de design, desenvolvimento,
instanciação, avaliação e evolução de um artefato tecnológico.
Este artigo analisa parte da literatura sobre DSR, Action Research e SSM na
próxima seção antes de desenvolver um design e uma justificativa para uma
abordagem Soft DSR na seção subsequente. Em seguida, a abordagem Soft
DSR proposta é avaliada analisando quais insights poderiam ter ocorrido e
melhorias feitas se a abordagem Soft DSR tivesse sido aplicada a um estudo
de caso publicado, em vez do método de pesquisa-ação orientado ao design
que foi aplicado. Por fim, a análise é discutida e as conclusões são tiradas.
2. REVISÃO DE LITERATURA
Esta seção revisa a literatura que serve de base para o
desenvolvimento de uma abordagem Soft DSR. Ele considera Design Science
Research, Action Research e Soft Systems Methodology. A pesquisa-ação foi
revisada por causa de suas semelhanças com DSR e SSM e porque um estudo
de pesquisa-ação orientado ao design foi usado no estudo de caso que é
analisado para avaliar os benefícios potenciais de uma abordagem Soft DSR.
2.1 Metodologia na pesquisa em Design Science A
Design Science Research (DSR) foi lançada como um
paradigma em vez de uma metodologia de pesquisa discreta.
Iivari [5] descreve seu caráter distinto como paradigma em
termos de sua ontologia, epistemologia, metodologia e ética.
Ele equipara a abordagem à metodologia de pesquisa
construtiva que é distinta da pesquisa-ação histórica, prática e filosoficamente
A metodologia em DSR tem sido amplamente considerada tangencialmente na
literatura. De fato, seu método básico se aproxima tanto da visão comum do
“método científico” que parece aceitável como uma suposição. O pesquisador
aprende sobre artefatos e cenários naturais formulando hipóteses (um projeto),
conduzindo um experimento (instanciando um artefato) e combinando os
resultados com as expectativas (avaliando). Talvez este simples processo de
pesquisa (design, construção-artefato, avaliação) não exija maiores elaborações.
Consequentemente, os principais trabalhos seminais em DSR de sistemas de
informação têm se preocupado com sua relevância na filosofia da ciência [5, 6],
a natureza da teoria em DSR [7, 8] e os critérios para avaliar DSR [9]. A
metodologia de pesquisa implícita nesses trabalhos parece muitas vezes ser
considerada como resultado da filosofia, teoria e critérios.
Machine Translated by Google
2.1.1 Iteração no DSR
O DSR geralmente não é considerado um processo iterativo. Em vez
disso, é considerado principalmente como episódico. Talvez seus fortes
vínculos conceituais com as profissões de engenharia e ciência da
computação ancorem a teoria em um conjunto de especificações
complexas, e o processo de construção seja tão complexo e caro que as
revisões após a avaliação sejam mais ou menos consideradas como
episódios separados da ciência do projeto, em vez de iterativos. desenvolvimento de artefatos.
Uma representação simples deste método episódico é mostrada na Figura
1 [10]. Essa abordagem consiste em quatro atividades: (1)
Pesquisa, (2) Avaliação Ex Ante, (3) Construção e (4) Avaliação Ex Post.
Essa abordagem assume que a identificação e especificação do problema
faz parte do processo de busca que desenvolve o projeto. Os dois
principais produtos do método são o design e o artefato. A aprendizagem
“científica” decorre do processo de busca, da construção e das duas
avaliações.
"A pesquisa"
Design Research Science
de antes
de Projeto
O design Avaliação
Pesquisa em Ciência do Design
"O
Construção"
Publicação antiga
O Artefato
Avaliação
Notação:
Atividade Fluxo Resultado
Figura 1. Método de Pesquisa Científica do Design Episódico.
Tal abordagem episódica é apropriada onde o projeto pode ser
relativamente completo e final em sua especificação e a avaliação do
artefato completará o projeto de pesquisa (ou episódio).
Certamente parece provável que esse método possa ser operado de
forma iterativa. Fazer isso implica que o design e o artefato devem ser
considerados como provisórios e sugere que eles devem ser
necessariamente mais simples, menos complexos e menos custosos se o
processo for repetido várias vezes. Essa abordagem pode ser representada
de maneira mais simples adicionando uma seta de “repetição” ao processo.
Veja a Figura 2.
"A pesquisa"
de antes
O design
Avaliação
"O
Construção"
Publicação antiga
O Artefato
Avaliação
Notação:
Atividade Fluxo Resultado
Figura 2. Método de pesquisa científica de design iterativo.
2.2 Prototipagem Um
método DSR iterativo aumenta a semelhança de tal método DSR
com a prototipagem e sua forma mais geral (e mais antiga) no
desenvolvimento organizacional, a pesquisa-ação. A prototipagem é
uma metodologia de desenvolvimento de sistema venerável que
envolve a construção e teste de protótipos de sistemas, muitas vezes
com o objetivo de esclarecer requisitos vagos [11] e muitas vezes
em colaboração com os usuários potenciais [12].
Os protótipos assumem diferentes formas para diferentes propósitos. O
mais simples é um protótipo de maquete que modela os aspectos físicos
do sistema final. Outro exemplo é um protótipo evolucionário que é um
modelo modificável e em execução de parte de um sistema. Essa forma
de prototipagem é a base de muitos produtos de software orientados a
lançamentos [13]. Como cada uma dessas formas de prototipagem envolve
projetar e implantar artefatos com o objetivo de aprender sobre o artefato
ou seu ambiente, parece problemático excluir as metodologias de
prototipagem do uso dentro do DSR.
Devido à natureza colaborativa da prototipagem, ela é considerada uma
abordagem de desenvolvimento de sistemas que também pode se tornar
um mecanismo de mudança organizacional [14]. A partir desta perspectiva,
o potencial de prototipagem para o desenvolvimento organizacional
também o torna útil como uma forma de metodologia de pesquisa-ação [15].
2.3 Pesquisa-ação
A semelhança entre metodologia de pesquisa-ação e DSR já gerou um
discurso na literatura. Superficialmente, as duas abordagens para a
descoberta científica parecem bastante distintas.
A pesquisa-ação visa a ação organizacional para criar mudanças a fim de
descobrir novos conhecimentos em um modo clínico. O DSR visa o design
para criar um artefato a fim de descobrir novos conhecimentos em um
modo generativo (ou criativo). Veja a
Figura 3.
Machine Translated by Google

ciência, ciência social e ciência da computação estão chegando a pontos

Mudar Artefato muito semelhantes, embora ainda diferentes, em suas abordagens de pesquisa.

Tendo considerado a literatura sobre DSR e AR, apresentamos agora a

literatura sobre Metodologia de Sistemas Soft.

2.4 METODOLOGIA DE SISTEMAS SOFT

A metodologia de sistemas flexíveis (SSM) é uma abordagem de ciência de
Ação Projeto sistemas proeminente para problemas técnico-sociais [2-4]. Por ter surgido
da junção da pesquisa-ação com a ciência de sistemas, é considerada uma
forma de pesquisa-ação [15]. Na prática, o SSM é menos usado para
Um modo clínico de descoberta Um modo generativo de descoberta pesquisa per se e mais usado apenas como uma metodologia de
desenvolvimento de sistemas. Sua ciência de sistemas e pensamento
Figura 3. Distinções superficiais entre pesquisa-ação e sistêmico o tornam eficaz para o desenvolvimento de sistemas (incluindo
design science. sistemas de informação) que são bem-sucedidos em ambientes
organizacionais sociais difíceis. É também uma abordagem iterativa para o
No entanto, essas distinções superficiais começam a evaporar quando o desenvolvimento de sistemas (como a prototipagem), mas que leva em
design é reconhecido como uma ação organizacional e quando situar um consideração o sistema social no qual um sistema técnico deve se integrar.
artefato novo ou diferente em um ambiente organizacional é reconhecido Mais importante ainda, a abordagem distingue o pensamento no mundo real
como uma mudança organizacional. Da mesma forma, como o DSR pode do pensamento em um mundo abstrato e sistêmico. Veja a representação do
produzir conceitos, construções e modelos, bem como instanciações de modelo de sete estágios do SMM [2] na Figura 4.
artefatos [6], os produtos intelectuais de ambas as abordagens podem ser os
mesmos. Em um sentido prático, qualquer uma das abordagens começa a
1. A situação do 7. Ação para
parecer subsumível dentro da outra. problema melhorar a 6. Mudanças viáveis
(não estruturada) situação do problema e desejáveis
a. ~~~~~~~~ b.
As semelhanças entre DSR e pesquisa-ação em alto nível de abstração são ~~~~~~~~ c.
~~~~~~~~~
2. A situação do 5. Comparação de 4 e 2 ...
inegáveis. Ambos geram conhecimento científico modificando intencionalmente problema
(expressa)
um cenário real e avaliando cuidadosamente o resultado [16]. A evidência da
Mundo real
semelhança também se torna aparente ao avaliar os resultados de cada
abordagem de pesquisa. Em certos casos, cada abordagem pode satisfazer
Sistemas a pensar
os critérios aceitos pela outra [17]. Sein et al [18] (não publicado) estão 3. Definições de raiz de
4. Modelos
conceituais

atualmente desenvolvendo a abordagem “Action Design” para mesclar ainda sistemas relevantes

mais a pesquisa-ação e a ciência do design.

4a. Conceito de 4b. Outros sistemas de

sistemas formais pensamento

Mas as semelhanças e a facilidade com que uma abordagem pode se fundir

com a outra não significa que essas abordagens de pesquisa sejam as
Figura 4. Metodologia de Sistemas Soft [2].
mesmas. A análise de Iivari [5] explica como as abordagens surgem de raízes
Existem diferentes versões publicadas do SSM conforme ele se desenvolveu
historicamente diferentes (pesquisa-ação no movimento sociotécnico e
ao longo dos anos. Nesta seção, damos uma visão geral do antigo modelo
ciência do design na engenharia). Suas intenções práticas básicas são
de sete estágios [2], pois acreditamos que seja mais acessível ao novato,
bastante diferentes (pesquisa-ação no tratamento de doenças sociais e
com atividades mais específicas nos estágios e iteração menos generalizada
ciência do design na construção de artefatos). Estes também diferem
do que o modelo de quatro estágios mais recente [4]. Ao implementar o SSM,
ontologicamente (a pesquisa-ação é nominalista, idealista e construtivista,
enquanto a ciência do design é realista e materialista); epistemologicamente usa-se técnicas relevantes para os vários estágios, alterna entre o mundo
real e o mundo do pensamento sistêmico e repete quando apropriado.
(a pesquisa-ação tende a ser antipositivista enquanto a design science tende
Descrevemos o processo geral e cada estágio brevemente abaixo.
a ser positivista); e metodologicamente (a pesquisa-ação idealiza as situações
do cliente enquanto a design science idealiza as situações de laboratório).
Iivari e Venable [19] mostram ainda níveis diferentes de sobreposição
O estágio um é o primeiro de dois estágios que exploram uma situação
dependendo de suas variantes – (1) não sobrepostos (ou seja, disjuntos), (2)
problemática dentro do quadro de pensamento do mundo real. No estágio
um pouco sobrepostos e (3) significativamente sobrepostos, mas que nunca
dois, as visões não estruturadas da situação problemática recebem mais
são exatamente iguais.
estrutura e expressão, de forma que as partes interessadas possam entendê-
las, que se concentrem na essência da situação e que identifiquem temas
O terceiro caso poderia ser chamado de “pesquisa-ação orientada para o
design”, que é o tipo considerado aqui. relevantes. Os principais objetivos são desenvolver uma compreensão
compartilhada de diferentes perspectivas e criar uma base para discussões
posteriores em estágios posteriores. O estágio três representa uma mudança
Claramente, existem semelhanças e diferenças entre DSR e pesquisa-ação.
do pensamento do mundo real (sobre perspectivas sobre o que é, o que é
Além disso, ambas as abordagens também compartilham a capacidade de
indesejável ou desejável e por quê) para o pensamento sistêmico (usando
adotar a prototipagem como uma abordagem subjacente, onde implementar
conceitos sistêmicos e técnicas inspiradas no pensamento sistêmico).
e avaliar um sistema de informação é um elemento da atividade de pesquisa.
O estágio três é sobre debater vários pontos de vista, definir o que as partes
De nossa perspectiva, partes do design
interessadas desejam em um sistema relevante (como uma solução para a
situação problemática) e selecionar uma (ou mais) definição(ões)
Machine Translated by Google

para consideração posterior no estágio 4. No estágio quatro, os modelos a imersão em uma situação suporta bem as abordagens de avaliação soft
conceituais são construídos, com base nas definições básicas acordadas do versus hard, alinhando-se bem com conceitos interpretativos versus positivistas
sistema desejado. Um modelo conceitual representa as atividades humanas na avaliação e evitando simplificações reducionistas (exageradas).
desejadas. O estágio 5 representa uma mudança do pensamento sistêmico
para reconsiderar como os modelos conceituais desenvolvidos no mundo do
pensamento sistêmico se encaixam no mundo real. São feitas comparações Tabela 1. Comparação das características de DSR,
entre os modelos conceituais e a situação-problema expressa. SSM e AR.
O estágio seis considera se as áreas identificadas para melhoria e mudança Característica DSR SSM COM
determinadas no estágio cinco podem ser aceitas e integradas à cultura. Orientação / Pesquisar Prática Praticar e
Finalmente, o estágio sete deve determinar o escopo da ação, quem deve Método para Pesquisar
agir, que tipo de ação deve ser tomada, em quais áreas e quando. …
Meta Problema Problema Problema
resolvendo resolvendo Resolvendo e/ou
Após a tomada de ação, mais iterações podem ser realizadas para avaliar a Comportamental
situação problemática e determinar se uma melhoria suficiente foi feita e por
Entendimento
que ou não. Problemas contínuos podem ser a motivação para outro ciclo (ou Situação Generalizada Situação
Especificidade
episódio) através do processo SSM.
Específico Específico e
generalizado
função de design Invenção / Aplicação ou Aplicação ou
O DSR e o SSM são semelhantes porque ambos se preocupam com a generativo (Invenção e (Invenção e
solução de problemas e com o design racional de soluções. Ambos podem
Aplicativo) Aplicativo)
envolver avaliação de soluções geradas e iteração de volta para atividades
Resultado Projeto Situado Situado
anteriores (ou mesmo todo o processo) onde pontos fracos são identificados
Teoria ou Organizacional Organizacional
e/ou melhorias adicionais são necessárias. A principal diferença entre o SSM
Artefato Melhoria Melhoria e
e o DSR é que o SSM se preocupa principalmente em resolver problemas
mostrado a
específicos para um cliente específico, enquanto o DSR se preocupa em
tem utilidade (Comportamental
resolver problemas generalizados para uma classe generalizada de partes
Teoria ou
interessadas. No entanto, conforme identificado acima, o SSM é muito útil
Projeto
para lidar com problemas sociotécnicos. Em particular, enquanto ambos
Teoria)
visam estar bem fundamentados na compreensão do problema e no raciocínio
sobre o design, o SSM fornece atividades e técnicas essenciais derivadas do
Tendo dado uma visão geral dos aspectos salientes da literatura sobre DSR,
pensamento sistêmico para fazer isso melhor. Na próxima seção, consideramos
Action Research e SSM, a próxima seção considerará como o SSM pode
como o SSM pode ser adaptado para uso em Design Science Research.
informar o design de uma metodologia flexível para DSR. O resultado é uma
proposta de adaptação do SSM para fins de uma metodologia sociotécnica
geral para DSR (uma metodologia “Soft DSR”).

2.5 CIÊNCIA DE DESIGN, PESQUISA DE

AÇÃO E SISTEMAS SOFT 3. ADAPTANDO SSM EM UMA METODOLOGIA
SOFT DSR
O SSM é comumente aplicado em situações de pesquisa-ação e tem
Devido às semelhanças descritas acima, adaptar SSM para DSR pode ser
semelhanças com a pesquisa-ação e a prototipagem. É complementar tanto
simples. Por exemplo, a representação iterativa de DSR na Figura 2 pode ser
à pesquisa-ação quanto à DSR. A Tabela 1 ilustra isso comparando e
facilmente conceituada como uma distinção entre pensar no mundo real e
contrastando essas três abordagens. Dada a natureza complementar de SSM
pensar no mundo dos sistemas abstratos com a distinção colocada após “O
e DSR, uma abordagem de Metodologia de Sistemas Soft para DSR pode ser
Projeto” e antes de “A Construção”. Aqui, a busca pela solução de design e a
apropriada quando o assunto do estudo inclui pesquisa sobre a interação
avaliação da solução de design são atividades que ocorrem no mundo
entre um artefato e um sistema social. Este último ponto é crítico.
abstrato do design thinking.

A vantagem do SSM é sua capacidade de estudar o artefato em relação ao

A construção do artefato e sua avaliação são atividades que ocorrem no
sistema social no qual o artefato está inserido e avaliado.
mundo real do sistema social no qual o artefato se situa.

Possíveis relações entre DSR e SSM não são bem exploradas. Tem havido
O design thinking envolve criatividade e não apenas análise. Envolve
alguma exploração da noção de uma forma suave de DSR [1]. Este trabalho
inspiração e o processo de gerar, desenvolver e testar ideias. Como as ideias
previu que uma abordagem suave para DSR iria (1) fazer forte uso da teoria
de design devem, em última análise, ser executadas na produção prática de
comportamental, (2) tratar os problemas e a resolução de problemas como
artefatos, o design thinking bem-sucedido incorpora o pensamento sistêmico
complexos e situados, (3) usar métodos interpretativos para avaliação de
[20].
artefatos e (4) examinar os todo o processo de design e avaliação durante a
avaliação [1].
Essa metodologia Soft DSR pode ser elaborada expressando as atividades
Com exceção do ponto (1) acima, o SSM acomoda naturalmente essas
SSM na linguagem das atividades DSR paralelas. Ver
características. O SSM é particularmente forte em evitar conceituações
simplistas e entendimentos de problemas. Isso é
Machine Translated by Google
Figura 5. Esta metodologia Soft Design Science Research (Soft DSR)
tem sete atividades.
1. Um problema específico é identificado e delineado.
2. Este problema deve então ser expresso como um conjunto específico
de requisitos
3. No mundo dos sistemas, os requisitos para o problema específico são
sistemicamente abstraídos e traduzidos em um problema geral com
dimensões técnicas e sociais.
Aqui, o design thinking é sobre uma classe de problemas, e não
sobre o problema específico de propriedade do cliente.
4. Um projeto de solução geral (uma classe de soluções) para o problema
geral é derivado do pensamento sistêmico e expresso em termos
de requisitos gerais. Essa atividade envolve uma combinação de
técnicas da ciência do design, como a busca de componentes
gerais da solução juntamente com a expressão usando a lógica
imperativa.
5. Os requisitos gerais de projeto são comparados com o problema
específico para adequação. Nesta atividade o problema específico
é rearticulado em termos dos requisitos gerais e da lógica imperativa.
6. Uma pesquisa declarativa é então feita para os componentes
específicos que fornecerão uma instância viável de uma solução
para os requisitos gerais. A busca declarativa se faz necessária por
dificuldades em operar a lógica imperativa.
7. Uma instância da solução específica é construída e implantada no
sistema social. Dessa forma, o problema específico é alterado
(espera-se que melhorado), o aprendizado é obtido e o ciclo
recomeça.
Este ciclo continua até que os problemas sociais e técnicos sejam
resolvidos.
1. O problema 7. Construa a
específico solução
solução específica
Lógica Declarativa
5. Comparação de 4
2. O problema e2
específico expresso
Mundo real
Design Thinking
4. Requisitos
3. O problema gerais
geral
4a. Pesquise por
componentes gerais de
solução
Figura 5. Pesquisa científica de design suave.
Esta adaptação de sistemas soft de DSR tem elementos que a distinguem
de SSM e DSR. Entre esses elementos estão (1) a distinção entre
atividades de design thinking e atividades do mundo real; (2) distinção
clara das atividades que envolvem a expressão do problema geral e
requisitos gerais; (3) a separação da lógica imperativa e declarativa; e (4)
a colocação lógica da construção do artefato e do problema específico
para resolver o problema específico do cliente. O design thinking, como
um Soft DSR paralelo ao pensamento sistêmico, é diferente do
pensamento sistêmico com ênfase na criatividade e na inspiração.
Também é diferente da típica análise empírica DSR que domina o
pensamento do mundo real sobre problemas específicos. Matricular
o pensamento de design em Soft DSR ajuda a esclarecer o posicionamento
distinto de problemas gerais e requisitos gerais em um mundo teórico e
abstrato. Os pontos fortes (facilidade de expressão de requisitos) e
limitações (dificuldade de operacionalização) da lógica imperativa também
são adequados a este mundo abstrato. Ao contrário de DSR e SSM, a
mudança do mundo abstrato de volta para o mundo real envolve lógicas
de troca expressas.
Mudar para a lógica declarativa (facilidade de expressão de soluções)
para fins de busca de soluções foi a solução de Simon. No Soft DSR,
essa troca lógica é expressa e definida com mais clareza do que no DSR
ou no SSM. Uma outra distinção é a natureza iterativa desta abordagem
DSR distinta, ou seja, a colocação da instância de uma solução de design
com a instância original do problema.
Formas gerais surgem como abstrações de instâncias do mundo real
[21]. As atividades de abstração no Soft DSR diferem distintamente do
SSM e do DSR. No SSM, a representação abstrata do sistema é expressa
por meio do processo de definição de definições de raiz e sua tradução
em modelos conceituais. No DSR, as abstrações surgem como teorização
do design. No Soft DSR, os processos abstratos são mais distintamente
formados em abstrações para formas gerais e operações criativas
usando essas formas gerais.
As duas principais formas gerais em Soft DSR são o problema
generalizado e os requisitos generalizados. As operações criativas
incluem escolher como abstrair o problema geral e decidir quais
características do problema geral serão usadas como base para os
requisitos gerais.
Tendo definido uma metodologia Soft DSR que adapta SSM para DSR, a
próxima seção fornecerá uma avaliação preliminar da metodologia,
analisando sua aplicação hipotética a um estudo DSR existente.
4. SOFT DSR EM AÇÃO: UMA AVALIAÇÃO
6. Procure uma
ANALÍTICA
Antes que uma metodologia de pesquisa proposta, como o Soft DSR,
receba uma avaliação “ao vivo” em testes de campo (ou seja, avaliação
naturalística [10, 22]), evidências devem ser necessárias para fornecer
indicações de sua probabilidade de desenvolver um resultado de design
bem-sucedido e descobertas de pesquisa significativas . Uma avaliação
artificial viável [10, 22] para desenvolver evidências antes de realizar uma
avaliação naturalística ao vivo é aplicar construções Soft DSR na
avaliação de um exemplo DSR concluído (e publicado). O objetivo deste
aplicativo é avaliar como essa pesquisa poderia ter sido melhorada (ou
4b. lógica imperativa
pelo menos feita de forma diferente) com o Soft DSR. Essa avaliação
fornecerá aos pesquisadores em potencial boas indicações dos resultados
potenciais.
Para tanto, selecionamos um projeto de DSR realizado com um grande
banco comercial que estudou difusão e adoção de TI [23]. Este caso foi
selecionado por vários motivos. Os detalhes do estudo original foram
publicados em outro lugar. Tivemos acesso ao material de apoio, aos
participantes e à experiência do caso original. Este caso usou uma
abordagem de pesquisa-ação orientada para o design que o torna um
candidato para consideração como pesquisa de melhoria, um dos
primeiros exemplos de um tipo de estudo da ciência do design. Finalmente,
como um caso de pesquisa-ação, também nos permite distinguir como a
orientação da ciência do design do Soft DSR diferiria (ou melhoraria) de
um estudo de pesquisa-ação. O contraste entre Soft DSR e pesquisa-
ação também fornece
Machine Translated by Google
insights sobre os contrastes entre a pesquisa-ação e a ciência do design em geral.
O caso envolve o Danske Bank, um grande banco europeu com mais de 20.000
funcionários. O banco operava uma grande divisão de TI, a Danske Data, que
desenvolve aplicativos para bancos e seguros. Principalmente os aplicativos devem
ser executados em um mainframe, mas alguns aplicativos são para Internet
banking, ambientes cliente/servidor e PCs. Os sistemas de mainframe da Danske
Data estão funcionando 24 horas por dia, e todos os dias 9 milhões de transações
são realizadas em 11.000 estações de trabalho.
Os desenvolvedores geralmente têm formação em TI em nível de bacharel ou têm
experiência em serviços bancários. Recentemente, cada vez mais funcionários
com mestrado foram contratados.
Para fins de avaliação da pesquisa em termos de Soft DSR, organizaremos uma
avaliação dos eventos na pesquisa de acordo com as etapas do Soft DSR na
Figura 5.
Soft DSR Passo 1: O problema específico
A partir de uma avaliação combinada do Capability Maturity Model [24] e Bootstrap
[25], ficou claro que muitos produtos e processos desenvolvidos pelo departamento
de TI não foram difundidos e adotados como pretendido. O relatório de avaliação
dizia: “Por que tantos produtos e procedimentos são bem descritos, mas não são
usados?” Este entendimento específico do problema foi identificado e delineado e
a necessidade de uma solução implícita.
Avaliação da Etapa 1
Essa etapa inicial é muito comum tanto para projetos de pesquisa-ação quanto
para projetos de design science. A situação-problema básica é claramente definida
em tais abordagens pragmáticas de pesquisa.
Soft DSR Step 2: O conjunto específico de requisitos
O relatório de avaliação sugeriu que o Danske Bank deveria fazer uma análise
mais aprofundada da difusão e adoção, o que foi feito posteriormente. Pessoas
perspicazes de todas as partes da organização, incluindo gerentes de projeto,
gerentes de linha e pessoas do departamento de metodologia, concordaram em
fazer parte de uma força-tarefa. Em duas oficinas, a força-tarefa diagnosticou o
problema de difusão e adoção. A causa da difusão e adoção inadequadas foi
reduzida a uma série de questões.
O problema a ser resolvido foi expresso como um conjunto específico de requisitos:
1. É um requisito para garantir a difusão e adoção de produtos e processos de
projetos de TI no Danske Bank.
2. É um requisito que o projeto individual assegure que seu novo produto será
usado conforme o esperado quando for concluído
Avaliação da Etapa 2
Esta etapa foi bem pensada e cuidadosamente executada por meio de oficinas
participativas. Os requisitos específicos parecem explícitos e válidos.
Soft DSR Passo 3: O problema geral
Como o empreendimento no Danske Bank fazia parte de um projeto de pesquisa
financiado externamente chamado “Centro de Melhoria do Processo de Software”,
houve inúmeras tentativas de esclarecer e especificar o problema geral (cf. [23]).
No entanto, não houve tradução explícita formalizada dos requisitos específicos
em uma declaração de problema geral sobre uma classe de problemas. Depois de
estudar o problema, os pesquisadores consultaram a literatura sobre difusão e
adoção e encontraram inspiração para uma abordagem de estrutura. A abordagem
de estrutura oferece um processo para implementação organizacional de inovações
de TI (descrito abaixo). Essa abordagem incorpora a natureza teórica da pesquisa-
ação. Essa abordagem implica que o problema geral com a difusão da inovação
em TI foi percebido como processos de implementação de inovação desorganizados
e incompletos.
Avaliação da Etapa 3
A generalização do problema não foi explicitamente abordada no projeto de
pesquisa. É uma suposição óbvia, semelhante a um “warrant” toulminiano que
modifica a tradução dos requisitos específicos para os requisitos gerais [26]. Um
problema generalizado claro e explicitamente declarado teria melhorado a base
lógica para a solução e possivelmente poderia ter modificado os requisitos, se
essa declaração de problema geral tivesse sido explicitada. Declarações mais
generalizadas (não específicas do Danske Bank) seriam:
1. É um requisito para garantir a difusão e adoção de produtos e processos de
projetos de TI em geral.
2. É um requisito que os projetos individuais assegurem que o que
eles produzem são usados como esperado.
Soft DSR Step 4a: Procurar componentes gerais de uma solução
O projeto de pesquisa teve um processo de busca explícito e bastante rigoroso
dos componentes disponíveis da solução geral. Este processo de busca envolveu
oficinas adicionais e o desenvolvimento de uma sub-força-tarefa. Para responder
aos problemas específicos, a infraestrutura do projeto foi alterada de uma força-
tarefa de 12 pessoas para um pequeno grupo de três (sendo um deles o autor
deste artigo), cada um trabalhando metade de seu tempo disponível. O processo
se desenrolou como uma segunda oficina um mês depois, que identificou várias
soluções para os problemas.
A subforça, ao estudar os sucessos e fracassos da organização no primeiro
workshop, percebeu que as tentativas de garantir a difusão adicionando algumas
atividades adicionais no final do projeto geralmente falham. O grupo concluiu que
iniciar tais tentativas no início do projeto teria um efeito no próprio produto.
O principal componente para tal solução poderia ser um framework a ser utilizado
em um workshop de um dia para projetos com foco na difusão e adoção logo após
a definição dos requisitos para um determinado produto.
A evidência de que tal workshop de um dia era promissor foi um esforço de difusão
anterior (incomum) bem-sucedido. Esse esforço incluiu um workshop de análise
para reunir clientes e desenvolvedores para um acordo sobre o escopo e os
requisitos. Também significava
Machine Translated by Google
que os projetos dentro do Danske Bank estavam familiarizados com o
conceito de workshop facilitado de 1 dia.
Avaliação da Etapa 4a
O processo de busca por componentes da solução geral fica evidente nos
relatórios de pesquisa. Muito tempo e esforço foram investidos nessa
atividade de pesquisa específica. Foram identificados muitos componentes
alternativos (candidatos) que acabaram não sendo utilizados como parte da
solução específica. Os componentes incluídos na solução incluem o formato
do workshop, a estrutura e o cronograma inicial do workshop. Esse processo
de pesquisa se encaixa bem com o Soft DSR.
Soft DSR Passo 4b: Lógica imperativa
Como projeto de pesquisa-ação, não surpreende que não haja referência
explícita à lógica imperativa. A noção de lógica imperativa é mais forte na
ciência do design. No entanto, podemos expressar prontamente os
componentes da solução em termos imperativos:
1. Realizar uma reunião de planejamento da difusão da inovação em formato
de workshop.
2. O workshop deve ser realizado no início do processo do projeto.
3. Siga uma estrutura clara para o workshop.
Avaliação da Etapa 4b
Embora a solução geral implique esses três imperativos, não houve uma
busca imperativa explícita pelos melhores componentes da solução. Dadas
as questões problemáticas com a lógica imperativa, Simon [27] descreve a
condução do processo de busca procurando por soluções através de
declarações declarativas. Por exemplo, considere as declarações
contrastantes,
1. “Um workshop inicial leva à difusão e adoção de TI.”
2. “Um workshop atrasado leva à difusão e adoção de TI.”
3. “Um workshop a qualquer momento leva à difusão e adoção de TI.”
Dessas três declarações, os pesquisadores observaram explicitamente que
(2) não levaria a uma solução viável. Logicamente, esse fato implica que (3)
não é válido. Portanto (1) é a única declaração viável e pode ser expressa
como o segundo imperativo na expressão da solução.
Também não houve consideração da solução geral, ao invés do problema
específico no Danske Bank. A consideração da generalidade na etapa 4 do
Soft DSR pode ter guiado esses pesquisadores para permitir configurações
organizacionais diferentes daquela em questão. Por exemplo, pode ser que
em algumas outras configurações, a declaração (2) ou (3) funcione bem. Se
essas declarações forem válidas, o imperativo dois mudaria para “O workshop
deve ser realizado no momento ideal do processo do projeto”. Os significados
alternativos de “ideal” podem ser declarados e pesquisados na Etapa 6 (a
busca de solução específica).
Dessa forma, o Soft DSR teria guiado os pesquisadores a uma consideração
mais aprofundada do grau em que os requisitos gerais eram
desnecessariamente específicos para o problema imediato. Claramente, a
solução específica é apropriada para o Danske Bank, mas a generalidade
dos resultados da pesquisa poderia ter sido melhorada pela metodologia
Soft DSR.
Soft DSR Passo 4: Os requisitos gerais
Como na Etapa 3, a pesquisa avançou em direção à sua solução geral sem
expressar especificamente a solução geral em termos de requisitos gerais.
Em vez disso, a solução geral é expressa em termos de problemas
remanescentes, que podem substituir bem os requisitos gerais e como uma
solução geral que é facilmente traduzida em imperativos.
Avaliação da Etapa 4
Comparado com o Soft DSR, as descrições da pesquisa fazem uma rápida
progressão da descrição do problema específico para uma solução
específica. Isso não é necessariamente inapropriado para a pesquisa-ação,
que às vezes pode assumir a natureza de um protótipo de solução. Em
algumas configurações, alterar rapidamente qualquer coisa pode fornecer
aprendizado adicional sobre a configuração do problema. Pode ser que os
pesquisadores estivessem adotando um ritmo moderadamente rápido neste
projeto de pesquisa-ação, usando o devido cuidado em fundamentar sua
solução para dados coletados e literatura de referência, mas evitando
atrasos desnecessários envolvidos na estruturação de seu trabalho abstrato.
O uso do Soft DSR teria levado em consideração mais recursos de pesquisa
para expressar o problema geral e a solução geral.
Soft DSR Step 5: Comparação dos requisitos gerais com o problema
específico
Na maioria das formas de pesquisa-ação, essa comparação é deixada como
uma implicação do planejamento da ação. À medida que o plano de ação é
construído, as lacunas ou incompatibilidades se tornarão mais óbvias. A
principal etapa de comparação é feita na avaliação do resultado da
implementação da ação planejada (ou seja, post hoc). O estudo de pesquisa
em questão não é particularmente diferente. Embora possa não ter sido
explícito, é provável que os pesquisadores estivessem constantemente
comparando o problema e a natureza geral da solução proposta como parte
rotineira do desenvolvimento contínuo da solução.
Avaliação da Etapa 5
Se considerados de uma perspectiva de Soft DSR, os termos do problema
específico e os termos dos requisitos gerais aparecem como comparáveis.
Consulte a Tabela 2.
Tabela 2. Comparação do problema específico e
dos requisitos gerais.
Problema específico da Etapa 2 Requisitos Gerais da Etapa 4 1.
Realizar
1. É um requisito para garantir a uma reunião de planejamento da
difusão e adoção de produtos difusão da inovação em formato
e de projetos de processos de workshop.
Danske de TI no
Bank. 2. O workshop deve ser realizado no
2. É um requisito que o projeto início do processo do projeto.
individual assegure que seu
novo produto será usado 3. Siga uma estrutura clara para o
conforme o esperado quando workshop (os detalhes devem
for concluído. ser determinados).
Machine Translated by Google
O problema específico 1 (garantir a difusão) e o requisito geral 1 (oficina
de difusão) alinham a solução geral com o problema específico. Da mesma
forma, o problema específico 2 (produtos do projeto) e o requisito geral 2
(tempo inicial do projeto) também alinham uma solução geral com o
problema específico. O terceiro requisito inigualável parece sensato como
medida para garantir a aplicabilidade dos outros dois requisitos.
Soft DSR Passo 6: Busca declarativa de solução específica
Simultaneamente com o estudo de casos do Danske Bank, a literatura
sobre difusão e adoção de TI foi trazida, e diferentes autores que analisaram
vários elementos da questão inspiraram a solução específica do Danske
Bank para o problema geral acima.
O foco específico está na estrutura exata para as oficinas.
A solução específica que projetamos tinha três fases denominadas análise,
projeto e planejamento, cada uma abrangendo dois estágios, conforme
mostrado na Figura 6. Os detalhes de cada uma dessas fases e estágios,
incluindo os motivos pelos quais foram adotados como componentes da
solução, são incluído no apêndice ao final deste trabalho.
Figura 6. A solução específica de exemplo.
Avaliação da Etapa 6
O processo de busca de componentes da solução específica é mencionado
nos relatórios de pesquisa, mas não está bem definido. O processo geral
incluiu oficinas iniciais e trabalhos posteriores na biblioteca e inspiração da
equipe de pesquisa menor. Os componentes da solução específica parecem
ter surgido principalmente desta última parte não estruturada do estudo.
Aprendemos com os relatórios do estudo por que os componentes foram
selecionados e como eles deveriam operar, mas parece que foi dada pouca
atenção exatamente como a busca na literatura e o processo de seleção
foram conduzidos. Por exemplo, não está claro nos relatórios quais
componentes foram considerados e rejeitados, nem quais foram os critérios
para o processo de seleção. Seguir a metodologia Soft DSR teria levado
os pesquisadores a considerar os processos de busca com mais cuidado e
prestar mais atenção aos critérios de seleção de componentes. É provável
que uma pesquisa mais ampla pudesse ter produzido componentes mais
viáveis e esses componentes poderiam ter sido descritos e expressos com
mais cuidado. A solução seria
provavelmente foram melhorados por essa atenção aos detalhes e pelo
desenvolvimento de mais diversidade.
Por causa da estrutura de pesquisa-ação, em vez de uma abordagem Soft
DSR, é difícil distinguir o desenvolvimento da solução específica do
desenvolvimento da solução geral. Até certo ponto, a única distinção clara
é que a solução específica, a estrutura, é especificada com mais detalhes.
De fato, é difícil dizer se a estrutura de processo mais detalhada
desenvolvida acima é geral (aplicável amplamente, não apenas no Danske
Bank) ou ajustada especificamente no Danske Bank.
A consideração dos detalhes de como “Seguir uma estrutura clara para o
workshop” (requisito geral 3 da etapa 2) poderia ter sido mais
apropriadamente considerada na etapa 4 e, em seguida, combinada com
os requisitos específicos da etapa 5.
Nem a lógica imperativa (nos requisitos gerais) nem a lógica declarativa (na
solução específica) são expressas nos relatórios de pesquisa. Podemos
traduzir os componentes da estrutura proposta na Figura 6 em sete
declarações imperativas:
1. Tenha três fases no workshop: análise, design e
planejamento 2. Na fase de análise, caracterizar a implementação
projeto
3. Na fase de análise, decida as funções de implementação 4.
Na fase de design, decida a estratégia de implementação 5. Na
fase de design, determine o produto como um todo 6. Na fase
de planejamento, determine os riscos de implementação 7. Na fase
de planejamento, descreva plano de implementação
Estes parecem estar alinhados com a declaração imperativa 3 decorrente
da etapa 4 (conforme observado acima), pois são bastante claros e,
considerados em conjunto, constituem uma estrutura para o workshop de
planejamento da difusão da inovação. No entanto, a progressão perfeita
das soluções gerais para as específicas mostradas não é necessariamente ideal.
A consideração de declarações declarativas alternativas pode ter levado a
etapas alternativas para a estrutura detalhada. Por exemplo, o imperativo
quatro (decidir a estratégia de implementação) pode ser expresso
declarativamente como,
1. “Decidir a estratégia de implementação na fase de projeto
leva à difusão e adoção da TI.”
Se os pesquisadores estivessem seguindo o Soft DSR, outros valores para
esta declaração deveriam ter sido pesquisados explicitamente, como,
2. “Decidir a estratégia de implementação na fase de análise
leva à difusão e adoção de TI.”
3. `“Decidir a estratégia de implementação na fase de
planejamento leva à difusão e adoção de TI.”
É provável que os pesquisadores tenham levado em consideração a ideia
representada por essas declarações alternativas, mas a importância do
processo de busca no Soft DSR os teria levado a um processo mais formal
e cuidadoso de consideração de declarações alternativas. Como resultado,
um conjunto mais diversificado de soluções alternativas pode ter sido mais
claramente considerado pelos pesquisadores e possivelmente outras
decisões de design feitas sobre a estrutura de organização do workshop.
Machine Translated by Google
Soft DSR Passo 7: Construir solução
Os pesquisadores projetaram claramente a solução específica (que pode
ser interpretada como uma instância de uma solução geral) e a implantaram
em projetos bancários. Como esse era um projeto de pesquisa-ação
orientado ao design, a solução foi aprimorada em cinco iterações. A
implantação inicial em um projeto real do Danske Bank resultou em vários
ajustes, e houve ajustes adicionais após uma segunda iteração em dois
outros workshops de projetos. Após a terceira iteração, a estrutura e o
workshop evoluíram para um formato aceitável para projetos internos.
Uma quarta e uma quinta iteração foram realizadas um ano depois para
adaptar a estrutura a projetos externos – ou seja, projetos envolvendo
clientes do Banco ou fora do Banco.
Dessa forma, o problema específico foi alterado e aprimorado quatro
vezes, ilustrando a natureza cíclica e iterativa da ciência do design.
Avaliação da Etapa 7
Tanto a pesquisa-ação quanto o Soft DSR são abordagens iterativas para
a pesquisa. Cada um envolve uma série de fases. O relatório de pesquisa
não é claro sobre a natureza dos ajustes resultantes das iterações. De
fato, é possível que aspectos da solução relatada sejam aqueles que
resultaram de refinamentos de várias iterações, ao invés de resultados de
uma busca inicial de solução.
Em termos de extensão do relatório, os pesquisadores provavelmente
estão relatando a estrutura final, e não a inicial. No entanto, o relatório
sugere que os ajustes foram direcionados para a solução específica e não
está claro se o problema geral ou os requisitos gerais foram revistos.
Poderia ser óbvio que a solução geral estava funcionando e o esforço
extra para reexaminar as abstrações era simplesmente desnecessário.
Em outras palavras, as iterações podem simplesmente ter passado pelas
Etapas 1, 6 e 7, em vez das Etapas 1–7. O Soft DSR pode ter melhorado
o processo de pesquisa adicionando ênfase à necessidade de reexpressar
constantemente o problema específico após a necessidade de ajustes e
reavaliar o problema geral, seus requisitos e sua relação com os problemas
específicos.
CONCLUSÃO
A revisão de um estudo DSR publicado, que usou um caso de pesquisa
de ação orientada para o design, desenvolveu uma série de insights
importantes sobre as semelhanças e diferenças entre as duas abordagens.
Com foco em possíveis melhorias no estudo de pesquisa que possam ter
ocorrido com o uso do Soft DSR, desenvolvemos evidências de seu
provável sucesso como metodologia em um estudo de pesquisa futuro. A
análise identificou semelhanças, diferenças ambíguas, melhorias prováveis
e possíveis desvantagens.
Semelhanças. O estudo de pesquisa de ação orientado ao design
examinado neste artigo compartilha algumas semelhanças claras com o Soft DSR. publicado que usou pesquisa-ação orientada para o design. A análise
Consistente com os ideais da Soft Design Science, o projeto de pesquisa-
ação parecia abordar a definição do problema com o objetivo de clareza e
especificidade. Requisitos explícitos, válidos e específicos são ideais em
ambas as abordagens. O projeto DSR de pesquisa-ação orientada ao
design também se envolveu em um processo de busca de soluções muito
importante e documentado. Também houve uma boa correspondência
entre o problema específico e os requisitos gerais gerados no estudo de
pesquisa-ação. esta partida
também é ideal para Soft DSR. A natureza iterativa do projeto de pesquisa-
ação também foi apropriada para o Soft DSR.
Diferenças Ambíguas. O estudo de pesquisa-ação examinado neste artigo
também é diferente do Soft DSR de várias maneiras.
No entanto, não está claro que todas as diferenças são melhorias. Por
exemplo, o estudo de pesquisa-ação orientado para o design não distinguiu
claramente os vários estágios de desenvolvimento da solução, como seria
de se esperar com o Soft DSR. Como resultado, a distinção entre os
requisitos gerais e a solução específica poderia ter sido mais clara. Embora
essa seja uma diferença entre o Soft DSR e o projeto estudado, pode ser
que essa busca por uma solução específica e contínua, sem identificar um
problema e uma solução geral, seja apropriada em alguns cenários de
pesquisa (por exemplo, onde o tempo é essencial ) e outras configurações
(por exemplo, onde uma solução ideal, de alta qualidade ou ótima é crítica)
podem se beneficiar das distinções.
Melhorias prováveis. Algumas diferenças provavelmente teriam melhorado
nos resultados do estudo se o Soft DSR tivesse informado a abordagem
da pesquisa. Ao mudar para o design thinking, uma investigação explícita
sobre o problema geral estava faltando no estudo de pesquisa-ação. A
Soft Design Science envolveria uma explicação mais cuidadosa do
problema geral, e esse detalhe adicional poderia ter mudado ou melhorado
a direção da pesquisa. Além disso, a Soft Design Science teria promovido
mais estrutura no processo de busca tanto para requisitos gerais quanto
para soluções específicas, usando expressamente declarações imperativas
e lógica declarativa. Particularmente no nível dos requisitos gerais, é bem
possível que os pesquisadores tenham obtido insights mais claros sobre a
generalidade da solução abordada pelos requisitos. No nível de pesquisa
específico, a estrutura adicionada pode ter permitido que a pesquisa
descobrisse mais componentes alternativos para a solução específica. O
Soft DSR também pode ter melhorado o projeto de pesquisa-ação,
revisando constantemente as representações específicas e gerais dos
espaços de problema e solução. Essa comparação pode detectar
mudanças nas construções subjacentes que, de outra forma, poderiam ter
sido perdidas no projeto de pesquisa-ação.
Possíveis Desvantagens. Um terceiro tipo de diferença oferece uma visão
de como o uso de Soft DSR para informar o estudo de pesquisa-ação pode
de fato ter degradado seus processos e resultados. Fica claro a partir da
avaliação do Soft DSR do estudo de pesquisa-ação que há mais estruturas
incorporadas na metodologia mais elaborada. Embora ofereça rigor, essa
estrutura adicional também pode sobrecarregar os pesquisadores com
complexidade adicional em suas tarefas.
Este artigo propôs uma Metodologia Soft DSR, que incorpora aspectos da
Metodologia Soft Systems em um processo DSR. A metodologia proposta
tem algumas semelhanças com a pesquisa-ação orientada para o design.
O artigo analisa uma aplicação hipotética de Soft DSR a um estudo DSR
identifica semelhanças e diferenças, incluindo prováveis melhorias e
algumas possíveis desvantagens.
No geral, as melhorias potenciais enumeradas acima fornecem uma
indicação positiva do valor potencial do uso de abordagens Soft DSR. Com
base nas evidências deste estudo, pesquisas futuras são necessárias para
desenvolver e usar o Soft DSR
Machine Translated by Google
metodologia como uma abordagem para projetar a pesquisa científica. A pesquisa
que aplica o Soft DSR em um novo ambiente com um novo objetivo de pesquisa
forneceria uma avaliação naturalista para complementar a análise artificial
apresentada neste artigo. As evidências neste artigo também sugerem que
pesquisas futuras sobre a metodologia DSR podem fornecer abordagens alternativas
para permitir DSR mais cuidadoso e completo.
APÊNDICE: ESTRUTURA DO WORKSHOP
DETALHES
Esta seção fornece detalhes do estudo de caso.
A componente de análise tem duas fases. Primeiro, nos concentramos em uma
série de perguntas para caracterizar o projeto. O objetivo era criar um entendimento
comum do produto que seria o resultado de um determinado projeto de TI. Aqui,
nossa pesquisa resultou em um conjunto de perguntas de [28]. Em segundo lugar,
focamos em quem estava desempenhando quais papéis na difusão e adoção do
resultado do projeto. Aqui desenhamos um modelo inspirado em CATWOE [4] e
[29]. A ideia principal do modelo de função que projetamos é que cinco funções
devem ser preenchidas para que a implementação seja bem-sucedida. Se uma das
funções não for preenchida, a implementação falhará. Os cinco papéis eram:
1. O grupo-alvo são as pessoas que vão usar o
produtos
2. O proprietário/patrocinador é responsável por iniciar o
implementação e escopo da direção. No final da implementação, o
proprietário/patrocinador também é responsável por exigir os resultados
resultantes da implementação.
3. O gerente de implementação é a pessoa que faz o
trabalho de implementação real. Freqüentemente, essa função é chamada
de gerente de projeto.
4. O campeão/embaixador são as pessoas que realmente
faz com que as pessoas do grupo-alvo levem a inovação
em uso.
5. "Outras partes interessadas secundárias" consiste em todas as outras
partes interessadas que não assumem nenhum dos quatro papéis principais.
O componente de design também consiste em duas etapas. Primeiro, tentamos
definir “o produto como um todo”. A ideia por trás de “todo o produto” é que o usuário
de um novo produto normalmente espera obter mais do que uma mera solução
técnica. Portanto, estamos trabalhando com três níveis de produto [30]:
1. O produto principal 2. O
produto completo 3. O produto
expandido
O produto principal é a ideia dos desenvolvedores sobre o que eles devem preparar
para oferecer aos clientes o que prometeram. Por exemplo, um desenvolvedor que
vai desenvolver um sistema de HomeBanking pode considerar o programa de
computador como o produto principal.
O produto inteiro é a ideia do cliente sobre o que ele obterá - ou seja, o produto
principal, incluindo produtos complementares relacionados para garantir que o
produto seja fácil de usar. Ou seja, um cliente que está
a compra de um sistema HomeBanking espera obter os discos com o programa,
além de um guia rápido, suporte telefônico de linha direta e um tutorial.
O produto expandido não é relevante até que todo o produto tenha sido colocado
em operação e o cliente ou desenvolvedor sugira complementar o produto existente
com um serviço adicional. Por exemplo, o cliente pode desejar que o sistema
HomeBanking também inclua um recurso de cálculo de impostos.
Em segundo lugar, examinamos como organizar a implementação do produto. O
objetivo é, em parte, esclarecer que tipo de produto devemos fazer para melhorar
as chances de sucesso na implementação. E em parte para criar uma estrutura para
um plano de implementação que possa ser usado na fase subsequente.
Para tanto, utilizamos uma teoria sobre estratégias de implementação desenvolvida
por Ken Eason [31]. A teoria compreende cinco estratégias diferentes, desde a
estratégia mais revolucionária – onde os usuários abandonam seu antigo sistema
um dia e adotam o novo sistema no dia seguinte – até a abordagem mais
evolucionária onde os usuários ao longo de meses ou anos, pouco a pouco , comece
a usar cada vez mais o novo sistema. As cinco estratégias de Eason são chamadas:
1. Big Bang 2.
Aplicação paralela
3. Introdução faseada
4. Difusão experimental 5.
Experimento baseado no usuário
Semelhante às duas fases anteriores, esta fase também possui duas etapas: uma
análise de risco e uma etapa de planejamento de implementação. Na primeira fase
da fase de planejamento, realizamos uma análise de risco para garantir que não
deixamos de lado nenhum problema potencial. A gestão de riscos lida com a
identificação e reação a problemas potenciais em tempo hábil [32]. A gestão de
riscos geralmente leva a atividades proativas. Em nossa análise de risco, nos
concentramos nas seis questões a seguir:
1. Identifique os riscos. Aqui usamos uma lista padrão dos dez maiores riscos
na organização com base na própria experiência da organização.
2. Avalie a probabilidade de cada risco em uma escala de um a
cinco.
3. Avalie a consequência de cada risco em uma escala de um a
cinco.
4. Faça uma lista de prioridades multiplicando a probabilidade por
consequência.
5. Encontre atividades – proativas ou de apoio – relacionadas aos três riscos
mais importantes.
6. Liste as atividades escolhidas como itens que devem ser incluídos no
o plano de implementação.
A segunda etapa é delinear um plano de implementação. Durante o workshop todas
as atividades mencionadas pelo grupo do projeto estão sendo anotadas em
pequenas notas. Essas anotações – que são atividades de implementação
apropriadas – agora são colocadas em um quadro-negro ou em um
Machine Translated by Google
tabela onde os benchmarks e os estados intermediários são delineados.
A última etapa do workshop fornece ao grupo do projeto um bom esboço
do plano de implementação. Pode ser aplicado diretamente em conexão
com a estimativa da fase de implementação e como entrada para o plano
de projeto e o plano de implementação final do projeto.
AGRADECIMENTOS
Gostaríamos de agradecer aos revisores anônimos por seus comentários
úteis, que nos permitiram melhorar este artigo.
REFERÊNCIAS
[1] Baskerville, R., Pries-Heje, J. e Venable, J. Soft Design Science
Research: Estendendo os limites da avaliação na Design Science
Research. Claremont Graduate University, Pasadena, 2007.
[2] Checkland, P. Sistemas de Pensamento, Prática de Sistemas. J. Wiley,
Chichester, 1981.
[3] Checkland, P. e Holwell, S. Informação, Sistemas e Sistemas de
Informação: Fazendo Sentido do Campo. John Wiley, Chichester, 1998.
[4] Checkland, P. e Scholes, J. Soft Systems Methodology in Practice. J.
Wiley, Chichester, 1990.
[5] Iivari, J. Uma análise paradigmática dos Sistemas de Informação como
ciência do design. Jornal escandinavo de sistemas de informação, 19, 2
(2007), 39-63.
[6] March, ST e Smith, GF Design e pesquisa em ciências naturais sobre
tecnologia da informação. Decision Support Systems, 15, 4 (dezembro de
1995), 251-266.
[7] Gregor, S. e Jones, D. A anatomia de uma teoria de design.
Jornal da Associação de Sistemas de Informação, 8, 5 (2007), 312-335.
[8] Walls, JG, Widmeyer, GR e El Sawy, OA Construindo uma teoria de
design de sistema de informação para EIS vigilante. Information Systems
Research, 3, 1 (1992), 36-59.
[9] Hevner, AR, March, ST, Park, J. e Ram, S. Design Science In
Information Systems Research. MIS Quarterly, 28, 1 (março de 2004),
75-105.
[10] Pries-Heje, J., Venable, J. e Baskerville, R. Estratégias para Avaliação
de Pesquisa em Ciência do Design. In Actas da 16ª Conferência Europeia
sobre Sistemas de Informação (ECIS 2008)
(Galway, Irlanda, 9-11 de junho de 2008). Universidade Nacional da Irlanda.
[11] Mason, R. e Carey, T. Prototipagem de sistemas de informação
interativos. Communications of The ACM 26 (1983), 347-354.
[12] Ehn, P. Projeto orientado para o trabalho de artefatos de computador.
Arbetslivscentrum, Estocolmo, 1988.
[13] Baskerville, R. e Stage, J. Prototipagem. Berkshire Publishing Group,
Great Barrington, MA, 2004.
[14] Porra, J. Sistemas coloniais. Information Systems Research, 10, 1
(Mar 1999 1999), 38-70.
[15] Baskerville, R. e Wood-Harper, AT Diversity in Information Systems
Action Research Methods. European Journal of Information Systems, 7, 2
(1998), 90-107.
[16] Järvinen, P. Action Research is Similar to Design Science Qualidade
e Quantidade 41, 1 (2007), 37-54.
[17] Cole, R., Purao, S., Rossi, M. e Sein, MK Sendo proativo: onde a
pesquisa-ação encontra a pesquisa em design.
Association for Information Systems, Las Vegas, Nevada, EUA, 2005.
[18] Sein, MK, Henfridsson, O., Purao, S., Rossi, M. e Lindgren, R. Action
Design Research: A Methodology For Design Of Artifacts In Context,
Kristiansand, Noruega, 2009.
[19] Iivari, J. e Venable, J. Action Research e Design Science Research –
Aparentemente semelhantes, mas decididamente diferentes.
In Actas da Conferência Europeia sobre Sistemas de Informação de 2009
(ECIS 2009) (Verona, Itália, 8-10 de Junho de 2009).
[20] Brown, T. Design Thinking. Harvard Business Review, 86, 6 (2008),
84-93.
[21] Lee, AS e Baskerville, RL Generalizando a generalização na pesquisa
de sistemas de informação. Pesquisa de Sistemas de Informação, 14, 3
(2003), 221-243.
[22] Venable, J. Uma estrutura para atividades de pesquisa em ciência do
design. In Proceedings of the Information Resource Management
Association Conference 2006 (Washington, DC, EUA, 2006).
[23] Pries-Heje, J. e Tryde, S. Difusão e adoção de produtos e processos
de TI em um banco dinamarquês. In Proceedings of the Difusing Software
product and Process Innovations. IFIP TC8 WG 8.6 Quarta Conferência
de Trabalho (Banff, Canadá, abril de 2001).
[24] Paulk, MC, Weber, C., Curtis, B. e Chrissis, MB O Modelo de
Maturidade de Capacidade: Diretrizes para Melhorar o Processo de
Software. Addison-Wesley, Reading, Massachusetts, 1995.
[25] Kuvaja, P., Similä, J., Krzanik, l., Bicego, A., Saukkonen, S. e Koch,
G. Software Process Assessment & Improvement. A Abordagem
BOOTSTRAP. Blackwell Publishing, Oxford, Reino Unido, 1994.
[26] Toulmin, S. Os usos do argumento. Cambridge University Press,
Cambridge, 1958.
[27] Simon, HA A Ciência do Artificial. MIT Press, Cambridge,
Massachusetts, 1996.
[28] Mathiassen, L. e Sørensen, C. Um guia para gerenciar novas
ferramentas de engenharia de software. Chapman & Hall, Londres, 1997.
[29] Bendix, J. e Andersen, OS Change Management - Comunicação,
Comportamento e Cooperação ("Change Management - Communication,
Behavior and Cooperation"). Børsens Forlag, Copenhagen, 1995.
[30] Moore, G. Crossing the Chasm: Marketing e venda de produtos de
tecnologia para clientes convencionais. Capstone, Mankato, 1991.
[31] Eason, K. Tecnologia da Informação e Mudança Organizacional.
Taylor & Francis, Londres, 1988.
[32] Iversen, JH, Mathiassen, L. e Nielsen, PA Gerenciando riscos na
melhoria de processos de software: uma abordagem de pesquisa de ação.
MIS Quarterly, 28, 3 (2004), 395-433.