1. SISTEMAS SOFTWARE 1.1. Introduccin.

Hoy en da los sistemas informticos se caracterizan por la rpida evolucin de los componentes hardware, que incrementan continuamente sus prestaciones junto con una fuerte tendencia a la estandarizacin y una gran diversidad de marcas y modelos con prestaciones y precios similares. Es por todo ello, que las prestaciones de los grandes ordenadores de aos anteriores hoy en da estn disponibles en un ordenador personal. El software es el mecanismo es el mecanismo que nos permite utilizar y explotar ese potencial. Todo esto hace que a la hora de plantearnos comprar un sistema informtico completo destinado a cualquier tipo de actividad (gestin de empresa, procesos industriales, uso domstico, etc.), el software es lo que va a marcar la diferencia. Siempre entre equipos con caractersticas similares elegiremos aqullas compaas con mayores prestaciones, calidad y facilidad de uso de su software. Por otro lado, decir que debido a la complejidad de los actuales sistemas informticos, el desarrollo del software no es nada fcil, haciendo necesario en muchas ocasiones proyectos con decenas de miles de lneas de cdigos. No se puede programar sin ms, es necesario analizar lo que tenemos que hacer, cmo lo vamos a hacer y cmo se van a coordinar las distintas personas que intervienen en el proyecto para llegar a obtener los resultados inicialmente esperados. Por lo visto anteriormente, podemos decir que el software, es el componente cuyo desarrollo presenta mayores dificultades, ya sea por su planificacin, el no cumplimiento de las estimaciones de costes iniciales, etctera. Pero todo es debido a que es una actividad reciente si la comparamos con otras actividades de ingeniera, y an es ms reciente la disciplina que establece el orden en el desarrollo de sistemas de software partiendo el problema, quizs, en que no estn lo suficientemente difundidos o valorados.

1.2. Evolucin de la industria del software.

En el comienzo de la informtica, el hardware tena mucha mayor importancia que en la actualidad, su coste era mucho mayor, y su fiabilidad, capacidad de almacenamiento y procesamiento era lo que determinaba las prestaciones de un determinado producto. El software pasaba a un segundo plano, no se le daba mucha importancia, la mayora se desarrollaba y era usado por la misma persona, siendo ella misma quien lo escriba, ejecutaba y si fallaba, lo depuraba. El diseo estaba en la mente de alguien y la documentacin no exista, si algo fallaba siempre estara esa persona para subsanar el error. Dada esta situacin, las empresas se dedicaron a la mejora de las prestaciones de los equipos en lo que se refiere al hardware, reduciendo los costes y aumentando la velocidad de clculo y capacidad de almacenamiento. Debido a esto el hardware se desarroll rpidamente y los sistemas informticos cada vez eran ms complejos necesitando un software, a su vez, ms complejo para su funcionamiento. Es entonces cuando surgen las primeras casas dedicadas al software y comienza la movilidad laboral, por lo que con la marcha de un trabajador era poco probable el mantenimiento o modificacin de los programas desarrollados por ste. Al no existir una metodologa y una documentacin consistente, los programas presentaban, en muchas ocasiones errores e inconsistencias, por lo que estaban en una continua depuracin elevando as los costes de los mismos. Era ms rpido en muchas ocasiones, comenzar de cero que modificar lo que ya estaba hecho, pero no por ello estaban exentos de errores y futuras modificaciones, por lo que la situacin volva a ser la misma. Hoy en da, todo ha cambiado y el software pasa a ser el elemento principal del coste frente al hardware, lo cual a llevado a la aparicin y desarrollo de nuevas tecnologas que enfocan integralmente el problema abarcando

todas sus fases, que en su mayora no se consideraban en los desarrollos tradicionales, y que son fundamentales en la reduccin de costes y plazos, as como la calidad del producto final. Es lo que llamamos la ingeniera del software, definindose como el tratamiento sistemtico de todas las fases del ciclo de vida del software.

1.3. Caractersticas del software.

Una definicin de software podra ser la siguiente: Software: instrucciones de ordenador que cuando se ejecutan proporcionan la funcin y el comportamiento deseado, estructuras de datos que facilitan a los programas manipular adecuadamente la informacin, y documentos que describen la operacin y el uso de los programas. Por ello, decir tiene que el software incluye no slo los programas de ordenador, sino tambin las estructuras de datos que manejan esos programas y la documentacin que se adjunta del proceso de desarrollo, mantenimiento y uso de dichos programas. Segn esto, mientras el hardware es algo fsico, material, el software es inmaterial y por ello tiene unas caractersticas completamente distintas. Algunas de ellas pueden ser:

El software se desarrolla, no se fabrica en s.

Tanto en el proceso de desarrollo del software como del hardware se siguen unas fases de anlisis, diseo y desarrollo o construccin, obteniendo un buen producto final dependiendo de la calidad del diseo. En el caso de produccin de hardware a gran escala, el coste del producto depende del coste de los materiales empleados y del propio proceso de produccin, no influyendo tanto en el coste las fases previas de ingeniera. En cambio en el caso del software, el desarrollo es una ms de las labores de ingeniera, y la produccin a gran o pequea escala no influye en el impacto que tiene la ingeniera en el coste, al ser un producto inmaterial. Por otro lado, el software no presenta problemas tcnicos y no requiere un control de calidad individualizado, cosa que si que ocurre en el hardware. Los costes del software radican en el desarrollo de la ingeniera y no en la produccin, y es ah donde hay que incidir para reducir el coste final del producto.

El software no se estropea.

Partiendo tanto de la figura 1.1, como de la figura 1.2, podemos observar como por un lado el hardware (figura 1.1.), tiene la llamada curva de baera, que indica que tiene muchos fallos al principio de su vida, debidos en gran parte a los defectos de diseo o a la baja calidad inicial de la fase de produccin. Dichos defectos se van subsanando hasta llegar a un nivel estacionario, pero los fallos vuelven a incrementarse debido al deterioro de los componentes (suciedad, vibraciones u otros factores externos) por lo que hay que sustituir los componentes defectuosos por otros nuevos para que la tasa de fallos vuelva a estar a un nivel estacionario.

