Fundamento del diseño
Una estructura de diseño basada en decisiones, que abarca las áreas de diseño de ingeniería , justificación del diseño y análisis de decisiones.
Detalle de un árbol del conocimiento según la Encyclopédie de Diderot y d'Alembert, de Chrétien Frédéric Guillaume Roth
Mapeo de información
Temas y campos
Enfoques de nodo-enlace
Véase también

Una justificación de diseño es una documentación explícita de las razones detrás de las decisiones tomadas al diseñar un sistema o artefacto . Tal como la desarrollaron inicialmente WR Kunz y Horst Rittel , la justificación de diseño busca brindar una estructura basada en la argumentación al proceso político y colaborativo de abordar problemas complejos . [1]

Descripción general

Una justificación de diseño es la lista explícita de decisiones tomadas durante un proceso de diseño y las razones por las cuales se tomaron esas decisiones. [2] Su objetivo principal es apoyar a los diseñadores brindándoles un medio para registrar y comunicar la argumentación y el razonamiento detrás del proceso de diseño. [3] Por lo tanto, debe incluir: [4]

  • las razones detrás de una decisión de diseño,
  • La justificación de ello,
  • las demás alternativas consideradas,
  • las compensaciones evaluadas, y
  • la argumentación que condujo a la decisión.

Varias áreas científicas están involucradas en el estudio de los fundamentos del diseño, como la informática [2], la ciencia cognitiva , [3] la inteligencia artificial , [5] y la gestión del conocimiento . [6] Para respaldar los fundamentos del diseño, se han propuesto varios marcos, como QOC, DRCS, IBIS y DRL.

Historia

Si bien los formatos de argumentación se remontan al trabajo de Stephen Toulmin en la década de 1950 [7] (datos, afirmaciones, garantías, respaldos y refutaciones), el origen de la lógica del diseño se remonta al desarrollo de la notación del Sistema de Información Basado en Problemas (IBIS) por parte de WR Kunz y Horst Rittel [1] en 1970. Desde entonces, se han propuesto varias variantes de IBIS.

  • La primera fue la Jerarquía Procesal de Asuntos (PHI), descrita por primera vez en la tesis doctoral de Ray McCall [8], aunque no fue nombrada en ese momento.
  • IBIS también fue modificado, en este caso para apoyar la ingeniería de software, por Potts y Bruns. [9] El enfoque de Potts y Bruns fue luego ampliado por el lenguaje de representación de decisiones (DRL), [10] que a su vez fue ampliado por RATSpeak. [5]
  • Las opciones y criterios de preguntas (QOC), también conocidas como análisis del espacio de diseño [11] [12], son una representación alternativa para la justificación basada en argumentación, al igual que Win-Win [13] y el modelo de recomendación e intención de decisiones (DRIM). [14]

El primer sistema de gestión de fundamentos (RMS) fue PROTOCOL, que admitía PHI, al que siguieron otros sistemas basados ​​en PHI, MIKROPOLIS y PHIDIAS. El primer sistema que admitía IBIS fue STIEC de Hans Dehlinger. [15] Rittel desarrolló un pequeño sistema en 1983 (que tampoco se publicó) y el más conocido gIBIS (IBIS gráfico) se desarrolló en 1987. [16]

No todos los enfoques de DR exitosos implican una argumentación estructurada. Por ejemplo, el enfoque de análisis de escenarios y afirmaciones de Carroll y Rosson [17] captura la lógica en escenarios que describen cómo se utiliza el sistema y qué tan bien las características del sistema respaldan los objetivos del usuario. El enfoque de Carroll y Rosson para la lógica del diseño tiene como objetivo ayudar a los diseñadores de software y hardware de computadoras a identificar las compensaciones subyacentes del diseño y hacer inferencias sobre el impacto de las posibles intervenciones de diseño. [18]

Conceptos clave en la justificación del diseño

Existen diversas formas de caracterizar los enfoques de DR. Algunas características distintivas clave son cómo se capturan, cómo se representan y cómo se pueden utilizar.

Captura de la razón

La captura de fundamentos es el proceso de adquirir información de fundamentos para una gestión de fundamentos.

