INTRODUCCIN

El proceso del software ha sido el foco de atencin de la ultima dcada dentro de ello definimos un marco de trabajo de las tareas que se requieren para construir software de alta calidad en donde los modelos tradicionales debern ser escogidos eficazmente para obtener un producto que cumpla con todas las expectativas del usuario final. No hay un solo modelo de desarrollo de software libre, igual que no hay un solo modelo de desarrollo de software propietario. De hecho, continuamente se estn experimentando nuevas ideas, que tratan de aprovechar alguna caracterstica de algn programa en cuestin, de la comunidad a la que va dirigido, o del propio hecho de ser software libre. En el desarrollo del presente trabajo ponemos ha consideracin diferentes modelos tradicionales para el desarrollo de software.

Objetivo:
Conocer las ventajas que nos ofrecen los diferentes modelos tradicionales de desarrollo de software.

MODELOS TRADICIONALES DE DESARROLLO DE SOFTWARE

El proceso de software es un conjunto estructurado de actividades para, especificar, disear, implementar, y probar sistemas software. Y es necesario utilizar diferente modelos para este proceso, los cuales son una representacin abstracta y representan una descripcin desde una perspectiva particular. MODELO ESPIRAL El modelo en espiral propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que acompaa la naturaleza interactiva de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Caractersticas: En este modelo el software se desarrollo en una serie de versiones incrementales.

Cada uno de los bucles representa una fase en el proceso. No hay fases fijas (tales como especificacin o diseo). Los bucles de la espiral se eligen dependiendo de lo que se vaya necesitando. Los riesgos se evalan explcitamente y se resuelven a lo largo del proceso.
El modelo es espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas, por lo general existen entre 3 y 6 regiones de tareas. Se utiliza para proyectos grandes. Las regiones de tareas se adaptan a las caractersticas del proyecto que va ha emprenderse.

El seguimiento ha realizarse es en direccin a las manecillas del reloj comenzando por el centro.

Regiones de tareas
Comunicacin con el cliente: Establece comunicacin entre el desarrollador y el cliente. Planificacin: Define el recurso el tiempo y otras informaciones relacionadas con el proyecto. Anlisis de Riesgos: evala riesgos tcnicos y de gestin. Ingeniera: construyen una o mas representaciones de la aplicacin. Construccin y Adaptacin: permiten construir, probar, instalar y proporcionar soporte al usuario. Ejemplo documento y practica. Evaluacin del cliente: obtiene la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin. MODELO DE DESARROLLO CONCURRENTE Este modelo se lo puede representar como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas. Caractersticas Define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades en la ingeniera de software.

Se utiliza a menudo como el paradigma de desarrollo de aplicaciones Cliente/Servidor. Cuando se aplica a Cliente/Servidor, este modelo define actividades en dos dimensiones: una dimensin de sistemas y una dimensin de componentes. Es aplicable aplicable a todo tipo de desarrollo de software, proporciona una imagen exacta del estado actual de un proyecto, define una red de actividades. Todas las actividades existen concurrentemente pero residen en estados diferentes.

Representacin Esquemtica

Ninguna.- Empieza la comunicacin con el cliente Bajo Desarrollo.- Es un estado de transicin que depende de los requerimientos del usuario . Cambios en Espera.- depender exclusivamente de las transiciones de bajo desarrollo e involucra los cambios requeridos por el usuario. Bajo Revisin.- Es el estado en el que se revisa el impacto de los cambios efectuados. En Lnea Base.- Resultados preliminares. Hecho.- Estado de verificacin. MODELO DE CONSTRUCCIN DE PROTOTIPOS Este modelo esta enfocado a crear resultados preliminares llamados prototipos o conocidos como un primer Sistema, la construccin de prototipos puede ser un

paradigma dentro de la ingeniera del software. La clave es seguir las reglas del juego al comienzo. Caractersticas El prototipo lo evala el cliente y el usuario, lo utiliza para refinar los requisitos del software final. El paradigma de construccin de prototipo comienza con la recoleccin de requisitos El diseo rpido lleva a la construccin de un prototipo. La interaccin ocurre una ves satisfecha las necesidades del cliente El desarrollador a menudo hace compromisos de implementacin para hacer que el prototipo funcione rpidamente. Gestin del proyecto es lenta. Representacin Esquemtica

Escuchar al cliente.- El desarrollador y el cliente encuentran y definen los objetivos globales para el software . Contruir/Revisar Maqueta.objetivos iniciales Elaboracin del primer sistema, verificacin de

El Cliente prueba la maqueta .- El ciente utiliza el prototipo entregado y de existir fallas se inicializa nuevamente el proceso.

MODELO DE ENSAMBLAJE DE COMPONENTES

