Racionalidade do projeto

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar
Uma estrutura de projeto baseada em decisões, que abrange as áreas de projeto de engenharia , lógica de projeto e análise de decisão .

Uma lógica de projeto é uma documentação explícita das razões por trás das decisões tomadas ao projetar um sistema ou artefato . Como inicialmente desenvolvido por WR Kunz e Horst Rittel , a lógica do design procura fornecer uma estrutura baseada em argumentação para o processo político e colaborativo de abordar problemas perversos . [1]

Visão geral [ editar ]

Uma lógica de design é a lista explícita de decisões tomadas durante um processo de design e as razões pelas quais essas decisões foram tomadas. [2] Seu objetivo principal é apoiar os designers , fornecendo um meio de registrar e comunicar a argumentação e o raciocínio por trás do processo de design. [3] Deve, portanto, incluir: [4]

  • as razões por trás de uma decisão de design,
  • a justificativa para isso,
  • as outras alternativas consideradas,
  • os trade-offs avaliados, e
  • a argumentação que levou à decisão.

Diversas áreas da ciência estão envolvidas no estudo dos fundamentos do design, como ciência da computação [2] ciência cognitiva , [3] inteligência artificial , [5] e gestão do conhecimento . [6] Para apoiar a lógica do projeto, vários frameworks foram propostos, como QOC, DRCS, IBIS e DRL.

História [ editar ]

Enquanto os formatos de argumentação podem ser rastreados até o trabalho de Stephen Toulmin na década de 1950 [7] dados, reivindicações, garantias, apoios e refutações, a origem da lógica do design pode ser rastreada até o desenvolvimento de WR Kunz e Horst Rittel [ 1] da notação Issue-Based Information System (IBIS) em 1970. Várias variantes do IBIS foram propostas desde então.

  • A primeira foi a Hierarquia Procedimental de Questões (PHI), descrita pela primeira vez na Dissertação de Doutorado de Ray McCall [8], embora não nomeada na época.
  • O IBIS também foi modificado, neste caso para dar suporte à Engenharia de Software, pela Potts & Bruns. [9] A abordagem Potts & Bruns foi então estendida pela Decision Representation Language (DRL). [10] que foi estendido pelo RATSpeak. [5]
  • Questions Options and Criteria (QOC), também conhecido como Design Space Analysis [11] [12] é uma representação alternativa para raciocínio baseado em argumentação, assim como o Win-Win [13] e o Decision Recommendation and Intent Model (DRIM). [14]

O primeiro Rationale Management System (RMS) foi o PROTOCOL, que suportava PHI, que foi seguido por outros sistemas baseados em PHI MIKROPOLIS e PHIDIAS. O primeiro sistema que forneceu suporte IBIS foi o STIEC de Hans Dehlinger. [15] Rittel desenvolveu um pequeno sistema em 1983 (também não publicado) e o mais conhecido gIBIS (IBIS gráfico) foi desenvolvido em 1987. [16]

Nem todas as abordagens de DR bem-sucedidas envolvem argumentação estruturada. Por exemplo, a abordagem Scenario-Claims Analysis de Carroll e Rosson [17] captura a lógica em cenários que descrevem como o sistema é usado e quão bem os recursos do sistema suportam os objetivos do usuário. A abordagem de Carroll e Rosson para a lógica do projeto destina-se a ajudar os designers de software e hardware de computador a identificar as compensações subjacentes do projeto e fazer inferências sobre o impacto de possíveis intervenções de projeto. [18]

Conceitos-chave na lógica do design [ editar ]

Existem várias maneiras de caracterizar as abordagens de DR. Alguns dos principais recursos distintivos são como ele é capturado, como é representado e como pode ser usado.

Captura de raciocínio [ editar ]

A captura de raciocínio é o processo de aquisição de informações de raciocínio para um gerenciamento de raciocínio.