Métodos de captura
  • Un método llamado "Reconstrucción" [4] captura los fundamentos en un formato sin procesar, como un video, y luego los reconstruye en un formato más estructurado. [19] La ventaja del método de Reconstrucción es que los fundamentos se pueden capturar con cuidado y el proceso de captura no interrumpirá al diseñador. Pero este método puede resultar costoso y generar sesgos en la persona que produce los fundamentos.
  • El método de "grabar y reproducir" [4] simplemente captura los fundamentos a medida que se desarrollan. Los fundamentos se capturan sincrónicamente en una videoconferencia o de manera asincrónica a través de un tablón de anuncios o una discusión por correo electrónico. Si el sistema tiene una representación informal y semiformal, el método será útil.
  • El método del "subproducto metodológico" [4] captura las razones durante el proceso de diseño siguiendo un esquema. Pero es difícil diseñar un esquema de este tipo. La ventaja de este método es su bajo costo.
  • Con una rica base de conocimientos (KB) creada de antemano, el método "Aprendiz" [4] captura los fundamentos formulando preguntas cuando se está confundido o en desacuerdo con la acción del diseñador. Este método beneficia no solo al usuario sino también al sistema.
  • En el método de "Generación automática" [4] , las justificaciones de diseño se generan automáticamente a partir de un historial de ejecución a bajo costo. Tiene la capacidad de mantener justificaciones consistentes y actualizadas. Pero el costo de compilar el historial de ejecución es alto debido a la complejidad y dificultad de algunos problemas de aprendizaje automático.
  • El método "Historiador" [20] permite que una persona o un programa informático observe todas las acciones del diseñador, pero no hace sugerencias. Las razones se capturan durante el proceso de diseño. [19]

Representación racional

La elección de la representación de la justificación del diseño es muy importante para asegurarnos de que las justificaciones que capturamos sean las que deseamos y podamos utilizar de manera eficiente. Según el grado de formalidad, los enfoques que se utilizan para representar la justificación del diseño se pueden dividir en tres categorías principales: informales, semiformales o formales. [4] En la representación informal, las justificaciones se pueden registrar y capturar simplemente utilizando nuestros métodos y medios tradicionalmente aceptados, como procesadores de texto, registros de audio y video o incluso escrituras a mano. Sin embargo, estas descripciones dificultan la interpretación automática u otros soportes informáticos. En la representación formal, la justificación debe recopilarse bajo un formato estricto para que las computadoras puedan interpretarla y comprenderla. Sin embargo, debido al formato estricto de la justificación definido por las representaciones formales, los contenidos difícilmente pueden ser comprendidos por los seres humanos y el proceso de captura de la justificación del diseño requerirá más esfuerzos para finalizar, y por lo tanto se vuelve más intrusivo.

Las representaciones semiformales intentan combinar las ventajas de las representaciones informales y formales. Por un lado, la información capturada debe poder ser procesada por computadoras para que se pueda proporcionar un mayor soporte informático. Por otro lado, el procedimiento y el método utilizados para capturar la información de la justificación del diseño no deben ser muy intrusivos. En el sistema con una representación semiformal, se sugiere la información esperada y los usuarios pueden capturar la justificación siguiendo las instrucciones para completar los atributos de acuerdo con algunas plantillas o simplemente escribir descripciones en lenguaje natural. [4]

Modelos basados ​​en argumentación

El modelo de Toulmin
Una forma comúnmente aceptada de representación semiformal de la justificación del diseño es estructurarla como argumentación. [5] El primer modelo basado en argumentación utilizado por muchos sistemas de justificación del diseño es el modelo de Toulmin. [7] El modelo de Toulmin define las reglas de la argumentación de la justificación del diseño con seis pasos: [21]
  1. Se hace la reclamación;
  2. Se proporcionan datos de apoyo;
  3. La orden proporciona evidencia de las relaciones existentes;
  4. La garantía puede estar respaldada por un respaldo;
  5. Se proporcionan calificadores de modelo (algunos, muchos, la mayoría, etc.);
  6. También se consideran posibles refutaciones.
