Tema1 proyectos

LOS PROYECTOS DE INGENIERÍA
-1-
LOS PROYECTOS DE INGENIERÍA.
1.- ¿Qué es la ingeniería ?
Según el Diccionario de la Real Academia de la Lengua Española, ingeniería es el “con-
junto de conocimientos y técnicas que permiten aplicar el saber científico a la utiliza-
ción de la materia y de las fuentes de energía, mediante invenciones o construcciones
útiles para el hombre”. En esta definición queda resaltada la necesidad de la utilidad de
lo inventado o construido, de donde puede deducirse que en todo trabajo de ingeniería
debe subyacer, de forma última, la persecución de un fin social; pero no se expresa otro
concepto muy importante en ingeniería y que es el aprovechamiento óptimo de recursos
y el logro de fines económicos. Así, la definición de la Real Academia puede ser refor-
mada y completada con la que se apunta a continuación: “la ingeniería es una actividad
profesional que usa el método científico para transformar de una manera económica y
óptima, los recursos naturales en formas útiles para el hombre.
Según esta nueva definición, un ingeniero necesita tener una amplia formación científica
y técnica que le permita abordar, de la forma más económica posible y utilizando un mí-
nimo de recursos, los problemas que la sociedad le plantee. Estos problemas tendrán
que ser estudiados en sus tres vertientes : técnica, económica y humana, para que pue-
da decirse que las soluciones de ingeniería adoptadas son realmente aceptables.
Desde el punto de vista de la Ingeniería del Software, una de las definiciones más co-
múnmente aceptadas es : “el establecimiento y uso de principios de ingeniería robus-
tos, orientados a obtener software económico que sea fiable y funcione de manera efi-
ciente sobre máquinas reales”.
1

-2-
1.1.- Características diferenciadoras de la ingeniería del software respecto
a la ingeniería tradicional.
Existe una serie de condicionantes específicos de la Ingeniería de Proyectos de Soft-
ware respecto a la Ingeniería tradicional, donde se da por supuesto que, en la mayoría
de los casos, se pretende construir o ejecutar obras, instalaciones o máquinas que con-
tribuirán a aumentar la rentabilidad económica de las empresas o a solucionar problemas
de manejo de materiales o de automatización de procesos. Respecto al software, éste no
da lugar a entidades físicas tangibles que hagan nada real en la mayoría de los casos,
excepto en aquellas circunstancias en que el software se utiliza para gobernar máquinas.
Así, puede decirse que la característica diferenciadora del software que favorece su dis-
tinción respecto a la metodología a utilizar en el diseño de proyectos es:
El software se desarrolla, no se fabrica. En los conceptos clásicos de ingeniería
se trataba de aplicar el conocimiento científico a la resolución de problemas rea-
les mediante el diseño y construcción de máquinas, instalaciones y edificios. Bajo
este punto de vista el componente principal del coste del proyecto se ubica en la
construcción o ejecución propiamente dicha, mientras que el coste derivado del
diseño puede aparecer como sustancialmente menor o incluso como insignifi-
cante. Es más, la mayor parte del esfuerzo que se realiza en la etapa de diseño
de proyectos de ingeniería clásica, estriba en evitar aumentos graves de coste en
la etapa de ejecución debidos a falta de previsión, malos cálculos, defectos de
funcionamiento, mala planificación, etc. Por el contrario, en proyectos de desa-
rrollo de software, la parte principal del coste gravita sobre la fase de diseño pro-
piamente dicha ya que, una vez concluida la misma, el resto del proceso de desa-
rrollo se reduce a la codificación. Por todo ello, a la hora de realizar un proyecto
de software lo más importante es estructurar convenientemente el periodo de di-
seño o diseñar el diseño.
2.- El proyecto de ingeniería.
En su acepción más amplia, el término proyecto expresa la “intención o pensamiento de
hacer algo para lo que se requerirá, generalmente, la utilización y el consumo de me-
dios”. Surge aquí el concepto de proyecto como un plan para ejecutar algo que, desde el
punto de vista de la ingeniería, se concretará en un estudio detallado tendente a resolver
los problemas técnicos, económicos y humanos mencionados anteriormente. A esta
acepción del término proyecto la denominaremos abreviadamente Proyecto Idea.

-3-
Siguiendo la definición dada por el Diccionario de la Real Academia en su acepción
quinta, un proyecto es “el conjunto de escritos, cálculos y dibujos que se hacen para dar
idea de cómo ha de ser y lo que ha de costar una obra de ingeniería”. Lógicamente, una
vez concebido un plan para resolver cualquier clase de problema, todo el estudio reali-
zado, las soluciones de diseño adoptadas, las normas a seguir para llevarlas a cabo y su
coste previsto deben recogerse en un documento. En el mismo sentido de esta acepción
existe en España una definición legal aprobada por el Decreto de la Presidencia del Go-
bierno de 19 de Octubre de 1961 en el que se dice que un proyecto es “un conjunto o
serie de documentos que definen la obra, de forma tal que un facultativo distinto del
autor pueda dirigir con arreglo al mismo las obras o trabajos correspondientes”. Evi-
dentemente, y considerando la fecha en que aparece, esta definición se refiere a la eje-
cución de proyectos clásicos, si bien debe quedar apuntado el hecho de que el docu-
mento que refleje el proyecto debe ser lo suficientemente claro y detallado como para
permitir a otra persona de la misma cualificación que el autor, comprender los algoritmos
que se utilizan, reproducir los programas generados, e instalarlos y mantenerlos ade-
cuadamente. En consecuencia, a esta definición del proyecto la llamaremos Proyecto
Documento. Otra definición en este sentido que complementa a la anterior en la idea de
ordenamiento de la información es la siguiente : “conjunto o serie de documentos que
representan, de forma ordenada, toda la información necesaria para la realización de
una obra o trabajo determinado”.
Una definición de proyecto desde el punto de vista de la economía sería “una actividad
en la que se invertirá dinero esperando obtener un rendimiento, y que desde el punto
de vista lógico se presta a su planificación, financiación y ejecución como un todo”.
Todas las definiciones anteriores se ajustan al concepto de proyecto, pero siempre de
forma parcial en función del punto de vista adoptado, así, una definición más general
puede conseguirse partiendo de la dada por el Diccionario de la Real Academia para el
término PROYECTAR que dice : “idear, trazar, disponer o proponer el plan y los medios
de ejecución de una cosa”. Según esta definición se pueden proyectar “cosas” diversas
tales como líneas eléctricas, máquinas, centrales nucleares o software, ya que se utiliza
el término en sentido amplio.
Ahondando en la última definición propuesta, proyecto es “la combinación de recursos
humanos y no humanos, reunidos en una organización temporal para conseguir un pro-
pósito determinado”. Se introduce así el concepto de uso de los recursos, lo que com-
prende un planeamiento muy general de lo proyectado que excede a la mera descripción
de aquello que se pretende realizar, incluyendo el tiempo que se ha de tardar, los me-

