Estructura para el diseño de cursos virtuales

Versión 1. Mayo de 2016

GENERALIDADES DE LA ASIGNATURA

INFORMACIÓN GENERAL DE LA ASIGNATURA/CURSO

Nombre del programa Ingeniería del Software

Nivel de formación Pregrado
Nombre de la asignatura Patrones, Estándares y Metodologías para la Construcción de
Software
N° créditos 3
Duración de la asignatura 2 semanas
Autor del contenido Miguel García Torres (mgarciat@upo.es).
a) Doctor en Ciencias de la Computación e Inteligencia Artificial
por la Universidad de La Laguna (España)
b) Profesor Contratado Doctor en la Universidad Pablo de
Olavide (Sevilla, España).
Fecha de actualización 12/10/2017 Versión N.º 1
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

MÓDULO N.º 3: Metodologías de desarrollo de software

2. INFORMACIÓN ESPECÍFICA DEL MÓDULO

Programa Ingeniería del Software

Número y nombre del Módulo 3: Metodologías de desarrollo de software
módulo
Duración del módulo 2 semanas
Autor del diseño Miguel García Torres
mgarciat@upo.es
Fecha de actualización 12/10/2017

INTRODUCCIÓN AL MÓDULO N° 3

En este módulo se abordarán distintas metodologías de desarrollo de software que han

demostrado ser un marco de trabajo esencial para poder estructurar, planificar y
controlar el proceso de desarrollo en sistemas de información. Inicialmente
comenzaremos dando una visión general de las distintas metodologías de desarrollo
para, a continuación, centrarnos en las metodologías ágiles. Este tipo de metodologías,
debido a su naturaleza iterativa e incremental supuso una optimización de los recursos.
A pesar de los inconvenientes que también tiene, es el tipo de metodología de desarrollo
más extendido en la actualidad.

Existen diversas propuestas de métodos ágiles de desarrollo. En la siguiente sección

veremos el marco de desarrollo ágil más extendido: Scrum. Este marco fue introducido
por Ikujiro Nonaka e Hirotaka Takeuchi a principio de los años 80, al analizar cómo
desarrollaban los nuevos productos la principales empresas tecnológicas.

En las siguientes secciones se abordarán las metodologías KANBAN y XP. Con esto se
pretender dar un panorama general de las distintas metodologías ágiles propuestas y
que son de utilidad en la actualidad.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

COMPETENCIAS DEL MÓDULO N° Y ESTRUCTURA TEMÁTICA

Competencias del módulo Estructura temática a abordar en el módulo

Introducir los tipos de desarrollo 1. Metodologías de desarrollo de software
de software que hay y describir 1.1. Introducción
aquellos marcos de desarrollo 1.2. eXtreme Programming (XP)
más representativos 1.3. Scrum

CONTENIDO DEL MÓDULO N.º 3

Unidad temática 1

1.1. Introducción

El desarrollo de software es un marco de trabajo para la gestión de proyectos de

software que asegura la consecución de unos hitos así como la calidad del
producto desarrollado. Tiene, como principal objetivo, la producción eficaz y
eficiente de un producto de software que reúna los requisitos del cliente.

El proceso de desarrollo de software es equiparable a cualquier otro proyecto en

ingeniería. Sin embargo, éste tiene una serie de desafíos relativos a la naturaleza
del producto.

Una cuestión importante es que un producto de software, aún siendo de pequeño

tamaño, puede contener una serie de errores debido a la imposibilidad de poder
verificar todas las posibles situaciones de ejecución que puedan presentarse.
Además, un producto software es intangible; dificultando así su definición así
como la de los requisitos. Es, por tanto, habitual que los requisitos definidos
deban modificarse. Por último se destaca que no existe una única forma de
desarrollar un producto de software de forma efectiva y eficiente. Debido a esto,
es difícil automatizar todo el proceso de desarrollo de software.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

1.2. Marco conceptual

1.2.1 Introducción

Un sistema informático está compuesto de hardware y software. Si bien el

proceso de producción de hardware está bien definido, en lo referente al
software, tanto su construcción como los productos obtenidos han sido
cuestionados debido a diversos problemas. Algunos de estos problemas, tal y
como señala Pressman (1997), son:

 El coste asociado a la construcción, mejoramiento y mantenimiento son

difíciles de estimar.
 Los sistemas no responden a las expectativas de los usuarios.
 Las aplicaciones suelen contener errores.
 Los cambios en el hardware suelen afectar al software.
 Es muy difícil hacer un aprovechamiento óptimo de los recursos.

Estas dificultades derivaron en lo que se pasó a llamar la crisis del software, el

