Taller de METODOLOGIAS DE

DESARROLLO DE SOFTWARE

Yeider ramirez lopez

Este documento está disponible en la Biblioteca Digital de la Universidad Católica Argentina, repositorio
institucional desarrollado por la Biblioteca Central “San Benito Abad”. Su objetivo es difundir y preservar
la producción intelectual de la Institución. La Biblioteca posee la autorización del autor para su
divulgación en línea

Cómo citar el documento: Maida, EG, Pacienzia, J. Metodologías de desarrollo de software [en línea].
Tesis de Licenciatura en Sistemas y Computación. Facultad de Química e Ingeniería “Fray Rogelio
Bacon”. Universidad Católica Argentina, 2015. Disponible en:
http://bibliotecadigital.uca.edu.ar/repositorio/tesis/metodologias-desarrollo-software.pdf [Fecha de
consulta:.........
 Introduccion
Este trabajo tiene como prospectiva dos objetivos, el primero de ellos pretende brindar una
descripción del marco teórico de referencia de las metodologías de desarrollo ágil presentando
algunas como: XP, CRYSTAL, SCRUM. El segundo objetivo busca analizar algunas características
esenciales de estas metodologías para adaptarlas al contexto de la ingeniería del software. En
la comunidad de la ingeniería delsoftware, se está viviendo con intensidad un debate abierto
entre los partidarios de las metodologías tradicionales (referidas como “metodologías
pesadas”) y aquellos que apoyan las ideas emanadas del “Manifiesto Ágil”.
La presente tesis se orienta a realizar una contribución en el área de metodología para el
diseño, desarrollo y evaluación de software, necesarios para abordar proyectos con una
metodología diferente a la estructurada.
Actualmente las metodologías de ingeniería de software pueden considerarse como una base
necesaria para la ejecución de cualquier proyecto de desarrollo de software que se considere
serio, y que necesite sustentarse en algo más que la experiencia y capacidades de sus
programadores y equipo. Estas metodologías son necesarias para poder realizar un proyecto
profesional, tanto para poder desarrollar efectiva y eficientemente el software, como para que
sirvan de documentación y se puedan rendir cuentas de los resultados obtenidos.
El objetivo general de la puesta en práctica de una metodología del software es construir un
producto de alta calidad de una manera oportuna. Dicha selección implica un conjunto de
principios fundamentales que se deben seguir y cumplir. Estos incluyen actividades explícitas
para el entendimiento del problema y la comunicación con el cliente, métodos definidos para
representar un diseño, mejores prácticas para la implementación de la solución y estrategias y
tácticas sólidas para las pruebas.
 Que entiende por metodologias de desarrollo
de software

La metodología de desarrollo de software es el conjunto de técnicas y métodos que

se utilizan para diseñar una solución de software informático. Trabajar con una
metodología es imprescindible por una cuestión de organización. Una metodología
es un conjunto integrado de técnicas y métodos que permite abordar de forma
homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto
de desarrollo. Es un proceso de software detallado y completo.

La metodología para el desarrollo de software es un modo sistemático de realizar,

gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de
éxito. Una metodología para el desarrollo de software comprende los procesos a
seguir sistemáticamente para idear, implementar y mantener un producto software
desde que surge la necesidad del producto hasta que cumplimos el objetivo por el
cual fue creado. Métodos que guían en la planificación y en el desarrollo del
software. Una metodología define una estrategia global para enfrentarse con el
proyecto
Las metodologías de desarrollo de software siempre parten de un componente
teórico y cuando son usadas por los equipos de trabajo conllevan a la utilización de
un conjunto de técnicas y métodos que al final determinarán las tareas generales y
específicas que se deberían realizar para alcanzar un objetivo.
Existen diferentes tipos de metodologías de desarrollo de software que fueron ideadas
pensando en problemas particulares presentados en la industria en contextos
específicos, por lo cual es importante conocer sus diferentes características y
contrastarlas con las necesidades particulares a las que se enfrenta a la hora de
desarrollar un producto y servicio. Es decir, cada una de estas tiene ventajas y enfoques
que pueden ser reutilizados en diferentes momentos.
 Diferencias entre metodologias
