UNIVERSIDAD AUTONMA DE CHIHUAHUA

FACULTAD DE CONTADURA Y ADMINISTRACIN

SECRETARA DE INVESTIGACIN Y POSGRADO

USO DE METODOLOGAS GLES PARA EL DESARROLLO DE SOFTWARE EN

UNA EMPRESA DE DESARROLLO DE SOFTWARE EN CIUDAD JUREZ

TRABAJO ESCRITO: ESTUDIO DE CASO

QUE COMO REQUISITO PARCIAL PARA OBTENER EL GRADO DE

MAESTRA EN SISTEMAS DE INFORMACIN

PRESENTA:
JOS ANTONIO SANDOVAL ACOSTA

Ciudad Jurez, Chih., abril de 2009

UNIVERSIDAD AUTONMA DE CHIHUAHUA

FACULTAD DE CONTADURA Y ADMINISTRACIN
SECRETARA DE INVESTIGACIN Y POSGRADO

Los que suscriben, ASESOR de la Materia de Sistemas de Informacin y ASESOR

de Metodologa respectivamente, hacen CONSTAR que el TRABAJO ESCRITO
orientado a un TRABAJO DE INVESTIGACION denominado:
USO DE METODOLOGAS GLES PARA EL DESARROLLO DE SOFTWARE EN
UNA EMPRESA DE DESARROLLO DE SOFTWARE EN CIUDAD JUREZ

Elaborada por el pasante de la Maestra en Sistemas de Informacin:

JOS ANTONIO SANDOVAL ACOSTA
Rene los trminos exigidos por el Reglamento General de Estudios de Posgrado y
por el Reglamento Interior de la Facultad de Contadura y Administracin, por lo que
se aprueba como requisito para la tramitacin del examen de grado correspondiente.
Se extiende la presente a los diecisiete das del mes de abril de dos mil nueve.
Asesor de la Materia

Asesor de Metodologa

M .A. P. Ana Mara Gallo Snchez

M.S.I. Ren Arroyo vila

Catedrticos Revisores

M.A. Csar Pacheco

M.A. Mercedes Ogaz Alamillo

AGRADECIMIENTOS
A dios por permitirme llegar a este punto en mi desarrollo profesional y acadmico.
Agradezco especialmente a las personas que colaboraron con este trabajo,
asesorndome, respondiendo mis preguntas, y contribuyendo con un poco de su
conocimiento para enriquecer el mo.

DEDICATORIA
Dedico este trabajo a aquellas personas que han colaborado con mi formacin
acadmica y mi desarrollo profesional, ya que con este trabajo, obtengo un logro
muy importante en mi vida profesional y en mis aspiraciones personales.

ii

RESUMEN
Objetivo: Describir el uso de metodologas giles en una empresa de desarrollo de
software en Ciudad Jurez, Chihuahua.
Metodologa: La investigacin fue de carcter no experimental ya que no se
manipul la variable. La poblacin de inters fueron todos los equipos de desarrollo
que pertenecientes a la empresa de desarrollo de software. El marco muestral
comprendi 3 equipos de desarrollo de software de dicha empresa, conformados por
4 personas cada uno La unidad de anlisis estuvo enfocada a aquellos equipos de
desarrollo de la empresa que lleven proyectos manejados (con gerencia). La variable
evaluada fue el uso de metodologas giles en el proceso de desarrollo de software.
Los indicadores fueron: Tiempo de Respuesta al cliente; Resultados de la revisin de
producto; Resultados de los mtricos de calidad. El tipo de muestreo aplicado fue
total, toda la poblacin. La recoleccin de los datos se llev a cabo a travs del
cuestionario, el cual se envi por correo electrnico a cada uno de los integrantes de
los equipos de desarrollo de software. Resultados: Los principales resultados
indican que el uso de una metodologa gil para el desarrollo de software mejora los
tiempos de entrega as como la productividad, y ayuda a reducir costos en el proceso
de desarrollo de software.
Palabras clave (Metodologas giles, desarrollo de software).

iii

NDICE GENERAL
Agradecimientos
Dedicatoria
Resumen
ndice de Cuadros
ndice de Grficas
ndice de Figuras
Introduccin
Antecedentes
Marco Terico
Breve Introduccin a las Metodologas de Desarrollo
El Manifiesto gil
Programacin Extrema (XP)
Metodologa Scrum
Otras Metodologas giles
Metodologas Tradicionales
La metodologa RUP
Codificar y corregir (Code-and-Fix)
Microsoft Solution Framework (MSF)
Modelo en cascada
Desarrollo evolutivo
Desarrollo incremental
Desarrollo en espiral
Cuando Usar Metodologas giles
Ventajas de las Metodologas giles
Problemas Comunes a los Mtodos giles
Justificacin
Objetivo
Metodologa
1.- Lugar y tiempo
2.- Carcter
3.- Diseo
4.- Poblacin de inters
5.- Unidad de anlisis
6.- Variable
7.- Indicadores
8.- Recoleccin de datos
9.- Anlisis de la informacin
10.- Interpretacin de resultados
Resultados y Discusin
Conclusiones y Recomendaciones
Literatura citada
Anexos

Pgina
I
ii
Iii
v
vi
vii
1
2
4
4
6
11
14
17
18
18
20
21
22
24
26
28
32
33
34
36
37
38
38
38
38
38
38
38
39
39
39
39
40
55
56
58

iv

NDICE DE CUADROS
Cuadro
nmero

1
2
3

Ttulo

Pgina

Metodologas giles ms conocidas para el desarrollo de

software
Diferencias entre metodologas tradicionales y giles
Diferencias por etapas y enfoque metodolgico

9
29
31

NDICE DE GRFICAS
Ttulo

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Grfica nmero
Pgina

Nivel de Participacin
Roles desempeados por los encuestados
Nivel de conocimiento/participacin
Tiempo de uso de Metodologas giles
Tamao del rea de trabajo
Conocimientos sobre la empresa
Porcentaje de proyectos con metodologas giles
Tiempo de uso de Metodologas giles por la empresa
Localidades que usan Metodologas giles
Razones para adoptar Metodologas giles
Metodologas giles ms conocidas
Barreras para adoptar las Metodologas giles
Porcentaje de proyectos exitosos usando Metodologas giles
Estimacin de beneficios obtenidos

41
42
43
44
45
46
47
48
49
50
51
52
53
54

vi

NDICE DE FIGURAS
Figura
nmero

1
2
3
4
5
6
7
8
9

Ttulo

Metodologa XP (eXtreme Programing)

Flujo de trabajo de la metodologa XP
Ciclo de la metodologa Scrum
Rational Unified Process (RUP)
Partes que componen la Metodologa MSF
Iteraciones en el Modelo en Cascada
Descripcin del Modelo de Desarrollo Evolutivo
Flujo General del Modelo de Desarrollo Iterativo Incremental
Flujo del Modelo de desarrollo en Espiral

Pgina

11
13
16
19
21
24
25
27
29

vii

INTRODUCCIN
Actualmente existen dos enfoques para realizar el desarrollo de software dentro de la
industria de tecnologas de informacin, las metodologas tradicionales y las
metodologas giles para el desarrollo de software. En la empresa de desarrollo
de software en Ciudad Jurez se utilizan ambos enfoques en sus equipos de
trabajo y desarrollo de software.
Existen 3 equipos de desarrollo de software, dos de ellos hacen uso de una
metodologa de software gil, mientras que el tercer equipo utiliza una
metodologa ms rgida y estricta que requiere de autorizaciones adicionales,
revisiones tanto en diseo como en cambios realizados y tiene una estructura de
desarrollo que toma ms tiempo llevar los cambios al usuario final.
La intencin de esta investigacin es describir el uso de metodologas giles para el
desarrollo de software dentro de dicha empresa y realizar una redaccin
explicativa de los beneficios obtenidos con su uso. No se pretende modificar los
actuales mtodos de trabajo ya que estos han demostrado tener gran eficacia
para la empresa.

ANTECEDENTES
La empresa de desarrollo de software de ciudad Jurez, Chihuahua con la que se
trabaj, es una empresa de Servicios de Tesorera y Seguridad de Valores (TSS
Treasury & Securities Services) genera ms de $ 8 mil millones en ingresos anuales
y es un lder mundial en custodia, prstamo de valores, fondos y administracin, as
como en servicios de tesorera. Servicios de Tesorera y de Valores apoya las
necesidades de los clientes institucionales en todo el mundo y es uno de los tres
principales proveedores en sus dos negocios: Servicios de Tesorera (TS Treasury
Services) y el Mundo Servicios de Valores (WSS Worldwide Securities Services).
En 2005, dicha empresa adquiri a otra, lder mundial en el comercio proveedor de
soluciones de gestin de ayudar a los clientes reducir el riesgo, mejorar el
cumplimiento y racionalizar el flujo de los envos internacionales. Ahora conocido
como Global Trade Services, la entidad combinada se integra la informacin utilizada
para la gestin financiera y la actividad fsica la cadena de suministro.
La empresa, ayuda a los clientes a gestionar mejor su integridad fsica y financiera
con las cadenas de suministro de una completa gama integrada de soluciones de
comercio y logstica. Como el nico banco con el de extremo a extremo la capacidad
de la cadena de suministro, que agregan valor tanto al importador y exportador de
partes de las transacciones. Dicha empresa ayuda a facilitar la financiacin, reducir
el riesgo comercial, gestin de relaciones de la cadena de suministro, mejorar el
cumplimiento y racionalizar los flujos comerciales.
La empresa proporciona el servicio administrado de las operaciones (GTS Global
Trade Services), garantizando la

