stringtranslate.com

Justificación 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.

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]

Varias áreas de la ciencia 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 la lógica 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 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 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

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]
  1. Se hace el reclamo;
  2. Se proporcionan datos de respaldo;
  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 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:

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]

Ver también

Referencias

  1. ^ 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
  2. ^ 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
  3. ^ 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
  4. ^ abcdefghi Lee, J. (1997). "Sistemas de justificación del diseño: comprensión de los problemas". Experto IEEE 12 (3): 78–85
  5. ^ 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.
  6. ^ Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory", Systems, Man and Cybernetics , págs. 1904 - 1908.
  7. ^ ab Stephen Toulmin (1958). Los usos del argumento . Cambridge: Prensa de la Universidad de Cambridge.
  8. ^ 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
  9. ^ 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
  10. ^ 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
  11. ^ 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
  12. ^ 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
  13. ^ 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.
  14. ^ 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.
  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 un lote - Versión de STIEC , Heidelberg/Stuttgart
  16. ^ 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.
  17. ^ 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
  18. ^ 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.
  19. ^ 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.
  20. ^ 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.
  21. ^ Reynolds, Chris (2000), ¿Qué es el modelo de Toulmin? Archivado el 25 de agosto de 2007 en Wayback Machine Paper en concentric.net.
  22. ^ 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.
  23. ^ 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.
  24. ^ McCall, RJ (1991). "PHI: una base conceptual para el diseño hipermedia". Estudios de diseño 12 (1): 30–41.
  25. ^ 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
  26. ^ 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
  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. ^ 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
  29. ^ Barry Boehm (1998). "Un modelo en espiral de desarrollo y mejora de software". Computadora 21 (5): 61–72
  30. ^ 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).
  31. ^ ab Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Gestión racional en ingeniería de software , Springer págs.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. Revista de sistemas y 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 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.
  34. ^ Morán, T.; Carroll, J., eds. (1996), Conceptos, técnicas y uso de la justificación del diseño , Lawrence Erlbaum Associates,
  35. ^ Dutoit, Gestión racional en ingeniería de software

Otras lecturas

Libros
Cuestiones especiales
Talleres de trabajo

enlaces externos