Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 16 vistas

    Ciclo Vida SW 170717175212

    Cargado por

    luffy110806
    1) El documento presenta diferentes modelos de desarrollo de software como el modelo en cascada, los modelos iterativos y el modelo en espiral. 2) Se describen los principios del desarrollo basado en componentes y el desarrollo basado en ingeniería dirigida por modelos. 3) Se discuten las ventajas y desventajas de cada modelo.

    Copyright:

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

    Ciclo Vida SW 170717175212

    Cargado por

    luffy110806
    16 vistas36 páginas
    1) El documento presenta diferentes modelos de desarrollo de software como el modelo en cascada, los modelos iterativos y el modelo en espiral. 2) Se describen los principios del desarrollo basado en componentes y el desarrollo basado en ingeniería dirigida por modelos. 3) Se discuten las ventajas y desventajas de cada modelo.

    Título original

    ciclo-vida-sw-170717175212 (1)

    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?

    1) El documento presenta diferentes modelos de desarrollo de software como el modelo en cascada, los modelos iterativos y el modelo en espiral. 2) Se describen los principios del desarrollo basado en componentes y el desarrollo basado en ingeniería dirigida por modelos. 3) Se discuten las ventajas y desventajas de cada modelo.

    Copyright:

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

    Ciclo Vida SW 170717175212

    Cargado por

    luffy110806
    1) El documento presenta diferentes modelos de desarrollo de software como el modelo en cascada, los modelos iterativos y el modelo en espiral. 2) Se describen los principios del desarrollo basado en componentes y el desarrollo basado en ingeniería dirigida por modelos. 3) Se discuten las ventajas y desventajas de cada modelo.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 36

    Ing. Jonatan I.

    Peña, Mted
    ING. Wilfredo Montero M.
     “Una aproximación lógica a la adquisición, el
    suministro, el desarrollo, la explotación y el
    mantenimiento del software”
    IEEE 1074

     “Un marco de referencia que contiene los


    procesos, las actividades y las tareas
    involucradas en el desarrollo, la explotación y el
    mantenimiento de un producto de software,
    abarcando la vida del sistema desde la definición
    de los requisitos hasta la finalización de su uso”
    ISO 12207-1
    SENN:
    FABREGAS:
    1- Investigación Preliminar
    1- Requerimientos
    2- Determ. de Requerimientos.
    2- Análisis/Diseño 3- Diseño del Sistema
    3- Construcción 4- Desarrollo del Software
    4- Pruebas 5- Prueba del Sistema
    5- Producción/Mantenimiento 6- Implantación y Evaluación

    PRESSMAN: EN GENERAL USAREMOS:


    1- Análisis 1- Análisis
    2- Diseño 2- Diseño
    3- Codificación 3- Implementación
    4- Prueba 4- Mantenimiento
    5- Mantenimiento
    • Implantación Ascendente
    • Las fases deben sucederse de manera Secuencial
    • El usuario no ve resultados, sino hasta el final
    • El usuario o el ambiente pueden cambiar las
    especificaciones originales del sistema.
    • Presenta numerosos problemas Analista-Usuario
    • Manejable como proyecto
    FASE N + 1 EL USUARIO:
    FASE N

    FASE 3

    FASE 2

    FASE 1
    El usuario
    y
    ?
    su
    Sistema
    Definitivo.
    Esto no es lo
    que yo
    esperaba...
    Y al final del ciclo de Desarrollo del
    sistema.....

    ¿ Será que no supe


    explicarles mis
    requerimientos ?
    Y al final del ciclo de Desarrollo del
    sistema.....

    Tal vez ellos


    no me
    entendieron...
    Y al final del ciclo de Desarrollo del
    sistema.....

    ?
    No siempre se definen los requerimientos
    en forma:
    Completa
    Correcta y
    Consistente
    A veces resulta difícil para
    el usuario, revisar todas las Sr. Usuario:
    especificaciones Tiene que leerse
    esto, esto, esto...

    Analista
    ANALISIS DISEÑO

    IMPLEMENTACION
    MANTENIMIENTO

    Sistemas II.
    1. ANALISIS:
    1.1. Estudio Preliminar
    1.2. Levantamiento de Información
    1.3. Definición del Problema
    1.4. Elaboración del Modelo Funcional del Sistema actual
    1.5. Determinación de Requerimientos
    1.6. Descripción y Evaluación de Alternativas
    1.7. Aprobación de alternativas

    Sistemas II.
    2.DISEÑO
    2.1. Elaborar Modelo Funcional del Sistema Propuesto
    2.2. Diseño Lógico
    2.3. Elaboración y Presentación del prototipo del Sistema
    2.4. Aprobación del Sistema Propuesto

    Sistemas II.
    3. IMPLEMENTACION
    3.1. Desarrollo del Software
    3.2. Prueba del Sistema
    3.3. Puesta en Marcha

    ¿ Qué significa poner en


    Marcha un Sistema ?

    Sistemas II.
    PUESTA EN MARCHA:
    Actividad de traslado de una aplicación probada a un ambiente de producción

    - Acondicionamiento de locales
    - Organización del Cliente
    - Entregar aplicación probada
    - Elaborar datos en Vivo
    - Adiestramiento
    - Carga de datos en vivo
    - Entrega de documentación
    - Asignar Responsabilidades
    - Determinar FIN de la instalación
    Sistemas II.
     Este, aunque es más comúnmente conocido como
    modelo en cascada es también llamado «modelo
    clásico», «modelo tradicional» o «modelo lineal
    secuencial».
     CRITICAS
     No refleja realmente el proceso de desarrollo
    del software
     Se tarda mucho tiempo en pasar por todo el
    ciclo
     Perpetua el fracaso de la industria del software
    en su comunicación con el usuario final
     El mantenimiento se realiza en el código fuente
     Las revisiones de proyectos de gran
    complejidad son muy difíciles
     Impone una estructura de gestión de proyectos
     Los procesos iterativos pueden ayudar a desvelar
    metas del diseño en el caso de clientes que no saben
    cómo definir lo que quieren.
     Observaciones:
     Se evitan proyectos largos y se entrega “Algo de
    valor” a los usuarios con cierta frecuencia
     El usuario se involucra más
     Difícil de evaluar el coste total
     Difícil de aplicar a sistemas transaccionales que
    tienden a ser integrados y a operar como un todo
     Requiere gestores experimentados
     Los errores en los requisitos se detectan tarde.
     El resultado puede ser muy positivo.
     Consiste en iterar en la fase de análisis tantas veces como
    sea necesario, mostrando prototipos al usuario para que
    pueda indicarnos de forma mas eficiente los requisitos del
    sistema.
     Observaciones:
     No modifica el flujo del ciclo de vida
     Reduce el riesgo de construir productos que
    no satisfagan las necesidades de los usuarios
     Reduce costos y aumenta la probabilidad de éxito
     Exige disponer de las herramientas adecuadas
     No presenta calidad ni robustez
     Una vez identificados todos los requisitos
    mediante el prototipo, se construye el producto
    de ingeniería.
     PARA QUE SEA EFECTIVO:
     Debe ser un sistema con el que se pueda
    experimentar
     Debe ser comparativamente barato (< 10%)
     Debe desarrollarse rápidamente
     Énfasis en la interfaz de usuario
     Equipo de desarrollo reducido
     Herramientas y lenguajes adecuados

    “El prototipado es un medio excelente para recoger el


    ‘feedback’ (realimentación) del usuario final”
     PELIGROS DEL PROTOTIPO
     El cliente ve funcionando lo que para él es la
    primera versión del prototipo que ha sido
    construido con “plastilina y alambres”, y puede
    desilusionarse al decirle que el sistema aun no ha
    sido construido.
     El desarrollador puede caer en la tentación de
    ampliar el prototipo para construir el sistema
    final sin tener en cuenta los compromisos de
    calidad y de mantenimiento que tiene con el
    cliente.
     Proporciona potencial para desarrollo rápido de versiones
    incrementales. En el modelo Espiral el software se construye
    en una serie de versiones incrementales. En las primeras
    iteraciones la versión incremental podría ser un modelo en
    papel o bien un prototipo.
    En cada vuelta o iteración hay que tener en cuenta:
     Los Objetivos: qué necesidad debe cubrir el producto.
     Alternativas: las diferentes formas de conseguir los
    objetivos de forma exitosa, desde diferentes puntos de vista
    como pueden ser:
     Características: experiencia del personal, requisitos a
    cumplir, etc.
     Formas de gestión del sistema.
     Riesgo asumido con cada alternativa.
     Desarrollar y Verificar: Programar y probar el software.
     Observaciones
     Trata de mejorar los ciclos de vida clásicos y prototipos.
     Permite acomodar otros modelos
     Incorpora objetivos de calidad y gestión de riesgos
     Elimina errores y alternativas no atractivas al comienzo
     Permite iteraciones, vuelta atrás y finalizaciones rápidas
     Cada ciclo empieza identificando:
    ▪ Los objetivos de la porción correspondiente
    ▪ Las alternativas
    ▪ Restricciones
     Cada ciclo se completa con una revisión que incluye todo
    el ciclo anterior y el plan para el siguiente.
     Reconocimiento explícito de las diferentes
    alternativas.
     Identificación de riesgos para cada alternativa
    desde el comienzo.
     Al dividir el proyecto en ciclos, al final de cada
    uno existe un acuerdo para los cambios que
    hay que realizar en el sistema.
     El modelo se adapta a cualquier tipo de
    actividad adicional.
     Principios
     Existen similitudes entre distintos sistemas de un mismo dominio
    de aplicación
     El software puede representarse como una combinación de módulos
     Diseñar aplicaciones = especificar módulos + interrelaciones
     Los sistemas nuevos se pueden caracterizar por diferencias respecto a
    los antiguos
     Reduce tiempos y costes de desarrollo
     Aumenta la fiabilidad
     Dificultad para reconocer los componentes potencialmente reutilizables
     Dificultad de catalogación y recuperación
     Problemas de motivación
     Problemas de gestión de configuración.
     Se define el sistema utilizando un lenguaje
    formal.
     La implementación es automática, asistida por
    el ordenador.
     La documentación se genera de forma
    automática.
     El mantenimiento se realiza “por
    sustitución” no mediante “parches”.
     Dificultad en la participación del usuario.
     Diseños poco optimizados.

    También podría gustarte