cual abarcó desde la década de los 60 hasta los 80 del siglo XX. Esto ayudó a
establecer y usar principios de la ingeniería orientados a obtener software eficaz,
eficiente y de forma económica. Posteriormente se consideraron la inclusión de
otros aspectos como la inclusión de métricas asociadas a la calidad del software,
satisfacción del cliente, etc.

Pressman (1997) caracteriza la ingeniería del software como una tecnología

multicapa. La Figura 1 muestra las distintas capas que considera:
 Calidad. Cualquier disciplina de la ingeniería del software debe estar
fundamentada en la calidad que permita incluir continuas mejoras en el
proceso de desarrollo del producto.
 Proceso. Define un marco de trabajo aplicable a un conjunto de áreas
claves para entregar un producto software de calidad y define los
contextos para construir dicho producto.
 Métodos. Esta capa se refiere a cómo construir, desde un punto de vista
técnico, un producto de software. Incluyen tareas de distinta índole como
el análisis de requisitos, diseño, construcción de programas, pruebas y
mantenimiento.
 Herramientas. Proporcionan un soporte automático o semi-automático
para el proceso y los métodos.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Figura 1: Capas de la Ingenieria del Software.

Fuente: http://sosagas.blogspot.com.es/2011/09/capas-de-la-ingenieria-de-software.html

Proceso de desarrollo de software

El proceso de desarrollo de software es un procedimiento intensamente

intelectual, afectado por la creatividad y juicio de las personas implicadas que
tiene como objetivo producir, de forma eficaz y eficiente, un producto de
software atendiendo a los requisitos del cliente.

Un producto de software es intangible y muy abstracto; de modo que dificulta la

definición del producto y sus requisitos. Esto sumado a la dificultad de conseguir
un desarrollo confiable 100% por la gran cantidad de factores que intervienen
(entradas, valores de variables, datos almacenados, etc.) dan indicio de la
complejidad del propio producto de software.

Otra dificultad asociada es la inmadurez de la disciplina de la ingeniería del

software, la cual hace que estemos en proceso de definición de distintos procesos
de software en función del contexto del proyecto. A pesar de esta
heterogeneidad, un proceso de desarrollo de software tiene una serie de
actividades fundamentales asociadas que están siempre presentes. Estas
actividades son:
 Especificación de software. Define la funcionalidad y las restricciones
que debe cumplir el software.
 Diseño e implementación. Abarca el diseño y construcción del software
de acuerdo a la especificación.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

 Validación. Conlleva el conjunto de actividades asociadas a la validación

del software desarrollado para que cumpla con las expectativas del
cliente.
 Evolución. El software ha de ir modificándose para adaptarse a las
necesidades del cliente.

Además de estas actividades, Pressman (1997) menciona otro conjunto de

actividades de protección que deben aplicarse durante todo el proceso del
software:
 Seguimiento y control de proyecto de software.
 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.
 Gestión de riesgos.

Según Pressman (1997), los elementos de un proceso de desarrollo de software

son:
 Un marco común del proceso. Son el conjunto de actividades que son
aplicables a todos los proyectos de software, con independencia del
tamaño y la complejidad.
 Un conjunto de tareas. Cada actividad de trabajo del proceso común es
una colección de tareas que hacen que el marco de trabajo se adapte a las
características particulares del proyecto de software y los requisitos del
equipo del proyecto. Abarca un conjunto de tareas de ingeniería del
software, hitos de proyectos, entregas y productos de trabajo del
software, y puntos de garantía de calidad.
 Las actividades de protección. Son un conjunto de actividades
independientes de cualquier actividad del marco de trabajo y aparecen
durante todo el proceso. El objetivo es la gestión, el rastreo y el control
del proyecto para garantizar la calidad del software.

La Figura 2 muestra los elementos del proceso de software según lo que

acabamos de ver.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Figura 2: Elementos del proceso del software.

Fuente:
http://users.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

También pueden verse los elementos de un proceso de desarrollo de software

mediante el establecimiento de sus relaciones respondiendo a quién debe hacer,
qué, cuándo y cómo debe hacerlo. Para ello hay que introducir el concepto de
artefacto, el cual es una pieza de información que es producida, modificada o
usada por un rol en una de sus actividades. Un artefacto puede ser un modelo,
un elemento de un modelo o un documento. La preguntas anteriores se
responden del siguiente modo:
 Quién: Las Personas participantes en el proyecto de desarrollo
desempeñando uno o más roles específicos.
 Qué: Los artefactos se especifican utilizando notaciones específicas. Las
herramientas apoyan la elaboración de artefactos soportando ciertas
notaciones.
 Cómo y Cuándo: Las actividades son una serie de pasos que lleva a cabo
un rol durante el proceso de desarrollo. El avance del proyecto está
controlado mediante hitos que establecen un determinado estado de
terminación de ciertos artefactos.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Modelos de proceso de software

Un modelo de proceso de software, según Sommerville (2002), puede definirse

como “Una representación simplificada de un proceso de software, representada
desde una perspectiva específica. Por su naturaleza los modelos son
simplificados, por lo tanto un modelo de procesos del software es una
abstracción de un proceso real.”

Existen una serie de modelos genéricos de desarrollo de software que, si bien no

son descripciones de procesos de software, pueden ser de utilidad para explicar
distintos enfoques del desarrollo de software. Algunos de estos modelos son:
 Codificar y corregir. Este es el modelo usado en los inicios del desarrollo
de software. Tiene dos pasos fundamentales:
◦ escribir código.
◦ Corregir errores del código.
En este modelo se empieza implementando algo y, a continuación, se va
pensando acerca de los requisitos, diseño, validación y mantenimiento.
Algunos de los principales problemas que presenta este modelo son:
◦ Mala estructuración del código tras diversas correcciones..
◦ Código difícil y costoso de mantener.
 Modelo en cascada. Se caracteriza por tomar las actividades
fundamentales del proceso de especificación, desarrollo, validación y
evolución y las representa como fases separadas del proceso. Consta de
las siguientes fases:
◦ Definición de los requisitos. Enfocado en comprender el dominio de
información del software como los servicios, las restricciones y
objetivos establecidos con los usuarios del sistema.
◦ Diseño de software. Descompone y organiza el sistema en
elementos. Establece la arquitectura del sistema y también identifica
y describe las abstracciones y relaciones de los componentes del
sistema.
◦ Implementación y pruebas unitarias. Creación del código y se
realizan las pruebas de cada módulo desarrollado.
◦ Integración y pruebas del sistema. Se integran todos los módulos y
se prueba su funcionamiento en conjunto.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

◦ Operación y mantenimiento. Consiste en la puesta en marcha del

sistema y se realizan correcciones y actualizaciones. También se
pueden identificar nuevos requisitos.

La interacción entre las distintas fases puede consultarse en la Figura 3.

Una fase no comienza hasta que termina la anterior. En la práctica este
modelo requiere de varias iteraciones así como de la interacción entre las
distintas fases de desarrollo.

Figura 3: Modelo de desarrollo en cascada.

Fuente:
http://users.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

Algunos de los problemas que presenta este modelo son:

◦ Las iteraciones son costosas.
◦ Las iteraciones requieren rehacer trabajo debido a la producción y
aprobación de los documentos tras cada fase.
◦ Existe una alta probabilidad de que el software no cumpla con los
requisitos del usuario por el largo tiempo de entrega del producto.
 Desarrollo en espiral. Este modelo fue introducido por Boehm (1988) y
es uno de los más populares por introducir un análisis de riesgo iterativo.
Esto es especialmente adecuado en proyectos de sistemas complejos de
gran escala.
Cada vuelta de ciclo se componen de cuatro fases, ocupando cada una de
estas fases un cuadrante:
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

◦ Definición de objetivos. Fase de definición de objetivos, de

restricciones del proceso y del producto en cada iteración. Se
identifican los riesgos.
◦ Evaluación y reducción de riesgos. Se analizan en detalle los riesgos
y se evalúan alternativas y se enfoca en la resolución de estos riesgos.
◦ Desarrollo y validación. Se escoge el modelo de desarrollo tras la
evaluación del riesgo y se desarrollan y verifican las entregas de cada
iteración.
◦ Planificación. En esta fase se determina si se ha de continuar con otra
iteración y se planifica en caso afirmativo.

La Figura 4 muestra un esquema de desarrollo en espiral.

Figura 4: Modelo de desarrollo en espiral.

Fuente: http://users.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

Metodologías para desarrollo de software

Las metodologías hacen referencia a un proceso de software detallado y

completo y se basan en una combinación de modelos de proceso genéricos visto
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

anteriormente. La metodología, además, debe definir con precisión los

artefactos, los roles y actividades así como el conjunto de prácticas y técnicas
recomendadas, guías de adaptación de la metodología al proyecto, etc.

No existe una clasificación única de los distintos tipos de metodología sino que
dependerá del criterio que se utilice. Si consideramos como criterio las
notaciones usadas para especificar artefactos producidos en actividades de
análisis y diseño, podemos clasificar las metodologías en dos grupos:
 Metodologías estructuradas. Se basan en el modelo básico
entrada/proceso/salida en el que los datos entran al sistema, a
continuación son manipulados y dan lugar a una salida.
 Metodologías orientadas a objetos. Son metodologías asociadas a los
lenguajes orientados a objetos.

Si consideramos como criterio, la filosofía de desarrollo encontraremos los

