stringtranslate.com

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.

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]

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.

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

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 :

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
Ediciones especiales
Talleres

Enlaces externos