UNIVERSIDAD TECNOLOGICA DE LOS ANDES

Facultad de Ingeniería
Escuela Profesional de Ingeniería de Sistemas e Informática
"Año del Dialogo y la Reconciliación Nacional”

TEMA:
METODOLOGÍAS EMPLEADAS EN
EL DESARROLLO DE PROYECTOS
INFORMATICOS

CURSO: Formulación y Evaluación de Proyectos.

DOCENTE: Ing. Luis David Gutiérrez Flores.

ESTUDIANTES: Janet López Huanca.

Karime Erika León Chayña.
Marco Antonio Poblete Cerazo.
Edgar Albert Díaz Huaillani.

CUSCO-PERÚ
2018
 PRESENTACIÓN

Ing. Luis David Gutiérrez Flores, docente de la asignatura de Gerencia de Proyectos

Informáticos, ante usted ponemos en consideración el siguiente trabajo monográfico
referente al tema “Metodologías Empleadas En El Desarrollo De Proyectos Informáticos”,
en el cual se ha expuesto y resaltado la preponderancia de la elección de una metodología
acorde los objetivos y necesidades de la organización para llevar a cabo exitosamente un
proyecto informático; este trabajo ha sido elaborado con esfuerzo y dedicación por parte de
sus estudiantes, los cuales somos conscientes de las exigencias que requieren la asignatura
de la cual usted se desempeña como docente.

Sin más que agregar agradecemos a la institución y a su persona por el servicio

integral que nos brindan a los estudiantes de esta prestigiosa casa de estudios.

Los Estudiantes.

2
 ÍNDICE

PRESENTACIÓN
ÍNDICE
INTRODUCCIÓN
1. Proyectos Informáticos……………………………………………………….…. 5
2. Gestión de proyectos informáticos: ¿tradicional o ágil?....................................... 5
2.1. Gestión de proyectos informáticos: la alternativa tradicional……….... 5
2.1.1. Cascada………………………………………………….…... 6
2.1.2. Prince2………………………………………………….…… 8
2.1.3. Proceso racional unificado (RUP)…………………….…….. 8
2.1.4. Desarrollo rápido de aplicaciones (RAD)…………….…….. 10
2.2. Gestión de proyectos informáticos: la alternativa ágil………………... 11
2.2.1. Scrum………………………………………………………... 12
2.2.2. Metodología Kanban…………………………………….….. 14
2.2.3. Metodologías Crystal (Crystal methods)……………………. 16
2.2.4. Metodología Extreme Programming (XP)……………….…. 18
CONCLUSIONES
REFERENCIAS BIBLIOGRÁFICAS

3
 INTRODUCCIÓN

En este trabajo describiremos las metodologías más importantes y difundidas en la

gestión de proyecto. La Metodología, (del griego metà "más allá", odòs "camino" y logos
"estudio"), hace referencia al conjunto de procedimientos basados en principios lógicos,
utilizados para alcanzar una gama de objetivos que rigen en una investigación científica o en
una exposición doctrinal.
En el ámbito de la gestión de proyectos, podemos definir una metodología como un
conjunto de técnicas, recomendaciones y verificaciones, que permitan sistematizar los
procesos en los que se descompone la gestión de un proyecto. El uso de una metodología
puede aportar muchas ventajas a la gestión de un proyecto, como pueden ser:

- Facilitar la tarea de planificación.

- Facilitar la tarea del control y seguimiento de un proyecto.
- Mejorar la relación coste/beneficio.
- Optimizar el uso de recursos disponibles.
- Facilitar la evaluación de resultados y el cumplimiento de los objetivos.
- Facilitar la comunicación efectiva entre los interesados del proyecto.
- Optimizar las fases del proceso de desarrollo.
- Facilitar el mantenimiento del producto final.
- Permitir la reutilización de partes del producto.
- Garantía de un nivel de calidad en el producto final.
- Ayudar en el cumplimiento de los plazos de tiempo fijados en la definición del
proyecto.
- Definir el ciclo de vida que más se ajuste a las condiciones y características del
desarrollo.

