Metodologias Desarrollo Software

Maida, Esteban Gabriel ; Pacienzia, Julin
Metodologas de desarrollo de software
Tesis de Licenciatura en Sistemas y Computacin

Facultad de Qumica e Ingeniera Fray Rogelio Bacon
Este documento est disponible en la Biblioteca Digital de la Universidad Catlica Argentina, repositorio institucional
desarrollado por la Biblioteca Central San Benito Abad. Su objetivo es difundir y preservar la produccin intelectual
de la Institucin.
La Biblioteca posee la autorizacin del autor para su divulgacin en lnea.
Cmo citar el documento:
Maida, EG, Pacienzia, J. Metodologas de desarrollo de software [en lnea]. Tesis de Licenciatura en Sistemas y
Computacin. Facultad de Qumica e Ingeniera Fray Rogelio Bacon. Universidad Catlica Argentina, 2015.
Disponible en: http://bibliotecadigital.uca.edu.ar/repositorio/tesis/metodologias-desarrollo-software.pdf [Fecha de
consulta:.........]
FACULTAD DE QUMICA E INGENIERIA FRAY ROGELIO BACON
PONTIFICIA UNIVERSIDAD CATLICA ARGENTINA SANTA MARIA DE LOS BUENOS AIRES
METODOLOGIAS DE
DESARROLLO DE
SOFTWARE
Tesis Final de Licenciatura en Sistemas y Computacin
Maida, Esteban Gabriel
Pacienzia, Julin
Diciembre 2015
Ctedra Seminario de Sistemas
Metodologas de Desarrollo de Software
Tesis Final Ctedra: Seminario de Sistemas
Carrera: Licenciatura en Sistemas y Computacin
______________________________________________________________________
2|P gin a
______________________________________________________________________
Agradecimientos y dedicatorias
La presente Tesis es un esfuerzo en el cual, directa o indirectamente, participaron varias

personas, leyendo, opinando, corrigiendo, tenindonos paciencia, dndonos nimo, acompandonos
en los momentos de crisis y en los momentos de felicidad.
Por estos motivos queremos agradecer a nuestras familias y a la gente que siempre apoyaron
nuestros proyectos y ambiciones.
A nuestros amigos y compaeros que hicieron de estos aos, los mejores de nuestras vidas.
A todos los profesores de nuestra carrera profesional porque han aportado su granito de arena
en nuestra formacin, dedicndonos todo el tiempo que fuera necesario para que hoy seamos personas
hechas y derechas, basndonos en la verdad, la justicia y la humildad.
3|P gin a
______________________________________________________________________
Resumen
En la actualidad la rapidez y el dinamismo en la industria del software han hecho replantear los
cimientos sobre los que se sustenta el desarrollo de software tradicional. Estudios recientes y el mismo
mercado actual est marcando la tendencia en la ingeniera del software teniendo como caractersticas
principales atender a las necesidades de rapidez, flexibilidad y variantes externas que hacen de nuestro
entorno una ventaja ms competitiva al aumentar la productividad y satisfacer las necesidades del
cliente en el menor tiempo posible para proporcionar mayor valor al negocio.
Ante esta situacin, el grado de adaptacin de las metodologas tradicionales a estos entornos de
trabajo no eran del todo eficientes y no cubran las necesidades del mercado actual.
En la actualidad existen una gran cantidad de metodologas para el desarrollo de software,
separadas en dos grandes grupos; las metodologas tradicionales o pesadas y las metodologas agiles.
Las metodologas tradicionales se basan en las buenas prcticas dentro de la ingeniera del
software, siguiendo un marco de disciplina estricto y un riguroso proceso de aplicacin.
Las metodologas agiles, en cambio, representan una solucin a los problemas que requieren una
respuesta rpida en un ambiente flexible y con cambios constantes, haciendo caso omiso de la
documentacin rigurosa y los mtodos formales.
El objetivo de esta investigacin es presentar e introducir sobre las existentes metodologas para el
desarrollo de software y los paradigmas que marcan la diferencia entre un mtodo estructurado y un
mtodo gil para as poder identificar cual se adapta de manera ms eficiente a un proyecto
determinado.
4|P gin a
______________________________________________________________________
INDICE
1. INTRODUCCION
1.1. DEFINICION DEL PROBLEMA

1.2. PROPOSITO DE LA INVESTIGACION
1.3. OBJETIVOS GENERALES
1.4. ALCANCES
1.5. LIMITACIONES
1.6. METODOLOGIAS
2. MARCO TEORICO
2.1. DEFINICION DE INGENIERIA

2.2. SOFTWARE
2.2.1. METODOLOGIA
2.2.2. IMPORTANCIA
2.2.3. PROBLEMAS
2.2.4. CARACTERISTICAS BASICAS
2.2.5. CLASIFICACION
2.3. QUE ES LA INGENIERIA DE SOFTWARE
2.4. QUE ES UNA METODOLOGIA Y PARA QUE SE UTILIZA
2.5. METODOLOGIA TRADICIONAL
2.6. METODOLOGIA AGIL
2.7. DIFERENCIAS ENTRE METODOLOGIA TRADICIONAL Y AGIL
2.8. PARADIGMAS DE LA INGENIERIA DE SOFTWARE
5|P gin a
______________________________________________________________________
3. INGENIERIA DE SOFTWARE
3.1. INTRODUCCION
3.2. OBJETIVOS
3.3. DISTRIBUCION DEL ESFUERZO EN UN PROYECTO DE SOFTWARE
3.4. ADMINISTRACION DE PROYECTOS DE SOFTWARE
3.4.1. INTRODUCCION
3.4.2. FACTORES DE LA ADMINISTRACION DE UN PROYECTO
3.4.3. SECUENCIA DE ACTIVIDADES DE ADMINISTRACION DE UN
PROYECTO
3.4.4. VALORES DEL CAPITAL HUMANO
3.4.5. ORGANIZACIN DE UN EQUIPO
3.5. RECURSOS
3.5.1. RECURSOS HUMANOS Y PARTICIPANTES
3.5.2. RECURSOS DE SOFTWARE
3.5.3. RECURSOS DE ENTORNO
3.6. CICLO DE VIDA DE UN PROYECTO DE SISTEMAS
3.6.1. RECOPILACION DE LOS REQUERIMIENTOS
3.6.2. ANLISIS
3.6.3. LIMITACIONES
3.6.4. ESPECIFICACIN
3.6.5. DISEO Y ARQUITECTURA
3.6.6. PROGRAMACIN
3.6.7. PRUEBAS DE SOFTWARE
3.6.8. IMPLEMENTACIN
3.6.9. DOCUMENTACIN
3.6.10. MANTENIMIENTO
6|P gin a
______________________________________________________________________
4. METODOLOGIAS CLASICAS
4.1. INTRODUCCION
4.2. VENTAJAS Y DESVENTAJAS
4.3. TIPOS DE METODOLOGIAS
4.3.1. WATERFALL (CASCADA)
4.3.2. PROTOTYPING
4.3.3. SPIRAL
4.3.4. INCREMENTAL
4.3.5. RAD
5. METODOLOGIAS AGILES
5.1. INTRODUCCION
5.2. BENEFICIOS
5.3.1. PROGRAMACION EXTREMA
5.3.2. SCRUM
5.3.3. CRYSTAL
5.3.4. KANBAN
5.3.5. FEATURE DRIVEN DEVELOPMENT (FDD)
5.3.6. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
5.3.7. LEAN DEVELOPMENT (LD) Y LEAN SOFTWARE DEVELOPMENT (LSD)
5.3.8. PROCESO UNIFICADO DE DESARROLLO SOFTWARE
6. ESTUDIO Y ANALISIS DE CASOS REALES
6.1. CASOS DE EXITO

6.2. CASOS DE FRACASO
7|P gin a
______________________________________________________________________
7. CONCLUSION
8. REFERENCIAS BIBLIOGRAFICAS
9. APENDICE
8|P gin a
______________________________________________________________________
1. INTRODUCCION
1.1. DEFINICION DEL PROBLEMA
Actualmente las metodologas de ingeniera de software pueden considerarse como una base
necesaria para la ejecucin de cualquier proyecto de desarrollo de software que se considere serio, y
que necesite sustentarse en algo ms que la experiencia y capacidades de sus programadores y equipo.
Estas metodologas son necesarias para poder realizar un proyecto profesional, tanto para poder
desarrollar efectiva y eficientemente el software, como para que sirvan de documentacin y se puedan
rendir cuentas de los resultados obtenidos.
Un amplio y buen conocimiento de estas metodologas servir de base terica y permitir
comprender completamente todo lo que requiere el anlisis, diseo, desarrollo e implantacin de un
sistema. Adems es importante, por la demanda que se tiene hoy en da por parte de muchas
empresas, el conocimiento de algunas metodologas de desarrollo de software en especfico.
Lo ms importante en una primera etapa es poder identificar qu metodologa de ingeniera de
software se adeca de la mejor manera a nuestro proyecto, para as lograr el mejor resultado en
tiempo y forma.
1.2. PROPOSITO DE LA INVESTIGACION
La presente tesis se orienta a realizar una contribucin en el rea de metodologa para el diseo,
desarrollo y evaluacin de software, necesarios para abordar proyectos con una metodologa diferente
a la estructurada.
1.3. OBJETIVOS GENERALES
La seleccin y aplicacin de una metodologa particular para el desarrollo de software, se centra

en el uso de un enfoque sistemtico de pasos y etapas a seguir para el cumplimiento de los objetivos
en comn.
El objetivo general de la puesta en prctica de una metodologa del software es construir un
producto de alta calidad de una manera oportuna. Dicha seleccin implica un conjunto de principios
fundamentales que se deben seguir y cumplir. Estos incluyen actividades explcitas para el
entendimiento del problema y la comunicacin con el cliente, mtodos definidos para representar un
diseo, mejores prcticas para la implementacin de la solucin y estrategias y tcticas slidas para
las pruebas.
9|P gin a
______________________________________________________________________
Para conseguir el objetivo de construir productos de alta calidad dentro de la planificacin, las
metodologas en general emplean una serie de prcticas para:
Entender el problema
Disear una solucin
Implementar la solucin correctamente
Probar la solucin
Gestionar las actividades anteriores para conseguir alta calidad
La utilizacin de la metodologa adecuada, representa un proceso formal que incorpora una serie
de mtodos bien definidos para el anlisis, diseo, implementacin y pruebas del software y sistemas.
Adems, abarca una amplia coleccin de mtodos y tcnicas de gestin de proyectos para el
aseguramiento de la calidad y la gestin de la configuracin del software.
1.4. ALCANCES
Se realiza una exposicin de los dos grandes grupos de metodologas, estructuradas y giles, en
toda su extensin, desde las primeras etapas del anlisis hasta la implementacin final del software y
su seguimiento. El alcance de la tesis trata de introducir al conocimiento de metodologas de trabajo
ms modernas de acuerdo a los desafos presentados en el mundo actual.
1.5. LIMITACIONES
Este trabajo permite la introduccin al conocimiento terico para comprender las fases y etapas
de las metodologas para el desarrollo de software existente. Tambin se tratarn algunos casos
prcticos en el captulo 6.
1.6. METODOLOGIAS
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas
propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Por una
parte tenemos aquellas propuestas ms tradicionales que se centran especialmente en el control del
proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben
producir, y las herramientas y notaciones que se usarn. Estas propuestas han demostrado ser
efectivas y necesarias en un gran nmero de proyectos, pero tambin han presentado problemas en
muchos otros. Una posible mejora es incluir en los procesos de desarrollo ms actividades, ms
artefactos y ms restricciones, basndose en los puntos dbiles detectados. Sin embargo, el resultado
final sera un proceso de desarrollo ms complejo que puede incluso limitar la propia habilidad del
equipo para llevar a cabo el proyecto. Otra aproximacin es centrarse en otras dimensiones, como por
10 | P g i n a
______________________________________________________________________
ejemplo el factor humano o el producto software. Esta es la filosofa de las metodologas giles, las
cuales dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del
software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en proyectos con
requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero
manteniendo una alta calidad. Las metodologas giles estn revolucionando la manera de producir
software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o
convencimiento no las ven como alternativa para las metodologas tradicionales.
Un objetivo claro ha sido encontrar procesos y metodologas, que sean sistemticas, predecibles
y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.
La evolucin de la disciplina de ingeniera del software ha trado consigo propuestas diferentes para
mejorar los resultados del proceso de construccin. Las metodologas tradicionales haciendo nfasis
en la planificacin y las metodologas giles haciendo nfasis en la adaptabilidad del proceso, delinean
las principales propuestas presentes.
En el prximo captulo trataremos algunos conceptos bsicos referidos al marco terico, tales
como, definicin de ingeniera, software, metodologas y paradigmas de la ingeniera. En el captulo 3
(tres) abordaremos temas relacionados especficamente a la ingeniera del software, como por
ejemplo, cules son los objetivos fundamentales, administracin de un proyecto, recursos y el ciclo de
vida. Continuaremos con el captulo n 4 (cuatro) donde explicaremos las metodologas clsicas, con
sus ventajas y desventajas, para luego proseguir con el siguiente captulo donde trataremos temas
exclusivos de las metodologas agiles. Posteriormente veremos estudios y anlisis de casos reales,
como casos de xitos, de fracasos y anlisis crticos. Finalmente sacaremos nuestras propias
conclusiones respecto a todo el trabajo realizado.
11 | P g i n a
______________________________________________________________________
2. MARCO TEORICO
2.1. DEFINICION DE INGENIERIA
La ingeniera es el conjunto de conocimientos y tcnicas, cientficas aplicadas al desarrollo,

implementacin, mantenimiento y perfeccionamiento de estructuras (tanto fsicas como tericas)
para la resolucin de problemas que afectan la actividad cotidiana de la sociedad.
La ingeniera es la actividad de transformar el conocimiento en algo prctico. (Autores varios).
2.2. SOFTWARE
El software es el equipamiento lgico e intangible de un sistema informtico, que comprende el

conjunto de los componentes lgicos necesarios que hacen posible la realizacin de tareas especficas,
en contraposicin a los componentes fsicos que son llamados hardware.
En otras palabras es el conjunto de los programas de cmputo, procedimientos, reglas,
documentacin y datos asociados, que forman parte de las operaciones de un sistema de
computacin. (Autores varios).
2.2.1. METODOLOGIA
Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar de forma
homognea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un
proceso de software detallado y completo. (Autores varios).
Las metodologas se basan en una combinacin de los modelos de proceso genricos. Definen
artefactos, roles y actividades, junto con prcticas y tcnicas recomendadas.
La metodologa para el desarrollo de software es un modo sistemtico de realizar, gestionar y
administrar un proyecto para llevarlo a cabo con altas posibilidades de xito. Una metodologa para el
desarrollo de software comprende los procesos a seguir sistemticamente para idear, implementar y
mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el
objetivo por el cual fue creado.
Si esto se aplica a la ingeniera del software, podemos destacar que una metodologa:
Optimiza el proceso y el producto software.
Mtodos que guan en la planificacin y en el desarrollo del software.
Define qu hacer, cmo y cundo durante todo el desarrollo y mantenimiento de un proyecto.
Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los
elementos que forman parte de una metodologa se pueden destacar:
Fases: tareas a realizar en cada fase o etapa.
Productos: E/S de cada fase, documentos.
12 | P g i n a
______________________________________________________________________
Procedimientos y herramientas: apoyo a la realizacin de cada tarea.

Criterios de evaluacin: del proceso y del producto. Saber si se han logrado los objetivos.
Una metodologa de desarrollo de software es un marco de trabajo que se usa para estructurar,
planificar y controlar el proceso de desarrollo de sistemas de informacin. Una gran variedad de estos
marcos de trabajo han evolucionado durante los aos, cada uno con sus propias fortalezas y
debilidades. Una metodologa de desarrollo de sistemas no tiene que ser necesariamente adecuada
para usarla en todos los proyectos. Cada una de las metodologas disponibles es ms adecuada para
tipos especficos de proyectos, basados en consideraciones tcnicas, organizacionales, de proyecto y
de equipo.
Una metodologa de desarrollo de software o metodologa de desarrollo de sistemas en ingeniera
de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de
desarrollo de un sistema de informacin.
El marco de trabajo de una metodologa de desarrollo de software consiste en:
Una filosofa de desarrollo de software, con el enfoque o enfoques del proceso de desarrollo
de software.
Mltiples herramientas, modelos y mtodos para ayudar en el proceso de desarrollo de
software.
Estos marcos de trabajo estn con frecuencia vinculados a algunos tipos de organizaciones, que se
encargan del desarrollo, soporte de uso y promocin de la metodologa. La metodologa con frecuencia
se documenta de alguna manera formal.
2.2.2. IMPORTANCIA DEL SOFTWARE
El software es ahora la clave del xito de muchas empresas y negocios, ya que sin l sera casi
imposible el mantenimiento y crecimiento de los mismos. Lo que diferencia una compaa de otra es
la suficiencia, exactitud y oportunidad de la informacin dada por el software.
El desarrollo de software se ha convertido en una industria con crecimiento vertical en los ltimos
aos. Hace un par de dcadas se sostena la teora de que los pases que posean los mejores recursos
naturales estaban destinados a ser los ms ricos y poderosos del mundo. Indudablemente los recursos
naturales tienen un papel importante en la economa de los pases, sin embargo poco a poco se fue
acuando una nueva ideologa que se sintetiza en lo siguiente: El que posee la informacin y el
conocimiento y hace mejor uso de l, es el que tiene el poder.
13 | P g i n a
______________________________________________________________________
2.2.3. PROBLEMAS DEL SOFTWARE
La planificacin y estimacin de costos frecuentemente son imprecisas.
Falta de productividad.
La calidad del software es a veces inaceptable.
Estos problemas al final crean insatisfaccin y falta de confianza de los clientes. Los problemas
anteriores son slo manifestacin de otras dificultades:
No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software.

Los proyectos de desarrollo de software se llevan a cabo con slo una vaga indicacin de los
requisitos del cliente.
La calidad del software es normalmente cuestionable.
El mantenimiento de software es muy costoso y no se le ha considerado un aspecto
importante.
Los problemas anteriores son solucionables, dndoles un enfoque de ingeniera al desarrollo de

software.
2.2.4. CARACTERISTICAS BASICAS
El software es un elemento del sistema que es lgico. Por tanto, el software tiene caractersticas
considerablemente distintas al hardware:
El software se desarrolla, no se fabrica en un sentido clsico.

El software no se desgasta con el tiempo.
La mayora de software se construye a medida, en vez de ensamblar componentes existentes.
Est creando en base a la lgica puramente.
14 | P g i n a
______________________________________________________________________
Figura N 1 Comparacin de ndices de fallas entre hardware y software.
2.2.5. CLASIFICACION
El software pude clasificarse en tres grandes grupos:

Software de sistema: Se llama Software de Sistema o Software de Base al conjunto de programas
que sirven para interactuar con el sistema, confiriendo control sobre el hardware, adems de dar
soporte a otros programas que administran los recursos y proporcionan una interfaz de uso.
El mejor ejemplo en este sentido son los populares sistemas operativos como Windows, Linux
o Mac OS. Este tipo de sistemas incluye entre otros:
Sistemas operativos
Controladores de dispositivos
Herramientas de diagnstico
Herramientas de Correccin y Optimizacin
Servidores de informacin
Programas utilitarios
Software de programacin: Es el conjunto de herramientas que permiten

al programador desarrollar programas informticos, usando diferentes alternativas y lenguajes de
programacin, de una manera prctica. Estos incluyen bsicamente:
Editores de texto
Compiladores
Intrpretes
Enlazadores
Depuradores
Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores herramientas, usualmente en
un entorno visual, de forma tal que el programador no necesite introducir
mltiples comandos para compilar, interpretar, depurar, etc. Habitualmente cuentan con una
avanzada interfaz grfica de usuario (GUI).
________________
Figura N 1 Extrada de [1]
15 | P g i n a
______________________________________________________________________
Software de aplicacin: son los programas diseados para o por los usuarios para facilitar la
realizacin de tareas especficas en la computadora, como pueden ser las aplicaciones ofimticas u
otros tipos de software especializados. Incluye entre muchos otros:
Aplicaciones para Control de sistemas y automatizacin industrial
Aplicaciones ofimticas (procesador de texto, hoja de clculo, programa de presentacin)
Software educativo
Software empresarial
Bases de datos
Telecomunicaciones (por ejemplo Internet y toda su estructura lgica)
Software mdico
Software de clculo numrico y simblico.
Software de diseo asistido (CAD)
Software de control numrico (CAM)
2.3. QUE ES LA INGENIERIA DE SOFTWARE
Haciendo una recopilacin de todos los conceptos que se han dado sobre la Ingeniera de software,
la podemos definir como la disciplina o rea de la informtica, que hace uso razonable de los principios
de ingeniera con el objetivo de obtener soluciones informticas econmicamente factible y que se
adapte a las necesidades de las empresas reales, tomando en cuenta los procesos de produccin y
mantenimiento de software que son desarrollados y modificados en el tiempo y con los costos
estimados.
Esta ingeniera trata con reas muy diversas de la informtica y de las Ciencias de la Computacin,
tales como construccin de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet,
abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Informacin
y aplicables a infinidad de reas (negocios, investigacin cientfica, medicina, produccin, logstica,
banca, etc.).
Algunas definiciones, dadas a travs del tiempo son:

Ingeniera de Software es el estudio de los principios y metodologas para el desarrollo y
mantenimiento de sistemas de software (Zelkovitz, 1978)
Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y
construccin de programas de computadora y a la documentacin asociada requerida para
desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o
Produccin de Software (Bohem, 1976).
Ingeniera de Software trata del establecimiento de los principios y mtodos de la ingeniera
a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales
(Bauer, 1972).
Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin
y mantenimiento del software; es decir, la aplicacin de la ingeniera al software (IEEE, 1993).
16 | P g i n a
______________________________________________________________________
En conclusin podemos decir que los cuatro autores anteriores, de manera diferente describen en
si el principal objetivo de la ingeniera de software, la cual es el establecimiento y puesta en prctica
de los principios y metodologas que nos lleven a un desarrollo eficiente de software en todas las
etapas desde sus inicios hasta su implementacin y mantenimiento.
2.4. QUE ES UNA METODOLOGIA Y PARA QUE SE UTILIZA
La metodologa hace referencia al conjunto de procedimientos racionales utilizados para alcanzar

un objetivo que requiera habilidades y conocimientos especficos.
La metodologa es una de las etapas especficas de un trabajo o proyecto que parte de una posicin
terica y conlleva a una seleccin de tcnicas concretas o mtodos acerca del procedimiento para el
cumplimiento de los objetivos. Es el conjunto de mtodos que se utilizan en una determinada actividad
con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cmo realizarlos para finalizar
una tarea.
2.5. METODOLOGIA TRADICIONAL
Desarrollar un buen software depende de un gran nmero de actividades y etapas, donde el

impacto de elegir la metodologa para un equipo en un determinado proyecto es trascendental para
el xito del producto.
Las metodologas tradicionales son denominadas, a veces, de forma despectiva, como
metodologas pesadas.
Centran su atencin en llevar una documentacin exhaustiva de todo el proyecto, la planificacin
y control del mismo, en especificaciones precisas de requisitos y modelado y en cumplir con un plan
de trabajo, definido todo esto, en la fase inicial del desarrollo del proyecto.
Estas metodologas tradicionales imponen una disciplina rigurosa de trabajo sobre el proceso de
desarrollo del software, con el fin de conseguir un software ms eficiente. Para ello, se hace nfasis en
la planificacin total de todo el trabajo a realizar y una vez que est todo detallado, comienza el ciclo
de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante
una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones para el modelado
y documentacin detallada. Adems, las metodologas tradicionales no se adaptan adecuadamente a
los cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde los
requisitos no pueden predecirse o bien pueden variar.
Otra de las caractersticas importantes dentro de este enfoque, son los altos costes al implementar
un cambio y la falta de flexibilidad en proyectos donde el entorno es voltil.
17 | P g i n a
______________________________________________________________________
2.6. METODOLOGIAS AGILES
Este enfoque nace como respuesta a los problemas que puedan ocasionar las metodologas
tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y la planificacin
adaptativa. Basan su fundamento en la adaptabilidad de los procesos de desarrollo.
Un modelo de desarrollo gil, generalmente es un proceso Incremental (entregas frecuentes con
ciclos rpidos), tambin Cooperativo (clientes y desarrolladores trabajan constantemente con una
comunicacin muy fina y constante), Sencillo (el mtodo es fcil de aprender y modificar para el
equipo) y finalmente Adaptativo (capaz de permitir cambios de ltimo momento). Las metodologas
giles proporcionan una serie de pautas y principios junto a tcnicas pragmticas que hacen que la
entrega del proyecto sea menos complicada y ms satisfactoria tanto para los clientes como para los
equipos de trabajo, evitando de esta manera los caminos burocrticos de las metodologas
tradicionales, generando poca documentacin y no haciendo uso de mtodos formales.
Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms
importante que el seguimiento estricto de un plan.
2.7. DIFERENCIAS ENTRE METODOLOGIA TRADICIONAL Y AGIL
En las metodologas tradicionales el principal problema es que nunca se logra planificar bien el
esfuerzo requerido para seguir la metodologa. Pero entonces, si logramos definir mtricas que apoyen
la estimacin de las actividades de desarrollo, muchas prcticas de metodologas tradicionales podran
ser apropiadas. El no poder predecir siempre los resultados de cada proceso no significa que estemos
frente a una disciplina de azar. Lo que significa es que estamos frente a la necesidad de adaptacin de
los procesos de desarrollo que son llevados por parte de los equipos que desarrollan software.
Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta
una idea interesante. Estas metodologas pueden involucrar prcticas tanto de metodologas giles
como de metodologas tradicionales. De esta manera podramos tener una metodologa por cada
proyecto, la problemtica sera definir cada una de las prcticas, y en el momento preciso definir
parmetros para saber cul usar.
Es importante tener en cuenta que el uso de un mtodo gil no vale para cualquier proyecto. Sin
embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente ligero y por eso
las personas que no estn acostumbradas a seguir procesos encuentran estas metodologas bastante
agradables.
18 | P g i n a
______________________________________________________________________
En la tabla que se muestra a continuacin aparece una comparativa entre estos dos grupos de
metodologas.
Tabla N 1 Comparacin entre Metodologa gil y Tradicional

Metodologas giles Metodologas Tradicionales
Basadas en heursticas provenientes de Basadas en normas provenientes de
prcticas de produccin de cdigo estndares seguidos por el entorno de
desarrollo
Especialmente preparados para cambios Cierta resistencia a los cambios

durante el proyecto
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos Proceso mucho ms controlado, con

principios numerosas polticas/normas
No existe contrato tradicional o al menos es Existe un contrato prefijado

