Tema 2 (El Ciclo de Vida del Software) PDF

Preview

Summary

Download Tema 2 (El Ciclo de Vida del Software) PDF

Description

Introducción a la Ing. del Software y los Sistemas de Información Tema 2: El Ciclo de Vida del Software Curso 2020 – 2021

1. Concepto de ciclo de vida: Se conoce como ciclo de vida del software al marco que engloba todos los procesos, actividades y tareas involucrados en el desarrollo, operación y mantenimiento de un producto o proyecto software. Abarcando la vida del sistema desde su inicio hasta su retirada. (ISO 12207) Un proyecto se define como un agregado de actividades formado por diferentes tareas donde se generan(sistemas, modelos o documentos) y consumen(personal, tiempo, equipamiento) recursos.

2. Ciclo de vida clásico: El ciclo de vida clásico, también llamada en cascada, se caracteriza por como su propio nombre indica, realizar las actividades de forma escalonada y por consiguiente tiene como inconveniente que, para poder ver realmente el proyecto como tal, hace falta esperar prácticamente a las últimas etapas del proyecto. En este, además se asume que se conocerán todos los requisitos antes de comenzar, sin embargo, eso rara vez es cierto. Aunque es el más fácil de planificar, este sistema, tiene muchos más inconvenientes que puntos a su favor. Entre alguno de sus inconvenientes está que hasta que no se termine una fase, no puede comenzarse la siguiente. Etapas de su desarrollo: - Análisis // Partimos de la premisa de conocer los requisitos del cliente - Diseño - Implementación - Pruebas - Mantenimiento

Otro de los inconvenientes de este formato es que es necesario entregar un entregable con la documentación tras la finalización de cada etapa. Algunas de sus ventajas y desventajas se pueden ver en la siguiente tabla: VENTAJAS

INCONVENIENTES

-

Es el más antiguo por lo que tiene un lugar destacado en la Ing. Software

-

Al ser tan antiguo, carece de flexibilidad ante los cambios

-

Es muy utilizado por su simpleza

-

Se tarda mucho en acabar un ciclo

-

Es mejor que no utilizar guías

-

Se necesita conocer los requisitos desde el principio del proyecto

-

Hasta llegar a las versiones finales no habrá ninguna versión operativa del sistema.

3. Ciclo de vida evolutivos: Estos ciclos siguen una forma de espiral dividida en 3 partes o etapas (requisitos, desarrollo y evaluación), a lo largo que evolucionando se va dando lugar a conocer nuevos requisitos, desarrollarlos y hacer evaluación de ellos antes de que se llegue a la siguiente versión. La mejora de este sistema es que no requiere que se conozcan los requisitos desde el comienzo del proyecto, sino que a lo largo de este se pueden ir incluyendo. Dentro de este ciclo de vida, destacan 2 formatos: CICLO DE VIDA INCREMENTAL

CICLO DE VIDA ITERATIVO

-

Son un conjunto de ciclos de vida en cascada colocados en serie.

-

Repeticiones de ciclos de vida en cascada colocados en serie.

-

A lo largo de su proceso vamos añadiendo nuevas funcionalidades en cada ciclo.

-

Las primeras versiones suelen ser prototipos desechables

-

Es más usado en grandes proyectos.

No se necesita conocer los requisitos desde el principio del proyecto

-

Se pueden ir añadiendo requisitos y mejoras al comienzo de cada ciclo.

-

-

En cada interacción se van acabando partes hasta llegar al final

En lugar de ir acabando partes, en cada ciclo se van modificando las versiones hasta llegar a la final y deseada.

