Principios de desarrollo de la Metodologa RUP

El RUP est basado en 6 principios clave que

son
los siguientes:

Adaptar el proceso

El proceso deber adaptarse a las necesidades del cliente ya que es muy importante
interactuar con l. Las caractersticas propias del proyecto u organizacin. El tamao del
mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo
especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o

disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de
todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se
refina la direccin del proyecto as como tambin los riesgos involucrados

Colaboracin entre equipos

El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber
una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes,
resultados, etc.

Elevar el nivel de abstraccin

Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del
software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto
evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de
software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor
 manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del
cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y
soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos
de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no
de un grupo independiente.

METODOLOGIA RUP
Editar 1 69

METODOLOGA PURA

Es una metodologa cuyo fin es entregar un producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML,
constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada
organizacin.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos
para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.

Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software.
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software

En est metodologia lo que se pretende es el desarrollo de un software, en el cual se aplicara

el PSP y el CMMI en todos sus fases, que esten en la realizacion de los procesos

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo
fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una
persona puede desempear distintos roles a lo largo del proceso).

CICLO DE VIDA . PON EN ESPAOL

Esfuerzo en actividades segn fase del proyecto

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las
distintas actividades.

Fases del ciclo de vida del RUP:

1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con
los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores.

2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que

permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema,
se disea la solucin preliminar.

3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,

para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

4. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para
los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin,
capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el
producto cumpla con las especificaciones entregadas por las personas involucradas en el
proyecto.
 La metodologa RUP tiene 6 principios clave:

1. Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la organizacin

para la que se est desarrollando el software.

2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores
del proyecto.

3. Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma
interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del producto y
analizar la opinin y sugerencias de los inversores .

5. Elevar el nivel de abstraccin: Motivar el uso de de conceptos reutilizables.

6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la

produccin.

Disciplina de desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para el
cual se est desarrollando el software.
Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.
Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema
automatizado y desarrollar una arquitectura para el sistema.
Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el
comportamiento deseado.
Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado
est presente.
Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

Disciplina de soporte RUP

Determina la documentacin que es necesaria realizar durante el proyecto.
 Configuracin y administracin del cambio: Guardar todas las versiones del proyecto.
Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear.
Ambiente: Administrar el ambiente de desarrollo del software.
Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.

Trabajadores: Personas involucradas en cada actividad del proyecto.
Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un documento,
un modelo, un elemento del modelo.

Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de
artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre
otros). Estos artefactos (entre otros) son los siguientes:

Inicio:

Documento Visin
Especificacin de Requerimientos

Elaboracin:

Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LOGICA:

Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)

VISTA DE IMPLEMENTACION:

Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
 VISTA CONCEPTUAL

Modelo de dominio

VISTA FISICA

Mapa de comportamiento a nivel de hardware

Metodologa Scrum
Qu es?

Scrum es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversin para su empresa (ROI). Se basa en
construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspeccin continua, adaptacin, auto-gestin e innovacin.

Cundo se utiliza?

Con la metodologa Scrum el cliente se entusiasma y se compromete con el proyecto dado

que lo ve crecer iteracin a iteracin. Asimismo le permite en cualquier momento realinear
el software con los objetivos de negocio de su empresa, ya que puede introducir cambios
funcionales o de prioridad en el inicio de cada nueva iteracin sin ningn problema.

Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del equipo que
 forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para
desarrollar sus capacidades.

Beneficios

Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que

le aporta cada requisito / historia del proyecto, el equipo los estima y con esta informacin
el Product Owner establece su prioridad. De manera regular, en las demos de Sprint
el Product Owner comprueba que efectivamente los requisitos se han cumplido y
transmite se feedback al equipo.
Flexibilidad a cambios: Alta capacidad de reaccin ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodologa est
diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
Reduccin del Time to Market: El cliente puede empezar a utilizar las funcionalidades ms
importantes del proyecto antes de que est finalizado por completo.
Mayor calidad del software: La metdica de trabajo y la necesidad de obtener una versin
funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad
superior.
Mayor productividad: Se consigue entre otras razones, gracias a la eliminacin de la
burocracia y a la motivacin del equipo que proporciona el hecho de que sean autnomos
para organizarse.
Maximiza el retorno de la inversin (ROI): Produccin de software nicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de
inversin.
Predicciones de tiempos: Mediante esta metodologa se conoce la velocidad media del
equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible
estimar fcilmente para cuando se dispondr de una determinada funcionalidad que
todava est en el Backlog.
Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de ms valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.

Proceso y Roles de Scrum

El proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteracin,

denominada Sprint, tiene una duracin preestablecida de entre 2 y 4 semanas, obteniendo
como resultado una versin del software con nuevas prestaciones listas para ser usadas. En
 cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se aaden nuevas
prestaciones priorizndose siempre aquellas que aporten mayor valor de negocio.

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje

no tcnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de
inversin considerando su beneficio y coste. Los requisitos y prioridades se revisan y
ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning: Reunin durante la cual el Product Owner presenta las historias del
backlog por orden de prioridad. El equipo determina la cantidad de historias que puede
comprometerse a completar en ese sprint, para en una segunda parte de la reunin, decidir
y organizar cmo lo va a conseguir.
Sprint: Iteracin de duracin prefijada durante la cual el equipo trabaja para convertir
las historias del Product Backlog a las que se ha comprometido, en una nueva versin del
software totalmente operativo.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.
Daily sprint meeting: Reunin diaria de cmo mximo 15 min. en la que el equipo se
sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el da
anterior, que har hoy y si hay impedimentos.
Demo y retrospectiva: Reunin que se celebra al final del sprint y en la que el equipo
presenta las historias conseguidas mediante una demonstracin del producto.
Posteriormente, en la retrospectiva, el equipo analiza qu se hizo bien, qu procesos seran
mejorables y discute acerca de cmo perfeccionarlos.

Roles

En Scrum, el equipo se focaliza en construir software de calidad. La gestin de un proyecto

Scrum se centra en definir cules son las caractersticas que debe tener el producto a construir
 (qu construir, qu no y en qu orden) y en vencer cualquier obstculo que pudiera
entorpecer la tarea del equipo de desarrollo.

El equipo Scrum est formado por los siguientes roles:

Scrum master: Persona que lidera al

equipo guindolo para que cumpla las
reglas y procesos de la metodologa.
Gestiona la reduccin de impedimentos
del proyecto y trabaja con el Product
Ownerpara maximizar el ROI.
Product owner (PO): Representante de
lso accionistas y clientes que usan el
software. Se focaliza en la parte de
negocio y el es responsable del ROI del
proyecto (entregar un valor superior al
dinero invertido). Traslada la visin del
proyecto al equipo, formaliza las
prestaciones en historias a incorporar en
el Product Backlog y las reprioriza de
forma regular.
Team: Grupo de profesionales con los
conocimientos tcnicos necesarios y que
desarrollan el proyecto de manera
conjunta llevando a cabo las historias a
las que se comprometen al inicio de cada
sprint.
Qu es una Metodologa?
En el desarrollo de software, una metodologa hace cierto
nfasis al entorno en el cul se plantea y estructura el
desarrollo de un sistema. Como lo mencion al principio,
existen una gran cantidad de metodologas de la
programacin que se han utilizado desde los tiempos atrs y
que con el paso del tiempo han ido evolucionando. Esto se debe
principalmente a que no todos los sistemas de la informacin,
son compatibles con todas las metodologas, pues el ciclo de
vida del software puede ser variable. Por esta razn, es
importante que dependiendo del tipo de software que se vaya a
desarrollar, se identifique la metodologa para el diseo de
softwareidnea.

En qu consisten las Metodologas de Desarrollo de

Software?
Una Metodologa de desarrollo de software, consiste
principalmente en hacer uso de diversas herramientas,
tcnicas, mtodos y modelos para el desarrollo.
Regularmente este tipo de metodologa, tienen la necesidad de
venir documentadas, para que los programadores que estarn
dentro de la planeacin del proyecto, comprendan
perfectamente la metodologa y en algunos casos el ciclo de
vida del software que se pretende seguir.
Aunque actualmente existen mucha variedad en metodologas
de programacin. La realidad es que todas estn basadas en
ciertos enfoques generalistas que se crearon hace muchos aos,
algunos tipos de metodologas de desarrollo de software que
se utilizaron e inventaron al principio de nuestra era
tecnolgica y son las que veremos a continuacin.

