1. Portada > Artículo
Bruno Munari. ¿qué es un problema?
Metodología para el diseño.
29-07-2004 - César Martín
Resumen: Este diseñador industrial / gráfico plantea un método proyectual basado en la
resolución de problemas. Esta metodología evita el inventar la rueda con cada proyecto
y plantea sistematizar la resolución de problemas.
Debate (73 comentarios) | Valoración media: 3,10 | Votos: 7814 | Lecturas: 190068
1. definición del problema
Lo primero que hay que hacer es definir el problema en su conjunto. �??Muchos
diseñadores creen que los problemas ya han sido suficientemente definidos por sus
clientes. Pero esto no es en absoluto suficiente�?�, dice Archer.
Por tanto es necesario empezar por la definición del problema, que servirá también para
definir los límites en los que deberá moverse el proyectista.
Supongamos que el problema consiste en proyectar una lámpara, habrá que definir si se
trata de una lámpara de sobremesa o de aplique, de estudio o de trabajo, para una sala o
un dormitorio. Si esta lámpara tendrá que ser de incandescencia o fluorescente o de luz
diurna o de otra cosa. Si tiene que tener un precio límite, si va a ser distribuida en los

2. grandes almacenes, si deberá ser desmontable o plegable, si deberá llevar un reóstato
para regular la intensidad luminosa, y cosas por el estilo.
2. elementos del problema
Cualquier problema puede ser descompuesto en sus elementos. Esta operación facilita la
proyectación porque tiende a descubrir los pequeños problemas particulares que se
ocultan tras los subproblemas. Una vez resueltos los pequeños problemas de uno en uno
(y aquí empieza a intervenir la creatividad abandonando la idea de buscar una idea), se
recomponen de forma coherente a partir de todas las características funcionales de cada
una de las partes y funcionales entre sí, a partir de las características materiales,
psicológicas, ergonómicas, estructurales, económicas y, por último, formales.
"Lo bello es la consecuencia de lo correcto", reza una regla japonesa.
El principio de descomponer un problema en sus elementos para poder analizarlo
procede del método cartesiano.
Como los problemas, sobre todo hoy en día, se han convertido en muy complejos y a
veces en complicados, es necesario que el proyectista tenga toda una serie de
informaciones sobre cada problema particular para poder proyectar con mayor
seguridad.
Tal vez sea oportuna una definición de "complejidad" para poder distinguir lo
complejo de lo complicado. Para Abraham A. Moles "un producto es
complicado cuando los elementos que lo componen pertenecen a numerosas
clases diferentes; mientras que es complejo si contiene un gran número de
elementos reagrupables no obstante en pocas clases".
Podría decirse que un automóvil es complicado mientras que un ordenador
electrónico es complejo. Actualmente se tiende a la producción de objetos poco

3. complicados, a reducir el número de las clases de los elementos que forman un
producto. Así pues, en un futuro habrá cada vez menos productos complicados.
Descomponer el problema en sus elementos quiere decir descubrir numerosos
subproblemas. "Un problema particular de diseño es un conjunto de muchos
subproblemas. Cada uno de ellos puede resolverse obteniendo un campo de soluciones
aceptables", asevera Archer.
Cada subproblema tiene una solución óptima que no obstante puede estar en
contradicción con las demás. La parte más ardua del trabajo del diseñador será la de
conciliar las diferentes soluciones con el proyecto global.
La solución del problema general consiste en la coordinación creativa de las soluciones
de los subproblemas.
Supongamos que el problema presentado sea el de proyectar una lámpara y supongamos
también haber definido que se trata de una lámpara de luz diurna para una habitación
normal.
Los subproblemas son:
• Qué tipo de luz deberá tener esta lámpara.
• Si esta luz deberá estar graduada por un reóstato.
• Con qué material habrá que construirla.
• Con qué tecnología habrá que trabajar este material para hacer la lámpara.
• Dónde tendrá el interruptor.
• Cómo será transportada, con qué embalaje.
• Cómo se dispondrá en el almacén.
• Si hay partes ya prefabricadas (portalámparas, reóstato, interruptor, etc.).
• Qué forma tendrá.
• Cuánto deberá costar.
Estos son los subproblemas que hay que resolver en forma creativa.
3. recopilación de datos
Sigamos todavía con el ejemplo del proyecto de la lámpara y veamos qué datos
convendrá recoger para decidir luego los elementos constitutivos del proyecto. En
primer lugar el diseñador tendrá que recoger todos los catálogos de las fábricas que
producen lámparas parecidas a la que hay que proyectar. Es evidente que, antes de
pensar en cualquier posible solución, es mejor documentarse. No vaya a ser que alguien
se nos haya adelantado. Carece completamente de sentido ponerse a pensar en un tipo
de solución sin saber si la lámpara en la que estamos trabajando ya existe en el mercado.
Por supuesto se encontrarán muchos ejemplos que habrá que descartar pero al final,
eliminando los duplicados y los tipos que nunca podrán ser competitivos, tendremos una
buena recopilación de datos.
Luego para cada elemento del problema, tendremos que buscar nuevamente más datos:
• Cuántos tipos de bombillas existen actualmente en el mercado.