Según la filosofía de desarrollo, las metodologías se pueden clasificar en dos grupos, las
metodologías tradicionales, que se basan en una fuerte planificación durante todo el
desarrollo y un ciclo de vida más tradicional, y las metodologías ágiles, en las que el
desarrollo de software es incremental, cooperativo, sencillo y adaptado.

4
1. PROYECTOS INFORMÁTICOS
Un proyecto informático es una secuencia de actividades que desarrolla durante un tiempo
predeterminado y con unos recursos limitados un equipo de personas, informáticos y no
informáticos, para obtener unos resultados sobre la organización y los procesos de trabajo.
Una parte sustancial de estas actividades requieren conocimientos y habilidades en las
materias de sistemas y tecnologías de la información.
Un proyecto requiere establecer una estructura organizativa específica para el proyecto,
formada por personas de diferentes partes de una organización o de varias (al menos y
siempre la organización de “los informáticos” y los “no informáticos”), que no trabajan
habitualmente juntos. Esta nueva estructura tiene que gestionarse con la ayuda de métodos,
herramientas y habilidades también nuevas y diferentes de las de cada organización o grupo
humano de los que intervienen (los informáticos o los financieros o los de recursos humanos).
Ejemplos de proyectos informáticos
- Desarrollo de aplicaciones a medida
- Construcción de una base de datos
- Adquisición e instalación de infraestructura
- Integración de sistemas
- Implantación de software estándar
- Despliegue de un entorno de desarrollo
- Migración de aplicaciones
- Instalación de una red wi-fi
- Reingeniería de procesos y circuitos de información

2. GESTIÓN DE PROYECTOS INFORMÁTICOS: ¿TRADICIONAL O ÁGIL?

2.1. GESTIÓN DE PROYECTOS INFORMÁTICOS: LA ALTERNATIVA TRADICIONAL
Los modelos de planificación empleados en la gestión de proyectos informáticos tradicional,
también conocidos como SDLCs (Software Development Lifecycles: ciclos de vida de
desarrollo software) descomponen los proyectos en fases. Un ejemplo típico podría ser:
- Iniciación.
- Planificación.
- Ejecución.

5
 - Monitorización y control.
- Cierre de proyecto.
Este tipo de metodologías basadas en una rígida planificación funcionan bien para la gestión
de proyectos informáticos pequeños y bien definidos, donde existen pocas variables, los
acontecimientos son bastante previsibles y el trabajo tiene un alcance limitado. Entre las más
conocidas se encuentran las siguientes:
- Cascada
- PRINCE2
- Proceso Racional Unificado (RUP)
- Desarrollo rápido de aplicaciones (RAD)

2.1.1. CASCADA
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de
software se concibe como un conjunto de etapas que se ejecutan una tras otra. Se le denomina
así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas
una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una
cascada. Fases del modelo:
- Análisis de requisitos del software: En esta fase se analizan las necesidades de los
usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase
surge una memoria llamada SRD (documento de especificación de requisitos), que
contiene la especificación completa de lo que debe hacer el sistema sin entrar en
detalles internos.
Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir
nuevos resultados a mitad del proceso de elaboración del software de una manera.
- Diseño del sistema: Descompone y organiza el sistema en elementos que puedan
elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como
resultado surge el SDD (Documento de Diseño del Software), que contiene la
descripción de la estructura relacional global del sistema y la especificación de lo que
debe hacer cada una de sus partes, así como la manera en que se combinan unas con
otras.

6
 Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado.
