LOS PROYECTOS DE INGENIERA

LOS PROYECTOS DE INGENIERA.

1.- Qu es la ingeniera ?
Segn el Diccionario de la Real Academia de la Lengua Espaola, ingeniera es el conjunto de conocimientos y tcnicas que permiten aplicar el saber cientfico a la utilizacin de la materia y de las fuentes de energa, mediante invenciones o construcciones tiles para el hombre. En esta definicin queda resaltada la necesidad de la utilidad de lo inventado o construido, de donde puede deducirse que en todo trabajo de ingeniera debe subyacer, de forma ltima, la persecucin de un fin social; pero no se expresa otro concepto muy importante en ingeniera y que es el aprovechamiento ptimo de recursos y el logro de fines econmicos. As, la definicin de la Real Academia puede ser reformada y completada con la que se apunta a continuacin: la ingeniera es una actividad profesional que usa el mtodo cientfico para transformar de una manera econmica y ptima, los recursos naturales en formas tiles para el hombre. Segn esta nueva definicin, un ingeniero necesita tener una amplia formacin cientfica y tcnica que le permita abordar, de la forma ms econmica posible y utilizando un mnimo de recursos, los problemas que la sociedad le plantee. Estos problemas tendrn que ser estudiados en sus tres vertientes : tcnica, econmica y humana, para que pueda decirse que las soluciones de ingeniera adoptadas son realmente aceptables. Desde el punto de vista de la Ingeniera del Software, una de las definiciones ms comnmente aceptadas es : el establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales.

-1-

LOS PROYECTOS DE INGENIERA

1.1.- Caractersticas diferenciadoras de la ingeniera del software respecto a la ingeniera tradicional.

Existe una serie de condicionantes especficos de la Ingeniera de Proyectos de Software respecto a la Ingeniera tradicional, donde se da por supuesto que, en la mayora de los casos, se pretende construir o ejecutar obras, instalaciones o mquinas que contribuirn a aumentar la rentabilidad econmica de las empresas o a solucionar problemas de manejo de materiales o de automatizacin de procesos. Respecto al software, ste no da lugar a entidades fsicas tangibles que hagan nada real en la mayora de los casos, excepto en aquellas circunstancias en que el software se utiliza para gobernar mquinas. As, puede decirse que la caracterstica diferenciadora del software que favorece su distincin respecto a la metodologa a utilizar en el diseo de proyectos es: El software se desarrolla, no se fabrica. En los conceptos clsicos de ingeniera se trataba de aplicar el conocimiento cientfico a la resolucin de problemas reales mediante el diseo y construccin de mquinas, instalaciones y edificios. Bajo este punto de vista el componente principal del coste del proyecto se ubica en la construccin o ejecucin propiamente dicha, mientras que el coste derivado del diseo puede aparecer como sustancialmente menor o incluso como insignificante. Es ms, la mayor parte del esfuerzo que se realiza en la etapa de diseo de proyectos de ingeniera clsica, estriba en evitar aumentos graves de coste en la etapa de ejecucin debidos a falta de previsin, malos clculos, defectos de funcionamiento, mala planificacin, etc. Por el contrario, en proyectos de desarrollo de software, la parte principal del coste gravita sobre la fase de diseo propiamente dicha ya que, una vez concluida la misma, el resto del proceso de desarrollo se reduce a la codificacin. Por todo ello, a la hora de realizar un proyecto de software lo ms importante es estructurar convenientemente el periodo de diseo o disear el diseo.

2.- El proyecto de ingeniera.

En su acepcin ms amplia, el trmino proyecto expresa la intencin o pensamiento de hacer algo para lo que se requerir, generalmente, la utilizacin y el consumo de medios. Surge aqu el concepto de proyecto como un plan para ejecutar algo que, desde el punto de vista de la ingeniera, se concretar en un estudio detallado tendente a resolver los problemas tcnicos, econmicos y humanos mencionados anteriormente. A esta acepcin del trmino proyecto la denominaremos abreviadamente Proyecto Idea.

-2-

LOS PROYECTOS DE INGENIERA

Siguiendo la definicin dada por el Diccionario de la Real Academia en su acepcin quinta, un proyecto es el conjunto de escritos, clculos y dibujos que se hacen para dar idea de cmo ha de ser y lo que ha de costar una obra de ingeniera. Lgicamente, una vez concebido un plan para resolver cualquier clase de problema, todo el estudio realizado, las soluciones de diseo adoptadas, las normas a seguir para llevarlas a cabo y su coste previsto deben recogerse en un documento. En el mismo sentido de esta acepcin existe en Espaa una definicin legal aprobada por el Decreto de la Presidencia del Gobierno 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. Evidentemente, y considerando la fecha en que aparece, esta definicin se refiere a la ejecucin de proyectos clsicos, si bien debe quedar apuntado el hecho de que el documento que refleje el proyecto debe ser lo suficientemente claro y detallado como para permitir a otra persona de la misma cualificacin que el autor, comprender los algoritmos que se utilizan, reproducir los programas generados, e instalarlos y mantenerlos adecuadamente. En consecuencia, a esta definicin del proyecto la llamaremos Proyecto Documento. Otra definicin en este sentido que complementa a la anterior en la idea de ordenamiento de la informacin es la siguiente : conjunto o serie de documentos que representan, de forma ordenada, toda la informacin necesaria para la realizacin de una obra o trabajo determinado. Una definicin de proyecto desde el punto de vista de la economa sera una actividad en la que se invertir dinero esperando obtener un rendimiento, y que desde el punto de vista lgico se presta a su planificacin, financiacin y ejecucin como un todo. Todas las definiciones anteriores se ajustan al concepto de proyecto, pero siempre de forma parcial en funcin del punto de vista adoptado, as, una definicin ms general puede conseguirse partiendo de la dada por el Diccionario de la Real Academia para el trmino PROYECTAR que dice : idear, trazar, disponer o proponer el plan y los medios de ejecucin de una cosa. Segn esta definicin se pueden proyectar cosas diversas tales como lneas elctricas, mquinas, centrales nucleares o software, ya que se utiliza el trmino en sentido amplio. Ahondando en la ltima definicin propuesta, proyecto es la combinacin de recursos humanos y no humanos, reunidos en una organizacin temporal para conseguir un propsito determinado. Se introduce as el concepto de uso de los recursos, lo que comprende un planeamiento muy general de lo proyectado que excede a la mera descripcin de aquello que se pretende realizar, incluyendo el tiempo que se ha de tardar, los me-

