VENTAJAS /DESVENTAJAS

Presentación del tema: "VENTAJAS /DESVENTAJAS"— Transcripción de la presentación:

1 VENTAJAS /DESVENTAJAS
CUADRO COMPARATIVO MODELO ENFOQUE VENTAJAS /DESVENTAJAS APLICABILIDAD MODELO EN CASCADA El inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. Los proyectos raras veces siguen una evolución secuencial. No todos los requisitos son expuestos, al principio, de forma explícita como requiere este modelo. El cliente debe tener paciencia, ya que la aplicación sólo estará disponible en un estado muy avanzado del proyecto. Ampliamente criticado desde el ámbito académico y la industria Utilizado cuando existen especificaciones amplias de los requerimientos del cliente. MODELO BASADO EN PROTOTIPOS Prototipos: No posee la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, alto grado de participación del usuario. El cliente puede pensar que el prototipo es una versión acabada. Pueden llegar a pasarse por alto la calidad del software global o el mantenimiento a largo plazo. Las herramientas elegidas pueden ser inadecuadas. La clave del éxito de este modelo consiste en definir bien, desde el principio, las reglas del juego. Alto grado de participación del usuario Se utiliza si en el mercado no se encuentra el producto pero el cliente desea resultados inmediatos. Conveniente en caso de ser necesario desarrollar módulos Para sistemas interactivos pequeños o de tamaño pequeño. Para partes de sistemas grandes Para sistemas con vida corta.

2 VENTAJAS /DESVENTAJAS
CUADRO COMPARATIVO MODELO ENFOQUE VENTAJAS /DESVENTAJAS APLICABILIDAD MODELO INCREMENTAL O EVOLUTIVO Modelo Lineal-Secuencial con el Modelo Basado en Prototipos El sistema no se entrega de una vez, sino que se divide y se entregan incrementos. Con cada incremento se entrega la parte de la funcionalidad que se ha establecido. Los requisitos son priorizados. Los requisitos con una más alta prioridad se incluyen en los incrementos más tempranos. Los requisitos de un incremento son inamovibles. Sin embargo estos puede verse modificados en incrementos posteriores. Este proceso se repite hasta la obtención de un producto completo. Sin embargo el modelo incremental se centra en la entrega de un producto operativo en cada incremento. Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos. Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos. Existe un riesgo bajo de fallar en el proyecto total. Los servicios del sistema con la prioridad más alta tienden a ser los más probados. Puede ser difícil ajustar los requisitos a los incrementos. Reemplazar el antiguo desarrollo con uno nuevo que satisfaga las nuevas necesidades según las redefiniciones del problema Manejo de Versiones MODELO ESPIRAL Es una mejora del Modelo Basado en prototipos Cada vuelta en la espiral representa una fase del proceso. No hay fases fijas, cada vuelta en la espiral determina las actividades a realizar. La dimensión radial representa el coste acumulado en la financiación de las fases. La dimensión angular representa el progreso hecho en completar cada ciclo de la espiral. Un ciclo a través de la espiral es simular un paso a través de un modelo en cascada Requiere comunicación permanente con el cliente por lo tanto si se cambia el contacto con le cual se realiza desarrollo es necesario que esté al tanto de lo realizado y lo pendiente, cliente debe ser gran conocedor del sistema. Utilizado para el desarrollo de aplicaciones complejas y/o específicas. (Ej. Investigación Genética)

3 ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

4

5 EXPRESIÓN DE NECESIDADES
Tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Parte de las necesidades del cliente entonces el documento resultante tiene como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial. Puede resultar un acuerdo comercial

6 EXPRESIÓN DE NECESIDADES
Tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Parte de las necesidades del cliente entonces el documento resultante tiene como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial. Puede resultar un acuerdo comercial

7 Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones).

8 ESPECIFICACIONES Formaliza los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Se obtiene un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).

9 ANÁLISIS Determina que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, Descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes: Funcional, Estático y Dinámico.

10 Diseño Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

11 Implementación Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos

12 Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).

13 Validación Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).

14 Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).  

15 La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa sólamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).

16 El alcance del ciclo de vida : depende de hasta dónde deseamos llegar con el proyecto.
La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar). La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida: según el ciclo de vida que adoptemos. Hay factores que no están reflejados en el ciclo de vida ni en las técnicas de desarrollo como son: Cumplimiento de entrega Tiempo Calidad costo

17 RIESGO Cuando hablamos de riesgo, nos referimos a la probabilidad que tendremos de volver a retomar una de las etapas anteriores, perdiendo tiempo, dinero y esfuerzo.

18 RIESGO Como prevenir los riesgos que se nos presenten en un proyecto?.

19 PARA TENER EN CUENTA...

20 MODELOS DE DESARROLLO Es una descripción de un proceso del software que se presenta desde una perspectiva particular. Por su naturaleza, los modelos son simplificaciones, por lo cual un modelo de proceso del software es una abstracción de un proceso real. Estos modelos incluyen actividades que son parte de los procesos y productos de software y de los roles de las personas involucradas

21 MODELOS DE DESARROLLO MODELO DE CASCADA MODELO EN V
MODELO DE CONSTRUCCIÓN DE PROTOTIPOS MODELO EN ESPIRAL MODELO DE PROCESOS MODELO INCREMENTAL