Por otro lado observamos que en el caso del software (figura 1.2.), inicialmente la tasa de fallos es alta, por errores no detectados durante su desarrollo, pero que una vez corregidos y dado que no est expuesto a factores de deterioro externos, la tasa de fallos debera alcanzar un nivel estacionario y mantenerse definitivamente. Todo esto no es ms que una simplificacin del modelo real de fallos de un producto software. Durante su vida, el software va sufriendo cambios debido a su mantenimiento, el cual puede orientarse tanto a la correccin de errores como a cambios en los requisitos iniciales del producto. Al realizar los cambios es posible que se produzcan nuevos errores con lo cual se manifiestan picos en la curva de fallos. Estos errores pueden corregirse, pero los sucesivos cambios, hacen que el producto se aleje cada vez ms de las especificaciones iniciales de acuerdo a las cuales fue desarrollado, conteniendo cada vez ms errores. Adems, a veces, se solicita un nuevo cambio antes de haber corregido todos los errores producidos por el cambio anterior. Por todo ello, como vemos en la figura 1.3, el nivel estacionario que se consigue despus de un cambio es algo superior al que haba antes de efectuarlo, degradndose poco a poco el funcionamiento del sistema. De esta manera, podemos decir que el software no se estropea, pero se deteriora.

Adems, hay que decir, que cuando un componente software se deteriora, al contrario que ocurre en el hardware, no podemos sustituirlo por otro porque no existen piezas de repuesto. Cada fallo indica un fallo en el diseo o en el proceso por el que se transform el diseo en cdigo mquina ejecutable. La solucin est en sustituir el diseo por otro as como el desarrollo del producto.

La mayora del software se construye a medida.

En el caso del hardware el diseo se realiza con componentes digitales existentes en catlogo que han sido probados por el fabricante y usuarios anteriores, teniendo unas especificaciones claras y estando bien definidos. Con el software no ocurre as. No existen catlogos de componentes, y aunque productos como sistemas operativos, editores, entornos de ventanas y bases de datos se venden en grandes ediciones, la gran mayora del software se fabrica a medida, siendo su reutilizacin muy baja. Se puede comprar software ya desarrollado, pero como unidades completas, no como componentes que pueden ser reensamblados para construir nuevos programas. Esto hace que el coste de ingeniera sobre el producto final sea muy elevado. A lo largo de los aos se ha intentado la reutilizacin del software pero tras muchos intentos ha habido poco xito. Un ejemplo claro de reutilizacin son las bibliotecas que se empezaron a desarrollar en los aos sesenta como subrutinas cientficas, reutilizables en muchas aplicaciones cientficas y de ingeniera, as como hoy en da la mayor parte de los lenguajes modernos incluyen bibliotecas de este tipo. Sin embargo, existen otros problemas como la bsqueda de un elemento en una estructura de datos, debido a la gran variacin que existe en cuanto a la organizacin interna de estas estructuras y en la composicin de los datos que la contienen, por lo que, aunque existen algoritmos para resolver estos problemas, no queda ms remedio que programarlos una y otra vez,

adaptndolos a cada situacin particular. Un nuevo intento de conseguir la reutilizacin se produjo con el uso de tcnicas de programacin estructurada y modular. Sin embargo, se dedica por lo general poco esfuerzo al diseo de mdulos lo suficientemente generales para ser reutilizables, y en todo caso, no se documentan ni se difunden lo suficiente para extender su uso, con lo cual se tiende a disear y programar mdulos muy semejantes una y otra vez. La programacin estructurada permite disear programas con una estructura ms clara y ms fcil de entender, lo cual permite la reutilizacin de mdulos dentro de los programas o incluso dentro del proyecto que se est desarrollando, pero la reutilizacin de cdigo en proyectos es muy baja. La ltima tendencia es el uso de tcnicas orientadas a objetos, que permiten la programacin por especializacin. Los objetos disponen de interfaces claras y los errores cometidos en su desarrollo pueden ser depurados sin que esto afecte a la correccin de otras partes del cdigo y pueden ser heredados y reescritos parcialmente, haciendo posible su reutilizacin an en situaciones no contempladas en el diseo inicial.

1.4. Aplicaciones del software.

El software puede aplicarse a numerosas situaciones del mundo real. En primer lugar, diremos que puede aplicarse a todos aquellos problemas para los que se ha establecido un conjunto de acciones que lleven a su resolucin (algoritmo). En estos casos, usamos lenguajes para implementar estos algoritmos. Es difcil establecer categoras genricas para las aplicaciones del software. Cuanto ms complejo es el mismo ms complicado se hace establecer compartimentos claramente separados. No obstante, se suele aceptar esta clasificacin:

1.4.1. Software de sistemas.

Formado por aquellos programas cuyo fin es servir al desarrollo o al funcionamiento de otros programas. Este tipo de programas son muy variados: editores, compiladores, sistemas operativos, entornos grficos, programas de telecomunicaciones, etc., pero todos ellos tienen unos puntos en comn y como estar muy prximos al hardware, ser utilizados por numerosos usuarios y por ser programas de difusin, no estn diseados normalmente a medida. Esto permite un mayor diseo y optimizacin, pero tambin les obliga a ser muy fiables, cumpliendo estrictamente las especificaciones para las que fueron creados.

1.4.2. Software de tiempo real

Formado por aquellos programas que miden, analizan y controlan los sucesos del mundo real a medida que ocurren, debiendo reaccionar de forma correcta a los estmulos de entrada en un tiempo mximo prefijado. Deben, por tanto, cumplir unos requisitos temporales muy estrictos, adems de ser fiables y tolerantes a fallos. Por otro lado, no suelen ser muy complejos y precisan de poca interaccin con el usuario.

1.4.3. Software de gestin

Este tipo de programas utiliza grandes cantidades de informacin almacenadas en bases de datos para poder facilitar las transacciones comerciales o la toma de decisiones. Adems de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crtico y los errores pueden ser corregidos a posteriori, incluyen programas interactivos que sirven de soporte a las transacciones comerciales.

1.4.4. Software cientfico y de ingeniera.

Es otro de los campos clsicos de aplicacin de la informtica. Se encarga de realizar complejos clculos