-3-

LOS PROYECTOS DE INGENIERA

dios a emplear, el modo de ejecutarlo y las previsiones sobre cunto costar y la rentabilidad econmica y social que se pretende obtener. Segn la ltima definicin, y compendiando todo lo anterior, el proyecto debe considerarse integralmente desde el momento en el que se concibe como respuesta a una problemtica humana (proyecto idea) y pasando por la fase de elaboracin tcnica como documento, hasta llegar a la fase de ejecucin en la que el tcnico que la dirija tendr tambin una labor de gran responsabilidad, e incluyendo las inversiones econmicas, que junto a lo anterior, permitirn obtener el rendimiento deseado.

3.- El proceso proyectual clsico o general.

Al definir la ingeniera nos hemos referido a una transformacin ptima de recursos en formas tiles para el hombre. Por ello, a travs del proyecto de ingeniera, se trata de pasar o evolucionar desde una situacin actual, no deseada que denominaremos situacin problema en la que existen ciertas necesidades insatisfechas, hasta otra situacin futura o situacin objetivo, en la que dichas necesidades quedan resueltas. Para que este proceso de desarrollo del proyecto de ingeniera tenga unos resultados ptimos se debe seguir una serie de etapas ordenadas de forma lgica de tal manera que, de una forma u otra respondan al esquema bsico de la figura 1.

3.1.- Identificacin del problema.

En esta fase se estudiar la necesidad objeto del proyecto y se analizarn las soluciones posibles hasta llegar a seleccionar la ms adecuada.

3.1.1.- Identificacin de necesidades y establecimiento de objetivos.

En esta etapa se trata de identificar inequvocamente 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 ingeniera para, a continuacin, 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 realizacin 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.

-4-

LOS PROYECTOS DE INGENIERA

NECESIDAD

SATISFACCIN DE NECESIDADES

ELABORACIN DE PROPUESTAS

EJECUCIN

EVALUACIN DE PROPUESTAS

CONFECCIN DEL PROYECTO

Figura 1. El proceso de proyecto. En la mayora de los casos el desarrollo de proyectos software tropieza con graves inconvenientes derivados de la incorrecta formulacin de objetivos lo que, generalmente, se debe a falta de comunicacin real entre el cliente y el equipo de desarrollo de software. Adems 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 escribir el cdigo: esta es la causa ms comn de proyectos software que no satisfacen la necesidad inicial. En muchos casos el cliente conoce su problema : debe acortar tiempos, organizarse mejor, calcular con ms precisin, disponer de bases de datos fcilmente actualizables... ; pero piensa que la solucin a estos problemas radica en el desarrollo de un nuevo programa para su empresa y as lo encarga al tcnico correspondiente. Si ste se prepara para escribir el programa inmediatamente habr incurrido en el mismo error que su cliente : confundir los deseos con las necesidades. En efecto, el cliente suele sobrevalorar las expectativas que tiene de la informtica y siempre pensar que con un nuevo pro-

-5-

LOS PROYECTOS DE INGENIERA

grama todo ira mejor. El primer paso del proyecto estriba precisamente en diferenciar claramente la necesidad real, por lo que se requiere una intensa comunicacin entre tcnico y cliente sobre el tipo de informacin que se maneja en su empresa, la funcin que se le da a la misma, rendimiento actual del sistema, criterios de evaluacin, etc... Slo despus de adquirir toda esta informacin estaremos en condiciones de determinar qu necesita realmente el cliente : puede que necesite un programa nuevo, pero puede que su problema se resuelva utilizando algoritmos ms potentes, mejorando las comunicaciones internas, gestionando mejor los datos o slo trabajando de otra forma, puntos que, entre otros muchos, ser necesario considerar antes de empezar a trabajar. La definicin del problema puede cambiarse de forma dinmica a medida que se desarrolla el software, ya que ste es flexible y se adapta con facilidad : 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 definicin del problema suelen obligar a comenzar de nuevo desde el principio. Evidentemente, cuanto ms avanzada est la fase de implementacin (codificacin y prueba) mayor ser el coste derivado de los cambios, hasta tal punto que, en la fase final, suele ser ms barato comenzar de cero que introducir modificaciones en el cdigo. El proceso anterior debe concretarse en dos vertientes : identificacin del problema real (el problema del cliente) y el problema tcnico (la manera de dar satisfaccin a las necesidades). As, la formulacin del problema tcnico pasa por responder a una serie de preguntas, como por ejemplo : existe la tecnologa necesaria para resolver el problema, cul es ? qu recursos se requerirn para dar solucin al problema ? cules 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 aadir los siguientes interrogantes : cul es el mercado potencial del producto ? qu ventajas tiene frente a la competencia ? qu lugar ocupa el producto dentro de la lnea general de la compaa o empresa ? La respuesta a este segundo grupo de preguntas suele escapar a la formacin normal del tcnico proyectista, por lo que habr que solicitar la colaboracin de gabinetes especializados o, en su defecto, recurrir a la realizacin de un estudio personal ms modesto basado en estadsticas regionales, nacionales o internacionales.

3.1.1.1.- Identificacin del problema real.

Para definir correctamente el problema real es necesario realizar un trabajo entre dos grupos diferentes de personas:

-6-

LOS PROYECTOS DE INGENIERA

a) La empresa cliente que formular el problema del proyecto (falta de eficacia en algunas operaciones, necesidad de modernizacin, disminuir costes de gestin...). b) La empresa de ingeniera, que convertir la formulacin de la necesidad del cliente en una definicin del problema que pueda ser abordada desde el punto de vista tcnico. Evidentemente, al tratarse de un trabajo en equipo, la empresa de ingeniera incidir sobre la formulacin del problema realizada por el cliente corrigindola o aportando ideas que escapan a aquel dada su distinta especializacin. Igualmente, el cliente dar sus ideas sobre la definicin hecha por el equipo tcnico aportando su experiencia en el campo especfico de que se trate. Para que exista una colaboracin eficaz entre ambas partes que d lugar a una identificacin precisa del problema es necesario preparar correctamente las entrevistas o reuniones de trabajo de tal manera que se ahorre tiempo y se obtengan conclusiones concretas, llegando a definirse cuestiones como: Periodo esperado de uso del proyecto. Tipo de usuarios del proyecto. Medios disponibles en la empresa (redes, equipos, perifricos,...). Plazo de ejecucin necesario. Posibilidad de descomponer en subproblemas. Requisitos impuestos por el cliente.

