Está en la página 1de 10

MODELOS DE PROCESO DE SOFTWARE

El Modelo Lineal Secuencial

Ing. De Sistemas/Informacin Diseo Anlisis

Cdigo

Prueba

Es llamado tambin Modelo Bsico o Modelo de Cascada y acompaa las actividades siguientes: Ingeniera y modelado de Sistemas/Informacin. El software siempre forma parte de un sistema ms grande. Anlisis de Requerimientos del Software. Se requiere conocer tanto el dominio del software como el de la aplicacin. Diseo. Se centra en: Estructuras de Datos. Arquitectura del Software Representaciones de Interfaz. Algoritmos a usar. Generacin de Cdigo. El diseo se convierte a una forma legible por la mquina. Pruebas. Procesos lgicos del software para asegurar que se cumplan las funciones deseadas y para corregir las desviaciones. Mantenimiento. Muy probablemente el software requerir cambios (excepto el software empotrado), as se vuelve a aplicar cada una de las fases anteriores a un sistema ya existente. El paradigma de cascada presenta varios problemas: 1.Los proyectos reales raras veces siguen el proyecto secuencial que el modelo propone. 2.Con frecuencia el usuario no expone con claridad los requerimientos y el modelo que requiere. 3.El cliente tendr una versin del resultado hasta que est prcticamente terminado, as un error grave pudiera detectarse hasta el final. 4.Los desarrolladores de software se retrasan sin necesidad, ya que unos deben esperar a que otros terminen para poder iniciar su trabajo. El modelo de ciclo de vida clsico (cascada) sigue siendo el ms extensamente usado.

El Modelo de Construccin de Prototipos


A veces se definen objetivos generales pero no especficos, en otros puede haber dudas respecto a la eficacia de algn algoritmo, a la adaptacin a un sistema operativo, a la interaccin hombre-mquina, etc. Para estos casos el mejor enfoque es el de construccin.

Escuchar al Cliente

Construir/ Revisar maqueta

Desarrollador y usuario definen los objetivos globales, identifican requisitos conocidos y reas donde se requiere ms detalle. Se prepara un diseo rpido y de ah un prototipo. El cliente evala el prototipo y en base a la evaluacin se debe de ir mejorando el producto en base a la interaccin cliente-desarrollador. La construccin del prototipo puede ser problemtica debido a: Con frecuencia el desarrollo bajo este paradigma es muy lento. Se pueden usar algunas herramientas por su disponibilidad ms que por su eficiencia y stas pueden pasar a ser a pesar de lo anterior parte del sistema. Puede ser un paradigma efectivo, si tanto cliente como desarrollador acuerdan que el prototipo sirva como un mecanismo de definicin de requerimientos, y entonces se descarta y se realiza la Ingeniera de Software con una visin hacia la calidad y la facilidad de mantenimiento.

El cliente aprueba la maqueta

El Modelo DRA (Desarrollo Rpido de Aplicaciones)


Este modelo enfatiza un ciclo de desarrollo muy corto, es una adaptacin a alta velocidad del modelo de cascada, usando un enfoque basado en componentes: Comprende las siguientes fases: Modelado de gestin. Se modela el flujo de informacin para determinar que informacin se genera, quien la genera, quien la usa. Modelado de datos. El flujo de informacin del paso anterior se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen los atributos de cada uno de los objetos y las relaciones entre ellos. Modelado del proceso. Los objetos de datos se transforman para lograr el flujo de informacin necesario para implementar una funcin de gestin. Se crean las descripciones del proceso para aadir, modificar o recuperar un objeto de datos. Generacin de aplicaciones. Este modelo supone el uso de tcnicas de 4 generacin, el DRA trata de utilizar componentes de programas ya existentes o crear componentes de programas ya existentes o crear componentes reutilizables. Prueba y entrega. Como se enfatiza la reutilizacin, el tiempo de pruebas se reduce. El Modelo DRA

Equipo no. 2 Equipo no. 1 Modelado de Gestin

Equipo no. 3
Modelado de Gestin

