INTRODUCCIÓN

El proceso del software ha sido el foco de atención de la ultima década 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 deberán 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 están experimentando nuevas ideas, que tratan de aprovechar alguna característica de algún programa en cuestión, de la comunidad a la que va dirigido, o del propio hecho de ser software libre. En el desarrollo del presente trabajo ponemos ha consideración diferentes modelos tradicionales para el desarrollo de software.

también llamadas regiones de tareas. • • .Objetivo: Conocer las ventajas que nos ofrecen los diferentes modelos tradicionales de desarrollo de software. por lo general existen entre 3 y 6 regiones de tareas. Se utiliza para proyectos grandes. • El modelo es espiral se divide en un número de actividades estructurales. implementar. Los bucles de la espiral se eligen dependiendo de lo que se vaya necesitando. los cuales son una representación abstracta y representan una descripción desde una perspectiva particular. es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. • No hay fases fijas (tales como especificación o diseño). Las regiones de tareas se adaptan a las características del proyecto que va ha emprenderse. especificar. • Cada uno de los bucles representa una fase en el proceso. Características: • En este modelo el software se desarrollo en una serie de versiones incrementales. y probar sistemas software. diseñar. Y es necesario utilizar diferente modelos para este proceso. • Los riesgos se evalúan explícitamente y se resuelven a lo largo del proceso. MODELO ESPIRAL El modelo en espiral propuesto originalmente por Boehm. MODELOS TRADICIONALES DE DESARROLLO DE SOFTWARE El proceso de software es un conjunto estructurado de actividades para.

tareas y estados asociados a ellas. Construcción y Adaptación: permiten construir. probar. Es aplicable aplicable a todo tipo de desarrollo de software. proporciona una imagen exacta del estado actual de un proyecto. instalar y proporcionar soporte al usuario.• El seguimiento ha realizarse es en dirección a las manecillas del reloj comenzando por el centro. MODELO DE DESARROLLO CONCURRENTE Este modelo se lo puede representar como una serie de actividades técnicas importantes. . Análisis de Riesgos: evalúa riesgos técnicos y de gestión. Planificación: Define el recurso el tiempo y otras informaciones relacionadas con el proyecto. Características • Define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades en la ingeniería de software. Cuando se aplica a Cliente/Servidor. Todas las actividades existen concurrentemente pero residen en estados diferentes. Ejemplo documento y practica. define una red de actividades. • • • • Se utiliza a menudo como el paradigma de desarrollo de aplicaciones Cliente/Servidor. Regiones de tareas Comunicación con el cliente: Establece comunicación entre el desarrollador y el cliente. este modelo define actividades en dos dimensiones: una dimensión de sistemas y una dimensión de componentes. Ingeniería: construyen una o mas representaciones de la aplicación. Evaluación del cliente: obtiene la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

Estado de verificación..Es el estado en el que se revisa el impacto de los cambios efectuados.dependerá exclusivamente de las transiciones de bajo desarrollo e involucra los cambios requeridos por el usuario. la construcción de prototipos puede ser un .Empieza la comunicación con el cliente Bajo Desarrollo.. Cambios en Espera. En Línea Base.Resultados preliminares..Es un estado de transición que depende de los requerimientos del usuario ...Representación Esquemática Ninguna. Hecho.. MODELO DE CONSTRUCCIÓN DE PROTOTIPOS Este modelo esta enfocado a crear resultados preliminares llamados prototipos o conocidos como un primer Sistema. Bajo Revisión.

paradigma dentro de la ingeniería del software.El desarrollador y el cliente encuentran y definen los objetivos globales para el software . La clave es seguir las reglas del juego al comienzo. .. Características • El prototipo lo evalúa el cliente y el usuario. • El paradigma de construcción de prototipo comienza con la recolección de requisitos • El diseño rápido lleva a la construcción de un prototipo. lo utiliza para refinar los requisitos del software final. Representación Esquemática Escuchar al cliente. • Gestión del proyecto es lenta.objetivos iniciales Elaboración del “primer sistema”. verificación de El Cliente prueba la maqueta ..El ciente utiliza el prototipo entregado y de existir fallas se inicializa nuevamente el proceso. • La interacción ocurre una ves satisfecha las necesidades del cliente • El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente. Contruir/Revisar Maqueta.