optimizacin de impuestos, garantizando las

operaciones en tiempo;

para ello, esta rea est conformada por diferentes

departamentos: direccin

general, evaluacin de proyectos, operacin, soporte

usuario, anlisis y diseo, desarrollo, calidad, centro de datos.

Como antecedente podemos mencionar que esta empresa est a la vanguardia en

operaciones aduaneras hoy en da a nivel internacional, contando con la ventaja
competitiva de brindar un sistema maduro y muy confiable, que le ha permitido
brindar servicios administrados a firmas fuertes en varios regmenes aduaneros
como son Deposito Fiscal, Maquiladora, Recinto Fiscalizado.
El rea de servicios administrados en Mxico cuenta aproximadamente con 110
personas para llevar la operacin completa de las diferentes cuentas. Cada uno de
los miembros tiene actividades especificas que contribuyen en el cumplimiento de la
tarea final, que es llevar la operacin al da del cliente, garantizando tiempo, fechas
de cumplimiento, recuperacin de saldos a favor, monitoreo de vencimientos, etc.
La empresa de desarrollo de software

en Ciudad Jurez tiene su centro de

desarrollo de software para Mxico, cuenta con una amplia cartera de clientes que
hacen uso de sus productos.
La empresa ofrece 3 principales productos de software a sus clientes, estos son
Sistema de Trmite Aduanero (STA), Sistema Automatizado Aduanero Integral (SAAI
M3) y Deposito Fiscal (DF). Cuenta con 3 equipos de desarrollo en ciudad Jurez,
cada uno encabezado por un lder.
Actualmente la empresa hace uso de diferentes mtodos de desarrollo, estos
dependen del equipo de desarrollo y el producto que desarrollan, siendo uno de los
equipos el que utiliza una metodologa rgida para el desarrollo y dos equipos mas
hacen uso de mtodos ms giles y menos documentacin.

MARCO TERICO
Breve Introduccin a las Metodologas de Desarrollo
Dentro del desarrollo de software y la altiva necesidad de que los proyectos lleguen
al xito y obtener un producto de gran valor para nuestros clientes, generan grandes
cambios en las metodologas adaptadas por los equipos para cumplir sus objetivos,
puesto que, unas se adaptan mejor que otras, al contexto del proyecto brindando
mejores ventajas.
Es por eso de la importancia de una metodologa robusta que ajustada en un equipo
cumpla con sus metas, y satisfaga mas all de la las necesidades definidas al inicio
del proyecto.
El xito del producto depende en gran parte de la metodologa escogida por el
equipo, ya sea tradicional o gil, donde los equipos maximicen su potencial

aumenten la calidad del producto con los recursos y tiempo establecidos.

Muchos de los proyectos de software fracasan antes de entrar a la fase de
desarrollo, debido a una mala planeacin o al exceso de sta. El 71 % de todos los
proyectos de IT no se cumplen o experimentan problemas de fecha de entrega o
presupuesto (The Standish Group, 2001).
Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de
mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse
la concepcin y fundamentos de metodologas existentes en otras reas y adaptarlas
al desarrollo de software. Esta nueva etapa de adaptacin contena el desarrollo
dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente
en el campo del software.

Las metodologas tradicionales concentran su atencin en llevar una documentacin

exhaustiva de todo proyecto y centran su atencin en cumplir en un plan de proyecto,
definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las
caractersticas importantes dentro de este enfoque tenemos los altos costos al
implementar y al no ofrecer una buena solucin para proyectos donde el entorno es
voltil. Las metodologas tradicionales o formales se enfocan en documentacin,
planificacin y procesos (plantillas tcnicas de administracin, revisiones, etc.)
(Figueroa y Sols, 2008).
Las metodologas tradicionales presentan ciertos problemas tales como:

Fases de obtencin de requerimientos, anlisis y diseo muy costosas en

cuanto a tiempo y recursos.

Muchos niveles de aprobacin, lo cual lleva comnmente al retraso en las

fechas de entrega.

Una vez que se llega a la fase de desarrollo es muy difcil para el equipo el
entender un sistema tan complejo al ser tan amplia el rea que se abarca.

En el otro lado estn las metodologas giles, las cuales se han incorporado muy
bien a un mundo de requerimientos cambiantes, y estas nos muestran ciertas
ventajas sobre los mtodos tradicionales, tales como:

Buena respuesta a los cambios durante la fase de desarrollo, lo cual es cada

vez ms comn en los proyectos.

Entrega continua y rpida de secciones funcionales del sistema.

Involucramiento del cliente.

Eliminacin del trabajo innecesario.

Mayor atencin a la parte tcnica y de diseo.

Mejora continua de los procesos y equipos de desarrollo (Highsmith, 2002).

Las metodologas giles presentan un nuevo enfoque que nace como respuesta a los
problemas de las metodologas tradicionales y se basa en aspectos puntuales, el
retrasar las decisiones y la planificacin adaptativa; permitiendo potencia an ms en
el desarrollo de software a gran escala. El resultado es un Manifiesto gil cuyas
principales ideas son:

Los individuos y las iteraciones entre ellos son ms importantes que las
herramientas y los procesos empelados.

Es ms importante crear un producto de software que funcione que escribir

documentacin exhaustiva.

La colaboracin con el cliente debe prevalecer sobre la negociacin de

contratos.

La capacidad de respuesta ante un cambio es ms importante que el

seguimiento estricto de un plan (Pires, 2001).

El Manifiesto gil
En febrero 11 13 de 2001 en las montaas Wasatch en Utah, 17 personas se
reunieron para platicar, esquiar y relajarse. Lo que surgi de esa reunin fue la
Alianza de Desarrollo de Software gil, todos los miembros de la alianza firmaron el
llamado Manifiesto gil el cual tiene como texto: Estamos poniendo al descubierto
nuevas y mejores maneras de desarrollar software, hacindolo y ayudando a otros a
que lo hagan. A travs de este trabajo hemos llegado a valorar: Los individuos y la
interaccin sobre los procesos y herramientas; El software que funciona sobre la
documentacin abarcadora; la colaboracin con el cliente sobre negociacin de
contratos; Responder al cambio sobre seguir un plan; Eso es, aunque hay valor en
las partes de la derecha, nosotros valoramos mas los de la izquierda.

Principios del Manifiesto:

La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

de software que le aporte un valor.

Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.

Entregar frecuentemente software que funcione desde un par de semanas

hasta un par de meses, con el menor intervalo de tiempo posible entre
entregas.

La gente del negocio y los desarrolladores deben de trabajar juntos a lo largo

del proyecto.

Construir el proyecto en torno a individuos motivados. Darles el entorno el

apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

El dialogo cara a cara es el mtodo ms eficiente y efectivo para comunicar

informacin dentro de un equipo de desarrollo.

El software que funciona es la medida principal de progreso.

Los procesos giles promueven un desarrollo sostenible. Los promotores

desarrolladores y usuarios deberan ser capaces de mantener una paz
constante.

La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.

La simplicidad es esencial.

Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos.

En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms

efectivo y segn esto ajusta su comportamiento (Abrahamsson y Ronkainen,
2002).

El movimiento gil no es anti-metodolgico menciona Fowler, se requiere restaurar

credibilidad en la palabra. Tambin se requiere restaurar un balance: adoptar el
modelado, pero no precisamente para archivarlo en un polvoso repositorio
corporativo. Adoptar documentacin, pero no para desperdiciar grandes cantidades
de papel en la creacin de tomos que nunca sean mantenidos o raramente usados
(Fowler, 2001).
Los creadores de dicho Manifiesto son: Kent Beck (Extreme Programming), Mike
Beedle, Arie van Bennekum (Dynamics Solutions Delivery Model), Alistair Cockburn
(Cystal), Ward Cunningham (Extreme Programming), Martin Fowler (Extreme
Programming), James Grenning (Extreme Programming), Jim Highsmith (Agile
Spreadsheet Development), Andrew Hunt (Pragmatic Programming), Ron Jeffries
(Extreme Programming), Jon CERN (Feature Driven Development), Brian Marick,
Robert C. Martin (Extreme Programming), Steve Mellor, Ken Schwaber (Scrum), Jeff
Sutherland (Scrum), Dave Thomas (Pragmatic Programming).
En la comunidad de la ingeniera del software, se est viviendo con intensidad un
debate abierto entre los partidarios de las metodologas tradicionales y aquellos que
apoyan las ideas emanadas del Manifiesto gil.
Por un lado, para muchos equipos de desarrollo el uso de metodologas tradicionales
les resulta muy lejano a su forma de trabajo actual; considerando las dificultades de
su introduccin e inversin asociada en trminos de formacin y compra de
herramientas. Por otro, las caractersticas de los proyectos para los cuales las
metodologas agiles han sido especialmente pensadas se ajustan a un amplio rango
de proyectos de desarrollo de software; aquellos en los cuales los equipos de
desarrollo son pequeos, con plazos reducidos, requisitos voltiles, basados en
nuevas tecnologas, etc. (Abrahamsson y Ronkainen, op cit).

