Modelos y ciclos de vida del desarrollo de software
La ingeniería de software, con el fin de ordenar el caos que era anteriormente el desarrollo de software, dispone de varios modelos, paradigmas y filosofías de desarrollo, estos los conocemos principalmente como modelos o ciclos de vida del desarrollo de software, esto incluye el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema y representa todas las actividades y artefactos (productos intermedios) necesarios para desarrollar una aplicación.
El ciclo de vida de un software contiene los siguientes procedimientos:
- Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
- Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
- Diseño general: requisitos generales de la arquitectura de la aplicación.
- Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
- Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
- Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
- Integración: para garantizar que los diferentes módulos se integren con la aplicación. Este es el propósito de la prueba de integración que está cuidadosamente documentada.
- Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
- Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
- Implementación
- Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
Modelo en cascada o clásico
En ingeniería de software el modelo en cascada ―también llamado desarrollo en cascada o ciclo de vida clásico― se basa en un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, esto sugiere una aproximación sistemática secuencial hacia el proceso de desarrollo del software, que se inicia con la especificación de requisitos del cliente y continúa con la planificación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.
Modelo de prototipos
En ingeniería de software, el modelo de prototipos pertenece a los modelos de desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta manera minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la manera en que interactúa el hombre y la máquina.
Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.
Modelo en espiral
El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada, es decir, cuando se aplica este modelo, el software se desarrolla en una serie de entregas evolutivas (ciclos o iteraciones), cada una de estas entregando prototipos más completas que el anterior, todo esto en función del análisis de riesgo y las necesidades del cliente. Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y por lo cual su uso en el ámbito real es muy escaso.
Modelo de desarrollo por etapas
Es un modelo en el que el software se muestra al cliente en etapas refinadas sucesivamente. Con esta metodología se desarrollan las capacidades más importantes reduciendo el tiempo necesario para la construcción de un producto; el modelo de entrega por etapas es útil para el desarrollo de la herramienta debido a que su uso se recomienda para problemas que pueden ser tratados descomponiéndolos en problemas más pequeños y se caracteriza principalmente en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.
En este modelo pueden distinguirse las siguientes fases:
- Especificación conceptual.
- Análisis de requisitos.
- Diseño inicial.
- Diseño detallado (codificación, depuración, prueba y liberación).
Cuando es por etapas, en el diseño global estas fases pueden repetirse según la cantidad de etapas que sean requeridas.
Entre sus ventajas tenemos:
- Detección de problemas antes y no hasta la única entrega final del proyecto.
- Eliminación del tiempo en informes debido a que cada versión es un avance.
- Estimación de tiempo por versión, evitando errores en la estimación del proyecto general.
- Cumplimiento a la fecha por los desarrolladores.
Modelo incremental o iterativo
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada, es decir, este modelo aplica secuencias lineales como el modelo en cascada, pero de una manera iterativa o escalada según como avance el proceso de desarrollo y con cada una de estas secuencias lineales se producen incrementos (mejoras) del software.
Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos, ya que como se mencionó anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo se diferencia en que este busca la entrega de un producto operacional con cada incremento que se le realice al software.
Modelo estructurado
Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño estructurado o de la programación estructurada para su desarrollo, también se utiliza en la creación de los algoritmos del programa. Este formato facilita la comprensión de la estructura de datos y su control. Entre las principales características de este modelo se encuentran las siguientes:
- Generalmente se puede diferenciar de una manera más clara los procesos y las estructuras de datos.
- Existen métodos que se enfocan principalmente en ciertos datos.
- La abstracción del programa es de un nivel mucho mayor.
- Los procesos y estructuras de datos son representados jerárquicamente.
Este modelo también presenta sus desventajas entre las cuales podemos mencionar algunas:
- Se podía encontrar datos repetidos en diferentes partes del programa.
- Cuando el código se hace muy extenso o grande su manejo se complica demasiado.
En el modelo estructurado las técnicas que comúnmente se utilizan son:
- El modelo entidad-relación, esta técnica se relaciona principalmente con los datos.
- El diagrama de flujo de datos, esta es utilizada principalmente para los procesos.
Modelo orientado a objetos
Estos modelos tienen sus raíces en la programación orientada a objetos y como consecuencia de ella gira en torno al concepto de clase, también lo hacen el análisis de requisitos y el diseño. Esto además de introducir nuevas técnicas, también aprovecha las técnicas y conceptos del desarrollo estructurado, como diagramas de estado y transiciones. El modelo orientado a objetos tiene dos características principales, las cuales ha favorecido su expansión:
- Permite la reutilización de software en un grado significativo.
- Su simplicidad facilita el desarrollo de herramientas informáticas de ayuda al desarrollo, el cual es fácilmente implementada en una notación orientada a objetos llamado UML.
Modelo RAD (rapid application development)
El RAD (rapid application development: ‘desarrollo rápido de aplicaciones’), es un modelo de proceso de software incremental, desarrollado inicialmente por James Maslow en 1980, que resalta principalmente un ciclo corto de desarrollo.
Esta es una metodología que posibilita la construcción de sistemas computacionales que combinen técnicas y utilidades CASE (Computer Aided Software Engineering), la construcción de prototipos centrados en el usuario y el seguimiento lineal y sistemático de objetivos, incrementando la rapidez con la que se producen los sistemas mediante la utilización de un enfoque de desarrollo basado en componentes.
Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite que un equipo de desarrollo cree un producto completamente funcional dentro de un periodo muy limitado de tiempo sin reducir en lo más mínimo la calidad del mismo.
Modelo de desarrollo concurrente
El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo. Este tipo de modelo se puede representar a manera de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera. Este modelo de desarrollo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización.
La concurrencia se logra de dos maneras:
- Las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente;
- Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.
En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.
Proceso unificado del desarrollo de software
El proceso unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.
Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
El proceso unificado tiene dos dimensiones:
- Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento
- Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.
El refinamiento más conocido y documentado del proceso unificado es el RUP (proceso unificado racional).
El proceso unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma manera, el proceso unificado de rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del proceso unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
Fuente: Wikipedia