tradicionales y metodologias agiles
Tabla Nº 1 – Comparación entre
Metodología Ágil y Tradicional

Metodologias Metodologias
agiles tradicionales
Basadas en heurísticas Basadas en normas
provenientes de prácticas de provenientes de estándares
producción de código seguidos por el entorno de
desarrollo
Especialmente preparados Cierta resistencia a los
para cambios durante el cambios
proyecto
Impuestas internamente (por Impuestas externamente
el equipo)
Proceso menos controlado, Proceso mucho más
con pocos principios controlado, con numerosas
políticas/normas
No existe contrato Existe un contrato prefijado
tradicional o al menos es
bastante flexible
El cliente es parte del equipo El cliente interactúa con el
de desarrollo equipo de desarrollo
mediante reuniones
Grupos pequeños (<10 Grupos grandes y
integrantes) y trabajando en posiblemente distribuidos
el mismo sitio
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la La arquitectura del software
arquitectura del software es esencial y se expresa
mediante modelos
Poca documentación Documentación exhaustiva
Muchos ciclos de entrega Pocos ciclos de entrega

Metodologias agiles Metodologias tradicionales

Se basan en heurÌsticas provenientes de Se basan en normas provenientes de
pr·cticas de producciÛn de cÛdigo est·ndares seguidos por el entorno de
desarrollo
Preparados para cambios durante el proyecto Cierta resistencia a los cambios
Impuestas internamente por el equipo Impuestas externamente
Proceso menos controlado, con pocos Proceso muy controlado, numerosas normas
principios
Contrato flexible e incluso inexistente Contrato prefijado
El cliente es parte del desarrollo Cliente interact˙a con el equipo de desarrollo
mediante reuniones
Grupos pequeños (<10) Grupos grandes
Pocos artefactos Mas artefactos
Menor Ènfasis en la arquitectura del software La arquitectura del software es esencial
 Metodologias agiles

Xp programacion extrema: XP es la abreviación comúnmente utilizada para referirse a

Extreme Programming, que es un marco de desarrollo de software ágil que busca producir
software de alta calidad en contextos con requisitos altamente cambiantes, riesgos que
involucran tiempos fijo con tecnologías nuevas y equipos de trabajo pequeños ubicados en un
mismo sitio.

En XP se definen cinco valores según Beck y Andrés (2004):

Comunicación: el desarrollo de software requiere de trabajo en equipo por lo cual es

importante la transferencia de conocimientos y utilizar medios de comunicación apropiados, se
propone la discusión cara a cara con herramientas que permitan dibujar o escribir, como, por
ejemplo: un tablero.

Simplicidad: esto se refiere a hacer solo las cosas que sean absolutamente necesarias evitando
el desperdicio, elaborar las cosas de forma que sea fácil entender por otros y abordar solo
requisitos conocidos.

Retroalimentación: esto permite identificar áreas de mejora y revisión constante de las

prácticas implementadas en el proceso de forma que se puedan establecer procesos de mejora
permanentes.

Coraje: se refiere al actuar sobre situaciones que pueden ser retadoras para el equipo, como,
por ejemplo:

Enfrentar problemas organizacionales.

Intentar implementar funcionalidades de formas diferentes cuando lo convencional no funciona

y aceptar comentarios, etc.
Respeto, los miembros del equipo deben respetarse entre sí para comunicarse y trabajar en
equipo. Cada persona contribuye en favor de lograr el objetivo del equipo.

La programación extrema puede que marque un antes y un después en la ingeniería del

software. La programación extrema ha pasado de ser una simple idea para un único
proyecto a inundar todas las factorías de software. Algunos la definen como un movimiento
social de los analistas del software hacia los hombres y mujeres de negocios, de lo que
debería ser el desarrollo de soluciones en contraposición a los legalismos de los contratos
de desarrollo. Es el más destacado de los procesos ágiles de desarrollo de software.

Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para
el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.

Para alcanzar el objetivo de software como solución ágil, la metodología XP se estructura en