Estas metodologas estn especialmente orientadas para proyectos que necesitan de

una solucin a la medida, con una elevada simplificacin sin dejar de lado el
aseguramiento de la calidad del producto. Las metodologas giles se centran en el
factor humano y el producto software; es decir, ellas le dan mayor valor al individuo, a
la colaboracin del cliente y al desarrollo incremental del software con iteraciones
muy cortas. En el cuadro 1 se muestran las metodologas giles ms comunes.
Cuadro 1. Metodologas giles ms conocidas para el desarrollo de software.

Metodologa

Creacin

Tipo de Modelo

Caracterstica

Highsmith 2000
Adaptative Software
(ASD)
Agile Modeling (AM)

Practicas + Ciclo de
vida

Inspirado en Sistemas
adaptativos complejos

Ambler 2002

Crystal Methods (CM)

Cockburn 1998

Agile RUP
(dX)
Dynamic Solutions
Delivery Model
(DSDM)
Evolutionary Project
Management
(Evo)
Extreme
Programming
(Xp)
Feature-driven
development
(FDD)
Lean Development
(LD)

Booch, Martin,
Newkirk 1998
Stapleton 1997

Metodologa basada
en la prctica
Familia de
Metodologas
Framework
/ Disciplina
Framework / Modelo
de ciclo de vida

Suministra modelado gil a

otros mtodos
nfasis en modelado de
ciclos
XP al revs con artefactos
de RUP
Creado por 16 expertos en
RAD

Gilb 1976

Framework adaptativo

Primer mtodo gil existente

Beck 1999

Disciplina en prcticas
de Ingeniera

Mtodo gil radical

De Luca & Coad 1998

Palmer & Felsing
2002
Charette 2001,
Mary & Tom
Poppendieck
Microsoft 1994

Metodologa

Mtodo gil de diseo y

construccin

Forma de Pensar
Modelo logstico

Metodologa basada en
procesos productivos

Lineamientos,
Disciplinas, prcticas

Framework de desarrollo de
soluciones

McConnell 1996

Survey de tcnicas y
modelos
Proceso Unificado

Seleccin de mejores
prcticas, no mtodos
mtodo (gil?) con
modelado

Proceso (Software de
management)

Complemento de otros
mtodo, giles o no

Microsoft Solutions
Framework
(MSF)
Rapid Development
(RAD)
Racional Unified
Process
(RUP)
Scrum

Krutchen 1996

Sutherland 1994
Schwaber 1995
Fuente (Reynoso, 2005)

A diferencia de los enfoques ms tradicionales, las metodologas giles se centran en

la generacin de liberaciones en las primeras etapas de productos de trabajo
utilizando principalmente tcnicas de colaboracin, como por ejemplo, programacin
par, refactorizacin y tener clientes trabajando en el lugar como parte del equipo de
miembros. Los programadores utilizan estas liberaciones que son productos de
trabajo, no prototipos para demostrar las caractersticas y funciones a los
contratantes que estn relacionados con su utilizacin, comercializacin y apoyo
(Cockburn, 2001).
En los proyectos de desarrollo de software ms tradicionales, el ciclo de vida
(simplificado) es anlisis, Desarrollo, Pruebas; primero obteniendo todos los
requerimientos conocidos para el producto completo, despus desarrollando todos
los elementos de software, despus probando que el producto completo est listo
para entregarse. En el desarrollo de software gil, el ciclo es anlisis, desarrollo,
pruebas, anlisis, desarrollo, pruebas; y as sucesivamente de manera que se
haga cada paso para cada caracterstica, una caracterstica a la vez. Las ventajas de
este proceso iterativo en el desarrollo de software son

Reduce Riesgos: clarifica la visibilidad de que esta terminado en fecha a

travs del proyecto.

Incrementa el valor: entregando algunos beneficios tempranamente; siendo

capaz de liberar un producto, en lugar de esperar a que todas las
caractersticas estn listas.

Ms flexibilidad/agilidad: se puede elegir el cambiar de direccin o adaptarse a

las siguientes iteraciones basadas en el software que se est usando
actualmente.

Mejor administracin de costos (Waters, 2007).

10

A continuacin se muestra una de las metodologas giles ms comunes y sobre la

cual muchos autores han escrito una gran cantidad de artculos.
Programacin Extrema (XP)
La Programacin Extrema (XP) es una metodologa gil que ha ganado creciente
aceptacin y reconocimiento en la comunidad del software. XP promueve una
disciplina de desarrollo de software basada en principios de simplicidad,
comunicacin, realimentacin y coraje. Est diseada para el uso con equipos
pequeos que necesitan desarrollar software rpidamente en un ambiente de
continuos cambios de requerimientos.
La metodologa XP utiliza prcticas efectivas como Refactoring, Programacin en
Pares, e Integracin Continua. Cada prctica proporciona una importante ventaja
para el ciclo de desarrollo. Por ejemplo, Refactoring proporciona un cambio gradual
del cdigo fuente hacia un diseo ms adaptable. La Programacin en Pares permite
a dos programadores compartir sus pensamientos y conocimientos tcnicos frente a
una pantalla en comn. Finalmente, la Integracin Continua asegura que exista
siempre un sistema corriendo en el que se ejecuten todas las pruebas con xito
(Beck, 1999). La figura 1 muestra la descripcin de la metodologa XP.
Figura 1: Metodologa XP (eXtreme Programing)

Fuente (Beck, op cit).

11

Caractersticas de la metodologa XP, esta se basa en:

Pruebas Unitarias: se basa en las pruebas realizadas a los principales

procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos
hacer pruebas de las fallas que pudieran ocurrir. Es como si nos
adelantramos a obtener los posibles errores.

Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean

patrones o modelos estndares, siendo ms flexible al cambio.

Programacin en pares: una particularidad de esta metodologa es que

propone la programacin en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estacin de trabajo.
Cada miembro lleva a cabo la accin que el otro no est haciendo en ese
momento. Es como el chofer y el copiloto: mientras uno conduce, el otro
consulta el mapa.

La metodologa XP propone algunas formas de trabajar:

Empieza en pequeo y aade funcionalidad con retroalimentacin continua

El manejo del cambio se convierte en parte sustantiva del proceso

El costo del cambio no depende de la fase o etapa

No introduce funcionalidades antes que sean necesarias

El cliente o el usuario se convierte en miembro del equipo

Derechos del cliente dentro de la metodologa XP:

Decidir que se implementa

Saber el estado real y el progreso del proyecto

Aadir, cambiar o quitar requerimientos en cualquier momento

Obtener lo mximo de cada semana de trabajo

Obtener un sistema funcionando cada tres o cuatro meses

12

Derechos del desarrollador en la metodologa XP:

Decidir cmo se implementan los procesos

Crear el sistema con la mejor calidad posible

Pedir al cliente en cualquier momento aclaraciones de los requerimientos

Estimar el esfuerzo para implementar el sistema

Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodologa es:

La comunicacin, entre los usuarios y los desarrolladores

La simplicidad, al desarrollar y codificar los mdulos del sistema

La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y

los usuarios finales (Wells, 2003).

El funcionamiento de la metodologa XP puede ser resumido por medio del esquema

descrito en la figura 2.
Figura 2: Flujo de trabajo de la metodologa XP.

Fuente (Wells, op cit)

13