-4-
dios a emplear, el modo de ejecutarlo y las previsiones sobre cuánto costará y la renta-
bilidad económica y social que se pretende obtener.
Según la última definición, y compendiando todo lo anterior, el proyecto debe conside-
rarse integralmente desde el momento en el que se concibe como respuesta a una pro-
blemática humana (proyecto idea) y pasando por la fase de elaboración técnica como
documento, hasta llegar a la fase de ejecución en la que el técnico que la dirija tendrá
también una labor de gran responsabilidad, e incluyendo las inversiones económicas,
que junto a lo anterior, permitirán obtener el rendimiento deseado.
3.- El proceso proyectual clásico o general.
Al definir la ingeniería nos hemos referido a una transformación óptima de recursos en
formas útiles para el hombre. Por ello, a través del proyecto de ingeniería, se trata de
pasar o evolucionar desde una situación actual, no deseada que denominaremos situa-
ción problema en la que existen ciertas necesidades insatisfechas, hasta otra situación
futura o situación objetivo, en la que dichas necesidades quedan resueltas.
Para que este proceso de desarrollo del proyecto de ingeniería tenga unos resultados
óptimos se debe seguir una serie de etapas ordenadas de forma lógica de tal manera
que, de una forma u otra respondan al esquema básico de la figura 1.
3.1.- Identificación del problema.
En esta fase se estudiará la necesidad objeto del proyecto y se analizarán las soluciones
posibles hasta llegar a seleccionar la más adecuada.
3.1.1.- Identificación de necesidades y establecimiento de objetivos.
En esta etapa se trata de identificar inequívocamente la necesidad que pretendemos
cubrir de entre las existentes en la sociedad y, por tanto, de definir el objetivo a alcanzar
con el desarrollo del proyecto de ingeniería para, a continuación, poner de manifiesto las
alternativas o caminos mediante los cuales es posible conseguir el resultado deseado.
Se pretende conocer concretamente el objetivo que deseamos lograr con la realización
del proyecto. Habrá situaciones en las que el objetivo sea identificado por el cliente que
encarga el proyecto, pero en otras muchas ocasiones esto no ocurrirá así y el ingeniero
deberá determinar por sí mismo el objetivo.

-5-
NECESIDAD
ELABORACIÓN
DE PROPUESTAS
EVALUACIÓN
DE PROPUESTAS
SATISFACCIÓN
DE NECESIDADES
EJECUCIÓN
CONFECCIÓN
DEL PROYECTO
Figura 1. El proceso de proyecto.
En la mayoría de los casos el desarrollo de proyectos software tropieza con graves in-
convenientes derivados de la incorrecta formulación de objetivos lo que, generalmente,
se debe a falta de comunicación real entre el cliente y el equipo de desarrollo de soft-
ware. Además existe un conjunto de “verdades” atribuidas al software que dificultan
enormemente el establecimiento de los objetivos y que son :
Enunciar someramente las necesidades es suficiente para comenzar a es-
cribir el código: esta es la causa más común de proyectos software que no sa-
tisfacen la necesidad inicial. En muchos casos el cliente conoce su problema :
debe acortar tiempos, organizarse mejor, calcular con más precisión, disponer de
bases de datos fácilmente actualizables... ; pero piensa que la solución a estos
problemas radica en el desarrollo de un nuevo programa para su empresa y así
lo encarga al técnico correspondiente. Si éste se prepara para escribir el progra-
ma inmediatamente habrá incurrido en el mismo error que su cliente : confundir
los deseos con las necesidades. En efecto, el cliente suele sobrevalorar las ex-
pectativas que tiene de la informática y siempre pensará que con un nuevo pro-

-6-
grama todo iría mejor. El primer paso del proyecto estriba precisamente en dife-
renciar claramente la necesidad real, por lo que se requiere una intensa comuni-
cación entre técnico y cliente sobre el tipo de información que se maneja en su
empresa, la función que se le da a la misma, rendimiento actual del sistema, crite-
rios de evaluación, etc... Sólo después de adquirir toda esta información estare-
mos en condiciones de determinar qué necesita realmente el cliente : puede que
necesite un programa nuevo, pero puede que su problema se resuelva utilizando
algoritmos más potentes, mejorando las comunicaciones internas, gestionando
mejor los datos o sólo trabajando de otra forma, puntos que, entre otros muchos,
será necesario considerar antes de empezar a trabajar.
La definición del problema puede cambiarse de forma dinámica a medida
que se desarrolla el software, ya que éste es flexible y se adapta con facili-
dad : superada la fase anterior debe ponerse especial cuidado en que no haya
modificaciones imprevistas ya que, una vez establecidos los recursos, interfaces
y funciones a utilizar, los cambios en la definición del problema suelen obligar a
comenzar de nuevo desde el principio. Evidentemente, cuanto más avanzada
esté la fase de implementación (codificación y prueba) mayor será el coste deri-
vado de los cambios, hasta tal punto que, en la fase final, suele ser más barato
comenzar de cero que introducir modificaciones en el código.
El proceso anterior debe concretarse en dos vertientes : identificación del problema real
(el problema del cliente) y el problema técnico (la manera de dar satisfacción a las nece-
sidades). Así, la formulación del problema técnico pasa por responder a una serie de
preguntas, como por ejemplo : ¿existe la tecnología necesaria para resolver el problema,
cuál es ? ¿qué recursos se requerirán para dar solución al problema ? ¿cuáles son las
limitaciones de tiempo y de dinero ? En aquellos casos en que se desarrolle un producto
para venderlo a muchos clientes potenciales habrá que añadir los siguientes interro-
gantes : ¿cuál es el mercado potencial del producto ? ¿qué ventajas tiene frente a la
competencia ? ¿qué lugar ocupa el producto dentro de la línea general de la compañía o
empresa ? La respuesta a este segundo grupo de preguntas suele escapar a la forma-
ción normal del técnico proyectista, por lo que habrá que solicitar la colaboración de ga-
binetes especializados o, en su defecto, recurrir a la realización de un estudio personal
más modesto basado en estadísticas regionales, nacionales o internacionales.
3.1.1.1.- Identificación del problema real.
Para definir correctamente el problema real es necesario realizar un trabajo entre dos
grupos diferentes de personas:

-7-
a) La empresa “cliente” que “formulará” el problema del proyecto (falta de efica-
cia en algunas operaciones, necesidad de modernización, disminuir costes de
gestión...).
b) La empresa de ingeniería, que convertirá la formulación de la necesidad del
cliente en una “definición” del problema que pueda ser abordada desde el punto
de vista técnico.
Evidentemente, al tratarse de un trabajo en equipo, la empresa de ingeniería incidirá
sobre la “formulación“ del problema realizada por el cliente corrigiéndola o aportando
ideas que escapan a aquel dada su distinta especialización. Igualmente, el cliente dará
sus ideas sobre la definición hecha por el equipo técnico aportando su experiencia en el
campo específico de que se trate.
Para que exista una colaboración eficaz entre ambas partes que dé lugar a una identifi-
cación precisa del problema es necesario preparar correctamente las entrevistas o reu-
niones de trabajo de tal manera que se ahorre tiempo y se obtengan conclusiones con-
cretas, llegando a definirse cuestiones como:
− Periodo esperado de uso del proyecto.
− Tipo de usuarios del proyecto.
− Medios disponibles en la empresa (redes, equipos, periféricos,...).
− Plazo de ejecución necesario.
− Posibilidad de descomponer en subproblemas.
− Requisitos “impuestos” por el cliente.
− Normativa de aplicación.
La preparación de la entrevista debe consistir en la elaboración de un guión o lista de
cuestiones en los que se trate de poner de manifiesto las inquietudes del cliente y todos
los puntos anejos o ramificaciones que puedan ser de interés, tales como personal dis-
ponible, espacio, limitaciones económicas, etc. Por otro lado no es conveniente tomar el
esquema previo como una pauta rígida a seguir, sino más bien como una guía que nos
permita ir abordando los temas a tratar con un orden lógico, sin impedir al cliente que
vaya expresando sus inquietudes, pero procurando no apartarnos demasiado de la línea
de información deseada. Asimismo, el paso de recogida de información con el cliente no
suele hacerse en una sola sesión, sino que es más usual ir avanzando poco a poco en el
nivel de detalle realizando entrevistas sucesivas. Lógicamente, es de utilidad que, con-
forme se vayan sucediendo las reuniones de definición del problema, vaya interviniendo
cada vez personal más especializado de cada una de las partes.

-8-
Un ejemplo de guión para una entrevista de toma de contacto podría ser:
1) Tipo de trabajo que se solicita: estudio, informe, anteproyecto o proyecto.
2) Formulación del problema con las palabras y desde el punto de vista del pro-
yectista.
3) Antecedentes: ¿se han realizado estudios previos sobre el tema? ¿estudios
de viabilidad? ¿estudios de mercado?
4) Plazos de entrega esperados.
5) Presentación del proyectista: exposición de trabajos realizados con anteriori-
dad, colaboradores, medios disponibles, etc...
6) Cuantificación del problema: estimar los recursos humanos a utilizar, fases
principales de realización del proyecto, costes del trabajo, información necesa-
ria para continuar.
Como resultado de la primera entrevista se prepara un informe con:
1) Contenido del proyecto.
2) Plazo propuesto.
3) Coste aproximado del proyecto.
4) Borrador del contrato u hoja de encargo.
3.1.1.2.- Identificación del problema técnico.
A continuación, el equipo de desarrollo tendrá que establecer todos los condicionantes
del problema, para lo que existe una técnica de ingeniería denominada PDS (Product
Design Specification) que consiste en dar respuesta a una lista de preguntas básicas:
1) Funcionamiento: debe describirse con detalle lo que el cliente espera del
producto, pero de forma técnica. Así, describir el funcionamiento del producto
será traducir a lenguaje técnico el problema enunciado por el cliente. Siempre
que sea posible, la descripción del funcionamiento debe hacerse de forma
simple, utilizando para cada función o acción un verbo y un nombre (por ejem-
plo: leer datos, utilizar el algoritmo, presentar en pantalla, guardar resultados,
imprimir resultados, ...). Por otro lado la descripción del funcionamiento de que
lo se diseña debe ser lo más simple posible y debe evitarse incluir en la lista
de funciones del producto aquellas que son “deseables” para el diseñador pe-
ro que no intervienen directamente o son accesorias, ya que con ello se au-
menta innecesariamente el coste y, generalmente, disminuye la fiabilidad del
producto conseguido.

-9-
2) Entorno: el siguiente elemento a especificar es el entorno, pero este con-
cepto hay que entenderlo en sentido amplio, es decir: el entorno de programa-
ción que se va a usar, o el interfaz de usuario, pero también hay que especifi-
car qué personas van a utilizar el producto que se diseña, su preparación, en
qué condiciones va a ser utilizado, incluyendo los ruidos, las vibraciones, tem-
peratura y humedad del ambiente, etc... Aspectos que, en general, condiciona-
rán no sólo el software que se diseña sino también el hardware necesario pa-
ra ejecutarlo.
3) Vida esperada: ningún producto es eterno, ya que constantemente aparecen
técnicas que ayudan a mejorar el diseño. Con respecto al software, esta ase-
veración se hace más evidente que con respecto a los productos industriales.
Por ello, es necesario definir cual va a ser la vida útil del producto, ya que en
algunos casos puede no merecer la pena realizar un gran esfuerzo en la fase
de diseño para un producto que va a ser sustituido en breve.
4) Ciclo de mantenimiento: el software que se entregue al cliente, ¿será defi-
nitivo, o sufrirá actualizaciones a lo largo del tiempo? En el caso de que sea
necesario ir actualizando el producto, hay que definir la periodicidad y el cos-
te, ya que estos datos influirán decisivamente sobre la calidad del producto y
sobre la imagen que el cliente forme de él.
5) Competencia: si existe en el mercado otro producto que puede realizar las
mismas tareas que se demandan del proyecto, será necesario conocer a fon-
do cuales son sus ventajas e inconvenientes, de tal manera que nunca se
ofrezca al cliente algo que sea peor que lo ya existente.
6) Aspecto externo: lo primero que ve el cliente es el aspecto externo del pro-
ducto, y después evalúa su funcionamiento. Respecto al software, el aspecto
externo radica, no sólo en que el interfaz sea “amigable” y de manejo intuitivo
y ergonómico, sino que también es necesario considerar aspectos como la
presentación (discos, CD-ROM, ...), el diseño de la carátula y del envoltorio, el
manual de usuario, que debe ser atractivo, fácilmente inteligible y no debe ne-
cesitar del apoyo de ninguna documentación adicional, etc.
7) Estandarización: el uso de diseños estándar facilita el trabajo, de tal manera
que debe utilizarse siempre que sea posible lo que ya está estipulado, como
por ejemplo bibliotecas de funciones matemáticas, protocolos de comunica-
ciones, combinaciones de colores, menús desplegables, tipos de ficheros...

-10-
8) Calidad y fiabilidad: el aseguramiento de la calidad es un campo que va to-
mando cada vez más importancia. Desde el punto de vista del diseñador del
software debe identificarse cuales son los puntos o elementos de riesgo, con
más probabilidad de fallo, e intentar minimizar esta probabilidad con un diseño
adecuado.
9) Programa de tareas: ningún plan de diseño estará completo sin que exista
un programa detallado de su realización a lo largo del tiempo, de tal manera
que se determine el plazo disponible para la ejecución de cada parte del pro-
yecto, los recursos (humanos y materiales) que se emplearán, y el coste apro-
ximado. El equipo de diseño debe conocer esta planificación y los plazos de
que dispone, pero no es eficaz a largo plazo dar a conocer la programación en
todos sus detalles ya que la tendencia del personal es la de agotar al máximo
los plazos disponibles.
10) Pruebas: otra de las especificaciones importantes a la hora de diseñar es la
de determinar qué partes del diseño serán sometidas a pruebas, en qué
momento, cuáles son las pruebas y cuáles son los resultados mínimos espe-
rados para que pueda darse por bueno el diseño. Asimismo, es importante
especificar si el usuario final va a tomar parte en las pruebas o no.
11) Seguridad: La seguridad consiste en especificar qué tratamiento se dará a
los datos propios del usuario y también la seguridad contra copias no permi-
tidas.
3.1.2.- Identificación de los factores limitativos.
Llegado este punto el ingeniero deberá haber identificado correctamente el problema
real y el problema técnico y debe prepararse para resolver éste último de forma óptima.
Comienza ahora la fase de toma de datos desde el punto de vista técnico. Una relación
de datos a recopilar en esta fase podría ser :
¿Qué tecnologías se requieren para conseguir la funcionalidad y el correcto
rendimiento del sistema ?
¿Qué es necesario desarrollar por completo : algoritmos, métodos o procesos ;
y cuál es la probabilidad de realizarlo con éxito ?
¿En qué proporción afectará al coste total del sistema el desarrollo de la meto-
dología ?