Métodos de captura
  • Um método chamado "Reconstrução" [4] captura os fundamentos em uma forma bruta, como o vídeo, e depois os reconstrói em uma forma mais estruturada. [19] A vantagem do método de Reconstrução é que os fundamentos podem ser cuidadosamente capturados e o processo de captura não atrapalha o designer. Mas este método pode resultar em alto custo e preconceitos da pessoa que produz as justificativas
  • O método "Record-and-replay" [4] simplesmente captura os fundamentos à medida que eles se desenrolam. Os fundamentos são capturados de forma síncrona em uma videoconferência ou capturados de forma assíncrona por meio de quadro de avisos ou discussão por e-mail. Se o sistema tiver representação informal e semiformal, o método será útil.
  • O método "Subproduto metodológico" [4] captura as razões durante o processo de projeto seguindo um esquema. Mas é difícil projetar tal esquema. A vantagem deste método é o seu baixo custo.
  • Com uma rica base de conhecimento (KB) criada antecipadamente, o método "Aprendiz" [4] captura racionais fazendo perguntas quando confunde ou discorda da ação do designer. Este método beneficia não apenas o usuário, mas o sistema.
  • No método "Geração Automática" [4] , os fundamentos do projeto são gerados automaticamente a partir de um histórico de execução a baixo custo. Tem a capacidade de manter racionalidades consistentes e atualizadas. Mas o custo de compilar o histórico de execução é alto devido à complexidade e dificuldade de alguns problemas de aprendizado de máquina.
  • O método "Historiador" [20] permite que uma pessoa ou programa de computador observe todas as ações do designer, mas não faça sugestões. Os fundamentos são capturados durante o processo de design. [19]

Representação racional [ editar ]

A escolha da representação da lógica do projeto é muito importante para garantir que a lógica que capturamos seja o que desejamos e podemos usar com eficiência. De acordo com o grau de formalidade, as abordagens usadas para representar a lógica do projeto podem ser divididas em três categorias principais: informal, semiformal ou formal. [4]Na representação informal, os raciocínios podem ser registrados e capturados apenas usando nossos métodos e mídias tradicionalmente aceitos, como processadores de texto, registros de áudio e vídeo ou até mesmo manuscritos. No entanto, essas descrições dificultam a interpretação automática ou outros suportes baseados em computador. Na representação formal, o raciocínio deve ser coletado sob um formato estrito para que o raciocínio possa ser interpretado e entendido por computadores. No entanto, devido ao formato estrito da lógica definida pelas representações formais, os conteúdos dificilmente podem ser compreendidos pelo ser humano e o processo de captura da racionalidade do projeto exigirá mais esforços para ser finalizado e, portanto, torna-se mais intrusivo.

As representações semiformais tentam combinar as vantagens das representações formais e informais. Por um lado, as informações capturadas devem poder ser processadas por computadores para que mais suporte baseado em computador possa ser fornecido. Por outro lado, o procedimento e o método usados ​​para capturar as informações da lógica do projeto não devem ser muito intrusivos. No sistema com representação semiformal, as informações esperadas são sugeridas e os usuários podem capturar o raciocínio seguindo as instruções para preencher os atributos de acordo com alguns modelos ou apenas digitar descrições em linguagem natural. [4]

Modelos baseados em argumentação [ editar ]

O modelo Toulmin
Uma maneira comumente aceita para a representação semiformal da lógica do design é estruturar a lógica do design como argumentação. [5] O modelo mais antigo baseado em argumentação usado por muitos sistemas de lógica de projeto é o modelo de Toulmin. [7] O modelo de Toulmin define as regras de argumentação do design rationale com seis etapas: [21]
  1. A reclamação é feita;
  2. Dados de suporte são fornecidos;
  3. Warrant fornece evidências para as relações existentes;
  4. A garantia pode ser suportada por um apoio;
  5. Qualificadores de modelo (alguns, muitos, a maioria, etc.) são fornecidos;
  6. Possíveis refutações também são consideradas.
