Ao de la Consolidacin del Mar de Grau

Metodologa de
desarrollo de software

CURSO:

METODOLOGA DE DESARROLLO DE SOFTWARE.

CATEDRTICO:
Lic. Kevin Vladimir ESPINOZA LPEZ.
ESTUDIANTE:
YAPIAS AVILEZ Lennie Juice.
CICLO :
III

SECCIN:

Junn Per
2016

INTRODUCCIN
Dentro del desarrollo de software y a la altiva necesidad de que los
proyectos lleguen al xito y obtener un producto de gran valor para
nuestros clientes, generan grandes cambios en las metodologas
adoptadas por los equipos para cumplir sus objetivos, puesto que,
unas se adaptan mejor que otras, al contexto del proyecto brindando
mejores ventajas.
Es por eso de la importancia de una metodologa robusta que
ajustada en un equipo cumpla con sus metas, y satisfaga mas all de
las necesidades definidas al inicio del proyecto.
El xito del producto depende en gran parte de la metodologa
escogida por el equipo, ya sea tradicional o gil, donde los equipos
maximicen su potencial, aumenten la calidad del producto con los
recursos y tiempos establecidos.
Una metodologa es un conjunto de procedimientos, tcnicas,
herramientas y un soporte documental que ayuda a los
desarrolladores a realizar un nuevo software. Puede seguir uno o
varios modelos de ciclo de vida, es decir, el ciclo de vida indica qu es
lo que hay que obtener a lo largo del desarrollo del proyecto pero no
cmo hacerlo. La metodologa indica cmo hay que obtener los
distintos productos parciales y finales. Finalmente depender de la
metodologa utilizada los productos del proyecto, por esta razn es
necesario, conoces a fondo cada una de ellas y poder diferenciar
entre una y otra, para de este modo saber elegir la correcta en el
momento de desarrollar un nuevo software, de otra manera el
producto no ser el mejor e incluso puede ser intil

PARADIGMA
1. Definicin
Un paradigma de programacin indica un mtodo de realizar
cmputos y la manera en que se deben estructurar y organizar las
tareas que debe llevar a cabo un programa
Los paradigmas fundamentales estn asociados a determinados
modelos de cmputo.
Tambin se asocian a un determinado estilo de programacin
Los lenguajes de programacin suelen implementar, a menudo de
forma parcial, varios paradigmas.
1.1.

Paradigma

tecnolgica

de

programacin: es

adoptada

por

de programadores y desarrolladores cuyo

una

propuesta

una
ncleo

comunidad
central

es

incuestionable en cuanto que nicamente trata de resolver uno o

varios problemas claramente delimitados; la resolucin de estos
problemas

debe

suponer

consecuentemente

un

avance

significativo en al menos un parmetro que afecte a la ingeniera

de software.
Un paradigma de programacin representa un enfoque particular o
filosofa para disear soluciones. Los paradigmas difieren unos de
otros, en los conceptos y la forma de abstraer los elementos
involucrados en un problema, as como en los pasos que integran
su solucin del problema, en otras palabras, el cmputo.
Tiene una estrecha relacin con la formalizacin de determinados
lenguajes

en

su

momento

de

definicin.

Es

un

estilo

de

programacin empleado.
Un paradigma de programacin est delimitado en el tiempo en
cuanto a aceptacin y uso, porque nuevos paradigmas aportan
nuevas o mejores soluciones que la sustituyen parcial o totalmente.

El paradigma de programacin que actualmente es el ms utilizado

es la "orientacin a objetos" (OO). El ncleo central de este
paradigma es la unin de datos y procesamiento en una entidad
llamada "objeto", relacionable a su vez con otras entidades
"objeto".
Tradicionalmente, datos y procesamiento se han separado en reas
diferente del diseo y la implementacin de software. Esto provoc
que

grandes

desarrollos

tuvieran

problemas

de

fiabilidad,

mantenimiento, adaptacin a los cambios y escalabilidad. Con la

OO y caractersticas como el encapsulado, polimorfismo o la
herencia, se permiti un avance significativo en el desarrollo de
software a cualquier escala de produccin. La OO parece estar
ligada en sus orgenes con lenguajes como Lisp y Simula, aunque el
primero que acu el ttulo de "programacin orientada a objetos"
fue Smalltalk.
2. Tipos ms comunes de paradigmas de programacin:
En general la mayora son variantes de los dos tipos principales,
imperativa y declarativa:
2.1. Programacin imperativa o por procedimientos: Es el
ms usado en general, se basa en dar instrucciones al ordenador
de como hacer las cosas en forma de algoritmos. La programacin
imperativa es la ms usada y la ms antigua, el ejemplo principal
es el lenguaje de mquina.
Ejemplos

de

lenguajes

puros

de

este

paradigma

seran

el C, BASIC o Pascal.
2.2. Programacin orientada a objetos: Est basada en el
imperativo, pero encapsula elementos denominados objetos que
incluyen tanto variables como funciones. Est representado por C+
+, C# o Java, entre otros, pero el ms representativo sera
el Smalltalk que est completamente orientado a objetos.

2.3. Programacin dinmica: est definida como el proceso de

romper

problemas

en

partes

pequeas

para

analizarlos

resolverlos de forma lo ms cercana al ptimo, busca resolver

problemas en O(n) sin usar por tanto mtodos recursivos. Este
paradigma est ms basado en el modo de realizar los algoritmos,
por lo que se puede usar con cualquier lenguaje imperativo.
2.4. Programacin

dirigida

por

eventos:

la programacin

dirigida por eventos es un paradigma de programacin en el que

tanto la estructura como la ejecucin de los programas van
determinados por los sucesos que ocurran en el sistema, definidos
por el usuario o que ellos mismos provoquen.
2.5. Programacin declarativa: est basado en describir el
problema declarando propiedades y reglas que deben cumplirse,
en lugar de instrucciones. Hay lenguajes para la programacin
funcional,
funcional.

la programacin
Unos

de

los

lgica,

la

primeros

combinacin

lenguajes

lgico-

funcionales

fueron Lisp y Prolog.

2.6. Programacin

funcional:

basada

en

la

definicin

los

predicados y es de corte ms matemtico, est representado

por Scheme una variante de Lisp o Haskel.
2.7. Programacin lgica: basado en la definicin de relaciones
lgicas, est representado por Prolog.
2.8. Programacin con restricciones: similar a la lgica usando
ecuaciones. Casi todos los lenguajes son variantes del Prolog.
2.9. Programacin multiparadigma: es el uso de dos o ms
paradigmas dentro de un programa. El lenguaje Lisp se considera
multiparadigma.
2.10.

Lenguaje especfico del dominio o DSL: se denomina

as a los lenguajes desarrollados para resolver un problema

especfico, pudiendo entrar dentro de cualquier grupo anterior. El

ms representativo sera SQL para el manejo de las bases de datos,

de tipo declarativo, pero los hay imperativos, como el Logo.
Si bien puede seleccionarse la forma pura de estos paradigmas al
momento de programar, en la prctica es habitual que se mezclen,
dando lugar a la programacin multiparadigma o lenguajes de
programacin multiparadigma.
Actualmente, el paradigma de programacin ms utilizado es el
paradigma de la programacin orientada a objetos.
3. ESQUEMA:
Paradigma

Paradigma
declarativo

Paradigma
imperativo

Orientado
a objetos

Funcion
Lgic
Orientado
al
o
a
METODOLOGA
enventos

Base de
datos

1. Definicin:
Las metodologas son las teoras del aprendizaje que orientan el
mtodo,

entre

ellas, la

teora

constructivista,

conductual,

cognitiva, desarrollista, social, crtica, etc.

Segn

KAPLAN,

la

metodologa es

el

estudio,

descripcin,

explicacin y justificacin de los mtodos y no los mtodos en s

mismos.
Es entender a la metodologa como conjunto de tcnicas o
procedimientos especficos que se emplean en una ciencia; que
entenderla como descripcin, explicacin y justificacin de los
mtodos en general.
Esquema:

2. Metodologa de Programacin
Una metodologa de programacin es un conjunto o sistema de
mtodos, principios y reglas que permiten enfrentar de manera
sistemtica el desarrollo de un programa que resuelve un
problema

algortmico. Estas

metodologas

generalmente

se

estructuran como una secuencia de pasos que parten de la

definicin del problema y culminan con un programa que lo
resuelve.

Esquema.

3. Estructuras de un programa:Un programa se va a dividir en 3 partes claramente diferenciadas:

Procesos de entrada

Proceso de datos

Procesos de salida