Cules son modelos del Ciclo de vida del Software

tradicionales?
Como les mencion hace un momento, regularmente, cada
metodologa de desarrollo de software, tiene un enfoque
bien marcado, estos enfoques no son para nada nuevos y se
siguen utilizando para la planeacin y desarrollo de software
an en nuestros tiempos, as que vamos a ver cules son cada
uno de ellos y aprenderemos como funcionan.
Metodologa en cascada: Framework lineal.

El modelo de desarrollo de Software en cascada, es

una metodologa de la programacin muy antigua. Si bien su
creador nunca lo menciona como metodologa en cascada, el
funcionamiento y lineamiento de los procesos de la planeacin,
son exactamente iguales. Bsicamente, el estilo del modelo en
cascada, es que no podrs avanzar a la siguiente fase, si la
anterior no se encuentra totalmente terminada, pues no tiene
porque haber vuelta atrs. Vamos a ver cuales son las fases de
desarrollo de software del modelo en cascada, para que te
puedas dar una idea.
1. Anlisis de Requisitos. El primer nivel del modelo cascada,
es el anlisis de requisitos. Bsicamente lo que se documenta
aqu, son los objetivos de lo que el software debe hacer al
terminar el desarrollo, sin entrar en detalles de la parte interna,
los cuales se vern durante el proceso. Sin embargo es
importante sealar que una ves avanzado el paso de anlisis, no
puede haber vuelta atrs, pues la metodologa para el diseo
de software con la cual se trabaja no lo permitir.
2. Diseo del Sistema. Todo lo que conlleva el armado de un
diseo para el sistema que vayas a utilizar, es lo que continua
despus del anlisis de requisitos. Aqu se elaborar lo que es
la estructura del sistema y se determinarn las especificaciones
para cada una de las partes del sistema que se planea
desarrollar. Siendo del mismo modo, una fase a la cul ya no
se podr volver despus de haber bajado al nivel 3.
3. Diseo del Programa. En este punto, an no ingresamos a
lo que es la escritura de cdigo, sin embargo ya se realizan los
algoritmos que se van a utilizar en la programacin. Si bien
recuerdas, un algoritmo no necesariamente es cdigo,
simplemente tomas una hoja de papel y escribes el algoritmo
que vas a utilizar. Esto es precisamente lo que se realiza en el
paso nmero 3.
4. Codificacin. Seguramente como programador, esta es la
parte que estabas esperando, pues ahora es momento de
empezar a escribir todo el cdigo que ser necesario para el
desarrollo del software. Para este punto, la velocidad y el
tiempo que se requiera, depender mucho del lenguaje de
programacin que vayas a utilizar. Pues algunos lenguajes de
programacin permiten utilizar componente, bibliotecas e
incluso algunas funciones para reutilizar cdigo, las cuales
podrn acelerar el proceso de codificacin en gran manera.
5. Ejecucin de Pruebas. La codificacin ha terminado y
ahora es momento de verificar que nuestro sistema es realmente
funciona, antes de que el cliente empiece a utilizarlo. Este es
precisamente el objetivo de la fase 5 de pruebas. Aqu es
recomendable que intentes mover lo ms que se pueda tu
software, con el objetivo de daarlo intencionalmente, de este
modo, si supera las pruebas de dao realizadas por t, entonces
estar listo para el usuario final.
6. Verificacin. Despus de haber realizado una gran cantidad
de pruebas en la Fase 5, debemos migrar a la verificacin. Esta
fase consiste en la ejecucin del Software por parte del usuario
final. Si la fase cinco se realiz correcta y profundamente, el
software no tendr ningn tipo de problema y el usuario final
quedar satisfecho con el resultado.
7. Mantenimiento. Seguramente te has dado cuenta, de que las
aplicaciones o el software actual, constantemente se est
actualizando. Esto se debe principalmente a que se le da
mantenimiento al software, se solucionan errores, se quitan
algunos bugs, se aaden funcionalidades, todo despus de que
el usuario final ya lo ha probado y utilizado en su fase final.
Esta es posiblemente una de las fases ms tediosas del modelo
de desarrollo de software, pues debes estar atento a los
comentarios de los usuarios, para ver que cosas son las que no
funcionan correctamente y a las cuales hay que darles
mantenimiento
Cules son los Principios bsicos del modelo de cascada?

Como puedes ver, el proceso de desarrollo de software con

el modelo de cascada es bastante complejo. Sin embargo uno
de sus principios es que cada una de las fases elaboradas, se
encuentre documentada perfectamente, de este modo, si el
desarrollo queda suspendido en alguna fase, cualquier usuario
que quiera continuar con el proyecto lo podr hacer leyendo la
documentacin.
As tambin, es muy comn encontrar metodologas para el
desarrollo de software en cascada con fechas de objetivos,
tiempos o presupuestos para determinadas fases.
Aprovechando el hecho de que una ves que avanzaste de fase,
es muy poco recomendable el volver atrs, aunque
regularmente se tiene un cierto nivel de tolerancia, pero lo
correcto en la utilizacin del modelo de cascada, es que no
puedas ir atrs a realizar modificaciones de ningn tipo.
Mtodo de Prototipos

Esta metodologa de la programacin todava sigue siendo la

favorita de muchos. Consiste bsicamente en que en base a los
requerimientos y necesidades que tiene el cliente, se realiza de
forma rpida un prototipo, este no vendr completo ni mucho
menos terminado, pero si permitir contar con las bases
necesarias para que cualquier programador pueda seguir
trabajando en el hasta llegar al cdigo final.
Por si no lo sabes an, un prototipo es una versin no terminada
del producto que se le entregar al cliente o usuario final. Esto
nos genera cierta ventaja en el desarrollo de productos similares
con funciones distintas, por ejemplo. Supongamos que vas a
desarrollar un proyecto para 3 clientes distintos, ambos con una
estructura idntica pero con funcionalidades muy distintas,
entonces lo que hacemos es crear un prototipo base y entorno a
el mostrarlo a nuestros clientes para que de ah se empiecen a
desarrollar las dems funciones.
Mejor vamos a ver cuales son las etapas de desarrollo de
softwarepor las cuales tendrs que pasar, en caso de utilizar la
metodologa de prototipos.
1. Planeacin. A diferencia de otras metodologas, la
planeacin debe ser muy rpida, en esta fase no puedes
demorarte mucho, pues recuerda que solamente ser un
prototipo por el momento.
2. Modelado. Nuevamente, una fase que deber ser
suficientemente rpida como para que nos nos quite nada de
tiempo. Hacer el modelado ser simple y te sigo recordando
que solamente es un prototipo, almenos por ahora.
3. Elaboracin del Prototipo. Ya que contamos con la
planeacin de lo que vamos a realizar y el modelado rpido,
entonces es momento de elaborar el prototipo. Para esta
instancia, ya no te dir que lo debes hacer rpido, puesto que te
tomar el tiempo que tenga sea necesario elaborarlo, recuerda
que este ya se muestra al cliente, as que ya es una fase
importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y
mostrado al cliente, es momento de comenzar el desarrollo.
Este te tomar una gran cantidad de tiempo, dependiendo del
tamao del proyecto y el lenguaje de programacin que se vaya
a utilizar.
5. Entrega y Retroalimentacin. Una de las cosas con las que
cuenta el modelo de prototipos, es que una ves entregado el
proyecto, debemos darle al cliente cierta retroalimentacin
sobre como utilizarlo y ciertamente es una fase que se
encuentra dentro de las etapas de desarrollo de software esta
metodologa.
6. Comunicacin con el Cliente. Es importante que una ves
entregado el proyecto, tengamos cierta comunicacin con el
cliente, bsicamente para que nos indique si el proyecto es
correcto o si desea agregarle ciertas funciones, nuestra
metodologa lo permite. Si fuera en modo cascada, entonces
seria algo realmente imposible de hacer.
7. Entrega del Producto Final. Por ltimo, solamente quedar
entregar el sistema elaborado mediante esta metodologa. Aqu
tendrs la ventaja de que el cdigo es reutilizable, para que as
con el prototipo ya puedas simplemente empezar de nuevo y
con una buena base de cdigo que te acelerar el proceso.
Cules son los Principios Bsicos del mtodo de prototipos?

Por supuesto, te habrs dado cuenta de que el modelo de