El primero de ellos tiene como objetivo definir la estructura de la solución (una vez
que la fase de análisis ha descrito el problema) identificando grandes módulos
(conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define
la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la
organización del código para comenzar la implementación.
- Diseño del programa: Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario, así como también los análisis
necesarios para saber qué herramientas usar en la etapa de Codificación.
- Codificación: Es la fase en donde se implementa el código fuente, haciendo uso de
prototipos, así como de pruebas y ensayos para corregir errores. Dependiendo del
lenguaje de programación y su versión se crean las bibliotecas y componentes
reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso
mucho más rápido.
- Pruebas: Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente. Se buscan sistemáticamente y se corrigen
todos los errores antes de ser entregado al usuario final.
- Implementación o Verificación del programa: Es la fase en donde el usuario final o el
cliente ejecuta el sistema, y se asegura que cubra sus necesidades.
- Mantenimiento: Una de las etapas más críticas, ya que se destina un 75 % de los
recursos, es el mantenimiento del software ya que al utilizarlo como usuario final puede
ser que no cumpla con todas nuestras expectativas.

7
 Metodología Cascada
FUENTE:https://openclassrooms.com/en/courses/4309151-gestiona-tu-proyecto-de
desarrollo/4538221-en-que-consiste-el-modelo-en-cascada

2.1.2. PRINCE2
(Segunda versión el método de gestión de proyectos en ambientes controlados). Prince2
proviene del acrónimo en inglés PRojects IN Controlled Environments (PRINCE), es decir,
convertir proyectos, que manejan una carga importante de variabilidad y de incertidumbre,
en entornos controlados.
Más que un conjunto de buenas prácticas, PRINCE2 propone una metodología de gestión de
proyectos que cubre, mediante lo que se conoce como Temáticas, la Calidad, el Cambio, la
estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el
Riesgo y el Progreso del proyecto, justificado por un Business Case (o estudio de viabilidad)
que debe ser revisado durante el ciclo de vida del proyecto y justificar en todo momento el
proyecto como consecución de los beneficios esperados.
La aplicación de la metodología PRINCE2 va más allá del tipo de proyecto, pudiendo
aplicarse en proyectos de toda índole, como Desarrollo de software o Construcción, por poner
ejemplos.
Proporciona directrices generales, no sólo aplicables al desarrollo software, basadas en un
conjunto específico de fases (iniciación, direccionamiento, control, gestión de limitaciones,
gestión de entrega de producto y cierre). Su punto débil es la falta de definición de las
prácticas tácticas reales aplicables a cada una de ellas.

2.1.3. PROCESO RACIONAL UNIFICADO (RUP)

Se estructura en torno a fases que se aplican de forma iterativa, pudiendo incluso solaparse y
repetirse cíclicamente. A diferencia de PRINCE2, RUP describe un conjunto detallado de las
prácticas, incluso para los elementos menos relevantes de un proyecto. Esta ampliación, lejos
de aportar simplicidad, complica su aplicación práctica, al excederse en detalles.
Requisitos De Gestión:

8
La documentación apropiada es esencial para cualquier proyecto de gran envergadura; en
cuenta que RUP describe cómo documentar la funcionalidad, las limitaciones del sistema,
restricciones de diseño y requisitos de negocio.
Los casos de uso y los escenarios son ejemplos de artefactos de proceso dependiente, que se
han considerado mucho más eficaz en la captura de requisitos funcionales.

Fases De La Metodología RUP:

Las fases indican el énfasis se da en el proyecto en un instante dado. Para capturar la
dimensión temporal de un proyecto, RUP divide el proyecto en cuatro fases diferentes:
- Iniciación o Diseño: énfasis en el alcance del sistema;
- Preparación: énfasis en la arquitectura;
- Construcción: énfasis en el desarrollo;
- Transición: énfasis en la aplicación.

Fases de la metodología RUP

FUENTE: https://metodoss.com/metodologia-rup/

RUP se basa también en las 4ps:

- Personas
- Diseño
- Producto
- Proceso

9
Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo; iteraciones han
definido término como las fases son objetivos. Todas las fases generan artefactos. Estos serán
utilizados en la siguiente fase y documentar el proyecto y permite un mejor seguimiento.

2.1.4. DESARROLLO RÁPIDO DE APLICACIONES (RAD):

Este método destaca la participación del usuario y la construcción de prototipos para probar
las técnicas y perfeccionar los requisitos. Después de definir el alcance del proyecto en la
fase de planificación de necesidades, los usuarios interactúan con los analistas de sistemas
para desarrollar prototipos en la fase de diseño del usuario. Después, son los propios usuarios
quienes proporcionan información directa durante la fase de construcción. Por último, en la
fase de cierre, los usuarios finales están entrenados para usar el producto a medida que se
lleva a cabo el despliegue.
El Modelo RAD comprende las siguientes etapas:
- Modelado de gestión. Este modelo se basa en dar respuesta a las siguientes preguntas:
 ¿Qué información conduce el proceso de gestión?
 ¿Qué información genera?
 ¿A dónde va la información?
 ¿Quién la procesa?
- Modelado de datos. En este modelo se definen los almacenes de datos y cómo se
relacionan los almacenes entre sí.
- Modelado del proceso. Se utiliza para añadir, modificar, suprimir o recuperar un objeto
de datos.
- Generación de aplicaciones. Para esto se utiliza una herramienta de cuarta (o quinta)
generación que permite crear el software y facilitar la construcción del programa.
- Pruebas y entrega. El proceso de desarrollo finaliza realizando pruebas de calidad del
software diseñado con la herramienta RAD, posteriormente se realiza la
implementación de la aplicación

10
 Metodología RAD
FUENTE: https://sisingblog.wordpress.com/2017/04/03/metodologia-rad/

Sin embargo, debido al rápido crecimiento y la progresión de la industria de IT, las

metodologías han tenido que evolucionar para conseguir que también los grandes proyectos
terminen a tiempo y sin exceder el presupuesto designado. Es la agilización de la gestión de
proyectos informáticos.

2.2. GESTIÓN DE PROYECTOS INFORMÁTICOS: LA ALTERNATIVA ÁGIL

Durante el boom tecnológico de mediados de 1990, los críticos de los métodos tradicionales
surgieron con fuerza dentro de la comunidad de desarrollo de software. Sus pruebas hicieron
evidente que las metodologías tradicionales aplicadas a la gestión de proyectos informáticos
no funcionaban debido, principalmente, a su rigidez. Algo diametralmente opuesto a la
naturaleza de un proyecto de este tipo. Retrasos, ampliaciones del presupuesto, productos de
baja calidad, malentendidos e insatisfacción del cliente ratificaban la necesidad de un cambio
de enfoque. En 2001, un equipo de 17 desarrolladores de software publicó el Manifiesto Ágil
que, como indican sus principios rectores, buscaba:
- Flexibilidad.
- Agilidad.
- Capacidad de adaptación.

El partir de un planteamiento de desarrollo iterativo permite la entrega gradual de las

capacidades a los clientes, proporcionándoles mayor valor y ajustándose mejor a sus

11
necesidades en todo momento. Inspiradas por la metodología ágil han surgido posteriormente
una serie de marcos de procesos específicos, para la gestión de proyectos informáticos que
incluyen:
- Scrum.
- Kanban
- Métodos Crystal (Crystal Methods).
- Extreme Programming (XP).

2.2.1. SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un
proyecto. 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.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde
los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo
que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no
es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral
de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.

Proceso de Scrum
Las actividades que se llevan a cabo en Scrum son las siguientes (los tiempos indicados son
para iteraciones de 2 semanas):
- Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene
dos partes:

12
 1. Selección de requisitos (2 horas). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las
dudas que surgen y selecciona los requisitos más prioritarios que prevé que
podrá completar en la iteración, de manera que puedan ser entregados si el
cliente lo solicita.
2. Planificación de la iteración (2 horas). El equipo elabora la lista de tareas de
la iteración necesarias para desarrollar los requisitos seleccionados. La
estimación de esfuerzo se hace de manera conjunta y los miembros del equipo
se auto asignan las tareas, se auto organizan para trabajar incluso en parejas
(o grupos mayores) con el fin de compartir conocimiento (creando un equipo
más resiliente) o para resolver juntos objetivos especialmente complejos.

- Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos), normalmente
delante de un tablero físico o pizarra (Scrum Taskboard). El equipo inspecciona el
trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer
las adaptaciones necesarias que permitan cumplir con la previsión de objetivos a
mostrar al final de la iteración. En la reunión cada miembro del equipo responde a tres
preguntas:
 ¿Qué he hecho desde la última reunión de sincronización para ayudar al equipo