Metodologa Scrum
Esta es, despus de la metodologa XP, la metodologa gil mejor conocida y la que
otros mtodos giles recomiendan como complemento, aunque su porcin del
mercado (3% segn el Cutter Consortium) es ms modesta que el ruido que hace.
Scrum es una metodologa para el desarrollo gil de productos, expuesta, en el
artculo The New Product Development Game [Harvard Business Review Ene-Feb
1986 en el que ponen de manifiesto que:

El mercado competitivo de los productos tecnolgicos, adems de los

conceptos bsicos de calidad, coste y diferenciacin, exige tambin rapidez y
flexibilidad.

Los nuevos productos representan cada vez un porcentaje ms importante en

el volumen de negocio de las empresas.

El mercado exige ciclos de desarrollo ms cortos (Takeuchi y Nonaka, 1986).

El mtodo Scrum no est concebido como mtodo independiente, sino que se

promueve como complemento de otras metodologas, incluyendo XP. Como mtodo,
Scrum enfatiza valores y prcticas de gestin, sin pronunciarse sobre requerimientos,
implementacin y dems cuestiones tcnicas; de all su deliberada insuficiencia y su
complementariedad. Scrum se define como un proceso de administracin y control
que implementa tcnicas de control de procesos; se lo puede considerar un conjunto
de patrones organizacionales.
Los valores de la metodologa Scrum son:

Equipos auto-dirigidos y auto-organizados. No hay gerente que decida, ni

otros ttulos que miembros del equipo o cerdos; la excepcin es el Scrum
Master que debe ser 50% programador y que resuelve problemas, pero no
manda. Los observadores externos se llaman gallinas; pueden observar,
pero no interferir ni opinar.

14

Una vez elegida una tarea, no se agrega trabajo extra. En caso que se
agregue algo, se recomienda quitar alguna otra cosa.

Encuentros diarios con las tres preguntas indicadas en la figura. Se realizan

siempre en el mismo lugar, en crculo. El encuentro diario impide caer en el
dilema sealado por Fred Brooks: Cmo es que un proyecto puede
atrasarse un ao?: Un da a la vez.

Iteraciones de treinta das; se admite que sean ms frecuentes.

Demostracin a participantes externos al fin de cada iteracin.

Al principio de cada iteracin, planeamiento adaptativo guiado por el cliente

(Schwaber y Beedle, 2001).

El nombre de los miembros del equipo y los externos se deriva de una tpica fbula
agilista: un cerdo y una gallina discutan qu nombre ponerle a un nuevo restaurant;
la gallina propuso Jamn y Huevos. No, gracias, respondi el cerdo, Yo estar
comprometido, pero t slo involucrada.
La metodologa Scrum define seis roles:
1. El Scrum Master: Interacta con el cliente y el equipo. Es responsable de
asegurarse que el proyecto se lleve a cabo de acuerdo con las prcticas,
valores y reglas de Scrum y que progrese segn lo previsto. Coordina los
encuentros diarios, formula las tres preguntas cannicas y se encarga de
eliminar eventuales obstculos. Debe ser miembro del equipo y trabajar a la
par.
2. Propietario del Proyecto: Es el responsable oficial del proyecto, gestin,
control y visibilidad de la lista de acumulacin o lista de retraso del producto
(product backlog). Es elegido por el Scrum Master, el cliente y los ejecutivos a
cargo. Toma las decisiones finales de las tareas asignadas al registro y
convierte sus elementos en rasgos a desarrollar.
3. Equipo de Scrum: Tiene autoridad para reorganizarse y definir las acciones
necesarias o sugerir remocin de impedimentos.
4. Cliente: Participa en las tareas relacionadas con los elementos del registro.

15

5. Administracin: Est a cargo de las decisiones fundamentales y participa en la

definicin de los objetivos y requerimientos. Por ejemplo, selecciona al Dueo
del Producto, evala el progreso y reduce el registro de acumulacin junto con
el Scrum Master.
6. Usuario: La dimensin del equipo total de Scrum no debera ser superior a
diez ingenieros. El nmero ideal es siete, ms o menos dos, una cifra
cannica en ciencia cognitiva [Mil56]. Si hay ms, lo ms recomendable es
formar varios equipos. No hay una tcnica oficial para coordinar equipos
mltiples, pero se han documentado experiencias de hasta 800 miembros,
divididos en Scrums de Scrum, definiendo un equipo central que se encarga
de la coordinacin, las pruebas cruzadas y la rotacin de los miembros
(Schwaber y Beedle, op cit).
La figura 3 describe el ciclo de la metodologa Scrum:
Figura 3: Ciclo de la metodologa Scrum
Creacin
del
Concepto

Especific.
Requerim.

Diseo

Cdigo

Prueba de
Unidad

Prueba de
Integracin

Prueba del
Sistema

Pre-Juego

Prueba de
Aceptacin

Post-Juego
Juego

Planteamiento

Lista de
retraso
de
product
o

Producto
final,
documentos

Lista de
retraso
de
Srpint

Integracin,
prueba de
sistema

Sprint
Anlisis &
Diseo

Diseo de Alto
Nivel/Arquitectura

Codificacin

Prueba

Entrega

Release
Intermedi
o

16

Fuente (Schwaber y Beedle, op cit).

Otras Metodologas giles

Aunque los creadores e impulsores de las metodologas giles ms populares han
suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente,
cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos
ms especficos. A continuacin se resumen otras metodologas giles. La mayora
de ellas ya estaban siendo utilizadas con xito en proyectos reales pero les faltaba
una mayor difusin y reconocimiento.

Crystal Methodologies: Se trata de un conjunto de metodologas para el

desarrollo de software caracterizadas por estar centradas en las personas que
componen el equipo y la reduccin al mximo del nmero de artefactos
producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de
software se considera un juego cooperativo de invencin y comunicacin,
limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave,
por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas,
as como tener polticas de trabajo en equipo definidas. Estas polticas
dependern del tamao del equipo, establecindose una clasificacin por
colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50
miembros) (Cockbun, 2001).

Dynamic Systems Development Method (DSDM): Define el marco para

desarrollar un proceso de produccin de software. Nace en 1994 con el
objetivo

de

crear

una

metodologa

RAD

unificada.

Sus

principales

caractersticas son: es un proceso iterativo e incremental y el equipo de

desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad,
estudio del negocio, modelado funcional, diseo y construccin, y finalmente
implementacin.

Las

tres

ltimas

son

iterativas,

adems

de

existir

realimentacin a todas las fases (Fowler, 2001).

Adaptive Software Development (ASD): Su impulsor es Jim Highsmith. Sus

principales

caractersticas son: iterativo, orientado a los componentes

17

software ms que a las tareas y tolerante a los cambios. El ciclo de vida que
propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje.
En la primera de ellas se inicia el proyecto y se planifican las caractersticas
del software; en la segunda desarrollan las caractersticas y finalmente en la
tercera se revisa su calidad, y se entrega al cliente. La revisin de los
componentes sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo (Highsmith y Orr, 2000).

Feature -Driven Development (FDD): Define un proceso iterativo que consta

de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las
fases de diseo e implementacin del sistema partiendo de una lista de
caractersticas que debe reunir el software. Sus impulsores son Jeff De Luca y
Peter Coad (Fowler y Beck, 1999)

Lean Development (LD): Definida por Bob Charettes a partir de su experiencia

en proyectos con la industria japonesa del automvil en los aos 80 y utilizada
en numerosos proyectos de telecomunicaciones en Europa. En LD, los
cambios se consideran riesgos, pero si se manejan adecuadamente se
pueden convertir en oportunidades que mejoren la productividad del cliente.
Su principal caracterstica es introducir un mecanismo para implementar
dichos cambios (Poppendieck, 2003).

Metodologas Tradicionales
Las

metodologas

tradicionales

(formales)

se

focalizan

en

documentacin,

planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.), a

continuacin se detalla RUP uno de los mtodos ms usados dentro de los mtodos
tradicionales.
La metodologa RUP es un proceso formal, Provee un acercamiento disciplinado
para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su
objetivo es asegurar la produccin de software de alta calidad que satisfaga los
requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue
desarrollado por Rational Software, y est integrado con toda la suite Rational de

18

herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la

organizacin que lo adopte. (Customizacin). Es guiado por casos de uso y centrado
en la arquitectura, y utiliza UML como lenguaje de notacin (Figueroa y Sols, op
cit). En la figura 4 podemos ver las fases de la metodologa RUP:
Figura 4: Rational Unified Process (RUP).

Fuente (Figueroa y Sols, op cit).

Fases: Las cuatro fases del ciclo de vida de la metodologa RUP son:

Concepcin

Elaboracin

Construccin

Transicin

Ventajas de la metodologa RUP:

Evaluacin en cada fase que permite cambios de objetivos

Funciona bien en proyectos de innovacin.

Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de

desarrollar el software.

Seguimiento detallado en cada una de las fases.

19

Desventajas de la metodologa RUP:

La evaluacin de riesgos es compleja

Excesiva flexibilidad para algunos proyectos

Estamos poniendo a nuestro cliente en una situacin que puede ser muy
incmoda para l.

Nuestro cliente deber ser capaz de describir y entender a un gran nivel de

detalle para poder acordar un alcance del proyecto con l (Figueroa y Sols,
op cit).

Codificar y corregir (Code-and-Fix)

Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene
dos pasos:

Escribir cdigo.

Corregir problemas en el cdigo.

Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos,

diseo, validacin, y mantenimiento.
Este modelo tiene tres problemas principales:

Despus de un nmero de correcciones, el cdigo puede tener una muy mala

estructura, hace que los arreglos sean muy costosos.

Frecuentemente, an el software bien diseado, no se ajusta a las

necesidades del usuario, por lo que es rechazado o su reconstruccin es muy
cara.

El cdigo es difcil de reparar por su pobre preparacin para probar y modificar

(Boehm, 2002).

20

Microsoft Solution Framework (MSF)

Esta es una metodologa flexible e interrelacionada con una serie de conceptos,
modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin
de proyectos tecnolgicos.
MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano
las elecciones tecnolgicas, como se muestra en la figura 5.
Figura 5: Partes que componen la Metodologa MSF.

Fuente (Microsoft, 2004)

MSF tiene las siguientes caractersticas:

