martes

Resumen de Modelos de Producción de Software II


Ciclo de Vida II
Para cada una de las fases o etapas listadas en el ítem anterior, existen sub-etapas (o tareas). El modelo de proceso o modelo de ciclo de vida utilizado para el desarrollo define el orden para las tareas o actividades involucradas también definen la coordinación entre ellas, y su enlace y realimentación. Entre los más modelos conocidos se puede mencionar: modelo en cascada o secuencial, modelo espiral, modelo iterativo incremental. De los antedichos hay a su vez algunas variantes o alternativas, más o menos atractivas según sea la aplicación requerida y sus requisitos.

Modelo Cascada
Este, aunque es más comúnmente conocido como modelo en cascada es también llamado modelo clásico, modelo tradicional o modelo lineal secuencial.
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños sistemas a desarrollar. En estas circunstancias, el paso de una etapa a otra de las mencionadas sería sin retorno, por ejemplo pasar del diseño a la codificación implicaría un diseño exacto y sin errores ni probable modificación o evolución: codifique lo diseñado sin errores, no habrá en absoluto variantes futuras. Esto es utópico; ya que intrínsecamente el software es de carácter evolutivo , cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.

Desventajas del modelo cascada:

  • Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande.
  • No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar.
  • El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto, con altos costos.


Modelo Incremental

 La descripción del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificación, desarrollo y validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.  El funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.


Modelo Lineal
El proceso de desarrollo puede involucrar numerosas y variadas tareas , desde lo administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento. Pero, casi rigurosamente, siempre se cumplen ciertas etapas mínimas; las que se pueden resumir como sigue:

  • Captura, elicitación , especificación y análisis de requisitos (ERS)
  • Diseño
  • Codificación
  • Pruebas (unitarias y de integración)
  • Instalación y paso a producción
  • Mantenimiento

En las anteriores etapas pueden variar ligeramente sus nombres, o ser más globales, o contrariamente, ser más refinadas; por ejemplo indicar como una única fase (a los fines documentales e interpretativos) de análisis y diseño; o indicar como implementación lo que está dicho como codificación; pero en rigor, todas existen e incluyen, básicamente, las mismas tareas específicas.

Autores:
Oscar Eduardo
Iván López Flores
Javier Ramos Carrillo
Grupo: 3CV3

Resumen de Modelos De Producción del Software



EL MODELO EN ESPIRAL.

Este modelo es no secuencial y por tanto resulta un poco más complejo de comprender que los anteriores además de incluir un análisis de riesgos. 

El modelo en espiral concreta cuatro fases:

  • Planificación
  • Análisis de Riesgos
  • Ingeniería (Construcción del prototipo)
  • Evaluación por el cliente


Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda de la espiral y se vuelve a la primera fase (de planificación).

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS.

El prototipo es una versión reducida del programa completo. 
Tras recoger los requisitos tanto del cliente como del sistema, se comienza con el diseño rápido del prototipo; el diseño completo obedece al previo diseño de pequeños prototipos específicos para funciones individuales. Más tarde, estos diseños serán unidos en uno sólo.
Después, se procede a la construcción del mismo. Éste prototipo es el que mostraremos al cliente para que lo evalúe y considere cambios en él, aunque no se trate de una versión definitiva.

EL MODELO DRA 
El Desarrollo Rápido de Aplicaciones es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases: 


  • Modelado de gestión: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso? 
  • Modelado de datos: Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. 
  • Modelado de proceso: Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. 
  • Generación de aplicaciones: El proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. 
  • Pruebas de entrega: Se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. 

Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda “ámbito en escalas”. Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto. 


Autores:
Oscar Eduardo.
Iván López Flores
Javier Ramos Carrillo
Grupo: 3CV3
Related Posts Plugin for WordPress, Blogger...