a cumplir su objetivo?
 ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir su
objetivo?
 ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro
objetivo?
Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda
mantener el foco para cumplir con sus objetivos.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar el objetivo de
la iteración o su productividad.

13
 Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para
prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican
los objetivos del proyecto (10%-15% del tiempo de la iteración) con el objetivo
de maximizar la utilidad de lo que se desarrolla y el retorno de inversión.

- Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos
partes:
1. Revisión (demostración) (1,5 horas). El equipo presenta al cliente los
requisitos completados en la iteración, en forma de incremento de producto
preparado para ser entregado con el mínimo esfuerzo. En función de los
resultados mostrados y de los cambios que haya habido en el contexto del
proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya
desde la primera iteración, re planificando el proyecto.
2. Retrospectiva (1,5 horas). El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El Facilitador
se encargará de eliminar o escalar los obstáculos identificados que estén más
allá del ámbito de acción del equipo.

2.2.2. METODOLOGÍA KANBAN

Se trata de una metodología japonesa, la cual consiste en ir etiquetando con tarjetas cada uno
de los procesos que se deben llevar a cabo, también se le ha denominado como “Un sistema
de producción de alta efectividad y productividad”. De hecho, empresas como la marca de
autos Toyota, fueron una de las primeras en implementarla para acelerar los procesos de
producción.
La palabra Kanban, en japonés significa “tarjetas visuales” y es precisamente lo que se
maneja en ella. Algunos la trabajan con lo que son tarjetas virtuales o bien simulando que se
pueden ver las tarjetas, sin embargo, una forma correcta de hacerlo es con tarjetas físicas,
que el equipo pueda ver y sentir para tener mayor efectividad.