Adaptable: es parecido a un comps, usado en cualquier parte como un mapa,

del cual su uso es limitado a un especfico lugar.

Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as

como tambin, proyectos que requieren 50 personas a ms.

21

Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones

basadas sobre cualquier tecnologa.

MSF se compone de varios modelos encargados de planificar las diferentes partes

implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y finalmente el modelo de Aplicacin (Microsoft, op cit)
Modelo en cascada
El primer modelo de desarrollo de software que se public se deriv de otros
procesos de ingeniera. ste toma las actividades fundamentales del proceso de
especificacin, desarrollo, validacin y evolucin y las representa como fases
separadas del proceso.
El modelo en cascada consta de las siguientes fases:

Definicin de los requisitos: Los servicios, restricciones y objetivos son

establecidos con los usuarios del sistema. Se busca hacer esta definicin en
detalle.

Diseo de software: Se particiona el sistema en sistemas de software o

hardware. Se establece la arquitectura total del sistema. Se identifican y
describen las abstracciones y relaciones de los componentes del sistema.

Implementacin y pruebas unitarias: Construccin de los mdulos y unidades

de software. Se realizan pruebas de cada unidad.

Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban

en conjunto. Se entrega el conjunto probado al cliente.

Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es

puesto en marcha y se realiza la correccin de errores descubiertos. Se
realizan mejoras de implementacin. Se identifican nuevos requisitos

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte

de un sistema mayor el trabajo comienza estableciendo los requisitos de todos
22

los elementos del sistema y luego asignando algn subconjunto de estos

requisitos al software.

Anlisis de los requisitos del software: el proceso de recopilacin de los

requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el mbito de la informacin del
software, as como la funcin, el rendimiento y las interfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos distintos del

programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce
los requisitos en una representacin del software con la calidad requerida
antes de que comience la codificacin.

Codificacin: el diseo debe traducirse en una forma legible para la maquina.

El paso de codificacin realiza esta tarea. Si el diseo se realiza de una
manera detallada la codificacin puede realizarse mecnicamente.

Prueba: una vez que se ha generado el cdigo comienza la prueba del

programa. La prueba se centra en la lgica interna del software, y en las
funciones externas, realizando pruebas que aseguren que la entrada definida
produce los resultados que realmente se requieren.

Mantenimiento: el software sufrir cambios despus de que se entrega al

cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que
el software deba adaptarse a cambios del entorno externo (sistema operativo
o dispositivos perifricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento (Pressman, 1997).

Cada fase tiene como resultado documentos que deben ser aprobados por el
usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se
incluye la correccin de los problemas encontrados en fases previas.
En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin
entre las distintas fases de desarrollo. Algunos problemas que se observan en el
modelo de cascada son:

23

Las iteraciones son costosas e implican rehacer trabajo debido a la produccin

y aprobacin de documentos.

Aunque son pocas iteraciones, es normal congelar parte del desarrollo y

continuar con las siguientes fases.

Los problemas se dejan para su posterior resolucin, lo que lleva a que estos
sean ignorados o corregidos de una forma poco elegante.

Existe una alta probabilidad de que el software no cumpla con los requisitos
del usuario por el largo tiempo de entrega del producto.

Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es

difcil responder a cambios en los requisitos.

La interaccin entre fases del Modelo en Cascada puede observarse en la figura 6.

Figura 6: Iteraciones en el Modelo en Cascada
Ingeniera y Anlisis
del Sistema
Anlisis de los
Requisitos
Diseo
Codificacin
Prueba
Mantenimiento

Fuente (Bennington, 1956).

Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza
como parte de proyectos grandes.
Desarrollo evolutivo

24

La idea detrs de este modelo es el desarrollo de una implantacin del sistema

inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se
desarrolle el sistema adecuado.
Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario,
ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada
iteracin.
En la figura 7 se observa cmo las actividades concurrentes: especificacin,
desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar
al producto final.
Figura 7: Descripcin del Modelo de Desarrollo Evolutivo

Fuente (Pressman, op cit)

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario

los requisitos hasta llegar a un sistema final. El desarrollo comienza con las
partes que se tiene ms claras. El sistema evoluciona conforme se aaden
nuevas caractersticas propuestas por el usuario.

25

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario

y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no estn claros para el
usuario y se utiliza un prototipo para experimentar con ellos. El prototipo
ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente.

Los usuarios y desarrolladores logran un mejor entendimiento del sistema.

Esto se refleja en una mejora de la calidad del software.

Es ms efectivo que el modelo de cascada, ya que cumple con las

necesidades inmediatas del cliente.

Desde una perspectiva de ingeniera y administracin se identifican los siguientes

problemas:

Proceso no Visible: Los administradores necesitan entregas para medir el

progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir
documentos que reflejen cada versin del sistema.

Sistemas pobremente estructurados: Los cambios continuos pueden ser

perjudiciales

para

la

estructura

del

software

haciendo

costoso

el

mantenimiento.

Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan

herramientas que pueden ser incompatibles con otras o que poca gente sabe
utilizar (Pressman, op cit).

Desarrollo incremental
Mills sugiri el enfoque incremental de desarrollo como una forma de reducir la
repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la
toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es
una combinacin del Modelo de Cascada y Modelo Evolutivo.

26

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para

retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es
dudoso, evolutivo (Mills y ONeill, 1980).
En la figura 8 podemos observar el flujo general del Modelo de Desarrollo Iterativo
Incremental.
Figura 8: Flujo General del Modelo de Desarrollo Iterativo Incremental

Fuente (Mills y ONeill, op cit).

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
Pueden empezar a usarlo desde el primer incremento.

Los clientes pueden aclarar los requisitos que no tengan claros conforme ven
las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede

distribuir en cada incremento.

Las partes ms importantes del sistema son entregadas primero, por lo cual
se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

27

Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000
lneas).

Cada incremento debe aumentar la funcionalidad.

Es difcil establecer las correspondencias de los requisitos contra los

incrementos.

Es difcil detectar las unidades o servicios genricos para todo el sistema.

Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los ms conocidos y fue
propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar
de una serie de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones
del proceso y del producto. Se realiza un diseo detallado del plan
administrativo. Se identifican los riesgos y se elaboran estrategias alternativas
dependiendo de estos.
2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada
riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de
requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la
evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales,
evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente
fase del proyecto.
Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo,
esta es una actividad importante en la administracin del proyecto.
El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones
se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos

28

contra las alternativas. Se evalan los riesgos con actividades como anlisis
detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica
la siguiente fase (Boehm, 1988).

La figura 9 muestra el flujo del Modelo de Desarrollo en Espiral:

Figura 9: Flujo del Modelo de desarrollo en Espiral

Fuente (Boehm, op cit).

Cuadro 2: Diferencias entre metodologas tradicionales y giles:

Metodologas Tradicionales
Basados en normas provenientes de
estndares seguidos por el entorno de
desarrollo. Cierta resistencia a los cambios
Impuestas externamente. Proceso mucho

Metodologas giles
Basada en heursticas provenientes de
prcticas de produccin de cdigo.
Especialmente preparadas para cambios
durante el proyecto.
Impuestas internamente (por el propio

29

ms controlado, con numerosas

polticas/normas.
El cliente interacta con el equipo de
desarrollo mediante reuniones. Ms
artefactos.
Ms roles. Grupos grandes y posiblemente
distribuidos.
La arquitectura del software esencial y se
expresa mediante modelos. Existe un
contrato prefijado.

equipo). Proceso menos controlado, con

pocos principios.
El cliente es parte del equipo de desarrollo.
Pocos artefactos.
Pocos roles. Grupos pequeos (<10
integrantes) y trabajando en el mismo sitio.
Menos nfasis en la arquitectura del
software. No existe contrato tradicional o es
bastante flexible.

Fuente (Boehm, op cit).

De acuerdo con el cuadro 2 se puede observar que las metodologas de desarrollo

giles son ms orientadas a procesos de desarrollo de software de pocas semanas
de desarrollo y con bajos niveles de formalizacin requeridos. A continuacin se
describen con mayor nivel de especificacin las principales semejanzas y diferencias
de las metodologas giles y las tradicionales:

Prcticas de desarrollo: En las metodologas de desarrollo gil se procura

realizar los procesos de software de acuerdo a las prcticas que le han dado
resultados al grupo. En las tradicionales se desarrolla de acuerdo a las
normas sugeridas por los estndares de desarrollo.

Adaptacin al cambio: En las metodologas giles por la misma capacidad de

reaccin son ms adaptables a los cambios por el contrario las tradicionales
por el nivel de formalidad en la fase de requerimientos son ms resistentes al
cambio.

Control: Por su capacidad de adaptacin el proceso se hace menos controlado

que en las metodologas tradicionales que ejercen mayor control en el proceso
por su nivel de formalizacin.

Documentacin: En las metodologas giles no se hace nfasis en la

documentacin ni en los artefactos a diferencia de las metodologas
tradicionales.

Equipo de trabajo: En las metodologas giles existen bajo nmero de

participantes y roles, por el contrario las metodologas tradicionales sugieren
los roles que proporcionan las normas.