bastante flexible
El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de

desarrollo mediante reuniones
Grupos pequeos (<10 integrantes) y Grupos grandes y posiblemente distribuidos

trabajando en el mismo sitio
Pocos artefactos Ms artefactos
Pocos roles Ms roles
Menos nfasis en la arquitectura del software La arquitectura del software es esencial y se

expresa mediante modelos
Poca documentacin Documentacin exhaustiva

Muchos ciclos de entrega Pocos ciclos de entrega
Como se muestra en la Tabla N 1, se puede apreciar que las metodologas giles, son ms baratas en
tiempo y recursos, obteniendo los mismos o mejores resultado ante las metodologas tradicionales.
________________
Tabla N 1 Extrada de [1]
19 | P g i n a
______________________________________________________________________
2.8. PARADIGMAS DE LA INGENIERIA DEL SOFTWARE
La ingeniera de software es reconocida como una disciplina legtima, digna de tener una
investigacin seria, un estudio cuidadoso y generando una gran controversia. En la industria el
ingeniero del software ha sustituido al programador como ttulo de trabajo preferente. Los modelos
de procesos de software, mtodos de ingeniera de software y herramientas se han adoptado con xito
en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la necesidad
de un enfoque ms disciplinado del software.
Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas, que

permite producir programas con una directriz especfica, tales como: estructura modular, fuerte
cohesin, alta rentabilidad, etc.
Existen tres categoras de paradigmas de programacin:

a. Los que soportan tcnicas de programacin de bajo nivel.
b. Los que soportan mtodos de diseo de algoritmos.
c. Los que soportan soluciones de programacin de alto nivel.
Los paradigmas relacionados con la programacin de alto nivel se agrupan en tres categoras de
acuerdo con la solucin que aportan para resolver el problema:
a. Solucin procedimental u operacional. Describe etapa a etapa el modo de construir la solucin.

Es decir seala la forma de obtener la solucin.
b. Solucin demostrativa. Es una variante de la procedimental. Especifica la solucin
describiendo ejemplos y permitiendo que el sistema generalice la solucin de estos ejemplos
para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir
resultados muy diferentes a sta, hace que sea tratada como una categora separada.
c. Solucin declarativa. Seala las caractersticas que debe tener la solucin, sin describir cmo
procesarla. Es decir seala qu se desea obtener pero no cmo obtenerlo.
Paradigma: El concepto de paradigma se utiliza en la vida cotidiana como sinnimo de ejemplo o para hacer referencia a
algo que se toma como modelo.
20 | P g i n a
______________________________________________________________________
3. INGENIERIA DE SOFTWARE
3.1. INTRODUCCION
En este captulo se desean presentar los fundamentos en que se basa el software, los mtodos, las
herramientas y los procedimientos que provee la ingeniera de software a fin de considerarlos para el
desarrollo de los programas en general. Se describen y analizan las etapas del proceso de la ingeniera
del software, desde la recopilacin de los requerimientos hasta la implementacin y posterior
mantenimiento.
Uno de los problemas ms importantes con los que se enfrentan los ingenieros en software y los
programadores en el momento de desarrollar un software de aplicacin, es la falta de marcos tericos
comunes que puedan ser usados por todas las personas que participan en el desarrollo del proyecto
informtico.
"La ingeniera del software surge a partir de las ingenieras de sistemas y de hardware, y considera
tres elementos claves: que son los mtodos, las herramientas y los procedimientos que facilitan el
control del proceso de desarrollo de software y brinda a los desarrolladores las bases de la calidad de
una forma productiva" (Pressman, 1993).
La ingeniera de software est compuesta por una serie de modelos que abarcan los mtodos, las
herramientas y los procedimientos. Estos modelos se denominan frecuentemente paradigmas de la
ingeniera del software y la eleccin de un paradigma se realiza bsicamente de acuerdo a la naturaleza
del proyecto y de la aplicacin, los controles y las entregas a realizar.
Para la construccin de un sistema de software, el proceso puede describirse sintticamente
como: la obtencin de los requisitos del software, el diseo del sistema de software (diseo preliminar
y diseo detallado), la implementacin, las pruebas, la instalacin, el mantenimiento y la ampliacin o
actualizacin del sistema.
El proceso de construccin est formado por etapas que son: la obtencin de los requisitos, el
diseo del sistema, la codificacin y las pruebas del sistema. Desde la perspectiva del producto, se
parte de una necesidad, se especifican los requisitos, se obtiene el diseo del mismo, el cdigo
respectivo y por ltimo el sistema de software. Algunos autores sostienen que el nombre ciclo de vida
ha sido relegado en los ltimos aos, utilizando en su lugar proceso de software, cambiando la
perspectiva de producto a proceso.
El software o producto, en su desarrollo pasa por una serie de etapas que se denominan ciclo de
vida, siendo necesario, definir en todas las etapas del ciclo de vida del producto, los procesos, las
actividades y las tareas a desarrollar.
Un ciclo de vida establece el orden de las etapas del proceso de software y los criterios a tener en
cuenta para poder pasar de una etapa a la siguiente. El tema del ciclo de vida lo han tratado algunas
organizaciones profesionales y organismos internacionales como la IEEE (Institute of Electrical and
electronics Engineers) y la ISO/IEC (International Standards Organization/International
Electrochemical Commission), que han publicado normas tituladas Standard for Developing Software
Life Cycle Proccesses (Estndar IEEE para el desarrollo de procesos del ciclo de vida del software)
(IEEE, 1991) y Software life-cycle process (Proceso de ciclo de vida del software) (ISO, 1994).
21 | P g i n a
______________________________________________________________________
3.2. OBJETIVOS
Los objetivos principales de la ingeniera de software son los siguientes:
Identificar las principales metodologas disponibles para la recoleccin y manejo de

requerimientos que deben cumplir los sistemas en desarrollo.
Conocer las principales herramientas de verificacin y validacin de software y su utilidad en
las diferentes fases del desarrollo de sistemas.
Disear aplicaciones informticas que se ajusten a las necesidades de las organizaciones.
Dirigir y coordinar el desarrollo de aplicaciones complejas.
Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto funcionamiento de los
programas y que se ajustan a los requisitos de anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando mtricas e indicadores y
controlando la calidad del software producido.
Organizar y supervisar el trabajo de su equipo de los tcnicos de mantenimiento y los
ingenieros de sistemas y redes.
Hoy en da, los productos de software se construyen con un nivel de urgencia que no se vea en
aos anteriores. La prioridad ms alta de las compaas es reducir el tiempo de salida al mercado, que
es la base del desarrollo rpido.
La ingeniera de software es percibida por algunos como demasiado formal, que consume
demasiado tiempo y demasiado estructurada para la flexibilidad necesaria durante el desarrollo de
hoy en da. Las personas que hacen estas crticas exponen que no se pueden permitir la formalidad de
un enfoque de ingeniera para construir software porque necesitan desarrollar productos de forma
rpida. Las personas que lanzan tales objeciones ven la ingeniera como una disciplina esttica y
piensan que no se puede adaptar a las necesidades cambiantes del negocio y la industria. La verdad
es, sin embargo, que la ingeniera del software es adaptativa y por lo tanto, relevante para cualquiera
que construya un producto software.
La ingeniera del software es adaptativa y no una metodologa rgida. Es una filosofa que puede
ser adaptada y aplicada a todas las actividades y dominios de aplicacin del desarrollo de software.
La ingeniera del software proporciona una amplia coleccin de opciones que los profesionales
pueden elegir para construir productos de alta calidad. Sin embargo, no hay un enfoque de ingeniera
individual o un conjunto de procesos, mtodos o herramientas de ingeniera del software para
construir un producto software.
22 | P g i n a
______________________________________________________________________
El enfoque de ingeniera del software, incluyendo los procesos, mtodos y herramientas puede y
debera ser adaptada al producto, la gente que lo construye y el entorno del negocio.
Todo este conjunto de ideas y opiniones llevaron a lo que hoy en da son las metodologas giles.
Entre los principios ms destacados de la ingeniera del software, podemos sealar los siguientes:
Haz de la calidad la razn de trabajar.

Una buena gestin es ms importante que una buena tecnologa.
Las personas y el tiempo no son intercambiables.
Seleccionar el modelo de ciclo de vida adecuado.
Entregar productos al usuario lo ms pronto posible.
Determinar y acotar el problema antes de escribir los requisitos.
Realizar un diseo.
Minimizar la distancia intelectual.
Documentar.
Las tcnicas son anteriores a las herramientas.
Primero hazlo correcto, luego hazlo rpido.
Probar, probar y probar.
Introducir las mejoras y modificaciones con cuidado.
Asuncin de responsabilidades.
La entropa del software es creciente.
La gente es la clave del xito.
Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo.
La gente necesita sentir que su trabajo es apreciado.
La educacin continua es responsabilidad de cada miembro del equipo.
El compromiso del cliente es el factor ms crtico en la calidad del software.
Tu mayor desafo es compartir la visin del producto final con el cliente.
La mejora continua de tu proceso de desarrollo de software es posible y esencial.
Tener procedimientos escritos de desarrollo de software puede ayudar a crear una cultura
compartida de buenas prcticas.
La calidad es el principal objetivo; la productividad a largo plazo es una consecuencia de una
alta calidad.
Haz que los errores los encuentre un colaborador, no un cliente.
Una clave en la calidad en el desarrollo de software es realizar iteraciones en todas las fases
del desarrollo excepto en la codificacin.
La gestin de errores y solicitud de cambios es esencial para controlar la calidad y el
mantenimiento.
Si mides lo que haces puedes aprender a hacerlo mejor.
Haz lo que tenga sentido; no recurras a los dogmas.
No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en los mayores
beneficios, y comienza a implementarlos.
23 | P g i n a
______________________________________________________________________
3.3. DISTRIBUCION DEL ESFUERZO EN UN PROYECTO DE SOFTWARE
El ciclo de vida de un proyecto de software est dividido en varias etapas. Cada una comprende un
cierto porcentaje de esfuerzo en donde conjuntamente conforman lo que se denomina el proyecto en
s.
Cada etapa va a requerir de una porcin de esfuerzo distinta a las dems las cuales son detalladas
a continuacin:
Figura N 2 Distribucin porcentual del esfuerzo de un proyecto de software.
Como se puede ver en la Figura N 2 el mantenimiento est constituido por todas las actividades
posteriores a la liberacin inicial del producto, las cuales son, el mejoramiento de las capacidades del
producto, adaptacin del producto a nuevos ambientes de cmputo y la depuracin de errores.
Gran porcentaje del esfuerzo total se dedica a mejorar el producto

Asignar poco tiempo a las pruebas piloto y de aceptacin es una de las razones de sobrepasar
el costo y tiempo de entrega de un producto
El mantenimiento gasta ms recursos que las actividades de desarrollo.
Por lo tanto, se puede decir que el mantenimiento de un software se lleva la mayor porcin de la
vida de un sistema, ya que este se va a mantener durante la existencia del sistema hasta que se vuelva
obsoleto.
_____________________
24 | P g i n a
______________________________________________________________________
3.4. ADMINISTRACION DE PROYECTOS DE SOFTWARE
3.4.1. INTRODUCCION
Las actividades tcnicas y gerenciales son igualmente importantes para el xito de un proyecto de
programacin. Las actividades de la administracin de un proyecto comprenden los mtodos para
organizar y seguir el curso del proyecto; estimacin de costos, polticas de asignacin de recursos,
control de presupuesto, determinacin de avances, ajustes al calendario de trabajo, procedimientos
de control de calidad, comunicacin con el cliente, etc.
La administracin de proyectos de desarrollo de software consiste en gestionar el desarrollo de un

producto, dentro del plazo previsto y con los fondos establecidos. Como esto requiere recursos
humanos, la administracin del proyecto involucra no slo la organizacin tcnica y las habilidades
organizativas, sino tambin el arte de dirigir un equipo de personas. La administracin de un proyecto
no es una actividad menor, puede ser tan transcendente como desarrollar la arquitectura.
La administracin de un proyecto comprende:
Estructura (Elementos organizativos involucrados)

Proceso administrativo (Responsabilidades y supervisin de participantes)
Proceso de desarrollo (mtodos, herramientas, lenguajes, documentacin y apoyo)
Programa (organizacin de los tiempos en los que deben realizarse los trabajos)
Algunos problemas importantes identificados en la administracin de software son:
Planeacin de proyectos de software pobres.

Procedimientos de seleccin de gerentes de proyecto pobres.
La medicin de proyectos es pobre.
Falta de procedimientos para vigilar el avance del proyecto.
Falta de estndares para medir la calidad del desempeo y cantidad de produccin
esperada.
Algunos mtodos sugeridos para solucionar estos problemas son:
Entrenar y educar a la direccin, jefes de proyecto y constructores.

Obligar al uso de estndares, procedimientos y documentacin.
Definir objetivos de la calidad deseada.
Desarrollar estimaciones de calendario y costos de forma exacta y verdadera.
Seleccionar jefes de proyecto basados en su capacidad para administrar proyectos ms
que en su habilidad tcnica.
25 | P g i n a
______________________________________________________________________
3.4.2. FACTORES DE LA ADMINISTRACION DE UN PROYECTO
La administracin de un proyecto debe controlar los siguientes factores:
El costo total del proyecto (aumentar o disminuir los gastos).

Las capacidades del proyecto (aadir o eliminar caractersticas funcionales).
La calidad del producto (aumentar el tiempo entre fallos de una cierta severidad).
La duracin del proyecto (reducir el tiempo programado un 20% o posponer un mes la
fecha de terminacin).
La calidad, la capacidad, los costos y los tiempos de realizacin son magnitudes que hay que
gestionar a los largo de un proyecto. El grado en el que estos cuatro factores pueden controlarse
depende de la naturaleza del proyecto y de quien o quienes los administra.
Aunque los costos pueden estar prefijados de antemano, frecuentemente se dispone de

flexibilidad, ya que en la prctica muy rara vez se cumple con los costos establecidos en
una primera instancia.
La capacidad del proyecto puede renegociarse en funcin de la evolucin del proyecto.
La calidad tambin puede variar. Cuando la calidad se establece baja, se disminuye los
costos de corto plazo, pero se incrementan los costos de largo plazo debido al costo de
mantenimiento y la insatisfaccin de los clientes. Si se establece una calidad excesiva, el
costo de desarrollo se puede hacer inaguantable.
Negociar el tiempo frente a cualquiera de las otras magnitudes es tambin algo habitual.
3.4.3. SECUENCIA DE ACTIVIDADES DE ADMINISTRACIN DE UN PROYECTO
Comprender el contenido, alcance y tiempos del proyecto.

Se refiere slo a un entendimiento global de los objetivos del proyecto y no en reunir los
requisitos que es funcin de los tcnicos.
Identificar el proceso de desarrollo (mtodos, herramientas, lenguajes, documentacin,

ayudas).
Es la decisin de qu metodologa de desarrollo usar (cascada, espiral, por incrementos, etc.)
Determinar la estructura organizativa (elementos de la organizacin involucrados).

Esto incluye identificar las unidades, departamentos, compaas, lderes disponibles, etc. Una
vez identificadas las partes y sus capacidades hay que decidir cmo deben interactuar para
realizar el trabajo.
26 | P g i n a
______________________________________________________________________
Identificar el proceso administrativo (establecer las responsabilidades de los

participantes).
Esto incluye determinar quin reportar a quin e identificar el modelo de organizacin
Programar el proceso (organigramas en los que se fijan los tiempos de ejecucin de cada
actividad).
Programar que actividades deben realizarse y en qu tiempo.
Establecer un equipo de personas (se busca y contrata el equipo de personas).

Se debe complementar la dotacin de personal de acuerdo con las actividades que debe
ejecutar cada grupo
Analizar los riesgos y buscar sus paliativos.

Los aspectos negativos que ocurren sin ser esperados, son las principales causas de que los
proyectos fracasen. La identificacin de los riegos y la bsqueda preventiva de soluciones es
una garanta de xito del proyecto.
Enumerar los productos que debe generar el proyecto.

Antes de iniciarse el proyecto desde el punto de vista tcnico debe establecerse sobre el
organigrama los productos de documentacin o de cdigo que deben generarse.
3.4.4. VALORES DEL CAPITAL HUMANO
El ingrediente principal para producir software es el equipo humano:
Profesionalidad: cumplir con las responsabilidades sociales.

Trabajo en equipo: organizacin de las funciones e interacciones.
Liderazgo: marca la direccin del trabajo basado en la experiencia.
El ingrediente principal requerido para producir software de alta calidad es la gente. Para esto se
cuenta con las actitudes de los ingenieros y tambin con la coordinacin en el tiempo para realizar el
proyecto. Esto requiere una combinacin de profesionalidad, trabajo en equipo y liderazgo.
27 | P g i n a
______________________________________________________________________
3.4.5. ORGANIZACIN DE UN EQUIPO
1. Se selecciona un lder
Asegura que se activen todos los aspectos del proyecto.
Resuelve las diferencias.
Propone las primeras tentativas.
Busca que el equipo lo acepte.
2. Se designan y documentan las responsabilidades

Lder del equipo: Propone y mantiene.
Responsable de gestin de la configuracin.
Responsable de calidad.
Responsable de administracin de requisitos.
Responsable de diseo.
Responsable de implementacin.
3. Designar y respaldar a cada responsable

Cada responsable debe estar respaldado por otro, que lo suple en caso de baja o ausencia.
3.5. RECURSOS
3.5.1. RECURSOS HUMANOS Y PARTICIPANTES
Son todas aquellas personas que intervienen y participan activamente en el ciclo de vida del
desarrollo del software desde cualquier instancia del proyecto. El nmero de personas requerido para
un proyecto de software slo puede ser determinado despus de realizar una estimacin del esfuerzo
de cada etapa implicada en el mismo (Analistas, Desarrolladores, PM, Lder tcnico, Arquitectos, etc.).
3.5.2. RECURSOS DE SOFTWARE
Son aquellos componentes de un software que son usados en otras aplicaciones de la misma
ndole, ya sea para reducir costos o tiempo (IDE, API, Herramientas de gestin, etc.).
3.5.3. RECURSOS DE ENTORNO
Es el entorno de las aplicaciones (hardware) el cual proporciona el medio fsico para desarrollar las
aplicaciones (software), esto hace que este recurso es indispensable.
28 | P g i n a
______________________________________________________________________
3.6. CICLO DE VIDA DE UN PROYECTO DE SISTEMA
El ciclo de vida de un proyecto de sistema est dividido en varias etapas. Cada etapa describe las
actividades que hay que realizar para obtener un conjunto concreto de productos de desarrollo del
software, las cuales se nombran a continuacin:
3.6.1. RECOPILACION DE LOS REQUERIMIENTOS
En esta primera etapa se realiza una recopilacin y/o encuesta con el cliente, la cual nos permite
obtener una visin de alto nivel sobre el proyecto, poniendo nfasis en la descripcin del problema
desde el punto de vista de los clientes y desarrolladores. Tambin se considera la posibilidad de una
planificacin de los recursos sobre una escala de tiempos.
3.6.2. ANALISIS
El propsito principal de esta etapa es conseguir una comprensin ms precisa de los requisitos y
una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema
completo, incluyendo la arquitectura.
El anlisis de requerimientos facilita al ingeniero de sistemas especificar la funcin y
comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las
ligaduras de diseo que debe cumplir el programa.
Tambin permite al ingeniero refinar la asignacin de software y representar el dominio de la
informacin que ser tratada por el programa. As como tambin brinda al diseador la representacin
de la informacin y las funciones que pueden ser traducidas en datos, arquitectura y diseo
procedimental.
Finalmente, la especificacin de requerimientos suministra al tcnico y al cliente, los medios para
valorar la calidad de los programas, una vez que se haya construido.
En la medida que logremos una clara comprensin de lo anterior obtendremos una arquitectura
estable y slida que nos facilite una comprensin en profundidad de los requisitos.
3.6.3. LIMITACIONES
En esta etapa se va a detallar la frontera del proyecto, es decir, cul es el alcance de nuestro
sistema.
Todo cambio que est fuera de las limitaciones se deber tratar como un cambio de alcance en la
etapa de mantenimiento.
29 | P g i n a
______________________________________________________________________
3.6.4. ESPECIFICACIONES
La obtencin de especificaciones a partir del cliente u otros actores intervinientes es un proceso

humano muy interactivo e iterativo. Normalmente a medida que se captura la informacin, se la
analiza y realimenta con el cliente, refinndola, pulindola y corrigiendo si es necesario. El analista
siempre debe llegar a conocer la temtica y el problema a resolver, dominarlo, hasta cierto punto,
hasta el mbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta
capacidad para comprender problemas de muy diversas reas o disciplinas de trabajo. El analista se
debe compenetrar con el rea de negocio del cliente, para comprender cmo ella trabaja y maneja su
informacin, desde niveles muy bajos e incluso llegando hasta los gerenciales.
Dada la gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas o
usuarios/clientes, es decir, gente que conoce profundamente el rea para la cual se desarrollar el
software.
Al contrario de los analistas, los clientes no tiene por qu saber nada de software, ni de diseos, ni
otras cosas relacionadas, slo se debe limitar a aportar objetivos, datos e informacin (de mano propia
o de sus registros, equipos, empleados, etc.) al analista, y guiado por l, para que, en primera instancia
defina un documento funcional y/o caso de uso.
3.6.5. DISEO Y ARQUITECTURA
Una vez realizada la etapa de anlisis y especificacin, se modela el sistema y definimos su

