Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 52 vistas

    Cuadro Comparativo

    Cargado por

    Jhon Zarate Moran
    Este cuadro compara metodologías tradicionales o clásicas de desarrollo de software, incluyendo sus ventajas y desventajas. La metodología cascada tiene una estructura sencilla pero el usuario final no se integra hasta el final. El prototipado es flexible pero caro. La metodología espiral permite evolucionar el software pero es compleja. El desarrollo incremental reduce el tiempo inicial pero requiere mucha planeación. El diseño rápido de aplicaciones es adaptable pero no se puede usar para proyectos pequeños.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    Cuadro Comparativo

    Cargado por

    Jhon Zarate Moran
    52 vistas3 páginas
    Este cuadro compara metodologías tradicionales o clásicas de desarrollo de software, incluyendo sus ventajas y desventajas. La metodología cascada tiene una estructura sencilla pero el usuario final no se integra hasta el final. El prototipado es flexible pero caro. La metodología espiral permite evolucionar el software pero es compleja. El desarrollo incremental reduce el tiempo inicial pero requiere mucha planeación. El diseño rápido de aplicaciones es adaptable pero no se puede usar para proyectos pequeños.

    Título original

    CUADRO_COMPARATIVO.docx

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Este cuadro compara metodologías tradicionales o clásicas de desarrollo de software, incluyendo sus ventajas y desventajas. La metodología cascada tiene una estructura sencilla pero el usuario final no se integra hasta el final. El prototipado es flexible pero caro. La metodología espiral permite evolucionar el software pero es compleja. El desarrollo incremental reduce el tiempo inicial pero requiere mucha planeación. El diseño rápido de aplicaciones es adaptable pero no se puede usar para proyectos pequeños.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    52 vistas3 páginas

    Cuadro Comparativo

    Cargado por

    Jhon Zarate Moran
    Este cuadro compara metodologías tradicionales o clásicas de desarrollo de software, incluyendo sus ventajas y desventajas. La metodología cascada tiene una estructura sencilla pero el usuario final no se integra hasta el final. El prototipado es flexible pero caro. La metodología espiral permite evolucionar el software pero es compleja. El desarrollo incremental reduce el tiempo inicial pero requiere mucha planeación. El diseño rápido de aplicaciones es adaptable pero no se puede usar para proyectos pequeños.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    Está en la página 1de 3

    CUADRO COMPARATIVO

    METODOLOGÍAS TRADICIONALES O CLÁSICAS

    METODOLOGÍA VENTAJAS DESVENTAJAS


    Una estructura sencilla gracias a una fase de proyecto El usuario final no se integra en el proceso de producción
    claramente diferenciadas. hasta que no termina la programación.
    CASCADA La cantidad de recursos necesarios para implementar este En ocasiones, los fallos solo se detectan una vez finalizado
    modelo es mínima. el proceso de desarrollo.
    Buena documentación
    Este modelo es de diseño flexible. Este modelo es costoso.
    Es fácil detectar errores. Tiene una documentación deficiente debido a los
    Podemos encontrar fácilmente la funcionalidad que falta. requisitos de los clientes en constante cambio.
    Existe un alcance de refinamiento, lo que significa que los Puede haber demasiada variación en los requisitos.
    nuevos requisitos se pueden acomodar fácilmente. Los clientes a veces exigen que el producto real se
    PROTOTIPADO
    El desarrollador puede reutilizarlo para proyectos más entregue poco después de ver un prototipo inicial.
    complicados en el futuro. Puede haber soluciones subóptimas debido a que los
    desarrolladores tienen prisa por construir prototipos.

    Puede adaptarse y aplicarse a lo largo de la vida del Resulta difícil convencer a grandes clientes de que el
    software de computadora. enfoque evolutivo es controlable.
    Como el software evoluciona a medida que progresa el Debido a su elevada complejidad no se aconseja
    proceso, el desarrollador y el cliente comprenden y utilizarlo en pequeños sistemas.
    reaccionan mejor ante riesgos en cada uno de los Genera mucho tiempo en el desarrollo del sistema
    ESPIRAL niveles evolutivos.
    Modelo costoso
    Permite a quien lo desarrolla aplicar el enfoque de
    construcción de prototipos en cualquier etapa de
    Requiere experiencia en la identificación de riesgos
    evolución del producto.
    Demanda una consideración directa de los riesgos
    técnicos en todas las etapas del proyecto y si se aplica
    adecuadamente debe reducir los riesgos antes de que
    se conviertan en problemas.
    En la utilización de grandes sistemas ha doblado la
    productividad.

    Con un paradigma incremental se reduce el tiempo de El modelo Incremental no es recomendable para


    casos de sistemas de tiempo real, de alto nivel de
    desarrollo inicial, ya que se implementa la funcionalidad
    seguridad, de procesamiento distribuido, y/o de alto
    parcial. índice de riesgos.
    También provee un impacto ventajoso frente al cliente, Requiere de mucha planeación, tanto administrativa
    como técnica.
    que es la entrega temprana de partes operativas del Requiere de metas claras para conocer el estado del
    Software. proyecto.

    El modelo proporciona todas las ventajas del modelo en


    cascada realimentado, reduciendo sus desventajas sólo al
    INCREMENTAL ámbito de cada incremento.

    Permite entregar al cliente un producto más rápido en


    comparación del modelo de cascada.

    Resulta más sencillo acomodar cambios al acotar el


    tamaño de los incrementos.

    Por su versatilidad requiere de una planeación cuidadosa


    tanto a nivel administrativo como técnico.
    Flexible y adaptable al cambio No se puede utilizar para proyectos más pequeños.
    Es útil cuando se necesita reducir el riesgo general del No todas las aplicaciones son compatibles con RAD
    proyecto. Si los desarrolladores no se comprometen a entregar el
    Es adaptable y flexible a los cambios. software a tiempo, los proyectos RAD pueden fallar
    Los entregables son más fáciles de mover a medida que Funciones reducidas debido al time boxing, donde las
    DISEÑO RÁPIDO DE se utilizan scripts, abstracciones de alto nivel y códigos funciones se envían a una versión posterior para
    APLICACIONES intermedios. completar un lanzamiento en poco tiempo.
    Debido a los generadores de códigos y la reutilización Requiere diseñadores o desarrolladores altamente
    de códigos, la codificación manual ha disminuido. calificados.
    Con menos personas, la productividad se puede
    aumentar en poco tiempo.

    También podría gustarte