prototipos puede llegar a ser un poco ms tedioso, aunque todo
depender del mbito en que lo utilices. Sin embargo uno de
sus principios bsicos que seguramente habrs notado, es que
con el mtodo de prototipos el proyecto se va dividiendo en
partes cada ves mas pequeas, para evitar el peligro ante los
riesgos frente a los que estamos expuestos.
Adems, otros de sus principios bsicos fundamentales, es que
con la metodologa de prototipos, el cliente final se involucra
mucho ms en el proyecto que con otras metodologas,
haciendo de esta forma que el producto final llegue
rpidamente aunque con un poco ms de presin en el proceso.
La ventaja es que conforme se van haciendo prototipos
pequeos, poco a poco se va llegando al producto final. Incluso
en algn determinado momento podrs llegar a crear un
prototipo que con solo ajustar ciertos detalles, se podra
convertir en el producto que el usuario quiere.
Modelo Incremental o Iterativo y Creciente

El modelo Incremental, es una metodologa de la

programacin muy utilizada hoy en da, pues su comodidad
de desarrollo permite que te obtenga un producto final mucho
ms completo y exitoso. Se trata especialmente de la
combinacin de los modelos lineal e iterativo o bien, modelo
de cascada y prototipos. Bsicamente consiste en completar
varias iteraciones de lo que es el modelo de cascada, pero sin
completar ninguna, haciendo iteraciones lo que se hace es crear
una evolucin en el producto, permitiendo que se agreguen
nuevas especificaciones, funcionalidades, opciones, funciones
y lo que el usuario requiera despus de cada iteracin.
En pocas palabras, el Modelo Incremental repite el modelo de
cascada una y otra ves, pero con pequeas modificaciones o
actualizaciones que se le puedan ir agregando al sistema. De
este modo el usuario final se ve sumamente sumergido en el
desarrollo y puedes proporcionarle un resultado ptimo.
Fases del Modelo Incremental

El modelo iterativo o incremental, cuenta con algunas fases de

desarrollo de software que realmente no tienen mucha
complejidad, vamos a verlas:
1. Inicializacin. como en todo modelo de desarrollo, debe
haber una inicializacin, aqu se puede hablar de dar una idea,
de tener algunos requisitos que se buscan en el proyecto y
ciertas especificaciones que se pueden manejar. No es
necesario que se haga una lista total de requerimientos pues
recordemos que el proyecto se basa en iteraciones, as que el
proyecto puede ir evolucionando poco a poco.
2. Periodos de Iteracin. Durante el desarrollo del proyecto,
es cuando damos inicio a las iteraciones. La primera iteracin
se realiza con las caractersticas iniciales, bsicamente al final
de la primer iteracin, queda un pequeo prototipo de lo que
ser el proyecto, pero se puede volver a inicializar la iteracin
y realizar modificaciones en los procesos, como el anlisis y
las especificaciones o funciones que el usuario final requiere
para su sistema.El nmero de iteraciones que se realicen son
ilimitadas y depender tanto del desarrollador como del usuario
final. Si nuestro objetivo es que el cliente o la persona que
necesita el trabajo quede completamente satisfecha, entonces
nos veremos en la necesidad de hacer la cantidad de iteraciones
que se requieran al final del da.
3. Lista de Control. Es importante que conforme se vaya
realizando cada iteracin, se vaya llevando un control del
mismo en una lista. Como si fuera un programa que recibe
actualizaciones constantemente. Cada una de las
actualizaciones o iteraciones deber ser documentada y de ser
posible, guardada en sus respectivas versiones, para que sea
sencillo volver atrs, en caso de que una iteracin no sea
exitosa o el usuario ya no la requiera.
Cules son los principios bsicos del Modelo Incremental?

Es importante definir los siguientes principios fundamentales,

pues nos permiten saber con claridad por donde va la idea de la
metodologa.
La idea de un modelo incremental, es utilizar una serie de
mini modelos de desarrollo de software en cascada,
segmentando requerimientos y permitiendo que el usuario vaya
de la mano con el proyecto durante la realizacin.
Bsicamente las fases de cada iteracin, son las mismas que
se manejan en el modelo de cascada, aunque tambin se
pueden agregar algunas, pero su objetivo es completar cada
fase de la iteracin, para que esta se vaya complementando
poco a poco y no se genere un desarrollo tedioso y cansado que
puede alargar la duracin del proyecto en demasa.
Debes saber, que cada iteracin te generar un prototipo cada
ves mas evolucionado, estos debers guardarlos por si en
determinado momento deseas volver atrs, pues a diferencia
del modelo de cascada, podemos retroceder cuando se requiera
y los prototipos se pueden volver a utilizar una y otra ves, pues
el cdigo fuente es reutilizable.
Modelo en Espiral

El modelo en espiral, fue utilizado y diseado por primera

ves por Barry Boehm en 1986. Se trata nuevamente de una
combinacin entre el modelo lineal o de cascada y el modelo
iterativo o basado en prototipos, sin embargo a este sistema lo
que debemos aadirle es la gestin de riesgos, algo que en los
modelos anteriores ni siquiera se menciona.
Este modelo, consiste en ciertas fases que se van realizando
en modo de espiral, utilizando procesos de la misma forma
en que se utilizan en el modelo de cascada, sin embargo aqu
estos no son obligatorios y no llevan precisamente el orden
establecido. Bsicamente se trata de un modelo evolutivo, que
conforme avancen los ciclos, ir incrementando el nivel de
cdigo fuente desarrollado, un incremento en la gestin de
riesgos y por supuesto un incremento en los tiempos de
ejecucin y planificacin del sistema, esto es lo que tiene el
modelo en espiral.
Para que tengas una idea ms clara, el modelo en espiral es
principalmente utilizado para el desarrollo de grandes
proyectos como la creacin de un sistema operativo. Sin
embargo necesitas de ciertos requisitos, como el hecho de
contar con personal completamente capacitado para las
funciones que se requieran. Mejor veamos cuales son las las
fases o tareas dentro del modelo de espiral.
1. Determinar Objetivo. Es importante que siempre
consideres una planeacin inicial, esta solo se realizar una ves.
Sin embargo el proceso de determinar objetivos se har
constantemente durante cada iteracin que se vaya realizando
con el modelo espiral. Esto se debe a que poco a poco se ir
incrementando ms el tamao del manual de usuario, los
requisitos, las especificaciones e incluso las restricciones. Todo
esto entra en lo que es la tarea de objetivos y con cada vuelta
en el espiral entraremos a esta tarea, la cual como todas las
dems, es fundamental.
2. Anlisis de Riesgo. Una etapa donde incluso una lluvia de
ideas podra ayudar, el anlisis de riesgos. Aqu debers tener
en cuenta todo aquello que pueda daar a tu proyecto, ya sea
que se trate de ciertas amenazas o de posibles daos que se
puedan ocasionar, teniendo adems un Plan B por as decirlo,
para que en caso de que ocurra algo inesperado, tener a la mano
la solucin para continuar con el proyecto.En esta fase del
modelo espiral, podemos agregar lo que son la creacin de
prototipos, pues siempre es bueno tener un respaldo de nuestro
cdigo, se esta forma en caso de que algo malo suceda,
volvemos a la versin anterior. As que cada vez que vayamos
a ingresar a la fase de pruebas e implementacin, ser necesario
contar con un prototipo que nos respalde.
3. Desarrollar, Validar y Probar. Bsicamente en esta fase,
la forma en que se estar desarrollando el proyecto, depender
del anlisis de riesgos, pues siempre se va a ir desarrollando el
proyecto enfocndose en los riesgos que podemos evitar en
nuestro software, es decir, si la situacin de riesgo ms obvia
se encuentra en la interfaz del usuario, entonces hay que
trabajar con prototipos para este enfoque, creando evoluciones
proporcionales, para ir evitando ese tipo de riesgos.Esto no
significa que ignoremos el resto del proyecto o del desarrollo,
sin embargo el modelo en espiral si acomoda un poco ms las
prioridades al momento, independientemente de todo lo dems.
Por lo que siempre en cada vuelta o iteracin que se le de al
modelo de espiral, tu avance siempre depender del anlisis de
riesgo, hasta que este sea mnimo y el desarrollo pueda
continuar de forma normal.
4. Planificacin. Antes de proceder a realizar otra iteracin o
vuelta al espiral, debemos prestar atencin a lo que sucedi en
la vuelta anterior. Debemos analizar detalladamente si los
riesgos encontrados ya tuvieron solucin, lo cual debe ser lo
ideal, puesto que ahora habra que analizar ms
especificaciones y ms requisitos del sistema para continuar
con el desarrollo.Bsicamente la fase de planificacin, nos
servir para determinar el avance de nuestro proyecto y indicar
hacia donde vamos a dirigirnos en la prxima iteracin.
Cules son los Principios bsicos del modelo en Espiral?