sobre datos numricos de todo tipo. En este caso un requisito bsico que deben cumplir es la correccin y exactitud de las operaciones que realizan. Este campo se ha ampliado ltimamente con el desarrollo de los sistemas de diseo, ingeniera y fabricacin asistida por ordenador (CAD, CAE y CAM), lo simuladores grficos y otras aplicaciones interactivas que lo acercan al software de tiempo real e incluso al de sistemas.

1.4.5. Software de ordenadores personales.

El uso de ordenadores personales y de uso domstico se ha extendido a lo largo de la ltima dcada. Aplicaciones tpicas son los procesadores de texto, las hojas de clculo, bases de datos, aplicaciones grficas, juegos, etctera. Son productos de amplia difusin orientados a usuarios no profesionales, por lo que sus principales requisitos son la facilidad en el uso y el bajo coste.

1.4.6. Software empotrado.

Es aqul que va instalado en otros productos industriales, como por ejemplo la electrnica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un vdeo domstico hasta un misil con cabeza nuclear, pasando por sistemas de control de los automviles, y realiza funciones muy diversas, desde complicados clculos en tiempo real a sencillas interacciones con el usuario facilitando el manejo del aparato que los incorpora. Comparten caractersticas con el software de sistemas, el de tiempo real, el de ingeniera y cientfico y el de ordenadores personales.

1.4.7. Software de inteligencia artificial.

El software basado en lenguajes procedimentales es til para realizar de forma rpida y fiable operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difcil su aplicacin a problemas que requieran funciones intelectuales ms elevadas. Esta deficiencia trata de subsanarla el software de inteligencia artificial, basndose en el uso de lenguajes declarativos, sistemas expertos y redes neuronales. Como hemos visto, el software permite aplicaciones muy diversas, pero en todas ellas encontramos algo en comn: el objetivo es que el software determine una determinada funcin cumpliendo, a su vez, una serie de requisitos (fiabilidad, correccin, respuesta en un tiempo determinado, facilidad de uso, bajo coste, etctera) a la hora de desarrollar el software.

1.5. Problemas del software.

A lo largo del tiempo, ya hemos visto que el software ha sufrido lo que se llama crisis del software. Dicha crisis vino como consecuencia de los problemas surgidos al desarrollar un software de cierta complejidad y que hoy en da tambin existen sin que se haya avanzado mucho en los intentos por darle una solucin. Estos problemas son causados por las propias caractersticas del software y por los errores cometidos por quienes intervienen en su produccin. Entre ellos podemos citar:

La planificacin y la estimacin de costes son muy imprecisas.

Al comenzar un proyecto de cierta complejidad es frecuente que surjan imprevistos que no estaban recogidos en la planificacin inicial, y como consecuencia se producir un cambio en los costes del proyecto. Sin embargo, en el desarrollo del software lo ms frecuente es que la planificacin sea prcticamente inexistente, y que nunca se revise en el desarrollo del proyecto. Sin una planificacin detallada es imposible hacer una estimacin de costes que tenga alguna posibilidad de cumplirse, y tampoco pueden localizarse las tareas conflictivas que pueden desviar los

costes previstos. Entre las causas de este problema podemos citar: No se recogen datos sobre el desarrollo de proyectos anteriores, con lo que no se adquiere la experiencia que pueda ser utilizada en nuevos proyectos. Los gestores de los proyectos no estn especializados en la produccin de software. Es decir, de siempre los responsables del desarrollo del software han sido ejecutivos de medio y alto nivel sin conocimientos de informtica, por lo que, si bien es cierto que siempre se ha dicho que un buen gestor puede gestionar cualquier proyecto, no cabe duda que tambin es necesario conocer las caractersticas especficas del software, aprender las tcnicas que se aplican en su desarrollo y conocer una tecnologa que est en continua evolucin.

La productividad es baja.
Los proyectos software tienen, en general, mayor duracin de lo que en un principio se esperaba. Como consecuencia de ello los costes se disparan y la productividad y beneficios disminuyen. Un punto importante que influye es la falta de propsitos claros a la hora de comenzar el proyecto. La mayora del software se desarrolla a partir de unas especificaciones ambiguas e incorrectas sin existir una comunicacin con el cliente hasta la entrega del producto. Todo esto no lleva a frecuentes modificaciones de las especificaciones o los cambios de ltima hora, despus de la entrega al cliente. No se realiza un estudio detallado de estos cambios y la complejidad interna de las aplicaciones va creciendo hasta hacerse imposible de mantener y cada modificacin, por pequea que sea, es ms costosa y puede ocasionar el fallo de todo el sistema. Debido a la falta de documentacin sobre cmo se ha desarrollado el producto a que las continuas modificaciones han distorsionado el diseo actual, el mantenimiento del software puede llegar a ser una tarea imposible de realizar, pudiendo llevar ms tiempo realizar una modificacin sobre el programa ya escrito que analizarlo y desarrollarlo entero de nuevo.

La calidad es mala.
Dado que las especificaciones son ambiguas o incluso incorrectas, y que no se realizan pruebas exhaustivas, el software contiene numerosos errores cuando se entrega al cliente. Dichos errores ocasionan un fuerte incremento de costes durante el mantenimiento del proyecto cuando, en realidad, ya se esperaba que estuviese acabado. Recientemente se ha empezado a dar importancia a la prueba sistemtica y completa, surgiendo as nuevos conceptos como fiabilidad y garanta de calidad.

El cliente queda insatisfecho.

Debido al poco inters mostrado al anlisis de los requisitos del proyecto, la falta de comunicacin con el cliente durante el desarrollo y la existencia de numerosos errores en el producto que se entrega, los clientes quedan muy poco satisfechos con los resultados obtenidos. Esto da lugar a que las aplicaciones tengan que ser diseadas y desarrolladas de nuevo, que no lleguen nunca a utilizarse o que se produzca un cambio de proveedor a la hora de comenzar un nuevo proyecto.

2. DEFINICIN DE INGENIERA DEL SOFTWARE.

Desarrollar un sistema de software complejo no es algo que puede abordarse sin una preparacin previa. El hecho de abordar un proyecto de desarrollo de software como cualquier otro ha llevado a una serie de problemas que limitan nuestra capacidad de aprovechar los recursos que el hardware pone a nuestra disposicin. Los problemas que a lo largo de los aos han ido apareciendo no es algo que se va a solucionar en un corto