Uma vantagem do modelo Toulmin é que ele usa palavras e conceitos que podem ser facilmente compreendidos pela maioria das pessoas.
Sistema de Informação Baseado em Problemas (IBIS)
Outra abordagem importante para a argumentação da lógica de design é o IBIS ( Issue-Based Information System ) [1] de Rittel e Kunz, que na verdade não é um sistema de software, mas uma notação argumentativa. Ele foi implementado em forma de software por gIBIS (IBIS gráfico), itIBIS (IBIS baseado em teste), Compendium e outros softwares. [22] [23] O IBIS usa alguns elementos racionais (denominados como nós) como questões, posições, argumentos, resoluções e vários relacionamentos, como mais geral que, sucessor lógico para, sucessor temporal para, substitui e semelhante, para vincular o discussões de assuntos.
Hierarquia Processual de Problemas (PHI)
PHI (Procedural Hierarchy of Issues) [24] estendeu o IBIS para questões não controversas e redefiniu os relacionamentos. PHI adiciona a relação de subquestões, o que significa que a resolução de um problema depende da resolução de outro problema.
Perguntas, Opções e Critérios (QOC)
QOC (Questões, Opções e Critérios) [25] é usado para análise de espaço de projeto. Semelhante ao IBIS, o QOC identifica os principais problemas de design como perguntas e as possíveis respostas às perguntas como opções. Além disso, o QOC utiliza critérios para descrever explicitamente os métodos de avaliação das opções, como os requisitos a serem atendidos ou as propriedades desejadas. As opções estão vinculadas a critérios de forma positiva ou negativa e esses vínculos são definidos como avaliações.
Linguagem de Representação de Decisão (DRL)
DRL (Decision Representation Language) [26] estende o modelo de Potts e Bruns de DR [9] e define os elementos primários como problemas de decisão, alternativas, objetivos, reivindicações e grupos. Lee (1991) argumentou que o DRL é mais expressivo do que outras linguagens. [26] DRL se concentra mais na representação da tomada de decisão e seu raciocínio do que no raciocínio do projeto.
RATSpeak
Baseado em DRL, o RATSpeak é desenvolvido e utilizado como linguagem de representação em SEURAT (Software Engineering Using RATionale). [27] O RATSpeak leva em consideração os requisitos (funcionais e não funcionais) como parte dos argumentos para alternativas aos problemas de decisão. O SEURAT também inclui uma Ontologia de Argumentos que é uma hierarquia de tipos de argumentos e inclui os tipos de declarações utilizados no sistema.
Modelo Espiral WinWin
O WinWin Spiral Model, que é usado na abordagem WinWin, [28] adiciona as atividades de negociação WinWin, incluindo a identificação das principais partes interessadas dos sistemas e a identificação das condições de ganho de cada parte interessada e negociação, na frente de cada ciclo da espiral . modelo de desenvolvimento de software [29] a fim de alcançar um acordo mutuamente satisfatório (ganha-ganha) para todas as partes interessadas do projeto.
No Modelo Espiral WinWin, os objetivos de cada stakeholder são definidos como condições Win. Quando houver um conflito entre as condições de vitória, ele será capturado como um problema. Em seguida, as partes interessadas inventam Opções e exploram compensações para resolver o problema. Quando o problema é resolvido, é alcançado um Acordo que satisfaça as condições de ganho das partes interessadas e capture a opção acordada. A lógica do design por trás das decisões é capturada durante o processo do modelo WinWin e será usada pelas partes interessadas e pelos designers para melhorar sua tomada de decisão posterior. [28] O modelo WinWin Spiral reduz as despesas gerais da captura da lógica do projeto, fornecendo aos interessados ​​um processo bem definido para negociar. Em [30]uma ontologia de lógica de decisão é definida e seu modelo utiliza a ontologia para resolver o problema de apoiar a manutenção de decisões no framework de colaboração WinWin.
Recomendação de projeto e modelo de intenção (DRIM)
DRIM (Recomendação de Projeto e Modelo de Intenção) é usado em SHARED-DRIM. [14] A estrutura principal do DRIM é uma proposta que consiste nas intenções de cada projetista, nas recomendações que satisfazem as intenções e nas justificativas das recomendações. As negociações também são necessárias quando existem conflitos entre as intenções de diferentes designers. A recomendação aceita torna-se uma decisão de projeto, e a lógica das recomendações não aceitas, mas propostas, também são registradas durante esse processo, o que pode ser útil durante o projeto iterativo e/ou manutenção do sistema.

Aplicativos [ editar ]