Est claro que el modelo en espiral, es sumamente distinto a los

dems. Encontramos por fuera cuatro fases bien organizadas,
las cules siempre deben llevar ese orden que se estipula desde
el principio. Una determinacin de objetivos, un anlisis de
riesgos, el desarrollo y las pruebas, junto con la planificacin,
la cual depender de los resultados de la iteracin para saber
como se actuar en la siguiente vuelta al espiral.
Bsicamente, en el modelo de espiral, toda la atencin est
enfocada hacia el anlisis de riesgos, pues el objetivo
primario ser reducir los riesgos que se vayan generando, de
otra forma el sistema no llegar a ser seguro jams.
Algo muy importante que debes ver en el modelo de espiral, es
que los interesados deben estar involucrados prcticamente en
cada vuelta que se de al espiral, para crear lo que son los
requisitos antes de realizar una vuelta ms y al final en la fase
de planificacin, se determinan los logros obtenidos, el avance
y lo que se esperar de una siguiente vuelta.
RAD: Desarrollo Rpido de Aplicaciones (Rapid Application
Development)

A diferencia de otras metodologas para el desarrollo de

software, la metodologa RAD o desarrollo rpido de
aplicaciones, no cuenta con una serie de fases ordenadas por
as decirlo. Aunque si est basada en lo que es el modelo de
cascada y la creacin de prototipos, sin embargo el proceso es
muy independiente a contar con ciertas fases estipuladas como
los modelos que hemos visto anteriormente. As que vamos a
ver los principios del modelo RAD.
Cules son los principios bsicos del Modelo RAD?

Del mismo modos que modelos anteriores, el Modelo RAD,

est basado en el uso de las iteraciones y principalmente en
el manejo de prototipos. Sin embargo a diferencia del resto,
la metodologa RAD hace uso de las Herramientas CASE, las
cuales permitirn acelerar el proceso considerablemente.
Del mismo modo que el modelos espiral y el de
prototipos, RAD se subdivide en pequeas secciones, las
cuales se irn optimizando y de esta forma se ir avanzando
mucho ms rpido que con grandes segmentos que pueden
volverse difciles dentro de un proceso acelerado como lo este
este modelo.
Una de las ventajas del RAD, es que el enfoque y las
prioridades van hacia la fase de desarrollo, a diferencia de
modelos como el espiral, que se enfoca en que los riesgos al
momento sean mucho menores. Ac con el RAD, se hace lo
contrario, si hay riesgos reducimos los requerimientos para
reducir los riesgos, no como en el espiral, que entre ms
riesgos, ms requisitos aportamos para que se incremente. Ac
la idea es reducir tiempos y no riesgos, o si, talves tambin,
pero la reduccin de riesgos es totalmente inversa al modelo
espiral.
Por supuesto, como en todos los modelos, vas a requerir de
ciertos factores documentados, de preferencia todo lo que se
pueda, para que en caso de que alguien ms venga a continuar
con este proyecto, tenga a la mano toda la informacin que
necesita y con unas cuentas lecturas pueda empezar a
desarrollar lo que se haba quedado pendiente en un
determinado momento.

Cul es tu metodologa tradicional preferida?

Si bien hemos visto mtodos muy diversos, informacin muy
variada y ciclos de desarrollo de software con distintos
enfoques. La realidad es que al final tu siempre decidirs como
trabajar y con que tipo de metodologa te sentiras ms a gusto.
Obviamente depende de muchos factores, principalmente del
tamao del proyecto, pues modelos como el espiral, son
especialmente para proyectos grandes y modelos como el
RAD, son enfocados en proyectos pequeos, sin tanto requisito
pero manejando siempre cierto nivel de calidad, el cual siempre
debes considerar.
A continuacin, analizaremos lo que son las metodologas
giles de desarrollo de software ms importantes, las cules
a diferencia de las metodologas tradicionales, funcionan mas
como una combinacin de estas para lograr un objetivo. Su
finalidad siempre ser el crear software de una forma ms
rapida de lo que se venia logrando con las metodologas de
antao. As que vamos a ver un poco de informacin referente
a lo que son las metodologas giles, como funcionan y que se
necesita para implementarlas.

Metodologas giles
Con el paso del tiempo, estaba claro que las metodologas
tradicionales, simplemente no se iban a acoplar con las nuevas
tecnologas, los nuevos lenguajes y sobretodo los
programadores modernos. Es por eso que desde principios del
Siglo, se han desarrollado lo que son las metodologas
giles. Una metodologa gil, consiste principalmente en
trabajar con menos documentacin de la que, como vimos, las
metodologas tradicionales utilizan en todo momento.
Existen una gran cantidad de metodologas giles de
desarrollo de software y todas las vamos a ver a continuacin.
Sin embargo antes hay que comprender en que consiste
detenidamente la metodologa gil, para lo cual contamos con
el manifiesto gil. Un documento en el cul se resume la
filosofa de este enfoque de desarrollo, as seguramente
despus de leer esos puntos, nos quedar an mas clara la idea
de hacia donde se pretende llegar y principalmente Cmo se
pretende llegar a los objetivos.
Manifiesto gil

Al Individuo y las Interaciones del Equipo. Una de las

cosas que sabemos muy bien, es que las personas son quienes
consiguen los xitos dentro de un proyecto de software. Sin
embargo tambin est claro que si el equipo de trabajo falla,
entonces todo se viene abajo y el enfoque que habia de xito se
convierte en incertidumbre. A diferencia de si el equipo
funciona perfectamente, se tienen mas cerca los objetivos, an
cuando no exista una lista de procesos establecida como se
hacia con las metodologas de antao.
Con este primer valor del desarrollo gil, se pretender hacer
ver, que en realidad no importa que el equipo de trabajo no sean
las personas ms brillantes del sector. Con que sean personas
que saben hacer bien el trabajo que se les asignar es ms que
suficiente. En este caso, las herramientas aunque son
importantes para incrementar el rendimiento, tambin es cierto
que si hay herramientas de ms y que no sirven de nada en un
principio, lo mejor es dejarlas de lado o estas nos quitarn
valioso tiempo que no tendremos.
Bsicamente el enfoque, es que no se intente crear un entorno
de trabajo desde un principio, tratando de que los
desarrolladores se adapten a ese entorno que nosotros
deseamos, pues este tipo de proyectos suelen tardar mucho
tiempo en desarrollarse, algunos incluso jams terminan y se
quedan estancados. El enfoque del desarrollo gil nos dice,
que es mejor formar primero un buen equipo de trabajo y
posteriormente entre ellos vayan creando su propio entorno.
Este proceso ayudar mucho ms a la metodologa gil y por
supuesto, la adaptacin ser un proceso fugaz.
Software funcional en lugar de demasiada
documentacin. Crear documentacin, es una de las
actividades que con las metodologas tradicionales, absorban
una gran cantidad de tiempo. Si nos acercamos a analizaras las
metodologas de antao, descubriremos que en cada una de
ellas, realizar la documentacin era una parte vital. Sin
embargo en las metodologas giles, esto ha cambiado, pues
existe una regla que dice de la siguientes forma: No producir
documentacin, almenos que sean sumamente necesarios al
momento para tomar una decisin. Por lo que adems se
extienda hacia el enfoque de que la documentacin debe ser
corta y breve, nada sumamente extenso que requiera de una
gran cantidad de tiempo de lectura.
Te preguntars y entonces, cuando un nuevo programador o
desarrollador sea colocado en un puesto dentro del proyecto,
como sabr hacia donde ir y el enfoque que se est llevando a
cabo. Para lo cual el manifiesto gil nos dice que, existen dos
elementos fundamentales para que un nuevo miembro del
equipo se ponga al da. El primero es el cdigo fuente, pues
suponiendo que es una persona conocedora, sabr hacia donde
va el curso del proyecto con tan solo leer el cdigo. La segunda
es que la interaccin con el equipo de trabajo, ser el
complemento ideal para que se acople al proyecto. De este
modo nos olvidamos de la extensa documentacin para un
software que al final del da debe estar totalmente funcional.
Colaboracin con el Cliente en lugar de hacer Contrato.
Una de las cosas importantes dentro de las metodologas
giles. Es que cambia el modo en que se trabajaba con el cliente
anteriormente. Y es que en las metodologas de antao, el
trabajo consista en tener una reunin previa con el cliente para
analizar los requerimientos del sistema, aqu se analizaban las
limitaciones del proyecto y se establecan los costos. Lo que
generaba cierta barrera de bloqueo entre las posibilidades de
desarrollar algo funcional para otras cosas o solo para el
objetivo establecido en la reunin. Esto al final poda ser
desastroso y dificultar la llegada al xito por parte del proyecto.
Sin embargo, ahora en el manifiesto gil, se propone que exista
una interaccin constante entre el cliente y el equipo de
desarrolladores. La idea es que el cliente vaya viendo como va
el sistema y analice nuevas funcionalidades o objetivos, ya que
estos no tienen porque plantearse desde el principio, si el
desarrollo nos puede llevar a una infinidad de posibilidades. De
esta forma el cliente al final queda totalmente satisfecho con el
producto final y habremos llegado al xito trabajando todos en
equipo de forma simultanea.
Posibilidad de Hacer cambios de planes a medio proyecto.
Suena mas o menos a lo que vimos en el punto anterior, pues
bsicamente la idea es evitar lo que es la planeacin extensa
y empezar a crear cdigo que permita expansin.
Recordemos que con las metodologas tradicionales, se
acostumbraba a enlistar los requisitos del sistema y el
desarrollo iba enfocado solamente a eso, lo cual ya no permita
que a medio desarrollo hubiera cambios, pues era un cdigo
poco moldeable y si se requeran nuevas cosas, en algunas
metodologas lo idea era volver a empezar.
La idea en las metodologas giles, es que durante el desarrollo
del software, si el cliente tiene la idea de incrementar sus
objetivos, especificaciones o requerimientos, lo pueda hacer
sin ningn problema. Pues bsicamente el sistema debe ser
flexible para todo lo que pueda surgir en el proceso. De este
forma, no solamente llegaremos al xito, si no que el cliente
quedar totalmente satisfecho con el trabajo desarrollado, pues
no tuvo que conformarse con lo primero que se le vino a la
mente, si no que se actualiz con las ideas que en la marcha
fueron surgiendo.

