Ciclo de vida del software

joan sebastián ramírez pérez2016

Agenda

• ¿Qué es una metodología?• Etapas ciclo de vida del software• Clasificación de las metodologías• Ciclos de vida existentes

¿Qué es una metodología de desarrollo de software?• 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.

• Sistematizar hace referencia a dividir el proyecto en etapas. La normalización de estas etapas ayuda a la administración y control del proyecto.

• Son los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado.

ETAPAS DEL CICLO DE VIDA

etapas del ciclo de vida• Expresión de necesidades• Especificaciones• Análisis• Diseño• Implementación• Debugging• Validación• Evolución

Expresión de necesidades

• Esta etapa tiene como objetivo elaborar un documento en el cual se reflejan los requerimientos y funcionalidades que ofrecerá al usuario el sistema a implementar (qué, y no cómo, se va a implementar).

Especificaciones

• Se formalizan los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta etapa.

Análisis• Se identifican los elementos que

intervienen en el sistema a desarrollar, su estructura, relaciones, evolución temporal, funcionalidades.

• Resultado de lo anterior se tendrá una descripción clara de qué producto vamos a construir, qué funcionalidades aportará y qué comportamiento tendrá.

Diseño• Ya se identificó qué hacer, ahora se

debe determinar cómo hacerlo (¿cómo debe ser construido el sistema en cuestión?

• Se debe definir en detalle: entidades y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases de Datos, etc.).

Implementación• Se empiezan a codificar algoritmos y

estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación o para un determinado sistema gestor de bases de datos.

Debugging• El objetivo de esta etapa es garantizar que

nuestro programa no contiene errores de diseño o codificación.

• En esta etapa no se busca saber si nuestro programa realiza lo que solicitó el usuario, esa tarea le corresponde a la etapa de implementación. En ésta se desea encontrar la mayor cantidad de errores.

• Todos los programas contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar la mayoría, si no todos, en esta etapa. También se pueden agregar pruebas de rendimiento.

Validación• Esta etapa tiene como objetivo la

verificación de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente.

• En muchos proyectos las etapas de validación y debugging se realizan en paralelo por la estrecha relación que llevan. Sin embargo, tenemos que evitar la confusión: podemos realizarlas en paralelo, pero no como una única etapa.

Evolución• En la mayoría de los proyectos se considera

esta etapa como mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades (evolución); sino la corrección de errores que surgen (mantenimiento).

• En la práctica esta denominación no es del todo errónea, ya que es posible que aún, luego de una etapa de debugging y validación exhaustiva, se filtren errores.

CLASIFICACIÓN DE LAS METODOLOGÍAS

Metodologías estructuradas

• La orientación de estas metodologías se dirige hacia los procesos que intervienen en el sistema a desarrollar, es decir, cada función a realizar por el sistema se descompone en pequeños módulos individuales.

• Es más fácil resolver problemas pequeños, y luego unir cada una de las soluciones, que abordar un problema grande.

Metodologías orientadas a objetos

• Ésta no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro.

• Esto nos permite que el código sea reutilizable. Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes.

Ciclos de vida

Ciclos de vida• Ciclo de vida Lineal• Ciclo de vida en V• Ciclo de vida Cascada

Puro• Ciclo de vida Cascada

con Subproyectos• Ciclo de Vida Iterativo• Ciclo de Vida por

Prototipos

• Ciclo de vida Evolutivo• Ciclo de vida

Incremental• Ciclo de vida en

Espiral• Ciclo de vida

Orientado a Objetos• Metodologías Ágiles

Ciclo de vida Lineal• Se descompone el proyecto

en etapas que se ejecutan una tras otra.

• Cada etapa es independiente y no hay retroalimentación entre ellas.

• Se facilita la gestión y administración.

• No apta para proyectos en los cuales se requiere retroalimentación entre sus etapas.

Ciclo de vida cascada puro• Creada en 1970 por Winston Royce.• Permite iteraciones y

retroalimentación entre sus etapas.• Es rígido, poco flexible y restrictivo.• Apoya a la planificación “simple” y

calidad del producto.• Los resultados solo se ven en etapas

finales, se requieren todos los requisitos desde el principio y un error en una etapa suele ser costosa para el proyecto.

• Debido a las criticas que recibió en los 90, se considera un modelo teórico con poca aplicación en la industria.

Ciclo de vida en v• Diseñado por Alan

Davis, contiene las mismas etapas del cascada puro solo que añade etapas de validación y verificación.

• Goza de las mismas fortalezas y falencias que el cascada puro.

Ciclo de vida Cascada con Subproyectos• Se sigue el cascada

puro pero se divide el proyecto en sub-etapas independientes que se pueden elaborar en paralelo.

• La posibilidad de tener más personas surge como fortaleza. Como desventaja aparece las dependencias que se pueden dar entre sub-etapas.

Ciclo de Vida Iterativo• Variación del cascada cuyo fin es

minimizar el riesgo entre las necesidades del usuario y el producto final derivados de malos entendidos en la etapa de licitación de requisitos.

• Cada iteración se realiza un cascada cuya entrega es una versión mejorada del producto.

• El resultado de la interacción es evaluado por el cliente y sometido a mejoras hasta conseguir un producto que satisface las necesidades.

• Se usa en proyectos en los cuales los requerimientos no están claros o en los que el cliente puede poner partes del software en producción.

Ciclo de Vida por Prototipos• Basado en prototipos como el

ciclo de vida iterativo.• Se usa cuando no se conoce el

producto o no se tiene certeza sobre las necesidades por parte del cliente. Es común en ideas de innovación o para usar tecnologías nuevas o poco probadas.

• Es el modelo preciso cuando se tiene incertidumbre sobre el producto o las tecnologías a usar.

• Por su naturaleza se hace difícil la administración de costos y tiempos.

Ciclo de vida Evolutivo• Acepta que los

requisitos del usuario pueden cambiar en el tiempo.

• Afronta la variación de los requisitos en un esquema requerimientos-desarrollo-evaluación.

• Es útil cuando desconocemos los requerimientos iniciales o los tenemos incompletos.

Ciclo de vida Incremental• Busca construir incrementando

las capacidades del software.

• Se construye el software por módulos.

• Se aplican modelos cascadas por modulo del sistema, lo que permite hacerle entregas al cliente antes de finalizar el proyecto.

• En caso de equivocación en la definición se desecha la iteración, sin afectar etapas posteriores.

• Es útil cuando el usuario necesita entregas parciales del software.

Ciclo de vida en Espiral• Diseñado por Boehm en 1988 como

evolución del modelo por prototipos.

• Se basa en ciclos repetitivos que se alimentan de la experiencia obtenida hasta llegar al producto final.

• Toma los beneficios del incremental y prototipos, pero tiene en cuenta los riesgos asociados a la incertidumbre de los requerimientos.

• Cada ciclo que se cumple (avance de espiral) genera prototipos que satisfacen al usuario o al cliente.

• Como ventajas presenta que convive con proyectos con alto grado de incertidumbre, bajo riesgo de retraso por detección de errores.

• Como desventaja tiene costo en tiempo, costo para evaluar riesgos y alta dependencia con el cliente.

Ciclo de vida Orientado a Objetos

• Data de la década del 90.

• Cada funcionalidad se considera un objeto, las propiedades del requerimiento o funcionalidad se consideran atributos y el comportamiento de los atributos se denomina método.

• Los requerimientos son abstractos lo cual le da flexibilidad.

• Se favorece la reducción de la complejidad del problema ayudando al perfeccionamiento del producto.

• El modelo aplica independiente si el lenguaje que se usará es o no es orientado a objetos.

Metodologías Ágiles

• Alistar Cockburn resume la agilidad en: entrega continua, colaboración, adaptación y mejora continua.