Normativa de aplicacin. La preparacin de la entrevista debe consistir en la elaboracin de un guin 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 inters, tales como personal disponible, espacio, limitaciones econmicas, etc. Por otro lado no es conveniente tomar el esquema previo como una pauta rgida a seguir, sino ms bien como una gua que nos permita ir abordando los temas a tratar con un orden lgico, sin impedir al cliente que vaya expresando sus inquietudes, pero procurando no apartarnos demasiado de la lnea de informacin deseada. Asimismo, el paso de recogida de informacin con el cliente no suele hacerse en una sola sesin, sino que es ms usual ir avanzando poco a poco en el nivel de detalle realizando entrevistas sucesivas. Lgicamente, es de utilidad que, conforme se vayan sucediendo las reuniones de definicin del problema, vaya interviniendo cada vez personal ms especializado de cada una de las partes.

-7-

LOS PROYECTOS DE INGENIERA

Un ejemplo de guin para una entrevista de toma de contacto podra ser: 1) Tipo de trabajo que se solicita: estudio, informe, anteproyecto o proyecto. 2) Formulacin del problema con las palabras y desde el punto de vista del proyectista. 3) Antecedentes: se han realizado estudios previos sobre el tema? estudios de viabilidad? estudios de mercado? 4) Plazos de entrega esperados. 5) Presentacin del proyectista: exposicin de trabajos realizados con anterioridad, colaboradores, medios disponibles, etc... 6) Cuantificacin del problema: estimar los recursos humanos a utilizar, fases principales de realizacin del proyecto, costes del trabajo, informacin necesaria para continuar. Como resultado de la primera entrevista se prepara un informe con: 1) 2) 3) 4) Contenido del proyecto. Plazo propuesto. Coste aproximado del proyecto. Borrador del contrato u hoja de encargo.

3.1.1.2.- Identificacin del problema tcnico.

A continuacin, el equipo de desarrollo tendr que establecer todos los condicionantes del problema, para lo que existe una tcnica de ingeniera denominada PDS (Product Design Specification) que consiste en dar respuesta a una lista de preguntas bsicas: 1) Funcionamiento: debe describirse con detalle lo que el cliente espera del producto, pero de forma tcnica. As, describir el funcionamiento del producto ser traducir a lenguaje tcnico el problema enunciado por el cliente. Siempre que sea posible, la descripcin del funcionamiento debe hacerse de forma simple, utilizando para cada funcin o accin un verbo y un nombre (por ejemplo: leer datos, utilizar el algoritmo, presentar en pantalla, guardar resultados, imprimir resultados, ...). Por otro lado la descripcin del funcionamiento de que lo se disea debe ser lo ms simple posible y debe evitarse incluir en la lista de funciones del producto aquellas que son deseables para el diseador pero que no intervienen directamente o son accesorias, ya que con ello se aumenta innecesariamente el coste y, generalmente, disminuye la fiabilidad del producto conseguido.

-8-

LOS PROYECTOS DE INGENIERA

2) Entorno: el siguiente elemento a especificar es el entorno, pero este concepto hay que entenderlo en sentido amplio, es decir: el entorno de programacin que se va a usar, o el interfaz de usuario, pero tambin hay que especificar qu personas van a utilizar el producto que se disea, su preparacin, en qu condiciones va a ser utilizado, incluyendo los ruidos, las vibraciones, temperatura y humedad del ambiente, etc... Aspectos que, en general, condicionarn no slo el software que se disea sino tambin el hardware necesario para ejecutarlo. 3) Vida esperada: ningn producto es eterno, ya que constantemente aparecen tcnicas que ayudan a mejorar el diseo. Con respecto al software, esta aseveracin se hace ms 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 diseo para un producto que va a ser sustituido en breve. 4) Ciclo de mantenimiento: el software que se entregue al cliente, ser definitivo, 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 coste, ya que estos datos influirn 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 fondo 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 producto, y despus evala su funcionamiento. Respecto al software, el aspecto externo radica, no slo en que el interfaz sea amigable y de manejo intuitivo y ergonmico, sino que tambin es necesario considerar aspectos como la presentacin (discos, CD-ROM, ...), el diseo de la cartula y del envoltorio, el manual de usuario, que debe ser atractivo, fcilmente inteligible y no debe necesitar del apoyo de ninguna documentacin adicional, etc. 7) Estandarizacin: el uso de diseos estndar facilita el trabajo, de tal manera que debe utilizarse siempre que sea posible lo que ya est estipulado, como por ejemplo bibliotecas de funciones matemticas, protocolos de comunicaciones, combinaciones de colores, mens desplegables, tipos de ficheros...

-9-

LOS PROYECTOS DE INGENIERA

8) Calidad y fiabilidad: el aseguramiento de la calidad es un campo que va tomando cada vez ms importancia. Desde el punto de vista del diseador del software debe identificarse cuales son los puntos o elementos de riesgo, con ms probabilidad de fallo, e intentar minimizar esta probabilidad con un diseo adecuado. 9) Programa de tareas: ningn plan de diseo estar completo sin que exista un programa detallado de su realizacin a lo largo del tiempo, de tal manera que se determine el plazo disponible para la ejecucin de cada parte del proyecto, los recursos (humanos y materiales) que se emplearn, y el coste aproximado. El equipo de diseo debe conocer esta planificacin y los plazos de que dispone, pero no es eficaz a largo plazo dar a conocer la programacin en todos sus detalles ya que la tendencia del personal es la de agotar al mximo los plazos disponibles. 10) Pruebas: otra de las especificaciones importantes a la hora de disear es la de determinar qu partes del diseo sern sometidas a pruebas, en qu momento, cules son las pruebas y cules son los resultados mnimos esperados para que pueda darse por bueno el diseo. 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 tambin la seguridad contra copias no permitidas.