-11-
A esta lista de preguntas puramente técnica hay que añadir otras sobre las limitaciones
del diseño que son impuestas por el exterior y que pueden ser de dos tipos :
Factores dato : son factores dato aquellos que no pueden ser modificados, co-
mo por ejemplo limitaciones de tiempo dadas por el plazo de entrega del proyec-
to, limitaciones presupuestarias del cliente, tecnología del hardware existente,
etc...
Factores estratégicos : son variables de diseño en las que habrá que elegir en-
tre dos o más posibilidades, dependiendo la solución final que se adopte de la
elección realizada. Por ejemplo ¿se desea que la solución generada pueda utili-
zarse en cualquier equipo, o es necesario disponer de unos requisitos mínimos ?
¿se utilizarán gráficos, o sólo pantallas de texto ? ¿qué tipo de sistema operativo
o entorno es más adecuado para este caso ?
3.2.- Elaboración de propuestas.
En este punto del proceso de proyecto habremos analizado las necesidades reales del
cliente, habremos identificado los problemas real y técnico y tendremos definidos los
factores dato y estratégicos. Se hace necesario, por lo tanto, pasar a buscar soluciones
que satisfagan la necesidad enunciada al mínimo coste posible.
Generalmente la solución a los problemas de ingeniería no es única, existiendo un aba-
nico de soluciones posibles que satisfacen en mayor o menor medida las restricciones
impuestas al problema. Asimismo, la elección de la solución más adecuada no suele ser
evidente ya que, si una solución satisface correctamente uno de los objetivos, puede
que no cumpla otros completamente. Para evitar los inconvenientes derivados de una
mala selección de soluciones, es necesario que el número de posibles alternativas de
diseño sea lo más grande posible y realizar una evaluación que contemple las solucio-
nes adoptadas desde varios aspectos, de tal manera que se tenga en cuenta, no sólo
que lo diseñado satisfaga las necesidades fundamentales del cliente, sino también la
economía, la ergonomía, la estética, la flexibilidad o adaptabilidad, la optimización en el
uso de los recursos, etc.
3.2.1.- Brainstorming.
El brainstorming (tormenta cerebral o tormenta de ideas) consiste en una reunión de
trabajo a cargo de un grupo de personas en número variable (7 a 12, aunque pueden ser
más) y que han de tener conocimientos en el tema de que se trata y conocer los condi-
cionantes específicos del problema de diseño. Durante cada sesión se expondrán ideas
para la posible resolución del problema estando prohibidas las críticas. Se obtiene así un

-12-
número relativamente grande de propuestas que serán evaluadas con posterioridad.
Para que la técnica del brainstorming tenga éxito, es necesario que haya un jefe, organi-
zador o moderador que prepare la reunión informando a los participantes del tema que
se va a tratar y de los criterios básicos a utilizar; asimismo tomará nota de las ideas ex-
puestas y las ordenará por afinidad entre ellas. Las propuestas así obtenidas serán
evaluadas por un equipo diferente de personas y se seleccionará las más acertadas.
La principal característica de esta técnica es la carencia de críticas, por lo que se libera
el subconsciente de los participantes y se da rienda suelta a la imaginación obteniéndo-
se gran cantidad de sugerencias.
Otro factor importante a la hora de profundizar en las soluciones es utilizar las ideas de
los demás, procurando mejorarlas o complementarlas, para ello puede ser interesante
que participen personas de distintas edades, profesiones y sexo. Por otro lado no tiene
sentido realizar una sesión de brainstorming para buscar ideas en un problema de solu-
ción única. El peligro principal de esta técnica es la divagación, ya que el estado mental
que se crea en los participantes favorece el desarrollo de las sugerencias más imaginati-
vas o fantásticas y un alejamiento del tema propuesto inicialmente, por lo que es misión
del organizador reconducir el tema tantas veces como estime preciso.
3.2.2.- Listas de preguntas y listas de objetivos.
Un método sencillo que permite aclarar ideas sobré qué y cómo diseñar, suele ser el de
las listas de preguntas y las listas de objetivos. En este método se pretende, partiendo
de una serie de preguntas estandarizadas sobre el diseño, profundizar en el conoci-
miento del problema y obtener conclusiones que puedan ser de aplicación directa a la
resolución de los mismos. A continuación se dan ejemplos de listas de preguntas y listas
de objetivos (tablas 1 y 2):
A la vista de las cuestiones generales que se enuncian en las tablas 1 y 2 resulta evi-
dente que en la mayoría de los casos no será posible cumplir con todos los requisitos al
mismo tiempo, ya que algunos se contradicen o se excluyen entre sí. Por otra parte, es
posible que en algunos casos algunas de las preguntas no puedan ser aplicadas ya que
excederán el ámbito normal de aplicación para la que han sido concebidas. Sin embargo
no debemos olvidar que en la fase de diseño del proyecto en que nos encontramos no
es aconsejable descartar de antemano ninguna posibilidad por lo que es recomendable
estudiar cada opción por separado para cada uno de los elementos que compondrán el
proyecto y trasladar las conclusiones al conjunto.