tres capas que agrupan las doce prácticas básicas de XP:
1. Metodología de programación: diseño sencillo, testing, refactorización y codificación con
estándares.
2. Metodología de equipo: propiedad colectiva del código, programación en parejas,
integración continua, entregas semanales e integridad con el cliente.
3. Metodología de procesos: cliente in situ, entregas frecuentes y planificación.

Adicional a los valores XP se caracteriza por la definición de un conjunto de 12

prácticas de desarrollo de software que aunque pueden ser adoptadas de forma aislada
tiene mayor relevancia cuando son desarrolladas en conjunto (Jeffries, 2011):
El juego de la planificación
Consiste en una reunión de planeación que realiza el equipo de desarrollo en conjunto
con el cliente para discutir y probar las características a ser desarrolladas.
Pequeños lanzamientos
Esta práctica sugiere hacer iteraciones cortas con funcionalidades pequeñas que
puedan ser probadas con el cliente de forma que se obtenga realimentación temprana y
frecuente.
Metáfora
Los nombres usados para definir cualquier tipo de identificador en el sistema deben ser
coherentes. El diseño y la estructura en general deben ser comprensibles para cualquier
persona.
Diseño simple
Esto implica hacer un código que funcione y que sea a la vez la solución más simple
posible, evitando duplicación de código, menor número de métodos y clases.
Pruebas
Sugiere el uso de técnicas donde se enfatice en el proceso de pruebas constantes
antes de iniciar la construcción del código, como, por ejemplo: TTD (desarrollo basado
en pruebas)
Refactorización
Eliminación de funciones innecesarias, desacoplar elementos y eliminar cualquier tipo
de redundancia de forma que se mantenga un código lo más limpio posible, que sea
fácil de entender y modifica.

Kanban: Kanban se basa en la idea de que el trabajo en curso debería limitarse, y sólo
deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior haya sido
entregado o ha pasado a otra función posterior de la cadena. La metodología Kanban utiliza
un mecanismo de control visual para hacer seguimiento del trabajo conforme este viaja a
través del flujo de valor. El Kanban implica que se genera una señal visual para indicar que
hay nuevos bloques de trabajo que pueden ser comenzados porque el trabajo en curso
actual no alcanza el máximo acordado. El aporte principal de Kanban a las metodologías
agiles es que a través de la implementación de tarjetas visuales, proporciona transparencia
al proceso, ya que su flujo de trabajo expone los cuellos de botella, colas, variabilidad y
desperdicios a lo largo del tiempo y todas las cosas que impactan al rendimiento de la
organización en términos de la cantidad de trabajo entregado y el ciclo de tiempo
requerido para entregarlo.

Como resultado, Kanban propicia la evolución incremental de los procesos existentes, una
evolución que generalmente está alineada con los valores de las metodologías agiles.
Kanban no genera una revolución radical de la forma en la que las personas trabajan, sino
que sugiere un cambio gradual.

Las principales ventajas de esta metodología es que es muy fácil de aplicar, actualizar y asumir por parte
del equipo. Además, se destaca por utilizar una técnica de gestión de las tareas muy visual y práctica, lo
que permite ver a simple vista el estado de los proyectos, así como también pautar el desarrollo del
trabajo de manera efectiva.

Principios del método Kanban

Calidad garantizada: todo lo que se hace debe salir bien en la primera instancia, no hay
margen de error.

Reducción del desperdicio: se basa en hacer solamente lo justo y necesario, para

garantizar que se haga bien. No es simplemente un método de gestión, sino también un
sistema de mejora en el desarrollo de proyectos, según los objetivos a alcanzar.
El equipo debe estar de acuerdo que el cambio continuo, gradual y evolutivo es la manera de
hacer mejoras en el sistema y debe apegarse a ello.
La aplicación del método Kanban implica la generación de un tablero de tareas que
permitirá mejorar el flujo de trabajo y alcanzar un ritmo sostenible.

Aplicación del método Kanban