3.1.2.- Identificacin de los factores limitativos.

Llegado este punto el ingeniero deber haber identificado correctamente el problema real y el problema tcnico y debe prepararse para resolver ste ltimo de forma ptima. Comienza ahora la fase de toma de datos desde el punto de vista tcnico. Una relacin de datos a recopilar en esta fase podra ser : Qu tecnologas se requieren para conseguir la funcionalidad y el correcto rendimiento del sistema ? Qu es necesario desarrollar por completo : algoritmos, mtodos o procesos ; y cul es la probabilidad de realizarlo con xito ? En qu proporcin afectar al coste total del sistema el desarrollo de la metodologa ?

-10-

LOS PROYECTOS DE INGENIERA

A esta lista de preguntas puramente tcnica hay que aadir otras sobre las limitaciones del diseo que son impuestas por el exterior y que pueden ser de dos tipos : Factores dato : son factores dato aquellos que no pueden ser modificados, como por ejemplo limitaciones de tiempo dadas por el plazo de entrega del proyecto, limitaciones presupuestarias del cliente, tecnologa del hardware existente, etc... Factores estratgicos : son variables de diseo en las que habr que elegir entre dos o ms posibilidades, dependiendo la solucin final que se adopte de la eleccin realizada. Por ejemplo se desea que la solucin generada pueda utilizarse en cualquier equipo, o es necesario disponer de unos requisitos mnimos ? se utilizarn grficos, o slo pantallas de texto ? qu tipo de sistema operativo o entorno es ms adecuado para este caso ?

3.2.- Elaboracin de propuestas.

En este punto del proceso de proyecto habremos analizado las necesidades reales del cliente, habremos identificado los problemas real y tcnico y tendremos definidos los factores dato y estratgicos. Se hace necesario, por lo tanto, pasar a buscar soluciones que satisfagan la necesidad enunciada al mnimo coste posible. Generalmente la solucin a los problemas de ingeniera no es nica, existiendo un abanico de soluciones posibles que satisfacen en mayor o menor medida las restricciones impuestas al problema. Asimismo, la eleccin de la solucin ms adecuada no suele ser evidente ya que, si una solucin satisface correctamente uno de los objetivos, puede que no cumpla otros completamente. Para evitar los inconvenientes derivados de una mala seleccin de soluciones, es necesario que el nmero de posibles alternativas de diseo sea lo ms grande posible y realizar una evaluacin que contemple las soluciones adoptadas desde varios aspectos, de tal manera que se tenga en cuenta, no slo que lo diseado satisfaga las necesidades fundamentales del cliente, sino tambin la economa, la ergonoma, la esttica, la flexibilidad o adaptabilidad, la optimizacin en el uso de los recursos, etc.

3.2.1.- Brainstorming.
El brainstorming (tormenta cerebral o tormenta de ideas) consiste en una reunin de trabajo a cargo de un grupo de personas en nmero variable (7 a 12, aunque pueden ser ms) y que han de tener conocimientos en el tema de que se trata y conocer los condicionantes especficos del problema de diseo. Durante cada sesin se expondrn ideas para la posible resolucin del problema estando prohibidas las crticas. Se obtiene as un

-11-

LOS PROYECTOS DE INGENIERA

nmero relativamente grande de propuestas que sern evaluadas con posterioridad. Para que la tcnica del brainstorming tenga xito, es necesario que haya un jefe, organizador o moderador que prepare la reunin informando a los participantes del tema que se va a tratar y de los criterios bsicos a utilizar; asimismo tomar nota de las ideas expuestas y las ordenar por afinidad entre ellas. Las propuestas as obtenidas sern evaluadas por un equipo diferente de personas y se seleccionar las ms acertadas. La principal caracterstica de esta tcnica es la carencia de crticas, por lo que se libera el subconsciente de los participantes y se da rienda suelta a la imaginacin obtenindose gran cantidad de sugerencias. Otro factor importante a la hora de profundizar en las soluciones es utilizar las ideas de los dems, 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 sesin de brainstorming para buscar ideas en un problema de solucin nica. El peligro principal de esta tcnica es la divagacin, ya que el estado mental que se crea en los participantes favorece el desarrollo de las sugerencias ms imaginativas o fantsticas y un alejamiento del tema propuesto inicialmente, por lo que es misin del organizador reconducir el tema tantas veces como estime preciso.

3.2.2.- Listas de preguntas y listas de objetivos.

Un mtodo sencillo que permite aclarar ideas sobr qu y cmo disear, suele ser el de las listas de preguntas y las listas de objetivos. En este mtodo se pretende, partiendo de una serie de preguntas estandarizadas sobre el diseo, profundizar en el conocimiento del problema y obtener conclusiones que puedan ser de aplicacin directa a la resolucin de los mismos. A continuacin 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 evidente que en la mayora 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 excedern el mbito normal de aplicacin para la que han sido concebidas. Sin embargo no debemos olvidar que en la fase de diseo del proyecto en que nos encontramos no es aconsejable descartar de antemano ninguna posibilidad por lo que es recomendable estudiar cada opcin por separado para cada uno de los elementos que compondrn el proyecto y trasladar las conclusiones al conjunto.

-12-

LOS PROYECTOS DE INGENIERA

Tabla 1. Lista de preguntas en el proceso de diseo.

PREGUNTAS BSICAS OTROS USOS? ADAPTAR? MODIFICAR? AGRANDAR? DISMINUIR? SUSTITUIR? INVERTIR? COMBINAR? ORDENAR? ELIMINAR? SEPARAR? EQUILIBRAR? IMPLEMENTAR? PREGUNTAS SECUNDARIAS Nuevos usos para lo ya existente?, nuevos usos de lo modificado? Qu podra copiar?, a qu se parece?, a quin o qu podra emular? Se podra buscar otra perspectiva?, otro diseo?, otro sistema?, otro equipo? Aumentar el tamao?, la velocidad?, los requerimientos? Qu se puede minimizar? Qu se puede intercambiar?, elementos?, entornos?, interfaces?, personal? Es necesario este orden de las cosas?, se puede hacer al revs? Enlazar partes distintas?, utilizar restos de operaciones anteriores? Qu se puede jerarquizar?, qu se puede estructurar? Hay algo realmente innecesario? Puede hacerse por partes? Cmo compensar los recursos?, cmo repartir el personal? Algoritmos?, funciones?, bases de datos?, qu hay que hacer partiendo de cero?

