Modelos de Desarrollo ALLSOFT S A de C

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

Introducción 4 Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final. 4 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. 2002 -2003, Derechos Reservados

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

Modelos de Desarrollo. . . R El Modelo de Cascada. R El Modelo en V. R En Flor. R Prototipos R El Modelo de Espiral. R El Modelo de Procesos. R Desarrollo Incremental. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

El Modelo de Cascada Inici o Análisis Diseño Código Pruebas Implem. 2002 -2003, Derechos Reservados

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 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

El Modelo en V Inici o Análisis Plan de Aceptación Integración del Sistema Implem. Diseño Pruebas de Integración del Sistema UAT Código I. S. T 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

Prototipos Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación. 2002 -2003, Derechos Reservados

Construcción de Prototipos ü Identificación de Requerimientos. ü Diseño Rápido. ü Utilizar el Prototipo. ü Revisar y Mejorar. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

El Modelo de Espiral Validación del Diseño Pruebas de Integración Análisis de Riesgo Diseño del Producto Prototipo Requerimientos Plan de Desarrollo Requerimientos del Software Validación de Requerimientos 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

El Modelo de Procesos Estabilización Idea/Necesidad Construcción Planeación 2002 -2003, Derechos Reservados

Las Metas Liberación Código Completo Visión y Alcance Especificaciones Aprobadas 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

En Contra … ü Requiere de mucha planeación, tanto administrativa como técnica. ü Requiere de metas claras para conocer el estado del proyecto. 2002 -2003, Derechos Reservados

¿Qué Modelo Utilizar? 34

Un Proyecto. . . 4 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. 2002 -2003, Derechos Reservados

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. 2002 -2003, Derechos Reservados

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

¿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? 2002 -2003, Derechos Reservados

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

Criterios de Exito 4 La alta gerencia debe soportar la utilización de un modelo. 4 Cualquier desviación al modelo debe ser documentada y aprobada. 4 Se debe de medir la eficiencia del modelo. 4 Retroalimentar y ajustar. 2002 -2003, Derechos Reservados

Ejercicios 41