La actividad de la ingeniería comienza con la identificación de clases cantidatas. El flujo del proceso vuelve a la espirar y volverá a introducir por ultimo la interacción ensambladora de componentes a través de la actividad de ingeniería. algunas veces llamados “clases”. Las clases creadas se almacenan en una biblioteca de clases o deposito. las clases orientadas a objetos son reutilizables. Representación Esquemática Comunicación con el Cliente. comenzando desde el centro.recolección de información.MODELO DE ENSAMBLAJE DE COMPONENTES En este modelo se incorpora muchas de las características del modelo en espiral.. . Los datos y algoritmos correspondientes se empaquetas en una sola clase. El proceso para la implementación de este modelo es en dirección a las manecillas del reloj. es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Si se diseñan y se implementan adecuadamente. donde proporciona beneficios. Características: • • • • • • • • Configura aplicaciones desde componentes preparados de software. Esta modelo lleva a la reutilización del software.

En esta fase se realiza un esquema jerárquico a parte.identificación de los riesgos en el transcurso del desarrollo del proyecto..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 especificación inicial. Análisis de Riesgos. El prototipo se centra en aquellas partes que el cliente tiene "poco claras" .ordenación dela información para el desarrollo de un sistema informatico...Planificación. El desarrollo comienza con aquellas partes mejor Comprendidas del sistema • • • Prototipado El objetivo es comprender los requerimientos del sistema. Implementación del producto Evaluación del Cliente.software. Construcción y Adaptación de la Ingenieria.

Los sistemas se integran a partir de componentes existentes: • Etapas del proceso • • • • Análisis de componentes Modificación de requerimientos Diseño del sistema con reutilización Desarrollo e integración • Esta aproximación tiene cada vez más importancia. Esto es importante para mostrar que el programa cumple con sus especificaciones MODELOS QUE UTILIZAN LA REUTILIZACIÓN Basados en la reutilización sistemática. aunque no se tiene mucha experiencia en ella .MODELO FORMAL DE SISTEMAS Basados en la transformación de una especificación matemática a través de diferentes representaciones hasta obtener un programa ejecutable Las transformaciones preservan la corrección de las especificaciones.