En cada uno de estos ciclos, se empiezan pidiendo los requisitos necesarios para hacer el análisis, tras ello, se continua con su posterior diseño e implementación. Una vez llegado a este punto, se muestra el avance al cliente y volveríamos a comenzar el ciclo hasta llegar a obtener un resultado satisfactorio. La gran diferencia entre ellos puede verse en la tabla anteriormente mostrada, mientras que en el método incremental se va haciendo el proyecto por partes y se le van añadiendo nuevas funcionalidades, en el método iterativo, se van haciendo diferentes versiones desde el prototipo inicial hasta su posterior finalización. Una vez tratado este último ciclo de vida, veamos más ciclos de vida que son basado en su origen por prototipos. Estos prototipos suelen ser de gran utilidad para obtener la aprobación por parte del cliente durante cualquier ciclo de vida, sin embargo, a veces es necesario revisar si es factible su realización en cuanto a esfuerzo y tiempo se trata, ya que para que estos salgan adelante, es necesaria la implicación de los usuarios. Estos prototipos pueden ser proyectos ejecutables, por lo tanto, permitiendo su reutilización o desecharse, siendo estos comúnmente realizados en papel, son los conocidos como mockups. Como ya hemos dicho, a veces los prototipos son desechables o evolucionan a través de su evolución, aunque también se le puede dar un enfoque mixto, realizando un prototipo desechable para los requisitos conocidos y para los no conocidos seguir un prototipo evolutivo. Además de estos, también existen los prototipos funcionales, estos sirven para evaluar los diferentes algoritmos antes de realizar el diseño del proyecto. Aunque parece una gran opción realizar prototipos de los proyectos siguiendo el modelo iterativo, éstos también tienen sus desventajas. A veces podemos deteriorar el modelo tendiendo a quedarnos con el modelo inicial, ya sea por gusto del cliente, por no querer volver a invertir tiempo en empezar desde cero (desechar código es algo que desagrada tanto a cliente como al programador) y preferir refinar lo ya creado o por propia relajación de los desarrolladores. 4. Ciclo de vida ágiles: Los ciclos de vida ágiles son ciclos que están formados por los evolutivos y los iterativos. Estos ciclos suelen ser de corta duración(de 2 semanas a 2 meses) y en cada iteración se incorporan los requisitos que se nos vayan pidiendo por parte de los usuarios. Estos ciclos de vida comparados con los ciclos en cascadas presentan una gran diferencia: Mientras que, en los ciclos en cascada, el tiempo y los requisitos están perfectamente definidos (y cerrados), y es a través de esa estimación por la que se obtienen los costes y la planificación de éste, en los ciclos ágiles se nos presenta un gran horizonte temporal que está mas sujeto a imprevistos y donde adaptando los costes y planificación somos capaces de obtener las características del proyecto. Los ciclos en cascada suelen ser utilizados en los organismos públicos (proyectos grandes y costosos), mientras que los ágiles son más comúnmente usados por organismos y empresas de particulares y privadas. Estos ciclos ágiles son capaces de implementar acciones del ciclo iterativo y del incremental a la vez, permitiendo así, hacer una especie de prototipo general mientras se van mejorando en algún aspecto en concreto del proyecto.

El manifiesto ágil fue un manifiesto firmado por investigadores conocidos en el ámbito de la ingeniería del software y se basa en 4 pilares fundamentales: - Individuos e interacciones vs Procesos y herramientas: La gente es el principal factor de éxito dentro de un proyecto, es por ello por lo que es mejor tener un personal a entorno cualificado, siendo preferible que el entorno sea diseñado por los desarrolladores. - Software vs Documentación: Aunque es cierto que es necesario realizar documentación sobre el proyecto, cuanto menor sea el número de estos y más breves y precisos, mejor. - Colaboración vs Negociación: La colaboración con el cliente es algo que marca el éxito de un proyecto, es por eso por lo que es mejor que éste conozca al equipo que desarrollará el mismo, ya que esto quizás sirva para que algún trabajador del proyecto forme parte a posteriori de futuros proyectos de cliente. - Respuesta al cambio vs Seguir un plan: El equipo encargado de realizar el proyecto debe tener la habilidad suficiente para en caso de surgir algún problema, responder ante éste. Es por ello por lo que es mejor tener una planificación flexible en todo cuanto sea posible. Comparativa entre el desarrollo ágil y el tradicional:

Aunque bien hemos visto que los métodos ágiles son mucho más eficientes que los tradicionales, también podemos implementar técnicas que nos sirvan de apoyo para dichos métodos haciéndolos más eficientes y efectivos:

 Refactorización (refactoring): Mejoras sobre el código fuente sin cambiar su funcionalidad.  Pruebas automáticas: Pruebas programadas en lugar de realizadas a mano.  Integración continua: Automatización de la compilación y ejecución de pruebas automáticas.  Gestión de configuración: Especialmente diseñada para apoyar la interacción y la integración continua. 5. Metodología: SCRUM: La metodología SCRUM es la más usada en la actualidad, esta está formada por iteraciones de un periodo corto de tiempo(1-4 semanas) al que llamamos sprints, durante estos e genera código ejecutable pero no se admiten cambios en el proyecto. Estos sprints se caracterizan por las Agile Meeting y las Backlog: - Agile Meeting: Son reuniones frecuentes donde intervienen todos los participantes del proyecto, en estas se explican los problemas que han surgido, los avances que han realizado cada uno y se plantean los temas de la próxima reunión. - Backlog: Es una lista donde se muestran las tareas que requieren una mayor prioridad, pueden ser de producto y de iteración.