Tabla 2. Lista de objetivos en el proceso de diseo.

OBJETIVOS DISMINUIR COSTES AHORRAR MATERIAL USAR LOS SUBPRODUCTOS HACERLO MS FIABLE HACERLO MS MANEJABLE HACERLO MS AGRADABLE HACERLO MS ERGONMICO HACERLO MS FLEXIBLE HACERLO MS FUNCIONAL HACERLO MS COMPRENSIBLE NORMALIZARLO APLICACIONES Mejorar la distribucin, ahorrar tiempo, planificar, organizar los recursos Economizar en el diseo, no imponer especificaciones innecesarias al hardware Reutilizar las partes diseadas y desechadas en otros proyectos, reciclar material Mejorar el sistema de pruebas, implantar un sistema de calidad Mejorar el diseo para que su uso sea ms intuitivo Mejorar la presentacin exterior del producto Estudiar la relacin diseo-trabajador y producto-usuario Adaptar los mtodos de trabajo a la mayor cantidad de productos, utilizar las mismas herramientas para otros diseos futuros Mejorar las prestaciones generales del producto Adjuntar manuales tiles y simples, ejemplos de utilizacin, instrucciones paso a paso Utilizar material y procedimientos standard

3.2.3.- La sinctica.
La sinctica es un mtodo de diseo 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 sinctica debe estar formado por un nmero no demasiado elevado de personas (hasta 6), en el cual la mitad puede formar parte del equipo de diseo 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 mtodo 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 crticas, y la diferencia estriba en que, si en el mtodo del brainstorming se trabaja en busca del mayor nmero de soluciones posible, en la sinctica se persigue obtener una nica solucin viable.

-13-

LOS PROYECTOS DE INGENIERA

La prctica demuestra que la sinctica funciona bien en la resolucin de problemas reales en los que existe una alta probabilidad de que las soluciones puedan llevarse a la prctica, como por ejemplo en aquellos casos en los que se desee buscar nuevas soluciones mejores y ms eficaces a problemas que ya hayan recibido alguna solucin 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 mtodo no da buenos resultados. Los cuatro tipos de analogas utilizados son: 1) Analoga directa: en la que se asimila el problema a algo existente en la realidad. 2) Analoga personal: el diseador se imagina a s mismo haciendo las veces u ocupando el lugar de lo que disea, de tal manera que toma una consciencia ms eficaz del problema. 3) Analoga simblica: se realiza una comparacin metafrica en la que lo que se disea se asimila a la totalidad o a parte de algo conocido: rbol de decisin, boca de un ro... 4) Analoga fantstica: este es el tipo ms libre en el que el diseador deja completa libertad a su imaginacin y el problema se asemeja a objetos inexistentes. La sesin de sinctica comienza con una exposicin del problema por parte del director o moderador de la misma de forma que, inicialmente, procure exponer las soluciones previamente existentes o triviales para que sean evitadas desde el principio por los participantes. Adems, debe sugerir alguna lnea principal dentro de los tipos de analogas mencionadas ya que, como puede suponerse, es relativamente frecuente la divagacin. En el caso de que las comparaciones que vayan realizando los participantes se alejen demasiado del problema inicial o sean demasiado fantsticas, debe procurar reconducir la discusin volviendo a resumir los objetivos que se persiguen. Si por el contrario aparecen comparaciones que tengan visos de poder convertirse en nuevas soluciones del problema, se profundizar en ellas hasta tener un prediseo.

3.2.4.- Ideas combinativas.

El mtodo de las ideas combinativas (o combinadas) es de utilidad en aquellos casos en los que existen slo unas cuantas formas posibles de dar solucin a un problema en

-14-

LOS PROYECTOS DE INGENIERA

cada uno de sus aspectos simples, de tal manera que estas opciones puedan ser combinadas, y cada combinacin evaluada, con facilidad. Supongamos un problema de diseo en el que hay que decidir sobre dos aspectos y cada uno de ellos slo tiene dos opciones posibles. As, el primer aspecto puede tomar la solucin 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 continuacin se piensa en posibles ventajas que es de esperar que tenga la solucin definitiva, como por ejemplo, transportabilidad, ergonoma, facilidad de manejo o esttica y se oponen a las cuatro soluciones en una tabla, marcando con una X aquella solucin que presente una determinada ventaja (tabla 3). Tabla 3. Tabla de seleccin de ideas combinativas. Transportabilidad Ergonoma Facilidad de manejo Esttica AB X X X Ab X X X X aB X ab

En este caso resulta evidente a primera vista que la solucin a elegir es la AB siempre y cuando el proyectista d la misma importancia a todas las caractersticas o ventajas del problema.

3.2.5.- Normas generales de diseo.

A continuacin se dan unas normas bsicas a seguir en la bsqueda de soluciones sea cual sea el mtodo empleado. 1) Evitar decisiones arbitrarias: siempre que se disea 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 diseo obteniendo algo verdaderamente til y original. 2) Buscar ms alternativas: quedarse con la primera idea no suele ser suficiente y siempre ser mejor tener varias opciones para comparar. 3) Construir prototipos: una vez que se haya diseado una parte con suficiente entidad como para que pueda ser llevada a la prctica, puede ponerse a punto en una versin reducida que permita estudiar su funcionamiento. A menudo, al ver un modelo pueden aflorar nuevas ideas que haban sido pasadas por alto.

-15-

LOS PROYECTOS DE INGENIERA