-13-
Tabla 1. Lista de preguntas en el proceso de diseño.
PREGUNTAS BÁSICAS PREGUNTAS SECUNDARIAS
¿OTROS USOS? ¿Nuevos usos para lo ya existente?, ¿nuevos usos de lo modificado?
¿ADAPTAR? ¿Qué podría copiar?, ¿a qué se parece?, ¿a quién o qué podría emular?
¿MODIFICAR? ¿Se podría buscar otra perspectiva?, ¿otro diseño?, ¿otro sistema?, ¿otro equipo?
¿AGRANDAR? ¿Aumentar el tamaño?, ¿la velocidad?, ¿los requerimientos?
¿DISMINUIR? ¿Qué se puede minimizar?
¿SUSTITUIR? ¿Qué se puede intercambiar?, ¿elementos?, ¿entornos?, ¿interfaces?, ¿personal?
¿INVERTIR? ¿Es necesario este orden de las cosas?, ¿se puede hacer al revés?
¿COMBINAR? ¿Enlazar partes distintas?, ¿utilizar restos de operaciones anteriores?
¿ORDENAR? ¿Qué se puede jerarquizar?, ¿qué se puede estructurar?
¿ELIMINAR? ¿Hay algo realmente innecesario?
¿SEPARAR? ¿Puede hacerse por partes?
¿EQUILIBRAR? ¿Cómo compensar los recursos?, ¿cómo repartir el personal?
¿IMPLEMENTAR? ¿Algoritmos?, ¿funciones?, ¿bases de datos?, ¿qué hay que hacer partiendo de cero?
Tabla 2. Lista de objetivos en el proceso de diseño.
OBJETIVOS APLICACIONES
DISMINUIR COSTES Mejorar la distribución, ahorrar tiempo, planificar, organizar los recursos
AHORRAR MATERIAL Economizar en el diseño, no imponer especificaciones innecesarias al hardware
USAR LOS SUBPRODUCTOS Reutilizar las partes diseñadas y desechadas en otros proyectos, reciclar material
HACERLO MÁS FIABLE Mejorar el sistema de pruebas, implantar un sistema de calidad
HACERLO MÁS MANEJABLE Mejorar el diseño para que su uso sea más intuitivo
HACERLO MÁS AGRADABLE Mejorar la presentación exterior del producto
HACERLO MÁS ERGONÓMICO Estudiar la relación diseño-trabajador y producto-usuario
HACERLO MÁS FLEXIBLE Adaptar los métodos de trabajo a la mayor cantidad de productos, utilizar las mis-
mas herramientas para otros diseños futuros
HACERLO MÁS FUNCIONAL Mejorar las prestaciones generales del producto
HACERLO MÁS COMPRENSIBLE Adjuntar manuales útiles y simples, ejemplos de utilización, instrucciones paso a
paso
NORMALIZARLO Utilizar material y procedimientos standard
3.2.3.- La sinéctica.
La sinéctica es un método de diseño en grupo en el que se explota la habilidad de las
personas para encontrar paralelismos o conexiones entre campos aparentemente muy
dispares. El grupo de sinéctica debe estar formado por un número no demasiado eleva-
do de personas (hasta 6), en el cual la mitad puede formar parte del equipo de diseño
del proyecto y la otra mitad pueden ser invitados del exterior, procurando siempre que
exista la mayor variedad posible de titulaciones y actividades profesionales. El método
de trabajo tiene algunas similitudes y diferencias con el brainstorming: el punto principal
de contacto es que debe trabajarse en un contexto en el que no existan las críticas, y la
diferencia estriba en que, si en el método del brainstorming se trabaja en busca del ma-
yor número de soluciones posible, en la sinéctica se persigue obtener una única solución
viable.

-14-
La práctica demuestra que la sinéctica funciona bien en la resolución de problemas rea-
les en los que existe una alta probabilidad de que las soluciones puedan llevarse a la
práctica, como por ejemplo en aquellos casos en los que se desee buscar nuevas solu-
ciones mejores y más eficaces a problemas que ya hayan recibido alguna solución con
anterioridad. Sin embargo, cuando el problema es completamente nuevo y es necesario
dar soluciones o adoptar la mejor de un abanico propuesto anteriormente, este método
no da buenos resultados.
Los cuatro tipos de analogías utilizados son:
1) Analogía directa: en la que se asimila el problema a algo existente en la rea-
lidad.
2) Analogía personal: el diseñador se imagina a sí mismo haciendo las veces u
ocupando el lugar de lo que diseña, de tal manera que toma una consciencia
más eficaz del problema.
3) Analogía simbólica: se realiza una comparación metafórica en la que lo que
se diseña se asimila a la totalidad o a parte de algo conocido: árbol de deci-
sión, boca de un río...
4) Analogía fantástica: este es el tipo más libre en el que el diseñador deja
completa libertad a su imaginación y el problema se asemeja a objetos inexis-
tentes.
La sesión de sinéctica comienza con una exposición del problema por parte del director o
moderador de la misma de forma que, inicialmente, procure exponer las soluciones pre-
viamente existentes o triviales para que sean evitadas desde el principio por los partici-
pantes. Además, debe sugerir alguna línea principal dentro de los tipos de analogías
mencionadas ya que, como puede suponerse, es relativamente frecuente la divagación.
En el caso de que las comparaciones que vayan realizando los participantes se alejen
demasiado del problema inicial o sean demasiado fantásticas, debe procurar reconducir
la discusión volviendo a resumir los objetivos que se persiguen. Si por el contrario apa-
recen comparaciones que tengan visos de poder convertirse en nuevas soluciones del
problema, se profundizará en ellas hasta tener un prediseño.
3.2.4.- Ideas combinativas.
El método de las ideas combinativas (o combinadas) es de utilidad en aquellos casos en
los que existen sólo unas cuantas formas posibles de dar solución a un problema en

-15-
cada uno de sus aspectos simples, de tal manera que estas opciones puedan ser com-
binadas, y cada combinación evaluada, con facilidad. Supongamos un problema de di-
seño en el que hay que decidir sobre dos aspectos y cada uno de ellos sólo tiene dos
opciones posibles. Así, el primer aspecto puede tomar la solución A o la a, y el segundo
la B o la b. Evidentemente, el espectro de posibles soluciones al problema general es
AB, Ab, aB y ab.
A continuación se piensa en posibles ventajas que es de esperar que tenga la solución
definitiva, como por ejemplo, transportabilidad, ergonomía, facilidad de manejo o estética
y se oponen a las cuatro soluciones en una tabla, marcando con una X aquella solución
que presente una determinada ventaja (tabla 3).
Tabla 3. Tabla de selección de ideas combinativas.
AB Ab aB ab
Transportabilidad X X
Ergonomía X X
Facilidad de manejo X
Estética X X X
En este caso resulta evidente a primera vista que la solución a elegir es la AB siempre y
cuando el proyectista dé la misma importancia a todas las características o ventajas del
problema.
3.2.5.- Normas generales de diseño.
A continuación se dan unas normas básicas a seguir en la búsqueda de soluciones sea
cual sea el método empleado.
1) Evitar decisiones arbitrarias: siempre que se diseña algo nuevo hay que
hacer frente a una serie de decisiones o elecciones. Tomar algunas de ellas
como rutinarias o triviales puede hacernos perder la oportunidad de mejorar el
diseño obteniendo algo verdaderamente útil y original.
2) Buscar más alternativas: quedarse con la primera idea no suele ser sufi-
ciente y siempre será mejor tener varias opciones para comparar.
3) Construir prototipos: una vez que se haya diseñado una parte con suficiente
entidad como para que pueda ser llevada a la práctica, puede ponerse a
punto en una versión reducida que permita estudiar su funcionamiento. A me-
nudo, al ver un modelo pueden aflorar nuevas ideas que habían sido pasadas
por alto.