espacio de tiempo pero identificarlos y conocer sus causas es el nico mtodo que nos puede ayudar a solucionarlos. La combinacin de mtodos aplicables a cada una de las fases del desarrollo del software, la construccin de herramientas para automatizar estos mtodos, el uso de tcnicas para garantizar la calidad de los productos desarrollados y la coordinacin de todas las personas que intervienen en el desarrollo de un proyecto, har que se avance mucho en la solucin de estos problemas. De todo esto se encarga la disciplina llamada Ingeniera del Software. Una definicin concreta puede ser: El establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico, que sea fiable y funcione de manera eficiente sobre las mquinas. La ingeniera del software abarca un conjunto de tres elementos clave: mtodos, herramientas y procedimientos, que facilitan al gestor el control del proceso de desarrollo y suministran a los implementadores bases para construir de forma productiva software de alta calidad. Los mt odos indican cmo construir tcnicamente el software, abarcando amplias tareas de planificacin y estimacin de proyectos, anlisis de requisitos, diseo de estructuras de datos, programas y procedimientos, la codificacin, las pruebas y el mantenimiento. Las herramient as proporcionan un soporte automtico o semiautomtico para usar los mtodos. Existen herramientas para cada una de las fases anteriores y sistemas que integran las herramientas de cada fase de forma que sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE (Computer Assisted Software Engineering). Los proc edimient os definen la secuencia en que se aplican los mtodos, los documentos que requieren, los controles que aseguran la calidad y las directrices que permiten a los gestores evaluar los progresos.

3. EL CICLO DE VIDA DEL SOFTWARE.

Por ciclo de vida del software, entendemos la sucesin de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Estas etapas representan el ciclo de actividades involucradas en el desarrollo, uso y mantenimiento de sistemas de software, adems de llevar asociadas una serie de documentos que sern la salida de cada una de estas fases y servirn de entrada en la fase siguiente. Tales actividades son: A dopc in e ident if ic ac in del s is t ema : es importante conocer el origen del sistema, as como las motivaciones que impulsaron el desarrollo del sistema (por qu, para qu, etctera.). A nlis is de requerimient os : identificacin de las necesidades del cliente y los usuarios que el sistema debe satisfacer. E s pec if ic ac in : los requerimientos se realizan en un lenguaje ms formal, de manera que se pueda encontrar la funcin de correspondencia entre las entradas del sistema y las salidas que se supone que genera. Al estar completamente especificado el sistema, se pueden hacer estimaciones cuantitativas del coste, tiempos de diseo y asignacin de personal al sistema, as como la planificacin general del proyecto.

E s pec if ic ac in de la arquit ec t ura : define las interfaces de interconexin y recursos entre mdulos del sistema de manera apropiada para su diseo detallado y administracin. Dis eo : en esta etapa, se divide el sistema en partes manejables que, como anteriormente hemos dicho se llaman mdulos, y se analizan los elementos que las constituyen. Esto permite afrontar proyectos de muy alta complejidad. Des arrollo e implement ac in : codificacin y depuracin de la etapa de diseo en implementaciones de cdigo fuente operacional. Int egrac in y prueba del s of t ware : ensamble de los componentes de acuerdo a la arquitectura establecida y evaluacin del comportamiento de todo el sistema atendiendo a su funcionalidad y eficacia. Doc ument ac in : generacin de documentos necesarios para el uso y mantenimiento. E nt renamient o y us o : instrucciones y guas para los usuarios detallando las posibilidades y limitaciones del sistema, para su uso efectivo. Mant enimient o del s of t ware : actividades para el mantenimiento operativo del sistema. Se clasifican en: evolucin, conservacin y mantenimiento propiamente dicho. Existen diversos modelos de ciclo de vida, pero cada uno de ellos va asociado a unos mtodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto.

4. Modelos. 4.1. Clasificacin. 4.1.1. Modelos descriptivos vs. modelos prescriptivos.

Un modelo de ciclo de vida del software es una caracterizacin -descriptiva o prescriptiva- de la evolucin del software. Los modelos prescriptivos dictan pautas de cmo deberan desarrollarse los sistemas de software; por lo tanto son ms fciles de articular ya que los detalles del desarrollo pueden ser ignorados, generalizados, etc. Esto puede dejar dudas acerca de la validez y robustez de este tipo de modelos. Otra forma de encarar el desarrollo de un modelo es la forma descriptiva, la cual se basa en la observacin del desarrollo de sistemas reales. Son ms difciles de articular debido a dos razones fundamentales: La captura de datos es un proceso que puede tomar aos. Los modelos descriptivos son especficos a los sistemas observados y solamente generalizables a travs de anlisis sistemticos.

4.1.2. Modelos tradicionales vs. modelos evolutivos

Los modelos tradicionales focalizan su atencin en la direccin del cambio en trminos de progreso a travs de una serie de etapas que eventualmente conducen a alguna etapa final. Aunque este tipo de modelos son a menudo intuitivos y muy tiles para el establecimiento de marcos de

trabajo, administracin y seleccin de herramientas para el desarrollo de software, presentan serios problemas: Fallan para proveer un mecanismo adecuado que permita gobernar los cambios en el desarrollo del software. Plantea una organizacin muy poco realista que implica una secuencia uniforme y ordenada de actividades de desarrollo. La rigidez que este tipo de modelos impone a los procesos de desarrollo impide que el producto pueda adaptarse dinmicamente para satisfacer los requerimientos siempre cambiantes. Esto restringe la creatividad y la productividad. Son pobres predictores de por qu ciertos cambios son hechos a un sistema, y por qu los sistemas evolucionan de maneras similares o diferentes. Como una solucin a estos problemas surgieron nuevas propuestas que pueden agruparse bajo el nombre de modelos evolutivos. Los modelos evolutivos presentan las siguientes caractersticas: Existen tres orientaciones: centrados en el producto, centrados en los procesos y centrados en la administracin y organizacin del proceso. Focalizan la atencin en los mecanismos y procesos que cambian sistemas. Estn caracterizados por el diseo, desarrollo y despliegue de una capacidad inicial usando tecnologa actual que incluye previsin para la adicin evolutiva de futuras capacidades a medida que se definen nuevos requerimientos y que las tecnologas maduran. Estn menos interesados en la etapa de desarrollo que en los mecanismos tecnolgicos y procesos organizacionales que posibilitan el surgimiento de sistemas a travs del tiempo y del espacio.

