Metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo.

Presentación del tema: "Metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo."— Transcripción de la presentación:

1 Metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. Esta sistematización nos indica como dividiremos un gran proyecto en módulos más pequeños llamados etapas, y las acciones que corresponden en cada una de ellas, nos ayuda a definir entradas y salidas para cada una de las etapas y, sobre todo, normaliza el modo en que administraremos el proyecto.

2 Modelos de Ciclo de Vida
La ingeniería de software tiene varios modelos, paradigmas o filosofía de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos : Modelos Básicos : - Modelo Cascada - Modelo Prototipos - Desarrollo Formal por Etapas Modelos Iterativos: - Desarrollo Incremental - Desarrollo en Espiral

3 Modelo de Ciclo de Vida Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas. Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas. Facilita la administración del desarrollo y la asignación de recursos por etapa

4 Desarrollo en Cascada

5 Desarrollo en Cascada Características :
Cada fase empieza cuando se ha terminado la fase anterior Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa Para ello, se realiza una revisión al final de la fase. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados. Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto.

6 Ventajas/Desventajas
El modelo Cascada Realimentado resulta muy atractivo, hasta ideal, si el proyecto presenta alta rigidez (pocos o ningún cambio, no evolutivo), los requisitos son muy claros y están correctamente especificados. Desventajas del Modelo Cascada : Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar. El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto con altos costos.

7 Modelo Atributos Problemas Aplicabilidad Modelos básicos Modelo de cascada Fases : Análisis y definición de requerimientos Diseño de sistema y del software Implementación y prueba de unidades Integración y prueba del sistema Operación y mantenimiento Dificultad para incorporar cambios después de que el proceso parte Particionamiento inflexible del proyecto en etapas distintas Esto dificulta responder a cambios en los requerimientos del cliente Cuando los requerimientos son muy bien comprendidos y existe bajo riesgo (el equipo de desarrollo se conoce, hay experiencia en proyectos similares, lenguaje de programación conocido, etc.)

8 Modelo Evolutivo

9 Modelo Evolutivo : Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos Versión # 2 Versión # 1 ANALISIS DISEÑO CODIGO PRUEBAS PRODUCTO PRODUCTO NUEVAS FUNCIONALIDADES

10 Modelo Evolutivo Características :
En el modelo evolutivo los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo.

11 Modelo Atributos Problemas Aplicabilidad Modelos básicos Desarrollo evolutivo - Desarrollo exploratorio El objetivo es trabajar con los clientes y evolucionar hacia un sistema final desde una especificación inicial. Debería partir con requerimientos bien conocidos - Prototipos desechables El objetivo es entender los requerimientos del sistema. Debería comenzar con requerimientos pobremente conocidos Falta de visibilidad del proceso Los sistemas a menudo resultan pobremente estructurados Puede ser necesario contar con habilidades especiales (ej., lenguajes para prototipos rápidos) Para sistemas interactivos pequeños o de mediano tamaño Para partes de sistemas grandes (Ej., la interfaz del usuario) Para sistemas de corta vida útil

12 Desarrollo Formal Permiten especificar, desarrollar y verificar un sistema aplicando una notación rigurosa y matemática. Eliminan muchos de los problemas que son difíciles de superar con otros paradigmas. La ambiguedad, la incompletez y la inconsistencia se pueden descubrir y corregir, no mediante una revisión, sino mediante la aplicación del análisis matemático. Su principal desventaja es que requiere que el desarrollador y el cliente tengan conocimientos formales para poderlos aplicar y comunicarse entre sí.

13 Ventajas / Desventajas
Si bien los métodos formales constituyen un acercamiento alternativo a las metodologías de desarrollo de software, existen un número de diferencias significativas que deben de ser consideradas al pensar en instaurar los métodos formales en un equipo de desarrollo de software: Los métodos formales requieren de un nivel avanzado en matemáticas. Los modelos de elicitación de requerimientos plantean sus metas en lenguaje natural, por ello es necesario un entrenamiento a nivel de todo el equipo de desarrollo.

14 Modelo Atributos Problemas Aplicabilidad Modelos básicos Desarrollo formal de sistemas • Basado en la transformación de una especificación matemática a través de diferentes representaciones hacia un programa ejecutable • Las transformaciones son “preservantes-de-correctitud” de modo que es evidente mostrar que el programa se ajusta a sus especificaciones • Personificado a través del enfoque de “Cuarto-limpio” para desarrollar software • Etapas del proceso -Definición de requerimientos -Especificación formal -Transformación formal -Integración y testing de sistema * Requiere habilidades y entrenamiento especializados para aplicar la técnica * Dificultad para formalmente especificar algunos aspectos del sistema tales como la interfaz del usuario En los sistemas críticos especialmente aquellos donde una seguridad o un caso de seguridad debe ser realizado antes de que el sistema sea puesto en operación

15 Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

16 Desarrollo Incremental

17 Ventajas / Desventajas
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, sólo la última iteración necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

18 Combinación de modelos básicos
Modelos iterativos Combinación de modelos básicos Problemas Aplicabilidad Desarrollo incremental - El desarrollo y entrega se dividen en incrementos con cada incremento entregando parte de la funcionalidad requerida - Requerimientos de usuarios son priorizados y la prioridad más alta es incluida en primeros incrementos Una vez comenzado el desarrollo de un incremento, los requerimientos son congelados de modo que requerimientos para incrementos posteriores puedan continuar evolucionando Se corre el riesgo de construir un software débilmente estructurado y difícil de entender y mantener. Para construir el software según las prioridades de los clientes. Permite entregar al cliente los incrementos conforme se van generando.

19 Combinación de modelos básicos
Modelos iterativos Combinación de modelos básicos Problemas Aplicabilidad Desarrollo incremental Ventajas : - Valor al cliente puede ser entregado con cada incremento, redundando en una temprana funcionalidad del sistema - Incrementos del comienzo actúan como un prototipo para ayudar a determinar requerimientos de futuros incrementos - Menor riesgo de falla general del proyecto - Servicios de más alta prioridad del sistema tienden a ser más probados Se corre el riesgo de construir un software débilmente estructurado y difícil de entender y mantener. Para construir el software según las prioridades de los clientes. Permite entregar al cliente los incrementos conforme se van generando.

20 Modelo de Desarrollo en Espiral

21 Desarrollo en Espiral Propuesto inicialmente por Boehm en Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior

22 Ventajas/Desventajas
Las Actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala. Desventajas importantes: Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto. Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.

23 Combinación de modelos básicos
Modelos iterativos Combinación de modelos básicos Problemas Aplicabilidad Desarrollo en espiral Proceso es representado como una espiral en lugar de una secuencia de actividades con retrocesos Cada giro en la espiral representa una fase en el proceso No hay fases fijas tales como especificación o diseño (se gira en la espiral dependiendo de qué se requiere) Riesgos son explícitamente identificados y resueltos durante el proceso de desarrollo para el sistema que puede ser cualquiera de los modelos genéricos Para sistemas con alto riesgo

24 Bibliografía Ian. Sommerville, “Ingeniería de Software, Addison Wesley”, México (2002), 6ta edición, 692 páginas. Juan Bravo Carrasco, “Gestión de procesos”, Editorial Evolución, 2005, 398 páginas. Juan Bravo Carrasco, “Gestión de proyectos de procesos y tecnología”, Editorial Evolución, 2006, 260 páginas.