siguientes grupos:
 Metodologías tradicionales o pesadas. Son aquellas que están
orientadas hacia una fuerte planificación durante todo el proceso de
desarrollo. En este caso se hace mucho énfasis las etapas de análisis y
diseño antes de la construcción del sistema.
 Metodologías ágiles. Orientados a un desarrollo de software
incremental, cooperativo, sencillo y adaptable a cambios que puedan
presentarse durante la etapa de desarrollo.

Algunas de las características que se buscan de la metodología son:

 Facilitar la comunicación entre las personas involucradas.
 Mantener el control durante desarrollo del sistema que se desarrolla
 Facilitar la gestión y seguimiento de proyectos
 Definir las restricciones del sistema
 Validación y verificar toda la documentación generada

Metodologías ágiles

En el proceso de desarrollo de software se hacía un especial énfasis en el control

del proceso mediante una definición de roles, actividades y artefactos,
incluyendo modelado y documentación. Este esquema, que ha demostrado ser
efectivo en proyectos de gran tamaño, ha dejado de ser efectivo en muchos
proyectos actuales debido a lo cambiante del entorno del sistema. En este
contexto surgen las metodologías ágiles como posible respuesta a esta necesidad
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

pues aportan una simplificación del proceso de desarrollo manteniendo la

calidad del producto.

En torno a las metodologías ágiles se creó la organización The Agile Alliance, la

cual está dedicada a promover los conceptos relacionados con el desarrollo ágil
de software y ayudar a las organizaciones para que adopten dicha metodología.
A pesar de que hay un debate entre aquellos que apoyan las metodologías
tradicionales, el fuerte apoyo de esta metodología hace prever una fuerte
proyección industrial.

El punto de partida es un manifiesto que resume la filosofía de esta metodología.

Este manifiesto enumera los principales valores del desarrollo ágil. Algunos de
estos valores son:
 Mayor énfasis al individuo y a las interacciones del equipo de desarrollo
que al proceso y las herramientas.
 Búsqueda del desarrollo de un software funcional por encima de una
documentación exhaustiva.
 Fluidez y mayor enfoque en la interacción entre el cliente y el equipo de
desarrollo en vez de centrarse en la negociación contractual.
 Flexibilidad ante los cambios que vayan surgiendo en vez de ceñirse de
forma rígida al plan inicial.

Estos valores dan pie a los doce principios del manifiesto, los cuales marcan la
diferencia con respecto a la metodología tradicional. Algunas de las
metodologías ágiles que podemos encontrar son:
 SCRUM
 Crystal Methodologies
 Dynamic Systems Development Method
 Adaptive Software Development
 Feature-Driven Development
 Lean Development
 eXtreme Programming (XP)

1.2.2 eXtreme Programming (XP)

XP es una metodología ágil que promueve el trabajo en equipo y se preocupa por

el aprendizaje de los desarrolladores y de que haya un buen ambiente de trabajo.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Es una metodología adecuada para equipos de trabajo pequeños y proyectos

con requisitos imprecisos y en los que hay un alto riesgo de cambios.

Valores

XP se basa en los siguientes valores:

 Comunicación fluida entre los miembros del equipo y con el cliente.
 Simplicidad en la búsqueda de soluciones eligiendo siempre las
soluciones más simples que se adecuen a las exigencias del cliente.
 Retroalimentación continua del cliente para que los desarrolladores
puedan dirigir el proyecto adecuadamente.
 Valentía para llevar a cabo los cambios que vayan siendo necesarios
aplicar.
 Respeto en el trato entre los miembros integrantes del proyecto de modo
que no quieran hacerse decisiones repentinas.

Roles

Los roles de acuerdo con la propuesta original de Beck son:

 Programador. Es el encargado de implementar el código del sistema y
escribir las pruebas unitarias.
 Cliente. Es un interlocutor que puede representar a una o varias
personas. Se encarga de describir el sistema así como las prioridades de
los distintos componentes.
 Encargado de pruebas (Tester). Es el encargado de ayudar al cliente a
escribir las pruebas funcionales. También ejecuta las pruebas y difunde
los resultados.
 Encargado de seguimiento (Tracker). Es el encargado de seguir y verificar
el grado de cumplimiento de los objetivos marcados tanto a nivel de
tiempo como de recursos.
 Entrenador (Coach). Es el responsable del proceso global. Sirve de guía a
los miembros del equipo para que apliquen las prácticas XP
adecuadamente.
 Consultor. Es un miembro externo del equipo que guía al equipo para
resolver un problema específico.
 Gestor (Big boss). Es el vínculo entre el cliente y el equipo. Su principal
trabajo es el de coordinar para que el equipo trabaje en las mejores
condiciones.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Modelo

