Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de proceso así como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabajo estándar pero cada uno aplica diferencias a cada una de las actividades y a su flujo de trabajo.
Los modelos prescriptivos de software nos definen un conjunto de tareas actividades, productos de trabajo que se requieren para desarrollar productos de calidad que son importantes para llevar control, estabilidad y organización a una actividad que tiende a ser caótica, el modelo prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingenieria de software. Se debe considerar que aun que un proceso sea prescriptivo esto no se debe asumir como estático, estos se deben adaptar al personal, al proyecto y al problema.
CUERPO.
Modelo de Proceso Prescriptivo
Modelo de Cascada.El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado.
Una variante de la representación del modelo de la cascada se denomina modelo en V, se ilustra el modelo en V, donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución.
- Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza.
- A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos
- El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los)programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento.
Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios (en las características, funciones y contenido de información). El modelo de la cascada suele ser inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situaciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.
El modelo incremental combina elementos de los flujos de proceso lineal y paralelo, en tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.
Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad. Este proceso se repite después de entregar cada incremento, hasta terminar el producto final.
Modelos de Proceso Evolutivo
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software.
Hacer Prototipos. El cliente describe un conjunto de de objetivos generales del software pero no identifica los requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la efectividad del software, si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo no sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y puede mezclarse con cualquier otro método.
El paradigma de construcción de prototipos se inicia con la comunicación el ingeniero de software y el cliente encuentran y definen los requisitos básicos y conocidos, entonces se plantea con rapidez una iteracion de construcción de prototipos y se presenta un diseño rápido y este se centra en aspectos visibles al cliente y al usuario final, se construye el prototipo y este se somete a una evaluación por parte del cliente/usuario para y con la retroalimentacion producida se reajustan los requisitos del software que se desarrollara. De tal forma que el prototipo sirve como un mecanismo para identificar los requisitos del software.
El Modelo Espiral. El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo cascada, el modelo cascada se puede adaptar y aplicar a través del ciclo de vida completo de una aplicación desde el desarrollo del concepto hasta el mantenimiento.
Cuando se aplica el modelo espiral se desarrolla una serie de entregas evolutivas iniciando desde posiblemente documentación y prototipos, hasta llegar versiones cada ves mejores del sistema.
Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo. Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya analizadas.
Proceso Modelo Concurrente.
El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelos de proceso. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: Hacer prototipos, análisis y diseño.
El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcional.
CONCLUSIONES
- El modelo de cascada es uno de los modelos más utilizado en proyectos pequeños ya que tiene q tener bien en claro los requerimiento del software, si no se tienen en claro estos requerimientos generar problemas al desarrollarlo.
- El modelos incremental aplica una secuencia lineal que produce incrementos lo cual modifica el software para cumplir las necesidades del cliente, este incremento se lo realiza hasta cumplir las especificaciones del cliente.
- El modelo evolutivo es el que se caracteriza por desarrollar versiones cada vez más completas del software, en este se encuentra el modelo prototipo el cual se hace ciertas especificaciones del software pero no se tiene en claro lo que se requiere por lo que se hace un diseño según las especificaciones, de tal forma que sirva para identificar los requerimientos del software. EL modelo espiral el cual se entregan las primeras iteraciones de forma de prototipo lo cual se lleva documentación hasta llegar a versiones mas complejas.
- Modelo concurrente este modelo es de tipo de red donde todas las personas actúan al mismo tiempo en el proceso del software, se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor
BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición
