Universidad de San Carlos de Guatemala

Facultad de ingeniera
Escuela de ciencias y sistemas
Software Avanzado
Escuela de vacaciones Diciembre 2015
Kevin Barrientos Castellanos
2012-12631

Metodologas de desarrollo
Todo proyecto de desarrollo de software debe de ser controlado de manera que se minimicen los
posibles riesgos que surgen durante el mismo. Si no se tiene claro lo qu se debe de hacer y el momento
en qu se debe de hacer el proyecto puede fracasar.
Por ello conforme la tecnologa avanza se han elaborado diferentes metodologas de desarrollo. Estas
metodologas establecen un marco de trabajo usado para estructurar, planificar y controlar el proceso de
desarrollo.
Entre las metodologas tradicionales ms comunes podemos mencionar: modelo cascada tan bien
conocido como tradicional, desarrollo iterativo incremental, desarrollo basado en prototipos y el
modelo espiral. Estas metodologas se caracterizan por tener un proceso bien definido sin embargo a
medida que la tecnologa avanza, las condiciones de desarrollo tan bien cambian. Por ejemplo antes el
desarrollo de software era un proceso en el que el cliente no participaba mucho y ahora se requiere de
su constante presencia a lo largo de las fases. Adems los equipos de trabajo han cambiando, se han
vuelto multidisciplinarios, situados en diferentes puntos geogrficos probablemente incluso en
diferentes pases. As pues han surgido metodologas que se adaptan de mejor manera y que han tenido
auge en los ltimos aos, estas son las llamadas metodologas giles entre las que podemos mencionar:
XP, Scrum y Kanban.
A continuacin se describe un pequeo resumen de cada metodologa. Aunque, en general un proyecto
de desarrollo adopta ms de una metodologa poniendo en practica los conceptos que ms se adecuan a
su entorno.

TRADICIONALES
CASCADA
Esta metodologa describe el ciclo tracicional del desarrollo de software en cinco etapas:
1.
2.
3.
4.
5.

Toma de requerimientos
Anlisis del problema
Diseo de la solucin
Codificacin
Pruebas

Estas etapas debern ejecutarse una despus de la otra de manera secuencial. La gran desventaja de este
planteamiento se debe a que en ciclo de vida de desarrollo de un producto real existen cambios que nos
forzarn a regresar a una etapa anterior, lo cual va en contra de esta metodologa. Sin embargo para un

desarrollo sencillo esta metodologa es fcil de implementar debido a que es clara en las tareas que se
realizarn en cada una de sus etapas. Sin embargo para un proyecto cuyos requerimientos no estn muy
definidos no se aconseja su implementacin ya que el proyecto esta sujeto a cambios constantes.
Desarrollo iterativo incremental
Esta metodologa pretende dividir el proyecto en etapas definidas e implementar en cada una de estas
etapas el mtodo de cascada. De esta manera cada iteracin es un objetivo alcanzado del cual se supone
no se retroceder. Con esto logramos manejar cambios con un menor impacto en el proyecto siempre y
cuando los cambios solo afecten la iteracin que se esta trabajando. Cualquier cambio que pretenda
afectar iteraciones anteriores representa un gran riesgo al proyecto.
BASADO EN PROTOTIPOS
Un prototipo es la representacin del sistema en funcionamiento, pero sin todas sus operaciones
desarrolladas a totalidad.
Esta metodologa basa todas sus etapas en prototipos. Cada prototipo es elaborado segn la toma de
requerimientos realizada previamente. Sus fases son:
Toma de requerimientos
Elaboracin de prototipo
Aprobacin por parte del cliente
Codificacin
Sirve para darle una idea general al cliente de lo que se desarrollar para as obtener su aprobacin
antes de elaborar el producto y as poder aclarar conceptos que pudieron no quedar muy claros. As
reducimos la incertidumbre de lo que se har y garantizamos un mayor grado de satisfaccin por parte
del cliente.
Esta metodologa involucra ms al cliente lo cual es de gran importancia para el xito de un proyecto
sin embargo carece de un anlisis formal de riesgos para su gestin en caso de presentarse.
ESPIRAL
Basada en el modelo incremental. Se agrega la planificacin, anlisis de riesgos e ingeniera. Tambin
cada entrega de prototipos se considera una vuelta (ciclo) del espiral sobre la cual se trabaja. Dentro de
sus ventajas y desventajas esta la agregacin de etapas necesarias tales como la gestin de riesgos la
cual con el tiempo se puede volver muy burocrtica impidiendo que el proyecto avance, sin embargo
sus beneficios son tiles si se maneja correctamente.

GILES
XP EXTREME PROGRAMMING
Desarrollada por Kent Beck.
Todo en el software cambia. Los requisitos cambian. El diseo cambia. El negocio cambia. La
tecnologa cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio
en s mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de
adaptarnos a dicho cambio cuando ste tiene lugar. Kent Beck.

La nota del autor infiere que es dicha metodologa implenta mecanismos para responder al constante
cambio que se produce a lo largo del ciclo de desarrollo de un proyecto. Al estar preparados para el
cambio, el riesgo disminuye.

En la programacin extrema, todos los requerimientos se expresan como escenarios (llamados

historias de usuario).
XP surgi como respuesta y posible solucin a los problemas derivados del cambio en los
requerimientos.
XP se plantea como una metodologa a emplear en proyectos de riesgo
XP aumenta la productividad
El cambio se lleva a cabo a travs de las entregas regulares del sistema, un desarrollo
previamente probado y la integracin continua.

Ventajas:
Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
Posee muchos roles (programador, cliente, tester, tracker, coach, consultor, big boss) por lo cual
con un equipo pequeo de trabajo es difcil llevarla a la prctica.
SCRUM
Esta metodologa ha sido ampliamente aceptada por su versatilidad. Aunque al inicio resulta
complicada su implementacin, una vez que se adquiere experiencia, proyectos con alto grado de
incertidumbre y de corta duracin pueden ser exitosos con un correcto control de su proceso.
Al igual que XP esta metodologa define roles que poseen funciones especficas en cada parte del
proceso de desarrollo. Los roles son:
Product Owner: persona que conoce a fondo el producto, posee una visin clara del producto.
Es quien define prioridades y es el encargado de manejar el product backlog segn lo considere
conveniente.
Scrum master: persona altamente capacitada en el desarrolladas bajo la metodologa SCRUM,
es un facilitador que quita impedimentos para que el proyecto continu su camino.
Equipo de desarrollo: desarrolladores.
Adems Scrum define ceremonias que se debe de llevar a cabo durante el desarrollo.
Product Grooming
Sprint Planning
Responsable: scrum master
Actividades
Sprint prioritization
Debe de tener una meta (producto funcional).
Analizar el product backlog para determinar cules se deben de realizar.
Sprint planning

Cmo se alcanzar el objetivo/meta

Determniar tareas
Estimate sprint backlog in hours
Daily scrum: el objetivo es conocer la respuesta a cada una de las siguietnes preguntas.
Qu se ha hecho desde el ltimo DS?
Qu se tiene planeado hacer hasta el prximo DS en la Story X?
Hay algn impedimento que impide cumplir con los objetivos?
Sprint Review
Para ver si el producto fue bueno o no. Generalmente participa el cliente, scrum master y
product owner, en ocaciones un miembro del equipo.
Retrospective
Mejora continua. Anlisis del ltimo sprint con los miembros del equipo, scrum master y
product owner.

Por ltimo los artefactos que utiliza Scrum son:

Producto backlog: caracterizan del producto.
Sprint: periodo de tiempo en el que se desarrolla una porcin del product backlog para tener un
producto funcional al final de ste periodo. Se recomienda que dure entre 1 a 4 semanas.
KANBAN
Kanban es otro marco utilizado para implementar gil. De vuelta en la dcada de 1940, Toyota
optimiz su proceso de ingeniera modelandolo al igual que los supermercados abastecan sus
estanteras. Los supermercados mantenan apenas suficiente producto para satisfacer la demanda de los
consumidores, una prctica que optimiza el flujo entre el supermercado y el consumidor. Debido a que
los niveles de inventario coinciden con los patrones de consumo, el supermercado gana eficacia
significativa en la gestin del inventario y la optimizacin para el cliente. Cuando Toyota trajo la idea a
los de pisos de la su fbrica, los equipos (tales como el equipo que se conecta las puertas al marco del
coche) entregaran una tarjeta, o "Kanban", entre s (por ejemplo, al equipo que rene las puertas) para
seal de que tienen un exceso de capacidad y estn dispuestos a tirar de ms materiales. Aunque la
tecnologa de sealizacin ha evolucionado, este sistema sigue siendo el ncleo de "justo a tiempo" de
fabricacin actual.
Un equipo Kanban solamente se centra en el trabajo que est activamente en progreso. Una vez que el
equipo completa un elemento de trabajo, arrancan el prximo elemento de trabajo de la parte superior
de la cartera. El propietario del producto es libre de volver a priorizar el trabajo de la cartera sin alterar
el equipo, porque cualquier cambio fuera de los elementos de trabajo actuales no afectan el equipo.
Mientras el dueo del producto mantiene los elementos de trabajo ms importantes en la parte superior
de la cartera, el equipo de desarrollo est asegurado que estn entregando valor mximo de nuevo a la
empresa. As que no hay necesidad de las iteraciones de longitud fija que se encuentra en scrum.
Efeciencia a travs del enfoque
La multi-tarea mata la eficiencia. Cuantos ms elementos de trabajo hay en un momento dado, se
incrementa el cambio de contexto, lo que dificulta su camino hasta su finalizacin. Es por eso que un
punto clave de Kanban es limitar la cantidad de trabajo en curso (WIP work-in-progress).