La metodología XP define cuatro variables para cualquier proyecto de software:

costo, tiempo, calidad y alcance. Tres de estas variables pueden ser establecidas
por actores eternos al equipo de desarrollo mientras que la cuarta la establecerá
el equipo de desarrollo en función de las otras variables. Por ejemplo, si el cliente
establece el alcance y la calidad, y el jefe del proyecto el costo, el equipo de
desarrollo determinará el tiempo de desarrollo necesario.

El desarrollo se organiza en trono a ciclos cortos denominados iteraciones, que

tienen asociados una serie de entregables al finalizar cada iteración. En cada
iteración se lleva a cabo un ciclo completo de análisis, diseño, desarrollo y
pruebas adecuadas a las reglas y prácticas que caracterizan a XP.

La Figura 5 muestra un esquema comparativo de las iteraciones entre los

modelos en cascada, iterativo y la metodología XP que combina los dos
anteriores. Un proyecto típico con XP suele tener entre 10 y 15 iteraciones.

Figura 5: Comparativa de las iteraciones en los desarrollo en cascada (a), en

el iterativo (b) y en XP (c).
Fuente:
http://www.runayupay.org/publicaciones/2244_555_COD_18_290814203
015.pdf

Proceso

A grandes rasgos el ciclo de desarrollo consiste en los siguientes pasos:

 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

 El cliente define el valor de negocio a implementar.

 El programador estima el esfuerzo necesario para su implementación.
 El cliente prioriza los distintos módulos en base a las restricciones
temporales.
 El programador construye ese valor de negocio.
 Vuelve al paso 1.

El ciclo de vida ideal se compone de seis fases:

 Exploración. Es una fase que toma de pocas semanas a pocos meses en
función del tamaño del proyecto y de la familiaridad del equipo con la
tecnología. Los clientes plantean las historias de los usuarios de interés
para la primera entrega del producto. El equipo se familiariza con las
herramientas, tecnologías y prácticas que se usarán en el proyecto.
 Planificación de la entrega. Es una fase breve que dura unos días en la que
el cliente establece las prioridades de cada historia de usuario. Los
programadores, por su parte, estiman el esfuerzo necesario de cada una
de ellas y lo plasman en un cronograma. La planificación suele realizarse
en base a unidades que representan una semana de trabajo. Cada historia
suele tener entre una y tres semanas.
 Iteraciones. En esta etapa se planifican las entregas de cada iteración que
no deben durar más de tres semanas cada una. En la primera iteración se
intentar establecer la arquitectura del producto y en la última, el sistema
debe estar listo para entrar en producción.
 Producción. Se toman decisiones sobre la inclusión de nuevas
características propiciados por los posibles cambios. Las ideas
propuestas y las sugerencias son documentadas para su posterior
implementación.
 Mantenimiento. Mientras la primera versión se encuentra en producción,
el proyecto XP debe mantener el sistema en funcionamiento al mismo
tiempo que desarrolla nuevas iteraciones.
 Muerte del proyecto. Se da cuando el cliente no tiene más historias para
ser incluidas en el sistema. Se genera una documentación final del
sistema y no se realizan más cambios en la arquitectura. También podría
ocurrir que terminara debido a que el sistema, tal y como lo planteó el
cliente, no genera los beneficios esperados por éste o no hay presupuesto
para mantenerlos.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Reglas y prácticas

La aplicación de la metodología XP con éxito requiere del cumplimiento de un

conjunto importante de reglas y prácticas. A continuación pasamos a describir
algunas de estas:
 Planificación. Hay dos actores principales; el cliente y el programador. El
primero establece las historias de cada usuario y su prioridad y el
programador el esfuerzo asociado a cada historia. Se ordenan las
historias en función de la prioridad y el esfuerzo, y se define el contenido
de cada iteración. Esto se realiza durante la planificación de la entrega, en
la planificación de cada iteración y en cualquier momento que sea
necesario.
 Entregas. La idea que subyace es que haya entregas de versiones
operativas aunque no cuenten con todas las funcionalidades pero que
tengan un cierto valor para el negocio.
 Simplicidad del diseño. Se debe diseñar la solución más simple que pueda
funcionar y ser implementada.
 Pruebas. Las pruebas unitarias son establecidas antes de escribir el
código. Para ello los clientes establecen las pruebas funcionales para cada
historia de usuario.
 Refactorización. El código se reestructura constantemente con el objetivo
de eliminar código duplicado, mejorar su legibilidad, simplificarlo y
hacerlo más flexible para facilitar futuros cambios.
 Propiedad colectiva del código. Cualquier programador puede contribuir
en la mejora o modificación del código para evitar que alguno de ellos sea
imprescindible.
 Integración continua. En cada momento en que un módulo es terminado