22 MODELO DE CASCADA Llamado ciclo de vida clásico o básico.
Tiene una secuencia ordenada. El trabajo de una etapa previa es la entrada al siguiente proceso. Provee de un gran control sobre las fechas de entrega. Consta de 6 etapas que son: Investigación preliminar, determinación de requisitos, diseño del sistema, desarrollo del sistema, prueba del sistema e implantación y evaluación

23 MODELO DE CASCADA

24 MODELO DE CASCADA

25 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. Recomendado para elaboración de proyectos grandes.

26 EN CONTRA... Tiene poca flexibilidad.
Los proyectos en la práctica raramente siguen un flujo secuencial. Siempre es difícil para el cliente mostrar los requerimientos explícitamente y con mucha anticipación. El cliente debe tener paciencia. No motiva al cambio. Poco apropiado para aplicaciones para la toma de decisiones. Usuarios con participación limitada.

27 EJEMPLO MODELO DE CASCADA
Una comida en un restaurante... REQUISITOS: Pedido del cliente. DISEÑO: Reseta DESARROLLO: Preparación del plato PRUEBAS: Visto bueno del chef IMPLANTACIÓN: Servir el plato EVALUACIÓN: El cliente

28 MODELO EN V En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relación entre ellas. Es una versión mejorada del modelo cascada, incorpora o se enfoca, de mejor manera al control de calidad, este modelo también muestra la relación iterativa entre las distintas fases en el proceso de desarrollo de software y añade dos partes que son:

29 MODELO EN V La VERIFICACIÓN: Que tiene relación con la pregunta...
¿ Se está haciendo correctamente el producto? La VALIDACIÓN: Que tiene relación con la pregunta... ¿ Se está haciendo el producto?, es decir, la demostración de que el software cumple con exactitud la finalidad pretendida.

30 MODELO EN V

31

32 A FAVOR... Se trata de un proceso ideal, por su robustez, para proyectos pequeños, con equipos de una a cinco personas. También es ideal, por su claridad, para toda esa gente que nunca ha programado siguiendo una metodología.

33 En algunos proyectos de desarrollo de software, puede ocurrir que en un test salga determinado error en cuanto a requerimientos de usuario o del sistema, por lo cual se corre el riesgo de estar obligado a retroceder bastante para encontrar el error y corregirlo. El modelo representa, en forma de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto.

34 El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero. El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.

35 Codificación: Cortar y coser
EJEMPLO MODELO EN V Elaboración de unos zapatos... Inicio: Describir que zapatos necesitan los clientes Especificación: Cual es la moda Fase Funcional: Deportivos, Formales, sandalias Fase Diseño: Elaboración plantillas, formas... Codificación: Cortar y coser Fase Test Diseño: Verificar talla correcta Fase Test Funcional: Verificar si cumple necesidades y estándares Fase Test Especificaciones: Verificar si el modelo cumple las expectativas del cliente Fin del proyecto: Zapato terminado

36 MODELO DE PROTOTIPOS Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación. Identificación de requerimientos Diseño rápido Utilizar el prototipo Revisar y Mejorar

37 MODELO DE PROTOTIPOS caracteristicas
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.

38 MODELO DE PROTOTIPOS

39 MODELO DE PROTOTIPO

40 A FAVOR… Útiles 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.

41 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.

42 EJEMPLO MODELO DE PROTOTIPOS
Elaboración de un pantalón… RECOLECCIÓN Y REFINAMIENTO DE REQUISITOS: Toma de medidas y Diseño del pantalón. DISEÑO RÁPIDO: Esquema, boceto o molde CONSTRUCCIÓN DEL PROTOTIPO: Corte y confección EVALUACIÓN DEL PROTOTIPO POR EL CLIENTE: Falencias REFINAMIENTO DEL PROTOTIPO: Corrección de falencias PRODUCTO DE INGENIERÍA: Pantalón terminado

43 MODELO EN ESPIRAL Los productos de software son creados a través de multiples repeticiones del proceso del ciclo de vida. Se rompen los mini-proyectos. Este modelo 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.

44 MODELO EN ESPIRAL

45 GRAFICO MODELO EN ESPIRAL

46 MODELO EN ESPIRAL

47 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.

48 EN CONTRA Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. Se puede caer en un desarrollo de nunca acabar.

49 MODELO 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. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,

50 MODELO 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.

51 GRÁFICO MODELO INCREMENTAL

52 MODELO INCREMENTAL

53 A FAVOR 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 acortar el tamaño de los incrementos. Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

54 MODELO 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. 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.

55 EN CONTRA Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto. Cada incremento debe ser pequeño para limitar el riesgo (menos de líneas). Cada incremento debe aumentar la funcionalidad.

56 TIPS PARA ELEGIR UN MODELO!!!

57 EN UN PROYECTO…. Todo proyecto es una organización temporal de individuos, con el fin de alcanzar un objetivo especifico dentro de: un periodo de tiempo, un presupuesto, un objetivo técnico.

58 Lo que nos indica que es:
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 Único, ya que involucra hacer algo que no se ha hecho antes.

59 Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a todos los proyectos.
Una empresa 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.

60 Cual elegir? Para seleccionar el modelo a adoptar habrá que hacerse una serie de preguntas: ¿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?

61 Para tener éxito!!! 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.

62 PARA TENER ÉXITO 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.