30

En el cuadro 3 se hace una comparativa entre cada una de las etapas ms comunes
en el desarrollo de software y los enfoques que hay entre las metodologas
tradicionales y giles.

Cuadro 3: Diferencias por etapas y enfoque metodolgico:

Modelos Rigurosos

Etapa
Anlisis de requerimientos

Planificacin predictiva y
aislada
Diseo flexible y extensible +
modelos + documentacin
exhaustiva
Desarrollo individual con
roles y responsabilidades
estrictas
Actividades de control:
orientado a los hitos +
gestin miniproyectos

Modelos giles
Planificacin adaptativa:
entregas frecuentes +
colaboracin del cliente
Diseo simple: documentacin
mnima + focalizado en la
comunicacin
Transferencia de
conocimiento: programacin
en pares + conocimiento
colectivo
Liderazgo-colaboracin:
empoderamiento + autoorganizacin

Planificacin
Diseo

Codificacin
Pruebas
Puesta en produccin

Fuente (Boehm, op cit).

Las metodologas tradicionales no se adaptan a las nuevas necesidades o

expectativas que tienen los usuarios hoy en da, en parte que los mtodos usados no
son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos
cambios

generalmente

implican

altos

costos,

demanda

de

tiempo

la

reestructuracin total del proyecto que se est llevando; en contraparte, los mtodos
giles permiten un desarrollo iterativo y adaptable que permite la integracin de
nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el
cliente como el desarrollador queden satisfechos porque el producto final tiene una
calidad adecuada.
Un proceso es gil cuando el desarrollo de software es:

31

Incremental. Entregas pequeas de software, con ciclos rpidos.

Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con

una cercana comunicacin.

Sencillo. El mtodo en s mismo es simple, fcil de aprender y modificar.

Est bien documentado y es adaptable. Permite realizar cambios de ltimo

momento).

Sus elementos claves son:

Poca documentacin

Simplicidad

Anlisis como una actividad constante

Diseo evolutivo

Integraciones

Pruebas diarias (Cans, Letelier, 2006).

Cuando Usar Metodologas giles

No existe una metodologa universal para hacer frente con xito a cualquier proyecto
de desarrollo de software. Toda metodologa debe ser adaptada al contexto del
proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema).
Histricamente, las metodologas tradicionales han intentado abordar la mayor
cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable
para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy
cambiantes.
Las metodologas giles ofrecen una solucin casi adecuada para una gran cantidad
de proyectos. Sin embargo existen mtodos ms generales y con mejores resultados
que otros. Saber qu reglas y metodologas aplicar en cada caso es ms importante
y til que seguir ciegamente siempre las mismas.

32

Las propias prcticas de los mtodos giles limitan o descartan su uso en algunos
proyectos. A continuacin se detallan algunos casos donde no conviene usar
mtodos giles.

Aplicaciones distribuidas. Las pruebas unitarias son complicadas de aplicar

entre componentes. Sera necesario construir una arquitectura de pruebas
para probar directamente los componentes, que podra ser tan complicada
como el sistema que se desea construir.

Aplicaciones que requieren seguir un diseo estricto. Por ejemplo: sistemas

operativos, software de telecomunicaciones.

Aplicaciones que requieren una documentacin exhaustiva. Por ejemplo:

sistemas militares, mdicos o industriales.

Aplicaciones basadas fundamentalmente en interfaces grficas de usuario: No

es fcil aplicar pruebas unitarias a las interfaces grficas.

Aplicaciones con cdigo heredado. Habra que reescribir todo el cdigo

heredado siguiendo los principios giles.

Proyectos muy grandes. La comunicacin entre los miembros del equipo es

difcil de conseguir.

Aplicaciones donde la escalabilidad o la eficacia sean importantes. La

escalabilidad o la eficacia no son caractersticas que se pueden aadir durante
el proceso del desarrollo del software o que puedan obtenerse refactorizando:
deben considerarse desde un principio (Cans, Letelier, op cit).

Ventajas de las Metodologas giles

Las metodologas giles presentan diversas ventajas como:

Rpida respuesta a cambios de requisitos a lo largo del desarrollo.

Entrega continua y en plazos cortos de software funcional.

Trabajo conjunto entre el cliente y el equipo de desarrollo.

Minimiza los costos frente a cambios.

Importancia de la simplicidad, al eliminar el trabajo innecesario.

Atencin continua a la excelencia tcnica y al buen diseo.

33

Mejora continua de los procesos y el equipo de desarrollo.

Evita malentendidos de requerimientos entre el cliente y el equipo.

El equipo de desarrollo no malgasta el tiempo y dinero del cliente

desarrollando soluciones innecesariamente generales y complejas que en
realidad no son un requisito del cliente.

Cada componente del producto final ha sido probado y satisface los

requerimientos (Cans, Letelier, op cit).

Problemas Comunes de las Metodologas giles

Como en cualquiera otra metodologa, tambin hay desventajas y problemas que
surgen a la hora de implementarlas:

Falta de documentacin del diseo. El cdigo no puede tomarse como una

documentacin. En sistemas de tamao grande se necesitar leer los cientos o
miles de pginas del listado de cdigo fuente.

Problemas derivados de la comunicacin oral. Este tipo de comunicacin

resulta difcil de preservar cuando pasa el tiempo y est sujeta a muchas
ambigedades.

Falta de calidad. Probar el cdigo de forma constante no genera productos de

calidad, slo revela falta de anlisis y diseo.

Fuerte dependencia de las personas. Como se evita en lo posible la

documentacin y los diseos convencionales, los proyectos giles dependen
crticamente de las personas.

Falta de procesos de revisin del cdigo. Con mtodos como el PSP o TSP se
han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La
programacin en parejas tiene resultados del 20 al 40%, que no es mucho
frente al 10 y el 25% de un programador.

Falta de reusabilidad. La falta de documentacin hacen difcil que se pueda

reutilizar el cdigo gil.

34

Sobre costos y retrasos derivados de la refactorizacin continua. Para un

sistema de ciertas proporciones, los costos y retrasos derivados de la
refactorizacin no pueden despreciarse.

Restricciones en cuanto a tamao de los proyectos abordables.

Rigidez. Algunos mtodos giles son muy rgidos: deben cumplirse muchas
reglas de una forma estricta para garantizar el xito del proyecto. Por ejemplo
XP exige en realidad mucho esfuerzo, concentracin y orden.

Cambios. Los modelos de datos son pesados y no pueden cambiarse as

como as solo porque el cliente que ira a incorporar ms funciones al sistema.

Problemas derivados del fracaso de los proyectos giles. Si un proyecto gil

fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el
diseo. La comprensin del sistema se queda en las mentes de los
desarrolladores (Cans, Letelier, op cit).

35

JUSTIFICACIN
La metodologa que actualmente usa la empresa le ha dado buenos resultados, pero
se usa de manera muy estricta a todos los proyectos. Aunque hay algunos grupos
que ya han adoptado practicas de metodologas giles, adems, requiere de un gran
nmero de formatos y documentos que deben ser llenados, documentados y
aprobados por muchos niveles, esto ha hecho que en algunos proyectos la respuesta
al cambio sea lenta, y requiera de bastante tiempo para que un cambio pueda ser
aprobado. Tambin, es cada vez ms comn un atraso significativo en las fases de
desarrollo.
Las metodologas giles proponen una solucin ligera al problema del exceso de
pasos para llevar a cabo una tarea, aunque se ha denominado que es aplicable por
lo regular para equipos pequeos, esta se puede llevar a la prctica sin problema en
desarrollo de sistemas grandes

36

OBJETIVO
Describir el uso de metodologas giles en una empresa de desarrollo de software en
Ciudad Jurez, Chihuahua.

37

METODOLOGA

1. Lugar y Tiempo
El trabajo se llev a cabo entre los meses de enero y abril de 2009 en una
empresa de desarrollo de software de Ciudad Jurez.
2. Carcter
La investigacin fue de carcter no experimental ya que no se manipul la
variable.
3. Diseo
El diseo de la investigacin fue de tipo transeccional descriptivo, ya que la
recoleccin de los datos se realiz en un momento nico en el tiempo y se incluy
una sola variable.
4. Poblacin de Inters
Todos los equipos de desarrollo que pertenezcan a la empresa de desarrollo de
software en Ciudad Jurez.
5. Unidad de anlisis.
La unidad de anlisis estuvo orientada hacia aquellos equipos de desarrollo de la
empresa que sean proyectos manejados (con gerencia) y estn usando mtricas
en sus entregas.
6. Variable
La variable que se midi en el proceso fue el uso de metodologas giles en el
proceso de desarrollo de software.

38

7. Indicadores
Variable: Uso de las metodologas giles.
Indicadores: Tiempo de Respuesta al cliente; Resultados de la revisin de
producto; Resultados de los mtricas de calidad.
8. Recoleccin de datos
El instrumento que se utilizo para la recoleccin de datos fue un cuestionario que
se realiz al gerente del rea de desarrollo de software relacionada, as como al
personal de cada uno de los equipos de desarrollo. Dicho cuestionario se agrega
como anexo 1.
9. Anlisis de la informacin
La informacin obtenida en la entrevista se comparo con la obtenida en
cuestionarios y de esta manera se determin el uso de

