formalización algebraica del método de arriba hacia...
Post on 08-Oct-2018
215 Views
Preview:
TRANSCRIPT
Página 1 de 32
Formalización algebraica del método de arriba hacia
abajo de diseño tecnológico
Juan Manuel García-Chamizo y Mario Nieto-Hidalgo
1Department of Computer Technology, University of Alicante,
P.O. Box 99, E-03080 Alicante, Spain
{juanma,mnieto}@dtic.ua.es
Resumen. La literatura sobre ingeniería del software contiene numerosas
propuestas para sistematizar las operaciones de diseño y ayudar en la toma de
decisiones relacionadas con las soluciones a los problemas. Este artículo
propone un marco conceptual para justificar la técnica de arriba hacia abajo que
se sigue en el diseño tecnológico. El punto de partida es el enunciado de un
problema en su versión de conjetura inicial, esto es, una hipótesis, y consta de
una fase inicial que es esencialmente del ámbito del problema, y una segunda
fase que es esencialmente del dominio de la solución. La fase del dominio del
problema aborda una técnica para expresar el enunciado del problema con
formato de una definición correcta y exacta, contextualizada en un dominio de
referencia que es un modelo del problema y basada en una estructura sintáctica
preestablecida. Esta fase produce una especificación formal del problema con
formato de una expresión lógica o matemática que refiere el problema a un
modelo y que denota, desde un enfoque externo al problema, los objetivos que
se persigue que la solución satisfaga. La fase del dominio de la solución obtiene
una especificación estructural de una solución al problema, que consiste en un
árbol descriptor de la jerarquía de los módulos que componen la estructura y un
grafo de las relaciones entre módulos, es decir, de la organización de los
módulos. El fundamento del proceso de tomar decisiones de arriba hacia abajo
consiste en clasificar las acciones que conforman el método de diseño y en
establecer una ordenación entre las clases de acciones encontradas. Se propone
un caso de estudio sencillo para poner de relieve el alcance de esta propuesta.
Palabras clave. Decisiones de diseño, Factores de diseño, Árbol estructural, Grafo de
organización, Factores esenciales de la solución, Factores circunstanciales de la
realización, Diseño orientado a modelo.
Página 2 de 32
CONTENIDO
1. Introducción ...................................................................................... 3
1.1. La actividad de diseñar 3
1.2. Conceptos sobre los problemas 7
2. Organización de los factores de diseño ........................................... 10
1.1. Evidencia empírica para clasificar los factores de diseño 10
1.2. La relación de alcance de las decisiones de diseño 12
1.3. Ordenación de las clases de factores de diseño 13
3. Plataforma para una especificación formal de problemas ............... 14
1.1. Decisiones de diseño sobre los modelos 15
1.2. Decisiones sobre los objetivos 16
4. Decisiones de diseño sobre los factores esenciales ......................... 17
1.1. Clasificación de los factores esenciales 17
1.2. Ordenación de las clases de factores esenciales 20
5. Especificación de problemas y de soluciones ................................. 21
1.1. Especificación formal de los problemas 21
1.2. Especificación estructural de las soluciones 23
1.3. Organización de una estructura 27
6. Decisiones de diseño sobre los factores circunstanciales ................ 28
7. Conclusiones ................................................................................... 29
Referencias .............................................................................................. 30
Página 3 de 32
1. Introducción
La motivación de este trabajo es proponer un marco conceptual para poder realizar
sistemáticamente las operaciones diseño y, en general, para ayudar en la toma de
decisiones relacionadas con las soluciones a los problemas. Este marco conceptual
puede proporcionar criterios para desarrollar procedimientos sistemáticos de decisión.
La consecuencia es que aumenta la parte de justificación objetiva de las soluciones a
los problemas a cambio de que disminuye la parte arbitraria que proviene de la
inspiración del ingeniero y, con ello, ganan terreno el rigor del procedimiento y la
fiabilidad del resultado.
Nótese que la aportación a la solución de un problema mediante la inspiración es la
que entronca con la experiencia, la preferencia, la casualidad, la moda, la costumbre,
la escuela o la corriente, la influencia externa, y otras causas de índole subjetiva o
fantástica. Esa inspiración podrá, a su vez, ser de naturaleza endógena, que es lo que
llamamos intuición, y producirá resultados artísticos (avalados por la convicción); e
incluso podrá ser de naturaleza exógena, que es lo que llamamos revelación
(resultados avalados por la creencia).
Debido a que los avales de la inspiración, la convicción y la confianza, son débiles, su
papel en el diseño de las cosas, los ingenios y los procesos se acepta como recurso
extremo, en ausencia de deducibilidad teórica y de empiria inductiva que garanticen
la objetividad. Por eso, la finalidad general de la metodología de diseño es maximizar
la base objetiva de las decisiones de diseño y, en consecuencia, disminuir la
subjetividad.
En un horizonte más lejano, la finalidad es desarrollar entornos computacionales que
proporcionen ayuda a los ingenieros en la actividad de tomar decisiones para crear los
objetos, los equipos, los sistemas o los métodos, es decir para proponer soluciones a
los problemas que acometen.
1.1. La actividad de diseñar
Estudios relativamente recientes tratan de proporcionar criterios para determinar,
entre el planteamiento top-down y el planteamiento bottom-up, cuál de ellos se
adecua mejor a la resolución de un determinado problema dentro del marco de los
sistemas multiagente [Crespi, 2008].
Unos años antes, en el ámbito del diseño de sistemas electrónicos con señales
mezcladas, Kundert desecha el planteamiento bottom-up debido a que carece de
potencia expresiva suficiente para producir las soluciones de diseño de circuitos con
la complejidad y el ritmo que demandan el mercado y la capacidad de fabricación.
Indica que es necesario un método formal de tipo top-down que pueda soportar un
proceso de diseño metódico y sistemático. Propone una secuencia de toma de
decisiones y verificación mediante simulación que, efectivamente, es sistemática,
pero totalmente empírica, sin fundamento formal alguno [Kundert, 2001], [Kundert,
2003].
Página 4 de 32
Hace ya 25 años, Mäntylä se mostraba partidario del diseño top-down de sistemas
mecánicos mediante entornos CAD [Mäntylä, 1990].
El modelado multi-granular resuelve aspectos de propagación de características entre
las diversas fases de modelado: el análisis de requerimientos, el diseño conceptual, el
diseño detallado y el prototipado [Huang, 2008], [Zhang, 2013].
Por su parte, el paradigma del diseño orientado a modelos resuelve aspectos de la
composición e integración a gran escala [Balasubramanian, 2006].
Automatizar la obtención de especificaciones formales partiendo de los requisitos de
un problema ha sido motivo de abundante esfuerzo investigador desde hace cincuenta
años [Wijngaarden, 1965], [Edunpuganty, 1989], [Bryant, 2000], [Bryant, 2002],
[Bjørner, 1978], [Dürr, 1995], [Bryant, 2003].
Brunetti y Golob proponen un enfoque de diseño basado en las características del
problema para capturar la semántica de las primeras fases de diseño con la finalidad
de utilizar dicha información en las fases finales de desarrollo del prototipo.
Encuentran empíricamente la doble estructura de árbol y grafo que más tarde propone
Qi, y con esta concepción desarrollan el entorno SINFONIA de ayuda al diseño
[Brunetti, 2000]. Qi propone una doble estructura basada en un árbol y un grafo para
modelar el ensamblaje y una notación para representar la estructura compuesta. El
nivel de relación del modelo de ensamblaje está representado mediante un árbol, y la
conexión entre los módulos del modelo de ensamblaje de árbol, está representado
mediante un grafo [Qi, 2009]. Otto muestra los principios y mecanismos subyacentes
de la arquitectura de los sistemas y de las estructuras de datos para obtener soluciones
mediante la transformación de los conceptos y de las características en
especificaciones formales consistentes pero encuentra que es necesario desarrollar
una base teórica que proporcione soporte al análisis conceptual de las características
de los problemas [Otto, 2001].
La literatura recoge también numerosas propuestas de análisis de requerimientos de
sistemas software en lenguaje natural. Así mismo, abundan los entornos de
transformación automática de cierto tipo de especificación formal a código fuente y
su validación a partir de dicha especificación [Spivey, 1992], [Duke, 1995], [Jackson,
2002].
Hay propuestas de análisis de requerimientos en lenguaje natural [Gomez,
1999],[Deeptimahanti, 2009], [Jlieva, 2005], [Meziane, 2008], [Brunel, 1998],
[Coleman, 1994].
La conclusión sobre el estado del conocimiento es que aumenta el interés por los
entornos de ayuda a la toma de decisiones de diseño para obtener una especificación
formal de un problema a partir de los objetivos que se plantea satisfacer dicho
problema. Ello se explica, entre otros motivos, por la también creciente envergadura
de los sistemas que dan solución a los problemas cada vez más complicados que se
abordan.
La mayor disponibilidad de entornos de ayuda computerizada al diseño se ha visto
favorecida por los avances en los enfoques metodológicos que han ido
incorporándose al diseño ingenieril en los cuales, cada vez son más relevantes las
variables arquitecturales de escalabilidad, sistematización y reutilizabilidad.
Página 5 de 32
Es deseable avanzar en los aspectos conceptuales de las relaciones entre los
problemas y los modelos con la finalidad de establecer un marco que sirva de soporte
al desarrollo de los entornos de ayuda a la especificación y resolución.
En la medida que la finalidad de este trabajo es sumamente abierta, el punto de
partida habrá de ser tan general como alcancemos a concebir, es decir, que no haya
restricciones o que si las hay, sean las indispensables. En ese sentido, conviene
observar que la actividad que realiza el maître para servir una ensalada, la que realiza
el estudiante para averiguar la superficie de un triángulo, o la que realiza el ingeniero
para diseñar un sistema, o para desarrollar un teclado, comparten la misma esencia:
contestar a la cuestión intuitiva “qué es lo que hay que hacer para hacer algo”.
Simplificadamente, contestar a la cuestión del “para hacer”.
Esa cuestión totalmente general puede descomponerse en un sinfín de cuestiones más
concretas, de manera que cualquier compendio de la respuesta a todas ellas constituirá
una respuesta al “para hacer”. Algunas de esas cuestiones son las siguientes: “qué (es
lo que hay que hacer)”, “quién (tiene que hacerlo)”, “con qué (hay que hacerlo)”,
“para quién (hacerlo)”, “cuánto (ha de costar)”, “cómo (hay que hacerlo)”, “cuándo
(se hace)”, “para qué (hay que hacerlo)”, “dónde (se hace), etc.
La tabla 1 muestra casos de preguntas que hay que contestar para tomar las decisiones
que proporcionan solución a algunos problemas.
Cada respuesta representa una acción, un evento o un valor de una variable. En lo
sucesivo, nos referiremos a estos factores de la creación de un ingenio o de la
resolución de un problema como a los “factores de diseño”. Las decisiones de diseño
consisten, precisamente, en establecer los factores de diseño.
El enunciado de un problema, es decir, la hipótesis, ha de ser del ámbito de los
enunciados a esclarecer, que es el ámbito de los problemas.
Tabla. 1. Cuestionarios para encontrar las actividades que hay que hacer para crear
los ingenios o resolver algunos de los problemas propuestos como ejemplos.
Qué es lo que hay que hacer para hacer algo
Ingenio Actividad
diseñar un sistema qué, cómo, cuándo, quién, dónde, con qué,…
servir ensalada a quién, cuándo, dónde, cómo, cuánto,…
calcular triángulo quién, cuál, con qué,…
producir un teclado con qué, cuánto,…
Sin perjuicio de otras posibilidades, la coherencia del procedimiento de diseño puede
garantizarse causalmente y, por lo tanto, su inicio ha de establecerse en la conjetura
inicial, esto es, la hipótesis de partida.
La figura 1 muestra el esquema general del proceso causal de diseño: el punto de
partida es una conjetura que pertenece al ámbito del problema, una secuencia de
acciones da lugar, sucesivamente, a una definición correcta y exacta del problema, a
Página 6 de 32
una instancia provisional de una solución, y a una instancia válida de esa solución,
también llamada prototipo.
Cada fase del método está fundamentada causalmente en la precedente. La hipótesis,
para no condicionar por adelantado podas en el árbol de posibles soluciones, debería
expresar el problema desde un punto de vista externo a la solución, sin hacer
consideraciones sobre la estructura y la composición de la solución. Es decir, la
hipótesis debe consistir en un enunciado del problema visto desde el universo, pero no
puede descartarse que también incluya condiciones sobre los ingredientes o sobre la
estructura de la solución.
Fig. 1. Esquema general del proceso causal de diseño: se inicia en una propuesta del
dominio del problema y culmina en una instancia válida del dominio de la solución.
El proceder que recoge la figura 1 está considerado por la comunidad internacional
como intuitivo, es decir, forma parte del sistema postular de la praxis ingenieril y, por
lo tanto, está asumido que no requiere mayor justificación. Tal estado de cosas
conlleva la aceptación del procedimiento de crear ingenios como una actividad cuya
esencia surge de la inspiración del ingeniero: sus conocimientos, experiencia,
habilidades, etc. Esto es, se asume, a la creación en ingeniería, una génesis inspirada
endógena y, por ende, basada en la intuición del ingeniero que proviene de sus
propias convicciones. El procedimiento está, pues, impregnado de arbitrariedad
subjetiva, luego es una expresión artística: el arte de diseñar. Por ello, resulta
francamente dificultoso encontrar trabajos en la literatura científica que avalen
formalmente su idoneidad salvo, quizás, contribuciones epistemológicas o
provenientes del ámbito de la historia y la filosofía de la ciencia [Hannay, 2007],
[Gregg, 2001], [Sjoberg, 2007] [Easterbrook, 2008], [Stol, 2013], [Wieringa, 2011].
En primera aproximación, la aceptación de la calidad de las soluciones que obtiene el
ingeniero depende en gran medida del arbitrio de cada persona.
La fórmula usual para investir de calidad objetiva a la creación subjetiva que realiza
el ingeniero la proporciona, en última instancia, un mecanismo de inducción parcial
que consiste en probar experimentalmente que la solución satisface los objetivos que
se propusieron a modo de condiciones para caracterizar el problema. La tabla 2
recoge un conocido refrán que proporciona la receta para aliñar una ensalada, cuyo
fundamento es la evidencia empírica de que esos ingredientes (con qué), en esas
proporciones (cuánto), y esa secuencia de elaboración (cómo) dan lugar a ensaladas
que se consideran buenas.
formular proponer verificar
DOMINIO DEL PROBLEMA DOMINIO DE LA SOLUCIÓN
Página 7 de 32
Tabla. 2. Elaboración tradicional de la ensalada mediante un criterio empírico basado
en la experiencia.
Procedimiento arbitrario para hacer una ensalada
“La ensalada, salada, poco vinagre, y bien aceitada”
con qué con sal, vinagre y aceite
cuánto mucha sal, poco vinagre y mucho aceite
cómo primero la sal, después el vinagre y, finalmente, el aceite
Lo que proponemos en el resto de este documento es un procedimiento para tomar las
decisiones que atañen a los factores de diseño. Este procedimiento está basado en las
relaciones binarias entre dichos factores de diseño. Resumidamente, de lo que se trata
es de caracterizar los factores de diseño que comparten determinadas propiedades,
asumiendo que todos los factores que sean de la misma clase serán susceptibles de
admitir un tratamiento análogo. Seguidamente, ordenar las clases de factores porque
ello proporcionará criterios sobre la secuencias de acciones a seguir para obtener
respuesta a la cuestión del “para hacer”.
1.2. Conceptos sobre los problemas
El concepto de problema ha recibido un trato extremadamente remiso en la literatura
científica. Los pocos autores que lo han abordado, lo hacen desde un enfoque
eminentemente epistemológico y filosófico, lo cual sirve para conocer a los
problemas pero aporta poco sobre cómo están constituidos y sobre cómo resolverlos
[Landry, 1995], [Agre, 1982]. Tanto Agre como Landry coinciden con todos los
autores en considerar a los problemas como el mecanismo de crear conocimiento, y
manejan el concepto de problema en sentido dinámico, relacionado con la actividad
de resolverlo en sí misma. Es lo que en este trabajo venimos llamando tomar
decisiones de diseño.
Agre propone una definición genérica del concepto de problema que está basada en
las nociones de conciencia, dificultad y convicción de poder ser resuelto. Finalmente,
señala la ausencia de trabajo científico sobre la relación que pueda existir entre la
resolución de problemas y el aprendizaje, y reconoce que parece existir una compleja
conexión conceptual entre aprendizaje, problema y solución.
Landry señala que han sido enunciadas numerosas definiciones de problema pero que
no han sido contrastadas empíricamente.
Preston, en relación con los sistemas de gestión de la información, apunta que los
problemas tienen una estructura inherente compuesta por variables finitas y reglas que
gobiernan las relaciones entre las variables. Así mismo, sugiere que el asunto clave es
identificar el conjunto de actividades ordenadas que componen el proceso de
resolución de problemas [Preston, 1991].
Como estamos interesados en una concepción procedural que pueda soportar las
transformaciones que requiere el proceso de resolución, proponemos que la creación
de conocimiento es el proceso de obtener la respuesta a partir de la pregunta o,
Página 8 de 32
equivalentemente, el de toma decisiones para obtener la solución partiendo del
problema.
En el ámbito estrictamente empírico, definimos la creación de conocimiento en los
términos que siguen. Un efecto observacional de una entidad, hecho o fenómeno del
universo depende de la naturaleza del propio fenómeno que se observa. La percepción
humana del efecto observacional ocurre mediante los órganos de los sentidos, y tal
vez de los instrumentos, y consiste en una transformación que filtra el efecto
observable. Finalmente, el conocimiento que se crea es la modulación que la mente
produce sobre la percepción, esto es, la interpretación de lo observado.
Es decir, el conocimiento que se crea al obtener la respuesta a un efecto observacional
consiste en el doble filtrado de percibir e interpretar. Los enfoques objetivista,
subjetivista y constructivista corresponderían a una clasificación de los problemas que
estuviera basada en las combinaciones posibles de las transformaciones de percepción
y de interpretación para producir conocimiento. Así, el objetivismo sería el caso en
que la interpretación fuera la identidad, en el subjetivismo sería la percepción la
identidad, y en el constructivismo, tanto la percepción como la interpretación serían
cualesquiera funciones. Más aún, si la percepción y la interpretación fueran la función
identidad, podríamos decir que la respuesta alcanzada es la verdad, lo cual significa
que la interpretación coincide con el efecto observacional. Por otro lado, la
percepción nula daría lugar a conocimiento inspirado, artístico o revelado,
dependiendo de que la fuente de inspiración fuera intuitiva o exógena.
En línea con la propuesta de Preston, con carácter general, consideramos que el
término problema tiene el significado estático de declaración que ha de ser
esclarecida. Para que el alcance sea lo más general posible, proponemos las siguientes
definiciones:
Problema. Un problema es un enunciado a esclarecer. Los componentes de la senten-
cia son términos que se refieren a los elementos involucrados en el problema, y los
llamamos variables del problema. El significado de la sentencia es una condición
entre las variables. Las variables no tienen por qué ser cuantificables y las condicio-
nes sobre ellas no tienen por qué ser funcionales.
El ámbito del enunciado del problema es, por lo tanto, el dominio de los efectos
observables, exento de la subjetividad que puedan incorporar la percepción y la
interpretación. Instrumentalmente, los problemas son efectos observables. Que la
sentencia haya de ser esclarecida, incorpora inevitablemente subjetivismo pero lo deja
inscrito en el ámbito del proceso de esclarecimiento, esto es, de resolución del
problema.
Decisión de diseño. Es la acción que deriva un enunciado a partir de otro. La deriva-
ción de enunciados establece coherencia causal entre un problema y una solución del
mismo. Las decisiones de diseño operan tanto sobre las variables como sobre la con-
dición del problema, y están relacionadas con los filtros de observación e interpreta-
ción. Una secuencia de acciones de diseño transforma el problema en un enunciado
solución.
Página 9 de 32
Las decisiones de diseño consisten, precisamente, en establecer los factores de diseño.
Las respuestas al “para hacer”, esto es, los factores de diseño han de ser derivables
con la condición del problema que resuelven.
Solución. Una solución a un problema es un enunciado derivado del problema, que lo
esclarece. Es decir una solución a un problema es conocimiento que se crea a partir de
un efecto observable, mediante la percepción y la interpretación. La naturaleza de una
solución es la misma que la de un problema, ya que la condición de ser solución radi-
ca en el valor semántico que se le asigna externamente.
Modelo de un conjunto de problemas. Es un problema cuyo enunciado forma parte
del enunciado de cada problema del conjunto. Sus variables son las variables comu-
nes a todos los problemas y su condición incluye a la unión de las condiciones. Por lo
tanto, un modelo es una abstracción de cada problema del conjunto, y, en consecuen-
cia un subproblema común a todos los problemas de dicho conjunto.
Bajo ese enfoque, la primera etapa de diseño que proponemos es descomponer el
problema en los dos subproblemas siguientes: - Subproblema modelo. Es la parte del problema relativa a las variables y las
condiciones sobre las mismas que este problema comparte con otros de una
familia. La resolución del subproblema modelo se refiere a tomar las decisiones de
diseño correspondientes al nivel de los modelos. Por ejemplo, plato (alimento,
comida) es un modelo del ingenio ensalada. Decidido un modelo, es posible definir
un problema en términos del mismo: una ensalada es un plato saludable. - Subproblema específico. Es la parte del problema relativa a las variables y las
condiciones sobre las mismas que distinguen a este problema del modelo. La
resolución del subproblema específico es el compendio de las decisiones de diseño
que corresponden a los aspectos del problema que no resuelve el modelo, es decir,
resolver el subproblema específico consiste en actividades de concreción sobre el
modelo. Por ejemplo: una ensalada es un plato a base de verduras frescas, crudas, y
baratas. La concreción de ser saludable la ensalada consiste en este caso en que las
verduras sean frescas, crudas y baratas.
La definición del modelo del problema restringe la solución al ámbito del propio
modelo y, por ello, provoca una poda en el árbol de las soluciones que admite el
problema. Expresar el problema en referencia a uno de sus modelos proporciona una
definición incompleta del problema y, como tal, su valor es declarativo para el
problema.
La caracterización del problema específico, por su parte, ha de expresar la condición
que complementa al modelo frente al problema y, por lo tanto, en el caso general,
involucra a los elementos de todo el problema. En el caso más general, podremos
extraer la condición del subproblema específico mediante transformaciones de la
hipótesis que aseguren su corrección y exactitud.
Página 10 de 32
2. Organización de los factores de diseño
Partiendo de la consideración de que un problema es un enunciado que establece una
condición entre las variables, que ha de ser esclarecido, han sido propuestas sendas
definiciones para los conceptos de “solución”, “decisión de diseño”, y “modelo”.
Dichas definiciones proporcionan una base para clasificar los factores de diseño y
para ordenar las clases de factores que intervienen en el diseño de soluciones
1.1. Evidencia empírica para clasificar los factores de diseño
Los factores de diseño están contenidos en las respuestas a las preguntas subyacentes
a la cuestión genérica del “para hacer”: los ingredientes del aliño, sus cantidades y el
orden de operación. Un análisis fenomenológico de los factores de diseño proporciona
evidencia empírica de que pueden ser clasificados.
Tomando como ejemplos los problemas “cómo hacer un teclado” y “cómo hacer una
ensalada”, las respuestas a las preguntas del “para hacer” se muestran en las tablas 3 y
4, respectivamente. La columna “Alcance de la respuesta” de dichas tablas denota la
identidad de la respuesta correspondiente. Los símbolos de la columna “Clase”
identifican las categorías de respuestas.
En el ejemplo de diseñar un teclado, las respuestas pueden ser las siguientes: referirse
a un superconjunto del ingenio teclado visto como problema (dispositivo), en cuyo
caso será una respuesta referente a un modelo del teclado (M); referirse a aspectos o
partes del ingenio teclado visto como solución (entrada, tecla, pulsación), que es lo
que denominaremos factores esenciales del ingenio que se diseña visto como solución
(E); o referirse a asuntos que no forman parte del ingenio teclado diseñado sino que
conforman el contexto de la actividad de diseñar (planificación, facultativo, precio,
etc.), a los cuales les llamamos factores circunstanciales de la actividad de realizar el
teclado (C).
Tabla. 3. Las respuestas que se obtienen al cuestionario para hacer un teclado pueden
referirse a un modelo del ingenio teclado (M), a factores esenciales del teclado (E), o
a factores circunstanciales de la actividad de diseñar el teclado (C).
Clases de respuestas para hacer un teclado
Cuestión Respuesta Alcance de la respuesta Clase
Qué es Un dispositivo Abstrae al problema M
Para qué es Para entrada de caracte-
res y órdenes La solución incluye a la
respuesta E
Con qué se hace Con teclas, circuitos,
chasis, etc. La solución incluye a la
respuesta
Cómo Convirtiendo pulsación
en señal eléctrica La solución incluye a la
respuesta
Cuándo La semana que viene La respuesta es externa a
la solución C
Página 11 de 32
Quién Un ingeniero electrónico La respuesta es externa a
la solución
Cuánto Menos de 50 € La respuesta es externa a
la solución
Dónde, de
quién, para
quién, etc.
… La respuesta es externa a
la solución
En el ejemplo de diseñar una ensalada, análogamente, las respuestas pueden referirse
al superconjunto comida, modelo de la instancia ensalada (M); referirse a
propiedades, partes o ingredientes, esto es, factores esenciales (E); o referirse al
contexto de elaboración de la ensalada (C).
Tabla. 4. Clases de respuestas al cuestionario para hacer una ensalada. Modelo (M:
comida), factores esenciales (E: sabrosa, nutritiva, lechuga, pepino, aceite, lecho de
verduras, aliño, etc.), y factores circunstanciales (C: planificación, facultativo, precio,
etc.).
Clases de respuestas para hacer una ensalada
Cuestión Respuesta Alcance de la respuesta Clase
Qué es Una comida Abstrae al problema M
Para qué es Sabrosa, nutritiva,
saludable y agrada-
ble
La solución incluye a la res-
puesta E
Con qué se hace Lechuga, pepino,
rúcula, aceite,… La solución incluye a la res-
puesta
Cómo Un lecho de verdu-
ras aliñadas La solución incluye a la res-
puesta
Cuándo En el momento de
servirla La respuesta es externa a la
solución C
Quién Un cocinero La respuesta es externa a la
solución
Cuánto Menos de 10 € La respuesta es externa a la
solución
Dónde, de
quién, para
quién, etc.
… La respuesta es externa a la
solución
Página 12 de 32
1.2. La relación de alcance de las decisiones de diseño
La existencia de la partición que aparece en las dos tablas {M, E, C}, teniendo en
cuenta el teorema fundamental de las relaciones de equivalencia, permite afirmar que
existe una relación de equivalencia en el conjunto de los factores de diseño.
Definimos el alcance de un factor de diseño sobre un problema en el ámbito de un
modelo como el conjunto de los problemas en los que la decisión de diseño produce
deriva. El alcance puede ser: el modelo y el problema, solamente el problema, o
ninguno de ellos.
Definición. La sentencia “alcance de la respuesta” establece una relación de equiva-
lencia en el conjunto de los factores de diseño (F,∼).
El alcance de la respuesta a una cuestión del “para hacer” determina si esa respuesta
es una condición del modelo y el problema (M), solamente del problema (E), o no
afecta al problema sino al proceso de obtención de la solución (C), significando esto
último la fabricación del ingenio o la realización de un prototipo. Luego, el alcance de
la respuesta viene a indicar el ámbito de la decisión de diseño que lleva aparejada la
respuesta a cada cuestión del “para hacer”: el modelo, las peculiaridades de problema,
o circunstancias de la resolución (contexto de la realización).
Hay tres clases de factores (F):
F = {M,E,C} - Los factores de diseño que se obtienen respondiendo a la cuestión “qué es el
problema” tienen alcance en el problema y en el modelo y, por lo tanto, recogen lo
abstracto del problema y dan lugar a las generalizaciones del mismo. - Los factores de diseño que se obtienen respondiendo a las cuestiones {para qué,
con qué, cómo} derivan de lo específico del problema. Las decisiones de diseño
sobre estas cuestiones esclarecen aspectos locales. Esta clase de los factores
comprende el subconjunto de los factores de diseño que son parte constituyente de
la solución y por ese motivo los denominamos factores esenciales: ingredientes,
propiedades, estructura o módulos. - Los factores circunstanciales se obtienen respondiendo a las restantes cuestiones
del “para hacer”{cuándo, quién, cuánto, dónde, a quién, de quién,…}. El contexto
resuelve aspectos que intervienen en el proceso de obtención del resultado: coste,
equipo de diseño, planificación, lugar, etc.
La figura 2 consiste en una representación del alcance que tienen las decisiones de
diseño en relación con la intensidad que esclarecen del problema o la cantidad del
ingenio que contribuyen a crear. El significado de cada una de las cuestiones del
“para hacer” contribuye a hacer intuitiva la correspondencia de los factores de diseño
y de las decisiones a que dan lugar. La interpretación del significado de las tres clases
de factores de diseño respecto del ingenio que se crea también se hace evidente.
Página 13 de 32
Fig. 2. Clases de factores de diseño e interpretación de su relación el ingenio.
Puede darse el caso de que factores que son genuinamente ajenos al modelo interese
considerarlos como propios del modelo. Por ejemplo, el factor “que tenga máxima
frescura” la ensalada es una respuesta genuina a la cuestión “cuándo” pero también
puede obtenerse como respuesta a la cuestión “qué es” si se da el caso de que el
restaurante considera que la frescura de la ensalada es un aspecto primordial. Desde el
punto de vista del formalismo, ese mismo factor de diseño puede obtenerse como
respuesta a la cuestión “qué es” y a la cuestión “cuándo”, lo cual descompondría el
rigor de la clasificación.
Por convenio, para mantener el rigor de la clasificación, imponemos la condición de
prevalencia de lo establecido en la hipótesis sobre la naturaleza genuina o habitual de
los factores de diseño.
Esto es una forma de imposición de causalidad dentro del método de diseño que
estamos justificando: si forma parte de la hipótesis, corresponde que genere
consecuencias y carece de sentido que constituya un hallazgo.
1.3. Ordenación de las clases de factores de diseño
Nos proponemos ordenar las tres clases de factores de diseño para obtener un criterio
sobre cuáles son las decisiones de diseño que hay que tomar en primer lugar y cuáles
las que corresponde tomar seguidamente.
Definimos la potencia de un factor de diseño sobre un problema en el ámbito de un
modelo como el cardinal de su alcance.
El dominio de la potencia es, por lo tanto, los valores {0,1,2}.
CUÁNTO
QUIÉN
otras
CUÁNDO
DÓNDE
ingenio
QUÉ
universo
PARA QUÉ
CÓMO
CON QUÉ
Página 14 de 32
Como dicho conjunto está ordenado, podemos establecer la siguiente:
Definición. La sentencia “potencia de un factor de diseño” ordena las clases de facto-
res de diseño: (F,>).
C < E < M
La conclusión es que existe una precedencia que establece cuál es la secuencia
correcta de niveles para tomar las decisiones que atañen a los factores de diseño.
factores circunstanciales < factores esenciales < modelo
La hipótesis constituye el hito de inicio de la actividad de diseñar y, en su esencia,
expresa abstractamente a la solución, corresponde al ámbito del modelo. Luego, la
secuencia formalmente correcta que hay que seguir en la toma de decisiones de
diseño para mantener la coherencia respecto de la potencia de los factores sobre los
que se toman las decisiones es la siguiente: decidir en primer lugar el modelo que va a
caracterizar a la solución, tomar seguidamente las decisiones sobre los factores
esenciales de la solución y, finalmente, las decisiones sobre el contexto en que tiene
lugar la creación de dicha solución.
La derivación de las decisiones de diseño da lugar a clases que admiten ser ordenadas
por su potencia, lo cual constituye un marco del diseño orientado a modelo.
El procedimiento causal para tomar las decisiones de diseño que hemos desarrollado
hasta este punto afecta a los aspectos globales de la resolución de problemas:
modelos, constituyentes y entorno. La casuística a que nos enfrentamos tiene los
siguientes rasgos definitorios: - Las decisiones de diseño relacionadas con los modelos corresponden esencialmente
al ámbito del problema pero están encaminadas a delimitar el marco general dentro
del cual habrá de obtenerse la solución. Su finalidad instrumental es hacer una
selección. Por lo tanto, aunque los elementos para el razonamiento sean del ámbito
del problema, los resultados son del ámbito de la solución. - Las decisiones de diseño relacionadas con los factores esenciales son las que tienen
que dilucidar sobre los ingredientes tecnológicos constituyentes de la solución,
sobre la interfaz de utilización de la misma, y los demás aspectos constitutivos de
la propia solución, esto es estructurales y organizacionales. La finalidad
instrumental de las decisiones de este nivel del diseño es sustancial, de
composición y constitución de la solución. - Las decisiones de diseño relacionadas con el contexto son procedimentales, de
ambientación del escenario, inmersa en el cual ocurre la solución.
3. Plataforma para una especificación formal de problemas
Como forma sistemática para resolver cualquier problema, esta propuesta tiene la
esencia de descomponer el problema de partida en otros que sean más sencillos y
proceder iterativamente hasta instancias de problemas que interese resolver mediante
técnicas específicas o cuya solución sea conocida.
El diseño orientado a modelo que hemos justificado para obtener una solución a un
problema trata de obtener esa solución mediante una estrategia “divide et vinces” que
Página 15 de 32
descompone canónicamente al problema inicial en dos subproblemas: un modelo del
problema, y otro subproblema que comprende la concreción que media entre el
modelo y el problema inicial. Luego, la selección del modelo es una decisión de
diseño dado que condiciona la solución que finalmente obtengamos para el problema.
Como estamos tratando de operar los problemas para obtener otros problemas o partes
de ellos, además de las concepciones postulares al uso, es necesario establecer
concepciones operacionales de las entidades que intervienen.
1.1. Decisiones de diseño sobre los modelos
Puede haber muchos modelos de un problema dado, tantos como resultan de
combinar los factores de diseño de este último y de proponer condiciones que
contengan a la del problema.
En términos topológicos, podemos referirnos al espacio de representación de todos los
factores de diseño y concebir cada problema como la región de ese espacio que
satisface la condición del problema.
La pretensión de resolver con estrategia orientada a modelo, con la finalidad de que la
solución obtenida para el modelo pueda ser utilizada para resolver otros problemas
que tengan ese mismo modelo, proporciona criterio para proponer una técnica de
selección del modelo que va a servir de marco a la solución de un problema dado.
En el caso general, la hipótesis de partida representa al problema que nos planteamos
resolver en términos, quizás, de un modelo y de un compendio de objetivos que ha de
alcanzar el problema, e incluso de requerimientos que debe satisfacer la solución.
Todo ello, mediante una expresión del lenguaje de la disciplina del problema,
pudiendo la tal expresión ser inexacta, imprecisa, ambigua, e incluso errónea.
Debido a esa posibilidad de incorrección, evitamos llamar enunciado del problema a
la hipótesis o conjetura inicial y reservamos el término problema para el enunciado
formalmente correcto y exacto que resulta de la transformación (léxica, sintáctica e
incluso semántica) de la hipótesis para obtener una definición que consiste en: - Una sentencia generalizadora que expresa el modelo; p.e.: “una ensalada es una
mezcla de verduras”. - Una sentencia de concreción, que expresa la condición como una conjunción de
otras condiciones más ligeras, extraídas de la hipótesis, en coherencia con el
modelo; p.e.:, “una ensalada es fresca, sabrosa, nutritiva y barata”.
Llamaremos “objetivos del problema” a las condiciones parciales correctas y exactas
extraídas de la hipótesis, expresadas en coherencia con el modelo.
El cometido de decidir el modelo del problema es, pues, doble: por un lado, establecer
la parte correspondiente de la solución, y por el otro, precisar el marco de la hipótesis.
La técnica que proponemos consiste en contestar a la cuestión “qué” es el problema,
para decidir cuál es el modelo de problema a proponer. Ej.: la pregunta “qué es la
ensalada”, obtendrá como respuesta modelos de ensalada: “entrante frío”, “alimento
saludable”, “mezcla de verduras”, etc.
Consta de los siguientes pasos: - Enunciar una colección de otros problemas tipo para los cuales, el modelo, lo sea.
Serán considerados casos favorables o ejemplos positivos.
Página 16 de 32
- Enunciar, tal vez, una colección de otros problemas tipo para los cuales, el modelo,
no lo sea. Serán considerados ejemplos negativos o contraejemplos. - Enunciar una condición derivada de la unión de las condiciones de los ejemplos, de
tal manera que no contenga las condiciones de los contraejemplos.
Siguiendo con el ejemplo de la ensalada, para proponer un modelo para la misma,
pueden servir como casos favorables los siguientes: ensalada murciana, pipirrana,
ensalada césar, ensalada waldorf, tabulé, ensalada rusa y escalivada. Como
contraejemplos, los siguientes: gazpacho, vichyssoise, cocido, paella, hervido y
verduras a la plancha.
Un modelo de ensalada es el de la siguiente definición:
“Ensalada es una mezcla diferenciada a base de verduras y tal vez otros ingredientes,
predominantemente fría”.
Cuando de lo que se trata es de resolver reutilizando modelos ya conocidos, lo
pertinente es considerar dichos modelos directamente. Así, en el caso de querer crear
una ensalada científicamente, podemos proponer: - Mezcla de verduras. Es una concepción de la ensalada bajo del enfoque del chef. - Alimento ligero. Este enfoque de la ensalada corresponde al punto de vista del
experto en dietética. - Entrante frío. Se trata del planteamiento que tiene el maître de lo que es una
ensalada.
En caso de estar interesados más en hacer la ensalada que en servirla o en su valor
nutritivo, una primera definición de ensalada sería la siguiente:
“Ensalada es una mezcla diferenciada a base de verduras y tal vez otros ingredientes,
predominantemente fría”.
En cambio, el experto en dietética podría proponer el siguiente modelo:
“Ensalada es una mezcla hipocalórica y facilitadora del tránsito intestinal a base de
verduras y tal vez otros ingredientes”.
Nótese que estas definiciones proporcionan solamente la información del problema
respecto del modelo que hemos decidido para el mismo. Su valor se limita al ámbito
de lo declarativo pero carece de utilidad operacional para transformarla en otra
expresión que contenga la información para producir la ensalada.
1.2. Decisiones sobre los objetivos
Establecido precisamente el marco de la hipótesis mediante un modelo del problema,
para completar la transformación de la misma en una expresión correcta, exacta y
precisa, bajo el planteamiento de que la propia hipótesis evite las preconcepciones
sobre la solución, corresponde que esa nueva expresión de la hipótesis esté enmarcada
en el ámbito del problema. Luego la transformación de la hipótesis ha de consistir en: - Corregir y refinar las expresiones, objetivos o requerimientos, contenidos en la
conjetura inicial. - Transformar los requerimientos sobre la solución que puedan estar contenidos en la
conjetura inicial en objetivos del ámbito del problema, esto es, expresiones
construidas con términos procedentes de un punto de vista externo a la interfaz que
Página 17 de 32
media entre el ingenio solución y el resto del universo. Esta transformación desliga
al enunciado del problema de potenciales restricciones del árbol de soluciones que
hubieran sido incorporadas arbitrariamente e incluso sin intención. Contrariamente,
como puede ocurrir que exista decisión de que determinado requerimiento sobre la
solución constituya un objetivo del problema (p.e., que un circuito sea CMOS),
todo lo que corresponde hacer es conservar tal consideración en su versión como
objetivo del problema. De esta forma, la nueva expresión de la hipótesis adquiere
la consistencia formal de ser un enunciado del problema desde el enfoque externo
al mismo problema y, por lo tanto, libre de precondiciones. - Proponer objetivos adicionales. Dado que el modelo del problema recoge los
objetivos establecidos en la conjetura inicial, la obtención del conjunto de todos los
objetivos del problema lleva consigo decidir sobre la incorporación de otros
objetivos adicionales que sean consistentes con los iniciales. Aquí es donde se
incorporan las conclusiones del estudio del estado del conocimiento sobre el
problema. El análisis del conocimiento que existe sobre el problema permite
determinar los avances que corresponde que satisfaga la solución, adicionalmente a
los contenidos en la hipótesis. La especificación formal, finalmente, contendrá el
compendio de los objetivos extraídos de la hipótesis y de los extraídos del análisis
del estado del conocimiento. Realizar el análisis del estado del conocimiento
después de definir el modelo justifica que el ámbito del análisis quede acotado por
el modelo. A su vez, los objetivos que se obtienen del análisis del conocimiento
pueden corresponder al propio modelo o a la parte específica del problema, lo cual
produce un refinamiento del modelo. Bajo ese punto de vista, en la práctica, ambas
actividades, definición del modelo y análisis del estado del conocimiento, se
realizan concurrentemente como un bucle formado por la secuencia: definición de
modelo seguida de análisis del estado del conocimiento.
4. Decisiones de diseño sobre los factores esenciales
1.1. Clasificación de los factores esenciales
Los factores esenciales E son las respuestas a las preguntas {para qué, con qué,
cómo}. Análogamente a como hemos procedido para la clasificación de los factores
de diseño en general, un análisis fenomenológico de los factores esenciales sugiere la
posibilidad de clasificarlos. Tomando como ejemplos los problemas de hacer un
teclado y de hacer una ensalada, las respuestas a las preguntas para encontrar
soluciones se muestran en las tablas 5 y 6, respectivamente.
Las anotaciones del campo “Rol” se refieren ahora al papel que desempeñan los
factores que dan respuesta a las cuestiones. En ambos casos surge una partición que,
teniendo en cuenta el teorema fundamental de las relaciones de equivalencia, permite
afirmar que existe una relación de equivalencia en el conjunto de los factores
esenciales de diseño tanto del teclado como de la ensalada. Más aún, la partición
consiste en las siguientes tres clases:
Página 18 de 32
- Los factores de la clase A, que representan la utilidad, son los factores esenciales
que la solución manifiesta explícitamente al universo, los que se perciben desde un
punto de vista externo a la solución. Son los factores de la arquitectura
(prestaciones) de la solución, podemos denominarlos factores explícitos. Su
característica operacional es que pueden deducirse de la hipótesis, y se obtienen
respondiendo a la cuestión “para qué”. Un ejemplo de factores explícitos para el
caso de la ensalada es “plato saludable de sabor intenso y fuerte contraste”. - Los factores de la clase T, son los ingredientes tecnológicos, es decir, que
representan a la constitución de la solución. Podemos denominarlos factores
intrínsecos. Su característica operacional es que son elementales por definición, y
se obtienen respondiendo a la cuestión “con qué”. Ejemplos de factores intrínsecos
para el caso de la ensalada son: lechuga, tomate, cebolla y aceite de oliva. - Los factores de la clase S son los constructivos de la solución, es decir, los factores
estructurales y de la organización de la solución. Podemos denominarlos factores
implícitos, y se obtienen respondiendo a la cuestión “cómo”. Representan la visión
interna de la solución. Un ejemplo de factores implícitos para el caso de la ensalada
es “mezcla aliñada de tomate y cebolla sobre lecho de espinacas”.
Tabla. 5. Clasificación empírica de las respuestas a las cuestiones sobre los factores
esenciales para hacer un teclado.
Cuestiones esenciales para hacer un teclado
Cuestión Respuestas Rol Clase
Para qué es Para entrada de caracteres y
órdenes La utilidad del
teclado A
Con qué se hace Con teclas, circuitos, chasis,
etc. Los constituyentes T
Cómo Convirtiendo presión en seña-
les eléctricas Su funcionamiento S
Tabla. 6. Clasificación empírica de las respuestas a las cuestiones sobre los factores
esenciales para hacer una ensalada.
Cuestiones esenciales para hacer una ensalada
Cuestión Respuestas Rol Clase
Para qué es Sabor, textura, salubridad,
nutrición,… La utilidad de la
ensalada A
Con qué se hace lechuga, pepino, aceite de
oliva,… Los ingredientes T
Cómo Un lecho de verduras y aceite
pulverizado Su construcción S
Página 19 de 32
Por lo tanto, el rol de un factor esencial consiste en la repercusión que tienen las
decisiones de diseño que lo incorporan a la solución, en la propia actividad de obtener
la solución: la deriva de los factores explícitos (arquitectura) a partir de la hipótesis es
deductiva, la de los factores implícitos (estructura) es inductiva, y la de los factores
intrínsecos (tecnología) es indirecta, a través de la estructura.
Definimos el rol de un factor de diseño en un problema como la naturaleza de la
deriva que lo produce. El rol puede ser: deducción, inducción o indirección.
Definición. La sentencia “rol de un factor esencial” establece una relación de equiva-
lencia en el conjunto de los factores esenciales (E,∼).
El conjunto de clases de equivalencia tiene tres elementos:
E = {A,T,S}
La figura 3 muestra la clasificación de los factores esenciales mediante las cuestiones
del “para hacer”.
Fig. 3. Clases de factores esenciales y su significado en las fases de toma de
decisiones de diseño.
Análogamente a lo que ocurre con los factores de diseño en general, para los factores
esenciales puede darse el caso de que factores genuinamente tecnológicos o
estructurales (ej.: tecnología CMOS) vengan impuestos en la hipótesis. Es decir, la
imposición de causalidad al método de diseño que estamos formalizando puede dar
lugar a que factores intrínsecos o implícitos formen parte de los objetivos que debe
satisfacer el problema. En tal caso, ese mismo factor (tecnología CMOS) puede
CUÁNTO
QUIÉN
otras
CUÁNDO
DÓNDE
ingenio
QUÉ
universo
PARA QUÉ
utilidad
ARQUITECTURA
factores explícitosCÓMO
constitución
ESTRUCTURA
factores implícitos
CON QUÉ
composición
TECNOLOGÍA
factores intrínsecos
Página 20 de 32
obtenerse como respuesta a la cuestión “para qué”, lo cual descompondría la
clasificación. Para que tal inconveniente no surja, imponemos la condición de
prevalencia de lo específico de un problema (establecido en la hipótesis) sobre lo
genuino para que un factor esencial sea explícito, implícito o intrínseco pero tenga
solamente un rol.
1.2. Ordenación de las clases de factores esenciales
Nos proponemos ordenar las tres clases de factores esenciales con la finalidad de
utilizar dicha ordenación como criterio para determinar cuáles son las decisiones de
diseño sobre los factores esenciales que hay que tomar antes y cuáles son las que
corresponde tomar después.
Un factor esencial dado “es parte de” otro factor esencial, si el primero es un factor
esencial del segundo (vistos como cosas, sistemas o hechos). Cada factor esencial es
factor esencial de sí mismo. Los factores intrínsecos son parte de los factores
implícitos, y éstos lo son de los explícitos.
La sentencia “ser un factor de diseño parte de otro” ordena los factores esenciales:
(E,>)
T < S < A
Los factores de diseño y, por lo tanto el método de diseño está ordenado:
factores circunstanciales < tecnología < estructura < arquitectura < modelo
Como, por otro lado, la hipótesis expresa al problema con enfoque desde el exterior,
corresponde al ámbito del modelo y a la arquitectura, y es la que constituye el hito de
inicio de la actividad de diseñar, la secuencia correcta que hay que seguir para tomar
decisiones de diseño es la que establece en primer lugar el modelo de problema que
va a caracterizar a la solución, seguidamente, tomar las decisiones sobre la
arquitectura del problema, después sobre la estructura y organización de la solución,
seguidamente sobre la tecnología y, finalmente, las decisiones sobre el contexto en
que tiene lugar la creación de dicha solución.
Luego, la secuencia coherente de diseño es:
modelo → arquitectura → estructura → tecnología → factores circunstanciales
En términos de las cuestiones del “para hacer”, la secuencia coherente de preguntas
es:
qué → para qué → cómo → con qué → las demás
La figura 4 muestra la secuencia causalmente coherente del método de diseño de
arriba hacia abajo.
Página 21 de 32
Fig. 4. Secuencia de diseño de arriba hacia abajo.
5. Especificación de problemas y de soluciones
1.1. Especificación formal de los problemas
La segunda etapa de la fase de especificación formal es la de la arquitectura, es decir,
la funcionalidad o las prestaciones que debe satisfacer una solución. Se obtiene
contestando a la cuestión “para qué”, lo cual proporciona los objetivos del problema
desde un punto de vista externo, además de potenciales desafíos que el entorno
plantea a la solución y los inconvenientes que puede tener la solución al problema,
que puedan derivarse de lo enunciado en la hipótesis. La tabla 7 contiene los objetivos
para el ejemplo de la ensalada.
Tabla. 7. Objetivos que debe satisfacer el problema de la ensalada.
Objetivos de la ensalada (incluyendo desafíos e inconvenientes)
núm Objetivo
o1 Valor nutritivo
o2 Aroma agradable
o3 Sabores diversos
o4 Apariencia atractiva
o5 Precio bajo
o6 Frescura
CUÁNTO
QUIÉN
otras
CUÁNDO
DÓNDE
ingenio
QUÉ
universo
contexto < tecnología < estructura < arquitectura < modelo
PARA QUÉ
CÓMO
CON QUÉ
Página 22 de 32
Nótese que los dos últimos objetivos son genuinamente factores circunstanciales pero
el hecho de ser objetivos los convierte en factores esenciales explícitos. La definición
ahora es la siguiente: “Ensalada es una mezcla fresca de verduras con valor nutritivo,
con aroma agradable, sabores diversos, apariencia atractiva y precio bajo.”
El modelo del problema junto con los objetivos, extraídos de la hipótesis y del estado
del arte, que el problema debe satisfacer responden, respectivamente, a las cuestiones
“qué es el problema” y “para qué sirve su solución”, esto es, la caracterización del
problema visto desde el punto de vista de su universo y, por lo tanto, bajo un enfoque
externo. La relevancia de este aspecto radica en que la aproximación externa,
objetivista, independiza de potenciales condicionantes que podrían provenir de
preconcepciones sobre la solución. La definición del problema es claramente formal
ya que denota exclusivamente la naturaleza del problema y su utilidad, con
independencia de la naturaleza y las características de la solución que finalmente se
provea.
La especificación formal admite una estructura sintáctica sencilla que consiste en un
predicado transitivo para asignar la identidad del modelo y otro predicado formal para
asignar los objetivos como una conjunción.
<problema> <verbo ser> <artículo> <modelo> <preposición> <objetivo>
(<conjunción> <objetivo>)* “.”
Algunos ejemplos de especificación formal se muestran en la tabla 8:
Tabla. 8. Ejemplos de especificación formal.
Especificación formal de problemas
problema especificación formal
tomate es una fruta con tegumento delgado y endotelio carnoso y
ácido y con semillas planas
marchar es desplazarse linealmente sobre una superficie desde una
posición inicial hasta otra posición final
ensalada es una mezcla fresca de verduras con valor nutritivo y con
aroma agradable y con sabores diversos y con apariencia
atractiva y con precio bajo
A modo de resumen, el proceso para obtener una expresión formal del problema parte
de la hipótesis y consiste en los siguientes pasos: - Corregir los errores e inconsistencias de la conjetura inicial. - Expresar los requerimientos (enfoque interno) que la hipótesis contiene como
objetivos (enfoque externo). - Decidir un modelo de referencia para el problema. - Completar los objetivos mediante el estudio del estado del conocimiento.
Página 23 de 32
- Expresar formalmente el problema como la composición de un predicado sobre el
modelo y otro sobre los objetivos.
La especificación formal del problema proporciona información declarativa y
utilitaria sobre el mismo, es decir, da a “conocer” el problema.
Para proporcionar una solución, se requiere que la información sobre el problema sea
constitutiva y operacional, es decir, “conocer cómo”, para poder identificar los
elementos de que consta, y “conocer cómo hacer”, para poder operar
transformaciones sobre los elementos.
1.2. Especificación estructural de las soluciones
Para obtener una solución, se requiere hacer una interpretación del problema desde el
punto de vista interno ya que hay que entender de la naturaleza de sus elementos y de
las relaciones entre ellos. Esos elementos, y esas relaciones constituyen la estructura,
la organización y los ingredientes de las soluciones, y cada enfoque del problema
desde el punto de vista interno puede producir distintas soluciones del problema.
En este apartado indicamos un método para obtener la especificación estructural y la
organización de una solución dentro del marco de la teoría de grafos, como un par que
consiste en un árbol que define una estructura jerarquizada de los módulos de la
solución, y en un grafo dirigido que organiza las relaciones entre los módulos.
El recorrido partiendo de la hipótesis que puede contener requerimientos (visión
interna informal), para obtener una especificación formal de objetivos (visión externa
formal), y nuevamente una especificación estructural y organizacional que consiste en
requerimientos (visión interna formal), constituye un proceso de ida y vuelta para
obtener lo que teníamos al principio pero objetivado, completado, expresado con
exactitud y corrección, y dentro del marco formal de la teoría de grafos.
Sean los objetivos las condiciones que se imponen al problema (enfoque externo),
sean los requerimientos las prestaciones que ha de tener una solución (enfoque
interno), sean los desafíos las condiciones que el contexto puede imponer al problema
(enfoque externo), y sean los inconvenientes las limitaciones que puede tener una
solución (enfoque interno).
El punto de partida para obtener la especificación estructural es la especificación
formal y, por lo tanto, de lo que se trata es de proponer un conjunto de requerimientos
de una solución, con la condición de que los requerimientos proporcionen una
cobertura que satisfaga el conjunto de los objetivos. Como al proponer requerimientos
pueden surgir desafíos o inconvenientes, la obtención de la cobertura final debe
también superar los desafíos, y contrarrestar los inconvenientes. Resumidamente, los
requerimientos han de: satisfacer los objetivos, superar los desafíos y contrarrestar los
inconvenientes.
Cualquier conjunción de los requerimientos de una solución puede interpretarse como
otro requerimiento que constituye la condición de un subproblema del problema
inicial, y una solución de ese subproblema es un módulo de la estructura de una
solución del problema inicial. En consecuencia, una cobertura mediante
requerimientos del conjunto de los objetivos del problema, los desafíos y los
inconvenientes, proporciona un árbol de dos niveles: el nivel 0 contiene un nodo raíz
Página 24 de 32
que representa a una solución del problema y el nivel 1 contiene un nodo por cada
requerimiento de la cobertura, representando cada nodo a un módulo de la solución.
Para el ejemplo de la ensalada, la fase de especificación estructural consiste en
contestar a la cuestión “cómo” es la ensalada, obteniendo los requerimientos de la
solución. Seguimos la estrategia de enunciar requerimientos para obtener una
cobertura de los objetivos y eventualmente los desafíos e inconvenientes que pudieran
haber surgido en la especificación funcional, o surgir ahora asociados a los
requerimientos. Las tablas 9 y 10 muestran un conjunto de requerimientos para el
ejemplo de la ensalada y la secuencia a seguir para obtenerlo.
Tabla. 9. Requerimientos de una solución al problema de la ensalada para cubrir los
objetivos de la tabla 7.
Requerimientos de la ensalada para cubrir los objetivos
objetivos
o1 o2 o3 o4 o5 o6
valor
nutri-
tivo
sabo-
res
diver
sos
aro-
ma a
gra-
dable
apa-
rien-
cia
atrac-
tiva
pre-
cio
bajo
fres-
cura
requerimientos
r1 base de verduras frescas de
buena calidad ✔ ✔ ✔ ✔
r2 núcleo a base de quesos
ligeros ✔ ✔ ✔
r3 aderezo a base de aceite de
oliva ✔ ✔ ✔
r4 elaborar justo antes de servir ✔
r5 incluir pasta en la ensalada ✔
r6 servir raciones reducidas ✔
Página 25 de 32
Tabla. 10. Aparición de desafíos e inconvenientes al definir los requerimientos, y
requerimientos adicionales para superar esos desafíos y contrarrestar esos
inconvenientes.
Aparición de desafíos e inconvenientes, y requerimientos adicionales
objetivos, desafíos e inconvenientes
o1 o2 o3 o4 o5 o6 d1 i1
va-
lor
nu-
tri-
tivo
sa-
bo-
res
di-
ver
sos
aro
ma
a
gra
da-
ble
apa
rien
cia
atra
cti-
va
pre
cio
ba-
jo
fres
cu-
ra
ace
ite
ca-
ro
so-
bre
car
ga
co-
ci-
na
requerimientos
r
1 base de verduras fres-
cas de buena calidad ✔ ✔ ✔ ✔
r
2 núcleo a base de quesos
ligeros ✔ ✔ ✔
r
3 aderezo a base de aceite
de oliva ✔ ✔ ✔
r
4 elaborar justo antes de
servir ✔
r
5 incluir pasta en la ensa-
lada ✔ ✔
r
6 servir raciones reduci-
das ✔ ✔
r
7 planificación de con-
tingencias ✔
Debido al requerimiento r3, aderezo a base de aceite de oliva, surge el desafío d1,
aceite caro. Para superar este nuevo desafío, habría que incorporar requerimientos
adicionales. En este ejemplo no es necesario ya que los requerimientos r5, incluir
pasta en la ensalada, y r6, servir raciones reducidas, permiten superar el desafío del
encarecimiento debido a la incorporación de aceite de oliva.
El requerimiento r4, elaborar justo antes de servir, lleva aparejado el inconveniente i1,
sobrecarga cocina, ya que desencadena contingencias temporales para montar la
ensalada, y ello obliga a una planificación correctiva de la actividad en la cocina, es
decir, a incorporar el requerimiento r7, planificación de contingencias, para
contrarrestar el inconveniente de instantaneidad.
La figura 5 muestra una selección de los módulos de la ensalada que cubre los
objetivos, supera los desafíos y contrarresta los inconvenientes. El conjunto de
requerimientos {r1, r2, r3, r5, r7} proporciona una solución al ingenio ensalada.
Página 26 de 32
Fig. 5. Niveles 0 y 1 del árbol estructural de la ensalada.
Recursivamente, proceder para cada nodo del nivel inferior como si el subproblema
que representa fuera un nuevo problema, es decir, considerando que los
requerimientos de ese nodo representan a la hipótesis del subproblema que resuelve.
La condición de terminación es obtener nodos que sean solución trivial o conocida.
Las hojas del árbol estructural son los módulos elementales que resuelven los
subproblemas atómicos, es decir, los componentes tecnológicos de la solución.
Proporcionan la respuesta a la cuestión “con qué” está hecha la solución.
La figura 6 muestra un árbol estructural completo para el ejemplo de la ensalada,
asumiendo que las materias primas son las que aparecen como nodos hoja, es decir,
que las verduras, la pasta, los condimentos y los quesos se adquieren en el mercado, y
que el programa de planificación también existe.
Si fuera el caso de un restaurante que tiene su propio huerto, cada nodo de las
verduras sería, a su vez, la raíz de un subárbol que represente al proceso agrícola de
producción de la verdura correspondiente.
Fig. 6. Árbol estructural de una solución organoléptica al problema de la ensalada.
ensalada
verduras planificar condimentosquesospasta
ensalada
verduras planificar condimentos
champiñón pimentónespinacarúculalechuga manchego elaborar servir aceite oliva salburgos
quesospasta
Página 27 de 32
1.3. Organización de una estructura
La organización de la estructura de una solución es un grafo dirigido que expresa las
relaciones entre los módulos de esa solución. Los nodos representan a los módulos de
la estructura y cada arista representa una relación entre los nodos que conecta. El
grafo de mayor detalle de la organización es el que contiene los nodos hoja del árbol
estructural pero también es un grafo de la organización cualquiera otro cuyos nodos
pertenezcan al árbol estructural y cumpla la condición de que sean alcanzables todos
los nodos hoja, directamente, o indirectamente a través de los nodos ascendientes.
El algoritmo que proponemos para construir los grafos de la estructura es el siguiente: - Construir un grafo cuyos nodos sean los nodos del nivel 1 del árbol estructural. - Definir las aristas de relación entre los nodos del grafo. - Para cada nodo del árbol estructural que se expande en el subárbol de sus hijos:
- Reemplazar, en el grafo de organización, al nodo por sus hijos. - Propagar, a los hijos que corresponda, cada arista del nodo reemplazado. - Definir las aristas de relación entre los hijos del nodo reemplazado.
En el ejemplo de la ensalada con estructura organoléptica, una posible solución puede
ser la siguiente: - Organización con los nodos del nivel 1 del árbol estructural (figura 7). Los nodos
“verduras” y “pasta” constituyen el módulo “lecho de verduras con pasta”. Cada
uno de los otros nodos queda como un módulo. El módulo “planificar” es el
destino de los demás. - Organización con los nodos del nivel 2 del árbol estructural (figura 8). El módulo
“planificar” se descompone en los módulos “elaborar” y “servir”. El módulo
“condimentos” se descompone en los módulos “sal” y “aliño”, consistiendo este
último en una maceración de aceite de oliva y pimentón. La sal se sirve por
separado. Cada arista de organización que conectaba a dos nodos del nivel 1 se ha
desglosado en las aristas que relacionan nodos del nivel 2 de los subárboles
correspondientes. Además, para cada subárbol con raíz en el nivel 1, se relacionan
los nodos dentro del propio subárbol.
Fig. 7. Grafo de la organización entre los nodos del nivel 1 de la estructura.
lecho de
verduras y
pasta
condimentosplanificarquesos
Página 28 de 32
Fig. 8. Grafo de organización de la ensalada.
6. Decisiones de diseño sobre los factores circunstanciales
Los factores circunstanciales caracterizan el contexto en que tiene lugar la actividad
en sí de realización de la solución que se diseña. Dicho contexto consiste en la
respuesta a todas las demás preguntas del “para hacer” que sean distintas del modelo
y de los factores esenciales, es decir, en la respuesta a las cuestiones “cuando”,
“quién”, “cuánto”, “dónde”, etc.
La conclusión del análisis del estado del conocimiento sobre el contexto de la
realización de la solución a un problema es que hay tantos procedimientos como
autores, es decir, cada ingeniero utiliza criterios propios para tomar las decisiones
contextuales de diseño, y lo hace siguiendo una secuencia particular, según
preferencias propias e incluso distinta para cada problema que resuelve [Banville,
1989].
Tal ausencia de sistematización avala que, con carácter general, carece de sentido
conceptual que haya precedencia de ningún tipo entre los factores circunstanciales. En
la práctica, esto, que es una obviedad, da lugar a diversas secuencias procedimentales
de toma de decisiones sobre el contexto. Por ejemplo, es frecuente que las respuestas
a la cuestión “cuánto” estén entre las primeras que se abordan, provocando notable
lecho de
verduras y
pasta
servir
aliñoelaborarquesos
sal
Página 29 de 32
impacto en la calidad de la solución. También podemos encontrar soluciones
obtenidas con criterio de conceder precedencia a las respuestas de la cuestión “quién
es el autor” pero con categoría de cuestión de contexto. Esas soluciones suelen tener
la impronta estilística del autor. Precedencia de las respuestas a la cuestión “quién es
el autor” que vaya más allá, sitúa a estas respuestas en la categoría de los factores
esenciales explícitos (para qué) y puede producir soluciones en que los aspectos
estilísticos estén por encima de otros factores arquitecturales como la propia
usabilidad o la robustez de la solución (casas inhóspitas, puentes impracticables,
catedrales interminables, smartphones que se doblan,…).
Conceptualmente, está claro que la justificación de las secuencias de acciones, para
tomar las decisiones sobre la parte contextual de una solución, es independiente del
problema.
La consecuencia formal es que, en el caso general, no existen relaciones de orden que
sean causales, es decir, inspiradas en el problema. La consecuencia metodológica es
que la definición del contexto de resolución de un problema es una actividad
intrínsecamente paralela. Por lo tanto, el tratamiento que corresponde es el de la
concurrencia de un conjunto de objetivos contextuales que debe alcanzar la solución.
Definimos el contexto de resolución de un problema como otro problema que puede
resolverse recursivamente de arriba hacia abajo basándose en la formalización
algebraica propuesta en este documento para la parte arquitectural (la de los factores
esenciales) de los problemas.
A lo más que podemos llegar en el caso general es a proponer un modelo para el
contexto de un problema.
Definición. El contexto general de un problema es otro problema cuyo dominio es el
conjunto de factores de diseño contenidos en las respuestas de las preguntas circuns-
tanciales del primero, excluidas las que constan explícitamente en su hipótesis, y cuya
condición es nula.
7. Conclusiones
Este artículo propone la clasificación de las decisiones que toman los ingenieros para
diseñar soluciones a los problemas de ingeniería a que se enfrentan. Hemos obtenido
cinco clases de decisiones: las orientadas al problema son las decisiones sobre el
modelo; las orientadas a la solución son las decisiones sobre la arquitectura, la
estructura, y la tecnología; y las decisiones sobre la realización del prototipo son las
del contexto. Respectivamente, son decisiones para conocer, para conocer cómo, y
para cómo hacer, y las hemos vinculado empíricamente a la actividad intuitiva de
contestar, respectivamente, a las cuestiones “qué”, “para qué”, “cómo”, “con qué”, y
“las demás”, que son implícitas a la pregunta universal “qué es lo que hay que hacer
para hacer una cosa”. A las respuestas a esas cuestiones, es decir, los elementos de las
clases de decisiones, las hemos llamado factores de diseño.
Página 30 de 32
Hemos ordenado las clases de factores de diseño según la secuencia: modelo >
arquitectura > estructura > tecnología > contexto. Con esto, disponemos de un base
formal para establecer un método para que el ingeniero tome las decisiones de diseño.
El hecho de que la hipótesis representa una versión del problema cercana a dominio
del modelo y de la arquitectura, hace que el diseño, para que sea causalmente
correcto, tenga que empezar por tomar decisiones sobre el modelo que proporciona el
marco a la solución, y continuar tomando decisiones secuencialmente según el orden
que hemos encontrado.
Dentro de cada clase de factores de diseño, los criterios de precedencia para
determinar cuáles son las decisiones de diseño que hay que tomar antes y cuáles han
de subordinarse, dependen de los objetivos de optimización y, por lo tanto, de cada
problema o de cada solución. Por ejemplo, las decisiones de diseño sobre la estructura
(selección de unos u otros requerimientos, árbol de módulos más horizontal o con más
niveles, etc.) no están sujetas a un método general independiente del problema, sino
que están dirigidas por los objetivos de optimización, que son dependientes de cada
caso. Lo mismo ocurre en cuanto a las decisiones de diseño sobre el contexto, de
manera que no es posible pronunciarse con carácter general sobre la precedencia de
los aspectos modales del diseño, es decir, no hay criterio general para establecer
precedencia entre las decisiones sobre tiempos, precios, autoría, y los demás aspectos
del contexto de diseño.
Referencias
1. [Crespi, 2008] Crespi, V., Galstyan, A. & Lerman, K., Top-down vs bottom-up
methodologies in multi-agent system design, Autonomous Robots, Vol 24 Issue 3, pp.
303-313, 2008. DOI 10.1007/s10514-007-9080-5
2. [Kundert, 2001] Kundert, K, A Formal Top-Down Design Process for Mixed-Signal
Circuits, Url: http://designers-guide.org/Design/top-down.pdf, 2001.
3. [Kundert, 2003] Kundert, K. Principles of Top-Down Mixed- Signal Design, Url:
http://www.designers-guide.org/Design/tdd-principles.pdf.
4. [Balasubramanian, 2006] Balasubramanian, K., Gokhale, A., Karsai, G., Sztipanovitis, J.,
& Neema, S., Developing Applications Using Model-Driven Design Environments,
Computer, Vol. 39 no 2, pp. 33-40, 2006. DOI 10.1109/MC.2006.54
5. [Mäntylä, 1990] Mäntylä, M., A modeling system for top-down design assembled
products, IBM Journal of Research and Development, Vol. 34 Issue 5, pp 636-659, 1990.
DOI 10.1147/rd.345.0636
6. [Edunpuganty, 1989] Edunpuganty, B. & Bryant B.R., "Two-level Grammar as a
Functional Programming Language", Oxford Journals - Mathematics & Physical Sciences
- Computer Journal, Vol. 32, Issue 1, pp. 36-44, 1989.
7. [Wijngaarden, 1965] Wijngaarden, van A., "Orthogonal design and description of a formal
language", Stichting Mathematisch Centrum, pp. 1-25, 1965.
8. [Qi, 2009] Qi, F., “A assembly modeling method based on assembly feature Graph-Tree
model", Industrial Engineering and Engineering Management, 2009. IE&EM '09. 16th In-
ternational Conference on. DOI 10.1109/ICIEEM.2009.5344360
9. [Huang, 2008] Huang, J. & Zhang, H., “Multi-Granularity Modeling of virtual prototyping
in collaborative product design” Computer Supported Cooperative Work in Design,
Página 31 de 32
CSCWD 2008. 12th International Conference on, pp. 710 - 715, 2008. DOI
10.1109/CSCWD.2008.4537065
10. [Zhang, 2013] Zhang, C.; Mao, H.; Peng, G. & Zhang, H. "A novel BOM based mul-
ti-resolution model for federated simulation", Computer Supported Cooperative Work in
Design (CSCWD), 2013 IEEE 17th International Conference on, On page(s): 178 - 183,
2013. DOI 10.1109/CSCWD.2013.6580959
11. [Brunetti, 2000] Brunetti, G. & Golob, B. “A feature-based approach towards an inte-
grated product model including conceptual design information”, Computer-Aided Design,
Vol 32, Issue 14, pp. 877–8827, December 2000. DOI 10.1016/S0010-4485(00)00076-2
12. [Otto, 2001] Otto, H.E. “From concepts to consistent object specifications: Transla-
tion of a domain-oriented feature framework into practice” Journal of Computer Science
and Technology, Vol 16, Issue 3, pp 208-230, May 2001. DOI 10.1007/BF02943200
13. [Spivey, 1992] J.M. Spivey, "The Z notation: a reference manual", Prentice Hall In-
ternational (UK) Ltd. Hertfordshire, UK, 1992, ISBN:0-13-978529-9.
14. [Duke, 1995] R. Duke, G. Rose & G. Smith, "Object-Z: A specification language ad-
vocated for the description of standards", Computer Standards & Interfaces, Vol. 17, pp.
511-533, 1995.
15. [Jackson, 2002] D. Jackson, "Alloy: a lightweight object modelling notation", ACM
Transactions on Software Engineering and Methodology, Vol. 11, Issue 2, pp. 256-290,
2002.
16. [Gomez, 1999] Gómez, F., Segami, C. & Delaune, C. "A system for the semiautomat-
ic generation of E-R models from natural language specifications", Data & Knowledge
Engineering, Vol. 29, pp. 57-81, 1999.
17. [Deeptimahanti, 2009] Deeptimahanti, D.K. & Ali Babar, M., "An Automated Tool
for Generating UML Models from Natural Language Requirements", IEEE/ACM Interna-
tional Conference on Automated Software Engineering, pp. 680-682, 2009.
18. [Jlieva, 2005] Ilieva, M. G. & Ormandjieva, O., "Automatic Transition of Natural
Language Software Requirements Specification into Formal Presentation", Lecture Notes
in Computer Science Natural Language Processing and Information Systems, Vol. 3513,
pp. 392-397, 2005.
19. [Meziane, 2008] Meziane, F., Athanasakis, N. & Ananiadou S., "Generating Natural
Language specifications from UML class diagrams", Requirements Engineering, Vol. 13,
pp. 1-18, 2008
20. [Brunel, 1998] J. M. Brunel & R. B. France, "Transforming UML models to formal
specifications", Proceedings of the OOPSLA, 1998.
21. [Coleman, 1994] Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H.,
Hayes, F. & Jeremaes, P., "Object-Oriented Development: The Fusion Method", Prentice
Hall, 1994.
22. [Hannay, 2007] Hannay, J.E.; Sjoberg, Dag I.K. & Dyba, Tore, "A Systematic Re-
view of Theory Use in Software Engineering Experiments", IEEE Transactions on Soft-
ware Engineering, Vol 33, Issue: 2, pp 87 - 107, 2007. DOI 10.1109/TSE.2007.12.
23. [Gregg, 2001] Gregg, D.G., Kulkarni, U.R. & Vinzé, A.S., “Understanding the Phi-
losophical Underpinnings of Software Engineering Research in Information Systems" In-
formation Systems Frontiers, Vol 3, Issue 2, pp 169-183, 2001. DOI
10.1023/A:1011491322406
24. [Sjoberg, 2007] Sjoberg, Dag I.K. ; Simula Res. Lab., Lysaker ; Dyba, Tore ; Jorgen-
sen, M., “The Future of Empirical Methods in Software Engineering Research”, Future of
Software Engineering, 2007. FOSE ‟07, pp. 358 - 378. DOI 10.1109/FOSE.2007.30
Página 32 de 32
25. [Easterbrook, 2008] Easterbrook, S.; Singer, J.; Storey, M.A. & Damian, D.; “Select-
ing Empirical Methods for Software Engineering Research”; Guide to Advanced Empirical
Software Engineering, pp 285-311. 2008. DOI 10.1007/978-1-84800-044-5_11
26. [Stol, 2013] Stol, K.-J. ; Lero-The Irish Software Eng. Res. Centre, Univ. of Lime-
rick, Limerick, Ireland ; Fitzgerald, B., “Uncovering theories in software engineering”,
Software Engineering (GTSE), 2013 2nd SEMAT Workshop on a General Theory of,
pp.5-14, 2013. DOI 10.1109/GTSE.2013.6613863
27. [Wieringa, 2011] Wieringa, R. ; Dept. of Comput. Sci., Univ. of Twente, Enschede,
Netherlands ; Daneva, M.; Condori-Fernandez, N., “The Structure of Design Theories, and
an Analysis of their Use in Software Engineering Experiments”, Empirical Software Engi-
neering and Measurement (ESEM), 2011 International Symposium on, pp. 295 - 304,
2011. DOI 10.1109/ESEM.2011.38
28. [Landry, 1995] Landry, M., A note on the concept of „Problem‟, Organization Studies
Vol.16/2, pp. 315-343, 1995.
29. [Agre, 1982] Agre, G.P., The Concept of Problem, Educational Studies: A Journal of
the American Educational Studies Association, Vol. 13:2, pp. 121-142, 1982. DOI:
10.1207/s15326993es1302_1
30. [Preston, 1991] Preston, A. M., ‟The "problem" in and of management information
sytems‟. Accounting, Management and Information Technologies. Vol 1, Iss 1. pp 43- 69.
1991. doi:10.1016/0959-8022(91)90012-4
31. [Banville, 1989] Banville, C.; Landry, M. Can the Field of MIS be Disciplined?
Communications of the ACM. Vol 32. 1, pp. 48-60,1989.
top related