1

Instituto Politécnico Nacional Unidad Profesional Interdisciplinaria de ingeniería y Ciencias Sociales y

Administrativas UPIICSA

Metodología Cascada

Arredondo Ochoa Luis Daniel García García Víctor Eduardo

Gómez González Samantha Giselle Reyes Flores Iván Alejandro

Zúñiga Morales Jesús Ricardo (coordinador)

Febrero 26, 2015

2

Introducción Desde el nacimiento del hombre como sociedad las organizaciones han tenido la necesidad de ser cada vez más competitivas para la obtención de mayores recursos, en la actualidad esto es lo que ha permitido el crecimiento económico de las naciones su desarrollo. La administración de dichas organizaciones ha requerido de nuevas formas de trabajo para generar productos y servicios de calidad. Un factor importante es el uso de las tecnologías de la información (TIC), las cuales ha permitido generar una ventaja competitiva sobre organizaciones del propio giro El uso de metodologías/modelos tradicionales y ágiles para el desarrollo de software no son aplicables en todos los proyectos, además, de que se tiene que invertir tiempo, dinero y esfuerzo en cada una de las áreas de las empresas desarrolladoras de software. Siguen existiendo desventajas en el uso de las distintas metodologías debido a un uso inadecuado de ellas en el desarrollo de software. En muchos casos llega a suceder que el recurso humano que se encuentra inmerso en los proyectos de desarrollo termina trabajando para la metodología, realizando un sinnúmero de actividades y de formatos en lugar de que la metodología facilite las actividades que se deben de desarrollar para el proyecto. Por ello lo que se propone en este trabajo es, dada recopilación de información obtenida de distintos lugares a cerca de lo que al tema de metodología cascada se refiere, abordaremos 5 aspectos del tema que son: La historia en la cual conoceremos datos importantes del método, su estructura, orientado a quién o qué esta este método, conoceremos las ventajas y desventajas de utilizar esta metodología y finalmente abordaremos el tema y sus aportes a las TIC

3

Índice Metodología Cascada Historia 4 Definición 4 – 5 Estructura 5 – 6 Orientación 7 Ventajas y desventajas 7 – 8 TIC 8 Conclusiones 9 Bibliografía 10

4

Método Cascada Historia En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada como un concepto inicial, un modelo que según él era defectuoso (Royce, 1970). Su trabajo explora cómo el modelo inicial podría ser convertido en un modelo interactivo, con comentarios de cada fase de influir en las fases posteriores. Es sólo el modelo inicial que recibió la notificación, su propia crítica de este modelo inicial se ha ignorado en gran medida. La expresión "modelo de cascada" rápidamente llegó a referirse no a la final de Royce, el diseño interactivo, sino más bien a su modelo puramente un orden secuencial. En este artículo se utiliza el sentido popular de la frase "cascada" del modelo. Para un modelo iterativo similar al final de la visión de Royce. A pesar de Royce intenciones para el modelo de cascada que ser modificado en un modelo interactivo, el uso del modelo de cascada como una secuencia proceso puramente sigue siendo popular, y, para algunos, la expresión "modelo de cascada" ha llegado a referirse a cualquier acercamiento al software creación que es visto como inflexible y no repetitivo. Aquellos que usan la frase "modelo de cascada" peyorativamente para modelos no-iterativo que por lo general no les gusta ver el modelo en cascada a sí misma como ingenua e inadecuada para un proceso iterativo.

Definición Definimos al modelo Cascada como un proceso secuencial, fácil de desarrollar en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento.

Es el primer modelo de proceso de desarrollo de software que se publicó y sirve como base para otras metodologías.

Se enfoca en una sola fase en la que todos los flujos de trabajo se ejecutan en forma secuencial y la siguiente fase no debe empezar hasta que la fase previa haya finalizado.

El resultado de cada fase es uno o más documentos aprobados. Esta metodología no es compatible con el desarrollo iterativo, se desarrolla

como una única y gran iteración. Es el modelo más simple conocido El resultado solo se ve al final. Si existe algún error esto tiene un resultado

catastrófico

5

Suele ser difícil para el cliente establecer todos los requisitos de manera explicita

Suele ser difícil para el cliente establecer toda la arquitectura del software de manera explicita

Se producen estados de bloqueo

Estructura

Análisis y definición de requerimientos.

