Una justificación del 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 lo desarrollaron inicialmente WR Kunz y Horst Rittel , la lógica del diseño busca proporcionar una estructura basada en la argumentación al proceso político y colaborativo de abordar problemas complejos . [1]
Descripción general
Una justificación del diseño es la lista explícita de decisiones tomadas durante un proceso de diseño y las razones por las que se tomaron esas decisiones. [2] Su objetivo principal es apoyar a los diseñadores proporcionándoles un medio para registrar y comunicar la argumentación y el razonamiento detrás del proceso de diseño. [3]
Por lo tanto, debería incluir: [4]
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 justificación del diseño se remonta al desarrollo de WR Kunz y Horst Rittel [1]. de la notación del Sistema de información basado en problemas (IBIS) en 1970. Desde entonces se han propuesto varias variantes de IBIS.
El primero fue la Jerarquía procesal de cuestiones (PHI), descrita por primera vez en la tesis doctoral de Ray McCall [8], aunque no se nombró en ese momento.
Potts & Bruns también modificó IBIS, en este caso para admitir ingeniería de software. [9] El enfoque de Potts & Bruns fue luego ampliado por el lenguaje de representación de decisiones (DRL). [10] que a su vez fue ampliado por RATSpeak. [5]
Preguntas, opciones y criterios (QOC), también conocido como Análisis del espacio de diseño [11] [12], es una representación alternativa para el razonamiento basado en argumentación, al igual que Win-Win [13] y el modelo de intención y recomendación de decisiones (DRIM). [14]
El primer sistema de gestión racional (RMS) fue PROTOCOL, que admitía PHI, al que siguieron otros sistemas basados en PHI, MIKROPOLIS y PHIDIAS. El primer sistema que apoyó a IBIS fue el STIEC de Hans Dehlinger. [15] Rittel desarrolló un pequeño sistema en 1983 (tampoco publicado) y el más conocido gIBIS (IBIS gráfico) se desarrolló en 1987. [16]
No todos los enfoques exitosos de DR 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 de los 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 sobre la justificación del diseño tiene como objetivo ayudar a los diseñadores de software y hardware de computadora a identificar las compensaciones subyacentes del diseño y hacer inferencias sobre el impacto de posibles intervenciones de diseño. [18]
Conceptos clave en la justificación del diseño.
Hay varias formas de caracterizar los enfoques de recuperación ante desastres. Algunas características distintivas clave son cómo se captura, cómo se representa y cómo se puede utilizar.
Captura de fundamentos
La captura de fundamentos es el proceso de adquirir información racional para una gestión racional.
Métodos de captura
Un método llamado "Reconstrucción" [4] captura los fundamentos en una forma sin procesar, como un video, y luego los reconstruye en una forma más estructurada. [19] La ventaja del método de Reconstrucción es que los fundamentos se pueden capturar cuidadosamente y el proceso de captura no perturbará al diseñador. Pero este método podría resultar en un alto costo y en sesgos por parte de la persona que presenta los fundamentos.
El método "Grabar y reproducir" [4] simplemente captura los fundamentos a medida que se desarrollan. Los fundamentos se capturan de forma sincrónica en una videoconferencia o de forma asincrónica a través de un tablero de anuncios o una discusión por correo electrónico. Si el sistema tiene representación informal y semiformal, el método será útil.
El método del "Subproducto metodológico" [4] captura los fundamentos durante el proceso de diseño siguiendo un esquema. Pero es difícil diseñar un esquema así. La ventaja de este método es su bajo coste.
Con una rica base de conocimiento (KB) creada de antemano, el método "Aprendiz" [4] captura los fundamentos al hacer preguntas cuando se confunde o no se está de acuerdo con la acción del diseñador. Este método beneficia no sólo al usuario sino también al sistema.
En el método de "Generación automática" [4] , los fundamentos del diseño se generan automáticamente a partir de un historial de ejecución a bajo costo. Tiene la capacidad de mantener fundamentos coherentes y actualizados. 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 de computadora observe todas las acciones del diseñador pero no haga sugerencias. Los fundamentos se capturan durante el proceso de diseño. [19]
Representación racional
La elección de la representación de los fundamentos del diseño es muy importante para asegurarnos de que los fundamentos que capturamos sean los que deseamos y podemos utilizar de manera eficiente. Según el grado de formalidad, los enfoques que se utilizan para representar la lógica del diseño se pueden dividir en tres categorías principales: informal, semiformal o formal. [4] En la representación informal, los fundamentos 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 escritos a mano. Sin embargo, estas descripciones dificultan la interpretación automática u otros soportes informáticos. En la representación formal, los fundamentos deben recopilarse bajo un formato estricto para que los ordenadores puedan interpretarlos y comprenderlos. Sin embargo, debido al formato estricto de la lógica definida por las representaciones formales, los contenidos difícilmente pueden ser entendidos por el ser humano y el proceso de capturar la lógica del diseño requerirá más esfuerzos para terminar y, por lo tanto, se vuelve más intrusivo.
Las representaciones semiformales intentan combinar las ventajas de las representaciones formales e informales. Por un lado, la información capturada debería poder ser procesada por computadoras para poder brindar más soporte informático. Por otro lado, el procedimiento y método utilizado para capturar información sobre la justificación del diseño no debería ser muy intrusivo. 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 Toulmin
Una forma comúnmente aceptada de representación semiformal de la justificación del diseño es estructurar la justificación del diseño 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 argumentación de la justificación del diseño con seis pasos: [21]
Se hace el reclamo;
Se proporcionan datos de respaldo;
La orden proporciona evidencia de las relaciones existentes;
La garantía puede estar respaldada por un respaldo;
Se proporcionan calificadores de modelo (algunos, muchos, la mayoría, etc.);
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 problemas (IBIS)
Otro enfoque importante para la argumentación de los fundamentos 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. Ha sido implementado en forma de software por gIBIS (IBIS gráfico), itIBIS (IBIS basado en pruebas), Compendium y otro software. [22] [23] IBIS utiliza algunos elementos racionales (denotados como nodos), como cuestiones, posiciones, argumentos, resoluciones y varias relaciones, como más general que, sucesor lógico de, sucesor temporal de, reemplaza y similar a, para vincular el discusiones sobre temas
Jerarquía procesal de cuestiones (PHI)
PHI (Jerarquía procesal de cuestiones) [24] extendió IBIS a cuestiones no controvertidas y redefinió las relaciones. PHI agrega la relación de subtema, lo que significa que la resolución de un problema depende de la resolución de otro problema.
Preguntas, opciones y criterios (QOC)
QOC (Preguntas, Opciones y Criterios) [25] se utiliza para el análisis del espacio de diseño. Al igual que IBIS, QOC identifica los problemas clave de diseño 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 deben satisfacerse o las propiedades deseadas. Las opciones se vinculan con criterios de manera positiva o negativa y estos vínculos se definen como valoraciones.
Lenguaje de representación de decisiones (DRL)
DRL (Decision Representation Language) [26] extiende el modelo de Potts y Bruns de DR [9] y define los elementos primarios como problemas de decisión, alternativas, metas, reclamos y grupos. Lee (1991) ha sostenido que DRL es más expresivo que otros lenguajes. [26] DRL se centra más en la representación de la toma de decisiones y su justificación que en la justificación del diseño.
RATAShabla
Basado en DRL, RATSpeak se desarrolla y utiliza como lenguaje de representación en SEURAT (Ingeniería de software utilizando RATionale). [27] RATSpeak tiene en cuenta los requisitos (funcionales y no funcionales) como parte de los argumentos para 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 en 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 ganadoras de cada parte interesada y negociación, al frente de cada ciclo de la espiral. modelo de desarrollo de software [29] con el fin de lograr un acuerdo mutuamente satisfactorio (winwin) para todas las partes interesadas del proyecto.
En el modelo en espiral WinWin, los objetivos de cada actor se definen como condiciones Win. 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 del 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 del diseño al proporcionar a las partes interesadas un proceso bien definido para negociar. En [30] se define una ontología del fundamento de la 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 intención y recomendación de diseño (DRIM)
DRIM (modelo de intención y recomendación de diseño) se utiliza en SHARED-DRIM. [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. Las negociaciones también son necesarias 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 tiene el potencial de usarse de muchas maneras diferentes. Un conjunto de usos, definido por Burge y Brown (1998), [19] son:
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 diversas 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 en el mismo. Si es necesario modificar el diseño, el DR también sugiere lo que debe modificarse en el diseño.
Enseñanza del diseño: la justificación del diseño podría utilizarse 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 generar un mejor diseño.
Asistencia en el 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 involucra 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 es utilizada por comunidades de investigación en ingeniería de software, diseño mecánico, inteligencia artificial, ingeniería civil e investigación de interacción persona-computadora. En ingeniería de software, podría usarse para respaldar las ideas de los diseñadores durante el análisis de requisitos, capturar y documentar reuniones de diseño y predecir 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 a resolver cualquier posible problema. [33]
Los gerentes de proyecto también pueden utilizar el DR para mantener actualizado su plan de proyecto y el estado del mismo. Además, los miembros del equipo del proyecto que faltaron a una reunión de diseño pueden consultar el DR para conocer lo que se discutió sobre un tema en particular. Las cuestiones no resueltas capturadas en la República Dominicana podrían utilizarse para organizar futuras reuniones 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 resultar útil para evitar la duplicación de trabajo. [5] En algunos casos, la recuperación ante desastres podría ahorrar tiempo y dinero cuando un sistema de software se actualiza desde sus versiones anteriores. [2]
Hay varios libros y artículos que brindan excelentes estudios sobre los enfoques racionales aplicados a HCI, [34] Diseño de ingeniería [4] e Ingeniería de software. [35]
^ abc Kunz, W.; Rittel, H. (1970), Cuestiones como elementos de los sistemas de información . Documento de trabajo 131, Centro para el Desarrollo Urbano y Regional, Universidad de California Berkeley
^ abc Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Design Rationale for Software Engineering: A Survey", 25ª Conferencia Internacional de Hawaii sobre Ciencias de Sistemas , 2, págs. 577-586
^ ab Horner, J.; Atwood, ME (2006), "Fundamentos del diseño eficaz: comprensión de las barreras", en Dutoit, AH; McCall, R.; Mistrík, I. et al., Gestión racional en ingeniería de software, Springer Berlin Heidelberg, págs. 73-90
^ abcdefghi Lee, J. (1997). "Sistemas de justificación del diseño: comprensión de los problemas". Experto IEEE 12 (3): 78–85
^ abcd Burge, JE; Brown, DC (2000), "Reasoning with Design Rationale", en Gero, J., Artificial Intelligence in Design '00 , Países Bajos: Kluwer Academic Publ., págs.
^ Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory", Systems, Man and Cybernetics , págs. 1904 - 1908.
^ ab Stephen Toulmin (1958). Los usos del argumento . Cambridge: Prensa de la Universidad de Cambridge.
^ McCall, R. (1978), Sobre la estructura y el uso de sistemas temáticos en el diseño , Tesis doctoral, Universidad de California, Berkeley, Microfilms universitarios
^ ab Potts, C.; Burns, G. (1988), "Recording the Reasons for Design Decisions", Décima Conferencia Internacional sobre Ingeniería de Software (ICSE '1988), págs. 418-427
^ Lee, J. (1991), "Ampliación del modelo de Potts y Bruns para registrar los fundamentos 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
^ Maclean, A.; Joven, RM.; Moran, T. (1989), "Fundamentos del diseño: el argumento detrás del artefacto", SIGCHI Bull . 20, págs. 247-252114-125
^ Maclean, A.; Joven, 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
^ Barry Boehm , Ross, R (1989). "Gestión de proyectos de software Theory-W: principios y ejemplos". Transacciones IEEE sobre ingeniería de software 18 (7): 902-916.
^ ab Peña-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design Recommendation-Intent Management System", Actas que habilitan la infraestructura de tecnologías para empresas colaborativas , IEEE Press, Morgantown, WV, págs.
^ 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 un lote - Versión de STIEC , Heidelberg/Stuttgart
^ Conklin, J.; YakemBegemanovic, M. (1988). "gIBIS: una herramienta de hipertexto para el debate exploratorio de políticas". Transacciones ACM en sistemas de información de oficina 6 (4): 303-331.
^ Carroll, JM; Rosson, M (1992). "Solucionar el ciclo tarea-artefacto: cómo hacer afirmaciones y diseñar por escenario". Transmisión ACM. inf. Sistema . 10 (2): 181-212
^ Carroll, JM y Rosson, MB (2003). La justificación del diseño como teoría. Modelos, teorías y marcos de HCI: hacia una ciencia multidisciplinaria, 431-461.
^ abc Burge, J.; Brown, DC (1998), Design Rationale: Types and Tools, Informe técnico, Instituto Politécnico de Worcester, Departamento de Ciencias de la Computación, consultado el 27 de abril de 2007.
^ Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "Representación del conocimiento de 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.
^ Reynolds, Chris (2000), ¿Qué es el modelo de Toulmin? Archivado el 25 de agosto de 2007 en Wayback Machine Paper en concentric.net.
^ Conklin, J.; Yakemovic, K. (1991). "Un enfoque orientado a procesos para la justificación del diseño". Interacción persona-computadora 6 (3 y 4): 357–391.
^ Rittel, Horst WJ ; Noble, Douglas (enero de 1989). Sistemas de información basados en problemas para el diseño (PDF) (Reporte técnico). Berkeley, CA: Instituto de Desarrollo Urbano y Regional, Universidad de California . OCLC 20155825. 492.
^ McCall, RJ (1991). "PHI: una base conceptual para el diseño hipermedia". Estudios de diseño 12 (1): 30–41.
^ Maclean, A.; Joven, 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
^ ab Lee, J. (1991), "Ampliación del modelo de Potts y Bruns para registrar los fundamentos 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
^ Burge, J. (2005), Ingeniería de software utilizando el diseño RATionale, Instituto Politécnico de Worcester, Departamento de Ciencias de la Computación
^ ab Barry Boehm ; Kitapci, H. (2006), "El enfoque WinWin: uso de una herramienta de negociación de requisitos para la captura y el uso de la justificación", en Dutoit, AH; McCall, R.; Mistrík, I. et al., Gestión racional en ingeniería de software , Springer Berlin Heidelberg, págs. 173-190
^ Barry Boehm (1998). "Un modelo en espiral de desarrollo y mejora de software". Computadora 21 (5): 61–72
^ Bosé, 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).
^ ab Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Gestión racional en ingeniería de software , Springer págs.1-48.
^ 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. Revista de sistemas y software, Elsevier. vol. 85, número 9, septiembre de 2012
^ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Aplicación de sistemas de justificación del diseño a la definición del proyecto: establecimiento de un proyecto de investigación. Archivado el 28 de septiembre de 2007 en Wayback Machine. Consultado el 27 de abril de 2007.
^ Morán, T.; Carroll, J., eds. (1996), Conceptos, técnicas y uso de la justificación del diseño , Lawrence Erlbaum Associates,
^ Dutoit, Gestión racional en ingeniería de software
Otras lecturas
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 creación de sentido colaborativo y educativo . Londres: Springer-Verlag.
Morán, T; Carroll J (1996). Conceptos, técnicas y uso de la justificación del diseño . Nueva Jersey: Lawrence Erlbaum Associates.
Cuestiones 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 No.4 Design Rationale 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 lógica del diseño, 1997, Vol.11 No.2, Cambridge University Press
Talleres de trabajo
Segundo taller sobre COMPARTIR y reutilizar el conocimiento arquitectónico: arquitectura, fundamento e intención de diseño (SHARK/ADI 2007), (RC.rug.nl) como parte del 29º Taller Int. Conf. en Ingeniería de Software (ICSE 2007) (CS.ucl.ac.uk)
Taller sobre fundamentos del diseño: problemas y progreso (Muohio.edu)
Moderadores del taller: Janet Burge y Rob Bracewell, celebrado el 9 de julio de 2006 junto con Design, Computing, and Cognition '06. Eindhoven, (wwwfaculty.arch.usyd.edu.au) Países Bajos
enlaces externos
Bcisive.austhink.com: Un paquete de software comercial diseñado para la justificación del diseño y la toma de decisiones de manera más amplia. Interfaz gráfica, capacidades para compartir.
Compendio: una herramienta hipermedia que proporciona capacidades de gestión del conocimiento visual basadas en IBIS. Aplicación Java gratuita, binaria y fuente, con una comunidad de usuarios activa que se reúne anualmente.
designVUE: una herramienta para la captura de conocimiento visual basada en IBIS y otros métodos. Aplicación Java gratuita.
SEURAT: complemento de Eclipse que integra la captura y el uso de fundamentos con un entorno de desarrollo de software. SEURAT está disponible como proyecto de código abierto en GitHub ([1]).