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ÓNDE PROPUESTAS

EVALUACIÓNDE PROPUESTAS

SATISFACCIÓNDE NECESIDADES

EJECUCIÓN

CONFECCIÓNDEL 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 medidaque 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 apaso

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 delproblema: 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.- UTILIDADa) Utilidad altab) Utilidad mediac) Utilidad baja

531

5 K1

2.- FUNCIONALIDADa) Aspectos funcionales bien estudiadosb) Aspectos funcionales correctosc) Aspectos funcionales poco importantes

531

10 K2

3.- ORIGINALIDADa) El producto es completamente innovadorb) Existen algunos productos parecidos en el mercadoc) Existen muchos productos similares

531

10 K3

4.- PRECIOa) El precio será muy asequibleb) Se estima un precio semejante al de los productos existentesc) El precio será superior al medio del mercado

531

5 K4

5.- EMPRESAa) El producto es innovador dentro de la empresab) El producto mejorará los diseñados previamente en la empresac) El producto está dentro de la línea de la empresa

531

7 K5

6.- MODULARIDADa) Se contempla la modularización y estandarizaciónb) Se estudiará más adelantec) No se contempla

531

5 K6

7.- ESTÉTICAa) Se considera un estudio de estilo en cuanto a colores, tipos de

letra, etc..b) Se tienen en cuenta someramentec) No se considera

5

31

10 K7

8.- ERGONOMÍAa) Se tiene en cuenta la ergonomía producto-usuariob) Se considera someramentec) No se considera

531

10 K8

9.- VIDA PREVISTAa) La vida útil esperada se adapta a las necesidades del mercadob) La vida útil excede a las necesidades del mercadoc) La vida útil prevista no alcanza las necesidades del mercado

531

5 K9

10.- TECNOLOGÍASa) Se utilizan nuevas técnicas de desarrollob) Se utilizan mejor las técnicas ya existentesc) Se utilizan las técnicas existentes sin mejorarlas

531

5 K10

11.- PRESUPUESTOa) La previsión presupuestaria es adecuadab) El presupuesto real se desviará del previstoc) El presupuesto de diseño es excesivo

531

10 K11

12.- FACTOR HUMANOa) El equipo de diseño tiene prestigio y experienciab) No tiene prestigio pero tiene experiencia previac) No hay referencias o no son adecuadas

531

10 K12

13.- TAMAÑO DEL PROYECTORESPECTO A LA EMPRESA

a) El presupuesto del proyecto es aceptable para la empresab) Es asequiblec) Es excesivo para el tamaño de la empresa

531

10 K13

SUMA ΣKi

14.- INFORMACIÓN2 X1 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 delsistema

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 yDiseño

Codificación

Prueba

Mantenimiento

ELABORACIÓNDE PROPUESTAS

EVALUACIÓNDE PROPUESTAS

SATISFACCIÓNDE NECESIDADES

EJECUCIÓN

CONFECCIÓNDEL 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ónde Requisitos

Evaluacióncon el Cliente

DiseñoRápido

Construccióndel PrototipoRevisión

ProductoFinal

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.

Documents

Tema1 proyectos