Definir el flujo de trabajo de los proyectos: para ello, simplemente deberemos crear nuestro
propio tablero, que deberá ser visible y accesible por parte de todos los miembros del
equipo.
Cada una de las columnas corresponderá a un estado concreto del flujo de tareas, que nos
servirá para saber en qué situación se encuentra cada proyecto. El tablero debe tener
tantas columnas como estados por los que pasa una tarea, desde que se inicia hasta que
finaliza. A diferencia de SCRUM, una de las peculiaridades del tablero es que este es
continuo. Esto significa que no se compone de tarjetas que se van desplazando hasta que
la actividad queda realizada por completo. En este caso, a medida que se avanza, las
nuevas tareas se acumulan en la sección inicial, de manera que en las reuniones periódicas
con el cliente se priorizan y se colocan dentro de la sección que se estima oportuna.

Dicho tablero puede ser específico para un proyecto en concreto o bien genérico. No hay unas
fases del ciclo de producción establecidas sino que se definirán según el caso en cuestión,
o se establecerá un modelo aplicable genéricamente para cualquier proyecto de la
organización.
Visualizar las fases del ciclo de producción. Al igual que Scrum, Kanban se basa en el
principio de desarrollo incremental, dividiendo el trabajo en distintas partes. Esto significa
que no hablamos de la tarea en sí, sino que lo dividimos en distintos pasos para agilizar el
proceso de producción.
Normalmente cada una de esas partes se escribe en un post-it y se pega en el tablero, en la
fase que corresponda. Dicho post-it contiene, normalmente, la descripción de la tarea con
la estimación de horas, la información básica para que el equipo sepa rápidamente la carga
total de trabajo que supone. Además, se pueden emplear fotos para asignar responsables
así como también usar tarjetas con distintas formas para poner observaciones o indicar
bloqueos.
Al final, el objetivo de la visualización es clarificar al máximo el trabajo a realizar, las tareas
asignadas a cada equipo de trabajo , así como también las prioridades y la meta asignada.
Stop Starting, start finishing. Este es el lema principal de la metodología Kanban. De esta
manera, se prioriza el trabajo que está en curso en vez de empezar nuevas tareas.
Precisamente, una de las principales aportaciones del Kanban es que el trabajo en curso
debe estar limitado y, por tanto, existe un número máximo de tareas a realizar en cada fase;
no se puede abrir una nueva tarea sin finalizar otra.
De esta manera, se pretende dar respuesta al problema habitual de muchas empresas de
tener muchas tareas abiertas pero con un promedio de finalización muy bajo. Aquí lo
importante es que las tareas que se abran se cierren antes de empezar con la siguiente.
Control del Flujo. A diferencia de SCRUM, la metodología Kanban no se aplica a un único
proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con
un flujo de trabajo constante, las tareas más importantes en cola para ser desarrolladas y
un seguimiento pasivo para no tener que interrumpir al trabajador en cada momento.
Asimismo, dicha metodología de trabajo nos permite hacer un seguimiento del trabajo
realizado, almacenando la información que nos proporcionan las tarjetas.
Las tres reglas de Kanban
1. Mostrar el proceso
2. Limitar el trabajo en curso
3. Optimizar el flujo de trabajo

Scrum: La metodología de trabajo de Scrum, tiene sus principios fundamentales en la

década de 1980, la cual fue desarrollada por su necesidad en procesos de reingeniería por
Goldratt, Takeuchi y Nonaka.
El concepto de Scrum tiene su origen sobre los nuevos procesos de desarrollo utilizados en
productos exitosos en Japón y los Estados. Estos equipos seguían patrones de ejecución de
proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos
altamente productivos y multidisciplinares con la colaboración entre los jugadores de
Rugby y su formación de Scrum, de la cual se tomó su nombre.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera
de trabajar de equipos altamente productivos.
Podríamos decir que SCRUM se basa en cierto caos controlado pero establece ciertos
mecanismos para controlar esta indeterminación, manipular lo impredecible y controlar la
flexibilidad.
Beneficios
Productividad mediante comunicación y creación de sinergias. Todos los miembros del
equipo tienen una misma visión del objetivo y se ha utilizado los conocimientos y las
experiencias de todos para elaborar la mejor solución entregable en el mínimo tiempo y con el
mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre
tareas.
Potenciación del compromiso del equipo sobre el objetivo común de la iteración: o Es todo el
equipo quien asume la responsabilidad de completar en la iteración los requisitos que
selecciona. Facilita la ayuda de cualquier miembro si se detecta algún impedimento que
bloquea el progreso de la iteración, especialmente si cuando se está llegando al final de la
iteración es necesaria la participación de todos para poder completar los objetivos
comprometidos.
El proceso de aplicación de Scrum En Scrum un proyecto se ejecuta en bloques temporales
cortos y fijos (iteraciones de 2 a 4 semanas como máximo). Cada iteración tiene que
proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser
entregado con el mínimo esfuerzo al cliente cuando lo solicite.
Ventajas de utilizar Scrum
Entregas parciales a corto plazo de resultados
 Gestión regular de las expectativas del cliente y basada en resultados tangibles.
