Modelos de Desarrollo - PowerPoint PPT Presentation

1 / 41
About This Presentation
Title:

Modelos de Desarrollo

Description:

ALLSOFT S.A. de C.V. Monterrey, N.L. Introducci n Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el ... – PowerPoint PPT presentation

Number of Views:44
Avg rating:3.0/5.0
Slides: 42
Provided by: Hector78
Category:

less

Transcript and Presenter's Notes

Title: Modelos de Desarrollo


1
Modelos de Desarrollo
  • ALLSOFT S.A. de C.V.
  • Monterrey, N.L.

2
Introducción
  • Para el desarrollo de cualquier producto de
    software se realizan una serie de tareas entre la
    idea inicial y el producto final.
  • Un modelo de desarrollo establece el orden en el
    que se harán las cosas en el proyecto, nos provee
    de requisitos de entrada y salida para cada una
    de las actividades.

3
Introducción
  • Es necesario destacar el ciclo de vida del
    proyecto y el modelo de desarrollo.
  • El ciclo de vida del proyecto ayuda a controlar
    las actividades del proyecto desde el inicio al
    fin del mismo.
  • El modelo de desarrollo nos ayuda a la forma en
    la que vamos a construir el producto.
  • Ambos se complementan para generar el producto
    desde el punto de vista técnico y administrativo.

4
Modelos de Desarrollo...
  • El Modelo de Cascada.
  • El Modelo en V.
  • En Flor.
  • Prototipos
  • El Modelo de Espiral.
  • El Modelo de Procesos.
  • Desarrollo Incremental.

5
El Modelo de Cascada
  • El ciclo de desarrollo de software.
  • Este modelo tiene una secuencia ordenada.
  • El trabajo de una etapa previa es la entrada del
    siguiente proceso.
  • Provee de un gran control sobre las fechas de
    entrega y entregables.

6
El Modelo de Cascada
  • Establece criterios de entrada y salida en cada
    fase claramente definidos.
  • Dado que provee pocos puntos de visibilidad da la
    impresión de que es lento.

7
El Modelo de Cascada
Inicio
Análisis
Diseño
Código
Pruebas
Implem.
8
A Favor...
  • Excelente cuando se tiene un producto estable y
    se conoce la tecnología.
  • Es un método muy estructurado que funciona bien
    con gente de poca experiencia.
  • Provee estabilidad en los requerimientos.
  • La planeación se puede hacer anticipadamente.

9
En Contra...
  • Tiene poca flexibilidad.
  • Los proyectos en la práctica raramente siguen un
    flujo secuencial.
  • Siempre es difícil para el cliente mostrar todos
    los requerimientos explícitamente y con mucha
    anticipación.
  • El cliente debe tener paciencia.

10
En Contra...
  • Es inflexible y no motiva al cambio.
  • Poco apropiado para aplicaciones para la toma de
    decisiones.
  • Los usuarios tienen una participación limitada.

11
El Modelo en V
  • Una reexaminación del modelo del ciclo de vida
    desde el punto de vista de aseguramiento de
    calidad.
  • Cuando cada proceso termina su producto, las
    especificaciones de prueba para la probar los
    procesos están también completas.

12
El Modelo en V
Inicio
Análisis
Diseño
Plan de Aceptación Integración del Sistema
Pruebas de Integración del Sistema
Código
I.S.T
Implem.
UAT
13
Modelo en Flor
  • El propósito del desarrollo de software es el de
    desarrollar un producto de software.
  • Los equipos no deben de estar preocupados por el
    proceso de desarrollo mismo.
  • Deben de desarrollarse todas las etapas un poco
    al mismo tiempo hasta que el producto final es
    alcanzado.

14
Prototipos
  • Un prototipo es una versión preliminar de un
    sistema de información con fines de demostración
    o evaluación.

15
Construcción de Prototipos
  • Identificación de Requerimientos.
  • Diseño Rápido.
  • Utilizar el Prototipo.
  • Revisar y Mejorar.

16
Prototipos...
  • Es un método menos formal de desarrollo.
  • El prototipeo es una técnica para comprender las
    especificaciones.
  • Un prototipo puede ser eliminado.
  • Un prototipo puede llegar a ser parte del
    producto final.

17
A Favor...
  • Utiles cuando los requerimientos son cambiantes.
  • Cuando no se conoce bien la aplicación.
  • Cuando el usuario no se quiere comprometer con
    los requerimientos.
  • Cuando se quiere probar una arquitectura o
    tecnología.
  • Cuando se requiere rapidez en el desarrollo.

18
En Contra...
  • No se conoce cuando se tendrá un producto
    aceptable.
  • No se sabe cuantas iteraciones serán necesarias.
  • Da una falsa ilusión al usuario sobre la
    velocidad del desarrollo.
  • Se puede volver el producto aún y cuando no este
    con los estándares.

19
El Modelo de Espiral
  • Los productos de software son creados a través de
    múltiples repeticiones del proceso del ciclo de
    vida. Se rompen un mini-proyectos.
  • Estos modelos han sido aplicados al desarrollo de
    software.
  • Aun no han madurado al punto de ser aplicados
    como modelos de desarrollo con tiempos y
    limitaciones de costos.