El Ciclo de Vida en Cascada o Clásico Este paradigma es el más antiguo de los empleados en la IS y se desarrolló a partir del ciclo convencional de una ingeniería. deberemos analizar cuáles son los requisitos y la función del sistema. que queremos informatizar una empresa) deberemos analizar el funcionamiento de la misma. que incluye no sólo las etapas de ingeniería sino toda la vida del producto: las pruebas. que comienza en el nivel de la ingeniería de sistemas y avanza a través de fases secuenciales sucesivas. Características • El ciclo de vida en cascada exige un enfoque sistemático y secuencial del desarrollo de software. las . por ejemplo un sistema de control. especialmente de las del hardware. No hay que olvidar que la IS surgió como copia de otras ingenierías. Es un ciclo de vida en sentido amplio. por ejemplo. El primer paso del ciclo de vida de un proyecto consiste en un análisis de las características y el comportamiento del sistema del cual el software va a formar parte. Estas fases son las siguientes:  Ingeniería y análisis del sistema. En el caso de un sistema ya existente (supongamos. para dar solución a los problemas más comunes que aparecían al desarrollar sistemas de software complejos. hasta que llega el momento de sustituirlo. En el caso de que queramos construir un sistema nuevo. el uso (la vida útil del software) y el mantenimiento. y luego asignaremos un subconjunto de estos requisitos al software. Ciclo de vida en cascada.

cuáles son los interfaces requeridos y cuál es el rendimiento que se espera lograr. Si el diseño es lo suficientemente detallado.al menos en parte . usando generadores de código. La fase de utilización se solapa con las del software deben . El análisis de requisitos debe ser más detallado para aquellos componentes del sistema que vamos a implementar mediante software. tanto del sistema como documentarse y revisarse con el cliente.  Análisis de requisitos del software.  Codificación. y puede hacerse . y asignaremos al software aquellas funciones que vamos a automatizar. la codificación es relativamente sencilla. Una vez superada la fase de pruebas.  Prueba. la arquitectura de las aplicaciones. funcionalidad e incluso la calidad del mismo antes de comenzar la codificación. El ingeniero del software debe comprender cuáles son los datos que se van a manejar. comienza la fase de pruebas. La codificación consiste en la traducción del diseño a un formato que sea legible para la máquina. Los requisitos.de forma automática. Una vez que ya tenemos el programa ejecutable. no sólo los casos normales y todos los módulos que forman parte del sistema.  Utilización. la estructura interna de los programas y las interfaces. especialmente en la codificación.operaciones que se llevan a cabo en ella. El diseño es el proceso que traduce los requisitos en una representación del software de forma que pueda conocerse la arquitectura. el software se entrega al cliente y comienza la vida útil del mismo.  Diseño. cuál va a ser la función que tiene que cumplir el software. El objetivo es comprobar que no se hayan producido errores en alguna de las fases de traducción anteriores. Para ello deben probarse todas las sentencias. El diseño se aplica a cuatro características distintas del software: la estructura de los datos.

que tienen que corregir los errores que aparecen.y dura hasta que el software. que tienen que acostumbrarse a las nuevas aplicaciones. requerimientos y funcionalidades customizables. el diseño o la codificación. durante la utilización. Fortalezas • Suministra una plantilla en la que pueden colocarse los métodos para el análisis. deje de utilizarse. si esto es posible.el mantenimiento y la sustitución . acaba por ser sustituida por otra más amplia. y también desde cualquier fase se puede volver a la anterior si se detectan fallos. codificación. con especificaciones. Así. y también para los implementadores.  Sustitución. La sustitución implica el desarrollo de programas para la interconexión de ambos sistemas. el viejo y el nuevo. durante el tiempo en que ambos sistemas funcionen en paralelo. evitando la duplicación del trabajo de las personas encargadas del proceso de datos. El software sufrirá cambios a lo largo de su vida útil. ni quedan . en el sistema operativo o en los periféricos. examinar e implementar el software antes de entregárselo a los clientes.  Mantenimiento. La vida del software no es ilimitada y cualquier aplicación. más rápida o más bonita y fácil de usar. • Que se produzcan cambios en alguno de los componentes del sistema informático: por ejemplo cambios en la máquina. el cliente detecte errores en el software: los errores latentes. a pesar de ser lineal. • Que el cliente requiera modificaciones funcionales (normalmente ampliaciones) no contempladas en el proyecto. ya reemplazado por otro. contiene flujos que permiten la vuelta atrás. • Facilitar el desarrollo de proyectos de software de gran volumen. detalla el informe. diseño. y para trasvasar la información entre ambos. • Este modelo hizo que los desarrolladores dispusieran del tiempo suficiente para completar. Estas vueltas atrás no son controladas. no sustituyendo todas las aplicaciones de golpe. • Debilidades • El modelo en cascada. puesto que la sustitución conlleva normalmente un aumento de trabajo para los usuarios. Es conveniente realizarla por fases. La sustitución 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. desde el mantenimiento se vuelve al análisis.posteriores . Estos cambios pueden ser debidos a tres causas: Que. prueba y mantenimiento. por buena que sea.

de acuerdo al tipo de proyecto para evitar errores. pero también es muy frecuente en que una fase. El ejemplo más típico es la fase de mantenimiento. por ejemplo el diseño. 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. no se dispone de una versión operativa del programa. proporciona una imagen exacta del estado actual de un proyecto. Todos los modelos exhiben ventajas e inconvenientes pero todos tienen una serie de fases genéricas en común El modelo concurrente es aplicable a todo tipo de desarrollo de software. Normalmente los clientes no tienen conocimiento de la importancia de la fase de análisis 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. el ciclo de vida clásico requiere la definición inicial de todos los requisitos y no es fácil acomodar en él las incertidumbres que suelen existir al comienzo de todos los proyectos. Siempre hay iteraciones. CONCLUSIONES: • • Los modelos de software son muy importantes e indispensables obtener un software de calidad. cuando son más costosos de corregir y más prisa (y más presiones) hay por que el programa se ponga definitivamente en marcha. costos altos y pérdida de recursos. El modelo de prototipos permite un desarrollo rápido del software. Hasta que se llega a la fase final del desarrollo: la codificación. para Todos los modelos de desarrollo de software tienen que ser escogidos adecuadamente. que implica siempre volver a alguna de las fases anteriores. según se plantean dudas concretas en el diseño o la codificación.• • • explícitas en el modelo. se detecten errores que obliguen a volver a la fase anterior. Sin embargo. Es difícil que se puedan establecer inicialmente todos los requisitos del sistema. • • • . Como la mayor parte de los errores se detectan cuando el cliente puede probar el programa no se detectan hasta el final del proyecto. el análisis.

RECOMENDACION: • Tener conocimiento teórico y práctico 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. .

Sign up to vote on this title
UsefulNot useful