4. • Cuántos tipos de reóstatos.
• Cuántos tipos de interruptores.
• Etcétera.
4. análisis de datos
El análisis de todos los datos recogidos puede proporcionar sugerencias sobre qué es lo
que no hay que hacer para proyectar bien una lámpara, y puede orientar la proyectación
hacia otros materiales, otras tecnologías, otros costes.
5. creatividad
La creatividad reemplazará a la idea intuitiva, vinculada todavía a la forma artístico-
romántica de resolver un problema. Así pues, la creatividad ocupa el lugar de la idea y
procede según su método. Mientras la idea, vinculada a la fantasía, puede proponer
soluciones irrealizables por razones técnicas, materiales o económicas, la creatividad se
mantiene en los límites del problema, límites derivados del análisis de los datos y de los
subproblemas.
6. materiales - tecnologías
La sucesiva operación consiste en otra pequeña recogida de datos relativos a los
materiales y a las tecnologías que el diseñador tiene a su disposición en aquel momento
para realizar su proyecto. La industria que ha planteado el problema al diseñador
dispondrá ciertamente de una tecnología propia para fabricar determinados materiales y
no otros. Por tanto es inútil pensar en soluciones al margen de estos dos datos relativos a
los materiales y a las tecnologías.
7. experimentación

5. Es ahora cuando el proyectista realizará una experimentación de los materiales y las
técnicas disponibles para realizar su proyecto. Muy a menudo materiales y técnicas son
utilizados de una única forma o de muy pocas formas según la tradición. Muchos
industriales dicen: �??Siempre lo hemos hecho así, ¿por qué habría que cambiar?�?
�. En cambio la experimentación permite descubrir nuevos usos de un material o de un
instrumento.
Hace algunos años fue lanzado al mercado un producto industrial llamado Fibralín,
compuesto de fibras de rayón entretejidas como un fieltro, de goma sintética. Este
material había sido producido para sustituir a determinados tejidos utilizados en la
confección en el interior de las prendas y se fabrica en diferentes grosores, desde el del
papel de fumar al del cartón. Tenía un precio muy asequible y un aspecto agradable
parecido al papel de seda japonés.
Este material, que todavía se produce, resiste bien la impresión serigráfica, y yo mismo
hice varias pruebas con él. Con este material proyecté instalaciones efímeras para
exposiciones de productos industriales. Desde entonces ese material, inventado para la
confección, es utilizado por sus cualidades y posibilidades específicas, incluso en
instalaciones y en impresiones artísticas en serigrafía.
8. modelos
Estas experimentaciones permiten extraer muestras, pruebas, informaciones, que pueden
llevar a la construcción de modelos demostrativos de nuevos usos para determinados
objetivos. Estos nuevos usos pueden ayudar a resolver subproblemas parciales que a su
vez, junto con los demás, contribuirán a la solución global.
Como se desprende de este esquema de método, todavía no hemos hecho ningún dibujo,
ningún boceto, nada que pueda definir la solución. Todavía no sabemos qué forma
tendrá lo que hay que proyectar. Pero en cambio tenemos la seguridad de que el margen
de posibles errores será muy reducido. Ahora podemos empezar a establecer relaciones
entre los datos recogidos e intentar aglutinar los subproblemas y hacer algún boceto
para construir modelos parciales. Estos bocetos hechos a escala o a tamaño natural
pueden mostrarnos soluciones parciales de englobamiento de dos o más subproblemas.
De esta forma obtendremos un modelo de lo que eventualmente podrá ser la solución
del problema.
9. verificación
Este es el momento de llevar a cabo una verificación del modelo o de los modelos
(puede ocurrir que las soluciones posibles sean más de una). Se presenta el modelo a un
determinado número de probables usuarios y se les pide que emitan un juicio sincero
sobre el objeto en cuestión. Sobre la base de estos juicios se realiza un control del
modelo para ver si es posible modificarlo, siempre que las observaciones posean un
valor objetivo.