Diseño del sistema

Implementación

Pruebas del sistema

Funcionamiento y mantenimiento

6

1. Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven como una especificación del sistema.

2. Diseño del sistema. El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

3. Implementación. Durante esta etapa, el diseño del software se lleva a cabo como

un conjunto o unidades de programas. La prueba de unidades implica verificar que cada una cumpla su especificación.

4. Pruebas del sistema. Los programas o las unidades individuales de programas se

integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema software se entrega al cliente.

5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente),

ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos

7

Orientación ¿Cuándo utilizarlo? La aplicación de la metodología en cascada mejora el desarrollo de proyectos de corto plazo, de poca innovación y proyectos definitivos y detallados. Para comenzar la aplicación de la metodología en cascada se necesita tener el análisis de los requerimientos bien definidos, el resultado del desarrollo dependerá de que estos requerimientos sean los adecuados para satisfacer la necesidad del proyecto. Se caracteriza por cumplir un orden secuencial en el desarrollo de sus tareas esto implica retardar el avance del proyecto ya que cada etapa inicia cuando haya finalizado la anterior siempre y cuando se haya realizado la evaluación respectiva y resuelto los errores en caso de que los hubiera tenido. Los resultados del proyecto solo se pueden conocer a partir de que se llegue a la aplicación, hasta entonces el cliente deberá tener paciencia para esperar los resultados. Esta metodología puede ser utilizada

• En proyectos que no impliquen alto riesgo, la tecnología a utilizar y los requerimientos estén bien definidos desde el principio y sea poco probable que cambien durante el desarrollo del sistema.

• Cuando se tienen grandes equipos de trabajo con roles bien definidos o existen varios grupos de trabajo y cada uno se encarga de un flujo completo de actividades.

• Algunos clientes requieren este tipo de metodología, cuando el sistema o cada etapa de desarrollo se contrata a un precio fijo. Un ejemplo de esto son los contratos con el gobierno.

Ventajas

Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy

bien los requerimientos y se conozca muy bien la herramienta a utilizar. Los artefactos que se producen en cada fase están bien definidos.

8

Desventajas

Un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

Su principal problema es su inflexibilidad, al dividir el proyecto en etapas secuenciales. En la práctica, estas etapas se superponen y proporcionan información a las otras. Por ejemplo, durante el diseño es posible identificar problemas con los requerimientos. El ciclo de vida del software no es un modelo lineal simple.

Se deben hacer compromisos en las etapas iniciales, lo que hace difícil responder a los cambios en los requerimientos del cliente.

El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera

Tecnologías de la información y comunicación En definitiva, el panorama en el desarrollo de software está sufriendo la misma problemática que el resto de sectores, tanto industriales como de servicios: la rapidez frente a la calidad, la flexibilidad frente a la fuerza de la costumbre, el método moderno adaptado a las necesidades de hoy en día frente al método tradicional y conocido. Las metodologías definen un procedimiento uniforme para el desarrollo de productos para las TIC. Es el estándar utilizado para los proyectos de la Administración Federal alemana y de defensa. Como está disponible públicamente muchas compañías lo usan. Es un método de gestión de proyectos y describe tanto métodos para la gestión como para el desarrollo de sistemas.

9

Conclusiones El objetivo principal de este trabajo de investigación fue el de dar a conocer las especificaciones de un modelo que sirviera como base para desarrollar software de calidad y que contribuya a la realización de proyectos de corte tecnológico, este modelo conocido como Cascada en general En lo que se refiere a las fases del modelo se concluyó que la etapa del análisis y diseño para el desarrollo de software se puede conjuntar en una sola y realizar el desarrollo de software de una manera más ágil, eso sin disminuir su calidad. Las etapas más importantes para las organizaciones es el análisis, diseño y desarrollo.

10

Bibliografía El Manual de Oslo y la innovación social. Arbor (2006), Echevarría, J 184(732): 609-618 doi: 10.3989/arbor.2008.i732.210 Ansoff H., Hayes I., Robert L.: El pensamiento estratégico. Ed. Trillas. Segunda edición. México, 1990. Cuervo, A. (1993). “El papel de la empresa en la competitividad”, Papeles de Economía española, no 56, pp. 362-378. http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software https://procesosdesoftware.wikispaces.com/metodo+cascada