Cules son las Principales Metodologas giles?

Algo que debes saber antes de dar paso a la descripcin de cada
una de las metodologas de la programacin giles, es que
aunque entre sus creadores crearon lo que fue el manifiesto
gil, la realidad es que cada una de las metodologas cuenta con
su propia personalidad y caractersticas nicas, que la
diferencian de las dems. Por eso a continuacin, veremos cada
una de las metodologas giles ms populares, para que tengas
un conocimiento ms solido de lo que son y hacia donde van
cada una de ellas.

Metodologa Scrum

Para que tengas una idea rpida, para que un proyecto ingrese
al marco de lo que es el modelo Scrum, debe contar con las
siguientes caractersticas:
Desarrollo Incremental. Una metodologa gil sin desarrollo
incremental, no puede ser considerada Scrum. Con incremental
hago nfasis a olvidarnos de la planeacin y de la ejecucin de
las lineas sin salirnos de lo pre establecido, pues con una
metodologa Scrum, el desarrollo se ir incrementando poco a
poco, sin importar el orden en el cual se lleven a cabo los
procesos.
Calidad de las personas. Bsicamente la calidad de un
producto, no ser analizada en base a la calidad de cada uno de
los procesos llevados a cabo. Al contrario, la calidad depender
de las personas, la auto organizacin y el conocimiento de los
equipos de trabajo.
Adis al Secuencial y Cascada. Aqu en el modelo Scrum,
hay algo a lo que se le denomina, solapamiento. Esto consiste
en que no importa en que proceso te encuentres, si un proceso
necesita ser trabajado, vuelves a el para realizar lo que tienes
que hacer, a diferencia de las metodologas cascada o
secuencial, donde no haba vuelta atrs. Ac afortunadamente
no hay ningn problema con eso y la ventaja es que se ahorran
tiempos.
La comunicacin es Fundamental. Una de las cosas que se
realizan, son los equipos de trabajo, sin embargo ac la ventaja
que tendrs es que podrs estar en constante comunicacin con
los otros equipos de trabajo, nadie est envuelto en su propia
burbuja y toda la informacin que se maneje o lleve a cabo,
ser comunicada sin problema.
Como funcionan los Procesos Scrum?

La metodologa Scrum, es bastante amigable y fomenta lo

que es el trabajo en equipo en todo momento, con la
finalidad de conseguir los objetivos de una forma rpida.
Veamos ahora cuales son los procesos con los cuales funciona
la metodologa, empezando por el Product Backlog, el cual nos
permitir llegar a los Sprints, a continuacin te explicar de que
te estoy hablando.
Product Backlog. El Product Backlog no es ms que una lista
de las funcionalidades del producto a desarrollar. Este debe ser
elaborado por el Product Owner, puesto que ms adelante les
explicar. Sin embargo no se trata de una lista cualquiera hecha
con escritos y nadams. El Product Backlog debe estar
ordenado de acuerdo a las prioridades del sistema de mas a
menos, con la idea de que las cosas con mayor prioridad sean
las que se realicen antes de cualquier cosa. De forma concreta,
digamos que el objetivo base del Product Owner, es que nos de
respuesta a la pregunta Qu hay que hacer?.
Sprint Backlog. Una ves que ya contamos con el Product
Backlog terminado, entonces aparecer el primer Sprint
Backlog. Pero Qu es el Sprint Backlog? Consiste
bsicamente en seleccionar algunos de los puntos escritos en el
Product Backlog, los cuales procedern a ser realizados. Sin
embargo en este punto el Sprint Backlog tiene como requisito
marcar el tiempo en que se llevar a cabo el Sprint.
Sprint Planning Meeting. Antes de iniciar un Sprint, el cual
es la fase de desarrollo, se realiza lo que es un Sprint Planning
Meeting. En este proceso del Scrum, es una reunin que se
realiza para definir plazos y procesos a efectuarse para el
proyecto establecido en el Product Backlog. Algo importante
que debes saber, es que cada Sprint, se compone de diversos
features, que no son otra cosa mas que procesos o subprocesos
que se deben realizar, puede ser la creacin de un logo, la
gestin de contenido, el diseo visual, etc. Todo depender del
proceso que se desee llevar a cabo.
Daily Scrum o Stand-up Meeting. Cuando un Sprint est en
proceso, despus de haber hecho la planeacin del proyecto
mediante plazos y procesos, entonces entramos a lo que son los
Daily Scrum o Stand-up Meeting. Aqu bsicamente lo que se
hace son reuniones diarias mientras se est llevando a cabo un
Sprint, para responder las siguientes preguntas: Que hice
ayer?, Qu voy a hacer hoy, Qu ayuda necesito?. Aqu entra
en funcin el Scrum Master, un puesto que igual mas adelante
les explicar. Pero el ser el encargado de determinar la
solucin de los problemas y cada complicacin que suceda.
Sprint Review. El Sprint Review, es bsicamente una resea
de lo que fue el Sprint. Consiste especficamente en la revisin
del Sprint terminado y para este punto ya tendra que haber algo
que mostrarle al cliente, algo realmente visual o tangible para
que se pueda analizar un cierto avance.
Sprint Retrospective. Para concluir, el Sprint Retrospective,
permite al equipo analizar los objetivos cumplidos, si se
cometieron errores, visualizarlos y tratar de no cometerlos
nuevamente mas adelante. Bsicamente tambin sirve este
proceso para lo que son la implementacin de mejoras.
Equipos que Componen los Procesos Scrum

Durante el punto anterior, te describ los procesos que se llevan

