Indice

1. Introduccion

2. Modelo de Cascada

2.1. Origen y evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Fases del modelo de Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3. Aplicacion del Modelo de Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5. Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6. Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1. Problemas con el modelo en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7. Modelo Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7.1. Caracteristicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7.2. Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7.3. Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8. Modelos de cascada modificados o mejorados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9. Modelo V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9.2. Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.9.3. Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.10. Caso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3. Modelo Evolutivo

11

3.1. Origen y evolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.2. Tipos de Desarrollo Evolutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.3. Fases de Modelo Evolutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5. Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.6. Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.7. Caso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

4. Tabla Comparativa

14

4.1. Modelos de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

1.

Introduccion

Un sistema informatico esta compuesto por hardware y software. En cuanto al hardware, su produccion se realiza sistematicamente y la base de conocimiento para el desarrollo de dicha actividad esta claramente definida. La fiabilidad del
hardware es, en principio, equiparable a la de cualquier otra maquina construida por el hombre. Sin embargo, respecto del
software, su construccion y resultados han sido historicamente cuestionados debido a los problemas asociados, entre ellos
podemos destacar los siguientes:
Los sistemas no responden a las expectativas de los usuarios.
Los programas fallan con cierta frecuencia.
Los costes del software son difciles de prever y normalmente superan las estimaciones.
La modificacion del software es una tarea difcil y costosa.
El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.
En Ingeniera en Software, un modelo de proceso de desarrollo de software que permite evitar estos problemas, puede
verse como una manera de dividir el trabajo en distintas actividades (o el ciclo de vida del producto en distintas fases) con
la intencion de lograr la mejor gestion y el mejor resultado para el proyecto. Estos modelos pueden incluir la definicion
previa de entregables especficos y otros artefactos que son creados y completados por el equipo para disenar, codificar,
probar y mantener el software en cuestion.
Como concepto un modelo de proceso de desarrollo de software es Una representacion simplificada de un proceso de
software, representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto un
modelo de procesos del software es una abstraccion de un proceso real.(Sommerville)

2.
2.1.

Modelo de Cascada
Origen y evolucion

En Ingeniera de software el desarrollo en cascada, es el enfoque metodologico que ordena rigurosamente las etapas del
proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacion de la etapa
anterior. Al final de cada etapa, el modelo esta disenado para llevar a cabo una revision final, que se encarga de determinar
si el proyecto esta listo para avanzar a la siguiente fase.
El modelo de cascada inicialmente propuesto por Winston W. Royce en 1970, fue adaptado para el software partir de
ciclos de vida de otras ramas de la ingeniera. Es el primero de los propuestos y el mas ampliamente seguido por las
organizaciones.
El origen del termino cascada se cita en un artculo publicado en 1970 Winston W. Royce, aunque Royce no utilizo el
termino cascada en este artculo. Ironico, Royce presentaba este modelo como ejemplo de un modelo danado y menos
tampoco lo defendio como una metodologa eficaz. El primer uso del termino cascada pudo haber sido un documento de
1976 por Bell y Thayer.

2.2.

Fases del modelo de Cascada

El numero de etapas suele variar, pero en general suelen ser:

Analisis de Requisitos

En esta fase se analizan las necesidades de los usuarios finales del software para determinar que objetivos debe
cubrir. De esta fase surge una memoria llamada SRD (documento de especificacion de requisitos), que contiene la
especificacion completa de lo que debe hacer el sistema sin entrar en detalles internos.
Diseno del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del
desarrollo en equipo. Como resultado surge el SDD (Documento de Diseno del Software), que contiene la descripcion
de la estructura relacional global del sistema y la especificacion de lo que debe hacer cada una de sus partes, as como
la manera en que se combinan unas con otras.
Diseno del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as
como tambien los analisis necesarios para saber que herramientas usar en la etapa de Codificacion
Codificacion
Es la fase en donde se implementa el codigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para
corregir errores. Dependiendo del lenguaje de programacion y su version se crean las bibliotecas y componentes
reutilizables dentro del mismo proyecto para hacer que la programacion sea un proceso mucho mas rapido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente
y que cumple con los requisitos, antes de ser entregado al usuario final.
Verificacion
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas
pruebas para comprobar que el sistema no falle.
Mantenimiento
Una de las etapas mas crticas, ya que se destina un 75 por ciento de los recursos, es el mantenimiento del Software
ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Fuente: Winston W. Royce, Managing the developmentof large, complex systems. Proceedings of the 1970 WESCON
Conference.
Este excelente artculo NO propone usar este modelo. Las llamo Pasos de implementacion para desarrollar un programa
de computadora grande para entregarlo al cliente.

2.3.

Aplicacion del Modelo de Cascada

Se sigue una secuencia lineal de etapas.
Las empresas establecen los productos y documentos que deben producirse en cada etapa.
Estos productos y/o documentos permiten seguir el avance del proyecto.
Tambien se establece que metodos aplicar en cada etapa.