Una ventaja del modelo Toulmin es que utiliza palabras y conceptos que la mayoría de las personas pueden entender fácilmente.
Sistema de información basado en cuestiones (IBIS)
Otro enfoque importante para la argumentación de la lógica del diseño es el IBIS ( Sistema de información basado en problemas ) de Rittel y Kunz, [1] que en realidad no es un sistema de software sino una notación argumentativa. Se ha implementado en forma de software mediante gIBIS (IBIS gráfico), itIBIS (IBIS basado en pruebas), Compendium y otro software. [22] [23] IBIS utiliza algunos elementos de lógica (denotados como nodos) como problemas, posiciones, argumentos, resoluciones y varias relaciones como más general que, sucesor lógico de, sucesor temporal de, reemplaza y similar a, para vincular las discusiones de problemas.
Jerarquía procesal de cuestiones (PHI)
La PHI (Jerarquía procesal de cuestiones) [24] amplió el sistema IBIS a cuestiones no controvertidas y redefinió las relaciones. La PHI añade la relación de subtema, lo que significa que la resolución de una cuestión depende de la resolución de otra cuestión.
Preguntas, opciones y criterios (QOC)
QOC (Preguntas, Opciones y Criterios) [25] se utiliza para el análisis del espacio de diseño. De manera similar a IBIS, QOC identifica los problemas de diseño clave como preguntas y las posibles respuestas a las preguntas como opciones. Además, QOC utiliza criterios para describir explícitamente los métodos para evaluar las opciones, como los requisitos que se deben satisfacer o las propiedades deseadas. Las opciones se vinculan con los criterios de forma positiva o negativa y estos vínculos se definen como evaluaciones.
Lenguaje de representación de decisiones (DRL)
El lenguaje de representación de decisiones (DRL) [26] extiende el modelo de DR de Potts y Bruns [9] y define los elementos primarios como problemas de decisión, alternativas, objetivos, reivindicaciones y grupos. Lee (1991) ha sostenido que el lenguaje de representación de decisiones (DRL) es más expresivo que otros lenguajes. [26] El lenguaje de representación de decisiones (DRL) se centra más en la representación de la toma de decisiones y su fundamento en lugar de en el fundamento del diseño.
Hablar de ratas
Basado en DRL, RATSpeak se desarrolló y se utilizó como lenguaje de representación en SEURAT (Software Engineering Using RATionale). [27] RATSpeak tiene en cuenta los requisitos (funcionales y no funcionales) como parte de los argumentos para las alternativas a los problemas de decisión. SEURAT también incluye una ontología de argumentos que es una jerarquía de tipos de argumentos e incluye los tipos de afirmaciones utilizadas en el sistema.
Modelo espiral WinWin
El modelo espiral WinWin, que se utiliza en el enfoque WinWin, [28] agrega las actividades de negociación WinWin, incluida la identificación de las partes interesadas clave de los sistemas y la identificación de las condiciones de ganancia de cada parte interesada y la negociación, al frente de cada ciclo del modelo de desarrollo de software en espiral [29] para lograr un acuerdo mutuamente satisfactorio (winwin) para todas las partes interesadas del proyecto.
En el modelo WinWin Spiral, los objetivos de cada parte interesada se definen como condiciones de victoria. Una vez que hay un conflicto entre las condiciones de victoria, se captura como un problema. Luego, las partes interesadas inventan opciones y exploran compensaciones para resolver el problema. Cuando se resuelve el problema, se logra un acuerdo que satisface las condiciones de victoria de las partes interesadas y captura la opción acordada. La lógica de diseño detrás de las decisiones se captura durante el proceso del modelo WinWin y será utilizada por las partes interesadas y los diseñadores para mejorar su toma de decisiones posterior. [28] El modelo WinWin Spiral reduce los gastos generales de la captura de la lógica de diseño al proporcionar a las partes interesadas un proceso bien definido para negociar. En [30] se define una ontología de la lógica de decisión y su modelo utiliza la ontología para abordar el problema de respaldar el mantenimiento de decisiones en el marco de colaboración WinWin.
Modelo de recomendación e intención de diseño (DRIM)
En SHARED-DRIM se utiliza DRIM (Design Recommendation and Intent Model). [14] La estructura principal de DRIM es una propuesta que consta de las intenciones de cada diseñador, las recomendaciones que satisfacen las intenciones y las justificaciones de las recomendaciones. También se necesitan negociaciones cuando existen conflictos entre las intenciones de diferentes diseñadores. La recomendación aceptada se convierte en una decisión de diseño, y la justificación de las recomendaciones no aceptadas pero propuestas también se registra durante este proceso, lo que puede ser útil durante el diseño iterativo y/o el mantenimiento del sistema.

Aplicaciones

