UM MÉTODO PARA CONSTRUÇÃO DE MODELOS I*
UTILIZANDO DESIGN THINKING
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/ posgraduacao
RECIFE 2016
Um Método para Construção de Modelos i* Utilizando Design Thinking
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
ORIENTADORA: Prof.a Carla Taciana Lima Lourenço Silva Schuenemann
RECIFE 2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S237m Santos, Laino Edemberguer dos
Um método para construção de modelos i* utilizando design thinking / Laino Edemberguer dos Santos. – 2016.
104 f.: il., fig.
Orientadora: Carla Taciana Lima Lourenço Silva Schuenemann.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2016.
Inclui referências e apêndices.
1. Engenharia de software. 2. Engenharia de requisitos. I. Schuenemann, Carla Taciana Lima Lourenço Silva (orientadora). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2017-101
Um Método para Construção de Modelos i* Utilizando Design
Thinking
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação
Aprovado em: 30/08/2016.
BANCA EXAMINADORA
_______________________________________________ Prof. Dr. Jaelson Freire Brelaz de Castro
Centro de Informática / UFPE
_________________________________________________ Prof. Dr. Gilberto Amado de Azevedo Cysneiros Filho
Departamento de Estatística e Informática / UFRPE
___________________________________________________ Profa. Dra. Carla Taciana Lima Lourenco Silva Schuenemann
Centro de Informática / UFPE
A Deus que, com seu amor sublime, nos deu a vida.
A Universidade Federal de Pernambuco – representada pelo corpo docente, admi-nistradores e os demais servidores – que me ofertou um ambiente propício ao aprendizado, disseminação e aprimoramento da ciência.
A professora Dra. Carla Silva, que me orientou com afinco durante todo o meu mestrado, como também pela confiança na minha capacidade científica.
Aos meus pais, Erivan Santos e Germania Santos, que me educaram com amor e me incentivaram, incondicionalmente, nas minhas escolhas profissionais e acadêmicas.
Aos meus avós – Amaro Santos (in memoriam), Manoel Oliveira, Maria Conceição, Sebastião Silva (in memoriam) e Maria Silva (in memoriam) – que, pelas experiências deles na vida, me guiaram pelo caminho do bem.
Aos familiares pela compreensão que tiveram nos momentos em que me ausentei de encontros da família, assim como por todo incentivo que me deram para que eu seguisse firme neste propósito.
A minha esposa, Bianca Nascimento, por estar ao meu lado nos momentos difíceis desta caminhada e por me ajudar a transformar mais este sonho em realidade.
Aos amigos, pela paciência de conversarem constantemente sobre este assunto e pelas críticas sinceras acerca deste trabalho.
A todos que direta ou indiretamente contribuíram para minha formação profissional ou acadêmica.
você antes precisa ter muitas ideias.” (Linus Pauling)
Pode-se agregar criatividade em produtos de software para diferenciá-los no meio das várias soluções concorrentes presentes no mercado, para melhorar a interação entre eles e os usuários e até mesmo com o objetivo de repensar (redesenhar) as regras dos domínios aos quais estão inseridos. No entanto, os processos criativos demandam atividades específicas diferentes daquelas exigidas pelos processos de software e produzem resultados que são difíceis de serem expressos e gerenciados como requisitos de software. A Engenharia de Requisitos possui métodos eficazes para buscar, representar, validar e gerenciar os objetivos que os stakeholders buscam num software demandado, como por exemplo o framework orientado a objetivos i*. Este trabalho dá continuidade aos esforços recentes de outros autores em unir criatividade e i*, a fim de propiciar que os resultados dos processos criativos possam ser transformados em modelos i* para serem usados como entrada para as atividades da engenharia de requisitos, haja vista os resultados dos métodos criativos serem difíceis de ser especificados formalmente. É importante destacar que este é o primeiro método proposto que busca fazer essa integração utilizando uma metodologia criativa amplamente difundida e fundamentada, o Design Thinking. Nesta abordagem, é definido um método para a construção colaborativa entre os stakeholders de modelos i* criativos, a partir da aplicação do Design Thinking. Em outras palavras, o método proposto especifica de forma lógica e interconectada, como, quando e por que executar técnicas e conceitos do Design Thinking, a fim de se criar modelos i* que representem os aspectos criativos levantados. A proposição deste método foi guiada pelo método científico pesquisa-ação, de modo que o arcabouço teórico, aliado às ações e interações sociais, possibilitaram fundamentar e testar formas eficazes de construir modelos i*, a partir da aplicação do Design Thinking. Holisticamente, o método está baseado nos estágios de inspiração, ideação e implementação do Design Thinking, exige uma postura de facilitador para o engenheiro de requisitos no processo criativo; define ferramentas e propicia um ambiente que possibilitam a colaboração entre os stakeholders e apontam momentos propícios para fomentar o pensamento criativo. Outro aspecto deveras relevante deste método é a possibilidade de stakeholders não técnicos fazerem parte do processo de construção dos modelos i* criativos. Isso porque a modelagem i* é considerada complexa e requer experiência e conhecimento consolidado do framework. Para amenizar essa complexidade, este método propõe que a construção de modelos i* guiado pelo Design Thinking se dê da definição de modelos mais abstratos e flexíveis até a adaptação e o refinamento para modelos i* válidos.
Palavras-chave: Engenharia de requisitos. Criatividade. Orientação a objetivos. Design
You can add creativity to software products to differentiate them among the various competing solutions on the market, to improve the interaction between them and the users and even in order to rethink (redesign) the rules of the domains to which they belong. However, the creative processes require different specific activities other than those required by software processes and produce results that are difficult to express and manage as software requirements. The Requirements Engineering has effective methods to search, represent, validate and manage the goals the stakeholders aims to achieve in the software-to-be, as for example the i* goal oriented framework. This work continues the recent efforts of other authors to join creativity and i*, in order to enable the results of creative processes can be transformed into i* models to be used as input to the activities of Requirements Engineering, given that the results of creative methods are difficult to formally specify. It is worth to highlight that this is the first method that propose to make this integration using a widespread and grounded creative methodology, the Design Thinking. In this approach, it is defined a method for collaborative construction of creative i* models among stakeholders through the application of the Design Thinking. In other words, the proposed method specifies in a interconnected and logical way, how, when and why to perform techniques and concepts of Design Thinking in order to create i* models representing the discovered creative aspects. The proposition of this method was guided by the reasearch-action scientific method, so that the theoretical framework, combined with social actions and interactions, enabled justifying and testing effective ways to construct i* models from the application of the Design Thinking. Holistically, the method is based on the stages of inspiration, ideation and implementation of the Design Thinking; It requires a facilitator position for the requirements engineer in the creative process, define tools and provides an environment that enables collaboration among stakeholders and suggest favorable moments to foster creative thinking. Another truly important aspect of this method is the possibility of non-technical stakeholders be part of the construction process of creative i* models, this because i* modeling is considered complex and requires experience and consolidated knowledge of the framework. To alleviate this complexity, this method proposes the construction of i* models guided by the Design Thinking starts by the definition of more abstract and flexible models and after by adapting and refining them to valid i* models.
Figura 1 – Notação básica do i* . . . 27
Figura 2 – Possíveis relações no modelo i* . . . 28
Figura 3 – Exemplo de modelo SD . . . 29
Figura 4 – Exemplo de modelo SR. . . 30
Figura 5 – Modelo SD/SR híbrido indicado para aprendizes . . . 32
Figura 6 – Fluxo do processo de Design Thinking . . . 38
Figura 7 – Subprocessos do Creadtivity . . . 45
Figura 8 – Captura de tela do Creative Leaf . . . 50
Figura 9 – Transformação do Diagrama de Contexto para modelo SD . . . 52
Figura 10 – Transformação do Customer Journey Map para modelo SR . . . 53
Figura 11 – Card para uma persona . . . 66
Figura 12 – Modelo da divisão do quadro de modelagem . . . 67
Figura 13 – Ligações entre os elementos no quadro de modelagem . . . 68
Figura 14 – Legenda no quadro de modelagem . . . 69
Figura 15 – Quadro de modelagem preenchido . . . 70
Figura 16 – Estágios do método de construção de modelos i* criativos . . . 73
Figura 17 – Quadro de modelagem usado na avaliação . . . 78
Figura 18 – Quadro de ideação usado na avaliação . . . 78
Figura 19 – Resultado do Brainstorm durante a avaliação . . . 79
Figura 20 – Card de persona preenchido . . . 80
Figura 21 – Resultado do Método 635 durante a avaliação . . . 81
Figura 22 – Modelo abstrato resultante da avaliação . . . 82
Figura 23 – Modelo SD resultante do modelo abstrato . . . 83
Tabela 1 – Principais atributos do Design Thinking . . . 35
Tabela 2 – Comparação entre os estágios das definições distintas de Design Thinking 37
Tabela 3 – Resumo do mapeamento das técnicas de criatividade no Creadtivity . . 46
AVAM Ambientes Virtuais de Aprendizagem Móvel
DT Design Thinking
ER Engenharia de Requisitos
ES Engenharia de Software
LER Laboratório de Engenharia de Requisitos
SD Strategic Dependency
SR Strategic Rationale
TI Tecnologia da Informação
UFPE Universidade Federal de Pernambuco
1 INTRODUÇÃO . . . 15
1.1 Justificativa . . . 16
1.2 Contribuições esperadas . . . 18
1.3 Objetivos geral e específicos . . . 19
1.4 Escopo negativo . . . 19
1.5 Metodologia de pesquisa . . . 20
1.6 Estrutura da dissertação . . . 21
2 FUNDAMENTAÇÃO TEÓRICA . . . 23
2.1 Introdução à Engenharia de Requisitos . . . 23
2.1.1 Criatividade na Engenharia de Requisitos . . . 24
2.2 i*: framework orientado a objetivos . . . 26
2.2.1 Uso do i* em ambientes criativos. . . 32
2.3 Design Thinking: uma metodologia criativa . . . 33
2.3.1 Uso do Design Thinking na criação de software . . . 39
2.4 Considerações finais . . . 41
3 TRABALHOS RELACIONADOS . . . 43
3.1 Uso do Design Thinking para concepção de softwares criativos . . . 43
3.2 Integração de Design Thinking e técnicas de criatividade na elicita-ção de requisitos . . . 45
3.3 Uma ferramenta para integrar modelagem i* e técnicas criativas . . 48
3.4 Uso do i* para suportar a Engenharia de Requisitos criativa . . . 51
3.5 Considerações finais . . . 53 4 METODOLOGIA DE PESQUISA . . . 55 4.1 Planejamento . . . 56 4.1.1 Concepção . . . 56 4.1.2 Amostragem . . . 56 4.1.3 Definição do tema . . . 57
4.1.4 Ameaças à validade interna . . . 57
4.1.5 Hipóteses assumidas . . . 58
4.2 Execução. . . 59
4.3 Resultados . . . 59
4.3.1 O produto. . . 59
5.1 Modelo abstrato . . . 62 5.1.1 Notação abstrata . . . 63 5.2 Papéis . . . 64 5.2.1 Design Thinker . . . 64 5.2.2 Engenheiro de Requisitos . . . 64 5.3 Ferramentas . . . 65 5.3.1 Personas . . . 65 5.3.2 Quadro de modelagem . . . 66 5.3.3 Quadro de ideação . . . 70 5.4 Técnicas . . . 70 5.4.1 Pesquisa. . . 71 5.4.2 Contação de histórias . . . 71 5.4.3 Técnicas criativas . . . 71 5.5 Briefing . . . 72 5.6 Estágios . . . 72
5.6.1 Imersão no universo do problema . . . 73
5.6.2 Imersão no universo das soluções . . . 73
5.7 Transformação do modelo abstrato para o modelo i* . . . 74
5.8 Considerações finais . . . 75 6 AVALIAÇÃO DO MÉTODO . . . 76 6.1 Ameaças à validade . . . 76 6.2 Execução. . . 77 6.2.1 Briefing . . . 77 6.2.2 Estágios . . . 77
6.2.3 Transformação do modelo abstrato. . . 83
6.3 Considerações finais . . . 85 7 CONSIDERAÇÕES FINAIS . . . 86 7.1 Contribuições científicas . . . 87 7.2 Limitações do método . . . 87 7.3 Trabalhos futuros . . . 88 REFERÊNCIAS . . . 89
APÊNDICE A – QUESTIONÁRIO DE AVALIAÇÃO DO MÉTODO PROPOSTO . . . 95
APÊNDICE B – RESUMO DAS AVALIAÇÕES DO MÉTODO PRO-POSTO . . . 97
APÊNDICE C – CARD PARA PERSONAS . . . 99
APÊNDICE D – PROTÓTIPO INICIAL DO QUADRO DE MODE-LAGEM DURANTE A EXECUÇÃO DA PESQUISA-AÇÃO . . . 100
ANEXOS
101
ANEXO A – PROTÓTIPO GERADO DURANTE A EXECUÇÃO DA PESQUISA-AÇÃO . . . 102
ANEXO B – MODELO SD GERADO DURANTE A EXECUÇÃO DA PESQUISA-AÇÃO . . . 103
ANEXO C – MODELO SR GERADO DURANTE A EXECUÇÃO DA PESQUISA-AÇÃO . . . 104
1 INTRODUÇÃO
Engenharia de Requisitos (ER) é a disciplina responsável por elicitar, analisar, documentar e validar os serviços e restrições de um software (SOMMERVILLE, 2011). Quando aplicada com uma perspectiva orientada a objetivos, é possível validar, sob a ótica dos stakeholders, as razões pelas quais os requisitos foram elicitados. Ao evidenciar as aspirações dos stakeholders, a orientação a objetivos ajuda o engenheiro de requisitos a gerenciar os conflitos de interesse existentes no projeto (LAMSWEERDE, 2001).
Segundo Horkoff e Maiden (2015b) em um estudo inicial, a sinergia entre mo-delagem orientada a objetivos e técnicas de criatividade muito tem a contribuir para o desenvolvimento de softwares, visto que daí resultarão softwares que atendem aos objetivos e interesses dos vários stakeholders e que entregam inovação, na forma de valor percebido pelos usuários, advinda do pensamento criativo.
Horkoff e Maiden (2015b) apontam que essa sinergia entre modelagem orientada a objetivos e criatividade traz à ER toda a maturidade da modelagem orientada a objetivos – a qual possibilita analisar, até mesmo com apoio de ferramentas automatizadas, a completude, consistência e validade dos requisitos sob a ótica dos objetivos essenciais e desejados pelos stakeholders – como também agrega o potencial inovador daquelas técnicas criativas aos produtos/serviços – incrementando a competitividade e o valor deles em relação aos produtos concorrentes.
No entanto, o estudo citado acima é necessariamente uma análise inicial, de forma que não define algum método prático e replicável para equipes de desenvolvimento de software na industria de Tecnologia da Informação (TI), limitando-se a trabalhar com conceitos abstratos de criatividade. Portanto, não faz qualquer integração com uma metodologia criativa específica e amplamente usada nos projetos que visam a criatividade.
Diante disto, nosso trabalho consiste em apresentar um método capaz de conduzir uma equipe à elicitação de requisitos criativos e, paralelamente, construir modelos i* que representem as ideias resultantes, tudo isso através da aplicação do Design Thinking.
Design Thinking (DT) é uma metodologia que busca gerar soluções criativas para um problema a partir da aplicação das técnicas e da forma de pensamento utilizadas pelos designers (BROWN, 2010). O DT pode ser visto como uma forma de pensamento complementar à lógica analítica predominante em TI, desta forma, apresenta grande po-tencial em conduzir a equipe à especificação de softwares criativos (LINDBERG; MEINEL; WAGNER, 2011).
Design Thinking” objetiva oferecer diretrizes para engenheiros de requisitos construírem modelos i*, orientados a objetivos, de requisitos criativos colaborativamente junto aos stakeholders. Nosso método se baseia na metodologia criativa DT, desta forma, buscaremos responder as perguntas o que?, como? e por que? aplicar do DT para que se consiga, como produto do método, modelos i* de requisitos criativos.
Especificar um método prático é necessário porque os resultados dos processos criativos são difíceis de serem transformados em requisitos de sistema e de serem analisados, mesmo que manualmente. De outro lado, é difícil conceber modelos i* com usuários não técnicos devido a complexidade da linguagem (HORKOFF,2015; HORKOFF; MAIDEN,
2015a;HORKOFF; MAIDEN,2015b;HORKOFF; MAIDEN; LOCKERBIE, 2015). Esta dissertação, então, é um passo evolutivo e prático para a integração dos domínios i* (modelagem orientada a objetivos) e DT (criatividade).
1.1
Justificativa
Iniciamos nossa justificativa, apontando a assertiva deHorkoff, Maiden e Lockerbie
(2015), na qual dizem que é essencial que softwares sejam tanto funcionais, atendendo as necessidades dos usuários, como inovadores, o que lhes atribui vantagem competitiva.
Já segundoMaiden, Robertson e Robertson(2006), há uma expectativa que a busca por produtos criativos continue a crescer, isso porque eles argumentam que a criatividade é indispensável no projeto de produtos inovadores. Indo além, nos trazem que os requisitos são, então, a abstração-chave que encapsula os resultados dos pensamentos criativos, ou seja, os requisitos devem guardar em suas especificações todas as características e definições resultantes de um processo criativo, a fim de que não se percam ou se desvirtuem.
No entanto, Horkoff, Maiden e Lockerbie(2015) argumentam que os resultados dos processos criativos são difíceis de serem transformados em requisitos de sistema, pois, sendo complexos por natureza, podem não ser claros o bastante para servirem de fundamento para tomada de decisões ao longo do projeto; assim como podem não ser facilmente capturados por pessoas não experts no domínio inerente ao produto ou processo. Se os resultados dos processos criativos são difíceis de serem postos em um documento formal de requisitos, certamente os transformar em modelos i* é bem mais complexo.
Desse modo, há a necessidade de um método que guie esse processo de transformação desses resultados em modelos de requisitos i*, para que seja possível usufruir das vantagens que a modelagem orientada a objetivos possui.
Propor um método para construir modelos i* criativos é claramente justificado quando se percebe que, mesmo sendo evidente que a união da modelagem orientada a objetivos e processos criativos é benéfica para a ER, não há muitos trabalhos científicos que
foquem nisto. Maiden et al.(2010) é vanguardista desse objetivo quando apontou a relação entre requisitos criativos e modelagem orientada a objetivos, ressaltando a necessidade de se criar novas técnicas e ferramentas de apoio. Mas, efetivamente, essa busca só foi iniciada recentemente nos trabalhos de Horkoff e Maiden (2015a), Horkoff e Maiden (2015b) e
Horkoff, Maiden e Lockerbie (2015).
Ainda como justificativa à proposição do nosso método, defende-se que ao desejar requisitos criativos em modelos i* é necessário ter a disposição técnicas e ferramentas que auxiliem o engenheiro de requisitos a diagnosticar quais ideias criativas contribuem e em que intensidade, para que os objetivos dos stakeholders sejam alcançados, ou mesmo prejudicados (MAIDEN et al., 2010).
Nesta mesma linha de pensamento, Horkoff, Maiden e Lockerbie (2015, pág. 4, tradução nossa) ratificam a necessidade de trabalhos que buscam integrar métodos criativos à modelagem i*.
Neste artigo, nós descrevemos o início de um programa de pesquisa que busca explorar a sinergia entre técnicas criativas e modelagem orientada a objetivos para a engenharia de requisitos.
[...]Nós fornecemos exemplos específicos de como técnicas de criatividade podem ser combinadas com modelagem orientada a objetivos para a engenharia de requisitos criativa. [...] Os planos futuros incluem uma maior exploração da combinação de técnicas de criatividade com a mo-delagem orientada a objetivos, incluindo domínios adicionais e técnicas de criatividade ainda mais sinérgicos (por exemplo, brainsketching, role play). Os futuros esforços serão concentrados em fornecer suporte de ferramentas, orientando os usuários através de um processo distribuído de pensamento criativo e modelagem.
Vejamos ainda:
Para tornar requisitos convencionais em criativos precisamos de técni-cas para adicionar novos comportamentos e qualidades – técnitécni-cas que transformem um comportamento ou qualidade necessários em novidade através dos caminhos exploratório, transformacional e combinacional, enquanto ainda contribuam para o alcance dos objetivos. Novas pesquisas são necessárias para desenvolver essas técnicas. (MAIDEN et al.,2010, pág. 9, tradução nossa)
Como pode ser constatado nos trechos transcritos acima, os trabalhos até então estão em uma fase inicial, de modo que não há resultados concretos e replicáveis, diante disto, é preciso que outros estudos continuem a explorar as possibilidades onde possam haver integração entre criatividade e i*. Neste trabalho, buscamos explorar especificamente a integração entre DT e i*.
Outro aspecto que corrobora a necessidade de um método prático é que a modelagem em i* requer experiência moderada com a linguagem, de modo que novatos têm muitas
dificuldades para lidar com os diversos elementos do i* (LAUE et al., 2014;HORKOFF,
2015). Essa dificuldade se agrava quando se trata de usuários não técnicos, o que torna extremamente difícil envolver os stakeholders na construção ou validação do modelo. Stakeholders não técnicos, mesmo depois de treinamento, apresentam dificuldade em entender, quando estão modelando, as atividades e os resultados delas (HORKOFF,2015;
CARVALLO; FRANCH, 2014). Portanto, o método que propomos tem como um dos objetivos diminuir a experiência técnica requerida, a fim de que todos os interessados possam contribuir criativamente pelo seu conhecimento do negócio e não pelo conhecimento técnico na linguagem i*.
Quanto ao DT, justificamos nossa escolha por esta metodologia pela evidência que vários estudos tem dado sobre o potencial criativo trazido à engenharia de requisitos. Ele tem como objetivo propor soluções criativas para problemas complexos, aqueles que envolvem vários interessados e objetivos, tem a natureza colaborativa e é essencialmente centrado no ser humano e sua interação social (BROWN, 2010; MARTIN, 2010). Dessa forma, é complacente com os anseios da ER. Neste contexto, o DT tem o papel de fomentar o pensamento divergente, questionador e abdutivo, podemos dizer que é uma quebra do modelo analítico consagrado nas ciências exatas como a computação. É, portanto, agregar à ER os métodos e ferramentas do mundo do design, o qual está consolidado como eficiente em conceber soluções criativas para problemas desde alguns séculos atrás (LINDBERG; MEINEL; WAGNER, 2011).
1.2
Contribuições esperadas
O método que propomos – resultante da condução de uma pesquisa-ação – se utiliza da metodologia DT para promover o pensamento criativo nos stakeholders, assim como faz valer a expertise do engenheiro de requisitos quando na construção e análise dos modelos i*. Desse modo, nosso método propõe atividades para ambos os papéis, assim como os conduz nas atividades em comum.
Nosso método busca auxiliar projetos que desejam agregar valor inovador – através da concretização de requisitos criativos – e garantir que os usuários tenham seus objetivos satisfeitos e/ou gerenciados. É por este motivo que buscamos integrar estes dois universos. Isso implica dizer que sua aplicação está intrinsecamente ligada a natureza do projeto, pois não achamos que todas as classificações de software possam usufruir plenamente deste método.
1.3
Objetivos geral e específicos
A fim de definirmos os objetivos do nosso estudo, tomamos como premissa a capacidade do DT de gerar soluções criativas (BROWN,2010) – quando considerados seus ensinamentos e quando em ambiente propício à criatividade –, assim como a maturidade e recursos benéficos trazidos à engenharia de requisitos pelo framework i* (YU, 1995).
Tendo isto em mente, nosso objetivo geral é expresso como segue:
• Especificar um método que conduza os stakeholders à construção de modelos i* criativos através da aplicação da metodologia Design Thinking.
Conscientes de que o objetivo geral rege todas as decisões e ações ao decorrer do estudo, mas que não pode ser atingido senão pela plena execução de objetivos menores, seguem abaixo objetivos específicos que almejamos e nos conduziram estritamente ao longo do estudo:
1. Integrar os métodos e ferramentas do Design Thinking ao processo de modelagem i*, de modo a propiciar a criatividade.
2. Diminuir a experiência técnica requerida para os stakeholders não-técnicos durante a construção modelos i* criativos.
3. Propiciar a construção coletiva e colaborativa de modelos i* criativos.
É importante destacar que o engenheiro de requisitos deve possuir expertise em DT para que a condução da equipe e aplicação das técnicas criativas sejam maximizadas, esta necessidade é ratificada pelos autores de DT, como consta no Capítulo 2.
1.4
Escopo negativo
É deveras importante salientar que nosso esforço foi enveredado unicamente para atingir os objetivos previamente citados. Por este motivo, este estudo não busca provar,
ou analisar, sob hipótese alguma o que segue abaixo:
• Provar que o Design Thinking é eficiente na geração de soluções criativas, como, por exemplo, medindo o quão criativos foram os modelos i* gerados.
• Melhorar, estender ou questionar o framework i*.
• Provar que o método proposto é mais eficiente na geração de modelos i* criativos que qualquer outro, mesmo porque as pesquisas desenvolvidas nesta vertente ainda são recentes para análises desta natureza.
Contrariamente a tentar provar o quão eficaz o DT é para gerar ideias criativas, temos o pressuposto – pelo que nos apresentam Lindberg, Meinel e Wagner(2011), Verganti(2006),
Verganti(2012),Martin (2010), Brown (2010) e Brown(2008) – que esta metodologia é bastante eficiente para fomentar o pensamento criativo. Também não pretendemos sob alguma hipótese melhorar, estender ou questionar o framework i*, em vez disso entendemos e reconhecemos – através de Horkoff e Maiden (2015a) e Yu (1995) – os benefícios que ele trouxe à ER.
1.5
Metodologia de pesquisa
Inicialmente enveredamos para uma revisão da bibliografia existente, a fim de formarmos um conhecimento sólido dos domínios estudados. Foi esta revisão que nos possibilitou definir a fundamentação teórica da dissertação.
Quanto ao método adotado para a condução do estudo, escolhemos o método científico pesquisa-ação para, a partir de um problema complexo real do tipo wicked problem1 , intercedermos junto à equipe de criação e inferirmos uma maneira para integrar
as práticas do DT à modelagem i*, de forma que produza como resultado modelos i* criativos – e que pudesse ser generalizada para outros projetos que objetivam a criatividade. A pesquisa-ação nos permitiu observar na prática os empecilhos à integração fluida, as ações que melhoraram a capacidade criativa da equipe sem que perdêssemos o foco nos objetivos dos stakeholders, a abstração necessária ao i* para que os envolvidos não necessitassem de conhecê-lo tecnicamente e também uma maneira de converter os resultados das técnicas criativas em modelos i*.
ParaThiollent (2011), a pesquisa-ação é o estudo de uma situação social com o fim de melhorar a qualidade da ação dentro da mesma. Esse método é amplamente usado nas ciências sociais, com o objetivo de entender e considerar as relações sociais que são determinantes para um fato e diante disto evidenciar o conhecimento necessário para que coletivamente haja êxito na melhoria da ação.
Vejamos o que nos dizGibertoni (2012, pág. 2):
[...] o mais importante na pesquisa-ação não é encontrar uma solução ótima, como em outros métodos, mas conseguir o compromisso com a mudança a ser feita para depois relatar a aplicação da teoria e também a resistência à aplicação de determinada técnica. Além disso, cabe ressaltar que existe uma meta bem maior que o resultado que se deseja alcançar: a geração e estruturação do conhecimento. Para Thiollent (2011) o ganho de conhecimento na pesquisa-ação é obtido através da observação e
1 Segundo (RITTEL,1967apudCHURCHMAN,1967), Wicked problems podem ser entendidos como
"uma classe de problemas de natureza social mal formulados, onde há informações confusas, um número considerável de stakeholders com interesses conflitantes, além de não estarem evidentes as possíveis ramificações que o problema pode tomar".
avaliação das ações (definidas com os participantes) e dos obstáculos encontrados. Esse conhecimento é passível de generalização parcial, uma vez que está fortemente ligado ao contexto da pesquisa. A qualidade do conhecimento, porém, está limitada pela eficácia da intervenção e pelo interesse da empresa no projeto.
Quanto a postura epistemológica, a qual se relaciona ao conhecimento e como ele pode ser obtido por parte dos pesquisadores, adotamos uma abordagem interpretativista, na qual o conhecimento é relativo e deve ser entendido do ponto de vista dos indivíduos diretamente envolvidos na pesquisa (DINIZ et al., 2006).
Mais à frente descreveremos com detalhes a execução da pesquisa-ação, mas de antemão entendemos ter sido bastante adequada para alcançarmos nossos objetivos. Isso porque ela nos propiciou, de imediato, conduzir ações que levassem a produção dos modelos i* necessários à equipe envolvida na pesquisa e, posteriormente, possibilitou experimentar e entender a dinâmica social necessária para que este estudo pudesse se concretizar. Não seria possível a construção deste método proposto sem que houvesse essa liberdade de experimentar e analisar social e colaborativamente as práticas para a construção de modelos i*, seguindo os preceitos do DT. Se tivéssemos optado por especificar o método solitariamente e testá-lo depois, certamente seria preciso realizar várias rodadas de experimentos, sem ter a certeza que as adaptações feitas entre os experimentos fariam sentido no meio social e colaborativo até que as testássemos. Resumindo, o feedback social ofertado pela pesquisa-ação foi determinante para que o método fosse definido.
1.6
Estrutura da dissertação
Além desse capitulo introdutório, essa dissertação está dividida em mais 6 (seis) capítulos:
No Capítulo 2 consta a fundamentação teórica que apresenta os conceitos e
as premissas assumidas neste estudo. Tomamos o cuidado de não só apresentar estes conceitos holisticamente, mas sim conduzi-los de modo que se especializem ao contexto deste trabalho.
Já no Capítulo 3, fizemos um apanhado de trabalhos que se relacionam direta e
indiretamente com o método proposto. Isso nos possibilitou entender qual a contribuição científica que poderíamos dar à área que nos propusemos a estudar, assim como deve passar aos leitores a noção do estado-da-arte na área.
Por sua vez, o Capítulo 4contém a documentação da condução da pesquisa-ação.
Tomamos o cuidado de apresentar um narrativa bastante detalhada, a fim de que seja possível atestar as validades internas e externas do método e do construto. É neste capítulo que apresentamos detalhes das ações, dos participantes e dos resultados obtidos com a
ação.
O capítuloCapítulo 5, considerado a contribuição científica dada por esta
disserta-ção, descreve o método resultante da condução da pesquisa-adisserta-ção, ou seja, a consolidação do conhecimento gerado na experimentação social. Ao apresentarmos nosso método, tomamos o cuidado de fazê-lo da forma mais minuciosa possível, haja vista nossa intenção ser facilitar a construção de modelos i* criativos através da aplicação do DT.
No capítulo Capítulo 6 apresentamos a segunda avaliação realizada com o intuito
de validar este método. Para isto, recrutamos uma equipe composta por 6 (seis) pessoas. Ao final da execução do método, os participantes o avaliaram através de um questionário fechado, o que nos possibilitou algumas conclusões quantitativas. Este capítulo também apresenta uma demonstração didática da aplicação do método em um problema real, neste caso o problema proposto para a avaliação.
Por fim, segue oCapítulo 7, no qual apresentamos as considerações finais deste
estudo e indicamos estudos futuros que contribuirão ainda mais para a integração entre a modelagem i* e o DT.
2 FUNDAMENTAÇÃO TEÓRICA
Apresentar os conceitos que caracterizam os domínios envolvidos nesta pesquisa é essencial para embasá-la, assim como validá-la perante os mesmos. Neste capítulo discutiremos sobre os domínios Engenharia de Requisitos, requisitos orientados a objetivos e Design Thinking, assim como as principais contribuições que eles entregam para a melhoria de software.
Cada subitem deste capítulo abordará um domínio específico, de forma que, ini-cialmente apresentaremos uma definição teórica mais ampla e consecutivamente com maior detalhamento abordaremos o assunto com um viés voltado para a nossa pesquisa. Este segundo momento é a teorização que embasa o método que definiremos adiante no
Capítulo 5.
2.1
Introdução à Engenharia de Requisitos
Para Pressman (2011) a ER é o espectro das várias tarefas que conduzem os stakeholders a um entendimento claro dos requisitos. Quanto a stakeholders, ele argumenta que é qualquer um que se beneficie direta ou indiretamente do software que está em desenvolvimento.
Já para Sommerville(2011, p. 57), tanto a definição de requisitos, quanto de ER, estão presentes no seguinte trecho:
“Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento. Esses requisitos refletem as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado engenharia de requisito”
Requisitos de software são comumente divididos em funcionais e não funcionais. Os requisitos funcionais descrevem o que o sistema deve fazer, ou seja, são declarações dos serviços que o sistema fornece, ou mesmo não fornece. Já os não funcionais são restrições impostas aos serviços e funções do sistema, podem estar relacionados a confiabilidade, tempo de resposta, etc. (SOMMERVILLE,2011).
Quanto aos processos de ER, incluem quatro atividades de alto nível, são elas: estudo de viabilidade, a qual busca saber se o sistema tem utilidade para os usuários, se é factível técnica e economicamente; elicitação e análise, que busca descobrir os requisitos e
entender a relação entre eles; especificação, que detalha os requisitos sob alguma forma-padrão e validação, a qual checa se os requisitos levantados realmente definem o software desejado pelo cliente. Estas atividades são intercaladas num processo iterativo. No entanto, devemos considerar que o entendimento dos stakeholders sobre o problema muda ao longo do processo de software, isso leva a mudanças nos requisitos. Para controlar essas mudanças e os impactos nos outros requisitos, há uma quinta atividade de alto nível chamada gerenciamento de requisitos (SOMMERVILLE, 2011).
A ER é descrita como wicked problems. Por isso, devemos considerar as diferenças socioculturais e as diferentes habilidades técnicas dos stakeholders – assim como os fatores dinâmicos, incertezas e riscos do contexto no qual estão inseridos – para vislumbrarmos os requisitos concernentes ao problema. Isso porque wicked problems são complexos por natureza, nos quais comumente os requisitos estão ausentes ou incompletos, começando a se definirem através da interação do grupo, seja convergente, seja divergentemente. Por isso é necessário focar no coletivo em detrimento do individual, assim como reforçar a necessidade de uma equipe multidisciplinar. Aliado a isto, os usuários apresentam grande dificuldade em descreverem o que querem, deixando a ER a obrigação de descobrir (MAHAUX et al.,
2013;LINDBERG; MEINEL; WAGNER,2011;MAIDEN; ROBERTSON; ROBERTSON,
2006).
Pressman (2011) e Sommerville(2011) taxativamente dizem que, considerando o cenário mercadológico, a maioria dos produtos de software é incremento dos que já existem, portanto, carecem de inovação. Pressman (2011) declara, ainda, em um capítulo dedicado aos tópicos emergentes na Engenharia de Software (ES), que a necessidade de gerenciar a complexidade, acomodar requisitos emergentes, estabelecer modelos de processos que aceitem mudanças e coordenar equipes multidisciplinares sugerem um novo tempo, onde ferramentas que suportem a colaboração entre os stakeholders serão tão importantes quanto as que suportem os aspectos tecnológicos.
2.1.1
Criatividade na Engenharia de Requisitos
Visto que criatividade pode assumir diferentes contextos nas várias áreas do conhecimento, para ER Maiden et al.(2010) nos dizem que criatividade é a captura de requisitos que são ao mesmo tempo novos e apropriados e ainda distinguem o termo inovação, argumentando que a implementação dos requisitos criativos conduz à inovação. De acordo com Boden (2004 apud RAYASAM; NIU, 2015), a criatividade na ER pode ser classificada como exploratória, a qual é obtida através de pesquisas profundas que desvendam uma gama de possibilidades; combinacional, a qual é obtida através de conexões entre objetos e disciplinas distintas num menos espaço de pesquisa e transformacional, que é entendida como a mais difícil de fomentar, haja vista ela buscar mudar (causar ruptura) os conceitos e regras que regem dado artefato.
O tema da criatividade tem recebido muita atenção dos pesquisadores da Engenharia de Requisitos (RE) ao longo da última década. Engenha-ria de Requisitos também tem sido demonstrada como uma disciplina inerentemente criativa, como recentemente sintetizado por Meiden et al.. Neste documento, sugerimos que Engenharia de Requisitos não é simplesmente um processo criativo, mas um processo criativo e colabo-rativo. A diferença é importante para a disciplina, porque, como vimos acima, criatividade individual e colaborativa são conhecidas por serem qualitativamente distintas e, portanto, requerem diferentes processos, ha-bilidades e técnicas. Nós argumentamos que as atividades de Engenharia de Requisitos quase sempre exigem criatividade colaborativa, porque as equipes de desenvolvimento precisam chegar a um consenso sobre um novo e valioso sistema que querem construir. (MAHAUX et al., 2013, pág. 1, tradução nossa)
Lemos et al.(2012), com o objetivo de mapear sistematicamente os estudos existen-tes sobre criatividade na ER, selecionaram e analisaram vários documentos dos bancos de dados mais renomados na área de TI - ACM Digital Library, IEEE Xplore, SpringerLink, etc. - que tivessem menção direta a criatividade e a Engenharia de Requisitos. Como resultado eles apresentaram a visão e contribuição de vários pesquisadores, assim como observaram a necessidade de mais pesquisas sobre a criatividade que abranjam todo o processo de ER, visto que a maioria dos estudos é para a fase de elicitação. Vejamos:
Nos últimos anos, o campo da criatividade para Engenharia de Requisitos tem recebido um crescente interesse de pesquisadores e profissionais. [...] Levantamento de requisitos é a fase que concentra a maioria dos estudos. O estudo confirma que as técnicas de criatividade melhoram o pensamento criativo nas atividades de requisitos. (LEMOS et al., 2012, pág. 1083, tradução nossa)
E este discurso é complementado por (MAHAUX et al.,2013, p. 9, tradução nossa): “Um apoio completo à criatividade colaborativa nos processos de Engenharia de Requisitos
pode ser um passo importante para uma melhor compreensão dos problemas de negócio e a geração de melhores soluções de negócio.”
A maioria dos processos da ER são processos criativos de resolução de problemas, no entanto a ênfase dada para a engenharia tem marginalizado o pensamento criativo como uma atividade importante. As atividades de ER comumente exigem criatividade colaborativa, uma vez que os stakeholders precisam discutir sobre o produto ou serviço, a fim de elicitar e mitigar os requisitos do mesmo. Podemos notar que há uma preocupação em afirmar o aspecto colaborativo da criatividade na ER, isso porque os especialistas em criatividade distinguem criatividade individual da colaborativa, porque esta última se baseia explicitamente nas interações dentro de um grupo para alcançar o resultado criativo (MAHAUX et al., 2013; MAHAUX; MAVIN; HEYMANS, 2012; MAIDEN et al., 2010).
Após uma longa discussão envolvendo as mais notáveis autoridades em criatividade na ER, Mahaux et al. (2013) propuseram um framework para explorar e ilustrar a
criatividade colaborativa nesta área. Em primeiro nível, este framework distingue os fatores coletivos dos individuais e em seguida os subdivide, a saber, resumidamente: dentre os fatores coletivos, sem o detalhamento das devidas subdivisões, constam objetivo, tempo, cultura, tolerância, divergência, confiança, liberdade, desafio, comunicação, liderança e técnica.
2.2
i*: framework orientado a objetivos
O i* é um framework de modelagem conceitual, orientado a objetivos, que tem por finalidade modelar contextos organizacionais para prover um mecanismo de análise estratégica. Para isso leva em conta os atores envolvidos, seus respectivos objetivos e as relações de inter-dependência entre esses elementos. Quanto ao objetivos, eles podem ser apresentados com a exigência de serem inflexíveis (goal), portanto só podem ser integralmente satisfeitos, ou flexíveis (softgoal), que podem estar parcialmente satisfeitos (YU,1995).
O uso do i* para a construção de modelos de requisitos no desenvolvimento de software ameniza os problemas não resolvidos pelos processos de requisitos convencionais. Com ele é possível expressar a intenção de um ator no uso do software e quais as dependências e influências com os outros atores e objetivos. Isso é extremamente relevante, visto que as mudanças nos requisitos se dão na prática porque os objetivos dos atores não foram satisfeitos, ou foram prejudicados de alguma forma. Somado a isto o i* propicia evidenciar e solucionar os conflitos de interesses existente, outro aspecto difícil de ser abordado por aqueles processos (I* WIKI, 2007;YU,1995).
A notação básica do i* está definida na Figura 1. E naFigura 2 as relações que os engenheiros de requisitos podem construir na modelagem i*. Segundo i* Wiki (2007), um dos objetivos de se criar modelos i* e a necessidade de explicitar como goals e softgoals podem ser satisfeitos através da operacionalização, ou através de ações mais concretas e decisões de projeto incluídas no modelo. Para ele, operacionalização, ou decomposição, é o processo de encontrar alternativas que satisfaçam os goals e softgoals. Desta forma, uma boa modelagem não deve ter goals e softgoals como últimos elementos de uma cadeia (leaf elements) ou sem links de entrada apontados para eles. Essas práticas tornarão os
modelos mais completos e precisos.
Os modelos i* podem ser do tipo Strategic Dependency (SD) ou Strategic Rationale (SR). O modelo SD é usado para denotar a rede de intenções e relacionamentos estratégicos de dependência entre os atores. Já o SR provê através da operacionalização uma estrutura para representar as estratégias internas dos atores, de modo que fiquem explícitos as alternativas e caminhos possíveis para atingir os goals e as relações com os outros elementos (I* WIKI,2007; YU, 1995).
Figura 1 – Notação básica do i*
Figura 2 – Possíveis relações no modelo i*
Fonte: (I* WIKI,2006)
No SD uma relação de dependência significa uma cooperação mutua entre atores, onde o dependente (depender) e aquele do qual se depende (dependee) são unidos por um link de dependência (dependum). O dependum pode ser um goal, softgoal, recurso ou tarefa. Enquanto que no SR os atores têm suas fronteiras estendidas para que os elementos necessários para satisfazer os objetivos dos atores se ligam um ao outro por um link de finalidade, decomposição ou contribuição (I* WIKI,2007; YU,1995).
De maneira geral, já tendo definido goal e softgoal, i* Wiki (2007) define uma tarefa como sendo uma forma específica de realizar algo e que pode ser decomposta em sub-elementos necessários para a execução da mesma; já um recurso é uma entidade física ou informacional desejada pelo ator, para este tipo de elemento não há questões em aberto sobre como será obtido; por sua vez, as premissas são condições consideradas verdadeiras pelo ator nas relações existentes para atingir um goal; no que diz respeito a links means-end, eles indicam a relação entre um fim (goal) e um meio de atingi-lo (tarefa);
enquanto que link de decomposição ligam uma tarefa a seus sub-elementos, os quais podem ser um goal, um recurso, um softgoal ou mesmo uma sub-tarefa e, por último, links de contribuição denotam a influência de um elemento sobre o outro.
Para termos uma melhor visualização destas possibilidades de modelagem, vejamos a Figura 3, a qual ilustra um modelo SD para uma clínica de saúde e a Figura 4, que ilustra um modelo SR para uma seguradora.
Figura 3 – Exemplo de modelo SD
Fonte: (YU,1995)
Realizar análises, automáticas ou não, sob os modelos i* possibilitam ao engenheiro de requisitos perceber uma falha de elicitação e especificação de requisitos precocemente e lhe dá apoio para corrigir e detectar possíveis impactos no sistema como um todo. Assim como é uma ótima base para que possa validar mais tardiamente os requisitos levantados. Considerando, então, a parcela de falhas nos projetos de software que estão relacionadas aos
requisitos, percebemos as vantagens trazidas a engenharia de requisitos pela modelagem orientada a objetivos e, consequentemente, a contribuição dada pelo i*.
Figura 4 – Exemplo de modelo SR
Fonte: (YU,1995)
A análise de um modelo dever ser feita através de questionamentos como: Para cada goal no modelo, o ator a quem ele pertence tem condições de alcançá-lo?; O caminho para um ator atingir um goal passa ou depende de outro ator?; Há mais de um caminho possível?; Os caminhos são viáveis?; O modelo como um todo é crível em satisfazer os goals dos atores?. Isso deve ser analisado até o momento em que o modelo seja crível e uma ou mais soluções viáveis sejam encontradas (I* WIKI, 2007).
O i* provê conceitos que facilitam a análise satisfatória das situações representadas no modelo. São eles: habilidade – é satisfatório quando o ator possui um caminho para atingir o propósito em questão; trabalhabilidade (do termo inglês workability) – é satisfatório quando o analista tem a certeza de que quando a ação for produzida o caminho apontado como satisfatório esterá disponível para o ator; viabilidade – está relacionado a quão evidente é a possibilidade de um caminho ser satisfatório ou não, onde, de modo geral,
um caminho é viável quando os softgoals no modelo forem suficientemente satisfeitos e, por último, credibilidade – que diz o quão críveis são às premissas adotadas no modelo (I* WIKI, 2007).
Apesar dos benefícios apresentados, a contrapartida do i* é certamente o grau de complexidade para conseguir modelos completos e precisos. Maiden et al. (2011) nos esclareceram bem este ponto quando reportaram uma análise sobre a experiência da aplicação do i* nos maiores projetos industriais que o puderam utilizar. Nesses projetos, apesar de os engenheiros de requisitos terem conhecimento técnico de i*, essa complexidade se mostrou evidente. Inicialmente eles apontam para a dificuldade que é desenvolver modelos SD e ter uma forma eficiente de estabelecer todas as possíveis dependências, ou seja, como perceber que as possibilidades de dependência foram exploradas até onde deviriam.
Outro ponto que pode trazer problemas é o fato de ser fácil usar a linguagem incorretamente, visto que é uma forma bastante diferente das quais a engenharia de software tradicionalmente havia proposto, por exemplo Unified Modeling Language (UML). UML diz apenas o que o sistema faz, enquanto i* deve dizer o que ele faz, porque faz e corss-referenciar a seus goals e softgoals. Ainda, os vários elementos existentes no i*, que podem ser ligados de diferentes formas nos modelos SD e SR, trazem problemas de modelagem inerentes apenas ao i* (MAIDEN et al., 2011).
Maiden et al.(2011) ainda argumentam que, dada a rigorosidade semântica do i*, é bastante difícil encontrar os atores e dependências mais importantes para os quais começar a produzir o primeiro modelo SD, a ponto de terem considerado a produção anterior de um modelo de contexto definidos por eles e usá-lo para guiar a produção do primeiro modelo SD.
Dada as dificuldades acima para engenheiros experientes, novos usuários do i* estão sujeitos a estas e outras que seguem. Horkoff (2015) realizou um estudo experimental que demonstrou que, mesmo trabalhando apenas nos modelos SD, grupos de novos usuários tiveram um progresso bastante lento na modelagem, pois muito tempo foi gasto discutindo ideias, dependências e atores, com consequente pouco tempo para registrarem o que haviam discutido. Alguns poucos grupos que começaram a modelagem SR estavam bastante confusos sobre os relacionamentos internos de decomposição, contribuição e means-end. Nas discussões os novos usuários tinham dificuldade em estabelecer equivalência entre os artefatos identificados no problema e os elementos representativos do i*.
A dificuldade com o uso efetivo do i* foi deveras considerável, a ponto de Hor-koff (2015) defender que a melhor estratégia para lidar com usuários novatos é fazê-los trabalharem primariamente com um modelo híbrido de SD e SR, postulado pelo autor e apresentado integralmente na Figura 5 – a qual ilustra um modelo híbrido para um serviço de estacionamento. Esse modelo intermediário inclui atores, fronteiras dos atores,
elementos internos às fronteiras e algumas dependências, mas sem entrar nos detalhes dos relacionamentos internos do modelo SR.
Figura 5 – Modelo SD/SR híbrido indicado para aprendizes
Fonte: (HORKOFF,2015)
E por fim,Horkoff(2015) alerta que apesar de o processo entre SD e SR ser iterativo, as equipes não demonstraram capacidade para melhorar os modelos SD delas a partir do progresso dos SR.
2.2.1
Uso do i* em ambientes criativos
Num trabalho recente apresentado porHorkoff, Maiden e Lockerbie (2015), eles demarcam o início de uma série de estudos que buscarão entender a sinergia existente entre modelagem orientada a objetivos e criatividade. Esta relação é portanto bastante vanguardista e, por consequência, nosso método proposto busca contribuir para esse entendimento.
Em um desses estudos, Horkoff e Maiden (2015b) executaram experimentos com o intuito de saber se é possível alinhar atividades de modelagem orientada a objetivos com atividades de prática criativa. Como resultado nos afirmam que os grupos não observaram restrição ao pensamento criativo devido às atividades de modelagem orientada a objetivos (i*). Contrariamente, evidenciaram que uma complementa a outra, visto que a modelagem orientada a objetivos permite a documentação clara (e técnica) das ideias levantadas pelos métodos criativos.
nos resultados criativos, apesar de, por limitações de tempo, não ter sido possível realizar mudanças (pela análise) nesses modelos. O experimento ainda demonstrou que a necessidade exploratória inicial requerida pela modelagem foi essencial para iniciar as atividades criativas, de modo que estas últimas foram melhor aceitas quando executas depois de iniciada a modelagem. Sobre este argumento, os próprios autores declaram ter sido influenciado pela ordem proposta para as atividades; e nós atentamos para questionar se as atividades criativas não envolveram qualquer fase anterior de exploração do problema, pois metodologias como o DT nos encaminham inicialmente da fase de inspiração (exploração do problema) adiante.
Como conclusão do experimento,Horkoff e Maiden (2015b) afirmam ser possível ter uma integração fluida entre as atividades de modelagem e de estimulo à criatividade, de modo que o fluxo mais adequado é aquele que executa as atividades concomitantemente, ou seja, intercala atividades de modelagem e de criação, a fim de que os resultados criativos possam ser expressos em modelos orientados a objetivos.
Outro experimento, realizado por Horkoff(2015), desta vez com novos usuários da linguagem i*, também atesta que os usuários conseguiram integrar atividades de modelagem e atividades criativas. Nesse estudoHorkoff(2015) conclui que os participantes não tiveram o pensamento criativo tolhido pelas atividades de modelagem e que argumentaram que a melhor forma de fazê-lo é executando essas atividades conjuntamente.
2.3
Design Thinking: uma metodologia criativa
Apesar de costumarmos relacionar o termo inovação à uma novidade tecnológica, diz-se que algo é inovador quando causa impacto nas vida das pessoas que usam o produto/serviço, quando rompem a ideia comum outrora apresentada por concorrentes ou, certamente, quando há a novidade em si. Ou seja, inovação é valor percebido. Já para o mercado, é a possibilidade de sair à frente do concorrente, de ganhar vantagem competitiva e de cobrar pelo valor agregado presente no produto/serviço. Ao longo dos anos, a disciplina design tem desenvolvido processos, métodos e ferramentas para resolver problemas, os mais complexos, de forma inovadora. Ao estimular/concretizar o pensamento criativo, os designers entregam inovação (VERGANTI,2006;VERGANTI,2012;MARTIN,
2010; BROWN, 2010).
A inovação guida pelo design, que aposta no poder de inferência e na experiência do designer, tem na pesquisa a fonte de inovação, ou seja, entregar inovação a partir da releitura de produtos antigos ou da união de produtos sob a visão do designer. Deste modo, o produto apresentado atinge usuários que não esperavam, mas que acolhem a proposta e lhe dão um valor único ante aos concorrentes (VERGANTI, 2006;VERGANTI, 2012).
pelos designers para gerar ideias e resolver problemas. É uma metodologia que integra fatores humanos, de negócio e tecnológico no entendimento do problema. É uma proposição para pensar de modo abdutivo, para que tanto a análise quanto a criatividade possam ser consideradas no universo das soluções. O DT é essencialmente colaborativo, multidisciplinar e centrado nas necessidades dos stakeholders (human-centric). Diferentemente da prática comum de delegar a um grupo pequeno de designer toda a responsabilidade de inovar, o DT evangeliza a disseminação deste modo de pensar para todos os stakeholders que objetivam ou estejam envolvidos em projetos criativos (MEINEL; LEIFER, 2011;MARTIN, 2010;
BROWN, 2008;BROWN, 2010; BROWN,2009; VIANNA et al.,2012;D.SCHOOL, 2010;
GREMETT; BAECK, 2011; WALOSZEK,2012; THIENEN et al., 2011).
Vianna et al. (2012) nos apresenta uma boa síntese do que se entende por DT:
No mais, como o nome já diz, o Design Thinking se refere à maneira do designer de pensar, que utiliza um tipo de raciocínio pouco convencional no meio empresarial, o pensamento abdutivo. Nesse tipo de pensamento, busca-se formular questionamentos através da apreensão ou compreensão dos fenômenos, ou seja, são formuladas perguntas a serem respondidas a partir das informações coletadas durante a observação do universo que permeia o problema. Assim, ao pensar de maneira abdutiva, a solução não é derivada do problema: ela se encaixa nele.
Ainda complementando, vejamos o que acrescenta Brown(2010):
Não se trata de uma proposta apenas centrada no ser-humano; ela é profundamente humana pela própria natureza. O design thinking se baseia em nossa capacidade de ser intuitivos, reconhecer padrões, desenvolver ideias que tenham um significado emocional além de palavras ou símbolos. Ninguém quer gerir uma empresa com base apenas em sentimento, intuição e inspiração, mas fundamentar-se demais no racional e no analítico também pode ser perigoso. A abordagem integrada que reside no centro do processo de design sugere um terceiro caminho.
Dar-se o nome de design thinker àqueles que estejam envolvidos num projeto guiado pelo DT, mas acima disto, àqueles que possam ser enquadrados nos principais atributos dele, como mostra a Tabela 1.
É extremamente desafiador promover inovação sob fortes restrições, no entanto é dever do design thinker estar disposto a aceitar e explorá-las. Um bom processo guiado pelo DT costuma identificar as principais restrições logo no início e, então, definir critérios para validá-las. As restrições podem ser avaliadas quanto ao seu grau de desejabilidade (faz sentido para as pessoas), viabilidade (modelo de negócio sustentável) e praticabilidade (funcionalmente possível). O DT busca não apenas explorar as restrições, mas pô-las em equilíbrio quanto a essas naturezas, o que não significa dizer que que um projeto bem-sucedido as terá com a mesma proporção. Uma equipe de design thinkers experientes
Tabela 1 – Principais atributos do Design Thinking
Atributo Descrição Comentário
Ambiguidade Ser confortável quando as
coisas não são claras ou quando você não sabe a resposta
Design Thinking visa wicked problems (mal definidos e complicados).
Colaborativo Trabalhar juntos em todas as
disciplinas
Pessoas projetam em equipes interdisciplinares.
Construtivo Criar novas ideias com base
em velhas, as quais também podem ser as ideias mais bem-sucedidas
Design Thinking é uma abordagem baseada em solução que procura um resultado futuro melhorado.
Curiosidade Ser interessado em coisas que
você não entende ou perceber as coisas com outros olhos
Tempo e esforço consideráveis são gastos em esclarecer os requisitos. Uma grande parte da atividade de resolução de problemas, então,
consiste de definição e modelagem do problema.
Empatia Ver e entender as coisas do
ponto de vista dos seus clientes
O foco está nas necessidades do usuário (contexto do problema).
Holístico Olhando pelo contexto maior
para o cliente
Design Thinking tenta atender às necessidades do usuário e também o sucesso do negócio.
Iterativo Um processo cíclico onde as
melhorias são feitas para uma solução ou ideia,
independentemente da fase
O processo de Design Thinking é tipicamente não-sequencial e pode incluir loops de feedback e ciclos (ver abaixo).
Sem
julgamento
Criar ideias sem julgamento em direção ao criador ou à ideia
Particularmente na fase de
brainstorming, não há julgamentos iniciais.
Mentalidade aberta
Abraçar Design Thinking como uma abordagem para qualquer problema,
independentemente do negócio ou escopo
O método incentiva a "pensar fora da caixa" ("ideias malucas"); ele desafia o óbvio e abraça uma abordagem mais experimental.
pode naturalmente mudar o foco do problema enquanto busca concluir o projeto (BROWN,
2008; BROWN, 2010).
No DT um projeto é delimitado com início, meio e fim. O início do projeto é marcado pela definição do briefing – o qual pode ser é entendido como um conjunto de restrições mentais que indicam por onde começar a exploração, podendo conter benchmarks, pelos quais é possível mensurar o progresso, assim como um conjunto de objetivos, os quais são a destinação final do projeto. Ainda sobre o projeto, este deve ser marcado por metas claras e objetivas a serem alcançadas. Essas metas proporcionam identificar estágios e, consequentemente, servem de termômetro para que a equipe mantenha o espírito criativo e colaborativo (BROWN, 2008; BROWN, 2010).
Quanto ao briefing, vejamos o que nos dizBrown (2010, pag. 22–23):
A analogia vai ainda mais longe. Da mesma forma que uma hipótese é diferente de um algoritmo, um briefing de projeto não é um conjunto de instruções ou uma tentativa de responder a uma pergunta antes de ela ser elaborada. Em vez disso, um briefing bem elaborado levará em conta a sorte, a imprevisibilidade e os caprichos do destino, já que esse é o âmbito criativo no qual surgem as ideias inovadoras. Se você já sabe o que quer, normalmente não faz muito sentido procurar.
[..] Um briefing de design abstrato demais arrisca deixar a equipe de projeto perdida em um nevoeiro. Já um briefing que parte de um conjunto reduzido demais de restrições praticamente garante que o resultado seja incremental e, provavelmente, medíocre.
Resumidamente, podemos dizer que um briefing deve deixar espaço para a equipe de projeto interpretar os conceitos, explorar e ... descobrir.
Quando nos referimos a equipe de projeto, Brown (2010) nos alerta que o mais importante é efetivamente inserir o cliente como um membro design thinker. Além disso, há a recomendação de que a interdisciplinaridade se faça presente, não apenas como pessoas de formações distintas, mas como pessoas com pensamentos/saberes dinamicamente interligados nas diversas áreas de conhecimento.
Outro fator relevante nas equipes de projeto é o tamanho, quanto maior a equipe menor é a efetividade em gerenciá-la e cultivar o pensamento criativo entre os membros. Mesmo com ferramentas modernas de gerenciamento de tarefas e reuniões há prejuízo ao fomento do pensamento abdutivo. Por este motivo, quando não for possível manter uma equipe enxuta, a literatura tem aconselhado a subdivisão em pequenas equipes gerenciadas constantemente para se manter a unidade do projeto. Equipes grandes têm dificuldade em se manterem focadas e, até mesmo, há prejuízo na aplicação de técnicas criativas – que normalmente preconizam uma integração afinada dos participantes (BROWN, 2008;
Tabela 2 – Comparação entre os estágios das definições distintas de Design Thinking
Estágios
prototípicos Wikipedia /Herbert Simon IDEO Toolkit Tim Brown (IDEO) d.school/ D-School (HPI) d.school Bootcamp Bootleg (HPI) – Modes Baeck & Gremett (2011) Mark Dziersk (Fast Company) Entender o
problema Definir Descobrir Inspirar-se Entender Simpatizar: Observar,
engajar, imergir Definir o problema a resolver (1) Definir o problema Observar
usuários Pesquisar Observar Buscar inspiração
Interpretar
os resultados Interpretar Ponto de vista Definir (Afirmação
do problema)
—
Gerar ideias
(Idear) Idear Idear Idear Idear Idear Idear múltiplas
ideias
(2) Criar e considerar várias alternativas
Prototipar,
experimentar Prototipar Experimentar Implementar Prototipar Prototipar Gerar protótipos (3) Refinar direções escolhidas (3.5) Repetir (opcional; etapas 2 e 3) Testar, implementar, melhorar Objetivos/ Escolher, implementar e aprender
Evoluir Testar Testar
(inclui refinar e melhorar as soluções) Solicitar feedback do usuário (4) Escolher o campeão, executar
Fonte: (WALOSZEK,2012, tradução nossa)
O último elemento que merece destaque nos projetos de DT é o que chamamos de espaço de inovação. Para Martin(2010) este espaço holisticamente deve perpassar todos os setores de uma organização, dos operadores à alta gestão. Este espaço, enquanto cultura de incentivo à criatividade, deve ser embasado por valores como otimismo, confiança e ousadia, já enquanto espaço físico deve prover suporte para ações de pesquisa e desenvol-vimento, fornecer e dar assistência às ferramentas necessárias para execução das técnicas de criatividade e propiciar o convívio/contato efetivo entre os membros da equipe (design thinkers).
O DT, quando aplicado a um projeto, se apresentará invariavelmente por meio de um processo iterativo e não linear. Isso se deve ao fato de ele ser verdadeiramente um processo exploratório, que se levado a cabo, conduzirá a equipe a caminhos de descobertas interligadas e contínuas, de modo que a equipe possa até mesmo ser motivada a repensar algumas premissas outrora adotadas. Há na literatura várias divisões desse processo em estágios – vide Tabela 2 – mas para nosso estudo consideramos a definição de Brown
(2008) – quarta coluna na tabela e também detalhada na Figura 6. Para entendermos melhor essa visão, complementada com Brown (2010), vejamos o que segue.
O estágio de inspiração consiste em entender o problema e as relações dele com outras áreas de conhecimento e com a vida social. Nele se define o estado-da-arte através de
Figura 6 – Fluxo do processo de Design Thinking
Fonte: (BROWN,2008)
uma busca sistematizada por conhecimento, podendo inclusive ser comparado às pesquisas de campo muito praticadas nas ciências sociais. Por esse motivo, o pensamento predomi-nante nesta fase é o de análise e síntese. Durante este estágio, curiosidade, ambiguidade, holístico e empatia são os atributos mais evidenciados.
Quando falamos de curiosidade, não limitamos o design thinker a ser apenas um espectador. Como dito anteriormente, a empatia está intrinsecamente ligada. Usar técnicas para se sentir “na pele” do usuário também é pratica recomendada.
Ao final deste estágio, a equipe deve ter um entendimento claro do estado-da-arte do problema. Assim como saberá em quais pontos podem atribuir criatividade, ou impor limitações que devem ser respeitadas. Por exemplo, num software que pretenda revolucionar o sistema radiodifusor, as leis vigentes de direitos autorais são limitações que devem ser apontadas, para que não haja risco de fracasso pré-anunciado do projeto.
Já no estágio de ideação, as técnicas de criatividade ganham maior destaque, visto que neste momento os pensamentos convergente e divergente devem ser predominantes a fim de gerar e selecionar alternativas criativas. Por exemplo, o brainstorm é muito utilizado para gerar alternativas, enquanto a prototipação é eficiente em selecioná-las.
Neste momento, o uso das técnicas criativas é amplamente difundido, por isso os atributos colaborativo, construtivo, mentalidade aberta e não julgamento devem ser os mais cultivados pela equipe. Apesar da ideação ser, normalmente, menor que a inspiração, neste estágio se atribui o aspecto verdadeiramente criativo a solução.
Já a implementação é tida como o menor estágio, não quanto ao tempo que se gastará para concluí-lo, mas pela menor contribuição do DT para executá-lo. Neste momento pode haver necessidade de tomar decisões sobre a execução – por exemplo, prototipar – o que deve ser apoiado por inspiração e ideação novamente, pois são os estágios onde se entende e inova o projeto.
Independente do estágio, o DT preconiza a utilização de um espaço que propicie a criatividade, de modo a fornecer conforto para manter a equipe unida e inter-acessível, além de ferramentas que ajudem no pensamento criativo. O post-it é uma ótima ferramenta para gerenciar as ideias, dada a flexibilidade de manipular e evidenciá-lo por todos da equipe. Outra ótima ferramenta é o pensamento visual, há ideias que são melhores vislumbradas ilustrativamente. Contar histórias também é extremamente importante, pois é um meio de cultivar a empatia.
O último destaque feito às práticas do DT é a importância da prototipação durante todo o projeto. Como dito por Jobst e Meinel (2014), prototipação ajuda os stakeholders a entenderem o que querem, ajuda os designers a resolverem conflitos e indica possíveis soluções para um problema, por isso, prototipar é certamente uma prática constante a ser adotada no DT.
2.3.1
Uso do Design Thinking na criação de software
Lindberg et al. (2012) e Lindberg et al. (2012) se debruçaram sobre o tema da criatividade fomentada pelo DT aplicada ao mercado de TI, no projeto intitulado Collaborative Creativity of Development Processes in the IT Industry. Nele exploraram a capacidade do DT de ampliar o entendimento e solução de problemas nos processos de TI. Concluíram que esta metodologia quando aplicada ao desenvolvimento de softwares maximizará o potencial criativo desses produtos, ressaltando que os preceitos do DT são aplicáveis a todas as fases do desenvolvimento, uma vantagem efetiva diante das outras abordagens que se limitam, geralmente, à elicitação de requisitos.
Eles ainda apontam que o DT se apresenta como um modelo de pensamento complementar ao já consagrado nas ciências exatas como a computação. Os design thinkers