14
Una de las principales ventajas de Kanban, es que además de ser una metodología Ágil,
también es muy fácil de usar e implementar, sobretodo porque el equipo de trabajo se unirá
y empezarán a trabajar a la par en diferentes aspectos del desarrollo. Veamos ahora, cuales
son los principios básicos de la metodología Kanban.

¿Qué ventajas presenta la metodología Kanban?

Las principales ventajas que aporta la metodología Kanban es que dada su representación a
través de tarjetas, es una metodología muy visual y muy sencilla, por lo que es fácilmente
incorporable al sistema y procesos de una empresa, además de que cualquiera que
empiece a usarla puede asimilarla de manera rápida y sencilla.

Reglas en las que se basa la metodología Kanban

FUENTE: https://revistas.udem.edu.co/index.php/ingenierias/article/view/1694/1751

Principios Básicos de Kanban

- Garantía de Calidad. Algo por lo que destaca Kanban, es que el ser una metodología
ágil, no es sinónimo de trabajar a las carreras o de hacer todo de golpe. Kanban
promueve la calidad antes que la velocidad, es decir, un producto bien hecho desde la

15
 primera vez que se elaboro es más rápido, que un producto mal hecho al cual se le
tienen que volver a meter las manos para arreglarlo.
- Desperdicios. la metodología kanban trabaja de una forma en la cual, solamente se
debe hacer lo necesario y requerido para que el sistema o el desarrollo quede bien.
Evitando todo aquello que es considerado como extra, superficial o innecesario. De
este modo no solamente se ofrece una mayor calidad en el producto, sino que además
se optimizan tiempos y costos.
- Mejora Continua. Algo interesante de la metodología Kanban, es que no solamente
de trata de un sistema diseñado para el proceso de desarrollo de Software, se puede
implementar en el desarrollo de cualquier tipo de producto, tal y como lo hizo Toyota.
Además, es un sistema que nos da la oportunidad de ir mejorando constantemente en
los procesos, dependiendo claro de cual sea el objetivo o la meta final.
- Es Flexible. Aquí es donde volvemos a hacer comparaciones con las metodologías de
antaño, donde la flexibilidad no existía, como si fueran metodologías del abuelo
estricto, acá eso no existe. La flexibilidad es uno de los principios de Kanban y ¿qué
obtenemos con ello? Gracias a que es flexible, podemos adelantarnos a un proceso que
queramos hacer o que tenga cierto nivel de prioridad, no necesitamos seguir una línea
de trabajo, lo cual hace de kanban una metodología más dinámica y además permite
resolver problemas que surjan de imprevisto, algo que con otras metodologías
simplemente ni se considera.