En este modelo se incorpora muchas de las caractersticas del modelo en espiral, es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Caractersticas: Configura aplicaciones desde componentes preparados de software, algunas veces llamados clases. La actividad de la ingeniera comienza con la identificacin de clases cantidatas. Los datos y algoritmos correspondientes se empaquetas en una sola clase. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables. Las clases creadas se almacenan en una biblioteca de clases o deposito. El flujo del proceso vuelve a la espirar y volver a introducir por ultimo la interaccin ensambladora de componentes a travs de la actividad de ingeniera. Esta modelo lleva a la reutilizacin del software, donde proporciona beneficios. El proceso para la implementacin de este modelo es en direccin a las manecillas del reloj, comenzando desde el centro.

Representacin Esquemtica Comunicacin con el Cliente.- recoleccin de informacin.

Planificacin.- ordenacin dela informacin para el desarrollo de un sistema informatico. Anlisis de Riesgos.- identificacin de los riesgos en el transcurso del desarrollo del proyecto. En esta fase se realiza un esquema jerrquico a parte. Construccin y Adaptacin de la Ingenieria.software. Implementacin del producto

Evaluacin del Cliente.- los resultados de nuestro sistema informatico debe satisfaces las necesidades del usuario MODELO EVOLUTIVO Desarrollo explorativo El objetivo es trabajar con el cliente y hacer evolucionar un sistema final a partir de un esbozo de una especificacin inicial. El desarrollo comienza con aquellas partes mejor

Comprendidas del sistema Prototipado El objetivo es comprender los requerimientos del sistema. El prototipo se centra en aquellas partes que el cliente tiene "poco claras"

MODELO FORMAL DE SISTEMAS Basados en la transformacin de una especificacin matemtica a travs de diferentes representaciones hasta obtener un programa ejecutable Las transformaciones preservan la correccin de las especificaciones. Esto es importante para mostrar que el programa cumple con sus especificaciones

MODELOS QUE UTILIZAN LA REUTILIZACIN Basados en la reutilizacin sistemtica. Los sistemas se integran a partir de componentes existentes: Etapas del proceso
Anlisis de componentes Modificacin de requerimientos Diseo del sistema con reutilizacin Desarrollo e integracin

Esta aproximacin tiene cada vez ms importancia, aunque no se tiene mucha experiencia en ella

El Ciclo de Vida en Cascada o Clsico

Este paradigma es el ms antiguo de los empleados en la IS y se desarroll a partir del ciclo convencional de una ingeniera. No hay que olvidar que la IS surgi como copia de otras ingenieras, especialmente de las del hardware, para dar solucin a los problemas ms comunes que aparecan al desarrollar sistemas de software complejos. Es un ciclo de vida en sentido amplio, que incluye no slo las etapas de ingeniera sino toda la vida del producto: las pruebas, el uso (la vida til del software) y el mantenimiento, hasta que llega el momento de sustituirlo.

Ciclo de vida en cascada. Caractersticas El ciclo de vida en cascada exige un enfoque sistemtico y secuencial del desarrollo de software, que comienza en el nivel de la ingeniera de sistemas y avanza a travs de fases secuenciales sucesivas. Estas fases son las siguientes: Ingeniera y anlisis del sistema. El primer paso del ciclo de vida de un proyecto consiste en un anlisis de las caractersticas y el comportamiento del sistema del cual el software va a formar parte. En el caso de que queramos construir un sistema nuevo, por ejemplo un sistema de control, deberemos analizar cules son los requisitos y la funcin del sistema, y luego asignaremos un subconjunto de estos requisitos al software. En el caso de un sistema ya existente (supongamos, por ejemplo, que queremos informatizar una empresa) deberemos analizar el funcionamiento de la misma, las

operaciones que se llevan a cabo en ella, y asignaremos al software aquellas funciones que vamos a automatizar. Anlisis de requisitos del software. El anlisis de requisitos debe ser ms detallado para aquellos componentes del sistema que vamos a implementar mediante software. El ingeniero del software debe comprender cules son los datos que se van a manejar, cul va a ser la funcin que tiene que cumplir el software, cules son los interfaces requeridos y cul es el rendimiento que se espera lograr. Los requisitos, tanto del sistema como documentarse y revisarse con el cliente. Diseo. El diseo se aplica a cuatro caractersticas distintas del software: la estructura de los datos, la arquitectura de las aplicaciones, la estructura interna de los programas y las interfaces. El diseo es el proceso que traduce los requisitos en una representacin del software de forma que pueda conocerse la arquitectura, funcionalidad e incluso la calidad del mismo antes de comenzar la codificacin. Codificacin. La codificacin consiste en la traduccin del diseo a un formato que sea legible para la mquina. Si el diseo es lo suficientemente detallado, la codificacin es relativamente sencilla, y puede hacerse - al menos en parte - de forma automtica, usando generadores de cdigo. Prueba. Una vez que ya tenemos el programa ejecutable, comienza la fase de pruebas. El objetivo es comprobar que no se hayan producido errores en alguna de las fases de traduccin anteriores, especialmente en la codificacin. Para ello deben probarse todas las sentencias, no slo los casos normales y todos los mdulos que forman parte del sistema. Utilizacin. Una vez superada la fase de pruebas, el software se entrega al cliente y comienza la vida til del mismo. La fase de utilizacin se solapa con las del software deben