6. En base a todos estos datos ulteriores se pueden empezar a preparar los dibujos
constructivos a escala o a tamaño natural, con todas las medidas exactas y todas las
indicaciones necesarias para la realización del prototipo.
bocetos
Los dibujos constructivos tendrán que servir para comunicar a una persona que no esté
al corriente de nuestros proyectos todas las informaciones útiles para preparar un
prototipo.
El esquema del método de proyectación, ilustrado en páginas precedentes, no es un
esquema fijo, no está completo y no es único y definitivo. Es lo que la experiencia nos
ha dictado hasta ahora. Insistimos sin embargo en que, a pesar de tratarse de un
esquema flexible, es mejor proceder, de momento, a las operaciones indicadas en el
orden presentado: igual que en la proyectación del arroz verde (ver más abajo) no puede
ponerse la cazuela al fuego sin el agua ni preparar el condimento una vez cocido el
arroz.
No obstante, si hay alguien capaz de demostrar objetivamente que es mejor cambiar el
orden de alguna operación, el diseñador está siempre dispuesto a modificar su
pensamiento frente a la evidencia objetiva, y es así como cada uno puede aportar su
contribución creativa a la estructuración de un método de trabajo que tiende, como es
sabido, a obtener el máximo resultado con el mínimo esfuerzo.
Ejemplo:Problema arroz verde
Definición del problema arroz verde con espinacas para cuatro personas
Elementos del problema arroz, espinacas, jamón, cebolla, aceite, sal, pimienta, caldo
Recopilación de datos ¿hay alguien que lo haya hecho antes?
Análisis de datos ¿cómo lo ha hecho? ¿qué puedo aprender de él?
Creatividad ¿cómo puede conjugarse todo esto de una forma correcta?
Materiales Tecnología ¿qué arroz? ¿qué cazuela? ¿qué fuego?
Experimentación pruebas, ensayos
Modelos muestra definitiva
Verificación bien, vale para 4
Dibujos Constructivos �??
Solución Arroz Verde servido en plato caliente

7. Cómo evitar problemas con clientes
En este artículo se explica como evitar problemas con clientes. Evitar problemas es
quizás la mejor solución a los problemas en si. Si te encuentras metido en problemas, la
solución más normal es reconocerlos y remediarlos.
bibliografía
Ofrecidos por la editorial GG
Bruno Munari, "Cómo nacen los objetos". Editorial GG_Diseño.
Bruno Munari, " Diseño y comunicación visual". Editorial GG_Diseño.
Amazon
Bruno munari. Quizás el favorito sea "Air made visible"
Comentarios
Debate en torno a este artículo: Debate (73 comentarios)
Quieres dejar tus comentarios a este artículo? Acude a la página de Comentarios
Puntúa este artículo
Compartir contenido: Menéame, Del.icio.us
Next: Resumen Up: Diseño conceptual de bases Previous: El modelo entidad-relación
Índice General
Metodología de diseño conceptual
El primer paso en el diseño de una base de datos es la producción del esquema
conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para
representar las distintas visiones que los usuarios tienen de la información. Cada una de
estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa
como, por ejemplo, producción, ventas, recursos humanos, etc.
Estas visiones de la información, denominadas vistas, se pueden identificar de varias
formas. Una opción consiste en examinar los diagramas de flujo de datos, que se pueden
haber producido previamente, para identificar cada una de las áreas funcionales. La otra
opción consiste en entrevistar a los usuarios, examinar los procedimientos, los informes
y los formularios, y también observar el funcionamiento de la empresa.