estructura (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los requisitos no
funcionales y otras restricciones.
Con toda esta informacin recopilada en los puntos anteriores, los profesionales tcnicos traducen
la informacin de alto nivel, en esquemas, diagramas, etc. de bajo nivel, para luego stos ser
comprendidos por el rea de desarrollo.
3.6.6. PROGRAMACION
Convertir un diseo a cdigo puede ser interpretada como la parte ms obvia e importante del
trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la
ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los
lenguajes de programacin utilizados, as tambin como a la calidad del diseo previamente realizado.
3.6.7. PRUEBAS DE SOFTWARE
La prueba del software es un elemento crtico para la garanta de la calidad del software. El objetivo
de la etapa de pruebas es garantizar la calidad del producto desarrollado.
30 | P g i n a
______________________________________________________________________
Esta etapa implica:

Verificar la interaccin de componentes.
Verificar la integracin adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el
software al cliente.
Disear pruebas que sistemticamente saquen a la luz diferentes clases de errores,
hacindolo con la menor cantidad de tiempo y esfuerzo.
La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad,
sino que la prueba debe ocurrir durante todo el ciclo de vida. Podemos probar la funcionalidad de los
primeros prototipos, la estabilidad, cobertura y rendimiento de la arquitectura, probar el producto
final, etc.
La prueba es un proceso que se enfoca sobre la lgica interna del software y las funciones externas.
La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error que
probablemente no fue previsto en las fases inciales del desarrollo del software.
Tipos de pruebas:
Pruebas de unidad: La prueba de unidad se centra en el mdulo. Usando la descripcin

del diseo detallado como gua, se prueban los caminos de control importantes con el fin
de descubrir errores dentro del mbito del mdulo. La prueba de unidad hace uso
intensivo de las tcnicas de prueba de caja blanca. Este tipo de prueba la realiza,
generalmente, el desarrollador luego de la codificacin de un mdulo.
Prueba de integracin: El objetivo es tomar los mdulos testeados en la prueba de unidad

y construir una estructura de programa que est de acuerdo con lo que dicta el diseo.
Hay dos formas de integracin:
o Integracin no incremental: Se combinan todos los mdulos por anticipado y se
prueba todo el programa en conjunto.
o Integracin incremental: El programa se construye y se prueba en pequeos
segmentos.
En la prueba de integracin el foco de atencin es el diseo y la construccin de la
arquitectura del software.
Las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra,
aunque se pueden llevar a cabo unas pocas pruebas de caja blanca.
Prueba del sistema: verifica que cada elemento encaja de forma adecuada y que se
alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema est
constituida por una serie de pruebas diferentes cuyo propsito primordial es ejercitar
profundamente el sistema basado en computadora. Algunas de estas pruebas son:
31 | P g i n a
______________________________________________________________________
o Prueba de validacin: proporciona una seguridad final de que el software

satisface todos los requerimientos funcionales y de rendimiento. Adems,
valida los requerimientos establecidos comparndolos con el sistema que
ha sido construido. Durante la validacin se usan exclusivamente tcnicas
de prueba de caja negra.
o Prueba de recuperacin: se fuerza a un fallo del software y se verifica que
la recuperacin se lleva a cabo apropiadamente.
o Prueba de seguridad: verificar los mecanismos de proteccin.
o Prueba de resistencia: se somete el sistema a operaciones anormales.
o Prueba de rendimiento: prueba el rendimiento del software en tiempo de
ejecucin.
o Prueba de instalacin: se centra en asegurar que el sistema software
desarrollado se puede instalar en diferentes configuraciones hardware y
software y bajo condiciones excepciones, por ejemplo con espacio de
disco insuficiente o continuas interrupciones.
Pruebas de regresin: Las pruebas de regresin son una estrategia de prueba en la cual las
pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versin
modificada, para asegurar la calidad despus de aadir la nueva funcionalidad. El propsito
de estas pruebas es asegurar que los defectos identificados en la ejecucin anterior de la
prueba se hayan corregido, que los cambios realizados no introduzcan nuevos o viejos
defectos.
La prueba de regresin puede implicar la re-ejecucin de cualquier tipo de prueba.
Normalmente, las pruebas de regresin se llevan a cabo durante cada iteracin,
ejecutando otra vez las pruebas de la iteracin anterior.
3.6.8. IMPLEMENTACION
Dentro del ciclo de vida se encuentra la fase de implementacin de un sistema, es la fase ms

costosa y que consume ms tiempo, se dice que es costosa porque muchas personas, herramientas y
recursos, estn involucrados en el proceso y consume mucho tiempo porque se completa todo el
trabajo realizado previamente durante el ciclo de vida.
En la fase de implementacin se instala el nuevo sistema de informacin para que empiece a
trabajar y se capacita a sus usuarios para que puedan utilizarlo.
La instalacin puede realizarse segn cuatro mtodos: Directo, paralelo, piloto y en fases.
Mtodo directo: Se abandona el sistema antiguo y se adopta inmediatamente el nuevo. Esto

puede ser sumamente riesgoso porque si algo no funciona correctamente, es imposible volver
al sistema anterior y las correcciones debern hacerse bajo la marcha. Regularmente con un
sistema nuevo suelen surgir problemas de pequea y gran escala. Si se trata de grandes
32 | P g i n a
______________________________________________________________________
sistemas, un problema puede significar una catstrofe, perjudicando o retrasando el

desempeo entero de la organizacin.
Mtodo paralelo: Los sistemas de informacin antiguo y nuevo operan juntos hasta que el
nuevo demuestra ser confiable. Este mtodo es de bajo riesgo. Si el sistema nuevo falla, la
organizacin puede mantener sus actividades con el sistema antiguo. Esto puede representar
un alto costo al requerir contar con personal y equipo para laborar con los dos sistemas, por
lo que este mtodo se reserva especficamente para casos en los que el costo de una falla sera
muy considerable.
Mtodo piloto: Pone a prueba el nuevo sistema slo en una parte de la organizacin. Al
comprobar su efectividad, se implementa en el resto de la organizacin. El mtodo es menos
costoso que el paralelo, aunque ms riesgoso. En este caso el riesgo es controlable al limitarse
a ciertas reas, sin afectar toda la empresa.
Mtodo en fases: La implementacin del sistema se divide en partes o fases, que se van
realizando a lo largo de un periodo de tiempo, sucesivamente. Una vez iniciada la primera fase,
la segunda no se inicia hasta que la primera se ha completado con xito. As se contina hasta
que se finaliza con la ltima fase. Es costoso porque se hace ms lenta la implementacin, pero
sin duda tiene el menor riesgo.
3.6.9. DOCUMENTACION
Es la gua o comunicacin escrita en sus diferentes formas, ya sea en modelaciones (UML),

modelado de negocio, RUP, diagramas, pruebas, manuales de usuario, manuales tcnicos, etc., todo
con el propsito de eventuales correcciones, utilizacin, mantenimiento futuro y ampliaciones al
sistema.
La importancia de la documentacin radica en que a menudo un sistema escrito por una persona
es modificado por otra. Es por ello que la documentacin sirve para facilitar la etapa de
mantenimiento.
La documentacin se compone de tres partes:
Documentacin Interna: Son los comentarios o mensajes que se aaden al cdigo fuente para
hacer ms claro el entendimiento de los procesos que lo conforman, incluyendo las
precondiciones y las pos condiciones de cada funcin.
Documentacin Externa: se define en un documento escrito con los siguientes puntos:

o Descripcin del Problema
o Datos del Autor
o Algoritmo (diagrama de flujo o Pseudocdigo)
33 | P g i n a
______________________________________________________________________
o Diccionario de Datos
o Cdigo Fuente (programa)
Manual de Usuario: Describe paso a paso la manera cmo funciona el programa, con el fin de
que el usuario lo pueda manejar para que obtenga el resultado deseado.
3.6.10. MANTENIMIENTO
El mantenimiento consiste en mantener y mejorar el software para enfrentar errores descubiertos

y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software.
Una pequea parte de este trabajo consiste en arreglar errores o mayormente conocidos como
Bugs. La mayor parte consiste en extender el sistema para que sea ms til y completo.
La fase de mantenimiento de software es una parte explcita del modelo en cascada del proceso
de desarrollo de software el cual fue desarrollado durante el movimiento de programacin
estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el
movimiento de ingeniera de software orientada a objeto no hace una mencin explcita de la fase de
mantenimiento.
En un ambiente formal de desarrollo de software, la organizacin o equipo de desarrollo tendrn
algn mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la
mayora de otros productos, es tpicamente lanzado con un conjunto conocido de defectos y
deficiencias.
Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones
operacionales o notas de lanzamiento (release notes) es as que los usuarios del software sern
capaces de trabajar evitando las deficiencias conocidas y conocern cuando el uso del software sera
inadecuado para tareas especficas.
Bugs: Defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creacin de programas de software.
34 | P g i n a
______________________________________________________________________
4. METODOLOGIAS CLASICAS
4.1. INTRODUCCION
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado al
desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue
esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente
y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las
actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones
para que adopten dichos conceptos. El punto de partida es fue el manifiesto gil, un documento que
resume la filosofa gil.
Principales ideas de la metodologa gil:
Se encarga de valorar al individuo y las iteraciones del equipo ms que a las herramientas o los
procesos utilizados.
Se hace mucho ms importante crear un producto software que funcione, que escribir mucha
documentacin.
El cliente est en todo momento colaborando en el proyecto.
Es ms importante la capacidad de respuesta ante un cambio realizado que el seguimiento
estricto de un plan.
4.2. VENTAJAS Y DESVENTAJAS
Ventajas:
La primera y ms importante, es que estas metodologas ofrecen una rpida respuesta a
cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es
tan importante realizar una buena recolecta de requisitos, como despus poder modificarlos
evitando grandes prdidas en cuanto a costes, motivacin, tiempo.
El cliente, si quiere colaborar, puede observar cmo va avanzando el proyecto, y por supuesto,
opinar sobre su evolucin gracias a las numerosas reuniones que realiza el equipo con el
cliente. Esto le da tranquilidad.
Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologas, los cambios
que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un
35 | P g i n a
______________________________________________________________________
pequeo intervalo de tiempo un pequeo trozo del proyecto al cliente, y si ste quiere
cambiarlo, solo se habr perdido unas semanas de trabajo. Con las metodologas tradicionales
las entregas al cliente se realizaban tras la realizacin de una gran parte del proyecto, eso
quiere decir que el equipo ha estado trabajando meses para que luego un mnimo cambio que
quiera realizar el cliente, conlleve la prdida de todo ese trabajo.
Importancia de la simplicidad al eliminar trabajo innecesario
Otros beneficios de las metodologas giles.
Simplificacin de la sobrecarga de procesos
Los equipos que trabajan para crear productos regulados por estndares de la industria, deben
demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de
trabajo para asegurarse de que cumplen con los estrictos mandatos de cdigo. Las metodologas giles
pueden ayudarles a cumplir los estndares de la industria con menos sobrecarga utilizando iteraciones
ms cortas y empaquetadas. El beneficio neto es un proceso que:
o Puede adaptarse a los cambios que, inevitablemente, surgirn

o Requiere menos sobrecarga en el proceso end-to-end
o Implica menos trabajo a medida que se acerca la fecha final
Calidad mejorada
Las prcticas de desarrollo gil proporcionan la funcionalidad suficiente como para satisfacer las
expectativas de los accionistas con una alta calidad. Piensa en lo que significa ofrecer lo suficiente.
Eso es, proporcionar la mnima funcionalidad con la mxima calidad. La mnima funcionalidad no
implica necesariamente una pobre funcionalidad, implica lo suficiente como para conseguir que el
trabajo se realice. Los accionistas suelen pensar que saben lo que quieren cuando especifican altos
niveles de requerimientos para un producto TI o de software. Sin embargo, la mayora de las veces,
cuando ven el producto final, ste no resuelve el problema. Simplemente, no se han imaginado de
forma precisa el mismo, o el problema ha cambiado o, incluso, la tecnologa no era tan buena como
pareca. Tambin puede ser que el producto no funcione realmente del modo en que las partes
interesadas tenan intencin, incluso aunque pensaran que haban descrito los requerimientos de
manera clara. Desarrollar iteraciones en poco tiempo y demostrar a los accionistas los productos
pronto y con frecuencia, permite tanto a los accionistas como a los equipos de desarrollo ponerse de
acuerdo y coincidir en que el producto cumple con cada una de sus necesidades.
36 | P g i n a
______________________________________________________________________
Mejorar la previsibilidad a travs de una mejor gestin del riesgo
Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a
muchas razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo
difcil que sera utilizar la nueva tecnologa; los requerimientos podan no estar del todo claros o los
clientes cambiaron de opinin cuando el trabajo estaba prcticamente finalizado. En cualquier caso,
los negocios demandan productos que cumplan con las fechas de entrega, de modo que los planes de
negocio directamente relacionados con ellos puedan cumplirse. Hay muchas formas en las que las
metodologas giles pueden ayudar a que los proyectos TI cumplan con las fechas de lanzamiento
previstas.
o Dar prioridad a los riegos. Las prcticas giles priorizan los aspectos de desarrollo de
alto riesgo permitiendo as una reduccin de los riesgos iniciales.
o Evaluacin de riesgos en paralelo. Para reas de riesgo donde debera haber mltiples
soluciones y el equipo no se pone de acuerdo a la hora de tomar el camino ms
adecuado, se debe tener en cuenta la posibilidad de optar por el desarrollo multi-set.
Esto requiere que diferentes equipos trabajen en paralelo resolviendo el mismo
problema con diferentes soluciones. La mayora de los equipos no considerarn ni tan
siquiera esta forma de trabajar, porque estn convencidos de que el tiempo y el coste
requeridos para hacer una evaluacin paralela son demasiado grandes. De hecho, el
desarrollo paralelo de alternativas es probable que traiga consigo las decisiones clave
a seguir.
Mejor perfil de productividad
Los equipos giles son ms productivos que aquellos que utilizan mtodos tradicionales a lo largo
de todo el ciclo de desarrollo. El desarrollo tradicional suele mostrar un patrn de trabajo parecido a
un palo de hockey, empezando con un ciclo de diseo de abajo arriba, movindose hasta una fase de
prototipo para pasar luego a un ciclo de desarrollo largo, seguido por otro ciclo totalmente
impredecible en el que se integran las piezas para pasar, por ltimo, a la fase de prueba final. A medida
que el proyecto progresa, los equipos tienen que trabajar juntos de manera ms coherente, confiando
en que todas las piezas trabajen juntas tal y como esperan. Pero lo cierto es que esto raramente ocurre,
de modo que la interaccin entre los equipos aumenta a medida que lo hacen los problemas de
integracin. Por ltimo, la fase de pruebas lleva todo esto al lmite. Trabajando juntos como un nico
equipo en fases verticales del producto desde el principio del ciclo de produccin, se evita el ciclo de
productividad tradicional de palo de hockey. Los equipos giles tienden a ser muy productivos desde
la primera iteracin hasta su lanzamiento y su ritmo tiene que ser gestionado de modo que no se
produzca agotamiento. Los equipos giles que mantienen este cdigo de trabajo con cada iteracin,
permiten realizar pruebas de rendimiento y sistemas desde el principio, pudiendo empezar en las
primeras iteraciones. De este modo, defectos crticos como problemas de integracin se descubren
37 | P g i n a
______________________________________________________________________
antes, la calidad general del producto es mayor y el equipo funciona de manera ms productiva
durante todo el ciclo de desarrollo.
Capacidad para aprovechar las inversiones realizadas
Adoptar las tcnicas giles de manera satisfactoria precisa un importante soporte de herramientas.
La mayora de los equipos invierten fuertemente en buenas herramientas de software y necesitan
elevar esa inversin y reducir la cantidad de cambios cuando empiezan a adoptar las metodologas
giles. La inversin ms crtica es una buena planificacin y una herramienta de gestin del trabajo que
proporcione una cartera de pedidos del equipo visible y que asocie el trabajo con cada elemento de
trabajo en cartera. Idealmente, esa herramienta de planificacin se integra con otras herramientas de
desarrollo, lo que permite a los equipos mantener la trazabilidad de la cartera de pedidos en otros
aspectos, incluyendo:
o Los requerimientos que la impulsan.

o La arquitectura bajo desarrollo.
o El software de la solucin.
o Las pruebas que validan la solucin.
Las herramientas de Rational trabajan muy bien juntas y con otros productos para ayudar a
entregar con xito proyectos giles. IBM Rational Team Concert es el componente central de
colaboracin y flujo de trabajo de la solucin IBM Rational para ingeniera de software y sistemas.
Proporciona una interfaz Open Services for Lifecycle Collaboration (OSLC) que permite a las
herramientas capacitadas OSLC integrarse sin problemas. Rational Team Concert proporciona al
equipo planificacin gil, visible y probada. De hecho, su adopcin para simplemente ese propsito ha
sido viral en IBM Software Group. Rational Team Concert proporciona gestin de elementos,
planificacin de equipos asociada a cargas de trabajo y visibilidad de proyectos, todos ellos, elementos
crticos en los proyectos giles. Los elementos de trabajo en Rational Team Concert son muy flexibles
en su uso y pueden asociarse con lanzamientos, equipos y dems.
Desventajas:
Falta de documentacin del diseo. Al no haber documentacin es el cdigo (junto con sus
comentarios) lo que se toma como documentacin.
Problemas derivados de la comunicacin oral. No hace falta decir que algo que est escrito
no se puede borrar, en cambio, algo dicho es muy fcil crear ambigedad.
Fuerte dependencia de las personas.
Falta de reusabilidad derivada de la falta de documentacin
Restricciones en cuanto a tamao de los proyectos
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.
38 | P g i n a
______________________________________________________________________
4.3.1. WATERFALL (CASCADA)
En Ingeniera de software el desarrollo en cascada, es denominado as por la posicin de las fases

en el desarrollo de esta, que parecen caer en cascada por gravedad hacia las siguientes fases. Es el
enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.
Al final de cada etapa, el modelo est diseado para llevar a cabo una revisin final, que se encarga de
determinar si el proyecto est listo para avanzar a la siguiente fase. Este modelo fue el primero en
originarse y es la base de todos los dems modelos de ciclo de vida.
Este modelo comenz a disearse en 1966 y se termin alrededor de 1970. El principal problema
de esta aproximacin es el que no podemos esperar que las especificaciones inciales sean correctas y
completas y que el usuario puede cambiar de opinin sobre una u otra caracterstica.
Adems los resultados no se pueden ver hasta muy avanzado el proyecto por lo que cualquier
cambio debido a un error puede suponer un gran retraso adems de un alto coste de desarrollo.
Como es evidente esto es solo un modelo terico, si el usuario cambia de opinin en algn aspecto
tendremos que volver hacia atrs en el ciclo de vida.
Figura N 3 Modelo del ciclo de vida en Cascada (Waterfall).

_____________________
39 | P g i n a
______________________________________________________________________
Ingeniera y Anlisis del Sistema: debido que el software es siempre parte de un sistema mayor,
el trabajo comienza estableciendo los requisitos de todos 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 mquina. 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 se han 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.
Desventajas:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay
iteraciones y se crean problemas en la aplicacin del paradigma.
Normalmente, es difcil para el cliente establecer explcitamente al principio todos los

requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar
disponible una versin operativa del programa. Un error importante no detectado hasta que
el programa est funcionando puede ser desastroso.
40 | P g i n a
______________________________________________________________________
4.3.2. PROTOTYPING
Un prototipo es una versin preliminar de un sistema de informacin con fines de demostracin o

evaluacin.
El prototipo de requerimientos es la creacin de una implementacin parcial de un sistema, para
el propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido
de una manera rpida tal como sea posible.
Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos
experimenten con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a
ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en la
documentacin actual de la especificacin de requerimientos la informacin entregada por los
usuarios para el desarrollo del sistema real. El prototipo puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como
predecesor de requerimientos). En otro caso, el prototipo puede servir su papel inmediatamente antes
de algn o todo el desarrollo incremental en modelos incremental o evolutivo.
El prototipo ha sido usado frecuentemente en los 90, porque la especificacin de requerimientos
para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes
encuentran que es mucho ms fcil proveer retroalimentacin convenientemente basada en la
manipulacin, leer una especificacin de requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados,
un prototipo generalmente se construye con los requerimientos entendidos ms pobremente.
En caso que ustedes construyan requerimientos bien entendidos, el cliente podra responder con
"s, as es", y nada podra ser aprendido de la experiencia.
Es un mtodo menos formal de desarrollo.

El prototipo es una tcnica para comprender las especificaciones.
Un prototipo puede ser eliminado.
Un prototipo puede llegar a ser parte del producto final.
Ventajas:
tiles cuando los requerimientos son cambiantes.

Cuando no se conoce bien la aplicacin.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnologa.
Cuando se requiere rapidez en el desarrollo.
41 | P g i n a
______________________________________________________________________
Desventajas:
No se conoce cuando se tendr un producto aceptable.

No se sabe cuntas iteraciones sern necesarias.
Da una falsa ilusin al usuario sobre la velocidad del desarrollo.
Se puede volver el producto an y cuando no est con los estndares.
Figura N 4 Modelo del ciclo de vida Prototipo.
______________________
42 | P g i n a
______________________________________________________________________
4.3.3. SPIRAL
Toma las ventajas del modelo de desarrollo en cascada y el de prototipos aadindole el concepto
de anlisis de riesgo.
Se definen cuatro actividades:
Planificacin: en la que se recolectan los requisitos iniciales o nuevos requisitos a aadir en esta
iteracin.
Anlisis de riesgo: basndonos en los requisitos decidimos si somos capaces o no de desarrollar el

software y se toma la decisin de continuar o no continuar.
Ingeniera: en el que se desarrolla un prototipo basado en los requisitos obtenidos en la fase de

planificacin.
Evaluacin del cliente: el cliente comenta el prototipo. Si est conforme con l se acaba el proceso,
si no se aaden los nuevos requisitos en la siguiente iteracin.
Figura N 5 Modelo del ciclo de vida en Espiral.

______________________
43 | P g i n a
______________________________________________________________________
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde
los cuadrantes son, habitualmente, fases de especificacin, diseo, realizacin y evaluacin (o
conceptos y trminos anlogos).
En cada fase el producto gana madurez (aproximacin al final deseado) hasta que en una
iteracin se logre el objetivo deseado y este sea aprobado se termina las iteraciones.
4.3.4. INCREMENTAL
Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.
Estas etapas, consisten en requerimientos, diseo, codificacin, pruebas y entrega. Permite
entregar al cliente un producto ms rpido en comparacin del modelo en cascada.
Reduce los riegos ya que provee visibilidad sobre el progreso de las nuevas versiones.
Provee retroalimentacin a travs de la funcionalidad mostrada.
Permite atacar los mayores riesgos desde el inicio.
Se pueden hacer implementaciones parciales si se cuenta con la suficiente funcionalidad.
Las pruebas y la integracin son constantes.
El progreso se puede medir en periodo cortos de tiempo.
Resulta ms sencillo acomodar cambios al acortar el tamao de los incrementos.
Se puede planear en base a la funcionalidad que se quiere entregar primero.
Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como
tcnico.
Ventajas:
La solucin se va mejorando en forma progresiva a travs de las mltiples iteraciones,

incrementa el entendimiento del problema y de la solucin por medio de los refinamientos
sucesivos.
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.
44 | P g i n a
______________________________________________________________________
Desventaja:
Requiere de mucha planeacin, tanto administrativa como tcnica

Requiere de metas claras para conocer el estado del proyecto.
Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo
tradicional de cascada.
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado Framework
(entornos de trabajo), de los cuales los dos ms famosos son el Rational Unified Process (RUP) y el
Dynamic Systems Development Method.
El desarrollo incremental e iterativo es tambin una parte esencial de un tipo de programacin
conocido como Extreme Programming y los dems frameworks de desarrollo rpido de software.
Figura N 6 Modelo del ciclo de vida Incremental.
______________________
45 | P g i n a
______________________________________________________________________
4.3.5. RAD
La metodologa de desarrollo conocida como diseo rpido de aplicaciones RAD (rapid application
development) ha tomado gran auge debido a la necesidad que tienen las instituciones de crear
aplicaciones funcionales en un plazo de tiempo corto. RAD es un ciclo de desarrollo diseado para
crear aplicaciones de computadoras de alta calidad.
El mtodo comprende el desarrollo interactivo, la construccin de prototipos y el uso de
utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rpido de
aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin.
Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de
usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas
ms conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo
o Clarion. En el rea de la autora multimedia, software como Neosoft Neoboo y MediaChance
Multimedia Builder proveen plataformas de desarrollo rpido de aplicaciones, dentro de ciertos
lmites.
Fases del RAD
Modelado de gestin: el flujo de informacin entre las funciones de gestin se modela de

forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de
gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin
la proces?
Modelado de datos: el flujo de informacin definido como parte de la fase de modelado de

gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se
definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre
estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan
transformados para lograr el flujo de informacin necesario para implementar una funcin de
gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar
un objeto de datos. Es la comunicacin entre los objetos.
Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta generacin. En

lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA
trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan
herramientas automticas para facilitar la construccin del software.
46 | P g i n a
______________________________________________________________________
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado

muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo,
se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a
fondo.
Caractersticas de RAD:
Equipos Hbridos:
Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de

tiempo completo del sistema as como aquellas personas involucradas con los requisitos.
Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y programadores
en uno.
Herramientas Especializadas:
Desarrollo "visual"
Creacin de prototipos falsos (simulacin pura)
Creacin de prototipos funcionales
Mltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en equipo
Componentes reusables
Interfaces estndares (API)
47 | P g i n a
______________________________________________________________________
Timeboxing:
Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.
Prototipos iterativos y evolucionarios:
Reunion JAD (Joint Application Development):

o Se renen los usuarios finales y los desarrolladores.
o Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:

o Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
o Los diseadores revisan el prototipo.
o Los clientes prueban el prototipo, depuran los requisitos.
o Los clientes y desarrolladores se renen para revisar juntos el producto, refinar los
requisitos y generar solicitudes de cambios.
o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se
eliminan si es necesario para cumplir el calendario.
Ventajas:
Comprar puede ahorrar dinero en comparacin con construir.

Los entregables pueden ser fcilmente trasladados a otra plataforma.
El desarrollo se realiza a un nivel de abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.
Desventajas:
Comprar puede ser ms caro que construir.

Costo de herramientas integradas y equipo necesario.
Progreso ms difcil de medir.
Menos eficiente.
Menor precisin cientfica.
Riesgo de revertirse a las prcticas sin control de antao.
48 | P g i n a
______________________________________________________________________
Ms fallas (por sndrome de codificar a lo bestia).

Prototipos pueden no escalar, un problema maysculo.
Funciones reducidas (por timeboxing).
Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas
legales.
Figura N 7 Modelo del ciclo de vida RAD.
_____________________
49 | P g i n a
______________________________________________________________________
5. METODOLOGIAS AGILES
5.1. INTRODUCCION
En las dos ltimas dcadas las notaciones de modelado y posteriormente las herramientas
pretendieron ser la clave para el xito en el desarrollo de software, no obstante, las expectativas no
fueron satisfechas del todo. Esto se debe en gran parte a que otro importante elemento, la
metodologa de desarrollo, haba sido postergado. De nada sirven buenas notaciones y herramientas
si no se proveen directivas eficientes para su aplicacin.
Hasta hace poco el proceso de desarrollo llevaba asociada un marcado nfasis en el control del
proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y
documentacin detallada. Este esquema tradicional para abordar el desarrollo de software ha
demostrado ser efectivo y necesario en proyectos de gran tamao donde por lo general se exige un
alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado y
eficiente para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en
donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.
Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y
flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniera del
software, asumiendo el riesgo que esto conlleva. Esto puede dar la impresin de que se van a hacer
mal las cosas o de dejarlo a medias pero lo cierto es que ser giles" no significa renunciar a
formalismos ni dejar de ser estrictos, rigurosos y metdicos.
En esta profesin y sobre todo en el rea del desarrollo de software, la teora nos orienta a ser
extremadamente estrictos al momento de hacer el anlisis y documentacin de nuestro sistema, pero
en la prctica actual no se puede perder tanto tiempo realizando estas tareas porque cuando se finaliza
el sistema, ste ya ha cambiado y el cliente se ha aburrido. Ser abducido y caer en esta nueva dinmica,
es muy fcil, cuando la presin nos cae encima y los plazos de entrega se acercan y cada vez se acortan
ms.
La alta competitividad actual hace que los sistemas de informacin se tengan que desarrollar de
forma rpida para adaptarse a la organizacin. Las prisas hacen que lo primero que se deseche sea un
anlisis exhaustivo y se sustituye por uno superficial o simplemente se elimina. ste es sin duda el gran
error, ya que deseamos tener un sistema desarrollado rpidamente pero con lo que realmente nos
encontramos es con un sistema lleno de errores, inmanejable y que no se puede mantener.
Es difcil cambiar las reglas del mercado mundial, as que lo que se ha pensado es adaptar las
metodologas de especificacin y desarrollo a este entorno cambiante y lleno de presiones, en el que
obtener un resultado rpido, algo que se pueda ver, mostrar y sobre todo utilizar, se ha vuelto crucial
para el xito de las organizaciones. La metodologa necesariamente ha de ser gil, debe tener un ciclo
corto de desarrollo y debe incrementar las funcionalidades en cada iteracin del mismo preservando
las existentes, ayudando al negocio en lugar de darle la espalda.
Es para este entorno para el que han nacido las metodologas giles y como consecuencia se cre
el Manifiesto gil.
50 | P g i n a
______________________________________________________________________
El Manifiesto gil describe, bsicamente, cuales son los principios sobre los que se basan los
mtodos reconocidos como giles.
ste manifiesto sugiere un enfoque orientado a la participacin de los usuarios y clientes, ms que
hacia los procesos y herramientas, trabajando ms en el software y menos en la documentacin,
colaborando ms con los clientes en vez de estar negociando y respondiendo a los cambios
sacrificando el plan de trabajo si es necesario.
En el "Manifiesto gil" se definen los cuatro valores principales por las que se deberan guiar las
metodologas giles.
1. Al individuo y sus interacciones ms que al proceso y las herramientas.

2. Desarrollar software que funciona ms que obtener una documentacin exhaustiva.
3. La colaboracin con el cliente ms que la negociacin de un contrato.
4. Responder a los cambios ms que seguir una planificacin.
El significado de cada uno de estos valores son los siguientes:
1. Al individuo y sus interacciones ms que al proceso y las herramientas.
Sin duda, la herramienta fundamental de la ingeniera del software y del desarrollo de

aplicaciones es el cerebro humano y nuestra capacidad para desarrollar y desenvolvernos con
nuestro entorno.
Una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar
su trabajo y de un equipo con el que colaborar. Estas interacciones deben tambin cuidarse.
Un factor clave para el xito es construir un buen equipo, que se lleven bien entre ellos, y que
adems sepan cmo construir su propio entorno de desarrollo. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte a l. Esto nos resta
eficiencia, es mejor que el equipo se configure sobre la base de sus necesidades y sus
caractersticas personales.
Adems, las interacciones que haga el equipo con el usuario final deberan ser igual de
fluidas siendo este usuario un miembro ms del equipo, con un objetivo comn, que es
conseguir que el proyecto funcione y sea til para l.
Si todo esto funciona bien, la eleccin de las herramientas y el proceso mismo de
desarrollo pasan a estar en un plano totalmente secundario en la ecuacin del xito del
proyecto.
2. Desarrollar software que funciona ms que obtener una documentacin exhaustiva.
Uno de los objetivos de una buena documentacin es poder ir a consultarla cuando