Modelad o de Datos

Modelado de Gestin Modelado de Datos

Modelado de Datos Modelado de Procesos

Modelado de Procesos
Generacin de Aplicaciones

Pruebas y Volumen

Modelado de Procesos

Generacin de Aplicaciones

Generacin de Aplicacione s Pruebas y

Pruebas y Volumen

Volumen
De 60 a 90 das
3

El DRA tiene algunos inconvenientes: Para proyectos grandes el DRA requiere recursos humanos suficientes para crear el nmero correcto de equipos. DRA requiere clientes y desarrolladores comprometidos en la generacin de aplicaciones con rapidez. No todas las aplicaciones son apropiadas para el DRA, si un sistema no se puede modularizar adecuadamente, ser problemtico para el DRA. Si est en juego el alto rendimiento, puede ser que no sea adecuado este modelo. Tampoco es adecuado cuando hay riesgos tcnicos altos como el uso de tecnologas nuevas, o se requiere mucha interaccin con programas ya existentes.

El Modelo de Procesos Evolutivos de Software


Los requerimientos con frecuencia cambian, por lo que se requiere un modelo que permita la evolucin del producto. El modelo Incremental.

Incremento 1

Ing. De Sistemas/Informaci Anlisi n Diseo s Incremento


2 Anlisis Incremento 3 Anlisis

Entrega de 1 Incremento

Cdigo

Diseo Diseo

Cdigo

Entrega de 2 Prueba Incremento Entrega de 3 Cdigo Prueba Incremento Cdigo Entrega de 4 Prueba Incremento

Prueba

Anlisis

Diseo

Cada secuencia lineal produce un incremento de software. El primer incremento es con frecuencia un PRODUCTO ESENCIAL. A diferencia del modelo de prototipos el incremental se centra en la entrega de un producto operacional con cada incremento. Particularmente til cuando la cantidad de recursos humanos no est disponible para una implementacin completa desde la primera vez.

Tiempo de Calendario

El Modelo en Espiral
Modelo de software evolutivo que combina la naturaleza interactiva de los prototipos con los aspectos controlados y sistemticos del modelo secuencial lineal. En este modelo el software se desarrolla en una serie de versiones incrementales. El Modelo en Espiral contiene 6 regiones: Comunicacin con el cliente. Planificacin. Anlisis de riesgos. Ingeniera. Construccin y adaptacin. Evaluacin del cliente. A diferencia del modelo de proceso clsico, que termina cuando se entrega en software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software. Un Modelo En Espiral Tpico

Tambin presenta algunos inconvenientes como: Puede ser difcil convencer a clientes (bajo contrato) que el enfoque evolutivo es controlable. Requiere mucha habilidad para la evaluacin del riesgo y de esto depende el xito. El modelo es relativamente nuevo y no se ha utilizado tanto como el de cascada y el de prototipo.

El Modelo de Ensamblaje de Componentes


Basado en que las tecnologas de objetos ofrecen el marco de trabajo adecuado para un modelo de proceso basado en componentes. Incorpora muchas caractersticas del modelo en espiral, ver figura siguiente: Modelo en Espiral Adaptado para el ciclo de vida clsico completo

Las clases (componentes en la figura) creadas en proyectos de Ingeniera de Software anteriores se almacenan en una biblioteca de clases o depsito. Cuando se identifican las clases candidatas, se examina la biblioteca de clases para ver si ya existen, si es as, se extraen y se extraen y se vuelven a usar. Si no estn en la biblioteca se aplican los mtodos orientados a objetos. Este modelo lleva al reuso de componentes y a los beneficios que esto implica, que puede ser el orden del 70% de reduccin en tiempo, del 84% en el costo.

El Modelo de Desarrollo Concurrente (Ingeniera concurrente)


Considerar que en un proyecto grande, an cuando se encuentre en la fase de codificacin, hay personal del proyecto dedicado a muchas fases de desarrollo como requerimientos, diseo, codificacin, pruebas simultneamente. El modelo de proceso concurrente puede presentarse en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas.