6. Ciclo de vida del Proceso Unificado: El RUB o ciclo de vida del proceso unificado, es un ciclo de vida que está formado por un proceso iterativo e incremental propuesto por los creadores de UML, y viene definido por 6 fases: - Inicio - Elaboración - Construcción - Transición // Fase entre la implementación y la puesta en producción - Producción - Retirada Son las mismas que en el ciclo de vida clásico solo que añadiendo las 2 últimas(transición y retirada). En este, tenemos que definir cuáles son las tareas, a cada una de estas le dedicaremos un tiempo en cada una de las fases. Por ejemplo, en análisis y diseño, en la fase de inicio no hacemos prácticamente nada, mientras que al llegar a la fase de elaboración hacemos la gran mayoría del proceso.

Durante la construcción nos centramos más en la parte de diseño que en análisis, y una vez que llega la etapa de transición y producción ya es prácticamente testimonial. En cambio, en la tarea de configuración y gestión del cambio, en las primeras fases se usa poco, mientras que una vez llegada la construcción es cuando tenemos que hacer una gestión eficiente de la configuración y de las versiones, y por supuesto, este es un esfuerzo que tiene que prolongarse durante la transición y producción. 7. Ciclo de vida en Métrica 3: La metodología de Métrica 3, surgió como metodología oficial de las Administraciones Públicas en España, su última versión es del año 2000. Esta permite aplicar diferentes ciclos de vida y se divide en 3 procesos básicos: - Plan de Sistemas de Información(PSI) - Desarrollo de Sistemas de Información: • Estudio de Viabilidad del Sistema (EVS) • Análisis del Sistema de Información (ASI) • Diseño del Sistema de Información (DSI) • Construcción del Sistema de Información (CSI) • Implantación y Aceptación del Sistema (IAS) - Mantenimiento de Sistemas de Información(MSI) Esta metodología tiene un principal problema y es que no es nada ágil, además de que, al ser usado por la administración pública, son proyectos donde se invierte mucho dinero y, por consiguiente, donde para cada proceso hace falta realizar un documento muy grande explicando todo lo que se hace, además con todo lujo de detalles. Al igual que los sistemas ágiles, Métrica 3, también incluye procesos de apoyo: - Gestión de proyectos - Seguridad - Gestión de la Configuración - Aseguramiento de la Calidad 8. Pruebas en el ciclo de vida: Las pruebas del aspecto son un importantísimo, hasta el punto de que hay desarrollos donde desde el min 0, se tiene un plan de pruebas y se van guiando por las pruebas. Un ejemplo de ello puede ser el modelo en V, que se caracteriza por hacer pruebas en cada una de las fases, de modo que tenemos que hacer: - Pruebas de aceptación con el cliente - Pruebas de sistemas con el entorno del usuario (software) - Pruebas de integración con el entorno tecnológico del usuario(diseño/arquitectura) - Pruebas unitarias con la implementación de componentes(desarrollo) 9. Ingeniería inversa: Cuando tenemos proyectos con sistemas antiguos u heredados(legacy systems), lo que hacemos es analizar el resultado de la fase de desarrollo de software, para obtener un diseño, es decir, partimos del código y raíz de ahí sacamos el modelo conceptual. Este un proceso muy útil en las metodologías ágiles.

10. Reingeniería del software: La reingeniería consiste en obtener la información que se saca por ingeniería inversa para hacer un mantenimiento. De hecho, no tiene sentido hacer el proceso de ingeniería inversa si no es para realizar la reingeniería. La ingeniería inversa es darle la vuelta al ciclo de vida, ya que una vez que el producto esté funcionando, tengo que obtener entregables que me son necesarios ahora pero que no se hicieron en su momento, con el fin de hacerle un mantenimiento. El mantenimiento preventivo del efecto 2000 ha sido el mayor esfuerzo de ingeniería inversa y reingeniería en la historia de la Ingeniería del Software hasta la fecha....