haya que modificar algo del sistema o surja alguna incertidumbre. Sin duda es un arma de
doble filo, una buena documentacin actualizada en cada modificacin y bien mantenida al da
permite saber el estado de la aplicacin y cmo realizar las modificaciones pertinentes, pero
51 | P g i n a
______________________________________________________________________
son pocos los que con las presiones externas de tiempo y dinero acaban actualizando la
documentacin. Generalmente, cuando se tiene que arreglar un programa porque algo falla o
surge un cambio de alcance, nos concentramos en que funcione ya que es muy posible que
haya usuarios parados y que la empresa o la organizacin est perdiendo dinero, en estos
casos, ni nos paramos a mirar detenidamente la documentacin ni, cuando se acaba de
arreglar, nos ponemos a actualizarla.
En la filosofa gil, lo primordial es evitar estos fallos, centrar nuestro tiempo en
asegurar que el software funciona y que se ha testeado exhaustivamente, e intentar reducir la
creacin de documentos poco tiles, de stos que acaban no mantenindose y ni siquiera
consultndose. La regla no escrita es no producir documentos superfluos, y slo producir
aquellos que sean necesarios de forma inmediata para tomar una decisin importante durante
el proceso de desarrollo. Estos documentos deben ser cortos y centrarse en lo fundamental,
olvidndonos de las ambigedades que no aportan nada a la comprensin del problema. No
obstante, los documentos son soporte de documentacin, permiten la transferencia del
conocimiento, registran informacin histrica, y en muchas cuestiones legales o normativas
son obligatorios, pero se resalta que son menos importantes que los productos que funcionan.
3. La colaboracin con el cliente ms que la negociacin de un contrato.
La consultora informtica de los ltimos aos se ha convertido en una lucha a muerte

entre el proveedor del servicio y el cliente que lo contrata. Por una parte, el cliente intenta que
se hagan el mayor nmero de funcionalidades con el mismo dinero, por otra parte, el consultor
intenta que por ese dinero slo se realicen las funcionalidades contratadas inicialmente. En las
reuniones de seguimiento de los proyectos es fcil or frases del tipo "esta modificacin no
entra en el contrato" respondida generalmente por la tan tpica "pues yo ya no tengo ms
presupuesto y as no podemos trabajar". Al final, este tipo de proyectos hacen que el consultor
informtico sea un hbrido entre analista y abogado, que desarrolla habilidades legales para
salvaguardarse en caso de conflicto jurdico.
Sin embargo, para que un proyecto tenga xito es fundamental la complicidad y el contacto
continuo entre el cliente y el equipo de desarrollo. El cliente debe ser y sentirse parte del
equipo. De esta manera, ambos entendern las dificultades del otro y trabajarn de forma
conjunta para solucionarlo.
4. Responder a los cambios ms que seguir una planificacin.
Una organizacin cambia constantemente, se adapta a las necesidades del mercado y

reorganiza sus flujos de trabajo para ser ms eficiente. Es difcil, pues, que en el desarrollo de
un proyecto, ste no sufra ningn cambio, ya que es seguro que las necesidades de
informacin de la empresa habrn cambiado. Y no slo esto, sino que las posibilidades
econmicas de la misma pueden influir sobre nuestro proyecto, bien sea agrandndolo o
reducindolo. Son muchos los factores que alterarn nuestra planificacin inicial del proyecto.
52 | P g i n a
______________________________________________________________________
Si no la adaptamos a estos cambios, corremos el riesgo de que, cuando acabemos,

nuestro sistema no cumpla con las necesidades pre-establecidas y el cliente se haya gastado
el dinero en vano. La habilidad de responder a los cambios de requisitos, de tecnologa,
presupuestarios o de estrategia, marcan sin duda el camino del xito del proyecto.
Como consecuencia de estos cuatro valores, el Manifiesto gil tambin enuncia los doce
principios que caracterizan un proceso gil diferencindolo de otro tradicional donde este
enfoque no se haba aplicado lo suficiente, siempre se haba dejado implcito pero sin hacer
hincapi en ellos.
a) La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de

software que le aporte un valor.
b) Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darn
una ventaja competitiva a nuestro cliente.
c) Hacer entregas frecuentes de software que funcione, desde un par de semanas a
un par de meses, con el menor intervalo de tiempo posible entre entregas.
d) Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a
lo largo de todo el proyecto.
e) Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo
que necesitan y confiar en ellos.
f) El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar
informacin dentro de un equipo de desarrollo.
g) El software que funciona es la principal medida del progreso.
h) Los procesos giles promueven un desarrollo sostenido. Los promotores, usuarios
y desarrolladores deben poder mantener un ritmo de trabajo constante de forma
indefinida.
i) La atencin continua a la calidad tcnica y al buen diseo mejoran la agilidad.
j) La simplicidad es esencial. Se ha de saber maximizar el trabajo que no se debe
realizar.
k) Las mejores arquitecturas, requisitos y diseos surgen de los equipos que se han
organizado ellos mismos.
l) En intervalos regulares, el equipo debe reflexionar con respecto a cmo llegar
a ser ms efectivo, y ajustar su comportamiento para conseguirlo.
Llegados a este punto, podemos intuir que las formas de hacer las cosas en la ingeniera del
software estn cambiando, adaptndose ms a las personas y a las organizaciones en las que han
de funcionar las aplicaciones.
Las metodologas giles no son la gran solucin a todos los problemas del desarrollo de
aplicaciones, ni tan siquiera se pueden aplicar en todos los casos, pero s que nos aportan otro
punto de vista de cmo se pueden llegar a hacer las cosas, de forma ms rpida, ms adaptable y
sin tener que perder la rigurosidad de las metodologas clsicas.
53 | P g i n a
______________________________________________________________________
5.2. BENEFICIOS
Durante la dcada pasada, las metodologas giles demostraron ser muy beneficiosas ayudando a
los equipos de desarrollo de software a la hora de entregar en fecha software de alta calidad que
compensara las necesidades de los clientes. Los equipos de software quieren trabajar con
metodologas giles porque necesitan un proceso que pueda responder de manera eficiente a los
cambios en los productos en desarrollo. Las metodologas giles permiten una mayor flexibilidad que
las metodologas tradicionales de desarrollo, ya que stas se bloquean y ralentizan en los detalles del
proyecto y son menos capaces de ajustarse a las cambiantes necesidades de los clientes, del mercado
y de los desafos imprevistos que plantea la tecnologa y el medio ambiente.
Algunos de los beneficios son los siguientes:
1. Simplificacin de la sobrecarga de procesos
Los equipos que trabajan para crear productos regulados por estndares de la industria, deben
demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de
trabajo para asegurarse de que cumplen con los estrictos mandatos de cdigo. Las metodologas giles
pueden ayudarles a cumplir los estndares de la industria con menos sobrecarga utilizando iteraciones
ms cortas y empaquetadas. El beneficio neto es un proceso que:
Puede adaptarse a los cambios que, inevitablemente, surgirn

Requiere menos sobrecarga en el proceso end-to-end
Implica menos trabajo a medida que se acerca la fecha final
2. Calidad mejorada
Las prcticas de desarrollo gil proporcionan la funcionalidad suficiente como para satisfacer las
expectativas de los clientes con una alta calidad. Eso es, proporcionar la mnima funcionalidad con la
mxima calidad. La mnima funcionalidad no implica necesariamente una pobre funcionalidad, sino
que implica lo suficiente como para conseguir que el trabajo se realice. Los clientes suelen pensar que
saben lo que quieren cuando especifican altos niveles de requerimientos para un producto de
software. Sin embargo, la mayora de las veces, cuando ven el producto final, ste no resuelve el
problema. Simplemente, no se han imaginado de forma precisa el mismo, o el problema ha cambiado
o, incluso, la tecnologa no era tan buena como pareca. Tambin puede ser que el producto no
funcione realmente del modo en que las partes interesadas tenan intencin, incluso aunque pensaran
que haban descrito los requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y
demostrar a los clientes los productos pronto y con frecuencia, permite tanto a los clientes como a los
equipos de desarrollo ponerse de acuerdo y coincidir en que el producto cumple con cada una de sus
necesidades.
54 | P g i n a
______________________________________________________________________
3. Mejorar la previsibilidad a travs de una mejor gestin del riesgo
Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a
muchas razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo
complejo que sera utilizar la nueva tecnologa, los requerimientos podan no estar del todo claros o
los clientes cambiaron de opinin cuando el trabajo estaba prcticamente finalizado. En cualquier
caso, los negocios demandan productos que cumplan con las fechas de entrega, de modo que los
planes de negocio directamente relacionados con ellos puedan cumplirse. Hay muchas formas en las
que las metodologas giles pueden ayudar a que los proyectos cumplan con las fechas de lanzamiento
previstas.
Dar prioridad a los riegos. Las prcticas giles priorizan los aspectos de desarrollo de alto riesgo
permitiendo as una reduccin de los riesgos iniciales.
Evaluacin de riesgos en paralelo. Para reas de riesgo donde debera haber mltiples soluciones
y el equipo no se pone de acuerdo a la hora de tomar el camino ms adecuado, se debe tener en cuenta
la posibilidad de optar por el desarrollo multi-set. Esto requiere que diferentes equipos trabajen en
paralelo resolviendo el mismo problema con diferentes soluciones. La mayora de los equipos no
considerarn ni tan siquiera esta forma de trabajar, porque estn convencidos de que el tiempo y el
coste requeridos para hacer una evaluacin paralela son demasiado grandes. De hecho, el desarrollo
paralelo de alternativas es probable que traiga consigo las decisiones clave a seguir.
4. Mejor perfil de productividad
Los equipos giles son ms productivos que aquellos que utilizan mtodos tradicionales a lo largo
de todo el ciclo de desarrollo. El desarrollo tradicional comienza con un ciclo de diseo de abajo arriba,
movindose hasta una fase de prototipo para pasar luego a un ciclo de desarrollo largo, seguido por
otro ciclo totalmente impredecible en el que se integran las piezas para pasar, por ltimo, a la fase de
prueba final. A medida que el proyecto progresa, los equipos tienen que trabajar juntos de manera
ms coherente, confiando en que todas las piezas trabajen juntas tal y como esperan. Pero lo cierto es
que esto raramente ocurre, de modo que la interaccin entre los equipos aumenta a medida que lo
hacen los problemas de integracin. Por ltimo, la fase de pruebas lleva todo esto al lmite. Trabajando
juntos como un nico equipo en fases verticales del producto desde el principio del ciclo de
produccin, se evita el ciclo de productividad tradicional. Los equipos giles tienden a ser muy
productivos desde la primera iteracin hasta su lanzamiento y su ritmo tiene que ser gestionado de
modo que no se produzca agotamiento. Los equipos giles que mantienen este cdigo de trabajo con
cada iteracin, permiten realizar pruebas de rendimiento y sistemas desde el principio, pudiendo
empezar en las primeras iteraciones. De este modo, defectos crticos como problemas de integracin
se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera ms
productiva durante todo el ciclo de desarrollo.
55 | P g i n a
______________________________________________________________________
5. Capacidad para aprovechar las inversiones realizadas
Adoptar las tcnicas giles de manera satisfactoria impone un importante soporte de

herramientas. La mayora de los equipos invierten fuertemente en buenas herramientas de software
y necesitan elevar esa inversin y reducir la cantidad de cambios cuando empiezan a adoptar las
metodologas giles. La inversin ms crtica es una buena planificacin y una herramienta de gestin
del trabajo que proporcione una cartera de pedidos del equipo visible y que asocie el trabajo con cada
elemento de trabajo en cartera. Idealmente, esa herramienta de planificacin se integra con otras
herramientas de desarrollo, lo que permite a los equipos mantener la trazabilidad de la cartera de
pedidos en otros aspectos, incluyendo:
Los requerimientos que la impulsan.

La arquitectura bajo desarrollo.
El software de la solucin.
Las pruebas que validan la solucin.
Algunas de las herramientas ms conocidas para la gestin y administracin de proyectos giles son:
Team Foundation Server (Microsoft)

Rational (IBM)
HP Quality Center (Hewlett Packard)
6. Realimentacin continua con el cliente
De forma temprana el cliente recibe entregables de valor, lo que permite ver los constantes
avances, logrando as, aportar en lo necesario para que el equipo vaya construyendo en la direccin
correcta lo anterior, inmediatamente reduce de forma drstica los errores y la posibilidad de costosas
correcciones, respondiendo a los cambios en requisitos de forma rpida y eficaz. El cliente es una parte
ms del equipo.
7. Equipo motivado
Cuando se realiza un proyecto aplicando alguna de las metodologas agiles, las personas
involucradas en el mismo estn ms motivadas ya que pueden usar su creatividad para resolver
problemas y cuando pueden decidir organizar su trabajo. Esto hace que las personas se sienten ms
satisfechas cuando pueden mostrar los logros que consiguen tomando sus propias decisiones.
56 | P g i n a
______________________________________________________________________
5.3.1. PROGRAMACION EXTREMA
La programacin extrema (XP) puede que marque un antes y un despus en la ingeniera del
software. sta nueva forma de trabajo fue creada por Kent Beck, Ward Cunninghamn y Ron Jeffries a
finales de los noventa. La programacin extrema ha pasado de ser una simple idea para un nico
proyecto a inundar todas las factoras de software. Algunos la definen como un movimiento social de
los analistas del software hacia los hombres y mujeres de negocios, de lo que debera ser el desarrollo
de soluciones en contraposicin a los legalismos de los contratos de desarrollo.
Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la
programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone
ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del
desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier
punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los
requisitos.
Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el
xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje
de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua
entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad
en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
tcnico.
Para alcanzar el objetivo de software como solucin gil, la metodologa XP se estructura en tres
capas que agrupan las doce prcticas bsicas de XP:
57 | P g i n a
______________________________________________________________________
Figura N 8 Capas de la Programacin Extrema.
1. Metodologa de programacin: diseo sencillo, testing, refactorizacin y codificacin con

estndares.
2. Metodologa de equipo: propiedad colectiva del cdigo, programacin en parejas, integracin
continua, entregas semanales e integridad con el cliente.
3. Metodologa de procesos: cliente in situ, entregas frecuentes y planificacin.
Introducir la vertiente de las relaciones sociales dentro de una metodologa es lo que hace de XP
algo ms que una gua de buenas maneras. Convierte a la programacin en algo mucho ms
humanizado, en algo que permite a las personas relacionarse y comunicarse para encontrar soluciones,
sin jerarquas ni enfrentamientos. Los analistas y programadores trabajan en equipo con el cliente final,
todos estn comprometidos con el mismo objetivo, que la aplicacin solvente o mitigue los problemas
que tiene el cliente. La vertiente social es fundamental en otras reas del conocimiento. XP tambin
humaniza a los desarrolladores. Un entorno agradable para el trabajo, que facilite la comunicacin y
los descansos adecuados, forma parte de esta metodologa.
Pero donde XP centra la mayor innovacin es en desmontar la preconcebida idea del coste del
cambio de las metodologas en cascada, es decir, lo que cuesta cambiar alguna funcionalidad de
nuestro aplicativo a medida que vamos avanzando en l. La idea generalizada es que cualquier
modificacin a final del proyecto es exponencialmente ms costosa que al principio del mismo. Si algo
no estaba especificado inicialmente, cuesta mucho introducirlo al final del proyecto.
_____________________
58 | P g i n a
______________________________________________________________________
Figura N 9 Curva de relacin Coste/Tiempo en metodologas tradicionales.
Lo que XP mantiene es que esta curva ha perdido vigencia y que con una combinacin de buenas
prcticas de programacin y tecnologa es posible lograr que la curva no crezca siempre de forma
exponencial.
XP pretende conseguir una curva de coste del cambio con crecimiento leve, que en un inicio es
ms costosa, pero que a lo largo del proyecto permite tomar decisiones de desarrollo lo ms tarde
posible sin que esa nueva decisin de cambio implique un alto coste en el proyecto.
Figura N 10 Curva de relacin Coste/Tiempo en metodologas giles.
La programacin extrema, propone una ecuacin de equilibrio entre el coste, el tiempo de

desarrollo, la calidad del software y el alcance de funcionalidades del mismo.
_______________________
59 | P g i n a
______________________________________________________________________
Las variables: coste, tiempo, calidad y alcance
El punto de partida de la metodologa XP son las variables que utiliza para cada proyecto:
Coste (la inversin econmica y en recursos).

Tiempo (el tiempo empleado, determinado por la fecha de entrega final).
Calidad (del cdigo y del aplicativo desarrollado).
Alcance (Conjunto de funcionalidades).
De estas cuatro variables, tres podrn ser fijadas por el cliente y/o por el jefe de proyectos, la
cuarta es responsabilidad del equipo de desarrollo y se establecer en funcin de las otras tres.
Obviamente con XP no se establece el valor de todas las variables a la primera de cambio, es un
proceso paulatino en el que cada uno de los responsables (cliente, jefe de proyecto y equipo de
desarrollo) negocian los valores de las variables que tienen asignadas hasta conseguir una ecuacin
equilibrada y que satisfaga a todos.
Distinguir entre los requisitos ms importantes y los que aportan menor valor al negocio, dando
prioridad a los primeros, nos ayudar a conseguir que el proyecto tenga en cada instante tanta
funcionalidad como sea posible. De esta manera, cuando nos acerquemos al plazo de entrega nos
aseguraremos de que lo principal est implementado y que slo quedarn los detalles de los que
podemos prescindir en el caso de necesidad. El objetivo es siempre maximizar el valor de negocio.
Los valores: comunicacin, simplicidad, realimentacin y coraje
Los creadores de esta metodologa quisieron medir su utilidad a travs de cuatro valores, que
representan aquellos aspectos cuyo cumplimiento nos va a garantizar el xito en el proyecto:
comunicacin, simplicidad, realimentacin y coraje.
Comunicacin: debe ser fluida entre todos los participantes en el proyecto. El entorno tiene
que favorecer la comunicacin espontnea, ubicando a todos los miembros en un mismo lugar.
La comunicacin directa nos da mucho ms valor que la escrita, podemos observar los gestos
del cliente, o la expresin de cansancio de nuestro compaero.
Simplicidad: cuanto ms sencilla sea la solucin, ms fcilmente podremos adaptarla a los

cambios. Las complejidades aumentan el coste del cambio y disminuyen la calidad del
software. Slo se utiliza lo que en ese momento nos da valor, y lo haremos de la forma ms
sencilla posible. Esto podra dar a pensar que va en contra de toda la filosofa de diseo y
utilizacin de patrones. Nada ms alejado de la realidad. En un proyecto XP, el uso de patrones
nos va a ayudar a reducir el tiempo de implantacin, pero lo que no vamos a hacer es dedicar
tiempo a la implementacin de patrones que no vayamos a utilizar en este proyecto, slo
haremos los que sean necesarios para ste, no utilizaremos tiempo del proyecto para
beneficiar a otro proyecto futuro que quizs no llegue nunca. Por otro lado, nada nos impide
60 | P g i n a
______________________________________________________________________
desarrollar un proyecto que nicamente se dedique a desarrollar patrones que ms tarde se

utilicen en proyecto XP.
Realimentacin: el usuario debe utilizar y probar el software desarrollado desde la primera

entrega, dndonos sus impresiones y sus necesidades no satisfechas, de manera que estas
cosas encontradas vuelvan a formar parte de los requisitos del sistema y as poder atacarlas
con tiempo.
Coraje: con XP debemos tocar continuamente cosas que ya funcionan, para mejorarlas,
optimizarlas o agregar funcionalidad. Es por eso que el coraje es parte del proyecto tambin,
ya que el miedo a tocar o modificar cosas que ya funcionan perfectamente, a veces puede ser
difcil.
Las doce prcticas bsicas de XP
Kent Beck, Ward Cunninghamn y Ron Jeffries tenan muy claro las prcticas que les haban dado
mejores resultados en sus proyectos. As que intentaron aplicarlas todas juntas dando una vuelta de
tuerca. sa fue la semilla de la metodologa de Programacin Extrema. Crearon las doce prcticas que
se refuerzan entre s para obtener los mejores resultados. Las relaciones entre ellas las podemos ver
en el siguiente grfico:
Figura N 11 Prcticas de la Programacin Extrema.

_______________________
61 | P g i n a
______________________________________________________________________
En el centro estn situadas las prcticas que ms resultados nos pueden dar al adaptarlas (diseo
simple, el test y la refactorizacin).
Incluso si no queremos tomar la totalidad de las prcticas de XP adoptando estas tres a nuestra
metodologa habitual, podemos tener una sustancial mejora en los resultados obtenidos.
1. Diseo simple: si nuestro diseo es simple, cuando alguien lo vea lo entender, si es complejo,
probablemente no pueda descifrarlo.
El principio es utilizar el diseo ms sencillo que consiga que todo funcione, de esta
manera facilitaremos el mantenimiento y minimizaremos los riesgos de modificaciones que se
hagan sin necesidad de entender el cdigo en su mximo nivel.
XP define diseo simple aquel que:
No tiene cdigo redundante, ni duplicado.

Supera todas las pruebas de funcionalidad, integridad y aceptacin.
No utiliza sintaxis complejas, es decir, que queda clara la intencin de los
programadores en cada lnea de cdigo.
Contiene el menor nmero posible de clases y mtodos.
Refactorizacin: inicialmente, nuestro sistema, son todas lneas de cdigo bien ordenadas
y comentadas, pero a medida que vamos introduciendo cambios, el orden se va perdiendo
hasta que aquello deriva en una serie de lneas de cdigo caticas, llenas de cdigo comentado
de las diferentes pruebas y con comentarios obsoletos que no se corresponden con la realidad
de la funcionalidad.
El excesivo coste de las modificaciones de las metodologas tradicionales se debe en gran
medida a este deterioro progresivo del cdigo, tras la acumulacin de modificaciones.
Para mantener la curva del coste de cambio tan plana como sea posible, en la metodologa
XP se aplica la refactorizacin, que no es otra cosa que modificar el cdigo para dejarlo en buen estado,
volviendo a escribir las partes que sean necesarias pero siempre desde un punto de vista global
a la funcionalidad, independientemente del cambio que hagamos.
El cdigo final debe conservar la claridad y sencillez del original. Los comentarios son muy
importantes para mantener esta claridad y sencillez.
2. Test: es el pilar fundamental de las prcticas de esta metodologa, sin los test, XP sera un
fracaso total, es el punto de anclaje que le da la base metodolgica a la flexibilidad de XP.
Si una funcionalidad no se ha testeado, slo funciona en apariencia, los tests han de ser
aplicados tras cada cambio, y han de ser automatizados en la medida que estos sean posibles.
Si no lo hacemos, podemos incurrir en fallos humanos a la hora de testearlos y eso puede
resultar fatal.
62 | P g i n a
______________________________________________________________________
El objetivo de los tests no es detectar errores, sino evitarlos, no se trata de corregir errores,
sino de prevenirlos. Para ello, los tests siempre se escriben antes que el cdigo a testear, nunca
despus. De esta manera estamos obligados a pensar por adelantado cules son los problemas
que podemos encontrar cuando usen nuestro cdigo, a ponernos en el lugar del usuario final,
y este hecho de pensar por adelantado evita muchos problemas, previnindonos sobre ellos
en lugar de dejar que aparezcan y luego responder sobre la marcha.
Cuando escribimos el cdigo, ya sabemos a qu se ha de enfrentar y de esta manera los
errores se minimizan. El objetivo de nuestro software ya no es cumplir unas funcionalidades
sino pasar una serie de tests definidos previamente. Es por esto por lo que el usuario final debe
ayudar al programador a desarrollar los tests unitarios de forma conjunta, ya que en stos
estar implcita la funcionalidad que queremos que tenga. Otro factor clave es que debe ser el
mismo programador el que los desarrolle, si no es as, perdemos la ventaja de minimizacin de
errores.
Los tests han de ser de tres tipos: de aceptacin, unitarios y de integridad; y siempre han
de estar automatizados en su mayor medida posible.
Test de aceptacin: es creado conjuntamente con el cliente final y debe reflejar las
necesidades funcionales del primero.
Test unitario: es creado por el programador para ver que todos los mtodos de la clase
funcionan correctamente.
Test de integridad: es creado por el equipo de desarrollo para probar que todo el
conjunto funciona correctamente con la nueva modificacin.
El uso de los tests nos facilita la refactorizacin, permitindonos comprobar de forma
sencilla que los cambios originados por la refactorizacin no han cambiado el
comportamiento del cdigo.
3. Estndares de codificacin: el equipo de desarrollo debe tener unas normas de codificacin

en comn, unas nomenclaturas propias que todos los miembros del equipo puedan entender.
El hecho de utilizar una nomenclatura comn permite que cualquier persona del equipo
entienda con mayor facilidad el cdigo desarrollado por otro miembro, de esta manera,
facilitamos las modificaciones y la refactorizacin.
Por ejemplo, si decidimos que a la hora de poner nombre a nuestras variables de una
funcin seguiremos las siguientes normas:
La primera letra ha de ser una "v" si es variable local o una "p" si nos viene por
parmetro de entrada o una "o" si es parmetro de entrada y salida.
La segunda letra ha de indicar el tipo de datos "n" si es numrico, "s" si es una cadena
de caracteres, "d" si es una fecha y "b" si es booleano.
El resto del nombre ha de ser descriptivo con su contenido lgico, separando
significados con el "_".
Si yo ahora en el cdigo veo la siguiente sentencia:
63 | P g i n a
______________________________________________________________________
If (vbPeriodo_no_calculable) {odFinal_Periodo = pdInicio_Periodo;} tengo mucha ms