-16-
4) Incrementar al máximo el grado de abstracción en la formulación del
problema: cuando el problema se define con gran detalle por parte del cliente
o del técnico es posible que en la misma definición esté enmascarada una
solución parcial que concuerda con los deseos del cliente o del diseñador. Por
ejemplo es posible definir un problema de proyecto como “diseñar una silla”
cuando el problema es “diseñar un artefacto para sentarse” lo que, evidente-
mente, no tiene por qué ser una silla ni parecerse a una silla.
5) Hacer esquemas, tablas y dibujos: no siempre es posible abstraerlo todo.
Poner las ideas en papel ayuda a comparar, decidir y mejorar.
6) Llevar siempre el problema hasta sus límites: las limitaciones impuestas
al problema por condicionantes económicos o de tiempo ya son suficientes.
No debe empobrecerse el resultado sólo por no haber explorado todas las ví-
as posibles de solución.
7) Cumplir las funciones especificadas: una vez realizada la PDS, hay que
ajustarse lo más posible a ella, de tal manera que si se encuentran dificultades
en el cumplimiento de alguna función siempre es mejor desechar un diseño y
empezar de nuevo que dejar especificaciones sin lograr.
8) Explotar al máximo los métodos y herramientas a nuestro alcance: a
menudo, el técnico se acostumbra a utilizar siempre los mismos criterios y las
mismas herramientas, lo que en la mayoría de los casos, va en contra de la
búsqueda del mejor diseño.
9) Realizar un desarrollo lógico del proceso de diseño: empezar por lo ge-
neral y terminar por lo particular. Suele ser de utilidad realizar una justificación
detallada de cada una de las decisiones de diseño que se tomen, de tal mane-
ra que pueda observarse una ilación lógica de unas a otras.
10) Hacerse preguntas: el diseñador debe adoptar una actitud de incredulidad
respecto a la bondad de lo que diseña, de tal manera que constantemente se
esté preguntando: ¿es necesaria esta parte? ¿cómo puede fallar esto? ¿por
qué lo estamos haciendo así?
3.3.- Evaluación de las propuestas alternativas.
Una vez logrado un abanico de posibles soluciones utilizando los métodos de diseño
mencionados anteriormente, es necesario elegir la mejor de todas las alternativas pro-

-17-
puestas. Sin embargo no es fácil determinar qué opción es la más adecuada en cada
caso ya que suelen existir criterios de valoración a menudo contrapuestos: quizá la solu-
ción económicamente más aceptable no es la mejor desde el punto de vista técnico o
viceversa, sin olvidar otros elementos de valoración tales como la estética o la imagen
externa, condicionantes legales o de cualquier otra índole que puedan ser de aplicación.
Por otra parte, la solución que satisfaga de forma óptima uno de los criterios quizá ni
siquiera alcance un mínimo en alguno de los demás, por lo que es necesario renunciar a
la perfección en aras de conjuntar todos los criterios en una solución de compromiso.
El proceso básico a seguir en la comparación técnico-económica de soluciones consiste
en identificar en primer lugar el coste de desarrollo del prototipo en contraposición con
los beneficios que se espera obtener (inputs y outputs); establecer cuales van ser los
criterios o índices de decisión, tales como índices económicos, técnicos o combinación
de ambos y, por último tener en cuenta la incertidumbre o riesgo que se corre al realizar
el estudio basándose en estimaciones a priori, por lo que habrá que considerar también
este aspecto utilizando un estudio de probabilidades o, al menos, un abanico de estima-
ciones optimistas y pesimistas.
Así, se hace necesario contar con herramientas de valoración que pongan de manifiesto
las virtudes y defectos de las soluciones para llegar a decidir cuál se adapta mejor al
problema. A continuación se exponen las técnicas más usuales.
3.3.1.- Jerarquización de las soluciones.
El proceso de selección de soluciones es el siguiente. Supongamos que para un deter-
minado proyecto se ha llegado a seis soluciones posibles (A, B, C, D, E, y F), el primer
paso consiste en determinar cuáles son los criterios de valoración (economía, estética,
facilidad de expansión o modificación, cumplimiento de los objetivos técnicos, etc...) y
ordenarlos de mayor a menor importancia. El segundo paso consiste en construir una
tabla en la que se asigna una puntuación a cada solución para cada uno de los criterios,
por ejemplo de 0 a 10, y se fija una puntuación mínima para que una solución pueda
considerarse aceptable. En este caso se va a tomar la puntuación mínima de 5 (tabla 4).
El tercer paso consiste en realizar filtros sucesivos de la siguiente manera: el criterio más
importante (el 1) no es cumplido por la solución C, que sin embargo alcanza correcta-
mente los demás, pero debido a que este criterio es el más importante, esta solución se
elimina del estudio. A continuación se pasa al segundo criterio, que es cumplido por to-
das las soluciones restantes, por lo que, tomando el tercer criterio se elimina la solución
B. En el cuarto paso desaparece la A, por lo que definitivamente quedan las soluciones
D, E y F como aceptables, pero para decidir entre ellas habría que adoptar criterios
complementarios o elegir otro método de valoración, por lo que el método de jerarquiza-
ción puede tomarse como una primera aproximación para eliminar las peores soluciones.

-18-
Tabla 4. Clasificación por jerarquización.
A B C D E F
1 10 9 4 8 10 9
2 7 8 5 7 5 7
3 6 3 10 6 8 6
4 4 4 9 9 9 5
5 7 8 7 5 6 5
3.3.2.- Método del valor técnico ponderado (VTP).
El método VTP es algo más difícil de aplicar que el de jerarquización, pero también es
más fiable que aquel. El éxito en la valoración adecuada de las soluciones depende de
la experiencia previa de quien lo aplique ya que, de carecer de ella, resulta fácil caer en
la subjetividad. Para aplicar el método se construye una tabla similar a la anterior (tabla
5), pero los criterios no se jerarquizan, sino que se les asigna un peso o importancia
relativa gi. Igual que en el método de jerarquización, se puntúan o califican las solucio-
nes de 0 a 10 (pi) para cada criterio y se multiplican las puntuaciones por los pesos. La
solución elegida será aquella en la que el Valor Técnico Ponderado (puntuación total
dividida por la puntuación máxima posible) sea la más alta.
Evidentemente la solución más indicada para este proyecto es la C, ya que es la que se
adapta mejor al conjunto de criterios de valoración elegido. Salta a la vista que el éxito
del método gravita sobre la correcta elección de los criterios de valoración y de los pe-
sos relativos de los mismos, así existe un conjunto de tablas de valoración prediseñadas
que pueden servir de utilidad. En la tabla 6 se da una lista completa de criterios de valo-
ración de soluciones para un nuevo diseño, en ella se ha asignado un peso estándar a
cada criterio de valoración, con lo que se obtienen buenos resultados en la práctica.
Tabla 5. Valor técnico ponderado (VTP).
Criterios Peso A B C D E
g p pxg p pxg p pxg p pxg p pxg
1 8 3 24 5 40 7 56 5 40 3 24
2 6 5 30 5 30 9 54 8 48 9 54
3 9 7 63 3 27 4 36 4 36 2 18
4 4 5 20 8 32 6 24 5 20 5 20
5 2 8 16 6 12 2 4 2 4 6 12
6 5 9 45 7 35 6 30 7 35 3 15
Suma 34 198 176 204 183 143
VTP 0.582 0.517 0.6 0.538 0.42