4) Incrementar al mximo el grado de abstraccin en la formulacin del problema: cuando el problema se define con gran detalle por parte del cliente o del tcnico es posible que en la misma definicin est enmascarada una solucin parcial que concuerda con los deseos del cliente o del diseador. Por ejemplo es posible definir un problema de proyecto como disear una silla cuando el problema es disear un artefacto para sentarse lo que, evidentemente, 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 lmites: las limitaciones impuestas al problema por condicionantes econmicos o de tiempo ya son suficientes. No debe empobrecerse el resultado slo por no haber explorado todas las vas posibles de solucin. 7) Cumplir las funciones especificadas: una vez realizada la PDS, hay que ajustarse lo ms posible a ella, de tal manera que si se encuentran dificultades en el cumplimiento de alguna funcin siempre es mejor desechar un diseo y empezar de nuevo que dejar especificaciones sin lograr. 8) Explotar al mximo los mtodos y herramientas a nuestro alcance: a menudo, el tcnico se acostumbra a utilizar siempre los mismos criterios y las mismas herramientas, lo que en la mayora de los casos, va en contra de la bsqueda del mejor diseo. 9) Realizar un desarrollo lgico del proceso de diseo: empezar por lo general y terminar por lo particular. Suele ser de utilidad realizar una justificacin detallada de cada una de las decisiones de diseo que se tomen, de tal manera que pueda observarse una ilacin lgica de unas a otras. 10) Hacerse preguntas: el diseador debe adoptar una actitud de incredulidad respecto a la bondad de lo que disea, de tal manera que constantemente se est preguntando: es necesaria esta parte? cmo puede fallar esto? por qu lo estamos haciendo as?

3.3.- Evaluacin de las propuestas alternativas.

Una vez logrado un abanico de posibles soluciones utilizando los mtodos de diseo mencionados anteriormente, es necesario elegir la mejor de todas las alternativas pro-

-16-

LOS PROYECTOS DE INGENIERA

puestas. Sin embargo no es fcil determinar qu opcin es la ms adecuada en cada caso ya que suelen existir criterios de valoracin a menudo contrapuestos: quiz la solucin econmicamente ms aceptable no es la mejor desde el punto de vista tcnico o viceversa, sin olvidar otros elementos de valoracin tales como la esttica o la imagen externa, condicionantes legales o de cualquier otra ndole que puedan ser de aplicacin. Por otra parte, la solucin que satisfaga de forma ptima uno de los criterios quiz ni siquiera alcance un mnimo en alguno de los dems, por lo que es necesario renunciar a la perfeccin en aras de conjuntar todos los criterios en una solucin de compromiso. El proceso bsico a seguir en la comparacin tcnico-econmica de soluciones consiste en identificar en primer lugar el coste de desarrollo del prototipo en contraposicin con los beneficios que se espera obtener (inputs y outputs); establecer cuales van ser los criterios o ndices de decisin, tales como ndices econmicos, tcnicos o combinacin de ambos y, por ltimo tener en cuenta la incertidumbre o riesgo que se corre al realizar el estudio basndose en estimaciones a priori, por lo que habr que considerar tambin este aspecto utilizando un estudio de probabilidades o, al menos, un abanico de estimaciones optimistas y pesimistas. As, se hace necesario contar con herramientas de valoracin que pongan de manifiesto las virtudes y defectos de las soluciones para llegar a decidir cul se adapta mejor al problema. A continuacin se exponen las tcnicas ms usuales.

3.3.1.- Jerarquizacin de las soluciones.

El proceso de seleccin de soluciones es el siguiente. Supongamos que para un determinado proyecto se ha llegado a seis soluciones posibles (A, B, C, D, E, y F), el primer paso consiste en determinar cules son los criterios de valoracin (economa, esttica, facilidad de expansin o modificacin, cumplimiento de los objetivos tcnicos, etc...) y ordenarlos de mayor a menor importancia. El segundo paso consiste en construir una tabla en la que se asigna una puntuacin a cada solucin para cada uno de los criterios, por ejemplo de 0 a 10, y se fija una puntuacin mnima para que una solucin pueda considerarse aceptable. En este caso se va a tomar la puntuacin mnima de 5 (tabla 4). El tercer paso consiste en realizar filtros sucesivos de la siguiente manera: el criterio ms importante (el 1) no es cumplido por la solucin C, que sin embargo alcanza correctamente los dems, pero debido a que este criterio es el ms importante, esta solucin se elimina del estudio. A continuacin se pasa al segundo criterio, que es cumplido por todas las soluciones restantes, por lo que, tomando el tercer criterio se elimina la solucin 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 habra que adoptar criterios complementarios o elegir otro mtodo de valoracin, por lo que el mtodo de jerarquizacin puede tomarse como una primera aproximacin para eliminar las peores soluciones.

-17-

LOS PROYECTOS DE INGENIERA

Tabla 4. Clasificacin por jerarquizacin. 1 2 3 4 5 A 10 7 6 4 7 B 9 8 3 4 8 C 4 5 10 9 7 D 8 7 6 9 5 E 10 5 8 9 6 F 9 7 6 5 5

3.3.2.- Mtodo del valor tcnico ponderado (VTP).

El mtodo VTP es algo ms difcil de aplicar que el de jerarquizacin, pero tambin es ms fiable que aquel. El xito en la valoracin adecuada de las soluciones depende de la experiencia previa de quien lo aplique ya que, de carecer de ella, resulta fcil caer en la subjetividad. Para aplicar el mtodo 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 mtodo de jerarquizacin, se puntan o califican las soluciones de 0 a 10 (pi) para cada criterio y se multiplican las puntuaciones por los pesos. La solucin elegida ser aquella en la que el Valor Tcnico Ponderado (puntuacin total dividida por la puntuacin mxima posible) sea la ms alta. Evidentemente la solucin ms indicada para este proyecto es la C, ya que es la que se adapta mejor al conjunto de criterios de valoracin elegido. Salta a la vista que el xito del mtodo gravita sobre la correcta eleccin de los criterios de valoracin y de los pesos relativos de los mismos, as existe un conjunto de tablas de valoracin prediseadas que pueden servir de utilidad. En la tabla 6 se da una lista completa de criterios de valoracin de soluciones para un nuevo diseo, en ella se ha asignado un peso estndar a cada criterio de valoracin, con lo que se obtienen buenos resultados en la prctica. Tabla 5. Valor tcnico ponderado (VTP). Criterios 1 2 3 4 5 6 Suma VTP Peso g 8 6 9 4 2 5 34 A p 3 5 7 5 8 9 pxg 24 30 63 20 16 45 198 0.582 p 5 5 3 8 6 7 B pxg 40 30 27 32 12 35 176 0.517 p 7 9 4 6 2 6 C pxg 56 54 36 24 4 30 204 0.6 p 5 8 4 5 2 7 D pxg 40 48 36 20 4 35 183 0.538 p 3 9 2 5 6 3 E pxg 24 54 18 20 12 15 143 0.42