2.2.3. METODOLOGÍAS CRYSTAL (Crystal Methods).

Las metodologías Crystal son una familia de metodologías ágiles, donde cada una de ellas
está adecuada para un tipo de proyecto. Su creador es el popular Cockburn uno de los
firmantes del manifiesto ágil.
El nombre de metodologías Crystal viene de que cada proyecto software puede caracterizarse
según dos dimensiones, tamaño y criticidad, al igual que los minerales se caracterizan por
dos dimensiones, color y dureza. Y esta es una de las bases de las metodologías Crystal.
a otra gran clave de metodologías Crystal, común a casi todas las metodologías ágiles, es que
lo más determinante para el éxito, o fracaso, de un proyecto son las persona (te dejo también

16
este post de cuando tratamos este tema). Una de las claves que determinan el éxito (o fracaso)
de un proyecto software.

Características
Las personas, como dispositivos activos, tienen modos de éxito y modos de fallo. Los
siguientes son los principales:
- Cuando el número de personas aumenta, también aumenta la necesidad de coordinar.
- Cuando el potencial de daños se incrementa, la tolerancia a variaciones se ve afectada.
- La sensibilidad del tiempo en que se debe estar en el mercado varía: a veces este tiempo
debe acortarse al máximo y se toleran defectos, otra se enfatiza la auditoria,
contabilidad, protección legal, entre otros.
- Las personas se comunican mejor cara a cara, con la pregunta y la respuesta en el
mismo espacio de tiempo.
- El factor más significativo es “comunicación”.

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión
del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro variantes de
metodologías:
- Crystal Clear para equipos de 8 o menos integrantes
- Amarillo, para 8 a 20
- Naranja, para 20 a 50
- Rojo, para 50 a 100
- Azul, para 100 a 200

Variantes de metodologías
Fuente: https://iswugaps2crystal.wordpress.com/2015/09/06/crystal/

La más exhaustivamente documentada es Crystal Clear (CC), y es la que se ha de describir a

continuación. CC puede ser usado en proyectos pequeños. El otro método elaborado en

17
profundidad es el Naranja, apto para proyectos de duración estimada en 2 años. Los otros dos
aún se están desarrollando. Como casi todos los otros métodos, CC consiste en valores,
técnicas y procesos. Los siete valores o propiedades de CC son:
- Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no
solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser
diaria, semanal o mensual.
- Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es
disponer en la sala de un experto diseñador senior y discutir respecto del tema que se
trate.
- Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas cada o una vez al
mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.
- Seguridad personal. Hablar con los compañeros cuando algo molesta dentro del grupo
- Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo.
- Fácil acceso a usuarios expertos. Tener alguna comunicación con expertos
desarrolladores.

2.2.4. METODOLOGÍA EXTREME PROGRAMMING (XP)

El Extreme (o XP) Programming es una metodología de desarrollo que pertenece a las
conocidas como metodologías ágiles (otras son Scrum, Kanban…), cuyo objetivo es el
desarrollo y gestión de proyectos con eficacia, flexibilidad y control.
Ambos conceptos, relacionados estrechamente, son distintos. Agile es el marco de
trabajo para el desarrollo del software, se hace mediante un proceso iterativo y define las
prácticas y roles del equipo. Por su lado, el XP programming es una metodología basada
en la comunicación, la reutilización del código desarrollado y la realimentación.