la metodologa gil

dentro de la empresa. La informacin se presenta en forma de grficas y

diagramas de proceso los cuales proporciono la empresa para mejor
comprensin de los procesos que llevan a cabo los empleados que desarrollan
software.
10. Interpretacin de resultados
Se realiz una redaccin explicativa de cmo se lleva a cabo el proceso de
desarrollo de software. Se presentaron graficas y diagramas de proceso que
muestran los porcentajes de uso de las metodologas giles dentro de la
empresa, el conocimiento que los empleados tienen al respecto y tambin los
procesos que el personal lleva a cabo durante el desarrollo de software.

39

RESULTADOS
Se realiz un cuestionario al personal de la empresa de desarrollo de software en
Ciudad Jurez, el cual est dividido en tres secciones, que son, preguntas sobre los
participantes, preguntas sobre la organizacin y preguntas sobre la transicin e
implementacin de las metodologas giles. Las primeras 4 grficas del cuestionario
son acerca del acercamiento que los encuestados han tenido hacia las metodologas
giles, las grficas 5, 6, 7, 8 y 9 son acerca de la organizacin donde labora el
personal encuestado, y las ltimas 5 (10, 11, 12 ,13 y 14) son acerca de la transicin
e implementacin de las metodologas giles en la organizacin.
En las primeras 4 grficas podemos ver que el personal ha participado muy poco en
este tipo de encuestas, han usado muy poco las metodologas giles aun cuando la
mayora de los encuestados son desarrolladores de software.
En las grficas 5, 6, 7, 8 y 9 podemos ver que el personal labora en grupos de
tamao medio, considerando un mximo 20 personas, el personal tiene poco
conocimiento acerca de quienes usan metodologas giles dentro de la empresa, as
mismo de la cantidad de proyectos que se estn usando bajo el esquema de
metodologas giles. La mayor parte del personal desconoce por cuanto tiempo han
usado metodologas giles en esta empresa, adems no tienen la certeza de cuantas
localidades de la empresa utilizan metodologas giles.
En las ltimas 5 grficas (10, 11, 12, 13 y 14) podemos ver que el personal desea el
cambio a las metodologas giles entre otras cosas para mejorar, calidad,
productividad y el proceso de mantenimiento del software. Las principales barreras
que el personal ve para la implementacin de una metodologa gil son la falta de
experiencia y la cultura organizacional. A pesar de este desconocimiento el personal
piensa que un alto porcentaje de proyectos usando estas metodologas es exitoso y
ha ayudado a reducir los defectos en el desarrollo de software y al incremento de la
productividad

40

Nivel de participacin: en esta grfica podemos ver el nivel de participacin en

encuestas anteriores del personal de la empresa de desarrollo de software de Ciudad
Jurez acerca del desarrollo de software usando metodologas giles.

Grfica 1: Nivel de participacin

41

En este cuadro podemos ver los roles que desempea el personal encuestado en la
empresa de desarrollo de software de Ciudad Jurez. Esta pregunta no se
representa con grfica de pastel ya que los encuestados podan contestar ms de
una opcin (o todas si as aplicaba su caso) por lo que se representa con una grfica
en barras y porcentajes.

Grfica 2: Roles desempeados por los encuestados

42

Nivel de conocimiento/participacin del personal encuestado de la empresa de

desarrollo de software de Ciudad Jurez sobre metodologas giles.

Grfica 3: Nivel de Conocimiento/Participacin

43

Tiempo que el personal de la empresa de desarrollo de software de Ciudad Jurez

ha usado las metodologas giles sin importar si ha sido por razones laborales o
personales.

Grfica 4: Tiempo de uso de Metodologas giles

44

Tamao del rea o grupo donde el personal encuestado labora.

Grfica 5: Tamao del rea de trabajo

45

Conocimiento sobre la distribucin del personal que usa metodologas giles en la

empresa de desarrollo de software de Ciudad Jurez.

Grfica 6: Conocimientos sobre la empresa

46

Porcentaje de proyectos que se desarrollan en la empresa de desarrollo de software

de Ciudad Jurez usando metodologas de desarrollo giles.

Grfica 7: Porcentaje de proyectos con metodologas giles

47

Tiempo durante el cual la empresa de desarrollo de software de Ciudad Jurez ha

estado haciendo uso de metodologas giles para el desarrollo de software.

Grfica 8: Tiempo de uso de Metodologas giles por la empresa

48

Nmero de localidades de la compaa que estn haciendo uso de las metodologas

giles para el desarrollo de software.

Grfica 9: Localidades que usan Metodologas giles

49

Principales razones para adoptar el uso de metodologas giles para el desarrollo de

software en la empresa de desarrollo de software de Ciudad Jurez. Esta pregunta
se representa en grafica de barras y porcentajes ya que el personal encuestado
poda responder ms de una opcin (o todas si aplicaba el caso).

Grfica 10: Razones para adoptar Metodologas giles

50

Metodologas giles para el desarrollo de software que ms conoce el personal

encuestado en la empresa de desarrollo de software de Ciudad Jurez.

Grfica 11: Metodologas giles ms conocidas

51

Barreras/obstculos que enfrenta el personal de la empresa de desarrollo de

software de Ciudad Jurez para adoptar en un futuro las metodologas giles para el
desarrollo de software. Esta pregunta no se representa con una grafica de pastel ya
que el personal encuestado poda responder ms de una opcin (o todas si aplicaba
en su caso) por lo que se representa con barras y porcentajes.

Grfica 12: Barreras para adoptar las Metodologas giles

52

Porcentaje de proyectos que el personal encuestado considera que han sido exitosos
usando metodologas giles en la empresa de desarrollo de software de Ciudad
Jurez.

Grfica 13: Porcentaje de proyectos exitosos usando Metodologas giles

53

Estimacin en porcentaje sobre cules son los beneficios que se han obtenido en la
organizacin con el uso de metodologas giles en la empresa de desarrollo de
software de Ciudad Jurez. En este recuadro se toman en cuenta los porcentajes de
aquellos encuestados que respondieron esta pregunta, los que no respondieron
fueron excluidos.

Grfica 14: Estimacin de beneficios obtenidos

Beneficio
Incremento en productividad
Mejora en tiempos de entrega
Reduccin de defectos en el software
Reduccin de costos

Porcentaje estimado
42%
36%
52%
28%

54

CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
El uso de una metodologa gil permite a la empresa de desarrollo de software de
Ciudad Jurez desarrollar software de manera ms rpida y segura, y a la vez
reducir el costo de desarrollo.
Existe el conocimiento bsico sobre metodologas giles de desarrollo de software
an cuando no se ha identificado una metodologa en particular. La empresa tiene
implementado un mtodo que facilita atender las necesidades inmediatas de clientes
demandantes de cambios en sus sistemas.
RECOMENDACIONES
Aunque la empresa cuenta con experiencia en el desarrollo de software utilizando
una metodologa gil, el personal tiene poco conocimiento de esto y no identifica a
ciencia cierta la metodologa utilizada, se recomienda lo siguiente:
1. Identificar la metodologa utilizada e informar al personal de la empresa cual
es la metodologa as como los pasos y procesos que esta implica.
2. Capacitar al personal de desarrollo que forma parte de los dos equipos que
utilizan metodologa gil en el desarrollo de software para que tengan mejor
conocimiento del tema, eso permitir madurar el proceso de desarrollo
mediante metodologas giles.
3. Definir adecuadamente los roles que se requieren en el modelo seleccionado
4. Dar mayor importancia al desarrollo de software por medio del uso de una
metodologa gil y formalizar su uso.

55

LITERATURA CITADA
Abrahamsson, P., Ronkainen, J. 2002. Agile software development methods
Review and analysis.. VTT Publications.
Beck, K. 1999. Extreme programming explained: Embrace Change. Reading, Mass.,
Addison-Wesley.
Boehm, B. 2002. Get Ready For the Agile Methods, With Care. Computer.
Boehm, B. 1988. A Spiral Model of Software Development and Enhancement.
Bennington, B. 1956. Agile Requirements Methods.
http://www.therationaledge.com/content/agilerequirements.
Cans, J., Letelier, P. 2006. Metodologas giles para el Desarrollo de Softaware.
Universidad Politcnica de Valencia.
http://www.willydev.net/descargas/prev/TodoAgil.pdf
Cockburn, A. 2001. Agile Software Development.. Addison-Wesley.
Cockburn, A. 2001. Agile software development: the people factor, Computer,
November 2001, IEEE.
Figueroa, G., Solis, C. 2008. Metodologas Tradicionales vs. Metodologas giles.
Universidad Tcnica Particular de Loja
Fowler, M. 2001. Planning Extreme Programming, Addison-Wesley Professional, 1st
edition.
Fowler, M., Beck, K. 1999. Refactoring: Improving the Design of Existing Code..
Addison-Wesley.
Highsmith, J. 2002. Agile software development ecosystems, Addison-Wesley,
Boston.
Highsmith, J., Orr, K. 2000. Adaptive Software Development: A Collaborative
Approach to Managing Complex Systems. Dorset House.
Microsoft, 2004. Microsoft Solution Framewordk Ver. 3.0.
http://www.microsoft.com/DownLoads/details.aspx?FamilyID=a71ac8961d28-45a4-880c-8b0cc8265c63&displaylang=en
Mills, H., ONeill, D. 1980. The Management of Software Engineering, IBM Systems
Pires, Donald. 2001. Manifiesto gil, Uniersidad de California en Los ngeles UCLA,
(en lnea), disponible en http://www.manifiestoagile.com
56