a cabo en la Scrum Metodologa, y en varios puntos mencion
ciertos equipos que son encargados de algunos aspectos
importantes. Por eso a continuacin veremos cuales son los
equipos que conforman la metodologa Scrum y con los cuales
se trabajar arduamente, obvio, cada quien con sus respectivas
responsabilidades.
Product Owner. Si se trata de tener un lder de proyecto,
entonces el Product Owner lo ser. Bsicamente son los ojos
del cliente, ser la persona encargada del proyecto y de visorear
que se lleve a cabo de tal forma que cumpla las expectativas de
lo que se espera.
Scrum Master. Ahora bien, para cada reunin realizada,
siempre debe estar un lder, en este caso el Scrum Master ser
el lider de cada una de las reuniones y ayudar en los problemas
que hayan surgido. Ser bsicamente como un facilitador el
cual minimizar obstculos, sin embargo no los omitir. En
realidad el Scrum Master debe ser una persona empapada de
conocimientos sobre el lenguaje o lenguajes bajo los cuales se
llevar a cabo el proyecto, de lo contrario no tendra como
ayudar a solucionar problemas.
Scrum Team. Bsicamente es el ncleo de la metodologa
Scrum, pues es el equipo de desarrollo, encargado de lo que es
la codificacin del software y de cumplir los objetivos o metas
propuestas por el Product Owner.
Cliente. Aunque no lo creas, el cliente tambin forma parte
del equipo, hablamos de eso hace un rato, cuando coment que
no es como en las metodologas tradicionales donde al cliente
se le pedan requerimientos y se le daba un costo total. En la
metodologa Scrum, el cliente tiene la capacidad para influir en
el proceso, debido a que siempre estar empapado de el, ya sea
que proponga nuevas ideas o bien haciendo algn tipo de
comentario.

Metodologa Kanban

Siguiendo con las metodologas giles, nos encontramos con

Kanban. Se trata de una metodologa Japonesa, la cual
consiste en ir etiquetando con tarjetas cada uno de los
procesos que se deben llevar a cabo, tambin se le ha
denominado como Un sistema de produccin de alta
efectividad y productividad. De hecho, empresas como la
marca de autos Toyota, fueron una de las primeras en
implementarla para acelerar los procesos de produccin.
La palabra Kanban, en Japons significa tarjetas
visuales y es precisamente lo que se maneja en ella.
Algunos la trabajan con lo que son tarjetas virtuales o bien
simulando que se pueden ver las tarjetas, sin embargo una
forma correcta de hacerlo es con tarjetas fsicas, que el equipo
pueda ver y sentir para tener mayor efectividad.
Una de las principales ventajas de Kanban, es que adems de
ser una metodologa gil, tambin es muy fcil de usar e
implementar, sobretodo porque el equipo de trabajo se unir y
empezarn a trabajar a la par en diferentes aspectos del
desarrollo. Veamos ahora, cuales son los principios bsicos de
la metodologa Kanban.
Principios Bsicos de Kanban

Garanta de Calidad. Algo por lo que destaca Kanban, es

que el ser una metodologa gil, no es sinnimo de trabajar a
las carreras o de hacer todo de golpe. Kanban promueve la
calidad antes que la velocidad, es decir, un producto bien hecho
desde la primera vez que se elaboro es ms rpido, que un
producto mal hecho al cual se le tienen que volver a meter las
manos para arreglarlo. Entendiendo esto, concluimos con que
todo debe salir bien desde el inicio y no debe haber margen de
error.
Desperdicios. Basado en lo que es el principio YAGNI, la
metodologa kanban trabaja de una forma en la cual, solamente
se debe hacer lo necesario y requerido para que el sistema o el
desarrollo quede bien. Evitando todo aquello que es
considerado como extra, superficial o innecesario. De este
modo no solamente se ofrece una mayor calidad en el producto,
si no que adems se optimizan tiempos y costos.
Mejora Continua. Algo interesante de la metodologa
Kanban, es que no solamente de trata de un sistema diseado
para el proceso de desarrollo de Software, se puede
implementar en el desarrollo de cualquier tipo de producto, tal
y como lo hizo Toyota. Adems es un sistema que nos da la
oportunidad de ir mejorando constantemente en los procesos,
dependiendo claro de cual sea el objetivo o la meta final.
Es Flexible. Aqu es donde volvemos a hacer comparaciones
con las metodologas de antao, donde la flexibilidad no
exista, como si fueran metodologas del abuelo estricto, ac
eso no existe. La flexibilidad es uno de los principios de
Kanban y qu obtenemos con ello?. Gracias a que es flexible,
podemos adelantarnos a un proceso que queramos hacer o que
tenga cierto nivel de prioridad, no necesitamos seguir una linea
de trabajo, lo cual hace de kanban una metodologa ms
dinmica y adems permite resolver problemas que surjan de
imprevisto, algo que con otras metodologas simplemente ni se
considera.
Cmo configurar una estrategia Kanban?

Realmente una de las cosas que diferencian a Kanban del

resto, es que ac vas a necesitar un tablero de verdad. No es
nada extrao ni loco, con el avance de los das de trabajo
notars que fue una magnifica idea comprar ese tablero y los
post-it para escribir objetivos. As que vamos a ver los pasos
para realizar bien la configuracin de una metodologa Kanban.
1. Definir el Flujo de Trabajo. Una ves que ya tienes el
tablero que es requisito para esta metodologa, es entonces
cuando podrs empezar a seccionarlo dependiendo del nmero
de tareas, fases o proyectos que tengas en puerta. Considera que
el tablero debe estar a la vista de todo el equipo de trabajo, pues
ser necesario estar al pendiente de los procesos y de ir
actualizndolos conforme se vaya avanzando en el. Ahora si
que como te comentaba, un tablero puede ser destinado para un
solo proyecto o bien para muchos proyectos, todo depender de
si deseas mantener el flujo de trabajo constante o
medianamente pausado.
2. Fases del Ciclo de Produccin. Es importante que te des
cuenta, de como debes seccionar el tablero para ir marcando el
flujo de produccin. En este caso es realmente necesario que
los procesos sean divididos en pequeos segmentos, para que
se pueda agilizar y no se quede estancado en uno con
demasiada duracin. Es por eso que en los post-it que vayas
colocando con cada proceso, deber ser colocado el nmero de
horas requeridas para completarlo, al finalizar las horas se
determinar el porque no se ha terminado o bien ya se habr
avanzado a otra fase.
3. Stop Starting, start finishing. La filosofa de Kanban,
trabaja de esta forma, no te voy a envolver en trminos que te
puedan confundir pues la idea es obvia: No se empieza una
nueva tarea, hasta terminar la otra. Esto se debe
principalmente a que la idea es tener un alto porcentaje de
tareas completadas y no como ciertos equipos de desarrollo que
tienen una gran cantidad de proyectos en puerta y muchas
tareas por hacer, la mayora empezadas, pero ninguna
terminada. Esta es la situacin principal que se trata de evitar
con Kanban y es que aunque parezca muy obvia, la realidad es
que muchos la pasan de largo, an cuando es fundamental.
4. Tener un Control. Algo con lo que trabaja Kanban, es con
el control del flujo de trabajo. Si bien la idea es que los
trabajadores tengan actividad realmente constante y no se
detengan an cuando terminen sus tareas. Kanban permite
llevar un control de todo gracias a las notas que se van
colocando. De esta forma adems permite que se ejecuten
varios proyectos se forma simultanea, una parte del equipo
pudo haber terminado sus tareas del proyecto anterior y avanzar
al siguiente, mientras los dems siguen todava trabajando en
ello. La idea es no provocar interrupciones a cada momento,
adems de que si necesitas un control, puedes ir almacenando
las tarjetas y listo.
Metodologa XP

Si hablamos de metodologas de la programacin sin

mencionar a la Metodologa XP, es como no hablar de nada en
absoluto. Esta metodologa es posiblemente la mas
destacada de las metodologas giles y esto se debe a su gran
capacidad de adaptacin ante cualquier tipo de imprevisto
que surja. Pues la idea no es mantener ciertos requisitos desde
que se est elaborando el proyecto, sino que durante el proceso,
estos vayan cambiando o vayan evolucionando gradualmente
sin complicaciones. Bsicamente los creadores de esta
metodologa XP, consideran que es mejor adaptarte en el
proceso a los requisitos que vayan apareciendo, que iniciar con
requisitos y desarrollar un proyecto en base a eso.
Si queremos ver la metodologa con otra perspectiva, se podra
decir que la metodologa XP o metodologa de
programacin extrema, como tambin se le conoce. Es la
combinacin de las dems metodologas, solamente que se
van utilizando de acuerdo a como sea necesario, por eso es
considerada como la ms destacada de las metodologas giles.
As que es momento de entrar en detalles y vamos a ver cuales
son los valores que conforman a la metodologa de
programacin XP.
Valores de la Metodologa XP

