Ingeniería de Software

Metodologías de
desarrollo de SW

Clase 1
Existen diferentes metodologías que se pueden aplicar en la gestión de proyectos de software y
equipos de desarrollo de software.

Waterfall

A principios de los años 50 surgió una de las metodologías tradicionales para desarrollar grandes
sistemas, conocido como la metodología en cascada o Waterfall. En aquella época se empezaba
a popularizar la necesidad de automatizar algunos procesos ocupando sistemas
computacionales por lo que esta metodología corresponde a la primera propuesta para gestionar
eficientemente soluciones de software.

Fases

Esta metodología consiste en 6 fases que se ejecutan de forma secuencial, es decir, no se

puede iniciar con una fase si no se termina la actual.

Figura 1. Fases en la metodología Waterfall.

Requerimientos

El objetivo de esta esta etapa consiste en identificar puntualmente cuáles son las necesidades
que el cliente o usuario final quiere satisfacer con el desarrollo del sistema.
La salida de esta fase consiste en un documento que contiene los requerimientos que el producto
de software debe satisfacer. Es importante mencionar que para esta fase no se necesita conocer
cómo se implementarán estos requerimientos solo se necesita saber cuáles son estos.

Existen varias técnicas que se pueden utilizar para esta fase, entre las más utilizadas y efectivas
está la de escribir historias de usuario.

Diseño

El objetivo de esta etapa consiste en diseñar cómo se implementará la solución de cada uno de
los requerimientos listados en la fase anterior.

La salida consiste en identificar los componentes que deberán existir en el sistema para cumplir
con todos los requerimientos.

Implementación

El objetivo de esta etapa consiste en implementar el código que se diseñó en la etapa anterior.

La salida consiste en el código que será desplegado en el ambiente productivo como solución.

Pruebas

El objetivo de esta etapa consiste en desarrollar las pruebas que verifican que la implementación
que se desarrolló en la etapa anterior cubra las necesidades del usuario y funcione como se tiene
contemplado.

La salida consiste en el diseño y código de las pruebas a ejecutar para probar que la solución
hace lo que se supone debe hacer.

Despliegue

El objetivo de esta etapa consiste en poner el sistema desarrollado en ambiente productivo para
ser utilizado por el usuario final en la forma en la que se tenía diseñada.

La salida consiste en la solución implementada en producción.

Mantenimiento

El objetivo de esta etapa consiste en arreglar errores que surgen una vez que el sistema está
siendo usado por los usuarios, así como mejoras que se van agregando al sistema conforme
este va evolucionando.
Ventajas

● Organiza el trabajo de forma secuencial por lo que todos los involucrados en el

proyecto, incluyendo el cliente o usuario final, saben en qué se está trabajando y qué
esperar de salida de cada fase.

Desventajas

● Debido a que es secuencial, no hay flexibilidad ni espacio para modificaciones o

identificación de mejoras o errores por parte del usuario final.
● Puede pasar mucho tiempo entre fases, lo que provoca que algo de una fase anterior se
vuelva obsoleto. Por ejemplo, una vez que estamos en la fase de pruebas el usuario
puede identificar que un requerimiento está equivocado o bien que debido a cambios de
negocio ya no es como se definió en la etapa de requerimientos.
● Agrega mucho riesgo e incertidumbre al proyecto debido a la rigidez de ser secuencial.
● Esta metodología no es recomendable para proyectos con alta probabilidad de cambios
y/o complejos.
● Esta metodología no es recomendable para proyectos desarrollados con el paradigma
de programación orientada a objetos.
● Esta metodología no es recomendable para proyectos que puede llevar mucho tiempo
su desarrollo.

Metodologías ágiles

Estas metodologías surgen como consecuencia de la falta de flexibilidad de la metodología de

Waterfall, aunque su origen no viene del desarrollo de software, sino de procesos de
manufactura, en donde en los años 70 se generaron diversas metodologías que permitieran
optimizar los tiempos de producción, sobretodo en las líneas de ensamble automotrices.

Existen diferentes frameworks que siguen los principios de metodologías ágiles, las 2 más
utilizadas en la industria son Scrum y Kanban.

Existe un manifiesto que todo framework de metodología ágil debe seguir:

● Se priorizan individuos e interacciones sobre procesos y herramientas

● Se prioriza tener software funcional sobre documentación extensiva
● Se prioriza la colaboración con el cliente sobre la negociación contractual
● Se prioriza la respuesta ante el cambio sobre seguir un plan al pie de la letra
A diferencia de la metodología Waterfall, esta metodología aplica las fases de desarrollo de un
proyecto de software se realizan de manera iterativa en un corto periodo de tiempo, por varios
periodos de tiempo. Esta forma de trabajo permite entregar features funcionales en poco
tiempo al usuario final, por lo que es posible identificar errores o mejoras de manera más
rápida. Es por esto que es conocida como metodología ágil.

En la Figura 2 se muestran:

Fuente: https://www.wearemarketing.com/blog/what-is-the-agile-
methodology-and-what-benefits-does-it-have-for-your-company.html