Valores de la metodología XP
Como toda metodología, la programación extrema cuenta con algunos valores que son
fundamentales para que se lleve a cabo como debe ser. En algunas otras metodologías
estos puntos los conocíamos como principios básicos, es realmente lo mismo solo que acá
los mencionan como valores, veamos cuales son.

18
 - Comunicación. Del mismo modo que otras metodologías como la Scrum, el cliente
tiene una gran intervención, pero obviamente la comunicación dependerá de más
factores. En cuando a la comunicación entre personas, los programadores se
comunican constantemente ya que trabajan en parejas, la comunicación que se tiene
con el cliente debe ser constante, pues recordemos que incluso el forma parte del
equipo de trabajo y es responsabilidad del cliente, comunicarnos algunas
actualizaciones que requiera en el proceso, nuevas ideas, soluciones a problemas o
sencillamente algún problema que el vea. Todo debe ser comunicado, esta parte es
realmente fundamental para el desarrollo de un producto exitoso.
- Simplicidad. El primero de los valores de la metodología de programación XP, es
la simplicidad. Ya que la idea es que el desarrollo sea velóz, por lo cual todas las
cuestiones de diseño se simplifican al máximo, lo mismo sucede con las lineas de
código, si se pueden simplificar, se hacen, además de que regularmente el mismo
código es donde va la documentación comentada, de esta forma nos evitamos el estar
haciendo documentación extra. Por esta razón, además es importante que en el ciclo
de desarrollo de software mediante la metodología XP, las variables, métodos y
clases, tengan nombres amigables y relacionados, de este modo no solamente se
ayuda el equipo de trabajo.
- Retroalimentación. El hecho de que el cliente se encuentre involucrado en el
proyecto, ayudará inicialmente con la retroalimentación. Pues conforme pasan los
días y se va analizando el código por pequeñas etapas, el cliente puede ir corrigiendo,
agregando, quitando o excluyendo algunas cosas, esa es la ventaja de la
programación por periodos cortos de tiempo, es decir, imagina que llevas varios
meses desarrollando el proyecto y cuando vas con el cliente, el proyecto no le gusta
y desea hacer tantos cambios que te llevará una eternidad. Precisamente eso es lo
que se trata de evitar con la metodología XP.

Características que componen la metodología XP

vamos a ver sus características, de esta forma te podrás dar una mejor idea de cómo
funciona una metodología XP.

19
 - Tipo de Desarrollo Iterativo e incremental. Como hemos visto en lo que llevamos
hablando de la metodología XP, el método está basado en lo que son las mejoras
continuas, a base de iteraciones y por supuesto un desarrollo incremental al estilo
espiral.
- Pruebas Unitarias. Una de las características además son las pruebas unitarias. Se
utiliza software de codificación eso sí, dependiendo del lenguaje que estemos usando
es la herramienta que nos corresponde, pero de este modo se analiza el código y
solucionan errores, antes de validarlo y darlo por bueno.
- Trabajo en Equipo. Más específico todavía, es el trabajo en parejas, el objetivo es
que el enfoque en parejas sea mayor, las distracciones son menores y el aprendizaje
del uno con el otro permite que el avance del proyecto sea mucho más eficiente que
cuando una persona es la encargada.
- Código simple es la clave. Algo importante con la metodología extrema, es que la
simplicidad siempre llevará la ventaja. Principalmente porque cuando se requiera
hacer un cambio, si el código fuente es muy complejo, posiblemente lleve much as
horas realizar los cambios e incluso una alternativa seria ya no hacer ningún cambio
para no perder tiempo. Esta es precisamente la razón por la cual el código simple, es
fundamental en la metodología.

Equipo de Trabajo dentro de una Metodología XP

Roles que componen el equipo de trabajo en un proyecto que se elaborará mediante la
metodología XP, para que tengas una idea de la formación que se debe efectuar.

- Programador. Es el encargado del código del sistema y además de hacer las pruebas
unitarias que se solicitan.
- Tester. Básicamente es el encargado de las pruebas del desarrollo. Lo que se vaya
implementando, el teste lo prueba y le dice al cliente o mejor dicho, le comunica al
cliente las pruebas funcionales, para posteriormente comunicarle al equipo los
resultados.