8. A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina
esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades,
relaciones, atributos, dominios de atributos e identificadores. El esquema conceptual
también tendrá una documentación, que se irá produciendo durante su desarrollo. Las
tareas a realizar en el diseño conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama entidad-relación.
8. Revisar el esquema conceptual local con el usuario.
1. Identificar las entidades
En primer lugar hay que definir los principales objetos que interesan al usuario. Estos
objetos serán las entidades. Una forma de identificar las entidades es examinar las
especificaciones de requisitos de usuario. En estas especificaciones se buscan los
nombres o los sintagmas nominales que se mencionan (por ejemplo: número de
empleado, nombre de empleado, número de inmueble, dirección del inmueble, alquiler,
número de habitaciones). También se buscan objetos importantes como personas,
lugares o conceptos de interés, excluyendo aquellos nombres que sólo son propiedades
de otros objetos. Por ejemplo, se pueden agrupar el número de empleado y el nombre de
empleado en una entidad denominada empleado, y agrupar número de inmueble,
dirección del inmueble, alquiler y número de habitaciones en otra entidad denominada
inmueble.
Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí
mismos. Por ejemplo, empleado es una entidad porque los empleados existen, sepamos
o no sus nombres, direcciones y teléfonos. Siempre que sea posible, el usuario debe
colaborar en la identificación de las entidades.
A veces, es difícil identificar las entidades por la forma en que aparecen en las
especificaciones de requisitos. Los usuarios, a veces, hablan utilizando ejemplos o
analogías. En lugar de hablar de empleados en general, hablan de personas concretas, o
bien, hablan de los puestos que ocupan esas personas.
Para liarlo aún más, los usuarios usan, muchas veces, sinónimos y homónimos. Dos
palabras son sinónimos cuando tienen el mismo significado. Los homónimos ocurren
cuando la misma palabra puede tener distintos significados dependiendo del contexto.
No siempre es obvio saber si un objeto es una entidad, una relación o un atributo. Por
ejemplo ¿cómo se podría clasificar matrimonio? Pues de cualquiera de las tres formas.
El análisis es subjetivo, por lo que distintos diseñadores pueden hacer distintas
interpretaciones, aunque todas igualmente válidas. Todo depende de la opinión y la
experiencia de cada uno. Los diseñadores de bases de datos deben tener una visión
selectiva y clasificar las cosas que observan dentro del contexto de la empresa u
organización. A partir de unas especificaciones de usuario es posible que no se pueda