4.2. Modelos de Ciclo de Vida del software. 4.2.1. Modelo Cascada.

El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de modelos de actividades de ingeniera con el fin de establecer algo de orden en el desarrollo de grandes productos de software. Consiste en diferentes etapas, las cuales son procesadas en una manera lineal. Comparado con otros modelos de desarrollo de software es ms rgido y mejor administrable. El modelo cascada es un modelo muy importante y ha sido la base de muchos otros modelos, sin embargo, para muchos proyectos modernos, ha quedado un poco desactualizado.

Descripcin del modelo

El modelo cascada es un modelo de ingeniera diseado para ser aplicado en el desarrollo de software. La idea principal es la siguiente: existen diferentes etapas de desarrollo, la salida de la primera etapa fluye hacia la segunda etapa y esta salida fluye hacia la tercera y as sucesivamente.

Existen generalmente cinco etapas en este modelo de desarrollo de software: A nlis is y def inic in de requerimient os : en esta etapa, se establecen los requerimientos del producto que se desea desarrollar. stos consisten usualmente en los servicios que debe proveer, limitaciones y metas del software. Una vez que se ha establecido esto, los requerimientos deben ser definidos en una manera apropiada para ser tiles en la siguiente etapa. Esta etapa incluye tambin un estudio de la factibilidad y viabilidad del proyecto con el fin de determinar la conveniencia de la puesta en marcha del proceso de desarrollo. Puede ser tomada como la concepcin de un producto de software y ser vista como el comienzo del ciclo de vida. Dis eo del s is t ema : el diseo del software es un proceso multipaso que se centra en cuatro atributos diferentes de los programas: estructura de datos, arquitectura del software, detalle del proceso y caracterizacin de las interfases. El proceso de diseo representa los requerimientos en una forma que permita la codificacin del producto (adems de una evaluacin de la calidad previa a la etapa de codificacin). Al igual que los requerimientos, el diseo es documentado y se convierte en parte del producto de software. Implement ac in : esta es la etapa en la cual son creados los programas. Si el diseo posee un nivel de detalle alto, la etapa de codificacin puede implementarse mecnicamente. A menudo suele incluirse un testeo unitario en esta etapa, es decir, las unidades de cdigo producidas son evaluadas individualmente antes de pasar a la etapa de integracin y testeo global. Tes t eo del s is t ema : una vez concluida la codificacin, comienza el testeo del programa. El proceso de testeo se centra en dos puntos principales: las lgicas internas del software; y las funcionalidades externas, es decir, se solucionan errores de comportamiento del software y se asegura que las entradas definidas producen resultados reales que coinciden con los requerimientos especificados.

Mant enimient o : esta etapa consiste en la correccin de errores que no fueron previamente detectados, mejoras funcionales y de performance, y otros tipos de soporte. La etapa de mantenimiento es parte del ciclo de vida del producto de software y no pertenece estrictamente al desarrollo. Sin embargo, mejoras y correcciones pueden ser consideradas como parte del desarrollo. Estas son las etapas principales. Tambin existen sub-etapas, dentro de cada etapa, pero stas difieren mucho de un proyecto a otro. Tambin es posible que ciertos proyectos de software requieran la incorporacin de una etapa extra o la separacin de una etapa en otras dos. Sin embargo, todas estas variaciones al modelo cascada poseen el mismo concepto bsico: la idea de que una etapa provee salidas que sern usadas como las entradas de la siguiente etapa (un flujo lineal entre las etapas). Por lo tanto, el progreso del proceso de desarrollo de un producto de software, usando el modelo cascada, es simple de conocer y controlar. Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo del software. stas son documentacin, verificacin y administracin. La documentacin es intrnseca al modelo cascada puesto que la mayora de las salidas que arrojan las etapas son documentos.

Problemas con el Modelo Cascada

El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado en la ingeniera del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada. Entre los problemas que aparecen cuando se aplica el modelo cascada estn: Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteracin siempre es necesaria y est presente, creando problemas en la aplicacin del modelo. A menudo es difcil para el cliente poder especificar todos los requerimientos explcitamente. El modelo de vida del software clsico requiere esto y presenta problemas acomodando la incertidumbre natural que existe al principio de cualquier proyecto. El cliente debe ser paciente. Una versin funcional del sistema no estar disponible hasta tarde en la duracin del desarrollo. Cualquier error o malentendido, si no es detectado hasta que el programa funcionando es revisado, puede ser desastroso. Cada uno de estos problemas es real. Sin embargo, el modelo clsico del ciclo de vida del software tiene un lugar bien definido e importante en los trabajos de ingeniera del software. Provee un patrn dentro del cual encajan mtodos para el anlisis, diseo, codificacin y mantenimiento.

Aplicacin
El modelo cascada se aplica bien en situaciones en las que el software es simple y en las que el dominio de requerimientos es bien conocido, la tecnologa usada en el desarrollo es accesible y los recursos estn disponibles.

4.2.2. Prototipado.
Dos de las crticas que se hacan al modelo de ciclo de vida en cascada eran que es difcil tener claros todos los requisitos del sistema al inicio del proyecto, y que no se dispone de una versin operativa del programa hasta las fases finales del desarrollo, lo que dificulta la deteccin de errores y deja tambin para el final el descubrimiento de los requisitos inadvertidos en las fases de anlisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de vida basado en la construccin de prototipos. En primer lugar, hay que ver si el sistema que tenemos que desarrollar es un buen candidato a utilizar el

