Qué es un proceso de desarrollo de software. Explicaciones generales de los más usados: la cascada o los procesos iterativos como RUP o Agile. Cuál es el método de desarrollo más adecuado para cada proyecto o equipo de desarrollo.
En este artículo queremos hablar de los procesos de desarrollo de programas informáticos. Debe quedar claro que estas serán unas notas generales sobre los procesos de desarrollo que existen, pero que no vamos a profundizar en ninguno, ya que para hacerlo necesitaríamos manuales o libros enteros. Por tanto, lo puedes considerar como algo de cultura general que te vendrá bien para tener una ligera idea de cómo se desarrollan aplicaciones grandes y complejas o pequeñas y sencillas.
Qué es el proceso de desarrollo de software
El proceso de desarrollo de software es el método que usamos para crear aplicaciones informáticas de cualquier tipo, que indica qué etapas tendrá que hacer el equipo de desarrollo, qué disciplinas del desarrollo se realizarán en cada etapa y cómo se organizará el mantenimiento, una vez se haya desarrollado el software.
A la vista de las aplicaciones existentes hoy en día... puedes pensar en juegos, procesadores de texto, programas de diseño... entenderás que los procesos de desarrollo pueden ser algo amplio y complejo, ya que incluye todo el flujo y actividades necesarias para crear el software, gestionar a los equipos de desarrolladores y las numerosas disciplinas que deben realizarse. Claro que todas las aplicaciones que se realizan no tienen la misma complejidad, pero lo cierto es que incluso en proyectos pequeños o medianos es importante el beneficio que se puede obtener al aplicar un proceso de desarrollo, ya que nos ayudará a aumentar sus posibilidades de éxito.
Existen diversos procesos de desarrollo que se usan en la actualidad y otros procesos de desarrollo que se utilizaron en su época y que ya están un poco en desuso. Dentro de los procesos de desarrollo actuales encontramos RUP y el Desarrollo Ágil, siendo éste último usado mayoritariamente en la industria del software. Ambos procesos son iterativos y pensados para aplicaciones de tamaño mediano o grande. Pero existen otros procesos como "La Cascada", más usado hace décadas, pero que puede ser útil todavía en la actualidad para aplicaciones pequeñas.
Vamos a ver rápidamente algunas notas de estos procesos de desarrollo, con la intención de repasar sus características generales.
Proceso de desarrollo de "Cascada"
En la cascada se realizan toda una serie de disciplinas del software, una detrás de otra en secuencia, de modo que al final del proceso se habrá realizado el programa completo. La cascada era el proceso de desarrollo que se realizaba anteriormente, antes de aparecer los procesos iterativos.
En la primera actividad de la cascada se realiza la especificación de los requerimientos del software, documentando qué se va a desarrollar. Luego se diseña el software, definiendo las partes o piezas en las que se va a distribuir el código, con las responsabilidades de cada una. Luego se programa todo el software, se prueba y finalmente se despliega en el lugar donde va a estar funcionando y disponible para sus usuarios.
Todas estas partes de la cascada que vamos realizando una detrás de otra serían las distintas disciplinas del software, siendo éstas las más importantes:
- Toma de requisitos
- Diseño
- Programación
- Pruebas
- Despliegue
Hasta ahora en el Manual de Iniciación a la programación habíamos hablado únicamente de la programación, pero como puedes ir viendo, el proceso de desarrollo incluye muchas cosas. Además, a estas disciplinas se les tendría que añadir la gestión del equipo, el análisis del software y otras cosas, pero estas serían las principales.
Entonces, en la cascada, una vez termina la fase anterior, comenzamos la siguiente. Por ejemplo, según requisitamos y sabemos todo lo que tenemos que programar, diseñamos la distribución de piezas de software que vamos a desarrollar. Una vez tememos claro qué vamos a programar y cómo, entonces lo programamos. Una vez que se ha programado todo, entonces se prueba, etc. Lo que es importante de entender es que el proceso no incluye iteraciones, sino que se realiza en una sola secuencia y no comienza una disciplina nueva hasta que no acaba la anterior.
El problema de la cascada es que, una vez terminado el software completo, se despliega y se entrega al cliente. Una vez el cliente ve cómo ha terminado el proyecto a menudo se detecta que faltan cosas que no se habían contemplado en los requisitos y que, por tanto, no se habían desarrollado. Esto suele ocurrir de manera natural, la mayoría de las veces porque es muy complicado prever todas las cosas que pueden facilitarle la vida al usuario de la aplicación. Otras veces ocurre porque simplemente el cliente no tiene claro exactamente lo que quiere y cómo lo quiere.
Como resultado, en muchas ocasiones las aplicaciones desarrolladas con el proceso de la cascada no son todo lo útiles que podrían ser, o les faltan cosas para que realmente puedan usarse. Esto genera frustración y fricciones entre el cliente final, que no tiene lo que realmente necesitaba, y el equipo de desarrollo, al que a menudo se le exigen partes del programa que realmente no se habían presupuestado.
Esta situación puede acabar de muchas maneras. El cliente puede ver tan frustradas sus expectativas que simplemente abandona el proyecto. El equipo de desarrollo puede acabar haciendo cosas que estaban fuera de presupuesto, reduciendo sus márgenes de ganancia y trabajando a disgusto. En el mejor de los casos, se tiene que recomenzar todo el proceso desde la realización de presupuesto con la toma de requisitos, diseño, programación… con una nueva cascada.
RUP
RUP son las siglas de Rational Unified Process y se trata de un proceso de desarrollo maduro, ampliamente especificado y con unas guías definidas de manera muy precisa. Es un proceso iterativo, lo que implica que el software se irá realizando en diversas etapas en las que cada vez se van acercando más a la solución final del proyecto.
La cascada sería como una única iteración en la que se realizan todas las disciplinas en orden, mientras que RUP es un proceso iterativo, que varias disciplinas en una iteración. Podrían ser todas o al menos una cantidad de ellas en cada iteración.
Además de iteraciones en RUP se disponen de etapas, que son conjuntos de iteraciones. Dependiendo de las etapas de desarrollo unas disciplinas u otras tendrán más presencia en sus iteraciones. Por ejemplo, en las iteraciones del principio en RUP se dedica más tiempo en la toma de requisitos del software y en el diseño de las partes más complicadas. A medida que el proyecto avanza, en iteraciones más hacia la mitad del proceso, se van acometiendo mayormente las partes de programación, pero a la vez que se sigue requisitando y probando. Al final del proceso se realizan mayormente disciplinas de pruebas y despliegue, pero se sigue desarrollando y quizás requisitando. Además, en todas las etapas e iteraciones se dedica tiempo a la gestión del proyecto.
Lo que debe quedar claro es que este proceso no se realiza como en la cascada: todo en una única secuencia, una cosa detrás de otra. En cambio, en cada iteración pueden surgir pequeñas entregas que pueden permitir a los clientes saber si hay cosas que no están saliendo como deberían. También, a medida que avanza el proyecto, es más sencillo saber dónde estamos y lo que nos queda, con lo que se puede ajustar el calendario de entregas y el presupuesto final de una manera más fiable.
En RUP el arquitecto del software es quien decide qué partes del proyecto se van a realizar primero. Como se ha dicho, el arquitecto decidirá comenzar siempre por aquellas partes que resulten más complejas y que condicionen el resto del desarrollo. Esto permite que desde el principio del proyecto se liberen las tareas que más podrían retrasar las entregas, dejando para el final las partes más fáciles y cuyos tiempos de desarrollo y costos son mucho más predecibles. Por lo tanto, a las pocas semanas de inicio del proyecto es posible tener unas predicciones más fiables del tiempo que se tardará en completar todo el desarrollo de la aplicación.
Proceso de desarrollo Ágil
El proceso de desarrollo Ágil, a menudo llamado simplemente "Agile" por su término en inglés, se caracteriza por ser iterativo, igual que RUP, y donde en cada iteración se realizan pequeñas aportaciones en todas las disciplinas del software. Es decir, en cada iteración se toma requisitos de las partes que se van a desarrollar, se diseña, se desarrolla, se prueba y se despliega.
Para la elección de los objetivos de cada iteración en el proceso ágil los gestores del proyecto se centran junto con el cliente en la creación de las partes que puedan aportar mayor valor al modelo de negocio del cliente, desarrollando al principio el mínimo posible para que la aplicación se pueda ir usando. Esto es ideal porque así en cada iteración surgen entregas de pequeñas partes del programa, que el cliente puede validar.
En las metodologías ágiles se le exige al cliente tomar parte activa del proyecto y estar más vinculado en el proceso de desarrollo. No solo debe participar para decidir qué se va a desarrollar en cada iteración, sino que además idealmente debería estar disponible en todo momento para resolver de inmediato cualquier duda sobre cómo se va a desarrollar cualquier parte de la aplicación, creándose programas que responden más a las necesidades reales del cliente.
Existen muchas diferencias entre RUP y los procesos Ágiles. Por un lado RUP es más pesado en el sentido en el que sus procesos generan más documentación y tienen una ruta más definida. Los ágiles no documentan tanto y hay disciplinas que se hacen todas a la vez, por ejemplo a medida que se programa se diseña y se prueba al mismo tiempo.
Pero lo más destacado es que en RUP las aplicaciones se realizan comenzando por las partes más difíciles y que condicionarán el desarrollo de todas las siguientes partes, mientras que los ágiles comienzan por lo que pueda aportar valor al negocio. Esta característica hace ideal el desarrollo ágil para startups que necesitan un producto mínimo viable cuanto antes, que puedan ir usando y probando sus usuarios, que son los que con sus necesidades decidirán qué partes les pueden aportar mayor valor.
Por una parte, en RUP es positivo centrarse en las partes más complejas, porque así da una noción más temprana del tiempo que se necesitará para desarrollar el proyecto completo y permitirá que, a medida que otros desarrolladores se incorporen, sea más fácil que tengan una dirección bien definida. Paralelamente si los desarrolladores no son tan experimentados no tendrán tanto problema, ya que las partes que tendrán que desarrollar serán las más sencillas y sistemáticas.
Pero por otra parte en Agile es interesante que se centren en lo que puede hacer que la aplicación sea útil desde el principio. Esto indica que en Agile será más fácil crear aplicaciones que se adaptan verdaderamente a las necesidades del cliente, pudiendo realizar los cambios en las aplicaciones a medida que se desarrollan y se van usando. El cliente debe participar más, indicando qué cosas dan más valor y qué cosas aportan menos, por lo que el presupuesto estará dirigido siempre a mejorar aquellas áreas de la aplicación que realmente están resultando útiles para el negocio.
En Agile no importa que haya que cambiar cosas con más frecuencia, ya que no hay líneas generales desde el inicio. Se exige delos desarrolladores Agile tener muchos conocimientos de todas las disciplinas y gracias a su amplia experiencia no les asustan los cambios, porque son capaces de llegar a diseños flexibles con facilidad. Además, técnicas como el refactoring son capaces de reaccionar y rediseñar el software para hacerlo más adaptable, sin que ello implique que se rompa o se cambie nada.
Adaptaciones del Agile
También queremos remarcar que Agile es un proceso más nuevo, en el cual muchas personas han participado y sobre el que se realizan todavía aportaciones frecuentes. No está claro que exista un método determinado, sino una serie de prácticas y técnicas sobre las que cada equipo realiza pequeñas adaptaciones para que encaje en el desarrollo de sus propios productos, o adaptando los flujos a medida que su propia experiencia lo va dictando.
Por tanto en el mundo de desarrollo Ágil todavía hay mucho ruido y surgen todos los años nuevos conceptos, técnicas, arquitecturas, etc. que van definiendo poco a poco las mejores prácticas. Esto da como resultado que cada equipo de desarrollo que dice ser ágil en realidad está aplicando su propio concepto de agilidad, trayendo las dinámicas que les resultan útiles, sin que exista un método siempre claro y definido como sí ocurre en RUP.
Qué proceso de desarrollo es más adecuado
Entre todos estos procesos de desarrollo no hay un claro vencedor para todos los casos, porque a menudo la mejor opción vendrá dada por el propio objetivo del software a desarrollar.
Primero es importante saber qué tipos de proyecto tenemos entre manos. Si es algo muy sencillo, donde todo está muy claro, puede ser es más que suficiente aplicar el método de la cascada.
Un proyecto sencillo puede ser aquel en el que un único desarrollador puede terminarlo en una semana o un par de ellas. También podrían ser proyectos quizás un poco más amplios, pero donde el desarrollador o desarrolladores tienen muy claras cuáles son las partes a programar, las tecnologías que se van a utilizar y, en resumen, no hay puntos oscuros que puedan traer dificultades.
En proyectos donde el tiempo de desarrollo será muy reducido y no hay mayores dificultades técnicas, la cascada puede ser suficiente porque hay muchas menos posibilidades que lo que desarrolle no se ajuste a las verdaderas necesidades del cliente. Además, el tiempo y dinero invertido para el desarrollo no será tan grande y la capacidad de reacción es rápida, ya que la entrega se produce enseguida.
Si el proyecto ya es más complejo, es necesario acudir a un proceso de desarrollo iterativo, porque la cascada a menudo es contraproducente, ya que es un proceso muy rígido. Si hacemos todas las fases una detrás de otra como define la cascada, los problemas de definición de los requisitos solo se encontrarán al final, cuando el trabajo ya ha sido presentado. Como hemos dicho, eso producirá insatisfacción del cliente o directamente el fracaso del proyecto.
Los procesos iterativos permiten ajustarse mejor a proyectos más complejos, donde el desarrollo se irá realizando progresivamente y donde los problemas de interpretación o definición de los requisitos aparecerán cuando todavía hay márgen de maniobra.
Para decidirse entre un método u otro, de los dos marcados como iterativos, podemos tener en cuenta sus ventajas e inconvenientes.
- RUP se adaptará bien en proyectos grandes o muy grandes y donde el objetivo está bien definido desde el principio y cuando existen en el equipo diversos perfiles de desarrolladores, con diversas habilidades y mayor y menor experiencia.
- El proceso Agile se adaptará bien para proyectos medianos y grandes que se asume pueden ir cambiando bastante a lo largo del tiempo, donde además todo el equipo de desarrollo tiene elevada experiencia y donde todos los desarrolladores son capaces de realizar de manera general prácticamente cualquiera de las disciplinas.
También el tipo de cliente puede ser clave para que un método de desarrollo sea más adecuado:
- RUP es ideal para clientes que quieren las cosas claras y quieren saber cuanto antes qué tiempo llevará el desarrollo del proyecto y a qué coste. Quizás en las primeras iteraciones las previsiones de tiempos y costes sean solamente aproximadas, pero a poco que el proyecto avance y después de las primeras iteraciones en las que se han desarrollado las guías arquitectónicas del proyecto y las partes más oscuras, será muy sencillo acertar con las previsiones de tiempo y coste.
- La propuesta de los ágiles a menudo trata de evitar dar tiempo y presupuesto final, porque asumen que dependerá de la marcha del proyecto y la evolución que tendrá a medida que se le añaden más funcionalidades o se tenga que cambiar las funcionalidades desarrolladas para adaptarse a las nuevas demandas. Ellos simplemente requisitan lo que son capaces de hacer en una iteración (que suele consistir en una o dos semanas de trabajo). Por tanto, atendiendo a lo que aporte valor para el cliente, serán capaces de decirte qué preveen hacer en una o dos semanas que dura una iteración. No sabrán decir el coste completo del proyecto, ya que durará el tiempo que sea necesario hasta que se cumplan los objetivos, y mientras el cliente solicite cambios o mejoras.
Al menos esa es la propuesta original de los métodos ágiles. Sin embargo, como no definir el tiempo e inversión completa desde el inicio resulta a menudo una situación muy molesta para los clientes, en la práctica los encargados del proyecto tienen que hacer previsiones más o menos acertadas. Aunque eso no es Agile, sino una de las muchas adaptaciones que se van realizando para que el método encaje en las costumbres de los equipos de desarrollo y las expectativas de los clientes.
Debido a la falta de concreción de los métodos ágiles con respecto a los tiempos y presupuestos de los proyectos completos, este método a veces es poco atractivo para algunos clientes y requiere adaptaciones. Sin embargo para otros como las startups, donde es importante tener algo viable cuanto antes y no se sabe muy bien dónde se va a llegar, Agile es una opción que encaja muy bien de manera natural.
Conclusión
Como os podéis imaginar, para cada uno de los procesos de desarrollo que hemos comentado en este artículo existen libros enteros para definirlos y especificarlos detalladamente. Aquí solamente hemos aportado un poco de visión global que puedes tomar como "cultura general".
Si deseas estudiar con detalle los procesos de desarrollo te recomendamos la lectura de libros publicados sobre cada uno de ellos o, todavía mejor, hacerte los cursos de EscuelaIT sobre estos temas. Por ejemplo tienes el curso de RUP o el Curso de Agile.
Si quieres saber más sobre los procesos de desarrollo te recomendamos esta charla en el canal de Youtube donde se abordaron de manera global.
Miguel Angel Alvarez
Fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Com...