se pasa a su integración en el sistema. Para ello hay que planificar y
automatizar el conjunto de pruebas necesarias para que el código sea
integrado en el sistema una vez supere con éxito dichas pruebas.
 Estándares de programación. Se motiva el uso de estándares de
programación que permitan mantener un código legible para los
miembros del equipo.

Si bien es verdad que el conjunto de prácticas planteadas por XP no son

novedosas y ya se aplican en distintos ámbitos de la ingeniería del software, el
mérito de XP es haberlas integrado de una forma efectiva y complementarlas con
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en
equipo.

1.2.3 Scrum

Scrum nace en 1986 de la mano de Takecuchi y Nonaka en 1986 para gestionar

proyectos en los que la agilidad, flexibilidad y la incertidumbres son elementos
fundamentales en torno al proyecto. Posteriormente, en 1993 Sutherland lo
aplica al modelo de desarrollo de software. Esta metodología está formada por
un conjunto de prácticas y reglas para poder emprender proyectos complejos
adaptativos. Da respuesta a los siguientes principios de desarrollo ágil:
 Gestión evolutiva del producto.
 Calidad del resultado basado en el conocimiento de cada miembro del
equipo, antes que en el explícito de los procesos y la tecnología empleada.
 Estrategia de desarrollo incremental a través de iteraciones (sprints).

Valores

La metodología Scrum se sirve de unos valores que ayudan a obtener el éxito. La

Figura 6 muestra un diagrama con estos valores, los cuales pasamos a describir
a continuación:
 Foco. Las distintas tareas de un proyecto pueden ser muy variadas. Los
equipos han de estar unidos con un foco en común para crear cohesión.
 Coraje. Los recursos y los datos son compartidos de modo que ninguno
se sienta aislado. Con el apoyo y el soporte del grupo se hace posible la
innovación.
 Apertura. La transparencia y la compartición de datos permite una mayor
eficiencia en la respuesta a las necesidades que van surgiendo así como a
la reestructuración de procesos.
 Compromiso. Los miembros del equipo aumentan su compromiso si
pueden encauzar su propio éxito mediante la consecución de los
objetivos de su parte dentro del todo que es el proyecto.
 Respeto. Al trabajar en equipo y compartiendo información, es
fundamental el respeto hacia los demás y los procesos compartidos para
obtener los resultados esperados.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Figura 6: Valores de la metodología Scrum.

Fuente: http://www.gazafatonarioit.com/2016/07/revision-la-
guia-de-scrum.html

Roles

En Scrum se diferencian dos tipos de roles fundamentales:

 Roles principales. Son aquellas personas o roles comprometidos con el
proyecto y el proceso Scrum.
◦ Dueño del producto (Product owner). Es una única persona
responsable de gestionar la Lista del Producto (Product Backlog).
Conoce el negocio del cliente y tiene visión del producto. Se encarga
de escribir las idas del cliente ordenarlas en función de la prioridad y
colocarlas en la Lista del Producto de forma visible, clara y
transparente para todos.
◦ Equipo de desarrollo (Development team). Es un grupo pequeño de
entre 5-9 personas. Son los encargados de organizar y tomar
decisiones sobre su propio trabajo. Está involucrado en le estimación
del esfuerzo de las tareas de la Lista del Producto.
◦ Facilitador (Scrum master). Es el encargado de verificar que el modelo
y la metodología funcionan. Interactúa con el cliente y los gestores
para que el trabajo se realice de forma fluida y sin inconvenientes.
 Roles auxiliares. Aquellas personas o roles que no son parte del proceso
Scrum.
◦ Usuario. Es el destinatario final del producto.
◦ Stakeholder. Representa a la persona o grupo de personas a las que el
proyecto les producirá un beneficio. Participan durante las revisiones
de las iteraciones.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

◦ Manager. Toma las decisiones finales participando en la selección de

los objetivos y los requisitos.

Proceso

En Scrum, se denomina sprint a la unidad básica de trabajo para un equipo y

consiste en una simple iteración de modo que a su finalización se tiene que
proporcionar un resultado completo, un incremento del producto final. El
tiempo mínimo de un sprint es de una semana y el máximo es de 4.

El proceso de desarrollo se divide en eventos y artefactos. Los eventos sirven

para crear regularidad y minimizar la necesidad de reuniones no definidas. Los
eventos tienen una duración máxima. De esta forma un sprint puede
considerarse como un contenedor de eventos. A continuación pasamos a
describir los eventos:
 Planificación de sprint (Sprint planning). En esta etapa se planifica el