paradigma de ciclo de vida de construccin de prototipos o al modelo en espiral. En general, cualquier aplicacin que presente mucha interaccin con el usuario, o que necesite algoritmos que puedan construirse de manera evolutiva, yendo de lo mas general a lo ms especfico es una buena candidata. No obstante, hay que tener en cuenta la complejidad: si la aplicacin necesita que se desarrolle una gran cantidad de cdigo para poder tener un prototipo que ensear al usuario, las ventajas de la construccin de prototipos se vern superadas por el esfuerzo de desarrollar un prototipo que al final habr que desechar o modificar mucho. Tambin hay que tener en cuenta la disposicin del cliente para probar un prototipo y sugerir modificaciones de los requisitos. Puede ser que el cliente no tenga tiempo para andar jugando o no vea las ventajas de este mtodo de desarrollo. Tambin es conveniente construir prototipos para probar la eficiencia de los algoritmos que se van a implementar, o para comprobar el rendimiento de un determinado componente del sistema en condiciones similares a las que existirn durante la utilizacin del sistema. Es bastante frecuente que el producto de ingeniera desarrollado presente un buen rendimiento durante la fase de pruebas realizada por los ingenieros antes de entregarlo al cliente pero que sea muy ineficiente, o incluso inviable, a la hora de almacenar o procesar el volumen real de informacin que debe manejar el cliente. En estos casos, la construccin de un prototipo de parte del sistema y la realizacin de pruebas de rendimiento, sirven para decidir, antes de empezar la fase de diseo, cul es el modelo ms adecuado de entre la gama disponible para el soporte hardware o cmo deben hacerse los accesos para obtener buenas respuestas en tiempo cuando la aplicacin est ya en funcionamiento. En otros casos, el prototipo servir para modelar y poder mostrar al cliente cmo va a realizarse la E/S de datos en la aplicacin, de forma que ste pueda hacerse una idea de como va a ser el sistema final, pudiendo entonces detectar deficiencias o errores en la especificacin aunque el modelo no sea ms que una cscara vaca. Segn esto un prototipo puede tener alguna de las tres formas siguientes: un prototipo, en papel o ejecutable en ordenador, que describa la interaccin hombre-mquina y los listados del sistema. un prototipo que implemente algn(os) subconjunto(s) de la funcin requerida, y que sirva para evaluar el rendimiento de un algoritmo o las necesidades de capacidad de almacenamiento y velocidad de clculo del sistema final. un programa que realice en todo o en parte la funcin deseada pero que tenga caractersticas (rendimiento, consideracin de casos particulares, etc.) que deban ser mejoradas durante el desarrollo del proyecto. La secuencia de tareas del paradigma de construccin de prototipos puede verse en la siguiente figura.

Si se ha decidido construir un prototipo, lo primero que hay que hacer es realizar un modelo del sistema, a partir de los requisitos que ya conozcamos. En este caso no es necesario realizar una definicin completa de los requisitos, pero s es conveniente determinar al menos las reas donde ser necesaria una definicin posterior ms detallada. Luego se procede a disear el prototipo. Se tratar de un diseo rpido, centrado sobre todo en la arquitectura del sistema y la definicin de la estructura de las interfaces ms que en aspectos de procedimiento de los programas: nos fijaremos ms en la forma y en la apariencia que en el contenido. A partir del diseo construiremos el prototipo. Existen herramientas especializadas en generar prototipos ejecutables a partir del diseo. Otra opcin sera utilizar tcnicas de cuarta generacin. La posibilidad ms reciente consiste en el uso de especificaciones formales, que faciliten el desarrollo incremental de especificaciones y permitan la prueba de estas especificaciones. En cualquier caso, el objetivo es siempre que la codificacin sea rpida, aunque sea en detrimento de la calidad del software generado. Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y sugiera modificaciones. En este punto el cliente puede ver una implementacin de los requisitos que ha definido inicialmente y sugerir las modificaciones necesarias en las especificaciones para que satisfagan mejor sus necesidades. A partir de estos comentarios del cliente y los cambios que se muestren necesarios en los requisitos, se proceder a construir un nuevo prototipo y as sucesivamente hasta que los requisitos queden totalmente formalizados, y se pueda entonces empezar con el desarrollo del producto final. Por tanto, el prototipado es una tcnica que sirve fundamentalmente para la fase de anlisis de requisitos, pero lleva consigo la obtencin de una serie de subproductos que son tiles a lo largo del desarrollo del proyecto:

Gran parte del trabajo realizado durante la fase de diseo rpido (especialmente la definicin de pantallas e informes) puede ser utilizada durante el diseo del producto final. Adems, tras realizar varias vueltas en el ciclo de construccin de prototipos, el diseo del mismo se parece cada vez ms al que tendr el producto final. Durante la fase de construccin de prototipos ser necesario codificar algunos componentes del software que tambin podrn ser reutilizados en la codificacin del producto final, aunque deban de ser optimizados en cuanto a correccin o velocidad de procesamiento. No obstante, hay que tener en cuenta que el prototipo no es el sistema final, puesto que normalmente apenas es utilizable. Ser demasiado lento, demasiado grande, inadecuado para el volumen de datos necesario, contendr errores (debido al diseo rpido), ser demasiado general (sin considerar casos particulares, que debe tener en cuenta el sistema final) o estar codificado en un lenguaje o para una mquina inadecuadas, o a partir de componentes software previamente existentes. No hay que preocuparse de haber desperdiciado tiempo o esfuerzos construyendo prototipos que luego habrn de ser desechados, si con ello hemos conseguido tener ms clara la especificacin del proyecto, puesto que el tiempo perdido lo ahorraremos en las fases siguientes, que podrn realizarse con menos esfuerzo y en las que se cometern menos errores que nos obliguen a volver atrs en el ciclo de vida. Hay que tener en cuenta que un anlisis de requisitos incorrecto o incompleto, cuyos errores y deficiencias se detecten a la hora de las pruebas o tras entregar el software al cliente, nos obligar a repetir de nuevo las fases de anlisis, diseo y codificacin, que habamos realizado cuidadosamente, pensando que estbamos desarrollando el producto final. Al tener que repetir estas fases, s que estaremos desechando una gran cantidad de trabajo, normalmente muy superior al esfuerzo de construir un prototipo basndose en un diseo rpido, en la reutilizacin de trozos de software preexistentes y en herramientas de generacin de cdigo para informes y manejo de ventanas. Uno de los problemas que suelen aparecer siguiendo el paradigma de construccin de prototipos, es que con demasiada frecuencia el prototipo pasa a ser parte del sistema final, bien sea por presiones del cliente, que quiere tener el sistema funcionando lo antes posible o bien porque los tcnicos se han acostumbrado a la mquina, el sistema operativo o el lenguaje con el que se desarroll el prototipo. Se olvida aqu que el prototipo ha sido construido de forma acelerada, sin tener en cuenta consideraciones de eficiencia, calidad del software o facilidad de mantenimiento, o que las elecciones de lenguaje, sistema operativo o mquina para desarrollarlo se han hecho basndose en criterios como el mejor conocimiento de esas herramientas por parte los tcnicos que en que sean adecuadas para el producto final. El utilizar el prototipo en el producto final conduce a que ste contenga numerosos errores latentes, sea ineficiente, poco fiable, incompleto o difcil de mantener. En definitiva a que tenga poca calidad, y eso es precisamente lo que se quiere evitar aplicando la ingeniera del software.