Como toda metodologa, la programacin extrema cuenta

con algunos valores que son fundamentales para que se
lleve acabo como debe ser. En algunas otras metodologas
estos puntos los conocamos como principios bsicos, es
realmente lo mismo solo que ac los mencionan como valores,
veamos cuales son.
Comunicacin. Del mismo modo que otras metodologas
como la Scrum, el cliente tiene una gran intervencin, pero
obviamente la comunicacin depender de mas factores. Por
ejemplo. El cdigo fuente de los programadores debe transmitir
esa comunicacin a todo el equipo, por eso las variables
amigables. De igual forma, se deben documentar las cosas mas
relevantes, independientemente de que sean comentadas en el
cdigo, pero es importante tener un documento extra para
explicaciones extensas, de lo contrario el cdigo se ver
infestado de escrito.En cuando a la comunicacin entre
personas, los programadores se comunican constantemente ya
que trabajan en parejas, la comunicacin que se tiene con el
cliente debe ser constante, pues recordemos que incluso el
forma parte del equipo de trabajo y es responsabilidad del
cliente, comunicarnos algunas actualizaciones que requiera en
el proceso, nuevas ideas, soluciones a problemas o
sencillamente algn problema que el vea. Todo debe ser
comunicado, esta parte es realmente fundamental para el
desarrollo de un producto exitoso.
Simplicidad. El primero de los valores de la metodologa de
programacin XP, es la simplicidad. Ya te haz de imaginar en
que consiste, puesto que la idea es que el desarrollo sea velz,
por lo cual todas las cuestiones de diseo se simplifican al
mximo, lo mismo sucede con las lineas de cdigo, si se pueden
simplificar, se hacen, adems de que regularmente el mismo
cdigo es donde va la documentacin comentada, de esta forma
nos evitamos el estar haciendo documentacin extra.Por esta
razn, adems es importante que en el ciclo de desarrollo de
software mediante la metodologa XP, las variables, mtodos
y clases, tengan nombres amigables y relacionados, de este
modo no solamente se ayuda el equipo de trabajo, el cual de
por si ya se debe conformar de dos personas por equipo, si no
que adems, cuando una persona nueva ingrese al proyecto,
ser muy rpida su adaptacin.
Retroalimentacin. El hecho de que el cliente se encuentre
involucrado en el proyecto, ayudar inicialmente con la
retroalimentacin. Pues conforme pasan los das y se va
analizando el cdigo por pequeas etapas, el cliente puede ir
corrigiendo, agregando, quitando o excluyendo algunas cosas,
esa es la ventaja de la programacin por periodos cortos de
tiempo, es decir, imagina que llevas varios meses desarrollando
el proyecto y cuando vas con el cliente, el proyecto no le gusta
y desea hacer tantos cambios que te llevar una eternidad.
Precisamente eso es lo que se trata de evitar con la metodologa
XP, que se tiren varios meses de trabajo a la basura y mejor se
vaya optimizando en pequeos lapsos de tiempo.Otra de las
formas de retroalimentacin con la cual contamos, es nuestro
cdigo fuente. Pues gracias a que podemos realizar diversas
pruebas unitarias, podremos ver la salud de nuestro cdigo, una
gran ventaja, pues si hay problemas o errores, siempre
estaremos a tiempo de realizar modificaciones y soluciones. A
diferencia de un proyecto sumamente extenso, donde
seguramente la cantidad de errores ser tan impresionante que
volver a empezar podr ser una opcin.
Valenta. Hay elementos donde el coraje o la valenta de los
programadores ser fundamental. Por ejemplo el dar solucin
a los problemas frente a los cuales se enfrente. El pasar por la
eliminacin de cdigo fuente en el programa desarrollado, an
cuando todo ese cdigo haya tomado una gran cantidad de
tiempo en hacerse o que tal el hecho de disear para hoy y no
para maana. Muchos lo hacen con esa idea en ocasiones, pero
con un poco de valenta y coraje que forman parte de los
valores de la metodologa, seguramente el xito llegar de
manera anticipada.
 Respeto. Originalmente, este quinto valor no se encontraba
en la metodologa XP, sin embargo es importante mencionarlo
pues hoy en da ya lo conforma. El respeto es importante para
que haya una buena comunin entre los programadores del
equipo. Nunca hay que denigrar a nadie ni agregar o ofender,
pues un autoestima alta en el equipo garantizar un trabajo
mucho ms eficiente. Por esta razn, cosas como el cdigo
fuente, las modificaciones, los fallos obtenidos, los problemas
o la solucin de problemas, son procesos que se deben respetar
para que el ambiente de trabajo tambin sea ptimo.
Caractersticas que componen la metodologa XP

Ya vimos los valores o principios bsicos, dejmoslo en valores

pues as es como lo denomina la metodologa, sin embargo
ahora vamos a ver sus caractersticas, de esta forma te podrs
dar una mejor idea de como funciona una metodologa XP.
Tipo de Desarrollo Iterativo e incremental. Como hemos
visto en lo que llevamos hablando de la metodologa XP, el
mtodo est basado en lo que son las mejoras continuas, a base
de iteraciones y por supuesto un desarrollo incremental al estilo
espiral.
Pruebas Unitarias. Una de las caractersticas adems son las
pruebas unitarias. Se utiliza software de codificacin eso si,
dependiendo del lenguaje que estemos usando es la
herramienta que nos corresponde, pero de este modo se analiza
el cdigo y solucionan errores, antes de validarlo y darlo por
bueno.
Trabajo en Equipo. Ms especifico todava, es el trabajo en
parejas, el objetivo es que el enfoque en parejas sea mayor, las
distracciones son menores y el aprendizaje del uno con el otro
permite que el avance del proyecto sea mucho ms eficiente
que cuando una persona es la encargada.
 Alguien del equipo trabaja con el cliente. Es fundamental
que el cliente intervenga en el desarrollo, pero obviamente el
no estar en la sala de desarrollo, se debe asignar a una persona
que sea le encargada de tener las reuniones con el cliente de
forma constante. El ser quien comunique al equipo los
cambios o el seguimiento del proyecto.
Correccin de Errores. Algo importante, el hecho de que la
metodologa XP sea realmente rpida para el desarrollo, no
significa que se pasen por alto los errores, de hecho primero se
le tiene que dar correccin a los errores antes de seguir
avanzando en el proyecto.
Reetructuracin del Cdigo. La idea es clara una
refacturacin del cdigo siempre se debe realizar. Con esto lo
que haremos es simplificar el cdigo pero no las funciones.
Pues regularmente cuando desarrollamos, agregamos algunas
cosas que pueden ser innecesarias y que no afectan en el
funcionamiento del sistema, estas son precisamente las que hay
que refacturar.
El Cdigo es de todos. Realmente aunque se trabaje en
equipos, al final todos tendrn la posibilidad de ver el cdigo,
proponer cambios o incluso hacerlos. La idea es que si uno no
detecta un error, otro lo podr hacer, por eso el cdigo fuente
es compartido entre todos.
Cdigo simple es la clave. Algo importante con la
metodologa extrema, es que la simplicidad siempre llevar la
ventaja. Principalmente porque cuando se requiera hacer un
cambio, si el cdigo fuente es muy complejo, posiblemente
lleve muchas horas realizar los cambios e incluso una
alternativa seria ya no hacer ningn cambio para no perder
tiempo. Esta es precisamente la razn por la cual el cdigo
simple, es fundamental en la metodologa.
Bsicamente, lo que es la simplicidad y la comunicacin van
de la mano. Puesto que a mayor simplicidad, la comunicacin
necesaria ser menor. Haciendo que la eficiencia se incremente
y la perdida de tiempo en comunicacin sea menor. Por eso es
importante seguir al pie de la letra estas dos ideales de la
metodologa.
Equipo de Trabajo dentro de una Metodologa XP

Ya para concluir con esta metodologa, recordemos que es una