trabajo a realizar durante el sprint. Para ello se recurre al equipo
completo que lo lleva a cabo de forma colaborativa. El facilitador se
asegura de que el evento se lleve a cabo. La planificación responde a estas
dos preguntas:
◦ ¿Qué puede entregarse en el Incremento resultante del sprint que
comienza?
◦ ¿Cómo se conseguirá hacer el trabajo necesario para entregar el
Incremento?
 Objetivos del sprint (Sprint goals). Es la meta considerada para el sprint
que puede lograrse mediante la implementación de la Lista de Producto.
Se crea durante la planificación del sprint.
 Scrum diario (Daily Scrum). Es una reunión de un bloque de tiempo de 15
minutos para que el Equipo de Desarrollo sincronice sus actividades y
cree un plan para las siguientes 24 horas. Esto se lleva a cabo
inspeccionando el trabajo avanzado desde el último Scrum Diario y
haciendo una proyección acerca del trabajo que podría completarse antes
del siguiente. El facilitador se asegura que se lleven a cabo estas
reuniones aunque la responsabilidad de dirigirla es del propio equipo.
 Revisión de sprint (Sprint review). Es una reunión que se lleva a cabo al
final del Sprint para revisar el incremento del producto llevado a cabo y
adaptar la Lista de Producto si es necesario. Es una reunión informal en
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

el que el objetivo es facilitar la retroalimentación de la información y

fomentar la colaboración.
 Retrospectiva de sprint (Sprint retrospective). Es una reunión que se lleva
a cabo tras la revisión del sprint y antes de la planificación del siguiente
sprint. El dueño del producto se reúne con el equipo y el facilitador para
hablar de lo ocurrido en el pasado sprint. El objetivo es revisar lo que se
hizo y crear un plan de mejoras que sean abordadas en el siguiente sprint.
Los puntos principales a tratar son:
◦ Qué se hizo mal para mejorarlo en el siguiente sprint.
◦ Qué se hizo bien para seguir en la misma senda.
◦ Qué inconvenientes se encontraron y perjudicaron la planificación.

Los artefactos, en cambio, representan trabajo o valor en diversa formas y están

diseñados específicamente para maximizar la transparencia de la información
clave, necesaria para asegurar que todos tengan el mismo entendimiento del
artefacto.
 Lista o pila de producto (Product backlog). Es la lista de necesidades del
cliente. Es un inventario en el que se almacenan todas las funcionalidades
o requisitos en forma de lista priorizada.
La lista es creada y gestionada por el cliente con ayuda del facilitador,
quien indicará el coste estimado para completar un requisito. Las
principales característica de esta lista son:
◦ Contiene los objetivos del producto.
◦ En cada objetivo se indica el valor asignado por el cliente y el coste
estimado.
◦ Se indica las posibles iteraciones y las publicaciones indicadas al
cliente.
◦ Ha de incluir los posibles riesgos así como las tareas necesarias para
solventarlos.
 Lista o pila de pendientes del sprint (Sprint backlog). Es la lista de tareas
correspondientes a un sprint y se elabora por el equipo durante la
planificación de un sprint. Se asignan las tareas a las personas y el tiempo
que queda para terminarlas. Se caracterizar por:
◦ Ser una lista ordenada de prioridades para el cliente.
◦ Por la posibilidad de haber dependencias entre tareas.
◦ Las tareas tienen un coste temporal similar de entre 4-16 horas.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

El diagrama del ciclo de vida de un proyecto que se aborda mediante Scrum

puede verse en la Figura 7. El proceso parte de la Lista del Producto priorizada,
que actúa como plan del proyecto. Para la elaboración de dicha lista han
participado diversos roles a partir de las opiniones de los usuarios. Estas
historias de usuario es dividida en tareas y es plasmado en el documento Lista
de Producto (Product Backlog) por el dueño del producto en asociación con el
cliente otorgando prioridades a dichas tareas.

Figura 7: Ciclo de vida de un proyecto Scrum.

Fuente: http://www.softwareplant.com/scrum/

A continuación se lleva a cabo la reunión de planificación de sprint para dividir

las tareas en iteraciones (sprints) de modo que cada iteración contendrá una
serie de tareas asociadas. Esto se plasma en el documento denominado Lista de
Pendientes de sprint (Sprint Backlog) y es responsabilidad exclusiva del equipo
de desarrollo.

En este momento empiezan las iteraciones en los que los distintos miembros del
equipo llevan a cabo trabajos de desarrollo y prueba. En esta etapa se llevan a
cabo reuniones diarias (Daily Scrum Meeting).

Al finalizar la iteración el equipo lleva a cabo la revisión y retrospectiva del sprint

terminado. Tras esto se considera que se ha finalizado el trabajo del sprint.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

1.3. Ejemplos

Caso práctico de uso de la metodología Scrum

Consideremos que un cliente se pone en contacto con una empresa de

