Explorando Modelos de Proceso de Software: Cascada, Ágil y Más

Modelos de Proceso de Software

Modelo en Cascada

Considerado el primer modelo empleado (Royce, 1970), consiste en la ejecución secuencial de una serie de fases. Cada fase genera documentación para la siguiente, y esta documentación debe ser aprobada antes de continuar. Una fase no comienza hasta que la anterior ha terminado por completo.

Requisito clave: Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.

Fases

• Conceptualización
• Análisis de requisitos
• Diseño
• Implementación
• Prueba
• Instalación y comprobación

Ventajas

• Es un modelo muy probado y sencillo de entender.
• Aplicable cuando el problema es estable y se trabaja con técnicas y herramientas conocidas.

Inconvenientes

• Poco realista para proyectos complejos o con requisitos volátiles.
• Supone una especificación de requisitos estable desde el inicio, lo cual es infrecuente.
• No se obtiene un producto funcional hasta muy tarde en el proceso.
• Un error grave detectado en las últimas fases puede ser muy costoso o incluso inviabilizar el proyecto.
• La falta de solapamiento entre fases puede provocar bloqueos y tiempos muertos en el equipo.

Modelo de Prototipado

Este modelo comienza con la recolección inicial de requisitos. Clientes y desarrolladores definen los objetivos globales del software e identifican los requisitos conocidos y aquellos que necesitan mayor definición.

Se realiza un diseño rápido, centrado principalmente en los aspectos visibles para el cliente (interfaz de usuario). Este diseño lleva a la construcción de un prototipo que es evaluado por el cliente. Esta evaluación se utiliza para refinar los requisitos del software.

El proceso se itera, construyendo y refinando prototipos. A menudo, el primer prototipo se desecha y sirve como base para el desarrollo del sistema final.

Ventajas

• Permite identificar y refinar los requisitos de forma incremental.
• Facilita la experimentación con diferentes alternativas por parte de los desarrolladores.
• Proporciona alta visibilidad: tanto clientes como desarrolladores ven resultados tangibles rápidamente.

Desventajas

• El cliente puede no entender la necesidad de desechar el prototipo inicial y esperar que evolucione directamente al producto final.
• Existe el riesgo de desarrollar software de baja calidad si se toman atajos en el prototipo (ej. usar un sistema operativo o lenguaje de programación inadecuado pero conocido por rapidez).

Desarrollo Evolutivo

Los modelos evolutivos se caracterizan por gestionar bien la naturaleza cambiante del software.

Características Principales

• Son iterativos: construyen versiones del software cada vez más completas.
• Se adaptan bien a:
  • Cambios en los requisitos del producto durante el desarrollo.
  • Fechas de entrega estrictas o poco realistas.
  • Especificaciones iniciales parciales o incompletas del producto.

Proceso Unificado de Desarrollo (RUP)

El Rational Unified Process (RUP) es un marco de proceso de desarrollo de software que se define por ser:

• Dirigido por casos de uso.
• Centrado en la arquitectura.
• Iterativo e incremental.
• Utiliza UML (Lenguaje Unificado de Modelado) para definir los modelos del sistema.

En RUP, el sistema software en construcción está formado por componentes software interconectados a través de interfaces.

Fases

1. Inicio: Descripción del producto final, alcance del proyecto y caso de negocio.
2. Elaboración: Especificación detallada de los casos de uso y diseño de la arquitectura del sistema.
3. Construcción: Se crea el producto a través de iteraciones, desarrollando el código y realizando pruebas.
4. Transición: Se entrega el producto a los clientes (usuarios finales) y se realizan ajustes finales.

Ventajas

• Proporciona un marco de proceso disciplinado y bien definido (racional).
• Fomenta el uso de tecnologías de componentes.

Inconvenientes

• Puede percibirse como muy complejo o pesado, muy ligado a las herramientas y métodos específicos de IBM Rational (aunque es adaptable).

Desarrollo Ágil

Un proceso ágil se enfoca en la flexibilidad y la respuesta rápida al cambio. Tiene 3 características clave:

• Es adaptable de forma incremental.
• Requiere retroalimentación constante del cliente.
• Se basa en la entrega continua de incrementos funcionales del software.

Extreme Programming (XP)

XP es una metodología ágil con las siguientes características:

• Alta visibilidad del progreso debido a ciclos de desarrollo muy cortos (iteraciones).
• Planificación incremental y flexible.
• Se adapta bien a cambios en los requisitos del negocio.
• Fuerte énfasis en pruebas automatizadas, escritas tanto por desarrolladores como por clientes (o sus representantes).
• Alta comunicación y colaboración dentro del equipo y con el cliente.
• Diseño evolutivo y refactorización continua.
• Prácticas como la programación en parejas (pair programming).
• Busca un equilibrio entre las necesidades a corto plazo (entregar funcionalidad) y las de largo plazo del proyecto (calidad y mantenibilidad).

Fortalezas

• Bueno para requisitos cambiantes o poco definidos inicialmente.
• Fundamentación práctica y orientada a resultados.

Debilidades

• Relativamente menos probado en proyectos a gran escala en comparación con modelos tradicionales.
• Funciona mejor con equipos pequeños y co-ubicados.

Scrum

Scrum es un marco de trabajo ágil que se basa en:

• Equipos auto-organizados y multifuncionales para maximizar la comunicación y minimizar la sobrecarga de gestión.
• Un proceso adaptable a cambios técnicos y de negocio para asegurar la entrega del mejor producto posible.
• Entregas frecuentes de incrementos de software potencialmente desplegables (al final de cada Sprint).
• Trabajo y equipo divididos en paquetes de bajo acoplamiento (Product Backlog Items, Sprint Backlog).
• Capacidad de construir un producto funcional cuando se requiera (al final de cada iteración).

Desarrollo Basado en Reutilización (Componentes)

Este enfoque se centra en construir software a partir de piezas preexistentes (componentes).

Conceptos Clave

• Una interfaz es una colección de operaciones que son utilizadas para especificar un servicio ofrecido por una clase o un componente. Define qué hace el componente, pero no cómo lo hace.
• Un componente es una parte física y reemplazable de un sistema que se ajusta a, y proporciona la realización de, un conjunto de interfaces. Es una unidad de composición con interfaces especificadas contractualmente y dependencias de contexto explícitas únicamente.

Un sistema software basado en componentes se modela y construye ensamblando componentes software interconectados a través de interfaces bien definidas.