Resultados anticipados.
Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc.
Gestión sistemática del Retorno de Inversión (ROI).
Mitigación sistemática de los riesgos del proyecto.
Productividad y calidad.
Alineamiento entre el cliente y el equipo de desarrollo.
Equipo motivado.
Requisitos para poder utilizar Scrum:
Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de
proyectos como Scrum:
Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.
Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y
disponibilidad para poder colaborar.
Compromiso de la Dirección de la organización para resolver problemas frecuentes y realizar
cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando
una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes
al servicio del equipo.
Compromiso conjunto y colaboración de los miembros del equipo.
Relación entre proveedor y cliente basada en la colaboración y transparencia.
Facilidad para realizar cambios en el proyecto.
Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas de planificación y
coordinación cuando varios equipos trabajan en el mismo proyecto).
Equipo trabajando en un mismo espacio común para maximizar la comunicación.
Dedicación del equipo a tiempo completo.
Estabilidad de los miembros del equipo.
Scrum se basa en los siguientes puntos:
El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos
(iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Las iteraciones se
pueden entender como mini proyectos, en todas las iteraciones se repite un proceso de trabajo
similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre el producto
final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental.
Para ello, cada requisito se debe completar en una única iteración. El equipo debe realizar
todas las tareas necesarias para completarlo (incluyendo pruebas y documentación) y que esté
preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no
se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de
requisitos.
La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada
iteración. Para que un proyecto proporcione el mejor resultado posible, y como soporte
fundamental al control empírico del proyecto, es necesario repriorizar los requisitos de manera
regular, en cada iteración, según el valor que proporcionan al cliente en ese momento y su
coste estimado de desarrollo. Como resultado de esta re priorización se actualiza la lista de
requisitos priorizada (Product Backlog).
El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al
cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en
función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo
se sincroniza diariamente y realiza las adaptaciones necesarias.
La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le
otorga la autoridad necesaria para organizar su trabajo.
La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el
cliente.
El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y
conseguir resultados. La técnica del timebox consiste en fijar el tiempo máximo para conseguir
ciertos objetivos, tomar una decisión o realizar unas tareas, y hacer lo mejor que podamos en
ese intervalo. De esta manera, en lugar de ponerse a trabajar en algo hasta que esté hecho, de
antemano se acuerda que sólo se dedica un tiempo limitado. La consciencia de esta limitación
temporal favorece la priorización de objetivos/tareas y fuerza la toma de decisiones.
Por otro lado hay tres roles centrales dentro del marco de trabajo de Scrum (SCRUMstudy,
2013) que se describen a continuación:

Dueño del producto (Product Owner)

Scrum Master
Equipo de desarrollo (Developer Team)
Además de los roles, Scrum define un conjunto de eventos con participantes y objetivos
claros que se desarrollan en momentos particulares del flujo general de Scrum, a
continuación, se detalla cada uno de estos:
Sprint
Planeación del Sprint
Reunión diaria (Daily Meeting)
Revisión del Sprint
Reunión de retrospectiva
 Como debe ser un buen product owner

En las metodologías ágiles, Scrum en particular, el rol del Product Owner (PO) es asumido
frecuentemente por una persona con conocimientos sólidos respecto de los usuarios, el
mercado, la competencia y las tendencias de futuro para el dominio o el tipo de sistema que se
está desarrollando. El desafío del PO es construir una visión del producto y luego plasmarla en
historias de usuario (user stories), que le ayudarán a transmitir esa visión al equipo de
desarrollo que va a construir el software. En este trabajo se plantea la problemática vinculada a
la creación, priorización, validación y aceptación del producto obtenido a partir de las user
stories; para lo cual se requieren conocimientos técnicos para los que el PO no siempre está
preparado.
HABILIDADES ESPERADAS PARA EL PRODUCT OWNER
se propone un conjunto de habilidades esperadas que complementan el perfil. Las mismas se
exponen a continuación: Convertir conocimiento tácito en explícito: El conocimiento tácito se
trata del conocimiento personal o propio del individuo, este conocimiento se halla
profundamente imbricado en la mente de la persona y ampliamente relacionado con la
experiencia práctica de la misma. El conocimiento explícito, ese otro tipo de conocimiento,
caracterizado por ser más formal y sistemático, que puede ser transmitido al equipo de
desarrollo.
En la metodología Scrum, uno de los tres roles en los equipos es el denominado Producto
Owner (en adelante, PO). El PO en un proyecto gestionado con Scrum es responsable de
maximizar el valor del producto y el trabajo del equipo de desarrollo, también, es la única
persona responsable de administrar el backlog del producto. Por este motivo, es usual decir
que el PO necesita mirar en al menos dos direcciones al mismo tiempo. Por un lado, debe
comprender suficientemente bien las necesidades y prioridades de los interesados de la
organización, los clientes y los usuarios como para actuar como su voz y, por otro lado, debe
comunicarle al equipo de desarrollo qué producto software construir y el orden en el cual
construirlo (entre otros aspectos). El propósito del proyecto es estudiar algunos aspectos del rol
del Product Owner tal cual se lo desempeña en la industria, de modo de comparar las prácticas
industriales con la propuesta oficial del desempeño y función de ese rol en los equipos Scrum.
El enfoque metodológico consistió en la confección de un cuestionario, la realización de
entrevistas cualitativas a informantes claves, la recolección y preparación de datos para su
análisis. Los resultados permitieron dar respuesta a la mayoría de las preguntas de
investigación, el destaque de la importancia de las habilidades blandas como el trabajo en
equipo y la comunicación, el hecho de ver en la industria una alta fidelidad a la implementación
de las ceremonias dentro del marco de Scrum y que se observaron algunos problemas o
dificultades con los que un PO puede encontrarse, por ejemplo problemas de descoordinación
causado por fallas en la comunicación, o problemas al momento de manejar las expectativas y
presiones que llegan del lado del negocio y del equipo .
 Cual es el rol de un buen scrum master

Su misión más importante es la de proteger al equipo de interrupciones mientras trabajan para

completar el sprint y resolverles cualquier incidencia u obstáculo que les impida cumplir la meta
del sprint. Preparará las reuniones y se asegura de que sean productivas. Asignará también las
tareas al equipo de Trabajo y hará un seguimiento de las ya asignadas. Otras de sus funciones más
destacadas son:

Resolver los conflictos que obstaculicen el ritmo normal del proyecto.

Incentivar y motivar al equipo de trabajo.
Fomentar la autogestión de sus colaboradores durante el proceso.
Negociar y renegociar las condiciones con el cliente.
Evitar la intromisión de terceros en las labores.
el Scrum Master tiene como misión facilitar el proceso y ayudar a las personas a resolver
problemas mientras refuerza las reglas del proceso, es quien vela por la productividad del
equipo y es responsable por mantener el proceso Scrum, por enseñarlo a cualquiera
involucrado en el proyecto y asegurar que todos siguen las reglas y prácticas de Scrum .

DP tendrán dificultades para tener éxito.

Enumera que el Scrum Master debe proporcionar: asesoría y formación al equipo para trabajar
de forma auto-organizada y con responsabilidad de equipo, visión y validación de la lista del
producto, moderación de las reuniones, resolución de impedimentos que en el sprint
pueden entorpecer la ejecución de las tareas, gestión de las «dinámicas de grupo» en el
equipo, configuración, diseño y mejora continua de las prácticas de Scrum en la
organización. Respeto de la organización y los implicados, con las pautas de tiempos y
formas de Scrum.
Para poder brindar estas funciones menciona que el Scrum Master debe tener un perfil con las
siguientes características: Excelente conocimiento de Scrum, Amplia vocación de servicio,
tendencia altruista, amplia capacidad para la resolución de problemas, Analítico y
observador, Saber incentivar y motivar, capacidad docente e instructiva, Buen carisma para
las negociaciones.

también indica como responsabilidades del Scrum Master: conocer el estado de las tareas,
identificar barrera y dependencias que impidan el flujo de Scrum y observar y resolver
conflictos personales.
 Conclusiones
En algunas tesis revisadas, el criterio de selecciÛn de la metodologÌa, es bastante subjetivo. Por
ello se ha buscado de establecer una escala ordinal de valoraciÛn de la importancia de los
criterios de selecciÛn, hecho que contribuye a una mejora en el proceso de selecciÛn pero que
no desaparece el nivel de subjetividad inherente al proceso En tal sentido, los autores se
comprometen, en un primo artÌculo, a enfocar el problema desde el punto de vista del proceso
analÌtico jer·rquico
En esta nueva generación, las metodologías tradicionales de desarrollo de software fueron
quedado obsoletas en determinados sectores, en los que la propia demanda de los
usuarios es más rápida que la capacidad de producción de las empresas ancladas a las
viejas metodologías de gestión de proyectos de sistemas informáticos. Este gran impacto
en las tecnologías, ha generado la necesidad de encontrar y crear nuevas metodologías de
trabajo y gestión, que aseguren la entrega en tiempo y forma del producto. Esta necesidad
de calidad, eficiencia, flexibilidad y rapidez en la entrega de un producto informático se
volvió prioridad y en conjunto con su necesidad se crearon las nombradas Metodologías
Agiles. El mundo en general y la vida de las personas, día a día se vuelve más ágil en todos
sus aspectos, siendo prácticamente inevitable la evolución en los sistemas de información
para poder atacar ésta demanda.

Ambos metodologías, pueden fracasar si son mal implementadas, gestionadas y

administradas.
 Bibliografias

https://repositorio.uca.edu.ar/handle/123456789/522
Amador Duran Toro, Beatriz Bernrdez Jiménez, “Metodología para el análisis de de requisitos
de sistemas de software versión 2.2”, Universidad de Sevilla, departamento de Lenguajes y
Sistemas informáticos, escuela Técnica superior de Ingeniería Informática, Diciembre de 2001.
Roger S.Pressman. “Ingeniería del Software: un enfoque práctico”, de segunda edición, Editorial
McGraw Hill. 1990. Manuel Díaz Rodríguez, Antonio Moña Gómez, “Ingeniería de Software
Especificación”, Departamento de Lenguajes de Ciencias de la computación, Universidad de
Málaga. Bruce I. Blum, “Software Engineering: A Holistic View”. Dorothy Graham, Erik Van
Veenendaal, Isabel Evans y Rex Black, “Foundations of Software Testing - ISTQB® Certification”.
2007. Duvall, Paul M., “Continuous Integration. Improving Software Quality and Reducing
Risk”. 2007. Hans Van Vliet, “Software Engineering. Principles and Practice”. Tercera edición.
2002. Ian Sommerville, “Software Engineering”. Sexta Edición. 2001. Ivar Jacobson, Grady
Booch y James Rumbaugh, “The Unified Software Development Process”. 1999. Kent Beck,
“Test-Driven Development by Example”. Kent Beck, Martin Fowler, “Planning Extreme
Programming”. 2000. Ken Schwaber, Mike Beedle, “Agile Software Development with
SCRUM”. 2008. Lawrence-Pfleeger y Shari, “Software Engineering: Theory and Practice”.
1998. Mitchel H. Levine, “Analyzing the Deliverables Produced in the Software Development
Life Cycle”. 2000. Pierre Bourque y Robert Dupuis, “Guide to the Software Engineering Body
of Knowledge”. 2004. Robert C. Martin, “Agile Software Development, Principles, Patterns,
and Practices”. Roger S. Pressman, “Software Engineering. A practitioner’s Approach”. Quinta
Edición. 2001. Ron Burback, “Software Engineering Methodology”. 1998. Tong Ka lok, Kent,
“Essential Skills for Agile Development”. Beck, K. “Extreme Programming Explained: Embrace
Change”. Boston: Addison-Wesley. 2000. Beck, K. Martin F. “Planning Extreme Programming”.
Boston: Addison-Wesley. 2001. Canós, J. H.; Letelier, P.; Penadés, M. C. “Metodologías ágiles
en el desarrollo del software”. Valencia: Universidad de Valencia. 2004. Cockburn, A. “Agile
Software Development”. Boston: Addison-Wesley. 2001. Cronin, G. “Extreme Solo: A Case
Study in Single Developer extreme Programming”. University of Auckland. 2003. Highsmith, J.
“Agile Software Development Ecosystems”. Boston: Addison-Wesley. 2002. Reynoso, C.
“Métodos heterodoxos en desarrollo del software”. Buenos Aires: Universidad de Buenos Aires.
2004. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas
Carrera: Licenciatura en Sistemas y Computación
______________________________________________________________________ 113 | P á
g i n a Salo, J. H.; Abrahamson, P.; Ronkainen, J.; Warsta, J. “Agile Software Development”.
2002. Schwaber, K.; Beedle, M. “Agile Software Development with Scrum”. Nueva Jersey:
Prentice Hall. 2002. Wake, W. C. “Extreme Programming Explored”. Boston: Addison-Wesley.
2002. Boehm, Barry W., “A Spiral Model of Software Development and Enhancement”, IEEE
Computer, Vol.21, No 15, pp.61-72. Mayo 1988. Martin, J., “Rapid Application Development”,
Macmillan Inc., New York. 1991. Beck, Kent, “Extreme Programming Explained”, Addison-
Wesley the XP Series, 2000. Alistair Cockburn. “Balancing Lightness with Sufficiency”.
Septiembre 2000. Pérez S. Jesús, “Metodologías Ágiles: La ventaja competitiva de estar
preparado para tomar decisiones lo más tarde posible y cambiarlas en cualquier momento”.
Artículo de Agile Spain. Grupo ISSI, Metodologías Ágiles en el Desarrollo de Software, Artículo
de Grupo ISSI Noviembre 2003. Acebal F.César, Cueva L. Juan, “EXtreme Programming (XP):
un nuevo método de desarrollo de software, Articulo de Novática”. Letelier P., Penadés C.,
“Metodologías ágiles para el desarrollo de Software: eXtreme Programming (XP)”, Universidad
Politécnica de Valencia. Shenone M. Hernán, “Diseño de una metodología Ágil de Desarrollo
de Software”, Tesis de Grado en Ingeniería en Informática, Universidad de Buenos Aires.
Página de Microsoft: MSDN en Español, “Métodos Heterodoxos en Desarrollo de Software”,
Artículo de Carlos Reynoso – Universidad de Buenos Aires, Abril del 2004.
REFERENCIAS BIBLIOGR£FICAS [1] Avison, D. and G. Fitzgerald, (1995). Information Systems
Development: Methodologies, Techniques, and Tools. McGraw-Hill. [2] Brooks, Fred (1995). The
Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Ed. Addison
Wesley. 2da edition. [3] CanÛs, Joseph (2005). Métodologías Ágiles en el Desarrollo de
Software. Universidad PolitÈcnica de Valencia. [4] Derniame, J (1999). Software Process:
Principles, Methodology, Technology. Lecture Notes in Computer Science 1500 Springer 1999,
ISBN 3-540-65516-6 BibTeX [5] Dijkstra E (1976). A Discipline of Programming. Prentice Hall,
Universidad de Texas. [6] Georgiadou, E. (2003) Software Proces And Product Improvement: A
Historical Perspective. Cybernetics and Systems Analysis. Vol. 39, N.° 1 2003. [7] RÌos, Edgar y
Wilson Suntaxi (2008). Desarrollo de un sistema inform·tico para los procesos de cosecha y post
cosecha de la camaronera Pampas de Cayanca. Tesis de grado, Facultad de ingenierÌa de
sistemas, Escuela PolitÈcnica Nacional, Quito.