-18-

LOS PROYECTOS DE INGENIERA

Tabla 6. Lista de valoracin de soluciones para nuevos diseos. CRITERIO

1.- UTILIDAD a) Utilidad alta b) Utilidad media c) Utilidad baja a) Aspectos funcionales bien estudiados b) Aspectos funcionales correctos c) Aspectos funcionales poco importantes a) El producto es completamente innovador b) Existen algunos productos parecidos en el mercado c) Existen muchos productos similares 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 a) El producto es innovador dentro de la empresa b) El producto mejorar los diseados previamente en la empresa c) El producto est dentro de la lnea de la empresa a) Se contempla la modularizacin y estandarizacin b) Se estudiar ms adelante c) No se contempla 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 a) Se tiene en cuenta la ergonoma producto-usuario b) Se considera someramente c) No se considera 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 a) Se utilizan nuevas tcnicas de desarrollo b) Se utilizan mejor las tcnicas ya existentes c) Se utilizan las tcnicas existentes sin mejorarlas a) La previsin presupuestaria es adecuada b) El presupuesto real se desviar del previsto c) El presupuesto de diseo es excesivo a) El equipo de diseo tiene prestigio y experiencia b) No tiene prestigio pero tiene experiencia previa c) No hay referencias o no son adecuadas a) El presupuesto del proyecto es aceptable para la empresa b) Es asequible c) Es excesivo para el tamao de la empresa

VALORACIN

P1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 5 3 1 X

G 5

PXG K1

2.- FUNCIONALIDAD

10

K2

3.- ORIGINALIDAD

10

K3

4.- PRECIO

K4

5.- EMPRESA

K5

6.- MODULARIDAD

K6

7.- ESTTICA

10

K7

8.- ERGONOMA

10

K8

9.- VIDA PREVISTA

K9

10.- TECNOLOGAS

K10

11.- PRESUPUESTO

10

K11

12.- FACTOR HUMANO

10

K12

13.- TAMAO DEL PROYECTO RESPECTO A LA EMPRESA SUMA 14.- INFORMACIN2

1 2

10

K13 Ki

Es vlido cualquier valor intermedio. Si un criterio no se valora por carecer de datos se puntuar con cero. X es el nmero de respuestas no nulas.

-19-

LOS PROYECTOS DE INGENIERA

La frmula de valoracin emprica contrastada por la prctica es la siguiente:

V=

ki 4N

+ (N/10)2 -1 > 10

La valoracin de las distintas soluciones en funcin del valor V obtenido se muestra en la tabla 7. Tabla 7. Valoracin de las soluciones.
VALORACIN (V) V>8.5 8.5>V>7.0 7.0>V>6.0 6.0>V>5.0 5.0>V CALIFICACIN EXCELENTE MUY BUENA BUENA NORMAL REGULAR

Adems debe dejarse parte de la valoracin a criterios puramente tcnicos con un informe complementario.

3.3.3.- Valoracin econmica.

El mtodo propuesto anteriormente lleva implcita una cierta valoracin econmica de las soluciones aportadas, sin embargo es posible llevar a cabo un estudio ms profundo en este aspecto aplicando alguna de las tcnicas existentes, tanto de estimacin de costes como de obtencin de ndices de valoracin, que escapan al contenido de este tema y que sern tratados ms adelante. En general, la evaluacin econmica parte de una estimacin del coste de desarrollo y de los beneficios que pueden obtenerse de la venta del producto en aos sucesivos, considerando los costes financieros y la inflacin prevista. Con ello se obtendrn unos ndices de valoracin que representarn la rentabilidad esperada del proyecto.

4.- El ciclo de vida del proyecto software.

Hasta el momento se ha tratado de los mtodos generales de diseo en ingeniera de proyectos, sin embargo existe una metodologa particular aplicable a los proyectos de software que, si bien se corresponde con los mtodos tradicionales, contempla las peculiaridades de este tipo de proyectos. El ciclo de vida del proyecto software no es ms que llamar por otro nombre a lo que hemos definido como el ciclo de vida del proyecto o

-20-

LOS PROYECTOS DE INGENIERA

proceso proyectual y se refleja en varios paradigmas o mtodos prcticos de aplicarlo: el ciclo de vida clsico, la construccin de prototipos, y los modelos en espiral.

4.1.- El ciclo de vida clsico.

El ciclo de vida clsico contempla el estudio general del proyecto partiendo del establecimiento e identificacin de objetivos hasta llegar a la prueba y mantenimiento del software desarrollado. Los pasos a seguir en el proceso de proyecto son: ingeniera del sistema, anlisis, diseo, codificacin, prueba y mantenimiento. Este enfoque es secuencial, por lo que este sistema se denomina tambin modelo en cascada y responde al esquema de la figura 2. Ingeniera del sistema: cuando se disea 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 cul debe ser el papel del software dentro de un sistema y estudiar las relaciones que debe tener con lo dems componentes, por lo tanto el primer anlisis a realizar ser a nivel de sistema global, interrelacionando lo que se pretende disear con todas las partes implicadas.

Ingeniera del sistema Anlisis Diseo Codificacin Prueba Mantenimiento

Figura 2. El ciclo de vida clsico.

-21-

LOS PROYECTOS DE INGENIERA