Scrum

Este framework tiene sus orígenes en los procesos de optimización de líneas de ensamble en
manufactura como Lean. Mucha de la filosofía y forma de trabajo de Scrum se basa en Toyota.

En este framework hay 3 figuras principales:

1. Product owner: Este rol representa al usuario final y a otros interesados en el proyecto
o stakeholders.

La responsabilidad principal de este rol consiste en llevar una lista de todos los features
que se deben desarrollar para cumplir con las necesidades del usuario. Estos quedan
registrados en un backlog.

2. Scrum master: Este rol es el responsable de llevar los sprints.

 La responsabilidad principal de este rol consiste en liderar al equipo de desarrollo
ayudándoles a resolver cualquier problema que pueda surgir durante los sprints.
También tiene la responsabilidad de dar a conocer y respetar los valores que sigue
scrum y su forma de trabajo.

3. Equipo de desarrollo: El equipo que implementa la solución.

La responsabilidad que cada miembro del equipo consiste en cumplir con las
responsabilidades que cada uno adquirió durante el diseño del sprint, y ayudar al resto
del equipo cuando un miembro está “atorado”.

Figura 3. Roles en Scrum

Forma de trabajo

● Sprints: Periodo de tiempo en el que se definen objetivos concretos que alcanzar. Este
periodo puede ir entre 1 a 4 semanas, normalmente 2 semanas.
● Diseño de sprint: Es una junta en la que el equipo define qué features de los existentes
en el backlog se atenderán durante el siguiente periodo de desarrollo o sprint.
● Daily meeting: 15 minutos para verificar cómo el equipo va avanzando en el objetivo(s)
del sprint e identificar si hay obstáculos.
● Sprint review: Es una junta que el equipo de desarrollo tiene con el usuario final para
mostrar los objetivos alcanzados durante el sprint. Se lleva a cabo al final de cada
sprint.
● Junta de retrospección: Una junta en la que el equipo se reúne para identificar cómo
pueden mejorar la forma de trabajo y ser más eficientes.
Ventajas

● Esta metodología es muy flexible y está centrada en brindar valor al cliente de manera
ágil, por lo que transparenta mucho del trabajo del equipo del usuario, lo que permite
tener una relación más honesta con el cliente, los usuarios y en general todos los
stakeholders involucrados en el proyecto.
● Su flexibilidad permite que el equipo y el desarrollo pueda adecuarse a los cambios y
sorpresas que pueden surgir durante el desarrollo de la solución de forma sencilla

Desventajas

● Seguir al pie de la letra Scrum puede llevar a tener exceso de juntas, para que estas no
se sientan como pérdida de tiempo que pudiera ser aprovechado para seguir
desarrollando, se debe respetar al 100% el tiempo dedicado a estas juntas sin
excederse.
● No se recomienda utilizar esta forma de trabajo si puede existir mucha rotación en los
integrantes que conforman parte del equipo de desarrollo.
● No se recomienda utilizar esta forma de trabajo para equipos de desarrollo de más de 6
personas.
●

Kanban

En este framework de trabajo se utiliza un tablero para visualizar el trabajo del equipo de
desarrollo con la finalidad de identificar la capacidad que tiene el equipo, y limitar la cantidad de
trabajo en la que se está trabajando.

Elementos que forman parte de este framework:

● El tablero kanban: El tablero que identifica las diferentes fases por las que una tarea
tiene que pasar para considerarse terminadas.
● Tarjetas de kanban: Tarjetas donde se define cuál es la tarea que se tiene que realizar.
● WIP limit: El límite de cuánto trabajo se puede tener en un periodo de tiempo.

Kanban funciona como un sistema Pull donde dependiendo de la capacidad que tiene el
equipo, se van moviendo las tarjetas del tablero de izquierda a derecha en una especie de flujo
de trabajo (flow).
En la Figura 4 se muestra un tablero Kanban de ejemplo que tiene 5 fases en el flujo de trabajo,
en cada fase se tiene un WIP particular, por lo que esa medida limita y define la cantidad de
trabajo que puede existir en cualquier momento.

Figura 4. Tablero de Kanban.

Una de las diferencias más grandes entre Scrum y Kanban es que en Kanban no se requiere
de tener roles específicos, la metodología puede funcionar sin modificar los roles que existen
en el equipo en el que se quiere implementar.

Ventajas

● Permite visualizar el trabajo del equipo de desarrollo

● Permite cuantificar cuánto puede trabajar el equipo en cada parte del flujo de trabajo,
por lo que se puede establecer un límite de cantidad de trabajo por cada fase.
● Al visualizar el trabajo, personas que no forman parte del equipo directamente pueden
identificar la cantidad de trabajo que el equipo tiene, en qué están trabajando y la fase
en la que cada issue se encuentra.
Desventajas

● Para llegar a establecer un límite de capacidad de trabajo por fase se requiere de

tiempo e iteraciones.
● Al igual que con Scrum, este marco de trabajo no se recomienda para equipos cuya
rotación de integrantes es frecuente.