20
El Modelo de Espiral
Pruebas de Integración
Validación del Diseño
Prototipo
Análisis de Riesgo
Prototipo
Diseño del Producto
Requerimientos del Software
Requerimientos
Plan de Desarrollo
Validación de Requerimientos
Prototipo
21
A Favor...
  • El producto avanza a pasos firmes solucionado
    riesgos en cada iteración.
  • El producto termina con todos los riesgos
    resueltos.
  • Se pueden incluir otros métodos de desarrollo en
    las iteraciones.
  • A medida que el costo aumenta, los riesgos se
    reducen.
  • Se tienen puntos de control en cada interacción.

22
En Contra...
  • Es complicado.
  • Requiere de mucha administración.
  • Difícil de definir los objetivos, metas que
    indiquen que podemos avanzar al siguiente ciclo.
  • Se puede caer en un desarrollo de nunca acabar.

23
El Modelo de Procesos
  • Impulsa un proceso iterativo de desarrollo.
  • Cada ciclo es una versión del producto.
  • Utiliza metas definidas para marcar la transición
    entre las distintas etapas.
  • Ofrece mayor poder de decisión a los usuarios.
  • Busca mejorar la calidad y creatividad.

24
El Modelo de Procesos
Estabilización
Idea/Necesidad
Planeación
Construcción
25
Las Metas
Liberación
Código Completo
Visión y Alcance
Especificaciones Aprobadas
26
A Favor...
  • Etapas claramente definidas con metas,
    entregables y responsables.
  • Se establecen roles asociados al modelo que
    promueven la participación de todos.
  • Involucra muy de cerca al usuario.

27
En Contra...
  • Dado que la mayoría de las decisiones son en
    consenso por el equipo en su conjunto, en
    ocasiones toman más tiempo de lo debido.
  • Para proyectos pequeños puede resultar poco
    practico.
  • El considerar versiones hace que se dejen de lado
    algunas decisiones.

28
Desarrollo Incremental
  • Permite construir el proyecto en etapas
    incrementales en donde cada etapa agrega
    funcionalidad.
  • Cada etapa consiste de requerimientos, diseño,
    codificación, pruebas, y entrega.
  • Permite entregar al cliente un producto más
    rápido en comparación del modelo de cascada.

29
Desarrollo Incremental
  • Reduce los riesgos ya que
  • Provee visibilidad sobre el progreso a través de
    sus nuevas versiones.
  • Provee retroalimentación a través de la
    funcionalidad mostrada.
  • Permite atacar los mayores riesgos desde el
    inicio.

30
Desarrollo Incremental
  • Se pueden hacer implementaciones parciales si se
    cuenta con la suficiente funcionalidad.
  • Las pruebas y la integración es constante.
  • El progreso se puede medir en periodos cortos de
    tiempo.
  • Resulta más sencillo acomodar cambios al acotar
    el tamaño de los incrementos.

31
Desarrollo Incremental
  • Se puede planear en base a la funcionalidad que
    se quiere entregar primero.
  • Por su versatilidad requiere de una planeación
    cuidadosa tanto a nivel administrativo como
    técnico.

32
A Favor
  • La solución se va mejorando en forma progresiva a
    través de las múltiples iteraciones.
  • Incrementa el entendimiento del problema y de la
    solución por medio de los refinamientos sucesivos.

33
En Contra
  • Requiere de mucha planeación, tanto
    administrativa como técnica.
  • Requiere de metas claras para conocer el estado
    del proyecto.

34
Qué Modelo Utilizar?
35
Un Proyecto...
  • Un proyecto es una organización transitoria de
    individuos dedicados a alcanzar un objetivo
    especifico dentro de un periodo de tiempo, un
    presupuesto, y un objetivo técnico.

36
Por lo Tanto...
  • Un proyecto
  • Tiene un principio y un fin.
  • Debe de tener un objetivo (debe de ser medible).
  • Requiere de un líder y de un equipo.
  • Lo que nos indica que es
  • Temporal y Unico, ya que involucra hacer algo
    que no se ha hecho antes.

37
Qué Modelo?
  • Dado que cada proyecto es único, no existe un
    modelo que se aplique al 100 a todos los
    proyectos de una organización.
  • Una organización puede contar con uno o más
    modelos de desarrollo para ser utilizados
    dependiendo del tipo de proyecto.
  • El modelo seleccionado tendrá influencia en el
    éxito del proyecto y en el tipo de decisiones que
    se deberán hacer.

38
Cuál Seguir?
  • Para seleccionar el modelo a adoptar habrá que
    hacerse una serie de cuestionamientos
  • Qué tantos son los riesgos del proyecto?
  • Qué tan claros están los requerimientos?
  • Se conoce bien la tecnología ha utilizar?
  • Visibilidad que requiere el proyecto?
  • Qué tanta planeación hacia adelante es
    requerida?
  • Qué restricciones se tienen?

39
Criterios de Exito
  • Contar con un modelo debidamente documentado.
    (entradas, salidas, entregables, aprobaciones)
  • Los documentos deben de estar actualizados.
  • La gente que participa en el proyecto debe estar
    capacitada en su uso.
  • Se debe de reforzar el uso del modelo mediante
    auditorias y revisiones.

40
Criterios de Exito
  • La alta gerencia debe soportar la utilización de
    un modelo.
  • Cualquier desviación al modelo debe ser
    documentada y aprobada.
  • Se debe de medir la eficiencia del modelo.
  • Retroalimentar y ajustar.

41
Ejercicios
Write a Comment
User Comments (0)
About PowerShow.com