Anlisis de requisitos: una vez identificado el sistema en su totalidad, pasaremos a realizar el anlisis de requisitos, que representa el segundo escaln en el proceso del proyecto. Concretamente deben identificarse aqu las funciones que deber realizar el software, el rendimiento esperado y los interfaces necesarios. Los requisitos deben ser revisados con el cliente o usuario antes de ser dados por vlidos. Diseo: el diseo del software no se refiere a la realizacin o codificacin del programa, sino a la determinacin de sus caractersticas formales generales, tales como la estructura de los datos, la arquitectura y la caracterizacin del interfaz. As, una vez diseado el software, debe asegurarse que este diseo cumple con todos los requisitos de calidad exigidos en el punto anterior. Codificacin: consiste en traducir el diseo realizado a lenguaje inteligible por la mquina. Este paso debe ser mecnico, ya que los problemas generales de diseo han sido resueltos con antelacin. Prueba: es el ltimo paso de la codificacin, 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 modificaciones debidas a falta de adaptacin real a las necesidades, variaciones del entorno tales como nuevas exigencias de rendimiento, o utilizacin de nuevos perifricos. En la fase de mantenimiento habr que aplicar de nuevo cada uno de los pasos del ciclo de vida general, pero con el diseo ya existente en lugar de con un diseo nuevo. Antes de continuar es necesario establecer un paralelismo entre el proceso general de proyecto y lo que hemos llamado el ciclo de vida clsico: el establecimiento de necesidades se corresponde con la ingeniera del sistema, en esta fase se realizan las entrevistas oportunas para llegar a definir correctamente los objetivos, tanto desde el punto de vista del cliente como desde el del tcnico, terminando con una memoria resumen de necesidades. El anlisis de requisitos, si bien es misin del equipo tcnico que vaya a desarrollar el software, no debe excluir la relacin con el cliente, por lo que es de utilidad realizar aqu una segunda tanda de entrevistas ms complejas, en las que intervenga tambin personal tcnico o usuarios directos de la empresa cliente, por lo tanto esta fase estara englobada dentro del establecimiento general de necesidades del proceso proyectual. Las dos siguientes fases del proceso general se corresponden con la fase de diseo del ciclo de vida clsico y en ellas deben aplicarse las tcnicas de elaboracin de propuestas y evaluacin de soluciones que se vieron en los apartados correspondientes.

-22-

LOS PROYECTOS DE INGENIERA

Es necesario prestar gran atencin en esta fase, ya que los errores que se detecten aqu sern mucho ms fciles y econmicos de solucionar que los que aparezcan en fases posteriores, por otro lado iniciar la codificacin sin realizar un diseo detallado de las estructuras de datos, arquitectura y diseo procedimental, es justamente lo contrario de lo que debe hacerse y sera como pedir a un arquitecto que construya una casa sin haber 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 diseo, al quedarse con una nica solucin en alguna de las etapas de diseo sin haber comparado las posibilidades que ofrece cada una de las alternativas, se corre el riesgo de optar por soluciones no adecuadas al problema en cuestin. Las fases de confeccin del proyecto y ejecucin son equivalentes a la de codificacin, aunque la primera de ellas se corresponde ms con una redaccin de la documentacin del proyecto y la segunda tiene parte en comn con la fase de prueba, ya que tanto la codificacin como las pruebas forman parte de la ejecucin formal del proyecto. Por ltimo, la evaluacin del grado de satisfaccin de las necesidades del cliente logrado con el proyecto realizado pertenece tanto a las pruebas del software como al mantenimiento del mismo una vez instalado. Evidentemente, tanto en el proceso general del proyecto como en el ciclo de vida clsico del software, el ciclo es cerrado, lo que significa que en cualquier momento del proceso es posible volver a replantear un estudio de necesidades, o una nueva elaboracin de propuestas, aunque esto no es deseable y debe evitarse por medio de la aplicacin lo ms detallada posible de las tcnicas del diseo. El ciclo de vida clsico es un mtodo muy utilizado, sin embargo presenta ciertas dificultades en su aplicacin: 1. Es difcil realizar un seguimiento secuencial de los pasos del proceso de desarrollo de proyectos reales, ya que todas las fases interaccionan entre s. Por lo tanto, la vuelta atrs mencionada anteriormente est casi asegurada, no tanto porque existan errores en el proceso como por la dificultad de definirlo 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 diseo si aparecen nuevos requisitos con el proceso avanzado. 3. Hasta las ltimas fases del proceso no existir una versin del programa capaz de ser utilizado, de tal manera que los posibles errores de diseo o de definicin de requisitos tienen consecuencias graves cuando se realizan las pruebas.

-23-

LOS PROYECTOS DE INGENIERA

ELABORACIN DE PROPUESTAS

Ingeniera del sistema

EVALUACIN DE PROPUESTAS

Anlisis y Diseo

CONFECCIN DEL PROYECTO

Codificacin

EJECUCIN

Prueba

SATISFACCIN DE NECESIDADES

Mantenimiento

Figura 3. Correspondencia entre el proceso general del proyecto y el ciclo de vida clsico. En cualquier caso el mtodo es interesante como gua en el proceso de diseo ya que responde a una metodologa racional del estudio del proyecto.

4.2.- Construccin de prototipos.

Uno de los problemas fundamentales que presenta el ciclo de vida clsico es la necesidad 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 perifricos se necesitan. En estos casos es ms til establecer un proceso iterativo en el

-24-

LOS PROYECTOS DE INGENIERA

que anlisis, diseo, codificacin y prueba se realizan de forma interactiva y simultnea. Para ello debe partirse de la construccin de un prototipo sobre el que establecer el primer paso del ciclo, este prototipo puede realizarse en papel, explicando cmo ser inicialmente 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 construccin de prototipos. Al igual que en el ciclo de vida clsico, debe comenzarse con la especificacin de requisitos por parte del cliente, a continuacin el ingeniero del software realizar un diseo rpido en el que se centrar en la entrada y salida de datos y, en general, en los aspectos del software visibles para el usuario.

Definicin de Requisitos Producto Final Diseo Rpido

Revisin

Construccin del Prototipo Evaluacin con el Cliente

Figura 4. Esquema general del mtodo de construccin de prototipos. Construido un prototipo, se pasar a evaluar ste con el usuario, que definir nuevos requisitos o redefinir los anteriores. Los problemas bsicos que presenta el modelo de construccin de prototipos es que el cliente a menudo ve programas funcionando que para el diseador son slo fases del proceso ya que an 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-

-25-

LOS PROYECTOS DE INGENIERA

trega inmediata del software. Por otro lado es posible que el diseador, por tratarse de un prototipo, utilice herramientas o lenguajes de programacin inadecuados con la intencin de modificarlos con posterioridad, pero a lo largo del proceso, quiz influido por las presiones del cliente, se d por satisfecho an a sabiendas de la falta de optimizacin. La solucin a estos problemas es relativamente fcil: establecer al principio un protocolo de trabajo con el cliente en que se informe al mismo del mtodo de generacin de prototipos y de que los primeros pasos slo deben servir para la definicin de los requisitos de tal manera que el software definitivo es objeto de un proceso ms largo.

-26-