¿Alguna vez has tenido una idea de negocio que implicaba desarrollo de software? Si este es tu caso, te habrás planteado una serie de pasos para poder llegar a la solución final de la mejor manera posible. Para cualquier aspecto del negocio, siempre se suele realizar un boceto de lo que se va a hacer. Y es igual cuando nos referimos al desarrollo de software, bien sea una aplicación para iOS o crear una web con funcionalidades específicas.
El proceso para el desarrollo de software es una estructura de pasos organizados para obtener un producto software. O lo que es lo mismo, unas guías qué nos dicen qué hacer y cuándo para obtener un resultado. También se suele denominar a este grupo de acciones, ciclo de vida del desarrollo software, ya que define cómo se inicia un proyecto, los pasos a seguir, y cómo terminar.
[Tweet "El proceso de desarrollo de software consiste en una estructura de pasos para obtener un producto"]
Existen distintos ciclos de vida que pueden ser aplicados a la construcción de software. No hay un ciclo mejor que otro, sino que cada uno se adapta a unas características particular del producto a obtener. A continuación, vamos a describir algunos de los ciclos de vida más conocidos, que pueden ser lo que estés buscando para obtener tu aplicación software.
Cómo afrontar el desarrollo de software
Modelo en cascada
Este ciclo de vida está planteado en bloques individuales que se van concatenando en el tiempo. Los grupos de actividades son los siguientes:
Requisitos: se definen completamente todas las necesidades del proyecto. Pueden ser tareas que ha de realizar la aplicación (o producto), e incluso las limitaciones que existen, como por ejemplo, que una web esté desarrollada con PHP.
Diseño: en este paso se realiza la descripción de los componentes necesarios, la arquitectura, el modelado de los datos, etc. Se obtienen respecto a los requisitos ya definidos.
Implementación: aquí el equipo de desarrollo codifica la solución con las tecnologías necesarias.
Verificación: se comprueba que todo funcione como está definido en los requisitos.
Mantenimiento: como es improbable detectar todos los errores en el proceso de desarrollo, se realiza un periodo de mantenimiento que el cliente y la empresa acuerden. Además de depurar fallos, también se incluye aquí la formación en el uso de la aplicación.
Como se puede observar, es muy importante definir bien todo lo que se quiere en la primera fase. Hay que
definir todas las necesidades de la forma más detallada posible. Este es un punto clave para obtener los resultados bosquejados previamente. Cuando el cliente define todo de una forma precisa, el
desarrollador sabe lo que tiene que hacer sin equívocos, por lo que los plazos no se alargan, los cambios de última hora no son un lastre y el proyecto se realiza correctamente. También es importante que quien realice el desarrollo, bien sea un freelance o una empresa, ayude al cliente a definir los requisitos, ya que son ellos los que tienen la experiencia en desarrollo de software.
Modelo incremental o iterativo
Este modelo es una adaptación del modelo en cascada para cuando no tenemos totalmente claros los requisitos o queremos realizar un proyecto en fases. La estrategia a seguir con el modelo incremental es
establecer varias entregas del producto, cada una con mayor funcionalidad que la anterior. Por lo tanto, al acabar el primer incremento, se empieza a desarrollar el siguiente, y así sucesivamente hasta tener el producto finalizado.
Esto permite dividir el resultado en distintos paquetes y poder ver evolucionar el resultado con cada entrega. La principal clave al utilizar este modelo es
definir previamente unos plazos de entrega y un presupuesto, ya que si vamos iterando sobre la solución, podemos llegar a un punto en el que el desarrollo se alargue tanto que no se obtendrá el producto final. Este detalle permite que se puedan modificar requisitos en cada entrega, teniendo en cuenta que si se modifica algún requisito, se consume tiempo y presupuesto, teniendo como obligación descartar otros requisitos para que el producto se realice dentro del plazo y presupuesto previstos.
Modelo por prototipos
El modelo por prototipos se utiliza principalmente para
tener una visión del producto pero sin funcionalidad. Con este modelo el cliente puede ver cómo va a quedar su aplicación y hacer las modificaciones pertinentes.
La estructura de este modelo se establece como el desarrollo de una versión previa sin funcionalidad que se entrega al cliente. Al revisar este prototipo se realizan correcciones, cambios en el formato, etc., pero sin añadir funcionalidad. Cuando se llega al prototipo deseado, se añade toda la funcionalidad.
Una estrategia eficaz para este modelo es
definir un plazo para obtener el prototipo final, con varios prototipos previos, y después establecer los plazos para el desarrollo de la solución, que suele ser aplicando un modelo en cascada.
Metodologías ágiles
Cuando se habla de metodologías ágiles suele referirse a metodologías que suscriben el manifiesto ágil: estamos
descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. Hay varios
modelos que destacan dentro de las metodologías ágil, como son Scrum y Kanban.
Scrum es un modelo que define períodos dentro del desarrollo, reuniones y roles, así como una documentación propia. Se centra en lo que el equipo de trabajo es capaz de hacer y no en crear una gran documentación la cual hay que seguir al pie de la letra.
Kanban, por otra parte, tiene elementos similares, pero es una estrategia de trabajo visual, que se centra en seguir la evolución de las tareas individualmente hasta que finalizan, pasando por distintos estados y siendo asignadas a miembros del equipo.
Para utilizar estas metodologías,
el cliente debe ser participativo, así como el equipo de desarrollo, que debe ser unido, y hacer participar al cliente de forma activa.
Conclusiones
De este resumen podemos deducir que no hay metodologías mejores o peores, sino que
cada una se adapta a un proyecto por sus propias características. También hay que tener en cuenta que en todo el proceso, es muy importante el cliente, que participa de distinta forma según la metodología, por lo que trabajar con un profesional o empresa, sabiendo qué proceso de desarrollo utiliza es beneficioso para obtener un buen resultado.
En esto también incluye a quién se contrate, pues las dos partes deben tener en cuenta que se trabaja con personas, y su gestión dentro de las metodologías es muy importante, porque son ellas las que pueden tener errores y las capacitadas para corregirlos que, como acabamos de ver, es algo que los ciclos de vida tienen muy en cuenta.