posteriores - el mantenimiento y la sustitucin - y dura hasta que el software, ya reemplazado por otro, deje de utilizarse. Mantenimiento. El software sufrir cambios a lo largo de su vida til. Estos cambios pueden ser debidos a tres causas: Que, durante la utilizacin, el cliente detecte errores en el software: los errores latentes. Que se produzcan cambios en alguno de los componentes del sistema informtico: por ejemplo cambios en la mquina, en el sistema operativo o en los perifricos. Que el cliente requiera modificaciones funcionales (normalmente ampliaciones) no contempladas en el proyecto. Sustitucin. La vida del software no es ilimitada y cualquier aplicacin, por buena que sea, acaba por ser sustituida por otra ms amplia, ms rpida o ms bonita y fcil de usar. La sustitucin de un software que est funcionando por otro que acaba de ser desarrollado es una tarea que hay que planificar cuidadosamente y que hay que llevar a cabo de forma organizada. Es conveniente realizarla por fases, si esto es posible, no sustituyendo todas las aplicaciones de golpe, puesto que la sustitucin conlleva normalmente un aumento de trabajo para los usuarios, que tienen que acostumbrarse a las nuevas aplicaciones, y tambin para los implementadores, que tienen que corregir los errores que aparecen. La sustitucin implica el desarrollo de programas para la interconexin de ambos sistemas, el viejo y el nuevo, y para trasvasar la informacin entre ambos, evitando la duplicacin del trabajo de las personas encargadas del proceso de datos, durante el tiempo en que ambos sistemas funcionen en paralelo. Fortalezas Suministra una plantilla en la que pueden colocarse los mtodos para el anlisis, diseo, codificacin, prueba y mantenimiento. Facilitar el desarrollo de proyectos de software de gran volumen, con especificaciones, requerimientos y funcionalidades customizables. Este modelo hizo que los desarrolladores dispusieran del tiempo suficiente para completar, examinar e implementar el software antes de entregrselo a los clientes, detalla el informe.

Debilidades El modelo en cascada, a pesar de ser lineal, contiene flujos que permiten la vuelta atrs. As, desde el mantenimiento se vuelve al anlisis, el diseo o la codificacin, y tambin desde cualquier fase se puede volver a la anterior si se detectan fallos. Estas vueltas atrs no son controladas, ni quedan

explcitas en el modelo, y este es uno de los problemas que presenta este paradigma En realidad los proyectos no siguen un ciclo de vida estrictamente secuencial como propone el modelo. Siempre hay iteraciones. El ejemplo ms tpico es la fase de mantenimiento, que implica siempre volver a alguna de las fases anteriores, pero tambin es muy frecuente en que una fase, por ejemplo el diseo, se detecten errores que obliguen a volver a la fase anterior, el anlisis. Es difcil que se puedan establecer inicialmente todos los requisitos del sistema. Normalmente los clientes no tienen conocimiento de la importancia de la fase de anlisis o bien no han pensado en todo detalle que es lo que quieren que haga el software. Los requisitos se van aclarando y refinando a lo largo de todo el proyecto, segn se plantean dudas concretas en el diseo o la codificacin. Sin embargo, el ciclo de vida clsico requiere la definicin inicial de todos los requisitos y no es fcil acomodar en l las incertidumbres que suelen existir al comienzo de todos los proyectos. Hasta que se llega a la fase final del desarrollo: la codificacin, no se dispone de una versin operativa del programa. Como la mayor parte de los errores se detectan cuando el cliente puede probar el programa no se detectan hasta el final del proyecto, cuando son ms costosos de corregir y ms prisa (y ms presiones) hay por que el programa se ponga definitivamente en marcha.

CONCLUSIONES: Los modelos de software son muy importantes e indispensables obtener un software de calidad. para

Todos los modelos de desarrollo de software tienen que ser escogidos adecuadamente, de acuerdo al tipo de proyecto para evitar errores, costos altos y prdida de recursos. El modelo de prototipos permite un desarrollo rpido del software. Todos los modelos exhiben ventajas e inconvenientes pero todos tienen una serie de fases genricas en comn El modelo concurrente es aplicable a todo tipo de desarrollo de software, proporciona una imagen exacta del estado actual de un proyecto.

RECOMENDACION: Tener conocimiento terico y prctico acerca de todos los modelos de desarrollo de software para con ello poder escoger el modelo apropiado que satisfaga las necesidades del usuario al que va dirigido.