La lógica del diseño puede utilizarse de muchas maneras diferentes. Burge y Brown (1998) [19] definen un conjunto de usos :

  • Verificación del diseño: la justificación del diseño se puede utilizar para verificar si las decisiones de diseño y el producto en sí son el reflejo de lo que los diseñadores y los usuarios realmente querían.
  • Evaluación del diseño: la justificación del diseño se utiliza para evaluar las distintas alternativas de diseño discutidas durante el proceso de diseño.
  • Mantenimiento del diseño: la justificación del diseño ayuda a determinar los cambios necesarios para modificar el diseño.
  • Reutilización del diseño: la justificación del diseño se utiliza para determinar cómo se podría reutilizar el diseño existente para un nuevo requisito con o sin cambios. Si es necesario modificar el diseño, el DR también sugiere qué se debe modificar en el diseño.
  • Enseñanza del diseño: los fundamentos del diseño podrían usarse como recurso para enseñar a personas que no están familiarizadas con el diseño y el sistema.
  • Comunicación del diseño: la lógica del diseño facilita una mejor comunicación entre las personas que participan en el proceso de diseño y, por lo tanto, ayuda a crear un mejor diseño.
  • Asistencia de diseño: la justificación del diseño podría utilizarse para verificar las decisiones de diseño tomadas durante el proceso de diseño.
  • Documentación de diseño: la justificación del diseño se utiliza para documentar todo el proceso de diseño, que incluye las deliberaciones en la sala de reuniones, las alternativas discutidas, las razones detrás de las decisiones de diseño y la descripción general del producto.

La DR se utiliza en comunidades de investigación en ingeniería de software, diseño mecánico, inteligencia artificial, ingeniería civil e investigación de interacción hombre-computadora. En ingeniería de software, se podría utilizar para respaldar las ideas de los diseñadores durante el análisis de requisitos, capturando y documentando reuniones de diseño y prediciendo posibles problemas debido a un nuevo enfoque de diseño. [31] En la arquitectura de software y el diseño de soluciones de subcontratación, puede justificar el resultado de las decisiones arquitectónicas y servir como guía de diseño. [32] En ingeniería civil, ayuda a coordinar la variedad de trabajos que los diseñadores realizan al mismo tiempo en diferentes áreas de un proyecto de construcción. También ayuda a los diseñadores a comprender y respetar las ideas de los demás y resolver cualquier posible problema. [33]

Los gerentes de proyectos también pueden utilizar el DR para mantener actualizados el plan y el estado del proyecto. Asimismo, los miembros del equipo del proyecto que no hayan asistido a una reunión de diseño pueden consultar el DR para saber qué se discutió sobre un tema en particular. Los problemas no resueltos capturados en el DR podrían utilizarse para organizar reuniones posteriores sobre esos temas. [31]

La lógica del diseño ayuda a los diseñadores a evitar los mismos errores cometidos en el diseño anterior. Esto también puede ser útil para evitar la duplicación del trabajo. [5] En algunos casos, la recuperación ante desastres puede ahorrar tiempo y dinero cuando se actualiza un sistema de software a partir de sus versiones anteriores. [2]

Hay varios libros y artículos que ofrecen excelentes estudios de los enfoques racionales aplicados a la HCI, [34] el diseño de ingeniería [4] y la ingeniería de software. [35]

Véase también