A lógica do design tem o potencial de ser usada de muitas maneiras diferentes. Um conjunto de usos, definido por Burge e Brown (1998), [19] são:

  • Verificação do design — A lógica do design pode ser usada para verificar se as decisões de design e o próprio produto são o reflexo do que os designers e os usuários realmente queriam.
  • Avaliação do projeto — A lógica do projeto é usada para avaliar as várias alternativas de projeto discutidas durante o processo de projeto.
  • Manutenção do projeto — A lógica do projeto ajuda a determinar as mudanças necessárias para modificar o projeto.
  • Reutilização do projeto — A lógica do projeto é usada para determinar como o projeto existente pode ser reutilizado para um novo requisito com ou sem alterações nele. Se houver necessidade de modificar o projeto, o DR também sugere o que precisa ser modificado no projeto.
  • Ensino de design — A lógica de design pode ser usada como um recurso para ensinar pessoas que não estão familiarizadas com o design e o sistema.
  • Comunicação do design — A lógica do design facilita uma melhor comunicação entre as pessoas envolvidas no processo de design e, assim, ajuda a criar um design melhor.
  • Assistência ao projeto — A lógica do projeto pode ser usada para verificar as decisões de projeto tomadas durante o processo de projeto.
  • Documentação do projeto — A lógica do projeto é usada para documentar todo o processo de projeto que envolve as deliberações da sala de reuniões, as alternativas discutidas, as razões por trás das decisões do projeto e a visão geral do produto.

O DR é usado por comunidades de pesquisa em engenharia de software, design mecânico, inteligência artificial, engenharia civil e pesquisa de interação humano-computador. Na engenharia de software, pode ser usado para apoiar as ideias dos projetistas durante a análise de requisitos, capturando e documentando reuniões de projeto e prevendo possíveis problemas devido à nova abordagem de projeto. [31] Na arquitetura de software e no design de soluções de terceirização, pode justificar o resultado das decisões de arquitetura e servir como guia de design. [32] Na engenharia civil, ajuda a coordenar a variedade de trabalhos que os projetistas realizam ao mesmo tempo em diferentes áreas de um projeto de construção. Também ajuda os designers a compreender e respeitar as ideias uns dos outros e a resolver quaisquer possíveis problemas. [33]

O DR também pode ser usado pelos gerentes de projeto para manter seu plano de projeto e o status do projeto atualizados. Além disso, os membros da equipe do projeto que perderam uma reunião de design podem consultar o DR para saber o que foi discutido sobre um tópico específico. As questões não resolvidas capturadas em DR podem ser usadas para organizar novas reuniões sobre esses tópicos. [31]

A lógica do design ajuda os designers a evitar os mesmos erros cometidos no design anterior. Isso também pode ser útil para evitar a duplicação de trabalho. [5] Em alguns casos, a DR pode economizar tempo e dinheiro quando um sistema de software é atualizado de suas versões anteriores. [2]

Existem vários livros e artigos que fornecem excelentes pesquisas de abordagens de lógica aplicadas a HCI, [34] Design de Engenharia [4] e Engenharia de Software. [35]

Veja também [ editar ]