9. deducir un conjunto único de entidades, pero después de varias iteraciones del proceso
de análisis, se llegará a obtener un conjunto de entidades que sean adecuadas para el
sistema que se ha de construir.
Conforme se van identificando las entidades, se les dan nombres que tengan un
significado y que sean obvias para el usuario. Los nombres de las entidades y sus
descripciones se anotan en el diccionario de datos. Cuando sea posible, se debe anotar
también el número aproximado de ocurrencias de cada entidad. Si una entidad se conoce
por varios nombres, éstos se deben anotar en el diccionario de datos como alias o
sinónimos.
2. Identificar las relaciones
Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas.
Del mismo modo que para identificar las entidades se buscaban nombres en las
especificaciones de requisitos, para identificar las relaciones se suelen buscar las
expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona
inmueble, cliente visita inmueble). Si las especificaciones de requisitos reflejan estas
relaciones es porque son importantes para la empresa y, por lo tanto, se deben reflejar
en el esquema conceptual.
Pero sólo interesan las relaciones que son necesarias. En el ejemplo anterior, se han
identificado las relaciones empleado gestiona inmueble y cliente visita inmueble. Se
podría pensar en incluir una relación entre empleado y cliente: empleado atiende a
cliente, pero observando las especificaciones de requisitos no parece que haya interés en
modelar tal relación.
La mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar
que también puede haber relaciones en las que participen más de dos entidades, así
como relaciones recursivas.
Es muy importante repasar las especificaciones para comprobar que todas las relaciones,
explícitas o implícitas, se han encontrado. Si se tienen pocas entidades, se puede
comprobar por parejas si hay alguna relación entre ellas. De todos modos, las relaciones
que no se identifican ahora se suelen encontrar cuando se valida el esquema con las
transacciones que debe soportar.
Una vez identificadas todas las relaciones, hay que determinar la cardinalidad mínima y
máxima con la que participa cada entidad en cada una de ellas. De este modo, el
esquema representa de un modo más explícito la semántica de las relaciones. La
cardinalidad es un tipo de restricción que se utiliza para comprobar y mantener la
calidad de los datos. Estas restricciones son aserciones sobre las entidades que se
pueden aplicar cuando se actualiza la base de datos para determinar si las
actualizaciones violan o no las reglas establecidas sobre la semántica de los datos.
Conforme se van identificando las relaciones, se les van asignando nombres que tengan
significado para el usuario. En el diccionario de datos se anotan los nombres de las
relaciones, su descripción y las cardinalidades con las que participan las entidades en
ellas.