Actividad de Anlisis Bajo Desarrollo

Ninguna

Cambios en espera Bajo Revisin

Cambios en espera

En lnea base

Hecho

Representa un estado de una actividad en Ingeniera del Software

La actividad anlisis se puede encontrar en uno de los estados. De forma similar, otras actividades se puedes representar de una manera anloga. Todas las actividades existen concurrentemente, pero residen en estados diferentes.

Este modelo define una serie de acontecimientos que dispararn transacciones de estado a
estado para cada una de las actividades de la Ingeniera de Software, ejemplo, durante las primeras etapas del diseo no se contempla una inconsistencia del modelo de anlisis. Esto genera la correccin del modelo de anlisis. Esto genera la correccin del modelo de anlisis, que disparar la actividad del estado Hecho al estado Cambios en espera. Este modelo se usa con frecuencia como el paradigma de desarrollo de aplicaciones clienteservidor. Cuando este modelo se aplica a cliente-servidor, define actividades en dos dimensiones. Dimensin de sistemas oDiseo oEnsamblaje oUso Dimensin de componentes. oDiseo oRealizacin La concurrencia se logra de dos formas: 1.Las actividades de sistemas y de componentes ocurren simultneamente y pueden modelarse con el enfoque orientado a objetos. 2.Una aplicacin cliente-servidor tpica se implementa con muchos componentes, cada uno de los cuales se pueden disear y realizar concurrentemente. Este modelo es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de considerar las actividades de la Ingeniera de Software a una secuencia de sucesos, define una red de actividades. Todas las actividades de la red existen simultneamente con otras.

Modelo de Mtodos Formales


Este modelo acompaa a un conjunto de actividades que conducen a la especificacin matemtica del software. Permite que se especifique, desarrolle y verifique un sistema basado en computadora, aplicando una notacin rigurosa y matemtica. Actualmente se usa una variacin de este enfoque llamada Ingeniera de Software de sala limpia (Clean Room Software Engineering). Su uso proporciona un mecanismo para eliminar muchos de los inconvenientes de los paradigmas de la Ingeniera de Software, como la ambigedad, lo incompleto y las inconsistencias. Estos modelos ofrecen una esperanza de software sin errores, sin embargo, su aplicacin en software de gestin presenta algunos problemas como:

1.El desarrollo es caro y toma mucho tiempo. 2.Pocos desarrolladores de software los conocen. 3.Es difcil usarlos como elemento de comunicacin con clientes que no tienen muchos conocimientos tcnicos. Para razones lgicas se usan ms por quienes requieren desarrollar software de alta seguridad y los que pasan muchos problemas econmicos por la adaptacin de errores de software.

Tcnicas de 4 Generacin (T4G)


Facilitan la especificacin de algunas caractersticas del software de alto nivel, luego, la herramienta genera automticamente el cdigo fuente en base a la especificacin. Puede incluir las siguientes herramientas: oLenguajes no procedimentales, de consulta a bases de datos, generacin de informes, manejo de datos, interaccin y definicin de pantallas, generacin de cdigos, capacidades grficas de alto nivel y capacidades de hoja de clculo. Al principio muchas de estas herramientas estaban disponibles para mbitos de aplicacin muy especficos, actualmente se han extendido a todas las categoras de aplicaciones de software. La situacin de los T4G pueden resumirse como sigue: 1.Su uso ha crecido mucho en la ltima dcada. Junto con los CASE y los generadores de cdigo ofrecen solucin fiable a muchos problemas de software. 2.Han resultado muy provechosos a aplicaciones pequeas y medianas. 3.En aplicaciones grandes exigen el mismo o ms tiempo de anlisis, diseo, y prueba, perdindose as el ahorro al evitar la codificacin. Este enfoque es ya importante y podra convertirse en el ms importante en el futuro.

Producto y Proceso
Si el proceso es dbil, el producto final seguramente sufrir, as hay que aceptar la dualidad producto-proceso y trabajar en ambos frentes.

10