Todo programa est constituido por un conjunto de instrucciones

capaces de gestionar un conjunto de datos.
Estas son las metodologas ms conocidas y habituales:
Esquema:

En la actualidad se cuenta con diversos tipos de mitologas para el

desarrollo de software, lo cual genera una gran problemtica sobre
cual debemos utilizar a la hora de disear un software, para esto
es necesario conocer a fondo las diversas metodologas existentes,
saber cmo funciona cada una, y as poder elegir correctamente la
ms adecuada segn la necesidad que se tenga. En la presente
investigacin se dan a conocer las tecnologas de desarrollo de
software ms utilizadas as como su funcionamiento, con el fin de
solucionar la problemtica anteriormente mencionada.
4. Metodologa convencional:
Aos 50
Desarrollo artesanal y ausencia de Metodologa

Enfocado en la Tarea de Programacin

Inconvenientes:

Los resultados finales son impredecibles

No hay forma de controlar lo que est sucediendo en el

Proyecto

Los cambios organizativos afectan negativamente al proceso de

desarrollo

METODOLOGIA SSADM

El gobierno britnico a principios de los 80 plantea estandarizar

proyectos de tecnologa de informacin bajo la necesidad de crear
una metodologa y se desarroll entre el Central Computing and
Telecommunications Agency (CCTA) y Learmonth and Burchett
Management Systems (LBMS), dando como resultado la metodologa
SSADM (Structures Systems Analysis and Design Method).
1. Origen
Tomando como fuente las bases tericas y las experiencias de RAD
(Rapad Application Development) el consorcio se fund en enero
de 1994 con la finalidad de desarrollar un modelo de desarrollo
independiente de herramientas y que fuera de dominio pblico.
2. Principios
De los procesos DSDM se basa en principios.

La implicacin activa de los usuarios es imprescindible.

Los miembros de los equipos de desarrollo DSDM deben tener la

autonoma y potestad necesarias para tomar decisiones.

Entrega frecuente de incrementos operativos del producto.

El principal criterio de prioridad, desarrollo y validacin de las

entregas incrementales es los objetivos y la salud del negocio

Los aspectos claves de SSADM v 4 Son:

nfasis en los usuarios: sus requisitos y participacin.

Definicin del proceso de produccin: qu hacer, cundo y
cmo.

Tres puntos de vista: datos, eventos, procesos.

Mxima

flexibilidad

en

herramientas

tcnicas

de

implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a cabo
el anlisis y diseo, pero no cubre aspectos como la planificacin
estratgica ni entra en la construccin del cdigo.
Los aspectos del SSADM son:
nfasis en los usuarios: requisitos y participacin

 Definicin del proceso de produccin: que hacer, como , cuando

Tres puntos de vista: dato, evento, proceso.
Mxima

flexibilidad

en

herramientas

tcnicas

de

implementacion.
El SSADM no cubre aspectos como la planificacin estratgica ni la
construccin del cdigo.
3. Procesos del ciclo de desarrollo DSDM
El ciclo de desarrollo de DSDM est compuesto de 5 fases,
precedidas de un pre-proyecto y un post-proyecto.
Pre-proyecto
Estudio de viabilidad
Estudio de negocio
Iteracin de modelado funcional
Iteracin de diseo y desarrollo
Implementacin
Post-desarrollo
4. Anlisis de sistemas estructurado y mtodo de diseo
(SSADM)
Originalmente lanzada como metodologa es un enfoque de
sistemas para el anlisis y diseo de sistemas de informacin.
SSADM fue producida para la agencia central de informtica y
telecomunicaciones ahora oficina de comercio gubernamental,
un gobierno del Reino Unido la oficina de que se trate con el uso
de la tecnologa en el gobierno, a partir de 1980.

SSADM es un mtodo de cascada para el anlisis y diseo

de sistemas
representa

de
el

informacin.
pinculo

se

del

considera

enfoque

que

riguroso

SSADM
en

la

documentacin hacia el diseo del sistema que contrasta con

mtodos giles como DSDM o Scrum.
SSADM es una aplicacin en particular y se basa en el trabajo
de las diferentes escuelas de anlisis estructurados mtodos y
desarrollo, como la de Peter Checkland Metodologa blanda de
sistemas, de Larry Constantino diseo estructurado, de Edward
Yourdon Mtodo

estructurado

de

Yourdon ,

de

Michael

A.

Jackson Programacin Estructurada de Jackson, y Tom De

Marco anlisis estructurado.
Los nombres "Sistemas estructurados mtodo de anlisis y
diseo"

"SSADM"

son marcas

registradas de

la Oficina

Gubernamental de Comercio (OGC), que es una oficina de

Hacienda del Reino Unido.

METODOLOGA MERISE
Esta metodologa surge en Francia en 1977 a propuesta del Ministerio
de Industria, como un intento de unificar criterios en torno a la
metodologa de desarrollo para los sistemas informticos de la
Administracin Pblica Francesa.
Sus principios generales son:

Desglose en etapas: estudio preliminar, estudio detallado,

realizacin y puesta en marcha.

Divisin en el estudio de los tratamientos por un lado y el

estudio de los datos por otro.

Uso del modelo Entidad/Relacin y sus formalismos para

representar los datos.

Uso de los Diagramas de Encadenamiento de Procedimientos

para representar los tratamientos.

Completo reparto de tareas y responsabilidades entre los

desarrolladores durante la fase inicial, y entre los ususarios y
ordenador en la explotacin. (Esquema director)
NIVEL
CONCEPTUAL
ORGANIZACION
AL
OPERACIONAL

TRATAMIENT
OS
Modelo
Conceptual
Modelo
Organizacional

DATOS

OPCIN

Modelo
Conceptual
Modelo
Lgico

De gestin

Modelo
Operacional

Modelo
Fsico

De
organizaci
n
Tcnica

1. Metodologa SSADM. (Mtodo Estructurado de Anlisis y Diseo de Sistemas).

Aparece en Gran Bretaa por los mismos motivos que MERISE y se establece como
obligatoria para la Administracin Pblica a partir de 1983.
Los aspectos claves de esta metodologa son:
nfasis en los usuarios: sus requisitos y participacin.
Definicin del proceso de produccin.
Tres puntos de vista: datos, eventos y procesos.
Mxima flexibilidad en herramientas y tcnicas de implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el anlisis y diseo,
pero no cubre aspectos como la planificacin estratgica ni entra en la construccin del
cdigo.
Es la metodologa adoptada como estndar por la Administracin Pblica Espaola.
Consiste en un conjunto de fases donde se utilizan multitud de tcnicas conducentes a la
obtencin de aplicaciones de calidad, fciles de mantener y muy bien documentadas.
1.1.Objetivos de Mtrica:
La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til
para la sistematizacin de las actividades que dan soporte al ciclo de vida del software
dentro de un marco que permite alcanzar los siguientes objetivos:
Proporcionar o definir Sistemas de Informacin que sirvan a la consecucin de los fines
de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de
los mismos.
Dotar a la Organizacin de Productos software que satisfagan las necesidades de los
usuarios dando una mayor importancia al anlisis de requisitos.
Mejorar la productividad permitiendo una mayor capacidad de adaptacin a los cambios
y teniendo en cuenta la reutilizacin en la medida de lo posible.
Facilitar la comunicacin y entendimiento entre los distintos participantes en la
produccin de software a lo largo de todo el ciclo de vida.

Facilitar la operacin, mantenimiento y uso de los Productos software obtenido.

1.2.

Caractersticas.
MTRICA contempla el desarrollo de Sistemas de Informacin para
las distintas tecnologas que actualmente estn conviviendo y los
aspectos de gestin que asegurarn que un Proyecto cumple sus
objetivos en trminos de calidad y coste.
Su punto de partida es la versin anterior de MTRICA de la cual se
ha conservado la adaptabilidad, flexibilidad y sencillez. Se ha tenido
en cuenta la experiencia de los usuarios de las versiones anteriores
para solventar los problemas o deficiencias detectados.
En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los
mtodos de desarrollo ms extendidos, as como los ltimos
estndares de ingeniera del software y calidad, as como referencias
especficas en cuanto a seguridad y gestin de proyectos.

1.3. Estructura:

En una nica estructura la metodologa MTRICA Versin 3 cubre

distintos tipos de desarrollo: estructurado y orientado a objetos, y
facilita a travs de interfaces la realizacin de los procesos de apoyo
u organizativos.

Procesos principales.

Interfaces.

1.4. Procesos principales:

Cada Proceso detalla las Actividades y Tareas a realizar.