Estos metodos se organizan en forma coherente en lo que es la metodologa de desarrollo.

2.4.

Caractersticas
Primer modelo empleado (Royce, 1970), tambien denominado ciclo de vida clasico y modelo lineal secuencial.
Consiste en la ejecucion secuencial de una serie de fases que se suceden, lo que da nombre al modelo.
Cada fase genera documentacion para la siguiente. Esta documentacion debe ser aprobada.
Una fase no comienza hasta que la anterior ha terminado.
Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.

2.5.

Fortalezas
Facilita la gestion del desarrollo.
Es el modelo de proceso de software mas simple en terminos de complejidad y facilidad de implementacion.
Emplea un metodo sistematico, ortodoxa del desarrollo y ejecucion de proyectos.

2.6.

Debilidades
Al ser un modelo estrictamente secuencial, saltando hacia atras y hacia adelante entre dos o mas fases no es posible.
La siguiente fase se puede llegar solo despues de que la anterior haya sido completada.
Debido a esto, los errores y los errores en el codigo no se pueden descubrir hasta ya menos que se alcanza la fase de
prueba. Esto puede conducir a una gran cantidad de desperdicio de tiempo y otros recursos valiosos.
Este modelo de proceso no es adecuado para los proyectos en los que los requisitos del proyecto son dinamicos o
que cambian constantemente.

2.6.1.

Problemas con el modelo en cascada

Se retrasa la deteccion de problemas crticos.
Idealista pensar en identificar correctamente todos los Requerimientos al principio.
No permite implementaciones parciales.
Usuario solo involucrado al principio y al final.

2.7.

Modelo Iterativo

De acuerdo a Royce en el proceso del modelo las iteraciones del diseno nunca son limitados a la etapa sucesiva y por eso
el modelo sin iteracion es un riesgo e invita al fracaso. Como alternativa Royce propuso un desarrollo mas incremental,
donde cada siguiente paso esta ligado con el paso anterior.

Tambien planteo otros tipos de soluciones a esta metodologa en aquel artculo.

2.7.1.

Caracteristicas

Las caractersticas de este modelo son:

Usando analisis y mediciones como guas para el proceso de mejora es una diferencia mayor entre las mejoras iterativas
y el desarrollo rapido de aplicaciones, principalmente por dos razones:
Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto.
Permite estudiar y despues mejorar y ajustar el proceso para el ambiente en particular.

2.7.2.

Fortalezas
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado.
Este metodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

2.7.3.

Debilidades
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean
problemas en la aplicacion del paradigma.
Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida
clasico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estara disponible una version operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente
definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atras.
Es comparativamente mas lento que los demas y el coste es mayor tambien.

2.8.

Modelos de cascada modificados o mejorados.

Cascada Salmon

Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996

Sashimi
7

Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996

Cascada Subproyectos

Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996

Cascada Iterativo

Fuente: Ingenieria del Software 7ma. Ed. - Ian Sommerville

Cascada Sistematico secuencial

Fuente: Ingenieria de software u n enfoque practico 7ma. Ed. - R. Pressman

2.9.

Modelo V

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolucion del mismo.
2.9.1.

Caractersticas
Cada fase empieza cuando se ha terminado la anterior.
Para pasar a la fase posterior es necesario haber logrado los objetivos de la previa.
Es u til como control de fechas de entregas.
Al final de cada fase el personal tecnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto.

Se puede identificar una ventaja principal con respecto al Modelo Cascada mas simple, y se refiere a que este modelo
involucra chequeos de cada una de las etapas del modelo de cascada.
2.9.2.

Fortalezas
El modelo en V hace mas explcita la tarea parte de la iteracion de las actividades del proceso.
Las pruebas de cada fase ayudaran a corregir posibles errores sin tener que esperar a que sean rectificados en la etapa
final del proceso.
Con las pruebas unitarias y de integracion se consigue obtener exactitud en los programas.

2.9.3.

Debilidades
Al encontrarse errores luego de realizar las pruebas se pierde tiempo y dinero, ya que cada prueba se realiza luego
de haber terminado la implementacion.

2.10.

Caso de Aplicacion

Si un equipo desarrollara una libreta de direcciones de clientes utilizando la metodologa de la cascada, el orden del
trabajo sera de la siguiente manera:
REQUISITOS DEL PRODUCTO
El Gerente del producto crea documentos de requisitos que incluyen los siguientes requisitos (en orden de prioridad):
El usuario debe ser capaz de crear nuevos contactos.
El usuario debe ser capaz de ver sus contactos.
El usuario debe ser capaz de importar contactos de otros programas.
El usuario debe ser capaz de enviar por correo electronico a sus contactos de la libreta de direcciones.
El usuario debe ser capaz de agregar imagenes para representar a sus contactos.
10