-19-
Tabla 6. Lista de valoración de soluciones para nuevos diseños.
CRITERIO VALORACIÓN P1
G PXG
1.- UTILIDAD
a) Utilidad alta
b) Utilidad media
c) Utilidad baja
5
3
1
5 K1
2.- FUNCIONALIDAD
a) Aspectos funcionales bien estudiados
b) Aspectos funcionales correctos
c) Aspectos funcionales poco importantes
5
3
1
10 K2
3.- ORIGINALIDAD
a) El producto es completamente innovador
b) Existen algunos productos parecidos en el mercado
c) Existen muchos productos similares
5
3
1
10 K3
4.- PRECIO
a) El precio será muy asequible
b) Se estima un precio semejante al de los productos existentes
c) El precio será superior al medio del mercado
5
3
1
5 K4
5.- EMPRESA
a) El producto es innovador dentro de la empresa
b) El producto mejorará los diseñados previamente en la empresa
c) El producto está dentro de la línea de la empresa
5
3
1
7 K5
6.- MODULARIDAD
a) Se contempla la modularización y estandarización
b) Se estudiará más adelante
c) No se contempla
5
3
1
5 K6
7.- ESTÉTICA
a) Se considera un estudio de estilo en cuanto a colores, tipos de
letra, etc..
b) Se tienen en cuenta someramente
c) No se considera
5
3
1
10 K7
8.- ERGONOMÍA
a) Se tiene en cuenta la ergonomía producto-usuario
b) Se considera someramente
c) No se considera
5
3
1
10 K8
9.- VIDA PREVISTA
a) La vida útil esperada se adapta a las necesidades del mercado
b) La vida útil excede a las necesidades del mercado
c) La vida útil prevista no alcanza las necesidades del mercado
5
3
1
5 K9
10.- TECNOLOGÍAS
a) Se utilizan nuevas técnicas de desarrollo
b) Se utilizan mejor las técnicas ya existentes
c) Se utilizan las técnicas existentes sin mejorarlas
5
3
1
5 K10
11.- PRESUPUESTO
a) La previsión presupuestaria es adecuada
b) El presupuesto real se desviará del previsto
c) El presupuesto de diseño es excesivo
5
3
1
10 K11
12.- FACTOR HUMANO
a) El equipo de diseño tiene prestigio y experiencia
b) No tiene prestigio pero tiene experiencia previa
c) No hay referencias o no son adecuadas
5
3
1
10 K12
13.- TAMAÑO DEL PROYECTO
RESPECTO A LA EMPRESA
a) El presupuesto del proyecto es aceptable para la empresa
b) Es asequible
c) Es excesivo para el tamaño de la empresa
5
3
1
10 K13
SUMA ΣKi
14.- INFORMACIÓN2
X
1
Es válido cualquier valor intermedio. Si un criterio no se valora por carecer de datos se puntuará con cero.
2
X es el número de respuestas no nulas.

-20-
La fórmula de valoración empírica contrastada por la práctica es la siguiente:
V=
Σki
4N
+ (N/10)2 -1 > 10
La valoración de las distintas soluciones en función del valor V obtenido se muestra en la
tabla 7.
Tabla 7. Valoración de las soluciones.
VALORACIÓN (V) CALIFICACIÓN
V>8.5 EXCELENTE
8.5>V>7.0 MUY BUENA
7.0>V>6.0 BUENA
6.0>V>5.0 NORMAL
5.0>V REGULAR
Además debe dejarse parte de la valoración a criterios puramente técnicos con un infor-
me complementario.
3.3.3.- Valoración económica.
El método propuesto anteriormente lleva implícita una cierta valoración económica de las
soluciones aportadas, sin embargo es posible llevar a cabo un estudio más profundo en
este aspecto aplicando alguna de las técnicas existentes, tanto de estimación de costes
como de obtención de índices de valoración, que escapan al contenido de este tema y
que serán tratados más adelante. En general, la evaluación económica parte de una
estimación del coste de desarrollo y de los beneficios que pueden obtenerse de la venta
del producto en años sucesivos, considerando los costes financieros y la inflación pre-
vista. Con ello se obtendrán unos índices de valoración que representarán la rentabili-
dad esperada del proyecto.
4.- El ciclo de vida del proyecto software.
Hasta el momento se ha tratado de los métodos generales de diseño en ingeniería de
proyectos, sin embargo existe una metodología particular aplicable a los proyectos de
software que, si bien se corresponde con los métodos tradicionales, contempla las pecu-
liaridades de este tipo de proyectos. El ciclo de vida del proyecto software no es más
que llamar por otro nombre a lo que hemos definido como el ciclo de vida del proyecto o

-21-
proceso proyectual y se refleja en varios paradigmas o métodos prácticos de aplicarlo: el
ciclo de vida clásico, la construcción de prototipos, y los modelos en espiral.
4.1.- El ciclo de vida clásico.
El ciclo de vida clásico contempla el estudio general del proyecto partiendo del estable-
cimiento e identificación de objetivos hasta llegar a la prueba y mantenimiento del soft-
ware desarrollado. Los pasos a seguir en el proceso de proyecto son: ingeniería del
sistema, análisis, diseño, codificación, prueba y mantenimiento. Este enfoque es se-
cuencial, por lo que este sistema se denomina también modelo en cascada y responde
al esquema de la figura 2.
Ingeniería del sistema: cuando se diseña software, éste no debe analizarse
aislada e individualmente, sino formando parte de un sistema mayor que puede
llamarse empresa, personas, datos, o hardware. Evidentemente es necesario
identificar cuál debe ser el papel del software dentro de un sistema y estudiar
las relaciones que debe tener con lo demás componentes, por lo tanto el primer
análisis a realizar será a nivel de sistema global, interrelacionando lo que se
pretende diseñar con todas las partes implicadas.
Ingeniería del
sistema
Análisis
Diseño
Codificación
Prueba
Mantenimiento
Figura 2. El ciclo de vida clásico.

-22-
Análisis de requisitos: una vez identificado el sistema en su totalidad, pasa-
remos a realizar el análisis de requisitos, que representa el segundo escalón en
el proceso del proyecto. Concretamente deben identificarse aquí las funciones
que deberá realizar el software, el rendimiento esperado y los interfaces nece-
sarios. Los requisitos deben ser revisados con el cliente o usuario antes de ser
dados por válidos.
Diseño: el diseño del software no se refiere a la realización o codificación del
programa, sino a la determinación de sus características formales generales,
tales como la estructura de los datos, la arquitectura y la caracterización del in-
terfaz. Así, una vez diseñado el software, debe asegurarse que este diseño
cumple con todos los requisitos de calidad exigidos en el punto anterior.
Codificación: consiste en traducir el diseño realizado a lenguaje inteligible por
la máquina. Este paso debe ser mecánico, ya que los problemas generales de
diseño han sido resueltos con antelación.
Prueba: es el último paso de la codificación, en el que se comprueba la sintaxis
correcta de las sentencias y el buen funcionamiento de las funciones, de tal
manera que todas las entradas posibles generen las salidas deseadas.
Mantenimiento: una vez entregado al cliente, el software puede sufrir modifi-
caciones debidas a falta de adaptación real a las necesidades, variaciones del
entorno tales como nuevas exigencias de rendimiento, o utilización de nuevos
periféricos. En la fase de mantenimiento habrá que aplicar de nuevo cada uno
de los pasos del ciclo de vida general, pero con el diseño ya existente en lugar
de con un diseño nuevo.
Antes de continuar es necesario establecer un paralelismo entre el proceso general de
proyecto y lo que hemos llamado el ciclo de vida clásico: el establecimiento de necesi-
dades se corresponde con la ingeniería del sistema, en esta fase se realizan las entre-
vistas oportunas para llegar a definir correctamente los objetivos, tanto desde el punto
de vista del cliente como desde el del técnico, terminando con una memoria resumen de
necesidades. El análisis de requisitos, si bien es misión del equipo técnico que vaya a
desarrollar el software, no debe excluir la relación con el cliente, por lo que es de utilidad
realizar aquí una segunda tanda de entrevistas más complejas, en las que intervenga
también personal técnico o usuarios directos de la empresa cliente, por lo tanto esta fase
estaría englobada dentro del establecimiento general de necesidades del proceso pro-
yectual. Las dos siguientes fases del proceso general se corresponden con la fase de
diseño del ciclo de vida clásico y en ellas deben aplicarse las técnicas de elaboración de
propuestas y evaluación de soluciones que se vieron en los apartados correspondientes.