Poppendieck M., Poppendieck T. 2003. Lean Software Development: An Agile

Toolkit for Software Development Managers. Addison Wesley.
Pressman, R. 1997. Software Engineering - A Practitioner's Approach, McGraw Hill.
Reynoso C. 2005. Mtodos giles en el desarrollo de software.
http://www.microsoft.com/spanish/msdn/latam/mediacenter/webcast/architect.a
spx (15 Nov 2005)
Schwaber K., Beedle M. 2001. Agile Software Development with SCRUM.. Prentice
Hall.
Takeuchi, H., Nanoka, I. 1986. The new product development game. Harvard
Business Review Jan/Feb.
The Standish Group. 2001. Fallas en los desarrollos de Sistemas de IT.
Waters, K. 2007. How do you eat an elephant?
http://www.agilealliance.org/article/articles_by_category/5 (25 Marzo
2007).
Wells, D. 2003. Proceedings of Extreme Programming and Agile Methods XP/Agile
Universe.

57

ANEXOS
Anexo 1: Cuestionario aplicado al personal y gerentes de JPMorgan Chase.
La siguiente encuesta tiene como objetivo determinar en nivel de uso de las
metodologas giles para el desarrollo de software dentro de la empresa. A
continuacin se describe brevemente las metodologas giles as como las
tradicionales.
Las metodologas tradicionales concentran su atencin en llevar una documentacin
exhaustiva de todo proyecto y centran su atencin en cumplir en un plan de proyecto,
definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las
caractersticas importantes dentro de este enfoque tenemos los altos costos al
implementar y al no ofrecer una buena solucin para proyectos donde el entorno es
voltil. Las metodologas tradicionales o formales se enfocan en documentacin,
planificacin y procesos (plantillas tcnicas de administracin, revisiones, etc.)
Las metodologas tradicionales presentan ciertos problemas tales como:
Fases de obtencin de requerimientos, anlisis y diseo muy costosas en cuanto a
tiempo y recursos.
Muchos niveles de aprobacin, lo cual lleva comnmente al retraso en las fechas
de entrega.
Una vez que se llega a la fase de desarrollo es muy difcil para el equipo el
entender un sistema tan complejo al ser tan amplia el rea que se abarca.
En el otro lado estn las metodologas giles, las cuales se han incorporado muy
bien a un mundo de requerimientos cambiantes, y estas nos muestran ciertas
ventajas sobre los mtodos tradicionales, tales como:
Buena respuesta a los cambios durante la fase de desarrollo, lo cual es cada vez
ms comn en los proyectos.
Entrega continua y rpida de secciones funcionales del sistema.
Involucramiento del cliente.
Eliminacin del trabajo innecesario.
58

 Mayor atencin a la parte tcnica y de diseo.

Mejora continua de los procesos y equipos de desarrollo
Las metodologas agiles presentan un nuevo enfoque que nace como respuesta a los
problemas de las metodologas tradicionales y se basa en aspectos puntuales, el
retrasar las decisiones y la planificacin adaptativa; permitiendo potencia an ms en
el desarrollo de software a gran escala. El resultado es un Manifiesto gil cuyas
principales ideas son:
Los individuos y las iteraciones entre ellos son ms importantes que las
herramientas y los procesos empelados.
Es ms importante crear un producto de software que funcione que escribir
documentacin exhaustiva.
La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos.
Por favor lea cuidadosamente las siguientes preguntas y responda subrayando la(s)
respuesta(s) convenientes en cada pregunta(s), en alguna de ellas es posible
seleccionar ms de una respuesta. En caso de responder este cuestionario por
medio de archivo electrnico favor de marcar en negrita las respuestas.
Nombre:
Correo Electrnico:

Empresa:

Preguntas sobre los participantes

Has tomado parte antes en una encuesta sobre metodologas de desarrollo?
a)
b)
c)
d)

Si
Primera vez
No
No recuerdo

59

2 Cul de los siguientes roles describe mejor tu actual posicin en la compaa?

-

Administrador de proyectos
Desarrollador/programador
Jefe de desarrollo
Consultor
Arquitecto de software
QA/pruebas/tester
IT Staff/soporte

3 Cul de las siguientes situaciones describe mejor tu nivel actual de

conocimiento/participacin en Metodologas giles?
-

Lder de equipo de desarrollo que usa metodologas giles

Formo parte de un equipo de desarrollo que hace uso de metodologas giles
Estoy considerando introducir metodologas giles en mi actual equipo
He formado parte de equipos de trabajo que hacen uso de metodologas

giles
He escuchado acerca de las metodologas giles, conozco muy poco al
respecto

4 Por cunto tiempo has hecho uso personalmente de las metodologas giles sin
importar si en el orden personal o laboral?
a)
b)
c)
d)
e)
f)

Nunca
6 meses
Hasta 1 ao
Entre 1 y 2 aos
Entre 2 y 5 aos
Ms de 5 aos

Preguntas sobre la organizacin

5 Qu tan grande es la empresa de software a la que perteneces? Incluyendo
personal relacionado en cualquier aspecto al desarrollo de software.
a) <5 personas
b) Entre 5 y 20 personas

60

c) Entre 21 y 50 personas
d) Ms de 50 personas

6 Actualmente la empresa tiene personal distribuido (que forma parte de los

equipos de desarrollo que usan metodologas giles) en localidades diferentes?
a) Si
b) No

7 Qu porcentaje de los proyectos de tu empresa se desarrollan haciendo uso de

metodologas giles?
a)
b)
c)
d)
e)

<20%
Entre 20 y 40%
Entre 40 y 60%
Entre 60 y 80%
Entre 80 y 100%

8 Por cunto tiempo tu empresa ha estado haciendo uso de metodologas giles en

sus proyectos?
a)
b)
c)
d)
e)
f)

Nunca
6 meses
Hasta 1 ao
Entre 1 y 2 aos
Entre 2 y 5 aos
Ms de 5 aos

9 Cuntas localidades distintas estn haciendo uso de metodologas giles en la

compaa?
a)
b)
c)
d)
e)

1
2
3
Ms de 3
Desconozco

Preguntas sobre la transicin e implementacin

61

10 Cul es la principal razn para adoptar metodologas giles dentro de la

empresa? En esta pregunta puedes seleccionar ms de una opcin.
-

Mejorar la habilidad en el manejo de cambios

Incrementar productividad
Mejorar calidad en el software
Mejorar la relacin entre TI y negocios
Reducir riesgos de negocio
Mejorar o aumentar la disciplina de desarrollo
Mejorar el proceso de mantenimiento y cambios de software
Mejorar el quipo de trabajo

11 Qu metodologas giles conoces mas? En esta pregunta puedes seleccionar

ms de una opcin.
a)
b)
c)
d)

Scrum
XP
RUP
Otras: Cules?

12 Cules son las barreras/obstculos para adoptar en un futuro las metodologas

giles en tu actual organizacin? En esta pregunta puedes seleccionar ms de una
opcin.
-

Cultura organizacional
Resistencia al cambio en la organizacin
Falta de experiencia con metodologas giles entre el personal
Apoyo de los niveles ms altos de la organizacin
Proyectos demasiado complejos
Falta de colaboracin por parte de los clientes
Desconfianza en los resultados de las metodologas giles
Tiempo de transicin muy largo
Limitantes en presupuestos financieros

13 Qu porcentaje de proyectos desarrollados con metodologas giles has sido

exitosos en su organizacin?
a) < 10%
62

b)
c)
d)
e)
f)

Entre 10 y 30%
Entre 30 y 60%
Entre 60 y 90%
Cercano al 100%
100%

14 Por favor intente estimar cuales son los beneficios que ha obtenido la
organizacin con el uso de metodologas giles (responder todos los incisos).
Beneficio
Incremento en productividad
Mejora en tiempos de entrega
Reduccin de defectos en el software
Reduccin de costos

Porcentaje estimado

Anexo 2: Planeacin de actividades para los equipos de desarrollo que usan

metodologa gil.

63

Anexo 3: Flujo del proceso de control de cambios para los equipos que trabajan
usando la metodologa gil de desarrollo.

64

Anexo 4: Flujo del proceso de desarrollo de sistemas para los equipos que utilizan
metodologas giles.

65

Anexo 5: Flujo del Proceso de Pruebas.

66

Anexo 6: Flujo del Anlisis y Diseo de sistemas

67

68