20
 - Tracker. El seguimiento será lo suyo. Será el encargado de realizar las
comparaciones entre los tiempos estimados antes de empezar un desarrollo y los
tiempos reales que se obtuvieron.
- Entrenador. Este elemento es realmente importante, puesto que es el responsable
del proyecto básicamente. Se encarga de guiar al equipo por el camino que deben
seguir.
- Consultor. Regularmente el consultor no formaba parte del equipo, bueno de hecho
no lo integra. El consultor sigue siendo un externo, pero que cuenta con
conocimientos específicos y que será capaz de ayudar en la solución de problemas.
- Gestor. Posiblemente el líder más alto. Si se trata de unir a los clientes con los
programadores, el gestor es el intermedio, es decir. Es el encargado de vincul ar e
interrelacionar al cliente con los programadores.

En general, no obstante, los participantes en este tipo de equipos no siempre toman un rol
fijo y contribuyen con los conocimientos de cada uno en aras del beneficio colectivo.
Dicho lo anterior, a continuación, se describen las fases por las que se rige de alguna manera
la programación extrema:
- Exploración. En esta fase, los clientes plantean de manera general los rasgos de las
historias de usuario que son de interés para la primera entrega del producto. Al mismo
tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y
prácticas que se utilizarán en el proyecto.
- Planificación de la Entrega (Release). En esta fase el cliente establece la prioridad de
cada historia de usuario, y los programadores realizan una estimación del esfuerzo
necesario para cada una de las historias. Se toman los acuerdos sobre la parte que
integrara la primera entrega y se determina un cronograma en conjunto con el cliente.
Una entrega debería obtenerse en no más de tres meses.
- Iteraciones: Esta fase incluye varias iteraciones sobre el sistema antes de ser
entregado, en no más de tres semanas. Los elementos que deben tomarse en cuenta
durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas,
velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior.
Todo el trabajo de la iteración es expresado en tareas de programación, cada una de

21
 ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas
de programadores.
- Producción: La fase de producción requiere de pruebas adicionales y revisiones de
rendimiento antes de que el sistema sea trasladado al entorno del cliente. También, se
deben tomar decisiones sobre la inclusión de nuevas características a la versión actual,
debido a cambios durante esta fase.
- 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. Para realizar esto se requiere de tareas de soporte para el cliente.
- Muerte del Proyecto: Es cuando el cliente no tiene más historias para ser incluidas en
el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos
como rendimiento y confiabilidad del sistema. Se genera la documentación final del
sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios esperados por el cliente o
cuando no hay presupuesto para mantenerlo.

22
 CONCLUSIONES

- La gestión de proyectos es la aplicación de herramientas, conocimientos, habilidades,

y técnicas para conseguir los objetivos del proyecto, lo cual ha generado múltiples
metodologías de gestión de proyectos según diferentes enfoques.
- En el ámbito de la gestión de proyectos, podemos concluir que una metodología es
un conjunto de técnicas, recomendaciones y verificaciones, que permitan sistematizar
los procesos en los que se descompone la gestión de un proyecto.

23
 REFERENCIAS BIBLIOGRÁFICAS

Colciencias Corp. (20 de 04 de 2016). Colciencias. Obtenido de

http://www.colciencias.gov.co/sites/default/files/upload/convocatoria/anexo3_3.pdf
https://openclassrooms.com/en/courses/4309151-gestiona-tu-proyecto-de
desarrollo/4538221-en-que-consiste-el-modelo-en-cascada
https://metodoss.com/metodologia-rup/
https://sisingblog.wordpress.com/2017/04/03/metodologia-rad/
https://revistas.udem.edu.co/index.php/ingenierias/article/view/1694/1751
https://iswugaps2crystal.wordpress.com/2015/09/06/crystal/
http://bibing.us.es/proyectos/abreproy/70193/fichero/3.+METODOLOG%C3%8DAS+DE+
GESTI%C3%93N+DE+PROYECTOS.pdf

24