Para cada tarea se indican:

Las tcnicas y prcticas a utilizar.

Los responsables de realizarla.

Sus productos de entrada y salida.

1.5. Estructura de procesos:

Planificacin PSI

Desarrollo

Estudio de viabilidad EVS

Anlisis ASI

Diseo DSI

Construccin CSI

Implantacin y aceptacin IAS

Mantenimiento MSI

1.6. Interfaces:

Aseguramiento de la Calidad

Seguridad

Gestin de Configuracin

Gestin de Proyectos

METODOLOGAS PESADAS
En

esta

leccin

se

abordan

las

metodologas

pesadas

ms

tradicionales para el desarrollo de software, procesos rigurosos con

abundante documentacin y formalismo pensada para garantizar la
calidad a la hora de fabricar aplicaciones y sistemas muy sofisticados.
Son las ms tradicionales, se centran en la definicin detallada de los
procesos y tareas a realizar, herramientas a utilizar, y requiere una extensa
documentacin, ya que pretende prever todo de antemano. Este tipo de
metodologas son ms eficaces y necesarias cuanto mayor es el proyecto
que se pretende realizar respecto a tiempo y recursos que son necesarios
emplear,

donde

una

gran

organizacin

es

requerida.

Una

de

las

metodologas pesadas ms conocidas y utilizadas es la Metodologa RUP

(Rational Unified Process) que divide el desarrollo en 4 fases que definen su

ciclo de vida:

Inicio: El objetivo es determinar la visin del proyecto y definir lo

que se desea realizar.

Elaboracin: Etapa en la que se determina la arquitectura ptima

del proyecto.

Construccin: Se obtiene la capacidad operacional inicial.

Transmisin: Obtener el producto acabado y definido.

1. Metodologas pesadas populares
Entre las metodologas tradicionales ms populares se encuentran
el mencionado Rational Unified Process (RUP) o tambin Microsoft
Solutions Framework (MSF), que centran su atencin en mantener
una documentacin exhaustiva del proyecto y cumplir con el plan
previsto y definido con precisin en la fase inicial del desarrollo del
proyecto. Digamos que las metodologas tradicionales suelen
enfatizar

la documentacin,

la

planificacin

y seguimiento