4.2.3. Espiral.
El problema con los modelos de procesos de software es que no se enfrentan lo suficiente con la incertidumbre inherente a los procesos de software. Importantes proyectos de software fallaron porque los riegos del proyecto se despreciaron y nadie se prepar para algn imprevisto. Boehm reconoci esto y trat de incorporar el factor riesgo del proyecto al modelo de ciclo de vida, agregndoselo a las mejores caractersticas de los modelos Cascada y Prototipado. El resultado fue el Modelo Espiral. La direccin del nuevo modelo fue incorporar los puntos fuertes y evitar las dificultades de otros modelos desplazando el nfasis de administracin hacia la evaluacin y resolucin del riesgo. De esta manera se permite tanto a los desarrolladores como a los clientes detener el proceso cuando se lo considere conveniente.

Descripcin del modelo

Bsicamente, la idea es desarrollo incremental usando el modelo Cascada para cada paso, ayudando a administrar los riesgos. No se define en detalle el sistema completo al principio; los diseadores deberan definir e implementar solamente los rasgos de mayor prioridad. Con el conocimiento adquirido, podran entonces volver atrs y definir e implementar ms caractersticas en trozos ms pequeos. El modelo Espiral define cuatro actividades principales en su ciclo de vida: Planeamiento: determinacin de los objetivos, alternativas y limitaciones del proyecto. Anlisis de riesgo: anlisis de alternativas e identificacin y solucin de riesgos. Ingeniera: desarrollo y testeo del producto. Evaluacin del cliente: tasacin de los resultados de la ingeniera. El modelo est representado por una espiral dividida en cuatro cuadrantes, cada una de las cuales representa una de las actividades arriba mencionadas.

Puntos fuertes
Evita las dificultades de los modelos existentes a travs de un acercamiento conducido por el riesgo.

Intenta eliminar errores en las fases tempranas. Es el mismo modelo para el desarrollo y el mantenimiento. Provee mecanismos para la aseguracin de la calidad del software. La reevaluacin despus de cada fase permite cambios en las percepciones de los usuarios, avances tecnolgicos o perspectivas financieras. La focalizacin en los objetivos y limitaciones ayuda a asegurar la calidad.

Puntos dbiles
Falta un proceso de gua explcito para determinar objetivos, limitaciones y alternativas. Provee ms flexibilidad que la conveniente para la mayora de las aplicaciones. La pericia de tasacin del riesgo no es una tarea fcil. El autor declara que es necesaria mucha experiencia en proyectos de software para realizar esta tarea exitosamente.

Aplicacin
Proyectos complejos, dinmicos, innovadores, ambiciosos, llevados a cabo por equipos internos (no necesariamente de software).

4.2.4. Cleanroom
Cleanroom es un proceso de administracin e ingeniera para el desarrollo de software de alta calidad con fiabilidad certificada. Focaliza la atencin en la prevencin en lugar de la correccin de errores, y la certificacin de la fiabilidad del software para el entorno de uso para cual fue planeado. En lugar de realizar pruebas de unidades y mdulos, se especifican formalmente componentes de software los cuales son verificados matemticamente en cuanto son construidos.

Descripcin del modelo

A continuacin se muestra una figura donde se esquematiza el modelo:

El modelo tiene las siguientes caractersticas: Desarrollo incremental: el software es particionado en incrementos los cuales se desarrollan utilizando el proceso cleanroom. Especificacin formal: el software a desarrollarse es formalmente especificado. Verificacin esttica: el software desarrollado es verificado matemticamente (los desarrolladores no pueden ejecutar el cdigo) utilizando argumentos de correctitud basados en matemticas. No hay pruebas a nivel unidad o mdulo. Pruebas estadsticas: el incremento de software integrado es examinado estadsticamente para determinar su fiabilidad. Hay tres equipos involucrados en el proceso de cleanroom: El equipo de especificacin: este equipo es responsable del desarrollo y mantenimiento de las especificaciones del sistema. Ambas especificaciones, las orientadas al cliente. El equipo de desarrollo: este equipo tiene la responsabilidad de desarrollar y verificar el software. El equipo de certificacin: este equipo es responsable del desarrollo de un conjunto de pruebas estadsticas para ejercitar el software una vez que fue construido. Con respecto a los equipos, estos deben ser pequeos: tpicamente de seis a ocho integrantes. El testeo del software debe ser llevado a cabo por un equipo independiente.

Ventajas del uso de Cleanroom

Cleanroom provee las prcticas de administracin e ingeniera que permiten a los equipos lograr cero fallos en el campo de uso, cortos ciclos de desarrollo, y una larga vida del producto. Reduce los fallos encontrados durante el proceso de certificacin a menos de cinco fallos por cada mil lneas de cdigo en la primera ejecucin del cdigo del primer proyecto. Equipos nuevos deberan experimentar un incremento del doble en la productividad con respecto a su primer proyecto. La productividad seguir incrementndose con la experiencia adquirida. Cleanroom lleva a una inversin en bienes tales como especificaciones detalladas y modelos que ayudan a mantener un producto viable durante una vida ms larga. Todos los beneficios tcnicos se trasladan en beneficios econmicos significantes.

Aplicacin
El mtodo cleanroom es mandatorio para cualquier sistema de software de misin crtica; sin embargo es apto para cualquier proyecto de software, en especial si el proyecto requiere deteccin de errores en fases tempranas.