Estos documentos de requerimientos incluiran requisitos detallados, escenarios de usuario y disenos posibles para la
funcionalidad.
Periodo de ejecucion: 2 semanas

ANALISIS
El equipo de ingeniera toma estos requisitos y las analiza, haciendo preguntas, segun sea necesario. Gerente del producto
actualiza el documento con los nuevos requisitos en caso de que falte alguno.
Periodo de ejecucion: 1 semanas

DISENO
El equipo de ingeniera crea un diseno para la funcionalidad, incluyendo el diseno de bases de datos, maquetas y los flujos
de trabajo.
Periodo de ejecucion: 3 semanas

IMPLEMENTACION
El equipo de ingeniera desarrolla la funcionalidad y la prepara las prueba.
Periodo de ejecucion: 1 semanas
PRUEBAS
El equipo del producto pone a prueba la funcionalidad completa.
Periodo de ejecucion: 2 semanas
LANZAMIENTO
La funcionalidad del producto se libera.
numero total de tiempo trascurrido: 9 semanas
Nota: si los cambios en el diseno se producen durante este flujo de trabajo, el proyecto tendra que volver a la segunda o
tercera fase y reiniciar el proceso.

3.
3.1.

Modelo Evolutivo
Origen y evolucion

Propuesto por Mills en 1980. Sugirio el enfoque incremental o evolutivo de desarrollo como una forma de reducir la
repeticion del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirir experiencia con el sistema. Surge porque en los primeros desarrollos se poda esperar largo tiempo hasta que el
software estuviese listo. Las reglas del negocio de hoy no lo permiten.
Es un modelo iterativo, que permite desarrollar versiones cada vez mas completas y complejas, hasta llegar al objetivo
final deseado; incluso evolucionar mas alla, durante la fase de operacion. Los modelos Iterativo Incremental y Espiral
(entre otros) son dos de los mas conocidos y utilizados del tipo evolutivo.
La idea detras de este modelo es el desarrollo de una implantacion del sistema inicial, exponerla a los comentarios del
usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene
una rapida realimentacion del usuario, ya que las actividades de especificacion, desarrollo y pruebas se ejecutan en cada
iteracion.

11

3.2.

Tipos de Desarrollo Evolutivo

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema
final. El desarrollo comienza con las partes que se tiene mas claras. El sistema evoluciona conforme se anaden nuevas
caractersticas propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad
de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estan claros
para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos
requisitos.

3.3.

Fases de Modelo Evolutivo

Planeacion: en esta etapa evalua la funcion y el rendimiento que se asignaron al software durante la ingeniera del
sistema de computadora para establecer un a mbito de proyecto que no sea ambiguo, e incomprensible.
Analisis de riesgos: en esta etapa l analista se encarga de analizar los riesgos que el software a crear estara expuesto
y as encontrar la manera de corregirlos.
Construccion y adaptacion de la ingeniera: en esta etapa se construye el software, se prueba si no tiene algun
problema o para detectar errores, se instala, y luego se le brinda soporte al cliente.
Valuacion del cliente: el cliente tiene la tarea de evaluar el software para verificar si este cumple con los requisitos
que este proporciono y esta en todo la tarea de aprobar o rechazar el software.

3.4.

Caractersticas
Es evolutivo.
Posee un enfoque evolutivo para la creacion de software.
Comienza con la identificacion de las clases mas importantes.
Examina los datos que se van a manejar.
Permite la reutilizacion del software.
El ensamblaje de los componentes reduce el 70 del 100 por ciento del tiempo del ciclo del desarrollo del software y
un 84 del 100 por ciento del costo del proyecto.

12

3.5.

Fortalezas
La especificacion puede desarrollarse de forma creciente.
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad
del software.
Es mas efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

3.6.

Debilidades
Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rapido, no es efectivo producir documentos que reflejen cada version del sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software
haciendo costoso el mantenimiento.
Se requieren tecnicas y herramientas: Para el rapido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Requiere de mucha planeacion, tanto administrativa como tecnica.
Requiere de metas claras para conocer el estado del proyecto.

3.7.

Caso de Aplicacion

Como un caso en la vida real: un equipo de sonido con cada una de sus piezas o componentes; es probable que por
separado puedan ser funcionales, pero para que verdaderamente desempenen la funcion que deberan, tienen que estar
unidas formando un todo.

13

4.
4.1.

Tabla Comparativa
Modelos de desarrollo

14

Conclusion
El desarrollo de software es uno de los pilares fundamentales de la Informatica y al cual se dedican muchas horas de
esfuerzos en universidades, centros de investigacion y empresas de todos los tamanos.
Todos los modelos exitentes tienen ventajas y desventajas, con lo que, al comenzar un proyecto, habra que examinar la
situacion actual para comprobar cual es el modelo mas adecuado al caso.

15