de las mejores que podran existir y que realmente vale la pena
implementar. Veamos cuales son los roles que componen el
equipo de trabajo en un proyecto que se elaborar mediante la
metodologa XP, para que tengas una idea de la formacin que
se debe efectuar.
Programador. Realmente no creo que sea necesario que te
diga lo que hace el programador. Bueno, es el encargado del
cdigo del sistema y adems de hacer las pruebas unitarias que
se solicitan.
Tester. Bsicamente es el encargado de las pruebas del
desarrollo. Lo que se vaya implementando, el teste lo prueba y
le dice al cliente o mejor dicho, le comunica al cliente las
pruebas funcionales, para posteriormente comunicarle al
equipo los resultados.
Tracker. El seguimiento ser lo suyo. Ser el encargado de
realizar las comparaciones entre los tiempos estimados antes de
empezar un desarrollo y los tiempos reales que se obtuvieron.
Tratando siempre de mantener al tanto al equipo para que traten
de mejorar los tiempos.
Entrenador. Este elemento es realmente importante, puesto
que es el responsable del proyecto bsicamente y precisamente
hace las funciones de un entrenador. Se encarga de guiar al
equipo por el camino que deben seguir.
 Consultor. Regularmente el consultor no formaba parte del
equipo, bueno de hecho no lo integra. El consultor sigue siendo
un externo, pero que cuenta con conocimientos especficos y
que ser capaz de ayudar en la solucin de problemas.
Gestor. Posiblemente el lder ms alto. Si se trata de unir a
los clientes con los programadores, el gestor es el intermedio,
es decir. Es el encargado de vincular e interrelacionar al cliente
con los programadores.

Conclusiones
As que ahora ya sabes muy bien como funciona cada una de
las metodologas bsicas y de los procesos o fases que
conlleva cada una de ellas, as como las metodologas giles
y las ventajas de utilizarlas, por supuesto que hoy en da
son las ms usadas. Sin embargo algunas metodologas
existentes actualmente que no son tan famosas, estn basadas
en estas principalmente, razn por la cual no se les hace mucha
mencin. De cualquier forma, al final del da, tanto tu, como tu
equipo de desarrollo de sistema, debern hacer el anlisis
inicial y determinar bajo que esquema quieren empezar a
desarrollar. Si formas parte de una agencia de desarrollo de
software, todo depender del tipo y tamao de software que el
cliente requiera, si no es as, entonces solamente debers elegir
uno para establecer cierto orden en tus procesos o tomar fases
de varios procesos como el de cascada y prototipos y crear tu
propia metodologa, pues esto es precisamente lo que muchos
hacen.

El proceso de desarrollo de software consiste

en una estructura de pasos para obtener un
producto
CLICK TO TWEET
Existen distintos ciclos de vida que pueden ser aplicados a la construccin de
software. No hay un ciclo mejor que otro, sino que cada uno se adapta a unas
caractersticas particular del producto a obtener. A continuacin, vamos a
describir algunos de los ciclos de vida ms conocidos, que pueden ser lo que
ests buscando para obtener tu aplicacin software.

Cmo afrontar el desarrollo de software

Modelo en cascada
Este ciclo de vida est planteado en bloques individuales que se van
concatenando en el tiempo. Los grupos de actividades son los siguientes:

Requisitos: se definen completamente todas las necesidades del proyecto.

Pueden ser tareas que ha de realizar la aplicacin (o producto), e incluso las
limitaciones que existen, como por ejemplo, que una web est desarrollada con
PHP.
Diseo: en este paso se realiza la descripcin de los componentes necesarios,
la arquitectura, el modelado de los datos, etc. Se obtienen respecto a los
requisitos ya definidos.
Implementacin: aqu el equipo de desarrollo codifica la solucin con las
tecnologas necesarias.
Verificacin: se comprueba que todo funcione como est definido en los
requisitos.
Mantenimiento: como es improbable detectar todos los errores en el proceso
de desarrollo, se realiza un periodo de mantenimiento que el cliente y la
empresa acuerden. Adems de depurar fallos, tambin se incluye aqu la
formacin en el uso de la aplicacin.
Como se puede observar, es muy importante definir bien todo lo que se quiere
en la primera fase. Hay que definir todas las necesidades de la forma ms
detallada posible. Este es un punto clave para obtener los resultados
bosquejados previamente. Cuando el cliente define todo de una forma precisa,
el desarrollador sabe lo que tiene que hacer sin equvocos, por lo que los
plazos no se alargan, los cambios de ltima hora no son un lastre y el proyecto
se realiza correctamente. Tambin es importante que quien realice el
desarrollo, bien sea un freelance o una empresa, ayude al cliente a definir los
requisitos, ya que son ellos los que tienen la experiencia en desarrollo de
software.

Modelo incremental o iterativo

Este modelo es una adaptacin del modelo en cascada para cuando no
tenemos totalmente claros los requisitos o queremos realizar un proyecto en
fases. La estrategia a seguir con el modelo incremental esestablecer varias
entregas del producto, cada una con mayor funcionalidad que la anterior. Por
lo tanto, al acabar el primer incremento, se empieza a desarrollar el siguiente, y
as sucesivamente hasta tener el producto finalizado.
Esto permite dividir el resultado en distintos paquetes y poder ver evolucionar el
resultado con cada entrega. La principal clave al utilizar este modelo es definir
previamente unos plazos de entrega y un presupuesto, ya que si vamos
iterando sobre la solucin, podemos llegar a un punto en el que el desarrollo se
alargue tanto que no se obtendr el producto final. Este detalle permite que se
puedan modificar requisitos en cada entrega, teniendo en cuenta que si se
modifica algn requisito, se consume tiempo y presupuesto, teniendo como
obligacin descartar otros requisitos para que el producto se realice dentro del
plazo y presupuesto previstos.

Modelo por prototipos

El modelo por prototipos se utiliza principalmente para tener una visin del
producto pero sin funcionalidad. Con este modelo el cliente puede ver cmo
va a quedar su aplicacin y hacer las modificaciones pertinentes.
La estructura de este modelo se establece como el desarrollo de una versin
previa sin funcionalidad que se entrega al cliente. Al revisar este prototipo se
realizan correcciones, cambios en el formato, etc., pero sin aadir
funcionalidad. Cuando se llega al prototipo deseado, se aade toda la
funcionalidad.

Una estrategia eficaz para este modelo es definir un plazo para obtener el
prototipo final, con varios prototipos previos, y despus establecer los plazos
para el desarrollo de la solucin, que suele ser aplicando un modelo en
cascada.

Metodologas giles
Cuando se habla de metodologas giles suele referirse a metodologas que
suscriben el manifiesto gil: estamos descubriendo formas mejores de
desarrollar software tanto por nuestra propia experiencia como ayudando a
terceros. A travs de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas Software
funcionando sobre documentacin extensiva Colaboracin con el cliente sobre
negociacin contractual Respuesta ante el cambio sobre seguir un plan. Esto
es, aunque valoramos los elementos de la derecha, valoramos ms los de la
izquierda. Hay variosmodelos que destacan dentro de las metodologas
gil, como son Scrum y Kanban.
Scrum es un modelo que define perodos dentro del desarrollo, reuniones y
roles, as como una documentacin propia. Se centra en lo que el equipo de
trabajo es capaz de hacer y no en crear una gran documentacin la cual hay
que seguir al pie de la letra.
Kanban, por otra parte, tiene elementos similares, pero es una estrategia de
trabajo visual, que se centra en seguir la evolucin de las tareas
individualmente hasta que finalizan, pasando por distintos estados y siendo
asignadas a miembros del equipo.
Para utilizar estas metodologas, el cliente debe ser participativo, as como el
equipo de desarrollo, que debe ser unido, y hacer participar al cliente de forma
activa.

Conclusiones
De este resumen podemos deducir que no hay metodologas mejores o peores,
sino que cada una se adapta a un proyecto por sus propias caractersticas.
Tambin hay que tener en cuenta que en todo el proceso, es muy importante el
cliente, que participa de distinta forma segn la metodologa, por lo que trabajar
con un profesional o empresa, sabiendo qu proceso de desarrollo utiliza es
beneficioso para obtener un buen resultado.
En esto tambin incluye a quin se contrate, pues las dos partes deben tener
en cuenta que se trabaja con personas, y su gestin dentro de las
metodologas es muy importante, porque son ellas las que pueden tener
errores y las capacitadas para corregirlos que, como acabamos de ver, es algo
que los ciclos de vida tienen muy en cuenta.