informacin que si hubiese visto la siguiente: If (pnc) { fp = ip;}
El funcionamiento es el mismo y ambas sentencias estn bien codificadas, pero la primera
nos da el valor aadido de la comprensin de la codificacin estndar.
4. Propiedad colectiva del cdigo: para poder aplicar la refactorizacin y para asegurarnos de
que el diseo es simple y que se codifican segn los estndares, tenemos que eliminar otra de
las ideas que estn muy arraigadas en el mundo del desarrollo de aplicaciones que es la
propiedad individual del cdigo. Frases como "que lo modifique quien lo hizo que seguro que
lo entiende mejor" o "quin ha tocado mi funcin?" dejan de tener sentido en XP, ya que el
diseo simple nos garantiza que ser fcilmente entendible, la refactorizacin permite que
cualquier miembro del equipo rehaga el cdigo, los test automatizados nos garantizan que no
hemos modificado el comportamiento esperado del cdigo con nuestra modificacin, y la
codificacin con estndares nos da ese grado de comprensin adicional.
En XP el cdigo es propiedad de todo el equipo y cualquier miembro tiene el derecho
y la obligacin de modificarlo, para hacerlo ms eficiente o comprensible, sin que nadie se
tenga por qu sentir ofendido o con miedo de tocar algo.
5. Programacin por parejas: la programacin siempre se ha visto como algo solitario, y tener
dos personas delante de un solo teclado y de un solo monitor sorprende en un inicio. Pero las
ventajas son muchas.
Nos es muy complicado pensar a nivel abstracto y luego pasar a pensar a nivel
concreto, y si lo hacemos de forma continua, acabamos desconcentrados y cometemos
errores. Es por esto por lo que, cuando programamos, primero pensamos la estrategia de
codificacin que vamos a seguir y luego nos ponemos a codificar cada una de las partes, sin
pensar de nuevo a nivel estratgico hasta que no finalizamos alguna de las partes o a veces la
totalidad del cdigo, y entonces vemos los errores o las cosas que nos hemos dejado en la
estrategia de codificacin original.
Pensar a lo grande y en detalle a la vez nos es imposible con un solo cerebro. En la
programacin en parejas uno de los miembros debe estar pensando a nivel tctico y el otro a
nivel estratgico de manera que esos dos procesos siempre estn activos reduciendo as los
errores y mejorando la calidad del programa. Obviamente, estos dos roles deben
intercambiarse cada poco tiempo entre los miembros de la pareja para abarcar todas las
posibilidades tcticas y estratgicas.
El nivel de los miembros de la pareja ha de ser equivalente, no sirve que uno sepa
mucho y otro no tenga ni idea, deben de estar equilibrados y obviamente llevarse bien para
que tenga xito.
Tambin la rotacin ha de ser muy importante, cada miembro del equipo ha de ser
capaz de trabajar en cualquier rea de la aplicacin que se est desarrollando. De esta manera
no provocaremos cuellos de botella cuando asignemos las tareas.
64 | P g i n a
______________________________________________________________________
El hecho de que asignemos las tareas por parejas hace que el tiempo de aprendizaje
se reduzca casi a cero, simplemente sustituyendo uno de los miembros por otro nuevo. As
pues, la rotacin de reas y de parejas nos garantiza que podremos hacer un reparto ms
equitativo del trabajo sin tener que depender de una sola persona para un trabajo especfico.
Otro efecto que produce la programacin en parejas es el psicolgico, disminuye la
frustracin de la programacin en solitario, tienes a alguien que entiende el problema justo al
lado, y con el que compartir el problema. Adems, muchas veces los problemas vienen por
falta de concentracin y se tiene la solucin delante de nosotros y no se ve, y se pierde mucho
tiempo.
6. Integracin contina: en XP no esperamos a que todas las partes estn desarrolladas para
integrarlas en el sistema, sino que a medida que se van creando las primeras funcionalidades
ya se ensamblan en el sistema, de manera que ste puede ser construido varias veces durante
un mismo da. Esto se hace para que las pruebas de integracin vayan detectando los errores
desde el primer momento y no al final de todo y hace que el impacto sea mucho menor. Es
responsabilidad de cada equipo publicar lo antes posible cada funcionalidad o cada
modificacin. La idea es que todos los miembros del equipo trabajen con la ltima versin del
cdigo, para as evitar pisar versiones desarrolladas por otros compaeros y tambin poder
interactuar nuestro cdigo con la ltima versin vigente y as evitar posibles errores de
compatibilidad.
7. 40 horas semanales: no se pueden trabajar durante 14 horas seguidas y hacerlo con calidad.
Las semanas de 70 horas de trabajo son contraproducentes. Al final de la semana se tiene que
llegar cansado pero satisfecho, nunca exhausto ni desmotivado. Trabajar horas extras
disminuye la moral y el espritu del equipo. Si durante dos semanas hay que hacer horas extras,
entonces es que el proyecto va mal y se debe replantear alguna de las cuatro variables.
8. Metfora del negocio: para que dos o ms personas se puedan comunicar de forma eficiente,
deben tener el mismo vocabulario y compartir el mismo significado. El modelo de negocio que
entiende el usuario final seguramente no se corresponder con el que cree entender el
programador. Es por esto por lo que en los equipos de XP se debe crear una "metfora" con la
que el usuario final se encuentre cmodo y que le sirva al equipo de desarrollo a la hora de
modelar las clases y mtodos del sistema. La metfora, es un requerimiento comn
compartido por el usuario y el equipo de desarrollo que describe cmo deben comportarse las
diferentes partes del sistema que se quiere implementar, en un alto nivel de abstraccin.
9. Cliente in situ: en ms de una ocasin, cuando estamos programando o analizando el sistema,

nos surge una duda y pensamos en que cuando veamos al usuario final se la preguntaremos.
Posiblemente tengamos que seguir trabajando sin resolver esa duda y, si nuestra suposicin
65 | P g i n a
______________________________________________________________________
ha sido errnea, mucho del trabajo realizado puede ser en vano y as haber aumentado el
coste de nuestro proyecto.
XP necesita que el cliente final forme parte del equipo de desarrollo y est ubicado
fsicamente en el mismo sitio para que as se agilice el tiempo de respuesta y se puedan validar
todas las funcionalidades lo antes posible.
En XP, el cliente siempre tiene que estar disponible para el resto del equipo, formando parte
de l y fomentando la comunicacin cara a cara, que es la ms eficiente de las comunicaciones
posibles.
10. Entregas frecuentes: Se deben desarrollar lo antes posible versiones pequeas del sistema,
que aunque no tengan toda la funcionalidad, nos den una idea de cmo ha de ser la entrega
final y que nos sirvan para que el usuario final se vaya familiarizando con el entorno y para que
el equipo de desarrollo pueda ejecutar las pruebas de integridad.
Las nuevas versiones tienen que ser tan pequeas como sean posibles, pero tienen
que aportar un nuevo valor agregado del negocio para el cliente. Dar valor al negocio es lo que
har que la visin final del cliente sea la mejor posible.
11. Planificacin incremental: la planificacin nunca ser perfecta, variar en funcin de cmo
varen las necesidades del negocio y en cada ciclo de re planificacin se volvern a establecer
las cuatro variables de la metodologa XP.
Asumir una planificacin esttica no corresponde con la agilidad que queremos dar, ya
que las necesidades del negocio pueden cambiar drsticamente mientras estamos
desarrollando el aplicativo. En XP la planificacin se va revisando continuamente, de forma
incremental, priorizando aquellas necesidades de negocio que nos aporten mayor valor.
La planificacin se plantea como un permanente dilogo entre los responsables de la
perspectiva empresarial y de la perspectiva tcnica del proyecto.
66 | P g i n a
______________________________________________________________________
Ciclo de vida de la Programacin Extrema
Las doce prcticas mencionadas anteriormente haban dado por separado muy buenos resultados
a Kent Beck y compaa, pero unificadas en un mismo ciclo de vida es lo que dio origen a la metodologa
XP.
Una de las caractersticas ms importantes de este modelo es la comunicacin y la mejor forma de
hacerlo es presencialmente. Cuando tenemos algo importante que decir, no hay mejor manera que
hacerlo cara a cara, para que no haya equvocos. La expresin, la entonacin y las miradas son muy
importantes en este proceso.
El ciclo de vida de XP se organiza como si fuese una conversacin cliente- desarrollador.
Figura N 12 Comunicacin Cliente - Desarrollador.
_______________________
67 | P g i n a
______________________________________________________________________
ste sera el desarrollo ideal de un proyecto XP. Para acercarnos a esto, se establece un ciclo de
vida dividido en seis fases.
1. Fase de exploracin
2. Fase de planificacin
3. Fase de iteraciones
4. Fase de produccin
5. Fase de mantenimiento
6. Fase de muerte del proyecto
Figura N 13 Fases del ciclo de vida de la Programacin Extrema.
1. La fase de exploracin: La fase de exploracin es la primera fase del ciclo de vida de la

metodologa XP. En ella se desarrollan tres procesos:
Las historias del usuario.
El spike arquitectnico.
La metfora del negocio.
Todo comienza con las historias del usuario" (users stories). En esta fase los usuarios plantean
a grandes rasgos las funcionalidades y requerimientos que desean obtener del aplicativo. Las
historias de usuario tienen el mismo propsito que los casos de uso, salvo en un punto crucial, las
escriben los usuarios y no el analista. Han de ser descripciones cortas y escritas en el lenguaje del
usuario sin terminologa tcnica.
Estas historias son las que guiarn la creacin de los tests de aceptacin que han de garantizar
que dichas historias se han comprendido y se han implementado correctamente.
_______________________
68 | P g i n a
______________________________________________________________________
No debemos confundir las historias de usuario con el anlisis de requisitos, la principal

diferencia est en la profundidad de anlisis, con los requisitos queremos llegar al ltimo detalle
para no quedar mal frente al cliente, pero en XP el cliente forma parte del equipo y le podemos
preguntar ms cosas durante la implementacin, as que el nivel de detalle en las historias de
usuario ha de ser el mnimo imprescindible para que nos hagamos una idea general de la
funcionalidad.
Las historias de usuario han de ser:

Escritas por el cliente final, en su lenguaje y sin tecnicismos.
Descripciones cortas de la usabilidad y funcionalidad que se espera del sistema.
Paralela y conjuntamente se empieza con el spike arquitectnico, en el que el equipo de
desarrollo empieza a familiarizarse con la metodologa, herramientas, lenguaje y
codificaciones que se van a usar en el proyecto.
En el spike arquitectnico el equipo de desarrollo:

Prueba la tecnologa.
Se familiariza con la metodologa.
Se familiariza con las posibilidades de la arquitectura.
Realiza un prototipo que demuestre que la arquitectura es vlida para el proyecto.
Una vez finalizadas las historias de usuario y el spike arquitectnico, se pasa a desarrollar
conjuntamente la metfora del negocio.
La metfora del negocio:

Es una historia comn compartida por el usuario y el equipo de desarrollo.
Debe servir para que el usuario se sienta a gusto refirindose al sistema en los trminos
de ella.
Debe servir a los desarrolladores para implementar las clases y objetos del sistema.
2. La fase de planificacin: el resultado ha de ser una planificacin, de manera flexible, del

proyecto.
El procedimiento es el siguiente:
El cliente entrega al equipo de desarrollo las historias de usuario que ha
confeccionado, pero priorizndolas de mayor a menor importancia.
El equipo de desarrollo las estudia y estima el coste de implementarlas.
Si el equipo de desarrollo considera que la historia de usuario es demasiado compleja,
entonces el usuario final debe descomponerla en varias historias independientes ms
sencillas.
Si el equipo de desarrollo no ve claro cmo implementar una parte de la historia, el
usuario puede realizar un spike tecnolgico para ver cmo se podra implantar y as
poder evaluar el coste.
69 | P g i n a
______________________________________________________________________
Una vez tenemos la lista de historias priorizadas junto con su coste de implementacin,
pasamos a convocar la reunin del plan de entregas.
El plan de entregas se compone de una serie de planes de iteracin en el que se especifica

qu funcionalidades se van a implementar en cada vuelta de la fase de iteraciones.
Participan de esta reunin tanto los usuarios como el equipo tcnico y cada uno debe
aportar su visin del negocio de manera que se obtengan ms rpidamente aquellas
funcionalidades que den el mayor beneficio para el negocio posible.
A cada iteracin se le asigna un tiempo intentando que todas sean lo ms parecido posible.
Se determina el alcance del proyecto.
3. La fase de iteraciones: como hemos dividido el proyecto en iteraciones, esta fase se repetir
tantas veces como iteraciones tengamos. Generalmente, cada iteracin suele ser de dos a tres
semanas.
El plan de iteracin se trata de la siguiente manera:
Se recogen las historias de usuario asignadas a esta iteracin.
Se detallan las tareas a realizar por cada historia de usuario.
Las tareas deben ser de uno o tres das de desarrollo. Si son ms grandes, se debera
intentar dividir en varias ms sencillas.
Se estima el coste de cada tarea. Si el total es superior al tiempo de iteracin, se deber
prescindir de alguna historia de usuario que se pasara a la siguiente iteracin. Si son
muchas las historias de usuario desechadas, entonces hay que volver a estimar las
cuatro variables de la metodologa y volver a planificar el proyecto.
Si el tiempo total estimado de las tareas es inferior al tiempo de iteracin, se puede
asumir una historia de usuario que correspondiese a la siguiente iteracin.
Se priorizan las tareas que ms valor darn al negocio, intentando que se finalicen
historias de usuario lo antes posible.
Se reparten las primeras tareas al equipo de desarrollo y el resto se deja en una cola
de tareas sin asignar de dnde se irn tomando a medida que se vayan finalizando las
anteriores.
Se convocan reuniones de seguimiento diarias para ver si nos vamos retrasando en las
estimaciones o nos vamos adelantando a ellas y as poder desechar o incorporar historias de
usuario.
Lo ms importante es que en cada momento de cada iteracin estemos realizando la tarea
que ms valor posible da al negocio de entre las que tenemos pendientes, de manera que, si
tenemos que reducir el alcance del proyecto, slo afecte a las funcionalidades secundarias de
nuestro aplicativo.
70 | P g i n a
______________________________________________________________________
4. La fase de produccin: llegamos a esta fase al alcanzar la primera versin que el usuario final
decida que puede ponerse en produccin.
Pasaremos el aplicativo a produccin cuando alcance las funcionalidades mnimas que
aporten un valor real al negocio y una operativa arquitectnica estable.
Es decir, no esperamos a tener todas las funcionalidades implementadas, sino que en
cuanto tenemos algo que los usuarios pueden utilizar y que ayuda al negocio, pasamos la
primera versin a produccin.
Paralelamente, se sigue con las iteraciones finales de proyecto. De esta manera, antes de
que finalice el proyecto, ya estamos dando valor a la organizacin, el ROI (retorno de la
inversin) del proyecto empieza a generarse antes de que ste finalice su versin final.
En la etapa de produccin se realizan tambin iteraciones como en la anterior etapa, pero
el ritmo de stas ya no es de dos a tres semanas, sino mensuales.
Esta fase se mantiene hasta que realizamos la ltima entrega, con la que finalizamos el
mbito del aplicativo y pasamos al mantenimiento del mismo.
Durante la fase de produccin, el ritmo de desarrollo decae debido a que el equipo debe
solventar las incidencias de los usuarios. Es por esto por lo que a veces es necesario incorporar
nuevo personal al equipo.
5. La fase de mantenimiento: una vez el alcance del proyecto se ha conseguido, y tenemos todas
las funcionalidades en produccin, se revisan con el usuario aquellas nuevas historias de
usuario que se han producido tras la puesta en produccin del proyecto.
Estas nuevas funcionalidades se van incorporando segn su valor de negocio y el
presupuesto adicional del que se disponga.
El equipo de desarrollo se reduce a la mnima expresin, dejando algunos miembros para
el mantenimiento.
6. La fase de muerte del proyecto: Cuando no existen ms historias de usuario para introducir
en nuestro sistema o cuando se reduce progresivamente valor de las historias de usuario
implementadas en l, el proyecto entra en la fase de muerte.
Se ir desinvirtiendo en l hasta abandonarlo totalmente cuando no aporte valor al
negocio o cuando sus historias de usuario hayan sido absorbidas por otro sistema de
informacin.
71 | P g i n a
______________________________________________________________________
Los diferentes roles dentro de la Programacin Extrema
Cada rol tiene unas funciones claras dentro de la metodologa. Cada persona del equipo puede
ejecutar uno o varios roles, o incluso cambiar de rol durante las diferentes fases del proyecto.
1. Programador:
Escribe las pruebas unitarias.
Produce el cdigo del programa.
2. Cliente:
Escribe las historias de usuario.
Disea las pruebas de aceptacin.
Prioriza las historias de usuario.
Aporta la dimensin de negocio al equipo de desarrollo.
Representa al colectivo de usuarios finales.
Est siempre disponible para consultas.
3. Encargado de pruebas (tester):

Ejecuta las pruebas de aceptacin.
Ayuda al cliente a disear pruebas de aceptacin.
Ejecuta las pruebas de integracin.
Difunde los resultados entre el equipo de desarrollo y el cliente.
Es el responsable automatizar los casos de prueba.
Encargado de seguimiento de los errores y sus diferentes estados.
Se encarga de realimentar todo el proceso de XP, midiendo las desviaciones con
respecto a las estimaciones y comunicando los resultados para mejorar las siguientes
estimaciones.
Realiza el seguimiento de cada iteracin del proceso de XP tanto en la etapa de
iteraciones como en la de produccin.
Revala la posibilidad de incorporar o eliminar historias de usuario.
4. Lder Tcnico
Se encarga del proceso global.
Garantiza que se sigue la filosofa de XP.
Conoce a fondo la metodologa.
Provee guas y ayudas a los miembros del equipo a la hora de aplicar las prcticas
bsicas de XP.
72 | P g i n a
______________________________________________________________________
5. Consultor:
No forma parte del equipo.
Tiene un conocimiento especfico de un rea en concreto.
Ayuda a resolver un problema puntual, ya sea de spike tecnolgico o de valor de
negocio.
6. PM (Project Manager):
Es el mximo responsable del proyecto.
Hace de enlace con los clientes.
Se encarga de coordinar y de garantizar las condiciones necesarias para el desarrollo
del trabajo.
5.3.2. SCRUM
La metodologa de trabajo de Scrum, tiene sus principios fundamentales en la dcada de 1980, la

cual fue desarrollada por su necesidad en procesos de reingeniera por Goldratt, Takeuchi y Nonaka.
El concepto de Scrum tiene su origen sobre los nuevos procesos de desarrollo utilizados en
productos exitosos en Japn y los Estados. Los equipos que desarrollaron estos productos partan de
requisitos muy generales, as como novedosos, y deban salir al mercado en mucho menos del
tiempo del que se tard en lanzar productos anteriores. Estos equipos seguan patrones de ejecucin
de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos
altamente productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby y su
formacin de Scrum, de la cual se tom su nombre.
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas
prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de
equipos altamente productivos.
Podramos decir que SCRUM se basa en cierto caos controlado pero establece ciertos mecanismos
para controlar esta indeterminacin, manipular lo impredecible y controlar la flexibilidad.
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 innovacin, la competitividad, la flexibilidad y
la productividad son fundamentales.
73 | P g i n a
______________________________________________________________________
Scrum tambin 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 reaccin ante la competencia, cuando la moral de los equipos es baja
y la rotacin alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o cuando
se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.
Fundamentos de Scrum
Scrum se basa en los siguientes puntos:
El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos
(iteraciones de un mes natural y hasta de dos semanas, si as se necesita).
Las iteraciones se pueden entender como mini proyectos, en todas las iteraciones se repite un
proceso de trabajo similar (de ah el nombre iterativo) para proporcionar un resultado
completo sobre el producto final, de manera que el cliente pueda obtener los beneficios del
proyecto de forma incremental. Para ello, cada requisito se debe completar en una nica
iteracin. El equipo debe realizar todas las tareas necesarias para completarlo (incluyendo
pruebas y documentacin) y que est preparado para ser entregado al cliente con el mnimo
esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad
arriesgada relacionada con la entrega de requisitos.
La priorizacin de los requisitos por valor para el cliente y coste de desarrollo en cada iteracin.
Para que un proyecto proporcione el mejor resultado posible, y como soporte fundamental
al control emprico del proyecto, es necesario repriorizar los requisitos de manera regular, en
cada iteracin, segn el valor que proporcionan al cliente en ese momento y su coste estimado
de desarrollo. Como resultado de esta re priorizacin se actualiza la lista de requisitos
priorizada (Product Backlog).
El control emprico del proyecto. Por un lado, al final de cada iteracin se demuestra al cliente
el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en funcin
de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se
sincroniza diariamente y realiza las adaptaciones necesarias.
La potenciacin del equipo, que se compromete a entregar unos requisitos y para ello se le
otorga la autoridad necesaria para organizar su trabajo.
La sistematizacin de la colaboracin y la comunicacin tanto entre el equipo y como con el

cliente.
El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir
resultados. La tcnica del timebox consiste en fijar el tiempo mximo para conseguir ciertos
objetivos, tomar una decisin o realizar unas tareas, y hacer lo mejor que podamos en ese
74 | P g i n a
______________________________________________________________________
intervalo. De esta manera, en lugar de ponerse a trabajar en algo hasta que est hecho, de
antemano se acuerda que slo se dedica un tiempo limitado. La consciencia de esta limitacin
temporal favorece la priorizacin de objetivos/tareas y fuerza la toma de decisiones.
Requisitos para poder utilizar Scrum
Los siguientes puntos son de especial importancia para la implantacin de una gestin gil de
proyectos como Scrum:
Cultura de empresa basada en trabajo en equipo, delegacin, creatividad y mejora continua.

Compromiso del cliente en la direccin de los resultados del proyecto, gestin del ROI y
disponibilidad para poder colaborar.
Compromiso de la Direccin de la organizacin para resolver problemas frecuentes y realizar
cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando
una cultura de gestin basada en la colaboracin y en la facilitacin llevada a cabo por lderes
al servicio del equipo.
Compromiso conjunto y colaboracin de los miembros del equipo.
Relacin entre proveedor y cliente basada en la colaboracin y transparencia.
Facilidad para realizar cambios en el proyecto.
Tamao de cada equipo entre 5 y 9 personas (con tcnicas especficas de planificacin y
coordinacin cuando varios equipos trabajan en el mismo proyecto).
Equipo trabajando en un mismo espacio comn para maximizar la comunicacin.
Dedicacin del equipo a tiempo completo.
Estabilidad de los miembros del equipo.
A continuacin se realiza un detalle ms especfico sobre los requisitos de Scrum:
1. Cultura de empresa
La cultura de la empresa proveedora del proyecto debe estar alineada con la filosofa de una
gestin gil de proyectos como Scrum y debe fomentar:
El trabajo en equipo y la colaboracin entre todas las personas implicadas en un proyecto.

Equipos autogestionados a los que se ha delegado la responsabilidad y autoridad para hacer
su trabajo.
La creatividad del equipo.
La transparencia y la mejora continua, tanto del contexto de la organizacin y del proyecto y
como de las herramientas del equipo.
Scrum sistematiza la identificacin de obstculos que pueden impedir el correcto progreso del
proyecto. Los problemas previamente existentes en la organizacin (procesos, personas,
75 | P g i n a
______________________________________________________________________
herramientas, etc.) y que atentan contra la productividad se harn ms evidentes cuando se aplique
Scrum y ser necesario ir solucionndolos en cada iteracin.
2. Compromiso del cliente
Scrum exige del cliente una alta implicacin y una dedicacin regular:
El cliente tiene la responsabilidad de dirigir los resultados del producto o proyecto.

El cliente debe disponer de una visin de alto nivel del producto o proyecto y tener reflejadas
sus expectativas en forma de lista de requisitos priorizada donde ha indicado el valor que le
aportar cada uno. A partir de los costes de desarrollo que le proporcione el equipo, priorizar
los requisitos en funcin del Retorno de la Inversin (ROI) ms rpido.
El cliente re planifica el proyecto en cada iteracin para maximizar este ROI de manera
continua.
Al tratarse de un proyecto que va entregando resultados en iteraciones regulares, el cliente
debe colaborar participando en el inicio de cada iteracin (reunin de planificacin) y en el fin
de cada iteracin (demostracin), y debe estar disponible durante la ejecucin de cada
iteracin para resolver dudas.
3. Compromiso de la Direccin
La Direccin debe estar comprometida y apoyar el uso de la metodologa:
Se harn muy evidentes los obstculos ya existentes y por venir que impiden el correcto
desarrollo de los proyectos (a nivel de expectativas del cliente, productividad, calidad, etc.),
sean organizativos, tcnicos, procesos, relaciones entre personas/departamentos, habilidades
de los equipos y dems.
Ser necesario tomar decisiones, realizar cambios organizativos, alinear a personas
y proporcionar recursos para hacer la transicin. Gestores y equipos debern desaprender
formas de trabajar y de relacionarse a las que estaban habituados y aprender nuevas
dinmicas.
Un proyecto ya no consistir en que cada Departamento/rea realice su parte del trabajo y se
la pase al siguiente. Ser necesario formar equipos autogestionados y
multidisciplinares capaces de conseguir un objetivo por ellos mismos.
Habr gestores que tendrn que cambiar sus roles para ser Facilitadores o Clientes, en una
jerarqua de equipos organizada.
Se tendr que gestionar aquellas conductas personales que no permiten que otras personas
puedan aportar ideas sobre el qu y el cmo de un proyecto, que defienden a toda costa su
parcela de responsabilidad, que les cuesta mucho cederla al equipo y dejar de controlarlo, que
no son capaces de delegar tareas o de colaborar con otras personas en la resolucin de
problemas.
76 | P g i n a
______________________________________________________________________
4. Compromiso del equipo
Scrum se basa en el compromiso conjunto y la colaboracin entre los miembros del equipo. La
transparencia entre todos es fundamental para poder inspeccionar la situacin real del proyecto y as
poder hacer las mejores adaptaciones que permitan conseguir el objetivo comn. Por ello, ser difcil
trabajar utilizando Scrum para las personas que:
No confan en los dems, no permiten que otras personas puedan aportar ideas sobre el qu
y el cmo, no son capaces de colaborar en la resolucin de problemas ni de delegar tareas.
No son transparentes respecto a su trabajo personal, sea por que defienden a toda costa su
parcela de responsabilidad o por inseguridad para comunicarse o colaborar, cosa que no
permite que sean ayudados.
Su modo de relacin se basa en la generacin de conflicto o bien evitan entrar en conflictos
sanos en que ambas partes ganen y terminar sin adquirir un compromiso real con el equipo.
Priorizan su ego, sus intereses personales, de carrera o de departamento, por encima de los
intereses del equipo.
No son capaces de cambiar sus hbitos y salir de su zona de confort, tienen miedo al cambio,
prefieren que se les diga qu tienen que hacer.
Quieren seguir siendo los hroes que solucionan los proyectos y/o las personas de las que
depende la empresa.
5. Relacin entre proveedor y cliente
La relacin entre el cliente y el proveedor del proyecto debe estar basada en el principio de obtener
el mayor beneficio posible en todos los puntos del proyecto. En lugar de estar ligados por un contrato
frreo de alcance, tiempo y coste, las dos partes asumen que habr cambios para que cliente pueda
obtener lo que realmente necesita, no lo que est escrito en un documento inicial o seguir un plan
inicial que vaya perdiendo su sentido. La relacin contractual se aproxima a un contrato de un equipo
por meses, donde el cliente dirige mes a mes los resultados que el proyecto debe ir proporcionando.
Debe existir transparencia en la ejecucin del proyecto para facilitar esta relacin. Esta transparencia
la facilita de manera regular el propio proceso de Scrum, especialmente en la actividad
de demostracin de los requisitos completados al final de cada iteracin.
6. Facilidad para realizar cambios en el proyecto
Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el
producto del proyecto y realizar cambios de forma controlada sin un coste prohibitivo para el cliente.
Para ello es necesario:
Disponer de tcnicas y herramientas que faciliten el crecimiento incremental y la introduccin

