ESCUELA SUPERIOR POLITCNICA AGROPECUARIA DE

MANAB MANUEL FLIX LPEZ

CARRERA INFORMTICA

SEMESTRE SEPTIMO

PERODO ABRIL-SEPT/2015

TEMA:
MODELOS DE PROCESO PRESCRIPTIVOS

MATERIA:
INGENIERIA DE SOFTWARE
AUTORA:
SINDY M. COBEA CEDEO
FACILITADORA:
ING. HIRAIDA SANTANA
MISIN
Formacin de profesionales ntegros que conjuguen ciencia, tecnologa y valores en
su accionar, comprometidos con la sociedad en el manejo adecuado de programas
y herramientas computacionales de ltima generacin.

VISIN
Ser referente en la formacin de profesionales de prestigio en el desarrollo de
aplicaciones informticas y soluciones de hardware.

CALCETA, MAYO 2015

INTRODUCCIN
En este captulo vamos a referirnos a los modelos de proceso prescriptivos y nos enfocaremos ms en
uno de los modelos ms utilizados por su sencilla utilizacin en ingeniera de software, nos referimos al
desarrollo en cascada o tambin llamado modelo en cascada, el cual es un enfoque metodolgico que
establece las fases o etapas de un proceso para el desarrollo de software, veremos tambin sus faces o
etapas con las que cuenta este modelo, sus ventajas, sus desventajas, sus inconvenientes a la hora de
desarrollar un programa y dems cosas que son muy utilizadas al momento de trabajar con este modelo.

MODELOS DE PROCESO PRESCRIPTIVO

Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el caos del
desarrollo de software. La historia indica que estos modelos tradicionales han dado cierta estructura til al
trabajo de ingeniera de software y que constituyen un mapa razonablemente eficaz para los equipos de
software. Sin embargo, el trabajo de ingeniera de software y el producto que genera siguen al borde del
caos.

MODELO EN CASCADA
En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada como un concepto
inicial, un modelo que segn l era defectuoso (Royce, 1970). Su trabajo explora cmo el modelo inicial
podra ser convertido en un modelo interactivo, con comentarios de cada fase de influir en las fases
posteriores. Es slo el modelo inicial que recibi la notificacin, su propia crtica de este modelo inicial se
ha ignorado en gran medida. La expresin "modelo de cascada" rpidamente lleg a referirse no a la final
de Royce, el diseo interactivo, sino ms bien a su modelo puramente un orden secuencial.

Este modelo tambin es conocido como modelo clsico, modelo tradicional o modelo lineal secuencial, el
mismo que da las pautas que permiten la organizacin en el desarrollo del software a travs de la
implementacin de sus caractersticas - etapas, esto quiere decir que cuando se est llevando a cabo
todas las tareas pertinentes dentro de esa etapa, no se podr avanzar a la siguiente etapa hasta no
concluir con todas las tareas.

Entre los problemas que en ocasiones surgen al aplicar el modelo de la cascada se encuentran los
siguientes:

1.

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
confusin conforme el equipo del proyecto avanza.

2.

A menudo, es difcil para el cliente enunciar en forma explcita todos los requerimientos.

3.

El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre
natural que existe al principio de muchos proyectos.

4.

El cliente debe tener paciencia. No se dispondr de una versin funcional del (de los) programa(s)
hasta que el proyecto est muy avanzado. Un error grande sera desastroso si se detectara hasta revisar
el programa en funcionamiento.

A continuacin una breve descripcin de cada proceso que constituye este modelo:

Planificacin: Realiza un estudio de factibilidad del software as como contemplar los posibles
costos que pueden surgir mediante su implementacin.

Anlisis y Diseo de Requerimientos: Involucra la identificacin de las caractersticas que nos

guan para determinar las funcionalidades del software de acuerdo al medio donde se pretende
implementar, es muy importante notar que trata de responder a las preguntas Quienes intervienen en
el uso del Software?,Qu restricciones tendr el software?

Diseo: Identifica y describe las abstracciones del software y cumple con los requerimientos
plasmando, todas esas caractersticas en un diseo que permite visualizar y contemplar
adicionalmente situaciones no previstas.

Implementacin: Realizar las pruebas pertinentes y verificar que se cumplen con las caractersticas
identificadas.

Operacin y Mantenimiento: Se instala dentro del ambiente, depender que pasar a partir de ah,
ya que esta etapa an puede considerar nuevamente la existencia de caractersticas que no han sido
contempladas y/o caractersticas innecesarias, implicando la modificacin del software para la
adaptacin de estas anomalas.

Crecimiento y cambio: Se evala el software de modo que se determina si se puede emplear dentro
de la nueva tecnologa no afectando la integridad del mismo, de modo que si no es posible que exista
una adaptacin a lo nuevo, el proceso de diseo del software nuevamente se repite desde el principio

Uso del modelo en cascada

El modelo de cascada es ampliamente utilizado por ejemplo de desarrollo de software grande como los
empleados por el Departamento de Defensa de los EE.UU y la NASA, y para muchos proyectos
gubernamentales de gran tamao. Los que utilizan esos mtodos no siempre formalmente distinguir entre
el modelo de cascada pura y los diferentes modelos de cascada modificada, por lo que puede ser difcil de
discernir exactamente qu modelos se estn utilizando y en qu medida.

Herramientas que se utilizan para cada fase:

Anlisis de requisitos: Personal administrativo des el jefe hasta la persona de menor rango.

Diseo del Sistema: Arquitectura pura de donde se va trabaja teniendo dependencia a su vez del
hardware.

Diseo del Programa: Todo el hardware y el software que se usara para el desarrollo del sistema

Codificacin: De igual manera el hardware y el software para desarrollar el programa

Pruebas: Personal capacitado para realizar las acciones del sistema.

