Modelos de Desarrollo de Software
- Ekipo
- 26 oct 2019
- 11 Min. de lectura
Actualizado: 27 oct 2019
Proceso de desarrollo de software
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto de software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación, se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.
El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos
Especificación de Software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
Diseño e implementacion: Se diseña y construye el software de acuerdo a la especificación.
Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente
Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:
Seguimiento y control del proyecto de software
Revisiones técnicas formales
Garantía de calidad del software
Gestión de configuración del software
Preparación y producción de documentos
Gestión de reutilizacion
Medición
La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativa mente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente,verificar continuamente la calidad, gestionar los cambios, etc.
Modelos de Proceso de Software
Se define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.”
Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software.
Modelos que se van a discutir a continuación:
Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal en sistemas
Desarrollo basado en reutilizacion en sistenas}
Desarrollo incremental
Desarrollo en espiral
1-Codificar y corregir(Code-and-fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
Escribir código.
Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento.
Este modelo tiene tres problemas principales:
Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.
Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.
El código es difícil de reparar por su pobre preparación para probar y modificar
2-Modelo en cascada
El modelo de desarrollo en cascada se originó en la industria y la construcción, donde los cambios a posterior son caros y difíciles de implementar. Cuando estás creando un producto material, realizar cambios en lo ya construido es mucho más difícil que en un programa informático. En el mundo del software, todavía no se habían implantado otras metodologías de desarrollo por lo que se adaptó el modelo en cascada que se utilizaba en otros sectores.
Fases del modelos:
El modelo de desarrollo en cascada sigue una serie de etapas de forma sucesiva, la etapa siguiente empieza cuando termina la etapa anterior.
Las fases que componen el modelo son las siguientes:
Requisitos del software:
En esta fase se hace un análisis de las necesidades del cliente para determinar las características del software a desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles técnicos. Hay que ser especialmente cuidadoso en esta primera fase, ya que en este modelo no se pueden añadir nuevos requisitos en mitad del proceso de desarrollo.
Por lo tanto, esta es la etapa en la que se lleva a cabo una descripción de los requisitos del software, y se acuerda entre el cliente y la empresa desarrolladora lo que el producto deberá hacer. Disponer de una especificación de los requisitos permite estimar de forma rigurosa las necesidades del software antes de su diseño. Además, permite tener una base a partir de la cual estimar el coste del producto, los riesgos y los plazos.
En el documento en el que se especifican los requisitos, se establece una lista de los requerimientos acordados. Los desarrolladores deben comprender de forma clara el producto que van a desarrollar. Esto se consigue teniendo una lista detallada de los requisitos, y con una comunicación fluida con el cliente hasta que termine el el tiempo de desarrollo.
Diseño:
En esta etapa se describe la estructura interna del software, y las relaciones entre las entidades que lo componen. Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.
Implementacion:
En esta fase se programan los requisitos especificados haciendo uso de las estructuras de datos diseñadas en la fase anterior.La programación es el proceso que lleva de la formulación de un problema de computación, a un programa que se ejecute produciendo los pasos necesarios para resolver dicho problema.
Al programar, tenemos que realizar actividades como el análisis de las condiciones, la creación de algoritmos, y la implementación de éstos en un lenguaje de programación específico.
Verificacion:
Como su propio nombre indica, una vez se termina la fase de implementación se verifica que todos los componentes del sistema funcionen correctamente y cumplen con los requisitos.
El objetivo de las pruebas es el de obtener información de la calidad del software, y sirven para: encontrar defectos o bugs, aumentar la calidad del software, refinar el código previamente escrito sin miedo a romperlo o introducir nuevos bugs, etc.
Instalacion y mantenimiento:
Una vez se han desarrollado todas las funcionalidades del software y se ha comprobado que funcionan correctamente, se inicia la fase de instalación y mantenimiento. Se instala la aplicación en el sistema y se comprueba que funcione correctamente en el entorno en que se va a utilizar.
A partir de ahora hay que asegurarse de que el software funcione y hay que destinar recursos a mantenerlo. El mantenimiento del software consiste en la modificación del producto después de haber sido entregado al cliente, ya sea para corregir errores o para mejorar el rendimiento o las características.
Para llevar a cabo correctamente la fase de mantenimiento, se necesita trazar un plan de antemano que nos prepare para todos los escenarios que puedan producirse durante esta fase. Para evitar futuros conflictos con el cliente, en el plan hay que especificar cómo los usuarios solicitarán las modificaciones o la corrección de errores, hacer una estimación del coste de la modificación de funcionalidades o corrección de errores, quién se encargará del mantenimiento, durante cuanto tiempo se dará soporte al software, etc.
Ventajas e Inconvenientes del desarrollo en cascada:
Ventas:
El tiempo que se pasa en diseñar el producto en las primeras fases del proceso puede evitar problemas que serían más costosos cuando el proyecto ya estuviese en fase de desarrollo.
La documentación es muy exhaustiva y si se une al equipo un nuevo desarrollador, podrá comprender el proyecto leyendo la documentación.
Al ser un proyecto muy estructurado, con fases bien definidas, es fácil entender el proyecto.
Ideal para proyectos estables, donde los requisitos son claros y no van a cambiar a lo largo del proceso de desarrollo.
Inconvenientes:
En muchas ocasiones, los clientes no saben bien los requisitos que necesitarán antes de ver una primera versión del software en funcionamiento. Entonces, cambiarán muchos requisitos y añadirán otros nuevos, lo que supondrá volver a realizar fases ya superadas y provocará un incremento del coste.
No se va mostrando al cliente el producto a medida que se va desarrollando, si no que se ve el resultado una vez ha terminado todo el proceso. Esto cual provoca inseguridad por parte del cliente que quiere ir viendo los avances en el producto
Los diseñadores pueden no tener en cuenta todas las dificultades que se encontrarán cuando estén diseñando un software, lo que conllevará re diseñar el proyecto para solventar el problema.
Para proyectos a largo plazo, este modelo puede suponer un problema al cambiar las necesidades del usuario a lo largo del tiempo. Si por ejemplo, tenemos un proyecto que va a durar 5 años, es muy probable que los requisitos necesiten adaptarse a los gustos y novedades del mercado.}
3-Desarrollo evolutivo
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
desarrollo exploratorio: donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
Prototipos desechables: donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:
Proceso no visible : Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema
A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa. Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.
4-Desarrollo formal en sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.
en esta imagen se ilustra un paradigma ideal de programación automática. Se distinguen dos
fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.
Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.
5-Desarrollo basado en reutilizacion
El modelo basado en reutilización se basa en la existencia de un número significante de componentes reutilizables, cuales se integran en el sistema, más que desarrollarlos desde cero. Aunque en la mayoría de los proyectos software existe algo de reutilización de software, habitualmente esta es una reutilización informal, “empírico”.
Las personas que trabajan en el proyecto buscan diseños o códigos similares para modificarlos a lo requerido e incorporarlos en el sistema. El enfoque orientado a reutilización se compone de un gran número de componentes de software re-utilizable, así como de marcos de trabajos para estos:
Definición de requerimientos
Análisis de componentes
Modificación de requerimientos
Diseño de sistemas con reutilización
Desarrollo e integración
Validación del sistema
La primera y la última etapa del proceso son similares pero las etapas intermedias son distintas:
Análisis de componentes: se buscan componentes para implementar la especificación de requerimientos.
Modificación de requerimientos: los requerimientos se modifican para reflejar los componentes disponibles; si eso no es posible, se buscan soluciones alternativas
Diseño de sistemas con reutilización: se diseña o se reutiliza un marco de trabajo para el sistema, tomando en cuenta los componentes disponibles; si no hay componentes adecuados, se diseñan otros nuevos.
Desarrollo e integración: los componentes disponibles se compran, los componentes no-disponibles se desarrollan y todos los componentes y los sistemas se integran
El desarrollo basado en reutilización
Ventajas:
El modelo orientado a reutilización reduce la cantidad de software a desarrollarse, los costos y los riesgos
El proceso es más rápido
Desventajas:
Los compromisos en los requerimientos son inevitables.
Existiendo el peligro de obtener un sistema que no cumple las necesidades reales de los usuarios
6-Procesos iterativos
A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.
7-Desarrollo incremental
El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.
Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.
Ventajas
Entre las ventajas que puede proporcionar un modelo de este tipo encontramos las siguientes:
Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y requisitos.Es más fácil probar y depurar en una iteración más pequeña.Es más fácil gestionar riesgos. Cada iteración es un hito gestionado fácilmente
Inconvenientes
Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar los siguientes:
Cada fase de una iteración es rígida y no se superponen con otras.Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio
8-Desarrollo en espiral
El desarrollo o modelo en espiral es un enfoque de desarrollo de software que puede ser considerado como una respuesta a los inconvenientes del desarrollo en cascada. El modelo en espiral describe el ciclo de vida de un software por medio de espirales, que se repiten hasta que se puede entregar el producto terminado. El desarrollo en espiral también se conoce como desarrollo o modelo incremental. El producto se trabaja continuamente y las mejoras a menudo tienen lugar en pasos muy pequeños.
Una característica clave del desarrollo en espiral es la minimización de los riesgos en el desarrollo de software, lo que podría resultar en un aumento de los costes totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son contrarrestados por el enfoque incremental, haciendo primero prototipos, que luego pasan al menos una vez, por las fases de desarrollo de software. El desarrollo en espiral es genérico y puede combinarse con otros métodos de desarrollo clásicos y ágiles, por lo que también se denomina modelo o desarrollo de segundo orden.
Fuentes:
Comments