Referencias

  1. ^ abc Kunz, W.; Rittel, H. (1970), Cuestiones como elementos de los sistemas de información . Documento de trabajo 131, Centro de Desarrollo Urbano y Regional, Universidad de California Berkeley
  2. ^ abc Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Fundamentos del diseño para la ingeniería de software: una encuesta", 25.ª Conferencia internacional de Hawái sobre ciencias de sistemas , 2, págs. 577-586
  3. ^ ab Horner, J.; Atwood, ME (2006), "Fundamentos de diseño eficaces: comprensión de las barreras", en Dutoit, AH; McCall, R.; Mistrík, I. et al., Gestión de fundamentos en ingeniería de software, Springer Berlin Heidelberg, págs. 73-90
  4. ^ abcdefghi Lee, J. (1997). "Sistemas de diseño racional: comprensión de los problemas". IEEE Expert 12 (3): 78–85
  5. ^ abcd Burge, JE; Brown, DC (2000), "Razonamiento con fundamentos de diseño", en Gero, J., Inteligencia artificial en el diseño '00 , Países Bajos: Kluwer Academic Publ., págs. 611–629
  6. ^ Xin, W.; Guangleng, X. (2001), "La justificación del diseño como parte de la memoria técnica corporativa", Sistemas, hombre y cibernética , págs. 1904 - 1908.
  7. ^ de Stephen Toulmin (1958). Los usos del argumento . Cambridge: Cambridge University Press.
  8. ^ McCall, R. (1978), Sobre la estructura y el uso de sistemas de problemas en el diseño , Tesis doctoral, Universidad de California, Berkeley, University Microfilms
  9. ^ ab Potts, C.; Burns, G. (1988), "Registro de las razones para las decisiones de diseño", 10.ª Conferencia Internacional sobre Ingeniería de Software (ICSE '1988), págs. 418-427
  10. ^ Lee, J. (1991), "Extensión del modelo de Potts y Bruns para registrar la justificación del diseño", Actas de la 13.ª Conferencia internacional sobre ingeniería de software (ICSE '13) , IEEE Computer Society Press, Los Alamitos, CA, págs. 114-125
  11. ^ Maclean, A.; Young, RM.; Moran, T. (1989), "Fundamento del diseño: el argumento detrás del artefacto", SIGCHI Bull . 20, págs. 247-252114-125
  12. ^ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Preguntas, opciones y criterios: elementos del análisis del espacio de diseño", en Moran, T.; Carroll, J., Conceptos, técnicas y uso de la justificación del diseño, Lawrence Erlbaum Associates , págs. 53-106
  13. ^ Barry Boehm , Ross, R (1989). "Gestión de proyectos de software de teoría-W: principios y ejemplos". IEEE Transactions on Software Engineering 18 (7): 902-916.
  14. ^ ab Pena-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: Sistema de gestión de recomendaciones e intenciones de diseño compartido", Actas de Enabling Technologies Infrastructure for Collaborative Enterprise , IEEE Press, Morgantown, WV, págs. 213-221
  15. ^ Dehlinger, H. (1978), Proyecto STIEC: Análisis de sistemas de generación y difusión de información científica y tecnológica en la Comunidad Europea", Informe nº 26: Informe sobre una versión en lote del STIEC , Heidelberg/Stuttgart
  16. ^ Conklin, J.; YakemBegemanovic, M. (1988). "gIBIS: Una herramienta de hipertexto para la discusión exploratoria de políticas". ACM Transactions on Office Information Systems 6 (4): 303-331.
  17. ^ Carroll, JM; Rosson, M (1992). "Cómo sortear el ciclo tarea-artefacto: cómo formular afirmaciones y diseñar por escenario". ACM Trans. Inf. Syst . 10 (2): 181-212
  18. ^ Carroll, JM y Rosson, MB (2003). La justificación del diseño como teoría. Modelos, teorías y marcos de trabajo de la HCI: hacia una ciencia multidisciplinaria, 431-461.
  19. ^ abc Burge, J.; Brown, DC (1998), Fundamento del diseño: tipos y herramientas, Informe técnico, Instituto Politécnico de Worcester, Departamento de Ciencias de la Computación, consultado el 27 de abril de 2007
  20. ^ Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "Representación del conocimiento en la historia del diseño y su implementación informática básica", Segunda Conferencia Internacional sobre Teoría y Metodología del Diseño, Chicago, IL, págs. 175-185
  21. ^ Reynolds, Chris (2000), ¿Qué es el modelo de Toulmin? Archivado el 25 de agosto de 2007 en Wayback Machine . Artículo en concentric.net.
  22. ^ Conklin, J.; Yakemovic, K. (1991). "Un enfoque orientado a procesos para la justificación del diseño". Human-Computer Interaction 6 (3 y 4): 357–391.
  23. ^ Rittel, Horst WJ ; Noble, Douglas (enero de 1989). Sistemas de información basados ​​en problemas para el diseño (PDF) (Informe técnico). Berkeley, CA: Instituto de Desarrollo Urbano y Regional, Universidad de California . OCLC  20155825. 492.
  24. ^ McCall, RJ (1991). "PHI: una base conceptual para el hipermedia de diseño". Design Studies 12 (1): 30–41.
  25. ^ Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Preguntas, opciones y criterios: elementos del análisis del espacio de diseño", en Moran, T.; Carroll, J., Conceptos, técnicas y uso de la justificación del diseño , Lawrence Erlbaum Associates, págs. 53-106
  26. ^ ab Lee, J. (1991), "Extensión del modelo de Potts y Bruns para registrar la justificación del diseño", Actas de la 13.ª Conferencia internacional sobre ingeniería de software (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, págs. 114-125
  27. ^ Burge, J. (2005), Ingeniería de software utilizando el diseño RATionale, Instituto Politécnico de Worcester, Departamento de Ciencias de la Computación
  28. ^ por Barry Boehm ; Kitapci, H. (2006), "El enfoque WinWin: uso de una herramienta de negociación de requisitos para la captura y uso de fundamentos", en Dutoit, AH; McCall, R.; Mistrík, I. et al., Gestión de fundamentos en ingeniería de software , Springer Berlin Heidelberg, págs. 173-190
  29. ^ Barry Boehm (1998). "Un modelo en espiral de desarrollo y mejora de software". Computer 21 (5): 61–72
  30. ^ Bose, P. (1995). "Un modelo para el mantenimiento de decisiones en el marco de colaboración WinWin". Ingeniería de software basada en el conocimiento (KBSE '95).
  31. ^ ab Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Gestión de fundamentos en ingeniería de software , Springer pp.1-48.
  32. ^ O. Zimmermann, C. Miksovic, J. Küster, Arquitectura de referencia, metamodelo y principios de modelado para la gestión del conocimiento arquitectónico en servicios de tecnología de la información. Journal of Systems and Software, Elsevier. Vol. 85, número 9, septiembre de 2012
  33. ^ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Aplicación de sistemas de justificación del diseño a la definición de proyectos: establecimiento de un proyecto de investigación. Archivado el 28 de septiembre de 2007 en Wayback Machine. Recuperado el 27 de abril de 2007.
  34. ^ Moran, T.; Carroll, J., eds. (1996), Fundamentos del diseño, conceptos, técnicas y uso , Lawrence Erlbaum Associates,
  35. ^ Dutoit, Gestión de la razón de ser en la ingeniería de software

Lectura adicional

Libros
  • Burge, JE; Carroll, JM; McCall R; Mistrík I (2008). Ingeniería de software basada en fundamentos . Heidelberg: Springer-Verlag.
  • Dutoit, AH; McCall R; Mistrík I; Paech B (2006). Gestión de Fundamentos en Ingeniería de Software . Heidelberg: Springer-Verlag.
  • Conklin, J (2005). Mapeo del diálogo . Weinheim: Wiley-VCH Verlag.
  • Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Visualización de la argumentación: herramientas de software para la construcción colaborativa y educativa de sentido . Londres: Springer-Verlag.
  • Moran, T; Carroll J (1996). Fundamentos del diseño: conceptos, técnicas y uso . Nueva Jersey: Lawrence Erlbaum Associates.
Ediciones especiales
  • Inteligencia artificial para el diseño, análisis y fabricación de ingeniería (AIEDAM), número especial: otoño de 2008, vol. 22, n.º 4 Fundamento del diseño http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html
  • Inteligencia artificial para el diseño, análisis y fabricación de ingeniería (AIEDAM), número especial sobre la representación y el uso de la justificación del diseño, 1997, vol. 11, n.º 2, Cambridge University Press
Talleres
  • Segundo taller sobre intercambio y reutilización de conocimientos arquitectónicos: arquitectura, fundamentos e intención de diseño (SHARK/ADI 2007), (RC.rug.nl) como parte de la 29.ª Conferencia Internacional sobre Ingeniería de Software (ICSE 2007) (CS.ucl.ac.uk)
  • Taller sobre fundamentos del diseño: problemas y avances (Muohio.edu)
  • Moderadores del taller: Janet Burge y Rob Bracewell, celebrado el 9 de julio de 2006 en colaboración con Design, Computing, and Cognition '06. Eindhoven (wwwfaculty.arch.usyd.edu.au), Países Bajos
  • Bcisive.austhink.com: Un paquete de software comercial diseñado para la justificación del diseño y la toma de decisiones en general. Interfaz gráfica, capacidades para compartir.
  • Compendio: herramienta hipermedia que ofrece capacidades de gestión visual del conocimiento basadas en IBIS. Aplicación Java gratuita, en formato binario y fuente, con una comunidad de usuarios activa que se reúne anualmente.
  • designVUE: una herramienta para la captura visual de conocimiento basada en IBIS y otros métodos. Aplicación Java gratuita.
  • SEURAT: un complemento de Eclipse que integra la captura y el uso de fundamentos con un entorno de desarrollo de software. SEURAT está disponible como un proyecto de código abierto en GitHub ([1]).
Obtenido de "https://es.wikipedia.org/w/index.php?title=Fundamento_del_diseño&oldid=1212324013"