de cambios.
77 | P g i n a
______________________________________________________________________
Mantener la simplicidad y calidad interna del producto que se est creando. Para cubrir los
requisitos actuales del cliente no hay que realizar ms esfuerzo del que sea necesario y, a la
vez, se debe vigilar de no hacer nada en contra de futuros requisitos.
Dado que los requisitos se desarrollan priorizados por su valor, es ms improbable que ocurran
cambios sustanciales en los primeros requisitos desarrollados, cuando se construye la base del
producto. Se fomenta que los cambios que suelen aparecen cuando el proyecto ya est avanzado se
realicen sobre requisitos que no son tan importantes.
La arquitectura emerge conforme se va necesitando, iteracin a iteracin, con lo que se asegura
que todo lo que se disea se utiliza y se prueba.
7. Tamao del equipo
El tamao de un equipo debe estar conformado entre 5 y 9 personas. Por debajo de 5 personas
cualquier imprevisto o interrupcin sobre un miembro del equipo compromete seriamente el
compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la
iteracin. Por encima de 9 personas, la comunicacin y colaboracin entre todos los miembros se hace
ms difcil y se forman subgrupos.
8. Equipo trabajando en un mismo espacio comn
Todos los miembros del equipo deben trabajar en la misma localizacin fsica, para poder
maximizar la comunicacin entre ellos mediante conversaciones cara a cara, diagramas en pizarras,
tarjetas en el tabln de tareas, etc. De esta manera se minimizan otros canales de comunicacin menos
eficientes (llamadas telefnicas, correos electrnicos, documentos), que hacen que las tareas se
transformen en un pasa manos o que hacen perder el tiempo en el establecimiento de la
comunicacin.
9. Dedicacin del equipo a tiempo completo
Los miembros del equipo deben dedicarse al proyecto a tiempo completo para de esta manera:
Evitar daar su productividad, que se vera afectada si tuviesen que ir cambiando de tarea para
diferentes proyectos o duplicando el nmero de reuniones para estos diferentes proyectos. Si
el equipo est dedicado a un nico proyecto es ms sencillo mantener el compromiso que
adquiere en cada iteracin. Como ayuda adicional para conseguir la mxima productividad, el
Facilitador se encarga de proteger al equipo de interrupciones externas.
Facilitar la gestin de recursos humanos de la organizacin. Esta gestin se simplifica si en la
organizacin las personas se reservan a un proyecto por iteraciones completas.
Por otro lado, el cliente y el facilitador deben estar dedicados al proyecto el tiempo necesario
para cumplir con sus responsabilidades.
78 | P g i n a
______________________________________________________________________
10. Estabilidad del equipo
El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mnimo posible,
para poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales,
conectarse y establecer su organizacin del trabajo.
El proceso de aplicacin de Scrum
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de 2 a 4

semanas como mximo). Cada iteracin tiene que proporcionar un resultado completo, un
incremento de producto final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente
cuando lo solicite.
Figura N 14 Proceso de Scrum.
El proceso parte de la lista de objetivos/requisitos priorizada del producto (Product Backlog),

que acta como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor
que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular
el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversin mediante
la replanificacin de objetivos del producto, que realiza durante la iteracin con vista a las siguientes
iteraciones.
_______________________
79 | P g i n a
______________________________________________________________________
Las actividades que se llevan a cabo en Scrum son las siguientes:
1. Planificacin de la iteracin (Sprint Planning)
La planificacin de las tareas a realizar en la iteracin se divide en dos partes:
Primera parte de la reunin. Se realiza en un timebox promedio de 1 a 2 horas.
o El cliente presenta al equipo la lista de requisitos priorizada (Product Backlog) del

producto o proyecto, pone nombre a la meta de la iteracin (de manera que ayude a
tomar decisiones durante su ejecucin) y propone los requisitos ms prioritarios a
desarrollar en ella.
o El equipo examina la lista, pregunta al cliente las dudas que le surgen, aade ms
condiciones de satisfaccin y selecciona los objetivos/requisitos ms prioritarios que
se compromete a completar en la iteracin, de manera que puedan ser entregados si
el cliente lo solicita.
Segunda parte de la reunin. Se realiza en un timebox promedio de 1 a 2 horas. El equipo

planifica la iteracin, elabora la tctica que le permitir conseguir el mejor resultado posible
con el mnimo esfuerzo. Esta actividad la realiza el equipo dado que ha adquirido un
compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cmo
realizarlo.
o Define las tareas necesarias para poder completar cada objetivo/requisito, creando la
lista de tareas de la iteracin (Sprint Backlog).
o Se realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea
(Pocker Planning).
o Cada miembro del equipo se autoasigna a las tareas que puede realizar.
Beneficios
Productividad mediante comunicacin y creacin de sinergias. Todos los miembros del equipo
tienen una misma visin del objetivo y se ha utilizado los conocimientos y las experiencias de
todos para elaborar la mejor solucin entregable en el mnimo tiempo y con el mnimo
esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas.
Potenciacin del compromiso del equipo sobre el objetivo comn de la iteracin:
o Es todo el equipo quien asume la responsabilidad de completar en la iteracin los
requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algn
impedimento que bloquea el progreso de la iteracin, especialmente si cuando se est
llegando al final de la iteracin es necesaria la participacin de todos para poder
completar los objetivos comprometidos.
80 | P g i n a
______________________________________________________________________
o Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se
autoasign) en los tiempos que proporcion. Si existe falta de compromiso con
respecto al resto de miembros del equipo se har muy evidente en las reuniones
diarias de sincronizacin del equipo (Daily meeting).
Una estimacin conjunta es ms fiable, dado que tiene en cuenta los diferentes conocimientos,
experiencia y habilidades de los integrantes del equipo.
2. Ejecucin de la iteracin (Sprint)
En Scrum un proyecto se ejecuta en bloques temporales de tiempos cortos y fijos (iteraciones de

2 a 4 semanas). Cada iteracin tiene que proporcionar un resultado completo, un incremento de
producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo
solicite slo sea necesario un esfuerzo mnimo para que el producto est disponible para
ser utilizado. Para ello, durante la iteracin el equipo colabora estrechamente y se llevan a cabo las
siguientes dinmicas:
Cada da el equipo realiza una reunin de sincronizacin (Daily meeting), donde cada miembro
inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica
cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de
la iteracin (Sprint Backlog) y los grficos de trabajo pendiente (Burndown charts).
El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso
y de que no se reduzca su productividad. Tambin se encarga de eliminar los obstculos que
el equipo no puede resolver por s mismo y protege al equipo de interrupciones externas que
puedan afectar su compromiso o su productividad.
Para poder completar el mximo de requisitos en la iteracin, se debe minimizar el nmero de

objetivos/requisitos en que el equipo trabaja simultneamente, completando primero los que den ms
valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas
de la iteracin, permite tener ms capacidad de reaccin frente a cambios o situaciones inesperadas.
3. Reunin diaria de sincronizacin del equipo (Daily meeting)
El objetivo de esta reunin es facilitar la transferencia de informacin y la colaboracin entre los

miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se
pueden ayudar unos a otros.
Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre
tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para
al finalizar la reunin poder hacer las adaptaciones necesarias que permitan cumplir con el
compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de planificacin de la
iteracin).
81 | P g i n a
______________________________________________________________________
En esta reunin, la cual es dirigida por el Scrum Master, cada miembro del equipo debe responder
las siguientes preguntas en un timebox de cmo mximo 15 minutos:
Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena
planeado? Cul fue el problema?
Qu voy a hacer a partir de este momento?
Qu impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteracin y en
el proyecto?
Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde se
actualiza el estado y el esfuerzo pendiente para cada tarea, as como con el grfico de horas pendientes
en la iteracin.
Recomendaciones
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del equipo no se
relajen ni se extiendan en ms detalles de los necesarios.
Realizar las reuniones de colaboracin entre miembros del equipo justo despus de la de
sincronizacin.
4. Demostracin de requisitos completados (Sprint Review)
Es una reunin informal donde el equipo presenta al cliente los requisitos completados en
la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo
esfuerzo, haciendo un recorrido por ellos lo ms real y cercano posible al objetivo que se pretende
cubrir.
En funcin 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
iteracin, re planificando el proyecto.
Se realiza en un timebox de 1 a 2 horas promedio.
Beneficios
El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos que
proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que necesita y tomar
mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los requisitos que solicit el cliente y
ver en qu puntos hay que mejorar la comunicacin entre ambos.
El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va
obteniendo. No est meses trabajando sin poder exhibir su obra.
82 | P g i n a
______________________________________________________________________
Restricciones
Slo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas
expectativas y pueda tomar decisiones correctas y objetivas en funcin de la velocidad de
desarrollo y el resultado realmente completado. Un requisito no completado quedar como
un requisito ms a re planificar.
5. Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que se
est desarrollando, el equipo analiza cmo ha sido su manera de trabajar durante la iteracin, por qu
est consiguiendo o no los objetivos a los que se comprometi al inicio de la iteracin y por qu el
incremento de producto que acaba de demostrar al cliente era lo que l esperaba o no.
Que se hizo bien.

Que hay que mejorar.
Qu he aprendido.
Cules son los problemas que podran impedirle progresar adecuadamente.
El Facilitador se encargar de ir eliminando los obstculos identificados que el propio equipo no

pueda resolver por s mismo.
Notar que esta reunin se realiza despus de la reunin de demostracin al cliente de los objetivos
conseguidos en la iteracin, para poder incorporar su feedback y cumplimiento de expectativas
como parte de los temas a tratar en la reunin de retrospectiva. Se realiza en un timebox de cmo
mximo 2 horas.
Beneficios
Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite

hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera
sistemtica, iteracin a iteracin, con resultados a corto plazo.
Aumenta la motivacin del equipo dado que participa en la mejora de proceso, se siente
escuchado, toma decisiones consensuadas (y ms sostenibles) para ir eliminando lo que
molesta e impide que sea ms productivo.
6. Replanificacin del proyecto (Product Backlog Refinement)
En las reuniones de planificacin de entregas y durante el transcurso de una iteracin (en el

Product Backlog Refinement), el cliente va trabajando en la lista de objetivos/requisitos priorizada del
producto o proyecto, aadiendo requisitos, modificndolos, eliminndolos, re priorizndolos,
cambiando el contenido de iteraciones y definiendo un calendario de entregas que se ajuste mejor a
sus nuevas necesidades.
83 | P g i n a
______________________________________________________________________
Los cambios en la lista de requisitos pueden ser debidos a:
Modificaciones que el cliente solicita tras la demostracin que el equipo realiza al final de cada
iteracin sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o
proyecto.
Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor,
hacer frente a urgencias o nuevas peticiones de clientes, etc).
Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
Para realizar esta tarea, el cliente colabora con el equipo:
Para cada nuevo objetivo/requisito, conjuntamente se hace una identificacin inicial de sus
condiciones de satisfaccin (que se detallarn en la reunin de planificacin de la iteracin).
El cliente obtiene del equipo la re estimacin de costes de desarrollo para completar los
objetivos/requisitos siguientes. El equipo ajusta el factor de complejidad, el coste para
completar los requisitos y su velocidad de desarrollo en funcin de la experiencia adquirida
hasta ese momento en el proyecto.
El cliente re prioriza la lista de objetivos/requisitos en funcin de estas nuevas estimaciones.
Roles y responsabilidades de las personas involucradas en la metodologa
1. Cliente (Product Owner)
Las responsabilidades del Cliente son:
Ser el representante de todas las personas interesadas en los resultados del proyecto (internas
o externas a la organizacin, promotores del proyecto y usuarios finales o consumidores
finales del producto) y actuar como interlocutor nico ante el equipo, con autoridad para
tomar decisiones.
Definir los objetivos del producto o proyecto.
Dirigir los resultados del proyecto y maximizar su ROI.
Es el propietario de la planificacin del proyecto. Crea y mantiene la lista priorizada con los
requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que
aportar cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona
el equipo.
Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas.
Antes de iniciar cada iteracin re planifica el proyecto en funcin de los requisitos que aportan
ms valor en ese momento, de los requisitos completados en la iteracin anterior y del
contexto del proyecto en ese momento
Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteracin.
84 | P g i n a
______________________________________________________________________
Participar en la reunin de planificacin de iteracin, proponiendo los requisitos ms

prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que
el equipo se comprometer a hacer.
Estar disponible durante el curso de la iteracin para responder a las preguntas o dudas que
puedan surgir.
No cambiar los requisitos que se estn desarrollando en una iteracin, una vez sta esta
iniciada.
2. Facilitador (Scrum Master)
Se encarga de liderar al equipo llevando a cabo las siguientes responsabilidades:
Controlar que todos los participantes del proyecto sigan los valores y principios giles,
las reglas y proceso de Scrum y guiar la colaboracin dentro del equipo y con el cliente de
manera que las sinergias sean mximas.
Asegurar que exista una lista de requisitos priorizada y que est preparada antes de la
siguiente iteracin.
Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de
sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y
consigan sus objetivos.
Ensear al equipo a auto gestionarse. No da respuestas, si no que gua al equipo con preguntas
para que descubra por s mismo una solucin.
Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada
iteracin, proporcionar un resultado til al cliente de la manera ms efectiva y as poder
finalizar el proyecto con xito. Estos obstculos se identifican de manera sistemtica en
las reuniones diarias de sincronizacin del equipo y en las reuniones de retrospectiva.
Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la iteracin
(introduccin de nuevos requisitos, desvinculacin no prevista de un miembro del equipo,
etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que
adquiri sobre los requisitos que completara en la iteracin.
3. Equipo (Team)
Es el grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen un
objetivo comn y comparten la responsabilidad del trabajo que realizan.
El tamao del equipo est entre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o
interrupcin sobre un miembro del equipo compromete seriamente el compromiso que han adquirido
y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteracin. Por encima de 9
personas, la comunicacin y colaboracin entre todos los miembros se hace ms difcil y se forman
subgrupos.
85 | P g i n a
______________________________________________________________________
Este equipo est constituido por los siguientes perfiles:
Desarrollador
Analista funcional
Analista Tcnico
Tester
Arquitecto
Proyect Manager
Team Leader
Es un equipo auto-organizado, que comparte informacin y cuyos miembros confan entre ellos.
Realiza de manera conjunta las siguientes actividades:
Seleccionar los requisitos que se compromete a completar en una iteracin, de forma que
estn preparados para ser entregados al cliente.
Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o
proyecto.
En la reunin de planificacin de la iteracin decide cmo va a realizar su trabajo:
o Seleccionar los requisitos que pueden completar en cada iteracin, realizando al
cliente las preguntas necesarias.
o Identificar todas las tareas necesarias para completar cada requisito.
o Estimar el esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se auto asigna a las tareas.
Durante la iteracin, trabajar de manera conjunta para conseguir los objetivos de la iteracin.
Cada especialista lidera el trabajo en su rea y el resto colaboran si es necesario para poder
completar un requisito.
Al finalizar la iteracin:
o Demostrar al cliente los requisitos completados en cada iteracin.
o Hacer una retrospectiva la final de cada iteracin para mejorar de forma continua su
manera de trabajar.
Herramientas que se utilizan en Scrum
Lista de objetivos / requisitos priorizada (Product Backlog)
La lista de objetivos/requisitos priorizada representa la visin y expectativas del cliente

respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y
gestionar la lista con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de
completar cada requisito.
86 | P g i n a
______________________________________________________________________
Lista de tareas de la iteracin (Sprint Backlog)
Es una lista de tareas que el equipo elabora en la reunin de planificacin de la iteracin (Sprint
planning) como plan para completar los objetivos/requisitos seleccionados para la iteracin y que se
compromete a demostrar al cliente al finalizar la iteracin, en forma de incremento de producto
preparado para ser entregado. A cada tarea se la suele llamar Historia (History)
Grficos de trabajo pendiente (Burndown charts)
Consiste en un grfico que indica el trabajo pendiente a lo largo del tiempo y muestra la
velocidad a la que se estan completando los objetivos/requisitos. Permite predecir si el equipo podr
completar el trabajo en el tiempo estimado.
Ventajas de utilizar Scrum
Entregas parciales a corto plazo de resultados

Gestin regular de las expectativas del cliente y basada en resultados tangibles.
Resultados anticipados.
Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el mercado, etc.
Gestin sistemtica del Retorno de Inversin (ROI).
Mitigacin sistemtica de los riesgos del proyecto.
Productividad y calidad.
Alineamiento entre el cliente y el equipo de desarrollo.
Equipo motivado.
5.3.3. CRYSTAL
Crystal no es solo una metodologa de desarrollo de software gil, ya que se la considera una
familia de metodologas, debido a que se subdivide en varios tipos en funcin a la cantidad de persona
involucradas en el proyecto. Esta nueva serie de metodologas fue creada por el antroplogo
Alistair Cockburn, el cul tomo como base el anlisis de distintos proyectos de desarrollo de software
y su propia experiencia, lo cual fusionando ambos aspectos dio lugar este nuevo mtodo de trabajo.
Estas metodologas presentan un enfoque gil, con gran nfasis en la comunicacin y con cierta
tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por Extreme
Programming.
Crystal Clear es la encarnacin ms gil de la serie y de la que ms documentacin se dispone. La
misma se define con mucho nfasis en la comunicacin y de forma muy liviana en relacin a los
entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los
usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las
cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time
para realizar validaciones sobre la UI (Interface de Usuario) y para participar en la definicin de los
requerimientos funcionales y no funcionales del software.
87 | P g i n a
______________________________________________________________________
La familia Crystal dispone de un cdigo de color para marcar la complejidad de una metodologa,
ya que cuanto ms oscuro es el color, ms pesado es el mtodo y cuanto ms crtico es un sistema,
ms rigor se requiere. El cdigo cromtico se aplica a una forma tabular que se usa para situar el rango
de complejidad al cual se aplica una metodologa.
El nombre Crystal deriva de la caracterizacin de los proyectos segn 2 dimensiones, tamao y
complejidad.
En la siguiente imagen se puede apreciar la escala de colores dependiendo de la complejidad del
sistema:
Figura N 15 Familia de Metodologas Crystal.
Claro (Clear) es para equipos de hasta 8 personas o menos.

Amarillo para equipos entre 10 a 20 personas.
Naranja para equipos entre 20 a 50 persona.
Roja para equipos de ms de 50 personas.
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. 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
o definidas.
_______________________
88 | P g i n a
______________________________________________________________________
Propiedades de Crystal Clear:
Entrega frecuente: consiste en entregar software a los clientes con frecuencia, no solamente
en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal
o mensual.
Comunicacin osmtica: todos juntos en el mismo cuarto. Una variante especial es disponer
en la sala de un experto diseador senior y discutir respecto del tema que se trate.
Mejora reexiva: tomarse un pequeo tiempo diariamente para pensar bien qu se est
haciendo, cotejar notas, reexionar, discutir.
Seguridad personal: hablar con los compaeros cuando algo molesta dentro del grupo.
Foco: saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo.
Fcil acceso a usuarios expertos: tener alguna comunicacin con expertos desarrolladores.
Roles:
Patrocinador: produce la Declaracin de Misin con Prioridades de Compromiso (Tradeoff).

Consigue los recursos y dene la totalidad del proyecto.
Usuario Experto: junto con el Experto en Negocios produce la Lista de Actores-Objetivos y el
Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir
atajos de teclado, modos de operacin, informacin a visualizar simultneamente, navegacin.
Diseador Principal: produce la Descripcin Arquitectnica. Se supone que debe ser al menos
un profesional de Nivel 3. En Metodologas giles se denen tres niveles de experiencia:
o Nivel 1 es capaz de seguir los procedimientos.
o Nivel 2 es capaz de apartarse de los procedimientos especcos y encontrar otros
distintos.
o Nivel 3 es capaz de manejar con uidez, mezclar e inventar procedimientos.
El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programador ms

experto.
Diseador/Programador: produce, junto con el Diseador Principal, los Borradores de
Pantallas, el Modelo Comn de Dominio, las Notas y Diagramas de Diseo, el Cdigo Fuente,
el Cdigo de Migracin, las Pruebas y el Sistema Empaquetado.
Experto en Negocios: junto con el Usuario Experto produce la Lista de Actores/Objetivos y el
Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y polticas del negocio.
Coordinador: con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el
Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteracin y la Agenda de
Visualizacin.
Verificador: produce el Reporte de errores. Puede ser un programador en tiempo parcial, o un
equipo de varias personas.
89 | P g i n a
______________________________________________________________________
Escritor: produce el Manual de Usuario. El Equipo como Grupo es responsable de producir la

Estructura y Convenciones del Equipo y los Resultados del Taller de Reexin.
La gua de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeos.
Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en
los miembros del equipo.
Presta especial importancia a la ubicacin fsica del grupo, donde la comunicacin cumple el
principal rol.
La entrega frecuente de cdigo confiable mantiene el foco y evita distracciones.
5.3.4. Kanban
Esta metodologa tiene como base de su origen la aplicacin de los procesos de produccin JIT
(Just in Time) ideados por la empresa automotriz Toyota, en la cual utilizaban tarjetas visuales para
identificar necesidades de material en la cadena de produccin.
Kanban se basa en la idea de que el trabajo en curso debera limitarse, y slo deberamos empezar
con algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra funcin
posterior de la cadena.
La metodologa Kanban utiliza un mecanismo de control visual para hacer seguimiento del trabajo
conforme este viaja a travs del flujo de valor. Normalmente, se emplea un panel o pizarra con notas
adhesivas o un panel electrnico de tarjetas para gestionar el flujo de trabajo y las asignaciones. Las
mejores prcticas apuntan al uso de ambos mtodos.
El Kanban (o tarjeta visual) implica que se genera una seal visual para indicar que hay nuevos
bloques de trabajo que pueden ser comenzados porque el trabajo en curso actual no alcanza el
mximo acordado.
El aporte principal de Kanban a las metodologas agiles es que a travs de la implementacin de
tarjetas visuales, proporciona transparencia al proceso, ya que su flujo de trabajo expone los cuellos
de botella, colas, variabilidad y desperdicios a lo largo del tiempo y todas las cosas que impactan al
rendimiento de la organizacin en trminos de la cantidad de trabajo entregado y el ciclo de tiempo
requerido para entregarlo. Proporciona a los miembros del equipo y a las partes interesadas visibilidad
sobre los efectos de sus acciones o falta de accin. De esta forma, cambia el comportamiento y motiva
a una mayor colaboracin en el trabajo. La visibilidad de los cuellos de botella, desperdicios y
variabilidades y su impacto tambin promueve la discusin sobre las posibles mejoras, y hace que los
equipos comiencen rpidamente a implementar mejoras en su proceso.
Como resultado, Kanban propicia la evolucin incremental de los procesos existentes, una
evolucin que generalmente est alineada con los valores de las metodologas agiles. Kanban no
genera una revolucin radical de la forma en la que las personas trabajan, sino que sugiere un cambio
gradual. Es un cambio que surge del entendimiento y del consenso de entre todos los participantes del
proyecto.
90 | P g i n a
______________________________________________________________________
Las principales ventajas de esta metodologa es que es muy fcil de aplicar, actualizar y asumir
por parte del equipo. Adems, se destaca por utilizar una tcnica de gestin de las tareas muy visual y
prctica, lo que permite ver a simple vista el estado de los proyectos, as como tambin pautar el
desarrollo del trabajo de manera efectiva.
Principios del mtodo Kanban
Calidad garantizada: todo lo que se hace debe salir bien en la primera instancia, no hay margen
de error. Para lograr esto no se premia la rapidez, sino la calidad final de las tareas realizadas.
Esto se basa en el hecho que muchas veces cuesta ms arreglarlo despus que hacerlo bien de
entrada.
Reduccin del desperdicio: se basa en hacer solamente lo justo y necesario, para garantizar
que se haga bien. Esto supone la reduccin de todo aquello que es superficial o secundario.
Mejora continua: Se acuerda perseguir el cambio incremental y evolutivo. No es simplemente
un mtodo de gestin, sino tambin un sistema de mejora en el desarrollo de proyectos, segn
los objetivos a alcanzar.
El equipo debe estar de acuerdo que el cambio continuo, gradual y evolutivo es la manera de
hacer mejoras en el sistema y debe apegarse a ello. Los cambios radicales pueden parecer ms
eficaces, pero tienen una mayor tasa de fracaso debido a la resistencia y el miedo en la
organizacin.
Flexibilidad: es necesario poder priorizar aquellas tareas entrantes segn las necesidades del
momento y tener la capacidad de dar respuesta a estas tareas imprevistas.
Aplicacin del mtodo Kanban
La aplicacin del mtodo Kanban implica la generacin de un tablero de tareas que permitir
mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta metodologa, deberemos
tener claro los siguientes aspectos:
1. Definir el flujo de trabajo de los proyectos: para ello, simplemente deberemos crear nuestro
propio tablero, que deber ser visible y accesible por parte de todos los miembros del equipo.
Cada una de las columnas corresponder a un estado concreto del flujo de tareas, que nos
servir para saber en qu situacin se encuentra cada proyecto. El tablero debe tener tantas
columnas como estados por los que pasa una tarea, desde que se inicia hasta que finaliza. A
diferencia de SCRUM, una de las peculiaridades del tablero es que este es continuo. Esto
significa que no se compone de tarjetas que se van desplazando hasta que la actividad queda
realizada por completo. En este caso, a medida que se avanza, las nuevas tareas (mejoras,
incidencias o nuevas funcionalidades) se acumulan en la seccin inicial, de manera que en las
reuniones peridicas con el cliente se priorizan y se colocan dentro de la seccin que se estima
oportuna.
91 | P g i n a
______________________________________________________________________
Dicho tablero puede ser especfico para un proyecto en concreto o bien genrico. No hay unas
fases del ciclo de produccin establecidas sino que se definirn segn el caso en cuestin, o se
establecer un modelo aplicable genricamente para cualquier proyecto de la organizacin.
2. Visualizar las fases del ciclo de produccin. Al igual que Scrum, Kanban se basa en el principio
de desarrollo incremental, dividiendo el trabajo en distintas partes. Esto significa que no
hablamos de la tarea en s, sino que lo dividimos en distintos pasos para agilizar el proceso de
produccin.
Normalmente cada una de esas partes se escribe en un post-it y se pega en el tablero, en la
fase que corresponda. Dicho post-it contiene, normalmente, la descripcin de la tarea con la
estimacin de horas, la informacin bsica para que el equipo sepa rpidamente la carga total
de trabajo que supone. Adems, se pueden emplear fotos para asignar responsables as como
tambin usar tarjetas con distintas formas para poner observaciones o indicar bloqueos
(cuando una tarea no puede hacerse porqu depende de otra).
Al final, el objetivo de la visualizacin es clarificar al mximo el trabajo a realizar, las tareas
asignadas a cada equipo de trabajo (o departamento), as como tambin las prioridades y la
meta asignada.
3. Stop Starting, start finishing. Este es el lema principal de la metodologa Kanban. De esta
manera, se prioriza el trabajo que est en curso en vez de empezar nuevas tareas.
Precisamente, una de las principales aportaciones del Kanban es que el trabajo en curso debe
estar limitado y, por tanto, existe un nmero mximo de tareas a realizar en cada fase; no se
puede abrir una nueva tarea sin finalizar otra.
De esta manera, se pretende dar respuesta al problema habitual de muchas empresas de tener
muchas tareas abiertas pero con un promedio de finalizacin muy bajo. Aqu lo importante es
que las tareas que se abran se cierren antes de empezar con la siguiente.
4. Control del Flujo. A diferencia de SCRUM, la metodologa Kanban no se aplica a un nico

proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con un
flujo de trabajo constante, las tareas ms importantes en cola para ser desarrolladas y un
seguimiento pasivo para no tener que interrumpir al trabajador en cada momento.
Asimismo, dicha metodologa de trabajo nos permite hacer un seguimiento del trabajo
realizado, almacenando la informacin que nos proporcionan las tarjetas.
Las tres reglas de Kanban
1. Mostrar el proceso
2. Limitar el trabajo en curso
3. Optimizar el flujo de trabajo
92 | P g i n a
______________________________________________________________________
1. Mostrar el proceso
Consiste en la visualizacin de todo el proceso de desarrollo, mediante un tablero fsico,
pblicamente asequible. El objetivo de mostrar el proceso, consiste en:
Entender mejor el proceso de trabajo actual.

Conocer los problemas que puedan surgir y tomar decisiones.
Mejorar la comunicacin entre todos los interesados/participantes del proyecto.
Hacer los futuros procesos ms predecibles.
Un tablero Kanban, se divide en columnas las cuales representan un proceso de trabajo. Un

ejemplo clsico de columnas para dividir un tablero Kanban, sera el siguiente:
Cola de entrada | Anlisis | Desarrollo | Test | Deploy
Figura N 16 Tablero Kanban.
La cantidad y nombre de las columnas, vara de acuerdo a las necesidades de cada equipo y en la
mayora de los casos, stas, son subdivididas en dos columnas: cola de espera y en curso.
2. Limitar el trabajo en curso

Los lmites del trabajo en curso consisten en acordar anticipadamente, la cantidad de tems que
pueden abordarse por cada proceso (es decir, por columnas del tablero). El principal objetivo de
establecer estos lmites, es el de detectar cuellos de botella que representan el estancamiento de un
proceso determinado.
_______________________
93 | P g i n a
______________________________________________________________________
Es un valor a tener en cuenta, que la resolucin de cuellos de botella, la mayora de las veces,
motiva la colaboracin del equipo entre los diferentes procesos. Pues mientras existen procesos
colapsados, existen a la vez, procesos libres para aceptar nuevos tems. El cuello de botella ha generado
un estancamiento, y los procesos libres, pueden ayudar a destrabar a los procesos colapsados.
3. Optimizar el flujo de trabajo
El objetivo es generar una produccin estable, continua y previsible. Midiendo el tiempo que el
ciclo completo de ejecucin del proyecto demanda (por ejemplo, cantidad de das desde el inicio del
anlisis hasta el fin de la implementacin), se obtiene el CycleTime.
Al dividir, el CycleTime por el WIP (trabajo en curso), se obtiene el rendimiento de trabajo,
denominado Throughput, es decir, la cantidad de tems que un equipo puede terminar en un
determinado perodo de tiempo.
Con estos valores, la optimizacin del flujo de trabajo consistir en la bsqueda de:
Minimizar el CycleTime
Maximizar el Throughput
Lograr una variabilidad mnima entre CycleTime y Throughput
Dicho todo esto, se puede decidir que implementando Kanban se consigue aumentar la eficiencia
en los procesos, evitar retrasos y no desaprovechar recursos, reduccin de tiempos muertos en y entre
procesos, mejor mantenimiento, informacin ms rpida y precisa, minimizacin de entregas con
errores y evitar sobrecarga de trabajo.
5.3.5. FEATURE DRIVEN DEVELOPMENT (FDD)
La metodologa gil FDD, con sus siglas en ingls Feature Driven Development, fue impulsada por
Jeff de Luca y Meter Coad en los aos 80.
Como las otras metodologas adaptables, se enfoca en iteraciones cortas que entregan
funcionalidad tangible. Dicho enfoque no hace nfasis en la obtencin de los requerimientos sino en
cmo se realizan las fases de diseo y construccin. Sin embargo, fue diseado para trabajar con otras
actividades de desarrollo de software y no requiere la utilizacin de ningn modelo de proceso
especfico. Hace nfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo
permanente del avance del proyecto. Al contrario de otras metodologas, FDD promete ser
conveniente para el desarrollo de sistemas crticos y est orientada a equipos de trabajo ms grandes,
con ms personas que aquellos a los que normalmente se aplican otras metodologas como Scrum.
Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto. No hace
nfasis en la obtencin de los requerimientos sino en cmo se realizan las fases de diseo y
construccin.
FDD se basa en un ciclo muy corto de iteracin, nunca superior a dos semanas, y en el que el
anlisis y los desarrollos estn orientados a cumplir una lista de Features que tiene que tener el
software a desarrollar.
94 | P g i n a
______________________________________________________________________
Un Feature debe cumplir las siguientes caractersticas:
Debe ser simple y poco costosa de desarrollar, de entre uno y diez das.
Debe aportar valor al cliente y ser relevante para su negocio.
Debe poderse expresar en trminos de accin, resultado y objeto.
La metodologa sigue cinco fases iterativas:
1. Desarrollo/Modificacin de un Modelo Global

2. Creacin/Modificacin de la lista de Features
3. Planificacin
4. Diseo
5. Implementacin
Ventajas
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.
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.
Mejora continua de los procesos y el equipo de desarrollo.
Evita malentendidos de requerimientos entre el cliente y el equipo.
Desventajas
Falta de documentacin del diseo. El cdigo no puede tomarse como una documentacin. En
sistemas de tamao grande se necesita 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.
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 reusabilidad. La falta de documentacin hacen difcil que pueda reutilizarse el cdigo
gil.
95 | P g i n a
______________________________________________________________________
5.3.6. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
Esta metodologa parte de la idea de que las necesidades del cliente son siempre cambiantes
durante el desarrollo del proyecto y posteriormente a su entrega.
Esta tcnica fue desarrollada por Jim Highsmith y Sam Bayer a comienzos de los 90. La novedad
de esta metodologa es que en realidad no es una metodologa de desarrollo de software, sino un
mtodo/tcnica, a travs del cual inculcar una cultura adaptativa a la empresa para adaptarse al
cambio y no luchar contra l. En ella no hay un ciclo de vida esttico (planear-disear-construir), si no
que ofrece un ciclo de vida iterativo, donde cada ciclo puede ser modificado al tiempo que otro es
ejecutado (especular colaborar-aprender).
Los objetivos de esta metodologa son:
1) Concienciar a la organizacin de que debe esperar cambio e incertidumbre y no orden y