desarrollo de robots. Como se ve en la Figura 8, el cliente se reúne con el
Dueño del Producto, quien toma nota de sus necesidades.

Figura 8: Reunión entre el cliente y el Dueño del Producto.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-
caso-prctico-1516220

A continuación, tal y como puede verse en la Figura 9, el Dueño del Producto

divide el proyecto en historias que formarán parte de la Lista de producto.

Figura 9: División del proyecto en historias.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-
caso-prctico-1516220

La Figura 10 muestra el siguiente paso. El Dueño del producto le entrega al

facilitador la Lista de Producto para que estime el coste de creación del producto.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Figura 10: Estimación del coste por parte del facilitador.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-
prctico-1516220

El equipo se reúne para estimar el coste de cada historia de la Lista de Producto

(ver Figura 11).

Figura 11: Estimación del coste de cada historia.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-
prctico-1516220

Una vez aprobado el presupuesto, por parte del cliente, se reordena la Lista de
Producto en función de las prioridades del propio cliente para que el equipo
trabaje según ese orden establecido.

A continuación el equipo comienza su trabajo desglosando la primera historia

de la Lista de Producto, y divide dicha historia en tareas menores para crear la
Lista de Sprint. Esto puede consultarse en la Figura 12.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

Figura 12: Iteración de una historia de usuario.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-
prctico-1516220

La Lista de Sprint fracciona el trabajo de un período de 15 días en tareas más

pequeñas, que tarden, como mucho, dos días. Estas tareas se colocan en una lista,
la cual prioriza el Dueño del Producto, quien ha consultado con el cliente, antes
de comenzar el Sprint. La Figura 13 muestra esta acción que realiza el Dueño del
Producto.

Figura 13: Lista de Sprint priorizada por el Dueño del Producto.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

El equipo comienza el Sprint tomando las tareas priorizadas. Una vez concluida
una se toma la siguiente de la lista.

Todos los días se convoca una reunión del equipo donde se cuenta las tareas
realizadas el día anterior y cuáles se van a realizar ese día. La Figura 14 muestra
un esquema de ejemplo de los asuntos a tratar en una de las reunioes diarias.

Figura 14: Esquema de las reuniones diarias.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-1516220

Una vez finalizado el Sprint, el Dueño del Producto le muestra al cliente el

resultado del trabajo realizado. El cliente valora ese primer resultado y puede
volver a priorizar la Lista de Producto antes de que comience otro Sprint.

El equipo de trabajo hace una reunión de retrospectiva para analizar lo

acontecido durante el Sprint que ha terminado. Tras esto se comienza de nuevo
a trabajar en otra historia del cliente.
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

1.4. Ejercicios de reflexión

1. Haga una comparativa que exponga las diferencias entre las metodologías
ágiles y las tradicionales.

Metodologías Ágiles Metodologías Tradicionales

2. Exponer y desarrollar los doce principios de la metodología ágil.

1. _________________________________
2. _________________________________
3. _________________________________
4. _________________________________
5. _________________________________
6. _________________________________
7. _________________________________
8. _________________________________
9. _________________________________
10. _________________________________
11. _________________________________
12. _________________________________
 Estructura para el diseño de cursos virtuales
Versión 1. Mayo de 2016

1.5. Conclusiones

En este módulo nos hemos enfocado en el proceso de desarrollo de software, el

cual es uno de los pilares de la informática. Debido a las dificultades surgidas en
torno a su desarrollo, corrección y mantenimiento, se ha establecido la
necesidad de desarrollar metodologías que permitan la producción eficaz y
eficiente de un producto software que reuna los requisitos del cliente.

En un mundo cambiante en el que hay avances tecnológicos constantemente y

surgen imprevistos durante el desarrollo de un producto software, las
metodologías ágiles han surgido para facilitar la tarea de desarrollar proyectos
de pequeño tamaño que presenten esta problemática y no pueden, por tanto,
ajustarse a desarrollos más tradicionales.

De entre todas las metodologías ágiles, XP y Scrum son dos de las más extendidas
en los entornos de desarrollo. La selección de la metodología dependerá de las
características del proyecto que se maneje y del conocimiento que manejen los
miembros del equipo de desarrollo del proyecto.

1.6. Material de estudio

Ubicación (indicar la base de

Temas que
Referencia bibliográfica (APA) datos donde se ubica o el
abordan
link web)
Ingeniería del Pressman, R, (1997). Ingeniería del Software: Un
Software enfoque práctico, McGraw Hill
Ingeniería del Sommerville, I., (2002). Software Engineering,
Software Pearson Education.
Modelo de Boehm, BW (1988). A Model of Spiral Software
desarrollo en develpment and Enhancement. IEEE Computer.
espiral