Referências [ editar ]

  1. ^ a b c Kunz, W.; Rittel, H. (1970), Questões como elementos de sistemas de informação . Documento de Trabalho 131, Centro de Desenvolvimento Urbano e Regional, Universidade da Califórnia em Berkeley
  2. ^ a b c Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Design Rationale for Software Engineering: A Survey", 25ª Conferência Internacional do Havaí em Ciências do Sistema , 2, pp. 577-586
  3. ^ a b Horner, J.; Atwood, ME (2006), "Racionalidade do Design Eficaz: Entendendo as Barreiras", em Dutoit, AH; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering, Springer Berlin Heidelberg, pp. 73-90
  4. ^ a b c d e f g h i Lee, J. (1997). "Design Rationale Systems: Entendendo os problemas". Especialista IEEE 12 (3): 78–85
  5. ^ a b c d Burge, JE; Brown, DC (2000), "Raciocínio com Design Rationale", em Gero, J., Inteligência Artificial em Design '00 , Holanda: Kluwer Academic Publ., pp. 611–629
  6. ^ Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory", Systems, Man and Cybernetics , pp. 1904 - 1908.
  7. ^ a b Stephen Toulmin (1958). Os Usos do Argumento . Cambridge: Cambridge University Press.
  8. ^ McCall, R. (1978), Sobre a estrutura e uso de sistemas de emissão em design , Dissertação de Doutorado, Universidade da Califórnia, Berkeley, University Microfilms
  9. ^ a b Potts, C.; Burns, G. (1988), "Gravando as razões para decisões de design", 10ª Conferência Internacional de Engenharia de Software (ICSE '1988), pp. 418-427
  10. Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale", Proceedings of the 13th International Conference on Software Engineering (ICSE '13) , IEEE Computer Society Press, Los Alamitos, CA, pp. 114 -125
  11. ^ Maclean, A.; Young, RM.; Moran, T. (1989), "Racionalidade do design: o argumento por trás do artefato", SIGCHI Bull . 20, pág. 247-252114-125
  12. ^ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questões, Opções e Critérios: Elementos de Análise do Espaço de Design", em Moran, T.; Carroll, J., Design Rationale Concepts, Techniques, and Use, Lawrence Erlbaum Associates , pp. 53-106
  13. ^ Barry Boehm , Ross, R (1989). "Gestão de projetos de software Teoria-W: princípios e exemplos.". Transações IEEE em Engenharia de Software 18 (7): 902-916.
  14. ^ a b Pena-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design Recomendação-Intent Management System", Proceedings Enabling Technologies Infrastructure for Collaborative Enterprise , IEEE Press, Morgantown, WV, pp. 213-221
  15. ^ Dehlinger, H. (1978), Projeto STIEC: Análise de Sistemas da Geração e Disseminação de Informação Científica e Tecnológica na Comunidade Européia" Relatório No. 26: Relatório sobre um Lote - Versão de STIEC , Heidelberg/Stuttgart
  16. ^ Conklin, J.; Yakem Begemanovic, M. (1988). "gIBIS: Uma ferramenta de hipertexto para discussão política exploratória". Transações ACM em Sistemas de Informação do Office 6 (4): 303-331.
  17. ^ Carroll, JM; Rosson, M (1992). "Contornando o ciclo tarefa-artefato: como fazer reivindicações e projetar por cenário". ACM Trans. Inf. Sist . 10 (2): 181-212
  18. ^ Carroll, JM, & Rosson, MB (2003). Racionalidade do projeto como teoria. Modelos, teorias e estruturas de HCI: em direção a uma ciência multidisciplinar, 431-461.
  19. ^ a b c Burge, J.; Brown, DC (1998), Design Rationale: Types and Tools, Technical Report , Worcester Polytechnic Institute, Computer Science Dept. , recuperado em 27 de abril de 2007
  20. ^ Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "Representação do conhecimento da história do design e sua implementação básica do computador", a 2ª Conferência Internacional sobre Teoria e Metodologia do Design, Chicago, IL, pp. 175-185
  21. ^ Reynolds, Chris (2000), Qual é o Modelo Toulmin? Arquivado em 25/08/2007 no Wayback Machine Paper em concentric.net.
  22. ^ Conklin, J.; Yakemovic, K. (1991). "Uma Abordagem Orientada ao Processo para Design Racional". Interação Humano-Computador 6 (3 e 4): 357–391.
  23. ^ Rittel, Horst WJ ; Noble, Douglas (janeiro de 1989). Sistemas de informação baseados em problemas para design (PDF) (Relatório técnico). Berkeley, CA: Instituto de Desenvolvimento Urbano e Regional, Universidade da Califórnia . OCLC  20155825 . 492.
  24. ^ McCall, RJ (1991). "PHI: Uma Fundação Conceitual para Design Hypermedia". Estudos de Design 12 (1): 30–41.
  25. ^ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questões, Opções e Critérios: Elementos de Análise do Espaço de Design", em Moran, T.; Carroll, J., Design Rationale Concepts, Techniques, and Use , Lawrence Erlbaum Associates, pp. 53-106
  26. ^ a b Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale", Proceedings of the 13th International Conference on Software Engineering (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, pp . 114-125
  27. ^ Burge, J. (2005), Engenharia de Software usando design RAtionale , Instituto Politécnico de Worcester, Departamento de Ciência da Computação
  28. ^ a b Barry Boehm ; Kitapci, H. (2006), "A Abordagem WinWin: Usando uma Ferramenta de Negociação de Requisitos para Captura e Uso de Racional", em Dutoit, AH; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering , Springer Berlin Heidelberg, pp. 173-190
  29. ^ Barry Boehm (1998). "Um modelo espiral de desenvolvimento e aprimoramento de software" . Computador 21 (5): 61–72
  30. ^ Bose, P. (1995). "Um modelo para manutenção de decisão na estrutura de colaboração WinWin". Engenharia de Software Baseada em Conhecimento (KBSE '95).
  31. ^ a b Dutoit, A.; McCall, B.; Mistrik et ai., eds. (2006), Rationale Management in Software Engineering , Springer pp.1-48.
  32. ^ O. Zimmermann, C. Miksovic, J. Küster, arquitetura de referência, metamodelo e princípios de modelagem para gerenciamento de conhecimento arquitetônico em serviços de tecnologia da informação . Jornal de Sistemas e Software, Elsevier. Vol. 85, Edição 9, setembro de 2012
  33. ^ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Aplicação de sistemas de lógica de design à definição de projetos – estabelecendo um projeto de pesquisa . Arquivado em 28-09-2007 no Wayback Machine Recuperado em 27 de abril de 2007
  34. ^ Moran, T.; Carroll, J., eds. (1996), Design Rationale Concepts, Techniques, and Use , Lawrence Erlbaum Associates,
  35. ^ Dutoit, Rationale Management in Software Engineering

Leitura adicional [ editar ]

Livros
  • Burge, JE; Carroll, JM; McCall R; Mistrik I (2008). Engenharia de Software Baseada em Racional . Heidelberg: Springer-Verlag.
  • Dutoit, AH; McCall R; Mistrik I; Paech B (2006). Rationale Management em Engenharia de Software . Heidelberg: Springer-Verlag.
  • Conklin, J (2005). Mapeamento Diálogo . Weinheim: Wiley-VCH Verlag.
  • Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Visualizando Argumentação: Ferramentas de Software para Criação de Sentido Colaborativo e Educacional . Londres: Springer-Verlag.
  • Moran, T; Carroll J (1996). Conceitos, técnicas e uso da lógica do projeto . NJ: Lawrence Erlbaum Associates.
Edições especiais
  • Inteligência Artificial para Projeto, Análise e Manufatura de Engenharia (AIEDAM), Edição Especial: Outono de 2008, Vol.22 No.4 Design Rationale http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html
  • Inteligência Artificial para Projeto, Análise e Manufatura de Engenharia (AIEDAM), Edição Especial sobre Representação e Uso da Racionalidade do Projeto, 1997, Vol.11 No.2, Cambridge University Press
Oficinas
  • Segundo Workshop sobre Compartilhamento e Reutilização do Conhecimento Arquitetônico - Arquitetura, lógica e intenção de projeto (SHARK/ADI 2007), ( RC.rug.nl ) como parte do 29º Int. Conf. em Engenharia de Software (ICSE 2007) ( CS.ucl.ac.uk )
  • Workshop sobre Design Rationale: Problemas e Progresso ( Muohio.edu )
  • Coordenadores do Workshop: Janet Burge e Rob Bracewell, realizado em 9 de julho de 2006 em conjunto com Design, Computing, and Cognition '06. Eindhoven, ( wwwfaculty.arch.usyd.edu.au ) Holanda

Links externos [ editar ]

  • Bcisive.austhink.com : Um pacote de software comercial projetado para lógica de design e lógica de decisão de forma mais ampla. Interface gráfica, recursos de compartilhamento.
  • Compêndio : Uma ferramenta de hipermídia que fornece recursos de gerenciamento de conhecimento visual com base no IBIS. Aplicativo Java gratuito, binário e fonte, com uma comunidade de usuários ativa que se reúne anualmente.
  • designVUE : Uma ferramenta para captura de conhecimento visual baseada em IBIS e outros métodos. Aplicativo Java gratuito.
  • SEURAT : Um plug-in Eclipse que integra captura e uso de lógica com um ambiente de desenvolvimento de software. SEURAT está disponível como um projeto de código aberto no GitHub ( [1] ).