estabilidad.
2) Desarrollar procesos iterativos de gestin del cambio.
3) Facilitar la colaboracin y la interaccin de las personas a nivel interpersonal, cultural y
estructural.
4) Marcar una estrategia de desarrollo rpido de aplicaciones pero con rigor y disciplina.
Sus principales caractersticas son:
1) Iterativo.
2) Orientado a los componentes software ms que a las tareas.
3) Tolerante a los cambios.
4) Guiado por los riesgos.
5) La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo.
El ciclo utilizado por ASD es conocido como: especular-colaborar-aprender, el cual est dedicado
a un constante aprendizaje y colaboracin entre desarrollador y cliente.
Ciclo de vida ASD
Especulacin
1) Inicio, para determinar la misin del proyecto.

2) Fijacin del marco temporal del proyecto.
3) Determinacin de nmero de iteraciones y la duracin de cada una.
4) Definicin de objetivo de cada iteracin.
5) Asignacin de funcionalidad de cada iteracin.
96 | P g i n a
______________________________________________________________________
Una primera fase de iniciacin para establecer los principales objetivos y metas del proyecto en su
conjunto y comprender las limitaciones (zonas de riesgo) con las que operar el proyecto.
En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin embargo,
estas son necesarias para la correcta atencin de los trabajadores que se mueven dentro de plazos de
forma que puedan priorizar sus tareas. Se decide el nmero de iteraciones para consumir el proyecto,
prestando atencin a las caractersticas que pueden ser utilizadas por el cliente al final de la iteracin.
Son por tanto necesarios, marcar objetivos prioritarios dentro de las mismas iteraciones.
Estos pasos se puede volver a examinar varias veces antes de que el equipo y los clientes estn
satisfechos con el resultado.
Colaborar
Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cclica. Un
trabajo importante es la coordinacin que asegure que lo aprendido por un equipo se transmite al
resto y no tenga que volver a ser aprendido por los otros equipos.
Aprender
En cada iteracin se revisa:

Calidad del producto desde el punto de vista del cliente.
Calidad del producto desde el punto de vista de los desarrolladores.
Funcionalidad desarrollada.
Estado del proyecto
Esta ltima etapa termina con una serie de ciclos de colaboracin, su trabajo consiste en capturar
lo que se ha aprendido, tanto positivo como negativo. Es un elemento crtico para la eficacia de los
equipos.
Se identifican cuatro tipos de aprendizaje en esta etapa:
Calidad del producto desde un punto de vista del cliente: es la nica medida legtima de xito,
pero adems, dentro de las metodologas giles, los clientes tienen un valor importante.
Calidad del producto desde un punto de vista de los desarrolladores: se trata de la evaluacin
de la calidad de los productos desde un punto de vista tcnico. Ejemplos de esto incluyen la
adhesin a las normas y objetivos conforme a la arquitectura.
La gestin del rendimiento: este es un proceso de evaluacin para ver lo que se ha aprendido
mediante el empleo de los procesos utilizados por el equipo.
Situacin del proyecto: como paso previo a la planificacin de la siguiente iteracin del
proyecto, es el punto de partida para la construccin de la siguiente serie de caractersticas.
97 | P g i n a
______________________________________________________________________
Ventajas
Se utiliza para poder aprender de los errores e iniciar nuevamente el ciclo de desarrollo.
Utiliza informacin disponible acerca de todos los cambios para poder mejorar el
comportamiento del software.
Promulga la colaboracin y la interaccin de personas.
Apunta hacia el Rapid Application Development (RAD), el cual enfatiza velocidad de desarrollo
para crear un producto de alta calidad, bajo mantenimiento involucrando al usuario lo ms
posible.
Desventajas
Los errores y cambios que no son detectados con anterioridad afectan la calidad del producto
y su costo total.
Ya que esta es una metodologa gil, no permite realizar procesos que son requeridos en las
metodologas tradicionales.
5.3.7.LEAN DEVELOPMENT (LD) Y LEAN SOFTWARE DEVELOPMENT (LSD)
El desarrollo Lean es una adaptacin a los entornos de desarrollo de software, del mtodo de
produccin que desarroll Toyota, para equipos pequeos de programadores. Se fundamenta
principalmente en constituir un equipo fuerte y altamente preparado capaz de llevar a cabo cualquier
tarea en poco tiempo, legando todo a la eficacia y la cohesin de los componentes del equipo y
obviando los procesos y la burocracia que conlleva normalmente el tener un sistema de produccin
preestablecido.
La filosofa Lean consiste en tener un equipo muy preparado, altamente motivado y muy unido.
Los activos ms importantes a tener en cuenta cuando se est desarrollando un proyecto bajo Lean
Development no son el tiempo o el dinero que se est invirtiendo sino el grado de compromiso y, sobre
todo, cunto est aprendiendo el equipo. Se considera que cuanto ms hayan aprendido los miembros
del equipo y ms unidos se sientan, la cantidad de tiempo y dinero necesario para llevar a cabo los
desarrollos ser cada vez menor.
Comprendiendo esta prctica desde un punto de vista empresarial, se deber hacer una inversin
fuerte al principio para sostener a un equipo poco fogueado y trabajar en mejorar su compromiso con
la empresa y dotarles de experiencia, pero a medio plazo estos costes se reducirn y la productividad
subir, previendo a la larga un escenario en el que los costes de produccin se mantienen estables y la
productividad del equipo es extraordinaria.
Las ventajas que se derivan de tener un equipo muy slido son entonces evidentes y muy tiles en
el mundo del desarrollo de software. Se dispone de programadores que son capaces de analizar la
situacin, tomar decisiones correctas y llevarlas a cabo a una velocidad fuera de lo normal. Se puede
comenzar a desarrollar teniendo una vaga idea de cul es el objetivo final del proyecto e ir variando el
98 | P g i n a
______________________________________________________________________
rumbo a la vez que se programa, posponiendo las decisiones importantes lo ms posible a medida que
se va disponiendo de datos estadsticos sobre la aceptacin del producto que se est desarrollando.
Es un mtodo de desarrollo gil muy eficaz para proyectos a medio plazo: se concibe una idea, se
programa y se lanza un prototipo que se ofrecen a un conjunto de personas para que lo prueben y
poder analizar su comportamiento. Una vez analizado, se toman decisiones, se vara el rumbo, se
desarrolla rpidamente y se repite el anlisis con un nuevo prototipo. Despus de una serie de
iteraciones, se obtendr un producto muy definido y que ha sido diseado especficamente para
cumplir el objetivo con el que fue concebido en funcin de las opiniones de los propios clientes finales.
Principios Lean
1. Eliminar los desperdicios

2. Ampliar el aprendizaje
3. Decidir lo ms tarde posible
4. Reaccionar tan rpido como sea posible
5. Potenciar el equipo
6. Crear la integridad
7. Vase todo el conjunto
Eliminar los desperdicios
Todo lo que no aade valor al cliente se considera un desperdicio: cdigo y funcionalidades

innecesarias. Requisitos poco claros, burocracia, comunicacin interna lenta.
Con el fin de poder eliminar los desperdicios deberamos ser capaces de reconocerlos y
encontrarlos. Si alguna actividad podra ser excluida o el mismo resultado podra ser logrado sin ella,
esta actividad es considerada un desperdicio. Los procesos y funcionalidades extra que no son usados
por el cliente son desperdicios. Los gastos de gestin que no producen valor real son desperdicios. Se
utiliza una tcnica llamada Value Stream Mapping (o mapa de flujo de valor) para distinguir y reconocer
los desperdicios. El segundo paso consiste en sealar las fuentes de los desperdicios y eliminarlos. Lo
mismo debe hacerse iterativamente hasta que incluso los procesos y procedimientos que parecan
esenciales sean eliminados.
Ampliar el aprendizaje
El desarrollo de software es un proceso de aprendizaje continuo, a ello se le suman los retos de los
equipos de desarrollo y el tamao del producto final. El mejor enfoque para encarar una mejora en el
ambiente de desarrollo de software es ampliar el aprendizaje. La acumulacin de defectos debe
evitarse ejecutando las pruebas tan pronto como el cdigo est escrito en lugar de aadir ms
99 | P g i n a
______________________________________________________________________
documentacin o planificacin detallada. Las distintas ideas podran ser probadas escribiendo cdigo
e integrndolo. El proceso de recopilacin de requisitos de usuarios podra simplificarse mediante la
presentacin de las pantallas de los usuarios finales para que estos puedan hacer sus aportes. El
proceso de aprendizaje es acelerado, con el uso de iteraciones cortas, cada una de ellas acompaada
de refactorizacin y sus pruebas de integracin.
Incrementando la retroalimentacin mediante reuniones cortas con los clientes se ayuda a
determinar la fase actual de desarrollo y se ajustan los esfuerzos para introducir mejoras en el futuro.
Durante las reuniones, tanto los clientes como el equipo de desarrollo, logran aprender sobre el
alcance del problema y buscan posibles soluciones para un mejor desarrollo. Por lo tanto, los clientes
comprenden mejor sus necesidades basndose en el resultado de los esfuerzos del desarrollo y los
desarrolladores aprenden a satisfacer mejor estas necesidades.
Otra idea para ampliar el aprendizaje es a travs de la integracin del cliente en el ambiente de
desarrollo para concentrar la comunicacin en las soluciones futuras y no en las soluciones posibles,
promoviendo as el nacimiento de la solucin a travs del dilogo con el cliente.
Decidir lo ms tarde posible
El desarrollo de software est siempre asociado con cierto grado de incertidumbre, los mejores
resultados se alcanzan con un enfoque basado en opciones por lo que se pueden retrasar las decisiones
tanto como sea posible hasta que stas se basen en hechos y no en suposiciones y pronsticos
inciertos. Cuanto ms complejo es un proyecto, ms capacidad para el cambio debe incluirse en ste,
as que debe permitirse el retraso de los compromisos importantes y cruciales. El enfoque iterativo
promueve este principio: la capacidad de adaptarse a los cambios y corregir los errores, ya que un
error podra ser muy costoso si se descubre despus de la liberacin del sistema.
Un enfoque de desarrollo de software gil puede llevarles opciones rpidamente a los clientes, lo
que implica, retrasar algunas decisiones cruciales hasta que los clientes hayan reconocido mejor sus
necesidades. Esto tambin permite la adaptacin tarda a los cambios y previene las costosas
decisiones delimitadas por la tecnologa. Esto no significa que no haya planificacin involucrada en el
proceso, por el contrario, las actividades de planificacin deben centrarse en las diferentes opciones y
se les adapta a la situacin actual; as como, se deben clarificar las situaciones confusas estableciendo
las pautas para una accin rpida.
Reaccionar tan rpido como sea posible
Cuanto antes se entrega el producto final sin defectos considerables ms pronto se pueden recibir
comentarios y se incorporan en la siguiente iteracin. Cuanto ms cortas sean las iteraciones, mejor
es el aprendizaje y la comunicacin dentro del equipo. Sin velocidad, las decisiones no pueden ser
postergadas. La velocidad asegura el cumplimiento de las necesidades actuales del cliente y no lo que
ste requera para ayer. Esto les da la oportunidad de demorarse pensando lo que realmente
100 | P g i n a
______________________________________________________________________
necesitan, hasta que adquieran un mejor conocimiento. Los clientes valoran la entrega rpida de un
producto de calidad.
La ideologa de produccin Just In Time podra aplicarse a programas de desarrollo, reconociendo
sus necesidades especficas y el ambiente. Lo anterior se logra mediante la presentacin de resultados,
la necesidad de dejar que el equipo se organizarse y dividiendo las tareas para lograr el resultado
necesario para una iteracin especfica.
Al principio, el cliente dispone los requisitos necesarios. Esto podra ser simplemente presentar los
requisitos en pequeas fichas o historias y los desarrolladores estimarn el tiempo necesario para la
aplicacin de cada tarjeta. As, la organizacin del trabajo cambia en sistema autopropulsado: cada
maana durante una reunin inicial cada miembro del equipo evala lo que se ha hecho ayer, lo que
hay que hacer hoy y maana y pregunta por cualquier nueva entrada necesaria de parte de sus colegas
o del cliente. Esto requiere la transparencia del proceso, que es tambin beneficioso para la
comunicacin del equipo.
Potenciar el equipo
Una creencia errnea es la de considerar a las personas como recursos. Las personas podran ser
los recursos desde el punto de vista de una hoja de datos estadsticos, pero en el desarrollo de
software, as como cualquier organizacin de negocios, las personas necesitan algo ms que la lista de
tareas y la seguridad de que no ser alterada durante la realizacin de las tareas. Las personas
necesitan motivacin y un propsito superior para el cual trabajar, un objetivo alcanzable dentro de la
realidad con la garanta de que el equipo puede elegir sus propios compromisos. Los desarrolladores
deberan tener acceso a los clientes; el jefe de equipo debe proporcionar apoyo y ayuda en situaciones
difciles, as como asegurarse de que el escepticismo no arruine el espritu de equipo.
Crear la integridad
Una de las maneras ms saludables hacia una arquitectura integrante es la refactorizacin.

Cuantas ms funcionalidades se aaden a las del sistema, ms se pierde del cdigo base para
futuras mejoras. As como en la Programacin extrema (XP), la refactorizacin es mantener la sencillez,
la claridad, la cantidad mnima de funcionalidades en el cdigo. Las repeticiones en el cdigo son signo
de un mal diseo de cdigo y deben evitarse. El completo y automatizado proceso de construccin
debe ir acompaada de una suite completa y automatizada de pruebas, tanto para desarrolladores y
clientes que tengan la misma versin, sincronizacin y semntica que el sistema actual. Al final, la
integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el cliente
espera que haga. Las pruebas automatizadas tambin son consideradas como parte del proceso de
produccin y, por tanto, si no agregan valor deben considerarse residuos. Las pruebas automatizadas
no deberan ser un objetivo, sino, un medio para un fin; especficamente para la reduccin de defectos.
101 | P g i n a
______________________________________________________________________
Vase todo el conjunto
Los sistemas de software hoy en da no son simplemente la suma de sus partes, sino tambin el
producto de sus interacciones. Los defectos en el software tienden a acumularse durante el proceso
de desarrollo por medio de la descomposicin de las grandes tareas en pequeas tareas y de la
normalizacin de las diferentes etapas de desarrollo. Las causas reales de los defectos deben ser
encontradas y eliminadas. Cuanto ms grande sea el sistema, ms sern las organizaciones que
participan en su desarrollo y ms partes son las desarrolladas por diferentes equipos y mayor es la
importancia de tener bien definidas las relaciones entre los diferentes proveedores con el fin de
producir una buena interaccin entre los componentes del sistema.
Como se puede ver, Lean va ms all de ser un conjunto de tcnicas, hoy por hoy es una filosofa
de gestin empresarial por s misma, que promueve la comunicacin y la motivacin como base de su
aprendizaje para llevar a cabo proyectos chicos-medianos de manera exitosa.
5.3.8.PROCESO UNIFICADO DE DESARROLLO SOFTWARE
Proceso Unificado de Desarrollo (RUP) es una metodologa de desarrollo de software que est
basado en componentes e interfaces bien definidas, y junto con el Lenguaje Unificado de Modelado
(UML), constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
Es un proceso que puede especializarse para una gran variedad de sistemas de software, en
diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaos de proyecto.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas
adaptables al contexto y necesidades de cada organizacin.
Es el resultado de varios aos de desarrollo y uso prctico en el que se han unificado tcnicas de
desarrollo, a travs del UML, y trabajo de muchas metodologas utilizadas por los clientes. La versin
que se ha estandarizado vio la luz en 1998 y se conoci en sus inicios como Proceso Unificado de
Rational 5.0, de ah las siglas con las que se identifica a este proceso de desarrollo.
Principales Elementos
Como RUP es un proceso, en su modelacin define como sus principales elementos:

Trabajadores: define el comportamiento y responsabilidades (rol) de un individuo, grupo
de individuos, sistema automatizado o mquina, que trabajan en conjunto como un
equipo. Ellos realizan las actividades y son propietarios de elementos.
Actividades: es una tarea que tiene un propsito claro, es realizada por un trabajador y
manipula elementos.
102 | P g i n a
______________________________________________________________________
Artefactos: productos tangibles del proyecto que son producidos, modificados y usados
por las actividades. Pueden ser modelos, elementos dentro del modelo, cdigo fuente y
ejecutables.
Flujo de actividades: secuencia de actividades realizadas por trabajadores y que produce
un resultado de valor observable.
Caractersticas Principales de RUP
Unifica los mejores elementos de metodologas anteriores.

Preparado para desarrollar grandes y complejos proyectos.
Orientado a Objetos.
Utiliza el UML como lenguaje de representacin visual.
Principales ventajas:
Coste del riesgo a un solo incremento.

Reduce el riesgo de no sacar el producto en el calendario previsto.
Acelera el ritmo de desarrollo.
Se adapta mejor a las necesidades del cliente.
Caractersticas del ciclo de vida de RUP
Dirigido por casos de uso
Los casos de uso reflejan lo que los usuarios futuros necesitan y desean, lo cual se capta cuando
se modela el negocio y se representa a travs de los requerimientos. A partir de aqu los casos de uso
guan el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes
flujos de trabajo, representan la realizacin de los casos de uso (cmo se llevan a cabo).
Centrado en la arquitectura
La arquitectura muestra la visin comn del sistema completo en la que el equipo de proyecto y
los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son ms
importantes para su construccin, los cimientos del sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo econmicamente. RUP se desarrolla mediante iteraciones,
comenzando por los casos de uso relevantes desde el punto de vista de la arquitectura. El modelo de
arquitectura se representa a travs de vistas en las que se incluyen los diagramas de UML.
103 | P g i n a
______________________________________________________________________
Iterativo e Incremental
Una iteracin involucra actividades de todos los flujos de trabajo, aunque desarrolla
fundamentalmente algunos ms que otros.
Por ejemplo, una iteracin de elaboracin centra su atencin en el anlisis y diseo, aunque refina
los requerimientos y obtiene un producto con un determinado nivel, pero que ir creciendo
incrementalmente en cada iteracin.
Es prctico dividir el trabajo en partes ms pequeas o miniproyectos. Cada miniproyecto es una
iteracin que resulta en un incremento. Las iteraciones hacen referencia a pasos en los flujos de
trabajo, y los incrementos, al crecimiento del producto. Cada iteracin se realiza de forma planificada
es por eso que se dice que son miniproyectos.
Flujo y fases de trabajo de RUP
Cada fase representa un ciclo de desarrollo en la vida de un producto de software.