10. 3. Identificar los atributos y asociarlos a entidades y relaciones
Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos.
Son atributos los nombres que identifican propiedades, cualidades, identificadores o
características de entidades o relaciones.
Lo más sencillo es preguntarse, para cada entidad y cada relación, ¿qué información se
quiere saber de ...? La respuesta a esta pregunta se debe encontrar en las
especificaciones de requisitos. Pero, en ocasiones, será necesario preguntar a los
usuarios para que aclaren los requisitos. Desgraciadamente, los usuarios pueden dar
respuestas a esta pregunta que también contengan otros conceptos, por lo que hay que
considerar sus respuestas con mucho cuidado.
Al identificar los atributos, hay que tener en cuenta si son simples o compuestos. Por
ejemplo, el atributo dirección puede ser simple, teniendo la dirección completa como un
solo valor: `San Rafael 45, Almazora'; o puede ser un atributo compuesto, formado por
la calle (`San Rafael'), el número (`45') y la población (`Almazora'). El escoger entre
atributo simple o compuesto depende de los requisitos del usuario. Si el usuario no
necesita acceder a cada uno de los componentes de la dirección por separado, se puede
representar como un atributo simple. Pero si el usuario quiere acceder a los
componentes de forma individual, entonces se debe representar como un atributo
compuesto.
También se deben identificar los atributos derivados o calculados, que son aquellos
cuyo valor se puede calcular a partir de los valores de otros atributos. Por ejemplo, el
número de empleados de cada oficina, la edad de los empleados o el número de
inmuebles que gestiona cada empleado. Algunos diseñadores no representan los
atributos derivados en los esquemas conceptuales. Si se hace, se debe indicar claramente
que el atributo es derivado y a partir de qué atributos se obtiene su valor. Donde hay que
considerar los atributos derivados es en el diseño físico.
Cuando se están identificando los atributos, se puede descubrir alguna entidad que no se
ha identificado previamente, por lo que hay que volver al principio introduciendo esta
entidad y viendo si se relaciona con otras entidades.
Es muy útil elaborar una lista de atributos e ir eliminándolos de la lista conforme se
vayan asociando a una entidad o relación. De este modo, uno se puede asegurar de que
cada atributo se asocia a una sola entidad o relación, y que cuando la lista se ha
acabado, se han asociado todos los atributos.
Hay que tener mucho cuidado cuando parece que un mismo atributo se debe asociar a
varias entidades. Esto puede ser por una de las siguientes causas:
• Se han identificado varias entidades, como director, supervisor y administrativo,
cuando, de hecho, pueden representarse como una sola entidad denominada
empleado. En este caso, se puede escoger entre introducir una jerarquía de
generalización, o dejar las entidades que representan cada uno de los puestos de
empleado.
• Se ha identificado una relación entre entidades. En este caso, se debe asociar el
atributo a una sola de las entidades y hay que asegurarse de que la relación ya se

11. había identificado previamente. Si no es así, se debe actualizar la documentación
para recoger la nueva relación.
Conforme se van identificando los atributos, se les asignan nombres que tengan
significado para el usuario. De cada atributo se debe anotar la siguiente información:
• Nombre y descripción del atributo.
• Alias o sinónimos por los que se conoce al atributo.
• Tipo de dato y longitud.
• Valores por defecto del atributo (si se especifican).
• Si el atributo siempre va a tener un valor (si admite o no nulos).
• Si el atributo es compuesto y, en su caso, qué atributos simples lo forman.
• Si el atributo es derivado y, en su caso, cómo se calcula su valor.
• Si el atributo es multievaluado.
4. Determinar los dominios de los atributos
El dominio de un atributo es el conjunto de valores que puede tomar el atributo. Por
ejemplo el dominio de los números de oficina son las tiras de hasta tres caracteres en
donde el primero es una letra y el siguiente o los dos siguientes son dígitos en el rango
de 1 a 99; el dominio de los números de teléfono y los números de fax son las tiras de 9
dígitos.
Un esquema conceptual está completo si incluye los dominios de cada atributo: los
valores permitidos para cada atributo, su tamaño y su formato. También se puede incluir
información adicional sobre los dominios como, por ejemplo, las operaciones que se
pueden realizar sobre cada atributo, qué atributos pueden compararse entre sí o qué
atributos pueden combinarse con otros. Aunque sería muy interesante que el sistema
final respetara todas estas indicaciones sobre los dominios, esto es todavía una línea
abierta de investigación.
Toda la información sobre los dominios se debe anotar también en el diccionario de
datos.
5. Determinar los identificadores
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos
los identificadores de cada una de las entidades. Los identificadores pueden ser simples
o compuestos. De cada entidad se escogerá uno de los identificadores como clave
primaria en la fase del diseño lógico.
Cuando se determinan los identificadores es fácil darse cuenta de si una entidad es
fuerte o débil. Si una entidad tiene al menos un identificador, es fuerte (otras
denominaciones son padre, propietaria o dominante). Si una entidad no tiene atributos
que le sirvan de identificador, es débil (otras denominaciones son hijo, dependiente o
subordinada).
Todos los identificadores de las entidades se deben anotar en el diccionario de datos.
6. Determinar las jerarquías de generalización

12. En este paso hay que observar las entidades que se han identificado hasta el momento.
Hay que ver si es necesario reflejar las diferencias entre distintas ocurrencias de una
entidad, con lo que surgirán nuevas subentidades de esta entidad genérica; o bien, si hay
entidades que tienen características en común y que realmente son subentidades de una
nueva entidad genérica.
En cada jerarquía hay que determinar si es total o parcial y exclusiva o superpuesta.
7. Dibujar el diagrama entidad-relación
Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad-
relación correspondiente a una de las vistas de los usuarios. Se obtiene así un esquema
conceptual local.
8. Revisar el esquema conceptual local con el usuario
Antes de dar por finalizada la fase del diseño conceptual, se debe revisar el esquema
conceptual local con el usuario. Este esquema está formado por el diagrama entidad-
relación y toda la documentación que describe el esquema. Si se encuentra alguna
anomalía, hay que corregirla haciendo los cambios oportunos, por lo que posiblemente
haya que repetir alguno de los pasos anteriores. Este proceso debe repetirse hasta que se
esté seguro de que el esquema conceptual es una fiel representación de la parte de la
empresa que se está tratando de modelar.
Next: Resumen Up: Diseño conceptual de bases Previous: El modelo entidad-relación
Índice General
María Mercedes Marqués Andrés
2001-02-12