-23-
Es necesario prestar gran atención en esta fase, ya que los errores que se detecten aquí
serán mucho más fáciles y económicos de solucionar que los que aparezcan en fases
posteriores, por otro lado iniciar la codificación sin realizar un diseño detallado de las
estructuras de datos, arquitectura y diseño procedimental, es justamente lo contrario de
lo que debe hacerse y sería como pedir a un arquitecto que construya una casa sin ha-
ber estudiado antes el terreno, los materiales y las normas de urbanismo, por ejemplo.
Por otro lado, tal como se ha especificado en los procedimientos de diseño, al quedarse
con una única solución en alguna de las etapas de diseño sin haber comparado las po-
sibilidades que ofrece cada una de las alternativas, se corre el riesgo de optar por solu-
ciones no adecuadas al problema en cuestión. Las fases de confección del proyecto y
ejecución son equivalentes a la de codificación, aunque la primera de ellas se corres-
ponde más con una redacción de la documentación del proyecto y la segunda tiene
parte en común con la fase de prueba, ya que tanto la codificación como las pruebas
forman parte de la ejecución formal del proyecto.
Por último, la evaluación del grado de satisfacción de las necesidades del cliente logrado
con el proyecto realizado pertenece tanto a las pruebas del software como al manteni-
miento del mismo una vez instalado. Evidentemente, tanto en el proceso general del pro-
yecto como en el ciclo de vida clásico del software, el ciclo es cerrado, lo que significa
que en cualquier momento del proceso es posible volver a replantear un estudio de ne-
cesidades, o una nueva elaboración de propuestas, aunque esto no es deseable y debe
evitarse por medio de la aplicación lo más detallada posible de las técnicas del diseño.
El ciclo de vida clásico es un método muy utilizado, sin embargo presenta ciertas dificul-
tades en su aplicación:
1. Es difícil realizar un seguimiento secuencial de los pasos del proceso de de-
sarrollo de proyectos reales, ya que todas las fases interaccionan entre sí.
Por lo tanto, la vuelta atrás mencionada anteriormente está casi asegurada,
no tanto porque existan errores en el proceso como por la dificultad de defi-
nirlo todo desde el primer momento con el suficiente nivel de profundidad.
2. Se necesita que el cliente especifique todos los requisitos, existiendo fuertes
penalizaciones de tiempo y dinero en el proceso de diseño si aparecen nue-
vos requisitos con el proceso avanzado.
3. Hasta las últimas fases del proceso no existirá una versión del programa ca-
paz de ser utilizado, de tal manera que los posibles errores de diseño o de
definición de requisitos tienen consecuencias graves cuando se realizan las
pruebas.

-24-
Ingeniería del
sistema
Análisis y
Diseño
Codificación
Prueba
Mantenimiento
ELABORACIÓN
DE PROPUESTAS
EVALUACIÓN
DE PROPUESTAS
SATISFACCIÓN
DE NECESIDADES
EJECUCIÓN
CONFECCIÓN
DEL PROYECTO
Figura 3. Correspondencia entre el proceso general del proyecto y el
ciclo de vida clásico.
En cualquier caso el método es interesante como guía en el proceso de diseño ya que
responde a una metodología racional del estudio del proyecto.
4.2.- Construcción de prototipos.
Uno de los problemas fundamentales que presenta el ciclo de vida clásico es la necesi-
dad de que todo esté perfectamente definido desde el principio, pero es posible que el
cliente no pueda especificar qué interfaz, qué tipo de datos van a ser manejados o qué
periféricos se necesitan. En estos casos es más útil establecer un proceso iterativo en el

-25-
que análisis, diseño, codificación y prueba se realizan de forma interactiva y simultánea.
Para ello debe partirse de la construcción de un prototipo sobre el que establecer el pri-
mer paso del ciclo, este prototipo puede realizarse en papel, explicando cómo será ini-
cialmente el interfaz, con un programa que implemente parte de los requerimientos y
subrutinas o con un programa preexistente que debe ser mejorado para cumplir con
todos los requisitos. En la figura 4 se muestra el esquema general del proceso de cons-
trucción de prototipos.
Al igual que en el ciclo de vida clásico, debe comenzarse con la especificación de requi-
sitos por parte del cliente, a continuación el ingeniero del software realizará un diseño
rápido en el que se centrará en la entrada y salida de datos y, en general, en los aspec-
tos del software visibles para el usuario.
Definición
de Requisitos
Evaluación
con el Cliente
Diseño
Rápido
Construcción
del PrototipoRevisión
Producto
Final
Figura 4. Esquema general del método de construcción de prototipos.
Construido un prototipo, se pasará a evaluar éste con el usuario, que definirá nuevos
requisitos o redefinirá los anteriores.
Los problemas básicos que presenta el modelo de construcción de prototipos es que el
cliente a menudo “ve” programas funcionando que para el diseñador son sólo fases del
proceso ya que aún no han sido depurados, no se ha optimizado el uso de la memoria o
no se ha estructurado el manejo de los datos, de tal manera que el cliente solicita la en-

-26-
trega inmediata del software. Por otro lado es posible que el diseñador, por tratarse de
un prototipo, utilice herramientas o lenguajes de programación inadecuados con la inten-
ción de modificarlos con posterioridad, pero a lo largo del proceso, quizá influido por las
presiones del cliente, se dé por satisfecho aún a sabiendas de la falta de optimización.
La solución a estos problemas es relativamente fácil: establecer al principio un protocolo
de trabajo con el cliente en que se informe al mismo del método de generación de proto-
tipos y de que los primeros pasos sólo deben servir para la definición de los requisitos
de tal manera que el software definitivo es objeto de un proceso más largo.

Tema1 proyectos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Similar a Tema1 proyectos

Similar a Tema1 proyectos (20)

Más de Aleman007

Más de Aleman007 (6)

Tema1 proyectos