Verificacin: Personal capacitado para verificar que todo est en orden.

Mantenimiento: Desarrolladores para la actualizacin y estabilidad del sistema.

El fracaso del modelo de cascada

Las razones principales son:

Los clientes quieren ver el producto a medida que se desarrolla

El cliente no puede validar el producto a medida que lo desarrollamos

El realizar la pruebas correspondientes en etapas avanzadas del desarrollo

Ventajas al usar este mtodo

Se tiene todo bien organizado y no se mezclan las fases

Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.

Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin porque
permite realizarla sin problemas.

Desventajas al usar este mtodo

Gran dependencia en los requerimientos inciales

Difcilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que
provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite
movilizarse entre fases.

El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresin de un
desarrollo lento, existe la incertidumbre de los clientes si sus proyectos sern entregados a tiempo.

Inicio de la codificacin muy tarde en el ciclo de vida del proyecto

Crticas sobre el mtodo en cascada

No refleja realmente el proceso de desarrollo del software. Ya que la mayora de los que desarrollan
proyectos no cumple con este lineamiento.

Se tarda mucho tiempo en pasar por todo el ciclo

La aplicacin de la metodologa en cascada se orienta mejor al desarrollo de proyectos de corto

plazo, de poca innovacin y proyectos definitivos y detallados.

Metodologa pueden confundir al equipo profesional en las etapas tempranas del proyecto.

No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos.

Caractersticas de este mtodo

Es el ms utilizado.

Es una visin del proceso de desarrollo de software como una sucesin de etapas que
produce productos intermedios.

Si se cambia el orden de las fases, el producto final ser de inferior calidad.

Proyectos para los que es adecuado

Aquellos para los que se dispone de todas las especificaciones desde el principio, por
ejemplo, los de reingeniera.

Se est desarrollando un tipo de producto que no es novedoso.

Proyectos complejos que se entienden bien desde el principio

MODELOS DE PROCESO INCREMENTAL

El modelo incremental combina elementos de los flujos de proceso lineal y paralelo, aplica secuencias
lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal
produce incrementos de software susceptibles de entregarse [McD93] de manera parecida a los
incrementos producidos en un flujo de proceso evolutivo.

Por ejemplo, un software para procesar textos que se elabore con el paradigma incremental quiz entregue
en el primer incremento las funciones bsicas de administracin de archivos, edicin y produccin del
documento; en el segundo dar herramientas ms sofisticadas de edicin y produccin de documentos; en
el tercero habr separacin de palabras y revisin de la ortografa; y en el cuarto se proporcionar la
capacidad para dar formato avanzado a las pginas. Debe observarse que el flujo de proceso para
cualquier incremento puede incorporar el paradigma del prototipo.

MODELOS DE PROCESO EVOLUTIVO

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar
versiones cada vez ms completas del software.

HACER PROTOTIPOS. Es frecuente que un cliente defina un conjunto de objetivos generales para el
software, pero que no identifique los requerimientos detallados para las funciones y caractersticas. En
otros casos, el desarrollador tal vez no est seguro de la eficiencia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debe adoptar la interaccin entre el humano y la mquina. En estas
situaciones, y muchas otras, el paradigma de hacer prototipos tal vez ofrezca el mejor enfoque.

En la mayora de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy lento,
muy grande, difcil de usar o todo a la vez. No hay ms alternativa que comenzar de nuevo, con ms
inteligencia, y construir una versin rediseada en la que se resuelvan los problemas.

El prototipo sirve como el primer sistema. Lo que Brooks recomienda es desecharlo. Pero esto quiz
sea un punto de vista idealizado. Aunque algunos prototipos se construyen para ser desechables, otros
son evolutivos; es decir, poco a poco se transforman en el sistema real.

Tanto a los participantes como a los ingenieros de software les gusta el paradigma de hacer prototipos.
Los usuarios adquieren la sensacin del sistema real, y los desarrolladores logran construir algo de
inmediato.

EL MODELO ESPIRAL. El modelo de desarrollo espiral es un generador de modelo de proceso

impulsado por el riesgo, que se usa para guiar la ingeniera concurrente con participantes mltiples de
sistemas intensivos en software.

Tiene dos caractersticas distintivas principales. La primera es el

enfoque cclico para el crecimiento incremental del grado de definicin de un sistema y su

implementacin, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de
referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y
mutuamente satisfactorias.

MODELOS CONCURRENTES
El modelo de desarrollo concurrente, en ocasiones llamado
ingeniera concurrente, permite que un equipo de software
represente elementos iterativos y concurrentes de cualquiera de
los modelos de proceso descritos en este captulo. Por ejemplo,
la actividad de modelado definida para el modelo espiral se logra
por medio de invocar una o ms de las siguientes acciones de
software: hacer prototipos, anlisis y diseo.

CONCLUSIN

En conclusin puedo decir que todos los modelo de proceso prescriptivos son muy
importantes, de acuerdo al tipo de sistema que se utilice, es por ello que debemos de saber
muy bien qu tipo de modelo es el mejor para el proyecto que se est, para as llegar al mejor
de los resultados y nuestro sistema funcione de la manera que deseamos desde su inicio hasta
el final del mismo.

BIBLIOGRAFA

Pressman, R. S.F. Ingeniera de Software, un enfoque prctico. Sptima edicin.

Ramone , M. 2012. Ingeniera del Software, Modelo en Cascada. (En lnea).

Consultado,

17

de

Marzo.

2015.

Disponible

en:

http://ingenexescom.blogspot.com/2012/02/modelo-en-cascada.html

Pressman, R. S.F. Ingeniera de Software, un enfoque prctico. sexta edicin.

Consultado, 17 de Marzo. 2015. Disponible en: http://es.scribd.com/doc/35015019/Metodologia-enCascada#scribd