La fase de concepcin o inicio tiene por finalidad definir la visin, los objetivos y el alcance del
proyecto, tanto desde el punto de vista funcional como del tcnico, obtenindose como uno de los
principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto.
El principal esfuerzo est radicado en el Modelamiento del Negocio y el Anlisis de
Requerimientos. Es la nica fase que no necesariamente culmina con una versin ejecutable.
La fase de elaboracin tiene como principal finalidad completar el anlisis de los casos de uso y
definir la arquitectura del sistema, adems se obtiene una aplicacin ejecutable que responde a los
casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema,
las decisiones sobre la arquitectura se hacen sobre la base de la comprensin del sistema completo y
los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido. La fase
de construccin est compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando
sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto.
Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que
satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el
inicio de la prxima iteracin.
La fase de transicin se inicia con una versin de prueba (beta) del sistema y culmina con el
sistema en fase de produccin.
En RUP se han agrupado las actividades en grupos lgicos definindose 9 flujos de trabajo
principales, los 6 primeros son conocidos como flujos de ingeniera y los tres ltimos como flujos de
apoyo.
Modelo del Negocio: describe los procesos de negocio, identificando quines participan y las
actividades que requieren automatizacin.
Requerimiento: define qu es lo que el sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se imponen.
104 | P g i n a
______________________________________________________________________
Anlisis y Diseo: describe cmo el sistema ser realizado a partir de la funcionalidad prevista
y las restricciones impuestas (requerimientos), por lo que indica con precisin lo que se debe
programar.
Implementacin: define cmo se organizan las clases y objetos en componentes, cules nodos
se utilizarn y la ubicacin en ellos de los componentes y la estructura de capas de la
aplicacin.
Prueba (Testing): busca los defectos a lo largo del ciclo de vida.
Instalacin: el sistema se pone en marcha en produccin (se libera al cliente y usuario final) y
se realizan actividades (empaque, instalacin, asistencia a usuarios, etc.) para entregar el
software a los usuarios finales.
Administracin del proyecto: involucra actividades con las que se busca producir un producto
que satisfaga las necesidades de los clientes.
Administracin de configuracin y cambios: describe cmo controlar los elementos producidos
por todos los integrantes del equipo de proyecto en cuanto a utilizacin/actualizacin
concurrente de elementos, control de versiones, etc.
Ambiente: contiene actividades que describen los procesos y herramientas que soportarn el
equipo de trabajo del proyecto; as como el procedimiento para implementar el proceso en
una organizacin.
Diferencias de RUP con las dems metodologas
Algunos aspectos que diferencian a RUP de las dems metodologas y lo que lo hace nico es que
en RUP, los casos de uso no son slo una herramienta para especificar los requisitos del sistema, sino
que tambin guan su diseo, implementacin y prueba. Los casos de uso constituyen un elemento
integrador y una gua del trabajo.
Adems de utilizar los casos de uso para guiar el proceso, se presta especial atencin al
establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante
cambios posteriores durante la construccin y el mantenimiento. Tambin este propone que cada fase
se desarrolle en iteraciones.
105 | P g i n a
______________________________________________________________________
6. ESTUDIO Y ANALISIS DE CASOS REALES
6.1. CASOS DE XITO
1. Tantus Technologies, Inc.
Cmo hace una organizacin para implementar algo que nunca ha desarrollado antes, para un
cliente que nunca lo ha utilizado anteriormente, para miembros de un equipo sin experiencia alguna y
para usuarios finales que nunca la haban sentido nombrar?. Esa es la pregunta que se plante Scott
Granieri, proyect manager de la empresa Tantus Technologies, cuando se dispusieron a explorar como
hacerle frente a un determinado componente del plan estratgico de un cliente federal. El siguiente
documento detalla la experiencia interna de cmo se implement Agile, sin contratar personal
capacitado en esta nueva metodologa y como se capacito al personal, clientes y usuarios finales
debido a las limitaciones presupuestarias.
El cliente, en 2011, decidi incorporar Agile como metodologa de trabajo debido a las tendencias
de la industria y del sector, tanto pblico como privado, en ese momento.
Las empresas de productos, as como los proveedores de servicios estaban adoptando esta nueva
metodologa de trabajo de manera exponencial, incluso las empresas de desarrollo de software ms
tradicionales, haban reconocido este movimiento metodolgico que sacuda la industria del software.
Para Tantus Technologies, el desafo de implementar un enfoque gil sobre el programa actual, era
complejo. Se enfrentaban a numerosos obstculos al intentar ayudar al cliente a alcanzar el objetivo
estratgico de incorporar un desarrollo gil de software.
La implementacin de prcticas agiles y la creacin de una cultura gil fue un gran desafo para la
organizacin; sin embargo se identificaron las tres categoras especficas de los desafos que tuvieron
que superar para lograr el xito: organizacin, cultural y personal.
Retos organizacionales
El programa federal, es una organizacin altamente matricial, soportando ms de 23 sistemas, con

ms de 80 miembros entre los equipos, realizando ambas operaciones y trabajos de mantenimiento a
lo largo de mejoras proyectadas. El nmero de proyectos por ao, oscilaba histricamente entre 50 y
70. Debido al gran nmero de proyectos y al conjunto de habilidades diversas necesarias para apoyar
a todos los distintos sistemas, se identificaron de 5 a 7 miembros por equipo multifuncional. Este reto,
era importante, porque uno de los factores claves para el xito de la implementacin de una
metodologia gil era tener todos los miembros de los equipos dedicados completamente a este nuevo
trabajo. Equipos estables y dedicados ayudan a construir cohesin conjuntamente como a su vez
tambin, aprenden a entender el producto, su metodologia y a sus compaeros de trabajo. Esta
estabilidad conduce a realizar una estimacin del esfuerzo mucho ms precisa. La estimacin de la
productividad del equipo, medida en puntos de la historia, se volva ms confiables con cada iteracin.
106 | P g i n a
______________________________________________________________________
Retos culturales
Se puso en marcha la implementacin de una metodologia gil sobre una organizacin con una
larga historia de desarrollo en casada. El programa haba madurado los procesos a lo largo de los aos,
tomando un gran esfuerzo para lograr CMMI y la impresa en el equipo de una cultura de xito a travs
de la conformidad con los procesos. Muchas de las lecciones aprendidas de las victorias del pasando,
deberan ser desafiadas y/o reemplazadas por un nuevo entorno de trabajo gil que incluira lo
siguiente:
La adopcin de tcnicas de programacin y el costo de estimacin gil
En un entorno gil, el tringulo tradicional de prioridades est a la inversa. Lo que una vez fue fijo
(alcance) se convierte en una variable, y las que eran tradicionalmente variables (recursos y tiempo)
se convierten en fijos. Cuando se empez a desarrollar la capacidad gil, no se saba cmo el equipo
lder de programacin iba a reaccionar a este nuevo enfoque de estimacin, especialmente despus
de poner tanto esfuerzo en crear sistemas para identificar y gestionar los horarios y los sobre costos.
Gestin vs liderazgo
Gran parte de la cultura y la estructura organizativa del sistema federal fue construido sobre
cimientos de la visin tradicional de cascada para la gestin de proyectos. Al igual que al reto sobre la
gestin de los horarios y al costo de estimacin, no se saba cmo esta cultura altamente estructurada
y tradicional se adaptara a la naturaleza ms dinmica de requerimientos, diseos y productos de
trabajo final producidos en un ambiente gil. Equipos autodirigidos y un entorno de constante cambio
eran conceptos extraos y potencialmente riesgosos para la jerarqua de la organizacin.
Desafos del personal
Tanto el personal de trabajo de la compaa como el personal del cliente, mostraban una escasez
de conocimientos en un entorno gil, lo que dificultaba el xito a tiempo del proyecto. Debido a esto,
en su momento se pens en contratar personal capacitado para poder enfrentar estos problemas de
experiencia, pero debido a limitaciones presupuestarias, se descartaron dichas opciones.
CMMI: Capability Maturity Model Integration es un modelo para la mejora y evaluacin de procesos para el desarrollo,
mantenimiento y operacin de sistemas de software.
107 | P g i n a
______________________________________________________________________
La solucin
En apoyo para el objetivo estratgico de una implementacin gil, se desarroll y ejecuto un plan
de accin gil. Los componentes claves fueron los siguientes:
Evaluacin y seleccin de un entorno de trabajo gil. Luego de este proceso, Tantus

Technologies se decidi por implementar Scrum.
Se envi parte del personal a capacitar para formar Scrum Masters certificados.
Se incorpor un recurso externo con conocimiento en Scrum para realizar capacitaciones y
demostrar al cliente la metodologia gil y sus beneficios
El desarrollo de una visin general de formacin para los nuevos clientes para educarlos acerca
de su papel como dueos del producto (product owner)
Creacin de un ciclo de vida de desarrollo de software gil incluyendo herramientas, plantillas
y tcnicas para el desarrollo y la entrega.
La identificacin del conjunto de Sprints a ejecutar durante el ciclo de vida del proyecto
Luego de un largo y duro ao de aprendizaje, el proyecto se pudo llevar a cabo con xito.
Lecciones aprendidas
Los principales resultados y factores claves de xito derivados de la experiencia que tuvo Tantus
Technologies son los siguientes:
Un Product Owner autorizado y disponible es clave: cuando un equipo de desarrollo puede

contar y trabajar con un cliente interno totalmente dedicado, centrado y confiado en su equipo
es parte de la clave del xito.
Un personal dedicado en el tiempo es de suma importancia: cuando las personas de un
proyecto entran y salen de los equipos, genera un efecto negativo en el mismo y puede afectar
drsticamente al proyecto y las dems reas. Es por esto que es altamente recomendable que
los equipos de trabajo se mantengan estticos en el tiempo para poder aprovechar al mximo
las experiencias logradas.
Respetar los tiempos: es normal de cualquier proyecto, que se quieran agregar ms
funcionalidades en iguales tiempos o incluso ms cortos. En cambio, mas Sprints, significan
entregas ms pequeas, reduciendo el riesgo y permitiendo al equipo a aprender ms
rpidamente y lograr los objetivos con un porcentaje muy bajo de fracaso. Para esto es
necesario resistirse a la tentacin de sobrecargar los sprints con ms user stories.
Desarrollar constantemente el Product Backlog: en Scrum se recomienda que el 5 o 10 por
ciento de cada sprint se dedicase a la refinacin del product backlog ya que es un componente
sumamente importante para la recoleccin de requisitos e informacin.
Herramientas automatizadas para la gestin del proyecto: Tantus Technologies se decidi por
adoptar la herramienta de gestin JIRA. Esta permite la gestin de las user stories, la carga de
errores, estimaciones, priorizacin, asignacin de tareas y seguimiento del trabajo.
108 | P g i n a
______________________________________________________________________
Es cierto que el punto principal de aplicar una metodologia gil consiste en eliminar las
herramientas burocrticas de trabajo e implementar la comunicacin entre las personas del equipo
pero, sin embargo, siempre es necesario una herramienta de gestin de este tipo.
2. Spotify
Existen muchsimas compaas que desarrollan software de una forma gil y exitosa. Google, por
ejemplo, cuenta con 15.000 desarrolladores trabajando en una rama del cdigo. Lanzan cambios varias
veces al da y realizan 75 millones de tests automticos diariamente.
Una empresa que ha sabido adaptarse perfectamente a las metodologas giles es Spotify, haciendo
especial hincapi en la figura del Scrum Master. Muchas veces contratan un Agile Coach externo con
una gran experiencia en el campo para liderar los proyectos. Vemos aqu la importancia de contar con
roles especializados que conozcan las metodologas giles para llevar un proyecto de este tipo al xito.
Ya no solo el Scrum Master, sino tambin otros roles como el Product Owner, responsable de entender
al cliente y al usuario para saber trasladar en tiempo y forma la informacin adecuada al equipo de
desarrollo.
Spotify es consciente de la metodologa de trabajo de su competencia (Google o Apple por
ejemplo), por lo que decidieron acercarse al Scrum de forma muy sistemtica. Compitiendo contra
semejantes corporaciones, saban que en cualquier momento podran ser derrotados a menos que
fuesen ms rpidos, ms baratos y mejores.
En Spotify los equipos se organizan por escuadrones (squads), pequeos equipos de Scrum con la
habilidad de implementar el software desarrollado al final de cada sprint, sin romper ningn otro
equipo. Una caracterstica curiosa del funcionamiento de Spotify es que cada uno de estos pequeos
grupos tiene una parte del producto que es totalmente suyo. Despus crean tribus (tribes) agregando
distintos escuadrones.
Aun as, Spotify necesita implementar, cambiar y actualizar su cdigo constantemente sin romper
nada ms. Para ello es necesaria una buena coordinacin central de la compaa.
Para ser rpido tambin es necesario deshacerse de todas aquellas partes del proceso que
entorpezcan el avance. En Spotify, por ejemplo, contaban con un equipo de operaciones que se
encargada de las implementaciones, pero el funcionamiento era demasiado lento. Por eso
decidieron eliminar esta fase y hacer que los propios desarrolladores implementasen sus trabajos.
Cada vez son ms las empresas que operan en el mundo digital y necesitan optimizar sus procesos
al mximo para asegurarse la primera posicin en el mercado. Es por ello que las metodologas giles
como el Scrum estn adquiriendo una importancia especial dentro de las organizaciones y los
profesionales especializados en la gestin de este tipo de proyectos son cada vez ms demandados.
109 | P g i n a
______________________________________________________________________
6.2. CASOS DE FRACASO
1. Healthcare
Healthcare es un proyecto del gobierno americano diseado para ofrecer toda la informacin y
transparencia sobre el mercado de los seguros sanitarios, para que los consumidores puedan
asegurarse de obtener el mejor valor. Jeff Sutherland, cocreador de Scrum, lo cita como ejemplo de
mala gestin de un proyecto Scrum.
Las principales causas del fracaso en el desarrollo de Healthcare fueron la falta de coordinacin
entre el Front End y el Back End, la falta de liderazgo en un proyecto con ms de 20 consultoras
implicadas y no haber lanzado el proyecto fase a fase sin testeo ni aprendizaje de por medio, haciendo
que fuese imposible detectar las fases que s funcionaban y las que no.
Segn Jeff Sutherlands, el fracaso de este proyecto no debera sorprendernos tanto ya que se trata
de un proyecto de desarrollo en cascada, y afirma que el 86% de este tipo de proyectos suelen acabar
en fracaso.
Tras trabajar en el desarrollo durante varios aos, slo se tuvieron seis das para testear la
aplicacin debido a las presiones para el inminente lanzamiento. Es de entender que con tan corto
periodo de testing el proyecto no saliese bien lo que provoco que, aunque el equipo del Back End
realmente trabaj como un proyecto gil y en unos meses ya haban terminado su trabajo, el error
estuvo en no respetar el segundo principio del manifiesto Agile de aceptacin del cambio: Aceptamos
que los requisitos cambien, incluso en etapas tardas del desarrollo. Los procesos giles aprovechan el
cambio para proporcionar ventaja competitiva al cliente. Por ms que se haya logrado el desarrollo,
no alcanz para su funcionamiento.
110 | P g i n a
______________________________________________________________________
7. CONCLUSION
Hoy en da la comunicacin, la tecnologa y los sistemas de informacin avanzan y evolucionan a

una velocidad exponencial generando consigo que la gestin de proyectos informticos est a la altura
de la velocidad de los cambios ocasionados por esta evolucin.
El mundo del desarrollo del software ha cambiado drsticamente desde la aparicin de internet y
la gran cantidad de herramientas que nos permiten crear ecosistemas de trabajo mucho ms
colaborativos en los que el flujo de informacin es mucho ms rpido que con las estructuras
tradicionales.
En esta nueva generacin, las metodologas tradicionales de desarrollo de software fueron
quedado obsoletas en determinados sectores, en los que la propia demanda de los usuarios es ms
rpida que la capacidad de produccin de las empresas ancladas a las viejas metodologas de gestin
de proyectos de sistemas informticos.
Este gran impacto en las tecnologas, ha generado la necesidad de encontrar y crear nuevas
metodologas de trabajo y gestin, que aseguren la entrega en tiempo y forma del producto. Esta
necesidad de calidad, eficiencia, flexibilidad y rapidez en la entrega de un producto informtico se
volvi prioridad y en conjunto con su necesidad se crearon las nombradas Metodologas Agiles.
El mundo en general y la vida de las personas, da a da se vuelve ms gil en todos sus aspectos,
siendo prcticamente inevitable la evolucin en los sistemas de informacin para poder atacar sta
demanda.
Los mtodos giles y los tradicionales no son competidores directos. Cada uno de ellos tiene su
propio segmento de aplicacin o terreno en base a las necesidades del proyecto y de bien saber
distinguir e identificar cual es la ms adecuada en base a las caractersticas de nuestro proyecto,
necesidades y recursos.
Algunos aspectos del desarrollo de software se beneficiarn del enfoque agilista mientras otros
obtendrn beneficios de un enfoque tradicional-predictivo menos gil y ms estructurado.
Ambos metodologas, pueden fracasar si son mal implementadas, gestionadas y administradas.
No podemos decir que exista una metodologa mejor que otra sino que depender de la naturaleza
de la empresa y la forma de organizacin de sus procesos internos y de la capacidad de los lderes del
proyecto de poder identificar la metodologa que ms se adecua e implementarla de manera eficiente.
Sin embargo, la tendencia natural actual indica que las metodologas agiles estn ganando terreno
muy rpidamente lo que en algunos aos podran generar la extincin definitiva de las metodologas
tradicionales.
111 | P g i n a
______________________________________________________________________
8. REFERENCIAS BIBLIOGRAFICAS
Amador Duran Toro, Beatriz Bernrdez Jimnez, Metodologa para el anlisis de de requisitos
de sistemas de software versin 2.2, Universidad de Sevilla, departamento de Lenguajes y
Sistemas informticos, escuela Tcnica superior de Ingeniera Informtica, Diciembre de 2001.
Roger S.Pressman. Ingeniera del Software: un enfoque prctico, de segunda edicin,
Editorial McGraw Hill. 1990.
Manuel Daz Rodrguez, Antonio Moa Gmez, Ingeniera de Software Especificacin,
Departamento de Lenguajes de Ciencias de la computacin, Universidad de Mlaga.
Bruce I. Blum, Software Engineering: A Holistic View.
Dorothy Graham, Erik Van Veenendaal, Isabel Evans y Rex Black, Foundations of Software
Testing - ISTQB Certification. 2007.
Duvall, Paul M., Continuous Integration. Improving Software Quality and Reducing Risk.
2007.
Hans Van Vliet, Software Engineering. Principles and Practice. Tercera edicin. 2002.
Ian Sommerville, Software Engineering. Sexta Edicin. 2001.
Ivar Jacobson, Grady Booch y James Rumbaugh, The Unified Software Development Process.
1999.
Kent Beck, Test-Driven Development by Example.
Kent Beck, Martin Fowler, Planning Extreme Programming. 2000.
Ken Schwaber, Mike Beedle, Agile Software Development with SCRUM. 2008.
Lawrence-Pfleeger y Shari, Software Engineering: Theory and Practice. 1998.
Mitchel H. Levine, Analyzing the Deliverables Produced in the Software Development Life
Cycle. 2000.
Pierre Bourque y Robert Dupuis, Guide to the Software Engineering Body of Knowledge.
2004.
Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices.
Roger S. Pressman, Software Engineering. A practitioners Approach. Quinta Edicin. 2001.
Ron Burback, Software Engineering Methodology. 1998.
Tong Ka lok, Kent, Essential Skills for Agile Development.
Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley. 2000.
Beck, K. Martin F. Planning Extreme Programming. Boston: Addison-Wesley. 2001.
Cans, J. H.; Letelier, P.; Penads, M. C. Metodologas giles en el desarrollo del software.
Valencia: Universidad de Valencia. 2004.
Cockburn, A. Agile Software Development. Boston: Addison-Wesley. 2001.
Cronin, G. Extreme Solo: A Case Study in Single Developer extreme Programming.
University of Auckland. 2003.
Highsmith, J. Agile Software Development Ecosystems. Boston: Addison-Wesley. 2002.
Reynoso, C. Mtodos heterodoxos en desarrollo del software. Buenos Aires: Universidad
de Buenos Aires. 2004.
112 | P g i n a
______________________________________________________________________
Salo, J. H.; Abrahamson, P.; Ronkainen, J.; Warsta, J. Agile Software Development. 2002.
Schwaber, K.; Beedle, M. Agile Software Development with Scrum. Nueva Jersey: Prentice
Hall. 2002.
Wake, W. C. Extreme Programming Explored. Boston: Addison-Wesley. 2002.
Boehm, Barry W., A Spiral Model of Software Development and Enhancement, IEEE
Computer, Vol.21, No 15, pp.61-72. Mayo 1988.
Martin, J., Rapid Application Development, Macmillan Inc., New York. 1991.
Beck, Kent, Extreme Programming Explained, Addison-Wesley the XP Series, 2000.
Alistair Cockburn. Balancing Lightness with Sufficiency. Septiembre 2000.
Prez S. Jess, Metodologas giles: La ventaja competitiva de estar preparado para tomar
decisiones lo ms tarde posible y cambiarlas en cualquier momento. Artculo de Agile Spain.
Grupo ISSI, Metodologas giles en el Desarrollo de Software, Artculo de Grupo ISSI
Noviembre 2003.
Acebal F.Csar, Cueva L. Juan, EXtreme Programming (XP): un nuevo mtodo de desarrollo
de software, Articulo de Novtica.
Letelier P., Penads C., Metodologas giles para el desarrollo de Software: eXtreme
Programming (XP), Universidad Politcnica de Valencia.
Shenone M. Hernn, Diseo de una metodologa gil de Desarrollo de Software, Tesis de
Grado en Ingeniera en Informtica, Universidad de Buenos Aires.
Pgina de Microsoft: MSDN en Espaol, Mtodos Heterodoxos en Desarrollo de Software,
Artculo de Carlos Reynoso Universidad de Buenos Aires, Abril del 2004.
113 | P g i n a
______________________________________________________________________
Sitios web
http://www.agile-spain.com
http://www.agilealliance.org
http://www.ieee.org/portal/site
http://www.agilemanifesto.org
Sitio web de la Organizacin Internacional para la Estandarizacin www.iso.org
http://www.swebok.org
http://www.rena.edu.ve/cuartaEtapa/Informatica/Tema11.html
http://www.inf-cr.uclm.es/www/mpolo/asig/0708/phd/apuntesDoctorado.pdf
http://audiemangt.blogspot.mx/2010/04/metodologia-clasica-en-cascada.html
http://www.agiles.org/agiles-parana
http://www.proyectosagiles.org/
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html
http://leansoftwareengineering.com/
http://www.projectperfect.com.au/downloads/Info/info_lean_development.pdf
http://www.poppendieck.com/
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
http://www.agileshift.cl/Tutorial/DesarrolloAgilParte2.pdf
http://www.willydev.net/descargas/prev/TodoAgil.pdf
http://ingenieriadesoftware.mex.tl/61162_FDD.html
https://agilidaddeldesarrollo.wordpress.com/2012/12/02/adaptive-software-development-
asd/
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/heterodox.asp#12
http://www.enterprisexp.org
http://www.dsdm.org
https://www.scrumalliance.org/community/articles/2013/november/success-story-
sometimes-it-just-may-take-a-waterfa
http://comunidad.iebschool.com/iebs/agile-scrum/exitos-y-fracasos-en-proyectos-scrum-
spotify-vs-healthcare/
114 | P g i n a
______________________________________________________________________
9. APENDICE
Figura N 1 Extrada de:

[http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf]

[http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf]

[https://www.academia.edu/13247296/MONOGRAFIA_SOBRE_LA_METODOLOGIA_DE_DESARR
OLLO_DE_SOFTWARE_RUP]
Figura N 4 Extrada de: [http://cflores334.blogspot.es/1192848180/]
Figura N 5 Extrada de: [http://andres-modelosdedesarrollo.blogspot.com.ar/]
Figura N 6 Extrada de: [http://xherrera334.blogspot.es/]
Figura N 7 Extrada de: [http://www.testingexcellence.com/rapid-application-development-rad/]

[https://www.exabyteinformatica.com/uoc/Informatica/Tecnicas_avanzadas_de_ingenieria_de_
software/Tecnicas_avanzadas_de_ingenieria_de_software_(Modulo_3).pdf]




115 | P g i n a
______________________________________________________________________

Figura N 14 Extrada de: [http://bytelchus.com/tableros-kanban/]
Figura N 15 Extrada de: [http://paradigmas14.blogspot.com.ar/p/metodologias-agiles.html]
Figura N 16 Extrada de: [http://www.michalwolski.pl/2014/09/kanban-i-wykrywanie-waskich-

gardel/].
116 | P g i n a

Metodologias Desarrollo Software

Cargado por

Información del documentohacer clic para expandir la información del documentoPDF

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Metodologias Desarrollo Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologias Desarrollo Software

Cargado por

Copyright:

Formatos disponibles

Maida, Esteban Gabriel ; Pacienzia, Julin

Metodologas de desarrollo de software

Tesis de Licenciatura en Sistemas y Computacin

Cmo citar el documento:

PONTIFICIA UNIVERSIDAD CATLICA ARGENTINA SANTA MARIA DE LOS BUENOS AIRES

Maida, Esteban Gabriel

La presente Tesis es un esfuerzo en el cual, directa o indirectamente, participaron varias

1.1. DEFINICION DEL PROBLEMA

2.1. DEFINICION DE INGENIERIA

6. ESTUDIO Y ANALISIS DE CASOS REALES

6.1. CASOS DE EXITO

1.1. DEFINICION DEL PROBLEMA

1.2. PROPOSITO DE LA INVESTIGACION

1.3. OBJETIVOS GENERALES

La seleccin y aplicacin de una metodologa particular para el desarrollo de software, se centra

2.1. DEFINICION DE INGENIERIA

La ingeniera es el conjunto de conocimientos y tcnicas, cientficas aplicadas al desarrollo,

El software es el equipamiento lgico e intangible de un sistema informtico, que comprende el

Procedimientos y herramientas: apoyo a la realizacin de cada tarea.

El marco de trabajo de una metodologa de desarrollo de software consiste en:

2.2.2. IMPORTANCIA DEL SOFTWARE

2.2.3. PROBLEMAS DEL SOFTWARE

La planificacin y estimacin de costos frecuentemente son imprecisas.

No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software.

Los problemas anteriores son solucionables, dndoles un enfoque de ingeniera al desarrollo de

2.2.4. CARACTERISTICAS BASICAS

El software se desarrolla, no se fabrica en un sentido clsico.

Figura N 1 Comparacin de ndices de fallas entre hardware y software.

El software pude clasificarse en tres grandes grupos:

Software de programacin: Es el conjunto de herramientas que permiten

2.3. QUE ES LA INGENIERIA DE SOFTWARE

Algunas definiciones, dadas a travs del tiempo son:

2.4. QUE ES UNA METODOLOGIA Y PARA QUE SE UTILIZA

La metodologa hace referencia al conjunto de procedimientos racionales utilizados para alcanzar

2.5. METODOLOGIA TRADICIONAL

Desarrollar un buen software depende de un gran nmero de actividades y etapas, donde el

2.6. METODOLOGIAS AGILES

2.7. DIFERENCIAS ENTRE METODOLOGIA TRADICIONAL Y AGIL

Tabla N 1 Comparacin entre Metodologa gil y Tradicional

Especialmente preparados para cambios Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Impuestas externamente

Proceso menos controlado, con pocos Proceso mucho ms controlado, con

No existe contrato tradicional o al menos es Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de

Grupos pequeos (<10 integrantes) y Grupos grandes y posiblemente distribuidos

Pocos artefactos Ms artefactos

Pocos roles Ms roles

Menos nfasis en la arquitectura del software La arquitectura del software es esencial y se

Poca documentacin Documentacin exhaustiva

2.8. PARADIGMAS DE LA INGENIERIA DEL SOFTWARE

Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas, que

Existen tres categoras de paradigmas de programacin:

a. Solucin procedimental u operacional. Describe etapa a etapa el modo de construir la solucin.

Los objetivos principales de la ingeniera de software son los siguientes:

Identificar las principales metodologas disponibles para la recoleccin y manejo de

Haz de la calidad la razn de trabajar.

3.3. DISTRIBUCION DEL ESFUERZO EN UN PROYECTO DE SOFTWARE

Figura N 2 Distribucin porcentual del esfuerzo de un proyecto de software.