riguroso de mltiples actividades (mediante plantillas, tcnicas de

administracin, revisiones formales, etc
Aunque los modelos generalmente son realistas y estn pensado
para

avanzar

en

la

construccin

del

software

de

una

manera iterativa e incremental, algunas de las caractersticas

negativas dentro de estos enfoques son los altos costos de
implementar cualquier cambio y el no ofrecer una buena solucin
para proyectos que operan en un entorno extremadamente
incierto.
2. Arquitectura orientada a servicios

2.1.

Ciclo de vida SOA

Varios de los modelos de proceso importantes se centran en la idea de

"arquitectura", muy a menudo en arquitecturas de componentes o en
las llamadas arquitecturas orientadas a servicios (Service-Oriented
Architecture o SOA). Por eso en esta seccin se explica brevemente lo
que son las arquitecturas orientadas a servicios.
Un servicio es un componente que provee un conjunto de funciones de
negocios. Conceptualmente son autnomos, opacos y bajamente
acoplados.
3. Arquitectura de referencia

4. Arquitectura de referencia SOA

SOA permite que los servicios de informacin satisfagan ms

gilmente las necesidades del negocio, cerrando cada vez ms la
brecha entre la estrategia del negocio y la tecnologa subyacente
al mismo. La idea es crear servicios basados en estndares,
interoperables e independientes de un proveedor especfico, para
fomentar

la

reutilizacin

de

servicios

que

permitan

crear

eficazmente nuevas aplicaciones o funcionalidades en nuestro

negocio.
5. Implementacin
Para implementar SOA es necesario evaluar el grado de madurez
de la organizacin y definir los grados que aspira alcanzar con el
tiempo. Se comenzara implementado un proyecto piloto, usando
SOA para servicios simples que impacten nicamente un rea del
negocio. En el caso de sistemas heredados se podran habilitar
como servicios aquellas funciones de negocio que requiere el
proyecto piloto, y esta sera una manera de ir introducindose en
el uso de esta arquitectura.
6. Servicios Web
Los Servicios Web (Web Services) juegan un papel importante en
SOA,

ya

que

brindan

mecanismos

independientes

de

la

plataforma con los que exponer, descubrir e invocar servicios.

SOA requiere que un servicio:

Sea descubrible e invocable dinmicamente como ocurre con

UDDI, WSDL, SOAP.

Tenga

una

definicin

del

contrato

independiente

de

plataforma tpicamente XML.

Pueda interpretar con otros servicios por ejemplo mediante

HTTP.

Lucasian: Un ejemplo de plataforma de servicios SOA

Metodologa RUP
Es un producto del proceso de ingeniera de software que proporciona
un

enfoque disciplinado para asignar tareas y responsabilidades

dentro de una organizacin del desarrollo. Su meta es asegurar la

produccin del software de alta calidad que resuelve las necesidades
de los usuarios dentro de un presupuesto y tiempo establecidos.
Esquema:

1. Dimensiones

2. El RUP tiene dos dimensiones:

La primera dimensin (eje horizontal) representa el aspecto
dinmico del proceso y se expresa en trminos de fases,
iteraciones y la finalizacin de las fases.

La segunda dimensin (eje vertical) representa el aspecto esttico

del proceso: cmo se describe en trminos de componentes de
proceso, disciplinas, actividades, flujos de trabajo, artefactos, y los
roles.
3. Caractersticas:
El RUP contiene tres caractersticas principales:
Proceso dirigido por Casos de Uso
Segn Kruchten Philippe (2000), Se define un caso de uso como
un fragmento de funcionalidad del sistema que proporciona al
usuario un valor aadido. Los Casos de Uso representan los
requisitos funcionales del sistema.
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 Inician el proceso de desarrollo y proporcionan

un hilo conductor, permitiendo establecer trazabilidad entre los
artefactos que son generados en las diferentes actividades del
proceso de desarrollo.
Basndose en los casos de uso, se crean los modelos de anlisis
y diseo, luego la implementacin que los lleva a cabo, y se
verifica

que

efectivamente

el

adecuadamente cada caso de uso.

4. Proceso centrado en la arquitectura

producto

implemente

La arquitectura de un sistema es la organizacin o estructura de

sus partes ms relevantes, lo que permite tener una visin comn
entre todos los involucrados desarrolladores y usuarios y una
perspectiva clara del sistema completo, necesaria para controlar el
desarrollo.
El caso RUP, adems es 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

el

mantenimiento.
La arquitectura dentro de RUP se representa en varias vistas.
Todas las vistas juntas forman el llamado modelo 4+1 de la
arquitectura. Segn Kruchten Philippe 1998el cual recibe este
nombre porque lo forman las vistas lgica, de implementacin, de
proceso y de despliegue, ms la de casos de uso que es la que da
cohesin a todas.

Al final de la fase de elaboracin se obtiene una baseline (base

de referencia) de la arquitectura donde fueron seleccionados una
serie de casos de uso arquitectnicamente relevantes (aquellos
que ayudan a mitigar los riesgos ms importantes, aquellos que
son los ms importantes para el usuario y aquellos que cubran las
funcionalidades significativas).
5. Proceso iterativo e incremental
El equilibrio correcto entre los casos de uso y la arquitectura es
muy parecido al equilibrio de la forma y la funcin en el desarrollo
de un producto, lo cual se consigue con el tiempo. Para esto, la

estrategia que se propone en RUP es tener un proceso iterativo e

incremental en donde el trabajo se divide en partes ms pequeas
o mini proyectos. Cada mini proyecto se puede ver como una
iteracin (un recorrido ms o menos completo a lo largo de todos
los flujos de trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el producto.

Cada iteracin aborda una parte de la funcionalidad total, pasando

por todos los flujos de trabajo relevantes y refinando la
arquitectura. Cada iteracin se analiza cuando se termina.
Durante la planificacin de los detalles de la siguiente iteracin, el
equipo tambin examina cmo afectarn los riesgos que an
quedan al trabajo en curso. Toda la retroalimentacin de la
iteracin

pasada

permite

reajustar

los

objetivos

para

las

siguientes iteraciones. Se contina con esta dinmica hasta que

se haya finalizado por completo con la versin actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se
realizan varias iteraciones que son una cantidad variable segn el
proyecto, y en las que se hace un mayor o menor hincapi en los
distintas actividades.
Las primeras iteraciones en las fases de Inicio y Elaboracin se
enfocan hacia la comprensin del problema y la tecnologa, la

delimitacin del mbito del proyecto, la eliminacin de los riesgos

crticos, y al establecimiento de una baseline base de referencia
de la arquitectura.
Para cada iteracin se escogen algunos casos de uso, se refina su
anlisis y diseo, y se procede a su implementacin y pruebas. Se
realizan

tantas

iteraciones

hasta

que

se

termine

la

implementacin de la nueva versin del producto.

En la fase de transicin se pretende garantizar que se tiene un
producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar, en cada fase participan todas las
disciplinas, pero, dependiendo de la fase, es el esfuerzo dedicado
a una disciplina.

6. Fases
El ciclo de vida del software del RUP se descompone en cuatro
fases secuenciales. En cada extremo de una fase se realiza una
evaluacin para determinar si los objetivos de la fase se han
cumplido. Una vez que la evaluacin obtiene los resultados
deseados, se procede a la siguiente fase.
7. Planeando las fases
El ciclo de vida consiste en una serie de ciclos, cada uno de los
cuales produce una nueva versin del producto, cada ciclo est
compuesto por fases:
1. Concepcin, Inicio o Estudio de oportunidad: Define el mbito
y objetivos del proyecto, adems de la funcionalidad y
capacidades del producto.

2. Elaboracin: Tanto la funcionalidad como el dominio del

problema se estudian a profundidad. Se define una arquitectura
bsica y se planifica

el proyecto

considerando

recursos

disponibles.
3. Construccin: El producto se desarrolla a travs de iteraciones
donde cada iteracin involucra tareas de anlisis, diseo e
implementacin Las fases de concepcin y elaboracin slo
dieron una arquitectura bsica que es refinada aqu de manera
incremental conforme se construye (se permiten cambios en la
estructura). Gran parte del trabajo es programacin y pruebas,
se documenta tanto el sistema construido como el manejo del
mismo En esta fase se hace una documentacin junto con el
producto.
4. Transicin: Se libera el producto y se entrega al usuario para
un uso real. Se incluyen tareas de mercadotecnia, empaquetado
atractivo, instalacin, configuracin, entrenamiento, soporte,
mantenimiento, etc.
8. Esfuerzo respecto de los flujos de trabajo o disciplinas
En la imagen posterior del documento se muestra el porcentaje el
esfuerzo que se tiene que realizar por cada una de las disciplinas o
flujos de trabajo, y los dos porcentajes que se muestran de forma
horizontal son para todo el proyecto.
Se puede observar que para la obtencin de requisitos en la fase de
concepcin se empiezan a conseguir, en la fase de elaboracin tiene
su auge, y va declinando en la fase de construccin. Con las dems
sucede algo similar en distintas iteraciones.

Esfuerzo respecto de las fases

9. Disciplinas
Las disciplinas son los flujos del trabajo, los cuales son una
secuencia de pasos para la culminacin de cada disciplina, estas
disciplinas se dividen en dos grupos: las primarias y las de apoyo.
Las primarias son las necesarias para la realizacin de un proyecto
de software, aunque para proyectos no muy grandes se pueden
omitir algunas; entre ellas se tienen: modelado del negocio,
requerimientos, anlisis y diseo, implementacin, pruebas y

despliegue. Las de apoyo son las que complementan y brindan

mejoras a las primarias y especifican otras caractersticas en la
realizacin de un proyecto de software; entre estas se tienen:
entorno, gestin del proyecto, gestin de configuracin y cambios.
10.

Modelado del negocio

Tiene como objetivos comprender la estructura y la dinmica de la

organizacin, comprender problemas actuales e identificar posibles
mejoras, comprender los procesos del negocio.
11.

Requerimientos

Sus objetivos son: establecer lo que el sistema debe hacer, se

definen los lmites del sistema, y una interfaz de usuario. Tambin
realiza una estimacin del costo y tiempo de desarrollo.
12.

Anlisis y diseo

Define la arquitectura del sistema y tiene como objetivos trasladar

requisitos en especificaciones de implementacin, al decir anlisis
se refiere a transformar CU (casos de uso) en clases, y al decir
diseo se refiere a refinar el anlisis para poder implementar los
diagramas de clases de anlisis de cada CU, los diagramas de
colaboracin de cada CU, el de clases de diseo de cada CU, el de
secuencia de diseo de CU, el de estados de las clases, etc.
13.

Implementacin

Tiene como objetivos implementar las clases de diseo como

componentes, asignar los componentes a los nodos, probar los
componentes individualmente (pruebas unitarias) e integrar los
componentes en un sistema ejecutable.

14.

Pruebas

Verificar

la

integracin),

integracin
verificar

de

que

los
todos

componentes
los

(prueba

requisitos

han

de
sido

implementados (pruebas del sistema), asegurar que los defectos

detectados han sido resueltos antes de la distribucin.
15.

Despliegue

Sus objetivos son asegurar que el producto est preparado para el

cliente, para proceder a su entrega y recepcin por el cliente. En
esta disciplina se realizan las actividades de probar el software en
su entorno final (Prueba Beta), empaquetarlo, distribuirlo e
instalarlo, as como la tarea de ensear al usuario.
16.

Gestin y configuracin de cambios

ste es esencial para controlar el nmero de artefactos producidos

por la cantidad de personal que trabajan en un proyecto
conjuntamente. Los controles sobre los cambios son de mucha
ayuda ya que evitan confusiones costosas, como la compostura de
algo que ya se haba arreglado.
17.

Entorno

Esta disciplina se enfoca sobre las actividades necesarias para

configurar el proceso que engloba el desarrollo de un proyecto y
describe las actividades requeridas para el desarrollo de las pautas
que apoyan un proyecto.
Su propsito es proveer a la organizacin que desarrollar el
software, un ambiente en el cual basarse, el cual provee procesos
y herramientas para poder desarrollar el software.
18.

Organizacin y elementos del RUP

Ya conociendo varias partes del RUP nos concentraremos ahora en

los elementos que lo componen, entre estos se tienen: flujos de
trabajo, detalle de los flujos de trabajo, actores, actividades (o
acciones) y artefactos.

19.

Actores o roles

Son los personajes encargados de la realizacin de las actividades

definidas dentro de los flujos de trabajo de cada una de las
disciplinas del RUP
20.

Analistas

- Analista del Proceso del Negocio.

- Diseador del Negocio.
- Revisor del Modelo del Negocio.
- Revisor de Requerimientos.
- Analista del Sistema.
- Especificador de Casos de Uso.
- Diseador de Interfaz del Usuario.
21.

Desarrolladores

- Arquitecto.
- Revisor de la Arquitectura.
- Diseador de Cpsulas.
- Revisor del Cdigo y Revisor del Diseo.
- Diseador de la Base de Datos.
- Diseador.
- Implementador y un Integrador.
22.

Probadores Profesionales

- Diseador de Pruebas.
- Probador.
23.

Encargados

- Encargado de Control del Cambio.

- Encargado de la Configuracin.
- Encargado del Despliegue.
- Ingeniero de Procesos.
- Encargado de Proyecto.
- Revisor de Proyecto.
24.

Otros

- Cualquier trabajador.
- Artista Grfico.
- Stakeholder.

- Administrador del Sistema.

- Escritor tcnico.
- Especialista de Herramientas.
25.

Artefactos

Los artefactos son el resultado parcial o final que es producido y

usado por los actores durante el proyecto. Son las entradas y
salidas de las actividades, realizadas por los actores, los cuales
utilizan y van produciendo estos artefactos para tener guas. Un
artefacto puede ser un documento, un modelo o un elemento de
modelo.
25.1. Conjunto de artefactos:
1. Modelado

del

negocio:

Capturan

presentan

el

contexto del negocio del sistema. Los artefactos del

modelado del negocio sirven como entrada y como
referencia para los requisitos del sistema.
2. Requerimientos: Capturan y presentan la informacin
usada en definir las capacidades requeridas del sistema.
3. Anlisis y diseo del sistema: Capturan y presenta la
informacin relacionada con la solucin a los problemas
que se presentaron en los requisitos fijados.
4. Implementacin: Capturan y presentan la realizacin de
la solucin presentada en el anlisis y diseo del sistema.
5. Pruebas: Los artefactos desarrollados como productos de
las actividades de prueba y de la evaluacin son
agrupadas por el actor responsable, con el cual se lleva
un conjunto de documentos de informacin sobre las
pruebas

realizadas

las

metodologas

de

pruebas

aplicadas.
6. Despliegue:

Capturan

presentan

la

informacin

relacionada con la transitividad del sistema, presentada

en la implementacin en el ambiente de la produccin.

7. Administracin del proyecto: Capturan los artefactos

asociados con el proyecto, el planeamiento y a la
ejecucin del proceso.
8. Administracin

de

cambios

configuracin:

Capturan y presentan la informacin relacionada con la

disciplina de configuracin y administracin del cambio.
9. Entorno o ambiente: Presenta los artefactos que se
utilizan como direccin a travs del desarrollo del sistema
para asegurar la consistencia de todos los artefactos
producidos.
26.

Desventajas de la metodologa:

No capturar un caso de uso a tiempo puede causar una

reconstruccin parcial de la arquitectura.
La falta de especificaciones en los requisitos por parte del
usuario puede causar ciertas discrepancias.
Se requiere mucho personal (dependiendo del proyecto).
27.

Ventajas de la metodologa:

Es el proceso de desarrollo ms general de los existentes

actualmente.
Es una forma disciplinada de asignar tareas y responsabilidades
en

una empresa de desarrollo (quin hace qu, cundo y

cmo).

Reutilizacin.

El diseador piensa en trminos del comportamiento de objetos

y no en detalles de bajo nivel.

Confiabilidad, Integridad y Estabilidad.

Mantenimiento ms sencillo. Modificaciones locales.

DIAGRAMAS DEL UML EL UML

El UML est compuesto por diversos elementos grficos que se
combinan para conformar diagramas. Debido a que el UML es un
lenguaje, cuenta con reglas para combinar tales elementos. La
finalidad de los diagramas es presentar diversas perspectivas de un
sistema, a las cuales se les conoce como modelo. Recordemos que un
modelo es una representacin simplificada de la realidad; el modelo
UML describe lo que supuestamente har un sistema, pero no dice
cmo implementar dicho sistema.
A continuacin se describirn los diagramas ms comunes del UML y
los conceptos que representan:
Diagrama de Clases
Diagrama de Objetos
Diagrama de Casos de Uso
Diagrama de Estados
Diagrama de Secuencias
Diagrama de Actividades
Diagrama de Colaboraciones
Diagrama de Componentes
Diagrama de Distribucin
Otras caractersticas
Paquetes
Notas
Estereotipos
1. Diagrama de clases:
Describen la estructura esttica de un sistema:

Las cosas que existen y que nos rodean se agrupan naturalmente en

categoras. Una clase es una categora o grupo de cosas que tienen
atributos (propiedades) y acciones similares.
Un ejemplo puede ser la clase Aviones que tiene atributos como el
modelo de avin, la cantidad de motores, la velocidad de

crucero y la capacidad de carga til. Entre las acciones de las

cosas de esta clase se encuentran: acelerar, elevarse, girar,
descender, desacelerar.
Un rectngulo es el smbolo que representa a la clase, y se divide en
tres reas. Un diagrama de clases est formado

por varios

rectngulos de este tipo conectados por lneas que representan las

asociaciones o maneras en que las clases se relacionan entre si

LAS METODOLOGAS GILES

1. Qu son las metodologas giles?
Las metodologas giles son una serie de tcnicas para la gestin
de proyectos que han surgido como contraposicin a los mtodos
clsicos de gestin como CMMI. Aunque surgieron en el mbito del
desarrollo de software, tambin han sido exportadas a otro tipo de
proyectos.
Todas las metodologas que se consideran giles cumplen con
el manifiesto gil que no es ms que una serie de principios que se
agrupan en 4 valores:
2. Los individuos y su interaccin, por encima de los procesos
y las herramientas.
3. El software

que

funciona, frente a la documentacin

exhaustiva.
4. La colaboracin con el cliente, por encima de la negociacin
contractual.
5. La respuesta al cambio, por encima del seguimiento de un
plan.
Inicialmente, mucha gente asocia metodologas giles con falta de
documentacin

control

sobre

el

proyecto,

pero

esto

es

totalmente falso! Lo que se desea es minimizar el impacto de las

tareas que no son totalmente imprescindibles para conseguir el
objetivo del proyecto. Se pretende aumentar la eficiencia de
las personas involucradas en el proyecto y como resultado de
ello, minimizar el coste.

Llegados a este punto, nos preguntamos si son mejores las

metodologas giles que las tradicionales. La respuesta es que no.
Entonces, son mejores las tradicionales frente a las giles?
Tampoco. Como otras muchas cosas en la vida, depende del tipo
de proyecto en el que se apliquen y aqu es donde tienen su punto
de unin con los principios Lean Startup.
2. Por qu estn relacionadas las metodologas giles y Lean
Startup?
Las metodologas tradicionales funcionan muy bien en proyectos
donde el problema es conocido y la solucin al mismo est bien
definida. En este entorno es fcil analizar, disear y ejecutar una
solucin, pero totalmente opuesto al entorno de una Startup.
Una Startup, por definicin, es una organizacin temporal se
mueve en un entorno de extrema incertidumbre buscando un
modelo de negocio replicable y escalable.
Una Startup que siga el enfoque Lean, plantea una serie de
hiptesis sobre un problema y realiza muchos experimentos con
distintas maneras de resolverlo. En resumen, tenemos un entorno
muy cambiante donde no est claro el problema a solucionar, ni la
forma de hacerlo. En este entorno son claramente ms
eficaces las metodologas giles ya que stas incorporan
mecanismos de gestin del cambio que implican un menor
esfuerzo.
Por lo tanto, lo que debemos tener claro es que:

Los principios Lean Startup se encargan de qu construir.

Las metodologas giles se encargan de cmo hacerlo.

3. Las principales metodologas giles

Uno de los principales focos de aplicacin de las metodologas
giles son los proyectos tecnolgicos. Cada una de ellas tiene sus
fortalezas y sus debilidades, pero no son excluyentes. En cada
proyecto

podemos adoptar una, o varias, en funcin de las

caractersticas del propio proyecto y del equipo.

Entre las metodologas giles ms usadas se encuentran:

 SCRUM. Es un marco de trabajo que nos proporciona una serie

de herramientas y roles para, de una forma iterativa, poder ver
el progreso y los resultados de un proyecto.
KANBAN. Se basa en una idea muy simple. sta es que el
trabajo en curso (Work In Progress, WIP) 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.
XP: 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.
Si ests pensando en adoptar alguna de estas metodologas, antes
de seleccionar cul, debes hacer un anlisis de sus debilidades, del
tipo de proyecto a gestionar y, si puedes, consulta con algn
gestor de proyectos. Yo, desde mi experiencia, te puedo dar 2
consejos muy bsicos:
Cambiar una forma de trabajar en una organizacin es una
tarea ardua y difcil. Al implantar una metodologa gil, no
realices un cambio demasiado brusco, adptalas poco a poco.
En

cualquier

metodologa

gil

el

cliente/usuario

del

software, tiene un papel clave. Si su implicacin y/o dedicacin

no va a ser muy alta, quizs este tipo de metodologas no sean las
ms apropiadas o habra que buscar alguna alternativa para
disponer del conocimiento del cliente/usuario del software a
desarrollar.

METODOLOGA SCRUM
1. 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.
Esquema:

2. 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.
3. Beneficios
1. Cumplimento de expectativas: El cliente establece sus
expectativas indicando el valor que le aporta cada requisitohistoria 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.
2. 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.

3. Reduccin del Time to Market: El cliente puede empezar a

utilizar las funcionalidades ms importantes del proyecto antes
de que est finalizado por completo.
4. 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.
5. 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.
6. 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.
7. 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.

8. 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.
4. Para qu sirve el Scrum en la Metodologa gil?
El Scrum es un proceso de la Metodologa gil que se usa
para minimizar los riesgos durante la realizacin de un proyecto,
pero de manera colaborativa.
Entre las ventajas se encuentran la productividad, calidad y que se
realiza un seguimiento diario de los avances del proyecto, logrando

que los integrantes estn unidos, comunicados y que el cliente

vaya viendo los avances.
5. Cmo funciona el Proceso
En primer lugar se define el Product Backlog, lo que nos permitir
realizar nuestros Sprints ms adelante.
Product

Backlog:

Es

una wish

list

sobre

las

funcionalidades del producto. Es elaborado por el Product

Owner y las funciones estn priorizadas segn lo que es ms y
menos importante para el negocio. El objetivo es que el Product
Owner responda la pregunta Qu hay que hacer?.
Sprint Backlog: Es un subconjunto de temes del Product
Backlog, que son seleccionados por el equipo para realizar
durante el Sprint sobre el que se va a trabajar. El equipo
establece la duracin de cada Sprint.
Sprint Planning Meeting: Esta reunin se hace al comienzo
de cada Sprinty se define cmo se va a enfocar el proyecto
que viene del Product Backlog las etapas y los plazos. Cada
Sprint

est

compuesto

por

diferentes

features. Por

ejemplo, decidimos que los features del primer Sprint son:

diseo del logo, definicin colores y contenido multimedia.
Daily

Scrum

Stand-up

Meeting: Es

una reunin

breve que se realiza a diario mientras dura el periodo de

Sprint. Se responden individualmente tres preguntas: Qu
hice

ayer?,

Qu

voy

hacer

hoy?,

Qu

ayuda

necesito? El Scrum Master debe tratar de solucionar los

problemas u obstculos que se presenten.
Sprint Review: Se revisa el sprint terminado, y ya debera
haber un avance claro y tangible para presentrselo al cliente.

 Sprint

Retrospective:

El

equipo revisa

los objetivos

cumplidos del Sprint terminado. Se anota lo bueno y lo malo,

para no volver a repetir los errores. Esta etapa sirve para
implementar mejoras desde el punto de vista del proceso del
desarrollo.

6. Participantes:
Product Owner: Habla por el cliente, y asegura que el equipo
cumpla las expectativas. Es el jefe responsable del proyecto.
Scrum Master: Lidera las reuniones y ayuda al equipo si es que
tienen problemas. Adems, minimiza los obstculos para cumplir el
objetivo del Sprint, es un facilitador pero no es un gestor.
Scrum Team: Son los encargados de desarrollar y cumplir lo que
les asigna el Product Owner.
Cliente: Recibe

el

producto

y puede

influir

en

el

proceso,

entregando sus ideas o comentarios respecto al desarrollo.

7. Para qu sirve el Scrum en la Metodologa gil?
El Scrum es un proceso de la Metodologa gil que se usa
para minimizar los riesgos durante la realizacin de un
proyecto, pero de manera colaborativa.
Entre las ventajas se encuentran la productividad, calidad y
que se realiza un seguimiento diario de los avances del

proyecto, logrando que los integrantes estn unidos, comunicados

y que el cliente vaya viendo los avances.
8. Cmo funciona el Proceso:
a. En primer lugar se define el Product Backlog, lo que nos
permitir realizar nuestros Sprints ms adelante.
b. Product

Backlog:

Es

una wish

list

sobre

las

funcionalidades del producto. Es elaborado por el Product

Owner y las funciones estn priorizadas segn lo que es ms y
menos importante para el negocio. El objetivo es que el Product
Owner responda la pregunta Qu hay que hacer?.
c. Sprint Backlog: Es un subconjunto de temes del Product
Backlog, que son seleccionados por el equipo para realizar
durante el Sprint sobre el que se va a trabajar. El equipo
establece la duracin de cada Sprint.
d. Sprint Planning Meeting: Esta reunin se hace al comienzo
de cada Sprinty se define cmo se va a enfocar el proyecto
que viene del Product Backlog las etapas y los plazos. Cada
Sprint

est

compuesto

por

diferentes

features. Por

ejemplo, decidimos que los features del primer Sprint son:

diseo del logo, definicin colores y contenido multimedia.
e. Daily

Scrum

Stand-up

Meeting: Es

una reunin

breve que se realiza a diario mientras dura el periodo de

Sprint. Se responden individualmente tres preguntas: Qu
hice

ayer?,

Qu

voy

hacer

hoy?,

Qu

ayuda

necesito? El Scrum Master debe tratar de solucionar los

problemas u obstculos que se presenten.
f. Sprint Review: Se revisa el sprint terminado, y ya debera
haber un avance claro y tangible para presentrselo al cliente.
g. Sprint

Retrospective:

El

equipo revisa

los objetivos

cumplidos del Sprint terminado. Se anota lo bueno y lo malo,

para no volver a repetir los errores. Esta etapa sirve para

implementar mejoras desde el punto de vista del proceso del
desarrollo.

9. Participantes:
a. Product Owner: Habla por el cliente, y asegura que el equipo

cumpla las expectativas. Es el

jefe

responsable

del

proyecto.
b. Scrum Master: Lidera las reuniones y ayuda al equipo si es

que tienen problemas. Adems, minimiza los obstculos para

cumplir el objetivo del Sprint, es un facilitador pero no es un
gestor.
c. Scrum Team: Son los encargados de desarrollar y cumplir

lo que les asigna el Product Owner.

d. Cliente: Recibe el producto y puede influir en el proceso,

entregando sus ideas o comentarios respecto al desarrollo.

METODOLOGA CRYSTAL CLEAR

1 Qu es Crystal Clear?
Crystal Clear no es una metodologa en si misma sino una familia
de metodologas con un cdigo gentico comn.
El nombre Crystal deriva de la caracterizacin de los proyectos
segn dimensiones, tamao y complejidad como en los minerales,
color y dureza.
Es la compilacin de un conjunto de metodologas que faciliten
el desarrollo de software dependiendo de varios factores, teniendo
como principal factor la cantidad de desarrolladores, incluida
dentro de las llamadas metodologas giles se caracteriza por
estar orientada a las personas que integran el equipo o grupo de
desarrolladores, que son en su mayor parte sobre los que recaer
el xito o fracaso del proyecto, as como a la disminucin de
artefactos que se produzcan. Surge a principios de los 90 por idea
de Alistair Cockburn con el objetivo de dar solucin a problemas
especficos de organizacin que presentaba el proyecto que se
llevaba a cabo en ese instante y a pesar de que ya haban surgido
y se encontraban en desarrollo otras metodologas giles como
la XP

(Extreme

Programing) y Scrum no

se

adaptaban

los

inconvenientes que ellos presentaban. Esta metodologa tiene

como premisa que el equipo o grupo de desarrolladores es
considerado el factor clave en el desarrollo de software por lo que
la mayor parte de los esfuerzos deben estar orientados a fortalecer
sus destrezas y habilidades, as como tener bien definidas la
poltica de trabajo en equipo que van a depender del tamao del
grupo.

2. Caractersticas
Una de sus caractersticas principales es la vital importancia que
se les da a los desarrolladores que componen el grupo de trabajo,
por lo cual sus puntos de estudio estn destinados a:
Aspecto humano del equipo
Tamao de un equipo
Comunicacin entre los desarrolladores
Polticas a seguir
Espacio fsico de trabajo
3. Rasgos de un equipo Crystal
Una disminucin en el nmero de desarrolladores proporcionar
una mejor comunicacin entre los mismos.
Trabajar en un mismo lugar dar lugar a una disminucin de
gastos por conceptos de comunicacin.
La mejora individual habilitar el paso a la mejora del equipo y
por consecuente al producto final.
4. Metodologas Crystal

Dependiendo de la cantidad de desarrolladores involucrados, el

bienestar de los mismos, el ciclo de vida del desarrollo del
proyecto,

el

presupuesto

monetario

imprescindible

el

presupuesto de uso opcional Cristal Methodologies es capaz de

clasificarse mediante los siguientes colores que determinan las
metodolas incluidas dentro de las metodologas Crystal:
Crystal Yellow
Crystal Orange
Crystal Orange Web
Crystal Red
Crystal Magenta
Crystal Blue

Aunque solamente tres de ellos han sido realmente construidos

y son usados en proyectos empresariales, institucionales etc.
a. Crystal Clear:
Esta denotacin esta diseada para grupos o equipos de
desarrollo de uno a seis desarrolladores que trabajen en una
misma oficina u oficinas adyacentes y en donde el proyecto
que se lleve a cabo no sea de gran envergadura o con grandes
dificultades para su desarrollo. La misma cuenta con cuatro
roles principales:
1. Patrocinador o ejecutivo que costee el proyecto
2. Diseador-programador lder
3. Diseador-programador
4. Cliente (que estara la menor parte del tiempo en el
desarrollo del proyecto).
Esta caracterizado por

tener libertades

en cuanto

a la

modelacin de los casos de uso, calendarios de visitas con el

cliente, creacin de borradores etc. que atrasaran la entrega de
un producto no complejo, aunque si recomienda la poltica
estndar de entregas incrementales al ciente as como las
pruebas convenientes del producto.
b. Crystal Orange
Puede incluir hasta 40 desarrolladores que sus respectivos
locales residan en el mismo edificio y que estaran trabajando
en un proyecto que por momentos puede estar hacindole
perder al equipo presupuesto de uso opcional. Est diseado
para sistemas de tamao o complejidad media. Los roles que
participan en esta seccin de la metodologa son:
1. Patrocinador o ejecutivo que costee el proyecto
2. Experto en negocios
3. Experto en usos tcnicos

4. Analista/diseador de negocios
5. Gerente del proyecto
6. Arquitecto de software
7. Diseador lder
8. Programador lder
9. Otros diseadores-programadores
10. Diseador de interfaz de usuario
11. Reuse point
12. Escritor de cdigo
13. Probador
Estos roles estn organizados en equipos denotados como:
equipo de planificacin del sistema, monitoreo del proyecto,
tecnologa, infraestructura, y pruebas externas.
El producto debe estar dotado de documentacin, liberacin
de secuencias, calendarios, reportes de estado del proyecto,
documentacin de la interfaz de usuario, modelo comn de
objetos (diseo de clases, bases de datos etc.), manual de
usuario, cdigo fuente, casos de prueba y cdigo de migracin
en caso de existir.
c. Orange Web:
Esta metodologa tiene como diferencia de la anterior que esta
diseada para proyectos que estn sometidos a cambios
continuos debido a que son usados por el cliente, segn su
creador (2003) esta metodologa se encuentra en prueba, y
presenta alrededor de 50 roles divididos en ejecutivos, gente
de

negocios,

gerentes,

analistas,

programadores,

probadores. Comparado con Crystal Orange presenta menos

proyectos debido a que generalmente se dedican a uno solo
con actualizacin de versiones.
5. Ventajas y Desventajas de las metodologas Crystal
5.1. Ventajas
Son apropiadas para entornos ligeros

 Al estar diseada para el cambio experimenta reduccin de

costo.
Presenta

una

planificacin

ms

transparente

para

los

clientes.
Se definen en cada iteracin cuales son los objetivos de la
siguiente.
Permite tener una muy til realimentacin de los usuarios.
5.2. Desventajas
Delimita el alcance del proyecto con el cliente.
6. Crystal Methodologies vs Metodologas tradicionales
Metodologas
tradicionales
Planificacin
predictiva y
aislada
Diseo flexible y
extensible,
modelos y
documentacin
exhaustiva.
Desarrollo
individual con roles
y
responsabilidades
estrictas.
Actividades de
control orientadas
a los hitos

vs
Anlisis de
requerimientos y
planificacin
Diseo

Codificacin

Pruebas y puesta
en produccin

Metodologas Crystal
Planificacin adaptativa
vista en entregas
frecuentes y
colaboracin del cliente
Diseo simple:
documentacin mnima
enfocada en la
comunicacin
Transferencia de
conocimiento: la
programacin en grupo
propicia el
conocimiento colectivo.
LiderazgoColaboracin:
empoderamiento y auto
organizacin.

Mtodos de Desarrollo de Sistemas Dinmicos (DSDM)

1. Mtodos de desarrollo de sistemas dinmicos

El mtodo de desarrollo de sistemas dinmicos en ingls Dynamic

Systems Development Method o DSDM.

DSDM fue desarrollado en el Reino Unido en los aos 90 por un

consorcio de proveedores y de expertos en la materia del desarrollo
de sistemas de informacin (IS).

Es un Mtodo que provee un framework para el desarrollo gil de

software.

DSDM se centra en los proyectos de sistemas de informacin que son

caracterizados por presupuestos y agendas apretadas.

2. Principios del DSDM

Involucrar al cliente es la clave para llevar un proyecto eficiente

y efectivo.

El equipo del proyecto debe tener el poder para tomar

decisiones que son importantes.

DSDM se centra en la entrega frecuente de productos.

El desarrollo es iterativo e incremental.

Todos los cambios durante el desarrollo son reversibles.

Las pruebas son realizadas durante todo el ciclo vital del

proyecto.

3. Requisitos previos para el uso de DSDM:

Interactividad, los usuarios y los jefes de Desarrollo.

Motivacin y participacin entre las partes (humanas) que

integran el equipo.

4. Situaciones No Aplicables Para DSDM

No existe aceptacin por parte de la direccin y otros

empleados.

Consiste en la falta de motivacin y participacin.

Poca habilidad por parte de los integrantes del equipo.

5. Diagrama del ciclo de vida del proyecto

Modelo:

METODOLOGA FDD
Es una metodologa gil para el desarrollo de sistemas, basado en
la calidad del software,

que

incluye

un

monitoreo

constante

del proyecto.
FDD fue desarrollado por Jeff De Luca y Peter Coad a mediados de los
aos 90. Esta metodologa se enfoca en iteraciones cortas que
permite entregas tangibles del producto en corto periodo de tiempo
que como mximo son de dos semanas.
Contenido
1. Caractersticas:
No hace nfasis en la obtencin de los requerimientos sino en
como se realizan las fases de diseo y construccin.
Se preocupa por la calidad, por lo que incluye un monitoreo
constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el
presupuesto, fallas en el programa o el hecho de entregar
menos de lo deseado.
Propone tener etapas de cierre cada dos semanas.
Se obtienen resultados peridicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que
producen un software funcional que el cliente y la direccin de
la empresa pueden ver y monitorear.
Define claramente entregas tangibles y formas de evaluacin
del progreso del proyecto.
2. Procesos
El FDD tiene cinco procesos. Los primeros tres se hacen al principio
del proyecto.
a. Desarrollar un modelo global: Al inicio del desarrollo se

construye un modelo teniendo en cuenta la visin, el contesto y

los requisitos que debe tener el sistema a construir. Este
modelo se divide en reas que se analizan detalladamente. Se
construye un diagrama de clases por cada rea.

b. Construir una lista de los rasgos: Se elabora una lista que

resuma las funcionalidades que debe tener el sistema, cuya

lista es evaluada por el cliente. Cada funcionalidad de la lista se
divide en funcionalidades ms pequeas para un mejor
entendimiento del sistema.
c. Planear por rasgo: Se procede a ordenar los conjuntos de

funcionalidades conforme a su prioridad y dependencia, y se

asigna a los programadores jefes.
d. Disear

por

rasgo:

Se

selecciona

un

conjunto

de

funcionalidades de la lista. Se procede a disear y construir la

funcionalidad mediante un proceso iterativo, decidiendo que
funcionalidad se van a realizar en cada iteracin. Este proceso
iterativo incluye inspeccin de diseo, codificacin, pruebas
unitarias, integracin e inspeccin de cdigo.
e. Construir por Rasgo: se procede a la construccin total del

proyecto.
3. Roles y responsabilidades
El equipo de trabajo est estructurado en jerarquas, siempre debe
haber un jefe de proyecto, y aunque es un proceso considerado
ligero tambin incluye documentacin (la mnima necesaria para
que algn nuevo integrante pueda entender el desarrollo de
inmediato).
4. Director del Proyecto: Lder administrativo y financiero del

proyecto. Protege al equipo de situaciones externas.

5. Arquitecto jefe: Realiza el diseo global del sistema. Ejecucin de

todas las etapas.

6. Director de desarrollo: Lleva diariamente las actividades de

desarrollo. Resuelve conflictos en el equipo. Resuelve problemas

referentes a recursos.
7. Programador

Jefe:

Analiza

los

requerimientos.

Disea

el

proyecto. Selecciona las funcionalidades a desarrollar de la ltima

fase del FDD.

8. Propietario de clases: Responsable del desarrollo de las clases

que se le asignaron como propias. Participa en la decisin de que

clase ser incluida en la lista de funcionalidades de la prxima
iteracin.
9. Expertos de dominio: Puede ser un usuario, un cliente, analista o

una

mezcla

de

requerimientos

estos.

del

Poseen

sistema.

el

Pasa

conocimiento

el

conocimiento

de

los

los

desarrolladores para que se asegure la entrega de un sistema

completo.
10.

Comparacin

Puesto que todos los procesos se centran en la produccin de

software es deseable una comparacin, no en su conjunto, sino
segn los medios que emplean y sus resultados. Realizamos una
comparacin entre FDD, RUP y XP.
11.

Tamao de los equipos: RUP esta pensado para proyectos y

equipos grandes, en cuanto a tamao y duracin. FDD y XP se

implementan

mejor

para

proyectos

cortos

equipos

ms

pequeos, siendo quizs FDD ms escalable que XP.

12.

Obtencin de requisitos: RUP y XP crean como base

UseCases

UserStories,

por

lo

contrario

FDD

no

define

explcitamente esa parte del proyecto sobre la adquisicin de

requisitos.
13.

Evaluacin del estado del proyecto: FDD es posiblemente el

proceso ms adecuado para definir mtricas que definan el estado

del proyecto, puesto que al dividirlos en unidades pequeas es
bastante sencillo hacer un seguimiento de las mismas. XP tambin
define esos componentes pequeos. RUP por su parte, es tan
grande y complejo en este sentido como en el resto, por lo que
manejar el volumen de informacin que puede generar requiere
mucho tiempo.
14.

Carga de trabajo: XP es un proceso ligero, esto es, que los

creadores del proceso han tenido cuidado de no poner demasiadas

tareas organizativas sobre los desarrolladores. RUP es un proceso

pesado, basado mucho en la documentacin, en la que no son

deseables todos esos cambios voltiles. FDD es por su parte un
proceso

intermedio,

en

el

sentido

de

que

genera

ms

documentacin que XP pero menos que RUP.

15.

Relacin con el cliente: Con RUP se presentarn al cliente los

artefactos del final de una fase, en contrapartida, la aseguracin

de la calidad en XP y FDD no se basa en formalismos en la
documentacin, si no en controles propios y una comunicacin
fluida con el cliente.
16.

Conocimiento sobre la arquitectura: En RUP se intentar

reducir la complejidad del software a producir a travs de una

planificacin intensiva. En XP se conseguir a travs de la
programacin a pares que ya en la creacin del cdigo se puedan
evitar errores y malos diseos. En FDD sin embargo se usan las
sesiones de trabajo conjuntas en fase de diseo para conseguir
una arquitectura sencilla y sin errores.

DESARROLLO DE SOFTWARE ADAPTATIVO (ASD)

1. Definicin:
ASD es una metodologa impulsada por Jim Highsmith que
incorpora el principio de la adaptacin continua, o sea, 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.
El desarrollo de software adaptativo reemplaza el ciclo de cascada
tradicional con una serie repetitiva de ciclos de especulacin,
colaboracin y aprendizaje. Este ciclo dinmico proporciona un

aprendizaje continuo y una adaptacin al estado emergente del

proyecto
Sus principales caractersticas son:
Iterativo.
Orientado a los componentes software mas que a las tareas.
Tolerante a los cambios.
Guiado por los riesgos.
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: Especularcolaborar-aprender, el cual est dedicado a un constante
aprendizaje y colaboracin entre desarrollador y cliente.
2. 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.
3. Colaboracin:
Desarrollo concurrente del trabajo de construccin y gestin del
producto.

4. Aprendizaje:
En cada iteracin se revisa:
-

Calidad del producto desde el punto de vista del cliente.

Calidad del

producto

desde

desarrolladores.
-

Funcionalidad desarrollada.

Estado del proyecto

el

punto

de

vista

de

los

Caractersticas bsicas de ASD

-

Trabajo orientado y guiado por la misin del proyecto.

Basado en la funcionalidad

Desarrollo iterativo

Desarrollo acotado temporalmente

Guiado por los riesgos

Trabajo tolerante al cambio

5. 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.
6. 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.

7. Modelos de esquemas de ciclo de vida:

7.1.

Ciclo de Vida en Cascada

7.2.

Ciclo de Vida Evolutivo

7.3.

Modelo Adaptativo

METODOLOGIA XP
1. Qu es XP?

Metodologa para un gil desarrollo de software.

Programacin basada en los deseos del cliente.

El equipo lo conforman los jefes de proyecto,

desarrolladores y el cliente.

Se rige por valores y principios.

2. Valores de XP

Comunicacin: Crear software requiere de sistemas

comunicados.

Simplicidad: Empezar con lo necesario y requerido y

trabajar desde ah.

Retroalimentacin: Del sistema, del cliente, y del equipo.

Valenta: Programa para hoy y no para maana.

Respeto: El equipo debe trabajar como uno, sin hacer

decisiones repentinas.

3. Caractersticas

i.

Desarrollo iterativo e incremental: pequeas mejoras, unas

tras otras.

ii.

Pruebas

unitarias continuas,

frecuentemente

repetidas

automatizadas, incluyendo pruebas de regresin. Se aconseja

escribir el cdigo de la prueba antes de la codificacin.
iii.

Programacin en parejas: se recomienda que las tareas de

desarrollo se lleven a cabo por dos personas en un mismo puesto.
Se supone que la mayor calidad del cdigo escrito de esta manera
-el cdigo es revisado y discutido mientras se escribe es ms
importante que la posible prdida de productividad inmediata.

iv.

Frecuente integracin del equipo de programacin con el

cliente o usuario. Se recomienda que un representante del cliente
trabaje junto al equipo de desarrollo.

v.

Correccin

de

todos

los errores antes

de

aadir

nueva

funcionalidad. Hacer entregas frecuentes.

vi.

Refactorizacin del cdigo, es decir, rescribir ciertas partes del

cdigo para aumentar su legibilidad y mantenibilidad pero sin
modificar su comportamiento. Las pruebas han de garantizar que
en la refactorizacin no se ha introducido ningn fallo.

vii.

Propiedad del cdigo compartida: en vez de dividir la

responsabilidad en el desarrollo de cada mdulo en grupos de
trabajo distintos, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresin garantizan que los posibles
errores sern detectados.

viii.

Simplicidad en el cdigo: es la mejor manera de que las cosas

funcionen. Cuando todo funcione se podr aadir funcionalidad si
es necesario. La programacin extrema apuesta que es ms
sencillo hacer algo simple y tener un poco de trabajo extra para
cambiarlo si se requiere, que realizar algo complicado y quizs
nunca utilizarlo.

ix.

La

simplicidad

complementarias.

la

comunicacin

Con

ms

son

comunicacin

extraordinariamente
resulta

ms

fcil

identificar qu se debe y qu no se debe hacer. Cuanto ms simple

es el sistema, menos tendr que comunicar sobre ste, lo que
lleva a una comunicacin ms completa, especialmente si se
puede reducir el equipo de programadores.
4. Valores de la metodologa Xp
Simplicidad
Comunicacin
Retroalimentacin
Coraje o valenta
5. Los pasos de la metodologa Xp
Segn Kent Beck:

Desarrollo iterativo e incremental

Pruebas unitarias continuas

Programacin en parejas

Frecuente integracin del equipo de programacin con el cliente

o usuario

Refactorizacin del cdigo

Simplicidad del cdigo

Propiedad del cdigo compartido

6. Fases de la metodologa Xp
Segn Kent Beck

7. Ventajas y desventajas:
7.1.

Ventajas

Programacin organizada.

Menor taza de errores.


7.2.

Satisfaccin del programador

Desventajas

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar

8. Ciclo de la XP

8. Usos y aplicaciones de XP

Extreme Programming se usa actualmente para la creacin y

desarrollo practico de software.

Este se ha usado mucho ltimamente, ya que es una

metodologa gil para desarrollar software, antes de dar
ejemplos de empresas que aplican

Extreme programming,

citar las ventajas y desventajas que este tipo de metodologa

gil aporta.

CONCLUSIONES

El retrasar las decisiones en un proyecto de software permite

potenciar el valor del producto tanto para el cliente como al equipo
o empresa que desarrolla

Para que un grupo de desarrollo adopte una metodologa gil debe

poseer experiencia trabajando con metodologas tradicionales, ya
que la experiencia es la que predomina en los mementos cruciales
del proyecto, adems debe tener la capacidad de ser equipos
auto-gestionados, altamente motivados y con gran innovacin

Las metodologas giles permiten disminuir costos

y brindar

flexibilidad a los proyectos de software donde la incertidumbre

est presente

El uso de metodologas tradicionales es esencial al inicio en un

equipo de desarrollo de software

Las metodologas giles se deberan aplicar en proyectos donde

exista mucha incertidumbre donde el entorno es voltil, donde los

requisitos

no se conocen con exactitud, mientras que las

metodologas

tradicionales

obligan

al

cliente

tomar

las

decisiones al inicio del proyecto.

BIBLIOGRAFA
Metodologas giles: La ventaja competitiva de estar preparado
para tomar decisiones lo ms tarde
cualquier

momento.

(En

posible y cambiarlas en

lnea),

Disponible

en:

www.spinec.org/wp-content/metodologiasagiles_01.pdf
Metodologas giles en lnea ,Disponible en: http://www.agilespain.com
ICONIX (En lnea), Disponible en:

www.spinec.org/wp-

content/ICONIX.pdf
Extreme Programming Refactored: The Case Against XP, MATT
Stephens and DOUG Rosenberg, Disponible en Formato chm
Introduccin a Iconix en lnea, Disponible en:
http://www.informit.com/articles/article.asp?
p=167902&rl=1