5. Conclusin. 5.1. Comparacin entre los modelos.

La siguiente tabla muestra una comparacin entre los cuatro modelos ms utilizados:

Criterio Disponibilidad de recursos Complejidad del proyecto Entendimiento de los requerimientos Tecnologa del producto Volatilidad de requerimientos Manejo de la perspectiva del riesgo Conocimiento del dominio del problema 5.2. Combinaciones.

Cascada Todos Baja Especfico Vieja No No Alto

Prototipado Algunos Media Vago Nueva Si Si Regular

Cleanroom Algunos Alta Vago Nueva Si No Alto

Espiral Algunos Alta Vago Nueva Si Si Pobre

Los mtodos presentados tienen un campo de aplicacin bien definido; sin embargo, los problemas reales con los que un equipo de desarrollo puede enfrentarse no calzan de manera perfecta en los dominios para los cuales los mtodos fueron pensados. Es tarea de los ingenieros adaptar un mtodo o componer uno nuevo a partir de los mtodos existentes para conseguir una solucin que se amolde al problema en particular que se est atacando. En definitiva, es el problema el que propone la solucin (o al menos el camino a la solucin).

Conclusiones.
Independientemente del paradigma que se utilice, del rea de aplicacin, y del tamao y la complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de fases genricas, existentes en todos los paradigmas. Estas fases son la definicin, el desarrollo y el mantenimiento.

Definicin.
La fase de definicin se centra en el qu . Durante esta fase, se intenta identificar: qu informacin es la que tiene que ser procesada. qu funcin y rendimiento son los que se esperan. qu restricciones de diseo existen. qu interfaces deben utilizarse. qu lenguaje de programacin, sistema operativo y soporte hardware van a ser utilizados. qu criterios de validacin se necesitan para conseguir que el sistema final sea correcto. Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarn tres tareas especficas:

Anlisis del sistema.

El anlisis del sistema define el papel de cada elemento de un sistema informtico, estableciendo cul es el

papel del software dentro de ese sistema.

Anlisis de requisitos del software.

El anlisis del sistema proporciona el mbito del software, su relacin con el resto de componentes del sistema, pero antes de empezar a desarrollar es necesario hacer una definicin ms detallada de la funcin del software. Existen dos formas de realizar el anlisis y refinamiento de los requisitos del software. Por una parte, se puede hacer un anlisis formal del mbito de la informacin para establecer modelos del fujo y la estructura de la informacin. Luego se amplan unos modelos para convertirlos en una especificacin del software. La otra alternativa consiste en construir un prototipo del software, que ser evaluado por el cliente para intentar consolidar los requisitos. Los requisitos de rendimiento y las limitaciones de recursos se traducen en directivas para la fase de diseo. El anlisis y definicin de los requisitos es una tarea que debe llevarse a cabo conjuntamente por el desarrollador de software y por el cliente. La especificacin de requisitos del software es el documento que se produce como resultado de esta etapa.

Planificacin del proyecto software.

Durante esta etapa se lleva a cabo el anlisis de riesgos, se definen los recursos necesarios para desarrollar el software y se establecen las estimaciones de tiempo y costes. El propsito de esta etapa de planificacin es proporcionar una indicacin preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan establecido. Posteriormente, la gestin del proyecto durante el desarrollo del mismo realiza y revisa el plan de proyecto de software.

Desarrollo.
La fase de definicin se centra en el c mo . cmo ha de ser la arquitectura de la aplicacin. cmo han de ser las estructuras de datos. cmo han de implementarse los detalles de procedimiento de los mdulos. cmo van a ser los interfaces. cmo ha de traducirse el diseo a un lenguaje de programacin. cmo van a realizarse las pruebas. Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarn cuatro tareas especficas:

Diseo.
El diseo del software traduce los requisitos a un conjunto de representaciones (grficas, en forma de tabla o basadas en algn lenguaje apropiado) que describen cmo van a estructurarse los datos, cul va a ser la arquitectura de la aplicacin, cul va a ser la estructura de cada programa y cmo van a ser las interfaces. Es

necesario seguir criterios de diseo que nos permitan asegurar la calidad del producto. Una vez finalizado el diseo es necesario revisarlo para asegurar la completitud y el cumplimiento de los requisitos del software.

Codificacin.
En esta fase, el diseo se traduce a un lenguaje de programacin, dando como resultado un programa ejecutable. La buena calidad de los programas desarrollados depende en gran medida de la calidad del diseo. Una vez codificados los programas debe revisarse su estilo y claridad, y se comprueba que haya una correspondencia con la estructura de los mismos definida en la fase de diseo. El listado fuente de cada mdulo (o el programa fuente en soporte magntico) pasa a formar parte de la configuracin del sistema.

Pruebas.
Una vez que tenemos implementado el software es preciso probarlo, para detectar errores de codificacin, de diseo o de especificacin. Las pruebas son necesarias para encontrar el mayor nmero posible de errores antes de entregar el programa al cliente. Es necesario probar cada uno de los componentes por separado (cada uno de los mdulos o programas) para comprobar el rendimiento funcional de cada una de estas unidades. A continuacin se procede a integrar los componentes para probar toda la arquitectura del software, y probar su funcionamiento y las interfaces. En este punto hay que comprobar si se cumplen todos los requisitos de la especificacin. Se puede desarrollar un plan y procedimiento de pruebas y guardar informacin sobre los casos de pruebas y los resultados de las mismas.

Garanta de calidad.
Una vez terminada la fase de pruebas, el software est casi preparado para ser entregado al cliente.

Mantenimiento.
La fase de mantenimiento se centra en los cambios que va a sufrir el software a lo largo de su vida til. Como ya hemos dicho, estos cambio pueden deberse a la correccin de errores, a cambios en el entorno inmediato del software o a cambios en los requisitos del cliente, dirigidos normalmente a ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y de desarrollo, pero en el contexto de un software ya existente y en funcionamiento.

BIBLIOGRAFA http://243.sip.ucm.es/is/intro.html http://www.centersoft.co.cu/Desasoft.htm

http://members.tripod.cl/RuthGarrido/ingsof/cap2-4.html http://www.reduaeh.mx/presenta/univirtual/notas_2.htm